When using fwupdtool install we pass all the possible devices and then
loop each one. If loading the requirement failed for a specific one
just continue to the next device rather than aborting too early.
Fixes https://github.com/fwupd/fwupd/issues/4509
--force was there because HSI specification was incomplete. However
now we have the ability for plugins to report when not enough data
was gathered to make a calculation. So change it to instead only
run if enough data was gathered.
On supported CPUs this will show up at HSI level 1 meaning that HSI
should be supported and trusted on this CPU if all plugins provided
enough data.
On non-Intel CPUs this will show up as missing data, meaning
that not enough plugins provide data for HSI to be trusted by default.
older json-glib versions can't work with saving or retrieving
HSI security events. Rather than showing non-sensical errors
about too old of a json glib version that are out of context,
just compile this stuff out on the older versions.
This fixes HSI security events showing up too as a result.
This is a feature that seems useful, but one that no vendor has actually
asked for. It's also of limited use for peripheral devices.
Showing the instance IDs by default is also going to make it much easier
to explain to hardware vendors where the GUIDs come from.
Fixes https://github.com/fwupd/fwupd/issues/4445
Before we had FuInstallTask which represented the specific install
action (install foo on bar), FuEngineRequest which described why the
install task was created, and FuEngine. The latter being both reposible
for calling *into* FuInstallTask and also *from* FuInstallTask as well.
Depending on the code, we had XbNodes of component and release, *and*
FwupdReleases as releases and lots of duplicated code to marshall the
former into various forms of the latter.
Create a FuRelease wrapper around FwupdRelease to replace FuInstallTask
and to simplify the code. Make the FuRelease builder do the device
requirement checks, and then use the engine to do checks requiring
engine state and context.
This ensures that two different clients cannot update the same device,
as there's a window where we're waiting for the device to come back in
bootloader mode where we might accept a request from a different client.
As a side effect it also means we no longer store the UPDATABLE flag
in the history database -- which is fine as it's pretty useless anyway;
the device had to have been UPDATABLE to be updated in the first place.
If we connect up the device for property changes and then do an update,
we might send the pre-update GVariant data rather than the post-install
FuDevice.
This could mean that any client using the signal to update UI elements
might either flicker between the values, or show the 'wrong' device
version.
This fixes the memory leak below:
$ sudo valgrind -v --leak-check=full fwupdtool get-devices
(...)
==3244345== 133 (64 direct, 69 indirect) bytes in 2 blocks are definitely lost in loss record 2,488 of 2,681
==3244345== at 0x4845899: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3244345== by 0x4C04D59: g_malloc (in /usr/lib/libglib-2.0.so.0.7000.4)
==3244345== by 0x4C1C816: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.7000.4)
==3244345== by 0x4C1CE9E: g_slice_alloc0 (in /usr/lib/libglib-2.0.so.0.7000.4)
==3244345== by 0x4B84684: g_type_create_instance (in /usr/lib/libgobject-2.0.so.0.7000.4)
==3244345== by 0x4B6BB65: ??? (in /usr/lib/libgobject-2.0.so.0.7000.4)
==3244345== by 0x4B6CAF4: g_object_new_with_properties (in /usr/lib/libgobject-2.0.so.0.7000.4)
==3244345== by 0x4B6D659: g_object_new (in /usr/lib/libgobject-2.0.so.0.7000.4)
==3244345== by 0x4AA8969: ??? (in /usr/lib/libgio-2.0.so.0.7000.4)
==3244345== by 0x153967: fu_engine_load_local_metadata_watches (fu-engine.c:7050)
==3244345== by 0x1540FC: fu_engine_load (fu-engine.c:7230)
==3244345== by 0x124D29: fu_util_start_engine (fu-tool.c:262)
(...)
==3244345== LEAK SUMMARY:
==3244345== definitely lost: 64 bytes in 2 blocks
==3244345== indirectly lost: 69 bytes in 2 blocks
==3244345== possibly lost: 1,936 bytes in 8 blocks
==3244345== still reachable: 234,668 bytes in 3,072 blocks
==3244345== suppressed: 0 bytes in 0 blocks
==3244345== Reachable blocks (those to which a pointer was found) are not shown.
==3244345== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==3244345==
==3244345== ERROR SUMMARY: 9 errors from 9 contexts (suppressed: 0 from 0)
Change-Id: I391eabfb1ef6eadbad100273445794172b2cb1fd
Fixes https://github.com/fwupd/fwupd/issues/4366
Based on a patch by Daniel Campello <campello@chromium.org>, many thanks.
tristate features will automatically disable if dependencies marked
as required are missing.
Packagers can manually override using `auto_features`.
Link: https://mesonbuild.com/Build-options.html#features
Current behavior is that only first checksum is used from metadata if no
<artifacts> section is present. Change this to process all checksums
available.
Change-Id: I03771971bee0fb7960460094bf0790d29bf11e0a
