On Tuesday, February 21, 2017 1:45:38 PM CET Michal Novotny wrote:
On Tue, Feb 21, 2017 at 12:03 PM, Pavel Raiskup
> On Tuesday, February 21, 2017 9:31:33 AM CET Michal Novotny wrote:
> > I plan to allow rebuilding all packages in a new chroot if users welcome
> > option.
> But how this is going to be implemented? Simply resubmit builds into
> initialized (empty) buildroot in random order work in most of the cases.
In theory, we can find out, from db, the order, in which the existing packages
were successfully built and build in that same order.
Many times the order is not enough. There are two(or more)-step bootstrap
processes where you need to build some trimmed package A, then build dependency
B, and then build full package A.
We can, however, always add the chroot where the packages are
built as an 'additional repository' for the new chroot.
Yes, that's what I've been doing (suggested by Mirek) .. but doing this manually
for like 7 maintained chroots is pretty error prone and boring manual job .. :(
You need to keep in mind to drop that additional repo once you bootstrapped...
Truth is that I should script this somehow via copr-cli, but ...
Anyways, yes -> if the Fedora N-1 was available automatically during
"mass-copr-rebuild", it would resolve the issues.
There is an issue that when we do rebuilding, we use the latest
"upstream" for MockSCM, PyPI, GitAndTito, Rubygems methods, which could
have evolved from the latest build in the linked chroot.
That's right but I don't think we can do much about it (except for the explicit
"copy fedora N-1 builds only" option). FTBFS bugs happen, the sooner user is
informed the better.