[PATCH] insane.bbclass: Make RPATH a non-fatal error

[PATCH] insane.bbclass: Make RPATH a non-fatal error

[Tom Rini]

In order to make the user experience better we now use bb.warn
on non-fatal QA errors and bb.error on fatal errors.

Signed-off-by: Tom Rini <tom_rini@mentor.com>
---
 classes/insane.bbclass |   12 +++++++++---
 1 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/classes/insane.bbclass b/classes/insane.bbclass
index a846832..3b042c9 100644
--- a/classes/insane.bbclass
+++ b/classes/insane.bbclass
@@ -116,7 +116,7 @@ def package_qa_make_fatal_error(error_class, name, path,d):
 
     TODO: Load a whitelist of known errors
     """
-    return not error_class in [0, 5, 7]
+    return not error_class in [0, 1, 5, 7]
 
 def package_qa_write_error(error_class, name, path, d):
     """
@@ -145,10 +145,16 @@ def package_qa_write_error(error_class, name, path, d):
              (ERROR_NAMES[error_class], name, package_qa_clean_path(path,d))
     f.close()
 
+# Returns False is there was a fatal problem and True if we did not hit a fatal
+# error
 def package_qa_handle_error(error_class, error_msg, name, path, d):
-    bb.error("QA Issue with %s: %s" % (name, error_msg))
+    fatal = package_qa_make_fatal_error(error_class, name, path, d)
     package_qa_write_error(error_class, name, path, d)
-    return not package_qa_make_fatal_error(error_class, name, path, d)
+    if fatal:
+        bb.error("QA Issue with %s: %s" % (name, error_msg))
+    else:
+        bb.warn("QA Issue with %s: %s" % (name, error_msg))
+    return not fatal
 
 def package_qa_check_rpath(file,name,d, elf):
     """
-- 
1.7.3.5

Re: [PATCH] insane.bbclass: Make RPATH a non-fatal error

[Khem Raj]

On (18/02/11 12:26), Tom Rini wrote:
> In order to make the user experience better we now use bb.warn
> on non-fatal QA errors and bb.error on fatal errors.
> 
> Signed-off-by: Tom Rini <tom_rini@mentor.com>

I really would like to get these issues fixed but I guess from grand
scheme of things for now

Acked-by: Khem Raj <raj.khem@gmail.com>

> ---
>  classes/insane.bbclass |   12 +++++++++---
>  1 files changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/classes/insane.bbclass b/classes/insane.bbclass
> index a846832..3b042c9 100644
> --- a/classes/insane.bbclass
> +++ b/classes/insane.bbclass
> @@ -116,7 +116,7 @@ def package_qa_make_fatal_error(error_class, name, path,d):
>  
>      TODO: Load a whitelist of known errors
>      """
> -    return not error_class in [0, 5, 7]
> +    return not error_class in [0, 1, 5, 7]
>  
>  def package_qa_write_error(error_class, name, path, d):
>      """
> @@ -145,10 +145,16 @@ def package_qa_write_error(error_class, name, path, d):
>               (ERROR_NAMES[error_class], name, package_qa_clean_path(path,d))
>      f.close()
>  
> +# Returns False is there was a fatal problem and True if we did not hit a fatal
> +# error
>  def package_qa_handle_error(error_class, error_msg, name, path, d):
> -    bb.error("QA Issue with %s: %s" % (name, error_msg))
> +    fatal = package_qa_make_fatal_error(error_class, name, path, d)
>      package_qa_write_error(error_class, name, path, d)
> -    return not package_qa_make_fatal_error(error_class, name, path, d)
> +    if fatal:
> +        bb.error("QA Issue with %s: %s" % (name, error_msg))
> +    else:
> +        bb.warn("QA Issue with %s: %s" % (name, error_msg))
> +    return not fatal
>  
>  def package_qa_check_rpath(file,name,d, elf):
>      """
> -- 
> 1.7.3.5
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

-- 
-Khem

Re: [PATCH] insane.bbclass: Make RPATH a non-fatal error

[Tom Rini]

On 02/18/2011 12:26 PM, Tom Rini wrote:
> In order to make the user experience better we now use bb.warn
> on non-fatal QA errors and bb.error on fatal errors.

Part of my motivation here is that after looking at poky, this error is 
_not_ fatal there yet (none are), and until we can kill libtool 2.2.x 
(which won't be until oe-core I believe) this is going to be a big 
problem to solve, generally involving a libtool hack.  I think we can 
best spend our time here on fixing RPATH issues that still show up once 
we're all using libtool 2.4 (as there will still be a few in 'odd' 
packages, but most will now be correct automatically).

I'm going to push this into my simplify-target-flags branch as well and 
see what falls out now (doing so already for smaller test cases).

-- 
Tom Rini
Mentor Graphics Corporation

Re: [PATCH] insane.bbclass: Make RPATH a non-fatal error

[Denys Dmytriyenko]

On Fri, Feb 18, 2011 at 12:36:45PM -0700, Tom Rini wrote:
> On 02/18/2011 12:26 PM, Tom Rini wrote:
>> In order to make the user experience better we now use bb.warn
>> on non-fatal QA errors and bb.error on fatal errors.
>
> Part of my motivation here is that after looking at poky, this error is 
> _not_ fatal there yet (none are), and until we can kill libtool 2.2.x 
> (which won't be until oe-core I believe) this is going to be a big problem 
> to solve, generally involving a libtool hack.  I think we can best spend 
> our time here on fixing RPATH issues that still show up once we're all 
> using libtool 2.4 (as there will still be a few in 'odd' packages, but most 
> will now be correct automatically).
>
> I'm going to push this into my simplify-target-flags branch as well and see 
> what falls out now (doing so already for smaller test cases).

Since our own Arago overlay still uses libtool 2.2 (disabling RPATH check 
locally), I fully support this change in OE until everyone adopts libtool 2.4

Acked-by: Denys Dmytriyenko <denys@ti.com>

-- 
Denys

Re: [PATCH] insane.bbclass: Make RPATH a non-fatal error

[Eric Bénard]

On 18/02/2011 20:26, Tom Rini wrote:
> In order to make the user experience better we now use bb.warn
> on non-fatal QA errors and bb.error on fatal errors.
>
> Signed-off-by: Tom Rini<tom_rini@mentor.com>
Acked-by: Eric Bénard <eric@eukrea.com>

Re: [PATCH] insane.bbclass: Make RPATH a non-fatal error

[Eric Benard]

On 18/02/2011 20:26, Tom Rini wrote:
> In order to make the user experience better we now use bb.warn
> on non-fatal QA errors and bb.error on fatal errors.
>
> Signed-off-by: Tom Rini<tom_rini@mentor.com>
Acked-by: Eric Benard <eric@eukrea.com>

Re: [PATCH] insane.bbclass: Make RPATH a non-fatal error

[Frans Meulenbroeks]

I am fine with the patch, but perhaps a better solution would be to
introduce a var to decide whether it is a fatal or not.
That way people distro's that use libtool 2.4 can decide to make it a
fatal. (or individual users in their local.conf)

Frans

Re: [PATCH] insane.bbclass: Make RPATH a non-fatal error

[Andreas Mueller]

On Saturday 19 February 2011 10:45:38 Frans Meulenbroeks wrote:
> I am fine with the patch, but perhaps a better solution would be to
> introduce a var to decide whether it is a fatal or not.
> That way people distro's that use libtool 2.4 can decide to make it a
> fatal. (or individual users in their local.conf)
> 
> Frans
How comes that I sometimes feel handled as spammer ;-) ?

