On Thu, Jan 23, 2025 at 6:02 PM Simo Sorce <simo@xxxxxxxxxx> wrote:
On Thu, 2025-01-23 at 09:45 -0500, Stephen Gallagher wrote:
> 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.
>
> [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@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
