locales gone, gnome-terminal doesn't start up anymore

locales gone, gnome-terminal doesn't start up anymore

[Danny Milosavljevic]

Hi,

so I've updated to 947a5d47a50252cb0b87b78a8f83f274dec593e2 git guix and now I don't have any useful locales.

$ locale -a
C
POSIX

Also, gnome-terminal doesn't start anymore:

$ gnome-terminal
Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0: Error calling StartServiceByName for org.gnome.Terminal: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.gnome.Terminal exited with status 8

$ gnome-terminal --disable-factory
Failed to parse arguments: Option "--disable-factory" is no longer supported in this version of gnome-terminal.

Sigh... at least xterm still works.

Re: locales gone, gnome-terminal doesn't start up anymore

[Ludovic Courtès]

Hi,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> so I've updated to 947a5d47a50252cb0b87b78a8f83f274dec593e2 git guix and now I don't have any useful locales.
>
> $ locale -a
> C
> POSIX

I think this has always been the case because this command only lists
statically-known locales, strangely enough.

> Also, gnome-terminal doesn't start anymore:
>
> $ gnome-terminal
> Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0: Error calling StartServiceByName for org.gnome.Terminal: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.gnome.Terminal exited with status 8
>
> $ gnome-terminal --disable-factory
> Failed to parse arguments: Option "--disable-factory" is no longer supported in this version of gnome-terminal.

Hmm, I suppose there is something else going on here.

Could you try in ‘guix system vm’ with the desktop.tmpl example and see
if the same problem occurs?

Thanks for reporting it,
Ludo’.

Re: locales gone

[Danny Milosavljevic]

Hi Ludo,

On Thu, 29 Sep 2016 14:39:00 +0200
ludo@gnu.org (Ludovic Courtès) wrote:
> Danny Milosavljevic <dannym@scratchpost.org> skribis:
> 
> > so I've updated to 947a5d47a50252cb0b87b78a8f83f274dec593e2 git guix and now I don't have any useful locales.
> >
> > $ locale -a
> > C
> > POSIX  
> 
> I think this has always been the case because this command only lists
> statically-known locales, strangely enough.

Ok, but I also get:

/gnu/store/ybwj3wmsjjqyszc1jclbg7l36pdwkrl3-xonsh-0.4.6/lib/python3.4/site-packages/xonsh/__amalgam__.py:12122: RuntimeWarning: Failed to set locale 'LC_TIME' to 'de_DE.UTF-8'
  warnings.warn(msg, RuntimeWarning)

Also, nano doesn't support UTF-8 text anymore.

I mean I can live with it but there's definitely something broken there.

Re: locales gone

[Ludovic Courtès]

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> Hi Ludo,
>
> On Thu, 29 Sep 2016 14:39:00 +0200
> ludo@gnu.org (Ludovic Courtès) wrote:
>> Danny Milosavljevic <dannym@scratchpost.org> skribis:
>> 
>> > so I've updated to 947a5d47a50252cb0b87b78a8f83f274dec593e2 git guix and now I don't have any useful locales.
>> >
>> > $ locale -a
>> > C
>> > POSIX  
>> 
>> I think this has always been the case because this command only lists
>> statically-known locales, strangely enough.
>
> Ok, but I also get:
>
> /gnu/store/ybwj3wmsjjqyszc1jclbg7l36pdwkrl3-xonsh-0.4.6/lib/python3.4/site-packages/xonsh/__amalgam__.py:12122: RuntimeWarning: Failed to set locale 'LC_TIME' to 'de_DE.UTF-8'
>   warnings.warn(msg, RuntimeWarning)

Did you try “de_DE.utf8”?  See the bit about “normalized codeset” at
<https://www.gnu.org/software/guix/manual/html_node/Locales.html>.

Ludo’.

Re: locales gone

[Danny Milosavljevic]

Hi,

I read the docs you pointed me to - however, previously this worked fine as-is. Also, I have a database that is inaccessible because the locale suddenly (sometimes) doesn't work anymore. It's not like I can change what locale it was created in without a time machine :)

$ psql -U postgres template1
psql: FATAL:  database locale is incompatible with operating system
DETAIL:  The database was initialized with LC_COLLATE "en_US.UTF-8",  which is not recognized by setlocale().
HINT:  Recreate the database with another locale or install the missing locale.

Also,

sqlalchemy.exc.OperationalError: (psycopg2.OperationalError) FATAL:  database locale is incompatible with operating system
DETAIL:  The database was initialized with LC_COLLATE "en_US.UTF-8",  which is not recognized by setlocale().
HINT:  Recreate the database with another locale or install the missing locale.

........ hmm.

