Using rescan allows use to give a priority to search paths. So this way
plugins in `CALLS_PLUGIN_DIR` take precedence over plugins we ship.
This also makes sure that the plugin test searches in the same location
as CallsManager.
We can build eds without canberra support.
This disables OAUTH2 feature of eds since it would need webkit and we don't
need it.
This also disables also dot locking for mails, because eds isn't used
for mails.
It is also not needed because we don't build the feedbackd daemon.
Without --no-cache newly "built" images end up just creating a new tag
for old images, see below.
$ podman images
REPOSITORY TAG IMAGE ID CREATED SIZE
registry.gitlab.gnome.org/gnome/calls/debian v0.0.20221013 a1c2d79e4f72 4 weeks ago 1.53 GB
registry.gitlab.gnome.org/gnome/calls/debian v0.0.20221117 4d2a38aa5bff 3 months ago 2.01 GB
registry.gitlab.gnome.org/gnome/calls/debian v0.0.20220817 4d2a38aa5bff 3 months ago 2.01 GB
gcovr > 5.1 (which is included in the latest Debian CI image) fails an
assertion because two different functions with the same name end up on
different lines because they are #ifdef'ed
The offending code is this:
G_DEFINE_TYPE_WITH_CODE
(CallsDummyProvider, calls_dummy_provider, CALLS_TYPE_PROVIDER,
G_IMPLEMENT_INTERFACE (CALLS_TYPE_MESSAGE_SOURCE,
calls_dummy_provider_message_source_interface_init))
G_DEFINE_DYNAMIC_TYPE_EXTENDED
(CallsDummyProvider, calls_dummy_provider, CALLS_TYPE_PROVIDER, 0,
G_IMPLEMENT_INTERFACE_DYNAMIC (CALLS_TYPE_MESSAGE_SOURCE,
calls_dummy_provider_message_source_interface_init))
There is already a gcovr issue here:
https://github.com/gcovr/gcovr/issues/586
The failed assertion looks like this:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/gcovr/workers.py", line 78, in worker
work(*args, **kwargs)
File "/usr/lib/python3/dist-packages/gcovr/gcov.py", line 337, in process_datafile
done = run_gcov_and_process_files(
File "/usr/lib/python3/dist-packages/gcovr/gcov.py", line 514, in run_gcov_and_process_files
process_gcov_data(fname, covdata, abs_filename, options)
File "/usr/lib/python3/dist-packages/gcovr/gcov.py", line 165, in process_gcov_data
insert_file_coverage(covdata, coverage)
File "/usr/lib/python3/dist-packages/gcovr/merging.py", line 159, in insert_file_coverage
return _insert_coverage_item(target, file.filename, file, merge_file, options)
File "/usr/lib/python3/dist-packages/gcovr/merging.py", line 135, in _insert_coverage_item
merged_item = merge_item(target_dict[key], new_item, options)
File "/usr/lib/python3/dist-packages/gcovr/merging.py", line 178, in merge_file
left.functions = _merge_dict(
File "/usr/lib/python3/dist-packages/gcovr/merging.py", line 99, in _merge_dict
_insert_coverage_item(left, key, right_item, merge_item, options)
File "/usr/lib/python3/dist-packages/gcovr/merging.py", line 135, in _insert_coverage_item
merged_item = merge_item(target_dict[key], new_item, options)
File "/usr/lib/python3/dist-packages/gcovr/merging.py", line 268, in merge_function
assert left.lineno == right.lineno
AssertionError
When the only feedback of an event is unavailable on a system (e.g. no
vibration motor or LED) the "feedback-ended" signal is emitted
immediately and the end reason will be LFB_EVENT_END_REASON_NOT_FOUND.
In this case we need to change the target state, so that our logic does
not end up retriggering the event infinitely.
Previously our code assumed that g_cancellable_cancel() the async DBus
calls to libfeedback would guarantee that the underlying operation would
not be performed (i.e. triggering or ending a feedback).
However the endless ringing exhibited in #470 shows this assumption not
to hold. Therefore we avoid using g_cancellable_cancel () completely and
default to waiting for the async operation to finish.
update_ring () now sets the target state by inspecting managed calls and
the main logic will now step towards the target state:
Changing from regular/loud to soft/quiet ringing (or vice versa)
requires we first end feedback before (re)triggering it.
Additionally the "is-quiet" and "is-ringing" properties are replaced by
a new "state" property to allow changing the combination atomically.
Closes: #470
Under normal conditions it is not expected that whether we can add
contacts or not (based on the presence of the appropriate action on
gnome-contacts) changes.
Nevertheless it can be beneficial for debugging when installing patched
and unpatched versions of gnome-contacts.
