Don’t update to the full CI setup from master, since its success depends
on other fixes which are only present in master. However, using v1 of
the Docker image is no longer possible since it’s been removed from the
registry. Using v3 should enable CI builds for glib-2-56 to succeed.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Previously, calling:
g_dbus_is_supported_address ("some-imaginary-transport:", NULL)
correctly returned FALSE; but calling:
g_dbus_is_supported_address ("some-imaginary-transport:", &error)
crashed with:
GLib-GIO:ERROR:../gio/gdbusaddress.c:434:g_dbus_is_supported_address:
assertion failed: (ret || (!ret && (error == NULL || *error != NULL)))
This was because, if the address component did not start with a known
transport, no error was set. Fix this, reusing an error string used by
the corresponding else branch in g_dbus_address_connect(), and adjust
the test to pass both NULL and non-NULL GError **s to this function in
every test case. This case:
g_assert (!g_dbus_is_supported_address ("some-imaginary-transport:foo=bar;unix:path=/this/is/valid", NULL));
would have caught this bug with a non-NULL GError **.
Previous version of this function started with a call to g_utf8_to_utf16(),
which also served as a NULL check, since g_utf8_to_utf16() just returns NULL
on NULL strings. Current version of this function does some filename string
checks first and converts it to utf16 only after these checks are done, and
these checks do not take into account the possibility of filename being NULL.
Fix this by explicitly checking for NULL.
The existing implementation was completely incorrect (despite the fix in
commit 566e64a66) — it always compared GVariants by pointer, rather than
by value.
Reimplement it to compare them by value where possible, depending on
their type. The core of this implementation is g_variant_compare(). See
the documentation and tests for further details of the new sort order.
This adds documentation and tests.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795735
This reverts commit 623f92ed2df41265c11c3ca1e03176033045d4de.
This fix went from one broken state to another. The real fix is to use
g_variant_compare(), which is pending review. See bug #795735.
https://bugzilla.gnome.org/show_bug.cgi?id=795735
This was causing g_param_value_defaults to return 1
for GVariant values even when the value is clearly
different from the default.
This was showing up as gtk-builder-tool stripping
non-default values for GtkActionable::action-target
from ui files.
Rebuild the fedora docker image to get the newest meson release.
(Backport 2.56: Tweaked by Philip Withnall <withnall@endlessm.com> to
drop MSYS2 changes.)
https://bugzilla.gnome.org/show_bug.cgi?id=795711
If g_get_home_dir() calculated a NULL home directory (due to $HOME being
unset and /etc/passwd being inaccessible, for example due to an
overly-zealous LSM), it would call g_once_init_leave (&home_dir, NULL),
which would emit a critical and fail to leave the GOnce critical
section. That meant that the following call to g_get_home_dir() would
deadlock in g_once_init_enter().
Fix that by setting the home directory to a made-up value in such cases
(which the documentation handily already explicitly allows).
Thanks to Simon McVittie for the analysis leading to an easy patch.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=773435
This test will only work on machines which have IPv6 enabled and have a
local IPv6 interface with ID 1. On machines which don’t (such as AWS
servers, which we run CI tests on), the GResolver tests will fail with
G_RESOLVER_ERROR_INVALID. We can’t differentiate this kind of failure
(where we’d want to skip the test) from an actual failure (where we’d
want to fail the test), so the only other option is to drop this
particular test vector. I don’t think it’s a significant loss.
This is the last fix needed to get our CI tests working reliably on
jenkins.gnome.org.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795234
There are various reasons why setting up a server might fail; it
reliably fails on AWS with IPv6 addresses (are we binding to the right
address?). Since we’re trying to test GSocket as a client, skip tests
where that happens.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795234
This fix undefined symbol link error when building for non-glibc
platform. Applications must link on libintl, it is not a public
dependency of libglib.
On glibc platforms libintl is a not found dependency and is just ignored
by meson, so it doesn't hurt to always have it.
https://bugzilla.gnome.org/show_bug.cgi?id=795406
glib-genmarshal shows redundant "time" warning message against combination with --header and --body option.
Before:
WARNING: Using --header and --body at the same time time is deprecated; use --body --prototypes instead
After:
WARNING: Using --header and --body at the same time is deprecated; use --body --prototypes instead
https://bugzilla.gnome.org/show_bug.cgi?id=795429
Signed-off-by: Kentaro Hayashi <hayashi@clear-code.com>
On gcc 4.7, we got the following error:
i686-nptl-linux-gnu-gcc --version
> i686-nptl-linux-gnu-gcc (crosstool-NG 1.20.0) 4.7.4
> $ echo '#include <glib-object.h>' | i686-nptl-linux-gnu-gcc -x c -I
staging/usr/include/glib-2.0 -I staging/usr/lib/glib-2.0/include -Wall
-Werror -c - -o /tmp/foo.o
> In file included from
staging/usr/include/glib-2.0/gobject/gbinding.h:29:0,
> from staging/usr/include/glib-2.0/glib-object.h:23,
> from <stdin>:1:
> staging/usr/include/glib-2.0/gobject/gobject.h: In function
'g_set_object':
> staging/usr/include/glib-2.0/gobject/gobject.h:725:5: error: value
computed is not used [-Werror=unused-value]
> cc1: all warnings being treated as errors
This error has been added by commit 3fae39a5d742afe73741f5fd7aa24e3ae8182f06
So enable the new g_set_object definition only if gcc >= 4.8
Fixes:
- http://autobuild.buildroot.net/results/b29a2f868438a2210873ea72f491db63175848be
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795138
Add a test for monitoring an existing local file, with the
WATCH_HARD_LINKS flag specified. This would previously cause a crash;
now it doesn’t.
This test contains a FIXME where I suspect we should be getting some
additional file change notifications from changes made through the hard
link; this requires further follow up and probably further fixes to our
inotify backend.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=755721
This gets the G_FILE_MONITOR_WATCH_HARD_LINKS flag to the state where it
doesn’t cause crashes, and essentially acts as a no-op. It will not yet
actually monitor for changes made via hard links.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=755721
The call to _start() fills in the dirname, basename, and filename
arguments according to the following rules:
dir watches: dirname filled
file watches: dirname and basename filled
hardlink: filename filled
This doesn't map to how the current inotify backend works very nicely,
so we need to adjust things a bit when creating our "sub" objects.
https://bugzilla.gnome.org/show_bug.cgi?id=755721
We do not need to use FindFirstFileW() to get a reparse tag if the
file that is being examined is not a reparse point.
This is a quick and relatively painless fix for the fact that
FindFirstFileW() fails on root directories. Since root directories
are unlikely to be reparse points (is it even possible?), not using
this function on non-reparse-points just sidesteps the issue.
https://bugzilla.gnome.org/show_bug.cgi?id=795153
If a handle was obtained from a fd that we got from up the stack,
we shouldn't call CloseHandle() on it in case of an error.
This is a bug. Luckily, it happens only on the error codepath, so,
hopefully, no one had hit it yet.
Commit 170466db accidentally partially reverted commit d1a03bc7.
Reinstate the missing check for OS X 10.9.
The Meson build does not have this problem.
https://bugzilla.gnome.org/show_bug.cgi?id=794380
If glib-networking is installed and built with libproxy support, this
test will use it. If a proxy is set in the environment, we might get
correctly told to go through it for certain accesses. However, this isn't
going to work, because the testsuite monkeys with the network monitor to
tell it that all addresses - including the proxy - aren't reachable.
We're trying to check if adding networks to a GNetworkMonitor works in
general. Proxies just get in the way here, so let's use the built in
dummy proxy resolver which just tells us that all URLs are directly
accessible.
https://bugzilla.gnome.org/show_bug.cgi?id=794801
Some very odd systems have the functions to initialise and destroy a
struct __res_state, but apparently not to do a DNS query using it. Fix
the compilation on those systems.
https://bugzilla.gnome.org/show_bug.cgi?id=794606
Previously we were only detecting typedef\*senum\s*\{, which does not
handle the case where there is an entifier for the enum itself but
not the typedef. glib-mkenums would then attempt to read the next line
looking for a matching {, but in vain.
https://bugzilla.gnome.org/show_bug.cgi?id=794506
We are transitioning to Meson for Visual Studio builds, but since the
Visual Studio projects are still around, we ought to keep them
up-to-date (and these projects are needed to build for Visual Studio
2008, at least for x64 builds).
Adapt to the source additions and merges for building
gio-querymodules.exe and gspawn-win[32|64]-helper-console.exe.
Tighten up the validation of application IDs so they are always exactly
D-Bus well-known names. This is a slight change to the accepted format,
but since anyone using the API with an application ID which was
previously valid, but which was not a valid D-Bus well-known name, would
have received an error from D-Bus when their application tried to
register on the bus, I think this break is acceptable.
It will affect any applications which have application IDs which are not
valid D-Bus well-known names, and which use the G_APPLICATION_NON_UNIQUE
flag. From a quick search in Debian Codesearch, no C applications use
that flag.
Update the documentation to use the rules from the D-Bus specification,
including the latest advice discouraging use of hyphens:
https://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-names-bus
Update the tests:
• Add the examples from the documentation to validate them.
• Especially the venerable 7-zip.org example.
• Move a couple of tests from expected-failure to expected-success:
they are valid D-Bus well-known names even if they’re a bit weird.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793400
This will make the assertion failure messages a little more useful, and
prevent the assertions being compiled out with G_DISABLE_ASSERT.
Introduces no functional changes.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793400
