Hi,

On Mon, Sep 06, 2021 at 05:07:50PM +0200, Mark Wielaard wrote:
> On Sat, 2021-09-04 at 01:47 +0200, Mark Wielaard wrote:
> > On Fri, Sep 03, 2021 at 02:08:40PM +0000, 
> > buildbot@builder.wildebeest.org wrote:
> > > The Buildbot has detected a new failure on builder elfutils-debian-
> > > armhf while building elfutils.
> > > Full details are available at:
> > >     https://builder.wildebeest.org/buildbot/#builders/15/builds/603
> > > 
> > > Buildbot URL: https://builder.wildebeest.org/buildbot/
> > > 
> > > Worker for this Build: debian-armhf
> > > 
> > > Build Reason: <unknown>
> > > Blamelist: Mark Wielaard <mark@klomp.org>
> > > 
> > > BUILD FAILED: failed test (failure)
> > 
> > So some of the builders did pass without any failures. But some had
> > errors, and not all the same ones. I couldn't replicate locally
> > (everything was green) both with make check and make distcheck.
> > 
> > But looking at the tests I noticed not all used a clean new cache and
> > some used the default database.
> > 
> > So hopefully the attached patch makes things a bit more stable by
> > explicitly setting the DEBUGINFOD_CACHE_PATH and invoke debuginfod
> > with a fresh sqlite database.
> 
> Sadly we still have failures even with this patch:
> https://builder.wildebeest.org/buildbot/#/changes/2567
> 
> The good news is that elfutils-fedora-x86_64, elfutils-fedora-ppc64le,
> elfutils-fedora-s390x, elfutils-debian-i386, elfutils-fedora-ppc64 and
> elfutils-debian-armhf are fully green, but...
> 
> On elfutils-centos-x86_64 make check fails with:
> 
> FAIL: run-debuginfod-tmp-home.sh
> FAIL: run-debuginfod-writable.sh
> 
> On elfutils-debian-arm64 make check fails with:
> 
> FAIL: run-debuginfod-federation-sqlite.sh
> 
> On elfutils-centos-x86_64 make check first timed out (!?!)
> then it failed with:
> 
> FAIL: run-debuginfod-tmp-home.sh
> FAIL: run-debuginfod-writable.sh
> 
> On elfutils-debian-amd64 make check failed with:
> 
> FAIL: run-debuginfod-archive-groom.sh
> 
> The failures still look somewhat random (although less random than
> before). I don't yet know why.

This doesn't really explain the above failures, but there were still
two tests that didn't use their own debuginfod client cache. Also one
set a useless, but confusing DEBUGINFOD_URLS.

Still looking for explanations of the other FAILS (which I cannot
reproduce locally).

Cheers,

Mark