Обсуждение: Updating IPC::Run in CI?
Hi all, Andres pointed out that one of my new OAuth tests has flaked on NetBSD [1]. The final line of debugging output is missing from the stderr coming from psql. I haven't ruled out a bug in my implementation, but I also remembered that there was some discussion on the list about stderr being lost by IPC::Run in rare circumstances [2], and that particular bug has since been fixed [3]. Is it possible to (safely) switch the CI images to use the most recent IPC::Run, so we can make use of Noah's fixes? NetBSD is currently running 20231003.0. Thanks, --Jacob [1] https://cirrus-ci.com/task/4537227113398272 [2] https://www.postgresql.org/message-id/fb666566-32bb-9c36-9c2e-3949b7a061bc%40gmail.com [3] https://github.com/cpan-authors/IPC-Run/issues/176
Hi, On 2025-09-18 10:08:49 -0700, Jacob Champion wrote: > Andres pointed out that one of my new OAuth tests has flaked on NetBSD > [1]. The final line of debugging output is missing from the stderr > coming from psql. > > I haven't ruled out a bug in my implementation, but I also remembered > that there was some discussion on the list about stderr being lost by > IPC::Run in rare circumstances [2], and that particular bug has since > been fixed [3]. Is it possible to (safely) switch the CI images to use > the most recent IPC::Run, so we can make use of Noah's fixes? NetBSD > is currently running 20231003.0. A lot of things are safely possible :). The stuff that's installed in the images is controlled by a bunch of scripts in my pg-vm-images repository. For netbsd the relevant install is in https://github.com/anarazel/pg-vm-images/blob/main/scripts/bsd/netbsd-prep-postgres.sh As you can see we currently don't install packages from outside netbsd's package repository. We could change that and install IPC::Run via cpan, but imo it's obviously nicer - and more representative of real world setups - if we just rely on OS/distro packages. I don't know what would be required to get netbsd to upate their IPC::Run package. https://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/devel/p5-IPC-Run/index.html If it were merged into netbsd, it'd be used for the CI images within a few days, they are regenerated every few days [1] (or if a change the the image sources is merged). Greetings, Andres Freund [1] the cron-like expression is "0 30 0 ? * SUN,TUE,THU *", probably because I didn't want to have to look at failures on Friday, Saturday
On Thu, Sep 18, 2025 at 11:18 AM Andres Freund <andres@anarazel.de> wrote:
> As you can see we currently don't install packages from outside netbsd's
> package repository. We could change that and install IPC::Run via cpan, but
> imo it's obviously nicer - and more representative of real world setups - if
> we just rely on OS/distro packages.
I guess there's a bit of a philosophical question there: for a
test-only dependency in our CI, do we want it to be "representative of
real-world setups", or do we want it to work as well as it can?
> I don't know what would be required to get netbsd to upate their IPC::Run
> package.
It's listed as outdated here:
https://www.netbsd.org/~wiz/perl.html
but I'm not entirely clear on the process for requesting an update. I
guess I could ask pkgsrc-users@?
Thanks,
--Jacob
Hi, On Thu, 18 Sept 2025 at 21:18, Andres Freund <andres@anarazel.de> wrote: > > Hi, > > On 2025-09-18 10:08:49 -0700, Jacob Champion wrote: > > Andres pointed out that one of my new OAuth tests has flaked on NetBSD > > [1]. The final line of debugging output is missing from the stderr > > coming from psql. > > > > I haven't ruled out a bug in my implementation, but I also remembered > > that there was some discussion on the list about stderr being lost by > > IPC::Run in rare circumstances [2], and that particular bug has since > > been fixed [3]. Is it possible to (safely) switch the CI images to use > > the most recent IPC::Run, so we can make use of Noah's fixes? NetBSD > > is currently running 20231003.0. > > A lot of things are safely possible :). > > The stuff that's installed in the images is controlled by a bunch of scripts > in my pg-vm-images repository. For netbsd the relevant install is in > > https://github.com/anarazel/pg-vm-images/blob/main/scripts/bsd/netbsd-prep-postgres.sh > > As you can see we currently don't install packages from outside netbsd's > package repository. We could change that and install IPC::Run via cpan, but > imo it's obviously nicer - and more representative of real world setups - if > we just rely on OS/distro packages. I have not checked it yet but we are on NetBSD 10.0 [1]. I thought upgrading to 10.1 might help... Apparently it does not, 10.1 too uses p5-IPC-Run-20231003 [2]. [1] https://github.com/anarazel/pg-vm-images/blob/main/packer/netbsd.pkrvars.hcl#L58C1-L58C75 [2] https://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/index-all.html -- Regards, Nazir Bilal Yavuz Microsoft
Hi, On 2025-09-18 11:48:15 -0700, Jacob Champion wrote: > On Thu, Sep 18, 2025 at 11:18 AM Andres Freund <andres@anarazel.de> wrote: > > As you can see we currently don't install packages from outside netbsd's > > package repository. We could change that and install IPC::Run via cpan, but > > imo it's obviously nicer - and more representative of real world setups - if > > we just rely on OS/distro packages. > > I guess there's a bit of a philosophical question there: for a > test-only dependency in our CI, do we want it to be "representative of > real-world setups", or do we want it to work as well as it can? I don't think there's a hard and fast rule, but I do think that it's a reasonably important goal to make sure that the OS/distro actually can build packages - and as part of that test those packages - reasonably well. So requiring wildly different things than what is available on $platform to run the tests reliably is bad. Greetings, Andres Freund
On Thu, Sep 18, 2025 at 12:16 PM Andres Freund <andres@anarazel.de> wrote: > I don't think there's a hard and fast rule, but I do think that it's a > reasonably important goal to make sure that the OS/distro actually can build > packages - and as part of that test those packages - reasonably well. So > requiring wildly different things than what is available on $platform to run > the tests reliably is bad. I agree with that in general, but if a buildfarm operator reports running into a already-fixed IPC::Run bug on an older distribution, presumably we're going to tell them to install a newer IPC::Run, right? --Jacob
On Thu, Sep 18, 2025 at 11:49 AM Nazir Bilal Yavuz <byavuz81@gmail.com> wrote: > I have not checked it yet but we are on NetBSD 10.0 [1]. I thought > upgrading to 10.1 might help... Apparently it does not, 10.1 too uses > p5-IPC-Run-20231003 [2]. Right. On the Debian side, looks like bookworm is stuck on 20220807.0 -- and updating to trixie won't help us either; that just gets us up to 20231003.0. --Jacob
On Thu, Sep 18, 2025 at 12:35 PM Jacob Champion <jacob.champion@enterprisedb.com> wrote: > Right. On the Debian side, looks like bookworm is stuck on 20220807.0 > -- and updating to trixie won't help us either; that just gets us up > to 20231003.0. To more explicitly defend my position here: I can request updates from package maintainers for <insert OS here>, but if the end result is that our LTS distributions will still be lagging, there's not much point. I'd rather bake the latest IPC::Run into our CI, and I'm happy to contribute code and cycles towards that. Any other opinions? Thanks, --Jacob
Jacob Champion <jacob.champion@enterprisedb.com> writes:
> To more explicitly defend my position here: I can request updates from
> package maintainers for <insert OS here>, but if the end result is
> that our LTS distributions will still be lagging, there's not much
> point. I'd rather bake the latest IPC::Run into our CI, and I'm happy
> to contribute code and cycles towards that.
+1. Maybe we can stop doing this at some future time when all those
OSes have absorbed an up-to-date IPC::Run, but for the near term we're
merely exposing ourselves to known failures.
regards, tom lane
Hi, On 2025-09-22 13:17:09 -0700, Jacob Champion wrote: > On Thu, Sep 18, 2025 at 12:35 PM Jacob Champion > <jacob.champion@enterprisedb.com> wrote: > > Right. On the Debian side, looks like bookworm is stuck on 20220807.0 > > -- and updating to trixie won't help us either; that just gets us up > > to 20231003.0. > > To more explicitly defend my position here: I can request updates from > package maintainers for <insert OS here>, but if the end result is > that our LTS distributions will still be lagging, there's not much > point. I'd rather bake the latest IPC::Run into our CI, and I'm happy > to contribute code and cycles towards that. > > Any other opinions? I think your position has merit. However, I'd like to have at least one of the tasks continue to use the non-built-in IPC::Run. I'll review patches installing a newer IPC::Run. Seperately, I wonder if we ought to add a warning to configure/meson output about IPC::Run < 2025... Greetings, Andres Freund
On Mon, Sep 22, 2025 at 1:24 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > +1. Maybe we can stop doing this at some future time when all those > OSes have absorbed an up-to-date IPC::Run, but for the near term we're > merely exposing ourselves to known failures. On Mon, Sep 22, 2025 at 1:27 PM Andres Freund <andres@anarazel.de> wrote: > I think your position has merit. However, I'd like to have at least one of the > tasks continue to use the non-built-in IPC::Run. > > I'll review patches installing a newer IPC::Run. I will work on that, then. Thanks both! > Seperately, I wonder if we ought to add a warning to configure/meson output > about IPC::Run < 2025... Probably. I imagine it's going to be very noisy for a bit, though. --Jacob