Verity uses -fstack-protector-strong which was added in 4.7, use -all
instead which is available in 4.6. Dunno what impact this has but we
don't actually use it yet so *shrug*. Only a temporary fix since we
would probably want to fork verity if we use it or drop support entirely
if we decide we never will.
This patch uses relative paths that are rejected by newer and stricter
eclass versions. Pulled from current portage but I'm purposefully *not*
updating the ebuild as the latest texi2html which in turn pulls in a lot
of new perl dependencies and we don't even care about texi2html or the
html docs it is used to produce in the first place so bleh.
This will be used to upload the latest images built from master, we
don't need every build so we just want to upload to a 'master'
directory, not one named for the current version.
The previous logic here only skipped the bootstrap if the toolchain
packages were already installed (which won't happen on the build host)
but we can also skip the bootstrap if binary packages are available
(which will happen on the build host). This will help avoid needless gcc
rebuilds :)
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.
Drop zero padding and format versions as described by the semver spec.
The terminology is a little awkward because we inherited the backwards
meaning of 'BUILD' and 'BRANCH' version identifiers but that the version
strings themselves conform to semver.
(This doesn't change the current version, that'll happen with our next
branch cut)
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.
Add core_upload_update to au-generator.zip which requires some extra
logic to make it runnable anywhere it may be. To organize the code a
little better all the delta_generator calls have been moved to
cros_generate_update_payload. core_upload_update is now just a wrapper
around cros_generate_update_payload and core-admin.
Cgpt was moved and a symlink based wrapper was added. That wrapper will
be improved soon, when when that's true we'll need to change this back.
A specific note... cgpt is currently statically linked. If that wrapper does
not remain statically linked, then a simple revert won't be enough.
BUG=chromium-os:39814
TEST=Manual au-generate.zip creation.
Change-Id: I2705b1eddd8ef28c7eb099512513daf80f586218
Reviewed-on: https://gerrit.chromium.org/gerrit/45128
Reviewed-by: Chris Sosa <sosa@chromium.org>
Commit-Queue: Don Garrett <dgarrett@chromium.org>
Tested-by: Don Garrett <dgarrett@chromium.org>