Per https://github.com/projectatomic/bubblewrap/issues/200
the paths need to be built differently to be able to accomodate
an unmerged /usr that Debian has.
Use ro bind mounts rather than symlinks to be compatible to both
Fedora's approach and Debian's approach
(Hopefully without breaking the Ubuntu packaging!)
When building, also generate a fwupdate-$ARCH-signed-template package
which contains metadata needed by the Debian signing service. This
will end up being turned into a new source package including a signed
version of the fwupdate binary.
Update the existing debian packaging files for fwupdate to do this,
and also add the core of the template in the debian/signing-template
directory. Also add a couple of helper scripts to drive things, and
update our README.Debian.
1) Drop the path at the end of the title (\fwupdx64.efi)
2) Linux-Firmware-Updater to Linux Firmware Updater
The behavior that required the hacky name has been fixed since shim 10
which is in all the relevant distros now.
3322257e61
In the redfish emulator, "/redfish/v1" returns "ServiceVersion".
However, in the HPE API explorer(*), it returns "RedfishVersion".
This commit checks both member and print the one that is available.
(*) https://ilorestfulapiexplorer.ext.hpe.com/
Redfish is an open industry standard specification and schema that helps enable
simple and secure management of modern scalable platform hardware.
This has only ever been tested using an emulator and not on real hardware.
Commit 83d46b0579 bumped the minimum meson version to 0.46.0
This makes building on current Ubuntu LTS release more difficult
as it contains 0.45.0.
Instead conditionalize the build to run that code when on newer
meson.
This commit can be reverted when it's appropriate to bump meson
build dependency.
In Fedora the only user of libfwupdate is fwupd and the fwupdate command line
tool. It makes sense to absorb the libfwupdate library interface into the
uefi plugin in fwupd. Benefits I can see include:
* fwupd and fwupdate are very similar names; a lot of OEMs are confused
* fwupd already depends on efivar for other things
* We are maintaining an artificial library interface
* The CI and translation hooks are already in place for fwupd
* We don't need to check for features or versions in fwupd, we can just develop
the feature (e.g. BGRT) all in one place.
