SetLanguage(): Write ~/.pam_environment instead of ~/.profile

Bug #866062 reported by Martin Pitt on 2011-10-04
24
This bug affects 3 people
Affects Status Importance Assigned to Milestone
accountsservice (Ubuntu)
Medium
Gunnar Hjalmarsson
Precise
Medium
Gunnar Hjalmarsson
language-selector (Ubuntu)
Undecided
Unassigned
Precise
Undecided
Unassigned

Bug Description

Just discussed in #u-devel: We currently write the user's locale into ~/.profile, which is icky as it's a shell script. For 12.04 onward we ought to use ~/.pam_environment and have it set by PAM.

Martin Pitt (pitti) on 2011-10-04
Changed in accountsservice (Ubuntu):
status: New → Triaged
importance: Undecided → Medium
Gunnar Hjalmarsson (gunnarhj) wrote :

This does sound interesting. As you know, I'd like to drop ~/.profile for the purpose, but so far I have had a few new accountsservice properties in mind instead. One advantage with using a-s is that the locales can be set correctly even if $HOME can't be accessed. Isn't that one of the reasons why accountsservice exists, btw?

Anyway, something new to consider.

Gunnar Hjalmarsson (gunnarhj) wrote :

In the case of some new accountsservice properties, I suppose that PAM can still be used to get the values and set the environment.

Robert Ancell (robert-ancell) wrote :

This is absolutely the correct place to set it as this means the locale is set correctly from the beginning of authentication throughout the entire session.

Gunnar Hjalmarsson [2011-10-04 20:16 -0000]:
> This does sound interesting. As you know, I'd like to drop ~/.profile
> for the purpose, but so far I have had a few new accountsservice
> properties in mind instead. One advantage with using a-s is that the
> locales can be set correctly even if $HOME can't be accessed.

If we can't access $HOME, we can't start a session, so that's not an
issue. It is only an issue if we want to implement a language selector
in the lightdm greeter, but then we can ask accountsservice.

Rhialto (rhialto-xs4all) wrote :

