A regression was introduced with commit: === commit dd15648fc2654b8d7c3e00ea7ab3dbf04f24f24b Date: Fri Sep 13 17:32:53 2013 +0100 cooker/command: Add finishcommand to reset cooker state After running a command on the server, it needs to reset to the initial state. This ensures that subsequent clients start from a known state and notice any configuration changes. Ultimately we may want to do more than this buts a good start and better than nothing. === The test is to run an operation twice where we expect that the cache should not reload or that the reload operation is extremely fast, vs a full cache reload. . oe-init-build-env-memres bitbake -c patch bash # Now there should be no cache reload on the second try bitbake -c patch bash
patch sent to bitbake ml
Removed 5535 from depends, because after investigation I found that there is a different issue. For #5535, the server should always be reseted, but for the current issue a sanity check for the cache is needed.
IMHO, this is not a bug, but an expected behaviour, see bug 5535. My point is that bug 5535 is in direct conflict with this bug, and I would expect a cooker reset and a full cache reload between build commands. The bitbake server should reload the configuration files and recipe caches between builds, since they may have changed. I think we need to revise this test.
Not a bug as per above comments.
Verified on master: d9d5b8b499af3ae01a1e33d0d3969c54c2d4ab1b Does not need TC, will be covered in TC for bug 6935