Bug#1042055: mutter: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 MESON_TESTTHREADS=8 meson test -C /<<PKGBUILDDIR>>/obj-x86_64-linux-gnu --no-rebuild --verbose --timeout-multiplier 6 --no-stdsplit --print-errorlogs --no-suite flaky returned exit code 5

[Lucas Nussbaum]

On 18/08/23 at 10:33 +0100, Simon McVittie wrote:
> Control: clone -1 -2 -3 -4 -5
> Control: retitle -1 mutter: FTBFS: test-framebuffer-get-bits.c:40: assertion failed (cogl_framebuffer_get_alpha_bits (fb_a) >= 1)
> Control: retitle -2 mutter: FTBFS: actor-event-hold test failed with exit status 245
> Control: retitle -3 mutter: FTBFS: color-management test: Failed to reset mocked colord state: Timeout was reached
> Control: retitle -4 mutter: FTBFS: override-redirect test timed out
> Control: retitle -5 mutter: FTBFS: set-parent-exported test: Failed to find mocked color manager system service, Timeout was reached
> Control: severity -2 important
> Control: severity -3 important
> Control: severity -4 important
> Control: severity -5 important
> Control: tags -2 + unreproducible
> Control: tags -3 + unreproducible
> Control: tags -4 + unreproducible
> Control: tags -5 + unreproducible
> Control: block 1043030 by -1
> Control: block 1049934 by -1
> Control: block 1035092 by -1
> 
> On Tue, 25 Jul 2023 at 23:02:16 +0200, Lucas Nussbaum wrote:
> > FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 MESON_TESTTHREADS=8 meson test -C /<<PKGBUILDDIR>>/obj-x86_64-linux-gnu --no-rebuild --verbose --timeout-multiplier 6 --no-stdsplit --print-errorlogs --no-suite flaky returned exit code 5
> 
> This is a long-winded way of saying "some tests failed". The more useful
> information for tracking regressions is either "some tests failed" if it's
> not possible to extract details, or the details of *which* tests failed.

Yeah, I know. Unfortunately, due to the variety of test frameworks in
the wild, it's hard to extract a more meaningful message...

> > >  98/212 mutter:cogl+cogl/conform / cogl-test-framebuffer-get-bits-gl3                                  FAIL             1.19s   (exit status 250 or signal 122 SIGinvalid)
> 
> I can reproduce this, and it's blocking other work on mutter 43. Version
> 44 in experimental does not seem to have this bug, though.
> 
> The assertion failure is:
> 
> > ERROR:../src/tests/cogl/conform/test-framebuffer-get-bits.c:40:test_framebuffer_get_bits: assertion failed (cogl_framebuffer_get_alpha_bits (fb_a) >= 1): (0 >= 1)
> 
> mutter passed tests when I uploaded it in mid June, so this presumably
> must be a regression triggered by changes in some dependency, perhaps
> Mesa. Let's use #1042055 for this failure and clones for the rest.
> 
> reproducible-builds also has this failure.
> 
> > > 140/212 mutter:clutter+clutter/conform / actor-event-hold                                              FAIL             1.06s   (exit status 245 or signal 117 SIGinvalid)
> 
> There is no obvious error message in the log (the test just exits). There's
> a warning, but it's non-fatal and appears in successful tests too. I can't
> reproduce this.
> 
> > > 169/212 mutter:core+mutter/unit / color-management                                                     FAIL            26.69s   (exit status 251 or signal 123 SIGinvalid)
> 
> "Failed to reset mocked colord state: Timeout was reached". I can't
> reproduce this.
> 
> > > 194/212 mutter:core+mutter/stacking / override-redirect                                                TIMEOUT        360.11s   killed by signal 15 SIGTERM
> 
> Timed out, no additional information in the log. I can't reproduce this.
> 
> > > 196/212 mutter:core+mutter/stacking / set-parent-exported                                              FAIL           176.22s   (exit status 251 or signal 123 SIGinvalid)
> 
> "Failed to find mocked color manager system service, Timeout was reached".
> I can't reproduce this.

Hi,

> Does your archive rebuild infrastructure build other things in parallel on
> the same machine, or any other factor like that which could make it more
> likely to get stuck / take a long time than a production buildd?

No. What I do is that I perform a first pass over all packages, building 3
packages per node in parallel. But then, failed builds are retried
without other builds in parallel.

In other rebuilds I made since then, the failures other than the first
one (98/212 mutter:cogl+cogl/conform /
cogl-test-framebuffer-get-bits-gl3) did not happen, so maybe what
happened was:
- the first build failed as expected with 98/212
- the second build failed for an unknown reason with all errors above

I'm fine with you closing all those other bugs for now if you prefer.

Lucas