<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Feb 9, 2016 at 8:41 AM Mark Hatle <<a href="mailto:mark.hatle@windriver.com">mark.hatle@windriver.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm sending this as an RFC. I know the patch works, but I think it highlights<br>
a potentially larger issue in the system.<br>
<br>
If we're processing data using shell pipes, the return code of a failed<br>
process may end up being lost -- avoiding the regular error capture when<br>
bitbake runs a task.<br>
<br>
In this particular case, while working to fix a bug in pseudo we made an<br>
error condition fatal (triggered an abort()), but buildhistory kept on<br>
processing ignoring any issues had occurred.<br>
<br>
Breaking up the processing into steps, things that 'could fail', and later<br>
processing steps that shouldn't fail will give us more of an opportunity to<br>
identify failures in the future and deal with them in a quicker manner,<br>
then having to investigate log files for messages.<br>
<br>
I'm suspecting we should run a janitor exercise against oe-core looking for<br>
similar situations where we might be piping the data and potentially losing<br>
return codes in the process.<br>
<br>
Comments?<br></blockquote><div><br></div><div>Hmm, wonder if it'd be worth adding the ability to inject extra 'set' options to the start of all emitted shell tasks, and make it obey SHELL, so you could set SHELL=bash and set -o pipefail.</div></div></div>