Prior to this, "${P}" would match upstream gentoo's distfile cache of
containerd, and that tarball would be used regardless of our SRC_URI
changing as we bumped the commit hash.
That resulted in us having an incorrect version of containerd installed
(and lying about the commit hash in --version to boot. Yikes!)
This fixes it by ensuring our package name actually uniquely identifies
the containerd package.
The choice to use the number of commits since the version as the patch
number is fairly arbitrary, but seemed like a sane and comparable number
to choose.
Due to containerd's somewhat fragile versioning, this number is not
technically unique (since there the v0.2.3 bump is commit to multiple
branches), but we can deal with issues if they happen.
Alternative fixes, such as FETCH_RESTRICT or other means of fooling the
cache logic, are more error prone and less faithful to portage's intent
that ${P} does uniquely identify an upstream source.
A different fix would be to use a CROS_WORKON style process for
containerd. There's no particular reason that approach is being avoided
other than the need to hack on containerd has so far been fairly small.
We can be more sloppy with versioning if/when we switch containerd over
to that process.
The choice to rename to 0.2.3 is because that commit (see
containerd/version.go) chooses to call itself 0.2.3, though it's newer
than the v0.2.5 tag. Docker 1.12 actually used a commit that contained
the 0.2.5 tag.
This is only an issue when the glibc versions differ between the
SDK and the sysroot. The M4 library detection functions in gettext
do bad things on their own, so bypass them.
The Ignition units are only used in the initramfs and are intertwined
with several other units in bootengine. Move them into bootengine for
simplicity.
This updates the ebuild to include a patch number indicating changes
since the referenced version number.
This is because docker uses untagged versions of runc, and so we need
additional version information.
Prior to this change, the runc ebuild inadvertently used the upstream
distfile cache of runc's distfile, regardless of the commit referenced
and the -r bumps.
This also re-fixes CVE-2016-9962. The patch for that vulnerability was
dropped once we thought the commit contained the fix, but since the
commit was being ignored and the fix never made it into any tagged
release, we accidentally regressed.
Finally, tihs updates the selinux patch. This was sourced from
projectatomic/runc on the docker-1.13.1 branch.
Our GRUB config specifies tty0 as the primary console, but it was being
forced to the serial port instead. As a result, boot failures produced
no visible error messages on tty0, and the emergency shell was likewise
inaccessible.
Now that Packet uses Ignition to configure systemd-networkd units
before systemd-networkd starts, the workaround described in the
below issue is no longer necessary:
https://github.com/coreos/bugs/issues/36
This reverts commit 7f3b121e061d4592729161026f18abe5444f22f0, reversing
changes made to aaaef8fa392528e6b57135a960428e9ef8b0dfbc.
I messed up and cherry-picked into master instead of the build-1298
branch and it worked because the file in question had since been renamed
to rc4.
This reverts that extraneous file.
Specifically, this drops the bindist USE flag, skips installing
some init.d files, and updates KEYWORDS for our architectures.
The build fix carried previously has been dropped since it is now
included in the upstream source archive.
