C.utf8 locale cannot be built

  • Open
  • quality assurance status badge
Details
2 participants
  • Ludovic Courtès
  • Tomas Volf
Owner
unassigned
Submitted by
Tomas Volf
Severity
normal
T
T
Tomas Volf wrote on 10 Nov 2023 15:42
(address . bug-guix@gnu.org)
ZU5Bcz1vIcoH1COM@ws
Hi,

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
Backtrace:
2 (primitive-load "/gnu/store/ccv2qfrqxk166ysg6anrzj1kz4h?")
In ice-9/boot-9.scm:
285:13 1 (for-each #<procedure 7fffeef5c540 at ice-9/eval.scm:3?> ?)
In guix/build/utils.scm:
812:6 0 (invoke "localedef" "--no-archive" "--prefix" "/gnu/st?" ?)
guix/build/utils.scm:812:6: In procedure invoke:
ERROR:
1. &invoke-error:
program: "localedef"
arguments: ("--no-archive" "--prefix" "/gnu/store/08rlginv27b9v1ba4n94plp7lmxjihja-locale-2.35/2.35" "-i" "C" "-f" "UTF-8" "/gnu/store/08rlginv27b9v1ba4n94plp7lmxjihja-locale-2.35/2.35/C.utf8")
exit-status: 4
term-signal: #f
stop-signal: #f
builder for `/gnu/store/v6jma6kmwywr509n4y0vypchnh4y5s3m-locale-2.35.drv' failed with exit code 1
build of /gnu/store/v6jma6kmwywr509n4y0vypchnh4y5s3m-locale-2.35.drv failed
View build log at '/var/log/guix/drvs/v6/jma6kmwywr509n4y0vypchnh4y5s3m-locale-2.35.drv.gz'.
cannot build derivation `/gnu/store/g47g7zqs5la6qpfmn6q1zgbhp291l1ha-system.drv': 1 dependencies couldn't be built
guix system: error: build of `/gnu/store/g47g7zqs5la6qpfmn6q1zgbhp291l1ha-system.drv' failed

This seems to be a known problem in 2.35,
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.

Tomas Volf

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

iQIzBAEBCgAdFiEEt4NJs4wUfTYpiGikL7/ufbZ/wakFAmVOQXMACgkQL7/ufbZ/
wanOIxAAsQ4oVlXZstZeu8QpLGguMOd/11y+1DKoiuVx1LJLaHQzMHnA9QRLb3vV
DFIGNBWO0d/BDgc1Wss6Qj1dbhHUUwWk8MmBLJtpfe4mRoz6ZIdpT5stpZgpMlty
NuMEUgPDXz3lkKUkoH2YxKMwrq149+atGwHrAJONi9qVCDF8iy1d3ByZNVWfjmAK
xtB3AHPNWjZI9NXD3KY+DfjZw1J1EM+CGIj3TnZXDWyPP9WRdH9fvzTD9hUx+TG8
M8N0jcEfGgtuARvq8R4LVywNV7gnDwHpn3P7YaM+iFlNG9AmPqdXGaIi1YGzrGqp
CkZlYLHTiXzzIQitDyffoRx022DToavLx4GKWIRy5ZOVgSb72+GUX921MEQPeYse
KNzPByeqS8wjZCuhDrKs/Wm+s0Bguvb1zVxVJJrXhc12lXgDQDrD6KSYTSmKW8n6
AeQZ5Pnen+4zspF5WUV4Qpte5WdVCDL4Q+n0BVTWjfQWawwgzWCOqcxP186Tw1ri
xkz3mx1zOasyeZ4tU6oZPiY5LejLrQpwJV7n/2RN5F60meILixgTGErNuYF1UYUD
+cZd+Se4gi7wCJFs0+QOAPpUKDydLHVv74HYsCjzpsRP5TpSyziDtilbyOJ9xuVC
nGwoZMCSubjPvAlQBkgSqL6qgXWIUSKyHGyiB3lpGqcSaPer1wU=
=g/4a
-----END PGP SIGNATURE-----


L
L
Ludovic Courtès wrote on 27 Nov 2023 23:02
(name . Tomas Volf)(address . ~@wolfsden.cz)(address . 67044@debbugs.gnu.org)
87bkbex3bh.fsf@gnu.org
Hi Tomas!

Tomas Volf <~@wolfsden.cz> skribis:

Toggle quote (8 lines)
> 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

[...]

Toggle quote (7 lines)
> 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).

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?

Thanks,
Ludo’.
T
T
Tomas Volf wrote on 28 Nov 2023 02:22
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 67044@debbugs.gnu.org)
ZWVA0iZhNXLZpfLV@ws
On 2023-11-27 23:02:26 +0100, Ludovic Courtès wrote:
Toggle quote (2 lines)
> Hi Tomas!

Hi! :)

Toggle quote (22 lines)
>
> 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.

Toggle quote (5 lines)
>
> 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.




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.
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEt4NJs4wUfTYpiGikL7/ufbZ/wakFAmVlQNIACgkQL7/ufbZ/
wan0AQ/+OHiwyDN13D0zAWS2o0MkFfs3bxt3ayWWNZE4QSvlWoYXnIlZnB56qREq
JKbfEc3ujuFZRrwIwhJ3cDQR3yr2edoIAZVv2VLPAR1BjUbeVe5Wm0MJxDvlSLr6
dNQqJEL8NIHMN2COWzQbyxPHP5eREDFgAW5JdB3UXiVVI4LRYwogD92kZO0x6Uj3
T21Ndqu7B1qOHWAOXdnwOqqvjUFoHxR/WF94PNs89CDKHdcR5vM9GJ2QM1y6CjXb
+S6PPO/v6O1x+rCMo+BbLHTiSitObwVhY5fQ9iVXqUcGAqKaQaqhd80vAELjzBYj
SFsxZb9JPPbabuYDrmQqVnmKbKsa7HqTbH2NzQFAU+n5ig4NytMDUuG8EFGXip71
n+9gmyc6/sHTDIxk0sRrBRwGmKmIFTl8GgcVFWADaQsVvvd1RtfVIweCSlabfwfY
vgBLqlvjHrP6Pzo9n3j+c84kwvkRCoR/Xs2VJEpVnkl1jy8bKiMTAjcZaX8MWcI7
vIcINUh0AG8vQtcrBPiV3ubURm8qgjhfMh0JquJKkge29CrAGXtAGG1vh0t/nqow
S+RTYKIhuSrGC6nUdGvI3ISXwflGp/hEnMdq7UgXvuk9zqoRQiKiZ7RET8snHguB
bm6YGKvbumIqMER9aPQUL1JwRGCxTtp1MLTaSCY7V41oVwXtnQA=
=+I50
-----END PGP SIGNATURE-----


L
L
Ludovic Courtès wrote on 7 Dec 2023 11:27
(name . Tomas Volf)(address . ~@wolfsden.cz)(address . 67044@debbugs.gnu.org)
87zfyme29z.fsf@gnu.org
Hello!

Tomas Volf <~@wolfsden.cz> skribis:

Toggle quote (2 lines)
> On 2023-11-27 23:02:26 +0100, Ludovic Courtès wrote:

[...]

Toggle quote (13 lines)
>> 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 decided to give it a go:


Please do chime in and let me know what you think!

Ludo’.
T
T
Tomas Volf wrote on 7 Dec 2023 23:09
(name . Ludovic Courtès)(address . ludo@gnu.org)
ZXJCpL0u0UoEb8YA@ws
Hi :)

On 2023-12-07 11:27:04 +0100, Ludovic Courtès wrote:
Toggle quote (8 lines)
> [..]
>
> I decided to give it a go:
>
> https://issues.guix.gnu.org/67686
>
> Please do chime in and let me know what you think!

Thanks to the detailed cover letter, now I understand the benefit, so I agree it
would make sense. I looked over the implementation, and it looks fine to me (I
am not sure if I am qualified to do the review though :) ).

I just have few notes:

1.

Toggle quote (2 lines)
> (glibc-2.35)[arguments]: Delete ‘install-utf8-c-locale’ phase.

I do think 2.35 should install the locale as well. That would require to change

(invoke (string-append bin "/localedef")
"--no-archive" "--prefix" locale
"-i" "C" "-f" "UTF-8"
(string-append locale "/C.UTF-8")))))

into

(invoke (string-append bin "/localedef")
"-c" "--no-archive" "--prefix" locale
"-i" "C" "-f" "UTF-8"
(string-append locale "/C.UTF-8")))))

however I think that is fine. I am using locale built like that and it works
well. What is more, from the discussion under the other issue[0], that is
exactly what is done during normal glibc build:

Toggle quote (2 lines)
> It turns out we ignore errors during the glibc build (--quiet -c).

After that the drop of 'install-utf8-c-locale can be moved into some other
version < 2.35.

2.

I still believe it makes sense to add the -c also into the locale builder,
because my understanding is that this change will not allow using (locale
"C.utf8") in the operating-system definition (since that would still try to
build it, and fail).

If you are not opposed to the idea, I can send a patch if you would prefer not
to do it yourself.

3.

Toggle quote (3 lines)
> I suspect libc builds an additional ‘localedef’ for the build machine but I’m
> not sure where it is, hmm…

I looked around a bit, and I am not sure that is true. There seems to be only
./locale/localedef created. However, there is localedef inside gcc-toolchain's
bin directory, and, of course, in the build glibc. I am not sure what are the
version requirements here, but I would expect at least the one provided by glibc
to be usable.



Have a nice day,
Tomas


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

iQIzBAEBCgAdFiEEt4NJs4wUfTYpiGikL7/ufbZ/wakFAmVyQqQACgkQL7/ufbZ/
wan7vA//RKpYBFeFpE6FNHWrCZwPhxNy/d/lna/1TCPdf1smFe1cwvkwGthh0DJF
l8sqd9U5faEUeY58vpzZRHZ0kUJHfMKbzEzzCrB1OV8uw6fkY8RYVy9rRdSS8vrZ
R3SKbFcYo8zHBcVGE2pve1MAY48TyqJY+EHOfz7XAb3osOMJt8E/JjSSmhBB8k8c
9cY0wUbACuTmViFagniR27/y3n3TAr3BHRDWRCXLtQx24/JjcQw8uWKFljemTwSk
BHiNyzXxv1ajr63Bfy5txFSRmn2MkubOmohFjkTwD9ApG/J7VMPiRLS22mPgSv98
1qB9/BzQ/s/4ktP+V2+jqrvZRe33b8b6brHpwd9P7eNKvjcERiG6kyu0d3Otmbnc
MsoCChne0Ao9gdKfkwJZq16aktpDCuyHXAP8jdvy1xLjREMInM2lmV+yR7EJJ7vE
Srt05ckoFoPAvPSUEyCJNPC5i07nmEn9oODSXuZHpDWd1I1n1m27jgRzIT69j8Ua
l3Hfi4xruGX+FsMaltrqPKnjRNyfseOp0CXhddZv8Lo8XPKh7wrdHG/7o8PF3pN1
KLbZFEXU9F8bAkK0DV3UNdDIKAH7R131ZsyjvPhG0UFknEXCbUJy1wLxiqlwYaJd
yD++ZP+ZN4s+jtqmjUlbP1cEZFyffmYc1R3JQ8+mIHa2FcD515Q=
=o7Za
-----END PGP SIGNATURE-----


L
L
Ludovic Courtès wrote on 9 Dec 2023 15:46
Re: [bug#67686] bug#67044: C.utf8 locale cannot be built
(name . Tomas Volf)(address . ~@wolfsden.cz)
87a5qj5t7h.fsf@gnu.org
Hi Tomas,

Tomas Volf <~@wolfsden.cz> skribis:

Toggle quote (25 lines)
>> (glibc-2.35)[arguments]: Delete ‘install-utf8-c-locale’ phase.
>
> I do think 2.35 should install the locale as well. That would require to change
>
> (invoke (string-append bin "/localedef")
> "--no-archive" "--prefix" locale
> "-i" "C" "-f" "UTF-8"
> (string-append locale "/C.UTF-8")))))
>
> into
>
> (invoke (string-append bin "/localedef")
> "-c" "--no-archive" "--prefix" locale
> "-i" "C" "-f" "UTF-8"
> (string-append locale "/C.UTF-8")))))
>
> however I think that is fine. I am using locale built like that and it works
> well. What is more, from the discussion under the other issue[0], that is
> exactly what is done during normal glibc build:
>
>> It turns out we ignore errors during the glibc build (--quiet -c).
>
> After that the drop of 'install-utf8-c-locale can be moved into some other
> version < 2.35.

I’m a bit wary of using ‘-c’ (aka. ‘--force’) unconditionally as this
could hide real problems.

But more importantly, I think it won’t matter whether glibc 2.35 ships
C.UTF-8 since it’s no longer going to be used, except for building old
locale data via ‘locale-libcs’.

Toggle quote (10 lines)
> 2.
>
> I still believe it makes sense to add the -c also into the locale builder,
> because my understanding is that this change will not allow using (locale
> "C.utf8") in the operating-system definition (since that would still try to
> build it, and fail).
>
> If you are not opposed to the idea, I can send a patch if you would prefer not
> to do it yourself.

No you’re right, we could add ‘-c’ to the code in (gnu system locale),
though perhaps it would be safer to do so only in the 2.35 + C.UTF-8
case.

(We can do that independently of this patch.)

Toggle quote (7 lines)
> 3.
>
>> I suspect libc builds an additional ‘localedef’ for the build machine but I’m
>> not sure where it is, hmm…
>
> I looked around a bit, and I am not sure that is true.

In the meantime I found that this is wrong indeed:


Thanks for your feedback!

Ludo’.
T
T
Tomas Volf wrote on 10 Dec 2023 01:57
(name . Ludovic Courtès)(address . ludo@gnu.org)
ZXUM8kHTfiKswOh7@ws
On 2023-12-09 15:46:58 +0100, Ludovic Courtès wrote:
Toggle quote (14 lines)
> > I still believe it makes sense to add the -c also into the locale builder,
> > because my understanding is that this change will not allow using (locale
> > "C.utf8") in the operating-system definition (since that would still try to
> > build it, and fail).
> >
> > If you are not opposed to the idea, I can send a patch if you would prefer not
> > to do it yourself.
>
> No you’re right, we could add ‘-c’ to the code in (gnu system locale),
> though perhaps it would be safer to do so only in the 2.35 + C.UTF-8
> case.
>
> (We can do that independently of this patch.)

My attempt at that can be found here: https://issues.guix.gnu.org/67735

Tomas

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

iQIzBAEBCgAdFiEEt4NJs4wUfTYpiGikL7/ufbZ/wakFAmV1DPIACgkQL7/ufbZ/
wakzhw//cJZHhz2Np/v2qjk6+hNBO5aAeCcA1NcVmfO/CPoLsIu2I/uOkYJi3ClS
b5cJLwhpQ3PV2Dyffi2eteBrs0clBeTy04Q8BPAY1H69bG2pWPAHvgT6roA0gBdl
I37CKs6Mg9LYgxgiYpOqfkV4qoPP6GxZyjs5jXlA4Uw/esWS33oL1NRacsZ+Ffin
Gx3uh9uZdAlZLc2G4vAIPGyoTw9rijILC9h59cJ71xASKvj9XYD2aUm6gkFI900v
w9TMA/kYO3PR86mheX4Vkvs8kmqSyR6PiGzDjkN1lH3tG5n21TaEiuR873y2te7d
ZHU5r7XmT/XuqZ818jhA1xQYt5D7PkRVeGPanjmlK1Dc4j77+jeYUDWBaW+tWKC8
zzmGCNztop0fEHr2jAmi4Vu/dk72fFy4gLmmHcPdVRYLIDwOSF/bEf0VQRXg0Mwy
BnY0tp1GBZBvL74JLq5ygzRl/73k6vD4SHy16KrdWJDnJIB1jrNIUJBYGvLbBthC
L/sRfkhPdizd5bxKJCpfRobloJXhzU7NkXExt9bOFhKlC8auOOY4g4snJZDTU+1k
Y7lRH/Oz/60a4UiBsQYsbk1MYhwJ61Rh7K9kjs9HtIzrfJYFgX7j1qSnQow0l2g8
OYhPCHIcTbrqSDyt8pCfze0rqeAJkx8Up9jDK04/bB9Gd1N3maA=
=1sE0
-----END PGP SIGNATURE-----


?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 67044@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 67044
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch