Dear package maintainer, this bugzilla is automated becasue the number of impacted packages it too high to go trough manually. It appears that your package failed to build with setuptools 74.1.3 and wheel 0.44 in https://copr.fedorainfracloud.org/coprs/churchyard/setuptools-74/package/glycin/ While it succeeded with setuptools 69.2.0 and wheel 0.43 in https://copr.fedorainfracloud.org/coprs/churchyard/setuptools-control/package/glycin/ This usually means this package fails to build with setuptools 74+ We plan to update setuptools to version 74 or newer in Fedora 42. This is and approved Fedora 42 Change: https://fedoraproject.org/wiki/Changes/Setuptools_74+ Please analyze the failure and fix it in rawhide. Thanks. You can use the builds from the churchyard/setuptools-74 copr for local testing. mock -r fedora-rawhide-x86_64 --addrepo 'https://download.copr.fedorainfracloud.org/results/churchyard/setuptools-74/fedora-rawhide-$basearch/' One of the most common problems is that the setup.py test command cannot be used. If that is the case here, run the tests in %check differently, e.g. via %pytest, %tox, %{python3} -m unittest, etc. If you need help, reach out to me in this bugzilla.
The error from the build log is: ``` /usr/bin/ld: /tmp/cceX8SM5.ltrans0.ltrans.o:(.data.rel+0x0): undefined reference to `gly_loader_get_type' /usr/bin/ld: /tmp/cceX8SM5.ltrans0.ltrans.o:(.data.rel+0x8): undefined reference to `gly_image_get_type' /usr/bin/ld: /tmp/cceX8SM5.ltrans0.ltrans.o:(.data.rel+0x10): undefined reference to `gly_frame_get_type' /usr/bin/ld: /tmp/cceX8SM5.ltrans0.ltrans.o:(.data.rel+0x18): undefined reference to `gly_sandbox_selector_get_type' /usr/bin/ld: /tmp/cceX8SM5.ltrans0.ltrans.o:(.data.rel+0x20): undefined reference to `gly_memory_format_get_type' /usr/bin/ld: /tmp/cceX8SM5.ltrans0.ltrans.o:(.data.rel+0x28): undefined reference to `gly_loader_error_get_type' /usr/bin/ld: /tmp/cceX8SM5.ltrans0.ltrans.o:(.data.rel+0x30): undefined reference to `gly_loader_error_quark' collect2: error: ld returned 1 exit status ``` I have no idea how a setuptools update could cause linker errors in a Rust package :)
I've submitted more builds to both coprs to rule out flakiness. Another possibility is another package "poisoned" the copr, but the root.log only shows python3-setuptools from copr_base.
Flaky it is.
Phew 😅 thank you for double-checking!