Hello,

(This is the first time I file a transition bug, I hope I did everything
well)

falcosecurity-libs 0.23 was packaged with an ABI change without changing
the library's name.

I've fixed that in experimental.

The only reverse-deps are src:sysdig and src:wireshark which I locally
built and tested against this version, and everything works nicely.

I can provide you with the build logs if useful.

I'd like to integrate falcosecurity-libs into unstable and then get the
following packages binNMU-ed (packages in brackets are Arch:all and
probably do not need a binNMU?):

src:wireshark:
 [libwireshark-data]
 libwireshark-dev
 libwireshark19
 libwiretap-dev
 libwiretap16
 libwsutil-dev
 libwsutil17
 stratoshark
 tshark
 wireshark
 wireshark-common
 wireshark-dev
 [wireshark-doc]

src:sysdig:
 sysdig

Ben file:
https://release.debian.org/transitions/html/auto-falcosecurity-libs.html

title = "falcosecurity-libs";
is_affected = .depends ~ "libfalcosecurity0t64" | .depends ~ "libfalcosecurity0.23";
is_good = .depends ~ "libfalcosecurity0.23";
is_bad = .depends ~ "libfalcosecurity0t64";

Bests,

Hi,

Not sure if you all been following, but there was some activity on
falcosecurity-libs about this ABI change (#1147298) and there is now a
transition bug in place (#1150154). I'm CCing the bugs so people are
aware of this mailing list discussion.

Cheers,
Charles

Control: tags -1 confirmed

Go ahead.

(arch:all packages cannot be binNMUed, but they also do not need to be.
The arch:all packages do not depend on libfalcosecurity0t64.)

Cheers

Hi Sebastian,

Sebastian Ramacher <sramacher@debian.org> wrote on 06/10/2026 at 14:45:21+0200:

Thanks!

Uploaded to unstable right now.

Do I need to do anything additionally or is the binNMU in your scope?

Tell me how I can help if I can.

Bests,

We handle the binNMUs, no need to do anything wrt those. However, if build
issues or autopkgtest regressions arise, then we'll likely need you to take a
look. That doesn't seem to be the case so far though.

Cheers,
Emilio