Red Hat Bugzilla – Bug 64061
LANG environment set to invalid Locale
Last modified: 2007-04-18 12:42:18 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (compatible; Konqueror/3.0.0-9; Linux) Description of problem: After installing skipjack beta 2 and upgrading with up2date, all my shells have LANG=en_US.iso885915. However, when I run programs like 'up2date' they complain that this is an invalid locale. I have two machine at beta 2 and both exhibit this behavior. I didn't have it in beta1. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. install beta2 2. open shell 3. run up2date Actual Results: I get messages like: (up2date:3993): Gdk-WARNING **: locale not supported by Xlib (up2date:3993): Gdk-WARNING **: can not set locale modifiers Expected Results: No locale messages Additional info: I can get around it by unseting LANG. However, it is a pain since it screws up most KDE menu functionality.
I did not run up2date and saw the same behavior. (I added a couple of packages on top of the default workstation configuration, but I did not remove any of the already selected ones.) I saw it in the first beta as well.
There appears to be an XFree patch that affects this: http://www.xfree86.org/4.2.0/ERRATA.html: Last updated: 11 March 2002 1. Xlib problem on Solaris and SVR4 On some platforms, particularly Solaris and SVR4, there is a bug in Xlib that prevents the i18n modules from being loaded. The symptoms are messages like the following: Warning: locale not supported by Xlib, locale set to C Warning: X locale modifiers not supported, using default Failed to open input method A source patch is available in the fixes subdirectory (4.2.0-xlib-i18n-module.patch). It is also included in the xf-4_2-branch branch of the XFree86 CVS repository.
This frequently reported problem, was fixed in the final release of Red Hat Linux 7.3. Please upgrade.