The current CDN (~$100/month) is kindly sponsored by Amazon, but that won't
last forever. In the future we can switch to a 'dumb' provider like BunnyCDN
for 1/10th of the cost.
Use a CNAME we control to make switching CDN providers easy in the future.
Some devices like the Nitrokey use a generic DFU bootloader that reports a
version number unrelated to the version number of the runtime. Add a flag so
that we can set the correct version when switching plugins during detach and
attach.
Don't optimize the device flag away. We need to be able to set the flag on all
devices that match the device ID, not just the one that happens to match now.
I assume they're trying to avoid compressing the firmware, but compressing the
metadata. Not insane, but slightly odd given the metadata is typically tiny.
Fixes: https://github.com/hughsie/fwupd/issues/392
If the device firmware was set incorrectly make then set it to the release
version so the database update works correctly. We can't do any kind of vercmp
in the database, so use a daemon warning so we can either fix the plugin or
the XML.
This fixes up the issue that the hardware reports '28.00' and the AppStream
release specifies '28.0'.
Fixes: https://github.com/hughsie/fwupd/issues/387
If this happens:
1.2.3 -> 1.2.4 = failure
1.2.3 -> 1.2.5 = success
...we want to preserve both in the history database so they can both be shared
with the LVFS. Use the device ID and the new and old firmware versions when
modifying and deleting entries.
This fix is made slightly more tricky as we have to drop the PRIMARY KEY
attribute on the device_id, and due to a limitation in SQLite, it means copying
the old history into a new table.
Previous to having the history database we could only notify about firmware that
as installed using the uefi plugin, as that had a few system-wide API calls to
say 'this update failed' or 'this was the error'.
Now we have the local history database not only can we report more details about
the UEFI update (e.g. the old version number) but we can also offer the same
functionality for all other plugins.
Although this does rework how the data for GetResults() is populated, it does
make the FuEngine object quite a lot less confused.
It also fixes a warning in the fwupd plugin for gnome-software, which was
expecting the FwupdRelease to be populated for the FwupdDevice.
