Somewhat embarrassingly we were not actually showing the 8bitdo manual detach
images because... we were not actually exporting them. I don't know how this
ever worked in GNOME Software, but it would also explain the low 'success' rate
of the 8bitdo firmware on the LVFS.
This will also be used by Logitech in the future for the C1 Unifying devices.
To work in gnome-softare, this also needs the matching functionality to call
gs_app_add_screenshot() with the new exported data.
When the LVFS switches over to outputting <issues> rather than appending to the
update description we need to be in a position to display the new data.
This allows the daemon to set the base directory to store remotes.
This fixes issues with systemd where the installation prefix was set
to soemthing not writable such as `/usr/local` but systemd
`STATE_DIRECTORY` doesn't match up.
```
$ fwupdmgr refresh
Fetching metadata https://cdn.fwupd.org/downloads/firmware.xml.gz
Downloading… [***************************************] Less than one minute remaining…
Fetching signature https://cdn.fwupd.org/downloads/firmware.xml.gz.asc
Failed to update metadata for lvfs: Error creating directory /usr/local/var/lib/fwupd/remotes.d: Read-only file system
```
It should also hopefully help with immutable systems.
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.
Some firmwares only update one part of the system, e.g. the EC or ME firmware.
Other updates include all the updates needed for the whole system, and vendors
have been doing different things with the component name due to this.
To fix, add an enumerated set of firmware 'categories' that can be set by the
uploader in the metainfo.xml file (or changed the LVFS) which automatically
set the name suffix.
Only append the translated version in the client when <categories> has
not been set, as the LVFS is still operating in compatibility mode and setting
the <name> with the prefix. Add the support to fwupd now so we can switch in
about 9 months time.
In the future we'll want to use this flag to signify if the release is an
upgrade, downgrade, below the version-lowest, or if it is locked in some way.
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.
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.
This also allows us to write mixed-endian structures and adds tests. As part of
this commit we've also changed the API of something that's not yet been in any
tarball release, so no pitchforks please.
This makes it much easier to write metainfo files as we don't have to ask OEMs
or ODMs to run fwupdtool or fwupd with --verbose and then sort through hundreds
of debugging statements.
The fwupdmgr get-devices output also now prints output like this:
20EQS64N0C System Firmware
Guid: ddc0ee61-e7f0-4e7d-acc5-c070a398838e
Guid: 40ce5954-bfa8-5762-926b-f4848cb28bc8 <- UEFI\RES_{DDC0EE61-E7F0-4E7D-ACC5-C070A398838E}
We're deliberately not showing the InstanceId lines in the get-updates command
as the instance IDs are not useful in this case. It will also only show the
InstanceID lines when run as a trusted user, for instance root.
The idea is that if the user should know something about the device update
"after" it's succesfully completed then the plugin can set `UpdateMessage`
for the device and a client can show it.
An example would be a device that doesn't reboot on its own and the user
needs to power cycle it manually.
The source URL allows us to comply with our various obligations when shipping
firmware built from GPL licensed sources. The details URL allows vendors to
include a link to a full HTML details page about the specific release.
These are set from the AppStream metadata and are specific to the firmware
release.
If not provided, the install duration falls back to the per-device duration
values which can be set in the quirk files.
This allows us to find out the logical parent device, for instance in composite
devices with more than one firmware image for a single device.
We also allow lazily specifying the device parent using a GUID and the engine
then automatically sets the parent object when the GUIDs match, which allows
children and parents to exist in different plugins.
We need to show this agreement text in every fwupd frontend and exporting a
helper function allows us to do two things:
* Share the semi-complicated code (and fallback) to avoid copy and pasting
* Easily change the code in the future, for instance allowing merging Metainfo
and AppStream metadata without updating all the front ends with new logic.
Also, we now verify the version script is correct each time we run the tests;
the consequences of getting the version script wrong are terribly bad.
Note, we can't actually use generated .map file for two reasons:
1. We don't hard depend on GObject Introspection
2. The map file is required to build the lib that the GIR is built from
To avoid the circular dep, and to ensure we don't change exported API
accidentaly actually check in a version of the version script to git.
Automake and autoconf are impossible to fully understand and Meson now provides
everything we need for a much smaller, faster, and more understandable build.
See http://mesonbuild.com/ for more information.
