It sometimes fails under valgrind, and is pointless: if the test is
wedged, it’s better to catch that with the timeout at the level of
`meson test`, which can be tailored (using `-t`) to the test environment
and wrapper.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2961#note_1600072
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Instead, iterate the `GMainContext` directly. This allows tests on
asynchronously returned values to be done in the actual test function,
rather than a callback, which should make the tests a little clearer.
This introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Do not use can_run_host_binaries() as it returns true even though
custom_target() does not currently correctly wrap target-built
tool binaries with exe_wrapper so they can be run on the host.
See https://github.com/mesonbuild/meson/issues/11029
This typically indicates a bug in the program, where a GTask has been
created, but a bug in the control flow has caused it to not return a
value.
There is one situation where it might be legitimate to finalise a GTask
without returning: if an error happens in your *_async() start function
after you’ve created a GTask, but before the async operation returns to
the main loop; and you report the error using g_task_report_*error()
rather than reporting it using the newly constructed GTask.
Another situation is where you are just using GTask as a convenient way
to move some work to another thread, without the complexity of creating
and running your own thread pool. GDBus does this with
g_dbus_interface_method_dispatch_helper(), for example.
In most other cases, it’s a bug. Emit a debug message about it, but not
a full-blown warning, as that would create noise in the legitimate
cases.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
the gio dbus codegen test has 10 test cases in it.
Each test case is given 100 seconds to complete.
That is far longer than they should need.
Furthermore, the entire test is only given 60s
to complete.
This commit makes the internal timeout more consistent
with the external timeout, by giving each of the 10
test cases 6 seconds instead of 100s.
That’s what xdgmime uses for zero-sized files (see `XDG_MIME_TYPE_EMPTY`).
Historically, GLib explicitly used `text/plain` for empty files, to
ensure they would open in a text editor. But `text/plain` is not really
correct for an empty file: the content isn’t text because there is no
content. The file could eventually become something else when written
to.
Text editors which want to be opened for new, empty files should add
`application/x-zerosize` to their list of supported content types.
Users who want to set a handler for `application/x-zerosize` on their
desktop should use
```sh
gio mime application/x-zerosize # to see the current handler
gio mime application/x-zerosize org.gnome.gedit.desktop # to set it
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2777
`HAVE_COCOA` should be used only in the places where we’re actually
depending on the Cocoa toolkit. It should not be used as a general way
of detecting building on a Darwin-based OS such as macOS.
Conversely, there are a few places in the code where we do want to
specifically detect the Cocoa toolkit (and others where we specifically
want to detect Carbon), so keep `HAVE_COCOA` and `HAVE_CARBON` around.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2802
This reverts commit 476e33c3f3.
We’ve decided to remove `G_OS_DARWIN` in favour of recommending people
use `__APPLE__` instead. As per the discussion on #2802 and linked
issues,
* Adding a new define shifts the complexity from “which of these
platform-provided defines do I use” to “which platform-provided
defines does G_OS_DARWIN use”
* There should ideally be no cases where a user of GLib has to use
their own platform-specific code, since GLib should be providing
appropriate abstractions
* Providing a single `G_OS_DARWIN` to cover all Apple products (macOS
and iOS) hides the complexity of what the user is actually testing:
are they testing for the Mach kernel, the Carbon and/or Cocoa user
space toolkits, macOS vs iOS vs tvOS, etc
Helps: #2802
Some of GLib's unit tests are under an apparently GLib-specific
permissive license, vaguely similar to the BSD/MIT family but with the
GPL's lack-of-warranty wording. This is not on SPDX's list of
well-known licenses, so we need to use a custom license name prefixed
with LicenseRef if we want to represent this in SPDX/REUSE syntax.
Most of the newer tests seem to be licensed under LGPL-2.1-or-later
instead.
Signed-off-by: Simon McVittie <smcv@collabora.com>
In g_proxy_resolver_lookup_async() we have some error validation that
detects invalid URIs and directly returns an error, bypassing the
interface's lookup_async() function. This is great, but when the
interface's lookup_finish() function gets called later, it may assert
that the source tag of the GTask matches the interface's lookup_async()
function, which will not be the case.
As suggested by Philip, we need to check for this situation in
g_proxy_resolver_lookup_finish() and avoid calling into the interface
here if we did the same in g_proxy_resolver_lookup_async(). This can be
done by checking the source tag.
I added a few new tests to check the invalid URI "asdf" used in the
issue report. The final case, using async GProxyResolver directly,
checks for this bug.
Fixes#2799
We need to make sure that such binaries are built and available at test time
or we may fail some tests requiring them (directly or through desktop file).
As per this, and because now generated desktop files are available both
at build and install time, don't skip some tests we were used to, but
actually enforce they are running.
We have some test programs on which some tests depend on, for example
appinfo-test is a tool that is used by the desktop-app-info tests.
So test can now have an 'extra_programs' key where the extra program
names can be included.
This could have been handled manually via 'depends', but this allows
to avoid repeating code and be sure that all is defined when extra
programs targets are checked.
`g_app_info_launch_default_for_uri_async()` has already returned by this
point, so waiting a long time is not really going to help.
Wait for 3× as long as the successful case took, which should allow for
long enough to catch true negatives, with a bit of variance.
On my system, this means waiting for about 14ms, rather than the 100ms
which this previous slept for. This speeds the test up by about 5%.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
We were generating .desktop files with different content when installed
tests were enabled, and thus making impossible to test some cases
because there was no built file until installed.
To avoid this, always generate both versions of desktop files while
install only the one containing the install path prefix if needed.
Given that it can be computed using an error-prone strings comparisons it
is better to provide a variable everywhere, so that we don't have the
risk of comparing values that are always false.
We have tests that are failing in some environments, but it's
difficult to handle them because:
- for some environments we just allow all the tests to fail: DANGEROUS
- when we don't allow failures we have flacky tests: A CI pain
So, to avoid this and ensure that:
- New failing tests are tracked in all platforms
- gitlab integration on tests reports is working
- coverage is reported also for failing tests
Add support for `can_fail` keyword on tests that would mark the test as
part of the `failing` test suite.
Not adding the suite directly when defining the tests as this is
definitely simpler and allows to define conditions more clearly (see next
commits).
Now, add a default test setup that does not run the failing and flaky tests
by default (not to bother distributors with testing well-known issues) and
eventually run all the tests in CI:
- Non-flaky tests cannot fail in all platforms
- Failing and Flaky tests can fail
In both cases we save the test reports so that gitlab integration is
preserved.
G_MODULE_SUFFIX is deprecated now because you will get the wrong
results using it most of the time:
1. The suffix on macOS is usually 'dylib', but it's 'so' when using
Autotools, so there's no way to get the suffix correct using
a pre-processor macro.
2. Prefixes also vary in a platform-specific way. You may or may not have
a 'lib' prefix for the name on Windows and on Cygwin the prefix is
'cyg'.
3. The library name itself can vary per platform. For instance, you may
want to load foo-1.dll on Windows and libfoo.1.dylib on macOS. This
is for libraries, not modules, but that is still a use-case that
people use the GModule API for.
g_module_build_path() does take care of (2) on Cygwin, but it
fundamentally cannot handle the possibility of multiple options for
the module name, since it does not do any I/O. Hence, it is also
deprecated.
Instead, g_module_open() has been improved so that it takes care of
all this by searching the filesystem for combinations of possible
suffixes and prefixes on each platform. Along the way, the
documentation for it was also improved to make it clearer what it
does.
Closes https://gitlab.gnome.org/GNOME/glib/-/issues/520
Closes https://gitlab.gnome.org/GNOME/glib/-/issues/1413
In principle we could script this so that each max-version.c is compiled
26 times, once per possible MAX_VERSION, but I haven't implemented
that here: just pinning to the oldest possible version is sufficient to
reproduce #2796.
These aren't included in the installed-tests, since they don't really
do anything at runtime (the important thing is that they compile
without warnings).
Reproduces: #2796
Signed-off-by: Simon McVittie <smcv@collabora.com>
Previously it was marked as failing on macOS, but commit
ed3998b390 seems to have fixed that. yay!
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1392
The access and creation time tests create a file, gets the time in
seconds, then gets the time in microseconds and assumes that the
difference between the two has to be above 0.
As rare as this may be, it can happen:
$ stat g-file-info-test-50A450 -c %y
2021-07-06 18:24:56.000000767 +0100
Change the test to simply assert that the difference not negative to
handle this case.
This is the same fix as 289f8b, but that was just modification time.
Signed-off-by: Ross Burton <ross.burton@arm.com>
Freebsd doesn't always have /proc mounted, so relying on
/proc for the tests isn't ideal.
This commit changes the desktop-app-info tests to use
mkfifo instead of /proc/../fd/.. to relay terminal
arguments.
Might help with this error message I'm seeing in CI:
/tmp/bin-path-H1UQT1/gnome-terminal: cannot create /proc/38961/fd/6: No such file or directory
In case the XDG database is not initialized yet we may try to sniff a
0-length data, making our content-type routines to mark non-empty files
as `application/x-zerosize`.
This is wrong, so in case the sniff size is not set, let's just
try to read the default value. To avoid false-application/x-zerosize
results (that are not something we want as per legacy assumptions).
See: https://bugzilla.gnome.org/show_bug.cgi?id=755795
Fixes: https://gitlab.gnome.org/GNOME/glib/-/issues/2742
It’s often (but not always) failing on the CI machines with a timeout
which looks like the FD sharing via `/proc` isn’t reliably working.
Disable this test (but not the whole `desktop-app-info` test suite) on
FreeBSD until someone who has access to a FreeBSD machine can debug it.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2781
The implementation of `g_desktop_app_info_launch_uris()` will spawn the
exec file once for each URI unless the desktop file has a placeholder in
its Exec line which supports multiple URIs at once.
The fake terminal doesn’t have such a placeholder, so the fake terminal
script is spawned twice in quick succession, once for each URI. Since it
was making two separate printf calls (one to print the output to the
pipe, and one to terminate it with a newline), it’s possible that two
invocations of the script could interleave their printf calls, resulting
in pipe input along the lines of `URI1 URI2 newline newline` rather than
`URI1 newline URI2 newline`.
This would cause the test to fail.
Fix that by making the script atomic by moving the newline into the
first printf call.
See: https://gitlab.gnome.org/GNOME/glib/-/jobs/2339109:
```
\# Fake 'nxterm' terminal created as: /tmp/bin-path-R6GWT1/nxterm
\# 'nxterm' called with arguments: '-e true nxterm-argument /tmp/bin-path-R6GWT1-e true nxterm-argument /tmp/test_desktop-app-info_CO92T1/desktop-app-info/launch-uris-with-terminal/nxterm/.dirs/data'
Bail out! GLib-GIO:ERROR:../gio/tests/desktop-app-info.c:1294:test_launch_uris_with_terminal: assertion failed (g_strv_length (output_args) == 4): (7 == 4)
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The cancellable may be cancelled just after the operation succeeds in a
different thread. So instead of checking whether the cancellable is
cancelled, check whether the operation returned a `CANCELLED` error, and
*then* assert that the cancellable is cancelled.
This should fix
https://pwithnall.pages.gitlab.gnome.org/-/glib/-/jobs/2338552/artifacts/_build/meson-logs/testlog.txt:
```
ok 1 /unix-streams/basic
Bail out! GLib-GIO:ERROR:../gio/tests/unix-streams.c:149:main_thread_skipped: assertion failed (err == (g-io-error-quark, 19)): err is NULL
stderr:
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The g_content_type_get_icon() function for win32 can lookup the
DefaultIcon associated with .txt and return a different result.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
On Win32, we get paths with mixed \\ and /, use GFile to resolve and
normalize the paths before comparing.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
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.
