Обсуждение: 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
On Mon, Sep 22, 2025 at 3:35 PM Jacob Champion <jacob.champion@enterprisedb.com> wrote: > 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! I got stuck on this a few weeks back and had to put it down. Of all things, I couldn't figure out how to download a Perl module in a secure manner across _all_ of our supported platforms. I tried to get --verify mode working with cpanm and found that it would simply continue downloading and running code without verification if the prerequisites weren't installed. (I am now reevaluating my own personal use of cpanm.) The state of the world there looks horrifying [1, 2]. I even considered pulling the tarball straight from Github and hardcoding the shasum for it, but I haven't been able to figure out how to Just Install That Thing I Downloaded via a blessed Perl utility. (CPAN itself appears to _require_ interactive use at first run, making it very difficult to use in a CI...) Anyone have a recipe for doing this? --Jacob [1] https://blogs.perl.org/users/neilb/2021/11/addressing-cpan-vulnerabilities-related-to-checksums.html [2] https://github.com/miyagawa/cpanminus/pull/674
Hi, On 2025-10-31 14:40:41 -0700, Jacob Champion wrote: > On Mon, Sep 22, 2025 at 3:35 PM Jacob Champion > <jacob.champion@enterprisedb.com> wrote: > > 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! > > I got stuck on this a few weeks back and had to put it down. Of all > things, I couldn't figure out how to download a Perl module in a > secure manner across _all_ of our supported platforms. I tried to get > --verify mode working with cpanm and found that it would simply > continue downloading and running code without verification if the > prerequisites weren't installed. (I am now reevaluating my own > personal use of cpanm.) The state of the world there looks horrifying > [1, 2]. Yuck. > (CPAN itself appears to _require_ interactive use at first > run, making it very difficult to use in a CI...) I think I had to figure this out in the past <dig>, ah, yea: https://github.com/anarazel/pg-vm-images/blob/8ac88f59e368f35a63d3a0635ee7baf3436d5ee3/scripts/windows_install_mingw64.ps1#L25-L27 msys '(echo; echo o conf recommends_policy 0; echo notest install IPC::Run) | cpan' Greetings, Andres Freund
On Fri, Oct 31, 2025 at 2:55 PM Andres Freund <andres@anarazel.de> wrote: > I think I had to figure this out in the past <dig>, ah, yea: > https://github.com/anarazel/pg-vm-images/blob/8ac88f59e368f35a63d3a0635ee7baf3436d5ee3/scripts/windows_install_mingw64.ps1#L25-L27 > > msys '(echo; echo o conf recommends_policy 0; echo notest install IPC::Run) | cpan' Heh. Okay, I'll give a version of that a shot. Thanks! --Jacob