The current CROS_WORKON_COMMIT of etcd-2.2.4 does not build from
arm64. Add a temporary conditional to set CROS_WORKON_COMMIT to
a known good revision for arm64.
Signed-off-by: Geoff Levand <geoff@infradead.org>
exec docker "$@" ${USE_SELINUX} will override DOCKER_OPTS if it contains
--selinux-enabled=false, and puts double --selinux-enabled in args which
is confusing too.
docker daemon --host=fd:// --selinux-enabled=false --selinux-enabled
metadata
* Add IUSE and description rkt_stage1_fly
ebuild
* Bump version to 0.15.0
* Add IUSE rkt_stage1_fly and enable by default
* Rewrite rkt ebuild to support multiple stage1 flavors
Two errors here: shred_keys was not updated when the keys were moved
from the top level directory to the certs directory and shred_keys was
getting called after `rm -r certs`, leaving nothing to shred.
Now the ebuild will fail if shred fails.
Since moving call to dracut into the coreos-kernel package in
pkg_setup step the pkg_setup function provided by linux-info hasn't been
called, breaking tc-arch-kernel which depends on the detected kernel
version to know if it should return "x86" or "x86_64".
Instead of calling `linux-info_pkg_setup` we now call `get_version`
directly which only looks up the version in the source, the old behavior
allowed for falling back to `get_running_version` which is not useful.
This check was broken in when the source symlinks were moved from `${S}`
to `${S}/source`. Also, since it is a environment sanity check running
the check as early as possible in `pkg_pretend` is appropriate.
When bootstrapping glibc installs headers but is not built. However a
native tool, cross-rpcgen, must be built in order to generate rpcsvc
header files. By skipping directly to `make headers-install` the tool
winds up getting built during src_install, building as root instead of
the portage user and so on. Although uncommon this may lead to
permission issues with ccache.
The SDK chroot has no control over /dev/pts since it is bind-mounted
from the host system. As far as I can tell there isn't any significant
issue caused by the `tty` group having a different gid on the host
system from the SDK anyway.
