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.
The libxmlb library is much faster to query, and does not require the daemon
to parse the XML metadata at startup. It's a zero-copy mmap design that is more
modern and less clunky.
RSS has reduced from 3Mb (peak 3.61Mb) to 1Mb (peak 1.07Mb) and the startup
time has gone from 280ms to 250ms.
With handling composite CAB files this information isn't relayed to the
frontend on which release is being handled, but was rather guessed.
Avoid showing invalid information in this instance.
The frontend was never notified of the release (and didn't parse the CAB) so
it doesn't know at this time what the version of the release is and
so this shows a NULL assertion at the time.
Commit 171ec0d added support for 'update' and 'downgrade' operations
in fwupdmgr. Since users can also install CAB files manually
show the titles for those too.
Multiple devices can be updated from one cabinet archive, and it would be quite
confusing just to print the first device title and then have the progressbar go
from 0..100 multiple times.
Use the existing device-changed signal to set the 'current device' and print a
new header if the device changes during the install phase.
With composite CAB files it's difficult to see between devices when packed:
Homepage: http://support.dell.com/
Vendor: Dell Inc.
TrustFlags: none
Unknown Device
Guid: 558d18fa-5530-5fc8-9e4b-de3ee8a5eca7
Homepage: http://support.dell.com/
Vendor: Dell Inc.
TrustFlags: none
Unknown Device
Previously if missing secure boot binaries, or invalid ESP was created the
plugin would just not load.
Now instead populate UpdateError and remove the updateble flag, but still show
the device in fwupdmgr and fwupdtool.
In Fedora the only user of libfwupdate is fwupd and the fwupdate command line
tool. It makes sense to absorb the libfwupdate library interface into the
uefi plugin in fwupd. Benefits I can see include:
* fwupd and fwupdate are very similar names; a lot of OEMs are confused
* fwupd already depends on efivar for other things
* We are maintaining an artificial library interface
* The CI and translation hooks are already in place for fwupd
* We don't need to check for features or versions in fwupd, we can just develop
the feature (e.g. BGRT) all in one place.
This is designed to be run as root accessing the hardware directly rather than
using the daemon. This would allow a snap or flatpak package to write firmware
even when the host fwupd daemon is too old.
Also, move the SMBIOS parsing code here as this is not needed in fwupdmgr.
GLib creates two static inline functions for paramaters that may
not be used that set off warnings in clang but not gcc.
Ignore these on clang builds everywhere that
G_DEFINE_AUTOPTR_CLEANUP_FUNC is used.
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.
This allows us to use PolicyKit, which means we will get prompted for
authorization if logged in as a user without permissions.
Fixes https://github.com/hughsie/fwupd/issues/455
As part of this ignore extra string arguments other than the device
ID for these methods.
This has two benefits:
1) No more copying and pasting device ID's for any of these methods
2) Bash completion can now show nicer output for these methods
This shares your history with a reporting server, typically the LVFS.
NOTE: no data is sent without the user opting-in, and the data sent is shown to
the user before upload.
Rename FuPending to FuHistory to better represent what the object is now doing.
Also, while we're here, switch to using SQLite prepared statements to avoid a
possible invalid read on i386 hardware.
Always set the AppStream app properties on the FwupdRelease. In some cases we
were returning FwupdRelease objects with no name or summary which gnome-software
was ignoring.
The data for these was just being generated internally based on the ID and the
basename of the original URI, and that's easy for the calling application to do
itself.
UEFI updates don't need to be retried since a785a1c. If the call to Install()
failed with NOT_SUPPORTED we can just show the error rather than doing the
little dance and involving the offline pending database for no reason.
Fixes some of https://github.com/hughsie/fwupd/issues/255
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 former, and that's how plugins are using it.
The Linux DMI class still does not provide the information we need, and parsing
the blob directly also allows the Dell and Redfish plugins to get the raw data.
We can use this as an alternative for GPG. No PKCS7 certificates are currently
installed by fwupd and it's expected that the LVFS will still only provide GPG
detached signatures.
If an OEM distributor wants to sign firmware with a PKCS7 and the corresponding
certificate is provided then the firmware will be marked as valid.
Only firmware shipping with a .p7b file will use the PKCS7 functionality,
similarly remote metadata validation will default to GPG unless Keyring=pkcs7
is specified in the config file.
