We will be carrying some patches so the version of the source code will
no longer be simply the upstream mainline version. A -coreos or
-coreos-r1 and so forth will be appended. A new variable defining the
source revision (e.g. -r1) has been added so we can continue to bump the
coreos-kernel revision independently of coreos-sources for minor things
like config updates.
We need some additional selinux policy to get rkt working. Right now
this is a slightly rough cut - we'll tidy this up over time and ensure
that it's not overly permissive. In addition, ensure that policy is
installed in /usr rather than /etc and /var in order to allow upgrades
to work properly.
Pull in various selinux bits that need modification, and enable them.
setools: Needs patching to support cross building
policycoreutils: Needs patching to remove python runtime dependency
sec-policy/*: We need custom policy modifications
In addition, modify selinux-policy-2.eclass to support pulling in selinux
includes from the build root rather than /, enable selinux in systemd's
use flags and enable selinux support in the kernel.
The update of the elfutils package for arm64 bumped the amd64 stable to
elfutils-0.158 which unfortunatly, has a cross compile bug. Specify the
unstable ~amd64 (elfutils-0.161) to work around the problem.
Signed-off-by: Geoff Levand <geoff@infradead.org>
Before we can enable ixgbevf devices by default we need to prevent the
interface names from changing names and surprising folks. On the down
side this may surprise anyone manually enabling ixgbevf on their
instances but I expect that to be the smaller population.
btmp and wtmp will now be properly rotated, yay!
Masking of logrotate configs has moved to just apply to boards, leaving
them in the SDK can be a useful reference.
SDK tarballs have a .DIGESTS file but it is created by catalyst instead
of the upload_image function. In order to support plain GPG signing but
not avoid re-generating .DIGESTS we need to move that code out of
upload_image to a new function. upload_files shouldn't do it itself
because it is also used for portage binary packages which shouldn't be
signed (there is no point, nothing would verify the signatures).
Previously we attempted to speed up the first build of a board by
pulling in binary packages regardless of their use flags, assuming that
if the package was already built the loop would not be an issue. Usually
this was true but not always. Now things like util-linux will always get
compiled when setting up a board for the first time but at least it
won't be as likely to fail.
