On Wed, Jan 22, 2025 at 8:08 PM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote:
Much like libtest, the mass rebuild has inadvertently bumped the soname
of libnfs. libnfs 6 was in dist-git but had never been built for
Rawhide (there were some attempts in side tags, but they all seem to
have been garbage collected). The mass rebuild built it, so now libnfs
has gone from 5.x to 6.x and soname libnfs.so.14 to libnfs.so.16. This
actually does include a major API change, see upstream:
https://github.com/sahlberg/libnfs/commit/5e8f7ce273308eb77f94248f4501e574a703c1a5
there are four external deps of libnfs that I can see:
gvfs-nfs-0:1.56.1-1.fc42.x86_64
qemu-block-nfs-2:9.2.0-3.fc42.x86_64
vlc-plugins-extra-1:3.0.21-15.fc42.x86_64
xine-lib-0:1.2.13-17.fc42.x86_64
qemu-block-nfs and gvfs-nfs are the most important there. qemu-block-
nfs not being installable is breaking at least one other build I'm
trying to do.
gvfs has a port to the new API already:
https://gitlab.gnome.org/GNOME/gvfs/-/merge_requests/257
I'm going to try and use that as a guide to patch qemu and get it
built. Otherwise we may have to try and unpick the soname bump :/
For the future I think we really need to consider some kind of
automated check for when dist-git is ahead of the most recently-tagged
package, when doing the mass rebuild. There are just too many problems
like this.
This is why ELN mass-rebuilds (even the ones not triggered by the Fedora mass-rebuild) always build from the dist-git commit of the last successful Rawhide build. I have been advocating for us using the same policy for Rawhide for some years now to avoid exactly the situation we hit here. Sure, it makes the rebuild script's logic a bit more complex (it needs to perform several queries into Koji to figure out what the latest build's git commit is), but I think that's worth the cause. The code ELN uses to do this is built into ELNBuildSync[1] if anyone wants to adapt it.
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
