Bug#894217: [reprotest] kk_KZ.RK1048 again

[Ximin Luo]

Inaki Malerba:
> Hi Chris!
> 
> Thanks for the answer.
> 
> On 17/04/18 13:18, Chris Lamb wrote:
>> Could you expand the commit message on this patch to include the
>> reason why beyond "causes trouble"?
> 
> I've done some research about the root problem but couldn't find much
> more than it's a relatively new encoding.
> My guess is that it's still not supported by some platforms. I found
> some threads about its inclusion to python[1] and glibc[2].
> 
> I agree that it might seem like it was added on purpose, but rather than
> checking for changes on the build, it makes the build tools fail.
> 
> If you know somebody that might know more about the nature of this
> problem, or why it was chosen, would you cc him/her, please? Maybe
> that's better than changing it.
> 
> 
> 
> 1. https://bugs.python.org/issue22682
> 2. https://lists.debian.org/debian-glibc/2004/06/msg00080.html
> 

I added this in commit 8b18046b6e96628cba2e2ce6011766ef964a71a9 specifically to test for things like #847596.

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

Since LC_ALL is meant to be an override anyways, programs should just fall back on the pre-existing locale settings if it's unrecognised. In other words, if any build programs crash, that would be the "ideal fix", and they should be patched to behave like that.

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