Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 339182 - terminals do not display lithuanian letters when session loaded "startx"
Summary: terminals do not display lithuanian letters when session loaded "startx"
Status: RESOLVED TEST-REQUEST
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Unspecified (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Gentoo Linux bug wranglers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-09-30 00:02 UTC by Motiejus Jakštys
Modified: 2011-02-08 09:43 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
manually modified /etc/profile after etc-update (profile,2.07 KB, text/plain)
2010-09-30 00:05 UTC, Motiejus Jakštys
Details
output of sh -c "set && env" in a working-letter terminal (works.txt,4.35 KB, text/plain)
2010-09-30 00:07 UTC, Motiejus Jakštys
Details
output of sh -c "set && env" in a NON-working-letter terminal (notworking.txt,4.36 KB, text/plain)
2010-09-30 00:08 UTC, Motiejus Jakštys
Details

Note You need to log in before you can comment on or make changes to this bug.
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 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:

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.