It is causing tests to timeout when libraries we are using
leak bus connections, and it turns out our tests run fine
without a session bus.
Backport of 1b265a7971171.
CI and downstream packagers have been using the Meson build for a while
now, and we checked that it's idempotent to the Autotools build.
Having two build systems in tree doesn't make maintaining and releasing
GTK any easier, even if it's the stable/frozen branch.
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.
a11ytests.test doesn't seem to be reliable enough to be used as a QA
acceptance criterion, and has been disabled as a build-time test in both
Gitlab-CI and Debian since 2019. a11ystate.test is not set up to be run
at build time at all, and has been marked as flaky on ci.debian.net
since 2018.
The rest of the testsuite/a11y directory seems to have been
reliable in practice, at least on ci.debian.net, so try leaving them
enabled as installed-tests.
In principle this could be made finer-grained by having a separate .test
file and a separate Meson test() for each .ui file, but that would
require more active maintenance of GTK 3.
Signed-off-by: Simon McVittie <smcv@debian.org>
At least some of the tests implemented via the accessibility-dump
executable are known to be unstable, but the tests based on separate
executables (tree-performance.c, etc.) have been reasonably consistently
passing on ci.debian.net for several years, so hopefully they are also
reliable enough for upstream CI and we don't need to mark them as flaky?
Signed-off-by: Simon McVittie <smcv@debian.org>
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.
In GTK 3.24.35, if the environment is such that the label-sizing.ui
reftest happens to be successful, the overall result of the test suite
is failure. This seems unlikely to have been the intention.
Instead of using should_fail, 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
with a command like:
meson test --setup=unstable_tests --suite=flaky --suite=failing
This arrangement is inspired by GNOME/glib!2987, which was contributed
by Marco Trevisan.
Signed-off-by: Simon McVittie <smcv@debian.org>
Since GLib 2.73.0 it can only be called once per process.
Based on commit 78c153ae in GTK 4, but combining the icontheme test's
two custom log writers into one log writer that serves both purposes,
to avoid the need for a subprocess.
Co-authored-by: Matthias Clasen <mclasen@redhat.com>
Resolves: https://gitlab.gnome.org/GNOME/gtk/-/issues/5119
Set all settings to their default values, so we
are less dependent on the environment to be set
up just right. In particular, this fixes animations
being disabled when we happen to run in a vm.
... if we're not using indicators and the policy may be visible. Not
doing this if the policy may be invisible is incorrect as we need to
reserve the space anyway in case the scrolledwindow is allocated at
minimum size and the child size increases to show the scrollbar.
Various files are in git but not in dist tarballs. Some of them look
like potentially useful references for downstream distributors.
Signed-off-by: Simon McVittie <smcv@debian.org>
The bug was introduced in commit:
9b7640b8 by Benjamin Otte, 2012-03-26 17:24:02
styleproperty: Make _gtk_style_property_parse_value() return a CssValue
In that commit, `values` changed from `GValue*` to `GtkCssValue**`,
but one `!G_IS_VALUE (&values[8])` was left untouched. As a result,
if `border` shorthand contains anything after color, it might crash,
depending on memory layout.
New test included.
Fixes: #751
We need to mark the prototypes in the headers so that they get exported
properly from the reftest DLLs that we build, so that the reftest DLLs
and program will link properly. Include gtk-reftest.h in
reftest-snapshot.c so that the compiler picks up the export directives
as needed.
Instead, use the standard library().
This is a meson best practice.
Fixes#2248.
Fixes -Ddefault_library=static not having any effect.
Cherry-Picked-From: bb9c07d8fe8b90c42ba81fb5bb6f8a9826252660
I couldn't get all reftests to work reliably, so the tests failing
on either CI or on my machine are skipped for now.
Installed tests are disabled by default and can be enabled with "-Dinstalled_tests=true"
The documentation for gtk_widget_get_action_group
and gtk_widget_list_prefixes states that both of
these operate on all the action groups that are
'available' to the widget.
Which means: they are meant to walk up the parent
muxer chain. So do that.
Add tests to verify the expected behavior.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1396
Under autotools the compiled schemas are in the build directory and with
meson they are in the root build dir. Avoid changing the autotools build for
now and add a special GTK_TEST_MESON env var which we can use to differentiate
the two.
See 1253e7bfcbc80f88 for a similar fix on master.
