OEcore/bitbake are moving to use the clearer ":" as an overrides
separator.
This is pass one of updating the meta-virt recipes to use that
syntax.
This has only been minimally build/runtime tested, more changes
will be required for missed overrides, or incorrect conversions
Note: A recent bitbake is required:
commit 75fad23fc06c008a03414a1fc288a8614c6af9ca
Author: Richard Purdie <richard.purdie@linuxfoundation.org>
Date: Sun Jul 18 12:59:15 2021 +0100
bitbake: data_smart/parse: Allow ':' characters in variable/function names
It is becomming increasingly clear we need to find a way to show what
is/is not an override in our syntax. We need to do this in a way which
is clear to users, readable and in a way we can transition to.
The most effective way I've found to this is to use the ":" charater
to directly replace "_" where an override is being specified. This
includes "append", "prepend" and "remove" which are effectively special
override directives.
This patch simply adds the character to the parser so bitbake accepts
the value but maps it back to "_" internally so there is no behaviour
change.
This change is simple enough it could potentially be backported to older
version of bitbake meaning layers using the new syntax/markup could
work with older releases. Even if other no other changes are accepted
at this time and we don't backport, it does set us on a path where at
some point in future we could
require a more explict syntax.
I've tested this patch by converting oe-core/meta-yocto to the new
syntax for overrides (9000+ changes) and then seeing that builds
continue to work with this patch.
(Bitbake rev: 0dbbb4547cb2570d2ce607e9a53459df3c0ac284)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
runc can be built with both selinux and seccomp tags. These tags
are a requirement for proper operation with some frameworks (like
k3s).
So we add checks for the appropriate distro features and then
automatically add them to the build tags, allowing us a coordinated
enabling of the functionality.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
When using podman (or other seccomp enabled container runtimes),
you will get an OCI container startup error if runc hasn't been
built with seccomp.
Adding a distro feature to runc and to the README to make it easier
to coordinate the support.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Add a new PACKAGECONFIG, static, which when enabled will build
runc as static. Default to enable it.
We need this because we should allow users to build runc as not
static so that when docker's cgroup driver is set to systemd,
we don't get error.
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
When the go-lang container recipes were first created there were issues
with strip and the resulting binaries. As such, strip was inhibited for
the various packages.
This variable is now set in the default classes, and tests show that
strip works on the binaries (saving up to 2M on disk for some binaries)
with no runtime issues found.
So we drop our explicit set of the inhibit and let the build proceed
by the defaults.
If issues are found, we can re-enable the setting or bbappends can
turn it back on for builds showing issues.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
If we're building runc-opencontainers it's likely that we're not using
docker.
Signed-off-by: Paul Barker <paul@betafive.co.uk>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
This requires libseccomp from meta-security so it is not enabled by default.
Signed-off-by: Pascal Bach <pascal.bach@siemens.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
go 1.9.x was triggering linkage errors on some build hosts due to
missing symbols.
| tmp/work/core2-64-poky-linux/runc-docker/1.0.0-rc5+gitAUTOINC+4fc53a81fb-r0/recipe-sysroot/usr/lib/../lib/libc.a(dl-reloc-static-pie.o): In function `elf_mac:
| /usr/src/debug/glibc/2.27-r0/git/sysdeps/x86_64/dl-machine.h:59: undefined reference to `_DYNAMIC'
| tmp/work/core2-64-poky-linux/runc-docker/1.0.0-rc5+gitAUTOINC+4fc53a81fb-r0/recipe-sysroot/usr/lib/../lib/libc.a(dl-reloc-static-pie.o): In function `elf_get:
| /usr/src/debug/glibc/2.27-r0/git/elf/get-dynamic-info.h:48: undefined reference to `_DYNAMIC'
By ensuring that our sysroot provided go binary and build flags make
it into the build enviroment we can build properly with 1.9 and 1.10
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
The runc makefile now uses $(GO) universally, but sets the variable
as GO := go by default. This means that the host go will be used
instead of our recipe sysroot variant.
A simple export of the variable is not enough in all cases (due
to Make assignments), so both export it AND pass it directly to the
oe_make call.
This fixes docker-runc builds on ARM64.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Ricardo Salveti <ricardo@opensourcefoundries.com> pointed out that
runc-docker was not getting a proper PV due to the use of SRCREV
in the variable.
By switching to SRCPV, we get the right PV for both variants of
runc.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
The go bbclass already inherits goarch.
Signed-off-by: Paul Barker <pbarker@toganlabs.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
These variables are now set correctly by go.bbclass in oe-core. Changing them to
point at the native sysroot just leads to build errors in some cases, for
example when the target and host have matching GOARCH but not matching c
libraries.
Signed-off-by: Paul Barker <pbarker@toganlabs.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Recently in the oe-core the go.bbclass changed and requires the
defition of the GO_IMPORT variable. This was intended to simplify how
the compilation works with go packages and it is still a work in
progress.
This patch set makes the recipes compatible to generate the same end
result as before using the new go.bbclass from oe-core.
Any patches that were included in the recipes had to have the paths
adjusted because the new go.bbclass manipulates the notion of S to be
S + "src" + "$GO_IMPORT" internally for the purpose of unpack, patch
and compile.
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Uprev to pick up latest changes in docker-runc.
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Continue work to use go infra in oe-core instead of the support for go
previously found in meta-virt. This is a 1:1 drop in replacement and
removes one more go piece from meta-virt in favor of the common
support found in oe-core.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Rather than explicit go-cross DEPENDS, we can inherit go.bbclass and
pick up them automatically.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Since there are two implementations of runc and containerd that may
not always be in sync, the docker variant, and the opencontainers
variable, we create a virtual/* namespace for these components.
Anything requiring runc or containerd should set a preferred provider
to get the desired/tested variant.
We set the default provider to the docker variants, since they are
the primary use case for these components.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>