linux/poky.git/bitbake/lib/toaster/toastergui/views.py, 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: toaster: better display of targets which produced no images

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

SDK targets (populate_sdk) produce SDK artifacts but no image files. Currently, these targets appear under the "Images" heading in the build dashboard, even though they aren't strictly image targets. Change the heading to "Build artifacts". Also remove the section which states that a build produced no image files: this is not correct for populate_sdk targets (those targets don't produce image files under any circumstances); and other changes mean that all targets which do produce images will now show those files. The check for whether to display the "Build artifacts" section also needs to change, as we show targets here which didn't produce any images but did produce SDK artifacts. [YOCTO #8556] (Bitbake rev: b4dce68045c4615e7a6a474e952f670721a3b54e) Signed-off-by: Elliot Smith Signed-off-by: bavery Signed-off-by: Richard Purdie

bitbake: toaster: use has_images() methods to display images correctly

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

In the build dashboard, we had issues with showing images correctly, as we were using the is_image property of targets to determine whether a target would have image files. This property can be set to True if a target refers to an image recipe (e.g. "core-image-minimal"), even if the task used in the build didn't produce any image files. By adding has_images() methods to the Target and Build objects, which count associated Target_Image_File objects, we can correctly determine whether a target has image files associated with it, and if any of the targets for a build has image files. This means that we can screen out the left-hand "Images" menu options for builds which contained image-related targets (e.g. "core-image-minimal") but which didn't produce any images (e.g. "rootfs" task). [YOCTO #9500] [YOCTO #9784] (Bitbake rev: f6bba0ff254d5ed3163151d4b938f3a43c9acb0a) 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: 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: layerdetails api Fix saving of git revision of a layer

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

Update, clean up and move the api for updating a layerversion from the views to api. Also update the layerdetails page to include the layerversion id in the url getter. [YOCTO #8952] (Bitbake rev: 20f4e23bc86290f0a42881a7cac44c41eafa86fc) Signed-off-by: Michael Wood Signed-off-by: Elliot Smith Signed-off-by: Richard Purdie

bitbake: toaster: views Fix most frequently built target in project reporting

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

Clean up and fix the most frequently built targets for the "Most built recipes" section for the project configuration page. [YOCTO #9846] (Bitbake rev: 860475cfdd35301fb609ab3c89347566b0ca0adc) Signed-off-by: Michael Wood Signed-off-by: Elliot Smith Signed-off-by: Richard Purdie

bitbake: toaster: remove SSTATE_MIRRORS from blacklists in views

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

Remove SSTATE_MIRRORS variable from blacklists in views.py This helps user to point mirrors using SSTATE_MIRRORS with toaster. [#YOCTO 9598] (Bitbake rev: c3dd4fb193c80ed9a6dbddf7f6a1eadd0964ac8c) Signed-off-by: Sujith H Signed-off-by: Michael Wood Signed-off-by: Richard Purdie

bitbake: toaster: fix typo which causes table searches to fail

2016-06-16T16:37:58+00:00

The iterator used to create a search query refers to a variable "x" which isn't set, causing an "'x' is not defined" error and preventing table searches (on non-ToasterTables) from working. Use the "field" variable instead, which contains the name of the field to add to the query. [YOCTO #9749] (Bitbake rev: a3ebeb37f7bd4cffe6707c634b4f0a0ea52ccc45) Signed-off-by: Elliot Smith Signed-off-by: Michael Wood Signed-off-by: Richard Purdie

bitbake: toaster: fix wrong usage of print_exc and format_exc

2016-06-15T07:35:06+00:00

First parameter of traceback.print_exc and traceback.format_exc APIs is a 'limit' - a number of stracktraces to print. Passing exception object to print_exc or format_exc is incorrect, but it works in Python 2 and causes printing only one line of traceback. In Python 3 comparison of integer and exception object throws exception: TypeError: unorderable types: int() < () As these APIs are usually used in except block of handling another exception this can cause hard to find and debug bugs. (Bitbake rev: c5a48931ac8db9e56f978c50861c19d0d0c808e3) Signed-off-by: Ed Bartosh Signed-off-by: Michael Wood Signed-off-by: Richard Purdie