[poky] Master stability update

[Tian, Kevin]

> From: Tian, Kevin
> Sent: Wednesday, January 26, 2011 10:52 AM
> 
> > From: Xu, Dongxiao
> > Sent: Wednesday, January 26, 2011 10:46 AM
> >
> > Richard Purdie wrote:
> > > We merged the features into master. I just want to highlight the
> > > status of the following issues:
> > >
> > > * pseudo problem causing failure of meta-toolchain and corruption of
> > > certain file permissions - fixed in master
> > >
> > > * the -live image issues some people and the autobuilder were seeing
> > > - fixed in master
> > >
> > > * the perf issue for linux-yocto-stable - fixed in master
> > >
> > > The following are know issues with master:
> > >
> > > * Using rm_work and switching machines to machines of the same
> > > "multimachine" architecture breaks.
> >
> > After sysroot is per machine, we may need to reserve the "image" folder
> even
> > when rm_work, since for the second machine build, do_populate_sysroot and
> > do_package will be re-run to populate files into a different sysroot folder.
> >
> > >
> > > * When switching machines of the same "multimachine" architecture
> > > (e.g.
> > > emenlow to atom-pc), some sstate packages are changing checksums when
> > > at first glance they shouldn't (e.g. perl do_install). A quick scan
> > > of my sstate directory:
> >
> > I also have a look at my local build sstate directories, there are 17 packages
> > whose prebuilt result could not shared betweeen atom-pc and emenlow.
> Some
> > of them may be not a problem since there are ${MACHINE} variables used in
> > do_install(), some others are strange why do_install will have two different
> > signatures between two different machines.
> >
> > I will spend some time investigating it.
> >
> 
> Note that checksum changes may not come from do_install itself, which
> including
> the hash from other tasks that do_install depends on. To capture the latter
> possibility, you can simply use "bitbake -S poky-image-minimal" which only
> generates
> .siginfo for all the tasks w/o actually running them. This way you can compare
> the
> difference between emenlow and atom-pc easily to see what actually change.
> 

After a quick check, I guess this is not a problem. for example perl.do_configure
changes checksum due to $MACHINE in dependency variables as Dongxiao said.
Once perl is not reusable, at least ~10 recieps (libzypp, libtool, rpm, ...) are not
reusable too because perl is in their task dependency chain.

I didn't check all the differences yet, but overall feeling is that this should be OK
as Dongxiao mentioned there're several obvious MACHINE related recipes. I'll
leave to Dongxiao for final confirmation. :-)

Thanks
Kevin