snap-based programs complain about locale

[Paul Eggert]

This is a followup to Launchpad Bug#1959845, as I was asked to file a separate bug report for the locale issue.

I am running Ubuntu 22.04.1 LTS on x86-64 with current patches. I am using snapd 1.60-0ubuntu1.

When I run the shell command "chromium --version" and attempt to debug the resulting situation a bit, I see the following. As you can see, I get a bogus diagnostic about the locale. My locale is fine, although evidently snap packages can't use it.

$ chromium --version
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
Chromium 103.0.5060.134 snap
$ LC_ALL=C chromium --version
Chromium 103.0.5060.134 snap
$ echo $SHELL
/bin/bash
$ env | grep -E '^LC_|^LANG='
LANG=C
LC_ALL=en_US.utf8
$ locale
LANG=C
LANGUAGE=
LC_CTYPE="en_US.utf8"
LC_NUMERIC="en_US.utf8"
LC_TIME="en_US.utf8"
LC_COLLATE="en_US.utf8"
LC_MONETARY="en_US.utf8"
LC_MESSAGES="en_US.utf8"
LC_PAPER="en_US.utf8"
LC_NAME="en_US.utf8"
LC_ADDRESS="en_US.utf8"
LC_TELEPHONE="en_US.utf8"
LC_MEASUREMENT="en_US.utf8"
LC_IDENTIFICATION="en_US.utf8"
LC_ALL=en_US.utf8

[Alberto Mardegan (mardy)]

Hi Paul, and thanks for opening this.

Generally one should not use the LC_ALL variable, but the other LC_* variables instead. If you are setting LC_ALL in your .bashrc, you could try removing it and see if things continue to work.

If you have a need to use LC_ALL, then the information I found online suggests adding the variable to /etc/environment. Can you see if that helps?

[Paul Eggert (eggert-cs)]

This is the first I've heard of any advice to avoid LC_ALL, and I wonder what is prompting that advice.

It would be a pain to set every other LC_* environment variable to en_US.utf8, and POSIX says there should be no point to doing so, as POSIX requires the painful approach to have the same effect as simply setting LC_ALL. See the POSIX spec for internationalization variables in:

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_02

Briefly, POSIX says that setting LC_ALL to a value should have the same effect as setting the other LC_* variables to that value. It should also have the same effect as setting LANG to that value while leaving all LC_* variables unset.

If the snap packaging for Chromium and Firefox doesn't do that, then it's a bug in the snap packaging that should get fixed.

[Paul Eggert (eggert-cs)]

> If you are setting LC_ALL in your .bashrc, you could try removing it and see if things continue to work.

Yes, that solves the --help problem, though of course it causes my locale to be wrong:

$ LC_ALL=en_US.utf8 chromium-browser --version
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
Chromium 103.0.5060.134 snap
520-day $ unset LC_ALL; chromium-browser --version
Chromium 103.0.5060.134 snap

> If you have a need to use LC_ALL, then the information I found online suggests adding the variable to /etc/environment. Can you see if that helps?

That requires root access, no? So it's not a viable solution for many users (and what, every time I install Ubuntu I have to fiddle with /etc/environment?). But anyway, it does not help to add a line 'LC_ALL="en_US.utf8"' to /etc/environment; I still get the diagnostic.

[Alberto Mardegan (mardy)]

> This is the first I've heard of any advice to avoid LC_ALL, and I wonder what is prompting that advice.

I didn't dig deep into the reasons, but there's plenty of authoritative resources in the internet who discourage using it.
See for example: https://wiki.debian.org/Locale

> It would be a pain to set every other LC_* environment variable to en_US.utf8

Well, you don't have to do it, because you can use LANG. And if you don't care about the sessions created by the console logins (most users nowadays just login from the graphical session), most desktop environments offer a configuration option in the user settings, where you can set the user's locale. Alternatively, the link from Debian I posted above contains a few other options.

[Paul Eggert (eggert-cs)]

> See for example: https://wiki.debian.org/Locale

That web page was wrong, so I wrote to debian.org and got it fixed. It now says: "You can set LANG or LC_ALL to your preferred locale. If there are specific aspects of your primary locale that you don't like (e.g., date formats), then you can leave LC_ALL unset, set LANG to a default locale, and set specific variables to override those features only. If you do this, you should override features in a compatible way. For example, if you do not set LC_ALL and set LANG=en_US.UTF-8, then you should not also set LC_TIME=ja_JP.eucjp because the codepages of the LANG and LC_TIME settings would clash."

> you don't have to do it, because you can use LANG.

LANG is error-prone because it allows the user to mess up their character encodings as now described in the Debian wiki. It's better to use LC_ALL, which works more reliably.

Here's another way to put it. Fedora, and everyone else who builds and uses Chromium and Firefox in the usual way, don't get the bogus diagnostic:

fedora$ LC_ALL=en_US.utf8 chromium-browser --version
Chromium 103.0.5060.114 Fedora Project

whereas Ubuntu uses a snap-based version, and gets the bogus diagnostic:

ubuntu$ LC_ALL=en_US.utf8 chromium-browser --version
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
Chromium 104.0.5112.79 snap

Ubuntu's the outlier here, and should get fixed.

[Alberto Mardegan (mardy)]

Hi Paul, thanks for the information! Since it seems that you also have access to a Fedora machine, can you please try and see what happens if you install the chromium snap in there? This would help us understand if it's a problem with the snap or with something else in the distribution.

[Paul Eggert (eggert-cs)]

> can you please try and see what happens if you install the chromium snap in there?

