[PATCH] Allow choosing the nl_NL.UTF-8 locale.

It's 100% translated according to . Warning: I don't have a Guix Data Service to test this with. * guix-data-service/model/package-metadata.scm (locales): Add nl_NL.utf-8 --- guix-data-service/model/package-metadata.scm | 1 + 1 file ch

Re: 01/01: gnu: evolution-data-server: Fix locale handling.

: Sun Jul 14 23:47:44 2019 -0400 >> >> gnu: evolution-data-server: Fix locale handling. >> >> * gnu/packages/gnome.scm (evolution-data-server)[arguments]: Add a phase >> that patches the source code to fix a locale handling issue. >> >> [...]

Re: 01/01: gnu: evolution-data-server: Fix locale handling.

Hi Timothy, guix-comm...@gnu.org writes: > samplet pushed a commit to branch core-updates > in repository guix. > > commit d619686250d8bb15bf67031f8ac80f9cfb400a26 > Author: Timothy Sample > Date: Sun Jul 14 23:47:44 2019 -0400 > > gnu: evolution-data-ser

Re: warning: failed to install locale

do it need to be fixed? AFAIU adding "export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale" to root's .profile or .bash_profile is not strictly needed (unless you want to install and run packages as root user), so I'd _not_ automate this via the binary install script or document this

Re: Locale error (Was: Re: New detailed troubleshooting section in the manual)

gnu/store/izyw1295kw5d47m4kv5d9ns4c1l7lz8k-profile/lib/locale > This is the cause of you seeing the message. > > I suggest you either try fixing this yourself by moving your variables to > .bash_profile or ask on an ubuntu forum or search the net for an answer how > to make ubuntu source your varia

Re: Locale error (Was: Re: New detailed troubleshooting section in the manual)

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.

Re: [PATCH 2/2] services: postgresql: Add locale to configuration

Christopher Baines skribis: > * gnu/services/databases.scm (): Add locale > field. > (postgresql-shepherd-service): Pass locale to initdb. > (postgresql-service): Add locale default. Applied, thanks! :-) Ludo’.

[PATCH 2/2] services: postgresql: Add locale to configuration

* gnu/services/databases.scm (): Add locale field. (postgresql-shepherd-service): Pass locale to initdb. (postgresql-service): Add locale default. --- doc/guix.texi | 8 gnu/services/databases.scm | 22 ++ 2 files changed, 22 insertions(+), 8

Re: [PATCH 2/2] services: postgresql: Add locale to configuration

Christopher Baines skribis: > On 11/12/16 23:14, Ludovic Courtès wrote: >> Hi! >> >> Christopher Baines skribis: >> >>> * gnu/services/postgresql.scm (): Add locale >>> field. >>> (postgresql-shepherd-service): Pass locale to

Re: [PATCH 2/2] services: postgresql: Add locale to configuration

