The following changes since commit afe653676dc6dfd49f0390239ff90b2f0052c2b8:

  Merge tag 'audio-pull-request' of https://gitlab.com/marcandre.lureau/qemu into staging (2026-02-23 14:03:50 +0000)

are available in the Git repository at:

  https://gitlab.com/jsnow/qemu.git tags/python-pull-request

for you to fetch changes up to 4e55bb4be53bc7a5e3fe1429af12d2e3090049a5:

  python: add setuptools and wheel dependencies (2026-02-24 13:11:29 -0500)

----------------------------------------------------------------

----------------------------------------------------------------

John Snow (19):
  python/mkvenv: create timestamp file for each group "ensured"
  python/mkvenv: bump 'qemu.qmp' dependency for testdeps
  python/mkvenv: add 'tooling' and 'functests' dependency groups
  python/mkvenv: add mechanism to install local package(s)
  meson, mkvenv: add functests custom target
  tests: Use configured python to run GitLab iotests
  iotests: tolerate being run outside of pyvenv
  tests: use "run" script to execute device-crash-test
  tests/lcitool: update lcitool to latest version
  tests/lcitool: add python3 wheel and setuptools deps for qemu
  python: add vendored qemu.qmp package
  meson, mkvenv: make functional tests depend on functests group
  meson, mkvenv: add qemu.git/python/qemu package to pythondeps.toml
  configure: unconditionally install "tooling" group
  tests: replace check-venv with vm-venv target
  scripts: nudge users to use 'run' script for scripts that import
    qemu.qmp
  python: delete qemu.qmp
  python: update README.rst to reflect qemu.qmp's removal
  python: add setuptools and wheel dependencies

 python/README.rst                             |   52 +-
 configure                                     |    2 +-
 meson.build                                   |    1 +
 .gitlab-ci.d/buildtest.yml                    |   26 +-
 .gitlab-ci.d/cirrus/freebsd-14.vars           |    2 +-
 .gitlab-ci.d/cirrus/macos-14.vars             |    2 +-
 .gitlab-ci.d/windows.yml                      |    2 +
 python/qemu/qmp/__init__.py                   |   60 -
 python/qemu/qmp/error.py                      |   53 -
 python/qemu/qmp/events.py                     |  751 -----------
 python/qemu/qmp/legacy.py                     |  339 -----
 python/qemu/qmp/message.py                    |  217 ----
 python/qemu/qmp/models.py                     |  146 ---
 python/qemu/qmp/protocol.py                   | 1101 -----------------
 python/qemu/qmp/py.typed                      |    0
 python/qemu/qmp/qmp_client.py                 |  732 -----------
 python/qemu/qmp/qmp_shell.py                  |  689 -----------
 python/qemu/qmp/qmp_tui.py                    |  665 ----------
 python/qemu/qmp/util.py                       |  150 ---
 python/qemu/utils/qom_fuse.py                 |    1 -
 python/scripts/mkvenv.py                      |   43 +-
 python/scripts/vendor.py                      |    2 +
 python/setup.cfg                              |   31 +-
 python/tests/minreqs.txt                      |    8 +-
 python/tests/protocol.py                      |  596 ---------
 python/wheels/qemu_qmp-0.0.5-py3-none-any.whl |  Bin 0 -> 72263 bytes
 pythondeps.toml                               |   21 +-
 pyvenv/meson.build                            |   27 +
 scripts/compare-machine-types.py              |    7 +-
 scripts/device-crash-test                     |    5 +-
 scripts/qmp/qemu-ga-client                    |   13 +-
 scripts/qmp/qmp-shell                         |   13 +-
 scripts/qmp/qmp-shell-wrap                    |   13 +-
 scripts/qmp/qom-fuse                          |   13 +-
 scripts/qmp/qom-get                           |   13 +-
 scripts/qmp/qom-list                          |   13 +-
 scripts/qmp/qom-set                           |   13 +-
 scripts/qmp/qom-tree                          |   13 +-
 scripts/qmp_helper.py                         |    9 +-
 scripts/render_block_graph.py                 |   10 +-
 scripts/simplebench/bench_block_job.py        |   10 +-
 tests/Makefile.include                        |   22 +-
 tests/docker/dockerfiles/alpine.docker        |    6 +-
 tests/docker/dockerfiles/centos9.docker       |  242 ++--
 .../dockerfiles/fedora-rust-nightly.docker    |  262 ++--
 .../dockerfiles/fedora-win64-cross.docker     |  162 +--
 tests/docker/dockerfiles/fedora.docker        |  262 ++--
 tests/docker/dockerfiles/opensuse-leap.docker |    1 +
 tests/functional/meson.build                  |    5 +-
 tests/lcitool/libvirt-ci                      |    2 +-
 tests/lcitool/mappings.yml                    |    2 +-
 tests/lcitool/projects/qemu.yml               |    2 +
 tests/lcitool/refresh                         |    8 +-
 tests/migration-stress/guestperf/engine.py    |   15 +-
 tests/qemu-iotests/testenv.py                 |   25 +-
 tests/vm/Makefile.include                     |   20 +-
 tests/vm/generated/freebsd.json               |    2 +
 tests/vm/haiku.x86_64                         |    2 +
 tests/vm/netbsd                               |    1 +
 tests/vm/openbsd                              |    3 +
 60 files changed, 766 insertions(+), 6142 deletions(-)
 delete mode 100644 python/qemu/qmp/__init__.py
 delete mode 100644 python/qemu/qmp/error.py
 delete mode 100644 python/qemu/qmp/events.py
 delete mode 100644 python/qemu/qmp/legacy.py
 delete mode 100644 python/qemu/qmp/message.py
 delete mode 100644 python/qemu/qmp/models.py
 delete mode 100644 python/qemu/qmp/protocol.py
 delete mode 100644 python/qemu/qmp/py.typed
 delete mode 100644 python/qemu/qmp/qmp_client.py
 delete mode 100644 python/qemu/qmp/qmp_shell.py
 delete mode 100644 python/qemu/qmp/qmp_tui.py
 delete mode 100644 python/qemu/qmp/util.py
 delete mode 100644 python/tests/protocol.py
 create mode 100644 python/wheels/qemu_qmp-0.0.5-py3-none-any.whl
 create mode 100644 pyvenv/meson.build

