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

From Tomas Vondra
Subject Re: Initdb-cs_CZ.WIN-1250 buildfarm failures
Date
Msg-id 5495B9A9.1040209@fuzzy.cz
Whole thread Raw
In response to Re: Initdb-cs_CZ.WIN-1250 buildfarm failures  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Initdb-cs_CZ.WIN-1250 buildfarm failures  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 20.12.2014 18:32, Tom Lane wrote:
> Tomas Vondra <tv@fuzzy.cz> writes:
>> On 20.12.2014 18:13, Pavel Stehule wrote:
>>> It is Microsoft encoding, - it is not available on Linux
> 
>> Not true. It is available on Linux, and the regression tests were 
>> running with it for a long time (essentially from the moment magpie
>> was added to the buildfarm).
> 
> Well, you had it at one time, but it sure doesn't seem to be there now.
>
> I poked around in the RHEL 6.6 release notes, and found this possibly
> relevant tidbit:

Ah, apparently I upgraded this VM to 6.6 - that wasn't exactly planned.

> 
>      mingw component, BZ#1063396
> 
>      Following the deprecation of Matahari packages in Red Hat
>      Enterprise Linux 6.3, at which time the mingw packages were noted
>      as deprecated, and the subsequent removal of Matahari packages
>      from Red Hat Enterprise Linux 6.4, the mingw packages are now
>      being removed from Red Hat Enterprise Linux 6.6.
> 
>      The mingw packages will no longer be shipped in future Red Hat
>      Enterprise Linux 6 minor releases, nor will they receive
>      security-related updates. Consequently, users are advised to
>      uninstall any earlier releases of the mingw packages from their
>      Red Hat Enterprise Linux 6 systems.
> 
> It seems plausible that a WIN-1250 locale would have been something 
> that would've been supplied by mingw rather than being part of
> either glibc-common or any official locale package. I'm not sure how
> that translates to it actively disappearing from your machine --- as
> the note says, you're "advised to uninstall" mingw, but I don't think
> the 6.6 update would have removed it automatically. Still, the
> outlines of a theory are starting to come into focus.

I don't think so. As I mentioned in the previous post, I still can
create the locale, but initdb still fails with an error about
ANSI_X3.4-1968 encoding.

But clearly, something changed between RH 6.5 and 6.6, because on 6.5 I
get this:

$ LANG=cs_CZ.WIN-1250 locale LC_NUMERIC
,
�
3;3
44
160
CP1250

while on 6.6 I get this:

$ LANG=cs_CZ.WIN-1250 locale LC_NUMERIC
,

3;3
44
160
ANSI_X3.4-1968

So yeah, the locale definition did change a bit - the  encoding is
different, and we can't cope with it.

> Immediate recommendation is to restart the buildfarm critters with
> the missing locale removed from their configurations. If you can find
> the locale again somewhere, by all means re-enable it, but better
> less testing than no testing in the meantime.

I've removed cs_CZ.WIN-1250 and sk_SK.WIN-1250 from the config. Let's
see how that works.


Tomas



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Initdb-cs_CZ.WIN-1250 buildfarm failures
Next
From: Tom Lane
Date:
Subject: Re: Initdb-cs_CZ.WIN-1250 buildfarm failures