This resulted in losing g_usb_source_set_callback@LIBGUSB_0.1.0 which causes a
build failure when building gusb as a subproject, and also the little-used
fu_chunk_to_string() from libfwupdplugin.
Signed-off-by: Richard Hughes <richard@hughsie.com>
fu_engine_install_blob may result in the device being reset during attach or
detach and needing to be replugged.
The device handle we're holding may be stale, but it is still used by the do
while loop itself for the ANOTHER_WRITE_REQUIRED test.
Similar to the other functions in the loop, let's get the device handle by id
in case that happened.
Original patch by Benson Leung <bleung@chromium.org>, many thanks.
Fixes https://github.com/fwupd/fwupd/issues/2297
This is required when the calling application needs the low-level soup-session
with the user agent set correctly rather than using the helper methods like
fwupd_client_download_bytes().
This is what GNOME Software needs to handle the GsApp progress completion.
If a system is configured without any downloadable remotes (e.g. with
a remote pointing to a local directory) the call of
fwupdmgr get-updates
fails by outputting "No remotes enabled." even though the call
"get-remotes" clearly shows the configured remote.
I found the following commit:
commit 991c95697e
Author: Mario Limonciello <mario.limonciello@dell.com>
Date: Wed Jun 17 15:23:13 2020 -0500
trivial: fu-util: correct an assertion when no remotes configured
introduced the problem. In the call chain:
fu_util_get_updates
-> fu_util_perhaps_refresh_remotes
-> fu_util_check_oldest_remote
the function fu_util_check_oldest_remote now returns FALSE if no
remote of kind FWUPD_REMOTE_KIND_DOWNLOAD is found.
The function fu_util_perhaps_refresh_remotes then returns FALSE
indicating failure even though without a downloadable remote the
concept of refreshing is not useful.
I think, we should return TRUE in this case, as no refresh is needed
and the operation can continue.
As the failure of fu_util_check_oldest_remote is ignored we also need
to pass NULL as error pointer here.
The use-case of this scenario without downloadable remote is by
distributing firmware updates through software updates where the
vendor directory with the capsule file is provided.
The I²C proxy specification is not always shared with all other devices as
I originally hoped, instead there are other legacy devices that use different
sets of I²C commands.
Un-share various bits of code to allow for additional I²C devices to be added.
No logic changes.
This takes care of downloading the correct files and allows remotes to be
refreshed from other CLI and GUI tools without copying large chunks of code.
This also allows us to download the metadata without writing two temp files
to the users cache directory. Although not security sensitive, it's probably
not a good idea if we can avoid it.
