GDM version 2.4.0.11 / xfree 4.2.1 If gdm is run through the /etc/init.d/xdm script (configured to use gdm in /etc/rc.conf), it does ignore locale settings (set in /etc/profile for all users), and runs in English. If gdm is run from root prompt it runs perfectly using the system Language. *From 2.4.0.9 changelog: - DefaultLocale no longer exists, the system setup is used. This was really broken.
I have no locale settings in /etc/profile ? What is the problem here really ? I use standard locale i suppose, so locales is not really my thing. Can't you set your locale settings in gdm ?
No, I'm not talking about locale settings for gnome configured in gdm menu, i mean system settings. In /etc/profile: export LANG="es_ES@euro" export LANGUAGE="spanish" export LC_ALL="es_ES@euro" So every program that runs in my system and has an availible translation to spanish, runs in spanish, from 'ls' to 'Evolution'. The question here, is the only thing that doesn't use these locale settings is GDM (When started from /etc/init.d/xdm). And it does have an availible translation, because if I run it from command line it runs in spanish ("Bienvenido a GDM", "usuario", "contrase
No, I'm not talking about locale settings for gnome configured in gdm menu, i mean system settings. In /etc/profile: export LANG="es_ES@euro" export LANGUAGE="spanish" export LC_ALL="es_ES@euro" So every program that runs in my system and has an availible translation to spanish, runs in spanish, from 'ls' to 'Evolution'. The question here, is the only thing that doesn't use these locale settings is GDM (When started from /etc/init.d/xdm). And it does have an availible translation, because if I run it from command line it runs in spanish ("Bienvenido a GDM", "usuario", "contraseña", "sistema", etc...). I don't know if it's a bug in GDM, /etc/init.d/script or the way locales are set in Gentoo. Off course, it also could be my fault, but i read localisation documentation from www.gentoo.org, and i did it that way. And more people from the spanish forum is having the same problem i have.
Hi folks, I can confirm this bug, which is somewhat important for i18n users. I've been studying it and this is what I found: The reason for this bug is a small hack done to the gdm ebuild, which fixed bug #5598. Basically, GDM should be run from a script (/usr/bin/gdm), which source /etc/profile and then call /usr/bin/gdm-binary (the ``real thing''). But one problem is that the stop() function in /etc/init.d/xdm tries to stop /usr/bin/gdm, and it should stop the binary instead. So the hack consists in deleting the script, and moving /usr/bin/gdm-binary to /usr/bin/gdm. This way, /etc/profile is no longer parsed, and things like what the reporter mentions start to happen. After a little testing, I came up with a solution that I'd rather discuss with other fellow developers before trying to commit anything. This is because, imo, the best solution to this bug is to make a slight correction to the /etc/init.d/xdm script, which is part of the highly attended x11-base/xfree package. Below, I'll attach a preliminary revision to the gdm package which: * Removes the previous fix for #5598 * Modifies the /etc/init.d/xdm script inside postinst(). It adds the following right before the call to `start-stop-daemon': [ -x /usr/bin/gdm-binary ] && myexe=${myexe/gdm/gdm-binary} Please test it if possible. foser, what do you think? should we modify the xdm.start file from x11-base/xfree? At the moment, I think this file could really use the following changes: * Include the above line, so start-stop-daemon use gdm-binary, not gdm. * Remove ``else retval=1'' from the stop() function, since the fact that the process isn't running (look at the if) isn't necessarily an error. In fact, every time I shut down my machine I see that stopping GDM is labeled as an error (the INT and KILL signals are previously sent to the gdm daemon). This is wrong. Thanks
Created attachment 5379 [details] gdm-2.4.0.11-r1.ebuild
Leonardo, you are right. I was having an error reported by xdm when trying to stop it using "xdm stop". I will try your patch
It looks like you got to the root of the problem, can't test it right now (have some pending downloads ;)). But the script as it is now will stop gdm if users have the gdm-binary around, even when they are really running xdm or kdm, thats behaviour we don't want (or am i overlooking something here ?). I guess you could check if a gdm process is running instead ( eg. existance of /var/run/gdm.pid ). On the retval thing i agree, i'm not sure of it's purpose anyway -> what does it mean when {x,g,k}dm refuses to stop, mostly it is not running at all so we got what we want. Besides that it fixes an esthetic problem ;) I'd say we shouldn't hack gdm to fix this problem, but should fix this script to do the right thing and have Azarah update it in the next xfree version. I'm adding Azarah as a CC, so he can have a look at this too.
The statement <myexe=${myexe/gdm/gdm-binary}> only replace gdm with gdm-binary in the 'myexe' variable if it contains the string 'gdm' in the first place, so a person using [xk]dm shouldn't be affected by this. As for the ebuild hack I propose, I think the right thing is to change /etc/init.d/xdm too, but my concern is that someone who has xfree already installed and emerge gdm, would need to re-emerge xfree (or at least run the ebuild's postinst() function). So letting the gdm ebuild modify the xdm script would avoid that. Granted, it doesn't look very clean... It's not that big of a deal anyway.
I cannot see a difference, as it will then still run the binary, and not the wrapper. Better fix would be to source /etc/profile, and not /etc/profile.env in /etc/init.d/xdm.
It wouldn't make a difference if we keep the hack that moves /usr/bin/gdm-binary to /usr/bin/gdm, yes. I'm convinced the solution shouldn't be inside the gdm ebuild, and I thought about sourcing /etc/profile instead of /etc/profile.env in /etc/init.d/xdm too, but I've tried that and it doesn't work (the environment doesn't last long enough, I guess). Maybe we can source /etc/profile from /etc/X11/startDM.sh instead. That works and it should close this bug.
Yes, sorry, should be done in startDM.sh rather. As for the hack ... its not good practice in my opinion to have whatever you start as daemon start the actual deamon by another name. Ill see to putting a tempory hack in gdm ebuild to fixup startDM.sh.
Ok, should be fixed in gdm-2.4.0.11-r1. Also did required fix in xfree. Please try this new gdm without remerging xfree to see if it will fix.
And ?
This seems to be fixed with the new startDM.sh script. Thanks. Closing
I have tried this new ebuild, and it didn't fix the problem.
Oops, there was a small mistake in the ebuild. Please sync your tree and try again.
Thanks Leonardo, blonde moment there =)
It Works :) !!!! Thank you :)!!!
*** Bug 11766 has been marked as a duplicate of this bug. ***
You should put all environment things in /etc/env.d and only source /etc/profile.env from startDM.sh for the $10000 prize
