mkosi: set locale to be en_US.UTF-8

[johnlinp]

Fixes: #7238

[poettering]

hmm, can you explain why C.UTF-8 wouldn't work here? everything I find on the internet suggests that that's a valid locale, and "local -a" appears to show it everywhere I checked as valid. I wonder if this is an ArchLinux specific thing, that that locale isn't set up properly there?

If C.UTF-8 is valid, I'd prefer to use it, since it means "don't do locale, except for using UTF-8 as character set", which is what we want and very different from "do american localization"... Given that the images we build aren't really supposed to be american, and given that we don't actually pull in localization package support (at least not where we can avoid it)

[johnlinp]

I did a bit of research on C.UTF-8. Please correct me if I'm wrong.

I don't think C.UTF-8 is valid everywhere. At least it's not valid by default (i.e. provided by glibc). Take Fedora as an example, C.UTF-8 isn't supported before this bug is fixed.

I suggest that we can start using C.UTF-8 only after this upstream glibc bug is fixed. Thank you.

[mbiebl]

but en_US.UTF-8 is also not guaranteed to exist everywhere (even less likely then C.UTF-8)
So I'm not sure this commit is actually fixing anything. It just breaks it for a different set of people.

[mbiebl]

For example, on a couple of Debian systems I have:

# locale -a
C
C.UTF-8
de_DE.utf8
POSIX

C.UTF-8 is guaranteed to be enabled on every Debian/Ubuntu based system. I think it's the same for Fedora. Other UTF-8 locales are not guaranteed to exist.

[poettering]

urks... do we have to auto-detect what is available? yuck!

[mbiebl]

@poettering I think you can only rely on C to be universally available.
C.UTF-8 is enabled by default (and not removable) by most major distros afaik. But no, atm it's not guaranteed to exist everywhere. Choosing en_US.UTF-8 is even worse.

[johnlinp]

I don't think en_US.UTF-8 is a worse choice. Since we have mkosi.arch, mkosi.debian, mkosi.fedora in .mkosi/, then we should guarantee that systemd is able to build on these three OSs. Maybe this pull request is a workaround, but it can solve the problem for this moment.

Or, should I file another issue to wait for the glibc bug and change it back to C.UTF-8?

[poettering]

I think the point @mbiebl was making is that en_US.UTF-8 on Debian is an optional locale, but C.UTF-8 is not there...

I figure we need to do some auto-discovery here: use C.UTF-8 when it exists, fallback to en_US.UTF-8 if it doesn't, fail if that doesn't exist too

[poettering]

(and other than that, I think the arch folks should also do what debian and fedora appear to do: guarantee for the existance of C.UTF-8)

[mbiebl]

don't think en_US.UTF-8 is a worse choice. Since we have mkosi.arch, mkosi.debian, mkosi.fedora in .mkosi/, then we should guarantee that systemd is able to build on these three OSs. Maybe this pull request is a workaround, but it can solve the problem for this moment.

It does not. As I showed you, en_US.UTF-8 is not guaranteed to exist on Debian/Ubuntu whereas C.UTF-8 is acutally guaranteed to exist.
I'm not sure if arch actually guarantees that en_US.UTF-8 always exists, but this commit broke it for Debian/Ubuntu users (unless they installed their system choosing en_US as language).

[mbiebl]

I think the point @mbiebl was making is that en_US.UTF-8 on Debian is an optional locale, but C.UTF-8 is not there...

"not there" → always guaranteed to be there

[mbiebl]

I figure we need to do some auto-discovery here: use C.UTF-8 when it exists, fallback to en_US.UTF-8 if it doesn't, fail if that doesn't exist too

Would mkosi support falling back to a non-UTF locale like C? If not, what you propose seems the only option then unfortunately.

[keszybz]

Yeah, I dislike the switch too. C.UTF-8 is exactly what we should use.

[poettering]

Would mkosi support falling back to a non-UTF locale like C? If not, what you propose seems the only option then unfortunately.

Nah, this is 2017. I'd rather make the stuff fail than end up using non-UTF8 ctypes...