Re: [oe] [meta-handheld][PATCH 2/3] udev: add bbappend and disable device cache as default.

2011-11-03 Thread Koen Kooi 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Op 02-11-11 22:00, Paul Eggleton schreef:
 On Monday 17 October 2011 01:26:50 Andrea Adami wrote:
 * For some reasons when the cache is created root can still be ro *
 and as solution you would be obliged to add 'rw' to your commandline.
 * There are patches in openembedded-classic to correct this * (and
 those are still pending for meta-oe). * Until a solution is found
 disable the creation of the device cache on boot.
 
 Signed-off-by: Andrea Adami andrea.ad...@gmail.com --- 
 recipes-core/udev/udev/default  |4  
 recipes-core/udev/udev_173.bbappend |1 + 2 files changed, 5 
 insertions(+), 0 deletions(-) create mode 100644 
 recipes-core/udev/udev/default create mode 100644 
 recipes-core/udev/udev_173.bbappend
 
 diff --git a/recipes-core/udev/udev/default 
 b/recipes-core/udev/udev/default new file mode 100644 index 
 000..ba2867e --- /dev/null +++ b/recipes-core/udev/udev/default @@ 
 -0,0 +1,4 @@ +# Default for /etc/init.d/udev + +# Uncomment this out
 to enable device cache +#DEVCACHE=/etc/dev.tar diff --git 
 a/recipes-core/udev/udev_173.bbappend 
 b/recipes-core/udev/udev_173.bbappend new file mode 100644 index 
 000..72d991c --- /dev/null +++ 
 b/recipes-core/udev/udev_173.bbappend @@ -0,0 +1 @@ 
 +FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
 
 I think this is going to cause problems for distros such as Angstrom
 that enable this layer without always using it. Can we just disable the
 dev cache for the machines in meta-handheld?

Or get with the program and use udev 174 with systemd, no need for a device
cache in that case!

regards,

Koen
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
Comment: GPGTools - http://gpgtools.org

iD8DBQFOslKBMkyGM64RGpERApRuAKCrFvkx2Ndu72tpP0DZSRXARyj1kgCgjPKR
uITbHbzYgtHKi/k2aEpRS+4=
=D6Yf
-END PGP SIGNATURE-


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

Re: [oe] [meta-handheld][PATCH 1/3] formfactor: initial commit of collie, poodle and tosa machconfig

2011-11-03 Thread Koen Kooi 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Op 02-11-11 22:02, Paul Eggleton schreef:
 On Monday 17 October 2011 01:26:49 Andrea Adami wrote:
 Signed-off-by: Andrea Adami andrea.ad...@gmail.com ...
 
 I've merged this series apart from 2/3 which we still need to discuss.

Can you please update patchwork as well?

regards,

Koen
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
Comment: GPGTools - http://gpgtools.org

iD8DBQFOslYVMkyGM64RGpERAq6HAJ9CyQw6938h72qMUs/pS2tCav4/6gCgjkTP
PBZSA6q8+J7Tf/ZeeF19INI=
=0BZJ
-END PGP SIGNATURE-


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

Re: [oe] [meta-handheld][PATCH 2/3] udev: add bbappend and disable device cache as default.

2011-11-03 Thread Andrea Adami 
On Thu, Nov 3, 2011 at 9:36 AM, Koen Kooi k...@dominion.thruhere.netwrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Op 02-11-11 22:00, Paul Eggleton schreef:
  On Monday 17 October 2011 01:26:50 Andrea Adami wrote:
  * For some reasons when the cache is created root can still be ro *
  and as solution you would be obliged to add 'rw' to your commandline.
  * There are patches in openembedded-classic to correct this * (and
  those are still pending for meta-oe). * Until a solution is found
  disable the creation of the device cache on boot.
 
  Signed-off-by: Andrea Adami andrea.ad...@gmail.com ---
  recipes-core/udev/udev/default  |4 
  recipes-core/udev/udev_173.bbappend |1 + 2 files changed, 5
  insertions(+), 0 deletions(-) create mode 100644
  recipes-core/udev/udev/default create mode 100644
  recipes-core/udev/udev_173.bbappend
 
  diff --git a/recipes-core/udev/udev/default
  b/recipes-core/udev/udev/default new file mode 100644 index
  000..ba2867e --- /dev/null +++ b/recipes-core/udev/udev/default @@
  -0,0 +1,4 @@ +# Default for /etc/init.d/udev + +# Uncomment this out
  to enable device cache +#DEVCACHE=/etc/dev.tar diff --git
  a/recipes-core/udev/udev_173.bbappend
  b/recipes-core/udev/udev_173.bbappend new file mode 100644 index
  000..72d991c --- /dev/null +++
  b/recipes-core/udev/udev_173.bbappend @@ -0,0 +1 @@
  +FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
 
  I think this is going to cause problems for distros such as Angstrom
  that enable this layer without always using it. Can we just disable the
  dev cache for the machines in meta-handheld?

 Or get with the program and use udev 174 with systemd, no need for a device
 cache in that case!

 regards,

 Koen


Sure, this is the future...but for now oe-core doesn't implement systemd as
default.

Until then, I think we should have sane defaults allowing to build with
just oe-core + meta-oe + meta-handheld even without distro layers.

Regards

Andrea


 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.5 (Darwin)
 Comment: GPGTools - http://gpgtools.org

 iD8DBQFOslKBMkyGM64RGpERApRuAKCrFvkx2Ndu72tpP0DZSRXARyj1kgCgjPKR
 uITbHbzYgtHKi/k2aEpRS+4=
 =D6Yf
 -END PGP SIGNATURE-


 ___
 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

