Description of problem: Since upgrading to f20, configuring ISO8859-1 encoding for the locale fails. It gets reset to en_US.utf8 on login to the XFCE session. Not sure whether this is really a xfce4-session bug, or a bug in some other pacakge, but that's my best guess. Version-Release number of selected component (if applicable): xfce4-session-4.10.1-3.fc20.x86_64 How reproducible: always Steps to Reproduce: 1. set LANG="en_US" in /etc/locale.conf 2. login to xfce 3. open some xfce4-terminal 4. echo $LANG Actual results: en_US.utf8 Expected results: en_US Additional info: login on virtual console works fine. Seems to be similar to https://bugzilla.redhat.com/show_bug.cgi?id=1001196 Setting LANG in .pam_environment and user_readenv=1 for pam_env.so in /etc/pam.d/lightdm doesn't help either. It gets overwritten in the same way. xfce4-terminal crashes when clicking the "Terminal" menu and then moving the mouse over "Set Encoding".
What does 'localectl' report? You are logging in via lightdm? or some other means? Does setting it to: en_US.iso88591 via localectl set-locale work?
(In reply to Kevin Fenzi from comment #1) > What does 'localectl' report? $ localectl System Locale: LANG=en_US VC Keymap: de-latin1-nodeadkeys X11 Layout: de X11 Model: pc105 X11 Variant: nodeadkeys > You are logging in via lightdm? or some other means? yes, lightdm-gtk executing ps and outputting $LANG from /etc/profile.d/lang.sh says that in the following contexts, LANG is set to en_US: 1. root 1169 0.0 0.2 269624 4424 ? SLsl 13:23 0:00 /usr/sbin/lightdm root 7559 2.1 0.5 165952 10356 tty1 Ss+ 14:28 0:00 \_ /usr/bin/X -background none :0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt1 -novtswitch root 7603 4.0 0.2 189756 4788 ? Sl 14:28 0:00 \_ lightdm --session-child 12 19 rtc 7614 0.0 0.0 115308 1452 ? Ss 14:28 0:00 \_ /bin/bash /etc/X11/xinit/Xsession startxfce4 rtc 7617 0.0 0.0 123480 1352 ? R 14:28 0:00 \_ ps auwwx --forest 2. root 1169 0.0 0.2 269624 4424 ? SLsl 13:23 0:00 /usr/sbin/lightdm root 7559 1.8 0.5 165952 10356 tty1 Ss+ 14:28 0:00 \_ /usr/bin/X -background none :0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt1 -novtswitch root 7603 2.6 0.2 189756 4788 ? Sl 14:28 0:00 \_ lightdm --session-child 12 19 rtc 7614 0.0 0.0 115308 1612 ? Ss 14:28 0:00 \_ /bin/bash /etc/X11/xinit/Xsession startxfce4 rtc 7631 0.0 0.0 123480 1356 ? R 14:28 0:00 \_ ps auwwx --forest 3. root 1169 0.0 0.2 269624 4424 ? SLsl 13:23 0:00 /usr/sbin/lightdm root 7559 2.0 0.5 168052 10512 tty1 Ss+ 14:28 0:00 \_ /usr/bin/X -background none :0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt1 -novtswitch root 7603 2.6 0.2 189756 4788 ? Sl 14:28 0:00 \_ lightdm --session-child 12 19 rtc 7614 2.0 0.0 117276 1664 ? Ss 14:28 0:00 \_ -/bin/bash -c startxfce4 rtc 7750 0.0 0.0 53304 584 ? Ss 14:28 0:00 \_ /usr/bin/ssh-agent /bin/sh -c exec -l /bin/bash -c "startxfce4" rtc 7761 0.0 0.0 123480 1352 ? R 14:28 0:00 \_ ps auwwx --forest But that in the following contexts it is set to en_US.utf8 1. rtc 7692 0.0 0.2 328320 4220 ? Sl 14:28 0:00 /usr/libexec/imsettings-daemon rtc 7801 0.0 0.0 113116 1444 ? S 14:28 0:00 \_ /bin/bash /usr/libexec/xinputinfo.sh /etc/X11/xinit/xinput.d/none.conf rtc 7805 0.0 0.0 123508 1432 ? R 14:28 0:00 \_ ps auwwx --forest 2. rtc 7692 0.0 0.2 328320 4368 ? Sl 14:28 0:00 /usr/libexec/imsettings-daemon rtc 7832 0.0 0.0 113116 1444 ? S 14:28 0:00 \_ /bin/bash /usr/libexec/xinputinfo.sh /etc/X11/xinit/xinput.d/none.conf rtc 7835 0.0 0.0 123508 1428 ? R 14:28 0:00 \_ ps auwwx --forest 3. (after manually opening xfce4-terminal) rtc 7783 3.6 0.6 531684 13872 ? Sl 14:28 0:00 xfce4-panel rtc 7887 0.6 0.4 433376 9388 ? Sl 14:28 0:00 \_ /usr/lib64/xfce4/panel/wrapper /usr/lib64/xfce4/panel/plugins/libactions.so 3 25165859 actions Action Buttons Log out, rtc 7893 1.0 0.4 433376 9392 ? Sl 14:28 0:00 \_ /usr/lib64/xfce4/panel/wrapper /usr/lib64/xfce4/panel/plugins/libactions.so 13 25165860 actions Action Buttons Log out, rtc 7894 0.6 0.4 428860 9268 ? Sl 14:28 0:00 \_ /usr/lib64/xfce4/panel/wrapper /usr/lib64/xfce4/panel/plugins/libthunar-tpa.so 16 25165865 thunar-tpa Trash Applet Disp rtc 7897 0.3 0.3 275088 7452 ? S 14:28 0:00 \_ /usr/lib64/xfce4/panel/wrapper /usr/lib64/xfce4/panel/plugins/libsystray.so 11 25165866 systray Notification Area Area rtc 7970 0.0 0.8 582184 16428 ? Sl 14:28 0:00 \_ xfce4-terminal rtc 7974 0.0 0.0 8448 716 ? S 14:28 0:00 \_ gnome-pty-helper rtc 7975 0.0 0.1 116516 3068 pts/0 Ss+ 14:28 0:00 \_ bash rtc 7999 0.0 0.0 123508 1436 pts/0 R+ 14:28 0:00 \_ ps auwwx --forest > Does setting it to: en_US.iso88591 via localectl set-locale work? I can't even set it: $ sudo localectl set-locale en_US.iso88591 [sudo] password for rtc: Failed to issue method call: Invalid argument So I can't tell whether it would work after setting.
(In reply to Peter Backes from comment #2) > I can't even set it: > > $ sudo localectl set-locale en_US.iso88591 > [sudo] password for rtc: > Failed to issue method call: Invalid argument > > So I can't tell whether it would work after setting. Ok, bug 974039. I had to sudo localectl set-locale LANG=en_US.iso88591 It doesn't change anything, however. LANG still gets reset to en_US.utf8 on login.
FYI, tried sudo yum downgrade http://kojipkgs.fedoraproject.org//packages/xfce4-session/4.10.1/2.fc20/x86_64/xfce4-session-4.10.1-2.fc20.x86_64.rpm http://kojipkgs.fedoraproject.org//packages/xfce4-session/4.10.1/2.fc20/x86_64/xfce4-session-engines-4.10.1-2.fc20.x86_64.rpm but that didn't help. So probably not a bug in xfce4-session itself. Also tried adding LANG=en_US to kernel command line. Didn't do the trick either. Note that neither xfce4-panel, nor xfce4 nor /usr/libexec/imsettings-daemon are children of xfce4-session according to ps auwwx --forest. The observations described above suggest that those are the processees that get LANG=en_US.utf8.
Adding Adam here for comment. He's dug around in the corners of the locale handling stuff and might at least have an idea where to go from here. Any ideas?
I'm afraid not, I was focusing more on keyboard layout stuff than locale configuration. Obvious thoughts are 'does it happen for a clean user account?' and 'does it happen if you use GDM?'
(In reply to Adam Williamson from comment #6) > Obvious thoughts are 'does it happen for a clean user account?' and 'does it > happen if you use GDM?' It doesn't happen for a clean user account. Found the cause: /var/lib/AccountsService/users/$USER contained the line Language=en_US.utf8 Why is AccountsService storing user information there in the first place? I'd assume such config belongs so $HOME
Moving to accountsservice for comment.
It seems to be a one-time issue on upgrade with my rather uncommon setup... If nobody else observed the problem, feel free to close as WORKSFORME...
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.