linux/poky.git/bitbake/lib/bb/ui, branch 2.2_M2

bitbake: toaster: add package manifest path to Target objects

2016-07-19T07:56:52+00:00

Store the path to the *.rootfs.manifest file for targets which generate images. A link to the package manifest is displayed in the build dashboard for targets which produce image files. Like the license manifest path, if a target would have produced the package manifest (but didn't, because it already existed), that path is copied from the target which did produce the package manifest. (Bitbake rev: 79b8e349a0da2ea6b97ad82daa5837e6dfffe0af) Signed-off-by: Elliot Smith Signed-off-by: bavery Signed-off-by: Richard Purdie

bitbake: buildinfohelper: only record image files for tasks which make images

2016-07-19T07:56:51+00:00

If a target is built which is classified as an "image" target (e.g. "core-image-minimal"), Toaster reads the list of files in the image (from the files-in-image.txt file). However, Toaster continues to do this for builds which don't produce images, if the recipe providing the target is an image recipe. This can result in a list of files in the image being attached to a target which didn't produce an image (e.g. rootfs). When associating files with an image, ensure that only targets with a task which produces an image have "files in the image" associated with them. [YOCTO #9784] (Bitbake rev: 44375d0c2a88e0070b8067c9285b89c54eaf3152) Signed-off-by: Elliot Smith Signed-off-by: bavery Signed-off-by: Richard Purdie

bitbake: toaster: improve scan for SDK artifacts

2016-07-19T07:56:51+00:00

SDK artifacts were previously picked up by toaster.bbclass and notified to buildinfohelper (via toasterui). The artifacts were then added to the Build object, so that it wasn't clear which artifact went with which target; we were also unable to attach SDK artifacts to a Build if they had already been attached to a previous build. Now, toaster.bbclass just notifies the TOOLCHAIN_OUTPUTNAME when a populate_sdk* target completes. The scan is moved to buildinfohelper, where we search the SDK deploy directory for files matching TOOLCHAIN_OUTPUTNAME and attach them to targets (not builds). If an SDK file is not produced by a target, we now look for a similar, previously-run target which did produce artifacts. If there is one, we clone the SDK artifacts from that target onto the current one. This all means that we can show SDK artifacts by target, and should always get artifacts associated with a target, regardless of whether it really build them. This requires an additional model, TargetSDKFile, which tracks the size and path of SDK artifact files with respect to Target objects. [YOCTO #8556] (Bitbake rev: 5e650c611605507e1e0d1588cd5eb6535c2d34fc) Signed-off-by: Elliot Smith Signed-off-by: bavery Signed-off-by: Richard Purdie

bitbake: buildinfohelper: fix retrieval of targets

2016-07-19T07:56:51+00:00

When buildinfohelper records the targets for a build, it looks up any existing targets for a build and creates them if they are not present. This is because in the case of Toaster-triggered builds, the Target objects have already been created (inside triggerBuild()) and don't need to be recreated; but in the case of cli builds, the Target objects have to be created by buildinfohelper. The issue is that the code for retrieving an existing target for a build only looks for Targets with a matching target and build, e.g. Targets for build X with target "core-image-minimal". But it is perfectly legitimate to call bitbake with a command like "bitbake core-image-minimal:do_populate_sdk core-image-minimal:do_populate_sdk_ext". In such a case, the code which looks for matching targets finds two objects, as it doesn't filter by task. Add the task into the filter for the Target so that only one Target object is be returned. Note that a command line like "bitbake recipe:task recipe:task" will still cause an error as bitbake doesn't de-duplicate the command line arguments and will run the recipe:task combination twice. (Bitbake rev: 1c0a689fdaae6469d4afb98583161073d32ea50b) Signed-off-by: Elliot Smith Signed-off-by: bavery Signed-off-by: Richard Purdie

bitbake: toaster: attach kernel artifacts to targets

2016-07-19T07:56:51+00:00

The bzImage and modules files were previously attached to a build, rather than to the target which produced them. This meant it was not possible to determine which kernel artifact produced by a build came from which target; which in turn made it difficult to associate existing kernel artifact with targets when those targets didn't produce artifacts (e.g. if the same machine + target combination was built again and didn't produce a bzImage or modules file because those files already existed). By associating kernel artifacts with the target (via a new TargetArtifactFile model), we make it possible to find all the artifacts for a given machine + target combination. Then, in cases where a build is completed but its targets don't produce any artifacts, we can find a previous Target object with the same machine + target and copy its artifacts to the targets for a just-completed build. Note that this doesn't cover SDK artifacts yet, which are still retrieved in toaster.bbclass and show up as "Other artifacts", lumped together for the whole build rather than by target. [YOCTO #8556] (Bitbake rev: 9b151416e428c2565a27d89116439f9a8d578e3d) Signed-off-by: Elliot Smith Signed-off-by: bavery Signed-off-by: Richard Purdie

bitbake: toaster: do image and artifact scan on BuildCompleted

2016-07-19T07:56:51+00:00

Move the image and artifact scan code from toaster.bbclass and consolidate its logic with the existing logic in buildinfohelper. Remove handler setup for events which used to be fired from toaster.bbclass but which are now handled directly by buildinfohelper. [YOCTO #8556] (Bitbake rev: f0085cd554604cfff4a3f40a34825fbb6878004f) Signed-off-by: Elliot Smith Signed-off-by: bavery Signed-off-by: Richard Purdie

bitbake: knotty: avoid errors when fetching outside of a task

2016-07-19T07:56:50+00:00

In a few places we use the fetcher code to fetch files outside of a task, for example uninative in OE. In that case the pid of the event is 0 and that was causing an error in BBUIHelper.eventHandler(). Check the pid and do nothing if it's 0. (Bitbake rev: 59cb919e5cd5c653fb4d69b2d6a4320648443e10) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

bitbake: buildinfohelper: ensure task datetimes are timezone-aware

2016-07-08T08:57:28+00:00

When using toaster-eventreplay to run a bitbake event file through toasterui/buildinfohelper, errors occur when the tasks are updated with buildstats info: RuntimeWarning: DateTimeField Task.started received a naive datetime (2016-07-06 09:15:22.070000) while time zone support is active. This is because a method in buildinfohelper returns a naive datetime, but Django is expecting timezone-aware datetimes. Ensure that datetimes used to set the started/ended times on tasks are converted to timezone-aware datetimes. (Bitbake rev: df9f4337bec87024ea6a43138c6080a755eb7fab) Signed-off-by: Elliot Smith Signed-off-by: Richard Purdie

bitbake: knotty: Handle process indicators more gracefully

2016-07-08T08:57:27+00:00

Mistakes can happen with the generation of the progress events, change knotty to be more tolerant of this rather than crashing, reporting to the user when something unexpected happens. I haven't debugged why multiple finish events appear to be triggered. (Bitbake rev: 7dd06b1016b36420a9c55a45ff29dd64ae1dbcda) Signed-off-by: Richard Purdie

bitbake: knotty: add quiet output mode

2016-07-08T08:57:27+00:00

Quiet output mode disables printing most messages (below warnings) to the console; however these messages still go to the console log file. This is primarily for cases where bitbake is being launched interactively from some other process, but where full console output is not needed. Because of the need to keep logging all normal events to the console log, this functionality was implemented within the knotty UI rather than in bb.msg (where verbose mode is implemented). We don't currently have a means of registering command line options from the UI end, thus the option actually has to be registered in main.py regardless of the UI, however I didn't feel like it was worth setting up such a mechanism just for this option. (Bitbake rev: db95cdef08e339dec7462bfde3ad7d75c1c60dd8) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie