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
g_desktop_app_info_load_from_keyfile() refuses to load .desktop files
where the executable doesn't exist. Therefore whether or not the .desktop
file added in commit 148995544 is actually considered during tests depends
on /usr/bin/flatpak being installed. This isn't a safe assumption to make,
so use /bin/sh to test filtering of "prefix" commands.
https://bugzilla.gnome.org/show_bug.cgi?id=795488
The executable name can be a useful bit of information to match on in
searches where it differs from the name (for example because the latter
is localised), but will produce surprising results where the real appli-
cation is executed by a shared binary (for example interpretors like
gjs or python, or sandboxes like flatpak).
Address this by adding a blacklist of binary names that are ignored
in search.
https://bugzilla.gnome.org/show_bug.cgi?id=795488
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 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
While 333 runs is very likely to reproduce the bug, Milan has previously
reproduced it with as few as 9 runs. Since this test will be run by the
CI machinery quite often, a lower number of runs each CI run will still
probably catch any regressions over time.
This reduces the total test runtime from 33s to 2s.
https://bugzilla.gnome.org/show_bug.cgi?id=793727
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
When using g_network_monitor_get_default() from another thread, it’s
possible for network-changed events to be processed after an instance of
GNetworkMonitor has been disposed, causing use-after-free problems.
Fix that by moving some of the initialisation into the GInitable.init()
chain, rather than in a main context idle callback.
This includes a unit test which probabilistically reproduces the bug
(but can’t do so deterministically due to it being a race condition).
Commit amended by Philip Withnall <withnall@endlessm.com> before
pushing.
https://bugzilla.gnome.org/show_bug.cgi?id=793727
When using g_settings_bind(), if a range binding triggers a range check
failure, g_settings_binding_property_changed() will return early, but it
won't cleanup properly causing some leaks. The binding will also still
be marked as 'running', which causes an assertion failure when trying to
free it:
"g_settings_binding_free: assertion failed: (!binding->running)"
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=794805
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
The `mount_monitor` variable is only set if the boolean
`with_mount_monitor` variable is set to TRUE, but the compiler does not
know that, so it'll warn when calling `g_clear_object()` even if the
clearing operation is gated with the same boolean.
Initializing with NULL does not cost us anything, and eliminates a
conditional branch.
https://bugzilla.gnome.org/show_bug.cgi?id=794732
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
If calling g_subprocess_communicate() on a GSubprocess with no
stdout/stderr pipe, a critical warning would be emitted from
g_memory_output_stream_steal_as_bytes(), as it would be called on a NULL
output stream.
Fix that, improve the relevant GIR annotations, and expand the unit
tests to cover it (and various other combinations of flags).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793331
g_data_input_stream_read_upto() was introduced in 2.26; now it’s GLib
2.56, we can probably deprecate the old versions (since the handling of
consuming the stop character differs between the sync and async versions
of it).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=584284
This is a variant of g_file_get_path() which returns a const string to
the caller, rather than transferring ownership.
I've been carrying `gs_file_get_path_cached()` in libgsystem and it
has seen a lot of use in the ostree and flatpak codebases. There are
probably others too.
I think language bindings like Python/Gjs could also use this to avoid
an extra malloc (i.e. we could transparently replace
`g_file_get_path()` with `g_file_peek_path()`.
(Originally by Colin Walters. Tweaked by Philip Withnall to update to
2.56, change the function name and drop the locking.)
https://bugzilla.gnome.org/show_bug.cgi?id=767976
Custom desktop file fields may be translated, but there is currently
no non-hacky way to look up the localized value; fill get gap with
a small wrapper around g_key_file_get_locale_string().
https://bugzilla.gnome.org/show_bug.cgi?id=779413
This was introduced in bug #742997, but not added to the Makefile.am, so
it’s missing from tarballs.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
https://bugzilla.gnome.org/show_bug.cgi?id=792322
Properly define GLIB/GOBJECT_STATIC_COMPILATION when static build is enabled.
Use library() instead of shared_library() to allow selecting static builds.
https://bugzilla.gnome.org/show_bug.cgi?id=784995
In order to enrich information displayed by GApplication command line
handling when --help is invoked, 3 new methods are proposed:
. g_application_set_option_context_parameter_string
. g_application_set_option_context_summary
. g_application_set_option_context_description
Those methods interact with the GApplication's internal GOptionContext
which is created for command line parsing in g_application_parse_command_line.
(please refer to the GOptionContext class for more information about option
context, parameter string, summary and description.)
To illustrate the 3 methods, an example is provided:
. gapplication-example-cmdline4.c
to suppress a compiler error with stricter warnings enabled (GCC):
gdbus-test-codegen.c: In function ‘on_handle_get_self’:
gdbus-test-codegen.c:403:26: error: format ‘%p’ expects argument of type
‘void *’, but argument 2 has type ‘GThread * {aka struct _GThread *}’
[-Werror=format=]
s = g_strdup_printf ("%p", g_thread_self ());
https://bugzilla.gnome.org/show_bug.cgi?id=792099
Previously, we waited an arbitrary 100ms or 200ms and then asserted
that the events had happened, but that might fail if the machine is
slow or heavily loaded.
We still wait for an arbitrary time for negative tests (asserting
that no more signals are received) because we don't have any way
to do better here.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884661https://bugzilla.gnome.org/show_bug.cgi?id=791744
New test to make sure we exercise the code paths in gdesktopappinfo.c
that get triggered when g_desktop_app_info_launch_uris_with_spawn()
is used (i.e. unknown app ID, no session bus), both for when either
a single URI or multiple ones are expected by the application.
https://bugzilla.gnome.org/show_bug.cgi?id=791337
Putting a <!-- --> in plural<!-- -->s was an old hack used to fix
linking the symbol with gtk-doc when gtk-doc didn’t know about plural
forms. gtk-doc does now know about plural forms, so the hack can be
removed.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
When using gdbus-codegen to produce generated code for a method with
an out parameter with a signature like 'as', make sure to include
an "(array)" annotation for that parameter.
(Reworked by Philip Withnall to improve code formatting.)
https://bugzilla.gnome.org/show_bug.cgi?id=741167
In the vast majority of cases, we can avoid temporary
allocations for paths in g_resources_enumerate_children().
In the case we need to add a suffix "/", we can usually just
build the path on the stack. In other cases, we can completely
avoid the strdup, which appears to only have been added for
readability. If the path is really long, we fallback to doing
what we did before, and use g_strconcat().
In the case of Builder, this saved 5.3mb of temporary
allocations in the process of showing the first application
window.
https://bugzilla.gnome.org/show_bug.cgi?id=790275
Previously, the path canonicalization for resources had liberal use of
strlen() and memmove() while walking through the path. This patch avoids
any secondary strlen() and removes all use of memmove().
A single allocation is created up front as we should only ever need one
additional byte more than then length of the incoming path string.
To keep the implementation readable, the mechanics are kept in external
functions. memrchr() was not used due to its lack of portability.
This is faster in every test case I've tested. Paths that contain
relative ../ have the most speedup.
https://bugzilla.gnome.org/show_bug.cgi?id=790310
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
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
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
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
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.
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
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
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
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
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
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
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
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
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.
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.
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
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
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
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
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
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
-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
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.
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
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
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
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
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.
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
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
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 ensures that the generated file is always the same (not dependent
on the build machine's environment), making the build reproducible.
Thanks to Jérémy Bobbio <lunar@debian.org> for the Debian bug report and
patch.
https://bugzilla.gnome.org/show_bug.cgi?id=763617
* On W32 use a real directory (SYSTEMROOT) instead of '/etc/'
* Disable test_symbolic_icon() as it can't be passed (symbolic icons are not
really supported)
* PowerPoint/Gettext test still fails, presumably because msvcrt qsort() moves
the entires (both have the same priority)
https://bugzilla.gnome.org/show_bug.cgi?id=735696
It was removed, apparently accidentally, in commit 5b48dc4.
This had the side-effect that it wasn't included in tarball releases,
which means that commit ab7b4be doesn't work when building a package.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=734469
Reviewed-by: Colin Walters <walters@verbum.org>
Add string serialisation functions for GNetworkAddress, GSocketAddress,
GUnixSocketAddress, GInetSocketAddress, GNetworkService and
GSocketConnectable. These are intended for use in debug output, not for
serialisation in network or disc protocols.
They are implemented as a new virtual method on GSocketConnectable:
g_socket_connectable_to_string().
GInetSocketAddress and GUnixSocketAddress now implement
GSocketConnectable directly to implement to_string(). Previously they
implemented it via their abstract parent class, GSocketAddress.
https://bugzilla.gnome.org/show_bug.cgi?id=737116
If an error in the underlying sendmmsg() syscall occurs after
successfully sending one or more messages, g_socket_send_messages()
should return the number of messages successfully sent, rather than an
error. This mirrors the documented sendmmsg() behaviour.
This is a slight behaviour change for g_socket_send_messages(), but as
it relaxes the error reporting (reporting errors in fewer situations
than before), it should not cause problems.
https://bugzilla.gnome.org/show_bug.cgi?id=751924
Add support for receiving multiple messages with a single system call,
using recvmmsg() if available. Otherwise, fall back to looping over
g_socket_receive_message().
This adds new API, g_socket_receive_messages(), and corresponding unit
tests.
https://bugzilla.gnome.org/show_bug.cgi?id=751924
We don't need to run binaries we just built in order to successfully
build GLib and friends any more.
Since commit b74e2a7, we don't need to run glib-genmarshal when building
GIO; since commit f9eb9eed, all our tests (including the ones that do
need to run binaries we just built) are only built when running "make
check", instead of unconditionally at every build.
This means that we don't need to check for existing, native binaries
when cross-compiling, and fail the configuration step if they are not
found — which also means that you don't need to natively build GLib for
your toolchain, in order to cross-compile GLib.
We can also use the cross-compilation conditional, and skip those tests
that require a binary we just built in order to build.
https://bugzilla.gnome.org/show_bug.cgi?id=753745
Enhance GTestTlsBackend to allow setting the issuer property of
GTlsCertificates, and add a test to ensure certificate chain
construction with g_tls_certificate_new_from_pem() works as expected.
https://bugzilla.gnome.org/show_bug.cgi?id=754264
These tests clear up a misunderstanding of mine: Monitoring
nonexisting files and directories *does* work with the inotify
implementation, it just has a very long timeout for scanning
for missing locations, so the test needs to take that into
account.
Add a new test which checks that atomically replacing a file that
is being monitored by GFileMonitor produced the expected events.
The test can easily be expanded to cover other file monitoring
scenarios.
This is a binding-friendly version of g_dbus_connection_register_object.
Based on a patch by Martin Pitt and the code of g_bus_watch_name_with_closures.
https://bugzilla.gnome.org/show_bug.cgi?id=656325
