Only a small amount of the firmware on the LVFS will be available. The user
can use --ipfs on the command line for testing, or change the system-wide
default in /etc/fwupd/daemon.conf.
The IPFS daemon and command line client will need to be installed manually.
The docs for `fwupd_device_get_children()` make it very clear that only the
parent should be assigned. Also add a warning to `fwupd_device_add_child()`
explaining it is for internal daemon use only.
We forgot to include FwupdClientDownloadFlags when adding the original method
fwupd_client_install_release() -- and we want to use additional download flags
for operations in the future.
The metadata might want to pass more than one location URI to the client, for
instance if the file is available from more than one HTTP mirror.
Use the noun of location to match the AppStream <artifact> naming; this is the
last place where LVFS AppStream diverges from the official specification and
it would be good to bring fwupd back into line -- although the LVFS will have
to write both elements for a very long time.
See https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html
Also: we're not changing the format of the `Uri` GVariant key to preserve both
forward and backwards compatibility of the library. We can remove it when we
next break API.
We don't want the (shared) progress notifications going to the thread-default
GMainContext by default as this changes behaviour (ABI?) with older libfwupd
versions.
If the client really does want progress notifications to go to a different
GMainContext they it can call fwupd_client_set_main_context() with the desired
context, e.g. g_main_context_get_thread_default() or g_main_context_new().
This has the intended side effect of returning progress and state notifications
to the main thread, which is typically (but not always) the thread that created
the FwupdClient object.
From Philip's guide: "Never iterate a context created outside the library,
including the global-default or thread-default contexts. Otherwise, GSources
created in the application may be dispatched when the application is not
expecting it, causing re-entrancy problems for the application code."
When using the sync API entrypoints like fwupd_client_get_devices() these call
into fwupd_client_connect() to ensure the proxy is set up. This is not thread
safe and chaos ensues if you call two sync functions from different threads,
like GNOME Software does at startup...
Use a mutex to protect access to this shared resource.
Original test code from Philip Withnall, slightly tweaked by me. Thanks!
The end year is legally and functionally redundant, and more importantly causes
cherry-pick conflicts when trying to maintain old branches. Use git for history.
That giant uint64_t isn't looking so big now, and we'll want to add even more
to it in the future. Split out some private flags that are never useful to the
client, although the #defines will have to remain until we break API again.
This fixes:
DEPRECATION: Library fwupd was passed to the "libraries" keyword argument of
a previous call to generate() method instead of first positional argument.
Adding fwupd to "Requires" field, but this is a deprecated behaviour that
will change in a future version of Meson.
Asking the user for the UID mapping isn't working very well, as it requires lots
of manual handholding. It also doesn't work very well when the device vendor
does not actually have a PCI ID or if the vendor has split into two entities.
Just use the OUI address as an additional VendorID and match any of the device
IDs against any of the metadata-supplied values.
The fprint daemon only keeps the device open for 5 seconds and then releases it,
which seems like a small window to hit.
But! We're asking the user to authenticate with the same device we're about to
upgrade so a different part of the stack woke up the hardware just before we're
about to deploy an update onto it.
Just retry a few times to make sure the device is idle. Use a flag to prevent
accidentally causing regressions in other plugins.
Fixes https://github.com/fwupd/fwupd/issues/2650
For fuzzing we want to exclude libcurl support as it depends on other very heavy
libraries like OpenSSL or libtasn which make the fuzzing binary much larger if
linked statically.
Some vendors really really want 1.5.x in newer RHEL versions, but the version
of curl is too old. Add #ifdefs so that we can emulate (somewhat imperfectly)
the 'new' CURLU functonality.
Use the 'default' main context by default so that we still get the signals
delivered via g_object_notify() but allow the library user to specify an
alternate GMainContext as required.
Using g_main_context_push_thread_default() works for PackageKit as signals are
returned using g_signal_emit() which is synchronous, and so doesn't use the
main context at all.
Use the same style of API which we did for libgusb all those years ago instead.
We can't do this in the library as Ubuntu want to ship a new libfwupd with an
old daemon. The new daemon only understands jcat and does not know how to
determine the age of an .asc file.
This fixes a regression from 2f49da7f4e where we
tried to parse the GPG .asc file as a JcatFile even although the remote had
Keyring=gpg (which is the default for ODM accounts on the LVFS) which returned
the cryptic 'Invalid compressed data' message.
The workaround for 1.5.2 is to change the local remote.conf from 'Keyring=gpg'
to 'Keyring=jcat' and to save the file.
