[oe] bitbake does not fail when QA issues encountered

[Frans Meulenbroeks]

2011/2/4 Stefan Schmidt <stefan at datenfreihafen.org>:
> Hello.
>
> On Fri, 2011-02-04 at 08:54, Frans Meulenbroeks wrote:
>> 2011/2/4 Tom Rini <tom_rini at mentor.com>:
>> > On 02/03/2011 03:20 PM, Denys Dmytriyenko wrote:
>> >>
>> >> On Thu, Feb 03, 2011 at 10:43:26AM -0700, 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:
>> >>>>>
>> >>>>> 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).
>> >>
>> >> So, do you ack the patch, should I push it in? It will break the build for
>> >> anyone still using libtool-2.2, specifically in gettext package...
>> >
>> > So, that would break angstrom-2008.1 so I don't think that's a great idea
>> > until we fix it..
>>
>> Then again, if we push it there will be some incentive to fix it.
>
> So you are going to care care about the not yet ready for libtool 2.4 fallout?
> Get warm with openjdk-6 then as it still needs libtool 2.2. :)
>
> More serious, I think this should at least wait until after the upcoming 2011-03
> release. We need to find a balance between waiting forever and not breaking
> existing stuff.
>
Ehm, so if there is an RPATH or GNU_HASH QA error the code is *not* broken?
In that case it should not be a QA error but a QA warning.
But if it is an error then the existing stuff is already broken.
Ignoring the error then is more like ostrich behaviour.

Just my two cents.
Frans.