Hello, at first lets see the docs: http://www.gentoo.org/doc/en/kde-split-ebuilds.xml - "To get absolutely all KDE split ebuilds, emerge kde-meta." http://www.gentoo.org/doc/en/kde-config.xml - "If you want a full-blown KDE installation, install kde-meta. This package will pull in all KDE applications as dependencies." Well, the second (the newer) one is not so clear (kde-i18n itself is not an application), but IMHO "all" or "full-blown" KDE should include kde-i18n ... I know it may sound strange to somebody, but there is really a big part of world outside America ;-) and this part is far bigger than the number of disabled people (who can select their enhancements at least via the USE "accessibility"). So I would suggest that if you do not want to install kde-i18n by default, make this at least USE controlled, or, in my opinion it would be nice to look at "userlocales" and system locale settings, and install it automatically if there is any other language than C or English. - thanks
You're right, it should be part of kde-meta. What you think of a "nls" useflag, in line with other packages? Usually nls is enabled for non-English systems.
(In reply to comment #1) > What you think of a "nls" useflag, in line with other packages? Usually nls is > enabled for non-English systems. > well, it looks like a good idea to me - reading the description, this use flag is exactly for that purpose ... a good example is the package man-pages - if nls is set, it pulls localised man pages
IA64 needs to be cleared up before. Please people mark ~ia64 version 3.5.3 of kde-i18n.
~ia64 done.
Thanks, fixed in CVS
(In reply to comment #5) > Thanks, fixed in CVS > We should change the nls use flag description to be more generic if nls use flag is to be used as we don't use gettext here I think: betelgeuse@pena ~ $ euse -i nls global use flags (searching: nls) ************************************************************ [- cD ] nls - Adds Native Language Support (using gettext - GNU locale utilities)
Reopening pending RFC on -dev...
Why don't you all mind your own business, for once? Sigh. KDE does use gettext for i18n, maybe we install something more (the doc) but it's always the same .mo files that get installed.
There is a problem. On a default system, nls is on by default. If I am using LINGUAS="en" for a plain English install (like most people would be doing) kde-meta will try to pull in kde-il8n. kde-il8n complains and fails to install because it does not support LINGUAS="en". The problem with this is now with a completely default install, you can not install kde-meta.
As mentioned in the comment above, this breaks a stable default install. i.e nls is turned on by default and no LINGUAS variable is set. Unfortunately for english speakers, setting LINGUAS="en" doesn't work either. The only thing to do is add "kde-base/kde-meta -nls" to /etc/portage/package.use which most likely isn't going to be obvious to a newer user.
*** Bug 156498 has been marked as a duplicate of this bug. ***
There still a problem, and it is not fixed (like comment #9 and comment #10 described). Other bugs are being marked as duplicate of this. This should be marked as REOPENED. I guess many people are asking this in forums and IRC.
(In reply to comment #10) I tried the solution of adding kde-base/kde-meta -nls to package.use and get the error: >> Emerging (1 of 1) kde-base/kde-i18n-3.5.5 to / ...snip... >>> Unpacking source... /usr/portage/kde-base/kde-i18n/kde-i18n-3.5.5.ebuild: line 27: [: missing `]' The line from the ebuild it says is in error is: if [ -z "${A}" && LINGUAS != "en"]; then
Someone forgot to check if LINGUAS was actually set or not. And it should be ${LINGUAS}... $ lack :)
Created attachment 102939 [details, diff] Patch to make ebuild work Latest change in CVS bypasses the explicit dying and error message but now breaks when it tries to unpack ${A} because A is actually empty. Here is a patch, tested, that makes everything work.
Created attachment 102938 [details, diff] Patch to make ebuild work Latest change in CVS bypasses the explicit dying and error message but now breaks when it tries to unpack ${A} because A is actually empty. Here is a patch, tested, that makes everything work.
*** Bug 156543 has been marked as a duplicate of this bug. ***
(In reply to comment #13) > >>> Unpacking source... > /usr/portage/kde-base/kde-i18n/kde-i18n-3.5.5.ebuild: line 27: [: missing `]' > > if [ -z "${A}" && LINGUAS != "en"]; then For me, the ] should be separated by space. Like this: if [ -z "${A}" && "${LINGUAS}" != "en" ]; then Of course, you could also use [[ ]] instead of [ ]
(In reply to comment #18) > (In reply to comment #13) > > >>> Unpacking source... > > /usr/portage/kde-base/kde-i18n/kde-i18n-3.5.5.ebuild: line 27: [: missing `]' > > > > if [ -z "${A}" && LINGUAS != "en"]; then > > For me, the ] should be separated by space. Like this: > > if [ -z "${A}" && "${LINGUAS}" != "en" ]; then > > Of course, you could also use [[ ]] instead of [ ] > This has already been fixed in portage. The problem is, this caused the other problem in the ebuild that I mentioned in comment #15 (and #16, stupid double posting).
Sorry to be stupid, but the patch from 15/16 helps, but the emerge still fails because LINGUA is not set, and "en" is not acceptable. I suppose I could set "en_GB" but I don't want to as the Brits don't know how to spell properly :-) What do I have to do to get a bog-stock stable system to update without needing magic incantations ? But I do appreciate the prompt attention from folks here, but it is not "fixed" as long as "emerge avuDN world" fails on a stock stable system.
(In reply to comment #20) > Sorry to be stupid, but the patch from 15/16 helps, but the emerge still fails > because LINGUA is not set, and "en" is not acceptable. I suppose I could set > "en_GB" but I don't want to as the Brits don't know how to spell properly :-) > > What do I have to do to get a bog-stock stable system to update without needing > magic incantations ? > > But I do appreciate the prompt attention from folks here, but it is not "fixed" > as long as "emerge avuDN world" fails on a stock stable system. > Try syncing the latest version. It should now have all relevant fixes. It works for me and I have only LINGUAS="en". Just make sure you have LINGUAS set in make.conf. I suppose maybe the error should add "en" to the list to be more helpful because the whole point of the latter part of the bug was getting "en" to work.
OK, thanks much. Works much better with "LINGUAS" instead of "LINGUA" :-)
Who's in charge of the KDE configuration guide? We should update it to state that LINGUAS needs to be set to a valid value (to include en) in order to install kde-meta. As it stands right now, a default stable install does not have LINGUAS set, so installing kde-meta will fail until it is set.
(In reply to comment #23) > Who's in charge of the KDE configuration guide? We should update it to state > that LINGUAS needs to be set to a valid value (to include en) in order to > install kde-meta. As it stands right now, a default stable install does not > have LINGUAS set, so installing kde-meta will fail until it is set. It would not be hard to change the ebuild so that if LINGUAS is not set, it would be treated the same as LINGUAS="en". My guess is that this would be the best desired effect. Also it should be noted that "en" should be added to the list of valid languages in the error message that is produced when an invalid LINGUAS is encountered.
Not to be pedantic, but shouldn't that be "en_US". Yanks are not the only ones who speak English, in fact they probably are some of the poorest speakers of the "King's English" (and yes, I am a Yank).
I'd opt for checking if LINGUAS is unset instead of forcing our users to add an unnecessary line. The other way around is to hardcode this into the eclass, but if it only affects one ebuild, let the ebuild treat it. Let Flameeyes speak about this.
*** Bug 157703 has been marked as a duplicate of this bug. ***
Reopening until unset LINGUAS is handled gracefully.
Fixed in CVS. The error message has been converted to a warning message and dies no more. It shows up only if LINGUAS is unset or if LINGUAS contains only unsupported languages. It does not show up if the only language code set is 'en'.
