The "removed" argument of the models "items-changed" signal was
forgotten making it misbehave when origins do get removed:
GLib-GObject[1287799]: WARNING: invalid (NULL) pointer instance
GLib-GObject[1287799]:CRITICAL: g_signal_connect_object: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
It was introduced in 4b51f340c8
to prevent accessing user home during tests:
The only place where this the home is currently accessed is when loading
SIP accounts and these can already be overriden with
CALLS_SIP_ACCOUNT_FILE.
It seems that XDG_CONFIG_HOME is propagated to the flatpak runner,
even though it was only overriden for the test suite.
========================================================================
Building module calls in /builds/devrtz/calls/.flatpak-builder/build/calls-1
========================================================================
Error: module calls: Error opening directory '/builds/devrtz/calls/_build/calls': Permission denied
Reported at https://gitlab.gnome.org/Infrastructure/GitLab/-/issues/596#note_1654082
Operations on the database are not cancellable, so we need to ensure any
critical code (such as database migration) has completed.
Otherwise we risk leaving the database in a locked state (or worse):
WARNING **: 09:24:53.428: Failed to determine schema version: sqlite3_prepare_v2 failed: database is locked: CREATE TABLE IF NOT EXISTS _gom_version (version INTEGER);
As Calls cannot deal with call waiting we should disable it entirely.
This works around issues where call audio get's completely broken once
the waiting call is disconnected on the BM818 modem shipped with the
Librem 5.
See https://source.puri.sm/Librem5/OS-issues/-/issues/311
It has been reported that the BM818 sometimes unexpectedly
changes the call state from "active" back to "ringing-in"
(as reported by ModemManager) shortly after accepting an incoming call.
ModemManager[734]: <info> [modem1/call1] user request to accept call
ModemManager[734]: <info> [modem1/call1] call is accepted
ModemManager[734]: <info> [modem1/call1] call state changed: ringing-in -> active (accepted)
ModemManager[734]: <info> [modem1/call1] call state changed: active -> ringing-in (unknown)
This leads to a failed assertion and program termination.
Instead of crashing raising a critical warning is more appropriate
and may allow the user to pick up the call after all.
Closes: #547
self->best_match is never NULL:
The test suite used to wrap calls_contacts_provder_new() to always return
NULL which in turn caused the best match to be NULL.
This was done to avoid warnings raised by libfolks
about missing the primary store (eds).
This is no longer necessary as the environment now tells folks which
backend to use.
self->best_match is never NULL:
The test suite used to wrap calls_contacts_provder_new() to always return
NULL which in turn caused the best match to be NULL.
This was done to avoid warnings raised by libfolks
about missing the primary store (eds).
This is no longer necessary as the environment now tells folks which
backend to use.
self->best_match is never NULL:
The test suite used to wrap calls_contacts_provder_new() to always return
NULL which in turn caused the best match to be NULL.
This was done to avoid warnings raised by libfolks
about missing the primary store (eds).
This is no longer necessary as the environment now tells folks which
backend to use.
If folks is built with the 'eds' backend it will get used by default.
During testing the system address book should not be queried.
It might even be impossible if the environment is not set up to
connect to the session bus raising the following warning:
(process:701522): folks-WARNING **: 09:13:54.291: Failed to find primary PersonaStore with type ID 'eds' and ID 'system-address-book'.
Individuals will not be linked properly and creating new links between Personas will not work.
The configured primary PersonaStore's backend may not be installed. If you are unsure, check with your distribution.
Fixes: #427
The windows need to be removed from the GtkApplication because they are
holding references to the application which prevents proper cleanup.
Fixes: #508
It is more fitting than the default "test" stage and
has the desirable side effect that the Debian packaging jobs
no longer need to wait for flatpak jobs to finish.
As libfeedback uses GDbusProxy under the hood which defaults to timing
out after 25 seconds there is no need to handle timeouts explicitly.
Furthermore 1 second seems to not always be enough time to get a
response which leads to endless ringing.
Fixes#543
There is no need to enable or disable actions until the popover
is actually presented.
This also get's rid of having to be notified of changes to the
"can-add-contact" property which led to a segfault as the signal handler
was not properly cleared.
Fixes: #535
As the "can-add-contact" property is now always checked,
the menu item will be properly shown.
Fixes: #485
