9064 2016-02-04 22:31:10 +0000 do_unpack does not wipe old source tree 2016-08-12 13:33:57 +0000 1 1 7 Build System, Metadata & Runtime BitBake bitbake 2.0 All Multiple RESOLVED FIXED Medium+ major 2.2 M3 1 ross.burton ross.burton jose.perez.carranza markus.lehtonen poky.bs.watcher poky.watcher sgw libertad.gonzalez.de.la.cruz --- --- No (bug/feature does not impact docs) oldest_to_newest 58619 0 ross.burton 2016-02-04 22:31:10 +0000 In the past I could do bitbake -C unpack [recipe] to force a recipe to rebuild from scratch, because the unpack task will be tainted and thus the unpack runs again. It appears that now this is broken and if I do bitbake -C unpack it skips unpack and patch, going straight to configure. (I'm sure this worked a few weeks ago, so a bisect shouldn't be too long) 58707 1 eduard.bartosh 2016-02-07 19:48:10 +0000 Works for me just fine on master@4a2f42ff9e0f4359d1ee8290582f1b29a2202372: build (master)> bitbake -C unpack zlib -D |grep ' Executing task do_unpack' DEBUG: Executing task do_unpack 58715 2 ross.burton 2016-02-08 10:49:14 +0000 I'm *certain* I saw this not working as it was causing problems. Of course now I can't replicate. I'll see if I can make it break. 59040 3 ross.burton 2016-02-15 17:08:02 +0000 Managed to replicate this. 1) bitbake foo 2) touch a file in foo's ${S} 3) bitbake foo -C unpack The file that was created in (2) still exists but (3) should have removed the source tree before unpacking again. 59273 4 markus.lehtonen 2016-02-19 15:37:48 +0000 To me it seems bitbake works as expected. In most cases do_unpack just calls base_do_unpack(), which in turn, just extracts the source into ${S}. Not removing anything. So if you change something in ${S} it will be "reset" back to the expected orig state, but, if you create new files they are not removed. What recipe did you try this with? 59274 5 ross.burton 2016-02-19 15:51:30 +0000 My standard test is m4. I'm *sure* it used to erase before unpacking. If it didn't really, then maybe it should? 59310 6 markus.lehtonen 2016-02-20 07:56:31 +0000 I just tested with m4 on two random commits in poky: commit 23083e7e5e3a8ee81b346b2ee6084d9fc83e66b5 Date: Thu Dec 3 16:02:27 2015 -0600 commit 87c4e58dda0e2f62b0c8e4ddc6bec244643b21af Date: Thu Mar 19 16:05:03 2015 +0000 It didn't cleanup S{S}. So I don't think it has ever done that (unless there was some short period somewhere where it did that). But, I agree that it probably should clean it up. It would sound more consistent if the build would always operate on a pristine source tree. 59373 7 markus.lehtonen 2016-02-23 11:57:34 +0000 Patch submitted: http://lists.openembedded.org/pipermail/openembedded-core/2016-February/117916.html 60267 8 markus.lehtonen 2016-03-22 07:25:49 +0000 Moving to 2.1M4. I re-sent the patch: http://lists.openembedded.org/pipermail/openembedded-core/2016-March/119295.html 63958 9 ross.burton 2016-07-13 23:58:41 +0000 This was implicated in causing devtool selftest failures on the autobuilder: https://autobuilder.yoctoproject.org/main/builders/nightly-oe-selftest/builds/582/steps/Running%20oe-selftest/logs/stdio 64776 10 markus.lehtonen 2016-08-02 07:23:21 +0000 Ah, it breaks usage of externalsrc :( What do you think about modifying externalsrc.bbclass so that it won't wipe ${S} 64827 11 markus.lehtonen 2016-08-03 08:59:35 +0000 Version 3 of the patch: https://patchwork.openembedded.org/patch/128383/ 65069 12 ross.burton 2016-08-11 16:00:10 +0000 Merged in oe-core eccae514b71394ffaed8fc45dea7942152a334a1. Moving milestone as this missed M2.