Emerging control-center-1.4.0.5-r1 (sucked in by emerging gnucash) fails with a compilation error. Reproducible: Always Steps to Reproduce: 1. emerge gnucash (this leads to emerging control-center-1.4.0.5-r1) Actual Results: make all-recursive make[1]: Entering directory `/var/tmp/portage/control-center-1.4.0.5-r1/work/control-center-1.4.0.5' Making all in intl make[2]: Entering directory `/var/tmp/portage/control-center-1.4.0.5-r1/work/control-center-1.4.0.5/intl' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/var/tmp/portage/control-center-1.4.0.5-r1/work/control-center-1.4.0.5/intl' Making all in po make[2]: Entering directory `/var/tmp/portage/control-center-1.4.0.5-r1/work/control-center-1.4.0.5/po' make[2]: *** No rule to make target `en.gmo', needed by `all-yes'. Stop. make[2]: Leaving directory `/var/tmp/portage/control-center-1.4.0.5-r1/work/control-center-1.4.0.5/po' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/control-center-1.4.0.5-r1/work/control-center-1.4.0.5' make: *** [all-recursive-am] Error 2 !!! ERROR: gnome-base/control-center-1.4.0.5-r1 failed. !!! Function src_compile, Line 43, Exitcode 2 !!! (no error message) Expected Results: compilation should have succeeded I have LINGUAS set to 'en fr'. According to this link http://mail.gnome.org/archives/gnome-list/2000-February/msg00194.html this is the cause of the problem. I commented out the LINGUAS line and emerged gnucash again. This time it worked (and compilation of control-center did work as well).
We do not consider setting LINGUAS a valid option, because it is troublesome in a lot of occasions. So this is not a bug to us. control-center-1* is totally unmaintained btw, so i guess you're just stuck here disabling LINGUAS.
*** Bug 53593 has been marked as a duplicate of this bug. ***
http://www.gentoo.org/doc/en/handbook/draft/desktop.xml?part=1&chap=2#doc_chap3 explicitly advises to set LINGUAS in make.conf so that each update of kde-i18n would automatically include the right languages. In my opinion this looks like the right way and ebuilds that break with LINGUAS set should simply unset it.
There are even ebuilds that break if LINGUAS is _not_ set: root@cube:~# emerge -v --oneshot kde-i18n Calculating dependencies ...done! >>> emerge (1 of 1) kde-base/kde-i18n-3.2.2 to / >>> Unpacking source... * * You must define a LINGUAS environment variable that contains a list * of the language codes for which languages you would like to install. * e.g.: LINGUAS="se de pt" * !!! ERROR: kde-base/kde-i18n-3.2.2 failed. !!! Function src_unpack, Line 75, Exitcode 0 !!! (no error message) root@cube:~# So PLEASE fix this ASAP. I need both kde-i18n and gnucash (=> control-center) on the same host. BTW: It seems control-center only chokes on single-part language descriptors (i.e. "de", "en", ... instead of "en_GB", "en_US", "de_DE", ...). You might consider just filtering those out of LINGUAS. PS: Why is control-center used at all if it's unmaintained?
because ppl would scream and yell if we ripped it. Anyway it works just fine if not broken auto* features get added overnight.
I think it's bad behaviour of the kde-i18n ebuild to break when a non-default variable needs to be set to work. It's bad behaviour anyway not to work by default (make a default choice). reassigning to bug-wranglers.. i think it's a problem, but it's not gnome's personally i think whoever thought it was wise to make something as known problematic as setting LINGUAS part of portage behaviour, should also fix the problems that arise from adding it.
What "default" choice would you propose? There was a long discussion about this on a bug last year, (somewhere in the #9000 range) and LINGUAS was the variable that we (the kde team) were told to use.
portage isn't translated atm, you could use that as default language since that makes it the one language you can't get around. Or install everything, because that was what happened in the past i assume. Anyway, it's not for me to decide. I just think it's bad the ebuild stops when nothing is set, ebuilds ideally should merge without user interaction and i don't think this is a case where it is really impossible to get around that. But that isn't really the focus of this bug...
For the default language one does not need to install any language pack and kde-i18n is not needed.
*** Bug 55987 has been marked as a duplicate of this bug. ***
Gnome team - step up and close these as WONTFIX or fix it. I'm tired of these being tossed back and forth.
The ebuild is missing this dependency: <=orbit-0.5.17
closing WONTFIX, this is not the gnome teams problem @comment #12 : a) that dep isn't needed in this ebuild b) it's not relevant to this bug at all
I had to install orbit-0.5.17 to get control-center-1.4.0.5-r1 to compile look at the the configure script and (similar) errormessage if orbit isn
I had to install orbit-0.5.17 to get control-center-1.4.0.5-r1 to compile look at the the configure script and (similar) errormessage if orbit isn´t installed: checking for working ORBit environment... no make all-recursive make[1]: Entering directory `/var/tmp/portage/control-center-1.4.0.5-r1/work/control-center-1.4.0.5' Making all in intl make[2]: Entering directory `/var/tmp/portage/control-center-1.4.0.5-r1/work/control-center-1.4.0.5/intl' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/var/tmp/portage/control-center-1.4.0.5-r1/work/control-center-1.4.0.5/intl' Making all in po make[2]: Entering directory `/var/tmp/portage/control-center-1.4.0.5-r1/work/control-center-1.4.0.5/po' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/var/tmp/portage/control-center-1.4.0.5-r1/work/control-center-1.4.0.5/po' Making all in macros make[2]: Entering directory `/var/tmp/portage/control-center-1.4.0.5-r1/work/control-center-1.4.0.5/macros' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/var/tmp/portage/control-center-1.4.0.5-r1/work/control-center-1.4.0.5/macros' Making all in control-center make[2]: Entering directory `/var/tmp/portage/control-center-1.4.0.5-r1/work/control-center-1.4.0.5/control-center' make[2]: *** No rule to make target `no', needed by `my_control_center_idl'. Stop. make[2]: Leaving directory `/var/tmp/portage/control-center-1.4.0.5-r1/work/control-center-1.4.0.5/control-center' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/control-center-1.4.0.5-r1/work/control-center-1.4.0.5' make: *** [all-recursive-am] Error 2 !!! ERROR: gnome-base/control-center-1.4.0.5-r1 failed. !!! Function src_compile, Line 42, Exitcode 2 !!! (no error message) I´m sorry if it´s just garbage but I NEED to install orbit first to get it compile
*** Bug 67627 has been marked as a duplicate of this bug. ***
Let me tell you, for a gentoo user it is really sad to hitting this bug and then read this bugzilla issue. I can't believe after one year you've been unable to settle to a fix that works for everyone.
Why? We don't write Gnome, or even maintain it, we just package it up. If upstream has completely dropped support for a long time, there's nothing we can do. Feel free to fix it yourself, and maintain the result, but we are not Gnome, we are Gentoo.
i know the gnome team could probably care less but i think the `string-linguas` function would work well (it's in eutils.eclass) i use it in binutils to auto detect LINGUAS that each release supports instead of having to manually update some list myself
string-linguas would probably be fine, I didn't know of it's existance. Though i'd still like these issues to be adressed in a wider I18N effort, but thats beyond the scope of this bug. Reality is that we really should be ditching gnome-1.4 and that this is a good point in time to do so. So expect an announcement mail concerning this soon.
Please consider that the latest GnuCash release still requires Gnome-1. It's the only reason I've installed Gnome-related packages on my system at all. GnuCash is mission critical for me. Removing packages required for building GnuCash would render Gentoo useless for me.
*** Bug 97044 has been marked as a duplicate of this bug. ***
I've committed -r2 that should fix this issue, can you guys test and report back? Thanks!
*** Bug 102894 has been marked as a duplicate of this bug. ***
Tested, works just fine here. Thanks.
Closing
*** Bug 114809 has been marked as a duplicate of this bug. ***
