3239 2012-10-05 08:55:03 +0000 1.3_M5.rc2 patch task execution problem when building eglibc 2012-10-05 12:39:58 +0000 1 1 7 Build System, Metadata & Runtime OE-Core core 1.4 x86 Multiple RESOLVED INVALID Undecided normal --- 1 tf+bugs.yocto sgw meta.mr.watcher meta.watcher --- --- --- oldest_to_newest 26273 0 tf+bugs.yocto 2012-10-05 08:55:03 +0000 I run into a strange eglibc build failure due to tasks not being executed in the correct order; it happened on a fresh build of 1.3_M5.rc2, and was, I suspect, triggered initially by a corrupt eglibc tarball; the problem went away after manually removing the offending tarball and wiping out temp, but as it could not be fixed by running -c cleanall, I thought it's worth flagging it up as it suggests some underlying problem in the sstate management. The initial failure was in do_patch, due to incomplete src tree from the corrupt tarball; not Yocto fault, obviously, but I'd expect -c cleanall eglibc to fix this, which it did not: bitbake -c cleanall eglibc bitbake eglibc fails in the patch task because the patch task is being run *before* the fetch and unpack tasks have finished; If I run bitbake -c cleansstate eglibc bitbake -c unpack eglibc bitbake -c patch -f eglibc this succeeds; but note that the -f to the patch task is necessary, without it the patch execution is skipped, which should not happen after -c cleansstate I think. So now I try to run the rest of the build: bitbake eglibc but now the patch task is run *again* and fails (but not as expected because the file is already patched but because the file to patch cannot be found -- it would seem the rogue patch task is being run in the wrong directory). The above suggests I think there is a bug in maintaining the state for, at least, the patch task. 26283 1 tf+bugs.yocto 2012-10-05 12:39:58 +0000 OK, with Richard's help worked out what is going on: the initial corrupted tarball, of course, causes both eglibc and eglibc-initial to fail; what I missed in the output is that the repeated patch failure is, in fact, for elibc-initial, which I did not clean. So I am going to close this again as this is an operator error, not a bug.