see http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-
February/029534.html

anyway - treating RPATH errors as fatal has lead to many QA fixes and further 
will follow...

my opinion now: keep RPATH errors fatal as developer's  whip :-) 

Andreas

Re: [PATCH] insane.bbclass: Make RPATH a non-fatal error

[Otavio Salvador]

On Sat, Feb 19, 2011 at 11:52, Andreas Mueller <schnitzeltony@gmx.de> wrote:
> On Saturday 19 February 2011 10:45:38 Frans Meulenbroeks wrote:
>> I am fine with the patch, but perhaps a better solution would be to
>> introduce a var to decide whether it is a fatal or not.
>> That way people distro's that use libtool 2.4 can decide to make it a
>> fatal. (or individual users in their local.conf)
>>
>> Frans
> How comes that I sometimes feel handled as spammer ;-) ?
>
> see http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-
> February/029534.html
>
> anyway - treating RPATH errors as fatal has lead to many QA fixes and further
> will follow...
>
> my opinion now: keep RPATH errors fatal as developer's  whip :-)

I agree about keeping it configurable.

Besides I think that we ought to keep it fatal until quite near of
release since we'll be "forced" to fix most of many of them.

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: [PATCH] insane.bbclass: Make RPATH a non-fatal error

[Tom Rini]

On 02/19/2011 06:26 AM, Otavio Salvador wrote:
> On Sat, Feb 19, 2011 at 11:52, Andreas Mueller<schnitzeltony@gmx.de>  wrote:
>> On Saturday 19 February 2011 10:45:38 Frans Meulenbroeks wrote:
>>> I am fine with the patch, but perhaps a better solution would be to
>>> introduce a var to decide whether it is a fatal or not.
>>> That way people distro's that use libtool 2.4 can decide to make it a
>>> fatal. (or individual users in their local.conf)
>>>
>>> Frans
>> How comes that I sometimes feel handled as spammer ;-) ?
>>
>> see http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-
>> February/029534.html
>>
>> anyway - treating RPATH errors as fatal has lead to many QA fixes and further
>> will follow...
>>
>> my opinion now: keep RPATH errors fatal as developer's  whip :-)
>
> I agree about keeping it configurable.
>
> Besides I think that we ought to keep it fatal until quite near of
> release since we'll be "forced" to fix most of many of them.

I just want to state, again, that most of these just go away with 
libtool 2.4.  Now, if people are looking for something to work on that 
won't just go away with an update to libtool 2.4:
- iscsi-target needs some love again for various kernel versions as that 
looks to be killing calamari and neek for nas-server-image
- 'micro' only builds for minimal-image and meta-toolchain, everything 
else has some build problem or another.

And I'm sure I'll have more logs as I sort out my autobuilder after the 
weekend.

-- 
Tom Rini
Mentor Graphics Corporation

Re: [PATCH] insane.bbclass: Make RPATH a non-fatal error

[Frans Meulenbroeks]

2011/2/19 Tom Rini <tom_rini@mentor.com>:
> On 02/19/2011 06:26 AM, Otavio Salvador wrote:
>>
>> On Sat, Feb 19, 2011 at 11:52, Andreas Mueller<schnitzeltony@gmx.de>
>>  wrote:
>>>
>>> On Saturday 19 February 2011 10:45:38 Frans Meulenbroeks wrote:
>>>>
>>>> I am fine with the patch, but perhaps a better solution would be to
>>>> introduce a var to decide whether it is a fatal or not.
>>>> That way people distro's that use libtool 2.4 can decide to make it a
>>>> fatal. (or individual users in their local.conf)
>>>>
>>>> Frans
>>>
>>> How comes that I sometimes feel handled as spammer ;-) ?
>>>
>>> see http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-
>>> February/029534.html
>>>
>>> anyway - treating RPATH errors as fatal has lead to many QA fixes and
>>> further
>>> will follow...
>>>
>>> my opinion now: keep RPATH errors fatal as developer's  whip :-)
>>
>> I agree about keeping it configurable.
>>
>> Besides I think that we ought to keep it fatal until quite near of
>> release since we'll be "forced" to fix most of many of them.
>
> I just want to state, again, that most of these just go away with libtool
> 2.4.  Now, if people are looking for something to work on that won't just go
> away with an update to libtool 2.4:
> - iscsi-target needs some love again for various kernel versions as that
> looks to be killing calamari and neek for nas-server-image

Peeked at iscsi-target for calamari. Some inet fields have changed
name in 2.6.32 or so, and apparently this is not handled fully.
Instead of trying to fix it, I moved the calamari recipe to 2.6.34
(which I'm already using for half a year or so, but apparently never
pushed).

I'll also see if I can update the neek version (probably also by
moving the kernel version forward.
Tomorrow I'll discuss this with Walter who afaik is the only other neek user.

Frans.

