It was going to be used in torcx manifest generation, but that
dependency has been removed for now.
I'm optimistically leaving the ebuild in.
Removing it from sdk-depends should speed up sdk bootstrap at least.
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 moves the default symlinking logic into build image as well.
This assumes that a torcx store is available locally with all images
referenced in the torcx manifest.
This is accomplished with a highly-indented double-for-loop, but I think
it's still decently readable.
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.
Torcx is special in that it wishes to be uploaded under a prefixed
directory (torcx), typically wishes to be downloaded from there, but
ultimately wants to be downloaded from a location without that prefix.
In fact, I expect during a normal release process, it will be uploaded
with that prefix to the build bucket, copied without that prefix to the
final bucket (during pre-release), and then finally downloaded without
the prefix.
I think this set of variables ends up being the cleanest way to
represent this complexity.
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 seems to fix the ccache permission issues `update_chroot` hits
while building ninja.
The erroneous files were created as root:portage, so a umask of 002
should let other portage group members share them, which seems entirely
reasonable.
This is a fairly boring meson ebuild. I had to apply a patch to make it
build.
This is included in the sdk for the torcx packaging work, where we'd
like to get a digest of a given torcx pkg. `casync digest` works well
for that and can be pointed at a directory easily enough.
The docker client and engine both include a 'BuildTime' variable set in
their build scripts.
Overriding that to a consistent value is sufficient for them to build
reproducibly as best I can tell.
This CLI's build scripts have a mechanism for doing this. The engine has
an upstream patch (included starting with 17.07) that allows doing the
same.
This modifies the build to apply the above build patch, and set a build
time for both.
It's expected that the build time will be set by the ebuild author each
time the ebuild is modified, thus turning the 'build time' output to
really be the 'package created time', which I think is a reasonable
difference.
