[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2 1/2] Partially revert commit d4e5ec877ca
From: |
Matthias Maier |
Subject: |
Re: [Qemu-devel] [PATCH v2 1/2] Partially revert commit d4e5ec877ca |
Date: |
Fri, 15 Jun 2018 08:20:36 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) |
On Fri, Jun 15, 2018, at 04:42 CDT, Daniel P. Berrangé <address@hidden> 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)?
Best,
Matthias