Am 15.11.2022 um 00:58 hat John Snow geschrieben:
On Mon, Nov 14, 2022 at 5:56 AM Kevin Wolf <kwolf@redhat.com> wrote:
Am 11.11.2022 um 20:20 hat Stefan Hajnoczi geschrieben:
Hanna Reitz (9):
block/mirror: Do not wait for active writes
block/mirror: Drop mirror_wait_for_any_operation()
block/mirror: Fix NULL s->job in active writes
iotests/151: Test that active mirror progresses
iotests/151: Test active requests on mirror start
block: Make bdrv_child_get_parent_aio_context I/O
block-backend: Update ctx immediately after root
block: Start/end drain on correct AioContext
tests/stream-under-throttle: New test
Hi Hanna,
This test is broken, probably due to the minimum Python version:
https://gitlab.com/qemu-project/qemu/-/jobs/3311521303
This is exactly the problem I saw with running linters in a gating CI,
but not during 'make check'. And of course, we're hitting it during the
-rc phase now. :-(
I mean. I'd love to have it run in make check too. The alternative was
never seeing this *anywhere* ...
What is the problem with running it in 'make check'? The additional
dependencies? If so, can we run it automatically if the dependencies
happen to be fulfilled and just skip it otherwise?
If I have to run 'make -C python check-pipenv' manually, I can guarantee
you that I'll forget it more often than I'll run it.
...but I'm sorry it's taken me so long to figure out how to get this
stuff to work in "make check" and also from manual iotests runs
without adding any kind of setup that you have to manage. It's just
fiddly, sorry :(
But yes, it seems that asyncio.TimeoutError should be used instead of
asyncio.exceptions.TimeoutError, and Python 3.6 has only the former.
I'll fix this up and send a v2 if it fixes check-python-pipenv.
Hopefully this goes away when we drop 3.6. I want to, but I recall
there was some question about some platforms that don't support 3.7+
"by default" and how annoying that was or wasn't. We're almost a year
out from 3.6 being EOL, so maybe after this release it's worth a crack
to see how painful it is to move on.
If I understand the documentation right, asyncio.TimeoutError is what
you should be using either way. That it happens to be a re-export from
the internal module asyncio.exceptions seems to be more of an
implementation detail, not the official interface.