On Sat, Jan 13, 2024 at 9:32 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > It looks like every recent cfbot run has failed in the > FreeBSD-13-Meson build, even if it worked in other ones. > The symptoms are failures in the TAP tests that try to > use interactive_psql: > > Can't call method "slave" on an undefined value at > /usr/local/lib/perl5/site_perl/IPC/Run.pm line 2889. > > I suspect that we are looking at some bug in IPC::Run that exists in > the version that that FreeBSD release has (but not, seemingly, > elsewhere in the community), and that was mostly harmless until > c53859295 made all Perl warnings fatal. Not sure what we want > to do about this.
Right, I see this locally on my FreeBSD box. Reverting the fatal warnings thing doesn't help, it's more broken than that. I tried to understand https://github.com/cpan-authors/IPC-Run/blob/master/lib/IPC/Run.pm https://github.com/cpan-authors/IO-Tty/blob/master/Pty.pm but I am not good at perl. I think the error means that in ## Close all those temporary filehandles that the kids needed. for my $pty ( values %{ $self->{PTYS} } ) { close $pty->slave; } the variable $pty holds undef, so then we have to find out where undef was put into $self->{PTYS}. There is a place that does: ## Just flag the pyt's existence for now. It'll be ## converted to a real IO::Pty by _open_pipes. $self->{PTYS}->{$pty_id} = undef; We can see that this started a couple of days ago: https://github.com/postgres/postgres/commits/master/ But at older commits I see the problem locally too, so, yeah, it must be coming from where else. Looking at the relevant packages p5-IPC-Run and p5-IO-Tty I see that they recently moved to 20231003.0 and 1.18, respectively. Downgrading p5-IPC-Run to p5-IPC-Run-20220807.0.pkg was not enough. Downgrading p5-IO-Tty to p5-IO-Tty-1.17.pkg allowed psql/010_tab_completion to pass with either version of p5-IPC-Run. The answer may lie in the commits between those versions here: https://github.com/cpan-authors/IO-Tty/commits/master/ I see that Debian Bookwork is still using 1.17, which fits with your guess that FreeBSD is just breaking first because it is using a newer version.
