[Reproducible-builds] automated diffoscope for parallel build bugs

[Jeremy Bicha]

On Thu, Aug 18, 2016 at 5:47 PM, Chris Lamb <lamby at debian.org> wrote:
> So, just to be 100% clear, simply varying DEB_BUILD_OPTIONS="parallel=X"
> would not have discovered this gedit bug? (Related, our list of variations
> between the builds can be viewed online[0])

I don't know, but the difference between parallel=17 and parallel=18
seems almost inconsequential compared to say, parallel=1 and
parallel=2. In other words, keep whatever high number is appropriate
for one build but completely disable parallel building (parallel=1)
for the other (or one of the other) builds.

I understand that building with parallel disabled takes much longer
for many packages so I don't know if this is just a lack of resources
issue.

> Ah, so this is mostly a one-off to justify that you would not break too
> many things before you enable it…? If so, I can think of a few hacky and
> temporary solutions.

I think it would be good to run at least periodically as code changes
to ensure that parallel building hasn't broken anything (similar to
how routine FTBFS testing is done [which now with reproducible builds
is done quite frequently]). I think it should probably be run over the
entire archive since debhelper 10 will presumably be widely deployed.

And no, it doesn't need to happen before some maintainer enables
parallel building; I think getting a bug report or a warning email or
whatever afterwards is fine.

> (Can you also clarify what you are saying would be arduous about "manually"
> diffoscoping? If the package is reproducible, then diffoscope would clearly
> return nothing…)

Building everything in pkg-gnome svn individually with and without
parallel and then running diffoscope by hand to compare every binary
package is not much fun. A script would make it easier but I don't
have a script for that. And maybe my problem is general and important
enough that a solution would be useful for all of Debian...

Thanks,
Jeremy