Re: [PATCH 0 of 1] Alternative debug-shell implementation

[Johannes Stezenbach <js at sig21 dot net>]

Hi Yann,

On Wed, Oct 17, 2012 at 01:38:38PM +0200, Yann E. MORIN wrote:
> On Wednesday 17 October 2012 12:15:21 Johannes Stezenbach wrote:
> > 
> > Current command (unknown), exited with error code: 1
> > Please fix it up and finish by exiting the shell with one of these values:
> >     1  fixed, continue with next build command
> >     3  abort build
> > 
> > ct-ng:~/tmp/tc/build>
> > 
> > Where scripts/crosstool-NG.sh@585 is "for step in ${CT_STEPS}; do".
> > I guess we can live with that but since there is no command
> > to fix or re-run it is a bit odd.
> 
> That's the question: for commands that are not run via CT_DoExecLog, do we
> want to spawn the debug-shell anyway, even if we can't display the command
> that failed? My opinion is: yes, because we ant to debug the fscking b!tch,
> even it it means a bit of rummaging...
> 
> At least, with the location in the error message and/or the last INFO line
> of the log, it should be relatively  easy to find the real location of the
> original error.
> 
> And remember that the debug-shell is just that: a debug-shell. Stumbling
> across such a case can be fixed by adding a CT_DoExecLog in front of the
> offending command.
> 
> In this specific case, I don't see what's wrong after just a quick glance,
> but I think it's better to fix CT_TestOrAbort (and the likes) to properly
> fail. I'll look at it tonight, when back home.

OK, guess it was just a bit unexpected for me, but it's OK.
You've got my ACK on the patch.

Thank you,
Johannes

--
For unsubscribe information see http://sourceware.org/lists.html#faq