It is no longer necessary to include these as they are explicitly built
with --onlydeps in build_sysext_packages().
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
The CoreOS support we have been carrying was merged upstream years ago.
The network configuration still needs special handling because our
cloud-init is called coreos-cloudinit, breaking the detection.
Flatcar's documentation used to point users at coreos-vagrant. This is
long dead and used the old Ignition VirtualBox support, which no longer
works. Rather than revive that, we can capture the essence of what
coreos-vagrant did in our base Vagrantfile.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
common-oem-files was a giant hack. oem-release can now be easily be
generated from metadata embedded in the sysext image itself. grub.cfg is
often just a couple of lines, so there's no point in having all this
complex logic around generating it, especially when that logic has some
exceptions anyway. It's far easier to just explicitly store each variant
under build_library/oem. The list of OEMs is now generated by looking
for coreos-base/oem-*/*.ebuild.
It turns out we haven't even been building this for years because of a
CI bug. There's no point in reviving it now.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
This allows the VirtualBox image to actually boot. It broke when
upstream Ignition changed how the VirtualBox support works.
VirtualBox supports arm64 these days, so we could enable this in the
common config, but we don't currently produce an arm64 VirtualBox image,
and I don't propose that we start now.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
These extension-release.d fields are equivalent to their non-SYSEXT
os-release counterparts. SYSEXT_ID is taken from the sysext's name as
given to build_sysext. SYSEXT_NAME, SYSEXT_VERSION_ID, and
SYSEXT_HOME_URL are taken from the package if only one is given.
SYSEXT_NAME is the new name for the OEM_NAME variable.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
Having a USE flag per OEM is unnecessary when we only really need to
know whether the package will be installed in an OEM sysext or not. A
single USE flag could do this, but our existing flatcar_target() helper
avoids the complexity of binpkg-multi-instance. The flag names were also
prone to conflicts (e.g. qemu) and we don't currently make use of them
anyway.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
It is no longer necessary to build the meta packages from source as they
are now covered by build_packages.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
Previously, the compression source was deleted after compression.
Keep it to allow seamless VM launching.
Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>
update_sdk_container_image failed to update baselayout because it
touched /sys, which is not allowed in an unprivileged docker build
environment.
dumb-tmpfiles-proc.sh does not touch existing directories, but it was
modifying the staging directory rather than the live filesystem, causing
Portage to record /sys in the package's CONTENTS and then make changes
to it when merging.
We only need to create the directories in pkg_preinst because the other
file types are already created in src_install.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
This generally shouldn't happen, given that we mostly only keep one
instance of a bin package, but just in case.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
We have long run with the ipc, network, and pid sandboxes disabled in
the belief that these did not work in a container even if it was
privileged. I suspect it really did work back then, but it certainly
does work now regardless.
update_sdk_container_image uses Portage in an unprivileged docker build
environment, so it is still necessary to disable these here. However,
this can be done more easily through the environment, and the regular
sandbox should work fine.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
