On 26/02/2026 12.39, Peter Lieven wrote:
Am 26.02.2026 um 12:16 schrieb Daniel P. Berrangé <[email protected]>:
On Thu, Feb 26, 2026 at 10:44:58AM +0000, Peter Maydell wrote:
On Tue, 24 Feb 2026 at 18:14, John Snow <[email protected]> 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
