This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 507357

Summary: 'yum grouplist' seems to misuse LC_CTYPE environment variable
Product: Red Hat Enterprise Linux 5 Reporter: Issue Tracker <tao>
Component: yumAssignee: James Antill <james.antill>
Status: CLOSED ERRATA QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: low Docs Contact:
Priority: low    
Version: 5.3CC: cward, ddumas, jhutar, mpoole, rlerch, tao
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
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.
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-09-02 03:34:25 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Issue Tracker 2009-06-22 09:47:01 EDT
Escalated to Bugzilla from IssueTracker
Comment 1 Issue Tracker 2009-06-22 09:47:03 EDT
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
Comment 2 Martin Poole 2009-06-22 09:54:34 EDT
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.
Comment 3 James Antill 2009-06-24 11:50:58 EDT
Added upstream, and given it's a one line change I'm going to try and add it to the 5.4 errata.
Comment 4 Denise Dumas 2009-06-24 15:55:52 EDT
Proposing for Snapshot 1
Comment 9 Chris Ward 2009-07-03 14:46:20 EDT
~~ 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.
Comment 12 Ruediger Landmann 2009-09-01 16:04:41 EDT
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.
Comment 13 errata-xmlrpc 2009-09-02 03:34:25 EDT
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