Re: Tell me your build error message annoyances!

[Richard Purdie <richard.purdie@linuxfoundation.org>]

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