Our current version, 1.2, is quite old. Bump to the latest stable (1.4)
with an eye towards bumping to 1.5 as soon.
Packages updated:
app-emulation/qemu
sys-firmware/ipxe
sys-firmware/seabios
x11-libs/pixman
We don't have a valid kernel (or use-case to have one) for "cros_host"
(the SDK) so just fake it. Also remove some unused flags.
This change prevents the latest kmod ebuild from pulling in
coreos-kernel, bootengine, and friends into the SDK.
The old chroot version system we inherited from Chromium OS always
assumes that a newly unpacked tarball is the latest and greatest but
since we version the SDK in the same way as target builds we can use
that version for these sorts of upgrade scripts and not make assumptions
about how late and great the starting tarball was.
The first upgrade script simply aborts to force the user to recreate
their chroot when moving from python 2.6 to 2.7.
I want to start including version info in SDK builds as an alternative
scheme to the existing "chroot_version_hooks" system which always
assumes freshly unpacked SDKs are the latest regardless of what version
they actually were.
argparse is bundled into python-2.7 so dev-python/argparse cannot be
installed. Instead the virtual package should be used to work with any
python version combination.
The python-r1 eclass makes upgrading major python versions a lot cleaner
by selecting the python implementation via use flags. To take advantage
of this as much as possible in the pending 2.7 upgrade bump all packages
that had ebuilds referring to the old python eclasses that have stable
ebuilds using the new eclasses in upstream Gentoo portage.
Packages updated:
app-text/gnome-doc-utils
dev-java/java-config
dev-libs/libxml2
dev-libs/libxslt
dev-python/argparse
dev-python/boto
dev-python/cherrypy
dev-python/dbus-python
dev-python/httplib2
dev-python/jinja
dev-python/lockfile
dev-python/markupsafe
dev-python/mock
dev-python/numpy
dev-python/paramiko
dev-python/pycairo
dev-python/pycrypto
dev-python/pyflakes
dev-python/pyinotify
dev-python/pyopenssl
dev-python/pyserial
dev-python/python-daemon
dev-python/python-dateutil
dev-python/pyxdg
dev-python/setproctitle
dev-python/simplejson
dev-python/six
dev-python/tempita
dev-python/unittest2
dev-python/ws4py
dev-util/gdbus-codegen
dev-vcs/subversion
media-libs/alsa-lib
sys-devel/clang
sys-devel/llvm
virtual/python-argparse
virtual/python-unittest2
They have some patches to fix cross-compiling in this build environment.
Start off simply by adding 2.7 as a new parallel install target, will
switch to 2.7 as the primary version in a later step.
This flag enables 'at_console' policy support using logind. I don't
think we actually have a use for that and having it disabled hasn't
caused anything weird that I know of so far so leave it disabled.
Enabling this flag causes a circular dependency between systemd and dbus
which is resolved in catalyst bootstrapped builds like the SDK but for
target builds this is a problem.
No need for me to maintain a similar profile in two entirely different
ways. This is also one tiny step towards cleaning up our profiles in
general. Original here: https://github.com/marineam/systemd-only-overlay
As part of this change the baselayout dependency on openrc is now
handled via a use flag instead of package.provided. We didn't previously
include a virtual/init package but Gentoo has one and I needed it for my
generic systemd-only overlay so might as well include it here if it is
needed in the future.
The recommended command using the config file was triggering a massive
memory leak in qemu because it was adding both the default virtual
hardware nic as well as the virtio nic. This could be worked around by
adding something like -net none or moving all the -net commands from the
file to the command line but eh. Clearly qemu config files are used and
tested by nobody else so lets just use a trusty script instead.
