On Tue, Apr 16, 2024 at 04:51:09PM +0100, Chris Lamb wrote: > Just to say that I am totally on board with the idea of ensuring we > get _something_ out of diffoscope on tests.reproducible-builds.org.
:) great! > Way better than 250 timeouts. https://tests.reproducible-builds.org/debian/stats_breakages.png showed that in the last 3-4 years there was constant progress on that! \o/ > However, I think this first iteration of --hard-timeout time has a few > things that would need ironing out first, and potentially make it not > worth implementing: > > (1) You suggest it should start again with "--max-container-depth 3", > but it would surely need some syntax (or another option?) to control > that "3" (but for the second time only). another option, --second-pass-max-container-depth or some such > (2) In fact, its easy to imagine that one would want to restart with > other restrictions as well: not just --max-container-depth. For > instance, excluding external commands like readelf and objdump that > you know to be slow. yes, that's a good idea and IMO should be automatically implied for the 2nd pass or round or try. > (3) The output might need some comment saying "this was re-run with > restrictions as we hit a timeout". absolutly. > (4) My gut feel that it would not be all that great to rely on CPython > to really properly clear up child processes after a certain amount of > time. Although I believe the most reliable top-level description to do > this kind of thing inside CPython is to start a watchdog thread that > sleeps until the timeout and then tries to kill everything, but my > experience of doing anything like this within Python itself is not > great, and essentially always needed something at the process level > outside of it for it to be reliable. A container would be even more > effective, I'm sure. hmmm. > In other words, I think the best way of achieving the result we want > is, alas, by doing it outside of diffoscope at the level of the > Jenkins. As in, exactly what you describe here: > > > Else we could also extend the current code for tests.r-b.o/debian, > > which currently > > just kills diffoscope after 2h, to then run diffoscope > > --max-container-depth 3 :) > > Is that a massive faff? :/ not really, I guess it would be rather simple even, I just thought (or think?) that it would be a nice feature for diffoscope proper. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The purpose of propaganda isn't to make you believe something. It's to make you believe nothing. So that you do nothing. (@DarthPutinKGB)
signature.asc
Description: PGP signature
_______________________________________________ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