> - 'micro' only builds for minimal-image and meta-toolchain, everything else
> has some build problem or another.
>
> And I'm sure I'll have more logs as I sort out my autobuilder after the
> weekend.
>
> --
> Tom Rini
> Mentor Graphics Corporation
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: [PATCH] insane.bbclass: Make RPATH a non-fatal error

[Tom Rini]

On 02/20/2011 05:42 AM, Frans Meulenbroeks wrote:
> 2011/2/19 Tom Rini<tom_rini@mentor.com>:
>> On 02/19/2011 06:26 AM, Otavio Salvador wrote:
>>>
>>> On Sat, Feb 19, 2011 at 11:52, Andreas Mueller<schnitzeltony@gmx.de>
>>>   wrote:
>>>>
>>>> On Saturday 19 February 2011 10:45:38 Frans Meulenbroeks wrote:
>>>>>
>>>>> I am fine with the patch, but perhaps a better solution would be to
>>>>> introduce a var to decide whether it is a fatal or not.
>>>>> That way people distro's that use libtool 2.4 can decide to make it a
>>>>> fatal. (or individual users in their local.conf)
>>>>>
>>>>> Frans
>>>>
>>>> How comes that I sometimes feel handled as spammer ;-) ?
>>>>
>>>> see http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-
>>>> February/029534.html
>>>>
>>>> anyway - treating RPATH errors as fatal has lead to many QA fixes and
>>>> further
>>>> will follow...
>>>>
>>>> my opinion now: keep RPATH errors fatal as developer's  whip :-)
>>>
>>> I agree about keeping it configurable.
>>>
>>> Besides I think that we ought to keep it fatal until quite near of
>>> release since we'll be "forced" to fix most of many of them.
>>
>> I just want to state, again, that most of these just go away with libtool
>> 2.4.  Now, if people are looking for something to work on that won't just go
>> away with an update to libtool 2.4:
>> - iscsi-target needs some love again for various kernel versions as that
>> looks to be killing calamari and neek for nas-server-image
>
> Peeked at iscsi-target for calamari. Some inet fields have changed
> name in 2.6.32 or so, and apparently this is not handled fully.
> Instead of trying to fix it, I moved the calamari recipe to 2.6.34
> (which I'm already using for half a year or so, but apparently never
> pushed).

Thanks.

> I'll also see if I can update the neek version (probably also by
> moving the kernel version forward.
> Tomorrow I'll discuss this with Walter who afaik is the only other neek user.

Note that I also see:
- uclibc total failure, but I assume unsupported and I'll drop
- minimal fails everywhere else with:
ERROR: QA Issue with staging: libsupc++.la failed sanity test (workdir) 
in path 
/var/hudson/workspace/sb_openembedded_autobuilder/BBPKGS/native-sdk-image/DISTRO/minimal/MACHINE/neek/label/sb-u1004/tmp/sysroots/nios2-linux/usr/lib
ERROR: QA Issue with staging: libstdc++.la failed sanity test (workdir) 
in path 
/var/hudson/workspace/sb_openembedded_autobuilder/BBPKGS/native-sdk-image/DISTRO/minimal/MACHINE/neek/label/sb-u1004/tmp/sysroots/nios2-linux/usr/lib
ERROR: QA staging was broken by the package built above

-- 
Tom Rini
Mentor Graphics Corporation

Re: [PATCH] insane.bbclass: Make RPATH a non-fatal error

[Eric Benard]

Hi Tom,

On 20/02/2011 15:46, Tom Rini wrote:
> - minimal fails everywhere else with:
> ERROR: QA Issue with staging: libsupc++.la failed sanity test (workdir) in
> path
> /var/hudson/workspace/sb_openembedded_autobuilder/BBPKGS/native-sdk-image/DISTRO/minimal/MACHINE/neek/label/sb-u1004/tmp/sysroots/nios2-linux/usr/lib
>
> ERROR: QA Issue with staging: libstdc++.la failed sanity test (workdir) in
> path
> /var/hudson/workspace/sb_openembedded_autobuilder/BBPKGS/native-sdk-image/DISTRO/minimal/MACHINE/neek/label/sb-u1004/tmp/sysroots/nios2-linux/usr/lib
>
can you try with this patch  ?
http://patches.openembedded.org/patch/719/

Eric

Re: [PATCH] insane.bbclass: Make RPATH a non-fatal error

[Andreas Mueller]

On Sunday 20 February 2011 15:46:48 Tom Rini wrote:
> On 02/20/2011 05:42 AM, Frans Meulenbroeks wrote:
> > 2011/2/19 Tom Rini<tom_rini@mentor.com>:
> >> On 02/19/2011 06:26 AM, Otavio Salvador wrote:
> >>> On Sat, Feb 19, 2011 at 11:52, Andreas Mueller<schnitzeltony@gmx.de>
> >>> 
> >>>   wrote:
> >>>> On Saturday 19 February 2011 10:45:38 Frans Meulenbroeks wrote:
> >>>>> I am fine with the patch, but perhaps a better solution would be to
> >>>>> introduce a var to decide whether it is a fatal or not.
> >>>>> That way people distro's that use libtool 2.4 can decide to make it a
> >>>>> fatal. (or individual users in their local.conf)
> >>>>> 
> >>>>> Frans
> >>>> 
> >>>> How comes that I sometimes feel handled as spammer ;-) ?
> >>>> 
> >>>> see http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-
> >>>> February/029534.html
> >>>> 
> >>>> anyway - treating RPATH errors as fatal has lead to many QA fixes and
> >>>> further
> >>>> will follow...
> >>>> 
> >>>> my opinion now: keep RPATH errors fatal as developer's  whip :-)
> >>> 
> >>> I agree about keeping it configurable.
> >>> 
> >>> Besides I think that we ought to keep it fatal until quite near of
> >>> release since we'll be "forced" to fix most of many of them.
> >> 
> >> I just want to state, again, that most of these just go away with
> >> libtool 2.4.  Now, if people are looking for something to work on that
> >> won't just go away with an update to libtool 2.4:
> >> - iscsi-target needs some love again for various kernel versions as that
> >> looks to be killing calamari and neek for nas-server-image
> > 
> > Peeked at iscsi-target for calamari. Some inet fields have changed
> > name in 2.6.32 or so, and apparently this is not handled fully.
> > Instead of trying to fix it, I moved the calamari recipe to 2.6.34
> > (which I'm already using for half a year or so, but apparently never
> > pushed).
> 
> Thanks.
> 
> > I'll also see if I can update the neek version (probably also by
> > moving the kernel version forward.
> > Tomorrow I'll discuss this with Walter who afaik is the only other neek
> > user.
> 
> Note that I also see:
> - uclibc total failure, but I assume unsupported and I'll drop
> - minimal fails everywhere else with:
> ERROR: QA Issue with staging: libsupc++.la failed sanity test (workdir)
> in path
> /var/hudson/workspace/sb_openembedded_autobuilder/BBPKGS/native-sdk-image/D
> ISTRO/minimal/MACHINE/neek/label/sb-u1004/tmp/sysroots/nios2-linux/usr/lib
> ERROR: QA Issue with staging: libstdc++.la failed sanity test (workdir) in
> path
> /var/hudson/workspace/sb_openembedded_autobuilder/BBPKGS/native-sdk-image/D
> ISTRO/minimal/MACHINE/neek/label/sb-u1004/tmp/sysroots/nios2-linux/usr/lib
> ERROR: QA staging was broken by the package built above
Can you try this with the cross.bbclass patch?

