Re: MBF: Packages which FTBFS with the nocheck build profile

[Helmut Grohne <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