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.
This includes the case where the device ID is unset, the child gets added and
the parent device ID then gets set. This makes the ordering for adding children
much less fragile.
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 leads to madness, as some formats are supersets of the detected types,
e.g. 'intel-me' is detected as 'quad' and 'bcd' is detected as 'pair'.
Where the version format is defined in a specification or hardcoded in the
source use a hardcoded enum value, otherwise use a quirk override.
Additionally, warn if the version does not match the defined version format
Set `UpdateError` in this case, and prevent updates.
If the `VersionFormat` is not known, then the device will later have
problems installing firmware with errors like:
```
failed to get release version: version format unset and version 13000001 ambiguous
```
or
```
Firmware version formats were different, device was '(null)' and release is 'plain'
```
This generally should be corrected by quirking the device.
These are dangerous GUIDs that shouldn't generally be used by any device
for distribution of firmware updates. They'll potentially apply to
devices outside of the vendor they were created for.
Additionally if two USB devices with common interface classes are
on the system, they may lead to one device not being populated by
fwupd.
Fixes https://github.com/hughsie/fwupd/issues/1162
I'm getting a bit fed up with failed reports from arch users where they just
have a broken system. I don't think it's useful to upload to the LVFS or notify
the vendor about failures like this.
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 is arguably the more correct fix, regardless of the UEFI quirk use as each
release was reading and converting the exact same property from the component.
Fixes https://github.com/hughsie/fwupd/issues/1156
This allows us to print the daemon-specific properties like VersionFormat when
debugging. The caller can continue to operate on the subclassed FwupdDevice
without changes.
