Since today, gimp-2.2-pre1 is released. An ebuild followes. I think it would be a good idea to put this in ~arch.
Created attachment 43169 [details] gimp-2.2-pre1 ebuild
Oh, I don't want to forget, the ebuild must be named gimp-2.2_pre1.ebuild not gimp-2.1-pre1.ebuild because Gentoo doesn't support this naming scheme
Bah, f*ck. It must be named "gimp-2.2_pre1.ebuild" not "gimp-2.2-pre1.ebuild". Sorry for that garbage.
Please watch your language, I'm not sure if any of us have time to maintain and watch pre-releases, opinion foser?
Created attachment 43383 [details] gimp-2.2_pre1-r1.ebuild Hanno pointed me to some elegancy issues. I've also fixed the SLOT-issue (gimp-2.2 isn't slottable with gimp-2.0.x, so it must be SLOT=2)
When I try and run this, I get : The GIMP requires FreeType version 2.1.7 or later. Installed FreeType version is 2.1.5. @reporter: are you using a masked version of freetype, or can you explain why I might be getting this message since you aren't. I don't have any general knowlege of fonts/freetype stuff.
Thanks for pointing me to this issue, I think its time for -rc2 ;-) I should fix the dependencies. Btw: foser, you've mentioned in the package.mask, that >=freetype-2.1.7 breaks many things but I'm using 2.1.9 and it seems to work fine. What issues are they in concrete?
Created attachment 43405 [details] gimp-2.2_pre1-r2.ebuild added freetype-2.1.7 to RDEPEND
well theres a bug open on >=freetype-2.1.7 issues that has more detail.
2.2 vs 2.0 is a night vs day difference and after trying 2.2, I dont see how anyone could move back :) -- anyway, point being, this really aught to be on portage. Also: server portage # find ./ | grep "_pre" | wc -l 821 So I dont see it being a pre release is any reason not to put it in portage. Especially since the gimp developers say its pretty stable.
Gimp's configure fails if glibc is < 2.4.5 so the ebuild should require glibc >= 2.4.5
from the wiki: http://wiki.gimp.org/gimp/WhatsNew2 GIMP now can be compiled as a console application, with no dependence on Gtk. Maybe the ebuild should handle this. (--enable-gimp-console) Benoit
gimp-2.2_pre2 is out
There is currently a problem with gimp-2.2_pre2. It failes while compiling. I will try to include the --enable-gimp-console-Feature. Sorry, it will take just a few days more, because my amount of time is currently very small so I have to delay this for a short time.
gimp-2.2 final version is out.
2.2 final is out. Couldn't compile with first try to copy old ebuild.
*** Bug 74991 has been marked as a duplicate of this bug. ***
upstream bug http://bugzilla.gnome.org/show_bug.cgi?id=161716 solution: copy the file and put it in the right place
Addition: The freetype plugin doesn't like freetype 2.1.9
I have now merged the previous ebuild for 2.0 and the pre1-r2 from this bug into an ebuild that works for me for 2.2.0, I will attach an ebuild and the .png file that is needed for the build. Can you please explain how you test the freetype-plugin, it worked for me as far as I could see. It crashed once, but I got it to work the second time. My config: freetype-2.1.9 gimp-2.2.0 gtk+-2.4.14 Although Bug 57783 still hits when I try to emerge gtk+ again...
Created attachment 46477 [details] Ebuild for gimp-2.2.0 that works for me Also the next attachment is needed, a .png-file is missing in the tarball.
Created attachment 46478 [details] Picture that is missing from the gimp-tarball Put the .png-file into /usr/portage/media-gfx/gimp/files/ before using the gimp-2.2.0.ebuild attached to this bug.
Created attachment 46516 [details] gimp-2.2.0 ebuild here an ebuild that should work for everybody, I'll commit it if is ok for everybody
bzip2 the pygimp-logo.png file in the ${FILESDIR} to use the posted ebuild
I'm just testing now on x86 and ppc, I'll add this to CVS as soon as I'm done.
Depending on bug 49494, because we require >=freetype-2.1.7
the .png image needs to be copied to plug-ings/pygimp/
correction plug-ins/pygimp/
Maybe I am wrong, but I think that: >=dev-libs/glib-2.2 >=x11-libs/gtk+-2.2.2 is not sufficient. I upgraded to glib 2.4.8 and gtk+ 2.4.13 and it compiles ok now. It did not before, and the ebuild didn't upgrade these libs. Regards: Uwe Fechner
We are aware of all of this, and have a completely working gimp-2.2 ebuild, with the fixed png, all of the dependencies updated etc. The only reason this isn't added is because it requires a masked version of freetype (>=2.1.7), and until that's unmasked, we can't add gimp-2.2. So in short, we thank you for your patience. Thanks.
Mike, Perhaps you can add GIMP 2.2 to Portage as also being masked in that case?
it is added (maybe the deps aren't all fixed in the ebuild I put yet)
freetype-2.1.9 is now available in ~. Should gimp-2.2 be unmasked yet
Have just compiled gimp 2.2 together with freetype-2.19-r1. Works fine for me. (Don't know if this is the right place to post such information, but I'll give it a try in the hope that it is valuable. Pls correct if I'm wrong.)
Created attachment 47059 [details] Freetype 2.1.7 The only way to have gimp 2.2 and firefox 1.0 is installing freetype >= 2.1.7 but <2.1.9. This is and ebuild removed from portage to install freetype 2.1.7
firefox works fine with freetype-2.1.9 (see mozilla-firefox-1.0-4ft2.patch which is applied by the ebuild) regards
firefox-1.0 was a blocker on my machine at first too. Unmerged it and afterwards emerged firefox-1.0-r3 without a problem. Works perfectly.
Gimp 2.2.1 just came out. Anyone know when this is going to get into portage?
"Fresh from 21C3, GIMP version 2.2.1 has been released. This is a bug-fix release in the stable GIMP 2.2 series. It fixes a couple of problems that have been reported for GIMP 2.2.0; an update is strongly recommended. The sources for GIMP 2.2.1 can be downloaded from the usual places." http://www.gimp.org
*** Bug 76394 has been marked as a duplicate of this bug. ***
# <lu_zero@gentoo.org> (22 Dec 2004) # Not ready yet Thanks for the descriptive reason for masking it. Gives me no clue whether or not I should go ahead and emerge it or wait.
It should be safe to unmask with the corrections obz made to the ebuild, but it's up to him to remove the final mask. This pack shouldn't have been added in it's initial state & the mask shouldn't have been necessary, but excitement and social pressure from bugs like these sometimes stab QA in the back.
Just a note, gimp-2.2.2 is out.
Created attachment 48393 [details] gimp-2.2.2.ebuild I've created a gimp-2.2.2.ebuild, containing lot's of cleanups: - cd ${S} - # Fix linking to older version of gimp if installed - this should - # void liquidx's hack, so it is removed. - epatch ${FILESDIR}/ltmain_sh-1.5.0-fix-relink.patch This was afaik only needed for linking-problems within the 1.3.x-prereleases. - # Install the missing pygimp logo - cp ${FILESDIR}/pygimp-logo.png ${S}/plug-ins/pygimp/ Fixed in current release. - # Since 1.3.16, fixes linker problems when upgrading - elibtoolize Same as above (1.3.x-releases). - # only use mmx if hardened is not set - local USE_MMX= Can't see the need of this, the MMX-useflag-thing is handled later with the HARDENED_SUPPRESS_MMX-var. - replace-flags "-march=k6*" "-march=i586" Tested on my k6, seems to be fixed in current release. - # gimp uses inline functions (plug-ins/common/grid.c) (#23078) - filter-flags "-fno-inline" Testet, no problem (this was a gimp 1.2-bug). - --disable-default-binary \ This is probably the reason why gimp-2 still doesn't install a gimp-binary, although it has been the default for a long time now. - # Create the gimp-remote link, see bug #36648 - dosym gimp-remote-2.2 /usr/bin/gimp-remote - Not needed with the above. Please test and give feedback if this can be committed.
> This was afaik only needed for linking-problems within the 1.3.x-prereleases. And why is that ? Are you sure the problem that was in the 1.3 releases is not in 2.0 ? (same goes for libtool problem) > Can't see the need of this, the MMX-useflag-thing is handled later with the HARDENED_SUPPRESS_MMX-var. Didn't look at the code, but this is about actually resetting a buildtime var iirc. It's not related to the use flag. > Tested on my k6, seems to be fixed in current release. This is the sort of thing i wouldn't bet on. > Testet, no problem (this was a gimp 1.2-bug). Same thing, often those bugs are quite confined to specific CFLAG setups. > This is probably the reason why gimp-2 still doesn't install a gimp-binary, although it has been the default for a long time now. This has been a deliberate choice SLOT-wise.
I've built gimp using your gimp-2.2.2 ebuild on amd64 (gcc 3.4.3) : that's clean for me.
Just one little point : I'd like to see the "=gimp-print-4.2.*" dependency replaced with ">=gimp-print-4.2" because gimp 2.2 builds against gimp-print-5.0.0_beta2.
gimp-2.0.x can not compile against >=gimp-print-4.3.
Tried out 2.2.2 on x86. unmasked and compiled gimp-print-5.0.0_beta2 first; but the config couldn't find it, didn't have time to dig in so I just downgraded it back to 4.2.7 and everything went fine. gcc-3.4.3-r1 glibc-2.3.4.20041102 freetype-2.1.9-r1 gimp-print-4.2.7 gimp-2.2.2
Hi, gimp-2.2.3 is out. What's holding this ebuild back from portage-incluison? Poly
I also call for 2.2.3 (and alot of unmasking of the old 2.0.x's too).
It's released since more than 1 month and not yet in portage :( C'mon guys !
I just renamed the ebuild in Comment #44 and emerged gimp-2.2.3 with no problems on a completely ~x86 system. I'm not using gimp-print nor do I have it installed though.
Could we please get this into portage?
Installed 2.2.3 by renaming the 2.2.2 ebuild. Everything seems ok. Will be checking out gimp print soon. By the way shouldn't we be putting this in portage yet? After all; the GIMP IS a high demand package.
Hey, what's the problem with updating GIMP in the portage tree? For everyone here who's discussing himself to death or who is sleeping or for whatever reasons GIMP is still not updated in portage after months, please also read this thread in the forum to get more comments from users: http://forums.gentoo.org/viewtopic.php?t=283241
Gimp 2.2.0.6 is out =)
I have added gimp-2.2.3 to cvs. Now a small request: Please stop leaving comments on bugzilla such as "me too" or "Its been out forever!?!" Every time you leave one of these unhelpful and sometimes rude comments, we get yet another piece of email to sort through. I'm sure most devs here get hundreds of emails a day. It really adds up when you aren't able to check mail for a few days, and you then have to spend the first hours of free time you get going through things like this. Unless we mark the bug close, we know that the issue still exists. This is all done in our spare time, which most of us don't have a lot of right now. In the future, please be more considerate when using bugzilla. If you still feel the need to complain, start a thread in the forums where it doesn't interfere with our work. Sorry things sometimes take longer...
Thank you. Besides, many people do think that even though some things may be slow due to time constraints of the volunteers, and yet more people are willing to test this out (*raises hand*), should an ebuild be too long someone's got to be bugged about it. I'll respect your request within a reasonable amount of time, but even us artists can't wait for something that's been out for a long time (several months).
