[PATCH 0/4] Various Misc tweaks

[PATCH 0/4] Various Misc tweaks

[Richard Purdie]

The following series is for a few things I've noticed needed fixing as
various patches have gone by:

  git://git.openembedded.org/openembedded-core-contrib rpurdie/misc2
  http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rpurdie/misc2

Richard Purdie (4):
  base.bbclass: Add compatibility package name mapping handler
  gcc: Drop part of the 64bithack patch which is no longer used
  module-init-tools-cross: Drop static binaries patch as a better fix
    has been merged
  base.bbclass: Fix PACKAGE_ARCH typo

 meta/classes/base.bbclass                          |   10 +++++++-
 .../recipes-devtools/gcc/gcc-4.5.1/64bithack.patch |   13 ----------
 meta/recipes-devtools/gcc/gcc-4.6/64bithack.patch  |   13 ----------
 .../files/no-static-binaries.patch                 |   25 --------------------
 .../module-init-tools-cross_3.16.bb                |    2 -
 5 files changed, 9 insertions(+), 54 deletions(-)
 delete mode 100644 meta/recipes-kernel/module-init-tools/files/no-static-binaries.patch

-- 
1.7.4.1

[PATCH 1/4] base.bbclass: Add compatibility package name mapping handler

[Richard Purdie]

This means if PKGARCHCOMPAT_ARMV7A is set, "armv7a-vfp-neon" is renamed
to be "armv7a". Other compatibility mappings can be added as needed.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
 meta/classes/base.bbclass |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index f12b3cb..3ed1bb8 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -133,6 +133,13 @@ def generate_git_config(e):
                 f.write(proxy_command)
                 f.close
 
+def pkgarch_mapping(d):
+    # Compatibility mappings of TUNE_PKGARCH (opt in)
+    if d.getVar("PKGARCHCOMPAT_ARMV7A", True):
+        if d.getVar("TUNE_PKGARCH", True) == "armv7a-vfp-neon":
+            d.setVar("TUNE_PKGARCH", "armv7a")
+
+
 addhandler base_eventhandler
 python base_eventhandler() {
 	from bb import note, error, data
@@ -203,6 +210,7 @@ python base_eventhandler() {
 
         if name == "ConfigParsed":
                 generate_git_config(e)
+                pkgarch_mapping(e.data)
 
 	if not data in e.__dict__:
 		return
-- 
1.7.4.1

Re: [PATCH 1/4] base.bbclass: Add compatibility package name mapping handler

[Mark Hatle]

On 7/27/11 9:29 AM, Richard Purdie wrote:
> This means if PKGARCHCOMPAT_ARMV7A is set, "armv7a-vfp-neon" is renamed
> to be "armv7a". Other compatibility mappings can be added as needed.

There are multiple armv7 cores without neon...  I think there might even be one
or two custom cores w/o VFP.  (Yes I know this violates the core spec from ARM,
but people do that all of the time.)

--Mark

> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> ---
>  meta/classes/base.bbclass |    8 ++++++++
>  1 files changed, 8 insertions(+), 0 deletions(-)
> 
> diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
> index f12b3cb..3ed1bb8 100644
> --- a/meta/classes/base.bbclass
> +++ b/meta/classes/base.bbclass
> @@ -133,6 +133,13 @@ def generate_git_config(e):
>                  f.write(proxy_command)
>                  f.close
>  
> +def pkgarch_mapping(d):
> +    # Compatibility mappings of TUNE_PKGARCH (opt in)
> +    if d.getVar("PKGARCHCOMPAT_ARMV7A", True):
> +        if d.getVar("TUNE_PKGARCH", True) == "armv7a-vfp-neon":
> +            d.setVar("TUNE_PKGARCH", "armv7a")
> +
> +
>  addhandler base_eventhandler
>  python base_eventhandler() {
>  	from bb import note, error, data
> @@ -203,6 +210,7 @@ python base_eventhandler() {
>  
>          if name == "ConfigParsed":
>                  generate_git_config(e)
> +                pkgarch_mapping(e.data)
>  
>  	if not data in e.__dict__:
>  		return

Re: [PATCH 1/4] base.bbclass: Add compatibility package name mapping handler

[Richard Purdie]

On Wed, 2011-07-27 at 09:44 -0500, Mark Hatle wrote:
> On 7/27/11 9:29 AM, Richard Purdie wrote:
> > This means if PKGARCHCOMPAT_ARMV7A is set, "armv7a-vfp-neon" is renamed
> > to be "armv7a". Other compatibility mappings can be added as needed.
> 
> There are multiple armv7 cores without neon...  I think there might even be one
> or two custom cores w/o VFP.  (Yes I know this violates the core spec from ARM,
> but people do that all of the time.)

I know there are but for some distros in OE have established "armv7a"
with a specific meaning. This gives us some way of merging the tune code
yet defer fixing those conflicts which can then happen at a time of
their choosing.

Its assumed anyone enabling the option knows what it means (which
Angstrom does and is where the request came from).

FWIW I have just merged the tune changes and this workaround flag.

Cheers,

Richard

Re: [PATCH 1/4] base.bbclass: Add compatibility package name mapping handler

[Koen Kooi]

Op 27 jul. 2011, om 16:50 heeft Richard Purdie het volgende geschreven:

> On Wed, 2011-07-27 at 09:44 -0500, Mark Hatle wrote:
>> On 7/27/11 9:29 AM, Richard Purdie wrote:
>>> This means if PKGARCHCOMPAT_ARMV7A is set, "armv7a-vfp-neon" is renamed
>>> to be "armv7a". Other compatibility mappings can be added as needed.
>> 
>> There are multiple armv7 cores without neon...  I think there might even be one
>> or two custom cores w/o VFP.  (Yes I know this violates the core spec from ARM,
>> but people do that all of the time.)
> 
> I know there are but for some distros in OE have established "armv7a"
> with a specific meaning. This gives us some way of merging the tune code
> yet defer fixing those conflicts which can then happen at a time of
> their choosing.
> 
> Its assumed anyone enabling the option knows what it means (which
> Angstrom does and is where the request came from).
> 
> FWIW I have just merged the tune changes and this workaround flag.

I think we might need a armv5e -> armv5te one and a slightly more tricky armv4 -> armv4t.

The armv4t without thumb case is interesting since we do want to use the EABI bx,lr but not other thumb instructions. My main reason for avoiding t1 is that the toolchain is perpetually broken for it. If gcc fixes a bug binutils will introduce a new one. 

regards,

Koen

Re: [PATCH 1/4] base.bbclass: Add compatibility package name mapping handler

[Phil Blundell]

On Wed, 2011-07-27 at 09:44 -0500, Mark Hatle wrote:
> On 7/27/11 9:29 AM, Richard Purdie wrote:
> > This means if PKGARCHCOMPAT_ARMV7A is set, "armv7a-vfp-neon" is renamed
> > to be "armv7a". Other compatibility mappings can be added as needed.
> 
> There are multiple armv7 cores without neon...  I think there might even be one
> or two custom cores w/o VFP.  (Yes I know this violates the core spec from ARM,
> but people do that all of the time.)

Which spec are you thinking of?  As far as I know, VFP has always been
optional for both ARM11 and Cortex.

p.

Re: [PATCH 1/4] base.bbclass: Add compatibility package name mapping handler

[Mark Hatle]

On 7/27/11 10:02 AM, Phil Blundell wrote:
> On Wed, 2011-07-27 at 09:44 -0500, Mark Hatle wrote:
>> On 7/27/11 9:29 AM, Richard Purdie wrote:
>>> This means if PKGARCHCOMPAT_ARMV7A is set, "armv7a-vfp-neon" is renamed
>>> to be "armv7a". Other compatibility mappings can be added as needed.
>>
>> There are multiple armv7 cores without neon...  I think there might even be one
>> or two custom cores w/o VFP.  (Yes I know this violates the core spec from ARM,
>> but people do that all of the time.)
> 
> Which spec are you thinking of?  As far as I know, VFP has always been
> optional for both ARM11 and Cortex.

I thought VFP was part of the instruction set as of ARMv7.  Neon is recommended
but options.  As I mentioned though, I know of chips in design that don't have
Neon, and I suspect also don't have VFP -- but they're ARMv7.. (they also have
stripped out the thumb2 part as well..)

--Mark

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

Re: [PATCH 1/4] base.bbclass: Add compatibility package name mapping handler

[Koen Kooi]

Op 27 jul. 2011, om 17:02 heeft Phil Blundell het volgende geschreven:

> On Wed, 2011-07-27 at 09:44 -0500, Mark Hatle wrote:
>> On 7/27/11 9:29 AM, Richard Purdie wrote:
>>> This means if PKGARCHCOMPAT_ARMV7A is set, "armv7a-vfp-neon" is renamed
>>> to be "armv7a". Other compatibility mappings can be added as needed.
>> 
>> There are multiple armv7 cores without neon...  I think there might even be one
>> or two custom cores w/o VFP.  (Yes I know this violates the core spec from ARM,
>> but people do that all of the time.)
> 
> Which spec are you thinking of?  As far as I know, VFP has always been
> optional for both ARM11 and Cortex.

From the conversations I had with ARM they implied that it isn't optional for cortex a8/9/15, only neon is (e.g. marvell dove, nvidia tegra2). I haven't seen any black on white contracts saying that, though :)

regards,

Koen

Re: [PATCH 1/4] base.bbclass: Add compatibility package name mapping handler

[Phil Blundell]

On Wed, 2011-07-27 at 17:06 +0200, Koen Kooi wrote:
> From the conversations I had with ARM they implied that it isn't optional for cortex a8/9/15, only neon is (e.g. marvell dove, nvidia tegra2). I haven't seen any black on white contracts saying that, though :)

The spec on the web seems to say fairly clearly that it's optional, at
least in theory.  I guess they might have commercial reasons for not
wanting to sell it without VFP in any given situation.

See:

http://www.arm.com/products/processors/cortex-a/cortex-a5.php?tab=Specifications

for example

p.

Re: [PATCH 1/4] base.bbclass: Add compatibility package name mapping handler

[Khem Raj]

On Wednesday, July 27, 2011 04:13:47 PM Phil Blundell wrote:
> On Wed, 2011-07-27 at 17:06 +0200, Koen Kooi wrote:
> > From the conversations I had with ARM they implied that it isn't
> > optional for cortex a8/9/15, only neon is (e.g. marvell dove, nvidia
> > tegra2). I haven't seen any black on white contracts saying that,
> > though :)
> The spec on the web seems to say fairly clearly that it's optional, at
> least in theory.  I guess they might have commercial reasons for not
> wanting to sell it without VFP in any given situation.
> 
> See:
> 
> http://www.arm.com/products/processors/cortex-a/cortex-a5.php?tab=Specificat
> ions
> 
> for example

thats only for for a5. For procesors koen mentioned VFP is mandatory
> 
> p.
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
-- 
Khem Raj

Re: [PATCH 1/4] base.bbclass: Add compatibility package name mapping handler

[Phil Blundell]

On Sat, 2011-07-30 at 11:43 -0700, Khem Raj wrote:
> On Wednesday, July 27, 2011 04:13:47 PM Phil Blundell wrote:
> > On Wed, 2011-07-27 at 17:06 +0200, Koen Kooi wrote:
> > > From the conversations I had with ARM they implied that it isn't
> > > optional for cortex a8/9/15, only neon is (e.g. marvell dove, nvidia
> > > tegra2). I haven't seen any black on white contracts saying that,
> > > though :)
> > The spec on the web seems to say fairly clearly that it's optional, at
> > least in theory.  I guess they might have commercial reasons for not
> > wanting to sell it without VFP in any given situation.
> > 
> > See:
> > 
> > http://www.arm.com/products/processors/cortex-a/cortex-a5.php?tab=Specificat
> > ions
> > 
> > for example
> 
> thats only for for a5. For procesors koen mentioned VFP is mandatory

Oh yeah, you're right.  Sorry, I didn't read his email carefully enough.

The original question, though, was whether VFP is mandatory for the
ARMv7-A architecture.  Irrespective of what the situation is with
A8/A9/A15, Cortex-A5 is still an ARMv7-A processor and hence VFP can't
be mandatory for the architecture as a whole.

p.

[PATCH 2/4] gcc: Drop part of the 64bithack patch which is no longer used

[Richard Purdie]

Since we now handle GLIBC_DYNAMIC_LINKER in gcc-configure-common.inc:

's#\(GLIBC_DYNAMIC_LINKER[^ ]*\)\( *"/lib.*\)#\1 SYSTEMLIBS_DIR\2#'

we can drop the patch which changes a hardcoded value for this.

No PR bump since there is no code change resulting from this, its just
a cleanup.

There is still a valid question over the remainder of this patch and its
interaction with multilib configurations.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
 .../recipes-devtools/gcc/gcc-4.5.1/64bithack.patch |   13 -------------
 meta/recipes-devtools/gcc/gcc-4.6/64bithack.patch  |   13 -------------
 2 files changed, 0 insertions(+), 26 deletions(-)

diff --git a/meta/recipes-devtools/gcc/gcc-4.5.1/64bithack.patch b/meta/recipes-devtools/gcc/gcc-4.5.1/64bithack.patch
index 890cc2f..05eafe3 100644
--- a/meta/recipes-devtools/gcc/gcc-4.5.1/64bithack.patch
+++ b/meta/recipes-devtools/gcc/gcc-4.5.1/64bithack.patch
@@ -20,16 +20,3 @@ Index: gcc-4.5.0/gcc/config/i386/t-linux64
  
  LIBGCC = stmp-multilib
  INSTALL_LIBGCC = install-multilib
-Index: gcc-4.5.0/gcc/config/i386/linux64.h
-===================================================================
---- gcc-4.5.0.orig/gcc/config/i386/linux64.h	2010-08-10 15:49:06.000000000 +0100
-+++ gcc-4.5.0/gcc/config/i386/linux64.h	2010-08-10 15:49:16.000000000 +0100
-@@ -59,7 +59,7 @@
-    done.  */
- 
- #define GLIBC_DYNAMIC_LINKER32 "/lib/ld-linux.so.2"
--#define GLIBC_DYNAMIC_LINKER64 "/lib64/ld-linux-x86-64.so.2"
-+#define GLIBC_DYNAMIC_LINKER64 "/lib/ld-linux-x86-64.so.2"
- 
- #if TARGET_64BIT_DEFAULT
- #define SPEC_32 "m32"
diff --git a/meta/recipes-devtools/gcc/gcc-4.6/64bithack.patch b/meta/recipes-devtools/gcc/gcc-4.6/64bithack.patch
index 84962e6..4b846bb 100644
--- a/meta/recipes-devtools/gcc/gcc-4.6/64bithack.patch
+++ b/meta/recipes-devtools/gcc/gcc-4.6/64bithack.patch
@@ -20,16 +20,3 @@ Index: gcc-4.6.0/gcc/config/i386/t-linux64
  
  LIBGCC = stmp-multilib
  INSTALL_LIBGCC = install-multilib
-Index: gcc-4.6.0/gcc/config/i386/linux64.h
-===================================================================
---- gcc-4.6.0.orig/gcc/config/i386/linux64.h
-+++ gcc-4.6.0/gcc/config/i386/linux64.h
-@@ -63,7 +63,7 @@ see the files COPYING3 and COPYING.RUNTI
-    done.  */
- 
- #define GLIBC_DYNAMIC_LINKER32 "/lib/ld-linux.so.2"
--#define GLIBC_DYNAMIC_LINKER64 "/lib64/ld-linux-x86-64.so.2"
-+#define GLIBC_DYNAMIC_LINKER64 "/lib/ld-linux-x86-64.so.2"
- 
- #if TARGET_64BIT_DEFAULT
- #define SPEC_32 "m32"
-- 
1.7.4.1

Re: [PATCH 2/4] gcc: Drop part of the 64bithack patch which is no longer used

[Lu, Lianhao]

Richard Purdie wrote on 2011-07-27:
> Since we now handle GLIBC_DYNAMIC_LINKER in gcc-configure-common.inc:
> 
> 's#\(GLIBC_DYNAMIC_LINKER[^ ]*\)\( *"/lib.*\)#\1 SYSTEMLIBS_DIR\2#'
> 

It seems to me that this patch may not be removed. The above code in gcc-configure-common.inc said it only useful for SDK. For gcc-cross, it doesn't change /lib64/ld-linux-x86-64.so.2 to /lib/ld-linux-x86-64.so.2 as what the 64bithack.patch does.

-Lianhao

> we can drop the patch which changes a hardcoded value for this.
> 
> No PR bump since there is no code change resulting from this, its just
> a cleanup.
> 
> There is still a valid question over the remainder of this patch and
> its interaction with multilib configurations.
> 
> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> ---
>  .../recipes-devtools/gcc/gcc-4.5.1/64bithack.patch |   13 -------------
>  meta/recipes-devtools/gcc/gcc-4.6/64bithack.patch  |   13 -------------
>  2 files changed, 0 insertions(+), 26 deletions(-)

Re: [PATCH 2/4] gcc: Drop part of the 64bithack patch which is no longer used

[Kumar Gala]

On Jul 28, 2011, at 9:35 AM, Lu, Lianhao wrote:

