[yocto] Added package to RDEPENDS in packagegroup, image that IMAGE_INSTALLs packagegroup not rebuilt

[Paul Eggleton]

On Thursday 06 November 2014 07:59:15 Isak Lichtenstein wrote:
> Hi Martin,
> 
> > -----Ursprüngliche Nachricht-----
> > Von: yocto-bounces at yoctoproject.org
> > [mailto:yocto-bounces at yoctoproject.org]
> > Im Auftrag von Vuille, Martin (Martin)
> > Gesendet: 05 November 2014 17:39
> > An: Paul Eggleton
> > Cc: yocto at yoctoproject.org
> > Betreff: Re: [yocto] Added package to RDEPENDS in packagegroup, image that
> > IMAGE_INSTALLs packagegroup not rebuilt
> > 
> > > -----Original Message-----
> > > From: Paul Eggleton [mailto:paul.eggleton at linux.intel.com]
> > > Sent: November 05, 2014 11:04 AM
> > > 
> > > OK, so this kind of explains it. To be perfectly honest the bitbake
> > > memory resident functionality (which Toaster uses behind the scenes)
> > > does have some holes in picking up changes, but I hadn't realised it
> > > would manifest in this particular manner. It seems like at the moment
> > > you'd need to stop and restart Toaster to be sure that the change gets
> > > picked> 
> > up.
> > 
> > 
> > - Stopped Toaster
> > - Removed the two cache directories
> > - bitbake <packagegroup>
> 
> I've spent yesterday morning trying to debug a similar problem. I had
> INHERIT += "rm_work" enabled in my local.conf file, and when removing it, I
> go the following error.: ERROR: No such task: do_rm_work
> ERROR: Task 10
> (/home/user/branches/dev/yocto/meta-libtest/recipes-support/libtest/libtest
> _1.0.bb, do_rm_work) failed with exit code '1'.
> 
> bitbake -e libtest | grep INHERIT showed me that rm_work was still around
> despite having removed it from my local.conf . INHERIT=" rm_work
> own-mirrors buildhistory toaster poky-sanity package_ipk image-mklibs
> image-prelink debian devshell sstate license blacklist sanity toaster
> buildhistory"
> 
> 
> Eventually I worked out that it was because I had Toaster running that the
> changes in local.conf where only partially picked up, and that's what
> created the error.
> 
> I'm not sure if this bug is related to the one you're seeing, but in case it
> is, it's definitely easier to reproduce than deleting/renaming the cache
> directories.

This is a slightly different symptom of the same underlying problem, yes.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre