This allows applications to get their value regardless whether glib is a
subproject or pkgconfig:
gio_dep = dependency('gio-2.0')
giomoduledir = gio_dep.get_variable('giomoduledir')
schemasdir = gio_dep.get_variable('schemasdir')
This reverts commit 5aa03882ca.
It fails to compile on newer Meson versions with
`--fatal-meson-warnings` due to:
```
WARNING: Project targeting '>= 0.52.0' but tried to use feature introduced in '0.54.0': variables arg in declare_dependency.
gio/meson.build:833:0: ERROR: Fatal warnings enabled, aborting
```
That happens regardless of the fact that we’ve correctly limited the use
of the `variables` argument to only when building with Meson ≥ 0.56.
Unfortunately Meson can’t statically detect that the argument is
conditional.
Bumping GLib’s Meson dependency is too much work right now, so this MR
unfortunately has to be reverted.
This allows applications to get their value regardless whether glib is a
subproject or pkgconfig:
gio_dep = dependency('gio-2.0')
giomoduledir = gio_dep.get_variable('giomoduledir')
schemasdir = gio_dep.get_variable('schemasdir')
`mock-resolver.c` is a mock implementation of `GResolver` used in the
`network-address` tests. It returns resolver results, and implements
timeouts, as directed by the test calling it.
In particular, it allows the IPv4 and IPv6 resolver results to be
returned using independent delays. This allows code paths which deal
with IPv4 and IPv6 results being returned at different times to be
tested, as the ‘Happy Eyeballs’ spec mandates various hard-coded
timeouts for returning the best results it can in a reasonable
timeframe.
Previously, `mock-resolver.c` implemented the timeouts by handling
`lookup_by_name()` in a `GTask` worker thread, and calling `g_usleep()`
for the timeout. This seemed to cause occasional CI failures, such as
https://gitlab.gnome.org/GNOME/glib/-/jobs/1843454, where a resolver
error would be returned rather than the expected results:
```
ok 52 /network-address/happy-eyeballs/ipv4-error-ipv6-first
\# GLib-GIO-DEBUG: IPv4 DNS error: IPv4 Broken
(/var/tmp/gitlab_runner/builds/Ff4WDDRj/0/GNOME/glib/_build/gio/tests/network-address:18428): GLib-GIO-DEBUG: 09:03:08.587: IPv4 DNS error: IPv4 Broken
Bail out! GLib-GIO:ERROR:../gio/tests/network-address.c:586:got_addr: assertion failed (error == NULL): IPv4 Broken (g-io-error-quark, 24)
stderr:
**
GLib-GIO:ERROR:../gio/tests/network-address.c:586:got_addr: assertion failed (error == NULL): IPv4 Broken (g-io-error-quark, 24)
```
While I’ve been unable to reproduce these failures locally, I suspect
they might be down to thread spawning occasionally taking long enough on
a CI runner to change the ordering of the timeouts, such that the ‘Happy
Eyeballs’ algorithm returns a different set of results from what the
test expects.
So, this commit rewrites part of `mock-resolver.c` to implement timeouts
in the main thread, rather than in a worker thread. That should
eliminate the delays in spawning threads, and should mean that the
timeout sources in `mock-resolver.c` are attached to the same
`GMainContext` as those from the ‘Happy Eyeballs’ algorithm which are
monitoring them, so a total order over the timeouts can be guaranteed.
Of course, I might be completely wrong since this is just a guess and I
can’t properly test it since I can’t reproduce the failure. Worth a try.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The test results weren’t being freed.
This makes the `network-address` test clean under memcheck for me.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
If these struct members aren't available, we can be more like an
abstraction layer by falling back to yielding 0.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Test failures were previously ignored on macOS because there are 12
tests which consistently fail (and have not yet been fixed, because
there are no regularly active macOS maintainers for GLib; you could help
here!).
However, this means that new test failures can’t be spotted.
So, explicitly mark those 12 tests as `should_fail` on macOS, and then
make other test failures cause failure of the CI run.
We can track the process of fixing those 12 tests on #1392 and #1251.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1392
As they use `g_test_dbus_*()`, they depend on dbus-daemon, so move them
to the part of the Meson file which lists those tests.
This disables them running on platforms which don’t have `dbus-daemon`
available. Arguably, this should be done by returning an error from
`g_test_dbus_up()` and then calling `g_test_skip()`, so the test is
correctly recorded as having been skipped. But that’s a fix for another
time.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Having compared the debug output, it doesn’t show anything unusual
happening that can’t already be seen from other output, for this test.
This is a partial revert of 8fd71dccc5. The debugging output it added to
other tests may still be useful.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1929
The retry loop for acquiring the lock for the authentication cookie file
currently tries to acquire the lock for 0.5s, then gives up, assumes the
lock file is stale, and deletes it.
That’s great if the lock file *is* stale because it’s been left there by
a crashed process.
It’s not so great if the lock file just happens to have been there every
time this process checked, because the cookie file is highly contested
while (for example) running lots of parallel unit tests.
Check for that situation by comparing the mtime of the lock file and
continuing to retry if it’s changed.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #1929
Rather than tracking them with a counter. This should close the race in
tracking the finalisation of the tasks by the task worker thread.
There’s no way to synchronise with that thread as it’s internal to
`g_task_run_in_thread()`.
This should hopefully stop the `debugcontroller` test being flaky.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2486#note_1384102
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
We are matching `<parameter>` as well as `<para>`, and we
end up with broken XML in case the (expanded) description
starts with `<parameter>`.
Fixes: #2601
