"Nothing PROVIDES" errors often come up when a recipe has been skipped
for some reason, and therefore it is useful to print out that reason
information when showing the error so that the user understands why the
error has occurred.
Given that we already feed the reason information into the skiplist for
various situations (COMMERCIAL_LICENSE, COMPATIBLE_MACHINE etc.) this
should now output a useful error message for skipped recipes.
Fixes [YOCTO #846], [YOCTO #1127]
(Bitbake rev: 6765218430e31c165888f26fbc75023c89a6eab2)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It was displaying the log messages in LIFO order, which isn't what we
expect to see. Thankfully this only occurred during an early abort (e.g.
config file parsing error), but those are the cases where it's very
important to see accurate messages, to diagnose.
(Bitbake rev: b838e0f3a1b481c295f66f5c9f561fa4d51de673)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This command can be used to search each BBPATH for files in the passed
directory which have a filename matching the supplied pattern.
This is implemented for use from the GUI (to determine the available
PACKAGE_CLASSES) but has been written so as to be generically useful and
reusable.
(Bitbake rev: 2a599812a57cb0b964880a6a2b7548423497ea92)
Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This takes the name of a .conf file and returns the full path to it
(Bitbake rev: 22c8600b885faf841795b872d82f68dfb644a26e)
Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
One of the implications is we need to register the event handlers before
executing the anonymous python functions. I can't find any issue with making
that change in any existing metadata use cases.
(Bitbake rev: a981df3cc9bf410d24f39919959952bdc6c76d03)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now we use bb.exceptions to pass pickleable traceback entries to the UI, and
the UI is free to do whatever it wants to do with this information. By
default, the log formatter for the UIs formats it with bb.exceptions. This
also means that all exceptions should now show 3 lines of context and limit to
5 entries.
(Bitbake rev: ee48d628ee038bd72e1cd94aa75f5ccbacbcee4c)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Only the xmlrpc server needs pickled events. Use the function names
to signify this requirement.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This means that anyone firing an event can get a systemexit and result in
their process exiting, which isn't ideal, but behaves the way it used to (in
particular, ensures that a sanity check failure will halt the build). This
should be revisited in the future.
(Bitbake rev: d6a0ffdd583be3df734171d7e91d334f798a79ce)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Note: this includes IndentationError, which is a subclass of SyntaxError.
(Bitbake rev: 156ea134e82d873ca4b5343261da2291a2b32ef6)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
- Name the event handler by its actual name, so the traceback shows it rather
than 'tmpHandler'.
- Rather than immediately aborting when encountering an event handler error,
display an error message and try to continue.
- Show a traceback for ordinary exceptions, skipping the first entry in the
traceback, so it only shows the useful information.
- Show an error, but no traceback, for SystemExit with a code other than 0.
- For for SystemExit with a code of 0, simply continue silently.
(Bitbake rev: faf682dfc23b7ef2ece04f7d50f9741224bb3bb0)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some configuration variables (MACHINE, MACHINE-SDK and DISTRO) set which
confguration files bitbake should use.
The added command , findConfigFiles, enables a UI to query which files are
suitable values for a specified parameter.
Signed-off-by: Joshua Lock <josh@linux.intel.com>
Add a new command generateTargetsTree() which returns a dependency tree of
possible targets (tasks and recipes) as well as their dependency information.
Optional parameter 'klass' also ensures any recipes which inherit the
specified class path (i.e. 'classes/image.bbclass') are included in the model
Signed-off-by: Joshua Lock <josh@linux.intel.com>
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>
This ensures that when a failure occurs very early on in bitbake startup, the
message formatting ematches that used by the UIs.
(Bitbake rev: c8ff0fd3e9f050a668f1a069cf37ee37db3664fa)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(Bitbake rev: bdd7813d8eecf7b6b636322e748ca6bf69118513)
Signed-off-by: Bob Foerster <robert@erafx.com>
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
Rather than updating the progress bar based on the recipe being processed
(whether cached or parsed), consider only parsed recipes. This reduces the
instability in progress rate introduced by the cached entries, and allows the
ETA to be resurrected and be a bit more useful.
(Bitbake rev: 618480f7739f6ae846f67a57bee5a78efb37839d)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
This version uses a thread rather than a process, to avoid problems with
waitpid handling. This gives slightly less overall build time reduction than
the separate process for it did (this reduces a -c compile coreutils-native by
about 3 seconds, while the process reduced it by 7 seconds), however this time
is quite insignificant relative to a typical build.
The biggest issue with non-backgrounded syncing is the perceived delay before
work begins, and this resolves that without breaking anything, or so it seems.
(Bitbake rev: 5ab6c5c7b007b8c77c751582141afc07c183d672)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
- Queue up any events fired to the UI before the UI exists
- At exit, check if UIs exist, and if not, flush the queue of LogRecords to
the console directly.
- When establishing a connection from the UI to the server, flush the queue of
events to the queue in the server connection, so the UI will receive them
when it begins its event loop.
(Bitbake rev: 73488aeb317ed306f2ecf99cc9d3708526a5933c)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
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.
(Bitbake rev: c23c015cf8af1868faf293b19b80a5faf7e736a5)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
The methodpool, ${@} expansions, anonymous python functions, event handlers
now all run with the same global context, ensuring a consistent environment
for them. Added a bb.utils.better_eval function which does an eval() with the
same globals as better_exec.
(Bitbake rev: 424d7e267b009cc19b8503eadab782736d9597d0)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
Richard Purdie
Paul Eggleton
Chris Larson
Joshua Lock
Bernhard Reutner-Fischer
Richard Purdie
Bob Foerster
Richard Purdie