Hey, JFYI, we enabled F31 chroots yesterday in Fedora Copr.
The process was surprisingly slow, and a lot of things didn't work properly during the process. Sorry for that, we'll take a look on how to minimize the problems for the next runs.
One warning on F31 chroots in copr! The F31 has Python 3.7, while rawhide has Python 3.8. Since we enabled the F31 chroot pretty late in Copr - after Python 3.8 landed rawhide - it might happen that you rebuilt your package against 3.8, and it got later copied into F31 chroot (with the rest of the packages). If this happened to you, you have non-installable package in repo.
It is hard hard to work-around now (rebuild is needed), if you have serious troubles with rebuilding - let us know, we can remove the packages manually from repositories.
Again, sorry for inconvenience, and happy building! Pavel
On Thu, 29 Aug 2019 at 22:51, Pavel Raiskup praiskup@redhat.com wrote:
Hey, JFYI, we enabled F31 chroots yesterday in Fedora Copr.
The process was surprisingly slow, and a lot of things didn't work properly during the process. Sorry for that, we'll take a look on how to minimize the problems for the next runs.
One warning on F31 chroots in copr! The F31 has Python 3.7, while rawhide has Python 3.8. Since we enabled the F31 chroot pretty late in Copr - after Python 3.8 landed rawhide - it might happen that you rebuilt your package against 3.8, and it got later copied into F31 chroot (with the rest of the packages). If this happened to you, you have non-installable package in repo.
The same happens for packages linking against gsl-devel: there was a soname bump in rawhide that didn't land in F31. All Copr packages built after the official branching point were linked against rawhide instead of F31, so they require the wrong library version. Check this and probably other soname bumps during the last couple of weeks.
Also, these packages are suffixed fc32 in the F31 chroot. Has dnf any problem with that?
BTW, is there any tool to check which packages in a chroot are broken without actually adding the repo and trying to install them?
Iñaki
On Thursday, August 29, 2019 11:10:37 PM CEST Iñaki Ucar wrote:
On Thu, 29 Aug 2019 at 22:51, Pavel Raiskup praiskup@redhat.com wrote:
Hey, JFYI, we enabled F31 chroots yesterday in Fedora Copr.
The process was surprisingly slow, and a lot of things didn't work properly during the process. Sorry for that, we'll take a look on how to minimize the problems for the next runs.
One warning on F31 chroots in copr! The F31 has Python 3.7, while rawhide has Python 3.8. Since we enabled the F31 chroot pretty late in Copr - after Python 3.8 landed rawhide - it might happen that you rebuilt your package against 3.8, and it got later copied into F31 chroot (with the rest of the packages). If this happened to you, you have non-installable package in repo.
The same happens for packages linking against gsl-devel: there was a soname bump in rawhide that didn't land in F31. All Copr packages built after the official branching point were linked against rawhide instead of F31, so they require the wrong library version. Check this and probably other soname bumps during the last couple of weeks.
Also, these packages are suffixed fc32 in the F31 chroot. Has dnf any problem with that?
I believe no. Dnf/RPM shouldn't operate with dist tag. Except for the version comparison (if package ENVRA only differs in dist tag number, the fc32 > fc31).
BTW, is there any tool to check which packages in a chroot are broken without actually adding the repo and trying to install them?
Maybe repoclosure?
Pavel
Iñaki
On Fri, 30 Aug 2019 at 08:51, Pavel Raiskup praiskup@redhat.com wrote:
BTW, is there any tool to check which packages in a chroot are broken without actually adding the repo and trying to install them?
Maybe repoclosure?
That's *very* helpful, thanks!
Iñaki
copr-devel@lists.fedorahosted.org