When using glib as subproject we are forced to pass glib_dep,
gobject_dep and gio_dep to any build target. If we pass only gio_dep it
will missing include directory for glib and gobject.
Putting the raw URIs in the documentation comments would not link them,
and the ‘%20’s in the URIs were being parsed by gtk-doc as symbol
references. Fix that by using Markdown to format them correctly as
links.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Using `%` indicates that you’re linking to a symbol. In these cases we
wanted some nicely formatted literals, or a link to a specific property.
Use backticks for the literals, and link to the property fully.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Due to the line wrapping, gtk-doc was interpreting this second line as
redefining the @dbus_register documentation.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
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
If a D-Bus interface was annotated with o.fd.DBus.Deprecated, then the
corresponding GObject property, in the common GInterface implemented
by the generated GDBusObjectProxies and GDBusObjectSkeletons, to
access the generated code for the D-Bus interface was not being marked
with G_PARAM_DEPRECATED, even though the gtk-doc snippet had the
'Deprecated: ' tag.
G_PARAM_DEPRECATED is older than gdbus-codegen, 2.26 and 2.30
respectively, hence it can be used unconditionally.
https://gitlab.gnome.org/GNOME/glib/merge_requests/485
If a D-Bus interface has a property that's annotated with
o.fd.DBus.Deprecated, then the corresponding GObject property was not
being marked with G_PARAM_DEPRECATED, even though the gtk-doc snippet
had the 'Deprecated: ' tag.
G_PARAM_DEPRECATED is older than gdbus-codegen, 2.26 and 2.30
respectively, hence it can be used unconditionally.
https://gitlab.gnome.org/GNOME/glib/merge_requests/485
Allowing unsafe rehandshakes used to be required for web compatibility,
but this is no longer a concern in 2018. So there should no longer be
compatibility benefits to calling this function. All it does is make
your TLS connection insecure.
Also, rehandshaking no longer exists at all in TLS 1.3.
At some point (maybe soon!) glib-networking will begin ignoring the
rehandshake mode, so let's deprecate it now.
Let's entirely deprecate calling this function for rehandshaking. The
current documentation is OK, but guarantees defined behavior (to attempt
a rehandshake) when TLS 1.2 is in use. But there's no way to force TLS
1.2, and also no way to check which version of TLS is in use. I really
should have deprecated use of this function for rehandshaking entirely
last time I updated it.
Fortunately, there should be no compatibility risk for existing code,
because rehandshaking has no visible effects at the API level.
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.
I made a mistake when last updating the documentation in 94a99ae9. I
wrote that, with TLS 1.3, this would perform a rekey instead of a
rehandshake. In fact, that's only true for client connections. For
server connections, it's a no-op.
I was a bit nervous about how to document the behavior anyway, because
we really don't know what behavior will be reasonable with non-GnuTLS
crypto backends. This behavior is reasonable for the GnuTLS backend, but
might not necessarily make sense for OpenSSL. Ideally, we would
discourage API users from doing things which could have unexpected
effects, so instead of documenting what the GnuTLS backend does, I think
it'd be better to document that this is "undefined but not dangerous,"
since of course we want to make sure that existing code that doesn't
know about TLS 1.3 is not broken.
The docs sound like settings list is a thing, and
a ::children-changed signal exists. That is not the
case, and will never be the case at this point, so
stop pretending.
Closes: #1362
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.
The length of the stolen data from a memory output stream is given by
get_data_size() — get_size() can be larger, and hence cause unnecessary
overallocation.
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
mntent-based implementation filter out mounts with device path that was
repeated. Consequently, it is not possible to show such mounts in UI even
with x-gvfs-show, because they are not returned from g_unix_mounts_get.
libmount-based implementation currently doesn't filter out any mounts
which causes issues to our volume monitors. Let's rather mark mounts
which don't point into fs root as system_internal. This approach won't be
affected by mount order as is mntent-based implementation. It will mark
more mounts as system_internal than it is filtered out with mntend-based
implementation, but there will be always possibility to show them in UI
over x-gvfs-show, which was not possible with mntend-based. We can
probably introduce some improvements later to not mark unique mounts as
system internal even if they don't point into fs root...
https://gitlab.gnome.org/GNOME/glib/issues/1271
Currently, there isn't API to determine root path for mounts created
over bind operation (or btrfs subvolumes). This causes issues to our
volume monitors if there is multiple mounts for one device, which can
happen with libmount-based implementation currently. Let's propagate
root path from libmount over g_unix_mount_get_root_path, so we can
handle this somehow in our volume monitors.
https://gitlab.gnome.org/GNOME/glib/issues/1271
Currently, readlink() is used only 12 times when expanding symlinks.
However, kernel uses 40 for this purpose and it is defined as MAXSYMLINKS.
Use that constant if available, or 40. See:
https://github.com/torvalds/linux/include/linux/namei.h.
find_mountpoint_for() uses current file in case of error, because
get_parent() returns NULL for error, but also if parent doesn't exist.
Return "." from get_parent() if parent doesn't exist in order to
differentiate the error state.
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
These were callers which explicitly specified the string length to
g_utf8_validate(), when it couldn’t be negative, and hence should be
able to unconditionally benefit from the increased string handling
length.
At least one call site would have previously silently changed behaviour
if called with strings longer than G_MAXSSIZE in length.
Another call site was passing strlen(string) to g_utf8_validate(), which
seems pointless: just pass -1 instead, and let g_utf8_validate()
calculate the string length. Its behaviour on embedded nul bytes
wouldn’t change, as strlen() stops at the first one.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
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>
G_FILE_ATTRIBUTE_ACCESS_CAN_TRASH can be set to a wrong value if
its parent dir is a symlink. This is because the find_mountpoint_for()
function tries to find mountpoint for a filepath and expands symlinks
only in parent dirs. But in this case the path is already parent dir
and needs to be expanded first...
Closes: https://gitlab.gnome.org/GNOME/glib/issues/1522
Fedora is using https://fedoraproject.org/wiki/Changes/Annobin
to try to ensure that all objects are built with hardening flags.
Pass down `CFLAGS` to ensure the SystemTap objects use them.
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>
Instead of sometimes returning a non-NULL buffer, always return NULL.
However, keep the documentation as explicitly returning undefined values
on failure, so that we can change the behaviour in future if needed.
The return values weren’t defined for failure before, so were
implicitly returning undefined values.
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.
There are a lot of gbooleans in the private GTask struct, which seems a
bit wasteful. Use a bitfield to compress the struct a bit.
This reduces the size of the struct from 216 bytes to 168 bytes on my
64-bit machine.
One of the fields needs to remain separate, since it’s used from a
TRACE() macro which calls typeof() on it.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
These functions already check to see if a successful result has already
been returned; expand them to also check to see if an error has been
returned.
We can’t just check GTask.result_set, as that’s actually an indicator
for whether the GTask.result member is filled — when
g_task_propagate_*() is called, it’s cleared again. We need a new state
bit.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1525
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 avoids the convenience library being treated as though it was
an installed static library (objects not included in the dependent
static library, and convenience library being listed in the pkg-config
metadata), both of which would make static linking impossible.
This is a workaround for meson not having
https://github.com/mesonbuild/meson/pull/3939 merged yet.
Fixes: https://gitlab.gnome.org/GNOME/glib/issues/1536
Signed-off-by: Simon McVittie <smcv@collabora.com>
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.
Currently this function calls `g_warning()` explicitly. It would be
nicer to properly propagate these failure up to the caller that tried to
initialise us.
`read_netlink_messages()` is the callback attached to the netlink socket
(G_IO_IN). It calls `g_socket_receive_message()`. There is a race
condition that if the socket is closed while there is a pending call, we
will try to receive on a closed socket, which fails.
To avoid this, we switch the order of the operations around: first
destroy the source and then close the socket.
This is not a correct way to check if `g_socket_new_from_fd()` failed.
Instead just see if it returned `NULL` itself.
This was preventing the netlink monitor from being initialised.
Closes#1518
All the other initialisation failure paths set a GError, but this one
didn’t. Set a GError to avoid breaking the invariant that returning
FALSE should always have a GError set.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1523
This is a speculative fix for epiphany#533, which we think might be
caused by xdg-desktop-portal not ever being started. This service is
started on-demand, not automatically.
1) Remove the non-Windows-only condition for subdir('tests').
2) Add libiphlpapi, libws2_32 and libsecur32 deps, needed for W32 tests.
3) Remove the -no-undefined argument (gcc doesn't understand it,
it *does* understand -Wl,-no-undefined; either way, the test
compiles without this argument just fine; maybe meson adds it
by itself - you can hardly build shared modules without it).
4) Add or fix a number of includes
5) Disable gdbus-objectmanager tests when building with MSVC
(right now these tests don't work on Windows anyway, so the fact
that MSVC can't even build them properly is irrelevant;
most likely gdbus-codegen needs changes to put _GLIB_EXTERN
before each function)
G_FILE_ATTRIBUTE_DOS_IS_MOUNTPOINT allows mountpoints
(NTFS reparse points with IO_REPARSE_TAG_MOUNT_POINT tag) to
be told apart from symlinks (NTFS reparse points with
IO_REPARSE_TAG_SYMLINK tag), even though both are reported
by glib as "symlinks".
G_FILE_ATTRIBUTE_DOS_REPARSE_POINT_TAG allows the exact
reparse tag value to be obtained by the user. This way
even more exotic reparse points can be identified and
handled by the user (glib itself currently has no code
to work with any reparse points that are not symlinks
or mountpoints).
The existing code was generating code with undefined results that modern compilers warn about:
accounts-generated.c:204:23: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
(GDBusArgInfo **) &_accounts_accounts_method_info_list_cached_users_OUT_ARG_pointers,
It wasn’t being tested. It should behave the same as
g_list_model_get_item(), so write a wrapper for the two.
This brings the code coverage of glistmodel.c up to 100%.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
When setting the GListStore:item-type property we need to check the
GType is a GObject (or subclass). There was some explicit code for this,
but when actually testing it and looking at the code coverage, it turns
out that the GObject property type check coming from
g_param_spec_gtype() does everything we want, and the custom
g_critical() can never be hit. So turn it into an assertion.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This is also faster, though I doubt anyone's able to measure it.
The previous code was a more complicted way to do the same thing and it
was likely written the more complicated way because it fell out commit
758d7073a9 when fixing
https://bugzilla.gnome.org/show_bug.cgi?id=795307
There are many cases where a default TLS database is not able to be
defined within the constraints of a system. For example glib-networking
(or glib-openssl) cannot retrieve the default certificate store on iOS
or Android and need to be initialized from a cert file of certificates
bundled with the application.
Previously GStreamer was relying on a custom patch to glib-networking to
populate the default database from the file pointed to by the
CA_CERTIFICATES environment variable however the mechanism that enabled
this was recently remove from glib-networking.
Adding a more generic g_tls_backend_set_default_database() API allows
application developers to override the default database using their own
certificates as well as allowing equivalent functionality on Android/iOS
(or others) as on the default database handling Linux.
Fixes https://gitlab.gnome.org/GNOME/glib-networking/issues/35
The ::network-changed signal is documented to indicate any change in
network configuration, which doesn't necessarily imply a property
change - additional services becoming available after connecting to
a VPN comes to mind for instance.
In order to match the "native" network monitor's behavior, always
emit the signal when it's in response to the 'changed' D-Bus signal.
Also emit the signal unconditionally when loading the initial property
values, to allow clients to differentiate between "offline" meaning
"offline" and "offline" meaning "uninitialized".
With 0d685b4946, we now encode resource
data as a string. Strings have trailing nul terminators. A C compiler
will happily ignore the fact that the nul terminator exceeds the stated
array length, and will drop it — but a C++ compiler won’t, and will
raise:
error: initializer-string for array of chars is too long [-fpermissive]
Fix that by increasing the array length by 1, and subtracting it again
in the GStaticResource struct.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This reverts commit 3c1902fcf9.
This was accidentally re-added from an old version of the branch before
!265 was merged. It should not have been re-added.
Rearrange the code so we try version 3 first,
falling back to version 2 and then version 1.
We still do a construct-time check to ensure
that we work with unsupported versions.
Note that this also takes care of setting the
initial property values in the version 1 case.
Version 3 of the network monitor portal interface adds
a CanReach method. Use it to implement can_reach.
The docs state that can_reach will either return TRUE
or set an error. So, set an error of G_IO_ERROR_HOST_UNREACHABLE
when the portal returns FALSE for CanReach.
GSettings XML schema files are installed in a well known directory
under Glib's installation directory: `glib-2.0/schemas`. However,
the Glib installation directory might vary, so the exact location of
the schema files might be unknown.
The information regarding this directory has been added to GIO's
pkg-config file, so it can be checked, and also overrided, by using
the command line utility.
The source callback for a GCancellable should have the cancellable itself
as first argument.
This was not the case, and when this code was hit, we were instead trying
to treat the pointer as a CommunicateState reference and thus wrongly
deferencing it, causing a memory error and a crash.
Some Testing revealed encoding resource data with string
escape codes to compile significantly quicker compared
to the same data encoded as an array with hexadecimal numbers.
See #1489
This is a follow-up to commit 614adf8a75,
which started generating two new files as part of the test; they need to
be cleaned up before distcheck will pass.
Ideally, the test should run a temporary directory and wipe that
directory itself before exiting, but that’s a bit of a big change to
make right now. Deferred to
https://gitlab.gnome.org/GNOME/glib/issues/1495.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
In file gio/gtestdbus.c, function watch_parent, there is a loop which
waits for commands sent from the parent process and kills all processes
recorded in 'pids_to_kill' array on parent process exit. The detection
of parent process exit is done by calling g_poll and checking whether
the returned event is G_IO_HUP. However, 'revents' is a bit mask, and
we should use a bitwise-AND check instead of the equality check here.
It seems to work fine on Linux, but it fails on FreeBSD because the
g_poll returns both G_IO_IN and G_IO_HUP on pipe close. This means the
watcher process continues waiting for commands after the parent process
exit, and g_io_channel_read_line returns G_IO_STATUS_EOF with 'command'
set to NULL. Then the watcher process crashes with segfault when calling
sscanf because 'command' is NULL. Since the test result is already
reported by the parent process as 'OK', this kind of crash is likely to
be unnoticed unless someone checks dmesg messages after the test:
pid 57611 (defaultvalue), uid 1001: exited on signal 11
pid 57935 (actions), uid 1001: exited on signal 11
pid 57945 (gdbus-bz627724), uid 1001: exited on signal 11
pid 57952 (gdbus-connection), uid 1001: exited on signal 11
pid 57970 (gdbus-connection-lo), uid 1001: exited on signal 11
pid 57976 (gdbus-connection-sl), uid 1001: exited on signal 11
pid 58039 (gdbus-exit-on-close), uid 1001: exited on signal 11
pid 58043 (gdbus-exit-on-close), uid 1001: exited on signal 11
pid 58047 (gdbus-exit-on-close), uid 1001: exited on signal 11
pid 58051 (gdbus-exit-on-close), uid 1001: exited on signal 11
pid 58055 (gdbus-export), uid 1001: exited on signal 11
pid 58059 (gdbus-introspection), uid 1001: exited on signal 11
pid 58065 (gdbus-names), uid 1001: exited on signal 11
pid 58071 (gdbus-proxy), uid 1001: exited on signal 11
pid 58079 (gdbus-proxy-threads), uid 1001: exited on signal 11
pid 58083 (gdbus-proxy-well-kn), uid 1001: exited on signal 11
pid 58091 (gdbus-test-codegen), uid 1001: exited on signal 11
pid 58095 (gdbus-threading), uid 1001: exited on signal 11
pid 58104 (gmenumodel), uid 1001: exited on signal 11
pid 58108 (gnotification), uid 1001: exited on signal 11
pid 58112 (gdbus-test-codegen-), uid 1001: exited on signal 11
pid 58116 (gapplication), uid 1001: exited on signal 11
pid 58132 (dbus-appinfo), uid 1001: exited on signal 11
If the watcher process crashes before killing the dbus-daemon process
spawned by the parent process, the dbus-daemon process will keep running
after all tests complete. Due to the implementation of 'communicate'
function in Python subprocess, it causes meson to crash. 'communicate'
assumes the stdout and stderr pipes are closed when the child process
exits, but it is not true if processes forked by the child process
doesn't exit. It causes Python subprocess 'communicate' function to
block on the call to poll until the timeout expires even if the test
finishes in a few seconds. Meson assumes the timeout exception always
means the test is still running. It calls 'communicate' again and
crashes because pipes no longer exist.
https://gitlab.gnome.org/Infrastructure/GitLab/issues/286https://github.com/mesonbuild/meson/issues/3967https://bugs.python.org/issue30154
Previously, glocalfile.c would not set file system metadata for
the free/used key for file systems which reported 0 free space. This is
because some file systems don’t set that metadata when you call
statfs(), so we can’t reliably report it. However, some do, and they
can legitimately set f_bavail and f_bfree to 0 if the file system is
full.
In order to avoid that, always set the file system metadata unless the
file system is FUSE or ncpfs.
This is a partial revert of commit 0b9f24c1e1: instead of the changes
made in that commit, I think we should maintain a blacklist of file
systems which are known to not correctly report free space.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/328
Similar issue was fixed with commit f929d148, but it's happening again.
Define G_MESSAGES_DEBUG=all when running CI to ensure we won't regress
anymore.
In order to determine whether to trash a file to the home directory, we
compare its st_dev to our home directory's st_dev field.
This is the wrong thing to do on overlayfs when deleting files, because
st_dev contains the ID of the filesystem providing the file (which can
be the lower or upper filesystem), but directories always return the ID
of the overlayfs. Thus the comparison fails and we are unable to trash
the file.
Fix this by checking st_dev of the parent directory when we are deleting
a file.
Also adjust `test_trash_not_supported` for this - make its st_dev check
look at the parent directory's `st_dev` rather than the temporary file's
own.
Fixes#1027.
The documentation was unclear about what error codes would be returned
on attempting to open an empty or corrupt GVDB file. Previous versions
of the documentation incorrectly said that corrupt GVDB files were
considered equivalent to empty ones.
A recent commit has clarified the documentation to include its error
handling behaviour.
Update the two users of GVDB within GLib, GResource and GSettingsSource,
to follow this change, and add unit tests for them both.
Other users of the GVDB copylib will need to update their copy and make
appropriate changes if they have bugs in their handling of this
situation. dconf is one example of this. GVDB should be updated from
https://gitlab.gnome.org/GNOME/gvdb.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1454
While mountpoints are *not* symlinks, strictly speaking,
they works in a similar enough way, so consider them to be
symlinks for the purpose of querying local file info.
On Windows st_ctime field is the file creation time.
POSIX mandates that field to be the file state change time.
Naturally, glib code interpreted st_ctime as POSIX suggested,
and the result was bad.
Fix this by introducing special W32-only logic for setting
attributes from st_ctime field.
Fixes issue #1452.
We now send the fallback SCSV, meaning use of this function will cause
modern servers to immediately terminate the connection, so let's warn
API users to expect that behavior and be crystal clear that this
function should only be used as a fallback when a normal connection
attempt has already failed.
Also, the documentation is mostly duplicated between the property and
the function, so let's just reference the function documentation from
the property.
7efd76dd67 added these configure time tests to work around a bug
with older Android. Since the test didn't take Windows into account it
wrongfully applied the workaround on Windows too, breaking the build.
With meson this wasn't an issue since the check is skipped on Windows there
and our CI didn't catch this issue.
Change the test to run on Android only for meson and autotools.
This also makes it clear that the test+code can be dropped again if we stop
supporting older Android versions at some point.
GLib currently tries to use FAM volume monitor for monitoring files
within home on NFS. If FAM support is not available, it fallbacks by
default to GInotifyFileMonitor. I think we should fallback to
GPollFileMonitor instead, because inotify is not reliable on NFS,
which may cause issues for dconf. With this patch, it should be safe to
not build libgiofam and still be sure that dconf works properly if home
is mounted on NFS. I think this might be a first step to remove FAM
support from GLib completely, because gamin is buggy and dead for
several years already. Gamin just polls files on NFS anyway. This
change applies on files only, because GPollFileMonitor seems doesn't
support dirs, however it should be enough for dconf. The other
drawback is that one can't set poll timeout currently. Just a note
that this can still be overwritten by GIO_USE_FILE_MONITOR.
Releasing GVolumeMonitor before g_volume_mount finish cause that
g_volume_get_mount returns NULL, because the mount is not correctly
propagated to the volume.
https://gitlab.gnome.org/GNOME/glib/issues/1458
The gresource code uses libelf if available but that also depends on mmap but isn't
guarded with HAVE_MMAP. This can make the build fail under MSYS2 where a mingw version
of libelf exists but there is no mmap.
Instead of guarting the libelf code with HAVE_LIBELF add a new macro named USE_LIBELF
which is only defined if libelf and mmap support are available.
Also install the mingw libelf version for CI so we catch similar errors in the future.
It is a bug if we distribute files which are generated at build time —
they should be built on the machine which is compiling GLib, not be
shipped in the tarball.
This brings the autotools-generated tarball in line with the
ninja-generated one, with the exception of man pages and gtk-doc HTML
output.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The documentation claims that g_volume_get_mount should succeed after
g_volume_mount. Let's update mounts before releasing g_volume_mount to
be sure that the mount is added to the corresponding volume. The same
is done in GVfsUDisks2VolumeMonitor.
https://gitlab.gnome.org/GNOME/glib/issues/1458
The network monitor portal interface is changing.
Version 2 is no longer using properties, but getters
instead (this lets the portal apply access control
and avoid sending information to non-networked
sandboxes).
To support both version 1 and 2 of the interface,
we stop using generated code and instead deal with
the api differences in our own code, which is not
too difficult.
Support version 1 as well
