Tails

#2 Updated by alant 2014-09-14 10:07:33

Alternatively, gnome-control-center sets locale through DBus on the system bus: org.freedesktop.locale1 /org/freedesktop/locale1 SetLocale.

#5 Updated by alant 2014-09-15 14:23:31

> But still, the major question remains IMO: how does the standard GDM greeter set the locale? IMO, we should just do the same.

As far as I found, it doesn’t anymore set the locale.

#8 Updated by intrigeri 2014-09-22 15:05:42

alant wrote:
> As far as I found, it doesn’t anymore set the locale.

So the locale is set by gnome-control-center once its run by the session manager? I’m kinda surprised, as for the correct locale environment to be set, it must be done in a process that’s a parent of the entire session.

> […] which looks like a bug in grep_n_set

I’ve looked at the code, and it seems correct, but I may be missing something.

> Anyway the right solution seems to set locale through DBus on the system bus: org.freedesktop.locale1 /org/freedesktop/locale1 SetLocale.

Agreed, if that’s how locales are initialized in a non-Tails GNOME session.

#9 Updated by intrigeri 2014-09-22 15:28:22

intrigeri wrote:
> > […] which looks like a bug in grep_n_set
>
> I’ve looked at the code, and it seems correct, but I may be missing something.

Ah, no, indeed it’s completely buggy: the vague grep -qs "$1" "$2" check will return true, as our .xsessionrc contains the string TAILS_WIKI_SUPPORTED_LANGUAGES, which contains the string “LANG”. So, grep_n_set switches to replacement mode (as opposed to addition mode). This would be fixed by anchoring the grep regexp to the beginning or a line (with whitespace, potentially), e.g. grep -qs "^\s*$1" "$2" or similar. However, one needs to check for each other usage of this function, to see if a stricter regexp breaks anything else.

#11 Updated by alant 2014-09-23 05:39:05

intrigeri wrote:
> alant wrote:
> > As far as I found, it doesn’t anymore set the locale.
>
> So the locale is set by gnome-control-center once its run by the session manager? I’m kinda surprised, as for the correct locale environment to be set, it must be done in a process that’s a parent of the entire session.

As far as I understand, gdm doesn’t take care of that anymore (I didn’t find any code to setup locale in gdm). I’ll investigate gnome-sesson.

> > Anyway the right solution seems to set locale through DBus on the system bus: org.freedesktop.locale1 /org/freedesktop/locale1 SetLocale.
>
> Agreed, if that’s how locales are initialized in a non-Tails GNOME session.

I tried to boot tails jessie, comment the line modifying .xsessionrc and change org.freedesktop.locale1.Locale with gdbus. It’s changed but the locale not applied in the session so it’s not the solution.

#14 Updated by intrigeri 2014-10-02 09:41:20

alant wrote:
> GDM seems to handle $LANG for the session in function build_launch_environment of daemon/gdm-launch-environment.c. If I understand well it looks for $LANG and other variables in /etc/locale.conf but setting this don’t work either.

Well, this function also sets RUNNING_UNDER_GDM to true, so I doubt it’s used to set up the (non-GDM) regular user GNOME session.

#15 Updated by intrigeri 2014-10-02 10:14:10

After reading https://help.gnome.org/admin/gdm/stable/configuration.html.en#userconfig, I’ve tried editing .dmrc in PostLogin/Default. The configured language isn’t applied. I guess that this file is loaded earlier, to set the user’s default language.

#16 Updated by intrigeri 2014-10-02 16:02:22

Regardless of what language I choose in the Greeter, I see in the logs (language.py):

__apply_locale: Setting session language to en_US.UTF-8

Some more debugging shows that self._locale is always en_US in __apply_locale. That’s a first bug, I think. I’ve not looked at it in more details. Alan, now that we have a first lead, are you interested in having a closer look?

Then, I also see that in the logs:

AccountsService-WARNING **: SetLanguage call failed: GDBus.Error:org.freedesktop.Accounts.Error.PermissionDenied: Not authorized

It seems that we have a second bug here, and even if __apply_locale was fixed, it might be that the correct locale could not be applied. We ship what looks very much like correct permissions to me in org.boum.tails.accounts.pkla: I checked in data/org.freedesktop.Accounts.User.xml the permission name, and tried with ResultAny=yes as well; but pkcheck seems to agree that our greeter’s process is not allowed to run this action. I’ve also tried setting the same permissions on /etc/polkit-1/localauthority that I have on my system, still same results. polkitd is started with --no-debug, it would be great to enable its debug output to understand better what’s happening.

#17 Updated by alant 2014-10-08 03:09:28

> Regardless of what language I choose in the Greeter, I see in the logs (language.py):
>
> __apply_locale: Setting session language to en_US.UTF-8
>
> Some more debugging shows that self._locale is always en_US in __apply_locale.

You mean even after choosing another language than english, right?

> That’s a first bug, I think. I’ve not looked at it in more details. Alan, now that we have a first lead, are you interested in having a closer look?
>
Yes definately. Thanks for the finding.

> Then, I also see that in the logs:
>
> AccountsService-WARNING **: SetLanguage call failed: GDBus.Error:org.freedesktop.Accounts.Error.PermissionDenied: Not authorized
>
> It seems that we have a second bug here, and even if __apply_locale was fixed, it might be that the correct locale could not be applied. We ship what looks very much like correct permissions to me in org.boum.tails.accounts.pkla: I checked in data/org.freedesktop.Accounts.User.xml the permission name, and tried with ResultAny=yes as well; but pkcheck seems to agree that our greeter’s process is not allowed to run this action. I’ve also tried setting the same permissions on /etc/polkit-1/localauthority that I have on my system, still same results. polkitd is started with --no-debug, it would be great to enable its debug output to understand better what’s happening.

Oh annoying… I could have a quick look but I’m not an expert of policykit. Would you loke to try again once the 1st bug is fixed

#19 Updated by intrigeri 2014-10-08 03:33:16

>> Regardless of what language I choose in the Greeter, I see in the logs (language.py):
>>
>> __apply_locale: Setting session language to en_US.UTF-8
>>
>> Some more debugging shows that self._locale is always en_US in __apply_locale.

> You mean even after choosing another language than english, right?

Right.

> Oh annoying… I could have a quick look but I’m not an expert of policykit.
> Would you loke to try again once the 1st bug is fixed

I’m no expert in that field either, but sure, I can have a closer look.

#20 Updated by intrigeri 2014-10-08 03:35:49

> Please find clarifications below.

Thanks!

#21 Updated by intrigeri 2014-11-07 10:58:36

Another lead (that shouldn’t prevent us from finding the bug highlighted above, that’s most likely in our own code) would be to use systemd’s localed:

• http://www.freedesktop.org/wiki/Software/systemd/localed/
• localectl(1)
• systemd-localed(8)

#23 Updated by intrigeri 2015-01-16 13:30:32

The feature/jessie-localectl branch migrates most of our locale and keyboard settings to localectl. Quickly tested in a live Tails/Jessie, but that’s all.

Not looked at the bug I’ve reported above, that Alan can’t reproduced, yet.