When installing with the default make.conf in full effect
/etc/init.d/functions.sh will be excluded which is the whole point of
the efunctions package in the first place. This should fix that.
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.
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.
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.
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
Build in a few ACPI drivers, and remove some hardware-specific drivers
that the boot kernel will never see.
Also disable CONFIG_WATCHDOG, as the boot kernel should never be alive
long enough for a watchdog to need to kick in.
