| Age | Commit message (Collapse) | Author |
|---|
|
The environment setup script generated in the build directory sets the PATH
variable by expanding ${PATH} which would have host paths filtered. Sourcing
this script to run runqemu will not work as it complains host stty (/bin/stty)
cannot be found.
To resolve this, the script no longer expands ${PATH} during generation time,
instead it will now source oe-init-build-env to initialize the build
environment so that all host paths will be preserved. Also be sure to prepend
STAGING_BINDIR_TOOLCHAIN to the PATH variable so that the toolchain from the
build directory can be found.
[YOCTO #12695]
(From OE-Core rev: a64a144096c0637387244b89ed22f4b5352b2522)
Signed-off-by: Chin Huat Ang <chin.huat.ang@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
git.gnome.org is no more. It has ceased to be. It's an ex-git.
Please see here:
https://about.gitlab.com/2018/05/31/welcome-gnome-to-gitlab/
Note that gitlab does not support git://, only https:// (and ssh).
[Commit message from Alexander Kanavin]
(From OE-Core rev: 8382cdc0888ca645a44aacaac1155afb8dcde979)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[Fixup for sumo context]
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
${PN}-${LICENSE_PACKAGE_SUFFIX} in packages
* linux-firmware contains ${PN}-license package since this commit:
commit 1ee083da0730408fffdbbf5f29abc299c0e61be9
Author: Jackie Huang <jackie.huang@windriver.com>
Date: Mon Apr 13 10:17:21 2015 +0800
linux-firmware: fix the mess of licenses
* LICENSE_CREATE_PACKAGE functionality in license.bbclass when enabled
adds new package with suffix:
LICENSE_PACKAGE_SUFFIX ??= "-lic"
but then it checks if ${PN}-${LICENSE_PACKAGE_SUFFIX} is included
in PACKAGES before adding it and when found it shows:
WARNING: linux-firmware-1_0.0+gitAUTOINC+4c0bf113a5-r0 do_package: linux-firmware-lic package already existed in linux-firmware.
and doesn't add the ${PN}-lic to PACKAGES and causes another warning:
WARNING: linux-firmware-1_0.0+gitAUTOINC+4c0bf113a5-r0 do_package: QA Issue: linux-firmware: Files/directories were installed but not shipped in any package:
/usr
/usr/share
/usr/share/licenses
/usr/share/licenses/linux-firmware
that's because it was searching ${PN}-lic in PACKAGES as a string
so it found ${PN}-lic as a substring of ${PN}-license, add a split
to search in an list
(From OE-Core rev: 9b9897fc034819385a9d4ce591cc79dd458f3f24)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[Yocto 12572]
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
Since ${SSTATE_ARCHS} now contains ${PACKAGE_EXTRA_ARCHS} there is no
longer any need to add those extra architectures to the list of
architectures handled in get_deployed_dependencies().
(From OE-Core rev: e55e6df4f1434458cdfa0e2d3610b48119e5a782)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
We assume that LIC_FILES_CHKSUM is a file: URI but don't actually verify this,
which can lead to problems if you have a URI that resolves to a path of / as
Bitbake will then dutifully checksum / recursively.
[ YOCTO #12883 ]
(From OE-Core rev: e2b8a3d5a10868f9c0dec8d7b9f5f89fdd100fc8)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
Commit d2aa88a6a92985f21414fceea2dc0facbf7f8779 was meant to backport build
dependencies on bc-native and openssl-native, but it also changed execution
of do_make_scripts() from calling make directly to using oe_runmake. That
change was made in master/sumo as part of a separate make-mod-scripts recipe.
Unfortunately, that doesn't work here in rocko in the context of module-base
class, as it gets executed inside out-of-tree module environment. Quite often
those out-of-tree modules provide own Makefile with custom EXTRA_OEMAKE var
defined. But do_make_scripts() gets executed within STAGING_KERNEL_DIR and
cannot simply use custom EXTRA_OEMAKE set by a module.
Move back to calling make and passing HOSTCC/HOSTCPP directly w/o using
EXTRA_OEMAKE.
For more details please see:
http://lists.openembedded.org/pipermail/openembedded-core/2018-August/154189.html
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
Cc: Bruce Ashfield <bruce.ashfield@windriver.com>
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: Anuj Mittal <anuj.mittal@intel.com>
Cc: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Armin Kuster <akuster@mvista.com>
|
|
Newer kernels (4.14/v4.15+) have dependencies for the build of
modules (and hence external modules). Without these dependencies
explicitly in the build chain, you can end up with build failures like:
work-shared/qemux86/kernel-source/scripts/extract-cert.c:21:25: fatal
error: openssl/bio.h: No such file or directory
| #include <openssl/bio.h>
| ^
| compilation terminated.
| make[2]: *** [scripts/extract-cert] Error 1
| make[1]: *** [scripts] Error 2
To ensure that these headers are in place, and that the scripts use
our build environment flags, we add a dependency on openssl-native
and use oe_make to invoke the build.
Older kernels have no issues with the extra dependency, so there's no
need to make this conditional.
(From OE-Core rev: 916cb2029d3c97bf12ebf03832b9ba980451dbcf)
Fixes [YOCTO #12860]
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[Tweaked to have changes in module*.bbclass instead from where
make-mod-scripts was split in sumo]
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
Kernels which use tools/objtool can now fail when building external modules
due to objtool being missing, the generated files can also cause problems
for kernel-devsrc.
Ensure objtool is generated in make-mod-scripts by also calling
"make prepare".
For devsrc, delete the generated binaries since they'd be native
binaries and unsuitable for the target.
The oeqa kernel module tests also need to have the additional "make prepare"
step added.
(From OE-Core rev: 52fd2993784b4218f5df4f343e7da45d964df305)
Fixes [YOCTO #12860]
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[Tweaked to add "make prepare" to module-base.bbclass instead of
make-mod-scripts.bb]
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
Add a Debian snapshot mirror from 2018 (specifically, 10th March, the date 9.4
was released) to DEBIAN_MIRRORS.
(From OE-Core rev: f3f394913b4e4a7c601ad1158faaf8b9d493e1c7)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
The isELF function works by running:
result = file <pathname>
if 'ELF' in result
By default 'file' will prepend the result with the path name of the file
that is being checked. This usually works fine, such as:
$ file /home/foo/openembedded-core/meta/classes/package.bbclass
/home/foo/openembedded-core/meta/classes/package.bbclass: Python script, ASCII text executable, with very long lines
However, if the path includes 'ELF', ELF will end up in the result, and then
the check will return positive.
$ file /home/ELF/openembedded-core/meta/classes/package.bbclass
/home/ELF/openembedded-core/meta/classes/package.bbclass: Python script, ASCII text executable, with very long lines
This will then result in the isELF coming back true, and possibly causing the
checks that use isELF, such as the 'is it already stripped' check, to do the
incorrect thing.
Adding the '-b' option to file will result in the path being omitted in the
result:
$ file /home/ELF/openembedded-core/meta/classes/package.bbclass
Python script, ASCII text executable, with very long lines
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
(cherry picked from commit 5a324e9b2cf6378f8eaa4e394f9cb36d4e2680ac)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Apparently there are recipes in the wild which generate files with
filenames containing '$' characters - which cause errors during
packaging.
Instead of adding another special case to escape '$' characters when
constructing the command passed to oe.utils.getstatusoutput(), switch
to using single quotes to quote the path - and therefore make isELF()
consistent with the way filenames and paths are quoted by every other
caller of oe.utils.getstatusoutput() in oe-core.
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
(cherry picked from commit 7877761534b0c2492da6289e9f2269d41b6ed464)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This reverts commit 46ddc11a8be79515b4ab9f9f7568c3d624ac72fe.
The change is good in master but became subtly broken during the
backport to rocko. Either the path passed to file should be quoted
using double quotes (with any " chars in the path being escaped) or
the path should be quoted using single quotes (and then any " chars
in the path should NOT be escaped). Escaping " chars and using single
quotes will cause problems for filenames containing " chars.
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
* this doesn't work correctly as discussed in:
http://lists.openembedded.org/pipermail/openembedded-commits/2018-January/218460.html
* some of the issues were fixed in master since then
but not all, so revert it until it's completely resolved
This reverts commit eac21f981337bfaddb2d67161a1ff049158041ce.
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
Its possible some dynamic runtime library in the dependency chain may
come from sstate and link to libraries which need the libc from
uninative. If we don't do this and binaries are run at do_install time
they would fail to find the symbols from the later libc. Examples:
cmake-native do_install:
bin/cmake: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not found (required by TOPDIR/tmp/work/x86_64-linux/cmake-native/3.10.3-r0/recipe-sysroot-native/usr/lib/libexpat.so.1)
dbus-native do_install:
tmp/work/x86_64-linux/dbus-native/1.12.2-r0/build/bus/.libs/lt-dbus-daemon: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not found (required by /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x32/build/build/tmp/work/x86_64-linux/dbus-native/1.12.2-r0/recipe-sysroot-native/usr/lib/libexpat.so.1)
This issue is resolved when the interpreter is changed at sstate unpack
time but this isn't soon enough to avoid issues at compile/install time.
By specifing which dynamic linker/loader to use at compile time, this
race window is removed entirely.
(From OE-Core rev: 35867ee035030ab76fc9ccdb0eb1c3f80126301c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
We have a problem when for example, a glibc 2.27 based system builds some
library like libpopt-native and puts it into sstate then it is reused
on a pre glibc-2.27 system to build something which depends on popt like
rpm-native. This results in an error like:
recipe-sysroot-native/usr/lib/libpopt.so: undefined reference to `glob@GLIBC_2.27'
In the past we've had this problem with new symbols like getrandom and
getentropy, here its with a more complex symbol where there is an old
version and a newer version.
We've looked into various options, basically we cannot link against our
uninative libc/ld.so since we don't have the right headers or compiler
link libraries. The compiler doesn't allow you to switch in a new set
either, even if we did want to ship them. Shipping a complete compiler,
dev headers and libs also isn't an option.
On the other hand if we follow the ld man page, it does say:
"""
The reasons for allowing undefined symbol references in shared libraries
specified at link time are that:
- A shared library specified at link time may not be the same as the one
that is available at load time, so the symbol might actually be
resolvable at load time.
"""
which is exactly this case. By the time the binary runs, it will use
our uninative loader and libc and the symbol will be available.
Therefore we basically have a choice, we get weird intermittent bugs,
we drop uninative entirely, or we pass this option.
If we pass the option, we can drop the other workarounds too.
(From OE-Core rev: 75a62ede393bf6b4972390ef5290d50add19341a)
(From OE-Core rev: d18bf7fa8e80d6cfaf3fdbe1ab06eec84b954432)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[Clean up for Rocko context]
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
The isELF function works by running:
result = file <pathname>
if 'ELF' in result
By default 'file' will prepend the result with the path name of the file
that is being checked. This usually works fine, such as:
$ file /home/foo/openembedded-core/meta/classes/package.bbclass
/home/foo/openembedded-core/meta/classes/package.bbclass: Python script, ASCII text executable, with very long lines
However, if the path includes 'ELF', ELF will end up in the result, and then
the check will return positive.
$ file /home/ELF/openembedded-core/meta/classes/package.bbclass
/home/ELF/openembedded-core/meta/classes/package.bbclass: Python script, ASCII text executable, with very long lines
This will then result in the isELF coming back true, and possibly causing the
checks that use isELF, such as the 'is it already stripped' check, to do the
incorrect thing.
Adding the '-b' option to file will result in the path being omitted in the
result:
$ file /home/ELF/openembedded-core/meta/classes/package.bbclass
Python script, ASCII text executable, with very long lines
(From OE-Core rev: 5a324e9b2cf6378f8eaa4e394f9cb36d4e2680ac)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[fixup for Rocko]
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
When it was something else than /usr/libexec (e.g. when
installing native SDK packages), things broke down.
(From OE-Core rev: d99e819a6cbde6d1116c434ddba4c5f8eca7e6d8)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster@mvista.com>
|
|
recipe parsing
When uninative is activated (poky's default) internal datastore variables are modified (NATIVELSBSTRING and SSTATEPOSTUNPACKFUNCS) to enable uninative
support. This is happening after parsing is done at the beginning of the build. On the next bitbake call the recipe would be parsed if the two
variables above were not added to the parsing whitelist BB_HASHCONFIG_WHITELIST.
The fix is to add these two variables to the recipe parsing whitelist BB_HASHCONFIG_WHITELIST, this is done at recipe parsing time, only when
uninative.bbclass is used.
(From OE-Core rev: 75bb95ada98ef129d2fa48568f27dddb078c852c)
Signed-off-by: Cuero Bugot <cbugot@sierrawireless.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster@mvista.com>
|
|
Recipes which use a shared workdir (e.g. gcc-runtine and libgcc) can
race over temporary files causing interesting build failures.
Using B instead of S avoids this problem.
[YOCTO #12605]
(From OE-Core rev: d6c13a5ff441f7076eb327c0d0b747bd7603db0f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
Debian anonscm service in Alioth is shutdown and thus
fetching sources fails.
https://wiki.debian.org/Alioth
"Alioth is broken, and there is nobody around to fix it. Don't ask the remaining people who give it life support to implement fixes and changes. It is being replaced by a cocktail of ?GitLab (see Salsa), read-only repos and keep-alive mechanisms. See below for more information."
https://wiki.debian.org/Salsa
"What is Salsa?
Salsa is the name of a collaborative development server for Debian based on the gitlab software. Salsa is supposed to provide the necessary tools for package maintainers, packaging teams and other Debian related individuals and groups for collaborative development.
What is the status of Salsa?
After various discussions about the future of Alioth, the Alioth Sprint in August 2017 gave birth to the initial setup of the the upcoming Salsa service. The productive weekend resulted in a working prototype and was launched as a beta in December 2017. It left its beta status in January 2018."
(From OE-Core rev: 08ff7b42d8b7d06ef61255185c95e900ada8769b)
Signed-off-by: Mikko Rapeli <mikko.rapeli@bmw.de>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
On some linux hosts image recipes will fail to build as follows:
ERROR: build-essential-0.3-r0 do_image_ext3: Usage: bbdebug [123] "message"
ERROR: build-essential-0.3-r0 do_image_ext3: Function failed: do_image_ext3 (log file is located at /opt/build/tmp/work/intel_corei7_64-wrs-linux/build-essential/0.3-r0/temp/log.do_image_ext3.43744)
ERROR: Logfile of failure stored in: /opt/build/tmp/work/intel_corei7_64-wrs-linux/build-essential/0.3-r0/temp/log.do_image_ext3.43744
ERROR: Task (/opt/layers/meta-overc/meta-build/recipes-core/images/build-essential_0.3.bb:do_image_ext3) failed with exit code '1'
Running with bitbake -v -v -v -D we get in the log file:
+ bbdebug 1 Executing 'dd if=/dev/zero of=/opt/build/tmp/work/intel_corei7_64-wrs-linux/build-essential/0.3-r0/deploy-build-essential-image-complete/build-essential-intel-corei7-64-20180220190510.rootfs.ext3 seek=484486 count=0 bs=1024'
+ USAGE='Usage: bbdebug [123] "message"'
+ '[' 3 -lt 2 ']'
+ DBGLVL=1
+ shift
++ echo 1
++ echo 1
++ tr -d t
++ tr -d t
+ NONDIGITS=1
+ '[' 1 ']'
+ bbfatal 'Usage: bbdebug [123] "message"'
The debug output tells us that the NONDIGITS check failed to remove
the digits using the tr expression. Enclosing the expression in
quotes causes it to work properly.
(From OE-Core rev: 9e6d283aa9c77685f55a62fa220226d9149ecd7a)
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
If we're building a SDK and we're using glibc so may be installing locales,
add a build-dependency on natiesdk-glibc-locale so the locales we need will
exist.
(From OE-Core rev: 8d6869a0a89d8cf3c6e57723fab2750ba2c885db)
(From OE-Core rev: 602fad36954a8e6a31b1c4d7a3ac9c002dcc8b8d)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
As glibc 2.27 can't read older locale-archives, SDKs using glibc 2.27 on hosts
using glibc earlier than 2.27 won't be able to find any locales, so bitbake
won't start and Python can't use UTF-8.
So by default install all locales into the SDK. Special-case Extensible SDKs by
installing no locales as they ship glibc in a buildtools, and that will have the
locales.
Locale installation requires cross-localedef, so add that to DEPENDS.
Also remove the explicit en_US addition in buildtools-tarball as it is now
redundant.
(From OE-Core rev: 96896568d197cd06302713c24c0f7d91bfaea6c1)
(From OE-Core rev: 8327d50ef66c94592d76b42e147011daafc6a7c3)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
If glibc is newer on the host than in uninative, the failure mode is
pretty nasty for clusters where the sstate is shared, including the Yocto
Project autobuilder.
This check aborts the use of uninative in such scenarios where a newer
glibc version appears and avoids corruption of sstate caches.
We use ldd to check the glibc version since that is included in libc-bin
(or equivalent) which locales use so it should always be present.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
(From OE-Core rev: 8f9d6f92edb5682a7f2012af6466dbcd19e2e422)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
I noticed many new QA warning with arm64 mulitlib
suspicious values 'initd-functions-dev' in RRECOMMENDS [multilib]
I believe this is a regression via commit
http://cgit.openembedded.org/openembedded-core/commit/meta/classes/update-rc.d.bbclass?id=cdcebd81c872cb7386c658998e27cf24e1d0447c
(From OE-Core rev: 223119dc96d2e37e3788df630d1995bf56dc156a)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
OE-Core changes the architecture independent RPM packages to use
"noarch" instead of "all". This change has been included in the commit
below:
,----
| commit 341810aff923ace6b1cc1e15e19383c4f8773b51
| Author: Alexander Kanavin <alexander.kanavin@linux.intel.com>
| Date: Mon Jan 9 16:37:28 2017 +0200
|
| package_rpm.bbclass: make architecture-independent .rpm packages
| "noarch" instead of "all"
|
| Too many places in dnf/rpm4 stack make that assumption; let's not
| fight against it.
|
| Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
`----
This is causing problems with machines that has "all" inside the
machine name.
Reported-by: Alexandru Palalau <ioan-alexandru.palalau@nxp.com>
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Ross Burton <ross.burton@intel.com>
(cherry picked from commit 3e4ddeab65d4d2e4aaf03d442c2a1a8c7a2ce8a2)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
Image will be generated for arm64, and no compression for Image in u-boot as
well. So we just put the file into the right place for the rest of the build
to find it.
Signed-off-by: Zumeng Chen <zumeng.chen@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
(cherry picked from commit ce6337ab4b415ee18360dfe4443a71ab75a60254)
Signed-off-by: Armin Kuster <akuster808@gmail.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>
(cherry picked from commit f387c28640cbb209b8a8ed5734b21c754d9f7663)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
If two builds are sharing the same DL_DIR, and the uninative file is local
to a layer. When the first build gets to uninative it creates the link local
to itself, and subsequent users can use the same link. However if that first
build then is deleted from the disk, the symlink is no longer valid (broken).
We need to update the system to detect this case, and use the model
implemented by the bitbke fetch2 code. Look for a broken link, remove it,
then try to create the link and ignore an exception if it already exists
(since we just unlinked any bad one).
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit bfd9664edad7044b5da53fc33b8d0f6508f00950)
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
commit 7e98c295c1bb511e [kernel-yocto: ensure that only a single
defconfig is processed] has an overly broad replacement strategy
for 'defconfig' and hence will chop up any fragment name that
happens to contain that string.
If we change the processing to split on whitespace and drop
any full work 'defconfig' fragments, we'll get the behaviour
we want (no duplicate defconfigs, but fragments with defconfig
in their name are fine).
[YOCTO #12487]
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
The current conflicting use of SDKDEPLOYDIR causes a race between do_populate_sdk
and do_populate_sdk_ext potentially causing the SDK to either go missing or the
build to fail.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
repos don't conflict
(From OE-Core rev: c9c0927bb6e71253cbdd5b6b780dca829526e1d8)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Currently, setting PV to include SRCPV for build-appliance results in:
bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression was
${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher
failure: Fetch command export ftp_proxy="http://proxy.yocto.io:5187/"; export
FTP_PROXY="http://proxy.yocto.io:5187/"; export PATH="${TMPDIR}/work/
qemux86_64-poky-linux/build-appliance-image/fetcheravoidrecurse-r0/
recipe-sysroot-native/usr/bin/python3-native:${TMPDIR}/work/
qemux86_64-poky-linux/build-appliance-image/fetcheravoidrecurse-r0/
recipe-sysroot-native/usr/bin/python3-native:${TMPDIR}/work/
qemux86_64-poky-linux/build-appliance-image/fetcheravoidrecurse-r0/
recipe-sysroot-native/usr/bin/python3-native:/home/pokybuild/
yocto-autobuilder/yocto-worker/buildtools/build/scripts:${TMPDIR}/
work/qemux86_64-poky-linux/build-appliance-image/fetcheravoidrecurse-r0/
recipe-sysroot-native/usr/bin/x86_64-poky-linux:${TMPDIR}/work/
qemux86_64-poky-linux/build-appliance-image/fetcheravoidrecurse-r0/
recipe-sysroot/usr/bin/crossscripts:${TMPDIR}/work/qemux86_64-poky-linux/
build-appliance-image/fetcheravoidrecurse-r0/recipe-sysroot-native/usr/sbin:
${TMPDIR}/work/qemux86_64-poky-linux/build-appliance-image/
fetcheravoidrecurse-r0/recipe-sysroot-native/usr/bin:${TMPDIR}/work/
qemux86_64-poky-linux/build-appliance-image/fetcheravoidrecurse-r0/
recipe-sysroot-native/sbin:${TMPDIR}/work/qemux86_64-poky-linux/
build-appliance-image/fetcheravoidrecurse-r0/recipe-sysroot-native/bin:/home/
pokybuild/yocto-autobuilder/yocto-worker/buildtools/build/bitbake/bin:${TMPDIR}
/hosttools"; export HOME="/home/pokybuild"; git -c core.fsyncobjectfiles=0
ls-remote git://git.yoctoproject.org/poky failed with exit code 127, output:
/bin/sh: 1: git: not found
This is because PV is being expanded when TMPDIR is unset.
Expand PV in advance to avoid this problem.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit e7da9a3adc1ed430fff7afae4233e62313759b65)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
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>
(cherry picked from commit d14adead5861007ac7e95c32396491f907ab9f8f)
Signed-off-by: Armin Kuster <akuster808@gmail.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>
(cherry picked from commit eee3ec805cf150f1c701427a2d182a537a67e8f5)
Signed-off-by: Armin Kuster <akuster808@gmail.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>
(cherry picked from commit e164f931c8b3046a8b6736166f8dd6d92f727d1c)
Signed-off-by: Armin Kuster <akuster808@gmail.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>
(cherry picked from commit 923f91d8d8606141ce218927bc943f4f4f34bcdd)
Signed-off-by: Armin Kuster <akuster808@gmail.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>
(cherry picked from commit 59f1ee104d1a6c04b0690b7c8ce481449da174d6)
Signed-off-by: Armin Kuster <akuster808@gmail.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>
(cherry picked from commit de2f2fc9e8e6d874a11e69adc2f438975a5c1359)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
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>
(cherry picked from commit 0f537d985b7b17af508a511fca8a4ec4b5804580)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
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>
(cherry picked from commit 7e98c295c1bb511ece51b5f8c97f26c173ddaf76)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
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>
(cherry picked from commit 44ff06635e7f575e67b7ebba5d6900b8ddbc4a06)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
When using KBUILD_DEFCONFIG, $sccs should be set to the $WORKDIR/defconfig
regardless if it compares or is copied. Otherwise $sccs is not set and the
defconfig is not found correctly.
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>
(cherry picked from commit b63cc051f1eb58c768f49db2c04843336e62d3df)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
When read-only-rootfs is active, we need to ensure that the rootfs
does not get mounted read/write by the kernel or initramfs. Adding
"ro" to the boot parameters achieves that.
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
(cherry picked from commit cfc09de06ecc12bb42181004689e881c75072665)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
When installing systemd template units with an argument, the current code
removes characters between the '@' and the '.' from service names in
SYSTEMD_SERVICE_${PN}, e.g.:
getty@tty1.service -> getty@.service
This fails for services with dots in the argument (which is perfectly
legal in systemd), since the code searches only until the first dot.
E.g.:
vlan@eth0.1.service -> vlan@1.service
This is obviously wrong, and fails in systemd_populate_packages(), where
it fails to find the unit file.
Fix this by reworking the removal of the argument part of the service
name, so that parts before '@' and after teh last '.' are used as base
name.
Signed-off-by: Martin Hundebøll <mnhu@prevas.dk>
Signed-off-by: Ross Burton <ross.burton@intel.com>
(cherry picked from commit 4704bd91458a728f28cbdc57dcf78f5d04cfd0cd)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
Sanity check for future packages.
[YOCTO #10944]
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
(cherry picked from commit 061fa614cec49deb0374ccadf3013e5cc8ad2c51)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
This kludge is not needed anymore, now that syslog packages (or any
other package) don't use update-alternatives for managing SysV init
scripts.
This reverts commit fc89a3f739ff25306ea91d9bdb424fc8389bdf72.
[YOCTO #10944]
(cherry picked from commit 7cb951a803deca151344d905bf2fab038e72e0d0)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
Stop using update-alternatives for managing /etc/init.d/functions. Also,
make the initscripts-functions subpackage to (runtime) conflict with
lsbinitscripts.
[YOCTO #10944]
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
(cherry picked from commit cdcebd81c872cb7386c658998e27cf24e1d0447c)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
Chin Huat Ang
Richard Purdie
Martin Jansa
Peter Kjellerstedt
Ross Burton
Denys Dmytriyenko
Bruce Ashfield
Mark Hatle
Andre McCurdy
Alexander Kanavin
Cuero Bugot
Mikko Rapeli
Jason Wessel
Armin Kuster
Otavio Salvador
Zumeng Chen
Thomas Perrot
Robert Yang
Stefan Agner
Mike Crowe
Saul Wold
Patrick Ohly
Martin Hundebøll
Markus Lehtonen