Fedora Account System
Red Hat Associate
Red Hat Customer
pychess fails to build with Python 3.14.0a2. ====================================================================== ERROR: test1 (analysis.CECPTests.test1) Test analyzing in forced mate situations ---------------------------------------------------------------------- Traceback (most recent call last): File "/builddir/build/BUILD/pychess-1.0.3-build/pychess-1.0.3/testing/analysis.py", line 79, in setUp self.loop = asyncio.get_event_loop() ~~~~~~~~~~~~~~~~~~~~~~^^ File "/usr/lib64/python3.14/asyncio/events.py", line 681, in get_event_loop raise RuntimeError('There is no current event loop in thread %r.' % threading.current_thread().name) RuntimeError: There is no current event loop in thread 'MainThread'. ====================================================================== ERROR: test2 (analysis.CECPTests.test2) Test analyzing in promotion situations ---------------------------------------------------------------------- Traceback (most recent call last): File "/builddir/build/BUILD/pychess-1.0.3-build/pychess-1.0.3/testing/analysis.py", line 79, in setUp self.loop = asyncio.get_event_loop() ~~~~~~~~~~~~~~~~~~~~~~^^ File "/usr/lib64/python3.14/asyncio/events.py", line 681, in get_event_loop raise RuntimeError('There is no current event loop in thread %r.' % threading.current_thread().name) RuntimeError: There is no current event loop in thread 'MainThread'. According to https://docs.python.org/dev/whatsnew/3.14.html#id3 Removed implicit creation of event loop by asyncio.get_event_loop(). It now raises a RuntimeError if there is no current event loop. (Contributed by Kumar Aditya in gh-126353.) https://docs.python.org/3.14/whatsnew/3.14.html For the build logs, see: https://copr-be.cloud.fedoraproject.org/results/@python/python3.14/fedora-rawhide-x86_64/08302059-pychess/ For all our attempts to build pychess with Python 3.14, see: https://copr.fedorainfracloud.org/coprs/g/python/python3.14/package/pychess/ 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.14: https://copr.fedorainfracloud.org/coprs/g/python/python3.14/ Let us know here if you have any questions. Python 3.14 is planned to be included in Fedora 43. To make that update smoother, we're building Fedora packages with all pre-releases of Python 3.14. 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.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 42 development cycle. Changing version to 42.
*** Bug 2371777 has been marked as a duplicate of this bug. ***
This currently fails with: + /usr/bin/python3 setup.py build '--executable=/usr/bin/python3 -sP' Warning: eco.db not found, please run pgn2ecodb.sh Traceback (most recent call last): File "/builddir/build/BUILD/pychess-1.0.3-build/pychess-1.0.3/setup.py", line 56, in <module> from distutils.command.register import register ModuleNotFoundError: No module named 'distutils.command.register'
> Warning: eco.db not found, please run pgn2ecodb.sh What happens with legacy db? What if there is no db? Guess it is a completely fresh installation, of course update package in running system is different.
That warning is not that important. The bigger issue is that this does not build with the current setuptools (No module named 'distutils.command.register') nor Python (RuntimeError: There is no current event loop in thread 'MainThread')
1. Well, eco.db may be user specific so general rpm process isn't involved. 2. Because distutils was removed in Python 3.12, we get ModuleNotFoundError: module named 'distutils'. Possible fix: dependency to setuptools - PEP 632 https://stackoverflow.com/questions/77931666/modulenotfounderror-no-module-named-distutils-how-to-solve-this-in-macos https://peps.python.org/pep-0632/ 3. CPython unbundled setuptools. Possible fix: replace.. loop = asyncio.get_event_loop() with.. loop = asyncio.new_event_loop() asyncio.set_event_loop(loop) https://github.com/python/cpython/issues/95299
> Because distutils was removed in Python 3.12, we get ModuleNotFoundError: module named 'distutils'. This was already fixed back then by using setuptools, which provides its own distutils module. However, now they have removed distutils.command.register from it.
Honestly, is that intentional to break build tools?
No idea. setuptools upstream is not very interested at maintaining compatibility with old distutils. I'm not happy about that either.
Hello, Please note that this comment was generated automatically by https://pagure.io/releng/blob/main/f/scripts/ftbfs-fti/follow-policy.py If you feel that this output has mistakes, please open an issue at https://pagure.io/releng/ This package fails to install and maintainers are advised to take one of the following actions: - Fix this bug and close this bugzilla once the update makes it to the repository. (The same script that posted this comment will eventually close this bugzilla when the fixed package reaches the repository, so you don't have to worry about it.) or - Move this bug to ASSIGNED if you plan on fixing this, but simply haven't done so yet. or - Orphan the package if you no longer plan to maintain it. If you do not take one of these actions, the process at https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/#_package_removal_for_long_standing_ftbfs_and_fti_bugs will continue. This package may be orphaned in 7+ weeks. This is the first reminder (step 3) from the policy. Don't hesitate to ask for help on https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/ if you are unsure how to fix this bug.
Hello, Please note that this comment was generated automatically by https://pagure.io/releng/blob/main/f/scripts/ftbfs-fti/follow-policy.py If you feel that this output has mistakes, please open an issue at https://pagure.io/releng/ This package fails to install and maintainers are advised to take one of the following actions: - Fix this bug and close this bugzilla once the update makes it to the repository. (The same script that posted this comment will eventually close this bugzilla when the fixed package reaches the repository, so you don't have to worry about it.) or - Move this bug to ASSIGNED if you plan on fixing this, but simply haven't done so yet. or - Orphan the package if you no longer plan to maintain it. If you do not take one of these actions, the process at https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/#_package_removal_for_long_standing_ftbfs_and_fti_bugs will continue. This package may be orphaned in 4+ weeks. This is the second reminder (step 4) from the policy. Don't hesitate to ask for help on https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/ if you are unsure how to fix this bug.
I've spent some time on this in the last couple of days - to try and fix the Games spin - but, well, I'm giving up. I have a spec that bumps to 1.0.5 and at least builds successfully - had to drop the first three patches, and change the sqlalchemy buildrequire to >= 2, run those two generator commands it complains about, drop the "debian specific menu stuff" bit, and add a buildrequire on gstreamer1-plugins-base - but the tests fail horribly with a whole *ton* of output. The definite failures I can identify are all about asyncio, and this thing's use of asyncio is so weird and complicated and apparently broken that I'm not going to waste a bunch of my time trying to figure out / fix it. Building 1.0.5 fails even on Fedora 42 (Python 3.13), with these errors: ====================================================================== ERROR: test1 (analysis.CECPTests.test1) Test analyzing in forced mate situations ---------------------------------------------------------------------- Traceback (most recent call last): File "/builddir/build/BUILD/pychess-1.0.5-build/pychess-1.0.5/testing/analysis.py", line 83, in setUp self.engineA, self.analyzerA = self._setupengine(ANALYZING) ~~~~~~~~~~~~~~~~~^^^^^^^^^^^ File "/builddir/build/BUILD/pychess-1.0.5-build/pychess-1.0.5/testing/analysis.py", line 60, in _setupengine analyzer = CECPEngine(engine, WHITE, 2, 0) File "/builddir/build/BUILD/pychess-1.0.5-build/pychess-1.0.5/lib/pychess/Players/CECPEngine.py", line 174, in __init__ self.parse_line_task = asyncio.create_task(self.parseLine(self.engine)) ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib64/python3.13/asyncio/tasks.py", line 407, in create_task loop = events.get_running_loop() RuntimeError: no running event loop ====================================================================== ERROR: test2 (analysis.CECPTests.test2) Test analyzing in promotion situations ---------------------------------------------------------------------- Traceback (most recent call last): File "/builddir/build/BUILD/pychess-1.0.5-build/pychess-1.0.5/testing/analysis.py", line 83, in setUp self.engineA, self.analyzerA = self._setupengine(ANALYZING) ~~~~~~~~~~~~~~~~~^^^^^^^^^^^ File "/builddir/build/BUILD/pychess-1.0.5-build/pychess-1.0.5/testing/analysis.py", line 60, in _setupengine analyzer = CECPEngine(engine, WHITE, 2, 0) File "/builddir/build/BUILD/pychess-1.0.5-build/pychess-1.0.5/lib/pychess/Players/CECPEngine.py", line 174, in __init__ self.parse_line_task = asyncio.create_task(self.parseLine(self.engine)) ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib64/python3.13/asyncio/tasks.py", line 407, in create_task loop = events.get_running_loop() RuntimeError: no running event loop ====================================================================== ERROR: test0 (learn.LearnTests.test0) Init layout ---------------------------------------------------------------------- Traceback (most recent call last): File "/builddir/build/BUILD/pychess-1.0.5-build/pychess-1.0.5/testing/learn.py", line 40, in setUp self.dd_task = asyncio.create_task(dd.start()) ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^ File "/usr/lib64/python3.13/asyncio/tasks.py", line 407, in create_task loop = events.get_running_loop() RuntimeError: no running event loop ====================================================================== ERROR: test1 (learn.LearnTests.test1) Start next endgame ---------------------------------------------------------------------- Traceback (most recent call last): File "/builddir/build/BUILD/pychess-1.0.5-build/pychess-1.0.5/testing/learn.py", line 40, in setUp self.dd_task = asyncio.create_task(dd.start()) ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^ File "/usr/lib64/python3.13/asyncio/tasks.py", line 407, in create_task loop = events.get_running_loop() RuntimeError: no running event loop ====================================================================== ERROR: test2 (learn.LearnTests.test2) Start next lecture ---------------------------------------------------------------------- Traceback (most recent call last): File "/builddir/build/BUILD/pychess-1.0.5-build/pychess-1.0.5/testing/learn.py", line 40, in setUp self.dd_task = asyncio.create_task(dd.start()) ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^ File "/usr/lib64/python3.13/asyncio/tasks.py", line 407, in create_task loop = events.get_running_loop() RuntimeError: no running event loop ====================================================================== ERROR: test3 (learn.LearnTests.test3) Start next lesson ---------------------------------------------------------------------- Traceback (most recent call last): File "/builddir/build/BUILD/pychess-1.0.5-build/pychess-1.0.5/testing/learn.py", line 40, in setUp self.dd_task = asyncio.create_task(dd.start()) ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^ File "/usr/lib64/python3.13/asyncio/tasks.py", line 407, in create_task loop = events.get_running_loop() RuntimeError: no running event loop ====================================================================== ERROR: test4 (learn.LearnTests.test4) Start next puzzle ---------------------------------------------------------------------- Traceback (most recent call last): File "/builddir/build/BUILD/pychess-1.0.5-build/pychess-1.0.5/testing/learn.py", line 40, in setUp self.dd_task = asyncio.create_task(dd.start()) ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^ File "/usr/lib64/python3.13/asyncio/tasks.py", line 407, in create_task loop = events.get_running_loop() RuntimeError: no running event loop ---------------------------------------------------------------------- Ran 144 tests in 168.146s FAILED (errors=7) ...plus a ton of pygtk deprecation warnings and complaints from asyncio about things not being awaited. So I kinda think pychess's use of asyncio is just fundamentally not working right since at least Python 3.13. I've added some notes to https://github.com/pychess/pychess/issues/2299 upstream.
Oh, I did try some 'obvious' hacks, like this: def setUp(self): try: self.loop = asyncio.get_event_loop() except RuntimeError: self.loop = asyncio.new_event_loop() ...or using `asyncio.run()` instead of messing with the event loop directly, but none of it worked, it all just still failed in other ways. I feel like something more fundamental is going on, like previously there *was* a running event loop at the time these setUp methods ran, or something.
OK, so I lied about giving up! I've figured out a few things that make the situation rather clearer... 1. I can actually get 1.0.3 to build and pass tests using a fairly simple tweak to the affected tests 2. The test failures we see trying to build 1.0.5 aren't Fedora-specific or triggered by any recent Python. The same failures actually happen in upstream's CI, running on Python 3.12 on Ubuntu - https://github.com/pychess/pychess/issues/2360 . But they never noticed because their test runner is broken and always returns 0: https://github.com/pychess/pychess/pull/2359 So, I guess I'll send my kinda-fixed 1.0.3 build for now, it's better than what we have (I tested it at least launches and draws chessboards and things). Let's hope upstream can resolve the test failures with 1.0.5 (they actually bisect to https://github.com/pychess/pychess/pull/1995 ).
https://bodhi.fedoraproject.org/updates/FEDORA-2025-2203e577cf
Adam, part of your change was offered 4 months ago via https://src.fedoraproject.org/rpms/pychess/pull-request/2 Also, see https://src.fedoraproject.org/rpms/pychess/pull-request/3, which fixes one of the comments.
yes, sorry, I didn't notice it. It would've been easier to notice if the bug was in POST state as it's supposed to be when a fix is suggested :/ in any case, I think the version I did is better (it's a direct backport of the commit as it landed upstream). Also, I have 1.0.5 building now, but am talking with upstream about better overall approaches to handling async in the testing rather than doing spot fixes, as well...
The fix was suggested before this bug was opened. I guess it would have been better if the package maintainers had responded to either the Bugzilla or the PR. This package was almost about to be orphaned, but by fixing it instead, we are now ready to repeat this exercise next time it's broken :)
We do have at least one actual user in https://github.com/pychess/pychess/issues/2299 , so it seems good to keep the package working if we can :D