Re: [PATCH] insane.bbclass: Make RPATH a non-fatal error

[Tom Rini]

On 02/20/2011 08:05 AM, Andreas Mueller wrote:
> On Sunday 20 February 2011 15:46:48 Tom Rini wrote:
>> On 02/20/2011 05:42 AM, Frans Meulenbroeks wrote:
>>> 2011/2/19 Tom Rini<tom_rini@mentor.com>:
>>>> On 02/19/2011 06:26 AM, Otavio Salvador wrote:
>>>>> On Sat, Feb 19, 2011 at 11:52, Andreas Mueller<schnitzeltony@gmx.de>
>>>>>
>>>>>    wrote:
>>>>>> On Saturday 19 February 2011 10:45:38 Frans Meulenbroeks wrote:
>>>>>>> I am fine with the patch, but perhaps a better solution would be to
>>>>>>> introduce a var to decide whether it is a fatal or not.
>>>>>>> That way people distro's that use libtool 2.4 can decide to make it a
>>>>>>> fatal. (or individual users in their local.conf)
>>>>>>>
>>>>>>> Frans
>>>>>>
>>>>>> How comes that I sometimes feel handled as spammer ;-) ?
>>>>>>
>>>>>> see http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-
>>>>>> February/029534.html
>>>>>>
>>>>>> anyway - treating RPATH errors as fatal has lead to many QA fixes and
>>>>>> further
>>>>>> will follow...
>>>>>>
>>>>>> my opinion now: keep RPATH errors fatal as developer's  whip :-)
>>>>>
>>>>> I agree about keeping it configurable.
>>>>>
>>>>> Besides I think that we ought to keep it fatal until quite near of
>>>>> release since we'll be "forced" to fix most of many of them.
>>>>
>>>> I just want to state, again, that most of these just go away with
>>>> libtool 2.4.  Now, if people are looking for something to work on that
>>>> won't just go away with an update to libtool 2.4:
>>>> - iscsi-target needs some love again for various kernel versions as that
>>>> looks to be killing calamari and neek for nas-server-image
>>>
>>> Peeked at iscsi-target for calamari. Some inet fields have changed
>>> name in 2.6.32 or so, and apparently this is not handled fully.
>>> Instead of trying to fix it, I moved the calamari recipe to 2.6.34
>>> (which I'm already using for half a year or so, but apparently never
>>> pushed).
>>
>> Thanks.
>>
>>> I'll also see if I can update the neek version (probably also by
>>> moving the kernel version forward.
>>> Tomorrow I'll discuss this with Walter who afaik is the only other neek
>>> user.
>>
>> Note that I also see:
>> - uclibc total failure, but I assume unsupported and I'll drop
>> - minimal fails everywhere else with:
>> ERROR: QA Issue with staging: libsupc++.la failed sanity test (workdir)
>> in path
>> /var/hudson/workspace/sb_openembedded_autobuilder/BBPKGS/native-sdk-image/D
>> ISTRO/minimal/MACHINE/neek/label/sb-u1004/tmp/sysroots/nios2-linux/usr/lib
>> ERROR: QA Issue with staging: libstdc++.la failed sanity test (workdir) in
>> path
>> /var/hudson/workspace/sb_openembedded_autobuilder/BBPKGS/native-sdk-image/D
>> ISTRO/minimal/MACHINE/neek/label/sb-u1004/tmp/sysroots/nios2-linux/usr/lib
>> ERROR: QA staging was broken by the package built above
> Can you try this with the cross.bbclass patch?

I'll do a smaller subset test for that patch once the big build is done 
(I hope less than 24h left for that).

-- 
Tom Rini
Mentor Graphics Corporation

Re: [PATCH] insane.bbclass: Make RPATH a non-fatal error

[Frans Meulenbroeks]

2011/2/20 Tom Rini <tom_rini@mentor.com>:
> On 02/20/2011 05:42 AM, Frans Meulenbroeks wrote:
>>
>> 2011/2/19 Tom Rini<tom_rini@mentor.com>:
>>>
>>> On 02/19/2011 06:26 AM, Otavio Salvador wrote:
>>>>
>>>> On Sat, Feb 19, 2011 at 11:52, Andreas Mueller<schnitzeltony@gmx.de>
>>>>  wrote:
>>>>>
>>>>> On Saturday 19 February 2011 10:45:38 Frans Meulenbroeks wrote:
>>>>>>
>>>>>> I am fine with the patch, but perhaps a better solution would be to
>>>>>> introduce a var to decide whether it is a fatal or not.
>>>>>> That way people distro's that use libtool 2.4 can decide to make it a
>>>>>> fatal. (or individual users in their local.conf)
>>>>>>
>>>>>> Frans
>>>>>
>>>>> How comes that I sometimes feel handled as spammer ;-) ?
>>>>>
>>>>> see http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-
>>>>> February/029534.html
>>>>>
>>>>> anyway - treating RPATH errors as fatal has lead to many QA fixes and
>>>>> further
>>>>> will follow...
>>>>>
>>>>> my opinion now: keep RPATH errors fatal as developer's  whip :-)
>>>>
>>>> I agree about keeping it configurable.
>>>>
>>>> Besides I think that we ought to keep it fatal until quite near of
>>>> release since we'll be "forced" to fix most of many of them.
>>>
>>> I just want to state, again, that most of these just go away with libtool
>>> 2.4.  Now, if people are looking for something to work on that won't just
>>> go
>>> away with an update to libtool 2.4:
>>> - iscsi-target needs some love again for various kernel versions as that
>>> looks to be killing calamari and neek for nas-server-image
>>
>> Peeked at iscsi-target for calamari. Some inet fields have changed
>> name in 2.6.32 or so, and apparently this is not handled fully.
>> Instead of trying to fix it, I moved the calamari recipe to 2.6.34
>> (which I'm already using for half a year or so, but apparently never
>> pushed).
>
> Thanks.
>
>> I'll also see if I can update the neek version (probably also by
>> moving the kernel version forward.
>> Tomorrow I'll discuss this with Walter who afaik is the only other neek
>> user.
>
> Note that I also see:
> - uclibc total failure, but I assume unsupported and I'll drop
> - minimal fails everywhere else with:
> ERROR: QA Issue with staging: libsupc++.la failed sanity test (workdir) in
> path
> /var/hudson/workspace/sb_openembedded_autobuilder/BBPKGS/native-sdk-image/DISTRO/minimal/MACHINE/neek/label/sb-u1004/tmp/sysroots/nios2-linux/usr/lib
> ERROR: QA Issue with staging: libstdc++.la failed sanity test (workdir) in
> path
> /var/hudson/workspace/sb_openembedded_autobuilder/BBPKGS/native-sdk-image/DISTRO/minimal/MACHINE/neek/label/sb-u1004/tmp/sysroots/nios2-linux/usr/lib
> ERROR: QA staging was broken by the package built above
>
>
Also mentioned this on irc, I will try patch 719 that is suggested
below, but this could be a toolchain issue (it would not be the
first).
Toolchain for nios is quite old (gcc 4.1.something, binutils 2.18.50.something).
It should be able to build minimal-image for distro minimal and micro.
And as far as I know neither uclibc nor eglibc are supported.
THen again it has been a while since I managed to give this attention.

Frans.

Re: [PATCH] insane.bbclass: Make RPATH a non-fatal error

[Andreas Mueller]

On Sunday 20 February 2011 17:31:26 Frans Meulenbroeks wrote:
> 2011/2/20 Tom Rini <tom_rini@mentor.com>:
> > On 02/20/2011 05:42 AM, Frans Meulenbroeks wrote:
> >> 2011/2/19 Tom Rini<tom_rini@mentor.com>:
> >>> On 02/19/2011 06:26 AM, Otavio Salvador wrote:
> >>>> On Sat, Feb 19, 2011 at 11:52, Andreas Mueller<schnitzeltony@gmx.de>
> >>>> 
> >>>>  wrote:
> >>>>> On Saturday 19 February 2011 10:45:38 Frans Meulenbroeks wrote:
> >>>>>> I am fine with the patch, but perhaps a better solution would be to
> >>>>>> introduce a var to decide whether it is a fatal or not.
> >>>>>> That way people distro's that use libtool 2.4 can decide to make it
> >>>>>> a fatal. (or individual users in their local.conf)
> >>>>>> 
> >>>>>> Frans
> >>>>> 
> >>>>> How comes that I sometimes feel handled as spammer ;-) ?
> >>>>> 
> >>>>> see http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-
> >>>>> February/029534.html
> >>>>> 
> >>>>> anyway - treating RPATH errors as fatal has lead to many QA fixes and
> >>>>> further
> >>>>> will follow...
> >>>>> 
> >>>>> my opinion now: keep RPATH errors fatal as developer's  whip :-)
> >>>> 
> >>>> I agree about keeping it configurable.
> >>>> 
> >>>> Besides I think that we ought to keep it fatal until quite near of
> >>>> release since we'll be "forced" to fix most of many of them.
> >>> 
> >>> I just want to state, again, that most of these just go away with
> >>> libtool 2.4.  Now, if people are looking for something to work on that
> >>> won't just go
> >>> away with an update to libtool 2.4:
> >>> - iscsi-target needs some love again for various kernel versions as
> >>> that looks to be killing calamari and neek for nas-server-image
> >> 
> >> Peeked at iscsi-target for calamari. Some inet fields have changed
> >> name in 2.6.32 or so, and apparently this is not handled fully.
> >> Instead of trying to fix it, I moved the calamari recipe to 2.6.34
> >> (which I'm already using for half a year or so, but apparently never
> >> pushed).
> > 
> > Thanks.
> > 
> >> I'll also see if I can update the neek version (probably also by
> >> moving the kernel version forward.
> >> Tomorrow I'll discuss this with Walter who afaik is the only other neek
> >> user.
> > 
> > Note that I also see:
> > - uclibc total failure, but I assume unsupported and I'll drop
> > - minimal fails everywhere else with:
> > ERROR: QA Issue with staging: libsupc++.la failed sanity test (workdir)
> > in path
> > /var/hudson/workspace/sb_openembedded_autobuilder/BBPKGS/native-sdk-image
> > /DISTRO/minimal/MACHINE/neek/label/sb-u1004/tmp/sysroots/nios2-linux/usr/
> > lib ERROR: QA Issue with staging: libstdc++.la failed sanity test
> > (workdir) in path
> > /var/hudson/workspace/sb_openembedded_autobuilder/BBPKGS/native-sdk-image
> > /DISTRO/minimal/MACHINE/neek/label/sb-u1004/tmp/sysroots/nios2-linux/usr/
> > lib ERROR: QA staging was broken by the package built above
> 
> Also mentioned this on irc, I will try patch 719 that is suggested
> below, but this could be a toolchain issue (it would not be the
> first).
> Toolchain for nios is quite old (gcc 4.1.something, binutils
> 2.18.50.something). It should be able to build minimal-image for distro
> minimal and micro. And as far as I know neither uclibc nor eglibc are
> supported.
Maybe a misunderstanding on my side but: patch 719 only affects libtool-2.2 
distros. I think minimal and micro distro do not pin libtool version so use 
libtool-2.4.
> THen again it has been a while since I managed to give this attention.
> 
> Frans.
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [PATCH] insane.bbclass: Make RPATH a non-fatal error