Re: [oe] [meta-handheld][PATCH 2/3] udev: add bbappend and disable device cache as default.

2011-11-03 Thread Andrea Adami 
On Thu, Nov 3, 2011 at 10:09 AM, Andrea Adami andrea.ad...@gmail.comwrote:

 On Thu, Nov 3, 2011 at 9:36 AM, Koen Kooi k...@dominion.thruhere.netwrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Op 02-11-11 22:00, Paul Eggleton schreef:
  On Monday 17 October 2011 01:26:50 Andrea Adami wrote:
  * For some reasons when the cache is created root can still be ro *
  and as solution you would be obliged to add 'rw' to your commandline.
  * There are patches in openembedded-classic to correct this * (and
  those are still pending for meta-oe). * Until a solution is found
  disable the creation of the device cache on boot.
 
  Signed-off-by: Andrea Adami andrea.ad...@gmail.com ---
  recipes-core/udev/udev/default  |4 
  recipes-core/udev/udev_173.bbappend |1 + 2 files changed, 5
  insertions(+), 0 deletions(-) create mode 100644
  recipes-core/udev/udev/default create mode 100644
  recipes-core/udev/udev_173.bbappend
 
  diff --git a/recipes-core/udev/udev/default
  b/recipes-core/udev/udev/default new file mode 100644 index
  000..ba2867e --- /dev/null +++ b/recipes-core/udev/udev/default @@
  -0,0 +1,4 @@ +# Default for /etc/init.d/udev + +# Uncomment this out
  to enable device cache +#DEVCACHE=/etc/dev.tar diff --git
  a/recipes-core/udev/udev_173.bbappend
  b/recipes-core/udev/udev_173.bbappend new file mode 100644 index
  000..72d991c --- /dev/null +++
  b/recipes-core/udev/udev_173.bbappend @@ -0,0 +1 @@
  +FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
 
  I think this is going to cause problems for distros such as Angstrom
  that enable this layer without always using it. Can we just disable the
  dev cache for the machines in meta-handheld?

 Or get with the program and use udev 174 with systemd, no need for a
 device
 cache in that case!

 regards,

 Koen


 Sure, this is the future...but for now oe-core doesn't implement systemd
 as default.

 Until then, I think we should have sane defaults allowing to build with
 just oe-core + meta-oe + meta-handheld even without distro layers.

 Regards

 Andrea



Oh, I forgot to say that's unfortunate oe-core is still on udev_164.
Probably they have been scared by the note # udev 169 and up require
kernel 2.6.36 for ARM:

Is this still a problem? Maybe we should insist on the oe-core list and try
to unify the recipes.

Regards

Andrea
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

[oe] [oe-core[ de034bf830bec1b64260ac8516dd584163716ef4 breaks iproute2

2011-11-03 Thread Sergey Lapin 
Hi, all!
iptables upgrade broke iproute2. Do anybody work on this?

NOTE: package iproute2-2.6.38-r0: task do_compile: Started
ERROR: Function 'do_compile' failed (see
/home/build1/OE/slave/angstrom_build/build/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/iproute2-2.6.38-r0/temp/log.do_compile.22734
for further information)
ERROR: Logfile of failure stored in:
/home/build1/OE/slave/angstrom_build/build/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/iproute2-2.6.38-r0/temp/log.do_compile.22734
Log data follows:
| + cd 
/home/build1/OE/slave/angstrom_build/build/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/iproute2-2.6.38-r0/iproute2-2.6.38
| + do_compile
| + base_do_compile
| + '[' -e Makefile -o -e makefile ']'
| + oe_runmake
| + '[' xmake = x ']'
| + bbnote make 'CC=ccache arm-angstrom-linux-gnueabi-gcc
-march=armv5te  -mno-thumb -mthumb-interwork  -mtune=arm926ej-s
-mthumb-interwork -mno-thumb
--sysroot=/home/build1/OE/slave/angstrom_build/build/build/tmp-angstrom_2010_x-eglibc/sysroots/crux'
KERNEL_INCLUDE=/home/build1/OE/slave/angstrom_build/build/build/tmp-angstrom_2010_x-eglibc/sysroots/crux/kernel/include
DOCDIR=/usr/share/doc/iproute2 'SUBDIRS=lib tc ip' SBINDIR=/sbin
| + echo 'NOTE: make CC=ccache arm-angstrom-linux-gnueabi-gcc
-march=armv5te  -mno-thumb -mthumb-interwork  -mtune=arm926ej-s
-mthumb-interwork -mno-thumb
--sysroot=/home/build1/OE/slave/angstrom_build/build/build/tmp-angstrom_2010_x-eglibc/sysroots/crux
KERNEL_INCLUDE=/home/build1/OE/slave/angstrom_build/build/build/tmp-angstrom_2010_x-eglibc/sysroots/crux/kernel/include
DOCDIR=/usr/share/doc/iproute2 SUBDIRS=lib tc ip SBINDIR=/sbin'
| NOTE: make CC=ccache arm-angstrom-linux-gnueabi-gcc  -march=armv5te
-mno-thumb -mthumb-interwork  -mtune=arm926ej-s -mthumb-interwork
-mno-thumb 
--sysroot=/home/build1/OE/slave/angstrom_build/build/build/tmp-angstrom_2010_x-eglibc/sysroots/crux
KERNEL_INCLUDE=/home/build1/OE/slave/angstrom_build/build/build/tmp-angstrom_2010_x-eglibc/sysroots/crux/kernel/include
DOCDIR=/usr/share/doc/iproute2 SUBDIRS=lib tc ip SBINDIR=/sbin
| + make 'CC=ccache arm-angstrom-linux-gnueabi-gcc  -march=armv5te
-mno-thumb -mthumb-interwork  -mtune=arm926ej-s -mthumb-interwork
-mno-thumb 
--sysroot=/home/build1/OE/slave/angstrom_build/build/build/tmp-angstrom_2010_x-eglibc/sysroots/crux'
KERNEL_INCLUDE=/home/build1/OE/slave/angstrom_build/build/build/tmp-angstrom_2010_x-eglibc/sysroots/crux/kernel/include
DOCDIR=/usr/share/doc/iproute2 'SUBDIRS=lib tc ip' SBINDIR=/sbin
| make[1]: Entering directory
`/home/build1/OE/slave/angstrom_build/build/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/iproute2-2.6.38-r0/iproute2-2.6.38/lib'
| make[1]: Nothing to be done for `all'.
| make[1]: Leaving directory
`/home/build1/OE/slave/angstrom_build/build/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/iproute2-2.6.38-r0/iproute2-2.6.38/lib'
| make[1]: Entering directory
`/home/build1/OE/slave/angstrom_build/build/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/iproute2-2.6.38-r0/iproute2-2.6.38/tc'
| ccache arm-angstrom-linux-gnueabi-gcc  -march=armv5te  -mno-thumb
-mthumb-interwork  -mtune=arm926ej-s -mthumb-interwork -mno-thumb
--sysroot=/home/build1/OE/slave/angstrom_build/build/build/tmp-angstrom_2010_x-eglibc/sysroots/crux
-D_GNU_SOURCE -O2 -Wstrict-prototypes -Wall -I../include
-DRESOLVE_HOSTNAMES -DLIBDIR=\/usr/lib/\ -DCONFIG_GACT
-DCONFIG_GACT_PROB -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed
-Wl,-export-dynamic -shared -fpic -o m_xt.so m_xt.c -lxtables
| m_xt.c: In function 'parse_ipt':
| m_xt.c:167:31: warning: passing argument 2 of
'xtables_merge_options' discards qualifiers from pointer target type
| 
/home/build1/OE/slave/angstrom_build/build/build/tmp-angstrom_2010_x-eglibc/sysroots/crux/usr/include/xtables.h:407:23:
note: expected 'struct option *' but argument is of type 'const struct
option *'
| m_xt.c:167:31: warning: passing argument 3 of
'xtables_merge_options' from incompatible pointer type
| 
/home/build1/OE/slave/angstrom_build/build/build/tmp-angstrom_2010_x-eglibc/sysroots/crux/usr/include/xtables.h:407:23:
note: expected 'const struct option *' but argument is of type
'unsigned int *'
| m_xt.c:167:31: error: too few arguments to function 'xtables_merge_options'
| 
/home/build1/OE/slave/angstrom_build/build/build/tmp-angstrom_2010_x-eglibc/sysroots/crux/usr/include/xtables.h:407:23:
note: declared here
| m_xt.c: In function 'print_ipt':
| m_xt.c:312:30: warning: passing argument 2 of
'xtables_merge_options' discards qualifiers from pointer target type
| /home/build1/OE/slave/angstrom_build/build/buERROR: Function
'do_compile' failed (see
/home/build1/OE/slave/angstrom_build/build/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/iproute2-2.6.38-r0/temp/log.do_compile.22734
for further information)
|

Re: [oe] [meta-handheld][PATCH 2/3] udev: add bbappend and disable device cache as default.

2011-11-03 Thread Koen Kooi 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Op 03-11-11 10:22, Andrea Adami schreef:
 On Thu, Nov 3, 2011 at 10:09 AM, Andrea Adami
 andrea.ad...@gmail.comwrote:
 
 On Thu, Nov 3, 2011 at 9:36 AM, Koen Kooi
 k...@dominion.thruhere.netwrote:
 
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
 
 Op 02-11-11 22:00, Paul Eggleton schreef:
 On Monday 17 October 2011 01:26:50 Andrea Adami wrote:
 * For some reasons when the cache is created root can still be ro
 * and as solution you would be obliged to add 'rw' to your
 commandline. * There are patches in openembedded-classic to
 correct this * (and those are still pending for meta-oe). * Until
 a solution is found disable the creation of the device cache on
 boot.
 
 Signed-off-by: Andrea Adami andrea.ad...@gmail.com --- 
 recipes-core/udev/udev/default  |4  
 recipes-core/udev/udev_173.bbappend |1 + 2 files changed, 5 
 insertions(+), 0 deletions(-) create mode 100644 
 recipes-core/udev/udev/default create mode 100644 
 recipes-core/udev/udev_173.bbappend
 
 diff --git a/recipes-core/udev/udev/default 
 b/recipes-core/udev/udev/default new file mode 100644 index 
 000..ba2867e --- /dev/null +++
 b/recipes-core/udev/udev/default @@ -0,0 +1,4 @@ +# Default for
 /etc/init.d/udev + +# Uncomment this out to enable device cache
 +#DEVCACHE=/etc/dev.tar diff --git 
 a/recipes-core/udev/udev_173.bbappend 
 b/recipes-core/udev/udev_173.bbappend new file mode 100644 index 
 000..72d991c --- /dev/null +++ 
 b/recipes-core/udev/udev_173.bbappend @@ -0,0 +1 @@ 
 +FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
 
 I think this is going to cause problems for distros such as
 Angstrom that enable this layer without always using it. Can we
 just disable the dev cache for the machines in meta-handheld?
 
 Or get with the program and use udev 174 with systemd, no need for a 
 device cache in that case!
 
 regards,
 
 Koen
 
 
 Sure, this is the future...but for now oe-core doesn't implement
 systemd as default.
 
 Until then, I think we should have sane defaults allowing to build
 with just oe-core + meta-oe + meta-handheld even without distro
 layers.
 
 Regards
 
 Andrea
 
 
 
 Oh, I forgot to say that's unfortunate oe-core is still on udev_164. 
 Probably they have been scared by the note # udev 169 and up require 
 kernel 2.6.36 for ARM:
 
 Is this still a problem? Maybe we should insist on the oe-core list and
 try to unify the recipes.

It's not a problem if you backport the patches udev needs :)

E.g.
http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/tree/recipes-kernel/linux/linux-omap4_2.6.35.7.bb



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
Comment: GPGTools - http://gpgtools.org

iD8DBQFOsl3BMkyGM64RGpERAmHPAJkBIlv7noLAr+tqSLyRRWNCRDu8JQCgsgun
62cQ+8B93YcHPBGjcd2J0rk=
=EVzO
-END PGP SIGNATURE-


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

Re: [oe] [meta-handheld][PATCH 2/3] udev: add bbappend and disable device cache as default.

2011-11-03 Thread Koen Kooi 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Op 03-11-11 10:09, Andrea Adami schreef:
 On Thu, Nov 3, 2011 at 9:36 AM, Koen Kooi
 k...@dominion.thruhere.netwrote:
 
 Op 02-11-11 22:00, Paul Eggleton schreef:
 On Monday 17 October 2011 01:26:50 Andrea Adami wrote:
 * For some reasons when the cache is created root can still be ro
 * and as solution you would be obliged to add 'rw' to your
 commandline. * There are patches in openembedded-classic to
 correct this * (and those are still pending for meta-oe). * Until
 a solution is found disable the creation of the device cache on
 boot.
 
 Signed-off-by: Andrea Adami andrea.ad...@gmail.com --- 
 recipes-core/udev/udev/default  |4  
 recipes-core/udev/udev_173.bbappend |1 + 2 files changed, 5 
 insertions(+), 0 deletions(-) create mode 100644 
 recipes-core/udev/udev/default create mode 100644 
 recipes-core/udev/udev_173.bbappend
 
 diff --git a/recipes-core/udev/udev/default 
 b/recipes-core/udev/udev/default new file mode 100644 index 
 000..ba2867e --- /dev/null +++
 b/recipes-core/udev/udev/default @@ -0,0 +1,4 @@ +# Default for
 /etc/init.d/udev + +# Uncomment this out to enable device cache
 +#DEVCACHE=/etc/dev.tar diff --git 
 a/recipes-core/udev/udev_173.bbappend 
 b/recipes-core/udev/udev_173.bbappend new file mode 100644 index 
 000..72d991c --- /dev/null +++ 
 b/recipes-core/udev/udev_173.bbappend @@ -0,0 +1 @@ 
 +FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
 
 I think this is going to cause problems for distros such as
 Angstrom that enable this layer without always using it. Can we
 just disable the dev cache for the machines in meta-handheld?
 
 Or get with the program and use udev 174 with systemd, no need for a
 device cache in that case!
 
 regards,
 
 Koen
 
 
 Sure, this is the future...but for now oe-core doesn't implement
 systemd as default.

Nor does it have udev 173. You can't argue that oe-core doesn't have
something that's in meta-oe when you're already relying on meta-oe.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
Comment: GPGTools - http://gpgtools.org

iD8DBQFOsl4HMkyGM64RGpERAtCEAJ9ogPDgyj0IsYMcKjLEML/PXvMK+ACgu3xN
RT3IaA5N1TqtzQQE81uoRHU=
=5YFd
-END PGP SIGNATURE-


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

Re: [oe] [oe-core[ de034bf830bec1b64260ac8516dd584163716ef4 breaks iproute2

2011-11-03 Thread Koen Kooi 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mails about oe-core need to be sent to the oe-core ml, not oe-dev.

Op 03-11-11 10:22, Sergey Lapin schreef:
 Hi, all! iptables upgrade broke iproute2. Do anybody work on this?
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
Comment: GPGTools - http://gpgtools.org

iD8DBQFOsmErMkyGM64RGpERAgafAJ9U4uxQuLeHbu/o67yyk+oiHxkGWgCgsiNv
5cuq1Wqq6e5pqNLvw/NLMa0=
=KTjR
-END PGP SIGNATURE-


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

[oe] [PATCH] new recipe - bluez-hcidump_2.1.bb, to build new version of bluez-hcidump-2.1 that compatible with bluez4_4.95.

2011-11-03 Thread Vita Preskovsky 
---
 recipes/bluez/bluez-hcidump_2.1.bb |   16 
 1 files changed, 16 insertions(+), 0 deletions(-)
 create mode 100644 recipes/bluez/bluez-hcidump_2.1.bb

diff --git a/recipes/bluez/bluez-hcidump_2.1.bb 
b/recipes/bluez/bluez-hcidump_2.1.bb
new file mode 100644
index 000..2e1389c
--- /dev/null
+++ b/recipes/bluez/bluez-hcidump_2.1.bb
@@ -0,0 +1,16 @@
+DESCRIPTION = Linux Bluetooth Stack HCI Debugger Tool.
+SECTION = console
+PRIORITY = optional
+DEPENDS = bluez-libs
+LICENSE = GPLv2
+PR = r0
+
+SRC_URI = http://bluez.sourceforge.net/download/bluez-hcidump-${PV}.tar.gz;
+S = ${WORKDIR}/bluez-hcidump-${PV}
+
+EXTRA_OECONF = --with-bluez-libs=${STAGING_LIBDIR} 
--with-bluez-includes=${STAGING_INCDIR}
+
+inherit autotools
+
+SRC_URI[md5sum] = b160f0672276398344eebe9df1b37a2c
+SRC_URI[sha256sum] = 
a6cc20b95b6b1a28ff336aad91e124555231628689225c1155e8cd7aac1af86d
-- 
1.7.0.4


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

[oe] Clean of qt4-embedded don't cleanup sysroot and deploy

2011-11-03 Thread Hauser, Wolfgang (external) 
It may be hidden by the huge work that is done by the community, so I
ask it again.

Hello,

if I do a bitbake -c clean for qt4-embedded or qt4-native all libraries
and binaries of QT are left in the sysroots and all created packages are
left in deploy. This is an result of splitting qt into several sub
packages and install them.

This behavior makes problems if I change the used QT Version of the
distro.
If qt recipe builds, it first searches for the libraries in sysroot
(standard library path of OE) and then it search in its working
directory. While the sysroots contain libraries of a different QT
version now, the build will fail. 

Is there a way to clean all sub packages of qt if I clean the
qt4-embedded or qt4-native package ?

An other solution may be to switch the order of the library paths in the
linker command (-L) to search libraries in the package working path
first. But how to do this in a proper way?

Regards
Wolfgang Hauser

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

Re: [oe] [meta-handheld][PATCH 2/3] udev: add bbappend and disable device cache as default.

2011-11-03 Thread Andrea Adami 
On Thu, Nov 3, 2011 at 10:25 AM, Koen Kooi k...@dominion.thruhere.netwrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Op 03-11-11 10:09, Andrea Adami schreef:
  On Thu, Nov 3, 2011 at 9:36 AM, Koen Kooi
  k...@dominion.thruhere.netwrote:
 
  Op 02-11-11 22:00, Paul Eggleton schreef:
  On Monday 17 October 2011 01:26:50 Andrea Adami wrote:
  * For some reasons when the cache is created root can still be ro
  * and as solution you would be obliged to add 'rw' to your
  commandline. * There are patches in openembedded-classic to
  correct this * (and those are still pending for meta-oe). * Until
  a solution is found disable the creation of the device cache on
  boot.
 
  Signed-off-by: Andrea Adami andrea.ad...@gmail.com ---
  recipes-core/udev/udev/default  |4 
  recipes-core/udev/udev_173.bbappend |1 + 2 files changed, 5
  insertions(+), 0 deletions(-) create mode 100644
  recipes-core/udev/udev/default create mode 100644
  recipes-core/udev/udev_173.bbappend
 
  diff --git a/recipes-core/udev/udev/default
  b/recipes-core/udev/udev/default new file mode 100644 index
  000..ba2867e --- /dev/null +++
  b/recipes-core/udev/udev/default @@ -0,0 +1,4 @@ +# Default for
  /etc/init.d/udev + +# Uncomment this out to enable device cache
  +#DEVCACHE=/etc/dev.tar diff --git
  a/recipes-core/udev/udev_173.bbappend
  b/recipes-core/udev/udev_173.bbappend new file mode 100644 index
  000..72d991c --- /dev/null +++
  b/recipes-core/udev/udev_173.bbappend @@ -0,0 +1 @@
  +FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
 
  I think this is going to cause problems for distros such as
  Angstrom that enable this layer without always using it. Can we
  just disable the dev cache for the machines in meta-handheld?
 
  Or get with the program and use udev 174 with systemd, no need for a
  device cache in that case!
 
  regards,
 
  Koen
 
 
  Sure, this is the future...but for now oe-core doesn't implement
  systemd as default.

 Nor does it have udev 173. You can't argue that oe-core doesn't have
 something that's in meta-oe when you're already relying on meta-oe.


Heh, I'm 'unfortunately' obliged to include meta-oe even if I want to build
a core-image-minimal for the machines in meta-handheld.

The problem is there are two sets of udev recipes! There should be one,
only one layer containing core packages.

I understand this is problematic and that Angstrom is already testing
systemd, still we should focus and find a concrete proposal for merging
with oe-core asap!

Cheers
Andrea
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] [meta-handheld][PATCH 1/3] formfactor: initial commit of collie, poodle and tosa machconfig

2011-11-03 Thread Paul Eggleton 
On Thursday 03 November 2011 09:51:33 Koen Kooi wrote:
 Op 02-11-11 22:02, Paul Eggleton schreef:
  On Monday 17 October 2011 01:26:49 Andrea Adami wrote:
  Signed-off-by: Andrea Adami andrea.ad...@gmail.com ...
  
  I've merged this series apart from 2/3 which we still need to discuss.
 
 Can you please update patchwork as well?

Apparently, despite patchwork saying I'm a contributor I have no ability to 
do so.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

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

[oe] Planned outage to move servers into new rackspace.

2011-11-03 Thread Tom King 
today, 3NOV2011, between 1000-1200PDT (1800-2000UTC) there will be a
short 15-30Minute outage for us to migrate our servers into the final
destination at the Colo.

This will affect all services including git, cgit, wiki, patches and bugs.

ka6sox
(for the OE Infra team)

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

[oe] [PATCH] rt-test: moved to github repo

2011-11-03 Thread Jason Kridner 
PR not bumped since previous builds would be identical.
---
 meta/recipes-rt/rt-tests/rt-tests_0.73.bb |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/meta/recipes-rt/rt-tests/rt-tests_0.73.bb 
b/meta/recipes-rt/rt-tests/rt-tests_0.73.bb
index a2cf6be..e816fa2 100644
--- a/meta/recipes-rt/rt-tests/rt-tests_0.73.bb
+++ b/meta/recipes-rt/rt-tests/rt-tests_0.73.bb
@@ -11,7 +11,7 @@ SRCREV = 81da016fb0f6ab0511fbec81fc8ba1a50398a20d
 PV = git${SRCPV}
 PR = r0
 
-SRC_URI = 
git://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git;protocol=git
+SRC_URI = git://github.com/clrkwllms/rt-tests.git;protocol=git
 
 S = ${WORKDIR}/git
 
-- 
1.7.4.1


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

Re: [oe] [PATCH] rt-test: moved to github repo

2011-11-03 Thread Martin Jansa 
On Thu, Nov 03, 2011 at 08:13:03AM -0400, Jason Kridner wrote:
 PR not bumped since previous builds would be identical.

This belongs to oe-core ML and there is already patch from Koen
http://patches.openembedded.org/patch/14239/

 ---
  meta/recipes-rt/rt-tests/rt-tests_0.73.bb |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/meta/recipes-rt/rt-tests/rt-tests_0.73.bb 
 b/meta/recipes-rt/rt-tests/rt-tests_0.73.bb
 index a2cf6be..e816fa2 100644
 --- a/meta/recipes-rt/rt-tests/rt-tests_0.73.bb
 +++ b/meta/recipes-rt/rt-tests/rt-tests_0.73.bb
 @@ -11,7 +11,7 @@ SRCREV = 81da016fb0f6ab0511fbec81fc8ba1a50398a20d
  PV = git${SRCPV}
  PR = r0
  
 -SRC_URI = 
 git://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git;protocol=git
 +SRC_URI = git://github.com/clrkwllms/rt-tests.git;protocol=git
  
  S = ${WORKDIR}/git
  
 -- 
 1.7.4.1
 
 
 ___
 Openembedded-devel mailing list
 Openembedded-devel@lists.openembedded.org
 http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


signature.asc
Description: Digital signature
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] [PATCH] rt-test: moved to github repo

2011-11-03 Thread Koen Kooi 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

OE-core patches need to go to the oe-core list :)

And have a look at
http://lists.linuxtogo.org/pipermail/openembedded-core/2011-November/012017.html

Op 03-11-11 13:13, Jason Kridner schreef:
 PR not bumped since previous builds would be identical. --- 
 meta/recipes-rt/rt-tests/rt-tests_0.73.bb |2 +- 1 files changed, 1 
 insertions(+), 1 deletions(-)
 
 diff --git a/meta/recipes-rt/rt-tests/rt-tests_0.73.bb 
 b/meta/recipes-rt/rt-tests/rt-tests_0.73.bb index a2cf6be..e816fa2 100644
 --- a/meta/recipes-rt/rt-tests/rt-tests_0.73.bb +++ 
 b/meta/recipes-rt/rt-tests/rt-tests_0.73.bb @@ -11,7 +11,7 @@ SRCREV = 
 81da016fb0f6ab0511fbec81fc8ba1a50398a20d PV = git${SRCPV} PR = r0
 
 -SRC_URI = 
 git://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git;protocol=git


 
+SRC_URI = git://github.com/clrkwllms/rt-tests.git;protocol=git
 
 S = ${WORKDIR}/git
 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
Comment: GPGTools - http://gpgtools.org

iD8DBQFOsocVMkyGM64RGpERAhSuAJ9CA5H0MqtYElRi9HySt/JH/lD02gCeLyvP
f1GuSNpNL8jDR9BarGHi8d8=
=p1q/
-END PGP SIGNATURE-


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

[oe] running bb located path info

2011-11-03 Thread mgundes 
   Hi everyone,

   I need to know is there a variable assigned with running current bb file
path?

   One of freenode #oe friend told me to try THISDIR but It did not work
for me. By the way, I use openembedded classic.

Regards,
Thanks

-- 
MahmutG
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] running bb located path info

