Re: bitbake does not fail when QA issues encountered

[Tom Rini <tom_rini@mentor.com>]

On 02/03/2011 12:09 AM, Denys Dmytriyenko wrote:
> On Thu, Jan 27, 2011 at 08:02:44AM -0700, Tom Rini wrote:
>> On 01/27/2011 04:27 AM, Frans Meulenbroeks wrote:
>>> 2011/1/27 Thomas Zimmermann<ml@vdm-design.de>:
>>>> On Wednesday 26 January 2011 16:27:43 Tom Rini wrote:
>>>>> I believe, from talking with Chris Larson about this before, in 1.8.x
>>>>> the error wasn't being populated upwards, but that got fixed.  At heart
>>>>> the problem is that QA errors aren't throwing a "kill the build" type
>>>>> error.  This should be changeable (and would cause 1.8.x to fail too, if
>>>>> someone backported this change to a 1.8.x using OE) to insane.bbclass.
>>>>
>>>> I don't think that a QA error should "kill the build" because then no
>>>> build
>>>> from scratch would be possible.
>>>> We have a QA error in coreutils-native because it doesn't inherit
>>>> gettext. But
>>>> adding this inherit would result in a dependencie loop.
>>>>
>>>> So if a QA error would stop build we would need something for those
>>>> situations.
>>>>
>>>> And additionally i think that most QA errors aren't fatal because most of
>>>> them
>>>> are for non-standard .desktop files.
>>>
>>> If it is not a fatal it should probably be given as a warning
>>> (especially the non-std .desktop things)
>>> If corutils-native has a problem becuase it does not inherit gettext,
>>> then maybe (if possible) it should be added or alternately if this is
>>> not a problem it definitely should not be an error but a warning.
>>>
>>> For me an error indicates something is broken and needs fixing.
>>> Reverting that: if a condition does not break things it is not an
>>> error (and yes, I know this is quite a black and white view, and that
>>> there are situations this is not true).
>>>
>>> Generally masking errors does not make them go away.
>>
>> The problem is that today we have QA Errors that are warnings
>> (coreutils-native) and QA Errors that result in a non-zero exit code but
>> also don't "kill the build" nor make it obvious at the end that there is a
>> non-zero exit code (GNU_HASH, RPATH).  Finally we do have "kill the build"
>> fatal checks in insane.bbclass, namely the do_qa_configure tests.
>
> Actually, I believe there was a simple error in the code which made QA Error
> on RPATH not kill the build[1]. BTW, GNU_HASH QA Error does stop the build.
>
> [1] http://thread.gmane.org/gmane.comp.handhelds.openembedded/42168

Good spotting.  But.. GNU_HASH QA error will give you a non-zero exit 
code and not kill the build so we're back where we started, albeit with 
a less often hit in the community trigger (but I bet more often hit in 
private / 3rd party collections).

-- 
Tom Rini
Mentor Graphics Corporation