linux/poky.git/meta/classes/image.bbclass, branch pyro-next

image: Expand PV to avoid AUTOREV parsing failures

2018-01-20T22:29:35+00:00

Currently, setting PV to include SRCPV for build-appliance results in: bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher failure: Fetch command export ftp_proxy="http://proxy.yocto.io:5187/"; export FTP_PROXY="http://proxy.yocto.io:5187/"; export PATH="${TMPDIR}/work/ qemux86_64-poky-linux/build-appliance-image/fetcheravoidrecurse-r0/ recipe-sysroot-native/usr/bin/python3-native:${TMPDIR}/work/ qemux86_64-poky-linux/build-appliance-image/fetcheravoidrecurse-r0/ recipe-sysroot-native/usr/bin/python3-native:${TMPDIR}/work/ qemux86_64-poky-linux/build-appliance-image/fetcheravoidrecurse-r0/ recipe-sysroot-native/usr/bin/python3-native:/home/pokybuild/ yocto-autobuilder/yocto-worker/buildtools/build/scripts:${TMPDIR}/ work/qemux86_64-poky-linux/build-appliance-image/fetcheravoidrecurse-r0/ recipe-sysroot-native/usr/bin/x86_64-poky-linux:${TMPDIR}/work/ qemux86_64-poky-linux/build-appliance-image/fetcheravoidrecurse-r0/ recipe-sysroot/usr/bin/crossscripts:${TMPDIR}/work/qemux86_64-poky-linux/ build-appliance-image/fetcheravoidrecurse-r0/recipe-sysroot-native/usr/sbin: ${TMPDIR}/work/qemux86_64-poky-linux/build-appliance-image/ fetcheravoidrecurse-r0/recipe-sysroot-native/usr/bin:${TMPDIR}/work/ qemux86_64-poky-linux/build-appliance-image/fetcheravoidrecurse-r0/ recipe-sysroot-native/sbin:${TMPDIR}/work/qemux86_64-poky-linux/ build-appliance-image/fetcheravoidrecurse-r0/recipe-sysroot-native/bin:/home/ pokybuild/yocto-autobuilder/yocto-worker/buildtools/build/bitbake/bin:${TMPDIR} /hosttools"; export HOME="/home/pokybuild"; git -c core.fsyncobjectfiles=0 ls-remote git://git.yoctoproject.org/poky failed with exit code 127, output: /bin/sh: 1: git: not found This is because PV is being expanded when TMPDIR is unset. Expand PV in advance to avoid this problem. (From OE-Core rev: 02a9c74b1e19ab3265eb8db2bb3a0de256cafffe) Signed-off-by: Richard Purdie

image.bbclass: drop initramfs bundle related code

2018-01-07T17:07:56+00:00

The original purpose of this code snippet was to repackage initramfs bundled kernel images before do_image_complete, to be able to be included by rootfs, but it's not going to achieve that since the initramfs bundled kernel images are not even installed to ${D}/boot after commit a49569e3a7534779bbe3f01a0647fd076c95798d: [ kernel.bbclass: do not copy bundled initramfs to /boot ] So there is not a initramfs bundled kernel package at all, we should drop the code, because it is leading kernel do_initramfs_bundle unnecessarily rerun and it's very time consuming and hence is impacting the performance a lot. (From OE-Core master rev: eca501aeb4f2cc9255fabab14c68f6910367aaf9) (From OE-Core rev: 22fd010b71b6ce79f3ede31e4e7da9dbc72de70e) (From OE-Core rev: f549338b0ed4d53dedac84c86e70ea9ffd12a17e) Signed-off-by: Ming Liu Signed-off-by: Richard Purdie Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

image_types.bbclass: Make u-boot signed images more versatile

2017-11-05T22:39:48+00:00

With the introduction of chaining compression/conversion support we can convert the old image_types_uboot.bbclass code that did a hand-chaining of a set of ${filesystem}.${compression} into generic and arbitrary support to sign whatever the user wants to sign for their image. This, for the record, does remove setting a valid compression type in the record in favour of just saying none. This is not a generally useful feature in U-Boot and I believe being versatile in terms of being able to pass in arbitrary compressions is more important. (From OE-Core rev: 979ff606d8c4c6f66c6dc533a92212f18708089e) Signed-off-by: Tom Rini Signed-off-by: Ross Burton Signed-off-by: Richard Purdie Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

