Description of problem: Only the $LANG variable stored in /etc/sysconfig/i18n gets propagated into the user's X session in Fedora 8, but for some reason all of the other locale variables such as LC_COLLATE and LC_MESSAGES do not propagate. This is discovered by typing "locale" at the prompt inside gnome-terminal or KDE's konsole terminal. Since only the $LANG variable propagates, the rest of the variables get set automatically to the value of $LANG, so if you manually do a "exec bash -login" to try to force it to reprocess the lang.sh script that sets these variables at system startup time, it doesn't work because lang.sh bails if $LANG is set already. This suggests to me that something is hardcoding the value of LANG somewhere in the gdm startup sequence, when it should be sourcing the /etc/sysconfig/i18n file instead. I looked at the prefdm script and it seems to be ok, so it looks like it is something screwy going on in the X initscripts. Version-Release number of selected component (if applicable): xorg-x11-xinit-1.0.7-2.fc8 gdm-2.20.1-5.fc8 initscripts-8.60-1 How reproducible: 100% Steps to Reproduce: 1. Clean Fedora 8 installation with all defaults. 2. Install the /etc/sysconfig/i18n file that I am going to attach shortly. 3. Reboot the computer. 4. Boot into runlevel 5 using the default *dm which I believe is gdm 5. Log in as a regular user 6. Start a gnome-terminal from the "Applications" menu. 7. Type "locale" at the prompt Actual results: pts/1 mharris@hammer:~$ locale LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL= Expected results: LC_COLLATE and LC_MESSAGES should be set to the defaults I have set them in /etc/sysconfig/i18n as follows: LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE=C LC_MONETARY="en_US.UTF-8" LC_MESSAGES=en_CA.UTF-8 LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL= Here's what I've troubleshooted so far: Correct operation: Booting into runlevel 3 and logging in at the console, or booting to runlevel 5, switching to VT1 and logging in as root or non-root and running "locale", the locale variables are set correctly as expected. This shows that the lang.sh script is being sourced properly during login and everything is getting set up right. I compared the lang.sh found in Fedora 7 with the one in Fedora 8 and they are identical, so no changes there which could cause this problem. In Fedora 7, I was logging in as user "mharris", then running "startx" to initiate X. Since console logins appear to source the i18n variables correctly, it seems that it propagated correctly into my startx induced X session, as the variables were set correctly in Fedora 7. Additional info: Not yet sure if this problem occurs under "startx" in Fedora 8 or not, but I'm going to try that next as well. I'm also not sure if the problem occurs under a gdm X session in Fedora 7 (for comparison) as I didn't have an i18n file set up when I used gdm under Fedora 7. I can test that out also however if that would be useful. My .bash_profile .bashrc and other login related files are all stock Fedora 8 and unmodified so far, so no chance of interference from that. Also, I do not have any homemade .xinitrc or similar scripts set up. Just a pretty stock Fedora 8 installation with default config files, etc. I'm going to go try a "startx" session now to see how that goes.
Created attachment 252411 [details] i18n config file
Here's another test I just did: pts/5 mharris@hammer:~$ locale LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL= pts/5 mharris@hammer:~$ unset LANG pts/5 mharris@hammer:~$ exec bash -login pts/5 mharris@hammer:~$ locale LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE=C LC_MONETARY="en_US.UTF-8" LC_MESSAGES=en_CA.UTF-8 LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL= So, if LANG is unset when lang.sh is processed, the correct thing does actually happen. This implies to me that: - gdm based X startup is not happening within a login shell - /etc/sysconfig/i18n is not getting sourced manually (nor $HOME/i18n) - something somewhere is setting just the LANG environment variable, which causes later login shell processing of /etc/profile.d/lang.sh to occur with LANG set, causing all other settings in /etc/sysconfig/i18n to end up being ignored.
Ok, I've rebooted into runlevel 3, logged in as "mharris", ran startx, and opened up a terminal. The locale environment was properly propagated: pts/1 mharris@hammer:~$ locale LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE=C LC_MONETARY="en_US.UTF-8" LC_MESSAGES=en_CA.UTF-8 LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL= Looks like this is definitely a problem with gdm based X server startup somewhere along the line. grepping /etc/X11 didn't yield any obvious clues though. A quick ugly hack might be to hack Xsession (or the appropriate files for gdm/kdm if they still have their own local hacks) to have: unset LANG . /etc/profile.d/lang.sh although that'd only be a horrible hack workaround if it works.
I'm not sure if this is releated but there's "ugly hack" in /etc/gdm/locale.alias which is not real locale.alias (explained in file's comments). There are defined the languages one can choose from gdm's login screen. If I choose for example Finnish, the LC_* are set to fi_FI.UTF-8 without honoring /etc/sysconfig/i18n (the file says LANG is en_US.UTF-8). That makes also me believe somehow gdm doesn't undertand the locales except LANG.
Yeah, it looks like gdm is breaking OS standards. Not sure if the problem is also present under kdm or xdm, but I'll try those in the future as well.
The same problem is with user i18n setting in $HOME/.i18n file. It is ignored. This is very annoying as it is very useful to have for example english messages: LC_MESSAGES=en_US.UTF-8 but native language sorting LC_COLLATE=pl_PL.UTF-8 etc. It is much easier to find online help in english searching for english failure message than localized one. It should not be ignored at least when "System Default" language is chosen at login screen.
I also use LANG=en_US.UTF-8 for English texts, but locale like time, monetary, etc. have in Polish (by changing /etc/sysconfig/i18n). It worked up to FC6 (not tested in F7). Other locales seem to be taken from LANG and propagated to all started GUI application (so "LC_TIME=pl_PL.UTF-8 some-graphic-app" doesn't work). I'm using Gnome.
AFAIK this also still happens with rawhide.
Still not fixed! In my opinion it is a serious bug. Probably "severity:low" and "priority:low" bugs are ignored by Redhat people.
This should be fixed now. If it's not, I'll need to investigate. (Note I don't ignore severity:low and priority:low bugs. In fact, I ignore severity and priority entirely, since people frequently set their pet peeve bugs to "urgent")
In which package is it fixed? Is the package already available in Updates?
This bug is filed against rawhide. If it's a problem in F8 too then it'll need a separate fix there.
Well, the description says Fedora 8. And I can confirm the bug exists in F8. Could someone with the appropriate rights change the version info of this bug to 8 or should we file a new bug?
Should gdm still be respecting "$HOME/.i18n"?
not specifically. gdm runs the Xsession script which ensures that exactly one login shell is run (which runs /etc/profile) It may have some logic for ~/.i18n. not sure.
When is the fix going to show up? XDM and KDM respect my $HOME/.i18n (as GDM did in F7 and prior).
The guess the guilty file is: /etc/profile.d/lang.sh It used to be like this: ------------------------------------------------------------------------------ sourced=0 for langfile in /etc/sysconfig/i18n $HOME/.i18n ; do [ -f $langfile ] && . $langfile && sourced=1 done ------------------------------------------------------------------------------ Now it is like this: ------------------------------------------------------------------------------ sourced=0 if [ -n "$LANG" ]; then sourced=1 else for langfile in /etc/sysconfig/i18n $HOME/.i18n ; do [ -f $langfile ] && . $langfile && sourced=1 done fi ------------------------------------------------------------------------------
Oh yea, I talked to jensp about this on IRC. The bug report that mentions that change has notting saying "I've commited this change, but I bet it will break something". He jinxed us all. /etc/sysconfig/i18n and ~/.i18n should be loaded separated since we want the former to be a default and the latter to be an override.
It works like that. Because $HOME/.i18n is after /etc/sysconfig/i18n there, $HOME/.i18n overrides /etc/sysconfig/i18n.
Sorry guys. I was wrong about /etc/profile.d/lang.sh being the guilty file. (Or it could still be, but the older configuration does not make this bug go away.) I wasn't using F8 box at the time I wrote that comment about /etc/profile.d/lang.sh. Now I am. I tested with the older config, and it doesn't have any effect unfortunately.
X/gdm/gnome must be reading and setting locale stuff by itself. Whatever I test in /etc/profile.d/lang.sh does not have any effect at all. I even did this in /usr/sbin/gdm: LANG="fi_FI.UTF-8" LANGUAGE="fi_FI.UTF-8" export LANG export LANGUAGE exec /usr/sbin/gdm-binary "$@" $ cat /etc/sysconfig/i18n LANG="fi_FI.UTF-8" SYSFONT="latarcyrheb-sun16" LANGUAGE="en_GB.UTF-8:en_US.UTF-8:en.UTF-8" I ended up in a gnome session with en_GB.UTF-8 set to all locale variables, LANGUAGE being unset. $ env | grep LANG LANG=en_GB.UTF-8 GDM_LANG=en_GB.UTF-8 So X/gdm/gnome must be reading /etc/sysconfig/i18n by itself. It reads that LANGUAGE is en, and then overrides LANG with it... Also previously GDM_LANG was only set, if something else than the default language was being used. Now it is always set.
**** For Rawhide **** I can ack the thing Jarkko stated above: GDM doesnt respect /etc/sysconfig/i18n nor $HOME/.i18n. But... the GDM_LANG gets set on the new GDM Login screen. Reproduce it: Select a User to Login -> On the Bottom of the screen pops a "language" dropdown. If you choose the Language there, it's getting right. The "confusing" thingy. The "Set Language on System/Administration" turns useless if you dont choose the right language on GDM Login !!! This is imho a HIGH Priority Bug in Rawhide (because there will be a _lot_ of confused users), at final F9. imho... Greetz Andy
> Reproduce it: > Select a User to Login -> On the Bottom of the screen pops a "language" > dropdown. If you choose the Language there, it's getting right. > > The "confusing" thingy. The "Set Language on System/Administration" turns > useless if you dont choose the right language on GDM Login !!! This has *always* been this way. system-config-language sets the default language; users are free to choose a different one in GDM.
What I meant was that previously GDM_LANG was the variable which showed up only if the user picked a language from the dropdown. If it was around, it told that the default language had been overridden. Now it seems to be always present. Perhaps (and probably) this does not have any effect for the behavior in this bug (it might tell us something though), but it's just a thing I noticed. Perhaps Andy has saved his language selection. Then you don't get the system default language but your own GNOME session default language. GDM login screen follows the system language by default (it can be started with another language, but by default it follows the system default). GDM login screen also actually properly follows /etc/sysconfig/i18n. So this bug happens with GNOME session (perhaps with other environments as well - I haven't tested) - not with GDM login screen. If you create another user account, you should be getting the system default language by default. And if you then change the system default, your GNOME session will be in the new language accordingly. If you choose a language from the dropdown and then save that selection, you will always get GNOME in that language - unless you explicitly choose another language from the dropdown again. This bug is about: GNOME (at least - I don't know if others too) does not execute /etc/profile.d/lang.sh but perhaps reads /etc/sysconfig/i18n on its own and reads only $LANG from it - or GDM sends only $LANG to GNOME. GNOME reading /etc/sysconfig/i18n does not feel probable because that would mean Fedora patching GNOME to do that. The most probable cause for this weirdness is that GDM only sends $LANG to GNOME. If that is true, this happens with all environments. Also, then this bug is in GDM itself - not in the X initscripts. Another possibility is that GNOME does not read other variables than $LANG. (Then this does not happen with other desktop environments.) Perhaps this is a common GDM/GNOME bug from upstream and not about initscripts..? We should test if this happens with all desktop environments or only with GNOME. If it happens with GNOME only, GNOME has the bug. If it happens with all, it is either initscripts or GDM. Because I can't find anything from the scripts, my money is on GDM. :)
It's definitely not GNOME. I just tested this: 1) I logged out from the GNOME session started from GDM 2) I went to the console side, logged in there 3) I executed: startx -- :1 --> I got everything as configured in /etc/sysconfig/i18n So this is related to GDM. It is either GDM or some scripts related to GDM.
Now I installed xmd, ran telinit 3, started xdm... Logged in from the xdm login screen and... I got everything as configured in /etc/sysconfig/i18n - again. This must be a bug in gdm itself - coming from upstream. So, this bug should be reassigned to: gdm
I know this corrective comment is not necessary, but I can't resist correcting myself. :) I of course meant I installed xdm - xorg-x11-xdm to be precise. $ rpm -q --whatprovides xdm xorg-x11-xdm-1.1.6-2.fc8.x86_64 Anyways, clearly as this happens only with gdm, it is very unlikely that initscripts is responsible for this. I bet gdm has the bug. I could test by starting xdm with the exact same command that /etc/X11/prefdm uses though... But I would be very surprised if xdm started to behave differently then.
Okay... I tested that by setting XDM as DISPLAYMANAGER in /etc/sysconfig/desktop. The result: I got everything as configured in /etc/sysconfig/i18n - as expected. I also tested to run "gdm" manually from the command line. It does not have any effect weather gdm is started from /etc/X11/prefdm (inittab) or manually. --> This bug must be in gdm itself - coming from upstream. I think my tests show that initscripts is not the one to blame. There aren't any gdm specific scripts in the initscripts package even (judging from rpm -ql output). This bug should be reassigned to gdm because gdm must be the one with the bug. The bug in gdm might be something like... When the desktopt environment is started, only LANG is sent to the environment. Perhaps the environment is started with some kind of exec like call and only LANG is sent with the call...
Let me explain what's going on. lang.sh has something like... 1) if LANG isn't set, source /etc/sysconfig/i18n and ~/i18n 2) if GDM_LANG is set, force LANG to be GDM_LANG before bug 229102 it had 1) even if LANG is set, pull LANG from /etc/sysconfig/i18n and ~/i18n 2) if GDM_LANG is set, force LANG to be GDM_LANG gdm no longer sets GDM_LANG in addition to LANG. It used to set both. We can add that back if we really need to, but it doesn't offer a lot, so I'ld like to avoid it. What it should probably be is. 1) if LANG is set, save LANG to SAVED_LANG 2) source /etc/sysconfig/i18n and ~/.i18n 3) if SAVED_LANG is set, restore LANG from SAVED_LANG Also, lang.sh has this variable "sourced" which means "pass the LC_ variables set in /etc/sysconfig/i18n through to the session", but it sometimes gets set when /etc/sysconfig/i18n isn't sourced so there are no LC_ variables to pass through!
Created attachment 303357 [details] a potential fix This is a stab at it. I haven't tested it.
The problem with this is that GDM only sets $LANG, which means that other things set in /etc/sysconfig/i18n and ~/.i18n would still take effect (LC_MESSAGES, LC_COLLATE, etc.) and there would be no (simple) way for the user to override them for their login session.
isn't that what we want? hidden advanced features still working?
/etc/sysconfig/i18n sets global language and locale settings. The system (also GDM/GNOME) should follow those settings by default. This is how GNU/Linux should work. ~/.i18n overrides those settings (and possibly sets some more). This is also how GNU/Linux should work. GDM can override the LANG variable from /etc/sysconfig/i18n and ~/.i18n, but it really should not override the LC_* variables. If you don't like the idea of LC_* variables not being overridden, don't set any LC_* variables in /etc/sysconfig/i18n. This is what I think. The current behavior doesn't follow the general idea how the i18n stuff should work. At least I think so.
Created attachment 303519 [details] a better patch The previous patch had a bug where it would ignore LANG in i18n completely instead of using it as an overridable default.
http://git.fedorahosted.org/git/?p=initscripts.git;a=commit;h=37638eda01ac8743d6dbd85f1d699619571432a0 Will be in 8.71-1.
I'm not totally sure if it's a good or a bad thing to override the LC_* variables in general (when user chooses some language explicitly from the list), but one thing is sure (and I think we all think this way): GDM should not remove any settings (like the LC_* variables) coming from /etc/sysconfig/i18n and ~/.i18n by default (when no language is selected from the language dropdown or saved by the user). I must have been doing something wrong when I tested that the lang.sh script didn't have any effect. I'll test that again later - with the changes from that commit. I hope it behaves logically now. :)
It's better but not 100% correct. LC_* variables (and $LANGUAGE) are now passed to the session, but if I have e.g. LANG="fi_FI.UTF-8" and LANGUAGE="en_US.UTF-8:en.UTF-8" in /etc/sysconfig/i18n, GDM overrides $LANG to be "en_US.UTF-8" from the LANGUAGE variable. This is not correct. GDM should not override anything by default. (It should override when a language is explicitly selected from the list, but by default it should not change any i18n settings.) It is better, but not quite right.
> gdm no longer sets GDM_LANG in addition to LANG. gdm-2.20.3-1.fc8.x86_64 does. Either it does set it or a newer version does not anymore.
f9 gdm should work better in this respect. Actually the latest 2.20 of upstream may work better, too. I can try pushing that to testing. The gdm in f8 sets GDM_LANG, the one in f9 does not.
gdm-2.20.5-1.fc8 has been submitted as an update for Fedora 8
mind giving http://koji.fedoraproject.org/koji/buildinfo?buildID=47107 a try?
gdm-2.20.5-1.fc8 works, but one still needs the lang.sh patch to set the LC_* values, maybe initscripts should be updated as well?
I've patched /etc/profile.d/lang.sh according to http://git.fedorahosted.org/git/?p=initscripts.git;a=commit;h=37638eda01ac8743d6dbd85f1d699619571432a0 from comment #35. I've installed: $ rpm -q gdm gdm-2.20.5-1.fc8.x86_64 I went to runlevel 3 and back to 5 so that I get a "fresh start" for gdm. (I've noticed that otherwise it might remember previous settings like the i18n stuff.) At the moment I have this: $ cat /etc/sysconfig/i18n LANG="en_GB.UTF-8" SYSFONT="latarcyrheb-sun16" LC_CTYPE="fi_FI.UTF-8" LC_COLLATE="fi_FI.UTF-8" LC_NUMERIC="en_IE.UTF-8" LC_MONETARY="en_IE.UTF-8" I don't have any saved language preference for my GDM/GNOME session. So I should get the system default i18n settings, when I log in without choosing any language from the list. This is what is set after login: $ env | grep LANG LANG=en_GB.UTF-8 GDM_LANG=en_GB.UTF-8 $ locale LANG=en_GB.UTF-8 LC_CTYPE=fi_FI.UTF-8 LC_NUMERIC=en_IE.UTF-8 LC_TIME="en_GB.UTF-8" LC_COLLATE=fi_FI.UTF-8 LC_MONETARY=en_IE.UTF-8 LC_MESSAGES="en_GB.UTF-8" LC_PAPER="en_GB.UTF-8" LC_NAME="en_GB.UTF-8" LC_ADDRESS="en_GB.UTF-8" LC_TELEPHONE="en_GB.UTF-8" LC_MEASUREMENT="en_GB.UTF-8" LC_IDENTIFICATION="en_GB.UTF-8" LC_ALL= So yes, it is working logically now. First I thought "but it *does* set GDM_LANG", but hey - this is not F9. :) So this is normal I guess. If we really want to make GDM (and other login managers as well) behave totally logically, we should improve the lang.sh (and lang.csh) patch a little bit more. The 100 % correct way to behave would be to save all locale and language related variables (plus _XKB_CHARSET - all variables which the lang.sh script exports) before sourcing i18n configuration files. That way things like: # LC_MESSAGES="en_US.UTF-8" gdm ...would actually work. I bet that doesn't work at the moment, because lang.sh only "remembers" the LANG variable.
Created attachment 303769 [details] Handle all exportable variables This patch adds handling of all the variables (not only LANG) that the lang.sh script exports. The patch is against http://git.fedorahosted.org/git/?p=initscripts.git;a=commit;h=37638eda01ac8743d6dbd85f1d699619571432a0 from comment #35.
Uups. Sorry, the patch is not against that version from the git repository. :) It is against the version in F8 + saved_lang from that git commit...
It doesn't matter though. I created a new patch against that version from the git repository --> no changes to the actual patch.
Created attachment 303770 [details] Handle all exportable variables (cleaned version) I cleaned the patch a bit. This takes fewer lines and is perhaps more readable.
About the overriding... I think gdm should override LANG, LANGUAGE and LC_MESSAGES when the user selects a language from the list (or have saved the selection). Otherwise the user doesn't necessarily get the selected language in all cases. BUT notice: I think this functionality does not belong to the lang.sh script. gdm should do that by itself. Now that we have lang.sh respecting pre-existing variables (if you commit my patch of course :)), gdm can do the override. gdm should just unset LANGUAGE and LC_MESSAGES when it sets LANG in that case (not always - just when the user chooses a language from the list or has a saved language). It should be an easy change I think.
Created attachment 303782 [details] Handle all exportable variables (csh version) This patch adds handling of all the variables (not only LANG) that the lang.csh script exports. The patch is against http://git.fedorahosted.org/git/?p=initscripts.git;a=commit;h=37638eda01ac8743d6dbd85f1d699619571432a0 from comment #35.
I'm not sure I like this idea, if for no other reason than it really uglifies the scripts. What's the usage case for this? When would you want to set this in a way other than using ~/.i18n?
It would be possible to run the graphical environment in different language/locale than the system by setting (exporting) the variables before the display manager starts. Is it needed? Perhaps - perhaps not. But it would be possible. (I can imagine that sometimes people could want to run the system in English, but the graphical environment in the local language.) Setting the language from the language selection list could be handled by gdm. (Which would be the architecturally correct way.) If we think about logic... If we override LANG, we should override all the variables. That would be the most consistent behavior. Is this *really* needed? I don't know... But handling all the pre-existing variables we export would be the most logical thing to do.
Actually we can't do what I suggested in the patches. I don't like my idea either. :) The lang.sh and lang.csh scripts are part of what gets run when /etc/profile is executed. I believe /etc/profile should reset all environment variables to the values configured in system configuration. For example, if LANG is "en_US.UTF-8" and I've changed it to, let's say "fi_FI.UTF-8", and I then execute /etc/profile... The correct behavior then is, that LANG resets back to the original value - "en_US.UTF-8". I think we should replace the saved_lang idea with GDM_LANG. We should not support any pre-existing values for the variables we export. GDM_LANG is not one of those, so if GDM_LANG would be set, it would be okay to override LANG with it (and also unset LANGUAGE and LC_MESSAGES).
Actually we broke the fix for bug #229102. :) The saved_lang idea only saves $LANG. Other passed variables a overridden from i18n configuration. The only way that could be avoided would be to use my patches. I just wonder if it's correct if /etc/profile does not reset all variables. Either way, something breaks. :)
When passing locale and language variables between systems, the correct behavior is to either use the local or the remote settings - not to mix them! 1) My patches would mix them (if the ssh client side sends some new variables, they would be exported to the session causing e.g. situations where we have latin and unicode variables existing at the same time). --> Not good. 2) The current fix (the commit) also mixes them (if the local side has other settings also than LANG, and the client side then sends different encoding in $LANG). --> Not good. 3) The previous way didn't mix them. But GNOME didn't start with all i18n settings, and also I'm not sure if the passed variables through ssh were exported properly to the session. --> Buggy and not perfect. How to make this work correctly? Well... To begin with, the exporting should always happen I think - so that we can be sure the variables are actually exported to the session (and not just to the currently running application like gdm or bash). Secondly... We should either use only values from the i18n configuration or only from the pre-existing settings (like coming through ssh). How to actually properly accomplish this, I'm not sure... The problem with gdm is that it sets LANG by itself but only LANG... Could this work if gdm would only set GDM_LANG and leave the actual environment stuff to /etc/profile scripts..? The other solution which comes to mind is that gdm sources the i18n configuration files by itself... (And /etc/profile would then just run an export for them.)
I think this is the only way to properly solve this: * If (and only if) LANG is _not_ set, source /etc/sysconfig/i18n and ~/.i18n. * Does sshd export the variables it receives from the client? If not, we need to execute the exporting part of the script every time. If it does, we naturally only need to execute the exports when the i18n configuration files are sourced by the lang.sh/lang.csh script. --> gdm should not set LANG if it does not source /etc/sysconfig/i18n and ~/.i18n by itself. Either make gdm to source the i18n configuration files (and either export the variables already by gdm or later in the lang.sh/lang.csh script) or add GDM_LANG back and _do not set LANG_ in gdm - or somehow make sure the i18n settings are already exported when gdm login is executed (and handle it so that LANG gets exported if it is changed by gdm). If we don't change the system drastically, this would mean in practise, that gdm would only set GDM_LANG (not LANG at all) if it changes the default LANG value. Then the lang.sh/lang.csh script would know to change LANG to be GDM_LANG.
Actually this can of course be done even if gdm sets LANG - if it also sets GDM_LANG. (We can sourse i18n conf always if GDM_LANG is set.) The other solution could be to somehow determine that we are on a ssh session (perhaps some variable tells us this).
I think this can be closed - the X case is certainly handled.
Created attachment 304029 [details] Handle the SSH case Now I got it! This way it works properly. Both the X and the SSH case are handled correctly doing it this way, I think - and no need for GDM_LANG. Everybody's happy. :) I know the SSH case is a separate issue, but because the fix for this bug affected the SSH case bug, here is the fix for that effect. This patch is against the latest version from the git repo.
Created attachment 304034 [details] Handle the SSH case (csh version) Here is the csh version. This patch is against the latest version from the git repo.
I'm sorry for sending so many comments to this bug! This should be my last comment now. Tested the lang.sh patch (lang.csh is identical in its logic): Works correctly with X and with SSH. Please commit the patches to the git repo. Thank you.
At this point, probably not until after F9 final.
I did something different, but similar. http://git.fedorahosted.org/git/?p=initscripts.git;a=commit;h=39d1593aad51817f5b64a9e95f2144dfaa018ebb If LANG is set, read the user customizations (and keep that LANG). If LANG is not set, read the system and user customizations. Not intending to touch this again for a while. :) Will be in 8.74-1.
Sorry! One more comment coming up. :) That is actually a very elegant solution. I really like it! :) With X: It supports all the default system and user settings when no language is selected. Then when a language is selected, it actually sets the whole environment to the selected value (you get what you ask by default, which is logical). But still if you want to use some LC_* settings with all languages, you can - by defining them in ~/.i18n. --> It does by default the expected thing, still being very customizable. With SSH: It supports all the settings the client sends. This is a very good thing because this way the character sets won't get mixed. And again, still, there can also be local overrides, if this is what the user wants - using ~/.i18n. (Remember here also that very often the home directory is shared between multiple hosts. Supporting also ~/.i18n is sometimes useful.) --> It does by default the expected thing, still being very customizable. Please *don't* touch this for a while. :) This 8.74-1 is coming to F9? It might be a good idea to release this change as a F8 update too. That was requested by Christian Menzel in comment #44. Anyway, thanks! I really like the solution.
gdm-2.20.5-1.fc8 has been pushed to the Fedora 8 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update gdm'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-3389
"If problems still persist, please make note of it in this bug report." The lang.sh/lang.csh script is ok now (I'm using the latest from the git repo), but now gdm (at least gdm-2.20.5-1.fc8) has a bug: It sets LANG always (and this F8 version also sets GDM_LANG, but that doesn't matter anymore + F9 version doesn't set it anymore anyway). It really should not do that when there is no language selected from the list or the user has not saved a preference. Now that it always sets LANG, lang.sh/lang.chs thinks that the locale was overridden by gdm. --> /etc/sysconfig/i18n is not sourced when it should be.
I think GDM should make sure LANG is always set since having it unset provides a less than working experience. lang.sh should account for that.
The problem with gdm now is that it removes everything else but leaves LANG. gdm itself has the environment properly set (environment is in place when gdm is started), but it doesn't pass it to the X session. Perhaps the solution is to make gdm to pass the environment to the X session. At least LANG, LC_*, LANGUAGE and LINGUAS should be passed to the X session. Either only them all just the whole environment.
gdm-2.20.5-1.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
requested by Jens Petersen (#27995)
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. 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 WONTFIX if it remains open with a Fedora 'version' of '8'. 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 prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
My bugzilla bug emails were vanishing into a void due to a .procmailrc glitch so I reviewed this bug just now. Due to the problem I initially reported, I switched to using "startx" as a temporary workaround, but just kept using it like that. Unfortunately I never noticed the progress made on this issue above so never tried to test any of it. My bad. ;) Glad to see the issue was tackled and presumably resolved in erratum and rawhide et al. I'm currently using CentOS 5 with no easy way to test current Fedora releases for my originally reported issue, so I'll assume it has been resolved and when I get a chance to bang on a newer release in the future I'll check it out. Thanks for giving attention to this issue guys!
Well... :) One thing is clear in my opinion: initscripts handles this correctly. I think there's no bug in initscripts regarding this. The lang.sh/lang.csh handles this in a general and correct way IMO. If you find this isn't still working as it should, I think no bugs should be applied (or this one reopened) against initscripts. Instead, in such case IMO it's a bug in the actual application... Which means in practise: If you think this still isn't working as it should, you should file a new bug against gdm because then it's gdm which doesn't work like you think it should. :) Regarding gdm... It depends on how you see its language selection I guess (what the selection is actually about; if it's about selecting LC_MESSAGES or about selecting full locale). If the gdm's language selection is seen as full locale selection, gdm behaves correctly when it resets the /etc/sysconfig/i18n locale settings by resetting env and then setting its own locale settings - in practise, LANG. (Btw. If the language selection is actually about full localization, perhaps it should use the term locale or similar in the UI instead of language...). Also... The current GDM doesn't have a "default system language/locale" selection anymore like it used to, so it doesn't have to support the system locale settings (if the selection is seen as full locale selection instead of just language (LC_MESSAGES)). If you think it's not good that way, perhaps some kind of feature request should be filed for gdm... I don't know as this all depends on how you even see gdm should work... But the general solution at initscripts is IMO correct and that shouldn't be touched again. :)
I filed the bug originally against xorg-x11-xinit as that initially seemed where the problem was. After exporing the issue briefly it was determined to be a problem caused by gdm. All I personally care about, is the original problem that I filed. Feel free to file your own bug report against the package you feel most appropriate however if the issue you were personally having is unresolved.
This is how it is in F10: 1) The system in general respects /etc/sysconfig/i18n * If you log into a local text console, you get what you've set to /etc/sysconfig/i18n (~/.i18n overrides). * So if you run startx you naturally get /etc/sysconfig/i18n + ~/.i18n * This means also that the gdm login screen respects /etc/sysconfig/i18n (if you e.g. change LC_TIME, the clock at the login screen's bottom right corner gets localized accordingly). * ~/.i18n is always applied. This means that if you log in with ssh to the machine, ~/.i18n overrides the locale settings (with ssh, it's actually by default more complex: /etc/sysconfig/i18n + remote locale settings + ~/.i18n). --> In my opinion this is correct behavior. And I doubt anyone disagrees. 2) The new gdm does not have a feature like "default system language/locale". You always select the language (of course it suggests something by default which is your last selection or if you've never changed it, it's the system's LANG from /etc/sysconfig/i18n). * The gdm's language selection behaves actually like a locale selection. It's a fully localized language selection. (At least this is how it works, so I guess the GNOME/Fedora developers see it as such - because why would gdm be resetting the environment otherwise there. So it doesn't take anything from /etc/sysconfig/i18n as it sets the whole locale of the X session to the selected locale. Technically gdm does this by resetting the environment and then setting LANG. When LANG is already set, the system's profile scripts don't override it and possible other locale variables.) * Also here, ~/.i18n is always applied. So if you put e.g. LC_* variables there, they are propagated to your X session. --> Is this correct behavior? If you see the language selection as a fully localized language selection (= a locale selection), then I think it actually is correct. I personally think it's perhaps best the way it is now because: 1) The selection actually sets the language always to the selected value. (Imagine if you had LC_MESSAGES in the system's locale configuration. Then the gdm's language selection would not seem to work at all. That could be confusing.) 2) In some cases the fully localized language is really what you want. E.g. in big user environments you don't want the same LC_* settings to be applied to all X sessions. 3) ~/.i18n works so you can always do what you need. So I'd say all is good. But that's of course my opinion only. :)
(In reply to comment #76) > 3) ~/.i18n works so you can always do what you need. > > So I'd say all is good. But that's of course my opinion only. :) Unfortunately, this is NOT good. Current behaviour breaks the general principle "administrator sets system-wide preferences in /etc/, user can override in ~/.-files". With current buggy GDM approach it is impossible to set separate values for different locale categories globally. And GDM is the ONLY one which exibits such non-compliant behaviour.
IIRC what I meant was that the initscripts part of this is correct. GDM is the one to blame here. GDM resets the locale settings.