[OE-core] [RFC PATCH 3/5] bootimg: Pull syslinux specific bits into syslinux.bbclass

[Darren Hart]

Working towards a more generic bootimg.bbclass, pull out all
syslinux specific bits and let syslinux.bbclass manage them
directly. This introduces no functional changes to the images
constructed and the behavior remains unchanged.

Signed-off-by: Darren Hart dvh...@linux.intel.com
---
 meta/classes/bootimg.bbclass  |   74 ---
 meta/classes/syslinux.bbclass |   84 +
 2 files changed, 85 insertions(+), 73 deletions(-)

diff --git a/meta/classes/bootimg.bbclass b/meta/classes/bootimg.bbclass
index 26d2fae..d4da95b 100644
--- a/meta/classes/bootimg.bbclass
+++ b/meta/classes/bootimg.bbclass
@@ -17,36 +17,26 @@
 # in syslinux. Actions based on the label are then performed (e.g. installing 
to 
 # an hdd)
 
-# External variables
+# External variables (also used by syslinux.bbclass)
 # ${INITRD} - indicates a filesystem image to use as an initrd (optional)
+# ${NOISO}  - skip building the ISO image if set to 1
 # ${ROOTFS} - indicates a filesystem image to include as the root filesystem 
(optional)
-# ${AUTO_SYSLINUXCFG} - set this to 1 to enable creating an automatic config
-# ${LABELS} - a list of targets for the automatic config
-# ${APPEND} - an override list of append strings for each label
-# ${SYSLINUX_OPTS} - additional options to add to the syslinux file ';' 
delimited 
 
 do_bootimg[depends] += dosfstools-native:do_populate_sysroot \
-   syslinux:do_populate_sysroot \
-   syslinux-native:do_populate_sysroot \
-  mtools-native:do_populate_sysroot \
-  cdrtools-native:do_populate_sysroot
+mtools-native:do_populate_sysroot \
+cdrtools-native:do_populate_sysroot
 
 PACKAGES =  
 EXCLUDE_FROM_WORLD = 1
 
 HDDDIR = ${S}/hdd/boot
-ISODIR = ${S}/cd/isolinux
+ISODIR = ${S}/cd
 
 BOOTIMG_VOLUME_ID   ?= boot
 BOOTIMG_EXTRA_SPACE ?= 512
 
-# Get the build_syslinux_cfg() function from the syslinux class
-
-SYSLINUXCFG  = ${HDDDIR}/syslinux.cfg
-SYSLINUXMENU = ${HDDDIR}/menu
-
 inherit syslinux
-   
+
 build_iso() {
# Only create an ISO if we have an INITRD and NOISO was not set
if [ -z ${INITRD} ] || [ ! -s ${INITRD} ] || [ ${NOISO} = 1 ]; 
then
@@ -56,31 +46,12 @@ build_iso() {
 
install -d ${ISODIR}
 
-   # Install the kernel
-   install -m 0644 ${STAGING_DIR_HOST}/kernel/bzImage \
-   ${ISODIR}/vmlinuz
-
-   # Install the configuration files
-   cp ${HDDDIR}/syslinux.cfg ${ISODIR}/isolinux.cfg
-
-   if [ -f ${SYSLINUXMENU} ]; then
-   cp ${SYSLINUXMENU} ${ISODIR}
-   fi
-
-   install -m 0644 ${INITRD} ${ISODIR}/initrd
-
-   if [ -n ${ROOTFS} ]  [ -s ${ROOTFS} ]; then 
-   install -m 0644 ${ROOTFS} ${ISODIR}/rootfs.img
-   fi
-
-   # And install the syslinux stuff 
-   cp ${STAGING_LIBDIR}/syslinux/isolinux.bin ${ISODIR}
+   syslinux_iso_populate
 
mkisofs -V ${BOOTIMG_VOLUME_ID} \
-   -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso \
-   -b isolinux/isolinux.bin -c isolinux/boot.cat -r \
-   -no-emul-boot -boot-load-size 4 -boot-info-table \
-   ${S}/cd/
+   -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso \
+   -b ${ISO_BOOTIMG} -c ${ISO_BOOTCAT} -r \
+   ${MKISOFS_OPTIONS} ${ISODIR}
 
cd ${DEPLOY_DIR_IMAGE}
rm -f ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.iso
@@ -89,35 +60,24 @@ build_iso() {
 
 build_hddimg() {
install -d ${HDDDIR}
-   install -m 0644 ${STAGING_DIR_HOST}/kernel/bzImage \
-   ${HDDDIR}/vmlinuz
-
-   if [ -n ${INITRD} ]  [ -s ${INITRD} ]; then 
-   install -m 0644 ${INITRD} ${HDDDIR}/initrd
-   fi
 
-   if [ -n ${ROOTFS} ]  [ -s ${ROOTFS} ]; then 
-   install -m 0644 ${ROOTFS} ${HDDDIR}/rootfs.img
-   fi
-
-   install -m 444 ${STAGING_LIBDIR}/syslinux/ldlinux.sys 
${HDDDIR}/ldlinux.sys
+   syslinux_hddimg_populate
 
-   # Do a little math, bash style
-   #BLOCKS=`du -s ${HDDDIR} | cut -f 1`
+   # Determine the block count for the final image
BLOCKS=`du -bks ${HDDDIR} | cut -f 1`
-   SIZE=`expr $BLOCKS + ${BOOTIMG_EXTRA_SPACE}`
+   SIZE=`expr $BLOCKS + ${BOOTIMG_EXTRA_SPACE}`
 
mkdosfs -n ${BOOTIMG_VOLUME_ID} -d ${HDDDIR} \
-   -C ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.hddimg $SIZE 
+   -C ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.hddimg $SIZE 
+
+   syslinux_hddimg_install
 
-   syslinux ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.hddimg
chmod 644 ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.hddimg
 
cd ${DEPLOY_DIR_IMAGE}
rm -f ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.hddimg
ln -s ${IMAGE_NAME}.hddimg ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.hddimg
-   
-} 
+}
 
 python do_bootimg() {
bb.build.exec_func('build_syslinux_cfg', d)
diff --git a/meta/classes/syslinux.bbclass 

[OE-core] [RFC PATCH 4/5] bootimg: Add grub-efi support

[Darren Hart]

Create a new grub-efi.bbclass and integrate it into bootimg alongside the
syslinux support. This new class uses the output from the grub-efi-native
recipe. Thanks goes to Josef Ahmad josef.ah...@intel.com for the original
build_grub_cfg() routine.

The EFI features are only added to the image if MACHINE_FEATURES contains
efi. The resulting images are therefor either legacy boot only (like they
were originally) or legacy boot and EFI boot.

A new dummy.bbclass was added to allow for the conditional include
of grub-efi. This makes it so if efi support is not to be built in, we
don't spend time building grub-efi-native just because the include adds
the dependency.

There is a bug in the mkdosfs tool from the dosfstools package which causes
it to crash when the directory passed with the -d parameter contains
sub-directories. An /EFI/BOOT directory is required for a proper EFI
installation. Until it is fixed, we install to the top level directory
for the hddimg.

Signed-off-by: Darren Hart dvh...@linux.intel.com
Signed-off-by: Josef Ahmad josef.ah...@intel.com
---
 meta/classes/bootimg.bbclass  |   13 
 meta/classes/dummy.bbclass|2 +
 meta/classes/grub-efi.bbclass |  140 +
 3 files changed, 155 insertions(+), 0 deletions(-)
 create mode 100644 meta/classes/dummy.bbclass
 create mode 100644 meta/classes/grub-efi.bbclass

diff --git a/meta/classes/bootimg.bbclass b/meta/classes/bootimg.bbclass
index d4da95b..44bb61e 100644
--- a/meta/classes/bootimg.bbclass
+++ b/meta/classes/bootimg.bbclass
@@ -35,7 +35,12 @@ ISODIR = ${S}/cd
 BOOTIMG_VOLUME_ID   ?= boot
 BOOTIMG_EXTRA_SPACE ?= 512
 
+EFI = ${@base_contains(MACHINE_FEATURES, efi, 1, 0, d)}
+EFI_CLASS = ${@base_contains(MACHINE_FEATURES, efi, grub-efi, dummy, 
d)}
+
 inherit syslinux
+inherit ${EFI_CLASS}
+
 
 build_iso() {
# Only create an ISO if we have an INITRD and NOISO was not set
@@ -47,6 +52,9 @@ build_iso() {
install -d ${ISODIR}
 
syslinux_iso_populate
+   if [ ${EFI} = 1 ]; then
+   grubefi_iso_populate
+   fi
 
mkisofs -V ${BOOTIMG_VOLUME_ID} \
-o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso \
@@ -62,6 +70,9 @@ build_hddimg() {
install -d ${HDDDIR}
 
syslinux_hddimg_populate
+   if [ ${EFI} = 1 ]; then
+   grubefi_hddimg_populate
+   fi
 
# Determine the block count for the final image
BLOCKS=`du -bks ${HDDDIR} | cut -f 1`
@@ -81,6 +92,8 @@ build_hddimg() {
 
 python do_bootimg() {
bb.build.exec_func('build_syslinux_cfg', d)
+   if d.getVar(EFI, True) == 1:
+   bb.build.exec_func('build_grub_cfg', d)
bb.build.exec_func('build_hddimg', d)
bb.build.exec_func('build_iso', d)
 }
diff --git a/meta/classes/dummy.bbclass b/meta/classes/dummy.bbclass
new file mode 100644
index 000..8c30071
--- /dev/null
+++ b/meta/classes/dummy.bbclass
@@ -0,0 +1,2 @@
+# An empty bbclass to facilitate dynamic inherit, include,
+# and require statements.
diff --git a/meta/classes/grub-efi.bbclass b/meta/classes/grub-efi.bbclass
new file mode 100644
index 000..333e6c5
--- /dev/null
+++ b/meta/classes/grub-efi.bbclass
@@ -0,0 +1,140 @@
+# grub-efi.bbclass
+# Copyright (c) 2011, Intel Corporation.
+# All rights reserved.
+#
+# Released under the MIT license (see packages/COPYING)
+
+# Provide grub-efi specific functions for building bootable images.
+
+# External variables
+# ${INITRD} - indicates a filesystem image to use as an initrd (optional)
+# ${ROOTFS} - indicates a filesystem image to include as the root filesystem 
(optional)
+# ${LABELS} - a list of targets for the automatic config
+# ${APPEND} - an override list of append strings for each label
+# ${GRUB_OPTS} - additional options to add to the config, ';' delimited # 
(optional)
+# ${GRUB_TIMEOUT} - timeout before executing the deault label (optional)
+
+do_bootimg[depends] += grub-efi-${TARGET_ARCH}-native:do_deploy
+
+GRUBCFG = grub.cfg
+GRUB_TIMEOUT ?= 10
+#FIXME: build this from the machine config
+GRUB_OPTS ?= serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1
+
+# FIXME: add EFI/BOOT to GRUB_HDDDIR once the mkdosfs subdir bug is resolved
+#http://bugzilla.yoctoproject.org/show_bug.cgi?id=1783
+EFIDIR = /EFI/BOOT
+GRUB_HDDDIR = ${HDDDIR}
+GRUB_ISODIR = ${ISODIR}${EFIDIR}
+
+grubefi_populate() {
+   DEST=$1
+
+   install -d ${DEST}
+
+   install -m 0644 ${STAGING_DIR_HOST}/kernel/bzImage ${DEST}/vmlinuz
+
+   if [ -n ${INITRD} ]  [ -s ${INITRD} ]; then 
+   install -m 0644 ${INITRD} ${DEST}/initrd
+   fi
+
+   if [ -n ${ROOTFS} ]  [ -s ${ROOTFS} ]; then 
+   install -m 0644 ${ROOTFS} ${DEST}/rootfs.img
+   fi
+
+   GRUB_IMAGE=bootia32.efi
+   if [ ${TARGET_ARCH} = x86_64 ]; then
+   GRUB_IMAGE=bootx64.efi
+   fi
+   install -m 0644 ${DEPLOY_DIR_IMAGE}/${GRUB_IMAGE} ${DEST}
+
+   install -m 0644 

[OE-core] [RFC PATCH 2/5] bootimg: Refactor build_hddimg and build_iso routines

[Darren Hart]

Separate the construction of the ISO image from that of the hddimg.
This is part of the groundwork for creating a much more flexible
live image builder.

Signed-off-by: Darren Hart dvh...@linux.intel.com
---
 meta/classes/bootimg.bbclass |   82 ++
 1 files changed, 43 insertions(+), 39 deletions(-)

diff --git a/meta/classes/bootimg.bbclass b/meta/classes/bootimg.bbclass
index 49ee85e..26d2fae 100644
--- a/meta/classes/bootimg.bbclass
+++ b/meta/classes/bootimg.bbclass
@@ -47,7 +47,47 @@ SYSLINUXMENU = ${HDDDIR}/menu
 
 inherit syslinux

-build_boot_bin() {
+build_iso() {
+   # Only create an ISO if we have an INITRD and NOISO was not set
+   if [ -z ${INITRD} ] || [ ! -s ${INITRD} ] || [ ${NOISO} = 1 ]; 
then
+   bbnote ISO image will not be created.
+   return
+   fi
+
+   install -d ${ISODIR}
+
+   # Install the kernel
+   install -m 0644 ${STAGING_DIR_HOST}/kernel/bzImage \
+   ${ISODIR}/vmlinuz
+
+   # Install the configuration files
+   cp ${HDDDIR}/syslinux.cfg ${ISODIR}/isolinux.cfg
+
+   if [ -f ${SYSLINUXMENU} ]; then
+   cp ${SYSLINUXMENU} ${ISODIR}
+   fi
+
+   install -m 0644 ${INITRD} ${ISODIR}/initrd
+
+   if [ -n ${ROOTFS} ]  [ -s ${ROOTFS} ]; then 
+   install -m 0644 ${ROOTFS} ${ISODIR}/rootfs.img
+   fi
+
+   # And install the syslinux stuff 
+   cp ${STAGING_LIBDIR}/syslinux/isolinux.bin ${ISODIR}
+
+   mkisofs -V ${BOOTIMG_VOLUME_ID} \
+   -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso \
+   -b isolinux/isolinux.bin -c isolinux/boot.cat -r \
+   -no-emul-boot -boot-load-size 4 -boot-info-table \
+   ${S}/cd/
+
+   cd ${DEPLOY_DIR_IMAGE}
+   rm -f ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.iso
+   ln -s ${IMAGE_NAME}.iso ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.iso
+}
+
+build_hddimg() {
install -d ${HDDDIR}
install -m 0644 ${STAGING_DIR_HOST}/kernel/bzImage \
${HDDDIR}/vmlinuz
@@ -77,48 +117,12 @@ build_boot_bin() {
rm -f ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.hddimg
ln -s ${IMAGE_NAME}.hddimg ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.hddimg

-   #Create an ISO if we have an INITRD
-   if [ -n ${INITRD} ]  [ -s ${INITRD} ]  [ ${NOISO} != 1 ] ; 
then
-   install -d ${ISODIR}
-
-   # Install the kernel
-
-   install -m 0644 ${STAGING_DIR_HOST}/kernel/bzImage \
-   ${ISODIR}/vmlinuz
-
-   # Install the configuration files
-
-   cp ${HDDDIR}/syslinux.cfg ${ISODIR}/isolinux.cfg
-
-   if [ -f ${SYSLINUXMENU} ]; then
-   cp ${SYSLINUXMENU} ${ISODIR}
-   fi
-
-   install -m 0644 ${INITRD} ${ISODIR}/initrd
-
-   if [ -n ${ROOTFS} ]  [ -s ${ROOTFS} ]; then 
-   install -m 0644 ${ROOTFS} ${ISODIR}/rootfs.img
-   fi
-
-   # And install the syslinux stuff 
-   cp ${STAGING_LIBDIR}/syslinux/isolinux.bin ${ISODIR}
-
-   mkisofs -V ${BOOTIMG_VOLUME_ID} \
-   -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso \
-   -b isolinux/isolinux.bin -c isolinux/boot.cat -r \
-   -no-emul-boot -boot-load-size 4 -boot-info-table \
-   ${S}/cd/
-
-   cd ${DEPLOY_DIR_IMAGE}
-   rm -f ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.iso
-   ln -s ${IMAGE_NAME}.iso 
${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.iso
-
-   fi
 } 
 
 python do_bootimg() {
bb.build.exec_func('build_syslinux_cfg', d)
-   bb.build.exec_func('build_boot_bin', d)
+   bb.build.exec_func('build_hddimg', d)
+   bb.build.exec_func('build_iso', d)
 }
 
 addtask bootimg before do_build
-- 
1.7.6.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/5] grub-efi-native: New recipe to build GRUB EFI images

[Darren Hart]

Add a recipe to build the GRUB efi images. This recipe is written as
a native recipe as the resulting GRUB utils are required to assemble
the final image. Rather than build a native and a target recipe (and
increase build times), this recipe builds the utils for the host and
passes an appropriate --target argument to the GRUB configure script
to build the modules for the target arch. The only output of this
recipe is an EFI image in the deploy directory.

Care is taken to ensure changing targets will force a rebuild of this
native recipe by including the target arch in the PN.

Signed-off-by: Darren Hart dvh...@linux.intel.com
---
 meta/recipes-bsp/grub/grub-efi-native_1.99.bb |   74 +
 1 files changed, 74 insertions(+), 0 deletions(-)
 create mode 100644 meta/recipes-bsp/grub/grub-efi-native_1.99.bb

diff --git a/meta/recipes-bsp/grub/grub-efi-native_1.99.bb 
b/meta/recipes-bsp/grub/grub-efi-native_1.99.bb
new file mode 100644
index 000..3c52ec9
--- /dev/null
+++ b/meta/recipes-bsp/grub/grub-efi-native_1.99.bb
@@ -0,0 +1,74 @@
+SUMMARY = GRUB2 is the next-generation GRand Unified Bootloader
+
+DESCRIPTION = GRUB2 is the next generaion of a GPLed bootloader \
+intended to unify bootloading across x86 operating systems. In \
+addition to loading the Linux kernel, it implements the Multiboot \
+standard, which allows for flexible loading of multiple boot images. \
+This recipe builds an EFI binary for the target. It does not install \
+or package anything, it only deploys a target-arch GRUB EFI image.
+
+HOMEPAGE = http://www.gnu.org/software/grub/;
+SECTION = bootloaders
+PRIORITY = optional
+
+LICENSE = GPLv3
+LIC_FILES_CHKSUM = file://COPYING;md5=d32239bcb673463ab874e80d47fae504
+
+# FIXME: We should be able to optionally drop freetype as a dependency
+DEPENDS = help2man-native
+RDEPENDS_${PN} = diffutils freetype
+PR = r1
+
+# Native packages do not normally rebuild when the target changes.
+# Ensure this is built once per HOST-TARGET pair.
+PN := grub-efi-${TRANSLATED_TARGET_ARCH}-native
+
+SRC_URI = ftp://ftp.gnu.org/gnu/grub/grub-${PV}.tar.gz;
+
+SRC_URI[md5sum] = ca9f2a2d571b57fc5c53212d1d22e2b5
+SRC_URI[sha256sum] = 
b91f420f2c51f6155e088e34ff99bea09cc1fb89585cf7c0179644e57abd28ff
+
+COMPATIBLE_HOST = '(x86_64.*|i.86.*)-(linux|freebsd.*)'
+
+S = ${WORKDIR}/grub-${PV}
+
+# Determine the target arch for the grub modules before the native class
+# clobbers TARGET_ARCH.
+ORIG_TARGET_ARCH := ${TARGET_ARCH}
+python __anonymous () {
+import re
+target = d.getVar('ORIG_TARGET_ARCH', True)
+if target == x86_64:
+grubtarget = 'x86_64'
+grubimage = bootx64.efi
+elif re.match('i.86', target):
+grubtarget = 'i386'
+grubimage = bootia32.efi
+else:
+raise bb.parse.SkipPackage(grub-efi is incompatible with target %s % 
target)
+d.setVar(GRUB_TARGET, grubtarget)
+d.setVar(GRUB_IMAGE, grubimage)
+}
+
+inherit autotools
+inherit gettext
+inherit native
+inherit deploy
+
+EXTRA_OECONF = --with-platform=efi --disable-grub-mkfont \
+--target=${GRUB_TARGET} --enable-efiemu=no --program-prefix=''
+
+do_mkimage() {
+   ./grub-mkimage -p / -d ./grub-core/ \
+  -O ${GRUB_TARGET}-efi -o ./${GRUB_IMAGE} \
+  boot linux fat serial part_msdos normal
+}
+addtask mkimage after do_compile before do_install
+
+do_deploy() {
+   install -m 644 ${S}/${GRUB_IMAGE} ${DEPLOYDIR}
+}
+addtask deploy after do_install before do_build
+
+do_install[noexec] = 1
+do_populate_sysroot[noexec] = 1
-- 
1.7.6.4


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

[OE-core] [RFC PATCH 5/5] bootimg: Allow for EFI-only boot images

[Darren Hart]

Condition building PCBIOS legacy images on MACHINE_FEATURES containing pcbios
or not containing efi. This ensures existing BSPs will continue to get the
old PCBIOS legacy-only images. New BSPs can add efi, pcbios, or both. The
images created likewise support one or the other or both.

EFI-only ISO images are untested.

Signed-off-by: Darren Hart dvh...@linux.intel.com
---
 meta/classes/bootimg.bbclass |   49 ++---
 1 files changed, 40 insertions(+), 9 deletions(-)

diff --git a/meta/classes/bootimg.bbclass b/meta/classes/bootimg.bbclass
index 44bb61e..d2088fe 100644
--- a/meta/classes/bootimg.bbclass
+++ b/meta/classes/bootimg.bbclass
@@ -38,7 +38,24 @@ BOOTIMG_EXTRA_SPACE ?= 512
 EFI = ${@base_contains(MACHINE_FEATURES, efi, 1, 0, d)}
 EFI_CLASS = ${@base_contains(MACHINE_FEATURES, efi, grub-efi, dummy, 
d)}
 
-inherit syslinux
+# Include legacy boot if MACHINE_FEATURES includes pcbios or if it does not
+# contain efi. This way legacy is supported by default if neither is
+# specified, maintaining the original behavior.
+def pcbios(d):
+   pcbios = base_contains(MACHINE_FEATURES, pcbios, 1, 0, d)
+   if pcbios == 0:
+   pcbios = base_contains(MACHINE_FEATURES, efi, 0, 1, d)
+   return pcbios
+
+def pcbios_class(d):
+   if d.getVar(PCBIOS, True) == 1:
+   return syslinux
+   return dummy
+
+PCBIOS = ${@pcbios(d)}
+PCBIOS_CLASS = ${@pcbios_class(d)}
+
+inherit ${PCBIOS_CLASS}
 inherit ${EFI_CLASS}
 
 
@@ -51,15 +68,24 @@ build_iso() {
 
install -d ${ISODIR}
 
-   syslinux_iso_populate
+   if [ ${PCBIOS} = 1 ]; then
+   syslinux_iso_populate
+   fi
if [ ${EFI} = 1 ]; then
grubefi_iso_populate
fi
 
-   mkisofs -V ${BOOTIMG_VOLUME_ID} \
-   -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso \
-   -b ${ISO_BOOTIMG} -c ${ISO_BOOTCAT} -r \
-   ${MKISOFS_OPTIONS} ${ISODIR}
+   if [ ${PCBIOS} = 1 ]; then
+   mkisofs -V ${BOOTIMG_VOLUME_ID} \
+   -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso \
+   -b ${ISO_BOOTIMG} -c ${ISO_BOOTCAT} -r \
+   ${MKISOFS_OPTIONS} ${ISODIR}
+   else
+   bbnote EFI-only ISO images are untested, please provide 
feedback.
+   mkisofs -V ${BOOTIMG_VOLUME_ID} \
+   -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso \
+   -r ${ISODIR}
+   fi
 
cd ${DEPLOY_DIR_IMAGE}
rm -f ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.iso
@@ -69,7 +95,9 @@ build_iso() {
 build_hddimg() {
install -d ${HDDDIR}
 
-   syslinux_hddimg_populate
+   if [ ${PCBIOS} = 1 ]; then
+   syslinux_hddimg_populate
+   fi
if [ ${EFI} = 1 ]; then
grubefi_hddimg_populate
fi
@@ -81,7 +109,9 @@ build_hddimg() {
mkdosfs -n ${BOOTIMG_VOLUME_ID} -d ${HDDDIR} \
-C ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.hddimg $SIZE 
 
-   syslinux_hddimg_install
+   if [ ${PCBIOS} = 1 ]; then
+   syslinux_hddimg_install
+   fi
 
chmod 644 ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.hddimg
 
@@ -91,7 +121,8 @@ build_hddimg() {
 }
 
 python do_bootimg() {
-   bb.build.exec_func('build_syslinux_cfg', d)
+   if d.getVar(PCBIOS, True) == 1:
+   bb.build.exec_func('build_syslinux_cfg', d)
if d.getVar(EFI, True) == 1:
bb.build.exec_func('build_grub_cfg', d)
bb.build.exec_func('build_hddimg', d)
-- 
1.7.6.4


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

Re: [OE-core] [RFC PATCH 0/5] EFI live image support

[Darren Hart]

On 11/24/2011 12:04 AM, Darren Hart wrote:
 
 Thanks to Koen Kooi, Chris Larson, Richard Purdie, and Josef Ahmad for their
 contributions of expertise, code, and testing.
 

The problem of course with listing people, is that you are likely to
miss some. Especially at midnight prior to a major holiday. My apologies
to Saul Wold and Joshua Lock who also provided valuable assistance, as
well as the others whom I shall predictably recall promptly upon
pressing Send.

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

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

[OE-core] [PATCH 0/1] distro_tracking_fields: update the status of some packages

[Xiaofeng Yan]

From: Xiaofeng Yan xiaofeng@windriver.com

directfb, libx11-diet and xorg-xserver-lite have updated their version. So I 
update these changes to  distro_tracking_fields.inc.

Pull URL: git://git.pokylinux.org/poky-contrib.git
  Branch: xiaofeng/maintainer
  Browse: 
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=xiaofeng/maintainer

Thanks,
Xiaofeng Yan xiaofeng@windriver.com
---


Xiaofeng Yan (1):
  distro_tracking_fields: update the status

 .../conf/distro/include/distro_tracking_fields.inc |   15 ---
 1 files changed, 12 insertions(+), 3 deletions(-)


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

[OE-core] [PATCH 1/1] distro_tracking_fields: update the status

[Xiaofeng Yan]

From: Xiaofeng Yan xiaofeng@windriver.com

directfb to 1.4.15
xorg-xserver-lite to 1.11.1
libx11-diet to 1.4.4

Signed-off-by: Xiaofeng Yan xiaofeng@windriver.com
---
 .../conf/distro/include/distro_tracking_fields.inc |   15 ---
 1 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/meta/conf/distro/include/distro_tracking_fields.inc 
b/meta/conf/distro/include/distro_tracking_fields.inc
index 17d9f2f..d334ef7 100644
--- a/meta/conf/distro/include/distro_tracking_fields.inc
+++ b/meta/conf/distro/include/distro_tracking_fields.inc
@@ -4656,9 +4656,15 @@ RECIPE_MAINTAINER_pn-libx11 = Dexuan Cui 
dexuan@intel.com
 
 RECIPE_STATUS_pn-libx11-diet = green
 DISTRO_PN_ALIAS_pn-libx11-diet = Debian=libx11-6 Fedora=libX11 
Ubuntu=libx11-6 OpenSuSE=xorg-x11-libX11
+RECIPE_LATEST_VERSION_pn-libx11-diet = 1.4.4
+RECIPE_LATEST_RELEASE_DATE_pn-libx11-diet = Jul 28,2011
+RECIPE_LAST_UPDATE_pn-libx11-diet =  Nov 22, 2011
 RECIPE_MAINTAINER_pn-libx11-diet = Xiaofeng Yan xiaofeng@windriver.com
 
-RECIPE_STATUS_pn-directfb = red
+RECIPE_STATUS_pn-directfb = green
+RECIPE_LATEST_VERSION_pn-directfb = 1.5.3
+RECIPE_LATEST_RELEASE_DATE_pn-direcfb = Aug 9,2011
+RECIPE_LAST_UPDATE_pn-directfb = Nov 7, 2011
 RECIPE_MAINTAINER_pn-directfb = Xiaofeng Yan xiaofeng@windriver.com
 
 RECIPE_STATUS_pn-libarchive  = green
@@ -4670,8 +4676,11 @@ RECIPE_MAINTAINER_pn-libarchive  = Xiaofeng Yan 
xiaofeng@windriver.com
 RECIPE_STATUS_pn-xserver-kdrive  = red
 RECIPE_MAINTAINER_pn-xserver-kdrive  = Xiaofeng Yan 
xiaofeng@windriver.com
 
-RECIPE_STATUS_pn-xserver-xf86-lite  = red
-RECIPE_MAINTAINER_pn-xserver-xf86-lite  = Xiaofeng Yan 
xiaofeng@windriver.com
+RECIPE_STATUS_pn-xserver-xorg-lite  = green
+RECIPE_LATEST_VERSION_pn-xserver-xorg-lite = 1.11.1
+RECIPE_LATEST_RELEASE_DATE_pn-xserver-xorg-lite = Sept 24, 2011
+RECIPE_LAST_UPDATE_pn-xserver-xorg-lite =  Sep 30,2011
+RECIPE_MAINTAINER_pn-xserver-xorg-lite  = Xiaofeng Yan 
xiaofeng@windriver.com
 
 RECIPE_STATUS_pn-libx11-trim = green
 DISTRO_PN_ALIAS_pn-libx11-trim = Debian=libx11-6 Fedora=libX11 
Ubuntu=libx11-6 OpenSuSE=xorg-x11-libX11
-- 
1.7.0.4


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

Re: [OE-core] [PATCH 3/9] gtk.inc: add directfb DISTRO_FEATURE

[Koen Kooi]

Op 24 nov. 2011, om 08:28 heeft Xiaofeng Yan het volgende geschreven:

 On 2011年11月24日 14:38, Koen Kooi wrote:
 Op 24 nov. 2011, om 04:06 heeft Xiaofeng Yan het volgende geschreven:
 
 
 From: Xiaofeng Yan xiaofeng@windriver.com
 
 
 gtk run over x11 at current OE-core. If gtk want to run over directfb, then 
 \
 the configuration related to x11 should be disabled and directfb should be 
 enabled.
 
 Apart from this patch is messing with PACKAGES as well, I still don't 
 believe it's true that x11 must be disabled for directfb to work
 
 
 
 As what I explained yesterday, One main goal of this image is to remove the 
 stuff related to x11 because I want to build an image only based on directfb 
 and run gtk over directfb.  

And you can do that perfectly well without disabling x11.

 you know, directfb as a graphic library is enough in many embedded 
 development. It has many advantages in embedded field like digital 
 television, set-top box, ...  Of course, it has its defect in other aspect. 
 So x11 is not needed in this image.  I just don't want to let user to take 
 too much time for building an image including directfb with no x11 during 
 developing product. 

I still don't see a decent reason for disabling x11 for directfb




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC PATCH 1/5] grub-efi-native: New recipe to build GRUB EFI images

[Koen Kooi]

Op 24 nov. 2011, om 09:05 heeft Darren Hart het volgende geschreven:

 Add a recipe to build the GRUB efi images. This recipe is written as
 a native recipe as the resulting GRUB utils are required to assemble
 the final image. Rather than build a native and a target recipe (and
 increase build times), 

That's a false dilemma. If you write it as a regular recipe with 
BBCLASSEXTEND=native your buildtime doesn't increase and you leave open the 
option of adding more BBCLASSEXTENDS if someone wants to ship it in an SDK.




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCHv2 1/2] libjson: add 0.9

[Koen Kooi]

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

Changes since v1:
* fix LICENSE

 meta/recipes-devtools/libjson/libjson_0.9.bb |   14 ++
 1 files changed, 14 insertions(+), 0 deletions(-)
 create mode 100644 meta/recipes-devtools/libjson/libjson_0.9.bb

diff --git a/meta/recipes-devtools/libjson/libjson_0.9.bb 
b/meta/recipes-devtools/libjson/libjson_0.9.bb
new file mode 100644
index 000..e4951a8
--- /dev/null
+++ b/meta/recipes-devtools/libjson/libjson_0.9.bb
@@ -0,0 +1,14 @@
+DESCRIPTION = JSON-C - A JSON implementation in C
+HOMEPAGE = http://oss.metaparadigm.com/json-c/;
+
+LICENSE = MIT
+LIC_FILES_CHKSUM = file://COPYING;md5=30a276a476b02c2dcd0849bde417fb17
+
+SRC_URI = http://oss.metaparadigm.com/json-c/json-c-${PV}.tar.gz;
+SRC_URI[md5sum] = 3a13d264528dcbaf3931b0cede24abae
+SRC_URI[sha256sum] = 
702a486c9bf8e19137d484ab5c49b4ad314eb5e1fe37062a72c0a0fa39439475
+
+S = ${WORKDIR}/json-c-${PV}
+
+
+inherit autotools
-- 
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] [PATCHv2 2/2] pulseaudio: update to 1.1, delete 0.9.x

[Koen Kooi]

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

Changes since v1:
* remove pulse from default-versions
* thumb1 has been verified to build

As indicated in the subject, this is an RFC, please review and test.
 
1) the ARM_INSTRUCTIONSET workarounds have been removed, so for people using 
thumb1, please test
2) this is only buildtested on armv7a, more buildtests and runtime tests are on 
their way, so please test 

 meta/conf/distro/include/default-versions.inc  |1 -
 .../pulseaudio/pulseaudio-0.9.22/armv4+v5asm.patch |   61 
 .../pulseaudio-0.9.22/autoconf_version.patch   |   17 --
 .../pulseaudio/pulseaudio-0.9.22/buildfix.patch|   17 --
 .../pulseaudio-0.9.22/configure_silent_rules.patch |   33 ---
 .../pulseaudio-0.9.22/gcc4-compile-fix.patch   |   22 ---
 .../pulseaudio/pulseaudio-0.9.22/tls_m4.patch  |   34 ---
 .../pulseaudio-0.9.22/volatiles.04_pulse   |2 -
 .../pulseaudio-0.9.23/autoconf_version.patch   |   17 --
 .../pulseaudio/pulseaudio-0.9.23/buildfix.patch|   17 --
 .../pulseaudio-0.9.23/configure_silent_rules.patch |   33 ---
 .../pulseaudio-0.9.23/fix_bluez_build.patch|   26 
 .../pulseaudio-0.9.23/gcc4-compile-fix.patch   |   22 ---
 .../pulseaudio/pulseaudio-0.9.23/tls_m4.patch  |   34 ---
 .../pulseaudio-0.9.23/volatiles.04_pulse   |2 -
 meta/recipes-multimedia/pulseaudio/pulseaudio.inc  |2 +-
 .../pulseaudio/pulseaudio/volatiles.04_pulse   |2 +
 .../pulseaudio/pulseaudio_0.9.22.bb|   24 
 .../pulseaudio/pulseaudio_0.9.23.bb|   27 -
 .../pulseaudio/pulseaudio_1.1.bb   |   19 ++
 20 files changed, 22 insertions(+), 390 deletions(-)
 delete mode 100644 
meta/recipes-multimedia/pulseaudio/pulseaudio-0.9.22/armv4+v5asm.patch
 delete mode 100644 
meta/recipes-multimedia/pulseaudio/pulseaudio-0.9.22/autoconf_version.patch
 delete mode 100644 
meta/recipes-multimedia/pulseaudio/pulseaudio-0.9.22/buildfix.patch
 delete mode 100644 
meta/recipes-multimedia/pulseaudio/pulseaudio-0.9.22/configure_silent_rules.patch
 delete mode 100644 
meta/recipes-multimedia/pulseaudio/pulseaudio-0.9.22/gcc4-compile-fix.patch
 delete mode 100644 
meta/recipes-multimedia/pulseaudio/pulseaudio-0.9.22/tls_m4.patch
 delete mode 100644 
meta/recipes-multimedia/pulseaudio/pulseaudio-0.9.22/volatiles.04_pulse
 delete mode 100644 
meta/recipes-multimedia/pulseaudio/pulseaudio-0.9.23/autoconf_version.patch
 delete mode 100644 
meta/recipes-multimedia/pulseaudio/pulseaudio-0.9.23/buildfix.patch
 delete mode 100644 
meta/recipes-multimedia/pulseaudio/pulseaudio-0.9.23/configure_silent_rules.patch
 delete mode 100644 
meta/recipes-multimedia/pulseaudio/pulseaudio-0.9.23/fix_bluez_build.patch
 delete mode 100644 
meta/recipes-multimedia/pulseaudio/pulseaudio-0.9.23/gcc4-compile-fix.patch
 delete mode 100644 
meta/recipes-multimedia/pulseaudio/pulseaudio-0.9.23/tls_m4.patch
 delete mode 100644 
meta/recipes-multimedia/pulseaudio/pulseaudio-0.9.23/volatiles.04_pulse
 create mode 100644 
meta/recipes-multimedia/pulseaudio/pulseaudio/volatiles.04_pulse
 delete mode 100644 meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.22.bb
 delete mode 100644 meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
 create mode 100644 meta/recipes-multimedia/pulseaudio/pulseaudio_1.1.bb

diff --git a/meta/conf/distro/include/default-versions.inc 
b/meta/conf/distro/include/default-versions.inc
index 90ff005..a86bc0c 100644
--- a/meta/conf/distro/include/default-versions.inc
+++ b/meta/conf/distro/include/default-versions.inc
@@ -1,7 +1,6 @@
 #
 # Default preferred versions
 #
-PREFERRED_VERSION_pulseaudio ?= 0.9.23
 
 # Force the python versions in one place
 PYTHON_BASEVERSION ?= 2.7
diff --git 
a/meta/recipes-multimedia/pulseaudio/pulseaudio-0.9.22/armv4+v5asm.patch 
b/meta/recipes-multimedia/pulseaudio/pulseaudio-0.9.22/armv4+v5asm.patch
deleted file mode 100644
index 4ce5a48..000
--- a/meta/recipes-multimedia/pulseaudio/pulseaudio-0.9.22/armv4+v5asm.patch
+++ /dev/null
@@ -1,61 +0,0 @@
-Derived from OE by Dongxiao Xu dongxiao...@intel.com
-
-Upstream-Status: Inappropriate [embedded specific]
-
-Index: pulseaudio-0.9.21/src/pulsecore/svolume_arm.c
-===
 pulseaudio-0.9.21.orig/src/pulsecore/svolume_arm.c
-+++ pulseaudio-0.9.21/src/pulsecore/svolume_arm.c
-@@ -37,6 +37,14 @@
- 
- #if defined (__arm__)
- 
-+/*
-+   the code below uses armv6 instructions; we can safely ifdef this away as 
the code is only
-+   called if the arm architecture is v6 or higher
-+*/
-+#if (!defined (__ARM_ARCH_4__)  !defined (__ARM_ARCH_4T__) \
-+   !defined (__ARM_ARCH_5__) !defined (__ARM_ARCH_5E__)  !defined 
(__ARM_ARCH_5T__) \
-+   !defined (__ARM_ARCH_5TE__)  !defined (__ARM_ARCH_5TEJ__))
-+
- #define MOD_INC() \
-  subs  

[OE-core] [PATCH 1/4] runqemu: look for *image* to be more flexible for image names

[Dexuan Cui]

From: Saul Wold s...@linux.intel.com

Signed-off-by: Saul Wold s...@linux.intel.com
---
 scripts/runqemu |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/runqemu b/scripts/runqemu
index 31e9822..a9a362f 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -114,7 +114,7 @@ while [ $i -le $# ]; do
 usage
 fi
 ;;
-*-image-*)
+*image*)
 if [ -z $ROOTFS ]; then
 if [ -f $arg ]; then
 process_filename $arg
@@ -307,7 +307,7 @@ findimage() {
 
 # Sort rootfs candidates by modification time - the most
 # recently created one is the one we most likely want to boot.
-filenames=`ls -t $where/*core-image*$machine.$extension 2/dev/null | 
xargs`
+filenames=`ls -t $where/*image*$machine.$extension 2/dev/null | xargs`
 for name in $filenames; do
 if [[ $name =~ core-image-sato-sdk ||
   $name =~ core-image-sato ||
-- 
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 2/4] gcc-package-target.inc: add the symbol link /lib/cpp

[Dexuan Cui]

Signed-off-by: Dexuan Cui dexuan@intel.com
---
 meta/recipes-devtools/gcc/gcc-4.6.inc|2 +-
 meta/recipes-devtools/gcc/gcc-package-target.inc |2 ++
 2 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/meta/recipes-devtools/gcc/gcc-4.6.inc 
b/meta/recipes-devtools/gcc/gcc-4.6.inc
index 7bf14e3..7cd0850 100644
--- a/meta/recipes-devtools/gcc/gcc-4.6.inc
+++ b/meta/recipes-devtools/gcc/gcc-4.6.inc
@@ -1,6 +1,6 @@
 require gcc-common.inc
 
-PR = r17
+PR = r18
 
 # Third digit in PV should be incremented after a minor release
 # happens from this branch on gcc e.g. currently its 4.6.0
diff --git a/meta/recipes-devtools/gcc/gcc-package-target.inc 
b/meta/recipes-devtools/gcc/gcc-package-target.inc
index f0f1a04..3076670 100644
--- a/meta/recipes-devtools/gcc/gcc-package-target.inc
+++ b/meta/recipes-devtools/gcc/gcc-package-target.inc
@@ -122,6 +122,8 @@ do_install () {
ln -sf ${TARGET_PREFIX}g++ g++
ln -sf ${TARGET_PREFIX}gcc gcc
ln -sf ${TARGET_PREFIX}cpp cpp
+   install -d ${D}${base_libdir}
+   ln -sf ${bindir}/${TARGET_PREFIX}cpp ${D}${base_libdir}/cpp
ln -sf g++ c++
ln -sf gcc cc
 
-- 
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 4/4] coreutils: build and install hostname

[Dexuan Cui]

busybox's hostname doesn't work with pseudo somehow, so let's use the version
of coreutils. This is needed for the self-hosted-image work.

Also add a patch to disable building the doc and manual: we don't really need
them and this causes compilation error in the cross-compiling case.

Signed-off-by: Dexuan Cui dexuan@intel.com
---
 .../coreutils/coreutils-8.14/disable_doc_man.patch |   36 
 meta/recipes-core/coreutils/coreutils_8.14.bb  |9 +++--
 2 files changed, 41 insertions(+), 4 deletions(-)
 create mode 100644 
meta/recipes-core/coreutils/coreutils-8.14/disable_doc_man.patch

diff --git a/meta/recipes-core/coreutils/coreutils-8.14/disable_doc_man.patch 
b/meta/recipes-core/coreutils/coreutils-8.14/disable_doc_man.patch
new file mode 100644
index 000..c9dc92c
--- /dev/null
+++ b/meta/recipes-core/coreutils/coreutils-8.14/disable_doc_man.patch
@@ -0,0 +1,36 @@
+Upstream-Status: Inappropriate [embedded specific]
+
+We don't really need to build the doc and manual.
+
+Morever, we get this failure in do_compile:
+help2man: can't get `--help' info from hostname.td/hostname
+
+This is because help2man tries to invoke hostname --help, but in the
+cross-compile case, the target binary may not be execuable on the host.
+
+Signed-off-by: Dexuan Cui dexuan@intel.com
+
+diff -Nru coreutils-8.14/Makefile.am coreutils-8.14/Makefile.am
+--- coreutils-8.14.orig/Makefile.am2011-10-10 15:30:55.0 +0800
 coreutils-8.14/Makefile.am 2011-11-24 17:29:26.398593744 +0800
+@@ -17,7 +17,7 @@
+ 
+ ALL_RECURSIVE_TARGETS =
+ 
+-SUBDIRS = lib src doc man po tests gnulib-tests
++SUBDIRS = lib src po tests gnulib-tests
+ 
+ changelog_etc =   \
+   ChangeLog-2005  \
+diff -Nru coreutils-8.14.orig/Makefile.in coreutils-8.14/Makefile.in
+--- coreutils-8.14.orig/Makefile.in2011-10-12 17:21:46.0 +0800
 coreutils-8.14/Makefile.in 2011-11-24 17:29:14.868593748 +0800
+@@ -1453,7 +1453,7 @@
+ 
+ # Some tests always need root privileges, others need them only sometimes.
+ ALL_RECURSIVE_TARGETS = install-root check-root distcheck-hook
+-SUBDIRS = lib src doc man po tests gnulib-tests
++SUBDIRS = lib src po tests gnulib-tests
+ changelog_etc = \
+   ChangeLog-2005  \
+   ChangeLog-2006  \
diff --git a/meta/recipes-core/coreutils/coreutils_8.14.bb 
b/meta/recipes-core/coreutils/coreutils_8.14.bb
index 01face0..ec41fe2 100644
--- a/meta/recipes-core/coreutils/coreutils_8.14.bb
+++ b/meta/recipes-core/coreutils/coreutils_8.14.bb
@@ -7,7 +7,7 @@ BUGTRACKER = http://debbugs.gnu.org/coreutils;
 LICENSE = GPLv3+
 LIC_FILES_CHKSUM = file://COPYING;md5=d32239bcb673463ab874e80d47fae504\
 
file://src/ls.c;startline=5;endline=16;md5=e1a509558876db58fb6667ba140137ad
-PR = r1
+PR = r2
 DEPENDS = gmp
 DEPENDS_virtclass-native = 
 
@@ -15,10 +15,13 @@ inherit autotools gettext
 
 SRC_URI = ${GNU_MIRROR}/coreutils/${BP}.tar.xz \
file://remove-usr-local-lib-from-m4.patch \
+   file://disable_doc_man.patch \
   
 SRC_URI[md5sum] = bcb135ce553493a45aba01b39eb3920a
 SRC_URI[sha256sum] = 
0d120817c19292edb19e92ae6b8eac9020e03d51e0af9cb116cf82b65d18b02d
 
+EXTRA_OECONF += --enable-install-program=hostname
+
 EXTRA_OECONF_virtclass-native = --without-gmp
 
 # [ gets a special treatment and is not included in this
@@ -29,9 +32,8 @@ bindir_progs = base64 basename chcon cksum comm csplit cut 
dir dircolors dirnam
 sha384sum sha512sum shred shuf sort split stat stdbuf sum tac 
tail tee test timeout\
 tr truncate tsort tty unexpand uniq unlink uptime users vdir 
wc who whoami yes df
 
-# hostname gets a special treatment and is not included in this
 base_bindir_progs = cat chgrp chmod chown cp date dd echo false kill ln ls 
mkdir \
- mknod mv pwd rm rmdir sleep stty sync touch true uname
+ mknod mv pwd rm rmdir sleep stty sync touch true uname 
hostname
 
 sbindir_progs= chroot
 
@@ -71,7 +73,6 @@ pkg_prerm_${PN} () {
for i in ${sbindir_progs}; do update-alternatives --remove $i $i.${PN}; 
done
 
# The special cases
-   update-alternatives --remove hostname hostname.${PN}
update-alternatives --remove uptime uptime.${PN}
update-alternatives --remove '[' 'lbracket.${PN}'
 }
-- 
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] Self Hosted Image: Added Task and Images

[Dexuan Cui]

From: Saul Wold s...@linux.intel.com

This is the first pass of creating a self hosted image, this task
and image can pass bitbake's sanity check (if modified to remove the
cvs check) and can build psuedo, albit very slowly on qemu.

Signed-off-by: Saul Wold s...@linux.intel.com
Signed-off-by: Dexuan Cui dexuan@intel.com
Signed-off-by: Zhai Edwin edwin.z...@intel.com
---
 meta/recipes-core/images/self-hosted-image.bb |   11 ++
 meta/recipes-core/tasks/task-self-hosted.bb   |  174 +
 2 files changed, 185 insertions(+), 0 deletions(-)
 create mode 100644 meta/recipes-core/images/self-hosted-image.bb
 create mode 100644 meta/recipes-core/tasks/task-self-hosted.bb

diff --git a/meta/recipes-core/images/self-hosted-image.bb 
b/meta/recipes-core/images/self-hosted-image.bb
new file mode 100644
index 000..7ddba9c
--- /dev/null
+++ b/meta/recipes-core/images/self-hosted-image.bb
@@ -0,0 +1,11 @@
+IMAGE_INSTALL = task-core-boot task-core-apps-console task-core-ssh-openssh 
task-self-hosted
+
+POKY_EXTRA_INSTALL = \
+task-self-hosted \
+
+
+IMAGE_ROOTFS_EXTRA_SPACE = 1048576
+
+inherit core-image
+
+PR = r0
diff --git a/meta/recipes-core/tasks/task-self-hosted.bb 
b/meta/recipes-core/tasks/task-self-hosted.bb
new file mode 100644
index 000..c218f43
--- /dev/null
+++ b/meta/recipes-core/tasks/task-self-hosted.bb
@@ -0,0 +1,174 @@
+#
+# Copyright (C) 2010 Intel Corporation
+#
+
+DESCRIPTION = Create Basic Image Tasks
+PR = r0
+LICENSE = MIT
+LIC_FILES_CHKSUM = 
file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
+
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420
+
+PACKAGES = \
+task-self-hosted \
+task-self-hosted-debug \
+task-self-hosted-sdk \
+task-self-hosted-extended \
+task-self-hosted-graphics \
+
+
+ALLOW_EMPTY = 1
+
+RDEPENDS_task-self-hosted = \
+task-self-hosted-debug \
+task-self-hosted-sdk \
+task-self-hosted-extended \
+task-self-hosted-graphics \
+
+
+# eglibc-utils: for rpcgen
+RDEPENDS_task-self-hosted-sdk = \
+sed \
+mktemp \
+eglibc-utils \
+autoconf \
+automake \
+binutils-symlinks \
+binutils \
+cpp \
+cpp-symlinks \
+ccache \
+gcc \
+gcc-symlinks \
+g++ \
+g++-symlinks \
+gettext \
+make \
+intltool \
+libstdc++ \
+libstdc++-dev \
+libtool \
+perl-module-re \
+perl-module-text-wrap \
+coreutils \
+diffutils \
+pkgconfig \
+findutils \
+quilt \
+less \
+distcc \
+ldd \
+file \
+tcl \
+
+
+RDEPENDS_task-self-hosted-debug =  \
+gdb \
+gdbserver \
+tcf-agent \
+rsync \
+strace
+
+
+RDEPENDS_task-self-hosted-extended = \
+binutils \
+bzip2 \
+chkconfig \
+chrpath \
+curl \
+dhcp-client \
+diffstat \
+diffutils \
+elfutils \
+expat \
+gamin \
+gdbm \
+git \
+gettext \
+gettext-runtime \
+grep \
+groff \
+gawk \
+hdparm \
+libaio \
+libxml2 \
+libusb1 \
+lrzsz \
+lsof \
+lzo \
+man \
+man-pages \
+mc \
+mdadm \
+minicom \
+mtools \
+ncurses \
+neon \
+openssl \
+opkg \
+opkg-utils \
+parted \
+patch \
+perl \
+perl-modules \
+perl-dev \
+pth \
+python \
+python-compile \
+python-compiler \
+python-core \
+python-curses \
+python-datetime \
+python-distutils \
+python-elementtree \
+python-fcntl \
+python-logging \
+python-misc \
+python-multiprocessing \
+python-netclient \
+python-netserver \
+python-pickle \
+python-re \
+python-rpm \
+python-shell \
+python-sqlite3 \
+python-subprocess \
+python-textutils \
+python-xmlrpc \
+python-email \
+python-unixadmin \
+python-compression \
+quota \
+readline \
+rpm \
+screen \
+setserial \
+strace \
+subversion \
+sysstat \
+tar \
+gzip \
+tcl \
+texi2html \
+texinfo \
+usbutils \
+unzip \
+watchdog \
+wget \
+which \
+xinetd \
+zip \
+zlib \
+cpio \
+
+
+
+RDEPENDS_task-self-hosted-graphics = \
+python-pygtk \
+mesa-dri \
+mesa-dri-dev \
+libglu \
+libglu-dev \
+libsdl \
+libsdl-dev \
+libx11-dev \
+
-- 
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/4] self-hosted-image: the first set of patch

[Dexuan Cui]

This is the first patchset for the task Build Applianc: self-hosted-image:
https://wiki.yoctoproject.org/wiki/Build_Appliance_Design

The only notable issue left is:
there is an eglibc_initial do_insall failure that seems be caused by make-3.82.
If we downgrade to make-3.81(the hacking patch is at
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=gzhai/build-applianceid=981a37e3e031e7c96361c1c170050ab3cdbadf6c),
bitbake core-image-minimal in the target can build fine. The built image can
run fine with host's qemu (in target, runqemu doesn't work yet as at least
sudo is absent -- we're fixing this).

The above patchset was done by the Build Appliance development team, including
Saul, Edwin and me.

Though there are still some known issues, now we want to share the patches.
Please review, comment and merge them(if they seem good :-).


Thanks!

-- Dexuan, on behalf of the team


The following changes since commit dc2d701207435b0dbd521a11d152f11d0f18d11e:

  apt: Fix locale header and hardcoded libname issues (2011-11-23 23:41:09 
+)

are available in the git repository at:
  git://git.pokylinux.org/poky-contrib dcui/self-hosted-v2
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dcui/self-hosted-v2

Dexuan Cui (2):
  gcc-package-target.inc: add the symbol link /lib/cpp
  coreutils: build and install hostname

Saul Wold (2):
  runqemu: look for *image* to be more flexible for image names
  Self Hosted Image: Added Task and Images

 .../coreutils/coreutils-8.14/disable_doc_man.patch |   36 
 meta/recipes-core/coreutils/coreutils_8.14.bb  |9 +-
 meta/recipes-core/images/self-hosted-image.bb  |   11 ++
 meta/recipes-core/tasks/task-self-hosted.bb|  174 
 meta/recipes-devtools/gcc/gcc-4.6.inc  |2 +-
 meta/recipes-devtools/gcc/gcc-package-target.inc   |2 +
 scripts/runqemu|4 +-
 7 files changed, 231 insertions(+), 7 deletions(-)
 create mode 100644 
meta/recipes-core/coreutils/coreutils-8.14/disable_doc_man.patch
 create mode 100644 meta/recipes-core/images/self-hosted-image.bb
 create mode 100644 meta/recipes-core/tasks/task-self-hosted.bb

-- 
1.7.6


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

Re: [OE-core] [RFC] gcc-cross.inc: Add depedency on BUILD_ARCH

[Richard Purdie]

On Thu, 2011-11-24 at 07:29 +, McClintock Matthew-B29882 wrote:
 On Thu, Nov 24, 2011 at 1:21 AM, Khem Raj raj.k...@gmail.com wrote:
  hmmm I guess cross recipes are special they should not have been built
  under target recipes. Adding build arch to package name would be ok
  too but may be if they were built under directory of their own which
  was something like build-host-target then it would also solve
  the problem i think
 
 I agree - this is the discussion I'm trying to start. ;)

I haven't had a chance to look into this in detail but the cross recipes
have been bothering me for a *long* time. I keep taking chunks of time
and dealing with issues. For example, packaging no longer happens in any
of the cross recipes, thankfully. We can share the gcc sources directory
and so on.

Those changes all open up the possibility of moving them to the native
build directory. The only missing piece left is suffixing the recipe
names with the TARGET_ARCH (like gcc-cross-canadian does, its been proof
of concept'd there).

Cheers,

Richard




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

Re: [OE-core] [RFC] gcc-cross.inc: Add depedency on BUILD_ARCH

[Phil Blundell]

On Thu, 2011-11-24 at 07:29 +, McClintock Matthew-B29882 wrote:
 On Thu, Nov 24, 2011 at 1:21 AM, Khem Raj raj.k...@gmail.com wrote:
  hmmm I guess cross recipes are special they should not have been built
  under target recipes. Adding build arch to package name would be ok
  too but may be if they were built under directory of their own which
  was something like build-host-target then it would also solve
  the problem i think
 
 I agree - this is the discussion I'm trying to start. ;)

It's certainly true that the way the cross recipes are done at the
moment does suck.  Really, they should be built as primarily native and
the target arch ought to just be encoded into ${PN} somehow, rather than
the current arrangement of pretending that they are target recipes.
(All the runtime bits are, or should be, packaged separately by either
libgcc or gcc-runtime so they will already get the right PACKAGE_ARCH.)

There are some old (and probably rather bit-rotten) patches to do that
in the pb/toolchain-desuck branch of oe-classic.  I'm not sure whether
any of that stuff will apply to modern oe-core but the general principle
ought still to be valid.

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/7] Distro Tracking and Patch Status

[Richard Purdie]

On Tue, 2011-11-22 at 17:18 -0800, Saul Wold wrote:
 Richard,
 
 This should be a pretty straight forward set of changes
 to the distro_tracking_fields and patch Status Updates.
 
 Please review and pull.
 
 Thanks
   Sau!
 
 
 The following changes since commit 381c7857a5b303bf9eadd7fffc39d17a2b8e31f2:
 
   matchbox-wm: Fix variable type in _NET_WORKAREA setting (2011-11-22 
 15:13:16 +)
 
 are available in the git repository at:
   git://git.openembedded.org/openembedded-core-contrib sgw/distro_track
   
 http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=sgw/distro_track
 
 Nitin A Kamble (1):
   at: update the upstream-status of patches
 
 Saul Wold (2):
   distro_tracking: Refect Recipe Updates  Status
   distro_tracking_fields: Update after Manual Check
 
 Scott Garman (1):
   distro_tracking: update manual checks for various recipes
 
 Shane Wang (3):
   distro_tracking: update manual checks for recipes
   distro_tracking: update manual checks for recipes
   distro_tracking: update manual checks for recipes

Merged to master, thanks.

Richard


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

Re: [OE-core] [PATCH 3/9] gtk.inc: add directfb DISTRO_FEATURE

[Phil Blundell]

On Thu, 2011-11-24 at 07:38 +0100, Koen Kooi wrote:
 Op 24 nov. 2011, om 04:06 heeft Xiaofeng Yan het volgende geschreven:
 
  From: Xiaofeng Yan xiaofeng@windriver.com
  
  gtk run over x11 at current OE-core. If gtk want to run over directfb, then 
  \
  the configuration related to x11 should be disabled and directfb should be 
  enabled.
 
 Apart from this patch is messing with PACKAGES as well, I still don't believe 
 it's true that x11 must be disabled for directfb to work

[...]

 +PACKAGECONFIG ??= ${@base_contains('DISTRO_FEATURES', 'x11', 'x11', '', d)} 
 \
 +   ${@base_contains('DISTRO_FEATURES', 'directfb', 'directfb', '', 
 d)}
 +
 +PACKAGECONFIG[x11] = --with-x=yes 
 --with-gdktarget=x11,--with-x=no,${X11DEPENDS}
 +PACKAGECONFIG[directfb] = --with-gdktarget=directfb,,directfb

If you're using a version of GTK+ which expects the --with-gdktarget
option then I think it is true that X11 and directfb are exclusive since
you can only have one backend enabled at a time.  There's nothing you
can do in the recipe that will help with this, though it would be nice
if you got a sensible diagnostic rather than one of the options just
being silently ignored.

With newer versions (3.0 and later, I think) there are separate
--enable-FOO-backend options for the different backends and you can turn
on as many as you want at the same time.  In those versions I don't
think --with-gdktarget will do anything useful at all so this patch
won't work.

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/5] Fixes for uclibc based builds

[Richard Purdie]

On Sun, 2011-11-20 at 09:50 -0800, Khem Raj wrote:
 This pull request has patches needed for core-image-sato to build with uclibc
 gcc update needed for fixes qt4 ICE seen on armv7-a
 Fix to matchbox to get core-image-sato building with gold linker
 
 The following changes since commit 0a9b1f504e685351921e27e42452f51630d64cd3:
 
   gcc-4.6: Fix gcc ICE on qt4-x11-free/armv7-a (2011-11-20 09:39:36 -0800)
 
 are available in the git repository at:
   git://git.openembedded.org/openembedded-core-contrib kraj/uclibc-updates
   
 http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=kraj/uclibc-updates
 
 Khem Raj (5):
   matchbox-stroke: Fix linking error with gold
   gettext_0.18.1.1: Fix QA Issue
   pulseaudio-0.9.23: Fix build on uclibc
   netbase: Update recipe 4.46 - 4.47
   gcc-4.6: Fix gcc ICE on qt4-x11-free/armv7-a

These have merged to master, apart from the matchbox-stroke change where
I've updated to a new revision of the upstream repo instead which should
fix the problem.

Cheers,

Richard


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

Re: [OE-core] [PATCHv2 2/2] pulseaudio: update to 1.1, delete 0.9.x

[Koen Kooi]

This one is still RFC, I screwed up with git-send-email.

Op 24 nov. 2011, om 10:18 heeft Koen Kooi het volgende geschreven:

 Signed-off-by: Koen Kooi k...@dominion.thruhere.net
 ---
 
 Changes since v1:
   * remove pulse from default-versions
   * thumb1 has been verified to build
 
 As indicated in the subject, this is an RFC, please review and test.
 
 1) the ARM_INSTRUCTIONSET workarounds have been removed, so for people using 
 thumb1, please test
 2) this is only buildtested on armv7a, more buildtests and runtime tests are 
 on their way, so please test 
 
 meta/conf/distro/include/default-versions.inc  |1 -
 .../pulseaudio/pulseaudio-0.9.22/armv4+v5asm.patch |   61 
 .../pulseaudio-0.9.22/autoconf_version.patch   |   17 --
 .../pulseaudio/pulseaudio-0.9.22/buildfix.patch|   17 --
 .../pulseaudio-0.9.22/configure_silent_rules.patch |   33 ---
 .../pulseaudio-0.9.22/gcc4-compile-fix.patch   |   22 ---
 .../pulseaudio/pulseaudio-0.9.22/tls_m4.patch  |   34 ---
 .../pulseaudio-0.9.22/volatiles.04_pulse   |2 -
 .../pulseaudio-0.9.23/autoconf_version.patch   |   17 --
 .../pulseaudio/pulseaudio-0.9.23/buildfix.patch|   17 --
 .../pulseaudio-0.9.23/configure_silent_rules.patch |   33 ---
 .../pulseaudio-0.9.23/fix_bluez_build.patch|   26 
 .../pulseaudio-0.9.23/gcc4-compile-fix.patch   |   22 ---
 .../pulseaudio/pulseaudio-0.9.23/tls_m4.patch  |   34 ---
 .../pulseaudio-0.9.23/volatiles.04_pulse   |2 -
 meta/recipes-multimedia/pulseaudio/pulseaudio.inc  |2 +-
 .../pulseaudio/pulseaudio/volatiles.04_pulse   |2 +
 .../pulseaudio/pulseaudio_0.9.22.bb|   24 
 .../pulseaudio/pulseaudio_0.9.23.bb|   27 -
 .../pulseaudio/pulseaudio_1.1.bb   |   19 ++
 20 files changed, 22 insertions(+), 390 deletions(-)
 delete mode 100644 
 meta/recipes-multimedia/pulseaudio/pulseaudio-0.9.22/armv4+v5asm.patch
 delete mode 100644 
 meta/recipes-multimedia/pulseaudio/pulseaudio-0.9.22/autoconf_version.patch
 delete mode 100644 
 meta/recipes-multimedia/pulseaudio/pulseaudio-0.9.22/buildfix.patch
 delete mode 100644 
 meta/recipes-multimedia/pulseaudio/pulseaudio-0.9.22/configure_silent_rules.patch
 delete mode 100644 
 meta/recipes-multimedia/pulseaudio/pulseaudio-0.9.22/gcc4-compile-fix.patch
 delete mode 100644 
 meta/recipes-multimedia/pulseaudio/pulseaudio-0.9.22/tls_m4.patch
 delete mode 100644 
 meta/recipes-multimedia/pulseaudio/pulseaudio-0.9.22/volatiles.04_pulse
 delete mode 100644 
 meta/recipes-multimedia/pulseaudio/pulseaudio-0.9.23/autoconf_version.patch
 delete mode 100644 
 meta/recipes-multimedia/pulseaudio/pulseaudio-0.9.23/buildfix.patch
 delete mode 100644 
 meta/recipes-multimedia/pulseaudio/pulseaudio-0.9.23/configure_silent_rules.patch
 delete mode 100644 
 meta/recipes-multimedia/pulseaudio/pulseaudio-0.9.23/fix_bluez_build.patch
 delete mode 100644 
 meta/recipes-multimedia/pulseaudio/pulseaudio-0.9.23/gcc4-compile-fix.patch
 delete mode 100644 
 meta/recipes-multimedia/pulseaudio/pulseaudio-0.9.23/tls_m4.patch
 delete mode 100644 
 meta/recipes-multimedia/pulseaudio/pulseaudio-0.9.23/volatiles.04_pulse
 create mode 100644 
 meta/recipes-multimedia/pulseaudio/pulseaudio/volatiles.04_pulse
 delete mode 100644 meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.22.bb
 delete mode 100644 meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
 create mode 100644 meta/recipes-multimedia/pulseaudio/pulseaudio_1.1.bb
 
 diff --git a/meta/conf/distro/include/default-versions.inc 
 b/meta/conf/distro/include/default-versions.inc
 index 90ff005..a86bc0c 100644
 --- a/meta/conf/distro/include/default-versions.inc
 +++ b/meta/conf/distro/include/default-versions.inc
 @@ -1,7 +1,6 @@
 #
 # Default preferred versions
 #
 -PREFERRED_VERSION_pulseaudio ?= 0.9.23
 
 # Force the python versions in one place
 PYTHON_BASEVERSION ?= 2.7
 diff --git 
 a/meta/recipes-multimedia/pulseaudio/pulseaudio-0.9.22/armv4+v5asm.patch 
 b/meta/recipes-multimedia/pulseaudio/pulseaudio-0.9.22/armv4+v5asm.patch
 deleted file mode 100644
 index 4ce5a48..000
 --- a/meta/recipes-multimedia/pulseaudio/pulseaudio-0.9.22/armv4+v5asm.patch
 +++ /dev/null
 @@ -1,61 +0,0 @@
 -Derived from OE by Dongxiao Xu dongxiao...@intel.com
 -
 -Upstream-Status: Inappropriate [embedded specific]
 -
 -Index: pulseaudio-0.9.21/src/pulsecore/svolume_arm.c
 -===
  pulseaudio-0.9.21.orig/src/pulsecore/svolume_arm.c
 -+++ pulseaudio-0.9.21/src/pulsecore/svolume_arm.c
 -@@ -37,6 +37,14 @@
 - 
 - #if defined (__arm__)
 - 
 -+/*
 -+   the code below uses armv6 instructions; we can safely ifdef this away as 
 the code is only
 -+   called if the arm architecture is v6 or higher
 -+*/
 -+#if (!defined (__ARM_ARCH_4__)  !defined (__ARM_ARCH_4T__) \
 -+ 

Re: [OE-core] [PATCH 2/4] gcc-package-target.inc: add the symbol link /lib/cpp

[Richard Purdie]

On Thu, 2011-11-24 at 18:08 +0800, Dexuan Cui wrote:
 Signed-off-by: Dexuan Cui dexuan@intel.com
 ---
  meta/recipes-devtools/gcc/gcc-4.6.inc|2 +-
  meta/recipes-devtools/gcc/gcc-package-target.inc |2 ++
  2 files changed, 3 insertions(+), 1 deletions(-)
 
 diff --git a/meta/recipes-devtools/gcc/gcc-4.6.inc 
 b/meta/recipes-devtools/gcc/gcc-4.6.inc
 index 7bf14e3..7cd0850 100644
 --- a/meta/recipes-devtools/gcc/gcc-4.6.inc
 +++ b/meta/recipes-devtools/gcc/gcc-4.6.inc
 @@ -1,6 +1,6 @@
  require gcc-common.inc
  
 -PR = r17
 +PR = r18
  
  # Third digit in PV should be incremented after a minor release
  # happens from this branch on gcc e.g. currently its 4.6.0
 diff --git a/meta/recipes-devtools/gcc/gcc-package-target.inc 
 b/meta/recipes-devtools/gcc/gcc-package-target.inc
 index f0f1a04..3076670 100644
 --- a/meta/recipes-devtools/gcc/gcc-package-target.inc
 +++ b/meta/recipes-devtools/gcc/gcc-package-target.inc
 @@ -122,6 +122,8 @@ do_install () {
   ln -sf ${TARGET_PREFIX}g++ g++
   ln -sf ${TARGET_PREFIX}gcc gcc
   ln -sf ${TARGET_PREFIX}cpp cpp
 + install -d ${D}${base_libdir}
 + ln -sf ${bindir}/${TARGET_PREFIX}cpp ${D}${base_libdir}/cpp
   ln -sf g++ c++
   ln -sf gcc cc

Why do we need this change?

Cheers,

Richard




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

Re: [OE-core] [RFC PATCH 1/5] grub-efi-native: New recipe to build GRUB EFI images

[Richard Purdie]

On Thu, 2011-11-24 at 09:59 +0100, Koen Kooi wrote:
 Op 24 nov. 2011, om 09:05 heeft Darren Hart het volgende geschreven:
 
  Add a recipe to build the GRUB efi images. This recipe is written as
  a native recipe as the resulting GRUB utils are required to assemble
  the final image. Rather than build a native and a target recipe (and
  increase build times), 
 
 That's a false dilemma. If you write it as a regular recipe with
 BBCLASSEXTEND=native your buildtime doesn't increase

That isn't true, if you build a target and a native version your build
time does increase. Using BBCLASSEXTEND does improve parsing time over
having two separate recipes though.

  and you leave open the option of adding more BBCLASSEXTENDS if
 someone wants to ship it in an SDK.

I did talk with Darren about why the recipe is the way it is and there
are some pretty nasty issues with the way grub builds itself. I'm
therefore ok with this as a version 1 and we can see whether there are
any issues that result which need us to rethink the way the recipe is
constructed. 

Its currently behaving very like the way the binutils/gcc cross recipes
will end up (see the separate thread with Matthew) Perhaps it should be
called grub-efi-cross even if it uses native.bbclass.

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 v2] Introduce multiarch DISTRO_FEATURE

[Julian Pidancet]

 +def get_gcc_multiarch_setting(bb, d):
 +    if 'multiarch' in bb.data.getVar('DISTRO_FEATURES',d,1).split() :
 +        if bb.data.getVar('TARGET_ARCH', d, 1) in [ 'i586', 'i686' ] :
 +            return --enable-targets=all
 +        if bb.data.getVar('TARGET_ARCH', d, 1) in [ 'powerpc' ] :
 +            return --enable-targets=powerpc64
 +        if bb.data.getVar('TARGET_ARCH', d, 1) in [ 'sparc' ] :
 +            return --enable-targets=all
 +    return 


 you forgot mips here


mips and s390 are not yet supported in the gcc version that OE is using.

-- 
Julian

___
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] directfb: change check sum

[Richard Purdie]

On Wed, 2011-11-23 at 20:59 +0100, Koen Kooi wrote:
 Op 23 nov. 2011, om 20:36 heeft Saul Wold het volgende geschreven:
 
  On 11/22/2011 11:37 PM, Koen Kooi wrote:
  
  Op 23 nov. 2011, om 08:21 heeft Xiaofeng Yan het volgende
 geschreven:
  
  From: Xiaofeng Yanxiaofeng@windriver.com
  
  Change check sum of directfb. The previous check sum is wrong.
  
  Why is it wrong? What has changed?
  
  
  Seems that when the recipe update occurred, the checksums where not
 properly updated at the same time, this is a valid and needed patch as
 it corrects the checksums for the 1.4.15 tarball.
 
 Now put that in the commit message :)

I merged this with an updated commit message.

Cheers,

Richard


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

[OE-core] [PATCH] base.bbclass: Use bb.plain to print the build header

[Richard Purdie]

If we just use print, the bitbake logging functions don't see the message
and it can get lost if bitbake is for example logging messages to disk.

Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index ba1f230..72196d6 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -232,7 +232,7 @@ python base_eventhandler() {
 
statuslines += layers_branch_rev
statusmsg = \nOE Build Configuration:\n%s\n % 
'\n'.join(statuslines)
-   print statusmsg
+   bb.plain(statusmsg)
 
needed_vars = [ TARGET_ARCH, TARGET_OS ]
pesteruser = []



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

[OE-core] [PATCH] bitbake.conf: Set BB_CONSOLELOG so we log console messages by default

[Richard Purdie]

Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 01f064c..4589909 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -732,6 +732,8 @@ DISTRO[unexport] = 1
 # Used by canadian-cross to handle string conversions on TARGET_ARCH where 
needed
 TRANSLATED_TARGET_ARCH ??= ${@d.getVar('TARGET_ARCH', True).replace(_, 
-)}
 
+BB_CONSOLELOG = ${TMPDIR}/cooker.log.${DATETIME}
+
 # Setup our default hash policy
 BB_SIGNATURE_HANDLER ?= basic
 BB_HASHTASK_WHITELIST ?= 
(.*-cross$|.*-native$|.*-cross-initial$|.*-cross-intermediate$|^virtual:native:.*|^virtual:nativesdk:.*)



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

[OE-core] [PATCH] avahi-ui: Fix packaging and conflict with the avahi recipe

[Richard Purdie]

We need to remove the files from avahi-ui which conflict with the avahi recipe.
If we don't do this they trigger packaging warnings and can also overwrite
files in the sysroot unexpectedly causing build failures (if X depends on
avahi, it expects avahi's files to stay there, not disappear as avahi-ui
build/stages).

This patch cleans up the packaging although I wish there were an alternative
to the do_install which makes my eyes bleed.

Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/recipes-connectivity/avahi/avahi-ui_0.6.30.bb 
b/meta/recipes-connectivity/avahi/avahi-ui_0.6.30.bb
index e0733a9..c903087 100644
--- a/meta/recipes-connectivity/avahi/avahi-ui_0.6.30.bb
+++ b/meta/recipes-connectivity/avahi/avahi-ui_0.6.30.bb
@@ -6,7 +6,7 @@ LIC_FILES_CHKSUM = 
file://LICENSE;md5=2d5025d4aa3495befef8f17206a5b0a1 \
 
 require avahi.inc
 
-PR = ${INC_PR}.0
+PR = ${INC_PR}.1
 
 DEPENDS += avahi gtk+ libglade
 
@@ -14,7 +14,7 @@ AVAHI_GTK = --enable-gtk --disable-gtk3
 
 S = ${WORKDIR}/avahi-${PV}
 
-PACKAGES = ${PN} ${PN}-utils ${PN}-dbg ${PN}-dev python-avahi avahi-discover 
avahi-discover-standalone
+PACKAGES = ${PN} ${PN}-utils ${PN}-dbg ${PN}-dev ${PN}-doc python-avahi 
avahi-discover avahi-discover-standalone
 
 FILES_${PN} = ${libdir}/libavahi-ui*.so.*
 FILES_${PN}-dbg += ${libdir}/.debug/libavah-ui*
@@ -25,7 +25,7 @@ FILES_${PN}-utils = ${bindir}/b* ${datadir}/applications/b*
 FILES_python-avahi = ${PYTHON_SITEPACKAGES_DIR}/avahi/*
 FILES_avahi-discover = ${bindir}/avahi-discover \
 ${datadir}/applications/avahi-discover.desktop \
-${datadir}/avahi/interfaces/avahi-discover.glade
+${datadir}/avahi/interfaces/avahi-discover*
 FILES_avahi-discover-standalone = ${bindir}/avahi-discover-standalone \

${datadir}/avahi/interfaces/avahi-discover.glade
 
@@ -35,3 +35,29 @@ RDEPENDS_python-avahi = python-dbus
 
 SRC_URI[md5sum] = e4db89a2a403ff4c47d66ac66fad1f43
 SRC_URI[sha256sum] = 
f9e4316c2339d0020726edd846d01bee0c39980906db0c247479e5807457ff1f
+
+do_install_append () {
+   rm ${D}${sysconfdir} -rf
+   rm ${D}${base_libdir} -rf
+   rm ${D}${base_libdir} -rf
+   rm ${D}${bindir}/avahi-b*
+   rm ${D}${bindir}/avahi-p*
+   rm ${D}${bindir}/avahi-r*
+   rm ${D}${bindir}/avahi-s*
+   rm ${D}${includedir}/avahi-c* -rf
+   rm ${D}${includedir}/avahi-g* -rf
+   rm ${D}${libdir}/libavahi-c*
+   rm ${D}${libdir}/libavahi-g*
+   rm ${D}${libdir}/pkgconfig/avahi-c*
+   rm ${D}${libdir}/pkgconfig/avahi-g*
+   rmdir ${D}${libdir}/avahi
+   rm ${D}${sbindir} -rf
+   rm ${D}${datadir}/avahi/a*
+   rm ${D}${datadir}/avahi/s*
+   rm ${D}${datadir}/dbus* -rf
+   rm ${D}${mandir}/man1/a*
+   rm ${D}${mandir}/man5 -rf
+   rm ${D}${mandir}/man8 -rf
+   rmdir ${D}${localstatedir}
+}
+



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

Re: [OE-core] [PATCH 2/4] gcc-package-target.inc: add the symbol link /lib/cpp

[Cui, Dexuan]

Richard Purdie wrote on 2011-11-24:
 On Thu, 2011-11-24 at 18:08 +0800, Dexuan Cui wrote:
 --- a/meta/recipes-devtools/gcc/gcc-package-target.inc
 +++ b/meta/recipes-devtools/gcc/gcc-package-target.inc
 @@ -122,6 +122,8 @@ do_install () {
  ln -sf ${TARGET_PREFIX}g++ g++
  ln -sf ${TARGET_PREFIX}gcc gcc
  ln -sf ${TARGET_PREFIX}cpp cpp
 +install -d ${D}${base_libdir}
 +ln -sf ${bindir}/${TARGET_PREFIX}cpp ${D}${base_libdir}/cpp
  ln -sf g++ c++
  ln -sf gcc cc
 
 Why do we need this change?
When I was trying self-hosted-image, eglibc's do_install failed in the target:
ERROR: cannot stat bootparam_prot.h: the cause is: rpcgen doesn't work 
properly: rpcgen can't exec /lib/cpp since it doesn't exist.

According to http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/lib.html,  if 
a C preprocessor is installed, /lib/cpp must be a reference to it, for 
historical reasons. The usual placement of this binary is /usr/bin/cpp.

Typical distros, like Ubuntu, openSuSE, Fedora, RHEL, all comply with the rule.

Actually in meta/recipes-devtools/gcc/gcc-package-target.inc, we do try to 
package ${base_libdir}/cpp:
 FILES_cpp = \
  ${bindir}/${TARGET_PREFIX}cpp \
  ${base_libdir}/cpp \
  ${libexecdir}/gcc/${TARGET_SYS}/${BINV}/cc1
But unluckily we didn't to create a symbol link in do_install. This patch adds 
the symbol link.

Thanks,
-- Dexuan



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

Re: [OE-core] [PATCH] base.bbclass: Use bb.plain to print the build header

[Darren Hart]

On 11/24/2011 06:57 AM, Richard Purdie wrote:
 If we just use print, the bitbake logging functions don't see the message
 and it can get lost if bitbake is for example logging messages to disk.
 
 Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org

Acked-by: Darren Hart dvh...@linux.intel.com

 ---
 diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
 index ba1f230..72196d6 100644
 --- a/meta/classes/base.bbclass
 +++ b/meta/classes/base.bbclass
 @@ -232,7 +232,7 @@ python base_eventhandler() {
  
   statuslines += layers_branch_rev
   statusmsg = \nOE Build Configuration:\n%s\n % 
 '\n'.join(statuslines)
 - print statusmsg
 + bb.plain(statusmsg)
  
   needed_vars = [ TARGET_ARCH, TARGET_OS ]
   pesteruser = []
 
 
 
 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

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

Re: [OE-core] [PATCH] bitbake.conf: Set BB_CONSOLELOG so we log console messages by default

[Darren Hart]

I believe this is the fix for Yocto Bug 1771? If so, awesome! A one
liner, something to be said for really knowing the codebase.

I would only suggest a commit log which includes the bug line,
motivation and the approach taken, per the contribution guidelines.
Maybe something like:


Fixes [YOCTO #1771]

The console log is often helpful for debugging issues. Difficult to
reproduce bugs would benefit from a log being generated by default as it
may be difficult to come by after the fact. Log to
tmp/cooker.log.${DATETIME} by default.


Thanks,

Darren


On 11/24/2011 06:58 AM, Richard Purdie wrote:
 Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
 ---
 diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
 index 01f064c..4589909 100644
 --- a/meta/conf/bitbake.conf
 +++ b/meta/conf/bitbake.conf
 @@ -732,6 +732,8 @@ DISTRO[unexport] = 1
  # Used by canadian-cross to handle string conversions on TARGET_ARCH where 
 needed
  TRANSLATED_TARGET_ARCH ??= ${@d.getVar('TARGET_ARCH', True).replace(_, 
 -)}
  
 +BB_CONSOLELOG = ${TMPDIR}/cooker.log.${DATETIME}
 +
  # Setup our default hash policy
  BB_SIGNATURE_HANDLER ?= basic
  BB_HASHTASK_WHITELIST ?= 
 (.*-cross$|.*-native$|.*-cross-initial$|.*-cross-intermediate$|^virtual:native:.*|^virtual:nativesdk:.*)
 
 
 
 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

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

Re: [OE-core] [RFC PATCH 1/5] grub-efi-native: New recipe to build GRUB EFI images

[Darren Hart]

On 11/24/2011 03:26 AM, Richard Purdie wrote:
 On Thu, 2011-11-24 at 09:59 +0100, Koen Kooi wrote:
 Op 24 nov. 2011, om 09:05 heeft Darren Hart het volgende geschreven:

 Add a recipe to build the GRUB efi images. This recipe is written as
 a native recipe as the resulting GRUB utils are required to assemble
 the final image. Rather than build a native and a target recipe (and
 increase build times), 

 That's a false dilemma. If you write it as a regular recipe with
 BBCLASSEXTEND=native your buildtime doesn't increase
 
 That isn't true, if you build a target and a native version your build
 time does increase. Using BBCLASSEXTEND does improve parsing time over
 having two separate recipes though.

Right, while it isn't a huge project to build, I didn't want to
contribute to the expanding build time unnecessarily.

 
  and you leave open the option of adding more BBCLASSEXTENDS if
 someone wants to ship it in an SDK.

I think the right thing to do here is to modify the origin grub recipe
to build with the efi platform enabled if we want to ship the binaries
on the TARGET. This recipe doesn't build the grub tools for deployment,
it builds the target bootloader binary image for the boot media. That's
the distinction I'm going with anyway.

 
 I did talk with Darren about why the recipe is the way it is and there
 are some pretty nasty issues with the way grub builds itself. I'm
 therefore ok with this as a version 1 and we can see whether there are
 any issues that result which need us to rethink the way the recipe is
 constructed. 
 
 Its currently behaving very like the way the binutils/gcc cross recipes
 will end up (see the separate thread with Matthew) Perhaps it should be
 called grub-efi-cross even if it uses native.bbclass.

If you prefer I can change it, I don't have a strong preference for the
name. That would end up as grub-efi-${TRANSLATED_TARGET_ARCH}-cross
after the PN adjustment then?


-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

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

Re: [OE-core] [PATCH] bitbake.conf: Set BB_CONSOLELOG so we log console messages by default

[Richard Purdie]

On Thu, 2011-11-24 at 08:13 -0800, Darren Hart wrote:
 I believe this is the fix for Yocto Bug 1771? If so, awesome! A one
 liner, something to be said for really knowing the codebase.

It has a dependent on a ~5 line change to bitbake over on bitbake-devel
but yes, it fixes 1771.

 I would only suggest a commit log which includes the bug line,
 motivation and the approach taken, per the contribution guidelines.
 Maybe something like:
 
 
 Fixes [YOCTO #1771]
 
 The console log is often helpful for debugging issues. Difficult to
 reproduce bugs would benefit from a log being generated by default as it
 may be difficult to come by after the fact. Log to
 tmp/cooker.log.${DATETIME} by default.
 

FWIW most of the commit message is over on bitbake-devel but I should
have referenced the bug number, yes.

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 2/4] gcc-package-target.inc: add the symbol link /lib/cpp

[Richard Purdie]

On Thu, 2011-11-24 at 23:37 +0800, Cui, Dexuan wrote:
 Richard Purdie wrote on 2011-11-24:
  On Thu, 2011-11-24 at 18:08 +0800, Dexuan Cui wrote:
  --- a/meta/recipes-devtools/gcc/gcc-package-target.inc
  +++ b/meta/recipes-devtools/gcc/gcc-package-target.inc
  @@ -122,6 +122,8 @@ do_install () {
 ln -sf ${TARGET_PREFIX}g++ g++
 ln -sf ${TARGET_PREFIX}gcc gcc
 ln -sf ${TARGET_PREFIX}cpp cpp
  +  install -d ${D}${base_libdir}
  +  ln -sf ${bindir}/${TARGET_PREFIX}cpp ${D}${base_libdir}/cpp
 ln -sf g++ c++
 ln -sf gcc cc
  
  Why do we need this change?
 When I was trying self-hosted-image, eglibc's do_install failed in the target:
 ERROR: cannot stat bootparam_prot.h: the cause is: rpcgen doesn't work 
 properly: rpcgen can't exec /lib/cpp since it doesn't exist.
 
 According to http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/lib.html,  
 if a C preprocessor is installed, /lib/cpp must be a reference to it, for 
 historical reasons. The usual placement of this binary is /usr/bin/cpp.
 
 Typical distros, like Ubuntu, openSuSE, Fedora, RHEL, all comply with the 
 rule.
 
 Actually in meta/recipes-devtools/gcc/gcc-package-target.inc, we do try to 
 package ${base_libdir}/cpp:
  FILES_cpp = \
   ${bindir}/${TARGET_PREFIX}cpp \
   ${base_libdir}/cpp \
   ${libexecdir}/gcc/${TARGET_SYS}/${BINV}/cc1
 But unluckily we didn't to create a symbol link in do_install. This patch 
 adds the symbol link.

Ok, this sounds great. Put this in the commit message though please!

Cheers,

Richard


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

Re: [OE-core] [RFC PATCH 1/5] grub-efi-native: New recipe to build GRUB EFI images

[Koen Kooi]

Op 24 nov. 2011, om 12:26 heeft Richard Purdie het volgende geschreven:

 On Thu, 2011-11-24 at 09:59 +0100, Koen Kooi wrote:
 Op 24 nov. 2011, om 09:05 heeft Darren Hart het volgende geschreven:
 
 Add a recipe to build the GRUB efi images. This recipe is written as
 a native recipe as the resulting GRUB utils are required to assemble
 the final image. Rather than build a native and a target recipe (and
 increase build times), 
 
 That's a false dilemma. If you write it as a regular recipe with
 BBCLASSEXTEND=native your buildtime doesn't increase
 
 That isn't true, if you build a target and a native version your build
 time does increase. Using BBCLASSEXTEND does improve parsing time over
 having two separate recipes though.

Are you really saying that 'bitbake grub-native' will build both versions if 
you use BBCLASSEXTEND!?!?! If not, it remains a false dilemma.




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] Getting started on creating a layer for OE-Core

[Philip Balister]

On 11/22/2011 12:59 PM, Ken Werner wrote:
 Hi,
 
 I'm currently reading the OpenEmbedded User Manual and wondering what's
 the best way to add a layer for the Linaro toolchain components (Linaro
 GCC, Linaro GDB). This is my first time with OE. I just setup the
 environment and started to build an image that targets qemuarm (bitbake
 is still building). Any suggestions or general help is much appreciated.

Can you comment on what you expect to get out of the Linaro toolchain layer?

As had been noted here, OE already has some of the Linaro work in the
toolchains. However, we have had issues with some patches so we can't
run a complete Linaro toolchain. (Toolchain guys, correct me if I am
wrong)

From my perspective, the Linaro work is great (I primarily use Cortex-A8
devices), but my understanding is that due to Linaro's focus on advanced
ARM processors, regressions for other architectures and older arms can
occur.

So I see the point of a dedicated Linaro tool layer being an excellent
vehicle for testing Linaro's work on a diverse set of machines to make
life easier for people using Linaro's work on other architectures.

Philip

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

Re: [OE-core] [RFC PATCH 1/5] grub-efi-native: New recipe to build GRUB EFI images

[Darren Hart]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 11/24/2011 08:51 AM, Koen Kooi wrote:
 
 Op 24 nov. 2011, om 12:26 heeft Richard Purdie het volgende 
 geschreven:
 
 On Thu, 2011-11-24 at 09:59 +0100, Koen Kooi wrote:
 Op 24 nov. 2011, om 09:05 heeft Darren Hart het volgende 
 geschreven:
 
 Add a recipe to build the GRUB efi images. This recipe is 
 written as a native recipe as the resulting GRUB utils are 
 required to assemble the final image. Rather than build a 
 native and a target recipe (and increase build times),
 
 That's a false dilemma. If you write it as a regular recipe
 with BBCLASSEXTEND=native your buildtime doesn't increase
 
 That isn't true, if you build a target and a native version your 
 build time does increase. Using BBCLASSEXTEND does improve
 parsing time over having two separate recipes though.
 
 Are you really saying that 'bitbake grub-native' will build both 
 versions if you use BBCLASSEXTEND!?!?! If not, it remains a false 
 dilemma.

No, that isn't it. Because of the way grub builds, you need the utils
in HOST_ARCH and the grub modules in TARGET_ARCH. Grub has a
monolithic build system, so in order to do this with BBCLASSEXTEND, we
would need to have grub-efi depend on grub-efi-native so that the
final do_mkimage task could use the -native version of grub-mkimage to
assemble the target-built modules into a final binary.

This approach builds grub natively and sets the --target to the
TARGET_ARCH so the modules are built for the target. This is why I'm
making the distinction between build the grub tools for deployment and
building the grub efi boot image. The approach to each is different,
and this recipe generates the boot image for the target.


- -- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOznttAAoJEKbMaAwKp364dG0H/0tScwNt0pc9gHDXDELdhCvp
JGJ8soO+yWgksG9o/p077oysd7HMm24Tq//m7FuRzgm0D2JymYwPwdLe06mA1ARs
BpwtvltUW5SLaWzJVeamxeNn5cDpdIcyaa904BdS2Ink/alZgTdoV60qh9LvElIh
P70Pb/GeV/Po5OLALmnYuEV39JPnRxz7RfaXr7qU/0e0JVGKxXa/hrBp8ZgzpYI4
WvGns2LrZRPi/Fp93Vc312NfZYa2y/s9H8ji+B2Nvdza99Zo9y4xtWSf9bDRn+4J
04Kw/CFUe4GqXrIoBATLvm8LmcS/fLaqtVY5Ewz5bSnPFRvXyYApmmNvWpy5hGs=
=LaXk
-END PGP SIGNATURE-

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

Re: [OE-core] Getting started on creating a layer for OE-Core

[Koen Kooi]

Op 24 nov. 2011, om 17:59 heeft Philip Balister het volgende geschreven:

 On 11/22/2011 12:59 PM, Ken Werner wrote:
 Hi,
 
 I'm currently reading the OpenEmbedded User Manual and wondering what's
 the best way to add a layer for the Linaro toolchain components (Linaro
 GCC, Linaro GDB). This is my first time with OE. I just setup the
 environment and started to build an image that targets qemuarm (bitbake
 is still building). Any suggestions or general help is much appreciated.
 
 Can you comment on what you expect to get out of the Linaro toolchain layer?
 
 As had been noted here, OE already has some of the Linaro work in the
 toolchains. However, we have had issues with some patches so we can't
 run a complete Linaro toolchain. (Toolchain guys, correct me if I am
 wrong)

There are 2 sets of problems:

1) OE-core needs to support more than just ARMv7 and up
2) Not every patch is an improvement

For 1) we need to add patches and sometimes take out patches. For 2) we usually 
remove the patch that breaks things, but sometimes we add a backport.

[..]

 So I see the point of a dedicated Linaro tool layer being an excellent
 vehicle for testing Linaro's work on a diverse set of machines to make
 life easier for people using Linaro's work on other architectures.

The exact same can be said by including most if not all linaro patches into the 
default toolchain. Having said that, a layer with 'pure' versions of the 
toolchain, uboot, kernel, etc as reference is a nice thing to have. But since 
we only have a finite amount of effort to spread around I'd advice working on 
OE-core instead of a seperate sandbox.

regards,

Koen

signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] Introduce multiarch DISTRO_FEATURE

[Khem Raj]

On (24/11/11 12:44), Julian Pidancet wrote:
  +def get_gcc_multiarch_setting(bb, d):
  +    if 'multiarch' in bb.data.getVar('DISTRO_FEATURES',d,1).split() :
  +        if bb.data.getVar('TARGET_ARCH', d, 1) in [ 'i586', 'i686' ] :
  +            return --enable-targets=all
  +        if bb.data.getVar('TARGET_ARCH', d, 1) in [ 'powerpc' ] :
  +            return --enable-targets=powerpc64
  +        if bb.data.getVar('TARGET_ARCH', d, 1) in [ 'sparc' ] :
  +            return --enable-targets=all
  +    return 

looking at above function can this be made into a single if statement
instead of 3

and we also need multiarch support in gdb recipes as well.

 
 
  you forgot mips here
 
 
 mips and s390 are not yet supported in the gcc version that OE is using.

yes right forgot about that it will be in 4.7
 
 -- 
 Julian

-- 
-Khem

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

Re: [OE-core] [PATCH v2] Introduce multiarch DISTRO_FEATURE

[Richard Purdie]

On Thu, 2011-11-24 at 09:36 -0800, Khem Raj wrote:
 On (24/11/11 12:44), Julian Pidancet wrote:
   +def get_gcc_multiarch_setting(bb, d):
   +if 'multiarch' in bb.data.getVar('DISTRO_FEATURES',d,1).split() :
   +if bb.data.getVar('TARGET_ARCH', d, 1) in [ 'i586', 'i686' ] :
   +return --enable-targets=all
   +if bb.data.getVar('TARGET_ARCH', d, 1) in [ 'powerpc' ] :
   +return --enable-targets=powerpc64
   +if bb.data.getVar('TARGET_ARCH', d, 1) in [ 'sparc' ] :
   +return --enable-targets=all
   +return 
 
 looking at above function can this be made into a single if statement
 instead of 3

Julian: Could you update this to use the syntax d.getVar instead of
bb.data.getVar(..., d) please? We recently did a fairly big cleanup of
these and I'd rather not see it creep back in! We also prefer True
instead of 1 although we've not done a big cleanup on that yet (its
planned).

As Khem mentioned, we can probably get this down to a couple of getVar
calls instead of the above too!

Cheers,

Richard




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

Re: [OE-core] Getting started on creating a layer for OE-Core

[Khem Raj]

On (24/11/11 11:59), Philip Balister wrote:
 On 11/22/2011 12:59 PM, Ken Werner wrote:
  Hi,
  
  I'm currently reading the OpenEmbedded User Manual and wondering what's
  the best way to add a layer for the Linaro toolchain components (Linaro
  GCC, Linaro GDB). This is my first time with OE. I just setup the
  environment and started to build an image that targets qemuarm (bitbake
  is still building). Any suggestions or general help is much appreciated.
 
 Can you comment on what you expect to get out of the Linaro toolchain layer?
 
 As had been noted here, OE already has some of the Linaro work in the
 toolchains. However, we have had issues with some patches so we can't
 run a complete Linaro toolchain. (Toolchain guys, correct me if I am
 wrong)


thats correct more often some patches whcih work on arm dont work on
other architectures so the patcheses we cherry pick usually exclude such
regressing patches and its a bit of work to identify them
but on positive side the patches we take get tested on wider
architectures. Also we only take gcc patches no other components

 
 From my perspective, the Linaro work is great (I primarily use Cortex-A8
 devices), but my understanding is that due to Linaro's focus on advanced
 ARM processors, regressions for other architectures and older arms can
 occur.
 
 So I see the point of a dedicated Linaro tool layer being an excellent
 vehicle for testing Linaro's work on a diverse set of machines to make
 life easier for people using Linaro's work on other architectures.

linaro layer would be a good idea although I think from distro point of
view they would want a single toolchain doing all architectures and
still would want advantages of linaro work so if this layer takes care
of fixing toolchain for non arm architectures it will be a lot of value
to distros using OE

but as such having layer would be a good thing as well.

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

-- 
-Khem

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

[OE-core] [PATCH] bitbake.conf: We only care about the absolute value of baselib

[Richard Purdie]

The value of baselib can be constructed in several different ways
and from a sstate perspective we don't care how it was made up,
we only care what the final value is. This uses the new functionality
in bitbake to ensure we only include the value of baselib and not
any intermediate dependencies.

[YOCTO #1583]

Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 01f064c..43d973d 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -8,6 +8,7 @@
 
 # Used by multilib code to change the library paths
 baselib = ${BASELIB}
+baselib[vardepvalue] = ${baselib}
 BASELIB = lib
 BASELIB_powerpc64 = lib64
 




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

Re: [OE-core] [RFC] gcc-cross.inc: Add depedency on BUILD_ARCH

[Phil Blundell]

On Thu, 2011-11-24 at 10:03 -0800, Khem Raj wrote:
 On (24/11/11 10:54), Phil Blundell wrote:
  On Thu, 2011-11-24 at 07:29 +, McClintock Matthew-B29882 wrote:
   On Thu, Nov 24, 2011 at 1:21 AM, Khem Raj raj.k...@gmail.com wrote:
hmmm I guess cross recipes are special they should not have been built
under target recipes. Adding build arch to package name would be ok
too but may be if they were built under directory of their own which
was something like build-host-target then it would also solve
the problem i think
   
   I agree - this is the discussion I'm trying to start. ;)
  
  It's certainly true that the way the cross recipes are done at the
  moment does suck.  Really, they should be built as primarily native and
  the target arch ought to just be encoded into ${PN} somehow, rather than
  the current arrangement of pretending that they are target recipes.
  (All the runtime bits are, or should be, packaged separately by either
  libgcc or gcc-runtime so they will already get the right PACKAGE_ARCH.)
 
 yes building them under native build dir and suffixing with
 build.host.arch would be way to go

I don't think it's necessary to put all three components in the name,
and doing so would make it harder to construct the right string to go in
DEPENDS later.

PACKAGE_ARCH for native is already the host system, so you get that one
for free, and the build arch is (or ought to be) irrelevant as far as
the artifacts are concerned.  So I think it's just the target system
name that needs to be encoded into PN for gcc-cross and binutils-cross.

p.



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

Re: [OE-core] [RFC] gcc-cross.inc: Add depedency on BUILD_ARCH

[Khem Raj]

On (24/11/11 18:08), Phil Blundell wrote:
 On Thu, 2011-11-24 at 10:03 -0800, Khem Raj wrote:
  On (24/11/11 10:54), Phil Blundell wrote:
   On Thu, 2011-11-24 at 07:29 +, McClintock Matthew-B29882 wrote:
On Thu, Nov 24, 2011 at 1:21 AM, Khem Raj raj.k...@gmail.com wrote:
 hmmm I guess cross recipes are special they should not have been built
 under target recipes. Adding build arch to package name would be ok
 too but may be if they were built under directory of their own which
 was something like build-host-target then it would also solve
 the problem i think

I agree - this is the discussion I'm trying to start. ;)
   
   It's certainly true that the way the cross recipes are done at the
   moment does suck.  Really, they should be built as primarily native and
   the target arch ought to just be encoded into ${PN} somehow, rather than
   the current arrangement of pretending that they are target recipes.
   (All the runtime bits are, or should be, packaged separately by either
   libgcc or gcc-runtime so they will already get the right PACKAGE_ARCH.)
  
  yes building them under native build dir and suffixing with
  build.host.arch would be way to go
 
 I don't think it's necessary to put all three components in the name,
 and doing so would make it harder to construct the right string to go in
 DEPENDS later.

yeah host in cross case would be useless since host = build we only need build 
and target
I thought of canadian builds

 
 PACKAGE_ARCH for native is already the host system, so you get that one
 for free, and the build arch is (or ought to be) irrelevant as far as
 the artifacts are concerned.  So I think it's just the target system
 name that needs to be encoded into PN for gcc-cross and binutils-cross.
 
 p.
 
 
 
 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

-- 
-Khem

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

[OE-core] [PATCH 1/1] intltool: remove XML::Parser check

[Saul Wold]

Add Patch to disable the XML::Parser check in the target
intltool.m4, this check will find the host (not native)
XML::Parser if it's installed possibly causing Host
contamination, but will also fail configuration if XML::Parser
is not installed on the host.

Since we know that XML::Parser is installed on the image, we don't
really need this check, so comment it out.

Signed-off-by: Saul Wold s...@linux.intel.com
---
 .../intltool-0.40.6/remove-xml-check.patch |   29 
 meta/recipes-devtools/intltool/intltool_0.40.6.bb  |7 +++--
 2 files changed, 33 insertions(+), 3 deletions(-)
 create mode 100644 
meta/recipes-devtools/intltool/intltool-0.40.6/remove-xml-check.patch

diff --git 
a/meta/recipes-devtools/intltool/intltool-0.40.6/remove-xml-check.patch 
b/meta/recipes-devtools/intltool/intltool-0.40.6/remove-xml-check.patch
new file mode 100644
index 000..476d091
--- /dev/null
+++ b/meta/recipes-devtools/intltool/intltool-0.40.6/remove-xml-check.patch
@@ -0,0 +1,29 @@
+Index: intltool-0.40.6/intltool.m4
+===
+--- intltool-0.40.6.orig/intltool.m4   2009-02-14 14:12:28.0 -0800
 intltool-0.40.6/intltool.m42011-11-23 15:39:34.689561872 -0800
+@@ -122,14 +122,16 @@
+IT_PERL_VERSION=`$INTLTOOL_PERL -e \printf '%vd', $^V\`
+AC_MSG_RESULT([$IT_PERL_VERSION])
+ fi
+-if test x$2 != xno-xml; then
+-   AC_MSG_CHECKING([for XML::Parser])
+-   if `$INTLTOOL_PERL -e require XML::Parser 2/dev/null`; then
+-   AC_MSG_RESULT([ok])
+-   else
+-   AC_MSG_ERROR([XML::Parser perl module is required for intltool])
+-   fi
+-fi
++
++# Disable this check since we know XML::Parser is installed
++#if test x$2 != xno-xml; then
++#   AC_MSG_CHECKING([for XML::Parser])
++#   if `$INTLTOOL_PERL -e require XML::Parser 2/dev/null`; then
++#   AC_MSG_RESULT([ok])
++#   else
++#   AC_MSG_ERROR([XML::Parser perl module is required for intltool])
++#   fi
++#fi
+ 
+ # Substitute ALL_LINGUAS so we can use it in po/Makefile
+ AC_SUBST(ALL_LINGUAS)
diff --git a/meta/recipes-devtools/intltool/intltool_0.40.6.bb 
b/meta/recipes-devtools/intltool/intltool_0.40.6.bb
index e9871fc..8180fd8 100644
--- a/meta/recipes-devtools/intltool/intltool_0.40.6.bb
+++ b/meta/recipes-devtools/intltool/intltool_0.40.6.bb
@@ -1,14 +1,15 @@
 require intltool.inc
 LICENSE=GPLv2
 LIC_FILES_CHKSUM = file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f
-PR = r5
+PR = r6
 
 SRC_URI_append =  file://intltool-nowarn-0.40.0.patch \
${NATIVEPATCHES} \
  
 
-NATIVEPATCHES = file://noperlcheck.patch
-NATIVEPATCHES_virtclass-native = file://use-nativeperl.patch
+NATIVEPATCHES = file://noperlcheck.patch \
+ file://remove-xml-check.patch
+NATIVEPATCHES_virtclass-native = file://use-nativeperl.patch 
 
 SRC_URI[md5sum] = 69bc0353323112f42ad4f9cf351bc3e5
 SRC_URI[sha256sum] = 
4d1e5f8561f09c958e303d4faa885079a5e173a61d28437d0013ff5efc9e3b64
-- 
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 0/1] Fix for host conamination

[Saul Wold]

This address a problem where a intltool.m4 check will fail if 
the host system does not have XML::Parser installed.


The following changes since commit 0a1dedeb8eea4e230b47d1516b3e6e90495fe49d:

  libtool: Avoid relinking when cross compiling, its pointless (2011-11-24 
00:02:27 +)

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

Saul Wold (1):
  intltool: remove XML::Parser check

 .../intltool-0.40.6/remove-xml-check.patch |   29 
 meta/recipes-devtools/intltool/intltool_0.40.6.bb  |7 +++--
 2 files changed, 33 insertions(+), 3 deletions(-)
 create mode 100644 
meta/recipes-devtools/intltool/intltool-0.40.6/remove-xml-check.patch

-- 
1.7.5.4


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

Re: [OE-core] [PATCH 1/1] intltool: remove XML::Parser check

[Khem Raj]

On Thu, Nov 24, 2011 at 10:29 AM, Saul Wold s...@linux.intel.com wrote:
 Add Patch to disable the XML::Parser check in the target
 intltool.m4, this check will find the host (not native)
 XML::Parser if it's installed possibly causing Host
 contamination, but will also fail configuration if XML::Parser
 is not installed on the host.

 Since we know that XML::Parser is installed on the image, we don't
 really need this check, so comment it out.

if it is installed then why does it fail to detect it ?


 Signed-off-by: Saul Wold s...@linux.intel.com
 ---
  .../intltool-0.40.6/remove-xml-check.patch         |   29 
 
  meta/recipes-devtools/intltool/intltool_0.40.6.bb  |    7 +++--
  2 files changed, 33 insertions(+), 3 deletions(-)
  create mode 100644 
 meta/recipes-devtools/intltool/intltool-0.40.6/remove-xml-check.patch

 diff --git 
 a/meta/recipes-devtools/intltool/intltool-0.40.6/remove-xml-check.patch 
 b/meta/recipes-devtools/intltool/intltool-0.40.6/remove-xml-check.patch
 new file mode 100644
 index 000..476d091
 --- /dev/null
 +++ b/meta/recipes-devtools/intltool/intltool-0.40.6/remove-xml-check.patch
 @@ -0,0 +1,29 @@
 +Index: intltool-0.40.6/intltool.m4
 +===
 +--- intltool-0.40.6.orig/intltool.m4   2009-02-14 14:12:28.0 -0800
  intltool-0.40.6/intltool.m4        2011-11-23 15:39:34.689561872 -0800
 +@@ -122,14 +122,16 @@
 +    IT_PERL_VERSION=`$INTLTOOL_PERL -e \printf '%vd', $^V\`
 +    AC_MSG_RESULT([$IT_PERL_VERSION])
 + fi
 +-if test x$2 != xno-xml; then
 +-   AC_MSG_CHECKING([for XML::Parser])
 +-   if `$INTLTOOL_PERL -e require XML::Parser 2/dev/null`; then
 +-       AC_MSG_RESULT([ok])
 +-   else
 +-       AC_MSG_ERROR([XML::Parser perl module is required for intltool])
 +-   fi
 +-fi
 ++
 ++# Disable this check since we know XML::Parser is installed
 ++#if test x$2 != xno-xml; then
 ++#   AC_MSG_CHECKING([for XML::Parser])
 ++#   if `$INTLTOOL_PERL -e require XML::Parser 2/dev/null`; then
 ++#       AC_MSG_RESULT([ok])
 ++#   else
 ++#       AC_MSG_ERROR([XML::Parser perl module is required for intltool])
 ++#   fi
 ++#fi
 +
 + # Substitute ALL_LINGUAS so we can use it in po/Makefile
 + AC_SUBST(ALL_LINGUAS)
 diff --git a/meta/recipes-devtools/intltool/intltool_0.40.6.bb 
 b/meta/recipes-devtools/intltool/intltool_0.40.6.bb
 index e9871fc..8180fd8 100644
 --- a/meta/recipes-devtools/intltool/intltool_0.40.6.bb
 +++ b/meta/recipes-devtools/intltool/intltool_0.40.6.bb
 @@ -1,14 +1,15 @@
  require intltool.inc
  LICENSE=GPLv2
  LIC_FILES_CHKSUM = file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f
 -PR = r5
 +PR = r6

  SRC_URI_append =  file://intltool-nowarn-0.40.0.patch \
                    ${NATIVEPATCHES} \
                  

 -NATIVEPATCHES = file://noperlcheck.patch
 -NATIVEPATCHES_virtclass-native = file://use-nativeperl.patch
 +NATIVEPATCHES = file://noperlcheck.patch \
 +                 file://remove-xml-check.patch
 +NATIVEPATCHES_virtclass-native = file://use-nativeperl.patch

  SRC_URI[md5sum] = 69bc0353323112f42ad4f9cf351bc3e5
  SRC_URI[sha256sum] = 
 4d1e5f8561f09c958e303d4faa885079a5e173a61d28437d0013ff5efc9e3b64
 --
 1.7.5.4


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


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

Re: [OE-core] [PATCH 1/4] runqemu: look for *image* to be more flexible for image names

[Richard Purdie]

On Thu, 2011-11-24 at 18:08 +0800, Dexuan Cui wrote:
 From: Saul Wold s...@linux.intel.com
 
 Signed-off-by: Saul Wold s...@linux.intel.com
 ---
  scripts/runqemu |4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/scripts/runqemu b/scripts/runqemu
 index 31e9822..a9a362f 100755
 --- a/scripts/runqemu
 +++ b/scripts/runqemu
 @@ -114,7 +114,7 @@ while [ $i -le $# ]; do
  usage
  fi
  ;;
 -*-image-*)
 +*image*)
  if [ -z $ROOTFS ]; then
  if [ -f $arg ]; then
  process_filename $arg
As I mentioned to Saul, this is a bad idea since its very close to
matching things like bzImage. I seem to remember something with a
*image* name being in deploy before and having problems 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 v2] Introduce multiarch DISTRO_FEATURE

[Julian Pidancet]

On Thu, Nov 24, 2011 at 5:36 PM, Khem Raj raj.k...@gmail.com wrote:

 and we also need multiarch support in gdb recipes as well.


Support for Biarch exists in gdb for x86 since May 2009, and it is
enabled by default as far as I can tell.
I managed to dig up the exact commit in the gdb sources:
http://sourceware.org/git/?p=gdb.git;a=commit;h=5d008094095c4a6f5ccc522abac263d6bc52738b

Regarding powerpc, it seems that gdb can only be made biarch when
configured for a powerpc64 machine.

-- 
Julian

___
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] Various Fixes

[Richard Purdie]

On Tue, 2011-11-22 at 21:55 -0800, nitin.a.kam...@intel.com wrote:
 From: Nitin A Kamble nitin.a.kam...@intel.com
 
 This set has fixes for gmp, at  site/x86-64-linux
 
 - Nitin
 
 The following changes since commit 40fe6457d5ca49fe113bc26c60d5add59d85b34f:
 
   matchbox-wm: Fix variable type in _NET_WORKAREA setting (2011-11-22 
 15:13:26 +)
 
 are available in the git repository at:
   git://git.pokylinux.org/poky-contrib nitin/misc
   http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=nitin/misc
 
 Nitin A Kamble (3):
   gmp: also generate the libgmpcxx library

This one needs the C++ piece split into a separate package please.

   at: update the upstream-status of patches
   site/x86_64-linux: add cvs config variables

These two have merged, thanks!

Richard


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

Re: [OE-core] [PATCH] Remove EGLIBPARALLELISM from deps for EXTRA_OEMAKE

[Richard Purdie]

On Tue, 2011-11-22 at 14:49 -0800, Saul Wold wrote:
 On 11/22/2011 02:40 PM, McClintock Matthew-B29882 wrote:
  On Tue, Nov 22, 2011 at 1:50 PM, Saul Wolds...@linux.intel.com  wrote:
  When possible, please include the recipe or file you are changing as part 
  of
  the patch subject.
 
  For example this would be:
 
  eglibc.inc: Remove EGLIBPARALLELISM from deps for EXTRA_OEMAKE
 
  Sorry. Shall I resubmit or will you handle this?
 
 I will handle this time, should have added that in my email.

Merged to master with the tweaked subject from Saul.

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] Some Upstream-Status patch updates

[Richard Purdie]

On Mon, 2011-11-14 at 17:14 -0800, Scott Garman wrote:
 Taking care of a few patch straglers that were missing Upstream-Status.
 
 The following changes since commit f2316ff39670ed99382411e15ac035550360fbdd:
 
   opkg: Ensure we use the uname/gname fields when extracting tarballs 
 (2011-11-14 11:15:36 +)
 
 are available in the git repository at:
   git://git.yoctoproject.org/poky-contrib sgarman/upstream-status-updates
   
 http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=sgarman/upstream-status-updates
 
 Scott Garman (2):
   dosfstools: add Upstream-Status to patches
   base-passwd: add Upstream-Status to patches, remove unused patch

Merged to master, thanks.

Richard


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

[OE-core] [PATCH] ofono: Fix missing python dependency and package tests separately

[Richard Purdie]

We need to ensure there is a python dependency for the ofono python
test scripts. To do this without introducing the dependency
unnecessarily for the core ofono functionality, this patch splits
the tests into a separate package too.

[YOCTO #1705]

Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/recipes-connectivity/ofono/ofono.inc 
b/meta/recipes-connectivity/ofono/ofono.inc
index 0b1a6e1..0cc58ae 100644
--- a/meta/recipes-connectivity/ofono/ofono.inc
+++ b/meta/recipes-connectivity/ofono/ofono.inc
@@ -17,4 +17,8 @@ do_install_append() {
   install -m 0755 ${WORKDIR}/ofono ${D}${sysconfdir}/init.d/ofono
 }
 
+PACKAGES =+ ${PN}-tests
+
 FILES_${PN} += ${base_libdir}/udev ${base_libdir}/systemd
+FILES_${PN}-tests = ${libdir}/ofono
+RDEPENDS_${PN}-tests = python
diff --git a/meta/recipes-connectivity/ofono/ofono_0.50.bb 
b/meta/recipes-connectivity/ofono/ofono_0.50.bb
index b679200..b4ef413 100644
--- a/meta/recipes-connectivity/ofono/ofono_0.50.bb
+++ b/meta/recipes-connectivity/ofono/ofono_0.50.bb
@@ -1,6 +1,6 @@
 require ofono.inc
 
-PR = r1
+PR = r2
 
 SRC_URI  = ${KERNELORG_MIRROR}/linux/network/ofono/${BPN}-${PV}.tar.bz2 \
  file://ofono
diff --git a/meta/recipes-connectivity/ofono/ofono_git.bb 
b/meta/recipes-connectivity/ofono/ofono_git.bb
index f1770c2..966d315 100644
--- a/meta/recipes-connectivity/ofono/ofono_git.bb
+++ b/meta/recipes-connectivity/ofono/ofono_git.bb
@@ -1,6 +1,6 @@
 require ofono.inc
 
-PR = r1
+PR = r2
 
 S   = ${WORKDIR}/git
 SRCREV = 14544d5996836f628613c2ce544380ee6fc8f514



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

Re: [OE-core] [PATCH 2/4] gcc-package-target.inc: add the symbol link /lib/cpp

[Cui, Dexuan]

Richard Purdie wrote on 2011-11-25:
 On Thu, 2011-11-24 at 23:37 +0800, Cui, Dexuan wrote:
 Richard Purdie wrote on 2011-11-24:
 On Thu, 2011-11-24 at 18:08 +0800, Dexuan Cui wrote:
 --- a/meta/recipes-devtools/gcc/gcc-package-target.inc
 +++ b/meta/recipes-devtools/gcc/gcc-package-target.inc
 @@ -122,6 +122,8 @@ do_install () {
ln -sf ${TARGET_PREFIX}g++ g++
ln -sf ${TARGET_PREFIX}gcc gcc
ln -sf ${TARGET_PREFIX}cpp cpp
 +  install -d ${D}${base_libdir}
 +  ln -sf ${bindir}/${TARGET_PREFIX}cpp ${D}${base_libdir}/cpp
ln -sf g++ c++
ln -sf gcc cc
 
 Why do we need this change?
 When I was trying self-hosted-image, eglibc's do_install failed in the
 target: ERROR: cannot stat bootparam_prot.h: the cause is: rpcgen
 doesn't work properly: rpcgen can't exec /lib/cpp since it doesn't
 exist.
 
 According to
 http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/lib.html,
 if a C preprocessor is installed, /lib/cpp must be a reference to it,
 for historical reasons. The usual placement of this binary is /usr/bin/cpp.
 
 Typical distros, like Ubuntu, openSuSE, Fedora, RHEL, all comply with
 the rule.
 
 Actually in meta/recipes-devtools/gcc/gcc-package-target.inc, we do
 try to
 package ${base_libdir}/cpp:
  FILES_cpp = \
   ${bindir}/${TARGET_PREFIX}cpp \
   ${base_libdir}/cpp \
   ${libexecdir}/gcc/${TARGET_SYS}/${BINV}/cc1
 But unluckily we didn't to create a symbol link in do_install. This
 patch
 adds the symbol link.
 
 Ok, this sounds great. Put this in the commit message though please!
Hi RP,
Please use the new commit(the only change is the updated commit message):
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/self-hosted-v2id=f6001f0b12cb561f5e08d3a5b0d61ab5fa924f40

Thanks,
-- Dexuan

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

Re: [OE-core] [PATCH 2/4] gcc-package-target.inc: add the symbol link /lib/cpp

[Richard Purdie]

On Fri, 2011-11-25 at 07:09 +0800, Cui, Dexuan wrote:
 Richard Purdie wrote on 2011-11-25:
  On Thu, 2011-11-24 at 23:37 +0800, Cui, Dexuan wrote:
  Richard Purdie wrote on 2011-11-24:
  On Thu, 2011-11-24 at 18:08 +0800, Dexuan Cui wrote:
  --- a/meta/recipes-devtools/gcc/gcc-package-target.inc
  +++ b/meta/recipes-devtools/gcc/gcc-package-target.inc
  @@ -122,6 +122,8 @@ do_install () {
   ln -sf ${TARGET_PREFIX}g++ g++
   ln -sf ${TARGET_PREFIX}gcc gcc
   ln -sf ${TARGET_PREFIX}cpp cpp
  +install -d ${D}${base_libdir}
  +ln -sf ${bindir}/${TARGET_PREFIX}cpp ${D}${base_libdir}/cpp
   ln -sf g++ c++
   ln -sf gcc cc
  
  Why do we need this change?
  When I was trying self-hosted-image, eglibc's do_install failed in the
  target: ERROR: cannot stat bootparam_prot.h: the cause is: rpcgen
  doesn't work properly: rpcgen can't exec /lib/cpp since it doesn't
  exist.
  
  According to
  http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/lib.html,
  if a C preprocessor is installed, /lib/cpp must be a reference to it,
  for historical reasons. The usual placement of this binary is /usr/bin/cpp.
  
  Typical distros, like Ubuntu, openSuSE, Fedora, RHEL, all comply with
  the rule.
  
  Actually in meta/recipes-devtools/gcc/gcc-package-target.inc, we do
  try to
  package ${base_libdir}/cpp:
   FILES_cpp = \
${bindir}/${TARGET_PREFIX}cpp \
${base_libdir}/cpp \
${libexecdir}/gcc/${TARGET_SYS}/${BINV}/cc1
  But unluckily we didn't to create a symbol link in do_install. This
  patch
  adds the symbol link.
  
  Ok, this sounds great. Put this in the commit message though please!
 Hi RP,
 Please use the new commit(the only change is the updated commit message):
 http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/self-hosted-v2id=f6001f0b12cb561f5e08d3a5b0d61ab5fa924f40

Thanks, I've merged this patch to master.

Cheers,

Richard


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

Re: [OE-core] [RFC] gcc-cross.inc: Add depedency on BUILD_ARCH

[McClintock Matthew-B29882]

On Wed, Nov 23, 2011 at 3:40 AM, Matthew McClintock m...@freescale.com wrote:
 +# we also add this to the PV so its clear in filenames
 +# that this is arch specific even though it's labeled as
 +# a target package
 +PV .= +${BUILD_ARCH_EXPANDED}

Seems like based on discussion this should be the following instead:

PN .= -{BUILD_ARCH}-${TARGET_ARCH}

-M

___
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] rpm: Flush old logs by change the DB_CONFIG

[Richard Purdie]

On Thu, 2011-11-17 at 16:32 +0800, Mei Lei wrote:
 Fixes [YOCTO #1174]
 
 Rpm logs will grow indefinitely, so change the config to flush those old logs.
 
 Signed-off-by: Mei Lei lei@intel.com
 ---
  .../recipes-devtools/rpm/rpm/rpm-log-auto-rm.patch |   12 
  meta/recipes-devtools/rpm/rpm_5.4.0.bb |5 +++--
  2 files changed, 15 insertions(+), 2 deletions(-)
  create mode 100644 meta/recipes-devtools/rpm/rpm/rpm-log-auto-rm.patch

Merged to master, thanks.

Richard


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

Re: [OE-core] [PATCH] Add PATCHRESOLVE to excluded vars for generating sstate-cache

[Richard Purdie]

On Thu, 2011-11-17 at 16:42 -0600, Matthew McClintock wrote:
 The method of resolving the patch should not effect the sstate-cache
 signature.
 
 Signed-off-by: Matthew McClintock m...@freescale.com
 ---
 I'm not 100% sure about this one either - should we even generate
 sstate-cache at all if we have a scenario where we try to resolve
 a patch?
 
  meta/classes/patch.bbclass |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

Merged to master, thanks.

In answer to the question, there clearly shouldn't be a dependency on
this variable. We can depend on the variable even if the conditional
code using it doesn't actually use the code as the dependency analysis
doesn't account for conditional code paths.

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 1/1] gtk+: Have gtk+ pick up ${NM} from the environment

[Richard Purdie]

On Thu, 2011-11-17 at 19:16 +0800, Xiaofeng Yan wrote:
 From: Xiaofeng Yan xiaofeng@windriver.com
 
 hen gtk+ configures, it should pick up ${NM} from the environment \
 if it is defined, instead of just looking for nm.
 
 Signed-off-by: Xiaofeng Yan xiaofeng@windriver.com
 ---
  .../gtk+/gtk+-2.24.6/configure-nm.patch|   14 ++
  meta/recipes-gnome/gtk+/gtk+_2.24.6.bb |3 ++-
  2 files changed, 16 insertions(+), 1 deletions(-)
  create mode 100644 meta/recipes-gnome/gtk+/gtk+-2.24.6/configure-nm.patch

Merged to master, thanks.

Richard


___
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] tslib: Set open mode for ts_calibate.c

[Richard Purdie]

On Thu, 2011-11-17 at 19:10 +0800, Xiaofeng Yan wrote:
 From: Xiaofeng Yan xiaofeng@windriver.com
 
 Get patch from: 
 http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/27614
 
 There is a potentially unsafe use of open(). Ubuntu 8.10+, for instance,
 by default enables the compiler flag -D_FORTIFY_SOURCE=2 \
 which throws an error of ts_calibrate.c. To fix this, \
 set a mode in the open() call, patch patched ts_calibrate.c \
 to set 0644 (S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH) and it compiles fine
 
 Signed-off-by: Xiaofeng Yan xiaofeng@windriver.com
 ---
  .../tslib/set-open-mode-for-ts_calibrate_c.patch   |   30 
 
  meta/recipes-graphics/tslib/tslib_1.0.bb   |5 ++-
  2 files changed, 33 insertions(+), 2 deletions(-)
  create mode 100644 
 meta/recipes-graphics/tslib/tslib/set-open-mode-for-ts_calibrate_c.patch

Merged to master, thanks.

Richard


___
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] eglibc_2.13: update SRCREV

[Richard Purdie]

On Wed, 2011-11-16 at 18:36 +0800, Kang Kai wrote:
 Update eglibc 2.13 SRCREV to 15508, just to sync with upstream
 Remove glibc_bug_fix_12454.patch, because it is already merged.
 
 Signed-off-by: Kang Kai kai.k...@windriver.com
 ---
  .../conf/distro/include/distro_tracking_fields.inc |3 +
  .../eglibc/eglibc-2.13/glibc_bug_fix_12454.patch   |  179 
 
  meta/recipes-core/eglibc/eglibc_2.13.bb|5 +-
  3 files changed, 5 insertions(+), 182 deletions(-)
  delete mode 100644 
 meta/recipes-core/eglibc/eglibc-2.13/glibc_bug_fix_12454.patch

Merged to master, thanks.

Richard


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

Re: [OE-core] [RFC] gcc-cross.inc: Add depedency on BUILD_ARCH

[Richard Purdie]

On Thu, 2011-11-24 at 23:56 +, McClintock Matthew-B29882 wrote:
 On Wed, Nov 23, 2011 at 3:40 AM, Matthew McClintock m...@freescale.com 
 wrote:
  +# we also add this to the PV so its clear in filenames
  +# that this is arch specific even though it's labeled as
  +# a target package
  +PV .= +${BUILD_ARCH_EXPANDED}
 
 Seems like based on discussion this should be the following instead:
 
 PN .= -{BUILD_ARCH}-${TARGET_ARCH}

What we really want is something like this in cross.bbclass:

MULTIMACH_TARGET_SYS = ${BUILD_ARCH}${BUILD_VENDOR}-${BUILD_OS}
PN .= -${TRANSLATED_TARGET_ARCH}

so that WORKDIR gets changed. I've not tested what this does to the
build though.

Also, looking at sstate.bbclass it does:

elif bb.data.inherits_class('cross', d):
bb.data.setVar('SSTATE_PKGARCH', 
bb.data.expand(${BUILD_ARCH}_${TUNE_PKGARCH}, d), d)
bb.data.setVar('SSTATE_MANMACH', 
bb.data.expand(${BUILD_ARCH}_${MACHINE}, d), d)

so it should be sticking BUILD_ARCH into the sstate file name directly.
This should mean you can't use 32 bit sstate files on a 64 bit system
and vice versa already?

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] Nothing uses USERNAME, remove it - can cause sstate-cache conflicts

[Richard Purdie]

On Wed, 2011-11-23 at 19:12 -0600, Matthew McClintock wrote:
 USER is the correct variable to use, also this can affect sstate
 cache as well.
 
 Signed-off-by: Matthew McClintock m...@freescale.com

Merged to master, thanks.

Richard


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

Re: [OE-core] [RFC] gcc-cross.inc: Add depedency on BUILD_ARCH

[McClintock Matthew-B29882]

On Thu, Nov 24, 2011 at 6:17 PM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
 This should mean you can't use 32 bit sstate files on a 64 bit system
 and vice versa already?

That would seem to be the case already:

SSTATE_PKG=/home/mattsm/git/poky/sstate-cache/sstate-gcc-cross-ppce5500-fsl-linux-4.6.1+svnr175454-r10-x86_64_ppce5500-2-${BB_TASKHASH}

SSTATE_PKG=/home/mattsm/git/poky/sstate-cache/sstate-gcc-cross-ppce500mc-fsl-linux-4.6.1+svnr175454-r10-i686_ppce500mc-2-${BB_TASKHASH}

So, I'm not 100% sure what is going on anymore...

-M

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

Re: [OE-core] [PATCH][oe-core 14/22] libsdl: enable alsa/opengl based on PACKAGECONFIG and respect DISTRO_FEATURES

[Martin Jansa]

On Wed, Nov 16, 2011 at 10:12:15AM +, Richard Purdie wrote:
 On Wed, 2011-11-16 at 00:45 +0100, Martin Jansa wrote:
  On Fri, Nov 11, 2011 at 05:28:50PM +0100, Martin Jansa wrote:
   Signed-off-by: Martin Jansa martin.ja...@gmail.com
   ---
meta/recipes-graphics/libsdl/libsdl_1.2.14.bb |   10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
   
   diff --git a/meta/recipes-graphics/libsdl/libsdl_1.2.14.bb 
   b/meta/recipes-graphics/libsdl/libsdl_1.2.14.bb
   index 17a3103..2f49f16 100644
   --- a/meta/recipes-graphics/libsdl/libsdl_1.2.14.bb
   +++ b/meta/recipes-graphics/libsdl/libsdl_1.2.14.bb
   @@ -12,7 +12,7 @@ LIC_FILES_CHKSUM = 
   file://COPYING;md5=27818cd7fd83877a8e3ef82b82798ef4

PROVIDES = virtual/libsdl

   -DEPENDS = ${@base_contains('DISTRO_FEATURES', 'opengl', 
   'virtual/libgl', '', d)} virtual/libx11 libxext libxrandr libxrender 
   alsa-lib tslib
   +DEPENDS = virtual/libx11 libxext libxrandr libxrender tslib
DEPENDS_virtclass-nativesdk = libx11-nativesdk libxrandr-nativesdk 
   libxrender-nativesdk libxext-nativesdk
  
  As Saul reported PACKAGECONFIG adds build time depends not only to
  DEPENDS but they also ends in DEPENDS_virtclass-nativesdk and nothing
  provides virtual/libgl-nativesdk. So I've resend this patch changing
  only alsa handling to PACKAGECONFIG and keeping opengl as it was.
  
  Cheers,
  
PR = r1
   @@ -29,17 +29,21 @@ SRC_URI[sha256sum] = 
   5d927e287034cb6bb0ebccfa382cb1d185cb113c8ab5115a0759798642
inherit autotools binconfig pkgconfig

EXTRA_OECONF = --disable-static --disable-debug --enable-cdrom 
   --enable-threads --enable-timers --enable-endian \
   ---enable-file --disable-oss --enable-alsa --disable-esd 
   --disable-arts \
   +--enable-file --disable-oss --disable-esd --disable-arts 
   \
--disable-diskaudio --disable-nas --disable-esd-shared 
   --disable-esdtest \
--disable-mintaudio --disable-nasm --enable-video-x11 
   --disable-video-dga \
--disable-video-fbcon --disable-video-directfb 
   --disable-video-ps2gs --disable-video-ps3 \
--disable-video-xbios --disable-video-gem 
   --disable-video-dummy \
--enable-input-events --enable-input-tslib 
   --enable-pthreads \
   - ${@base_contains('DISTRO_FEATURES', 'opengl', 
   '--enable-video-opengl', '--disable-video-opengl', d)} \
 --disable-video-svga \
--disable-video-picogui --disable-video-qtopia 
   --enable-dlopen \
--disable-rpath

   +PACKAGECONFIG ??= ${@base_contains('DISTRO_FEATURES', 'opengl', 
   'opengl', '', d)} \
   +   ${@base_contains('DISTRO_FEATURES', 'alsa', 'alsa', 
   '', d)}
   +PACKAGECONFIG[alsa] = --enable-alsa,--disable-alsa,alsa-lib,
   +PACKAGECONFIG[opengl] = 
   --enable-video-opengl,--disable-video-opengl,virtual/libgl,
   +
 
 What we could do is have a 
 PACKAGECONFIG_virtclass-nativesdk = ${@base_contains('DISTRO_FEATURES', 
 'alsa', 'alsa', '', d)} 
 or something like that.

We've discussed this on IRC and just to be sure, do you want me to add
this first or can this patch go in now when builder is greener? The
jansa/pull branch has the version using PACKAGECONFIG only for alsa and
keeping opengl mangling as it was.

http://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/pullid=aafe9d871bcbdf6995432e2c8404a6c49ba942b5

Regards,

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

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