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<[email protected]>: >>> 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 -- Denys _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
