We have to actually remove these as opposed to ~keywording them because
crossdev will always use packages from overlays if they exist.
This won't actually impact anyone's SDK just yet as update_chroot will
only use binary packages for the toolchains. It will keep checking for
updates but not do anything until those updates are available from the
binhost. So the next release will switch to the new toolchain.
We no longer have any correlation between ebuild category and whether
the local checkout can be found in src/platform or src/third_party.
Instead provide a new variable to manually specify which it should be.
As-is it isn't possible to build local changes in src/platform trees.
lbzip2 is surprisingly fast and is particularly useful for dealing with
large archives and filesystem images. In a similar vein pbzip2 has been
used for handling binary packages for a while but lbzip2 seems a bit
better. Since I plan on using the heck out of lbzip2 add it to the build
and system package sets. While mucking around might as well start
swapping pbzip2 for lbzip2 for consistency's sake although it doesn't
seem to matter much for binary packages. For now we can only switch
make.conf for targets, the host make.conf can't change till everyone's
SDK has lbzip2 installed.
Previously only targets were being built with bindist but we should
build the SDK with it as well. This avoids the re-compile of openssl,
openssh, and freetype when creating a new chroot since the SDK tarballs
are already built with the bindist flag. Also turn the bindist flag back
on for freetype in the target profile, we don't need ClearType sub-pixel
rendering on our systems. :)
This places a dev signing key on disk for testing purposes. As noted in
the ebuild a production key will replace this key when building official
images.
Update to latest release. cros_sdk is still using this file instead of
version.txt in the manifest because it needs a tarball that already
exists when building a new version for the first time. At some point
that will work differently but for now we'll have to keep this file.
We were already using the default for CFLAGS, etc. LDFLAGS had
--as-needed but that has gone into the default Gentoo profile so we
ought to move it there as well. Also, ld's -O1 and -O2 are equivalent so
use the profile default -O1.
The version will now be tracked in the manifest so the old
coreos_version.sh needs to source it from there. Also export variables
with a COREOS_ prefix in addition to CHROMEOS_ since the latter name
isn't really correct. This is particularly true for the data published
via lsb_release.
