Ocaml-devel

ocaml-devel@lists.fedoraproject.org

1363 discussions

ocaml-cmdliner 1.1.x
by Jerry James 15 Sep '22

15 Sep '22

Hi all, I would like to update ocaml-alcotest to version 1.6.0, which adds support for OCaml 5.0. It needs an updated version of ocaml-cmdliner, though, namely version 1.1.0 or later. I propose to make the following changes: - ocaml-cmdliner: update to version 1.1.1, then: - ocaml-alcotest: update to version 1.6.0 - ocaml-bisect-ppx: simple rebuild - ocaml-fmt: simple rebuild - ocaml-logs: simple rebuild - ocaml-mdx: add upstream patch (not yet in any released version) - ocaml-ocp-indent: simple rebuild with unrelated bug fixes - ocaml-odoc: simple rebuild - ocaml-uutf: add upstream patch to avoid deprecated interfaces - opam: simple rebuild, with small BR and R adjustments This COPR has all of the builds I have in mind: https://copr.fedorainfracloud.org/coprs/jjames/Cmdliner1.1.1/. I am primary maintainer of all of these packages except for ocaml-cmdliner and opam. If the maintainers of those packages don't object, I would like to proceed with these updates. Regards, -- Jerry James http://www.jamezone.org/

1 0

OCaml 5.0.0 alpha 1 scratch build
by Richard W.M. Jones 06 Sep '22

06 Sep '22

For my sins I'm doing a scratch build of OCaml 5.0.0 alpha 1 here: https://koji.fedoraproject.org/koji/taskinfo?taskID=91701007 Looking at this there are quite a few larger changes in packaging: - It seems as if this generates META files for stdlib libraries, whereas previously those were generated by ocaml-findlib. (This is a more sensible way to do things, but still a large packaging change from our point of view.) - It puts libraries like dynlink, unix etc into subdirectories, previously only threads was in a subdirectory. - Various extra unexpected files are packaged. See diff attached. I'm expecting this will break a lot of things. 5.0.0 also includes multicore support, and is not fully backwards compatible with all C extensions. I believe the main change will be for extensions which are relying on converting raw C pointers to OCaml pointers without wrapping/hiding them in a Custom value. An example of the deprecated behaviour is in ocaml-ancient which is a package I will likely drop. Some other useful links: https://discuss.ocaml.org/t/ocaml-5-0-first-normal-alpha-release/10216 https://github.com/ocaml/opam-repository/issues/21526 https://github.com/ocaml/ocaml/blob/5.0/Changes 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

2 1

ocaml-ppxlib upgrade
by Jerry James 09 Aug '22

09 Aug '22

