The comment specifies how to use the variables but uses the older and
now unsupported override syntax. Let's update to match the newer syntax.
Cc: Quentin Schulz <foss+yocto@0leil.net>
(From OE-Core rev: 0a381eea4d50ff1c6e7c7d0d4df62eb581454b48)
(From OE-Core rev: bb64f3fed29b9532e6ddc9a2ba0283d373622d87)
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Ross Burton <ross.burton@arm.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>
* we were installing them with -${KERNEL_DTB_NAME} suffix
and then adding a symlink without this suffix if
KERNEL_IMAGETYPE_SYMLINK is set:
if [ "${KERNEL_IMAGETYPE_SYMLINK}" = "1" ] ; then
ln -sf $dtb_base_name-${KERNEL_DTB_NAME}.$dtb_ext $deployDir/$dtb_base_name.$dtb_ext
fi
and another one when KERNEL_DTB_LINK_NAME is set:
if [ -n "${KERNEL_DTB_LINK_NAME}" ] ; then
ln -sf $dtb_base_name-${KERNEL_DTB_NAME}.$dtb_ext $deployDir/$dtb_base_name-${KERNEL_DTB_LINK_NAME}.$dtb_ext
fi
but KERNEL_DEVICETREE variable doesn't include this
-${KERNEL_DTB_NAME} suffix, so everything which uses KERNEL_DEVICETREE
either needs to add it as well or depend on KERNEL_IMAGETYPE_SYMLINK
being set, e.g. IMAGE_BOOT_FILES variable used by do_image_wic is
generated by make_dtb_boot_files function here:
2ad4dd667a/conf/machine/include/rpi-base.inc (L118)
and do_image_wic fails without KERNEL_IMAGETYPE_SYMLINK:
| WARNING: bootloader config not specified, using defaults
|
| ERROR: _exec_cmd: install -m 0644 -D deploy/images/raspberrypi4-64/bcm2711-rpi-4-b.dtb image/1.0-r1/tmp-wic/boot.1/bcm2711-rpi-4-b.dtb returned '1' instead of 0
| output: install: cannot stat 'deploy/images/raspberrypi4-64/bcm2711-rpi-4-b.dtb': No such file or directory
we can fix the function to append -${KERNEL_DTB_NAME} or we can
change this to install without suffix and then add ${KERNEL_DTB_NAME}
link only when KERNEL_DTB_NAME is set (${MACHINE} by default)
* now it looks strange to have both KERNEL_DTB_LINK_NAME and KERNEL_DTB_NAME
symlinks, but keep it for backwards compatibility and it will make
more sense again together with the rest of [YOCTO #12937] where version
specific *_LINK_NAME links are created as hardlinks in separate do_deploy_links
task.
[YOCTO #12937]
(From OE-Core rev: 3d04a8405b0fffef7df0760bd4551bd8767a1954)
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>
1 - Adapt do_configure to the new format of the shrinkwrap
2 - Remove useless function _npmsw_dependency_dict because the dictionnary
is already given by npmsw:foreach_dependencies
3 - Rename arguments of callback functions
(From OE-Core rev: 89e02fa47e8e4f77b7d7c552c07f8dc05f6e42ad)
Signed-off-by: BELOUARGA Mohamed <m.belouarga@technologyandstrategy.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
NPM changed its manner to handle peer dependencies over its versions.
Before NPM 3: NPM installs automatically peer dependencies
between NPM 3 and 7: NPM shows a warning about peer dependencies
After NPM 3: NPM reworked its manner how to handle peer dependencies
The shrinkwrap doesn't have the parameters of the peer dependencies, so we cannot
fetch them. in the same time peer dependencies are not direct dependencies, they should
be installed as run time dependencies.
(From OE-Core rev: a5734148649be93529e5d5172cb47928957a6536)
Signed-off-by: BELOUARGA Mohamed <m.belouarga@technologyandstrategy.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The intent behind these functions was to dump the system state when issues occured
but it has never really worked as we'd planned. Regular monitoring as the build
runs has largely replaced this as that allows a trend to be seen rather than a spot
value which was never really useful. The code is bitrotting and not functioning
correctly so drop it.
[YOCTO #13872]
RP: Reword commit message
(From OE-Core rev: dea37ba49a236029da73d5cfbfc069bffc38b508)
Signed-off-by: Thomas Roos <throos@amazon.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Instaed of allways create the directories and removing it at the if they are
not used, we can just do it when there are modules configuration to be created.
So the best thing to do is install the directories only when necessary.
(From OE-Core rev: 71460993f350bca3d5a22115fd5551696f955c9f)
Signed-off-by: Jose Quaresma <jose.quaresma@foundries.io>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Additionally:
- drop pseudo from INSANE_SKIP for 32bit time API check
(pseudo passes the check; it's not clear where the issue may have been)
- move rust exceptions to the cargo class, as the problem
is common across the ecosystem, and needs to be fixed in the
libc crate.
(From OE-Core rev: d3d406bf636e579c17708b408e11c12d252533ee)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This needs to be done for any item that is linked under rustc,
and not just rust itself. Latest python-cryptography exposes the issue.
(From OE-Core rev: d3811228747590ea06e8d68be4785d45ec9c478f)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
cargo_do_compile runs only if the recipe is built using cargo
as the top level tool. Some recipes hide usage of cargo inside setuptools
(or autoconf) and use do_compile definitions specific to those,
and so the environment isn't properly set up.
This was exposed by latest versions of python3-cryptography.
(From OE-Core rev: 9f4ff643a028d7f5670d80861f2ce19ca2d90faa)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
strip can be coming from binutils or from llvm
in some cases llvm-strip can fail on kernel
Subprocess output:aarch64-yoe-linux-llvm-strip: error: Link field value 28 in section .rela.dyn is not a symbol table
This helps in selecting which strip is used when building kernel
(From OE-Core rev: 03973c8c1c93ddb1c8e05b773bfcc45aed73a99f)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Cc: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We don't need to see warnings for missing target debug directories. Just
show a note in the logs instead.
(From OE-Core rev: 52db25c58069c4f440da33daf0474255c9fa870b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a basic artifacts retrievers in testimage class which:
- triggers when at least one runtime test fails but tests execution
encountered no major issue
- reads a list of paths to retrieve from TESTIMAGE_FAILED_QA_ARTIFACTS
- checks for artifacts presence on target
- retrieve those files over scp thanks to existing ssh class
- store those files in an "artifacts" directory in "tmp/log/oeqa/<image>"
This implementation assumes that the SSH or Qemu target has run and
finished gracefully. If tests do not finish because of an exception,
artifacts will not be retrieved
Bring partial solution to [YOCTO #14901]
(From OE-Core rev: 36ef582b8c1c99e6af1ce79ea79f5b059d2a1aad)
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The configuration in sysusers.d used to be parsed to create users/groups at
build time instead at runtime. This was leading to several conflicts with
users/groups defined in base-passwd recipe and specific definitions in recipes
inheriting the useradd class. Some of those conflicts raised unseen errors in
the do_rootfs command's logs.
As an example, the root home directory is set by default to `/home/root` but
systemd expects it as `/root`.
The new command `systemd_sysusers_check` checks each configuration for
users/groups and compare their properties to what is actually defined in the
`/etc/passwd` and `/etc/group` of the target rootfs.
(From OE-Core rev: 0c7e76df68acfeca059a6b906d2a891d56f01e77)
Signed-off-by: Louis Rannou <lrannou@baylibre.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, uboot do_menuconfig task is breaking when UBOOT_CONFIG is
chosen rather than UBOOT_MACHINE, it simply fails with the following
errors:
| make: *** No rule to make target 'menuconfig'. Stio.
| Command failed.
| Press any key to continue...
this is due to the work directory of do_menuconfig is set to ${B} but
not ${B}/$config.
We should distinguish two situations:
1) When there is only one config item in UBOOT_CONFIG, do_menuconfig
should work just like how it works for UBOOT_MACHINE.
2) When there are multiple config items in UBOOT_CONFIG, do_menuconfig
should print out some information saying it's not supported other
than just failing.
This patch mainly aims to fix that by introducing a extra variable
KCONFIG_CONFIG_ENABLE_MENUCONFIG, it would be set to 'false' for
situation 2), and when it's set to 'true', then set
KCONFIG_CONFIG_ROOTDIR correctly in uboot-config.bbclass to let
do_menuconfig task work.
DEVTOOL_DISABLE_MENUCONFIG could be replaced by this new variable
KCONFIG_CONFIG_ENABLE_MENUCONFIG.
(From OE-Core rev: f9e834e317880cf47dbb4f8285bc36d743beae5e)
Signed-off-by: Ming Liu <liu.ming50@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I've encountered issues reproducing initramfs and UKI image builds,
which will be fixed with this patch.
1. initramfs
There's a symbolic link to /sbin/init, which is appended to the cpio archive after creation.
The links timestamp needs to be static and the cpio append command needs the '--reproducible' flag to produce deterministic outcomes.
2. Unified Kernel Image
'--preserve-dates' is required for a static 'Time/Date' entry.
I've added '--enable-deterministic-archives' although in my case this
didn't change anything.
(From OE-Core rev: fd027729bafb4e085ba0949e38e724f3a8cad102)
Signed-off-by: Frieder Paape <frieder@konvera.io>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Packagegroups have "special" sstate signature behaviour in that they don't rebuild
when their dependencies do. This causes problems for SPDX task signatures. Since
packagegroups don't actually have any code in them, we don't need the standard
dependencies anyway so cancel out and allow the sstate signatures to function
correctly.
(From OE-Core rev: 5c4ed243c144e261eae5f2ccf5626371d87a8a43)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM[1] controls the search
behavior of find_program(). When this variable's value was
first used in OE, it was deliberately set to BOTH to allow
searching of host tools. This is to ensure the necessary tools
from host could be used. The downside is that the configure
behavior may differ on different host environments.
Later, this cmake.bbclass was added the ability to search tools
under the HOSTTOOLS_DIR. This means we no longer needs cmake to
search the host paths. So we remove the class-native setting of
BOTH.
[1] https://cmake.org/cmake/help/latest/variable/CMAKE_FIND_ROOT_PATH_MODE_PROGRAM.html
(From OE-Core rev: f4ea12f6635125ee793f4dd801c538c0186f9dc3)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In some cases, empty versioned directories are being left behind in
sysroots from previous versions of packages. This appears to be found
with recipes relying on hatchling, and causes errors at the do_compile
step:
| File "/workspace/yocto/manual/openembedded-core/build/tmp-glibc/work/core2-64-oe-linux/python3-iniconfig/2.0.0-r0/recipe-sysroot-native/usr/lib/python3.11/site-packages/packaging/version.py", line 197, in __init__
| match = self._regex.search(version)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^
| TypeError: expected string or bytes-like object, got 'NoneType'
To fix this error, add a do_prepare_recipe_sysroot postfunc in the
python_hatchling class that removes any nested empty directories from
the sysroots during build, so that dependent recipes don't get caught
on them.
(From OE-Core rev: 3ded8b83cebb6d2b9f9da1c0325148f8da4ed23b)
Signed-off-by: Trevor Gamblin <tgamblin@baylibre.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a specific kernel provider or configuration wants to enable BTF
and pahole analysis, it isn't currently possible due to the explicit
definition to false in the base kernel build arguments.
pahole is now detected by the kernel built itself, so unless
pahole-native is enabled, the result is the same.
If a kernel does require an explicit disable of pahole, it is better
to carry PAHOLE=false in those specific recipes.
(From OE-Core rev: b1e4851a36ed47ce6ba880a49264b9a57c78cf4f)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Just like UBOOT_LOCALVERSION, an end user can set KERNEL_LOCALVERSION
to append a string to the name of the local version of the kernel
image.
(From OE-Core rev: 229435a52f36ddec5f85fb6d5ccd42044b688397)
Signed-off-by: Ming Liu <liu.ming50@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Upstream's dtb directory structure has no real standard. They just tend
to idle around the 2/3 directory depth. Recursively search for the
dtb/dtbo files instead of assuming anything.
Fixes: 04ab57d200 (kernel-devicetree: allow specification of dtb
directory, 2023-05-02)
(From OE-Core rev: 81570ba93eb282fd4566077d3b7b9ddf8c303002)
Signed-off-by: Randolph Sapp <rs@ti.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The gi-docgen tool depends, as it's name suggests, on
gobject-introspection being available.
(From OE-Core rev: 874dc89182835ff01d881b998c707c1a9f1ccb08)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a recipe inherits gobject-introspection then there's a good chance
that it needs the gobject-introspection-native recipe for the m4 macros
in introspection.m4, because we always autoreconf so we always need the
macros to be present.
Change the dependencies so that inheriting g-i always adds a dependency
on gobject-introspection-native, and a dependency on qemu-native and
target gobject-introspection if G-I is enabled.
Partially reverts 4e51c18.
(From OE-Core rev: 2763bc8c3a8d789ddc8e22e6df69400dcba6d6f3)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use the notation suggested by Martin Jansa to avoid a bashism. Also
switch KERNEL_DTBVENDORED to the more common 0/1 notation instead of
true/false.
Fixes: 04ab57d200 (kernel-devicetree: allow specification of dtb
directory, 2023-05-02)
(From OE-Core rev: dd5a5abc9d88c3bc8ff2c52b042600f00f054015)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Randolph Sapp <rs@ti.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* since "populate_sdk_base: ensure ptest-pkgs pulls in ptest-runner" change:
https://git.openembedded.org/openembedded-core/commit/?id=ecff0642be5781f7f6cca617158b04ac9a0e85f0
in multilib build when building lib32-foo-image it can pick wrong
ptest-runner package if it was built in the same TMPDIR before the
image, do_rootfs then fails to find it, if the package manager config
doesn't have 64-bit feed enabled:
opkg_prepare_url_for_install: Couldn't find anything to satisfy 'ptest-runner'
(From OE-Core rev: 4d24749e7e94881bb952f5c927f0012eb70d4390)
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>
It can be useful for user of this class for giving common rust test
arguments (like --shuffle, --format or --test-threads)
To add arguments to test binary , simply define RUST_TEST_ARGS
in your recipe that inherit ptest-cargo, for example:
RUST_TEST_ARGS = "--shuffle"
(From OE-Core rev: ea1feece62b0347aa2ebf02509ff2da151d96b61)
Signed-off-by: Frederic Martinsons <frederic.martinsons@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Avoid dependency on unavailable virtual/lib32-arm-distromllib32-linux-gnueabi-binutils
MLPREFIX was dropped from other cases in:
https://git.openembedded.org/openembedded-core/commit/?id=6856fc5c848cc2564bebe03a007ef109f46d0adb
This was causing:
ERROR: Nothing PROVIDES 'virtual/lib32-arm-distromllib32-linux-gnueabi-binutils' (but virtual:multilib:lib32:oe-core/meta/recipes-core/images/core-image-minimal.bb DEPENDS on or otherwise requires it). Close matches:
virtual/arm-distromllib32-linux-gnueabi-binutils
virtual/lib32-arm-distromllib32-linux-gnueabi-compilerlibs
virtual/lib32-arm-distromllib32-linux-gnueabi-go-runtime
ERROR: Required build target 'lib32-core-image-minimal' has no buildable providers.
Missing or unbuildable dependency chain was: ['lib32-core-image-minimal', 'virtual/lib32-arm-distromllib32-linux-gnueabi-binutils']
in cases where multilib and WIC were enabled at the same time
(From OE-Core rev: d7644212a17537e9966218fbb99f21a64569f322)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fedora/Redhat and Arch are somewhat standardized on their dtb directory
structure. Let's add some flags to configure yocto to mimic that
behavior.
Add the following variables to the kernel class:
- KERNEL_DTBDEST (controls the destination directory for dtbs)
- KERNEL_DTBVENDORED (controls if vendor subdirectories are to
be respected)
Currently KERNEL_DTBDEST is expected to be a subdir of KERNEL_IMAGEDEST
and KERNEL_DTBVENDORED is expected to be "true"/"false". This only
applies to the package directory structure. The deploydir structure is
purposely left untouched for compatibility with existing recipes.
By default this is configured to behave the same as the current recipe
and produce a flat dtb directory at KERNEL_IMAGEDEST.
(From OE-Core rev: 04ab57d20009d85eb566e83ae6fe1dcea4db7300)
Signed-off-by: Randolph Sapp <rs@ti.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This new class offers the possibility to build rust unit tests
(and integration tests) and find them correctly.
Due to non deterministic names of generated binaries, a custom
parsing of build result must be performed.
See https://github.com/rust-lang/cargo/issues/1924
All rust projects will generate a test binary with "cargo build --tests"
command, even if there are no test defined in source code.
The binary will just output that it ran 0 tests.
(From OE-Core rev: dad9bad239d757ae0b159fe5f1276b6856547b4c)
Signed-off-by: Frederic Martinsons <frederic.martinsons@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[YOCTO #15108] -- https://bugzilla.yoctoproject.org/show_bug.cgi?id=15108
Since the latest change, the PYTHONPATH is overwritten instead of extended.
This leads to changed behavior and build errors of recipes where the PYTHONPATH
is set before setup_target_config is run.
Fixes: c9617c03bcee ("python3targetconfig.bbclass: use PYTHONPATH to point to the target config")
(From OE-Core rev: 2442ab92f8610784d28d8d83056b643bd95b0b4e)
Signed-off-by: Johannes Schrimpf <dev@loewen-email.de>
[Luca: add Fixes: tag]
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The default value of address-cells is "1", so the generated "its" file
only support 32bits address for uboot FIT image.
However, some platforms may want to support 64bits address of
UBOOT_LOADADDRESS and UBOOT_ENTRYPOINT.
Therefore, add variables to support both 64bits and 32bits address.
By default, the address-cell is 1 which is used for 32bits load address.
If users would like to use 64bits load address,
users are able to set as following for "0x400000000" 64bits load address.
1. FIT_ADDRESS_CELLS = "2"
2. UBOOT_LOADADDRESS= "0x04 0x00000000"
(From OE-Core rev: b4e46cdbd0727d97d13c2b8e9e4ce19c5c693f51)
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The default value of address-cells is "1", so the generated "its" file
only supports 32bits address for kernel FIT image.
However, some platforms may want to support 64bits address
of UBOOT_LOADADDRESS and UBOOT_ENTRYPOINT.
Therefore, adds a variable to support both 64bits and 32bits address cells.
By default, the address-cell is "1" which is used for 32bits load address.
If users would like to use 64bits load address, users are able to
set as following for "0x400000000" 64bits load address.
1. FIT_ADDRESS_CELLS = "2"
2. UBOOT_LOADADDRESS= "0x04 0x00000000"
(From OE-Core rev: 8ce15c76c50d5d61524fea585d19989baefb5df2)
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* this in the end doesn't help much, I was debugging warning (about base-files.do_install
signature being different than expected) from:
python3 $target_sdk_dir/ext-sdk-prepare.py $LOGFILE '${SDK_INSTALL_TARGETS}'
this shows the warning on console, but it doesn't end in $LOGFILE, because it
writes only contents of cooker log into the $LOGFILE with:
with open(logfile, 'a') as logf:
logf.write('Preparing SDK for %s...\n' % ', '.join(sdk_targets))
ret = run_command_interruptible('BB_SETSCENE_ENFORCE=1 bitbake --quiet %s' % ' '.join(sdk_targets))
if not ret:
ret = run_command_interruptible('bitbake --quiet build-sysroots')
lastlog = get_last_consolelog()
if lastlog:
with open(lastlog, 'r') as f:
for line in f:
logf.write(line)
if ret:
print('ERROR: SDK preparation failed: error log written to %s' % logfile)
return ret
maybe we could remove whole support for $LOGFILE parameter and just redirect
the output like other commands on this line
(From OE-Core rev: 719f22df160ebde303274ccfc04049cffdb51577)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add DT_FILES variable to allow the user of the class to select specific
dts files to build. This is useful for packages featuring dts files
for multiple machines.
Since many machine configs contain a list of dtb files
(e.g. KERNEL_DEVICETREE), DT_FILES works with both dts and dtb files.
(From OE-Core rev: a6164c384a5bf3980a7a6c7f23927af9aca93b85)
Signed-off-by: Petr Kubizňák <kubiznak@2n.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The perl-version.bbclass executes functions which can depend on
variables potentially populated by native, such as `libdir`. The
sanity `native-last` suggests that recipes should `inherit native`
last, but when that is done the variables like PERLVERSION end up
as `None`, since `${STAGING_LIBDIR}` needs `${libdir}` which is not
yet populated (by native).
All recipes in poky and widely used meta-layers have already been
updated to use the functions directly instead of relying on these
problematic variables. Delete the variables so that future recipes
do not make the mistake of using them.
Related: openbmc/openbmc#3770
(From OE-Core rev: 9351b6e7fab5669340bb062b9c84fb4faa3dce0b)
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Function 'gen_updatealternativesvardeps' still used old override
syntax when fetching variable flags. Update to use ':' instead to match
recipe meta data. This was found by review and no real issue encountered
but it is a bug that affects variable dependencies and can affect rebuilds
as task hashes might not be accurate.
(From OE-Core rev: 5691f554b2cd50f256a8cbb1d96781e9eb6b930e)
Signed-off-by: Peter Bergin <peter.bergin@windriver.com>
Signed-off-by: Peter Bergin <peter@berginkonsult.se>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is little point in having "crosssdk" suffex added to the virtual provider within
gcc/go since the TARGET_PREFIX or SDK_PREFIX already encapsulates this. Remove it
allowing some of the special case overriding to be removed.
This also allows removal of some of the MLPREFIX usage since again, the triplet
also covers this.
(From OE-Core rev: fe0206ba482d209b24e636d578aa68ba5e67ba1b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This already got fixed in the toolchain file that is used during development
in cb42802f2f
The toolchain file generated by the cmake.bbclass however does not set
CMAKE_SYSROOT. Under certain circumstances this also leads to the error:
`"stdlib.h: No such file or directory #include_next <stdlib.h>"`
during the build of a recipe.
An example where this accured was during the upgrade of the Apache Thrift
recipe in meta-openembedded to 0.11.0. With this change the build works out of
the box.
CMAKE_SYSROOT must only be set when crosscompiling, otherwise it will interfere
with the native compiler headers.
(From OE-Core rev: eb51e30e17c0c98441583854e8f8632e4fb5d11c)
Signed-off-by: Pascal Bach <pascal.bach@siemens.com>
(from http://lists.openembedded.org/pipermail/openembedded-core/2018-August/154791.html )
Signed-off-by: Mikko Rapeli <mikko.rapeli@bmw.de>
Signed-off-by: Poonam Jadhav <poonam.jadhav@kpit.com>
Signed-off-by: Poonam Jadhav <ppjadhav456@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is a partial fix for bugzilla 15059 [https://bugzilla.yoctoproject.org/show_bug.cgi?id=15059]
It has been noted by several people that when an initramfs is bundled:
- a lot of the kernel is rebuilt
- it takes a really long time
When looking at the logs, the second kernel compilation (that performs
the bundle) is not using the parallel make settings, and builds with
-j1.
We are already explicitly passing PARALLEL_MAKE when building kernel
modules, and by extending that explicit use to the main kernel
compilation, we ensure that we always get a parallel build.
Build times chnaged from more than 30 minutes for the bundle, to
3 minutes in local testing.
The question of whether or not too much is rebuilding during the
bundle step is still an open question, but with this tweak, at least
the build time is back in the realm of acceptable.
(From OE-Core rev: 88fd394ecf0f2174b792075d409d87046896426b)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
