Chris Larson [Fri, 10 Sep 2010 18:14:54 +0000 (11:14 -0700)]
Fix exit code display for task failure
Per the python documentation, os.waitpid returns the exitcode shifted up by 8
bits, and we weren't compensating, resulting in a display of 'failed with 256'
when a worker process exits with a code of 1.
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Chris Larson [Fri, 10 Sep 2010 01:03:40 +0000 (18:03 -0700)]
Simplify build exception handling
- Drop EventException
- Use FuncFailed as the primary function failure exception, using TaskFailed
for the event (leaving it up to the process running exec_{func,task} to
display the more detailed information available in the exception).
- Switch InvalidTask to an exception rather than an event, as that's a
critical issue.
- Reduce the number of messages shown to the user when a task fails -- they
don't need to be told it fails 12 times. Work remains in this area though.
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Chris Larson [Sat, 4 Sep 2010 01:58:22 +0000 (18:58 -0700)]
Merge branch 'logging'
* logging:
Drop 'fn' arguments to bb.msg functions
Add pending deprecation warnings to the bb.msg functions
Switch bitbake internals to use logging directly rather than bb.msg
Use logging in the knotty ui, and pass the log record across directly
Use the python logging module under the hood for bb.msg
Chris Larson [Thu, 10 Jun 2010 17:35:31 +0000 (10:35 -0700)]
Switch bitbake internals to use logging directly rather than bb.msg
We use a custom Logger subclass for our loggers
This logger provides:
- 'debug' method which accepts a debug level
- 'plain' method which bypasses log formatting
- 'verbose' method which is more detail than info, but less than debug
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Chris Larson [Thu, 10 Jun 2010 15:05:52 +0000 (08:05 -0700)]
Use logging in the knotty ui, and pass the log record across directly
This kills firing of Msg* events in favor of just passing along LogRecord
objects. These objects hold more than just level and message, but can also
have exception information, so the UI can decide what to do with that.
As an aside, when using the 'none' server, this results in the log messages in
the server being displayed directly via the logging module and the UI's
handler, rather than going through the server's event queue. As a result of
doing it this way, we have to override the event handlers of the base logger
when spawning a worker process, to ensure they log via events rather than
directly.
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Chris Larson [Wed, 11 Aug 2010 20:52:30 +0000 (13:52 -0700)]
Merge branch 'sched'
* sched:
Split out 'find next buildable task' into a separate generator function
Let the RunQueueScheduler control the number of active tasks
Add the ability to use runqueue schedulers from the metadata
Chris Larson [Thu, 22 Jul 2010 18:27:10 +0000 (11:27 -0700)]
Add the ability to use runqueue schedulers from the metadata
If you create a runqueue scheduler class in a python module, available in the
usual python search path, you can now make it available to bitbake via the
BB_SCHEDULERS variable, and the user can then select it as they select any
other scheduler.
Example usage:
In a test.py I placed appropriately:
import bb.runqueue
class TestScheduler(bb.runqueue.RunQueueScheduler):
name = "myscheduler"
In local.conf, to make it available and select it:
Chris Larson [Thu, 5 Aug 2010 04:58:51 +0000 (21:58 -0700)]
When shutting down, send SIGTERM, not SIGINT
SIGINT should be from the user, not a script. It also doesn't work as
reliably to shut down processes, as it's not always interpreted as a
termination request. In addition, it causes KeyboardInterrupt exceptions in
the worker processes, which can interfere with our exception handling.
utils: Fix number of arguments to bb.msg functions
the 'fn' argument of them is not used, should be removed anytime:
sed -i -e
'/^def.*fn/s/,[[:space:]]*fn[[:space:]]*=[[:space:]]*None[[:space:]]*)/)/g'
lib/bb/msg.py
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
Chris Larson [Thu, 22 Jul 2010 17:54:58 +0000 (10:54 -0700)]
Let the runqueue find the user selected scheduler dynamically
Searches the module (bb.runqueue) for any new style classes which are
instances of RunQueueScheduler, and uses the one whose 'name' attribute
matches the value of BB_SCHEDULER.
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Jeff Dike [Tue, 29 Jun 2010 12:33:24 +0000 (13:33 +0100)]
create cooker object after cleaning the environment
Previously, the cooker object was created before the environment was
cleaned, saving everything that was in the environment and dumping
into the run scripts.
The patch ensures that the cooker gets a cleaned environment when it's
created.
Jeff Dike [Tue, 29 Jun 2010 12:32:04 +0000 (13:32 +0100)]
Move the logger initialization from cooker to utils
In order to move the environment cleaning, which wants to log a
message, before cooker creation, the logging facility initialization
needs to happen earlier. So, it is now in init_logger in utils.py and
called from bitbake before the creation of the data object.
It also seems more correct to initialize a global facility like this
from a more global context than the creation of an object, of which
there could theoretically be many.
Nitin A Kamble [Fri, 4 Jun 2010 04:50:02 +0000 (21:50 -0700)]
bitbake decodeurl: fix the file:// url handling
Without this patch decoding a url of this kind file://dir/filename gives
path=/filename host=dir.
With the patch it decodes as path=/dir/filename host=""
Probably nobody stumbled on this issue yet because nobody used
file:// urls with directory names in the path.
Chris Larson [Thu, 10 Jun 2010 16:14:39 +0000 (09:14 -0700)]
Switch a fatal usage to SystemExit ("T" not set)
This failure is one the *user* needs to see, as it may have to do with their
setup, but where they don't need to see a traceback and all, since they're not
developers, so I think SystemExit is appropriate here.
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Chris Larson [Thu, 10 Jun 2010 16:43:39 +0000 (09:43 -0700)]
Use PendingDeprecationWarning for functions moved from bb to bb.utils
This is necessary, as there has not yet been a release with the bb.utils
versions in place. We can't show them a deprecation warning when they can't
safely change it yet. Show a PendingDeprecationWarning until 1.10 releases
and OE requires it, then we can move to DeprecationWarning.
Signed-off-by: Chris Larson <chris_larson@mentor.com>
projects / thirdparty / openembedded / openembedded-core-contrib.git / log
