| Summary: | unsupported locale setting causes subscription-manager-gui to traceback on startup on rhel 5.8 | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | J.C. Molet <jmolet> |
| Component: | subscription-manager | Assignee: | Chris Duryee <cduryee> |
| Status: | CLOSED ERRATA | QA Contact: | J.C. Molet <jmolet> |
| Severity: | urgent | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 5.8 | CC: | alikins, cduryee, spandey, wpoteat |
| Target Milestone: | rc | ||
| Target Release: | 5.8 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | 0.98.5-1.el5 | Doc Type: | Bug Fix |
| Doc Text: |
No description necessary
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-02-21 06:43:17 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Bug Depends On: | |||
| Bug Blocks: | 715031, 769266 | ||
|
Description
J.C. Molet
2011-11-23 19:43:51 UTC
Investigating this further:
In the DatePicker class in widgets.py, it seems to set and unset the time local in several of its functions, similar to this:
self.date_picker_locale = managerlib.find_date_picker_locale()
# unset locale if we can't parse it here
self.orig_locale = locale.getlocale(locale.LC_TIME)
locale.setlocale(locale.LC_TIME, self.date_picker_locale)
self._date_entry.set_text(self._date.strftime("%x"))
locale.setlocale(locale.LC_TIME, self.orig_locale)
both managerlib.find_date_picker_locale() and locale.getlocale() return tuples of the local and encoding.
In rhel5 they return: ('en_US', 'utf')
In rhel6 they return: ('en_US', 'UTF-8')
the locale.setlocale() function converts this tuple to a string and then sets the locale with that string; the problem is that 'en_US.utf' is not a valid locale, as it needs the '-8' or '8' added to the end.
The locale ('en_US', 'utf') is set when gtk.glade.bindtextdomain('rhsm', '/usr/share/locale/') is run. I'm guessing that that function looks for a translation file for your lang/program and gets the encoding. As there is no en_US translation file it must default to 'utf' in rhel5.
I've tested this with languages that have translation files that set the encoding properly an they seem to work.
Thanks for the detailed bug report. This is related to http://bugs.python.org/issue1699853, which was marked as notabug. The core issue is that setlocale() and getlocale() do slightly different things, and thus the output of getlocale() cannot always be relied upon by setlocale(). For example, if I set my locale as "en_US.UTF-8", then setlocale(getlocale()) will not work. I don't have a fix for this yet, still working on it. After further review, I am not sure if this is fixable in subscription-manager without backing out the fix for bug 746732. Originally, we had an issue with strptime/strftime in bug 708095. This was fixed by making the following call: time.strptime(today.strftime("%x"), "%x") This checks to see if python is able to generate today's date in the environment's locale and use that as valid date input. If it fails, we default to en_GB. However, this caused all dates in subscription-manager to use the fallback en_GB time locale, even dates that are not to be used as input (see bz 746732). We are not able to alter the way strptime/strftime creates and parses dates without altering python's locale. This creates its own problems, since it is possible to read in a locale, alter it, and not be able to reset it back to the original definition again. Adrian may know of some other way to do this, but I think we should just back out 746732's fix and either change the bug to WONTFIX or move the original strptime/strftime bug upstream. *** Bug 756389 has been marked as a duplicate of this bug. *** working on a fix now, please ignore comment #3 for the time being. fae0fc6c master 0.98.4+ application opens now. marking VERIFIED. subscription-manager-gnome-0.98.3-1.git.18.fae0fc6.el5_7
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
New Contents:
No description necessary
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2012-0154.html |