Re: sstate info

[Gary Thomas <gary@mlbassoc.com>]

On 2012-01-12 06:37, Martin Jansa wrote:
> On Thu, Jan 12, 2012 at 06:31:01AM -0700, Gary Thomas wrote:
>> On 2012-01-12 06:13, Martin Jansa wrote:
>>> On Thu, Jan 12, 2012 at 02:57:21AM -0700, Gary Thomas wrote:
>>>> I'm trying to understand why sstate sometimes [most times in my case]
>>>> is not reusable.  Comparing some of the .siginfo files gives me some
>>>> info, e.g.
>>>>
>>>> $ bitbake-diffsigs p60_poky/sstate-cache/sstate-pseudo-native-i686-linux-1.2-r4-i686-2-66ad8e10f260d506d065831a738c04a3_populate-sysroot.tgz.siginfo
>>>> p60_test_pass1/sstate-cache/sstate-pseudo-native-i686-linux-1.2-r4-i686-2-c7e01d52b467bbe3af0556a43806521a_populate-sysroot.tgz.siginfo
>>>> Hash for dependent task virtual:nativepseudo_1.2.bb.do_install changed from 9edd41e331b29f08941225709c325a0d to 9865df7c4aa84fdb288c06faecf63426
>>>>
>>>> How do I figure out what went into the hash(es) that changed?
>>>
>>> Try to look in stamps directory
>>>
>>> something like:
>>> tmp-eglibc/stamps/x86_64-linux/pseudo-native-1.2-r4.do_install.sigdata.504f9aac443e1f135aa2d1cbcf84c614
>>
>> How can I interpret the contents of that file?
>
> find file for virtual:nativepseudo_1.2.bb.do_install
> with checksum 9edd41e331b29f08941225709c325a0d and
> with checksum 9865df7c4aa84fdb288c06faecf63426 and
> then compare them with bitbake-diffsigs again
>
> or use bitbake-diffsigs for one sigdata file

I worked this down to the do_patch in pseudo-native:
$ bitbake-diffsigs p60_poky/tmp/stamps/i686-linux/pseudo-native-1.2-r4.do_patch.sigdata.6e97a41d825568db298fdc9dbaed563c 
p60_test_pass1/tmp/stamps/i686-linux/pseudo-native-1.2-r4.do_patch.sigdata.a0d4e99625c211f4f1d793213014ac07
basehash changed from f5994d735ee2b909b72ee811364befc1 to 564be8db4146afa5fc3579dc4c1618d3
Variable DATE value changed from 20120110 to 20120111
Hash for dependent task quilt-native_0.50.bb.do_populate_sysroot changed from 9307106f3c5dfd49d953e206cb1b6da5 to 24151a370083d625b84a2afb77955021

Why is DATE as a variable important?
Why is it not ignored by this statement in ./meta/classes/patch.bbclass?
    patch_do_patch[vardepsexclude] = "DATE SRCDATE PATCHRESOLVE"

As is, it seems that the sstate cache is only good on the day it
was made :-(

Here's what I tried yesterday:
   * Create a new build, e.g.
     % . /local/poky/oe-init-build-env /local/test_pass1
     -- adjust local.conf to match desired target
     % bitbake core-image-minimal
   * Create a new build, using the previous one's sstate-cache
     % . /local/poky/oe-init-build-env /local/test_pass2
     -- adjust local.conf to match desired target
     -- enable sstate cache via these lines in local.conf:
          SSTATE_MIRRORS ?= "\
          file://.* file:///local/test_pass1/sstate-cache/"
     % bitbake core-image-minimal

This all went to plan - the sstate cache was reused for every package except
one.  For some reason, dbus-1 had to be rebuilt.

Today, I tried it again, just like the second step.  Low and behold, virtually
none of the sstate packages were reused :-(  This seems totally broken to me
and has been filed as bug #1896

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------