[Frans Meulenbroeks]

2011/2/20 Andreas Mueller <schnitzeltony@gmx.de>:
> On Sunday 20 February 2011 17:31:26 Frans Meulenbroeks wrote:
>> 2011/2/20 Tom Rini <tom_rini@mentor.com>:
>> > On 02/20/2011 05:42 AM, Frans Meulenbroeks wrote:
>> >> 2011/2/19 Tom Rini<tom_rini@mentor.com>:
>> >>> On 02/19/2011 06:26 AM, Otavio Salvador wrote:
>> >>>> On Sat, Feb 19, 2011 at 11:52, Andreas Mueller<schnitzeltony@gmx.de>
>> >>>>
>> >>>>  wrote:
>> >>>>> On Saturday 19 February 2011 10:45:38 Frans Meulenbroeks wrote:
>> >>>>>> I am fine with the patch, but perhaps a better solution would be to
>> >>>>>> introduce a var to decide whether it is a fatal or not.
>> >>>>>> That way people distro's that use libtool 2.4 can decide to make it
>> >>>>>> a fatal. (or individual users in their local.conf)
>> >>>>>>
>> >>>>>> Frans
>> >>>>>
>> >>>>> How comes that I sometimes feel handled as spammer ;-) ?
>> >>>>>
>> >>>>> see http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-
>> >>>>> February/029534.html
>> >>>>>
>> >>>>> anyway - treating RPATH errors as fatal has lead to many QA fixes and
>> >>>>> further
>> >>>>> will follow...
>> >>>>>
>> >>>>> my opinion now: keep RPATH errors fatal as developer's  whip :-)
>> >>>>
>> >>>> I agree about keeping it configurable.
>> >>>>
>> >>>> Besides I think that we ought to keep it fatal until quite near of
>> >>>> release since we'll be "forced" to fix most of many of them.
>> >>>
>> >>> I just want to state, again, that most of these just go away with
>> >>> libtool 2.4.  Now, if people are looking for something to work on that
>> >>> won't just go
>> >>> away with an update to libtool 2.4:
>> >>> - iscsi-target needs some love again for various kernel versions as
>> >>> that looks to be killing calamari and neek for nas-server-image
>> >>
>> >> Peeked at iscsi-target for calamari. Some inet fields have changed
>> >> name in 2.6.32 or so, and apparently this is not handled fully.
>> >> Instead of trying to fix it, I moved the calamari recipe to 2.6.34
>> >> (which I'm already using for half a year or so, but apparently never
>> >> pushed).
>> >
>> > Thanks.
>> >
>> >> I'll also see if I can update the neek version (probably also by
>> >> moving the kernel version forward.
>> >> Tomorrow I'll discuss this with Walter who afaik is the only other neek
>> >> user.
>> >
>> > Note that I also see:
>> > - uclibc total failure, but I assume unsupported and I'll drop
>> > - minimal fails everywhere else with:
>> > ERROR: QA Issue with staging: libsupc++.la failed sanity test (workdir)
>> > in path
>> > /var/hudson/workspace/sb_openembedded_autobuilder/BBPKGS/native-sdk-image
>> > /DISTRO/minimal/MACHINE/neek/label/sb-u1004/tmp/sysroots/nios2-linux/usr/
>> > lib ERROR: QA Issue with staging: libstdc++.la failed sanity test
>> > (workdir) in path
>> > /var/hudson/workspace/sb_openembedded_autobuilder/BBPKGS/native-sdk-image
>> > /DISTRO/minimal/MACHINE/neek/label/sb-u1004/tmp/sysroots/nios2-linux/usr/
>> > lib ERROR: QA staging was broken by the package built above
>>
>> Also mentioned this on irc, I will try patch 719 that is suggested
>> below, but this could be a toolchain issue (it would not be the
>> first).
>> Toolchain for nios is quite old (gcc 4.1.something, binutils
>> 2.18.50.something). It should be able to build minimal-image for distro
>> minimal and micro. And as far as I know neither uclibc nor eglibc are
>> supported.
> Maybe a misunderstanding on my side but: patch 719 only affects libtool-2.2
> distros. I think minimal and micro distro do not pin libtool version so use
> libtool-2.4.

Ah ok, I think you are right, thanks for bringing that up.
Guess it'll need some more attention, but as it stands I am quite
constrained on time upcoming few days.

Frans.

Re: [PATCH] insane.bbclass: Make RPATH a non-fatal error

[Frans Meulenbroeks]

2011/2/20 Tom Rini <tom_rini@mentor.com>:
> On 02/20/2011 05:42 AM, Frans Meulenbroeks wrote:
>>
>> 2011/2/19 Tom Rini<tom_rini@mentor.com>:
>>>
>>> On 02/19/2011 06:26 AM, Otavio Salvador wrote:
>>>>
>>>> On Sat, Feb 19, 2011 at 11:52, Andreas Mueller<schnitzeltony@gmx.de>
>>>>  wrote:
>>>>>
>>>>> On Saturday 19 February 2011 10:45:38 Frans Meulenbroeks wrote:
>>>>>>
>>>>>> I am fine with the patch, but perhaps a better solution would be to
>>>>>> introduce a var to decide whether it is a fatal or not.
>>>>>> That way people distro's that use libtool 2.4 can decide to make it a
>>>>>> fatal. (or individual users in their local.conf)
>>>>>>
>>>>>> Frans
>>>>>
>>>>> How comes that I sometimes feel handled as spammer ;-) ?
>>>>>
>>>>> see http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-
>>>>> February/029534.html
>>>>>
>>>>> anyway - treating RPATH errors as fatal has lead to many QA fixes and
>>>>> further
>>>>> will follow...
>>>>>
>>>>> my opinion now: keep RPATH errors fatal as developer's  whip :-)
>>>>
>>>> I agree about keeping it configurable.
>>>>
>>>> Besides I think that we ought to keep it fatal until quite near of
>>>> release since we'll be "forced" to fix most of many of them.
>>>
>>> I just want to state, again, that most of these just go away with libtool
>>> 2.4.  Now, if people are looking for something to work on that won't just
>>> go
>>> away with an update to libtool 2.4:
>>> - iscsi-target needs some love again for various kernel versions as that
>>> looks to be killing calamari and neek for nas-server-image
>>
>> Peeked at iscsi-target for calamari. Some inet fields have changed
>> name in 2.6.32 or so, and apparently this is not handled fully.
>> Instead of trying to fix it, I moved the calamari recipe to 2.6.34
>> (which I'm already using for half a year or so, but apparently never
>> pushed).
>
> Thanks.
>
>> I'll also see if I can update the neek version (probably also by
>> moving the kernel version forward.
>> Tomorrow I'll discuss this with Walter who afaik is the only other neek
>> user.
>
> Note that I also see:
> - uclibc total failure, but I assume unsupported and I'll drop
> - minimal fails everywhere else with:
> ERROR: QA Issue with staging: libsupc++.la failed sanity test (workdir) in
> path
> /var/hudson/workspace/sb_openembedded_autobuilder/BBPKGS/native-sdk-image/DISTRO/minimal/MACHINE/neek/label/sb-u1004/tmp/sysroots/nios2-linux/usr/lib
> ERROR: QA Issue with staging: libstdc++.la failed sanity test (workdir) in
> path
> /var/hudson/workspace/sb_openembedded_autobuilder/BBPKGS/native-sdk-image/DISTRO/minimal/MACHINE/neek/label/sb-u1004/tmp/sysroots/nios2-linux/usr/lib
> ERROR: QA staging was broken by the package built above
>

