Disable a couple more failing tests.

Gbp-Pq: Name disable-a-couple-more-failing-tests.patch

Disable a couple of faliing tests in Raspbian.

Last-Update: 2021-09-07

Gbp-Pq: Name disable-tests-raspbian.patch

Disable clipboard test

This regularly times out on buildds, but I can't reproduce the hang
locally.

Bug: https://gitlab.gnome.org/GNOME/gtk/-/issues/4229
Forwarded: no

Gbp-Pq: Topic debian
Gbp-Pq: Name Disable-clipboard-test.patch

Disable inscription-markup.ui reftest

It's rendered 1px to the left of where it should be, which is not a
serious problem for practical use of GTK, but is a test failure.

Bug: https://gitlab.gnome.org/GNOME/gtk/-/issues/5099
Forwarded: not-needed, workaround

Gbp-Pq: Topic debian
Gbp-Pq: Name Disable-inscription-markup.ui-reftest.patch

reftests: Allow minor differences to be tolerated

Based on an earlier patch by Michael Biebl, as used in Debian's GTK 3
packaging, with additional inspiration from librsvg's reftests.

Each .ui or .node reftest can have an accompanying .keyfile file
like this:

    [reftest]
    tolerated-diff-level=20
    tolerated-diff-pixels=1000

If the image differs, but the number of pixels that differ is no more
than tolerated-diff-pixels and the differences are no more than
tolerated-diff-level, then we treat it as a success with warnings, save
the .diff.png for analysis, and use g_test_incomplete() to record the
test-case as "TODO".

Signed-off-by: Simon McVittie <smcv@debian.org>
Forwarded: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3195
Applied-upstream: no, upstream want reftests to be a strict pass/fail with identical results required

Gbp-Pq: Topic debian
Gbp-Pq: Name reftests-Allow-minor-differences-to-be-tolerated.patch

reftest_compare_surfaces: Report how much the images differ

In unattended/non-interactive/autobuilder environments where the images
are not trivially accessible, this provides a way to distinguish between
totally different rendering and more subtle issues.

Signed-off-by: Simon McVittie <smcv@debian.org>
Forwarded: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3195
Applied-upstream: no, upstream want reftests to be a strict pass/fail with identical results required

Gbp-Pq: Topic debian
Gbp-Pq: Name reftest_compare_surfaces-Report-how-much-the-images-diffe.patch

node-editor: Save test data relative to current working directory

This avoids hard-coding the GTK source directory into the binary, which
would make the binary non-reproducible across different source paths,
particularly in a distro build environment where the source directory
used by autobuilders will often not exist on end-user systems. The node
editor can still be used to create new test-cases by running it with the
GTK source directory as its current working directory.

Bug: https://gitlab.gnome.org/GNOME/gtk/-/issues/5403
Forwarded: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/5297
Signed-off-by: Simon McVittie <smcv@debian.org>
Gbp-Pq: Name node-editor-Save-test-data-relative-to-current-working-di.patch

testsuite: Don't create .test files for flaky or failing tests

These tests can be run manually, but are not suitable for use as an
acceptance test, so let's not make frameworks like Debian's autopkgtest
run these when they run ginsttest-runner in the most obvious way.

Signed-off-by: Simon McVittie <smcv@debian.org>
Applied-upstream: 4.9.2, commit:94b57a967c492ab18df8142557710ba0b1a02cee

Gbp-Pq: Name testsuite-Don-t-create-.test-files-for-flaky-or-failing-t.patch

testsuite: Use separate setups for unstable tests instead of should_fail

There are two possible interpretations of "expected failure": either
the test *must* fail (exactly the inverse of an ordinary test, with
success becoming failure and failure becoming success), or the test
*may* fail (with success intended, but failure possible in some
environments). Autotools had the second interpretation, which seems
more useful in practice, but Meson has the first.

Instead of using should_fail, we can put the tests in one of two new
suites: "flaky" is intended for tests that succeed or fail unpredictably
according to the test environment or chance, while "failing" is for
tests that ought to succeed but currently never do as a result of a
bug or missing functionality. With a sufficiently new version of Meson,
the flaky and failing tests are not run by default, but can be requested
by running a setup that does not exclude them, with a command like:

    meson test --setup=x11_unstable --suite=flaky --suite=failing

As a bonus, now that we're setting up setups and their excluded suites
programmatically, the gsk-compare-broadway tests are also excluded by
default when running the test setup for a non-broadway backend.

When running the tests in CI, --suite=gtk overrides the default
exclude_suites, so we have to specify --no-suite=flaky and
--no-suite=failing explicitly.

This arrangement is inspired by GNOME/glib!2987, which was contributed
by Marco Trevisan.

Signed-off-by: Simon McVittie <smcv@debian.org>
Applied-upstream: 4.9.2, commit:957dd49ef7d371926f90212bdf52b92742062e3e

Gbp-Pq: Name testsuite-Use-separate-setups-for-unstable-tests-instead-.patch

gtk4 (4.8.3+ds-1+rpi1) bookworm-staging; urgency=medium

  [changes brought forward from 4.4.0+ds1-5+rpi1 by Peter Michael Green <plugwash@raspbian.org> at Tue, 07 Sep 2021 10:26:09 +0000]
  * Disable a couple of faliing tests in Raspbian.
  * Fix clean target.

  [changes introduced in 4.8.3+ds-1+rpi1 by Peter Michael Green]
  * Disable a couple more failing tests.

[dgit import unpatched gtk4 4.8.3+ds-1+rpi1]

Import gtk4_4.8.3+ds-1+rpi1.debian.tar.xz

[dgit import tarball gtk4 4.8.3+ds-1+rpi1 gtk4_4.8.3+ds-1+rpi1.debian.tar.xz]

Import gtk4_4.8.3+ds.orig.tar.xz

[dgit import orig gtk4_4.8.3+ds.orig.tar.xz]