On Tuesday, February 21, 2017 1:45:38 PM CET Michal Novotny wrote: > On Tue, Feb 21, 2017 at 12:03 PM, Pavel Raiskup <prais...@redhat.com> wrote: > > > 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 > > such > > > option. > > > > Definitely. > > > > 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 already > 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. Thanks, Pavel > > > Pavel > > > > > _______________________________________________ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
