<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 16, 2013 at 6:28 PM, Paul Eggleton <span dir="ltr"><<a href="mailto:paul.eggleton@linux.intel.com" target="_blank">paul.eggleton@linux.intel.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":k" style="overflow:hidden">I just got around to trying this again, only this time I cloned a new poky<br>
tree in a different path which should replicate your situation and used<br>
SSTATE_MIRRORS to point to the previous sstate-cache. It built completely from<br>
sstate as it expected. For reference I was testing with the latest dylan<br>
branch and core-image-minimal.<br>
<br>
As I said earlier, if you look at the code only the checksum value goes into<br>
the task checksum and not the filename, so the path to the base of the metadata<br>
changing cannot influence the task checksum. However, I think I can see how you<br>
would think that the paths changing influenced the checksum, since the data<br>
that we put into the siginfo file *does* contain the full path, and thus<br>
bitbake-diffsigs will report that as having changed even though that difference<br>
didn't change the task checksum. That is a bug and we should fix how we store<br>
paths either in the cache or in the siginfo file, but that fix will have to take<br>
into account different layer paths. I'd suggest a simpler and more reliable<br>
approach would be to just get the relative path to os.path.dirname of the<br>
recipe rather than TOPDIR.<br>
<br>
As far as I can tell though that won't actually fix the issue triggering<br>
rebuilds in your case. Something else must be changing. It would be<br>
interesting if you could dig into what that might be as I can't reproduce the<br>
rebuilding issue here.</div></blockquote></div><br>on a related topic, we have given a 'hands on workshop' last week at our Linaro Conference. in order to avoid potential network issues and wasting too much time building, we had prepared 'tarballs' for 1) download folder, 2) sstate</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">For sstate we have prepared a couple of such archive for OpenSuse and Ubuntu (12.04, 13.04) for both 32-bit and 64-bit variants.</div><div class="gmail_extra"><br>
</div><div class="gmail_extra">We used 'dylan' in our workshop since the archives were created a couple of days before, to avoid new commits in master. </div><div class="gmail_extra"><br></div><div class="gmail_extra">
Interesting remarks: </div><div class="gmail_extra"> - 'download' archive worked nicely for everyone</div><div class="gmail_extra"> - 'sstate' archive worked for some people, but not everyone. </div><div class="gmail_extra">
<br></div><div class="gmail_extra">In my particular case I was able to run a complete build from sstate without rebuilding *anything* using the 13.04-64 sstate tarball. but for some people it only used the sstate partially. I didn't get a chance to 'debug' what the problem was. but all our files are available in case some more folks want to play with them.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">You can download the archives here: <a href="http://people.linaro.org/~trevor.woerner/LCE2013/">http://people.linaro.org/~trevor.woerner/LCE2013/</a></div><div class="gmail_extra">
<br></div><div class="gmail_extra">And the instructions to recreate the 'build env' (e.g. checkout the layers) is described here: <a href="https://collaborate.linaro.org/x/NYBm">https://collaborate.linaro.org/x/NYBm</a> </div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div>