The metadata might want to pass more than one location URI to the client, for
instance if the file is available from more than one HTTP mirror.
Use the noun of location to match the AppStream <artifact> naming; this is the
last place where LVFS AppStream diverges from the official specification and
it would be good to bring fwupd back into line -- although the LVFS will have
to write both elements for a very long time.
See https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html
Also: we're not changing the format of the `Uri` GVariant key to preserve both
forward and backwards compatibility of the library. We can remove it when we
next break API.
The end year is legally and functionally redundant, and more importantly causes
cherry-pick conflicts when trying to maintain old branches. Use git for history.
This allows a device to identify with different streams, for instance a Lenovo
laptop could have a coreboot firmware or a AMI firmware. The GUIDs would be the
same, but switching firmware would only be done rarely and very carefully.
Another example would be switching the Broadcom BCM57xx nework adaptors from the
vendor nonfree firmware with a signed PXE image, to the free software reverse
engineered driver with no PXE support (and thus no signed DXE) at all.
It is expected firmware would have additional metadata something like this:
...
<branch>sdcc</branch>
<description>
<p>
This is an alternate firmware built by the community using only free
software tools.
</p>
</description>
<requires>
<id compare="ge" version="1.5.0">org.freedesktop.fwupd</id>
<client>switch-branch</client>
</requires>
...
Additionally, alternate branch firmware will not be returned for clients not
setting the FWUPD_FEATURE_FLAG_SWITCH_BRANCH before the GetReleases request.
The idea here is that we can show the user both a string and an optional
line-art image when the update has completed. The line art is often more well
understood for non-English speakers.
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.
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.
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.
It only remained on FwupdResult because I couldn't make up my mind about whether
it was a property of the device, or the firmware release. It's more logically
the latter, as you could have a .cab file with multiple versions of the
firmware and only the first being signed.
Although we supported other hashes than SHA1 (which is now moderately unsafe)
we had to switch the metadata provider and daemon on some kind of flag day to
using SHA256. Since that's somewhat impractical, just allow multiple checksums
to be set on objects and just try to match whatever is given in preference
order.
This also means we can easily transition to other hash types in the future.
The removed API was never present in a tarball release, so not an API break.
