Description of problem: GNOME desktop fails to start when global locale is set to ISO 8859-15. Our customer has a legacy application that expects input and output in 8-bit ISO 8859 locale; specifically ISO 8859-15. When they tried to validate this application on RHEL 7.2, the application failed to start. This is most likely an issue with KDE as well and we'll open a separate bug for that if necessary. Version-Release number of selected component (if applicable): Unknown How reproducible: Always Steps to Reproduce: 1. Enable ISO8859-15 as the global locale. 2. Start GNOME Actual results: You get a blank desktop without menus, icons and background. Expected results: Additional info: This was working on RHEL 7.1 and some changes have been introduced since then for it to no longer workon RHEL 7.2.
How is the customer setting the locale? I just tried to do it here and the desktop starts fine. gnome-terminal doesn't start however. It explicitly has code to check for non-utf8 encodings and fails if a non-utf8 encoding is discovered. I don't know if that check got added in the 7.2 rebase. If it did we could consider reverting it to stay compatible with 7.1. Aside from that, though, in general non-utf8 locales aren't supported. It exposes the desktop to a class of bugs that don't exist with UTF-8 locales and QE doesn't do any non-utf8 testing. There's nothing intrinsic about non-UTF-8 locales that would prevent them from working. Internally graphical applications will convert strings to UTF-8 encoding before processing them. So if the desktop is crashing, it's probably a one-line fix, since non-utf8 locales are not supported or tested, there are probably more one-line crash fixes required behind that one. And of course gnome-terminal would need to be changed to not explicitly disallow non-UTF-8 locales. One hurdle that may complicate supporting non-UTF-8 locales is the D-Bus protocol. Its string type requires the encoding to be UTF-8 (and will kick clients off the bus that don't follow those rules). That means clients may need to be fixed to explicitly convert strings to utf-8 before passing them to the bus (which could be a problem if the string is a filename, since the otherside wouldn't be able to open the file if its name was converted), or the api may need to be changed to use a byte arrays instead of a string types (which wouldn't be backward compatible) Ideally if the customer has an old application that requires, non-utf8 encoding, they would just run that application with LANG= set and keep the desktop utf-8.
Upstream: https://bugzilla.gnome.org/show_bug.cgi?id=732127
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. https://rhn.redhat.com/errata/RHBA-2016-2167.html