On 17/06/2026 11:54, Sergei Golovan wrote:
Hi Emilio,
On Wed, Jun 17, 2026 at 12:32 PM Emilio Pozuelo Monfort
<[email protected]> wrote:
Control: tags -1 confirmed
This is already ongoing, marking as such.
Thank you!
On 03/06/2026 19:37, Sergei Golovan wrote:
Now, I'm planning to:
1. send bugreports to the packages which FTBFS with severity normal;
2. upload Erlang 29 and Elixir to unstable right after Elixir 1.20 is
released
3. bump severity of FTBFS bugs to serious;
4. make binNMUS for all affected packages (there are 66 of them, two of
which aren't in testing)
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 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.
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.
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?
Cheers,
Emilio
