Packages algaeff.2.0.0, asai.0.3.0 and yuujinchou.5.2.0

[favonia]

This pull-request concerns:

• algaeff.2.0.0: Reusable Effects-Based Components
• asai.0.3.0: A library for constructing and printing compiler diagnostics
• yuujinchou.5.2.0: A library for hierarchical names and lexical scoping

---

---

🐫 Pull-request generated by opam-publish v2.2.0

[favonia]

Dear OPAM repository maintainers,

This is my first time dealing with revdep failures due to breaking changes. The culprit is algaeff 2.0.0. Should I manually add upper bounds in the OPAM files of all broken packages? We coordinated the releases so that the latest versions will build, but we were not sure what to do with older versions that no longer build. Please kindly advise. Thanks!

[avsm]

Thanks @favonia. If you could push upper bounds to broken packages in this PR, that would be helpful. It maintains the invariant that older packages will not break with the new release, and that newer users can pick up the latest releases if they do not have any constraints. Once there's a set of upper bounds pushed for older packages (either in this PR, or separately -- entirely up to you), this is good to merge.

[favonia]

Hi, there was some issue when building forester 2.1 with lower-bounds. I'm not sure how to fix it, and I noticed that its lower-bound test was already failing when it was released (#23855). Maybe we should investigate it in another PR because it seems independent of what's in this PR?

PS: in addition to adding upper bounds, I also fixed yuujinchou 3.0.0 (bwd >= 2.0) and partially forester 2.1 (domainslib >= 0.5.0). Not sure how yuujinchou 3.0.0 passed the build. For forester, I saw one error that indicated it requires a (breaking) change introduced by domainslib 0.5.0, so I just added the lower bound. However, I could not immediately see how to fix the other error.

Perhaps I should tag @jonsterling here...

[jonsterling]

I'm also a bit baffled by this situation, but I have to admit I am not well-versed in the packaging conventions. Can an expert please help us figure out what we need to do in order to maintain the integrity of the opam repository while making this joint release?

[mseri]

Thanks for the upper bounds. The failure in the previous release was different. Let me see if I can understand what makes it fail now:

#=== ERROR while compiling forester.2.1 =======================================#
# context              2.2.0~alpha3~dev | linux/x86_64 | ocaml-base-compiler.5.1.0 | pinned(https://github.com/jonsterling/ocaml-forester/archive/refs/tags/2.1.tar.gz)
# path                 ~/.opam/5.1/.opam-switch/build/forester.2.1
# command              ~/.opam/opam-init/hooks/sandbox.sh build dune build -p forester -j 31 @install
# exit-code            1
# env-file             ~/.opam/log/forester-7-9ea015.env
# output-file          ~/.opam/log/forester-7-9ea015.out
### output ###
# (cd _build/default && /home/opam/.opam/5.1/bin/ocamlc.opt -w -40 -g -bin-annot -I lib/frontend/.Forester.objs/byte -I /home/opam/.opam/5.1/lib/algaeff -I /home/opam/.opam/5.1/lib/bwd -I /home/opam/.opam/5.1/lib/domainslib -I /home/opam/.opam/5.1/lib/lockfree -I /home/opam/.opam/5.1/lib/ocaml/str -I /home/opam/.opam/5.1/lib/ocaml/unix -I /home/opam/.opam/5.1/lib/ocamlgraph -I /home/opam/.opam/5.1/lib/ppx_deriving/runtime -I /home/opam/.opam/5.1/lib/result -I /home/opam/.opam/5.1/lib/stdlib-shims -I /home/opam/.opam/5.1/lib/xmlm -I /home/opam/.opam/5.1/lib/yuujinchou -I lib/core/.Core.objs/byte -I lib/prelude/.Prelude.objs/byte -I lib/render/.Render.objs/byte -no-alias-deps -open Forester -o lib/frontend/.Forester.objs/byte/forester__Parser.cmi -c -intf lib/frontend/Parser.pp.mli)
# File "lib/frontend/Parser.mli", line 46, characters 56-64:
# 46 | val main: (Lexing.lexbuf -> token) -> Lexing.lexbuf -> (Code.doc)
#                                                              ^^^^^^^^
# Error: Unbound module Code

[favonia]

I saw a strange error in freebsd,freebsd-ocaml-4.14-amd64,asai.0.2.0,tests and will rerun the job. However, I think the error message is something ocaml-ci (or whatever running it) can work on so I'm posting it here:

/usr/home/opam: (run (cache (opam-archives (target /usr/home/opam/.opam/download-cache)))
                     (network host)
                     (shell  "opam reinstall asai.0.2.0;\
                            \n        res=$?;\
                            \n        test \"$res\" != 31 && exit \"$res\";\
                            \n        export OPAMCLI=2.0;\
                            \n        build_dir=$(opam var prefix)/.opam-switch/build;\
                            \n        failed=$(ls \"$build_dir\");\
                            \n        partial_fails=\"\";\
                            \n        for pkg in $failed; do\
                            \n          if opam show -f x-ci-accept-failures: \"$pkg\" | grep -qF \"\\\"freebsd\\\"\"; then\
                            \n            echo \"A package failed and has been disabled for CI using the 'x-ci-accept-failures' field.\";\
                            \n          fi;\
                            \n          test \"$pkg\" != 'asai.0.2.0' && partial_fails=\"$partial_fails $pkg\";\
                            \n        done;\
                            \n        test \"${partial_fails}\" != \"\" && echo \"opam-repo-ci detected dependencies failing: ${partial_fails}\";\
                            \n        exit 1"))
Uncaught exception: Unix.Unix_error(Unix.ENOTTY, "clear_nonblock", "")
2023-11-06 21:59.06: Job failed: Failed: Internal error

[favonia]

@mseri I'm very impressed by how you could find a lower bound to fix forester. Would you mind sharing your tips?

[favonia]

Now Open-CI is in a weird state. freebsd,freebsd-ocaml-4.14-amd64,asai.0.2.0,tests actually should not be run at all, because asai 0.2.0 was not compatible with OCaml 4.14, and yet there was a failing job. In an attempt to fix it, I clicked on "Rebuild failed", and that failing job "disappeared", but the summary still does not show "passed".

[mseri]

Hi. So for the freebsd error, indeed it was a CI failure (maybe out of memory or something of the likes), it would have not been a problem for the merge. Similarly, it shows failed because the machine testing ocaml 4.06 is stuck on some other job and not responding, not a problem for the PR as well.

As per the lower bounds. This is tricky. I would say that it is a mix of luck and experience. Looking at the failure, it happened in a part of code generated by menhir, since there was no bound on menhir I went to look at dune and menhir docs and there was a mention of introducing the new menhir mode in dune in that release. In the sources, forester was using that mode, so I tried

[mseri]

Thanks, this is good to merge

[jonsterling]

Thanks @mseri very much for your triage!