Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 339182

Summary: terminals do not display lithuanian letters when session loaded "startx"
Product: Gentoo Linux Reporter: Motiejus Jakštys <desired.mta>
Component: [OLD] UnspecifiedAssignee: Gentoo Linux bug wranglers <bug-wranglers>
Severity: normal CC: czajernia, desired.mta, dieter, pchrist
Priority: High    
Version: unspecified   
Hardware: x86   
OS: Linux   
Package list:
Runtime testing required: ---
Attachments: manually modified /etc/profile after etc-update
output of sh -c "set && env" in a working-letter terminal
output of sh -c "set && env" in a NON-working-letter terminal

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/ 
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) gentoo-dev 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) gentoo-dev 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:

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.