This assumption breaks when, for instance:
* Called as /bin/gdbus-codegen
* Installed on Windows in a directory that is not `bin/`
For such cases, we cannot make any assumptions about the directory
structure, and must hard-code the datadir.
https://bugzilla.gnome.org/show_bug.cgi?id=786785
The return value from g_get_user_special_dir() might be NULL. Safest to
use g_strcmp0() uniformly everywhere.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=661442
If gio open exits before the program it starts fully activates, then
the dbus-daemon may avoid doing the activating method call.
This commit works around the problem by pinging the activated application,
and waiting for a reply.
Same workaround is used in gtk-launch and was used in gvfs-open before
it was replaced by gio open.
https://bugzilla.gnome.org/show_bug.cgi?id=780296
Commit 53ed180 improved mtab processing, however, also introduced bug
in code obtaining mount points. mtab was used by mistake also for
g_unix_mount_points_get implementation, which is obviously wrong and
fstab has to be used instead...
https://bugzilla.gnome.org/show_bug.cgi?id=781867
Fix get_mounts_timestamp() to not use a stat'ed mtime for /proc/ files.
Instead, use mount_poller_time if /proc/ watch is running, or otherwise
return a new generated timestamp to always assume mounts-changed, which
is safer than previous behaviour of always assuming mounts-not-changed
(as mtime never changes for /proc/ files when queried from the same
process).
We say it's safer because allows caches depending on:
g_unix_mounts_get(&time_read)
g_unix_mounts_changed_since()
to drop possibly outdated/duplicated values, as that was the case for the
GIO mounts cache used in gio/glocalfile.c which provides mount info for
g_file_query_filesystem_info() call, as described in below referenced bug.
This fix complements related commit bd9e266e11https://bugzilla.gnome.org/show_bug.cgi?id=787731
Add testcase for function g_file_query_filesystem_info()
reporting outdated info for "filesystem::readonly" attribute
when said attribute was different in a previous mounted
partition in the same device (as GIO maintains a mounts cache
per 'st_dev' stat() member).
To trigger a mount operation, testcase uses program 'bindfs'
instead of 'mount --bind' as bindfs does not require root
privileges. And 'fusermount -u' command is used to unmount said
bindfs mount.
As a reference in Fedora, 'bindfs' is installed from 'bindfs'
package and 'fusermount' from 'fuse' package (this one is installed
by default as being part of 'System Tools' group).
The test creates a directory with a file in it, then mounts it
readonly over another directory (the mountpoint), it then checks
that g_file_query_filesystem_info() for the file in it indeed reports
"filesystem::readonly" as TRUE. Then unmounts and mounts again this
time rw (not readonly), it then checks again if g_file_query_filesystem_info()
is reporting "filesystem::readonly" as TRUE, if that's the case, it
confirms the bug by opening said file in write mode.
Testcase is only added for Unix builds.
https://bugzilla.gnome.org/show_bug.cgi?id=787731
This reverts commit 8028494335.
Adding (array length=…) to a gchar* parameter causes the GIR file to
contain an array of strings, rather than an array of characters. While
we fix GIR, revert those changes.
Some of the other changes in the file (which have an explicit
(element-type) already) are fine.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=765063
The m4 and bash completion items are usable and relevant
depending on the host system's configuration. So, we check for the
presence of the programs that these items depend on, and only install
them when those programs are found.
For the Valgrind suppression files, we don't install them on Windows as
Valgrind is currently not supported on Windows.
Als fix the path where the GDB helpers are installed, as the path is
incorrectly constructed.
This will fix the "install" stage when building on Visual Studio at
least as there are some post-install steps that are related to them,
which will make use of these programs.
https://bugzilla.gnome.org/show_bug.cgi?id=783270
I’m unsure what the original reasoning for returning TRUE by default
from supports_dtls was, but it is not backwards-compatible. If a
pre-existing GTlsBackend implementation never implements the
supports_dtls vfunc, the supports_dtls() method will magically return
TRUE rather than FALSE.
Since any backend which does implement DTLS should be implementing the
supports_dtls vfunc (and no DTLS-supporting backends have actually been
merged yet; see bug #697908), it seems safer to make this slight API
break in the name of backwards compatibility than to leave it as
returning TRUE incorrectly.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=787485
Language bindings have so far been unable to implement the GListModel
interface because the ::get_item virtual function returns a
non-bindable type (gpointer). The `gpointer` type gets translated into
`void` by G-I meaning that get_item() implementations can't return any
items.
We can set the return type of the get_item() vfunc explicitly to
GObject, which fixes the issue.
This patch also removes the existing (type GObject) annotation on
g_list_model_get_item(), which is necessary because if its return type
matches that of the get_item() vfunc, G-I connects the two and
propagates the 'skip' annotation from one to the other resulting in the
get_item() vfunc being hidden. There's no API break here because the
'skip' annotation makes g_list_model_get_item() invisible to G-I users
anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=787271
Calling g_application_quit() ignores the hold count; this patch adds a
warning to the documentation about other code having a hold on the
application and expecting it to exist.
https://bugzilla.gnome.org/show_bug.cgi?id=737278
Setting a variable and then assigning it to itself avoids
-Wunused-but-set-variable but this specific trick is now caught by
-Wself-assign. Instead, actually use the value or don't bother
assigning it at all:
gdbusauthmechanismsha1.c: #ifdef a var decl to match its actual use use
gdbusauthmechanismsha1.c: call g_ascii_strtoll() in void context
https://bugzilla.gnome.org/show_bug.cgi?id=745723
Setting a variable and then assigning it to itself avoids
-Wunused-but-set-variable but this specific trick is now caught by
-Wself-assign. Instead, actually use the value or don't bother
assigning it at all:
gdbusauth.c: call g_data_input_stream_read_byte() in void context
gdbusauthmechanismsha1.c: value is actually used
gdbusmessage.c: use consistent preprocessor-token protection
gthreadedresolver.c: skip over bytes in data blob
httpd.c: do something useful with the value
https://bugzilla.gnome.org/show_bug.cgi?id=745723
It's not likely that the runtime of a bound language using the
introspection supports running in a process forked by a foreign
library, so that a closure programmed in that language would work
safely.
Any programming environment supporting that would probably have
its own advanced facilities for process spawning, or be able
to access the GLib spawning APIs via raw C bindings (still
represented in the introspection, (skip) only adds a flag)
and do any low-level preparatory dances as necessary for the
forked runtime.
Note that there are other APIs making use of GSpawnChildSetupFunc,
but they are usable with the closure nullified, and we cannot annotate
the closure parameters away because that would break the annotated API
for bindings; accordingly to bug #738176 comment #3, the current bindings'
users are expected to pass null.
Make it a bit more obvious when the DTLS methods aren’t implemented by a
particular TLS backend; return an invalid type rather than crashing.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=752240
Instead of a full reference, which causes problems for clients that
expect a GSettings instance to stop firing signals once they drop the
last reference.
https://bugzilla.gnome.org/show_bug.cgi?id=780861
See bug #786456 for a detailed analysis of the situation which can cause
this (in summary, if a g_subprocess_wait_async() call is cancelled on a
GSubprocess which is already known to be dead).
The problem was that the GCancellable callback handler was
unconditionally returning a result for the GTask for
g_subprocess_wait_async(), even if that GTask had already returned a
result and the callback was being invoked after the GTask had been
removed from the pending_waits list.
Fix that by checking whether the GTask is still in the pending_waits
list before returning a result for it.
Thanks to Will Thompson for some very useful unit tests which reproduce
this (which will be pushed in the following commit).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=786456
Similarly to the previous commit, move the temporary directory for the
monitor test from $(cwd) to the system temporary directory.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=785260
Rather than creating a temporary directory in the current directory
(typically the builddir), then never deleting it; create one in the
system /tmp directory, and clean it up properly afterwards.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=785260
The following warning is shown, when both g_output_stream_write and
g_output_stream_close fail:
"GError set over the top of a previous GError or uninitialized memory."
Let's clear the error after use.
https://bugzilla.gnome.org/show_bug.cgi?id=786463
We want to set _WIN32_WINNT so that functions will be properly found in
the headers, to target the NT6.1+ (Windows 7+) APIs.
Also improve the checks for if_nametoindex() and if_indextoname() on
Windows as they are supported in Windows Vista+, but they have
to be checked by linking against iphlpapi.lib (or -liphlpapi). On other
platforms, they are still checked as they were before.
https://bugzilla.gnome.org/show_bug.cgi?id=783270
Some of the dependencies' build systems for Visual Studio do not provide a
pkg-config file upon build, so we use find_library() for them when the
corresponding pkg-config files are not found during Visual Studio builds,
so that one will not need to make up pkg-config files for them, which
could be error-prone. These .lib names match the names that are built
with the officially supported build system that is used by their
respective Visual Studio support.
For ZLib, this will make gio-2.0.pc reflect on the zlib .lib based on
what is found, or whether we use the fallback/bundled ZLib, when we
don't have a pkg-config file for ZLib on MSVC. We still need to depend
on Meson to be updated to put the correct link argument for linking ZLib
in the pkg-config case.
https://bugzilla.gnome.org/show_bug.cgi?id=783270
Calling g_variant_get (parameters, "(&s)") when parameters has a
signature other than (s) is considered to be a programming error.
In practice the message bus (dbus-daemon or a reimplementation) should
always send the expected type, but be defensive.
(Modified by Philip Withnall to improve type check.)
Signed-off-by: Simon McVittie <smcv@collabora.com>
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=784392
PulseAudio and LibreOffice are among the services that use this flag.
Refusing to queue for a name lets you do this transaction,
but atomically, avoiding the transient state where you briefly join
the queue and then are given the name when its primary owner drops it:
result = RequestName(name)
if result == IN_QUEUE:
ReleaseName(name)
result = EXISTS
return result
(Modified by Philip Withnall to add documentation.)
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=784392
The implementation passes flags through directly to the RequestName()
call, so if any new values break that equivalence, the implementation
will have to be changed.
Signed-off-by: Simon McVittie <smcv@collabora.com>
https://bugzilla.gnome.org/show_bug.cgi?id=784392
If no callback is provided, token is never set, but it’s then passed to
g_variant_new_string(), which requires a non-NULL input.
Fix that by moving all the option handling inside the (callback != NULL)
case.
Spotted by Coverity (CID #1378714).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=785817
Little did I know when making commit
c257757cf6 that a lot of the output of
glib-compile-schemas is string matched in some of the unit tests. Fix
them to match the updated strings.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=695573
Some platforms use different extensions for compile-time linkable
libraries vs runtime-loadable modules. Need to use special libtool
flag in the latter case for consistency with what gmodule expects.
https://bugzilla.gnome.org/show_bug.cgi?id=731703
• Fix capitalisation to be consistent
• Use Unicode quotation marks where appropriate
• Move trailing \n characters out of the translable strings and append
them unconditionally
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=695573
Mention that it really is a good idea to save errno before doing
literally anything else after calling a function which could set it.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=785577
Prevent the situation where errno is set by function A, then function B
is called (which is typically _(), but could be anything else) and it
overwrites errno, then errno is checked by the caller.
errno is a horrific API, and we need to be careful to save its value as
soon as a function call (which might set it) returns. i.e. Follow the
pattern:
int errsv, ret;
ret = some_call_which_might_set_errno ();
errsv = errno;
if (ret < 0)
puts (strerror (errsv));
This patch implements that pattern throughout GLib. There might be a few
places in the test code which still use errno directly. They should be
ported as necessary. It doesn’t modify all the call sites like this:
if (some_call_which_might_set_errno () && errno == ESOMETHING)
since the refactoring involved is probably more harmful than beneficial
there. It does, however, refactor other call sites regardless of whether
they were originally buggy.
https://bugzilla.gnome.org/show_bug.cgi?id=785577
The /etc/mtab file is still used by some distributions (e.g. Slackware),
so it has to be monitored instead of /proc/self/mountinfo in order to
avoid races between g_unix_mounts_get and "mounts-changed" signal. The
util-linux is built with --enable-libmount-support-mtab in that case and
mnt_has_regular_mtab is used for checks. Let's use mnt_has_regular_mtab
also to determine which file to monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=779607
Unlike g_application_register, there is no public API to unregister the
GApplication from D-Bus. Therefore, if the GApplication is set up
manually without using g_application_run, then neither can the
GApplicationImpl be destroyed nor can dbus_unregister be called before
destruction.
This is fine as long as no sub-class has implemented dbus_unregister.
If they have, their method method will be called after destruction, and
they should be prepared to deal with the consequences.
As long as there is no public API for unregistering, let's demote the
assertion to a WARNING. Bravehearts who don't use g_application_run
can continue to implement dbus_unregister, but they would have been
adequately notified.
This reverts commit c1ae1170fa.
https://bugzilla.gnome.org/show_bug.cgi?id=725950
Invoking the dbus_unregister virtual method during destruction is
problematic. It would happen after a sub-class has dropped its
references to its instance objects, and it is surprising to be asked to
unexport exported D-Bus objects after that.
This problem was masked as a side-effect of commit 21b1c390a3.
Let's ensure that it doesn't regress by asserting that dbus_unregister
has happened before destruction.
Based on a patch by Giovanni Campagna.
https://bugzilla.gnome.org/show_bug.cgi?id=725950
When using the Freedesktop backend for GNotification, it seems like a
better idea to map G_NOTIFICATION_PRIORITY_HIGH to NOTIFY_URGENCY_NORMAL
(instead of NOTIFY_URGENCY_CRITICAL) provided that the difference
between GNotification's NORMAL and HIGH priorities is minor.
Signed-off-by: Adrian Perez de Castro <aperez@igalia.com>
https://bugzilla.gnome.org/show_bug.cgi?id=784815
When building glib as a subproject, #include's for xdp-dbus.h from xdp-dbus.c
and for gdbus-daemon-generated.h from gdbus-daemon-generated.c were generated as
being prefixed with the subproject prefix, eg
#include "subproject/glib/gio/gdbus-daemon-generated.h".
That failed since the root of the build directory is obviously not part of the
include path when building a subproject.
Passing --output-directory @OUTDIR@ to gdbus-codegen and removing @OUTDIR@ from
--generate-c-code fixes the issue.
meson.source_root() returns the toplevel source directory
of the toplevel project, thus the paths were wrong when using
it. Simply using files() gets us the right path
https://bugzilla.gnome.org/show_bug.cgi?id=784133
With meson from git dependencies of dependencies are no
longer added automatically and recursively to the linker
lines. Meaning dependencies that are used have to be
passed directly and explicitly or we'll get linker errors.
Need to fix up some of the tests a little, because the
test binary will not necessarily be run from the current
build sub-directory, and the build directory structure
might not always be a mirror of the source directory
structure, so pass location of glib-mkenums and
glib-compile-scheme and such directly.
This reduces the build-time dependencies of glib to only Python 3,
Meson, and git. Git is also optional if you provide a tarball in
which the subproject directories already exist.
The Python port was done by Jussi Pakkanen on bugzilla:
https://bugzilla.gnome.org/show_bug.cgi?id=779332
This version contains some fixes from that and also changes all
instances of `@` to `\u0040` because Meson does not yet provide a
configure_file() mode that ignores unknown @MACRO@ values.
This is a stub-only library that can be used while building against
MSVC and contains no i18n machinery at all.
The dependencies added indirectly use the libintl.h header, and when
built as a subproject, the header won't be in a path known the
pre-processor.
Don't use it project-wide for building everything. Otherwise
symbols for shared modules won't be exposed, e.g. in the
resourceplugin used by the gio resource unit test.
giomodule test needed symbol visibility pragmas added. This is needed on
Windows anyway, so it's better to do it this way rather than disabling
-fvisibility=hidden for the test modules.
Disable gio tests on Windows, fix .gitignore to not ignore
config.h.meson, and add more things to it.
Rename the library file naming and versioning to match what Autotools
outputs, e.g., libglib-2.0.so.0.5000.2 on Linux, libglib-2.0-0.dll and
glib-2.0-0.dll on Windows with MSVC.
Several more tiny fixes, more executables built and installed, install
pkg-config and m4 files, fix building of gobject tests.
Changes to gdbus-codegen to support out-of-tree builds without
environment variables set (which you can't in Meson). We now add the
build directory to the Python module search path.
g_build_filename() returns a gchar*, but it was stored in a const gchar*
and then g_free()d, which is wrong and led to a warning about the const
qualifier being cast away.
The g_file_copy() documentation didn't mention if
G_FILE_COPY_ALL_METADATA was applicable or not, and users were led to
call g_file_copy_attributes() to specify it after the g_file_copy()
call, unless they checked the source (been there, done that).
https://bugzilla.gnome.org/show_bug.cgi?id=784037
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>
Otherwise, we might end up returning TRUE from
g_app_info_launch_default_for_uri but with a set error parameter. This
will lead to confusing results depending on how the caller checks for
errors. Checking error != NULL indicats the call failed but checking the
return value indicates that it succeeded.
There are a few places where commit 18a33f72 replaced valid (nullable)
(optional) annotations with just (optional). That has a different
meaning.
(nullable) (optional) can only be applied to gpointer* parameters, and
means that both the gpointer* and returned gpointer can be NULL. i.e.
The caller can pass in NULL to ignore the return value; and the returned
value can be NULL.
(optional) can be applied to anything* parameters, and means that the
anything* can be NULL. i.e. The caller can pass in NULL to ignore the
return value. The return value cannot be NULL.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Some annotations I made while trying to debug bug #781847. They
introduce no behavioural changes.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Compiling with clang 3.8.1-18 (debian, x86_64) I ran across this
error:
gio-tool.c:40:31: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
message = g_strdup_vprintf (format, args);
^~~~~~
gio-tool.c:55:31: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
message = g_strdup_vprintf (format, args);
^~~~~~
2 errors generated.
To fix the first one, related with the function print_error(), this
patch adds to the function prototype a compiler's attribute.
For the second one, since the usage of that function is to print
one string and the format is already provided, the patch simplifies
the function by no receiving variadic arguments.
https://bugzilla.gnome.org/show_bug.cgi?id=781125
It's unnecessary, and only adds visual noise; we have been fairly
inconsistent in the past, but the semi-colon-less version clearly
dominates in the code base.
https://bugzilla.gnome.org/show_bug.cgi?id=669355
The g_drive_is_removable() support was added recently in gio/gvfs
(see Bug 765900 and Bug 765457). It was also added in gvfs-mount,
but we forgot to add it also in gio-tool-mount.
https://bugzilla.gnome.org/show_bug.cgi?id=776169
This patch contains the following changes:
- Print all errors with "gio: " prefix
- Print file uri in error for each tool allowing multiple locations
- Mark all error messages translatable
- Do not leak strings used in error messages
- Always start error messages with capital letter
- Unify some error messages across various tools
- Fix addional/missing new line characters
https://bugzilla.gnome.org/show_bug.cgi?id=776169
Being able to determine that a certificate chain is invalid is not
considered an error, but success. This might not be obvious at first
due to the way the method is named and described currently. Since we
cannot change the name, let's improve the description and clarify this
aspect of its behaviour.
https://bugzilla.gnome.org/show_bug.cgi?id=780310
g_dbus_proxy_get_cached_property() and
g_dbus_proxy_get_cached_property_names() can both return NULL if the
property cache is empty. Avoid a crash if this situation arises (which
it looks like it could, from reading the code) by gracefully bailing out
on NULL return values.
Coverity issues: #1257044, #1257045https://bugzilla.gnome.org/show_bug.cgi?id=741229
socket->priv->timeout is only a guint, and the multiplication is
performed before it’s widened to gint64 to be stored in start_time
(thanks, C). This means any timeout of 50 days or more would overflow.
Fixing this bug makes me feel a real sense of self-worth.
Coverity ID: 1159478
Signed-off-by: Philip Withnall <withnall@endlessm.com>
request_completion is checked several blocks higher in the function.
Spotted by Coverity.
Coverity ID: 1373215
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The previously documented requirements for implementing init() and
init_async() as completely idempotent were really quite hard to achieve,
and brought a lot of pain for very little gain. Many implementations of
GInitable and GAsyncInitable did not actually follow the requirements,
or did not correctly handle concurrent init_async() calls.
Relax those requirements so that classes can decide whether their init()
or init_async() implementations need to be idempotent.
https://bugzilla.gnome.org/show_bug.cgi?id=766660
This is effectively the mc-wait-for-name tool from
telepathy-mission-control; moving it in to gdbus-tool will make it more
widely useful without making people depend on telepathy-mission-control
for no other reason. The code here is reimplemented from scratch to use
GDBus.
It blocks until the specified well-known name is owned by some process
on the bus (which can be the session, system, or any other bus). By
passing --activate, the same (or a different) name can be auto-started
on the bus first.
A timeout can be specified to ensure the process doesn’t block forever.
https://bugzilla.gnome.org/show_bug.cgi?id=745971
This will help us break generic GType deadlocks between people using
GDBus in different threads (which is supported), not just by GType
usage in the GDBus thread.
This should fix the common cases we're seeing in the wild, although I
have some lingering concerns that if someone e.g. referenced
e.g. `G_TYPE_DBUS_AUTH_MECHANISM_SHA1` etc. we'd need to add those
too.
https://bugzilla.gnome.org/show_bug.cgi?id=674885
We currently assume that the OpenURI portal should be used
unconditionally when running inside a flatpak sandbox. While
the portal is what we usually want, there are exceptions:
Yelp is now included in the GNOME runtime to allow displaying
help without exporting the user documentation, and the sandboxed
app itself may register a scheme handler.
To account for those cases transparently, always try the normal
code path first and only fall back to calling the portal when
that fails.
https://bugzilla.gnome.org/show_bug.cgi?id=780471
These calls cause race warnings from tsan, but are not a thread safety
problem, because we can only ever observe single bit changes: all
modifications to the GSource.flags field are done with a lock held; all
reads are of independent fields, so no intermediate state can ever be
observed. This assumes that a non-atomic read will consistently give us
an old value or a new value.
In any case, these g_source_is_destroyed() calls can happen from any
thread, and the state could be changed from another thread immediately
after the call returns; so the checks are pointless. In addition,
calling g_source_set_ready_time() or g_source_destroy() on a destroyed
source is not a problem.
https://bugzilla.gnome.org/show_bug.cgi?id=778049
Calling the D-Bus method for the OpenURI portal "protects" the logic from
not ever having the remote method running in case the xdg-desktop-portal
process is not yet running and the caller quits quickly after the call.
This should not be a problem as the method returns immediately (regardless
of the user making a selection), but making it synchronous would prevent
situations where the OpenURI method would never be called because of D-Bus
dropping the message after the caller dies, without explicitly waiting for
a reply.
https://bugzilla.gnome.org/show_bug.cgi?id=780441
Actually, Unicode changes to this file got reverted in
2d56c49b10. Also, there is
"No such interface '%s'" string already, so we avoid
breaking the string freeze.
g_subprocess_launcher_spawn() is NULL-terminated, and must have a
non-NULL argv0 specified, so G_GNUC_NULL_TERMINATED is appropriate here.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=780032
This highlighted a bug in GDBusConnection, where an interface name was
not included in a message referring to it.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=780032
This is an implementation of most of GAppInfo using the OS X
NSBundle APIs.
Missing at this point are things that don't have equivalents
in OS X, such as hidden desktop files, last-used, manual type
associations, and g_app_info_get_all().
https://bugzilla.gnome.org/show_bug.cgi?id=734946
This is an implementation of most of GContentType using the OS X
UTType APIs.
Missing at this point is an implementation of
g_content_types_get_registered() and g_content_type_guess_for_tree().
https://bugzilla.gnome.org/show_bug.cgi?id=734946
Previously, _kh_cancel_sub assumed that it only needed to call
_km_remove if sub did not exist in subs_hash_table. This is erroneous
because the complementary operation, _km_add_missing, can be called
from process_kqueue_notifications, in which context sub can *only* have
come from subs_hash_table.
Since _km_remove is implemented using g_slist_remove, which is
documented to be a noop if the list does not contain the element to be
removed, it is safe to call _km_remove unconditionally here.
https://bugzilla.gnome.org/show_bug.cgi?id=778515
g_settings_schema_source_get_default() is (transfer none), not (transfer
full).
Spotted by Marvin Schmidt.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=779265
On the warning/critical error handling paths for g_settings_set(), the
GVariant value was not ref-sunk, and the schema key was leaked. This
won’t affect code in production (unless it’s seriously buggy), but
eliminates some leaks from the error testing paths in the GSettings
tests.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=779265
Spotted while running `make check` under Valgrind. While it’s not
necessary to fix memory leaks in glib-compile-schemas (since it’s a
utility which runs briefly then exits), fixing them makes more
legitimate leaks in the Valgrind output more obvious, and means we can
be sure there aren’t leaks in the underlying GLib/GIO code which
glib-compile-schemas is calling.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=779265
When unregistered extension point (i.e. NULL pointer) is passed
to `g_io_extension_point_get_extensions`, it causes a segfault.
This commit adds an assertion, to prevent this.
https://bugzilla.gnome.org/show_bug.cgi?id=779183
Happens when the waiting-for-auth state is re-entered:
SERVER_STATE_WAITING_FOR_AUTH
|
v
G_DBUS_AUTH_MECHANISM_STATE_REJECTED
|
v
SERVER_STATE_WAITING_FOR_AUTH
Causing the previous `mech` pointer to get overwritten.
https://bugzilla.gnome.org/show_bug.cgi?id=778991
We're first getting the notification by its notify_id, but activating
the action afterwards could redraw it, leading to a dangling pointer.
Fix this by simply searching the list of active notifications again
after activating the action.
GNOME Builder's code was assuming that setting the launcher's
environ to NULL makes the subprocess have an empty environment, but in
fact the parent process's variables are still inherited because execv is
used instead of execve when envp is NULL. This commit clarifies the
documentation to make the behavior clear.
https://bugzilla.gnome.org/show_bug.cgi?id=778422
Add filesystem attribute to propagate time, when the metadata for the file
in "recent:///" was last changed. This attribute is needed for sorting
recent backend files in client applications.
https://bugzilla.gnome.org/show_bug.cgi?id=777507
This is small enough that it shouldn't cause problems on most machines
we support, but big enough to increase throughput on a lot of devices
and network protocols.
Note that the actual value is 256k minus malloc overhead, so that it
fits nicely in a 256k block (as suggested by Alexander Larsson).
See https://bugzilla.gnome.org/show_bug.cgi?id=773632https://bugzilla.gnome.org/show_bug.cgi?id=773823
It was suggested that the project files be moved here as we don't actually
need to go two directory layers from $(srcroot), and would help us to
standardize on things in the future across the board.
When performing the verify and building the error string there were two
possibilities of an infinite loop. The first is the missing twos-complement
to unset the bit in the filtered flags. The second is the lack of handling
G_SUBPROCESS_FLAGS_NONE which can return a valid GFlagsValue (and cannot
unset the bit since the value is zero).
This walks all known values in the GSubprocessFlags type class and check
if they are set. This has the benefit that we don't call needless functions
which walk the same table as well as avoiding mutating values to build
the error string.
https://bugzilla.gnome.org/show_bug.cgi?id=775913
When an invalid hostname is passed for connection, the
g_hostname_to_ascii() might fail when creating the request in
create_request(). Make sure that error is caught and reported rather
than passing "(null)" as the hostname of the site we want to connect to.
https://bugzilla.gnome.org/show_bug.cgi?id=772989
The tests defaultvalue, gdbus-peer and gdbus-unix-addresses will fail
without DBUS, so only run them in case we HAVE_DBUS_DAEMON.
Signed-off-by: Ingo Brückl <ib@wupperonline.de>
https://bugzilla.gnome.org/show_bug.cgi?id=767609
WSAWaitForMultipleEvents() only returns for one of the waiting threads, and
that one might not even be the one waiting for the condition that changed. As
such, only let a single thread wait on the event and use a GCond for all other
threads.
With this it is possible to e.g. have an UDP socket that is written to from
one thread and read from in another thread on Win32 too. On POSIX systems this
was working before already.
https://bugzilla.gnome.org/show_bug.cgi?id=762283
-2LL<<34 is undefined, because left-shifting a negative number is
undefined (it was implementation-defined behaviour in C99, but
is formally undefined in C11). The undefined behaviour sanitizer
picks this up.
Signed-off-by: Simon McVittie <smcv@debian.org>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=775510
Reviewed-by: Colin Walters
glibc string.h declares memcpy() with attribute(nonnull(1,2)), causing
calls with NULL arguments to be treated as undefined behaviour.
This is consistent with ISO C99 and C11, which state that passing 0
to string functions as an array length does not remove the requirement
that the pointer to the array is a valid pointer.
gcc -fsanitize=undefined catches this while running OSTree's test suite.
Similarly, running the GLib test suite reports similar issues for
qsort(), memmove(), memcmp().
Signed-off-by: Simon McVittie <smcv@debian.org>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=775510
Reviewed-by: Colin Walters
_g_dbus_auth_mechanism_server_data_send may fail in which case
we would endup getting a NULL data. In this case we should not
try to encode the data and simply let the state machine to continue.
The auth mechanism will change internally to REJECTED so we just
need to continue the iteration.
https://bugzilla.gnome.org/show_bug.cgi?id=775309
If we have an input parameter (or return value) we need to use (nullable).
However, if it is an (inout) or (out) parameter, (optional) is sufficient.
It looks like (nullable) could be used for everything according to the
Annotation documentation, but (optional) is more specific.
If g_socket_receive_message_with_timeout() is called with messages ==
NULL set the msg_control buffer to empty to not request the control
messages from recvmsg() at all.
This completely disables the control message processing and reduces
overhead, which might be critical at high packet rate.
https://bugzilla.gnome.org/show_bug.cgi?id=774520
This commit broke some tests, and I don't have the time
to fix up all the expected output, so I'll revert the changes
to the affected files for now.
This needs to be redone with the necessary test fixes.
I'm guessing the developments were done in 2.44 but the patches landed
after the 2.45.0 bump without an update to the Since tags.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=769630
GLib has g_unix_mount_at (mount_path) already, let's add g_unix_mount_for
(file_path) for whatever path. GLib already contains some private code
for such task. Let's make this code public. This functionality is needed
by GVfs (see Bug 771431) in order to avoid copy-and-pasting.
https://bugzilla.gnome.org/show_bug.cgi?id=772160
There have been some improvements to the tool recently, but it's hard to
know if those are available on a given system unless the tool provides a
--version commandline option.
https://bugzilla.gnome.org/show_bug.cgi?id=772269
It only works through its virtual methods, so while it could be
instantiated before (and this is technically an API break), any instance
of it would previously have crashed as soon as any of its methods were
called anyway.
If anybody has any problems with this ABI break, please make them known
during the 2.51 unstable development cycle and it can be reverted.
https://bugzilla.gnome.org/show_bug.cgi?id=772255
/proc/self/mountinfo is used to monitor changes of mounts with libmount.
However, GFileMonitor is used currently to monitor this file, which
doesn't work and consequently "changed" signal is never emitted. Special
monitoring needs to be used instead, same as it is used for /proc/mounts.
https://bugzilla.gnome.org/show_bug.cgi?id=662946
People might put more extraneous whitespace in a @since line in a
documentation comment, which should not affect the ordering of
methods/signals/etc. in the generated output.
https://bugzilla.gnome.org/show_bug.cgi?id=770372
Add --dependency-file=foo.d option to generate a gcc -M -MF style
dependency file for other build tools. The current output of
--generate-dependencies is only useful for use directly in Makefile
rules, but can't be used in other build systems like that.
The generated dependency file looks like this:
$ glib-compile-resources --sourcedir= test.gresource.xml --dependency-file=-
test.gresource.xml: test1.txt test2.txt test2.txt
test1.txt:
test2.txt:
test2.txt:
Unlike --generate-dependencies, the --dependency-file option can be
used together with other --generate options to create dependencies
as side-effect of generating sources.
Based on a patch by Tim-Philipp Müller in
https://bugzilla.gnome.org/show_bug.cgi?id=745754
The changes in this patch, compared to his are to always return
the hash table with file information from parse_resource_file, so
we can use it for dependency output, regardless if generate_dependencies
was TRUE or not.
Add --dependency-file=foo.d option to generate a gcc -M -MF style
dependency file for other build tools. The current output of
--generate-dependencies is only useful for use directly in Makefile
rules, but can't be used in other build systems like that.
The generated dependency file looks like this:
$ glib-compile-resources --sourcedir= test.gresource.xml --dependency-file=-
test.gresource.xml: test1.txt test2.txt test2.txt
test1.txt:
test2.txt:
test2.txt:
Unlike --generate-dependencies, the --dependency-file option can be
used together with other --generate options to create dependencies
as side-effect of generating sources.
Based on a patch by Tim-Philipp Müller.
https://bugzilla.gnome.org/show_bug.cgi?id=745754
Previously, this would not work, as it would result in comparing the
order of a string and an integer. Make it work, and make 'UNRELEASED'
compare higher than other versions so it's always treated as the latest
version.
'UNRELEASED' is commonly used by maintainers to highlight new API while
it's being prototyped, until they know which version it will actually
be released in. At the time of release, they replace all 'UNRELEASED'
strings in git with the new version number.
An example of this usage is here:
d380ac6a2a (9208ee267cb05db1afd3a5c323d71e51db489447_7619_7656)https://bugzilla.gnome.org/show_bug.cgi?id=769995
gcc 6 warns (fatally, by default) that %c only uses a 2-digit year
in some locales. The precise format does not seem to be important
for this sample code, so use ISO 8601 instead of suppressing the
warning with a pragma.
Signed-off-by: Simon McVittie <smcv@debian.org>
Reviewed-by: Colin Walters
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=768453
At some point, upstream SystemTap changed from using a
STAP_HAS_SEMAPHORES preprocessor variable for this, to using
_SDT_HAS_SEMAPHORES instead. We need to update our build system to
disable that as well.
The original discussion about use of semaphores is here:
https://bugzilla.gnome.org/show_bug.cgi?id=606044
This was breaking the build with -flto enabled, either because -flto
doesn’t work with semaphores.
https://bugzilla.gnome.org/show_bug.cgi?id=768198
GDatagramBased allows connection-oriented and connection-less sockets,
but does not allow stream-based sockets (because it’s datagram-based).
So it supports SCTP and UDP, but not TCP.
Clarify that in the documentation, and people sometimes confuse
connection-oriented with stream-based, due to the prevalence of TCP.
Use mnt_context_get_mtab instead of using mnt_context_get_table(), since
that's the recommended way of accessing mtab/mountinfo information, and
also because that way the (struct libmnt_table *) will get automatically
deallocated when calling mnt_free_context()
https://bugzilla.gnome.org/show_bug.cgi?id=769238
g_socket_listener_add_address() is synchronous; all of the events will
have been emitted before it returns and it doesn't queue any sources.
The test was unintentionally depending on the fact that
g_main_context_iterate(NULL, TRUE) would return anyway (at least the
first time it was called), but that's no longer true after e4ee307.
https://bugzilla.gnome.org/show_bug.cgi?id=768968
glib-compile-resources --generate is supposed to automatically detect
whether to generate source code or header from the target's file extension.
However, this only worked for C; extend this to include the canonical
C++ filename extensions. Also make the check case insensitive.
https://bugzilla.gnome.org/show_bug.cgi?id=747134
Include the filename for the file in question in many of the
error messages in glocalfile.c. This is useful information when
diagnosing such errors, so make it easily available.
http://bugzilla.gnome.org/show_bug.cgi?id=754012
The recently-added GIO tools is intended to be built on all platforms, so
adjust the code a bit to enable this:
-Use gssize instead of ssize_t, as ssize_t is not supported by all
compilers.
-Include io.h on Windows, and define STDIN_FILENO and STDOUT_FILENO if
necessary on Windows.
https://bugzilla.gnome.org/show_bug.cgi?id=768357
Ensure that @key is non-%NULL on g_settings_reset().
It turns out that using g_settings_reset() with %NULL key (although
invalid as per the API documentation and not possible via bindings)
accidentally produces the same effect as the _reset_all() API that we
are about to add.
Add the standard precondition checks to prevent that from happening.
https://bugzilla.gnome.org/show_bug.cgi?id=744678
GSettings objects were not unreffed in test_flags, test_enums and
test_ranges tests and when we skip internationalization tests, ie
test_l10n(_context).
https://bugzilla.gnome.org/show_bug.cgi?id=768560
The two known use-cases for autolaunching are:
* X-forwarding: "ssh -Y myhost myapp" resulting in a
session bus on myhost but an X server on the original host
* Legacy desktop environments on OSs without D-Bus integration:
e.g. running a single GNOME or KDE app under fvwm or something,
without a session dbus-daemon being started by either systemd,
gnome-session, or OS integration scripts analogous to Debian's
/etc/X11/Xsession.d/75dbus_dbus-launch
In either case, an X11 DISPLAY is also needed.
"dbus-launch --autolaunch" doesn't do anything useful when unable
to connect to an X11 display; this has been the case since the feature
was added in 2006, and is useful to avoid "split brain" situations in
which two processes that ought to be part of the same session end up
on separate session buses. Since dbus commit 407c111 in 2011,
libdbus hasn't even attempted to run "dbus-launch --autolaunch"
unless getenv("DISPLAY") returns non-null in the parent: this avoids
doing a relatively complicated fork-and-exec that is clearly not
going to lead to success. This commit gives GDBus the same policy.
This change was originally made to work around a race condition in
subprocess spawning (Debian bug #737380, GNOME bug #711090) but
it seems valid in its own right.
In my opinion as D-Bus maintainer, "dbus-launch --autolaunch" should
be considered to be an X11 feature, and any future D-Bus enhancements
(e.g. kdbus) or successors for X11 (e.g. Wayland, Mir) should obtain
a session bus address by other means - either a session manager
such as "systemd --user", gnome-session or Upstart, or a wrapper
for the user session like dbus-run-session(1).
Related to dbus bug <https://bugs.freedesktop.org/show_bug.cgi?id=19997>.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=723506
Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737380
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
xdg-desktop-portal support is only usable on *NIX platforms, so don't build
them on non-*NIX platforms. Also clean up gio/Makefile.am a bit to split out
the listings for the platform-specific sources from the platform-neutral
sources, and assemble them for the final list of sources required for libgio.
https://bugzilla.gnome.org/show_bug.cgi?id=768498
OS X apparently stringifies the IPv6 address "::80" as "::0.0.0.128",
which is bizarre, but that address *is* in a "reserved for future use"
range, so it's not unambiguously wrong I guess. Anyway, fix the text
to use an address everyone can agree on.
https://bugzilla.gnome.org/show_bug.cgi?id=768551
The backend for this lives in xdg-desktop-portal,
and is in turn using GNetworkMonitor.
When network is not available in the sandbox, there is
no point in reporting accurately about the network
status outside the sandbox. Just return 'no connection'
in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=768498
We need to patch in the portal support at a high enough
level that GAppInfo is not involved - a sandboxed app may
not be able to see any applications, so it can only launch
the defaults.
Note that even though the API is called launch_default...,
the portal may still offer the user to choose the application
to launch.
https://bugzilla.gnome.org/show_bug.cgi?id=768498
These are private helper functions that will be used in
the following commits to get information about whether
we are running in a flatpak sandbox, etc.
We allow the use of GTK_USE_PORTAL=1 in the environment
to force the use of portals. This can be useful for
testing and debugging portal interaction.
https://bugzilla.gnome.org/show_bug.cgi?id=768498
This command collects the various commandline utilities that
are currently shipped in gvfs, and unifies them under a single,
command-style binary.
The tools just use GIO APIs, so it makes sense for them to live here.
In a vague attempt at ensuring the .stp scripts can be closely
associated with the .so files which they hard-code references to, rename
the scripts so they include the LT version — so that they are the .so
file name plus .stp.
This does not fix the fact that our .stp scripts will not work on
multiarch systems, as they are installed in an architecture-independent
directory (/usr/share/systemtap/tapset). At the moment, it is
recommended that any distribution who package the .stp files should
install them in the architecture-specific subdirectories of this (for
example, /usr/share/systemtap/tapset/x86-64).
A better long-term solution for this is under discussion upstream:
https://sourceware.org/bugzilla/show_bug.cgi?id=20264https://bugzilla.gnome.org/show_bug.cgi?id=662802
The list of supported schemes is not known at compile-time, so it is
wrong to iterate the list with G_N_ELEMENTS() and we miss all but the
first scheme. Fix by checking for the %NULL sentinel instead.
https://bugzilla.gnome.org/show_bug.cgi?id=768119
Add filesystem attribute to detect remote filesystems in order to
replace hardcoded filesystem types in GtkFileSystem. Set this attribute
also for GLocalFile appropriately.
Bump version to 2.49.3, so that early adopters of new API have a version
number to target.
If none of the closures in the hash table return a non-null value, the
loop never ends. Since the end of the hash table has been reached at
that point, g_hash_table_iter_next() starts asserting.
The possible fix is making the return value of g_hash_table_iter_next()
the condition in the loop.
https://bugzilla.gnome.org/show_bug.cgi?id=768029
Add a new API to allow clients to register a custom GFile implementation
handling a particular URI scheme.
This can be useful for tests, but also for cases where a different URI
scheme is desired to be used with another custom GFile backend.
As an additional cleanup, we can use this to register the "resource" URI
scheme too.
Based on a patch by Jasper St. Pierre <jstpierre@mecheye.net>.
https://bugzilla.gnome.org/show_bug.cgi?id=767887
5cea1c861d introduced accessors for 64bit
ints to gsettings, at which point the testcases were expanded.
Unfortunately, the expanded tests contained a bug: integer constants
passed to g_object_set() for a 64-bit property need an up-cast. Add
that now.
Problem found by Iain Lane.
If a backup file is created, opened successfully, then fstat() on it
fails (perhaps due to another process deleting it in the mean time?),
the FD will be leaked.
Coverity issue: #1159485https://bugzilla.gnome.org/show_bug.cgi?id=730187
Previously this would cause an assertion failure when checking the paths
of exported objects, as it would try to check that their paths started
with ‘//’ due to mishandling the root object case.
Includes a unit test.
https://bugzilla.gnome.org/show_bug.cgi?id=761810
proxy->priv->name_owner gets overwritten in async_init_data_set_name_owner() on the
assumption that it will always be NULL when we get there. However,
on_name_owner_changed() can run first, and it does set name_owner.
==20126== 42 bytes in 6 blocks are definitely lost in loss record 15,174 of 48,256
==20126== at 0x4C280F3: malloc (vg_replace_malloc.c:299)
==20126== by 0x7541D00: g_malloc (gmem.c:104)
==20126== by 0x7558FEE: g_strdup (gstrfuncs.c:364)
==20126== by 0x6DF8E4F: on_name_owner_changed (gdbusproxy.c:1399)
==20126== by 0x6DE94C4: emit_signal_instance_in_idle_cb (gdbusconnection.c:3743)
==20126== by 0x753C315: g_main_dispatch (gmain.c:3066)
==20126== by 0x753C315: g_main_context_dispatch (gmain.c:3642)
==20126== by 0x753C667: g_main_context_iterate.isra.24 (gmain.c:3713)
==20126== by 0x753CA69: g_main_loop_run (gmain.c:3907)
==20126== by 0x5E38000: meta_run (main.c:556)
==20126== by 0x401EC0: main (main.c:441)
https://bugzilla.gnome.org/show_bug.cgi?id=755439
This fixes a build failure in Continuous that resulted in the error:
../../../gio/tests/test.gresource.xml: Failed to locate
'test-generated.txt' in any source directory.
Makefile:4676: recipe for target 'test.gresource' failed
make[6]: *** [test.gresource] Error 1
Nautilus wants to show entries in the sidebar only for removable devices.
It uses currently sort of conditions to determine which devices should be
shown. Those condition fails in some cases unfortunatelly. Lets provide
g_drive_is_removable() which uses udisks Removable property to determine
which devices should be shown. It should return true for all drives with
removable media, or flash media, or drives on usb and firewire buses.
https://bugzilla.gnome.org/show_bug.cgi?id=765900
This prevents testsuite from trying to build any TESTS in that
subdirectory, which will fail, because there are no TESTS defined
in that Makefile.am.
This happens when user runs make check TESTS=...
https://bugzilla.gnome.org/show_bug.cgi?id=766407
This adds a new --c-generate-autocleanup option to gdbus-codegen
which can be used to instruct gdbus-codegen about what autocleanup
definitions to emit.
Doing this unconditionally was found to interfere with existing
code out in the wild.
The new option takes an argument that can be
none, objects or all; to indicate whether to generate no
autocleanup functions, only do it for object types, or do it
for interface types as well. The default is 'objects', which
matches the unconditional behavior of gdbus-codegen on the 2.48
branch.
https://bugzilla.gnome.org/show_bug.cgi?id=763379
The use of past tense in g_task_had_error makes one assume that it
won't forget about any errors that might have occurred. Except, in
reality, it would.
Let's use a boolean flag to remember the error once it's been
propagated, as opposed to keeping the error around. This ensures that
the g_task_propagate_* methods continue to give invalid results when
called more than once, as mentioned in the documentation.
https://bugzilla.gnome.org/show_bug.cgi?id=764163
Some GNOME projects unconditionally work around the generated code's
lack of g_autoptr support by defining the autoptr cleanup function
themselves, which is not forward-compatible; as a result, commit
cbbcaa4 broke them. Do not define the cleanup function unless the
including app "opts in" to newer APIs via GLIB_VERSION_MAX_ALLOWED.
Projects requiring compatibility with GLib < 2.49 can get a
forward-compatible g_autoptr for a generated GInterface type found in
a library, for example ExampleAnimal in the GIO tests, by declaring
and using a typedef with a distinct name outside the library's
namespace:
typedef AutoExampleAnimal ExampleAnimal;
G_DEFINE_AUTOPTR_CLEANUP_FUNC (AutoExampleAnimal, g_object_unref)
...
g_autoptr (AutoExampleAnimal) animal = NULL;
/* returns ExampleAnimal * */
animal = example_animal_proxy_new_sync (...);
/* takes ExampleAnimal * first argument */
example_animal_call_poke_sync (animal, ...);
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=763379
Reviewed-by: Colin Walters <walters@verbum.org>
Reviewed-by: Emmanuele Bassi <ebassi@gnome.org>
The rest of the generated classes gained g_autoptr support in fd6ca66,
but this one is still missing. Because whatever_proxy_new_finish() and
whatever_proxy_new_sync() are declared as returning a Whatever *
instead of a WhateverProxy *, and the generated method-call stubs
act on a Whatever *, it's reasonably common to want to declare a
g_autoptr (Whatever).
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/review?bug=763379
Reviewed-by: Colin Walters <walters@verbum.org>
gdbus-tool prints a hint about the expected arguments to a function call
in case of errors. Unfortunately, it prints this message on all errors.
I've seen this confuse users several times -- they go on tweaking the
arguments trying to get the correct type, even though they had it
correct in the first place.
Let's limit the hint to the case where it was actually invalid arguments
that triggered the problem. Also, adjust the code that prints the
message so that it will also report on the case that no arguments were
expected.
We could possibly get closer to what we want by comparing the list of
expected arguments with the parameter list, as it was parsed from the
user, but that would involve composing the expected type. Let's keep
this simple for now.
https://bugzilla.gnome.org/show_bug.cgi?id=765710
When debugging a program or testing a change to an installed version, it
is often useful to be able to replace resources in the program or a
library, without recompiling.
To support this, for debugging and hacking purposes, it's now possible
to define a G_RESOURCE_OVERLAYS environment variable as a
colon-separated list of substitutions to perform when looking up
GResources.
A substitution has the form
"/org/gtk/libgtk=/home/desrt/gtk-overlay"
The part before the '=' is the resource subpath for which the overlay
applies. The part after is a filesystem path which contains files and
subdirectories as you would like to be loaded as resources with the
equivalent names.
In the example above, if an application tried to load a resource with
the resource path '/org/gtk/libgtk/ui/gtkdialog.ui' then GResource would
check the filesystem path '/home/desrt/gtk-overlay/ui/gtkdialog.ui'. If
a file was found there, it would be used instead.
Substitutions must start with a slash, and must not have a trailing
slash before the '='. It is possible to overlay the location of a
single resource with an individual file.
https://bugzilla.gnome.org/show_bug.cgi?id=765668
Replace the hand-written equivalent of this with the call to the
GHashTable built-in version to save a few lines of code.
The GResource code was written a couple of years before this function
existed.
Similarly, replace a set-mode usage of g_hash_table_insert() with a call
to g_hash_table_add().
https://bugzilla.gnome.org/show_bug.cgi?id=765668
GContextSpecificGroup has been somewhat broken for a rather long time:
when we remove the last reference on an object held in the group, we try
to clean up the source, but fail to actually remove it from the
mainloop.
We will soon stop emitting signals on the source (due to it having been
removed from the hash table) but any "in flight" signals will still be
delivered on the source, which continues to exist. This is a problem if
the event is being delivered just as the object is being destroyed.
This also means that we leave the source attached to the mainloop
forever (and next time will create a new one)...
This is demonstrated with the GtkAppChooser dialog which writes an
update to the mimeapps.list file just as it is closing, triggering the
app info monitor to fire just as it is being destroyed.
Karl Tomlinson correctly analysed the problem and proposed this fix.
https://bugzilla.gnome.org/show_bug.cgi?id=762994
GApplication has accepted any valid bus name as an application ID since
before the time of D-Bus activation. This includes bus names with '-'.
Several applications have even attempted support bus activation with
these names, going as far as installing D-Bus service files, without
realising that they are silently falling back to fork()/exec() on
account of the name containing a dash.
The reason for the problem is that D-Bus object paths cannot contain
dashes. We solved this problem privately in an unspecified way inside
of GApplication but substituting '_' in this case, but never made this
part of the Desktop Entry Specification.
The fact that these apps with '-' in the desktop file names aren't
actually using D-Bus activation is beside the point: their intent here
was clear. Let's avoid forcing them to rename their desktop files again
by simply accepting '-' in desktop file names and munging the path in
the way that GApplication did so historically.
The new path escaping code here has been copied more or less verbatim
from GApplication's own code for the same purpose, with only the removal
of one irrelevant part.
An update to the desktop entry specification will follow.
https://bugzilla.gnome.org/show_bug.cgi?id=764754
