Re: Bug#934928: win32-loader FTBFS on stable - any idea ?
On Sat, 24 Aug 2019 at 18:49:20 +0200, Didier 'OdyX' Raboud wrote:
> The difference I finally found was that the buildds use LANG=C.UTF-8 and
> LC_ALL=C.UTF-8 whereas mine was not enforcing these (and so I was building
> with LC_ALL=POSIX).
This was a change in sbuild 0.78.0, so in practice a difference between
buildds hosted on <= stretch (which used LC_ALL=POSIX) and buildds hosted
on >= buster (which use LC_ALL=C.UTF-8).
Forcing the POSIX (or equivalently C) locale effectively means you are
reverting a small part of the behaviour of newer sbuild, to be more like
the old sbuild where the win32-loader currently in buster was built,
so it seems a good minimal change to address this.
> +# A non-UTF-8 locale is needed for the NSIS build to convert some language
> strings
> +LC_ALL := POSIX
> +export LC_ALL
This is the first time I've encountered a package where changing the locale
to C.UTF-8 *causes* FTBFS - normally the failure mode is that unit tests
assume a UTF-8 (or at least legacy 8-bit) locale, and fail in LC_ALL=POSIX
(or equivalently LC_ALL=C).
It would be interesting to know whether the Farsi locale *works* in the
resulting build; but if it doesn't, then that probably isn't a regression,
because version 0.9.4 in buster would probably be broken in the same way.
smcv
Reply to: