Add various fixes to enable us to build a selection of useful USB plugins.
Also, skip tests that don't make sense on WIN32 or that will not work.
With much help from Mario Limonciello <mario.limonciello@dell.com> -- Thanks!
Recently had a discussion on the expected behavior of calling
`#fwupdmgr update`/`fwupdtool update` with `--allow-reinstall`
in place.
It wasn't working which was confusing to the reporter, but I
feel that flag should only be usable with `install`. Upgrades
are for upgrades and downgrades are for downgrades. Reinstalls are
for reinstall.
This is inspired by a change in flashrom to read the version string for meson
dynamically.
No need for "post release version bump", this happens automatically from git
now by there being a dirty commit.
Don't show output for all devices - it doesn't work for most of them.
I also found that running verify on my Synaptics touchpad device puts it
into a pretty bad state until reboot. That's of course a problem on
it's own, but at least prompting for it will prevent it from easily
happening.
```
Uploading firmware reports helps hardware vendors to quickly identify failing and successful updates on real devices.
Upload report now? (Requires internet connection):
0. Do not upload reports at this time, but prompt again for future updates
1. Do not upload reports, and never ask to upload reports for future updates
2. Upload reports just this one time, but prompt again for future updates
3. Upload reports this time and automatically upload reports after completing future updates
1
key ReportUri not supported
```
Before:
```
Uploading firmware reports helps hardware vendors to quickly identify failing and successful updates on real devices.
Upload report now? (Requires internet connection):0. Do not upload reports at this time, but prompt again for future updates
1. Do not upload reports, and never ask to upload reports for future updates
2. Upload reports just this one time, but prompt again for future updates
3. Upload reports this time and automatically upload reports after completing future updates
```
After:
```
Uploading firmware reports helps hardware vendors to quickly identify failing and successful updates on real devices.
Upload report now? (Requires internet connection):
0. Do not upload reports at this time, but prompt again for future updates
1. Do not upload reports, and never ask to upload reports for future updates
2. Upload reports just this one time, but prompt again for future updates
3. Upload reports this time and automatically upload reports after completing future updates
```
Updating firware is sometimes scary, and for user-facing CLI tools we ought to
show some kind of reassurance than it went well.
Fixes some of https://github.com/fwupd/fwupd/issues/1409
This brings consistency to all fwupd output and allows stuff like
this:
```
No upgrades for Thunderbolt controller in Dell dock, current is 43.00: 40.00=older
No upgrades for Package level of Dell dock, current is 01.00.08.01: 01.00.04.01=older
No upgrades for RTS5413 in Dell dock, current is 01.21: 01.21=same
No upgrades for RTS5487 in Dell dock, current is 01.47: 01.47=same
No upgrades for VMM5331 in Dell dock, current is 05.04.00: 05.03.10=older
No upgrades for WD19TB, current is 01.00.00.02: 01.00.00.00=older
○
└─XPS 13 9380 System Firmware:
│ Device ID: 6c24a747f97668873b761558e322398a91dbf394
│ Current version: 0.1.6.0
│ Minimum Version: 0.1.6.0
│ Vendor: Dell Inc.
│ Flags: internal|updatable|require-ac|supported|registered|needs-reboot
│
└─XPS 13 9380 System Update:
Version: 0.1.7.0
Remote ID: lvfs
Summary: Firmware for the Dell XPS 13 9380
License: proprietary
Size: 0x1563d67
Vendor: Dell Inc.
Flags: is-upgrade
Description: This stable release fixes the following issues:
Fixed the issue where the Dell Power Manager displays an error when a 130W Type-C adapter is connected to the system.
new functionality has also been added:
Added a new feature to automatically suspend BitLocker before upgrading the firmware. After the firmware upgrade is complete, BitLocker is automatically enabled.
```
Mostly for consistency purpose. Details:
* It's confusing that internally the functions for `FwupdClient` use
`upgrade` in the name.
* The logical antonym of `downgrade` is `upgrade` not `update`
* People who don't use the tool frequently may try `get-upgrades`
Fixes Debian bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921820
Introduce a new --log option to fwupdmgr that will log stdout to an argument.
If run under systemd, prefix that argument with $RUNTIME_DIRECTORY.
Add a new systemd unit and associated timer to regularly refresh metadata.
After the metadata refresh is complete, save the output to the motd location.
The timer and service are disabled by default and can be enabled by an admin.
Normally the flag 'supported' is used to indicate that devices can
update from a remote such as LVFS.
Running `#fwupdmgr get-updates` in this situation will show a message
for each device that is already up to date as well as messages for
devices that have updates available.
If no devices contain the supported flag, `# fwupdmgr get-updates`
will show no output, which is confusing to some people.
Show "No updatable devices" instead for those situations.
Unexpected behaviors can happen if:
* a snapped daemon is running with a packaged frontend
* a packaged daemon is running with a snapped frontend
This should make sure that if the snap is installed on top of a
packaged frontend that people don't try to mix and match as much.
The lines are almost impossible to read as they are not wrapped and not
delimited from the normal script output. Add a box around to make them stand out:
╔══════════════════════════════════════════════════════════════════════════════╗
║ The LVFS is a free service that operates as an independent legal entity and ║
║ has no connection with Fedora. Your distributor may not have verified any ║
║ of the firmware updates for compatibility with your system or connected ║
║ devices. All firmware is provided only by the original equipment ║
║ manufacturer. ║
║ ║
║ Enabling this functionality is done at your own risk, which means you have ║
║ to contact your original equipment manufacturer regarding any problems ║
║ caused by these updates. Only problems with the update process itself ║
║ should be filed at https://bugzilla.redhat.com/. ║
║ ║
╚══════════════════════════════════════════════════════════════════════════════╝
Agree and enable the remote? [Y|n]:
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.
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.
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.
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.
It's currently a hodge podge of commands that can install files not
always invoking a reboot or shutdown.
Move the actual code into `fu-util-common.c` and make sure that all
`install` and `update` functions call it now.
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.
