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.
* oem-azure: add hyperv daemons
This change adds hyperv daemons hv_fcopy, hv_kvp, and hv_vss to the
Azure and HyperV OEM sysexts. hv_kvp specifically is needed to submit OS version
information to the Azure hypervisor.
The daemons, tough userspace programs, are built from the kernel sources
as they are included in the Linux kernel.
As the ebuild is (somewhat) kernel specific, it should be updated when the kernel
is updated. Respective additions have been made to the kernel update GitHub actions
automation.
Signed-off-by: Thilo Fromm <thilofromm@microsoft.com>
Co-authored-by: Mathieu Tortuyaux <mtortuyaux@microsoft.com>
We can now use Gentoo's upstream ebuild, save for a few small overrides
in a separate env file.
This bumps GRUB from 2.06 to 2.12, The existing two Flatcar patches have
been rebased.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
The old version 2.1.4 does not cross-compile without help from QEMU that
we cannot rely on going forwards. 2.1.10 is Meson-based and handles this
much better.
Rather than update the package in-place, migrate it to portage-stable
and cover the differences with a small patch and env script.
Upstream now carries the systemd files, so we do not need to add these.
/etc is now automatically moved to /usr/share/flatcar/etc, so we no
longer need any special handling for that here, but I have added a
compatibility symlink for iscsid.conf.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
The coreos-overlay package under app-admin was written by Jeremi around
the same time I added it to Gentoo under sys-apps. It has had a new
release since.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
It is not clear why this was forked originally. One reason was to avoid
the sys-apps/lsb-release dependency, but it probably wasn't just that.
It seems likely that the upstream package did not support cross targets
at the time. Now it does.
It appears that LTO was previously enabled by us following Gentoo rather
than through an explicit decision. They now disable it by default, so we
do likewise. It previously used "fat" LTO, which makes Rust especially
slow to build and reportedly made rustc slower than with "thin" LTO!
There seems little benefit in using thin LTO given that we rebuild Rust
almost as much as the packages that use it, plus we don't enable LTO
anywhere else.
We still avoid rustdoc to keep the size down using INSTALL_MASK. This
isn't as good as not building it in the first place, but this alone
isn't worth keeping a fork.
Cross targets are now handled via the admittedly experimental
RUST_CROSS_TARGETS support. This has been in place for a while, and I
think it is fairly widely used now. If it does disappear, it would
almost certainly be for something even better.
This also updates Rust from 1.80.0 to 1.80.1.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
We have previously avoided this package because its /etc/lsb-release
clashes with the symlink created by our sys-apps/baselayout. This has
led to the need to fork some packages, such as dev-lang/rust, just to
avoid the dependency.
Instead, we can just stop it from installing /etc/lsb-release with
INSTALL_MASK. I also considered having it create the symlink instead of
baselayout, but baselayout has the tmpfiles.d handling, so this is
simpler.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
