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: 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
Ran 6 tests in 33.043s
Test failed: <unittest.runner.TextTestResult run=6 errors=1 failures=0>
For the build logs, see:
For all our attempts to build python-ZEO with Python 3.10, see:
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:
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
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
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:
from uvloop import new_event_loop
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
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!