This adds the option --torcx_store to specify the path to a
directory containing torcx images to be baked into the OS image. A
blank string can be given instead of a path to restore the previous
behavior and leave an empty vendor store.
The default value is the default path created by build_torcx_store,
which is used when build_packages updates torcx images. This means
that the current pattern "./build_packages && ./build_image prod"
should result in a fully updated OS image with all torcx images
available in the vendor store.
The idea is that once the installed board packages have changed,
the sysroot that was used to build any existing torcx packages may
no longer be compatible. It will therefore run build_torcx_store,
passing relevant options to it, to build a new torcx store of
images with the current sysroot.
This adds --skip_torcx_store to use the previous behavior.
This creates new torcx stores under src/build/torcx, similar to the
layout of src/build/images. The script contains a list of packages
to build so there is a deterministic set that gets branched with
this repository. For development, a different list can also be
given on the command line.
Images are created by building only the direct dependencies of
meta-packages under the app-torcx category. They use the board
root as the sysroot for cross-compiling. The base layout of the
installation root is structured so everything is under either /bin
or /lib for simplicity. Any systemd units are rewritten so they
depend on a successful torcx apply, and they inject the appropriate
torcx runtime directory into the PATH.
When ELF binaries are compiled, they are given an RPATH value of
/ORIGIN/../lib which gets rewritten to $ORIGIN/../lib. The final
value enables automatic dynamic linking with packaged libraries.
The intermediate value is to avoid having to escape the $ through
the various build system layers (which are different for each
package) and it pretends to be an absolute path to silence security
warnings.
We were chowning the host directory, not the one in the chroot.
Host gpg >= 2.1.13 puts the gpg-agent socket in /run/user/UID/gnupg,
which is bind-mounted into the chroot, but the SDK gpg was ignoring it
because /run/user/UID was not owned by UID. This broke tag signing with
YubiKeys.
When OVA template is not being used, the default dhcp value yes will
trigger cloud-init to generate a 00-.network file, which will break
network connectivity Intermittently. Please see the details here:
https://github.com/coreos/bugs/issues/1802#issuecomment-297847614
When building dev images, the PORTAGE_BINHOST value during build
time is written to the image's make.conf. This breaks the default
binary package setup, since Jenkins is using gs:// URLs for signed
package verification and authenticated downloads, and the make.conf
doesn't inherit the GS_* variables to handle those schemes.
This should be reverted when signed packages are properly supported
by default in the dev images.
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
5a76e4e5e9 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 8e754f9c2b.
INFO build_oem_aci: Writing coreos_oem_gce_aci_stage_packages.txt
awk: cmd. line:1: fatal: cannot open file `/build/amd64-usr/var/db/pkg//DEPEND' for reading (No such file or directory)
INFO build_oem_aci: Writing coreos_oem_gce_aci_stage_licenses.txt
awk: cmd. line:1: fatal: cannot open file `/build/amd64-usr/var/db/pkg//DEPEND' for reading (No such file or directory)
