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 _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
