In many plugins we've wanted to use ->prepare_firmware() to parse the firmware
ahead of ->detach() and ->write_firmware() but this has the limitation that it
can only return a single blob of data.
For many devices, multiple binary blobs are required from one parsed image,
for instance providing signatures, config and data blobs that have to be pushed
to the device in different way.
This also means we parse the firmware *before* we ask the user to detach.
Break the internal FuDevice API to support these firmware types as they become
more popular.
This also allows us to move the Intel HEX and SREC parsing out of the dfu plugin
as they are used by a few plugins now, and resolving symbols between plugins
isn't exactly awesome.
This allows several things, for instance:
* Adding or removing blacklisted plugins or devices
* Changing the idle timeout where allowed
...without a user needing to manually modify a configuration file.
This information was a predecessor to metadata provided by LVFS with
actual files associated. It's not useful to 99% of the machines it runs
on, and future VIA metadata should come directly with releases on LVFS.
The offline updates environment is special, and we have to be careful to delete
the trigger before doing anything that can fail to avoid boot loops.
For this reason, split it out to a simple self-contained binary that is easy to
understand.
If another offline update task is run at the same time, e.g. pk-offline-update
from PackageKit then we might corrupt the package database when the client
D-Bus request times out.
Copy the fixes from PackageKit so that the offline updates work together.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1685471
This currently just outputs the current list of devices with releases and makes
it possible to integrate firmware version reporting with other tools like mgmt.
This feature is turned on with the new fwupdtool option `--enable-json-state`
The intended use case is for ChromeOS to be able to save information about
devices on the system when `fwupdtool update` was run to display in the UX at
a later time.
The following warnings were displayed by Debian appstream metadata
validation.
```
metainfo-validation-issue
Validation of the metainfo file found a problem: Found empty 'url' tag.
metainfo-validation-issue
Validation of the metainfo file found a problem: Type 'console-application' component, but no information about binaries in $PATH was provided via a provides/binary tag.
metainfo-validation-issue
Validation of the metainfo file found a problem: Found empty 'url' tag.
```
This is intended for devices that it is not safe to immediately activate
the firmware. It may be called at a more convenient time instead.
Both fwupdmgr and fwupdtool support the feature.
- if called at runtime with fwupdmgr it uses the daemon
- during shutdown fwupdtool uses the pending.db to perform this feature.
For this we need to register as a console application (which fwupdtool is, I
suppose) and also supply a usable icon.
I've used the new GNOME icon theme guidelines so please add a drop shadow
before using: https://gitlab.gnome.org/GNOME/Initiatives/issues/2
Two new arguments added to fwupdtool: `--prepare` and `--cleanup`
They are used only with the `install-blob` command
This makes sure that devices can get rebooted in dell-dock even if using
fwupdtool to install a single blob.
Signed-off-by: Richard Hughes <richard@hughsie.com>
Now that there is actually support to load non-static information
(at least from fwupd perspective) it makes sense to support this
command in both tools.
This will perform updates with all currently present metadata.
It is "intended" for usage with local metadata repositories referring
to local files.
fwupdtool however does also support fetching a file from the web
and if the metadata refers to the file on the web it should also work
for that.
Plugins are allowed to 'opt-out' of this behaviour using _RULE_INHIBITS_IDLE.
This should be used where waking up the hardware to coldplug is expensive,
either from a power consumption point of view, or if other artifacts are going
to be seem -- for instance if the screen flickers when probing display devices.
This functionality is also inhibited when the actual upgrade is happening,
for obvious reasons.
Admins can turn off this auto-sleep behaviour by editing the daemon.conf file.
Fixes https://github.com/hughsie/fwupd/issues/417
This matches what a lot of other projects do, and means we can easily format
the release notes back into NEWS format, but also into HTML and Markdown.
This also means we can show the correct update description in gnome-software
when building a flatpak, rather than falling back to the generic project
description.