(Bitbake rev: 587b144ee409d444494d8d7f2d1c53ede8f7c953)
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With new bitbake UIs having the cooker exit at 'random' points
in the codebase is problematic. This patch raises an exception
which matches the situation instead.
(Bitbake rev: 181a9735d02ebd517378558e909efc8b1b118973)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These functions in the main bb module have long been deprecated
and moved to other modules. Finally remove the compatibility links.
(Bitbake rev: ccd181c3ed4852e2b9169cf19aaf18aeacddcc18)
(Bitbake rev: d7f817518c5df2524a4bcf008ba63c71a8eb48bb)
(Bitbake rev: 89b31a4fb44f2c2ad0bb4210151652cd3730418d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Sanity test failures are no longer fatal with this change so whilst
its the right idea, the code paths need more work.
This reverts commit a50017ba71250e1710a6425b60ac7e3f03d88295.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With new bitbake UIs having the cooker exit at 'random' points
in the codebase is problematic. This patch raises an exception
which matches the siutation instead.
(Bitbake rev: a50017ba71250e1710a6425b60ac7e3f03d88295)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The method this older code was accessing doesn't exist. A library shouldn't
be changing behaviour based on the environment anyway when sepcific function
calls exist to correctly setup the logging. Fix the crash if BBDEBUG was used
by moving the code to bin/bitbake.
[YOCTO #3319]
(Bitbake rev: 3a1b75037fe1e5282ffd40b037e93353405faa45)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We have a problem knowing when to show the user debug information and
when not to since the code has already shown the user suitable information
about why a failure is occurring.
This patch adds a bb.BBHandledException exception class which can be used
to identify those exceptions which don't need further explanation to
the user.
This patch uses this class for the bb.providers exceptions and ensures the
command handling code correctly filters the exceptions meaning that
"bitbake invalid"
now shows an simple error message and not a python traceback.
[YOCTO #1141 partial]
(Bitbake rev: eac9249b40ae1e3aa21e016010c862664e59a8d4)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
At the moment it bugs me a lot that we only have one effective logging
level for bitbake, despite the logging module having provision to do
more advanced things. This patch:
* Changes the core log level to the lowest level we have messages of
(DEBUG-2) so messages always flow through the core logger
* Allows build.py's task logging code to log all the output regardless
of what output is on the console and sets this so log files now
always contain debug level messages even if these don't appear
on the console
* Moves the verbose/debug/debug-domains code to be a UI side setting
* Adds a filter to the UI to only print the user requested output.
The result is more complete logfiles on disk but the usual output to the
console.
There are some behaviour changes intentionally made by this patch:
a) the -v option now controls whether output is tee'd to the console.
Ultimately, we likely want to output a message to the user about where the
log file is and avoid placing output directly onto the console for every
executing task.
b) The functions get_debug_levels, the debug_levels variable, the
set_debug_levels, the set_verbosity and set_debug_domains functions are
removed from bb.msg.
c) The "logging" init function changes format.
d) All messages get fired to all handlers all the time leading to an
increase in inter-process traffic. This could likely be hacked around
short term with a function for a UI to only request events greater than
level X. Longer term, having masks for event handlers would be better.
e) logger.getEffectiveLevel() is no longer a reliable guide to what
will/won't get logged so for now we look at the default log levels instead.
[YOCTO #304]
(Bitbake rev: 45aad2f9647df14bcfa5e755b57e1ddab377939a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It's cleaner to leave it behaving as usual, passing the exception data in the
exc_info attribute of the LogRecord where it normally lies, and then let
LogHandler make it pickleable so it can be sent to the UI.
(Bitbake rev: 3539c9474a0b53f57e614544c70a7197ecdfb130)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It turns out that while log filters added with addFilter are only associated
with that logger, and not its children, handlers are inherited, and handlers
can be filters. So, let's add filtering to our existing LogHandler class
which dispatches our log records as bitbake events.
(Bitbake rev: 0153ace246e7c88366f45c8f035a2b4505a1c115)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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
(Bitbake rev: 3b2c1fe5ca56daebb24073a9dd45723d3efd2a8d)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
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.
(Bitbake rev: 43700fa1ca1d2635de4ed46110057cb164ee82d1)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
This ensures the check is run for anyone using the package, including
setup.py, though it's sad that it's necessary, since all it really wants is
__version__.
Ideally, we'd avoid the version check entirely in favor of checking for
functionality, but that's rather difficult with language constructs like
context managers, so this'll do for now.
(Bitbake rev: f936f1c0edf70860ea0f39ec1a500ba43b56f289)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
As an example, this displays a deprecation warning for the use of
"bb.encodeurl" when you should be using "bb.fetch.encodeurl". It includes a
convenience function for this purpose. It should be of use when moving
objects between modules permanently, changing the API the user sees.
(Bitbake rev: 78f56049ba863b2e585b89db12b32697eb879bbc)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
We should add back in some proper unit testing. Doctest is rather limited,
and we haven't actually made use of it since the original implementation of
the datastore when the project started, as far as I'm aware.
(Bitbake rev: 3a11c2807972bbbddffde2fa67fc380d159da467)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
