Switching language and format broken

Gunnar, thanks for looking into this.

See also bug 1631750.

So I looked briefly at this today. By the time I filed that other bug, accountsservice hadn't really changed from xenial. gnome-settings-daemon doesn't look to me like it does stuff with language settings. gnome-control-center had been updated from 3.18 to 3.20. And then I found this commit:

https://git.gnome.org/browse/gnome-control-center/commit/?h=gnome-3-20&id=30470d721

Since the region panel didn't change much in 3.20 I suspect that commit might be our problem.
https://git.gnome.org/browse/gnome-control-center/log/panels/region?h=gnome-3-20
(Look at 2016 commits only)

(There were some November 2015 commits too but they didn't look important)

Did some testing on zesty. When I had switched to lightdm, language switching between already installed languages worked fine, so gdm3 seems to be the culprit.

Haven't been able to spot the applicable code in the gdm3 source. Tried the attached patch, but it didn't help.

If I set the variables in ~/.profile, it works, so gdm3 sets the system wide environment variables after PAM has read ~/.pam_environment but before it sources ~/.profile.

This issue is present on an artful daily build as well. gdm3 somehow overrides variables set by ~/.pam_environment. (With lightdm it works as expected.)

It should be noticed that the issue is present whether g-c-c or language-selector is used to change the display language.

If nobody figures out what makes the variables in ~/.pam_environment be overridden by the variables in /etc/default/locale, I'm thinking of an ugly hack which may work.

~/.pam_environment is maintained by /usr/share/language-tools/save-to-pam-env. In case of a GNOME desktop we could make that file write to ~/.profile as well.

Testing in an up-to-date artful VM, when switching languages in g-c-c, both LANG and LANGUAGE are updated in both ~/.pam_environment and /etc/default/locale.

That VM is an artful install that has been updated daily, not an upgrade from a previous release.

Olivier: Is /etc/default/locale written to also?? That's not what Sebastien and I observed. I'll go to a (relatively) fresh artful install and recheck then.

If that's the case, the issue may not be so urgent. But it's poor design, since it means that if a user changes language, s/he changes it for all users on the system.

The /etc/default/locale file was not altered when I just tested on an updated artful.

To clarify: I used the g-c-c interface to switch language. If I had clicked "Manage Installed Languages" to open Language Support and then clicked "Apply System-Wide", /etc/default/locale would have been updated too. But that 'does not count'. Language Support is available to work around the fact that installation of new languages from g-c-c does not work currently.

I didn't click "Apply System-Wide". When I changed the language in g-c-c /etc/default/locale was written to (LANG and LANGUAGE were updated). I agree that this is unexpected behaviour though, I wouldn't expect the current user's setting to be applied system-wide unless explicitly requested.

In /etc/pam.d/gdm-launch-environment:

    session required pam_env.so readenv=1 user_readenv=1 envfile=/etc/default/locale

In pam_env.c (handle_env function), the env should be set from /etc/default/locale and then overridden by ~/.pam_environment. If I add the 'debug' parameter to the module invokation, I see only the calls to pam_putenv corresponding to /etc/default/locale, which means that for some reason to be determined ~/.pam_environment is not being sourced.

Wonder if there is a problem with this code:

https://git.gnome.org/browse/gdm/tree/daemon/gdm-session-worker.c#n993

@Steve: gdm3 seems to not read ~/.pam_environment. Do you possibly have an idea off the top of your head?

/etc/pam.d/gdm-launch-environment is run as user gdm, so it's not what we're interested in.

/etc/pam.d/gdm-password appears to be what sets the environment upon user login.

When adding some logging to that module, I'm seeing the following:

pam_env(gdm-password:session): username=ubuntu
pam_env(gdm-password:session): user env path: /home/ubuntu/.pam_environment
pam_env(gdm-password:session): parsing config file
pam_env(gdm-password:session): remove variable "LANGUAGE=fr_FR:en_GB:en"
pam_env(gdm-password:session): remove variable "LANG=fr_FR.UTF-8"

It turns out, "VARIABLE=value" is not the correct syntax for ~/.pam_environment. The expected syntax is "VARIABLE [DEFAULT=[value]] [OVERRIDE=[value]]" (man pam_env.conf).
And indeed if I modify ~/.pam_environment to conform to that syntax, I'm seeing this instead:

pam_env(gdm-password:session): pam_putenv("LANGUAGE=fr_FR:en_GB:en")
pam_env(gdm-password:session): pam_putenv("LANG=fr_FR.UTF-8")

That doesn't seem to fix the overall issue though, as the values of LANGUAGE and LANG are still those from /etc/default/locale after logging in.

/usr/share/language-tools/save-to-pam-env is the script that writes to ~/.pam_environment with an incorrect syntax.

I added a FOOBAR variable to both ~/.pam_environment and /etc/default/locale, with different values in each file, and after logging in the value is the one from ~/.pam_environment. So I don't think gdm sources /etc/default/locale after ~/.pam_environment. However variables LANG, LANGUAGE and LC_* appear to be overridden by the values in /etc/default/locale, and set_up_session_language() in daemon/gdm-session.c (https://git.gnome.org/browse/gdm/tree/daemon/gdm-session.c#n2488) looks suspicious in that regard.

Yep, suspicious indeed. I built gdm3 with that function disabled:

https://launchpad.net/~gunnarhj/+archive/ubuntu/gdm3

And yes, that's it. You nailed it Olivier; thanks a lot!

Why didn't I see it when looking at that file many months ago... :( Anyway, I have submitted a MP.

And I can confirm that the packages in Gunnar's PPA appear to fix the issue here, without any visible regression, from my limited testing.

the function has been added to fix https://bugzilla.gnome.org/show_bug.cgi?id=709105

I filed https://bugzilla.gnome.org/show_bug.cgi?id=788762 to continue the conversation upstream.

See conversation on the upstream bug report. It turns out calling set_up_session_language() earlier (e.g. in on_setup_complete_cb) doesn't fix the problem: gdm_session_start_session() calls send_environment(), which overrides the environment set up by pam with the values from /etc/default/locale again.

I guess not calling set_up_session_language() at all is the correct fix in our case.

This bug was fixed in the package gdm3 - 3.26.1-3ubuntu2

---------------
gdm3 (3.26.1-3ubuntu2) artful; urgency=medium

  * debian/patches/ubuntu_dont_set_language_env.patch:
    - Don't run the set_up_session_language() function, since it
      overrides variable values set by ~/.pam_environment
      (LP: #1662031). Thanks to Olivier Tilloy for debugging!

 -- Gunnar Hjalmarsson <email address hidden> Wed, 11 Oct 2017 13:20:09 +0200