date:20110927

Hi Richard,

This pull request is to fix several multilib bugs related with RPM backend,
please help to review.

BTW, I am issuing a round of multilib testing agasint:
 - lib32 sato image on qemux86 machine
 - lib32 sato image on qemux86-64 machine
 - lib64 sato image on qemux86-64 machine
 - lib64 sato image on qemux86 machine
 - sato image on qemux86-64 with several lib32 packages (lib32-connman)

I will update you the test result once it is finished.

Thanks,
Dongxiao

The following changes since commit 684a4b517d13884c315688967fadd5e6a4845b71:

  libffi: really populate -dev package (2011-09-26 20:50:27 +0100)

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

Dongxiao Xu (4):
  multilib.bbclass: map RDEPENDS and LINGUAS_INSTALL for image recipes
  multilib: remove the multilib handling to allarch
  multilib: add MLPREFIX to deploy folder
  tune-i586: fix hardcoded TUNE_PKGARCH

 meta/classes/multilib.bbclass  |   12 +---
 meta/classes/multilib_global.bbclass   |2 +-
 meta/classes/package_rpm.bbclass   |   10 --
 meta/classes/rootfs_rpm.bbclass|2 +-
 meta/conf/machine/include/tune-i586.inc|3 ++-
 meta/conf/multilib.conf|7 +++
 .../python/python-pygobject_2.27.91.bb |2 +-
 7 files changed, 25 insertions(+), 13 deletions(-)


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

[OE-core] [PATCH 1/4] multilib.bbclass: map RDEPENDS and LINGUAS_INSTALL for image recipes

RDEPENDS of image type recipe needs to be mapped to make sure that the
packages included in the image should be multilib version.

Also add LINGUAS_INSTALL into MULTILIB_PACKAGE_INSTALL list.

[YOCTO #1496]
[YOCTO #1527]

Signed-off-by: Dongxiao Xu dongxiao...@intel.com
---
 meta/classes/multilib.bbclass |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/meta/classes/multilib.bbclass b/meta/classes/multilib.bbclass
index 98f6911..0ea1038 100644
--- a/meta/classes/multilib.bbclass
+++ b/meta/classes/multilib.bbclass
@@ -54,9 +54,12 @@ python __anonymous () {
 
 if bb.data.inherits_class('image', d):
 map_dependencies(PACKAGE_INSTALL, d)
-pinstall = d.getVar(PACKAGE_INSTALL, True) +   + 
d.getVar(MULTILIB_PACKAGE_INSTALL, False)
+map_dependencies(LINGUAS_INSTALL, d)
+map_dependencies(RDEPENDS, d)
+pinstall = d.getVar(LINGUAS_INSTALL, True) +   + 
d.getVar(PACKAGE_INSTALL, True) +   + d.getVar(MULTILIB_PACKAGE_INSTALL, 
False)
 d.setVar(MULTILIB_PACKAGE_INSTALL, pinstall)
 d.setVar(PACKAGE_INSTALL, )
+d.setVar(LINGUAS_INSTALL, )
 # FIXME, we need to map this to something, not delete it!
 d.setVar(PACKAGE_INSTALL_ATTEMPTONLY, )
 return
-- 
1.7.1


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

[OE-core] [PATCH 3/4] multilib: add MLPREFIX to deploy folder

Add MLPREFIX to multilib deploy forlder to avoid the confliction between
multilib and normal package deploy directory.

Signed-off-by: Dongxiao Xu dongxiao...@intel.com
---
 meta/classes/multilib.bbclass|5 -
 meta/classes/package_rpm.bbclass |   10 --
 meta/classes/rootfs_rpm.bbclass  |2 +-
 3 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/meta/classes/multilib.bbclass b/meta/classes/multilib.bbclass
index 6c0dd37..1aed2a9 100644
--- a/meta/classes/multilib.bbclass
+++ b/meta/classes/multilib.bbclass
@@ -92,9 +92,4 @@ python __anonymous () {
 multilib_map_variable(PACKAGES_DYNAMIC, variant, d)
 multilib_map_variable(PACKAGE_INSTALL, variant, d)
 multilib_map_variable(INITSCRIPT_PACKAGES, variant, d)
-
-package_arch = d.getVar(PACKAGE_ARCH, True)
-machine_arch = d.getVar(MACHINE_ARCH, True)
-if package_arch == machine_arch:
-d.setVar(PACKAGE_ARCH, variant + _ + package_arch)
 }
diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass
index 775d525..45de0f8 100644
--- a/meta/classes/package_rpm.bbclass
+++ b/meta/classes/package_rpm.bbclass
@@ -903,8 +903,14 @@ python do_package_rpm () {
rpmbuild = bb.data.getVar('RPMBUILD', d, True)
targetsys = bb.data.getVar('TARGET_SYS', d, True)
targetvendor = bb.data.getVar('TARGET_VENDOR', d, True)
-   pkgwritedir = bb.data.expand('${PKGWRITEDIRRPM}/${PACKAGE_ARCH}', d)
-   pkgarch = 
bb.data.expand('${PACKAGE_ARCH}${TARGET_VENDOR}-${TARGET_OS}', d)
+   package_arch = bb.data.getVar('PACKAGE_ARCH', d, True) or 
+   if package_arch not in all any noarch.split():
+   ml_prefix = (bb.data.getVar('MLPREFIX', d, True) or 
).replace(-, _)
+   bb.data.setVar('PACKAGE_ARCH_EXTEND', ml_prefix + package_arch, 
d)
+   else:
+   bb.data.setVar('PACKAGE_ARCH_EXTEND', package_arch, d)
+   pkgwritedir = 
bb.data.expand('${PKGWRITEDIRRPM}/${PACKAGE_ARCH_EXTEND}', d)
+   pkgarch = 
bb.data.expand('${PACKAGE_ARCH_EXTEND}${TARGET_VENDOR}-${TARGET_OS}', d)
magicfile = 
bb.data.expand('${STAGING_DIR_NATIVE}/usr/share/misc/magic.mgc', d)
bb.mkdirhier(pkgwritedir)
os.chmod(pkgwritedir, 0755)
diff --git a/meta/classes/rootfs_rpm.bbclass b/meta/classes/rootfs_rpm.bbclass
index 5ac6bca..dd370b2 100644
--- a/meta/classes/rootfs_rpm.bbclass
+++ b/meta/classes/rootfs_rpm.bbclass
@@ -220,8 +220,8 @@ python () {
 default_tune = localdata.getVar(DEFAULTTUNE_virtclass-multilib- 
+ eext[1], False)
 if default_tune:
 localdata.setVar(DEFAULTTUNE, default_tune)
-localdata.setVar(MACHINE_ARCH, eext[1] + _ + 
localdata.getVar(MACHINE_ARCH, False))
 package_archs = localdata.getVar(PACKAGE_ARCHS, True) or 
+package_archs =  .join([i in all noarch any.split() and i or 
eext[1]+_+i for i in package_archs.split()])
 ml_package_archs +=   + package_archs
 ml_prefix_list +=   + eext[1]
 #bb.note(ML_PACKAGE_ARCHS %s %s %s % (eext[1], 
localdata.getVar(PACKAGE_ARCHS, True) or (none), overrides))
-- 
1.7.1


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

[OE-core] [PATCH 4/4] tune-i586: fix hardcoded TUNE_PKGARCH

Use TUNE_FEATURES to determine the setting to TUNE_PKGARCH, which fixes
the wrong setting of PACKAGE_ARCH in multilib case.

Signed-off-by: Dongxiao Xu dongxiao...@intel.com
---
 meta/conf/machine/include/tune-i586.inc |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/meta/conf/machine/include/tune-i586.inc 
b/meta/conf/machine/include/tune-i586.inc
index ba655b9..963afb8 100644
--- a/meta/conf/machine/include/tune-i586.inc
+++ b/meta/conf/machine/include/tune-i586.inc
@@ -1,5 +1,6 @@
 DEFAULTTUNE ?= i586
-TUNE_PKGARCH ?= i586
+TUNE_PKGARCH_TMP := ${@bb.utils.contains(TUNE_FEATURES, m32, x86, 
x86_64, d)}
+TUNE_PKGARCH ?= ${@bb.utils.contains(TUNE_FEATURES, i586, i586, 
TUNE_PKGARCH_TMP, d)}
 
 require conf/machine/include/ia32/arch-ia32.inc
 
-- 
1.7.1


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

[OE-core] [PATCH 2/4] multilib: remove the multilib handling to allarch

currently we have allarch type of recipes, which may still have
architecture dependency, like x11-common. So we need to drop the
handling to allarch in multilib case.

Also remove the PV postfix in python-pygobject DEPENDS, since multilib
code will treat a native package multilib capable.

[YOCTO #1497]
[YOCTO #1498]

Signed-off-by: Dongxiao Xu dongxiao...@intel.com
---
 meta/classes/multilib.bbclass  |2 +-
 meta/classes/multilib_global.bbclass   |2 +-
 meta/conf/multilib.conf|7 +++
 .../python/python-pygobject_2.27.91.bb |2 +-
 4 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/meta/classes/multilib.bbclass b/meta/classes/multilib.bbclass
index 0ea1038..6c0dd37 100644
--- a/meta/classes/multilib.bbclass
+++ b/meta/classes/multilib.bbclass
@@ -8,7 +8,7 @@ python multilib_virtclass_handler () {
 return
 
 # There should only be one kernel in multilib configs
-if bb.data.inherits_class('kernel', e.data) or 
bb.data.inherits_class('module-base', e.data) or 
bb.data.inherits_class('allarch', e.data):
+if bb.data.inherits_class('kernel', e.data) or 
bb.data.inherits_class('module-base', e.data):
 raise bb.parse.SkipPackage(We shouldn't have multilib variants for 
the kernel)
 
 if bb.data.inherits_class('image', e.data):
diff --git a/meta/classes/multilib_global.bbclass 
b/meta/classes/multilib_global.bbclass
index cd22163..2da66a5 100644
--- a/meta/classes/multilib_global.bbclass
+++ b/meta/classes/multilib_global.bbclass
@@ -5,7 +5,7 @@ python multilib_virtclass_handler_global () {
 variant = e.data.getVar(BBEXTENDVARIANT, True)
 
 if isinstance(e, bb.event.RecipeParsed) and not variant:
-if bb.data.inherits_class('kernel', e.data) or 
bb.data.inherits_class('module-base', e.data) or 
bb.data.inherits_class('allarch', e.data):
+if bb.data.inherits_class('kernel', e.data) or 
bb.data.inherits_class('module-base', e.data):
 variants = (e.data.getVar(MULTILIB_VARIANTS, True) or ).split()
 
 # Process PROVIDES
diff --git a/meta/conf/multilib.conf b/meta/conf/multilib.conf
index 3133bf1..b9da33a 100644
--- a/meta/conf/multilib.conf
+++ b/meta/conf/multilib.conf
@@ -452,3 +452,10 @@ BBCLASSEXTEND_append_pn-zip =  ${MULTILIBS}
 BBCLASSEXTEND_append_pn-zlib =  ${MULTILIBS}
 BBCLASSEXTEND_append_pn-zypper =  ${MULTILIBS}
 BBCLASSEXTEND_append_pn-libsdl =  ${MULTILIBS}
+BBCLASSEXTEND_append_pn-qemu-config =  ${MULTILIBS}
+BBCLASSEXTEND_append_pn-x11-common =  ${MULTILIBS}
+BBCLASSEXTEND_append_pn-update-rc.d =  ${MULTILIBS}
+BBCLASSEXTEND_append_pn-avahi-ui =  ${MULTILIBS}
+BBCLASSEXTEND_append_pn-python-pycairo =  ${MULTILIBS}
+BBCLASSEXTEND_append_pn-python-pygtk =  ${MULTILIBS}
+BBCLASSEXTEND_append_pn-python-pygobject =  ${MULTILIBS}
diff --git a/meta/recipes-devtools/python/python-pygobject_2.27.91.bb 
b/meta/recipes-devtools/python/python-pygobject_2.27.91.bb
index 9ff2fe7..fd696a5 100644
--- a/meta/recipes-devtools/python/python-pygobject_2.27.91.bb
+++ b/meta/recipes-devtools/python/python-pygobject_2.27.91.bb
@@ -2,7 +2,7 @@ DESCRIPTION = Python GObject bindings
 SECTION = devel/python
 LICENSE = LGPLv2.1
 LIC_FILES_CHKSUM = file://COPYING;md5=a916467b91076e631dd8edb7424769c7
-DEPENDS = python python-pygobject-native-${PV} glib-2.0
+DEPENDS = python python-pygobject-native glib-2.0
 DEPENDS_virtclass-native = glib-2.0-native
 RDEPENDS_virtclass-native = 
 PR = r2
-- 
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 2/5] kernel.bbclass: respect MACHINE_KERNEL_PR

2011-09-27 Thread Bruce Ashfield

On Sat, Sep 17, 2011 at 6:18 PM, Dmitry Eremin-Solenikov
dbarysh...@gmail.com wrote:
 MACHINE_KERNEL_PR was introduced long ago in org.oe.dev. It's present in
 meta-oe kernel.bbclass. Several machines depend on this functionality.

I don' t have a big problem with this, since the change is obviously
harmless if it
doesn't need to be used. But similar to my comment on patch 3/5, is there any
history/technical reasons we can capture here ?

I did a quick search to dig up a bit on this myself, but a summary
would definitely
help, since I see that this has a long and sometimes twisting history. Is it as
simple as ?

 A machine.conf or local.conf can increase MACHINE_KERNEL_PR to force
 rebuilds for kernel and external modules

Cheers,

Bruce



 Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
 ---
  meta/classes/kernel.bbclass |    5 +
  1 files changed, 5 insertions(+), 0 deletions(-)

 diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
 index c577011..b44e3b5 100644
 --- a/meta/classes/kernel.bbclass
 +++ b/meta/classes/kernel.bbclass
 @@ -20,6 +20,11 @@ python __anonymous () {
     image = bb.data.getVar('INITRAMFS_IMAGE', d, True)
     if image:
         bb.data.setVar('INITRAMFS_TASK', '${INITRAMFS_IMAGE}:do_rootfs', d)
 +
 +    machine_kernel_pr = bb.data.getVar('MACHINE_KERNEL_PR', d, True)
 +
 +    if machine_kernel_pr:
 +        bb.data.setVar('PR', machine_kernel_pr, d)
  }

  inherit kernel-arch deploy
 --
 1.7.2.5


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




-- 
Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end

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

[OE-core] [PATCH 0/1] remove gnome-vfs completely

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

All,
This patch remove gnome-vfs completely: remove itself, dependence on it, and
other obsolete recipe depending on it.

Last time, I remember one recipe in oe-core depends on gnome-vfs, but nobody
depends on it. Could somebody have a double check on oe-core?

Thanks,
Edwin

The following changes since commit e3c5d7a90ae179af0ac128ea4dfc1a5a6602c2e4:

  libtool: Fix an issue where unnecessary rpaths were being injected 
(2011-09-26 17:56:44 +0100)

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

Zhai Edwin (1):
  gnome-vfs: remove this obsolete recipe completely in favor of
GIO/GVFS

 .../recipes-gnome/libgsf/libgsf_1.14.5.bb  |8 ++-
 meta-demoapps/recipes-graphics/clutter/table.inc   |   13 -
 .../recipes-graphics/clutter/table/fixes.patch |   16 --
 .../recipes-graphics/clutter/table_git.bb  |   15 --
 .../conf/distro/include/distro_tracking_fields.inc |   11 
 meta/conf/multilib.conf|1 -
 .../gnome/gnome-vfs-2.24.4/gconftool-lossage.patch |   13 -
 .../gnome-vfs-2.24.4/gnome-vfs-no-kerberos.patch   |   53 
 meta/recipes-gnome/gnome/gnome-vfs_2.24.4.bb   |   50 --
 meta/recipes-kernel/oprofile/oprofileui.inc|2 +-
 10 files changed, 7 insertions(+), 175 deletions(-)
 delete mode 100644 meta-demoapps/recipes-graphics/clutter/table.inc
 delete mode 100644 meta-demoapps/recipes-graphics/clutter/table/fixes.patch
 delete mode 100644 meta-demoapps/recipes-graphics/clutter/table_git.bb
 delete mode 100644 
meta/recipes-gnome/gnome/gnome-vfs-2.24.4/gconftool-lossage.patch
 delete mode 100644 
meta/recipes-gnome/gnome/gnome-vfs-2.24.4/gnome-vfs-no-kerberos.patch
 delete mode 100644 meta/recipes-gnome/gnome/gnome-vfs_2.24.4.bb


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

[OE-core] [PATCH 1/1] gnome-vfs: remove this obsolete recipe completely in favor of GIO/GVFS

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

Remove oprofileui/libgsf's dependence on gnome-vfs, delete table that is out of
maintenance in clutter.

Signed-off-by: Zhai Edwin edwin.z...@intel.com
---
 .../recipes-gnome/libgsf/libgsf_1.14.5.bb  |8 ++-
 meta-demoapps/recipes-graphics/clutter/table.inc   |   13 -
 .../recipes-graphics/clutter/table/fixes.patch |   16 --
 .../recipes-graphics/clutter/table_git.bb  |   15 --
 .../conf/distro/include/distro_tracking_fields.inc |   11 
 meta/conf/multilib.conf|1 -
 .../gnome/gnome-vfs-2.24.4/gconftool-lossage.patch |   13 -
 .../gnome-vfs-2.24.4/gnome-vfs-no-kerberos.patch   |   53 
 meta/recipes-gnome/gnome/gnome-vfs_2.24.4.bb   |   50 --
 meta/recipes-kernel/oprofile/oprofileui.inc|2 +-
 10 files changed, 7 insertions(+), 175 deletions(-)
 delete mode 100644 meta-demoapps/recipes-graphics/clutter/table.inc
 delete mode 100644 meta-demoapps/recipes-graphics/clutter/table/fixes.patch
 delete mode 100644 meta-demoapps/recipes-graphics/clutter/table_git.bb
 delete mode 100644 
meta/recipes-gnome/gnome/gnome-vfs-2.24.4/gconftool-lossage.patch
 delete mode 100644 
meta/recipes-gnome/gnome/gnome-vfs-2.24.4/gnome-vfs-no-kerberos.patch
 delete mode 100644 meta/recipes-gnome/gnome/gnome-vfs_2.24.4.bb

diff --git a/meta-demoapps/recipes-gnome/libgsf/libgsf_1.14.5.bb 
b/meta-demoapps/recipes-gnome/libgsf/libgsf_1.14.5.bb
index 3ac7d6e..bf1b1ad 100644
--- a/meta-demoapps/recipes-gnome/libgsf/libgsf_1.14.5.bb
+++ b/meta-demoapps/recipes-gnome/libgsf/libgsf_1.14.5.bb
@@ -1,10 +1,14 @@
 DESCRIPTION = GNOME Structured File Library
 LICENSE = GPL
 SECTION = libs
-PR = r1
+PR = r2
+
+LIC_FILES_CHKSUM = file://COPYING;md5=dc7371b50816c96e145fa0f8ade8e24d \
+file://COPYING.LIB;md5=61464cfe342798eeced82efe9ae55f63 \
+
file://gsf/gsf.h;endline=25;md5=15cf6d31ad023167779ab5f0bbb76f49
 
 DEPENDS= libxml2 bzip2 glib-2.0 zlib
-RDEPENDS_${PN} = gconf gnome-vfs
+RDEPENDS_${PN} = gconf
 
 
 PACKAGES =+ ${PN}-gnome ${PN}-gnome-dev 
diff --git a/meta-demoapps/recipes-graphics/clutter/table.inc 
b/meta-demoapps/recipes-graphics/clutter/table.inc
deleted file mode 100644
index 937ad56..000
--- a/meta-demoapps/recipes-graphics/clutter/table.inc
+++ /dev/null
@@ -1,13 +0,0 @@
-DESCRIPTION = Table Clutter Demo
-HOMEPAGE = http://www.clutter-project.org/;
-LICENSE = LGPLv2.1  GPLv2
-
-DEPENDS = clutter-gst-1.4 gnome-vfs
-
-inherit autotools pkgconfig
-
-do_install() {
-   install -d ${D}${bindir}
-   install -m 0755 ${S}/table ${D}${bindir}/table
-}
-
diff --git a/meta-demoapps/recipes-graphics/clutter/table/fixes.patch 
b/meta-demoapps/recipes-graphics/clutter/table/fixes.patch
deleted file mode 100644
index 323bf13..000
--- a/meta-demoapps/recipes-graphics/clutter/table/fixes.patch
+++ /dev/null
@@ -1,16 +0,0 @@
-Upstream-Status: Pending
-
-Index: table/Makefile
-===
 table.orig/Makefile2007-07-10 13:24:18.0 +0100
-+++ table/Makefile 2007-07-10 13:28:10.0 +0100
-@@ -8,7 +8,7 @@ all: table
- 
- 
- table: table.o clutter-dominatrix.o clutter-video-player.o
--  $(CC) -g -Wall $(CFLAGS) -o $@ table.o clutter-dominatrix.o 
clutter-video-player.o $(LIBS)
-+  $(CC) -g -Wall $(CFLAGS) $(LDFLAGS) -o $@ table.o clutter-dominatrix.o 
clutter-video-player.o $(LIBS)
- 
- clean:
-   rm -fr *.o table
-\ No newline at end of file
diff --git a/meta-demoapps/recipes-graphics/clutter/table_git.bb 
b/meta-demoapps/recipes-graphics/clutter/table_git.bb
deleted file mode 100644
index d0ae184..000
--- a/meta-demoapps/recipes-graphics/clutter/table_git.bb
+++ /dev/null
@@ -1,15 +0,0 @@
-require table.inc
-
-LIC_FILES_CHKSUM = file://fluttr/COPYING;md5=59530bdf33659b29e73d4adb9f9f6552 
\
-
file://script-viewer/COPYING;md5=7fbc338309ac38fefcd64b04bb903e34
-
-SRCREV = 4b267533ce16656cba4104fc39dc12709c1bdddf
-PV = 0.3.0+git${SRCPV}
-PR = r1
-
-SRC_URI = git://git.clutter-project.org/toys.git;protocol=git \
-   file://fixes.patch;patch=1
-
-S = ${WORKDIR}/git/table
-
-
diff --git a/meta/conf/distro/include/distro_tracking_fields.inc 
b/meta/conf/distro/include/distro_tracking_fields.inc
index c1f15e1..c08a1c8 100644
--- a/meta/conf/distro/include/distro_tracking_fields.inc
+++ b/meta/conf/distro/include/distro_tracking_fields.inc
@@ -4609,17 +4609,6 @@ RECIPE_COMMENTS_pn-libx11-trim = 
 RECIPE_LAST_UPDATE_pn-libx11-trim = Jul 9, 2010
 RECIPE_MAINTAINER_pn-libx11-trim = Dexuan Cui dexuan@intel.com
 
-RECIPE_STATUS_pn-gnome-vfs = green
-RECIPE_DEPENDENCY_CHECK_pn-gnome-vfs = not done
-RECIPE_LATEST_VERSION_pn-gnome-vfs = 2.24.4
-RECIPE_NO_OF_PATCHES_pn-gnome-vfs = 2
-RECIPE_INTEL_SECTION_pn-gnome-vfs = gnome/lib
-RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn-gnome-vfs = 6 months

Re: [OE-core] [PATCH 0/1] remove gnome-vfs completely

2011-09-27 Thread Zhai, Edwin

BTW,
I found many recipes in meta-demoapps are not maintained: no 
LIC_FILES_CHKSUM/SRCREV, no workable SRC_URI, and even no layer.conf under 
meta-demoapps.

We need more test for demoapps, and require each commit to take care of them, 
or 
else remove them completely...


On Tue, Sep 27, 2011 at 09:49:25PM +0800, edwin.z...@intel.com wrote:
 From: Zhai Edwin edwin.z...@intel.com
 
 All,
 This patch remove gnome-vfs completely: remove itself, dependence on it, and
 other obsolete recipe depending on it.
 
 Last time, I remember one recipe in oe-core depends on gnome-vfs, but nobody
 depends on it. Could somebody have a double check on oe-core?
 
 Thanks,
 Edwin
 
 The following changes since commit e3c5d7a90ae179af0ac128ea4dfc1a5a6602c2e4:
 
   libtool: Fix an issue where unnecessary rpaths were being injected 
 (2011-09-26 17:56:44 +0100)
 
 are available in the git repository at:
   git://git.pokylinux.org/poky-contrib gzhai/master2
   http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=gzhai/master2
 
 Zhai Edwin (1):
   gnome-vfs: remove this obsolete recipe completely in favor of
 GIO/GVFS
 
  .../recipes-gnome/libgsf/libgsf_1.14.5.bb  |8 ++-
  meta-demoapps/recipes-graphics/clutter/table.inc   |   13 -
  .../recipes-graphics/clutter/table/fixes.patch |   16 --
  .../recipes-graphics/clutter/table_git.bb  |   15 --
  .../conf/distro/include/distro_tracking_fields.inc |   11 
  meta/conf/multilib.conf|1 -
  .../gnome/gnome-vfs-2.24.4/gconftool-lossage.patch |   13 -
  .../gnome-vfs-2.24.4/gnome-vfs-no-kerberos.patch   |   53 
 
  meta/recipes-gnome/gnome/gnome-vfs_2.24.4.bb   |   50 --
  meta/recipes-kernel/oprofile/oprofileui.inc|2 +-
  10 files changed, 7 insertions(+), 175 deletions(-)
  delete mode 100644 meta-demoapps/recipes-graphics/clutter/table.inc
  delete mode 100644 meta-demoapps/recipes-graphics/clutter/table/fixes.patch
  delete mode 100644 meta-demoapps/recipes-graphics/clutter/table_git.bb
  delete mode 100644 
 meta/recipes-gnome/gnome/gnome-vfs-2.24.4/gconftool-lossage.patch
  delete mode 100644 
 meta/recipes-gnome/gnome/gnome-vfs-2.24.4/gnome-vfs-no-kerberos.patch
  delete mode 100644 meta/recipes-gnome/gnome/gnome-vfs_2.24.4.bb
 
 
 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

-- 
best rgds,
edwin

___
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] remove gnome-vfs completely

2011-09-27 Thread Paul Eggleton

On Tuesday 27 September 2011 15:02:24 Zhai, Edwin wrote:
 BTW,
 I found many recipes in meta-demoapps are not maintained: no
 LIC_FILES_CHKSUM/SRCREV, no workable SRC_URI, and even no layer.conf under
 meta-demoapps.
 
 We need more test for demoapps, and require each commit to take care of
 them, or else remove them completely...

My personal opinion as far as OE-core is concerned is that the whole of meta-
demoapps should be removed; perhaps the recipes within it can be provided in 
another layer (which we can then use within the Yocto project if desired) but 
they do not belong in OE-core IMHO.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

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

Re: [OE-core] [PATCH 1/1] gnome-vfs: remove this obsolete recipe completely in favor of GIO/GVFS


On 09/27/2011 06:49 AM, edwin.z...@intel.com wrote:

From: Zhai Edwinedwin.z...@intel.com

Remove oprofileui/libgsf's dependence on gnome-vfs, delete table that is out of
maintenance in clutter.


Can you please split this in to 4 separate patches so that we might 
cherry-pick the oprofileui change for 1.1.


Ideally, this would be a clutter/table patch, gnome-vfs patch, libgsf 
and oprofile


Thanks
Sau!



Signed-off-by: Zhai Edwinedwin.z...@intel.com
---
  .../recipes-gnome/libgsf/libgsf_1.14.5.bb  |8 ++-
  meta-demoapps/recipes-graphics/clutter/table.inc   |   13 -
  .../recipes-graphics/clutter/table/fixes.patch |   16 --
  .../recipes-graphics/clutter/table_git.bb  |   15 --
  .../conf/distro/include/distro_tracking_fields.inc |   11 
  meta/conf/multilib.conf|1 -
  .../gnome/gnome-vfs-2.24.4/gconftool-lossage.patch |   13 -
  .../gnome-vfs-2.24.4/gnome-vfs-no-kerberos.patch   |   53 
  meta/recipes-gnome/gnome/gnome-vfs_2.24.4.bb   |   50 --
  meta/recipes-kernel/oprofile/oprofileui.inc|2 +-
  10 files changed, 7 insertions(+), 175 deletions(-)
  delete mode 100644 meta-demoapps/recipes-graphics/clutter/table.inc
  delete mode 100644 meta-demoapps/recipes-graphics/clutter/table/fixes.patch
  delete mode 100644 meta-demoapps/recipes-graphics/clutter/table_git.bb
  delete mode 100644 
meta/recipes-gnome/gnome/gnome-vfs-2.24.4/gconftool-lossage.patch
  delete mode 100644 
meta/recipes-gnome/gnome/gnome-vfs-2.24.4/gnome-vfs-no-kerberos.patch
  delete mode 100644 meta/recipes-gnome/gnome/gnome-vfs_2.24.4.bb

diff --git a/meta-demoapps/recipes-gnome/libgsf/libgsf_1.14.5.bb 
b/meta-demoapps/recipes-gnome/libgsf/libgsf_1.14.5.bb
index 3ac7d6e..bf1b1ad 100644
--- a/meta-demoapps/recipes-gnome/libgsf/libgsf_1.14.5.bb
+++ b/meta-demoapps/recipes-gnome/libgsf/libgsf_1.14.5.bb
@@ -1,10 +1,14 @@
  DESCRIPTION = GNOME Structured File Library
  LICENSE = GPL
  SECTION = libs
-PR = r1
+PR = r2
+
+LIC_FILES_CHKSUM = file://COPYING;md5=dc7371b50816c96e145fa0f8ade8e24d \
+file://COPYING.LIB;md5=61464cfe342798eeced82efe9ae55f63 \
+
file://gsf/gsf.h;endline=25;md5=15cf6d31ad023167779ab5f0bbb76f49

  DEPENDS= libxml2 bzip2 glib-2.0 zlib
-RDEPENDS_${PN} = gconf gnome-vfs
+RDEPENDS_${PN} = gconf


  PACKAGES =+ ${PN}-gnome ${PN}-gnome-dev 
diff --git a/meta-demoapps/recipes-graphics/clutter/table.inc 
b/meta-demoapps/recipes-graphics/clutter/table.inc
deleted file mode 100644
index 937ad56..000
--- a/meta-demoapps/recipes-graphics/clutter/table.inc
+++ /dev/null
@@ -1,13 +0,0 @@
-DESCRIPTION = Table Clutter Demo
-HOMEPAGE = http://www.clutter-project.org/;
-LICENSE = LGPLv2.1  GPLv2
-
-DEPENDS = clutter-gst-1.4 gnome-vfs
-
-inherit autotools pkgconfig
-
-do_install() {
-   install -d ${D}${bindir}
-   install -m 0755 ${S}/table ${D}${bindir}/table
-}
-
diff --git a/meta-demoapps/recipes-graphics/clutter/table/fixes.patch 
b/meta-demoapps/recipes-graphics/clutter/table/fixes.patch
deleted file mode 100644
index 323bf13..000
--- a/meta-demoapps/recipes-graphics/clutter/table/fixes.patch
+++ /dev/null
@@ -1,16 +0,0 @@
-Upstream-Status: Pending
-
-Index: table/Makefile
-===
 table.orig/Makefile2007-07-10 13:24:18.0 +0100
-+++ table/Makefile 2007-07-10 13:28:10.0 +0100
-@@ -8,7 +8,7 @@ all: table
-
-
- table: table.o clutter-dominatrix.o clutter-video-player.o
--  $(CC) -g -Wall $(CFLAGS) -o $@ table.o clutter-dominatrix.o 
clutter-video-player.o $(LIBS)
-+  $(CC) -g -Wall $(CFLAGS) $(LDFLAGS) -o $@ table.o clutter-dominatrix.o 
clutter-video-player.o $(LIBS)
-
- clean:
-   rm -fr *.o table
-\ No newline at end of file
diff --git a/meta-demoapps/recipes-graphics/clutter/table_git.bb 
b/meta-demoapps/recipes-graphics/clutter/table_git.bb
deleted file mode 100644
index d0ae184..000
--- a/meta-demoapps/recipes-graphics/clutter/table_git.bb
+++ /dev/null
@@ -1,15 +0,0 @@
-require table.inc
-
-LIC_FILES_CHKSUM = file://fluttr/COPYING;md5=59530bdf33659b29e73d4adb9f9f6552 
\
-
file://script-viewer/COPYING;md5=7fbc338309ac38fefcd64b04bb903e34
-
-SRCREV = 4b267533ce16656cba4104fc39dc12709c1bdddf
-PV = 0.3.0+git${SRCPV}
-PR = r1
-
-SRC_URI = git://git.clutter-project.org/toys.git;protocol=git \
-   file://fixes.patch;patch=1
-
-S = ${WORKDIR}/git/table
-
-
diff --git a/meta/conf/distro/include/distro_tracking_fields.inc 
b/meta/conf/distro/include/distro_tracking_fields.inc
index c1f15e1..c08a1c8 100644
--- a/meta/conf/distro/include/distro_tracking_fields.inc
+++ b/meta/conf/distro/include/distro_tracking_fields.inc
@@ -4609,17 +4609,6 @@ RECIPE_COMMENTS_pn-libx11-trim = 
  RECIPE_LAST_UPDATE_pn-libx11-trim = Jul 9, 2010
  RECIPE_MAINTAINER_pn-libx11-trim = Dexuan Cuidexuan@intel.com

Re: [OE-core] [PATCH 0/1] remove gnome-vfs completely

2011-09-27 Thread Richard Purdie

On Tue, 2011-09-27 at 15:16 +0100, Paul Eggleton wrote:
 On Tuesday 27 September 2011 15:02:24 Zhai, Edwin wrote:
  BTW,
  I found many recipes in meta-demoapps are not maintained: no
  LIC_FILES_CHKSUM/SRCREV, no workable SRC_URI, and even no layer.conf under
  meta-demoapps.
  
  We need more test for demoapps, and require each commit to take care of
  them, or else remove them completely...
 
 My personal opinion as far as OE-core is concerned is that the whole of meta-
 demoapps should be removed; perhaps the recipes within it can be provided in 
 another layer (which we can then use within the Yocto project if desired) but 
 they do not belong in OE-core IMHO.

I agree it needs to become a separately layer and some of the components
there might be better in other locations.

Its something we meant to deal with later in the OE-Core development
cycle and basically forgot. Maybe someone could file an enhancement
bug? :)

First step would be to move it whole to its own layer repo.

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/1] remove gnome-vfs completely

2011-09-27 Thread Otavio Salvador

On Tue, Sep 27, 2011 at 13:19, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
...
 First step would be to move it whole to its own layer repo.

I think we can just remove them all and let the necessity tell us what
is really required.

-- 
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] Build Times and Performance - Discussion + new ideas

2011-09-27 Thread Richard Purdie

Every now and again I look at our build times and want to cry - we keep
taking longer with new features and whilst we have made many
improvements, I'm certain there are ways we can speed up. 

I've got some recent experiences to share with people. Its long and is
in the form of a story rather than a conclusion as I'd like people to
understand how I looked into the problem as well as the conclusion.

On Sunday my new build machine powered up. The exact specs aren't so
important but its built from shelf components and the end result is a
dual six core Xeon machine with 48GB RAM. Why is this a good idea when
most people don't have one of these on their desk (yet)? 

Several reasons. Firstly, it means I should be able to benchmark things
faster and test things faster. If I can speed builds up on this, they
should speed up for other systems too. Being able to iterate over
patches faster increases my productivity.

Secondly is the yet comment above. The trend for the future appears to
be for more cores so these machines will start appearing on people's
desks. It would be nice if when people do have them, the build system
can use their power.

Sadly, this is the first machine I've had where I've not been able to
max it out easily with OE/Poky. I hate not using the hardware so I see
this as a challenge :)

So the big question, where is our performance bottleneck?

People keep telling me we're disk IO bound. This was partly why I have a
machine with large amounts of memory, to either prove or disprove this
theory. My tests so far pretty clearly indicate this is not the problem.

I'm putting together some tips on build performance which I'm putting
on:

https://wiki.yoctoproject.org/wiki/Build_Performance

As detailed there I've setup a partition formatted with ext4 with no
journal, no barriers and most importantly a long commit time. The intent
here is to allow things to exist in memory and not block on disk IO.

My tests for a core-image-sato show the disk footprint (du -s tmp ) to
be about 26.9GB and my kernel disk cache is about 30.5GB after a build.
Allowing 3.6GB for the sources and system, its approximately right for a
totally cached build. My only question would be related to fsync() calls
during the build but I'm hoping there aren't too many of them. Certainly
we're not read bound.

I'm going to recheck the build time with a large tmpfs backed by swap
but looking at monitoring tools during the build so far I'm feeling disk
IO isn't our biggest problem. So what is?

As a marker stone, a build from scratch (prepopulated downloads) took:

NOTE: Tasks Summary: Attempted 4446 tasks of which 198 didn't need to be
rerun and 0 failed.

real53m6.377s
user295m55.850s
sys 52m20.720s


which for a system with this much power is pretty disappointing.
Watching the build, it unpacks most of the sources within the first few
minutes but takes an age to get the cross compiler established. We
aren't using all the cpu cores for a lot of that. The only times we do
are building qt (not in this test case) or the kernel.

I next had a look at bitbake gcc-cross-initial -g and bitbake
gcc-cross-initial -e | grep DEPENDS= which show we have a ton of
dependencies creeping in there. By the far the most problematic is
gettext-native.

There are some things in the system we don't autoreconf. By large I
encourage us to autoreconf but the exceptions are binutils, gcc and
glibc (I don't want to go into why here). Taking this as something we
aren't going to change, we can actually turn this to our advantage since
we don't need the gettext m4 macros to autoreconf and hence don't need
the gettext dependency if (and only if) we disable nls in binutils and
gcc.

Do we actually care about nls in binutils-cross and gcc-cross*? I'd say
not, especially since we always force the C locale anyway. Obviously fcc
and binutils themselves are different.

So I went on a spree of disabling nls for bitutils/gcc cross and all
their dependencies. 

While doing this I noticed that we can likely remove the help2man-native
dependency from many recipes. I'd really like to do this for all native
recipes and disable doc generation for the -native packages.

For now I came up with the hack below. The bugs in this are:

a) I removed bison-native and zlib-native from binutils-cross as 
   dependencies when they're needed. My system has those anyway so I'm 
   not worrying about this for a proof of concept
b) I've removed help2man-native dependencies but didn't check if any of 
   the recipes actually call help2man and need docs disabling
