We are not able to login into angstrom images now
since many chnages has gone into upstream OE-core
drop libpam change to drop secure nullok
add empty-root-password to EXTRA_IMAGE_FEAUTURES
it should actually be controlled and added only for
debug images, but thats for production folks
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Lets not mix linaro and non linaro toolchains so let
linaro toolchain fill in gaps for nativesdk when needed
Signed-off-by: Khem Raj <raj.khem@gmail.com>
In angstrom we use linaro gcc for ARM, but only for cross and target
compilers, when it comes to cross sdk compilers then we switch to
OE-core, this worked fine until gcc-source recipe was introduced, the
implementation forces to have just 1 version of gcc sources, which
happens to be provided by linaro gcc here, so as soon as it comes to
building non-linaro gcc it does not know that sources are not in
expected shared location
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Without this multimachine builds blow up due to packages having the same
license between architectures. Shocking and unexpected!
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
error caused in do_rootfs:
| NOTE: > Executing update_pixbuf_cache intercept ...
| FATAL: kernel too old
| WARNING: The postinstall intercept hook 'update_pixbuf_cache' failed (exit code: 127)! See log for details!
and many other 'kernel too old' messages.
So let's trust in OLDEST_KERNEL set by oe-core's bitbake.conf.
Signed-off-by: Andreas Müller <schnitzeltony@googlemail.com>
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
In daisy update-alternatives has been moved from opkg to the opkg-utils recipe.
opkg-utils now creates an additional package update-alternatives-opkg.
Without this patch the opkg-utils recipe is built and the opkg-utils package is
installed for VIRTUAL-RUNTIME_update-alternatives.
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
Remove unused pinnings, use linaro toolchains for arm
including gdb
use OE-Core toolchain for providing native and crossdk
components of toolchain. this helps to choose linaro or
OE-Core toolchain in a single tmpdir and per architecture
still being able to share common components. We really
dont care who provides native and crossdk components anyway
the arm code improvements that come from linaro gcc is
paramount for crossgcc and gcc on target and candian-gcc in
case of SDK where we will use it anyway
Update comments to match current state of affairs
beautify the files a bit
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Remove unused pinnings, use linaro toolchains for arm
including gdb
use OE-Core toolchain for providing native and crossdk
components of toolchain. this helps to choose linaro or
OE-Core toolchain in a single tmpdir and per architecture
still being able to share common components. We really
dont care who provides native and crossdk components anyway
the arm code improvements that come from linaro gcc is
paramount for crossgcc and gcc on target and candian-gcc in
case of SDK where we will use it anyway
Update comments to match current state of affairs
beautify the files a bit
Signed-off-by: Khem Raj <raj.khem@gmail.com>