This is inspired by a change in flashrom to read the version string for meson
dynamically.
No need for "post release version bump", this happens automatically from git
now by there being a dirty commit.
This device was showing up from a LG 38UC99-W USB-C monitor
```
VMM0000:
Device ID: d762543f8c20f636e6fff031a000078d3e10c600
Summary: Multi-Stream Transport Device
Current version: 0.00.000
Vendor: Synaptics
GUIDs: 42addef4-40f9-5e89-b925-d564e35ed368 ← MST-(null)-vmm0000-0
cf8c03c5-18bf-53c4-971f-4a08f88932b5 ← MST-(null)-0
e9427b6a-7389-5461-a592-1da5f8ec99fd ← MST-(null)
Device Flags: • Updatable
```
If for any reason loading these strings fail (e.g. the DW5821e/eSIM
module fails to load the product string when running the fastboot USB
layout), do not make the whole open operation fail.
Right now different integer sizes are used willy nilly and could
conceivably lead to overflow issues.
Additionally the values that come out of the kernel for `HID_ID`
are actually 8 digits, so they should be represented by a larger
data type.
Corrects an error during probe for intel graphics:
```
failed to add udev device /sys/devices/pci0000:00/0000:00:02.0: failed to open (null): Bad address
```
```
failed to close device: Bad file descriptor
```
fu-udev-device will open a locker automatically now.
However synaptics-rmi closes the file descriptor on it's own with `g_clear_object`.
So destroy the fd in synaptics-rmi.
The read property from hidraw HID_ID is 0018:00002D1F:00004946 where
the vendor id 2D1F starts from offset 9 from base address.
This change probes the hidraw vid/pid with a wanted plugin properly.
Set `IS_BOOTLOADER` unconditionally when in fastboot mode. This seems logically
what it is; a degraded mode that's able to update firmware without runtime
functionality.
Fixes https://github.com/fwupd/fwupd/issues/1532
This script re-uses code from existing firmware-packager related items
to:
* Find the matching device on the system
* Append an ESRT header
* Build a CAB file
* Pass the CAB file into fwupd daemon
The root of this problem is that we were trying to use pending.db as both a
pending report store and also a record of history, so you could see updates for
device foo 1.2.3->1.2.4 and then 1.2.4->1.2.5.
This sort-of half worked, but it meant in some cases we matched on the old
device version, sometimes on the new release version and sometimes matching on
either.
The problem was that in various places we were using the device ID as *the*
primary key, and so we had various functions like fu_history_get_device_by_id()
that expected to return just one device, not several.
The device ID also changes if the device is moved from USB plug to another, and
so it got even more complicated again trying to de-dupe the devices.
The sanest thing to do is to decide that pending.db only contains the latest
attempt to go from one version to another using device-id as the primary key.
This makes reporting work reliably now, although has the effect you can't
report a 1.2.3->1.2.4 and 1.2.4->1.2.5 at the same time. Note, if you tried to
do the latter before, the update-error (if set) would be wrong on the second
report...
For the 1.3.3 release make it all simpler and so the reporting works reliably.
Longer term we can design a better database schema that uses unique ID to
represent the *transaction* itself, that isn't tied to the device ID in any way.
This might mean extending the DBus API to cope with multiple devices being
returned with the same device-id set.
