Description of problem: An unsupported locale setting causes subscription-manager-gui to traceback on startup making it unsuable on rhel 5.8 Version-Release number of selected component (if applicable): python-rhsm-0.98.3-1.git.2.74cd6bb.el5_7 subscription-manager-gnome-0.98.3-1.git.16.14460bc.el5_7 subscription-manager-firstboot-0.98.3-1.git.16.14460bc.el5_7 subscription-manager-0.98.3-1.git.16.14460bc.el5_7 How reproducible: always Steps to Reproduce: 1. Start subscription-manager-gui on a rhel 5.8 box Actual results: /usr/share/rhsm/subscription_manager/gui/widgets.py:47: GtkWarning: gdk_gc_new: assertion `drawable != NULL' failed self.glade = gtk.glade.XML(os.path.join(GLADE_DIR, glade_file)) /usr/share/rhsm/subscription_manager/gui/widgets.py:47: GtkWarning: gdk_gc_copy: assertion `GDK_IS_GC (dst_gc)' failed self.glade = gtk.glade.XML(os.path.join(GLADE_DIR, glade_file)) /usr/share/rhsm/subscription_manager/gui/widgets.py:47: GtkWarning: gdk_gc_set_values: assertion `GDK_IS_GC (gc)' failed self.glade = gtk.glade.XML(os.path.join(GLADE_DIR, glade_file)) /usr/share/rhsm/subscription_manager/gui/widgets.py:47: GtkWarning: gdk_gc_set_dashes: assertion `GDK_IS_GC (gc)' failed self.glade = gtk.glade.XML(os.path.join(GLADE_DIR, glade_file)) unsupported locale setting Expected results: no traceback Additional info: This seems to be working on rhel6 and fedora. My $LANG is set to the exotic: en_US.UTF-8
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