This allows us to match up the AppStream data we've parsed in gnome-software and the firmware update we've got from fwupd. This means we can get access to some of the data that fwupd doesn't care about, for instance the how-to-upgrade screenshots.
The DFU specification specifies that only one of the DFU interfaces has to
export a functional descriptor; I assumed they all had to. Adding support
for this kind of device rapidly turned into a massive restructure and it was
all too complicated anyway.
Reorganise the code so that we can support these kinds of devices and clean up
the API so it's sane and easy to use. This also allows us to generate the
GObject introspection GIR and to also install libdfu as a shared library.
If you've got any comments about the API, please shout now as when 6.0 is
released it will become API and ABI stable.
Using our own special version for the input for the GUID calculations means
that the result is not 'googlable'.
This does have the result of changing the GUIDs stored in the 'verify' database
but given the string->GUID function in appstream-glib has also changed to
become standards compliant and that only a few people are using it I felt it
was worth the pain.
In most cases this is out of chance, but in some random cases the gzip
decompressor decides to reuse the input buffer as a decompression buffer,
which means we get junk data after the decompressed text.
To solve this, just truncate the data at the reported size, and then feed this
into the XML parser.
Fixes: https://github.com/hughsie/fwupd/issues/36
If we send junk to UpdateMetadata() the deamon did something like this:
* Clear existing entries from memory
* Try to load junk file into memory -> error
This left us with no entries in the in-memory store, which required the user to
either keep retrying the 'fwupdmgr update' until it worked or just forced them
to restart fwupd so it loaded the old valid store from the cache file.
Now, only clear the in-memory store and add the new firmware entries when
we know the file has been parsed correctly.
Fixes: https://github.com/hughsie/fwupd/issues/35
This allows a vendor to upload a single file that targets different versions of
the same hardware. If this feature is used, the metainfo.xml files *must* have
something like <checksum target="content" filename="firmware2.rom"/> inside the
latest <release> tag.
readlink() man page says that applications must not rely on it returning
null-terminated links. This commit switches it to use g_file_read_link()
instead that has much nicer API and shields us from readlink() oddities.
On devices with a lot of PCI devices this can take a couple of seconds per
device, and if this feature is not desired then disabling it saves system
resources.
The firmware may be more generic, and it also allows us to match the GUID then
doing 'verify' on a device with a different device PID than the firmware
actually declares.
This allows the text clients like fwupdmgr to convert to UTF-8 text, and
graphical clients can use the markdown target to ensure the links are made
clickable and paragraphs are presented in the right way.
For large files, EVENT_CREATED gets emitted when the first chunk hits the disk,
not when the file has finished copying. To fix, just wait for the file monitor
to hint that all the changes in the operation have happened and then process
the firmware files.
This downloads the latest version of the firmware and applies it to any
matching hardware. e.g.
$ fwupdmgr update
Downloading 1.2.3 for ColorHug...
Updating 1.2.3 on ColorHug...
* Loading firmware
* Decompressing firmware
* Restarting device
* Writing firmware to device
* Verifying firmware from device
* Restarting device
Done!
The way this works is we try with the user settings, and if this fails with
NotSupported and the offline flag is unset then we retry the action with a
warning and the flag manually set.
I chose to do this in the client rather than the daemon as I don't want to
encode too many magic rules when we don't know the kind of devices that will
appear in the future.
Fixes the other half of https://github.com/hughsie/fwupd/pull/23
It seems a little odd to call it 'Update' when it's being used for downgrading
and reinstalling as well.
As we're making things simpler, just use a single 'install' action in fwupdmgr
rather than 'install', 'update-online', 'update-offline'. We can use the flags
and fallbacks to do the right thing in all cases, and make the typical case
(installing a local file to any matching hardware) simple.
Fixes half of https://github.com/hughsie/fwupd/pull/23
This only returns the latest version, if you actually need to know details
about all versions including downgrades then you still need to load the
AppStream metadata and match devices manually.
fwupdate will handle creating the appropriate BootNext entry.
No other changes are needed from fwupd.
Signed-off-by: Richard Hughes <richard@hughsie.com>
