The useragent was being set as 'fwupdtool/1.8.11 fwupd/(NULL)' which the LVFS
did not like. As we're using fwupdtool without a daemon proxy just set the
fwupd version manually.
Fixes https://github.com/fwupd/fwupd/issues/5519
This allows us to only shut down the P2P daemon in the installed tests.
The easy fix would have been to use something like:
gdbus call --address unix:path=/run/fwupd.sock --object-path / --method org.freedesktop.fwupd.Quit'
...but the daemon does not implement an ObjectManager, which gdbus requires.
This worked correctly for so long because the p2p tests were being run after
the bus tests, so shutting down the system daemon had no effect.
Fedora 37 seems to have flipped the order for some reason -- and now it
*sometimes* matters that we were doing the worng thing...
We already had this as an inhibit, but this was not translated client-side.
We also need to propagate the problem to the bootloader device if the device
replugs during firmware update.
Force the compiler to treat them as uint64_t so that bitwise operations work.
At the moment flags greater than 1<<32 are just being silently ignored...
Some front end clients are going to be allow-listing updates based on what
the release was tested on, or by who the testing team was.
Export this data from each report when requested.
Recently we had an update that changed the system-defined Platform Key, and
we've certainly had updates in the past that changed the Boot#### variables.
Store some core ACPI and UEFI system integrity state from before and after the
update which can be used to mark (waivable) test failures on the LVFS.
Saving the quirks in the GResource section worked well, but it made the build
system very complicated and also meant the .data section was duplicated in
both `fwupd` and `fwupdtool` -- negating a lot of the hard-fought savings.
Simplify this feature so that we just `cat` all the quirk files together, then
gzip them into a single file. This means that at startup fwupd only needs to
check the mtime of one file, and weirdly it's actually faster to load a smaller
compressed file from disk that it is to load multiple uncompressed files.
If a specific plugin calls fu_plugin_set_secure_config_value() and then
fu_plugin_set_config_value() then we'll save the file with the world-readable
permissions.
Set a plugin flag to say that 'this plugin is storing sensitive details' which
allows us to use the same entrypoint and also fix up any files at startup that
do not have the correct permissions.
G_APPLICATION_FLAGS_NONE was deprecated, but we don't actually need the single
instance functionality, so just use a non-deprecated flag instead.
This fixes Debian CI.
