[Pkg-xfce-devel] Bug#734391: Bug#734391: lightdm: language selection of lightdm seems to be totally fucked up

Mon Jan 6 21:09:46 UTC 2014

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Mon, Jan 06, 2014 at 07:52:17PM +0100, Klaus Maria Pfeiffer wrote:
> Package: lightdm
> Version: 1.9.5-1
> Severity: normal
> 
> Dear Maintainer,
> 
> I know, that for that topic there are already some open bugs, but either they
> are quiet old, only handling one part of this problem or workaround is not
> complete.
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679386
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694588
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733261

So you open another one, so everyone is *really* confused? Also, I find
the tone pretty offensive, which doesn't exactly incitates me to anwer
the report at all.

> initially, lightdm is suggesting me a total wrong locale czech (would have
> awaited english due to LANGUAGE set), as you can see in
> http://kmp.or.at/~klaus/lightdm_locale/screenshot_lightdm_tc1_0_virgin_czech.png

Yes, incidentally it's the first one of the available list.
> 
> lets login. languages are mixed up, as you can see in
> http://kmp.or.at/~klaus/lightdm_locale/screenshot_lightdm_tc1_1_first_login.png
> 
> ;===
> tux at dodahos:~$ export | grep -i lang
> declare -x LANG="cs_CZ.utf8"
> declare -x LANGUAGE="en_US:en"
> 
> tux at dodahos:~$ cat .dmrc
> [Desktop]
> Language=cs_CZ.utf8
> Session=lightdm-xsession
> ;===

I don't see how they are mixed up. czech was selected in the menu, so
LANG is set to czech. *You* set LANGUAGE (which lightdm doesn't touch).
> 
> lets login with user bauersbua, but now with esperanto locale selected. same
> here, don't need a screenshot. :-)
> 
> ;===
> bauersbua at dodahos:~$ export | grep -i lang
> declare -x LANG="eo.utf8"
> declare -x LANGUAGE="en_US:en"
> 
> bauersbua at dodahos:~$ cat .dmrc
> [Desktop]
> Language=eo.utf8
> Session=lightdm-xsession
> ;===

Perfectly consistent here too.
> 
> so, lets init 6.
> 
> same as before, lightdm is suggesting me the wrong locale czech.

Again, first one in the list, until someone selects a new one.

> I give the
> username of bauersbua and language is switched to esperanto. fine.

Indeed. User local is loaded as soon as it can, so either when you enter
a matching username, or when selecting the user in the userlist if
enabled.

> now I delete
> username and give tux and language is still esperanto, would have awaited czech
> now. see screenshot
> http://kmp.or.at/~klaus/lightdm_locale/screenshot_lightdm_tc1_2_wrong_language.png

This one looks indeed weird.

> ok, lets select locale czech and login with tux. same as before. lets logout.

What do you mean “same as before”? LANG correctly set to cs_CZ and
LANGUAGE still set to en_US?

> give username bauersbua, ... (same as before as after init 6).
> 
> lets sum up this testcase #1:
> i system locale set to none
> - wrong locale suggested by lightdm
> - LANGUAGE not set correct by lightdm

I'm honestly not sure lightdm should touch LANGUAGE at all. Considering
it's a priority list, replacing the content by one locale doesn't look
like a good idea. Maybe adding the currently selected locale on top of
the list? If it's not set, then it's useless to set it to the same
content as LANG.

> - languages mixed up in xfce

Likely because of the LANG/LANGUAGE mismatch.

> - locale in lightdm looked up in .dmrc for user only first time.

Yup.
> 
> 
> 
> there's a workaround mentioned in http://bugs.debian.org/cgi-
> bin/bugreport.cgi?bug=679386#107, lets apply and test it as testcase #2.

I should indeed revisit that bug, but it's most likely fixed with recent
lightdm-gtk-greeter versions. Also the shell workarounds look pretty bad
so I won't even comment.
> 
> 
> ok, lets set system locale with dpkg-reconfigure locales to en_US.UTF-8.
> 
> ;===
> root at dodahos:~# locale -a
> C
> cs_CZ.utf8
> C.UTF-8
> de_AT.utf8
> en_US.utf8
> eo.utf8
> POSIX
> 
> root at dodahos:~# cat /etc/default/locale
> #  File generated by update-locale
> LANG=en_US.UTF-8
> LANGUAGE="en_US:en"
> ;===
> 
> lightdm's dmrc cache and .dmrc file of all users just deleted, as before.
> 
> this is testcase #3.

> 
> perfect, lightdm is suggesting me locale english. lets login tux with czech.
> LANG still overwritten.
> 
> ;===
> tux at dodahos:~$ cat .dmrc
> [Desktop]
> Language=cs_CZ.utf8
> Session=lightdm-xsession
> 
> tux at dodahos:~$ cat .xsessionrc
> export LANG=cs_CZ.UTF-8
> export LANGUAGE=cs_CZ:cs:en

When did you add a .xsessionrc? Because it'll set the variables for the
session completely outside of lightdm/lightdm-gtk-greeter.
> 
> tux at dodahos:~$ export | grep -i lang
> declare -x LANG="cs_CZ.utf8"
> declare -x LANGUAGE="cs_CZ:cs:en"
> ;===
> 
> now tux has .dmrc file, so, would await at next login lightdm is suggesting me
> czech. nooo. its suggesting me english. wtf? seems to be lightdm is ignoring
> users .dmrc file if LANG is set.

Before or after entering the login?
> 
> lets sum up this testcase #3:
> i system locale set to en_US.UTF-8
> + system locale suggested by lightdm
> + LANGUAGE set correct due to patch out of http://bugs.debian.org/cgi-
> bin/bugreport.cgi?bug=679386#107
> - LANG overwritten even if set in .xsessionrc

You're confused here, .xsessionrc is sourced after the login.

> + only one language in xfce
> - locale in lightdm never looked up in users .dmrc file due to system locale
> set.
> 
> 
> 
> lets go for testcase #4 and set back system locale to none, remove patch from
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679386#107 (as initial) and
> disable language selector in /etc/lightdm/lightdm-gtk-greeter.conf by setting
> show-language-selector=false.

> 
> we will do now the language selection by .xsessionrc.

Then you're completely outside of login process.
> so it really seems to me, that language handling is totally fucked up in
> lightdm.

Now, this is rude. If you have constructive comments, you're welcome to
do so. It's even quick to actually read the code you're bashing.

Considering there's like one piece of information here (the fact that
the locale is not re-loaded the second time a user login is entered),
I'm pretty much inclined to just ignore the rest.

> gre3tings, Klaus

Not really, actually.
- -- 
Yves-Alexis Perez
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBCgAGBQJSyxuWAAoJEG3bU/KmdcClee0H/inYsDi/DRyuGR136FJFwD6q
RKnD9P360AtWhcbky1DViVd7JaTQNoAKGHX0P1mKEpz2Bpjrmu/oa0EfQqo5MT57
kh3QQPEP2/pYGdcEU9oEPIk7Z2el73rTeZM5X6RafSgCIzWANyHMRFd2zgsTd5uj
J1EWLMkWBe8sMNVIGAmlzcd5fCiK9/Qh6cHL/s/4DGI7MX1GdvBUI+Dm1zb497Pd
PjxGlQk93DjLLn343v//DIiVutCRRLa/VaCAZ5ZgL0+7rnDhJLc0oUoQ/4m49KJq
ffYCdeTh/pmfCMYorCUuGLB701jbB2YIrswM3fdNh14pbmbIw4S02XfrdrcPjR0=
=hGxF
-----END PGP SIGNATURE-----