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/ Your package (pcs) Fails To Install in Fedora 43: can't install pcs: - nothing provides python(abi) = 3.13 needed by pcs-0.12.0-1.fc42.noarch can't install pcs-web-ui: - nothing provides python(abi) = 3.13 needed by pcs-web-ui-0.12.0-1.fc42.noarch If you know about this problem and are planning on fixing it, please acknowledge so by setting the bug status to ASSIGNED. If you don't have time to maintain this package, consider orphaning it, so maintainers of dependent packages realize the problem. If you don't react accordingly to the policy for FTBFS/FTI bugs (https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/), your package may be orphaned in 8+ weeks. P.S. The data was generated solely from koji buildroot, so it might be newer than the latest compose or the content on mirrors. To reproduce, use the koji/local repo only, e.g. in mock: $ mock -r fedora-43-x86_64 --config-opts mirrored=False install pcs pcs-web-ui P.P.S. If this bug has been reported in the middle of upgrading multiple dependent packages, please consider using side tags: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#updating-inter-dependent-packages Thanks!
I'm not quite sure why this is not a FTBFS bug since pcs-0.12.0-2.fc43 failed to build. pcs-0.12.0-1.fc42.noarch is not a rebuilt package and that is the reason why it fails to install. The "python(abi) = 3.13" requirement is generated by RPM during build time depending on the Python interpreter present on the build machine. This is not a real error. Here are the failed builds: https://koji.fedoraproject.org/koji/taskinfo?taskID=133516909 https://koji.fedoraproject.org/koji/taskinfo?taskID=133622677 I had a quick look and didn't find much because the build.log has over 33GB! Something seems to be really wrong. I'll try to resolve the issue next week.
Upstream 0.12.1 includes fixes for Python 3.14.
Yes, mlisik was faster than me and discovered that the issue was caused by a switch to the forkserver method in multiprocessing.Pool [1]. The issue was that the executors in the test suite no longer inherited context changed in other parts of pcs done outside of the test code (like modifying of sys.path). We decided to explicitly use the fork method because properly fixing this would make running tests harder. We already encountered the issue with deadlocks that is being solved in Python 3.14 - this was in pcsd, and we already use forkserver to deal with it. Since I'm done with the upstream releases now, I'll rebase pcs in Fedora very soon and that will fix this issue. [1] https://docs.python.org/3.14/whatsnew/3.14.html#incompatible-changes
Any chance the version bump can be done before the F43 mass rebuild starts on Wednesday? Otherwise we're going to end up with an attempted rebuild of 0.12.0 which ends up in an (endless?) loop of retries.
Yes, already on it: https://src.fedoraproject.org/rpms/pcs/pull-request/56
FEDORA-2025-6e6f4af8f4 (pcs-0.12.1-1.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2025-6e6f4af8f4
FEDORA-2025-6e6f4af8f4 (pcs-0.12.1-1.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.