All modules from PyPi packaged as RPM.
If the package failed to build, then there is nothing we can do about it. You may ping authors of PYP2RPM and kindly ask them to improve that tool.
What happens to cause the “forked” but un-built configurations in, for example:
Where the F39-42 configurations are all “forked” but not built?
The result of this is that a build on F41 trying to use the F41 configuration of that project ends up getting:
Problem: cannot install the best candidate for the job
- nothing provides python(abi) = 3.11 needed by python3-google-auth-oauthlib-1.0.0-1.fc38.noarch from copr_copr_PyPI
which I guess is because the F38 build that was done with python 3.11 is just pulled forward without a new build using the current python version for that configuration.
Cheers.
Hrm. Like this one too: Build 5209816 in @copr/PyPI but this one happened for post F37 configurations.
It seems it’s quite impossible to use @copr/PyPI for Fedora newer releases as it seems none of the packages have actually been rebuilt and they just keep getting pulled forward into configurations in which they don’t actually work.
How can this get resolved? At least a broken build for a given configuration doesn’t cause use of @copr/PyPI to break builds because it’s more like the package just isn’t available rather than it being available but broken for the pulled-forward configurations.