Now when an alpha is tagged (i.e. it branches off master.xml), the
manifest repository still gets a tag, a commit on master, and a new
build branch pointing at that commit, but by default an additional
commit is appended to the build branch that branches the projects
coreos-overlay, portage-stable, and scripts in the manifest. When
given the --push option, a build branch is created in each of these
project repositories so everything is prepared for future minor
releases to build upon.
This is implemented in yet another option so that the previous
behavior is still available, but it probably makes sense to just
hard-code the default behavior of --branch and --branch_projects
and drop those options.
This changes the format from:
sys-apps/systemd-212-r8::coreos GPL-2 LGPL-2.1 MIT public-domain
to a JSON structure:
[
{
"project": "sys-apps/systemd-212-r8::coreos",
"license": ["GPL-2", "LGPL-2.1", "MIT", "public-domain"]
}
]
We don't have to worry about the changing format because the previous
format was never published. This is designed to match the
bill-of-materials [1] format so that it can be consumed by the site.
[1]: https://github.com/coreos/license-bill-of-materials
Even though there's an upstream gentoo ebuild, it depends on cmake
(which had trouble cross-compiling for arm64).
tini is a simple enough program that writing our own makefile for it is
pretty easy, and it'll pay off in reduced buildtime and dependencies for
now since we can avoid dragging in cmake.
Note that we don't bother providing the static useflag and just make it
always static since we're packaging this for docker regardless.
The Gentoo ebuild has modified the dependencies to require static
libraries for the system programs instead of just the user ones.
The only CoreOS changes to the ebuild are to add the vpc patch, and
to mark arm64 stable (even though it isn't used).
5a76e4e5e9027443ef2014d8e1d06e9baa9e50aa started exporting COREOS_BUILD_ID
whenever it was found in version.txt, even if its value was blank. Because
COREOS_BUILD_ID is in ENVIRONMENT_WHITELIST, this caused generated build IDs
to be propagated into the SDK chroot environment and reused for every build
in a "cork enter" session. Stop exporting COREOS_BUILD_ID when we set it
ourselves.
See also 8e754f9c2bd4b4ec6561613ff57c095886877960.