On Fri, Oct 06, 2023 at 11:16:17AM -0400, Stephen Gallagher wrote: > So, as we all know, build ordering is hard (and, despite intuitive > belief, not actually deterministic). > > ELN actually "cheats" somewhat when we do our builds. When we process > a batch of builds (triggered by a set of tag events that come in all > at the same time, such as when a side-tag is merged), we create a new > ELN side-tag, tag all of the new *Rawhide* builds into this side tag, > then trigger a rebuild of all of those builds for ELN. The result here > is that we use the Fedora build in the buildroot to avoid > bootstrapping issues. Now, there are some special-case packages for > which we do *NOT* automatically tag in the Fedora builds because they > have known incompatibilities. All OCAML packages fall into this > category, since we discovered about 9 months ago that we absolutely > cannot mix Fedora's OCAML builds with ELN's (I don't recall the exact > reason). It's probably because the build flags are different and (unnecessarily) OCaml encodes the build flags into the hashes of one of the base modules. I forget the exact details but there's an email on this list about it somewhere. Anyway the upshot is that if the build flags change at all, as they obviously do in Fedora vs RHEL, then the hashes change. We ought to fix this upstream ... Anyway I was going to say why not order the packages by their original build date in Koji? Rich. > Our other "cheat" when we rebuild a batch is that we automatically do > rebuilds at least once for any failure, to account for things like > build ordering and test flakes. In the case you're describing, > unforunately, we had a situation where 1) it was OCAML, and therefore > the Fedora packages weren't in the buildroot and 2) ocaml built > successfully against the older version of the macros. If the > BuildRequires: had been in play there, it would have failed, the batch > would have finished building whatever else was able to succeed (such > as the macros) and then the second pass would have succeeded. > > I'm sorry you got hit by this, Richard. It's an unfortunate confluence > of limitations in our rebuild approach. > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
