On Sun, Feb 16, 2025 at 08:42:50PM -0500, Andres Freund wrote: > On February 16, 2025 7:50:18 PM EST, Tom Lane <t...@sss.pgh.pa.us> wrote: > >Noah Misch <n...@leadboat.com> writes: > >> On Sun, Feb 16, 2025 at 06:18:44PM -0500, Tom Lane wrote: > >>> I think that > >>> IPC::Run may be screwing up here, because I have seen non-Windows > >>> CI failures that look like it didn't read all the stderr output. > >>> For example, this pgbench test failure on macOS from [1]: > > > >> https://github.com/cpan-authors/IPC-Run/commit/2128df3bbcac7e733ac46302c4b1371ffb88fe14 > >> fixed that one. > > > >Ah. Do we know whether that fix has made it into our CI images? > >(Or anywhere else, for that matter?) > > The CI images are regenerated three times a week, but for most OSs, they will > only install perl modules via the applicable packaging method, so it'll > depend on when they pick up that version. > > On Windows cpan is used, so it should pick that new version fairly quickly if > a release has been made. > > On macos we can't currently use images, so we just cache all the installed > macports packages. The cache is keyed by OS version and list of packages to > be installed, with no other forced invalidation right now. So it's hard to > predict when a new version of a package will be picked up and it will differ > between git repositories. I've been wondering whether the cached macports > install should just be regularly generated instead, along the other ci images.
The change is not in a release yet. We could have macos install IPC::Run from github, or I could get a release cut so it can make its way to macports. https://ports.macports.org/port/p5.34-ipc-run/builds/ suggests it ingested the last release within a couple days of release, so macports itself may add negligible latency.
