Mentions of virtual/rust in some scripts were replaced with
dev-lang/rust-bin. These were usually about skipping the update/build
of the package, and these already contained dev-lang/rust, so added
the -bin variant for completeness.
I think I pulled the package from Gentoo in order to update some
protobuf package, which needed abseil. But it fizzled out once I
realized that update_engine needs to be updated first to the new
version of protobuf library.
The cross issues that were previously addressed by our fork are no
longer an issue since p11-kit migrated to Meson.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
The new arm64 firmware supporting Secure Boot (see next commit) is in
QCOW2 format only, avoiding the extra space taken up by the 64MB
padding. Supporting both raw and QCOW2 images would be messy, so switch
entirely to QCOW2.
Only the 4MB images are in QCOW2 format on amd64, so also switch away
from the 2MB images. 4MB images are now the default for most
distributions as they are needed to apply certain Windows updates.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
virt-fw-vars handles X.509 conversion and QCOW2 conversion transparently
and can update all the variables in a single invocation.
Bonus: Asking it to list the variables doesn't cause a segfault due to
the feature not really being implemented. :D
The 00000000-0000-0000-0000-000000000000 owner GUID is what flash-var
used to set, as we didn't specify the -g argument. We don't need to set
a meaningful value as this file is only for testing.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
Gentoo has moved this package so that it can support multiple platforms.
The newer version is needed for Secure Boot support on arm64. This is
newer than the version that QEMU is currently pinned to so unpin it via
the USE flag.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
It couldn't be added before to automation, because the eclass in
Gentoo would introduce have unwanted side-effects into our built
images. But the Gentoo version of the eclass is essentially a no-op
when USE=split-usr is disabled. We have recently moved to use Gentoo
profiles that disable USE=split-usr altogether, and with this move, we
can now safely put the eclass into automation.
This marks the point where the entirety of the portage-stable is under
automation.