> Richard Purdie wrote on 2011-07-27:
>> Since we now handle GLIBC_DYNAMIC_LINKER in gcc-configure-common.inc:
>> 
>> 's#\(GLIBC_DYNAMIC_LINKER[^ ]*\)\( *"/lib.*\)#\1 SYSTEMLIBS_DIR\2#'
>> 
> 
> It seems to me that this patch may not be removed. The above code in gcc-configure-common.inc said it only useful for SDK. For gcc-cross, it doesn't change /lib64/ld-linux-x86-64.so.2 to /lib/ld-linux-x86-64.so.2 as what the 64bithack.patch does.
> 
> -Lianhao

Agreed, seeing similar issues on ppc64.  I think the sed line might not be doing with Richard intended.

We get:

./i386/linux.h:#define GLIBC_DYNAMIC_LINKER SYSTEMLIBS_DIR "/lib/ld-linux.so.2"
./i386/linux64.h:#define GLIBC_DYNAMIC_LINKER32 SYSTEMLIBS_DIR "/lib/ld-linux.so.2"
./i386/linux64.h:#define GLIBC_DYNAMIC_LINKER64 SYSTEMLIBS_DIR "/lib64/ld-linux-x86-64.so.2"

- k


> 
>> we can drop the patch which changes a hardcoded value for this.
>> 
>> No PR bump since there is no code change resulting from this, its just
>> a cleanup.
>> 
>> There is still a valid question over the remainder of this patch and
>> its interaction with multilib configurations.
>> 
>> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
>> ---
>> .../recipes-devtools/gcc/gcc-4.5.1/64bithack.patch |   13 -------------
>> meta/recipes-devtools/gcc/gcc-4.6/64bithack.patch  |   13 -------------
>> 2 files changed, 0 insertions(+), 26 deletions(-)
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH 2/4] gcc: Drop part of the 64bithack patch which is no longer used

[Khem Raj]

On (27/07/11 15:29), Richard Purdie wrote:
> Since we now handle GLIBC_DYNAMIC_LINKER in gcc-configure-common.inc:
> 
> 's#\(GLIBC_DYNAMIC_LINKER[^ ]*\)\( *"/lib.*\)#\1 SYSTEMLIBS_DIR\2#'
> 
> we can drop the patch which changes a hardcoded value for this.
> 
> No PR bump since there is no code change resulting from this, its just
> a cleanup.
> 
> There is still a valid question over the remainder of this patch and its
> interaction with multilib configurations.
> 
> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> ---
>  .../recipes-devtools/gcc/gcc-4.5.1/64bithack.patch |   13 -------------
>  meta/recipes-devtools/gcc/gcc-4.6/64bithack.patch  |   13 -------------
>  2 files changed, 0 insertions(+), 26 deletions(-)
> 
> diff --git a/meta/recipes-devtools/gcc/gcc-4.5.1/64bithack.patch b/meta/recipes-devtools/gcc/gcc-4.5.1/64bithack.patch
> index 890cc2f..05eafe3 100644
> --- a/meta/recipes-devtools/gcc/gcc-4.5.1/64bithack.patch
> +++ b/meta/recipes-devtools/gcc/gcc-4.5.1/64bithack.patch
> @@ -20,16 +20,3 @@ Index: gcc-4.5.0/gcc/config/i386/t-linux64
>   
>   LIBGCC = stmp-multilib
>   INSTALL_LIBGCC = install-multilib
> -Index: gcc-4.5.0/gcc/config/i386/linux64.h
> -===================================================================
> ---- gcc-4.5.0.orig/gcc/config/i386/linux64.h	2010-08-10 15:49:06.000000000 +0100
> -+++ gcc-4.5.0/gcc/config/i386/linux64.h	2010-08-10 15:49:16.000000000 +0100
> -@@ -59,7 +59,7 @@
> -    done.  */
> - 
> - #define GLIBC_DYNAMIC_LINKER32 "/lib/ld-linux.so.2"
> --#define GLIBC_DYNAMIC_LINKER64 "/lib64/ld-linux-x86-64.so.2"
> -+#define GLIBC_DYNAMIC_LINKER64 "/lib/ld-linux-x86-64.so.2"

This change while I like it that we are moving to use default will now
emit /lib64/ld-linux-x86-64.so.2 into INTERP section but I dont see
a corresponding patch to fix root file systems where the defualt libdir
for x86-64 is changed to be lib64

So this will end up in userspace not booting at all since init wont
find the dynamic linker to start with.

Thanks

-Khem

[PATCH 3/4] module-init-tools-cross: Drop static binaries patch as a better fix has been merged

[Richard Purdie]

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
 .../files/no-static-binaries.patch                 |   25 --------------------
 .../module-init-tools-cross_3.16.bb                |    2 -
 2 files changed, 0 insertions(+), 27 deletions(-)
 delete mode 100644 meta/recipes-kernel/module-init-tools/files/no-static-binaries.patch

