Re: [PULL 00/23] QEMU changes for 7.0 soft freeze

[Thomas Huth]

On 09/03/2022 17.07, Paolo Bonzini wrote:
> On 3/9/22 10:46, Thomas Huth wrote:
> > > That one also drops the progress report of non-failed tests, so I'm not 
> > > sure it's an improvement.
> >
> > That only works here anyway if I don't run "make check" with the "-jX" 
> > option ... which I hardly do, since it then takes forever to finish the 
> > testing. So at least for me that's not really a reason.
>
> The point of having a separate "make check-block" was to have the progress 
> report ("--verbose --num-processes 1" gives the progress report, the same 
> with --print-errorlogs doesn't).

Yes, understood, but again, that only works for me if I run:

 make check-block

But if I run:

 make check-block -j8

I only get one single line saying:

 [1/1] 🌓 qemu:block / qemu-iotests qcow2                   2s

And the progress report is only printed in one go at the end, after all 
tests have finished. Since I'm using -jX with X > 1 by default, the progress 
report that you get with -j1 is simply no advantage for me. Is your build 
behaving differently? ... then this maybe depends on the meson version? I 
think my build is using the one from the submodule, version 0.59.3.

> > Ok ... could you maybe ask the meson folks to include the fix in the 
> > upcoming stable releases?
>
> Did it, hopefully will be in 0.61.3.

Great!

... but I guess this will be too late for QEMU 7.0 ?

I just sent out

 "[PATCH v4] tests: Do not treat the iotests as separate meson test target 
anymore"

in case we want to continue with the TAP mode for 7.0 (only updated the 
patch description) ... but since we're in freeze mode already, I'm also fine 
if you say that this is not appropriate for QEMU 7.0 anymore and that we 
should revert the TAP patches instead.

> > ... the meson master branch has been switched to Python 3.7 already,
> > but AFAIU we still target Python 3.6 in QEMU, so I'm not sure whether
> > we will be able to jump on the next main release with QEMU... we
> > might need to stick with a 0.61.x release for a while in the future?
> 3.6 was EOL'd in December, so I expect that QEMU will bump the requirement 
> sometime this year too.

Yes, that makes sense ... I was just thinking about RHEL 8 and its clones, 
which have Python 3.6 as default ... but I think they also ship Python 3.8 
as alternative, so I guess it should be fine to increase the minimum Python 
version for QEMU 7.1 ?

 Thomas