Bug#1136715: Please update ben for release.debian.org
Le 16/07/2026 à 16:07, Stéphane Glondu a écrit : 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? Hmm, you mentioned that already, it's not. I could make a backport of 1.22 for trixie by reverting a single commit. Should be available soon. 1.22~bpo13+1 has just been accepted. Cheers, -- Stéphane
Bug#1136715: Please update ben for release.debian.org
Hi, Le 16/07/2026 à 12:12, Paul Gevers a écrit : 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? Hmm, you mentioned that already, it's not. I could make a backport of 1.22 for trixie by reverting a single commit. Should be available soon. Cheers, -- Stéphane
Bug#1136715: Please update ben for release.debian.org
Hi, On 16-07-2026 12:04, Paul Gevers wrote: Hi, On 23-05-2026 07:51, Stéphane Glondu wrote: One can argue it fixes a bug, so maybe it could qualify for an oldstable update? 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? 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 OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1136715: Please update ben for release.debian.org
Hi, On 23-05-2026 07:51, Stéphane Glondu wrote: One can argue it fixes a bug, so maybe it could qualify for an oldstable update? 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 OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1136715: Please update ben for release.debian.org
On Fri, 15 May 2026 07:02:37 +0200 =?utf-8?q?St=C3=A9phane_Glondu?= < [email protected]> wrote: > Package: release.debian.org > Severity: important > > 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
Bug#1136715: Please update ben for release.debian.org
Le 21/05/2026 à 13:12, Stéphane Glondu a écrit : 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. One can argue it fixes a bug, so maybe it could qualify for an oldstable update? FYI, I've attached a debdiff. Cheers, -- Stéphanediff -Nru ben-0.10.1/debian/changelog ben-0.10.1+deb12u1/debian/changelog --- ben-0.10.1/debian/changelog 2023-01-23 07:36:52.0 +0100 +++ ben-0.10.1+deb12u1/debian/changelog 2026-05-14 10:32:33.0 +0200 @@ -1,3 +1,11 @@ +ben (0.10.1+deb12u1) bookworm; urgency=medium + + * Backport changes from sid: +- Evaluate build-dependencies as on buildds +- Fix parsing of multiarch qualifiers in dependencies + + -- Stéphane Glondu Thu, 14 May 2026 10:32:33 +0200 + ben (0.10.1) unstable; urgency=medium [ Stéphane Glondu ] diff -Nru ben-0.10.1/.gitignore ben-0.10.1+deb12u1/.gitignore --- ben-0.10.1/.gitignore 2023-01-23 07:36:52.0 +0100 +++ ben-0.10.1+deb12u1/.gitignore 1970-01-01 01:00:00.0 +0100 @@ -1,6 +0,0 @@ -_build -ben -*~ -modules.png -doc/ben.1 -doc/refman.html diff -Nru ben-0.10.1/lib/package.ml ben-0.10.1+deb12u1/lib/package.ml --- ben-0.10.1/lib/package.ml 2023-01-23 07:36:52.0 +0100 +++ ben-0.10.1+deb12u1/lib/package.ml 2026-05-14 10:32:33.0 +0200 @@ -110,12 +110,39 @@ add key (f previous) t end +let eval_conjunction xs = List.for_all (String.starts_with ~prefix:"!") xs +let eval_disjunction xs = List.exists eval_conjunction xs + let get_and_split = - let rex = Re.Pcre.regexp "(?:[, |]|\\([^)]+\\))+" in + let open Re.Pcre in + let rex_split_pkg = regexp ",\\s*" in + let rex_split_alt = regexp "\\s*\\|\\s*" in + let rex_match_pkg = regexp "^([^ :]+)(?::\\S+)?(?:\\s+(.*))?$" in + let rex_match_profile = regexp "<([^>]+)>" in + let rex_split_spaces = regexp "\\s+" in fun field x -> try - let deps = get field x in - Re.Pcre.split ~rex deps + get field x |> split ~rex:rex_split_pkg + |> List.map (fun x -> + match split ~rex:rex_split_alt x with x :: _ -> x | _ -> x) + |> List.filter_map (fun x -> + match exec ~rex:rex_match_pkg x with + | exception Not_found -> None + | g -> + Some +(get_substring g 1, try get_substring g 2 with Not_found -> "")) + |> List.filter_map (fun (pkg, extra) -> + if +Re.all rex_match_profile extra +|> List.map (fun g -> +Re.Group.get g 1 |> split ~rex:rex_split_spaces) +|> fun xs -> +if xs = [] then true +else + (* we evaluate the build profile restriction formula with no profiles *) + eval_disjunction xs + then Some pkg + else None) with Not_found -> [] let build_depends x =
Bug#1136715: Please update ben for release.debian.org
Le 21/05/2026 à 11:59, Paul Gevers a écrit : Le 15/05/2026 à 07:02, Stéphane Glondu a écrit : 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/ I've just uploaded ben 1.21 to unstable, and also compiled it in the repo above. 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? 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. The following works on respighi: - extract (with dpkg -x) ben and libben-ocaml into ~/ben I prefer we don't need to this (although not sure what others think). 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, -- Stéphane
Bug#1136715: Please update ben for release.debian.org
Hi Stéphane, On 5/21/26 11:20, Stéphane Glondu wrote: Le 15/05/2026 à 07:02, Stéphane Glondu a écrit : 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/ I've just uploaded ben 1.21 to unstable, and also compiled it in the repo above. 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? The following works on respighi: - extract (with dpkg -x) ben and libben-ocaml into ~/ben I prefer we don't need to this (although not sure what others think). Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1136715: Please update ben for release.debian.org
Hi, Le 15/05/2026 à 07:02, Stéphane Glondu a écrit : 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/ I've just uploaded ben 1.21 to unstable, and also compiled it in the 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, -- Stéphane
Bug#1136715: Please update ben for release.debian.org
Package: release.debian.org
Severity: important
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,
--
Stéphane
