On Mon, Feb 24, 2020 at 01:53:37PM -0700, Jerry James wrote: > On Mon, Feb 24, 2020 at 1:57 AM Richard W.M. Jones <rjones@xxxxxxxxxx> wrote: > > * z3 - https://bugzilla.redhat.com/show_bug.cgi?id=1792740 > > Actually, z3 should build. I checked in a workaround. The bug is > still open to remind me to figure out and fix the real problem. Got it, thanks. > > coq and friends failed last time, but I believe they should work now. > > Latest status is in this thread: > > https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/thread/6I2CB4KNAZXH6TKX5WQZJ3ZQGBIOCNJK/ > > I'm still 3 package reviews away from being able to update the coq > stack. Real soon now.... I guess I could help here. Do you have a link to any unassigned reviews? > I may have caused you a problem with the ocaml-ounit update I > requested. Now we have ocaml-ounit requiring ocaml-dune to build, and > ocaml-dune requiring ocaml-ounit to run its tests. I guess ocaml-dune > will need a bootstrap mode where it does not run its tests. > > That's not going to be the end, either. There is a new upstream > release of menhir, and it has switched to using dune to build. That > means that we will have menhir requiring dune to build, and dune > requiring menhir to run its tests. > > And then coq is in the process of switching over to using dune to > build. It can still be built the old way, but some day that will not > be possible. Then coq will need dune to build, menhir will need coq > to build, and dune will need menhir to run its tests. It's actually not so much of a problem with binaries (unlike OCaml libraries). Packages that build self-contained binaries (menhir, dune) don't have to be built in the normal build-dependency order since the old binaries will presumably still work to build the parser (menhir) or run the build (dune). The only problem would be if the older binary has a bug or lacks a feature which is required to build the newer package, but I suppose that is not likely. I guess I'll find out shortly if this theory is true or not. The bigger issue is going to be goals itself which, unlike make, will not arbitrarily break dependency cycles. However I should still be able to break those manually in the Goalfile, or failing that temporarily in the spec file. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org _______________________________________________ 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
