Fedora Account System
Red Hat Associate
Red Hat Customer
python-ZEO fails to build with Python 3.10.0a4. Client storage should work with multi-processing. ... SERVER FAILED TO START Exit status 0 ERROR ====================================================================== ERROR: test_work_with_multiprocessing (ZEO.tests.testZEO.MultiprocessingTests) Client storage should work with multi-processing. ---------------------------------------------------------------------- Traceback (most recent call last): File "/builddir/build/BUILD/ZEO-5.2.2/src/ZEO/tests/testZEO.py", line 1634, in test_work_with_multiprocessing addr, adminaddr = self.globs['start_server']() File "/builddir/build/BUILD/ZEO-5.2.2/src/ZEO/tests/forker.py", line 141, in start_server addr, stop = start_zeo_server( File "/builddir/build/BUILD/ZEO-5.2.2/src/ZEO/_forker.py", line 245, in start_zeo_server addr = qout.get(timeout=start_timeout) File "/builddir/build/BUILD/ZEO-5.2.2/src/ZEO/_forker.py", line 292, in get raise Empty() _queue.Empty ---------------------------------------------------------------------- Ran 6 tests in 33.043s FAILED (errors=1) Test failed: <unittest.runner.TextTestResult run=6 errors=1 failures=0> For the build logs, see: https://copr-be.cloud.fedoraproject.org/results/@python/python3.10/fedora-rawhide-x86_64/01865287-python-ZEO/ For all our attempts to build python-ZEO with Python 3.10, see: https://copr.fedorainfracloud.org/coprs/g/python/python3.10/package/python-ZEO/ 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.
The server is failing to start: ERROR ZEO.tests.forker:_forker.py:154 In server thread Traceback (most recent call last): File "/builddir/build/BUILD/ZEO-5.2.2/src/ZEO/_forker.py", line 121, in runner server.create_server() File "/builddir/build/BUILD/ZEO-5.2.2/src/ZEO/runzeo.py", line 249, in create_server self.server = create_server(self.storages, self.options) File "/builddir/build/BUILD/ZEO-5.2.2/src/ZEO/runzeo.py", line 344, in create_server return StorageServer( File "/builddir/build/BUILD/ZEO-5.2.2/src/ZEO/StorageServer.py", line 757, in __init__ self.acceptor = Acceptor(self, addr, ssl, msgpack) File "/builddir/build/BUILD/ZEO-5.2.2/src/ZEO/asyncio/server.py", line 235, in __init__ server = loop.run_until_complete(f) File "uvloop/loop.pyx", line 1456, in uvloop.loop.Loop.run_until_complete File "uvloop/loop.pyx", line 1685, in create_server TypeError: gather() got an unexpected keyword argument 'loop' It looks like ZEO expects a several years old version of uvloop. I'll have to see if we can port forward to a more recent version.
src/ZEO/asyncio/compat.py does this: if PY3: import asyncio try: from uvloop import new_event_loop except ImportError: from asyncio import new_event_loop I have verified that if I remove the uvloop BR, forcing the use of asyncio, that all tests pass. So the problem is definitely related to uvloop somehow. But isn't uvloop supposed to be a drop-in replacement for asyncio? The code above is the only explicit mention of uvloop in the sources. Does that mean there is a bug in uvloop, since asyncio works as expected?
Line 1685 of /usr/lib64/python3.10/site-packages/uvloop/loop.pyx: infos = await aio_gather(*fs, loop=self) There's the unexpected 'loop' keyword argument right there.
> Does that mean there is a bug in uvloop, since asyncio works as expected? It seems so. If you want to open a bugzilla for uvloov, please mark it as blocking this one, but do not reassign this bugzilla (we use it for tracking purposes). Fixed upstream in https://github.com/MagicStack/uvloop/commit/2870219558eba983813aeab249e08371266ab524
https://src.fedoraproject.org/rpms/python-uvloop/pull-request/3
FEDORA-2021-a3274e88eb has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
Thank you for the diagnosis and fix, Miro!