2011-11-03 Thread Chris Larson 
On Thu, Nov 3, 2011 at 2:06 PM, mgundes mg...@hotmail.com wrote:
   I need to know is there a variable assigned with running current bb file
 path?

   One of freenode #oe friend told me to try THISDIR but It did not work
 for me. By the way, I use openembedded classic.

The 'FILE' variable holds the current file's full path. FILE_DIRNAME
is the directory it's in.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

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

Re: [oe] [oe-commits] Martin Jansa : midori: fix build with dirty vala

2011-11-03 Thread Andreas Müller 
On Thursday, November 03, 2011 01:52:48 AM Andreas Müller wrote:
 On Thursday, November 03, 2011 12:32:54 AM Martin Jansa wrote:
   Hm - I am afraid since this update midori never finishes configuring
   here. I waited for approximately 2 hours and stopped the process. The
   log file is attached ( a fresh retry creates similar log ). I commented
   out the whole
  
  Have you tried to revert it to see that it's not caused ie by glib
  changes or something? Because my vala detection change is already
  finished before it writes this stuff and the tar in waf is compared with
  hardcoded checksum, so it also could not change just by this monster
  blob.
 
 When sending previous mail I had two runs with and without your patch which
 gave me a clear picture. Now I have had some further rebuilds - seems
 sometimes it builds sometimes not! It's a bit late - tomorrow I would like
 to check further builds to see if I get a hang too with your patch
 reverted.
