From: Phil Blundell <pb@pbcl.net>
To: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] insane bbclass: turn fatal errors back into fatal errors
Date: Fri, 01 Jul 2011 15:55:06 +0100 [thread overview]
Message-ID: <1309532106.2633.74.camel@phil-desktop> (raw)
In-Reply-To: <4FC82E26-5A0C-48DF-99F5-7E2D9B8C7290@dominion.thruhere.net>
On Thu, 2011-06-30 at 17:49 +0200, Koen Kooi wrote:
> It's a white list, so:
>
> # 0 - non dev contains .so
> # 5 - .la contains installed=yes or reference to the workdir
> # 7 - the desktop file is not valid
> # 8 - .la contains reference to the workdir
> # 9 - LDFLAGS ignored
>
> Are warnings and
>
> # 1 - package contains a dangerous RPATH
> # 2 - package depends on debug package
> # 3 - non dbg contains .so
> # 4 - wrong architecture
> # 6 - .pc contains reference to /usr/include or workdir
> # 10 - Build paths in binaries
> # 11 - package depends on devel package
>
> Are fatal errors. The splits seems arbitrary to me, but it that's how it was last year before RP disabled all fatal errors.
I guess the split does make some sense as it is, although I can't see
any reason for #8 not to be in the fatal set. #5 also seems like it
would belong there except that, as far as I can tell, that test doesn't
actually exist in the code so it's a bit academic how the results are
treated.
#7 is, in the scheme of things, a relatively minor infringement (and
usually an upstream bug anyway) so probably oughtn't to make a package
unshippable. #9 is potentially a nuisance but in most cases doesn't
cause any actual problems, so again I think it's fair for this to be a
warning.
Incidentally, it seems that the description for #6 is a bit wrong: it
doesn't actually do any checking for /usr/include. And #3 should
obviously be talking about .debug not .so.
p.
next prev parent reply other threads:[~2011-07-01 14:58 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-30 15:11 [PATCH] insane bbclass: turn fatal errors back into fatal errors Koen Kooi
2011-06-30 15:33 ` Paul Eggleton
2011-06-30 15:49 ` Koen Kooi
2011-06-30 15:59 ` Paul Eggleton
2011-07-01 16:25 ` Richard Purdie
2011-07-01 17:12 ` Richard Purdie
2011-07-01 17:16 ` Khem Raj
2011-07-01 17:25 ` Mark Hatle
2011-07-01 17:33 ` Koen Kooi
2011-07-01 18:18 ` Richard Purdie
2011-07-04 14:10 ` Paul Eggleton
2011-07-05 10:38 ` Richard Purdie
2011-07-01 14:55 ` Phil Blundell [this message]
2011-07-01 15:09 ` Koen Kooi
2011-06-30 15:58 ` Tom Rini
2011-06-30 16:08 ` Mark Hatle
2011-06-30 20:35 ` Koen Kooi
2011-06-30 20:59 ` Scott Garman
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=1309532106.2633.74.camel@phil-desktop \
--to=pb@pbcl.net \
--cc=openembedded-core@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.