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.
