So long, and thanks for everything. We’re a Meson-only shop now.
glib-2-58 will remain the last stable GLib release series which is
buildable using autotools.
We continue to install autoconf macros for autotools-using projects
which depend on GLib; they are stable API.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Calling
g_list_model_get_item (store, 0);
g_list_model_get_item (store, -1u);
does not return NULL for the second call, as it should.
This was showing up in GTK+ list model tests.
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.
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.
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>
g_assert() is for runtime code, and can be compiled out. g_assert_*()
cannot be compiled out, and give more helpful failure messages for
specific types.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
g_assert() can be compiled out with G_DISABLE_ASSERT, which renders the
test useless. The g_assert_*() functions provide more helpful feedback
on failure too.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
By encoding the path to the appinfo-test binary in the .desktop files,
we can avoid a chdir() call in the tests, which was a bit ugly.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/538
This partially reverts commit 27b5fb5892.
The infrastructure for disabling a test is kept, but the appinfo and
desktop-app-info tests no longer need to be run serially.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1601
This checks if the stream is writable before writing
to it. If the write succeeded with no error, then the
stream has to be also writable after the write
As RFC 8305 recommends we can start multiple DNS queries in parallel
to more quickly make an initial response, especially when one is
particularly slow/broken.
This is to ensure that the generated code is still compilable by the
running compiler, and see whether we can read the things in there
properly.
See issue #1580.
Otherwise they fill your real ~/.config/mimeapps.list with rubbish and
race for access to it. This is arguably not good.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1514
With the changes to limit GVariant type nesting (commit 7c4e6e9fbe),
it’s now possible to have a valid type signature which is not a valid
GVariant type when enclosed in parentheses (to make it a tuple).
Check for that when parsing the signature field in a D-Bus message.
Includes a unit test.
oss-fuzz#11120
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This test is intended to verify the fix for
https://bugzilla.gnome.org/show_bug.cgi?id=787731, which was that
g_file_query_filesystem_info() would return stale information for the
mount. After replacing a read-only mount with a read-write mount, this
test used to only fail if G_FILE_ATTRIBUTE_FILESYSTEM_READONLY was TRUE
and yet the file could be opened for writing. In particular, if (due to
a test bug) the file really was still on a read-only filesystem, the
test would pass.
Now that we have fixed that bug in the test, we can make a stronger
assertion.
fusermount -z behaves like umount --lazy, which is documented thus:
> Detach the filesystem from the file hierarchy now, and clean up all
> references to this filesystem as soon as it is not busy anymore.
Without this, the call to `fusermount -u` often fails with:
/usr/bin/fusermount: failed to unmount /home/wjt/src/gnome/glib/_build/dir_bindfs_mountpoint: Device or resource busy
which causes the subsequent call to bindfs to fail:
fuse: mountpoint is not empty
fuse: if you are sure this is safe, use the 'nonempty' mount option
It's not clear what is causing the mount to be busy. Inserting a
g_usleep (100 * 1000) before the calls to `fusermount -u` also works to
make the problem go away, but for the purposes of this test the
important point is that the mount is detached from the directory, for
which a lazy unmount is fine.
Fixes#1590.
In practice, fusermount -u often fails:
/usr/bin/fusermount: failed to unmount /home/wjt/src/gnome/glib/_build/dir_bindfs_mountpoint: Device or resource busy
which causes the subsequent calls to bindfs to fail:
fuse: mountpoint is not empty
fuse: if you are sure this is safe, use the 'nonempty' mount option
This may or may not cause the current test run to fail, but it reliably
causes a repeat run of the test to fail. This change causes the current
run to fail instead.
Currently, GDBusProxy:g-name-owner only notifies changes to the unique
name owner of the remote object in case the proxy was constructed for a
well-known name.
That sounds like an artificial restriction, and it's convenient to
connect to notify::g-name-owner if a proxy instance has already been
created for an unique name, instead of additionally using
g_bus_watch_name() to track the owner.
To fix this, always connect to NameOwnerChanged after the proxy is
initialized, instead of only doing so when the proxy was constructed for
a well-known name.
https://bugzilla.gnome.org/show_bug.cgi?id=791316https://gitlab.gnome.org/GNOME/glib/issues/1310
test_c_args is defined in the root meson.build with unfiltered list of
compiler flags, then redefined in gio/tests/meson.build after the
subdir() call. Move it before.
Similarly to g_source_set_name(), this sets a name on a GTask for
debugging and profiling. Importantly, this name is propagated to the
GSource for idle callbacks for the GTask, ending the glorious reign of
`[gio] complete_in_idle_cb`.
The name can be queried using g_task_get_name(). Locking is avoided by
only allowing the name to be set before the GTask is used from another
thread.
Includes tests.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This is the most degenerate possible test but it does exercise this code
path.
(Tweaked by Philip Withnall <withnall@endlessm.com> to also add the flag
to the autotools build.)
The executable depends only on the generated header file at compile
time, and on the library at link time. So meson can decide to compile
gdbus-peer.c before compiling the library and thus won't have generated
the header yet, causing the build error.
So declare_dependency() should only have the header file in its sources,
to force generating files before compiling gdbus-peer.c without
including objectmanager-gen.c into gdbus-peer's sources.
We use libgdbus_example_objectmanager_dep as dependency for various
tests, but this implies only a link dependency while it doesn't ensure
that the sources are generated.
Make this explicit
Test symlink expansion in find_mountpoint_for() function over
_g_local_file_find_topdir_for(). find_mount_for() is crucial for many
of glocalfile.c functionality (e.g. to determine correct trash location)
and symlink expansion has to work properly.
https://gitlab.gnome.org/GNOME/glib/issues/1522
This introduces no real functional changes (except when compiling with
G_DISABLE_ASSERT, in which case it fixes the test). Mostly just a code
cleanup.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The code was checking whether the signature provided by the blob was a
valid D-Bus signature — but that’s a superset of a valid GVariant type
string, since a D-Bus signature is zero or more complete types. A
GVariant type string is exactly one complete type.
This meant that a D-Bus message with a header field containing a variant
with an empty type signature (for example) could cause a critical
warning in the code parsing it.
Fix that by checking whether the string is a valid type string too.
Unit test included.
oss-fuzz#9810
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Parsing a D-Bus message with the signature field in the message header
of type other than ‘g’ (GVariant type signature) would cause a critical
warning. Instead, we should return a runtime error.
Includes a test.
oss-fuzz#9825
Signed-off-by: Philip Withnall <withnall@endlessm.com>
There were tests for invalid UTF-8 output when asynchronously
communicating with a subprocess, but nothing for synchronous
communication. Add such a test, and refine the code as a result.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
When using glib as a meson subproject on Windows the build currently fails
due to too long paths during the build process. See
https://github.com/mesonbuild/meson/issues/4226 for the upstream bug.
To work around the issue shorten the filenames of the generated gdbus files.
The tests were making assumptions about the order of the returned D-Bus
introspection nodes. However, these are semantically unordered and
changes to e.g. GHashTable would break the tests.
Fix this by applying a sort prior to validation.
This method drops the last reference *it* owns to the GTask, but then
continues to call methods on the GTask. This wasn’t resulting in
failures because a ref in another thread kept the GTask alive, but
that’s quite dodgy.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The X-Flatpak-RenamedFrom key is used in .desktop files to identify past
names for the desktop file. It is defined to be a list of strings.
However, there was previously no correct way to retrieve a list of
strings from the GKeyFile wrapped by GDesktopAppInfo, short of
re-parsing the file with GKeyFile.
Note that doing something like:
g_strsplit (g_desktop_app_info_get_string (...), ";", -1)
is not correct: the raw value "a\;b;" represents the one-element list
["a;b"], but g_key_file_get_string() rejects the sequence "\;", and so
g_desktop_app_info_get_string() returns NULL in this case. (Of course, a
.desktop file with a semicolon in its name is a pathological case.)
Add g_desktop_app_info_get_string_list(), a trivial wrapper around
g_key_file_get_string_list(), similar to g_desktop_app_info_get_string()
and co.
The change from g_key_file_free() to g_key_file_unref() in the test is
needed because g_key_file_free() clears the contents of the keyfile.
This is fine for all the fields which are eagerly loaded and copied into
GDesktopAppInfo, but not when we want to access arbitrary stuff from the
keyfile.
This makes it easier to debug test failures, by ensuring that g_debug()
and g_test_message() are printed as TAP diagnostics.
Fixes: https://gitlab.gnome.org/GNOME/glib/issues/1528
Signed-off-by: Simon McVittie <smcv@collabora.com>
None of these files starts with a #! line, and they are not native
binary executables, so if a user attempts to execute them as a program,
Unix shells will run them as /bin/sh scripts. This is not going to end
well, since none of them are shell scripts (the gio bash completion
is for bash, which is not a lowest-common-denominator POSIX shell, and
in any case is designed to be sourced rather than executed).
Fixes: #1539
Signed-off-by: Simon McVittie <smcv@collabora.com>
These keep on taking just longer than 30s on my local machine when run
in parallel with the rest of the tests (i.e. with `ninja test`). Testing
them individually, they do terminate correctly.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
g_icon_new_for_string() docs states that it should return a single name
when created with a single name. I add a second condition to this case:
the themed icon must not include default fallbacks (i.e. it must not
have been created with `g_themed_icon_new_with_default_fallbacks()`).
Otherwise the return value of `g_icon_new_for_string()` would not
recreate the same icon list when passed to `g_icon_new_for_string()`
(which would be another documentation inconsistency).
g_icon_new_for_string() is now back to old behavior for this specific
case.
I also revert the unit test for this case, and add a new unit test when
using g_themed_icon_new_with_default_fallbacks() with a single name as
well.
Closes#1513.
