date:20120927

[OE-core] [PATCH] sstate-cache-management: hide error message when one of possible layer location doesn't exist

2012-09-27 Thread Martin Jansa

* fixes [YOCTO #3116]

Signed-off-by: Martin Jansa 
---
 scripts/sstate-cache-management.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/sstate-cache-management.sh 
b/scripts/sstate-cache-management.sh
index f519555..4c06fe8 100755
--- a/scripts/sstate-cache-management.sh
+++ b/scripts/sstate-cache-management.sh
@@ -174,7 +174,7 @@ remove_duplicated () {
   topdir=$(dirname $oe_core_dir)
   tunedirs="`find $topdir/meta* ${oe_core_dir}/meta* $layers -path 
'*/meta*/conf/machine/include'`"
   [ -n "$tunedirs" ] || echo_error "Can't find the tune directory"
-  all_machines="`find $topdir/meta* ${oe_core_dir}/meta* $layers -path 
'*/meta*/conf/machine/*' -name '*.conf' | sed -e 's/.*\///' -e 's/.conf$//'`"
+  all_machines="`find $topdir/meta* ${oe_core_dir}/meta* $layers -path 
'*/meta*/conf/machine/*' -name '*.conf' 2>/dev/null | sed -e 's/.*\///' -e 
's/.conf$//'`"
   all_archs=`grep -r -h "^AVAILTUNES .*=" $tunedirs | sed -e 's/.*=//' -e 
's/\"//g'`
   # Add the qemu and native archs
   # Use the "_" to substitute "-", e.g., x86-64 to x86_64
-- 
1.7.12


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

[OE-core] [PATCH 0/1] autotools.bbclass: using relative paths for acpaths

2012-09-27 Thread wenzong.fan

From: Wenzong Fan 

Fix autotools.bbclass to use relative paths for acpaths instead of
absolute ones. Since absolute paths may cause potential autoreconf
error like:

Can't exec "/bin/sh": Argument list too long ...

This error occurs while building coreutils with long TMPDIR, because
it has bunch of m4 files need to be expanded.

[YOCTO #2766]

The following changes since commit 0b09e50810162a07ef0aecee91ee32b4a36334a3:

  busybox: Fix misplaced quote (2012-09-26 18:28:36 +0100)

are available in the git repository at:

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

Wenzong Fan (1):
  autotools.bbclass: using relative paths for acpaths

 meta/classes/autotools.bbclass |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

-- 
1.7.9.5


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

[OE-core] [PATCH 1/1] autotools.bbclass: using relative paths for acpaths

2012-09-27 Thread wenzong.fan

From: Wenzong Fan 

Fix autotools.bbclass to use relative paths for acpaths instead of
absolute ones. Since absolute paths may cause potential autoreconf
error like:

Can't exec "/bin/sh": Argument list too long ...

This error occurs while building coreutils with long TMPDIR, because
it has bunch of m4 files need to be expanded.

[YOCTO #2766]

Signed-off-by: Wenzong Fan 
---
 meta/classes/autotools.bbclass |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/classes/autotools.bbclass b/meta/classes/autotools.bbclass
index e4e034b..874e01d 100644
--- a/meta/classes/autotools.bbclass
+++ b/meta/classes/autotools.bbclass
@@ -130,7 +130,8 @@ autotools_do_configure() {
if [ x"${acpaths}" = xdefault ]; then
acpaths=
for i in `find ${S} -maxdepth 2 -name \*.m4|grep -v 
'aclocal.m4'| \
-   grep -v 'acinclude.m4' | sed -e 
's,\(.*/\).*$,\1,'|sort -u`; do
+   grep -v 'acinclude.m4' | sed -e 
's,\(.*/\).*$,\1,'|sort -u| \
+   sed -e 's,${S},\.,'`; do
acpaths="$acpaths -I $i"
done
else
-- 
1.7.9.5


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

Re: [OE-core] [oe-core][RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default

2012-09-27 Thread Martin Jansa

On Sat, Sep 22, 2012 at 06:45:44PM +0100, Richard Purdie wrote:
> On Sat, 2012-09-22 at 18:51 +0200, Martin Jansa wrote:
> > * bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE
> > * this way xscale or arm926ejs is not used by default when some machine
> >   includes its tune*.inc, but it's easy for DISTRO to say it wants
> >   OPTDEFAULTTUNE for some packages or always (if they don't want to
> >   share built packages between xscale and arm926ejs).
> > 
> > Signed-off-by: Martin Jansa 
> > ---
> >  meta/conf/bitbake.conf   | 1 +
> >  meta/conf/machine/include/tune-arm926ejs.inc | 3 ++-
> >  meta/conf/machine/include/tune-xscale.inc| 3 ++-
> >  3 files changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> > index 9b41749..e433fcb 100644
> > --- a/meta/conf/bitbake.conf
> > +++ b/meta/conf/bitbake.conf
> > @@ -95,6 +95,7 @@ HOST_LD_ARCH = "${TARGET_LD_ARCH}"
> >  HOST_AS_ARCH = "${TARGET_AS_ARCH}"
> >  HOST_EXEEXT = ""
> >  
> > +OPTDEFAULTTUNE ??= "${DEFAULTTUNE}"
> >  TUNE_ARCH ??= "INVALID"
> >  TUNE_CCARGS ??= ""
> >  TUNE_LDARGS ??= ""
> 
> As I've said previously, I do not think OPTDEFAULTTUNE is clear in usage
> or in meaning and we need to find a better solution. I'm therefore not
> keen on this change.

OK, what about the rest of patchset (without OPTDEFAULTTUNE bits) to use
different PKGARCH for different TUNE_CCARGS?
 
> I also still think this is a distro packaging issue and should be solved
> by the distro, even if that means more complexity there. That is the
> right place for this particular complexity IMO. I'm happy to support
> that from the core but not in something as user visible and confusing as
> this variable.

Agreed OPTDEFAULTTUNE is to help distro configs, because complexity
there will be much worse then when it's defined in tune-* files, because
now will have to define DEFAULTTUNE/OPTDEFAULTTUNE for each MACHINE (or
TUNE_FEATURE) it supports and it's less orthogonal (machine/distro
config) then it could be.

Cheers,

-- 
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

[OE-core] [PATCH] gnome-keyring: include unpackaged files with PAM enabled

2012-09-27 Thread Constantin Musca

Include missing files/dirs:
${base_libdir}/security/*.la
${base_libdir}/security/*${SOLIBSDEV}
${base_libdir}/security/.debug/

[YOCTO #2805]

Signed-off-by: Constantin Musca 
---
 meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb |9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb 
b/meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb
index d822721..92e0e1b 100644
--- a/meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb
+++ b/meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb
@@ -11,7 +11,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
 
 SECTION = "x11/gnome"
 
-PR = "r9"
+PR = "r10"
 
 inherit autotools gnome gtk-doc pkgconfig
 
@@ -43,7 +43,10 @@ FILES_${PN} += "${datadir}/dbus-1/services ${datadir}/gcr"
 
 FILES_${PN}-dev += "${libdir}/${BPN}/devel/*.la \
 ${libdir}/${BPN}/devel/*${SOLIBSDEV} \
-${libdir}/${BPN}/standalone/*.la"
+${libdir}/${BPN}/standalone/*.la \
+${base_libdir}/security/*.la \
+${base_libdir}/security/*${SOLIBSDEV}"
 
 FILES_${PN}-dbg += "${libdir}/${BPN}/standalone/.debug/ \
-${libdir}/${BPN}/devel/.debug/"
+${libdir}/${BPN}/devel/.debug/ \
+${base_libdir}/security/.debug/"
-- 
1.7.9.5


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

Re: [OE-core] [PATCH] gdk-pixbuf: Use qemu to run postinsts in offline root mode

2012-09-27 Thread Phil Blundell

On Wed, 2012-09-26 at 13:28 +0100, Phil Blundell wrote:
> On Wed, 2012-09-26 at 14:23 +0200, Martin Jansa wrote:
> > On Wed, Sep 26, 2012 at 01:11:44PM +0100, Phil Blundell wrote:
> > > This makes it possible to use gdk-pixbuf on a read-only rootfs.
> > 
> > Isn't this issue resolved in "[RFC 0/7] Postinstall improvements" too?
> 
> Ah, possibly.  I haven't really been following that thread.  I'll take a
> look.

I found the patch that I guess you were referring to:

http://lists.linuxtogo.org/pipermail/openembedded-core/2012-September/029913.html

Personally I don't like that solution so much; the reliance on
NATIVE_ROOT containing the appropriate bits seems a bit fragile.  But I
suppose it's a matter of opinion.

p.



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

Re: [OE-core] perl-nativesdk interesting fail in do_install

2012-09-27 Thread Christian Glindkamp

On 2012-09-24 12:28, Marcin Juszkiewicz wrote:
> I want to build 'meta-toolchain' but on my Ubuntu 12.10 it fails on
> 'nativesdk-perl' recipe in do_install:
> 
> |
> /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/perl/5.14.2/pod/perlxstut.pod
> |
> /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/perl/5.14.2/pod/a2p.pod
> |
> | Warning: perl appears in your path in the following locations beyond where
> | we just installed it:
> |
> /home/hrw/HDD/devel/canonical/ci-linaro/oecore/build/tmp-eglibc/sysroots/x86_64-linux/usr/bin/perl-native/perl
> | /usr/bin/perl
> |
> | make[1]: Nothing to be done for `install.man'.
> | make[1]: Leaving directory
> `/home/hrw/HDD/devel/canonical/ci-linaro/oecore/build/tmp-eglibc/work/x86_64-nativesdk-oesdk-linux/nativesdk-perl-5.14.2-r9/perl-5.14.2'
> |
> /home/hrw/HDD/devel/canonical/ci-linaro/oecore/build/tmp-eglibc/work/x86_64-nativesdk-oesdk-linux/nativesdk-perl-5.14.2-r9/image
> /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin
> | ln: failed to create symbolic link
> `/home/hrw/HDD/devel/canonical/ci-linaro/oecore/build/tmp-eglibc/work/x86_64-nativesdk-oesdk-linux/nativesdk-perl-5.14.2-r9/image/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/perl':
> No such file or directory
> | ERROR: Function failed: do_install (see
> /home/hrw/HDD/devel/canonical/ci-linaro/oecore/build/tmp-eglibc/work/x86_64-nativesdk-oesdk-linux/nativesdk-perl-5.14.2-r9/temp/log.do_install.24991
> for further information)
> ERROR: Task 2
> (virtual:nativesdk:/home/hrw/HDD/devel/canonical/ci-linaro/oecore/openembedded-core/meta/recipes-devtools/perl/perl_5.14.2.bb,
> do_install) failed with exit code '1'
> 
> Perl is installed as /home/hrw/HDD/devel/canonical/ci-linaro/ \
> oecore/build/tmp-eglibc/work/x86_64-nativesdk-oesdk-linux/ \
> nativesdk-perl-5.14.2-r9/image/ \
> usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/ \
> usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/ \
> usr/bin/perl
> 
> Note repeated "/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux" in
> path.
> 
> Any idea how it happened? Did someone built 'meta-toolchain' recently?

I'm having the same error at the moment. I suppose commit
38234f2e276356b1d77a87ceabc486107e336d19 was meant to fix the issue, but
it doesn't.

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

[OE-core] [PATCH] eglibc: Remove bogus PACKAGES_DYNAMIC setting

2012-09-27 Thread Phil Blundell

It transpires that eglibc has been setting PACKAGES_DYNAMIC = "libc6*" for
some time.  However, this is bogus for at least two reasons:

1. Bitbake interprets PACKAGES_DYNAMIC as a regex, not a glob, so this will
match against any package whose name starts "libc" plus zero or more sixes.
This is particularly toxic because the nativesdk variant picks up the same
value and will, consequently, start trying to build itself at the slightest
excuse.

2. eglibc doesn't actually build any packages named "libc6", other
than the ones that are named in PACKAGES anyway, so the dynamic provider
declaration is in any case useless.

Simply deleting the line is not sufficient since then we get the default
value from bitbake.conf which causes eglibc.bb to fight with eglibc-locale.bb.
So instead we must set it to the empty string for good results.

Signed-off-by: Phil Blundell 
---
 meta/recipes-core/eglibc/eglibc_2.16.bb |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-core/eglibc/eglibc_2.16.bb 
b/meta/recipes-core/eglibc/eglibc_2.16.bb
index 3a7ae50..b37922d 100644
--- a/meta/recipes-core/eglibc/eglibc_2.16.bb
+++ b/meta/recipes-core/eglibc/eglibc_2.16.bb
@@ -43,7 +43,8 @@ SRC_URI_append_virtclass-nativesdk = " 
file://ld-search-order.patch \
 S = "${WORKDIR}/${EGLIBC_BRANCH}/libc"
 B = "${WORKDIR}/build-${TARGET_SYS}"
 
-PACKAGES_DYNAMIC = "libc6*"
+PACKAGES_DYNAMIC = ""
+
 RPROVIDES_${PN}-dev = "libc6-dev virtual-libc-dev"
 PROVIDES_${PN}-dbg = "glibc-dbg"
 
-- 
1.7.10.4




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

[OE-core] [PATCH] perl: Fix nativesdk install path

2012-09-27 Thread Christian Glindkamp

Commit 38234f2e276356b1d77a87ceabc486107e336d19 tried to fix the sed
expressions by anchoring the left side of the search regexp to prevent
$prefix$prefix type expression in the perl config. For nativesdk this is
not enough. Adding anchors on both side fixes this.

Signed-off-by: Christian Glindkamp 
---

This is currently only build tested, but buildhistory for perl did not change.

 meta/recipes-devtools/perl/perl_5.14.2.bb |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-devtools/perl/perl_5.14.2.bb 
b/meta/recipes-devtools/perl/perl_5.14.2.bb
index 3c1360f..0009855 100644
--- a/meta/recipes-devtools/perl/perl_5.14.2.bb
+++ b/meta/recipes-devtools/perl/perl_5.14.2.bb
@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM = 
"file://Copying;md5=2b4c6ffbcfcbdee469f02565f253d81a \
 # We need gnugrep (for -I)
 DEPENDS = "virtual/db grep-native"
 DEPENDS += "gdbm zlib"
-PR = "r9"
+PR = "r10"
 
 # 5.10.1 has Module::Build built-in
 PROVIDES += "libmodule-build-perl"
@@ -150,9 +150,9 @@ do_configure() {
-e 's,@ARCH@-thread-multi,,g' \
-e 's,@ARCH@,${TARGET_ARCH}-${TARGET_OS},g' \
-e 's,@STAGINGDIR@,${STAGING_DIR_HOST},g' \
-   -e "s%\([ \"^\',=]\+\)/usr/include%\1${STAGING_INCDIR}%g" \
-  -e "s%\([ \"^\',=]\+\)/usr/lib/%\1${libdir}/%g" \
-  -e "s%\([ \"^\',=]\+\)/usr/%\1${exec_prefix}/%g" \
+   -e "s%\([ \"^\',=]\+\)/usr/include\([ 
\"^\',=]\+\)%\1${STAGING_INCDIR}\2%g" \
+  -e "s%\([ \"^\',=]\+\)/usr/lib/\([ 
\"^\',=]\+\)%\1${libdir}/\2%g" \
+  -e "s%\([ \"^\',=]\+\)/usr/\([ 
\"^\',=]\+\)%\1${exec_prefix}/\2%g" \
   -e "s%/perl5%/perl%g" \
 config.sh-${TARGET_ARCH}-${TARGET_OS}
 
-- 
1.7.2.5


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

[OE-core] overuse of bitbake flags considered harmful

2012-09-27 Thread Phil Blundell

I was mildly amused to discover, the other day, that the output of
"bitbake -e rpm | grep PACKAGECONFIG" is not quite as one might naïvely
expect.  

I guess the right response to this is perhaps that bitbake ought
nowadays to find some other way to store its own internal state, since
the idiom of using flags is pretty well established in oe-core.

p.



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

[OE-core] [PATCH 1/3] siteinfo.bbclass: add AArch64 support

2012-09-27 Thread Marcin Juszkiewicz

Signed-off-by: Marcin Juszkiewicz 
---
 meta/classes/siteinfo.bbclass |2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/classes/siteinfo.bbclass b/meta/classes/siteinfo.bbclass
index 8c256ce..aab0867 100644
--- a/meta/classes/siteinfo.bbclass
+++ b/meta/classes/siteinfo.bbclass
@@ -18,6 +18,7 @@
 def siteinfo_data(d):
 archinfo = {
 "allarch": "endian-little bit-32", # bogus, but better than 
special-casing the checks below for allarch
+"aarch64": "endian-little bit-64 arm-common",
 "arm": "endian-little bit-32 arm-common",
 "armeb": "endian-big bit-32 arm-common",
 "avr32": "endian-big bit-32 avr32-common",
@@ -60,6 +61,7 @@ def siteinfo_data(d):
 "mingw32": "common-mingw",
 }
 targetinfo = {
+"aarch64-linux-gnu": "aarch64-linux",
 "arm-linux-gnueabi": "arm-linux",
 "arm-linux-uclibceabi": "arm-linux-uclibc",
 "armeb-linux-gnueabi": "armeb-linux",
-- 
1.7.10.4


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

[OE-core] Add AArch64 support into OE-Core

2012-09-27 Thread Marcin Juszkiewicz

This patchset adds support for AArch64 in all required classes:

- insane
- kernel-arch
- siteinfo

Everything is from public available information (binutils, linux).


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

[OE-core] [PATCH 2/3] kernel-arch.bblass: add AArch64 support

2012-09-27 Thread Marcin Juszkiewicz

Signed-off-by: Marcin Juszkiewicz 
---
 meta/classes/kernel-arch.bbclass |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/classes/kernel-arch.bbclass b/meta/classes/kernel-arch.bbclass
index 6446504..b3b78b6 100644
--- a/meta/classes/kernel-arch.bbclass
+++ b/meta/classes/kernel-arch.bbclass
@@ -8,7 +8,7 @@ valid_archs = "alpha cris ia64 \
i386 x86 \
m68knommu m68k ppc powerpc powerpc64 ppc64  \
sparc sparc64 \
-   arm \
+   arm aarch64 \
m32r mips \
sh sh64 um h8300   \
parisc s390  v850 \
@@ -22,6 +22,7 @@ def map_kernel_arch(a, d):
 
 if   re.match('(i.86|athlon|x86.64)$', a):  return 'x86'
 elif re.match('armeb$', a): return 'arm'
+elif re.match('aarch64$', a):   return 'arm64'
 elif re.match('mips(el|64|64el)$', a):  return 'mips'
 elif re.match('p(pc|owerpc)(|64)', a):  return 'powerpc'
 elif re.match('sh(3|4)$', a):   return 'sh'
-- 
1.7.10.4


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

[OE-core] [PATCH 3/3] insane.bbclass: add AArch64 support

2012-09-27 Thread Marcin Juszkiewicz

Signed-off-by: Marcin Juszkiewicz 
---
 meta/classes/insane.bbclass |1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 1fb8970..b390242 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -44,6 +44,7 @@ def package_qa_get_machine_dict():
 "arm" :   (40, 0,0,  True, 
 32),
   },
 "linux" : { 
+"aarch64" :   (183,0,0,  True, 
 64),
 "arm" :   (40,97,0,  True, 
 32),
 "armeb":  (40,97,0,  False,
 32),
 "powerpc":(20, 0,0,  False,
 32),
-- 
1.7.10.4


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

[OE-core] [PATCH v2] sanity.bbclass: bblayers.conf should be updated automatically

2012-09-27 Thread Constantin Musca

- add check_bblayers_conf bitbake function which does the bblayers.conf
v4 -> v5 update if necessary (every layer should make its specific
bblayers.conf upgrades appending to the check_bblayers_conf function)
- we ask the user to re-run bitbake because we can't trigger reparsing
without being invasive

[YOCTO #3082]

Signed-off-by: Constantin Musca 
---
 meta/classes/sanity.bbclass |   61 ++-
 1 file changed, 60 insertions(+), 1 deletion(-)

diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index 385d733..9c3ab1f 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -4,6 +4,56 @@
 
 SANITY_REQUIRED_UTILITIES ?= "patch diffstat makeinfo git bzip2 tar gzip gawk 
chrpath wget cpio"
 
+python check_bblayers_conf() {
+bblayers_fn = os.path.join(d.getVar('TOPDIR', True), 'conf/bblayers.conf')
+
+current_lconf = int(d.getVar('LCONF_VERSION', True))
+if not current_lconf:
+sys.exit()
+lconf_version = int(d.getVar('LAYER_CONF_VERSION', True))
+lines = []
+
+import re
+def find_line(pattern, lines):
+return next(((index, line)
+for index, line in enumerate(lines)
+if re.search(pattern, line)), (None, None))
+
+if current_lconf < 4:
+sys.exit()
+
+with open(bblayers_fn, 'r') as f:
+lines = f.readlines()
+
+if current_lconf == 4:
+topdir_var = '$' + '{TOPDIR}'
+index, bbpath_line = find_line('BBPATH', lines)
+if bbpath_line:
+start = bbpath_line.find('"')
+if start != -1 and (len(bbpath_line) != (start + 1)):
+if bbpath_line[start + 1] == '"':
+lines[index] = (bbpath_line[:start + 1] +
+topdir_var + bbpath_line[start + 1:])
+else:
+if not topdir_var in bbpath_line:
+lines[index] = (bbpath_line[:start + 1] +
+topdir_var + ':' + bbpath_line[start + 1:])
+else:
+sys.exit()
+else:
+index, bbfiles_line = find_line('BBFILES', lines)
+if bbfiles_line:
+lines.insert(index, 'BBPATH = "' + topdir_var + '"\n')
+else:
+sys.exit()
+
+index, line = find_line('LCONF_VERSION', lines)
+current_lconf += 1
+lines[index] = 'LCONF_VERSION = "%d"\n' % current_lconf
+with open(bblayers_fn, "w") as f:
+f.write(''.join(lines))
+}
+
 def raise_sanity_error(msg, d):
 if d.getVar("SANITY_USE_EVENTS", True) == "1":
 bb.event.fire(bb.event.SanityCheckFailed(msg), d)
@@ -337,7 +387,16 @@ def check_sanity(sanity_data):
 current_lconf = sanity_data.getVar('LCONF_VERSION', True)
 lconf_version = sanity_data.getVar('LAYER_CONF_VERSION', True)
 if current_lconf != lconf_version:
-messages = messages + "Your version of bblayers.conf was generated 
from an older version of bblayers.conf.sample and there have been updates made 
to this file. Please compare the two files and merge any changes before 
continuing.\nMatching the version numbers will remove this message.\n\"meld 
conf/bblayers.conf ${COREBASE}/meta*/conf/bblayers.conf.sample\" is a good way 
to visualise the changes.\n"
+try:
+bb.build.exec_func("check_bblayers_conf", sanity_data)
+if sanity_data.getVar("SANITY_USE_EVENTS", True) == "1":
+bb.event.fire(bb.event.SanityCheckFailed("Your 
conf/bblayers.conf has been automatically updated. Please close and re-run."), 
sanity_data)
+return
+else:
+bb.note("Your conf/bblayers.conf has been automatically 
updated. Please re-run %s." % os.path.basename(sys.argv[0]))
+sys.exit(0)
+except Exception:
+messages = messages + "Your version of bblayers.conf was generated 
from an older version of bblayers.conf.sample and there have been updates made 
to this file. Please compare the two files and merge any changes before 
continuing.\nMatching the version numbers will remove this message.\n\"meld 
conf/bblayers.conf ${COREBASE}/meta*/conf/bblayers.conf.sample\" is a good way 
to visualise the changes.\n"
 
 # If we have a site.conf, check it's valid
 if check_conf_exists("conf/site.conf", sanity_data):
-- 
1.7.9.5


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

[OE-core] [PATCH] cml1.bbclass: Convert tab indentation in python functions into four-space

2012-09-27 Thread Jason Wessel

Based on the previous commit 604d46c686d06d62d5a07b9c7f4fa170f99307d8
(Convert tab indentation in python functions into four-space), the
cml.bbclass was not converted, and in order to properly extend it
with external bbappend's it needs to be converted.

Signed-off-by: Jason Wessel 
---
 meta/classes/cml1.bbclass |   28 ++--
 1 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/meta/classes/cml1.bbclass b/meta/classes/cml1.bbclass
index 37ed792..ba44196 100644
--- a/meta/classes/cml1.bbclass
+++ b/meta/classes/cml1.bbclass
@@ -15,23 +15,23 @@ HOSTLDFLAGS = "${BUILD_LDFLAGS}"
 HOST_LOADLIBES = "-lncurses"
 
 python do_menuconfig() {
-try:
-mtime = os.path.getmtime(".config")
-except OSError:
-mtime = 0
+try:
+mtime = os.path.getmtime(".config")
+except OSError:
+mtime = 0
 
-oe_terminal("${SHELL} -c \"make menuconfig; if [ $? -ne 0 ]; then echo 
'Command failed.'; printf 'Press any key to continue... '; read r; fi\"", 
'${PN} Configuration', d)
+oe_terminal("${SHELL} -c \"make menuconfig; if [ $? -ne 0 ]; then echo 
'Command failed.'; printf 'Press any key to continue... '; read r; fi\"", 
'${PN} Configuration', d)
 
-# FIXME this check can be removed when the minimum bitbake version has 
been bumped
-if hasattr(bb.build, 'write_taint'):
-try:
-newmtime = os.path.getmtime(".config")
-except OSError:
-newmtime = 0
+# FIXME this check can be removed when the minimum bitbake version has 
been bumped
+if hasattr(bb.build, 'write_taint'):
+try:
+newmtime = os.path.getmtime(".config")
+except OSError:
+newmtime = 0
 
-if newmtime > mtime:
-bb.note("Configuration changed, recompile will be forced")
-bb.build.write_taint('do_compile', d)
+if newmtime > mtime:
+bb.note("Configuration changed, recompile will be forced")
+bb.build.write_taint('do_compile', d)
 }
 do_menuconfig[depends] += "ncurses-native:do_populate_sysroot"
 do_menuconfig[nostamp] = "1"
-- 
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] jpeg-native: Do not use libtool-cross for native recipe

2012-09-27 Thread Khem Raj

On Wed, Sep 26, 2012 at 6:59 AM, Richard Purdie
 wrote:
> On Tue, 2012-09-25 at 06:27 -0700, Khem Raj wrote:
>> On Tue, Sep 25, 2012 at 1:14 AM, Richard Purdie
>>  wrote:
>> > This wallpapers over cracks. Why is libtool-native/libtool-cross broken?
>> > Shouldn't we fix whatever is breaking libtool?
>> >
>>
>> it is not broken. But we were ending up using cross-libtool for native
>> recipe that does not seem right.
>
> Looking at your original error message, it says:
>
>  /work/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/bin/x86_64-linux-libtool
>
> which is libtool-native. I appreciate that the OEMAKE line to use the
> cross version is wrong but it looks like it still manages to find the
> native libtool and that it isn't working.

hmmm I tried and it worked fine when libtool-cross was staged. I guess
my problem was
that it was trying to find native sed in native sysroot. I cant
reproduce it. But I guess
the patch still makes sense. I can send it with commit message changed
if you are ok with that

>
> Cheers,
>
> Richard
>
>

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

[OE-core] [PATCH 2/2] initramfs: Make mkdir not fail

2012-09-27 Thread Ross Burton

From: Damien Lespiau 

This patch make "mkdir foo" not fail if foo already exists.

Signed-off-by: Damien Lespiau 
Signed-off-by: Ross Burton 
---
 meta/recipes-core/initrdscripts/files/init-live.sh |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-core/initrdscripts/files/init-live.sh 
b/meta/recipes-core/initrdscripts/files/init-live.sh
index fb7af31..2639308 100644
--- a/meta/recipes-core/initrdscripts/files/init-live.sh
+++ b/meta/recipes-core/initrdscripts/files/init-live.sh
@@ -21,15 +21,15 @@ ISOLINUX=""
 UNIONFS="no"
 
 early_setup() {
-mkdir /proc
-mkdir /sys
+mkdir -p /proc
+mkdir -p /sys
 mount -t proc proc /proc
 mount -t sysfs sysfs /sys
 
 # support modular kernel
 modprobe isofs 2> /dev/null
 
-mkdir /run
+mkdir -p /run
 udevd --daemon
 udevadm trigger --action=add
 }
-- 
1.7.10


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

[OE-core] [PATCH 1/2] initrd: Spawn an emergency shell when something goes wrong

2012-09-27 Thread Ross Burton

From: Damien Lespiau 

set -e allows to exit if a command fails. We install a trap and execute
emergency_shell() when either the init script exits or when ctrl-c is
typed (say if we are stuck somewhere and we want to debug it).

Signed-off-by: Damien Lespiau 
Signed-off-by: Ross Burton 
---
 meta/recipes-core/initrdscripts/files/init-live.sh |   11 +++
 1 file changed, 11 insertions(+)

diff --git a/meta/recipes-core/initrdscripts/files/init-live.sh 
b/meta/recipes-core/initrdscripts/files/init-live.sh
index 3fba7dc..fb7af31 100644
--- a/meta/recipes-core/initrdscripts/files/init-live.sh
+++ b/meta/recipes-core/initrdscripts/files/init-live.sh
@@ -2,6 +2,17 @@
 
 PATH=/sbin:/bin:/usr/sbin:/usr/bin
 
+emergency_shell()
+{
+echo "Bug in initramfs /init detected. Dropping to a shell. Good luck!"
+echo
+sh
+}
+trap "emergency_shell" 0 2
+
+# exit immediately if a command fails
+set -e
+
 ROOT_MOUNT="/rootfs/"
 ROOT_IMAGE="rootfs.img"
 MOUNT="/bin/mount"
-- 
1.7.10


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

[OE-core] [PATCH 0/2] initramfs fixes

2012-09-27 Thread Ross Burton

A colleague was working on an initramfs-based yocto system and encounting some
issues because the initial script is quite fragile.

Attached are two patches to make it less fragile, and drop you to a shell if it
does break.

The following changes since commit 55b3e7bf48a67c0ce42308b8332262fbe4eccd24:

  dbus: disable all X11 when native (2012-09-26 21:23:37 +0100)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib ross/initramfs

for you to fetch changes up to 265e1e50186d5982b40d87f37f0662a0e09a7daa:

  initramfs: Make mkdir not fail (2012-09-27 15:17:35 +0100)


Damien Lespiau (2):
  initrd: Spawn an emergency shell when something goes wrong
  initramfs: Make mkdir not fail

 meta/recipes-core/initrdscripts/files/init-live.sh |   17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

Damien Lespiau (2):
  initrd: Spawn an emergency shell when something goes wrong
  initramfs: Make mkdir not fail

 meta/recipes-core/initrdscripts/files/init-live.sh |   17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

-- 
1.7.10


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

[OE-core] Fail in perl-native_5.14.2.bb

2012-09-27 Thread Steven Munk Østergaard


Hello, peace be with thee... :)

I found a mistake in the "do_configure()" function of: 
"perl-native_5.14.2.bb"


I am not experienced enough with mailing list to produce patches, but i 
will try...


Explanation:
sed is in " -e "s%/perl5%/perl%g" \ " replacing parts of @DESTDIR@ which 
makes its patch way to long and doubles up parts of it's folders...

This patch works for me...


Index: perl/perl_5.14.2.bb
===
--- perl.orig/perl_5.14.2.bb
+++ perl/perl_5.14.2.bb
@@ -146,14 +146,14 @@ do_configure() {
 ${@base_contains('DISTRO_FEATURES', 'largefile', '', 
'do_nolargefile', d)}


 # Update some paths in the configuration
-sed -i -e 's,@DESTDIR@,${prefix},g' \
-   -e 's,@ARCH@-thread-multi,,g' \
+sed -i -e 's,@ARCH@-thread-multi,,g' \
-e 's,@ARCH@,${TARGET_ARCH}-${TARGET_OS},g' \
-e 's,@STAGINGDIR@,${STAGING_DIR_HOST},g' \
-e "s%\([ \"^\',=]\+\)/usr/include%\1${STAGING_INCDIR}%g" \
-e "s%\([ \"^\',=]\+\)/usr/lib/%\1${libdir}/%g" \
-e "s%\([ \"^\',=]\+\)/usr/%\1${exec_prefix}/%g" \
-e "s%/perl5%/perl%g" \
+   -e 's,@DESTDIR@,${prefix},g' \
 config.sh-${TARGET_ARCH}-${TARGET_OS}

 case "${TARGET_ARCH}" in

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

Re: [OE-core] [oe-core][PATCH 00/10] qt4: upgrade to 4.8.3 and cleanup

2012-09-27 Thread Paul Eggleton

On Thursday 27 September 2012 00:27:05 Martin Jansa wrote:
> Please test on more architectures.
> I've tested complete qt4-native + qt4-free-x11 on armv4t.
> And only do_patch for nativesdk-qt4-tools, qt-mobility-*, qt4-embedded.

So this is great work and these patches look good, although I'm still not 
particularly happy with breaking out so many of the configure options because 
I'm convinced it won't stop here; but it's possible I might be overruled on 
this issue. 

The bigger problem is when these patches are arriving - we're late into the 
stabilisation period and given the choice I'd prefer not to merge them until 
the next development cycle.

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] jpeg-native: Do not use libtool-cross for native recipe

2012-09-27 Thread Richard Purdie

On Thu, 2012-09-27 at 07:14 -0700, Khem Raj wrote:
> On Wed, Sep 26, 2012 at 6:59 AM, Richard Purdie
>  wrote:
> > On Tue, 2012-09-25 at 06:27 -0700, Khem Raj wrote:
> >> On Tue, Sep 25, 2012 at 1:14 AM, Richard Purdie
> >>  wrote:
> >> > This wallpapers over cracks. Why is libtool-native/libtool-cross broken?
> >> > Shouldn't we fix whatever is breaking libtool?
> >> >
> >>
> >> it is not broken. But we were ending up using cross-libtool for native
> >> recipe that does not seem right.
> >
> > Looking at your original error message, it says:
> >
> >  
> > /work/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/bin/x86_64-linux-libtool
> >
> > which is libtool-native. I appreciate that the OEMAKE line to use the
> > cross version is wrong but it looks like it still manages to find the
> > native libtool and that it isn't working.
> 
> hmmm I tried and it worked fine when libtool-cross was staged. I guess
> my problem was
> that it was trying to find native sed in native sysroot. I cant
> reproduce it. But I guess
> the patch still makes sense. I can send it with commit message changed
> if you are ok with that

I'm not really. I'd like to understand what the problem is we're fixing
before I take patches. We don't understand what is wrong here.

Cheers,

Richard


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

Re: [OE-core] overuse of bitbake flags considered harmful

2012-09-27 Thread Richard Purdie

On Thu, 2012-09-27 at 13:22 +0100, Phil Blundell wrote:
> I was mildly amused to discover, the other day, that the output of
> "bitbake -e rpm | grep PACKAGECONFIG" is not quite as one might naïvely
> expect.  
> 
> I guess the right response to this is perhaps that bitbake ought
> nowadays to find some other way to store its own internal state, since
> the idiom of using flags is pretty well established in oe-core.

For those who don't realise what's going on here, the output is:

python PACKAGECONFIG () {
db bzip2 zlib beecrypt openssl libelf python}

since "python" is a flag bitbake uses to identify python functions too.

I suspect the better solution would be to use "_python" internally since
we already have a convention within bitbake of prefixing internally used
flags with "_".

http://git.yoctoproject.org/cgit.cgi/poky/commit/bitbake/lib/bb/data_smart.py?id=49bc007c80e429090c4db51e30c5ce27e8a72558
http://git.yoctoproject.org/cgit.cgi/poky/commit/bitbake/lib/bb/data_smart.py?id=980d658f3f1e6c5b459f741385533a11d35009ca

This would mean the metadata shouldn't use that namespace but I think we
can live with that.

Cheers,

Richard




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

Re: [OE-core] [PATCH] perl: Fix nativesdk install path

2012-09-27 Thread Saul Wold


On 09/27/2012 05:20 AM, Christian Glindkamp wrote:

Commit 38234f2e276356b1d77a87ceabc486107e336d19 tried to fix the sed
expressions by anchoring the left side of the search regexp to prevent
$prefix$prefix type expression in the perl config. For nativesdk this is
not enough. Adding anchors on both side fixes this.

Signed-off-by: Christian Glindkamp 
---

This is currently only build tested, but buildhistory for perl did not change.

  meta/recipes-devtools/perl/perl_5.14.2.bb |8 
  1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-devtools/perl/perl_5.14.2.bb 
b/meta/recipes-devtools/perl/perl_5.14.2.bb
index 3c1360f..0009855 100644
--- a/meta/recipes-devtools/perl/perl_5.14.2.bb
+++ b/meta/recipes-devtools/perl/perl_5.14.2.bb
@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM = 
"file://Copying;md5=2b4c6ffbcfcbdee469f02565f253d81a \
  # We need gnugrep (for -I)
  DEPENDS = "virtual/db grep-native"
  DEPENDS += "gdbm zlib"
-PR = "r9"
+PR = "r10"

  # 5.10.1 has Module::Build built-in
  PROVIDES += "libmodule-build-perl"
@@ -150,9 +150,9 @@ do_configure() {
 -e 's,@ARCH@-thread-multi,,g' \
 -e 's,@ARCH@,${TARGET_ARCH}-${TARGET_OS},g' \
 -e 's,@STAGINGDIR@,${STAGING_DIR_HOST},g' \
-   -e "s%\([ \"^\',=]\+\)/usr/include%\1${STAGING_INCDIR}%g" \
-  -e "s%\([ \"^\',=]\+\)/usr/lib/%\1${libdir}/%g" \
-  -e "s%\([ \"^\',=]\+\)/usr/%\1${exec_prefix}/%g" \
+   -e "s%\([ \"^\',=]\+\)/usr/include\([ 
\"^\',=]\+\)%\1${STAGING_INCDIR}\2%g" \
+  -e "s%\([ \"^\',=]\+\)/usr/lib/\([ 
\"^\',=]\+\)%\1${libdir}/\2%g" \
+  -e "s%\([ \"^\',=]\+\)/usr/\([ 
\"^\',=]\+\)%\1${exec_prefix}/\2%g" \
   -e "s%/perl5%/perl%g" \
  config.sh-${TARGET_ARCH}-${TARGET_OS}




Merged into OE-Core

Thanks  
Sau!


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

Re: [OE-core] [PATCH] dbus: disable all X11 when native

2012-09-27 Thread Saul Wold


On 09/26/2012 01:25 PM, Ross Burton wrote:

Without --without-x the X11 detection would still go ahead and find the host X11
headers, which seems to cause problems at link time.

Signed-off-by: Ross Burton 
---
  meta/recipes-core/dbus/dbus.inc |4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-core/dbus/dbus.inc b/meta/recipes-core/dbus/dbus.inc
index 5c99e11..550eb0a 100644
--- a/meta/recipes-core/dbus/dbus.inc
+++ b/meta/recipes-core/dbus/dbus.inc
@@ -10,7 +10,7 @@ DEPENDS = "expat virtual/libintl 
${@base_contains('DISTRO_FEATURES', 'x11', '${X
  DEPENDS_virtclass-native = "expat-native virtual/libintl-native"
  DEPENDS_virtclass-nativesdk = "nativesdk-expat virtual/nativesdk-libintl 
virtual/libx11"

-INC_PR = "r4"
+INC_PR = "r5"

  SRC_URI = "http://dbus.freedesktop.org/releases/dbus/dbus-${PV}.tar.gz \
 file://tmpdir.patch; \
@@ -64,7 +64,7 @@ pkg_postinst_dbus() {
  }

  EXTRA_OECONF_X = "${@base_contains('DISTRO_FEATURES', 'x11', '--with-x', 
'--without-x', d)}"
-EXTRA_OECONF_X_virtclass-native = "--disable-x11-autolaunch"
+EXTRA_OECONF_X_virtclass-native = "--without-x --disable-x11-autolaunch"

  EXTRA_OECONF = "--disable-tests \
  --disable-checks \



Merged into OE-Core

Thanks
Sau!


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

Re: [OE-core] [oe-commits] Martin Jansa : xserver-xorg: use EXTENDPKGV instead of PV in RCONFLICTS_${PN}-module-exa

2012-09-27 Thread Martin Jansa

On Thu, Sep 27, 2012 at 02:29:25PM +, g...@git.openembedded.org wrote:
> Module: openembedded-core.git
> Branch: master
> Commit: ed0216d29fc4355c5220f3ad51df04a63cacb0c3
> URL:
> http://git.openembedded.org/?p=openembedded-core.git&a=commit;h=ed0216d29fc4355c5220f3ad51df04a63cacb0c3
> 
> Author: Martin Jansa 
> Date:   Sat Sep 22 19:13:14 2012 +0200
> 
> xserver-xorg: use EXTENDPKGV instead of PV in RCONFLICTS_${PN}-module-exa
> 
> * it doesn't make much sense with PV, because xserver-xorg-module-exa
>   was introduced in
>   
> http://git.openembedded.org/openembedded-core/commit/meta/recipes-graphics/xorg-xserver?id=1a666ee1cda3c0b74daba5881fc5f62e13deec66
>   so our xserver-xorg-module-exa RCONFLICTS with xserver-xorg (<= 1.11.2-r4)
>   and (< 1.11.2) is not good enough
> 
> * because we don't know how many PRINC are in BSP/DISTRO layers,
>   then it's safer to RCONFLICTS with every older version then current
>   EXTENDPKGV
> 
> Also fixes whitespace to work correctly with opkg

The whitespace problem wasn't opkg fault AFAIK, but
bb.utils.explode_dep_versions as shown in 
http://patchwork.openembedded.org/patch/37069/

Cheers

> 
> Signed-off-by: Martin Jansa 
> 
> --
> 
> * I haven't really tested this with IPK, since it was changed from
>   RREPLACES to RCONFLICTS (because of RPM) and all my installed devices
>   are already upgraded
> Signed-off-by: Richard Purdie 
> 
> ---
> 
>  .../recipes-graphics/xorg-xserver/xserver-xorg.inc |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc 
> b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
> index 643ca70..7513399 100644
> --- a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
> +++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
> @@ -66,7 +66,7 @@ PACKAGES =+ "${PN}-security-policy \
>  
>  RRECOMMENDS_${PN} += "${PN}-security-policy xkeyboard-config rgb 
> xserver-xf86-config"
>  RDEPENDS_${PN}-xvfb += "xkeyboard-config"
> -RCONFLICTS_${PN}-module-exa = "${PN} (<${PV})"
> +RCONFLICTS_${PN}-module-exa = "${PN} (< ${EXTENDPKGV})"
>  
>  FILES_${PN} = "${bindir} ${libdir}/X11/Options ${libdir}/X11/Cards 
> ${libdir}/X11/getconfig ${libdir}/X11/etc ${libdir}/modules/*.so 
> ${libdir}/xorg/modules/*.so /etc/X11 ${libdir}/xorg/protocol.txt 
> ${datadir}/X11/xorg.conf.d"
>  FILES_${PN}-dev += "${libdir}/xorg/modules/*.la 
> ${libdir}/xorg/modules/*/*.la"
> 
> 
> ___
> Openembedded-commits mailing list
> openembedded-comm...@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-commits

-- 
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] [PATCH] eglibc: Remove bogus PACKAGES_DYNAMIC setting

2012-09-27 Thread Saul Wold


On 09/27/2012 04:44 AM, Phil Blundell wrote:

It transpires that eglibc has been setting PACKAGES_DYNAMIC = "libc6*" for
some time.  However, this is bogus for at least two reasons:

1. Bitbake interprets PACKAGES_DYNAMIC as a regex, not a glob, so this will
match against any package whose name starts "libc" plus zero or more sixes.
This is particularly toxic because the nativesdk variant picks up the same
value and will, consequently, start trying to build itself at the slightest
excuse.

2. eglibc doesn't actually build any packages named "libc6", other
than the ones that are named in PACKAGES anyway, so the dynamic provider
declaration is in any case useless.

Simply deleting the line is not sufficient since then we get the default
value from bitbake.conf which causes eglibc.bb to fight with eglibc-locale.bb.
So instead we must set it to the empty string for good results.

Signed-off-by: Phil Blundell 
---
  meta/recipes-core/eglibc/eglibc_2.16.bb |3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-core/eglibc/eglibc_2.16.bb 
b/meta/recipes-core/eglibc/eglibc_2.16.bb
index 3a7ae50..b37922d 100644
--- a/meta/recipes-core/eglibc/eglibc_2.16.bb
+++ b/meta/recipes-core/eglibc/eglibc_2.16.bb
@@ -43,7 +43,8 @@ SRC_URI_append_virtclass-nativesdk = " 
file://ld-search-order.patch \
  S = "${WORKDIR}/${EGLIBC_BRANCH}/libc"
  B = "${WORKDIR}/build-${TARGET_SYS}"

-PACKAGES_DYNAMIC = "libc6*"
+PACKAGES_DYNAMIC = ""
+
  RPROVIDES_${PN}-dev = "libc6-dev virtual-libc-dev"
  PROVIDES_${PN}-dbg = "glibc-dbg"



Merged into OE-Core

Thanks
Sau!


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

Re: [OE-core] [PATCH] cml1.bbclass: Convert tab indentation in python functions into four-space

2012-09-27 Thread Saul Wold


On 09/27/2012 06:52 AM, Jason Wessel wrote:

Based on the previous commit 604d46c686d06d62d5a07b9c7f4fa170f99307d8
(Convert tab indentation in python functions into four-space), the
cml.bbclass was not converted, and in order to properly extend it
with external bbappend's it needs to be converted.

Signed-off-by: Jason Wessel 
---
  meta/classes/cml1.bbclass |   28 ++--
  1 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/meta/classes/cml1.bbclass b/meta/classes/cml1.bbclass
index 37ed792..ba44196 100644
--- a/meta/classes/cml1.bbclass
+++ b/meta/classes/cml1.bbclass
@@ -15,23 +15,23 @@ HOSTLDFLAGS = "${BUILD_LDFLAGS}"
  HOST_LOADLIBES = "-lncurses"

  python do_menuconfig() {
-try:
-mtime = os.path.getmtime(".config")
-except OSError:
-mtime = 0
+try:
+mtime = os.path.getmtime(".config")
+except OSError:
+mtime = 0

-oe_terminal("${SHELL} -c \"make menuconfig; if [ $? -ne 0 ]; then echo 'Command 
failed.'; printf 'Press any key to continue... '; read r; fi\"", '${PN} Configuration', d)
+oe_terminal("${SHELL} -c \"make menuconfig; if [ $? -ne 0 ]; then echo 'Command 
failed.'; printf 'Press any key to continue... '; read r; fi\"", '${PN} Configuration', d)

-# FIXME this check can be removed when the minimum bitbake version has 
been bumped
-if hasattr(bb.build, 'write_taint'):
-try:
-newmtime = os.path.getmtime(".config")
-except OSError:
-newmtime = 0
+# FIXME this check can be removed when the minimum bitbake version has 
been bumped
+if hasattr(bb.build, 'write_taint'):
+try:
+newmtime = os.path.getmtime(".config")
+except OSError:
+newmtime = 0

-if newmtime > mtime:
-bb.note("Configuration changed, recompile will be forced")
-bb.build.write_taint('do_compile', d)
+if newmtime > mtime:
+bb.note("Configuration changed, recompile will be forced")
+bb.build.write_taint('do_compile', d)
  }
  do_menuconfig[depends] += "ncurses-native:do_populate_sysroot"
  do_menuconfig[nostamp] = "1"



Merged into OE-Core

Thanks
Sau!


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

Re: [OE-core] [PATCH] util-linux: Don't package chkdupexe

2012-09-27 Thread Saul Wold


On 09/25/2012 06:04 AM, Phil Blundell wrote:

The chkdupexe utility is fairly worthless and drags perl in as a build 
dependency
of the whole util-linux recipe.  If anybody actually wants to use this script
then we should package it separately, but for the time being let's just delete 
it.

Signed-off-by: Phil Blundell 
---
  meta/recipes-core/util-linux/util-linux.inc   |6 +++---
  meta/recipes-core/util-linux/util-linux_2.21.2.bb |6 +-
  2 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/meta/recipes-core/util-linux/util-linux.inc 
b/meta/recipes-core/util-linux/util-linux.inc
index b2a1552..d62d406 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -31,7 +31,7 @@ PACKAGES =+ "util-linux-agetty util-linux-fdisk 
util-linux-cfdisk util-linux-sfd
   util-linux-mount util-linux-readprofile util-linux-libblkid \
   util-linux-libblkid-dev util-linux-libuuid 
util-linux-libuuid-dev \
   util-linux-uuidgen util-linux-lscpu util-linux-fsck 
util-linux-blkid \
- util-linux-chkdupexe util-linux-mkfs util-linux-mcookie"
+ util-linux-mkfs util-linux-mcookie"

  EXTRA_OECONF = "--libdir=${base_libdir} --disable-use-tty-group \
  --disable-makeinstall-chown --enable-elvtune --enable-init \
@@ -63,7 +63,6 @@ FILES_util-linux-libuuid-dev = "${base_libdir}/libuuid.so 
${base_libdir}/libuuid
  FILES_util-linux-lscpu = "${bindir}/lscpu"

  FILES_util-linux-fsck = "${base_sbindir}/fsck*"
-FILES_util-linux-chkdupexe = "${bindir}/chkdupexe"
  FILES_util-linux-mkfs = "${sbindir}/mkfs"

  # Util-linux' blkid replaces the e2fsprogs one
@@ -72,7 +71,6 @@ RCONFLICTS_util-linux-blkid = "e2fsprogs-blkid"
  RREPLACES_util-linux-blkid = "e2fsprogs-blkid"

  RDEPENDS_${PN} = "util-linux-umount util-linux-swaponoff util-linux-losetup"
-RDEPENDS_${PN}-chkdupexe = "perl"
  RRECOMMENDS_${PN} = "util-linux-fdisk util-linux-cfdisk util-linux-sfdisk 
util-linux-mount util-linux-readprofile util-linux-mkfs "

  RRECOMMENDS_${PN}_virtclass-native = ""
@@ -125,6 +123,8 @@ do_install () {

ln -sf swapon.${BPN}   ${D}${base_sbindir}/swapoff.${BPN}
rm -f ${D}${sbindir}/swapoff
+
+   rm -f ${D}${bindir}/chkdupexe
  }

  inherit update-alternatives
diff --git a/meta/recipes-core/util-linux/util-linux_2.21.2.bb 
b/meta/recipes-core/util-linux/util-linux_2.21.2.bb
index 792730c..39e3609 100644
--- a/meta/recipes-core/util-linux/util-linux_2.21.2.bb
+++ b/meta/recipes-core/util-linux/util-linux_2.21.2.bb
@@ -1,5 +1,5 @@
  MAJOR_VERSION = "2.21"
-PR = "r4"
+PR = "r5"
  require util-linux.inc

  # note that `lscpu' is under GPLv3+
@@ -40,7 +40,3 @@ addtask remove_lscpu before do_configure after do_patch

  CACHED_CONFIGUREVARS += "scanf_cv_alloc_modifier=as"
  EXTRA_OECONF_virtclass-native += "--disable-fallocate --disable-use-tty-group"
-
-do_install_append () {
-   sed -i -e '1s,.*,#!${bindir}/env perl,' ${D}${bindir}/chkdupexe
-}



Merged into OE-Core

Thanks
Sau!


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

Re: [OE-core] [PATCH] util-linux: Remove static libraries from -dev packages

2012-09-27 Thread Saul Wold


On 09/25/2012 05:54 AM, Phil Blundell wrote:

Fixes the QA warnings:

WARNING: QA Issue: non -staticdev package contains static .a library: 
util-linux-libblkid-dev path 
'/work/mips32el-oe-linux/util-linux/2.21.2-r3micro3/packages-split/util-linux-libblkid-dev/lib/libblkid.a'
WARNING: QA Issue: non -staticdev package contains static .a library: 
util-linux-libuuid-dev path 
'/work/mips32el-oe-linux/util-linux/2.21.2-r3micro3/packages-split/util-linux-libuuid-dev/lib/libuuid.a'

Signed-off-by: Phil Blundell 
---
  meta/recipes-core/util-linux/util-linux.inc   |4 ++--
  meta/recipes-core/util-linux/util-linux_2.21.2.bb |2 +-
  2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-core/util-linux/util-linux.inc 
b/meta/recipes-core/util-linux/util-linux.inc
index 2c5267f..b2a1552 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -57,9 +57,9 @@ FILES_util-linux-readprofile = 
"${base_sbindir}/readprofile.${BPN}"
  FILES_util-linux-uuidgen = "${bindir}/uuidgen"

  FILES_util-linux-libblkid = "${base_libdir}/libblkid.so.*"
-FILES_util-linux-libblkid-dev = "${base_libdir}/libblkid.so 
${base_libdir}/libblkid.a ${base_libdir}/libblkid.la ${includedir}/blkid 
${libdir}/pkgconfig/blkid.pc"
+FILES_util-linux-libblkid-dev = "${base_libdir}/libblkid.so 
${base_libdir}/libblkid.la ${includedir}/blkid ${libdir}/pkgconfig/blkid.pc"
  FILES_util-linux-libuuid = "${base_libdir}/libuuid.so.*"
-FILES_util-linux-libuuid-dev = "${base_libdir}/libuuid.so ${base_libdir}/libuuid.a 
${base_libdir}/libuuid.la ${includedir}/uuid ${libdir}/pkgconfig/uuid.pc"
+FILES_util-linux-libuuid-dev = "${base_libdir}/libuuid.so ${base_libdir}/libuuid.la 
${includedir}/uuid ${libdir}/pkgconfig/uuid.pc"
  FILES_util-linux-lscpu = "${bindir}/lscpu"

  FILES_util-linux-fsck = "${base_sbindir}/fsck*"
diff --git a/meta/recipes-core/util-linux/util-linux_2.21.2.bb 
b/meta/recipes-core/util-linux/util-linux_2.21.2.bb
index e8f00fc..792730c 100644
--- a/meta/recipes-core/util-linux/util-linux_2.21.2.bb
+++ b/meta/recipes-core/util-linux/util-linux_2.21.2.bb
@@ -1,5 +1,5 @@
  MAJOR_VERSION = "2.21"
-PR = "r3"
+PR = "r4"
  require util-linux.inc

  # note that `lscpu' is under GPLv3+



Merged into OE-Core

Thanks
Sau!


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

Re: [OE-core] [PATCH 1/2] package_rpm.bbclass: change the arch's "-" to "_" for platform

2012-09-27 Thread Saul Wold


On 09/25/2012 06:38 AM, Robert Yang wrote:

The platform and platform_extra will be written to /etc/rpm/platform,
the rpm's arch has changed the "-" to "_", so the value in platform
should also be updated.

[YOCTO #3159]

Signed-off-by: Robert Yang 
---
  meta/classes/package_rpm.bbclass | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass
index 64689d8..be6bd45 100644
--- a/meta/classes/package_rpm.bbclass
+++ b/meta/classes/package_rpm.bbclass
@@ -276,8 +276,8 @@ process_pkg_list_rpm() {
  package_install_internal_rpm () {

local target_rootfs="${INSTALL_ROOTFS_RPM}"
-   local platform="${INSTALL_PLATFORM_RPM}"
-   local platform_extra="${INSTALL_PLATFORM_EXTRA_RPM}"
+   local platform="`echo ${INSTALL_PLATFORM_RPM} | sed 's#-#_#g'`"
+   local platform_extra="`echo ${INSTALL_PLATFORM_EXTRA_RPM} | sed 
's#-#_#g'`"
local confbase="${INSTALL_CONFBASE_RPM}"
local package_to_install="${INSTALL_PACKAGES_RPM}"
local package_attemptonly="${INSTALL_PACKAGES_ATTEMPTONLY_RPM}"



Merged into OE-Core

Thanks
Sau!


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

Re: [OE-core] [PATCH] jpeg-native: Do not use libtool-cross for native recipe

2012-09-27 Thread Khem Raj

On Thu, Sep 27, 2012 at 8:16 AM, Richard Purdie
 wrote:
> On Thu, 2012-09-27 at 07:14 -0700, Khem Raj wrote:
>> On Wed, Sep 26, 2012 at 6:59 AM, Richard Purdie
>>  wrote:
>> > On Tue, 2012-09-25 at 06:27 -0700, Khem Raj wrote:
>> >> On Tue, Sep 25, 2012 at 1:14 AM, Richard Purdie
>> >>  wrote:
>> >> > This wallpapers over cracks. Why is libtool-native/libtool-cross broken?
>> >> > Shouldn't we fix whatever is breaking libtool?
>> >> >
>> >>
>> >> it is not broken. But we were ending up using cross-libtool for native
>> >> recipe that does not seem right.
>> >
>> > Looking at your original error message, it says:
>> >
>> >  
>> > /work/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/bin/x86_64-linux-libtool
>> >
>> > which is libtool-native. I appreciate that the OEMAKE line to use the
>> > cross version is wrong but it looks like it still manages to find the
>> > native libtool and that it isn't working.
>>
>> hmmm I tried and it worked fine when libtool-cross was staged. I guess
>> my problem was
>> that it was trying to find native sed in native sysroot. I cant
>> reproduce it. But I guess
>> the patch still makes sense. I can send it with commit message changed
>> if you are ok with that
>
> I'm not really. I'd like to understand what the problem is we're fixing
> before I take patches. We don't understand what is wrong here.
>


yes it seems something else is going on since for native recipes
STAGING_BINDIR_CROSS=${STAGING_BINDIR_NATIVE}
which means it ends up sourcing the native libtool for jpeg-native

When I did bitbake jpeg-native from scratch it worked fine too.

It appeared on a build server so it could have some weird race condition show
up. I will keep an eye if it happens again then I would like to
understand and hopefully reproduce.

Let me withdraw this patch.

> Cheers,
>
> Richard
>

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

Re: [OE-core] [PATCH 0/2] package_rpm.bbclass: two fixes

2012-09-27 Thread Saul Wold


On 09/25/2012 06:38 AM, Robert Yang wrote:

* Two fixes
   - Change the arch's "-" to "_" in /etc/rpm/platform
   - Fix the incremental rpm image generation

// Robert

The following changes since commit 8b3aa00029e62df6d05710cf166fd5d09bdb29cf:

   documentation/poky-ref-manual/ref-variables.xml: Update B variable 
(2012-09-24 16:36:09 +0100)

are available in the git repository at:

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

Robert Yang (2):
   package_rpm.bbclass: change the arch's "-" to "_" for platform
   package_rpm.bbclass: no initial_solution in the second build

  meta/classes/package_rpm.bbclass | 15 +--
  1 file changed, 9 insertions(+), 6 deletions(-)


Merged both into OE-Core

Thanks
Sau!


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

Re: [OE-core] [oe-core][PATCH 00/10] qt4: upgrade to 4.8.3 and cleanup

2012-09-27 Thread Martin Jansa

On Thu, Sep 27, 2012 at 04:10:20PM +0100, Paul Eggleton wrote:
> On Thursday 27 September 2012 00:27:05 Martin Jansa wrote:
> > Please test on more architectures.
> > I've tested complete qt4-native + qt4-free-x11 on armv4t.
> > And only do_patch for nativesdk-qt4-tools, qt-mobility-*, qt4-embedded.
> 
> So this is great work and these patches look good, although I'm still not 
> particularly happy with breaking out so many of the configure options because 
> I'm convinced it won't stop here; but it's possible I might be overruled on 
> this issue. 

I've added that, because meta-webos layer disables more stuff then .inc
file forces enabled, so I would have to rewrite whole QT_CONFIG_FLAGS
(if I don't want to have e.g. -webkit from .inc and -no-webkit appended
after that through QT_DISTRO_FLAGS).

But it can be just 2 variables instead of 6 if it's issue.

> The bigger problem is when these patches are arriving - we're late into the 
> stabilisation period and given the choice I'd prefer not to merge them until 
> the next development cycle.

The cleanup part is formal only, so with low risk IMHO.

I have some layer with .bbappends to it which needs 4.8.3 (or 4.8.2) so recipe 
even with negative D_P would help me to be able to use next oe-core release.

Cheers,

-- 
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] [PATCH] layer.conf: allow other layers to depend on this version

2012-09-27 Thread Saul Wold


On 09/25/2012 07:58 AM, Paul Eggleton wrote:

Set LAYERVERSION and rename the collection to "core". Given changes such
as the tabs to spaces cleanup for python functions in the current
version, this allows other layers to depend on this version of OE-Core
specifically should they choose to do so, by specifying the following
in their own layer.conf:

LAYERDEPENDS_layername = "core:1"

Where layername is whatever value is being added to BBFILE_COLLECTIONS.

(This change does nothing unless a layer has LAYERDEPENDS set.)

Signed-off-by: Paul Eggleton 
---
  meta/conf/layer.conf |   10 +++---
  1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf
index ed50f1c..78ceae9 100644
--- a/meta/conf/layer.conf
+++ b/meta/conf/layer.conf
@@ -3,9 +3,13 @@ BBPATH .= ":${LAYERDIR}"
  # We have a packages directory, add to BBFILES
  BBFILES += "${LAYERDIR}/recipes-*/*/*.bb"

-BBFILE_COLLECTIONS += "normal"
-BBFILE_PATTERN_normal := "^${LAYERDIR}/"
-BBFILE_PRIORITY_normal = "5"
+BBFILE_COLLECTIONS += "core"
+BBFILE_PATTERN_core := "^${LAYERDIR}/"
+BBFILE_PRIORITY_core = "5"
+
+# This should only be incremented on significant changes that will
+# cause compatibility issues with other layers
+LAYERVERSION_core = "1"

  # Set a variable to get to the top of the metadata location
  COREBASE := '${@os.path.normpath("${LAYERDIR}/../")}'



Merged into OE-Core

Thanks
Sau!


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

Re: [OE-core] [PATCH] iproute2: Use configured values for ${base_sbindir} and ${libdir}

2012-09-27 Thread Saul Wold


On 09/25/2012 09:38 AM, Phil Blundell wrote:

These were previously being hard-coded to "/sbin" and "/usr/lib" respectively,
resulting in unpackaged files if the configured values were something else.

Signed-off-by: Phil Blundell 
---
  meta/recipes-connectivity/iproute2/iproute2.inc  |2 +-
  meta/recipes-connectivity/iproute2/iproute2_3.5.1.bb |2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-connectivity/iproute2/iproute2.inc 
b/meta/recipes-connectivity/iproute2/iproute2.inc
index 7caf7d0..d8b1a17 100644
--- a/meta/recipes-connectivity/iproute2/iproute2.inc
+++ b/meta/recipes-connectivity/iproute2/iproute2.inc
@@ -13,7 +13,7 @@ DEPENDS = "flex-native bison-native"

  inherit update-alternatives

-EXTRA_OEMAKE = "CC='${CC}' KERNEL_INCLUDE=${STAGING_KERNEL_DIR}/include 
DOCDIR=${docdir}/iproute2 SUBDIRS='lib tc ip' SBINDIR=/sbin"
+EXTRA_OEMAKE = "CC='${CC}' KERNEL_INCLUDE=${STAGING_KERNEL_DIR}/include 
DOCDIR=${docdir}/iproute2 SUBDIRS='lib tc ip' SBINDIR='${base_sbindir}' 
LIBDIR='${libdir}'"

  do_install () {
  oe_runmake DESTDIR=${D} install
diff --git a/meta/recipes-connectivity/iproute2/iproute2_3.5.1.bb 
b/meta/recipes-connectivity/iproute2/iproute2_3.5.1.bb
index fc7292e..c1e9bd3 100644
--- a/meta/recipes-connectivity/iproute2/iproute2_3.5.1.bb
+++ b/meta/recipes-connectivity/iproute2/iproute2_3.5.1.bb
@@ -1,6 +1,6 @@
  require iproute2.inc

-PR = "r0"
+PR = "r1"

  SRC_URI = "${KERNELORG_MIRROR}/linux/utils/net/${BPN}/${BPN}-${PV}.tar.xz \
 file://configure-cross.patch"



Merged into OE-Core

Thanks
Sau!


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

Re: [OE-core] [PATCH] SDK: trap any IO errors in the relocate script

2012-09-27 Thread Saul Wold


On 09/25/2012 09:35 AM, Laurentiu Palcu wrote:

BTW: in the future it's good to say the "filename: "

So this would be "relocate_sdk.py: "

If the files being relocated are already used by other processes the
relocate script will fail with a traceback. This patch will trap any IO
errors when opening such a file and gracefully report them to the user.

Also change the exit code from 1 to -1 for a better adt-installer user
experience (like pointing the user to the adt_installer.log).

[YOCTO #3164]

Signed-off-by: Laurentiu Palcu 
---
  scripts/relocate_sdk.py |   14 --
  1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/scripts/relocate_sdk.py b/scripts/relocate_sdk.py
index b247e65..637ffe9 100755
--- a/scripts/relocate_sdk.py
+++ b/scripts/relocate_sdk.py
@@ -29,6 +29,7 @@ import sys
  import stat
  import os
  import re
+import errno

  old_prefix = re.compile("##DEFAULT_INSTALL_DIR##")

@@ -171,7 +172,7 @@ def change_dl_sysdirs():

  # MAIN
  if len(sys.argv) < 4:
-exit(1)
+exit(-1)

  new_prefix = sys.argv[1]
  new_dl_path = sys.argv[2]
@@ -184,7 +185,16 @@ for e in executables_list:
  else:
  os.chmod(e, perms|stat.S_IRWXU)

-f = open(e, "r+b")
+try:
+f = open(e, "r+b")
+except IOError as ioex:
+if ioex.errno == errno.ETXTBSY:
+print("Could not open %s. File used by another process.\nPlease "\
+  "make sure you exit all processes that might use any SDK "\
+  "binaries." % e)
+else:
+print("Could not open %s: %s(%d)" % (e, ioex.strerror, ioex.errno))
+exit(-1)

  arch = get_arch()
  if arch:


Merged into OE-Core

Thanks
Sau!


___
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] Correcting LICENSE for ossp-uuid

2012-09-27 Thread Saul Wold


On 09/25/2012 03:31 PM, Elizabeth Flanagan wrote:

LICENSE information for ossp-uuid was tossing a warning. this fixes license
as well as provides a more detailed LIC_FILES_CHKSUM.

The following changes since commit a8edf79fce381d0433f18bd38df6cd74008e5179:

   bitbake: fetch2/git: Don't use deprecated API (2012-09-25 15:55:57 +0100)

are available in the git repository at:
   git://git.yoctoproject.org/poky-contrib eflanagan/ossp-uuid-native
   
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=eflanagan/ossp-uuid-native

Elizabeth Flanagan (1):
   ossp-uuid: LICENSE type corrections.

  meta/recipes-devtools/ossp-uuid/ossp-uuid_1.6.2.bb |7 ---
  1 files changed, 4 insertions(+), 3 deletions(-)



Merged into OE-Core

Thanks
Sau!


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

Re: [OE-core] [PATCH] at: atd remove useless --make-pidfile option.

2012-09-27 Thread Saul Wold


On 09/26/2012 12:09 AM, Xin Ouyang wrote:

For start-stop-daemon, --make-pidfile is used when starting a
program that does not create its own pid file.
atd would create its own /var/run/atd.pid, so remove this option.

Signed-off-by: Xin Ouyang 
---
  meta/recipes-extended/at/at_3.1.13.bb |2 +-
  meta/recipes-extended/at/files/S99at  |2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-extended/at/at_3.1.13.bb 
b/meta/recipes-extended/at/at_3.1.13.bb
index a391d6e..3580e09 100644
--- a/meta/recipes-extended/at/at_3.1.13.bb
+++ b/meta/recipes-extended/at/at_3.1.13.bb
@@ -11,7 +11,7 @@ PAM_DEPS = "libpam libpam-runtime pam-plugin-env 
pam-plugin-limits"

  RCONFLICTS_${PN} = "atd"
  RREPLACES_${PN} = "atd"
-PR = "r3"
+PR = "r4"

  SRC_URI = "${DEBIAN_MIRROR}/main/a/at/at_${PV}.orig.tar.gz \
  file://configure.patch \
diff --git a/meta/recipes-extended/at/files/S99at 
b/meta/recipes-extended/at/files/S99at
index bcfcbda..386f8a4 100644
--- a/meta/recipes-extended/at/files/S99at
+++ b/meta/recipes-extended/at/files/S99at
@@ -7,7 +7,7 @@ umask 077

  start() {
echo -n "Starting atd: "
-   start-stop-daemon --start --quiet --make-pidfile --pidfile 
/var/run/atd.pid --background --exec /usr/sbin/atd -- -f
+   start-stop-daemon --start --quiet --pidfile /var/run/atd.pid 
--background --exec /usr/sbin/atd -- -f
echo "OK"
  }
  stop() {



Merged into OE-Core

Thanks
Sau!


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

Re: [OE-core] [oe-core] ysvinit-inittab: fix hang issue of series consoles check

2012-09-27 Thread Saul Wold


On 09/26/2012 12:18 AM, b19...@freescale.com wrote:

From: Zhenhua Luo 

 the kernel boot process hangs when /proc/consoles doesn't exists, check
 the existence of /proc/consoles before executing pkg_postinst script.

 Following is the log when /proc/consoles doesn't exist:
 Running postinst /etc/rpm-postinsts/102...
 cat: /proc/consoles: No such file or directory
 cat: /proc/consoles: No such file or directory
 cat: /proc/consoles: No such file or directory
 INIT: Entering runlevel: 5
 Starting OpenBSD Secure Shell server: sshd
   generating ssh RSA key...
   generating ssh ECDSA key...
   generating ssh DSA key...
 done.
 Starting network benchmark server: netserver.
 Starting system log daemon...0
 Starting kernel log daemon...0
 Stopping Bootlog daemon: bootlogd.
 INIT: no more processes left in this runlevel

Signed-off-by: Zhenhua Luo 
---
  .../sysvinit/sysvinit-inittab_2.88dsf.bb   |4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb 
b/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
index 5b79caf..b289853 100644
--- a/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
+++ b/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
@@ -2,7 +2,7 @@ DESCRIPTION = "Inittab for sysvinit"
  LICENSE = "GPLv2"
  LIC_FILES_CHKSUM = 
"file://${COREBASE}/meta/files/common-licenses/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6"

-PR = "r8"
+PR = "r9"

  SRC_URI = "file://inittab"

@@ -54,7 +54,7 @@ EOF

  pkg_postinst_${PN} () {
  # run this on the target
-if [ "x$D" = "x" ]; then
+if [ "x$D" = "x" ] && [ -e /proc/consoles ]; then
tmp="${SERIAL_CONSOLES_CHECK}"
for i in $tmp
do



Merged into OE-Core

Thanks
Sau!


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

Re: [OE-core] [PATCH] package_ipk: Remove spurious '-i' in grep command for log_check

2012-09-27 Thread Saul Wold


On 09/26/2012 04:55 AM, Phil Blundell wrote:

ipk_log_check uses a case-sensitive grep (which is correct) when deciding
whether there were any errors or not.  But if it decides that there were, it
then uses a case-insensitive grep to display them.  This results in a large
amount of irrelevant and confusing output which makes it hard to see the real
errors amongst the noise.

Suppress this by removing the unwanted -i.

Signed-off-by: Phil Blundell 
---
  meta/classes/package_ipk.bbclass |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/package_ipk.bbclass b/meta/classes/package_ipk.bbclass
index efe299e..59cb856 100644
--- a/meta/classes/package_ipk.bbclass
+++ b/meta/classes/package_ipk.bbclass
@@ -182,7 +182,7 @@ ipk_log_check() {
then
echo "log_check: There were error messages in the 
logfile"
printf "log_check: Matched keyword: [$keyword_die]\n\n"
-   echo "$lf_txt" | grep -v log_check | grep -C 5 -i 
"$keyword_die"
+   echo "$lf_txt" | grep -v log_check | grep -C 5 
"$keyword_die"
echo ""
do_exit=1
fi



Merged into OE-Core

Thanks
Sau!


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

Re: [OE-core] [PATCH] kexec-tools: admit mips as a COMPATIBLE_HOST

2012-09-27 Thread Saul Wold


On 09/24/2012 04:49 AM, Phil Blundell wrote:

Signed-off-by: Phil Blundell 
---
  meta/recipes-kernel/kexec/kexec-tools.inc |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/kexec/kexec-tools.inc 
b/meta/recipes-kernel/kexec/kexec-tools.inc
index 278ce34..ee1f1e8 100644
--- a/meta/recipes-kernel/kexec/kexec-tools.inc
+++ b/meta/recipes-kernel/kexec/kexec-tools.inc
@@ -12,6 +12,6 @@ SRC_URI = 
"${KERNELORG_MIRROR}/linux/utils/kernel/kexec/kexec-tools-${PV}.tar.gz

  inherit autotools

-COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*|powerpc.*)-(linux|freebsd.*)'
+COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*|powerpc.*|mips.*)-(linux|freebsd.*)'

  INSANE_SKIP_${PN} = "arch"


Merged into OE-Core

Sau!

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

Re: [OE-core] [PATCH] qemu-native: fix build on hosts without libX11 installed

2012-09-27 Thread Saul Wold


On 09/22/2012 03:30 AM, Martin Jansa wrote:

Signed-off-by: Martin Jansa 
---
  meta/recipes-devtools/qemu/qemu_1.2.0.bb | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/qemu/qemu_1.2.0.bb 
b/meta/recipes-devtools/qemu/qemu_1.2.0.bb
index 7091f6d..191ee48 100644
--- a/meta/recipes-devtools/qemu/qemu_1.2.0.bb
+++ b/meta/recipes-devtools/qemu/qemu_1.2.0.bb
@@ -17,7 +17,7 @@ SRC_URI = "\
  SRC_URI[md5sum] = "78eb1e984f4532aa9f2bdd3c127b5b61"
  SRC_URI[sha256sum] = 
"c8b84420d9f4869397f84cad2dabd9a475b7723d619a924a873740353e9df936"

-PR = "r1"
+PR = "r2"

  SRC_URI_append_virtclass-nativesdk = "\
  file://relocatable_sdk.patch \
@@ -29,4 +29,8 @@ do_configure_prepend_virtclass-nativesdk() {
sed -i 's/-lX11//g' Makefile.target
fi
  }
+do_configure_prepend_virtclass-native() {
+   # Undo the -lX11 added by linker-flags.patch, don't assume that host 
has libX11 installed
+   sed -i 's/-lX11//g' Makefile.target
+}




Merged into OE-Core

Thanks
Sau!


___
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] autotools.bbclass: using relative paths for acpaths

2012-09-27 Thread Saul Wold


On 09/27/2012 01:23 AM, wenzong@windriver.com wrote:

From: Wenzong Fan 

Fix autotools.bbclass to use relative paths for acpaths instead of
absolute ones. Since absolute paths may cause potential autoreconf
error like:

 Can't exec "/bin/sh": Argument list too long ...

This error occurs while building coreutils with long TMPDIR, because
it has bunch of m4 files need to be expanded.

[YOCTO #2766]

The following changes since commit 0b09e50810162a07ef0aecee91ee32b4a36334a3:

   busybox: Fix misplaced quote (2012-09-26 18:28:36 +0100)

are available in the git repository at:

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

Wenzong Fan (1):
   autotools.bbclass: using relative paths for acpaths

  meta/classes/autotools.bbclass |3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)



Merged into OE-Core

Thanks
Sau!


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

Re: [OE-core] [PATCH] gnome-keyring: include unpackaged files with PAM enabled

2012-09-27 Thread Saul Wold


On 09/27/2012 01:17 AM, Constantin Musca wrote:

Include missing files/dirs:
 ${base_libdir}/security/*.la
 ${base_libdir}/security/*${SOLIBSDEV}
 ${base_libdir}/security/.debug/

[YOCTO #2805]

Signed-off-by: Constantin Musca 
---
  meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb |9 ++---
  1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb 
b/meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb
index d822721..92e0e1b 100644
--- a/meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb
+++ b/meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb
@@ -11,7 +11,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \

  SECTION = "x11/gnome"

-PR = "r9"
+PR = "r10"

  inherit autotools gnome gtk-doc pkgconfig

@@ -43,7 +43,10 @@ FILES_${PN} += "${datadir}/dbus-1/services ${datadir}/gcr"

  FILES_${PN}-dev += "${libdir}/${BPN}/devel/*.la \
  ${libdir}/${BPN}/devel/*${SOLIBSDEV} \
-${libdir}/${BPN}/standalone/*.la"
+${libdir}/${BPN}/standalone/*.la \
+${base_libdir}/security/*.la \
+${base_libdir}/security/*${SOLIBSDEV}"

  FILES_${PN}-dbg += "${libdir}/${BPN}/standalone/.debug/ \
-${libdir}/${BPN}/devel/.debug/"
+${libdir}/${BPN}/devel/.debug/ \
+${base_libdir}/security/.debug/"



Merged into OE-Core

Thanks
Sau!


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

Re: [OE-core] [PATCH] sstate-cache-management: hide error message when one of possible layer location doesn't exist

2012-09-27 Thread Saul Wold


On 09/27/2012 12:36 AM, Martin Jansa wrote:

* fixes [YOCTO #3116]

Signed-off-by: Martin Jansa 
---
  scripts/sstate-cache-management.sh | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/sstate-cache-management.sh 
b/scripts/sstate-cache-management.sh
index f519555..4c06fe8 100755
--- a/scripts/sstate-cache-management.sh
+++ b/scripts/sstate-cache-management.sh
@@ -174,7 +174,7 @@ remove_duplicated () {
topdir=$(dirname $oe_core_dir)
tunedirs="`find $topdir/meta* ${oe_core_dir}/meta* $layers -path 
'*/meta*/conf/machine/include'`"
[ -n "$tunedirs" ] || echo_error "Can't find the tune directory"
-  all_machines="`find $topdir/meta* ${oe_core_dir}/meta* $layers -path 
'*/meta*/conf/machine/*' -name '*.conf' | sed -e 's/.*\///' -e 's/.conf$//'`"
+  all_machines="`find $topdir/meta* ${oe_core_dir}/meta* $layers -path 
'*/meta*/conf/machine/*' -name '*.conf' 2>/dev/null | sed -e 's/.*\///' -e 
's/.conf$//'`"
all_archs=`grep -r -h "^AVAILTUNES .*=" $tunedirs | sed -e 's/.*=//' -e 
's/\"//g'`
# Add the qemu and native archs
# Use the "_" to substitute "-", e.g., x86-64 to x86_64



Merged into OE-Core

Thanks
Sau!


___
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] license.bbclass: Variable standardization

2012-09-27 Thread Saul Wold


On 09/26/2012 02:50 PM, Elizabeth Flanagan wrote:

The variable mentioned in license.conf is LICENSE_PATH. The variable
used in license.bbclass is LICENSE_DIR. Conforming to what is in
license.conf

Signed-off-by: Elizabeth Flanagan 
---
  meta/classes/license.bbclass |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/meta/classes/license.bbclass b/meta/classes/license.bbclass
index ffcaf93..ad543f6 100644
--- a/meta/classes/license.bbclass
+++ b/meta/classes/license.bbclass
@@ -186,7 +186,7 @@ python do_populate_lic() {
  license_source_dirs = []
  license_source_dirs.append(generic_directory)
  try:
-additional_lic_dirs = d.getVar('LICENSE_DIR', True).split()
+additional_lic_dirs = d.getVar('LICENSE_PATH', True).split()


Beth, I found that we also have LICENSE_DIRECTORY, so the intent here is 
to be a multiple directory (such as a search PATH) for licenses?


There is also some documentation that needs to be changed, should not 
prevent this patch from being pulled.




Sau!


  for lic_dir in additional_lic_dirs:
  license_source_dirs.append(lic_dir)
  except:



___
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] autotools.bbclass: using relative paths for acpaths

2012-09-27 Thread Richard Purdie

On Thu, 2012-09-27 at 16:23 +0800, wenzong@windriver.com wrote:
> From: Wenzong Fan 
> 
> Fix autotools.bbclass to use relative paths for acpaths instead of
> absolute ones. Since absolute paths may cause potential autoreconf
> error like:
> 
> Can't exec "/bin/sh": Argument list too long ...
> 
> This error occurs while building coreutils with long TMPDIR, because
> it has bunch of m4 files need to be expanded.
> 
> [YOCTO #2766]
> 
> Signed-off-by: Wenzong Fan 
> ---
>  meta/classes/autotools.bbclass |3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/classes/autotools.bbclass b/meta/classes/autotools.bbclass
> index e4e034b..874e01d 100644
> --- a/meta/classes/autotools.bbclass
> +++ b/meta/classes/autotools.bbclass
> @@ -130,7 +130,8 @@ autotools_do_configure() {
>   if [ x"${acpaths}" = xdefault ]; then
>   acpaths=
>   for i in `find ${S} -maxdepth 2 -name \*.m4|grep -v 
> 'aclocal.m4'| \
> - grep -v 'acinclude.m4' | sed -e 
> 's,\(.*/\).*$,\1,'|sort -u`; do
> + grep -v 'acinclude.m4' | sed -e 
> 's,\(.*/\).*$,\1,'|sort -u| \
> + sed -e 's,${S},\.,'`; do
>   acpaths="$acpaths -I $i"
>   done
>   else

We applied this but it nearly instantly caused build failure reports.
Anything with multiple configure.ac files where sub configures are used
such as bdwgc-native will fail after this.

I've therefore reverted it and we need to find another way.

Cheers,

Richard


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

Re: [OE-core] [PATCH 0/3] license.bbclass fixes

2012-09-27 Thread Saul Wold


On 09/26/2012 02:50 PM, Elizabeth Flanagan wrote:

[YOCTO #3118]

license.conf hasn't been being parsed. This commit series ensures that
license.conf is parsed, that it contains useful variables that should be
in a global conf file and that those variables are not kept within
license.bbclass.


So where is the inherit license bbclass?

Sau!


This also fixes an discreprancy between the documentation of LICENSE_PATH (which
is what we tell people to use) and what we were using "LICENSE_DIR". This 
ensures
that when the end user needs to add additional licenses, that they use
LICENSE_PATH += "path/to/additional/licenses" and that it works.




The following changes since commit 0b09e50810162a07ef0aecee91ee32b4a36334a3:

   busybox: Fix misplaced quote (2012-09-26 18:28:36 +0100)

are available in the git repository at:
   git://git.yoctoproject.org/poky-contrib eflanagan/LICENSE_PATH
   
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=eflanagan/LICENSE_PATH

Elizabeth Flanagan (3):
   license.bbclass: Variable standardization
   bitbake.conf: parse license config
   license.conf/bbclass: Move globals to license.conf

  meta/classes/license.bbclass |   67 +-
  meta/conf/bitbake.conf   |1 +
  meta/conf/licenses.conf  |   64 
  3 files changed, 66 insertions(+), 66 deletions(-)



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

Re: [OE-core] [oe-commits] Martin Jansa : xserver-xorg: use EXTENDPKGV instead of PV in RCONFLICTS_${PN}-module-exa

2012-09-27 Thread Martin Jansa

On Thu, Sep 27, 2012 at 05:34:19PM +0200, Martin Jansa wrote:
> On Thu, Sep 27, 2012 at 02:29:25PM +, g...@git.openembedded.org wrote:
> > Module: openembedded-core.git
> > Branch: master
> > Commit: ed0216d29fc4355c5220f3ad51df04a63cacb0c3
> > URL:
> > http://git.openembedded.org/?p=openembedded-core.git&a=commit;h=ed0216d29fc4355c5220f3ad51df04a63cacb0c3
> > 
> > Author: Martin Jansa 
> > Date:   Sat Sep 22 19:13:14 2012 +0200
> > 
> > xserver-xorg: use EXTENDPKGV instead of PV in RCONFLICTS_${PN}-module-exa
> > 
> > * it doesn't make much sense with PV, because xserver-xorg-module-exa
> >   was introduced in
> >   
> > http://git.openembedded.org/openembedded-core/commit/meta/recipes-graphics/xorg-xserver?id=1a666ee1cda3c0b74daba5881fc5f62e13deec66
> >   so our xserver-xorg-module-exa RCONFLICTS with xserver-xorg (<= 1.11.2-r4)
> >   and (< 1.11.2) is not good enough
> > 
> > * because we don't know how many PRINC are in BSP/DISTRO layers,
> >   then it's safer to RCONFLICTS with every older version then current
> >   EXTENDPKGV
> > 
> > Also fixes whitespace to work correctly with opkg
> 
> The whitespace problem wasn't opkg fault AFAIK, but
> bb.utils.explode_dep_versions as shown in 
> http://patchwork.openembedded.org/patch/37069/

Ah and it was meant to be applied together with this patch, so now it's
missing PR bump..

Cheers,

> > Signed-off-by: Martin Jansa 
> > 
> > --
> > 
> > * I haven't really tested this with IPK, since it was changed from
> >   RREPLACES to RCONFLICTS (because of RPM) and all my installed devices
> >   are already upgraded
> > Signed-off-by: Richard Purdie 
> > 
> > ---
> > 
> >  .../recipes-graphics/xorg-xserver/xserver-xorg.inc |2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc 
> > b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
> > index 643ca70..7513399 100644
> > --- a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
> > +++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
> > @@ -66,7 +66,7 @@ PACKAGES =+ "${PN}-security-policy \
> >  
> >  RRECOMMENDS_${PN} += "${PN}-security-policy xkeyboard-config rgb 
> > xserver-xf86-config"
> >  RDEPENDS_${PN}-xvfb += "xkeyboard-config"
> > -RCONFLICTS_${PN}-module-exa = "${PN} (<${PV})"
> > +RCONFLICTS_${PN}-module-exa = "${PN} (< ${EXTENDPKGV})"
> >  
> >  FILES_${PN} = "${bindir} ${libdir}/X11/Options ${libdir}/X11/Cards 
> > ${libdir}/X11/getconfig ${libdir}/X11/etc ${libdir}/modules/*.so 
> > ${libdir}/xorg/modules/*.so /etc/X11 ${libdir}/xorg/protocol.txt 
> > ${datadir}/X11/xorg.conf.d"
> >  FILES_${PN}-dev += "${libdir}/xorg/modules/*.la 
> > ${libdir}/xorg/modules/*/*.la"
> > 
> > 
> > ___
> > Openembedded-commits mailing list
> > openembedded-comm...@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-commits
> 
> -- 
> Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com



-- 
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] [oe-commits] Martin Jansa : xserver-xorg: use EXTENDPKGV instead of PV in RCONFLICTS_${PN}-module-exa

2012-09-27 Thread Otavio Salvador

On Thu, Sep 27, 2012 at 2:55 PM, Martin Jansa  wrote:
> On Thu, Sep 27, 2012 at 05:34:19PM +0200, Martin Jansa wrote:
>> On Thu, Sep 27, 2012 at 02:29:25PM +, g...@git.openembedded.org wrote:
>> > Module: openembedded-core.git
>> > Branch: master
>> > Commit: ed0216d29fc4355c5220f3ad51df04a63cacb0c3
>> > URL:
>> > http://git.openembedded.org/?p=openembedded-core.git&a=commit;h=ed0216d29fc4355c5220f3ad51df04a63cacb0c3
>> >
>> > Author: Martin Jansa 
>> > Date:   Sat Sep 22 19:13:14 2012 +0200
>> >
>> > xserver-xorg: use EXTENDPKGV instead of PV in RCONFLICTS_${PN}-module-exa
>> >
>> > * it doesn't make much sense with PV, because xserver-xorg-module-exa
>> >   was introduced in
>> >   
>> > http://git.openembedded.org/openembedded-core/commit/meta/recipes-graphics/xorg-xserver?id=1a666ee1cda3c0b74daba5881fc5f62e13deec66
>> >   so our xserver-xorg-module-exa RCONFLICTS with xserver-xorg (<= 
>> > 1.11.2-r4)
>> >   and (< 1.11.2) is not good enough
>> >
>> > * because we don't know how many PRINC are in BSP/DISTRO layers,
>> >   then it's safer to RCONFLICTS with every older version then current
>> >   EXTENDPKGV
>> >
>> > Also fixes whitespace to work correctly with opkg
>>
>> The whitespace problem wasn't opkg fault AFAIK, but
>> bb.utils.explode_dep_versions as shown in
>> http://patchwork.openembedded.org/patch/37069/
>
> Ah and it was meant to be applied together with this patch, so now it's
> missing PR bump..

It keeps failing for me.

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

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

[OE-core] [PATCH] xserver-xorg: Use rdepends to ensure xserver-xorg-module-exa match version

2012-09-27 Thread Otavio Salvador

This fix the installation of xserver-xorg-module-exa package at rootfs
using opkg. It were failing as conflicts where not working properly.

Signed-off-by: Otavio Salvador 
---
 .../xorg-xserver/xserver-xorg-1.11.2.inc   |2 +-
 .../recipes-graphics/xorg-xserver/xserver-xorg.inc |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg-1.11.2.inc 
b/meta/recipes-graphics/xorg-xserver/xserver-xorg-1.11.2.inc
index 35cb33a..32bd9fd 100644
--- a/meta/recipes-graphics/xorg-xserver/xserver-xorg-1.11.2.inc
+++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg-1.11.2.inc
@@ -8,4 +8,4 @@ SRC_URI += "file://crosscompile.patch \
 SRC_URI[md5sum] = "8796fff441e5435ee36a72579008af24"
 SRC_URI[sha256sum] = 
"fa415decf02027ca278b06254ccfbcceba2a83c2741405257ebf749da4a73cf2"
 
-PR = "r8"
+PR = "r9"
diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc 
b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
index 7513399..bea0252 100644
--- a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
+++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
@@ -66,7 +66,7 @@ PACKAGES =+ "${PN}-security-policy \
 
 RRECOMMENDS_${PN} += "${PN}-security-policy xkeyboard-config rgb 
xserver-xf86-config"
 RDEPENDS_${PN}-xvfb += "xkeyboard-config"
-RCONFLICTS_${PN}-module-exa = "${PN} (< ${EXTENDPKGV})"
+RDEPENDS_${PN}-module-exa = "${PN} (= ${EXTENDPKGV})"
 
 FILES_${PN} = "${bindir} ${libdir}/X11/Options ${libdir}/X11/Cards 
${libdir}/X11/getconfig ${libdir}/X11/etc ${libdir}/modules/*.so 
${libdir}/xorg/modules/*.so /etc/X11 ${libdir}/xorg/protocol.txt 
${datadir}/X11/xorg.conf.d"
 FILES_${PN}-dev += "${libdir}/xorg/modules/*.la ${libdir}/xorg/modules/*/*.la"
-- 
1.7.2.5


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

Re: [OE-core] [oe-core][RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default

2012-09-27 Thread Mark Hatle

Let me preface this by I have read the patch set.. Martin asked me to comment on 
the items below...


On 9/27/12 3:37 AM, Martin Jansa wrote:

On Sat, Sep 22, 2012 at 06:45:44PM +0100, Richard Purdie wrote:

On Sat, 2012-09-22 at 18:51 +0200, Martin Jansa wrote:

* bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE
* this way xscale or arm926ejs is not used by default when some machine
   includes its tune*.inc, but it's easy for DISTRO to say it wants
   OPTDEFAULTTUNE for some packages or always (if they don't want to
   share built packages between xscale and arm926ejs).

Signed-off-by: Martin Jansa 
---
  meta/conf/bitbake.conf   | 1 +
  meta/conf/machine/include/tune-arm926ejs.inc | 3 ++-
  meta/conf/machine/include/tune-xscale.inc| 3 ++-
  3 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 9b41749..e433fcb 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -95,6 +95,7 @@ HOST_LD_ARCH = "${TARGET_LD_ARCH}"
  HOST_AS_ARCH = "${TARGET_AS_ARCH}"
  HOST_EXEEXT = ""

+OPTDEFAULTTUNE ??= "${DEFAULTTUNE}"
  TUNE_ARCH ??= "INVALID"
  TUNE_CCARGS ??= ""
  TUNE_LDARGS ??= ""


As I've said previously, I do not think OPTDEFAULTTUNE is clear in usage
or in meaning and we need to find a better solution. I'm therefore not
keen on this change.


OK, what about the rest of patchset (without OPTDEFAULTTUNE bits) to use
different PKGARCH for different TUNE_CCARGS?


I've been an advocate for a while that the processor optimization (CCARGS) does 
make it into the PKGARCH.  ARMPKGSFX_CPU seems like a reasonable approach to do 
this.  It allows each tune to set something to tell people what that binary is 
really built for, and for the 'base' tunes (i.e. armv5) it can be left off.


The only concern I have with that is:

+ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", 
"-arm926ejs", "", d)}"


That probably should be a .= instead of just '='.  That way if the user loads 
multiple compatible tunes the right ARMPKGSFX_CPU will be used.  (Alternatively 
using the overrides would work as well for this.. i.e. 
ARMPKGSFX_CPU_tune-arm926ejs instead...


I see Patch 5/5 instead moves toward the ARMPKGARCH usage instead...  This is 
fine as well, and it was designed to be overriden.. but again the .= or 
-tune_... syntax should be used...


Anyway, my point in this is I like having the stuff unique, but we need to be 
sure that you can specify more then one tune file during a build w/o clashes.



I also still think this is a distro packaging issue and should be solved
by the distro, even if that means more complexity there. That is the
right place for this particular complexity IMO. I'm happy to support
that from the core but not in something as user visible and confusing as
this variable.


Agreed OPTDEFAULTTUNE is to help distro configs, because complexity
there will be much worse then when it's defined in tune-* files, because
now will have to define DEFAULTTUNE/OPTDEFAULTTUNE for each MACHINE (or
TUNE_FEATURE) it supports and it's less orthogonal (machine/distro
config) then it could be.


I really don't have a strong opinion on this either way.  I know for the stuff 
I've done in the past (not oe-based) we've just manually configured (the 
equivalent of the distro conf) with the information on the handful of items that 
people wanted optimized the most...  eglibc, openssl, mysql/posgresql... 
otherwise folks don't seem to care, and re-use works fine.


If the list is small (i.e. less then 10 packages) that specifying it via package 
specific overrides in the distro file should be fine.. if it's more then 10 
(typically) then we need to start looking for another approach.


I'd almost suggest in the distro file you could do:

OPTDEFAULTTUNE = "$@{...}" where ... is check for something set by the BSP (or 
elsewhere), if set use that value, otherwise using the DEFAULTTUNE value.


DEFAULTTUNE- = "${OPTDEFAULTTUNE}"

and then everything can be encapsulated into the distro file (and distro BSPs). 
 The downside of this approach is that it's not the 'standard' implementation.


--Mark


Cheers,



___
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] [oe-core][RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default

2012-09-27 Thread Martin Jansa

On Thu, Sep 27, 2012 at 01:58:35PM -0500, Mark Hatle wrote:
> Let me preface this by I have read the patch set.. Martin asked me to comment 
> on 
> the items below...
> 
> On 9/27/12 3:37 AM, Martin Jansa wrote:
> > On Sat, Sep 22, 2012 at 06:45:44PM +0100, Richard Purdie wrote:
> >> On Sat, 2012-09-22 at 18:51 +0200, Martin Jansa wrote:
> >>> * bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE
> >>> * this way xscale or arm926ejs is not used by default when some machine
> >>>includes its tune*.inc, but it's easy for DISTRO to say it wants
> >>>OPTDEFAULTTUNE for some packages or always (if they don't want to
> >>>share built packages between xscale and arm926ejs).
> >>>
> >>> Signed-off-by: Martin Jansa 
> >>> ---
> >>>   meta/conf/bitbake.conf   | 1 +
> >>>   meta/conf/machine/include/tune-arm926ejs.inc | 3 ++-
> >>>   meta/conf/machine/include/tune-xscale.inc| 3 ++-
> >>>   3 files changed, 5 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> >>> index 9b41749..e433fcb 100644
> >>> --- a/meta/conf/bitbake.conf
> >>> +++ b/meta/conf/bitbake.conf
> >>> @@ -95,6 +95,7 @@ HOST_LD_ARCH = "${TARGET_LD_ARCH}"
> >>>   HOST_AS_ARCH = "${TARGET_AS_ARCH}"
> >>>   HOST_EXEEXT = ""
> >>>
> >>> +OPTDEFAULTTUNE ??= "${DEFAULTTUNE}"
> >>>   TUNE_ARCH ??= "INVALID"
> >>>   TUNE_CCARGS ??= ""
> >>>   TUNE_LDARGS ??= ""
> >>
> >> As I've said previously, I do not think OPTDEFAULTTUNE is clear in usage
> >> or in meaning and we need to find a better solution. I'm therefore not
> >> keen on this change.
> >
> > OK, what about the rest of patchset (without OPTDEFAULTTUNE bits) to use
> > different PKGARCH for different TUNE_CCARGS?
> 
> I've been an advocate for a while that the processor optimization (CCARGS) 
> does 
> make it into the PKGARCH.  ARMPKGSFX_CPU seems like a reasonable approach to 
> do 
> this.  It allows each tune to set something to tell people what that binary 
> is 
> really built for, and for the 'base' tunes (i.e. armv5) it can be left off.
> 
> The only concern I have with that is:
> 
> +ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", 
> "-arm926ejs", "", d)}"
> 
> That probably should be a .= instead of just '='.  That way if the user loads 
> multiple compatible tunes the right ARMPKGSFX_CPU will be used.  
> (Alternatively 
> using the overrides would work as well for this.. i.e. 
> ARMPKGSFX_CPU_tune-arm926ejs instead...

OK.

> I see Patch 5/5 instead moves toward the ARMPKGARCH usage instead...  This is 
> fine as well, and it was designed to be overriden.. but again the .= or 
> -tune_... syntax should be used...

I tend to prefer ARMPKGARCH as it's shorter xscale-te/armv5te-xscale.

But not sure what to do with all "lower" PACKAGE_EXTRA_ARCHS:
PACKAGE_EXTRA_ARCHS_tune-xscale-be = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}"
do we want PACKAGE_EXTRA_ARCHS_tune-armv5teb only or also something like
armv4t-xscale?

Well whole PACKAGE_EXTRA_ARCHS has too many entries already (opkg update
would try to download many feeds but only a few does exist).

> Anyway, my point in this is I like having the stuff unique, but we need to be 
> sure that you can specify more then one tune file during a build w/o clashes.
> 
> >> I also still think this is a distro packaging issue and should be solved
> >> by the distro, even if that means more complexity there. That is the
> >> right place for this particular complexity IMO. I'm happy to support
> >> that from the core but not in something as user visible and confusing as
> >> this variable.
> >
> > Agreed OPTDEFAULTTUNE is to help distro configs, because complexity
> > there will be much worse then when it's defined in tune-* files, because
> > now will have to define DEFAULTTUNE/OPTDEFAULTTUNE for each MACHINE (or
> > TUNE_FEATURE) it supports and it's less orthogonal (machine/distro
> > config) then it could be.
> 
> I really don't have a strong opinion on this either way.  I know for the 
> stuff 
> I've done in the past (not oe-based) we've just manually configured (the 
> equivalent of the distro conf) with the information on the handful of items 
> that 
> people wanted optimized the most...  eglibc, openssl, mysql/posgresql... 
> otherwise folks don't seem to care, and re-use works fine.
> 
> If the list is small (i.e. less then 10 packages) that specifying it via 
> package 
> specific overrides in the distro file should be fine.. if it's more then 10 
> (typically) then we need to start looking for another approach.
> 
> I'd almost suggest in the distro file you could do:
> 
> OPTDEFAULTTUNE = "$@{...}" where ... is check for something set by the BSP 
> (or 
> elsewhere), if set use that value, otherwise using the DEFAULTTUNE value.
> 
> DEFAULTTUNE- = "${OPTDEFAULTTUNE}"

Yes but first I have to say:
DEFAULTTUNE_spitz = armv5te
OPTDEFAULTTUNE_spitz = xscale
DEFAULTTUNE_qemuarm = armv5te
OPTDEFAULTTUNE_qemuarm = arm926ejs
or
DEFA

Re: [OE-core] [oe-core][RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default

2012-09-27 Thread Mark Hatle


On 9/27/12 2:12 PM, Martin Jansa wrote:

On Thu, Sep 27, 2012 at 01:58:35PM -0500, Mark Hatle wrote:

Let me preface this by I have read the patch set.. Martin asked me to comment on
the items below...

On 9/27/12 3:37 AM, Martin Jansa wrote:

On Sat, Sep 22, 2012 at 06:45:44PM +0100, Richard Purdie wrote:

On Sat, 2012-09-22 at 18:51 +0200, Martin Jansa wrote:

* bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE
* this way xscale or arm926ejs is not used by default when some machine
includes its tune*.inc, but it's easy for DISTRO to say it wants
OPTDEFAULTTUNE for some packages or always (if they don't want to
share built packages between xscale and arm926ejs).

Signed-off-by: Martin Jansa 
---
   meta/conf/bitbake.conf   | 1 +
   meta/conf/machine/include/tune-arm926ejs.inc | 3 ++-
   meta/conf/machine/include/tune-xscale.inc| 3 ++-
   3 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 9b41749..e433fcb 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -95,6 +95,7 @@ HOST_LD_ARCH = "${TARGET_LD_ARCH}"
   HOST_AS_ARCH = "${TARGET_AS_ARCH}"
   HOST_EXEEXT = ""

+OPTDEFAULTTUNE ??= "${DEFAULTTUNE}"
   TUNE_ARCH ??= "INVALID"
   TUNE_CCARGS ??= ""
   TUNE_LDARGS ??= ""


As I've said previously, I do not think OPTDEFAULTTUNE is clear in usage
or in meaning and we need to find a better solution. I'm therefore not
keen on this change.


OK, what about the rest of patchset (without OPTDEFAULTTUNE bits) to use
different PKGARCH for different TUNE_CCARGS?


I've been an advocate for a while that the processor optimization (CCARGS) does
make it into the PKGARCH.  ARMPKGSFX_CPU seems like a reasonable approach to do
this.  It allows each tune to set something to tell people what that binary is
really built for, and for the 'base' tunes (i.e. armv5) it can be left off.

The only concern I have with that is:

+ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs",
"-arm926ejs", "", d)}"

That probably should be a .= instead of just '='.  That way if the user loads
multiple compatible tunes the right ARMPKGSFX_CPU will be used.  (Alternatively
using the overrides would work as well for this.. i.e.
ARMPKGSFX_CPU_tune-arm926ejs instead...


OK.


I see Patch 5/5 instead moves toward the ARMPKGARCH usage instead...  This is
fine as well, and it was designed to be overriden.. but again the .= or
-tune_... syntax should be used...


I tend to prefer ARMPKGARCH as it's shorter xscale-te/armv5te-xscale.

But not sure what to do with all "lower" PACKAGE_EXTRA_ARCHS:
PACKAGE_EXTRA_ARCHS_tune-xscale-be = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}"
do we want PACKAGE_EXTRA_ARCHS_tune-armv5teb only or also something like
armv4t-xscale?

Well whole PACKAGE_EXTRA_ARCHS has too many entries already (opkg update
would try to download many feeds but only a few does exist).


The PACKAGE_EXTRA_ARCHS should contain all of the 'compatible' arch names. 
Which of course feed into the list of feeds used by the various packaging 
systems.  I think it's up to the distribution to modify or limit the feeds 
resolved, but I don't know if there is a clean way to do this.  I always error 
on listing more then less, because I don't know how people are going to want to 
mix and match things.  (And a BSP or end user can always just define what the 
PACKAGE_EXTRA_ARCHS value should be.)



Anyway, my point in this is I like having the stuff unique, but we need to be
sure that you can specify more then one tune file during a build w/o clashes.


I also still think this is a distro packaging issue and should be solved
by the distro, even if that means more complexity there. That is the
right place for this particular complexity IMO. I'm happy to support
that from the core but not in something as user visible and confusing as
this variable.


Agreed OPTDEFAULTTUNE is to help distro configs, because complexity
there will be much worse then when it's defined in tune-* files, because
now will have to define DEFAULTTUNE/OPTDEFAULTTUNE for each MACHINE (or
TUNE_FEATURE) it supports and it's less orthogonal (machine/distro
config) then it could be.


I really don't have a strong opinion on this either way.  I know for the stuff
I've done in the past (not oe-based) we've just manually configured (the
equivalent of the distro conf) with the information on the handful of items that
people wanted optimized the most...  eglibc, openssl, mysql/posgresql...
otherwise folks don't seem to care, and re-use works fine.

If the list is small (i.e. less then 10 packages) that specifying it via package
specific overrides in the distro file should be fine.. if it's more then 10
(typically) then we need to start looking for another approach.

I'd almost suggest in the distro file you could do:

OPTDEFAULTTUNE = "$@{...}" where ... is check for something set by the BSP (or
elsewhere), if set use that value, otherwise using the DE

Re: [OE-core] [oe-core][RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default

2012-09-27 Thread Martin Jansa

On Thu, Sep 27, 2012 at 02:18:07PM -0500, Mark Hatle wrote:
> On 9/27/12 2:12 PM, Martin Jansa wrote:
> > On Thu, Sep 27, 2012 at 01:58:35PM -0500, Mark Hatle wrote:
> >> Let me preface this by I have read the patch set.. Martin asked me to 
> >> comment on
> >> the items below...
> >>
> >> On 9/27/12 3:37 AM, Martin Jansa wrote:
> >>> On Sat, Sep 22, 2012 at 06:45:44PM +0100, Richard Purdie wrote:
>  On Sat, 2012-09-22 at 18:51 +0200, Martin Jansa wrote:
> > * bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE
> > * this way xscale or arm926ejs is not used by default when some machine
> > includes its tune*.inc, but it's easy for DISTRO to say it wants
> > OPTDEFAULTTUNE for some packages or always (if they don't want to
> > share built packages between xscale and arm926ejs).
> >
> > Signed-off-by: Martin Jansa 
> > ---
> >meta/conf/bitbake.conf   | 1 +
> >meta/conf/machine/include/tune-arm926ejs.inc | 3 ++-
> >meta/conf/machine/include/tune-xscale.inc| 3 ++-
> >3 files changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> > index 9b41749..e433fcb 100644
> > --- a/meta/conf/bitbake.conf
> > +++ b/meta/conf/bitbake.conf
> > @@ -95,6 +95,7 @@ HOST_LD_ARCH = "${TARGET_LD_ARCH}"
> >HOST_AS_ARCH = "${TARGET_AS_ARCH}"
> >HOST_EXEEXT = ""
> >
> > +OPTDEFAULTTUNE ??= "${DEFAULTTUNE}"
> >TUNE_ARCH ??= "INVALID"
> >TUNE_CCARGS ??= ""
> >TUNE_LDARGS ??= ""
> 
>  As I've said previously, I do not think OPTDEFAULTTUNE is clear in usage
>  or in meaning and we need to find a better solution. I'm therefore not
>  keen on this change.
> >>>
> >>> OK, what about the rest of patchset (without OPTDEFAULTTUNE bits) to use
> >>> different PKGARCH for different TUNE_CCARGS?
> >>
> >> I've been an advocate for a while that the processor optimization (CCARGS) 
> >> does
> >> make it into the PKGARCH.  ARMPKGSFX_CPU seems like a reasonable approach 
> >> to do
> >> this.  It allows each tune to set something to tell people what that 
> >> binary is
> >> really built for, and for the 'base' tunes (i.e. armv5) it can be left off.
> >>
> >> The only concern I have with that is:
> >>
> >> +ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs",
> >> "-arm926ejs", "", d)}"
> >>
> >> That probably should be a .= instead of just '='.  That way if the user 
> >> loads
> >> multiple compatible tunes the right ARMPKGSFX_CPU will be used.  
> >> (Alternatively
> >> using the overrides would work as well for this.. i.e.
> >> ARMPKGSFX_CPU_tune-arm926ejs instead...
> >
> > OK.
> >
> >> I see Patch 5/5 instead moves toward the ARMPKGARCH usage instead...  This 
> >> is
> >> fine as well, and it was designed to be overriden.. but again the .= or
> >> -tune_... syntax should be used...
> >
> > I tend to prefer ARMPKGARCH as it's shorter xscale-te/armv5te-xscale.
> >
> > But not sure what to do with all "lower" PACKAGE_EXTRA_ARCHS:
> > PACKAGE_EXTRA_ARCHS_tune-xscale-be = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}"
> > do we want PACKAGE_EXTRA_ARCHS_tune-armv5teb only or also something like
> > armv4t-xscale?
> >
> > Well whole PACKAGE_EXTRA_ARCHS has too many entries already (opkg update
> > would try to download many feeds but only a few does exist).
> 
> The PACKAGE_EXTRA_ARCHS should contain all of the 'compatible' arch names. 
> Which of course feed into the list of feeds used by the various packaging 
> systems.  I think it's up to the distribution to modify or limit the feeds 
> resolved, but I don't know if there is a clean way to do this.  I always 
> error 
> on listing more then less, because I don't know how people are going to want 
> to 
> mix and match things.  (And a BSP or end user can always just define what the 
> PACKAGE_EXTRA_ARCHS value should be.)

Yes that's what I do now, but I'm not too happy about it :/
SUPPORTED_EXTRA_ARCHS ?= "armv4t armv5te armv6-novfp armv7a-vfp-neon x86_64 x86"
SUPPORTED_EXTRA_ARCHS_armv7a ?= "armv7a-vfp-neon"
SUPPORTED_EXTRA_ARCHS_armv6 ?= "armv6-novfp"

> >> Anyway, my point in this is I like having the stuff unique, but we need to 
> >> be
> >> sure that you can specify more then one tune file during a build w/o 
> >> clashes.
> >>
>  I also still think this is a distro packaging issue and should be solved
>  by the distro, even if that means more complexity there. That is the
>  right place for this particular complexity IMO. I'm happy to support
>  that from the core but not in something as user visible and confusing as
>  this variable.
> >>>
> >>> Agreed OPTDEFAULTTUNE is to help distro configs, because complexity
> >>> there will be much worse then when it's defined in tune-* files, because
> >>> now will have to define DEFAULTTUNE/OPTDEFAULTTUNE for each MACHINE (or
> >>> TUNE_FEATURE) it supports

Re: [OE-core] [oe-core][RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default

2012-09-27 Thread Mark Hatle


On 9/27/12 2:40 PM, Martin Jansa wrote:

On Thu, Sep 27, 2012 at 02:18:07PM -0500, Mark Hatle wrote:

On 9/27/12 2:12 PM, Martin Jansa wrote:

On Thu, Sep 27, 2012 at 01:58:35PM -0500, Mark Hatle wrote:

Let me preface this by I have read the patch set.. Martin asked me to comment on
the items below...

On 9/27/12 3:37 AM, Martin Jansa wrote:

On Sat, Sep 22, 2012 at 06:45:44PM +0100, Richard Purdie wrote:

On Sat, 2012-09-22 at 18:51 +0200, Martin Jansa wrote:

* bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE
* this way xscale or arm926ejs is not used by default when some machine
 includes its tune*.inc, but it's easy for DISTRO to say it wants
 OPTDEFAULTTUNE for some packages or always (if they don't want to
 share built packages between xscale and arm926ejs).

Signed-off-by: Martin Jansa 
---
meta/conf/bitbake.conf   | 1 +
meta/conf/machine/include/tune-arm926ejs.inc | 3 ++-
meta/conf/machine/include/tune-xscale.inc| 3 ++-
3 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 9b41749..e433fcb 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -95,6 +95,7 @@ HOST_LD_ARCH = "${TARGET_LD_ARCH}"
HOST_AS_ARCH = "${TARGET_AS_ARCH}"
HOST_EXEEXT = ""

+OPTDEFAULTTUNE ??= "${DEFAULTTUNE}"
TUNE_ARCH ??= "INVALID"
TUNE_CCARGS ??= ""
TUNE_LDARGS ??= ""


As I've said previously, I do not think OPTDEFAULTTUNE is clear in usage
or in meaning and we need to find a better solution. I'm therefore not
keen on this change.


OK, what about the rest of patchset (without OPTDEFAULTTUNE bits) to use
different PKGARCH for different TUNE_CCARGS?


I've been an advocate for a while that the processor optimization (CCARGS) does
make it into the PKGARCH.  ARMPKGSFX_CPU seems like a reasonable approach to do
this.  It allows each tune to set something to tell people what that binary is
really built for, and for the 'base' tunes (i.e. armv5) it can be left off.

The only concern I have with that is:

+ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs",
"-arm926ejs", "", d)}"

That probably should be a .= instead of just '='.  That way if the user loads
multiple compatible tunes the right ARMPKGSFX_CPU will be used.  (Alternatively
using the overrides would work as well for this.. i.e.
ARMPKGSFX_CPU_tune-arm926ejs instead...


OK.


I see Patch 5/5 instead moves toward the ARMPKGARCH usage instead...  This is
fine as well, and it was designed to be overriden.. but again the .= or
-tune_... syntax should be used...


I tend to prefer ARMPKGARCH as it's shorter xscale-te/armv5te-xscale.

But not sure what to do with all "lower" PACKAGE_EXTRA_ARCHS:
PACKAGE_EXTRA_ARCHS_tune-xscale-be = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}"
do we want PACKAGE_EXTRA_ARCHS_tune-armv5teb only or also something like
armv4t-xscale?

Well whole PACKAGE_EXTRA_ARCHS has too many entries already (opkg update
would try to download many feeds but only a few does exist).


The PACKAGE_EXTRA_ARCHS should contain all of the 'compatible' arch names.
Which of course feed into the list of feeds used by the various packaging
systems.  I think it's up to the distribution to modify or limit the feeds
resolved, but I don't know if there is a clean way to do this.  I always error
on listing more then less, because I don't know how people are going to want to
mix and match things.  (And a BSP or end user can always just define what the
PACKAGE_EXTRA_ARCHS value should be.)


Yes that's what I do now, but I'm not too happy about it :/
SUPPORTED_EXTRA_ARCHS ?= "armv4t armv5te armv6-novfp armv7a-vfp-neon x86_64 x86"
SUPPORTED_EXTRA_ARCHS_armv7a ?= "armv7a-vfp-neon"
SUPPORTED_EXTRA_ARCHS_armv6 ?= "armv6-novfp"


Anyway, my point in this is I like having the stuff unique, but we need to be
sure that you can specify more then one tune file during a build w/o clashes.


I also still think this is a distro packaging issue and should be solved
by the distro, even if that means more complexity there. That is the
right place for this particular complexity IMO. I'm happy to support
that from the core but not in something as user visible and confusing as
this variable.


Agreed OPTDEFAULTTUNE is to help distro configs, because complexity
there will be much worse then when it's defined in tune-* files, because
now will have to define DEFAULTTUNE/OPTDEFAULTTUNE for each MACHINE (or
TUNE_FEATURE) it supports and it's less orthogonal (machine/distro
config) then it could be.


I really don't have a strong opinion on this either way.  I know for the stuff
I've done in the past (not oe-based) we've just manually configured (the
equivalent of the distro conf) with the information on the handful of items that
people wanted optimized the most...  eglibc, openssl, mysql/posgresql...
otherwise folks don't seem to care, and re-use works fine.

If the list is small (i.e. less then 10 packages) that specifying

Re: [OE-core] [PATCH] perl: Fix nativesdk install path

2012-09-27 Thread Mark Hatle

I had to revert this patch.  With it enabled, if I enable multilibs and build 
for x86_64 (so my libdir == /usr/lib64), perl no longer finishes do_install().


When I revert it fixes that issue, but of course then the nativesdk is broken 
again.

--Mark

On 9/27/12 10:32 AM, Saul Wold wrote:

On 09/27/2012 05:20 AM, Christian Glindkamp wrote:

Commit 38234f2e276356b1d77a87ceabc486107e336d19 tried to fix the sed
expressions by anchoring the left side of the search regexp to prevent
$prefix$prefix type expression in the perl config. For nativesdk this is
not enough. Adding anchors on both side fixes this.

Signed-off-by: Christian Glindkamp 
---

This is currently only build tested, but buildhistory for perl did not change.

   meta/recipes-devtools/perl/perl_5.14.2.bb |8 
   1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-devtools/perl/perl_5.14.2.bb 
b/meta/recipes-devtools/perl/perl_5.14.2.bb
index 3c1360f..0009855 100644
--- a/meta/recipes-devtools/perl/perl_5.14.2.bb
+++ b/meta/recipes-devtools/perl/perl_5.14.2.bb
@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM = 
"file://Copying;md5=2b4c6ffbcfcbdee469f02565f253d81a \
   # We need gnugrep (for -I)
   DEPENDS = "virtual/db grep-native"
   DEPENDS += "gdbm zlib"
-PR = "r9"
+PR = "r10"

   # 5.10.1 has Module::Build built-in
   PROVIDES += "libmodule-build-perl"
@@ -150,9 +150,9 @@ do_configure() {
  -e 's,@ARCH@-thread-multi,,g' \
  -e 's,@ARCH@,${TARGET_ARCH}-${TARGET_OS},g' \
  -e 's,@STAGINGDIR@,${STAGING_DIR_HOST},g' \
-   -e "s%\([ \"^\',=]\+\)/usr/include%\1${STAGING_INCDIR}%g" \
-  -e "s%\([ \"^\',=]\+\)/usr/lib/%\1${libdir}/%g" \
-  -e "s%\([ \"^\',=]\+\)/usr/%\1${exec_prefix}/%g" \
+   -e "s%\([ \"^\',=]\+\)/usr/include\([ 
\"^\',=]\+\)%\1${STAGING_INCDIR}\2%g" \
+  -e "s%\([ \"^\',=]\+\)/usr/lib/\([ 
\"^\',=]\+\)%\1${libdir}/\2%g" \
+  -e "s%\([ \"^\',=]\+\)/usr/\([ 
\"^\',=]\+\)%\1${exec_prefix}/\2%g" \
   -e "s%/perl5%/perl%g" \
   config.sh-${TARGET_ARCH}-${TARGET_OS}




Merged into OE-Core

Thanks  
Sau!


___
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] [oe-core][RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default

2012-09-27 Thread Martin Jansa

On Thu, Sep 27, 2012 at 02:53:21PM -0500, Mark Hatle wrote:
> On 9/27/12 2:40 PM, Martin Jansa wrote:
> > On Thu, Sep 27, 2012 at 02:18:07PM -0500, Mark Hatle wrote:
> >> On 9/27/12 2:12 PM, Martin Jansa wrote:
> >>> On Thu, Sep 27, 2012 at 01:58:35PM -0500, Mark Hatle wrote:
>  Let me preface this by I have read the patch set.. Martin asked me to 
>  comment on
>  the items below...
> 
>  On 9/27/12 3:37 AM, Martin Jansa wrote:
> > On Sat, Sep 22, 2012 at 06:45:44PM +0100, Richard Purdie wrote:
> >> On Sat, 2012-09-22 at 18:51 +0200, Martin Jansa wrote:
> >>> * bitbake.conf has OPTDEFAULTTUNE with weak default value of 
> >>> DEFAULTTUNE
> >>> * this way xscale or arm926ejs is not used by default when some 
> >>> machine
> >>>  includes its tune*.inc, but it's easy for DISTRO to say it wants
> >>>  OPTDEFAULTTUNE for some packages or always (if they don't want to
> >>>  share built packages between xscale and arm926ejs).
> >>>
> >>> Signed-off-by: Martin Jansa 
> >>> ---
> >>> meta/conf/bitbake.conf   | 1 +
> >>> meta/conf/machine/include/tune-arm926ejs.inc | 3 ++-
> >>> meta/conf/machine/include/tune-xscale.inc| 3 ++-
> >>> 3 files changed, 5 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> >>> index 9b41749..e433fcb 100644
> >>> --- a/meta/conf/bitbake.conf
> >>> +++ b/meta/conf/bitbake.conf
> >>> @@ -95,6 +95,7 @@ HOST_LD_ARCH = "${TARGET_LD_ARCH}"
> >>> HOST_AS_ARCH = "${TARGET_AS_ARCH}"
> >>> HOST_EXEEXT = ""
> >>>
> >>> +OPTDEFAULTTUNE ??= "${DEFAULTTUNE}"
> >>> TUNE_ARCH ??= "INVALID"
> >>> TUNE_CCARGS ??= ""
> >>> TUNE_LDARGS ??= ""
> >>
> >> As I've said previously, I do not think OPTDEFAULTTUNE is clear in 
> >> usage
> >> or in meaning and we need to find a better solution. I'm therefore not
> >> keen on this change.
> >
> > OK, what about the rest of patchset (without OPTDEFAULTTUNE bits) to use
> > different PKGARCH for different TUNE_CCARGS?
> 
>  I've been an advocate for a while that the processor optimization 
>  (CCARGS) does
>  make it into the PKGARCH.  ARMPKGSFX_CPU seems like a reasonable 
>  approach to do
>  this.  It allows each tune to set something to tell people what that 
>  binary is
>  really built for, and for the 'base' tunes (i.e. armv5) it can be left 
>  off.
> 
>  The only concern I have with that is:
> 
>  +ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs",
>  "-arm926ejs", "", d)}"
> 
>  That probably should be a .= instead of just '='.  That way if the user 
>  loads
>  multiple compatible tunes the right ARMPKGSFX_CPU will be used.  
>  (Alternatively
>  using the overrides would work as well for this.. i.e.
>  ARMPKGSFX_CPU_tune-arm926ejs instead...
> >>>
> >>> OK.
> >>>
>  I see Patch 5/5 instead moves toward the ARMPKGARCH usage instead...  
>  This is
>  fine as well, and it was designed to be overriden.. but again the .= or
>  -tune_... syntax should be used...
> >>>
> >>> I tend to prefer ARMPKGARCH as it's shorter xscale-te/armv5te-xscale.
> >>>
> >>> But not sure what to do with all "lower" PACKAGE_EXTRA_ARCHS:
> >>> PACKAGE_EXTRA_ARCHS_tune-xscale-be = 
> >>> "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}"
> >>> do we want PACKAGE_EXTRA_ARCHS_tune-armv5teb only or also something like
> >>> armv4t-xscale?
> >>>
> >>> Well whole PACKAGE_EXTRA_ARCHS has too many entries already (opkg update
> >>> would try to download many feeds but only a few does exist).
> >>
> >> The PACKAGE_EXTRA_ARCHS should contain all of the 'compatible' arch names.
> >> Which of course feed into the list of feeds used by the various packaging
> >> systems.  I think it's up to the distribution to modify or limit the feeds
> >> resolved, but I don't know if there is a clean way to do this.  I always 
> >> error
> >> on listing more then less, because I don't know how people are going to 
> >> want to
> >> mix and match things.  (And a BSP or end user can always just define what 
> >> the
> >> PACKAGE_EXTRA_ARCHS value should be.)
> >
> > Yes that's what I do now, but I'm not too happy about it :/
> > SUPPORTED_EXTRA_ARCHS ?= "armv4t armv5te armv6-novfp armv7a-vfp-neon x86_64 
> > x86"
> > SUPPORTED_EXTRA_ARCHS_armv7a ?= "armv7a-vfp-neon"
> > SUPPORTED_EXTRA_ARCHS_armv6 ?= "armv6-novfp"
> >
>  Anyway, my point in this is I like having the stuff unique, but we need 
>  to be
>  sure that you can specify more then one tune file during a build w/o 
>  clashes.
> 
> >> I also still think this is a distro packaging issue and should be 
> >> solved
> >> by the distro, even if that means more complexity there. That is the
> >> right place for this particular comp

Re: [OE-core] [oe-commits] Andrei Gherzan : busybox: Package hwclock.sh initscript separately

2012-09-27 Thread Martin Jansa

On Fri, Aug 17, 2012 at 05:09:34PM +, g...@git.openembedded.org wrote:
> Module: openembedded-core.git
> Branch: master
> Commit: b97e37e1444ef32e7837dcc79e3fad36c4284b65
> URL:
> http://git.openembedded.org/?p=openembedded-core.git&a=commit;h=b97e37e1444ef32e7837dcc79e3fad36c4284b65
> 
> Author: Andrei Gherzan 
> Date:   Fri Aug 17 00:15:15 2012 +0300
> 
> busybox: Package hwclock.sh initscript separately
> 
> We package this separately to be able to pull this in only if this makes
> sense for the MACHINE.
> 
> Signed-off-by: Andrei Gherzan 
> Signed-off-by: Saul Wold 
> 
> ---
> 
>  meta/recipes-core/busybox/busybox.inc |5 +++--
>  1 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/recipes-core/busybox/busybox.inc 
> b/meta/recipes-core/busybox/busybox.inc
> index 78239a2..5a5b383 100644
> --- a/meta/recipes-core/busybox/busybox.inc
> +++ b/meta/recipes-core/busybox/busybox.inc
> @@ -14,15 +14,16 @@ SECTION = "base"
>  export EXTRA_CFLAGS = "${CFLAGS}"
>  export EXTRA_LDFLAGS = "${LDFLAGS}"
>  
> -PACKAGES =+ "${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog ${PN}-mdev"
> +PACKAGES =+ "${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog ${PN}-mdev 
> ${PN}-hwclock"
>  
>  FILES_${PN}-httpd = "${sysconfdir}/init.d/busybox-httpd /srv/www"
>  FILES_${PN}-syslog = "${sysconfdir}/init.d/syslog* 
> ${sysconfdir}/syslog-startup.conf*"
>  FILES_${PN}-mdev = "${sysconfdir}/init.d/mdev ${sysconfdir}/mdev.conf"
>  FILES_${PN}-udhcpd = "${sysconfdir}/init.d/busybox-udhcpd"
>  FILES_${PN}-udhcpc = "${sysconfdir}/udhcpc.d ${datadir}/udhcpc"
> +FILES_${PN}-hwclock = "${sysconfdir}/init.d/hwclock.sh"
>  
> -INITSCRIPT_PACKAGES = "${PN}-httpd ${PN}-syslog ${PN}-udhcpd ${PN}-mdev"
> +INITSCRIPT_PACKAGES = "${PN}-httpd ${PN}-syslog ${PN}-udhcpd ${PN}-mdev 
> ${PN}-hwclock""
>  
>  INITSCRIPT_NAME_${PN}-httpd = "busybox-httpd"
>  INITSCRIPT_NAME_${PN}-syslog = "syslog"

Missing 
INITSCRIPT_NAME_${PN}-hwclock = "hwclock.sh"
?

Did you test it? 

Here it fails like this:
Configuring busybox-hwclock.
usage: update-rc.d [-n] [-f] [-r ]  remove
   update-rc.d [-n] [-r ] [-s]  defaults [NN | sNN kNN]
   update-rc.d [-n] [-r ] [-s]  start|stop NN runlvl 
[runlvl] [...] .
-n: not really
-f: force
-v: verbose
-r: alternate root path (default is /)
-s: invoke start methods if appropriate to current runlevel
Collected errors:
 * pkg_run_script: package "busybox-hwclock" postinst script returned status 1.
 * opkg_configure: busybox-hwclock.postinst returned 1.

And indeed it's broken:
SHR root@qemux86-64 ~ $ cat /var/lib/opkg/info/busybox-hwclock.postinst
#!/bin/sh
if test "x$D" != "x"; then
OPT="-r $D"
else
OPT="-s"
fi
update-rc.d $OPT ${INITSCRIPT_NAME} defaults

Cheers,

-- 
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] [PATCH] staging: Avoid staging the same binaries again and again

2012-09-27 Thread Phil Blundell

On Mon, 2012-09-24 at 10:54 +0100, Richard Purdie wrote:
> sysroot_stage_* are symmetrical so I can't imagine this happening.
> 
> The main worry would be something happening before sysroot_stage_all.
> SYSROOT_PREPROCESS_FUNCS happen afterwards so there is at least a hook
> used in most cases that would avoid the issue.
> 
> I'm torn whether its better to be simple or less fragile in this case.
> Or simply do some tests (if ${bindir} != ${sbindir}) and so on.

I'm not quite sure what the conclusion was from this previous
discussion.  Did you want me to redo the patch to work in some other
way?

p.


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

Re: [OE-core] [PATCH] staging: Avoid staging the same binaries again and again

2012-09-27 Thread Richard Purdie

On Thu, 2012-09-27 at 22:18 +0100, Phil Blundell wrote:
> On Mon, 2012-09-24 at 10:54 +0100, Richard Purdie wrote:
> > sysroot_stage_* are symmetrical so I can't imagine this happening.
> > 
> > The main worry would be something happening before sysroot_stage_all.
> > SYSROOT_PREPROCESS_FUNCS happen afterwards so there is at least a hook
> > used in most cases that would avoid the issue.
> > 
> > I'm torn whether its better to be simple or less fragile in this case.
> > Or simply do some tests (if ${bindir} != ${sbindir}) and so on.
> 
> I'm not quite sure what the conclusion was from this previous
> discussion.  Did you want me to redo the patch to work in some other
> way?

The release is now at -rc2 and this patch hasn't reached the threshold
of things I'm willing to take. I've tried to at least get some of the
patches you're posted in but I wish we'd had them a couple of weeks
ago :/.

I also wish we could find some neater/simpler way of doing this since
I'm not a fan of "obscuring" the code more than we have to. I'm not
coming up with any great ways of doing it though.

Cheers,

Richard

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

[OE-core] OE-Core Release Status

2012-09-27 Thread Richard Purdie

We're now at -rc2 for the October release of OE-Core. I've noticed a
sudden surge of patches on the list, several of which are things like
version increments which are no longer really appropriate at this point
in the release cycle.

Why haven't we branched?

The plus side of branching now would be continued patches into master.
The downside is that QA and autobuilder resources are concentrating on
release and hence not on ensuring regressions are being added. I also
really need my energy focused on the release rather than reviewing other
code. I'm out of bandwidth so I'm putting off branching.

There is also the risk that if we branch, people will continue with
master development and ignore the release branch and I'd like to apply a
little pressure against this.

So if patches are getting ignored its likely they've been deemed not
suited to the state of the tree right now. I may start to queue things
on master-next but no guarantees and I would ask people to try and help
make the release a good one.

If there are patches being ignored you think do qualify for -rcX, please
ping me as it is hard to keep track of everything.

Cheers,

Richard










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

[OE-core] [PATCH] tcl: Fix dangerous do_install staging references

2012-09-27 Thread Richard Purdie

Nothing should ever be poking files directly into the staging/sysroot
directories, it should always go through ${D}.

This patch ensures this recipe does this and hence fixes various
potential build issues such as lack of sstate tracking of files.

