Hi Emilio, On Wed, Jun 17, 2026 at 3:09 PM Emilio Pozuelo Monfort <[email protected]> wrote: > > On 17/06/2026 11:54, Sergei Golovan wrote: > > Hi Emilio, > > > > On Wed, Jun 17, 2026 at 12:32 PM Emilio Pozuelo Monfort > >> > >> Are we ready for that binNMU round? > > > > Do I understand correctly, that binNMU just replaces the existing > > package, so if there is the same version in testing and in unstable > > then the binNMUd version immediately becomes available in testing and > > in unstable? If it is so, then I'd wait until erlang 29 with a few > > packages (elixir, elixir-ex-doc) enter testing. If binNMUs are treated > > as new versions with their own migration schedule, then I'll prepare > > the list of binNMUs shortly. > > binNMUs are new binary versions in sid, with the previous one in testing/sid > still available. Then binNMUs have their own migration excuses, per > architecture, and britney won't migrate them until they are ready (e.g. their > dependencies are satisfied, the rest of the checks pass...).
I see. Then I'll prepare the list of binNMUs in a day or two. > > I don't think erlang can migrate to testing until everything is ready and the > binNMUs have been done, since only one version of erlang-base can exist in > testing, and the new version can't migrate until all the rdeps are also > updated > (in lockstep) to depend on the new provided ABI. Formally, software built with Erlang 27 should be able to work if run using the Erlang 29 runtime. There are some issues with individual modules though. Specifically, in Erlang 28/29 the new regex engine is used, so any package that uses the re module has to be rebuilt. Though it's better to rebuild everything just to be sure they will not break in some other way. > > The list of binNMUs is most likely the red packages in [1], minus some > packages > which may fail to build and would require changes, and thus sourceful uploads. > In any case, it's not a big deal if we schedule those too, and the remaining > red > packages will be the ones needing source changes. I can collect and schedule > those if it sounds good. There is at least one false positive in the list in [1]: laniakea (it's picked up by the "rebar" in build dependencies, but it's a different rebar). The others look okay. > > > As for now, I've uploaded erlang, elixir-lang, and a few packages that > > need updating/patching (tsung, erlang-hex, erlang-erware-commons, > > elixir-ex-doc). > > > > Also, the maintainer of rabbitmq-server has updated it as well. > > > > So, there are several new packages in unstable. They are still not in > > testing either because of their age, or because of some issues with > > reverse dependencies. In particular: > > > > autopkgtests triggered by rabbitmq-server (see [1]) fail because they > > are trying to run the new rabbitmq-server (built with erlang 29) with > > erlang 27. I think that simultaneous migration of erlang 29 and > > rabbitmq-server should be fine, but I didn't find corresponding > > autopkgtest logs to confirm. Manually executed autopkgtests do not > > fail for me. > > The issue is that testing's rabbitmq-server doesn't require erlang 27, it just > depends on erlang >= 27. It doesn't depend on erlang-abi (= 27), so > theoretically it could run with erlang 29. That's why the migration software > is > checking if it works, because in a theoretical world, erlang 29 could migrate > to > testing while rabbitmq-server stays at the old version. We can probably do > some > magic here to smooth this out. Paul, can you help with this? I've filed a bugreport [2] (and the rabbitmq-server's maintainer already switched the bug status to pending) which ensures the runtime dependencies to be consistent with the erlang version the package is built with. [1] https://release.debian.org/transitions/html/erlang-29.html [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1140214 Cheers! -- Sergei Golovan
