Replace ChromiumOS target binhosts with our own. The auto-generated
files have been stubbed out and configs for targets we don't currently
support have been removed. MARCH_TUNE is now defined here.
After this change target binhosts will defined here and
/etc/make.conf.board and overlay-amd64-generic/make.conf are no longer
used. The new setup_board only creates /etc/make.conf.board_setup.
This file mostly just defined BINHOSTs but I'd like to move that
completely into coreos-overlay as the SDK BINHOSTs have always been. It
also sourced src/overlays/overlay-amd64-generic/make.conf but I want to
move the few things it defined into coreos-overlay as well.
The one interesting thing this file did was to optionally define
ACCEPT_LICENSE but that can go into /etc/make.conf.board_setup instead.
Overall this takes a chunk out of the make.conf spaghetti. :)
With these installed bootstrap_sdk should work inside the sdk itself.
Probably won't add this to the sdk by default since it pulls in extra
stuff most people don't need and is only really needed for build hosts.
Building our own packages so we don't want the old ones! This is just a
first stage, automated builds aren't going yet and I'm not covering
amd64-generic and its cross toolchain, just the sdk.
The old binhost/host/*.conf files are just stubbed out until I'm
positive nothing else is referring to them.
As-is catalyst and cros-workon's live ebuilds don't mix since the
catalyst chroot does not provide /mnt/host like the sdk chroot does.
Besides, only people actively working on a project should use the live
versions since anyone else will install it one time and then never
upgrade after that, even when the version marked stable is actually
newer than their old live build.
For SDK builds this means not accepting ~amd64 for core-admin and
update_engine and adding a stable ebuild for core-admin. (update_engine
already has a stable ebuild which is even up-to-date)
Despite the big scary warning saying otherwise upstream Gentoo has
actually included shadow in this list since 2011 (while also forgetting
to delete the warning, cute!). Not having it here runs the risk of
causing a failure during catalyst builds if something tries to add a
system user or group before shadow gets installed.
Upstream commit:
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/profiles/default/linux/packages.build?r1=1.5&r2=1.6
This version of efunctions does not depend on cros workon and git to
install and thus is suitable for bootstrapping. It also uses the
original author as the upstream rather than a coreos mirror. Since it is
not coreos specific any more I've moved it to sys-apps.
Added to both system and bootstrap package sets.
For extra fun it is also in my new systemd-only Gentoo overlay:
https://github.com/marineam/systemd-only-overlay
The old-style virtual/portage is gone and replaced by a new-style
virtual/package-manager in Gentoo. For now just use sys-apps/portage
since that's all we want anyway.
By default emerge will not install build dependencies if it doesn't need
them (i.e. installing a binary package) but we want to make sure
everything gets included in stage4 no matter how it was installed.
This uses Gentoo's catalyst for very thoroughly building images from
scratch. Using images based on this will eliminate some of the hackery
in make_chroot.sh for building up the sdk from a stock stage3 tarball.
For reference the procedure it performs is this:
1. snapshot: Grab a snapshot of portage-stable. Note that overalys are
not snapshotted.
2. stage1: Using a "seed" tarball as a build environment, build a
minimal root file system into a clean directory using ROOT=...
and USE=-* The restricted USE flags are key be small and avoid
circular dependencies.
3. stage2: Run portage-stable/scripts/bootstrap.sh
This rebuilds the toolchain. Probably not strictly necessary most of
the time but does super-duper-promise that the toolchain isn't linked
to or otherwise influenced by whatever was in the "seed" tarball.
4. stage3: Run emerge -e system to rebuild everything using the fresh
toolchain using the normal USE flags provided by the profile. This
will also pull in assorted base system packages that weren't included
in the minimal environment stage1 created.
5. stage4: Install any extra packages or other desired tweaks. For the
sdk we just install all the packages normally make_chroot.sh does.
This was over a year out of date and it seems a sizable number of the
ones for Apache aren't responding so downloading an old version of
subversion has been less than happy with the old list...
Meant to add this last week... It can either pull from Gentoo CVS or a
local directory (in case you rsynced the whole portage tree). Just name
a package by pkg-cat/name and it will update portage-stable.
Enable:
CONFIG_MACVLAN=m
CONFIG_MACVTAP=m
CONFIG_VETH=m
Docker needs VETH, and might use MACVLAN in the future, it can't hurt to
enable them, they take up no running space if not used.
As-is all of the various emerge wrapping scripts default to using
--getbinpkg whenever --usepkg is enabled. This means every single emerge
command made makes multiple synchronous HTTP requests to the upstream
binary package repository to get the latest package list. This gets
really frustrating when working remotely with limited network
connectivity. Using --usepkg with --nogetbinpkg will use locally cached
packages without making remote requests.
This feature forces emerge to only fetch sources from mirrors, never the
SRC_URI provided in actual ebuilds. Disabling this should fix our issues
with portage tarballs vanishing. :-D
