Re: [OE-core] Tell me your build error message annoyances!
On Tue, 2011-05-31 at 15:26 -0700, Scott Garman wrote: I'd like to collect some feedback on error messages while building that you find confusing/annoying/unhelpful. I'm going to be working on trying to improve the situation and would like to hear from you about what could be more helpful. Here's another one which, although perhaps slightly off-topic for your current effort, still seems to fall into all three of the categories you mentioned :-) After I made a typo (mismatched quotes) in one of my recipes, my next bitbake run printed: Loading cache: 100% |#| ETA: 00:00:00 Loaded 1323 entries from dependency cache. NOTE: Error expanding variable do_configure | ETA: --:--:-- ERROR: Command execution failed: Traceback (most recent call last):# | ETA: 00:00:00 File /home/pb/oe/bitbake/lib/bb/command.py, line 99, in runAsyncCommand self.cooker.updateCache() File /home/pb/oe/bitbake/lib/bb/cooker.py, line 871, in updateCache if not self.parser.parse_next(): File /home/pb/oe/bitbake/lib/bb/cooker.py, line 1120, in parse_next self.shutdown(clean=False) File /home/pb/oe/bitbake/lib/bb/cooker.py, line 1102, in shutdown bb.codeparser.parser_cache_save(self.cfgdata) File /home/pb/oe/bitbake/lib/bb/codeparser.py, line 77, in parser_cache_save data, version = p.load() EOFError So, this is (a) confusing, because EOFError doesn't yield much information about the actual cause of the problem; (b) unhelpful, since it doesn't mention which line of the file (or even which recipe) was to blame; and (c) annoying, for the usual reasons to do with python traceback. Somewhat worse, even after I fixed the typo, any subsequent attempt to run bitbake would just result in: Loading cache: 100% |#| ETA: 00:00:00 Loaded 1323 entries from dependency cache. Traceback (most recent call last): | ETA: --:--:-- File /usr/lib/python2.6/multiprocessing/util.py, line 235, in _run_finalizers finalizer() File /usr/lib/python2.6/multiprocessing/util.py, line 174, in __call__ res = self._callback(*self._args, **self._kwargs) File /home/pb/oe/bitbake/lib/bb/codeparser.py, line 77, in parser_cache_save data, version = p.load() EOFError (repeated about 10 times) I deleted tmp/cache/* and that seemed to fix the problem. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Tell me your build error message annoyances!
On Thu, 2011-06-09 at 12:02 +0100, Phil Blundell wrote: After I made a typo (mismatched quotes) in one of my recipes, my next bitbake run printed: Loading cache: 100% |#| ETA: 00:00:00 Loaded 1323 entries from dependency cache. NOTE: Error expanding variable do_configure | ETA: --:--:-- ERROR: Command execution failed: Traceback (most recent call last):# | ETA: 00:00:00 File /home/pb/oe/bitbake/lib/bb/command.py, line 99, in runAsyncCommand self.cooker.updateCache() File /home/pb/oe/bitbake/lib/bb/cooker.py, line 871, in updateCache if not self.parser.parse_next(): File /home/pb/oe/bitbake/lib/bb/cooker.py, line 1120, in parse_next self.shutdown(clean=False) File /home/pb/oe/bitbake/lib/bb/cooker.py, line 1102, in shutdown bb.codeparser.parser_cache_save(self.cfgdata) File /home/pb/oe/bitbake/lib/bb/codeparser.py, line 77, in parser_cache_save data, version = p.load() EOFError So, this is (a) confusing, because EOFError doesn't yield much information about the actual cause of the problem; (b) unhelpful, since it doesn't mention which line of the file (or even which recipe) was to blame; and (c) annoying, for the usual reasons to do with python traceback. Somewhat worse, even after I fixed the typo, any subsequent attempt to run bitbake would just result in: Loading cache: 100% |#| ETA: 00:00:00 Loaded 1323 entries from dependency cache. Traceback (most recent call last): | ETA: --:--:-- File /usr/lib/python2.6/multiprocessing/util.py, line 235, in _run_finalizers finalizer() File /usr/lib/python2.6/multiprocessing/util.py, line 174, in __call__ res = self._callback(*self._args, **self._kwargs) File /home/pb/oe/bitbake/lib/bb/codeparser.py, line 77, in parser_cache_save data, version = p.load() EOFError (repeated about 10 times) I deleted tmp/cache/* and that seemed to fix the problem. FWIW, bitbake master has fixes for this specific issue and a number of other codeparser performance related issues. If it meets EOF while loading it will now just assume the cache file is corrupt and ignore/rebuild it. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Tell me your build error message annoyances!
On Mon, 2011-06-06 at 21:53 -0700, Darren Hart wrote: On 06/03/2011 08:47 AM, Chris Larson wrote: Heh, I used to have a personal branch where I dropped those, and also removed the unnecessary NOTE: prefix. I think its a given that something that doesn't indicate a warning or an error is simply informative :) The problem with dropping those messages is for postprocessing scripts, which may well want/need to know when a task completes, not just when it starts. Still, yet another case of something we could drop as long as we log it. We need to add a main bitbake execution log that captures everything, including debug messages, whether the user specifies -D or not. In most systems, running with -D implies not only greater verbosity, but also reduced performance. I haven't checked, but I expect that is the case with bitbake as well. I don't think we want to enable all of -D and log it by default. I'm not sure the performance hit of this would be that great to be honest, particularly if we localised the output to the tasks and didn't hit the IPC mechanism for all the messages. It certainly could be valuable to have more robust logfiles on disk so that when things do break we can dive into them and get full debug info rather than the current partial info. The main cost would be increased disk space but disks are cheap comparatively and the IO is minor compared to other things we do... Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Tell me your build error message annoyances!
On 06/02/2011 11:10 PM, Darren Hart wrote: o I'm seeing duplicate messages lately - no examples handy, I'll post or open a bug next time. Hi Darren, Before I can file a bug for this, I'll need more details/a reproducible test case. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Tell me your build error message annoyances!
On 06/03/2011 08:47 AM, Chris Larson wrote: On Fri, Jun 3, 2011 at 8:43 AM, Phil Blundell p...@pbcl.net wrote: On Fri, 2011-06-03 at 09:22 -0500, Mark Hatle wrote: I believe currently we have around 3-5 messages per step, and it's still too noisy -- unless you need to debug something. Correct. Right now, the output looks like: NOTE: Running task 613 of 728 (ID: 190, virtual:native:/home/pb/oe/oe-core/meta/recipes-core/util-linux/util-linux_2.19.1.bb, do_install) NOTE: package util-linux-native-2.19.1-r0: task do_install: Started NOTE: package util-linux-native-2.19.1-r0: task do_install: Succeeded NOTE: Running task 614 of 728 (ID: 191, virtual:native:/home/pb/oe/oe-core/meta/recipes-core/util-linux/util-linux_2.19.1.bb, do_populate_sysroot) NOTE: package util-linux-native-2.19.1-r0: task do_populate_sysroot: Started NOTE: package util-linux-native-2.19.1-r0: task do_populate_sysroot: Succeeded It looks as though the Started and Succeeded lines could just be deleted without losing any real information. Heh, I used to have a personal branch where I dropped those, and also removed the unnecessary NOTE: prefix. I think its a given that something that doesn't indicate a warning or an error is simply informative :) The problem with dropping those messages is for postprocessing scripts, which may well want/need to know when a task completes, not just when it starts. Still, yet another case of something we could drop as long as we log it. We need to add a main bitbake execution log that captures everything, including debug messages, whether the user specifies -D or not. In most systems, running with -D implies not only greater verbosity, but also reduced performance. I haven't checked, but I expect that is the case with bitbake as well. I don't think we want to enable all of -D and log it by default. Thanks, -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Tell me your build error message annoyances!
On 05/31/2011 03:26 PM, Scott Garman wrote: Hey folks, I'd like to collect some feedback on error messages while building that you find confusing/annoying/unhelpful. I'm going to be working on trying to improve the situation and would like to hear from you about what could be more helpful. I'm starting to track some of these situations with the following bugs: http://bugzilla.pokylinux.org/show_bug.cgi?id=542 http://bugzilla.pokylinux.org/show_bug.cgi?id=1127 http://bugzilla.pokylinux.org/show_bug.cgi?id=1128 I can't promise to fix everything you come up with, but I'd like to try to make a dent in some of these issues and improve the usability of our build system. Thanks, Scott 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). o I'm seeing duplicate messages lately - no examples handy, I'll post or open a bug next time. 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). 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. 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. 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. Thanks for collecting these Scott, great idea! -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Tell me your build error message annoyances!
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
Re: [OE-core] Tell me your build error message annoyances!
On 6/3/11 1:10 AM, Darren Hart wrote: On 05/31/2011 03:26 PM, Scott Garman wrote: ... 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 have heard similar comments from others as well. 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. Upon failure we stop updating the UI and print something like: Even if it did scroll, somehow limiting the messages being printed would be beneficial. It's been suggested to me simply one (or two) messages per step MAX. Running linux-yocto do_compile Running matchbox do_fetch ... I believe currently we have around 3-5 messages per step, and it's still too noisy -- unless you need to debug something. 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. Thanks for collecting these Scott, great idea! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Tell me your build error message annoyances!
On Wed, Jun 01, 2011 at 05:25:58PM +0100, Richard Purdie wrote: On Wed, 2011-06-01 at 16:06 +0100, Phil Blundell wrote: On Tue, 2011-05-31 at 15:26 -0700, Scott Garman wrote: I'd like to collect some feedback on error messages while building that you find confusing/annoying/unhelpful. I'm going to be working on trying to improve the situation and would like to hear from you about what could be more helpful. Funnily enough we were just having a discussion about this on irc. My personal top two least favourite diagnostics are: a) bitbake -b nonexistent-file gives ten lines of so of python exception traceback and then prints MultipleMatches. b) bitbake -b recipe.bb, with a recipe that skips (due to an inCOMPATIBLE_MACHINE or whatever) gives the traditional ten lines of traceback spew and then prints TypeError: 'NoneType' object is not iterable. This is with bitbake 1.13.0. Agreed, these are issues. I'd like to highlight that there is an underlying design issue in bitbake which make these hard issues to fix. Its very hard for bitbake to work out when it needs to show the traceback and when it doesn't. If the user has been given an explanation of the problem we shouldn't show the traceback but its hard to know that is the case. Somehow we therefore need to improve the error infrastructure in bitbake to be able to tell the difference between an unexpected error where a traceback is useful and a known error which has been explained to the user and no traceback is required. Well perhaps it would be easier to build a list of packages that have been skipped? I think the cache knows about them. Perhaps they could be reported to a skipped file or something similar? --mark ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Tell me your build error message annoyances!
On Friday 03 June 2011 15:35:45 mark gross wrote: Well perhaps it would be easier to build a list of packages that have been skipped? I think the cache knows about them. Perhaps they could be reported to a skipped file or something similar? FYI there is a patch I submitted the other day to bitbake-devel which tracks these in their own internal list. The next step is that when a NoProvider event comes up we can look through this list to see if the requested target is in there, and if so report that it was skipped along with the reason why. I would think that this obviates the need to show the list of skipped packages at the start, although we could easily allow them to be reported via some other mechanism. This is a separate exercise to sorting out the flow of exceptions within bitbake, but still very important for the overall task of improving error output. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Tell me your build error message annoyances!
Op 1 jun 2011, om 00:26 heeft Scott Garman het volgende geschreven: Hey folks, I'd like to collect some feedback on error messages while building that you find confusing/annoying/unhelpful. I'm going to be working on trying to improve the situation and would like to hear from you about what could be more helpful. I'm starting to track some of these situations with the following bugs: http://bugzilla.pokylinux.org/show_bug.cgi?id=542 http://bugzilla.pokylinux.org/show_bug.cgi?id=1127 http://bugzilla.pokylinux.org/show_bug.cgi?id=1128 I can't promise to fix everything you come up with, but I'd like to try to make a dent in some of these issues and improve the usability of our build system. This one popped up recently, -b doesn't work anymore: koen@dominion:/OE/tentacle/sources/meta-texasinstruments/recipes-kernel/linux$ ls | grep omap4 linux-omap4/ linux-omap4_2.6.35.3.bb linux-omap4-2.6.35.7/ linux-omap4_2.6.35.7.bb koen@dominion:/OE/tentacle/sources/meta-texasinstruments/recipes-kernel/linux$ MACHINE=omap4430-panda bitbake -b $PWD/linux-omap4_2.6.35.7.bb ERROR: Command execution failed: Traceback (most recent call last): File /OE/tentacle/sources/bitbake/lib/bb/command.py, line 102, in runAsyncCommand commandmethod(self.cmds_async, self, options) File /OE/tentacle/sources/bitbake/lib/bb/command.py, line 190, in buildFile command.cooker.buildFile(bfile, task) File /OE/tentacle/sources/bitbake/lib/bb/cooker.py, line 722, in buildFile fn = self.matchFile(fn) File /OE/tentacle/sources/bitbake/lib/bb/cooker.py, line 700, in matchFile matches = self.matchFiles(buildfile) File /OE/tentacle/sources/bitbake/lib/bb/cooker.py, line 683, in matchFiles filelist, masked = self.collect_bbfiles() File /OE/tentacle/sources/bitbake/lib/bb/cooker.py, line 948, in collect_bbfiles files.sort( key=lambda fileitem: self.calc_bbfile_priority(fileitem) ) File /OE/tentacle/sources/bitbake/lib/bb/cooker.py, line 948, in lambda files.sort( key=lambda fileitem: self.calc_bbfile_priority(fileitem) ) File /OE/tentacle/sources/bitbake/lib/bb/cooker.py, line 411, in calc_bbfile_priority for _, _, regex, pri in self.status.bbfile_config_priorities: AttributeError: 'NoneType' object has no attribute 'bbfile_config_priorities' 'bitbake linux-omap4-2.6.35.7' does work, though ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Tell me your build error message annoyances!
On Fri, 2011-06-03 at 09:22 -0500, Mark Hatle wrote: I believe currently we have around 3-5 messages per step, and it's still too noisy -- unless you need to debug something. Correct. Right now, the output looks like: NOTE: Running task 613 of 728 (ID: 190, virtual:native:/home/pb/oe/oe-core/meta/recipes-core/util-linux/util-linux_2.19.1.bb, do_install) NOTE: package util-linux-native-2.19.1-r0: task do_install: Started NOTE: package util-linux-native-2.19.1-r0: task do_install: Succeeded NOTE: Running task 614 of 728 (ID: 191, virtual:native:/home/pb/oe/oe-core/meta/recipes-core/util-linux/util-linux_2.19.1.bb, do_populate_sysroot) NOTE: package util-linux-native-2.19.1-r0: task do_populate_sysroot: Started NOTE: package util-linux-native-2.19.1-r0: task do_populate_sysroot: Succeeded It looks as though the Started and Succeeded lines could just be deleted without losing any real information. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Tell me your build error message annoyances!
On Fri, Jun 3, 2011 at 8:43 AM, Phil Blundell p...@pbcl.net wrote: On Fri, 2011-06-03 at 09:22 -0500, Mark Hatle wrote: I believe currently we have around 3-5 messages per step, and it's still too noisy -- unless you need to debug something. Correct. Right now, the output looks like: NOTE: Running task 613 of 728 (ID: 190, virtual:native:/home/pb/oe/oe-core/meta/recipes-core/util-linux/util-linux_2.19.1.bb, do_install) NOTE: package util-linux-native-2.19.1-r0: task do_install: Started NOTE: package util-linux-native-2.19.1-r0: task do_install: Succeeded NOTE: Running task 614 of 728 (ID: 191, virtual:native:/home/pb/oe/oe-core/meta/recipes-core/util-linux/util-linux_2.19.1.bb, do_populate_sysroot) NOTE: package util-linux-native-2.19.1-r0: task do_populate_sysroot: Started NOTE: package util-linux-native-2.19.1-r0: task do_populate_sysroot: Succeeded It looks as though the Started and Succeeded lines could just be deleted without losing any real information. Heh, I used to have a personal branch where I dropped those, and also removed the unnecessary NOTE: prefix. I think its a given that something that doesn't indicate a warning or an error is simply informative :) The problem with dropping those messages is for postprocessing scripts, which may well want/need to know when a task completes, not just when it starts. Still, yet another case of something we could drop as long as we log it. We need to add a main bitbake execution log that captures everything, including debug messages, whether the user specifies -D or not. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Tell me your build error message annoyances!
On Wed, 2011-06-01 at 16:06 +0100, Phil Blundell wrote: On Tue, 2011-05-31 at 15:26 -0700, Scott Garman wrote: I'd like to collect some feedback on error messages while building that you find confusing/annoying/unhelpful. I'm going to be working on trying to improve the situation and would like to hear from you about what could be more helpful. Funnily enough we were just having a discussion about this on irc. My personal top two least favourite diagnostics are: Another non-favourite: if you fail to specify the right protocol for the git fetcher then you end up with something like: ERROR: Function 'Fetcher failure for URL: 'None'. Fetch command export HOME=/home/pb; export GIT_CONFIG=/home/pb/oe/build/tmp-eglibc/sysroots/x86_64-linux/usr/etc/gitconfig; export PATH=...; git ls-remote rsync://gitolite@cam-git/pb/linux-2.6.35 master failed with signal 128, output: fatal: Could not make temporary directory: No such file or directory ' failed Usually the value of $PATH is about half a screenful so this error looks more monstrous in real life than it probably does above, and it isn't immediately apparent that the no such file or directory thing is a result of having tried to fetch with the wrong URI scheme. This is made slightly more irritating by the fact that there isn't much consistency between the different fetchers about the URI structure; some of them want a proto attribute whereas others (including git) want protocol, so it's harder than perhaps it ought to be to remember what the correct naming is. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Tell me your build error message annoyances!
On Wed, 2011-06-01 at 16:06 +0100, Phil Blundell wrote: On Tue, 2011-05-31 at 15:26 -0700, Scott Garman wrote: I'd like to collect some feedback on error messages while building that you find confusing/annoying/unhelpful. I'm going to be working on trying to improve the situation and would like to hear from you about what could be more helpful. Funnily enough we were just having a discussion about this on irc. My personal top two least favourite diagnostics are: a) bitbake -b nonexistent-file gives ten lines of so of python exception traceback and then prints MultipleMatches. b) bitbake -b recipe.bb, with a recipe that skips (due to an inCOMPATIBLE_MACHINE or whatever) gives the traditional ten lines of traceback spew and then prints TypeError: 'NoneType' object is not iterable. This is with bitbake 1.13.0. Agreed, these are issues. I'd like to highlight that there is an underlying design issue in bitbake which make these hard issues to fix. Its very hard for bitbake to work out when it needs to show the traceback and when it doesn't. If the user has been given an explanation of the problem we shouldn't show the traceback but its hard to know that is the case. Somehow we therefore need to improve the error infrastructure in bitbake to be able to tell the difference between an unexpected error where a traceback is useful and a known error which has been explained to the user and no traceback is required. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Tell me your build error message annoyances!
On Wed, Jun 1, 2011 at 9:25 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Wed, 2011-06-01 at 16:06 +0100, Phil Blundell wrote: On Tue, 2011-05-31 at 15:26 -0700, Scott Garman wrote: I'd like to collect some feedback on error messages while building that you find confusing/annoying/unhelpful. I'm going to be working on trying to improve the situation and would like to hear from you about what could be more helpful. Funnily enough we were just having a discussion about this on irc. My personal top two least favourite diagnostics are: a) bitbake -b nonexistent-file gives ten lines of so of python exception traceback and then prints MultipleMatches. b) bitbake -b recipe.bb, with a recipe that skips (due to an inCOMPATIBLE_MACHINE or whatever) gives the traditional ten lines of traceback spew and then prints TypeError: 'NoneType' object is not iterable. This is with bitbake 1.13.0. Agreed, these are issues. I'd like to highlight that there is an underlying design issue in bitbake which make these hard issues to fix. Its very hard for bitbake to work out when it needs to show the traceback and when it doesn't. If the user has been given an explanation of the problem we shouldn't show the traceback but its hard to know that is the case. Somehow we therefore need to improve the error infrastructure in bitbake to be able to tell the difference between an unexpected error where a traceback is useful and a known error which has been explained to the user and no traceback is required. I think we have too many places where exceptions are responded to. If we pushed the handling up as far as we can, it'd reduce the duplication of error handling code a great deal. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
