Busybox only supports the short option '-k'. (#4866)
Using this instead of '--keep' allows fwupd to be built on systems like Alpine Linux where /bin/gzip is supplied by Busybox.
By pre-commit getting setup early we were installing markdown and
meson into the virtual environment. This might not be a bad thing
if we encouraged virtual environments for development, but we don't.
`yu` was added in 014e5526ff to solve cache issues.
But since then several other invocations of pacman have been added and doing so constantly is pointless, as you are unlikely to see new upgrades while the CI is running (and it might not be desired either). It also breaks testing older versions of fwupd as seen in GH-4860. So upgrade only once at the beginning and keep installing from the same cache afterwards.
When support was added for falling back to SMBIOS data from the kernel
in /sys/class/dmi, we inadvertently stopped caring about the data parsed
directly from DMI tables as first priority. This caused a regression in
hwids from some OEMs that relied upon IDs that could only be properly built
from DMI tables, not the kernel /sys/class/dmi interface.
Link: https://bugs.launchpad.net/ubuntu/+source/fwupd/+bug/1982103
Fixes: 464425fb5 ("SMBIOS: try reading from /sys/class/dmi if direct access fails")
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
We want to allow all the device hotplug events to be processed before
marking the update as completed. Otherwise, we might have a situation
where we have a child device attached to a parent, where we want to
update the parent, then the child. e.g.
1. Add parent
2. Add child
3. Update parent
4. Attach parent
5. Wait for parent
...some time passes...
6. Parent re-appears
7. Update finishes, client indicates success
...child update is scheduled...
...which returns with failure as it does not exist...
8. Add child
The child should have been added *before* the update completed to avoid
the caller from needing an unspecified delay as a *workaround*.
Some of URLs disappeared. Marked all versions from the
commit as persistent on LVFS to avoid CABs loss.
Signed-off-by: Denis Pynkin <denis.pynkin@collabora.com>
This allows us to load sets of different host security attributes
for testing the various front end tools we have now. e.g.
sudo FWUPD_HOST_EMULATE=thinkpad-p1-iommu.json.gz fwupd
or, using a non-compressed absolute path:
sudo FWUPD_HOST_EMULATE=/tmp/test/thinkpad-p1-iommu.json fwupd
Data can be created with `./contrib/generate-emulation.py file.json`
and then can be manually modified if required. Running the script on
a file that already exists will just strip out any unneeded data, as
well as piping content into it using stdin.
As a precaution, the org.fwupd.hsi.HostEmulation attribute is added
so we do not ask the user to upload the HSI report. It also allows
the LVFS to ignore any HSI reports with this attribute for clients
that upload HSI reports regardless.
See https://github.com/fwupd/fwupd/discussions/4832
The FWUPD_DEVICE_FLAG_TRUSTED flag is used by the daemon, but if the
information is being set on the GVariant then it's not required to
filter it client-side.
This makes it easier to debug, as this shows what the checksum would be
stored in the history database on successful update.
We're already generating them, and so it's really just being helpful.
In one place we were accidentally setting the contents checksum,
because the LVFS was setting the artifact type of 'binary' for metainfo
export -- which was never going to match on the LVFS.
This means we don't need to worry about changing multiple
implementations if the HSI levels change for a specific ID.
It also means we can fake HSI results in the future without having
to also store the 'correct' level in the input file.
APL doesn't have a PCH so change it to ich. This change make no
difference, and is just for correctness.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
