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 rebuild with the newest version will be performed at the latest during
the mass rebuild for the given version.
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.
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.
Regards,
Jitka
[1] https://copr.fedorainfracloud.org/coprs/jplesnik/swig-test/monitor/
--
Jitka Plesnikova
Senior Software Engineer
Red Hat
--
_______________________________________________
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
