From: Tom Rini <tom_rini@mentor.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: bitbake does not fail when QA issues encountered
Date: Thu, 27 Jan 2011 08:02:44 -0700 [thread overview]
Message-ID: <4D418914.2030703@mentor.com> (raw)
In-Reply-To: <AANLkTimy4Q0Y_3Y-=8=QCifqQUYwWmFx4T0DH+dNXPeZ@mail.gmail.com>
On 01/27/2011 04:27 AM, Frans Meulenbroeks wrote:
> 2011/1/27 Thomas Zimmermann<ml@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.
--
Tom Rini
Mentor Graphics Corporation
next prev parent reply other threads:[~2011-01-27 15:03 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-25 19:37 bitbake does not fail when QA issues encountered Maupin, Chase
2011-01-25 20:58 ` Frans Meulenbroeks
2011-01-25 21:36 ` Khem Raj
2011-01-26 10:32 ` Martyn Welch
2011-01-26 15:03 ` Maupin, Chase
2011-01-26 15:27 ` Tom Rini
2011-01-27 9:38 ` Thomas Zimmermann
2011-01-27 11:27 ` Frans Meulenbroeks
2011-01-27 15:02 ` Tom Rini [this message]
2011-02-03 7:09 ` Denys Dmytriyenko
2011-02-03 17:43 ` Tom Rini
2011-02-03 22:20 ` Denys Dmytriyenko
2011-02-03 23:09 ` Tom Rini
2011-02-04 7:54 ` Frans Meulenbroeks
2011-02-04 8:16 ` Stefan Schmidt
2011-02-04 8:37 ` Frans Meulenbroeks
2011-02-04 9:03 ` Stefan Schmidt
2011-02-04 9:57 ` Frans Meulenbroeks
2011-02-04 12:42 ` Otavio Salvador
2011-02-04 13:10 ` Frans Meulenbroeks
2011-02-04 13:58 ` Andreas Mueller
2011-02-04 14:59 ` Tom Rini
2011-02-04 15:26 ` Frans Meulenbroeks
2011-02-04 15:52 ` Otavio Salvador
2011-02-05 13:35 ` Frans Meulenbroeks
2011-02-06 1:21 ` Otavio Salvador
2011-02-06 12:02 ` Frans Meulenbroeks
2011-02-09 20:02 ` Maupin, Chase
2011-02-09 20:13 ` Maupin, Chase
2011-02-10 6:32 ` Frans Meulenbroeks
2011-02-04 17:37 ` Tom Rini
2011-02-04 14:44 ` Tom Rini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D418914.2030703@mentor.com \
--to=tom_rini@mentor.com \
--cc=openembedded-devel@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox