Since it’s deprecated in favour of positional arguments, including it in
the help output is confusing.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795304
These generate basic .c and .h files containing the GDBusInterfaceInfo
for a D-Bus introspection XML file, but no other code (no skeletons,
proxies, GObjects, etc.).
This is useful for projects who want to describe their D-Bus interfaces
using introspection XML, but who wish to implement the interfaces
manually (for various reasons, typically because the skeletons generated
by gdbus-codegen are too simplistic and limiting). Previously, these
projects would have had to write the GDBusInterfaceInfo manually, which
is painstaking and error-prone.
The new --interface-info-[body|header] options are very similar to
--[body|header], but mutually exclusive with them.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795304
Recursive annotations do seem to be supported, so we should support them
properly in the type system representation. This currently introduces no
behavioural changes, but will be used in upcoming commits.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795304
This is to avoid race between dispose() being called on the
GFdoNotificationBackend instance, and any pending operations which are
still waiting on a D-Bus reply when it’s disposed.
(thx to Philip Withnall for pointing that out)
Signed-off-by: Arnaud Rebillout <elboulangero@gmail.com>
The basic test for duplicate icon names was not working fine when taking
into account fallbacks and icon style mix. This fixes it.
Also resolve the few review comments, i.e.: comment explaining
g_themed_icon_update_names() and the priority order applied to icons;
and using guint for 'i'.
Previously, calling:
g_dbus_is_supported_address ("some-imaginary-transport:", NULL)
correctly returned FALSE; but calling:
g_dbus_is_supported_address ("some-imaginary-transport:", &error)
crashed with:
GLib-GIO:ERROR:../gio/gdbusaddress.c:434:g_dbus_is_supported_address:
assertion failed: (ret || (!ret && (error == NULL || *error != NULL)))
This was because, if the address component did not start with a known
transport, no error was set. Fix this, reusing an error string used by
the corresponding else branch in g_dbus_address_connect(), and adjust
the test to pass both NULL and non-NULL GError **s to this function in
every test case. This case:
g_assert (!g_dbus_is_supported_address ("some-imaginary-transport:foo=bar;unix:path=/this/is/valid", NULL));
would have caught this bug with a non-NULL GError **.
The way things were before: a FreedesktopNotification struct is
allocated before the dbus call, and this same struct is possibly re-used
for other dbus calls. If the server becomes unavailable, the callback
will be invoked after the call times out, which leaves a long time where
other dbus calls can happen, re-using the same FreedesktopNotification
as user data. When the first call times out, the callback is invoked,
and the user data is freed. Subsequent calls that used the same user
data will time out later on, and try to free a pointer that was already
freed, hence segfaults.
This bug can be reproduced in Cinnamon 3.6.7, as mentioned in:
<https://github.com/linuxmint/Cinnamon/issues/7491>
This commit fixes that by always allocating a new
FreedesktopNotification before invoking dbus_call(), ensuring that the
callback always have a valid user data.
Signed-off-by: Arnaud Rebillout <elboulangero@gmail.com>
Use a GOnce to make sure we only warn about notifications not being
supported on Windows once, rather than on each attempted notification.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: https://gitlab.gnome.org/GNOME/glib/issues/1234
On an Android build, API 22, at least, I got a:
> warning: "UNIX_PATH_MAX" redefined
We were currently defining it as:
> #define UNIX_PATH_MAX sizeof (((struct sockaddr_un *) 0)->sun_path)
Whereas Android's headers define this variable of sockaddr_un as:
> char sun_path[UNIX_PATH_MAX];
So by definition, we will still get the right result in the end by just
using the original value of UNIX_PATH_MAX.
C_IN macro was added years ago in bcbaf1bef0, using same value as the
internal code of Android with the reasonning that "some parts of the API
used by the resolver objects is not public in the Android NDK (yet)".
Well since then things are changed, since it is definitely available (at
least on the API 22 of Android which I am using) in the public header
arpa/nameser_compat.h.
Let's just add a #ifndef to handle both cases when you build with an
older or recent API.
Meson has the ability to classify tests according to "suites", a list of
tags. This is especially useful when we want to run specific sets of
tests — e.g. only GLib's tests — instead of the whole test suite. It
also allows us to classify special tests, like "slow" ones, so that we
can only run them when needed.
FIONREAD ioctl on Linux reports the size of payload on UDP sockets.
However, other systems usually add internal header size to the reported
size, which vary between different operating systems and socket types.
To make it work on more systems, we should follow what we do on Windows
instead of using this unreliable FIONREAD ioctl.
This fixes socket test on FreeBSD.
libelf, just like libc, is not a single project. It is an interface
which can be implemented independently by different operating systems.
Therefore, we cannot expect all systems to provide a .pc file, and we
should fallback to cc.find_library and cc.has_function like what we
already do in autotools build.
Non-glibc gettext implementation seems to decide the language from
LC_MESSAGES environment variable instead of LC_MESSAGES locale, so
we should set both environment variable and locale when running tests
which need translation from specific languages.
G_IO_ERROR_NOT_SUPPORTED is used as parameter for g_set_io_error(),
however, errno is expected instead and thus error code is set to 0,
which is wrong. Let's use ENOTSUP instead.
To be honest, I am not sure why, but in some special environments (e.g.
our CI integration) can happen, that file device number is different from
parent device number. Return "Unable to find or create trash directory for
%s" error from g_local_file_trash() in that case and also set
G_FILE_ATTRIBUTE_ACCESS_CAN_TRASH appropriately.
Make the --help output more consistent with the man page, making it more
obvious that --sourcedir only applies to the files referenced in FILE,
not to the location of FILE itself.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1406
Change G_FILE_ATTRIBUTE_ACCESS_CAN_TRASH logic to be consistent
with recent g_local_file_trash changes, i.e. set this to FALSE for
locations on system-internal mounts.
https://gitlab.gnome.org/GNOME/glib/issues/251
New bugs appears periodically in nautilus/gvfs/glib components that not
all trashed files are shown in trash:///. It used to be problem mostly
for "bind mounts" and btrfs subvolumes only. Currently, it is also
problem for nfs, cifs and other filesystems, which have been recently
added by commmit 0d69462f on the list of system internal filesystems.
This happens because the trash backend doesn't monitor files on system
internal mounts. Such behavior is not against the trash-spec, however,
we should be consistent within GNOME.
This behavior has the nice side-effect that it solves issues with hangs
on network filesystems: https://gitlab.gnome.org/GNOME/glib/issues/605,
because those are currently on the system internal filesystem list.
https://gitlab.gnome.org/GNOME/glib/issues/251
Main changes were:
- take into account that style variants are added to the list of icon
names.
- In the test of icons set with 3 names ("first", "testicon" and
"last"), I also changed "first" to "first-symbolic" so that we can
test in such a case that the variant is the regular icon (only for
this name, out of the 3).
- Finally icon hashes are necessarily changed, and since emblems are
sorted by their hash in emblem icons, I had to invert an order which
was now different in one of the tests.
... a theme icon.
Otherwise fallbacks of the added icon name are not added to the list (if
use-default-fallbacks is set), nor is the regular/symbolic variant. Also
if we do not recreate the finale list from scratch, sorting of icons and
their variants may end up wrong.
To this end, let's keep around the icon names used for initialization,
separate from the finale name list.
When a themed icon is constructed with several input icon names, add the
variants (symbolic as well as level fallbacks) for every icon names, not
only the first one.
The search order is: first icon name, then its level fallbacks, then
second icon name, then its level fallbacks, then all style variants
(symbolic or regular, opposite to requested style) keeping the same
order again.
This fixes the contenttype GIO unit test.
Whatever the preferred icon style is (symbolic, regular or the requested
style), fallbacking to the other style in case of absent variant is
better than not finding any icon at all.
Also style fallbacking should be managed separately from property
"use-default-fallbacks". Default fallbacks are meant for the process of
getting up in context levels (as separated by dashes in icon name). Even
though it also uses dash characters in format, this is a different
concept as the variant of styles.
Without this commit for instance, if an icon only had a symbolic
variant, and the theme had "-gtk-icon-style" set to "regular" while your
GTK+ application requested the regular icon name, you were getting no
icons, and the application would look completely broken.
Now one would at least fallback to the symbolic icon as last resort
(which is infinitely better than having no icons).
Autoconf macro AC_HEADER_MAJOR doesn't define a macro in config.h when
major is defined in sys/types.h. This was not a problem because major
is assumed to be always available. However, commit aefffa3fbc
changes this assumption in order to fix build on systems without major,
which causes code using major to be disabled on systems putting major
in sys/types.h.
This commit defines a new macro MAJOR_IN_TYPES for both autotools and
meson builds to make major useful on these systems again.
gio-querymodules-wrapper.py is copied from glib-networking. This python
wrapper script is needed because meson.build cannot check for DESTDIR
env variable itself, unlike Makefile.am. It is used to update
giomodule.cache file when installing GIO modules like fam.
The previously implementation considered a file to be a mountpoint if
its parent is on a different device. / is its own parent, so by this
definition it is not a mountpoint.
But / is (generally) listed in fstab, and fstab(5) defines the
directories it contains to be mountpoints. This attribute should follow
that definition (and reasonable expectation): the root directory is a
mountpoint.
So, add a special-case for the case where the file's parent has the same
st_dev and st_ino as the file, which is true only at the root.
Test this attribute at / (only on POSIX), /proc (but only on Linux), and
at many files and directories created by the test suite (which cannot be
mountpoints).
Sometimes file monitor events may be slow to emit. Using g_idle_add
makes it less possible for events to be scheduled later than the main
loop quit, preventing test failure caused by missing events.
This fixes test failure on FreeBSD.
The check in _ke_is_excluded, which causes GKqueueFileMonitor to
fallback to GPollFileMonitor when it returns TRUE, was made to prevent
file monitor from blocking unmount of removable drives on systems not
supporting O_EVTONLY flag in open. However, since g_mount_can_unmount
always returns TRUE on Unix-like platforms, the check always returns
TRUE on non-standard mount points, which is very likely to cause all
programs on the desktop to use the polling fallback if GNOME is
installed in a different prefix for development. This makes the desktop
sluggish and results in bad developer experience on *BSD.
Kqueue isn't good at detecting rapid file creation and deletion. It
tends to miss events because events returned by the kernel don't include
filename information. Since the size of struct kevent is fixed, it is
probably not possible to extend the API to include file names without
breaking ABI. Therefore, we disables the test here to avoid test failure
that is impossible to fix in a reliable way.
The test 'file' uses non-standard '--bytes' option when running du,
which may cause error on non-GNU systems. To keep the test working,
we skips the du check as if we don't find a du command when du fails.
-export-dynamic is a libtool flag. It is also supported by GCC as an
undocumented flag, but it is not supported by Clang. Since we don't use
libtool in meson, we should use -Wl,--export-dynamic instead.
In master, it is already possible to build GLib using Visual Studio
using Meson[1] for some time, so we should focus on maintaining only the
Meson build files for building GLib with Visual Studio.
[1]: There are caveats when building with Visual Studio 2008, namely
that one needs to use the mt command to embed the manifests that
are generated with the .exe/DLLs, for all builds, and that in the
case where the compilation hangs on Visual Studio 2008 x64, as a
workaround, should stop the build by terminating all cl.exe tasks
and change the compiler optimization flag from /O2 (full speed) to
/O1 (optimize for size), due to compiler optimization issues.
Change G_FILE_ATTRIBUTE_ACCESS_CAN_TRASH logic to be consistent
with recent g_local_file_trash changes, i.e. set this to FALSE for
locations on system-internal mounts.
https://gitlab.gnome.org/GNOME/glib/issues/251
New bugs appears periodically in nautilus/gvfs/glib components that not
all trashed files are shown in trash:///. It used to be problem mostly
for "bind mounts" and btrfs subvolumes only. Currently, it is also
problem for nfs, cifs and other filesystems, which have been recently
added by commmit 0d69462f on the list of system internal filesystems.
This happens because the trash backend doesn't monitor files on system
internal mounts. Such behavior is not against the trash-spec, however,
we should be consistent within GNOME.
This behavior has the nice side-effect that it solves issues with hangs
on network filesystems: https://gitlab.gnome.org/GNOME/glib/issues/605,
because those are currently on the system internal filesystem list.
https://gitlab.gnome.org/GNOME/glib/issues/251
This test assumes the subprocess does not print anything else on stdout
other than the dbus address, otherwise g_test_trap_assert_stdout()
fails to match. But if the env running tests has G_MESSAGES_DEBUG=all
then it will also print "PATH=%s".
It's a synonym of G_VOLUME_IDENTIFIER_KIND_UNIX_DEVICE.
It doesn't change anything except not feeling dirty from using a wrongly
prefixed constant for the object type.
See: #182
Help is usually printed from tools if no arguments are given and there
is not default action. However "gio mount" and "gio trash" just silently
return. Let's print "No locations given" error and show help consistently.
"gio help COMMAND" shows some arguments with "..." and some with "…",
which looks weird, e.g.:
$ gio help mount
gio mount [OPTION…] [LOCATION...]
Let's use "…" consitently.
- Compiler checks were failing because it were using C compiler to build
objc code.
- xdgmime is needed on osx too.
- -DGIO_COMPILATION must be passed to objc compiler too.
- gapplication doesn't build on osx, it is excluded in autotools too.
We have to be careful when we use add_project_link_arguments(): All
targets are built using link arguments for the C language, except for
libgio on osx which use the objc language, because it contains some ".m"
source files. See https://github.com/mesonbuild/meson/issues/3585.
https://bugzilla.gnome.org/show_bug.cgi?id=796214
Those files got renamed to .c to work around an automake issue, but
Meson needs them to have .m extension. Better rename them at build time
in Makefile.am since that's where the workaround is needed.
https://bugzilla.gnome.org/show_bug.cgi?id=672777
Fixes this build error on macOS when inside an ssh terminal:
Traceback (most recent call last):
File "[...]/gio/tests/gengiotypefuncs.py", line 23, in <module>
for line in f:
File "[...]/lib/python3.6/encodings/ascii.py", line 26, in decode
return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 2625: ordinal not in range(128)
https://bugzilla.gnome.org/show_bug.cgi?id=796328
GVfsUDisks2VolumeMonitor handles x-gvfs-hide/x-gvfs-show mount options
used to overwrite our heuristics whether the mount should be shown, or
hidden. Unfortunately, it works currently only for mounts with
corresponding fstab entries, because the options are read over
g_unix_mount_point_get_options. Let's introduce g_unix_mount_get_options
to allow reading of the options for all sort of mounts (e.g. created
over pam_mount, or manually mounted).
(Minor fixes to the documentation by Philip Withnall
<withnall@endlessm.com>.)
https://bugzilla.gnome.org/show_bug.cgi?id=668132
On non-glibc platforms gettext is provided by extra libintl dependency.
We wrongly thought libintl is an internal dependency and applications
needs to explicitly link on it, but turns out that breaks many
applications and with autotools the .pc generated actually has -lintl in
public "Libs:".
https://bugzilla.gnome.org/show_bug.cgi?id=796085
-z nodelete breaks the libresourceplugin module usage in the resources.c
test, which expects to be able to unload it.
Make the Meson build match what the autotools build does: only pass
glib_link_flags to the headline libraries (glib-2.0, gio-2.0,
gobject-2.0, gthread-2.0, gmodule-2.0) and omit it from all other build
targets.
https://bugzilla.gnome.org/show_bug.cgi?id=788771
gioenumtypes needs to be generated:
In file included from ../../../../external/glib/gio/kqueue/gkqueuefilemonitor.c:37:
In file included from ../../../../external/./glib/gio/glocalfilemonitor.h:25:
In file included from ../../../../external/./glib/gio/gunixmounts.h:24:
../../../../external/./glib/gio/gio.h:86:10: fatal error: 'gio/gioenumtypes.h' file not found
#include <gio/gioenumtypes.h>
^~~~~~~~~~~~~~~~~~~~
https://bugzilla.gnome.org/show_bug.cgi?id=794325
It inserted the new items one position after the given one and inserted all new items
at the same position resulting in the items being in the reverse order of the
input array.
It was decided to make these behavioural changes because this function has according to
https://codesearch.debian.net/search?q=g_list_store_splice only one real user (nautilus)
and it didn't do what one would expect from reading the documentation.
https://bugzilla.gnome.org/show_bug.cgi?id=795307
All those logging functions already add a newline to any message they
print, so there’s no need to add a trailing newline in the message
passed to them.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
The monitor_path comes from g_file_get_path(), so should be freed with
g_free() rather than free(). This makes no difference because they are
the same function in practice, but using free() is a bit confusing.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
This continues one of the const-correctness fixes from the previous
commit (it needed some more transitive fixes), and reverts another of
them, since it was over-zealous.
This fixes CI failure: https://gitlab.gnome.org/GNOME/glib/-/jobs/27125.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
Spotted when temporarily compiling with -Wwrite-strings. This only goes
a small way towards making the code base -Wwrite-strings–clean. It
introduces no functional changes, and fixes no bugs.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
This fix undefined symbol link error when building for non-glibc
platform. Applications must link on libintl, it is not a public
dependency of libglib.
On glibc platforms libintl is a not found dependency and is just ignored
by meson, so it doesn't hurt to always have it.
https://bugzilla.gnome.org/show_bug.cgi?id=795406
Fix various warnings regarding unused variables, duplicated
branches etc by adjusting the ifdeffery and some missing casts.
gnulib triggers -Wduplicated-branches in one of the copied files,
disable as that just makes updating the code harder.
The warning indicating missing features are made none fatal through
pragmas. They still show but don't abort the build.
https://bugzilla.gnome.org/show_bug.cgi?id=793729
Make it a bit more obvious that the changed properties are provided as
an a{sv}.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
g_desktop_app_info_load_from_keyfile() refuses to load .desktop files
where the executable doesn't exist. Therefore whether or not the .desktop
file added in commit 148995544 is actually considered during tests depends
on /usr/bin/flatpak being installed. This isn't a safe assumption to make,
so use /bin/sh to test filtering of "prefix" commands.
https://bugzilla.gnome.org/show_bug.cgi?id=795488
The executable name can be a useful bit of information to match on in
searches where it differs from the name (for example because the latter
is localised), but will produce surprising results where the real appli-
cation is executed by a shared binary (for example interpretors like
gjs or python, or sandboxes like flatpak).
Address this by adding a blacklist of binary names that are ignored
in search.
https://bugzilla.gnome.org/show_bug.cgi?id=795488
Removing the event and closing the related file descriptor must be
done first to make sure the kqueue subsystem delete pending events.
The timeout must be disarmed before freeing the directory dependency
list otherwise it might populate it again.
https://bugzilla.gnome.org/show_bug.cgi?id=795193
This makes it a bit easier for debugging which files were generated from
which introspection XML.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=650875
Add a test for monitoring an existing local file, with the
WATCH_HARD_LINKS flag specified. This would previously cause a crash;
now it doesn’t.
This test contains a FIXME where I suspect we should be getting some
additional file change notifications from changes made through the hard
link; this requires further follow up and probably further fixes to our
inotify backend.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=755721
This gets the G_FILE_MONITOR_WATCH_HARD_LINKS flag to the state where it
doesn’t cause crashes, and essentially acts as a no-op. It will not yet
actually monitor for changes made via hard links.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=755721
The call to _start() fills in the dirname, basename, and filename
arguments according to the following rules:
dir watches: dirname filled
file watches: dirname and basename filled
hardlink: filename filled
This doesn't map to how the current inotify backend works very nicely,
so we need to adjust things a bit when creating our "sub" objects.
https://bugzilla.gnome.org/show_bug.cgi?id=755721
This test will only work on machines which have IPv6 enabled and have a
local IPv6 interface with ID 1. On machines which don’t (such as AWS
servers, which we run CI tests on), the GResolver tests will fail with
G_RESOLVER_ERROR_INVALID. We can’t differentiate this kind of failure
(where we’d want to skip the test) from an actual failure (where we’d
want to fail the test), so the only other option is to drop this
particular test vector. I don’t think it’s a significant loss.
This is the last fix needed to get our CI tests working reliably on
jenkins.gnome.org.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795234
There are various reasons why setting up a server might fail; it
reliably fails on AWS with IPv6 addresses (are we binding to the right
address?). Since we’re trying to test GSocket as a client, skip tests
where that happens.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795234
While 333 runs is very likely to reproduce the bug, Milan has previously
reproduced it with as few as 9 runs. Since this test will be run by the
CI machinery quite often, a lower number of runs each CI run will still
probably catch any regressions over time.
This reduces the total test runtime from 33s to 2s.
https://bugzilla.gnome.org/show_bug.cgi?id=793727
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
When using g_network_monitor_get_default() from another thread, it’s
possible for network-changed events to be processed after an instance of
GNetworkMonitor has been disposed, causing use-after-free problems.
Fix that by moving some of the initialisation into the GInitable.init()
chain, rather than in a main context idle callback.
This includes a unit test which probabilistically reproduces the bug
(but can’t do so deterministically due to it being a race condition).
Commit amended by Philip Withnall <withnall@endlessm.com> before
pushing.
https://bugzilla.gnome.org/show_bug.cgi?id=793727
Spotted while running valgrind on gsettings-test, as per the previous
commit.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
When using g_settings_bind(), if a range binding triggers a range check
failure, g_settings_binding_property_changed() will return early, but it
won't cleanup properly causing some leaks. The binding will also still
be marked as 'running', which causes an assertion failure when trying to
free it:
"g_settings_binding_free: assertion failed: (!binding->running)"
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=794805
There's a race condition somewhere in GTestDBus that can result in
the next test being started at a time when g_bus_get() would still
return the connection that is in the process of closing. This can
be reproduced reasonably reliably by running the gapplication test
10K times in a loop.
Instead of relying on waiting for the weak reference to be released,
we can force the issue by clearing it.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=768996
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894677
This adds a null notification backend implementation for win32, purely
to avoid crashes due to a missing backend when applications use
GNotification. This backend does nothing except print a warning when a
notification is supposed to be emitted.
In future, it can be expanded to use win32 API to present toaster
notifications appropriately.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=776583
If glib-networking is installed and built with libproxy support, this
test will use it. If a proxy is set in the environment, we might get
correctly told to go through it for certain accesses. However, this isn't
going to work, because the testsuite monkeys with the network monitor to
tell it that all addresses - including the proxy - aren't reachable.
We're trying to check if adding networks to a GNetworkMonitor works in
general. Proxies just get in the way here, so let's use the built in
dummy proxy resolver which just tells us that all URLs are directly
accessible.
https://bugzilla.gnome.org/show_bug.cgi?id=794801
Explain why we say "See new_stateful()" (although it's pretty obvious).
Drop a redundant copy of the argument description in the body text.
Add a # to the GVariant type name so that we can have a nice link.
https://bugzilla.gnome.org/show_bug.cgi?id=795070
If something is nullable, it's always helpful to identify what NULL
means. Also, this is not the parameter for the .activate() vfunc, as we
take that over: rather, it is the parameter for the ::activate signal.
https://bugzilla.gnome.org/show_bug.cgi?id=795070
The `mount_monitor` variable is only set if the boolean
`with_mount_monitor` variable is set to TRUE, but the compiler does not
know that, so it'll warn when calling `g_clear_object()` even if the
clearing operation is gated with the same boolean.
Initializing with NULL does not cost us anything, and eliminates a
conditional branch.
https://bugzilla.gnome.org/show_bug.cgi?id=794732
The g_auto macros are available only with GCC-compatible compilers on
Unix, but having __attribute__((cleanup)) is not part of our toolchain
requirements, so we shouldn't use it — even if we are building on
Unix-compatible systems.
https://bugzilla.gnome.org/show_bug.cgi?id=794732
Some very odd systems have the functions to initialise and destroy a
struct __res_state, but apparently not to do a DNS query using it. Fix
the compilation on those systems.
https://bugzilla.gnome.org/show_bug.cgi?id=794606
GSocketListener can keep internal references to itself for pending
accept() calls, which mean that it can stay alive (and keep listening
on ports) even after a user drops their last reference to it. They need
to call g_socket_listener_close() explicitly to avoid that.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=794207
There's no need to unconditionally print an error message if xmllint or
json-glib-format are not found when running glib-compile-resources is
called; we only need to warn if they are not available when we need
them. To avoid spamming the build logs, we can also warn once.
https://bugzilla.gnome.org/show_bug.cgi?id=794285
The glib-compile-resources tool has hand-rolled "open a temporary file"
code paths. Since error handling is hard, let's rely on GLib API that is
meant to do that consistently for us.
Get rid of some tabs mixed with spaces while we're at it.
https://bugzilla.gnome.org/show_bug.cgi?id=794284
Similarly to how glib-compile-resources can call xmllint to eliminate
whitespace in XML files to reduce their size inside a GResource, we can
use json-glib-format to achieve the same result.
The mechanism for using json-glib-format is the same, with a separate
environment variable if we want to direct glib-compile-resources to a
version of json-glib-format that is not the one in the PATH.
https://bugzilla.gnome.org/show_bug.cgi?id=794284
Normally, the list of mounts is filtered to exclude mounts in
/run/media/$username where $username is not the current user. However,
root can access all the mounts under /run/media/, regardless of the
username — so there’s no point in filtering out those mounts.
In some cases, filtering them out is harmful. In the case of a system
service which uses GVolumeMonitor, for example, filtering them out means
the service cannot see automounted USB sticks belonging to user
sessions.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793994
Tighten up the validation of application IDs so they are always exactly
D-Bus well-known names. This is a slight change to the accepted format,
but since anyone using the API with an application ID which was
previously valid, but which was not a valid D-Bus well-known name, would
have received an error from D-Bus when their application tried to
register on the bus, I think this break is acceptable.
It will affect any applications which have application IDs which are not
valid D-Bus well-known names, and which use the G_APPLICATION_NON_UNIQUE
flag. From a quick search in Debian Codesearch, no C applications use
that flag.
Update the documentation to use the rules from the D-Bus specification,
including the latest advice discouraging use of hyphens:
https://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-names-bus
Update the tests:
• Add the examples from the documentation to validate them.
• Especially the venerable 7-zip.org example.
• Move a couple of tests from expected-failure to expected-success:
they are valid D-Bus well-known names even if they’re a bit weird.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793400
This will make the assertion failure messages a little more useful, and
prevent the assertions being compiled out with G_DISABLE_ASSERT.
Introduces no functional changes.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793400
- Stop using a custom thread for listening to kqueue(2) events. Instead
call kevent(2) in non blocking mode in a monitor callback. Under the
hood poll(2) is used to figure out if new events are available.
- Do not use a socketpair with a custom protocol requiring 2 supplementary
context switches per event to commicate between multiple threads. Calling
kevent(2), in non blocking mode, to add/remove events is fine from any
context.
- Add kqueue(2) events without the EV_ONESHOT flag. This removes a race
where some notifications were lost because events had to be re-added for
every new notification.
- Get rid of the global hash table and its associated lock and races. Use
the 'cookie' argument of kevent(2) to pass the associated descriptor when
registering an event.
- Fix _kh_file_appeared_cb() by properly passing a monitor instead of a
source to g_file_monitor_emit_event().
- Properly refcount sources.
- Remove a lot of abstraction making it harder to fix the remaining issues.
https://bugzilla.gnome.org/show_bug.cgi?id=739424
If the GNetworkMonitorNetlink is finalised part-way through a dump
(after request_dump() is called, but before finish_dump() is called),
dump_networks was leaked. Fix that.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793880
This should introduce no functional changes. Factor out some common
code, flip some arguments around to use the more conventional (data,
length) order, and move some memory management calls out of
if-blocks.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793880
By using g_timeout_source_new_seconds(), we can let timer wakeups be
coalesced by the scheduler, and reduce power consumption a bit. This
shouldn’t really affect the accuracy of the network monitoring.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793880
Previously, the GSource would be attached to whatever GMainContext was
the thread default at the time; but that might no longer be the same as
the default at the time of constructing the GNetworkMonitor.
Save the default from construction time, so that source callbacks are
always invoked in the same GMainContext.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793880
In doing so, ensure that g_option_context_set_ignore_unknown_options()
is always called if completion is being done.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793597
In this situation:
$ gdbus emit --session --object-path /org/foo/bar --sig<tab><tab><tab>
We will currently insert --signal three times.
We should only do that once.
https://bugzilla.gnome.org/show_bug.cgi?id=793597
Commit faf9440908 made the bash completion more
robust, but in doing so it made the optional --dest argument to `gdbus emit'
mandatory by mistake.
Remove the error case when --dest is not specified. To keep the completion
working, we shuffle the cases around. --dest should be offered up for
completion after --session/--system/--address have been supplied, so we can
complete its argument. Additionally, if --dest isn't specified then we can't
complete --object-path or --signal, so guard these completions accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=793597
When completing, we parse the options that the user has typed so far. Up
until now we've been doing this without ignoring unknown options. This
leads to broken completions when the user has typed an incomplete
parameter.
For example, when doing the following:
$ gdbus emit --session --obj<tab>
We expect --object-path to be completed, but it is currently not. What
happens is that we fail to parse the options, therefore don't act on
--session and so don't connect to the session bus, then we early-exit
because we need to know which bus to operate on for later completions.
Instead we can ignore the half-completed --obj, parse --session, get
connected to the bus and then move on to the later completion code.
https://bugzilla.gnome.org/show_bug.cgi?id=793597
This change increases throughput when copying files for some filesystems
(Modified by Philip Withnall <withnall@endlessm.com> to add more error
handling.)
https://bugzilla.gnome.org/show_bug.cgi?id=791457
It incorrectly said that an error could only be returned if the GVariant
was incorrect for the D-Bus API, but that’s not true: an error will also
be returned if you call it on a closed GDBusConnection.
Clarify that, and mention the actual error codes which are returned.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
If calling g_subprocess_communicate() on a GSubprocess with no
stdout/stderr pipe, a critical warning would be emitted from
g_memory_output_stream_steal_as_bytes(), as it would be called on a NULL
output stream.
Fix that, improve the relevant GIR annotations, and expand the unit
tests to cover it (and various other combinations of flags).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793331
Building against libmount installed into a non-default prefix wasn’t
working, as we were using #include <libmount/libmount.h> rather than
the correct #include <libmount.h> — all the mount.pc pkg-config files
set `Cflags: -I${includedir}/libmount`.
Fixing this while retaining the fallback support for versions of
libmount without a pkg-config file would have been tricky (we would need
to work out a suitable -I flag to set in LIBMOUNT_CFLAGS) to still be
able to use the correct #include path). Thankfully, libmount gained
pkg-config support a long time ago, so I think we can safely drop the
fallback code. In particular, Debian Jessie, Ubuntu Trusty, and CentOS 5
all ship a mount.pc file.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793288
If flush_async is deleted by a child class, then calling
g_output_stream_flush_async would leave the GOutputStream in an invalid
state. I'm not aware of any GOutputStream that would be affected by this
issue, but might as well fix it.
https://bugzilla.gnome.org/show_bug.cgi?id=738277
