Report forwarded
to bug-guix@gnu.org: bug#33678; Package guix.
(Sat, 08 Dec 2018 21:37:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Danny Milosavljevic <dannym@scratchpost.org>:
New bug report received and forwarded. Copy sent to bug-guix@gnu.org.
(Sat, 08 Dec 2018 21:37:02 GMT) (full text, mbox, link).
Can we do something against the locale problems that keep showing up
when updating?
Right now, after a half-finished update from guix master (half-finished because
once any package build breaks, the entire update will stop), I cannot use any
Umlauts because "xterm -u8" stops working as it should:
$ xterm -u8
Warning: locale not supported by C library, locale unchanged
$
Why does this keep happening? Shouldn't the functional nature and modularity
of Guix keep using the old locales where those make sense and the new locales
where those make sense?
Environment:
$ locale -a
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_COLLATE to default locale: No such file or directory
C
POSIX
$ echo $LC_ALL
de_DE.utf8
$ echo $LANG
en_US.utf8
$ echo $GUIX_LOCPATH
/run/current-system/locale
$ ls $GUIX_LOCPATH/2.28/en_US.utf8/
LC_ADDRESS LC_IDENTIFICATION LC_MONETARY LC_PAPER
LC_COLLATE LC_MEASUREMENT LC_NAME LC_TELEPHONE
LC_CTYPE LC_MESSAGES LC_NUMERIC LC_TIME
$ ls xxx
ls: Zugriff auf 'xxx' nicht möglich: Datei oder Verzeichnis nicht gefunden
$
^^ Note: Message is in German, as it should. I left in the mangled Umlauts
for documentation purposes.
(Aha, updating just xterm fixes the problem).
When locales don't work, I can't enter umlauts at all - they get replaced by a
"generic" character that isn't an umlaut, even when checked using a hexdump
tool.
So not only couldn't I see the umlauts, I couldn't type them blindly either.
Danny Milosavljevic <dannym@scratchpost.org> writes:
> (Aha, updating just xterm fixes the problem).
>
> When locales don't work, I can't enter umlauts at all - they get replaced by a
> "generic" character that isn't an umlaut, even when checked using a hexdump
> tool.
>
> So not only couldn't I see the umlauts, I couldn't type them blindly either.
Does adding locales for both the new and old libc to your system help?
E.g.:
(operating-system
[...]
(locale-libcs (list glibc-2.27 (canonical-package glibc))))
?
On Sat, Dec 08, 2018 at 10:35:51PM +0100, Danny Milosavljevic wrote:
> Can we do something against the locale problems that keep showing up
> when updating?
>
> Right now, after a half-finished update from guix master (half-finished because
> once any package build breaks, the entire update will stop), I cannot use any
> Umlauts because "xterm -u8" stops working as it should:
> $ xterm -u8
> Warning: locale not supported by C library, locale unchanged
> $
>
> Why does this keep happening? Shouldn't the functional nature and modularity
> of Guix keep using the old locales where those make sense and the new locales
> where those make sense?
>
> Environment:
>
> $ locale -a
> 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_COLLATE to default locale: No such file or directory
Is this only on foreign distros? I cannot reproduce this in a Guix VM.
These errors occurred for me on the foreign distro Debian also for
Debian commands like localectl because the locale command was taken
from a glibc in root’s guix profile. I uninstalled the glibc package
and now Debian’s locale commands work again. `strace locale` made it
seem like the directory for the de_DE.UTF-8 locale was never checked
by the locale program, only de_DE.utf8 and others, which apparently
are not what Debian uses.
Regards,
Florian
Information forwarded
to bug-guix@gnu.org: bug#33678; Package guix.
(Sat, 08 Dec 2018 23:37:01 GMT) (full text, mbox, link).
Guten Tag! :-)
Danny Milosavljevic <dannym@scratchpost.org> skribis:
> Can we do something against the locale problems that keep showing up
> when updating?
>
> Right now, after a half-finished update from guix master (half-finished because
> once any package build breaks, the entire update will stop), I cannot use any
> Umlauts because "xterm -u8" stops working as it should:
> $ xterm -u8
> Warning: locale not supported by C library, locale unchanged
> $
>
> Why does this keep happening? Shouldn't the functional nature and modularity
> of Guix keep using the old locales where those make sense and the new locales
> where those make sense?
Please see:
https://www.gnu.org/software/guix/manual/en/html_node/Locales.html#Locale-Data-Compatibility-Considerations
The solution, as described in this section, is to have both (say)
locales for glibc 2.27 and locales for glibc 2.28, which you can specify
in ‘locale-libcs’.
Another option is what ‘guix’ commands print every time you run them: to
install the corresponding ‘glibc-utf8-locales’ package.
Now I perfectly understands that this annoys everyone of us when that
happens, and many people don’t seem to find the info. So I’m open to
suggestions on how to improve this!
Thanks,
Ludo’.
Added tag(s) fixed.
Request was from Ludovic Courtès <ludo@gnu.org>
to control@debbugs.gnu.org.
(Mon, 08 Apr 2019 20:24:02 GMT) (full text, mbox, link).
bug closed, send any further explanations to
33678@debbugs.gnu.org and Danny Milosavljevic <dannym@scratchpost.org>
Request was from Ludovic Courtès <ludo@gnu.org>
to control@debbugs.gnu.org.
(Mon, 08 Apr 2019 20:24:03 GMT) (full text, mbox, link).
bug archived.
Request was from Debbugs Internal Request <help-debbugs@gnu.org>
to internal_control@debbugs.gnu.org.
(Tue, 07 May 2019 11:24:04 GMT) (full text, mbox, link).
Debbugs is free software and licensed under the terms of the
GNU Public License version 2. The current version can be
obtained from https://bugs.debian.org/debbugs-source/.