It has some weird semantics that seem to trip us up after updating
bash to 5.1. We tried to use it inside functions to clean up some
stuff after function returns. This can be emulated with an EXIT trap
within a subshell. Fortunately all the users of the RETURN trap were
not setting any global variables - modifications of such variables are
local to the subshell and are lost when the subshell exits.
We are enabling CgroupV2 support globally, which requires Docker 20.10.
It is possible to return to CgroupV1 locally via kernel commandline, but
that will still work with Docker 20. If someone really needs older
Docker versions we will recommend to also fetch torcx packages from
older releases or rely on upstream binaries.
Since EAPI=7 was supported, portage can no longer use different
ROOT and SYSROOT values. The torcx images were installed into a
temporary root directory after being built using the board's
development files. To continue using this setup, the torcx image's
packages are built as normal binary packages for the board root
without being installed, then the binary packages are installed in
the temporary torcx root.
The new Docker release schedule has a new release every six months
after 18.09, which has a support period longer than our current LTS
versions. Drop the LTS torcx image and let Docker versions promote
normally again.
Per the comment there, they were implemented in a broken fashion.
This leaves the door open for using them in the future, but in the
meanwhile simply uses the sha512sum as the digest (which solves the
immediate issue).
This also moves the 'torcx' prefixing logic over to the torcx upload
root introduced in the release util library.
It also corrects a bug in how the source package was being determined.
This modifies the `build_torcx_store` script to produce a manifest and
cas-like structure of packages referenced by that manifest.
It also removes the symlink creation logic (which will be re-added in
build_image in coming commits).
The concept of "extra packages", which are referenced in the manifest,
but aren't installed in the rootfs, is also introduced.
Since the logic of what to include in the rootfs is also extracted into
build_image, supporting these "extra packages" isn't very complicated
for this file.
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.
