-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Control: clone 735265 -2
Control: retitle -2 don't set locale if no dmrc and no selection is made
On Wed, Jan 15, 2014 at 01:07:22PM +0900, Olaf Meeuwissen wrote:
> Yves-Alexis Perez writes:
>
> > Note: I'm replying to both bugs at once because they look quite the
> > same. I'm not merging them right now because that's not completely sure
> > either.
> >
> > On Tue, Jan 14, 2014 at 12:40:01PM +0900, Olaf Meeuwissen wrote:
> >> Package: lightdm
> >> Version: 1.8.5-3
> >> Severity: normal
> >>
> >> Dear Maintainer,
> >>
> >> I have seen #690899, #691446 and #733261 but feel that my issue is not
> >> quite the same. Hence a separate bug report.
> >>
> >> I have a few locale tweaks in my ~/.xsessionrc (following comments found
> >> in /etc/X11/Xsession.d/40x11-common_xsessionrc). The relevant bit of my
> >> customizations:
> >>
> >> export LANG=ja_JP.UTF-8
> >> export LC_MESSAGES=en_GB.UTF-8
> >> export LANGUAGE=${LC_MESSAGES}
> >>
> >> This has been working great for me for several years. After the recent
> >> upgrade of lightdm (from 1.6.3-1) the LANG setting got clobbered to the
> >> first enabled locale, i.c. aa_DJ.UTF-8, whereas the system default is C.
> >>
> >> The system default locale and enabled locales have not been changed in
> >> a long time, nor has my .xsessionrc. What might have played a role
> >> was me removing my ~/.dmrc at about the same point as the upgrade as
> >> part of a dot-file cleanup. Changing its Language setting to the same
> >> value as the LANG setting in my ~/.xsessionrc fixed things for me.
> >>
> >> I would expect the preselected locale for lightdm's locale selector to
> >> be the system default (or whatever is configured explicitly for that bit
> >> of lightdm functionality), not whichever of the enabled locales is
> >> listed first in /etc/locale.gen.
> >
> > Yeah, that's not really optimal indeed. Actually that's the case only
> > for the first startup after boot, and before an user is selected.
>
> And that user has a ~/.dmrc with a language setting in it. If the user
> has no ~/.dmrc, then the first available locale is the default.
> Actually, if you enter a user name, move to the password field and then
> enter a *different* user's name (one who has no ~/.dmrc), that user will
> end up with the previous user's locale preference.
Indeed. I guess the correct behaviour would be to not set anything by
default (and reset to that behaviour in case a different username is
selected). This behavior is in lightdm-gtk-greeter by the way.
I'm cloning to a new bug to specifically address this, so we don't get
lost.
>
> >> The system default would then become
> >> the user's locale if a user does not have a ~/.dmrc file. Also, I would
> >> expect any tweaks in a user's ~/.xsessionrc to take effect/precedence
> >> and not be clobbered by any locale functionality courtesy of lightdm.
> >>
> >> That is to say, I would expect my LANG setting in ~/.xsessionrc to take
> >> precedence over whatever is (or ends up) in ~/.dmrc. If I have nothing
> >> in my ~/.xsessionrc, I expect to end up with what is configured in
> >> /etc/default/locale.
> >
> > Well that should be the case, actually.
>
> It is not. I created a new user account on my system and restarted
> lightdm. I gave that user the following ~/.xsessionrc
>
> $ cat .xsessionrc
> #! /bin/sh
>
> unset LC_ALL
> LANG=ja_JP.UTF-8
> LC_MESSAGES=en_GB.UTF-8
> LANGUAGE=${LC_MESSAGES}
>
> export LANG
> export LANGUAGE
> export LC_MESSAGES
>
> At the ligthdm login screen, I confirmed that the selected language was
> the first one in my system's /etc/locale.gen (aa_DJ.UTF-8) and selected
> bo_IN.UTF-8 before logging in.
>
> $ cat .dmrc
> [Desktop]
> Language=bo_IN.utf8
> Session=lightdm-xsession
>
> $ locale
> LANG=bo_IN.utf8
> LANGUAGE=en_GB.UTF-8
> LC_CTYPE="bo_IN.utf8"
> LC_NUMERIC="bo_IN.utf8"
> LC_TIME="bo_IN.utf8"
> LC_COLLATE="bo_IN.utf8"
> LC_MONETARY="bo_IN.utf8"
> LC_MESSAGES=en_GB.UTF-8
> LC_PAPER="bo_IN.utf8"
> LC_NAME="bo_IN.utf8"
> LC_ADDRESS="bo_IN.utf8"
> LC_TELEPHONE="bo_IN.utf8"
> LC_MEASUREMENT="bo_IN.utf8"
> LC_IDENTIFICATION="bo_IN.utf8"
> LC_ALL=
>
> As you can see, the LANG value is *not* as per ~/.xsessionrc which sets
> and exports ja_JP.UTF-8. However, the LC_MESSAGES and LANGUAGE
> variables *are* as per ~/.xsessionrc.
Well, again, I'm not responsible for .xsessionrc behavior. The way you
set it looks correct. It might make sense to check the content of
`locales' just before setting them in .xsessionrc (just put the call
on top of .xsessionrc).
But in any case, setting LANG in .xsessionrc doesn't make much sense
imho.
>
> Subsequent logins use ~/.dmrc to set the user's preceived language
> preference when you enter the user name and move to the password field.
> After login, the locale is as per above with the *wrong* LANG value.
>
> > The lightdm greeter will select a locale based on .dmrc if it exists,
> > but if the user chose another one in the menu, then it'll use that for
> > LANG.
>
> My "problem" is that I didn't select any language when I first
> encountered the problem. I just entered my user name and password at
> the login screen. That's all.
> Actually, I don't think I ever bothered selecting a language via that
> chooser interface.
The behavior changed in -4 to actually use what the user might have
selected in the language selector, instead of the previously used
language. Problem is that something is always selected by default.
>
> > Then, at login, /etc/X11/Xsession is run, which in turns run-parts
> > the scripts in /etc/X11/Xsession.d and especially
> > 40x11-common_xsessionrc, so whatever you put in .xsessionrc will take
> > precedence over previously set variables (and independantly of lightdm)
> >
> > I repeat, by the time .xsessionrc is parsed, lightdm or the greeter
> > doesn't have a chance to do anything to modify the locale anymore.
>
> If that is true, something else must be doing that.
Then try to debug using set -x or stuff like that. Sorry for not helping
here, but it's complicated enough just to manage those tricky bugs
inside the greeter.
> Problem is that /etc/X11/Xsession.d/40x11-common_xsessionrc advises you
> to do so.
>
> $ head /etc/X11/Xsession.d/40x11-common_xsessionrc
> # This file is sourced by Xsession(5), not executed.
>
> #Source user defined xsessionrc (locales and other environment variables)
> if [ -r "$USERXSESSIONRC" ]; then
> . "$USERXSESSIONRC"
> fi
No, it just says that you can do stuff there if you want. Nobody forces
you to do that, it's just a nice way to add stuff not already present,
or to correct stuff (like me switching only LC_MESSAGES).
Regards,
- --
Yves-Alexis Perez
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBCgAGBQJS1jKdAAoJEG3bU/KmdcClsroIAIrgBGaak6VpVOcUPL8ZxPoa
j9ee8gYWL0rTVYdeaufOYWDIyPiWRLDhg/POqMa1IEhci05xItLI1T+0mhoWE6rs
zuolMNLdFMx9rjL1MG3rCYqxW8kw+a/Xl9z+wfdMe0Eo520Ncwegndz6O0U1p+sO
BVKNPQX5boFD0oyH9rnrgf4flVWnK/ro3QqN6+qsmxOyTZK3iB3E8tWKKmubvyJK
bZlw2wxSS1sz0gAKK8NdPqFcDre2+R2bos9rHKddXIPMoow9aJDh2X5f9AyQGAaX
DC7RSecbOKwbfEUfAIxCjh1aCVbc/7Gv+UgBIDLmO5Og6rKfiYrDeihlTrfmhIU=
=FjZ9
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
