Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Mike Crowe <mac@mcrowe.com>
To: Chris Larson <clarson@kergoth.com>,
	openembedded-core@lists.openembedded.org
Subject: Re: Using SSTATE_MIRRORS with sstate subdirectories
Date: Fri, 19 Oct 2012 19:33:01 +0100	[thread overview]
Message-ID: <20121019183301.GA17013@mcrowe.com> (raw)
In-Reply-To: <CABcZANkCuggDC-rmqBA=N3GaWqTYWAPr+9eOoECiTSGVVgQN7A@mail.gmail.com>

On Fri, Oct 19, 2012 at 10:41:17AM -0700, Chris Larson wrote:
> On Fri, Oct 19, 2012 at 9:57 AM, Mike Crowe <mac@mcrowe.com> wrote:
> > SSTATE_MIRRORS = "\
> > file://Debian-testing/.* file:///private/sstate-cache/Debian-6.0.6/PATH \n \
> > file://.* file:///private/sstate-cache/PATH \n \
> > "
> >
> > Then I get paths like:
> >
> > DEBUG: For url file://Debian-testing/8c/sstate-tar-replacement-native-x86_64-linux-1.26-r3-x86_64-2-8cc4342260b064ace38e0aa1acf2f618_populate-sysroot.tgz returning file:///private/sstate-cache/Debian-6.0.6/Debian-testing/8c/sstate-tar-replacement-native-x86_64-linux-1.26-r3-x86_64-2-8cc4342260b064ace38e0aa1acf2f618_populate-sysroot.tgz
> 
> SSTATE_MIRRORS = "\
> file://${LSBNATIVESTRING} file:///private/sstate-cache/Debian-6.0.6 \n \
> file://.* file:///private/sstate-cache/PATH \n \
> "

Hi Chris,

Thanks for your reply.

After correcting ${LSBNATIVESTRING} to ${NATIVELSBSTRING} that worked!

I'm still somewhat baffled as to why that one doesn't require PATH but
the general one does but that no longer matters to me.
 
> We do this at mentor with a class to simplify the setup. See
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/tree/classes/sstate-reuse.bbclass.
> Then you'd do this:
> 
> INHERIT += "sstate-reuse"
> SSTATE_MIRROR_DISTROS = "Debian-testing"
> SSTATE_MIRROR_SITES = "file:///private/sstate-cache"
> 
> We do most of our automated builds on 32 bit and 64 bit centos 5.4
> hosts, then those native/cross sstates can then be reused just about
> everywhere, since that distro is so old.

Thanks. That looks interesting. I'm trying to do something similar,
except our main automated build machine is Debian stable and the
"clients" are Debian stable, testing and Ubuntu recent. I'd made the
same assumption that binaries compiledon Debian stable should run on
all the others.

Thanks again.

Mike.



  reply	other threads:[~2012-10-19 18:46 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-19 15:38 Using SSTATE_MIRRORS with sstate subdirectories Mike Crowe
2012-10-19 15:46 ` Chris Larson
2012-10-19 15:52   ` Paul Eggleton
2012-10-19 16:02     ` Mike Crowe
2012-10-19 16:57   ` Mike Crowe
2012-10-19 17:41     ` Chris Larson
2012-10-19 18:33       ` Mike Crowe [this message]
2012-10-19 19:03         ` Chris Larson
2012-10-19 21:01           ` Mike Crowe
2012-10-19 18:24     ` McClintock Matthew-B29882

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20121019183301.GA17013@mcrowe.com \
    --to=mac@mcrowe.com \
    --cc=clarson@kergoth.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox