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 just sets the code file size to the var file size, so it gets
zero-padding without having to pipe commands together.
From: David Michael <david.michael@coreos.com>
[Rebased]
Signed-off-by: Geoff Levand <geoff@infradead.org>
And default to git instead of rsync.
git has no rate limiting and will generally be quicker after the first
run.
This does leave a bit of extra data in your local portage-stable `.git`
directory, but it doesn't seem unreasonable to me.
Note: this means we lose the "ChangeLog" file. In the rsync
repositories, that file has been generated by egencache, but the git
repository never has it checked in.
The motivation behind retaining this backwards compatibility, at least
now, is that it's actually non-trivial to revert these code changes for
a given release.
The `sign.sh` changes can easily be changed, but the `core_sign_update`
code is included in the update-specific "au_zip" file. Replacing that is
a little more fiddly.
Since it's possible we'll still want to revert to the previous signing
behavior, make it so the update payload (namely core_sign_update) should
work both under the previous `sign.sh` script, and when using the new
one.
We currently sign with both a devel key and a prod key. The devel key is
insecure and need not be included on a smartcard, so it makes sense to
leave it be on disk.
However, the previous commit's padding changes removed this legacy
method of signing.
For simplicity, simply re-introduce the old logic conditionally based on
whether it's a smartcard or not.
Alternate options could be using `-pkcs` instead of `-raw` for both
keys, but that is a more intricate change I'd be less confident in
making.
Sign updates using private keys on smartcards. This involves changing the
padding approach - rather than including the padding in the hash, ask the
card to generate the padding itself, since the card will refuse to sign
pre-padded material. Use + as a key separator rather than : as the PKCS#11
URI includes colons.
