Bug#894217: [reprotest] kk_KZ.RK1048 again

Ximin Luo infinity0 at debian.org
Tue Apr 17 22:01:00 BST 2018


Inaki Malerba:
> Hi Ximin
>> More generally, I'd argue that build programs shouldn't fail simply when LC_ALL is unrecognised, for example gcc works perfectly fine.
>>
>> $ LC_ALL=ououi gcc -c /dev/null 2>/dev/null; echo $?
>> 0
> 
> Totally agree.
> Normally, it should fallback to a known config, but, as you can see in
> the following example, the problem it's not exactly that the LC_ALL is
> unrecognized but the LC itself.
> A similar problem happens with Sphinx.
> 
> Sorry if that's not what you meant.
> 
> ```
> # LC_ALL=kk_KZ.RK1048 help2man
> Unknown encoding 'RK1048' at /usr/bin/help2man line 56.
> 
> # LC_ALL=bleble help2man
> perl: warning: Setting locale failed.
> perl: warning: Please check that your locale settings:
> [..]
Well, this detail does not change my main point. Why should any program silently accept LC_ALL=oeuieoui (and print warnings, that's fine) but blow up when running LC_ALL=kk_KZ.XXXXX? It should at most print a warning, not crash. Try it yourself:

$ LC_ALL=kk_KZ.XXXXXX gcc -c /dev/null 2>/dev/null; echo $?
0

BTW help2man seems to work fine on my Debian testing+unstable system with both LC_ALL=kk_KZ.RK1048 and LC_ALL=kk_KZ.XXXXXX and perl 5.26.1-5; I can't reproduce the behaviour you're describing.

I'd suggest to go with the solution that I suggested, i.e. keep filing those bugs you're filing for buggy programs (the fix is to ignore unknown encodings parsed from LC_ALL) and:

Ximin Luo:
> In the meantime you could add an option that lets you configure the locales that reprotest sets, so that your local builds using old buggy programs don't crash. (IMO they *should* crash in tests.r-b.org's official test suites.) See `man reprotest` section VARIATIONS, you could add one for locales.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git



More information about the Reproducible-builds mailing list