Help Requested: Prevent CI Errors before DNF5 will replace DNF
by Nicola Sella
Hi all,
I am looking for feedback and guidance on how to test DNF5 against Fedora
CI.
I'd like to start this discussion before the obsolete switch is turned on
to avoid any disruption.[1]
Currently, the team's plan is to build a side-tag with the DNF-to-DNF5
switch on, and advertise that on the Fedora devel list to gather feedback
and allow users/teams to test their builds/workflows in the side-tag.
Furthermore, I'd like to put together, or update, a list of requirements to
ease the transition from DNF to DNF5.
Any recommendations or ideas that should be followed to test DNF5 in Fedora
CI?
Thanks,
Nicola
[1]: https://pagure.io/fedora-ci/general/issue/416
1 month, 1 week
Re: Update gumbo-parser to 0.12.1/libgumbo SONAME bump
by Adam Williamson
On Fri, 2024-03-01 at 13:27 -0600, Jason Tibbitts wrote:
> > > > > > Adam Williamson <adamwill(a)fedoraproject.org> writes:
>
> > Honestly, we could really use more automation here, but it's a fairly
> > hard thing to do *reliably* and there just isn't anybody specifically
> > tasked with it so it doesn't happen.
>
> So sure, we could use something but it doesn't have to start out as some
> complex fully automatic system. (Would be nice, but...)
>
> Can we agree that we'd be at least half of the way there if we just had
> a well defined way to:
>
> * Know what package depend on the one you're updating
>
> * Easily bump and chain-build all of that in a side tag
>
> Surely there's a reopquery or fedrq command line that will find at least
> most of what needs to be rebuilt. It doesn't have to be absolutely
> perfect but it can't be that hard to get close. I know there's a
> distinction between build and runtime dependencies and rich/conditional
> dependencies complicate things a bit, but those much smarter than I am
> must have already figured out how to get something that's at least
> somewhat useful.
>
> Once you have the package list, maybe it needs some kind of sorting
> before you can just bump and chain-build things, but I think in many
> cases it doesn't. So, yes, a 100% tool would be really hard but the 80%
> tool really shouldn't be that bad, and almost any tool would really help
> people out.
Yeah, for sure, that's why I'm trying to nibble around the edges by
updating the docs to strongly encourage chain builds, document using
fedpkg chain-build on a side tag, and hopefully get fedpkg chain-build
enhanced so it can create the side tag and the final update
automatically. If we can get that, then I can make the docs explain how
to use it.
ISTR there've been several recent discussions of complex dep chains on
this very list where people have floated candidates for repoquery/fedrq
commands...if there's one we're pretty confident is The Best, we can
definitely plumb that into the docs at least (plumbing it all the way
into fedpkg might be a step too far, though).
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net
1 month, 3 weeks
Re: Update gumbo-parser to 0.12.1/libgumbo SONAME bump
by Adam Williamson
On Fri, 2024-03-01 at 09:34 +0100, Michael J Gruber wrote:
> Am Fr., 1. März 2024 um 07:55 Uhr schrieb Ralf Corsépius <rc040203(a)freenet.de>:
> >
> > Hi,
> >
> > I intend to update gumbo-parser to 0.12.1 in rawhide.
> > This comes along with an soname bump libgumbo to libgumbo.so.2
> >
> > This requires a rebuilt of several dependent packages, AFAICT:
> > claws-mail
> > litehtml
> > mupdf
> > perl-HTML-Gumbo
> > python3-PyMuPDF
> > qpdfview
> > zathura-pdf-mupdf
> >
> > I'll try to rebuild these packages on side-tag f41-build-side-84865
> > (Please, bear with me, I haven't used side-tags, before. I couldn't find
> > any usable docs on how to use them)
> >
> > Preliminary tests indicate, something unrelated to libgumbo.so.* has
> > changed with these packages (Probably mupdf), causing gpdfview to FTBFS
> > and dependency changes in rawhide.
>
> Interesting. I wasn't aware of that dependency - I guess I have to
> re-run detection more often. Speaking of - do we have a policy about
> this? This is not about blaming, but how do we ensure that everyone is
> aware of new dependencies? Frequent re-runs to detect them or
> announcements the other way round?
Unless I've missed something, the general situation in Fedora is all
the onus is on the party bumping the depended-upon package. We don't
require dependent packages to announce their dependencies in any way
(except, you know, through an actual package dependency).
If you're changing a package in any way that could be fairly considered
"not backwards compatible" for another package depending on it in a
"typical" way, I'm pretty sure the onus is on you to find those
dependencies and make sure they are handled, not vice versa.
Honestly, we could really use more automation here, but it's a fairly
hard thing to do *reliably* and there just isn't anybody specifically
tasked with it so it doesn't happen. I had an interesting chat with
Martin Pitt about britney -
https://release.debian.org/doc/britney/what-is-britney.html - which
Debian and Ubuntu use in this area. If I understood the explanation
correctly, it's a sort of automated update bundler; Debian and Ubuntu
devs can just throw builds at a staging area, and britney takes care of
grouping them into logical sets based on their dependencies. So to do
an soname bump you'd build the bumped library in the staging area, wait
for it to appear in the staging area buildroot (I guess), then build
all the dependencies, and britney would figure out that this group of
packages needs to go out of the staging area and into stable together
and make that happen, so the packager doesn't have to group them
manually. If you've got a build in the staging area which britney can't
"solve", I think, you get alerts so you know what needs doing ("package
X needs rebuilding against your thing", or whatever).
Something along those lines for Fedora would be awesome! But we can't
just lift-and-shift britney - we'd have to adapt it to RPM dependencies
(if that hasn't been done already) and integrate it with Bodhi
(definitely not done already). That's a lot of work for someone. We
could conceivably code an equivalent feature into Bodhi ourselves, but
again, a lot of work for someone. And it'd probably need some thought
about a way to allow cutoffs/exceptions so you could get an soname bump
through if it has 500 dependencies and you've fixed 499 and the other
is some obscure package that hasn't been maintained for a year. All of
that is work that isn't #1 on anybody's priority list, I think :( I
would love to say I'm gonna work on it, but I've added three neat
projects to my "neat side project backlog" since *yesterday* and it's
about a thousand items long at this point, so, hmm.
It'd also be nice to have a reliable distro-wide automated check for
"does this update break the dependencies of anything else?" so we could
at least prevent all updates that break dep chains going stable. Right
now openQA catches some such cases, but *only* ones that affect
critical path packages *and* happen to involve a package that actually
gets installed during an openQA test. The CI rpmdeplint test is
supposed to cover this, I think, but historically hasn't proven
reliable enough to be made universally gating (and I think maybe only
works on Rawhide). But again...somebody has to clear the time to work
on it :|
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net
1 month, 3 weeks
