SetLanguage(): Write ~/.pam_environment instead of ~/.profile
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.
Changed in accountsservice (Ubuntu): | |
status: | New → Triaged |
importance: | Undecided → Medium |
Gunnar Hjalmarsson (gunnarhj) wrote : | #1 |
Gunnar Hjalmarsson (gunnarhj) wrote : | #2 |
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 : | #3 |
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.
Martin Pitt (pitti) wrote : Re: [Bug 866062] Re: SetLanguage(): Write ~/.pam_environment instead of ~/.profile | #4 |
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 : | #5 |
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 : | #6 |
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 : | #7 |
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 |
Changed in accountsservice (Ubuntu Precise): | |
status: | In Progress → Fix Committed |
Changed in language-selector (Ubuntu Precise): | |
status: | New → Fix Committed |
Launchpad Janitor (janitor) wrote : | #8 |
This bug was fixed in the package accountsservice - 0.6.15-2ubuntu3
---------------
accountsservice (0.6.15-2ubuntu3) precise; urgency=low
[ Gunnar Hjalmarsson ]
* debian/
debian/
- Addition of FormatsLocale property and SetFormatsLocale method.
* debian/
- Make SetLanguage() and SetFormatsLocale() write to
~
- Make the LANG variable, which up to now has represented regional
formats, denote the display language instead (LP: #877610).
* debian/
- 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
~
- 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/
- Modify /etc/default/locale and /etc/environment due to a changed
meaning of the LANG environment variable.
[ Martin Pitt ]
* debian/
upgrading to this version. Also, slightly improve the call to grep.
* debian/
0001-
* debian/
* debian/
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/
-- 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 : | #9 |
This bug was fixed in the package language-selector - 0.63
---------------
language-selector (0.63) precise; urgency=low
[ Martin Pitt ]
* LanguageSelecto
package. (LP: #843430)
* language_
"locale()" search. Register it in setup.py.
* LanguageSelecto
data/blacklist, we haven't needed it for a long time, and don't intend to
bring back this hack.
* dbus_backend/
current code isn't using them, and there is no need to have this in a
D-BUS service. language_
* Drop tests/test_
"set system-wide locale" bits.
* Drop LanguageSelecto
dbus_
language_
* LanguageSelecto
using language_
bad code.
* Change code to use the LanguageSelecto
explicitly, to make it easier to get rid of LangCache.
* LanguageSelecto
evaluation logic, and some more dead code, rewrite using
language_
* Drop tests.moved/. Unused, no automatic tests, not very useful.
* LanguageSelecto
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
SetFormatsL
(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/LanguageSe
applicable, so removed.
* LanguageSelecto
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-
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 |
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.