Re: pltcl tests fail with FreeBSD 13.2
Andres Freund writes: > On 2023-07-31 19:11:38 -0400, Tom Lane wrote: >> Huh. Maybe worth reporting as a FreeBSD bug? > Yea. Hoping our local freebsd developer has a suggestion as to which component > to report it to, or even fix it :). You already have a reproducer using just tcl, so I'd suggest filing it against tcl and letting them drill down as needed. (It's possible that it actually is tcl that's misbehaving, seeing that our core regression tests are passing in the same environment.) regards, tom lane
Re: pltcl tests fail with FreeBSD 13.2
Hi, On 2023-07-31 19:11:38 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2023-07-31 18:33:37 -0400, Tom Lane wrote: > >> (And could it be that we had one in the predecessor 13.1 image?) > > > No, I checked, and it's not in there either... It looks like the difference > > is > > that 13.1 reads the UTC zoneinfo in that case, whereas 13.2 doesn't. > > Huh. Maybe worth reporting as a FreeBSD bug? Yea. Hoping our local freebsd developer has a suggestion as to which component to report it to, or even fix it :). > In any case I don't think it's *our* bug. Agreed. An explicit tzsetup UTC isn't much to carry going forward... Greetings, Andres Freund
Re: pltcl tests fail with FreeBSD 13.2
Andres Freund writes: > On 2023-07-31 18:33:37 -0400, Tom Lane wrote: >> (And could it be that we had one in the predecessor 13.1 image?) > No, I checked, and it's not in there either... It looks like the difference is > that 13.1 reads the UTC zoneinfo in that case, whereas 13.2 doesn't. Huh. Maybe worth reporting as a FreeBSD bug? In any case I don't think it's *our* bug. regards, tom lane
Re: pltcl tests fail with FreeBSD 13.2
Hi,
On 2023-07-31 18:33:37 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I saw that CI image builds for freebsd were failing, because 13.1, used
> > until
> > now, is EOL. Update to 13.2, no problem, I thought. Ran a CI run against
> > 13.2
> > - unfortunately that failed. In pltcl of all places.
>
> I tried to replicate this in a freshly-installed 13.2 VM, and could
> not, which is unsurprising because the FreeBSD installation process
> does not let you skip selecting a timezone --- which creates
> /etc/localtime AFAICT. So I'm unconvinced that we ought to worry
> about the case where that's not there. How is it that the CI image
> lacks that file?
I don't know why it lacks the file - the CI image is based on the google cloud
image freebsd maintains / publishes ([1][2]). Which doesn't have /etc/localtime.
I've now added a "tzsetup UTC" to the image generation, which fixes the test
failure.
> (And could it be that we had one in the predecessor 13.1 image?)
No, I checked, and it's not in there either... It looks like the difference is
that 13.1 reads the UTC zoneinfo in that case, whereas 13.2 doesn't.
Upstream 13.1 image:
truss date 2>&1|grep -E 'open|stat'
...
open("/etc/localtime",O_RDONLY,0101401200) ERR#2 'No such file or
directory'
open("/usr/share/zoneinfo/UTC",O_RDONLY,00) = 3 (0x3)
fstat(3,{ mode=-r--r--r-- ,inode=351417,size=118,blksize=32768 }) = 0 (0x0)
open("/usr/share/zoneinfo/posixrules",O_RDONLY,014330460400) = 3 (0x3)
fstat(3,{ mode=-r--r--r-- ,inode=356621,size=3535,blksize=32768 }) = 0 (0x0)
fstat(1,{ mode=p- ,inode=696,size=0,blksize=4096 }) = 0 (0x0)
Upstream 13.2 image:
open("/etc/localtime",O_RDONLY,01745)ERR#2 'No such file or
directory'
fstat(1,{ mode=p- ,inode=658,size=0,blksize=4096 }) = 0 (0x0)
Why not reading the UTC zone leads to timestamps being out of range, I do not
know...
Greetings,
Andres Freund
[1] https://wiki.freebsd.org/GoogleCloudPlatform
[2] https://cloud.google.com/compute/docs/images#freebsd
Re: pltcl tests fail with FreeBSD 13.2
Andres Freund writes: > I saw that CI image builds for freebsd were failing, because 13.1, used until > now, is EOL. Update to 13.2, no problem, I thought. Ran a CI run against 13.2 > - unfortunately that failed. In pltcl of all places. I tried to replicate this in a freshly-installed 13.2 VM, and could not, which is unsurprising because the FreeBSD installation process does not let you skip selecting a timezone --- which creates /etc/localtime AFAICT. So I'm unconvinced that we ought to worry about the case where that's not there. How is it that the CI image lacks that file? (And could it be that we had one in the predecessor 13.1 image?) regards, tom lane
Re: pltcl tests fail with FreeBSD 13.2
Hi,
On 2023-07-31 12:15:10 -0700, Andres Freund wrote:
> It sure looks like freebsd 13.2 tcl is just busted. Notably it can't even
> parse what it generates:
>
> echo 'puts [clock scan [clock format [clock seconds] -format "%Y/%m/%d"]
> -format "%Y/%m/%d"]'|tclsh8.6
>
> Which works on 13.1 (and other operating systems), without a problem.
>
> I used truss as a very basic way to see differences between 13.1 and 13.2 -
> the big difference was .2 failing just after
> access("/etc/localtime",F_OK) ERR#2 'No such file or
> directory'
> open("/etc/localtime",O_RDONLY,077)ERR#2 'No such file or
> directory'
>
> whereas 13.1 also saw that, but then continued to
>
> issetugid()= 0 (0x0)
> open("/usr/share/zoneinfo/UTC",O_RDONLY,00)= 3 (0x3)
> fstat(3,{ mode=-r--r--r-- ,inode=351417,size=118,blksize=32768 }) = 0 (0x0)
> ...
>
> which made me test specifying the timezone explicitly:
> echo 'puts [clock scan [clock format [clock seconds] -format "%Y/%m/%d"
> -timezone "UTC"] -format "%Y/%m/%d" -timezone "UTC"]'|tclsh8.6
>
> Which, surprise, works.
>
> So does specifying the timezone via the TZ='UTC' environment variable.
>
>
> I guess there could be a libc behaviour change or such around timezones? I do
> see
> https://www.freebsd.org/releases/13.2R/relnotes/
> "tzcode has been upgraded to version 2022g with improved timezone change
> detection and reliability fixes."
One additional datapoint: If I configure the timezone with "tzsetup" (which
creates /etc/localtime), the problem vanishes as well.
Greetings,
Andres Freund
