On 12/31/2014 12:26 PM, Tomas Vondra wrote:
On 31.12.2014 17:29, Andrew Dunstan wrote:
Sorry, I should have tested it. This seems to work:
if ($branch eq 'REL9_0_STABLE')
{
$PGBuild::Options::skip_steps .= ' pl-install-check';
$main::skip_steps{'pl-install-check'} = 1
On 31.12.2014 17:29, Andrew Dunstan wrote:
>
> Sorry, I should have tested it. This seems to work:
>
>if ($branch eq 'REL9_0_STABLE')
>{
> $PGBuild::Options::skip_steps .= ' pl-install-check';
> $main::skip_steps{'pl-install-check'} = 1;
>}
>
> cheers
Meh, no problem
On 12/31/2014 07:49 AM, Tomas Vondra wrote:
On 28.12.2014 00:46, Noah Misch wrote:
On Tue, Dec 23, 2014 at 03:32:59PM +0100, Tomas Vondra wrote:
On 23.12.2014 15:21, Andrew Dunstan wrote:
No, config_opts is what's passed to configure. Try something like:
if ($branch eq 'REL9_0_STABLE')
On 28.12.2014 00:46, Noah Misch wrote:
> On Tue, Dec 23, 2014 at 03:32:59PM +0100, Tomas Vondra wrote:
>> On 23.12.2014 15:21, Andrew Dunstan wrote:
>>>
>>> No, config_opts is what's passed to configure. Try something like:
>>>
>>> if ($branch eq 'REL9_0_STABLE')
>>> {
>>> $skip_ste
On Tue, Dec 23, 2014 at 03:32:59PM +0100, Tomas Vondra wrote:
> On 23.12.2014 15:21, Andrew Dunstan wrote:
> >
> > No, config_opts is what's passed to configure. Try something like:
> >
> > if ($branch eq 'REL9_0_STABLE')
> > {
> > $skip_steps{'pl-install-check'} = 1;
> > }
>
On 23.12.2014 15:21, Andrew Dunstan wrote:
>
> No, config_opts is what's passed to configure. Try something like:
>
> if ($branch eq 'REL9_0_STABLE')
> {
> $skip_steps{'pl-install-check'} = 1;
> }
Applied to all three animals.
Tomas
--
Sent via pgsql-hackers mailing list
On 12/23/2014 07:14 AM, Tomas Vondra wrote:
On 23.12.2014 09:19, Noah Misch wrote:
On Sat, Dec 20, 2014 at 07:28:33PM +0100, Tomas Vondra wrote:
On 20.12.2014 19:05, Tom Lane wrote:
Locale cs_CZ.WIN-1250 is evidently marked with a codeset property of
"ANSI_X3.4-1968" (which means old-school U
On 23.12.2014 09:19, Noah Misch wrote:
> On Sat, Dec 20, 2014 at 07:28:33PM +0100, Tomas Vondra wrote:
>> On 20.12.2014 19:05, Tom Lane wrote:
>>> Locale cs_CZ.WIN-1250 is evidently marked with a codeset property of
>>> "ANSI_X3.4-1968" (which means old-school US-ASCII). That's certainly
>>> wrong
On Sat, Dec 20, 2014 at 07:28:33PM +0100, Tomas Vondra wrote:
> On 20.12.2014 19:05, Tom Lane wrote:
> > Locale cs_CZ.WIN-1250 is evidently marked with a codeset property of
> > "ANSI_X3.4-1968" (which means old-school US-ASCII). That's certainly
> > wrong. I believe the correct thing would be "C
On 20.12.2014 19:35, Tom Lane wrote:
> Tomas Vondra writes:
>> On 20.12.2014 19:05, Tom Lane wrote:
>>> I am betting that you recreated them differently from before.
>
>> And you're probably right. Apparently, I recreated them like this:
>
>> $ localedef -v -c -i cs_CZ -f WIN-1250 cs_CZ.WI
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 are
Tomas Vondra writes:
> On 20.12.2014 19:05, Tom Lane wrote:
>> I am betting that you recreated them differently from before.
> And you're probably right. Apparently, I recreated them like this:
> $ localedef -v -c -i cs_CZ -f WIN-1250 cs_CZ.WIN-1250
> but the correct way seems to be this:
On 20.12.2014 19:05, Tom Lane wrote:
> Tomas Vondra writes:
>> I believe the locale system (at the OS level) works just like before. I
>> remember I had to manually create the locales while initially setting up
>> the animals. Then, ~2 months ago something happened (I asssume a yum
>> update) and
Tomas Vondra writes:
> 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
T
Tomas Vondra writes:
> I believe the locale system (at the OS level) works just like before. I
> remember I had to manually create the locales while initially setting up
> the animals. Then, ~2 months ago something happened (I asssume a yum
> update) and some of the locales disappeared. But I have
On 20.12.2014 18:32, Tom Lane wrote:
> Tomas Vondra 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 mo
On 20.12.2014 17:48, Noah Misch wrote:
> 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: in
On 12/20/2014 12:32 PM, Tom Lane wrote:
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.
Tomas Vondra 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).
We
2014-12-20 18:17 GMT+01:00 Tomas Vondra :
> On 20.12.2014 18:13, Pavel Stehule wrote:
> >
> > 2014-12-20 17:48 GMT+01:00 Noah Misch >
> > $ LANG=cs_CZ.WIN-1250 locale LC_NUMERIC
> >
> >
> > It is Microsoft encoding, - it is not available on Linux
>
> Not true. It is available on Linux, and th
On 20.12.2014 18:13, Pavel Stehule wrote:
>
> 2014-12-20 17:48 GMT+01:00 Noah Misch
> $ LANG=cs_CZ.WIN-1250 locale LC_NUMERIC
>
>
> 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 (es
2014-12-20 17:48 GMT+01:00 Noah Misch :
> 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 'i
Noah Misch writes:
> 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 "
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
>
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
25 matches
Mail list logo
