The problem could be reproduced with the following settings:
MACHINE = "qemux86-64"
KERNEL_SPLIT_MODULES = "0"
require conf/multilib.conf
MULTILIBS ?= "multilib:lib32"
DEFAULTTUNE:virtclass-multilib-lib32 ?= "core2-32"
The error message is as below:
bb.data_smart.ExpansionError: Failure expanding variable KERNEL_VERSION_PKG_NAME, expression was ${@legitimize_package_name(d.getVar('KERNEL_VERSION'))} which triggered exception TypeError: expected string or bytes-like object
The variable dependency chain for the failure is: KERNEL_VERSION_PKG_NAME -> RPROVIDES:kernel-modules
This is because multilib_virtclass_handler_global function in
multilib_global.bbclass deletes KERNEL_VERSION. So we need to handle
such situation. We'll also need to delete KERNEL_VERSION_PKG_NAME
to avoid this parsing error.
(From OE-Core rev: 43dd497bc161ac44faecfdff052db03679dbb4f8)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Otherwise, PACKAGE_WRITE_DEPS would contain non-multilib variants
of dependencies even when building multilib items, resulting in
sysroots being populated with entirely wrong versions of them.
This hasn't been noticed until now through sheer (bad) luck, I think,
except in the cpio recipe, but the previous commit shows that the issues
did occur, quietly. Every other recipe in oe-core and meta-oe does not
prepend the multilib prefix.
(From OE-Core rev: 234965cb88ccfa9c3a357928f7155b119044e8fc)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This exposes the following failure in a multilib setup, when everything
up to do_package_write_rpm is in sstate, but do_package_write_rpm is not
(there's a similar fail for lib64-man-db, and the failures themselves will be fixed separately
in the next commit):
Exception: subprocess.CalledProcessError: Command '/srv/storage/alex/yocto/build-multilib/tmp/work/x86_64-pokymllib64-linux/lib64-quilt/0.67/recipe-sysroot/usr/bin/postinst-base-passwd' returned non-zero exit status 1.
Subprocess output:
install: cannot stat '/srv/storage/alex/yocto/build-multilib/tmp/work/x86_64-pokymllib64-linux/lib64-quilt/0.67/lib64-recipe-sysroot/usr/share/base-passwd/passwd.master': No such file or directory
(From OE-Core rev: 5ffa333db28bc5d8e440c983fdf95589d332461d)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
do_populate_lic dependencies are defined inside license.bbclass such as:
addtask populate_lic after do_patch before do_build
but externalsrc deletes the do_patch task, so the only dependency left for
do_populate_lic is "before do_build"
On a devtool context, when doing devtool modify, sources are extracted inside
build/workspace/sources/${BPN}/ and local files inside
build/workspace/sources/${BPN}/oe-local-files
When building the recipe after a devtool modify, do_unpack is called again to
unpack (possibly modified) local files from
build/workspace/sources/${BPN}/oe-local-files into ${WORKDIR}.
Since the only left dependency for do_populate_lic is do_build, the
do_populate_lic can be called BEFORE do_unpack. Most of the time this is not a
problem, because license files are generally located inside ${S}, which
corresponds to build/workspace/sources/${BPN} (and is already unpacked),
but this can lead to an issue if recipe sets LIC_FILES_CHKSUM to look for
files in ${WORKDIR} (example from init-ifupdown_1.0.bb):
LIC_FILES_CHKSUM = "file://${WORKDIR}/copyright;md5=3dd6192d306f582dee7687da3d8748ab"
So devtool modify init-ifupdown && bitbake init-ifupdown gives the following
error:
WARNING: init-ifupdown-1.0-r0 do_populate_lic: Could not copy license file <...>/build/tmp/work/qemux86_64-poky-linux/init-ifupdown/1.0/copyright to <...>/build/tmp/work/qemux86_64-poky-linux/init-ifupdown/1.0/license-destdir/qemux86_64/init-ifupdown/copyright: [Errno 2] No such file or directory: '<...>/build/tmp/work/qemux86_64-poky-linux/init-ifupdown/1.0/copyright'
ERROR: init-ifupdown-1.0-r0 do_populate_lic: QA Issue: init-ifupdown: LIC_FILES_CHKSUM points to an invalid file: <...>/build/tmp/work/qemux86_64-poky-linux/init-ifupdown/1.0/copyright [license-checksum]
ERROR: init-ifupdown-1.0-r0 do_populate_lic: Fatal QA errors were found, failing task.
ERROR: Logfile of failure stored in: <...>/build/tmp/work/qemux86_64-poky-linux/init-ifupdown/1.0/temp/log.do_populate_lic.838584
ERROR: Task (<...>/poky/meta/recipes-core/init-ifupdown/init-ifupdown_1.0.bb:do_populate_lic) failed with exit code '1'
Fix this by forcing the do_populate_lic task to run after do_unpack
(From OE-Core rev: ea6a0cccdd274534809df62a0a196bf83489a1e5)
Signed-off-by: Julien Stephan <jstephan@baylibre.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Vendor directory might still be required during install stage, so defer
the removal until later stage.
(From OE-Core rev: f4538e3884a0cfa07e16e6a2c986271cc7322dd8)
Signed-off-by: Vyacheslav Yurkov <uvv.mail@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Take into account module version when populating vendor directory,
because a module with the same URL but with a different version tag
could be used as an indirect dependency.
(From OE-Core rev: 8f6320c0858941b2441e290ef3586b48c2700cd1)
Signed-off-by: Vyacheslav Yurkov <uvv.mail@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Create symlinks for local modules, which are usually not referenced in
the SRC_URI, but still expected to be found in the vendor directory
during the build.
(From OE-Core rev: 16da5d9ad448aafd8b5fd63480727bd1b09ec9f1)
Signed-off-by: Vyacheslav Yurkov <uvv.mail@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now that bitbake supports the use of inherit_defer, switch all conditional
(variable based) inherits to use this instead. This leads to more a more
deterministic user experience since there is no longer an immediate expansion
and later changes to the variables in question (e.g. a bbappend) are
accounted for.
This patch tries to ensure the behaviour before/after remains as unchanged
as it reasonably can, e.g. by always inherting populate_sdk_base. native
and nativesdk continue to need to be inherited last, hence being used
with inherit_defer in a handful of very specific cases.
(From OE-Core rev: 451363438d38bd4552d5bcec4a92332f5819a5d4)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Ported from the meta-darwin layer:
The call to out.split("\n") expects a string, thus the parameter text=True is
needed (otherwise Popen returns a bytes object).
Note that "text" is just a more readable alias for universal_newlines.
(From OE-Core rev: 0abaa7bf7f7d9a5ac96e6fdbe99334cb2fb0e4db)
Signed-off-by: Dominik Schnitzer <dominik@snap.com>
Signed-off-by: Etienne Cordonnier <ecordonnier@snap.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* The tarfile module doesn't support xz options or environment varible
XZ_DEFAULTS, this makes do_ar_patched incrediblely slow when the file is
large, for example, chromium-x11 is about 3GB:
- "bitbake chromium-x11 -car_patched" hasn't been done after 3 hours on my
host, I checked the partial tar.xz file is only 1.5GB, so maybe more than 6
hours is required to complete the task.
- Now only less than 4 minutes is needed on the same host.
* Need add xz to HOSTTOOLS when archiver.bbclass is enabled and compression is xz.
(From OE-Core rev: 6548354f049b173e8d443bc547d35c9d9fc05259)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
On occasion a file is attmpeded to be opened prior to the
creation of the spdx_workdir. Create the directory before
the open, just in case.
File: '/build/layers/poky/meta/classes/create-spdx-2.2.bbclass', lineno: 1081, function: combine_spdx
1077: )
1078:
1079: image_spdx_path = spdx_workdir / (rootfs_name + ".spdx.json")
1080:
*** 1081: with image_spdx_path.open("wb") as f:
1082: doc.to_json(f, sort_keys=True, indent=get_json_indent(d))
(From OE-Core rev: bb9f2a9c0ff5dcdeaf1a0beb6a614d0d022a2481)
Signed-off-by: Jeremy A. Puhlman <jpuhlman@mvista.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There are other recipes except the listed ones which use work-shared, improve
the checking to make other recipes such as llvm-project-source work with
do_ar_patched.
(From OE-Core rev: 5fbb4ca8da4f4f1ea426275c45634802dcb5a575)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a task is adde which has a dependency on the do_populate_sysroot task of
the recipe, it will cause it to be installed into the sysroot (similar to
do_addto_recipe_sysroot). This fails since the postinst script is an overlapping
file:
Exception: FileExistsError: [Errno 17] File exists:
'tmp/sysroots-components/all/useraddbadtask/usr/bin/postinst-useradd-useraddbadtask'
->
'tmp/work/all-poky-linux/useraddbadtask/1.0/recipe-sysroot/usr/bin/postinst-useradd-useraddbadtask'
The copy written out at do_prepare_recipe_sysroot time is just for debug so
rename it, meaning there are no longer overlapping files and the installation
can be successful, removing the error.
[YCOTO #14961]
With the bug fixed, enable the test.
(From OE-Core rev: 564339afb73fc52a66c1a08437587cad1c4d46e7)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If recipe A requires the useradd actions of recipe B we need to
ensure that recipe B is part of the recipe A dependancy chain. In
order to do that, we introduce USERADD_DEPENDS. This makes sure
that the do_populate_sysroot_setscene of recipe B exists for
recipe A in case of a missing TMPDIR. This requires changes made in
runqueue.py by RP.
This commit along with the runqueue fixes effects:
Bug 13419 - recipes that add users to groups cannot rely on other recipes creating those groups (when population from sstate happens)
Bug 13904 - do_prepare_recipe_sysroot: postinst-useradd-* does not run in order of dependency and sometimes fails
Bug 13279 - Make sure users/groups exist for package_write_* tasks
Bug 15084 - For some reason using of same user in two recipes does not work properly
I've included the start of self-testing for useradd by adding tests for
13419 (which ends up testing 13904, 13279, 15084 by virtue of them all
having the same root cause)
(From OE-Core rev: b47f2352376bd16b7e7087b4dab143403e67e094)
Signed-off-by: Eilís 'pidge' Ní Fhlannagáin <pidge@baylibre.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This change introduced a warning if version comparisons failed, but
this is far too common an issue in data that we don't control, so this
shouldn't cause a warning:
WARNING: automake-native-1.16.5-r0 do_cve_check: automake: Failed to compare 1.16.5 = branch_1-9 for CVE-2009-4029
WARNING: subversion-1.14.2-r0 do_cve_check: subversion: Failed to compare 1.14.2 = m1 for CVE-2010-4539
WARNING: subversion-1.14.2-r0 do_cve_check: subversion: Failed to compare 1.14.2 = m2 for CVE-2010-4539
WARNING: subversion-1.14.2-r0 do_cve_check: subversion: Failed to compare 1.14.2 = m3 for CVE-2010-4539
WARNING: subversion-1.14.2-r0 do_cve_check: subversion: Failed to compare 1.14.2 = m4\/m5 for CVE-2010-4539
WARNING: subversion-1.14.2-r0 do_cve_check: subversion: Failed to compare 1.14.2 = m1 for CVE-2010-4644
WARNING: subversion-1.14.2-r0 do_cve_check: subversion: Failed to compare 1.14.2 = m2 for CVE-2010-4644
WARNING: subversion-1.14.2-r0 do_cve_check: subversion: Failed to compare 1.14.2 = m3 for CVE-2010-4644
WARNING: subversion-1.14.2-r0 do_cve_check: subversion: Failed to compare 1.14.2 = m4\/m5 for CVE-2010-4644
WARNING: subversion-1.14.2-r0 do_cve_check: subversion: Failed to compare 1.14.2 = m1 for CVE-2011-0715
WARNING: subversion-1.14.2-r0 do_cve_check: subversion: Failed to compare 1.14.2 = m2 for CVE-2011-0715
WARNING: subversion-1.14.2-r0 do_cve_check: subversion: Failed to compare 1.14.2 = m3 for CVE-2011-0715
WARNING: subversion-1.14.2-r0 do_cve_check: subversion: Failed to compare 1.14.2 = m4\/m5 for CVE-2011-0715
WARNING: automake-1.16.5-r0 do_cve_check: automake: Failed to compare 1.16.5 = branch_1-9 for CVE-2009-4029
WARNING: mpg123-1.32.3-r0 do_cve_check: mpg123: Failed to compare 1.32.3 = pre0.59s for CVE-2003-0577
WARNING: mpg123-1.32.3-r0 do_cve_check: mpg123: Failed to compare 1.32.3 = pre0.59s for CVE-2004-0982
WARNING: mpg123-1.32.3-r0 do_cve_check: mpg123: Failed to compare 1.32.3 = pre0.59s for CVE-2004-1284
WARNING: mpg123-1.32.3-r0 do_cve_check: mpg123: Failed to compare 1.32.3 = pre0.59s_r11 for CVE-2006-3355
WARNING: mpg123-1.32.3-r0 do_cve_check: mpg123: Failed to compare 1.32.3 = pre0.59s for CVE-2007-0578
WARNING: mpg123-1.32.3-r0 do_cve_check: mpg123: Failed to compare 1.32.3 = pre0.59s_r11 for CVE-2007-0578
WARNING: mpg123-1.32.3-r0 do_cve_check: mpg123: Failed to compare 1.32.3 = pre0.59s for CVE-2009-1301
WARNING: mpg123-1.32.3-r0 do_cve_check: mpg123: Failed to compare 1.32.3 = pre0.59s_r11 for CVE-2009-1301
This reverts commit a1989e4197178c2431ceca499e0b4876b233b131.
(From OE-Core rev: c7c7dbdd5474002cfd9ec24864e77a0df2b790ea)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Judgment processing of vulnerable using "=" compares characters as strings rather than numbers,
and misjudges "cases that do not match in strings but do match in numbers" as "Patched".
(e.g. PV = "1.2.0" and Vulnerabilities Affected Versions (registered with NVD) = "1.2")
Therefore, if the comparison operator used in the judgment processing of vulnerable is "=",
add numeric comparison processing.
(From OE-Core rev: a1989e4197178c2431ceca499e0b4876b233b131)
Signed-off-by: Shinji Matsunaga <shin.matsunaga@fujitsu.com>
Signed-off-by: Shunsuke Tokumoto <s-tokumoto@fujitsu.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In the case of a repository with submodules, we need to add the
"devtool-base" and "devtool-patched" tag on all submodules in order to
properly detect the added/removed/modified patches
(From OE-Core rev: 241da68805d177d4ec4b302c8a997645cc645286)
Signed-off-by: Julien Stephan <jstephan@baylibre.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A previous commit tried to add the --follow-symlinks option to
the perform_passwd_expire function in useradd_base.bbclass, however it used
a single -.
This is interpreted as --file=ollow-symlinks which results in...
sed: couldn't open file ollow-symlinks: No such file or directory
and...
ERROR: <image name>: passwd --expire operation did not succeed.
Fix by adding the missing -
(From OE-Core rev: 3c0deafcfcea3f610c7dd9a2d2884a16fbfe0497)
Signed-off-by: Adam Johnston <adam.johnston@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If /etc/passwd is a symlink, sed -i on same file will replace the
symlink with a new file. Prevent that by adding --follow-symlinks
option to sed
(From OE-Core rev: 6ec004b2e7b4342465af8e5e6cc66041834821a0)
Signed-off-by: Joakim Tjernlund <joakim.tjernlund@infinera.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Drop a len() usage that isn't needed, drop a comment that isn't needed
and use bb.fatal() to end the task with an error.
(From OE-Core rev: 1b9cf9cc2a52902e1181d2dac2ba9f2c3172835a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The JSON report generated by the cve-check class is basically a huge
list of packages. This list of packages is, however, unsorted.
To make things easier for people comparing the JSON, or more
specifically for git when archiving the JSON over time in a git
repository, we can sort the list by package name.
(From OE-Core rev: e9861be0e5020830c2ecc24fd091f4f5b05da036)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This allows, e.g., *.cmake to be added to CONFIGURE_FILES to make the
do_configure task depend on changes to any cmake file.
(From OE-Core rev: 09873b3fb24a00cfbd73282d29e4c5821774f579)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As in other places, print a more helpful error if a SPDX document is not
found when assembling documents for the final SPDX archive.
(From OE-Core rev: 0a3f7e0b41552e113347d6f5edefe84fd4e47fdf)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This message can appear in do_rootfs and the users tend to think this is
some kind of packaging issue. Add SPDX to the message so users like me
think in the right direction.
(From OE-Core rev: ddcf15134b5ec4bf4c728156461c2e45194d71ca)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Replace SDK_NAME with TOOLCHAIN_OUTPUTNAME when naming SDK host and
target SPDX archives.
In most cases TOOLCHAIN_OUTPUTNAME is almost identical to SDK_NAME,
but sometimes custom meta-toolchain recipes have some variations and
populate_sdk_base.bbclass already uses TOOLCHAIN_OUTPUTNAME to name
corresponding host and target manifests:
SDK_HOST_MANIFEST = "${SDKDEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.host.manifest"
SDK_TARGET_MANIFEST = "${SDKDEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.target.manifest"
To match the naming convention, also use TOOLCHAIN_OUTPUTNAME here
for naming SPDX archives as well, resulting in:
${TOOLCHAIN_OUTPUTNAME}-host.spdx.tar.zst
${TOOLCHAIN_OUTPUTNAME}-target.spdx.tar.zst
(From OE-Core rev: 38158670256e2ce803aa45f609108d29523b3135)
Signed-off-by: Denys Dmytriyenko <denys@konsulko.com>
Signed-off-by: Denys Dmytriyenko <denis@denix.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently the by-id and by-namespace SPDX files are created without reference
to PACKAGE_ARCH. This means that for two machines using a common package architecture
(e.g. genericx86-64 and qqemux86-64), there would be overlapping files. This means
that the build of one can remove files from the other leading to build failures. An
example would be:
MACHINE=qemux86-64 bitbake core-image-minimal
MACHINE=genericx86-64 bitbake core-image-minimal
MACHINE=qemux86-64 bitbake linux-yocto -c clean
MACHINE=genericx86-64 bitbake core-image-minimal -C rootfs
To fix this, add PACKAGE_ARCH to the path used for the files and use a search
path based upon PACKAGE_ARCHS to access them.
(From OE-Core rev: b2db10e966438071d00d2057b84d5f347613d841)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When building multilibs, we need to inject the multilib sstate pkgarch
into SSTATE_ARCHS so the list forms a complete search path. Add a tweak
to do this.
PACKAGE_ARCH defaults to TUNE_PKGARCH so this is equivalent and just
guards against recipes changing the value which may have other unwanted
side effects.
(From OE-Core rev: 37126ffc7ccbd3df57ebbd8e581d158f03bb3b4c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In a effort to debug YOCTO #15185, improve the logging when a package
file cannot be found in the list of SPDX files.
(From OE-Core rev: 35d827d44d65380bfb7f6e1d0a0ee63516f822a8)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Originally these were shell functions but they have long since been processed by
bb.build.exec_func(). Since we no longer need shell syntax, we can drop the ';'
delimiters and just use a space separated string.
This cleans up the variable and quietly removes any stray ';' that do happen to
still make it in.
(From OE-Core rev: c3365dfd9ddd7fbe70b62e0f11166e57a8ca6f73)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now that SRCPV isn't needed we can simplify things in a few places...
(From OE-Core rev: 843f82a246a535c353e08072f252d1dc78217872)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Source control information being present in PV used to be a hard requirement
for bitbake to operate correctly. Now that hashes are a required part of task
stamps, this requirement no longer exists.
This means we can defer the hash pieces to PKGV and simplify PV.
Use new bitbake fetcher API to inject the source revisions directly into the hash
allowing removal of some horrible code from base.bbclass and avoiding any hardcoding
about how SRCREV may or may not be used.
Use that API to object the string to append to PKGV and append that directly.
The user visible effect of this change is that PV will no longer have revision
information in it and this will now be appended to PV through PKGV when the
packages are written. Since PV is used in STAMP and WORKDIR, users will see
small directory naming and stamp naming changes.
This will mean that sstate reuse through hash equivalence where the source
revision changes but the output does not will become possible as the sstate
naming will become less specific and no longer contain the revision.
The SRCPV variable will no longer be needed in PV and is effectively now just
a null operation. Usage can be removed over time.
(From OE-Core rev: a8e7b0f932b9ea69b3a218fca18041676c65aba0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Native recipes are not able to use ccache currently, due to a circular
dependency between ccache-native and cmake-native.
This affects also other native recipes, but not all, imposing a
limitation in build time optimizations.
The introduction of CCACHE_NATIVE_RECIPES_ALLOWED allows the user to specify
which native recipes should use ccache, keeping it disable by default for all
native recipes.
(From OE-Core rev: 87cb2be71e0c0c123eaae6a5ae135900c95535db)
Signed-off-by: Angelo Ribeiro <Angelo.Ribeiro@criticaltechworks.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If accepted, this patch should merge with the corresponding BitBake
patch titled "fetch2: add Google Cloud Platform (GCP) fetcher".
(From OE-Core rev: 1e2e596bcdff031d7d7dc1d6f6adbb03d9ec2995)
Signed-off-by: Emil Ekmečić <eekmecic@snap.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Instead of deleting setscene tasks, now SSTATE_SKIP_CREATION is set instead.
This seems to fix the compile issues where the populate_sysroot task was
not run when an externalsrc recipe was built as a dependency.
[YOCTO #15164]
[RP addition: The deltask was added by me in 2012 when the class was created.
The trouble is bitbake assumes 'sstate' tasks have a setscene task and by deleting
the setscene task, bitbake stops thinking the task can be accelerated. There is other
code in the sysroot code which assumes some tasks are always sstate tasks.
We cannot delete the task without changes to the way bitbake learns about 'setscene'
tasks so the patch is correct, avoiding creating files is the better approach given
the way the world works now.
There would be concerns about exisitng sstate reuse however this shouldn't occur
since SRC_URI changes and that will change the underlying hashes. Hash equivalency
could potentially cause issues by joining hashes together again however if the output
matches, that shouldn't in theory cause any issue.]
(From OE-Core rev: ee4667a24ccdd8c9d547e73aecf661e6a1283890)
Signed-off-by: Peter Suti <peter.suti@streamunlimited.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
- Replace CVE_CHECK_IGNORE with CVE_STATUS to be more flexible.
The CVE_STATUS should contain an information about status wich
is decoded in 3 items:
- generic status: "Ignored", "Patched" or "Unpatched"
- more detailed status enum
- description: free text describing reason for status
Examples of usage:
CVE_STATUS[CVE-1234-0001] = "not-applicable-platform: Issue only applies on Windows"
CVE_STATUS[CVE-1234-0002] = "fixed-version: Fixed externally"
CVE_CHECK_STATUSMAP[not-applicable-platform] = "Ignored"
CVE_CHECK_STATUSMAP[fixed-version] = "Patched"
(From OE-Core rev: 34f682a24b7075b12ec308154b937ad118d69fe5)
Signed-off-by: Andrej Valek <andrej.valek@siemens.com>
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* ${IMAGE_NAME}${IMAGE_NAME_SUFFIX} is almost always used together already
and when they aren't it's usually because of hardcoded '.rootfs' suffix
* it's a bit strange, because ${IMAGE_NAME_SUFFIX} is applied after the
version from ${IMAGE_VERSION_SUFFIX}, if we move it to ${IMAGE_LINK_NAME}
then it will be applied before the version and ${IMAGE_LINK_NAME}
will be just the version-less symlink to latest built version.
* it's not added to INITRAMFS_IMAGE_NAME as it assumes that all
images used as initramfs will set IMAGE_NAME_SUFFIX to empty.
Many already do as shown bellow, but you might need to extend
this list in your layer.
* this also allows to drop support for imgsuffix varflag, recipes which
don't want to have .rootfs suffix can just set IMAGE_NAME_SUFFIX to
empty and it will be consistently respected by both IMAGE_NAME and IMAGE_LINK_NAME
* imgsuffix = d.getVarFlag("do_" + taskname, 'imgsuffix') or d.expand("${IMAGE_NAME_SUFFIX}.")
is kind of terrible, notice trailing '.' after ${IMAGE_NAME_SUFFIX}
while this dot was in imgsuffix in:
do_bootimg[imgsuffix] = "."
but in both cases it's not really part of the imgsuffix, but the
"extension" type separator as in dst variable:
dst = os.path.join(deploy_dir, link_name + "." + type)
- src = img_name + imgsuffix + type
+ src = img_name + "." + type
* for ubifs volumes move vname after IMAGE_NAME_SUFFIX
* to better document these changes here is an example with default poky
configuration with just:
IMAGE_FSTYPES:append:pn-core-image-minimal = " live wic wic.vmdk ubi"
MKUBIFS_ARGS = "-m 2048 -e 129024 -c 968 -x zlib"
UBINIZE_ARGS = "-m 2048 -p 131072 -s 512"
added in local.conf, so that deploy_dir has also some initramfs and more
IMAGE_FSTYPES
* "ls -lahi tmp/deploy/images/qemux86-64/"
output after "bitbake core-image-minimal"
And deploy-dir is cleaned between runs with:
bitbake -c clean core-image-minimal core-image-minimal-initramfs virtual/kernel grub-efi systemd-boot
The output confirms that the only change is ".rootfs" added not only
in ext4 and manifest files, but also for hddimg, iso, qemuboot.conf
testdata.json for both the actual artifacts as well as the symlinks
while core-image-minimal-initramfs doesn't have them as IMAGE_NAME_SUFFIX
was already set to empty there:
meta/classes-recipe/baremetal-image.bbclass:IMAGE_NAME_SUFFIX ?= ""
meta/recipes-core/images/core-image-minimal-initramfs.bb:IMAGE_NAME_SUFFIX ?= ""
meta/recipes-core/images/core-image-tiny-initramfs.bb:IMAGE_NAME_SUFFIX ?= ""
meta/recipes-extended/baremetal-example/baremetal-helloworld_git.bb:IMAGE_NAME_SUFFIX ?= ""
meta/recipes-extended/images/core-image-testcontroller-initramfs.bb:IMAGE_NAME_SUFFIX ?= ""
before these changes:
total 297M
31269162 drwxr-xr-x 2 martin martin 4.0K Mar 7 19:19 .
31263942 drwxr-xr-x 3 martin martin 4.0K Mar 7 12:53 ..
35845703 lrwxrwxrwx 2 martin martin 77 Mar 7 12:27 bzImage -> bzImage--6.1.14+git0+e8d08fc4c0_b05ca3429c-r0.0-qemux86-64-20230307112110.bin
35845704 -rw-r--r-- 2 martin martin 11M Mar 7 12:27 bzImage--6.1.14+git0+e8d08fc4c0_b05ca3429c-r0.0-qemux86-64-20230307112110.bin
35845702 lrwxrwxrwx 2 martin martin 77 Mar 7 12:27 bzImage-qemux86-64.bin -> bzImage--6.1.14+git0+e8d08fc4c0_b05ca3429c-r0.0-qemux86-64-20230307112110.bin
40236967 -rw-r--r-- 2 martin martin 13M Mar 7 19:19 core-image-minimal-initramfs-qemux86-64-20230307181808.cpio.gz
40203232 -rw-r--r-- 2 martin martin 1.1K Mar 7 19:19 core-image-minimal-initramfs-qemux86-64-20230307181808.manifest
40212700 -rw-r--r-- 2 martin martin 1.6K Mar 7 19:19 core-image-minimal-initramfs-qemux86-64-20230307181808.qemuboot.conf
40211556 -rw-r--r-- 2 martin martin 211K Mar 7 19:19 core-image-minimal-initramfs-qemux86-64-20230307181808.testdata.json
40236964 lrwxrwxrwx 2 martin martin 62 Mar 7 19:19 core-image-minimal-initramfs-qemux86-64.cpio.gz -> core-image-minimal-initramfs-qemux86-64-20230307181808.cpio.gz
40203235 lrwxrwxrwx 2 martin martin 63 Mar 7 19:19 core-image-minimal-initramfs-qemux86-64.manifest -> core-image-minimal-initramfs-qemux86-64-20230307181808.manifest
40212690 lrwxrwxrwx 2 martin martin 68 Mar 7 19:19 core-image-minimal-initramfs-qemux86-64.qemuboot.conf -> core-image-minimal-initramfs-qemux86-64-20230307181808.qemuboot.conf
40211560 lrwxrwxrwx 2 martin martin 68 Mar 7 19:19 core-image-minimal-initramfs-qemux86-64.testdata.json -> core-image-minimal-initramfs-qemux86-64-20230307181808.testdata.json
40237307 -rw-r--r-- 2 martin martin 57M Mar 7 19:19 core-image-minimal-qemux86-64-20230307181808.hddimg
40237329 -rw-r--r-- 2 martin martin 56M Mar 7 19:19 core-image-minimal-qemux86-64-20230307181808.iso
40220347 -rw-r--r-- 2 martin martin 1.6K Mar 7 19:19 core-image-minimal-qemux86-64-20230307181808.qemuboot.conf
40236942 -rw-r--r-- 2 martin martin 34M Mar 7 19:19 core-image-minimal-qemux86-64-20230307181808.rootfs.ext4
40211563 -rw-r--r-- 2 martin martin 1.2K Mar 7 19:19 core-image-minimal-qemux86-64-20230307181808.rootfs.manifest
40237206 -rw-r--r-- 2 martin martin 16M Mar 7 19:19 core-image-minimal-qemux86-64-20230307181808.rootfs.tar.bz2
40237216 -rw-r--r-- 2 martin martin 20M Mar 7 19:19 core-image-minimal-qemux86-64-20230307181808.rootfs.ubi
40224358 -rw-r--r-- 2 martin martin 19M Mar 7 19:19 core-image-minimal-qemux86-64-20230307181808.rootfs.ubifs
40360386 -rw-r--r-- 2 martin martin 73M Mar 7 19:19 core-image-minimal-qemux86-64-20230307181808.rootfs.wic
40237285 -rw-r--r-- 2 martin martin 35M Mar 7 19:19 core-image-minimal-qemux86-64-20230307181808.rootfs.wic.vmdk
40209866 -rw-r--r-- 2 martin martin 206K Mar 7 19:19 core-image-minimal-qemux86-64-20230307181808.testdata.json
40236946 lrwxrwxrwx 2 martin martin 56 Mar 7 19:19 core-image-minimal-qemux86-64.ext4 -> core-image-minimal-qemux86-64-20230307181808.rootfs.ext4
40237336 lrwxrwxrwx 2 martin martin 51 Mar 7 19:19 core-image-minimal-qemux86-64.hddimg -> core-image-minimal-qemux86-64-20230307181808.hddimg
40237337 lrwxrwxrwx 2 martin martin 48 Mar 7 19:19 core-image-minimal-qemux86-64.iso -> core-image-minimal-qemux86-64-20230307181808.iso
40211564 lrwxrwxrwx 2 martin martin 60 Mar 7 19:19 core-image-minimal-qemux86-64.manifest -> core-image-minimal-qemux86-64-20230307181808.rootfs.manifest
40220348 lrwxrwxrwx 2 martin martin 58 Mar 7 19:19 core-image-minimal-qemux86-64.qemuboot.conf -> core-image-minimal-qemux86-64-20230307181808.qemuboot.conf
40237205 lrwxrwxrwx 2 martin martin 59 Mar 7 19:19 core-image-minimal-qemux86-64.tar.bz2 -> core-image-minimal-qemux86-64-20230307181808.rootfs.tar.bz2
40209873 lrwxrwxrwx 2 martin martin 58 Mar 7 19:19 core-image-minimal-qemux86-64.testdata.json -> core-image-minimal-qemux86-64-20230307181808.testdata.json
40237217 lrwxrwxrwx 2 martin martin 55 Mar 7 19:19 core-image-minimal-qemux86-64.ubi -> core-image-minimal-qemux86-64-20230307181808.rootfs.ubi
40236771 lrwxrwxrwx 2 martin martin 57 Mar 7 19:19 core-image-minimal-qemux86-64.ubifs -> core-image-minimal-qemux86-64-20230307181808.rootfs.ubifs
40237287 lrwxrwxrwx 2 martin martin 55 Mar 7 19:19 core-image-minimal-qemux86-64.wic -> core-image-minimal-qemux86-64-20230307181808.rootfs.wic
40237286 lrwxrwxrwx 2 martin martin 60 Mar 7 19:19 core-image-minimal-qemux86-64.wic.vmdk -> core-image-minimal-qemux86-64-20230307181808.rootfs.wic.vmdk
40237192 -rw-r--r-- 2 martin martin 3.8K Mar 7 19:19 core-image-minimal.env
34458377 -rw-r--r-- 2 martin martin 616K Mar 7 17:55 grub-efi-bootx64.efi
34963606 -rwxr-xr-x 2 martin martin 103K Mar 6 22:02 linuxx64.efi.stub
35845662 -rw-r--r-- 2 martin martin 8.2M Mar 7 12:27 modules--6.1.14+git0+e8d08fc4c0_b05ca3429c-r0.0-qemux86-64-20230307112110.tgz
35845701 lrwxrwxrwx 2 martin martin 77 Mar 7 12:27 modules-qemux86-64.tgz -> modules--6.1.14+git0+e8d08fc4c0_b05ca3429c-r0.0-qemux86-64-20230307112110.tgz
34963605 -rwxr-xr-x 2 martin martin 140K Mar 6 22:02 systemd-bootx64.efi
27651415 -rw-r--r-- 2 martin martin 274 Mar 7 19:19 ubinize-core-image-minimal-qemux86-64-20230307181808.cfg
after these changes:
total 297M
31269162 drwxr-xr-x 2 martin martin 4.0K Mar 7 19:16 .
31263942 drwxr-xr-x 3 martin martin 4.0K Mar 7 12:53 ..
39479266 lrwxrwxrwx 2 martin martin 77 Mar 7 12:27 bzImage -> bzImage--6.1.14+git0+e8d08fc4c0_b05ca3429c-r0.0-qemux86-64-20230307112110.bin
39479267 -rw-r--r-- 2 martin martin 11M Mar 7 12:27 bzImage--6.1.14+git0+e8d08fc4c0_b05ca3429c-r0.0-qemux86-64-20230307112110.bin
39479264 lrwxrwxrwx 2 martin martin 77 Mar 7 12:27 bzImage-qemux86-64.bin -> bzImage--6.1.14+git0+e8d08fc4c0_b05ca3429c-r0.0-qemux86-64-20230307112110.bin
39648810 -rw-r--r-- 2 martin martin 13M Mar 7 19:15 core-image-minimal-initramfs-qemux86-64-20230307181456.cpio.gz
39638400 -rw-r--r-- 2 martin martin 1.1K Mar 7 19:15 core-image-minimal-initramfs-qemux86-64-20230307181456.manifest
39644650 -rw-r--r-- 2 martin martin 1.6K Mar 7 19:15 core-image-minimal-initramfs-qemux86-64-20230307181456.qemuboot.conf
39637657 -rw-r--r-- 2 martin martin 211K Mar 7 19:15 core-image-minimal-initramfs-qemux86-64-20230307181456.testdata.json
39648091 lrwxrwxrwx 2 martin martin 62 Mar 7 19:15 core-image-minimal-initramfs-qemux86-64.cpio.gz -> core-image-minimal-initramfs-qemux86-64-20230307181456.cpio.gz
39638401 lrwxrwxrwx 2 martin martin 63 Mar 7 19:15 core-image-minimal-initramfs-qemux86-64.manifest -> core-image-minimal-initramfs-qemux86-64-20230307181456.manifest
39644651 lrwxrwxrwx 2 martin martin 68 Mar 7 19:15 core-image-minimal-initramfs-qemux86-64.qemuboot.conf -> core-image-minimal-initramfs-qemux86-64-20230307181456.qemuboot.conf
39637662 lrwxrwxrwx 2 martin martin 68 Mar 7 19:15 core-image-minimal-initramfs-qemux86-64.testdata.json -> core-image-minimal-initramfs-qemux86-64-20230307181456.testdata.json
39654281 -rw-r--r-- 2 martin martin 34M Mar 7 19:15 core-image-minimal-qemux86-64.rootfs-20230307181456.ext4
39656710 -rw-r--r-- 2 martin martin 57M Mar 7 19:15 core-image-minimal-qemux86-64.rootfs-20230307181456.hddimg
39657112 -rw-r--r-- 2 martin martin 56M Mar 7 19:16 core-image-minimal-qemux86-64.rootfs-20230307181456.iso
39645313 -rw-r--r-- 2 martin martin 1.2K Mar 7 19:15 core-image-minimal-qemux86-64.rootfs-20230307181456.manifest
39646013 -rw-r--r-- 2 martin martin 1.6K Mar 7 19:15 core-image-minimal-qemux86-64.rootfs-20230307181456.qemuboot.conf
39656336 -rw-r--r-- 2 martin martin 16M Mar 7 19:15 core-image-minimal-qemux86-64.rootfs-20230307181456.tar.bz2
39644408 -rw-r--r-- 2 martin martin 206K Mar 7 19:15 core-image-minimal-qemux86-64.rootfs-20230307181456.testdata.json
39656583 -rw-r--r-- 2 martin martin 20M Mar 7 19:15 core-image-minimal-qemux86-64.rootfs-20230307181456.ubi
39654124 -rw-r--r-- 2 martin martin 19M Mar 7 19:15 core-image-minimal-qemux86-64.rootfs-20230307181456.ubifs
39802371 -rw-r--r-- 2 martin martin 73M Mar 7 19:16 core-image-minimal-qemux86-64.rootfs-20230307181456.wic
39657113 -rw-r--r-- 2 martin martin 35M Mar 7 19:16 core-image-minimal-qemux86-64.rootfs-20230307181456.wic.vmdk
39654412 lrwxrwxrwx 2 martin martin 56 Mar 7 19:15 core-image-minimal-qemux86-64.rootfs.ext4 -> core-image-minimal-qemux86-64.rootfs-20230307181456.ext4
39657167 lrwxrwxrwx 2 martin martin 58 Mar 7 19:16 core-image-minimal-qemux86-64.rootfs.hddimg -> core-image-minimal-qemux86-64.rootfs-20230307181456.hddimg
39657168 lrwxrwxrwx 2 martin martin 55 Mar 7 19:16 core-image-minimal-qemux86-64.rootfs.iso -> core-image-minimal-qemux86-64.rootfs-20230307181456.iso
39645316 lrwxrwxrwx 2 martin martin 60 Mar 7 19:15 core-image-minimal-qemux86-64.rootfs.manifest -> core-image-minimal-qemux86-64.rootfs-20230307181456.manifest
39646014 lrwxrwxrwx 2 martin martin 65 Mar 7 19:15 core-image-minimal-qemux86-64.rootfs.qemuboot.conf -> core-image-minimal-qemux86-64.rootfs-20230307181456.qemuboot.conf
39656315 lrwxrwxrwx 2 martin martin 59 Mar 7 19:15 core-image-minimal-qemux86-64.rootfs.tar.bz2 -> core-image-minimal-qemux86-64.rootfs-20230307181456.tar.bz2
39644406 lrwxrwxrwx 2 martin martin 65 Mar 7 19:15 core-image-minimal-qemux86-64.rootfs.testdata.json -> core-image-minimal-qemux86-64.rootfs-20230307181456.testdata.json
39656584 lrwxrwxrwx 2 martin martin 55 Mar 7 19:15 core-image-minimal-qemux86-64.rootfs.ubi -> core-image-minimal-qemux86-64.rootfs-20230307181456.ubi
39654775 lrwxrwxrwx 2 martin martin 57 Mar 7 19:15 core-image-minimal-qemux86-64.rootfs.ubifs -> core-image-minimal-qemux86-64.rootfs-20230307181456.ubifs
39657126 lrwxrwxrwx 2 martin martin 55 Mar 7 19:16 core-image-minimal-qemux86-64.rootfs.wic -> core-image-minimal-qemux86-64.rootfs-20230307181456.wic
39657088 lrwxrwxrwx 2 martin martin 60 Mar 7 19:16 core-image-minimal-qemux86-64.rootfs.wic.vmdk -> core-image-minimal-qemux86-64.rootfs-20230307181456.wic.vmdk
39654418 -rw-r--r-- 2 martin martin 3.8K Mar 7 19:15 core-image-minimal.env
39475732 -rw-r--r-- 2 martin martin 616K Mar 7 17:55 grub-efi-bootx64.efi
31507074 -rwxr-xr-x 2 martin martin 103K Mar 6 22:02 linuxx64.efi.stub
39479261 -rw-r--r-- 2 martin martin 8.2M Mar 7 12:27 modules--6.1.14+git0+e8d08fc4c0_b05ca3429c-r0.0-qemux86-64-20230307112110.tgz
39479263 lrwxrwxrwx 2 martin martin 77 Mar 7 12:27 modules-qemux86-64.tgz -> modules--6.1.14+git0+e8d08fc4c0_b05ca3429c-r0.0-qemux86-64-20230307112110.tgz
31507058 -rwxr-xr-x 2 martin martin 140K Mar 6 22:02 systemd-bootx64.efi
27651415 -rw-r--r-- 2 martin martin 274 Mar 7 19:15 ubinize-core-image-minimal-qemux86-64.rootfs-20230307181456.cfg
[YOCTO #12937]
(From OE-Core rev: 26d97acc71379ab6702fa54a23b6542a3f51779c)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Current error message is difficult to read:
ERROR: Nothing PROVIDES 'image'
trs-image was skipped: image - image: normal username test does not have a static ID defined. Add test to one of these files
It's not clear that first "image" is recipe name, second "image" is
binary package name and that "test" is the user account which does not
have a static ID defined. Improve the error message so that these are
more explicit. Now the error message looks like:
image was skipped: Recipe image, package image: normal username "test" does not have a static ID defined.
(From OE-Core rev: 07898218f3908a83e07178b6530dfa48d55d4ec2)
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Otherwise the task is still put into sstate, which means the error can
effectively be hidden by ignoring it.
(From OE-Core rev: 9d00f3ba4555510cf9525f4f6f186bf8a1371cee)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some variables cause issues with taskhashes and are accounted for in the
output in other ways, or don't affect it. Exclude these to improve the
taskhashes with create-spdx and allow the sstate selftests to work better.
(From OE-Core rev: e7daaa50af4ccd5ccb568f7a380ded18c7f74ab0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There are two seperate PKGDATA_DIR directories, one for the target and one for
the SDK. Rather than fail when a package can't be found, try the SDK first.
We use a datastore copy to keep the code simple, rather than havng to parameterise
all the packagedata functions.
(From OE-Core rev: 701d8f975c89dc6753188fbcf9d4883650ba5b58)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes the runtime dependency calculations to also only follow direct
dependencies of the current task instead of all transient dependencies
in a similar way as the build time dependencies.
(From OE-Core rev: 5fa00564b047725541a5fed95b621f0202803345)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Build time dependencies were not being correctly calculated for SPDX
documents because while a task can `deptask` itself (as do_create_spdx
did), those dependencies do not appear in BB_TASKDEPDATA (to avoid
circular dependencies).
To fix this, an intermediate task called do_collect_sdpx_deps is created
that does the 'deptask' on do_create_spdx and records the recipe
dependencies. do_create_spdx then runs after this new task. This breaks
the circular dependency and thus all of the do_create_spdx tasks
correctly show up as dependencies of do_collect_spdx_deps.
In addition, the dependency collection logic was improved to handle the
case of transitive dependencies (that is, a dependency of a dependency)
SPDX documents missing and causing an error. These transitive
dependencies don't actually need to be included anyway since one can
follow the relationship of the direct dependency to find them. As such,
the code is reworked to find the current task in BB_TASKDEPDATA, and
then only collect the immediate dependencies of the current task.
(From OE-Core rev: 55b3f160b13c6db778db09476cc4c73e70c5e930)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a package renames itself using PKG, the new name should be respected
as a name that the recipe provides.
(From OE-Core rev: 871f48126180bf30c001c6b97268cee1853dbda2)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Enabling the SPDX class and running two builds, one with SDKMACHINE=i686
and then again with SDKMACHINE=x86_64 would lead to errors since the output
was stored per MACHINE and the overlapping files would cause manifest errors.
The hashfn data from bitbake has SSTATE_PKGARCH encoded into it which is how
sstate separates out it's targets and SDPX should be using the same structure.
Therefore switch to using this.
(From OE-Core rev: 51049cde0cf477f7988b94c1041eb33b018a669f)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Extending archiver is not possible without duplicating the anonymous
function's logic. Move this logic in a separate function
"include_package" which returns a bool.
(From OE-Core rev: 292c626526b2ba6d3a66463c0c7ab59eb8903ab4)
Signed-off-by: Antonin Godard <antoningodard@pm.me>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Make the report-error catch ParseError error as below and then
we can check it directly via error report web.
ParseError at /build/layers/oe-core/meta/recipes-support/curl/curl_7.88.1.bb:32: unparsed line: 'PACKAGECONFIG[ares] = "--enable-ares,--disable-ares,c-ares,,,threaded-resolver'
(From OE-Core rev: dc22ac8b20cafbc517b7750dc3381c1a9a42cda4)
Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
