Bug#884654: glib2.0 FTBFS on amd64: gdbus test suite failures

[Simon McVittie]

Control: clone -1 -2
Control: clone -1 -3
Control: clone -1 -4
Control: clone -1 -5
Control: retitle -1 glib2.0: FTBFS on amd64 buildd: gdbus-peer test: assertion 'source->ref_count > 0' failed
Control: retitle -2 glib2.0: sometimes FTBFS on reproducible-builds: gwakeup, gwakeup-fallback tests terminated by SIGALRM
Control: found -2 2.50.3-2
Control: found -2 2.54.1-1
Control: retitle -3 glib2.0: sometimes FTBFS on reproducible-builds: gdbus-threading test: assertion failed (elapsed_msec < 8000): (8220 < 8000)
Control: found -3 2.50.3-2
Control: retitle -4 glib2.0: sometimes FTBFS on reproducible-builds: gmenumodel test: assertion failed (items_changed_count == 1): (0 == 1)
Control: retitle -5 glib2.0: sometimes FTBFS on reproducible-builds: tar: ./usr/share/locale/en_??/LC_MESSAGES/glib20.mo/: Cannot savedir: Not a directory
Control: found -5 2.54.1-1

On Mon, 18 Dec 2017 at 06:37:40 +0100, Helmut Grohne wrote:
> glib2.0 fails to build from source on amd64. This happens both on the
> buildd
> https://buildd.debian.org/status/fetch.php?pkg=glib2.0&arch=amd64&ver=2.54.2-2&stamp=1513222982&raw=0
> and on the reproducible infrastructure
> https://tests.reproducible-builds.org/debian/logs/unstable/amd64/glib2.0_2.54.2-2.build2.log.gz.
> Though reproducible experiences more failures (including gwakeup and
> gmenumodel).

I don't think these have the same root cause. r-b doesn't seem to get
the assertion failure seen on the buildd, but it does get different
test failures. Please use separate bugs for what appear to be separate
issues.

Let's use #884654 for the failure on the buildd, and its clones for the
failures on reproducible-builds. All of these might need to be downgraded
to non-RC if they can't be reproduced elsewhere or understood, but I'll
leave them all RC for now.

We are unlikely to be able to get anywhere with most of these test
failures unless someone can reproduce them in an environment that leaves
core dumps, or at least captures backtraces.

The failure on the buildd is new, although I think I might have seen it
before in local testing (but never reproducibly). It's probably some
rarely-hit race condition?

Clone -2 is not new. It has also happened (more often for
gwakeup-fallback) in earlier versions:
https://tests.reproducible-builds.org/debian/rbuild/stretch/amd64/glib2.0_2.50.3-2.rbuild.log
https://tests.reproducible-builds.org/debian/rbuild/buster/amd64/glib2.0_2.54.1-1.rbuild.log
https://tests.reproducible-builds.org/debian/logs/buster/armhf/glib2.0_2.54.1-1.build2.log.gz
Presumably it doesn't happen on the real buildds because the reproducible
build workers are more heavily-loaded, or have more or fewer CPUs, or
some other factor. It isn't the build vs. build2 variation, because this
test failure has been seen in both.

Clone -3 can also be seen in
https://tests.reproducible-builds.org/debian/rbuild/buster/amd64/glib2.0_2.54.1-1.rbuild.log

Clone -4 might be new, or just rare.

Clone -5 (a build failure inside dpkg-builddeb, not a test failure)
I don't know what is going on, and it doesn't seem particularly likely
to be a GLib bug - GLib just puts files in a tree like any other package,
so I'm not sure how it would trigger this particular failure. It can be
seen in these logs:
https://tests.reproducible-builds.org/debian/rbuild/buster/i386/glib2.0_2.54.1-1.rbuild.log
https://tests.reproducible-builds.org/debian/rbuild/unstable/armhf/glib2.0_2.54.2-2.rbuild.log
(not build2, so we presumably can't blame disorderfs either).

    smcv