I use sylpheed-claws-0.9.5, updated it yesterday. It depends on >=sys-devel/gettext-0.12. Now when I emerge sync, the gettext-ebuilds have been reorganized. sys-devel/gettext-0.12.ebuild has ben removed (tried different rsync-mirrors) and sys-devel/gettext-0.12.1.ebuild has keywords="-*" set and is obviously not installable. Emerge also wants to downgrade gettext to 0.11.5-r1 when I emerge -p gettext. Why is gettext 0.12.1 not installable? I did not get any problems compiling it. I use ACCEPT_KEYWORDS="~x86".
try ACCEPT_KEYWORDS="-nls" it's ofcourse just a workaround
Do you mean USE="-nls" or ACCEPT_KEYWORDS="-nls"? Okay, but my workaround is just to modify the gettext-0.12.1.ebuild from KEYWORDS="-*" to KEYWORDS="~x86" and make it installable. I do not have any problems with gettext 0.12.1... Both are really dirty workarounds but I still cannot see the reason why gettext-0.12.1 should not be installable.
I also upgraded portage tree to version 2.0.49-r5 I changed KEYWORDS="~x86" on gettext ebuild file as described by Bernd Wurst and all compiled well without any errors.
I've been having this bug too, but updating to gettext-0.11.5-r1 fixes it. I'm using keywords "~ppc"
err... oops was updating to lower version than required. maybe sylpheed-claws could be changed to require that version?
stu $ emerge -u world -vp These are the packages that I would merge, in order: Calculating world dependencies \ !!! all ebuilds that could satisfy ">=sys-devel/gettext-0.12" have been masked. !!! (dependency required by "net-mail/sylpheed-claws-0.9.5" [ebuild]) !!! Problem with ebuild net-mail/sylpheed-claws-0.9.5 !!! Possibly a DEPEND/*DEPEND problem. !!! Depgraph creation failed. stu $ From the Sylpheed-claws ChangeLog 06 Sep 2003; Karl Trygve Kalleberg <karltk@gentoo.org> sylpheed-claws-0.9.4-r1.ebuild: Won't compile without gettext-0.12 or newer, added proper dep. I would relly like to be able to emerge other things (or at least get a list of those that need updating!!!), but someone decided to mask gettext-0.12 before checking other dependancies. Unmerging gettext-0.12 and sylpheed-claws-0.9.4 is NOT an option - they both work fine and fix a few bugs. And yes, I need nls for reading non-english emails.
KNOCK! KNOCK! It's been 2 weeks that this has been going on! Aren't there any developers out there that can change the DEPEND in sylpheed-claws or mask it or something. It's a real pain to have to mask syslpheed-claws-0.9.5 everytime I emerge sync.
Well 2 1/2 weeks and we get a new version with exactly the same problem!. Seemant added sylpheed-claws-0.9.6 to the cvs tree and it still depends on the "-*" masked gettext-0.12. Guess I'm gonna spend the next month or so unmasking gettext everytime I sync so that I can emerge -up world to see what needs updating :(
Stuart is not the only one with this problem. I'd like to emerge update world, but the claws/gettext-0.12 problem kills the process. Without removing sylpheed-claws, which I love, how can I get around this problem? Or can someone fix the ebuild...
The problem with gettext is that bootstrap fails with gettext 0.12. Unmasking it would make systems uninstallable for a lot of people, which is obviously a much bigger pain in the rear than a mail client not working.
I understand the reason for gettext being masked, however I don't understand the reason for sylpheed-claws not being masked if it depends on a masked package. I have installed gettext-0.12.1 and sylpheed-claws with no problems, my problem is that at present portage fails to emerge -up world properly.
Seems to me that portage has facilities to resolve these problems yourself when running testing builds and trees, things such as package.unmask/mask and PORTDIR_OVERLAY are there for a reason, I'd suggest reading up on them and your life will be _allot_ easier living on the bleeding edge. Problems such as these are bound to happen from time to time while a resolution is being worked out in the unstable tree, learning the correct way to "workaround" these problems is a good thing IMHO.
I know of several work arounds, but I'm not really living on the bleeding edge. I have a small number of ~x86 package installed happens to include sylpheed-claws-0.9.4-r1, which I would install on all computers I use as it has been rock solid for me and has all the features I require in a mail app. As I have mentioned before I expect some rocky periods for being "~x86", and realize that some apps won't necessarily play well together, but it had been over 3 weeks and I didn't get any help or suggestions until I posted on gentoo-dev. It appears that the dev population disagrees with me that not masking sylpheed-claws while it depends on a masked package is a problem. I'll stop bothering you with my bugzilla posts then. P.S. Package.unmask doesn't help here as gettext is not masked in package.mask, but instead "-*" - an easier way to get around this would be nice.
The thing is, it doesn't actually need gettext-0.12. If you change the dependency to use an unmasked version of gettext, it compiles and runs fine.
One thing I don't understand: Why is gettext-0.12 not MASKED but UNINSTALLABLE? If it would be in the package.mask as usual, I could place a line "=sys-devel/gettext-0.12" in my /etc/portage/package.unmask and everything would be fine. At the moment, it's uninstallable because it's not marked for any architecture. Why is this done that way? Would be nice if there were a possibility in package.mask for masking on specific architectures only. :-)
gettext-0.12 is marked for ia64.
So it's really a sylpheed-claws ebuild bug. Reassigning to Seemant accordingly.
sylpheed does need gettext > 0.12 afaik for correct string translations etc in certain languages other than english.
Is the bootstrap prblem still valid, I thought drobbins fixed it a few weeks ago. I also think that the -* is not necessary, we already tell people to NOT use AK="~x86" during bootstrap which is IMO sufficient. And yes, sylpheed-claws >= 0.9.4 really needs gettext-0.12 for nls support. So we either get gettext unmasked really soon or mask all sylpheed-claws versions >=0.9.4 (which will probably disgust a lot of people).
If memory serves, the bootstrap problem was fixed by including gettext directly in stages. That means that anyone using even slightly older stages will get screwed if it's unmasked.
Just had an idea for another possible solution: add a check to bootstrap.sh to print a big warning / error out if the user has ACCEPT_KEYWORDS="~x86" and USE="nls" set.
The simple workaround for me was to create a copy of gettext-0.12.1.ebuild in $PORTDIR_OVERLAY/sys-devel/gettext/ edit the KEYWORDS to ~x86 instead of -* and leave it at that. Emerge -up world and emerge sync will now work happily, up untl gettext-0.12.2 comes out anyway.
gettext has been fixed to not check for cpp and g++, though the patch could do with some cleaning. Battoussai is currently in the cleaning process for it.
