Issue: Qt: Locales not supported on X server
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 4043
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
The problem, or the biggest hint about the problem
I'm trying to track down this error, finally found a clue:

:: Code ::
Xsession: X session started for h3 at Sat Jan 24 09:04:51 PST 2009
startkde: Starting up...
startkde: Running kpersonalizer...
/usr/bin/iceauth:  creating new authority file /home/h3/.ICEauthority
Qt: Locales not supported on X server
QInputContext: no input method context available
QInputContext: no input method context available


This is the output from a failed xsession start, found in ~/.xsession-errors file.

Since the core bug had two parts, both involving locale issues I suspected this was a locale problem all along, but I couldn't pinpoint it: kwin failed to start, thus breaking kde sessions (THE killer feature of kde in my opinion) completely, and one, much older, kde compose key + character combinations allowing you to create type characters, that is, being broken for a LONG time now for me.

I'd found somewhat related issues in the past online, but they were always referring to kde4, and this isn't related at all to kde4, although I thought it might have been because I installed kde4 apps in the past, but when I made one last attempt, prior to finding this solution, to solve this bug by reinstalling kde, I made a point of not installing any kde4 apps, to keep the debugging dataset simple, and the problem persisted.

The main hint that led me to the solution
Found a site that noted this:

:: Quote ::
The current locale is set in the file /etc/sysconfig.locale, which is sourced by /etc/profile.d/lc.sh, which in turn is loaded by login shells. /etc/sysconfig/locale has a number of variables, most people will only want to set the first 2: LANG and LC_ALL.
............
About locales, UTF-8, and Xlib
locale -a may report some locales like fr_FR.utf8@euro.UTF-8 :
$ locale -a
C
en_GB
en_GB.iso88591
en_GB.utf8
en_US
en_US.iso88591
en_US.utf8
fr_FR
fr_FR@euro
fr_FR@euro.UTF-8
fr_FR.iso88591
fr_FR.iso885915@euro
fr_FR.utf8
fr_FR.utf8@euro.UTF-8
POSIX
If you choose fr_FR.utf8 or fr_FR.utf8@euro.UTF-8, you may get errors like the following (for Qt and gtk applications) :
$kwrite
Qt: Locales not supported on X server

$gftp
Gdk-WARNING **: locale not supported by Xlib.
This problems comes from two things :
- utf8 is not standard, UTF-8 is.
- euro with UTF-8 is superfluous.
So, in this case, to have a french locale with UTF-8, you'll have to use fr_FR.UTF-8


I checked with locale:

:: Code ::
locale
LANG=en_US.UTF-8
LANGUAGE=en_US.UTF-8
LC_CTYPE="en_US.utf8 "
LC_NUMERIC="en_US.utf8 "
LC_TIME="en_US.utf8 "
LC_COLLATE="en_US.utf8 "
LC_MONETARY="en_US.utf8 "
LC_MESSAGES="en_US.utf8 "
LC_PAPER="en_US.utf8 "
LC_NAME="en_US.utf8 "
LC_ADDRESS="en_US.utf8 "
LC_TELEPHONE="en_US.utf8 "
LC_MEASUREMENT="en_US.utf8 "
LC_IDENTIFICATION="en_US.utf8 "
LC_ALL=en_US.utf8


Note the utf8 there.

And checking with locale -a shows:

:: Code ::
locale -a
C
en_US.utf8
es_ES.utf8
nn_NO.utf8
POSIX

Just as the guy said it would.
Back to top
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 4043
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
And the culprit was in my case a stray export file:

:: Code ::
cat /etc/environment*
export LANG=en_US.utf8
export LC_ALL=en_US.utf8


That's where the incorrect syntax was loaded. I found this by doing this:

:: Code ::
grep -iRls en_US.utf8 /etc

prior to removing /etc/environment, I also removed all knoppix config data found in /etc:
:: Code ::
ls -R /etc | grep -i knoppix

showed me a few stray knoppix configs, one dealing with, no surprise, locale generation.

This was one of the longest running bugs I have had, but because I basically looked every where else for why both kde sessions failed to load, and why the compose key failed to let me type euro style characters and so on, I knew it had to be connected to locales.

I simply renamed the offending environment file and restarted, and everything was fine. Man.... this bug took me over a year to solve, and many thanks to the above site for pointing me finally in the right direction.

And then everything was fine, the xsession-error was fixed, and my locale shows this:

:: Code ::
locale
LANG=en_US.UTF-8
LANGUAGE=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=


All nice and happy now! UTF-8 as it should be, no kwin start failures, compose key works, and utf-8 is back working in all other apps too.

The moral of the story
Debian's dislike of derived distros is well deserved, this issue was I believe caused by a stray knoppix / kanotix configuration file. I'd actually asked the helpful people at irc.oftc.net/debian a few times for hints, but now that it turns out to have been a piece of cruft from my original Kanotix install, I really feel kind of bad having made them use some support time to help me out (though they did point me to looking at the .xsession-errors file, which showed me the first concrete hint of the error).

So the moral of the story is this: if you are making a derived distro, please make sure to NOT throw in little hacks and tricks that will prove to be virtually impossible to debug in the future, long after your interest and memory of that release has faded and become yet another interweb null entity.

Knoppix and the heavily knoppix influenced kanotix were especially bad about this, but I'm sure things like Xandros are worse, and Mepis does its own little non-standard things as well that will catch you long term.

So next time you pick your distro, ask yourself, if I run this long term, who will support me, who will help me debug? Is the distro using hacks that will be forgotten in a year or two? And that are totally undocumented?

This is, by the way, why all scripts I do make a huge effort to never change or add anything outside of Debian itself, no tricky methods, no weird config file hacks, etc. I may fail now and then, but this is always the goal, especially for smxi and sgfxi. This doesn't mean that everything is dfsg pure, ie, nvidia driver installs will use the nvidia driver installer, vmware will use the vmware installer, but besides things like that, all methods and tricks used are strictly debian style.
Back to top
Display posts from previous:   

All times are GMT - 8 Hours