There happened mid air collision between OCaml rebuilds and Ruby rebuilds unfortunately. At least the following packages were build against old Ruby and will need rebuild again:
nbdkit libguestfs hivex Will you build them in f32-build-side-17977 side tag? Should I build them again or will you build them as soon the side tag is merged back? Vít Dne 18. 01. 20 v 13:03 Richard W.M. Jones napsal(a): > OCaml 4.10.0 beta1 was released upstream about a week ago > (https://bugzilla.redhat.com/show_bug.cgi?id=1673688). I'm intending > to build OCaml packages into a side tag starting today, and then > if it seems to work well integrate it into F32. > > The release notes for this are here: > > https://github.com/ocaml/ocaml/blob/4.10/Changes > > Please note there are some incompatible changes. The ones which I > think may affect Fedora are below (but there are more, please read the > release notes in full): > > * #1859, #9117: enforce safe (immutable) strings by removing > the -unsafe-string option by default. This can be overridden by > a configure-time option (available since 4.04 in 2016): > --disable-force-safe-string since 4.08, -no-force-safe-since > between 4.07 and 4.04. > > I don't intend to enable this option in our build. If my greps are > right there is one package (coccinelle) which is still hanging on > to -unsafe-string. > > In the force-safe-string mode (now the default), the return type of the > String_val macro in C stubs is `const char*` instead of > `char*`. This change may break C FFI code. > (Kate Deplaix) > > This will probably affect more packages, but is a trivial > const-correctness fix. > > * #8713: Introduce a state table in the runtime to contain the global > variables. > (The Multicore runtime will have one such state for each domain.) > > This changes the name of some internal variables of the OCaml runtime; > in many cases <caml/compatibility.h> provides a compatibility macro with > the old name, but programs using runtime internals may need to be fixed. > > Properly written FFI extensions shouldn't hit this, but I imagine > there will be some that are affected. I will try to fix these on a > case by case basis. > > Rich. > _______________________________________________ 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
