OCaml is a statically-safe programming language derived from ML which compiles to very fast native code. It contains native code backends for most architectures (all Fedora primary & secondary arches except s/390x in fact). Currently Fedora downstream carries two non-upstream backends: For ppc64 (big endian), a backend was written many years ago by David Woodhouse and was upstream for a time, but was dropped when the PlayStation 3 stopped supporting Linux. For ppc64le (little endian / POWER8) IBM's Michel Normand contributed a native code backend last year. The upstream project always carried a ppc (32 bit) backend, but we didn't use it and it's not very interesting for us. https://git.fedorahosted.org/cgit/fedora-ocaml.git/log/?h=fedora-24-4.02 Red Hat and IBM have provided help and loaned equipment to the upstream project, and as a result upstream have now added ppc64 and ppc64le backends. This work was merged at the end of August. These backends were inspired by the Red Hat & IBM work but are not derivatives. For details see: https://github.com/ocaml/ocaml/pull/225 So what I want to do is add the new backends [actually it's a single, combined and extended ppc/ppc64/ppc64le backend] to Fedora Rawhide, and drop our non-upstream backends. I have so far cherry-picked the merge commit on top of our Fedora OCaml tree, and I have dropped the downstream ppc64/ppc64le commits from our tree. (This is not pushed yet so doesn't appear in the git.fedorahosted.org link above.) I have tested it on ppc64le to check that the compiler compiles itself. A scratch build of the compiler with the new backend is here (I reserve the right to make further changes, this is just a preliminary test build): http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2741551 I used this to compile some ocaml-* packages on ppc64le, with -- it has to be said -- mixed results. There are two compiler bugs revealed. This compiler won't be able to compile all the ocaml-* packages on POWER. However because of the depth of dependencies, I cannot easily do scratch builds to find out which packages will be broken. Hence I'd like to do a full rebuild, again, to see what breaks. This *shouldn't affect primary architectures at all*, but will probably leave some broken ocaml-* packages on the ppc64/ppc64le secondary arches. We've actually done two complete rebuilds during the F24 development cycle already, which in a way is good because it means I know how long it should take, and I'm confident that the scripts I use will work again: http://git.annexia.org/?p=goals.git;a=blob;f=fedora_ocaml_rebuild.ml;h=13... So I'm pretty confident the primary arch rebuild will go fine, since it's not affected by any of the above changes - it's basically just a release bump. We don't even need to use a side tag for this because the "old" and "new" packages can be mixed on x86 - they are the same. The plan for ppc64/ppc64le would then be to fix the bugs revealed in the rebuild with upstream help. Any comments? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW