Bug 1791969
| Summary: | py4j version 0.10.9 / fails to build with Python 3.9: imports abc from collections | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Miro Hrončok <mhroncok> |
| Component: | py4j | Assignee: | Raphael Groner <projects.rg> |
| Status: | CLOSED DEFERRED | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | cstratak, hugovk+redhatbugzilla, mhroncok, mplch, projects.rg |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | py4j-0.10.9-1.fc32 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-02-28 09:07:40 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: | 1785415 | ||
This has been fixed in master in July 2019 (PR https://github.com/bartdag/py4j/pull/356) but the last release 0.10.8.1 was in October 2018 (https://github.com/bartdag/py4j/releases/tag/0.10.8.1). I've asked for a new release in the issue: https://github.com/bartdag/py4j/issues/345. This has been released in version 0.10.9: https://github.com/bartdag/py4j/issues/345#issuecomment-578414971. (In reply to Hugo van Kemenade from comment #2) > This has been released in version 0.10.9: > https://github.com/bartdag/py4j/issues/345#issuecomment-578414971. Thanks for the hint. It's not yet released. https://github.com/bartdag/py4j/commit/3745e493ee8ece0279a57683bbe3784db785b94e > Thanks for the hint. It's not yet released. > https://github.com/bartdag/py4j/commit/ > 3745e493ee8ece0279a57683bbe3784db785b94e 0.10.9 was released Jan 25, 2020: https://pypi.org/project/py4j/0.10.9/ They forgot to push the tags, but it's now done: https://github.com/bartdag/py4j/issues/345#issuecomment-583247140 https://github.com/bartdag/py4j/releases/tag/0.10.9 Tests execution in mock gets stuck after:
[exec] testPythonToJava (py4j.tests.memory_leak_test.ClientServerTest) ... ok
[exec] testPythonToJavaToPython (py4j.tests.memory_leak_test.ClientServerTest) ... ok
Successfully built in rawhide. This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle. Changing version to 32. Please try to rebuild with recent rawhide and feel free to reopen this bug if there's still an issue or you'd like to see builds for other branches. There still is an issue, reopening.
Seems like some network test is failing:
[junit] Received temp: null
[junit] Testsuite: py4j.GatewayServerTest
[junit] Tests run: 5, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.813 sec
[junit]
[junit] Testcase: testListener(py4j.GatewayServerTest): Caused an ERROR
[junit] null
[junit] py4j.Py4JNetworkException
[junit] at py4j.GatewayServer.startSocket(GatewayServer.java:789)
[junit] at py4j.GatewayServer.start(GatewayServer.java:764)
[junit] at py4j.GatewayServer.start(GatewayServer.java:747)
[junit] at py4j.GatewayServerTest.testListener(GatewayServerTest.java:82)
[junit] Caused by: java.net.BindException: Address already in use (Bind failed)
[junit] at java.net.PlainSocketImpl.socketBind(Native Method)
[junit] at java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
[junit] at java.net.ServerSocket.bind(ServerSocket.java:390)
[junit] at py4j.GatewayServer.startSocket(GatewayServer.java:787)
[junit]
[junit]
BUILD FAILED
/builddir/build/BUILD/py4j-0.10.9/py4j-java/build.xml:141: Test py4j.GatewayServerTest failed
For the build logs, see:
https://copr-be.cloud.fedoraproject.org/results/@python/python3.9/fedora-rawhide-x86_64/01242346-py4j/
> [junit] Caused by: java.net.BindException: Address already in use (Bind failed)
Well known issue when execution is done of several tests in parallel, in optimization concerns. Will take a closer look.
In Python 3.9.0a4 we have managed to revert the change that disables importing abstract base classes (collections.abc) directly form the regular collections module. It was reverted to ease transition for projects that did not yet actually dropped support for Python 2.7. The removal is scheduled for Python 3.10 instead. We are mass closing all the bug reports about build failures that were caused by this. Expect a new Bugzilla report in case this package fails to build with Python 3.9 for a different reason as well. In case you haven't done this already, we highly recommend to talk to your upstream and get this fixed anyway, because this will return in Python 3.10 and Python upstream is very unlikely to postpone this once more. In case you've already done that, thank you (this message is mass posted to all the relevant Bugzillas). |
py4j fails to build with Python 3.9.0a2. Traceback (most recent call last): File "/usr/lib/python3.9/site-packages/sphinx/config.py", line 361, in eval_config_file execfile_(filename, namespace) File "/usr/lib/python3.9/site-packages/sphinx/util/pycompat.py", line 81, in execfile_ exec(code, _globals) File "/builddir/build/BUILD/py4j-0.10.8.1/py4j-web/conf.py", line 22, in <module> import py4j.java_gateway File "/builddir/build/BUILD/py4j-0.10.8.1/py4j-python/src/py4j/java_gateway.py", line 2496, in <module> __import__("py4j.java_collections") File "/builddir/build/BUILD/py4j-0.10.8.1/py4j-python/src/py4j/java_collections.py", line 13, in <module> from collections import ( ImportError: cannot import name 'MutableMapping' from 'collections' (/usr/lib64/python3.9/collections/__init__.py) See https://docs.python.org/3.9/whatsnew/3.9.html#removed "The abstract base classes in collections.abc no longer are exposed in the regular collections module. This will help create a clearer distinction between the concrete classes and the abstract base classes." For the build logs, see: https://copr-be.cloud.fedoraproject.org/results/@python/python3.9/fedora-rawhide-x86_64/01148667-py4j/ For all our attempts to build py4j with Python 3.9, see: https://copr.fedorainfracloud.org/coprs/g/python/python3.9/package/py4j/ 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.9: https://copr.fedorainfracloud.org/coprs/g/python/python3.9/ Let us know here if you have any questions. Python 3.9 will be included in Fedora 33. To make that update smoother, we're building Fedora packages with early pre-releases of Python 3.9. 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.