Hi, this series aims to support Python 3.14; a large part of how it
achieves this is by backporting various changes that have been made to
the python-qemu-qmp standalone library to ensure that our in-tree
version is very nearly byte identical to the standalone version.

Several of Dan's patches are appended here which remove all deprecated
behavior from our test suite and enables printing warnings whenever
deprecated behavior is used so we will be able to catch it more readily
in the future.

Following this series, I intend to drop the QMP library from the qemu
tree once and for all so that they do not desynchronize again. The
standalone library needs to drop avocado-framework and cut a v0.0.4
release first, but it's currently my top priority to end this
embarrassing patch of duplicated code and maintenance.

Reviewers: try applying this series and using diff to compare the
qemu.git/python/qemu/qmp and python-qemu-qmp.git/qemu/qmp directories;
you should find only five differences: three instances of LICENSE text
being slightly different (pointing to LICENSE vs COPYING) and two
instances of a pylint ignore that are not needed in qemu.git due to
slightly different linter configuration in qemu.git/python/setup.cfg.

If further changes are warranted, it is my preference to try to
"upstream" them first before backporting them here instead of trying to
amend this series.

RFC: Should I squash the last two backport patches? One technically
introduces a regression which breaks our "no regressions in series"
rule, but makes the per-patch relationship murkier. Please let me know.

--js

Adam Dorsey (1):
  python: backport 'feat: allow setting read buffer limit'

Daniel P. Berrangé (5):
  iotests: drop compat for old version context manager
  python: ensure QEMUQtestProtocol closes its socket
  iotests/147: ensure temporary sockets are closed before exiting
  iotests/151: ensure subprocesses are cleaned up
  iotests/check: always enable all python warnings

John Snow (13):
  python: backport 'Change error classes to have better repr methods'
  python: backport 'EventListener: add __repr__ method'
  python: backport 'kick event queue on legacy event_pull()'
  python: backport 'protocol: adjust logging name when changing client
    name'
  python: backport 'drop Python3.6 workarounds'
  python: backport 'qmp-shell: add common_parser()'
  python: backport 'make require() preserve async-ness'
  python: backport 'qmp-shell-wrap: handle missing binary gracefully'
  python: backport 'qmp-tui: Do not crash if optional dependencies are
    not met'
  python: backport 'Remove deprecated get_event_loop calls'
  python: backport '*really* remove get_event_loop'
  python: backport 'python: avoid creating additional event loops per
    thread'
  python: synchronize qemu.qmp documentation

 python/qemu/machine/qtest.py     |   2 +
 python/qemu/qmp/__init__.py      |   3 +-
 python/qemu/qmp/error.py         |   7 +-
 python/qemu/qmp/events.py        |  50 ++++++--
 python/qemu/qmp/legacy.py        |  46 +++++---
 python/qemu/qmp/message.py       |  22 ++--
 python/qemu/qmp/models.py        |   8 +-
 python/qemu/qmp/protocol.py      | 194 +++++++++++++++++++------------
 python/qemu/qmp/qmp_client.py    | 155 +++++++++++++++++-------
 python/qemu/qmp/qmp_shell.py     | 165 ++++++++++++++++++--------
 python/qemu/qmp/qmp_tui.py       |  30 +++--
 python/qemu/qmp/util.py          | 143 ++++++-----------------
 python/tests/protocol.py         |  10 +-
 tests/qemu-iotests/147           |   1 +
 tests/qemu-iotests/151           |   5 +
 tests/qemu-iotests/check         |   4 +
 tests/qemu-iotests/testenv.py    |   7 +-
 tests/qemu-iotests/testrunner.py |   9 +-
 18 files changed, 532 insertions(+), 329 deletions(-)

-- 
2.50.1

On Mon, Sep 01, 2025 at 04:26:42PM -0400, John Snow wrote:
> RFC: Should I squash the last two backport patches? One technically
> introduces a regression which breaks our "no regressions in series"
> rule, but makes the per-patch relationship murkier. Please let me know.

What is the effect of the regression ?

If someone is running 'make check' (or a variant thereof), through
a "git bisect" will this regression be significant enough to break
their git bisect ?


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

On Tue, Sep 2, 2025, 12:54 PM Daniel P. Berrangé <berrange@redhat.com>
wrote:

> On Mon, Sep 01, 2025 at 04:26:42PM -0400, John Snow wrote:
> > RFC: Should I squash the last two backport patches? One technically
> > introduces a regression which breaks our "no regressions in series"
> > rule, but makes the per-patch relationship murkier. Please let me know.
>
> What is the effect of the regression ?
>
> If someone is running 'make check' (or a variant thereof), through
> a "git bisect" will this regression be significant enough to break
> their git bisect ?
>

It could, yes. To avoid it I need to squash the latest get_event_loop
change in to the second-to-last one.

I guess I'll just notate that it's cherry-picked from two commits and
include both commit messages.

Does that sound OK? (I've never really "cherry picked" across repositories
like this where the file paths do not actually match, so it's been a bit of
a manual affair.)


>
> With regards,
> Daniel
> --
> |: https://berrange.com      -o-
> https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-
> https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-
> https://www.instagram.com/dberrange :|
>
>

On Tue, Sep 02, 2025 at 12:58:24PM -0400, John Snow wrote:
> On Tue, Sep 2, 2025, 12:54 PM Daniel P. Berrangé <berrange@redhat.com>
> wrote:
> 
> > On Mon, Sep 01, 2025 at 04:26:42PM -0400, John Snow wrote:
> > > RFC: Should I squash the last two backport patches? One technically
> > > introduces a regression which breaks our "no regressions in series"
> > > rule, but makes the per-patch relationship murkier. Please let me know.
> >
> > What is the effect of the regression ?
> >
> > If someone is running 'make check' (or a variant thereof), through
> > a "git bisect" will this regression be significant enough to break
> > their git bisect ?
> >
> 
> It could, yes. To avoid it I need to squash the latest get_event_loop
> change in to the second-to-last one.
> 
> I guess I'll just notate that it's cherry-picked from two commits and
> include both commit messages.
> 
> Does that sound OK? (I've never really "cherry picked" across repositories
> like this where the file paths do not actually match, so it's been a bit of
> a manual affair.)

Yeah, just noting that its a combo of two commits sounds good to me.


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|