Bug 339182 – terminals do not display lithuanian letters when session loaded "startx"

• Product: Gentoo Linux
• Status: RESOLVED TEST-REQUEST

[Description Motiejus Jakštys 2010-09-30 00:02:11 UTC]

If I load startx (exec ck-launch-session dbus-launch openbox-session) and open any terminal in openbox and try to type in Lithuanian letters, I get question marks (as well as I can't see already typed letters).
If I load *different kind of* terminal from the first terminal (say, first - lxterminal, second - gnome-terminal), then the letters are fine.
If I start openbox from GDM, letters are fine at once.

Reproducible: Always

Steps to Reproduce:
1. startx openbox
2. setxkbmap lt
3. start lxterminal/gnome-terminal/roxterm
4. type in 'ą' (1 above qwerty's 'q').
Actual Results:  
Types '?'

Expected Results:  
Should type 'ą'

It stopped working when I emerged openrc and merged etc configuration files. I did some changes in /etc, although I don't know if they are related. I will attach my /etc/profile, I suspect something might be wrong with it (although source /etc/profile runs fine).

[Comment 1 Motiejus Jakštys 2010-09-30 00:05:00 UTC]

Created attachment 249011 [details]
manually modified /etc/profile after etc-update

Some things manually tuned, I suspect there can be problems with it's interpretation (locale settings, etc), although source /etc/profile runs fine.

[Comment 2 Motiejus Jakštys 2010-09-30 00:07:16 UTC]

Created attachment 249013 [details]
output of sh -c "set && env" in a working-letter terminal

[Comment 3 Motiejus Jakštys 2010-09-30 00:08:53 UTC]

Created attachment 249015 [details]
output of sh -c "set && env" in a NON-working-letter terminal

[Comment 4 Motiejus Jakštys 2010-09-30 17:42:52 UTC]

Found how to fix it. Startx was initiated like this from the initscripts:
    /bin/su motiejus -l -c '/usr/bin/startx >/dev/null 2>&1 &'

removing the '-l' switch fixes the situation. If anyone knows why, I would be glad to know...

[Comment 5 Dieter P 2011-02-03 09:17:34 UTC]

Why was this marked as resolved?
The only thing we know is how to work around the issue, and we don't even know how or why the workaround works.

FWIW I have a similar issue on Arch Linux, where the initscripts generate this file:
$ cat /etc/profile.d/locale.sh 
export LANG=en_US.UTF-8
if [ "$CONSOLE" = "" -a "$TERM" = "linux" -a -t 1 ]; then printf "\033%%G"; fi

which is then supposedly sourced by the login shell.
I found out that this did not happen because of how I start my session, the good news is, I find a slightly different workaround then the one already mentioned.
The key is to launch `bash -l`, so in inittab:

#x:5:once:/bin/su dieter -l -c '/usr/bin/startx >/dev/null 2>&1' # doesn't set locale/LANG properly
#x:5:once:/bin/su dieter -l -c '/bin/bash -c "/usr/bin/startx >/dev/null 2>&1"' # doesn't set locale/LANG properly
x:5:once:/bin/su dieter -l -c '/bin/bash -l -c "/usr/bin/startx >/dev/null 2>&1"' # sets locale/LANG properly

[Comment 6 Motiejus Jakštys 2011-02-03 12:03:03 UTC]

You are right. A good explanation would be nice here. Thanks for additional info.

[Comment 7 Jeroen Roovers (RETIRED) 2011-02-03 18:42:18 UTC]

Why was it reopened? It looks like some kind of support problem with a custom configuration - it would be nice to have this on the forums as "RESOLVED" but unless someone points out how the /default/ configuration goes wrong (and what the fix is), I can't really assign this bug report.

[Comment 8 Panagiotis Christopoulos (RETIRED) 2011-02-08 09:43:35 UTC]

(In reply to comment #5)
> Why was this marked as resolved?
> The only thing we know is how to work around the issue, and we don't even know
> how or why the workaround works.
> 

It was resolved because the original reporter marked it as resolved fixed. Our official localization guide is here:

http://www.gentoo.org/doc/en/guide-localization.xml

Please, tweak your configuration following these instructions and you may solve this. If you still have issues, reopen only if you have submitted more information, such as "emerge --info", locale, "emerge -pv openbox" and if it happens with all terminals(also if it happens with other window managers, xorg version) etc. and *only* if you are absolutely certain that this is a real bug and not a misconfiguration of your side. I resolve this as TEST-REQUEST. 

ps: the -l flags in su and bash, provide an environment similar what the user whould have if he/she had login directly, so check your bashrc s and your /etc/profile for changes you've already done and affect that.