diffoscope 259 is marked for autoremoval from testing on 2024-05-04
It (build-)depends on packages with these RC bugs:
1064676: android-platform-tools-apksig: FTBFS: dh_auto_test: error: gradle
--info --console plain --offline --stacktrace --no-daemon
--refresh-dependencies --gradle-user-home
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: libscout
Version: 2.3.2-3
Severity: normal
X-Debbugs-Cc: reproducible-builds@alioth-lists.debian.net, Fay Stegerman
Dear Maintainer,
a few days ago I filed "#1068705: diffoscope crashes on libscout 2.3.2-3 build
on unstable but not bullseye" which then led Fay Stegerman to discover
On Mon, Apr 15, 2024 at 03:00:42PM +0200, Fay Stegerman wrote:
> > (thanks again!), am I correct to assume that thus there's no need
> > to file a seperate bug against libscout?
> It's generating a broken ZIP file with duplicate entries. It really shouldn't
> be doing that, regardless of whether
