If the do_package task is prebuilt instead of executed, we don't get any information about packages built for the recipe. Built packages information should be collected for both task types (prebuilt and executed).
Paul, any suggestion ?
This is the disadvantage of using events triggered from do_package; if do_package never happens you won't get the information delivered to you. Either: 1) Switch to an implementation that ensures the appropriate information is stored in pkgdata and retrieved at the end of the build, which will always be available; or 2) Look up the data from the previous run of this function from the earlier build (less desirable, because web hob might have been disabled the actual last time do_package was executed).
I would go with no 1) if we: a) decide on a policy to have a observing UI request hold-of-end-of-build from bitbake, so it has time to process the files on the system before the build ends and another controlling UI is accepted. Would this be acceptable ? b) add a command to bitbake server that will dump the contents of a file on disk; this is because if the bitbake server runs on a different machine, there is no local file access.
a) I think this has to happen anyway if we're to hope to do anything at the end. Without looking at the current implementation, surely if the controlling UI is still connected no other build should be able to be started unless by that controlling UI? b) Right; either we have a generic "get me this file/directory" or a number of specific "get me this specific information" calls.
review on poky-contrib:toaster/master edb12586c27ccddb054737ee6e081f663e2c60da
We have fixed this by displaying at least the set of packages installed if the build target is an image recipe. If the build target is not an image recipe, the built packages information is still empty if do_package does not execute. We'll address this with an empty state for the built packages page (see bug 4865).
verified in master:3ada51f7aa26fc95d5f9ba4498c0ea54acc6e42e