Peeked some more itnto this.

If I peek in ./nios2-linux/usr/lib/libsupc++.la I see:

# libsupc++.la - a libtool library file
# Generated by ltmain.sh - GNU libtool 1.4a-GCC3.0 (1.641.2.256
2001/05/28 20:09:07 with GCC-local changes)
#
# Please DO NOT delete this file!
# It is necessary for linking the library.

# The name that we can dlopen(3).
dlname=''

# Names of this library.
library_names=''

# The name of the static archive.
old_library='libsupc++.a'

# Libraries that this one depends upon.
dependency_libs='
-L/home/frans/oe/tmp_minimal/work/nios2-linux/gcc-cross-4.1.2-r27.2/gcc-4.1.2/build.i686-linux.nios2-linux/nios2-linux/libstdc++-v3/src
-L/home/frans/oe/tmp_minimal/work/nios2-linux/gcc-cross-4.1.2-r27.2/gcc-4.1.2/build.i686-linux.nios2-linux/nios2-linux/libstdc++-v3/src/.libs
-lm -L/home/frans/oe/tmp_minimal/work/nios2-linux/gcc-cross-4.1.2-r27.2/gcc-4.1.2/build.i686-linux.nios2-linux/./gcc
-L/home/frans/oe/tmp_minimal/sysroots/i686-linux/usr/nios2/nios2-linux/bin
-L/home/frans/oe/tmp_minimal/sysroots/i686-linux/usr/nios2/nios2-linux/lib
-L/home/frans/oe/tmp_minimal/sysroots/i686-linux/usr/nios2/lib/gcc/nios2-linux/4.1.2
-L/home/frans/oe/tmp_minimal/sysroots/i686-linux/usr/nios2/lib/gcc/nios2-linux/4.1.2/../../../../nios2-linux/lib
-L/home/frans/oe/tmp_minimal/sysroots/nios2-linux/lib
-L/home/frans/oe/tmp_minimal/sysroots/nios2-linux/usr/lib -lgcc_s -lc
-lgcc_s

...

For other platforms I see
# libsupc++.la - a libtool library file
# Generated by libtool (GNU libtool 1.3134 2009-11-29) 2.2.7a
#
# Please DO NOT delete this file!
# It is necessary for linking the library.

# The name that we can dlopen(3).
dlname=''

# Names of this library.
library_names=''

# The name of the static archive.
old_library='libsupc++.a'

# Linker flags that can not go in dependency_libs.
inherited_linker_flags=''

# Libraries that this one depends upon.
dependency_libs=''
...

Note the different versions of libtool and the different dependency libs
I guess the libsupc++ comes from gcc and nios2 has a very old gcc
(4.1.2), but there is no newer version (nios2 support is not
mainlined).
Anyone a suggestion?

Frans.

Re: [PATCH] insane.bbclass: Make RPATH a non-fatal error

[Andreas Mueller]

On Sunday 20 February 2011 19:26:23 Frans Meulenbroeks wrote:
> 2011/2/20 Tom Rini <tom_rini@mentor.com>:
> > On 02/20/2011 05:42 AM, Frans Meulenbroeks wrote:
> >> 2011/2/19 Tom Rini<tom_rini@mentor.com>:
> >>> On 02/19/2011 06:26 AM, Otavio Salvador wrote:
> >>>> On Sat, Feb 19, 2011 at 11:52, Andreas Mueller<schnitzeltony@gmx.de>
> >>>> 
> >>>>  wrote:
> >>>>> On Saturday 19 February 2011 10:45:38 Frans Meulenbroeks wrote:
> >>>>>> I am fine with the patch, but perhaps a better solution would be to
> >>>>>> introduce a var to decide whether it is a fatal or not.
> >>>>>> That way people distro's that use libtool 2.4 can decide to make it
> >>>>>> a fatal. (or individual users in their local.conf)
> >>>>>> 
> >>>>>> Frans
> >>>>> 
> >>>>> How comes that I sometimes feel handled as spammer ;-) ?
> >>>>> 
> >>>>> see http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-
> >>>>> February/029534.html
> >>>>> 
> >>>>> anyway - treating RPATH errors as fatal has lead to many QA fixes and
> >>>>> further
> >>>>> will follow...
> >>>>> 
> >>>>> my opinion now: keep RPATH errors fatal as developer's  whip :-)
> >>>> 
> >>>> I agree about keeping it configurable.
> >>>> 
> >>>> Besides I think that we ought to keep it fatal until quite near of
> >>>> release since we'll be "forced" to fix most of many of them.
> >>> 
> >>> I just want to state, again, that most of these just go away with
> >>> libtool 2.4.  Now, if people are looking for something to work on that
> >>> won't just go
> >>> away with an update to libtool 2.4:
> >>> - iscsi-target needs some love again for various kernel versions as
> >>> that looks to be killing calamari and neek for nas-server-image
> >> 
> >> Peeked at iscsi-target for calamari. Some inet fields have changed
> >> name in 2.6.32 or so, and apparently this is not handled fully.
> >> Instead of trying to fix it, I moved the calamari recipe to 2.6.34
> >> (which I'm already using for half a year or so, but apparently never
> >> pushed).
> > 
> > Thanks.
> > 
> >> I'll also see if I can update the neek version (probably also by
> >> moving the kernel version forward.
> >> Tomorrow I'll discuss this with Walter who afaik is the only other neek
> >> user.
> > 
> > Note that I also see:
> > - uclibc total failure, but I assume unsupported and I'll drop
> > - minimal fails everywhere else with:
> > ERROR: QA Issue with staging: libsupc++.la failed sanity test (workdir)
> > in path
> > /var/hudson/workspace/sb_openembedded_autobuilder/BBPKGS/native-sdk-image
> > /DISTRO/minimal/MACHINE/neek/label/sb-u1004/tmp/sysroots/nios2-linux/usr/
> > lib ERROR: QA Issue with staging: libstdc++.la failed sanity test
> > (workdir) in path
> > /var/hudson/workspace/sb_openembedded_autobuilder/BBPKGS/native-sdk-image
> > /DISTRO/minimal/MACHINE/neek/label/sb-u1004/tmp/sysroots/nios2-linux/usr/
> > lib ERROR: QA staging was broken by the package built above
> 
> Peeked some more itnto this.
> 
> If I peek in ./nios2-linux/usr/lib/libsupc++.la I see:
> 
> # libsupc++.la - a libtool library file
> # Generated by ltmain.sh - GNU libtool 1.4a-GCC3.0 (1.641.2.256
> 2001/05/28 20:09:07 with GCC-local changes)
> #
> # Please DO NOT delete this file!
> # It is necessary for linking the library.
> 
> # The name that we can dlopen(3).
> dlname=''
> 
> # Names of this library.
> library_names=''
> 
> # The name of the static archive.
> old_library='libsupc++.a'
> 
> # Libraries that this one depends upon.
> dependency_libs='
> -L/home/frans/oe/tmp_minimal/work/nios2-linux/gcc-cross-4.1.2-r27.2/gcc-4.1
> .2/build.i686-linux.nios2-linux/nios2-linux/libstdc++-v3/src
> -L/home/frans/oe/tmp_minimal/work/nios2-linux/gcc-cross-4.1.2-r27.2/gcc-4.
> 1.2/build.i686-linux.nios2-linux/nios2-linux/libstdc++-v3/src/.libs -lm
> -L/home/frans/oe/tmp_minimal/work/nios2-linux/gcc-cross-4.1.2-r27.2/gcc-4.
> 1.2/build.i686-linux.nios2-linux/./gcc
> -L/home/frans/oe/tmp_minimal/sysroots/i686-linux/usr/nios2/nios2-linux/bin
> -L/home/frans/oe/tmp_minimal/sysroots/i686-linux/usr/nios2/nios2-linux/lib
> -L/home/frans/oe/tmp_minimal/sysroots/i686-linux/usr/nios2/lib/gcc/nios2-l
> inux/4.1.2
> -L/home/frans/oe/tmp_minimal/sysroots/i686-linux/usr/nios2/lib/gcc/nios2-l
> inux/4.1.2/../../../../nios2-linux/lib
> -L/home/frans/oe/tmp_minimal/sysroots/nios2-linux/lib
> -L/home/frans/oe/tmp_minimal/sysroots/nios2-linux/usr/lib -lgcc_s -lc
> -lgcc_s
> 
> ...
> 
> For other platforms I see
> # libsupc++.la - a libtool library file
> # Generated by libtool (GNU libtool 1.3134 2009-11-29) 2.2.7a
> #
> # Please DO NOT delete this file!
> # It is necessary for linking the library.
> 
> # The name that we can dlopen(3).
> dlname=''
> 
> # Names of this library.
> library_names=''
> 
> # The name of the static archive.
> old_library='libsupc++.a'
> 
> # Linker flags that can not go in dependency_libs.
> inherited_linker_flags=''
> 
> # Libraries that this one depends upon.
> dependency_libs=''
> ...
> 
> Note the different versions of libtool and the different dependency libs
> I guess the libsupc++ comes from gcc and nios2 has a very old gcc
> (4.1.2), but there is no newer version (nios2 support is not
> mainlined).
> Anyone a suggestion?
> 
> Frans.
In my case the QA RPATH error was caused by the value found in 

libdir=..

But here situation seems a bit different. How about manually setting to correct 

libdir=/usr/lib

and continue build?

Andreas

Re: [PATCH] insane.bbclass: Make RPATH a non-fatal error

[Holger Freyther]

On 02/18/2011 08:26 PM, Tom Rini wrote:
> In order to make the user experience better we now use bb.warn
> on non-fatal QA errors and bb.error on fatal errors.


hmm. for every binary with a bad RPATH in your distribution your product can
get bad press very fast. I think the commit message should reflect this in a
way that we are aware of this and don't care.

holger

Re: [PATCH] insane.bbclass: Make RPATH a non-fatal error

[Frans Meulenbroeks]

2011/2/19 Holger Freyther <holger+oe@freyther.de>:
> On 02/18/2011 08:26 PM, Tom Rini wrote:
>> In order to make the user experience better we now use bb.warn
>> on non-fatal QA errors and bb.error on fatal errors.
>
>
> hmm. for every binary with a bad RPATH in your distribution your product can
> get bad press very fast. I think the commit message should reflect this in a
> way that we are aware of this and don't care.
>
> holger
>
That's why I suggested to at least make it user/distro configurable,
so those of us who do care can easily enable it.

Frans

Re: [PATCH] insane.bbclass: Make RPATH a non-fatal error

[Tom Rini]

On 02/19/2011 10:33 AM, Holger Freyther wrote:
> On 02/18/2011 08:26 PM, Tom Rini wrote:
>> In order to make the user experience better we now use bb.warn
>> on non-fatal QA errors and bb.error on fatal errors.
>
>
> hmm. for every binary with a bad RPATH in your distribution your product can
> get bad press very fast. I think the commit message should reflect this in a
> way that we are aware of this and don't care.

Agreed, I will update the RPATH wording when I push this.  Thanks!

-- 
Tom Rini
Mentor Graphics Corporation