Install or downgrade firmware on all devices to make the system match
a well known set. This allows two things:
* Factory recovery where a device in the field has been upgraded
* Ensuring a consistent set of tested firmware for a specific workload
A tag is assigned either during upload or added post-upload on the LVFS
which is included in the metadata. A single firmware can be marked with
multiple tags, and tags can be duplicated for different firmwares.
Send the users locale to the daemon so that it can be used to prefer
the localized update text over the default en_US version.
$ LANG=fr_FR.UTF8 fwupdmgr get-details test.cab
...
└─ACME Plan 9:
Nouvelle version: 0.0.5
Licence: Propriétaire
Urgence: Faible
Fournisseur: ACME Ltd.
Description: Cette version stable corrige des bugs.
I decided to send the locale to the daemon rather than change the
`Description` to return GVariant to `a{ss}` as we also probably want
to support things like localized summary and URLs too in the future.
When coldplugging expensive servers with a huge number of Redfish
devices it takes about 30 seconds to start fwupd while we wait for the
BMC to return results.
In the event of a 429 response libcurl does not fail curl_easy_perform()
and instead saves the 'Too Many Requests' string as the payload.
This obviously fails the cabinet checksum specified in the metadata.
Move the response code checks to the success branch and also add checks
for the other 4xx and 5xx errors.
Fixes the fwupd half of https://github.com/fwupd/firmware-lenovo-thinkpad/issues/137
The "return error and hope the client resubmits the firmware again"
pattern is clunky. There are two plugins doing this now, and about to
be one more.
This adds FwupdRequest which provides a structured way of asking the
user to perform an action, e.g. to replug the device or to press a
special key or button.
This replaces much of the UpdateMessage and UpdateImage API although
it is still used internally. Clients capable of processing the new
DeviceRequest signal should add REQUESTS to their feature flags.
Also, this allows us go back to the old meaning of _NEEDS_BOOTLOADER,
which was "needs rebooting into a bootloader mode" rather than the
slightly weird "user needs to do something and resubmit request".
Until gi-docgen is declared stable support either of them.
This effectively means that hand builds and CI builds will use
gi-docgen, but distro builds use gtk-doc-tools.
The call to g_proxy_resolver_get_default() is (transfer none) and so unref'ing
it causes GLib to get very upset. Also, move it to be per-FwupdClient rather
than per-request as it can be expensive to call in the PAC-runner case.
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.
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.
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.
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.
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.
