2011/2/4 Stefan Schmidt <[email protected]>: > Hello. > > On Fri, 2011-02-04 at 08:54, Frans Meulenbroeks wrote: >> 2011/2/4 Tom Rini <[email protected]>: >> > 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. _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
