This reverts commit 398c048c66.
It got removed because it used to cause build issues, but now that we
have a CI let's hope it won't be a problem any more.
We got a complaint here that trashing via the
portal deletes the target of a symlink, not the
symlink itself. It turns out that following the
symlink already happens on the glib side.
https://github.com/flatpak/xdg-desktop-portal/issues/412
Even if g_variant_get_va(), which we eventually call, checks on the
validity of the value argument, check it early to avoid surprises, such
as this intermittent FreeBSD test failure:
(/var/tmp/gitlab_runner/builds/3fe11159/0/GNOME/glib/_build/gio/tests/gdbus-connection:65788): GLib-CRITICAL **: 15:13:25.670: g_variant_get_va: assertion 'value != NULL' failed
Skipped tests use "77" as the return value, so return 77 instead of 0
when the static-link.py test gets skipped because of a missing
environment variable.
If the fuse module is loaded but /dev/fuse doesn't exist, it's likely
that we're running in a rootless container, or a badly setup one, and we
won't be able to use fuse, so skip this test.
This happened on my local system using podman running as a normal user,
but this apparently works as expected in our CI[1].
[1]: https://gitlab.gnome.org/GNOME/glib/merge_requests/466
It's not supported on macOS' clang compiler and will fail the visibility
check and thus make the G_GNUC_INTERNAL attribute do nothing.
Compiler stderr:
/var/folders/nt/j2v2x4wd5cl33fq27mm31mwc0000gn/T/tmpxxf2zzi_/testfile.c:13:19: error: target does not support 'protected' visibility; using 'default' [-Werror,-Wunsupported-visibility]
__attribute__ ((visibility ("protected")))
^
1 error generated.
Checking if "GNU C visibility attributes test" compiles: NO
Add a Python-based test wrapper for the `gdbus-codegen` executable,
similar to the existing tests for `glib-mkenums` and friends.
Add a few basic tests to begin with, but this doesn’t approach anywhere
near full coverage.
The next step is to move the existing Meson-based `gdbus-codegen` tests
from `gio/tests/meson.build` into the Python test suite.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1612
Previously, running `gdbus-codegen` with no arguments would exit
successfully with no output. While technically correct, that seems
unhelpful.
Require at least one interface file to be specified, so the user gets an
error message if they don’t specify any.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
It’s not particularly useful to put the gdbus-codegen version or the
name of the input file into the output from `gdbus-codegen`, and it
makes the output less reproducible. Drop it.
Also clarify the licensing.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1612
If not doing this it might happen that the cancelled signal is emitted
between reaching a reference count of 0 and finalizing the GSource, at
which point part of the GSource is already freed and calling any GSource
functions is dangerous.
Instead do this from the dispose function. At this time the GSource is
not partially freed yet and calling any GSource API is safe as long as
we ensure that we have a strong reference to the GSource before calling
any GSource API.
Especially check for a valid reference count. This is possible now in
all cases because of the addition of the dispose function and makes
usage of already finalized/finalizing GSources more obvious than the
use-after-free that would otherwise happen.
This allows GSource implementors to safely clear any other references to
the GSource while the GSource is still valid, unlike when doing the same
from the finalize function.
After the dispose function has run, it is valid for the reference count
of the GSource to be > 0 again to allow the case where another thread in
the mean-time got access to the GSource reference before the dispose
function was called.
This allows fixing a thread-safety issue in the GCancellable, GstBus and
various other GSource implementations.
This doesn’t change how they run, but does split the code out a bit and
mean we can interleave it with comments. Should make it a little less
vile.
Suggested by Emmanuele Bassi; see !1252.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This makes things slightly more extensible in future, but introduces no
functional differences right now.
See https://docs.gitlab.com/ce/ci/yaml/README.html#extends.
Suggested by Jordan Petridis.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
_kqsub_free assumes the caller has called _kqsub_cancel before calling
it. It checks if both 'deps' and 'fd' have been freed and aborts when
the condition is not met. Since the only caller of _kqsub_free is
g_kqueue_file_monitor_finalize, which does call _kqsub_cancel before
calling _kqsub_free, it seems to be correct for _kqsub_free to assert
values of these two members there.
However, it is possible for _kqsub_cancel to return early without
freeing any resource _kqsub_free expects to be freed. When the kevent
call fails, _kqsub_cancel does not free anything and _kqsub_free aborts
with assertion failure. This is an unexpected behavior, and it can be
fixed by always freeing resources in _kqsub_cancel.
Fixes: https://gitlab.gnome.org/GNOME/glib/issues/1935
"gio mount" doesn't print anything in case of success, however "gio mount -d"
prints "Mounted [id] at [mount_path]", which is inconsistent. It might probably
make sense for fstab volumes, but "gio mount -d" now support UUIDs which are
heavily used for daemon mounts and I think that it is not wise to print
"/run/user/$UID/gvfs" mount paths. The mount path can be still found over
"gio mount -l". Let's remove this message to make it more consistent.
"gio mount" only allows mounting volumes using device files, but not using
UUIDs. Volume monitors for various GVfs locations usually supports just UUIDs.
It would be handy to support them also for testing purposes (because
"g_file_mount_enclosing_volume()" does something else than "g_volume_mount()"
in case of shares provided by GOA volume monitor for example). Let's update
"-d" option to support also UUIDs.
https://gitlab.gnome.org/GNOME/gvfs/issues/251
