email> 
 18:36:11 
 tests= 
 001, 
 domain: . 
 fedrtdeggddukedujedvucetufdo 
 rihhlpdfurfetoffkrfgpnffqhge 
 ffhffvkfgjfhfutgfgsehtqhertd 
  
 From: debian@fabian.gruenbichler.email 
  
 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. 
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2)