Signed-off-by: Richard Purdie 
---
diff --git a/meta/recipes-devtools/tcltk/tcl_8.5.11.bb 
b/meta/recipes-devtools/tcltk/tcl_8.5.11.bb
index e5fe7d3..fab6057 100644
--- a/meta/recipes-devtools/tcltk/tcl_8.5.11.bb
+++ b/meta/recipes-devtools/tcltk/tcl_8.5.11.bb
@@ -44,7 +44,7 @@ do_compile_prepend() {
 
 do_install() {
autotools_do_install
-   oe_libinstall -so libtcl8.5 ${STAGING_LIBDIR}
+   oe_libinstall -so libtcl8.5 ${D}${libdir}
ln -sf ./tclsh8.5 ${D}${bindir}/tclsh
sed -i "s+${WORKDIR}+${STAGING_INCDIR}+g" tclConfig.sh
sed -i "s,-L${libdir},-L=${libdir},g" tclConfig.sh
@@ -54,8 +54,8 @@ do_install() {
cd ..
for dir in compat generic unix
do
-   install -d ${STAGING_INCDIR}/tcl${PV}/$dir
-   install -m 0644 $dir/*.h ${STAGING_INCDIR}/tcl${PV}/$dir/
+   install -d ${D}${includedir}/tcl${PV}/$dir
+   install -m 0644 $dir/*.h ${D}${includedir}/tcl${PV}/$dir/
done
 }
 



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

[OE-core] [PATCH] sstate: Relax the duplicate file whitelist for now

2012-09-27 Thread Richard Purdie

do_package is a machine specific task at the moment due to packagedata. This 
means
do_package tasks and their dependencies rerun between different machines
with various duplicate file installations. There are plans to fix this but 
they're
too invasive before release.

This patch relaxes the whitelist for sstate duplicate file detection to account
for this. Post-release, we re-enable stricter settings once do_package is not
machine specific.

Signed-off-by: Richard Purdie 
---
diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index 6878e1a..03f083e 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -17,7 +17,11 @@ SSTATE_EXTRAPATH   = ""
 SSTATE_EXTRAPATHWILDCARD = ""
 SSTATE_PATHSPEC   = 
"${SSTATE_DIR}/${SSTATE_EXTRAPATHWILDCARD}*/${SSTATE_PKGSPEC}"
 
-SSTATE_DUPWHITELIST = "${DEPLOY_DIR_IMAGE}/ ${DEPLOY_DIR}/licenses/ 
${DEPLOY_DIR_IPK}/all/ ${DEPLOY_DIR_RPM}/all ${DEPLOY_DIR_DEB}/all/"
+# In theory we should be using:
+# SSTATE_DUPWHITELIST = "${DEPLOY_DIR_IMAGE}/ ${DEPLOY_DIR}/licenses/ 
${DEPLOY_DIR_IPK}/all/ ${DEPLOY_DIR_RPM}/all ${DEPLOY_DIR_DEB}/all/ 
${TMPDIR}/pkgdata/all${TARGET_VENDOR}-${TARGET_OS}"
+# However until do_package is not machine specific, we'll have to make do with 
this:
+SSTATE_DUPWHITELIST = "${DEPLOY_DIR}/ ${TMPDIR}/pkgdata/"
+
 
 SSTATE_SCAN_FILES ?= "*.la *-config *_config"
 SSTATE_SCAN_CMD ?= 'find ${SSTATE_BUILDDIR} \( -name "${@"\" -o -name 
\"".join(d.getVar("SSTATE_SCAN_FILES", True).split())}" \) -type f'



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

Re: [OE-core] [oe-commits] Martin Jansa : xserver-xorg: use EXTENDPKGV instead of PV in RCONFLICTS_${PN}-module-exa

2012-09-27 Thread Mark Hatle

Just an FYI -- Martin Jansa found a problem with the implement of the package 
version comparison.


In deb and ipk, they do not support '<' or '>', instead it's '<<' and '>>'. 
(Odd, historical reasons apparently).


While RPM doesn't have any idea what '<<' or '>>' is.

Talking with RP and others it seems like the best approach is to implement a 
conversion, in the deb and ipk packaging classes, to convert '<' and '>' to the 
'<<' and '>>' equivalents.  As well as add a sanity check that nobody is using 
'<<' or '>>'.


I'm in the process of doing that now.

--Mark

On 9/27/12 1:08 PM, Otavio Salvador wrote:

On Thu, Sep 27, 2012 at 2:55 PM, Martin Jansa  wrote:

On Thu, Sep 27, 2012 at 05:34:19PM +0200, Martin Jansa wrote:

On Thu, Sep 27, 2012 at 02:29:25PM +, g...@git.openembedded.org wrote:

Module: openembedded-core.git
Branch: master
Commit: ed0216d29fc4355c5220f3ad51df04a63cacb0c3
URL:
http://git.openembedded.org/?p=openembedded-core.git&a=commit;h=ed0216d29fc4355c5220f3ad51df04a63cacb0c3

Author: Martin Jansa 
Date:   Sat Sep 22 19:13:14 2012 +0200

xserver-xorg: use EXTENDPKGV instead of PV in RCONFLICTS_${PN}-module-exa

* it doesn't make much sense with PV, because xserver-xorg-module-exa
   was introduced in
   
http://git.openembedded.org/openembedded-core/commit/meta/recipes-graphics/xorg-xserver?id=1a666ee1cda3c0b74daba5881fc5f62e13deec66
   so our xserver-xorg-module-exa RCONFLICTS with xserver-xorg (<= 1.11.2-r4)
   and (< 1.11.2) is not good enough

* because we don't know how many PRINC are in BSP/DISTRO layers,
   then it's safer to RCONFLICTS with every older version then current
   EXTENDPKGV

Also fixes whitespace to work correctly with opkg


The whitespace problem wasn't opkg fault AFAIK, but
bb.utils.explode_dep_versions as shown in
http://patchwork.openembedded.org/patch/37069/


Ah and it was meant to be applied together with this patch, so now it's
missing PR bump..


It keeps failing for me.




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

Re: [OE-core] [oe-commits] Martin Jansa : xserver-xorg: use EXTENDPKGV instead of PV in RCONFLICTS_${PN}-module-exa

2012-09-27 Thread Martin Jansa

On Fri, Sep 28, 2012 at 12:41 AM, Mark Hatle  wrote:
> Just an FYI -- Martin Jansa found a problem with the implement of the
> package version comparison.
>
> In deb and ipk, they do not support '<' or '>', instead it's '<<' and '>>'.
> (Odd, historical reasons apparently).
>
> While RPM doesn't have any idea what '<<' or '>>' is.
>
> Talking with RP and others it seems like the best approach is to implement a
> conversion, in the deb and ipk packaging classes, to convert '<' and '>' to
> the '<<' and '>>' equivalents.  As well as add a sanity check that nobody is
> using '<<' or '>>'.
>
> I'm in the process of doing that now.
>
> --Mark

There is still some problem in opkg, now when I'm testing << with opkg
which should work as LESS (and < as LESS_EQUAL), it still shows <= in
opkg status and behaves like <=. So there is probably some bug in opkg
still hidden :/

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

Re: [OE-core] [PATCH 0/3] license.bbclass fixes

2012-09-27 Thread Flanagan, Elizabeth

On Thu, Sep 27, 2012 at 10:08 AM, Saul Wold  wrote:
> On 09/26/2012 02:50 PM, Elizabeth Flanagan wrote:
>>
>> [YOCTO #3118]
>>
>> license.conf hasn't been being parsed. This commit series ensures that
>> license.conf is parsed, that it contains useful variables that should be
>> in a global conf file and that those variables are not kept within
>> license.bbclass.
>>
> So where is the inherit license bbclass?

For the yocto project it's an INHERIT +=  within poky.conf.
meta-angstrom does not inherit it within
conf/distro/include/angstrom.inc.

-b

>
> Sau!
>
>
>> This also fixes an discreprancy between the documentation of LICENSE_PATH
>> (which
>> is what we tell people to use) and what we were using "LICENSE_DIR". This
>> ensures
>> that when the end user needs to add additional licenses, that they use
>> LICENSE_PATH += "path/to/additional/licenses" and that it works.
>>
>
>> The following changes since commit
>> 0b09e50810162a07ef0aecee91ee32b4a36334a3:
>>
>>busybox: Fix misplaced quote (2012-09-26 18:28:36 +0100)
>>
>> are available in the git repository at:
>>git://git.yoctoproject.org/poky-contrib eflanagan/LICENSE_PATH
>>
>> http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=eflanagan/LICENSE_PATH
>>
>> Elizabeth Flanagan (3):
>>license.bbclass: Variable standardization
>>bitbake.conf: parse license config
>>license.conf/bbclass: Move globals to license.conf
>>
>>   meta/classes/license.bbclass |   67
>> +-
>>   meta/conf/bitbake.conf   |1 +
>>   meta/conf/licenses.conf  |   64
>> 
>>   3 files changed, 66 insertions(+), 66 deletions(-)
>>
>



-- 
Elizabeth Flanagan
Yocto Project
Build and Release

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

Re: [OE-core] [PATCH 0/3] license.bbclass fixes

2012-09-27 Thread Saul Wold


On 09/27/2012 04:50 PM, Flanagan, Elizabeth wrote:

On Thu, Sep 27, 2012 at 10:08 AM, Saul Wold  wrote:

On 09/26/2012 02:50 PM, Elizabeth Flanagan wrote:


[YOCTO #3118]

license.conf hasn't been being parsed. This commit series ensures that
license.conf is parsed, that it contains useful variables that should be
in a global conf file and that those variables are not kept within
license.bbclass.


So where is the inherit license bbclass?


For the yocto project it's an INHERIT +=  within poky.conf.
meta-angstrom does not inherit it within
conf/distro/include/angstrom.inc.

-b


Acked-by: Saul Wold 


Sau!



This also fixes an discreprancy between the documentation of LICENSE_PATH
(which
is what we tell people to use) and what we were using "LICENSE_DIR". This
ensures
that when the end user needs to add additional licenses, that they use
LICENSE_PATH += "path/to/additional/licenses" and that it works.




The following changes since commit
0b09e50810162a07ef0aecee91ee32b4a36334a3:

busybox: Fix misplaced quote (2012-09-26 18:28:36 +0100)

are available in the git repository at:
git://git.yoctoproject.org/poky-contrib eflanagan/LICENSE_PATH

http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=eflanagan/LICENSE_PATH

Elizabeth Flanagan (3):
license.bbclass: Variable standardization
bitbake.conf: parse license config
license.conf/bbclass: Move globals to license.conf

   meta/classes/license.bbclass |   67
+-
   meta/conf/bitbake.conf   |1 +
   meta/conf/licenses.conf  |   64

   3 files changed, 66 insertions(+), 66 deletions(-)









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

[OE-core] [PATCH v2 09/10] binutils.inc: add vardep on multiarch DISTRO_FEATURE

2012-09-27 Thread Matthew McClintock

binutils will build differently if this feature is enabled, so
make the do_configure step depend on it

Signed-off-by: Matthew McClintock 
---
Not sure if we should try to fix via configure options

v2: update commit message a bit

 meta/recipes-devtools/binutils/binutils.inc |2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-devtools/binutils/binutils.inc 
b/meta/recipes-devtools/binutils/binutils.inc
index ee748a4..ff64882 100644
--- a/meta/recipes-devtools/binutils/binutils.inc
+++ b/meta/recipes-devtools/binutils/binutils.inc
@@ -80,6 +80,8 @@ export CC_FOR_BUILD = "LD_LIBRARY_PATH= ${BUILD_CC}"
 export CPP_FOR_BUILD = "${BUILD_CPP}"
 export CFLAGS_FOR_BUILD = "${BUILD_CFLAGS}"
 
+MULTIARCH := "${@bb.utils.contains("DISTRO_FEATURES", "multiarch", "yes", 
"no", d)}"
+do_configure[vardeps] += "MULTIARCH"
 do_configure () {
(cd ${S}; gnu-configize) || die "Failed to run gnu-configize"
oe_runconf
-- 
1.7.9.7



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

[OE-core] [PATCH v2 05/10] arch-powerpc.inc: add altivec as a valid tune feature

2012-09-27 Thread Matthew McClintock

Signed-off-by: Matthew McClintock 
---
v2: no changes

This patch and the others should fix Yocto bug #3072

 meta/conf/machine/include/powerpc/arch-powerpc.inc |2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/conf/machine/include/powerpc/arch-powerpc.inc 
b/meta/conf/machine/include/powerpc/arch-powerpc.inc
index 12909d9..ae81cde 100644
--- a/meta/conf/machine/include/powerpc/arch-powerpc.inc
+++ b/meta/conf/machine/include/powerpc/arch-powerpc.inc
@@ -19,6 +19,8 @@ TUNEVALID[fpu-soft] = "Use software FPU."
 TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "fpu-soft", 
"-msoft-float", "", d)}"
 TARGET_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "fpu-soft", "soft", "", 
d)}"
 
+TUNEVALID[altivec] = "Altivec"
+
 # Basic tune definitions
 AVAILTUNES += "powerpc powerpc-nf" 
 TUNE_FEATURES_tune-powerpc-nf = "m32 fpu-soft"
-- 
1.7.9.7



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

[OE-core] [PATCH v2 04/10] eglibc_2.16.bb: refresh fsl-ppc-no-fsqrt.patch for Freescale targets

2012-09-27 Thread Matthew McClintock

Signed-off-by: Matthew McClintock 
---
v2: refresh for all Freescale targets, and fix mixup between
single and double precision

 .../eglibc/eglibc-2.16/fsl-ppc-no-fsqrt.patch  |   50 ++--
 meta/recipes-core/eglibc/eglibc_2.16.bb|2 +-
 2 files changed, 47 insertions(+), 5 deletions(-)

diff --git a/meta/recipes-core/eglibc/eglibc-2.16/fsl-ppc-no-fsqrt.patch 
b/meta/recipes-core/eglibc/eglibc-2.16/fsl-ppc-no-fsqrt.patch
index 712b353..f619f08 100644
--- a/meta/recipes-core/eglibc/eglibc-2.16/fsl-ppc-no-fsqrt.patch
+++ b/meta/recipes-core/eglibc/eglibc-2.16/fsl-ppc-no-fsqrt.patch
@@ -9,8 +9,8 @@ Upstream-Status: Pending
 
 Index: libc/sysdeps/powerpc/fpu/math_private.h
 ===
 libc.orig/sysdeps/powerpc/fpu/math_private.h   2012-09-03 
22:37:58.0 -0700
-+++ libc/sysdeps/powerpc/fpu/math_private.h2012-09-17 09:35:09.709124003 
-0700
+--- libc.orig/sysdeps/powerpc/fpu/math_private.h
 libc/sysdeps/powerpc/fpu/math_private.h
 @@ -25,10 +25,12 @@
  #include 
  #include_next 
@@ -30,8 +30,50 @@ Index: libc/sysdeps/powerpc/fpu/math_private.h
  extern double __slow_ieee754_sqrt (double);
 Index: libc/ports/sysdeps/powerpc/powerpc64/e5500/fpu/math_private.h
 ===
 /dev/null  1970-01-01 00:00:00.0 +
-+++ libc/ports/sysdeps/powerpc/powerpc64/e5500/fpu/math_private.h  
2012-09-17 09:56:59.129124074 -0700
+--- /dev/null
 libc/ports/sysdeps/powerpc/powerpc64/e5500/fpu/math_private.h
+@@ -0,0 +1,9 @@
++#ifndef _E5500_MATH_PRIVATE_H_
++#define _E5500_MATH_PRIVATE_H_ 1
++/* E5500 core FPU does not implement
++   fsqrt */
++
++#define __CPU_HAS_FSQRT 0
++#include_next 
++
++#endif /* _E5500_MATH_PRIVATE_H_ */
+Index: libc/ports/sysdeps/powerpc/powerpc64/e6500/fpu/math_private.h
+===
+--- /dev/null
 libc/ports/sysdeps/powerpc/powerpc64/e6500/fpu/math_private.h
+@@ -0,0 +1,9 @@
++#ifndef _E6500_MATH_PRIVATE_H_
++#define _E6500_MATH_PRIVATE_H_ 1
++/* E6500 core FPU does not implement
++   fsqrt */
++
++#define __CPU_HAS_FSQRT 0
++#include_next 
++
++#endif /* _E6500_MATH_PRIVATE_H_ */
+Index: libc/ports/sysdeps/powerpc/powerpc32/e500mc/fpu/math_private.h
+===
+--- /dev/null
 libc/ports/sysdeps/powerpc/powerpc32/e500mc/fpu/math_private.h
+@@ -0,0 +1,9 @@
++#ifndef _E500MC_MATH_PRIVATE_H_
++#define _E500MC_MATH_PRIVATE_H_ 1
++/* E500MC core FPU does not implement
++   fsqrt */
++
++#define __CPU_HAS_FSQRT 0
++#include_next 
++
++#endif /* _E500MC_MATH_PRIVATE_H_ */
+Index: libc/ports/sysdeps/powerpc/powerpc32/e5500/fpu/math_private.h
+===
+--- /dev/null
 libc/ports/sysdeps/powerpc/powerpc32/e5500/fpu/math_private.h
 @@ -0,0 +1,9 @@
 +#ifndef _E5500_MATH_PRIVATE_H_
 +#define _E5500_MATH_PRIVATE_H_ 1
diff --git a/meta/recipes-core/eglibc/eglibc_2.16.bb 
b/meta/recipes-core/eglibc/eglibc_2.16.bb
index 5d88831..a0824cd 100644
--- a/meta/recipes-core/eglibc/eglibc_2.16.bb
+++ b/meta/recipes-core/eglibc/eglibc_2.16.bb
@@ -3,7 +3,7 @@ require eglibc.inc
 SRCREV = "20393"
 
 DEPENDS += "gperf-native kconfig-frontends-native"
-PR = "r13"
+PR = "r14"
 PR_append = "+svnr${SRCPV}"
 
 EGLIBC_BRANCH="eglibc-2_16"
-- 
1.7.9.7



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

[OE-core] [PATCH v2 08/10] insane.bbclass: skip checking arch (machine/bits) for powerpc kernel recipe

2012-09-27 Thread Matthew McClintock

For a 32-bit machine, we still might always (or optionally) want to build a
64-bit kernel so we add an exception.

Signed-off-by: Matthew McClintock 
---
Not sure if we should just skip for all virtual/kernel's?

Should we use some variable for this instead?
-BUILD_64BIT_KERNEL? PROMOTE_TO_64BIT_KERNEL?

 meta/classes/insane.bbclass |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 1fb8970..173b71f 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -402,11 +402,13 @@ def package_qa_check_arch(path,name,d, elf, messages):
 
 # Check the architecture and endiannes of the binary
 if not ((machine == elf.machine()) or \
-   ("virtual/kernel" in provides) and (target_os == "linux-gnux32")):
+   ("virtual/kernel" in provides) and (target_os == "linux-gnux32") or \
+   ("virtual/kernel" in provides) and (target_arch == "powerpc")):
 messages.append("Architecture did not match (%d to %d) on %s" % \
  (machine, elf.machine(), package_qa_clean_path(path,d)))
 elif not ((bits == elf.abiSize()) or  \
-   ("virtual/kernel" in provides) and (target_os == "linux-gnux32")):
+   ("virtual/kernel" in provides) and (target_os == "linux-gnux32") or \
+   ("virtual/kernel" in provides) and (target_arch == "powerpc")):
 messages.append("Bit size did not match (%d to %d) %s on %s" % \
  (bits, elf.abiSize(), bpn, package_qa_clean_path(path,d)))
 elif not littleendian == elf.isLittleEndian():
-- 
1.7.9.7



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

[OE-core] [PATCH v2 07/10] flac_1.2.1.bb: use TUNE_FEATURES to enable/disable altivec

2012-09-27 Thread Matthew McClintock

Signed-off-by: Matthew McClintock 
---
v2: no changes

 meta/recipes-multimedia/flac/flac_1.2.1.bb |6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-multimedia/flac/flac_1.2.1.bb 
b/meta/recipes-multimedia/flac/flac_1.2.1.bb
index 157128f..6520b71 100644
--- a/meta/recipes-multimedia/flac/flac_1.2.1.bb
+++ b/meta/recipes-multimedia/flac/flac_1.2.1.bb
@@ -36,10 +36,8 @@ EXTRA_OECONF = "--disable-oggtest --disable-id3libtest \
 --without-xmms-exec-prefix \
 --without-libiconv-prefix \
 --without-id3lib"
-EXTRA_OECONF_prepend_e500mc = "--disable-altivec "
-EXTRA_OECONF_prepend_e5500 = "--disable-altivec "
-EXTRA_OECONF_prepend_e5500-64b = "--disable-altivec "
-EXTRA_OECONF_prepend_mpc8315e-rdb = "--disable-altivec "
+
+EXTRA_OECONF += "${@bb.utils.contains("TUNE_FEATURES", "altivec", " 
--enable-altivec", " --disable-altivec", d)}"
 
 PACKAGES += "libflac libflac++ liboggflac liboggflac++"
 FILES_${PN} = "${bindir}/*"
-- 
1.7.9.7



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

[OE-core] [PATCH v2 03/10] eglibc_2.16.bb: refresh ppc_slow_ieee754_sqrt.patch for Freescale targets

2012-09-27 Thread Matthew McClintock

Make same changes for e6500 fpu as done with others

Signed-off-by: Matthew McClintock 
---
v2: refresh patch for other new arches that were added by the previous commit
which was causing new build errors

 .../eglibc/eglibc-2.16/ppc_slow_ieee754_sqrt.patch |  278 ++--
 meta/recipes-core/eglibc/eglibc_2.16.bb|2 +-
 2 files changed, 261 insertions(+), 19 deletions(-)

diff --git a/meta/recipes-core/eglibc/eglibc-2.16/ppc_slow_ieee754_sqrt.patch 
b/meta/recipes-core/eglibc/eglibc-2.16/ppc_slow_ieee754_sqrt.patch
index 9a932ff..60532cb 100644
--- a/meta/recipes-core/eglibc/eglibc-2.16/ppc_slow_ieee754_sqrt.patch
+++ b/meta/recipes-core/eglibc/eglibc-2.16/ppc_slow_ieee754_sqrt.patch
@@ -5,9 +5,9 @@ Signed-off-by: Khem Raj 
 Upstream-Status: Pending
 Index: libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrt.c
 ===
 libc.orig/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrt.c  2012-07-03 
22:36:01.172386436 -0700
-+++ libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrt.c   2012-07-03 
23:04:37.396469515 -0700
-@@ -40,7 +40,7 @@
+--- libc.orig/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrt.c
 libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrt.c
+@@ -40,7 +40,7 @@ static const float half = 0.5;
 simultaneously.  */
  
  double
@@ -16,7 +16,7 @@ Index: libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrt.c
  {
if (__builtin_expect (b > 0, 1))
  {
-@@ -77,7 +77,7 @@
+@@ -77,7 +77,7 @@ __ieee754_sqrt (double b)

/* Handle small numbers by scaling.  */
if (__builtin_expect ((u.parts.msw & 0x7ff0) <= 0x0200, 0))
@@ -25,7 +25,7 @@ Index: libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrt.c
  
  #define FMADD(a_, c_, b_)   \
({ double __r;\
-@@ -126,4 +126,12 @@
+@@ -126,4 +126,12 @@ __ieee754_sqrt (double b)
  }
return f_wash (b);
  }
@@ -40,9 +40,9 @@ Index: libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrt.c
  strong_alias (__ieee754_sqrt, __sqrt_finite)
 Index: libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrtf.c
 ===
 libc.orig/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrtf.c 2012-07-03 
22:36:01.172386436 -0700
-+++ libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrtf.c  2012-07-03 
23:07:06.260476775 -0700
-@@ -38,7 +38,7 @@
+--- libc.orig/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrtf.c
 libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrtf.c
+@@ -38,7 +38,7 @@ static const float threehalf = 1.5;
 square root.  */
  
  float
@@ -51,7 +51,7 @@ Index: libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrtf.c
  {
if (__builtin_expect (b > 0, 1))
  {
-@@ -93,4 +93,10 @@
+@@ -93,4 +93,10 @@ __ieee754_sqrtf (float b)
  }
return f_washf (b);
  }
@@ -64,9 +64,9 @@ Index: libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrtf.c
  strong_alias (__ieee754_sqrtf, __sqrtf_finite)
 Index: libc/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrt.c
 ===
 libc.orig/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrt.c 2012-07-03 
22:36:01.176386435 -0700
-+++ libc/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrt.c  2012-07-03 
23:14:16.328497458 -0700
-@@ -40,7 +40,7 @@
+--- libc.orig/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrt.c
 libc/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrt.c
+@@ -40,7 +40,7 @@ static const float half = 0.5;
 simultaneously.  */
  
  double
@@ -75,7 +75,7 @@ Index: libc/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrt.c
  {
if (__builtin_expect (b > 0, 1))
  {
-@@ -77,7 +77,7 @@
+@@ -77,7 +77,7 @@ __ieee754_sqrt (double b)

/* Handle small numbers by scaling.  */
if (__builtin_expect ((u.parts.msw & 0x7ff0) <= 0x0200, 0))
@@ -84,7 +84,7 @@ Index: libc/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrt.c
  
  #define FMADD(a_, c_, b_)   \
({ double __r;\
-@@ -126,4 +126,12 @@
+@@ -126,4 +126,12 @@ __ieee754_sqrt (double b)
  }
return f_wash (b);
  }
@@ -99,9 +99,9 @@ Index: libc/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrt.c
  strong_alias (__ieee754_sqrt, __sqrt_finite)
 Index: libc/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrtf.c
 ===
 libc.orig/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrtf.c2012-07-03 
22:36:01.176386435 -0700
-+++ libc/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrtf.c 2012-07-03 
23:13:52.732496373 -0700
-@@ -38,7 +38,7 @@
+--- libc.orig/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrtf.c
 libc/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrtf.c
+@@ -38,7 +38,7 @@ static const float threehalf = 1.5;
 square root.  */
  
  float
@@ -110,7 +110,7 @@ Index: libc/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrtf.c
  {
if (__builtin_expect (b > 0, 1))
  {

[OE-core] [PATCH v2 06/10] tune-ppce6500.inc: add e6500 tune files

2012-09-27 Thread Matthew McClintock

Also supports a new altivec TUNE_FEATURE

Signed-off-by: Matthew McClintock 
---
v2: no changes

 meta/conf/machine/include/tune-ppce6500.inc |   21 +
 1 file changed, 21 insertions(+)
 create mode 100644 meta/conf/machine/include/tune-ppce6500.inc

diff --git a/meta/conf/machine/include/tune-ppce6500.inc 
b/meta/conf/machine/include/tune-ppce6500.inc
new file mode 100644
index 000..982a7a4
--- /dev/null
+++ b/meta/conf/machine/include/tune-ppce6500.inc
@@ -0,0 +1,21 @@
+DEFAULTTUNE ?= "ppce6500"
+
+require conf/machine/include/powerpc/arch-powerpc64.inc
+
+TUNEVALID[e6500] = "Enable Freescale e6500 specific processor optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "e6500", "-mcpu=e6500", 
"", d)}"
+
+AVAILTUNES += "ppce6500 ppc64e6500"
+TUNE_FEATURES_tune-ppce6500 = "m32 fpu-hard e6500 altivec"
+BASE_LIB_tune-ppce6500 = "lib"
+TUNE_PKGARCH_tune-ppce6500 = "ppce6500"
+PACKAGE_EXTRA_ARCHS_tune-ppce6500 = "${PACKAGE_EXTRA_ARCHS_tune-powerpc} 
ppce6500"
+
+TUNE_FEATURES_tune-ppc64e6500 = "m64 fpu-hard e6500 altivec"
+BASE_LIB_tune-ppc64e6500 = "lib64"
+TUNE_PKGARCH_tune-ppc64e6500 = "ppc64e6500"
+PACKAGE_EXTRA_ARCHS_tune-ppc64e6500 = "${PACKAGE_EXTRA_ARCHS_tune-powerpc64} 
ppc64e6500"
+
+# glibc configure options to get e6500 specific library
+GLIBC_EXTRA_OECONF_powerpc64 += "${@bb.utils.contains("TUNE_FEATURES", 
"e6500", "--with-cpu=e6500", "", d)}"
+GLIBC_EXTRA_OECONF_powerpc += "${@bb.utils.contains("TUNE_FEATURES", "e6500", 
"--with-cpu=603e", "", d)}"
-- 
1.7.9.7



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

[OE-core] [PATCH v2 10/10] libx11.inc: fix build issues for older CentOS distros

2012-09-27 Thread Matthew McClintock

Fixes these sorts of issues present on older gcc (CentOS 5.x in this case)

| cc1: error: unrecognized command line option "-Werror=implicit"
| cc1: error: unrecognized command line option "-Werror=nonnull"
| cc1: error: unrecognized command line option "-Werror=init-self"
| cc1: error: unrecognized command line option "-Werror=main"
| cc1: error: unrecognized command line option "-Werror=missing-braces"
| cc1: error: unrecognized command line option "-Werror=sequence-point"
| cc1: error: unrecognized command line option "-Werror=return-type"
| cc1: error: unrecognized command line option "-Werror=trigraphs"
| cc1: error: unrecognized command line option "-Werror=array-bounds"
| cc1: error: unrecognized command line option "-Werror=write-strings"
| cc1: error: unrecognized command line option "-Werror=address"
| cc1: error: unrecognized command line option "-Werror=int-to-pointer-cast"
| cc1: error: unrecognized command line option "-Werror=pointer-to-int-cast"

Also fixes:

makekeys-makekeys.o: In function `main':
makekeys.c:(.text+0x85): undefined reference to `__isoc99_sscanf'
makekeys.c:(.text+0xa7): undefined reference to `__isoc99_sscanf'
collect2: ld returned 1 exit status
make: *** [makekeys] Error 1

Older libc do not have this defined, we can use the -D_GNU_SOURCE
to the compiler to prevent generating calls to this function and
make linking work

Signed-off-by: Matthew McClintock 
---
This replaces the previous patch series that fixes libx11 issues

 meta/recipes-graphics/xorg-lib/libx11.inc |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-graphics/xorg-lib/libx11.inc 
b/meta/recipes-graphics/xorg-lib/libx11.inc
index 3ecd9e5..97bd1c2 100644
--- a/meta/recipes-graphics/xorg-lib/libx11.inc
+++ b/meta/recipes-graphics/xorg-lib/libx11.inc
@@ -11,7 +11,7 @@ inherit siteinfo
 FILESPATH = "${FILE_DIRNAME}/libx11"
 
 PE = "1"
-INC_PR = "r8"
+INC_PR = "r9"
 
 PROVIDES = "virtual/libx11"
 
@@ -23,6 +23,7 @@ DEPENDS += "xproto xextproto xtrans libxcb kbproto inputproto"
 DEPENDS += "xproto-native"
 
 EXTRA_OECONF += "--with-keysymdefdir=${STAGING_INCDIR}/X11/"
+EXTRA_OEMAKE += 'CWARNFLAGS=""'
 
 # Let people with incredibly archaic requirements enable Xcms and BigFont, but
 # disable them by default.
@@ -33,7 +34,7 @@ PACKAGECONFIG[bigfont] = 
"--enable-xf86bigfont,--disable-xf86bigfont,xf86bigfont
 # src/util/makekeys needs to be compiled natively, so tell it what compiler to
 # use.
 export CC_FOR_BUILD = "${BUILD_CC}"
-export CFLAGS_FOR_BUILD = "${BUILD_CFLAGS}"
+export CFLAGS_FOR_BUILD = "${BUILD_CFLAGS} -D_GNU_SOURCE"
 export CPPFLAGS_FOR_BUILD = "${BUILD_CPPFLAGS}"
 export LDFLAGS_FOR_BUILD = "${BUILD_LDFLAGS}"
 
-- 
1.7.9.7



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

[OE-core] [PATCH v2 02/10] eglibc_2.16.bb: refresh ppc-sqrt_finite.patch for Freescale targets

2012-09-27 Thread Matthew McClintock

Signed-off-by: Matthew McClintock 
---
v2: add the current changes for the new arches here as well

 .../eglibc/eglibc-2.16/ppc-sqrt_finite.patch   |  104 +---
 meta/recipes-core/eglibc/eglibc_2.16.bb|2 +-
 2 files changed, 89 insertions(+), 17 deletions(-)

diff --git a/meta/recipes-core/eglibc/eglibc-2.16/ppc-sqrt_finite.patch 
b/meta/recipes-core/eglibc/eglibc-2.16/ppc-sqrt_finite.patch
index 5289051..6ea666b 100644
--- a/meta/recipes-core/eglibc/eglibc-2.16/ppc-sqrt_finite.patch
+++ b/meta/recipes-core/eglibc/eglibc-2.16/ppc-sqrt_finite.patch
@@ -16,9 +16,9 @@ ChangeLog
  
 Index: libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrt.c
 ===
 libc.orig/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrt.c  2012-01-06 
18:07:42.296909187 -0800
-+++ libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrt.c   2012-01-06 
18:09:22.572914856 -0800
-@@ -39,14 +39,8 @@
+--- libc.orig/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrt.c
 libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrt.c
+@@ -39,14 +39,8 @@ static const float half = 0.5;
 We find the actual square root and half of its reciprocal
 simultaneously.  */
  
@@ -33,16 +33,16 @@ Index: libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrt.c
  {
if (__builtin_expect (b > 0, 1))
  {
-@@ -132,3 +126,4 @@
+@@ -132,3 +126,4 @@ __ieee754_sqrt (b)
  }
return f_wash (b);
  }
 +strong_alias (__ieee754_sqrt, __sqrt_finite)
 Index: libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrtf.c
 ===
 libc.orig/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrtf.c 2012-01-06 
18:10:37.068917644 -0800
-+++ libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrtf.c  2012-01-06 
18:11:33.408920635 -0800
-@@ -37,14 +37,8 @@
+--- libc.orig/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrtf.c
 libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrtf.c
+@@ -37,14 +37,8 @@ static const float threehalf = 1.5;
 We find the reciprocal square root and use that to compute the actual
 square root.  */
  
@@ -57,16 +57,16 @@ Index: libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrtf.c
  {
if (__builtin_expect (b > 0, 1))
  {
-@@ -99,3 +93,4 @@
+@@ -99,3 +93,4 @@ __ieee754_sqrtf (b)
  }
return f_washf (b);
  }
 +strong_alias (__ieee754_sqrtf, __sqrtf_finite)
 Index: libc/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrt.c
 ===
 libc.orig/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrt.c 2012-01-06 
18:11:51.460925644 -0800
-+++ libc/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrt.c  2012-01-06 
18:12:39.344924405 -0800
-@@ -39,14 +39,8 @@
+--- libc.orig/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrt.c
 libc/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrt.c
+@@ -39,14 +39,8 @@ static const float half = 0.5;
 We find the actual square root and half of its reciprocal
 simultaneously.  */
  
@@ -81,16 +81,16 @@ Index: libc/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrt.c
  {
if (__builtin_expect (b > 0, 1))
  {
-@@ -132,3 +126,4 @@
+@@ -132,3 +126,4 @@ __ieee754_sqrt (b)
  }
return f_wash (b);
  }
 +strong_alias (__ieee754_sqrt, __sqrt_finite)
 Index: libc/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrtf.c
 ===
 libc.orig/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrtf.c2012-01-06 
18:13:00.892924586 -0800
-+++ libc/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrtf.c 2012-01-06 
18:15:27.992931106 -0800
-@@ -37,14 +37,8 @@
+--- libc.orig/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrtf.c
 libc/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrtf.c
+@@ -37,14 +37,8 @@ static const float threehalf = 1.5;
 We find the reciprocal square root and use that to compute the actual
 square root.  */
  
@@ -105,7 +105,79 @@ Index: libc/sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrtf.c
  {
if (__builtin_expect (b > 0, 1))
  {
-@@ -99,3 +93,4 @@
+@@ -99,3 +93,4 @@ __ieee754_sqrtf (b)
+ }
+   return f_washf (b);
+ }
++strong_alias (__ieee754_sqrtf, __sqrtf_finite)
+Index: libc/sysdeps/powerpc/powerpc32/e500mc/fpu/e_sqrt.c
+===
+--- libc.orig/sysdeps/powerpc/powerpc32/e500mc/fpu/e_sqrt.c
 libc/sysdeps/powerpc/powerpc32/e500mc/fpu/e_sqrt.c
+@@ -132,3 +132,4 @@ __ieee754_sqrt (b)
+ }
+   return f_wash (b);
+ }
++strong_alias (__ieee754_sqrt, __sqrt_finite)
+Index: libc/sysdeps/powerpc/powerpc32/e500mc/fpu/e_sqrtf.c
+===
+--- libc.orig/sysdeps/powerpc/powerpc32/e500mc/fpu/e_sqrtf.c
 libc/sysdeps/powerpc/powerpc32/e500mc/fpu/e_sqrtf.c
+@@ -99,3 +99,4 @@ __ieee754_sqrtf (b)
+ }
+   return f_washf (b);
+ }
++strong_alias (__ieee754_sqrtf, __sqrtf_finite)
+Index: libc/sysdeps/powerpc/powerpc32/e5500/fpu/e_sqrt.c
+===
+--- libc.orig/s

[OE-core] [PATCH v2 04/10] eglibc_2.16.bb: refresh fsl-ppc-no-fsqrt.patch for Freescale targets

2012-09-27 Thread Matthew McClintock

Signed-off-by: Matthew McClintock 
---
v2: refresh for all Freescale targets, and fix mixup between
single and double precision
v3: add 32-bit e6500 which was missed

 .../eglibc/eglibc-2.16/fsl-ppc-no-fsqrt.patch  |   68 ++--
 meta/recipes-core/eglibc/eglibc_2.16.bb|2 +-
 2 files changed, 65 insertions(+), 5 deletions(-)

diff --git a/meta/recipes-core/eglibc/eglibc-2.16/fsl-ppc-no-fsqrt.patch 
b/meta/recipes-core/eglibc/eglibc-2.16/fsl-ppc-no-fsqrt.patch
index 712b353..89a330f 100644
--- a/meta/recipes-core/eglibc/eglibc-2.16/fsl-ppc-no-fsqrt.patch
+++ b/meta/recipes-core/eglibc/eglibc-2.16/fsl-ppc-no-fsqrt.patch
@@ -9,8 +9,8 @@ Upstream-Status: Pending
 
 Index: libc/sysdeps/powerpc/fpu/math_private.h
 ===
 libc.orig/sysdeps/powerpc/fpu/math_private.h   2012-09-03 
22:37:58.0 -0700
-+++ libc/sysdeps/powerpc/fpu/math_private.h2012-09-17 09:35:09.709124003 
-0700
+--- libc.orig/sysdeps/powerpc/fpu/math_private.h
 libc/sysdeps/powerpc/fpu/math_private.h
 @@ -25,10 +25,12 @@
  #include 
  #include_next 
@@ -30,8 +30,8 @@ Index: libc/sysdeps/powerpc/fpu/math_private.h
  extern double __slow_ieee754_sqrt (double);
 Index: libc/ports/sysdeps/powerpc/powerpc64/e5500/fpu/math_private.h
 ===
 /dev/null  1970-01-01 00:00:00.0 +
-+++ libc/ports/sysdeps/powerpc/powerpc64/e5500/fpu/math_private.h  
2012-09-17 09:56:59.129124074 -0700
+--- /dev/null
 libc/ports/sysdeps/powerpc/powerpc64/e5500/fpu/math_private.h
 @@ -0,0 +1,9 @@
 +#ifndef _E5500_MATH_PRIVATE_H_
 +#define _E5500_MATH_PRIVATE_H_ 1
@@ -42,3 +42,63 @@ Index: 
libc/ports/sysdeps/powerpc/powerpc64/e5500/fpu/math_private.h
 +#include_next 
 +
 +#endif /* _E5500_MATH_PRIVATE_H_ */
+Index: libc/ports/sysdeps/powerpc/powerpc64/e6500/fpu/math_private.h
+===
+--- /dev/null
 libc/ports/sysdeps/powerpc/powerpc64/e6500/fpu/math_private.h
+@@ -0,0 +1,9 @@
++#ifndef _E6500_MATH_PRIVATE_H_
++#define _E6500_MATH_PRIVATE_H_ 1
++/* E6500 core FPU does not implement
++   fsqrt */
++
++#define __CPU_HAS_FSQRT 0
++#include_next 
++
++#endif /* _E6500_MATH_PRIVATE_H_ */
+Index: libc/ports/sysdeps/powerpc/powerpc32/e500mc/fpu/math_private.h
+===
+--- /dev/null
 libc/ports/sysdeps/powerpc/powerpc32/e500mc/fpu/math_private.h
+@@ -0,0 +1,9 @@
++#ifndef _E500MC_MATH_PRIVATE_H_
++#define _E500MC_MATH_PRIVATE_H_ 1
++/* E500MC core FPU does not implement
++   fsqrt */
++
++#define __CPU_HAS_FSQRT 0
++#include_next 
++
++#endif /* _E500MC_MATH_PRIVATE_H_ */
+Index: libc/ports/sysdeps/powerpc/powerpc32/e5500/fpu/math_private.h
+===
+--- /dev/null
 libc/ports/sysdeps/powerpc/powerpc32/e5500/fpu/math_private.h
+@@ -0,0 +1,9 @@
++#ifndef _E5500_MATH_PRIVATE_H_
++#define _E5500_MATH_PRIVATE_H_ 1
++/* E5500 core FPU does not implement
++   fsqrt */
++
++#define __CPU_HAS_FSQRT 0
++#include_next 
++
++#endif /* _E5500_MATH_PRIVATE_H_ */
+Index: libc/ports/sysdeps/powerpc/powerpc32/e6500/fpu/math_private.h
+===
+--- libc.orig/ports/sysdeps/powerpc/powerpc32/e6500/fpu/math_private.h
 libc/ports/sysdeps/powerpc/powerpc32/e6500/fpu/math_private.h
+@@ -1,9 +1,9 @@
+-#ifndef _E5500_MATH_PRIVATE_H_
+-#define _E5500_MATH_PRIVATE_H_ 1
+-/* E5500 core FPU does not implement
++#ifndef _E6500_MATH_PRIVATE_H_
++#define _E6500_MATH_PRIVATE_H_ 1
++/* E6500 core FPU does not implement
+fsqrt */
+ 
+ #define __CPU_HAS_FSQRT 0
+ #include_next 
+ 
+-#endif /* _E5500_MATH_PRIVATE_H_ */
++#endif /* _E6500_MATH_PRIVATE_H_ */
diff --git a/meta/recipes-core/eglibc/eglibc_2.16.bb 
b/meta/recipes-core/eglibc/eglibc_2.16.bb
index 5d88831..a0824cd 100644
--- a/meta/recipes-core/eglibc/eglibc_2.16.bb
+++ b/meta/recipes-core/eglibc/eglibc_2.16.bb
@@ -3,7 +3,7 @@ require eglibc.inc
 SRCREV = "20393"
 
 DEPENDS += "gperf-native kconfig-frontends-native"
-PR = "r13"
+PR = "r14"
 PR_append = "+svnr${SRCPV}"
 
 EGLIBC_BRANCH="eglibc-2_16"
-- 
1.7.9.7



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

[OE-core] perl install error

2012-09-27 Thread Khem Raj

Hi

On ppc64 I am getting 

| Warning: perl appears in your path in the following locations beyond where
| we just installed it:
| /work/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/bin/perl-native/perl
|
| make[1]: Nothing to be done for `install.man'.
| make[1]: Leaving directory 
`/work/yocto/poky/build/tmp/work/ppc64e5500-poky-linux/perl-5.14.2-r10/perl-5.14.2'
| ln: failed to create symbolic link 
`/work/yocto/poky/build/tmp/work/ppc64e5500-poky-linux/perl-5.14.2-r10/image//usr/lib64/perl5':
 No such file or directory
| ERROR: Function failed: do_install (see 
/work/yocto/poky/build/tmp/work/ppc64e5500-poky-linux/perl-5.14.2-r10/temp/log.do_install.6656
 for further information)
ERROR: Task 1679 (/work/yocto/poky/meta/recipes-devtools/perl/perl_5.14.2.bb, 
do_install) failed with exit code '1'
NOTE: Tasks Summary: Attempted 4082 tasks of which 4057 didn't need to be rerun 
and 1 failed.


It was working fine yesterday
anyone else seeing it ?
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] perl install error

2012-09-27 Thread Khem Raj


On Sep 27, 2012, at 8:22 PM, Khem Raj  wrote:

> Hi
> 
> On ppc64 I am getting 
> 
> | Warning: perl appears in your path in the following locations beyond where
> | we just installed it:
> | 
> /work/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/bin/perl-native/perl
> |
> | make[1]: Nothing to be done for `install.man'.
> | make[1]: Leaving directory 
> `/work/yocto/poky/build/tmp/work/ppc64e5500-poky-linux/perl-5.14.2-r10/perl-5.14.2'
> | ln: failed to create symbolic link 
> `/work/yocto/poky/build/tmp/work/ppc64e5500-poky-linux/perl-5.14.2-r10/image//usr/lib64/perl5':
>  No such file or directory
> | ERROR: Function failed: do_install (see 
> /work/yocto/poky/build/tmp/work/ppc64e5500-poky-linux/perl-5.14.2-r10/temp/log.do_install.6656
>  for further information)
> ERROR: Task 1679 (/work/yocto/poky/meta/recipes-devtools/perl/perl_5.14.2.bb, 
> do_install) failed with exit code '1'
> NOTE: Tasks Summary: Attempted 4082 tasks of which 4057 didn't need to be 
> rerun and 1 failed.
> 
> 
> It was working fine yesterday
> anyone else seeing it ?


If I revert 

perl: Fix nativesdk install path
Commit 38234f2e276356b1d77a87ceabc486107e336d19 tried to fix the sed
expressions by anchoring the left side of the search regexp to prevent
$prefix$prefix type expression in the perl config. For nativesdk this is
not enough. Adding anchors on both side fixes this.

Signed-off-by: Christian Glindkamp 
Signed-off-by: Richard Purdie 



It works again

Thanks
-Khem



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

[OE-core] [PATCH v2 04/10] eglibc_2.16.bb: refresh fsl-ppc-no-fsqrt.patch for Freescale targets

2012-09-27 Thread Matthew McClintock

Signed-off-by: Matthew McClintock 
---
v2: refresh for all Freescale targets, and fix mixup between
single and double precision
v3: add 32-bit e6500 which was missed
v4: Screwed up the patch, fixed in v4

All these patches are on my tree in poky-contrib:
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mattsm/master

 .../eglibc/eglibc-2.16/fsl-ppc-no-fsqrt.patch  |   64 ++--
 meta/recipes-core/eglibc/eglibc_2.16.bb|2 +-
 2 files changed, 61 insertions(+), 5 deletions(-)

diff --git a/meta/recipes-core/eglibc/eglibc-2.16/fsl-ppc-no-fsqrt.patch 
b/meta/recipes-core/eglibc/eglibc-2.16/fsl-ppc-no-fsqrt.patch
index 712b353..511ee9d 100644
--- a/meta/recipes-core/eglibc/eglibc-2.16/fsl-ppc-no-fsqrt.patch
+++ b/meta/recipes-core/eglibc/eglibc-2.16/fsl-ppc-no-fsqrt.patch
@@ -9,8 +9,8 @@ Upstream-Status: Pending
 
 Index: libc/sysdeps/powerpc/fpu/math_private.h
 ===
 libc.orig/sysdeps/powerpc/fpu/math_private.h   2012-09-03 
22:37:58.0 -0700
-+++ libc/sysdeps/powerpc/fpu/math_private.h2012-09-17 09:35:09.709124003 
-0700
+--- libc.orig/sysdeps/powerpc/fpu/math_private.h
 libc/sysdeps/powerpc/fpu/math_private.h
 @@ -25,10 +25,12 @@
  #include 
  #include_next 
@@ -30,8 +30,8 @@ Index: libc/sysdeps/powerpc/fpu/math_private.h
  extern double __slow_ieee754_sqrt (double);
 Index: libc/ports/sysdeps/powerpc/powerpc64/e5500/fpu/math_private.h
 ===
 /dev/null  1970-01-01 00:00:00.0 +
-+++ libc/ports/sysdeps/powerpc/powerpc64/e5500/fpu/math_private.h  
2012-09-17 09:56:59.129124074 -0700
+--- /dev/null
 libc/ports/sysdeps/powerpc/powerpc64/e5500/fpu/math_private.h
 @@ -0,0 +1,9 @@
 +#ifndef _E5500_MATH_PRIVATE_H_
 +#define _E5500_MATH_PRIVATE_H_ 1
@@ -42,3 +42,59 @@ Index: 
libc/ports/sysdeps/powerpc/powerpc64/e5500/fpu/math_private.h
 +#include_next 
 +
 +#endif /* _E5500_MATH_PRIVATE_H_ */
+Index: libc/ports/sysdeps/powerpc/powerpc64/e6500/fpu/math_private.h
+===
+--- /dev/null
 libc/ports/sysdeps/powerpc/powerpc64/e6500/fpu/math_private.h
+@@ -0,0 +1,9 @@
++#ifndef _E6500_MATH_PRIVATE_H_
++#define _E6500_MATH_PRIVATE_H_ 1
++/* E6500 core FPU does not implement
++   fsqrt */
++
++#define __CPU_HAS_FSQRT 0
++#include_next 
++
++#endif /* _E6500_MATH_PRIVATE_H_ */
+Index: libc/ports/sysdeps/powerpc/powerpc32/e500mc/fpu/math_private.h
+===
+--- /dev/null
 libc/ports/sysdeps/powerpc/powerpc32/e500mc/fpu/math_private.h
+@@ -0,0 +1,9 @@
++#ifndef _E500MC_MATH_PRIVATE_H_
++#define _E500MC_MATH_PRIVATE_H_ 1
++/* E500MC core FPU does not implement
++   fsqrt */
++
++#define __CPU_HAS_FSQRT 0
++#include_next 
++
++#endif /* _E500MC_MATH_PRIVATE_H_ */
+Index: libc/ports/sysdeps/powerpc/powerpc32/e5500/fpu/math_private.h
+===
+--- /dev/null
 libc/ports/sysdeps/powerpc/powerpc32/e5500/fpu/math_private.h
+@@ -0,0 +1,9 @@
++#ifndef _E5500_MATH_PRIVATE_H_
++#define _E5500_MATH_PRIVATE_H_ 1
++/* E5500 core FPU does not implement
++   fsqrt */
++
++#define __CPU_HAS_FSQRT 0
++#include_next 
++
++#endif /* _E5500_MATH_PRIVATE_H_ */
+Index: libc/ports/sysdeps/powerpc/powerpc32/e6500/fpu/math_private.h
+===
+--- /dev/null
 libc/ports/sysdeps/powerpc/powerpc32/e6500/fpu/math_private.h
+@@ -0,0 +1,9 @@
++#ifndef _E6500_MATH_PRIVATE_H_
++#define _E6500_MATH_PRIVATE_H_ 1
++/* E6500 core FPU does not implement
++   fsqrt */
++
++#define __CPU_HAS_FSQRT 0
++#include_next 
++
++#endif /* _E6500_MATH_PRIVATE_H_ */
diff --git a/meta/recipes-core/eglibc/eglibc_2.16.bb 
b/meta/recipes-core/eglibc/eglibc_2.16.bb
index 5d88831..a0824cd 100644
--- a/meta/recipes-core/eglibc/eglibc_2.16.bb
+++ b/meta/recipes-core/eglibc/eglibc_2.16.bb
@@ -3,7 +3,7 @@ require eglibc.inc
 SRCREV = "20393"
 
 DEPENDS += "gperf-native kconfig-frontends-native"
-PR = "r13"
+PR = "r14"
 PR_append = "+svnr${SRCPV}"
 
 EGLIBC_BRANCH="eglibc-2_16"
-- 
1.7.9.7



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

Re: [OE-core] perl install error

2012-09-27 Thread McClintock Matthew-B29882

Khem,

I'm just not looking at a similiar issue. Do this:

cat tmp/sstate-control/manifest-* | grep usr/lib/perl5

And see which recipe is making this folder. It should be the perl
recipe, first not some other recipe...

Side question are you using FSL layers?

-M

On Thu, Sep 27, 2012 at 10:28 PM, Khem Raj  wrote:
>
> On Sep 27, 2012, at 8:22 PM, Khem Raj  wrote:
>
>> Hi
>>
>> On ppc64 I am getting
>>
>> | Warning: perl appears in your path in the following locations beyond where
>> | we just installed it:
>> | 
>> /work/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/bin/perl-native/perl
>> |
>> | make[1]: Nothing to be done for `install.man'.
>> | make[1]: Leaving directory 
>> `/work/yocto/poky/build/tmp/work/ppc64e5500-poky-linux/perl-5.14.2-r10/perl-5.14.2'
>> | ln: failed to create symbolic link 
>> `/work/yocto/poky/build/tmp/work/ppc64e5500-poky-linux/perl-5.14.2-r10/image//usr/lib64/perl5':
>>  No such file or directory
>> | ERROR: Function failed: do_install (see 
>> /work/yocto/poky/build/tmp/work/ppc64e5500-poky-linux/perl-5.14.2-r10/temp/log.do_install.6656
>>  for further information)
>> ERROR: Task 1679 
>> (/work/yocto/poky/meta/recipes-devtools/perl/perl_5.14.2.bb, do_install) 
>> failed with exit code '1'
>> NOTE: Tasks Summary: Attempted 4082 tasks of which 4057 didn't need to be 
>> rerun and 1 failed.
>>
>>
>> It was working fine yesterday
>> anyone else seeing it ?
>
>
> If I revert
>
> perl: Fix nativesdk install path
> Commit 38234f2e276356b1d77a87ceabc486107e336d19 tried to fix the sed
> expressions by anchoring the left side of the search regexp to prevent
> $prefix$prefix type expression in the perl config. For nativesdk this is
> not enough. Adding anchors on both side fixes this.
>
> Signed-off-by: Christian Glindkamp 
> Signed-off-by: Richard Purdie 
>
>
>
> It works again
>
> Thanks
> -Khem
>
>
>
> ___
> 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] boost: Support enums in hash

2012-09-27 Thread Khem Raj

Fixes builds which were building fine with previous versions of boost

Signed-off-by: Khem Raj 
---
 meta/recipes-support/boost/boost_1.51.0.bb|6 ++-
 meta/recipes-support/boost/files/hash_enums.patch |   45 +
 2 files changed, 49 insertions(+), 2 deletions(-)
 create mode 100644 meta/recipes-support/boost/files/hash_enums.patch

diff --git a/meta/recipes-support/boost/boost_1.51.0.bb 
b/meta/recipes-support/boost/boost_1.51.0.bb
index 1564b0e..b95049f 100644
--- a/meta/recipes-support/boost/boost_1.51.0.bb
+++ b/meta/recipes-support/boost/boost_1.51.0.bb
@@ -2,8 +2,10 @@ include boost.inc
 
 LIC_FILES_CHKSUM = 
"file://LICENSE_1_0.txt;md5=e4224ccaecb14d942c71d31bef20d78c"
 
-PR = "${INC_PR}.0"
+PR = "${INC_PR}.1"
 
-SRC_URI += "file://arm-intrinsics.patch"
+SRC_URI += "file://arm-intrinsics.patch \
+file://hash_enums.patch \
+   "
 SRC_URI[md5sum] = "4b6bd483b692fd138aef84ed2c8eb679"
 SRC_URI[sha256sum] = 
"fb2d2335a29ee7fe040a197292bfce982af84a645c81688a915c84c925b69696"
diff --git a/meta/recipes-support/boost/files/hash_enums.patch 
b/meta/recipes-support/boost/files/hash_enums.patch
new file mode 100644
index 000..368da96
--- /dev/null
+++ b/meta/recipes-support/boost/files/hash_enums.patch
@@ -0,0 +1,45 @@
+Allow hashing of enums.
+Fixes errors like 
+
+/opt/poky/1.3.0-1/sysroots/i586-poky-linux/usr/include/boost/functional/hash/extensions.hpp:257:34:
 error: no matching function for call to 'hash_value(const myspace::idx&)'
+
+Upstream-Status: Pending
+Singed-off-by: Khem Raj 
+
+Index: boost_1_51_0/boost/functional/hash/hash.hpp
+===
+--- boost_1_51_0.orig/boost/functional/hash/hash.hpp   2012-07-15 
16:28:30.0 -0700
 boost_1_51_0/boost/functional/hash/hash.hpp2012-09-26 
14:00:57.738364002 -0700
+@@ -15,6 +15,8 @@
+ #include 
+ #include 
+ #include 
++#include 
++#include 
+ 
+ #if defined(BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION)
+ #include 
+@@ -89,6 +91,9 @@
+ typename boost::hash_detail::long_numbers::type hash_value(T);
+ template 
+ typename boost::hash_detail::ulong_numbers::type hash_value(T);
++template 
++typename boost::enable_if, std::size_t>::type
++  hash_value(T);
+ 
+ #if !BOOST_WORKAROUND(__DMC__, <= 0x848)
+ template  std::size_t hash_value(T* const&);
+@@ -178,7 +183,12 @@
+ {
+ return hash_detail::hash_value_unsigned(v);
+ }
+-
++template 
++typename boost::enable_if, std::size_t>::type
++  hash_value(T v)
++{
++  return static_cast(v);
++}
+ // Implementation by Alberto Barbati and Dave Harris.
+ #if !BOOST_WORKAROUND(__DMC__, <= 0x848)
+ template  std::size_t hash_value(T* const& v)
-- 
1.7.9.5


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

[OE-core] [PATCH] flex,bison: Add nativesdk variants

2012-09-27 Thread Khem Raj

It is needed in some SDKs that we ship own
version of lex/yacc for sdk host

Signed-off-by: Khem Raj 
---
 meta/recipes-devtools/bison/bison_2.5.1.bb |2 +-
 meta/recipes-devtools/flex/flex_2.5.35.bb  |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-devtools/bison/bison_2.5.1.bb 
b/meta/recipes-devtools/bison/bison_2.5.1.bb
index d53c1d6..47b4a6c 100644
--- a/meta/recipes-devtools/bison/bison_2.5.1.bb
+++ b/meta/recipes-devtools/bison/bison_2.5.1.bb
@@ -33,4 +33,4 @@ do_install_append_virtclass-native() {
BISON_PKGDATADIR=${STAGING_DATADIR_NATIVE}/bison
 }
 #bison-native encodes the staging M4 path
-BBCLASSEXTEND = "native"
+BBCLASSEXTEND = "native nativesdk"
diff --git a/meta/recipes-devtools/flex/flex_2.5.35.bb 
b/meta/recipes-devtools/flex/flex_2.5.35.bb
index 7419f10..2218c91 100644
--- a/meta/recipes-devtools/flex/flex_2.5.35.bb
+++ b/meta/recipes-devtools/flex/flex_2.5.35.bb
@@ -2,7 +2,7 @@ require flex.inc
 PR = "r3"
 LICENSE="BSD"
 LIC_FILES_CHKSUM = "file://COPYING;md5=e4742cf92e89040b39486a6219b68067"
-BBCLASSEXTEND = "native"
+BBCLASSEXTEND = "native nativesdk"
 
 SRC_URI += "file://avoid-FORTIFY-warnings.patch \
 file://int-is-not-the-same-size-as-size_t.patch"
-- 
1.7.9.5


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

Re: [OE-core] perl install error

2012-09-27 Thread Khem Raj


On Sep 27, 2012, at 8:40 PM, McClintock Matthew-B29882  
wrote:

> Khem,
> 
> I'm just not looking at a similiar issue. Do this:
> 


just 'not' or just 'now' ?

> cat tmp/sstate-control/manifest-* | grep usr/lib/perl5
> 
> And see which recipe is making this folder. It should be the perl
> recipe, first not some other recipe…


cat sstate-control/manifest-* | grep usr/lib/perl5

return nothing

> 
> Side question are you using FSL layers?

yes

> 
> -M
> 
> On Thu, Sep 27, 2012 at 10:28 PM, Khem Raj  wrote:
>> 
>> On Sep 27, 2012, at 8:22 PM, Khem Raj  wrote:
>> 
>>> Hi
>>> 
>>> On ppc64 I am getting
>>> 
>>> | Warning: perl appears in your path in the following locations beyond where
>>> | we just installed it:
>>> | 
>>> /work/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/bin/perl-native/perl
>>> |
>>> | make[1]: Nothing to be done for `install.man'.
>>> | make[1]: Leaving directory 
>>> `/work/yocto/poky/build/tmp/work/ppc64e5500-poky-linux/perl-5.14.2-r10/perl-5.14.2'
>>> | ln: failed to create symbolic link 
>>> `/work/yocto/poky/build/tmp/work/ppc64e5500-poky-linux/perl-5.14.2-r10/image//usr/lib64/perl5':
>>>  No such file or directory
>>> | ERROR: Function failed: do_install (see 
>>> /work/yocto/poky/build/tmp/work/ppc64e5500-poky-linux/perl-5.14.2-r10/temp/log.do_install.6656
>>>  for further information)
>>> ERROR: Task 1679 
>>> (/work/yocto/poky/meta/recipes-devtools/perl/perl_5.14.2.bb, do_install) 
>>> failed with exit code '1'
>>> NOTE: Tasks Summary: Attempted 4082 tasks of which 4057 didn't need to be 
>>> rerun and 1 failed.
>>> 
>>> 
>>> It was working fine yesterday
>>> anyone else seeing it ?
>> 
>> 
>> If I revert
>> 
>> perl: Fix nativesdk install path
>> Commit 38234f2e276356b1d77a87ceabc486107e336d19 tried to fix the sed
>> expressions by anchoring the left side of the search regexp to prevent
>> $prefix$prefix type expression in the perl config. For nativesdk this is
>> not enough. Adding anchors on both side fixes this.
>> 
>> Signed-off-by: Christian Glindkamp 
>> Signed-off-by: Richard Purdie 
>> 
>> 
>> 
>> It works again
>> 
>> Thanks
>> -Khem
>> 
>> 
>> 
>> ___
>> 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] perl install error

2012-09-27 Thread Khem Raj


On Sep 27, 2012, at 8:52 PM, McClintock Matthew-B29882  
wrote:

> On Thu, Sep 27, 2012 at 10:43 PM, Khem Raj  wrote:
>> 
>> On Sep 27, 2012, at 8:40 PM, McClintock Matthew-B29882 
>>  wrote:
>> 
>>> Khem,
>>> 
>>> I'm just not looking at a similiar issue. Do this:
>>> 
>> 
>> 
>> just 'not' or just 'now' ?
>> 
>>> cat tmp/sstate-control/manifest-* | grep usr/lib/perl5
>>> 
>>> And see which recipe is making this folder. It should be the perl
>>> recipe, first not some other recipe…
>> 
>> 
>> cat sstate-control/manifest-* | grep usr/lib/perl5
>> 
>> return nothing
> 
> Maybe this is not the same root cause then.

reverting that commit fixed it. before that I tried to cleans state clean all 
perl and perl-native
to no avail.

> 
>> 
>>> 
>>> Side question are you using FSL layers?
>> 
>> yes
> 
> Is libhugetlbfs getting built?

No


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

Re: [OE-core] perl install error

2012-09-27 Thread McClintock Matthew-B29882

On Thu, Sep 27, 2012 at 11:18 PM, Khem Raj  wrote:
>
> On Sep 27, 2012, at 8:52 PM, McClintock Matthew-B29882  
> wrote:
>
>> On Thu, Sep 27, 2012 at 10:43 PM, Khem Raj  wrote:
>>>
>>> On Sep 27, 2012, at 8:40 PM, McClintock Matthew-B29882 
>>>  wrote:
>>>
 Khem,

 I'm just not looking at a similiar issue. Do this:

>>>
>>>
>>> just 'not' or just 'now' ?
>>>
 cat tmp/sstate-control/manifest-* | grep usr/lib/perl5

 And see which recipe is making this folder. It should be the perl
 recipe, first not some other recipe…
>>>
>>>
>>> cat sstate-control/manifest-* | grep usr/lib/perl5
>>>
>>> return nothing
>>
>> Maybe this is not the same root cause then.
>
> reverting that commit fixed it. before that I tried to cleans state clean all 
> perl and perl-native
> to no avail.

OK, well we got the same error and ours was from another sstate-cache
installing files in /usr/lib/perl5 before perl installed it's own
symlink. cleaning cache for perl did not help either.

Reverting that patch could have causes rebuilds and change of ordering
(possibly) that might mask the error a little longer. If ours are
related.

-M

>>
>>>

 Side question are you using FSL layers?
>>>
>>> yes
>>
>> Is libhugetlbfs getting built?
>
> No
>
>
> ___
> 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] perl install error

2012-09-27 Thread Khem Raj


On Sep 27, 2012, at 9:23 PM, McClintock Matthew-B29882  
wrote:

> On Thu, Sep 27, 2012 at 11:18 PM, Khem Raj  wrote:
>> 
>> On Sep 27, 2012, at 8:52 PM, McClintock Matthew-B29882 
>>  wrote:
>> 
>>> On Thu, Sep 27, 2012 at 10:43 PM, Khem Raj  wrote:
 
 On Sep 27, 2012, at 8:40 PM, McClintock Matthew-B29882 
  wrote:
 
> Khem,
> 
> I'm just not looking at a similiar issue. Do this:
> 
 
 
 just 'not' or just 'now' ?
 
> cat tmp/sstate-control/manifest-* | grep usr/lib/perl5
> 
> And see which recipe is making this folder. It should be the perl
> recipe, first not some other recipe…
 
 
 cat sstate-control/manifest-* | grep usr/lib/perl5
 
 return nothing
>>> 
>>> Maybe this is not the same root cause then.
>> 
>> reverting that commit fixed it. before that I tried to cleans state clean 
>> all perl and perl-native
>> to no avail.
> 
> OK, well we got the same error and ours was from another sstate-cache
> installing files in /usr/lib/perl5 before perl installed it's own
> symlink. cleaning cache for perl did not help either.
> 
> Reverting that patch could have causes rebuilds and change of ordering
> (possibly) that might mask the error a little longer. If ours are
> related.


Does it mean that if I invalidate whole state it will work ?
thats kind of gross


> 
> -M
> 
>>> 
 
> 
> Side question are you using FSL layers?
 
 yes
>>> 
>>> Is libhugetlbfs getting built?
>> 
>> No
>> 
>> 
>> ___
>> 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] perl install error

2012-09-27 Thread McClintock Matthew-B29882

On Thu, Sep 27, 2012 at 11:38 PM, Khem Raj  wrote:
>
> On Sep 27, 2012, at 9:23 PM, McClintock Matthew-B29882  
> wrote:
>
>> On Thu, Sep 27, 2012 at 11:18 PM, Khem Raj  wrote:
>>>
>>> On Sep 27, 2012, at 8:52 PM, McClintock Matthew-B29882 
>>>  wrote:
>>>
 On Thu, Sep 27, 2012 at 10:43 PM, Khem Raj  wrote:
>
> On Sep 27, 2012, at 8:40 PM, McClintock Matthew-B29882 
>  wrote:
>
>> Khem,
>>
>> I'm just not looking at a similiar issue. Do this:
>>
>
>
> just 'not' or just 'now' ?
>
>> cat tmp/sstate-control/manifest-* | grep usr/lib/perl5
>>
>> And see which recipe is making this folder. It should be the perl
>> recipe, first not some other recipe…
>
>
> cat sstate-control/manifest-* | grep usr/lib/perl5
>
> return nothing

 Maybe this is not the same root cause then.
>>>
>>> reverting that commit fixed it. before that I tried to cleans state clean 
>>> all perl and perl-native
>>> to no avail.
>>
>> OK, well we got the same error and ours was from another sstate-cache
>> installing files in /usr/lib/perl5 before perl installed it's own
>> symlink. cleaning cache for perl did not help either.
>>
>> Reverting that patch could have causes rebuilds and change of ordering
>> (possibly) that might mask the error a little longer. If ours are
>> related.
>
>
> Does it mean that if I invalidate whole state it will work ?
> thats kind of gross

I think just making sure perl is deployed to sysroot first fixes this
issue. For us we were simply missing a 'DEPENDS = perl' for a recipe
which installed stuff in /usr/lib/perl5 - if perl is deployed to
sysroot first the symlink is always in place properly.

-M

>
>
>>
>> -M
>>

>
>>
>> Side question are you using FSL layers?
>
> yes

 Is libhugetlbfs getting built?
>>>
>>> No
>>>
>>>
>>> ___
>>> 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

Re: [OE-core] [oe-commits] Richard Purdie : sstate.bbclass: Detect overwriting files in sstate controlled directories

2012-09-27 Thread Andreas Müller

On Fri, Aug 31, 2012 at 2:38 AM,   wrote:
> Module: openembedded-core.git
> Branch: master
> Commit: 1f1b6f93d6b7aa8c9bd9bb5b1826997812e36932
> URL:
> http://git.openembedded.org/?p=openembedded-core.git&a=commit;h=1f1b6f93d6b7aa8c9bd9bb5b1826997812e36932
>
> Author: Richard Purdie 
> Date:   Sat Aug 25 15:48:14 2012 +
>
> sstate.bbclass: Detect overwriting files in sstate controlled directories
>
> We have a potential problem where two sstate packages try and touch the same
> file. This adds code which will print a warning whenever this happens.
>
> The implementation does but by maintaining a master file list and comparing
> file accesses against this. There are a number of places we have duplicate
> accesses which are harmless, mostly in the deploy directory so these
> are whitelisted.
>
> For now the code prints warnings, this could be strengthened in future to
> become error messages. Whilst working on this code on and off over the past
> few months various issues were uncovered, some serious.
>
> [YOCTO #238]
>
> Signed-off-by: Richard Purdie 
>
> ---
>
>  meta/classes/sstate.bbclass |   45 
> ++-
>  1 files changed, 44 insertions(+), 1 deletions(-)
>
> diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
> index 6762e32..02594a7 100644
> --- a/meta/classes/sstate.bbclass
> +++ b/meta/classes/sstate.bbclass
> @@ -3,6 +3,7 @@ SSTATE_VERSION = "2"
>  SSTATE_MANIFESTS ?= "${TMPDIR}/sstate-control"
>  SSTATE_MANFILEBASE = "${SSTATE_MANIFESTS}/manifest-${SSTATE_MANMACH}-"
>  SSTATE_MANFILEPREFIX = "${SSTATE_MANFILEBASE}${PN}"
> +SSTATE_MASTERMANIFEST = "${SSTATE_MANIFESTS}/master.list"
>
>  def generate_sstatefn(spec, hash, d):
>  if not hash:
> @@ -17,6 +18,7 @@ SSTATE_EXTRAPATH   = ""
>  SSTATE_EXTRAPATHWILDCARD = ""
>  SSTATE_PATHSPEC   = 
> "${SSTATE_DIR}/${SSTATE_EXTRAPATHWILDCARD}*/${SSTATE_PKGSPEC}"
>
> +SSTATE_DUPWHITELIST = "${DEPLOY_DIR_IMAGE}/ ${DEPLOY_DIR}/licenses/ 
> ${DEPLOY_DIR_IPK}/all/ ${DEPLOY_DIR_RPM}/all ${DEPLOY_DIR_DEB}/all/"
>
>  SSTATE_SCAN_FILES ?= "*.la *-config *_config"
>  SSTATE_SCAN_CMD ?= 'find ${SSTATE_BUILDDIR} \( -name "${@"\" -o -name 
> \"".join(d.getVar("SSTATE_SCAN_FILES", True).split())}" \) -type f'
> @@ -125,7 +127,6 @@ def sstate_install(ss, d):
>  locks.append(bb.utils.lockfile(lock))
>
>  for state in ss['dirs']:
> -oe.path.copytree(state[1], state[2])
>  for walkroot, dirs, files in os.walk(state[1]):
>  bb.debug(2, "Staging files from %s to %s" % (state[1], state[2]))
>  for file in files:
> @@ -140,9 +141,35 @@ def sstate_install(ss, d):
>  if not dstdir.endswith("/"):
>  dstdir = dstdir + "/"
>  shareddirs.append(dstdir)
> +
> +# Check the file list for conflicts against the master manifest
> +mastermanifest = d.getVar("SSTATE_MASTERMANIFEST", True)
> +whitelist = d.getVar("SSTATE_DUPWHITELIST", True)
> +lock = bb.utils.lockfile(mastermanifest + ".lock")
> +fileslist = [line.strip() for line in open(mastermanifest)]
> +bb.utils.unlockfile(lock)
> +match = []
> +for f in sharedfiles:
> +if f in fileslist:
> +realmatch = True
> +for w in whitelist:
> +if f.startswith(w):
> +realmatch = False
> +break
> +if realmatch:
> +match.append(f)
> +if match:
> +bb.warn("The recipe is trying to install files into a shared area 
> when those files already exist. Those files are:\n   %s" % "\n   
> ".join(match))
> +
> +# Write out the manifest and add to the task's manifest file
> +lock = bb.utils.lockfile(mastermanifest + ".lock")
> +mf = open(mastermanifest, "a")
>  f = open(manifest, "w")
>  for file in sharedfiles:
> +mf.write(file + "\n")
>  f.write(file + "\n")
> +bb.utils.unlockfile(lock)
> +
>  # We want to ensure that directories appear at the end of the manifest
>  # so that when we test to see if they should be deleted any contents
>  # added by the task will have been removed first.
> @@ -152,6 +179,10 @@ def sstate_install(ss, d):
>  f.write(di + "\n")
>  f.close()
>
> +# Run the actual file install
> +for state in ss['dirs']:
> +oe.path.copytree(state[1], state[2])
> +
>  for postinst in (d.getVar('SSTATEPOSTINSTFUNCS', True) or '').split():
>  bb.build.exec_func(postinst, d)
>
> @@ -268,6 +299,18 @@ def sstate_clean_manifest(manifest, d):
>  except OSError:
>  pass
>
> +# Remove the entries from the master manifest
> +mastermanifest = d.getVar("SSTATE_MASTERMANIFEST", True)
> +lock = bb.utils.lockfile(mastermanifest + ".lock")
> +mf = open(mastermanifest + ".new", "w")
> +for line in open(mastermanifest, "r"):
> +if not line or line in entries:
> +continue
> +mf.write(lin

Re: [OE-core] [oe-core][PATCH 00/10] qt4: upgrade to 4.8.3 and cleanup

2012-09-27 Thread Anders Darander

* Martin Jansa  [120927 17:44]:

> On Thu, Sep 27, 2012 at 04:10:20PM +0100, Paul Eggleton wrote:
> > On Thursday 27 September 2012 00:27:05 Martin Jansa wrote:
> > > Please test on more architectures.
> > > I've tested complete qt4-native + qt4-free-x11 on armv4t.
> > > And only do_patch for nativesdk-qt4-tools, qt-mobility-*, qt4-embedded.
> > 
> > So this is great work and these patches look good, although I'm still not 
> > particularly happy with breaking out so many of the configure options 
> > because 
> > I'm convinced it won't stop here; but it's possible I might be overruled on 
> > this issue. 

> I've added that, because meta-webos layer disables more stuff then .inc
> file forces enabled, so I would have to rewrite whole QT_CONFIG_FLAGS
> (if I don't want to have e.g. -webkit from .inc and -no-webkit appended
> after that through QT_DISTRO_FLAGS).

> But it can be just 2 variables instead of 6 if it's issue.

I haven't looked closely at the patches, but we're also disabling lots
of stuff (though, quite a bit of that comes from meta-oe). Thus, I'm
leaning towards an easier way to handle this.

We're currently using an approach were we add to QT_CONFIG_FLAGS, to set
our desired config, and oe_filter_out() to remove certain defaults from
oe-core and meta-oe. Thus, everything that can help reduce this mess is
something we'd appreciate.

Cheers,
Anders


-- 
Anders Darander
ChargeStorm AB / eStorm AB

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

Re: [OE-core] [PATCH] SDK: trap any IO errors in the relocate script

2012-09-27 Thread Laurentiu Palcu



On 09/27/2012 06:49 PM, Saul Wold wrote:
> On 09/25/2012 09:35 AM, Laurentiu Palcu wrote:
> 
> BTW: in the future it's good to say the "filename: "
This is what I usually use when I change single files. However,
sometimes (and I know this particular patch is not the case), I change
multiple files to fix a single problem or add a feature. In this case
your BKM is not quite appropriate. I will end up with a commit subject
like this:

filename1, filename2, filename3: 

If those files belong to a certain functional area, say SDK, I thought
it was more appropriate to prepend the subject with SDK.

Also, the contribution guidelines on the wiki, state the same (see rpm
example):

https://wiki.yoctoproject.org/wiki/Contribution_Guidelines

Am I wrong here?

Thanks,
Laurentiu

> 
> So this would be "relocate_sdk.py: "
>> If the files being relocated are already used by other processes the
>> relocate script will fail with a traceback. This patch will trap any IO
>> errors when opening such a file and gracefully report them to the user.
>>
>> Also change the exit code from 1 to -1 for a better adt-installer user
>> experience (like pointing the user to the adt_installer.log).
>>
>> [YOCTO #3164]
>>
>> Signed-off-by: Laurentiu Palcu 
>> ---
>>   scripts/relocate_sdk.py |   14 --
>>   1 file changed, 12 insertions(+), 2 deletions(-)
>>
>> diff --git a/scripts/relocate_sdk.py b/scripts/relocate_sdk.py
>> index b247e65..637ffe9 100755
>> --- a/scripts/relocate_sdk.py
>> +++ b/scripts/relocate_sdk.py
>> @@ -29,6 +29,7 @@ import sys
>>   import stat
>>   import os
>>   import re
>> +import errno
>>
>>   old_prefix = re.compile("##DEFAULT_INSTALL_DIR##")
>>
>> @@ -171,7 +172,7 @@ def change_dl_sysdirs():
>>
>>   # MAIN
>>   if len(sys.argv) < 4:
>> -exit(1)
>> +exit(-1)
>>
>>   new_prefix = sys.argv[1]
>>   new_dl_path = sys.argv[2]
>> @@ -184,7 +185,16 @@ for e in executables_list:
>>   else:
>>   os.chmod(e, perms|stat.S_IRWXU)
>>
>> -f = open(e, "r+b")
>> +try:
>> +f = open(e, "r+b")
>> +except IOError as ioex:
>> +if ioex.errno == errno.ETXTBSY:
>> +print("Could not open %s. File used by another process.\nPlease 
>> "\
>> +  "make sure you exit all processes that might use any SDK 
>> "\
>> +  "binaries." % e)
>> +else:
>> +print("Could not open %s: %s(%d)" % (e, ioex.strerror, 
>> ioex.errno))
>> +exit(-1)
>>
>>   arch = get_arch()
>>   if arch:
>>
> Merged into OE-Core
> 
> Thanks
>   Sau!
> 

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

[OE-core] [PATCH 0/1] ltp: add dependency libcap

2012-09-27 Thread Kang Kai

The following changes since commit 3c58f92d46e32c40b80575f14e0f6f66c9920c66:

  Revert "autotools.bbclass: using relative paths for acpaths" (2012-09-27 
17:57:58 +0100)

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

Kang Kai (1):
  ltp: add dependency libcap

 meta/recipes-extended/ltp/ltp_20120903.bb |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

-- 
1.7.5.4


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

[OE-core] [PATCH 1/1] ltp: add dependency libcap

2012-09-27 Thread Kang Kai

Similar to libaio, libcap is another dependency of ltp.

If libcap has been done populate_sysroot but rpm/ipk package is not
created, ltp will be compiled with libcap. So when install ltp to a
image, it complains that package libcap is not found.

[Yocto #2973]

Signed-off-by: Kang Kai 
---
 meta/recipes-extended/ltp/ltp_20120903.bb |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-extended/ltp/ltp_20120903.bb 
b/meta/recipes-extended/ltp/ltp_20120903.bb
index 85270ea..e3e760d 100644
--- a/meta/recipes-extended/ltp/ltp_20120903.bb
+++ b/meta/recipes-extended/ltp/ltp_20120903.bb
@@ -19,9 +19,9 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3 \

file://utils/benchmark/kernbench-0.42/COPYING;md5=94d55d512a9ba36caa9b7df079bae19f
 \
"
 
-DEPENDS = "attr libaio"
+DEPENDS = "attr libaio libcap"
 
-PR = "r0"
+PR = "r1"
 
 SRC_URI = "${SOURCEFORGE_MIRROR}/ltp/ltp-full-${PV}.bz2"
 
-- 
1.7.5.4


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

96 matches

Mail list logo