c) I excluded help2man in non -native cases for some recipes
d) I didn't disable nls and it dependencies for gcc-cross, only 
   -initial and -intermediate
e) I stopped analysing the dependency chain at gcc-cross-intermediate, 
   it would likely be faster again if I fixed gcc-cross' dependencies

At each step I was running the bitbake dependency graph for the next
item on the critical path and giving hard consideration to

[OE-core] Selectable linker (ld or gold) per recipe

2011-09-27 Thread Khem Raj

Hello

We have gold and ld available to us as linker alternatives. When
linking webkit with ld it takes 45 mins and grabs 2G of memory where
as with gold on same machine
it took 7 minutes. But then we can not use gold to link glibc and
kernel and may not work on all supported arches. So gold may not be a
complete replacement for ld. A good solution is that we make it
possible
to choose linker at compile time when building the application. gcc
does not have provisions to select linker on commandline although it
has configure
options to select default linker.

We can use two solutions

One where target-ld is a wrapper to ld.gold or ld.bfd and calls the
linker based on commandline options passed to it e.g
arm-oe-linux-gnueabi-ld -gold and arm-oe-linux-gnueabi-ld -bfd and
this option can be passed thru the compiler with -Wl and same wrapper
gets symlinked to the ld called by compiler driver if no option is
specified than bfd linker
is used