$ ls /run/current-system/locale/2.23/
ca_ES.utf8  en_CA.utf8   es_ES.utf8  fr_FR.utf8  nl_NL.utf8  tr_TR.utf8
cs_CZ.utf8  en_GB.utf8   es_MX.utf8  ga_IE.utf8  pl_PL.utf8  uk_UA.utf8
da_DK.utf8  en_US.utf8   fi_FI.utf8  it_IT.utf8  pt_PT.utf8  vi_VN.utf8
de_DE.utf8  en_US.UTF-8  fr_BE.utf8  ja_JP.utf8  ro_RO.utf8  zh_CN.utf8
el_GR.utf8  es_AR.utf8   fr_CA.utf8  ko_KR.utf8  ru_RU.utf8
en_AU.utf8  es_CL.utf8   fr_CH.utf8  nb_NO.utf8  sv_SE.utf8

$ export LC_COLLATE=en_US.UTF-8
$ python3
Python 3.4.3 (default, Jan  1 1970, 00:00:01) 
[GCC 4.9.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale(locale.LC_COLLATE, "")
'en_US.utf8'
$ psql -U postgres template1
psql: FATAL:  database locale is incompatible with operating system
DETAIL:  The database was initialized with LC_COLLATE "en_US.UTF-8",  which is not recognized by setlocale().
HINT:  Recreate the database with another locale or install the missing locale.

Re: locales gone

[Ludovic Courtès]

Hi!

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> I read the docs you pointed me to - however, previously this worked fine as-is. Also, I have a database that is inaccessible because the locale suddenly (sometimes) doesn't work anymore. It's not like I can change what locale it was created in without a time machine :)
>
> $ psql -U postgres template1
> psql: FATAL:  database locale is incompatible with operating system
> DETAIL:  The database was initialized with LC_COLLATE "en_US.UTF-8",  which is not recognized by setlocale().
> HINT:  Recreate the database with another locale or install the missing locale.

What does this return:

  ldd $(which psql) | grep glibc

?

If it says 2.22, then you need to add the 2.22 locale data to your OS,
as per
<https://www.gnu.org/software/guix/manual/html_node/Locales.html#Locale-Data-Compatibility-Considerations>.

HTH,
Ludo’.

Re: locales gone

[Danny Milosavljevic]

On Thu, 13 Oct 2016 22:22:47 +0200
ludo@gnu.org (Ludovic Courtès) wrote:

>   ldd $(which psql) | grep glibc

$ ldd $(which psql) |grep glibc
        libm.so.6 => /gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/libm.so.6 (0x00007fc4b8c49000)
        libc.so.6 => /gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/libc.so.6 (0x00007fc4b8691000)
        libpthread.so.0 => /gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/libpthread.so.0 (0x00007fc4b8474000)
        /gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/ld-linux-x86-64.so.2 (0x00007fc4b93be000)

Re: locales gone

[Ludovic Courtès]

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> On Thu, 13 Oct 2016 22:22:47 +0200
> ludo@gnu.org (Ludovic Courtès) wrote:
>
>>   ldd $(which psql) | grep glibc
>
> $ ldd $(which psql) |grep glibc
>         libm.so.6 => /gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/libm.so.6 (0x00007fc4b8c49000)
>         libc.so.6 => /gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/libc.so.6 (0x00007fc4b8691000)
>         libpthread.so.0 => /gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/libpthread.so.0 (0x00007fc4b8474000)
>         /gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/ld-linux-x86-64.so.2 (0x00007fc4b93be000)

Then you’d have to strace psql to see why it thinks that en_US.UTF-8 is
unavailable.

Ludo’.

Re: locales gone

[Danny Milosavljevic]

Hi,

On Fri, 14 Oct 2016 12:59:10 +0200
ludo@gnu.org (Ludovic Courtès) wrote:
> Then you’d have to strace psql to see why it thinks that en_US.UTF-8 is
> unavailable.

connect(3, {sa_family=AF_FILE, sun_path="/tmp/.s.PGSQL.5432"}, 110) = 0
getsockopt(3, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
getsockname(3, {sa_family=AF_FILE, NULL}, [2]) = 0
poll([{fd=3, events=POLLOUT|POLLERR}], 1, 4294967295) = 1 ([{fd=3, revents=POLLOUT}])
sendto(3, "\0\0\0U\0\3\0\0user\0postgres\0database\0template1\0application_name\0psql\0client_encoding\0UTF8\0\0", 85, MSG_NOSIGNAL, NULL, 0) = 85
poll([{fd=3, events=POLLIN|POLLERR}], 1, 4294967295) = 1 ([{fd=3, revents=POLLIN}])
recvfrom(3, "R\0\0\0\10\0\0\0\0E\0\0\1\34SFATAL\0CXX000\0Mdatabase locale is incompatible with operating system\0DThe database was initialized with LC_COLLATE \"en_US.UTF-8\",  which is not recognized by setlocale().\0HRecreate the database with another locale or install the missing locale.\0Fpostinit.c\0L368\0RCheckMyDatabase\0\0", 16384, 0, NULL, NULL) = 294
write(2, "psql: FATAL:  database locale is incompatible with operating system\nDETAIL:  The database was initialized with LC_COLLATE \"en_US.UTF-8\",  which is not recognized by setlocale().\nHINT:  Recreate the database with another locale or install the missing locale.\n", 258psql: FATAL:  database locale is incompatible with operating system
DETAIL:  The database was initialized with LC_COLLATE "en_US.UTF-8",  which is not recognized by setlocale().
HINT:  Recreate the database with another locale or install the missing locale.
) = 258
close(3)                                = 0
exit_group(2)                           = ?

So it seems the message comes from the server.

Re: locales gone

[Danny Milosavljevic]

And if I strace postgres service I get

[pid  6184] open("/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid  6184] open("/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
[pid  6184] fstat(3, {st_mode=S_IFREG|0444, st_size=2997, ...}) = 0
[pid  6184] read(3, "# Locale name alias data base.\n#"..., 4096) = 2997
[pid  6184] read(3, "", 4096)           = 0
[pid  6184] close(3)                    = 0
[pid  6184] open("/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/locale/en_US.UTF-8/LC_COLLATE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid  6184] open("/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/locale/en_US.utf8/LC_COLLATE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid  6184] open("/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/locale/en_US/LC_COLLATE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid  6184] open("/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/locale/en.UTF-8/LC_COLLATE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid  6184] open("/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/locale/en.utf8/LC_COLLATE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid  6184] open("/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/locale/en/LC_COLLATE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

And indeed those don't exist.

/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23 does exist. There's a share/locale in there but no lib/locale .

Re: locales gone

[Danny Milosavljevic]

And the postgres service has these environment variables:

HOME=/
TERM=linux
BOOT_IMAGE=/gnu/store/1w33nqlw4il84i4xr3pif45insmz82ln-linux-libre-4.7.2/bzImage
--root=dayas:/
--system=/gnu/store/v4za34zybd8743cvxyx9j73w492c7nca-system
--load=/gnu/store/v4za34zybd8743cvxyx9j73w492c7nca-system/boot
crashkernel=256M
root_trim=yes
PATH=/gnu/store/qfqdkv99yhjqlza4sz198vzx03pnsg8i-shadow-4.2.1/sbin

No locale stuff...

Also, crashkernel=256M and root_trim come from my (kernel-arguments '("crashkernel=256M" "modprobe.blacklist=pcspkr,snd_pcsp" "quiet" "acpi_osi=Linux" "clocksource=acpi_pm" "allow-discards" "root_trim=yes"))

Re: locales gone

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 2209 bytes --]

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> And if I strace postgres service I get
>
> [pid  6184] open("/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> [pid  6184] open("/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
> [pid  6184] fstat(3, {st_mode=S_IFREG|0444, st_size=2997, ...}) = 0
> [pid  6184] read(3, "# Locale name alias data base.\n#"..., 4096) = 2997
> [pid  6184] read(3, "", 4096)           = 0
> [pid  6184] close(3)                    = 0
> [pid  6184] open("/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/locale/en_US.UTF-8/LC_COLLATE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> [pid  6184] open("/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/locale/en_US.utf8/LC_COLLATE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> [pid  6184] open("/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/locale/en_US/LC_COLLATE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> [pid  6184] open("/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/locale/en.UTF-8/LC_COLLATE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> [pid  6184] open("/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/locale/en.utf8/LC_COLLATE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> [pid  6184] open("/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/locale/en/LC_COLLATE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
>
> And indeed those don't exist.

Ooh, I see.  To work around an issue in our glibc 2.23 package (that I
forgot to fix in 2.24), whereby glibc does not look for locale data in
/run/current-system/locale, commit
ab3a64507a792e4da0527b423fbc28f8768e736a sets GUIX_LOCPATH in
/etc/environment.

However, that doesn’t help with daemons, because those do not honor that
file.

I suppose the untested patch below would work around it.  Could you try
and report back?  (Will require a reboot or testing with ‘guix system
vm’.)

Thanks,
Ludo’.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 707 bytes --]

diff --git a/gnu/services/shepherd.scm b/gnu/services/shepherd.scm
index 3273184..4dbf7e3 100644
--- a/gnu/services/shepherd.scm
+++ b/gnu/services/shepherd.scm
@@ -81,6 +81,11 @@
                     (false-if-exception (close-fdes fd))
                     (loop (+ 1 fd))))
 
+                ;; Our glibc package currently looks for locale data in
+                ;; PREFIX/lib/locale instead of /run/current-system/locale.
+                ;; Work around it.
+                (setenv "GUIX_LOCPATH" "/run/current-system/locale")
+
                 ;; Start shepherd.
                 (execl (string-append #$shepherd "/bin/shepherd")
                        "shepherd" "--config" #$shepherd-conf)))))

Re: locales gone

[Leo Famulari]

On Mon, Oct 17, 2016 at 11:00:25AM +0200, Ludovic Courtès wrote:
> Danny Milosavljevic <dannym@scratchpost.org> skribis:
> 
> > And if I strace postgres service I get
> >
> > [pid  6184] open("/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> > [pid  6184] open("/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
> > [pid  6184] fstat(3, {st_mode=S_IFREG|0444, st_size=2997, ...}) = 0
> > [pid  6184] read(3, "# Locale name alias data base.\n#"..., 4096) = 2997
> > [pid  6184] read(3, "", 4096)           = 0
> > [pid  6184] close(3)                    = 0
> > [pid  6184] open("/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/locale/en_US.UTF-8/LC_COLLATE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> > [pid  6184] open("/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/locale/en_US.utf8/LC_COLLATE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> > [pid  6184] open("/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/locale/en_US/LC_COLLATE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> > [pid  6184] open("/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/locale/en.UTF-8/LC_COLLATE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> > [pid  6184] open("/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/locale/en.utf8/LC_COLLATE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> > [pid  6184] open("/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/locale/en/LC_COLLATE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> >
> > And indeed those don't exist.
> 
> Ooh, I see.  To work around an issue in our glibc 2.23 package (that I
> forgot to fix in 2.24), whereby glibc does not look for locale data in
> /run/current-system/locale, commit
> ab3a64507a792e4da0527b423fbc28f8768e736a sets GUIX_LOCPATH in
> /etc/environment.

Did commit 9f58fe3d1c not fix that issue?

Re: locales gone

[Ludovic Courtès]

Leo Famulari <leo@famulari.name> skribis:

> On Mon, Oct 17, 2016 at 11:00:25AM +0200, Ludovic Courtès wrote:
>> Danny Milosavljevic <dannym@scratchpost.org> skribis:
>> 
>> > And if I strace postgres service I get
>> >
>> > [pid  6184] open("/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
>> > [pid  6184] open("/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
>> > [pid  6184] fstat(3, {st_mode=S_IFREG|0444, st_size=2997, ...}) = 0
>> > [pid  6184] read(3, "# Locale name alias data base.\n#"..., 4096) = 2997
>> > [pid  6184] read(3, "", 4096)           = 0
>> > [pid  6184] close(3)                    = 0
>> > [pid  6184] open("/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/locale/en_US.UTF-8/LC_COLLATE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
>> > [pid  6184] open("/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/locale/en_US.utf8/LC_COLLATE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
>> > [pid  6184] open("/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/locale/en_US/LC_COLLATE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
>> > [pid  6184] open("/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/locale/en.UTF-8/LC_COLLATE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
>> > [pid  6184] open("/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/locale/en.utf8/LC_COLLATE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
>> > [pid  6184] open("/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/locale/en/LC_COLLATE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
>> >
>> > And indeed those don't exist.
>> 
>> Ooh, I see.  To work around an issue in our glibc 2.23 package (that I
>> forgot to fix in 2.24), whereby glibc does not look for locale data in
>> /run/current-system/locale, commit
>> ab3a64507a792e4da0527b423fbc28f8768e736a sets GUIX_LOCPATH in
>> /etc/environment.
>
> Did commit 9f58fe3d1c not fix that issue?

Oh you’re right, it’s fixed in ‘core-updates’:

--8<---------------cut here---------------start------------->8---
$ ./pre-inst-env guix build -e '(@@ (gnu packages commencement) glibc-final)'

[...]

/gnu/store/1qpfjj4rk11wm6ix098hqbai9wrwb24c-glibc-2.24-debug
/gnu/store/iwgi9001dmmihrjg4rqhd6pa6788prjw-glibc-2.24
$ strings /gnu/store/iwgi9001dmmihrjg4rqhd6pa6788prjw-glibc-2.24/lib/libc.so.6 | grep /run/current-system
/run/current-system/locale/2.24
/run/current-system/locale/2.24/locale-archive
--8<---------------cut here---------------end--------------->8---

For current master the patch might still be helpful.

Thanks Leo!

Ludo’.

Re: locales gone

[Danny Milosavljevic]

Hi Ludo,

On Mon, 17 Oct 2016 11:00:25 +0200
ludo@gnu.org (Ludovic Courtès) wrote:
> I suppose the untested patch below would work around it.  Could you try
> and report back?  (Will require a reboot or testing with ‘guix system
> vm’.)

First I tried whether it's still broken with current (~5 min ago) Guix master: yes, it is.

Then I applied the patch on my physical computer (not VM), reconfigured and rebooted. It works now. Thanks :)