This is useful for cargo dependencies specified as git repositories, where
those repositories themselves have submodules that need to be checked out.
(From OE-Core rev: f871d9d6094ec0001d826e4b5b3395c1842631bb)
Signed-off-by: Chris Spencer <spencercw@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We've realised that "bitbake XXXx -c populate_sdk" doesn't actually trigger
the package_qa tests to run. This means test coverage on the autobuilder was
poor. Fix this and run the tests for SDKs.
(From OE-Core rev: f35d9b7cc3998c88743397c5dc7e60dac8e4bbea)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
'UPDATE' as a name is somewhat unfortunate as the variable is intended only for
the 'devtool upgrade' operation and devtool also has an 'update-recipe' operation.
(From OE-Core rev: 4467aa0661e233f44c4ce029428c67d88fccfc07)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, "tarball" sdk based recipes don't generate SPDX manifests as they
don't include the rootfs generation classes. Split the SPDX 3.0 image class into
two so the SDK components can be included where needed.
To do this, introduce an SDK_CLASSES variable similar to IMAGE_CLASSES which
the SDK code can use.
Migrate testsdk usage to this.
Also move the image/sdk spdx classes to classes-recipe rather than the general classes
directory since they'd never be included on a global level.
For buildtools-tarball, it has its own testsdk functions so disable the class there as
a deferred inherit would overwrite it.
(From OE-Core rev: 662396533177b72cc1d83e95841b27f7e42dcb20)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some recipes use setuptools3 but should be using a PEP517-compliant
backend, be it the setuptools itself via python_setuptools_build_meta or
an alternative backend such as flit/hatch/poetry.
As we can't currently assume Python 3.11 on the build host we need to
parse the pyproject.toml manually, but this should be sufficient for the
limited parsing needed.
This task emits a QA error if a build backend is set, and can be ignored
by using INSANE_SKIP if needed.
[ YOCTO #14736 ]
(From OE-Core rev: a9d800f6cdfcedbe3de8366d935ee5f0c8557c06)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When a create-spdx-* classes is processing documents, it needs to
find the document in a path that is related to the SSTATE_ARCH
when a packge is generated. The SSTATE_ARCH can be affected by
multilib configurations, resulting is something like armv8a-mlib.
When the image (or SDK) is being generated and the components are
collected, the system has no knowledge of the multilib arch and
will fail to find it, such as:
ERROR: meta-toolchain-1.0-r0 do_populate_sdk: No SPDX file found
for package libilp32-libgcc-dbg,
False sstate:libilp32-libgcc:armv8a-ilp32-mllibilp32-elf:14.1.0:r0:armv8a-ilp32:12:
sstate:libilp32-libgcc::14.1.0:r0::12:
Adding in the new SPDX_MULTILIB_SSTATE_ARCHS will provide a full
set of SSTATE_ARCHS including ones that contain the multilib
extension which will allow create-spdx-* to correctly find the
document it is looking for. This would also be valuable to any
other function doing a similar search through SSTATE_ARCH that may
have been extended with multilib configurations.
(From OE-Core rev: f1499c36c1054fc90f7b7268cc95285f2eca72f7)
Signed-off-by: Mark Hatle <mark.hatle@amd.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Enables usage of TCLIBC=picolibc extending OE functionality to build and use
picolibc based toolchains to build baremetal applications.
Picolibc is a set of standard C libraries, both libc and libm, designed for
smaller embedded systems with limited ROM and RAM. Picolibc includes code
from Newlib and AVR Libc, but adresses some of newlibs concerns, it retains
newlibs directory structure, math, string and locale implementations, but
removed the GPL bits used to build the library, swiches old C style code for
C18 and replaces autotools with meson.
This patch adds a picolibc recipe for the C library, a picolibc-helloworld
recipe that contains an example application and a testcase that builds it.
Picolibc can be built for ARM and RISCV architectures, its been tested both
for 32 and 64 bits, the provided example recipe produces the following output:
hello, world
Runqemu does not automatically show any output since it hides QEMU stderr which
is where the QEMU monitors output is directed to when using semihosting, but,
manually running the same QEMU command does work properly.
(From OE-Core rev: c7535ecaccb72ef21a61f9aec5c68e61fb4f6fb6)
Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandro@enedino.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If EXTERNAL_KERNEL_DEVICETREE and dtb_image_sect are empty variables
dtb_path ends up as "/" which is available on most Unix systems but
probably not the dtb_path which is needed here. Checking for a file
makes more sense and also solves the issue with the "/".
(From OE-Core rev: c8f629b6991449cc6726f48a607d9e1bd50807ee)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
white space changes only.
- python part should be 4 spaces, not 8.
- use tabs for shell
(From OE-Core rev: 000079a973e8c97d496ca721259437880a7ea70d)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* -image and -base change PKG to:
PKG:${KERNEL_PACKAGE_NAME}-image = "${KERNEL_PACKAGE_NAME}-image-${@legitimize_package_name(d.getVar(KERNEL_VERSION))}"
PKG:${KERNEL_PACKAGE_NAME}-base = "${KERNEL_PACKAGE_NAME}-${@legitimize_package_name(d.getVar(KERNEL_VERSION))}"
* but only when debian.bbclass is inheritted they add the original package name into RPROVIDES by:
https://git.openembedded.org/openembedded-core/commit/?id=3409c4379559afbb1d1d29045582995147a33bbc
* fixes the build if some packagegroup or something RDEPENDS on kernel-image or kernel-base
and the DISTRO doesn't inherit debian.bbclass
* as shown in pkgdata:
linux-raspberrypi $ egrep "^(PKG:)|(RPRO)" 6.6.36+git-*/pkgdata/runtime/kernel-image
6.6.36+git-debian/pkgdata/runtime/kernel-image:RPROVIDES:kernel-image: kernel-image (=6.6.36+git@PRSERV_PV_AUTOINC@+733366844f_769634f344)
6.6.36+git-debian/pkgdata/runtime/kernel-image:PKG:kernel-image: kernel-image-6.6.36-v8
6.6.36+git-without-debian/pkgdata/runtime/kernel-image:PKG:kernel-image: kernel-image-6.6.36-v8
linux-raspberrypi $ egrep "^(PKG:)|(RPRO)" 6.6.36+git-*/pkgdata/runtime/kernel-image-image
6.6.36+git-debian/pkgdata/runtime/kernel-image-image:RPROVIDES:kernel-image-image: kernel-image-image (=6.6.36+git@PRSERV_PV_AUTOINC@+733366844f_769634f344)
6.6.36+git-debian/pkgdata/runtime/kernel-image-image:PKG:kernel-image-image: kernel-image-image-6.6.36-v8
6.6.36+git-without-debian/pkgdata/runtime/kernel-image-image:PKG:kernel-image-image: kernel-image-image-6.6.36-v8
(From OE-Core rev: 05498781657a3f8b38b000f91594ecd78850ce47)
Signed-off-by: Martin Jansa <martin.jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
MCNAME isn't defined outside our mcextend ptest images so use a wildcard in
TESTIMAGE_FAILED_QA_ARTIFACTS instead. This unbreaks the value in other images.
(From OE-Core rev: e7af85a7b7b966685a9eeaba11628dc10c1ea44b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add linux:linux to CVE_PRODUCT. linux:linux is used by the kernel CNA
in raw CVE entries. We can't use just linux, because of conflicts with
CPE entries of multiple distributions.
(From OE-Core rev: 27404c4ef815f41aac994e9f390776a8bf4f9553)
Signed-off-by: Marta Rybczynska <marta.rybczynska@syslinbit.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
multilib_script.bbclass was unable to work correctly in the case where
e.g. a PACKAGECONFIG removed the script that it was intended to rename
(as an example, the "trace" PACKAGECONFIG in cairo). The way to fix this
would be to do something like:
MULTILIB_SCRIPTS = "${@bb.utils.contains('PACKAGECONFIG', 'trace', '${PN}-perf-utils:${bindir}/cairo-trace', '', d)}"
but this is not possible because the variable is not expanded before
being split.
To fix this, change the class to expand the variable before splitting.
There are two cases to be considered that could possibly break:
1) If the RHS of the ":" contains a ":", which is accounted for by
limiting the splitting to 1 split, which will leave the ":" in the
RHS in tact. Of note, this works because ":" isn't valid in a
package name
2) If the RHS of the ":" contained whitespace, however this would have
broken the mv command written to multilibscript_rename(), so this
isn't occurring in practice.
(From OE-Core rev: b9c992e69f3f44051610386ce4f743e224750694)
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>
Downstream tasks may want to know what image files were written so write
out a manifest in do_image_complete. The format of the manifest is the
same as the one in image.bbclass
(From OE-Core rev: 4c4f1e020533c26f90e95960745f6de90d77e64e)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adds a class that allows recipes to opt out of generating SPDX
(From OE-Core rev: 170277da0dc34e3f797451473ebfbde82922f593)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adds the variable overrides to set the SPDX image purpose for various
image types
(From OE-Core rev: e1a8f59462d88c92dfdb3632ca95ded094c9472a)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Downstream tasks may want to know what image files were written by the
do_image family of tasks (e.g. SPDX) so have each task write out a
manifest file that describes the files it produced, then aggregate them
in do_image_complete
(From OE-Core rev: 5e55ed4c5b9d5af3c96b82805af34af1512fc3d1)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix error in run.do_assemble_fitimage_initramfs.2779256:
line 238: [: =: unary operator expected
if FIT_CONF_DEFAULT_DTB is empty.
(From OE-Core rev: 19a6eea0951404403dcb5d0deeda8558b1337f82)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
if IMAGE_LINK_NAME is set empty to disable the symlinking
for image artifacts in deploy, testexport fails, as the path assembly
is incorrect.
In that case fallback to IMAGE_NAME
(From OE-Core rev: 0c1d098e6dd08fa3a5aafca656457ac6badcef89)
Signed-off-by: Konrad Weihmann <kweihmann@outlook.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The qemuboot.conf file contains the realpath of the kernel image
referenced by QB_DEFAULT_KERNEL. So, it must be recreated in case the
realpath of the referenced kernel image changes.
The variables KERNEL_IMAGE_NAME and KERNEL_IMAGE_BIN_EXT determine the
realpath of the kernel image relative to DEPLOY_DIR_IMAGE. Adding both of
them to the vardeps of the write_qemuboot_conf task triggers the
write_qemuboot_conf task in case the realpath of the kernel image
referenced by QB_DEFAULT_KERNEL changes.
Fixes: [YOCTO 15525]
(From OE-Core rev: f8b3975a9ce36ea7af5fd76243a823da2842415b)
Signed-off-by: "Weisser, Pascal" <pascal.weisser.ext@karlstorz.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes bug 15464.
OECORE_NATIVE_SYSROOT is correctly set up and exported in the SDK's
environment file. But it's then unset in buildtools/environment-setup-*.
The value is restored in the SDK's environment file but is not exported
again.
(From OE-Core rev: 825c996b7995d3ad510933b1a88229831ca5ea29)
Signed-off-by: Gauthier HADERER <ghaderer@wyplay.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
if IMAGE_LINK_NAME is set empty to disable the symlinking
for image artifacts in deploy, testimage fails, as the path assembly
is incorrect.
In that case fallback to IMAGE_NAME
(From OE-Core rev: c7a4e7e294992acc589c62adcaf6cd32659f2f9b)
Signed-off-by: Konrad Weihmann <kweihmann@outlook.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We're currently encouraging an "arms race" with the FLAGS variables since
a recipe might want to set a specific flag for all variants but to do so,
+= won't work due to the assignment in the native/nativesdk class files. This
means recipes are using append.
Since the default variables are constructed out of TARGET_XXX variables and
we redefine these, there is no need to re-define the un-prefixed variables. If
we drop that, the += appends and similar work and recipes don't have to resort
to append.
Change the classes and cleanup a number of recipes to adapt to the change. This
change will result in some flags appearing to some native/nativesdk variants
but that is probably what was originally expected anyway.
(From OE-Core rev: a157b2f9d93428ca21265cc860a3b58b3698b3aa)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since the change done in commit 32cba1cc916a ("insane: Error for S ==
WORKDIR"), usage of WORKDIR is not allowed anymore.
Switch S from WORKDIR to UNPACKDIR as implemented in commit d9328e3b0b06
("recipes: Switch away from S = WORKDIR").
(From OE-Core rev: 7a06069a041a908c1d190f8fb7dd923b86217703)
Signed-off-by: Andrey Zhizhikin <andrey.z@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The commit “Use a copy of image for kernel*.rpm if fs doesn't support
symlinks” [1] added postinst and postrm scripts to the kernel package which
create a symlink after package installation. This should not happen if
`KERNEL_IMAGETYPE_SYMLINK` is not `1`.
Background: The u-boot implementation of jffs2 does not support symlinks.
Using a hardlink or removing `${KERNEL_VERSION}` from the file name fails,
because the current postinst script replaces the file with the symlink.
[1] 8b6b95106a
Cc: Bruce Ashfield <bruce.ashfield@gmail.com>
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: Yanfei Xu <yanfei.xu@windriver.com>
(From OE-Core rev: 6a763401862d9ee96749ad18378b6344778c2c66)
Signed-off-by: Jörg Sommer <joerg.sommer@navimatix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Added 7zip support and options and extension/type parameter
for it to able to make any custom archive type for SDK archive.
(From OE-Core rev: 02bbc736cf4f097a78afed4c7614000bd058ef3f)
Signed-off-by: Benjamin Szőke <egyszeregy@freemail.hu>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When we upgrade a recipe that inherits cargo-update-recipe-crates and
the upstream Cargo.toml/Cargo.lock have been changed, we need to run
the update_crates task or else the devtool upgrade (and therefore
AUH upgrade) will fail.
Add "do_update_crates" task to RECIPE_UPDATE_EXTRA_TASKS for all
recipes that inherit this class.
(From OE-Core rev: 0156ab3e009fa789c629f6c0ab06fcf21add94f8)
Signed-off-by: Tim Orling <tim.orling@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There are two types of soft FPU options for arm, soft and softfp, and if
using the latter the wrong dynamic loader will be used.
E.g. go will link against ld-linux-armhf.so.3, but libc6 will only ship
a ld-linux.so.3, so go programs will fail to start.
Fix this by instead checking for TARGET_FPU being 'hard' and then
applying the suffix.
(From OE-Core rev: 07b4c7a2bd23f8645810e13439e814caaaf9cd94)
Signed-off-by: Jonas Gorski <jonas.gorski@bisdn.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It always executes the scripts whether 'qemu-usermode' in
'MACHINE_FEATURES' or not. Fix the criterion to make it work.
(From OE-Core rev: 9e163246dcbbd2187c9ba28432c613b0d6c850c6)
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
libtool auto detects the sysroot from gcc's parameters or configuration so we
don't need to pass in this configuration separately to libtool.
Whilst the option names do conflict with gcc/binutils, that is an issue for those
projects to resolve, not us. Upstream libtool did reject the patch. We can
drop this patch and simplify our code.
(From OE-Core rev: 7c8553f81bccc3e8c2bb1116ee1e89f5f8af4c9e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Copying in the bb_unihashes cache file was at best a hack and creates a number of
challenges. One is staying in sync with bitbake since it may not have saved the
most recent version of the file. A second is a determinism problem since there may
be more entries in the file than the SDK should have had access to.
To improve the situation, add code to write the data into the locked-sigs.inc file
such that even when locked-sigs aren't used, the right hash mappings are injected
by the get_cached_unihash call.
The functions in copy_buildsystem need to be updated to preserve data they're not
editting.
(From OE-Core rev: 11373def3171e75b3b74ef694da213dd21f3064c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Right before this message is printed, the in-tree defconfig is checked
against the one in WORKDIR. If it is different, and therefore either
provided through SRC_URI or patched, then the message is printed.
Therefore, the debug message is incorrect and should say that a patched
defconfig was detected and overwritten.
Fixes: 004da4c6c602 ("kernel-yocto: split meta data gathering into patch and config phases")
Cc: Bruce Ashfield <bruce.ashfield@gmail.com>
(From OE-Core rev: f25717bff291ca225a70e63d3266656d8e643531)
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The siteconfig code was only used for 5 cache values. The complexity added to sstate
to support this code was considerable and the runtime much more significant than
any benefit the cache files would have added. Drop the support for this which
was only used minimally for ncurses and zlib.
(From OE-Core rev: f3766dc038f7ba9780ddaf5eb8d27385ea31d7d0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The change in commit 39fc503036
("classes: image_types: apply EXTRA_IMAGECMD:squashfs* in oe_mksquashfs()")
assigns $@ to a local variable without quoting it. While this works with
bash, it fails with dash. Here, only the first token of $@ is assigned
to the variable, and the reamining tokens are passed as arguments to the
"local" keyword.
Fix it by adding the missing quotes.
(From OE-Core rev: 14ca134f9f72d518c9180156a8efac19f8bb3ab0)
Signed-off-by: Martin Hundebøll <martin@geanix.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When this error is triggered, its a bit vague in specifying where the
issue is e.g.
ERROR: nbd-3.26.1-r0 do_package: nbd does not appear in package list, please add it
Some packages may intentionally remove PN from packages and find it
confusing as to why the system is still asking this to be in PACKAGES
(From OE-Core rev: 025a5e4529dff37a6423d305b12b7a51ceedd9e5)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It was previously discovered that mcmodel=medany should be used for RISCV64,
however this was only being set for the applications themselves, but not for
newlib, this meant that we ended up with C library that used a code model and
an application that used another one which is not something we want.
Pass mcmodel=medany when building newlib for RISCV64 as well.
Also, s/CFLAGS/TARGET_CFLAGS to standarize across recipes, the variable
expansion provides no functional difference at this point.
(From OE-Core rev: 3ed0a2fab5dbc37dd352ead8846da6aae5de5c20)
Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandro@enedino.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some build systems (notably, Meson) like to be told when cross-compiling
what the target endian and word size is. We don't have these exported
via the variables, so add them using siteinfo as a source of data.
(From OE-Core rev: c2fee816cae6dbedcb40f15be4a1b9ee91757a64)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The kernel has special handling of ${S} and it is therefore expected to be empty
at do_unpack time. For now, ignore this QA check until the kernel unpack process
can be more standardised.
(From OE-Core rev: f2f3f965d6d5fc19b357891e8c55473782124662)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The go class has its own fork of the base unpack code. At the time I was
told this was fine, it now isn't as that code is changing.
Rather than have a fork, put the path magic into a variable and then go
recipes can just set SRC_URI appropriately, e.g.:
git://go.googlesource.com/example;branch=master;protocol=https;destsuffix=${GO_SRCURI_DESTSUFFIX}
This avoids having special case hacks in the class and makes everything
a little more obvious.
(From OE-Core rev: cc4ec43a2b657fb4c58429ab14f1edc2473c1327)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The only real reason for oe-local-files was to support S = WORKDIR. With changes to
drop support for that, it makes sense to simplify devtool and to try and make both
the code and the processes/workflows simpler.
This patch drops support for S = WORKDIR, removes oe-local-files and then updates
the test cases to match this new situation.
At the code level, we assume we can always now track code changes using git and
that things committed into git are handled as patches (as before) but delta against
HEAD is saved as specific file level changes to the recipe.
One test is disabled as it is no longer approproate. It is being keped until we can
make WORKDIR != UNPACKDIR at which point it should be revisited.
(From OE-Core rev: ce8190c519052fed10b5233697b69a75868db45a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Replace references of WORKDIR with UNPACKDIR where it makes sense to do
so in preparation for changing the default value of UNPACKDIR.
(From OE-Core rev: 1f18b9a512800860d5153d89eb82b56388efad6f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The variable uninative_checksum is returned without being set, causing a
build error. Set it to None by default instead.
(From OE-Core rev: 69ead1f2d403e6a0e5365ce4e89288f846d3ef33)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since commit c991f9d6031 ("image_types: Set SOURCE_DATE_EPOCH for squashfs"),
I assume, the EXTRA_IMAGECMD:squashfs* variable(s) has been ignored.
This is due to the override magic, which isn't applied to functions
called by IMAGE_CMD:<type>, but only to the IMAGE_CMD:<type> itself.
Other image types (e.g. ext*) works around this by passing the
EXTRA_IMAGECMD variable as an argument to the called function.
To do the same for oe_mksquashfs(), the number of mandatory arguments is
fixed to one (with a little logic to handle the zstd filename). This
allows passing ${EXTRA_IMAGECMD} as an argument to oe_mksquashfs(),
which makes the variable functional again.
(From OE-Core rev: e6c1e3a65c3672473dcd01e4a950f89b70121d6b)
Signed-off-by: Martin Hundebøll <martin@geanix.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When using multiple u-boot configurations in UBOOT_CONFIG, the helper
function uboot_assemble_fitimage_helper() was not called with all
combinations of type & binary, due to a copy-n-paste indexing error.
(From OE-Core rev: 2d338548a4b745a71eaf6c29231adc93c4165778)
Signed-off-by: Ralph Siemsen <ralph.siemsen@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Work through the initial issues I found where we need to change WORKDIR
to UNPACKDIR.
(From OE-Core rev: 86fec41b1e809d1a2fa2feadc26d29020df53d39)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
${COREBASE}/scripts contains a "git" wrapper disabling fakeroot/pseudo.
This patch allows CMake to find ${COREBASE}/scripts/git instead of
${HOSTTOOLS_DIR}/git. This is needed for git invocations during do_install,
since do_install is a fakeroot task, and otherwise all git commands fail
with "fatal: detected dubious ownership in repository ...".
I don't know how common it is for CMake projects to invoke git during the
install phase intentionally. It's probably more common to do this during
the configure phase. However, the install step may re-run the configure
step, if some dependencies changed.
In my case, this happened in incremental Yocto builds which reran
do_install and repopulated parts of the recipe-sysroot during that,
without first rerunning do_configure or do_compile. One of the dependencies
changed (but only changing a file in some unrelated sub-package of it which
was not even installed into the recipe-sysroot), causing the dependant's
recipe-sysroot to be repopulated during do_install and thus causing the
CMake project to be reconfigured during do_install.
(From OE-Core rev: c1d1252032a5f146ad91eafc6f57ab4ea2a72e9c)
Signed-off-by: Daniel Klauer <daniel.klauer@gin.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the kernel folder does not exist, find will result in an error.
This can occur if the kernel has no modules but, for example, custom modules are created.
Add check before deleting.
(From OE-Core rev: 7ef767d84d56b25498e45db83bb8f9d9caebeaf9)
Signed-off-by: Heiko Thole <heiko.thole@entwicklung.eq-3.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
