On 17/07/2024 21:56, Adrian Bunk wrote:
On Wed, Jul 17, 2024 at 11:28:04AM +0200, Emilio Pozuelo Monfort wrote:
On 16/07/2024 13:16, Adrian Bunk wrote:
On Tue, Jul 16, 2024 at 10:25:43AM +0200, Stéphane Glondu wrote:
Hi,
Hi Stéphane,
Le 27/06/2024 à 11:38, Stéphane Glondu a écrit :
The remaining unknowns are llvm-toolchain-{14,15,16,17,18}... [...]
I've done a rebuild of the OCaml universe with yesterday's unstable
(mostly). The "missing" packages are the same, but the llvm-toolchain-16
build got far enough to FTBFS because of OCaml 5.2.0. This is likely to
affect llvm-toolchain-{14,15} as well, but might be fixed in newer versions.
I've reported bugs accordingly.
[...] Worst case scenario: the OCaml bindings can be disabled (they
don't have reverse dependencies in Debian).
I still think this is the best course of action.
looking at [1] this might be the only reasonable course of action for LLVM < 17.
Disabling them sounds fine (specially for 14 which is no longer in testing
and 15 which we're trying to get rid of), but ideally it can be done ahead
of the start in order to prevent delays with the transition.
Other than that, I'm happy with the current state and we could go ahead. So
if you can get those bindings disabled, then I think we can go ahead.
I tried looking at that, but this "ideally" is in level 15 of the ocaml
transition.
The bindings are already enabled only on some architectures, uploads to
disable them everywhere are trivial while it's a pain to test any changes
without the first 14 levels of the transition.
It would really be much easier to have the binNMUs scheduled and then
fix LLVM.
If by fixing you mean disabling the ocaml bindings, then I'm not sure why it
needs to happen after the binNMUs. If you mean actually fixing the bindings so
they work with the new ocaml, then sure, that's fine.
I see that autopkgtests are being run and some issues are being spotted. I'm
starting the gsl transition first, let's do this one after gsl (hopefully it
will be straightforward).
Cheers,
Emilio
