On Sun, 2021-03-14 at 20:16 -0400, Denys Dmytriyenko wrote: > On Fri, Mar 12, 2021 at 12:17:08PM +0100, Martin Jansa wrote: > > On Fri, Mar 12, 2021 at 03:59:20PM +0800, Robert Yang wrote: > > > Hi RP, > > > > > > On 3/11/21 10:38 PM, Richard Purdie wrote: > > > > On Thu, 2021-03-11 at 10:02 +0100, Martin Jansa wrote: > > > > > On Thu, Mar 11, 2021 at 12:46:22AM -0800, Robert Yang wrote: > > > > > > This can fix a do_package error when compile with meta-secure-core > > > > > > layer: > > > > > > http://layers.openembedded.org/layerindex/branch/master/layer/meta-secure-core/ > > > > > > > > > > > > $ bitbake kernel-initramfs > > > > > > [snip] > > > > > > WARNING:kernel-initramfs-1.0-r0 do_package: Manifest > > > > > > build/tmp-glibc/sstate-control/manifest-x86_64_x86_64-nativesdk-secure-core-image-initramfs.packagedata > > > > > > not found in intel_x86_64 corei7-64 core2-64 x86_64 allarch > > > > > > x86_64_x86_64-nativesdk (variant '')? > > > > > > [snip] > > > > > > > > > > > > This is because kernel-initramfs wants to pack an initramfs image > > > > > > into > > > > > > kernel-initramfs.rpm which adds a dependency in kernel-initramfs.bb > > > > > > to do this: > > > > > > > > > > > > d.appendVarFlag('do_install', 'depends', ' > > > > > > ${INITRAMFS_IMAGE}:do_image_complete') > > > > > > > > > > > > This causes kernel-initramfs' do_package depends on > > > > > > ${INITRAMFS_IMAGE}:do_image_complete's do_packagedata, then we will > > > > > > get the > > > > > > error. Delete do_packagedata as other do_package relelated tasks > > > > > > for the image > > > > > > recipe will fix the error. > > > > > > > > > > > > Signed-off-by: Robert Yang <liezhi.y...@windriver.com> > > > > > > > > > > Acked-by: Martin Jansa <martin.ja...@gmail.com> > > > > > > > > > > I went a bit further and inheritted nopackages, but RP mentioned that > > > > > it > > > > > might be removing too much. Nothing failed with nopackages over night, > > > > > but still this smaller version will be safer as this needs to got to > > > > > gatesgarth and dunfell as well now. > > > > > > > > This has side effects and there was a reason this wasn't done > > > > originally. The > > > > trouble is that nobody is testing for that, just wanting to fix the > > > > problem > > > > they see. To prove this isn't straightforward, I tested this locally, > > > > comparing > > > > task-depends.dot from "bitbake core-image-sato -g" before and after > > > > this patch. > > > > > > If we want to avoid disconnecting them, it seems that a better way is > > > fixing > > > this in the recipes which has this problem? For example, I got this error > > > in > > > secure-core-image-initramfs.bb, then we can add "deltask do_packagedata" > > > in the > > > recipe to fix the problem. > > > > That's what I did in initramfs-android-image (which was triggering this > > for me as reported on ML) > > https://github.com/shr-distribution/meta-smartphone/commit/732dd29325d882a9b3414764ad4c7a254dae3f03 > > The issue of doing this in each and every possible initramfs image recipe is > that it does not scale. For example, this code in the original patch is very > common: > > d.appendVarFlag('do_install', 'depends', ' > ${INITRAMFS_IMAGE}:do_image_complete') > > And INITRAMFS_IMAGE can be set anywhere - in machine config, distro config or > even by end user in local.conf > > > > > @Martin maybe we shouldn't backport this patch to gatesgarth or dunfell > > > since > > > it may suprise the users. > > > > Unfortunately > > https://git.openembedded.org/openembedded-core/commit/?h=dunfell&id=e0c1db170fdd6c1d78fdfce017feae26c96fac29 > > was already backported to both gatesgarth and dunfell. > > Yeah, it's unfortunate. Our LTS maintainer is too good! :) > Seriously though, not sure why changing warning to error was even considered > for backporting to LTS! Making things stricter doesn't usually fall under > "bugfix" category...
FWIW I'm leaning to merging a deltask to image.bbclass in master and suggesting we revert this and live with the warning in older branches... The deltask will probably break things but I'm starting to think that is the lesser of several issues. Its not appropriate for the stable branches though. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#149442): https://lists.openembedded.org/g/openembedded-core/message/149442 Mute This Topic: https://lists.openembedded.org/mt/81249042/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
