Arch Linux

Adding glibc maintainers too because systemd upstream want us to generate C.UTF-8 by default: https://github.com/systemd/systemd/pull/23252#issuecomment-1115825144

So does this work if C.UTF-8 locale is generated and available?

Yes. But we currently do not enforce such a thing on user systems.

So, this issue seems to be causing all kinds of build mayhem...

Researching the back story [1] indicates upstream are ultimately wanting to include C.UTF-8 as built-in to Glibc itself (exactly how the "C" locale is currently handled). Even though this didn't quite happen in the 2.35 release, maybe we should simply include it with our glibc by default anyway? This is what Debian / Fedora appear to be doing. I haven't looked in detail yet but hopefully it's a simple matter of crafting a suitable "localedef" command.

Failing that, someone should just whack C.UTF-8 into devtools and get a release out ASAP. Thanks!

[1] https://sourceware.org/glibc/wiki/Proposals/C.UTF-8

As long as glibc doesn't ship C.UTF-8 by default, I'd suggest to remove the '#' from locale.gen by default and issue a localedef command with the installscript (on install only). Upgrades shall be handeled by pacdiff or manual merge. So anyone installing a fresh arch will have the locale enabled and existing users see the change in the pacnew file.

Any objections?

Sounds good to me, so +1...

Currently the install script has `locale-gen` in `post_upgrade()` only... Is there a reason for that? How are locales generated on initial installation?

Generating locales on install has been rejected before:  FS#67464 

I think we have a good reason now, as systemd is expecting us to include C.UTF-8 and glibc will probably include it in the future similar to the C locale.

I don't think enabling C.UTF-8 in /etc/locale.gen is the best option due to the manual intervention required. Instead I suggest pregenerating C.UTF-8 using localedef and ship it in /usr/lib/locale/C.UTF-8/ as part of glibc. This is what Debian does:

https://salsa.debian.org/glibc-team/glibc/-/blob/83fb5553addb34aa12820b93a5344866e6a92196/debian/rules.d/build.mk#L372
https://salsa.debian.org/glibc-team/glibc/-/blob/83fb5553addb34aa12820b93a5344866e6a92196/debian/debhelper.in/libc-bin.install#L21

For this to work, our custom locale-gen script needs to be patched to only remove /usr/lib/locale/locale-archive instead of all the contents of the /usr/lib/locale/ folder. This has been patched in Debian by

https://salsa.debian.org/glibc-team/glibc/-/commit/0c4e4734074fd8a45c5ac8a4100b083037fa449c

Attached to this comment is a proposed patch to the glibc PKGBUILD that implements the above suggestion. I tested that the following works:

- After upgrading a system that did not have C.UTF-8 enabled in /etc/locale.gen to this new glibc package, the C.UTF-8 locale is available (tested with "locale -a" and "LANG=C.UTF-8 perl") without any user intervention.
- After upgrading a system that had C.UTF-8 already enabled, nothing changes, C.UTF-8 continues to work as before.
- Running locale-gen (directly or through an alpm hook) preserves /usr/lib/locale/C.UTF-8/ so that the locale continues to work, whether enabled in /etc/locale.gen or not.

If C.UTF-8 is going to be shipped in the glibc package, it should probably be removed from /etc/locale.gen. Otherwise it'll just be confusing.

Sure, that could be achieved using

sed -i '/#C\.UTF-8 /d' "$pkgdir/etc/locale.gen"

See the updated patch attached to this comment.

@diabonas, this looks like an excellent solution! (/me tries to find a like button)

My only comment would be that both Debian and Fedora go out of their way to fully ensure the just-built glibc is used to do the actual work:

elf/ld.so --library-path blah localedef blah ...

Just calling the "locale/localedef" binary directly might not cut the mustard. There must be a reason why they do it. It probably matters when upgrading to a new major Glibc version. If we are bootstrapping a toolchain where we build Glibc twice then maybe it doesn't matter much. Anyway, just raising it as a potential issue.

I hope glibc will include the locale by default. But let's keep this in mind in case we run into erros. Thanks @diabonas and @Toolybird