date:20110728

For some reason when I get to do_rootfs for core-image-sato when using rpms I 
run into an issue in that:

${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}

Isn't expanding or taking the assignment in 
meta/conf/machine/include/tune-ppcFOO.inc but just using what it found in 
meta/conf/bitbake.conf

the tune-ppcFOO.inc looks like:

DEFAULTTUNE ?= ppce5500

require conf/machine/include/powerpc/arch-powerpc64.inc

TUNEVALID[ppce5500] = Enable ppce5500 specific processor optimizations
TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, ppce5500, 
-mcpu=e5500, , d)}
TUNE_PKGARCH .= ${@bb.utils.contains(TUNE_FEATURES, ppce5500, ppce5500, 
, d)}

AVAILTUNES += ppce5500
TUNE_FEATURES_tune-ppce5500 = m64 hard-fpu ppce5500
PACKAGE_EXTRA_ARCHS_tune-ppce5500 = powerpc64 ppce5500

any ideas?

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

Re: [OE-core] Add basic PowerPC core tune config (bug?)

2011-07-28 Thread Saul Wold


On 07/27/2011 10:25 PM, Kumar Gala wrote:

For some reason when I get to do_rootfs for core-image-sato when using rpms I 
run into an issue in that:

${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}

Isn't expanding or taking the assignment in 
meta/conf/machine/include/tune-ppcFOO.inc but just using what it found in 
meta/conf/bitbake.conf

the tune-ppcFOO.inc looks like:

DEFAULTTUNE ?= ppce5500

require conf/machine/include/powerpc/arch-powerpc64.inc

TUNEVALID[ppce5500] = Enable ppce5500 specific processor optimizations
TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, ppce5500, -mcpu=e5500, , 
d)}
TUNE_PKGARCH .= ${@bb.utils.contains(TUNE_FEATURES, ppce5500, ppce5500, , 
d)}

AVAILTUNES += ppce5500
TUNE_FEATURES_tune-ppce5500 = m64 hard-fpu ppce5500
PACKAGE_EXTRA_ARCHS_tune-ppce5500 = powerpc64 ppce5500

any ideas?

I believe that I am seeing this also with an atom-pc build, where the 
PACKAGE_EXTRA_ARCHS seems OK, but ends up just being i586 instead of a 
list of ARCHS that includes core2 (which atom-pc should be).


I am looking into this issue.

Sau!


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



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

Re: [OE-core] libzypp variable expansion problem


Op 28 jul. 2011, om 04:19 heeft Kumar Gala het volgende geschreven:

 In meta/recipes-extended/libzypp/libzypp_git.bb we having something that 
 looks like:
 
while [ $# -gt 0 ]; do
   ...
if [ ${AVOID_CONSTRUCTOR} != true ]; then
  ARCH=_$1
else
  ARCH=IdString(\$1\)
fi
   ...
COMPAT_WITH=${ARCH},${COMPAT} $COMPAT_WITH
done
 
 The problem is the COMPAT_WITH line should show up in the resulting script as 
 is, however its not getting expanded because ARCH is set.  So we end up with:
 
   COMPAT_WITH=powerpc,${COMPAT} $COMPAT_WITH
 
 instead of
 
   COMPAT_WITH=${ARCH},${COMPAT} $COMPAT_WITH
 
 Not quite sure how to fix this w/regards to quoting to prevent the expansion. 
  One solution is to just rename ARCH to something like CARCH.

Not really a solution to your problem, but in general ${FOO} gets expanded by 
bitbake, $FOO gets expanded by shell.

regards,

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

[OE-core] [PATCH 1/1] python-native: Fix a compiler finding issue

2011-07-28 Thread Mei Lei

The CC variable sometimes add option information after compiler name, but 
python can't get the real compiler name if those information added.
Fix this issue by dropping the option information when finding compiler name.

Signed-off-by: Mei Lei lei@intel.com
---
 .../python/python-native/unixccompiler.patch   |   20 
 .../recipes-devtools/python/python-native_2.6.6.bb |3 ++-
 2 files changed, 22 insertions(+), 1 deletions(-)
 create mode 100644 
meta/recipes-devtools/python/python-native/unixccompiler.patch

diff --git a/meta/recipes-devtools/python/python-native/unixccompiler.patch 
b/meta/recipes-devtools/python/python-native/unixccompiler.patch
new file mode 100644
index 000..10a9baf
--- /dev/null
+++ b/meta/recipes-devtools/python/python-native/unixccompiler.patch
@@ -0,0 +1,20 @@
+Upstream-Status: Inappropriate [embedded specific]
+
+# The CC variable,sometimes like:x86_64-poky-linux-gcc   -m64 
--sysroot=/${TMPDIR}/sysroots/qemux86-64, contains option information. 
+# This will lead to wrong compiler name qemux86-64 rather than 
x86_64-poky-linux-gcc when python finding the compiler name.
+
+#Signed-off-by: Mei Lei lei@intel.com
+
+diff --git Python-2.6.6/Lib/distutils/unixccompiler.py 
Python-2.6.6/Lib/distutils/unixccompiler.py
+index 6d0b84d..aaf49cb 100644
+--- Python-2.6.6/Lib/distutils/unixccompiler.py
 Python-2.6.6/Lib/distutils/unixccompiler.py
+@@ -282,7 +282,7 @@ class UnixCCompiler(CCompiler):
+ # this time, there's no way to determine this information from
+ # the configuration data stored in the Python installation, so
+ # we use this hack.
+-compiler = os.path.basename(sysconfig.get_config_var(CC))
++compiler = os.path.basename(sysconfig.get_config_var(CC).split()[0])
+ if sys.platform[:6] == darwin:
+ # MacOSX's linker doesn't understand the -R flag at all
+ return -L + dir
diff --git a/meta/recipes-devtools/python/python-native_2.6.6.bb 
b/meta/recipes-devtools/python/python-native_2.6.6.bb
index 59ed61a..2b00d32 100644
--- a/meta/recipes-devtools/python/python-native_2.6.6.bb
+++ b/meta/recipes-devtools/python/python-native_2.6.6.bb
@@ -1,6 +1,6 @@
 require python.inc
 DEPENDS = openssl-native bzip2-full-native zlib-native readline-native 
sqlite3-native
-PR = ${INC_PR}.2
+PR = ${INC_PR}.3
 
 LIC_FILES_CHKSUM = file://LICENSE;md5=38fdd546420fab09ac6bd3d8a1c83eb6
 
@@ -12,6 +12,7 @@ SRC_URI = 
http://www.python.org/ftp/python/${PV}/Python-${PV}.tar.bz2 \
file://11-distutils-never-modify-shebang-line.patch \
file://12-distutils-prefix-is-inside-staging-area.patch \
file://debug.patch \
+   file://unixccompiler.patch \
file://nohostlibs.patch
 S = ${WORKDIR}/Python-${PV}
 
-- 
1.6.3.3


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

[OE-core] [PATCH 0/1]python-native: Fix a compiler finding issue

2011-07-28 Thread Mei Lei

Hi,
This patch will fix an compiler finding issue.
The CC variable, its value sometimes like x86_64-poky-linux-gcc   -m64 
--sysroot=/${TMPDIR}/sysroots/qemux86-64, contains option information. This 
will confuse python when finding the compiler name, wrong compiler name 
qemux86-64 were found rather than the x86_64-poky-linux-gcc.
When I fixing python-pycairo multilib dir issue, above issue appeared and 
block the compile process. Please review it.

Thanks
Lei

The following changes since commit 819f18f8bc000f13b644edc194d2a12b4ea5fecf:
  Richard Purdie (1):
Move architecture specific TARGET_OS mangling into tune files

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib lmei3/python-pycairo
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=lmei3/python-pycairo

Mei Lei (1):
  python-native: Fix a compiler finding issue

 .../python/python-native/unixccompiler.patch   |   20 
 .../recipes-devtools/python/python-native_2.6.6.bb |3 ++-
 2 files changed, 22 insertions(+), 1 deletions(-)
 create mode 100644 
meta/recipes-devtools/python/python-native/unixccompiler.patch


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

Re: [OE-core] [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle

2011-07-28 Thread Martin Jansa

On Wed, Jul 27, 2011 at 12:19:22PM -0500, Mark Hatle wrote:
 On 7/27/11 10:25 AM, Phil Blundell wrote:
  On Wed, 2011-07-27 at 09:58 -0500, Mark Hatle wrote:
  For the tune names..  armv5 means I want classic ARM instructions, while 
  armv5t
  means I was thumb instructions.
 
  So armv5 and armv5t are distinct in the contents of the tunings.
  
  Ah, I see.  Does that go for v4t too?  I can imagine cases where you
  would want to say select the v4T ISA but generate ARM code not Thumb.
 
 Yes, for all of them, the TUNENAME selects the features that you want to use 
 to
 compile, and suggests the other information like compatible architectures.
 
 In the case where you want to build primarily one, and optionally the other 
 the
 tunename makes it easy..
 
 Say you want all of your system thumb, except for a few specific programs..
 
 TUNENAME = armv4t
 
 TUNENAME_pn-mysql = armv4
 
 In the opposite case, where you want everything ARM, except for a few thumb:
 
 TUNENAME = armv7
 TUNENAME_pn-bash = armv7t
 
 PACKAGE_EXTRA_ARCHS_tune-armv7 = ${PACKAGE_EXTRA_ARCHS_tune-armv7t}

We've discussed this yesterday on #yocto and there is problem with this

Before tune-* overhaul we had ARM_INSTRUCTION_SET option to force arm
mode from recipe even for architectures supporting thumb (ie armv4t).

Mark is right that if we have PACKAGE_ARCH = armv4t and we force
no-thumb with ARM_INSTRUCTION_SET = arm then PACKAGE_ARCH should be
switched to armv4 only to indicate that.

But ARM_INSTRUCTION_SET worked for all ARM architectures, but now I
would need to set
TUNENAME_pn-eglibc = armv4 in 
openembedded-core/meta/conf/machine/include/arm/arch-armv4.inc
TUNENAME_pn-eglibc = armv5 in 
openembedded-core/meta/conf/machine/include/arm/arch-armv5.inc
TUNENAME_pn-eglibc = armv6 in 
openembedded-core/meta/conf/machine/include/arm/arch-armv6.inc
TUNENAME_pn-eglibc = armv7 in 
openembedded-core/meta/conf/machine/include/arm/arch-armv7.inc
etc.. because I cannot disable thumb (while keeping thumb-interwork
enabled) from recipe globally for all as 
openembedded-core/meta/conf/machine/include/tune-thumb.inc
does, but that's not used and 
ARM_THUMB_M_OPT = 
${@['-mno-thumb','-mthumb'][bb.data.getVar('ARM_INSTRUCTION_SET', d, 1) == 
'thumb']}
is not respected anymore in
openembedded-core/meta/conf/machine/include/arm/feature-arm-thumb.inc

ARM_INSTRUCTION_SET = arm is used in some recipes because with thumb
enabled it fails to build and maybe such recipes can be fixed
(ie eglibc now fails for armv4t and armv7a)
and for some recipes it's set because it's producing faster code (where
binary size was more important).

Another problem with setting TUNENAME_pn-foo for every arch is when
foo_1.0.bb is in some obscure layer somewhere and maintainer of that
layer would need to alter all arch-armv[4567]*.inc files to keep foo
from using thumb. Maybe something like this in recipe should work?
TUNENAME_pn-eglibc_armv4t = armv4
TUNENAME_pn-eglibc_armv5t = armv5

And scale of ARM_INSTRUCTION_SET now ignored with oe-core:
OE om-gta02@shr ~/shr-core/openembedded-core $ git grep ARM_INSTRUCTION_SET
meta/classes/qt4e.bbclass:ARM_INSTRUCTION_SET = arm
meta/classes/qt4x11.bbclass:ARM_INSTRUCTION_SET = arm
meta/conf/machine/include/tune-thumb.inc:ARM_INSTRUCTION_SET ?= arm
meta/conf/machine/include/tune-thumb.inc:OVERRIDE_THUMB = ${@['', 
':thumb'][bb.data.getVar('ARM_INSTRUCTION_SET', d, 1) == 'thumb']}
meta/conf/machine/include/tune-thumb.inc:ARM_THUMB_M_OPT = ${@['-mno-thumb', 
'-mthumb'][bb.data.getVar('ARM_INSTRUCTION_SET', d, 1) == 'thumb']}
meta/recipes-core/eglibc/eglibc.inc:ARM_INSTRUCTION_SET = arm
meta/recipes-core/glib-2.0/glib.inc:ARM_INSTRUCTION_SET = arm
meta/recipes-core/glibc/glibc.inc:ARM_INSTRUCTION_SET = arm
meta/recipes-core/glibc/glibc_2.10.1.bb:ARM_INSTRUCTION_SET = arm
meta/recipes-core/uclibc/uclibc.inc:
${@[,s,.*COMPILE_IN_THUMB_MODE.*,COMPILE_IN_THUMB_MODE=y,;][bb.data.getVar(ARM_INSTRUCTION_SET,
 d, 1) != arm]} \
meta/recipes-devtools/gcc/gcc-csl-arm-2008q1.inc:ARM_INSTRUCTION_SET = arm
meta/recipes-graphics/xorg-xserver/xserver-kdrive.inc:ARM_INSTRUCTION_SET = 
arm
meta/recipes-multimedia/alsa/alsa-lib_1.0.24.1.bb:ARM_INSTRUCTION_SET = arm
meta/recipes-multimedia/gstreamer/gst-plugins-bad_0.10.21.bb:ARM_INSTRUCTION_SET
 = arm
meta/recipes-multimedia/libmad/libmad_0.15.1b.bb:ARM_INSTRUCTION_SET = arm
meta/recipes-multimedia/tremor/tremor_20101121.bb:ARM_INSTRUCTION_SET = arm
meta/recipes-qt/qt4/qt4_arch.inc:ARM_INSTRUCTION_SET = arm
meta/recipes-support/boost/boost-36.inc:ARM_INSTRUCTION_SET = arm
meta/recipes-support/gmp/gmp.inc:ARM_INSTRUCTION_SET = arm
meta/recipes-support/libgcrypt/libgcrypt.inc:ARM_INSTRUCTION_SET = arm
meta/recipes-support/liboil/liboil_0.3.17.bb:ARM_INSTRUCTION_SET = arm

OE om-gta02@shr ~/shr-core/meta-openembedded $ git grep ARM_INSTRUCTION_SET
meta-efl/classes/e-base.bbclass:ARM_INSTRUCTION_SET = arm
meta-efl/recipes-efl/webkit/webkit-efl_svn.bb:ARM_INSTRUCTION_SET = arm

[OE-core] Sanity check failed after glibc deletion (was: Re: [PATCH] glibc: deleted)

2011-07-28 Thread Samuel Stirtzel

My current configuration was set up with the help of the Angstrom
instructions [1], and I applied patches via the oebb.sh update
command.
Running Bitbake would show the following sanity error on any image / machine:

samuel@S-Linux:/var/oe-core/setup-scripts$ bitbake console-image
ERROR:  Poky's config sanity checker detected a potential misconfiguration.
Either fix the cause of this error or at your own risk disable the
checker (see sanity.conf).
Following is the list of potential problems / advisories:

You have a 32-bit libc, but no 32-bit headers.  You must install
the 32-bit libc headers.

ERROR: Execution of event handler 'check_sanity_eventhandler' failed


For me it looks like an error with my configuration, but on the other
side, before the update building images with bitbake worked.
Well I don't know exactly if this is caused by the glibc deletion, but
IMHO it seems very likely.
Anyone else faced the same problem?

Help would be very appreciated.

Regards
--Samuel

[1] 
http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-angstrom/tree/README

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

Re: [OE-core] Add basic PowerPC core tune config (bug?)

2011-07-28 Thread Cui, Dexuan

Saul Wold wrote on 2011-07-28:
 On 07/27/2011 10:25 PM, Kumar Gala wrote:
 For some reason when I get to do_rootfs for core-image-sato when using
 rpms I run into an issue in that:
 
 ${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
 
 Isn't expanding or taking the assignment in
 meta/conf/machine/include/tune-ppcFOO.inc but just using what it
 found in meta/conf/bitbake.conf
 
 I believe that I am seeing this also with an atom-pc build, where the
 PACKAGE_EXTRA_ARCHS seems OK, but ends up just being i586 instead of a
 list of ARCHS that includes core2 (which atom-pc should be).
Hi, I'm suffering from the exactly same issue... :-(
I don't know why PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} isn't expending yet.

Thanks,
-- Dexuan



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

Re: [OE-core] Add basic PowerPC core tune config (bug?)

On Thursday 28 July 2011 08:48:43 Cui, Dexuan wrote:
 Saul Wold wrote on 2011-07-28:
  On 07/27/2011 10:25 PM, Kumar Gala wrote:
  For some reason when I get to do_rootfs for core-image-sato when using
  rpms I run into an issue in that:
  
  ${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
  
  Isn't expanding or taking the assignment in
  meta/conf/machine/include/tune-ppcFOO.inc but just using what it
  found in meta/conf/bitbake.conf
  
  I believe that I am seeing this also with an atom-pc build, where the
  PACKAGE_EXTRA_ARCHS seems OK, but ends up just being i586 instead of a
  list of ARCHS that includes core2 (which atom-pc should be).
 
 Hi, I'm suffering from the exactly same issue... :-(
 I don't know why PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} isn't expending
 yet.

It seems to me that ??= gets confused because the variable name needs 
expanding. If you change the ${DEFAULTTUNE} reference to core2 in 
PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} ??= ${TARGET_ARCH} it all works. I 
don't know if that indicates a BitBake bug or whether we should try to work 
around it.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

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

Re: [OE-core] [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle

On Thu, 2011-07-28 at 09:24 +0200, Martin Jansa wrote:
 Mark is right that if we have PACKAGE_ARCH = armv4t and we force
 no-thumb with ARM_INSTRUCTION_SET = arm then PACKAGE_ARCH should be
 switched to armv4 only to indicate that.

No, this is wrong.  Even with ARM_INSTRUCTION_SET = arm you might have
BX instructions in the output, in which case armv4t is the correct
PACKAGE_ARCH.  You can only set PACKAGE_ARCH = armv4 if all the BXs
have been suppressed, which means that you lose the ability to do
interworking.

p.


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

Re: [OE-core] Add basic PowerPC core tune config (bug?)


Op 28 jul. 2011, om 10:47 heeft Paul Eggleton het volgende geschreven:

 On Thursday 28 July 2011 08:48:43 Cui, Dexuan wrote:
 Saul Wold wrote on 2011-07-28:
 On 07/27/2011 10:25 PM, Kumar Gala wrote:
 For some reason when I get to do_rootfs for core-image-sato when using
 rpms I run into an issue in that:
 
 ${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
 
 Isn't expanding or taking the assignment in
 meta/conf/machine/include/tune-ppcFOO.inc but just using what it
 found in meta/conf/bitbake.conf
 
 I believe that I am seeing this also with an atom-pc build, where the
 PACKAGE_EXTRA_ARCHS seems OK, but ends up just being i586 instead of a
 list of ARCHS that includes core2 (which atom-pc should be).
 
 Hi, I'm suffering from the exactly same issue... :-(
 I don't know why PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} isn't expending
 yet.
 
 It seems to me that ??= gets confused because the variable name needs 
 expanding. If you change the ${DEFAULTTUNE} reference to core2 in 
 PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} ??= ${TARGET_ARCH} it all works. I 
 don't know if that indicates a BitBake bug or whether we should try to work 
 around it.

I think it has to do with when the anonymous python runs. Try comparing 
'bitbake -e' and and 'bitbake -e some-image':

koen@dominion:/OE/tentacle/sources/openembedded-core/meta$ bitbake -e | grep 
PACKAGE_EXTRA_ARCHS\=
# PACKAGE_EXTRA_ARCHS=${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
PACKAGE_EXTRA_ARCHS=arm armv4 armv4t armv5 armv5t armv5-vfp armv5t-vfp armv5e 
armv5te armv5e-vfp armv5te-vfp armv6-vfp armv6t-vfp armv7-vfp armv7t2-vfp 
armv7a-vfp armv7at2-vfp armv7a-vfp-neon armv7at2-vfp-neon

koen@dominion:/OE/tentacle/sources/openembedded-core/meta$ bitbake -e 
efl-nodm-image | grep PACKAGE_EXTRA_ARCHS\=
# PACKAGE_EXTRA_ARCHS=${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
PACKAGE_EXTRA_ARCHS=arm

regards,

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

[OE-core] [PATCH 1/2] libnewt: update to 0.52.13

From: Kang Kai kai.k...@windriver.com

update libnewt to 0.52.13, and remove include-without-python.patch
because it has been merged.

Signed-off-by: Kang Kai kai.k...@windriver.com
---
 .../newt/files/include-without-python.patch|   73 
 .../{libnewt_0.52.12.bb = libnewt_0.52.13.bb} |7 +-
 2 files changed, 3 insertions(+), 77 deletions(-)
 delete mode 100644 
meta/recipes-extended/newt/files/include-without-python.patch
 rename meta/recipes-extended/newt/{libnewt_0.52.12.bb = libnewt_0.52.13.bb} 
(87%)

diff --git a/meta/recipes-extended/newt/files/include-without-python.patch 
b/meta/recipes-extended/newt/files/include-without-python.patch
deleted file mode 100644
index 263e9de..000
--- a/meta/recipes-extended/newt/files/include-without-python.patch
+++ /dev/null
@@ -1,73 +0,0 @@
-Upstream-Status: Pending
-
-From 3d13769050fac4cc6c904c174edc27e4f03d Mon Sep 17 00:00:00 2001
-From: Otavio Salvador ota...@ossystems.com.br
-Date: Thu, 20 Jan 2011 14:14:51 -0200
-Subject: [PATCH] build: add -without-python
-
-Signed-off-by: Otavio Salvador ota...@ossystems.com.br

- Makefile.in  |8 
- configure.ac |   10 --
- 2 files changed, 12 insertions(+), 6 deletions(-)
-
-diff --git a/Makefile.in b/Makefile.in
-index e764e61..74e9097 100644
 a/Makefile.in
-+++ b/Makefile.in
-@@ -77,7 +77,7 @@ showkey: showkey.o $(LIBNEWT)
-   $(CC) -g -o showkey showkey.o $(LIBNEWT) $(LDFLAGS) $(LIBS)
- 
- _snackmodule.so:   snackmodule.c $(LIBNEWTSH)
--  for ver in $(PYTHONVERS) ; do \
-+  [ -n $(PYTHONVERS) ]  for ver in $(PYTHONVERS) ; do \
-   mkdir -p $$ver ;\
-   PCFLAGS=`$$ver-config --cflags`; \
-   PIFLAGS=`$$ver-config --includes`; \
-@@ -85,7 +85,7 @@ _snackmodule.so:   snackmodule.c $(LIBNEWTSH)
-   PLFLAGS=`$$ver-config --libs`; \
-   $(CC) $(CPPFLAGS) $$PIFLAGS $$PCFLAGS -c -o $$ver/snackmodule.o 
snackmodule.c ;\
-   $(CC) --shared $$PLDFLAGS $$PLFLAGS $(LDFLAGS) -o 
$$ver/_snackmodule.so $$ver/snackmodule.o -L.  -lnewt $(LIBS);\
--  done
-+  done || :
-   touch $@
- 
- whiptail: $(NDIALOGOBJS) $(LIBNEWTSH)
-@@ -141,11 +141,11 @@ install-sh: sharedlib $(WHIPTCLSO) _snackmodule.so
-   ln -sf $(LIBNEWTSONAME) $(instroot)/$(libdir)/libnewt.so
-   ln -sf $(LIBNEWTSH) $(instroot)/$(libdir)/$(LIBNEWTSONAME)
-   [ -n $(WHIPTCLSO) ]  install -m 755 whiptcl.so 
$(instroot)/$(libdir) || :
--  for ver in $(PYTHONVERS) ; do \
-+  [ -n $(PYTHONVERS) ]  for ver in $(PYTHONVERS) ; do \
-  [ -d $(instroot)/$(libdir)/$$ver/site-packages ] || install -m 755 
-d $(instroot)/$(libdir)/$$ver/site-packages ;\
-  install -m 755 $$ver/_snackmodule.so 
$(instroot)/$(libdir)/$$ver/site-packages ;\
-  install -m 644 snack.py $(instroot)/$(libdir)/$$ver/site-packages ;\
--  done
-+  done || :
- 
- Makefile: newt.spec
-   echo You need to rerun ./configure before continuing
-diff --git a/configure.ac b/configure.ac
-index 7bc381a..dc04352 100644
 a/configure.ac
-+++ b/configure.ac
-@@ -54,8 +54,14 @@ fi
- AC_CHECK_HEADERS([popt.h libintl.h])
- 
- AC_MSG_CHECKING([for python versions])
--PYTHONVERS=$(echo /usr/include/python*/Python.h | sed s|/usr/include/||g| 
sed s|/Python.h||g 2 /dev/null)
--AC_MSG_RESULT([$PYTHONVERS])
-+AC_ARG_WITH([python], [  --without-pythondo not compile python 
support])
-+if test x$with_python = xno; then
-+  AC_MSG_RESULT([skipped])
-+  PYTHONVERS=
-+else
-+  PYTHONVERS=$(ls /usr/include/python*/Python.h 2 /dev/null | sed 
s|/usr/include/||g| sed s|/Python.h||g 2 /dev/null)
-+  AC_MSG_RESULT([$PYTHONVERS])
-+fi
- AC_SUBST([PYTHONVERS])
- 
- AC_ARG_WITH([tcl], [  --without-tcl   do not compile whiptcl.so])
--- 
-1.7.2.3
-
diff --git a/meta/recipes-extended/newt/libnewt_0.52.12.bb 
b/meta/recipes-extended/newt/libnewt_0.52.13.bb
similarity index 87%
rename from meta/recipes-extended/newt/libnewt_0.52.12.bb
rename to meta/recipes-extended/newt/libnewt_0.52.13.bb
index e2ad559..94ad0ee 100644
--- a/meta/recipes-extended/newt/libnewt_0.52.12.bb
+++ b/meta/recipes-extended/newt/libnewt_0.52.13.bb
@@ -17,16 +17,15 @@ LIC_FILES_CHKSUM = 
file://COPYING;md5=55ca817ccb7d5b5b66355690e9abc605
 # slang needs to be = 2.2
 DEPENDS = slang popt
 
-PR = r2
+PR = r0
 
 SRCREV = c3c7be75f6ef1adfc2be5f99c1e8ef3f0ab58c38
 
-SRC_URI = git://git.fedorahosted.org/git/newt;protocol=git \
-   file://include-without-python.patch \
+SRC_URI = https://fedorahosted.org/releases/n/e/newt/newt-0.52.13.tar.gz \
file://remove_slang_include.patch \
file://fix_SHAREDDIR.patch
 
-S = ${WORKDIR}/git
+S = ${WORKDIR}/newt-${PV}
 
 EXTRA_OECONF = --without-python --without-tcl
 
-- 
1.7.5.1.300.gc565c


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org

[OE-core] [PATCH 0/2] update distro tracking fields

From: Kang Kai kai.k...@windriver.com

Hi Saul,

I update the distro tracking fields of mailx slang libnewt and alsa-tools.

Because the mailx license file COPYING has lots of copyrights including 
personal,
company and MPL. I have no idea how to update the LICENSE and keep the STATUS 
red.

Do you have any suggestion about that?
Thank you!

The following changes since commit 860a41bae6b863a289b06a9684d9cf6c58a307bd:

  arch-ia32.inc: Fix up TUNE_ARCH variable conflicts (2011-07-26 22:39:59 +0100)

are available in the git repository at:
  git://git.pokylinux.org/poky-contrib kangkai/distro
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=kangkai/distro

Kang Kai (2):
  libnewt: update to 0.52.13
  distro_tracking_fields: update packages info

 .../conf/distro/include/distro_tracking_fields.inc |   28 +---
 .../newt/files/include-without-python.patch|   73 
 .../{libnewt_0.52.12.bb = libnewt_0.52.13.bb} |7 +-
 meta/recipes-extended/slang/slang_2.2.4.bb |1 +
 .../recipes-multimedia/alsa/alsa-tools_1.0.24.1.bb |9 ++-
 5 files changed, 28 insertions(+), 90 deletions(-)
 delete mode 100644 
meta/recipes-extended/newt/files/include-without-python.patch
 rename meta/recipes-extended/newt/{libnewt_0.52.12.bb = libnewt_0.52.13.bb} 
(87%)

-- 
1.7.5.1.300.gc565c


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

[OE-core] [PATCH 2/2] distro_tracking_fields: update packages info

From: Kang Kai kai.k...@windriver.com

update distro tracking fields of libnewt mailx slang and alsa-tools.

Signed-off-by: Kang Kai kai.k...@windriver.com
---
 .../conf/distro/include/distro_tracking_fields.inc |   28 ---
 meta/recipes-extended/slang/slang_2.2.4.bb |1 +
 .../recipes-multimedia/alsa/alsa-tools_1.0.24.1.bb |9 --
 3 files changed, 25 insertions(+), 13 deletions(-)

diff --git a/meta/conf/distro/include/distro_tracking_fields.inc 
b/meta/conf/distro/include/distro_tracking_fields.inc
index 3a3991d..974f6bd 100644
--- a/meta/conf/distro/include/distro_tracking_fields.inc
+++ b/meta/conf/distro/include/distro_tracking_fields.inc
@@ -5697,8 +5697,13 @@ RECIPE_MAINTAINER_pn-docbook-utils = Scott Garman 
scott.a.gar...@intel.com
 RECIPE_LATEST_VERSION_pn-task-qte-toolchain-target = 1.0
 RECIPE_MANUAL_CHECK_DATE_pn-task-qte-toolchain-target = Feb 28, 2011
 DISTRO_PN_ALIAS_pn-task-qte-toolchain-target = Intel
-RECIPE_LATEST_VERSION_pn-mailx = 12.4
-RECIPE_MANUAL_CHECK_DATE_pn-mailx = Feb 28, 2011
+
+RECIPE_STATUS_pn-mailx = red
+RECIPE_LATEST_VERSION_pn-mailx = 12.5
+RECIPE_LAST_UPDATE_pn-mailx = Jul 1, 2011
+RECIPE_MANUAL_CHECK_DATE_pn-mailx = Jul 28, 2011
+RECIPE_MAINTAINER_pn-mailx = Kai Kang kai.k...@windriver.com
+
 RECIPE_LATEST_VERSION_pn-libgcc = 4.5.1
 RECIPE_MANUAL_CHECK_DATE_pn-libgcc = Feb 28, 2011
 
@@ -5724,13 +5729,15 @@ RECIPE_MAINTAINER_pn-linuxdoc-tools = Scott Garman 
scott.a.gar...@intel.com
 
 RECIPE_STATUS_pn-slang = green
 RECIPE_LATEST_VERSION_pn-slang = 2.2.4
-RECIPE_LAST_UPDATE_pn-slang = Apr 10, 2011
-RECIPE_MANUAL_CHECK_DATE_pn-slang = Jun 6, 2011
+RECIPE_LAST_UPDATE_pn-slang = Jul 28, 2011
+RECIPE_MANUAL_CHECK_DATE_pn-slang = Jun 28, 2011
+RECIPE_MAINTAINER_pn-slang = Kai Kang kai.k...@windriver.com
 
 RECIPE_STATUS_pn-libnewt = green
-RECIPE_LATEST_VERSION_pn-libnewt = 0.52.12
-RECIPE_LAST_UPDATE_pn-libnewt = Aug 06, 2010
-RECIPE_MANUAL_CHECK_DATE_pn-libnewt = Jun 4, 2011
+RECIPE_LATEST_VERSION_pn-libnewt = 0.52.13
+RECIPE_MAINTAINER_pn-libnewt = Kai Kang kai.k...@windriver.com
+RECIPE_LAST_UPDATE_pn-libnewt = Jul 27, 2011
+RECIPE_MANUAL_CHECK_DATE_pn-libnewt = Jul 27, 2011
 RECIPE_NO_UPDATE_REASON_pn-libnewt = 
 
 RECIPE_STATUS_pn-createrepo = green
@@ -5762,10 +5769,11 @@ RECIPE_COMMENTS_pn-rxvt-unicode = 
 RECIPE_LAST_UPDATE_pn-rxvt-unicode = May 25, 2011
 RECIPE_MAINTAINER_pn-rxvt-unicode = Saul Wold s...@linux.intel.com
 
-RECIPE_STATUS_pn-alsa-tools = red
+RECIPE_STATUS_pn-alsa-tools = green
 RECIPE_LATEST_VERIONS_pn-alsa-tools = 1.0.24.1
-RECIPE_LAST_UPDATE_pn-alsa-tools = Jan 31, 2011
-RECIPE_MANUAL_CHECK_DATE_pn-alsa-tools = Jun 7, 2011 
+RECIPE_LAST_UPDATE_pn-alsa-tools = Jul 28, 2011
+RECIPE_MANUAL_CHECK_DATE_pn-alsa-tools = Jul 28, 2011
+RECIPE_MAINTAINER_pn-alsa-tools = Kai Kang kai.k...@windriver.com
 
 RECIPE_STATUS_pn-mesa-demos = red
 RECIPE_LATEST_VERSION_pn-mesa-demos = 8.0.1
diff --git a/meta/recipes-extended/slang/slang_2.2.4.bb 
b/meta/recipes-extended/slang/slang_2.2.4.bb
index 4bf5737..e13f0ad 100644
--- a/meta/recipes-extended/slang/slang_2.2.4.bb
+++ b/meta/recipes-extended/slang/slang_2.2.4.bb
@@ -7,6 +7,7 @@ The S-Lang library, provided in this package, provides the 
S-Lang \
 extension language.  S-Lang's syntax resembles C, which makes it easy \
 to recode S-Lang procedures in C if you need to.
 
+HOMEPAGE = http://www.jedsoft.org/slang/;
 SECTION = libs
 DEPENDS = pcre
 PR = r5
diff --git a/meta/recipes-multimedia/alsa/alsa-tools_1.0.24.1.bb 
b/meta/recipes-multimedia/alsa/alsa-tools_1.0.24.1.bb
index 1bf9cd0..d6ecf7f 100644
--- a/meta/recipes-multimedia/alsa/alsa-tools_1.0.24.1.bb
+++ b/meta/recipes-multimedia/alsa/alsa-tools_1.0.24.1.bb
@@ -1,13 +1,16 @@
 BROKEN = 1
 
-DESCRIPTION = Alsa Tools
+DESCRIPTION = Alsa Tools package contains advanced tools for certain sound 
cards.
+HOMEPAGE = http://www.alsa-project.org;
+BUGTRACKER = https://bugtrack.alsa-project.org/alsa-bug/login_page.php;
 SECTION = console/utils
-LICENSE = GPLv2
+LICENSE = GPLv2  LGPLv2+
 DEPENDS = alsa-lib ncurses
 
 PR = r2
 
-LIC_FILES_CHKSUM = 
file://hdsploader/COPYING;md5=94d55d512a9ba36caa9b7df079bae19f
+LIC_FILES_CHKSUM = 
file://hdsploader/COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
+
file://ld10k1/COPYING.LIB;md5=7fbc338309ac38fefcd64b04bb903e34
 
 SRC_URI = ftp://ftp.alsa-project.org/pub/tools/alsa-tools-${PV}.tar.bz2 \
file://autotools.patch
-- 
1.7.5.1.300.gc565c


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

[OE-core] [PATCHv2] gst-plugins: partially sync packaging with OE .dev

Gst-plugins get 2 extra packages:

${PN}-apps: helper apps in ${bindir}
${PN}-meta: meta package that will drag in all plugins, libs and apps ${PN} 
generates

And all libs are split out and run through debian style renaming if enabled.

The packaging include was split out to be reused by external plugins (e.g. 
gst-plugin-gl, gst-fluendo-*).

The new package list looks like:

libgstapp-0.10-0_0.10.32-r1_armv7a.ipk
libgstfft-0.10-0_0.10.32-r1_armv7a.ipk
[..]
gst-plugins-base-videorate_0.10.32-r1_armv7a.ipk
gst-plugins-base-videoscale_0.10.32-r1_armv7a.ipk
[..]
gst-plugins-base-meta_0.10.32-r1_armv7a.ipk
[..]
gst-plugins-base-apps_0.10.32-r1_armv7a.ipk

Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---

Changes since v1:
* keep gst-plugin-{base,good,base,ugly}-foo naming, this will get 
addressed in a follow-up patch

 .../gstreamer/gst-plugins-bad_0.10.21.bb   |2 +-
 .../gstreamer/gst-plugins-base_0.10.32.bb  |2 +-
 .../gstreamer/gst-plugins-good_0.10.28.bb  |2 +-
 .../gstreamer/gst-plugins-package.inc  |   34 
 .../gstreamer/gst-plugins-ugly_0.10.17.bb  |2 +-
 meta/recipes-multimedia/gstreamer/gst-plugins.inc  |   18 +-
 6 files changed, 40 insertions(+), 20 deletions(-)
 create mode 100644 meta/recipes-multimedia/gstreamer/gst-plugins-package.inc

diff --git a/meta/recipes-multimedia/gstreamer/gst-plugins-bad_0.10.21.bb 
b/meta/recipes-multimedia/gstreamer/gst-plugins-bad_0.10.21.bb
index 2b8a89c..a7023e3 100644
--- a/meta/recipes-multimedia/gstreamer/gst-plugins-bad_0.10.21.bb
+++ b/meta/recipes-multimedia/gstreamer/gst-plugins-bad_0.10.21.bb
@@ -9,7 +9,7 @@ LIC_FILES_CHKSUM = 
file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3 \
 
 DEPENDS += gst-plugins-base libmusicbrainz tremor librsvg
 
-PR = r0
+PR = r1
 
 inherit gettext
 
diff --git a/meta/recipes-multimedia/gstreamer/gst-plugins-base_0.10.32.bb 
b/meta/recipes-multimedia/gstreamer/gst-plugins-base_0.10.32.bb
index a9e2b52..82d9afc 100644
--- a/meta/recipes-multimedia/gstreamer/gst-plugins-base_0.10.32.bb
+++ b/meta/recipes-multimedia/gstreamer/gst-plugins-base_0.10.32.bb
@@ -13,7 +13,7 @@ SRC_URI +=  file://gst-plugins-base-tremor.patch
 SRC_URI[md5sum] = 2920af2b3162f3d9fbaa7fabc8ed4d38
 SRC_URI[sha256sum] = 
e9aabfac83f6480896da0686e9c911989f896fbad634821b7771ed84a446172b
 
-PR = r0
+PR = r1
 
 inherit gettext
 
diff --git a/meta/recipes-multimedia/gstreamer/gst-plugins-good_0.10.28.bb 
b/meta/recipes-multimedia/gstreamer/gst-plugins-good_0.10.28.bb
index b9648e3..cca63e9 100644
--- a/meta/recipes-multimedia/gstreamer/gst-plugins-good_0.10.28.bb
+++ b/meta/recipes-multimedia/gstreamer/gst-plugins-good_0.10.28.bb
@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM = 
file://COPYING;md5=a6f89e2100d9b6cdffcea4f398e37343 \
 
 DEPENDS += gst-plugins-base gconf cairo jpeg libpng gtk+ zlib libid3tag flac \
speex libsoup-2.4
-PR = r0
+PR = r1
 
 inherit gettext
 
diff --git a/meta/recipes-multimedia/gstreamer/gst-plugins-package.inc 
b/meta/recipes-multimedia/gstreamer/gst-plugins-package.inc
new file mode 100644
index 000..796df14
--- /dev/null
+++ b/meta/recipes-multimedia/gstreamer/gst-plugins-package.inc
@@ -0,0 +1,34 @@
+LIBV = 0.10
+
+python populate_packages_prepend () {
+   gst_libdir = bb.data.expand('${libdir}/gstreamer-${LIBV}', d)
+   postinst = bb.data.getVar('plugin_postinst', d, 1)
+   glibdir = bb.data.expand('${libdir}', d)
+
+   do_split_packages(d, glibdir, '^lib(.*)\.so\.*', 'lib%s', 'gstreamer %s 
library', extra_depends='', allow_links=True)
+   do_split_packages(d, gst_libdir, 'libgst(.*)\.so$', 
bb.data.expand('${PN}-%s', d), 'GStreamer plugin for %s', postinst=postinst, 
extra_depends=bb.data.expand('${PN}',d))
+   do_split_packages(d, gst_libdir, 'libgst(.*)\.l?a$', 
bb.data.expand('${PN}-%s-dev', d), 'GStreamer plugin for %s (development 
files)', extra_depends=bb.data.expand('${PN}-dev',d))
+   
+   pn = bb.data.getVar('PN', d, 1)
+   metapkg =  pn + '-meta'
+   bb.data.setVar('ALLOW_EMPTY_' + metapkg, 1, d)
+   bb.data.setVar('FILES_' + metapkg, , d)
+   blacklist = [ pn + '-locale', pn + '-dev', pn + '-dbg', pn + '-doc' ]
+   metapkg_rdepends = []
+   packages = bb.data.getVar('PACKAGES', d, 1).split()
+   for pkg in packages[1:]:
+   if not pkg in blacklist and not pkg in metapkg_rdepends and not 
pkg.endswith('-dev') and not pkg.endswith('-dbg') and not pkg.count('locale') 
and not pkg.count('-static'):
+   metapkg_rdepends.append(pkg)
+   bb.data.setVar('RDEPENDS_' + metapkg, ' '.join(metapkg_rdepends), d)
+   bb.data.setVar('DESCRIPTION_' + metapkg, pn + ' meta package', d)
+}
+
+ALLOW_EMPTY = 1
+
+PACKAGES += ${PN}-apps ${PN}-meta
+FILES_${PN}-apps = ${bindir}
+
+FILES_${PN} = ${datadir}/gstreamer-${LIBV}
+FILES_${PN}-dbg += ${libdir}/gstreamer-${LIBV}/.debug
+
+
diff --git

Re: [OE-core] [PATCHv2] gst-plugins: partially sync packaging with OE .dev

On Thu, 2011-07-28 at 11:44 +0200, Koen Kooi wrote:
 +ALLOW_EMPTY = 1

Is that necessary?  You seem to be setting ALLOW_EMPTY_${PN}-meta=1 in
your python code anyway.

p.



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

Re: [OE-core] Add basic PowerPC core tune config (bug?)


Op 28 jul. 2011, om 11:20 heeft Phil Blundell het volgende geschreven:

 On Thu, 2011-07-28 at 10:57 +0200, Koen Kooi wrote:
 Op 28 jul. 2011, om 10:47 heeft Paul Eggleton het volgende geschreven:
 
 On Thursday 28 July 2011 08:48:43 Cui, Dexuan wrote:
 Saul Wold wrote on 2011-07-28:
 On 07/27/2011 10:25 PM, Kumar Gala wrote:
 For some reason when I get to do_rootfs for core-image-sato when using
 rpms I run into an issue in that:
 
 ${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
 
 Isn't expanding or taking the assignment in
 meta/conf/machine/include/tune-ppcFOO.inc but just using what it
 found in meta/conf/bitbake.conf
 
 I believe that I am seeing this also with an atom-pc build, where the
 PACKAGE_EXTRA_ARCHS seems OK, but ends up just being i586 instead of a
 list of ARCHS that includes core2 (which atom-pc should be).
 
 Hi, I'm suffering from the exactly same issue... :-(
 I don't know why PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} isn't expending
 yet.
 
 It seems to me that ??= gets confused because the variable name needs 
 expanding. If you change the ${DEFAULTTUNE} reference to core2 in 
 PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} ??= ${TARGET_ARCH} it all works. 
 I 
 don't know if that indicates a BitBake bug or whether we should try to work 
 around it.
 
 I think it has to do with when the anonymous python runs. Try comparing 
 'bitbake -e' and and 'bitbake -e some-image':
 
 koen@dominion:/OE/tentacle/sources/openembedded-core/meta$ bitbake -e | grep 
 PACKAGE_EXTRA_ARCHS\=
 # PACKAGE_EXTRA_ARCHS=${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
 PACKAGE_EXTRA_ARCHS=arm armv4 armv4t armv5 armv5t armv5-vfp armv5t-vfp 
 armv5e armv5te armv5e-vfp armv5te-vfp armv6-vfp armv6t-vfp armv7-vfp 
 armv7t2-vfp armv7a-vfp armv7at2-vfp armv7a-vfp-neon armv7at2-vfp-neon
 
 koen@dominion:/OE/tentacle/sources/openembedded-core/meta$ bitbake -e 
 efl-nodm-image | grep PACKAGE_EXTRA_ARCHS\=
 # PACKAGE_EXTRA_ARCHS=${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
 PACKAGE_EXTRA_ARCHS=arm
 
 No, I think Paul is right about the cause (though I don't agree with him
 that it is a bug exactly).  The timing of anonymous python oughtn't to
 be different in those two cases so I don't think that will be making a
 difference.
 
 That assignment to PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} in
 bitbake.conf is just fundamentally bogus.  As far as the bitbake parser
 is concerned, PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} and
 PACKAGE_EXTRA_ARCHS_tune-arm926ejs are different variables (assuming
 DEFAULTTUNE=arm926ejs for the sake of an example) and it will create
 both of them.  Then, later, when the lvalues get expanded the latter
 will be overwritten by the former which seems like it is exactly the
 opposite to the effect that's wanted here.
 
 This is long-standing bitbake behaviour and I'm not sure it would be
 practical to change.  I think the metadata just needs to be written to
 work with the semantics that we have.

Removing the PACKAGE_EXTRA_ARCHS line from bitbake.conf makes it work for me 
again, is that an acceptable solution?

regards,

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

Re: [OE-core] Add basic PowerPC core tune config (bug?)

On Thu, 2011-07-28 at 12:00 +0200, Koen Kooi wrote:
 Removing the PACKAGE_EXTRA_ARCHS line from bitbake.conf makes it work for me 
 again, is that an acceptable solution?

Sounds about right to me.  If ${TARGET_ARCH} really does need to go into
PACKAGE_EXTRA_ARCHS by default (which sounds implausible to me) then
we'll have to find some other way to achieve that.

p.



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

[OE-core] [PATCH] [PATCH] raptor: add recipe

Signed-off-by: Frans Meulenbroeks fransmeulenbro...@gmail.com
Signed-off-by: Ben Gardiner bengardi...@nanometrics.ca
Signed-off-by: Tom Rini tom_r...@mentor.com

This recipe is a port of recipes/raptor/raptor_1.4.21.bb from
git://git.openembedded.org/openembedded, commits
01e8e9f325d8d251e852e7a5704b5fe50880e1ad 'raptor: added recipe' and
f1d24b5a986233f869364eb109476f5184e76d10 'raptor: add libxml2 DEPENDS'

The recipe was modified by adding a LIC_FILES_CHKSUM assignment.

Signed-off-by: Ben Gardiner bengardi...@nanometrics.ca

---

Not tested in the oe-core + meta-openembedded et. al. layers. We are not
ready yet to migrate from the 2011.03-maintenance branch. This patch is
proposed for inclusion in oe-core so that we can meet the new policy
requirements for inclusion in the 2011.03-maintenance branch and submit
a subsequent pull-request for commit
f1d24b5a986233f869364eb109476f5184e76d10 raptor: add libxml2 DEPENDS
---
 meta/recipes-support/raptor/raptor_1.4.21.bb |   13 +
 1 files changed, 13 insertions(+), 0 deletions(-)
 create mode 100644 meta/recipes-support/raptor/raptor_1.4.21.bb

diff --git a/meta/recipes-support/raptor/raptor_1.4.21.bb 
b/meta/recipes-support/raptor/raptor_1.4.21.bb
new file mode 100644
index 000..84fa69e
--- /dev/null
+++ b/meta/recipes-support/raptor/raptor_1.4.21.bb
@@ -0,0 +1,13 @@
+DESCRIPTION = Raptor RDF Parser Library
+SECTION = libs
+HOMEPAGE = http://librdf.org/raptor/;
+LICENSE = LGPL 2.1/GPL 2/Apache 2.0
+LIC_FILES_CHKSUM = file://COPYING;md5=751419260aa954499f7abaabaa882bbe
+PR = r0
+SRC_URI = http://download.librdf.org/source/raptor-${PV}.tar.gz;
+DEPENDS = libxml2
+
+inherit autotools pkgconfig
+
+SRC_URI[md5sum] = 992061488af7a9e2d933df6b694bb876
+SRC_URI[sha256sum] = 
db3172d6f3c432623ed87d7d609161973d2f7098e3d2233d0702fbcc22cfd8ca
-- 
1.7.4.1


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

Re: [OE-core] [PATCH] [PATCH] raptor: add recipe


Op 28 jul. 2011, om 05:38 heeft Ben Gardiner het volgende geschreven:

 Signed-off-by: Frans Meulenbroeks fransmeulenbro...@gmail.com
 Signed-off-by: Ben Gardiner bengardi...@nanometrics.ca
 Signed-off-by: Tom Rini tom_r...@mentor.com
 
 This recipe is a port of recipes/raptor/raptor_1.4.21.bb from
 git://git.openembedded.org/openembedded, commits
 01e8e9f325d8d251e852e7a5704b5fe50880e1ad 'raptor: added recipe' and
 f1d24b5a986233f869364eb109476f5184e76d10 'raptor: add libxml2 DEPENDS'

Why does this need to be in OE-core and not in some other layer? It doesn't 
look so core to me, especially since nothing in oe-core (or meta-oe/efl/gnome 
for that matter) depends on it

 
 The recipe was modified by adding a LIC_FILES_CHKSUM assignment.
 
 Signed-off-by: Ben Gardiner bengardi...@nanometrics.ca
 
 ---
 
 Not tested in the oe-core + meta-openembedded et. al. layers.

So why are you sending it if it isn't tested?

 We are not
 ready yet to migrate from the 2011.03-maintenance branch. This patch is
 proposed for inclusion in oe-core so that we can meet the new policy
 requirements for inclusion in the 2011.03-maintenance branch

Where does it say it's OK to do a pull request for untested recipes? And where 
does it say it needs to be in OE-core first?

 and submit
 a subsequent pull-request for commit

I seriously disagree with sending pull requests for the maintenaince branch for 
untested recipes!
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/1] meta-environment: set correct *MULTIMACH_TARGET_SYS.

2011-07-28 Thread Lianhao Lu

Fixed [BUGID #1299]. OLD_MULTIMACH_TARGET_SYS is no longer available.
Use new recipe-scope variable REAL_MULTIMACH_TARGET_SYS instead.

Signed-off-by: Lianhao Lu lianhao...@intel.com
---
 meta/classes/toolchain-scripts.bbclass |7 ---
 meta/recipes-core/meta/meta-environment.bb |9 +
 2 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/meta/classes/toolchain-scripts.bbclass 
b/meta/classes/toolchain-scripts.bbclass
index 3301319..832cce4 100644
--- a/meta/classes/toolchain-scripts.bbclass
+++ b/meta/classes/toolchain-scripts.bbclass
@@ -66,13 +66,14 @@ toolchain_create_tree_env_script () {
 # This function creates an environment-setup-script for use by the ADT 
installer
 toolchain_create_sdk_env_script_for_installer () {
# Create environment setup script
-   
script=${SDK_OUTPUT}/${SDKPATH}/environment-setup-${OLD_MULTIMACH_TARGET_SYS}
+   local multimach_target_sys=$1
+   
script=${SDK_OUTPUT}/${SDKPATH}/environment-setup-${multimach_target_sys}
rm -f $script
touch $script
-   echo 'export 
PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/${OLD_MULTIMACH_TARGET_SYS}:$PATH'
  $script
+   echo 'export 
PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/'${multimach_target_sys}':$PATH'
  $script
echo 'export PKG_CONFIG_SYSROOT_DIR=##SDKTARGETSYSROOT##'  $script
echo 'export 
PKG_CONFIG_PATH=##SDKTARGETSYSROOT##${target_libdir}/pkgconfig'  $script
-   echo 'export 
CONFIG_SITE=${SDKPATH}/site-config-${OLD_MULTIMACH_TARGET_SYS}'  $script
+   echo 'export 
CONFIG_SITE=${SDKPATH}/site-config-'${multimach_target_sys}  $script
echo 'export CC=${TARGET_PREFIX}gcc'  $script
echo 'export CXX=${TARGET_PREFIX}g++'  $script
echo 'export GDB=${TARGET_PREFIX}gdb'  $script
diff --git a/meta/recipes-core/meta/meta-environment.bb 
b/meta/recipes-core/meta/meta-environment.bb
index 351cbf0..6d547bb 100644
--- a/meta/recipes-core/meta/meta-environment.bb
+++ b/meta/recipes-core/meta/meta-environment.bb
@@ -2,13 +2,14 @@ DESCRIPTION = Package of environment files for SDK
 LIC_FILES_CHKSUM = 
file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
 
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420
 LICENSE = MIT
-PR = r4
+PR = r5
 
 EXCLUDE_FROM_WORLD = 1
 
 inherit toolchain-scripts
 # get target config site before inheritting cross-canadian
 TARGET_CONFIG_SITE := ${@siteinfo_get_files(d)}
+REAL_MULTIMACH_TARGET_SYS = ${TUNE_PKGARCH}${TARGET_VENDOR}-${TARGET_OS}
 
 SDK_DIR = ${WORKDIR}/sdk
 SDK_OUTPUT = ${SDK_DIR}/image
@@ -22,12 +23,12 @@ do_generate_content() {
 rm -rf ${SDK_OUTPUT}
 mkdir -p ${SDK_OUTPUT}/${SDKPATH}
 
-toolchain_create_sdk_siteconfig 
${SDK_OUTPUT}/${SDKPATH}/site-config-${OLD_MULTIMACH_TARGET_SYS} 
${TARGET_CONFIG_SITE}
+toolchain_create_sdk_siteconfig 
${SDK_OUTPUT}/${SDKPATH}/site-config-${REAL_MULTIMACH_TARGET_SYS} 
${TARGET_CONFIG_SITE}
 
-toolchain_create_sdk_env_script_for_installer
+toolchain_create_sdk_env_script_for_installer ${REAL_MULTIMACH_TARGET_SYS}
 
 # Add version information
-toolchain_create_sdk_version 
${SDK_OUTPUT}/${SDKPATH}/version-${OLD_MULTIMACH_TARGET_SYS}
+toolchain_create_sdk_version 
${SDK_OUTPUT}/${SDKPATH}/version-${REAL_MULTIMACH_TARGET_SYS}
 }
 addtask generate_content before do_install after do_compile
 
-- 
1.7.0.4


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

Re: [OE-core] Sanity check failed after glibc deletion (was: Re: [PATCH] glibc: deleted)

2011-07-28 Thread Samuel Stirtzel

The oebb.sh script can be used to update all openembedded-core layers
and custom added sources from the layers.txt file in
oe-core-dir/setup-scripts/sources/layers.txt.
After checking my local repositories with git-log again, I found out
that your patch is not responsible for this.
It seems like something else (most likely not openembedded-core
related) has caused this error.

My desktop PC runs a 64bit Linux.
After locating the error message in sanity.bbclass (line 279) which
follows, either (like you said) the stubs-32.h was removed or some
strange lib configurations applied something to my PC.
This could not be caused from updating the git repositories or
applying patches, so something else must have happened (I still wonder
what).
And since it occured right after i updated my sources my first guess
was glibc, I should have looked in the sanity.bbclass earlier.
--
if os.path.exists('%s/libc.so.6' % lib32path) and not
os.path.exists('/usr/include/gnu/stubs-32.h'):
  messages = messages + You have a 32-bit libc, but no 32-bit
headers.  You must install the 32-bit libc headers.\n
--
After I re-installed gcc-multilib the error disappeared.
Seems odd to me but the problems are gone.

Regards
--Samuel

2011/7/28 Phil Blundell ph...@gnu.org:
 I'm not familiar with oebb.sh or its functionality.  But, from what
 you're saying below it sounds as though it works something like
 git-am.  If I'm understanding correctly you used it to apply the glibc
 deletion patch, and now you get this sanity failure (whereas you didn't
 get it immediately before applying the patch).  Is that right?

 I can't think of any reason why deleting the glibc recipes would cause
 the 32-bit header check to start failing, and that error certainly isn't
 happening for me.  If you revert the patch, does the failure go away?
 Have you verified that you really do have gnu/stubs-32.h installed in
 the appropriate place?

 p.

 On Thu, 2011-07-28 at 09:30 +0200, Samuel Stirtzel wrote:
 My current configuration was set up with the help of the Angstrom
 instructions [1], and I applied patches via the oebb.sh update
 command.
 Running Bitbake would show the following sanity error on any image / machine:

 samuel@S-Linux:/var/oe-core/setup-scripts$ bitbake console-image
 ERROR:  Poky's config sanity checker detected a potential misconfiguration.
     Either fix the cause of this error or at your own risk disable the
 checker (see sanity.conf).
     Following is the list of potential problems / advisories:

     You have a 32-bit libc, but no 32-bit headers.  You must install
 the 32-bit libc headers.

 ERROR: Execution of event handler 'check_sanity_eventhandler' failed


 For me it looks like an error with my configuration, but on the other
 side, before the update building images with bitbake worked.
 Well I don't know exactly if this is caused by the glibc deletion, but
 IMHO it seems very likely.
 Anyone else faced the same problem?

 Help would be very appreciated.

 Regards
 --Samuel

 [1] 
 http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-angstrom/tree/README

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



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


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

[OE-core] [PATCH 0/1] Fix bug #1299 for meta-environment

2011-07-28 Thread Lianhao Lu

Using recipe-scope variable REAL_MULTIMACH_TARGET_SYS instead of the unavailable
OLD_MULTIMACH_TARGET_SYS to generate meta-environment files for ADT installer.

The following changes since commit f94b781695cd8fa387daff16ecbf3987a0883018:
  Bruce Ashfield (1):
poky.conf: explicitly referenced preferred linux-yocto version

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib llu/bug1299
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=llu/bug1299

Lianhao Lu (1):
  meta-environment: set correct *MULTIMACH_TARGET_SYS.

 meta/classes/toolchain-scripts.bbclass |7 ---
 meta/recipes-core/meta/meta-environment.bb |9 +
 2 files changed, 9 insertions(+), 7 deletions(-)


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

Re: [OE-core] [PATCH] [PATCH] raptor: add recipe

2011-07-28 Thread Frans Meulenbroeks

2011/7/28 Ben Gardiner bengardi...@nanometrics.ca

 Signed-off-by: Frans Meulenbroeks fransmeulenbro...@gmail.com


Eh, yes and no.

I did write the original recipe and commited it on 14 aug 2010 with a
sign-off message.
As such this got my signoff, but I am not sure the signoff should be
repeated if this moved to oe-core.

My sign-off at that time is definitely not to be used as a suggestion it is
ok for oe-core (actually I feel this is not something for oe-core)

And (in reply to Koen), this recipe was tested by me for openembedded when I
submitted it. Afaik I have never build it with oe-core/meta-oe.
Reason to add it then was because flickcurl needed it (and I needed
flickcurl).

Frans.


 Signed-off-by: Ben Gardiner bengardi...@nanometrics.ca
 Signed-off-by: Tom Rini tom_r...@mentor.com

 This recipe is a port of recipes/raptor/raptor_1.4.21.bb from
 git://git.openembedded.org/openembedded, commits
 01e8e9f325d8d251e852e7a5704b5fe50880e1ad 'raptor: added recipe' and
 f1d24b5a986233f869364eb109476f5184e76d10 'raptor: add libxml2 DEPENDS'

 The recipe was modified by adding a LIC_FILES_CHKSUM assignment.

 Signed-off-by: Ben Gardiner bengardi...@nanometrics.ca

 ---

 Not tested in the oe-core + meta-openembedded et. al. layers. We are not
 ready yet to migrate from the 2011.03-maintenance branch. This patch is
 proposed for inclusion in oe-core so that we can meet the new policy
 requirements for inclusion in the 2011.03-maintenance branch and submit
 a subsequent pull-request for commit
 f1d24b5a986233f869364eb109476f5184e76d10 raptor: add libxml2 DEPENDS
 ---
  meta/recipes-support/raptor/raptor_1.4.21.bb |   13 +
  1 files changed, 13 insertions(+), 0 deletions(-)
  create mode 100644 meta/recipes-support/raptor/raptor_1.4.21.bb

 diff --git 
 a/meta/recipes-support/raptor/raptor_1.4.21.bbb/meta/recipes-support/raptor/
 raptor_1.4.21.bb
 new file mode 100644
 index 000..84fa69e
 --- /dev/null
 +++ b/meta/recipes-support/raptor/raptor_1.4.21.bb
 @@ -0,0 +1,13 @@
 +DESCRIPTION = Raptor RDF Parser Library
 +SECTION = libs
 +HOMEPAGE = http://librdf.org/raptor/;
 +LICENSE = LGPL 2.1/GPL 2/Apache 2.0
 +LIC_FILES_CHKSUM = file://COPYING;md5=751419260aa954499f7abaabaa882bbe
 +PR = r0
 +SRC_URI = http://download.librdf.org/source/raptor-${PV}.tar.gz;
 +DEPENDS = libxml2
 +
 +inherit autotools pkgconfig
 +
 +SRC_URI[md5sum] = 992061488af7a9e2d933df6b694bb876
 +SRC_URI[sha256sum] =
 db3172d6f3c432623ed87d7d609161973d2f7098e3d2233d0702fbcc22cfd8ca
 --
 1.7.4.1


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

Re: [OE-core] [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle

On Wed, 2011-07-27 at 15:34 +0100, Phil Blundell wrote:
 On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
  +PACKAGE_EXTRA_ARCHS_tune-armv4tb = ${PACKAGE_EXTRA_ARCHS_tune-armv4} 
  armv4tb
 
 That should be ${PACKAGE_EXTRA_ARCHS_tune-armv4b} armv4tb, I think.
 Otherwise you will get a mixture of big and little endian in there.

I think the equivalent big-endian definitions for v5 and v6 have this
problem too.  For example:

PACKAGE_EXTRA_ARCHS_tune-armv6b = ${PACKAGE_EXTRA_ARCHS_tune-armv5e-vfp} 
armv6b-vfp
PACKAGE_EXTRA_ARCHS_tune-armv6tb = ${PACKAGE_EXTRA_ARCHS_tune-armv5te-vfp} 
armv6b-vfp armv6tb-vfp

seems wrongish to me.  

p.



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

Re: [OE-core] [PATCH 1/1] combo-layer-tool: add tool to manipulate combo layers

Op 5 jul. 2011, om 18:28 heeft Paul Eggleton het volgende geschreven:

From: Yu Ke ke...@intel.com

This patch adds the script combo-layer to manipulate combo layer
repos. A combo layer repo is a repo containing multiple component
repos, e.g. oe-core, bitbake, BSP repos. The combo layer repo needs to
be updated by syncing with the component repo upstream. This script
is written to assist the combo layer handling.

The combo layer tool provides three functionalities:
- init: when the combo layer repo and component repo does not exist,
init will git init the combo layer repo, and also git clone the
component repos

- update: combo layer tool will pull the latest commit from component
repo upstream, and apply the commits since last update commit to the
combo repo. If the user specifies interactive mode(--interactive),
they can edit the patch list to select which commits to apply.

- splitpatch: split the combo repo commit into separate patches per
component repo, to facilitate upstream submission.

Combo layer tool uses a config file to define the component repo info.
Please check the combo-layer.conf.example for a detailed explanation
of the config file fields.

I've been playing with this script and I have a few remarks about it. First the
ones that aren't the fault of the script:

1) overlapping files like .gitignore breaks the script
2) git format-patch | git am is a lossy process, so you can't import oe-core
and bitbake from scratch:

[14:08:48] Apply
/Users/koen/Projects/Angstrom/setup-scripts/sources/combo-layer/patch-d99aaa2f-57f3-4c07-aac3-afc0538cae88/bitbake/0020-codeparser.py-Ignore-incomplete-cache-files.patch
[14:08:48] Applying: codeparser.py: Ignore incomplete cache files
error: patch failed: bitbake/lib/bb/codeparser.py:75
error: bitbake/lib/bb/codeparser.py: patch does not apply
Patch failed at 0001 codeparser.py: Ignore incomplete cache files
When you have resolved this problem run git am --resolved.
If you would prefer to skip this patch, instead run git am --skip.
To restore the original branch and stop patching run git am --abort.

3) rotating disks are slow when trying to apply a few thousand patches

As for the script I only have one real complaint: The inability to set branches
so you can make a combo layer based on non-master (e.g. release) branches.

For the rest it does what it says on the tin :)

regards,

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

Re: [OE-core] [PATCH 1/1] combo-layer-tool: add tool to manipulate combo layers

On Thu, 2011-07-28 at 14:11 +0200, Koen Kooi wrote:
 1) overlapping files like .gitignore breaks the script
 2) git format-patch | git am is a lossy process, so you can't import oe-core 
 and bitbake from scratch: 

Assuming I understand the intent correctly (which is by no means
certain), it sounds like maybe what you want for (2) is git-subtree.  I
agree that generating patches and piping them into git am sounds a bit
suboptimal for moving changesets from one place to another.

p.



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

[OE-core] [PATCH 1/7] lighttpd: Upgrade to 1.4.29

From: Zhai Edwin edwin.z...@intel.com

Signed-off-by: Zhai Edwin edwin.z...@intel.com
---
 .../{lighttpd_1.4.28.bb = lighttpd_1.4.29.bb} |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)
 rename meta/recipes-extended/lighttpd/{lighttpd_1.4.28.bb = 
lighttpd_1.4.29.bb} (90%)

diff --git a/meta/recipes-extended/lighttpd/lighttpd_1.4.28.bb 
b/meta/recipes-extended/lighttpd/lighttpd_1.4.29.bb
similarity index 90%
rename from meta/recipes-extended/lighttpd/lighttpd_1.4.28.bb
rename to meta/recipes-extended/lighttpd/lighttpd_1.4.29.bb
index d43766c..c1d5f81 100644
--- a/meta/recipes-extended/lighttpd/lighttpd_1.4.28.bb
+++ b/meta/recipes-extended/lighttpd/lighttpd_1.4.29.bb
@@ -18,14 +18,14 @@ RDEPENDS_${PN} +=  \
 
 PR = r0
 
-SRC_URI = 
http://download.lighttpd.net/lighttpd/releases-1.4.x/lighttpd-${PV}.tar.gz;name=src
 \
+SRC_URI = 
http://download.lighttpd.net/lighttpd/releases-1.4.x/lighttpd-${PV}.tar.bz2 \
 file://index.html \
 file://lighttpd.conf \
 file://lighttpd \
 
 
-SRC_URI[src.md5sum] = 202d36efc6324adb95a3600d2826ec6a
-SRC_URI[src.sha256sum] = 
efd7623f43182723b99c51d57a24158e22a207cd90dca35aaf3b2e3bac115712
+SRC_URI[md5sum] = e6e67b09986cb504db630b5a86b2dd76
+SRC_URI[sha256sum] = 
afd8af213e65afb48b397d004696c6620a7ae7f3d4f162ec46a04b9b9dbfd599
 
 EXTRA_OECONF =  \
  --without-bzip2 \
-- 
1.7.1


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

[OE-core] [PATCH 2/7] libsoup-2.4: Upgrade to 2.34.2

From: Zhai Edwin edwin.z...@intel.com

Signed-off-by: Zhai Edwin edwin.z...@intel.com
---
 ...libsoup-2.4_2.34.1.bb = libsoup-2.4_2.34.2.bb} |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-support/libsoup/{libsoup-2.4_2.34.1.bb = 
libsoup-2.4_2.34.2.bb} (76%)

diff --git a/meta/recipes-support/libsoup/libsoup-2.4_2.34.1.bb 
b/meta/recipes-support/libsoup/libsoup-2.4_2.34.2.bb
similarity index 76%
rename from meta/recipes-support/libsoup/libsoup-2.4_2.34.1.bb
rename to meta/recipes-support/libsoup/libsoup-2.4_2.34.2.bb
index f9e8de5..57af8f7 100644
--- a/meta/recipes-support/libsoup/libsoup-2.4_2.34.1.bb
+++ b/meta/recipes-support/libsoup/libsoup-2.4_2.34.2.bb
@@ -12,8 +12,8 @@ DEPENDS = glib-2.0 gnutls libxml2 libproxy sqlite3 
libgnome-keyring
 
 SRC_URI = ${GNOME_MIRROR}/libsoup/2.34/libsoup-${PV}.tar.bz2
 
-SRC_URI[md5sum] = 846779d898c11f97b5de28a79ea82254
-SRC_URI[sha256sum] = 
a2f846af2c4c08e15eacc9879c8c9be4d85f8105f960f96a9ba3dbabd9ee517b
+SRC_URI[md5sum] = 2454b38681a6e082b613a781a501e721
+SRC_URI[sha256sum] = 
1d70edc48c309528635012269733739f9cd22548913125864318a65d1b6f1261
 
 S = ${WORKDIR}/libsoup-${PV}
 
-- 
1.7.1


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

[OE-core] [PATCH 3/7] apr: Upgrade to 1.4.5

From: Zhai Edwin edwin.z...@intel.com

Remove buildconf_fix.patch as already in upstream.

Signed-off-by: Zhai Edwin edwin.z...@intel.com
---
 meta/recipes-support/apr/apr/buildconf_fix.patch   |   27 
 .../apr/{apr_1.4.2.bb = apr_1.4.5.bb} |9 +++---
 2 files changed, 5 insertions(+), 31 deletions(-)
 delete mode 100644 meta/recipes-support/apr/apr/buildconf_fix.patch
 rename meta/recipes-support/apr/{apr_1.4.2.bb = apr_1.4.5.bb} (85%)

diff --git a/meta/recipes-support/apr/apr/buildconf_fix.patch 
b/meta/recipes-support/apr/apr/buildconf_fix.patch
deleted file mode 100644
index 2c9d62e..000
--- a/meta/recipes-support/apr/apr/buildconf_fix.patch
+++ /dev/null
@@ -1,27 +0,0 @@
-Remove the new libtool detection method to avoid config failure. Poky's libtool
-has different format for aclocaldir, and there is no elegant parsing method,
-so fall back to old detection.
-
-Signed-off-by: Zhai Edwin edwin.z...@intel.com
-
-Upstream-Status: Inappropriate [configuration]
-
-Index: apr-1.4.2/buildconf
-===
 apr-1.4.2.orig/buildconf   2009-11-13 06:19:49.0 +0800
-+++ apr-1.4.2/buildconf2010-11-29 14:39:19.0 +0800
-@@ -50,14 +50,6 @@
- 
- if [ -f libtool.m4 ]; then 
-ltfile=`pwd`/libtool.m4
--elif grep all_pkgmacro_files $libtoolize  /dev/null; then
--# libtool 2.x
--   aclocal_dir=`sed -n '/^aclocaldir=/{s/.*=//;p;q;}'  $libtoolize`
--   ltfiles=`sed -n '/^all_pkgmacro_files=/{s/.*=//;;s///;p;q;}'  
$libtoolize`
--   for f in $ltfiles; do
--   test -f $aclocal_dir/$f  cp $aclocal_dir/$f build
--   done
--   ltfile=$aclocal_dir/libtool.m4
- else
-ltfindcmd=`sed -n \/=[^\\\`]/p;/libtool_m4=/{s/.*=/echo /p;q;}\ \
- $libtoolize`
diff --git a/meta/recipes-support/apr/apr_1.4.2.bb 
b/meta/recipes-support/apr/apr_1.4.5.bb
similarity index 85%
rename from meta/recipes-support/apr/apr_1.4.2.bb
rename to meta/recipes-support/apr/apr_1.4.5.bb
index 89bdadf..26a1818 100644
--- a/meta/recipes-support/apr/apr_1.4.2.bb
+++ b/meta/recipes-support/apr/apr_1.4.5.bb
@@ -11,11 +11,10 @@ PR = r0
 SRC_URI = ${APACHE_MIRROR}/apr/${P}.tar.bz2 \
file://configure_fixes.patch;patch=1 \
   file://cleanup.patch;patch=1 \
-   file://configfix.patch;patch=1 \
-   file://buildconf_fix.patch;patch=1
+   file://configfix.patch;patch=1
 
-SRC_URI[md5sum] = 4b00e8f70c067893d075577962656b35
-SRC_URI[sha256sum] = 
2017ca700694d09d2b0b21dd7c4d195e43a48735aac88526160c6195ee8f5391
+SRC_URI[md5sum] = 8b53f5a5669d0597f2da889a2f576eb6
+SRC_URI[sha256sum] = 
38c61cacb39be649411cdab212979c71ce29495549c249c2e9a1b0d12480c93e
 
 inherit autotools lib_package binconfig
 
@@ -26,6 +25,8 @@ do_configure_prepend() {
./buildconf
 }
 
+FILES_${PN}-dev += ${libdir}/apr.exp ${datadir}/build-1/*
+
 #for some reason, build/libtool.m4 handled by buildconf still be overwritten
 #when autoconf, so handle it again.
 do_configure_append() {
-- 
1.7.1


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

[OE-core] [PATCH 6/7] gpgme: Upgrade to 1.3.1

From: Zhai Edwin edwin.z...@intel.com

Signed-off-by: Zhai Edwin edwin.z...@intel.com
---
 .../disable_gpgconf_check.patch|0
 .../gpgme/{gpgme_1.3.0.bb = gpgme_1.3.1.bb}   |8 
 2 files changed, 4 insertions(+), 4 deletions(-)
 rename meta/recipes-support/gpgme/{gpgme-1.3.0 = 
gpgme-1.3.1}/disable_gpgconf_check.patch (100%)
 rename meta/recipes-support/gpgme/{gpgme_1.3.0.bb = gpgme_1.3.1.bb} (78%)

diff --git a/meta/recipes-support/gpgme/gpgme-1.3.0/disable_gpgconf_check.patch 
b/meta/recipes-support/gpgme/gpgme-1.3.1/disable_gpgconf_check.patch
similarity index 100%
rename from meta/recipes-support/gpgme/gpgme-1.3.0/disable_gpgconf_check.patch
rename to meta/recipes-support/gpgme/gpgme-1.3.1/disable_gpgconf_check.patch
diff --git a/meta/recipes-support/gpgme/gpgme_1.3.0.bb 
b/meta/recipes-support/gpgme/gpgme_1.3.1.bb
similarity index 78%
rename from meta/recipes-support/gpgme/gpgme_1.3.0.bb
rename to meta/recipes-support/gpgme/gpgme_1.3.1.bb
index 4c45a44..64b6ea2 100644
--- a/meta/recipes-support/gpgme/gpgme_1.3.0.bb
+++ b/meta/recipes-support/gpgme/gpgme_1.3.1.bb
@@ -5,14 +5,14 @@ BUGTRACKER = https://bugs.g10code.com/gnupg/index;
 LICENSE = GPLv2+  LGPLv2.1+
 LIC_FILES_CHKSUM = file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
 file://COPYING.LESSER;md5=bbb461211a33b134d42ed5ee802b37ff 
\
-
file://src/gpgme.h;endline=23;md5=2775a99d3dd524c4f848ff1c59093038 \
+
file://src/gpgme.h.in;endline=23;md5=942b47052c0674c6a3b9b9e6127628a4 \
 
file://src/engine.h;endline=22;md5=e96acfaab1cff82dd8fbefddd2f5c436
 
 SRC_URI = ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-${PV}.tar.bz2 \
file://disable_gpgconf_check.patch;patch=1;pnum=1
 
-SRC_URI[md5sum] = 4784e3c6086c9c25e9a1b4d9f7c5aa96
-SRC_URI[sha256sum] = 
74e040fcd46061f6b0d8b621a2a2a48100a7ba5c9f69e7cf207259a6e2e3e6a1
+SRC_URI[md5sum] = 90afa8436ce2b2683c001c824bd22601
+SRC_URI[sha256sum] = 
15ef27a875ae0d79d7446fd931deda11438e724ffbeac74449ed19cba23df4d4
 DEPENDS = libgpg-error libassuan pth
 PR = r0
 
@@ -25,4 +25,4 @@ PACKAGES =+ ${PN}-pth ${PN}-pthread
 FILES_${PN}-pth = ${libdir}/libgpgme-pth.so.*
 FILES_${PN}-pthread = ${libdir}/libgpgme-pthread.so.*
 FILES_${PN} = ${libdir}/libgpgme.so.*
-FILES_${PN}-dev += ${bindir}/gpgme-config
+FILES_${PN}-dev += ${bindir}/gpgme-config 
${datadir}/common-lisp/source/gpgme/*
-- 
1.7.1


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

[OE-core] [PATCH 7/7] parted: Upgrade to 3.0

From: Zhai Edwin edwin.z...@intel.com

Signed-off-by: Zhai Edwin edwin.z...@intel.com
---
 .../{parted-2.3 = parted-3.0}/no_check.patch  |0
 .../{parted-2.3 = parted-3.0}/syscalls.patch  |0
 .../parted/{parted_2.3.bb = parted_3.0.bb}|4 ++--
 3 files changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-extended/parted/{parted-2.3 = parted-3.0}/no_check.patch 
(100%)
 rename meta/recipes-extended/parted/{parted-2.3 = parted-3.0}/syscalls.patch 
(100%)
 rename meta/recipes-extended/parted/{parted_2.3.bb = parted_3.0.bb} (78%)

diff --git a/meta/recipes-extended/parted/parted-2.3/no_check.patch 
b/meta/recipes-extended/parted/parted-3.0/no_check.patch
similarity index 100%
rename from meta/recipes-extended/parted/parted-2.3/no_check.patch
rename to meta/recipes-extended/parted/parted-3.0/no_check.patch
diff --git a/meta/recipes-extended/parted/parted-2.3/syscalls.patch 
b/meta/recipes-extended/parted/parted-3.0/syscalls.patch
similarity index 100%
rename from meta/recipes-extended/parted/parted-2.3/syscalls.patch
rename to meta/recipes-extended/parted/parted-3.0/syscalls.patch
diff --git a/meta/recipes-extended/parted/parted_2.3.bb 
b/meta/recipes-extended/parted/parted_3.0.bb
similarity index 78%
rename from meta/recipes-extended/parted/parted_2.3.bb
rename to meta/recipes-extended/parted/parted_3.0.bb
index 14c9c25..29daf01 100644
--- a/meta/recipes-extended/parted/parted_2.3.bb
+++ b/meta/recipes-extended/parted/parted_3.0.bb
@@ -10,8 +10,8 @@ SRC_URI = ${GNU_MIRROR}/parted/parted-${PV}.tar.gz \
file://no_check.patch \
file://syscalls.patch 
 
-SRC_URI[md5sum] = 30ceb6df7e8681891e865e2fe5a7903d
-SRC_URI[sha256sum] = 
e81fa140805b5cd029ff6dda5cfa94d223e83ac182ebcae94f841d62ce468829
+SRC_URI[md5sum] = a94e84a9b9944715c4453f82ccc639bf
+SRC_URI[sha256sum] = 
8886eece015202f6bd5ce8414f4b68838452cef509f2e3389ad56128219837b7
 
 EXTRA_OECONF = --disable-Werror --disable-device-mapper
 
-- 
1.7.1


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

[OE-core] [PATCH] scripts/oe-buildenv-internal: Add SOCKS5_{USER, PASSWD} to BB_ENV_EXTRAWHITE

If a SOCKS5 gateway is needed for a proxy access like git it might also
require authentication to the proxy via a password and username.  Adding
SOCKS5_USER  SOCKS5_PASSWD to BB_ENV_EXTRAWHITE allow for automation
of the authentication request to occur when something like a git fetch
is going through the proxy.

Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
* Fixes issue with a git fetch request failing to get pass a firewall

 scripts/oe-buildenv-internal |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/scripts/oe-buildenv-internal b/scripts/oe-buildenv-internal
index c13fc40..b223292 100755
--- a/scripts/oe-buildenv-internal
+++ b/scripts/oe-buildenv-internal
@@ -55,4 +55,4 @@ unset BITBAKEDIR
 export BUILDDIR
 export PATH
 
-export BB_ENV_EXTRAWHITE=MACHINE DISTRO TCMODE TCLIBC http_proxy ftp_proxy 
https_proxy all_proxy ALL_PROXY no_proxy SSH_AGENT_PID SSH_AUTH_SOCK 
BB_SRCREV_POLICY SDKMACHINE BB_NUMBER_THREADS PARALLEL_MAKE GIT_PROXY_COMMAND
+export BB_ENV_EXTRAWHITE=MACHINE DISTRO TCMODE TCLIBC http_proxy ftp_proxy 
https_proxy all_proxy ALL_PROXY no_proxy SSH_AGENT_PID SSH_AUTH_SOCK 
BB_SRCREV_POLICY SDKMACHINE BB_NUMBER_THREADS PARALLEL_MAKE GIT_PROXY_COMMAND 
SOCKS5_PASSWD SOCSK5_USER
-- 
1.7.3.4


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

Re: [OE-core] [PATCH 1/1] combo-layer-tool: add tool to manipulate combo layers

On Thursday 28 July 2011 13:11:00 Koen Kooi wrote:
 I've been playing with this script and I have a few remarks about it. First
 the ones that aren't the fault of the script:
 
 1) overlapping files like .gitignore breaks the script

This can be a problem, yes. However if you know about these sorts of conflicts 
ahead of time you can mitigate them by adding the appropriate logic to a hook 
script (which can filter out stuff from the patches as they pass through).

 2) git format-patch | git am is a lossy process, so you can't import
 oe-core and bitbake from scratch:
 
   [14:08:48] Apply
 /Users/koen/Projects/Angstrom/setup-scripts/sources/combo-layer/patch-d99a
 aa2f-57f3-4c07-aac3-afc0538cae88/bitbake/0020-codeparser.py-Ignore-incomple
 te-cache-files.patch [14:08:48] Applying: codeparser.py: Ignore incomplete
 cache files error: patch failed: bitbake/lib/bb/codeparser.py:75
   error: bitbake/lib/bb/codeparser.py: patch does not apply
   Patch failed at 0001 codeparser.py: Ignore incomplete cache files
   When you have resolved this problem run git am --resolved.
   If you would prefer to skip this patch, instead run git am --skip.
   To restore the original branch and stop patching run git am --abort.

Perhaps I'm being thick, but what's the reason for this failing?
 
 3) rotating disks are slow when trying to apply a few thousand patches

I think this is kind of the fault of the script in that it's the default 
behaviour - frankly I never expected anyone to use combo-layer to build a 
combined repo from scratch dragging across the entire history. Ideally you 
would begin from an existing repository that you had manually combined 
together, and combo-layer is the way of keeping it up-to-date after that 
point. We could easily automate the initial creation within the script if 
people think it's useful - I did think about doing that but I figured it's not 
something you expect to do very often.

 As for the script I only have one real complaint: The inability to set
 branches so you can make a combo layer based on non-master (e.g. release)
 branches.

Agreed, this is an omission, shouldn't be too difficult to fix though. It's on 
my 
todo list, feel free to submit a patch if you want it fixed faster ;)

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

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

[OE-core] [PATCH 5/7] libassuan: Upgrade to 2.0.2

From: Zhai Edwin edwin.z...@intel.com

Signed-off-by: Zhai Edwin edwin.z...@intel.com
---
 .../{libassuan_2.0.1.bb = libassuan_2.0.2.bb} |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-support/libassuan/{libassuan_2.0.1.bb = 
libassuan_2.0.2.bb} (82%)

diff --git a/meta/recipes-support/libassuan/libassuan_2.0.1.bb 
b/meta/recipes-support/libassuan/libassuan_2.0.2.bb
similarity index 82%
rename from meta/recipes-support/libassuan/libassuan_2.0.1.bb
rename to meta/recipes-support/libassuan/libassuan_2.0.2.bb
index 5425673..53c1230 100644
--- a/meta/recipes-support/libassuan/libassuan_2.0.1.bb
+++ b/meta/recipes-support/libassuan/libassuan_2.0.2.bb
@@ -12,7 +12,7 @@ DEPENDS = libgpg-error
 
 SRC_URI = ftp://ftp.gnupg.org/gcrypt/libassuan/libassuan-${PV}.tar.bz2;
 
-SRC_URI[md5sum] = 53a7d4c22af909d7236d17d454ef935b
-SRC_URI[sha256sum] = 
1117be532ac41b13790b4756df7fa747d3d04264f7b4544aa9d7ff468a24b457
+SRC_URI[md5sum] = 3e7d00fd2ee8a0b9c51ac7616ef3f1ec
+SRC_URI[sha256sum] = 
61e0cba33dcbade2dce953b95f06b843af2a73de875303f2585227ecd475b4d8
 
 inherit autotools binconfig
-- 
1.7.1


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

Re: [OE-core] [PATCH 1/1] combo-layer-tool: add tool to manipulate combo layers


Op 28 jul. 2011, om 15:00 heeft Paul Eggleton het volgende geschreven:

 On Thursday 28 July 2011 13:11:00 Koen Kooi wrote:
 I've been playing with this script and I have a few remarks about it. First
 the ones that aren't the fault of the script:
 
 1) overlapping files like .gitignore breaks the script
 
 This can be a problem, yes. However if you know about these sorts of 
 conflicts 
 ahead of time you can mitigate them by adding the appropriate logic to a hook 
 script (which can filter out stuff from the patches as they pass through).

Is that a hook in git or the combo script?

 
 2) git format-patch | git am is a lossy process, so you can't import
 oe-core and bitbake from scratch:
 
  [14:08:48] Apply
 /Users/koen/Projects/Angstrom/setup-scripts/sources/combo-layer/patch-d99a
 aa2f-57f3-4c07-aac3-afc0538cae88/bitbake/0020-codeparser.py-Ignore-incomple
 te-cache-files.patch [14:08:48] Applying: codeparser.py: Ignore incomplete
 cache files error: patch failed: bitbake/lib/bb/codeparser.py:75
  error: bitbake/lib/bb/codeparser.py: patch does not apply
  Patch failed at 0001 codeparser.py: Ignore incomplete cache files
  When you have resolved this problem run git am --resolved.
  If you would prefer to skip this patch, instead run git am --skip.
  To restore the original branch and stop patching run git am --abort.
 
 Perhaps I'm being thick, but what's the reason for this failing?

I don't know, I had a number of strange failures, which I blame the 
format-patch | am construct for. Git sucks for non-Linus workflows, we just 
have to live with that.

 3) rotating disks are slow when trying to apply a few thousand patches
 
 I think this is kind of the fault of the script in that it's the default 
 behaviour - frankly I never expected anyone to use combo-layer to build a 
 combined repo from scratch dragging across the entire history. Ideally you 
 would begin from an existing repository that you had manually combined 
 together, and combo-layer is the way of keeping it up-to-date after that 
 point. We could easily automate the initial creation within the script if 
 people think it's useful - I did think about doing that but I figured it's 
 not 
 something you expect to do very often.

With my distro maintainer hat on, I wouldn't use a combined repo for my 
day-to-day development setup, but I would hand it to my downstream users. The 
use-case I was trying to use it for is to create a git snapshot for a release 
where everything is in one place.

The current result: https://github.com/koenkooi/Angstrom-integration-layer

It is missing the angstrom buildscripts and config files, but it's a start.

Phil mentioned subtree, which is also worth looking at:

https://github.com/apenwarr/git-subtree

regards,

Koen



 
 As for the script I only have one real complaint: The inability to set
 branches so you can make a combo layer based on non-master (e.g. release)
 branches.
 
 Agreed, this is an omission, shouldn't be too difficult to fix though. It's 
 on my 
 todo list, feel free to submit a patch if you want it fixed faster ;)
 
 Cheers,
 Paul
 
 -- 
 
 Paul Eggleton
 Intel Open Source Technology Centre


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

Re: [OE-core] [PATCH 1/1] combo-layer-tool: add tool to manipulate combo layers

On Thursday 28 July 2011 14:15:55 Koen Kooi wrote:
 Is that a hook in git or the combo script?

The combo script. The sample config file has an example of how to configure one 
(as well as an example hook script that adds origin commit IDs).
 
 With my distro maintainer hat on, I wouldn't use a combined repo for my
 day-to-day development setup, but I would hand it to my downstream users.
 The use-case I was trying to use it for is to create a git snapshot for a
 release where everything is in one place.

This is definitely the kind of thing combo-layer is useful for.

 Phil mentioned subtree, which is also worth looking at:
 
 https://github.com/apenwarr/git-subtree

I've looked at it in the past but not tried it, must have a proper test soon.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

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

Re: [OE-core] [PATCH] [PATCH] raptor: add recipe

2011-07-28 Thread Frans Meulenbroeks

2011/7/28 Ben Gardiner bengardi...@nanometrics.ca

Hi Koen, Frans,

On Thu, Jul 28, 2011 at 6:48 AM, Koen Kooi k...@dominion.thruhere.net
wrote:

Op 28 jul. 2011, om 05:38 heeft Ben Gardiner het volgende geschreven:

Signed-off-by: Frans Meulenbroeks fransmeulenbro...@gmail.com
Signed-off-by: Ben Gardiner bengardi...@nanometrics.ca
Signed-off-by: Tom Rini tom_r...@mentor.com

This recipe is a port of recipes/raptor/raptor_1.4.21.bb from
git://git.openembedded.org/openembedded, commits
01e8e9f325d8d251e852e7a5704b5fe50880e1ad 'raptor: added recipe' and
f1d24b5a986233f869364eb109476f5184e76d10 'raptor: add libxml2 DEPENDS'

Why does this need to be in OE-core and not in some other layer? It
doesn't look so core to me, especially since nothing in oe-core (or
meta-oe/efl/gnome for that matter) depends on it

Because oe-core's meta/recipes-support (naively) seemed like a
reasonable place for it. I would be happy to re-spin the patch for
locating it in any layer. Please advise me.

oe-core is only for core recipes. Not sure about the exact definition, but I
suspect it is something like recipes that (virtually) everybody needs.
I'm not sure about layer policies, but maybe this could go to meta-oe.

It's true that nothing depends on it. As Frans mentions later it's
only dependent in oe.dev is flickrcurl. Raptor is both a library and a
utility; we use the latter so raptor itself is a dependency of our
images.

The recipe was modified by adding a LIC_FILES_CHKSUM assignment.

Signed-off-by: Ben Gardiner bengardi...@nanometrics.ca

---

Not tested in the oe-core + meta-openembedded et. al. layers.

I'm sorry for the confusion -- this recipe is/was tested in oe.dev and
2011.03-maintenance branches.

I'd say that before submitting you should as a minimum test that it builds
properly in the layer you are submitting it (so e.g. we're sure all depends
are there).

So why are you sending it if it isn't tested?

We are not
ready yet to migrate from the 2011.03-maintenance branch. This patch is
proposed for inclusion in oe-core so that we can meet the new policy
requirements for inclusion in the 2011.03-maintenance branch

Where does it say it's OK to do a pull request for untested recipes? And
where does it say it needs to be in OE-core first?

My understanding of Tom's post to the oe.dev mailing list is that
commits in pull-requests for 2011.03 need to first be oe-core or one
of its layers.

No idea here.
But why would add a patch for LIC_FILES_CHECKSUM in the maintenance tree.
If I recall correctly those are not needed in 2011.03 (but if it is and it
is missing from the recipe, I think it should be added, if not, probably
leave the recipe as is).

In Message-ID: 4dfa7108.5020...@mentor.com On Thu, Jun 16, 2011 at
5:09 PM, Tom Rini tom_r...@mentor.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all,

As part of this weeks TSC meeting, an agenda item was brought up about
the 2011.03-maintenance branch and oe-core / etc. I have now updated
the policy about where changes need to be before they can be included in
2011.03-maintenance to include being in oe-core / meta-oe or other
relevant public layer instead of being only in the oe.dev master branch.
This is not a policy change, but a clarification of what was there
previously. Thanks all!

On Thu, Jul 28, 2011 at 7:29 AM, Frans Meulenbroeks
fransmeulenbro...@gmail.com wrote:

2011/7/28 Ben Gardiner bengardi...@nanometrics.ca

Signed-off-by: Frans Meulenbroeks fransmeulenbro...@gmail.com

Eh, yes and no.

I did write the original recipe and commited it on 14 aug 2010 with a
sign-off message.
As such this got my signoff, but I am not sure the signoff should be
repeated if this moved to oe-core.

Fair enough. It is your Sign-off to give or take.

I was following the patch message guidelines. Example: Importaing
from Elsewhere Modified in particular:

http://wiki.openembedded.org/index.php/Commit_Patch_Message_Guidelines#Example:_Importing_from_Elsewhere_Modified

Ah ok, Those guidelines are fairly new and I was not too aware of them. If
it is in accordance with the guidelines it is fine with me to keep them.
I was mainly triggered by the signed-off lines at the beginning of your
message (which I don't think are in accordance to the above mentioned
guidelines).
The only concern I have is that the sign-off would be interpreted as my
blessing for this patch in oe-core. If it only is used as an indicator of
the origin or as a statement that I released and was entitled to release the
original stuff, that is ok (as that is still appropriate).

I will remove your Sign-off in v2.

My sign-off at that time is definitely not to be used as a suggestion it
is
ok for oe-core (actually I feel this is not something for oe-core)

Understood -- I am happy to re-spin for inclusion in any layer. Please
advise.

Best Regards,
Ben Gardiner

---

Re: [OE-core] [PATCH] [PATCH] raptor: add recipe

Hi Frans,

On Thu, Jul 28, 2011 at 9:52 AM, Frans Meulenbroeks
fransmeulenbro...@gmail.com wrote:

2011/7/28 Ben Gardiner bengardi...@nanometrics.ca

Hi Koen, Frans,

On Thu, Jul 28, 2011 at 6:48 AM, Koen Kooi k...@dominion.thruhere.net
wrote:

Op 28 jul. 2011, om 05:38 heeft Ben Gardiner het volgende geschreven:

Signed-off-by: Frans Meulenbroeks fransmeulenbro...@gmail.com
Signed-off-by: Ben Gardiner bengardi...@nanometrics.ca
Signed-off-by: Tom Rini tom_r...@mentor.com

Why does this need to be in OE-core and not in some other layer? It
doesn't look so core to me, especially since nothing in oe-core (or
meta-oe/efl/gnome for that matter) depends on it

Because oe-core's meta/recipes-support (naively) seemed like a
reasonable place for it. I would be happy to re-spin the patch for
locating it in any layer. Please advise me.

Ok -- I suppose not everybody needs to parse RDF in various serialized
representations :)

V2 will be targetted to meta-oe, thanks.

The recipe was modified by adding a LIC_FILES_CHKSUM assignment.

Signed-off-by: Ben Gardiner bengardi...@nanometrics.ca

---

Not tested in the oe-core + meta-openembedded et. al. layers.

I'm sorry for the confusion -- this recipe is/was tested in oe.dev and
2011.03-maintenance branches.

I'd say that before submitting you should as a minimum test that it builds
properly in the layer you are submitting it (so e.g. we're sure all depends
are there).

So why are you sending it if it isn't tested?

Where does it say it's OK to do a pull request for untested recipes? And
where does it say it needs to be in OE-core first?

My understanding of Tom's post to the oe.dev mailing list is that
commits in pull-requests for 2011.03 need to first be oe-core or one
of its layers.

Well, I would not submit _this_ patch for pull-request. I was hoping
to get this version of raptor included and then submit a pull-request
for a cherry-pick of the patch to add libxml2 to DEPENDS.

On Wed, Jul 27, 2011 at 11:38 PM, Ben Gardiner
bengardi...@nanometrics.ca wrote:
This patch is
proposed for inclusion in oe-core so that we can meet the new policy
requirements for inclusion in the 2011.03-maintenance branch and submit
a subsequent pull-request for commit
f1d24b5a986233f869364eb109476f5184e76d10 raptor: add libxml2 DEPENDS

In Message-ID: 4dfa7108.5020...@mentor.com On Thu, Jun 16, 2011 at
5:09 PM, Tom Rini tom_r...@mentor.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all,

On Thu, Jul 28, 2011 at 7:29 AM, Frans Meulenbroeks
fransmeulenbro...@gmail.com wrote:

2011/7/28 Ben Gardiner bengardi...@nanometrics.ca

Signed-off-by: Frans Meulenbroeks fransmeulenbro...@gmail.com

Eh, yes and no.

I did write the original recipe and commited it on 14 aug 2010 with a
sign-off message.
As such this got my signoff, but I am not sure the signoff should be
repeated if this moved to oe-core.

Fair enough. It is your Sign-off to give or take.

I was following the patch message guidelines. Example: Importaing
from Elsewhere Modified in particular:

http://wiki.openembedded.org/index.php/Commit_Patch_Message_Guidelines#Example:_Importing_from_Elsewhere_Modified

Ah ok, Those guidelines are fairly new and I was not too aware of them. If
it is in accordance with

[OE-core] lib vs lib64?

With recent multilib changes for a pure 64-bit target (no multilib) should 
things be in /lib or /lib64?

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

[OE-core] [PATCH 0/1] Fix PACKAGE_EXTRA_ARCHS

Here's a fix as discussed for the PACKAGE_EXTRA_ARCHS issue since the
tune file changes. It may not be the proper fix but it does at least it
makes the value of this variable correct again.

The following changes since commit 1fe892ab6876c405599c79657221a8b4675b6ecf:

  Update TERMCMD message to align with previous change (2011-07-27 17:43:27 
+0100)

are available in the git repository at:
  git://git.openembedded.org/openembedded-core-contrib paule/core-pkgarch-fix
  
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/core-pkgarch-fix

Paul Eggleton (1):
  bitbake.conf: remove PACKAGE_EXTRA_ARCHS_tune-XXX default

 meta/conf/bitbake.conf |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

-- 
1.7.4.1


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

[OE-core] [PATCH 1/1] bitbake.conf: remove PACKAGE_EXTRA_ARCHS_tune-XXX default

Because of the way BitBake handles ??= under certain circumstances, this
default setting ends up stepping all over the real setting from the arch
include file. Since virtually all arch include files or tune files define
a real value for this we shouldn't need to have a default (or it needs to
be done in a different way).

Signed-off-by: Paul Eggleton paul.eggle...@linux.intel.com
---
 meta/conf/bitbake.conf |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 6e109ec..9c80f11 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -84,7 +84,6 @@ HOST_EXEEXT = 
 TUNE_ARCH ??= INVALID
 TUNE_CCARGS ??= 
 TUNE_FEATURES ??= ${TUNE_FEATURES_tune-${DEFAULTTUNE}}
-PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} ??= ${TARGET_ARCH}
 LIBCEXTENSION ??= 
 ABIEXTENSION ??= 
 
-- 
1.7.4.1


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

Re: [OE-core] lib vs lib64?

On Thu, 2011-07-28 at 09:15 -0500, Kumar Gala wrote:
 With recent multilib changes for a pure 64-bit target (no multilib) should 
 things be in /lib or /lib64?

They should be in ${base_libdir}.  Whether that's /lib or /lib64 is a
DISTRO choice I suppose.

p.



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

Re: [OE-core] [PATCH] [PATCH] raptor: add recipe

2011-07-28 Thread Frans Meulenbroeks

2011/7/28 Ben Gardiner bengardi...@nanometrics.ca



 Well, I would not submit _this_ patch for pull-request. I was hoping
 to get this version of raptor included and then submit a pull-request
 for a cherry-pick of the patch to add libxml2 to DEPENDS.


Ah, missed that you also added libxml2.
Not sure about the policies of the maintenance branch, but I suspect the
proper way would be to fix and test in openembedded then submit a pull
request.
Then again maybe the policies for the maintenance branch are different.

[...]

 
 http://wiki.openembedded.org/index.php/Commit_Patch_Message_Guidelines#Example:_Importing_from_Elsewhere_Modified
 
  Ah ok, Those guidelines are fairly new and I was not too aware of them.
 If
  it is in accordance with the guidelines it is fine with me to keep them.
  I was mainly triggered by the signed-off lines at the beginning of your
  message (which I don't think are in accordance to the above mentioned
  guidelines).


 Oh. I thought they were [in accordance]. I guess there would usually
 be a commit body before the initial Signed-off-by:'s ; however, there
 was no original commit body to preserve.


Ah ok, understood.
Actually, I guess we should preserve the first line of the commit too.
This is what git log says:

frans@frans-desktop:~/workspace/openembedded/recipes/raptor$ git log *
commit 01e8e9f325d8d251e852e7a5704b5fe50880e1ad
Author: Frans Meulenbroeks fransmeulenbro...@gmail.com
Date:   Sat Aug 14 21:27:49 2010 +0200

raptor: added recipe

Signed-off-by: Frans Meulenbroeks fransmeulenbro...@gmail.com



Best regards, Frans.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] mpc8315e-rdb core-image-minimal fails

Anyone got any ideas about the following:

| ERROR: Function 'do_rootfs' failed (see 
/local/home/galak/git/poky/build/tmp/work/mpc8315e_rdb-poky-linux/core-image-minimal-1.0-r0/temp/log.do_rootfs.19834
 for fu
rther information)
| Generating solve db for 
/local/home/galak/git/poky/build/tmp/deploy/rpm/mpc8315e_rdb...
|total:   1  0.00 MB  1.573137 secs
|fingerprint:   816  0.004148 MB  0.062215 secs
|install:   272  0.00 MB  0.384963 secs
|dbadd: 272  0.00 MB  0.375238 secs
|dbget:  0.00 MB  0.003093 secs
|dbput: 272  1.315744 MB  0.302582 secs
|readhdr:  2721  2.573624 MB  0.178385 secs
|hdrload:  1360  3.828344 MB  0.007262 secs
|hdrget:  49259  0.00 MB  0.048944 secs
| Generating solve db for /local/home/galak/git/poky/build/tmp/deploy/rpm/all...
|total:   1  0.00 MB  0.29 secs
|fingerprint:18  0.24 MB  0.000280 secs
|install: 6  0.00 MB  0.044466 secs
|dbadd:   6  0.00 MB  0.039504 secs
|dbget:  19  0.00 MB  0.000103 secs
|dbput:   6  0.018916 MB  0.006250 secs
|readhdr:61  0.038096 MB  0.000212 secs
|hdrload:33  0.063864 MB  0.000327 secs
|hdrget:983  0.00 MB  0.001306 secs
| Generating solve db for /local/home/galak/git/poky/build/tmp/deploy/rpm/all...
| Processing task-core-boot...
| error: Failed dependencies:
|   tinylogin is needed by task-core-boot-1.0-r7.mpc8315e_rdb
|   busybox is needed by task-core-boot-1.0-r7.mpc8315e_rdb
|   modutils-initscripts is needed by task-core-boot-1.0-r7.mpc8315e_rdb
|   initscripts is needed by task-core-boot-1.0-r7.mpc8315e_rdb
|   update-alternatives-cworth is needed by 
task-core-boot-1.0-r7.mpc8315e_rdb
|   udev is needed by task-core-boot-1.0-r7.mpc8315e_rdb
|   sysvinit is needed by task-core-boot-1.0-r7.mpc8315e_rdb
|   netbase is needed by task-core-boot-1.0-r7.mpc8315e_rdb
|   base-passwd is needed by task-core-boot-1.0-r7.mpc8315e_rdb
|   console-tools is needed by keymaps-1.0-r19.mpc8315e_rdb
|   initscripts is needed by keymaps-1.0-r19.mpc8315e_rdb
|   /bin/sh is needed by keymaps-1.0-r19.mpc8315e_rdb
NOTE: package core-image-minimal-1.0-r0: task do_rootfs: Failed
ERROR: Task 8 
(/local/home/galak/git/poky/meta/recipes-core/images/core-image-minimal.bb, 
do_rootfs) failed with exit code '1'
ERROR: 
'/local/home/galak/git/poky/meta/recipes-core/images/core-image-minimal.bb' 
failed

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

Re: [OE-core] [PATCH 1/1] bitbake.conf: remove PACKAGE_EXTRA_ARCHS_tune-XXX default


On Jul 28, 2011, at 9:18 AM, Paul Eggleton wrote:

 Because of the way BitBake handles ??= under certain circumstances, this
 default setting ends up stepping all over the real setting from the arch
 include file. Since virtually all arch include files or tune files define
 a real value for this we shouldn't need to have a default (or it needs to
 be done in a different way).
 
 Signed-off-by: Paul Eggleton paul.eggle...@linux.intel.com
 ---
 meta/conf/bitbake.conf |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

Acked-by: Kumar Gala ga...@kernel.crashing.org

- k

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

Re: [OE-core] [PATCH] [PATCH] raptor: add recipe

Hi Koen, Frans,

On Thu, Jul 28, 2011 at 6:48 AM, Koen Kooi k...@dominion.thruhere.net wrote:

 Op 28 jul. 2011, om 05:38 heeft Ben Gardiner het volgende geschreven:

 Signed-off-by: Frans Meulenbroeks fransmeulenbro...@gmail.com
 Signed-off-by: Ben Gardiner bengardi...@nanometrics.ca
 Signed-off-by: Tom Rini tom_r...@mentor.com

 This recipe is a port of recipes/raptor/raptor_1.4.21.bb from
 git://git.openembedded.org/openembedded, commits
 01e8e9f325d8d251e852e7a5704b5fe50880e1ad 'raptor: added recipe' and
 f1d24b5a986233f869364eb109476f5184e76d10 'raptor: add libxml2 DEPENDS'

 Why does this need to be in OE-core and not in some other layer? It doesn't 
 look so core to me, especially since nothing in oe-core (or meta-oe/efl/gnome 
 for that matter) depends on it

Because oe-core's meta/recipes-support (naively) seemed like a
reasonable place for it. I would be happy to re-spin the patch for
locating it in any layer. Please advise me.

It's true that nothing depends on it. As Frans mentions later it's
only dependent in oe.dev is flickrcurl. Raptor is both a library and a
utility; we use the latter so raptor itself is a dependency of our
images.


 The recipe was modified by adding a LIC_FILES_CHKSUM assignment.

 Signed-off-by: Ben Gardiner bengardi...@nanometrics.ca

 ---

 Not tested in the oe-core + meta-openembedded et. al. layers.

I'm sorry for the confusion -- this recipe is/was tested in oe.dev and
2011.03-maintenance branches.

 So why are you sending it if it isn't tested?

 We are not
 ready yet to migrate from the 2011.03-maintenance branch. This patch is
 proposed for inclusion in oe-core so that we can meet the new policy
 requirements for inclusion in the 2011.03-maintenance branch

 Where does it say it's OK to do a pull request for untested recipes? And 
 where does it say it needs to be in OE-core first?

My understanding of Tom's post to the oe.dev mailing list is that
commits in pull-requests for 2011.03 need to first be oe-core or one
of its layers.

In Message-ID: 4dfa7108.5020...@mentor.com On Thu, Jun 16, 2011 at
5:09 PM, Tom Rini tom_r...@mentor.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi all,

 As part of this weeks TSC meeting, an agenda item was brought up about
 the 2011.03-maintenance branch and oe-core / etc.  I have now updated
 the policy about where changes need to be before they can be included in
 2011.03-maintenance to include being in oe-core / meta-oe or other
 relevant public layer instead of being only in the oe.dev master branch.
  This is not a policy change, but a clarification of what was there
 previously.  Thanks all!


On Thu, Jul 28, 2011 at 7:29 AM, Frans Meulenbroeks
fransmeulenbro...@gmail.com wrote:


 2011/7/28 Ben Gardiner bengardi...@nanometrics.ca

 Signed-off-by: Frans Meulenbroeks fransmeulenbro...@gmail.com

 Eh, yes and no.

 I did write the original recipe and commited it on 14 aug 2010 with a
 sign-off message.
 As such this got my signoff, but I am not sure the signoff should be
 repeated if this moved to oe-core.

Fair enough. It is your Sign-off to give or take.

I was following the patch message guidelines. Example: Importaing
from Elsewhere Modified in particular:

http://wiki.openembedded.org/index.php/Commit_Patch_Message_Guidelines#Example:_Importing_from_Elsewhere_Modified

I will remove your Sign-off in v2.

 My sign-off at that time is definitely not to be used as a suggestion it is
 ok for oe-core (actually I feel this is not something for oe-core)

Understood -- I am happy to re-spin for inclusion in any layer. Please advise.

Best Regards,
Ben Gardiner

---
Nanometrics Inc.
http://www.nanometrics.ca

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

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

2011-07-28 Thread 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.pur...@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: [OE-core] [PATCH] [PATCH] raptor: add recipe


Op 28 jul. 2011, om 16:29 heeft Ben Gardiner het volgende geschreven:

 On Thu, Jul 28, 2011 at 10:24 AM, Frans Meulenbroeks
 fransmeulenbro...@gmail.com wrote:
 
 
 2011/7/28 Ben Gardiner bengardi...@nanometrics.ca
 
 
 Well, I would not submit _this_ patch for pull-request. I was hoping
 to get this version of raptor included and then submit a pull-request
 for a cherry-pick of the patch to add libxml2 to DEPENDS.
 
 Ah, missed that you also added libxml2.
 Not sure about the policies of the maintenance branch, but I suspect the
 proper way would be to fix and test in openembedded then submit a pull
 request.
 Then again maybe the policies for the maintenance branch are different.
 
 :) They are. AFAICT I need to get this recipe (including libxml2 dep
 update) into oe-core or its layers :)

I ask again, what makes you think that? Pretty much all of the recent 
maintenance commits are from .dev.

As for getting it in meta-oe, you need to test it first in that layer before 
sending a patch.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] [PATCH] raptor: add recipe


Op 28 jul. 2011, om 16:43 heeft Ben Gardiner het volgende geschreven:

 Hi Koen,
 
 On Thu, Jul 28, 2011 at 10:36 AM, Koen Kooi k...@dominion.thruhere.net 
 wrote:
 
 Op 28 jul. 2011, om 16:29 heeft Ben Gardiner het volgende geschreven:
 
 On Thu, Jul 28, 2011 at 10:24 AM, Frans Meulenbroeks
 fransmeulenbro...@gmail.com wrote:
 
 
 2011/7/28 Ben Gardiner bengardi...@nanometrics.ca
 
 
 Well, I would not submit _this_ patch for pull-request. I was hoping
 to get this version of raptor included and then submit a pull-request
 for a cherry-pick of the patch to add libxml2 to DEPENDS.
 
 Ah, missed that you also added libxml2.
 Not sure about the policies of the maintenance branch, but I suspect the
 proper way would be to fix and test in openembedded then submit a pull
 request.
 Then again maybe the policies for the maintenance branch are different.
 
 :) They are. AFAICT I need to get this recipe (including libxml2 dep
 update) into oe-core or its layers :)
 
 I ask again, what makes you think that? Pretty much all of the recent 
 maintenance commits are from .dev.
 
 I'm sorry I guess my previous reply got lost in the noise. I think
 that because I read it from Tom. If it is at all possible to
 circumvent this requirement

What did you exactly read and why do you think it's a requirement? From 
http://wiki.openembedded.org/index.php/2011.03-maintenance:

Changes may reside in either the openembedded 'master' repository OR a 
relevant public layer in the oe-core / meta-oe / etc universe
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] [PATCH] raptor: add recipe

On Thu, Jul 28, 2011 at 10:24 AM, Frans Meulenbroeks
fransmeulenbro...@gmail.com wrote:

2011/7/28 Ben Gardiner bengardi...@nanometrics.ca

Well, I would not submit _this_ patch for pull-request. I was hoping
to get this version of raptor included and then submit a pull-request
for a cherry-pick of the patch to add libxml2 to DEPENDS.

Ah, missed that you also added libxml2.
Not sure about the policies of the maintenance branch, but I suspect the
proper way would be to fix and test in openembedded then submit a pull
request.
Then again maybe the policies for the maintenance branch are different.

:) They are. AFAICT I need to get this recipe (including libxml2 dep
update) into oe-core or its layers :)

[...]

http://wiki.openembedded.org/index.php/Commit_Patch_Message_Guidelines#Example:_Importing_from_Elsewhere_Modified

Oh. I thought they were [in accordance]. I guess there would usually
be a commit body before the initial Signed-off-by:'s ; however, there
was no original commit body to preserve.

Ah ok, understood.
Actually, I guess we should preserve the first line of the commit too.
This is what git log says:

frans@frans-desktop:~/workspace/openembedded/recipes/raptor$ git log *
commit 01e8e9f325d8d251e852e7a5704b5fe50880e1ad
Author: Frans Meulenbroeks fransmeulenbro...@gmail.com
Date: Sat Aug 14 21:27:49 2010 +0200

raptor: added recipe

Signed-off-by: Frans Meulenbroeks fransmeulenbro...@gmail.com

Yes! Good point, Frans. It is 'added' not 'add' Sorry about that.

Best Regards,
Ben Gardiner

---
Nanometrics Inc.
http://www.nanometrics.ca

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

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


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.pur...@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


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

Re: [OE-core] [PATCH 1/1] python-native: Fix a compiler finding issue

2011-07-28 Thread Tom Rini

On 07/28/2011 12:20 AM, Mei Lei wrote:
 The CC variable sometimes add option information after compiler name, but 
 python can't get the real compiler name if those information added.
 Fix this issue by dropping the option information when finding compiler name.
 
 Signed-off-by: Mei Lei lei@intel.com

I think this is going to cause problems when you must pass flags to gcc
to have it work, eg 'gcc -m64'.

-- 
Tom Rini
Mentor Graphics Corporation

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

Re: [OE-core] [PATCH] scripts/oe-buildenv-internal: Add SOCKS5_{USER, PASSWD} to BB_ENV_EXTRAWHITE

2011-07-28 Thread Tom Rini

On 07/28/2011 06:10 AM, Kumar Gala wrote:
 If a SOCKS5 gateway is needed for a proxy access like git it might also
 require authentication to the proxy via a password and username.  Adding
 SOCKS5_USER  SOCKS5_PASSWD to BB_ENV_EXTRAWHITE allow for automation
 of the authentication request to occur when something like a git fetch
 is going through the proxy.
 
 Signed-off-by: Kumar Gala ga...@kernel.crashing.org

We also need to make sure these variables do NOT make it into the sstate
signature, which I think means one more change somewhere else (but I
don't recall where off-hand).

-- 
Tom Rini
Mentor Graphics Corporation

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

Re: [OE-core] lib vs lib64?

2011-07-28 Thread Tom Rini

On 07/28/2011 07:17 AM, Phil Blundell wrote:
 On Thu, 2011-07-28 at 09:15 -0500, Kumar Gala wrote:
 With recent multilib changes for a pure 64-bit target (no multilib) should 
 things be in /lib or /lib64?
 
 They should be in ${base_libdir}.  Whether that's /lib or /lib64 is a
 DISTRO choice I suppose.

Assuming the libc has been patched for that arch.  Or do we no longer
need that change?  I know there was a patch for mips64 to look at /lib
not /lib64 for ld.so, etc, etc.

-- 
Tom Rini
Mentor Graphics Corporation

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

[OE-core] [PATCH] tune-cortex{m1, m3, r4}: correct spelling of cortex

Otherwise the test in TUNE_CCARGS will never match.

Signed-off-by: Phil Blundell ph...@gnu.org
---
 meta/conf/machine/include/tune-cortexm1.inc |2 +-
 meta/conf/machine/include/tune-cortexm3.inc |2 +-
 meta/conf/machine/include/tune-cortexr4.inc |3 +--
 3 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/meta/conf/machine/include/tune-cortexm1.inc 
b/meta/conf/machine/include/tune-cortexm1.inc
index 493025d..3eecd5b 100644
--- a/meta/conf/machine/include/tune-cortexm1.inc
+++ b/meta/conf/machine/include/tune-cortexm1.inc
@@ -6,6 +6,6 @@ TUNEVALID[cortexm1] = Enable Cortex-M1 specific processor 
optimizations
 TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, cortexm1, 
-mtune=cortex-m1, , d)}
 
 AVAILTUNES += cortexm1
-TUNE_FEATURES_tune-cortexm1 = ${TUNE_FEATURES_tune-armv7a} coretexm1
+TUNE_FEATURES_tune-cortexm1 = ${TUNE_FEATURES_tune-armv7a} cortexm1
 PACKAGE_EXTRA_ARCHS_tune-cortexm1 = ${PACKAGE_EXTRA_ARCHS_tune-armv7at}
 
diff --git a/meta/conf/machine/include/tune-cortexm3.inc 
b/meta/conf/machine/include/tune-cortexm3.inc
index f774fa6..85408eb 100644
--- a/meta/conf/machine/include/tune-cortexm3.inc
+++ b/meta/conf/machine/include/tune-cortexm3.inc
@@ -10,6 +10,6 @@ TUNEVALID[armv7m] = Enable Cortex-M3 specific processor 
optimizations
 TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, armv7m, 
-march=armv7-m, , d)}
 
 AVAILTUNES += cortexm3
-TUNE_FEATURES_tune-cortexm3 = armv7m vfp coretexm3
+TUNE_FEATURES_tune-cortexm3 = armv7m vfp cortexm3
 PACKAGE_EXTRA_ARCHS_tune-cortexm3 = ${PACKAGE_EXTRA_ARCHS_tune-armv7at} 
armv7m
 
diff --git a/meta/conf/machine/include/tune-cortexr4.inc 
b/meta/conf/machine/include/tune-cortexr4.inc
index 738f5af..8d2459f 100644
--- a/meta/conf/machine/include/tune-cortexr4.inc
+++ b/meta/conf/machine/include/tune-cortexr4.inc
@@ -10,6 +10,5 @@ TUNEVALID[armv7r] = Enable Cortex-R4 specific processor 
optimizations
 TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, armv7r, 
-march=armv7-m, , d)}
 
 AVAILTUNES += cortexr4
-TUNE_FEATURES_tune-cortexr4 = armv7r vfp coretexr4
+TUNE_FEATURES_tune-cortexr4 = armv7r vfp cortexr4
 PACKAGE_EXTRA_ARCHS_tune-cortexr4 = ${PACKAGE_EXTRA_ARCHS_tune-armv7at} 
armv7r
-
-- 
1.7.4.1




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

Re: [OE-core] [PATCH] scripts/oe-buildenv-internal: Add SOCKS5_{USER, PASSWD} to BB_ENV_EXTRAWHITE


On Jul 28, 2011, at 10:09 AM, Tom Rini wrote:

 On 07/28/2011 06:10 AM, Kumar Gala wrote:
 If a SOCKS5 gateway is needed for a proxy access like git it might also
 require authentication to the proxy via a password and username.  Adding
 SOCKS5_USER  SOCKS5_PASSWD to BB_ENV_EXTRAWHITE allow for automation
 of the authentication request to occur when something like a git fetch
 is going through the proxy.
 
 Signed-off-by: Kumar Gala ga...@kernel.crashing.org
 
 We also need to make sure these variables do NOT make it into the sstate
 signature, which I think means one more change somewhere else (but I
 don't recall where off-hand).

Yeah, I didn't find anything obvious while grepping.

- k

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

Re: [OE-core] [yocto] mpc8315e-rdb core-image-minimal fails

I think I know the cause, let me dig up the change that is related.  What bit 
is looking for just ppc603e?

- k

On Jul 28, 2011, at 10:42 AM, Crossley, Malcolm (GE Intelligent Platforms) 
wrote:

 Hi Kumar,
 
 I'm just debugging the same issue.
 
 It's caused by folder for the target specific packages being mis-named
 powerpcppc603e instead of ppc603e which the rpm package bbclass is
 expecting. 
 
 I haven't figured out why this is happening yet but I have a workaround
 which is to move ${BUILD_DIR}/deploy/rpm/powerpcppc603e to
 ${BUILD_DIR}/deploy/rpm/ppc603e.
 
 I will let you know as soon as I find the cause. 
 
 Regards
 
 Malcolm
 
 -Original Message-
 From: yocto-boun...@yoctoproject.org
 [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Kumar Gala
 Sent: 28 July 2011 15:26
 To: Patches and discussions about the oe-core layer
 Cc: Yocto discussion list
 Subject: [yocto] mpc8315e-rdb core-image-minimal fails
 
 Anyone got any ideas about the following:
 
 | ERROR: Function 'do_rootfs' failed (see
 /local/home/galak/git/poky/build/tmp/work/mpc8315e_rdb-poky-linux/core-i
 mage-minimal-1.0-r0/temp/log.do_rootfs.19834 for fu
 rther information)
 | Generating solve db for
 /local/home/galak/git/poky/build/tmp/deploy/rpm/mpc8315e_rdb...
 |total:   1  0.00 MB  1.573137 secs
 |fingerprint:   816  0.004148 MB  0.062215 secs
 |install:   272  0.00 MB  0.384963 secs
 |dbadd: 272  0.00 MB  0.375238 secs
 |dbget:  0.00 MB  0.003093 secs
 |dbput: 272  1.315744 MB  0.302582 secs
 |readhdr:  2721  2.573624 MB  0.178385 secs
 |hdrload:  1360  3.828344 MB  0.007262 secs
 |hdrget:  49259  0.00 MB  0.048944 secs
 | Generating solve db for
 /local/home/galak/git/poky/build/tmp/deploy/rpm/all...
 |total:   1  0.00 MB  0.29 secs
 |fingerprint:18  0.24 MB  0.000280 secs
 |install: 6  0.00 MB  0.044466 secs
 |dbadd:   6  0.00 MB  0.039504 secs
 |dbget:  19  0.00 MB  0.000103 secs
 |dbput:   6  0.018916 MB  0.006250 secs
 |readhdr:61  0.038096 MB  0.000212 secs
 |hdrload:33  0.063864 MB  0.000327 secs
 |hdrget:983  0.00 MB  0.001306 secs
 | Generating solve db for
 /local/home/galak/git/poky/build/tmp/deploy/rpm/all...
 | Processing task-core-boot...
 | error: Failed dependencies:
 |   tinylogin is needed by task-core-boot-1.0-r7.mpc8315e_rdb
 |   busybox is needed by task-core-boot-1.0-r7.mpc8315e_rdb
 |   modutils-initscripts is needed by
 task-core-boot-1.0-r7.mpc8315e_rdb
 |   initscripts is needed by task-core-boot-1.0-r7.mpc8315e_rdb
 |   update-alternatives-cworth is needed by
 task-core-boot-1.0-r7.mpc8315e_rdb
 |   udev is needed by task-core-boot-1.0-r7.mpc8315e_rdb
 |   sysvinit is needed by task-core-boot-1.0-r7.mpc8315e_rdb
 |   netbase is needed by task-core-boot-1.0-r7.mpc8315e_rdb
 |   base-passwd is needed by task-core-boot-1.0-r7.mpc8315e_rdb
 |   console-tools is needed by keymaps-1.0-r19.mpc8315e_rdb
 |   initscripts is needed by keymaps-1.0-r19.mpc8315e_rdb
 |   /bin/sh is needed by keymaps-1.0-r19.mpc8315e_rdb
 NOTE: package core-image-minimal-1.0-r0: task do_rootfs: Failed
 ERROR: Task 8
 (/local/home/galak/git/poky/meta/recipes-core/images/core-image-minimal.
 bb, do_rootfs) failed with exit code '1'
 ERROR:
 '/local/home/galak/git/poky/meta/recipes-core/images/core-image-minimal.
 bb' failed
 
 - k
 ___
 yocto mailing list
 yo...@yoctoproject.org
 https://lists.yoctoproject.org/listinfo/yocto


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

Re: [OE-core] lib vs lib64?


On Jul 28, 2011, at 10:15 AM, Tom Rini wrote:

 On 07/28/2011 07:17 AM, Phil Blundell wrote:
 On Thu, 2011-07-28 at 09:15 -0500, Kumar Gala wrote:
 With recent multilib changes for a pure 64-bit target (no multilib) should 
 things be in /lib or /lib64?
 
 They should be in ${base_libdir}.  Whether that's /lib or /lib64 is a
 DISTRO choice I suppose.
 
 Assuming the libc has been patched for that arch.  Or do we no longer
 need that change?  I know there was a patch for mips64 to look at /lib
 not /lib64 for ld.so, etc, etc.

Yeah, the issue I'm running into seems related to:

commit 6c936b4b1a2fb1bdf1f3f91482af7e33e71b5c10
Author: Richard Purdie richard.pur...@linuxfoundation.org
Date:   Wed Jul 27 10:19:30 2011 +0100

gcc: Drop part of the 64bithack patch which is no longer used

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

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

And it not doing what is expected.

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

Re: [OE-core] [PATCH] scripts/oe-buildenv-internal: Add SOCKS5_{USER, PASSWD} to BB_ENV_EXTRAWHITE

On Thursday 28 July 2011 16:40:34 Kumar Gala wrote:
 On Jul 28, 2011, at 10:09 AM, Tom Rini wrote:
  On 07/28/2011 06:10 AM, Kumar Gala wrote:
  If a SOCKS5 gateway is needed for a proxy access like git it might also
  require authentication to the proxy via a password and username.  Adding
  SOCKS5_USER  SOCKS5_PASSWD to BB_ENV_EXTRAWHITE allow for automation
  of the authentication request to occur when something like a git fetch
  is going through the proxy.
  
  Signed-off-by: Kumar Gala ga...@kernel.crashing.org
  
  We also need to make sure these variables do NOT make it into the sstate
  signature, which I think means one more change somewhere else (but I
  don't recall where off-hand).
 
 Yeah, I didn't find anything obvious while grepping.

I think what you're looking for is BB_HASHBASE_WHITELIST; however IIRC it's 
only really necessary if another variable refers to SOCKS5_*, or it is used in 
some bit of python/shell script; otherwise it shouldn't appear in the variable 
dependencies and thus won't make it's way into the sstate signature.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

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

Re: [OE-core] [PATCH 1/1] [M3]meta-environment: set correct *MULTIMACH_TARGET_SYS.

2011-07-28 Thread Zhang, Jessica



-Original Message-
From: openembedded-core-boun...@lists.openembedded.org 
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Lianhao 
Lu
Sent: Thursday, July 28, 2011 4:24 AM
To: openembedded-core@lists.openembedded.org
Subject: [OE-core] [PATCH 1/1] meta-environment: set correct 
*MULTIMACH_TARGET_SYS.

Fixed [BUGID #1299]. OLD_MULTIMACH_TARGET_SYS is no longer available.
Use new recipe-scope variable REAL_MULTIMACH_TARGET_SYS instead.

Signed-off-by: Lianhao Lu lianhao...@intel.com
Acted-by: Jessica Zhang jessica.zh...@intel.com
---
 meta/classes/toolchain-scripts.bbclass |7 ---
 meta/recipes-core/meta/meta-environment.bb |9 +
 2 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/meta/classes/toolchain-scripts.bbclass 
b/meta/classes/toolchain-scripts.bbclass
index 3301319..832cce4 100644
--- a/meta/classes/toolchain-scripts.bbclass
+++ b/meta/classes/toolchain-scripts.bbclass
@@ -66,13 +66,14 @@ toolchain_create_tree_env_script () {
 # This function creates an environment-setup-script for use by the ADT 
installer
 toolchain_create_sdk_env_script_for_installer () {
# Create environment setup script
-   
script=${SDK_OUTPUT}/${SDKPATH}/environment-setup-${OLD_MULTIMACH_TARGET_SYS}
+   local multimach_target_sys=$1
+   
script=${SDK_OUTPUT}/${SDKPATH}/environment-setup-${multimach_target_sys}
rm -f $script
touch $script
-   echo 'export 
PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/${OLD_MULTIMACH_TARGET_SYS}:$PATH'
  $script
+   echo 'export 
PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/'${multimach_target_sys}':$PATH'
  $script
echo 'export PKG_CONFIG_SYSROOT_DIR=##SDKTARGETSYSROOT##'  $script
echo 'export 
PKG_CONFIG_PATH=##SDKTARGETSYSROOT##${target_libdir}/pkgconfig'  $script
-   echo 'export 
CONFIG_SITE=${SDKPATH}/site-config-${OLD_MULTIMACH_TARGET_SYS}'  $script
+   echo 'export 
CONFIG_SITE=${SDKPATH}/site-config-'${multimach_target_sys}  $script
echo 'export CC=${TARGET_PREFIX}gcc'  $script
echo 'export CXX=${TARGET_PREFIX}g++'  $script
echo 'export GDB=${TARGET_PREFIX}gdb'  $script
diff --git a/meta/recipes-core/meta/meta-environment.bb 
b/meta/recipes-core/meta/meta-environment.bb
index 351cbf0..6d547bb 100644
--- a/meta/recipes-core/meta/meta-environment.bb
+++ b/meta/recipes-core/meta/meta-environment.bb
@@ -2,13 +2,14 @@ DESCRIPTION = Package of environment files for SDK
 LIC_FILES_CHKSUM = 
file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
 
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420
 LICENSE = MIT
-PR = r4
+PR = r5

 EXCLUDE_FROM_WORLD = 1

 inherit toolchain-scripts
 # get target config site before inheritting cross-canadian
 TARGET_CONFIG_SITE := ${@siteinfo_get_files(d)}
+REAL_MULTIMACH_TARGET_SYS = ${TUNE_PKGARCH}${TARGET_VENDOR}-${TARGET_OS}

 SDK_DIR = ${WORKDIR}/sdk
 SDK_OUTPUT = ${SDK_DIR}/image
@@ -22,12 +23,12 @@ do_generate_content() {
 rm -rf ${SDK_OUTPUT}
 mkdir -p ${SDK_OUTPUT}/${SDKPATH}

-toolchain_create_sdk_siteconfig 
${SDK_OUTPUT}/${SDKPATH}/site-config-${OLD_MULTIMACH_TARGET_SYS} 
${TARGET_CONFIG_SITE}
+toolchain_create_sdk_siteconfig 
${SDK_OUTPUT}/${SDKPATH}/site-config-${REAL_MULTIMACH_TARGET_SYS} 
${TARGET_CONFIG_SITE}

-toolchain_create_sdk_env_script_for_installer
+toolchain_create_sdk_env_script_for_installer ${REAL_MULTIMACH_TARGET_SYS}

 # Add version information
-toolchain_create_sdk_version 
${SDK_OUTPUT}/${SDKPATH}/version-${OLD_MULTIMACH_TARGET_SYS}
+toolchain_create_sdk_version 
${SDK_OUTPUT}/${SDKPATH}/version-${REAL_MULTIMACH_TARGET_SYS}
 }
 addtask generate_content before do_install after do_compile

--
1.7.0.4


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

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

Re: [OE-core] [PATCH 0/1][M3] Fix bug #1299 for meta-environment

2011-07-28 Thread Zhang, Jessica



-Original Message-
From: openembedded-core-boun...@lists.openembedded.org 
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Lianhao 
Lu
Sent: Thursday, July 28, 2011 4:24 AM
To: openembedded-core@lists.openembedded.org
Subject: [OE-core] [PATCH 0/1] Fix bug #1299 for meta-environment

Using recipe-scope variable REAL_MULTIMACH_TARGET_SYS instead of the unavailable
OLD_MULTIMACH_TARGET_SYS to generate meta-environment files for ADT installer.

The following changes since commit f94b781695cd8fa387daff16ecbf3987a0883018:
  Bruce Ashfield (1):
poky.conf: explicitly referenced preferred linux-yocto version

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib llu/bug1299
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=llu/bug1299

Lianhao Lu (1):
  meta-environment: set correct *MULTIMACH_TARGET_SYS.

 meta/classes/toolchain-scripts.bbclass |7 ---
 meta/recipes-core/meta/meta-environment.bb |9 +
 2 files changed, 9 insertions(+), 7 deletions(-)


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

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

Re: [OE-core] [PATCH] [PATCH] raptor: add recipe

On Thu, Jul 28, 2011 at 10:46 AM, Koen Kooi k...@dominion.thruhere.net wrote:

 Op 28 jul. 2011, om 16:43 heeft Ben Gardiner het volgende geschreven:

 Hi Koen,

 On Thu, Jul 28, 2011 at 10:36 AM, Koen Kooi k...@dominion.thruhere.net 
 wrote:

 Op 28 jul. 2011, om 16:29 heeft Ben Gardiner het volgende geschreven:

 On Thu, Jul 28, 2011 at 10:24 AM, Frans Meulenbroeks
 fransmeulenbro...@gmail.com wrote:


 2011/7/28 Ben Gardiner bengardi...@nanometrics.ca


 Well, I would not submit _this_ patch for pull-request. I was hoping
 to get this version of raptor included and then submit a pull-request
 for a cherry-pick of the patch to add libxml2 to DEPENDS.

 Ah, missed that you also added libxml2.
 Not sure about the policies of the maintenance branch, but I suspect the
 proper way would be to fix and test in openembedded then submit a pull
 request.
 Then again maybe the policies for the maintenance branch are different.

 :) They are. AFAICT I need to get this recipe (including libxml2 dep
 update) into oe-core or its layers :)

 I ask again, what makes you think that? Pretty much all of the recent 
 maintenance commits are from .dev.

 I'm sorry I guess my previous reply got lost in the noise. I think
 that because I read it from Tom. If it is at all possible to
 circumvent this requirement

 What did you exactly read and why do you think it's a requirement? From 
 http://wiki.openembedded.org/index.php/2011.03-maintenance:

 Changes may reside in either the openembedded 'master' repository OR a 
 relevant public layer in the oe-core / meta-oe / etc universe

I read:

In Message-ID: 4dfa7108.5020...@mentor.com On Thu, Jun 16, 2011 at
5:09 PM, Tom Rini tom_r...@mentor.com wrote:
 [...]
 the policy about where changes need to be before they can be included in
 2011.03-maintenance to include being in oe-core / meta-oe or other
 relevant public layer instead of being only in the oe.dev master branch.

and took instead of being only to mean that the development effort
must shift to pushing into oe-core (or it's layers).

My mistake and thank you for clarifying this is not a requirement.
Please drop this patch from consideration.

Best Regards,
Ben Gardiner

---
Nanometrics Inc.
http://www.nanometrics.ca

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

[OE-core] [PATCH] arch-armv6, arch-armv5-dsp: correct endianness confusion

PACKAGE_EXTRA_ARCHS_tune-armv5eb needs to be defined in terms of
the non-e with the same endianness, i.e. PACKAGE_EXTRA_ARCHS_tune-armv5b
not PACKAGE_EXTRA_ARCHS_tune-armv5, otherwise PACKAGE_EXTRA_ARCHS will 
end up containing a semi-random mixture of endiannesses and disaster 
will ensue.  Likewise for the vfp and armv6 variants.

This is all a bit confusing because TUNE_FEATURES is done the opposite
way around, i.e. TUNE_FEATURES_tune-armv5eb is derived by taking the
armv5e version and adding bigendian.  But fixing that is probably
a subject for a separate patch.

Signed-off-by: Phil Blundell ph...@gnu.org
---
 meta/conf/machine/include/arm/arch-armv5-dsp.inc |8 
 meta/conf/machine/include/arm/arch-armv6.inc |4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/meta/conf/machine/include/arm/arch-armv5-dsp.inc 
b/meta/conf/machine/include/arm/arch-armv5-dsp.inc
index 498a012..9f03a0f 100644
--- a/meta/conf/machine/include/arm/arch-armv5-dsp.inc
+++ b/meta/conf/machine/include/arm/arch-armv5-dsp.inc
@@ -24,8 +24,8 @@ PACKAGE_EXTRA_ARCHS_tune-armv5tehf-vfp = 
${PACKAGE_EXTRA_ARCHS_tune-armv5thf-vf
 AVAILTUNES += armv5eb armv5teb
 TUNE_FEATURES_tune-armv5eb ?= ${TUNE_FEATURES_tune-armv5e} bigendian
 TUNE_FEATURES_tune-armv5teb ?= ${TUNE_FEATURES_tune-armv5te} bigendian
-PACKAGE_EXTRA_ARCHS_tune-armv5eb = ${PACKAGE_EXTRA_ARCHS_tune-armv5} armv5eb
-PACKAGE_EXTRA_ARCHS_tune-armv5teb = ${PACKAGE_EXTRA_ARCHS_tune-armv5t} 
armv5eb armv5teb
+PACKAGE_EXTRA_ARCHS_tune-armv5eb = ${PACKAGE_EXTRA_ARCHS_tune-armv5b} armv5eb
+PACKAGE_EXTRA_ARCHS_tune-armv5teb = ${PACKAGE_EXTRA_ARCHS_tune-armv5tb} 
armv5eb armv5teb
 
 # Big Endian + VFP/DSP
 AVAILTUNES += armv5eb-vfp armv5teb-vfp armv5ehfb-vfp armv5tehfb-vfp
@@ -33,8 +33,8 @@ TUNE_FEATURES_tune-armv5eb-vfp ?= 
${TUNE_FEATURES_tune-armv5e-vfp} bigendian
 TUNE_FEATURES_tune-armv5teb-vfp ?= ${TUNE_FEATURES_tune-armv5te-vfp} 
bigendian
 TUNE_FEATURES_tune-armv5ehfb-vfp ?= ${TUNE_FEATURES_tune-armv5eb-vfp} 
callconvention-hard
 TUNE_FEATURES_tune-armv5tehfb-vfp ?= ${TUNE_FEATURES_tune-armv5teb-vfp} 
callconvention-hard
-PACKAGE_EXTRA_ARCHS_tune-armv5eb-vfp = ${PACKAGE_EXTRA_ARCHS_tune-armv5-vfp} 
armv5eb armv5eb-vfp
-PACKAGE_EXTRA_ARCHS_tune-armv5teb-vfp = 
${PACKAGE_EXTRA_ARCHS_tune-armv5t-vfp} armv5eb armv5teb armv5eb-vfp 
armv5teb-vfp
+PACKAGE_EXTRA_ARCHS_tune-armv5eb-vfp = ${PACKAGE_EXTRA_ARCHS_tune-armv5b-vfp} 
armv5eb armv5eb-vfp
+PACKAGE_EXTRA_ARCHS_tune-armv5teb-vfp = 
${PACKAGE_EXTRA_ARCHS_tune-armv5tb-vfp} armv5eb armv5teb armv5eb-vfp 
armv5teb-vfp
 PACKAGE_EXTRA_ARCHS_tune-armv5ehfb-vfp = 
${PACKAGE_EXTRA_ARCHS_tune-armv5hfb-vfp} armv5ehfb-vfp
 PACKAGE_EXTRA_ARCHS_tune-armv5tehfb-vfp = 
${PACKAGE_EXTRA_ARCHS_tune-armv5thfb-vfp} armv5ehfb-vfp armv5tehfb-vfp
 
diff --git a/meta/conf/machine/include/arm/arch-armv6.inc 
b/meta/conf/machine/include/arm/arch-armv6.inc
index 20924c9..9f2e9ac 100644
--- a/meta/conf/machine/include/arm/arch-armv6.inc
+++ b/meta/conf/machine/include/arm/arch-armv6.inc
@@ -25,8 +25,8 @@ TUNE_FEATURES_tune-armv6b ?= ${TUNE_FEATURES_tune-armv6} 
bigendian
 TUNE_FEATURES_tune-armv6tb ?= ${TUNE_FEATURES_tune-armv6t} bigendian
 TUNE_FEATURES_tune-armv6hfb ?= ${TUNE_FEATURES_tune-armv6b} 
callconvention-hard
 TUNE_FEATURES_tune-armv6thfb ?= ${TUNE_FEATURES_tune-armv6tb} 
callconvention-hard
-PACKAGE_EXTRA_ARCHS_tune-armv6b = ${PACKAGE_EXTRA_ARCHS_tune-armv5e-vfp} 
armv6b-vfp
-PACKAGE_EXTRA_ARCHS_tune-armv6tb = ${PACKAGE_EXTRA_ARCHS_tune-armv5te-vfp} 
armv6b-vfp armv6tb-vfp
+PACKAGE_EXTRA_ARCHS_tune-armv6b = ${PACKAGE_EXTRA_ARCHS_tune-armv5eb-vfp} 
armv6b-vfp
+PACKAGE_EXTRA_ARCHS_tune-armv6tb = ${PACKAGE_EXTRA_ARCHS_tune-armv5teb-vfp} 
armv6b-vfp armv6tb-vfp
 PACKAGE_EXTRA_ARCHS_tune-armv6hfb = ${PACKAGE_EXTRA_ARCHS_tune-armv5ehfb-vfp} 
armv6hfb-vfp
 PACKAGE_EXTRA_ARCHS_tune-armv6thfb = 
${PACKAGE_EXTRA_ARCHS_tune-armv5tehfb-vfp} armv6hfb-vfp armv6thfb-vfp
 
-- 
1.7.4.1




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

Re: [OE-core] [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle

2011-07-28 Thread Martin Jansa

On Thu, Jul 28, 2011 at 09:54:06AM +0100, Phil Blundell wrote:
 On Thu, 2011-07-28 at 09:24 +0200, Martin Jansa wrote:
  Mark is right that if we have PACKAGE_ARCH = armv4t and we force
  no-thumb with ARM_INSTRUCTION_SET = arm then PACKAGE_ARCH should be
  switched to armv4 only to indicate that.
 
 No, this is wrong.  Even with ARM_INSTRUCTION_SET = arm you might have
 BX instructions in the output, in which case armv4t is the correct
 PACKAGE_ARCH.  You can only set PACKAGE_ARCH = armv4 if all the BXs
 have been suppressed, which means that you lose the ability to do
 interworking.

Ah right, we cannot allow this to be in ie collie feed. So old behavior
was correct in this aspect too.

Thanks

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


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

Re: [OE-core] [yocto] mpc8315e-rdb core-image-minimal fails (PACKAGE_ARCHS question)


On Jul 28, 2011, at 11:05 AM, Saul Wold wrote:

 On 07/28/2011 08:45 AM, Kumar Gala wrote:
 I think I know the cause, let me dig up the change that is related.  What 
 bit is looking for just ppc603e?
 
 This might also be related to the PACKAGE_EXTRA_ARCHS issue, please try the 
 patch that Koen posted.
 
 Thanks
   Sau!

so in conf/bitbake.conf

PACKAGE_ARCH = ${TUNE_PKGARCH}
MACHINE_ARCH = ${@[bb.data.getVar('TUNE_PKGARCH', d, 1), 
bb.data.getVar('MACHINE', d, 1)][bool(bb.data.getVar('MACHINE', d, 
1))].replace('-', '_')}
PACKAGE_EXTRA_ARCHS ??= ${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
PACKAGE_ARCHS = all any noarch ${PACKAGE_EXTRA_ARCHS} ${MACHINE_ARCH}


Shouldn't PACKAGE_ARCHS be:

PACKAGE_ARCHS = all any noarch ${PACKAGE_ARCH} ${PACKAGE_EXTRA_ARCHS} 
${MACHINE_ARCH}

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

[OE-core] [PATCH] libzypp: Fix variable substitution problem in do_archgen step

The do_archgen step creates a script that utilizes the variable name
${ARCH}.  However, we also utilize and define ${ARCH} so instead of
having the following in the script:

COMPAT_WITH=${ARCH},${COMPAT} $COMPAT_WITH

We get something like:

COMPAT_WITH=powerpc,${COMPAT} $COMPAT_WITH

Just renaming the variable in the script to not conflict with ${ARCH}
fixes the issue.

Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
 meta/recipes-extended/libzypp/libzypp_git.bb |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-extended/libzypp/libzypp_git.bb 
b/meta/recipes-extended/libzypp/libzypp_git.bb
index 6555bd4..a9ed639 100644
--- a/meta/recipes-extended/libzypp/libzypp_git.bb
+++ b/meta/recipes-extended/libzypp/libzypp_git.bb
@@ -111,9 +111,9 @@ do_archgen () {
shift ; continue;;
esac
if [ ${AVOID_CONSTRUCTOR} != true ]; then
- ARCH=_$1
+ CARCH=_$1
else
- ARCH=IdString(\$1\)
+ CARCH=IdString(\$1\)
fi
shift
COMPAT=
@@ -129,7 +129,7 @@ do_archgen () {
COMPAT=${arch_val},$COMPAT
fi
done
-   COMPAT_WITH=${ARCH},${COMPAT} $COMPAT_WITH
+   COMPAT_WITH=${CARCH},${COMPAT} $COMPAT_WITH
done
for each_compat in ${COMPAT_WITH} ; do
echo defCompatibleWith( ${each_compat} ); 
 zypp/poky-arch.h
-- 
1.7.3.4


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

Re: [OE-core] [yocto] mpc8315e-rdb core-image-minimal fails (PACKAGE_ARCHS question)

2011-07-28 Thread Crossley, Malcolm (GE Intelligent Platforms)

On Thu, 2011-07-28 at 20:54 +0200, Martin Jansa wrote:
 this change causes ERROR here with nokia900:
 Error, the PACKAGE_ARCHS variable contains duplicates. The following archs 
 are listed more than once: armv7a-vfp-neon

It isn't totally obvious to me that it needs to be an error for
PACKAGE_ARCHS to contain dupes.  AFAIK there is no reason that it
couldn't simply be uniquified before use.

p.



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

Re: [OE-core] [yocto] mpc8315e-rdb core-image-minimal fails

Hi Kumar,

I'm just debugging the same issue.

It's caused by folder for the target specific packages being mis-named
powerpcppc603e instead of ppc603e which the rpm package bbclass is
expecting. 

I haven't figured out why this is happening yet but I have a workaround
which is to move ${BUILD_DIR}/deploy/rpm/powerpcppc603e to
${BUILD_DIR}/deploy/rpm/ppc603e.

I will let you know as soon as I find the cause. 

Regards

Malcolm

-Original Message-
From: yocto-boun...@yoctoproject.org
[mailto:yocto-boun...@yoctoproject.org] On Behalf Of Kumar Gala
Sent: 28 July 2011 15:26
To: Patches and discussions about the oe-core layer
Cc: Yocto discussion list
Subject: [yocto] mpc8315e-rdb core-image-minimal fails

Anyone got any ideas about the following:

| ERROR: Function 'do_rootfs' failed (see
/local/home/galak/git/poky/build/tmp/work/mpc8315e_rdb-poky-linux/core-i
mage-minimal-1.0-r0/temp/log.do_rootfs.19834 for fu
rther information)
| Generating solve db for
/local/home/galak/git/poky/build/tmp/deploy/rpm/mpc8315e_rdb...
|total:   1  0.00 MB  1.573137 secs
|fingerprint:   816  0.004148 MB  0.062215 secs
|install:   272  0.00 MB  0.384963 secs
|dbadd: 272  0.00 MB  0.375238 secs
|dbget:  0.00 MB  0.003093 secs
|dbput: 272  1.315744 MB  0.302582 secs
|readhdr:  2721  2.573624 MB  0.178385 secs
|hdrload:  1360  3.828344 MB  0.007262 secs
|hdrget:  49259  0.00 MB  0.048944 secs
| Generating solve db for
/local/home/galak/git/poky/build/tmp/deploy/rpm/all...
|total:   1  0.00 MB  0.29 secs
|fingerprint:18  0.24 MB  0.000280 secs
|install: 6  0.00 MB  0.044466 secs
|dbadd:   6  0.00 MB  0.039504 secs
|dbget:  19  0.00 MB  0.000103 secs
|dbput:   6  0.018916 MB  0.006250 secs
|readhdr:61  0.038096 MB  0.000212 secs
|hdrload:33  0.063864 MB  0.000327 secs
|hdrget:983  0.00 MB  0.001306 secs
| Generating solve db for
/local/home/galak/git/poky/build/tmp/deploy/rpm/all...
| Processing task-core-boot...
| error: Failed dependencies:
|   tinylogin is needed by task-core-boot-1.0-r7.mpc8315e_rdb
|   busybox is needed by task-core-boot-1.0-r7.mpc8315e_rdb
|   modutils-initscripts is needed by
task-core-boot-1.0-r7.mpc8315e_rdb
|   initscripts is needed by task-core-boot-1.0-r7.mpc8315e_rdb
|   update-alternatives-cworth is needed by
task-core-boot-1.0-r7.mpc8315e_rdb
|   udev is needed by task-core-boot-1.0-r7.mpc8315e_rdb
|   sysvinit is needed by task-core-boot-1.0-r7.mpc8315e_rdb
|   netbase is needed by task-core-boot-1.0-r7.mpc8315e_rdb
|   base-passwd is needed by task-core-boot-1.0-r7.mpc8315e_rdb
|   console-tools is needed by keymaps-1.0-r19.mpc8315e_rdb
|   initscripts is needed by keymaps-1.0-r19.mpc8315e_rdb
|   /bin/sh is needed by keymaps-1.0-r19.mpc8315e_rdb
NOTE: package core-image-minimal-1.0-r0: task do_rootfs: Failed
ERROR: Task 8
(/local/home/galak/git/poky/meta/recipes-core/images/core-image-minimal.
bb, do_rootfs) failed with exit code '1'
ERROR:
'/local/home/galak/git/poky/meta/recipes-core/images/core-image-minimal.
bb' failed

- k
___
yocto mailing list
yo...@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

Re: [OE-core] [yocto] mpc8315e-rdb core-image-minimal fails (PACKAGE_ARCHS question)


On Jul 28, 2011, at 2:04 PM, Phil Blundell wrote:

 On Thu, 2011-07-28 at 20:54 +0200, Martin Jansa wrote:
 this change causes ERROR here with nokia900:
 Error, the PACKAGE_ARCHS variable contains duplicates. The following archs 
 are listed more than once: armv7a-vfp-neon
 
 It isn't totally obvious to me that it needs to be an error for
 PACKAGE_ARCHS to contain dupes.  AFAIK there is no reason that it
 couldn't simply be uniquified before use.
 
 p.
 

Ok, maybe we want:

-PACKAGE_ARCHS = all any noarch ${PACKAGE_EXTRA_ARCHS} ${MACHINE_ARCH}
+PACKAGE_ARCHS = all any noarch ${TUNE_PKGARCH} ${PACKAGE_EXTRA_ARCHS} 
${MACHINE_ARCH}

instead as we redefine PACKAGE_ARCH in different places.

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

[OE-core] [PATCH] bitbake.conf: Add PACKAGE_ARCHS to include TUNE_PKGARCH

Recent changes to how TUNE_PKGARCH is composed means it might not be in
the PACKAGE_EXTRA_ARCHS_tune list.  Rather than having to update all
such lists we just add TUNE_PKGARCH to PACKAGE_ARCHS.

An example, for ppc603e TUNE_PKGARCH is now:

powerpcppc603e

However, PACKAGE_EXTRA_ARCHS_tune-ppc603e = powerpc ppc603e

Thus we run into issues during things like rpm packagine since it will
not end up dealing the rpms created in a 'powerpcppc603e' directory.

Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
 meta/conf/bitbake.conf |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 9c80f11..d8b9f36 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -104,7 +104,7 @@ SDK_CC_ARCH = ${BUILD_CC_ARCH}
 PACKAGE_ARCH = ${TUNE_PKGARCH}
 MACHINE_ARCH = ${@[bb.data.getVar('TUNE_PKGARCH', d, 1), 
bb.data.getVar('MACHINE', d, 1)][bool(bb.data.getVar('MACHINE', d, 
1))].replace('-', '_')}
 PACKAGE_EXTRA_ARCHS ??= ${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
-PACKAGE_ARCHS = all any noarch ${PACKAGE_EXTRA_ARCHS} ${MACHINE_ARCH}
+PACKAGE_ARCHS = all any noarch ${TUNE_PKGARCH} ${PACKAGE_EXTRA_ARCHS} 
${MACHINE_ARCH}
 # MACHINE_ARCH shouldn't be included here as a variable dependency
 # since machine specific packages are handled using multimachine
 PACKAGE_ARCHS[vardepsexclude] = MACHINE_ARCH
-- 
1.7.3.4


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

[OE-core] [PATCH 5/5] image-mklibs.bbclass: Add powerpc64 arch support

Just mimic what we do on powerpc (32-bit).

Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
 meta/classes/image-mklibs.bbclass |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/meta/classes/image-mklibs.bbclass 
b/meta/classes/image-mklibs.bbclass
index 9f5a4ea..d5e8ab7 100644
--- a/meta/classes/image-mklibs.bbclass
+++ b/meta/classes/image-mklibs.bbclass
@@ -16,7 +16,7 @@ mklibs_optimize_image_doit() {
 ${WORKDIR}/mklibs/executables.list
 
case ${TARGET_ARCH} in
-   powerpc | mips | microblaze )
+   powerpc | powerpc64 | mips | microblaze )
dynamic_loader=/lib/ld.so.1
;;
x86_64)
-- 
1.7.3.4


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

[OE-core] [PATCH 1/5] tune/arch-powerpc64: Fix typo with 64-bit TUNE_CCARGS handling

When figuring out how to set TUNE_CCARGS we should look for 'm64' not
'n64' in TUNE_FEATURES.

Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
 .../machine/include/powerpc/arch-powerpc64.inc |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/meta/conf/machine/include/powerpc/arch-powerpc64.inc 
b/meta/conf/machine/include/powerpc/arch-powerpc64.inc
index a99f18d..e55910c 100644
--- a/meta/conf/machine/include/powerpc/arch-powerpc64.inc
+++ b/meta/conf/machine/include/powerpc/arch-powerpc64.inc
@@ -1,6 +1,6 @@
 TUNEVALID[m64] = Power ELF64 standard ABI
 TUNE_CONFLICTS[m64] = m32
-TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, n64, -m64, , d)}
+TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, m64, -m64, , d)}
 TUNE_ARCH .= ${@bb.utils.contains(TUNE_FEATURES, [ m64 ], powerpc64, 
, d)}
 
 AVAILTUNES += powerpc64 powerpc64-nf
-- 
1.7.3.4


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

[OE-core] [PATCH] tune-ppce500mc: Adjust PowerPC e500mc tune file to correctly set hard fpu.

From: Malcolm Crossley malcolm.cross...@ge.com

Signed-off-by: Malcolm Crossley malcolm.cross...@ge.com
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
 meta/conf/machine/include/tune-ppce500mc.inc |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/meta/conf/machine/include/tune-ppce500mc.inc 
b/meta/conf/machine/include/tune-ppce500mc.inc
index a4cdb1f..73217dd 100644
--- a/meta/conf/machine/include/tune-ppce500mc.inc
+++ b/meta/conf/machine/include/tune-ppce500mc.inc
@@ -7,5 +7,5 @@ TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, 
ppce500mc, -mcpu=e500mc
 TUNE_PKGARCH .= ${@bb.utils.contains(TUNE_FEATURES, ppce500mc, 
ppce500mc, , d)}
 
 AVAILTUNES += ppce500mc
-TUNE_FEATURES_tune-ppce500mc = m32 hard-fpu ppce500mc
+TUNE_FEATURES_tune-ppce500mc = m32 fpu-hard ppce500mc
 PACKAGE_EXTRA_ARCHS_tune-ppce500mc = powerpc ppce500mc
-- 
1.7.3.4


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

Re: [OE-core] [PATCH] bitbake.conf: Add PACKAGE_ARCHS to include TUNE_PKGARCH


On Jul 28, 2011, at 3:46 PM, Kumar Gala wrote:

 Recent changes to how TUNE_PKGARCH is composed means it might not be in
 the PACKAGE_EXTRA_ARCHS_tune list.  Rather than having to update all
 such lists we just add TUNE_PKGARCH to PACKAGE_ARCHS.
 
 An example, for ppc603e TUNE_PKGARCH is now:
 
   powerpcppc603e
 
 However, PACKAGE_EXTRA_ARCHS_tune-ppc603e = powerpc ppc603e
 
 Thus we run into issues during things like rpm packagine since it will
 not end up dealing the rpms created in a 'powerpcppc603e' directory.
 
 Signed-off-by: Kumar Gala ga...@kernel.crashing.org
 ---
 meta/conf/bitbake.conf |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

Hmm, this does cause some issues like:

ERROR:  Poky's config sanity checker detected a potential misconfiguration.
Either fix the cause of this error or at your own risk disable the checker 
(see sanity.conf).
Following is the list of potential problems / advisories:

Error, the PACKAGE_ARCHS variable contains duplicates. The following archs 
are listed more than once: ppc603e
ERROR: Execution of event handler 'check_sanity_eventhandler' failed

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

[OE-core] [PATCH] sanity.bbclass: Add sanity check that TUNE_PKGARCH appears in PACKAGE_ARCHS

Its possible we get duplications if we explicity add TUNE_PKGARCH to
PACKAGE_ARCHS so instead just add a sanity check to verify it.

Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
 meta/classes/sanity.bbclass |   10 +-
 1 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index b054146..999e15d 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -375,8 +375,10 @@ def check_sanity(e):
 elif oeroot.find (' ') != -1:
 messages = messages + Error, you have a space in your COREBASE 
directory path. Please move the installation to a directory which doesn't 
include a space.
 
-# Check that we don't have duplicate entries in PACKAGE_ARCHS
+# Check that we don't have duplicate entries in PACKAGE_ARCHS  that 
TUNE_PKGARCH is in PACKAGE_ARCHS
 pkgarchs = data.getVar('PACKAGE_ARCHS', e.data, True)
+tunepkg = data.getVar('TUNE_PKGARCH', e.data, True)
+tunefound = False
 seen = {}
 dups = []
 
@@ -385,9 +387,15 @@ def check_sanity(e):
dups.append(pa)
else:
seen[pa] = 1
+   if pa == tunepkg:
+   tunefound = True
+
 if len(dups):
messages = messages + Error, the PACKAGE_ARCHS variable contains 
duplicates. The following archs are listed more than once: %s %  .join(dups)
 
+if tunefound == False:
+   messages = messages + Error, the PACKAGE_ARCHS variable does not 
contain TUNE_PKGARCH (%s). % tunepkg
+
 if messages != :
 raise_sanity_error(messages)
 
-- 
1.7.3.4


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

[OE-core] [PATCH] tune/powerpc: Cleanup setting of TUNE_PKGARCH

Add some uniformity to the naming scheme and reduce a bit of redudancy.

Names are now back to: ppc603e, ppce300c2, ppce500, ppce500mc,
ppce500v2.

On 64-bit we'll have something like ppc64e5500.

Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
 meta/conf/machine/include/powerpc/arch-powerpc.inc |5 +++--
 meta/conf/machine/include/tune-ppc603e.inc |2 +-
 meta/conf/machine/include/tune-ppce300c2.inc   |2 +-
 meta/conf/machine/include/tune-ppce500.inc |2 +-
 meta/conf/machine/include/tune-ppce500mc.inc   |2 +-
 meta/conf/machine/include/tune-ppce500v2.inc   |2 +-
 6 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/meta/conf/machine/include/powerpc/arch-powerpc.inc 
b/meta/conf/machine/include/powerpc/arch-powerpc.inc
index 93b1c05..a8226ea 100644
--- a/meta/conf/machine/include/powerpc/arch-powerpc.inc
+++ b/meta/conf/machine/include/powerpc/arch-powerpc.inc
@@ -3,6 +3,7 @@
 # *) Hard Floating Point on 64-bit
 
 DEFAULTTUNE ?= powerpc
+TUNE_PKGARCH ?= ppc
 
 TUNEVALID[m32] = Power ELF32 standard ABI
 TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, m32, -m32, , d)}
@@ -12,6 +13,7 @@ TUNEVALID[m64] = Power ELF64 standard ABI
 TUNE_CONFLICTS[m64] = m32 nf
 TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, m64, -m64, , d)}
 TUNE_ARCH .= ${@bb.utils.contains(TUNE_FEATURES, [ m64 ], powerpc64, 
, d)}
+TUNE_PKGARCH .= ${@bb.utils.contains(TUNE_FEATURES, [ m64 ], 64, , 
d)}
 
 TUNEVALID[fpu-hard] = Use hardware FPU.
 TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, fpu-hard, 
-mhard-float, , d)}
@@ -23,8 +25,7 @@ TARGET_FPU .= ${@bb.utils.contains(TUNE_FEATURES, 
fpu-soft, soft, , d)}
 ABIEXTENSION = ${@['','spe'][d.getVar('TARGET_FPU', True) in ['ppc-efd', 
'ppc-efs']]}
 
 PPCPKGSFX_FPU = ${@bb.utils.contains(TUNE_FEATURES, fpu-soft, -nf, , 
d)}
-
-TUNE_PKGARCH ?= ${TUNE_ARCH}${PPCPKGSFX_FPU}
+TUNE_PKGARCH .= ${PPCPKGSFX_FPU}
 
 # Basic tune definitions
 AVAILTUNES += powerpc powerpc-nf 
diff --git a/meta/conf/machine/include/tune-ppc603e.inc 
b/meta/conf/machine/include/tune-ppc603e.inc
index 7c05394..12ba425 100644
--- a/meta/conf/machine/include/tune-ppc603e.inc
+++ b/meta/conf/machine/include/tune-ppc603e.inc
@@ -4,7 +4,7 @@ require conf/machine/include/powerpc/arch-powerpc.inc
 
 TUNEVALID[ppc603e] = Enable ppc603e specific processor optimizations
 TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, ppc603e, -mcpu=603e, 
, d)}
-TUNE_PKGARCH .= ${@bb.utils.contains(TUNE_FEATURES, ppc603e, ppc603e, 
, d)}
+TUNE_PKGARCH .= ${@bb.utils.contains(TUNE_FEATURES, ppc603e, 603e, , 
d)}
 
 AVAILTUNES += ppc603e
 TUNE_FEATURES_tune-ppc603e = m32 fpu-hard ppc603e
diff --git a/meta/conf/machine/include/tune-ppce300c2.inc 
b/meta/conf/machine/include/tune-ppce300c2.inc
index bad2611..6fe3e42 100644
--- a/meta/conf/machine/include/tune-ppce300c2.inc
+++ b/meta/conf/machine/include/tune-ppce300c2.inc
@@ -4,7 +4,7 @@ require conf/machine/include/powerpc/arch-powerpc.inc
 
 TUNEVALID[ppce300c2] = Enable ppce300c2 specific processor optimizations
 TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, ppce300c2, 
-mcpu=e300c2, , d)}
-TUNE_PKGARCH = ${@bb.utils.contains(TUNE_FEATURES, ppce300c2, 
ppce300c2, ${TUNE_ARCH}, d)}
+TUNE_PKGARCH = ${@bb.utils.contains(TUNE_FEATURES, ppce300c2, e300c2, 
${TUNE_ARCH}, d)}
 
 AVAILTUNES += ppce300c2
 TUNE_FEATURES_tune-ppce300c2 = m32 fpu-soft ppce300c2
diff --git a/meta/conf/machine/include/tune-ppce500.inc 
b/meta/conf/machine/include/tune-ppce500.inc
index c34d631..0e850f1 100644
--- a/meta/conf/machine/include/tune-ppce500.inc
+++ b/meta/conf/machine/include/tune-ppce500.inc
@@ -4,7 +4,7 @@ require conf/machine/include/powerpc/arch-powerpc.inc
 
 TUNEVALID[ppce500] = Enable ppce500 specific processor optimizations
 TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, ppce500, -mcpu=8540, 
, d)}
-TUNE_PKGARCH .= ${@bb.utils.contains(TUNE_FEATURES, ppce500, ppce500, 
, d)}
+TUNE_PKGARCH .= ${@bb.utils.contains(TUNE_FEATURES, ppce500, e500, , 
d)}
 
 TUNEVALID[spe] = Enable SPE ABI extensions
 TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, spe, -mabi=spe 
-mspe, , d)}
diff --git a/meta/conf/machine/include/tune-ppce500mc.inc 
b/meta/conf/machine/include/tune-ppce500mc.inc
index 73217dd..9fee226 100644
--- a/meta/conf/machine/include/tune-ppce500mc.inc
+++ b/meta/conf/machine/include/tune-ppce500mc.inc
@@ -4,7 +4,7 @@ require conf/machine/include/powerpc/arch-powerpc.inc
 
 TUNEVALID[ppce500mc] = Enable ppce500mc specific processor optimizations
 TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, ppce500mc, 
-mcpu=e500mc, , d)}
-TUNE_PKGARCH .= ${@bb.utils.contains(TUNE_FEATURES, ppce500mc, 
ppce500mc, , d)}
+TUNE_PKGARCH .= ${@bb.utils.contains(TUNE_FEATURES, ppce500mc, e500mc, 
, d)}
 
 AVAILTUNES += ppce500mc
 TUNE_FEATURES_tune-ppce500mc = m32 fpu-hard ppce500mc
diff --git a/meta/conf/machine/include/tune-ppce500v2.inc 
b/meta/conf/machine/include/tune-ppce500v2.inc
index 819d68a..2a0451b 100644
---

Re: [OE-core] [PATCH] sanity.bbclass: Add sanity check that TUNE_PKGARCH appears in PACKAGE_ARCHS

2011-07-28 Thread Saul Wold


On 07/28/2011 05:07 PM, Kumar Gala wrote:

Its possible we get duplications if we explicity add TUNE_PKGARCH to
PACKAGE_ARCHS so instead just add a sanity check to verify it.

Signed-off-by: Kumar Galaga...@kernel.crashing.org
---
  meta/classes/sanity.bbclass |   10 +-
  1 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index b054146..999e15d 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -375,8 +375,10 @@ def check_sanity(e):
  elif oeroot.find (' ') != -1:
  messages = messages + Error, you have a space in your COREBASE directory 
path. Please move the installation to a directory which doesn't include a space.

-# Check that we don't have duplicate entries in PACKAGE_ARCHS
+# Check that we don't have duplicate entries in PACKAGE_ARCHS  that 
TUNE_PKGARCH is in PACKAGE_ARCHS
  pkgarchs = data.getVar('PACKAGE_ARCHS', e.data, True)
+tunepkg = data.getVar('TUNE_PKGARCH', e.data, True)
+tunefound = False
  seen = {}
  dups = []

@@ -385,9 +387,15 @@ def check_sanity(e):
dups.append(pa)
else:
seen[pa] = 1
+   if pa == tunepkg:
+   tunefound = True
+
  if len(dups):
 messages = messages + Error, the PACKAGE_ARCHS variable contains duplicates. The 
following archs are listed more than once: %s %  .join(dups)


Kumar,

Thanks for the patch, some questions.

Is this correct, do you still want to report the error, if there is a dup?

Would it not just be better to just drop the dup if it is the TUNE_PKGARCH?

Sau!


+if tunefound == False:
+   messages = messages + Error, the PACKAGE_ARCHS variable does not contain 
TUNE_PKGARCH (%s). % tunepkg
+
  if messages != :
  raise_sanity_error(messages)



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

Re: [OE-core] [PATCH 1/1] python-native: Fix a compiler finding issue

2011-07-28 Thread Mei, Lei



-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
Tom Rini
Sent: Thursday, July 28, 2011 11:09 PM
To: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH 1/1] python-native: Fix a compiler finding issue

On 07/28/2011 12:20 AM, Mei Lei wrote:
 The CC variable sometimes add option information after compiler name, but
python can't get the real compiler name if those information added.
 Fix this issue by dropping the option information when finding compiler name.

 Signed-off-by: Mei Lei lei@intel.com

I think this is going to cause problems when you must pass flags to gcc
to have it work, eg 'gcc -m64'.

This patch fixed your worried issue.
The CC variable, sometimes like:  x86_64-poky-linux-gcc -m64 
--sysroot=/${TMPDIR}/sysroots/qemux86-64, contains flags information. 
This will lead to wrong compiler name qemux86-64 rather than 
x86_64-poky-linux-gcc when python finding the compiler name, so add this 
patch to find the real gcc name.

Thanks
Lei 



--
Tom Rini
Mentor Graphics Corporation

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

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

Re: [OE-core] [PATCH] sanity.bbclass: Add sanity check that TUNE_PKGARCH appears in PACKAGE_ARCHS


On Jul 28, 2011, at 7:41 PM, Saul Wold wrote:

 On 07/28/2011 05:07 PM, Kumar Gala wrote:
 Its possible we get duplications if we explicity add TUNE_PKGARCH to
 PACKAGE_ARCHS so instead just add a sanity check to verify it.
 
 Signed-off-by: Kumar Galaga...@kernel.crashing.org
 ---
  meta/classes/sanity.bbclass |   10 +-
  1 files changed, 9 insertions(+), 1 deletions(-)
 
 diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
 index b054146..999e15d 100644
 --- a/meta/classes/sanity.bbclass
 +++ b/meta/classes/sanity.bbclass
 @@ -375,8 +375,10 @@ def check_sanity(e):
  elif oeroot.find (' ') != -1:
  messages = messages + Error, you have a space in your COREBASE 
 directory path. Please move the installation to a directory which doesn't 
 include a space.
 
 -# Check that we don't have duplicate entries in PACKAGE_ARCHS
 +# Check that we don't have duplicate entries in PACKAGE_ARCHS  that 
 TUNE_PKGARCH is in PACKAGE_ARCHS
  pkgarchs = data.getVar('PACKAGE_ARCHS', e.data, True)
 +tunepkg = data.getVar('TUNE_PKGARCH', e.data, True)
 +tunefound = False
  seen = {}
  dups = []
 
 @@ -385,9 +387,15 @@ def check_sanity(e):
  dups.append(pa)
  else:
  seen[pa] = 1
 +if pa == tunepkg:
 +tunefound = True
 +
  if len(dups):
 messages = messages + Error, the PACKAGE_ARCHS variable contains 
 duplicates. The following archs are listed more than once: %s %  
 .join(dups)
 
 Kumar,
 
 Thanks for the patch, some questions.
 
 Is this correct, do you still want to report the error, if there is a dup?
 
 Would it not just be better to just drop the dup if it is the TUNE_PKGARCH?

I wasn't sure how to drop the dup. :)

If there is a way to uniq PACKAGE_ARCHS that would be fine 

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

[OE-core] [PATCH 0/2] update distro tracking fields V2

From: Kang Kai kai.k...@windriver.com

Hi Saul,
  
I update the libnewt SRC_URI and checksum. Because the bb file is libnewt and 
the source
file is newt, so I write the SRC_URI with newt-${PV}.

Update the distro tracking fields of mailx slang libnewt and alsa-tools.

Because the mailx license file COPYING has lots of copyrights including 
personal,
company and MPL. I have no idea how to update the LICENSE and so keep the 
STATUS red.
Do you have any suggestion about this?

Thank you! 


The following changes since commit 860a41bae6b863a289b06a9684d9cf6c58a307bd:

  arch-ia32.inc: Fix up TUNE_ARCH variable conflicts (2011-07-26 22:39:59 +0100)

are available in the git repository at:
  git://git.pokylinux.org/poky-contrib kangkai/distro
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=kangkai/distro

Kang Kai (2):
  libnewt: update to 0.52.13
  distro_tracking_fields: update packages info

 .../conf/distro/include/distro_tracking_fields.inc |   28 +---
 .../newt/files/include-without-python.patch|   73 
 .../{libnewt_0.52.12.bb = libnewt_0.52.13.bb} |   10 ++-
 meta/recipes-extended/slang/slang_2.2.4.bb |1 +
 .../recipes-multimedia/alsa/alsa-tools_1.0.24.1.bb |9 ++-
 5 files changed, 31 insertions(+), 90 deletions(-)
 delete mode 100644 
meta/recipes-extended/newt/files/include-without-python.patch
 rename meta/recipes-extended/newt/{libnewt_0.52.12.bb = libnewt_0.52.13.bb} 
(80%)

-- 
1.7.5.1.300.gc565c


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

[OE-core] [PATCH 2/2] distro_tracking_fields: update packages info

From: Kang Kai kai.k...@windriver.com

update distro tracking fields of libnewt mailx slang and alsa-tools.

Signed-off-by: Kang Kai kai.k...@windriver.com
---
 .../conf/distro/include/distro_tracking_fields.inc |   28 ---
 meta/recipes-extended/slang/slang_2.2.4.bb |1 +
 .../recipes-multimedia/alsa/alsa-tools_1.0.24.1.bb |9 --
 3 files changed, 25 insertions(+), 13 deletions(-)

diff --git a/meta/conf/distro/include/distro_tracking_fields.inc 
b/meta/conf/distro/include/distro_tracking_fields.inc
index 3a3991d..974f6bd 100644
--- a/meta/conf/distro/include/distro_tracking_fields.inc
+++ b/meta/conf/distro/include/distro_tracking_fields.inc
@@ -5697,8 +5697,13 @@ RECIPE_MAINTAINER_pn-docbook-utils = Scott Garman 
scott.a.gar...@intel.com
 RECIPE_LATEST_VERSION_pn-task-qte-toolchain-target = 1.0
 RECIPE_MANUAL_CHECK_DATE_pn-task-qte-toolchain-target = Feb 28, 2011
 DISTRO_PN_ALIAS_pn-task-qte-toolchain-target = Intel
-RECIPE_LATEST_VERSION_pn-mailx = 12.4
-RECIPE_MANUAL_CHECK_DATE_pn-mailx = Feb 28, 2011
+
+RECIPE_STATUS_pn-mailx = red
+RECIPE_LATEST_VERSION_pn-mailx = 12.5
+RECIPE_LAST_UPDATE_pn-mailx = Jul 1, 2011
+RECIPE_MANUAL_CHECK_DATE_pn-mailx = Jul 28, 2011
+RECIPE_MAINTAINER_pn-mailx = Kai Kang kai.k...@windriver.com
+
 RECIPE_LATEST_VERSION_pn-libgcc = 4.5.1
 RECIPE_MANUAL_CHECK_DATE_pn-libgcc = Feb 28, 2011
 
@@ -5724,13 +5729,15 @@ RECIPE_MAINTAINER_pn-linuxdoc-tools = Scott Garman 
scott.a.gar...@intel.com
 
 RECIPE_STATUS_pn-slang = green
 RECIPE_LATEST_VERSION_pn-slang = 2.2.4
-RECIPE_LAST_UPDATE_pn-slang = Apr 10, 2011
-RECIPE_MANUAL_CHECK_DATE_pn-slang = Jun 6, 2011
+RECIPE_LAST_UPDATE_pn-slang = Jul 28, 2011
+RECIPE_MANUAL_CHECK_DATE_pn-slang = Jun 28, 2011
+RECIPE_MAINTAINER_pn-slang = Kai Kang kai.k...@windriver.com
 
 RECIPE_STATUS_pn-libnewt = green
-RECIPE_LATEST_VERSION_pn-libnewt = 0.52.12
-RECIPE_LAST_UPDATE_pn-libnewt = Aug 06, 2010
-RECIPE_MANUAL_CHECK_DATE_pn-libnewt = Jun 4, 2011
+RECIPE_LATEST_VERSION_pn-libnewt = 0.52.13
+RECIPE_MAINTAINER_pn-libnewt = Kai Kang kai.k...@windriver.com
+RECIPE_LAST_UPDATE_pn-libnewt = Jul 27, 2011
+RECIPE_MANUAL_CHECK_DATE_pn-libnewt = Jul 27, 2011
 RECIPE_NO_UPDATE_REASON_pn-libnewt = 
 
 RECIPE_STATUS_pn-createrepo = green
@@ -5762,10 +5769,11 @@ RECIPE_COMMENTS_pn-rxvt-unicode = 
 RECIPE_LAST_UPDATE_pn-rxvt-unicode = May 25, 2011
 RECIPE_MAINTAINER_pn-rxvt-unicode = Saul Wold s...@linux.intel.com
 
-RECIPE_STATUS_pn-alsa-tools = red
+RECIPE_STATUS_pn-alsa-tools = green
 RECIPE_LATEST_VERIONS_pn-alsa-tools = 1.0.24.1
-RECIPE_LAST_UPDATE_pn-alsa-tools = Jan 31, 2011
-RECIPE_MANUAL_CHECK_DATE_pn-alsa-tools = Jun 7, 2011 
+RECIPE_LAST_UPDATE_pn-alsa-tools = Jul 28, 2011
+RECIPE_MANUAL_CHECK_DATE_pn-alsa-tools = Jul 28, 2011
+RECIPE_MAINTAINER_pn-alsa-tools = Kai Kang kai.k...@windriver.com
 
 RECIPE_STATUS_pn-mesa-demos = red
 RECIPE_LATEST_VERSION_pn-mesa-demos = 8.0.1
diff --git a/meta/recipes-extended/slang/slang_2.2.4.bb 
b/meta/recipes-extended/slang/slang_2.2.4.bb
index 4bf5737..e13f0ad 100644
--- a/meta/recipes-extended/slang/slang_2.2.4.bb
+++ b/meta/recipes-extended/slang/slang_2.2.4.bb
@@ -7,6 +7,7 @@ The S-Lang library, provided in this package, provides the 
S-Lang \
 extension language.  S-Lang's syntax resembles C, which makes it easy \
 to recode S-Lang procedures in C if you need to.
 
+HOMEPAGE = http://www.jedsoft.org/slang/;
 SECTION = libs
 DEPENDS = pcre
 PR = r5
diff --git a/meta/recipes-multimedia/alsa/alsa-tools_1.0.24.1.bb 
b/meta/recipes-multimedia/alsa/alsa-tools_1.0.24.1.bb
index 1bf9cd0..d6ecf7f 100644
--- a/meta/recipes-multimedia/alsa/alsa-tools_1.0.24.1.bb
+++ b/meta/recipes-multimedia/alsa/alsa-tools_1.0.24.1.bb
@@ -1,13 +1,16 @@
 BROKEN = 1
 
-DESCRIPTION = Alsa Tools
+DESCRIPTION = Alsa Tools package contains advanced tools for certain sound 
cards.
+HOMEPAGE = http://www.alsa-project.org;
+BUGTRACKER = https://bugtrack.alsa-project.org/alsa-bug/login_page.php;
 SECTION = console/utils
-LICENSE = GPLv2
+LICENSE = GPLv2  LGPLv2+
 DEPENDS = alsa-lib ncurses
 
 PR = r2
 
-LIC_FILES_CHKSUM = 
file://hdsploader/COPYING;md5=94d55d512a9ba36caa9b7df079bae19f
+LIC_FILES_CHKSUM = 
file://hdsploader/COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
+
file://ld10k1/COPYING.LIB;md5=7fbc338309ac38fefcd64b04bb903e34
 
 SRC_URI = ftp://ftp.alsa-project.org/pub/tools/alsa-tools-${PV}.tar.bz2 \
file://autotools.patch
-- 
1.7.5.1.300.gc565c


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

[OE-core] [PATCH 0/2] update distro tracking fields V3

From: Kang Kai kai.k...@windriver.com

Hi Saul,
  
v3 update the mailx license.

I update the libnewt SRC_URI and checksum. Because the bb file is libnewt and 
the source
file is newt, so I write the SRC_URI with newt-${PV}.

Update the distro tracking fields of mailx slang libnewt and alsa-tools.

Thank you!

The following changes since commit 860a41bae6b863a289b06a9684d9cf6c58a307bd:

  arch-ia32.inc: Fix up TUNE_ARCH variable conflicts (2011-07-26 22:39:59 +0100)

are available in the git repository at:
  git://git.pokylinux.org/poky-contrib kangkai/distro
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=kangkai/distro

Kang Kai (2):
  libnewt: update to 0.52.13
  distro_tracking_fields: update packages info

 .../conf/distro/include/distro_tracking_fields.inc |   28 +---
 meta/recipes-extended/mailx/mailx_12.5.bb  |2 +-
 .../newt/files/include-without-python.patch|   73 
 .../{libnewt_0.52.12.bb = libnewt_0.52.13.bb} |   10 ++-
 meta/recipes-extended/slang/slang_2.2.4.bb |1 +
 .../recipes-multimedia/alsa/alsa-tools_1.0.24.1.bb |9 ++-
 6 files changed, 32 insertions(+), 91 deletions(-)
 delete mode 100644 
meta/recipes-extended/newt/files/include-without-python.patch
 rename meta/recipes-extended/newt/{libnewt_0.52.12.bb = libnewt_0.52.13.bb} 
(80%)

-- 
1.7.5.1.300.gc565c


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

[OE-core] [PATCH 2/2] distro_tracking_fields: update packages info