Got a recipe for that, that doesn't involve destroying the standard chromium browser? I've never used snaps on Fedora, nor flatpaks either. My Fedora machine has only traditional .rpm packages, such as the chromium package for chromium-browser, an installed package that I don't want to disrupt.

[Alberto Mardegan (mardy)]

Installing the snap will not touch your existing rpm installation of chromium; you can install the snap, run "chromium --version", then uninstall it.

AFAIK, the chromium snap will try to import your existing profile, but it won't destroy or change it.

[Paul Eggert (eggert-cs)]

> you can install the snap, run "chromium --version", then uninstall it

OK, I did that, and it works fine on Fedora. Here's a shell transcript:

$ sudo dnf install snapd
[sudo] password for eggert:
Last metadata expiration check: 0:02:24 ago on Mon Aug 8 09:58:55 2022.
Dependencies resolved.
================================================================================
 Package Architecture Version Repository Size
================================================================================
Installing:
 snapd x86_64 2.56.2-4.fc36 updates 14 M
Installing dependencies:
 snap-confine x86_64 2.56.2-4.fc36 updates 2.5 M
 snapd-selinux noarch 2.56.2-4.fc36 updates 230 k

Transaction Summary
================================================================================
Install 3 Packages

Total download size: 16 M
Installed size: 57 M
Is this ok [y/N]: y
Downloading Packages:
(1/3): snapd-selinux-2.56.2-4.fc36.noarch.rpm 287 kB/s | 230 kB 00:00
(2/3): snap-confine-2.56.2-4.fc36.x86_64.rpm 2.2 MB/s | 2.5 MB 00:01
(3/3): snapd-2.56.2-4.fc36.x86_64.rpm 7.8 MB/s | 14 MB 00:01
--------------------------------------------------------------------------------
Total 7.1 MB/s | 16 MB 00:02
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing : 1/1
  Running scriptlet: snapd-selinux-2.56.2-4.fc36.noarch 1/3
  Installing : snapd-selinux-2.56.2-4.fc36.noarch 1/3
  Running scriptlet: snapd-selinux-2.56.2-4.fc36.noarch 1/3
  Installing : snap-confine-2.56.2-4.fc36.x86_64 2/3
  Installing : snapd-2.56.2-4.fc36.x86_64 3/3
  Running scriptlet: snapd-2.56.2-4.fc36.x86_64 3/3
Created symlink /etc/systemd/system/sockets.target.wants/snapd.socket → /usr/lib/systemd/system/snapd.socket.
Created symlink /etc/systemd/user/sockets.target.wants/snapd.session-agent.socket → /usr/lib/systemd/user/snapd.session-agent.socket.

  Running scriptlet: snapd-selinux-2.56.2-4.fc36.noarch 3/3
  Running scriptlet: snapd-2.56.2-4.fc36.x86_64 3/3
  Verifying : snap-confine-2.56.2-4.fc36.x86_64 1/3
  Verifying : snapd-2.56.2-4.fc36.x86_64 2/3
  Verifying : snapd-selinux-2.56.2-4.fc36.noarch 3/3

Installed:
  snap-confine-2.56.2-4.fc36.x86_64 snapd-2.56.2-4.fc36.x86_64
  snapd-selinux-2.56.2-4.fc36.noarch

Complete!
$ sudo snap install chromium
error: too early for operation, device not yet seeded or device model not acknowledged
$ ls -ld /snap
ls: cannot access '/snap': No such file or directory
$ sudo snap install chromium
2022-08-08T10:04:38-07:00 INFO Waiting for automatic snapd restart...
chromium 104.0.5112.79 from Canonical✓ in...

[Alberto Mardegan (mardy)]

Sorry for the stupid question Paul, but since in comment #5 you explicitly exported "LC_ALL=en_US.utf8" into the environment when running chromium: are you sure that the environment variable was set in Fedora when you ran the commands above?

[Paul Eggert (eggert-cs)]

Not a stupid question at all; as it turns out I did the Fedora test with a different environment. I tried the Fedora test again with LC_ALL set and this time got the same misbehavior as on Ubuntu. (There was one other thing different: this time I got Chromium 104 instead of 103; don't know if that matters.)

The shell transcript ended this way:

$ LC_ALL=en_US.utf8 /var/lib/snapd/snap/bin/chromium --version
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
Importing existing chromium profile from /home/eggert/.config/chromium (version 100.0.4896.127)
Import done in 3.590 s
Chromium 104.0.5112.79 snap
$ LC_ALL=en_US.utf8 /var/lib/snapd/snap/bin/chromium --version
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
Chromium 104.0.5112.79 snap

[Paul Eggert (eggert-cs)]

Is any further info needed from me? Currently the bug is marked "Incomplete" but I don't see what info is needed to complete it.

[Alberto Mardegan (mardy)]

Hi Paul, no, as far as I'm concerned there's no more info I need. I believe that the best people to look into this issue are in the Desktop Team, as they maintain the scripts that set the environment when launching desktop apps. Unfortunately, though, their bug tracker is not in launchpad.

Would you mind filing an issue at https://github.com/snapcore/snapd-desktop-integration/issues, briefly explaining the problem and providing a link to this discussion?

I think we can keep this bug here open until it either expires, or we get confirmation that the bug is in snapd (then I'd set it to "confirmed").

[Paul Eggert (eggert-cs)]

Thanks for the suggestion of filing a bug upstream. I filed one here:

https://github.com/snapcore/snapd-desktop-integration/issues/22

In the upstream version I noted a new symptom, namely, diagnostics from update.go that I recieved one time. So you might want to look at the upstream report too.

[Alberto Mardegan (mardy)]

Thanks Paul! I believe that the update.go issue will be fixed with https://github.com/snapcore/snapd/pull/12127