email> 
 06:42:12 
 tests= 
 FOURLA= 
 autolearn_ 
 2025 
 fedrtdeggddukeefudeiucetufdo 
 rihhlpdfurfetoffkrfgpnffqhge 
 gvnhhtshculddquddttddmnecujf 
  
 From: debian@fabian.gruenbichler.email 
  
 On Tue, Nov 4, 2025, at 7:53 PM, Adrian Bunk wrote: 
 > On Tue, Nov 04, 2025 at 06:08:16PM +0100, Fabian Grünbichler wrote: 
 > [..] 
 > 
 >> - there is no support for building sets of interdependent uploads without 
 >>   releasing them (which would be required for embargoed issues to first 
 upload 
 >>   a fixed crate package, then rebuild everything linking it, then release 
 all 
 >>   the packages together) 
 >> 
 >> this part is probably only solvable by or with involvement of the 
 security team 
 >> and DSA, for obvious reasons. 
 > 
 > I would treat this as a bonus feature, not a mandatory one, 
 > since it is not strictly necessary and not easy to implement. 
  
 sure, it is in the "nice to have" category rather than the "absolute 
 blocker" 
 one.. 
  
 >> 3) lack of source NMUs 
 >> 
 >> there are no source NMUs, so any affected source package that builds an 
 >> arch:all package and also happens to link the problematic source 
 statically 
 >> needs a real, sourceful upload, which scales a lot worse if the number of 
 such 
 >> packages is higher than a handful. 
 > 
 > This is not true, that problem only exists when the arch:all package 
 > itself contains a statically linked binary. 
  
 ack 
  
 > There are cases where this applies (e.g. open source firmware for a 
 > microcontroller in an arch:all package), but these are rare. 
 > 
 >> IIRC there are some plans for tackling this, not related to the issue we 
 are 
 >> discussing at the moment, because source NMUs would be awesome in general 
 ;) 
 >> 
 >> 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. 
 >>... 
 > 
 > drt-tools already supports checking X-Cargo-Built-Using and Static-Built- 
 Using. 
  
 yes, Sebastinas already replied in the same vain :) 
  
 >> did I miss any blockers? please reach out if you have more input or want 
 to 
 >> work on improving the situation! 
 > 
 >>From my list above: 
 > 
 > 4. Handling of many binNMUs 
 > 
 > As part of a DSA for src:rustc in forky we might be talking about 
 >> 1k binNMUs per architecture, let's assume 10k binNMUs altogether. 
  
 I think that over estimates the number of affected packages. 
  
 by my count: 
 - S-B-U rustc in unstable would be 169 (binary) packages (which very likely 
   undercounts) 
 - B-D rustc, cargo, or any of the related debhelper packages in unstable, 
   filtering out source packages which only build `librust-.*-dev` packages, 
 I 
   end up with 310 source packages (which probably overcounts) 
  
 so that gives us a rough number of packages currently possibly missing S-B-U 
 (in the wider Rust ecosystem). 
  
 > In unstable we are already seeing such numbers when a release team 
 > member does "Rebuild for outdated Built-Using" (which also covers 
 > Go and some other stuff), it takes a day and then it is finished. 
  
 like I said - rustc updates every 6 weeks, so yeah, this is roughly everyday 
 business for unstable. 
  
 and while I do think that preparing for the worst case is a good idea, we 
 should also be aware that this is the - hopefully rare to never occuring - 
 worst case, the usual cases will be much smaller. 
  
 most issues so far - AFAICT - did not affect the codegen part of the 
 toolchain, 
 but the toolchain itself (e.g., cargo's interaction with the system), and 
 would 
 only warrant a fix of the toolchain, without a rebuild of (parts of) the 
 world. 
  
 how would a codegen issue with security implications in GCC be handled? ;) 
  
 > Are all steps automated enough that getting 10k uploads through 
 >   security-new -> security -> stable-new -> stable-pu -> stable 
 > is feasible? 
 > 
 > Especially for stable-pu -> stable on release day it also matters that 
 > this is reasonably fast. 
 > 
 > 
 > 5. binNMU version numbering in stable releases 
 > 
 > Currently stable releases (and testing) use the same binNMU versions as 
 > unstable. The result of re-using a version like 1.0-1+b1 in stable when 
  
 [continued in next message] 
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2)