Greetings, OCaml packagers! I would like to update ocaml-ppxlib to version 0.27.0 for several bug fixes in that release. However, it comes with some API changes, which means that all consuming packages have to be rebuilt. I have done local mock builds to check for problems. I checked for newer versions of each package that had to be rebuilt as I went. This is the list of packages I propose to touch. Packages to upgrade: - ocaml-curl 0.9.2 - ocaml-lambda-term 3.2.0 (we can't upgrade to 3.3.x yet) - ocaml-lwt 5.6.1 - ocaml-ounit 2.2.6 - ocaml-ppxlib 0.27.0 - ocaml-sedlex 3.0 Packages with nontrivial spec file changes (but same version): - ocaml-csv - ocaml-lwt-log - ocaml-ppx-deriving-yojson Simple rebuilds: - flocq - frama-c - gappalib-coq - haxe - ocaml-bin-prot - ocaml-bisect-ppx - ocaml-logs - ocaml-markup - ocaml-menhir - ocaml-ppx-assert - ocaml-ppx-base - ocaml-ppx-cold - ocaml-ppx-compare - ocaml-ppx-custom-printf - ocaml-ppx-deriving - ocaml-ppx-enumerate - ocaml-ppx-expect - ocaml-ppx-fields-conv - ocaml-ppx-hash - ocaml-ppx-here - ocaml-ppx-import - ocaml-ppx-inline-test - ocaml-ppx-js-style - ocaml-ppx-let - ocaml-ppx-optcomp - ocaml-ppx-sexp-conv - ocaml-ppx-variants-conv - ocaml-time-now - ocaml-tyxml - ocaml-zmq - utop - why3 - zenon I will file PRs for packages in the first 2 groups so package maintainers can see what I have in mind. Once the PRs have all been merged, I will take care of doing the rebuilds. Let me know if you have any concerns. -- Jerry James http://www.jamezone.org/

1 0

camlp-streams package review
by Jerry James 05 Jul '22

05 Jul '22

Hi all, Richard mentioned some packages warning that they need to migrate to camlp-streams. I've been looking at the ocaml-atd FTBFS (https://bugzilla.redhat.com/show_bug.cgi?id=2098760) and it appears to me that camlp-streams is required to fix that. So here is a review request for ocaml-camlp-streams: https://bugzilla.redhat.com/show_bug.cgi?id=2104283 Does anyone have time for a review? -- Jerry James http://www.jamezone.org/

1 0

ocaml dune 3
by Richard W.M. Jones 05 Jul '22

05 Jul '22

Annoyingly now that I've done the OCaml rebuild, I discovered that the version of Dune that we're shipping is quite old. Fedora Rawhide ships 2.9.3, latest upstream is 3.3.1. https://bugzilla.redhat.com/show_bug.cgi?id=2002676 This wouldn't necessarily matter, but I found a new package that depends on 3.x: https://bugzilla.redhat.com/show_bug.cgi?id=2099754 Well, it _may_ work with 2.9 (after hacking the dune-project file) but it fails a bit later because of some missing dependencies so I'm not entirely sure. Anyhow, I wonder if there's a reason why we're sticking with dune 2.9, or if I can upgrade it? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html

3 5

odoc
by Jerry James 30 Jun '22

30 Jun '22

Back when I started working on packaging the dependencies of odoc, I had a vision of a tree of nicely cross-referenced documentation for Fedora OCaml packages. That vision has not come to pass, and probably never will. To achieve it, we would have to do bootstrap builds of all packages in the odoc dependency tree, then start the builds over again with documentation included. That would be a big hassle. Most of the documentation is online anyway, and OCaml developers will probably use opam to generate a tree of nicely cross-linked documentation, so the payoff for doing that extra work would be small. As a result, I propose that going forward we remove odoc from the BuildRequires of OCaml packages and consequently stop building the documentation. Does anybody object? -- Jerry James http://www.jamezone.org/

3 3

Re: Package proposal: google-drive-ocamlfuse
by Dan Čermák 30 Jun '22

30 Jun '22

Marián Konček <mkoncek(a)redhat.com> writes: > I recently discovered this project: > https://github.com/astrada/google-drive-ocamlfuse > > Supposedly it makes it possible to mount google drive as a filesystem > using fuse. > > I wanted to try to package it myself, but ocaml seems a bit esoteric and > we are currently missing at least 5 dependencies in Fedora. > > Nevertheless I think this package would be useful for many people. > > Would anyone (perhaps someone who maintains other ocaml packages) be > willing to package this? The problem with this is, that the most active OCaml packagers are Rich Jones and Jerry James, who already have a ton of packages on their plate. Unless they have a specific use for this tool, I wouldn't shove it on theirs (unless they want of course ;-) ). I have a different proposal though: I have a little bit of experience with OCaml packaging and some time this week, so if you want, I can try to guide you through OCaml packaging. Cheers, Dan

3 2

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

OCaml 4.14
by Richard W.M. Jones 22 Jun '22

22 Jun '22

Been a bit busy of late (writing OCaml code though ..), but as you can see there's a new OCaml compiler out, 4.14.0: https://ocaml.org/releases/4.14.0.html I intend to update to this in the next few days, only in Rawhide. But before that are there any other OCaml packages that you think should be updated first? 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

2 8

New OCaml macros
by Jerry James 18 Mar '22

18 Mar '22

Hello OCaml packagers! There is now a COPR repo showing off what the new OCaml macros can do: https://copr.fedorainfracloud.org/coprs/jjames/Infer/ Yes, that's the same COPR repo I just mentioned on fedora-devel-list. I'm interested in feedback. Things to note: 1. I basically did a full review on each package. This has taken a few months. In the process, I have identified lots of incorrect License tags and found other ways the spec files could be improved or simplified. If your OCaml package isn't in the COPR repo, that means I didn't see anything in the spec file that ought to be changed. 2. I've abandoned the use of odoc to build documentation. Richard Jones pointed out that odoc has been a big source of dependency loops, for one thing. For another, we can't really take advantage of odoc's crosslinking capabilities without doing bootstrap builds for dozens of packages until we can build odoc, then building everything a second time to generate the documentation. Finally, the documentation is generally available online anyway. Does anybody object to discarding the odoc-generated documentation? 3. I've moved away from using %srcname or %libname macros. As Miro has been pointing out on fedora-devel-list for some time, those macros seem to obscure more than they help. 4. If you want to see how all of these OCaml packages are related to each other, take a look at one of these: https://jamezone.org/pleasure/software/Fedora/infer.dot https://jamezone.org/pleasure/software/Fedora/infer.pdf This graph shows the "build before" order. That is, if there is an arrow from A to B, then A must be built before B. Legend: Black node: package is in Fedora Green node: package has been submitted for review Red node: package is not in Fedora Solid black line: Mandatory build requirement Dashed black line: Optional build requirement Solid blue line: Test requirement Solid green line: Documentation requirement 5. Packages that are no longer used after the changes in the repo are made. We can retire these unless someone has another need for them: - ocaml-migrate-parsetree - ocaml-seq - ocaml-uuidm 6. Many leaf packages contain useful binaries in their own right, or are used by non-OCaml parts of Fedora. These are the leaf packages whose usefulness is unknown to me. If nobody is actively using these, we can think about retiring them: - ocaml-ancient - ocaml-augeas - ocaml-calendar - ocaml-camlimages - ocaml-cil - ocaml-csv - ocaml-curl - ocaml-curses - ocaml-dbus - ocaml-expat - ocaml-facile - ocaml-gsl - ocaml-lacaml - ocaml-mysql - ocaml-newt - ocaml-obuild - ocaml-omake - ocaml-perl4caml - ocaml-postgresql - ocaml-res - ocaml-SDL, and ocaml-lablgl too - ocaml-ssl - ocaml-xmlrpc-light - ocamlify - ocamlmod If this looks good, then I will start making pull requests, starting from the top of that graph in #4 and work my way downward. Be warned that some of the proposed changes require coordination between multiple packages. Regards, -- Jerry James http://www.jamezone.org/

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Ocaml-devel