[oe] bitbake does not fail when QA issues encountered

[Tom Rini]

On 02/03/2011 10:43 AM, Tom Rini wrote:
> 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 at 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).

I think what we need to do is take what I think the poky approach is 
which is to change QA Error to QA Warning for things we aren't willing 
"kill the build" on.  And given existing user bases we should (per 
Stefan's suggestion later) make anything that doesn't kill the build 
really today into a warning and change it post-release, or in 
meta-openembedded.  I'll try and get to this today and RFC the change.

-- 
Tom Rini
Mentor Graphics Corporation