* sstate-cache question
@ 2017-05-22 14:53 Gary Thomas
2017-05-22 14:56 ` Gary Thomas
2017-05-22 20:35 ` Paul Eggleton
0 siblings, 2 replies; 11+ messages in thread
From: Gary Thomas @ 2017-05-22 14:53 UTC (permalink / raw)
To: yocto
I have a build where I've never manually removed anything from
the sstate-cache and this same build has been used for hundreds
of builds over the last 18 months. I just tried to find out why
gcc-cross-arm had to be rebuilt (it seems to happen almost every
time I update my Poky/Yocto tree (master)). Here's what I got:
$ bitbake-diffsigs -t gcc-cross-arm compile
Hash for dependent task gcc/gcc-cross_6.3.bb.do_configure changed from 208373dd9ae01101a26a9412eb50b110 to
d65095d4b9aff89f6990bd17c0ab210b
Unable to find matching sigdata for /local/poky-cutting-edge/meta/recipes-devtools/gcc/gcc-cross_6.3.bb.do_configure
with hashes 208373dd9ae01101a26a9412eb50b110 or d65095d4b9aff89f6990bd17c0ab210b
So if I didn't remove those files, where did they go? Am I doing
something wrong running this tool? (running the same command for
qemu-native seemed to work correctly)
Thanks for any ideas
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: sstate-cache question
2017-05-22 14:53 sstate-cache question Gary Thomas
@ 2017-05-22 14:56 ` Gary Thomas
2017-05-22 20:35 ` Paul Eggleton
1 sibling, 0 replies; 11+ messages in thread
From: Gary Thomas @ 2017-05-22 14:56 UTC (permalink / raw)
To: yocto
On 2017-05-22 16:53, Gary Thomas wrote:
> I have a build where I've never manually removed anything from
> the sstate-cache and this same build has been used for hundreds
^directory^
> of builds over the last 18 months. I just tried to find out why
> gcc-cross-arm had to be rebuilt (it seems to happen almost every
> time I update my Poky/Yocto tree (master)). Here's what I got:
>
> $ bitbake-diffsigs -t gcc-cross-arm compile
> Hash for dependent task gcc/gcc-cross_6.3.bb.do_configure changed from 208373dd9ae01101a26a9412eb50b110 to
> d65095d4b9aff89f6990bd17c0ab210b
> Unable to find matching sigdata for /local/poky-cutting-edge/meta/recipes-devtools/gcc/gcc-cross_6.3.bb.do_configure
> with hashes 208373dd9ae01101a26a9412eb50b110 or d65095d4b9aff89f6990bd17c0ab210b
>
> So if I didn't remove those files, where did they go? Am I doing
> something wrong running this tool? (running the same command for
> qemu-native seemed to work correctly)
>
> Thanks for any ideas
>
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: sstate-cache question
2017-05-22 14:53 sstate-cache question Gary Thomas
2017-05-22 14:56 ` Gary Thomas
@ 2017-05-22 20:35 ` Paul Eggleton
2017-05-23 5:27 ` Gary Thomas
1 sibling, 1 reply; 11+ messages in thread
From: Paul Eggleton @ 2017-05-22 20:35 UTC (permalink / raw)
To: Gary Thomas; +Cc: yocto
Hi Gary,
On Tuesday, 23 May 2017 2:53:45 AM NZST Gary Thomas wrote:
> I have a build where I've never manually removed anything from
> the sstate-cache and this same build has been used for hundreds
> of builds over the last 18 months. I just tried to find out why
> gcc-cross-arm had to be rebuilt (it seems to happen almost every
> time I update my Poky/Yocto tree (master)). Here's what I got:
>
> $ bitbake-diffsigs -t gcc-cross-arm compile
> Hash for dependent task gcc/gcc-cross_6.3.bb.do_configure changed from
208373dd9ae01101a26a9412eb50b110 to
> d65095d4b9aff89f6990bd17c0ab210b
> Unable to find matching sigdata for /local/poky-cutting-edge/meta/recipes-
devtools/gcc/gcc-cross_6.3.bb.do_configure
> with hashes 208373dd9ae01101a26a9412eb50b110 or
d65095d4b9aff89f6990bd17c0ab210b
>
> So if I didn't remove those files, where did they go? Am I doing
> something wrong running this tool? (running the same command for
> qemu-native seemed to work correctly)
Is this with master, pyro, morty or some other version?
If you search for files with those hashes in their name do they show up?
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: sstate-cache question
2017-05-22 20:35 ` Paul Eggleton
@ 2017-05-23 5:27 ` Gary Thomas
2017-05-23 10:42 ` Chris Z.
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Gary Thomas @ 2017-05-23 5:27 UTC (permalink / raw)
To: Paul Eggleton; +Cc: yocto
On 2017-05-22 22:35, Paul Eggleton wrote:
> Hi Gary,
>
> On Tuesday, 23 May 2017 2:53:45 AM NZST Gary Thomas wrote:
>> I have a build where I've never manually removed anything from
>> the sstate-cache and this same build has been used for hundreds
>> of builds over the last 18 months. I just tried to find out why
>> gcc-cross-arm had to be rebuilt (it seems to happen almost every
>> time I update my Poky/Yocto tree (master)). Here's what I got:
>>
>> $ bitbake-diffsigs -t gcc-cross-arm compile
>> Hash for dependent task gcc/gcc-cross_6.3.bb.do_configure changed from
> 208373dd9ae01101a26a9412eb50b110 to
>> d65095d4b9aff89f6990bd17c0ab210b
>> Unable to find matching sigdata for /local/poky-cutting-edge/meta/recipes-
> devtools/gcc/gcc-cross_6.3.bb.do_configure
>> with hashes 208373dd9ae01101a26a9412eb50b110 or
> d65095d4b9aff89f6990bd17c0ab210b
>>
>> So if I didn't remove those files, where did they go? Am I doing
>> something wrong running this tool? (running the same command for
>> qemu-native seemed to work correctly)
>
> Is this with master, pyro, morty or some other version?
Poky master: 2568e18701fb20d7105eb6e4929f3aff4b9f9c06
>
> If you search for files with those hashes in their name do they show up?
Only .siginfo files:
$ find sstate-cache/ -name "*d65095d4b9aff89f6990bd17c0ab210b*"
sstate-cache/universal/d6/sstate:gcc-cross-arm:x86_64-amltd-linux-gnueabi:6.3.0:r0:x86_64_arm:3:d65095d4b9aff89f6990bd17c0ab210b_configure.tgz.siginfo
$ find sstate-cache -name "*208373dd9ae01101a26a9412eb50b110*"
sstate-cache/universal/20/sstate:gcc-cross-arm:x86_64-amltd-linux-gnueabi:6.3.0:r0:x86_64_arm:3:208373dd9ae01101a26a9412eb50b110_configure.tgz.siginfo
However, I do find some in tmp/stamps:
$ ls tmp/stamps/x86_64-linux/gcc-cross-arm
6.3.0-r0.do_build.41aca0d85971087f4675d2f504642ce4
6.3.0-r0.do_compile.b0eae7e91833efd5e7eceaedbc59983e
6.3.0-r0.do_compile.sigdata.9a06aa40225be30babaceb7673cef0a6
6.3.0-r0.do_compile.sigdata.b0eae7e91833efd5e7eceaedbc59983e
6.3.0-r0.do_configure.d65095d4b9aff89f6990bd17c0ab210b
6.3.0-r0.do_configure.sigdata.208373dd9ae01101a26a9412eb50b110
6.3.0-r0.do_configure.sigdata.d65095d4b9aff89f6990bd17c0ab210b
6.3.0-r0.do_fetch.1dd3c87b3e509c20fa4ffe61d6dc3b41
6.3.0-r0.do_gcc_stash_builddir.063822f91220bb40cef0696eb604a568
6.3.0-r0.do_gcc_stash_builddir.sigdata.063822f91220bb40cef0696eb604a568
6.3.0-r0.do_gcc_stash_builddir.sigdata.28144d3c18c0a09f23f3b0c5e80f049d
6.3.0-r0.do_install.0f96c5448dc9360ca3a24d551ad3da89
6.3.0-r0.do_install.sigdata.0f96c5448dc9360ca3a24d551ad3da89
6.3.0-r0.do_install.sigdata.f2e4d12289c5039854081a832dc8bc0e
6.3.0-r0.do_populate_lic_setscene.d2c9226ddb0de5277e2347b69ef84664
6.3.0-r0.do_populate_sysroot.15afc3bb019a6c0c1285cbda46cb32b0
6.3.0-r0.do_populate_sysroot.sigdata.15afc3bb019a6c0c1285cbda46cb32b0
6.3.0-r0.do_populate_sysroot.sigdata.a0c5b715ae9217f02318beff6987d169
6.3.0-r0.do_prepare_recipe_sysroot.150112323551011e0e87f99f47ad79c4
6.3.0-r0.do_prepare_recipe_sysroot.sigdata.150112323551011e0e87f99f47ad79c4
6.3.0-r0.do_prepare_recipe_sysroot.sigdata.4a528becf11832cc3b8f6fa479e98210
I guess the sstate-cache info alone is not sufficient to use 'bitbake diffsigs'?
I do occasionally wipe tmp & downloads, so that may explain these errors.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: sstate-cache question
2017-05-23 5:27 ` Gary Thomas
@ 2017-05-23 10:42 ` Chris Z.
2017-05-25 4:36 ` Gary Thomas
2017-06-01 3:28 ` Paul Eggleton
2 siblings, 0 replies; 11+ messages in thread
From: Chris Z. @ 2017-05-23 10:42 UTC (permalink / raw)
To: Gary Thomas; +Cc: Paul Eggleton, yoctoproject
Hi,
@Gary
I guess the sstate-cache info alone is not sufficient to use 'bitbake diffsigs'?
Usage:
bitbake-diffsigs -t recipename taskname
bitbake-diffsigs sigdatafile1 sigdatafile2
bitbake-diffsigs sigdatafile1
Compares siginfo/sigdata files written out by BitBake
Options:
-h, --help show this help message and exit
-t recipename taskname, --task=recipename taskname
find the signature data files for last two runs of the
specified task and compare them
If I remember correctly sigdata is stored also in tmp/stamps/ when
you will use bitbake -S
More on debugging:
https://wiki.yoctoproject.org/wiki/TipsAndTricks/Understanding_what_changed_(diffsigs_etc)
Br,
Chris Z
On Tue, May 23, 2017 at 7:27 AM, Gary Thomas <gary@mlbassoc.com> wrote:
> On 2017-05-22 22:35, Paul Eggleton wrote:
>>
>> Hi Gary,
>>
>> On Tuesday, 23 May 2017 2:53:45 AM NZST Gary Thomas wrote:
>>>
>>> I have a build where I've never manually removed anything from
>>> the sstate-cache and this same build has been used for hundreds
>>> of builds over the last 18 months. I just tried to find out why
>>> gcc-cross-arm had to be rebuilt (it seems to happen almost every
>>> time I update my Poky/Yocto tree (master)). Here's what I got:
>>>
>>> $ bitbake-diffsigs -t gcc-cross-arm compile
>>> Hash for dependent task gcc/gcc-cross_6.3.bb.do_configure changed from
>>
>> 208373dd9ae01101a26a9412eb50b110 to
>>>
>>> d65095d4b9aff89f6990bd17c0ab210b
>>> Unable to find matching sigdata for
>>> /local/poky-cutting-edge/meta/recipes-
>>
>> devtools/gcc/gcc-cross_6.3.bb.do_configure
>>>
>>> with hashes 208373dd9ae01101a26a9412eb50b110 or
>>
>> d65095d4b9aff89f6990bd17c0ab210b
>>>
>>>
>>> So if I didn't remove those files, where did they go? Am I doing
>>> something wrong running this tool? (running the same command for
>>> qemu-native seemed to work correctly)
>>
>>
>> Is this with master, pyro, morty or some other version?
>
>
> Poky master: 2568e18701fb20d7105eb6e4929f3aff4b9f9c06
>
>>
>> If you search for files with those hashes in their name do they show up?
>
>
> Only .siginfo files:
> $ find sstate-cache/ -name "*d65095d4b9aff89f6990bd17c0ab210b*"
> sstate-cache/universal/d6/sstate:gcc-cross-arm:x86_64-amltd-linux-gnueabi:6.3.0:r0:x86_64_arm:3:d65095d4b9aff89f6990bd17c0ab210b_configure.tgz.siginfo
> $ find sstate-cache -name "*208373dd9ae01101a26a9412eb50b110*"
> sstate-cache/universal/20/sstate:gcc-cross-arm:x86_64-amltd-linux-gnueabi:6.3.0:r0:x86_64_arm:3:208373dd9ae01101a26a9412eb50b110_configure.tgz.siginfo
>
> However, I do find some in tmp/stamps:
> $ ls tmp/stamps/x86_64-linux/gcc-cross-arm
> 6.3.0-r0.do_build.41aca0d85971087f4675d2f504642ce4
> 6.3.0-r0.do_compile.b0eae7e91833efd5e7eceaedbc59983e
> 6.3.0-r0.do_compile.sigdata.9a06aa40225be30babaceb7673cef0a6
> 6.3.0-r0.do_compile.sigdata.b0eae7e91833efd5e7eceaedbc59983e
> 6.3.0-r0.do_configure.d65095d4b9aff89f6990bd17c0ab210b
> 6.3.0-r0.do_configure.sigdata.208373dd9ae01101a26a9412eb50b110
> 6.3.0-r0.do_configure.sigdata.d65095d4b9aff89f6990bd17c0ab210b
> 6.3.0-r0.do_fetch.1dd3c87b3e509c20fa4ffe61d6dc3b41
> 6.3.0-r0.do_gcc_stash_builddir.063822f91220bb40cef0696eb604a568
> 6.3.0-r0.do_gcc_stash_builddir.sigdata.063822f91220bb40cef0696eb604a568
> 6.3.0-r0.do_gcc_stash_builddir.sigdata.28144d3c18c0a09f23f3b0c5e80f049d
> 6.3.0-r0.do_install.0f96c5448dc9360ca3a24d551ad3da89
> 6.3.0-r0.do_install.sigdata.0f96c5448dc9360ca3a24d551ad3da89
> 6.3.0-r0.do_install.sigdata.f2e4d12289c5039854081a832dc8bc0e
> 6.3.0-r0.do_populate_lic_setscene.d2c9226ddb0de5277e2347b69ef84664
> 6.3.0-r0.do_populate_sysroot.15afc3bb019a6c0c1285cbda46cb32b0
> 6.3.0-r0.do_populate_sysroot.sigdata.15afc3bb019a6c0c1285cbda46cb32b0
> 6.3.0-r0.do_populate_sysroot.sigdata.a0c5b715ae9217f02318beff6987d169
> 6.3.0-r0.do_prepare_recipe_sysroot.150112323551011e0e87f99f47ad79c4
> 6.3.0-r0.do_prepare_recipe_sysroot.sigdata.150112323551011e0e87f99f47ad79c4
> 6.3.0-r0.do_prepare_recipe_sysroot.sigdata.4a528becf11832cc3b8f6fa479e98210
>
> I guess the sstate-cache info alone is not sufficient to use 'bitbake
> diffsigs'?
> I do occasionally wipe tmp & downloads, so that may explain these errors.
>
> --
> ------------------------------------------------------------
> Gary Thomas | Consulting for the
> MLB Associates | Embedded world
> ------------------------------------------------------------
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: sstate-cache question
2017-05-23 5:27 ` Gary Thomas
2017-05-23 10:42 ` Chris Z.
@ 2017-05-25 4:36 ` Gary Thomas
2017-05-27 2:11 ` Chris Z.
2017-06-01 3:28 ` Paul Eggleton
2 siblings, 1 reply; 11+ messages in thread
From: Gary Thomas @ 2017-05-25 4:36 UTC (permalink / raw)
To: yocto
On 2017-05-23 07:27, Gary Thomas wrote:
> On 2017-05-22 22:35, Paul Eggleton wrote:
>> Hi Gary,
>>
>> On Tuesday, 23 May 2017 2:53:45 AM NZST Gary Thomas wrote:
>>> I have a build where I've never manually removed anything from
>>> the sstate-cache and this same build has been used for hundreds
>>> of builds over the last 18 months. I just tried to find out why
>>> gcc-cross-arm had to be rebuilt (it seems to happen almost every
>>> time I update my Poky/Yocto tree (master)). Here's what I got:
>>>
>>> $ bitbake-diffsigs -t gcc-cross-arm compile
>>> Hash for dependent task gcc/gcc-cross_6.3.bb.do_configure changed from
>> 208373dd9ae01101a26a9412eb50b110 to
>>> d65095d4b9aff89f6990bd17c0ab210b
>>> Unable to find matching sigdata for /local/poky-cutting-edge/meta/recipes-
>> devtools/gcc/gcc-cross_6.3.bb.do_configure
>>> with hashes 208373dd9ae01101a26a9412eb50b110 or
>> d65095d4b9aff89f6990bd17c0ab210b
>>>
>>> So if I didn't remove those files, where did they go? Am I doing
>>> something wrong running this tool? (running the same command for
>>> qemu-native seemed to work correctly)
>>
>> Is this with master, pyro, morty or some other version?
>
> Poky master: 2568e18701fb20d7105eb6e4929f3aff4b9f9c06
>
>>
>> If you search for files with those hashes in their name do they show up?
>
> Only .siginfo files:
> $ find sstate-cache/ -name "*d65095d4b9aff89f6990bd17c0ab210b*"
> sstate-cache/universal/d6/sstate:gcc-cross-arm:x86_64-amltd-linux-gnueabi:6.3.0:r0:x86_64_arm:3:d65095d4b9aff89f6990bd17c0ab210b_configure.tgz.siginfo
>
> $ find sstate-cache -name "*208373dd9ae01101a26a9412eb50b110*"
> sstate-cache/universal/20/sstate:gcc-cross-arm:x86_64-amltd-linux-gnueabi:6.3.0:r0:x86_64_arm:3:208373dd9ae01101a26a9412eb50b110_configure.tgz.siginfo
>
>
> However, I do find some in tmp/stamps:
> $ ls tmp/stamps/x86_64-linux/gcc-cross-arm
> 6.3.0-r0.do_build.41aca0d85971087f4675d2f504642ce4
> 6.3.0-r0.do_compile.b0eae7e91833efd5e7eceaedbc59983e
> 6.3.0-r0.do_compile.sigdata.9a06aa40225be30babaceb7673cef0a6
> 6.3.0-r0.do_compile.sigdata.b0eae7e91833efd5e7eceaedbc59983e
> 6.3.0-r0.do_configure.d65095d4b9aff89f6990bd17c0ab210b
> 6.3.0-r0.do_configure.sigdata.208373dd9ae01101a26a9412eb50b110
> 6.3.0-r0.do_configure.sigdata.d65095d4b9aff89f6990bd17c0ab210b
> 6.3.0-r0.do_fetch.1dd3c87b3e509c20fa4ffe61d6dc3b41
> 6.3.0-r0.do_gcc_stash_builddir.063822f91220bb40cef0696eb604a568
> 6.3.0-r0.do_gcc_stash_builddir.sigdata.063822f91220bb40cef0696eb604a568
> 6.3.0-r0.do_gcc_stash_builddir.sigdata.28144d3c18c0a09f23f3b0c5e80f049d
> 6.3.0-r0.do_install.0f96c5448dc9360ca3a24d551ad3da89
> 6.3.0-r0.do_install.sigdata.0f96c5448dc9360ca3a24d551ad3da89
> 6.3.0-r0.do_install.sigdata.f2e4d12289c5039854081a832dc8bc0e
> 6.3.0-r0.do_populate_lic_setscene.d2c9226ddb0de5277e2347b69ef84664
> 6.3.0-r0.do_populate_sysroot.15afc3bb019a6c0c1285cbda46cb32b0
> 6.3.0-r0.do_populate_sysroot.sigdata.15afc3bb019a6c0c1285cbda46cb32b0
> 6.3.0-r0.do_populate_sysroot.sigdata.a0c5b715ae9217f02318beff6987d169
> 6.3.0-r0.do_prepare_recipe_sysroot.150112323551011e0e87f99f47ad79c4
> 6.3.0-r0.do_prepare_recipe_sysroot.sigdata.150112323551011e0e87f99f47ad79c4
> 6.3.0-r0.do_prepare_recipe_sysroot.sigdata.4a528becf11832cc3b8f6fa479e98210
>
> I guess the sstate-cache info alone is not sufficient to use 'bitbake diffsigs'?
> I do occasionally wipe tmp & downloads, so that may explain these errors.
>
I just updated my Poky/Yocto master (a3d160f9e5826140cc8d6b2ed1b38bf022443b08) and it happened again.
I'm still interested in why gcc-cross-arm had to be rebuilt _again_, so I ran:
$ bitbake-diffsigs -t gcc-cross-arm compile
NOTE: Started PRServer with DBfile: /build/p0382_2016-01-13/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 45466, PID: 7995
Hash for dependent task gcc/gcc-cross_6.3.bb.do_configure changed from d65095d4b9aff89f6990bd17c0ab210b to
1378c7a11d96284c3d53894d6434b590
Unable to find matching sigdata for /local/poky-cutting-edge/meta/recipes-devtools/gcc/gcc-cross_6.3.bb.do_configure
with hashes d65095d4b9aff89f6990bd17c0ab210b or 1378c7a11d96284c3d53894d6434b590
NOTE: Started PRServer with DBfile: /build/p0382_2016-01-13/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 45466, PID: 7995
NOTE: Terminating PRServer...
$ find tmp/stamps -name "*d65095d4b9aff89f6990bd17c0ab210b*" -or -name "*1378c7a11d96284c3d53894d6434b590*"
tmp/stamps/x86_64-linux/gcc-cross-arm/6.3.0-r0.do_configure.sigdata.1378c7a11d96284c3d53894d6434b590
tmp/stamps/x86_64-linux/gcc-cross-arm/6.3.0-r0.do_configure.sigdata.d65095d4b9aff89f6990bd17c0ab210b
tmp/stamps/x86_64-linux/gcc-cross-arm/6.3.0-r0.do_configure.1378c7a11d96284c3d53894d6434b590
So, a similar error/outcome, but in this case the necessary files
do seem to be present. I did notice that the only files with those
signatures were for do_configure, so I tried:
$ bitbake-diffsigs -t gcc-cross-arm configure
NOTE: Started PRServer with DBfile: /build/p0382_2016-01-13/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 34530, PID: 8063
Hash for dependent task gcc/gcc-cross_6.3.bb.do_prepare_recipe_sysroot changed from 150112323551011e0e87f99f47ad79c4 to
c45aaef0cb01f463f9a1b30bd815cd28
Unable to find matching sigdata for
/local/poky-cutting-edge/meta/recipes-devtools/gcc/gcc-cross_6.3.bb.do_prepare_recipe_sysroot with hashes
150112323551011e0e87f99f47ad79c4 or c45aaef0cb01f463f9a1b30bd815cd28
NOTE: Started PRServer with DBfile: /build/p0382_2016-01-13/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 34530, PID: 8063
NOTE: Terminating PRServer...
$ find tmp/stamps -name "*150112323551011e0e87f99f47ad79c4*" -or -name "*c45aaef0cb01f463f9a1b30bd815cd28*"
tmp/stamps/x86_64-linux/gcc-cross-arm/6.3.0-r0.do_prepare_recipe_sysroot.c45aaef0cb01f463f9a1b30bd815cd28
tmp/stamps/x86_64-linux/gcc-cross-arm/6.3.0-r0.do_prepare_recipe_sysroot.sigdata.c45aaef0cb01f463f9a1b30bd815cd28
tmp/stamps/x86_64-linux/gcc-cross-arm/6.3.0-r0.do_prepare_recipe_sysroot.sigdata.150112323551011e0e87f99f47ad79c4
Still not working :-( What am I missing? How do I track this down
(both the issues with bitbake-diffsigs as well as why gcc-cross-arm
is being rebuilt)?
Thanks
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: sstate-cache question
2017-05-25 4:36 ` Gary Thomas
@ 2017-05-27 2:11 ` Chris Z.
0 siblings, 0 replies; 11+ messages in thread
From: Chris Z. @ 2017-05-27 2:11 UTC (permalink / raw)
To: Gary Thomas; +Cc: yoctoproject
Hi Gary,
Have you tried to check those:
tmp/stamps/x86_64-linux/gcc-cross-arm/6.3.0-r0.do_prepare_recipe_sysroot.sigdata.c45aaef0cb01f463f9a1b30bd815cd28
tmp/stamps/x86_64-linux/gcc-cross-arm/6.3.0-r0.do_prepare_recipe_sysroot.sigdata.150112323551011e0e87f99f47ad79c4
with bitbake-diffsigs ? Maybe it's monkey work but last time I had to
debug such issue I had to recursively check those tasks which differ
to find root cause.
Br,
Chris Z
On Thu, May 25, 2017 at 6:36 AM, Gary Thomas <gary@mlbassoc.com> wrote:
> On 2017-05-23 07:27, Gary Thomas wrote:
>>
>> On 2017-05-22 22:35, Paul Eggleton wrote:
>>>
>>> Hi Gary,
>>>
>>> On Tuesday, 23 May 2017 2:53:45 AM NZST Gary Thomas wrote:
>>>>
>>>> I have a build where I've never manually removed anything from
>>>> the sstate-cache and this same build has been used for hundreds
>>>> of builds over the last 18 months. I just tried to find out why
>>>> gcc-cross-arm had to be rebuilt (it seems to happen almost every
>>>> time I update my Poky/Yocto tree (master)). Here's what I got:
>>>>
>>>> $ bitbake-diffsigs -t gcc-cross-arm compile
>>>> Hash for dependent task gcc/gcc-cross_6.3.bb.do_configure changed from
>>>
>>> 208373dd9ae01101a26a9412eb50b110 to
>>>>
>>>> d65095d4b9aff89f6990bd17c0ab210b
>>>> Unable to find matching sigdata for
>>>> /local/poky-cutting-edge/meta/recipes-
>>>
>>> devtools/gcc/gcc-cross_6.3.bb.do_configure
>>>>
>>>> with hashes 208373dd9ae01101a26a9412eb50b110 or
>>>
>>> d65095d4b9aff89f6990bd17c0ab210b
>>>>
>>>>
>>>> So if I didn't remove those files, where did they go? Am I doing
>>>> something wrong running this tool? (running the same command for
>>>> qemu-native seemed to work correctly)
>>>
>>>
>>> Is this with master, pyro, morty or some other version?
>>
>>
>> Poky master: 2568e18701fb20d7105eb6e4929f3aff4b9f9c06
>>
>>>
>>> If you search for files with those hashes in their name do they show up?
>>
>>
>> Only .siginfo files:
>> $ find sstate-cache/ -name "*d65095d4b9aff89f6990bd17c0ab210b*"
>>
>> sstate-cache/universal/d6/sstate:gcc-cross-arm:x86_64-amltd-linux-gnueabi:6.3.0:r0:x86_64_arm:3:d65095d4b9aff89f6990bd17c0ab210b_configure.tgz.siginfo
>> $ find sstate-cache -name "*208373dd9ae01101a26a9412eb50b110*"
>>
>> sstate-cache/universal/20/sstate:gcc-cross-arm:x86_64-amltd-linux-gnueabi:6.3.0:r0:x86_64_arm:3:208373dd9ae01101a26a9412eb50b110_configure.tgz.siginfo
>>
>> However, I do find some in tmp/stamps:
>> $ ls tmp/stamps/x86_64-linux/gcc-cross-arm
>> 6.3.0-r0.do_build.41aca0d85971087f4675d2f504642ce4
>> 6.3.0-r0.do_compile.b0eae7e91833efd5e7eceaedbc59983e
>> 6.3.0-r0.do_compile.sigdata.9a06aa40225be30babaceb7673cef0a6
>> 6.3.0-r0.do_compile.sigdata.b0eae7e91833efd5e7eceaedbc59983e
>> 6.3.0-r0.do_configure.d65095d4b9aff89f6990bd17c0ab210b
>> 6.3.0-r0.do_configure.sigdata.208373dd9ae01101a26a9412eb50b110
>> 6.3.0-r0.do_configure.sigdata.d65095d4b9aff89f6990bd17c0ab210b
>> 6.3.0-r0.do_fetch.1dd3c87b3e509c20fa4ffe61d6dc3b41
>> 6.3.0-r0.do_gcc_stash_builddir.063822f91220bb40cef0696eb604a568
>> 6.3.0-r0.do_gcc_stash_builddir.sigdata.063822f91220bb40cef0696eb604a568
>> 6.3.0-r0.do_gcc_stash_builddir.sigdata.28144d3c18c0a09f23f3b0c5e80f049d
>> 6.3.0-r0.do_install.0f96c5448dc9360ca3a24d551ad3da89
>> 6.3.0-r0.do_install.sigdata.0f96c5448dc9360ca3a24d551ad3da89
>> 6.3.0-r0.do_install.sigdata.f2e4d12289c5039854081a832dc8bc0e
>> 6.3.0-r0.do_populate_lic_setscene.d2c9226ddb0de5277e2347b69ef84664
>> 6.3.0-r0.do_populate_sysroot.15afc3bb019a6c0c1285cbda46cb32b0
>> 6.3.0-r0.do_populate_sysroot.sigdata.15afc3bb019a6c0c1285cbda46cb32b0
>> 6.3.0-r0.do_populate_sysroot.sigdata.a0c5b715ae9217f02318beff6987d169
>> 6.3.0-r0.do_prepare_recipe_sysroot.150112323551011e0e87f99f47ad79c4
>>
>> 6.3.0-r0.do_prepare_recipe_sysroot.sigdata.150112323551011e0e87f99f47ad79c4
>>
>> 6.3.0-r0.do_prepare_recipe_sysroot.sigdata.4a528becf11832cc3b8f6fa479e98210
>>
>> I guess the sstate-cache info alone is not sufficient to use 'bitbake
>> diffsigs'?
>> I do occasionally wipe tmp & downloads, so that may explain these errors.
>>
>
> I just updated my Poky/Yocto master
> (a3d160f9e5826140cc8d6b2ed1b38bf022443b08) and it happened again.
> I'm still interested in why gcc-cross-arm had to be rebuilt _again_, so I
> ran:
>
> $ bitbake-diffsigs -t gcc-cross-arm compile
> NOTE: Started PRServer with DBfile:
> /build/p0382_2016-01-13/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 45466,
> PID: 7995
> Hash for dependent task gcc/gcc-cross_6.3.bb.do_configure changed from
> d65095d4b9aff89f6990bd17c0ab210b to 1378c7a11d96284c3d53894d6434b590
> Unable to find matching sigdata for
> /local/poky-cutting-edge/meta/recipes-devtools/gcc/gcc-cross_6.3.bb.do_configure
> with hashes d65095d4b9aff89f6990bd17c0ab210b or
> 1378c7a11d96284c3d53894d6434b590
> NOTE: Started PRServer with DBfile:
> /build/p0382_2016-01-13/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 45466,
> PID: 7995
> NOTE: Terminating PRServer...
> $ find tmp/stamps -name "*d65095d4b9aff89f6990bd17c0ab210b*" -or -name
> "*1378c7a11d96284c3d53894d6434b590*"
> tmp/stamps/x86_64-linux/gcc-cross-arm/6.3.0-r0.do_configure.sigdata.1378c7a11d96284c3d53894d6434b590
> tmp/stamps/x86_64-linux/gcc-cross-arm/6.3.0-r0.do_configure.sigdata.d65095d4b9aff89f6990bd17c0ab210b
> tmp/stamps/x86_64-linux/gcc-cross-arm/6.3.0-r0.do_configure.1378c7a11d96284c3d53894d6434b590
>
> So, a similar error/outcome, but in this case the necessary files
> do seem to be present. I did notice that the only files with those
> signatures were for do_configure, so I tried:
>
> $ bitbake-diffsigs -t gcc-cross-arm configure
> NOTE: Started PRServer with DBfile:
> /build/p0382_2016-01-13/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 34530,
> PID: 8063
> Hash for dependent task gcc/gcc-cross_6.3.bb.do_prepare_recipe_sysroot
> changed from 150112323551011e0e87f99f47ad79c4 to
> c45aaef0cb01f463f9a1b30bd815cd28
> Unable to find matching sigdata for
> /local/poky-cutting-edge/meta/recipes-devtools/gcc/gcc-cross_6.3.bb.do_prepare_recipe_sysroot
> with hashes 150112323551011e0e87f99f47ad79c4 or
> c45aaef0cb01f463f9a1b30bd815cd28
> NOTE: Started PRServer with DBfile:
> /build/p0382_2016-01-13/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 34530,
> PID: 8063
> NOTE: Terminating PRServer...
> $ find tmp/stamps -name "*150112323551011e0e87f99f47ad79c4*" -or -name
> "*c45aaef0cb01f463f9a1b30bd815cd28*"
> tmp/stamps/x86_64-linux/gcc-cross-arm/6.3.0-r0.do_prepare_recipe_sysroot.c45aaef0cb01f463f9a1b30bd815cd28
> tmp/stamps/x86_64-linux/gcc-cross-arm/6.3.0-r0.do_prepare_recipe_sysroot.sigdata.c45aaef0cb01f463f9a1b30bd815cd28
> tmp/stamps/x86_64-linux/gcc-cross-arm/6.3.0-r0.do_prepare_recipe_sysroot.sigdata.150112323551011e0e87f99f47ad79c4
>
> Still not working :-( What am I missing? How do I track this down
> (both the issues with bitbake-diffsigs as well as why gcc-cross-arm
> is being rebuilt)?
>
> Thanks
>
>
> --
> ------------------------------------------------------------
> Gary Thomas | Consulting for the
> MLB Associates | Embedded world
> ------------------------------------------------------------
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: sstate-cache question
2017-05-23 5:27 ` Gary Thomas
2017-05-23 10:42 ` Chris Z.
2017-05-25 4:36 ` Gary Thomas
@ 2017-06-01 3:28 ` Paul Eggleton
2017-06-01 3:44 ` Gary Thomas
2 siblings, 1 reply; 11+ messages in thread
From: Paul Eggleton @ 2017-06-01 3:28 UTC (permalink / raw)
To: Gary Thomas; +Cc: yocto
Hi Gary,
My apologies, I just realised I never sent this reply.
On Tuesday, 23 May 2017 5:27:57 PM NZST you wrote:
> On 2017-05-22 22:35, Paul Eggleton wrote:
> > On Tuesday, 23 May 2017 2:53:45 AM NZST Gary Thomas wrote:
> >> I have a build where I've never manually removed anything from
> >> the sstate-cache and this same build has been used for hundreds
> >> of builds over the last 18 months. I just tried to find out why
> >> gcc-cross-arm had to be rebuilt (it seems to happen almost every
> >> time I update my Poky/Yocto tree (master)). Here's what I got:
> >>
> >> $ bitbake-diffsigs -t gcc-cross-arm compile
> >> Hash for dependent task gcc/gcc-cross_6.3.bb.do_configure changed from
> > 208373dd9ae01101a26a9412eb50b110 to
> >> d65095d4b9aff89f6990bd17c0ab210b
> >> Unable to find matching sigdata for /local/poky-cutting-edge/meta/
> >> recipes-devtools/gcc/gcc-cross_6.3.bb.do_configure
> >> with hashes 208373dd9ae01101a26a9412eb50b110 or
> > d65095d4b9aff89f6990bd17c0ab210b
> >>
> >> So if I didn't remove those files, where did they go? Am I doing
> >> something wrong running this tool? (running the same command for
> >> qemu-native seemed to work correctly)
> >
> > Is this with master, pyro, morty or some other version?
>
> Poky master: 2568e18701fb20d7105eb6e4929f3aff4b9f9c06
OK so this is definitely after my recent fixes then.
> > If you search for files with those hashes in their name do they show up?
>
> Only .siginfo files:
> $ find sstate-cache/ -name "*d65095d4b9aff89f6990bd17c0ab210b*"
> sstate-cache/universal/d6/sstate:gcc-cross-arm:x86_64-amltd-linux-gnueabi:
> 6.3.0:r0:x86_64_arm:3:d65095d4b9aff89f6990bd17c0ab210b_configure.tgz.siginfo
> $ find sstate-cache -name "*208373dd9ae01101a26a9412eb50b110*"
> sstate-cache/universal/20/sstate:gcc-cross-arm:x86_64-amltd-linux-gnueabi:
> 6.3.0:r0:x86_64_arm:3:208373dd9ae01101a26a9412eb50b110_configure.tgz.siginfo
>
> However, I do find some in tmp/stamps:
> $ ls tmp/stamps/x86_64-linux/gcc-cross-arm
> 6.3.0-r0.do_build.41aca0d85971087f4675d2f504642ce4
> 6.3.0-r0.do_compile.b0eae7e91833efd5e7eceaedbc59983e
> 6.3.0-r0.do_compile.sigdata.9a06aa40225be30babaceb7673cef0a6
> 6.3.0-r0.do_compile.sigdata.b0eae7e91833efd5e7eceaedbc59983e
> 6.3.0-r0.do_configure.d65095d4b9aff89f6990bd17c0ab210b
> 6.3.0-r0.do_configure.sigdata.208373dd9ae01101a26a9412eb50b110
> 6.3.0-r0.do_configure.sigdata.d65095d4b9aff89f6990bd17c0ab210b
> 6.3.0-r0.do_fetch.1dd3c87b3e509c20fa4ffe61d6dc3b41
> 6.3.0-r0.do_gcc_stash_builddir.063822f91220bb40cef0696eb604a568
> 6.3.0-r0.do_gcc_stash_builddir.sigdata.063822f91220bb40cef0696eb604a568
> 6.3.0-r0.do_gcc_stash_builddir.sigdata.28144d3c18c0a09f23f3b0c5e80f049d
> 6.3.0-r0.do_install.0f96c5448dc9360ca3a24d551ad3da89
> 6.3.0-r0.do_install.sigdata.0f96c5448dc9360ca3a24d551ad3da89
> 6.3.0-r0.do_install.sigdata.f2e4d12289c5039854081a832dc8bc0e
> 6.3.0-r0.do_populate_lic_setscene.d2c9226ddb0de5277e2347b69ef84664
> 6.3.0-r0.do_populate_sysroot.15afc3bb019a6c0c1285cbda46cb32b0
> 6.3.0-r0.do_populate_sysroot.sigdata.15afc3bb019a6c0c1285cbda46cb32b0
> 6.3.0-r0.do_populate_sysroot.sigdata.a0c5b715ae9217f02318beff6987d169
> 6.3.0-r0.do_prepare_recipe_sysroot.150112323551011e0e87f99f47ad79c4
> 6.3.0-r0.do_prepare_recipe_sysroot.sigdata.150112323551011e0e87f99f47ad79c4
> 6.3.0-r0.do_prepare_recipe_sysroot.sigdata.4a528becf11832cc3b8f6fa479e98210
>
> I guess the sstate-cache info alone is not sufficient to use 'bitbake
> diffsigs'?
It ought to be. At face value it should be finding the files in either place
- we'd need to debug the code to find out why it isn't. Is that something you
might be able to help me with?
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: sstate-cache question
2017-06-01 3:28 ` Paul Eggleton
@ 2017-06-01 3:44 ` Gary Thomas
2017-06-01 4:32 ` Paul Eggleton
0 siblings, 1 reply; 11+ messages in thread
From: Gary Thomas @ 2017-06-01 3:44 UTC (permalink / raw)
To: Paul Eggleton; +Cc: yocto
On 2017-06-01 05:28, Paul Eggleton wrote:
> Hi Gary,
>
> My apologies, I just realised I never sent this reply.
>
> On Tuesday, 23 May 2017 5:27:57 PM NZST you wrote:
>> On 2017-05-22 22:35, Paul Eggleton wrote:
>>> On Tuesday, 23 May 2017 2:53:45 AM NZST Gary Thomas wrote:
>>>> I have a build where I've never manually removed anything from
>>>> the sstate-cache and this same build has been used for hundreds
>>>> of builds over the last 18 months. I just tried to find out why
>>>> gcc-cross-arm had to be rebuilt (it seems to happen almost every
>>>> time I update my Poky/Yocto tree (master)). Here's what I got:
>>>>
>>>> $ bitbake-diffsigs -t gcc-cross-arm compile
>>>> Hash for dependent task gcc/gcc-cross_6.3.bb.do_configure changed from
>>> 208373dd9ae01101a26a9412eb50b110 to
>>>> d65095d4b9aff89f6990bd17c0ab210b
>>>> Unable to find matching sigdata for /local/poky-cutting-edge/meta/
>>>> recipes-devtools/gcc/gcc-cross_6.3.bb.do_configure
>>>> with hashes 208373dd9ae01101a26a9412eb50b110 or
>>> d65095d4b9aff89f6990bd17c0ab210b
>>>>
>>>> So if I didn't remove those files, where did they go? Am I doing
>>>> something wrong running this tool? (running the same command for
>>>> qemu-native seemed to work correctly)
>>>
>>> Is this with master, pyro, morty or some other version?
>>
>> Poky master: 2568e18701fb20d7105eb6e4929f3aff4b9f9c06
>
> OK so this is definitely after my recent fixes then.
>
>>> If you search for files with those hashes in their name do they show up?
>>
>> Only .siginfo files:
>> $ find sstate-cache/ -name "*d65095d4b9aff89f6990bd17c0ab210b*"
>> sstate-cache/universal/d6/sstate:gcc-cross-arm:x86_64-amltd-linux-gnueabi:
>> 6.3.0:r0:x86_64_arm:3:d65095d4b9aff89f6990bd17c0ab210b_configure.tgz.siginfo
>> $ find sstate-cache -name "*208373dd9ae01101a26a9412eb50b110*"
>> sstate-cache/universal/20/sstate:gcc-cross-arm:x86_64-amltd-linux-gnueabi:
>> 6.3.0:r0:x86_64_arm:3:208373dd9ae01101a26a9412eb50b110_configure.tgz.siginfo
>>
>> However, I do find some in tmp/stamps:
>> $ ls tmp/stamps/x86_64-linux/gcc-cross-arm
>> 6.3.0-r0.do_build.41aca0d85971087f4675d2f504642ce4
>> 6.3.0-r0.do_compile.b0eae7e91833efd5e7eceaedbc59983e
>> 6.3.0-r0.do_compile.sigdata.9a06aa40225be30babaceb7673cef0a6
>> 6.3.0-r0.do_compile.sigdata.b0eae7e91833efd5e7eceaedbc59983e
>> 6.3.0-r0.do_configure.d65095d4b9aff89f6990bd17c0ab210b
>> 6.3.0-r0.do_configure.sigdata.208373dd9ae01101a26a9412eb50b110
>> 6.3.0-r0.do_configure.sigdata.d65095d4b9aff89f6990bd17c0ab210b
>> 6.3.0-r0.do_fetch.1dd3c87b3e509c20fa4ffe61d6dc3b41
>> 6.3.0-r0.do_gcc_stash_builddir.063822f91220bb40cef0696eb604a568
>> 6.3.0-r0.do_gcc_stash_builddir.sigdata.063822f91220bb40cef0696eb604a568
>> 6.3.0-r0.do_gcc_stash_builddir.sigdata.28144d3c18c0a09f23f3b0c5e80f049d
>> 6.3.0-r0.do_install.0f96c5448dc9360ca3a24d551ad3da89
>> 6.3.0-r0.do_install.sigdata.0f96c5448dc9360ca3a24d551ad3da89
>> 6.3.0-r0.do_install.sigdata.f2e4d12289c5039854081a832dc8bc0e
>> 6.3.0-r0.do_populate_lic_setscene.d2c9226ddb0de5277e2347b69ef84664
>> 6.3.0-r0.do_populate_sysroot.15afc3bb019a6c0c1285cbda46cb32b0
>> 6.3.0-r0.do_populate_sysroot.sigdata.15afc3bb019a6c0c1285cbda46cb32b0
>> 6.3.0-r0.do_populate_sysroot.sigdata.a0c5b715ae9217f02318beff6987d169
>> 6.3.0-r0.do_prepare_recipe_sysroot.150112323551011e0e87f99f47ad79c4
>> 6.3.0-r0.do_prepare_recipe_sysroot.sigdata.150112323551011e0e87f99f47ad79c4
>> 6.3.0-r0.do_prepare_recipe_sysroot.sigdata.4a528becf11832cc3b8f6fa479e98210
>>
>> I guess the sstate-cache info alone is not sufficient to use 'bitbake
>> diffsigs'?
>
> It ought to be. At face value it should be finding the files in either place
> - we'd need to debug the code to find out why it isn't. Is that something you
> might be able to help me with?
>
Happy to give it a go, just let me know what you need
Thanks
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: sstate-cache question
2017-06-01 3:44 ` Gary Thomas
@ 2017-06-01 4:32 ` Paul Eggleton
2017-06-01 7:40 ` Gary Thomas
0 siblings, 1 reply; 11+ messages in thread
From: Paul Eggleton @ 2017-06-01 4:32 UTC (permalink / raw)
To: Gary Thomas; +Cc: yocto
On Thursday, 1 June 2017 3:44:49 PM NZST Gary Thomas wrote:
> On 2017-06-01 05:28, Paul Eggleton wrote:
> > It ought to be. At face value it should be finding the files in either
> > place - we'd need to debug the code to find out why it isn't. Is that
> > something you might be able to help me with?
>
> Happy to give it a go, just let me know what you need
Thanks. A first step would probably be to enable debug output with -d and see
what it reports in terms of the files being searched for.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: sstate-cache question
2017-06-01 4:32 ` Paul Eggleton
@ 2017-06-01 7:40 ` Gary Thomas
0 siblings, 0 replies; 11+ messages in thread
From: Gary Thomas @ 2017-06-01 7:40 UTC (permalink / raw)
To: Paul Eggleton; +Cc: yocto
On 2017-06-01 06:32, Paul Eggleton wrote:
> On Thursday, 1 June 2017 3:44:49 PM NZST Gary Thomas wrote:
>> On 2017-06-01 05:28, Paul Eggleton wrote:
>>> It ought to be. At face value it should be finding the files in either
>>> place - we'd need to debug the code to find out why it isn't. Is that
>>> something you might be able to help me with?
>>
>> Happy to give it a go, just let me know what you need
>
> Thanks. A first step would probably be to enable debug output with -d and see
> what it reports in terms of the files being searched for.
I didn't see much more info here:
$ bitbake-diffsigs -d -t gcc-cross-arm compile
NOTE: Started PRServer with DBfile: /build/p0382_2016-01-13/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 40390, PID: 10044
DEBUG: Signature file (previous):
/build/p0382_2016-01-13/tmp/stamps/x86_64-linux/gcc-cross-arm/6.3.0-r0.do_compile.sigdata.b0eae7e91833efd5e7eceaedbc59983e
DEBUG: Signature file (latest):
/build/p0382_2016-01-13/tmp/stamps/x86_64-linux/gcc-cross-arm/6.3.0-r0.do_compile.sigdata.84ca7d1957f1644215d99765ece65d9e
Hash for dependent task gcc/gcc-cross_6.3.bb.do_configure changed from d65095d4b9aff89f6990bd17c0ab210b to
1378c7a11d96284c3d53894d6434b590
Unable to find matching sigdata for /local/poky-cutting-edge/meta/recipes-devtools/gcc/gcc-cross_6.3.bb.do_configure
with hashes d65095d4b9aff89f6990bd17c0ab210b or 1378c7a11d96284c3d53894d6434b590
NOTE: Started PRServer with DBfile: /build/p0382_2016-01-13/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 40390, PID: 10044
NOTE: Terminating PRServer...
gthomas@europa:p0382_2016-01-13$ find tmp/stamps -name "*d65095d4b9aff89f6990bd17c0ab210b*" -or -name
"*1378c7a11d96284c3d53894d6434b590*"
tmp/stamps/x86_64-linux/gcc-cross-arm/6.3.0-r0.do_configure.sigdata.1378c7a11d96284c3d53894d6434b590
tmp/stamps/x86_64-linux/gcc-cross-arm/6.3.0-r0.do_configure.sigdata.d65095d4b9aff89f6990bd17c0ab210b
tmp/stamps/x86_64-linux/gcc-cross-arm/6.3.0-r0.do_configure.1378c7a11d96284c3d53894d6434b590
I've seen very nice back-trail type output where the program recursively lists
the tasks with changes until it finally settles, so I gave that a go manually:
$ bitbake-diffsigs -d -d -t gcc-cross-arm configure
NOTE: Started PRServer with DBfile: /build/p0382_2016-01-13/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 34193, PID: 10104
DEBUG: Signature file (previous):
/build/p0382_2016-01-13/tmp/stamps/x86_64-linux/gcc-cross-arm/6.3.0-r0.do_configure.sigdata.d65095d4b9aff89f6990bd17c0ab210b
DEBUG: Signature file (latest):
/build/p0382_2016-01-13/tmp/stamps/x86_64-linux/gcc-cross-arm/6.3.0-r0.do_configure.sigdata.1378c7a11d96284c3d53894d6434b590
Hash for dependent task gcc/gcc-cross_6.3.bb.do_prepare_recipe_sysroot changed from 150112323551011e0e87f99f47ad79c4 to
c45aaef0cb01f463f9a1b30bd815cd28
Unable to find matching sigdata for
/local/poky-cutting-edge/meta/recipes-devtools/gcc/gcc-cross_6.3.bb.do_prepare_recipe_sysroot with hashes
150112323551011e0e87f99f47ad79c4 or c45aaef0cb01f463f9a1b30bd815cd28
NOTE: Started PRServer with DBfile: /build/p0382_2016-01-13/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 34193, PID: 10104
NOTE: Terminating PRServer...
gthomas@europa:p0382_2016-01-13$ bitbake-diffsigs -d -d -t binutils-cross-arm populate_sysroot
NOTE: Started PRServer with DBfile: /build/p0382_2016-01-13/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 36611, PID: 10208
DEBUG: Signature file (previous):
/build/p0382_2016-01-13/tmp/stamps/x86_64-linux/binutils-cross-arm/2.28-r0.do_populate_sysroot.sigdata.60dbc717c23db51fc4322fe94cf60913
DEBUG: Signature file (latest):
/build/p0382_2016-01-13/tmp/stamps/x86_64-linux/binutils-cross-arm/2.28-r0.do_populate_sysroot.sigdata.2ed367f21ff6b6f36b05dde1983bc81d
Hash for dependent task binutils/binutils-cross_2.28.bb.do_install changed from 160c34a18c757a239c78889e6b4125b7 to
271845fc54aeec43d79afaf24cf0ebb4
Unable to find matching sigdata for
/local/poky-cutting-edge/meta/recipes-devtools/binutils/binutils-cross_2.28.bb.do_install with hashes
160c34a18c757a239c78889e6b4125b7 or 271845fc54aeec43d79afaf24cf0ebb4
NOTE: Started PRServer with DBfile: /build/p0382_2016-01-13/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 36611, PID: 10208
NOTE: Terminating PRServer...
gthomas@europa:p0382_2016-01-13$ bitbake-diffsigs -d -d -t binutils-cross-arm install
NOTE: Started PRServer with DBfile: /build/p0382_2016-01-13/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 37882, PID: 10221
DEBUG: Signature file (previous):
/build/p0382_2016-01-13/tmp/stamps/x86_64-linux/binutils-cross-arm/2.28-r0.do_install.sigdata.160c34a18c757a239c78889e6b4125b7
DEBUG: Signature file (latest):
/build/p0382_2016-01-13/tmp/stamps/x86_64-linux/binutils-cross-arm/2.28-r0.do_install.sigdata.271845fc54aeec43d79afaf24cf0ebb4
Hash for dependent task binutils/binutils-cross_2.28.bb.do_compile changed from 77a651f90acba2ae988ef9d906fce3b6 to
0f0a9186b50974acc0dde8674141aeda
Unable to find matching sigdata for
/local/poky-cutting-edge/meta/recipes-devtools/binutils/binutils-cross_2.28.bb.do_compile with hashes
77a651f90acba2ae988ef9d906fce3b6 or 0f0a9186b50974acc0dde8674141aeda
NOTE: Started PRServer with DBfile: /build/p0382_2016-01-13/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 37882, PID: 10221
NOTE: Terminating PRServer...
gthomas@europa:p0382_2016-01-13$ bitbake-diffsigs -d -d -t binutils-cross-arm compile
NOTE: Started PRServer with DBfile: /build/p0382_2016-01-13/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 41341, PID: 10234
DEBUG: Signature file (previous):
/build/p0382_2016-01-13/tmp/stamps/x86_64-linux/binutils-cross-arm/2.28-r0.do_compile.sigdata.77a651f90acba2ae988ef9d906fce3b6
DEBUG: Signature file (latest):
/build/p0382_2016-01-13/tmp/stamps/x86_64-linux/binutils-cross-arm/2.28-r0.do_compile.sigdata.0f0a9186b50974acc0dde8674141aeda
Hash for dependent task binutils/binutils-cross_2.28.bb.do_configure changed from 836554b225cdcb2fe809154e5335f8d7 to
89d1eff220293f794d96c2b6ad923fbb
Unable to find matching sigdata for
/local/poky-cutting-edge/meta/recipes-devtools/binutils/binutils-cross_2.28.bb.do_configure with hashes
836554b225cdcb2fe809154e5335f8d7 or 89d1eff220293f794d96c2b6ad923fbb
NOTE: Started PRServer with DBfile: /build/p0382_2016-01-13/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 41341, PID: 10234
NOTE: Terminating PRServer...
gthomas@europa:p0382_2016-01-13$ bitbake-diffsigs -d -d -t binutils-cross-arm configure
NOTE: Started PRServer with DBfile: /build/p0382_2016-01-13/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 34817, PID: 10246
gthomas@europa:p0382_2016-01-13$ bitbake-diffsigs -d -d -t binutils-cross-arm configure
NOTE: Started PRServer with DBfile: /build/p0382_2016-01-13/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 34817, PID: 10246
DEBUG: Signature file (previous):
/build/p0382_2016-01-13/tmp/stamps/x86_64-linux/binutils-cross-arm/2.28-r0.do_configure.sigdata.836554b225cdcb2fe809154e5335f8d7
DEBUG: Signature file (latest):
/build/p0382_2016-01-13/tmp/stamps/x86_64-linux/binutils-cross-arm/2.28-r0.do_configure.sigdata.89d1eff220293f794d96c2b6ad923fbb
Hash for dependent task binutils/binutils-cross_2.28.bb.do_prepare_recipe_sysroot changed from
c7aeed8c1bdfcf29bca91407e42bd4f9 to e31b5d78ee20994b02e6405b8f6e9e55
Unable to find matching sigdata for
/local/poky-cutting-edge/meta/recipes-devtools/binutils/binutils-cross_2.28.bb.do_prepare_recipe_sysroot with hashes
c7aeed8c1bdfcf29bca91407e42bd4f9 or e31b5d78ee20994b02e6405b8f6e9e55
NOTE: Started PRServer with DBfile: /build/p0382_2016-01-13/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 34817, PID: 10246
NOTE: Terminating PRServer...
gthomas@europa:p0382_2016-01-13$ bitbake-diffsigs -d -d -t binutils-cross-arm prepare_recipe_sysroot
NOTE: Started PRServer with DBfile: /build/p0382_2016-01-13/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 43542, PID: 10261
DEBUG: Signature file (previous):
/build/p0382_2016-01-13/tmp/stamps/x86_64-linux/binutils-cross-arm/2.28-r0.do_prepare_recipe_sysroot.sigdata.c7aeed8c1bdfcf29bca91407e42bd4f9
DEBUG: Signature file (latest):
/build/p0382_2016-01-13/tmp/stamps/x86_64-linux/binutils-cross-arm/2.28-r0.do_prepare_recipe_sysroot.sigdata.e31b5d78ee20994b02e6405b8f6e9e55
Hash for dependent task flex/flex_2.6.0.bb.do_populate_sysroot:virtual:native changed from
803870aa199689fc7ebe4bf052340b08 to 8671f84da160642ed9f3dc73b4c4cf25
Hash for dependent task flex/flex_2.6.0.bb.do_install:virtual:native changed from 15021a55c6f3b406fe0ec8c445ecf4bb to
d2f9d5f6b8cf3bc8bfa0afc11f604b26
Hash for dependent task flex/flex_2.6.0.bb.do_compile:virtual:native changed from 14ab5d1a366945bd300c4251adb40780
to 0270e3d57148c7c6d5ce6b9381d3c5ef
Hash for dependent task flex/flex_2.6.0.bb.do_configure:virtual:native changed from
03ca5f9dec1c8c0ed67d726e8459393d to a5bceb4ecfa3d0b1dd8b7d0e616c5386
Hash for dependent task flex/flex_2.6.0.bb.do_prepare_recipe_sysroot:virtual:native changed from
4b53b86cc1d850c3141b20656b0e6cee to 5db6825e2f7b2149bc14e863b90b6494
Hash for dependent task libtool/libtool-native_2.4.6.bb.do_populate_sysroot changed from
534965cfa73951508afd571c4950acc6 to 9e460d34c50195d38c5e00c9f6f31d68
Hash for dependent task libtool/libtool-native_2.4.6.bb.do_install changed from
c69723aaa815843eb30edc9fc5339e7b to 09ce0c427b39e469d84a6400b1e1422e
Hash for dependent task libtool/libtool-native_2.4.6.bb.do_compile changed from
0d445434af23d62d309f4263f54a54a5 to 68e46b072d25ff4ae3b976367139d29b
Hash for dependent task libtool/libtool-native_2.4.6.bb.do_configure changed from
06a03ebb367ea7c1b9f815249ec063da to d5d9f9278028f743d5a50bcaad6f163b
Hash for dependent task libtool/libtool-native_2.4.6.bb.do_prepare_recipe_sysroot changed from
43df7e3c672bf326d48358c87f0f0449 to ab843480e8e0e6e79007569ba0339fd7
Hash for dependent task automake/automake_1.15.bb.do_populate_sysroot:virtual:native changed from
0a44651cba1faf36d7bc4d477b6a5c7a to 0494b5a86330f82e7020055f1a934222
Hash for dependent task automake/automake_1.15.bb.do_install:virtual:native changed from
2a2bdcb315ecee2e79e462c74a6c8e9a to efcea8dc841eaf9cec211c02f138fa79
Hash for dependent task automake/automake_1.15.bb.do_compile:virtual:native changed from
7b100576aa812338aea2e2eca0f1ae75 to 8f8a135547d6a80d109af8450294f3a6
Hash for dependent task automake/automake_1.15.bb.do_configure:virtual:native changed from
cc27a4ecd28d1a46f74da0b445657e81 to 9e8a7cfd506133a84d67a9bff3b9c9c1
Hash for dependent task automake/automake_1.15.bb.do_prepare_recipe_sysroot:virtual:native
changed from 67db0a1d198eee4e3f605cc465080778 to 603ac9ef5e75181eb75859c1977cc4cc
Hash for dependent task automake/automake_1.15.bb.do_fetch:virtual:native changed from
7c7f1a657800704d2e749c8c6079ef92 to ab02e18b2632fbc5606746e88021a5cc
basehash changed from c2b3c6b61901e097efd83adeb0f5ead8 to 0f08750b29690602e317e0d9b15bf85d
Variable SRC_URI value changed:
"${GNU_MIRROR}/automake/automake-${PV}.tar.gz file://python-libdir.patch
file://buildtest.patch file://performance.patch file://new_rt_path_for_test-driver.patch
file://automake-replace-w-option-in-shebangs-with-modern-use-warnings.patch
{+file://0001-automake-port-to-Perl-5.22-and-later.patch+} {+ +}"
Dependency on checksum of file 0001-automake-port-to-Perl-5.22-and-later.patch was added
NOTE: Started PRServer with DBfile: /build/p0382_2016-01-13/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 43542, PID: 10261
NOTE: Terminating PRServer...
So, it finally got to the answer I was looking for - a change in automake (which seems to ripple everywhere)
Why was it able to back up at some point, but it stopped short before?
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2017-06-01 7:40 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-05-22 14:53 sstate-cache question Gary Thomas
2017-05-22 14:56 ` Gary Thomas
2017-05-22 20:35 ` Paul Eggleton
2017-05-23 5:27 ` Gary Thomas
2017-05-23 10:42 ` Chris Z.
2017-05-25 4:36 ` Gary Thomas
2017-05-27 2:11 ` Chris Z.
2017-06-01 3:28 ` Paul Eggleton
2017-06-01 3:44 ` Gary Thomas
2017-06-01 4:32 ` Paul Eggleton
2017-06-01 7:40 ` Gary Thomas
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.