> According to this your ~.profile was not sourced when you logged in
> (GUIX_LOCPATH is not defined in your environment)
>
My mistake, I went back to a previous snapshot and installed inside guix
environment, there I exported the GUIX_LOCPATH running env:
GUIX_LOCPATH=/gnu/store/izyw1295kw5d47m4k
Hi
On 2018-11-04 18:54, Laura Lazzati wrote:
Did your export
export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale" from somewhere?
I tried to solve it when i first installed guix, but then did not mind
anymore.
Could you send me the output of your environment?
paste.debian.net/
Andreas Enge skribis:
> Would it make sense to declare a search path with respect to GUIX_LOCPATH
> then?
It’s done, but it’s in libc, so you don’t see it unless you install
‘glibc’ in your profile.
Ludo’.
Hi Ricardo,
On Tue, Oct 13, 2015 at 01:55:38PM +0200, Ricardo Wurmus wrote:
> When using Guix on top of another distribution you should only set
> GUIX_LOCPATH to make sure that only Guix programmes use the locales in
> your profile. All other applications (those of the host system) will
> contin
On Tue, 13 Oct 2015 13:38:42 +0200
Andreas Enge wrote:
> Hello,
>
> although I am afraid to raise allergic reactions, I must say that locales
> do not seem to work any more on my guix on debian setting since the last
> upgrade... Although I chose a utf8 locale, I am not seeing special
> characte
My GuixSD returned to work with locale default (setted in
/etc/config.scm: (locale "en_US.UTF-8")) after upgrade.
Before I added in my .bashrc: LC_ALL=C to fix it. But it ins't required
to me.
Locale work now to me.
--
Daniel Pimentel (d4n1 3:)
Hi Andreas,
> although I am afraid to raise allergic reactions, I must say that locales
> do not seem to work any more on my guix on debian setting since the last
> upgrade... Although I chose a utf8 locale, I am not seeing special characters
> in mutt (taken from guix).
>
> Hopefully it is just a
l...@gnu.org (Ludovic Courtès) skribis:
> Besides, commit e8c9f04 is interesting: ‘substitute*’ will now break
> non-UTF-8 files by defaults (replacing invalid UTF-8 sequences with
> question marks in the output.)
Based on that observation, commit dd0a8ef forced the ‘patch-*’
procedures to treat
l...@gnu.org (Ludovic Courtès) skribis:
> Mark H Weaver skribis:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>
>>> Commit 5335c56 adds an ‘install-locale’ phase to gnu-build-system and
>>> the next one adds glibc-utf8-locale to the implicit inputs.
>>>
>>> During bootstrap, locales aren’t availa
Mark H Weaver skribis:
> l...@gnu.org (Ludovic Courtès) writes:
>
>> Commit 5335c56 adds an ‘install-locale’ phase to gnu-build-system and
>> the next one adds glibc-utf8-locale to the implicit inputs.
>>
>> During bootstrap, locales aren’t available so we’re still running on the
>> C locale, whi
l...@gnu.org (Ludovic Courtès) writes:
> Commit 5335c56 adds an ‘install-locale’ phase to gnu-build-system and
> the next one adds glibc-utf8-locale to the implicit inputs.
>
> During bootstrap, locales aren’t available so we’re still running on the
> C locale, which is fine in practice because we
l...@gnu.org (Ludovic Courtès) writes:
> Mark H Weaver skribis:
>
>> Guile converts POSIX byte strings (e.g. file names) to strings using to
>> the current locale encoding, but the default locale in our build
>> environment is "C" which means ASCII-only.
>>
>> I would advocate using a UTF-8 local
On Thu, Feb 12, 2015 at 09:20:04PM +0100, Ludovic Courtès wrote:
> For the non-bootstrap environment, we could make a ‘glibc-utf8-locale’
> that would only include ‘en_US.UTF-8’ (or a few more, but which one?)
> and add it to the implicit inputs of ‘gnu-build-system’.
>From what I can see, any one
13 matches
Mail list logo
