The Python version was added for the Meson build, but we might as well
use it from autotools too, since it does exactly the same thing as the
Perl version (modulo not including a trailing linebreak, but that
doesn’t matter).
Works fine with Python 2.7 or Python 3.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=790147
This will fix a few broken links in the documentation, and shut up a
load of gtk-doc warnings (but certainly not all of them).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=790015
Uris may be altered by the following code, which breaks xdg-open:
file = g_file_new_for_commandline_arg (arg[i])
uri = g_file_get_uri (file);
Examples of possible uri changes:
mailto:email -> mailto:///email
magnet:?xt=urn:hash -> magnet:///?xt=urn:hash
ssh://user@host -> sftp://user@host
This patch causes that uris aren't preprocessed for locations with
scheme, however absolute and relative paths are still preprocessed.
https://bugzilla.gnome.org/show_bug.cgi?id=779182
create_cstr_from_cfstring_with_fallback() is allowed to be called when str == NULL
but create_cstr_from_cfstring() isn't which leads to warnings in the console.
Fix this by adding NULL checks into create_cstr_from_cfstring_with_fallback().
https://bugzilla.gnome.org/show_bug.cgi?id=788936
The patch basically just grabs the implementation of g_content_type_get_icon_internal()
from gcontenttype.c - the only difference is that it first converts UTI to MIME using
g_content_type_get_mime_type() and at the end frees this temporary MIME type.
https://bugzilla.gnome.org/show_bug.cgi?id=788936
This commit adds new W32-only functions to gstdio.c,
and a new header file, gstdioprivate.h.
These functions are:
g_win32_stat_utf8()
g_win32_lstat_utf8()
g_win32_fstat()
and they fill a private structure, GWin32PrivateStat,
which has all the fields that normal stat has, as well as some
extras.
These functions are then used throughout glib and gio to get better
data about the system. Specifically:
* Full, 64-bit size, guaranteed (g_stat() is forced to use 32-bit st_size)
* Full, 64-bit file identifier (st_ino is 0 when normal stat() is used, and still is)
* W32 File attributes (which stat() doesn't report); in particular, this allows
symlinks to be correctly identified
* Full, 64-bit time, guaranteed (g_stat() uses 32-bit st_*time on 32-bit Windows)
* Allocated file size (as a W32 replacement for the missing st_blocks)
st_mode remains unchanged (thus, no S_ISLNK), so when these are given back to
glib users (via g_stat(), for example, which is now implemented by calling g_win32_stat_utf8),
this field does not contain anything unexpected.
g_lstat() now calls g_win32_lstat_utf8(), which works on symlinks the way it's supposed to.
Also adds the g_win32_readlink_utf8() function, which behaves like readlink()
(including its inability to return 0-terminated strings and inability to say how large
the output buffer should be; these limitations are purely for compatibility with
existing glib code).
Thus, symlink support should now be much better, although far from being complete.
A new W32-only test in gio/tests/file.c highlights the following features:
* allocated size
* 64-bit time
* unique file IDs
https://bugzilla.gnome.org/show_bug.cgi?id=788180
The GAsyncResult documentation didn't specify the context in which the
GAsyncReadyCallback is expected to be invoked. Since asynchronous
operations can be implemented in various ways involving GSources,
threads and coroutines, it is useful to mention what the standard
expections are.
Unfortunately, since this was left undefined for so long, we can only
phrase it as a suggestion, and not as a hard requirement.
https://bugzilla.gnome.org/show_bug.cgi?id=783825
Where we were already treating GHashTables as sets, modify them to use
the set-specific APIs g_hash_table_add() and g_hash_table_contains(), to
make that usage more obvious and less prone to being broken.
Heavily based on patches by Garrett Regier <garrettregier@gmail.com>.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=749371
This is needed by gnome-control-center and gnome-settings-daemon; it
makes existing checks from gunixmounts.c public.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788927
In my previous patch, I failed to call g_source_remove_unix_fd() in
order to actually stop polling the fd of the closed socket.
The test did not catch this, because the test only checks that the right
source callback is dispatched properly. I don't know how to test this.
https://bugzilla.gnome.org/show_bug.cgi?id=723655
Checks that after a GSocket is closed, a source created off it
with g_socket_create_source() will dispatch exactly once with
G_IO_NVAL.
Based on a patch by Mikhail Zabaluev
https://bugzilla.gnome.org/show_bug.cgi?id=723655
We're eventually going to drop Autotools, but in the meantime we should
probably use idiomatic options and reduce warnings.
GLib is pretty much already safe for subdir-objects to be enabled,
except in the GIO tests, where the build references files that are
generated in a different level. For that, we can use the same solution
employed by GTK+, and link the appropriate file in the right
sub-directory.
https://bugzilla.gnome.org/show_bug.cgi?id=788989
Ensure that the debug call won't crash if create_cstr_from_cfstring
returns NULL, fix the leak of that CFArrayRef, and make explicit the
failure condition of LSFindApplicationForInfo.
https://bugzilla.gnome.org/show_bug.cgi?id=788936
During testing with gdk-pixbuf I noticed failures during content type
to mime conversion. The root reason was the unsafe conversion used
in create_cstr_from_cfstring. The problem was addressed in commit
c60226e0a1 but that was reverted. I noticed the commit only
when I had fixed the problem. In addition I added a test to check
the content type to mime conversion on MacOS. This problem is
discussed in Bug #788936.
See: https://bugzilla.gnome.org/show_bug.cgi?id=788936
It adds support for source-specific multicast IGMPv3.
Allow receiving data only from a specified source when joining
a multicast group.
g_socket_join_multicast_group_ssm can be called multiple times
to allow receiving data from more than one source.
Support IPv4 and IPv6.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=740791
Closes: Bug #788401
The problem is described here:
https://bugzilla.gnome.org/show_bug.cgi?id=788401
This patch introduces the use of the xdgmime system to guess
the content type from data. So you can guess for example the
type public.svg-image from the file content of a svg file.
This patch only applies to MacOS. A test for the regression
is also included.
This reverts commit c60226e0a1.
Pushed without review. This should be reviewed on bug #788936 first.
Several issues with the patch:
• Takes the string length unnecessarily early.
• Calls CFRelease(str) before g_strdup(cstr) which could lead to
use-after-free.
• Code style issues.
• Don’t want to encourage pushing patches without review.
priv->map_object_path_to_object_proxy must be protected to avoid
concurrent access by multiple threads. Move the hash table insertion
into the critical section.
https://bugzilla.gnome.org/show_bug.cgi?id=788368
On slow ARM machines doing parallel builds, there's no guarantee that
we'll get scheduled in a window between (100ms|250ms) and 500ms.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=769674
On slow ARM machines doing parallel builds, there's no guarantee that
we'll get through this in 5 seconds.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=769674
"len" is only used by some platforms' implementations (as controlled
by various autoconf/#ifdef tokens) and only in a small codeblock in
those cases, but was declared based on a looser #ifdef heuristic and
in a larger scope. The result is an unused-variable warning when built
on some platforms. Move declaration to the local codeblocks that use
the variable, which also restricts it to the narrower set of platforms
where those codeblocks are used.
https://bugzilla.gnome.org/show_bug.cgi?id=689323
ssize_t is supported widely, but not universally, so use gssize instead.
Currently only one piece of code actually *needs* this change to be compilable
with MSVC, the rest are mostly in *nix parts of the code, but these are changed
too, for symmetry.
https://bugzilla.gnome.org/show_bug.cgi?id=788180
• `gdbus monitor` can’t work at all for non-message-bus connections,
since it can’t subscribe to signals.
• Other tab completions for names depend on the connection being a
message bus connection, but we still need to print `--dest` (etc.)
when tab completing them, even if we can’t print a list of
available names.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788594
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
