The `GTK_USE_PORTAL` environment variable has started to be misused by
users, which is causing deployment issues (such as portal services
themselves ending up being forced to use portals, which is never going
to work).
Try and sidestep users’ broken configurations by renaming the
environment variable, and also separating it from the old GTK
environment variable, since the GLib one affects a lot more processes.
This environment variable is meant to be used for
debugging and development, and never in production.
GTK already renamed their environment variable in
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4829, so keeping the
`GTK_USE_PORTAL` name in GLib doesn’t make sense anyway.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #3107
The introspection parser isn't good enough to expand the shift symbol,
which means G_TYPE_FUNDAMENTAL_MAX is evaluated as (255 << 0).
We can use the `(value)` annotation to force the symbol value in the
introspection data.
See: GNOME/gobject-introspection#473
On FreeBSD /home is generally a symlink to /usr/home, so the relative
resolves to /usr/bin instead of /bin and `sh` can only be found in /bin
on FreeBSD. Fix this by resolving symlinks in the CWD first.
When building for CHERI with additional warning flags, implicitly
converting uintptr_t to an integer type that can't store a pointer
results in a compiler warnings. Silence two of these by adding
explicit casts.
Some compilers (e.g. CHERI LLVM) warn when casting a non-intptr_t integer
type to a pointer. The GSIZE_TO_POINTER() macro thus triggers warnings
which can be silence by casting to guintptr before gpointer.
NB: This macro must not be used to create valid pointers from a integer.
I had thought that because `g_source_destroy()` was called for the two
sources (cancel and timeout) in the `GTask` finalize function for a
threaded resolver operation, that it would be fine to use a plain
pointer in the source callbacks to point to the `GTask`.
That turns out to not be true: because the source callbacks are executed
in the GLib worker thread, and the `GTask` can be finalized in another
thread, it’s possible for a source callback (e.g. `cancelled_cb()`) to
be scheduled in the worker thread, then for the `GTask` to be finalized,
and then the source callback to continue execution and find itself
doing a use-after-free.
Fix that by using a weak ref to the `GTask` in the source callbacks,
rather than a plain pointer.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Fixes: #3105
The gutils-user-database.c is broken in two ways and currently doesn't test anything:
* It only overrides getpwuid, where the implementation used getpwnam_r if it exist, which should be every system for at least 20 years.
* It only partly cargo-culted setting the environment for the local and installed tests, but failed to actually set the environment for either.
Before commit 71b7efd08a, `GKeyFile`
incorrectly allowed invalid escape sequences: it would treat the
sequence as a literal, set a `GError`, but not return failure from the
function. So if a caller was explicitly checking for returned `GError`s,
they could detect the invalid escape; but if they were just checking the
function’s return value, they’d miss it.
This is not correct use of `GError`, and the [Desktop Entry
Spec](https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s04.html)
doesn’t allow for invalid escape sequences to be accepted. So it’s wrong
in both ways.
However, the commit above changed this behaviour without realising it,
quite close to the 2.78 stable release deadline. There are numerous key
files in the wild which use invalid escape sequences, and it’s too late
in the cycle to ‘break’ parsing of all of them.
So, for now, revert to the old behaviour for invalid escape sequences,
and give people another cycle to adapt to the changes. This will likely
mean they end up calling `g_key_file_get_value()` rather than
`g_key_file_get_string()`. See
https://gitlab.gnome.org/GNOME/glib/-/issues/3098 for tracking
re-enabling the error handling for invalid escape sequences.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Fixes: #3095
See: #3098
