[virt-tools-list] [PATCH virt-viewer] Don't set LC_ALL=C during build as that breaks python apps

[Eric Blake]

On 07/25/2017 07:48 AM, Daniel P. Berrange wrote:
> Setting LC_ALL=C breaks python apps doing I/O on UTF-8 source
> files. In particular this broke glib-mkenums
> 
>     Traceback (most recent call last):
>       File "/usr/bin/glib-mkenums", line 669, in <module>
>         process_file(fname)
>       File "/usr/bin/glib-mkenums", line 406, in process_file
>         line = curfile.readline()
>       File "/usr/lib64/python3.6/encodings/ascii.py", line 26, in decode
>         return codecs.ascii_decode(input, self.errors)[0]
>     UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 849: ordinal not in range(128)

Eww. Are we sure that's not a bug in python?  LC_ALL=C is supposed to be
8-bit clean (every byte is a character, you can never get an encoding
error), and a superset of 7-bit ascii.  The failure makes is sound like
python is incorrectly treating LC_ALL=C as requesting only 7-bit ascii
instead of full 8-bit cleanness.

> +++ b/maint.mk
> @@ -117,8 +117,8 @@ news-check-lines-spec ?= 1,10
>  news-check-regexp ?= '^\*.* $(VERSION_REGEXP) \($(today)\)'
>  
>  # Prevent programs like 'sort' from considering distinct strings to be equal.
> -# Doing it here saves us from having to set LC_ALL elsewhere in this file.
> -export LC_ALL = C
> +# Doing it here saves us from having to set LC_COLLATE elsewhere in this file.
> +export LC_COLLATE = C

This makes the build non-deterministic on platforms that have exported
LC_ALL.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/virt-tools-list/attachments/20170725/684f3238/attachment.sig>