[OE-core] Tell me your build error message annoyances!
Richard Purdie
richard.purdie at linuxfoundation.org
Fri Jun 3 08:11:36 UTC 2011
On Thu, 2011-06-02 at 23:10 -0700, Darren Hart wrote:
> These are maybe a bit off topic, but I'll leave it to you to decide if
> they meet the criteria for this effort.
>
> o bb.debug messages are not logged anywhere nor do they appear on the
> console with -DDD during recipe parsing (while bb.note messages do
> make it to the console).
This isn't a priority for Scott's work at this point IMO.
> o I'm seeing duplicate messages lately - no examples handy, I'll post
> or open a bug next time.
This is a genuine bug that seems to have crept in recently which need to
fix, not sure its Scott who needs to do it though.
> o The bash logging facility (logging.bbclass) is still a second class
> citizen and probably needs a bitbake server hook so bbnote, bbplain,
> bbdebug, etc. can call into bitbake proper and use the python
> equivalents and therefor also make it to the proper destination
> (console or log).
This also isn't a priority for Scott's work at this point IMO.
> o It's been mentioned, but I'd like to second that most of the time,
> getting a traceback is really not very helpful. Chris Larson mentioned
> moving the exception handling higher up the stack - I think that
> makes a lot of sense. I'd also suggest not printing a traceback unless
> running with at least -D. A catchall try block that only
> does:
>
> print "Unhandled exception:", e
>
> under normal conditions and prints a trace with -D enabled would clean
> things up a lot I think.
I'm going to disagree here a little here. If something unexpected
happens we always need the traceback so the pastebin'd error message
means something to the developers. Currently it shows up even when the
failure is a known error case and a message has been printed to the user
and this is a bug though.
If we get exception handling right I think we solve this problem too.
> o In general I find the default UI to be exceedingly noisy. It feels
> very much like what I would write for something I was actively
> developing - ie, something I expect to break a lot! I don't think
> that's the sort of impression we want users to have while building a
> release (for example).
>
> I'd prefer if what we currently get today was the output of -D. The
> current output could instead be something a lot more in the vein of
> what we see with recipe parsing. Perhaps one line per
> BB_NUMBER_TREADS (N), maybe something like:
>
> Task 2300/4600 [#################### ]
> 0: linux-yocto: do_compile
> 1: matchbox: do_fetch
> ...
> N: dbus: do_configure
>
> It would of course update the current lines and not scroll. Most of
> the time, this would be plenty information.
You're describing the code in the ncurses UI. It is there and you can
run it but its unfinished :(.
> Upon failure we stop
> updating the "UI" and print something like:
>
> ERROR: An unhandled exception occured while processing
> linux-yocto: do_fetch
>
> Exception: No such file or directory.
>
> Run with -D for a more detailed error report or consult the
> appropriate log file:
>
> $(pwd)/tmp/work/$machine/linux-yocto-$HASH-$HASH \
> /temp/log.do_fetch.$PID
>
> Or something along those lines.
You should never be asked to rerun something, it should know when to
print the right information.
Cheers,
Richard
More information about the Openembedded-core
mailing list