On Fri, Jun 15, 2018 at 08:20:36AM -0500, Matthias Maier wrote: > > On Fri, Jun 15, 2018, at 04:42 CDT, Daniel P. Berrangé <berra...@redhat.com> > wrote: > > > On Thu, Jun 14, 2018 at 11:40:41PM -0500, Matthias Maier wrote: > >> This commit removes the PYTHON_UTF8 workaround. The problem with setting > >> > >> LC_ALL= LANG=C LC_CTYPE=en_US.UTF-8 > >> > >> is that the en_US.UTF-8 locale might not be available. In this case > > > > What platform are you using where UTF8 locale is not available ? > > For example, neither Debian (and for that matter Ubuntu) nor Gentoo > guarantee that the en_US.UTF-8 locale is available. > > We in particular encounter build problems on Gentoo when users have only > set very specific, non en_US locales, for example de_DE.UTF-8 (or > similar). > > > Indeed I would ideally like to make the entire of QEMU build with an > > explicit en_US.UTF-8 or C.UTF-8 locale, to ensure that we get reliably > > reproducible builds, as locale differences have been known to impact > > output of many tools not just python. > > We face the same problem in Gentoo and usually advice users to set > LC_ALL=C when submitting bug reports. (It is frustrating that glibc > upstream doesn't get their act together fixing and merging the current > C.UTF-8 proposal.) > > So what about making the build system more robust (by merging the > patches, or a variant) and either setting C.UTF-8, or C globally > (depending on availability)?
Yes, if we could figure out a way to check for existance of locales, we could make configure check for C.UTF-*, en_US.UTF-8, C in that order, using the first it finds to work. Fun fact, on macOS 'C' is always UTF-8, so its valid to use just 'C'. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
