Toolbox: Gebietsschemaproblem, muss das Paket glibc-langpack-* installieren

Ja, ich habe auch von einer ähnlichen Kuriosität gehört, die von tschechischen Benutzern berichtet wurde, aber da locale für Varianten von en (nicht nur en_US ) gut zu funktionieren schien, habe ich es vergessen es.

Wissen Sie, wie das Paket glibc-langpack-fr auf Ihrem Fedora-Host installiert wird?

Dank @halfline verstehe ich das etwas besser.

Es ist wahrscheinlich, dass das Ersetzen von glibc-minimal-langpack durch glibc-all-langpacks die dringendsten Probleme löst:

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

Ich denke, dass eine vollständige Korrektur auch das Entfernen von /etc/rpm/macros.image-language-conf und die Neuinstallation aller Pakete mit fehlenden Übersetzungen beinhalten würde. Das würde etwas Ähnliches wie #55 beinhalten, das die Auswirkungen von tsflags=nodocs rückgängig macht.

Hilfreich wäre auch ein konkreter Testfall, mit dem ich meine Experimente validieren kann.

Eine einfachere Lösung oder Problemumgehung könnte vorerst darin bestehen, podman mit LANG=C.utf8 auszuführen.
Das sollte die meisten der aktuellen Probleme beheben, denke ich.

Der minimalistische Testfall soll nur locale ausführen:

<strong i="10">@toolbox</strong> ~ $ 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
:

Ich weiß nicht, ob dies diesem Problem nachgeht oder nicht, aber in einer neueren Toolbox wird das Gebietsschema nicht mehr vom Host beibehalten. jetzt bekomme ich das en_US.UTF-8 Gebietsschema, keinen Gebietsschemafehler und die gleichen vim-Probleme wie in #14 (außer dass es nicht in tmux läuft)

Derzeit installiert Toolbox standardmäßig nur glibc-langpack-en .
Bearbeiten Ich denke, dies wird vom fedora:30 Bild geerbt.

Im neuesten fedora:30 (und fedora:rawhide) wurde glibc-langpack-en weggelassen.
das betrifft zB https://bodhi.fedoraproject.org/updates/FEDORA-CONTAINER-2019-724ac61633

Eigentlich scheint mir das eigentliche Problem darin zu bestehen, dass Fedora:30 /etc/locale.conf LANG="en_US.UTF-8" :
vorausgesetzt, die obige Änderung ist beabsichtigt.
Wir könnten es mit sed -e 's/en_US/C' /etc/locale.conf .

Okay, es scheint von https://bugzilla.redhat.com/show_bug.cgi?id=1727489 abgedeckt zu sein

Kann bestätigen, dass die Installation von glibc-langpack-en oder glibc-alll-langpacks dieses Problem behebt. Denken Sie daran, dass das spätere Gewicht etwa 200 MB beträgt, was der Hälfte des Containergewichts entspricht.

Das Ausführen von $ toolbox run locale auf dem Host ergibt:

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"
(...)

Es scheint das Gebietsschema des Hosts inhärent zu sein, was nicht der Fall ist, wenn $ locale innerhalb einer containerisierten Shell-Sitzung ausgeführt wird:

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

Ich bin mir zwar nicht sicher, ob es sich um ein separates Problem handelt, aber die Installation von glibc-langpack-en oder glibc-all-langpacks behebt es für mich. Ich habe Fedora 31 Silverblue.