diff --git a/meta/recipes-kernel/module-init-tools/files/no-static-binaries.patch b/meta/recipes-kernel/module-init-tools/files/no-static-binaries.patch
deleted file mode 100644
index 33fb6e0..0000000
--- a/meta/recipes-kernel/module-init-tools/files/no-static-binaries.patch
+++ /dev/null
@@ -1,25 +0,0 @@
-# Building a native, statically-linked insmod can result in ld failing because
-# it can't find a static libc.  A native, static insmod is unnecessary anyway,
-# so this patch just removes it.
-#
-# - jdike@linux.intel.com
-#
-# Change to a simpler method by just disabling static link flag, since even
-# removing those lines don't prevent insmod.static from compile
-#
-# by Kevin Tian <kevin.tian@intel.com>, 2010-07-21
-
-Upstream-Status: Pending
-
-Index: module-init-tools-3.2.2/Makefile.am
-===================================================================
---- module-init-tools-3.2.2.orig/Makefile.am	2010-05-26 15:43:16.000000000 -0400
-+++ module-init-tools-3.2.2/Makefile.am	2010-05-26 16:04:06.232990785 -0400
-@@ -10,7 +10,6 @@
- modindex_SOURCES = modindex.c zlibsupport.c zlibsupport.h testing.h
- 
- insmod_static_SOURCES = insmod.c
--insmod_static_LDFLAGS = -static
- # We don't want the $(zlib_flags) here: that makes a dynamic executable
- insmod_static_LDADD = libmodtools.a
- 
diff --git a/meta/recipes-kernel/module-init-tools/module-init-tools-cross_3.16.bb b/meta/recipes-kernel/module-init-tools/module-init-tools-cross_3.16.bb
index 38f0476..a6c5d21 100644
--- a/meta/recipes-kernel/module-init-tools/module-init-tools-cross_3.16.bb
+++ b/meta/recipes-kernel/module-init-tools/module-init-tools-cross_3.16.bb
@@ -3,8 +3,6 @@ PR = "r0"
 inherit cross
 PROVIDES += "virtual/${TARGET_PREFIX}depmod"
 
-SRC_URI += "file://no-static-binaries.patch"
-
 SRC_URI[md5sum] = "bc44832c6e41707b8447e2847d2019f5"
 SRC_URI[sha256sum] = "e1f2cdcae64a8effc25e545a5e0bdaf312f816ebbcd0916e4e87450755fab64b"
 
-- 
1.7.4.1

[PATCH 4/4] base.bbclass: Fix PACKAGE_ARCH typo

[Richard Purdie]

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
 meta/classes/base.bbclass |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 3ed1bb8..a0a189f 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -407,7 +407,7 @@ python () {
         # if multiple differences are present?
         # Look through PACKAGE_ARCHS for the priority order?
         if pkgarch and pkgarch == mach_arch:
-            bb.data.setVar('PACAKGE_ARCH', "${MACHINE_ARCH}", d)
+            bb.data.setVar('PACKAGE_ARCH', "${MACHINE_ARCH}", d)
             bb.warn("Recipe %s is marked as only being architecture specific but seems to have machine specific packages?! The recipe may as well mark itself as machine specific directly." % d.getVar("PN", True))
 }
 
-- 
1.7.4.1

Re: [PATCH 4/4] base.bbclass: Fix PACKAGE_ARCH typo

[Khem Raj]

On Wednesday, July 27, 2011 03:29:15 PM Richard Purdie wrote:
> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> ---
>  meta/classes/base.bbclass |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
> index 3ed1bb8..a0a189f 100644
> --- a/meta/classes/base.bbclass
> +++ b/meta/classes/base.bbclass
> @@ -407,7 +407,7 @@ python () {
>          # if multiple differences are present?
>          # Look through PACKAGE_ARCHS for the priority order?
>          if pkgarch and pkgarch == mach_arch:
> -            bb.data.setVar('PACAKGE_ARCH', "${MACHINE_ARCH}", d)
> +            bb.data.setVar('PACKAGE_ARCH', "${MACHINE_ARCH}", d)

nice I was wondering this warning in my builds

>              bb.warn("Recipe %s is marked as only being architecture
> specific but seems to have machine specific packages?! The recipe may as
> well mark itself as machine specific directly." % d.getVar("PN", True)) }
-- 
Khem Raj