Created attachment 321 [details] Three log files: bitbake-20120113180834-Pq6.log, bitbake-20120113180945-WWq.log, and bitbake-20120113181019-NtT.log I was verifying an example in the YP Dev Manual and could not get it to work correctly using poky-contrib in the josh/edison branch. The example begins with section B.2, which changes the kernel configuration using menuconfig and then rebuilds the kernel image and runs it in qemu to look at the configuration. I worked a bit with Darren and he said the behavior here is strange and I should send the log files to you. Here are the commands used: cd ~/poky-contrib source oe-init-build-env log bitbake linux-yocto -c menuconfig log bitbake linux-yocto -c compile -f log bitbake linux-yocto -c deploy -f I am attaching the three log files. Here is more explanation from Darren.... Specifically the deploy command doesn't get run. If Scott just runs "bitbake linux-yocto" after the forced compile, it doesn't run any tasks (and it should run install->deploy->package). Maybe something wonky with the stamp files? I thought the deploy -f should ignore those though, so I can't explain why that doesn't work around the problem.
My impression is that this is a failure with bitbake not tracking the state properly. When a "bitbake $RECIPE -c compile -f" is run, it is my understanding that a subsequent "bitbake $RECIPE" command should pick up from the task following compile. Richard, would you agree? Or do you feel there is more investigation to be done for the kernel recipe itself? I'm marking this as High Major because this is a breakage in the defined Linux kernel workflow.
I'm trying to reproduce locally now.
FWIW I agree. The -f to the deploy task shouldn't be necessary.
Agreed, the -f should not be necessary - but note from the log that it did not work either. The deploy task was not run even with -f.
I agree that either way, whether you run "bitbake linux-yocto", "bitbake linux-yocto -c deploy" or add a -f too, it should rerun those tasks. The fact it doesn't is a clear bug.
This wasn't reproducible for me unfortunatley. I updated contrib/josh/edison and build for qemux86. I'm building with BB=14,PM=12, and only ipk. Otherwise my config should be mostly stock. I built on Ubuntu 11.10 64b. Scott, what are you building on? Have you tried this from a completely clean state?
Darren, My machine is 64-bit and runs Ubuntu 10.04 LTS. BB=4 and PM=4. MACHINE=qemux86. PACKAGE_CLASSES = package_rpm. I ran it after running the example in B.1, which is the one that changes the kernel source and inserts the printk statements that you see when you start qemu. I will completely wipe the slate and re-run everything clean. I am going to use poky-contrib as the Git repo. I will work from 'josh/edison' branch. I will also work from the 'edison' branch in the poky-extras repo I set up inside poky-contrib. Does this sound ok?
Scott, sounds good.
I ran this with a clean slate and in a very isolated manner that did not piggy-back on the previous example. The example worked as written. So this apparently is not a bug.