Bug 57928

Summary:	"=" sign appended to language set by gdm
Product:	[Retired] Red Hat Linux	Reporter:	Martin Norback <d95mback>
Component:	gdm	Assignee:	Havoc Pennington <hp>
Status:	CLOSED RAWHIDE	QA Contact:	Aaron Brown <abrown>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.2	CC:	roswell
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2002-03-23 21:45:18 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Martin Norback 2002-01-02 13:10:05 UTC

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 22:50:21 UTC

I believe this may be fixed in recent gdm packages, but need to double check.

Comment 2 Havoc Pennington 2002-02-11 23:35:22 UTC

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 10:48:45 UTC

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-18 01:10:26 UTC

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 22:38:59 UTC

2.2.3.1-21 should fix this. I also fixed it in GNOME CVS.

Comment 6 Need Real Name 2002-03-01 23:27:19 UTC

Well, talk to your RH colleagues who deleted the whole i386
*and* SRPMS trees in rawhide ... !

Comment 7 Robert Clark 2002-03-22 00:01:32 UTC

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-22 01:04:36 UTC

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 21:45:13 UTC

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 21:58:57 UTC

Thanks for tracking it down (glad it was initscripts, I was kind of unsure what
gdm would be doing to cause that)