[yocto] task is executed even when sstate-cache md5 matches

[Pepe Perez]

I have however other targets in which do_fetch is not executed at all. Why sometimes is executed and why some others not...?Moreover, I did the test with three users: one populates the sstate-cache, a second resolves its build entirely from sstate and a third one in which do_fetch is executed
This is important for me because I'm working in a project in which do_fetch should not be executed, but always resolved with the sstate

      From: Richard Purdie <richard.purdie at linuxfoundation.org>
 To: Pepe Perez <pp.perez at yahoo.com>; "yocto at yoctoproject.org" <yocto at yoctoproject.org> 
 Sent: Wednesday, February 22, 2017 7:26 AM
 Subject: Re: [yocto] task is executed even when sstate-cache md5 matches
   
On Tue, 2017-02-21 at 06:30 +0000, Pepe Perez wrote:
> I have following siginfo packages:
> 
> Generated in my build sstate-cache
> build/sstate-cache/be/sstate:proc-
> fifo::1.0.3:r1::3:be9c419f0caa05042d43c03d576d2e15_fetch.tgz.siginfo
> 
> Previously existing in my build SSTATE_MIRRORS:
> /central/sstate-cache/be/sstate:proc-
> fifo::1.0.3:r1::3:be9c419f0caa05042d43c03d576d2e15_fetch.tgz.siginfo
> 
> I had many other targets where setscene was successful and no task
> was executed. Why fetch is executed in the target above, if md5 is a
> match?

do_fetch is not an sstate task and there is no ".tgz" file, only a
siginfo file which is data about how the checksum is constructed and
for debugging of other sstate checksums. Pulling the downloads from a
download mirror would likely be just as successful as it would be if
do_fetch were an sstate task.

Cheers,

Richard


   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20170222/ea7cf3fc/attachment.html>