Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1897558
| Summary: | python-djvulibre fails to build with Python 3.10: Avoid using PyObject_AsCharBuffer(), PyObject_AsReadBuffer() and PyObject_AsWriteBuffer() | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Tomáš Hrnčiar <thrnciar> |
| Component: | python-djvulibre | Assignee: | Audrey Yeena Toskin <audrey> |
| Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | audrey, brian, mhroncok, thrnciar |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-03-11 18:49:00 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1890881 | ||
Does the Python Foundation not use semver...? I might have expected an API change like this to prompt changing to version 4.x... Well, whatever, I'm not super familiar with Python development, but I can always forward this bug report to the upstream developer. https://github.com/jwilk/python-djvulibre/issues/13 python-djvulibre's last release was in 2019; hopefully they're still maintaining it... But if not, I'd packaged it specifically for use as a dependency for the application Lector, which isn't super actively developed either and I assume didn't attract all that many Fedora users :/ (In reply to Andrew Toskin from comment #1) > Does the Python Foundation not use semver...? I might have expected an API > change like this to prompt changing to version 4.x... No, Python versioning predates semver. Upgrading to 3.10 is a major upgrade. IIRC the idea is that if all incompatible changes are done at the same time in Python 4, it will be a disaster. PyObject_AsWriteBuffer was only a compatibility shim wth Python 2. Now when Python 2 is after EOL, Python upstream has decided to remove most of such shims. Thanks for the upstream report. > PyObject_AsWriteBuffer was only a compatibility shim wth Python 2...
Gotcha. That makes sense, I guess.
I'll report back if the upstream writes a response worth sharing. In the meanwhile, let me know if you need anything else.
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle. Changing version to 34. python-djvulibre released v0.8.6, which is supposed to fix support for Python 3.10. So, update v0.8.6-1 is testing in Bodhi now. I'm not sure off the top of my head how to confirm upstream's fix, though, since after updating my Rawhide virtual machine, I still have Python 3.9. Hello, you can find instructions on how to test locally here: https://copr.fedorainfracloud.org/coprs/g/python/python3.10/ But it's not necessary because the update to 0.8.6 indeed fixes this issue. https://copr.fedorainfracloud.org/coprs/g/python/python3.10/build/2067642/ Thanks! Cool, thanks for checking. |
python-djvulibre fails to build with Python 3.10.0a2. Traceback (most recent call last): File "/usr/lib/python3.10/site-packages/nose/failure.py", line 39, in runTest raise self.exc_val.with_traceback(self.tb) File "/usr/lib/python3.10/site-packages/nose/loader.py", line 416, in loadTestsFromName module = self.importer.importFromPath( File "/usr/lib/python3.10/site-packages/nose/importer.py", line 47, in importFromPath return self.importFromDir(dir_path, fqname) File "/usr/lib/python3.10/site-packages/nose/importer.py", line 94, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File "/usr/lib64/python3.10/imp.py", line 234, in load_module return load_source(name, filename, file) File "/usr/lib64/python3.10/imp.py", line 171, in load_source module = _load(spec) File "<frozen importlib._bootstrap>", line 711, in _load File "<frozen importlib._bootstrap>", line 680, in _load_unlocked File "<frozen importlib._bootstrap_external>", line 791, in exec_module File "<frozen importlib._bootstrap>", line 228, in _call_with_frames_removed File "/builddir/build/BUILD/python-djvulibre-0.8.5/tests/test_decode.py", line 36, in <module> from djvu.decode import ( ImportError: /builddir/build/BUILDROOT/python-djvulibre-0.8.5-3.fc34.x86_64/usr/lib64/python3.10/site-packages/djvu/decode.cpython-310-x86_64-linux-gnu.so: undefined symbol: PyObject_AsWriteBuffer https://docs.python.org/3.10/whatsnew/changelog.html#id16 bpo-41103: PyObject_AsCharBuffer(), PyObject_AsReadBuffer(), PyObject_CheckReadBuffer(), and PyObject_AsWriteBuffer() are removed. Please migrate to new buffer protocol; PyObject_GetBuffer() and PyBuffer_Release(). For the build logs, see: https://copr-be.cloud.fedoraproject.org/results/@python/python3.10/fedora-rawhide-x86_64/01757428-python-djvulibre/ For all our attempts to build python-djvulibre with Python 3.10, see: https://copr.fedorainfracloud.org/coprs/g/python/python3.10/package/python-djvulibre/ 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.10: https://copr.fedorainfracloud.org/coprs/g/python/python3.10/ Let us know here if you have any questions. Python 3.10 will be included in Fedora 35. To make that update smoother, we're building Fedora packages with early pre-releases of Python 3.10. 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.