ValveSoftware / steam-runtime

A runtime environment for Steam applications

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

SteamLinuxRuntime: locales might not work as intended on Clear Linux

smcv opened this issue · comments

Originally reported by @K1ngfish3r in ValveSoftware/steam-for-linux#10577, but I'm separating this into its own more specific issue report, because it's a side issue rather than the main point of ValveSoftware/steam-for-linux#10577 and ValveSoftware/steam-for-linux#10789.

Your system information

  • Steam Runtime Version: (not relevant)
  • Distribution (e.g. Ubuntu 18.04): ClearLinux
  • Link to your full system information: (not provided)
  • Have you checked for system updates?: (not provided)
  • What compatibility tool are you using?: SLR 3.0 sniper
  • What versions are listed in steamapps/common/SteamLinuxRuntime/VERSIONS.txt? (not relevant)
  • What versions are listed in steamapps/common/SteamLinuxRuntime_soldier/VERSIONS.txt? (not relevant)
  • What versions are listed in steamapps/common/SteamLinuxRuntime_sniper/VERSIONS.txt? both 0.20240321.82093 and 0.20240307.80401 reproduce this issue

Steps to reproduce

  • Run Steam with either LANG=C.UTF-8 or LANG=en_US.UTF-8 in the environment, and no other locale environment variables set
  • Look at steamwebhelper.log

Expected result

No warnings, startup is as fast as would normally be feasible

Actual result

setlocale "en_US.UTF-8": No such file or directory
pressure-vessel-locale-gen: Missing locale en_US.UTF-8
pressure-vessel-locale-gen: Generating locale en_US.UTF-8...
pressure-vessel-locale-gen: Generated locale en_US.UTF-8 successfully
pressure-vessel-adverb[19866]: W: Container startup will be faster if missing locales are created at OS level

It is not yet clear whether this is misconfiguration on @K1ngfish3r's system, or a limitation in SLR where it does not understand the filesystem layout used in ClearLinux.

@K1ngfish3r, this is a side issue from your comments elsewhere. I'd like to diagnose whether this is misconfiguration on your system, or whether this is a SLR limitation.

To use a locale, it is not sufficient to set LANG=en_US.UTF-8: you also need glibc to have the appropriate locale data available. I don't know how this is meant to work on ClearLinux, but in most distros (Debian/Ubuntu and Arch), there are two ways you can get locale data:

  1. Install a package that provides precompiled locale data for every supported locale. In Debian/Ubuntu this is the locales-all package, and it provides files like these:
/usr/lib/locale/en_US.utf8/LC_ADDRESS
/usr/lib/locale/en_US.utf8/LC_COLLATE
/usr/lib/locale/en_US.utf8/LC_CTYPE
/usr/lib/locale/en_US.utf8/LC_IDENTIFICATION
/usr/lib/locale/en_US.utf8/LC_MEASUREMENT
/usr/lib/locale/en_US.utf8/LC_MESSAGES/SYS_LC_MESSAGES
/usr/lib/locale/en_US.utf8/LC_MONETARY
/usr/lib/locale/en_US.utf8/LC_NAME
/usr/lib/locale/en_US.utf8/LC_NUMERIC
/usr/lib/locale/en_US.utf8/LC_PAPER
/usr/lib/locale/en_US.utf8/LC_TELEPHONE
/usr/lib/locale/en_US.utf8/LC_TIME
  1. Install a package that provides files like /usr/share/i18n/locales/en_US, and run a tool that will generate a file with only the locales you want. In Debian/Ubuntu, this is the locales package, and you select the locales you want by uncommenting one or more lines in /etc/locale.gen and then running locale-gen, which generates /usr/lib/locale/locale-archive for you.

As a result of some annoying historical factors, Steam and Steam games want to see an en_US.UTF-8 locale, even if the OS does not provide one, and even though in 2024, C.UTF-8 is better for that purpose. For example, as a British user of Debian, I would normally have only en_GB.UTF-8 and C.UTF-8 locales (but not en_US.UTF-8), but Steam wants me to set up en_US.UTF-8 as well.

I don't know how this works on ClearLinux - the paths I quoted are right for Debian/Ubuntu and for Arch, but I know ClearLinux sometimes diverges from other distros. What are the paths that it uses?

And, did you already set up your system so that en_US.UTF-8 is a locale that is available? An easy way to check this is to run:

LC_ALL=en_US.UTF-8 perl -e ''

If the en_US.UTF-8 locale is correctly set up, it should exit with status 0 and no output.

If the en_US.UTF-8 locale doesn't work, it will log messages that look something like this:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
	LANGUAGE = "en_GB:en",
	LC_ALL = "en_US.UTF-8",
	LANG = "en_GB.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_GB.UTF-8").

erm

i@clr~ $ sudo swupd search-file /usr/share/i18n/locales/en_US
Downloading all Clear Linux manifests
 [100%]

Searching for '/usr/share/i18n/locales/en_US'

Bundle glibc-locale [installed] (1130 MB on system)
	/usr/share/i18n/locales/en_US

i@clr~ $ cat /usr/share/defaults/etc/locale.conf
LANG=en_US.UTF-8
i@clr~ $ locale
locale     localectl  localedef
i@clr~ $ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
i@clr~ $ LC_ALL=en_US.UTF-8 perl -e ''
i@clr~ $ perl --version

This is perl 5, version 38, subversion 2 (v5.38.2) built for x86_64-linux-thread-multi...

Pre-compiled locales were not provided so I tried finding /usr/share/i18n/locales/en_US, which I seem to have installed already. Then I tried to locate /usr/share/defaults/etc/locale.gen but there was only a locale.conf with a single line inside it. I also do not have the locale-gen command, but I did have a locale. Then I tried the final command and got no errors.

Should I go about obtaining locale-gen and compiling the locale?

It looks as though Clear Linux must be using some path for the compiled locales that is not one of the ones we know about. Are there other paths like SYS_LC_MESSAGES or locale-archive?

Note that if swupd search-file is searching the package manager's database, it will not necessarily find any files that are dynamically generated on the end-user system (they might be below /var somewhere).

From experimenting with a ClearLinux live-image, ClearLinux uses various non-standard paths for locales:

  • /var/cache/locale/locale-archive as its equivalent of Debian's /usr/lib/locale/locale-archive
  • /var/cache/locale/locale.alias as its equivalent of Debian's /usr/lib/locale/locale.alias -> /etc/locale.alias symlink
  • /usr/share/locale as its equivalent of Debian's /usr/lib/locale

This is awkward, because /usr/share/locale already means something different (it's where third-party software like GTK installs locale files), so we can't just overwrite it with a symlink to the host copy like we do on other OSs with an atypical locale setup.