There are a variety of files being installed into $datadir which we
don't need. Pick the top "offenders" which amount of thousands of files
and simply don't install them. These include things like test data,
terminfo data, locale data for native tools and so on. This saves
copying these files into native and target sysroots and should improve
performance (smaller sstate, fewer files to copy around).
With this and the python recipe change, alsa-tools went from:
recipe-sysroot: 18357
recipe-sysroot-native: 14129
to
recipe-sysroot: 10809
recipe-sysroot-native: 8079
which is a decent improvement.
(From OE-Core rev: 064b38c29543761186862cdbfe0155082137a212)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 366c72941fe1c24d0b1d96df46e13cb9eb4e79d6)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
python2-native executable is not available in sysroot anymore, which
causes compilation of some nodejs modules to fail. Switch to python3 as a
default python version.
(From OE-Core rev: 5cc15f53d55923815a859009a1ffe6cff145b6d7)
Signed-off-by: Vyacheslav Yurkov <uvv.mail@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit d21f50ecf8e8683a92b7d234fa8225c2c1470595)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some packages don't have shrinkwrap file which
means no npmsw uri is provided in the recipe.
(From OE-Core rev: 2c17be47120d388cffafe8213a4b8a92d537805c)
Signed-off-by: Kamel Bouhara <kamel.bouhara@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 47760b0d7d66b2b68ee197d359f0b7b17374d742)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The tar output seems to vary depending on the version of tar used and distro
configuration. Be explict about the output format to avoid this and be
determinstic.
(From OE-Core rev: c56f3c9febc1732aa1302524c6c4da36f16bd1f7)
(From OE-Core rev: a9b4a1e82eb45832dd641a77733737c6fd759890)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 9dbe0f69f8)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
add CVE_VERSION_SUFFIX to indicate the version suffix type, currently
works in two value, "alphabetical" if the version string uses single
alphabetical character suffix as incremental release, blank to not
consider the unidentified suffixes. This can be expand when more suffix
pattern identified.
refactor cve_check.Version class to use functools and add parameter to
handle suffix condition.
Also update testcases to cover new changes.
(From OE-Core rev: 5dfd5ad5144708b474ef31eaa89a846c57be8ac0)
(From OE-Core rev: 73f8c25a44ee33866a8fa61824437285cea96249)
Signed-off-by: Lee Chee Yang <chee.yang.lee@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 86b42289bd)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The way distutils.version.LooseVersion compare version are tricky, it treat
all these ( "1.0-beta2", "1.0-rc1", "1.0A", "1.0p2" and "1.0pre1") as greater
version than "1.0". This might be right for "1.0A" and "1.0p1" but not for
the rest, also these version could be confusing, the "p" in "1.0p1" can be
"pre" or "patched" version or even other meaning.
Replace Looseversion with custom class, it uses regex to capture common
version format like "1.1.1" or tag format using date like "2020-12-12" as
release section, check for following known string/tags ( beta, rc, pre, dev,
alpha, preview) as pre-release section, any other trailing characters
are difficult to understand/define so ignore them. Compare release
section and pre-release section saperately.
included selftest for the version class.
[YOCTO#14127]
(From OE-Core rev: 6ced85e9ddd3569240f1e8b82130d1ac0fffbc40)
(From OE-Core rev: 02a44b507a1e49a4c460f3e1bec92832b71dfe08)
Signed-off-by: Lee Chee Yang <chee.yang.lee@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 3807c6d9a7)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
An exception is fired when a BuildStarted event is sent to buildhistory bbclass
and the variable BUILDHISTORY_FEATURES is not set.
ERROR: Execution of event handler 'buildhistory_eventhandler' failed
Traceback (most recent call last):
File "<...>/meta/classes/buildhistory.bbclass", line 862, in buildhistory_eventhandler(e=<bb.event.BuildStarted object at 0x7f94c3810250>):
python buildhistory_eventhandler() {
> if e.data.getVar('BUILDHISTORY_FEATURES').strip():
reset = e.data.getVar("BUILDHISTORY_RESET")
AttributeError: 'NoneType' object has no attribute 'strip'
This can happen in a multiconfig build where the default configuration use the
buildhistory class but not the configuration in mc. It should be a rare case that
this happens and it was found in a missconfigured build.
(From OE-Core rev: a74e30a4de02c8efd3e7102ba7a4fe06df53cc34)
(From OE-Core rev: 83ee03a6f05ff60459dbcc4fcfb78f95bb0b4848)
Signed-off-by: Peter Bergin <peter@berginkonsult.se>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 55ead1be58)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The srctree_hash was calculated only from main source directory ignoring
changes in submodules.
[YOCTO #13748]
Use submodule--helper to determine all submodules, and calculate hash
from all git tree objects names combined.
(From OE-Core rev: 50ff9afb3990bcf60b4fa1f937506cb84028c32d)
(From OE-Core rev: 6d8a58b11117372fdbf0a86fbc6698ee509fc816)
Signed-off-by: Tomasz Dziendzielski <tomasz.dziendzielski@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 9385670add)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a user executes the environment script instead of sourcing it,
there's an error about an empty element in PATH. This is because
bitbake isn't present in environment variable PATH. Hence, this
patch adds a sanity check to verify if bitbake is present in
PATH and if bitbake isn't present issue a warning message.
[YOCTO #13822]
(From OE-Core rev: e08799913a7f207bc63e085eb98196fd61ed57bc)
(From OE-Core rev: 59de426a624edcb02a0f7ad53ee5955d9f3b2cf3)
Signed-off-by: Dorinda Bassey <dorindabassey@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit dbd80a923c)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a user builds in a path in PSEUDO_IGNORE_PATHS, random failures
are generated. Hence this patch adds a sanity check in sanity.bbclass
to ensure that a user isn't building in PSEUDO_IGNORE_PATHS.
[YOCTO #14179]
(From OE-Core rev: 7a681525e904914e938de25df5cc64209097d15d)
(From OE-Core rev: 35f3e08c52e163e4496c0222896c49888ad5c960)
Signed-off-by: Dorinda Bassey <dorindabassey@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit bfeeaf9ff1)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If srcdir is under poky directory (e.g. devtool poky/build/workspace/sources)
and is not a git repository then ${@srctree_hash_files(d)} will run "git
rev-parse --git-dir" and detect poky directory as git-dir and run "'git', 'add',
'-A', '.'], cwd=s_dir" trying to add srcdir but build dir is in .gitignore and
latest git will fail with "The following paths are ignored by one of your
.gitignore files: build" which will end with "ExpansionError during parsing".
In this commit I added a check if git_dir is the same as git-dir from
TOPDIR (which will detect poky directory) and if yes, then treat srcdir
as non-git sources.
(From OE-Core rev: 95fbac8dcad6c93f4c9737e9fe13e92ab6befa09)
(From OE-Core rev: 1da57e92812a1025d975204797b761a3be3998aa)
Signed-off-by: Tomasz Dziendzielski <tomasz.dziendzielski@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 28bdfe0066)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
None is a bad choice of return value for functions used in variables
(strings) as a failure results in concatination errors. Use a string
with a clear meaning that can be searched for instead.
(From OE-Core rev: 4e8022635fc8543d135fed3091a9f555899d1b3c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
By default the wic working directory is placed under the output
directory. When invoking wic under bitbake, the wic output directory is
added to PSEUDO_PATHS_IGNORE to avoid issues with files being removed
from outside a pseudo environment (see oe-core commit ad8f5532ff).
However, wic will copy the rootfs directory into its working directory
if it needs to add or remove content before creating a filesystem image.
This copy of the rootfs directory must be tracked by pseudo in order to
keep the permissions correct in the resulting image. So we can't have
the wic working directory under a path in PSEUDO_PATHS_IGNORE unless
we like broken permissions.
To fix this the new '-w' argument to wic is used to move the working
directory away from the output directory.
Note that wic deletes the temporary working directory automatically
when it finishes creating an image so users won't normally see the
'tmp-wic' directory under WORKDIR.
Fixes [Yocto #14129]
(From OE-Core rev: 28d2e131555372a79499746057468cb18db69d69)
Signed-off-by: Paul Barker <pbarker@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 4d07169499c47fa9dc759e6f81843416a6dc25c5)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This allows programs from HOSTTOOLS (e.g. 'install', 'rm', 'mv', etc) to
be more easily executed by wic. Without this change only programs from
an actual *-native recipe built by bitbake can be executed by wic.
(From OE-Core rev: 00474d990174c3c4af6e0a6058871f925380750a)
Signed-off-by: Paul Barker <pbarker@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 8eb186acdecfbb3151c9a0ab148358e3fe5cce39)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* now without ${COREBASE}/meta in PSEUDO_IGNORE_PATHS after:
73d538f207 bitbake.conf: Prevent pyc file generation in pseudo context
the do_package tasks are failing when LICENSE_CREATE_PACKAGE is enabled
pseudo.log shows that it's because of license texts copied from
${COREBASE}/meta:
path mismatch [46 links]: ino 96733640 db '/OE/build/tmp-glibc/work/all-oe-linux/foo/1.0/image/usr/share/licenses/foo/generic_Apache-2.0' req '/OE/build/openembedded-core/meta/files/common-licenses/Apache-2.0'.
(From OE-Core rev: d850874e865f2cb2417d520820c3c5288cae38c5)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
go 1.15 has reworked internal linker, which has resulted in regressions
in OE where native binaries generated using internal linker in some
cases result in corruption during populate_sysroot e.g. glide-native
crashing when used after relocation.
This improved reliability of native binaries working especially when
they use cgo or pie build modes
(From OE-Core rev: 7fa9d5719aa02a9baa4f389c2d24f5de8939f46b)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Cc: Otavio Salvador <otavio.salvador@ossystems.com.br>
Cc: Konrad Weihmann <kweihmann@outlook.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit daf4856ea3ccafc05c808a34d4c6af2bfafea12f)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
pseudo-native is a bit special. It conditionally compiles in support for
xattr, statx and statvfs amongst other options. If a pseudo-native binary is
used on a system where these functions are present but it wasn't compiled in
we see hard to debug permissions problems.
An example is the devtool.DevtoolExtractTests.test_devtool_deploy_target
oe-selftest which shows a cryptic error:
File "/home/pokybuild/yocto-worker/oe-selftest-fedora/build/meta/lib/oeqa/selftest/cases/devtool.py", line 1388, in test_devtool_deploy_target
self.assertEqual(filelist1, filelist2)
File "/usr/lib64/python3.9/unittest/case.py", line 831, in assertEqual
assertion_func(first, second, msg=msg)
File "/usr/lib64/python3.9/unittest/case.py", line 1037, in assertListEqual
self.assertSequenceEqual(list1, list2, msg, seq_type=list)
File "/usr/lib64/python3.9/unittest/case.py", line 1019, in assertSequenceEqual
self.fail(msg)
File "/usr/lib64/python3.9/unittest/case.py", line 670, in fail
raise self.failureException(msg)
AssertionError: Lists differ: ['-rwxr-xr-x 6000 6000 /etc/init.d/mdmonitor', '-rw-r-[10124 chars]n.8'] != ['-rwxr-xr-x root root /etc/init.d/mdmonitor', '-rw-r-[10124 chars]n.8']
First differing element 0:
'-rwxr-xr-x 6000 6000 /etc/init.d/mdmonitor'
'-rwxr-xr-x root root /etc/init.d/mdmonitor'
This is due to a version of pseudo without statx being used on a system where
ls uses statx, hence the files are displayed as 6000.6000 instead of root.root.
Avoid this by always building pseudo-native for the specific distro in question rather
than using a universal sstate feed.
This hopefully fixes one of the mysterious AB-INT issues.
(From OE-Core rev: d3ec2ecdf8915a9fb1c4ea36a29b05090abf089c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 6e3785a3f1f3cf68f5fe101cd6bebe91db165973)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Yi pointed out that commit 1a70a92d1f10 ("kernel-module-split.bbclass:
identify kernel modconf files as configuration files") is
unintentionally adding the actual kernel /lib/modules .ko files to the
CONFFILES variable.
The root cause is the re-use of the 'files' variable in that commit.
Fix it by using a separate variable to keep track of the generated
module .conf files that need to be marked as configuration files.
Fixes: 1a70a92d1f10 ("kernel-module-split.bbclass: identify kernel modconf files as configuration files")
Reported-by: Yi Zhao <yi.zhao@windriver.com>
(From OE-Core rev: 6cc93de69fc53af0a3b7fb8d6c6201d4911e78b9)
Signed-off-by: Gratian Crisan <gratian.crisan@ni.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit db5f2ca532db4f0d2e05b7cb5f9d146e1dd76ab3)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The current implementation will always pick an existing templateconf.cfg if
present else it will use the one from OE. A user might not always want to pick
an existing tempalteconf.cfg even if its present. Introduce
SDK_CUSTOM_TEMPLATECONF variable to provide an option for the user to specify if he
wants to use an existing custom templateconf.cfg or not
If SDK_CUSTOM_TEMPLATECONF=='1' then enable custom templateconf.cfg. By default
SDK_CUSTOM_TEMPLATECONF is set to '0'
(From OE-Core rev: c59ffcc4ba70cec8b6342a0205b880953919cba7)
Signed-off-by: Sai Hari Chandana Kalluri <chandana.kalluri@xilinx.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit d0f863a24d05bddeb21e181fb01fa0051c79d7d8)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We now depend on tar 1.28, so talking about older tar versions is just
confusing.
(From OE-Core rev: 22c7bbdaecd9eea52bf919e363ee68ce8256bdbd)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit f19e43dec63a86c200e04ba14393583588550380)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If files are copied into /usr/src/debug directly from WORKDIR (e.g. makedevs)
we'd get the permissions from the checkout which would depend on the host umask.
Avoid this and be deterministic by setting the file modes consistently. Core
code copies the files in so we're responsible for the permissions.
Unfortunately to force this change to apply we need to invalidate both
the package tasks and the hash equivalance mappings since file mode
'corruption' already made it into the output hashes (both input options
were mapped to the output hashes).
(From OE-Core rev: 1f807da38b9d9aebdd86b3b5839305e03d9930e1)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 1f958bcd6c9cd12ec76d80586cba15f4d6ed17a7)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The output currently shows the remapped product and version fields,
which may not be the actual recipe name/version. As this report is about
recipes, use the real values.
(From OE-Core rev: 62e07072bbeeebfead34bbdb04e75cff1c4ef1e1)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 18827d7f40db4a4f92680bd59ca655cca373ad65)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When copying license files to the image rootfs, i.e to
/usr/share/common-licenses, a canonical name of a license should be
used, otherwise duplicated files end up in common-licenses directory.
For example, GPL-2.0 license according to conf/license.conf can be
referenced in recipes as GPL-2, GPLv2, and GPLv2.0. If a license name is
used directly, we end up with three files in the rootfs with the same
content. If a canonical name used instead, then each license gets copied
only once.
(From OE-Core rev: 0fda54af52dfb57598ea9409113d33dacb786dc1)
Signed-off-by: Vyacheslav Yurkov <Vyacheslav.Yurkov@bruker.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 670fe71dd18ea675f35581db4a61fda137f8bf00)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As per lib/oe/rootfs.py and lib/oe/package_manager/???/__init__.py
the PACKAGE_FEED baseurl is defined as the joined paths of:
URIS/BASE_PATHS/ARCHS
Therefore, the do_rootfs task should depend furthermore on
PACKAGE_FEED_{BASE_PATHS,ARCHS} to properly retrigger a build if
the value changes.
(From OE-Core rev: 14165724d41a5d00384a9db60b49b37ac4f3b40f)
Signed-off-by: Loic Domaigne (ljd) <tech@domaigne.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit e5329464f5ebad909c4c9bd27a718bbd8f4cc221)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With 'ld-is-gold' and linux kernel 5.4 or later, menuconfig
task for kernel recipes will fail with:
$ bitbake -c menuconfig virtual/kernel
...
scripts/kconfig/mconf Kconfig
scripts/Kconfig.include:43: gold linker 'x86_64-poky-linux-ld' not supported
/OE/build/tmp/work-shared/qemux86-64/kernel-source/scripts/kconfig/Makefile:29:
recipe for target 'menuconfig' failed
make[2]: *** [menuconfig] Error 1
/OE/build/tmp/work-shared/qemux86-64/kernel-source/Makefile:606:
recipe for target 'menuconfig' failed
make[1]: *** [menuconfig] Error 2
/OE/build/tmp/work-shared/qemux86-64/kernel-source/Makefile:185:
recipe for target '__sub-make' failed
make: *** [__sub-make] Error 2
Command failed.
This is because that the KERNEL_LD variable already set in
kernel-arch.bbclass isn't used by do_menuconfig function of
cml1.bbclass.
To fix this issue specify LD variable while calling the kernel
menuconfig command through KERNEL_KCONFIG_COMMAND.
(From OE-Core rev: 263e0c7a301fc11d3cf4ced4ffb911ebf6cb2f14)
Signed-off-by: Wonmin Jung <wonmin82@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 1faf66ce0b1f8f5165277161e07e25e672370c3f)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There were two copies of this patch floating around, and the merged
variant has the copy in the wrong place.
module.lds is only created during modules_prepare, and that target is
not invoked during our main build of the kernel. We aren't about to
change the kernel build (there's no need), so we move the copy into
the compile_kernelmodules task. After that runs, we have module.lds
availble to copy.
This has been tested against clean kernel + out of tree module
builds, and the dependencies are correct that the file is copied
before the out of tree module build starts.
(From OE-Core rev: d9e327063f63193186822d958706081d64ec8139)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 7d94f9209ebaaf59ea001239a889dd7f928a0e7c)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The upstream commit 596b0474d3d [kbuild: preprocess module linker
script], adds a dependency on module.lds for external module
building.
Since module.lds is generated as part of 'modules_prepare', we
must make it available with the other kernel artifacts in the
kernel shared workdir, otherwise out of tree builds fail.
This fixes errors like:
| make[4]: *** No rule to make target 'scripts/module.lds', needed by
'build/tmp/work/qemuarm64-poky-linux/cryptodev-module/1.11-r0/git/cryptodev.ko'.
Stop.
| make[4]: *** Waiting for unfinished jobs....
We also ensure that kernel-devsrc has a copy to support on
target module builds that are often prepared with 'make scripts
prepare'. Those targets won't regenerate it, so the build fails.
If 'make modules_prepare' is used, the file will be regenerated
and overwrite our copy (as expected).
(From OE-Core rev: 27856184dee4b68254cb302b2294c115a46fcf16)
Signed-off-by: Pan, Kris <kris.pan@intel.com>
Signed-off-by: Lili Li <lili.li@intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 0fc66a0b64953aae38d0124b57615fffaec8de52)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When a run is ended by overall timeout, print the already executed
testcases, to provide some hints which testcase might made the
test suite reach global timeout.
Nonetheless make the testrun exit with an error
(From OE-Core rev: 54a7e5feee2bec78f8d526b69076fd0e8e50e228)
Signed-off-by: Konrad Weihmann <kweihmann@outlook.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 2bcc643195a3b3c66d698fac8b7af037c08545ac)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently the modconf fragments representing the configuration for
kernel modules are written out to appropriate .conf files and added to
the FILES variable. However they are not identified as 'configuration
files' and installing a new version of a kernel module results in a
conflict and a failed installed because the respective .conf file is
already in place from a previous install.
Add the generated .conf files to the CONFFILES variable denoting their
true nature.
(From OE-Core rev: eb42ef100c52b243eee55b950f3dc7d4010ea1f2)
Signed-off-by: Gratian Crisan <gratian.crisan@ni.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 1a70a92d1f1006be115429a4262259c9084f484d)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This reverts commit d123606c4bef85c2436b40f51e47b602b7600c0b.
This change contains races as it will start poking into do_package task
directories from do_populate_sysroot. If we want to do this for native
recipes, we need to add guards around the package code and only make
this happen for native in populate_sysroot, not target in
populate_sysroot too. Backtrace from an example problem below:
ERROR: openssl-1.1.1g-r0 do_populate_sysroot: Error executing a python function in exec_python_func() autogenerated:
The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: <module>
0001:
*** 0002:buildhistory_emit_pkghistory(d)
0003:
File: '/home/ross/Yocto/poky/meta/classes/buildhistory.bbclass', lineno: 319, function: buildhistory_emit_pkghistory
0315:
0316: write_pkghistory(pkginfo, d)
0317:
0318: # Create files-in-<package-name>.txt files containing a list of files of each recipe's package
*** 0319: bb.build.exec_func("buildhistory_list_pkg_files", d)
0320:}
0321:
0322:python buildhistory_emit_outputsigs() {
0323: if not "task" in (d.getVar('BUILDHISTORY_FEATURES') or "").split():
File: '/home/ross/Yocto/poky/bitbake/lib/bb/build.py', lineno: 256, function: exec_func
0252: with bb.utils.fileslocked(lockfiles):
0253: if ispython:
0254: exec_func_python(func, d, runfile, cwd=adir)
0255: else:
*** 0256: exec_func_shell(func, d, runfile, cwd=adir)
0257:
0258: try:
0259: curcwd = os.getcwd()
0260: except:
File: '/home/ross/Yocto/poky/bitbake/lib/bb/build.py', lineno: 503, function: exec_func_shell
0499: with open(fifopath, 'r+b', buffering=0) as fifo:
0500: try:
0501: bb.debug(2, "Executing shell function %s" % func)
0502: with open(os.devnull, 'r+') as stdin, logfile:
*** 0503: bb.process.run(cmd, shell=False, stdin=stdin, log=logfile, extrafiles=[(fifo,readfifo)])
0504: except bb.process.ExecutionError as exe:
0505: # Find the backtrace that the shell trap generated
0506: backtrace_marker_regex = re.compile(r"WARNING: Backtrace \(BB generated script\)")
0507: stdout_lines = (exe.stdout or "").split("\n")
File: '/home/ross/Yocto/poky/bitbake/lib/bb/process.py', lineno: 184, function: run
0180: if not stderr is None:
0181: stderr = stderr.decode("utf-8")
0182:
0183: if pipe.returncode != 0:
*** 0184: raise ExecutionError(cmd, pipe.returncode, stdout, stderr)
0185: return stdout, stderr
Exception: bb.process.ExecutionError: Execution of '/yocto/ross/build/tmp/work/neoversen1-poky-linux/openssl/1.1.1g-r0/temp/run.buildhistory_list_pkg_files.4158804' failed with exit code 2:
/yocto/ross/build/tmp/work/neoversen1-poky-linux/openssl/1.1.1g-r0/temp/run.buildhistory_list_pkg_files.4158804: 183: cd: can't cd to /yocto/ross/build/tmp/work/neoversen1-poky-linux/openssl/1.1.1g-r0/packages-split/openssl-engines
(From OE-Core rev: 59aac6e134289d657d80bfb1d6f25b388d539818)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we want to also collect SRC_URI for native recipes we need to ensure
that the code that writes out all of the recipe info is called - there
isn't a do_packagedata for native recipes so we need to piggyback on
do_populate_sysroot instead.
(From OE-Core rev: d123606c4bef85c2436b40f51e47b602b7600c0b)
Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It can be useful to record SRC_URI into buildhistory for the purposes of
tracking exactly which sources got built (we already have SRCREV) as
well as getting an indication when changes to the SRC_URI relate to
changes in the output.
(From OE-Core rev: 70714795aafc98a6df1df7f944867093eb8cafc7)
Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* seems to be broken for many years, does someone still use sh3/sh4?
scripts/tune/log.fake-sh3.sh3eb:
Parsing recipes...
ERROR: /OE/build/oe-core/openembedded-core/meta/recipes-devtools/vala/vala_0.48.9.bb: Unable to determine endianness for architecture 'sh3eb'
ERROR: /OE/build/oe-core/openembedded-core/meta/recipes-devtools/vala/vala_0.48.9.bb: Please add your architecture to siteinfo.bbclass
scripts/tune/log.fake-sh4.sh4aeb
scripts/tune/log.fake-sh4.sh4eb:
Parsing recipes...
ERROR: /OE/build/oe-core/openembedded-core/meta/recipes-support/vim/vim-tiny_8.2.bb: Unable to determine endianness for architecture 'sh4eb'
ERROR: /OE/build/oe-core/openembedded-core/meta/recipes-support/vim/vim-tiny_8.2.bb: Please add your architecture to siteinfo.bbclass
(From OE-Core rev: 1f26495884b8f567aecadc5936651846dfeed3f5)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As waf is always out-of-tree, we can delete ${B} before every build.
(From OE-Core rev: 92bf649f16926f8e3b2f7b8aab9cd7f31bbc5082)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Waf typically uses `python` as the intepretter but inside a task this
does not exist. Typically this is solved by patching waf (see the
glmark2 recipe) but not all versionf of Waf support Python 3 so we can't
assume a specific interpretter.
Instead, create a new variable WAF_PYTHON for the correct interpretter,
and default this to `python3`. If the user has a recipe that needs
Python 2 then this can be changed in the recipe.
(From OE-Core rev: 802e80d35e6374b9b80f89068d00b84fe2d04ca1)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This helps in overriding CACHED_CONFIGUREVARS with wrappers to run
configure under e.g. for static analysers like scan-build from clang,
while it should not change the functionality in normal case.
Since CONFIG_SHELL was introduced, it silently broke this use case and
failed running static analyser on autotool based recipes
(From OE-Core rev: 14c3454db0108ff78b73eecfae179a69241d9f5c)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The product name when compiling meta-toolchain is:
poky-glibc-x86_64-${IMAGE_BASENAME}-cortexa57-qemuarm64-toolchain-3.1+snapshot.host.manifest
poky-glibc-x86_64-${IMAGE_BASENAME}-cortexa57-qemuarm64-toolchain-3.1+snapshot.target.manifest
poky-glibc-x86_64-${IMAGE_BASENAME}-cortexa57-qemuarm64-toolchain-3.1+snapshot.testdata.json
poky-glibc-x86_64--cortexa57-qemuarm64-toolchain-3.1+snapshot.sh
inherit image-artifact-names to solve this problem.
(From OE-Core rev: 1a566f1685258bdd6da50c8d2183ff21bed41bb3)
Signed-off-by: Zang Ruochen <zangrc.fnst@cn.fujitsu.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Allow different recipes to build things from the one external source tree in
parallel, but only if the build is happening outside the source tree.
(From OE-Core rev: 8c6b12683c3160a5b7c62d1fe00a9f848e062df0)
Signed-off-by: Douglas Royds <douglas.royds@taitradio.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Under some circumstances it is not desirable to create a combined locale
archive (/usr/lib/locale/locale-archive).
The new variable IMAGE_LOCALES_ARCHIVE defaults to '1', so the default
behaviour is not changed.
(From OE-Core rev: 8d78b819c2ec33fce3a34254fa90864ee5fa7617)
Signed-off-by: Michael Thalmeier <michael.thalmeier@hale.at>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adds variables that can be used to allow a recipe to pass extra
arguments to `waf build` and `waf install`. In most cases, you want to
pass the same arguments to `build` and `install` (since install is a
superset of `build`), so by default setting EXTRA_OEWAF_BUILD also
affects `waf install`, but this can be overridded.
(From OE-Core rev: 493e17a2f5cbbbe3b1e435dadb281b007bca2cbf)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* to make sure we won't hit such corner cases in future add a warning
to prevent trailing slashes and duplicated slashes even when they
in most cases don't cause harm
* only a few cases were found in layers included in my world builds:
oe-core: 1
meta-oe: 7
meta-python2: 1
meta-qt5: 1
meta-aws: 1
will send patches for these once this warning is approved for oe-core
(From OE-Core rev: 8a4c473c07cba159cf88ed775b9f073c6adf31d4)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cannot use os.path.samefile, because S/B might not exist at this time yet
* there is issue with PSEUDO_IGNORE_PATHS when some recipe sets e.g.
S = "${WORKDIR}/"
whole WORKDIR gets added to PSEUDO_IGNORE_PATHS and then the build
can fail with various strange errors, in my case do_package was
failing when do_package calls:
fix_perms(.../1.0-r0/package/etc, 755, 0, 0, /etc)
and fails with "[Errno 1] Operation not permitted:"
(From OE-Core rev: 50b11a61ab29acb8ec990668353e0b7305114628)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
After the recent path ignore changes, there are invalid entries in exiting
pseudo databases which will trip up users with the new abort() (proving
how common the pseudo potential corrpution is!). Inform them a clean TMPDIR
is needed.
(From OE-Core rev: 016ee90e210c9b15b80e8370d83f41a14867a413)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
