in ee2e2c3674 the plugin name was changed
from uefi to uefi_capsule. while the config file name was changed, the
section name should also be changed.
fixes#2748
If the date is wrong, the SSL certificate may not be in a valid date range and
the user gets a rather unhelpful 'SSL handshake failed' error message.
Detect the most common case and show a warning when starting fwupdmgr.
Fixes https://github.com/fwupd/fwupd/issues/2723
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 logic error wasn't being caught because the `DelayedActivation`
sysfs code wasn't running.
Basically the WD19TB device will have `skips-restart` applied by the quirk
by default. After `fu_thunderbolt_device_setup_controller` has run
it will have `skips-restart` removed but `usable-during-update` applied
if on a new enough kernel.
In this circumstance the `DelayedActivation` would re-apply `skips-restart`
which is the wrong intended behavior per 834b28009d
The Thunderbolt plugin wasn't actually working properly for
`DelayedActivation` because Thunderbolt devices weren't actually registered.
This only affected ChromeOS.
WD19TB uses skip-restart in some cases, but not all.
The matrix of cases is enumerated in 834b28009d
Unfortunately in the most common case now - new kernel and new daemon
`skip-restart` *isn't* used. The device should be left in a `needs-activation`
state though.
Use this to skip the trigger of failed upload report.
Fixes: #2731
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.
