> > It sounds like you're on the right track but there is a piece of > information which I can highlight: do_fetch is not an sstate > accelerated task. > > As such, I'd not expect a do_fetch task to come from sstate. What > happens is that a recipe's other sstate tasks (populate_sysroot, > package_write_XXX, package, package_qa, packagedata) come from sstate > and if that happens, tasks like fetch, configure, compile and so on > don't need to happen. > > I'd therefore look at the populate_sysroot task and compare the sigs > there. >
The tasks with sstate artifacts all have different hashes than the cached versions, It's a little hard to tell as I'm trying to grab logs of a CI system that cleans up build folders often, but I think this is following a task dependency chain back to the do_fetch. Given that the do_fetch in the stamps folder and the do_fetch in the cache have different task hashes wouldn't that imply that all the dependant tasks have different task hashes and need to re-run as well? (though unpack/configure etc to the package/deploy tasks with sstate artifacts beyond just siginfo files). > > Also, FWIW do_fetch can have task dependencies although you may be > right that yours does not. > Yes in this case from the siginfo it doesn't but I will bear it in mind. Is there something else that could be affecting the do_fetch task hash given that the sig info reports "Tasks this task depends on: []" and the base hash is unchanged? Thanks, Phil
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#63938): https://lists.yoctoproject.org/g/yocto/message/63938 Mute This Topic: https://lists.yoctoproject.org/mt/108814179/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