-- 
2.53.0

On Tue, 24 Feb 2026 at 18:14, John Snow <jsnow@redhat.com> wrote:
>
> The following changes since commit afe653676dc6dfd49f0390239ff90b2f0052c2b8:
>
>   Merge tag 'audio-pull-request' of https://gitlab.com/marcandre.lureau/qemu into staging (2026-02-23 14:03:50 +0000)
>
> are available in the Git repository at:
>
>   https://gitlab.com/jsnow/qemu.git tags/python-pull-request
>
> for you to fetch changes up to 4e55bb4be53bc7a5e3fe1429af12d2e3090049a5:
>
>   python: add setuptools and wheel dependencies (2026-02-24 13:11:29 -0500)
>
> ----------------------------------------------------------------
>
> ----------------------------------------------------------------
>



Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/11.0
for any user-visible changes.

-- PMM

On Tue, 24 Feb 2026 at 18:14, John Snow <jsnow@redhat.com> wrote:
>
> The following changes since commit afe653676dc6dfd49f0390239ff90b2f0052c2b8:
>
>   Merge tag 'audio-pull-request' of https://gitlab.com/marcandre.lureau/qemu into staging (2026-02-23 14:03:50 +0000)
>
> are available in the Git repository at:
>
>   https://gitlab.com/jsnow/qemu.git tags/python-pull-request
>
> for you to fetch changes up to 4e55bb4be53bc7a5e3fe1429af12d2e3090049a5:
>
>   python: add setuptools and wheel dependencies (2026-02-24 13:11:29 -0500)
>
> ----------------------------------------------------------------
>
> ----------------------------------------------------------------

Hi -- it looks like this pullreq may have broken the "coverity" job
that (run on a separate schedule from main CI) does a QEMU build to
upload to the coverity scan service:

https://gitlab.com/qemu-project/qemu/-/jobs/13264087007

It fails during QEMU configure:

Dependency libnfs found: NO. Found 16.2.0 but need: '<6.0.0' ;
matched: '>=1.9.3'
Run-time dependency libnfs found: NO
../meson.build:1150:11: ERROR: Dependency lookup for libnfs with
method 'pkgconfig' failed: Invalid version, need 'libnfs' ['<6.0.0']
found '16.2.0'.

I'm guessing this is because:
 * the coverity job runs on the amd64-fedora-container
 * we just upgraded our Fedora container to F43
 * coverity configures with --enable-libnfs
 * in meson.build we enforce libnfs < 6.0.0
 * F43 ships with a newer libnfs

The "not libnfs v6" restriction was added by thuth in
commit e2d98f257138 in 2024 because of a big API change in
libnfs v6. The theory was that this was a temporary hack
until somebody updated block/nfs.c to handle the new API.
Over a year later, nobody has touched block/nfs.c...

I guess for the moment we should fix the Coverity build
by dropping the --enable-libnfs (and accepting that we
don't scan block/nfs.c any more). For the longer term:

 * does anybody want to update block/nfs.c ?
 * or should we mark it as deprecated and plan to eventually
   drop it, given that the set of supported distros you can
   build it on is rapidly shrinking ?

thanks
-- PMM

Peter Maydell <peter.maydell@linaro.org> writes:

[...]

> I guess for the moment we should fix the Coverity build
> by dropping the --enable-libnfs (and accepting that we
> don't scan block/nfs.c any more). For the longer term:
>
>  * does anybody want to update block/nfs.c ?

Plan A: somebody does that.

>  * or should we mark it as deprecated and plan to eventually
>    drop it, given that the set of supported distros you can
>    build it on is rapidly shrinking ?

Plan B.

I recommend to execute on of them in this development cycle.  We can
always un-deprecate if somebody updates it during the deprecation grace
period.

> Am 27.02.2026 um 13:14 schrieb Markus Armbruster <armbru@redhat.com>:
> 
> Peter Maydell <peter.maydell@linaro.org> writes:
> 
> [...]
> 
>> I guess for the moment we should fix the Coverity build
>> by dropping the --enable-libnfs (and accepting that we
>> don't scan block/nfs.c any more). For the longer term:
>> 
>> * does anybody want to update block/nfs.c ?
> 
> Plan A: somebody does that.

I can look into it next week. Does that still fit in the cycle?

Peter

On 27/02/2026 14.37, Peter Lieven wrote:
> 
> 
>> Am 27.02.2026 um 13:14 schrieb Markus Armbruster <armbru@redhat.com>:
>>
>> Peter Maydell <peter.maydell@linaro.org> writes:
>>
>> [...]
>>
>>> I guess for the moment we should fix the Coverity build
>>> by dropping the --enable-libnfs (and accepting that we
>>> don't scan block/nfs.c any more). For the longer term:
>>>
>>> * does anybody want to update block/nfs.c ?
>>
>> Plan A: somebody does that.
> 
> I can look into it next week. Does that still fit in the cycle?

Yes, soft freeze date is March 10th:

  https://wiki.qemu.org/Planning/11.0

  HTH,
   Thomas

On Fri, 27 Feb 2026 at 13:37, Peter Lieven <pl@dlhnet.de> wrote:
>
>
>
> > Am 27.02.2026 um 13:14 schrieb Markus Armbruster <armbru@redhat.com>:
> >
> > Peter Maydell <peter.maydell@linaro.org> writes:
> >
> > [...]
> >
> >> I guess for the moment we should fix the Coverity build
> >> by dropping the --enable-libnfs (and accepting that we
> >> don't scan block/nfs.c any more). For the longer term:
> >>
> >> * does anybody want to update block/nfs.c ?
> >
> > Plan A: somebody does that.
>
> I can look into it next week. Does that still fit in the cycle?

Yes, just about. Softfreeze starts on the 10th March and
changes are supposed to be in pull requests before that.
If the required changes turn out to be fairly minor then
we can probably let it get in even if it's a little bit
behind on that schedule.

-- PMM

On Thu, Feb 26, 2026 at 10:44:58AM +0000, Peter Maydell wrote:
> On Tue, 24 Feb 2026 at 18:14, John Snow <jsnow@redhat.com> wrote:
> >
> > The following changes since commit afe653676dc6dfd49f0390239ff90b2f0052c2b8:
> >
> >   Merge tag 'audio-pull-request' of https://gitlab.com/marcandre.lureau/qemu into staging (2026-02-23 14:03:50 +0000)
> >
> > are available in the Git repository at:
> >
> >   https://gitlab.com/jsnow/qemu.git tags/python-pull-request
> >
> > for you to fetch changes up to 4e55bb4be53bc7a5e3fe1429af12d2e3090049a5:
> >
> >   python: add setuptools and wheel dependencies (2026-02-24 13:11:29 -0500)
> >
> > ----------------------------------------------------------------
> >
> > ----------------------------------------------------------------
> 
> Hi -- it looks like this pullreq may have broken the "coverity" job
> that (run on a separate schedule from main CI) does a QEMU build to
> upload to the coverity scan service:
> 
> https://gitlab.com/qemu-project/qemu/-/jobs/13264087007
> 
> It fails during QEMU configure:
> 
> Dependency libnfs found: NO. Found 16.2.0 but need: '<6.0.0' ;
> matched: '>=1.9.3'
> Run-time dependency libnfs found: NO
> ../meson.build:1150:11: ERROR: Dependency lookup for libnfs with
> method 'pkgconfig' failed: Invalid version, need 'libnfs' ['<6.0.0']
> found '16.2.0'.
> 
> I'm guessing this is because:
>  * the coverity job runs on the amd64-fedora-container
>  * we just upgraded our Fedora container to F43
>  * coverity configures with --enable-libnfs

Do we really need to be hardcoding configure options ?

It is a pretty random subset of options, compared to what gets
enabled in the build.

Originally we had the hand-built Dockerfile, but now nearly all
our dockerfiles are auto-generated by lcitool, so we get the full
set of QEMU deps on every distro. 

There is a risk that we break a meson/configure chck somewhere,
but IMHO that's not something our coverity needs to be validating
directly. If that happens and we later fix it, coverity would
pick up any flaws that weere introduced in the window it was
broken.

>  * in meson.build we enforce libnfs < 6.0.0
>  * F43 ships with a newer libnfs
> 
> The "not libnfs v6" restriction was added by thuth in
> commit e2d98f257138 in 2024 because of a big API change in
> libnfs v6. The theory was that this was a temporary hack
> until somebody updated block/nfs.c to handle the new API.
> Over a year later, nobody has touched block/nfs.c...
> 
> I guess for the moment we should fix the Coverity build
> by dropping the --enable-libnfs (and accepting that we
> don't scan block/nfs.c any more). For the longer term:
> 
>  * does anybody want to update block/nfs.c ?
>  * or should we mark it as deprecated and plan to eventually
>    drop it, given that the set of supported distros you can
>    build it on is rapidly shrinking ?

MAINTAINERS file marks it as "maintained" but given the ongoing
brokeness that feels outdated :-(

In Fedora we've been carrying a patch to QEMU to enable libnfs
v6.

  https://src.fedoraproject.org/rpms/qemu/blob/rawhide/f/0002-nfs-Add-support-for-libnfs-v2-api.patch
  https://src.fedoraproject.org/rpms/qemu/blob/rawhide/f/0008-Revert-meson.build-Disallow-libnfs-v6-to-fix-the-bro.patch

I vaguely recall someone saying there was problem with this patch but I
can't remember details. We've had no bug reports AFAIR, but that could
just mean it has few/no users to begin with.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

> Am 26.02.2026 um 12:16 schrieb Daniel P. Berrangé <berrange@redhat.com>:
> 
> On Thu, Feb 26, 2026 at 10:44:58AM +0000, Peter Maydell wrote:
>> On Tue, 24 Feb 2026 at 18:14, John Snow <jsnow@redhat.com> wrote:
>>> 
>>> The following changes since commit afe653676dc6dfd49f0390239ff90b2f0052c2b8:
>>> 
>>>  Merge tag 'audio-pull-request' of https://gitlab.com/marcandre.lureau/qemu into staging (2026-02-23 14:03:50 +0000)
>>> 
>>> are available in the Git repository at:
>>> 
>>>  https://gitlab.com/jsnow/qemu.git tags/python-pull-request
>>> 
>>> for you to fetch changes up to 4e55bb4be53bc7a5e3fe1429af12d2e3090049a5:
>>> 
>>>  python: add setuptools and wheel dependencies (2026-02-24 13:11:29 -0500)
>>> 
>>> ----------------------------------------------------------------
>>> 
>>> ----------------------------------------------------------------
>> 
>> Hi -- it looks like this pullreq may have broken the "coverity" job
>> that (run on a separate schedule from main CI) does a QEMU build to
>> upload to the coverity scan service:
>> 
>> https://gitlab.com/qemu-project/qemu/-/jobs/13264087007
>> 
>> It fails during QEMU configure:
>> 
>> Dependency libnfs found: NO. Found 16.2.0 but need: '<6.0.0' ;
>> matched: '>=1.9.3'
>> Run-time dependency libnfs found: NO
>> ../meson.build:1150:11: ERROR: Dependency lookup for libnfs with
>> method 'pkgconfig' failed: Invalid version, need 'libnfs' ['<6.0.0']
>> found '16.2.0'.
>> 
>> I'm guessing this is because:
>> * the coverity job runs on the amd64-fedora-container
>> * we just upgraded our Fedora container to F43
>> * coverity configures with --enable-libnfs
> 
> Do we really need to be hardcoding configure options ?
> 
> It is a pretty random subset of options, compared to what gets
> enabled in the build.
> 
> Originally we had the hand-built Dockerfile, but now nearly all
> our dockerfiles are auto-generated by lcitool, so we get the full
> set of QEMU deps on every distro. 
> 
> There is a risk that we break a meson/configure chck somewhere,
> but IMHO that's not something our coverity needs to be validating
> directly. If that happens and we later fix it, coverity would
> pick up any flaws that weere introduced in the window it was
> broken.
> 
>> * in meson.build we enforce libnfs < 6.0.0
>> * F43 ships with a newer libnfs
>> 
>> The "not libnfs v6" restriction was added by thuth in
>> commit e2d98f257138 in 2024 because of a big API change in
>> libnfs v6. The theory was that this was a temporary hack
>> until somebody updated block/nfs.c to handle the new API.
>> Over a year later, nobody has touched block/nfs.c...
>> 
>> I guess for the moment we should fix the Coverity build
>> by dropping the --enable-libnfs (and accepting that we
>> don't scan block/nfs.c any more). For the longer term:
>> 
>> * does anybody want to update block/nfs.c ?
>> * or should we mark it as deprecated and plan to eventually
>>   drop it, given that the set of supported distros you can
>>   build it on is rapidly shrinking ?
> 
> MAINTAINERS file marks it as "maintained" but given the ongoing
> brokeness that feels outdated :-(
> 
> In Fedora we've been carrying a patch to QEMU to enable libnfs
> v6.
> 
>  https://src.fedoraproject.org/rpms/qemu/blob/rawhide/f/0002-nfs-Add-support-for-libnfs-v2-api.patch
>  https://src.fedoraproject.org/rpms/qemu/blob/rawhide/f/0008-Revert-meson.build-Disallow-libnfs-v6-to-fix-the-bro.patch

Sorry, I was not aware of any build problems so far and as I wrote Peter earlier I was some time out of Qemu development, but that changed recently.

Is there a reason why Ronnie’s patch never went upstream? Surely, it was incomplete without the fix in the build scripts.

I do not see any issue with both patches. If there are issues at all I would suspect a problem introduced in libnfs v6.

In general I found nfs in userspace really useful especially if it is only used for ISOs or qemu-img jobs.

A broken NFS server mounted in the host can easily bring down a lot of things including a VM that has a ISO mounted from it.

Peter

On 26/02/2026 12.39, Peter Lieven wrote:
> 
> 
>> Am 26.02.2026 um 12:16 schrieb Daniel P. Berrangé <berrange@redhat.com>:
>>
>> On Thu, Feb 26, 2026 at 10:44:58AM +0000, Peter Maydell wrote:
>>> On Tue, 24 Feb 2026 at 18:14, John Snow <jsnow@redhat.com> wrote:
>>>>
>>>> The following changes since commit afe653676dc6dfd49f0390239ff90b2f0052c2b8:
>>>>
>>>>   Merge tag 'audio-pull-request' of https://gitlab.com/marcandre.lureau/qemu into staging (2026-02-23 14:03:50 +0000)
>>>>
>>>> are available in the Git repository at:
>>>>
>>>>   https://gitlab.com/jsnow/qemu.git tags/python-pull-request
>>>>
>>>> for you to fetch changes up to 4e55bb4be53bc7a5e3fe1429af12d2e3090049a5:
>>>>
>>>>   python: add setuptools and wheel dependencies (2026-02-24 13:11:29 -0500)
>>>>
>>>> ----------------------------------------------------------------
>>>>
>>>> ----------------------------------------------------------------
>>>
>>> Hi -- it looks like this pullreq may have broken the "coverity" job
>>> that (run on a separate schedule from main CI) does a QEMU build to
>>> upload to the coverity scan service:
>>>
>>> https://gitlab.com/qemu-project/qemu/-/jobs/13264087007
>>>
>>> It fails during QEMU configure:
>>>
>>> Dependency libnfs found: NO. Found 16.2.0 but need: '<6.0.0' ;
>>> matched: '>=1.9.3'
>>> Run-time dependency libnfs found: NO
>>> ../meson.build:1150:11: ERROR: Dependency lookup for libnfs with
>>> method 'pkgconfig' failed: Invalid version, need 'libnfs' ['<6.0.0']
>>> found '16.2.0'.
>>>
>>> I'm guessing this is because:
>>> * the coverity job runs on the amd64-fedora-container
>>> * we just upgraded our Fedora container to F43
>>> * coverity configures with --enable-libnfs
>>
>> Do we really need to be hardcoding configure options ?
>>
>> It is a pretty random subset of options, compared to what gets
>> enabled in the build.
>>
>> Originally we had the hand-built Dockerfile, but now nearly all
>> our dockerfiles are auto-generated by lcitool, so we get the full
>> set of QEMU deps on every distro.
>>
>> There is a risk that we break a meson/configure chck somewhere,
>> but IMHO that's not something our coverity needs to be validating
>> directly. If that happens and we later fix it, coverity would
>> pick up any flaws that weere introduced in the window it was
>> broken.
>>
>>> * in meson.build we enforce libnfs < 6.0.0
>>> * F43 ships with a newer libnfs
>>>
>>> The "not libnfs v6" restriction was added by thuth in
>>> commit e2d98f257138 in 2024 because of a big API change in
>>> libnfs v6. The theory was that this was a temporary hack
>>> until somebody updated block/nfs.c to handle the new API.
>>> Over a year later, nobody has touched block/nfs.c...
>>>
>>> I guess for the moment we should fix the Coverity build
>>> by dropping the --enable-libnfs (and accepting that we
>>> don't scan block/nfs.c any more). For the longer term:
>>>
>>> * does anybody want to update block/nfs.c ?
>>> * or should we mark it as deprecated and plan to eventually
>>>    drop it, given that the set of supported distros you can
>>>    build it on is rapidly shrinking ?
>>
>> MAINTAINERS file marks it as "maintained" but given the ongoing
>> brokeness that feels outdated :-(
>>
>> In Fedora we've been carrying a patch to QEMU to enable libnfs
>> v6.
>>
>>   https://src.fedoraproject.org/rpms/qemu/blob/rawhide/f/0002-nfs-Add-support-for-libnfs-v2-api.patch
>>   https://src.fedoraproject.org/rpms/qemu/blob/rawhide/f/0008-Revert-meson.build-Disallow-libnfs-v6-to-fix-the-bro.patch
> 
> Sorry, I was not aware of any build problems so far and as I wrote Peter earlier I was some time out of Qemu development, but that changed recently.
> 
> Is there a reason why Ronnie’s patch never went upstream?

Searching for the subject of that patch in my qemu-devel folder, I don't get 
any results. So I guess that patch has never been posted to the qemu-devel 
mailing list?

  Thomas

> Am 26.02.2026 um 13:41 schrieb Thomas Huth <thuth@redhat.com>:
> 
> On 26/02/2026 12.39, Peter Lieven wrote:
>>> Am 26.02.2026 um 12:16 schrieb Daniel P. Berrangé <berrange@redhat.com>:
>>> 
>>> On Thu, Feb 26, 2026 at 10:44:58AM +0000, Peter Maydell wrote:
>>>> On Tue, 24 Feb 2026 at 18:14, John Snow <jsnow@redhat.com> wrote:
>>>>> 
>>>>> The following changes since commit afe653676dc6dfd49f0390239ff90b2f0052c2b8:
>>>>> 
>>>>>  Merge tag 'audio-pull-request' of https://gitlab.com/marcandre.lureau/qemu into staging (2026-02-23 14:03:50 +0000)
>>>>> 
>>>>> are available in the Git repository at:
>>>>> 
>>>>>  https://gitlab.com/jsnow/qemu.git tags/python-pull-request
>>>>> 
>>>>> for you to fetch changes up to 4e55bb4be53bc7a5e3fe1429af12d2e3090049a5:
>>>>> 
>>>>>  python: add setuptools and wheel dependencies (2026-02-24 13:11:29 -0500)
>>>>> 
>>>>> ----------------------------------------------------------------
>>>>> 
>>>>> ----------------------------------------------------------------
>>>> 
>>>> Hi -- it looks like this pullreq may have broken the "coverity" job
>>>> that (run on a separate schedule from main CI) does a QEMU build to
>>>> upload to the coverity scan service:
>>>> 
>>>> https://gitlab.com/qemu-project/qemu/-/jobs/13264087007
>>>> 
>>>> It fails during QEMU configure:
>>>> 
>>>> Dependency libnfs found: NO. Found 16.2.0 but need: '<6.0.0' ;
>>>> matched: '>=1.9.3'
>>>> Run-time dependency libnfs found: NO
>>>> ../meson.build:1150:11: ERROR: Dependency lookup for libnfs with
>>>> method 'pkgconfig' failed: Invalid version, need 'libnfs' ['<6.0.0']
>>>> found '16.2.0'.
>>>> 
>>>> I'm guessing this is because:
>>>> * the coverity job runs on the amd64-fedora-container
>>>> * we just upgraded our Fedora container to F43
>>>> * coverity configures with --enable-libnfs
>>> 
>>> Do we really need to be hardcoding configure options ?
>>> 
>>> It is a pretty random subset of options, compared to what gets
>>> enabled in the build.
>>> 
>>> Originally we had the hand-built Dockerfile, but now nearly all
>>> our dockerfiles are auto-generated by lcitool, so we get the full
>>> set of QEMU deps on every distro.
>>> 
>>> There is a risk that we break a meson/configure chck somewhere,
>>> but IMHO that's not something our coverity needs to be validating
>>> directly. If that happens and we later fix it, coverity would
>>> pick up any flaws that weere introduced in the window it was
>>> broken.
>>> 
>>>> * in meson.build we enforce libnfs < 6.0.0
>>>> * F43 ships with a newer libnfs
>>>> 
>>>> The "not libnfs v6" restriction was added by thuth in
>>>> commit e2d98f257138 in 2024 because of a big API change in
>>>> libnfs v6. The theory was that this was a temporary hack
>>>> until somebody updated block/nfs.c to handle the new API.
>>>> Over a year later, nobody has touched block/nfs.c...
>>>> 
>>>> I guess for the moment we should fix the Coverity build
>>>> by dropping the --enable-libnfs (and accepting that we
>>>> don't scan block/nfs.c any more). For the longer term:
>>>> 
>>>> * does anybody want to update block/nfs.c ?
>>>> * or should we mark it as deprecated and plan to eventually
>>>>   drop it, given that the set of supported distros you can
>>>>   build it on is rapidly shrinking ?
>>> 
>>> MAINTAINERS file marks it as "maintained" but given the ongoing
>>> brokeness that feels outdated :-(
>>> 
>>> In Fedora we've been carrying a patch to QEMU to enable libnfs
>>> v6.
>>> 
>>>  https://src.fedoraproject.org/rpms/qemu/blob/rawhide/f/0002-nfs-Add-support-for-libnfs-v2-api.patch
>>>  https://src.fedoraproject.org/rpms/qemu/blob/rawhide/f/0008-Revert-meson.build-Disallow-libnfs-v6-to-fix-the-bro.patch
>> Sorry, I was not aware of any build problems so far and as I wrote Peter earlier I was some time out of Qemu development, but that changed recently.
>> Is there a reason why Ronnie’s patch never went upstream?
> 
> Searching for the subject of that patch in my qemu-devel folder, I don't get any results. So I guess that patch has never been posted to the qemu-devel mailing list?

That might explain it. I meanwhile had a chance to look into the source of libnfs v6 it seems that patch is wrong.

It writes bytes number of bytes to the address auf iov->iov[0].iov_base. If bytes is greater than the iov->iov[0] buffer, it writes beyond the end of the buffer.
I cannot see at a glance if that’s potentially dangerous, but it might be.

In fact libnfs v6 adds support for supplying a read buffer, but not for iovectors.
What the patch really should do is to pass iov[0].iov_base if niov == 1 and create a bounce buffer otherwise.

Peter

On Thu, 26 Feb 2026 at 11:16, Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Thu, Feb 26, 2026 at 10:44:58AM +0000, Peter Maydell wrote:
> > I'm guessing this is because:
> >  * the coverity job runs on the amd64-fedora-container
> >  * we just upgraded our Fedora container to F43
> >  * coverity configures with --enable-libnfs
>
> Do we really need to be hardcoding configure options ?
>
> It is a pretty random subset of options, compared to what gets
> enabled in the build.

The comment in scripts/coverity-scan/run-coverity-scan gives the
rationale:

# We configure with a fixed set of enables here to ensure that we don't
# accidentally reduce the scope of the analysis by doing the build on
# the system that's missing a dependency that we need to build part of
# the codebase.

And indeed this thread shows that it worked -- without the
--enable-libnfs we would simply not have noticed that we'd
silently stopped scanning block/nfs.c. Now we get to make an
active decision that we're OK with that.

thanks
-- PMM