Bug 1323217

Summary: Fails to start when global locale is set to ISO 8859
Product: Red Hat Enterprise Linux 7 Reporter: Siddharth Nagar <snagar>
Component: gnome-terminalAssignee: Debarshi Ray <debarshir>
Status: CLOSED ERRATA QA Contact: Desktop QE <desktop-qa-list>
Severity: high Docs Contact:
Priority: high    
Version: 7.3CC: alanm, ayadav, csoriano, debarshir, dking, dzhukous, egmont, fmuellner, joboyer, mclasen, mkrajnak, pgeorgie, rmatos, rstrode, tpelka, vanhoof, vbenes
Target Milestone: rcKeywords: ZStream
Target Release: 7.3   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: gnome-terminal-3.14.3-5.el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1324761 1905333 (view as bug list) Environment:
Last Closed: 2016-11-03 23:48:49 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1203710, 1324761, 1905333    

Description Siddharth Nagar 2016-04-01 14:51:51 UTC
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.

Comment 2 Ray Strode [halfline] 2016-04-01 19:08:41 UTC
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.

Comment 12 Egmont Koblinger 2016-04-11 08:59:53 UTC
Upstream: https://bugzilla.gnome.org/show_bug.cgi?id=732127

Comment 15 errata-xmlrpc 2016-11-03 23:48:49 UTC
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