We ignored assertions happening on callbacks as they only raise
exceptions that does not stop the execution.
So ensure that this is happening in all the tests as synaptics was
doing already
To compute the device ports we walked up through the devices using
g_usb_device_get_parent(), but this is supposed to return a device with
transfer full, so we need to unref it when done with it.
To handle this nicely, use a mixture of autopointer's and g_set_object
to ensure we're doing the right thing when passing the ownership around.
It's suggested to use g_memdup2 everywhere, but since we've a max-glib
version set we'd get a "deprecation" warning.
Avoid it this by re-defininig it through a macro in both cases.
gitlab has coverage integration in MRs, but we need a cobertura
formatted XML files (each must be less than 10 MB) to show it, since
meson generates it already via gcovr, we can just inform gitlab about it
See https://docs.gitlab.com/ee/ci/testing/test_coverage_visualization.html
WARNING: You should add the boolean check kwarg to the run_command call.
It currently defaults to false,
but it will default to true in future releases of meson.
See also: https://github.com/mesonbuild/meson/issues/9300
Traceback (most recent call last):
File "/builds/libfprint/libfprint/tests/umockdev-test.py", line 17, in <module>
version = tuple(int(_) for _ in umockdev_version.split(b'.'))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/builds/libfprint/libfprint/tests/umockdev-test.py", line 17, in <genexpr>
version = tuple(int(_) for _ in umockdev_version.split(b'.'))
^^^^^^
ValueError: invalid literal for int() with base 10: b'g9049374\n'
Fix possible race which would happen when freeing the devices array
before cancelling the initialisation:
(/builds/libfprint/libfprint/_build/tests/test-fp-context:1449): GLib-CRITICAL **: 14:00:19.640: g_ptr_array_add: assertion 'rarray' failed
Drop re-definition of stderr. There's no need for this anywhere
(including glibc). This breaks in particular on musl because
stderr (and stdin) are both const, and macros unlike in glibc.
Bug: https://bugs.gentoo.org/853811
When opening the device, query the stored prints. This should usually
always succeed (and it should be fast). If it fails, then we are very
likely dealing with a corrupted template storage on the device. In that
case, emit the command to clear the storage in order to reset the device
and get it back into a usable state.
It is completely fine for a capture to have a low quality or fail. No
need to warn about this. Main reason to remove it though is so that
recordings that contain such a message do not trigger a failure.
