python-zarr fails to build with Python 3.10.0a2. Error log is too long to be pasted here. There is many test failures. Please see build logs. For the build logs, see: https://copr-be.cloud.fedoraproject.org/results/@python/python3.10/fedora-rawhide-x86_64/01806940-python-zarr/ For all our attempts to build python-zarr with Python 3.10, see: https://copr.fedorainfracloud.org/coprs/g/python/python3.10/package/python-zarr/ 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.
Many failures are: E AttributeError: '_cffi_backend.buffer' object has no attribute 'tobytes'
> E AttributeError: '_cffi_backend.buffer' object has no attribute 'tobytes' I checked cffi archives and it seems like this type never had a tobytes() method. I guess that previously, zarr didn't get a '_cffi_backend.buffer' object, but another type. Maybe buffer[:] or bytes(buffer) can be used instead. I don't understand what is the "ffi" module in the CFFI documentation. I found ffi.buffer documentation, not sure if it's related: https://cffi.readthedocs.io/en/latest/ref.html#ffi-buffer-ffi-from-buffer
New version of zarr - 2.6.1 is now available. I tried to rebuild it in our Python3.10 COPR, but the errors are still present. https://copr.fedorainfracloud.org/coprs/g/python/python3.10/build/1810021/
I reported the test failures to upstream: https://github.com/zarr-developers/zarr-python/issues/669
That is likely an issue with Python-LMDB; My redhat-foo is not that good, but it looks like from googling that Python-lmdb on EPEL is 0.92 (from 2016), and that there was many releases (8) since then, last one August 28 2020. Can you confirm your version of Python-lmdb ? Note that zarr-python failure due to lmdb are non-fatal as they will affect only people using lmdb stores. You can also just not-install python-lmdb when running the test suite; as it will automatically skip the lmdb test when it is not present. I'm happy to add a conditional version check in zarr on Python and Python-LMDB version that skip the test on 3.10 with a known incompatible version of LMDB if that can help.
Thank you for the pointer! Indeed, python-lmdb is at 0.92 even in Fedora. Here's a PR to update it to 1.0.0: https://src.fedoraproject.org/rpms/python-lmdb/pull-request/1
Indeed, python-zarr builds with Python 3.10 and python-lmdb 1.0.0: https://copr.fedorainfracloud.org/coprs/g/python/python3.10/build/1810977/
Ok, that is great. We've also added a workaround on zarr-python, so next release might not need python-lmdb 1.0.0 to work. Merging the workaround have closed the upstream issue; and as you point out that with LMDB 1.0.0 build appear to succeed; I'm going to assume it's ok to keep the upstream bug closed. Let me know if you need to re-open, and/or if there is anything we can do to make your life easier like notifying you on new release, or including specific patches/files in the source.
Yes, it's definitely OK to leave it closed. Thank you for investigating this one! We get release notifications from PyPI. (It's set up for zarr; I've recommended it to Fedora's lmdb maintainer as well.)
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle. Changing version to 34.
The new zarr is out with a workaround, and the Python 3.10 copr has been passing.