package: jenkins.debian.org
severity: wishlist
hi,
in https://salsa.debian.org/qa/jenkins.debian.net/-/merge_requests/163
James Addison suggested to use --max-container-depth=3 (or 5) for
when diffscope runs into a timeout on a package. (or rather not then,
but always, which why this MR wasnt accepted.)
However this lead to the following discussion on irc:
jayaddison: thanks for closing MR163!
no probs! thought it might confuse/distract someone later
otherwise :)
jayaddison: thinking about it, we could probably run diffoscope with
the reduced depth option on those packages we know diffoscope timeouts, eg all
packages listed more than 4 times on
https://tests.reproducible-builds.org/debian/index_breakages.html
the breakage job could generated that list, and then
reproducible_build.sh could consume it and act accordingly
interesting idea. that was going to be my next question (how to
maintain the list of relevant packages)
I'm slightly averse to adaptive testing because it becomes a
maintenance/debug challenge over time, but am thinking about it
what's the effect of a diffoscope timeout at the moment? no
output at all?
< h01ger> thinking about it, this could cause an interesting jojo effect:
git-annex is tested, diffoscope runs into a timeout. this happens more than 4
times -> git-annex is put on the list of packages which diffoscope is run on
with reduced depth. thus, (hopefullly! now) diffoscope doesnt run into a
timeout
anymore. this happens so often that git-annex appears less than 4
times on the breakages page ->
git-annex is tested without a timeout again, rinse repeat, until
diffoscope or git-annex is improved
yes, its basically empty, see eg
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/git-annex.html
basically true for any link on
https://tests.reproducible-builds.org/debian/index_breakages.html
ok. I guess 'in theory' it'd be nice for diffoscope to diff to
depth 1, then write output, then proceed to depth 2, rewrite output, etc.
nah, depth 3/4/5 should be fine, i hope
first few levels are generally .deb, data/xz or something, and...
I forget. but fast/inexpensive compute-wise
yeah
if we could write output after each layer, there should always be
'something' to show on the results page even if it later fails at depth 8 or
whatever
s/fails/times-out
i'd just go with layer X for a start, i doubt its useful to make this
more sophisticated, esp from the start. also its sophisticated enough to only
invoke this for a few timeouting packages
or maybe even simpler: first run diffoscope normally, then if that runs into a
timeout,
run with --max-container-depth=3 (or 5). I think this would be acceptable with
only 286 suite/arch/package combinations currently which run into a timeout.
I'd still like to store/record somewhere (for later reading, eg to then
semiautomatically
add this information to notes.git) that diffoscope ran into a timeout on this
package,
but for the moment I don't have a plan how to that exactly.
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄
Deutschland ist so rechts, es wird sogar diskutiert ob die Nazis links waren.
(@elhotzo, 20220206)
signature.asc
Description: PGP signature