I created a simple script rebuilding midori again and again. I tested it with 
your patch reverted - I cannot tell when, but when I came back had also hang 
on 
configure. So your patch is out of suspicion. For now my strategy will be 
living 
with it.
 
  Could you also check if there is something interesting in ps aux or
  strace when it's hanging? On all 3 boxes I have tried this it always
  worked as expected.
  
   | do_configure_prepend()
   
   function, ran
   
   | bitbake -ccleanall midori
   
   and
   
   | bitbake midori
   
   without further issues in few minutes.
   
   Maybe we should rethink this monster blob commit intended to fix a
   corner case...
  
  Yes pity that this corner case is our only vala-native and I was hopping
  that newer midori with newer waf-1.6 will be released soon and this
  won't be needed anymore..
What I still do not unterstand: Since configure detetced vala correct with 
patch 
reverted I ran

~/tmp/oe-core-eglibc/sysroots/x86_64-linux/usr/bin/valac --version

I got

Vala 0.12.1

Why am I not dirty?

Andreas

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

Re: [oe] running bb located path info

2011-11-03 Thread mgundes 
   Thanks Chris.

Regards,

On Thu, Nov 3, 2011 at 11:21 PM, Chris Larson clar...@kergoth.com wrote:

 On Thu, Nov 3, 2011 at 2:06 PM, mgundes mg...@hotmail.com wrote:
