On Fri, Oct 6, 2023 at 7:38 AM Richard W.M. Jones <rjo...@redhat.com> wrote: > > > On Fri, Oct 06, 2023 at 12:23:09PM +0100, Richard W.M. Jones wrote: > > On Fri, Oct 06, 2023 at 10:19:22AM +0100, Richard W.M. Jones wrote: > > > On Fri, Oct 06, 2023 at 08:48:52AM +0100, Richard W.M. Jones wrote: > > > > On Thu, Oct 05, 2023 at 10:03:59AM +0100, Richard W.M. Jones wrote: > > > > > Over the next few days I'm going to rebuild all OCaml packages in > > > > > Rawhide for OCaml 5.1, plus some non-OCaml packages that have OCaml > > > > > bindings. > > > > > > > > > > OCaml 5.1 is basically a small point release, but it does add back > > > > > native code support for riscv64 and s390x. The only remaining > > > > > architecture that hasn't been updated for OCaml 5 (and is therefore > > > > > still using the bytecode interpreter) is ppc64le. > > > > > > > > I think the builds are complete, except one which is running now. > > > > > > > > Only swig failed to build but that appears to be a general FTBFS bug: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2242372 > > > > > > > > I'll submit an update later today once I've done a few more checks. > > > > > > https://bodhi.fedoraproject.org/updates/FEDORA-2023-f0270d1637 > > > > ELN builds are failing because they need to be done in build order, > > not in random or alphabetical order or whatever ELN uses, so that's a > > thing ... > > Actually it's worse. Because this build of ocaml: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=107128822 > > was built before ocaml-srpm-macros was updated, it is being built > wrongly. The s390x build.log contains "--disable-native-compiler" but > it should be the opposite since native compilation is now supported. > > Now partly this is a mistake in the spec file which should BR > ocaml-srpm-macros >= 9 (I'll fix that shortly), but partly this is > caused by the wrong build ordering of ELN. >
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). 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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
