Just want to confirm I'm doing your workaround properly... like this? $ ln -s gnu/store/...-glibc-utf8-locales-2.22/lib/locale /run/current-system/locale $ echo $LOCPATH
The previous line is blank, showing that $LOCPATH is unset. On Tue, Sep 29, 2015, at 10:32, Mark H Weaver wrote: > Federico Beffa <be...@ieee.org> writes: > > > l...@gnu.org (Ludovic Courtès) writes: > > > > [...] > > > >> Consequences for Guix on foreign distros: > >> > >> • If the host distro provides binaries that use libc < 2.22 and you > >> use a mixture of Guix-provided and distro-provided programs, this is > >> pretty bad. > >> > >> Solution: unset LOCPATH and say goodbye to locales for Guix-provided > >> packages (setting LOCPATH=$HOME/.guix-profile/lib/locale would break > >> all the distro-provided programs), or use exclusively Guix-provided > >> programs, or use the “C” locale. > > > > Does this means that Guix on other distributions is no longer of > > interest to the Guix project and it is essentially unsupported? > > > > Or is this a transitory situation and an acceptable solution is being > > worked on? > > I think I know a workaround: leave LOCPATH unset, and make > /run/current-system/locale a symlink to freshly generated locales for > glibc 2.22. Guix-compiled software is configured to look for locales > there if LOCPATH is unset. > > Mark >
