Bug#1086552: mutter: sometimes FTBFS: mutter:clutter+clutter/conform / timeline: FAIL: missed 1 frame

[Simon McVittie]

Source: mutter
Version: 47.1-1
Severity: serious
Tags: ftbfs experimental
Justification: fails to build from source (but built successfully in the past)

mutter failed to build from source on several architectures, including
'all', with this failure in the
"mutter:clutter+clutter/conform / timeline" test-case:

> 1..1
> # Start of timeline tests
> Without delay...
> 3: Doing frame 10, delta = 0
> 2: Doing frame 0, delta = 0
> 1: Doing frame 0, delta = 0
> # libmutter-INFO: Acquired name org.gnome.Mutter.InputMapping
> # libmutter-INFO: Acquired name org.gnome.Mutter.ServiceChannel
> 3: Doing frame 8, delta = 261
> 3: Marker 'start-marker' (1666) reached, delta = 261
> 2: Doing frame 2, delta = 261
> 1: Doing frame 2, delta = 261
> 1: Marker 'start-marker' (0) reached, delta = 261
> 3: Doing frame 8, delta = 100
> 3: Marker 'baz' (1333) reached, delta = 100
> 2: Doing frame 2, delta = 100
> 2: Marker 'bar' (333) reached, delta = 100
> 1: Doing frame 2, delta = 100
> 3: Doing frame 7, delta = 100
> 2: Doing frame 3, delta = 100
> 1: Doing frame 3, delta = 100
> 3: Doing frame 7, delta = 100
> 2: Doing frame 3, delta = 100
> 1: Doing frame 3, delta = 100
> 3: Doing frame 6, delta = 100
> 2: Doing frame 4, delta = 100
> 1: Doing frame 4, delta = 100
> 3: Doing frame 5, delta = 100
> 2: Doing frame 5, delta = 100
> 1: Doing frame 5, delta = 100
> 3: Doing frame 5, delta = 100
> 3: Marker 'foo' (833) reached, delta = 100
> 2: Doing frame 5, delta = 100
> 1: Doing frame 5, delta = 100
> 1: Marker 'baz' (833) reached, delta = 100
> 1: Marker 'bar' (833) reached, delta = 100
> 1: Marker 'foo' (833) reached, delta = 100
> 3: Doing frame 4, delta = 100
> 2: Doing frame 6, delta = 100
> 1: Doing frame 6, delta = 100
> 3: Doing frame 4, delta = 100
> 2: Doing frame 6, delta = 100
> 1: Doing frame 6, delta = 100
> 3: Doing frame 3, delta = 100
> 2: Doing frame 7, delta = 100
> 1: Doing frame 7, delta = 100
> 3: Doing frame 2, delta = 100
> 2: Doing frame 8, delta = 100
> 1: Doing frame 8, delta = 100
> 3: Doing frame 2, delta = 100
> 2: Doing frame 8, delta = 100
> 1: Doing frame 8, delta = 100
> 3: Doing frame 1, delta = 100
> 2: Doing frame 9, delta = 100
> 1: Doing frame 9, delta = 100
> 3: Doing frame 1, delta = 100
> 3: Marker 'near-end-marker' (166) reached, delta = 100
> 2: Doing frame 9, delta = 100
> 1: Doing frame 9, delta = 100
> 1: Marker 'near-end-marker' (1500) reached, delta = 100
> 3: Doing frame 0, delta = 100
> 2: Doing frame 10, delta = 100
> 1: Doing frame 10, delta = 100
> 3: Doing frame 0, delta = 100
> 3: Marker 'end-marker' (0) reached, delta = 100
> 3: Completed
> 2: Doing frame 10, delta = 100
> 2: Completed
> 1: Doing frame 10, delta = 100
> 1: Marker 'end-marker' (1666) reached, delta = 100
> 1: Completed
> FAIL: missed 1 frame for timeline 1
> **
> Clutter-Conform:ERROR:../src/tests/clutter/conform/timeline.c:281:timeline_base: assertion failed: (check_timeline (timeline_1, &data_1, TRUE))

If this is operating in real-time, then I think this test might need
to be disabled or marked as flaky for buildd purposes: on an un-loaded
developer machine with a real GPU and other nice amenities, we might be
able to assert that the deadline for a frame is never missed, but on a
buildd that is set up for batch processing, rendering in software and
potentially running other things in parallel, I don't think that assertion
is realistic.

It might also be pragmatic to disable the tests when we are only doing
an Architecture: all build (like we do in glib2.0), so that those always
succeed, even if some builds for specific architectures fail.

    smcv