11:09:10 
 0.1, 
 USER_IN_ 
 h/aQssNWgiCizRAss/@localhost 
 581c- 
 From: bunk@debian.org 
  
 On Wed, Nov 05, 2025 at 07:15:33AM +0100, Fabian Grünbichler wrote: 
 > 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: 
 >... 
 > > 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). 
  
 Sorry, my fault that I was estimating based on memory instead of double- 
 checking. 
  
 Go actually has higher numbers here, with 372 packages having a golang 
 compiler in Built-Using on amd64/unstable (which gives ~ 2600 binNMUs 
 over 7 release architectures). 
  
 > > 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? ;) 
  
 If affected packages can be narrowed down to a smaller number by 
 scanning all binary packages in the archive (which is not hard) 
 it's OK, otherwise it would be a disaster. 
  
 But CVEs in glibc are not rare,[1] and when I say src:rustc I am 
 thinking of libstd-rust-dev. 
  
 >... 
 > > 6. Non-flaky builds 
 > > 
 > > When we are talking about 10k binNMUs as part of a DSA, it would be a 
 > > real pain if only 99% of all builds are successful since that would be 
 > > 100 build failures the security team would have to handle manually. 
 > 
 > and this as part of QA is a good idea anyway, yes! the packages shipping 
 > binaries built from/with Rust code are already regularly rebuilt during the 
 > pre-release phase in unstable, either by virtue of natural churn, or by 
 > scheduled rebuilds because of rustc updates, so the risk here should be 
 smaller 
 > than with other ecosystems where the last build might have been years ago. 
 >... 
  
 Santiago Vila is doing a really good job at finding those, but we might 
 need a policy from the release team that packages must build successfully 
 every single time and that it is an RC bug when the build succeeds only 
 in 99.9% of all attempts. 
  
 In a related note, the "giveback" option for DDs at buildd.d.o should 
 then perhaps be removed. 
  
 cu 
 Adrian 
  
 [1] The C ecosystem also has the problems of missing B-U, and that so far 
     never all packages have been rebuilt for B-U in point releases. 
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2)