The Clutter class's ability to switch between tarballs and git isn't really
useful, so remove it. If it comes back, it should use the devupstream class.
(From OE-Core rev: 6150ec737bad895b9fb62f711449a259887ebd1b)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For non-python developers it's difficult to identify where start
searching in case of errors. Fixing and marking the string to
grep for might help finding some root causes of issues slightly
quicker.
(From OE-Core rev: 44fff749ee7bfe47e88286aec1e8a22e63079ca7)
Signed-off-by: Jens Rehsack <sno@netbsd.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Log both the source of the source_date_epoch and the resulting
source_date_epoch in all cases.
Also, now that we are determining the source_date_epoch successfully for both
yocto and non-yocto kernels, remove the inherits_class('kernel') exception.
We will log a failure to find a source_date_epoch for kernels as well.
(From OE-Core rev: 48fe0e83435f9fb53b1e5b37d5d9f1c2caccd22d)
Signed-off-by: Douglas Royds <douglas.royds@taitradio.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Change the search regime for find_git_folder():
1. WORKDIR/git: This is the default git fetcher unpack path
2. ${S}
3. Go looking for .git/ under the WORKDIR as a last resort.
linux-yocto:
We had an existing (silent) defect. The linux-yocto recipes all specify
two git SRC_URIs, one for the kernel source itself, the other for the
kmeta data (config fragments and friends). find_git_folder() was finding
the git checkout for the kmeta data, but due to a typo in the git log -1
--pretty=%ct line, we were (silently) reading the source_date_epoch from
the ${S} directory = STAGING_KERNEL_DIR, which is empty. If your
build/ happened to be inside a git checkout, git would walk up the
directory tree, and silently read the commit timestamp from this other
git checkout. The correct path to read the git commit timestamp from is
the "gitpath", being that found by find_git_folder(), though this
function was incorrectly finding the kmeta data checkout, not the kernel
source tree.
Non-kernel git recipes:
The default git fetcher clones and checks out the sources at
WORKDIR/git/ regardless of the setting of S (unless subpath or
destsuffix is set). find_git_folder() now looks for the
WORKDIR/git/.git/ directory first.
Non-yocto linux kernels:
Kernel recipes that don't inherit kernel-yocto should always set
S = ${WORKDIR}/git, so that when base_do_unpack_append() in
kernel.bbclass moves the checkout down to the STAGING_KERNEL_DIR and
symlinks it as WORKDIR/git, the build can still work by following the
symlink. We were previously failing to follow the symlink in the
os.walk(), but we now look first for WORKDIR/git/.git/, and find it due
to the symlink.
If none of the above mechanisms work for finding the git checkout,
perhaps there was a subpath or destsuffix specified in the SRC_URI.
We go looking for the git checkout under the WORKDIR as a last resort.
(From OE-Core rev: b0ddb141d36853447f85ecaac07dbc9c5779627f)
Signed-off-by: Douglas Royds <douglas.royds@taitradio.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
this makes it possible to use this for musl where we are trying to
create a glibc compat package
Add missing aarch64 loader definition for glibc function
(From OE-Core rev: 0a02ea79ec522582b46138a027eb166819e5647d)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
BPF Linux ELF objects are generated with kernel-selftests with
>= 4.18 kernel and when clang is enabled which packages BPF objects
into packages, therefore recongnise this as a valid ELF target
Add a selftest for BPF
Do not flag BPF objects in target, since they pretty much will be ok for
most of kernels architectures we care do support BPF
(From OE-Core rev: 3667a8ec016bae3f8026ef7b4c895546804f6368)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The rprovides of target-sdk-provides-dummy don't be updated with
multilib, so it fails package_qa_multilib check. Because
target-sdk-provides-dummy doesn't install any file to sysroot, it is
safe to skip package_qa_multilib check for target-sdk-provides-dummy.
Remove ${MLPREFIX}target-sdk-provides-dummy from TOOLCHAIN_TARGET_TASK
at same time in populate_sdk_base.bbclass.
(From OE-Core rev: 3197c086269a4b21fb807a9c552b56f23c5b86dc)
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Update SSTATE_DUPWHITELIST in sstate.bbclass.
* remove ${DEPLOY_DIR_RPM}/noarch/ which is not overwritten any more
* add directories for package target-sdk-provides-dummy
(From OE-Core rev: 6d3ca476dbc2059f4b7fa3dfd73de6bbfed49198)
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some allarch packages rdepends non-allarch packages. when multilib is
used, it doesn't expand the dependency chain correctly, e.g.
core-image-sato -> ca-certificates(allarch) -> openssl
we expect dependency chain for lib32-core-image-sato:
lib32-core-image-sato -> ca-certificates(allarch) -> lib32-openssl
it should install lib32-openssl for ca-certificates but openssl is still
wrongly required.
Only enable allarch when multilib is not used to fix the issue.
(From OE-Core rev: a23c482cab4f874f4a6a6889716123569eb5ece9)
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
kernel-fitimage.bbclass replaces an occurance of "fitImage" in
KERNEL_IMAGETYPE_FOR_MAKE by an image type that is buildable for the
architecture (such as zImage). The kernel-fitimage.bbclass packs that
image as sub-image in a flattened image tree image (fitImage) and
deploys this fitImage along with the image tree source file (.its).
kernel-fitimage.bbclass does not alter KERNEL_IMAGETYPES, which thus
also contains "fitImage", which kernel.bbclass will also deploy
redundantly with different naming.
The result is a dual deployment with slightly different naming,
each with a set of symlinks.
The solution chosen is to have fitImage deployment be handled by
kernel-fitimage.bbclass, and have kernel.bbclass ignore fitImage
types during deployment.
(From OE-Core rev: 65cded55fa96b1ba72149a31689c081ac27af7f7)
Signed-off-by: Leon Woestenberg <leon@sidebranch.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
By default the devicetree class adds padding to the generated .dtb
files, which can be needed by the bootloader. However it also pads
.dtbo files, which is not useful.
Don't apply padding to the overlay devicetrees.
To achieve this:
* move "-p ${DT_PADDING_SIZE}" to a new variable, DTB_BFLAGS (B for
"base")
* add "-p 0" to DTC_OFLAGS to disable padding for overlays
Cc: Nathan Rossi <nathan@nathanrossi.com>
(From OE-Core rev: 678fe8c66b19f141f6869859cf365aec037e89d9)
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
QEMU_USE_KVM can either be a boolean or a whitespace separated list
of kvm supported machines.
For the 'intel-corei7-64' machine, defined in meta-intel, kvm could not be
used as the 'x86' substring is not part of its machine name.
By changing the order of this 'or' statement and setting
the 'QEMU_USE_KVM' variable to 'intel-corei7-64', it is possible to run the
'testimage' task with kvm support successfully.
(From OE-Core rev: a22789253aa653dc50fb159b40910248c2f98dd4)
Signed-off-by: Emmanuel Roullit <emmanuel.roullit@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The code currently only prints a single depchain due to overwriting data
instead of appending. Fix this.
(From OE-Core rev: 48af19cdfa92aa9d336da50afe4ed3dde92daecc)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Occasionally we see warnings like:
WARNING: core-image-sato-1.0-r0 do_populate_sdk: Manifest /home/pokybuild/yocto-worker/nightly-qa-extras/build/build/tmp/sstate-control/manifest-allarch-nativesdk-linux-libc-headers.populate_sysroot not found in i686_linux allarch (variant '')?
which occur when do_populate_sdk is run in an otherwise empty TMPDIR.
It occurs because do_stash_locale is not recognised as a setscene task
and is removed from the taskgraph meaning the dependency chains fed
through setscene_depvalid don't match what was actually setscene'd.
That task is recipe specific and not in the global SSTATETASKS so we
hardcode the value for now to stop the build warnings. This is going to
need to be revisited for a more generic solution.
(From OE-Core rev: d8d5b624058920113f9d297f7f711d6d3249ae39)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Running 'gcc --version' for every image recipe is slow and increases parsing
time/resource usage for no good reason. Only compute the value in when we're
really running the task/function.
(From OE-Core rev: bf49316bb9913b7c89de64d6a194be31aa66e16b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
All other functions in this class use TAB for indentation while
the do_compile function uses '4 spaces'. Adjust it for consistency.
(From OE-Core rev: c2829b74892633c554a5f8262d4cafbe0fa6c3a7)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It's possible that the perms conf file specified by FILESYSTEM_PERMS_TABLES
does not exist. Currently, this situation is silently ignored, which
is likely to lead to further do_rootfs failures.
So fix to output a warning, telling user that the specified file
in FILESYSTEM_PERMS_TABLES cannot be found.
(From OE-Core rev: e14b9f2a667889092251053933dc2f3c51f01ef0)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It was otherwise being deferred until boot time
(From OE-Core rev: f8a4ce9b2d59a380d35305a2cd7f73b279bbd8f5)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Extract a general version of RPATH fix for libxml-parser-perl_2.44.bb
from
292471701 libxml-parser-perl: fix "...contains bad RPATH"
into cpan.bbclass to catch most errors reported by Khem Raj via
http://errors.yoctoproject.org/Errors/Build/66538/
Genrally, Perl 5 toolchain deals with cross-compile sysroots
as if a dependency is installed at an exostic place on a server.
This issue needs to be addressed wider into the community.
(From OE-Core rev: a5439ff9627d309f6980947f5ee573d85e672228)
Signed-off-by: Jens Rehsack <sno@netbsd.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
During the re-working of kernel fragments and status output cleanup the
visibility for BSP level errors was dropped/removed.
The audit phase can detect errors, redefinition and invalid
configuration fragments. We control the visibility of these reports via
the existing KCONF_BSP_AUDIT_LEVEL variable.
By default, errors and invalid configuration values will be displayed as
a warning. If redefinition values are to be shown the audit level must
be raised above the deafult value of '2'. We inhibit these by default,
since there are many valid reasons why a BSP will change a default /
base config .. and showing them offers no value to the BSP user.
(From OE-Core rev: 4933b686b0f75d6841630917a2d90832df41cac7)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Replace usage of os.utils.getstatusoutput() with direct subprocess
calls. Pass a modified environment and working directory where necessary
to bypass the need to execute in a shell.
(From OE-Core rev: 21de5cc43cfedc703e5bc0515507a6dae36afb74)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Define variable SSTATE_PRUNE_OBSOLETEWORKDIR with '?=' in sstate.bbclass,
then it could be overwritten by user configuration.
(From OE-Core rev: 22af59c9bfec31b31027ebd2a4da162f481aa6b5)
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The devshell.bbclass set var-SHELL to var-DEVSHELL, and terminal.bbclass
initial var-SHELL with `bash'. Keep sync with it, use var-SHELL rather
than hardcoded `/bin/sh' as the shebang of wrapper script.
On Ubuntu host, default shell is dash (/bin/sh -> dash), even though
we assign var-SHELL with `/bin/bash', the wrapper script is still dashism.
(From OE-Core rev: 27e2ede65f1193e49f9483b08a55495d88740a65)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
While multiple hardlinks of binary located in different dirs,
there are also multiple hardlinks of separated debug info file
with the same binary name in same debug dirs. But in each dir,
only one debug file with original name works. Because all of
binary hardlinks have one `.gnu_debuglink' which is added in
`splitdebuginfo'. It caused gdb could not find debugging
symbols.
[Before the patch]
$ find .
./usr/bin/foo
./usr/bin/foo-hd1
./usr/bin/.debug
./usr/bin/.debug/foo
./usr/bin/.debug/foo-hd1
./usr/libexec/foo-hd2
./usr/libexec/.debug
./usr/libexec/.debug/foo-hd2
$ readelf --debug-dump usr/libexec/foo-hd2
Contents of the .gnu_debuglink section:
Separate debug info file: foo
$ gdb usr/libexec/foo-hd2
Reading symbols from usr/libexec/foo-hd2...(no debugging symbols found)...done.
[Before the patch]
[Apply the patch]
$ find .
./usr/bin/foo
./usr/bin/foo-hd1
./usr/bin/.debug
./usr/bin/.debug/foo
./usr/libexec/foo-hd2
./usr/libexec/.debug
./usr/libexec/.debug/foo
$ gdb usr/libexec/foo-hd2
Reading symbols from usr/libexec/foo-hd2...Reading symbols from usr/libexec/.debug/foo...done.
[Apply the patch]
(From OE-Core rev: d4eaf42f7708f8d3a31a04d958bd7420dd7dd6b9)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The following statement was accidently removed. Add it back.
values['ml'] = ['']
This patch fixes the following error.
Exception: KeyError: 'ml'
(From OE-Core rev: 0791c4d39edbedaa493a9fc6aa6e7415f14980bb)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Replace usage of oe.utils.getstatusoutput() with direct subprocess calls.
(From OE-Core rev: f1a1b31add242380490023c2ee7eec1b4fbcd85b)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The previous patch has duplicate split calls and one needs to be removed
to avoid failures
(From OE-Core rev: 02c8d048cbab38a48f698504d0f5e912d3d24a36)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
get_multilib_datastore() should be able to handle the original datastore
correctly now so rely upon this rather than custom coding.
(From OE-Core rev: 2ae85af480066e252fca01f3005ecac2ff37a8d4)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We could do with one decent general purpose python function to query the
path to the dynamic loader. Convert the shell code into python.
Also correct baremetal to return "None", not musl loaders.
(From OE-Core rev: 73fab4ede12d8ae31be72b5cb4ab29d7ef7dae17)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This does the same thing, but is more efficient in case st_nlinks
is (already) 1.
Depends on bitbake commit 7ae93cf40ab91965147055100432961436bce46c .
(From OE-Core rev: 38180b5c1044be13458fb927ad1babae61e4c51f)
Signed-off-by: Rasmus Villemoes <rv@rasmusvillemoes.dk>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The modern the time, the improvements in ExtUtils::MakeMaker.
Nowadays, .packlist and perllocal.pod aren't touched anymore when appropriate
flags set during configure stage. Controlling the flags globally avoids
dual-life recipes need share patching.
Further: remove prepending ${PERL_ARCHLIB} in PERL5LIB - it's wrong (search
order is site_lib, vendor_lib, core) - and ${PERL_ARCHLIB} contains core
libpath only ...
(From OE-Core rev: 2e61533e7c1b1cfd49dc771e907207f11a15c44f)
Signed-off-by: Jens Rehsack <sno@netbsd.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* to avoid confusion with "type" command in shell
(From OE-Core rev: 8d454ea754c96561257b1cc011fa638ceaa771db)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* some people don't like the ${MACHINE} in the symlink, because now the DEPLOYDIR already
contains ${MACHINE} subdirectory, add KERNEL_ARTIFACT_LINK_NAME variable to change it
in one place without the need to list all variables for various artifacts
(From OE-Core rev: 416b58d84f1124212f114198d2fcb1f3a9bbd223)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* for consistency with other artifacts variables, include only the version string, not the actual name or extension
* changing .tgz to something else in the MODULE_TARBALL_NAME variable only wouldn't make much sense
because then kernel.bbclass still calls "tar -cvzf" to create it
(From OE-Core rev: 43bd7f39157da49f7fb0c2d6d9751059471c8d53)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* for consistency with IMAGE_NAME and IMAGE_LINK_NAME
and to avoid confusion with IMAGE_BASENAME (which is the
actual name of the artifact, e.g. PN while KERNEL_IMAGE_BASE_NAME
was only the version suffix)
(From OE-Core rev: f952c8e08b4798aa0f8bf764cfd70bda0eae9b8b)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* use the same naming scheme for fitImage files like all other deployed artifacts
* remove unnecessary cd to DEPLOYDIR
* remove unnecessary cd to B
(From OE-Core rev: fd69f8b2d7dd950cee9e820ef91ea90521c95ace)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* this makes it easier to use different version string than DATETIME, e.g. set from jenkins job
while keeping the suffix consistent across all artifacts stored in DEPLOYDIR
(From OE-Core rev: 1245935b9bf32e0321d8ff12492983ba8506190a)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The testdata.json is being written to DEPLOY_DIR_IMAGE directly,
thus bypassing sstate, which results in an ever growing list
of files.
Write them to IMGDEPLOYDIR instead, so as to benefit from the
automatic management via sstate.
(From OE-Core rev: 1f7399a5e5d12b7ca3faf399a70c1613d522c28d)
Signed-off-by: André Draszik <andre.draszik@jci.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
- Import from meta-oe layer
- This is useful for many packages where CR-LF
needs to be adjusted, many recipes depend on it
e.g. meta-multimedia libebml and so on.
(From OE-Core rev: bd4a02d8d3cfb476a2da0f4616605c92604266c0)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
