[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
> +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.


Reply to: