Re: win+Meson test failures due to ps/build-meson-fixes-0130 topic?

[Jeff King <peff@peff.net>]

On Wed, Feb 26, 2025 at 06:45:06AM +0100, Patrick Steinhardt wrote:

> > I'll also note that in one of my earlier attempts (which had
> > ek/mingw-rename-symlink merged before po/meson-perl-fix), one of the
> > 10 "win+Meson test" jobs failed ("win+Meson test (7)" to be exact).
> > Rerunning the failed test succeeds, so there must be something flaky
> > in t0610-reftable-basics test that is exposed by this change,
> > perhaps?
> > 
> >   https://github.com/git/git/actions/runs/13528071468/attempts/1
> >   https://github.com/git/git/actions/runs/13528071468/attempts/2
> > 
> > As the ps/build-meson-fixes-0130 topic has 13 changes, and each
> > iteration in the above exercise took somewhere around 20 minutes, I
> > won't dive into the topic myself to identify which one of these
> > individual topics causes the breakage.  This however gave me enough
> > to go on to today's 'master' integration (mainly, by mark the topic
> > to be held in 'next' until this gets resolved, and deal with the
> > other topics).
> 
> Hm, interesting. I didn't notice those issues in our CI. Thanks for
> diving into it, I'll figure out what has happened here.

I spent a little time poking at this yesterday. Here's what I found in
case it helps.

I arbitrarily picked t0210 to poke at because it's short and it was
failing. Interestingly, the failing command was clone, with the client
complaining that it did not understand the server's protocol version
response.

Running with GIT_TRACE_PACKET shows that we got a line:

  version 2\r\n

And the extra "\r" confuses the parser. So perhaps something in the
build changed that is affecting how CRLF is output by standard
functions? That would explain why we see failures all over the test
suite. I didn't dig into any other cases, though.

-Peff