FreeBSD, DragonflyBSD and NetBSD support O_NOFOLLOW, but they use error
numbers that are different from what POSIX standard specifies. They are
not going to change the behavior, and existing programs on these systems
already take advantage of this difference. To support them, we have to
add a check in GIO to use different error numbers on these systems.
https://bugzilla.gnome.org/show_bug.cgi?id=775593
For historical reasons, the reference dbus-daemon responds to most
method calls on all object paths. However, the canonical path
of the object implementing the o.fd.DBus interface is
/org/freedesktop/DBus, and in some environments (notably AppArmor
with the <abstractions/dbus-session-strict> abstraction) only this
path is allowed.
https://bugs.freedesktop.org/show_bug.cgi?id=101256 officially
deprecates all other object paths, and when adding new APIs we will
only make them available on the canonical object path.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Emmanuele Bassi <ebassi@gnome.org>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=783593
The caller passes in a GString instance which is then modified by the
function, rather than the function building its own GString and passing
it out to the caller.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=783392
For the files in gio/ (but not in gio/ sub-directories), only the *.[ch]
files were handled in commit 3bf4a720c3.
For the modified files in glib/tests/markups/, I've tested that
`make check` still succeeds.
After this commit,
$ git grep -in "GNU Library"
and
$ git grep -in "Library General"
return only results in COPYING files and in glib/libcharset/. The latter
was not updated because it's a copy.
$ git grep -in "version 2" | grep -iv "version 2\.1"
now doesn't return any LGPL license header.
- glib-gettextize.in: GPL
- glib/gen-unicode-tables.pl: GPL
- glib/gnulib/: a copy
- glib/libcharset/: a copy
- m4macros/attributes.m4: GPL
- po/po2tbl.sed.in: GPL
- tap-driver.sh: GPL
- tests/*.pl: GPL
https://bugzilla.gnome.org/show_bug.cgi?id=776504
If g_dbus_unwatch_name() is called from one thread at the same time as
the GDBusConnection is emitting ::disconnected in another thread, there
will be a race and the handler for ::disconnected may end up using
memory after it’s freed.
Fix this by serialising through the map_id_to_client, so that
on_connection_disconnected() atomically gets a strong reference to the
Client, or NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=777307
Previously, this was done at the time of spawning the subprocess, which
meant the g_subprocess_launcher_*_environ() functions could not be used
to modify the parent process’ environment.
Change the code to copy the parent process’ environment when
g_subprocess_launcher_set_environ(NULL) is called. Document the change
and add a unit test.
https://bugzilla.gnome.org/show_bug.cgi?id=778422
Since GtkApplication auto-loads some well-known resource paths. Add a
cross-reference to its documentation. (The cross-reference won’t be
linked if the GTK+ documentation isn’t available at build time, but this
is probably good enough. It is likely to be available.)
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=782336
The OpenURI portal has a separate method to handle local
files now. Use it.
At the same time, split out the openuri helpers into separate
files, and generate code for the OpenURI portal.
https://bugzilla.gnome.org/show_bug.cgi?id=783193
In addition to code, gdbus-codegen can also generate docbook
documentation for DBus interfaces. There's no good reason why
the newly added --output-directory option shouldn't apply to
those generated files as well.
https://bugzilla.gnome.org/show_bug.cgi?id=783201
When we call org.freedesktop.Application.Open to activate
an application and pass file uris, the application may not
be able to see the files due to a flatpak sandbox.
Flatpak puts the flatpak app-id in the X-Flatpak key in
desktop files that it exports, so we can easily recognize
applications that may be affected by this.
In this case, call the document portal to export the files
and pass the resulting uri's instead of the original ones.
https://bugzilla.gnome.org/show_bug.cgi?id=783130
Add $XDG_DATA_HOME/glib-2.0/schemas as a schema source, after (higher
priority than) $XDG_DATA_DIRS/glib-2.0/schemas but before
$GSETTINGS_SCHEMA_DIR. This is per the XDG Base Directory Specification,
which states that user specific versions of data in $XDG_DATA_DIRS can
be created in $XDG_DATA_HOME.
https://bugzilla.gnome.org/show_bug.cgi?id=741335
Currently, all mime types are considered subclasses of
application/octet-stream, but according to the freedesktop
standard, everything but the inode/* types is a subclass of
application/octet-stream.
Update the special case for application/octet-stream so that all
types but inode/* will match with it and add unit test for it.
https://bugzilla.gnome.org/show_bug.cgi?id=782311
g_dbus_connection_call_internal() accesses the user data it passes to
g_dbus_connection_send_message_with_reply() after the call. That data
might be freed already in the case that the callback is called
immediately.
Fix this by removing the 'serial' field from the user data altogether
and fetch the serial from the message in the callback.
https://bugzilla.gnome.org/show_bug.cgi?id=748263
mnt_table_is_fs_mounted causes unwanted automount requests due to
canonicalization of source and target. It might be replaced by
mnt_table_find_source as per the documentation in order to prevent
the automounts, but it is redundant. All mtab entries should be already
mounted and thus mnt_table_is_fs_mounted result is always true (it
basically checks that the fs from mtab is in mtab). Let's remove
the check at all.
https://bugzilla.gnome.org/show_bug.cgi?id=781867
libmnt_context is useless. It contains cache which is useful for searching,
but it isn't used in our case. Let's use mnt_context_parse_mtab instead
directly and the mtab processing will be faster.
https://bugzilla.gnome.org/show_bug.cgi?id=781867
The GNetworkMonitor docs were talking about one implementation,
omitting the others. While fixing that, add a bit about implementations
to the GProxyResolver docs too.
When we are inside a sandbox, we want to use the portal
implementation, since it is the only one that has a chance
of working.
This is safe to do, since the portal implementation will
just fail initialization when loaded outside a sandbox.
The flatpak-info file was moved to a different location a while
ago, we should read it from there instead of relying on the
compat symlink. One advantage is that this is a fixed, short
path, we don't have to construct one dynamically.
https://bugzilla.gnome.org/show_bug.cgi?id=781826
Looks like the author started typing one thing, then changed their mind
about how to phrase the sentence, and typed something else.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
