Description of Problem: Chosing english in gdm generates the LANG string en.ISO-8859-1 which is then reported as not supported by the C library. This makes programs that actually use the charmap variable fail. Version-Release number of selected component (if applicable): gdm-2.2.3.1-20 glibc-2.2.4-19.3 How Reproducible: Always Steps to Reproduce: 1. Choose "English" in gdm. 2. Login 3. Start a program that uses charmap from locale (mutt for instance) Actual Results: The program doesn't display iso-8859-1 characters correctly. Expected Results: The program should display those correctly if the locale was correct.
I believe this may be fixed in recent gdm packages, but need to double check.
Looks fixed in rawhide: english en.ISO-8859-1 english.us en_US.ISO-8859-1 english.gb en_GB.ISO-8859-1
I think you misunderstood the problem. english en.ISO-8859-1 is not a good line. martin@caesar:~/CVS/External$ LANG=en.ISO-8859-1 locale charmap ANSI_X3.4-1968 martin@caesar:~/CVS/External$ LANG=en_US.ISO-8859-1 locale charmap ISO-8859-1 martin@caesar:~/CVS/External$ LANG=en_GB.ISO-8859-1 locale charmap ISO-8859-1 It may be that the problem is in libc. I don't really know, but using en_US.ISO-8859-1 even for plain english should be ok?
I have a similar problem. Recently many applications start with this message: locale `en_US.ISO-8859-1=' not supported by Xlib; trying `C'. They work fine BTW. I think the problem is that there is a "=" at the end of the locale string that shouldn't be there. Resetting the LANG shell variable to just "en_US.ISO-8859-1" solves the problem. My system is a well-maintained RH 7.2 with all RH updates applied. I believe the problem is caused by some recent official Red Hat update. (don't know which one) friendly greetings, Rob van Nieuwkerk
2.2.3.1-21 should fix this. I also fixed it in GNOME CVS.
Well, talk to your RH colleagues who deleted the whole i386 *and* SRPMS trees in rawhide ... !
Sorry to report that I'm still seeing this: charon:~> rpm -q gdm gdm-2.2.3.1-21 charon:~> echo $GDM_LANG en_GB.ISO-8859-1 charon:~> echo $LANG en_GB.ISO-8859-1= and plenty of: Gdk-WARNING **: locale not supported by Xlib, locale set to C
Hmm, I didn't notice that the trailing "=" was a separate bug. Do you get trailing = if you choose other languages, such as C/POSIX or Spanish or whatever?
Yes, it occurs with all languages. I've tracked it down to the following line: setenv LANG=$GDM_LANG in lang.csh from initscripts-6.43-1. Should be: setenv LANG $GDM_LANG It looks like this has already been fixed in initscripts-6.58-1 (RawHide), though, so please go ahead and resolve this. Sorry for the confusion.
Thanks for tracking it down (glad it was initscripts, I was kind of unsure what gdm would be doing to cause that)