Age | Commit message (Collapse) | Author |
|
The "sdkbasepath + '/conf/local.conf.bak" doesn't exist when
"oe.copy_buildsystem.check_sstate_task_list()" fails, then os.replace() would
raise FileNotFoundError, which overcomes the real error. Keep the error status
makes debug easier, so remove the try..finally.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
|
|
The "bitbake image -cpopulate_sdk/ext" generates SDK/eSDK for all multilib
variants, so "bitbake lib32-image -cpopulate_sdk/ext" is not needed, and it
doesn't work well, for example:
MACHINE ?= "qemux86-64"
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
$ bitbake lib32-core-image-minimal -cpopulate_sdk_ext
[snip]
Exception: FileExistsError: [Errno 17] File exists: '/buildarea/lyang1/test_q64/tmp/sysroots-components/core2-64/openssl/sysroot-providers/openssl10' -> '/buildarea/lyang1/test_q64/tmp/work/qemux86_64-pokymllib32-linux/lib32-core-image-minimal/1.0-r0/lib32-recipe-sysroot/sysroot-providers/openssl10'
[snip]
The problem is populate_sdk_ext installs all multilib variants, and
extend_recipe_sysroot() handles foo-image depends lib32-foo-image, but doesn't
handle lib32-foo-image depends foo-image, we can use a lot of trick ways to make
it work:
1) Get foo-image's RECIPE_SYSROOT when build lib32-foo-image
2) Handle conflicts with foo-image.do_rootfs
3) Handle conflicts when "bitbake lib32-foo-image foo-image -cpopulate_sdk_ext"
And maybe other potential problems, this looks painful, so just delete the task.
[YOCTO #12210]
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
|
|
Install all MULTILIB_VARIANTS to sysroot and pack them only makes sense to
image recipe, so limit it to image recipe only, and it can fix:
MACHINE = "qemux86-64"
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "core2-32"
$ bitbake lib32-meta-ide-support
WARNING: lib32-meta-ide-support-1.0-r3 do_configure: Manifest for ncurses not found, searched manifests:
/workspace2/lyang1/test_mlwarn/tmp-glibc/sstate-control/manifest-qemux86_64-ncurses.populate_sysroot
/workspace2/lyang1/test_mlwarn/tmp-glibc/sstate-control/manifest-core2-32-ncurses.populate_sysroot
/workspace2/lyang1/test_mlwarn/tmp-glibc/sstate-control/manifest-i586-ncurses.populate_sysroot
/workspace2/lyang1/test_mlwarn/tmp-glibc/sstate-control/manifest-x86-ncurses.populate_sysroot
/workspace2/lyang1/test_mlwarn/tmp-glibc/sstate-control/manifest-allarch-ncurses.populate_sysroot
This is because core2-64 is not in lib32-meta-ide-support's
PACKAGE_ARCHS which doesn't like image recipe (lib32-image recipe's
DEFAULTTUNE is not overridded)
[YOCTO #12298]
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
|
|
This can fix do_rootfs and depends chaos when multilib, for example
ca-certificates is an allarch recipe:
MACHINE = "qemux86-64"
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "core2-32"
IMAGE_INSTALL_append = " ca-certificates"
$ bitbake ca-certificates
$ rpm -qpR tmp-glibc/deploy/rpm/noarch/ca-certificates-20170717-r0.noarch.rpm
[snip]
openssl
[snip]
It requires openssl, but lib32-openssl doesn't proivide it:
$ rpm -qp --provides tmp-glibc/deploy/rpm/core2_32/lib32-openssl-1.0.2l-r0.core2_32.rpm
lib32-openssl = 1.0.2l-r0
So openssl-1.0.2l-r0.core2_64.rpm would be installed when install
ca-certificates, e.g.:
MACHINE = "qemux86-64"
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "core2-32"
IMAGE_INSTALL_append = " ca-certificates"
$ bitbake lib32-core-image-minimal
The openssl-1.0.2l-r0.core2_64.rpm and other 64 bit packages are installed,
this is incorrect.
We have two solutions on this:
1) Let lib32-openssl provide openssl, but this would cause more problems when
building since more than one providers for openssl.
Or
2) Extend allarch recipes, there would be ca-certificates-20170717-r0.noarch.rpm
and lib32-ca-certificates-20170717-r0.noarch.rpm, then ca-certificates
requires openssl, and lib32-ca-certificates requires lib32-openssl, the
packages will be installed correctly, this is the best solution that I can
find.
The problem has existed for years for deb and ipk (rpm did work since it didn't
use lib32-BPN in rpm filename before changed to dnf, for example, there was no
lib32-openssl.core2_32.rpm, but openssl.core2_32.rpm), this patch can fix the
problem for rpm, ipk and deb.
[YOCTO #12288]
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
|
|
The PACKAGE_INSTALL is only used by image recipe, the previous code had
handled it in "if bb.data.inherits_class('image', d)", handle it again
doesn't make any sense (there is no PACKAGE_INSTALL for non-image
recipe), so remove it.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
|
|
Fixed:
MACHINE = "qemux86-64"
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "core2-32"
$ bitbake lib32-wrlinux-image-glibc-small
WARNING: lib32-wrlinux-image-glibc-small-1.0-r1 do_rootfs: Manifest for lib32-qemuwrapper-cross not found, searched manifests:
/path/to/tmp/sstate-control/manifest-qemux86_64-lib32-qemuwrapper-cross.populate_sysroot
/path/to/tmp/sstate-control/manifest-core2-64-lib32-qemuwrapper-cross.populate_sysroot
/path/to/tmp/sstate-control/manifest-x86_64-lib32-qemuwrapper-cross.populate_sysroot
/path/to/tmp/sstate-control/manifest-allarch-lib32-qemuwrapper-cross.populate_sysroot
It was because image recipes' multilib PACKAGE_EXTRA_ARCHS are not changed by
mutlilib.bbclass, so extend_recipe_sysroot() didn't know anything about
mutlilib's PACKAGE_EXTRA_ARCHS, now fix it.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
|
|
The old warning was:
WARNING: lib32-wrlinux-image-glibc-small-1.0-r1 do_prepare_recipe_sysroot: Manifest /path/to/tmp/sstate-control/manifest-allarch-lib32-qemuwrapper-cross.populate_sysroot not found?
The message wasn't clear enough, it searched a few manifests, but only
reported the last one, which confused user.
Now the warning is:
WARNING: lib32-wrlinux-image-glibc-small-1.0-r1 do_rootfs: Manifest for lib32-qemuwrapper-cross not found, searched manifests:
/path/to/tmp/sstate-control/manifest-qemux86_64-lib32-qemuwrapper-cross.populate_sysroot
/path/to/tmp/sstate-control/manifest-core2-64-lib32-qemuwrapper-cross.populate_sysroot
/path/to/tmp/sstate-control/manifest-x86_64-lib32-qemuwrapper-cross.populate_sysroot
/path/to/tmp/sstate-control/manifest-allarch-lib32-qemuwrapper-cross.populate_sysroot
Whick makes debug easier.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
|
|
Fixed:
MACHINE = "qemux86-64"
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
$ bitbake core-image-sato lib32-core-image-sato
$ bitbake build-sysroots
All lib32 manifests which had been built should be installed, but only a few
such as qemux86_64-lib32-base-files were installed (it was installed because
MACHINE_ARCH was still qemux86-64 when multilib), but others such as
x86-lib32-zlib were not installed, this was incorrect. For multilib builds,
fix-up overrides to prepend :virtclass-multilib- and then again append
additional multilib arches from the PACKAGE_EXTRA_ARCHS list if needed can fix
the problem.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
|
|
It only substituted staging_target for target recipe which didn't work
for multilib, for example, postinst-useradd-lib32-polkit:
* No multilib:
PATH=/path/to/tmp-glibc/work/core2-64-wrs-linux/polkit/0.113-r0/recipe-sysroot-native/bin
staging_target=/path/to/tmp-glibc/work/core2-64-wrs-linux/polkit/0.113-r0/recipe-sysroot
The PATH would be substituted to:
FIXMESTAGINGDIRTARGET-native/bin
Not the funny "-native/bin", this works well.
* When multilib:
PATH=/path/to/tmp-glibc/work/core2-32-wrsmllib32-linux/lib32-polkit/0.113-r0/recipe-sysroot-native/bin
staging_target=/path/to/tmp-glibc/work/core2-32-wrsmllib32-linux/lib32-polkit/0.113-r0/lib32-recipe-sysroot
Now staging_target endswith "/lib32-recipe-sysroot", so it can't
replace '/recipe-sysroot-native' in PATH , so PATH can't be fixed, and
there would be build errors when building multilib + rm_work, for
example:
chown: invalid user: ‘polkitd:root’
Substitute staging_host for target recipe can fix the problem, now all
of native, cross and target need substitute staging_host, so we can
simply the code a little.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
|
|
Fixed:
MACHINE = "qemux86-64"
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
$ bitbake <image> -cpopulate_sdk_ext
$ bitbake <image> -ctestsdkext
[snip]
Standard Output: /bin/sh: 1: i686-wrsmllib32-linux-gcc: not found
[snip]
It was failed because no lib32 toolchain or lib installed.
This patch fixes:
* Set SDK_TARGETS correctly
* Return multilib depends in get_ext_sdk_depends()
* Write information to all environment-setup-* scripts.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
|
|
Fixed:
MACHINE = "qemux86-64"
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
$ bitbake <image> -cpopulate_sdk_ext
[snip]
Exception: subprocess.CalledProcessError: Command 'sed -e [snip]'
[snip]
Subprocess output:
[snip]
sed: can't read /path/to/work/qemux86_64-wrs-linux/wrlinux-image-glibc-small/1.0-r1/recipe-sysroot/usr/lib/perl/5.24.1/ExtUtils/Liblist/Kid.pm: No such file or directory
[snip]
It was failed because "/usr/lib" is in qemux86_64-wrsmllib32-linux/, not in
qemux86_64-wrs-linux. The code has considered mutitlib, but seems not
completed, the multilib "variant" was not in fixme, so it wasn't handled
correctly, this patch fixes the problem.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
|
|
Various recipes that inherit cmake contain FILES_${PN}-dev magic to add the
generated package files to their -dev packages. Since this is a standard
feature of cmake, we might as well teach cmake.bbclass to do this itself so
those recipes can be simpler.
Signed-off-by: Mike Crowe <mac@mcrowe.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
It is duplicated to previous.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
It had been dropped by:
commit 65581c68d130fa74d703f6c3c92560e053857ac7
Author: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Date: Mon Feb 13 16:44:48 2017 +0200
rootfs_rpm.bbclass: migrate image creation to dnf
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The previous code:
os.rename(sdkbasepath, temp_sdkbasepath)
try:
foo
finally:
os.rename(temp_sdkbasepath, sdkbasepath)
always renamed the path, it made the debug harder when error happened.
drop the "try: finally" makes the debug easier.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Otherwise it would generate lines like the following when multilib:
INHERIT += "own-mirrors"SSTATE_MIRRORS += " \n file://.* file:///path/to/../share/sstate-cache/PATH"
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This is very useful for debugging. The similar to testsdk.bbclass.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
To make it easier to debug problems with renaming caused by debian.bbclass,
explicitly log when packages are renamed.
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Although the meson crossfile should take care of setting the right cross
environment for a target build, meson slurps any set CFLAGS, CXXFLAGS,
LDFLAGS, and CPPFLAGS from the environment and injects them into the
build (see mesonbuild/environment.py:get_args_from_envvars for details).
This means that we are seeing native CFLAGS, CXXFLAGS, LDFLAGS, and
CPPFLAGS in the target build, which is wrong and causes build failures
when target and native have libraries in common (the linker gets
confused and bails).
That said, we *do* need to set certain vars for all builds so that meson
can find the right build tools. Without this, meson will fail during its
sanity checking step because it will determine the build tools to be
unrunnable since they output target instead of native artifacts.
The solution to all of this is to set CC, CXX, LD, and AR globally to
the native tools while setting the other native vars *only* for the
native build. For target builds, these vars will get overridden by the
cross file as we expect.
Signed-off-by: Martin Kelly <mkelly@xevo.com>
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
gnomebase.bbclass hardcodes the autotools inherit, so make it
configurable and allow meson to be specified instead.
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
[RP: patches tweaked to only need the one class]
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Improve binary reproducibility of RPM packages.
Ensure timestamps in RPM packages are not later than the value
of SOURCE_DATE_EPOCH. If SOURCE_DATE_EPOCH is not set,
timestamps are not clamped.
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
If no ptest packages are installed in the image, the test does nothing;
if ptest packages are installed in the image, then they should be
run without user having to enable that manually.
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The original recipe has been provided and improved by:
Ross Burton <ross.burton@intel.com>
Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Adam C. Foltzer <acfoltzer@galois.com>
Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Linus Svensson <linussn@axis.com>
I have added patches to fix up gtk-doc and
gobject-introspection in cross-compilation environments,
and also change the order of linker arguments to replicate
autotools more closely (and fix linking errors in some corner
cases).
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Currently we can't access this function from lib/oe as its a class function.
Move it to allow such access.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The "ls -s sparse_file"'s result is 0, use stat to replace of it.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
When using kernel-fitimage class with microblaze, the image type has to be
linux.bin not zImage. This patch fixes the bad image type replacement
for microblaze
Signed-off-by: Manjukumar Matha <manjukumar.harthikote-matha@xilinx.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Add aarch64 32-bits (ILP32) ELF header into dictionary and
check binaries for 32-bitness.
Signed-off-by: Daniel Díaz <daniel.diaz@linaro.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
More information about ARM64 ILP32 can be found here:
* https://wiki.debian.org/Arm64ilp32Port
* https://wiki.linaro.org/Platform/arm64-ilp32
Signed-off-by: Daniel Díaz <daniel.diaz@linaro.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
As discussed and agreed in Linaro Connect Budapest 2017 [1],
the GNU name for ARM64 with 32-bit ABI has been changed, e.g.,
from:
aarch64_ilp32-linux-gnu
to:
aarch64-linux-gnu_ilp32
The current code has "ilp32" as an OS variant; this change
updates that variant to include the underscore in order to
match the agreed convention.
More information about ARM64 ILP32 can be found here:
* https://wiki.debian.org/Arm64ilp32Port
* https://wiki.linaro.org/Platform/arm64-ilp32
[1] https://lists.linaro.org/pipermail/cross-distro/2017-March/000864.html
Signed-off-by: Daniel Díaz <daniel.diaz@linaro.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
When using kernel-fitimage class with aarch64, the image type has to be
Image not zImage. This patch fixes the bad image type replacement for
aarch64
Signed-off-by: Thomas Perrot <thomas.perrot@tupi.fr>
Signed-off-by: Manjukumar Matha <manjukumar.harthikote-matha@xilinx.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
The 32bit core-image-minimal-initramfs should be built when build lib32-iso, e.g.:
MACHINE = "qemux86-64"
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
IMAGE_FSTYPES += "iso"
$ bitbake lib32-core-image-minimal
Exception: FileExistsError: [Errno 17] File exists: '/path/to/tmp/sysroots-components/core2-64/qemuwrapper-cross/usr/bin/crossscripts/qemuwrapper' -> '/path/to/tmp/work/qemux86_64-pokymllib32-linux/lib32-core-image-minimal/1.0-r0/lib32-recipe-sysroot/usr/bin/crossscripts/qemuwrapper'
This was because:
lib32-core-image-minimal -> core-image-minimal-initramfs
core-image-minimal-initramfs -> qemuwrapper-cross
lib32-core-image-minimal -> lib32-qemuwrapper-cross
So we got the error, build lib32-core-image-minimal-initramfs can fix the problem.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
It's a problem when initramfs is invalid, so print warn rather than note.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Some distros may want to provide alternate kernel "flavors" via feeds or
within bootable images. For example, readily available builds which
provide certain diagnostic features can enable developers and testers to
more quickly resolve issues by avoiding lengthy kernel builds.
This change allows for building multiple flavors of the kernel and
module packages by templatizing kernel package names via a new
KERNEL_PACKAGE_NAME variable in kernel.bbclass. It defaults to the old
name of "kernel", but can be overridden by certain recipes providing
alternate kernel flavors.
To maintain compatibility, recipes providing alternate kernel flavors
cannot be the "preferred provider" for virtual/kernel. This is because
OE puts the preferred provider's build and source at
"tmp-glibc/work-shared/$MACHINE/kernel-build-artifacts/" and
"tmp-glibc/work-shared/$MACHINE/kernel-source/" instead of
"tmp-glibc/work/*/$PN/" like other recipes. Therefore, recipes using the
default KERNEL_PACKAGE_NAME="kernel" follows the old semantics -- build
in the old location and may be preferred provider -- while recipes using
all other KERNEL_PACKAGE_NAME's build from the normal WORKDIR and don't
provide "virtual/kernel".
Testing:
1. Add `KERNEL_PACKAGE_NAME_pn-linux-yocto-tiny = "tiny-linux"`
to local.conf so that linux-yocto-tiny may build alongside
the main kernel (linux-yocto).
2. `bitbake linux-yocto linux-yocto-tiny` to build both kernel flavors.
3. Verified image and modules IPKs exist for both:
tmp-glibc/deploy/ipk/qemux86/kernel-* for linux-yocto
tmp-glibc/deploy/ipk/qemux86/tiny-linux* for linux-yocto-tiny
4. Verified linux-yocto is the "preferred provider", and was built in
shared directory: tmp-glibc/work-shared/qemux86/kernel-*
5. Add `CORE_IMAGE_BASE_INSTALL_append_pn-core-image-base = "tiny-linux"`
to local.conf to install both kernel flavors in core-image-base.
6. `bitbake core-image-base` to build an image.
7. Verified image contains two bzImage's under /boot/, with
"yocto-standard" (linux-yocto recipe) selected to boot via symlink.
Discussion threads:
http://lists.openembedded.org/pipermail/openembedded-core/2015-December/thread.html#114122
http://lists.openembedded.org/pipermail/openembedded-core/2017-July/thread.html#139130
[YOCTO #11363]
Signed-off-by: Ioan-Adrian Ratiu <adrian.ratiu@ni.com>
Signed-off-by: Gratian Crisan <gratian.crisan@ni.com>
Signed-off-by: Haris Okanovic <haris.okanovic@ni.com>
Coauthored-by: Gratian Crisan <gratian.crisan@ni.com>
Coauthored-by: Haris Okanovic <haris.okanovic@ni.com>
Coauthored-by: Josh Hernstrom <josh.hernstrom@ni.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
On some build hosts distros (e.g. Fedora 26) waf tries to be
smart about libdir detection and defaults to [EXEC_PREFIX/lib64].
This obviously is not what we want for 32-bit targets and usually
fails in the do_package phase:
WARNING: gstreamer1.0-plugins-imx-0.13.0-r0 do_package: QA Issue: gstreamer1.0-plugins-imx: Files/directories were installed but not shipped in any package:
/usr/lib64/libgstimxcommon.so.0
...
Depending on version, waf knows prefix or prefix, bindir and
libdir as default options. Explicitly pass the right set of
arguments.
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
During the introduction of support for multiple kernel image types in
849b67b2e4820564b5e5c9bd4bb293c44351c5f3, do_sizecheck was changed to only
warn if any kernel was bigger than ${KERNEL_IMAGE_MAXSIZE}. (Well, it tried
to warn - it turns out that there's no function called "warn", it should be
"bbwarn".) The previous behaviour had been to fail the build if the single
kernel image did not fit.
It seems possible that people might be generating both compressed and
uncompressed kernels and only really care whether the compressed one fits.
This means that we shouldn't just always fail if any of the images are too
large. So, let's warn (correctly this time) on every image that is too
large, but only ultimately fail if no image will fit. The build will also
fail if ${KERNEL_IMAGETYPES} is empty, but I hope that no-one needs to do
that.
While we're here correct a typo in the KERNEL_IMAGE_MAXSIZE validity check.
Signed-off-by: Mike Crowe <mac@mcrowe.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
As warned in a proir commit, it's time to remove the elf image type,
it is not long used anywhere (that I am aware of) and the mkelfimage
tool has been removed from the upstream coreboot code base.
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Debugedit provided by rpm 4.14 is rewriting binaries in-place, and was
found to produce broken output at least for grub:
http://lists.openembedded.org/pipermail/openembedded-core/2017-November/143989.html
A replacement utility was suggested via private mail:
https://lists.fedorahosted.org/archives/list/elfutils-devel@lists.fedorahosted.org/message/VZP4G5N2ELYZEDAB3QYLXYHDGX4WMCUF/
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
|
|
The 'wic' image may use files which has been deployed (e.g in
do_deploy) for some partitions that may need to be copied in a
specific partition or filesystem (e.g a bootloader).
When using 'bitbake <image> -c image_wic', from a clean build, the
contents of do_deploy must also be available so we need to ensure all
do_deploy of the image dependencies has been complete.
Reported-by: Fabio Berton <fabio.berton@ossystems.com.br>
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
There is a race with rm_work when tasks run deltask do_build since
do_rm_work becomes a floating task. Handle this by injecting
the populate_sysroot/lic dependencies manually if the tasks returned
are empty. This depends on a change to fix bb.build.preceedtask() in
bitbake too.
[YOCTO #12365]
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
We actually caught the ext4 size issue in the wild with the debug
output in the oe_mkext234fs() code, but it did not help. What that
showed was that the get_rootfs_size was returning a default size of
8192, where as the actual rootfs was more like 10572, thus too large
to fit in the created sparse file.
This additional temporary debug code should help us determine where
the failure might be.
More debug for
[YOCTO #12304]
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
This will speed up file creation and still allow the btrfs tools to
create a full btrfs image. This is similar to what we do for ext234
FS types.
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
So that both QEMU_USE_KVM = "True" and "1" will work.
[YOCTO #12343]
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
The pypi.bbclass has usefullness in many meta layers, not
just meta-python. Add it to oe-core for the benefit of
everyone.
Documentation strings for PYPI_PACKAGE, PYPI_PACKAGE_EXT and
PYPI_SRC_URI added to meta/conf/documentation.conf
Signed-off-by: Tim Orling <timothy.t.orling@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
For uninative to work, it relies on it being updated to new versions as
newer glibcs are built. This means the uninative generated by the current
build may not be as recent as the uninative that is being downloaded by
uninative.bbclass.
If this occurs, we can get symbol mismatch errors.
Ultimately, the sstate and the uninative versions need to match so we
should use the same tarball as uninative.bbclass is using, not the one
we built.
[YOCTO #12405]
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Running:
$ oe-selftest -r sstatetests.SStateTests.test_sstate_sametune_samesigs
after commit cdcebd81c872cb7386c658998e27cf24e1d0447c results in:
NOTE: Resolving any missing task queue dependencies
NOTE: Multiple providers are available for runtime lib32-initd-functions (lib32-initscripts, lib32-lsbinitscripts)
Consider defining a PREFERRED_RPROVIDER entry to match lib32-initd-functions
and will occasionally pick a different value on the second stamps run
causing a test failure. Update the multilib code to handle
PREFERRED_RPROVIDER too.
There is a bigger worry here which is why the builds aren't deterministic. This is
caused by a bug in bitbake's providers.py and a separate fix will be sent for that
which would cause this test to always pass or always fail.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
As a follow up to the changes to ensure that KBUILD_DEFCONFIG will
always get its defconfig into the processing, we also should ensure that
we don't get both a KBUILD_DEFCONFIG and a SRC_URI defconfig in the
configuration queue. If both are in the configuration queue, we end up
with competing values and a potentially long running check of 5000+
options x 2 against the final .config.
By removing the defconfig found from the SRC_URI when one is found
via KBUILD_DEFCONFIG, we ensure that only one will be processed.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The bberror does not stop the build correctly, this should be a
bbfatal_log to ensure the failure correctly stops the build and logs
the failure.
Part of
[YOCTO #12162]
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|