Bugzilla Bug 137297

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 an attachment (id=102939) [details]
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 an attachment (id=102938) [details]
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'.