On Thu, Jan 23, 2025 at 6:02 PM Simo Sorce <s...@redhat.com> wrote:
> On Thu, 2025-01-23 at 09:45 -0500, Stephen Gallagher wrote: > > On Wed, Jan 22, 2025 at 8:08 PM Adam Williamson < > adamw...@fedoraproject.org> > > 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. > > > > [1] > > > https://gitlab.com/redhat/centos-stream/ci-cd/distrosync/distrobuildsync/-/blob/main/elnbuildsync/batching.py?ref_type=heads#L91 > > > What would be the NVR of the resulting RPM ? > Sorry, thanks. I forgot to note that ELN has a different %{dist} tag structure than Fedora. We include a "buildroot number" in the %{dist} which we bump before a mass rebuild. Thus, the ENVR differs by that buildroot number (while the rest of the ENVR remains the same). So, something like samba-4.21.3-6.eln145 vs samba-4.21.3-6.eln146 Rawhide doesn't have that buildroot number solution, but since the mass-rebuild does an rpmdev-bumpspec to increase the release number anyway, it accomplishes the same thing.
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
