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

Re: Bug#934928: win32-loader FTBFS on stable - any idea ?



Le dimanche, 25 août 2019, 12.20:16 h CEST Simon McVittie a écrit :
> 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).

Ah, thanks for the background.

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

win32-loader is special™ :-)

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

I have not tested win32-loader in non-Wine win32 environments recently, so 
we'd need someone with a Farsi Windows to test this.

But I see that Thomas is doing a lot of work on the experimental branch, and 
we should let this hit unstable soon!

Cheers,
    OdyX

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: