Ocaml-devel February 2022

ocaml-devel@lists.fedoraproject.org

2 participants
6 discussions

OCaml spec file support macros
by Jerry James 30 Jun '22

30 Jun '22

Hi all, I've been experimenting with adding some macros to make OCaml packaging a bit easier. You can see what I have so far here: https://src.fedoraproject.org/fork/jjames/rpms/ocaml-srpm-macros/c/9554c809… With these macros, the main part of a spec file for a package that builds with dune can be as simple as this: ``` %build %dune_build %install %dune_install %check %dune_check %files -f .ofiles %doc README.md %license LICENSE.md %files devel -f .ofiles-devel ``` Packages that do not use dune to build can still use the %ocaml_files macro at the end of %install to generate .ofiles and .ofiles-devel files to pass to %files. New macros: - %ocamldir: shorter replacement for %{_libdir}/ocaml - %odoc_package: inspired by %javadoc_package, everything you need in one place to declare a package that contains odoc documentation. - %relink_stublibs: automatically locate any dll*.so files created by ocamlmklib and relink them with Fedora linker flags - %_add_release_func: internal macro to add `--release` to flags passed to %dune_build or %dune_check if neither `--release` nor `-p` has been given. I should probably rewrite it in lua. - %dune_build: invoke `dune build` with a standard set of flags, followed by %relink_stublibs. Arguments can be passed to dune, e.g., `%dune_build @install`. - %dune_check: invoke `dune runtest` with a standard set of flags. Arguments can be passed to dune, e.g., `%dune_check -p foobar`. - %ocaml_files: generate .ofiles* files to pass to %files from files installed in the buildroot. Use of this macro requires python3 to be installed in the chroot. By default, files are split into a main package (.ofiles) and a devel package (.ofiles-devel). Use `%ocaml_files -n` to ump all files together into .ofiles. Use `%ocaml_files -s` to generate files with the OCaml module name embedded in them; e.g., .ofiles-module1, .ofiles-module1-devel, .ofiles-module2, .ofiles-module2-devel, etc. - %dune_install: invoke `dune install` with a standard set of flags, then: - Remove any .dune-keep markers left over from running odoc - Remove anything installed into /usr/doc - Remove all *.ml files that have matching *.mli files installed - Invoke %ocaml_files, with the same -s or -n options passed to %dune_install itself I would appreciate any feedback you can offer. My questions: 1. Is ocaml-srpm-macros the best place for this? 2. Is the python dependency for %ocaml_files / %dune_install okay? I thought about writing it in lua to avoid the external dependency, but then the entire %install script has to be written in lua. If the entire %install script is just %dune_install, then that's okay, but it seems like a significant barrier otherwise. 3. Can you think of any other macros that would be useful? 4. I wonder if it would be useful to allow overrides for the logic used by %ocaml_files to split files into the main and devel packages. Perhaps something like this: -d file1,file2,...: comma-separated list of files to put in the devel package, even if they would normally go in the main package -m file1,file2,...: comma-separated list of files to put in the main package, even if they would normally go in the devel package Too bad for you if you want to do this to a file with a comma in its name. :-) Of course, one can always do surgery on the .ofiles* files after they are created, so maybe this would be overkill. I was working on making a bunch of spec files for everyone to look at when the package notes feature derailed me. Sigh. I'm going to get that cleaned up first, then I hope to get back to making examples. Regards, -- Jerry James http://www.jamezone.org/

4 9

Updating OCaml packages
by Jerry James 28 Feb '22

28 Feb '22

