Do not search in path for snapctl to avoid it to be potentially
overridden by changing the PATH env variable.
Still allow testing by using an ifdef to check if we're building for the
test files or not.
Test all the snap cases and the unknown sandbox one.
We need to use different test processes as we initialize the portal
type early enough that it can't be changed later.
This is of particular use in the gsettings backend, which is currently using
dconf for all snaps.
Fully confined snaps should use the keyfile backend, as Flatpaks do.
Co-Authored-by: Marco Trevisan <mail@3v1n0.net>
Classic snaps are just a kind of packages with no sandbox at all, so
there's no point to mark them as sandboxed.
In this way we can just do IO checks once without having to multiply
them.
Co-Authored-by: Robert Ancell <robert.ancell@canonical.com>
This reverts commit 91f14cd058.
The freedesktop SDK, which is used by gnome-build-meta, only has Meson
0.63. Bumping GLib’s Meson dependency to 0.64 means that, at the moment,
GLib is not buildable in gnome-build-meta and hence can’t be tested in
nightly pipelines against other projects, etc.
That’s bad for testing GLib.
It’s arguably bad that we’re restricted to using an older version of
Meson than shipped by Debian Testing, but that’s a separate discussion
to be had.
Revert the Meson 0.64 dependency until the freedesktop SDK ships Meson ≥
0.64. This also means reverting the simplifications to use of
`gnome.mkenum_simple()`.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3077#note_1601064
This reverts commit 7e3e591d43.
The freedesktop SDK, which is used by gnome-build-meta, only has Meson
0.63. Bumping GLib’s Meson dependency to 0.64 means that, at the moment,
GLib is not buildable in gnome-build-meta and hence can’t be tested in
nightly pipelines against other projects, etc.
That’s bad for testing GLib.
It’s arguably bad that we’re restricted to using an older version of
Meson than shipped by Debian Testing, but that’s a separate discussion
to be had.
Revert the Meson 0.64 dependency until the freedesktop SDK ships Meson ≥
0.64. This also means reverting the simplifications to use of
`gnome.mkenum_simple()`.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3077#note_1601064
This reverts commit 19353017a7.
The freedesktop SDK, which is used by gnome-build-meta, only has Meson
0.63. Bumping GLib’s Meson dependency to 0.64 means that, at the moment,
GLib is not buildable in gnome-build-meta and hence can’t be tested in
nightly pipelines against other projects, etc.
That’s bad for testing GLib.
It’s arguably bad that we’re restricted to using an older version of
Meson than shipped by Debian Testing, but that’s a separate discussion
to be had.
Revert the Meson 0.64 dependency until the freedesktop SDK ships Meson ≥
0.64. This also means reverting the simplifications to use of
`gnome.mkenum_simple()`.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3077#note_1601064
This reverts commit 756b424cce.
The freedesktop SDK, which is used by gnome-build-meta, only has Meson
0.63. Bumping GLib’s Meson dependency to 0.64 means that, at the moment,
GLib is not buildable in gnome-build-meta and hence can’t be tested in
nightly pipelines against other projects, etc.
That’s bad for testing GLib.
It’s arguably bad that we’re restricted to using an older version of
Meson than shipped by Debian Testing, but that’s a separate discussion
to be had.
Revert the Meson 0.64 dependency until the freedesktop SDK ships Meson ≥
0.64. This also means reverting the simplifications to use of
`gnome.mkenum_simple()`.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3077#note_1601064
Meson now uses find_program() to get glib-mkenum from glib instead of
from system. That was already fixed at least in >=0.60 which is our
current minimum requirement.
This is a spiritual follow-up to commit 8cff531520, which
added `G_TEST_OPTION_ISOLATE_DIRS` to the `gdbus-connection-flush` test
to avoid its D-Bus cookie lock file from being erroneously deleted by
other tests running in parallel.
The same failure mode could affect any of the other D-Bus tests which
connect to a bus. As an easy fix, enable `G_TEST_OPTION_ISOLATE_DIRS`
for all of them.
The only test it’s not (yet) enabled for is `gdbus-address-get-session`
as that messes around with `XDG_RUNTIME_DIR` to test finding the session
bus. It might be possible to use `G_TEST_OPTION_ISOLATE_DIRS` with it,
but that would take longer than I have right now.
In any case, the more tests (which try to connect to a bus) that this is
enabled for, the lower the chances of spurious test failure due to them
conflicting over shared resources.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Because Meson complains about using `configure_file(copy: true)`.
Includes improvements by Xavier Claessens.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This is deprecated since Meson 0.62.0, since Meson does this
automatically for us.
This fixes a Meson configure warning.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
It’s been broken since we ported to Meson and nobody has complained, so
let’s deprecate it this cycle and remove it in GLib ≥ 2.78.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2786
They were mixing up `(optional)` and `(nullable)`, and didn’t correctly
annotate the arguments as `(inout)` or `(transfer full)`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2793
We need to ensure that all the expected macros and utilities are working
with all the supported C standards, so just repeat the tests with all
the ones the compiler supports.
We defined G_NO_RETURN as [[noreturn]] in the C++ case, but only after
trying the __attribute__ syntax, so it was never used in GNUC compatible
compilers.
Give it priority instead when supporting a C++11 compiler and onwards.
As per this we need to adapt the code in the places where it was not
properly used (leading to compilation warnings).
It sometimes fails under valgrind, and is pointless: if the test is
wedged, it’s better to catch that with the timeout at the level of
`meson test`, which can be tailored (using `-t`) to the test environment
and wrapper.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2961#note_1600072
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Since it’s now always called the same way after safe_fdwalk() has been
called. This introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This thread is created once during the process’ lifetime and cannot be
destroyed and recreated, as the thread scheduler settings might have
changed since then.
Mark the leak as explicit, mostly for documentation purposes — but it
might quieten some static analysers.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Coverity CID: #1474614
In `safe_closefrom()`, we thought it would be OK to assert that an FD
being closed is valid, when using `safe_fdwalk()`, as it only walks over
known-valid FDs.
However, there is a situation where that might not be true: the program
is being run under valgrind. Valgrind opens some FDs for its own use
which are ≥1024, and it emulates a lowered soft limit on FDs. So if we
were to use `safe_fdwalk_with_invalid_fds()` it would see the lowered
soft limit and not try to close valgrind’s internal FDs.
However, `safe_fdwalk()` looks at `/proc`, which valgrind does not emulate,
so it sees the secret valgrind internal FDs, and then tries to close them.
Valgrind doesn’t like this, prints ‘Warning: invalid file descriptor
1024 in syscall close()’ and returns `EBADF`. That return value
causes `g_close()` to warn about faulty FD refcounting, and that causes
unit test failures.
Fix that by relaxing our assumptions about FD validity: use
the `close_func_with_invalid_fds()` call back for closing FDs
from `safe_fdwalk()`, rather than using `close_func()`. That will
ignore `EBADF` return values.
This should fix valgrind failures like this one:
https://gitlab.gnome.org/GNOME/glib/-/jobs/2389977
Related prior art: https://bugs.freedesktop.org/show_bug.cgi?id=99839
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The new macro form of `g_str_equal()` had stricter type checking than
the original function form. That would be nice, except it causes new
compiler warnings in third party projects, which counts as an API break
for us, so unfortunately we can’t do it.
Add some tests to prevent regressions on this again.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2809
Sadly, in C++ there's not an universal way to get what language standard
is used to compile GLib-based programs, in fact while most compilers
relies on `__cplusplus`, MSVC is defining that, but it does not use it
to expose such information (unless `/Zc:__cplusplus` arg is used).
On the other side, MSVC reports the language standard via _MSVC_LANG [1].
This complication makes us defining some macros in a very complex way
(such as glib_typeof()), because we need to perform many checks just to
understand if a C++ compiler is used and what standard is expecting.
To avoid this, define multiple macros that can be used to figure out
what C++ standard is being used.
[1] https://docs.microsoft.com/en-us/cpp/build/reference/zc-cplusplus?view=msvc-170
It was previously only enabled (by default) on macOS, which led to
code being committed which triggered warnings, as that CI job is not
always run.
Avoid that risk by always enabling the warning.
The reasoning for using this warning is that explicit initialisation is
clearer than implicit. We also want to support GLib’s public headers
being used in projects which build with
`-Werror=missing-field-initializers`, but can’t easily enable the
warning for our public headers but not our internal code. So enable it
everywhere.
Make it a warning rather than an error, as there’s a risk that system
header changes will trigger it in distro release builds, which would
cause false build failures. By making it a warning, GLib developers can
build with `-Werror` and promote it to an error, while distros can
choose not to.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2812
