On Sat, Dec 20, 2014 at 05:14:03PM +0100, CSPUG wrote: > On 20.12.2014 07:39, Noah Misch wrote: > > Buildfarm members magpie, treepie and fulmar went absent on > > 2014-10-29. Since returning on 2014-11-16, they have consistently > > failed with 'initdb: invalid locale name "cs_CZ.WIN-1250"'. No > > commits in that period readily explain a regression in this area. Did > > the underlying system configurations change? > > I'm pretty sure it's because of broken locales at the system level. It was > working fine, and I haven't done any substantial changes to the system > except for occasional "yum update", so I'm unaware of what went wong :( > > The issue looks like this: > > # locale -a | grep en_US > en_US > en_US.iso88591 > en_US.iso885915 > en_US.utf8 > > # locale en_US > locale: unknown name "en_US"
The NAME argument to the "locale" tool is something like LC_PAPER, not a locale name. Use "LANG=en_US locale LC_NUMERIC" to test locale loading.
> The only reasons I can think of is that some of the updates required > a reboot, and I haven't done that because that would kill all the VMs > running on that HW, including the one with CLOBBER_CACHE_RECURSIVE > tests. And that'd throw away tests running for ~3 months. > > I've disabled the three animals (magpie, fulmar, treepie) for now, because > there's no point in running the tests until the locale issues are fixed. If > anyone has an idea of what might be wrong, let me know.
Those animals have been successfully completing initdb for several locales, including en_US, before failing at cs_CZ.WIN-1250. You could disable just the cs_CZ.WIN-1250 steps. A CentOS 6.6 system here also lacks such a locale:
$ LANG=cs_CZ.WIN-1250 locale LC_NUMERIC
It is Microsoft encoding, - it is not available on Linux
Regards
Pavel
locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory .
