On Friday 12 October 2012 11:07:31 Saul Wold wrote: > On 10/11/2012 06:27 AM, Paul Eggleton wrote: > > The shared state cache as pointed to by SSTATE_DIR by default now has > > two-character subdirectories to prevent there being an issue with too > > many files in the same directory; also, native sstate packages will go > > into a subdirectory named using the distro ID string. If you copy the > > newly structured sstate cache to a mirror location (either local or > > remote) and then point to it in SSTATE_MIRRORS, you need to append > > "PATH" to the end of the mirror URL so that the path used by bitbake > > before the mirror substitution is appended to the path used to access > > the mirror. > > > > Signed-off-by: Paul Eggleton <paul.eggle...@linux.intel.com> > > --- > > > > meta/conf/local.conf.sample | 7 +++++-- > > 1 file changed, 5 insertions(+), 2 deletions(-) > > > > diff --git a/meta/conf/local.conf.sample b/meta/conf/local.conf.sample > > index 04d947f..d181e75 100644 > > --- a/meta/conf/local.conf.sample > > +++ b/meta/conf/local.conf.sample > > @@ -194,9 +194,12 @@ PATCHRESOLVE = "noop" > > > > # would contain the sstate-cache results from previous builds (possibly > > from other # machines). This variable works like fetcher > > MIRRORS/PREMIRRORS and points to the # cache locations to check for the > > shared objects. > > > > +# NOTE: if the mirror uses the same structure as SSTATE_DIR, you need to > > add PATH +# at the end as shown in the examples below. This will be > > substituted with the +# correct path within the directory structure. > > > > #SSTATE_MIRRORS ?= "\ > > > > -#file://.* http://someserver.tld/share/sstate/ \n \ > > -#file://.* file:///some/local/dir/sstate/" > > +#file://.* http://someserver.tld/share/sstate/PATH \n \ > > +#file://.* file:///some/local/dir/sstate/PATH" > > > > # CONF_VERSION is increased each time build/conf/ changes incompatibly > > and is used to # track the version of this file when it was generated. > > This can safely be ignored if > > I think this is really a Poky File, so should go to the > p...@yoctoproject.org!
There is a version of the file in both repositories, I sent a patch for each one. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
