It's confusing to have FuConfig load both the daemon.conf file and also keep
track of the enabled remotes. It's also wasteful of memory to keep the GKeyFile
alive the entire time.
Logically these are different pools of information and should be managed by
different objects. This allows us to implement reload() in a sane way and be
less reliant on the inotify event.
Currently devices with a matching GUID will match any metadata that
has the same GUID.
For Dell in the future there will be a situation that the same GUID
is supported by two different FwupdDevice objects but the payload
required for the different objects will vary.
So start matching the protocol and the GUID both to make sure that
the right Fwupd device gets matched from the metadata.
Dell does not include the first byte in the ESRT value, ignoring it. Using a
`quad` means we get versions like `0.1.4.0` rather than `1.4.0` which confuses
both users comparing versions to the vendor website, and also anyone trying to
do analysis on the firmware.
We painted ourselves into a corner when we added the `LVFS::VersionFormat`
metadata key, as using newer keys like `bcd` would not be recognised by older
versions of the daemon as there was no explicit fallback path.
This allows plugins or devices to 'upgrade' from simpler formats like:
* `pair` -> `bcd`
* `quad` -> `intel-me`
* `triplet` -> `surface`
* `plain` -> `misc-defined-vendor-format`
This means the LVFS can write multiple `LVFS::VersionFormat` keys, although the
'older' version format has to be listed first to preserve compatibility with
older daemon versions that just validate the first matching node.
Add various fixes to enable us to build a selection of useful USB plugins.
Also, skip tests that don't make sense on WIN32 or that will not work.
With much help from Mario Limonciello <mario.limonciello@dell.com> -- Thanks!
In some CI infrastructures other devices show up and so the webcam
is not automatically picked.
```
Enabling fwupd-tests remote...
Successfully enabled remote
Update the device hash database...
Choose a device:
0. Cancel
1. 08d460be0f1f9f128413f816022a6439e0078018 (Integrated Webcam™)
2. bbbf1ce3d1cf15550c3760b354592040292415bb (Virtio network device)
Request canceled
FAIL: fwupd/fwupdmgr.test (Child process exited with code 2)
SUMMARY: total=1; passed=0; skipped=0; failed=1; user=0.0s; system=0.0s; maxrss=11736
FAIL: fwupd/fwupdmgr.test (Child process exited with code 2)
autopkgtest [22:09:32]: test ci: -----------------------]
ci FAIL non-zero exit status 2
autopkgtest [22:09:33]: test ci: - - - - - - - - - - results - - - - - - - - - -
autopkgtest [22:09:33]: @@@@@@@@@@@@@@@@@@@@ summary
ci FAIL non-zero exit status 2
```
Only on Lenovo devices the DMI version string is prefixed with
CBETxxxx to make the thinkpad_acpi kernel module happy.
Add a new quirk called "CorebootVersionQuirks" to detect platforms
that need to cut of the prefix.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
In fu_plugin_startup we make sure that the FU_HWIDS_KEY_BIOS_VENDOR
matches "coreboot", so there's no need to read it again.
Remove the call to fu_plugin_get_dmi_value and drop the first call
to fu_device_set_vendor as it gets overwritten below.
Hardcode the id string for now.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
We don't actually need either of the things it provides (looking up in source
and built, and converting to an absolute path) so just replace it with
g_build_filename() instead.
This also has the advantage that it does the right thing on Windows.