On 11/12/16 23:14, Ludovic Courtès wrote: Hi! Christopher Baines skribis: * gnu/services/postgresql.scm (): Add locale field. (postgresql-shepherd-service): Pass locale to initdb. (postgresql-service): Add locale default. [...] + (locale postgresql-configuration-locale

Re: [PATCH 2/2] services: postgresql: Add locale to configuration

Hi! Christopher Baines skribis: > * gnu/services/postgresql.scm (): Add locale > field. > (postgresql-shepherd-service): Pass locale to initdb. > (postgresql-service): Add locale default. [...] > + (locale postgresql-configuration-locale > + (

[PATCH 2/2] services: postgresql: Add locale to configuration

* gnu/services/postgresql.scm (): Add locale field. (postgresql-shepherd-service): Pass locale to initdb. (postgresql-service): Add locale default. --- gnu/services/databases.scm | 22 ++ 1 file changed, 18 insertions(+), 4 deletions(-) diff --git a/gnu/services

Re: HI ... warning: failed to install locale: Invalid argument -2

Hi, > $ guix package -i glibc-locales > > ... fails just as a bare guix does ... What do you mean by that? What is the exact error message you see? The warning you posted earlier is harmless, as far as I know. ~~ Ricardo

Re: HI ... warning: failed to install locale: Invalid argument -3

libc in the store. To make locales work you’d have to install the “glibc-locales” (or “glibc-utf8-locales”) package (as you tried according to your previous message) and then set GUIX_LOCPATH to tell the Guix glibc where to find the locale data. Debian’s glibc will not be affected by this. ~~ Ricardo

HI ... warning: failed to install locale: Invalid argument -2

I've read the fine manual abit ... 7.2.6.1 Locale Data Compatibility Considerations ... seems to be about what to do to avoid this happening in the first place, refers to 2.6.1 Locales which offers a solution that seems to require a working guix to fix a broken guix ... $ guix packa

HI ... warning: failed to install locale: Invalid argument

Hi, I'm installing guix on my debian jessie system and have gotten to where I ought to be able to type 'guix', I think, but I get ... jfl@wsdeb:/tmp$ guix warning: failed to install locale: Invalid argument guix: missing command name Try `guix --help' for more information

HI ... warning: failed to install locale: Invalid argument -3

Hi again, My debian jessie says ... jfl@wsdeb:~$ ldd --version ldd (Debian GLIBC 2.19-18+deb8u1) 2.19 Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PUR

Re: [PATCH] Gracefully handle incompatible locale data

On 10/27/2015 11:30 AM, Samuel Thibault wrote: > Hello, > > Ludovic Courtès, le Tue 22 Sep 2015 17:27:55 +0200, a écrit : >> loadlocale.c:130: _nl_intern_locale_data: Assertion `cnt < (sizeof >> (_nl_value_type_LC_COLLATE) / sizeof (_nl_value_type_LC_COLLATE[0]))' failed. >> >> This patch chang

Re: [PATCH] Gracefully handle incompatible locale data

On 10/13/2015 10:45 AM, Ludovic Courtès wrote: >> - What does localedef --list-archive return? >> >> - The new LC_COLLATE format will make it's way into the binary locale >> archive >> and that means glibc can't read the locale-archive? Does it fail

Re: [PATCH] Gracefully handle incompatible locale data

Samuel Thibault skribis: > Ludovic Courtès, le Tue 22 Sep 2015 17:27:55 +0200, a écrit : >> loadlocale.c:130: _nl_intern_locale_data: Assertion `cnt < (sizeof >> (_nl_value_type_LC_COLLATE) / sizeof (_nl_value_type_LC_COLLATE[0]))' failed. >> >> This patch changes such conditions to return EI

Re: [PATCH] Gracefully handle incompatible locale data

Hello, Ludovic Courtès, le Tue 22 Sep 2015 17:27:55 +0200, a écrit : > loadlocale.c:130: _nl_intern_locale_data: Assertion `cnt < (sizeof > (_nl_value_type_LC_COLLATE) / sizeof (_nl_value_type_LC_COLLATE[0]))' failed. > > This patch changes such conditions to return EINVAL instead of aborting.

Re: [PATCH 02/43] gnu: ghc-old-locale: New package for updated GHC.

On 2015-10-15 at 14:20, quoth Paul van der Walt: > +(define-public ghc-old-locale > + (package > +(name "ghc-old-locale") > +(version "1.0.0.7") > +(source > + (origin > + (method url-fetch) > + (uri (string-append > +

[PATCH 02/43] gnu: ghc-old-locale: New package for updated GHC.

* gnu/packages/haskell.scm (ghc-old-locale): New variable. * gnu/packages/haskell.scm (ghc-data-default-instances-old-locale): Update dependencies. * gnu/packages/haskell.scm (ghc-mtl): Update to version 2.2.1. * gnu/packages/haskell.scm (ghc-utf8-string): Update to version 1.0.1.1. --- gnu

Re: Locale

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’.

Re: Locale

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

Re: Locale

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

Re: [PATCH] Gracefully handle incompatible locale data

"Carlos O'Donell" skribis: > On 09/29/2015 04:08 AM, Ludovic Courtès wrote: >> "Carlos O'Donell" skribis: [...] >> Apart from that, ‘localedef --list-archive’ simply opens the locale >> archive (typically /usr/lib/locale/locale-archive,

Re: [PATCH] Gracefully handle incompatible locale data

data from libc 2.21. >> >> If you change this particular case to EINVAL, what does the user see >> as a result of this change? > > The user-visible change is that, if incompatible or broken locale data > is found, a call like: > > setlocale (LC_ALL, "&quo

Re: [PATCH] Gracefully handle incompatible locale data

ally, but for this one change you're making >> we should fix it as best we can. >> > > If I am reading this correctly, the change to from an abort to EINVAL > would be fine if it is accompanied by a change to localedef > --list-archive. Is that correct? > > A so

Re: Locale

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:)

Re: Locale

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). > > Ho

Locale

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 characters in mutt (taken from guix). Hopefully it is just a simple matter

Re: [PATCH] Gracefully handle incompatible locale data

h change is needed, but I’m waiting for confirmation or clarification: https://sourceware.org/ml/libc-alpha/2015-09/msg00727.html > A solution to this would be great given we now run into this assert with > locale archives built with different glibc builds along the 2.22 release > branch. I’m glad you value the practical benefits. ;-) Ludo’.

Re: [PATCH] Gracefully handle incompatible locale data

eading this correctly, the change to from an abort to EINVAL would be fine if it is accompanied by a change to localedef --list-archive. Is that correct? A solution to this would be great given we now run into this assert with locale archives built with different glibc builds along the 2.22 release branch. Allan

Re: [PATCH] Gracefully handle incompatible locale data

Hello! A friendly ping so the discussion does not die out. :-) https://sourceware.org/ml/libc-alpha/2015-09/threads.html#00575 https://sourceware.org/ml/libc-alpha/2015-09/msg00727.html TIA, Ludo’.

Re: [PATCH 0/2] Avoiding incompatible locale data in LOCPATH

On Mon, Oct 5, 2015 at 11:09 PM, Ludovic Courtès wrote: > Federico Beffa skribis: > >> I'm wondering if it would be better to point GUIX_LOCPATH to >> >> export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale >> >> and have 'glibc' itself to append

Re: [PATCH 0/2] Avoiding incompatible locale data in LOCPATH

Federico Beffa skribis: > I'm wondering if it would be better to point GUIX_LOCPATH to > > export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale > > and have 'glibc' itself to append it's own version number to that > string. In this way pre 2.22 programs (l

Re: [PATCH 0/2] Avoiding incompatible locale data in LOCPATH

gt;>> do: >>>> >>>> guix package -i glibc-locales >>>> export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale/2.22 >>>> >>>> Note the extra “/2.22”, which comes from commit f2d7bbb. This is a bit >>>> of an annoyance for end users

Re: [PATCH 0/2] Avoiding incompatible locale data in LOCPATH

-locales >>> export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale/2.22 >>> >>> Note the extra “/2.22”, which comes from commit f2d7bbb. This is a bit >>> of an annoyance for end users, but the point is that eventually this >>> would allow us to recomm

Re: [PATCH 0/2] Avoiding incompatible locale data in LOCPATH

Mark H Weaver skribis: > l...@gnu.org (Ludovic Courtès) writes: > >> After a lot more thought, I changed my mind. >> >> I realized that with the patch at >> <https://sourceware.org/ml/libc-alpha/2015-09/msg00575.html>, it’s OK to >> have, say, >>

Re: [PATCH 0/2] Avoiding incompatible locale data in LOCPATH

Mark H Weaver skribis: > l...@gnu.org (Ludovic Courtès) writes: > >> So with current ‘core-updates’, someone on a “foreign distro” needs to >> do: >> >> guix package -i glibc-locales >> export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale/2.22 >> &

Re: [PATCH 0/2] Avoiding incompatible locale data in LOCPATH

l...@gnu.org (Ludovic Courtès) writes: > So with current ‘core-updates’, someone on a “foreign distro” needs to > do: > > guix package -i glibc-locales > export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale/2.22 > > Note the extra “/2.22”, which comes from commit f2d7bbb.

Re: [PATCH 0/2] Avoiding incompatible locale data in LOCPATH

l...@gnu.org (Ludovic Courtès) writes: > After a lot more thought, I changed my mind. > > I realized that with the patch at > <https://sourceware.org/ml/libc-alpha/2015-09/msg00575.html>, it’s OK to > have, say, > > > LOCPATH=$HOME/.guix-profile/lib/locale/2.22:

Re: [PATCH 0/2] Avoiding incompatible locale data in LOCPATH

So with current ‘core-updates’, someone on a “foreign distro” needs to do: guix package -i glibc-locales export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale/2.22 Note the extra “/2.22”, which comes from commit f2d7bbb. This is a bit of an annoyance for end users, but the point is that

Re: [PATCH 0/2] Avoiding incompatible locale data in LOCPATH

ograms wouldn't break. >> >> The second patch was suggested by Mark. It basically adds "/2.22" to every >> directory name specified in LOCPATH, as well as to the default locale >> directory. The idea here is that libc would only stumble on compatible >> l

Re: [PATCH 0/2] Avoiding incompatible locale data in LOCPATH

tch was suggested by Mark. It basically adds "/2.22" to every > directory name specified in LOCPATH, as well as to the default locale > directory. The idea here is that libc would only stumble on compatible > locale data. > > Actually with that second patch, I think 'GU

Re: [PATCH 0/2] Avoiding incompatible locale data in LOCPATH

Daniel Pimentel skribis: > I added 'export LC_ALL="C"' in my ~.bashrc. > > I'll to do upgrade and report it. With LC_ALL=C, one sidesteps the problem. For real testing, you need to use LC_ALL=pt_BR.utf8 or something like that. Ludo’.

Re: [PATCH 0/2] Avoiding incompatible locale data in LOCPATH

On 2015-10-03 19:20, l...@gnu.org wrote: After a lot more thought, I changed my mind. I realized that with the patch at <https://sourceware.org/ml/libc-alpha/2015-09/msg00575.html>, it’s OK to have, say, LOCPATH=$HOME/.guix-profile/lib/locale/2.22:$HOME/.guix-profile/lib/locale/2.23

Re: [PATCH 0/2] Avoiding incompatible locale data in LOCPATH

After a lot more thought, I changed my mind. I realized that with the patch at <https://sourceware.org/ml/libc-alpha/2015-09/msg00575.html>, it’s OK to have, say, LOCPATH=$HOME/.guix-profile/lib/locale/2.22:$HOME/.guix-profile/lib/locale/2.23 That way, programs will pick locale data t

Re: [PATCH 0/2] Avoiding incompatible locale data in LOCPATH

abc2e35f7e05c49192 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= Date: Thu, 1 Oct 2015 21:32:50 +0200 Subject: [PATCH] gnu: glibc: Look for locale data in versioned sub-directories. * gnu/packages/patches/glibc-versioned-locpath.patch: New file. * gnu-system.am (dist_patch_DA

Re: [PATCH 0/2] Avoiding incompatible locale data in LOCPATH

Ludovic Courtès writes: > So, below are a couple of patches implementing ideas that were discussed here > and on IRC to improve the locale mess. > > The first patch adds the 'GUIX_LOCPATH' environment variable, the idea being > that on foreign distros, users could set

[PATCH 0/2] Avoiding incompatible locale data in LOCPATH

So, below are a couple of patches implementing ideas that were discussed here and on IRC to improve the locale mess. The first patch adds the 'GUIX_LOCPATH' environment variable, the idea being that on foreign distros, users could set this variable instead of 'LOCPATH', a

[PATCH 2/2] gnu: glibc: Look for locale data in versioned sub-directories.

;glibc-guix-locpath.patch" +"glibc-versioned-locpath.patch" "glibc-o-largefile.patch") (build-system gnu-build-system) @@ -510,16 +511,12 @@ store.") ;; Set the default locale path. In pra

Re: Preparing for the libc/locale upgrade

Leo Famulari writes: > 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. I thi

Re: Preparing for the libc/locale upgrade

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: >

Re: Preparing for the libc/locale upgrade

On 30/09/2015 14:35, Federico Beffa wrote: From my point of view Mark's suggestion sounds as the most acceptable (although I've not tested it as I've not updated my Guix yet). I just tested it, it works fine. And, finally, no more error messages about missing locales anywhere! Konrad.

Re: Preparing for the libc/locale upgrade

some reason I don't see Mark's message on the ML. So instead of a link, a copy/paste from his email: " 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 con

Re: Preparing for the libc/locale upgrade

Federico Beffa skribis: > On Mon, Sep 28, 2015 at 10:45 PM, Ludovic Courtès wrote: [...] > From my point of view Mark's suggestion sounds as the most acceptable Which one is it? >> IMO Guix is not at fault; rather, it sheds light on a shortcoming of >> libc’s handlin

Re: Preparing for the libc/locale upgrade

hat 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-p

Re: Preparing for the libc/locale upgrade

hat 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-p

Re: Preparing for the libc/locale upgrade

ded 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 >

Re: [PATCH] Gracefully handle incompatible locale data

INVAL, what does the user see > as a result of this change? The user-visible change is that, if incompatible or broken locale data is found, a call like: setlocale (LC_ALL, ""); returns EINVAL instead of aborting. > Do they get a non-zero exit code from `localedef --list-

Re: [PATCH] Gracefully handle incompatible locale data

On 09/26/2015 06:24 AM, Ludovic Courtès wrote: > Furthermore, the function in question returns EINVAL in other similar > cases–e.g., when libc 2.22 loads LC_COLLATE data from libc 2.21. If you change this particular case to EINVAL, what does the user see as a result of this change? Do they get a n

Re: Preparing for the libc/locale upgrade

ded 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 >

Preparing for the libc/locale upgrade

n: 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 distr

Re: [PATCH] Gracefully handle incompatible locale data

the patch would be a violation of these rules. WDYT? > It is a fundamental system misconfiguration issue not to have upgraded > the binary locale data from one release to another. I would not call it “misconfiguration.” With GNU Guix, unprivileged users can install packages in their “profi

Re: [PATCH] Gracefully handle incompatible locale data

On 09/24/2015 12:12 PM, Ludovic Courtès wrote: > Ondřej, I think we have been miscommunicating. > > I noticed that a program linked against 2.21 or earlier would abort with > an assertion failure when it stumbles upon 2.22 locale data. > > All the patch tries to do is change t

Re: [PATCH] Gracefully handle incompatible locale data

Mark H Weaver skribis: > [Removed libc-alpha from the CC list] > > l...@gnu.org (Ludovic Courtès) writes: > >> With libc 2.22 people are starting to realize that libc does not >> guarantee that it can load locale data built with another libc version, >>

Preparing for the libc/locale upgrade

Problem: Programs linked against libc < 2.22 abort when trying to load libc 2.22-or-later locale data: https://lists.gnu.org/archive/html/guix-devel/2015-08/msg00737.html Programs linked against libc 2.22 do not abort when trying to load 2.21 locale data, but they fail to load data for

Re: [PATCH] Gracefully handle incompatible locale data

Ondřej, I think we have been miscommunicating. I noticed that a program linked against 2.21 or earlier would abort with an assertion failure when it stumbles upon 2.22 locale data. All the patch tries to do is change the abort to EINVAL (and skip locale data) when that happens. I’m not claiming

Re: [PATCH] Gracefully handle incompatible locale data

urtès wrote: > >> >> With libc 2.22 people are starting to realize that libc does not > >> >> guarantee that it can load locale data built with another libc version, > >> >> but they learn it the hard way: > >> >> > >> >&g

Re: [PATCH] Gracefully handle incompatible locale data

[Removed libc-alpha from the CC list] l...@gnu.org (Ludovic Courtès) writes: > With libc 2.22 people are starting to realize that libc does not > guarantee that it can load locale data built with another libc version, > but they learn it the hard way: > > l

Re: [PATCH] Gracefully handle incompatible locale data

not >> >> guarantee that it can load locale data built with another libc version, >> >> but they learn it the hard way: >> >> >> >> loadlocale.c:130: _nl_intern_locale_data: Assertion `cnt < (sizeof >> >> (_nl_value_type_LC_COL

Re: [PATCH] Gracefully handle incompatible locale data

Andreas Schwab writes: > What about the other assertion? Ignore that. This one is a real internal consistency check. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."

Re: [PATCH] Gracefully handle incompatible locale data

l...@gnu.org (Ludovic Courtès) writes: > diff --git a/locale/loadlocale.c b/locale/loadlocale.c > index fdba6e9..e04e720 100644 > --- a/locale/loadlocale.c > +++ b/locale/loadlocale.c > @@ -122,8 +122,9 @@ _nl_intern_locale_data (int category, const void *data, &g

Re: [PATCH] Gracefully handle incompatible locale data

On Tue, Sep 22, 2015 at 11:22:40PM +0200, Ludovic Courtès wrote: > Ondřej Bílka skribis: > > > On Tue, Sep 22, 2015 at 05:27:55PM +0200, Ludovic Courtès wrote: > >> With libc 2.22 people are starting to realize that libc does not > >> guarantee that it can load

Re: [PATCH] Gracefully handle incompatible locale data

Ondřej Bílka skribis: > On Tue, Sep 22, 2015 at 05:27:55PM +0200, Ludovic Courtès wrote: >> With libc 2.22 people are starting to realize that libc does not >> guarantee that it can load locale data built with another libc version, >> but they learn it the hard way: >

Re: [PATCH] Gracefully handle incompatible locale data

On Tue, Sep 22, 2015 at 05:27:55PM +0200, Ludovic Courtès wrote: > With libc 2.22 people are starting to realize that libc does not > guarantee that it can load locale data built with another libc version, > but they learn it the hard way: > > loadlocale.c:130: _nl_intern_locale_

Re: [PATCH] Gracefully handle incompatible locale data

Looks OK to me.

[PATCH] Gracefully handle incompatible locale data

With libc 2.22 people are starting to realize that libc does not guarantee that it can load locale data built with another libc version, but they learn it the hard way: loadlocale.c:130: _nl_intern_locale_data: Assertion `cnt < (sizeof (_nl_value_type_LC_COLLATE) / siz

[PATCH 04/13] gnu: Add ghc-data-default-instances-old-locale.

* gnu/packages/haskell.scm (ghc-data-default-instances-old-locale): New variable. --- gnu/packages/haskell.scm | 23 +++ 1 file changed, 23 insertions(+) diff --git a/gnu/packages/haskell.scm b/gnu/packages/haskell.scm index e6bc25e..8c05c47 100644 --- a/gnu/packages

Re: warning: failed to install locale: Invalid argument

"Cook, Malcolm" skribis: >> "Cook, Malcolm" skribis: >> >> > With each call to guix I get >> > >> >warning: failed to install locale: Invalid argument >> >> See >> <http://www.gnu.org/software/guix/manual

Re: warning: failed to install locale: Invalid argument

This works for me: https://github.com/pjotrp/guix-notes/blob/master/INSTALL.org#set-locale On Fri, Jul 24, 2015 at 09:01:15PM +, Cook, Malcolm wrote: > > "Cook, Malcolm" skribis: > > > > > With each call to guix I get > > > > > > wa

RE: warning: failed to install locale: Invalid argument

> "Cook, Malcolm" skribis: > > > With each call to guix I get > > > > warning: failed to install locale: Invalid argument > > See > <http://www.gnu.org/software/guix/manual/html_node/Application- > Setup.html#Locales-1>. Thanks Ludo, I sh

Re: warning: failed to install locale: Invalid argument

"Cook, Malcolm" skribis: > With each call to guix I get > > warning: failed to install locale: Invalid argument See <http://www.gnu.org/software/guix/manual/html_node/Application-Setup.html#Locales-1>. I’ve added a cross-ref to that section from “Binary Installation”. Ludo’.

warning: failed to install locale: Invalid argument

With each call to guix I get warning: failed to install locale: Invalid argument I am using fresh binary install of 0.8.3 into clean CentOS7 following http://www.gnu.org/software/guix/manual/html_node/Binary-Installation.html Can anyone provide guidance on how to proceed on this? Thx

Re: Locale of build environments

106:20: In procedure #: ice-9/boot-9.scm:106:20: Throw to key `encoding-error' with args `("scm_to_stringn" "cannot convert narrow string to output locale" 84 #f #f)'. --8<---cut here---end--->8--- The failure here occurs when

Re: Locale of build environments

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. >

Re: Locale of build environments

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 st

Re: Locale of build environments

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 p

Re: Locale of build environments

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. &g

Re: Locale of build environments

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

Locale of build environments

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 locale for all builds by