summaryrefslogtreecommitdiffstats
path: root/bitbake/lib/bb/ui
Commit message (Collapse)AuthorAgeFilesLines
* bitbake: build/uihelper: Show better information about multiconfig tasks on UIRichard Purdie2017-01-111-1/+4
| | | | | | | | | | Currently the UI shows X is building, possibly multiple times but doesn't say which of the multilibs that might be. This adds a prefix to the task name so the mulitconfig being built can be identified. (Bitbake rev: dfb775c67a96a79f3b85104870c0ade46ef2a9ea) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: buildinfohelper Handle regex pathsbrian avery2016-11-031-1/+26
| | | | | | | | | | | | | | We were presuming that all the layer dependency information was of the form "^/path/to/layer" to we were just stripping the leading "^" off of the layer information when we were matching the layer priorities to the toaster database. This patch splits out the priorities layer match which gets a regex from the task/recipe match which is gets a path. (Bitbake rev: 82775c80d169266cc18ca2b2065a05c79dc6fbfc) Signed-off-by: brian avery <brian.avery@intel.com> Signed-off-by: Michael Wood <michael.g.wood@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: depexp: Close UI with error message on NoProvider eventJussi Kukkonen2016-10-111-0/+24
| | | | | | | | | | | | | | Without this the UI just sits there doing nothing. Showing an infobar in-UI would be nicer but not much more useful since currently user couldn't do anything in-UI to fix the situation. Implementation is based on the one in knotty. Fixes [YOCTO #9288] (Bitbake rev: eee9231a543f1d0b9ef3cd8377fc46fd23afb97b) Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: ui/knotty.py: Fix signal handling of SIGWINCH in BBProgressAníbal Limón2016-10-091-7/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add the ability to pass default signal handler for SIGWINCH in BBProgress because with multiple instace of BBProgress the original signal handler set by TerminalFilter (sigwinch_handle) is lost. This is a fix for stack trace due to multiple async calls of ProgressBar _handle_resize (ioctl to terminal fd), see: NOTE: Executing SetScene Tasks Fatal Python error: Cannot recover from stack overflow. Current thread 0x00007f70a4793700 (most recent call first): File "/home/alimonb/repos/poky/bitbake/lib/progressbar/progressbar.py", line 183 in _handle_resize File "/home/alimonb/repos/poky/bitbake/lib/bb/ui/knotty.py", line 58 in _handle_resize File "/home/alimonb/repos/poky/bitbake/lib/bb/ui/knotty.py", line 60 in _handle_resize ... File "/home/alimonb/repos/poky/bitbake/lib/bb/ui/knotty.py", line 60 in _handle_resize ... Aborted (Bitbake rev: 812bd49cb569379ee90d5be28a4b6e60645f1e54) Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: buildinfohelper: Use correct way to get message from ↵Michael Wood2016-10-061-6/+3
| | | | | | | | | | | | | | | LogMessage Use the correct method to get a message value from the LogMessage object rather than constructing it ourselves which is not recommended. This causes an exception when the msg contains a '%' such as when there are wildcards in file names (something2.%.bbappends) (Bitbake rev: 11b3b6a7087554d14a2812a9ae463dce740b879e) Signed-off-by: Michael Wood <michael.g.wood@intel.com> Signed-off-by: bavery <brian.avery@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: make error message more informativeEd Bartosh2016-09-301-1/+1
| | | | | | | | | | | | | | | | | Error message ERROR: Unprocessed MetadataEvent <bb.event.MetadataEvent object at 0x7f750e671a58> doesn't give a lot of information about the event. It just prints event object, which is always bb.event.MetadataEvent. Including event type into the error message should make it more informative: ERROR: Unprocessed MetadataEvent TaskArtifacts (Bitbake rev: 603c7c13536d3fa1786270e863688c1d2e511196) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Michael Wood <michael.g.wood@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: fix 'Unhandled MetadataEvent' errorEd Bartosh2016-09-301-0/+4
| | | | | | | | | | | | New MetadataEvent 'TaskArtifacts' causes this error. Processing of this event will hopefully be implemented in future. For now it should be enough to just skip it. (Bitbake rev: 114a3fe3f23ef09782c5aa18f425d0d0dbdfdd35) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Michael Wood <michael.g.wood@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: fix handling of EnvironmentErrorEd Bartosh2016-09-301-3/+6
| | | | | | | | | | | | | Due to the bug in processing EnvironmentError exception, toasterui ignores it. As EnvironmentError is a base for OSError and IOError this means that all OSError and IOError exceptions were silently ignored. (Bitbake rev: c8f4ca008bf9396b0ed45d44bfe2220c82a614a9) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Michael Wood <michael.g.wood@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: check if file existEd Bartosh2016-09-301-0/+3
| | | | | | | | | | | | | | | | | | Buildinfohelper assumes that all files mentioned in manifest exist in deploy/ directory, which is not always the case. Toaster crashes with OSError trying to call os.stat on non-existing file. Checking if file exists before processing it should fix this. [YOCTO #10185] (Bitbake rev: 54565e7ca84d2722a2454e7fa52cda564b28b527) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Michael Wood <michael.g.wood@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty: ensure progress bar output is accounted for in displayPaul Eggleton2016-09-231-5/+4
| | | | | | | | | | | | | | | | | | | | When calculating how many lines we'd printed we weren't properly taking the progress bars into account, with the result that sometimes if the last line printed on the terminal wrapped to the next line (which is possible) we backed up less lines than we should have. Additionally, we should always print a newline after updating the progress bar - there's no need to check if there wasn't output (there always will be courtesy of our overridden _need_update()) and we now allow the line to wrap so we don't need to check the other condition either. Hopefully this will fix [YOCTO #10046]. (Bitbake rev: 326d18d96faf02675ba34ad3c3a20cd424b39b91) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty: Show task elapsed timeRichard Purdie2016-09-231-1/+10
| | | | | | | | | | | | | Its often useful to know how long a task has been running for. This patch adds that information to the task display, updating every 5s if there were no other updates so the user can see how long tasks have been running for. [YOCTO #9737] (Bitbake rev: 6c42025e5dd7761213be3f82f3252a7892d2239d) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: buildinfohelper local layer don't construct path using git ↵Michael Wood2016-09-211-3/+5
| | | | | | | | | | | | | | | info When the layer is local source don't try and work out the location of the layer by using the git information (getGitCloneDirectory) [YOCTO #10199] (Bitbake rev: 3dfea5214d4bd006e26630e5024774ecb84ea527) Signed-off-by: Michael Wood <michael.g.wood@intel.com> Signed-off-by: bavery <brian.avery@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: unlock BuildEnvirnoment when build is doneEd Bartosh2016-09-211-3/+5
| | | | | | | | | | | | | | | | There is no need to lock build environment before changing build status as this operation is very fast. However, there is a need to unlock it after changing build status. Explicitly unlocked BuildEnvironment after build reaches final status SUCCEEDED, FAILED or CANCELLED. This should allow runbuilds process to pickup next build faster. (Bitbake rev: faa88272d656640c039572c5c8f3e6c56535b6f7) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Michael Wood <michael.g.wood@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: notify runbuilds when build status changesEd Bartosh2016-09-211-0/+4
| | | | | | | | | | | | | Called signal_runbuilds API when build is scheduled, cancelled or finished to notify runbuilds process about builds status change. [YOCTO #8918] (Bitbake rev: fe08f0fa4b328908e73695ebbceca87bc86a49f9) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Michael Wood <michael.g.wood@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: uihelper: use elif instead of repeated ifRoss Burton2016-09-211-6/+5
| | | | | | (Bitbake rev: a1d6f6425cd9ef9e07344869817517172afd6e27) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: keep layer name in variable history pathDavid Reyna2016-09-081-1/+2
| | | | | | | | | | | | | | When converting variable history file names to relative paths, keep the layer directory's name so that the user can distinguish between conf files with the same name. [YOCTO #8188] (Bitbake rev: 59561d652af91c2099b735084f0e44275d68e637) Signed-off-by: David Reyna <david.reyna@windriver.com> Signed-off-by: Michael Wood <michael.g.wood@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: buildinfohelper: discover kernel artifacts correctlyElliot Smith2016-09-021-4/+7
| | | | | | | | | | | | | | | | | | | | Because some image_license.manifest files contain multiple FILES lines, and because those lines can sometimes not contain a list of files (i.e. they look like "FILES:\n"), we were resetting the list of kernel artifacts when we hit the second "empty" line. Fix by ignoring any FILES line which doesn't list files, and by appending any files found in a valid FILES line, rather than overwriting the existing list. [YOCTO #10107] (Bitbake rev: 927ec3524625ac731326b3c1c1361c2a4d2bd9e1) Signed-off-by: Elliot Smith <elliot.smith@intel.com> Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toasterui, knotty: don't print taskid followed by taskstring which ↵Martin Jansa2016-08-202-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | are now in most cases identical * unify the format how the task is described * don't show taskid followed by taskstring as the taskstring is different only for setscene tasks (by _setscene suffix) * the duplicated output was introduced by: 2c88afb taskdata/runqueue: Rewrite without use of ID indirection as reported and confirmed as a bug here: http://lists.openembedded.org/pipermail/openembedded-core/2016-June/123148.html * show: NOTE: Running task 541 of 548 (/OE/build/oe-core/openembedded-core/meta/recipes-core/zlib/zlib_1.2.8.bb:do_package) instead of much longer: NOTE: Running task 541 of 548 (ID: /OE/build/oe-core/openembedded-core/meta/recipes-core/zlib/zlib_1.2.8.bb:do_package, /OE/build/oe-core/openembedded-core/meta/recipes-core/zlib/zlib_1.2.8.bb:do_package) and similarly for failed tasks: ERROR: Task (virtual:native:/OE/build/oe-core/openembedded-core/meta/recipes-core/zlib/zlib_1.2.8.bb:do_install) failed with exit code '1' instead of much longer: ERROR: Task virtual:native:/OE/build/oe-core/openembedded-core/meta/recipes-core/zlib/zlib_1.2.8.bb:do_install (virtual:native:/OE/build/oe-core/openembedded-core/meta/recipes-core/zlib/zlib_1.2.8.bb:do_install) failed with exit code '1' (Bitbake rev: 696693d45f5eff1226866ed79dbfb67161d8cd3f) Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty: don't show number of running tasks in quiet modePaul Eggleton2016-08-171-1/+3
| | | | | | | | | | | There's not a whole lot of point showing how many tasks are running when we're in quiet mode, it just looks a bit strange particularly when it's not running any tasks. (Bitbake rev: 5317200d9cd73c6f971bc1b0cfe8692749e27e3a) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty: fix task progress bar not starting at 0%Paul Eggleton2016-08-171-2/+5
| | | | | | | | | | If we have the task number here we need to subtract 1 to get the number of tasks completed. (Bitbake rev: 7c78a1cd3f0638ae76f7c7a469b7f667c7c58090) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: buildinfohelper Add handling local layers (i.e. non-git) ↵Michael Wood2016-08-111-4/+23
| | | | | | | | | | | | layers Adds handling of the non-git layers to create and update the corresponding layer objects in Toaster. (Bitbake rev: 0a9b5d7d9655dbb09d458fc6e330e932f0f9dab6) Signed-off-by: Michael Wood <michael.g.wood@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toasterui: ensure that the Build object is always availableElliot Smith2016-08-112-83/+122
| | | | | | | | | | | | | | | | | | | | | | | | | | Many of the methods in toasterui and buildinfohelper rely on the internal state of the buildinfohelper; in particular, they need a Build object to have been created on the buildinfohelper. If the creation of this Build object is tied to an event which may or may not occur, there's no guarantee that it will exist. This then causes assertion errors in those methods. To prevent this from happening, add an _ensure_build() method to buildinfohelper. This ensures that a minimal Build object is always available whenever it is needed, either by retrieving it from the BuildRequest or creating it; it also ensures that the Build object is up to date with whatever data is available on the bitbake server (DISTRO, MACHINE etc.). This method is then called by any other method which relies on a Build object being in the internal state, ensuring that the object is either available, or creating it. (Bitbake rev: 0990b4c73f194ec0be1762e4e48b1a525d8349fb) Signed-off-by: Elliot Smith <elliot.smith@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: show progress of recipe parsing in recent builds areaElliot Smith2016-08-112-53/+96
| | | | | | | | | | | | | | | | | | | | | | | | | | | Modify buildinfohelper and toasterui so that they record the recipe parse progress (from ParseProgress events in bitbake) on the Build object. Note that because the Build object is now created at the point when ParseStarted occurs, it is necessary to set the build name to the empty string initially (hence the migration). The build name can be set when the build properly starts, i.e. at the BuildStarted event. Then use this additional data to determine whether a Build is in a "Parsing" state, and report this in the JSON API. This enables the most recent builds area to show the recipe parse progress. Add additional logic to update the progress bar if the progress for a build object changes. [YOCTO #9631] (Bitbake rev: f33d51d46d70e73e04e325807c1bc4eb68462f7b) Signed-off-by: Elliot Smith <elliot.smith@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: orm Remove the layerindex specific up_branch fieldsMichael Wood2016-07-261-3/+3
| | | | | | | | | | | | | | | | | | We don't need to keep track of layerindex data in our database. And using branch==release is very confusing in the schema. Instead use the existing Release definition to keep track of which release a layer_version is for. Remove the Branch model and all references to it. Create a migration path to convert from up_branches to their corresponding releases. (Bitbake rev: f8f4cffe6fd371f3a7e63690c68f3fcb5dc1f297) Signed-off-by: Michael Wood <michael.g.wood@intel.com> Signed-off-by: Elliot Smith <elliot.smith@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty: don't display ETA for tasks with progressPaul Eggleton2016-07-261-1/+1
| | | | | | | | | | | | | | | It turns out that progress information we can extract from a task is rarely apportioned closely enough to the time taken for the ETA to be accurate, so showing it is going to be misleading most of the time for anything but the most basic of examples. Let's just remove it and avoid misleading (or worse, annoying) the user. Fixes [YOCTO #9986]. (Bitbake rev: 235db4870b11db97250979e647b54cdb5ce4fbb6) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty: fix some minor bugs in BBProgressPaul Eggleton2016-07-261-12/+13
| | | | | | | | | | | | If you specify custom widgets then we don't want to assume where the "extra" position is - you should have to specify it, and if it isn't specified it shouldn't just wipe out the last widget or you can start to see odd behaviour if you're modifying the code. (Bitbake rev: 19e33c10feb1637589ceb05b5e8d58b1e012ccb8) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: add package manifest path to Target objectsElliot Smith2016-07-191-3/+21
| | | | | | | | | | | | | | | | | | | 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 <elliot.smith@intel.com> Signed-off-by: bavery <brian.avery@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: buildinfohelper: only record image files for tasks which make imagesElliot Smith2016-07-191-5/+15
| | | | | | | | | | | | | | | | | | | | | | | | 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 <elliot.smith@intel.com> Signed-off-by: bavery <brian.avery@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: improve scan for SDK artifactsElliot Smith2016-07-192-44/+138
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <elliot.smith@intel.com> Signed-off-by: bavery <brian.avery@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: buildinfohelper: fix retrieval of targetsElliot Smith2016-07-191-7/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <elliot.smith@intel.com> Signed-off-by: bavery <brian.avery@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: attach kernel artifacts to targetsElliot Smith2016-07-191-29/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <elliot.smith@intel.com> Signed-off-by: bavery <brian.avery@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: do image and artifact scan on BuildCompletedElliot Smith2016-07-192-26/+181
| | | | | | | | | | | | | | | | 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 <elliot.smith@intel.com> Signed-off-by: bavery <brian.avery@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty: avoid errors when fetching outside of a taskPaul Eggleton2016-07-191-3/+4
| | | | | | | | | | | | 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 <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: buildinfohelper: ensure task datetimes are timezone-awareElliot Smith2016-07-081-1/+1
| | | | | | | | | | | | | | | | | | | | | 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 <elliot.smith@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty: Handle process indicators more gracefullyRichard Purdie2016-07-081-4/+12
| | | | | | | | | | | 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 <richard.purdie@linuxfoundation.org>
* bitbake: knotty: add quiet output modePaul Eggleton2016-07-081-25/+32
| | | | | | | | | | | | | | | | | | | | | 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 <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty: show task progress barPaul Eggleton2016-07-081-4/+19
| | | | | | | | | | | | | | In addition to the "currently running n tasks (x of y)" message, show a progress bar for another view on how much of the build is left. We have to take care to reset it when moving from the scenequeue to the runqueue, and explicitly don't include an ETA since not all tasks take equal time and thus it isn't possible to estimate the time remaining with the information available. (Bitbake rev: de682015a3fefeff36ddc4197641a700f3fb558d) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty: add code to support showing progress for sstate object queryingPaul Eggleton2016-07-081-2/+13
| | | | | | | | | | | | | Add support code on the BitBake side to allow sstate.bbclass in OpenEmbedded to report progress when it is checking for availability of artifacts from shared state mirrors. Part of the implementation for [YOCTO #5853]. (Bitbake rev: 070ae856da0715dbaf4c560c837ea796ffc29f00) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: lib: implement basic task progress supportPaul Eggleton2016-07-082-10/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | For long-running tasks where we have some output from the task that gives us some idea of the progress of the task (such as a percentage complete), provide the means to scrape the output for that progress information and show it to the user in the default knotty terminal output in the form of a progress bar. This is implemented using a new TaskProgress event as well as some code we can insert to do output scanning/filtering. Any task can fire TaskProgress events; however, if you have a shell task whose output you wish to scan for progress information, you just need to set the "progress" varflag on the task. This can be set to: * "percent" to just look for a number followed by a % sign * "percent:<regex>" to specify your own regex matching a percentage value (must have a single group which matches the percentage number) * "outof:<regex>" to look for the specified regex matching x out of y items completed (must have two groups - first group needs to be x, second y). We can potentially extend this in future but this should be a good start. Part of the implementation for [YOCTO #5383]. (Bitbake rev: 0d275fc5b6531957a6189069b04074065bb718a0) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty: import latest python-progressbarPaul Eggleton2016-07-081-1/+1
| | | | | | | | | | | | | Since we're going to make some minor extensions to it, it makes sense to bring in the latest version of python-progressbar. Its structure has changed a little but the API hasn't; however we do need to ensure our overridden _needs_update() function's signature in BBProgress() matches properly. (Bitbake rev: c3e51d71b36cbc9e9ed1b35fb93d0978e24bc98a) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty: provide a symlink to the latest console logPaul Eggleton2016-07-081-0/+6
| | | | | | | | | | | If you're looking to find the latest console log repeatedly it can be a bit tedious - let's just create a symlink just as we do with other logs to make it easy to find. (Bitbake rev: e9f41c0507a6527bf2ed86506813d4d4a89f8ebf) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: depexp.py: port to gtk+3Jussi Kukkonen2016-06-201-79/+80
| | | | | | | | | | | | | The code is still a bit icky (and should be refactored to not use Gdk.threads_enter/leave) but it should work about as reliably as it did with Gtk+2. Based on earlier patches by Maxin and Joshua. (Bitbake rev: 8eee64a64144e27b5b8c2aca88e138882c3deab7) Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: fix wrong usage of format_excEd Bartosh2016-06-161-1/+1
| | | | | | | | | | | | | | | | | | | | First parameter of traceback.format_exc is a 'limit' - a number of stracktraces to format. Passing exception object to format_exc is incorrect, but it works in Python 2 as this code from traceback module works: while tb is not None and (limit is None or n < limit): Comparing integer counter n with the exception object in Python 2 always results in True. However, in Python 3 it throws exception: TypeError: unorderable types: int() < <Exception type>() As format_exc is used in except block of handling another exception this can cause hard to find and debug bugs. (Bitbake rev: a9509949d7e2adba6e3cd89f97daa19a955855b5) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: replace viewkeys() -> keys()Ed Bartosh2016-06-151-1/+1
| | | | | | | | | | | | Python 3 doesn't have dict.viewkeys method, renaming to keys(). [YOCTO #9584] (Bitbake rev: 8ae2fc26fc7c4f42817dece62b9a59fbda27c0b0) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: Revert "buildinfohelper: work around unicode exceptions"Ed Bartosh2016-06-021-6/+4
| | | | | | | | | | | This commit causes buildinfohelper to crash when run on python 3 as python 3 doesn't have unicode builtin function. This reverts commit 7a309d964a86f3474eaab7df6d438ed797f935c0. (Bitbake rev: 750ca5c8d5a25fc519b75c56352dec7823c7e240) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: goggle/image-writer: Drop since bitrotting and no longer usedRichard Purdie2016-06-0218-3907/+0
| | | | | | | | | | | The upgrade to python3 is the final nail in the coffin for image-writer and the goggle UI. Neither seem used or recieve patches and are based on old versions of GTK+ so drop them, and the remaining crumbs support pieces. (Bitbake rev: ee7df1ca00c76f755057c157c093294efb9078d8) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: image-writer/goggle: Disable pygtkcompat problemsRichard Purdie2016-06-023-12/+13
| | | | | | | | | | | Disable the problematic gtk usage for use with pygtkcompat. The following commit removes these tools/UIs entirely but we may as well leave this piece in the history in case anyone does want a starting point for reusing them. (Bitbake rev: c53c7418d392452450352ca2175667dbdbd92401) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Convert to python 3Richard Purdie2016-06-027-22/+27
| | | | | | | | | Various misc changes to convert bitbake to python3 which don't warrant separation into separate commits. (Bitbake rev: d0f904d407f57998419bd9c305ce53e5eaa36b24) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: Remove DATABASE_URL being passed around as an environment varMichael Wood2016-05-201-10/+10
| | | | | | | | | | | | | | | | | | We don't need to pass the DATABASE_URL around and read it back if we setup the django framework in the correct way. We make the default sqlite database path a full path so that the database isn't being assumed to be in CWD. Also add some more useful comments on the database settings. This is preparation work to migrate the build tests and be able to trigger builds on differently configured databases. (Bitbake rev: 973c740404ca6a09feea250d3433075995067fe0) Signed-off-by: Michael Wood <michael.g.wood@intel.com> Signed-off-by: Elliot Smith <elliot.smith@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty: Fix output buffering issuesRichard Purdie2016-05-171-0/+2
| | | | | | | | | | | | | We need to flush the footer removal, else it may not be outputted until the buffer is flushed as part of StreamHandler and this would lead to it removing the ERROR output just printed which is extremely confusing. Also ensure the footer is cleared before printing a summary as in some cases it wasn't being removed, also leading to user confusion. (Bitbake rev: 0e030c4d074c41859608dab5f3ad26b05f56b306) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-05-23 17:57:01 +0000