Bug 57928 - "=" sign appended to language set by gdm
"=" sign appended to language set by gdm
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: gdm (Show other bugs)
7.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Havoc Pennington
Aaron Brown
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-01-02 08:10 EST by Martin Norback
Modified: 2007-04-18 12:38 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-03-23 16:45:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Martin Norback 2002-01-02 08:10:05 EST
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.
Comment 1 Havoc Pennington 2002-01-18 17:50:21 EST
I believe this may be fixed in recent gdm packages, but need to double check.
Comment 2 Havoc Pennington 2002-02-11 18:35:22 EST
Looks fixed in rawhide:

 english         en.ISO-8859-1
 english.us      en_US.ISO-8859-1
 english.gb      en_GB.ISO-8859-1
Comment 3 Martin Norback 2002-02-12 05:48:45 EST
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?
Comment 4 Need Real Name 2002-02-17 20:10:26 EST
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
Comment 5 Havoc Pennington 2002-03-01 17:38:59 EST
2.2.3.1-21 should fix this. I also fixed it in GNOME CVS.
Comment 6 Need Real Name 2002-03-01 18:27:19 EST
Well, talk to your RH colleagues who deleted the whole i386
*and* SRPMS trees in rawhide ... !



Comment 7 Robert Clark 2002-03-21 19:01:32 EST
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
Comment 8 Havoc Pennington 2002-03-21 20:04:36 EST
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?
Comment 9 Robert Clark 2002-03-23 16:45:13 EST
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.
Comment 10 Havoc Pennington 2002-03-23 16:58:57 EST
Thanks for tracking it down (glad it was initscripts, I was kind of unsure what
gdm would be doing to cause that)

Note You need to log in before you can comment on or make changes to this bug.