I need to know is there a variable assigned with running current bb
 file
  path?
 
One of freenode #oe friend told me to try THISDIR but It did not work
  for me. By the way, I use openembedded classic.

 The 'FILE' variable holds the current file's full path. FILE_DIRNAME
 is the directory it's in.
 --
 Christopher Larson
 clarson at kergoth dot com
 Founder - BitBake, OpenEmbedded, OpenZaurus
 Maintainer - Tslib
 Senior Software Engineer, Mentor Graphics

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




-- 
MahmutG
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] [oe-commits] Martin Jansa : midori: fix build with dirty vala

2011-11-03 Thread Martin Jansa 
On Thu, Nov 03, 2011 at 10:45:16PM +0100, Andreas Müller wrote:
 On Thursday, November 03, 2011 01:52:48 AM Andreas Müller wrote:
  On Thursday, November 03, 2011 12:32:54 AM Martin Jansa wrote:
Hm - I am afraid since this update midori never finishes configuring
here. I waited for approximately 2 hours and stopped the process. The
log file is attached ( a fresh retry creates similar log ). I commented
out the whole
   
   Have you tried to revert it to see that it's not caused ie by glib
   changes or something? Because my vala detection change is already
   finished before it writes this stuff and the tar in waf is compared with
   hardcoded checksum, so it also could not change just by this monster
   blob.
  
  When sending previous mail I had two runs with and without your patch which
  gave me a clear picture. Now I have had some further rebuilds - seems
  sometimes it builds sometimes not! It's a bit late - tomorrow I would like
  to check further builds to see if I get a hang too with your patch
  reverted.
 I created a simple script rebuilding midori again and again. I tested it with 
 your patch reverted - I cannot tell when, but when I came back had also hang 
 on 
 configure. So your patch is out of suspicion. For now my strategy will be 
 living 
 with it.
  
   Could you also check if there is something interesting in ps aux or
   strace when it's hanging? On all 3 boxes I have tried this it always
   worked as expected.
   
