Escalated to Bugzilla from IssueTracker
Event posted on 2009-06-04 11:43 BST by ahumbe 1. Provide time and date of the problem >>> Always. 2. Indicate the platform(s) (architectures) the problem is being reported against. >>> All platforms. 3. Provide clear and concise problem description as it is understood at the time of escalation >>> We have following environment variables set on RHEL 5 system if the default language is set to US English, LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" Here LC_CTYPE represents "Character classification and case conversion." and LC_MESSAGES represents "Formats of informative and diagnostic messages and interactive responses." When we run "yum grouplist" then we get output in US English language, but if we change the value for LC_CTYPE to fr_FR.UTF-8 then "yum grouplist" gives output in French language. So it seems that yum is following LC_CTYPE instead of LC_MESSAGES. 4. Steps to reproduce : If the system language is set to US English then following are the values with environment variables, we can check the same using "locale" command LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" Then yum output is as follows # yum grouplist | head Loaded plugins: rhnplugin, security Setting up Group Process Installed Groups: Mail Server Network Servers System Tools Available Groups: Administration Tools Authoring and Publishing DNS Name Server but if we change the value for LC_CTYPE to fr_FR.UTF-8 # export LC_CTYPE="fr_FR.UTF-8" then we get output as bellow # yum grouplist | head Loaded plugins: rhnplugin, security Setting up Group Process Installed Groups: Outils de système Serveur de messagerie Serveurs de réseau Available Groups: Authoring et Publishing Base de données MySQL Base de données PostgreSQL * Desired behavior >>> As the LC_CTYPE states the character classification and LC_MESSAGES is used for informative and diagnostic messages and interactive responses, so "yum grouplist" should use the language mentioned in "LC_MESSAGES" to display output. 5. State specific action requested of SEG >>> We would like SEG to confirm whether this yum behavior is expected or this is an bug. 6. Attach Sosreport >>> Attached. 7. Additional details * Following are the client system details where I tested this issue locally Red Hat Enterprise Linux Client release 5.2 (Tikanga) , Linux dhcp7-220.pnq.redhat.com 2.6.18-92.el5 #1 SMP Tue Apr 29 13:16:12 EDT 2008 i686 athlon i386 GNU/Linux This System is registered on RHN hosted. * Also able to reproduce this issue if system is registered to satellite v 5.2 This event sent from IssueTracker by mpoole [Support Engineering Group] issue 303828
This would appear to be a bug in get_my_lang_code() in yum/misc.py import locale mylang = locale.getlocale() which according to the http://docs.python.org/library/locale.html?highlight=locale#locale.getlocale will return the LC_CTYPE unless told otherwise. As "man 7 locale" notes LC_CTYPE This changes the behavior of the character handling and classification functions, such as isupper(3) and toupper(3), and the multi-byte character functions such as mblen(3) or wctomb(3). LC_MESSAGES changes the language messages are displayed in and what an affirmative or negative answer looks like. The GNU C-library contains the gettext(3), ngettext(3), and rpmatch(3) functions to ease the use of these information. The GNU gettext family of functions also obey the environment variable LANGUAGE. so in the light of the above, and given that the only uses of the get_my_lang_code() function is to provide either a language for translated lookup or sorting of entries, it would seem the correct fix would be to have the get_my_lang_code() function call local.getlocale with 'LC_MESSAGES' as its parameter. This finding needs to be verified by someone with greater familiarity of both python locale behaviour and general locale handling experience.
Added upstream, and given it's a one line change I'm going to try and add it to the 5.4 errata.
Proposing for Snapshot 1
~~ Attention - RHEL 5.4 Beta Released! ~~ RHEL 5.4 Beta has been released! There should be a fix present in the Beta release that addresses this particular request. Please test and report back results here, at your earliest convenience. RHEL 5.4 General Availability release is just around the corner! If you encounter any issues while testing Beta, please describe the issues you have encountered and set the bug into NEED_INFO. If you encounter new issues, please clone this bug to open a new issue and request it be reviewed for inclusion in RHEL 5.4 or a later update, if it is not of urgent severity. Please do not flip the bug status to VERIFIED. Only post your verification results, and if available, update Verified field with the appropriate value. Questions can be posted to this bug or your customer or partner representative.
Release note added. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: The Linux environment variable LC_CTYPE specifies a character set and the variable LC_MESSAGES specifies a language for messages. Previously, yum selected a language for messages based on LC_CTYPE instead of LC_MESSAGES. Although on many configurations, LC_CTYPE and LC_MESSAGES will be set to the same language and character encoding, this is not necessarily the case, and by using the wrong environment variable, yum would not provide the expected output under configurations where LC_CTYPE and LC_MESSAGES were set differently. Yum now uses LC_MESSAGES to determine the language to provide messages in, resulting in consistent and expected behavior.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2009-1419.html