On Thu, 2021-03-11 at 16:10 +0100, Martin Jansa wrote: > On Thu, Mar 11, 2021 at 02:38:16PM +0000, 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. > > The trouble for me is that seeing this "bitbake -g" again, doesn't > look wrong to me and:
It is a change of behaviour and it is not mentioned in the commit message so it would silently break anyone using SRC_URI in image recipes (amongst other possible failure modes). Whether they should be doing that is a different question. > > > I know last time we tried this I got several complaints > > from users who use these tasks for things. > > is the first time I've heard about people using these tasks in image > recipes. I haven't found any reference to this in the patches which > previously touched this area. Complaining that people don't remember > whole history of OE like you isn't fair :). I just remember changing this area of code and getting complaints. The information probably isn't in the commits but in the mailing list discussion surrounding them. Sadly my memory is far from perfect on any of this, seeing that diff did spark something though :/. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#149294): https://lists.openembedded.org/g/openembedded-core/message/149294 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] -=-=-=-=-=-=-=-=-=-=-=-
