Toolbox: Locale issue, need to install glibc-langpack-* package

[mildred]

using stack to build a haskell program inside Fedora toolbox, I got a strange error that I could track down to a locale issue. There were other issues such as less not showing up UTF-8 byte sequences. Running locale showed up errors:

$ locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=fr_FR.UTF-8
LC_CTYPE="fr_FR.UTF-8"
LC_NUMERIC="fr_FR.UTF-8"
LC_TIME="fr_FR.UTF-8"
LC_COLLATE="fr_FR.UTF-8"
LC_MONETARY="fr_FR.UTF-8"
LC_MESSAGES="fr_FR.UTF-8"
LC_PAPER="fr_FR.UTF-8"
LC_NAME="fr_FR.UTF-8"
LC_ADDRESS="fr_FR.UTF-8"
LC_TELEPHONE="fr_FR.UTF-8"
LC_MEASUREMENT="fr_FR.UTF-8"
LC_IDENTIFICATION="fr_FR.UTF-8"
LC_ALL=

Installing the glibc-langpack-fr package (in my case) solved the issue. That should probably be performed when the toolbox is created the first time. Or it could be part of the documentation.

[debarshiray]

Yes, I have heard of a similar oddity reported by Czech users too, but since locale seemed to work fine for variants of en (not just en_US), I forgot about it.

Do you know how the glibc-langpack-fr package gets installed on your Fedora host?

[debarshiray]

Thanks to @halfline I understand this a little better.

It's likely that replacing glibc-minimal-langpack with glibc-all-langpacks will solve the most pressing issues:

# dnf -y swap glibc-minimal-langpack glibc-all-langpacks

I think that a complete fix would also involve removing /etc/rpm/macros.image-language-conf and reinstalling all packages with missing translations. That would involve something similar to #55, which undoes the effects of tsflags=nodocs.

[debarshiray]

It would also be helpful to have a concrete test case that I can use to validate my experiments.

[juhp]

A simpler fix or workaround for now might be just to run podman with LANG=C.utf8.
That should fix most of the current problems I reckon.

Minimalist testcase is just to run locale:

@toolbox ~ $ locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=ja_JP.UTF-8
:

[mildred]

I don't know if this is following up this issue or not, but in a recent toolbox, the locale is no longer preserved from the host. now I get the en_US.UTF-8 locale, no locale error, and the same vim issues as in #14 (except not running inside tmux)

[juhp]

Currently toolbox only installs glibc-langpack-en by default.
edit I think this is inherited from the fedora:30 image.

[juhp]

In latest fedora:30 (and fedora:rawhide) glibc-langpack-en was dropped.
eg this affects https://bodhi.fedoraproject.org/updates/FEDORA-CONTAINER-2019-724ac61633

Actually it looks to me the real problem is that fedora:30 /etc/locale.conf has LANG="en_US.UTF-8":
assuming the above change is intentional.
We could workaround it with sed -e 's/en_US/C' /etc/locale.conf.

[juhp]

Okay it seems covered by https://bugzilla.redhat.com/show_bug.cgi?id=1727489

[A6GibKm]

Can confirm that installing glibc-langpack-en or glibc-alll-langpacks fixes this issue. Havee in mind that the later weigth about 200mb which is half's the container weigth.

[ghost]

Running $ toolbox run locale on the host yields:

locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
(...)

It seems to inherent the host's locale, which is not the case when running $ locale within a containerized shell session:

$ toolbox enter
⬢$ locale
LANG=C.UTF-8
LC_CTYPE="C.UTF-8"
(...)

While I am not certain whether it is a separate issue, installing glibc-langpack-en or glibc-all-langpacks fixes it for me. I'm on Fedora 31 Silverblue.