image.bbclass: Sorted ctypes to avoid basehash error

2017-09-22T16:53:25+00:00

When selected multiple subimages a similar error could happend: Variable do_image_cpio[subimages] value changed \ from 'cpio.gz.u-boot cpio.gz' to 'cpio.gz cpio.gz.u-boot' To avoid this, 'ctypes' should be sorted at 'gen_conversion_cmds'. This garantee that 'CONVERSION_CMD_xxx' are always written in tha same order and consequently 'do_image_cpio' have the same hash. (From OE-Core rev: 271f1a5f65b8685a1e3645026876251122ef3974) (From OE-Core rev: 404a04a862a71a5a0fb1c20b6bc9fc9c8b2bb98c) Signed-off-by: Gerson Fernando Budke Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

image: Fix "metadata is not deterministic" when chaining 2+ CONVERSION_CMDs

2017-08-29T10:57:29+00:00

When we have more than one CONVERSION_CMD being used, for example ext4.gz.sha256sum we will see errors about "metadata is not deterministic". This is because we do not have a stable order of intermediate files that will be removed in the generated shell command. We fix this by calling sorted() on the set of rm_tmp_images so that we will have a stable hash again. Cc: Patrick Ohly (From OE-Core rev: 26feb0580642ef8934206ea73cdce9e1f73d14ef) Signed-off-by: Tom Rini Signed-off-by: Richard Purdie (cherry picked from commit 98a2afeb3a53bec7a72a4a9846e1dba636cc6f3d) Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

image.bbclass: Correct chaining compression support

2017-08-29T10:57:29+00:00

When chaining of compression/conversion types was added, we had a new way to handle doing things like "ext4.bz2.sha256sum" or "ext2.gz.u-boot". However, because the U-Boot image class isn't included normally, it wasn't properly converted at the time. After the support was added the "clean" argument that the .u-boot code uses no longer functions. The fix for this inadvertently broke chaining compression/conversion. First, correct the u-boot conversion code. Fixes: 46bc438374de ("image.bbclass: do exact match for rootfs type") Cc: Zhenhua Luo Cc: Richard Purdie Cc: Patrick Ohly (From OE-Core rev: ad22f73519292f53d2ea6eaae99f8a919c4f2c26) Signed-off-by: Tom Rini Signed-off-by: Ross Burton Signed-off-by: Richard Purdie (cherry picked from commit 0a7ce0b971a208956cb895ba5a869ec8c5d94703) Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

run-postinsts: simplify the logic of whether to install it to images

2017-03-14T14:42:17+00:00

The logic is scattered all over the place, but amounts to "install, unless the rootfs is read only". Let's express that directly. (From OE-Core rev: 697804229a172125ce7d3bfc9b343812d6fe3240) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

image-container.bbclass: Add the "container" IMAGE_FSTYPES

2017-02-19T14:49:00+00:00

The "container" fstype does very little other than pick tar.bz2 as the actual image type and disable installation of ROOTFS_BOOTSTRAP_INSTALL. [YOCTO #9502] (From OE-Core rev: e45f074b792a43aa2fd84a5a3f0e20bf1d88ad7e) Signed-off-by: Randy Witt Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

image.bbclass: Use 'populate_sdk_base' for non-linux targets

2017-02-15T17:29:56+00:00

When 'populate_sdk_ext' was first introduced in commit bf81d6bb7f6 it replaced the inheriting of 'populate_sdk_base'. For non-linux targets building the extensible SDK caused build errors, and the image class was changed to inherit 'populate_sdk' when targeting a non-linux SDK_OS (in commmit e471ce3464d). However inheriting 'populate_sdk' instead of 'populate_sdk_base' causes the SDK to always be built, this is not expected for the image class. This change makes the image class inherit 'populate_sdk_base' in the non-linux SDK_OS case so that it behaves the same as it is expected to behave where 'bitbake -c populate_sdk' must be executed to generate the SDK deployables. (From OE-Core rev: b7d6bb07fd37c55d07903a1e8921f17e39afde0a) Signed-off-by: Nathan Rossi Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

classes: Drop now unneeded update_data calls

2017-02-15T17:29:55+00:00

Now that the datastore works dynamically we don't need the update_data calls so we can just remove them. They're not actually done anything at all for a while. (From OE-Core rev: 8de0c5d3bd01919e2bf0394f9c485936d6098cec) Signed-off-by: Richard Purdie