On Sun, Mar 14, 2021, 2:18 PM Richard Purdie < richard.pur...@linuxfoundation.org> wrote:
> 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... > Agreed, I'll add a revert to my next set of patches. Steve > 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 (#149447): https://lists.openembedded.org/g/openembedded-core/message/149447 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] -=-=-=-=-=-=-=-=-=-=-=-