| do_configure_prepend()

function, ran

| bitbake -ccleanall midori

and

| bitbake midori

without further issues in few minutes.

Maybe we should rethink this monster blob commit intended to fix a
corner case...
   
   Yes pity that this corner case is our only vala-native and I was hopping
   that newer midori with newer waf-1.6 will be released soon and this
   won't be needed anymore..
 What I still do not unterstand: Since configure detetced vala correct with 
 patch 
 reverted I ran
 
 ~/tmp/oe-core-eglibc/sysroots/x86_64-linux/usr/bin/valac --version
 
 I got
 
 Vala 0.12.1
 
 Why am I not dirty?

SHR buildhost with shr-chroot:
OE @ ~ $ ~/shr-core/tmp/sysroots/x86_64-linux/usr/bin/valac --version
Vala 0.12.1-dirty

my buildhost with shr-chroot:
OE @ ~ $ ~/shr-core/tmp/sysroots/x86_64-linux/usr/bin/valac --version
Vala 0.12.1

So right now only bad people are dirty and only sometimes.. see how they
get dirty

vala/build-aux/git-version-gen
...
# Don't declare a version dirty merely because a time stamp has changed.
git status  /dev/null 21

dirty=`sh -c 'git diff-index --name-only HEAD' 2/dev/null` || dirty=
case $dirty in
'') ;;
*) # Append the suffix only if there isn't one already.
case $v in
  *-dirty) ;;
  *) v=$v-dirty ;;
