Dear Release Team,


Until ben 1.17, build profiles were completely ignored by "ben
monitor" (which generates transition tracker pages) when computing
dependency levels.

In dh-ocaml 3.0, I introduced a build profile (pkg.dh-ocaml.bootstrap)
that has build-dependency cycles and cannot be built when
bootstrapping or doing an OCaml transition. It should never be used on
buildds. It should not be taken into account in monitor. However it
currently is, and as a consequence 13 levels (or so) of the OCaml
permanent tracker page are collapsed into 1.

In ben 1.18, I decided to evaluate build-dependencies as on buildds:
take first alternative of disjunctions, and assume no build
profiles. This introduced a regression with multiarch specifiers,
which I fixed in ben 1.19.


AFAIU, transition tracking pages are genenerated on respighi which
still runs bookworm and ben 0.10.1. The latest versions of ben do not
compile as-is on bookworm because of toolchain changes.

Therefore, I recompiled the OCaml world from sid (albeit with OCaml
5.4.1) on bookworm (enough to compile ben):

https://ocaml.debian.net/backports/20260514/

Trying the resulting ben on respighi, I faced a regression with
projectb import, which I fixed in ben 1.20. The resulting binaries can
be found in:

https://ocaml.debian.net/backports/20260514/repo/pool/ben/

On respighi, one can take only:

 - /usr/bin/ben
 - /usr/lib/x86_64-linux-gnu/ocaml/5.4.1/ben/templates/debianrt

from ben_*.deb above, and run ben with BEN_TEMPLATES_DIR appropriately
set. (I do not recommend directly installing packages from the
repository above on respighi.)


Alternatively, I backported the changes from ben 1.18 and 1.19 into a
"bookworm" branch in ben:

https://salsa.debian.org/debian/ben/-/commits/bookworm

It compiles on bookworm, and the resulting package should be directly
(system-)installable on respighi...but is based on the old 0.10.1
version. My recommendation would be using a non-system install of
1.20 instead, as explained above.


Other changes in 0.10.1..1.20 that might be of interest for the
Release Team include:

From version 1.5:
 - Add build-{status,architecture} pseudo-headers (Closes: #763462)

From version 1.15:
 - Add an option to ignore build-depends-indep (Closes: #1122238)


Would you consider updating ben in the release.debian.org setup?


Cheers,

Hi,

Le 15/05/2026 à 07:02, Stéphane Glondu a écrit :
repo above.

The following works on respighi:
- extract (with dpkg -x) ben and libben-ocaml into ~/ben
- copy /srv/release.debian.org/www/transitions into ~/tmp/transitions
- adjust paths in Makefile and conf to use ~/ben/usr/bin/ben and
~/tmp/transitions (in actual production, one would just have to change
the path to ben)
- for the test, I kept only permanent trackers and amd64
- "make cron"

You can compare:

https://release.debian.org/transitions/html/ocaml.html

with:

https://ocaml.debian.net/ben/ocaml.html

(the latter is not updated frequently)


Cheers,

Hi Stéphane,


Can you maybe upload it to oldstable-backports-sloppy (and in
preparation for future upgrades of respighi to stable-backports) once it
migrate to enable us to just ask DSA to install it from there?


I prefer we don't need to this (although not sure what others think).

Paul

Le 21/05/2026 à 11:59, Paul Gevers a écrit :

As said in my initial report, the toolchain and/or library stack changed
too much for unstable's ben to be built in bookworm (or trixie). It is
just easier for me to rebuild unstable's OCaml world in $ANY_SUITE. Due
to the static nature of OCaml linking, executables usually don't need
OCaml runtime libraries on so-called "native" architectures (which amd64
is). (Ben is peculiar as it uses plugins as "templates".)

Nonetheless, the changes that scratch my present itch are
cherry-pickable into bookworm's version:

https://salsa.debian.org/debian/ben/-/tree/bookworm

and are already in testing (version 1.20), one can just build it with
sbuild in a bookworm chroot... but I'm afraid this doesn't qualify for
an official backport, as it's a version that never existed anywhere.

I understand your reluctance, but this is the simplest I could find to
have latest ben in production, which is in principle a good idea (IMHO).
 From comments in Makefile, this has already be done in the past.
Moreover, maybe this could motivate people to work more on the
tracker/monitor part of ben if they could see the effect quickly on the
release.debian.org website.


Cheers,

Le 21/05/2026 à 13:12, Stéphane Glondu a écrit :

One can argue it fixes a bug, so maybe it could qualify for an oldstable
update?

FYI, I've attached a debdiff.


Cheers,

Hi,


With oldstable no longer supported by the release and security teams I
have asked DSA (via adsb) whether respighi can/should be upgraded. Once
that happens, is a proper backport for trixie an option again?

Paul

Hi,


Hmm, you mentioned that already, it's not. If we would upgrade to
trixie, would it break again if I'd now take the binaries you targeted
for bookworm?

Paul

Hi,

Le 16/07/2026 à 12:12, Paul Gevers a écrit :

I could make a backport of 1.22 for trixie by reverting a single commit.
Should be available soon.


Cheers,

Le 16/07/2026 à 16:07, Stéphane Glondu a écrit :

1.22~bpo13+1 has just been accepted.


Cheers,