From: helmut@subdivi.de 
  
 Hi Santiago, 
  
 On Thu, Oct 02, 2025 at 12:54:07PM +0200, Santiago Vila wrote: 
 > Remark: I only report a nocheck FTBFS when the package builds ok 
 > normally, because otherwise you have to compare two different modes of 
 > failure, and that makes things a lot more complex for little gain. 
  
 Right, sorting out FTBFS before nocheck FTBFS makes sense. That amounts 
 to swapping steps 1 and 2. 
  
 > So, I know for sure that the current MBF I just did misses a few cases. 
 > I consider those to be "hidden" by their current regular FTBFS issue, 
 > and they will stop to be hidden when their regular FTBFS issue is fixed. 
 > 
 > >    2. Perform a normal build 
 > >       + failure? -> stop + report FTBFS 
 > >    3. Compare the binary artifacts of these builds for equality 
 > >       + equal? -> stop 
 > >    4. Perform another normal build 
 > >       + failure? -> stop + report random FTBFS 
 > >    5. Compare the binary artifacts of the two normal builds 
 > >       + equal? -> stop + report nocheck changing the result 
 > >    6. Compare the content filenames of the nocheck build and the normal 
 > >       build 
 > >       + inequal? -> stop + report nocheck changing the result 
 > > 
 > > What do you think? 
 > 
 > I have to choose my battles because I have too many of them... 
 > 
 > I'm not ready to do cross-builds yet, and my framework is not ready to 
  
 There is no cross build involved here. 
  
 > compare binary artifacts as such (because the outcome is always "build 
 > logs"), but maybe I should think about extracting the Checksums-Sha256 
 > from the build logs (regular build) and do something with them, 
 > as a sub-product of my current archive rebuilds. 
  
 Yes, the aforementioned method should work with build logs obtained from 
 sbuild only, because sbuild records the package checksums (as you 
 noted) and also lists package contents after a successful build (this is 
 part of step 6). So the analysis is a bit more elaborate as you get to 
 combine two to three build logs to generate a report, but other than 
 that your log-centric workflow should continue to work with this. 
  
 > Is there an easy way to get a list of packages known to be reproducible? 
 > [ In the worst case, I could just get all the packages in sid (from 
 > Sources.xz) and substract the ones having an entry in notes.git ] 
  
 PGPASSWORD=udd-mirror psql --host=udd-mirror.debian.net --user=udd-mirror 
 udd 
 -c 'select * from reproducible limit 10;' 
  
 Helmut 
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2)