All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martyn Welch <martyn.welch@ge.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: bitbake does not fail when QA issues encountered
Date: Wed, 26 Jan 2011 10:32:57 +0000	[thread overview]
Message-ID: <4D3FF859.2050509@ge.com> (raw)
In-Reply-To: <AANLkTinc6eLwC5ZTu_uO=Ki00x1VQJc6vs_pFwz1f5oX@mail.gmail.com>

On 25/01/11 21:36, Khem Raj wrote:
> On Tue, Jan 25, 2011 at 12:58 PM, Frans Meulenbroeks
> <fransmeulenbroeks@gmail.com> wrote:
>> 2011/1/25 Maupin, Chase <chase.maupin@ti.com>:
>>> All,
>>>
>>> I have noticed that when building packages such as perl that while my build will report success and no errors, the return status from the bitbake command was "1".  I was able to produce this by doing:
>>>
>>> MACHINE=am37x-evm bitbake perl
>>>
>>> After bitbake completed I saw:
>>>
>>> NOTE: Tasks Summary: Attempted 851 tasks of which 0 didn't need to be rerun and 0 failed.
>>>
>>> but checking $? yields a return status of "1".
>>>
>>> I looked into the log and noticed a lot of messages like:
>>>
>>> ERROR: QA Issue with db: package db contains bad RPATH
>>>
>>> My understanding is that recent fixes to libtool 2.4 prevent these errors but I am using an older version of Angstrom which pins to libtool 2.2.  I also have found this issue with the Arago distribution which likewise uses libtool 2.2.
>>>
>>> So my question here is whether bitbake should be failing when it encounters these QA issues with a bad RPATH and exiting?
>>>
>>> If not then should the return status be "1"?  This causes issues when using a script that issues builds and then checks the return status for success or failure.  If the QA issues are deemed acceptable (or should be warnings) then I would expect the return status to not indicate a failure.
>>>
>>> I have attached a log of my build for reference
>>>
>>> As another interesting side note which I don't know is related or not, when building Arago with bitbake 1.10.2 the return status is "1".  When building the same Arago metadata with bitbake 1.8.19 the return status is "0".  What is strange here is that since Arago uses a slightly older version of the OE metadata it is not seeing the RPATH errors reported above (the check isn't in the insane.bbclass for Arago yet).  So for some reason bitbake 1.8.19 says everything went fine and bitbake 1.10.2 reports a status of "1" even though there is no reported error.  I'm not sure if this is related to the above in any way or if this is a separate issue.
>>>
>>> Sincerely,
>>> Chase Maupin
>>>
>>
>> I've seen this on other places as well.
>> I'd say if a package has a QA issue the build of that package should
>> fail, because the resulting output is defnitely not OK.
>>
> 
> yes it should fail. However some may raise questions "it used to build
> and not it doesnt"
> so someone has to fix the problems quickly
> 

...and if it is considered a failure and returns 1, the summary shouldn't be
reporting "0 failed", or at least there should be something reported at the
end of the build to state that the build has been deemed a failure for those
not running in a script and who don't read through the entire log of the build!

Martyn

>> Frans
>>
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel


-- 
Martyn Welch (Principal Software Engineer) | Registered in England and
GE Intelligent Platforms                   | Wales (3828642) at 100
T +44(0)127322748                          | Barbirolli Square, Manchester,
E martyn.welch@ge.com                      | M2 3AB  VAT:GB 927559189



  reply	other threads:[~2011-01-26 14:21 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 [this message]
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
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=4D3FF859.2050509@ge.com \
    --to=martyn.welch@ge.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.