Re: Update gumbo-parser to 0.12.1/libgumbo SONAME bump
Dne 01. 03. 24 v 19:58 Adam Williamson napsal(a):
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 :
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
We have:
https://gitlab.com/fedora/packager-tools/mass-prebuild
It does not do automated official builds, but it certainly helps to
better understand what is the impact of changes on dependent packages.
Vít
- 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 :|
OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
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
Re: Update gumbo-parser to 0.12.1/libgumbo SONAME bump
On Sat, Mar 2, 2024, 09:06 Mattia Verga via devel < devel@lists.fedoraproject.org> wrote: > > On Friday, March 1st, 2024 at 20:27, Jason Tibbitts wrote: > > > > > > > > Adam Williamson adamw...@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. > > > > My idea was to write a Python script based on libdnf APIs and third party > python modules to create a dependency tree of packages, so that also Mass > Rebuilds can be run by the tree levels instead of alphabetically. However, > I had no time to further develop the idea, as I also learn how to fetch > data from libdnf (and if that is possible at all). > The problem with this idea is that the dependency tree is not a "tree", but a graph that is *not* acyclic. So you just *cannot* make a linearized version / topographic sort without some amount of "bootstrap" changes to break (or ignore) some of the involved dependencies. Fabio > Mattia > -- > ___ > 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 > -- ___ 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
Re: Update gumbo-parser to 0.12.1/libgumbo SONAME bump
On Friday, March 1st, 2024 at 20:27, Jason Tibbitts wrote: > > > > Adam Williamson adamw...@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. > My idea was to write a Python script based on libdnf APIs and third party python modules to create a dependency tree of packages, so that also Mass Rebuilds can be run by the tree levels instead of alphabetically. However, I had no time to further develop the idea, as I also learn how to fetch data from libdnf (and if that is possible at all). Mattia -- ___ 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
Re: Update gumbo-parser to 0.12.1/libgumbo SONAME bump
On Fri, 2024-03-01 at 13:27 -0600, Jason Tibbitts wrote: > > > > > > Adam Williamson 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: @ad...@fosstodon.org https://www.happyassassin.net -- ___ 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
Re: Update gumbo-parser to 0.12.1/libgumbo SONAME bump
> Adam Williamson 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. - J< -- ___ 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
Re: Update gumbo-parser to 0.12.1/libgumbo SONAME bump
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
> :
> >
> > 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: @ad...@fosstodon.org
https://www.happyassassin.net
--
___
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
Re: Update gumbo-parser to 0.12.1/libgumbo SONAME bump
Am Fr., 1. März 2024 um 11:06 Uhr schrieb Ralf Corsépius : > BTW: f40 also is affected by the FTBFS. > > > How do you test the > > fitz plugin? > > No idea. All I did was to address the FTBFS ;) > > > (BTW: qpdfview needs to remove deprecated patchN, too.) > I know ;) > > I would suggest you to apply your patches to qpdfview to rawhide, ASAP? > I'd then pick them up and add qpdfview (w/ your patches) to my side-tag. https://src.fedoraproject.org/rpms/qpdfview/pull-request/2 (I'm not a pp and don't have commit rights there.) In addition, I've rebuilt qpdfview locally (F39 mock with my mupdf copr for the rawhide mupdf.spec built on F39), tested and installed. Display of PDFs and annotations work. I don't know how the fitz plugin is used, though. The shared build of mupdf is in rawhide and F40. Since I"ve used it on F39 myself for a few weeks now, I wouldn't mind merging this down to F39 if it makes things easier for you. Michael -- ___ 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
Re: Update gumbo-parser to 0.12.1/libgumbo SONAME bump
Am 01.03.24 um 10:29 schrieb Michael J Gruber: Am Fr., 1. März 2024 um 10:19 Uhr schrieb Ralf Corsépius : Am 01.03.24 um 09:34 schrieb Michael J Gruber: Am Fr., 1. März 2024 um 07:55 Uhr schrieb Ralf Corsépius : 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 This was the list of packages depending on gumbo for f39. In rawhide, for reasons, I don't know, python3-PyMuPDF and python3-PyMuPDF do not seem to depend on gumbo, anymore. Grr, this was meant to be "python3-PyMuPDF and 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. The version of mupdf in rawhide seems to have dropped libmupdf-third, which seems to be the origin of qpdfview's FTBFS. I don't know, if this change is intentional or happened by accident. Yes, that is what I had tried to explain. mupdf still depends on tesseract, gumbo etc, but packages depending on mupdf do not need to build against those, only against mupdf, unless they require the other ones directly, of course. I have a working local mockbuild for qpdfview now. Me too ;-) Removing all references to -lmupad-third from qpdfview.spec was sufficient to work-around the FTBFS. BTW: f40 also is affected by the FTBFS. How do you test the fitz plugin? No idea. All I did was to address the FTBFS ;) (BTW: qpdfview needs to remove deprecated patchN, too.) I know ;) I would suggest you to apply your patches to qpdfview to rawhide, ASAP? I'd then pick them up and add qpdfview (w/ your patches) to my side-tag. Ralf -- ___ 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
Re: Update gumbo-parser to 0.12.1/libgumbo SONAME bump
Am Fr., 1. März 2024 um 10:19 Uhr schrieb Ralf Corsépius : > > > > Am 01.03.24 um 09:34 schrieb Michael J Gruber: > > Am Fr., 1. März 2024 um 07:55 Uhr schrieb Ralf Corsépius > > : > >> > >> 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 > > This was the list of packages depending on gumbo for f39. > > In rawhide, for reasons, I don't know, python3-PyMuPDF and > python3-PyMuPDF do not seem to depend on gumbo, anymore. > > >> 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. > > The version of mupdf in rawhide seems to have dropped libmupdf-third, > which seems to be the origin of qpdfview's FTBFS. > > I don't know, if this change is intentional or happened by accident. Yes, that is what I had tried to explain. mupdf still depends on tesseract, gumbo etc, but packages depending on mupdf do not need to build against those, only against mupdf, unless they require the other ones directly, of course. I have a working local mockbuild for qpdfview now. How do you test the fitz plugin? (BTW: qpdfview needs to remove deprecated patchN, too.) Michael Michael -- ___ 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
Re: Update gumbo-parser to 0.12.1/libgumbo SONAME bump
Am 01.03.24 um 09:34 schrieb Michael J Gruber: Am Fr., 1. März 2024 um 07:55 Uhr schrieb Ralf Corsépius : 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 This was the list of packages depending on gumbo for f39. In rawhide, for reasons, I don't know, python3-PyMuPDF and python3-PyMuPDF do not seem to depend on gumbo, anymore. 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. The version of mupdf in rawhide seems to have dropped libmupdf-third, which seems to be the origin of qpdfview's FTBFS. I don't know, if this change is intentional or happened by accident. qpdfview.spec will need some changes and will most probably lose the direct dependency on gumbo, tesseract etc. I'll look into that today, or over the weekend at the latest. In particular, qpdfview would not have needed a rebuild against gumbo etc if it had been built against mupdf shared already. Give me a couple of hours - I am working on this right now. AFAICS, the only problem qpdfview has is mupdf-third. And no, side-tags don't hurt, they are fun :) Only caveat: permissions, i.e. who can build into which side-tags. I ended up with commit rights to all mupdf dependencies at that time. That's a none-issue for a pp, of course. I don't know - I am a proven-packager and have almost universal permissions ;-) Ralf -- ___ 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
Re: Update gumbo-parser to 0.12.1/libgumbo SONAME bump
Am Fr., 1. März 2024 um 07:55 Uhr schrieb Ralf Corsépius : > > 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? I switched mupdf from the old static build (which required many side-tag rebuilds) to a shared rebuild which will reduce dependency rebuilds in the future (and follows upstream's choice for their dependent package). I coordinated this with all dependent packages that I was aware of. qpdfview.spec will need some changes and will most probably lose the direct dependency on gumbo, tesseract etc. I'll look into that today, or over the weekend at the latest. In particular, qpdfview would not have needed a rebuild against gumbo etc if it had been built against mupdf shared already. And no, side-tags don't hurt, they are fun :) Only caveat: permissions, i.e. who can build into which side-tags. I ended up with commit rights to all mupdf dependencies at that time. That's a none-issue for a pp, of course. Michael -- ___ 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
Re: Update gumbo-parser to 0.12.1/libgumbo SONAME bump
On Fri, 2024-03-01 at 07:54 +0100, Ralf Corsépius wrote: > 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) Thanks for trying! This doc should be pretty good: https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#_side_tags I have an active PR to revise that page a bit, but it doesn't change much about the side tag instructions themselves. One neat thing I found out while working on various docs around this today is that you can use `fedpkg chain-build --target (side tag name)` to do a chain build to a side tag. I haven't tried it, but it ought to work fine. So, just create your side tag, wait for it to exist, run the chain-build, and if it all goes OK, create the update from the side tag. I think it'd make sense these days for `fedpkg chain-build` to *default* to creating a new side tag and doing the builds there automatically (and then maybe creating an update when they're all done), so I filed https://pagure.io/fedpkg/issue/540 for that. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ 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
