Otherwise, the build will fail when the toolchain is static-only, even
with -Ddefault_library=static. I talked to a Meson developer in their
IRC channel, who told me that the correct fix was to ensure that
shared_library is only used if default_library != static.
Simulate launching applications using terminals by creating scripts on
the fly that are named as the terminals that we support, ensuring that
these are called with the arguments that we expect.
Related to: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2839
Check if thumbnails are created in the path we expect and that we can
retrieve their information, but also that we try to get the biggest size
available when multiple are available.
We've various macros definitions that are depending using C++ features
that may not work in all the standard versions, so recompile the cxx
tests that we have in all the ones we want to support.
desktop-app-info test may fail when repeated with multiple concurrent
processes because the actions test relies on checking the existence of
in the shared build directory, so by doing something like:
meson test -C _build desktop-app-info -t 0.3 --repeat 80
We may end up in timeout errors, because we are waiting for files that
have been already deleted by other processes.
To avoid this, let's rely on writing the files on `$G_TEST_TMPDIR` env
variable, that is always set and unique, given that we're using the
G_TEST_OPTION_ISOLATE_DIRS test option.
We were testing the case in which we were opening an actual file, and so
potentially using a fd-list, however we were missing the case in which a file
was not existent.
And in such case we are incidentally hitting a leak now.
All of these warnings indicate programmer error, so critical is most
appropriate here.
Exceptions: deprecation warnings are just warnings. Also, warnings that
are worded with uncertainty can remain warnings rather than criticals.
Enumeration members should either have the name of the type as their
prefix, or they should all have the same prefix.
The "default flags" enumeration member for GApplicationFlags is
unfortunately named G_APPLICATION_FLAGS_NONE, while every other member
of the same type has a G_APPLICATION prefix. The result is that the nick
name of the enumeration member is "flags-none", and that language
bindings will have to use something like
Gio.ApplicationFlags.FLAGS_NONE.
To fix this API wart, we can deprecate the FLAGS_NONE member, and add a
new DEFAULT_FLAGS.
A shell one-liner was enough to set GIO_LAUNCHED_DESKTOP_FILE_PID,
but ideally we also want to do the equivalent of sd_journal_stream_fd()
to set up its standard output and standard error streams.
Ideally we would call sd_journal_stream_fd() in a process that will
exec the real program, otherwise it will report the wrong process ID
in the Journal, but we can't easily do that in a forked child when
using posix_spawn() for subprocesses.
This reverts commit 2b533ca99a.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The dominant implementations of the well-known session and system
message buses are the reference implementation from the dbus project
(dbus-daemon) and the sd-bus-based reimplementation dbus-broker, both
of which have correct implementations for EXTERNAL authentication with
an unspecified authorization identity.
This makes it reasonably safe to assume that the well-known message
buses can cope with the unspecified authorization identity, even if we
cannot make the same assumption for custom servers such as the ones
used in ibus and gvfs (which might have been started with an older
GLib version before upgrading GLib in-place).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Instead of using a GDBusConnection, this does the handshake at a lower
level using specific strings in the SASL handshake, to verify that we
will interoperate with various clients including sd-bus, libdbus and
older versions of GDBus.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We don't need a cpp toolchain for building glib so lets just
automatically disable tests requiring one when not available.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
The test was flacky because we were only relying on the presence of a
file, while the callback could have not been called yet, while ensure
for both assumptions to be true before stop iterating the loop.
These headers have all been written manually, by looking through the git
log for each file and noting the copyright of each significant
contribution.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1415
It doesn't make sense for a proxy resolver to return NULL without an
error on the first call. Whereas a DNS resolver would do this to
indicate that a query completed successfully but found no results, a
proxy resolver should return "direct://" instead. Therefore, if we are
going to return NULL, we ought to have an error as well. Let's make sure
this actually happens by adding some fallback errors just in case
GProxyResolver feeds us weird results.
Additionally, we should not return any errors except
G_IO_ERROR_CANCELLED after the very first iteration. This is an API
contract of GSocketAddressEnumerator. Let's add some checks to ensure
this.
Note that we have inadequate test coverage for GProxyAddressEnumerator.
It's tested here only via GSocketClient. We could do a bit better by
testing it directly as well. For example, I've added tests to see what
happens when GProxyResolver returns both a valid and an invalid URI, but
it's not so interesting here because GSocketClient always uses the valid
result and ignores the error from GProxyAddressEnumerator.
Fixes#2597
This has no practical impact, since it's only a test, and none of the
test code would have hit this bug, but the GTestProxyResolver's check to
see if the URI scheme is simple:// currently only compares the first
four bytes of the string, so it's actually only checking for the "simp"
and would match anything else after that, e.g. "simpleton://". This is
surely not intended.
This was causing intermittent failures on macOS, depending on whether
the tmpdir ended with a `/` or `/some-dir`. `g_strrstr()` is not the
right function to use to extract a basename from a path, for this
reason.
When it failed, the macOS test was failing with:
```
ok 16 /gsubprocess/env
Bail out! GLib-GIO:ERROR:../gio/tests/gsubprocess.c:1507:test_cwd: assertion failed (basename == tmp_lineend_basename): ("/T\n" == "/\n")
```
The test now passes reliably, which means that it can be removed from
the list of expected failures on macOS.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1392
On macOS the comparison was failing as one of the paths had a trailing
slash while the other didn’t.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