esac ;;
esac

shr buildhost:
OE @ ~/shr-core/tmp/work/x86_64-linux $ git diff-index --name-only HEAD
dev/.keep
dev/null
etc/group
etc/hosts
etc/localtime
etc/passwd
etc/resolv.conf
proc/.keep
sys/.keep
var/cache/ldconfig/aux-cache
var/run/utmp

and my buildhost:
OE @ ~/shr-core/tmp/work/x86_64-linux $ git diff-index --name-only HEAD
fatal: Not a git repository (or any parent up to mount parent /OE/shr-core/tmp)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).

The difference is that my tmp/work dir is mount -o bind outside shr-chroot
(which is itself git checkout).

So yes.. the detection in vala is not optimal and and causes false positive 
-dirty, 
but midori should be able to build even with really dirty vala_git.bb and newer
waf is also fixing it like this.

If someone confirms that this patch is causing some problems I'll remove -dirty 
detection from vala completely so it will also report clean on really dirty 
vala_git.bb.

Regards,

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


signature.asc
Description: Digital signature
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] [oe-commits] Martin Jansa : midori: fix build with dirty vala

2011-11-03 Thread Andreas Müller 
On Thursday, November 03, 2011 11:29:18 PM Martin Jansa wrote:
 On Thu, Nov 03, 2011 at 10:45:16PM +0100, Andreas Müller wrote:
  On Thursday, November 03, 2011 01:52:48 AM Andreas Müller wrote:
   On Thursday, November 03, 2011 12:32:54 AM Martin Jansa wrote:
 Hm - I am afraid since this update midori never finishes
 configuring here. I waited for approximately 2 hours and stopped
 the process. The log file is attached ( a fresh retry creates
 similar log ). I commented out the whole

Have you tried to revert it to see that it's not caused ie by glib
changes or something? Because my vala detection change is already
finished before it writes this stuff and the tar in waf is compared
with hardcoded checksum, so it also could not change just by this
monster blob.
   
   When sending previous mail I had two runs with and without your patch
   which gave me a clear picture. Now I have had some further rebuilds -
   seems sometimes it builds sometimes not! It's a bit late - tomorrow I
   would like to check further builds to see if I get a hang too with
   your patch reverted.
  
  I created a simple script rebuilding midori again and again. I tested it
  with your patch reverted - I cannot tell when, but when I came back had
  also hang on configure. So your patch is out of suspicion. For now my
  strategy will be living with it.
  
Could you also check if there is something interesting in ps aux or
strace when it's hanging? On all 3 boxes I have tried this it
always worked as expected.

 | do_configure_prepend()
 
 function, ran
 
 | bitbake -ccleanall midori
 
 and
 
 | bitbake midori
 
 without further issues in few minutes.
 
 Maybe we should rethink this monster blob commit intended to fix a
 corner case...

Yes pity that this corner case is our only vala-native and I was
hopping that newer midori with newer waf-1.6 will be released soon
and this won't be needed anymore..
  
  What I still do not unterstand: Since configure detetced vala correct
  with patch reverted I ran
  
  ~/tmp/oe-core-eglibc/sysroots/x86_64-linux/usr/bin/valac --version
  
  I got
  
  Vala 0.12.1
  
  Why am I not dirty?
 
 SHR buildhost with shr-chroot:
 OE @ ~ $ ~/shr-core/tmp/sysroots/x86_64-linux/usr/bin/valac --version
 Vala 0.12.1-dirty
 
 my buildhost with shr-chroot:
 OE @ ~ $ ~/shr-core/tmp/sysroots/x86_64-linux/usr/bin/valac --version
 Vala 0.12.1
 
 So right now only bad people are dirty and only sometimes.. see how they
 get dirty
:-))
 
 vala/build-aux/git-version-gen
 ...
 # Don't declare a version dirty merely because a time stamp has changed.
 git status  /dev/null 21
 
 dirty=`sh -c 'git diff-index --name-only HEAD' 2/dev/null` || dirty=
 case $dirty in
 '') ;;
 *) # Append the suffix only if there isn't one already.
 case $v in
   *-dirty) ;;
   *) v=$v-dirty ;;
 esac ;;
 esac
 
 shr buildhost:
 OE @ ~/shr-core/tmp/work/x86_64-linux $ git diff-index --name-only HEAD
 dev/.keep
 dev/null
 etc/group
 etc/hosts
 etc/localtime
 etc/passwd
 etc/resolv.conf
 proc/.keep
 sys/.keep
 var/cache/ldconfig/aux-cache
 var/run/utmp
 
 and my buildhost:
 OE @ ~/shr-core/tmp/work/x86_64-linux $ git diff-index --name-only HEAD
 fatal: Not a git repository (or any parent up to mount parent
 /OE/shr-core/tmp) Stopping at filesystem boundary
 (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
 
 The difference is that my tmp/work dir is mount -o bind outside shr-chroot
 (which is itself git checkout).
This is not a corner case - sorry
 
 So yes.. the detection in vala is not optimal and and causes false positive
 -dirty, but midori should be able to build even with really dirty
 vala_git.bb and newer waf is also fixing it like this.
agreed
 
 If someone confirms that this patch is causing some problems I'll remove
 -dirty detection from vala completely so it will also report clean on
 really dirty vala_git.bb.
After my tests it is not modified waf causing the trouble.
 
 Regards,
Thanks a lot for taking your time to clear up this one.

Andreas

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