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.
Why no EPEL 8? Understanding of course that the success rate is going to be lower, indeed, but surely it’s not zero and some amount of EPEL 8 support is better than none, yes?
On the other end of the spectrum, why no EPEL 10?
Because every additional chroot need more attention and more time to fix issues. And we are not happy with the unresolved issue this repo have.
If you (or anyone else) is willing to co-maintain this project we will give you the rights to work on it.
I don’t think I am suggesting that adding a new chroot means that everything has to build in it successfully. I am not suggesting any additional effort be put towards making things that are not building yet to build. I am just suggesting adding new chroots to get whatever additional benefit (packages) they might provide without having to do anything. Surely some, even minor amount of packages that build for a given chroot is better than zero, yes?
On that note, I notice that some number of packages which have not had an update in some time don’t have builds for chroots that might have been added since they were last built. I.e.: Build 3067049 in @copr/PyPI.
I’m not sure what the solution is there, but it seems that when a new chroot is added a pass through all of the packages that have not previously built on that chroot would be beneficial. I guess that’s not something that COPR does natively, right? Should it perhaps? Should that be an RFE for COPR?