Re: block/nfs.c and libnfs vs Fedora 43 (was: Re: [PULL v2 00/19] Python patches)

["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

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