Thread: 7.x horology regression test on Solaris buildfarm machines
I see that kudu and dragonfly are now failing regression in the 7.3 and 7.4 branches, as a consequence of this patch: http://archives.postgresql.org/pgsql-committers/2007-02/msg00491.php Is it reasonable to assume that that machine will soon be patched to know about the new US DST rules? If not, I suppose we could install variant horology-solaris-1947_1.out files to allow either result to succeed, but it seems a bit silly ... regards, tom lane
Tom Lane wrote: > I see that kudu and dragonfly are now failing regression in the 7.3 and > 7.4 branches, as a consequence of this patch: > http://archives.postgresql.org/pgsql-committers/2007-02/msg00491.php > > Is it reasonable to assume that that machine will soon be patched to > know about the new US DST rules? If not, I suppose we could install > variant horology-solaris-1947_1.out files to allow either result to > succeed, but it seems a bit silly ... > > Yeah. I have stopped building 7.4 on hyena. cheers andrew
On Tue, 27 Feb 2007, Tom Lane wrote: > I see that kudu and dragonfly are now failing regression in the 7.3 and > 7.4 branches, as a consequence of this patch: > http://archives.postgresql.org/pgsql-committers/2007-02/msg00491.php > > Is it reasonable to assume that that machine will soon be patched to > know about the new US DST rules? If not, I suppose we could install > variant horology-solaris-1947_1.out files to allow either result to > succeed, but it seems a bit silly ... > I'll look at an upgrade. Eel is failing as well, but surprisingly canary is not. Canary hasn't had any updates applied, so why isn't it failing as well: jurka@netbsd:~$ zdump -v /etc/localtime | grep 2007 /etc/localtime Sun Apr 1 08:59:59 2007 UTC = Sun Apr 1 01:59:59 2007 MST isdst=0 /etc/localtime Sun Apr 1 09:00:00 2007 UTC = Sun Apr 1 03:00:00 2007 MDT isdst=1 /etc/localtime Sun Oct 28 07:59:59 2007 UTC = Sun Oct 28 01:59:59 2007 MDT isdst=1 /etc/localtime Sun Oct 28 08:00:00 2007 UTC = Sun Oct 28 01:00:00 2007 MST isdst=0 Kris Jurka
On Tue, 27 Feb 2007, Kris Jurka wrote: > I'll look at an upgrade. Eel is failing as well, but surprisingly canary is > not. Canary hasn't had any updates applied, so why isn't it failing as well: > Shouldn't all of the buildfarm members be failing either before or after the patch? That doesn't seem to be the case for any of them. Kris Jurka
Kris Jurka <books@ejurka.com> writes: > Shouldn't all of the buildfarm members be failing either before or after > the patch? That doesn't seem to be the case for any of them. No, because for the "standard" regression behavior we have variant result files both with and without the DST law change: see horology and horology_1. The issue only comes up for machines that were matching to horology-no-DST-before-1970.out (which may be only old HPUX) or horology-solaris-1947.out (which I suppose is only Solaris). The reason I got around to making the patch now is I recently updated my old HPUX machine for the law change, and so 7.x started to fail for me ... regards, tom lane
On Tue, 27 Feb 2007, Tom Lane wrote: > No, because for the "standard" regression behavior we have variant > result files both with and without the DST law change: see horology and > horology_1. The issue only comes up for machines that were matching to > horology-no-DST-before-1970.out (which may be only old HPUX) or > horology-solaris-1947.out (which I suppose is only Solaris). The reason > I got around to making the patch now is I recently updated my old HPUX > machine for the law change, and so 7.x started to fail for me ... > OK, kudu + dragonfly updated. I probably won't get around to fixing eel (cygwin) for some time though. Kris Jurka