Bug#894217: [reprotest] kk_KZ.RK1048 again

Ximin Luo infinity0 at debian.org
Wed Apr 18 22:40:00 BST 2018


Agustin Henze:
> Hi Ximin,
> 
> On Tue, 17 Apr 2018 21:01:00 +0000 Ximin Luo <infinity0 at debian.org> wrote:
>> 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
>>
> 
> Thank you for taking time testing it :). This example does work for me as well.
> 
>> 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.
>>
> 
> Doesn't work for me, please find attached a Dockerfile and its output (I've
> stripped out the non-important parts).

Your perl/python tests miss the point. I think it's fine for .encode() to crash or raise an exception when given an unrecognised encoding, because it's an explicit command. I don't think it's fine for LC_ALL to crash or raise an exception, because it's meant to be an opportunistic override.

Have you tried:

$ LC_ALL=kk_KZ.XXXXXX perl -e 'print "yes\n";'
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
	LANGUAGE = "en_GB:en",
	LC_ALL = "kk_KZ.XXXXXX",
	LANG = "en_GB.utf8"
    are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_GB.utf8").
yes

$ LC_ALL=kk_KZ.XXXXXX python2 -c 'print "yes\n";'
yes

They work fine on my computer but since I was unable to reproduce the bug here anyways, I am not sure if it means much. But these tests are more "to the point" than your tests in your output.txt.

IMO the time spent discussing this on this bug report would have been better spent writing patches for the affected programs.

I really don't think reprotest should be coded to ignore known problems. If you want to avoid these bugs (in other programs), give `reprotest --vary=-locales` then the problem is evident visually on the command-line and not "brushed under the carpet" and you can still continue with your other tests.

X

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



More information about the Reproducible-builds mailing list