do_prepare_recipe_sysroot may perform groupadd, which requires pseudo.
However, do_prepare_recipe_sysroot does not depend on pseudo explicitly,
which sometimes causes a build error when building a recipe that adds
groups.
This issue only occurs when executing do_prepare_recipe_sysroot for a
recipe that adds groups before finishing a task that depends on pseudo
for a recipe that doesn't add groups.
(From OE-Core rev: 427320d7621846d57649af46bf57c88f86cac612)
Signed-off-by: Mattias Hansson <mattihn@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The use case is setting INCOMPATIBLE_LICENSE per image,
rather than as an awkward, and too strict global setting.
This for example would allow building development images with gplv3 tools,
but production images without them, and checking that nothing gpl3-licensed
gets into the latter.
Examples are provided via the selftest: four scenarios are tested:
- bash is added to the image, with a default gpl3 license; this is rejected
- bash is added to the image, with a "gpl3 & other" license; this is also rejected
- bash is added to the image, with a "gpl3 | other" license; this is accepted, but
only 'other' is added to the license manifest (this was already handled correctly
previously).
- bash is added to the image with a default gpl3 license, and is additionally
whitelisted for that image; this is accepted.
Eventually, this would allow deprecating the meta-gplv2 layer, while still
enforcing the no-gpl3 rule where possible and needed.
(From OE-Core rev: fd50395bc0783a3cce7b5b0d7398f22783ebbeca)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This would help with checking incompatible licenses at do_rootfs step
in image creation, where it is beneficial to pass the license string
directly to the function.
(From OE-Core rev: 8a0f342e4fc33b1aa53089b1de583d45d2951476)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
nativesdk builds such as nativesdk-dnf are installing systemd
service files, leading bitbake to throw installed-vs-shipped
warnings, but these are not needed in nativesdk:
WARNING: nativesdk-dnf-4.2.2-r0 do_package: QA Issue: nativesdk-dnf: Files/directories were installed but not shipped in any package:
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/systemd
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/systemd/system
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/systemd/system/dnf-automatic.timer
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/systemd/system/dnf-makecache.timer
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/systemd/system/dnf-automatic.service
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/systemd/system/dnf-makecache.service
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/systemd/system/dnf-automatic-notifyonly.timer
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/systemd/system/dnf-automatic-download.service
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/systemd/system/dnf-automatic-download.timer
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/systemd/system/dnf-automatic-notifyonly.service
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/systemd/system/dnf-automatic-install.timer
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/systemd/system/dnf-automatic-install.service
Please set FILES such that these items are packaged. Alternatively if they are unneeded, avoid installing them or delete them within do_install.
nativesdk-dnf: 13 installed and not shipped files. [installed-vs-shipped]
Rather than have each recipe remove the files, an RMINITDIR case
for nativesdk builds should be added to systemd.bbclass.
(From OE-Core rev: 86092fdac2ed2935b25a6c05f16055df77a10575)
Signed-off-by: Trevor Gamblin <trevor.gamblin@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The readelf binary is prefixed, so export READELF in the SDKs so that the
correct readelf binary can be used.
This fixes problems with the symbol extractor in Meson with multilib SDKs where
readelf can't be found correctly.
(From OE-Core rev: 2795e3bfdefc9f48294802ea7301dae1910553dc)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
perlocal.pod is an index file of locally installed modules and so shouldn't be
installed by any distribution packages. cpan.bbclass already sets NO_PERLOCAL
to stop this file being generated by most Perl recipes, but if a recipe is using
MakeMaker directly (such as rrdtool) then they might not be doing this
correctly.
To avoid multiple packages shipping this file and then failing to install
together, add a QA test to check if this file exists and by default emit an
error if it does.
[ YOCTO #13491 ]
(From OE-Core rev: 5d16d265cc61c4e279fe3bf66016a00d9daa4068)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* in oe-core commit 1860d9d3c62e2e94cd68a809385873ffd8270b6d I've accidentally
removed the backshash here
Reported-By: "Hilsdorf, Jan (LAWO)" <Jan.Hilsdorf@lawo.com>
(From OE-Core rev: 44f0047c0268f3e9f9fdf78f93bdad9bfe491174)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Turn:
ERROR: Unable to parse Var <OE_IMPORTED[:=]>
Traceback (most recent call last):
File "Var <OE_IMPORTED[:=]>", line 1, in <module>
File "/media/build1/poky/meta/classes/base.bbclass", line 35, in oe_import(d=<bb.data_smart.DataSmart object at 0x7f1d941ad208>):
for toimport in oe.data.typed_value("OE_IMPORTS", d):
> imported = __import__(toimport)
inject(toimport.split(".", 1)[0], imported)
File "/media/build1/poky/meta/lib/oe/sstatesig.py", line 267, in <module>:
>class SignatureGeneratorOEEquivHash(SignatureGeneratorOEBasicHashMixIn, bb.siggen.SignatureGeneratorUniHashMixIn, bb.siggen.SignatureGeneratorBasicHash):
name = "OEEquivHash"
bb.data_smart.ExpansionError: Failure expanding variable OE_IMPORTED[:=], expression was ${@oe_import(d)} which triggered exception AttributeError: module 'bb.siggen' has no attribute 'SignatureGeneratorUniHashMixIn'
into:
ERROR: Error importing OE modules: module 'bb.siggen' has no attribute 'SignatureGeneratorUniHashMixIn'
which can then trigger a version mismatch error message.
(From OE-Core rev: 5b01726d1cf478aba8d1acc73e29f6cab0c9371e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
packagegroups whose dependencies are affected by MACHINE_FEATURES
need to be marked as MACHINE_ARCH *before* inheriting the
packagegroup class, not after.
This has changed in commit 9c826962ec8f
("packagegroup: Make allarch inherit conditional"),
commit 4f3f34deaf in poky but the comment here
wasn't updated at the time.
(From OE-Core rev: 7eae2502936aa36401491cd1e0e5975db96529ae)
Signed-off-by: André Draszik <andre.draszik@jci.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Create bash-completion-pkgs image feature to load *-bash-completion packages
into an image. The packages are created by the bash-completion
bbclass but are currently never loaded.
(From OE-Core rev: d47c5981877555a5a6b9aeb93ea6f3c1aa97fc44)
Signed-off-by: Joe Slater <joe.slater@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We don't have a compiler, so no icecc.
Silences a spew of warnings of the form:
do_configure: Cannot use icecc: could not get ICECC_CC or ICECC_CXX
(From OE-Core rev: 0315aabeff8e6483b737d0e23d6841f1394ad3c8)
Signed-off-by: Douglas Royds <douglas.royds@taitradio.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Creates the source data epoch file destination directory when restoring
from sstate
(From OE-Core rev: f5259a62d444dfc221a9ba592dbca35564f794ac)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Write out the hash equiv cache file into any eSDK so that it doesn't rely
on having to call the hash server for the basic data requests.
(From OE-Core rev: 05c6842e747261b3350d6325e238429cf8728ca0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
set in the ramdisk node the compression property
always to "none", as U-Boot nowadays since commit:
b1307f884a91 ("fit: Support compression for non-kernel components (e.g. FDT)")
decompress non kernel components. Setting compression
to the used comression algorithm now, will end in
fail of your kernel boot with the ramdisk.
This issue is fixed since commit:
bddd98573465 ("fit: Do not automatically decompress ramdisk images")
which now prints a warning in U-Boot, instead of decompressing
the ramdisk, but we should setup compression property correct.
(From OE-Core rev: f963a51544a9a7b1abbaa87c95b3c0279847d697)
Signed-off-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The deployment of the source date epoch file had a race condition where
any task attempting to read from the file would race with creation of
the sstate archive for the do_deploy_source_date_epoch task. The
creation of the sstate archive requires moving the directory to a
temporary location, then moving it back. This means that the file
disappears for a short period of time, which will cause a failure if any
other task is running and trying to open the file to get the current
source date epoch.
The solution is to copy the source date epoch file to a separate
directory when deploying so the file never disappears. When the file is
restored from sstate, it is moved to the correct location after being
extracted.
[YOCTO #13501]
(From OE-Core rev: ac27d12fe5480e9b8cc93de6a32bf9631c52d7f4)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There's INITRAMFS_FSTYPES that can be set differently.
(From OE-Core rev: 141d02400696020e83df3edcf13021fde139d261)
Signed-off-by: Böszörményi Zoltán <zboszor@pr.hu>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In the case where multiple packages provide the same file, we show an error.
Otherwise, python will generate a different build depending on which provider
appears first in the dictionary. On my system this order changes every time
I run bitbake causing intermittent build differences.
Add a sorted() to fix the determinism issue too.
(From OE-Core rev: 61c41369003444bfbf1c45e7cfd2752a4b7bc22f)
Signed-off-by: Jonathan Marler <johnnymarler@hp.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It should have been removed in 3db9d865 (classes/package_rpm.bbclass:
Enhance diagnostic messages) when it was split in two new notes.
Also change the casing of two other notes to align them with the other
notes.
(From OE-Core rev: b40e245795cd19c7d36df096fa1f30c75490ce46)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
externalsrc do_configure task watches oe-devtool-tree-sha1 file and its
checksum. That file basically contains the result of `git add -A
${EXTERNALSRC} && git write-tree` which is the hash of temporary
"commit" of the non committed changes. This file is stored in the .git
directory of the git repo of the externalsrc recipe. do_configure then
depends on the checksum of oe-devtool-tree-sha1 file.
If 2+ recipes with different externalsrc paths but same git repo (e.g.
one recipe at /some/path and the other at /some/path/subdir) are parsed,
this oe-devtool-tree-sha1 will be overwritten by those recipes at
parsing time since .git is shared between those recipes.
If there is one non committed git change in /some/path but not in
/some/path/subdir, the oe-devtool-tree-sha1 of both recipes will be
different.
What will happen is that recipe1 will watch over the
oe-devtool-tree-sha1 with a specific checksum, fill in file-checksums
for do_configure correctly, then recipe2 will watch over the identically
named file with different content also fill in the file-checksums
varflag. When do_configure of recipe1 will be evaluated for
re-execution, oe-devtool-tree-sha1 will be of the value of what is
watched over by recipe2, thus triggering a rebuild of recipe1.
This behavior is not always reproducible which I'm guessing is due to a
small window between recipe1 putting info into oe-devtool-tree-sha1 and
calculating the checksum of that file and recipe2 putting its content
into oe-devtool-tree-sha1.
By appending the name of the recipe to oe-devtool-tree-sha1, we make
sure that a recipe won't have its oe-devtool-tree-sha1 overwritten by
another recipe sharing the same externalsrc git repo.
(From OE-Core rev: 1b727dd7295a7a7fe17800f8038242efbf7fe2b7)
Signed-off-by: Quentin Schulz <quentin.schulz@streamunlimited.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When doing a devtool build-sdk from within an esdk all nativesdk
components would be rebuilt. This patch introduces SDK_INCLUDE_NATIVESDK
flag to toggle the inclusion of nativesdk packages when creating the
esdk sstate
Currently locked-sigs.inc is generated during do_sdk_depends which
doesn't pull in nativesdk packages. Generating another locked-sigs.inc
in do_populate_sdk_ext and pruning it to only nativesdk* packages by
using a modified version of the already existing function
prune_locked_sigs and merging it with the current locked-sigs.inc
Also adding SDK_INCLUDE_NATIVESDK tasklistfn to the logic surrounding
setting tasklist file to not prune esdk sstate during creation
[YOCTO #13261]
(From OE-Core rev: d046afd12e1c209b29dca6ba402b9aa14680c5ce)
Signed-off-by: Jaewon Lee <jaewon.lee@xilinx.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When archiving patched source, WORKDIR should only be changed to
${ARCHIVER_WORKDIR} if the recipe doesn't use a shared work directory.
This matches the behavior of do_unpack_and_patch for these recipes.
This fixes kernel recipes that set S = "${WORKDIR}/git"
(From OE-Core rev: e3caee8f86f2cca1d052f1f1b233018a3d4baa97)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Check that /etc/gconf exists before trying to find files under it, to avoid
writing find error messages to the rootfs log.
Also use ${sysconfdir}/gconf instead of hardcoding /etc/gconf.
(From OE-Core rev: 70a77b91031388ea29eff6b8885fd25cc35b1dae)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
sometimes, it is not enough to reproduce a failed build with current
info on error reports web, add local.conf/auto.conf into error
report to make it more easier to reproduce failed build
Note: this need work together with change in repo error-report-web,
which will display local.conf and auto.conf as Error Details
[YOCTO #13252]
(From OE-Core rev: 7adf9707c04d8ef6bcd8d8bda555687f705e6ee6)
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Define common functions for populating EFI directories in live image by
reusing common code from grub-efi and systemd-boot bbclasses.
(From OE-Core rev: 3728899a0cd543793db258da0976362b4bde7133)
Signed-off-by: Dmitry Eremin-Solenikov <dmitry_eremin-solenikov@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use variables from image-uefi.conf instead of hardcoding them in the class.
(From OE-Core rev: 094c272a74b4963ea5c010b9701bb83fa799a558)
Signed-off-by: Dmitry Eremin-Solenikov <dmitry_eremin-solenikov@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use variables from image-uefi.conf instead of hardcoding them in the
class.
(From OE-Core rev: 8d15c015d2498d541a6e52fc4e7553e692ff3ac5)
Signed-off-by: Dmitry Eremin-Solenikov <dmitry_eremin-solenikov@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Removes all references to the SSTATE_HASHEQUIV_SERVER variable. This
variable is redundant now that BB_HASHSERVE is present.
(From OE-Core rev: 54b3adb6bc90a8e4b9e92952688772ee074d36e5)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix error like:
lib32-e2fsprogs-1.45.3-r0 do_package_qa: QA Issue: /usr/sbin/e2scrub_all
contained in package lib32-e2fsprogs-e2scrub requires /bin/bash,
but no providers found in RDEPENDS_lib32-e2fsprogs-e2scrub
For some lib32 packages(eg: lib32-bash, lib32-sed) which probvides files,
extend is not needed
Eg: RPROVIDES of lib32-bash expects to have /bin/bash, with original
extend, it will become lib32-/bin/bash, then will cause above error
Fix by don't extend file dependency, and skip multilib check for file dependency
in do_package_qa to avoid error like:
WARNING: lib32-bash-5.0-r0 do_package: QA Issue: lib32-bash package lib32-bash
- suspicious values '/bin/bash /bin/sh' in RPROVIDES [multilib]
(From OE-Core rev: a9163120ed52534e7dbf4db50dc2b03bbf69f06b)
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These variables dont make sense for nativesdk targets which essentially
are target only properties, this helps in avoiding recompile of
nativesdk-libgcc-initial when switch libcs. nativesdk targets are glibc
only for OE
(From OE-Core rev: aff2d1264030a8061fc1b31dae0f369bfd76826b)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
musl based extensible sdk fails to install
ERROR: OE-core's config sanity checker detected a potential misconfiguration.
Either fix the cause of this error or at your own risk disable the checker (see sanity.conf).
Following is the list of potential problems / advisories:
Your system needs to support the en_US.UTF-8 locale.
The real reason is that its missing locale-archive in buildtools-tarball
hence python3 from buildtools-tarball fails to run bitbake when
installing esdk
(From OE-Core rev: c6e8e13f910544b2a4435d8b9e6dbc65847ef182)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add the break_hardlinks kwarg to break hardlinks when modifying files.
This uses the bb.utils.break_hardlinks function to break hardlinks. The
default is to maintain existing behaviour and leave hardlinks in place.
(From OE-Core rev: 7628f6bdb5704c018d83e284364994b72557eaa5)
Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
packages can use
find_package(PythonInterp REQUIRED)
find_package(PythonLibs REQUIRED)
while we control PYTHON pointing to native py3 the libs and include
directories will then point to build host version, which can result in
unexpected combination and if we are lucky we get errors if its quite
different e.g. py2 libs/includes and py3 executable
This variable can be then used to export PYTHON_LIBRARY and
PYTHON_INCLUDE_DIR so that above find_packages can work correctly
see [1] for how it happens in cmake
LLDB uses it see [2]
[1] https://github.com/Kitware/CMake/blob/master/Modules/FindPythonLibs.cmake
[2] https://github.com/llvm/llvm-project/blob/master/lldb/cmake/modules/LLDBConfig.cmake#L226
(From OE-Core rev: e45c06fe6f9a21c2cd06ae003cb112556382f81e)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This reverts commit 6676411fccff2d331878e4ca1f9411aafb056a80.
This revert restores the original code and adds a comment. The commit
that was reverted broke a number of wic templates and tools which rely
on the initramfs creation dependency and the case where the
INITRAMFS_IMAGE_BUNDLE is not set.
If an end user does not want the INITRAMFS_IMAGE generated, it should
be set to "".
[ Issue: LIN1019-1791 ]
(From OE-Core rev: ab61a11623ac0a25ba1c98d686c79815abab573f)
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
PRIVATE_LIBS is used to exclude 'private' libraries from getting added to
automatic runtime dependency resolution. This variable currently has to list
all libraries by name, which becomes a maintenance issue if the list
of such libraries frequently changes, or is very large.
This change allows using shell-style wildcards in the variable, similar
to how FILES lists what gets packaged.
(From OE-Core rev: 732db32714c208d8eeeb90308926dc886ef7b791)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Do not attempt to archive recipes which have no packaging tasks (e.g.
inherits nopackages).
(From OE-Core rev: 8618425e3f5a095a4fd409029c46e770c9526eee)
Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The debug output showed the wrong variable.
(From OE-Core rev: 9b404c24ddc6212576b78c9fc56c57baa0fb3745)
Signed-off-by: Daniel Klauer <daniel.klauer@gin.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It's not clear that we actually need to call mount -o remount,XX from
the busybox-inittab inittab at all, but as we currently do, let's
respect read-only-rootfs in IMAGE_FEATURES and not remount / as rw.
(From OE-Core rev: 8840a831d47a94f36bb2e173164dbaf9b955e809)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
compiling systemtap with icecc causes the following build failure
> build/tmp/work/silvermont-64-poky-linux/systemtap/4.0-r0/recipe-sysroot/usr/include/python3.7m/modsupport.h:120:66: note: in definition of macro 'PyModule_AddIntMacro'
> HelperSDT/_HelperSDT.c:145:34: error: 'PyTrace_RETURN' undeclared (first use in this function); did you mean 'PyTrace_C_RETURN'?
(From OE-Core rev: 66719424096eb0d3470647579364efe1556dc7b6)
Signed-off-by: Tim Blechmann <tim@klingt.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The locale-processing in cross-localedef was proven to be unsafe to
run in parallel due to the way it tried to make hard links to files
that could disappear before the link operation was completed.
To avoid corruption of the pseudo database, and create a
deterministically generated link tree, the operation of the locale
generation and the hard link resolution have been split into two
separate parts. A side effect of this change is that the do_package()
rule for glibc-locale will be slightly smaller because some of the
hard links were missed in the past, particularly if you had a lot of
cpus free to perform the work.
Before the patch:
% du -sk locale-tree
312524 locale-tree
With the patch:
% du -sk locale-tree
290772 locale-tree
A number of comparisons were performed such as diffing the output,
cross checking the link references using tar's listing output, and
comparing against the results with out a parallel build to ensure the
locale-tree is correct in its final form.
[YOCTO #11299]
[YOCTO #12434]
(From OE-Core rev: 93d935927dd0ec0fa6f0a80a71236a7b00a5d1a4)
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
do_package has PKGDESTWORK as a cleandir and do_packagedata has it as an sstate-input
dir. This means do_package wipes out the directory at both do_package and do_package_setscene.
do_package_setscene and do_packagedata_setscene can run in parallel when installing from
sstate which means they can wipe out parts of each other leading to interesting
build failures.
We therefore have to add in a hardlink copy so that the directories can work independently
of each other.
(From OE-Core rev: 692b2046bb60806ee6bbde6ba15bd1637b00efb1)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These postfuncs cause native recipes to rebuild when changing system
init provider between sysvinit and systemd. Some of these native recipes
are pretty early in dependency chain ( e.g. util-linux ) which can casue
rebuild of pretty much everything including compiler.
Found with bitbake-diffsigs
Hash for dependent task python/python3_3.7.4.bb:do_prepare_recipe_sysroot:virtual:native:/mnt/a/yoe/sources/openembedded-core/meta/recipes-devt
ools/python/python3_3.7.4.bb changed from 2a45fe0cd0d3640a88c4a5c8b1880c4e9a089cc7446a91d2a920c1cef6fa916a to bc2a0921cce50da1b7be3b59a3d8211ec
2a31262493ffa5909acbb7116fad3bf
Hash for dependent task util-linux/util-linux_2.34.bb:do_populate_sysroot:virtual:native:/mnt/a/yoe/sources/openembedded-core/meta/recipes-
core/util-linux/util-linux_2.34.bb changed from 15d6e165f025f10c2c455df8a875cafe021eaed4214c793e708d4827a58ca89d to 54e542d5da99cacfc9290ef5d27
9de50bdcb9195f67ae6dfff59fe41d10f7bd2
Hash for dependent task util-linux/util-linux_2.34.bb:do_install:virtual:native:/mnt/a/yoe/sources/openembedded-core/meta/recipes-core/
util-linux/util-linux_2.34.bb changed from e25b1119ce8dd7ca43fbd2db771e04fa6ff6b9d701fd78ac6c443224b036ed9f to bb5b172a83e7edd272402a9dcd80c4e1
29aa1ecb824c2cfa388086cfed24fef5
basehash changed from 62df6610eab9c1b1a17d7132943507641c8538690f26186843c86144d4598e64 to 80471f7c0bded9d1b593da69708b0e0f10882db08
5e1bf769edb3018e6c744d0
Variable rm_sysvinit_initddir value changed:
@@ -11,4 +11,4 @@
shutil.rmtree(sysv_initddir)
DISTRO_FEATURES{systemd} = Unset
-DISTRO_FEATURES{sysvinit} = Set
+DISTRO_FEATURES{sysvinit} = Unset
(From OE-Core rev: f2d60e0f6a8e93cb0779f4719e58b99ad01fb954)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The way this class uses overrides to support generation of multiple
sections is subject to two different issues: 1) labels that conflict
with existing override names causing the value for the conflicting label
to be set for all labels, and 2) reusing the override list through each
iteration, prepending each new label to the list of overrides makes
earlier labels' value take precedence over later labels, making later
labels virtually impossible to customize.
The first issue is resolved by removing all label names from overrides
before iterating over labels. The second issue is resolved by
generating a fresh list of overrides with only the current label added.
The current label is also appended to the list of overrides instead of
prepended, which makes it the highest priority override. This is
matches the behavior of devtool-source.bbclass, which similarly
monkey-patches overrides.
Closes https://bugzilla.yoctoproject.org/show_bug.cgi?id=13469 .
(From OE-Core rev: 42b44fdd9e63b8d39cf83baecec08328275558ff)
Signed-off-by: Will Page <wpage@polysync.io>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Recursive RDEPENDS resolution requires that all of the dependent
recipes' packaging has completed. There is no mechanism to ensure that
and therefore races were observed.
This change effectively requires recipes to list their runtime file
dependencies explicitly rather than have them pulled indirectly.
This may require a bit of fixing in layers, but should result
in a better definition of runtime file dependencies.
(From OE-Core rev: 08e2b5a31b23b98459479caf6ec5f5c6fc19d57a)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
