Hi release team!

I'd like to update Erlang for forky to new major release Erlang 29
which is already released upstream and is uploaded to experimental.

The current Erlang version in unstabl is 27, and as far as I know
there weren't any major breackages in Erlang 28 and 29, so for the
most packages it will be sufficient just to make binNMUs.

Currently, there are only 4 packages in unstable which FTBFS with Erlang
29:

elixir-lang (working version 1.19.5 is in experimental, thoug I think I'll wait
    until 1.20 is released upstream with official support for Erlang 29)
erlang-erlware-commons (patch is prepared)
erlang-erlydtl (patch is prepared)
erlang-jose (patch is prepared)

and one package which depends on Erlang implicitly via Elixir:

erlang-hex (updated version is in experimental)

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)

Cheers!

Ben file:

title = "erlang";
is_affected = .build-depends ~ /dh-rebar|erlang-dev|erlang-base|rebar|rebar3/;
is_good = .depends ~ /erlang-base (>= 1:29/;
is_bad = .depends ~ /erlang-base (>= 1:(1|2[0-8])/;

This is already ongoing, marking as such.

Are we ready for that binNMU round?

Cheers,
Emilio

Hi Emilio,

On Wed, Jun 17, 2026 at 12:32 PM Emilio Pozuelo Monfort <pochu@debian.org> wrote:

Thank you!

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.

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.

Apparently, ruby-bunny requires an update to work with the new
rabbitmq-server, but it currently suffers from a random FTBFS bug (see
[2]). Santiago did a good job of reporting the bug upstream and
preparing the patch. Hopefully, it'll be fixed soon.

[1] https://tracker.debian.org/pkg/rabbitmq-server
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1139980

Cheers!

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.

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

Hi Emilio,

I see. Then I'll prepare the list of binNMUs in a day or two.

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.
(it's picked up by
the "rebar" in build dependencies, but it's a different rebar). The
others look okay.

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!

Hi Emilio,

Here is the first portion of the list of binNMUs for Erlang-dependent packages.
For the others I'd like to wait until rebar is rebuilt and retested.
Some of the affected
packages are architecture all. I suppose I'd have to make source
uploads for them?

nmu elixir-earmark-parser . ANY . unstable . -m "Rebuild with Erlang
29, see #1138785"
nmu elixir-makeup . ANY . unstable . -m "Rebuild with Erlang 29, see #1138785"
nmu elixir-makeup-c . ANY . unstable . -m "Rebuild with Erlang 29, see #1138785"
nmu elixir-makeup-elixir . ANY . unstable . -m "Rebuild with Erlang
29, see #1138785"
nmu elixir-makeup-erlang . ANY . unstable . -m "Rebuild with Erlang
29, see #1138785"
nmu erlang-uuid . ANY . unstable . -m "Rebuild with Erlang 29, see #1138785"
nmu wings3d . ANY . unstable . -m "Rebuild with Erlang 29, see #1138785"
nmu rebar . ANY . unstable . -m "Rebuild with Erlang 29, see #1138785"

Cheers!

Yes, we cannot binNMU on all.

Scheduled

Cheers

Hi Sebastian,

The rest of binNMUs:

nmu elixir-nimble-parsec . ANY . unstable . -m "Rebuild with Erlang
29, see #1138785"
nmu erlang-asciideck . ANY . unstable . -m "Rebuild with Erlang 29,
see #1138785"
nmu erlang-base64url . ANY . unstable . -m "Rebuild with Erlang 29,
see #1138785"
nmu erlang-bbmustache . ANY . unstable . -m "Rebuild with Erlang 29,
see #1138785"
nmu erlang-cf . ANY . unstable . -m "Rebuild with Erlang 29, see #1138785"
nmu erlang-cl . ANY . unstable . -m "Rebuild with Erlang 29, see #1138785"
nmu erlang-cowlib . ANY . unstable . -m "Rebuild with Erlang 29, see #1138785"
nmu erlang-getopt . ANY . unstable . -m "Rebuild with Erlang 29, see #1138785"
nmu erlang-goldrush . ANY . unstable . -m "Rebuild with Erlang 29, see #1138785"
nmu erlang-horse . ANY . unstable . -m "Rebuild with Erlang 29, see #1138785"
nmu erlang-idna . ANY . unstable . -m "Rebuild with Erlang 29, see #1138785"
nmu erlang-jiffy . ANY . unstable . -m "Rebuild with Erlang 29, see #1138785"
nmu erlang-lager . ANY . unstable . -m "Rebuild with Erlang 29, see #1138785"
nmu erlang-luerl . ANY . unstable . -m "Rebuild with Erlang 29, see #1138785"
nmu erlang-metrics . ANY . unstable . -m "Rebuild with Erlang 29, see #1138785"
nmu erlang-mimerl . ANY . unstable . -m "Rebuild with Erlang 29, see #1138785"
nmu erlang-p1-acme . ANY . unstable . -m "Rebuild with Erlang 29, see #1138785"
nmu erlang-p1-cache-tab . ANY . unstable . -m "Rebuild with Erlang 29,
see #1138785"
nmu erlang-p1-eimp . ANY . unstable . -m "Rebuild with Erlang 29, see #1138785"
nmu erlang-p1-mqtree . ANY . unstable . -m "Rebuild with Erlang 29,
see #1138785"
nmu erlang-p1-mysql . ANY . unstable . -m "Rebuild with Erlang 29, see #1138785"
nmu erlang-p1-oauth2 . ANY . unstable . -m "Rebuild with Erlang 29,
see #1138785"
nmu erlang-p1-pam . ANY . unstable . -m "Rebuild with Erlang 29, see #1138785"
nmu erlang-p1-pgsql . ANY . unstable . -m "Rebuild with Erlang 29, see #1138785"
nmu erlang-p1-pkix . ANY . unstable . -m "Rebuild with Erlang 29, see #1138785"
nmu erlang-p1-sip . ANY . unstable . -m "Rebuild with Erlang 29, see #1138785"
nmu erlang-p1-sqlite3 . ANY . unstable . -m "Rebuild with Erlang 29,
see #1138785"
nmu erlang-p1-stringprep . ANY . unstable . -m "Rebuild with Erlang
29, see #1138785"
nmu erlang-p1-stun . ANY . unstable . -m "Rebuild with Erlang 29, see #1138785"
nmu erlang-p1-tls . ANY . unstable . -m "Rebuild with Erlang 29, see #1138785"
nmu erlang-p1-utils . ANY . unstable . -m "Rebuild with Erlang 29, see #1138785"
nmu erlang-p1-xml . ANY . unstable . -m "Rebuild with Erlang 29, see #1138785"
nmu erlang-p1-yaml . ANY . unstable . -m "Rebuild with Erlang 29, see #1138785"
nmu erlang-p1-yconf . ANY . unstable . -m "Rebuild with Erlang 29, see #1138785"
nmu erlang-p1-zlib . ANY . unstable . -m "Rebuild with Erlang 29, see #1138785"
nmu erlang-poolboy . ANY . unstable . -m "Rebuild with Erlang 29, see #1138785"
nmu erlang-proper . ANY . unstable . -m "Rebuild with Erlang 29, see #1138785"
nmu erlang-redis-client . ANY . unstable . -m "Rebuild with Erlang 29,
see #1138785"
nmu erlang-unicode-util-compat . ANY . unstable . -m "Rebuild with
Erlang 29, see #1138785"
nmu kamailio . ANY . unstable . -m "Rebuild with Erlang 29, see #1138785"
nmu ejabberd . ANY . unstable . -m "Rebuild with Erlang 29, see #1138785"
nmu ejabberd-contrib . ANY . unstable . -m "Rebuild with Erlang 29,
see #1138785"

Cheers!

Done

Cheers

And erlang has migrated. Let's close this.

Cheers,
Emilio

Really closing now.

Hi Emilio, Sebastian,

Thank you for the help! The transition is indeed complete now (if some
bugs will reveal themselves, we'll deal with them on an individual
basis).

Cheers!