Vagrant Cascadian wrote:
> Some things just take a long time to run diffoscope, and
> tests.reproducible-builds.org only lets diffoscope run for 150m and then
> kills it to avoid very large unreproducible packages from eating all the
> resources.
(I do see that Vagrant has sent a diff in a subsequent email in this
thread...)
For the benefit of Roman, there are actually two levels of timeouts
involved when running diffoscope on tests.reproducible-builds.org:
First, we pass a value to diffoscope's --timeout option:
--timeout SECONDS Best-effort attempt at a global timeout in seconds. If
enabled, diffoscope will not recurse into any further
sub-archives after X seconds of total execution time.
(default: no timeout) [experimental]
... and then there's a longer and harsher timeout that's controlled by
the Jenkins apparatus that runs tests.r-b.org. It is this timeout you
are seeing when you see "diffoscope was killed..." on the website.
It's not strictly a *bug* that diffoscope takes a long time, but it is
curious that the best-effort "--timeout" is not kicking in early enough
and ensuring that the harsher timeout does not kill diffoscope outright.
Indeed, the --timeout option was implemented precisely to avoid having
no output whatsoever on tests.r-b.org.
Vagrant, do you have --profile output, out of interest? It would be
interesting, for instance, if the HTML generation was taking so long
that even if diffoscope stopped recursing into subarchives, it hit
Jenkins' hard timeout. This may suggest that there is a bug in the
HTML generation, and/or that the --timeout value on tests.r-b.org has
not been set low enough relative to the hard timeout.
Best wishes,
--
o
⬋ ⬊ Chris Lamb
o o reproducible-builds.org 💠
⬊ ⬋
o
_______________________________________________
Reproducible-builds mailing list
Reproducible-builds@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
