python-pexpect failed to build from source in Fedora rawhide/f42 https://koji.fedoraproject.org/koji/taskinfo?taskID=128086738 For details on the mass rebuild see: https://fedoraproject.org/wiki/Fedora_42_Mass_Rebuild Please fix python-pexpect at your earliest convenience and set the bug's status to ASSIGNED when you start fixing it. If the bug remains in NEW state for 8 weeks, python-pexpect will be orphaned. Before branching of Fedora 43, python-pexpect will be retired, if it still fails to build. For more details on the FTBFS policy, please visit: https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
Created attachment 2072060 [details] build.log file build.log too big, will only attach last 32768 bytes
Created attachment 2072061 [details] root.log file root.log too big, will only attach last 32768 bytes
Created attachment 2072062 [details] state.log
This bug appears to have been reported against 'rawhide' during the Fedora Linux 42 development cycle. Changing version to 42.
The problem here is that the package FTBFS on ppc64le and s390x only (as shown in https://koji.fedoraproject.org/koji/taskinfo?taskID=134147966, a scratch build where I forced the package to build on all architectures), because the package is “too slow” on those architectures, so we get: > FAILED tests/test_performance.py::PerformanceTestCase::test_100000 - pexpect.exceptions.TIMEOUT: Timeout exceeded. I recommend just ignoring tests/test_performance.py entirely: these tests help catch serious performance regressions upstream, but gating downstream builds on particular benchmark results doesn’t make sense across diverse hardware. I opened https://src.fedoraproject.org/rpms/python-pexpect/pull-request/14 to implement this suggestion.
FEDORA-2025-9227dd44fe (python-pexpect-4.9.0-11.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2025-9227dd44fe
FEDORA-2025-9227dd44fe (python-pexpect-4.9.0-11.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.