Jitka Plesnikova venit, vidit, dixit 2025-10-29 09:24:53: > > > On 10/28/25 11:48, Michael J Gruber wrote: > > Michael J Gruber venit, vidit, dixit 2025-08-06 13:42:29: > >> Am Mi., 6. Aug. 2025 um 12:32 Uhr schrieb Jitka Plesnikova > >> <[email protected]>: > >>> > >>> > >>> On 8/5/25 21:00, Michael J Gruber wrote: > >>>> Hi there, > >>>> > >>>> this is half a question and half a remark. python-PyMuPDF started to > >>>> FTBFS recently with a weird error message: > >>>> > >>>> https://koschei.fedoraproject.org/build/21026539 > >>>> > >>>> python-PyMuPDF uses swig generated python bindings from the package > >>>> mupdf. After staring at the error and koschei's list of changes for a > >>>> while, knowing that my regular rebuilds in copr showed no such issue, > >>>> I did the following in mock locally: > >>>> > >>>> rebuild and install mupdf (unchanged) > >>>> rebuild python-PyMuPDF > >>>> > >>>> This worked. My current assumption is that that the patch in > >>>> swig-4.3.1-4.fc43 introduced a change which made a rebuild necessary - > >>>> i.e. the mupdf bindings built with swig-4.3.1-3 do not work when I use > >>>> them to build python-PyMuPDF with swig-4.3.1-4. The rebuilt bindings > >>>> do work. > >>>> > >>>> Since my mock changeroot does not want to downgrade swig I cannot test > >>>> for sure, just wanted to throw it out there in case someone > >>>> experiences strange effects with call signatures of overloaded > >>>> functions using swig. > >>>> > >>>> Michael > >>> Hi, > >>> > >>> I applied patch for removing DeprecationWarning > >>> -https://github.com/swig/swig/issues/2881 > >>> > >>> The issue is mention in commit: > >>> https://github.com/pymupdf/PyMuPDF/commit/9115023eb7844fe3e1ca7ca2842f6f88c427c60b > >>> > >>> The fix will be part of future SWIG 4.4.0. > >> Sure. That's what I mentioned as "introduced a change". > >> > >> What I didn't expect was that this necessitates rebuilds of packages > >> which use swig - it made unchanged packages FTBFS (which built fine > >> during mass rebuild). And as this cause and solution was difficult to > >> spot for me I wanted to warn others. > >> > >> Those warnings have been around for a while already (as mentioned in > >> PyMuPDF), and the swig fix removes them. Neither is a problem, but > >> apparently the backported swig patch changes something else, too, or > >> necessitates a rebuild for other reasons. After all, I had to change > >> *neither* package, but I had to rebuild the first one (against new > >> swig) in order to build the second one (against new swig), and - other > >> than glibc - the only relevant change in chroot seems to be that swig > >> change. > >> > >> To put it more bluntly: if a swig change requires rebuilds of packages > >> BR'ing swig I'd expect a notice. Same if it wasn't swig but something > >> else. > >> > >> Michael > > Indeed, swig 4.4.0 requires yet another rebuild. python-PyMuPDF FTBFS: > > > > https://koschei.fedoraproject.org/package/python-PyMuPDF > > > > If I rebuild mupdf against swig 4.4.0 and then python-PyMuPDF things > > work. > > > > So, again: > > > > Are packages using swig supposed to be rebuilt for a swig change? > > > > If yes then at least an announcement on devel would be nice (if not > > taking care of rebuilds). > > > > But maybe these packages are doing something special if noone else > > complains. > > > > Michael > Hi, > > I apologize for the issues. SWIG is only a build dependency, and in my > view, > there is no need to perform a rebuild when a new version of SWIG is added.
The experience for "my" packages is different, as I tried to explain. I'm still wondering whether my packages are "special" or could/should do something differently - it seems I'm the only one reporting issues like these. So maybe mupdf/PyMuPDF use internals which are not guaranteed to be stable? Upstream manages them separately (source repos etc) but bundles mupdf with PyMuPDF wheels (I'm simplifying). > The rebuild with the newest version will be performed at the latest during > the mass rebuild for the given version. The mass rebuild does not solve the mentioned problem, it only exposes it. Note that a mass rebuild does not rebuild packages against rebuilt packages (a misconception which I used to have) but against the existing buildroot. So, if we have package M and P (built against swig 4.3) in the buildroot and a mass rebuild is done then (assuming swig 4.4 in the buildroot as it is now) the follwoing happens: - M is rebuild in the mass rebuild side-tag against swig 4.4 - P is rebuilt in the mass rebuild side-tag against swig 4.3 and M *from the buildroot*, i.e. the pre-mass-rebuild M which had been built against swig 4.3. So, the P-rebuild will fail, and indeed it will fail until the mass-rebuild side-tag has been merged and P can be rebuilt against the proper M. ... and that is why it's important that we have no FTBFS packages before the mass rebuild :) [Meanwhile I've rebuilt M and P myself of course.] > In any case, before every SWIG update, I perform a test rebuild [1] to > check > if the new version breaks anything, and I collaborate with the SWIG > upstream > on potential fixes. Thanks. This catches potential problems which could arise during a rebuild and made it easy for me to just rebuild both (in a side-tag). > With the next update, I will try to send at least an email with information > about it and a list of packages that might be affected. Thanks! I'll also try and set watch flags for me on swig. Michael -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
