On Tue, Nov 4, 2025, at 7:01 PM, Sebastian Ramacher wrote: > On 2025-11-04 18:08:16 +0100, Fabian Grünbichler wrote: >> 4) lack of tooling to analyze which packages need to be rebuilt >> >> for binNMUs in unstable, there is drt-tools[2] (which allows scheduling >> transition or ExtraSourceOnly related binNMUs, as well as built-by-maintainer >> ones via excuses). other similar workflows also have tools to assist with >> (re)building. TTBOMK, there is no such tooling for finding out which packages >> (potentially) need a rebuild because of an updated, statically linked >> package. >> >> I suspect this would not be too hard to write once S-B-U is finalized and has >> more adoption. it would also be nice for unstable binNMUs after non-security >> updates, although at least in the Rust part of the archive those happen >> regularly anyway, triggered by the toolchain's 6 week release cadence. > > drt-tools already supports S-B-U. For B-U we already track necessary > rebuilds for stable and oldstable at > resphighi.d.o:~sramacher/nmu-eso-stable and > resphighi.d.o:~sramacher/nmu-eso-oldstable. Starting to track rebuilds > required due to S-B-U would be easy enough.
very nice! I didn't look inside in detail, just went by the Readme ;) > There are however a few issues that I haven't had the time to work on to > get this fully ready. We currently run into issues with reused versions > as there is no easy/good way to track all used versions. So we had > binNMUs in stable where versions had been reused or which caused prop > ups. Once I have time to figre out how to compute unique binNMU versions > and schedule potentially necessary binNMUs in unstable at the same time, > we should be more close to an automatable solution. (see also [1]) that sounds solvable, although a bit involved/annoying > Also, drt-tools does not know about not released stable updates, so it > only check for necessary rebuilds once packages have been released to > stable-security or proposed-updates. so it is not directly usable in case of embargoed issues, but could maybe be adapted to do so if the corresponding infrastructure materializes, or by implementing a mode that basically does the "what-if" calculations without requiring the actual update to already exist.
