Hi Junio, On Fri, 15 Feb 2019, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > On Thu, 14 Feb 2019, Junio C Hamano wrote: > > > >> "Johannes Schindelin via GitGitGadget" <gitgitgadget@xxxxxxxxx> > >> writes: > >> > >> > From: Johannes Schindelin <johannes.schindelin@xxxxxx> > >> > > >> > In cc95bc2025 (t5562: replace /dev/zero with a pipe from > >> > generate_zero_bytes, 2019-02-09), we replaced usage of /dev/zero (which > >> > is not available on NonStop, apparently) by a Perl script snippet to > >> > generate NUL bytes. > >> > > >> > Sadly, it does not seem to work on NonStop, as t5562 reportedly hangs. > >> > ... > >> > In the end, though, what counts is that this here change incidentally > >> > fixes that hang (maybe also on NonStop?). Even more positively, it gets > >> > rid of yet another unnecessary Perl invocation. > >> > >> Thanks for a quick band-aid. > >> > >> Will apply directly to 'master' so that we won't forget before -rc2. > > > > Thank you, that will be good, as the builds still seem to fail. All of > > them. > > Actually, I am really tempted to instead not apply this, but revert > that genzerobytes Perl thing. This assumes that your Azure thing > did not have the breakage before we applied that patchset. What do > you think? Honestly, I don't care, as long as we can stop *all* of the CI builds failing, soon. So whether you revert that commit, or apply mine, it is up to you, but I'd really rather not see another batch of useless builds. > Trying four or more possible band-aids that may or may not work > without knowing what the real cause of the hangs are is not > something I want to see people spend excessive time of theirs on > this close to the final. I'd rather avoid distraction and see > people spend their cycles on bugs that matter, instead of trying to > chase test breakages that have always been present for those without > /dev/zero. I am not fundamentally opposed to supporting those > without /dev/zero but I'd prefer to see it happen in 'pu' until we > identify and fix the real cause---which may well be a real bug in > the http-backend stuff---and the time to do that is not during the > rc period where we close the tree for new features and non-regression > fixes. While I am quite positive that my patch helps (even on NonStop, because reportedly the hang is in .13 while my fix is about .15, which the commit that caused the regression also touches), I am okay with holding off until after v2.21.0. But in the long run, the only sane thing really is to move more and more functionality in the test suite for which we rely on Perl into test-tool. It is really the only thing that makes sense, from the perspectives of performance, robustness and portability. Ciao, Dscho