Hello OCaml packagers, I am going to update some packages in Rawhide today. Most of the Jane Street packages had releases of version 0.15.0 in late November, and we updated them in early December ... except that maybe they weren't really released. All of the 0.15.0 tags were moved to a later commit 2 weeks ago. I don't know what the story is, but there are code changes, so I'm going to update them to the current set of 0.15.0 tags. Other version updates: - coq 8.15.0 - flocq 3.4.3 - ocaml-gen 1.0 - ocaml-integers 0.6.0 - ocaml-menhir 20220210 - ocaml-mtime 1.4.0 - ocaml-qcheck 0.18.1 - ocaml-stdcompat 18 - ocaml-uutf 1.0.3 - why3 1.4.1 Also, I made a terrible, horrible, no good, very bad mistake with the last alt-ergo update. I uploaded the tarball for the version with a problematic license instead of the free version. I'm going to upload the correct tarball and rebuild. The following packages need rebuilds due to the above changes: - frama-c - gappalib-coq - ocaml-alcotest - ocaml-luv - ocaml-lwt - ocaml-markup - ocaml-ppxlib - ocaml-pyml - ocaml-sedlex - ocaml-tyxml - zenon I plan to repeat all of these builds for F36 if no problems arise in Rawhide. If you need to build any of these packages today, please build into the side tag: fedpkg build --target=f37-build-side-51187 Thanks, -- Jerry James http://www.jamezone.org/

1 1

Patch for ocamlmklib
by Jerry James 17 Feb '22

17 Feb '22

I would like to ask for your collective wisdom again. Upstream has provided OC_CFLAGS and OC_LDFLAGS as a way to set the default compiler and linker flags for ocamlopt. However, there is currently no way to set the default linker flags for ocamlmklib. Many OCaml stublibs in Fedora are therefore not linked with the Fedora hardening flags. I've done some hacky things in some packages to relink the stublibs with the correct flags, but it would be nice if ocamlmklib would use the right flags out of the box. I took a stab tonight at embedding OC_LDFLAGS in ocamlmklib. It doesn't seem very difficult. Would one or two of you mind looking at the attached patch and see what you think? If it looks good, I will try submitting it upstream. Thank you, -- Jerry James http://www.jamezone.org/

2 2

Re: Upstream Unison solved the OCaml compatibility architectural flaw?
by Richard W.M. Jones 17 Feb '22

17 Feb '22

On Wed, Feb 16, 2022 at 10:09:14PM -0500, Jeff F. wrote: > I don't know if that changes anything in your view, but it seems > that upstream has solved the OCaml dependency problem now (or at > least the three issues I could see pinned at the top of their bug > tracker), with this: https:// github.com/bcpierce00/unison/pull/626 > > In your opinion, does this solve the problem Fedora was facing in > terms of packaging/maintainability of Unison downstream, or is this > not sufficient and there is something more that needs to be fixed > (if so, what would it be)? It's certainly excellent news that Stephane has implemented this. It opens the way to reintroducing unison into Fedora, although I don't have the time to do it myself. Suggest joining fedora-ocaml-devel list & discussing there. https://lists.fedoraproject.org/archives/list/ocaml-devel@lists.fedoraproje… 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

1 0

rpmautospec breakage in Rawhide
by Jerry James 09 Feb '22

09 Feb '22

The last OCaml mass rebuild made incorrect changes to two spec files that use rpmautospec, namely ocaml-base64 and ocaml-opam-file-format. The Release field should be reverted to plain "%autorelease" and the changelog entry above "%autochangelog" removed. If nobody has time to deal with it before the mass rebuild starts, I can fix them. -- Jerry James http://www.jamezone.org/

2 6

Package notes
by Jerry James 04 Feb '22

04 Feb '22

I've been watching the action on these bugs since the new package notes facility broke frama-c: https://bugzilla.redhat.com/show_bug.cgi?id=2043092 https://bugzilla.redhat.com/show_bug.cgi?id=2044028 It just dawned on me that, due to this feature, when the mass rebuild packages are merged into Rawhide, we may end up with the entire OCaml ecosystem failing to build from source. The reason is that ocaml.spec bakes $RPM_LD_FLAGS into ocamlopt. Well, $RPM_LD_FLAGS now includes a path to a package-specific notes file, which means every ocaml-foo package that uses ocamlopt is going to get the path to the notes file for the ocaml package, which isn't going to exist. -- Jerry James http://www.jamezone.org/

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Ocaml-devel February 2022