Second option is that we install both linkers and then add necessary
option to gcc to select the linker I have not explored this option but
it certainly would be useful

This can give us some base so we can select linker per recipe

Ideas ?

Thanks

-Khem

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

[OE-core] [RFH] package_setscene failing when using gitpkgv

2011-09-27 Thread Otavio Salvador

Hello,

We have some packages that use gitpkgv but protocol ssh ... for this
specific case we're seeing the building get stuck due ssh asking for
credentials.

After looking at why this happened we figured it was due the use of
pseudo but this is expected to be used for package_setscene however we
fail to see why git ls-remote is being ran when package_setscene is
called.

Anyone has a clue?

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

Re: [OE-core] Selectable linker (ld or gold) per recipe

2011-09-27 Thread Phil Blundell

On Tue, 2011-09-27 at 10:23 -0700, Khem Raj wrote:
 We have gold and ld available to us as linker alternatives. When
 linking webkit with ld it takes 45 mins and grabs 2G of memory where
 as with gold on same machine
 it took 7 minutes. But then we can not use gold to link glibc and
 kernel and may not work on all supported arches. So gold may not be a
 complete replacement for ld. A good solution is that we make it
 possible
 to choose linker at compile time when building the application. gcc
 does not have provisions to select linker on commandline although it
 has configure
 options to select default linker.

Are there any real-world scenarios where this is actually causing a
problem?  Glibc already has its own private compiler (i.e.
gcc-cross-initial) which it can configure any way it wishes, and the
kernel generally likes to call ld directly rather than via the gcc
driver.  So those two are basically a non-issue as far as gold is
concerned.  The thing about not working on all arches is also something
of an non-problem from this point of view, since if gold doesn't work on
a particular architecture (eg mips, I think) then there can't be any
question about which linker should be selected and specifying it
per-recipe would be pointless.

I'm not necessarily opposed to adding a wrapper to make the linker
selectable per recipe but it does rather seem to me that it's a solution
in search of a problem.  And, if it genuinely is a widespread problem I
would have rather thought that it ought to be tackled in consultation
with gcc upstream, otherwise they might go off and invent a different
mechanism for doing the same thing.

p.



___
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] [RFC] enable Pegasus touch screen

2011-09-27 Thread Tom Zanussi

On Mon, 2011-09-26 at 18:03 -0700, Zhai, Edwin wrote:
 From: Zhai Edwin edwin.z...@intel.com
 
 Tom,
 These changes, based on meta-intel/tzanussi/pegasus, are needed to enable
 eGalax touch screen on Pegasus. Could you pls. help to review?
 

Hi Edwin,

First, I don't think this is the correct list for meta-intel stuff,
please use the yocto list.

Anyway, the first two patches look ok to me, but the 3rd seems to be a
combination of what it says in the title, enabling touch screen kernel
config, and updating the BSP to work with the current kernel recipes.
The latter should I think be squashed into the base BSP, which isn't
posted.

 When will you push Pegasus changes into meta-intel/master? We can have a 
 common
 place for people to try pegasus...
 

The meta-pegasus you pointed to seems to be an old version, basically
the same prototype version I gave you for the demo.  I thought the
current one had been updated to address the comments from the quick
review of Aug 9:

- meta-pegasus - commented-out stuff in pegasus.conf, xorg.conf,
linux-yocto-2.6.37.bbappend, ReleaseNotes are unrelated to the BSP, etc.

Also, it has a blacksand.pdf and has old kernel recipes, etc.

Basically, it needs to be cleaned up a bit before it can be pulled in,
and should be buildable without relying on later patches.

Also, I'm wondering if there's a reason it's using 2.6.37 - we're at 3.0
now, and it would be good if it used that.

Finally, please also add yourself or whoever will be the maintainer
going forward to meta-intel/MAINTAINERS...

Thanks,

Tom

 Thanks,
 Edwin
 
 The following changes since commit 59dc67f6e64a836fc01fa91a1200e76264bb954d:
 
   meta-pegasus: new layer for Pegasus (N455) systems (2011-06-15 23:27:47 
 -0500)
 
 are available in the git repository at:
   git://git.pokylinux.org/poky-contrib gzhai/pegasus
   http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=gzhai/pegasus
 
 Zhai Edwin (3):
   eGalax touchscreen offical xorg driver
   Config xorg.conf with eGalax touchscreen input driver
   Enabled kernel module for eGalax touch screen.
 
  meta-pegasus/conf/machine/pegasus.conf |2 +-
  .../xf86-input-egalax/88eGalaxCalibrate.sh |5 ++
  .../xorg-driver/xf86-input-egalax_3.06.5605.bb |   49 
 
  .../xserver-xf86-config/pegasus/xorg.conf  |   10 
  .../xorg-xserver/xserver-xf86-config_0.1.bbappend  |2 +
  .../recipes-kernel/linux/linux-yocto/pegasus.cfg   |4 ++
  .../linux/linux-yocto_2.6.37.bbappend  |   12 +
  7 files changed, 83 insertions(+), 1 deletions(-)
  create mode 100755 
 meta-pegasus/recipes-graphics/xorg-driver/xf86-input-egalax/88eGalaxCalibrate.sh
  create mode 100644 
 meta-pegasus/recipes-graphics/xorg-driver/xf86-input-egalax_3.06.5605.bb
  create mode 100644 meta-pegasus/recipes-kernel/linux/linux-yocto/pegasus.cfg
  create mode 100644 
 meta-pegasus/recipes-kernel/linux/linux-yocto_2.6.37.bbappend
 



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

Re: [OE-core] [PATCH] Use useradd and update-rc.d classes in the OpenSSH recipe

2011-09-27 Thread Scott Garman

On 09/26/2011 05:47 PM, Julian Pidancet wrote:

On Tue, Sep 27, 2011 at 12:59 AM, Julian Pidancet
julian.pidan...@gmail.com wrote:

On Tue, Sep 27, 2011 at 12:38 AM, Saul Wolds...@linux.intel.com wrote:

Is there a reason you did not include the group and --disable-password here?

I think it would be good to leave thelong name options in also.

Sau!

The -U option creates a group with the same name. The
--disable-password option only exists with adduser and is default with
useradd -r.
I'd just like to point out that adduser is originally a perl script
from debian and reimplemented in busybox. The options it takes are not
compatible with the more standard useradd from the shadow package.

For some reason, some long options like --system (which is supposed to
be supported in useradd) did not work during my first
experimentations, but I will investigate and respin a patch with long
options if possible.

Also, I discovered that the following recipes still depends on adduser:
ppp-dialin, avahi, distcc, xserver-nodm-init, pulseaudio, hal, dbus

It would be good to use the useradd class with all of them.

In the shadow-sysroot package that we build to be able to use the
useradd class, we apply the add_root_cmd_options.patch to add the
--root option to useradd.

The --root option allows useradd to chroot somewhere so it can modify
/etc/passwd, but at the same time, it disables all the other long
options in the program.

It looks like it is impossible to use long options with the useradd
class. I don't know how straighforward it would be to modify this
patch to get the long options back. But is it worth the pain ?

Hi Julian,

Are you using the latest from oe-core master? I thought this patch from
Phil addressed this issue:

http://cgit.openembedded.org/cgit.cgi/openembedded-core/commit/?id=8fce8180c802ad187c4df44c17207bfb026ce6c7

Scott

--
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center

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

[OE-core] [PATCH 1/1] ghostscript: disable check for time.h

From: Joshua Lock joshual@takoba.(none)

ghostscript has it's own hacky check for time.h which hard-codes paths, this
means in the native case it fails on systems such as Ubuntu 11.10 where the
location of time.h has changed. Further it means the target build has had a
host-intrusion issue.

This patch disables the check for time.h, future releases of ghostscript
use standard autotools checks for time.h's location.

Signed-off-by: Joshua Lock j...@linux.intel.com
---
 .../ghostscript/ghostscript_9.02.bb|5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/meta/recipes-extended/ghostscript/ghostscript_9.02.bb 
b/meta/recipes-extended/ghostscript/ghostscript_9.02.bb
index 2e46734..9b21c66 100644
--- a/meta/recipes-extended/ghostscript/ghostscript_9.02.bb
+++ b/meta/recipes-extended/ghostscript/ghostscript_9.02.bb
@@ -36,6 +36,11 @@ SRC_URI[sha256sum] = 
03ea2cad13a36f8f9160912012b79619a826e7148fada6d3531feb2540
 
 EXTRA_OECONF = --without-x --with-system-libtiff --without-jbig2dec 
--without-jasper --with-fontpath=${datadir}/fonts
 
+# This has been fixed upstream but for now we need to subvert the check for 
time.h
+# http://bugs.ghostscript.com/show_bug.cgi?id=692443
+# http://bugs.ghostscript.com/show_bug.cgi?id=692426
+CFLAGS += -DHAVE_SYS_TIME_H=1
+
 inherit autotools
 
 do_configure () {
-- 
1.7.6.2


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

[OE-core] [PATCH 0/1] Fix building ghostcript variants on Ubuntu 11.10

Ubuntu 11.10 has moved sys/time.h such that the hard-coded test paths in
ghostscripts configuration scripts fails.

This patch works around that issue.

Regards,
Joshua

The following changes since commit 684a4b517d13884c315688967fadd5e6a4845b71:

  libffi: really populate -dev package (2011-09-26 20:50:27 +0100)

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

Joshua Lock (1):
  ghostscript: disable check for time.h

 .../ghostscript/ghostscript_9.02.bb|5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

-- 
1.7.6.2


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

[OE-core] [PATCH 2/2] Use useradd and update-rc.d classes in the OpenSSH recipe

2011-09-27 Thread Julian Pidancet

The current sshd postinst and postrm scripts in the OpenSSH make the
package dependant of the adduser/addgroup scripts which may not be
available on all systems.

This patch replaces the sshd postinst and postrm scripts with proper
usage of the useradd and update-rc.d classes.

This patch had been modified from the previous proposed version to
use useradd long options for more clarity.

Signed-off-by: Julian Pidancet julian.pidan...@gmail.com
---
 meta/recipes-connectivity/openssh/openssh_5.8p2.bb |   29 +--
 1 files changed, 8 insertions(+), 21 deletions(-)

diff --git a/meta/recipes-connectivity/openssh/openssh_5.8p2.bb 
b/meta/recipes-connectivity/openssh/openssh_5.8p2.bb
index 030a83b..5f5f0bc 100644
--- a/meta/recipes-connectivity/openssh/openssh_5.8p2.bb
+++ b/meta/recipes-connectivity/openssh/openssh_5.8p2.bb
@@ -29,6 +29,14 @@ PAM_SRC_URI = file://sshd
 SRC_URI[md5sum] = 0541579adf9d55abb15ef927048d372e
 SRC_URI[sha256sum] = 
5c35ec7c966ce05cc4497ac59c0b54a556e55ae7368165cc8c4129694654f314
 
+inherit useradd update-rc.d
+
+USERADD_PACKAGES = ${PN}-sshd
+USERADD_PARAM_${PN}-sshd = --system --no-create-home --home-dir /var/run/sshd 
--shell /bin/false --user-group sshd
+INITSCRIPT_PACKAGES = ${PN}-sshd
+INITSCRIPT_NAME_${PN}-sshd = sshd
+INITSCRIPT_PARAMS_${PN}-sshd = defaults 9
+
 inherit autotools
 
 # LFS support:
@@ -91,16 +99,6 @@ RDEPENDS_${PN} += ${PN}-scp ${PN}-ssh ${PN}-sshd 
${PN}-keygen
 DEPENDS_${PN}-sshd += update-rc.d
 RDEPENDS_${PN}-sshd += update-rc.d ${PN}-keygen
 
-pkg_postinst_${PN}-sshd () {
-   if [ x$D != x ]; then
-   exit 1
-   else
-   addgroup sshd
-   adduser --system --home /var/run/sshd --no-create-home 
--disabled-password --ingroup sshd -s /bin/false sshd
-   update-rc.d sshd defaults 9
-   fi
-}
-
 pkg_postinst_${PN}-scp () {
update-alternatives --install ${bindir}/scp scp scp.${PN} 90
 }
@@ -117,16 +115,5 @@ pkg_postrm_${PN}-scp () {
update-alternatives --remove ${bindir}/scp scp.${PN}
 }
 
-pkg_postrm_${PN}-sshd () {
-   if [ x$D != x ]; then
-   exit 1
-   else
-   ${sysconfdir}/init.d/sshd stop
-   deluser sshd
-   delgroup sshd
-   update-rc.d -f sshd remove
-   fi
-}
-
 CONFFILES_${PN}-sshd = ${sysconfdir}/ssh/sshd_config
 CONFFILES_${PN}-ssh = ${sysconfdir}/ssh/ssh_config
-- 
1.7.3.4


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

[OE-core] [RFC PATCH 1/1] texinfo: fix build on Ubuntu Oneiric

Calling the missing script with the help2man program argument fails for some
output targets on Ubuntu Oneiric.

Reading the help of missing I see that the help2man program value just touches
the output file - therefore this patch touches the three problematic files
in do_install_prepend.

Signed-off-by: Joshua Lock j...@linux.intel.com
---
 meta/recipes-extended/texinfo/texinfo_4.13a.bb |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/meta/recipes-extended/texinfo/texinfo_4.13a.bb 
b/meta/recipes-extended/texinfo/texinfo_4.13a.bb
index 9f1c04a..8864d7c 100644
--- a/meta/recipes-extended/texinfo/texinfo_4.13a.bb
+++ b/meta/recipes-extended/texinfo/texinfo_4.13a.bb
@@ -33,6 +33,9 @@ do_compile_prepend() {
if [ -d tools ];then
oe_runmake -C tools/gnulib/lib
fi
+   touch ${S}/doc/texi2pdf.1
+   touch ${S}/doc/info.1
+   touch ${S}/doc/install-info.1
 }
 
 do_install_append() {
-- 
1.7.6.2


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

[OE-core] [RFC PATCH 0/1] Fix texinfo build on Ubuntu Oneiric

Texinfo fails to build on Ubuntu 11.10, but not any of my other systesm,
the following patch resolves this in what feels like a harmless way.

Any comments?

Regards,
Joshua

The following changes since commit 684a4b517d13884c315688967fadd5e6a4845b71:

  libffi: really populate -dev package (2011-09-26 20:50:27 +0100)

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

Joshua Lock (1):
  texinfo: fix build on Ubuntu Oneiric

 meta/recipes-extended/texinfo/texinfo_4.13a.bb |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

-- 
1.7.6.2


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

Re: [OE-core] [PATCH 3/4] eglibc: Add recipes for 2.14

2011-09-27 Thread Khem Raj

On Tue, Sep 27, 2011 at 4:07 PM, Saul Wold saul.w...@intel.com wrote:
 On 09/26/2011 08:39 PM, Khem Raj wrote:

 Backport Fedora patch to enable sunrpc as it was in 2.13
 Fix cross-localedef-native to be able to build from eglibc 2.14 branch

 Tested builds/boot of angstrom/console-image on qemu for
 arm,mips,ppc,i386,x86_64

 Signed-off-by: Khem Rajraj.k...@gmail.com
 ---
  .../eglibc/cross-localedef-native_2.14.bb          |   44 ++
  .../eglibc/eglibc-2.14/IO-acquire-lock-fix.patch   |   17 +
  .../eglibc-2.14/armv4-eabi-compile-fix.patch       |   25 +
  .../eglibc-2.14/eglibc-rpc-export-again.patch      |   69 +++
  .../eglibc-svn-arm-lowlevellock-include-tls.patch  |   21 +
  .../eglibc/eglibc-2.14/generate-supported.mk       |   11 +
  .../eglibc/eglibc-2.14/ld-search-order.patch       |   56 ++
  .../eglibc/eglibc-2.14/mips-rld-map-check.patch    |   26 +
  .../eglibc/eglibc-2.14/multilib_readlib.patch      |   17 +
  .../recipes-core/eglibc/eglibc-2.14/ppc-sqrt.patch |  538
 
  .../eglibc-2.14/shorten-build-commands.patch       |   82 +++
  .../eglibc/eglibc-2.14/stack-protector-test.patch  |   35 ++
  meta/recipes-core/eglibc/eglibc-initial_2.14.bb    |    6 +
  meta/recipes-core/eglibc/eglibc-locale_2.14.bb     |    1 +
  meta/recipes-core/eglibc/eglibc_2.14.bb            |  219 
  15 files changed, 1167 insertions(+), 0 deletions(-)
  create mode 100644
 meta/recipes-core/eglibc/cross-localedef-native_2.14.bb
  create mode 100644
 meta/recipes-core/eglibc/eglibc-2.14/IO-acquire-lock-fix.patch
  create mode 100644
 meta/recipes-core/eglibc/eglibc-2.14/armv4-eabi-compile-fix.patch
  create mode 100644
 meta/recipes-core/eglibc/eglibc-2.14/eglibc-rpc-export-again.patch
  create mode 100644
 meta/recipes-core/eglibc/eglibc-2.14/eglibc-svn-arm-lowlevellock-include-tls.patch
  create mode 100644 meta/recipes-core/eglibc/eglibc-2.14/etc/ld.so.conf
  create mode 100644
 meta/recipes-core/eglibc/eglibc-2.14/generate-supported.mk
  create mode 100644
 meta/recipes-core/eglibc/eglibc-2.14/ld-search-order.patch
  create mode 100644
 meta/recipes-core/eglibc/eglibc-2.14/mips-rld-map-check.patch
  create mode 100644
 meta/recipes-core/eglibc/eglibc-2.14/multilib_readlib.patch
  create mode 100644 meta/recipes-core/eglibc/eglibc-2.14/ppc-sqrt.patch
  create mode 100644
 meta/recipes-core/eglibc/eglibc-2.14/shorten-build-commands.patch
  create mode 100644
 meta/recipes-core/eglibc/eglibc-2.14/stack-protector-test.patch
  create mode 100644 meta/recipes-core/eglibc/eglibc-initial_2.14.bb
  create mode 100644 meta/recipes-core/eglibc/eglibc-locale_2.14.bb
  create mode 100644 meta/recipes-core/eglibc/eglibc_2.14.bb


 Khem,

 This one seems to have had a problem on mips, when I built it on the
 Autobuilder, I get the following failure:
 checking for ld --version-script... no
 | *** WARNING: You should not compile GNU libc without versioning. Not using
 | *** versioning will introduce incompatibilities so that old binaries
 | *** will not run anymore.
 | *** For versioning you need recent binutils (binutils-2.8.1.0.23 or
 newer).
 | checking for .previous assembler directive... yes
 | checking for .protected and .hidden assembler directive... yes
 | checking whether __attribute__((visibility())) is supported... yes
 | checking for broken __attribute__((visibility()))... no
 | checking for broken __attribute__((alias()))... no
 | checking whethERROR: Function 'do_configure' failed (see
 /srv/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-mips/build/build/tmp/work/mips-poky-linux/eglibc-2.13-r17+svnr14157/temp/log.do_configure.1476

this here tells me that its compiling eglibc 2.13 not 2.14
did you change EGLIBCVERSION to 2.14 in
meta/conf/distro/include/tcmode-default.inc ?

I have been building angstrom/systemd-gnome-image with all the patches
I posted on that branch
for all architectures without any failures.

 for further information)
 | er to put _rtld_local into .sdata section... yes
 | checking for .preinit_array/.init_array/.fini_array support... no
 | configure: error: Need linker with .init_array/.fini_array support.
 | ERROR: oe_runconf failed

 You can see this at:
 http://autobuilder.yoctoproject.org:8010/builders/nightly-mips/builds/88/steps/shell_42/logs/stdio

 Sau!







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

Re: [OE-core] [PATCH 3/4] eglibc: Add recipes for 2.14


On 09/27/2011 05:17 PM, Khem Raj wrote:

On Tue, Sep 27, 2011 at 4:07 PM, Saul Woldsaul.w...@intel.com  wrote:

On 09/26/2011 08:39 PM, Khem Raj wrote:


Backport Fedora patch to enable sunrpc as it was in 2.13
Fix cross-localedef-native to be able to build from eglibc 2.14 branch

Tested builds/boot of angstrom/console-image on qemu for
arm,mips,ppc,i386,x86_64

Signed-off-by: Khem Rajraj.k...@gmail.com
---
  .../eglibc/cross-localedef-native_2.14.bb  |   44 ++
  .../eglibc/eglibc-2.14/IO-acquire-lock-fix.patch   |   17 +
  .../eglibc-2.14/armv4-eabi-compile-fix.patch   |   25 +
  .../eglibc-2.14/eglibc-rpc-export-again.patch  |   69 +++
  .../eglibc-svn-arm-lowlevellock-include-tls.patch  |   21 +
  .../eglibc/eglibc-2.14/generate-supported.mk   |   11 +
  .../eglibc/eglibc-2.14/ld-search-order.patch   |   56 ++
  .../eglibc/eglibc-2.14/mips-rld-map-check.patch|   26 +
  .../eglibc/eglibc-2.14/multilib_readlib.patch  |   17 +
  .../recipes-core/eglibc/eglibc-2.14/ppc-sqrt.patch |  538

  .../eglibc-2.14/shorten-build-commands.patch   |   82 +++
  .../eglibc/eglibc-2.14/stack-protector-test.patch  |   35 ++
  meta/recipes-core/eglibc/eglibc-initial_2.14.bb|6 +
  meta/recipes-core/eglibc/eglibc-locale_2.14.bb |1 +
  meta/recipes-core/eglibc/eglibc_2.14.bb|  219 
  15 files changed, 1167 insertions(+), 0 deletions(-)
  create mode 100644
meta/recipes-core/eglibc/cross-localedef-native_2.14.bb
  create mode 100644
meta/recipes-core/eglibc/eglibc-2.14/IO-acquire-lock-fix.patch
  create mode 100644
meta/recipes-core/eglibc/eglibc-2.14/armv4-eabi-compile-fix.patch
  create mode 100644
meta/recipes-core/eglibc/eglibc-2.14/eglibc-rpc-export-again.patch
  create mode 100644
meta/recipes-core/eglibc/eglibc-2.14/eglibc-svn-arm-lowlevellock-include-tls.patch
  create mode 100644 meta/recipes-core/eglibc/eglibc-2.14/etc/ld.so.conf
  create mode 100644
meta/recipes-core/eglibc/eglibc-2.14/generate-supported.mk
  create mode 100644
meta/recipes-core/eglibc/eglibc-2.14/ld-search-order.patch
  create mode 100644
meta/recipes-core/eglibc/eglibc-2.14/mips-rld-map-check.patch
  create mode 100644
meta/recipes-core/eglibc/eglibc-2.14/multilib_readlib.patch
  create mode 100644 meta/recipes-core/eglibc/eglibc-2.14/ppc-sqrt.patch
  create mode 100644
meta/recipes-core/eglibc/eglibc-2.14/shorten-build-commands.patch
  create mode 100644
meta/recipes-core/eglibc/eglibc-2.14/stack-protector-test.patch
  create mode 100644 meta/recipes-core/eglibc/eglibc-initial_2.14.bb
  create mode 100644 meta/recipes-core/eglibc/eglibc-locale_2.14.bb
  create mode 100644 meta/recipes-core/eglibc/eglibc_2.14.bb



Khem,

This one seems to have had a problem on mips, when I built it on the
Autobuilder, I get the following failure:
checking for ld --version-script... no
| *** WARNING: You should not compile GNU libc without versioning. Not using
| *** versioning will introduce incompatibilities so that old binaries
| *** will not run anymore.
| *** For versioning you need recent binutils (binutils-2.8.1.0.23 or
newer).
| checking for .previous assembler directive... yes
| checking for .protected and .hidden assembler directive... yes
| checking whether __attribute__((visibility())) is supported... yes
| checking for broken __attribute__((visibility()))... no
| checking for broken __attribute__((alias()))... no
| checking whethERROR: Function 'do_configure' failed (see
/srv/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-mips/build/build/tmp/work/mips-poky-linux/eglibc-2.13-r17+svnr14157/temp/log.do_configure.1476


this here tells me that its compiling eglibc 2.13 not 2.14
did you change EGLIBCVERSION to 2.14 in
meta/conf/distro/include/tcmode-default.inc ?

Nope, that might be my problem, so something is getting hosed around for 
mips because everything else is building OK.  Maybe it's one of the 
compiler changes or does that need tcmode changes also?


Sau!



I have been building angstrom/systemd-gnome-image with all the patches
I posted on that branch
for all architectures without any failures.


for further information)
| er to put _rtld_local into .sdata section... yes
| checking for .preinit_array/.init_array/.fini_array support... no
| configure: error: Need linker with .init_array/.fini_array support.
| ERROR: oe_runconf failed

You can see this at:
http://autobuilder.yoctoproject.org:8010/builders/nightly-mips/builds/88/steps/shell_42/logs/stdio

Sau!









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

[OE-core] [PATCH 1/5] multilib.bbclass: map RDEPENDS and LINGUAS_INSTALL for image recipes

RDEPENDS of image type recipe needs to be mapped to make sure that the
packages included in the image should be multilib version.

Also add LINGUAS_INSTALL into MULTILIB_PACKAGE_INSTALL list.

[YOCTO #1496]
[YOCTO #1527]

Signed-off-by: Dongxiao Xu dongxiao...@intel.com
---
 meta/classes/multilib.bbclass |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/meta/classes/multilib.bbclass b/meta/classes/multilib.bbclass
index 98f6911..0ea1038 100644
--- a/meta/classes/multilib.bbclass
+++ b/meta/classes/multilib.bbclass
@@ -54,9 +54,12 @@ python __anonymous () {
 
 if bb.data.inherits_class('image', d):
 map_dependencies(PACKAGE_INSTALL, d)
-pinstall = d.getVar(PACKAGE_INSTALL, True) +   + 
d.getVar(MULTILIB_PACKAGE_INSTALL, False)
+map_dependencies(LINGUAS_INSTALL, d)
+map_dependencies(RDEPENDS, d)
+pinstall = d.getVar(LINGUAS_INSTALL, True) +   + 
d.getVar(PACKAGE_INSTALL, True) +   + d.getVar(MULTILIB_PACKAGE_INSTALL, 
False)
 d.setVar(MULTILIB_PACKAGE_INSTALL, pinstall)
 d.setVar(PACKAGE_INSTALL, )
+d.setVar(LINGUAS_INSTALL, )
 # FIXME, we need to map this to something, not delete it!
 d.setVar(PACKAGE_INSTALL_ATTEMPTONLY, )
 return
-- 
1.7.1


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

[OE-core] [PATCH 2/5] multilib: remove the multilib handling to allarch

currently we have allarch type of recipes, which may still have
architecture dependency, like x11-common. So we need to drop the
handling to allarch in multilib case.

Also remove the PV postfix in python-pygobject DEPENDS, since multilib
code will treat a native package multilib capable.

[YOCTO #1497]
[YOCTO #1498]

Signed-off-by: Dongxiao Xu dongxiao...@intel.com
---
 meta/classes/multilib.bbclass  |2 +-
 meta/classes/multilib_global.bbclass   |2 +-
 meta/conf/multilib.conf|7 +++
 .../python/python-pygobject_2.27.91.bb |2 +-
 4 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/meta/classes/multilib.bbclass b/meta/classes/multilib.bbclass
index 0ea1038..6c0dd37 100644
--- a/meta/classes/multilib.bbclass
+++ b/meta/classes/multilib.bbclass
@@ -8,7 +8,7 @@ python multilib_virtclass_handler () {
 return
 
 # There should only be one kernel in multilib configs
-if bb.data.inherits_class('kernel', e.data) or 
bb.data.inherits_class('module-base', e.data) or 
bb.data.inherits_class('allarch', e.data):
+if bb.data.inherits_class('kernel', e.data) or 
bb.data.inherits_class('module-base', e.data):
 raise bb.parse.SkipPackage(We shouldn't have multilib variants for 
the kernel)
 
 if bb.data.inherits_class('image', e.data):
diff --git a/meta/classes/multilib_global.bbclass 
b/meta/classes/multilib_global.bbclass
index cd22163..2da66a5 100644
--- a/meta/classes/multilib_global.bbclass
+++ b/meta/classes/multilib_global.bbclass
@@ -5,7 +5,7 @@ python multilib_virtclass_handler_global () {
 variant = e.data.getVar(BBEXTENDVARIANT, True)
 
 if isinstance(e, bb.event.RecipeParsed) and not variant:
-if bb.data.inherits_class('kernel', e.data) or 
bb.data.inherits_class('module-base', e.data) or 
bb.data.inherits_class('allarch', e.data):
+if bb.data.inherits_class('kernel', e.data) or 
bb.data.inherits_class('module-base', e.data):
 variants = (e.data.getVar(MULTILIB_VARIANTS, True) or ).split()
 
 # Process PROVIDES
diff --git a/meta/conf/multilib.conf b/meta/conf/multilib.conf
index 3133bf1..b9da33a 100644
--- a/meta/conf/multilib.conf
+++ b/meta/conf/multilib.conf
@@ -452,3 +452,10 @@ BBCLASSEXTEND_append_pn-zip =  ${MULTILIBS}
 BBCLASSEXTEND_append_pn-zlib =  ${MULTILIBS}
 BBCLASSEXTEND_append_pn-zypper =  ${MULTILIBS}
 BBCLASSEXTEND_append_pn-libsdl =  ${MULTILIBS}
+BBCLASSEXTEND_append_pn-qemu-config =  ${MULTILIBS}
+BBCLASSEXTEND_append_pn-x11-common =  ${MULTILIBS}
+BBCLASSEXTEND_append_pn-update-rc.d =  ${MULTILIBS}
+BBCLASSEXTEND_append_pn-avahi-ui =  ${MULTILIBS}
+BBCLASSEXTEND_append_pn-python-pycairo =  ${MULTILIBS}
+BBCLASSEXTEND_append_pn-python-pygtk =  ${MULTILIBS}
+BBCLASSEXTEND_append_pn-python-pygobject =  ${MULTILIBS}
diff --git a/meta/recipes-devtools/python/python-pygobject_2.27.91.bb 
b/meta/recipes-devtools/python/python-pygobject_2.27.91.bb
index 9ff2fe7..fd696a5 100644
--- a/meta/recipes-devtools/python/python-pygobject_2.27.91.bb
+++ b/meta/recipes-devtools/python/python-pygobject_2.27.91.bb
@@ -2,7 +2,7 @@ DESCRIPTION = Python GObject bindings
 SECTION = devel/python
 LICENSE = LGPLv2.1
 LIC_FILES_CHKSUM = file://COPYING;md5=a916467b91076e631dd8edb7424769c7
-DEPENDS = python python-pygobject-native-${PV} glib-2.0
+DEPENDS = python python-pygobject-native glib-2.0
 DEPENDS_virtclass-native = glib-2.0-native
 RDEPENDS_virtclass-native = 
 PR = r2
-- 
1.7.1


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

[OE-core] [PATCH 0/5][PULL] multilib: bug fixes related with RPM backend

Hi Richard,

This pull request is to fix several multilib bugs related with RPM backend,
please help to review and pull.

I've done a round of multilib testing agasint:
 - lib32 sato image on qemux86 machine
 - lib32 sato image on qemux86-64 machine
 - lib64 sato image on qemux86-64 machine
 - lib64 sato image on qemux86 machine
 - sato image on qemux86-64 with several lib32 packages (lib32-connman)

All the above test cases can pass the build and most can successfully boot up
(except for the lib64 on qemux86).

Therefore the following bugs could be addressed:

[YOCTO #1496]
[YOCTO #1497]
[YOCTO #1498]
[YOCTO #1527]

Thanks,
Dongxiao

The following changes since commit 684a4b517d13884c315688967fadd5e6a4845b71:

  libffi: really populate -dev package (2011-09-26 20:50:27 +0100)

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

Dongxiao Xu (5):
  multilib.bbclass: map RDEPENDS and LINGUAS_INSTALL for image recipes
  multilib: remove the multilib handling to allarch
  multilib: add MLPREFIX to deploy folder
  tune-i586: fix hardcoded TUNE_PKGARCH
  package_rpm: combine normal and multilib solution manifest together

 meta/classes/multilib.bbclass  |   12 +---
 meta/classes/multilib_global.bbclass   |2 +-
 meta/classes/package_rpm.bbclass   |   15 +++
 meta/classes/rootfs_rpm.bbclass|2 +-
 meta/conf/machine/include/tune-i586.inc|3 ++-
 meta/conf/multilib.conf|7 +++
 .../python/python-pygobject_2.27.91.bb |2 +-
 7 files changed, 28 insertions(+), 15 deletions(-)


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

[OE-core] [PATCH 5/5] package_rpm: combine normal and multilib solution manifest together

When RPM does the real install, if the first manifest file is empty, the
installation will stop without handling the second manifest file.

Merge the two manifest files together to fix this issue.

Signed-off-by: Dongxiao Xu dongxiao...@intel.com
---
 meta/classes/package_rpm.bbclass |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass
index 45de0f8..fa0d8c3 100644
--- a/meta/classes/package_rpm.bbclass
+++ b/meta/classes/package_rpm.bbclass
@@ -395,6 +395,8 @@ package_install_internal_rpm () {
-D __dbi_txn create nofsync private \
| grep -i 'Packageorigin' | cut -d : -f 2  
${target_rootfs}/install/install_multilib_solution.manifest
 
+   cat ${target_rootfs}/install/install_solution.manifest  
${target_rootfs}/install/total_solution.manifest
+   cat ${target_rootfs}/install/install_multilib_solution.manifest  
${target_rootfs}/install/total_solution.manifest
 
# Attempt install
${RPM} --root ${target_rootfs} \
@@ -403,8 +405,7 @@ package_install_internal_rpm () {
-D _dbpath ${rpmlibdir} \
--noscripts --notriggers --noparentdirs --nolinktos 
--replacepkgs \
-D __dbi_txn create nofsync private \
-   -Uhv ${target_rootfs}/install/install_solution.manifest \
-   ${target_rootfs}/install/install_multilib_solution.manifest
+   -Uhv ${target_rootfs}/install/total_solution.manifest
 }
 
 python write_specfile () {
-- 
1.7.1


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

[OE-core] [PATCH 3/5] multilib: add MLPREFIX to deploy folder

Add MLPREFIX to multilib deploy forlder to avoid the confliction between
multilib and normal package deploy directory.

Signed-off-by: Dongxiao Xu dongxiao...@intel.com
---
 meta/classes/multilib.bbclass|5 -
 meta/classes/package_rpm.bbclass |   10 --
 meta/classes/rootfs_rpm.bbclass  |2 +-
 3 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/meta/classes/multilib.bbclass b/meta/classes/multilib.bbclass
index 6c0dd37..1aed2a9 100644
--- a/meta/classes/multilib.bbclass
+++ b/meta/classes/multilib.bbclass
@@ -92,9 +92,4 @@ python __anonymous () {
 multilib_map_variable(PACKAGES_DYNAMIC, variant, d)
 multilib_map_variable(PACKAGE_INSTALL, variant, d)
 multilib_map_variable(INITSCRIPT_PACKAGES, variant, d)
-
-package_arch = d.getVar(PACKAGE_ARCH, True)
-machine_arch = d.getVar(MACHINE_ARCH, True)
-if package_arch == machine_arch:
-d.setVar(PACKAGE_ARCH, variant + _ + package_arch)
 }
diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass
index 775d525..45de0f8 100644
--- a/meta/classes/package_rpm.bbclass
+++ b/meta/classes/package_rpm.bbclass
@@ -903,8 +903,14 @@ python do_package_rpm () {
rpmbuild = bb.data.getVar('RPMBUILD', d, True)
targetsys = bb.data.getVar('TARGET_SYS', d, True)
targetvendor = bb.data.getVar('TARGET_VENDOR', d, True)
-   pkgwritedir = bb.data.expand('${PKGWRITEDIRRPM}/${PACKAGE_ARCH}', d)
-   pkgarch = 
bb.data.expand('${PACKAGE_ARCH}${TARGET_VENDOR}-${TARGET_OS}', d)
+   package_arch = bb.data.getVar('PACKAGE_ARCH', d, True) or 
+   if package_arch not in all any noarch.split():
+   ml_prefix = (bb.data.getVar('MLPREFIX', d, True) or 
).replace(-, _)
+   bb.data.setVar('PACKAGE_ARCH_EXTEND', ml_prefix + package_arch, 
d)
+   else:
+   bb.data.setVar('PACKAGE_ARCH_EXTEND', package_arch, d)
+   pkgwritedir = 
bb.data.expand('${PKGWRITEDIRRPM}/${PACKAGE_ARCH_EXTEND}', d)
+   pkgarch = 
bb.data.expand('${PACKAGE_ARCH_EXTEND}${TARGET_VENDOR}-${TARGET_OS}', d)
magicfile = 
bb.data.expand('${STAGING_DIR_NATIVE}/usr/share/misc/magic.mgc', d)
bb.mkdirhier(pkgwritedir)
os.chmod(pkgwritedir, 0755)
diff --git a/meta/classes/rootfs_rpm.bbclass b/meta/classes/rootfs_rpm.bbclass
index 5ac6bca..dd370b2 100644
--- a/meta/classes/rootfs_rpm.bbclass
+++ b/meta/classes/rootfs_rpm.bbclass
@@ -220,8 +220,8 @@ python () {
 default_tune = localdata.getVar(DEFAULTTUNE_virtclass-multilib- 
+ eext[1], False)
 if default_tune:
 localdata.setVar(DEFAULTTUNE, default_tune)
-localdata.setVar(MACHINE_ARCH, eext[1] + _ + 
localdata.getVar(MACHINE_ARCH, False))
 package_archs = localdata.getVar(PACKAGE_ARCHS, True) or 
+package_archs =  .join([i in all noarch any.split() and i or 
eext[1]+_+i for i in package_archs.split()])
 ml_package_archs +=   + package_archs
 ml_prefix_list +=   + eext[1]
 #bb.note(ML_PACKAGE_ARCHS %s %s %s % (eext[1], 
localdata.getVar(PACKAGE_ARCHS, True) or (none), overrides))
-- 
1.7.1


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

[OE-core] [PATCH 4/5] tune-i586: fix hardcoded TUNE_PKGARCH

Use TUNE_FEATURES to determine the setting to TUNE_PKGARCH, which fixes
the wrong setting of PACKAGE_ARCH in multilib case.

Signed-off-by: Dongxiao Xu dongxiao...@intel.com
---
 meta/conf/machine/include/tune-i586.inc |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/meta/conf/machine/include/tune-i586.inc 
b/meta/conf/machine/include/tune-i586.inc
index ba655b9..a40ce18 100644
--- a/meta/conf/machine/include/tune-i586.inc
+++ b/meta/conf/machine/include/tune-i586.inc
@@ -1,5 +1,6 @@
 DEFAULTTUNE ?= i586
-TUNE_PKGARCH ?= i586
+TUNE_PKGARCH_TMP = ${@bb.utils.contains(TUNE_FEATURES, m32, x86, 
x86_64, d)}
+TUNE_PKGARCH ?= ${@bb.utils.contains(TUNE_FEATURES, i586, i586, 
TUNE_PKGARCH_TMP, d)}
 
 require conf/machine/include/ia32/arch-ia32.inc
 
-- 
1.7.1


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

[OE-core] [PATCH 2/3] zypper sat-solver: needs RDEPENDS on rpm-lib

Signed-off-by: Saul Wold s...@linux.intel.com
---
 meta/recipes-extended/libzypp/libzypp_git.bb   |8 
 meta/recipes-extended/sat-solver/sat-solver_git.bb |4 +++-
 meta/recipes-extended/zypper/zypper_git.bb |6 --
 3 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/meta/recipes-extended/libzypp/libzypp_git.bb 
b/meta/recipes-extended/libzypp/libzypp_git.bb
index 4b1b8e4..7d9382a 100644
--- a/meta/recipes-extended/libzypp/libzypp_git.bb
+++ b/meta/recipes-extended/libzypp/libzypp_git.bb
@@ -8,13 +8,10 @@ inherit cmake gettext
 
 DEPENDS  = rpm boost curl libxml2 zlib sat-solver expat openssl udev
 
-# rpmdb2solv from sat-solver is run from libzypp
-RDEPENDS_${PN} = sat-solver
-
 S = ${WORKDIR}/git
 SRCREV = 15b6c52260bbc52b3d8e585e271b67e10cc7c433
 PV = 0.0-git${SRCPV}
-PR = r14
+PR = r15
 
 SRC_URI = git://github.com/openSUSE/libzypp.git;protocol=git \
file://no-doc.patch \
@@ -32,6 +29,9 @@ SRC_URI_append_mips =  
file://mips-workaround-gcc-tribool-error.patch
 # ARM specific global constructor workaround
 SRC_URI_append_arm  =  file://arm-workaround-global-constructor.patch
 
+# rpmdb2solv from sat-solver is run from libzypp
+RDEPENDS_${PN} = sat-solver rpm-libs
+
 PACKAGES =+ ${PN}-pkgmgt
 
 FILES_${PN} += ${libdir}/zypp ${datadir}/zypp ${datadir}/icons
diff --git a/meta/recipes-extended/sat-solver/sat-solver_git.bb 
b/meta/recipes-extended/sat-solver/sat-solver_git.bb
index 0d9a439..b616c57 100644
--- a/meta/recipes-extended/sat-solver/sat-solver_git.bb
+++ b/meta/recipes-extended/sat-solver/sat-solver_git.bb
@@ -8,7 +8,7 @@ DEPENDS = libcheck rpm zlib expat db
 
 SRCREV = 0a7378d5f482f477a01cf1690d76871ab8bdcc32
 PV = 0.0-git${SRCPV}
-PR = r11
+PR = r12
 
 PARALLEL_MAKE=
 
@@ -29,6 +29,8 @@ EXTRA_OECMAKE +=  -DLIB=${@os.path.basename('${libdir}')}
 
 inherit cmake pkgconfig
 
+RDEPENDS_${PN} = rpm-libs
+
 PACKAGE_ARCH = ${MACHINE_ARCH}
 
 do_archgen () {
diff --git a/meta/recipes-extended/zypper/zypper_git.bb 
b/meta/recipes-extended/zypper/zypper_git.bb
index 7f7ceb3..4f4fc4d 100644
--- a/meta/recipes-extended/zypper/zypper_git.bb
+++ b/meta/recipes-extended/zypper/zypper_git.bb
@@ -5,8 +5,7 @@ LICENSE  = GPLv2+
 LIC_FILES_CHKSUM = file://COPYING;md5=3201406e350b39e05a82e28b5020f413
 
 DEPENDS  = libzypp augeas
-RRECOMMENDS_${PN} = procps util-linux-uuidgen
-PR = r5
+PR = r6
 SRCREV = 2c5bb6ceb99ecd950ef993e43d77bf0569ea0582
 
 inherit cmake
@@ -20,4 +19,7 @@ S = ${WORKDIR}/git
 
 PV = 1.5.3-git${SRCPV}
 
+RDEPENDS_${PN} = rpm-libs
+RRECOMMENDS_${PN} = procps util-linux-uuidgen
+
 PACKAGE_ARCH = ${MACHINE_ARCH}
-- 
1.7.6


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

[OE-core] [PATCH 3/3] rpm: fix QA Warning on installed but not shipped staticdev filesw

Signed-off-by: Saul Wold s...@linux.intel.com
---
 meta/recipes-devtools/rpm/rpm_5.4.0.bb |   17 ++---
 1 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/meta/recipes-devtools/rpm/rpm_5.4.0.bb 
b/meta/recipes-devtools/rpm/rpm_5.4.0.bb
index 356512a..bbef0be 100644
--- a/meta/recipes-devtools/rpm/rpm_5.4.0.bb
+++ b/meta/recipes-devtools/rpm/rpm_5.4.0.bb
@@ -168,7 +168,7 @@ EXTRA_OECONF = --verbose \
 
 CFLAGS_append =  -DRPM_VENDOR_WINDRIVER -DRPM_VENDOR_POKY
 
-PACKAGES = ${PN}-dbg ${PN} ${PN}-doc ${PN}-libs ${PN}-dev ${PN}-common 
${PN}-build python-rpm-dbg python-rpm perl-module-rpm perl-module-rpm-dev 
${PN}-locale
+PACKAGES = ${PN}-dbg ${PN} ${PN}-doc ${PN}-libs ${PN}-dev ${PN}-staticdev 
${PN}-common ${PN}-build python-rpm-dbg python-rpm perl-module-rpm 
perl-module-rpm-dev ${PN}-locale
 
 SOLIBS = 5.4.so
 
@@ -304,27 +304,30 @@ FILES_perl-module-rpm-dev = 
${prefix}/share/man/man3/RPM* \

 
 FILE_${PN}-dev = ${includedir}/rpm \
-   ${libdir}/librpm.a \
${libdir}/librpm.la \
${libdir}/librpm.so \
-   ${libdir}/librpmconstant.a \
${libdir}/librpmconstant.la \
${libdir}/librpmconstant.so \
-   ${libdir}/librpmdb.a \
${libdir}/librpmdb.la \
${libdir}/librpmdb.so \
-   ${libdir}/librpmio.a \
${libdir}/librpmio.la \
${libdir}/librpmio.so \
-   ${libdir}/librpmmisc.a \
${libdir}/librpmmisc.la \
${libdir}/librpmmisc.so \
-   ${libdir}/librpmbuild.a \
${libdir}/librpmbuild.la \
${libdir}/librpmbuild.so \
${libdir}/pkgconfig/rpm.pc \

 
+FILE_${PN}-staticdev =  \
+   ${libdir}/librpm.a \
+   ${libdir}/librpmconstant.a \
+   ${libdir}/librpmdb.a \
+   ${libdir}/librpmio.a \
+   ${libdir}/librpmmisc.a \
+   ${libdir}/librpmbuild.a \
+   
+
 ###%{_rpmhome}/lib/libxar.a
 ###%{_rpmhome}/lib/libxar.la
 ###%{_rpmhome}/lib/libxar.so
-- 
1.7.6


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

[OE-core] [PATCH 1/3] rpm: ensure that magic file is relocatable

rpm-native was reading from /usr/share/misc/magic which is wrong
it needs to be set to read from the sysroot.  This also adds wrappers
to the rpm-build tools to ensure they know were to find the macros that
point to the right directories.

Fixes [YOCTO #1532]

Signed-off-by: Saul Wold s...@linux.intel.com
---
 meta/recipes-devtools/rpm/rpm_5.4.0.bb |   14 +++---
 1 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-devtools/rpm/rpm_5.4.0.bb 
b/meta/recipes-devtools/rpm/rpm_5.4.0.bb
index a7b360d..356512a 100644
--- a/meta/recipes-devtools/rpm/rpm_5.4.0.bb
+++ b/meta/recipes-devtools/rpm/rpm_5.4.0.bb
@@ -44,8 +44,8 @@ LIC_FILES_CHKSUM = 
file://COPYING.LIB;md5=2d5025d4aa3495befef8f17206a5b0a1
 
 DEPENDS = bzip2 zlib db openssl elfutils expat libpcre attr acl popt 
${extrarpmdeps}
 extrarpmdeps = python perl
-extrarpmdeps_virtclass-native = 
-PR = r21
+extrarpmdeps_virtclass-native = file-native
+PR = r22
 
 # rpm2cpio is a shell script, which is part of the rpm src.rpm.  It is needed
 # in order to extract the distribution SRPM into a format we can extract...
@@ -119,7 +119,7 @@ EXTRA_OECONF = --verbose \
${WITH_DB} \
${WITH_Z} \
--with-file \
-   --with-path-magic=/usr/share/misc/magic \
+   --with-path-magic=%{_usrlibrpm}/../../share/misc/magic \
--without-lua \
--without-tcl \
--with-syck=internal \
@@ -289,6 +289,7 @@ FILES_${PN}-build = ${prefix}/src/rpm \
${libdir}/rpm/vpkg-provides2.sh \
${libdir}/rpm/perfile_rpmdeps.sh \

+RDEPENDS_${PN}-build = file
 
 #%rpmattr   %{_rpmhome}/gem_helper.rb
 #%rpmattr   %{_rpmhome}/symclash.*
@@ -420,6 +421,13 @@ do_install_append_virtclass-native() {
RPM_ETCRPM=${STAGING_ETCDIR_NATIVE}/rpm \
RPM_LOCALEDIRRPM=${STAGING_DATADIR_NATIVE}/locale
 
+   for rpm_binary in ${D}/${libdir}/rpm/bin/rpm*; do
+   create_wrapper $rpm_binary
+   RPM_USRLIBRPM=${STAGING_LIBDIR_NATIVE}/rpm \
+   RPM_ETCRPM=${STAGING_ETCDIR_NATIVE}/rpm \
+   RPM_LOCALEDIRRPM=${STAGING_DATADIR_NATIVE}/locale
+   done
+
# Adjust popt macros to match...
cat ${D}/${libdir}/rpm/rpmpopt | sed -e s,^\(rpm[^ ]*\)\([ 
]\),\1.real\2,  ${D}/${libdir}/rpm/rpmpopt.new
mv ${D}/${libdir}/rpm/rpmpopt.new ${D}/${libdir}/rpm/rpmpopt
-- 
1.7.6


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

[OE-core] [PATCH 0/3] Fix for RPM host contamination issue

Richard,

The first patch of this set fixes the host contamination issue that 
was found.

The second 2 fixes are doing some RDEPENDS clean up and QA warning on
un-packaged files.

Sau!

The following changes since commit 684a4b517d13884c315688967fadd5e6a4845b71:

  libffi: really populate -dev package (2011-09-26 20:50:27 +0100)

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

Saul Wold (3):
  rpm: ensure that magic file is relocatable
  zypper  sat-solver: needs RDEPENDS on rpm-lib
  rpm: fix QA Warning on installed but not shipped staticdev filesw

 meta/recipes-devtools/rpm/rpm_5.4.0.bb |   31 +--
 meta/recipes-extended/libzypp/libzypp_git.bb   |8 ++--
 meta/recipes-extended/sat-solver/sat-solver_git.bb |4 ++-
 meta/recipes-extended/zypper/zypper_git.bb |6 ++-
 4 files changed, 32 insertions(+), 17 deletions(-)

-- 
1.7.6


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

[OE-core] [PATCH 3/4] tables: remove it as obsolete recipe

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

tables depends on obsolete gnome-vfs, and is not maintained in clutter git repo

Signed-off-by: Zhai Edwin edwin.z...@intel.com
---
 meta-demoapps/recipes-graphics/clutter/table.inc   |   13 -
 .../recipes-graphics/clutter/table/fixes.patch |   16 
 .../recipes-graphics/clutter/table_git.bb  |   15 ---
 3 files changed, 0 insertions(+), 44 deletions(-)
 delete mode 100644 meta-demoapps/recipes-graphics/clutter/table.inc
 delete mode 100644 meta-demoapps/recipes-graphics/clutter/table/fixes.patch
 delete mode 100644 meta-demoapps/recipes-graphics/clutter/table_git.bb

diff --git a/meta-demoapps/recipes-graphics/clutter/table.inc 
b/meta-demoapps/recipes-graphics/clutter/table.inc
deleted file mode 100644
index 937ad56..000
--- a/meta-demoapps/recipes-graphics/clutter/table.inc
+++ /dev/null
@@ -1,13 +0,0 @@
-DESCRIPTION = Table Clutter Demo
-HOMEPAGE = http://www.clutter-project.org/;
-LICENSE = LGPLv2.1  GPLv2
-
-DEPENDS = clutter-gst-1.4 gnome-vfs
-
-inherit autotools pkgconfig
-
-do_install() {
-   install -d ${D}${bindir}
-   install -m 0755 ${S}/table ${D}${bindir}/table
-}
-
diff --git a/meta-demoapps/recipes-graphics/clutter/table/fixes.patch 
b/meta-demoapps/recipes-graphics/clutter/table/fixes.patch
deleted file mode 100644
index 323bf13..000
--- a/meta-demoapps/recipes-graphics/clutter/table/fixes.patch
+++ /dev/null
@@ -1,16 +0,0 @@
-Upstream-Status: Pending
-
-Index: table/Makefile
-===
 table.orig/Makefile2007-07-10 13:24:18.0 +0100
-+++ table/Makefile 2007-07-10 13:28:10.0 +0100
-@@ -8,7 +8,7 @@ all: table
- 
- 
- table: table.o clutter-dominatrix.o clutter-video-player.o
--  $(CC) -g -Wall $(CFLAGS) -o $@ table.o clutter-dominatrix.o 
clutter-video-player.o $(LIBS)
-+  $(CC) -g -Wall $(CFLAGS) $(LDFLAGS) -o $@ table.o clutter-dominatrix.o 
clutter-video-player.o $(LIBS)
- 
- clean:
-   rm -fr *.o table
-\ No newline at end of file
diff --git a/meta-demoapps/recipes-graphics/clutter/table_git.bb 
b/meta-demoapps/recipes-graphics/clutter/table_git.bb
deleted file mode 100644
index d0ae184..000
--- a/meta-demoapps/recipes-graphics/clutter/table_git.bb
+++ /dev/null
@@ -1,15 +0,0 @@
-require table.inc
-
-LIC_FILES_CHKSUM = file://fluttr/COPYING;md5=59530bdf33659b29e73d4adb9f9f6552 
\
-
file://script-viewer/COPYING;md5=7fbc338309ac38fefcd64b04bb903e34
-
-SRCREV = 4b267533ce16656cba4104fc39dc12709c1bdddf
-PV = 0.3.0+git${SRCPV}
-PR = r1
-
-SRC_URI = git://git.clutter-project.org/toys.git;protocol=git \
-   file://fixes.patch;patch=1
-
-S = ${WORKDIR}/git/table
-
-
-- 
1.7.1


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

[OE-core] [PATCH 4/4] gnome-vfs: remove it as obsolete recipe in favor of GIO/GVFS

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

Signed-off-by: Zhai Edwin edwin.z...@intel.com
---
 .../conf/distro/include/distro_tracking_fields.inc |   11 
 meta/conf/multilib.conf|1 -
 .../gnome/gnome-vfs-2.24.4/gconftool-lossage.patch |   13 -
 .../gnome-vfs-2.24.4/gnome-vfs-no-kerberos.patch   |   53 
 meta/recipes-gnome/gnome/gnome-vfs_2.24.4.bb   |   50 --
 5 files changed, 0 insertions(+), 128 deletions(-)
 delete mode 100644 
meta/recipes-gnome/gnome/gnome-vfs-2.24.4/gconftool-lossage.patch
 delete mode 100644 
meta/recipes-gnome/gnome/gnome-vfs-2.24.4/gnome-vfs-no-kerberos.patch
 delete mode 100644 meta/recipes-gnome/gnome/gnome-vfs_2.24.4.bb

diff --git a/meta/conf/distro/include/distro_tracking_fields.inc 
b/meta/conf/distro/include/distro_tracking_fields.inc
index c1f15e1..c08a1c8 100644
--- a/meta/conf/distro/include/distro_tracking_fields.inc
+++ b/meta/conf/distro/include/distro_tracking_fields.inc
@@ -4609,17 +4609,6 @@ RECIPE_COMMENTS_pn-libx11-trim = 
 RECIPE_LAST_UPDATE_pn-libx11-trim = Jul 9, 2010
 RECIPE_MAINTAINER_pn-libx11-trim = Dexuan Cui dexuan@intel.com
 
-RECIPE_STATUS_pn-gnome-vfs = green
-RECIPE_DEPENDENCY_CHECK_pn-gnome-vfs = not done
-RECIPE_LATEST_VERSION_pn-gnome-vfs = 2.24.4
-RECIPE_NO_OF_PATCHES_pn-gnome-vfs = 2
-RECIPE_INTEL_SECTION_pn-gnome-vfs = gnome/lib
-RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn-gnome-vfs = 6 months
-RECIPE_LATEST_RELEASE_DATE_pn-gnome-vfs = Sep 28, 2010
-RECIPE_COMMENTS_pn-gnome-vfs = 
-RECIPE_LAST_UPDATE_pn-gnome-vfs = Nov 24, 2010
-RECIPE_MAINTAINER_pn-gnome-vfs = Dexuan Cui dexuan@intel.com
-
 RECIPE_STATUS_pn-xcb-util = green
 RECIPE_DEPENDENCY_CHECK_pn-xcb-util = not done
 RECIPE_LATEST_VERSION_pn-xcb-util = 0.3.8
diff --git a/meta/conf/multilib.conf b/meta/conf/multilib.conf
index 3133bf1..db2f6f5 100644
--- a/meta/conf/multilib.conf
+++ b/meta/conf/multilib.conf
@@ -118,7 +118,6 @@ BBCLASSEXTEND_append_pn-gnome-doc-utils =  ${MULTILIBS}
 BBCLASSEXTEND_append_pn-gnome-keyring =  ${MULTILIBS}
 BBCLASSEXTEND_append_pn-gnome-mime-data =  ${MULTILIBS}
 BBCLASSEXTEND_append_pn-gnome-mime-data =  ${MULTILIBS}
-BBCLASSEXTEND_append_pn-gnome-vfs =  ${MULTILIBS}
 BBCLASSEXTEND_append_pn-gnutls =  ${MULTILIBS}
 BBCLASSEXTEND_append_pn-grep =  ${MULTILIBS}
 BBCLASSEXTEND_append_pn-groff =  ${MULTILIBS}
diff --git a/meta/recipes-gnome/gnome/gnome-vfs-2.24.4/gconftool-lossage.patch 
b/meta/recipes-gnome/gnome/gnome-vfs-2.24.4/gconftool-lossage.patch
deleted file mode 100644
index 0f52136..000
--- a/meta/recipes-gnome/gnome/gnome-vfs-2.24.4/gconftool-lossage.patch
+++ /dev/null
@@ -1,13 +0,0 @@
-Upstream-Status: Inappropriate [configuration]
-
 gnome-vfs-2.6.0/configure.in~  2004-03-22 12:36:23.0 +
-+++ gnome-vfs-2.6.0/configure.in   2004-06-07 16:04:34.0 +0100
-@@ -154,7 +154,7 @@
- AC_PATH_PROG(GCONFTOOL, gconftool-2, no)
- 
- if test x$GCONFTOOL = xno; then
--  AC_MSG_ERROR([gconftool-2 executable not found in your path - should be 
installed with GConf])
-+  AC_MSG_WARN([gconftool-2 executable not found in your path - should be 
installed with GConf])
- fi
- 
- AM_GCONF_SOURCE_2
diff --git 
a/meta/recipes-gnome/gnome/gnome-vfs-2.24.4/gnome-vfs-no-kerberos.patch 
b/meta/recipes-gnome/gnome/gnome-vfs-2.24.4/gnome-vfs-no-kerberos.patch
deleted file mode 100644
index dabec32..000
--- a/meta/recipes-gnome/gnome/gnome-vfs-2.24.4/gnome-vfs-no-kerberos.patch
+++ /dev/null
@@ -1,53 +0,0 @@
-Upstream-Status: Inappropriate [configuration]
-
-removes kerberos completely to avoid conflicts with installed kerberos
 configure.in.orig  2007-01-05 19:42:26.418541610 +0200
-+++ configure.in   2007-01-05 19:42:56.604261797 +0200
-@@ -436,47 +436,6 @@
- ])
- AM_CONDITIONAL(HAVE_CDDA, test $have_cdda = yes)
- AC_SUBST(CDDA_LIBS)
--
--dnl GSSAPI
--dnl Check for Kerberos installation
--have_gssapi=no
--AC_PATH_PROG([KRB5_CONFIG], krb5-config, none, $PATH:/usr/kerberos/bin)
-- 
--if test x$KRB5_CONFIG != xnone; then
--   GSSAPI_LIBS=`${KRB5_CONFIG} --libs gssapi`
--   GSSAPI_CFLAGS=`${KRB5_CONFIG} --cflags gssapi`
--   
--   saved_CPPFLAGS=$CPPFLAGS
--   saved_LIBS=$LIBS
--   LIBS=$LIBS $GSSAPI_LIBS
--   CPPFLAGS=$CPPFLAGS $GSSAPI_CFLAGS
--   # MIT and Heimdal put gssapi.h in different places
--   AC_CHECK_HEADERS(gssapi/gssapi.h gssapi.h, [
--   AC_CHECK_FUNCS(gss_init_sec_context, [
--   AC_MSG_NOTICE([GSSAPI authentication support enabled])
--   AC_DEFINE(HAVE_GSSAPI, 1, [Define if GSSAPI support is enabled])
--   AC_CHECK_HEADERS(gssapi/gssapi_generic.h)
--   have_gssapi=yes
--   
--   # MIT Kerberos lacks GSS_C_NT_HOSTBASED_SERVICE
--   AC_CHECK_DECL([GSS_C_NT_HOSTBASED_SERVICE],,
--  [AC_DEFINE([GSS_C_NT_HOSTBASED_SERVICE], gss_nt_service_name, 
-- [Define if GSS_C_NT_HOSTBASED_SERVICE is not defined otherwise])
--  ], [

[OE-core] [PATCH 1/4] oprofileui: remove dependence on gnome-vfs

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

Signed-off-by: Zhai Edwin edwin.z...@intel.com
---
 meta/recipes-kernel/oprofile/oprofileui.inc |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/meta/recipes-kernel/oprofile/oprofileui.inc 
b/meta/recipes-kernel/oprofile/oprofileui.inc
index 5170357..ab14c38 100644
--- a/meta/recipes-kernel/oprofile/oprofileui.inc
+++ b/meta/recipes-kernel/oprofile/oprofileui.inc
@@ -8,7 +8,7 @@ SECTION = x11
 LICENSE = GPLv2
 LIC_FILES_CHKSUM = file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f
 
-DEPENDS = glib-2.0 gtk+ libglade gnome-vfs libxml2 avahi-ui gconf
+DEPENDS = glib-2.0 gtk+ libglade libxml2 avahi-ui gconf
 
 inherit autotools pkgconfig gtk-icon-cache
 
-- 
1.7.1


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

[OE-core] [PATCH 0/4] Remove gnome-vfs completely

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

All,
gnome-vfs need to be removed and taken place by gio. These patches remove the
dependece on it, and obsolete recipes that need it.

Pls. help to pull.

Thanks,
Edwin

The following changes since commit e3c5d7a90ae179af0ac128ea4dfc1a5a6602c2e4:

  libtool: Fix an issue where unnecessary rpaths were being injected 
(2011-09-26 17:56:44 +0100)

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

Zhai Edwin (4):
  oprofileui: remove dependence on gnome-vfs
  libgsf: remove dependence on gnome-vfs
  tables: remove it as obsolete recipe
  gnome-vfs: remove it as obsolete recipe in favor of GIO/GVFS

 .../recipes-gnome/libgsf/libgsf_1.14.5.bb  |8 ++-
 meta-demoapps/recipes-graphics/clutter/table.inc   |   13 -
 .../recipes-graphics/clutter/table/fixes.patch |   16 --
 .../recipes-graphics/clutter/table_git.bb  |   15 --
 .../conf/distro/include/distro_tracking_fields.inc |   11 
 meta/conf/multilib.conf|1 -
 .../gnome/gnome-vfs-2.24.4/gconftool-lossage.patch |   13 -
 .../gnome-vfs-2.24.4/gnome-vfs-no-kerberos.patch   |   53 
 meta/recipes-gnome/gnome/gnome-vfs_2.24.4.bb   |   50 --
 meta/recipes-kernel/oprofile/oprofileui.inc|2 +-
 10 files changed, 7 insertions(+), 175 deletions(-)
 delete mode 100644 meta-demoapps/recipes-graphics/clutter/table.inc
 delete mode 100644 meta-demoapps/recipes-graphics/clutter/table/fixes.patch
 delete mode 100644 meta-demoapps/recipes-graphics/clutter/table_git.bb
 delete mode 100644 
meta/recipes-gnome/gnome/gnome-vfs-2.24.4/gconftool-lossage.patch
 delete mode 100644 
meta/recipes-gnome/gnome/gnome-vfs-2.24.4/gnome-vfs-no-kerberos.patch
 delete mode 100644 meta/recipes-gnome/gnome/gnome-vfs_2.24.4.bb


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

[OE-core] [PATCH 2/4] libgsf: remove dependence on gnome-vfs