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>
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>
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>
This is inspired from
https://github.com/python/cpython/blob/master/configure.ac
Helps cross compiling python C modules in some cases where they do
not respect normal CFLAGS
Errors like using gcc to link when compiler is clang is fixed
(From OE-Core rev: 0ab1b35172a41021f5e27c5d17d1e131ce5befd7)
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>
This class sets POSTINST_INTERCEPTS and POSTINST_INTERCEPTS_CHECKSUMS,
to allow us to pull intercepts from BBPATH. This is kept as a separate
class, as it's needed by both image construction and sdk construction,
the latter to support meta-toolchain & similar recipes.
(From OE-Core rev: 7a2044df4ae8d80cf25a6bfd9b71978ffefbfa33)
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Using re.compile() is around six times faster than recompiling the regexp
each time so maintain a cache.
(From OE-Core rev: 41eb382737706e245f2b7104e313c8dfaa370945)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use the newly introduced SSTATE_EXCLUDEDEPS_SYSROOT for specifying
the base-passwd|shadow-sysroot recipes to be excluded from a recipe sysroot.
(From OE-Core rev: 68e502e9063a88532fe0154f152ba408f0091900)
Signed-off-by: André Draszik <andre.draszik@jci.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use the newly introduced SSTATE_EXCLUDEDEPS_SYSROOT for specifying
the *-initial recipes to be excluded from a recipe sysroot.
(From OE-Core rev: 6706bad52f9311ea79c534ee90014c3216992999)
Signed-off-by: André Draszik <andre.draszik@jci.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, a dependency on any -native recipe will pull in
all dependencies of that -native recipe in the recipe
sysroot. This behaviour might not always be wanted, e.g.
when that -native recipe depends on build-tools that are
not relevant for the current recipe.
This change adds a SSTATE_EXCLUDEDEPS_SYSROOT variable,
which will be evaluated for such recursive dependencies to
be excluded. The idea is similar to
http://lists.openembedded.org/pipermail/openembedded-core/2018-January/146324.html
except that the list is not hard-coded anymore.
SSTATE_EXCLUDEDEPS_SYSROOT is evaluated as two regular
expressions of recipe and dependency to ignore, e.g. in
the above flex-native / bison-native use-case, one would
specify
SSTATE_EXCLUDEDEPS_SYSROOT = ".*->(flex|bison)-native"
in layer.conf.
The existing special handling of "-initial" as well as
"base-passwd" and "shadow-sysroot" could also be
streamlined:
SSTATE_EXCLUDEDEPS_SYSROOT += "\
.*->.*-initial.* \
.*(base-passwd|shadow-sysroot)->.* \
"
Another anticipated user is meta-java, where certain newer
JDKs can only be bootstrapped (built) using older JDKs,
but it doesn't make much sense to copy all those older
JDKs and their own build tools (ant, etc.) into the
sysroot of recipes wanting to be built using the newer JDK
(only), e.g.:
SSTATE_EXCLUDEDEPS_SYSROOT += "\
openjdk-8-native->(ant-native|attr-native|coreutils-native|icedtea7-native|libxslt-native|make-native|openssl-native|zip-native|unzip-native) \
"
(From OE-Core rev: 92c5131a2feae2036c71a36c18bb9175bb2856dc)
Signed-off-by: André Draszik <andre.draszik@jci.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Disable downloading of the vulnerability DB in do_check_cves() task.
When invoked in this task, cve-check-tool attempts re-download of the CVE DB
if the latter is older than certain threshold. While reasonable for a
stand-alone CVE checker, this behavior can cause errors in parallel builds
if the build time is longer than this threshold:
* Other tasks might be using the DB.
* Several packages can start the download of the same file at the same time.
This check is not really needed, as the DB has been downloaded by
cve_check_tool:do_populate_cve_db() which is a prerequisite of any do_build().
The DB will be at most (threshold + build_time) old.
(From OE-Core rev: 125789b6ee6d47ab84192230f63971c4e22418ba)
Signed-off-by: Konstantin Shemyak <konstantin.shemyak@ge.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
To handle the case where ${COREBASE} isn't the git directory, avoid
erroring out when the git command fails. If we don't have a timestamp
after this, fall back to the timestamp from conf/bitbake.conf.
(From OE-Core rev: 97b439469a45a089431ca9c31893288c855045f4)
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
nativesdk-gpgme fails package_qa when setting PACKAGE_DEBUG_SPLIT_STYLE
= "debug-with-srcpkg".
ERROR: nativesdk-gpgme-1.10.0-r0 do_package_qa: QA Issue: non debug package contains .debug directory: nativesdk-python3-gpg path /work/x86_64-nativesdk-oesdk-linux/nativesdk-gpgme/1.10.0-r0/packages-split/nativesdk-python3-gpg/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/python3.5/site-packages/gpg/.debug/_gpgme.cpython-35m-x86_64-linux-gnu.so [debug-files]
This turns out to be because the automatic moving of the -dbg package to
the beginning of the package list is disabled in that case, so the
python3-gpg packages that the recipe prepends to PACKAGES ends up before
the -dbg package.
It's not clear why the "and not split_source_package" was added when
debug-with-srcpkg was introduced. Presumably the intention was to
prevent the -dbg package to end up before the -src package, which we of
course need to. But at the same time, we still need -dbg packages to end
up before all other packages.
Using list.insert(0, ...) also means that if there happens to more than
one -dbg package, their relative ordering gets inverted in the new list.
This tries to fix these issues by sorting the packages by (priority,
original position), where priority is 10 for -src, 30 for -dbg and 50
for everything else. That guarantees that packages of the same "type"
preserve their relative ordering, while also ensuring that -dbg always
preceed other packages. This scheme is also quite extensible, and,
should the need arise, one could even expose the priorities as a knob
the recipe author could use to ensure specific orderings of packages
instead of the somewhat fragile and coarse-grained method of "prepend or
append, and ensure you do that in a proper order".
Probably the autodebug condition needs to stay, but I think the
split_source_package condition in the preceding elif should be removed,
so that that logic applies to all packages called -src, not just the one
we might have created a few lines above.
(From OE-Core rev: 805edbc7dc9ceae00d991f9b4e185bbbe1d3ba45)
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Files when restored from sstate were missing their sparseness. Fix up various
functions to preserve this and make things more deterministic.
(From OE-Core rev: 055402e5504f041c346571e243c7cf0894955cad)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently if you build qemux86 and then generic86, the latter will
remove all of the former from deploy and workdir. This is because
qemux86 is i586, genericx86 is i686 and the architctures are compatible
therefore the sstate 'cleaup' code kicks in.
There was a valid reason for this to ensure i586 packages didn't get into
an i686 rootfs for example. With the rootfs creation being filtered now, this
is no longer necessary.
Instead, save out a list of stamps which a give machine has ever seen in
a given build and only clean up these things if they're no longer
"reachable".
In particular this means the autobuilder should no longer spend a load of time
deleting files when switching MACHINE, improving build times.
(From OE-Core rev: 5634f2fb1740732056d2c1a22717184ef94405bf)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Refactor the locale archive function from the SDK to also make it work during
general image creation. This reduces the size of the locales from 900MB to 220MB
in core-image-lsb-sdk.
The exception handling around subprocess was dropped as the standard subprocess
exception printing is better handled than the catchall exception.
(From OE-Core rev: 8ffd93bdb09b0a4a84b27dafcd684c6abba392ed)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
We want to preserve sparse files when building the system, add the option
to tar to ensure we do this when copying files.
(From OE-Core rev: d86da5ae386a8129a966a53901de160823f4d250)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If multilib scripts handle more than one file per package, the variable
ALTERNATIVE_${PN} will be overwritten and there will be only one symbol
link file. Append to the variable to avoid this.
(From OE-Core rev: f474a7ed02acaffe5d0fcc67e06dde17fc8e4d0e)
Signed-off-by: Zhixiong Chi <zhixiong.chi@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The devtool-source class moves all local files specified in SRC_URI to
an oe-local-files directory. When using devtool and a recipe space kernel-meta,
devtool modify throws an error because the paths the kernel-yocto class
is looking for feature directories in, don't include the oe-local-files
directory which devtool is using.
This patch checks for feature directories in oe-local-files,
and if present, adds that path to include directives.
[YOCTO #12855]
(From OE-Core rev: 4eceae7e3e6dab935e2cf49b75148139192fc6e7)
Signed-off-by: Jaewon Lee <jaewon.lee@xilinx.com>
Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandr@xilinx.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When using a recipe space kernel-meta, scc files are added through
SRC_URI, but they may include corresponding kernel fragments or patches
that are not necessarily in SRC_URI.
For bitbake, this is not a problem because the kernel-yocto class adds
the path where the .scc file was found to includes which consequentially
makes the .cfg, .patch file available to the kernel build.
However, when using devtool, only files specified in SRC_URI are copied
to oe-local-files in devtool's workspace. So if the cfg/patch file is not in
SRC_URI, it won't be copied, causing a kernel build failure when trying
to find it.
This fix parses local .scc files in SRC_URI, copies the corresponding
.cfg/.patch file to devtool's workdir, and also adds it to local_files
so it is available when doing a devtool build for the kernel.
[YOCTO #12858]
v2: also supporting patch not in SRC_URI
v3: fix spacing issues
(From OE-Core rev: 5dffd5403664dfcc9e8e42fd3581d5cb70823d7e)
Signed-off-by: Jaewon Lee <jaewon.lee@xilinx.com>
Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandr@xilinx.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Replace the generic whitelist entry with entries for the three specific
'problem' cases in OE-Core. This means the general DEPLOY_DIR_IMAGE entry
doesn't mask problems for others as was recently encoutered by users
reported on irc. In the whitelisted cases they occur only in multilib builds
and the files are identical.
(From OE-Core rev: 05f6042a40bb772f7ce8d6819c5b2937d8c9808d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently the user has no indication of how much sstate was already present
or that would be used by the build. This change adds some summary information
so that the user can see how much reuse is occurring. To fully work it
needs some extra information from a recent bitbake commit but this is
optional.
When combined with bitbake --dry-run this feature can be used to check
if sstate would be reused in a build.
[YOCTO #12749]
(From OE-Core rev: 596f76029ccb6f87c3b049552bd08f5034c41d9c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Replace usage of oe.utils.getstatusoutput() with direct subprocess
calls.
(From OE-Core rev: 2f44b9b5babf8c95340b141917c1142081f1e594)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Using os.path.getmtime() will dereference symbolic links in an attempt
to get the last modified time. This can cause errors if the target
doesn't exist, or worse map to some absolute build host path which would
make a build not reproducible.
(From OE-Core rev: fae23c72288068f90e2f357a8abf1384850c02ed)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This bbclass implements the device tree compilation for user provided
device trees. In order to use this class, it should be inherited in a
BSP recipe which provides the sources. The default setup enables
inclusion of kernel device tree sources (though can be disabled by the
recipe by overriding DT_INCLUDE or KERNEL_INCLUDE).
This provides an additional mechanism for BSPs to provide device trees
and device tree overlays for their target machines. Whilst still
enabling access to the kernel device trees for base SoC includes and
headers.
This approach to providing device trees has benefits for certain use
cases over patching the device trees into the kernel source.
* device trees are separated from kernel source, allows for selection of
kernel and or kernel versions without needing to explicitly patch the
kernel (or appending to the kernel recipes).
* providing device trees from separate sources, from the layer,
generated by the recipe or other recipes.
This class also implements some additional features that are not
available in the kernel-devicetree flow. This includes population of
device tree blobs into the sysroot which allows for other recipes to
consume built dtbs (e.g. U-Boot with EXT_DTB compilation), device tree
overlay compilation and customizing DTC compilation args (boot
cpu/padding/etc.).
(From OE-Core rev: 3874c3859c3515fc8440fa9e776a02ad6ff3135c)
Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
Acked-by: Martin Hundebøll <mnhu@prevas.dk>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It's useful for the SDK to know exactly what TARGET_ARCH and TARGET_OS are,
specifically for SDK QA.
(From OE-Core rev: 0b5f1b0430efac8129bca330370d8818ea93bb39)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
CMake, in it's infinite wisdom, when searching for libraries (using
find_library) will look inside the libraries PREFIX/lib, PREFIX/lib32, and
PREFIX/lib64. In a multilib SDK more than one of these will exist (potentially
all three) and obviously for a given build configuration only one of those is
valid. This search path is hard-coded deep inside CMake but by setting
CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX we can bypass it and set an explicit
lib<SUFFIX> to use.
Do this by writing ${baselib} into the environment file, and then stripping
"lib" from this to obtain the suffix in the cmake-specific environment script,
which is then read in the CMake toolchain.
(From OE-Core rev: 47160a8c51310f2b40cabf4c1910b5df6e0a15d6)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Instead of both classes using ${PYTHON_PN} (which is set by python-dir and
python3-dir), hardcode the right values so that it is possible to inherit both
pythonnative and python3native at the same time.
If both are inherited then both native Pythons are available, but the last to be
inherited will be the one to set PYTHON.
(From OE-Core rev: 96ccdadb8473daa3c9c2e1cb42fbdff1edd270d6)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the configure fails then we don't really want to see hundreds of lines of
test output (this would be similar to dumping out autoconf's config.log). The
error includes the path of the full log if further debugging is required.
(From OE-Core rev: 09917f582aa1a7b752fa96303e06f9f4712a1d86)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch enables multiconfig dependencies (mcdepends) to be used on
recipes using the following format:
task[mcdepends] = "multiconfig:FROM-MC:TO-MC:PN:task-to-depend-on"
For the sake of simplicity consider the following example:
Assuming we have set up multiconfig builds, one for qemux86 and one for
qemuarm, named x86 and arm respectively.
Adding the following line to an image recipe (core-image-sato):
do_image[mcdepends] = "multiconfig:x86:arm:core-image-minimal:do_rootfs"
Would state that core-image-sato:do_image from x86 will depend on
core-image-minimal:do_rootfs from arm so it can be executed.
This patch makes modifications to bitbake.conf to enable mcdepends, and
to sstatesig and staging.bbclass to avoid conflicts between packages from
different multiconfigs.
[YOCTO #10681]
(From OE-Core rev: f71bfe833c657244d2fd07b3b71e86081d7d1c04)
Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandr@xilinx.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Recent changes broke the preservation of hardlinks during processing due to a missing index.
Fix this, reducing the size of the git recipe packages in particular (it contains many hardlinks).
(From OE-Core rev: 28eeada955762f38ccbd1d26c53768364dbd1a5e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Whilst the package managers handle multilib ELF binaries well, they don't
handle scripts in the *bindir directories well. This adds support for
marking these up so that they can be handled using update-alternatives.
Its done this way so that non-multilib systems don't see any changes and
there is standardisation amongst the multilibs on how the alternatives are
named and prioritiesd. The priotitisation code needs to be added but this
change means there is somewhere to add it.
Recipe needs to set MULTILIB_SCRIPTS in the form <pkgname>:<scriptname>, e.g.
MULTILIB_SCRIPTS = "${PN}-dev:${bindir}/file1 ${PN}:${base_bindir}/file2"
to indicate which script files to process from which packages.
libtool is used a as a reference to stop the libtool scripts conflicting
in a multilib case and allows the kernel-devsrc change to be merged.
(From OE-Core rev: 18e837433d07cfdce4019c13f682c6676425a2ad)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For distutils3, any setup.py invoking will cause setup_requires
argument to trigger a code fetching. Since the following commit
applied in oe-core, code fetching occurs during do_confugire
before the do_compile.
...
b805cef distutils: clean the build tree in do_configure
...
Refer what do_compile did, add var-NO_FETCH_BUILD to do_configure.
Sync with distutils3, add do_configure to distutils also.
[YOCTO #12084]
(From OE-Core rev: 9d556092fcc6f04c487afd126d52935bac133165)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The testtools or subunit is not part of python's standard library, so check them
before use.
Fixed when they are not installed on host:
$ bitbake core-image-minimal -ctestsdk
Exception: ImportError: No module named 'testtools'
Now it can run with a warning:
WARNING: core-image-minimal-1.0-r0 do_testsdk: Failed to import testtools or subunit, the testcases will run serially
(From OE-Core rev: ae53461608c4e71533378369b3f623b4c9002e39)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* this allows to work around some of the issues with file-rdeps
* e.g. in my case I have /usr/lib/libmali.so.0.1 which according to rpmdeps
provides only following libmali*
libmali.so(LIBMALI_1.0)
libmali.so.0.1
but many users of this link with libmali.so directly and according to
rpmdeps require libmali.so which causes file-rdeps for a lot of
recipes
* I was using simple work around to just set:
RPROVIDES_${PN} = "libmali.so libGLESv2.so libEGL.so"
but that doesn't work well with multilib, because the value gets
expanded with MLPREFIX and
RPROVIDES_${PN} = "lib32-libmali.so lib32-libGLESv2.so lib32-libEGL.so"
doesn't help at all.
[YOCTO #9217] Many unsolveable QA warnings from build-deps and file-rdeps
(From OE-Core rev: 01b9810ff1cea53ae321f6fbe760b83573ed78c0)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The variable is PACKAGE_WRITE_DEPS as seen in the default below the
comment.
(From OE-Core rev: 364449251ffe4ff2c11acaa258edcec244c38818)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Leaving -Wcross out of the bbnote version of the autoreconf command
seems to be a long standing inconsistency (dating back to the very
first commit in oe-core) but there's no obvious reason to do so.
(From OE-Core rev: 40644b2b33db6332293543bb39e8d4da07cf8c54)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
- Unify var-DISTUTILS_INSTALL_ARGS in distutils and setuptools
- Supply "--root" directory to the "install" command, and use
it as a prefix to strip off the purported filename encoded
in bytecode files. (It strips build path prefix from .pyc files)
[YOCTO #8446]
[YOCTO #12084]
(From OE-Core rev: 21f0c5a50e00ac34975d79fd48f08730d8f19b15)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a python recipe is using setuptools and the setup_requires argument, where
setuptools will use easy_install to fetch the module if it isn't
present.
The build failed on a machine where a proxy was required, but succeeded on a
machine which had direct access to the internet
Add var-NO_FETCH_BUILD, and set it in distutils_do_compile which does not
allow to fetch code from internet during do_compile.
Example result:
...
ERROR: Do not try to fetch `pytest-runner1' for building. Please add its native recipe to DEPENDS.
Traceback (most recent call last):
File "setup.py", line 56, in <module>
...
The improvement is flexible for test_requirements argument (used at
`setup.py test'), where use easy_install also.
[YOCTO #12084]
(From OE-Core rev: 57414f4a1c549e6faaa110e6e95ff601b05b7361)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The current code pokes into do_deploy manifests from do_image_complete when the
do_image_complete task may or may not depend upon the do_deploy tasks in question.
Often it gets lucky, sometimes it results in build failures.
To fix this, split the functionality to its own task which can have the correct
task dependencies. This means the data in BB_TASKDEPDATA is definitive, the other
code can be dropped, as can the IMAGE_EXTRATYPES do_populate_lic dependencies
from image.bbclass.
This fixes bugs which show up as:
NOTE: recipe linux-yocto-4.14.48+gitAUTOINC+d64aec9793_97c8063d2d-r0: task do_deploy: Started
ERROR: core-image-minimal-1.0-r0 do_image_complete: 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:write_deploy_manifest(d)
0003:
File: '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/meta/classes/license.bbclass', lineno: 33, function: write_deploy_manifest
0029: 'w+').write(output)
0030:}
0031:
0032:python write_deploy_manifest() {
*** 0033: license_deployed_manifest(d)
0034:}
0035:
0036:python license_create_manifest() {
0037: import oe.packagedata
File: '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/meta/classes/license.bbclass', lineno: 191, function: license_deployed_manifest
0187: # It is necessary to mark this will be used for image manifest
0188: man_dic[dep]["IMAGE_MANIFEST"] = True
0189: man_dic[dep]["PN"] = dep
0190: man_dic[dep]["FILES"] = \
*** 0191: " ".join(get_deployed_files(dep_dic[dep]))
0192: with open(os.path.join(lic_dir, dep, "recipeinfo"), "r") as f:
0193: for line in f.readlines():
0194: key,val = line.split(": ", 1)
0195: man_dic[dep][key] = val[:-1]
File: '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/meta/classes/license.bbclass', lineno: 289, function: get_deployed_files
0285: """
0286:
0287: dep_files = []
0288: excluded_files = []
*** 0289: with open(man_file, "r") as manifest:
0290: all_files = manifest.read()
0291: for f in all_files.splitlines():
0292: if ((not (os.path.islink(f) or os.path.isdir(f))) and
0293: not os.path.basename(f) in excluded_files):
Exception: FileNotFoundError: [Errno 2] No such file or directory: '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/build-st-730/tmp/sstate-control/manifest-qemux86_64-linux-yocto.deploy'
ERROR: core-image-minimal-1.0-r0 do_image_complete: Function failed: write_deploy_manifest
ERROR: Logfile of failure stored in: /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/build-st-730/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/temp/log.do_image_complete.50537
NOTE: recipe core-image-minimal-1.0-r0: task do_image_complete: Failed
ERROR: Task (/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/meta/recipes-core/images/core-image-minimal.bb:do_image_complete) failed with exit code '1'
NOTE: recipe linux-yocto-4.14.48+gitAUTOINC+d64aec9793_97c8063d2d-r0: task do_deploy: Succeeded
(From OE-Core rev: b54cdaea7844ee3bf0c39eb97cc7c4c17ed5818c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This means the image code is only included in image recipes through
the IMAGE_CLASSES variable.
This sets things up to allow us to fix image deploy dependency problems.
(From OE-Core rev: fd44b8b4b2484f2d35c7a0e749e7dc316d601989)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Using 'sub' in one function just confuses things, standardise and fix
formatting of the parameters too.
(From OE-Core rev: a740c638148ed7236c49eed55ae9a15b94e55b9f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This reverts commit 6671a4d980c8bef8f402780a308f6c43a25044aa.
This breaks uninative tarball since the call of relocate_sdk.py from uninative.bbclass
wasn't updated to account for this change. It isn't clear what value that code could
pass in and this isn't simple to fix so revert until a better fix can be found
that doesn't break uninative.
(From OE-Core rev: b247392b4ced57cfe694656032f6a6723740a9e8)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
After this replacement, the parent exception handling works so we don't
need subprocess wrapping with bb.error in the underlying functions.
The underlying contexts also have better module handling so the imports
can be cleaned up.
(From OE-Core rev: aa8260adf53139d776a2affe6118d28b295c1fab)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Replace usage of oe.utils.getstatusoutput() with direct subprocess calls. The
call is just a wraper to the subprocess call of the same name and requires
the caller to handle exceptions themselves. We usually do this badly, failing
to show the output or the command or the return code.
Its much safer to rely on a call like subprocess.check_output() instead.
This also makes it easier to spot and remove cases where shell=True isn't
needed in a later cleanup.
(From OE-Core rev: 9f058857fb692f1251deb43bcaa7ed0120140093)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently the compression of sstate objects is single threaded. In the case
of ltp, this takes around 33s. If we add pigz into the list of non-fatal
HOSTTOOLS and then use if it available when building the sstate object,
this time drops to around 6s.
Since pigz is now widely available this is an optimisation we should
utilise.
(From OE-Core rev: 2de56aa0792ec93445130d801936a8ea643fad27)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This allows the calls to is_elf (which calls file) to happen in parallel
allowing a speedup of do_package and do_populate_sysroot for native
recipes.
(From OE-Core rev: bbe0d3e26484f3f347262d40a8a9d415ce21fb43)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There are probably further cleanups needed here but this at least removes
the major code duplication between these two similar funcitons, keeping the
kernel module ".ko" extension check for efficiency to avoid opening and
reading file contents in the general case.
(From OE-Core rev: 7ad0c0d6ab12bebeac097fc0f5210c876dcfe9be)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This function is a bit more invasive to add parallelism to but
allows the shlibs analysis to happen in multiple threads. In order
to return values correctly/safely the data types needed tweaking
to avoid lists and use immutable objects.
(From OE-Core rev: b5788fb1f795f2f35d1788d8311e12984ffb2122)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adjust the code so that the splitting of debug symbols from files happens
in parallel. To to this we need to move some path handling code into the
main function and pass more parameters in.
(From OE-Core rev: 9f0c2ed5d44a16e8268ac521236c4752f930f26a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We don't need any functionality from the shell here, its just extra fork
overhead. Therefore remove it and use subprocess directly.
(From OE-Core rev: bcc03ea19e103f6aa93bada2f49fcc5cc7bc0790)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The command for running dwarfsrcfiles is simple and does not need a subshell
for each execution. By expanding out this function to use check_output()
from subprocess and a list of arguments, the shell overhead can be dropped.
For recipes with lots of files this gives a significant saving.
(From OE-Core rev: 6334129dfbe266602fab70ce445641053a05be6c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The current code had broken exception handling due to the use of a
"traceback" variable as well as an import. Use the new library code
for this instead which reduces code duplication and has fixed/improved
exception handling.
The chdir code can be dropped since any directory changes are in other
processes now so there is no need for it here and the code no longer
changes directory.
(From OE-Core rev: bcd47389f4b1fc69d2bb4da01933bfa1fdcae092)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I think this lock dates from before we had sstate for do_packagedata.
Since WORKDIR is recipe specific and we write into WORKDIR, we no longer need
any write locks in the do_packagedata code itself, its handled by the sstate
task lock for the final copy in at the end. The final write lock can be simply
removed.
The only time we need read locking is when actually reading data from the
shared directory. We can therefore reduce the window the lock is held
significantly as well, hence improving the speed of packagedata tasks running
in parallel.
(From OE-Core rev: f7106cdf2190d9ec59132a1cb2bb431d653cd9c5)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch removes hardcodes added to relocate_sdk.py
during SDK build, making it flexible and reusable.
Now default SDK path is passed to the script as
parameter rather then harcoded inside it.
This allows to reuse this script for multiple
relocations, and adds possibility to relocate
SDK multiple times
(From OE-Core rev: 6671a4d980c8bef8f402780a308f6c43a25044aa)
Signed-off-by: Ruslan Bilovol <rbilovol@cisco.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some packages containing shared libraries might be registered
as shlib providers when they shouldn't (for example, the lib is for
their private use and must not generate any dependency).
EXCLUDE_FROM_SHLIBS is targeted at that, but it could be set
for entire recipe only.
This patch allows to set list of packages that are not candidates
for shlib providers.
Variable EXCLUDE_PACKAGES_FROM_SHLIBS is used, e.g.:
EXCLUDE_PACKAGES_FROM_SHLIBS = "glibc-ptest glibc-mtest"
Cc: Andrii Bordunov <aborduno@cisco.com>
(From OE-Core rev: 43be374a6deceeaf105794f034957c65bb6bec72)
Signed-off-by: Oleksii Konoplitskyi <okonopli@cisco.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
armv7+ used thumb2 ISA and it compiles fine with thumb2
issues are only when using thumb1 ISA
(From OE-Core rev: c0ef8a91f671f30acd92e2734144f7ddf1acda53)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In python3, passing a unicode object to hashlib will result in an
exception that encourages you to encode it first.
(From OE-Core rev: b06a44f1081ea422a365e80bc79b2aeb2783d23f)
Signed-off-by: Olof Johansson <olofjn@axis.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The same functionality already exists within bitbake, so avoid
duplicating.
(From OE-Core rev: 978f5a8f16bf5942aad73d761df2a00aeb36339d)
Signed-off-by: Olof Johansson <olofjn@axis.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The path variable is used in an error message a few lines later, but was
never defined.
(From OE-Core rev: 863ff90b788f66241860e27e1fd3a791b00984cc)
Signed-off-by: Olof Johansson <olofjn@axis.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The string.replace function is removed in python3. Instead, the str
method "replace" should be used instead.
(From OE-Core rev: 8538aabf62d866f36764b4b136ee8575308df690)
Signed-off-by: Olof Johansson <olofjn@axis.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Instead of decoding every file we open as UTF-8 (with many errors as machine
code isn't UTF-8), convert the build path to the UTF-8 byte representation and
search for that instead.
(From OE-Core rev: ffb52d383bfe413cf31fef13663fe9937a146c76)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
All values written out to pkgdata are escaped (see write_if_exists() in
package.bbclass). In practice there tend not to be characters that need
escaping except in the scriptlets (pkg_preinst, pkg_postinst, pkg_prerm
and pkg_postrm) where currently we still see the escape codes in the
corresponding files within buildhistory (e.g. \n and \t) and thus also
in the output of buildhistory-diff, hindering proper diffing of changes.
To fix this, when we read values from pkgdata and write them out to
buildhistory, we need to interpret the escape codes by doing the exact
reverse of what we do in package.bbclass.
(From OE-Core rev: c258379181a438cb01728d223b3d05e0ab205941)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The FILELIST field of the package info file in the buildhistory
repository is a space-separated list of all of the files in the package.
If a name of a file packaged by a recipe contains a space character then
of course the result was that we didn't handle its name properly. To fix
that, use quotes around any filename containing spaces and at the other
end use these quotes to extract the proper entries.
Fixes [YOCTO #12742].
(From OE-Core rev: 801b705957dc683030d11393f43407d0b3506b6a)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This allows the user mode flexibility about centrally overriding these
rather than needing to do it on a per recipe basis.
(From OE-Core rev: b0fb5bbd5f62857c32b2e071bcac841f856b1f1b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This uses the new concurrenttest code to enable parallel test execution
if specified.
(From OE-Core rev: 07d19fb3adab7a8d83ba83d9a16395f70d7b7a47)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We have several options for parallel processing in oeqa, parallel
execution of modules, threading and mulitple processes for the runners.
After much experimentation is appears the most scalable and least
invasive approach is multiple processes using concurrenttestsuite
from testtools. This means we can drop the current threading code
which is only used by the sdk test execution.
oeqa/decorator/depends: Remove threading code
Revert "oeqa/sdk: Enable usage of OEQA thread mode"
This reverts commit adc434c063.
Revert "oeqa/core/tests: Add tests of OEQA Threaded mode"
This reverts commit a4eef558c9.
Revert "oeqa/core/decorator/oetimeout: Add support for OEQA threaded mode"
This reverts commit d3d4ba902d.
(From OE-Core rev: a98ab5e560e73b6988512fbae5cefe9e42ceed53)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently we check if the rootfs.img size is greater than 4 GB and use
mcopy to copy it over to a hddimg, a FAT32 volume.
This results in problems when IMAGE_ROOTFS_SIZE is set to be exact 4 GB
(4294967296 bytes). mcopy uses the max offset/file size to be 4294967295
and as a result, it errors out without any warning to the user.
Change the 4 GB check to '-ge' to catch these cases. Since we allow
IMAGE_ROOTFS_SIZE to be in KBs, the maximum allowed is 4194303 KB. Also,
tweaked the error message to refer to wic too.
Fixes [YOCTO #12776]
(From OE-Core rev: 16956dacd4be2c64e5816ccb2b222b5b128838c9)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We should pass the build arguments to setup.py when doing a clean, because
sometimes the arguments are required for setup.py get started.
(From OE-Core rev: f9324af88a99eca28b160fa31aa4516fd397e44b)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use elif for consistency.
(From OE-Core rev: 2ad89f12c9819326b29588a8a6c642aaae990f18)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* this makes it easier to access these variables from some other bbclass
e.g. sdcard_image-rpi.bbclass in meta-raspberry where we need to know
how some files in deploy are named, but we cannot inherit kernel.bbclass
as it's used in image recipe not kernel recipe
* alternatively we can move these to bitbake.conf like similar image variables are:
meta/conf/bitbake.conf:IMAGE_BASENAME = "${PN}"
meta/conf/bitbake.conf:IMAGE_NAME = "${IMAGE_BASENAME}-${MACHINE}-${DATETIME}"
meta/conf/bitbake.conf:IMAGE_LINK_NAME = "${IMAGE_BASENAME}-${MACHINE}"
(From OE-Core rev: 7d0ef0eaa1bfe97015a774c26f5791622e7e8b12)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* use INITRAMFS_BASE_NAME and INITRAMFS_SYMLINK_NAME variables, like
other kernel artifacts are using
* use "${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME}" instead of
"${PV}-${PR}-${MACHINE}-${DATETIME}" to be consistent with other files
* allow to modify default symlink name with INITRAMFS_SYMLINK_NAME
instead of currently used:
initramfs_symlink_name=${type}-initramfs-${MACHINE}
(From OE-Core rev: 935b9d5a2bd12effad65f69a631ecff96b8bb553)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* add 2 new variables:
KERNEL_DTB_BASE_NAME
KERNEL_DTB_SYMLINK_NAME
instead of reusing KERNEL_IMAGE_SYMLINK_NAME and than expecting that
default value ${MACHINE} was being used in e.g.:
DTB_SYMLINK_NAME=`echo ${symlink_name} | sed "s/${MACHINE}/${DTB_BASE_NAME}/g"`
* install normal DTB files only once even if there is multiple entries
in KERNEL_IMAGETYPE_FOR_MAKE and don't prefix them with the type of
the kernel image, use the KERNEL_IMAGETYPE_FOR_MAKE as a prefix only
when installing them bundled with kernel or initramfs image.
* deploy the files from ${D}/${KERNEL_IMAGEDEST}/ instead of kernel
build directory, so that we don't need to call
DTB_PATH=`get_real_dtb_path_in_kernel "${DTB}"`
again in do_deploy
* create all links in do_deploy task, because default KERNEL_DTB_BASE_NAME
like KERNEL_IMAGE_BASE_NAME contains PKGR and PKGR is different in
do_install and do_deploy, because kernel.bbclass calls
meta/classes/kernel.bbclass:do_install[prefuncs] += "package_get_auto_pr"
meta/classes/kernel.bbclass:do_deploy[prefuncs] += "package_get_auto_pr"
* the filenames are a bit different, but with separate variable it
should be easier for other bbclasses which use these DTB files to
find them correctly, just use either the cannonical name
$dtb_base_name.$dtb_ext or $dtb_base_name-${KERNEL_DTB_SYMLINK_NAME}.$dtb_ext
because PKGR (and other PKG* variables) might be different in your
task and kernel.do_deploy task.
* fix DTB files being deployed with incorrect filenames when
KERNEL_IMAGE_SYMLINK_NAME isn't set to ${MACHINE}, e.g. instead of
the default:
-rw-r--r-- 2 bitbake bitbake 1.4K Nov 20 07:41 deploy/images/raspberrypi3-64/Image-1-4.9.59+git0+e7976b2aff-r0.2-lirc-rpi-20171120043031.dtbo
lrwxrwxrwx 2 bitbake bitbake 64 Nov 20 07:41 deploy/images/raspberrypi3-64/Image-lirc-rpi.dtbo -> Image-1-4.9.59+git0+e7976b2aff-r0.2-lirc-rpi-20171120043031.dtbo
lrwxrwxrwx 2 bitbake bitbake 64 Nov 20 07:41 deploy/images/raspberrypi3-64/lirc-rpi.dtbo -> Image-1-4.9.59+git0+e7976b2aff-r0.2-lirc-rpi-20171120043031.dtbo
I was getting:
-rw-r--r-- 2 bitbake bitbake 1348 Nov 20 10:28 deploy/images/raspberrypi3-64/Image-linux-raspberrypi-lirc-rpi.dtbo
lrwxrwxrwx 2 bitbake bitbake 37 Nov 20 10:28 deploy/images/raspberrypi3-64/Image-linux-raspberrypi-lirc-rpi-master-20171120102653.dtbo -> Image-linux-raspberrypi-lirc-rpi.dtbo
lrwxrwxrwx 2 bitbake bitbake 37 Nov 20 10:28 deploy/images/raspberrypi3-64/lirc-rpi.dtbo -> Image-linux-raspberrypi-lirc-rpi.dtbo
and e.g. sdcard_image-rpi.bbclass from meta-raspberrypi:
37e4e18f4a/classes/sdcard_image-rpi.bbclass
was failing in:
mcopy -i ${WORKDIR}/boot.img -s ${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGETYPE}-${DTB_BASE_NAME}.dtb ::${DTB_BASE_NAME}.dtb
because ${KERNEL_IMAGETYPE}-${DTB_BASE_NAME}.dtb doesn't exist in my
build, due to
DTB_SYMLINK_NAME=`echo ${symlink_name} | sed "s/${MACHINE}/${DTB_BASE_NAME}/g"`
not replacing whole "${KERNEL_IMAGE_SYMLINK_NAME}" (read ${MACHINE})
with just ${DTB_BASE_NAME}
* with this change applied the deploy dir looks like this:
-rw-r--r-- 2 bitbake bitbake 1.4K Nov 20 15:49 deploy/images/raspberrypi3-64/lirc-rpi-1-4.9.59+git0+e7976b2aff-r0.8-raspberrypi3-64-20171120154716.dtbo
lrwxrwxrwx 2 bitbake bitbake 74 Nov 20 15:49 deploy/images/raspberrypi3-64/lirc-rpi.dtbo -> lirc-rpi-1-4.9.59+git0+e7976b2aff-r0.8-raspberrypi3-64-20171120154716.dtbo
lrwxrwxrwx 2 bitbake bitbake 74 Nov 20 15:49 deploy/images/raspberrypi3-64/lirc-rpi-raspberrypi3-64.dtbo -> lirc-rpi-1-4.9.59+git0+e7976b2aff-r0.8-raspberrypi3-64-20171120154716.dtbo
and works correctly even with DISTRO using different naming scheme
* the sdcard_image-rpi.bbclass still needs to be modified, I've provided
updated version here:
https://github.com/agherzan/meta-raspberrypi/pull/159
* mpc8315e-rdb.conf MACHINE in meta-yocto-bsp also needs small fix:
https://lists.yoctoproject.org/pipermail/poky/2018-July/011436.html
(From OE-Core rev: 1860d9d3c62e2e94cd68a809385873ffd8270b6d)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* just to make it more clear what is local shell variable and what is
replaced by bitbake from the metadata and also to prevent the variable
to be incorrectly expanded by bitbake if someone happens to define
e.g. DTB_BASE_NAME
(From OE-Core rev: 98b0f13f0650d970aac7441e7fcfc1089570785f)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
"allow root login" should not be bundled in ssh_allow_empty_password,
because some distro may want only one of "allow root login" and "allow
empty password", so split it out into ssh_allow_root_login and add new
imagefeature allow-root-login so they can be controlled separately,
debug-tweaks will still include both of them.
(From OE-Core rev: 1ab494f06a12548a902298afabd0a842161ef10d)
Signed-off-by: Jackie Huang <jackie.huang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
python-distribute is obsolete and is now simply a PROVIDES of python-setuptools,
so use the right name.
The identical change for setuptools3.bbclass was done in 2015 in 8922e60.
(From OE-Core rev: 87e38f0306400609aeac92bc13fd6f41d61e6271)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Meson uses 'mips' for both big- and little-endian MIPS machines, so map mipsel
to mips.
(From OE-Core rev: 23734432a24da77aa838ad4bdcbcc294cde08348)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently if we do a testsdkext task for the image, it would take
very long time to finish. The time is mostly spent fetching kernel
source via network.
We have done some configuration in auto.conf, trying to make use
of own-mirrors.bbclass to avoid fetching kernel via network.
However, the solution normally does not work. Below is some log
from log.do_fetch.
DEBUG: Fetcher failure: Unable to find file \
file:///path/to/downloads/git2_git.yoctoproject.org.linux-yocto.git.tar.gz \
anywhere.
The tar.gz file is not available. It is generated only if
BB_GENERATE_MIRROR_TARBALLS is set to "1". The default value of
BB_GENERATE_MIRROR_TARBALLS is "0", and according to the manual, users
need choose to set it to "1" only if they are trying to make a source
mirror. So generally, this var's value is "0".
Anyway, we do need to avoid fetching kernel source from network when
doing testsdkext. So set PREMIRRORS in auto.conf to achieve this.
After this change, the time reduces from 4209.131s to 1399.436s on
my local machine.
[YOCTO #12729]
(From OE-Core rev: fd18ddb0664f69d77681590774b0123251a98728)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With PATCHTOOL=git patches the changes in the patch_task_postfunc
of the classes/patch. This works OK when the S dir is a Git repo
but doesn't if the source is a tarball.
The while condition in the patch_task_patch_prefunc must be
jailed into the WORKDIR. In the opposite, when you are executing
the recipe out of a Git subtree the function simply fails but when
your recipes are into a Git repo the patch_task_postfunc execute a
commit over your BSP local Git repo adding the changes in an
arbitrary Git repo found in the path from the SOURCE directory to
the '/'. This situation is highly probable in cases like ~home
directories under the control of a .git repo or Yocto BSP which
manage the meta layers as git submodules.
This patch fix the changes introduced in
classes/patch: when PATCHTOOL = "git" double-check the repository
commit: 86ab56b551
Author: Paul Eggleton <paul.eggleton@linux.intel.com>
Date: Tue Dec 5 14:36:58 2017 +1300
classes/patch: when PATCHTOOL = "git" double-check the repository
If a bug is present or the user has set PATCHTOOL = "git" on a source
tree that isn't git, if we try to perform git operations (such as
committing or changing branches) when extracting source, then we might
in fact be running those operations on the metadata repository if the
build directory is underneath, say, poky or OE-Core, and that could
make a mess. Check if the source tree is a git repository and refuse
to continue if it isn't.
(From OE-Core rev: db6ce9d8838b1f9064604654ab579da3e237f361)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
base_do_configure() tries to do "make clean" if there is a Makefile present.
For most recipes using distutils there is not a Makefile, but we do know that
"setup.py clean" will work so call that instead.
(From OE-Core rev: b805cefb24566772a2beb5d02036266e45370913)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This reverts commit 2e7f3b2b9318d1e5395ad58131eafb873f614326.
It was breaking quite common use case that the dtb files are in
some subdirectory and then kernel build fails to build them.
As reported by khem:
http://lists.openembedded.org/pipermail/openembedded-core/2018-July/152578.html
me:
http://lists.openembedded.org/pipermail/openembedded-core/2018-July/152579.html
on raspberrypi3 build:
make[3]: *** No rule to make target 'arch/arm/boot/dts/dwc2.dtbo'. Stop.
arch/arm/Makefile:345: recipe for target 'dwc2.dtbo' failed
make[2]: *** [dwc2.dtbo] Error 2
Makefile:146: recipe for target 'sub-make' failed
and trevor on the IRC:
20:35:49 < tlwoerner> the recent 2e7f3b2b9318d1e5395ad58131eafb873f614326 commit in oe-core seems to cause dragonboard-410c's kernel to fail to build
20:36:26 < tlwoerner> for the dragonboard-410c, KERNEL_DEVICETREE is set to "qcom/apq8016-sbc.dtb" but the build failure is:
20:36:37 < tlwoerner> *** No rule to make target 'arch/arm64/boot/dts/dts/qcom/apq8016-sbc.dtb'. Stop.
20:36:44 < tlwoerner> i.e. the "qcom/" is getting removed
20:37:08 < tlwoerner> oops!!
20:37:33 < tlwoerner> wrong copy&paste, the actual error is:
20:37:36 < tlwoerner> *** No rule to make target 'arch/arm64/boot/dts/apq8016-sbc.dtb'. Stop.
20:37:53 < tlwoerner> i.e., the "qcom/" is being stripped out
(From OE-Core rev: 0d725c76c113dec441a7319a6ee997e4ae8c4c88)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The cross file specifies the host/target cpu_family, which should be one of a
defined set of values[1] but if it isn't Meson won't complain and instead
recipes may behave unexpectedly.
[1] http://mesonbuild.com/Reference-tables.html#cpu-families
(From OE-Core rev: e33b902a1dc4294dac148715f4d3ca5b0a6ee1b7)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
- Ensure that the PACKAGECONFIG arguments are always in EXTRA_OEMESON
- Log the arguments that are being passed in do_configure.
- Do verbose builds so the compile logs are useful for debugging build problems
(From OE-Core rev: 3112ff268d095a65ecb893dd6ca88a85b0f70446)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As well as setting RECIPE_SYSROOT we also need to set STAGING_DIR_HOST/TARGET.
(From OE-Core rev: 59a0a05235d80c86251cf45d7142bfc57f2e70d2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Without this, recipes can't find allarch data files like autoconf-archive.
(From OE-Core rev: 8ae70703f68853a8714a4fb8fa5d959b5e21a02d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The normalize_dtb function was buggy because
it only converted from .dts suffix to .dtb
suffix if the user passed a full source path to
KERNEL_DEVICETREE containing the /dts/ path.
The problem is that if the user did that there
would be a warning.
On the othet hand if user just set the variable
KERNEL_DEVICETREE="file.dts" the bbclass translation
to the respective .dtb target did not occur and
make would fail saying it has no rule to make target
file.dts
This patch decouples the logic of having /dts/ in the
path from the target translation.
(From OE-Core rev: 2e7f3b2b9318d1e5395ad58131eafb873f614326)
Signed-off-by: Paulo Neves <ptsneves@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If UBOOT_DTB_BINARY is empty, then don't try inserting the U-Boot
signing keys into the DTB. In this configuration the keys are expected
to be already present in U-Boot's DTB.
(From OE-Core rev: a0d74767f7bd18c853df6b0be162363076d8f965)
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
MACHINE = "qemumips64"
MULTILIBS = "multilib:lib64 multilib:lib32"
DEFAULTTUNE = "mips64-n32"
DEFAULTTUNE_virtclass-multilib-lib64 = "mips64"
DEFAULTTUNE_virtclass-multilib-lib32 = "mips32r2"
bitbake core-image-minimal -c populate_sdk
Results in gcc-cross-canadian-mips failing to build due to the use
of an incorrect sysroot, fix this. All nativesdk pieces should be in
the same sysroot (unprefixed).
(From OE-Core rev: ae48ee6627e6c1c4f1fcc4ead40edc968e64f7fe)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With the fixes to other parts of multilib, it was found that the fixup code's
assumptions about the recipe sysroot were incorrect. We need to use the value
calculated earlier in the function.
It turns out there is a rather neat way to do this which cleans up the code
as an added bonus.
(From OE-Core rev: 2c1978fe1a5b72167c49010fbdd39a9e2eefdef8)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently there is duplication in the code, we can clean this up
by extending the multilib variants list.
This code also currently fails its its called from an existing multilib
context since its assumes the data store passed in is the non-multilib
case. When building an image, say lib32-core-image-sato, this leads to
incorrect PATH values.
To fix this, we also request a data store for the "" variant allowing
this corner case to be fixed and for the function to correctly return
values for each multilib even when a multilib is already selected.
(From OE-Core rev: cc1c481560b81c223170230430308c7e2f08c812)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently if you enable multilib, then build an image, the multilib
recipe sysroot is build in the wrong WORKDIR. If you then clean and
rebuild the image you see "file exists" errors.
This patch ensures the real WORKDIR is used consistently and then
cleans/rebuilds also work correctly.
(From OE-Core rev: c013ae59a158378d06ecf8eb123df0a10bf986b4)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Changed package recommendations so that the license package of a
recipe is recommended for all packages of a recipe instead of for one
package given by the recipe name.
Pre-patch behaviour results in a missing recommendation when a recipe
does not have a package with the same name.
(From OE-Core rev: 07343ff6282dd18432ecee5d9b80ad1fb86217f1)
Signed-off-by: Alp Özmert <info@ib-oezmert.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Move packaging rules for cmake -dev files from cmake.bbclass into
bitbake.conf to handle recipes (e.g. harfbuzz 1.8.1) which build with
autotools but also install cmake -dev files.
(From OE-Core rev: 543e39ad5e2baa0f1ece013a89483783e6b15dd9)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
package_qa_handle_error() returns True on non-fatal issues and False on
fatal issues. But the current usage has been to do
sane = package_qa_handle_error(...)
which would always reset sanity status to be that of the last issue
identified. This change the assignments to use the &= operator instead:
sane &= package_qa_handle_error(...)
As far as I can tell, this is not a real problem in practice, because
warnings of different levels (WARN_QA, ERROR_QA) does not seem to have
been mixed in a way that triggered this issue.
(From OE-Core rev: 21d015f6c9927598d64c48c925638619b25cf232)
Signed-off-by: Olof Johansson <olofjn@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a license file referenced from LIC_FILES_CHKSUM doesn't exist,
insane.bbclass would output an error message, but would continue the
build. This change makes this error fatal (as I suspect has been the
intention).
(From OE-Core rev: da29440633706fb7a346391d97894d6f2cbb0d01)
Signed-off-by: Olof Johansson <olofjn@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If SOURCE_DATE_EPOCH is unset (in addition to the existing "0" behaviour)
parse out the top most commit timestamp from the kernel tree to use as the
timestamp.
(From OE-Core rev: 2f0dd67a5a8d4269f5155004d532d8fa972b3223)
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When REPRODUCIBLE_TIMESTAMP_ROOTFS is unset and we want to parse one
from git, use COREBASE as the base for the git command so we have a
known repository which we're using. Without this the build may fail
if the current directory is not part of a git repository.
(From OE-Core rev: 1c2197f96d69547e10b74dc722d9a569d9a2b2b6)
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Systemd mount configuration file must have a name that match the mount
point directory they control. So for instance, if a mount file contains
[Mount]
...
Where=/mnt/my-data
The file must be named `mnt-my\x2ddata.mount`, or systemd will refuse to
honour it.
If this config file contains an [Install] section, it will silently fail
because the unit file is not escaped properly when systemctl is called.
To fix that, make sure paths are escaped through `shlex.quote`.
(From OE-Core rev: bbd9524256461f1bcafd4103edd575e668de76f8)
Signed-off-by: Damien Riegel <damien.riegel@savoirfairelinux.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
The testimage changes break the autobuilder. The plan is to revert these hacks
but due to various changes happening with the autobuilder, we need these for now
to keep things working until we can move to the new autobuilder codebase.
(From OE-Core rev: 309a02931779f32d1139cc1169a039cbe4638706)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The TEST_IMAGE interface has never particularly worked and image testing currently
gets configured manually.
This reworks the interface to better serve the needs of its users, replacing it
with TESTIMAGE_AUTO.
This does away with the need for the separate class due to better bitbake APIs for
changing tasks.
TESTIMAGE_AUTO will automatically boot under qemu any image that is built. It
also adds in dependencies so that any SDK for which testing is requested will
automatically be built first.
The code in bitbake.conf was error prone (e.g. testsdk wasn't considered), this
improves it to standardise on IMAGE_CLASSES as the standard configuration mechanism.
(From OE-Core rev: b34d44f3dfea8254826a46701a4fe3769a900434)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The logic can be improved and the historical NOISO/NOHDD variables
moved into the class and out of common code.
The variables are also then removed in favour of directly controlling
the behaviour from IMAGE_FSTYPES in line with all the other image types.
(From OE-Core rev: a052caed563a09a01f5a3ea1f0477f379c05bee0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Right now the code handling class inherits is spread all over and
its hard to get an idea of what is happening overall. Combine all
the code together to make it clearer. There shoould be no functionality
changes.
(From OE-Core rev: 9b6cda7ff443eebfc5a5a8c9442c93a881807dab)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The current looping structure is confusing, simplify it a bit
to improve readability. Should be no functionality changes.
(From OE-Core rev: 498065b51b205b43d7dae1008014eba85a8f138c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This function is a little obtuse, add more comments about what its
doing and why. Also combine some of the statements where possible
to improve clarity.
(From OE-Core rev: 3e0c22e9bd9757cd458a073a3f043a48184d7bab)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Once, there were do_setscene tasks but this hasn't been the case for years,
drop the old code.
(From OE-Core rev: b13a691f1cfc0d68a0f94c343fa3a1b987dbe117)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is a reworked version of the issue which 5479654eea
attempted to fix.
"""
Each time I build my image after the first, I end up with a
do_image_complete_setscene stamp file with an extra _setscene appended to
the name. Eventually, the filenames end up being so long that mv complains
and the build fails.
It looks like this behaviour was introduced when the special handling was
added for do_image_complete in 2ff9d40dc88d43567472218cf3d3faf414398c71.
"""
Instead of the original approach which broke do_package_setscene, add
an entry to explictly stop the stacking _setscene pieces on do_image_complete.
It's not straightforward to just move *do_image_complete* after the
*_setscene* pattern because do_image_complete stamps would then match
do_image*.
(From OE-Core rev: 0f4e734e0ef40076351ed7ff795aac36197e4949)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Whilst this fixes the do_image_complete_setscene append problem, it creates a
new problem since the code can no longer reach the *do_package_setscene.*
code block below it. This breaks builds as per [YOCTO #12765]. Revert this
change in search of a better fix.
This reverts commit 5479654eea.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The variants are needed in particular when executing postinst_intercepts as
those may require running binaries built for different architectures and
against different sets of library paths, when multilib is in use (or nativesdk host
packages are installed), so a single global variant of the script was not working.
I do understand expanding PATH and DEPENDS in this manner is hackish, however
every other approach I could think of is worse.
(From OE-Core rev: 2f31eecc40ea4d0865aa28d65a0ba7d5a629393a)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previously only one global variant of the script was created,
which caused numerous issues:
1) multilib was not properly supported due to multilib variants each
needing their own version of the qemu binary and library paths to be set
2) nativesdk was not properly supported for the same reason
This patch also moves setting LD_LIBRARY_PATH directly into the
recipe, as passing it down from other recipes did not work when
said recipes were allarch, and adjusts calls to qemuwrapper from
postinst-intercepts, so that its correct variant is selected.
Also, the various qemu fallbacks in qemuwrapper script are all removed,
as they are no longer necessary.
(From OE-Core rev: d10fd6ae3fe46290c6e3a5250878966d9f12ca3f)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This has the following benefits:
- consistent with how the other caches are created into target rootfs
- only runs once per package manager transaction, instead of once per every immodule package
- correctly postpones to first boot if qemu is not working; from postinst itself
this would've required special arrangements to avoid what is now a do_rootfs failure.
(From OE-Core rev: cca3c084b6c9bf600d7306e3fe12c4f236b78656)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The checksum value is only calculated if the uninative class is
inherited, so check for inherit before adding it to local.conf
(From OE-Core rev: 3b5b832589d943700b273e3a4d83561be0c47f36)
Signed-off-by: Jeremy Puhlman <jpuhlman@mvista.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The audit package specifies the following:
UPDATERCPN = "auditd"
However because it is not multilibized, the value "auditd" is used to
search for the package to add the post install script too. In the mutlilib
alternate abi case, that package does not exist. It ends up assigning
the post install script to the lib32-audit-lic package, which
subsequently failes to execute the script due to the initscript it is
trying to turn on is not installed.
(From OE-Core rev: ce99653e1af50d9e8f070ca6ae810908c4c138c6)
Signed-off-by: Jeremy Puhlman <jpuhlman@mvista.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There's a bug in Meson[1] where it find_program("foo") will fail if foo is
defined in the cross file as a list.
This is causing the Meson build of libdrm to fail, but for this instance we can
work around the problem by only using lists in the cross file if there are
arguments, and just using a string if there are not.
[1] https://github.com/mesonbuild/meson/issues/3737
(From OE-Core rev: 7fd8bc469c2caacc1c2021bd0aa83dd6da7fe1e7)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When generating the extended SDK, there is a copy step where this class
goes through the layers and other stuff that have been copied to
generate the SDK. The corebase; ie. the folder that contains the core
layer 'meta' is treated in a special way. Unfortunately in our tree, we
have:
sources/meta/meta
| `- core layer
`------- corebase
In populate_sdk_ext's copy_buildsystem, the heuristic to determine which
element of the list returned by copy_bitbake_and_layers is corebase is
fooled by such layout.
In copy_bitbake_and_layers, corebase is already handled specifically and
reliably, so we should let that function tell us which folder is
corebase instead of trying to determine it.
To do so, change the return type of copy_bitbake_and_layers to a tuple
that contains (corebase, copied_layers). It also simplifies the code on
the caller side.
(From OE-Core rev: 5368bc5d0d3606198b93e877bcafcd77bb5f4fd1)
Signed-off-by: Damien Riegel <damien.riegel@savoirfairelinux.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When generating overlay DTB configuration sections, U-Boot doesn't want
the kernel specified again as we already have that in our base DTB. Add
support for this to allow bootm to process overlay configuration sections.
(From OE-Core rev: c0db9776beb4f519079a554a733353c368739dcf)
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Introduce UBOOT_DTB_LOADADDRESS and UBOOT_DTBO_LOADADDRESS so that you
can set where U-Boot loads full and overlay DTBs. This is required when
using bootm's overlay support to construct the final DTB.
(From OE-Core rev: 05d2230db1d7379494814407fc0d79d7e755d89e)
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The sshd UseDNS option has defaulted to "no" since openssh 6.8p1,
so it's no longer necessary to postprocess the rootfs to force the
option:
https://www.openssh.com/txt/release-6.8
(From OE-Core rev: 0cb4f11614bd3b17db8e6b3516761193cd45d082)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When include conf/distro/include/security_flags.inc, NOPIE flags are
still required for mips64 target builds. Otherwise it fails to build
packages such as glide which inherit go.bbclass:
| .../tmp-glibc/work/mips64-wrs-linux/glide/0.13.1-r0/recipe-sysroot-native/usr/bin/mips64-wrs-linux/../../libexec/mips64-wrs-linux/
| gcc/mips64-wrs-linux/7.3.0/ld: .../tmp-glibc/work/mips64-wrs-linux/glide/0.13.1-r0/go-tmp/go-link-518447869/go.o:
| relocation r_mips_26 against `a local symbol' can not be used when making a shared object; recompile with -fPIC`
Use override 'mipsarch' to set SECURITY_CFLAGS for both mips and mips64.
(From OE-Core rev: 98b24e9268dc444356ce8bd9ddfec6adcce5e02a)
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
By default, we ought to use console="${console},${baudrate}" as
console bootparam as commonly it is left to be passed with the
bootargs.
(From OE-Core rev: 2ce3534b2011cf5516780c9fd7e00bd107619adc)
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a package installs manual files, it should update manual index cache
after its installation. Add package 'man-db' to RDEPENDS which contains
command 'mandb' to update the cache. And do the update in the post
install scripts.
(From OE-Core rev: 078900f2416202b677471b10b69c8defb0f14c8d)
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Instead of patching Module::Build, maybe Module::Build::Tiny and all other
similar tools, use the official way to tell them which is the target perl
on target.
(From OE-Core rev: f3925216b06ff7fbe21989210f8eb11e16be6631)
(From OE-Core rev: 306435507c4790ec44f30cd3c7fa7d340b441ec4)
Signed-off-by: Jens Rehsack <sno@netbsd.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch adds the posibility to build using TCLIBC=newlib.
It allows users to build baremetal applications with the use of a
C library.
Newlib is a lightweight C library meant to be used on embedded systems,
it is meant to be easily portable for new platforms and to provide
basic functionality on them, by design, it provides stubs for some of
these core functions declared as weak, so they can be built correctly
and then linked against some other library which provides specifics
about the platform being used if need be, libgloss takes care of these
in some cases, but it can also be extended, this patch also allows the
user to easily add other libraries to it by adding them to
NEWLIB_EXTENDED for this specific reason.
(From OE-Core rev: 9f0570351a7b0877aa50efff5fe9a9ef368cb38f)
Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandr@xilinx.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch adds makes it possible to build elf for powerpc by adding
this combination to the elf headers machine dictionary, this can be
useful when trying to build baremetal applications where the TARGET_OS=elf
(From OE-Core rev: 6f7ef4f6049fa8f2a8e17abfcf53ccbc22394088)
Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandr@xilinx.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With recent kernels (i.e. 4.17+) the configuration phase of the kernel
will check for capabilities/options of the compiler for CVE and other
mitigation support.
For a general kernel, we want to ensure that CC is fully defined when
the config targets are invoked (so the proper compiler will be checked).
For linux-yocto, we also need to specify the compiler/tools dependencies
for the configme task since it executes before configure and hence the
main kernel build DEPENDS will not always be in the sysroot before it
executes. Without those dependencies the kernel will be incorrectly
configured (i.e. bison is missing) or the configuration will fail the
mitigation tests.
[YOCTO #12757]
(From OE-Core rev: ff1bdd75d50f0ebac3d599e461685ace29559a82)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It's useful for the post-relocate scripts to be able to see the SDK
environment, for example to see the values of CC, CXX etc. in order to
dynamically generate toolchain files.
To enable this, source the SDK environment script prior to calling the
relocate scripts.
(From OE-Core rev: adcf69ee3310171580c28e141fec6997b1f06da4)
Signed-off-by: Martin Kelly <mkelly@xevo.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, if a post-relocate script fails, it fails silently. We should
be louder about this, as it likely indicates a broken SDK.
Print a message if a post-relocate script fails.
(From OE-Core rev: 369b5f3f98f8455c79731621cc669ad1948e2022)
Signed-off-by: Martin Kelly <mkelly@xevo.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, we look only for scripts matching *.sh, which means we can't
write post-relocate scripts in other languages.
Expand this to allow any type of script.
(From OE-Core rev: 5569a6ec6d3c4358719350cac88afa69a76097a8)
Signed-off-by: Martin Kelly <mkelly@xevo.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A function is uses a mix of spaces and tabs. The rest of the file
uses tabs, so switch to tabs uniformly.
(From OE-Core rev: 693daaac7399a5a7665cd3bcbc915ff93db36db5)
Signed-off-by: Martin Kelly <mkelly@xevo.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previously, when dropbear was started via its init script, relocation
of DROPBEAR_RSAKEY_DIR to support read-only rootfs was handled at
run time from within the init script.
Update the init script to take advantage of the read-only rootfs
config setup by read_only_rootfs_hook() and therefore be consistent
with startup under systemd (where relocation of DROPBEAR_RSAKEY_DIR
is handled by the read_only_rootfs_hook() at build time).
(From OE-Core rev: 4990f87b2f6a8b30c8d1c767636e7f5527f595ba)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
testimage-auto is expected to run testimage task's codes automatically.
But in fact, it's currently missing some codes, including testimage_sanity
and create_rpm_index.
This leads to the problem of unexpected runtime failure of test_dnf_makecache.
The error message is as below.
RESULTS - dnf.DnfRepoTest.test_dnf_makecache - Testcase 1744: ERROR
This error is caused by the fact that create_rpm_index is not executed
before running the tests.
There's no reason why such codes should not be in testimage_main, so
move them into it.
(From OE-Core rev: fa7ba486ded13907f63f9300f66350ba2835a3f7)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Having 'auto' in TEST_SUITES will also run the 'dnf' test cases,
so also check it to determine whether to create rpm index or not.
This is to fix the following error when TEST_SUITES = "auto".
RESULTS - dnf.DnfRepoTest.test_dnf_makecache - Testcase 1744: ERROR
(From OE-Core rev: c1f4177848d25a9121f2a85da655ee414cd424b1)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The current behaviour of TEST_SUITES is very confusing.
setting: TEST_SUITES = ""
result: Execute all test cases.
setting: TEST_SUITES = "some_case_not_exist"
result: Error out with 'Empty test suite' message.
The expected behaviour of TEST_SUITES should be:
1. when 'auto' is in it, execute as many test cases as possible
2. when no valid test case is specified, error out and give user message
The first one is implemented by a previous patch.
The second one is fixed in this patch.
Also add debug message to show test cases to be executed. This is
for easier debugging.
(From OE-Core rev: 909568821fbad8a6a7034b10a2dc349a210fdfc6)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The native override is specified in two different places, so let's move
it into a function to reduce code duplication.
(From OE-Core rev: c455ec4a12d4966524da9436722476aa2d428765)
Signed-off-by: Martin Kelly <mkelly@xevo.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
One of the uses of externalsrc is to enable iterative editing and
rebuilding of source files during development. In such situations,
disabling Automake dependency tracking can lead to sources not being
rebuilt even though files they depend on have been modified.
(From OE-Core rev: af2f802d5b59203a887982af83252565b8078085)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently if KERNEL_IMAGETYPES contains both vmlinux and vmlinux.gz,
KERNEL_IMAGETYPE_FOR_MAKE will end up containing two copies of
vmlinux, which will result in two calls to "make vmlinux" from
kernel_do_compile().
Avoid duplicating vmlinux in KERNEL_IMAGETYPE_FOR_MAKE plus some
minor non-functional updates to formatting and comments.
(From OE-Core rev: 80455a0b6cce6d12a5b32194d0cad2e4c7f71599)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Building on a host OS other than a recent version of Linux is not
recommended or supported. Drop the historical _build-${BUILD_OS}
over-ride to avoid giving the impression that other host OS's might
be supported.
(From OE-Core rev: 428fc39356cb77830de9e0d3f1dbd00f5868290a)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There doesn't seem to be a clear reason to have two separate
variables to hold whitelisted GPLv3 recipes. Both variables are
treated the same, so adding a recipe to LGPLv2_WHITELIST_GPL-3.0 is
already equivalent to adding it to WHITELIST_GPL-3.0.
Anyone needing to whitelist a GPLv3 recipe should now just use
WHITELIST_GPL-3.0.
(From OE-Core rev: d4dea76fbe9765d489e3e522a9d2c22049610c7b)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The _virtclass-XXX over-rides are problematic in that they are higher
priority than _forcevariable, which is documented as being the
highest priority over-ride.
Since they are now obsolete (replaced by _class-native and
_class-nativesdk) drop them entirely rather than try to fix their
priority.
(From OE-Core rev: c5aa33ac483618bc23fbaccb0a18853186f9155d)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some backported patches fix multiple CVEs and list the corresponding
identifiers on multiple lines, rather than on a single line.
cve-check.bbclass yields false positive warnings when CVE IDs are
presented on multiple lines because re.search() returns only
the first match.
An example of this behavior may be found when running do_cve_check() on
the wpa-supplicant recipe while in the rocko branch. Only CVE-2017-13077
is reported to be patched by commit de57fd8, despite the patch including
fixes for a total of 9 CVEs.
This is resolved by iterating over all regular expression matches,
rather than just the first.
(From OE-Core rev: 8fb70ce2df66fc8404395ecbe66a75d0038f22dd)
Signed-off-by: Jon Szymaniak <jon.szymaniak.foss@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add test cases to test “exclude” and “installroot“ options, also modify
the logic of filtering packages on the feed to have all the packages
needed by the tests.
[YOCTO #10744]
(From OE-Core rev: 1121806603c6f621d084b692216f3f616a0768dc)
Signed-off-by: Jose Perez Carranza <jose.perez.carranza@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Each time I build my image after the first, I end up with a
do_image_complete_setscene stamp file with an extra _setscene appended to
the name. Eventually, the filenames end up being so long that mv complains
and the build fails.
It looks like this behaviour was introduced when the special handling was
added for do_image_complete in 2ff9d40dc88d43567472218cf3d3faf414398c71.
So, let's ensure that the *_setscene* pattern is matched before anything
else so that any do_image_complete_setscene stamp file is always ignored
and the do_image_complete non-setscene stamp file is moved only once.
It's not straightforward to just move *do_image_complete* after the
*_setscene* pattern because do_image_complete stamps would then match
do_image*.
(From OE-Core rev: f04e6bd144deb0c8fe2742f66b18904b6619a502)
Signed-off-by: Mike Crowe <mac@mcrowe.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a recipe sets S to ${WORKDIR}/ then the S != WORKDIR test doesn't work as
expected. Use os.path.normpath() to normalise the paths so string comparison
works.
(From OE-Core rev: 06aaafd14f3c8e27faeea0a514f80e1ff5eb4deb)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Commit a1690131691507bbf5853540229b3ad775b836bf removed the ability of
recipes to set KERNEL_IMAGETYPE_FOR_MAKE. Fix that by letting recipes
continue to set their own KERNEL_IMAGETYPE_FOR_MAKE if they so wish.
They may have been doing so for a while, and don't want to have their
carefully-selected value trampled on by kernel.bbclass.
This may be required if the recipe itself wants to build one type of
kernel, but post-process it into a different type, rather like the
vmlinux->vmlinux.gz support provided by kernel.bbclass.
(From OE-Core rev: 38abd26fe7de321e0f1fc4895f754f34dee90f6c)
Signed-off-by: Mike Crowe <mac@mcrowe.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
shlibs is largely useless for allarch, the particular usecase where it
fails is when DISTRO_FEATURE is changing due to libc being different e.g.
Variable package_do_shlibs value changed:
-DISTRO_FEATURES{ldconfig} = Set
+DISTRO_FEATURES{ldconfig} = Unset
musl -> glibc or other way around 'ldconfig' gets added or deleted to
DISTRO_FEATURE set, neither this distro feature nor the shlibs processing
during packaging is of interest to allarch packages which are largely
arch independent scripts
(From OE-Core rev: 06602d56d1d311562144eafe459fcea36931a34c)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The SSTATECLEANFUNCS mechanism was introduced to solve user/group
deletion problem. After RSS mechanism was introduced, there's no
need to do so.
There was a patch to remove these obsolete codes for useradd.bbclass,
but the codes in sstate.bbclass were not removed. So clean it up.
(From OE-Core rev: 215b83ce892a7002ed0b1bd7b82a08e67ae15121)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We have some tasks depending on image's do_image_complete task, and we
are also using WKS files to generate partitioned images, but now there
is lacking a inter dependency between do_image_wic and
do_image_complete, so we have to depend on both of them.
Fixed by adding the dependency.
(From OE-Core rev: e3a25f06f2cde701415f4130a43c9b3895d42f10)
Signed-off-by: Ming Liu <liu.ming50@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Native.bbclass needs to fixup both base_libdir and libdir to handle things like multiarch. This fixes wic and ext4.* image failures during do_rootfs where mkfs.ext4 can't find its libraries.
(From OE-Core rev: 464dad0dc93aeeedd34d90c2f06596060ec135fd)
Signed-off-by: Koen Kooi <koen.kooi@linaro.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Where /bin/sh is dash, the recent toolchain scripts change fails as the $(pwd)
usage in oe-init-build-env doesn't function correctly. Fix this by saving
and restoring the cwd and calling the script within its own directory.
This fixes meta-ide-support on dash based systems.
(From OE-Core rev: dceca6d34071b4cbef9e28bbf19dc12f5d925525)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
Allow debugsource listing using dwarfsourcefiles to fail for static
libraries when the archive content is not as expected.
(From OE-Core rev: e2235b7567a9aba474cda4cdc20cc9bfffc63711)
Signed-off-by: Ola x Nilsson <olani@axis.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This reverts commit b28114cf1e.
The "-E" option for flock is not ubiquitously supported, so don't use
it.
(From OE-Core rev: 802a2877a78a44c17f3e142f7d12017a08d09dad)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
PACKAGELOCK is there to protect readers of PKGDATA_DIR from writes and files
changing whilst they're being read. With various changes to the codebase,
the lock code has become confused as the files are now written by the sstate
code in do_packagedata, not in do_package directly any longer.
This change cleans up the code so read sites take the shared lock (anything in
do_package), write sites take the full lock (do_packagedata sstate).
The lock from do_package sstate is no longer needed since it doesn't write
outside WORKDIR.
(From OE-Core rev: d46cadbbb42aa71f9436d640891d6ccc8f8e3618)
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>
"package.bbclass: Include dbgsrc for static libs" introduced a regression
on mingw, fix this by excluding on that TARGETOS.
(From OE-Core rev: 305dda730738a8fb3789047b06fcc45d10212aa3)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The debugsource must be added from the package providing the static
lib, because any package using that lib does not have access to the
source code.
Fixes [YOCTO #12558]
(From OE-Core rev: eefa5ba35663fabe1f3f8cf7f1ff126d51240613)
Signed-off-by: Ola x Nilsson <olani@axis.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
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>
We just ran into an issue where tar failed to build on one server setup
but built everywhere else just fine.
It was running makeinfo to regenerate some docs files and makeinfo was too
old for the host it was running on. There was no dependency on makeinfo-native
as it was not meant to be regenerating the docs.
It was being regenerated as a date from a timestamp used in the docs
was different in Asian timezones than in the other timezones our builds
were being tested in.
I added an entry to https://wiki.yoctoproject.org/wiki/TipsAndTricks/
about how this was debugged.
As such, lets default to setting and exporting TZ to 'UTC' as was already
pioneered by the reproducibile builds work. This makes the builds
deterministic.
[YOCTO #12665]
(From OE-Core rev: 2a90ae7a3286724ff9e3615c4dbf56038f703810)
(From OE-Core rev: e31f31f81efe4b60938b724bece2a03c7c74a68d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
Conditionally support binary reproducibility of rootfs images.
If REPRODUCIBLE_TIMESTAMP_ROOTFS is specified then:
1. set /etc/timestamp to a reproducible value
2. set /etc/version to a reproducible value
3. set /etc/gconf: set mtime in all %gconf.xml to reproducible values
The reproducible value is taken from the variable REPRODUCIBLE_TIMESTAMP_ROOTFS.
[YOCTO #11176]
[YOCTO #12422]
(From OE-Core rev: 11e45082ad00b9c172e59bf6b2a76dd613773f5a)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Bump the version number for force remotes to use a newly generated
environment, since the old one potentially had a few bugs
(From OE-Core rev: 6c3b2ac41f3412ebce8364df637d64e34daab8a6)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Improve reporting when the icecream environment cannot be created by
assigning the flock call a specific error number when the lock fails so
it can be distinguished from environment creation errors.
(From OE-Core rev: 563448a7a3ca87cc07528c18f8047913e0468e7a)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The ICECC_ENV_DEBUG variable can be set in local.conf to pass additional
debugging options to the Icecream toolchain creation script.
(From OE-Core rev: be913284bb34ebf4a71770646044603a2a27d01b)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
xz has native support for threaded compression now and SDK creation was the only
part of oe-core which is using pixz instead of xz.
Not only does this remove pixz-native from the SDK dependencies, but in my
limited testing xz -T0 is slightly faster and produces smaller archives than
pixz for the same input.
(From OE-Core rev: ce1cfa57d9828c0898f52e736f671ce8db534031)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since pigz is no longer a drop-in replacement for gzip (oe-core 1624b7b) the
image creation has been using gzip instead of pigz, despite still depending on
pigz-native. Fix this by invoking pigz explicitly.
(From OE-Core rev: 214fa7fe3b162162d2fa8b31eec28bedd86fcc7d)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* 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>
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>
This makes sure files provided by packages that use any of the extra
architectures defined using ${PACKAGE_EXTRA_ARCHS} are cleaned from
tmp/sysroot-components when sstate_eventhandler2() executes.
Without this, changing a package from using one of the extra
architectures to another architecture would lead to files being
leftover in tmp/sysroot-components, which could later be picked up
when creating the RSS for another package rather than the files that
belonged to the updated package.
(From OE-Core rev: b959b3bd92aa2939d407800fc4167b0535fd4674)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Without this change, there will be two sstate index files in
tmp/sstate-control for any machine that contains a dash in the
name.
(From OE-Core rev: 29e7799bdb3773c40492e01448e0c614ed44583d)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is IMAGE_GEN_DEBUGFS="1" variable that enables build of
additional rootfs-dbg and additional archive that contains
complimentary symbols files for a given image. But the issue
with this resulting directory and tarball that before use it
has to be combined with original image content. It is required
since all cross debugging tools like gdb, perf, and systemtap
need file system that contains both target executables/libraries
and their symbols. Those tools need to find executable/library
first and through it debuglink note find corresponding symbols
file.
image-combined-dbg when added to USER_CLASSES just copies
final resulting rootfs back into rootfs-dbg creating combined
target and debug symbols rootfs that can be used for debugging
directly.
(From OE-Core rev: 7ccb077f51c9232de70e5c6f9897fd9986e3be9d)
Signed-off-by: Victor Kamensky <kamensky@cisco.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When archiving a kernel, if S is ${WORKDIR}/git, then
${WORKDIR}/git is in fact a soft link into work-shared,
and the archive contains just the soft link. Fix by
archiving the real directory.
(From OE-Core rev: 564204dd6b73697ef4b6c17243067892876cc323)
Signed-off-by: Tom Hochstein <tom.hochstein@nxp.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Special handling for kernel source in work-shared was
incorrectly limited to kernel-yocto.bbclass instead
of kernel.bbclass.
(From OE-Core rev: b8c5680a67888d43540366a40bd0c501e926ac31)
Signed-off-by: Tom Hochstein <tom.hochstein@nxp.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
Previously this wasn't done, and so any packages installed from
populate_sdk would not have the postinsts fully executed
(particularly generation of various caches via running nativesdk or target
binaries with qemu wasn't working).
[YOCTO #12630]
(From OE-Core rev: a484ff072eea3f47de2c3348048201249cefa46b)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As introduced by a56fb90dc3 ('base.bbclass
wipe ${S} before unpacking source') the base.bbclass uses a python
anonymous function to set the 'do_unpack' varflag 'cleandirs' to either
'${S}' or '${S}/patches' depending on equality of '${S}' and '${WORKDIR}'.
Not that this only differs from the way almost all other recipes set or
modify a tasks 'cleandirs' flag, it also has a significant impact on the
kernel.bbclass (and possibly further ones) and causes incorrect
behavior for rebuilds triggered by source modification, e.g. by a change
of the defconfig file for a kernel build.
The kernel.bbclass tries to extend do_unpack[cleandirs]:
| do_unpack[cleandirs] += " ${S} ${STAGING_KERNEL_DIR} ${B} ${STAGING_KERNEL_BUILDDIR}"
As python anonymous functions are evaluated at the very end of recipe
parsing, the d.setVarFlag('do_unpack', 'cleandirs', '${S}') statement in
base.bbclass will overwrite every modification to cleandirs that is done
as shown for the kernel class above.
As a result of this, a change to a kernels 'defconfig' will lead to an
updated defconfig file in ${WORKDIR}, but as ${B} never gets cleaned and
${B}/.config still exists, it will not be copied to ${B}/.config and
thus not find its way in the build kernel.
This is a severe issue for the kernel development and build process!
This patch changes setting of the cleandirs varflag in base.bbclass to
a simple variable assignment as almost all other recipes do it. This now
again allows overwriting or appending the varflag with common methods
such as done in kernel.bbclass.
This issue affects morty, pyro, rocko and master.
(From OE-Core rev: 20901b9783220aa6e7adae4951c531919c20859b)
Signed-off-by: Enrico Jorns <ejo@pengutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It's possible that a trailing or extra slash somewhere in the external
source path could result in the directory not being removed from
cleandirs; it's also possible that a cleandirs entry is somewhere
underneath the source tree and that tree should never have parts of it
deleted by the build system. Use oe.path.is_path_parent() (which makes
paths absolute before checking them) to find out if any path in
cleandirs is anywhere underneath the external source path, and drop it
if it is.
(From OE-Core rev: 87ec0fb470274d980f8553a85f778809c269c5d7)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use the existing oe.recipeutils.split_var_value() function to split the
unexpanded value of the cleandirs varflag, in case it contains python
expressions - we don't want to split the expression itself as the chunks
will not expand properly individually and we can miss something that
expands to the source tree (and thus it can get deleted, the avoidance
of which is the whole point of this code).
(From OE-Core rev: 611cee69d7300a4746edd752c9557af60e7beecc)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
Set KBUILD_BUILD_VERSION=1 to avoid build version being incremented on
every build. It is visible in the output of "cat /proc/version" after
the hash character.
(From OE-Core rev: 7fa32ee42c3320e9e2b24ef747e43484b719f617)
Signed-off-by: Jonathan Liu <net147@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With the change from assuming kernels will be named "vmlinuz"
everywhere, to instead using KERNEL_IMAGETYPE, we require that
KERNEL_IMAGETYPE is set to something. Instead of setting the default in
multiple individual files, set it in default-distrovars.inc.
x86(-64) arches get bzImage as the default. Others get zImage as per
meta/conf/documentation.conf.
Also set KERNEL_IMAGETYPES, as we will eventually be switching away from
KERNEL_IMAGETYPE.
Thanks to Andre McCurdy <armccurdy@gmail.com> for the arch defaults
part.
(From OE-Core rev: a57d784211a39587538094425ee0246e9ddfbf9d)
Signed-off-by: California Sullivan <california.l.sullivan@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
The multilib version would race against then non-ml version leading
to all kinds of odd build failures.
(From OE-Core rev: 6bb70bd3857edb8cb6cc1317f57b899a89be2653)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
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.
(From OE-Core rev: 7877761534b0c2492da6289e9f2269d41b6ed464)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Although get_filesystem_id() is a private API and never gets passed
a path containing spaces or other special characters, etc, quote the
path anyway for consistency.
(From OE-Core rev: 1a9878cdb1cdb807c47e852b780c8ef9b93a214e)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Before, waf.bbclass would fail to catch FileNotFoundError. Now, it will
catch this error and say that waf doesn't exist.
Fixes [YOCTO 12553]
(From OE-Core rev: f8321dedec7abe392f7e49ff8eee0640463adae5)
Signed-off-by: Amanda Brindle <amanda.r.brindle@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Setup environment for builds requiring binary reproducibility.
Determine and export SOURCE_DATE_EPOCH per each recipe.
This is a crucial step to achieve binary reproducibility.
The value for this variable (timestamp) is obtained after source code for
a recipe has been unpacked, but before it is patched. If the code sources
come from a GIT repo, we get the timestamp from the top commit. (GIT repo
does not preserve file mktime timestamps). Otherwise, if GIT repo is not
present, we try to get mtime from known files such as NEWS, ChangeLog, etc.
If this also fails, we go through all files and get the timestamp from the
youngest one. We create an individual timestamp for each recipe.
The timestamp is stored in the file '__source_date_epoch.txt' (in the folder
source-date-epoch_). Later on, each task reads this file and sets
the exported value of SOURCE_DATE_EPOCH to the value found in the file.
Uasge:
INHERIT += "reproducible_build"
[YOCTO#11178]
[YOCTO#11179]
(From OE-Core rev: cc438ac7711dedbe05d654e99af9316c9215b02e)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
To use 'glide' this class does the integration and reduces code
duplication.
(From OE-Core rev: e0dbcdc2ca0b05b6b062a0ec1496204bb2122fbf)
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
LZ4 format currently used by the Linux kernel is the 'legacy' format.
In order to avoid creating an image that can't be used as a compressed
initial ramdisk with Linux kernel, rename lz4_legacy to lz4.
[YOCTO #12461]
[YOCTO #12149]
(From OE-Core rev: 0c62a9b272d381bd5a16cfef19ecd1a15f521473)
Signed-off-by: Maxin B. John <maxin.john@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Kernel v4.14 and newer contain the following in their Makefile:
HOST_LFS_LDFLAGS := $(shell getconf LFS_LDFLAGS)
HOSTLDFLAGS := $(HOST_LFS_LDFLAGS)
This breaks our menuconfig, because it can no longer find ncurses if its
not on the host machine. This can be seen in linux-yocto-dev, for
example:
[clsulliv@clsulliv build]$ bitbake virtual/kernel -c menuconfig
GEN ./Makefile
HOSTLD scripts/kconfig/mconf
/home/clsulliv/yocto/poky/build/tmp/hosttools/ld: cannot find -lncurses
/home/clsulliv/yocto/poky/build/tmp/hosttools/ld: cannot find -ltinfo
collect2: error: ld returned 1 exit status
make[3]: *** [scripts/Makefile.host:99: scripts/kconfig/mconf] Error 1
make[2]: *** [/home/clsulliv/yocto/poky/build/tmp/work-shared/intel-corei7-64/kernel-source/Makefile:504: menuconfig] Error 2
make[1]: *** [Makefile:146: sub-make] Error 2
make: *** [Makefile:24: __sub-make] Error 2
Command failed.
Press any key to continue...
Fix this by setting HOSTLDFLAGS to ${BUILD_LDFLAGS} in our
'make menuconfig' command.
(From OE-Core rev: 6afe8e211bfb3deb359194488f34a2c56f4b5ef6)
Signed-off-by: California Sullivan <california.l.sullivan@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
My attempt at only inheriting python3native if it was needed was broken and
didn't work, so back it out and always inherit.
(From OE-Core rev: eb08ce66cf7ca6dbdb51fb9b9725267606fba6b9)
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.
(From OE-Core rev: d6f6101cd0ae92e8ad2dec0bcb6db5044726edf9)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This allows catching errors in the scriptlets which would otherwise
go unnoticed, e.g. this sequence:
====
bogus_command
proper_command
====
would work just fine without any visible warnings or errors.
This was previously done only for rpm packages; this patch replaces
the rpm-specific tweak with one that works for all package types.
(From OE-Core rev: a0aa12e1d0ea9064b8dd816d4e82238df765506b)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Export environmental variables needed for binary reproducibility with consistent values.
This class can be used either directly via:
INHERIT += "reproducible_build_simple"
or can be inherited by a more complex/complete bbclass, for example a bblass which
will crack SOURCE_DATE_EPOCH for each recipe.
(From OE-Core rev: 5c2685c5ee2f8210a36b9a8591491b6af0482084)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Replace the occurences of BUILD_REPRODUCIBLE_BINARIES with expanded
values ${BUILD_REPRODUCIBLE_BINARIES} so the variable does not need to be
exported.
(From OE-Core rev: 27f87bbc8395a2481ef808465a62d213a6b678ac)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As of the 4.13 kernel, there are configuration + linker combinations
that do not need (or build) crtsavres.o for ppc64 targets. The commit
of interest is:
commit efe0160cfd40a99c052a00e174787c1f4158a9cd
Author: Nicholas Piggin <npiggin@gmail.com>
Date: Fri May 12 01:56:52 2017 +1000
powerpc/64: Linker on-demand sfpr functions for modules
For final link, the powerpc64 linker generates fpr save/restore
functions on-demand, placing them in the .sfpr section. Starting with
binutils 2.25, these can be provided for non-final links with
--save-restore-funcs. Use that where possible for module links.
This saves about 200 bytes per module (~60kB) on powernv defconfig
build.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
As such, our arch test for crtsavres.o is not enough, we add a secondary
existence check before trying the copy.
[YOCTO #12576]
(From OE-Core rev: af58819253a2d4526dc8871a17e1492bd1d92951)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Respect GTKDOC_ENABLED when inheriting python3native and DEPENDing on
qemu-native, as they're not needed when disabled.
python3native is required as otherwise the host Python is most likely used which
may or may not have python3-six installed (a requirement of gtk-doc).
(From OE-Core rev: b93386b22e1dc78b2917652dac4ad02745a99989)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We should use the value of CC for the c compiler setting in cross
compilation configuration file for meson. For example, if we only
use ${HOST_PREFIX}gcc instead of ${CC}, we would meet the following
do_compile failure for systemd.
cc1: fatal error: linux/capability.h: No such file or directory
Do the same change for LD, AR, NM, STRIP and READELF.
(From OE-Core rev: 177bd96a531fcc85e62baff04aba327e2bccee07)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Many go packages can take advantage of dep tool since
they manage their own dependencies, this class helps
in using go dep tool for such packages
(From OE-Core rev: 9bea8313b0dd5a6af08d15ee8634fe2ef9ee0f75)
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>
With go1.10 the NOPIE flags are only required for
MIPS target builds, and are now incompatible for
the other architectures.
(From OE-Core rev: f2ff90eb7d27a2f69f5948fa8c301de30f5c8132)
Signed-off-by: Matt Madison <matt@madison.systems>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
While useful on embedded devices for saving disk space, use
of shared runtime in Go is not the usual practice, so disable
it for nativesdk builds. We don't use it for native builds,
either, so this makes the SDK match the native environment
more closely.
(From OE-Core rev: fde7017f9735c0d317023022817b28771df53109)
Signed-off-by: Matt Madison <matt@madison.systems>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Don't enable verbose test output (-test.v)
by default, as it generates too much noise
for automated results parsing
* Override do_install_ptest_base in the bbclass,
so recipes can provide their own modifications
with do_install_ptest.
* Improve the generated run-ptest script to better
handle large numbers of tests, and to generate
'status: test name' output similar to Automake
tests.
* Install all non-vendored 'testdata' directories
from the source into the ptest package, as some
packages share test data among multiple tests.
(From OE-Core rev: 11037462d80cefbee90a69e6a8a95895375ed6da)
Signed-off-by: Matt Madison <matt@madison.systems>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Any directory in a Go package's source tree called
'testdata' contains test data, and isn't necessary
for building.
Some packages include ELF files and other binaries
as test data, and staging them in the sysroot and
-dev package leads to unnecessary QA warnings.
(From OE-Core rev: b013db7ab58d4d56ad5c6e54a3a32df31aaf8809)
Signed-off-by: Matt Madison <matt@madison.systems>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The 'go env' in the do_compile function and
the set -x/+x in the do_install_ptest function
were used for debugging the bbclass, and aren't
really needed.
(From OE-Core rev: 351e9fc39408e094bbb4beedf51221adc8afd143)
Signed-off-by: Matt Madison <matt@madison.systems>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
and export it. Go 1.10 now supports using this
separate variable locating its temporary files.
TMPDIR is still set, for compatibility with go1.9;
that can be dropped once 1.9 is retired.
(From OE-Core rev: ce9d70ae2f9981bf5b42641922c34c1ed54eeca3)
Signed-off-by: Matt Madison <matt@madison.systems>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Go 1.10 adds support for selecting hard/soft float
object code through the GOMIPS environment variable.
(From OE-Core rev: f3cabc92dca3408da18f04e4af4051fba1f63c14)
Signed-off-by: Matt Madison <matt@madison.systems>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Patches and recipes reworked for go 1.10's significant
changes to its bootstrap and build steps.
* Update go1.4 source tarball used for go-native
bootstrapping to the version recommended
in the current go documentation
* Remove test data from installed sources to eliminate
some packaging QA warnings
* Set GOCACHE to 'off' to disable 1.10's build caching
in the go recipes and bbclass
* Update go_do_compile to compile both static and
dynamic objects dynamic linking is in use, since
go1.10's build tool is pickier about this
(From OE-Core rev: 4fd749ca6450a4870be1c1e13802f084b6eb0db6)
Signed-off-by: Matt Madison <matt@madison.systems>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There's no need to add to the local copy of overrides and then not do
anything with it.
Now that this function is being used in package creation it was causing
sstate issues as well, as MACHINE is always in OVERRIDES, so something
trivial such as the name of the MACHINE would cause the hash to change.
(From OE-Core rev: 24ddc80fc39291d9952b8e3bd37d66c1c4376e6b)
Signed-off-by: California Sullivan <california.l.sullivan@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There's no need to add to the local copy of overrides and then not do
anything with it.
Now that this function is being used in package creation it was causing
sstate issues as well, as MACHINE is always in OVERRIDES, so something
trivial such as the name of the MACHINE would cause the hash to change.
(From OE-Core rev: 56ab83611d9737b42f05586d2c45d5c438cfc293)
Signed-off-by: California Sullivan <california.l.sullivan@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We can't guarantee vmlinuz anymore. Use KERNEL_IMAGETYPE instead.
(From OE-Core rev: cceb4266f3e70382e171c3a338c10d9730c9dc3f)
Signed-off-by: California Sullivan <california.l.sullivan@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This class is useful on its own and can be used to create configuration
recipes.
(From OE-Core rev: 5d14ff6e25d3b334d4cc9363a6ddeb16f4c2911d)
Signed-off-by: California Sullivan <california.l.sullivan@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We can't guarantee the kernel will be named vmlinuz anymore. Use
KERNEL_IMAGETYPE instead.
(From OE-Core rev: 8e9a5350e51d4c3be5417e55e4fd1428f49f3d8b)
Signed-off-by: California Sullivan <california.l.sullivan@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rather than renaming the kernel to vmlinuz and assuming the name is
vmlinuz in the grub.cfg, copy to ${KERNEL_IMAGETYPE} and also use that
value in the grub.cfg file.
(From OE-Core rev: d37be17527b354fddb3a5740d0197c590d620f42)
Signed-off-by: California Sullivan <california.l.sullivan@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I can't find VM_DEFAULT_KERNEL used anywhere else, and we should not be
statically installing the kernel as vmlinuz.
(From OE-Core rev: 5493bb5ba4b4520f944d38b214a3d53a5282e0be)
Signed-off-by: California Sullivan <california.l.sullivan@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This part is useful on its own, whereas the whole class together is
specific for image-live.
(From OE-Core rev: 8daf2c544eb40d97d99a41627ddc5529c0e23f3c)
Signed-off-by: California Sullivan <california.l.sullivan@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Handling of backfilling is trickier than you'd think. We need this to execute
early enough that the user will see the changes in bitbake -e and other output
yet late enough that the virtclass extensions have changed the tunes before
it executes.
It makes more sense to execute this at anonymous python time now bitbake -e
correctly handles this and that unbreaks multilib corruption of these variables.
[YOCTO #12373]
(From OE-Core rev: cefd312541019c1bb0132f41334df58971fd81ef)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now we're filtering tasks in the rpm indexing code so that tasks can only
see the packages they really depend upon, having noexec package_write tasks
around is causing problems since the tasks exist but don't have manifests.
Removing the tasks entirely solves this problem and streamlines the
task execution graph too.
(From OE-Core rev: 027445cd88a4e706bdfe83bb4ff2c21e2186982a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now bitbake is executing anonymous python fragments in bitbake -e,
ensure we don't show the error in that context (where PN would be
unchanged from default).
(From OE-Core rev: 79240b3af32c7fa44751752e9e8f2ff832439643)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Initialize the git config prior creating a git repository in a plain
directory.
(From OE-Core rev: 0e3a9bed988b5fd4de770fe8cd1160b9f6c8c365)
Signed-off-by: Justin Bronder <jsbronder@cold-front.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
cmake_do_compile() and cmake_do_install() basically do the
same, except they use a different --target, and at the
moment this is copy/pasted code with a minor modification.
Other recipes which e.g. might want to support compilation
as part of ptest have to do the same. This is a bit
inconvenient.
By factoring out all of this into a common helper,
cmake_runcmake_build(), this is easily re-used. An
(imaginary) recipe can compile ptest support simply by
using
cmake_runcmake_build --target buildtest-TESTS
(assuming such a build target exists).
Also, this now is very similar to oe_runmake().
(From OE-Core rev: 7620dafe7358f017a8cd558b480af73896768f04)
Signed-off-by: André Draszik <andre.draszik@jci.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Several of the calls to getVar() were either superfluously passing
True for the expand argument, or were wrongly passing False
(From OE-Core rev: a7b0f7605f62420d7c9b9d5ef2e03c5cc5c81d03)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
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)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The shlibs detection/handling iterates the package list twice, but PRIVATE_LIBS
is only fetched in the first loop which means the second loop only considers the
value set.
(From OE-Core rev: 8c90c0081c38b33c99655f806cbe668600c170cc)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Changing ICECC_ENV_VERSION or select variables that the user can set to
control the behavior of icecc should not cause recipes to rebuild
(From OE-Core rev: b2c64414bbc357d35c1b076840bfc6ede3c90754)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Create a common function for locating task manifest files rather than
several implementations with missing pieces.
(From OE-Core rev: 68150bac7444f089f19c789e9f6602d59f605d7a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
We need to use the meson.cross file when building for nativesdk.
Additionally, we need to trick meson's sanity tests, just as it is
done for target builds.
(From OE-Core rev: abcb330c462c2c06d36f8f3681a6bd07d562c1fe)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Explicitly depend on bison-native for deterministic builds, as it is required
for the build:
| HOSTCC scripts/basic/fixdep
| GEN ./Makefile
| HOSTCC scripts/kconfig/conf.o
| YACC scripts/kconfig/zconf.tab.c
| /bin/sh: bison: command not found
| scripts/Makefile.lib:217: recipe for target 'scripts/kconfig/zconf.tab.c' failed
In most cases, this dependency comes indirectly via toolchain dependencies,
specifically binutils-cross, which pulls bison-native. Different setups,
such as with external toolchain, would expose this problem, since correct
dependency is not marked explicitly.
(From OE-Core rev: d26b700553fe8fa21c2e42b04e11bb380d94ef36)
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The icecream native tools should not be included in uninative tarballs
even though it is nativesdk
(From OE-Core rev: fd87ebd7e8906e047620c2d4afa62337b5521e6f)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adds a version to the environment which can be used to invalidate any
previous environments on the remote compile nodes
(From OE-Core rev: 9bda79af100293ea3cb986dd501e0be028f2f04c)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes the case where ccache is enabled along with Icecream. In these
cases, there is the danger that Icecream will accidentally add the
ccache executable to the toolchain, which prevents it from working. In
particular, Fedora enables ccache by default via symbolic links in PATH.
(From OE-Core rev: 09ba173f56dcd7299a07d4dac3633fe7818f7282)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The binary 'cve-check-update' downloads the CVE database from the Internet.
If the system is behind a web proxy, the download fails, as proxy-related
variables are not exported.
In turn, 'cve-check-tool' does not connect to the network and correspondingly
does not need exported proxies.
Exported all proxy-related environment variables to 'cve-check-update' and
removed the unneeded export from 'cve-check-tool'.
(From OE-Core rev: 17db210975c740aff12732c511cf4fb32b507365)
Signed-off-by: Konstantin Shemyak <konstantin.shemyak@ge.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
While modern Linux kernels still support it, the userspace tools
haven't been updated in over a decade. Also, squashfs provides
both better performance, and better compression ratio:
https://elinux.org/Squash_Fs_Comparisons
(From OE-Core rev: 9443981d3934b366e39404719486d2b34d8a9d73)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Remove do_make_scripts() from module-base.bbclass and put
functionality in a recipe. This will build the scripts only
once instead of each time an external module is built.
[YOCTO #12228]
(From OE-Core rev: ea12c46fe8748fb6606c603d463075a8624e6563)
Signed-off-by: Joe Slater <jslater@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
All typos were in comments but some of these comments end up in run/log files.
The typos can be annoying when searching the log files so they're worth
fixing with ispell.
(From OE-Core rev: defffa3ba772d1643649591f6de96a4263570200)
Signed-off-by: Randy MacLeod <Randy.MacLeod@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Suppress any warnings git might generate when searching for a valid git
directory, as there are use cases where the directory is expected to not
exist and the warning is superfluous
(From OE-Core rev: 66011996e1a8b738b31466fccad9973f8b48f71d)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The code to extract the integer number of parallel build threads and
construct a new argument from them has started to be copied in multiple
locations, so create two new helper utilities to aid recipes.
The first helper (parallel_make()) extracts the integer number of
parallel build threads from PARALLEL_MAKE. The second
(parallel_make_argument()) does the same and then puts the result back
into a format string, optionally clamping it to some maximum value.
Additionally, rework the oe-core recipes that were manually doing this
to use the new helper utilities.
(From OE-Core rev: ccd1142d22b31ed85d8823b1bc9e11ccfd72b61f)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There's no point even looking in the database for these, so unset CVE_PRODUCT.
(From OE-Core rev: f47da3e91541d75e1213dd9cf1f89ed16f21141a)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For some recipes is is meaningless to do a CVE check, for example packagegroups
or images. Check that CVE_PRODUCT is set and short-circuit the scan if it
isn't.
(From OE-Core rev: d1e7cb5c9e0d5d253b6bb5c968fa58944ea42d06)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For reasons which I don't understand, the Berkeley DB tarball is version 5.3.28
but in CVE reports the version is 11.2.5.3.28.
To handle this allow recipes to override their version as well as their name.
(From OE-Core rev: 36fbf96cf284acbc810ff3bf00702f1f82bc0da9)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is where the other task logs go, so it's a sensible place to put it.
(From OE-Core rev: 4bbb8cd5f3943231ab5be0448d1b0d4a08341249)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
CFLAGS is unset during kernel_do_compile and thus the default build
path substitutions in DEBUG_PREFIX_MAP are missing.
To enhance reproducible build for kernel modules, such as lttng-modules
and cryptodev-module, this patch appends them, plus substitution of
STAGING_KERNEL_DIR, to KERNEL_CC.
(From OE-Core rev: ef7dac8511fc1647bc481c0e2ffa19e08e06f007)
Signed-off-by: He Zhe <zhe.he@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Icecream has a behavior that causes it to recompile files locally if gcc
generates any warnings or errors. The reason for this is that GCC tries
to re-read the input file in order to display the offending line with a
caret below it, which doesn't work in the remote chroot.
Default to disabling this this workaround and add
-fno-diagnostics-show-caret to the GCC flags so that errors and warnings
generated by GCC do not show erroneous results.
(From OE-Core rev: a1488291c5733a113c28475352eded61bf52bfe8)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If icecc is inherited, generated SDKs will automatically have optional
support for compiling using the Icecream distributed compiler
(From OE-Core rev: dea45ac88251b22b0b74dc4b3ba6ca13fe0b86d6)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Recipes can now install post-relocation scripts which will be run when
the SDK is installed.
(From OE-Core rev: 93ec145f421a45077b40ae99ee6a96bc11f91f18)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
icecc.bbclass will no longer attempt to distribute cross-canadian
compiles. While it is technically possible to generate a toolchain that runs
on the build system and generates executables for the host system, this
is not the normal way that icecc operates. There are so few of these
recipes that it is probably not worth maintaining a distinct code path
for them.
(From OE-Core rev: b8a39cf5884d4ab85e82c4437b81b5fbba06137e)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
STAGING_BINDIR_TOOLCHAIN is actually a path list, not a single path. Fix
icecc.bbclass to try all the paths in the variable instead of treating
it as a single path.
(From OE-Core rev: 8db0d3c14c166265b740030c208e0e19a0b2a1c6)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Generate the icecc toolchains in a shared work directory. This class was
already setup to correctly synchronize creating the toolchains in a
shared location before the RSS changes, so return to that behavior
instead of generated the toolchains in each recipe's sysroot.
Additionally, it makes no sense for each recipe to generate a toolchain,
only to find it was already generated and uploaded to the compile server
by another recipe.
(From OE-Core rev: 20a53ac7818f268d4a4c86c8f35ca982baf96acf)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There are cases where its useful to allow only a select few files
to be excluded from the package stripping mechanism. Currently
this isn't possible so add a variable to allow this.
This is to be used sparingly as in general the core code should be
doing the right thing. This is better than the alternative of leaving the whole
package unstripped.
(From OE-Core rev: 92845c65f8801de7dfa34c87b22ca2e66f18557a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
64 bit entry point should be passed in 2 literals ( "0x1 0x00008000"
).ENTRYPOINT is assigned with first half only and erroring out as
'command not found' for the second half. Adding quotes while assignment fixes the
issue.
(From OE-Core rev: e886c9c5e1a8ab28388a2e8bbb936ad5eea78615)
Signed-off-by: Vineeth Chowdary Karumanchi <vineethchowz.chowdary@xilinx.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The same thing can now be done with "bitbake <target> --runall=fetch"
or "bitbake <target> --runall=checkuri".
Dropping the tasks takes "bitbake core-image-sato -g" from 22s to 8s
since it no longer has to resolve the recursive dependencies (it
doesn't know if any given target will touch them or not until it
computes them). That is a significant enough win that its worth any
impact this may have on the small number of users using the tasks.
(From OE-Core rev: 8bbb43e948af45d0fa5ab31b456147f691fa2ec3)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some NPM modules have the same name as their low level dependencies.
To prevent recipe naming conflicts, allow node module recipe names
to start with the "node-" prefix.
(From OE-Core rev: 6b417c7c3a38463c64756beae9817fa2a80fd09e)
Signed-off-by: Zoltán Böszörményi <zboszor@pr.hu>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
npm cache clear throws an error with npm@5 and suggests to
use npm cache verify instead. But our cache is actually empty,
so use npm cache clear --force.
npm install in the source directory creates symlinks with npm@5.
Use a combination of npm pack and npm install module-version.tgz
that works the same way with older and new npm versions and is
guaranteed to create actual copies instead of directory symlinks.
This change allows using nodejs 8.x LTS, tested with 8.9.4.
(From OE-Core rev: 2d7d2a460842c8747df17990970f22f4a11f36f6)
Signed-off-by: Zoltán Böszörményi <zboszor@pr.hu>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
waf requires that the current working directory be the project root (in
this case ${S} when it is invoked. The check to get the waf version was
being executed as a prefunc for do_configure, which meant it was
executed before the current working directory was switched to ${S}, and
thus would fail with some recipes. Fix this by changing to ${S} before
executing "waf --version"
(From OE-Core rev: aa168ee7f785ff007ca645db57698883922b5eb3)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If --numeric-owner is neither used when creating or extracting the archive
containing the rootfs then tar tries to change the numeric uid/gid of the
files based on user/group names of the host used to extract the archive.
Create the archive with --numeric-owner to remove the burden of having to
use --numeric-owner when extracting.
(From OE-Core rev: 061e04cb6335a10f560e57255b7335b8c9891207)
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This allows catching errors in the scriptlets which would otherwise
go unnoticed, e.g. this sequence:
====
bogus_command
proper_command
====
would work just fine. Note that this patch needs all of the preceding
patches, as otherwise running failing scriptlets with -e would defer
them to first boot, instead of properly reporting failure and aborting
the package installation.
(From OE-Core rev: 3cd8a55d5298ce9cc176e402fdb727abb26a1a4c)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This function is a convenient and more readable shortcut for situations
when the postinst code always needs to run on target. All commands that
cannot be executed during cross-install and can only be run on target
should go into this function. They will only be executed on first boot
(if package was cross-installed) or immediately during package installation
on target.
Plain pkg_postinst() works as before: it is run during cross-install time,
it can contain a request to defer to first boot, and it is also run
during package installation on target.
Also fix the oeqa test for this functionality to use the new function
where appropriate.
(From OE-Core rev: 229f4e975fb6957f44b5c56735fd6d58564098d7)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These base_* functions were moved into meta/lib/oe back in 2010 and wrappers
left in utils.bbclass for compatibility. It's been eight years, so I think it's
time to remove them.
(From OE-Core rev: 0391fcad9103abca0796a068f957d0df63ab4776)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These functions were moved to meta/lib/oe in 2010 and the base_* functions in
utils.bbclass were intended to be a short-term compatibility layer. They're
still used in a few places, so update the callers to use the new functions.
(From OE-Core rev: c97acbd034532895ce57c6717ed1b3ccc7900b0d)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Remove hardcoding c/c++ compiler to be gcc alone, its
possible to use clang as replacement for cross compilers
from meta-clang, therefore set clang/clang++ if
TOOLCHAIN = "clang"
(From OE-Core rev: 05789489d25a5ceac0403613ad789d78198be6ee)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The RPM packages contain BUILDHOST based on the current build host.
This breaks reproducibility if the same package is build on two different hosts.
To improve reproducible builds, we always set BUILDHOST as "reproducible".
(From OE-Core rev: f3beb683380ec0d9efa0d6af83205350afd1b2de)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The requirement for images being built using RPM is too strict to have access to
the RPM functions, simply checking that package_rpm is in PACKAGE_CLASSES is
sufficient.
Also fail if SRPMs are requested but package_rpm isn't enabled, instead of
silently not doing what we were asked.
(From OE-Core rev: cdae5c41e4f67a8757efc5ce1ef11d730edc3af1)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
(From OE-Core rev: 3e4ddeab65d4d2e4aaf03d442c2a1a8c7a2ce8a2)
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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]
(From OE-Core rev: fd2678190db6575dc909104b60c284d0c41f605f)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
RPM spec files don't distinguish between spec-level license and the primary
package license, so always output the License for every package (defaulting to
the recipe-wide license) and use LICENSE_${PN} if set for the primary package.
As the primary use of package_rpm is to generate built packages, this fixes the
license fields in the generated packages.
[ YOCTO #12057 ]
(From OE-Core rev: 8c333e592fa7a3a887c792ac14e5cde2141b5d35)
(From OE-Core rev: 42e0de37d18f072dc5dcf5dc45cb441e4c2110d8)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The new name is much more consistent with what this actually means. We put
the pieces in place to rename everything a while back but looks like we
forgot to actually do it! Fix that now.
(From OE-Core rev: af9612f5d6b848fceea22d10ee964437299be776)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The f2fs filesystem is a newer flash filesystem that is available in
meta-filesystems. This needs a minimum sized blank space to operate
in correctly.
The f2fs has overprovision functionality and when building smaller
filesystems, you actually need more space, therefore under 500M (or so)
double the amount of space needed in order to handle the overprovision
functions in f2fs.
(From OE-Core rev: dec029686a47b574edfce4472fe2167db54398fb)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a dependency on xz-native and pass '-Z xz' to opkg-build to use xz instead
of gzip when building packages.
(From OE-Core rev: b95b6ba1a2959e2294a8848fa35f20163388eb06)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: ce6337ab4b415ee18360dfe4443a71ab75a60254)
Signed-off-by: Zumeng Chen <zumeng.chen@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The repository indexes updated during do_populate_sdk_ext and do_populate_sdk
can conflcit. Add the missing lockfile calls for deb/ipk and in the rpm case,
ensure different directories are used for the index for the two sdk cases.
(From OE-Core rev: 5e5569c962c9ebc898eeb5044214e95117b190e1)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: 792cfbab488782a7bd610fc2078077d5497be4d1)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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]
(From OE-Core rev: 77144bc808be02deb3351c9c1bf5b4f2b8c3a6ec)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This changes the cmake class to use Ninja instead of Make by default.
If a recipe is broken with Ninja then the recipe can set OECMAKE_GENERATOR="Unix
Makefiles" to change back to Make.
(From OE-Core rev: bacaa26decb8a1e3fa672e1923954793fde48766)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add OECMAKE_GENERATOR variable to control which generator is used by CMake,
defaulting to the upstream default of Unix Makefiles for now. The other
supported option is Ninja, which is faster than Make for large projects (for
example, using Ninja takes three minutes off webkitgtk:do_compile for me).
(From OE-Core rev: 6e3f719076cab469f56cd1555bd219a5c3fd135d)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, we include MESON_C_ARGS in write_config[vardeps], but we
don't include MESON_LINK_ARGS, which also affects meson.cross. In
addition, we include TOOLCHAIN_OPTIONS, from which both are derived.
Add MESON_LINK_ARGS, and remove TOOLCHAIN_OPTIONS, which does not
directly appear in meson.cross and should be pulled in indirectly by
MESON_C_ARGS and MESON_LINK_ARGS.
(From OE-Core rev: 4db37cc8d9139076682e2528d29e92fad2eb1c90)
Signed-off-by: Martin Kelly <mkelly@xevo.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, CFLAGS and CXXFLAGS are not making it into the compile line.
This is because meson appends CFLAGS/CXXFLAGS from the environment only
for native but not for cross builds (probably to keep cross-builds more
isolated). As a result, we need to make sure these vars goes into
meson.cross. This is similar to what cmake.bbclass does with
OECMAKE_C_FLAGS and OECMAKE_CXX_FLAGS.
Change c_args and cpp_args in meson.cross to include these vars, and
update write_config[vardeps] accordingly.
(From OE-Core rev: f435d1b75d3775f6ec0df6027766008b40209fd7)
Signed-off-by: Martin Kelly <mkelly@xevo.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
OE manages all the compile flags, so we don't want meson to inject its
own flags. Currently, it's injecting -O0 and causing build breaks when
security flags are enabled (because _FORTIFY_SOURCE requires an
optimized build and meson defaults to a debug -O0 build).
Add --buildtype plain so meson will not add its own optimization flags.
(From OE-Core rev: 73ff85986d82c8da601d7c7cf9a02961f2f66a09)
Signed-off-by: Martin Kelly <mkelly@xevo.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The 3.10.1 version has been in Dec 13, 2017, and has a great set of
features and improvements since the last upgrade.
The release notes of 3.10 release is available at:
https://cmake.org/cmake/help/v3.10/release/3.10.html
Patches updates:
- cmake-Prevent-the-detection-of-Qt5.patch: so it replaces the sed
command calls inside the cmake.inc
- 0001-FindCUDA-Use-find_program-if-find_host_program-is-no.patch:
merged upstream, so it has been removed.
- support-oe-qt4-tools-names.patch: rebased.
License-checksum-change: added new contributors
(From OE-Core rev: 9e58926f1cea9d5cb18cb923855d1ae98f88a8ac)
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In the case of a fitImage the this step should be done on the
image use to assemble the fitImage.
(From OE-Core rev: a061c6bfd3a049a2c8d14bcfafd6e1837afb95e5)
Signed-off-by: Thomas Perrot <thomas.perrot@tupi.fr>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The older style calls (plus a bashism in kernel.bbclass, fixed
separately) were introduced via the recent change to add support for
multiple kernel packages:
http://git.openembedded.org/openembedded-core/commit/?id=6c8c899849d101fd1b86aad0b8eed05c7c785924
(From OE-Core rev: e660ef68de3b3891a26ed6e10d96dc4efaf03ffc)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The "oldnoconfig" target has been supported since Linux 2.6.36.
According to OLDEST_KERNEL, the oldest kernel currently supported by
OE is 3.2.0, so the fallback to yes '' | make oldconfig is no longer
required.
(From OE-Core rev: 6abee5468e05333fbd9bd5ac8fc203a749ae3b3e)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This code is old and was of it's time, rewrite it to use modernish (we support
Python 3.4, so can't use subprocess.run()) subprocess and re idioms instead.
(From OE-Core rev: 8f7fdab41b8d6aced6753920bb5deed147c9baa8)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The existing code is looking for libraries in all paths which end in ${libdir}.
This caused false-positives for recipes such as lz4 which had files called
/usr/lib/lz4/ptest/usr/lib/liblz4.so, and resulted in lz4-ptest being
incorrectly renamed to liblz4.
Solve this by explicitly looking for ${libdir} etc under the packages-split
directory.
(From OE-Core rev: 7b1896f6f5367010b54c6a8b300db84037734533)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Don't hardcode the targets used in do_compile and do_install, instead build
"all" and "install" by default but respect OECMAKE_TARGET_COMPILE and
OECMAKE_TARGET_INSTALL variables.
(From OE-Core rev: 806765ec466597d38231d4be303cb48c26e21466)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In line with the other gettext cleanups, drop the nativesdk-gettext dependency
as it isn't needed (similarly to the previous target gettext dependencies).
This then means we can drop DEPENDS_GETTEXT as there are no other users.
(From OE-Core rev: c43c054cb778e0c5c082996cd6e6c45f5fc9e1bf)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
possible bashism in run.do_install line 163 (should be 'b = a'):
if [ "kernel" == "kernel" ]; then
Fixes "[: kernel: unexpected operator" when not using bash by default,
which causes the default kernel image link to not be created.
(From OE-Core rev: 9d82fffd24742a5eb40bcb9b9ecea01a42be0be6)
Signed-off-by: Ricardo Salveti <ricardo@opensourcefoundries.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We usually forcibly delete any gettext macros we come across to ensure that the
latest versions we ship are used, but if we're building gettext then it's a bad
idea to delete the gettext macros.
Historically this hasn't been a problem as the top-level gettext configure
doesn't use AM_GNU_GETTEXT so the deletion was never done, but this may change.
(From OE-Core rev: f16657df977e54210774812d4e616403c76eb060)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Using TARGET_CC_ARCH is inconsistent with CC, which uses HOST_CC_ARCH, and the
rest of meson.bbclass, which uses HOST_PREFIX, HOST_OS, etc.
(From OE-Core rev: 8a61e0c0c53275ebc623296f46676d920b11eb3b)
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
ARM specific TUNE_PKGARCH renaming was adding in 2011 handle the
transition from armv7a -> armv7a-vfp-neon:
http://git.openembedded.org/openembedded-core/commit/?id=08c0b7060009113e8dffdef51ff6b9b4b7f28894
Active package feeds should now have long since updated to the new
naming. For example, Angstrom stopped using on the legacy naming in
2012:
2e33fb5bd0
(From OE-Core rev: 0341a3c44e511d3246096edd3009432805e57b89)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Make 'wic' image creation tool/command available in eSDK
environment. This would allow eSDK users to manipulate
images within eSDK environment.
[YOCTO #12177]
(From OE-Core rev: 90df6758a9f8753c646b129aa912e3849bf4c987)
Signed-off-by: Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Using host gpg has been problematic, and particularly this removes
the need to serialize package creation, as long as --auto-expand-secmem
is passed to gpg-agent, and gnupg >= 2.2.4 is in use
(https://dev.gnupg.org/T3530).
Sadly, gpg-agent itself is single-threaded, so in the longer run
we might want to seek alternatives:
https://lwn.net/Articles/742542/
(a smaller issue is that rpm itself runs the gpg fronted in a serial
fashion, which slows down the build in cases of recipes with very
large amount of packages, e.g. glibc-locale)
Note that sstate signing and verification continues to use host
gpg, as depending on native gpg would create circular dependencies.
[YOCTO #12022]
(From OE-Core rev: 08fef6198122fe79d4c1213f9a64b862162ed6cd)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: 6b25c76da51180da7c97308d5f8f5558c68cdca3)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: 087510795331fa21ff52f103269087c06b1660fa)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When we migrated rpm v5 -> v4, we lost the ability to drop "per file"
dependencies from the rpm backend for things like "/bin/bash" and
"/usr/bin/env" which meant the sdks were becomming 'bloated'.
This restores the functionality using a dummy package, similarly to
the way the buildtools perl issue was addressed. It also removes
the non-functional old code so as not to confuse people in future.
I ran into this problem trying to filter dependencies to only rpms
a build directly depends upon and it turns out we have some determinism issues
in this area so this is something key to fix.
(From OE-Core rev: 9d490dc01dcedb216129b22cbe17a6c99efc4f5c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We can end up with / in dependency names from file dependencies but the
deb format doesn't allow this. Filter the names to allow such dependencies
to work. Names have to start with an alphanumeric digit so also handle this.
This allows for future handling of "per file" dependencies similarly to
the rpm backend, bring parity to the functionality of the backends.
(From OE-Core rev: fc08972688d784f561c8be88d3100d6baaf22070)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
DEPENDS_GETTEXT defaults to gettext-native, so there's no need to set it again
in these classes.
(From OE-Core rev: 5e4b1915e7a5a94d410c5292b5ed2f447c82b18a)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: d91dc4666683a96e9d03cbbd21b8a546f9069c93)
Signed-off-by: Mike Crowe <mac@mcrowe.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It is duplicated to previous.
(From OE-Core rev: 1309b800fbc48bc6a3b7864eb7827b24f855ddac)
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
(From OE-Core rev: 38df1653da65a8a4e5f84b369b699307d5b4fc4f)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(From OE-Core rev: 52f121a726da573c90e5857caff95e50b01ea02a)
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.
(From OE-Core rev: 32126512349d65f0dbc31196c4ec6e1a1147cf5e)
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"
(From OE-Core rev: 65b2a0e1ba7e176f3e405ed8968665660fc414d3)
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.
(From OE-Core rev: de30b61b87047f61de4629f8e5bd87598de7fd0c)
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.
(From OE-Core rev: 2c27df943035b4df7c5d0be1ab8d0f4f3a31f4d2)
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.
(From OE-Core rev: de7ae028c65a978969b2e06fdc1a2d08bc141a5b)
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.
(From OE-Core rev: 32c2faf394ba7bf75a7273fb9f5e58cc4ee3f3ad)
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.
(From OE-Core rev: 225a7156d1fb2fbffadf38e4f4e491f053358082)
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.
(From OE-Core rev: f57feab2727dca916744deb64825f3beaf07961d)
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).
(From OE-Core rev: 1f8dea686cdfd6d360ba4a97f62d274c39eaeb8e)
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.
(From OE-Core rev: b241a666f2867ffa425f6d43763d7c3c17941dcf)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The "ls -s sparse_file"'s result is 0, use stat to replace of it.
(From OE-Core rev: 1b2ec7a04069a0af2d4164c24109a5fa2fd0b1f6)
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
(From OE-Core rev: 4e0903e2f71658d595ccb1fa9dddf0f73b373f7e)
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.
(From OE-Core rev: 4b4a1295b8476d2820935eb5661b2d24a49b29b2)
Signed-off-by: Daniel Díaz <daniel.diaz@linaro.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
More information about ARM64 ILP32 can be found here:
* https://wiki.debian.org/Arm64ilp32Port
* https://wiki.linaro.org/Platform/arm64-ilp32
(From OE-Core rev: 4e8840aa7adf91f04da2a1947b8d1dff7f88df50)
Signed-off-by: Daniel Díaz <daniel.diaz@linaro.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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
(From OE-Core rev: 3a599e9d9df4aee25b6aa887563ef833559d96f8)
Signed-off-by: Daniel Díaz <daniel.diaz@linaro.org>
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
(From OE-Core rev: d14adead5861007ac7e95c32396491f907ab9f8f)
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>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: eee3ec805cf150f1c701427a2d182a537a67e8f5)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It's a problem when initramfs is invalid, so print warn rather than note.
(From OE-Core rev: e164f931c8b3046a8b6736166f8dd6d92f727d1c)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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#114122http://lists.openembedded.org/pipermail/openembedded-core/2017-July/thread.html#139130
[YOCTO #11363]
(From OE-Core rev: 6c8c899849d101fd1b86aad0b8eed05c7c785924)
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>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: 923f91d8d8606141ce218927bc943f4f4f34bcdd)
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: 59f1ee104d1a6c04b0690b7c8ce481449da174d6)
Signed-off-by: Mike Crowe <mac@mcrowe.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: 2781e8d608c0fd2108aeab294f982e9249793852)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
(From OE-Core rev: f387c28640cbb209b8a8ed5734b21c754d9f7663)
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]
(From OE-Core rev: 0f537d985b7b17af508a511fca8a4ec4b5804580)
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]
(From OE-Core rev: 978472c58629d1448399207873bbead96b27102e)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: de2f2fc9e8e6d874a11e69adc2f438975a5c1359)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
So that both QEMU_USE_KVM = "True" and "1" will work.
[YOCTO #12343]
(From OE-Core rev: f28890ae2eb8a9cb2da39588e696a4b0c501bdf0)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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
(From OE-Core rev: c350812523017f113f63e0b863fd526b4d6331b9)
Signed-off-by: Tim Orling <timothy.t.orling@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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]
(From OE-Core rev: a24c10b7bdab8aa960fdd3a58d2009f24344e579)
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.
(From OE-Core rev: ced4ac760926ce43a937dad2be3b873b1beec6aa)
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.
(From OE-Core rev: 7e98c295c1bb511ece51b5f8c97f26c173ddaf76)
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]
(From OE-Core rev: 44ff06635e7f575e67b7ebba5d6900b8ddbc4a06)
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>
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]
(From OE-Core rev: b63cc051f1eb58c768f49db2c04843336e62d3df)
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>
If there are many recipes that should be cleaned out from the
sysroots, it can actually take some time. This adds a progress bar to
give a visual clue that the clean up is actually progressing.
(From OE-Core rev: d9b59df1230a20c7a5c9f4fb0325bb9216025a16)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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).
(From OE-Core rev: bfd9664edad7044b5da53fc33b8d0f6508f00950)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We depend on the host GNU patch, but patch < 2.7 can't handle git-style patches.
This results in patches that fail to apply, or worse apply incorrectly.
(From OE-Core rev: ddda57ab1dee989dce8754350471807c916a6f47)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This code is an error path so nobody noticed that oe.utils.getstatusoutput() is
just a wrapper around subprocess.getstatusoutput() which returns an (int,
string) pair not (string, string).
(From OE-Core rev: 33bf6e05af0a68da32f0484460b1de5f7f4eea98)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a bug is present or the user has set PATCHTOOL = "git" on a source
tree that isn't git, if we try to perform git operations (such as
committing or changing branches) when extracting source, then we might
in fact be running those operations on the metadata repository if the
build directory is underneath, say, poky or OE-Core, and that could
make a mess. Check if the source tree is a git repository and refuse
to continue if it isn't.
(From OE-Core rev: 59ae5b7cbfeedb216a57c3f77fe52527b6c918cc)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
