summaryrefslogtreecommitdiffstats
path: root/bitbake/lib/bb/ui/knotty.py
Commit message (Collapse)AuthorAgeFilesLines
...
* bitbake: knotty: prevent extra logger from being enabled for tinfoilPaul Eggleton2017-06-121-2/+3
| | | | | | | | | | | | | | | tinfoil sets up its own logger by default, but if and when we initialise the UI (by default knotty) will also set one up, leading to duplicated messages specifically from tasks. To avoid this, rather than adding some kind of parameter, just check if there is already a logger outputting to stdout/stderr and if so, skip adding our own. Part of the fix for [YOCTO #11275]. (Bitbake rev: 66d866745f35468d1540a793d07e3a401298b84b) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty: Remove extra whitespace after task progress barsPeter Kjellerstedt2017-03-131-3/+1
| | | | | | | | | | | | | For some reason, BBProgress.setextra() always adds a space at the end. This prevents the task progress bars from filling the entire width of the terminal, making them stop one character short. This looks odd when shown together with the main progress bar, which does fill the entire terminal width. (Bitbake rev: 6540e98090d6a88607489a23c063be338bcc3b57) Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty: fix --observe-only optionPaul Eggleton2016-12-141-3/+7
| | | | | | | | | | | If we're in observe-only mode then we cannot run commands that would affect the server's state, including getSetVariable, so prevent that from being called in observe-only mode. (Bitbake rev: 2c5a8661430edebff67ab4a108995033d182b5d6) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty: make quiet option a level optionPaul Eggleton2016-12-141-7/+28
| | | | | | | | | | | | | | | | | Allow you to specify -q / --quiet more than once to reduce the messages even further. It will now operate as follows: Level Option Result ----- ------ ---------------------------------------- 0 Print usual output 1 -q Only show progress and warnings or above 2 -qq Only show warnings or above 3+ -qqq Only show errors (Bitbake rev: 6cf2582e17c28ca04f5cfb59858c4a9778c700d4) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker process: fire heartbeat event at regular time intervalsPatrick Ohly2016-12-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | The intended usage is for recording current system statistics from /proc in buildstats.bbclass during a build and for improving the BB_DISKMON_DIRS implementation. All other existing hooks are less suitable because they trigger at unpredictable rates: too often can be handled by doing rate-limiting in the event handler, but not often enough (for example, when there is only one long-running task) cannot because the handler does not get called at all. The implementation of the new heartbeat event hooks into the cooker process event queue. The process already wakes up every 0.1s, which is often enough for the intentionally coarse 1s delay between heartbeats. That value was chosen to keep the overhead low while still being frequent enough for the intended usage. If necessary, BB_HEARTBEAT_EVENT can be set to a float specifying the delay in seconds between these heartbeat events. (Bitbake rev: 7cf22ea057d28c54bd98dc1ab7a43402a29ff1f5) Signed-off-by: Patrick Ohly <patrick.ohly@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: 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: toasterui, knotty: don't print taskid followed by taskstring which ↵Martin Jansa2016-08-201-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | 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: 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: 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-081-9/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: bitbake: Convert to python 3Richard Purdie2016-06-021-3/+3
| | | | | | | | | 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: 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>
* bitbake: knotty: Ensure consolelog file handle is closedRichard Purdie2016-05-131-0/+5
| | | | | | | | | If we don't close the console log file handle, python prints a warning about unclosed file handles upon exit which is annoying. (Bitbake rev: 624dd92952b2fc736fd86abe5f2390b87b3a7dd3) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Update logger.warn() -> logger.warning()Richard Purdie2016-05-111-4/+4
| | | | | | | | | | python deprecated logger.warn() in favour of logger.warning(). This is only used in bitbake code so we may as well just translate everything to avoid warnings under python 3. Its safe for python 2.7. (Bitbake rev: 676a5f592e8507e81b8f748d58acfea7572f8796) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: providers: Add PREFERRED_RPROVIDER supportRichard Purdie2016-04-151-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Sometimes you can end up in a situation where you need to specify that a specific runtime entity should be provided by a specific entry. An example of this is bluez where you could end up in a situation where for example: NOTE: multiple providers are available for runtime libasound-module-bluez (bluez4, bluez5) NOTE: consider defining a PREFERRED_PROVIDER entry to match libasound-module-bluez NOTE: multiple providers are available for runtime bluez-hcidump (bluez-hcidump, bluez5) NOTE: consider defining a PREFERRED_PROVIDER entry to match bluez-hcidump The only option here is to set something like PREFERRED_PROVIDER_bluez4 = "bluez4" which is clearly not very informative. I've actually held off adding RPROVIDER support for a long while as this does have sigificant potential for misuse. It doesn't for example allow multiple runtime providers of the same name to coexist, that simply isn't supported. It therefore doesn't replace some of the name mappings such as busybox verses coreutils that OE-Core faces as that is a different problem with different constraints. This mechanism is simply to provide bitbake with a hint to decide what the dependency tree should look like. Also, this allows us to stop printing a confusing message telling the user to set PREFERRED_PROVIDER when the setting needed would be rather ambiguous. [YOCTO #5044] (Bitbake rev: 62eb39d1474d024b204634689071700605c6095c) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker/knotty: Prefix parse logs with filename being parsedRichard Purdie2016-04-151-1/+2
| | | | | | | | | | | | | We now prefix log messages coming from worker task context with the PF and task info, however parsing messages all have to be manually prefixed which is ugly and error prone. This change modifies the log handler filter so this happens automatically, meaning we don't have to change every message to include that information. This makes error messages longer but more usable. (Bitbake rev: 1af0ccaac81e182c4ca520037dda362d180e5605) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bb.ui.knotty: prefix task messages with recipe/taskChristopher Larson2016-02-161-5/+13
| | | | | | | | | An example prefix: `perl-5.22.1-r0 do_compile:` (Bitbake rev: 792b759e59e31d2e43d525a6e50d866b4f51f072) Signed-off-by: Christopher Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty: Set exit failure code on runQueueTaskFailed eventsRichard Purdie2016-02-151-0/+1
| | | | | | | | | | | If the worker segfaults, we may never see a TaskFailed event from it, only a runQueueTaskFailed event. In this case, return_value isn't getting set leading to an incorrect exit code from bitbake. Fix by setting return_value in both places. (Bitbake rev: e5dd50e0d95d532fe31dde61f8c6b1a7a72321e9) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty: Don't show errors for universe provider issuesRichard Purdie2016-02-011-5/+13
| | | | | | | | | | | | When running universe builds, we don't expect an error exit code for provider warnings. Change the error messages to warnings in this case. This deals with errors causing problems on our autobuilders amongst other issues. (Bitbake rev: d4989fb0355476de172169f0698757f7360e9a1f) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Set process names to be meaninfulRichard Purdie2016-01-301-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | This means that when you view the process tree, the processes have meaningful names, aiding debugging: $ pstree -p 30021 bash(30021)───KnottyUI(115579)───Cooker(115590)─┬─PRServ(115592)───{PRServ Handler}(115593) ├─Worker(115630)───bash:sleep(115631)───run.do_sleep.11(115633)───sleep(115634) └─{ProcessEQueue}(115591) $ pstree -p 30021 bash(30021)───KnottyUI(117319)───Cooker(117330)─┬─Cooker(117335) ├─PRServ(117332)───{PRServ Handler}(117333) ├─Parser-1:2(117336) └─{ProcessEQueue}(117331) Applies to parse threads, PR Server, cooker, the workers and execution threads, working within the 16 character limit as best we can. Needed to tweak the bitbake-worker magic values to tell the workers apart. (Bitbake rev: 539726a3b2202249a3f148d99e08909cb61902a5) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty: Use non-interactive mode as fallback for dumb terminalsRichard Purdie2016-01-081-0/+4
| | | | | | | | | | | | | | | TERM=dumb bitbake X shows no output for task status which is suboptimal. Use the non-interactive mode if the terminal doesn't support what we need for interactive mode giving a better user experience. Also print a note to the console to say this has happened. [YOCTO #8768] (Bitbake rev: 6f84cf4bd77f35fcd07e0b2f5149f1d6866a414d) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty: Improve exception error messageRichard Purdie2015-12-181-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | Instead of: """ can only concatenate tuple (not "int") to tuple """ we now see: """ Traceback (most recent call last): File "/media/build1/poky/bitbake/lib/bb/ui/knotty.py", line 324, in main termfilter.updateFooter() File "/media/build1/poky/bitbake/lib/bb/ui/knotty.py", line 210, in updateFooter lines = 1 + int(len(content) / (self.columns + 1)) TypeError: can only concatenate tuple (not "int") to tuple """ which makes tacking down and fixing the problem much easier. Also ensure we set an error exit code. (Bitbake rev: d965bcae6cfd268406a3bd1ef77c5bb6c6e1c6d7) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty: Fix row/column function return value issueRichard Purdie2015-12-181-1/+1
| | | | | | | | | | | | | When the row handling was introduced, one of the callbacks was missed resulting in: TypeError: can only concatenate tuple (not "int") to tuple Fix it. (Bitbake rev: 0b77cea2bf5b5f5704e2650fb0332f5d78037781) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty: Enforce terminal line limit to stop crazy scrollingRichard Purdie2015-12-081-3/+4
| | | | | | | | | | | | | | | | If there are more tasks running than there are lines on the terminal, the data scrolls in ways the UI wasn't designed for. This patch adjusts the UI just to show the processes which fit onto the number of rows in the terminal window. You can see the total number running from the counter in the top left as usual and this makes warning and errors messages scrolling from the top of the window work as designed. Ultimately, scrolling would be nice but is for another time, this fixes the biggest UI issue on highly parallel machines. (Bitbake rev: 67b77658e2bfa849f6f55c9c262cb11d6bfdb399) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bb/ui: Use getSetVariable command for BB_CONSOLELOGRichard Purdie2015-10-291-1/+1
| | | | | | | | | | | | | | | | | | | | Metadata can define BB_CONSOLELOG as containing ${DATETIME} and this can get expanded to a different value each time the variable is read. In the case of BB_CONSOLELOG, this behaviour is not desireable. The values of DATE/TIME are locked down at build time but this is too late for the purposes of ensuring the system can figure out the real value of BB_CONSOLELOG. The best way to do this is to set the variable into the datastore, thereby preserving its value. [YOCTO #8411] (Bitbake rev: 021f2eb55ab5863b57ed1b3f19f1b329bc1ad477) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: properly fix bitbake.lock handlingRichard Purdie2015-08-011-20/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the PR server or indeed any other child process takes some time to exit (which it sometimes does when saving its database), it can end up holding bitbake.lock after the UI exits, which led to errors if you ran bitbake commands successively - we saw this when running the PR server oe-selftest tests in OE-Core. The recent attempt to fix this wasn't quite right and ended up breaking memory resident bitbake. This time we close the lock file when cooker shuts down (inside the UI process) instead of unlocking it, and this is done in the cooker code rather than the actual UI code so it doesn't matter which UI is in use. Additionally we report that we're waiting for the lock to be released, using lsof or fuser if available to list the processes with the lock open. The 'magic' in the locking is due to all spawned subprocesses of bitbake holding an open file descriptor to the bitbake.lock. It is automatically unlocked when all those fds close the file (as all the processes terminate). We close the UI copy of the lock explicitly, then close the server process copy, any remaining open copy is therefore some proess exiting. (The reproducer for the problem is to set PRSERV_HOST = "localhost:0" and add a call to time.sleep(20) after self.server_close() in lib/prserv/serv.py, then run "bitbake -p; bitbake -p" ). Cleanup work done by Paul Eggleton <paul.eggleton@linux.intel.com>. This reverts bitbake commit 69ecd15aece54753154950c55d7af42f85ad8606 and e97a9f1528d77503b5c93e48e3de9933fbb9f3cd. (Bitbake rev: a29780bd43f74b7326fe788dbd65177b86806fcf) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty.py: Make sure bitbake.lock is unlocked before exitingLeonardo Sandoval2015-07-091-0/+20
| | | | | | | | | | | | Before exiting the UI, unlocks the bitbake.lock owned by cooker; this way consecutive bitbake executions can lock it again without trouble. [Yocto #7941] (Bitbake rev: 69ecd15aece54753154950c55d7af42f85ad8606) Signed-off-by: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty.py: fix indentRobert Yang2015-03-191-19/+19
| | | | | | | | | It used 5 spaces as the indent. (Bitbake rev: 162d35ed53d34b28b153adf643044e7f105fcff1) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty: Do not log show_versions outputRob Woolley2015-03-161-1/+1
| | | | | | | | | | | | | Every time the bitbake show versions command (bitbake -s) is run it creates a 100k log file. The consolelogfile is disabled for show environment and disabling show versions would make the behaviour match. (Bitbake rev: dee0ba94e39ea49c1e9261a5e8932356e3bb7c57) Signed-off-by: Rob Woolley <rob.woolley@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty: Catch exceptions on broken pipesRob Woolley2015-03-161-19/+24
| | | | | | | | | | | | | | | | Any exceptions that occur in calls to logging methods are automatically suppressed, including exceptions due to broken pipes. However, the knotty summary messages are printed directly to stdout, which means that any broken pipes will cause an exception traceback in python. By wrapping the summary section in a try / catch block we can check for IOError exceptions caused by broken pipes and let them pass. (Bitbake rev: 146e7e157f97b676858ecff583dd53800d997253) Signed-off-by: Rob Woolley <rob.woolley@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: command/cooker/knotty: Fix memres handling of command environment ↵Richard Purdie2015-01-211-1/+1
| | | | | | | | | | | | | | | | changes If the environment changes, we need memory resident bitbake to adapt to those changes. This adds in functionality to handle this alongside the configuration option handling code. This means that the common usage: MACHINE=X bitbake Y now works with the memory resident server. (Bitbake rev: 4d1343010da757a0c126bc22475354da44aaf8e3) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty: Ensure commandline parameters are updated in memres serverRichard Purdie2014-09-231-0/+1
| | | | | | | | | | | | | | | | When using options like -k, -f, -v and so on with the memory resident server, they'd currently only be set on the initial values passed to the original command. This ensures they now match those specified on the commandline for the options where this makes sense. To make this work, a command to update the options on the server side is required so this is added. [YOCTO #5292] (Bitbake rev: 1c75cc4d0c8b606c1fe76e6bf60bf6a32298b105) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty: ignore interrupted system callsDan McGregor2014-09-011-1/+1
| | | | | | | | | | | | | With the improved exception handling added in an earlier commit bitbake now stops when recieving a SIGWINCH. This happens frequently when disconnecting and reconnecting tmux sessions and bitbake didn't survive. Restore old behaviour of ignoring interrupted system calls but keep proper exception handling for other errors. (Bitbake rev: 418358a595c75f45b8d15160ec42bbe569562d91) Signed-off-by: Dan McGregor <dan.mcgregor@usask.ca> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty: Improve exception handlingRichard Purdie2014-08-231-1/+9
| | | | | | | | | | | | Currently, IOErrors are just passed over due to the broken Exception clause. A command like "bitbake X | <invalid command>" would break stdout triggering a traceback. With these changes we print the exceptions, shut down the server gracefully and exit which is a much nicer behaviour and is less confusion to the user. (Bitbake rev: 9544108f7b413038d871ce6ca88232de2f2434d9) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty: Move second event check into a proper blockNamhyung Kim2014-08-021-2/+2
| | | | | | | | | so that it doesn't check it twice for non-empty events (Bitbake rev: e304ace6d8f7d0808ee401b7c01146b2798a81b4) Signed-off-by: Namhyung Kim <namhyung@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty: Fix output printed to the user at debug log levelsRichard Purdie2014-05-111-1/+1
| | | | | | | | | | | | | | | | | | If a user runs with the -v or -D options, its understandable they'd expect to see log output from the workers yet right now a bug in the log handling does not show this. Fix the conditional to ensure such log output is shown on the terminal when it has been requested. Ideally this data should always flow to the logfiles but that is for another patch. This also fixes the code to do what was always intended in the comments, i.e. if the user specifies -D or -v, output is shown from the tasks, otherwise notes are suppressed. (Bitbake rev: 20a3c93d8572969e76563f29bff89400b93ffae7) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: knotty: Clear footer before outputting to stderrPeter Kjellerstedt2014-04-081-2/+3
| | | | | | | | | | | | | With the recent change to split the log output to stdout and stderr, error messages that appeared while the footer was printed got all messed up. This was because the messages to stderr was output _after_ the footer, then clearFooter() tried to remove the footer but removed the error message and parts of the footer. (Bitbake rev: 4fafea4fa69542b491e84463f6eae0d5bf645673) Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty: Show a link to the logfile for failed setscene tasksRichard Purdie2014-03-271-0/+3
| | | | | | | | | | | Its not immediately obvious to the user that a logfile exists for a failed setscene task. Add code to knotty to display where that logfile is in those cases. [YOCTO #6055] (Bitbake rev: 0664fa15597785dd90cf205531a9801e6da6ba47) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty: Split error output onto stderrRichard Purdie2014-03-271-1/+5
| | | | | | | | | | | | When using bitbake -e in scripts, it would be helpful if the error output appeared on stderr, not stdout. This change enables that building upon the new bb.msg filters. [YOCTO #5274] (Bitbake rev: ebb797fc5c37d729e3cc8b2dc7156287d385c13b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty: Ensure the progress bar shows on stdoutRichard Purdie2014-03-271-1/+1
| | | | | | | | | | | | I can understand why some programs would want the progress on stderr so that real output can be captured on stdout. This is confusing for bitbake since we don't show a progress bar at all in non-interactive cases. Therefore make sure the progress bar goes to stdout, not the stderr default. (Bitbake rev: 0529aa9966df5c56b07affe865efce18852efe5a) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-05-22 15:39:57 +0000