SSTATE builds more broken than I thought

SSTATE builds more broken than I thought

[Gary Thomas]

It seems that when you have SSTATE_MIRRORS enabled, certain
files are ending up in the wrong place.  In particular, there
are a bunch of files "*deploy-ipk*" being placed in ${OEROOT}/...!!

Here's what I just discovered after trying my little experiment
(bug #526) yesterday.

$ find /tmp/poky-master/ -name "*deploy-ipk*"
/tmp/poky-master/meta/recipes-kernel/linux/files/sstate-linux-wrs-qemuarm-poky-linux-gnueabi-2.6.34+git0+d1cd5c80ee97e81e130be8c3de3965b770f320d6_0+4f4177b4bea5b8858acc1eeb788d80b7af0df962-r12-armv5te-1-3559c0381a4081ae6e23a5ba8bc7d435_deploy-ipk.tgz
/tmp/poky-master/meta/recipes-core/images/sstate-poky-image-minimal-qemuarm-poky-linux-gnueabi-1.0-r0-armv5te-1-393bfe7f6b63c8fb85b7fbf1281a33a3_deploy-ipk.tgz
/tmp/poky-master/meta/recipes-core/tasks/sstate-task-poky-boot-qemuarm-poky-linux-gnueabi-1.0-r7-armv5te-1-6cceb5879edee4d66ae5644664ee4586_deploy-ipk.tgz
/tmp/poky-master/meta/recipes-extended/zypper/zypper/sstate-zypper-armv5te-poky-linux-gnueabi-1.4.7-git0+9eb0e248e06c8d20ad054be2439149d9ede37531-r1-armv5te-1-f6d39a32074b296543290cf29d982031_deploy-ipk.tgz
/tmp/poky-master/meta/recipes-extended/procps/procps-3.2.7/sstate-procps-armv5te-poky-linux-gnueabi-3.2.7-r9-armv5te-1-f65081285df4fe29a846cfebd18ca2ca_deploy-ipk.tgz

/tmp/poky-master is my original Poky (${OEROOT} in old terminology)
tree.  My build tree is somewhere totally different.

This was after building the same image.  If I build something new,
it gets much worse:

$ find /tmp/poky-master/ -name "*deploy-ipk*"
/tmp/poky-master/meta/recipes-support/libcap/sstate-libcap-armv5te-poky-linux-gnueabi-2.19-r1-armv5te-1-04f875e9f6b875a448302ae572f13c80_deploy-ipk.tgz
/tmp/poky-master/meta/recipes-support/libevent/sstate-libevent-armv5te-poky-linux-gnueabi-1.4.14b-r0-armv5te-1-d6dab558e9ae7defd7ba47bef5830330_deploy-ipk.tgz
/tmp/poky-master/meta/recipes-connectivity/nfs-utils/sstate-libnfsidmap-armv5te-poky-linux-gnueabi-0.23-r0-armv5te-1-1034a99ba6e20f1e4c21e2baa756d7bc_deploy-ipk.tgz
/tmp/poky-master/meta/recipes-connectivity/nfs-utils/nfs-utils/sstate-nfs-utils-armv5te-poky-linux-gnueabi-1.2.2-r1-armv5te-1-1857f64d548cfe271a6b6f43db03867e_deploy-ipk.tgz
/tmp/poky-master/meta/recipes-connectivity/portmap/portmap-6.0/sstate-portmap-armv5te-poky-linux-gnueabi-6.0-r7-armv5te-1-7aa6ab3c84b6fdb798f2e2865c8b0b85_deploy-ipk.tgz
/tmp/poky-master/meta/recipes-kernel/linux/files/sstate-linux-wrs-qemuarm-poky-linux-gnueabi-2.6.34+git0+d1cd5c80ee97e81e130be8c3de3965b770f320d6_0+4f4177b4bea5b8858acc1eeb788d80b7af0df962-r12-armv5te-1-3559c0381a4081ae6e23a5ba8bc7d435_deploy-ipk.tgz
/tmp/poky-master/meta/recipes-core/images/sstate-poky-image-minimal-qemuarm-poky-linux-gnueabi-1.0-r0-armv5te-1-393bfe7f6b63c8fb85b7fbf1281a33a3_deploy-ipk.tgz
/tmp/poky-master/meta/recipes-core/tasks/sstate-task-poky-boot-qemuarm-poky-linux-gnueabi-1.0-r7-armv5te-1-6cceb5879edee4d66ae5644664ee4586_deploy-ipk.tgz
/tmp/poky-master/meta/recipes-core/util-linux/util-linux-2.17.2/sstate-util-linux-armv5te-poky-linux-gnueabi-2.17.2-r1-armv5te-1-7150d2c180d3f6453a1555f2384e0ad6_deploy-ipk.tgz
/tmp/poky-master/meta/recipes-devtools/flex/sstate-flex-armv5te-poky-linux-gnueabi-2.5.35-r1-armv5te-1-9823f95f24a63065e045fab33ffc3b8a_deploy-ipk.tgz
/tmp/poky-master/meta/recipes-devtools/bison/bison/sstate-bison-armv5te-poky-linux-gnueabi-2.4.2-r0-armv5te-1-1617549c8529ac8e79ff62051cbf937e_deploy-ipk.tgz
/tmp/poky-master/meta/recipes-extended/pam/libpam-1.1.1/sstate-libpam-armv5te-poky-linux-gnueabi-1.1.1-r1-armv5te-1-19848d9fbff9cb63512c4f862321e2b9_deploy-ipk.tgz
/tmp/poky-master/meta/recipes-extended/tcp-wrappers/tcp-wrappers-7.6/sstate-tcp-wrappers-armv5te-poky-linux-gnueabi-7.6-r0-armv5te-1-9ea49de542653cd771ead8864ee1ec8e_deploy-ipk.tgz
/tmp/poky-master/meta/recipes-extended/zypper/zypper/sstate-zypper-armv5te-poky-linux-gnueabi-1.4.7-git0+9eb0e248e06c8d20ad054be2439149d9ede37531-r1-armv5te-1-f6d39a32074b296543290cf29d982031_deploy-ipk.tgz
/tmp/poky-master/meta/recipes-extended/procps/procps-3.2.7/sstate-procps-armv5te-poky-linux-gnueabi-3.2.7-r9-armv5te-1-f65081285df4fe29a846cfebd18ca2ca_deploy-ipk.tgz

Conclusion: when SSTATE_MIRRORS are enabled, some intermediate packages
are being written in the Poky (${OEROOT}) tree which should not be touched
by a build.

Filed as bug #533

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

Re: SSTATE builds more broken than I thought

[Richard Purdie]

On Wed, 2010-11-10 at 16:27 -0700, Gary Thomas wrote:
> It seems that when you have SSTATE_MIRRORS enabled, certain
> files are ending up in the wrong place.  In particular, there
> are a bunch of files "*deploy-ipk*" being placed in ${OEROOT}/...!!
> 
> Here's what I just discovered after trying my little experiment
> (bug #526) yesterday.
> 
> $ find /tmp/poky-master/ -name "*deploy-ipk*"
> /tmp/poky-master/meta/recipes-kernel/linux/files/sstate-linux-wrs-qemuarm-poky-linux-gnueabi-2.6.34+git0+d1cd5c80ee97e81e130be8c3de3965b770f320d6_0+4f4177b4bea5b8858acc1eeb788d80b7af0df962-r12-armv5te-1-3559c0381a4081ae6e23a5ba8bc7d435_deploy-ipk.tgz
> /tmp/poky-master/meta/recipes-core/images/sstate-poky-image-minimal-qemuarm-poky-linux-gnueabi-1.0-r0-armv5te-1-393bfe7f6b63c8fb85b7fbf1281a33a3_deploy-ipk.tgz
> /tmp/poky-master/meta/recipes-core/tasks/sstate-task-poky-boot-qemuarm-poky-linux-gnueabi-1.0-r7-armv5te-1-6cceb5879edee4d66ae5644664ee4586_deploy-ipk.tgz
> /tmp/poky-master/meta/recipes-extended/zypper/zypper/sstate-zypper-armv5te-poky-linux-gnueabi-1.4.7-git0+9eb0e248e06c8d20ad054be2439149d9ede37531-r1-armv5te-1-f6d39a32074b296543290cf29d982031_deploy-ipk.tgz
> /tmp/poky-master/meta/recipes-extended/procps/procps-3.2.7/sstate-procps-armv5te-poky-linux-gnueabi-3.2.7-r9-armv5te-1-f65081285df4fe29a846cfebd18ca2ca_deploy-ipk.tgz
> 
> /tmp/poky-master is my original Poky (${OEROOT} in old terminology)
> tree.  My build tree is somewhere totally different.
> 
> This was after building the same image.  If I build something new,
> it gets much worse:
> 
> $ find /tmp/poky-master/ -name "*deploy-ipk*"
> /tmp/poky-master/meta/recipes-support/libcap/sstate-libcap-armv5te-poky-linux-gnueabi-2.19-r1-armv5te-1-04f875e9f6b875a448302ae572f13c80_deploy-ipk.tgz
> /tmp/poky-master/meta/recipes-support/libevent/sstate-libevent-armv5te-poky-linux-gnueabi-1.4.14b-r0-armv5te-1-d6dab558e9ae7defd7ba47bef5830330_deploy-ipk.tgz
> /tmp/poky-master/meta/recipes-connectivity/nfs-utils/sstate-libnfsidmap-armv5te-poky-linux-gnueabi-0.23-r0-armv5te-1-1034a99ba6e20f1e4c21e2baa756d7bc_deploy-ipk.tgz
> /tmp/poky-master/meta/recipes-connectivity/nfs-utils/nfs-utils/sstate-nfs-utils-armv5te-poky-linux-gnueabi-1.2.2-r1-armv5te-1-1857f64d548cfe271a6b6f43db03867e_deploy-ipk.tgz
> /tmp/poky-master/meta/recipes-connectivity/portmap/portmap-6.0/sstate-portmap-armv5te-poky-linux-gnueabi-6.0-r7-armv5te-1-7aa6ab3c84b6fdb798f2e2865c8b0b85_deploy-ipk.tgz
> /tmp/poky-master/meta/recipes-kernel/linux/files/sstate-linux-wrs-qemuarm-poky-linux-gnueabi-2.6.34+git0+d1cd5c80ee97e81e130be8c3de3965b770f320d6_0+4f4177b4bea5b8858acc1eeb788d80b7af0df962-r12-armv5te-1-3559c0381a4081ae6e23a5ba8bc7d435_deploy-ipk.tgz
> /tmp/poky-master/meta/recipes-core/images/sstate-poky-image-minimal-qemuarm-poky-linux-gnueabi-1.0-r0-armv5te-1-393bfe7f6b63c8fb85b7fbf1281a33a3_deploy-ipk.tgz
> /tmp/poky-master/meta/recipes-core/tasks/sstate-task-poky-boot-qemuarm-poky-linux-gnueabi-1.0-r7-armv5te-1-6cceb5879edee4d66ae5644664ee4586_deploy-ipk.tgz
> /tmp/poky-master/meta/recipes-core/util-linux/util-linux-2.17.2/sstate-util-linux-armv5te-poky-linux-gnueabi-2.17.2-r1-armv5te-1-7150d2c180d3f6453a1555f2384e0ad6_deploy-ipk.tgz
> /tmp/poky-master/meta/recipes-devtools/flex/sstate-flex-armv5te-poky-linux-gnueabi-2.5.35-r1-armv5te-1-9823f95f24a63065e045fab33ffc3b8a_deploy-ipk.tgz
> /tmp/poky-master/meta/recipes-devtools/bison/bison/sstate-bison-armv5te-poky-linux-gnueabi-2.4.2-r0-armv5te-1-1617549c8529ac8e79ff62051cbf937e_deploy-ipk.tgz
> /tmp/poky-master/meta/recipes-extended/pam/libpam-1.1.1/sstate-libpam-armv5te-poky-linux-gnueabi-1.1.1-r1-armv5te-1-19848d9fbff9cb63512c4f862321e2b9_deploy-ipk.tgz
> /tmp/poky-master/meta/recipes-extended/tcp-wrappers/tcp-wrappers-7.6/sstate-tcp-wrappers-armv5te-poky-linux-gnueabi-7.6-r0-armv5te-1-9ea49de542653cd771ead8864ee1ec8e_deploy-ipk.tgz
> /tmp/poky-master/meta/recipes-extended/zypper/zypper/sstate-zypper-armv5te-poky-linux-gnueabi-1.4.7-git0+9eb0e248e06c8d20ad054be2439149d9ede37531-r1-armv5te-1-f6d39a32074b296543290cf29d982031_deploy-ipk.tgz
> /tmp/poky-master/meta/recipes-extended/procps/procps-3.2.7/sstate-procps-armv5te-poky-linux-gnueabi-3.2.7-r9-armv5te-1-f65081285df4fe29a846cfebd18ca2ca_deploy-ipk.tgz
> 
> Conclusion: when SSTATE_MIRRORS are enabled, some intermediate packages
> are being written in the Poky (${OEROOT}) tree which should not be touched
> by a build.
> 
> Filed as bug #533

Are these all files or are they symlinks? Are they just present for
deploy-ipk or are there others?

Cheers,

Richard

Re: SSTATE builds more broken than I thought

[Gary Thomas]

On 11/11/2010 10:32 PM, Richard Purdie wrote:
> On Wed, 2010-11-10 at 16:27 -0700, Gary Thomas wrote:
>> It seems that when you have SSTATE_MIRRORS enabled, certain
>> files are ending up in the wrong place.  In particular, there
>> are a bunch of files "*deploy-ipk*" being placed in ${OEROOT}/...!!
>>
>> Here's what I just discovered after trying my little experiment
>> (bug #526) yesterday.
>>
>> $ find /tmp/poky-master/ -name "*deploy-ipk*"
>> /tmp/poky-master/meta/recipes-kernel/linux/files/sstate-linux-wrs-qemuarm-poky-linux-gnueabi-2.6.34+git0+d1cd5c80ee97e81e130be8c3de3965b770f320d6_0+4f4177b4bea5b8858acc1eeb788d80b7af0df962-r12-armv5te-1-3559c0381a4081ae6e23a5ba8bc7d435_deploy-ipk.tgz
>> /tmp/poky-master/meta/recipes-core/images/sstate-poky-image-minimal-qemuarm-poky-linux-gnueabi-1.0-r0-armv5te-1-393bfe7f6b63c8fb85b7fbf1281a33a3_deploy-ipk.tgz
>> /tmp/poky-master/meta/recipes-core/tasks/sstate-task-poky-boot-qemuarm-poky-linux-gnueabi-1.0-r7-armv5te-1-6cceb5879edee4d66ae5644664ee4586_deploy-ipk.tgz
>> /tmp/poky-master/meta/recipes-extended/zypper/zypper/sstate-zypper-armv5te-poky-linux-gnueabi-1.4.7-git0+9eb0e248e06c8d20ad054be2439149d9ede37531-r1-armv5te-1-f6d39a32074b296543290cf29d982031_deploy-ipk.tgz
>> /tmp/poky-master/meta/recipes-extended/procps/procps-3.2.7/sstate-procps-armv5te-poky-linux-gnueabi-3.2.7-r9-armv5te-1-f65081285df4fe29a846cfebd18ca2ca_deploy-ipk.tgz
>>
>> /tmp/poky-master is my original Poky (${OEROOT} in old terminology)
>> tree.  My build tree is somewhere totally different.
>>
>> This was after building the same image.  If I build something new,
>> it gets much worse:
>>
>> $ find /tmp/poky-master/ -name "*deploy-ipk*"
>> /tmp/poky-master/meta/recipes-support/libcap/sstate-libcap-armv5te-poky-linux-gnueabi-2.19-r1-armv5te-1-04f875e9f6b875a448302ae572f13c80_deploy-ipk.tgz
>> /tmp/poky-master/meta/recipes-support/libevent/sstate-libevent-armv5te-poky-linux-gnueabi-1.4.14b-r0-armv5te-1-d6dab558e9ae7defd7ba47bef5830330_deploy-ipk.tgz
>> /tmp/poky-master/meta/recipes-connectivity/nfs-utils/sstate-libnfsidmap-armv5te-poky-linux-gnueabi-0.23-r0-armv5te-1-1034a99ba6e20f1e4c21e2baa756d7bc_deploy-ipk.tgz
>> /tmp/poky-master/meta/recipes-connectivity/nfs-utils/nfs-utils/sstate-nfs-utils-armv5te-poky-linux-gnueabi-1.2.2-r1-armv5te-1-1857f64d548cfe271a6b6f43db03867e_deploy-ipk.tgz
>> /tmp/poky-master/meta/recipes-connectivity/portmap/portmap-6.0/sstate-portmap-armv5te-poky-linux-gnueabi-6.0-r7-armv5te-1-7aa6ab3c84b6fdb798f2e2865c8b0b85_deploy-ipk.tgz
>> /tmp/poky-master/meta/recipes-kernel/linux/files/sstate-linux-wrs-qemuarm-poky-linux-gnueabi-2.6.34+git0+d1cd5c80ee97e81e130be8c3de3965b770f320d6_0+4f4177b4bea5b8858acc1eeb788d80b7af0df962-r12-armv5te-1-3559c0381a4081ae6e23a5ba8bc7d435_deploy-ipk.tgz
>> /tmp/poky-master/meta/recipes-core/images/sstate-poky-image-minimal-qemuarm-poky-linux-gnueabi-1.0-r0-armv5te-1-393bfe7f6b63c8fb85b7fbf1281a33a3_deploy-ipk.tgz
>> /tmp/poky-master/meta/recipes-core/tasks/sstate-task-poky-boot-qemuarm-poky-linux-gnueabi-1.0-r7-armv5te-1-6cceb5879edee4d66ae5644664ee4586_deploy-ipk.tgz
>> /tmp/poky-master/meta/recipes-core/util-linux/util-linux-2.17.2/sstate-util-linux-armv5te-poky-linux-gnueabi-2.17.2-r1-armv5te-1-7150d2c180d3f6453a1555f2384e0ad6_deploy-ipk.tgz
>> /tmp/poky-master/meta/recipes-devtools/flex/sstate-flex-armv5te-poky-linux-gnueabi-2.5.35-r1-armv5te-1-9823f95f24a63065e045fab33ffc3b8a_deploy-ipk.tgz
>> /tmp/poky-master/meta/recipes-devtools/bison/bison/sstate-bison-armv5te-poky-linux-gnueabi-2.4.2-r0-armv5te-1-1617549c8529ac8e79ff62051cbf937e_deploy-ipk.tgz
>> /tmp/poky-master/meta/recipes-extended/pam/libpam-1.1.1/sstate-libpam-armv5te-poky-linux-gnueabi-1.1.1-r1-armv5te-1-19848d9fbff9cb63512c4f862321e2b9_deploy-ipk.tgz
>> /tmp/poky-master/meta/recipes-extended/tcp-wrappers/tcp-wrappers-7.6/sstate-tcp-wrappers-armv5te-poky-linux-gnueabi-7.6-r0-armv5te-1-9ea49de542653cd771ead8864ee1ec8e_deploy-ipk.tgz
>> /tmp/poky-master/meta/recipes-extended/zypper/zypper/sstate-zypper-armv5te-poky-linux-gnueabi-1.4.7-git0+9eb0e248e06c8d20ad054be2439149d9ede37531-r1-armv5te-1-f6d39a32074b296543290cf29d982031_deploy-ipk.tgz
>> /tmp/poky-master/meta/recipes-extended/procps/procps-3.2.7/sstate-procps-armv5te-poky-linux-gnueabi-3.2.7-r9-armv5te-1-f65081285df4fe29a846cfebd18ca2ca_deploy-ipk.tgz
>>
>> Conclusion: when SSTATE_MIRRORS are enabled, some intermediate packages
>> are being written in the Poky (${OEROOT}) tree which should not be touched
>> by a build.
>>
>> Filed as bug #533
>
> Are these all files or are they symlinks? Are they just present for
> deploy-ipk or are there others?

They are files.

Sorry, but I don't understand your other question.  These are the only
extra files polluting the tree, except for Python *.py? object files
which are also always created.

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

Re: SSTATE builds more broken than I thought

[Richard Purdie]

On Fri, 2010-11-12 at 01:18 -0700, Gary Thomas wrote:
> > Are these all files or are they symlinks? Are they just present for
> > deploy-ipk or are there others?
> 
> They are files.
> 
> Sorry, but I don't understand your other question.  These are the only
> extra files polluting the tree, except for Python *.py? object files
> which are also always created.

Are there any files related to other sstate tasks such as
populate-sysroot*.tgz or package*.tgz or is there just *deploy-ipk*.tgz?

In other words I'm wondering if this is something specific to the
deploy-ipk sstate task...

Cheers,

Richard

Re: SSTATE builds more broken than I thought

[Gary Thomas]

On 11/12/2010 01:30 AM, Richard Purdie wrote:
> On Fri, 2010-11-12 at 01:18 -0700, Gary Thomas wrote:
>>> Are these all files or are they symlinks? Are they just present for
>>> deploy-ipk or are there others?
>>
>> They are files.
>>
>> Sorry, but I don't understand your other question.  These are the only
>> extra files polluting the tree, except for Python *.py? object files
>> which are also always created.
>
> Are there any files related to other sstate tasks such as
> populate-sysroot*.tgz or package*.tgz or is there just *deploy-ipk*.tgz?
>
> In other words I'm wondering if this is something specific to the
> deploy-ipk sstate task...

The only extra files created are *deploy-ipk*.tgz
This most certainly is restricted to the deploy-ipk sstate task and only
happens if SSTATE_MIRRORS is defined.

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

Re: SSTATE builds more broken than I thought

[Richard Purdie]

On Fri, 2010-11-12 at 01:35 -0700, Gary Thomas wrote:
> On 11/12/2010 01:30 AM, Richard Purdie wrote:
> > On Fri, 2010-11-12 at 01:18 -0700, Gary Thomas wrote:
> >>> Are these all files or are they symlinks? Are they just present for
> >>> deploy-ipk or are there others?
> >>
> >> They are files.
> >>
> >> Sorry, but I don't understand your other question.  These are the only
> >> extra files polluting the tree, except for Python *.py? object files
> >> which are also always created.
> >
> > Are there any files related to other sstate tasks such as
> > populate-sysroot*.tgz or package*.tgz or is there just *deploy-ipk*.tgz?
> >
> > In other words I'm wondering if this is something specific to the
> > deploy-ipk sstate task...
> 
> The only extra files created are *deploy-ipk*.tgz
> This most certainly is restricted to the deploy-ipk sstate task and only
> happens if SSTATE_MIRRORS is defined.

This should be fixed in ae98f7eacb9e61fe086d88dc694b4c651af9fee3, it
turns out to be an issue with the local fetcher not searching DL_DIR.

Cheers,

Richard

Re: SSTATE builds more broken than I thought

[Gary Thomas]

On 11/12/2010 04:31 PM, Richard Purdie wrote:
> On Fri, 2010-11-12 at 01:35 -0700, Gary Thomas wrote:
>> On 11/12/2010 01:30 AM, Richard Purdie wrote:
>>> On Fri, 2010-11-12 at 01:18 -0700, Gary Thomas wrote:
>>>>> Are these all files or are they symlinks? Are they just present for
>>>>> deploy-ipk or are there others?
>>>>
>>>> They are files.
>>>>
>>>> Sorry, but I don't understand your other question.  These are the only
>>>> extra files polluting the tree, except for Python *.py? object files
>>>> which are also always created.
>>>
>>> Are there any files related to other sstate tasks such as
>>> populate-sysroot*.tgz or package*.tgz or is there just *deploy-ipk*.tgz?
>>>
>>> In other words I'm wondering if this is something specific to the
>>> deploy-ipk sstate task...
>>
>> The only extra files created are *deploy-ipk*.tgz
>> This most certainly is restricted to the deploy-ipk sstate task and only
>> happens if SSTATE_MIRRORS is defined.
>
> This should be fixed in ae98f7eacb9e61fe086d88dc694b4c651af9fee3, it
> turns out to be an issue with the local fetcher not searching DL_DIR.

Trying the same process as in bug #526, it failed with this error:

NOTE: package gcc-cross-initial-4.5.0-r10: task do_fetch: Started
ERROR: Error in executing python function in: /local/poky-amltd/meta/recipes-devtools/gcc/gcc-cross-initial_4.5.0.bb
ERROR: Exception:<type 'exceptions.AttributeError'> Message:'module' object has no attribute 'exists'
NOTE: Running task 330 of 3106 (ID: 1534, /local/poky-amltd/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_2.6.34.bb, do_patch)
ERROR: Traceback:
ERROR:   File "base_do_fetch", line 64, in <module>
ERROR:
ERROR:   File "base_do_fetch", line 12, in base_do_fetch
ERROR:
ERROR:   File "/home/local/poky-amltd/scripts/..//bitbake/lib/bb/fetch/__init__.py", line 220, in init
ERROR:     urldata[url].setup_localpath(d)
ERROR:
ERROR:   File "/home/local/poky-amltd/scripts/..//bitbake/lib/bb/fetch/__init__.py", line 529, in setup_localpath
ERROR:     self.localpath = self.method.localpath(self.url, self, d)
ERROR:
ERROR:   File "/home/local/poky-amltd/scripts/..//bitbake/lib/bb/fetch/local.py", line 54, in localpath
ERROR:     if os.exists(dlpath):
ERROR:
ERROR: The lines leading to this error were:
ERROR:  0060:                                   bb.note("%s-%s: %s has no entry in conf/checksums.ini, not checking URI" % (pn,pv,uri))
ERROR:  0061:           except Exception:
ERROR:  0062:                   raise bb.build.FuncFailed("Checksum of '%s' failed" % uri)
ERROR:  0063:
ERROR: Task failed: ('Function base_do_fetch failed', '/home/local/poky-after-rp-fix/tmp/work/armv7a-poky-linux-gnueabi/gcc-cross-initial-4.5.0-r10/temp/log.do_fetch.2110')

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

Re: SSTATE builds more broken than I thought

[Richard Purdie]

On Fri, 2010-11-12 at 16:55 -0700, Gary Thomas wrote:
> On 11/12/2010 04:31 PM, Richard Purdie wrote:
> > On Fri, 2010-11-12 at 01:35 -0700, Gary Thomas wrote:
> >> On 11/12/2010 01:30 AM, Richard Purdie wrote:
> >>> On Fri, 2010-11-12 at 01:18 -0700, Gary Thomas wrote:
> >>>>> Are these all files or are they symlinks? Are they just present for
> >>>>> deploy-ipk or are there others?
> >>>>
> >>>> They are files.
> >>>>
> >>>> Sorry, but I don't understand your other question.  These are the only
> >>>> extra files polluting the tree, except for Python *.py? object files
> >>>> which are also always created.
> >>>
> >>> Are there any files related to other sstate tasks such as
> >>> populate-sysroot*.tgz or package*.tgz or is there just *deploy-ipk*.tgz?
> >>>
> >>> In other words I'm wondering if this is something specific to the
> >>> deploy-ipk sstate task...
> >>
> >> The only extra files created are *deploy-ipk*.tgz
> >> This most certainly is restricted to the deploy-ipk sstate task and only
> >> happens if SSTATE_MIRRORS is defined.
> >
> > This should be fixed in ae98f7eacb9e61fe086d88dc694b4c651af9fee3, it
> > turns out to be an issue with the local fetcher not searching DL_DIR.
> 
> Trying the same process as in bug #526, it failed with this error:
[...]

Right, I messed up those commits. I should know better than make commits
when travelling and jetlagged.

I ended up reverting the first fixes and pushing a set of different
fixes.

Previously you (and I think Kevin Tian) reporting bitbake spending a
huge amount of time thinking about shared state. When I was debugging
this I noticed a potential cause of that, my local test setups were
evidently just too fast to notice it. I added another commit:

http://git.pokylinux.org/cgit.cgi/poky/commit/?id=89929e1f283c8508c505c9731ad933880abf22a1

which should make things faster (n^2 faster where n is the number of
tasks).

Thanks again for testing and reporting the issues, I believe this code
will make a significant difference for people once it works reliably and
we're close to making that happen.

Cheers,

Richard

Re: SSTATE builds more broken than I thought

[Tian, Kevin]

>From: Richard Purdie
>Sent: Monday, November 15, 2010 1:58 AM
>
>On Fri, 2010-11-12 at 16:55 -0700, Gary Thomas wrote:
>> On 11/12/2010 04:31 PM, Richard Purdie wrote:
>> > On Fri, 2010-11-12 at 01:35 -0700, Gary Thomas wrote:
>> >> On 11/12/2010 01:30 AM, Richard Purdie wrote:
>> >>> On Fri, 2010-11-12 at 01:18 -0700, Gary Thomas wrote:
>> >>>>> Are these all files or are they symlinks? Are they just present for
>> >>>>> deploy-ipk or are there others?
>> >>>>
>> >>>> They are files.
>> >>>>
>> >>>> Sorry, but I don't understand your other question.  These are the only
>> >>>> extra files polluting the tree, except for Python *.py? object files
>> >>>> which are also always created.
>> >>>
>> >>> Are there any files related to other sstate tasks such as
>> >>> populate-sysroot*.tgz or package*.tgz or is there just *deploy-ipk*.tgz?
>> >>>
>> >>> In other words I'm wondering if this is something specific to the
>> >>> deploy-ipk sstate task...
>> >>
>> >> The only extra files created are *deploy-ipk*.tgz
>> >> This most certainly is restricted to the deploy-ipk sstate task and only
>> >> happens if SSTATE_MIRRORS is defined.
>> >
>> > This should be fixed in ae98f7eacb9e61fe086d88dc694b4c651af9fee3, it
>> > turns out to be an issue with the local fetcher not searching DL_DIR.
>>
>> Trying the same process as in bug #526, it failed with this error:
>[...]
>
>Right, I messed up those commits. I should know better than make commits
>when travelling and jetlagged.
>
>I ended up reverting the first fixes and pushing a set of different
>fixes.
>
>Previously you (and I think Kevin Tian) reporting bitbake spending a
>huge amount of time thinking about shared state. When I was debugging
>this I noticed a potential cause of that, my local test setups were
>evidently just too fast to notice it. I added another commit:
>
>http://git.pokylinux.org/cgit.cgi/poky/commit/?id=89929e1f283c8508c505c9731ad93388
>0abf22a1

thanks for the quick fix. I'll verify it later. If basehash/taskhash don't change,
the result should be soon. Or else another full rebuild is required as the prebuilt base.

btw, I have a quick scan about cases failing to reuse prebuilt (on a built in the weekend
at a commit before above commits), there're 31:

NOTE: package calibrateproto-0.0+git0+1da6fd1e2c7a49648245c98481fabea8b9690a8c-r2: task do_install: Succeeded
NOTE: package sat-solver-0.0-git0+aa799f7bae0ec055e0e527203635001bb7346dbc-r1: task do_install: Succeeded
NOTE: package bzip2-1.0.5-r3: task do_install: Succeeded
NOTE: package libxcalibrate-0.0+git0+209d83af61ed38a002c8096377deac292b3e396c-r0: task do_install: Succeeded
NOTE: package hal-0.5.14-r2: task do_install: Succeeded
NOTE: package task-poky-boot-1.0-r7: task do_install: Succeeded
NOTE: package trace-cmd-1.0.4+git0+0d252224626bd6926324f023a65f20c165232891-r1: task do_install: Succeeded
NOTE: package procps-3.2.7-r9: task do_install: Succeeded
NOTE: package xtscal-0.6.3-r12: task do_install: Succeeded
NOTE: package kexec-tools-2.0.1-r0: task do_install: Succeeded
NOTE: package poky-image-sato-1.0-r0: task do_install: Succeeded
NOTE: package connman-0.56-r2: task do_install: Succeeded
NOTE: package gnome-vfs-2.24.3-r0: task do_install: Succeeded
NOTE: package libzypp-0.0-git0+4494797d5b0369365b1af63921de45b197ead64f-r3: task do_install: Succeeded
NOTE: package oprofileui-0.0+svnr197-r0: task do_install: Succeeded
NOTE: package zypper-1.4.7-git0+9eb0e248e06c8d20ad054be2439149d9ede37531-r1: task do_install: Succeeded
NOTE: package gst-plugins-base-0.10.29-r1: task do_install: Succeeded
NOTE: package libowl-av-0.0+svnr398-r4: task do_install: Succeeded
NOTE: package gaku-0.0+svnr399-r3: task do_install: Succeeded
NOTE: package owl-video-0.0+svnr394-r2: task do_install: Succeeded
NOTE: package bluez4-4.66-r0: task do_install: Succeeded
NOTE: package gst-plugins-bad-0.10.19-r2: task do_install: Succeeded
NOTE: package eds-dbus-2.30+git0+7337d11aed576e7caaa12b4e881ad8d33668799f-r1: task do_install: Succeeded
NOTE: package tasks-0.16-r0: task do_install: Succeeded
NOTE: package dates-0.4.11+git0+514185dc1f6588085fda41eb59898b93d0487dd4-r0: task do_install: Succeeded
NOTE: package contacts-0.12+git0+19853893fdb595de6aa59db0d9dc2f9451ed2933-r0: task do_install: Succeeded
NOTE: package gst-plugins-good-0.10.23-r0: task do_install: Succeeded
NOTE: package gst-meta-base-0.10-r8: task do_install: Succeeded
NOTE: package linux-wrs-2.6.34+git0+5adcf6fbcd7491d8d3e1805929f575041d439235_0+aae69fdf104b0a9d7b3710f808aac6ab303490f7-r12: task do_install: Succeeded
NOTE: package webkit-gtk-1.3.2+svnr62027-r0: task do_install: Succeeded
NOTE: package web-webkit-0.0+svnr110-r2: task do_install: Succeeded

I haven't got time looking into all of them. For random 3 (bzip2, gnome-vfs, webkit-gtk),
they have the same symptom on populate_sysroot, e.g:

basehash changed from c7c1d0c7ea052eef6f6665b8959b44fc to 3eb4a010cbfb3b15df49d433f6593b0c
Variable BB_TASKHASH value changed from 9e077b25e1e2c50d4f8a09a9356a6a6c to 0d6608b425d8a59b21f5874b4914b412
Hash for dependent task /home/poky/tasks/poky/meta/recipes-extended/bzip2/bzip2_1.0.5.bb.do_install changed from c4cba89fa491ecb0916a56f1e75c5f17 to c4e7f58c385e384749cc20ca1bd8fccf

* basehash varies while no variable is explicitly listed by bitbake-diffsigs. I expected
to see the variable causing difference to be marked explicitly here.
* taskhash varies due to do_install, however bitbake-diffsigs doesn't list how do_install
checksum is calculated. I made a quick comparison between run.do_install scripts, with
major difference still on expanded variables. There may still have some whitelist work
to be done.

I used same source tree for two builds, which share same sstate-cache directory.

>
>which should make things faster (n^2 faster where n is the number of
>tasks).
>
>Thanks again for testing and reporting the issues, I believe this code
>will make a significant difference for people once it works reliably and
>we're close to making that happen.
>

Agree. :-)

Thanks,
Kevin

Re: SSTATE builds more broken than I thought

[Tian, Kevin]

>From: Tian, Kevin
>Sent: Monday, November 15, 2010 9:14 AM
>
>I haven't got time looking into all of them. For random 3 (bzip2, gnome-vfs, webkit-gtk),
>they have the same symptom on populate_sysroot, e.g:
>
>basehash changed from c7c1d0c7ea052eef6f6665b8959b44fc to
>3eb4a010cbfb3b15df49d433f6593b0c
>Variable BB_TASKHASH value changed from 9e077b25e1e2c50d4f8a09a9356a6a6c to
>0d6608b425d8a59b21f5874b4914b412
>Hash for dependent task
>/home/poky/tasks/poky/meta/recipes-extended/bzip2/bzip2_1.0.5.bb.do_install changed
>from c4cba89fa491ecb0916a56f1e75c5f17 to c4e7f58c385e384749cc20ca1bd8fccf
>
>* basehash varies while no variable is explicitly listed by bitbake-diffsigs. I expected
>to see the variable causing difference to be marked explicitly here.
>* taskhash varies due to do_install, however bitbake-diffsigs doesn't list how do_install
>checksum is calculated. I made a quick comparison between run.do_install scripts, with
>major difference still on expanded variables. There may still have some whitelist work
>to be done.
>
>I used same source tree for two builds, which share same sstate-cache directory.
>

Another interesting thing. When I compare other prebuilt tasks, all the rest tasks
show the difference on task dependencies of do_install, which then results in the
taskhash difference. Take 'package' for example:

---

Tasks this task depends on changed from set

(['GLIBCTARGETOS', 'TARGET_VENDOR', 'FILE', 'PACKAGES', 'PR', 'PV', 'package_do_package', 'DEPLOY_DIR', 'PF', 'PE', 'PN', 'package_rpm_do_package', 'MULTIMACH_TARGET_SYS', 'D', 'TARGET_ARCH', 'TARGET_OS', 'TMPDIR', 'PKGD', 'WORKDIR', 'PACKAGEFUNCS', 'EXTENDPE', 'MULTIMACH_ARCH', 'PACKAGE_PREPROCESS_FUNCS'])

to set

(['GLIBCTARGETOS', 'TARGET_VENDOR', 'FILE', 'PACKAGES', 'PR', 'PV', 'package_do_package', 'DEPLOY_DIR', 'PF', 'PE', 'PN', 'package_rpm_do_package', 'MULTIMACH_TARGET_SYS', 'D', 'TARGET_ARCH', 'TARGET_OS', 'TMPDIR', 'PKGD', 'WORKDIR', 'PACKAGEFUNCS', 'EXTENDPE', 'MULTIMACH_ARCH', 'PACKAGE_PREPROCESS_FUNCS'])

Hash for dependent task /home/poky/tasks/poky/meta/recipes-extended/bzip2/bzip2_1.0.5.bb.do_install changed from c4cba89fa491ecb0916a56f1e75c5f17 to c4e7f58c385e384749cc20ca1bd8fccf

---

First, I carefully checked above dependency list, which show NO difference at all.

Second, you can see the taskhash values actually match my earlier post about
populate_sysroot prebuilts. However at that place no dep info is shown except 
the hashvalue change.

I'll try more to see whether it's consistent.

Thanks
Kevin

Re: SSTATE builds more broken than I thought

[Tian, Kevin]

well, a typo in siggen.py causes below confusion, which I sent a pull request at:
http://git.pokylinux.org/cgit.cgi/poky-contrib/commit/?h=tk/master&id=e0df54e800a811c355a748308218edb33f963e9a

After clearing that out, the symptom of 31 cases could be refined as:

- all 4 sstate tasks vary (populate_sysroot, deploy_ipk, deploy_rpm, and package), and
all vary on do_install taskhash. do_install taskhash is same for 4 tasks in same build

- populate_sysroot has one more difference on basehash

- both basehash and taskhash differences don't list explicit variable differences

- it's always reproducible. I use bzip2 as the example. In original build providing sstate
prebuilts, bzip2 clean/rebuild always takes the desired prebuilts. In 2nd build using
prebuilts, bzip2 clean/rebuild always start from scratch with same checksum cross
the builds (by manually removing new prebuilts generated by itself)

- their native equivalents DO reuse prebuilts, such as bzip2-native

I may need have more debug into the execution process to catch the difference, but
I only have time back on this tomorrow. So if anyone else could reproduce it
and take some look, it'd be great. If we could make rest 31 recipes working, that
would really boost build performance, since several big time-consuming recipes fall
into this remaining group like kernel, webkit-gtk, etc.

Thanks
Kevin

>From: Tian, Kevin
>Sent: Monday, November 15, 2010 9:36 AM
>
>>From: Tian, Kevin
>>Sent: Monday, November 15, 2010 9:14 AM
>>
>>I haven't got time looking into all of them. For random 3 (bzip2, gnome-vfs, webkit-gtk),
>>they have the same symptom on populate_sysroot, e.g:
>>
>>basehash changed from c7c1d0c7ea052eef6f6665b8959b44fc to
>>3eb4a010cbfb3b15df49d433f6593b0c
>>Variable BB_TASKHASH value changed from 9e077b25e1e2c50d4f8a09a9356a6a6c to
>>0d6608b425d8a59b21f5874b4914b412
>>Hash for dependent task
>>/home/poky/tasks/poky/meta/recipes-extended/bzip2/bzip2_1.0.5.bb.do_install
>changed
>>from c4cba89fa491ecb0916a56f1e75c5f17 to c4e7f58c385e384749cc20ca1bd8fccf
>>
>>* basehash varies while no variable is explicitly listed by bitbake-diffsigs. I expected
>>to see the variable causing difference to be marked explicitly here.
>>* taskhash varies due to do_install, however bitbake-diffsigs doesn't list how do_install
>>checksum is calculated. I made a quick comparison between run.do_install scripts, with
>>major difference still on expanded variables. There may still have some whitelist work
>>to be done.
>>
>>I used same source tree for two builds, which share same sstate-cache directory.
>>
>
>Another interesting thing. When I compare other prebuilt tasks, all the rest tasks
>show the difference on task dependencies of do_install, which then results in the
>taskhash difference. Take 'package' for example:
>
>---
>
>Tasks this task depends on changed from set
>
>(['GLIBCTARGETOS', 'TARGET_VENDOR', 'FILE', 'PACKAGES', 'PR', 'PV',
>'package_do_package', 'DEPLOY_DIR', 'PF', 'PE', 'PN', 'package_rpm_do_package',
>'MULTIMACH_TARGET_SYS', 'D', 'TARGET_ARCH', 'TARGET_OS', 'TMPDIR', 'PKGD',
>'WORKDIR', 'PACKAGEFUNCS', 'EXTENDPE', 'MULTIMACH_ARCH',
>'PACKAGE_PREPROCESS_FUNCS'])
>
>to set
>
>(['GLIBCTARGETOS', 'TARGET_VENDOR', 'FILE', 'PACKAGES', 'PR', 'PV',
>'package_do_package', 'DEPLOY_DIR', 'PF', 'PE', 'PN', 'package_rpm_do_package',
>'MULTIMACH_TARGET_SYS', 'D', 'TARGET_ARCH', 'TARGET_OS', 'TMPDIR', 'PKGD',
>'WORKDIR', 'PACKAGEFUNCS', 'EXTENDPE', 'MULTIMACH_ARCH',
>'PACKAGE_PREPROCESS_FUNCS'])
>
>Hash for dependent task
>/home/poky/tasks/poky/meta/recipes-extended/bzip2/bzip2_1.0.5.bb.do_install changed
>from c4cba89fa491ecb0916a56f1e75c5f17 to c4e7f58c385e384749cc20ca1bd8fccf
>
>---
>
>First, I carefully checked above dependency list, which show NO difference at all.
>
>Second, you can see the taskhash values actually match my earlier post about
>populate_sysroot prebuilts. However at that place no dep info is shown except
>the hashvalue change.
>
>I'll try more to see whether it's consistent.
>
>Thanks
>Kevin

Re: SSTATE builds more broken than I thought

[Tian, Kevin]

>From: Richard Purdie
>Sent: Monday, November 15, 2010 1:58 AM
>To: Gary Thomas
>Cc: Poky
>Subject: Re: [poky] SSTATE builds more broken than I thought
>
>On Fri, 2010-11-12 at 16:55 -0700, Gary Thomas wrote:
>> On 11/12/2010 04:31 PM, Richard Purdie wrote:
>> > On Fri, 2010-11-12 at 01:35 -0700, Gary Thomas wrote:
>> >> On 11/12/2010 01:30 AM, Richard Purdie wrote:
>> >>> On Fri, 2010-11-12 at 01:18 -0700, Gary Thomas wrote:
>> >>>>> Are these all files or are they symlinks? Are they just present for
>> >>>>> deploy-ipk or are there others?
>> >>>>
>> >>>> They are files.
>> >>>>
>> >>>> Sorry, but I don't understand your other question.  These are the only
>> >>>> extra files polluting the tree, except for Python *.py? object files
>> >>>> which are also always created.
>> >>>
>> >>> Are there any files related to other sstate tasks such as
>> >>> populate-sysroot*.tgz or package*.tgz or is there just *deploy-ipk*.tgz?
>> >>>
>> >>> In other words I'm wondering if this is something specific to the
>> >>> deploy-ipk sstate task...
>> >>
>> >> The only extra files created are *deploy-ipk*.tgz
>> >> This most certainly is restricted to the deploy-ipk sstate task and only
>> >> happens if SSTATE_MIRRORS is defined.
>> >
>> > This should be fixed in ae98f7eacb9e61fe086d88dc694b4c651af9fee3, it
>> > turns out to be an issue with the local fetcher not searching DL_DIR.
>>
>> Trying the same process as in bug #526, it failed with this error:
>[...]
>
>Right, I messed up those commits. I should know better than make commits
>when travelling and jetlagged.
>
>I ended up reverting the first fixes and pushing a set of different
>fixes.
>
>Previously you (and I think Kevin Tian) reporting bitbake spending a
>huge amount of time thinking about shared state. When I was debugging
>this I noticed a potential cause of that, my local test setups were
>evidently just too fast to notice it. I added another commit:

how did your local test exactly setup?

>
>http://git.pokylinux.org/cgit.cgi/poky/commit/?id=89929e1f283c8508c505c9731ad93388
>0abf22a1
>
>which should make things faster (n^2 faster where n is the number of
>tasks).

I did a quick test just now, the result is not that promising. The total time
of sstate setscene took ~8min this time, however there're also less tasks
executed:

Previous run: ~25min, sstate-setscene starts from 133 of 1673 tasks
Current run: ~8min, sstate_setscene starts from 1283 of 1673 tasks

From the build process, there did have more recipes rebuilt from scratch
instead of taking prebuilt this time, such as gcc, etc. The build even didn't
finish, with C preprocessor sanity check failure on gcc-runtime.

This may not be a good test though, as I'm still using the prebuilts generated
from last week (at d9ff2f897aa271e6b2d7e4dcaf8b8d19de513b50), while
the 2nd build uses latest ddbf5e9c48afdeefeaec120a02d43536f5fd1ce1 plus
my siggen fix.

I'll redo a slow test by having both builds from the same commit, while keeping
original env for further analysis later.

Thanks
Kevin