Locales not working

Locales not working

[Andreas Enge]

Hello,

after the latest upgrade of my profile, the locales do not seem to work
any more. All the fancy utf8 in your messages is broken in mutt, and
the locale command returns:
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=de_DE.UTF-8
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=

Do I need to set anything special? Install a separate package?

In the meantime, hooray for "--roll-back"! Äöüß!

Andreas

Re: Locales not working

[Andreas Enge]

Ah, it turns out that I wrote my message before reading the ongoing discussion
on locales. What a coincidence! So we were at least two being bitten by this
bug (yes, yes) at the same time! I do not think it is reasonable to break
systems for saving 100MB.

The code of glibc states
            ;; Installing a locale archive with all the locales is to
            ;; expensive (~100 MiB), so we rely on users to install the
            ;; locales they really want.
But how do I do that? I wondered if there was an additional "locale" output
of glibc, but there is not.

$ guix package -A locale
does not return anything useful.

There is a section 6.2.6 in the manual, but it only speaks about GSD,
not about Guix inside other systems.

So there needs to be a simple way to install locales to be used by Guix
packages, and it needs to be documented. Or the patch could be reverted.

Andreas

Re: Locales not working

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> The code of glibc states
>             ;; Installing a locale archive with all the locales is to
>             ;; expensive (~100 MiB), so we rely on users to install the
>             ;; locales they really want.
> But how do I do that? I wondered if there was an additional "locale" output
> of glibc, but there is not.
>
> $ guix package -A locale
> does not return anything useful.
>
> There is a section 6.2.6 in the manual, but it only speaks about GSD,
> not about Guix inside other systems.

Right, Mark reported it as well.

The basic idea is that it’s up to you to define $LOCPATH and have it
point to a place that contains locale data (info "(libc) Locale Names").

But I think we could provide a ‘glibc-locales’ package (110 MiB) for
those in search of a quick fix on foreign distros.

(Time passes...)

Commit aee6180c adds ‘glibc-locales’.  You can install it and do:

  export LOCPATH=$HOME/.guix-profile/share/locale

though that’s not the most efficient approach space-wise.

I would instead recommend using your host libc’s locale data, which
should be compatible; something like that (untested):

  export LOCPATH=/usr/share/locale

Last, commit d6718df of ‘core-updates’ adds a search path specification
for ‘LOCPATH’.  (Not really useful for profiles since one would need to
explicitly install glibc in their profile to get the message about
‘LOCPATH’.)

Ludo’.

Re: Locales not working

[Andreas Enge]

On Wed, Feb 11, 2015 at 09:39:36PM +0100, Ludovic Courtès wrote:
> Commit aee6180c adds ‘glibc-locales’.  You can install it and do:
>   export LOCPATH=$HOME/.guix-profile/share/locale

Excellent, that works for me!

Thank you very much,

Andreas

Re: Locales not working

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:

> Commit aee6180c adds ‘glibc-locales’.  You can install it and do:
>
>   export LOCPATH=$HOME/.guix-profile/share/locale

I tried adding 'glibc-locales' to my system profile, and got this:

--8<---------------cut here---------------start------------->8---
ERROR: union-build: collision between file and directories ((files ("/gnu/store/nda1ih2iy8likfipl62afiqs6jwdsfxi-glibc-locales-2.20/share/locale/zh_CN/LC_TIME")) (dirs ("/gnu/store/mgfqcbm31rh738z13xlwh9ld9dm2vfvz-coreutils-8.23/share/locale/zh_CN/LC_TIME")))
--8<---------------cut here---------------end--------------->8---

Indeed, in coreutils "share/locale/zh_CN/LC_TIME" is a directory
containing a symbolic link "coreutils.mo" pointing to
"../LC_MESSAGES/coreutils.mo", whereas in glibc-locales
"share/locale/zh_CN/LC_TIME" is a binary file.

Any ideas how to resolve this conflict?

      Mark

LC_TIME category in Coreutils

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> I tried adding 'glibc-locales' to my system profile, and got this:
>
> ERROR: union-build: collision between file and directories ((files ("/gnu/store/nda1ih2iy8likfipl62afiqs6jwdsfxi-glibc-locales-2.20/share/locale/zh_CN/LC_TIME")) (dirs ("/gnu/store/mgfqcbm31rh738z13xlwh9ld9dm2vfvz-coreutils-8.23/share/locale/zh_CN/LC_TIME")))
>
> Indeed, in coreutils "share/locale/zh_CN/LC_TIME" is a directory
> containing a symbolic link "coreutils.mo" pointing to
> "../LC_MESSAGES/coreutils.mo", whereas in glibc-locales
> "share/locale/zh_CN/LC_TIME" is a binary file.
>
> Any ideas how to resolve this conflict?

