Right now this can only be set at construction but not read back.
That seems unnecessarily restrictive, and we'll need to read these
flags from outside of gdbusconnection.c in the next commit, so let's
just make it public.
https://gitlab.gnome.org/GNOME/glib/issues/1620
Add option to not encode resource data into the C source file
in order to embed the data using `ld -b binary`. This improves compilation
times, but can only be done on Linux or other platforms with a
supporting linker.
(Rebased by Philip Withnall, fixing minor rebase conflicts.)
Fixes#1489
This reverts commit 52bab0254a.
It silently conflicted with another commit,
90ca3b4dd0, which was merged later than
it. I’ve kept commit 90ca3b because it also frees the GError; 52bab
doesn’t.
This is my failure to rebase and test old branches before merging them,
instead of assuming that the lack of automatically detected merge
conflicts actually means there are no merge conflicts.
There was no distinction between literals which need to be typed, and
normal words in the prose.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
We need stronger alignment guarantees for the memory allocations done
through g_rc_box_alloc_full(): while the passed block size may be
aligned, we're not aligning the private data size; this means the
overall allocation may become unaligned, and this could raise issues
when we use the private data size as an offset to access the reference
count.
Fixes: #1581
Allow any type of private key in PEM files by treating PEM guards ending
with "PRIVATE KEY-----" as a private key instead of looking for a
pre-defined set of PEM guards. This enables the possibility for custom
GTlsBackend to add support for new key types.
Test cases have been expanded to ensure PEM parsing works for private
key when either header or footer is missing.
Encrypted PKCS#8 is still rejected. Test case has been added for this to
ensure behaviour is the same before and after this change.
It’s not possible for g_build_home_dir() to return NULL. The fallback
code here seems to originate from commit 1607e3f1 in 2005 (bug 169348),
where it was added with the explanation “Guard against g_home_dir being
NULL”.
The XDG Base Directory specification doesn’t have anything to say about
what to do when $HOME is unset:
https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
It’s all a bit moot, though, becaause since commit 9cbfb560
(bug 773435), g_{get,build}_home_dir() cannot return NULL. So just drop
the fallback.
See discussion on
https://gitlab.gnome.org/GNOME/glib/merge_requests/505#note_386109.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The `apps` subprocess is spawned by desktop-app-info to interpret the
forest of .desktop files, and its output is provided on stdout. If debug
output is mixed up with that output, tests which parse the output fail.
Disable the debug output from the subprocess to prevent this.
The new debug output appeared as a result of recent changes to the
desktop file dir monitoring code in gdesktopappinfo.c.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The appinfo-test.desktop file is set up with an Exec= path which points
to the compiled and installed appinfo-test utility. When running the
tests uninstalled, however, this might not be present, which causes
loading appinfo-test.desktop to fail.
Split appinfo-test.desktop in two: keep the existing
appinfo-test.desktop for tests which need to launch appinfo-test, and
add a new appinfo-test-static.desktop for tests which don’t launch
anything (and, for example, just inspect GAppInfo properties).
appinfo-test-static.desktop uses an Exec= line which should always be
present (`true`) so it should never fail to load.
Allow the tests using appinfo-test-static.desktop to be run uninstalled
or installed. Allow the tests using appinfo-test.desktop to be skipped
if loading appinfo-test.desktop fails, which is an indicator that the
test is running uninstalled.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
