bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#67044: C.utf8 locale cannot be built


From: Tomas Volf
Subject: bug#67044: C.utf8 locale cannot be built
Date: Tue, 28 Nov 2023 02:22:26 +0100

On 2023-11-27 23:02:26 +0100, Ludovic Courtès wrote:
> Hi Tomas!

Hi! :)

> 
> Tomas Volf <~@wolfsden.cz> skribis:
> 
> > when trying to build a system with C.utf8 locale, I end up with the 
> > following
> > error:
> >
> >     building /gnu/store/v6jma6kmwywr509n4y0vypchnh4y5s3m-locale-2.35.drv...
> >     building locale 'C.utf8'...
> >     [error] LC_MONETARY: value for field `mon_decimal_point' must not be an 
> > empty string
> >     [error] no output file produced because errors were issued
> 
> [...]
> 
> > This seems to be a known problem in 2.35,
> > https://sourceware.org/bugzilla/show_bug.cgi?id=28861 .  On the page there 
> > is
> > also a workaround, and that is to compile with the locales with -c.
> >
> > So that would be one solution until we update to 2.36 or higher.  I do not 
> > see a
> > way to override this (add the -c) from the operating-system definition.
> 
> We could/should fix this in (gnu system locale).

That is currently not possible I am afraid, since %default-locale-definitions is
global, not per-version, and glibc-2.33 is installed by default.

> 
> Now, it would also be nice if C.utf8 were built-in, shipped with the
> ‘glibc’ package we have (to me that’s the whole point of C.utf8).  We
> should fix that now in ‘core-updates’.  Ideas on how to do that?

After short research, I do have an idea.  My knowledge of Guix's internals is
not good enough (yet? :)) to implement it though.  And I am not even sure it
should be done.  Anyway here it goes:

1. Add a phase after 'install that builds and installs the C.utf8 locale, as
documented here[0].
2. Make glibc package add the directory into GUIX_LOCPATH.  Since it accepts :
separated directories, it should be possible, however I am unsure how.

I think that should do it.  However, I am not sure what the benefit would be.
The base locale is C, anything else (like C.utf8) is extra, and user needs to
modify LANG to get it working anyway.  So installing it via the glibc-locales
seems fine enough.

In my opinion, the correct long-term approach here is to just add C.utf8 into
%default-locale-definitions.  That however cannot be done until glibc-2.33 is
dropped from %default-locale-libcs.

For the time being however, using C.utf8 is solvable[1] from the
operating-system definition, with the exception of compiling the locale.  About
which is this issue and the fix is trivial[2].

I am not sure this issue is worth overthinking it.

0: https://www.gnu.org/software/libc/manual/html_node/Running-make-install.html
1: https://emacs.ch/@graywolf/111404592336140803
2: 
https://git.sr.ht/~graywolf/guix/commit/1e94b59a7b27d44435f321083a01242bdf16c566



Let me know what you think :)

Tomas

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]