python-PyMuPDF fails to build with Python 3.14.0a5. + /usr/bin/pytest -k 'not test_codespell and not test_pylint and not test_fontarchive and not test_flake8 and not test_2791 and not test_3050 and not test_subset_fonts and not test_fit_springer and not test_spikes and not test_1645 and not test_4180 and not test_insert and not test_3087' ImportError while loading conftest '/builddir/build/BUILD/python-PyMuPDF-1.25.3-build/PyMuPDF-1.25.3/tests/conftest.py'. tests/conftest.py:4: in <module> import pymupdf ../BUILDROOT/usr/lib64/python3.14/site-packages/pymupdf/__init__.py:423: in <module> OptBytes = typing.Optional[typing.ByteString] /usr/lib64/python3.14/typing.py:3840: in __getattr__ raise AttributeError(f"module {__name__!r} has no attribute {attr!r}") E AttributeError: module 'typing' has no attribute 'ByteString' <sys>:0: DeprecationWarning: builtin type swigvarlink has no __module__ attribute According to https://docs.python.org/dev/whatsnew/3.14.html#typing ByteString has been removed from both typing and collections.abc modules. It had previously raised a DeprecationWarning since Python 3.12. https://docs.python.org/3.14/whatsnew/3.14.html For the build logs, see: https://copr-be.cloud.fedoraproject.org/results/@python/python3.14/fedora-rawhide-x86_64/08767758-python-PyMuPDF/ For all our attempts to build python-PyMuPDF with Python 3.14, see: https://copr.fedorainfracloud.org/coprs/g/python/python3.14/package/python-PyMuPDF/ Testing and mass rebuild of packages is happening in copr. You can follow these instructions to test locally in mock if your package builds with Python 3.14: https://copr.fedorainfracloud.org/coprs/g/python/python3.14/ Let us know here if you have any questions. Python 3.14 is planned to be included in Fedora 43. To make that update smoother, we're building Fedora packages with all pre-releases of Python 3.14. A build failure prevents us from testing all dependent packages (transitive [Build]Requires), so if this package is required a lot, it's important for us to get it fixed soon. We'd appreciate help from the people who know this package best, but if you don't want to work on this now, let us know so we can try to work around it on our side.
Huh! What better day to file a bug re py 3.14 than 3/14! Since you don't bump versions but rebuild I"m wondering about dependencies, though: python-PyMuPDF requires python3-mupdf which are swig generated bindings from package mupdf. I maintain both mupdf and PyMuPDF, so component assignment is not critical here. mupdf does not have a test suite, PyMuPDF does. Has the complete chain been rebuilt and py 3.14 enabled? In any case, py docs suggest `collections.abc.Buffer` which has been introduced in py 3.12 only - upstream will not like that requirement; alternatively, `bytes | bytearray | memoryview`, which is a mouthful unless one scans the codebase for which interface is required - or one uses a type alias ByteString ... Thanks for the clear instructions in copr (as always)!
It certainly looks that way: https://download.copr.fedorainfracloud.org/results/@python/python3.14/fedora-rawhide-x86_64/08767758-python-PyMuPDF/builder-live.log.gz : python3-mupdf x86_64 1.25.4-1.fc43 copr_base 18.5 MiB mupdf-devel x86_64 1.25.4-1.fc43 copr_base 2.2 MiB We're still in the alpha phase, awaiting the 6th one (planned for today, of course, given the date). Only after beta 1 planned for May we'll be reasonably sure that nothing new should get broken. Till then there may be more fluctuations.
(In reply to Karolina Surma from comment #2) > We're still in the alpha phase, awaiting the 6th one (planned for today, of > course, given the date). Only after beta 1 planned for May we'll be > reasonably sure that nothing new should get broken. Till then there may be > more fluctuations. I just pushed a fix. Should I wait for more stabilization to happen before a rebuild?
The build is successful, so feel free to close the bug. If anything new appears, I'll just open another one with the relevant log excerpt. Thank you for the fix!