Re: Initdb-cs_CZ.WIN-1250 buildfarm failures - Mailing list pgsql-hackers

From Noah Misch
Subject Re: Initdb-cs_CZ.WIN-1250 buildfarm failures
Date
Msg-id 20141220164843.GE1838835@tornado.leadboat.com
Whole thread Raw
In response to Initdb-cs_CZ.WIN-1250 buildfarm failures  (Noah Misch <noah@leadboat.com>)
Responses Re: Initdb-cs_CZ.WIN-1250 buildfarm failures
Re: Initdb-cs_CZ.WIN-1250 buildfarm failures
Re: Initdb-cs_CZ.WIN-1250 buildfarm failures
List pgsql-hackers
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
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
.

-1
46
0
ANSI_X3.4-1968
$ locale -a|grep cs_
cs_CZ
cs_CZ.iso88592
cs_CZ.utf8

Perhaps an update made the system stricter about rejecting unknown locales.



pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: POLA violation with \c service=
Next
From: Steve Singer
Date:
Subject: Re: [PATCH] HINT: pg_hba.conf changed since last config reload