Hi all, Sebastian kindly helped me better understand the release team side of this on #debian-release.
On Sat, Mar 21, 2026 at 08:46:56PM +0100, Helmut Grohne wrote: > So while this is an ABI break, it only affects suricata on riscv64 in > Debian. It may break stuff outside Debian, but any binary that we'd > break would also be broken on Fedora. Thus I propose a binNMU of > suricata followed by an upload of libunwind that Breaks: suricata > (<< 1:8.0.4-1+b1) [riscv64]. > > I intend to NMU libunwind to add these breaks if you agree and schedule > the binNMU. Doing this should finally migrate a significant chunk of > packages to forky.. If the binNMU were to be scheduled, suricata would migrate and then libunwind would migrate. The missing Breaks would not prevent migration. Therefore, libunwind should be NMUed before suricata is binNMUed. In particular, the projected approach is acceptable to the release team. So I did NMU libunwind another time and the migration page looks sensible now. Migration would now render suricata uninstallable. Please proceed with the binNMU and resolve this long matter. For reference: * libunwind cannot migrate before suricata is binNMUed. * Once libunwind migrates, python-memray's autopkgtest passes. * python-asv-bench-memray and sphinx-needs are blocked on python-memray. * doxysphinx and sphinx-data-viewer are blocked on sphinx-needs. * hipblas, hipblaslt, hipfft, hipsparse, miopen, rocblas, rocfft, rocm-docs-core, rocrand, rocsolver, and rocsparse are blocked on doxysphinx. * From there there are at least three more dependency layers. Helmut
