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).
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.
Created attachment 249013 [details] output of sh -c "set && env" in a working-letter terminal
Created attachment 249015 [details] output of sh -c "set && env" in a NON-working-letter terminal
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...
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
You are right. A good explanation would be nice here. Thanks for additional info.
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.
(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.
