From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Christopher Larson <clarson@kergoth.com>
Cc: Mike Looijmans <mike.looijmans@topic.nl>,
"OE Core \(openembedded-core@lists.openembedded.org\)"
<openembedded-core@lists.openembedded.org>
Subject: Re: How to find out why shared sstate is not being used for a recipe
Date: Thu, 29 May 2014 00:12:13 +0100 [thread overview]
Message-ID: <1401318733.2607.71.camel@ted> (raw)
In-Reply-To: <CABcZANm0dkCh1zFysD6VjDLS-ijHGqNat=FRVTYf03SeUF4XDQ@mail.gmail.com>
On Wed, 2014-05-28 at 13:46 -0700, Christopher Larson wrote:
>
> On Wed, May 28, 2014 at 1:42 PM, Khem Raj <raj.khem@gmail.com> wrote:
> On Mon, May 26, 2014 at 11:58 PM, Mike Looijmans
> <mike.looijmans@topic.nl> wrote:
> > I have a deja-vu feeling about this question.
> >
> > I have this recipe:
> >
> >
> https://github.com/topic-embedded-products/meta-topic/blob/master/recipes-bsp/fpga/fpga-image-miami.bb
> >
> > Which includes this one:
> >
> https://github.com/topic-embedded-products/meta-topic/blob/master/recipes-bsp/fpga/fpga-image.inc
> >
> > I have a build server that exports its sstate-cache
> directory through HTTP,
> > and a local host that attempts to use that sstate-cache.
> This works fine,
> > except for the recipe above. Building this recipe takes
> about 1 hour, so i
> > really really really want to share that state at any cost.
> As you can see,
> > I've done a big shotgun blast of "vardepdsexclude" to get
> the recipe to be
> > as common as possible. Still any host wants to build its own
> version.
> >
> > How can I diagnose the REASON that my machine thinks it
> isn't building the
> > exact same thing as the build server?
>
>
> see https://wiki.yoctoproject.org/wiki/Enable_sstate_cache
> towards the end it talks about verifying sstate sigs
>
>
> If the sstate is local at least, you can use bitbake -S printdiff
> <target>. There's also bitbake-whatchanged, but the bitbake one is
> superior.
Worst case, you can pull the siginfo files from one build and the
siginfo files from the sstate mirror and then see which ones are
different, then run bitbake-diffsigs X Y to compare the two files.
bitbake -S just tries to automate that process if it can.
Cheers,
Richard
next prev parent reply other threads:[~2014-05-28 23:12 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-27 6:58 How to find out why shared sstate is not being used for a recipe Mike Looijmans
2014-05-28 20:42 ` Khem Raj
2014-05-28 20:46 ` Christopher Larson
2014-05-28 23:12 ` Richard Purdie [this message]
2014-06-03 5:25 ` Mike Looijmans
2014-06-03 5:35 ` Mike Looijmans
2014-06-03 8:45 ` Richard Purdie
2014-06-03 13:54 ` Mike Looijmans
2014-06-03 14:10 ` Richard Purdie
2014-06-04 6:19 ` Mike Looijmans
2014-06-04 10:44 ` Mike Looijmans
2014-06-03 8:32 ` Martin Jansa
2014-06-03 9:07 ` Richard Purdie
2014-08-18 8:12 ` Mike Looijmans
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=1401318733.2607.71.camel@ted \
--to=richard.purdie@linuxfoundation.org \
--cc=clarson@kergoth.com \
--cc=mike.looijmans@topic.nl \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.