> 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? 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
