All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Jansa <martin.jansa@gmail.com>
To: Mike Looijmans <mike.looijmans@topic.nl>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: How to find out why shared sstate is not being used for a recipe
Date: Tue, 3 Jun 2014 10:32:04 +0200	[thread overview]
Message-ID: <20140603083204.GN2426@jama> (raw)
In-Reply-To: <538D5C34.4060905@topic.nl>

[-- Attachment #1: Type: text/plain, Size: 3771 bytes --]

On Tue, Jun 03, 2014 at 07:25:08AM +0200, Mike Looijmans wrote:
> On 05/29/2014 01:12 AM, Richard Purdie wrote:
> > 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.
> 
> It's on two different machines, so I think that does not qualify as "local".
> 
> > 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.
> 
> How do I find what to pull? I have (ssh) access to both machines. The 
> sstate-cache dir contains a bunch of two-digit directories and a gazillion files.
> 
> I could just copy the whole thing to one machine, there's gigabit between 
> them, but then what do I do with these files?

You can also use openembedded-core/scripts/sstate-diff-machines.sh
script to create just .sigdata files on both machines and then copy just
this sstate-diff directory, see header of that script for very short
readme.

> > bitbake -S just tries to automate that process if it can.
> >
> 
> bitbake -S usually crashes here.

Are you using latest bitbake? There was fix for that in newer bitbake already/

> Met vriendelijke groet / kind regards,
> 
> Mike Looijmans
> 
> TOPIC Embedded Systems
> Eindhovenseweg 32-C, NL-5683 KH Best
> Postbus 440, NL-5680 AK Best
> Telefoon: (+31) (0) 499 33 69 79
> Telefax:  (+31) (0) 499 33 69 70
> E-mail: mike.looijmans@topic.nl
> Website: www.topic.nl
> 
> Please consider the environment before printing this e-mail
> 
> Visit us at MEDTEC Europe 3-5 June, Messe Stuttgart, stand number 5D20
> http://medteceurope.com/index.php?page=home-en
> 
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

  parent reply	other threads:[~2014-06-03  8:31 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
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 [this message]
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=20140603083204.GN2426@jama \
    --to=martin.jansa@gmail.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.