As the GVariant returned in secret_service_real_prompt_finish should
be already sunk by secret_prompt_perform_finish, calling
g_variant_ref_sink actually increases the refcount and causes a leak.
Signed-off-by: Daiki Ueno <dueno@src.gnome.org>
GLib is discussing deprecating/removing it upstream [1] since it has
only limited uses. Next to that, it seems to bork stack traces here when
using ASAN (for which you also have to specify `G_SLICE=always-malloc`
and some other envvars too).
In other words, let's just get rid of using `GSlice` and call the
allocation APIs directly.
[1]: https://gitlab.gnome.org/GNOME/glib/-/issues/1079
Our GAsyncInitable implementations in SecretService, SecretCollection,
and SecretItem internally wrap GDBusProxy::init_async and perform
additional error processing. To chain up we used to pass around a
single GTask, which caused an issue in the (additional) error path:
GDBusProxy::init_async may have already called
g_task_return_boolean(task, TRUE) and in that case GLib produces the
following warning:
g_task_return_error: assertion '!task->ever_returned' failed
This fixes the issue by creating a temporary GTask around
GDBusProxy::init_async call.
Signed-off-by: Daiki Ueno <dueno@src.gnome.org>
The condition checking g_task_is_valid was inverted, resulting in errors
being ignored.
Move the check to a g_return_val_if_fail to be in line with all other
uses of g_task_is_valid.
Fixes https://bugs.archlinux.org/task/63666
GSimpleAsyncResult is deprecated in favor of the simpler GTask, so use
that instead. This cuts down on the deprecation warnings.
I wanted to do both separately, but porting one without the other led to
some faulty casts from GSimpleAsyncResult to GTask (and vice versa).
Allow parallel building and testing by using a single Makefile.am
Implement parallel testing using TAP, with various drivers and
compilers living in the build/ directory.
Fix all sorts of issues that this caused, including builddir != srcdir,
leaks in tests and so on.
It would have been nice to break out all the above into separate
commits ... blush.
Much like g_dbus_connection_call() we now pass our return_type value
when starting the async operation. This unbreaks vala and various
other bindings that make assumptions about the form of xxx_finish()
async calls.
This is an API/API break, but its to the portion of the library
marked as unstable. Only used by seahorse (in jhbuild) and updated
usage there.
The previous way of setting collection_gtype and item_gtype
on SecretServiceClass was not very bindings friendly. Instead
allow per instance virtual functions to return the GTypes.
The _new() suffix confuses vala and gobject introspection thinking
that it's a constructor, and there's no way to tell it otherwise. And
things really get messy because they're async functions.
So while we're still unstable, rename these functions to
secret_service_open() secret_service_open_sync() and
secret_service_open_finish().
This is an API/API break, but its to the portion of the library
marked as unstable. Only used by seahorse (in jhbuild) and updated
usage there.
* This is necessary because sometimes we don't want to complain,
for expected errors, when running nested operations.
* The fact that we have to do this is silly, and soon there
will be a solution in glib itself.
https://bugzilla.gnome.org/show_bug.cgi?id=688165
* C callers need to use libsecret-0 pkg-config file for stable and
libsecret-unstable for unstable stuff.
* Vala callers need to '--pkg libsecret-unstable' for unstable
* GObject Introspection callers need to use the SecretUnstable package
* Death by a thousand paper cuts from gir and vapi not liking
the fact that the secret.h file was not usable uninstalled
and installed in the same way.
