Vagrant Cascadian wrote:
> On 2024-04-16, Chris Lamb wrote:
>> 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
Holger Levsen wrote:
>> (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,
On 2024-04-16, Chris Lamb wrote:
> 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
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.
Holger Levsen wrote:
> Anyhow, about my --hard-timeout option idea:
>
> my idea of "--hard-timeout $time" is that diffoscope terminates itself
> after $time, no matter what *and* then re-starts itself with
> "--max-container-depth 3"
Just to say that I am totally on board with the idea of
Package: diffoscope
Version: 264
Severity: wishlist
Dear Maintainer,
currenlty diffoscope has a --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
6 matches
Mail list logo
