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.
