Re: SSTATE builds more broken than I thought

[Richard Purdie <rpurdie@linux.intel.com>]

On Fri, 2010-11-12 at 16:55 -0700, Gary Thomas wrote:
> On 11/12/2010 04:31 PM, Richard Purdie wrote:
> > On Fri, 2010-11-12 at 01:35 -0700, Gary Thomas wrote:
> >> On 11/12/2010 01:30 AM, Richard Purdie wrote:
> >>> On Fri, 2010-11-12 at 01:18 -0700, Gary Thomas wrote:
> >>>>> Are these all files or are they symlinks? Are they just present for
> >>>>> deploy-ipk or are there others?
> >>>>
> >>>> They are files.
> >>>>
> >>>> Sorry, but I don't understand your other question.  These are the only
> >>>> extra files polluting the tree, except for Python *.py? object files
> >>>> which are also always created.
> >>>
> >>> Are there any files related to other sstate tasks such as
> >>> populate-sysroot*.tgz or package*.tgz or is there just *deploy-ipk*.tgz?
> >>>
> >>> In other words I'm wondering if this is something specific to the
> >>> deploy-ipk sstate task...
> >>
> >> The only extra files created are *deploy-ipk*.tgz
> >> This most certainly is restricted to the deploy-ipk sstate task and only
> >> happens if SSTATE_MIRRORS is defined.
> >
> > This should be fixed in ae98f7eacb9e61fe086d88dc694b4c651af9fee3, it
> > turns out to be an issue with the local fetcher not searching DL_DIR.
> 
> Trying the same process as in bug #526, it failed with this error:
[...]

Right, I messed up those commits. I should know better than make commits
when travelling and jetlagged.

I ended up reverting the first fixes and pushing a set of different
fixes.

Previously you (and I think Kevin Tian) reporting bitbake spending a
huge amount of time thinking about shared state. When I was debugging
this I noticed a potential cause of that, my local test setups were
evidently just too fast to notice it. I added another commit:

http://git.pokylinux.org/cgit.cgi/poky/commit/?id=89929e1f283c8508c505c9731ad933880abf22a1

which should make things faster (n^2 faster where n is the number of
tasks).

Thanks again for testing and reporting the issues, I believe this code
will make a significant difference for people once it works reliably and
we're close to making that happen.

Cheers,

Richard