The GitHub Action artifacts are compressed zip files which include
bz2 files which are either the raw .bin images that have many zero bytes
in the rootfs but the main data in /usr is using zstd compression, or
they are the qcow2 .img images which are compressed themselves (and of
course have the same /usr compression). The bz2 compression doesn't help
in our case.
Remove the bz2 compression layer. If in the future non-zip artifacts
are supported we can add it back for the .bin image only by using
explicit calls only for that file instead of the
--image_compression_formats= flag for all images.
The qemu and qemu_uefi_secure images have the same contents as the
qemu_uefi image which wastes space on the release server. A similar
case is the PXE vmlinuz which is the same as the regular one, too.
Set up symlinks for same images, and also detect this when compressing
to set up symlinks there as well. To reduce complexity, the qemu and
qemu_uefi_secure images are not supported anymore and the Jenkins or
GitHub CI will skip over them if specified. Users that build their own
images need to adapt, though.
The PXE image and its helper script is a very handy way to test an image
because it does not preserve state. One can boot the same file over and
over again without having to reset the image. One can also easily pass
in additional kernel cmdline options without having to set up grub.cfg.
In Gentoo, packages dev-util/cmake, dev-util/meson,
dev-util/meson-format-array, dev-util/ninja and sys-devel/make got
moved to new category named dev-build. Reflect that in our repos too.
The {sys-devel,dev-build}/make package is moved from overlay into
portage-stable - it used to be there to carry a patch that fixed
builds of the sys-devel/binutils package. I think that the issue was
fixed long time ago in make, so now it's time to put it back to
portage-stable and under package automation.
Updating it to 3.0.17 breaks the build. First there are some
signedness issues (which I fixed), but then there is some header
ordering issue which results in errors about some names being
undefined. This is because a header that defines those names includes
some other header before defining the names. That other header pulls
in some other header that end up referencing the not-yet-defined
names:
In file included from /usr/include/efi/efilib.h:22,
from Include/OpenSslSupport.h:19,
from Include/stddef.h:15,
from /usr/include/efi/x86_64/efibind.h:99,
from /usr/include/efi/efi.h:42,
from ./Library/BaseLib.h:1,
from ./InternalCryptLib.h:18,
from Hash/CryptMd4.c:15:
/usr/include/efi/efidebug.h:22:8: error: unknown type name ‘UINTN’
22 | extern UINTN EFIDebug;
/usr/include/efi/x86_64/efibind.h defines UINTN in line 124, but
includes stddef.h in line 99.
I'm not dealing with it knowing that Sayan is working on secure-boot
stuff which involves updating sys-boot/shim, so this bug should go
away soon.
show-fixed-kernel-cves.py script from flatcar-build-scripts requires
this package:
Traceback (most recent call last):
File "/home/runner/actions-runner/_work/scripts/scripts/flatcar-build-scripts/show-fixed-kernel-cves.py", line 29, in <module>
from packaging import version
ModuleNotFoundError: No module named 'packaging'
Instead of depending on default value of build_image's base_sysext
parameter, create a file that explicitly lists which base sysexts will
be built for each architecture. The file can be sourced by other
scripts that need this kind of information. Currently, image.sh and
image_changes.sh use this file.
This is to limit the amount of reports consisting purely of failures,
because some files were missing. And those files will be missing,
because an OEM might not even have any image for certain arches (like
digitalocean has no arm64 images).
