Fixes the following warning sometimes appearing during image builds:
WARNING: The license listed ABC was not in the licenses collected for recipe xyz
The files being looked for here, which runs during do_rootfs,
are written out by the do_populate_lic task for each recipe. However,
there was no explicit dependency between do_rootfs and all of the
do_populate_lic tasks to ensure they had run - only an implicit link via
do_build, so it is possible that sometimes they had not depending on how
the tasks were scheduled. Add an explicit set of dependencies to fix
this.
(From OE-Core master rev: ef7dc532e800d9b170246550cbc8703adf624beb)
(From OE-Core rev: f521d8d2d1ea495383f54e5e7c2754dde007f7eb)
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>
Fixes the following error showing up for layers that aren't a git repo
(or aren't parented by one):
fatal: Not a git repository (or any of the parent directories): .git
This was because we weren't intercepting stderr. We might as well just
use bb.process.run() here which does that and returns stdout and stderr
separately.
(This was a regression that came in with OE-Core revision
3aac11076e).
Fixes [YOCTO #8661].
(From OE-Core master rev: f533c1bf4c6edbecc67f9e2c62fd475d64668e86)
(From OE-Core rev: 8968ede9c8cdcd2cbf13bd5bba95883082189908)
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>
We weren't splitting SRC_URI values containing multiple URIs here; this
didn't cause any errors except when a trailing ; was left on a URI, in
which case the next URI was considered part of the parameter, which
didn't contain a = and therefore was considered invalid.
We only care about the first URI in SRC_URI in this context (since
that's the upstream URI by convention) so split it as we should and take
the first item.
Fixes [YOCTO #8645].
(From OE-Core master rev: 8e75b7e7d54e5638b42b9e7f90f2c6c17e62033f)
(From OE-Core rev: a28eba9fb03720c805eae02c3d0aebf9294e300b)
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>
Previously UNINATIVE_LOADER was always ld-linux-x86-64.so.2. That is
incorrect when the host is 32-bit.
This change also changes to using ?= so the user can override
UNINATIVE_LOADER if so desired.
[YOCTO #8124]
(From OE-Core master rev: b78fa0bcadd54bb29b6f1bb3a9308d4c454bf4e2)
(From OE-Core rev: b901a3057ff511f4c8bc730b37b967a93995de2f)
Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
TARGET_CPPFLAGS, TARGET_CFLAGS, TARGET_CPPFLAGS and TARGET_LDFLAGS may
differ between MACHINEs. Since they are exported they affect task hashes
even if unused which leads to multiple variants of allarch packages
existing in sstate and bouncing in the sysroot when switching between
MACHINEs.
allarch packages shouldn't be using these variables anyway, so let's
ensure they have a fixed value in order to avoid this problem.
(Compare with 05a70ac30b37cab0952f1b9df501993a9dec70da and
14f4d016fef9d660da1e7e91aec4a0e807de59ab.)
(From OE-Core rev: 16482cf042e129e8f429bdcea9c0c9addb0e8a0b)
Signed-off-by: Mike Crowe <mac@mcrowe.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch removes errornous extra path-specs from cpan_build.bbclass
because corrected path specs at build time are enough.
* fixes wrong path used when building using Module::Build toolchain
(From OE-Core rev: bb59eb410c716057190fb0d115ef85b2c12e6518)
Signed-off-by: Jens Rehsack <sno@netbsd.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch fixes some issues in classes providing cpan module build support:
* add support even for xs modules with more than 3 levels as
B::Hooks::End::Of::Scope or Math::Random::ISAAC::XS
* correct handling of Module::Build (as far as stolen from pkgsrc
and my humble knowledge)
* configure to install to vendor_libs as default, even when
inherited do_install remains unused (overwritten do_install)
(From OE-Core rev: 6948d2bd35cda57f520f0180a6bb43cc70262f41)
Signed-off-by: Jens Rehsack <sno@netbsd.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The intercept runs against the native sysroot so we need to pass it
the native libdir instead of the target libdir, as otherwise it will
use target paths (such as lib64) in the native sysroot.
(From OE-Core rev: 0fe84007176c98644b1917966c98501beb7e0ce2)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Before, the users and groups specified in the passwd file and the
groups file had to have trailing colons to make sure there were enough
elements in the definitions, or bitbake would throw a Python
exception. After this change one can omit the trailing colons, which
especially simplifies passwd files used only to specify static UIDs.
(From OE-Core rev: 7754e0f71eb794f0e06a1b005e3824fac4cdac6c)
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>
The intercept doesn't need STAGING_LIBDIR_NATIVE anymore, so don't pass it.
(From OE-Core rev: 189d6232a2a9eb7192887b60f05b6643414a4ec6)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now that file-native is ASSUME_PROVIDED, check that it's actually present.
(From OE-Core rev: 5dad6758980233f976e39357b91b9cc673a574af)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The code assumes that PKG_DATADIR exists and will fail if an image has not been
generated which creates it. This occurs when something like buildtools-tarball
is built which doesn't have target packages, only nativesdk ones.
Since this shouldn't be fatal, workaround this by creating the missing
directory.
(From OE-Core rev: 319c5d55bb0c7e429766f46dd42a15e16a43c4dd)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The PACKAGES is not mapped with MLPREFIX when setting LICENSE_EXCLUSION
in base.bbclass. For example,
For libgcc-dev,
LICENSE_EXCLUSION-libgcc-dev=1
but for lib32-libgcc-dev,
LICENSE_EXCLUSION-libgcc-dev=1
Obviously it is wrong for lib32-libgcc-dev.
Add MLPREFIX before the package name during setting LICENSE_EXCLUSION
(From OE-Core rev: 6597130256a1609c3e05ec5891aceaf549c37985)
Signed-off-by: Jian Liu <jian.liu@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Automatically export public key(s) of the signing key(s) from the gpg
keyring. Adds a new simple recipe that does the actual task of exporting
the keys. This patch makes the RPM_GPG_PUBKEY and PACKAGE_FEED_GPG
PUBKEY settings obsolete.
(From OE-Core rev: 23b30c34581948e1ea02c25cbf7b9194d7e49fb8)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
After this change signed package feeds should be enabled by adding
INERIT += "sign_package_feed"
instead of definining PACKAGE_FEED_SIGN="1".
(From OE-Core rev: 2ba901da9a07350cc8975fc951ef5054b32d421b)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Simplifies the configuration. Makes way for the removal of
RPM_GPG_PUBKEY setting and possible future implementation of a separate
signing server support. Also, moves the configuration sanity checking
into a separate function.
(From OE-Core rev: 6ea062dffce3df59cc4ba88edd181dc1dac759f9)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This bitbake configuration variable can be used to define the gpg home
directory.
(From OE-Core rev: 7ea2f8aca832433f448a79d103c945a63ac6474b)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Before the fetcher validated the specified SRCREV was reachable on a
specified branch, linux-yocto style kernel's were comparing the value
of KBRANCH and branch on the SRC_URI and then allowing a SRC_URI
specified branch to override KBRANCH.
With the introduction of kernel meta data on the SRC_URI, this routine
is incorrectly picking up a kernel-cache repository and then attempting
to apply that branch information to the kernel repository.
The rationalization of the branch specification is largely no longer
required, and will may be removed in the future. But for now, to keep
changes minimal, we can simply not return branch information that comes
from kernel meta data by checking the 'type' parameter and skipping
if it is of type 'kmeta'.
(From OE-Core rev: 87363ec019e04b486dee5f07b7226465be7acd6c)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
gcc packages use a shared source directory, this causes an issue since the archiver will
try to patch the same source several times (one for each gcc package), producing an error,
the archiver class used stamp-base to check this, nonetheless our gcc packages no longer
use stamp-base, they use gcc-shared instead, which is what broke this functionality.
This patch adds a check to see whether or not the source should be patched,
avoiding patching the source when it shouldn't.
Also, we dont need to create multiple identical tarballs for all gcc packages,
this patch fixes this and creates a single source tarball for gcc.
When requesting patched sources, a race condition is created for linux-yocto tasks,
unpack_and_patch is executed along with kernel_configme, which most of the time
causes errors during configure, since kernel_configme task is specific to the kernel,
simply modifying the tasks order by creating a dependency to kernel_configme was impossible,
causing errors on all other packages that didnt use kernel_configme, this is fixed by
creating a special case for the kernel, adding tasks with correct dependencies,
avoiding the race condition and behaving the way it should for all other packages as well.
[YOCTO #8378]
(From OE-Core rev: aecaa0e8739db1c228a6db78225a717d9f348a5b)
Signed-off-by: Alejandro Hernandez <alejandro.hernandez@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In c0da4270c76375a7a8cbcc09319fe4570ebbc5bd two bbwarn were changed to
bbnote for the case where an added user or group already exists. The
same should have been done for groupmems, groupdel and userdel as well
since the warnings that are currently generated are superflouous.
The two remaining similar bbwarn for groupmod and usermod are left as
is since there they actually make sense.
(From OE-Core rev: f775e4cffe45edb673a414a2038c4f2b09b9b827)
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>
Building nativesdk-glibc-locale results in many messages like:
QA Issue: nativesdk-locale-base-en-sg rdepends on localedef, but it isn't a build dependency? [build-deps]
It should depend on ${MLPREFIX}localedef, not just localedef
to fix these warnings.
(From OE-Core rev: 80e2dfbfef2d40c3ab074142deac73317f89e3a2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you run the extensible SDK environment setup script in a shell
session where oe-init-build-env has been run already, and attempt to use
the two together, strange things happen - you may not even be running
devtool from the extensible SDK, but the OE tree. This isn't a supported
use case anyway, so show a warning recommending starting a new shell
session.
(From OE-Core rev: 41afc48ab979dff6ebb3ea4003dd6baefff7f644)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Print a note at the end of the environment setup script pointing to
devtool.
(From OE-Core rev: ea1d566bc2ff61f2e086effb9ca6551b263eacbe)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In order to prepare the build system within the extensible SDK, we
actually go ahead and build the targets specified by SDK_TARGETS (by
default the image the SDK was built for). Assuming that's an image, we
don't actually need to build the image itself - we just need to have
everything done up to the point before building the image, so that we
have everything needed in the sysroot.
In order to do this, create temporary bbappends for each of the targets
in the workspace layer that stub out do_rootfs and related tasks if they
exist. This is a little bit of a hack but is the least intrusive fix at
this point. To make things a bit tidier, I have split out the
preparation commands into a separate script so we can run that in the
appropriate environment rather than all the commands separately.
Fixes [YOCTO #7590].
(From OE-Core rev: d2a2962897b89731a5705b0cbc7c6f36aa53dcc8)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Make indentation consistent here in preparation for the changes that
follow.
(From OE-Core rev: 59a3789c678bf58c0a04b8def416246654680841)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Commit 771f89498c introduces an error message that is very rarely hit and
when it is, it is usually easy to trace the root cause very quickly. The
information provided in the error message isn't enough to lead you back to
the actual failure, however, so expand upon it a bit, pinpointing the
specific package and flag that fails.
(From OE-Core rev: ead4a552464309e6ef3381590994b6cea225ca20)
Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The code to get the git and branch hash for the current commit in a specific
repository was quite complex and prone to breakage, replace it with subprocess
and git rev-parse.
(From OE-Core rev: bd8ff33cf2439536c6e41cf0ee9dd8fb3b64770a)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
when we generate hddimage and use it to prepare SD card
using scripts/contrib/mkefidisk.sh as described here
http://elinux.org/Minnowboard:MinnowMaxYoctoProject
The content of startup.nsh contains
bootx64.efi
but this file is actually not in same dir as startup.nsh
its in /EFI/BOOT so for this to work entry in startup.nsh
should be
fs0:\EFI\BOOT\bootx64.efi
Otherwise the image is D-O-A
(From OE-Core rev: 38fe481911e7c4e9f674ded8f66878dff9e12ce3)
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>
cross-compilation warning from insane.bbclass is slightly misleading.
So, remove the misleading path from warning.
[YOCTO #7540]
(From OE-Core rev: fd0c6de410856ec42e20762163575f0efde44541)
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>
Currently error-report doesn't manage Unicode because
the files are opened with the default codec.
This patch changes the codec of the files to UTF-8,
this way the reports will include Unicode characters.
This is useful for the qemu output when doing the
testimage task.
[YOCTO #8225]
(From OE-Core rev: afb5308770de776181da5b44f9dc30922836bc38)
Signed-off-by: Mariano Lopez <mariano.lopez@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* this can be useful for passing extra parameters, pass
-v by default to see what's going on in do_rootfs
* we need to use this for extra parameter we implemented
in fontconfig:
--ignore-mtime always use cache file regardless of font directory mtime
because the checksum of fontcache generated in do_rootfs
doesn't match with /usr/share/fonts directory as seen on
target device causing fontconfig to re-create the cache
when fontconfig is used for first time or worse create
new cache in every user's home directory when /usr/
filesystem is read only and cache cannot be updated.
Running FC_DEBUG=16 fc-cache -v on such device shows:
FcCacheTimeValid dir "/usr/share/fonts" cache checksum 1441207803 dir checksum 1441206149
* my guess is that the checksum is different, because pseudo
(which is unloaded when running qemuwrapper) or because some
influence of running the rootfs under qemu.
(From OE-Core rev: e07fdc5f047f309a0e99331f430c14d708ed2161)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Modify do_install_ptest_base to run do_install_ptest and install the
Makefile irrespective of the presence of ${WORKDIR}/run-ptest. This
change allows "ptest-aware" packages to install run-ptest as part of
the make machinery.
(From OE-Core rev: 2055517d91e0c55ed108d3a6f52abd1d2c6824b2)
Signed-off-by: Ian Ray <ian.ray@ge.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Proxies defined in the enviroment where not taken into account
on the distrodata tasks. This commit implied passing the datastore
into the distro_check library and context manager for the
urllib.urlopen function.
One way to run distrodata tasks is using 'universe' as target and the
'all' distrodata task:
$ bitbake universe -c distrodataall
$ bitbake universe -c distro_checkall
$ bitbake universe -c checklicenseall
Logs are located under TMPDIR/log
[YOCTO #7567]
(From OE-Core rev: 7d1c3470bb06e43245ccb7f067121de606506430)
Signed-off-by: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Ross reported the following waring when building edgerouter BSP:
WARNING: Section not found: .comment
The reason is that the testing of the existing sections in do_strip()
returned the wrong value. Please see the following code in do_strip():
for str in ${KERNEL_IMAGE_STRIP_EXTRA_SECTIONS}; do {
if [ "$headers" != *"$str"* ]; then
bbwarn "Section not found: $str";
fi
"$CROSS_COMPILE"strip -s -R $str ${KERNEL_OUTPUT}
}; done
The "*" doesn't have special meaning in the if string test, so it will
return true even the $str is a substring of $headers. Fix this issue
by replacing it with "! (echo "$headers" | grep -q "^$str$")".
Reported-by: Ross Burton <ross.burton@intel.com>
(From OE-Core rev: 4965f122ca67c0ff60dc60f7885db1ed9db909b4)
Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The MACHINE variable is used to handle sysroot paths within one of the
patches to python3-native. In this context, it is relocation safe and
the resulting packages should not have MACHINE specific checksums,
therefore excluding MACHINE in this context is safe.
This whole setup is ugly and ideally we should come up with a better
way of handling this but at least allow a stop gap solution for now.
(From OE-Core rev: be4e6ea8a92bd90f354f8c04eade39ccce8b73d5)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This adds the markup to inform bitbake to rerun the deploy task per MACHINE.
This makes sense since DEPLOY_DIR_IMAGE contains MACHINE. Doing it this
way means the same artefact will be reused from sstate rather than rebuilt.
(From OE-Core rev: 4052e0858d72505728c2a746fac935bf281903fd)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
multilib task signatures turned out to have issues since
SIGGEN_EXCLUDERECIPES_ABISAFE and SIGGEN_EXCLUDE_SAFE_RECIPE_DEP
did not have multilib mappings. This adds those mappings in which
in turn improves multilib task checksums to match the standard
non-mulitlib versions.
(From OE-Core rev: ea872b735c92a30d03cfa32953e060430e6f7f0b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Just like we have in oe-selftest, you can add
<filename>.<Class>.<testname> in TEST_SUITES in order to
run just that test
(From OE-Core rev: 3bf5204315fedc586fdf641583cfdb2c1a78c5c0)
Signed-off-by: Lucian Musat <george.l.musat@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If building for a BE8 ARM target, arch is "armeb" rather than
"arm", but ABI should still be "gnueabi". Otherwise gcc won't
build.
(From OE-Core rev: d2e1cf176b2a705f3e4bd4ab7c35bb1de5dc6985)
Signed-off-by: Peter Seebach <peter.seebach@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When looking at and trying to build a slightly customised SDK, I
realised the code could be simplified and written in a way which was
more customisable.
This patch moves various function calls into the SDK_POSTPROCESS_COMMAND
which was intended for this kind of use.
(From OE-Core rev: baa4e43a29e45df17eaa3456acc179b08d571db6)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In the json file the whole datastore is serialized which contains
absolute path to the oeqa folder. This breaks the functionality
when trying to run the tests from other machines.
(From OE-Core rev: 94057ccc70aa3fe29d774f571a65f56fd1285d4c)
Signed-off-by: Lucian Musat <george.l.musat@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
