On Wed, 2014-05-28 at 13:46 -0700, Christopher Larson wrote: > > On Wed, May 28, 2014 at 1:42 PM, Khem Raj <raj.k...@gmail.com> wrote: > On Mon, May 26, 2014 at 11:58 PM, Mike Looijmans > <mike.looijm...@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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
