If we plug in USB device A, remove it, plug in USB device B and get the same
autogenerated string all kinds of nasty things happen to the history database.
This allows us to record whether we've shown the user a notification (either in
the terminal or in a GUI) that an update failed or was successful.
This can't be done in the session otherwise we'd get a notification for every
different user on the system. Notifying also isn't the same as reporting,
although one can certainly follow on from the latter.
In newer releases libusb has started returning LIBUSB_TRANSFER_ERROR (rather
than the arguably more correct LIBUSB_TRANSFER_STALL...) when the device is
removed before the control transfer has completed.
The previous fix (db6ed9ede3) didn't
do a good enough job and autopkgtest was still failing on another
individual test.
This makes sure that stderr will never conflict with autopkgtest
in the future.
This will be useful in the future for debugging crashes with known
problematic versions of libsmbios.
Also use this information to turn off the blacklist from previously
bad known combinations of libsmbios + certain systems
There have been some problems with changes in systemd that will require
other changes to be made in umockdev. These changes are being sorted
out upstream. For now this makes Travis CI fail every time on the Arch
job. Until we know that's fixed upstream, disabling the test suite in
Arch at least makes CI useful again.
The autopkgtest test cases in Debian and Ubuntu are failing due to
output present in stderr.
fwupdmgr behavior however is that it's expected that this test should
show output on stderr for this item.
Deduplicate based on the ID, without assuming the devices will be the same
in-memory object. Also, only emit the changed signal if the device is waiting
for a replug.
Fixes https://github.com/hughsie/fwupd/issues/364
In the case of failing to even set up UpdateCapsule, the uefi plugin would
dutifully return SUCCESS as it was referring to the 2nd-to-last update that
actually worked.
This reverts commit 47ff62b986.
This lets master build on Ubuntu 17.10.
Ubuntu 17.10 doesn't have the newer appstream-glib, so reverting
this commit means Ubuntu 17.10 can't use the HWID's stuff from
b8f8db2082
without a manual backport.
Ubuntu 18.04 and later already have the newer appstream-glib
though, so they will get the HWIDs functionality
The SUPPORTED flag is used when a device appears in the AppStream metadata of
any enabled remote, so when we rescan the modified store also ensure the flag
state is still correct.
Fixes https://github.com/hughsie/fwupd/issues/363
The work for this landed in what will turn into efivar 33.
Later down the road when efivar 33 is in most the major distros
this can be removed and a requirement set for efivar 33.
This shares your history with a reporting server, typically the LVFS.
NOTE: no data is sent without the user opting-in, and the data sent is shown to
the user before upload.