Another disadvantage of ~/.profile is that bash doesn't always read it. In fact this is noted at the top of that file itself (at least in my version).
I have some problems with the regional language settings (I want time/date in Dutch but text messages in English), but when I set the regional settings (with xubuntu's Applications > Settings > Language Support), suddenly Firefox and other things started to be in Dutch as well. In a terminal, far too many LC_* settings were suddenly nl_NL.UTF-8, according to the locale command. For a proper bug report, I wanted to reproduce this in a clean test account but I couldn't.
I suspect now that the fact that I have a ~/.bash_login file has something to do with it (so ~/.profile isn't read, or isn't always read, or something).
It's annoying that one can only test this by logging out; I can't quite seem to reproduce it in the test login either.

Gunnar Hjalmarsson (gunnarhj) wrote :

Am 2011-10-18 12:46, schrieb Rhialto:
> I have some problems with the regional language settings (I want
> time/date in Dutch but text messages in English), but when I set the
> regional settings (with xubuntu's Applications > Settings > Language
> Support), suddenly Firefox and other things started to be in Dutch as
> well.

If you experience that behavior Oneiric (where it should not be possible) it does sound like ~/.profile is not read, so you probably should get that fixed.

But if you are the only user, even without ~/.profile you should be able to get the desired combination by clicking "Apply System-Wide" from the "Language" tab in Language Support.

Hadmut Danisch (hadmut) wrote :

by the way, that method of modifying ~/.profile breaks its contents since it replaces _all_ occurences of that export entries.

This makes it impossible to share .profile files between different computers with different language settings, even if it contains case-instructions for the different computers. It even destroys the old settings, and loss of data is usually to be considered as a severe and important bug.

Automatically modifying user-written shell scripts is an absolute no-go and really broken by design. This design decision should have never been made.

There's lots of better files for doing that. Files in /etc/X11/Xsession.d read things like ~/.gnomerc or ~/.xsessionrc which would be much better (or even use a specific file for language settings), but under all circumstances keep fingers from ~/.profile.

Even worse, this affects the settings if someone is logging in through ssh or with other desktops.

This is not just bad design, this is really a bug.

regards

Changed in accountsservice (Ubuntu Precise):
assignee: Martin Pitt (pitti) → Gunnar Hjalmarsson (gunnarhj)
status: Triaged → In Progress
Martin Pitt (pitti) on 2012-02-02
Changed in accountsservice (Ubuntu Precise):
status: In Progress → Fix Committed
Martin Pitt (pitti) on 2012-02-02
Changed in language-selector (Ubuntu Precise):
status: New → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package accountsservice - 0.6.15-2ubuntu3

---------------
accountsservice (0.6.15-2ubuntu3) precise; urgency=low

  [ Gunnar Hjalmarsson ]
  * debian/patches/0001-formats-locale-property.patch and
    debian/libaccountsservice0.symbols:
    - Addition of FormatsLocale property and SetFormatsLocale method.
  * debian/patches/0009-language-tools.patch:
    - Make SetLanguage() and SetFormatsLocale() write to
      ~/.pam_environment instead of ~/.profile (LP: #866062).
    - Make the LANG variable, which up to now has represented regional
      formats, denote the display language instead (LP: #877610).
  * debian/patches/0010-set-language.patch:
    - If the Language or FormatsLocale property is not yet set when
      queried, respond with a sensible, dynamically generated fallback
      value.
    - Code added for migrating ~/.profile environment settings to
      ~/.pam_environment.
    - Don't alter any settings if SetLanguage is called from a language
      chooser on the greeter and /home is encrypted or not yet mounted.
    - Misc. code refactoring.
  * debian/accountsservice.postinst:
    - Modify /etc/default/locale and /etc/environment due to a changed
      meaning of the LANG environment variable.

  [ Martin Pitt ]
  * debian/accountsservice.postinst: Only run the LANG migration when
    upgrading to this version. Also, slightly improve the call to grep.
  * debian/libaccountsservice0.symbols: Fix versions of symbols from
    0001-formats-locale-property.patch.
  * debian/libaccountsservice0.symbols: Add new symbols from 0.6.15-2ubuntu1.
  * debian/accountsservice.postinst: In the LANG migration, do not add all the
    variables to a file which doesn't define LANG, so that we don't repeat
    them in /etc/environment when they are already in /etc/default/locale.
 -- Martin Pitt <email address hidden> Fri, 03 Feb 2012 06:42:19 +0100

Changed in accountsservice (Ubuntu Precise):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package language-selector - 0.63

---------------
language-selector (0.63) precise; urgency=low

  [ Martin Pitt ]
  * LanguageSelector/LanguageSelector.py: Fix KeyError crash on a nonexisting
    package. (LP: #843430)
  * language_support_pkgs.py: Add PackageKit WhatProvides() plugin for
    "locale()" search. Register it in setup.py.
  * LanguageSelector/LangCache.py, data/blacklist, setup.py: Drop support for
    data/blacklist, we haven't needed it for a long time, and don't intend to
    bring back this hack.
  * dbus_backend/ls-dbus-backend: Drop GetMissingPackages{,Async} methods. The
    current code isn't using them, and there is no need to have this in a
    D-BUS service. language_support_pkgs works fine as user in frontends.
  * Drop tests/test_dbus_backend.py. It only exercised above method, not the
    "set system-wide locale" bits.
  * Drop LanguageSelector/CheckLanguageSupport.py,
    dbus_backend/ls-dbus-backend: Not used by anything any more, obsoleted by
    language_support_pkgs.py.
  * LanguageSelector/LanguageSelector.py: Reimplement getMissingLangPacks()
    using language_support_pkgs.py. This gets rid of a lot of redundant and
    bad code.
  * Change code to use the LanguageSelector.LangCache namespace more
    explicitly, to make it easier to get rid of LangCache.
  * LanguageSelector/LangCache.py: Remove yet another copy of the pkg_depends
    evaluation logic, and some more dead code, rewrite using
    language_support_pkgs.
  * Drop tests.moved/. Unused, no automatic tests, not very useful.
  * LanguageSelector/LangCache.py, LanguageSelector/qt/QtLanguageSelector.py:
    Drop last remainders of the languageSupport* info, language-support-* were
    dropped several cycles ago.

  [ Gunnar Hjalmarsson ]
  * Make the LANG variable, which up to now has represented regional
    formats, denote the display language instead (LP: #877610).
  * Make use of accountsservice's FormatsLocale property and
    SetFormatsLocale method when selecting a user's regional formats.
    (LP: #866062)
  * When setting the system-wide language, ensure that the system
    regional formats locale is set in order to prevent surprise
    changes of the formats.
  * data/LanguageSelector.ui: Text about rebooting no longer
    applicable, so removed.
  * LanguageSelector/LocaleInfo.py: Encode @variant string in the
    translate() function as UTF-8 to avoid a UnicodeDecodeError if a
    locale with @variant is selected for regional formats.
  * debian/control: Bump accountsservice dependency to >= 0.6.15-2ubuntu3,
    to ensure that we have the new SetFormatsLocale method.
  * debian/control: Make im-switch a dependency of language-selector-gnome,
    since it's no longer a dependency of ibus (LP: #908762).
 -- Martin Pitt <email address hidden> Fri, 03 Feb 2012 07:01:24 +0100

Changed in language-selector (Ubuntu Precise):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers