Right now, we land inside a 404 if we go to:
https://gnome.pages.gitlab.gnome.org/gtk/
as we have all our API references in a sub-level. We should have a
landing page for the root, similar to developer.gnome.org/references/.
gstreamers gl support included headers from this
package without depending on it. Work around this
packaging error by explicitly adding the needed
dependencies.
Most of this is cribbed from glib.
We don't use COMMON_MESON_FLAGS here, since disabling
-Werror one subproject at a time is too painful for
all the promoted sub-sub-projects. This needs a better
solution in meson.
Since this is a full rebuild of the entire stack, limit
this to master and merge requests.
Yielding option means that if pango is built as a subproject, it will
take the value of that option from the parent project (e.g. gst-build).
For that to work it must be of the same type, which is "feature" instead
of "boolean" in all GStreamer modules.
Yielding option means that if pango is built as a subproject, it will
take the value of that option from the parent project (e.g. gst-build).
For that to work it must be of the same type, which is "feature" instead
of "boolean" in all GStreamer modules.
Use feature options for things that are optional features,
update the docs.
Visible changes here is that the 'print-backends' option
got renamed to 'print' to go better with 'media', and the
'tracker3' option got renamed to 'tracker'.
For options that have been changed into features, the
syntax now is -Dfeature=enabled or -Dfeature=disabled
or -Dfeature=auto.
The win toolchain has problems linking meson subprojects to libgtk.
To work around that build glib/pango from git and install them first
as long as the installed version is too old at least.
Fixes#3002
Sysprof has moved to a new ABI which removes GLib from the capture library
so that GLib itself can link against sysprof-capture.
This bumps the library ABI so we can keep things coordinated between all
the new tracing layers in the stack.
The leak sanitizer causes on average 3-4 tests
to segfault during a testsuite run. Disable it
for now to see if we can get a successful
testsuite run with asan alone.
Run our testsuite under asan. We do this in a
separate build, since we need to turn off
introspection to make the build succeed.
As Michael Catanzaro pointed out, this requires a
privileged runner in order to use kernel apis.
When running the testsuite with the address sanitizer,
many of our dependencies cause it to report cause it
to report memory leaks, causing tests to fail.
Therefore, point the leak sanitizer at a list of
suppressions. The list is kept in the lsan.supp
file in git.
Add libasan and libubsan to fedora-base:v20,
and build fedora:20 on top of it.
This is so we can build and run the tests with
the address and undefined behavior sanitizers.
Split the fedora image into fedora-base (containing just
the packages) and fedora (adding the user setup), and add
a fedora-docs image that is adding pandoc on top of the
fedora-base image.
The test setup mechanism in meson is not flexible
enough to let us run different suites depending
on setup, so just pass in explicitly which suites
we want to skip, depending on the backend.
We want the test names in the junit xml to be
unique across all the tests in a job, so we need
to include the backend in the test name.
And we also want to see the used backend in
the html report.
They use powershell instead of cmd.exe, use the tag win32-ps instead of win32,
and run Windows 2016 instead of 2012r2.
The old runners will be switched off in the comming weeks.
We are going to need to hide the report generation into the test runner
script, as we want the job to produce the reports even in case of
failure, instead of bailing out immediately.
We should have a single job for building both static and shared
versions of GTK. On the other hand, having a separate job for the
release build would be a plus.
Additionally, we shouldn't use an opaque script to build GTK; the only
step in the process that requires hand-holding is running the tests
suites under Xvfb, and having the build options visible from the YAML
file gives us a better idea of what kind of build we're running.
We should show all the possible result sections:
- passed
- skipped
- expected failures
- failures
- timed out
Even if we consider the first three to be successes.
My web design skills are terrible, but it's better than nothing; I'm
sure this will lead to somebody filing a merge request to make the
test report look a lot better.
While we're at it, let's include the reftest images inside the report
itself, so we don't have to hunt them down.
The JUnit cover report is useful, but only up to a point; for instance,
it's not used unless it's part of a merge request. This means you don't
get a report if you're pushing to a branch that does not have an MR open.
With a simple Python script and some minimal templating, we can generate
an HTML report from the "I Can't Believe it's not JSON™" log that Meson
produces, and keep it as a CI artifact.
Since we're embedding text coming from the tests into the report, we
should specify an encoding for both the source JSON file and the target
XML file when opening them.
GitLab's CI will bail out at the first failure, which means the
JSON-to-JUnit conversion script won't run unless it's part of the same
script that we run for building an testing.
