Now uses the package database instead of filesystem so the check works
even if /bin and friends are symlinks to /usr. Also disable the
whitelist and check that the expected symlinks are correct if the
symlink-usr USE flag is enabled.
- it shouldn't be possible to set the SDK version to the same as the new
tag's version. The SDK must always be a previous build.
- don't fail if there isn't any old manifests to git rm.
There are ways to improve, it'd be sexy if it was truly safe and we
could throw around annoying terms like idempotent to make this kind of
sequence just work but doesn't yet: tag_release; tag_release --push
On CoreOS we use systemd to manage docker containers. Having docker
automatically start containers on reboot makes everything confused. Stop
doing this.
Some packages bundled with old gnulib fail to build, reporting ‘gets’
undeclared here. Bump the two I know of (so far) to pull in the fix from
upstream Gentoo.
This makes double sure that the symlink is never removed by INSTALL_MASK
or PKG_INSTALL_MASK. This symlink is so strictly required by random
tools we cannot allow it to ever go missing by mistake.
When calling update_chroot with --usepkg --nogetbinpkg the default
emerge command line will force binary packages for the toolchain but if
the packages are not available locally building via crossdev is
required. Since the crossdev bootstrap process rebuilds the toolchain a
couple times with different use flags if binary packages are forced the
second stages gets skipped resulting in a broken gcc and glibc install.
Instead of gating only on --usepkg depend on both flags as a pair. This
keeps setup_board's behavior a little closer to build_packages. The
buildbot is using --nogetbinpkg to avoid pulling in existing packages
built by the SDK but setup_board is causing some to be pulled in anyway.
glibc 2.16 has been marked stable upstream. By chance it also fixes
cross compiling header files in /usr/include/rpcsvc which should resolve
rpcbind's build failure searching for rpcsvc/mount.h. This previously
was not an issue because the hacky glibc install copied the files
directly from the host chroot into the target sysroot directories.
A case of binary packages masking breakage, didn't notice this broke
because I didn't happen to trigger a build of gmerge during my testing.
This package.provided file contained the hackily installed toolchain
which is now handled via a normal emerge instead.