I would have expected packages other than libc to provide only
LC_MESSAGES, so I didn’t think such collisions could happen.

This happens with Coreutils because its bootstrap.conf adds
‘EXTRA_LOCALE_CATEGORIES = LC_TIME’ to po/Makevars, and apparently
always has.

However, I suspect this isn’t needed.  Can someone comment?

Thanks,
Ludo’.

bug#19933: LC_TIME category in Coreutils

[Andreas Schwab]

ludo@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver <mhw@netris.org> skribis:
>
>> I tried adding 'glibc-locales' to my system profile, and got this:
>>
>> ERROR: union-build: collision between file and directories ((files ("/gnu/store/nda1ih2iy8likfipl62afiqs6jwdsfxi-glibc-locales-2.20/share/locale/zh_CN/LC_TIME")) (dirs ("/gnu/store/mgfqcbm31rh738z13xlwh9ld9dm2vfvz-coreutils-8.23/share/locale/zh_CN/LC_TIME")))
>>
>> Indeed, in coreutils "share/locale/zh_CN/LC_TIME" is a directory
>> containing a symbolic link "coreutils.mo" pointing to
>> "../LC_MESSAGES/coreutils.mo", whereas in glibc-locales
>> "share/locale/zh_CN/LC_TIME" is a binary file.
>>
>> Any ideas how to resolve this conflict?
>
> I would have expected packages other than libc to provide only
> LC_MESSAGES, so I didn’t think such collisions could happen.

glibc's locale files are supposed to reside in $(libdir)/locale, not
$(datadir)/locale, so there is no conflict.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: LC_TIME category in Coreutils

[Ludovic Courtès]

Andreas Schwab <schwab@linux-m68k.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Mark H Weaver <mhw@netris.org> skribis:
>>
>>> I tried adding 'glibc-locales' to my system profile, and got this:
>>>
>>> ERROR: union-build: collision between file and directories ((files ("/gnu/store/nda1ih2iy8likfipl62afiqs6jwdsfxi-glibc-locales-2.20/share/locale/zh_CN/LC_TIME")) (dirs ("/gnu/store/mgfqcbm31rh738z13xlwh9ld9dm2vfvz-coreutils-8.23/share/locale/zh_CN/LC_TIME")))
>>>
>>> Indeed, in coreutils "share/locale/zh_CN/LC_TIME" is a directory
>>> containing a symbolic link "coreutils.mo" pointing to
>>> "../LC_MESSAGES/coreutils.mo", whereas in glibc-locales
>>> "share/locale/zh_CN/LC_TIME" is a binary file.
>>>
>>> Any ideas how to resolve this conflict?
>>
>> I would have expected packages other than libc to provide only
>> LC_MESSAGES, so I didn’t think such collisions could happen.
>
> glibc's locale files are supposed to reside in $(libdir)/locale, not
> $(datadir)/locale, so there is no conflict.

Oops, indeed (I had been using a custom value for ‘libc_cv_localedir’
and overlooked what the default value is.)

Thank you,
Ludo’.

bug#19933: LC_TIME category in Coreutils

[Paul Eggert]

On 02/23/2015 01:28 PM, Ludovic Courtès wrote:
> I suspect this isn’t needed.

This is needed so that 'ls -l' can output a date format suitable for the 
current locale.  These formats aren't part of glibc and so are not in 
glibc's LC_TIME information.  The default formats for the C locale are 
"%b %e  %Y" for older files and "%b %e %H:%M" for newer files, but the 
formats differ in other locales (e.g., Dutch uses "%e %b" instead of "%b 
%e").

Re: bug#19933: LC_TIME category in Coreutils

[Ludovic Courtès]

Paul Eggert <eggert@cs.ucla.edu> skribis:

> On 02/23/2015 01:28 PM, Ludovic Courtès wrote:
>> I suspect this isn’t needed.
>
> This is needed so that 'ls -l' can output a date format suitable for
> the current locale.  These formats aren't part of glibc and so are not
> in glibc's LC_TIME information.  The default formats for the C locale
> are "%b %e  %Y" for older files and "%b %e %H:%M" for newer files, but
> the formats differ in other locales (e.g., Dutch uses "%e %b" instead
> of "%b %e").

I see, thanks for the explanation.

Ludo’.