[oe] bitbake does not fail when QA issues encountered

[Stefan Schmidt]

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.

regards
Stefan Schmidt