This is what’s available in the new Debian Stable, so we can expect it
to be available pretty much everywhere.
Subsequent commits will clean up old workarounds.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The package naming is confusing. It turns out we’ve been installing the
wrong libpcre version for ages, but haven’t noticed because the correct
version has previously been installed on the system by default.
It seems that Debian Bullseye doesn’t have the old libpcre installed by
default, so now we have to fix this package name and make sure it’s
installed in the CI images. Building it as a subproject is a pain.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Previously, the code validated that child objects have a path with the
object manager strictly as a prefix. That doesn’t work in the case where
the object manager’s path is `/`. This case is not recommended, but is
supported.
If the object manager’s path is `/`, validate that child objects’ paths
are not equal to it. If they are equal to it, warn the user rather than
emitting a critical warning, since we can’t expect any users who’ve not
been compliant with the spec to instantly rework their D-Bus APIs.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2500
0.2 was just tagged, which includes a commit from 2018 that fixes a
meson warning which caused the project to fail to build on Windows with
--fatal-meson-warnings enabled.
Emit this when we're about to spawn or DBus activate a GAppInfo. This
allows lauchers to keep the appinfo associated with a startup id.
We use a GVariant to allow for future exansion of the supplied data.
When using g_desktop_app_info_launch_uris_as_manager the "launched"
signal allows to map a desktop-startup-id to a GAppInfo. Make this
possible for DBus activation too.
Since we don't have a PID there we pass a 0. Update the signal
description accordingly.
These should be implemented by loadable IO module libraries, but are not
callable in GLib itself.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2498
This is a partial revert of commit
f378352051, as the previous commits have
silenced the AddressSanitizer warnings for `GContentType`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2310
These just wrap the `__lsan_enable()` and `__lsan_disable()` functions
from the AddressSanitizer client API. They’re useful in situations where
the intended-to-be-leaked memory is being allocated in third-party code,
such as xdgmime. We can’t patch that code to call `g_ignore_leak()`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2310
The function pointer casts silence the compiler and allow the code to
build (and even run in the typical case). However, when building with
control flow integrity checks, the runtime (rightfully) complains about
calling a function via a mismatched function pointer type.
In order to make xdgmime properly relocatable so that unit tests can use
it without it reading and modifying the user’s actual xdgmime files, and
without the need to call setenv() (and get tied up with thread safety
problems), add a xdg_mime_set_dirs() method to allow the dirs to be
overridden. They will still default to the values of $XDG_DATA_HOME and
$XDG_DATA_DIRS.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Allocate an empty cache object, check cache objects for being empty
before using them.
Otherwise the code will re-read cache every 5 seconds, as NULL cache
does not trigger the code that stores mtime, which makes the cache
file appear modified/unloaded permanently.
https://bugzilla.gnome.org/show_bug.cgi?id=735696
Since returning exactly one match has special significance, don't
give up matching before we've found at least 2 types. Also, make
sure that we don't return the same mime type more than once.
Bug 541236.
