Re: [OE-core] [PATCH] image_types: add IMAGE_ROOTFS_ALIGNMENT
On 03/02/2012 09:10 AM, Ken Werner wrote:
On 03/02/2012 01:44 AM, Saul Wold wrote:
On 03/01/2012 12:55 PM, Ken Werner wrote:
Introduce a new variable called IMAGE_ROOTFS_ALIGNMENT that allows to
control
the aligment of the size of the rootfs. Its default value is set to
1KiB so
that the existing behaviour is not changed. In case the SD card
emulation of
a QEMU system emulator gets used you may set the alignment to 2MiB.
---
meta/classes/image_types.bbclass | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/meta/classes/image_types.bbclass
b/meta/classes/image_types.bbclass
index f756c39..314d6d1 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -55,9 +55,19 @@ def get_imagecmds(d):
cmds += \n + localdata.getVar(runimagecmd, True)
return cmds
+# The default aligment of the size of the rootfs is set to 1KiB. In
case
+# you're using the SD card emulation of a QEMU system simulator you may
+# set this value to 2048 (2MiB alignment).
+IMAGE_ROOTFS_ALIGNMENT ?= 1
+
runimagecmd () {
# Image generation code for image type ${type}
- ROOTFS_SIZE=`du -ks ${IMAGE_ROOTFS}|awk '{base_size = ($1 *
${IMAGE_OVERHEAD_FACTOR}); OFMT = %.0f ; print ((base_size
${IMAGE_ROOTFS_SIZE} ? base_size : ${IMAGE_ROOTFS_SIZE}) +
${IMAGE_ROOTFS_EXTRA_SPACE}) }'`
+ # The base_size gets calculated:
+ # - initial size determined by `du -ks` of the IMAGE_ROOTFS
+ # - then multiplied by the IMAGE_OVERHEAD_FACTOR
+ # - then rounded up to IMAGE_ROOTFS_ALIGNMENT
+ # - finally tested against IMAGE_ROOTFS_SIZE
+ ROOTFS_SIZE=`du -ks ${IMAGE_ROOTFS}|awk '{base_size = $1 *
${IMAGE_OVERHEAD_FACTOR} + ${IMAGE_ROOTFS_ALIGNMENT} - 1; base_size -=
base_size % ${IMAGE_ROOTFS_ALIGNMENT}; print ((base_size
${IMAGE_ROOTFS_SIZE} ? base_size : ${IMAGE_ROOTFS_SIZE}) +
${IMAGE_ROOTFS_EXTRA_SPACE}) }'`
${cmd}
Is there a reason you removed the OFMT from this line?
Hi,
Thanks for reviewing!
I'm not too much into awk but I thought the fraction part of the result
from the modulo operation equals the fraction part of the initial
base_size. Since we subtract each other only the integer part remains.
Of course I'm happy to put the OFMT back in if it's desired. Just let me
know and I'll provide and updated patch.
Regards,
Ken
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] udev-164: don't hardcode path to pidof
* pidof lives in /bin, search it in $PATH.
* Assume pidof's presence.
Signed-off-by: Andreas Oberritter o...@opendreambox.org
---
meta/recipes-core/udev/udev/init |6 ++
meta/recipes-core/udev/udev_164.bb |2 +-
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/meta/recipes-core/udev/udev/init b/meta/recipes-core/udev/udev/init
index 78b5b1c..f9e9014 100644
--- a/meta/recipes-core/udev/udev/init
+++ b/meta/recipes-core/udev/udev/init
@@ -28,10 +28,8 @@ readfile () {
}
kill_udevd() {
- if [ -x /sbin/pidof ]; then
- pid=`/sbin/pidof -x udevd`
- [ -n $pid ] kill $pid
- fi
+ pid=`pidof -x udevd`
+ [ -n $pid ] kill $pid
}
export ACTION=add
diff --git a/meta/recipes-core/udev/udev_164.bb
b/meta/recipes-core/udev/udev_164.bb
index b993a13..d661044 100644
--- a/meta/recipes-core/udev/udev_164.bb
+++ b/meta/recipes-core/udev/udev_164.bb
@@ -1,6 +1,6 @@
include udev.inc
-PR = r11
+PR = r12
SRC_URI += file://udev-166-v4l1-1.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] Recipes with disabled parallel make
On 02.03.2012 23:29, Yury Bushmelev wrote: 2012/2/10 Khem Raj raj.k...@gmail.com: Hi Just grepped for the occurances of disabled parallel make and I see around 40 cases on oe-core git grep PARALLEL_MAKE.*=.*\\ recipes* | grep -v # If someone has time to kill then it would help to see if some of these are fixed by time or can be fixed it can help in paralleling the build a bit more. Well, I have some first results! :) 1. Recipes (files) confirmed to fail with P_M enabled (need to have P_M disabled as it is now): meta/recipes-connectivity/bind/bind_9.8.1.bb meta/recipes-extended/slang/slang_2.2.4.bb meta/recipes-extended/tcp-wrappers/tcp-wrappers_7.6.bb meta/recipes-support/js/js_1.7.0+1.8.0rc1.bb meta/recipes-support/pth/pth_2.0.7.bb meta/recipes-devtools/libtool/libtool_2.4.2.bb might need disabled P_M, too: | ./mipsel-oe-linux-libtool --tag=CC --mode=compile ccache mipsel-oe-linux-gcc -mel -mabi=32 -mhard-float -march=mips32 --sysroot=.../tmp/sysroots/dm7020hd -DHAVE_CONFIG_H -I. -DLTDLOPEN=libltdl -DLT_CONFIG_H='config.h' -DLTDL -I. -I. -Ilibltdl -I./libltdl -I./libltdl/libltdl -Os -pipe -g -feliminate-unused-debug-types -c -o libltdl/libltdl_libltdl_la-slist.lo `test -f 'libltdl/slist.c' || echo './'`libltdl/slist.c | /bin/sh: ./mipsel-oe-linux-libtool: /bin/sh: bad interpreter: Text file busy | make[2]: *** [libltdl/libltdl_libltdl_la-slist.lo] Error 126 | make[2]: *** Waiting for unfinished jobs This was a fresh build with clean tmp and sstate-cache. I've just seen this failue for the first time. BB_NUMBER_THREADS = 4 PARALLEL_MAKE = -j 4 Regards, Andreas ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] udev-164: don't hardcode path to pidof
Acked-by: Otavio Salvador ota...@ossystems.com.br On Thu, Mar 8, 2012 at 09:08, Andreas Oberritter o...@opendreambox.org wrote: * pidof lives in /bin, search it in $PATH. * Assume pidof's presence. Signed-off-by: Andreas Oberritter o...@opendreambox.org -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] kernel.bbclass: Remove warnings for modutils and modprobe.d
On 3/7/12 11:04 AM, Darren Hart wrote:
On 03/07/2012 12:21 AM, Koen Kooi wrote:
Op 7 mrt. 2012, om 09:06 heeft Darren Hart het volgende geschreven:
Fixes [Yocto #2036]
The source and build directories are unused, remove them.
The modutils and modprobe.d directories may be used if modules are built that
are either autoloaded or have modprobe.d entries. This isn't known at install
time, so check after the package split if these directories are empty and
remove them if they are.
Signed-off-by: Darren Hartdvh...@linux.intel.com
CC: Paul Eggletonpaul.eggle...@linux.intel.com
---
meta/classes/kernel.bbclass | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 8fbec90..169df33 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -105,6 +105,8 @@ kernel_do_install() {
oe_runmake DEPMOD=echo INSTALL_MOD_PATH=${D} modules_install
rm -f ${D}/lib/modules/${KERNEL_VERSION}/modules.order
rm -f ${D}/lib/modules/${KERNEL_VERSION}/modules.builtin
+ rm ${D}/lib/modules/${KERNEL_VERSION}/build
+ rm ${D}/lib/modules/${KERNEL_VERSION}/source
How do you want to support on-target building of exernal modules?
That is an open issue that needs to be addressed, but we don't install
the build or source directories now (unless I'm missing something), so
these are links to nowhere at the moment.
We do have a bug open to support on-target module building. I supect
we'll need to add these as part of a headers package or similar. So
these may come back.
Just as a note.. headers package(s) are the wrong way to support kernel modules
compilation on the target. You really need to supply a configured kernel source
tree --- often you can dump the .c files though. Kernel headers (for module
compilation) and userspace are often intentionally different.. and people get
this confused often. (I can't express how often I've had to convince someone
that, no you can't guaranty a working kernel module from the stuff in /usr/include!)
The right approach is to provide, as part of the kernel itself, a source
tree/headers package tha installes into the
{D}/lib/modules/${KERNEL_VERSION}/source (or similar) directory, and instruct
people to use that location when building kernel modules on the target.
--Mark
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [CONSOLIDATED PULL 02/20] self-hosted: Fix multiple libx11 error
On Tue, 2012-03-06 at 09:03 -0800, Saul Wold wrote: From: Zhai Edwin edwin.z...@intel.com Self-hosted needs package libx11-dev, which is ambiguous as virtual/libx11 is provided by libx11 or libx11-trim. This patch explictly set the perferred one, libx11-trim-dev, to avoid this. Signed-off-by: Zhai Edwin edwin.z...@intel.com --- meta/recipes-core/tasks/task-self-hosted.bb |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) This patch should be dropped, an alternative fix has been merged (http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=157b44cf72c8660ba53b8fe1b321d2ef314c07ef) Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [CONSOLIDATED PULL 01/20] libsdl: add DirectFB support
On Tue, 2012-03-06 at 09:03 -0800, Saul Wold wrote:
From: Andreas Oberritter o...@opendreambox.org
* Use conditional dependencies for DirectFB, like
it's already done for OpenGL and X11.
Signed-off-by: Andreas Oberritter o...@opendreambox.org
---
meta/recipes-graphics/libsdl/libsdl_1.2.14.bb |8 +---
1 files changed, 5 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 62a2d1f..5c9e645 100644
--- a/meta/recipes-graphics/libsdl/libsdl_1.2.14.bb
+++ b/meta/recipes-graphics/libsdl/libsdl_1.2.14.bb
@@ -12,12 +12,13 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=27818cd7fd83877a8e3ef82b82798ef4
PROVIDES = virtual/libsdl
-DEPENDS = ${@base_contains('DISTRO_FEATURES', 'opengl', 'virtual/libgl',
'', d)} \
+DEPENDS = ${@base_contains('DISTRO_FEATURES', 'directfb', 'directfb', '',
d)} \
+ ${@base_contains('DISTRO_FEATURES', 'opengl', 'virtual/libgl',
'', d)} \
${@base_contains('DISTRO_FEATURES', 'x11', 'virtual/libx11
libxext libxrandr libxrender', '', d)} \
tslib
DEPENDS_virtclass-nativesdk = ${@base_contains('DISTRO_FEATURES', 'x11',
'libx11-nativesdk libxrandr-nativesdk libxrender-nativesdk
libxext-nativesdk', '', d)}
-PR = r6
+PR = r7
SRC_URI = http://www.libsdl.org/release/SDL-${PV}.tar.gz \
file://configure_tweak.patch \
@@ -35,9 +36,10 @@ EXTRA_OECONF = --disable-static --disable-debug
--enable-cdrom --enable-threads
--enable-file --disable-oss --disable-esd --disable-arts \
--disable-diskaudio --disable-nas --disable-esd-shared
--disable-esdtest \
--disable-mintaudio --disable-nasm --disable-video-dga \
---disable-video-fbcon --disable-video-directfb
--disable-video-ps2gs --disable-video-ps3 \
+--disable-video-fbcon --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', 'directfb',
'--enable-video-directfb', '--disable-video-directfb', d)} \
${@base_contains('DISTRO_FEATURES', 'opengl',
'--enable-video-opengl', '--disable-video-opengl', d)} \
${@base_contains('DISTRO_FEATURES', 'x11',
'--enable-video-x11', '--disable-video-x11', d)} \
--disable-video-svga \
I'm going to take this but in future I'd prefer to see changes like this
starting to use PACKAGECONFIG.
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] udev-164: don't hardcode path to pidof
On Thu, 2012-03-08 at 13:08 +0100, Andreas Oberritter wrote: * pidof lives in /bin, search it in $PATH. * Assume pidof's presence. Signed-off-by: Andreas Oberritter o...@opendreambox.org --- meta/recipes-core/udev/udev/init |6 ++ meta/recipes-core/udev/udev_164.bb |2 +- 2 files changed, 3 insertions(+), 5 deletions(-) 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] gtk+: Amend upstream status of configure-nm.patch
On Thu, 2012-03-08 at 09:47 +0800, James Limbouris wrote: Signed-off-by: James Limbouris ja...@digitalmatter.com.au --- .../gtk+/gtk+-2.24.8/configure-nm.patch|4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) 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 v2] bzip2: split into binary and library packages
On Wed, 2012-03-07 at 22:03 +0100, Andreas Oberritter wrote: * Create libbz2 (and -dev, -staticdev), which can be installed without the bzip2 executables. Signed-off-by: Andreas Oberritter o...@opendreambox.org --- v1-v2: Bump PR of every package depending on bzip2 as suggested by Koen. 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] [PATCHv3] bluez4: add dependency on libcheck to enable test modules
On Wed, 2012-03-07 at 14:48 -0600, Chase Maupin wrote:
* The later versions of bluez such as 4.98 require libcheck
in order to build the test packages as enabled by the
--enable-test option passed in EXTRA_OECONF.
* Failure to have the libcheck package available results in the
configure script ignoring the --enable-test option and not
building the test modules.
* Adding libcheck, which is greater than the minimum required
version of the check library of 0.9.6 allows building the
test modules.
* Build tested for am335x-evm MACHINE type and run time tested
by back porting this fix to the oe-classic and arago setup
and booting on am335x-evm.
Signed-off-by: Chase Maupin chase.mau...@ti.com
---
* Updated in version 2:
* Bumped the PR of the bluez4_4.98 recipe. I assume this is the
way to handle changes to the .inc file since there is no INC_PR
* Updated in version 3:
* Fixed typo in commit message
---
meta/recipes-connectivity/bluez/bluez4.inc |2 +-
meta/recipes-connectivity/bluez/bluez4_4.98.bb |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-connectivity/bluez/bluez4.inc
b/meta/recipes-connectivity/bluez/bluez4.inc
index 9158687..fbbe0bf 100644
--- a/meta/recipes-connectivity/bluez/bluez4.inc
+++ b/meta/recipes-connectivity/bluez/bluez4.inc
@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e \
file://COPYING.LIB;md5=fb504b67c50331fc78734fed90fb0e09 \
file://src/main.c;beginline=1;endline=24;md5=9bc54b93cd7e17bf03f52513f39f926e
\
file://sbc/sbc.c;beginline=1;endline=25;md5=1a40781ed30d50d8639323a184aeb191
-DEPENDS = udev alsa-lib libusb dbus-glib glib-2.0
+DEPENDS = udev alsa-lib libusb dbus-glib glib-2.0 libcheck
RDEPENDS_${PN}-dev = bluez-hcidump
ASNEEDED =
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] kernel.bbclass: Remove warnings for modutils and modprobe.d
On Wed, 2012-03-07 at 00:06 -0800, Darren Hart wrote: Fixes [Yocto #2036] The source and build directories are unused, remove them. The modutils and modprobe.d directories may be used if modules are built that are either autoloaded or have modprobe.d entries. This isn't known at install time, so check after the package split if these directories are empty and remove them if they are. Signed-off-by: Darren Hart dvh...@linux.intel.com CC: Paul Eggleton paul.eggle...@linux.intel.com --- meta/classes/kernel.bbclass | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) 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] external-csl-toolchain: override PKGV, not PKGV_${PN}
On Wed, 2012-03-07 at 10:24 -0600, Christopher Larson wrote:
From: Christopher Larson chris_lar...@mentor.com
This is needed to ensure that the RDEPENDS_${PN}-dev,
RDEPENDS_${PN}-staticdev, and RRECOMMENDS_${PN}-dbg are accurate with respect
to the PKGV of the ${PN} package, and incidentally fixes an rpm packaging
issue, as rpm dislikes the recipe PV as PKGV.
Signed-off-by: Christopher Larson chris_lar...@mentor.com
---
meta/recipes-core/meta/external-csl-toolchain.bb | 17 +
1 files changed, 1 insertions(+), 16 deletions(-)
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] arch-powerpc.inc: use default value of TUNE_PKGARCH
On Tue, 2012-03-06 at 17:20 -0600, Matthew McClintock wrote:
We can use the default value for TUNE_PKGARCH, and now we just
append -nf if TARGET_FPU is fpu-soft
Signed-off-by: Matthew McClintock m...@freescale.com
---
meta/conf/machine/include/powerpc/arch-powerpc.inc |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/meta/conf/machine/include/powerpc/arch-powerpc.inc
b/meta/conf/machine/include/powerpc/arch-powerpc.inc
index c9b2829..abd72ed 100644
--- a/meta/conf/machine/include/powerpc/arch-powerpc.inc
+++ b/meta/conf/machine/include/powerpc/arch-powerpc.inc
@@ -18,10 +18,8 @@ TARGET_FPU .= ${@bb.utils.contains(TUNE_FEATURES,
fpu-soft, soft, , d)}
ABIEXTENSION = ${@['','spe'][d.getVar('TARGET_FPU', True) in ['ppc-efd',
'ppc-efs']]}
-PPCPKGSFX_FPU = ${@bb.utils.contains(TUNE_FEATURES, fpu-hard , ,
-nf, d)}
-
-PPCPKGARCH = ${TUNE_ARCH}${PPCPKGSFX_FPU}
-TUNE_PKGARCH ?= ${PPCPKGARCH}
+PPCPKGSFX_FPU = ${@['', '-nf'][bb.data.getVar('TARGET_FPU',d,1) in
['fpu-soft']]}
+TUNE_PKGARCH_append = ${PPCPKGSFX_FPU}
Can we please do d.getVar(xxx, True) and not bb.data and ,1 :)
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] prservice: Added sanity check for prservice connection.
On Wed, 2012-03-07 at 15:36 +0800, Lianhao Lu wrote: Fixed bug [YOCTO #2052]. Added sanity check for variables of PRSERV_HOST and PRSERV_PORT, also for the connection availabity of prservice. Signed-off-by: Lianhao Lu lianhao...@intel.com --- meta/classes/prexport.bbclass |4 +++- meta/classes/primport.bbclass |3 +++ meta/lib/oe/prservice.py | 18 +- 3 files changed, 23 insertions(+), 2 deletions(-) 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] Undeterministic builds with different distributions
Hello Mark, thank you for your remarks. I'm going to file bug reports for everything I'm unable to fix myself. On 08.03.2012 18:50, Mark Hatle wrote: On 3/7/12 8:27 PM, Andreas Oberritter wrote: * Owners differ, e.g.: --rw-rw-r-- 1000 1000 2048 ./lib/firmware/rt73.bin +-rw-r--r-- root root 2048 ./lib/firmware/rt73.bin Builds were done by userids 1000 (a) and 1001 (b). Are you comparing final images, sysroots or? If you are comparing tarball images, be sure to either actually be root when you extract it, or enable pseudo for the proper root permissions/user/groups emulation. I compared files-in-image.txt, generated by buildhistory.bbclass. Since on machine b the displayed user is root, I suppose that the displayed username is set by pseudo and will match the username of the final image. Also note that only few files had uid 1000 on machine a. I'm going to clean tmp and sstate-cache on both machines and rebuild with matching build directories. Regards, Andreas ___ 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] kernel.bbclass: Remove warnings for modutils and modprobe.d
On Thu, 2012-03-08 at 11:39 -0600, Mark Hatle wrote:
On 3/7/12 11:04 AM, Darren Hart wrote:
On 03/07/2012 12:21 AM, Koen Kooi wrote:
Op 7 mrt. 2012, om 09:06 heeft Darren Hart het volgende geschreven:
Fixes [Yocto #2036]
The source and build directories are unused, remove them.
The modutils and modprobe.d directories may be used if modules are built
that
are either autoloaded or have modprobe.d entries. This isn't known at
install
time, so check after the package split if these directories are empty and
remove them if they are.
Signed-off-by: Darren Hartdvh...@linux.intel.com
CC: Paul Eggletonpaul.eggle...@linux.intel.com
---
meta/classes/kernel.bbclass | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 8fbec90..169df33 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -105,6 +105,8 @@ kernel_do_install() {
oe_runmake DEPMOD=echo INSTALL_MOD_PATH=${D} modules_install
rm -f ${D}/lib/modules/${KERNEL_VERSION}/modules.order
rm -f ${D}/lib/modules/${KERNEL_VERSION}/modules.builtin
+ rm ${D}/lib/modules/${KERNEL_VERSION}/build
+ rm ${D}/lib/modules/${KERNEL_VERSION}/source
How do you want to support on-target building of exernal modules?
That is an open issue that needs to be addressed, but we don't install
the build or source directories now (unless I'm missing something), so
these are links to nowhere at the moment.
We do have a bug open to support on-target module building. I supect
we'll need to add these as part of a headers package or similar. So
these may come back.
Just as a note.. headers package(s) are the wrong way to support kernel
modules
compilation on the target. You really need to supply a configured kernel
source
tree --- often you can dump the .c files though. Kernel headers (for module
compilation) and userspace are often intentionally different.. and people get
this confused often. (I can't express how often I've had to convince someone
that, no you can't guaranty a working kernel module from the stuff in
/usr/include!)
The right approach is to provide, as part of the kernel itself, a source
tree/headers package tha installes into the
{D}/lib/modules/${KERNEL_VERSION}/source (or similar) directory, and
instruct
people to use that location when building kernel modules on the target.
We already provide such a source tree for external module compilation
within the build itself. There is also an open bug to provide the same
tree for on-target use so I think we have a good plan which is
consistent with the above. For now I really want to clean up the warning
messages. We can add correct symlinks once we have on target support so
I've taken Darren's patch.
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] udev-164: don't hardcode path to pidof
* pidof lives in /bin, search it in $PATH.
* Assume pidof's presence.
* Remove -e shell option, because pidof may return nonzero.
Signed-off-by: Andreas Oberritter o...@opendreambox.org
---
v1-v2: Removed -e.
meta/recipes-core/udev/udev/init |8 +++-
meta/recipes-core/udev/udev_164.bb |2 +-
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/meta/recipes-core/udev/udev/init b/meta/recipes-core/udev/udev/init
index 78b5b1c..d521685 100644
--- a/meta/recipes-core/udev/udev/init
+++ b/meta/recipes-core/udev/udev/init
@@ -1,4 +1,4 @@
-#!/bin/sh -e
+#!/bin/sh
### BEGIN INIT INFO
# Provides: udev
@@ -28,10 +28,8 @@ readfile () {
}
kill_udevd() {
- if [ -x /sbin/pidof ]; then
- pid=`/sbin/pidof -x udevd`
- [ -n $pid ] kill $pid
- fi
+ pid=`pidof -x udevd`
+ [ -n $pid ] kill $pid
}
export ACTION=add
diff --git a/meta/recipes-core/udev/udev_164.bb
b/meta/recipes-core/udev/udev_164.bb
index b993a13..d661044 100644
--- a/meta/recipes-core/udev/udev_164.bb
+++ b/meta/recipes-core/udev/udev_164.bb
@@ -1,6 +1,6 @@
include udev.inc
-PR = r11
+PR = r12
SRC_URI += file://udev-166-v4l1-1.patch
--
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] udev-164: fixup don't hardcode path to pidof
* Remove -e shell option, because pidof may return nonzero. Signed-off-by: Andreas Oberritter o...@opendreambox.org --- meta/recipes-core/udev/udev/init |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/meta/recipes-core/udev/udev/init b/meta/recipes-core/udev/udev/init index f9e9014..d521685 100644 --- a/meta/recipes-core/udev/udev/init +++ b/meta/recipes-core/udev/udev/init @@ -1,4 +1,4 @@ -#!/bin/sh -e +#!/bin/sh ### BEGIN INIT INFO # Provides: udev -- 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 v2] udev-164: fixup don't hardcode path to pidof
* Remove -e shell option, because pidof may return nonzero. Signed-off-by: Andreas Oberritter o...@opendreambox.org --- * Of course I forgot to bump PR. meta/recipes-core/udev/udev/init |2 +- meta/recipes-core/udev/udev_164.bb |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-core/udev/udev/init b/meta/recipes-core/udev/udev/init index f9e9014..d521685 100644 --- a/meta/recipes-core/udev/udev/init +++ b/meta/recipes-core/udev/udev/init @@ -1,4 +1,4 @@ -#!/bin/sh -e +#!/bin/sh ### BEGIN INIT INFO # Provides: udev diff --git a/meta/recipes-core/udev/udev_164.bb b/meta/recipes-core/udev/udev_164.bb index d661044..c5813ec 100644 --- a/meta/recipes-core/udev/udev_164.bb +++ b/meta/recipes-core/udev/udev_164.bb @@ -1,6 +1,6 @@ include udev.inc -PR = r12 +PR = r13 SRC_URI += file://udev-166-v4l1-1.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 v2] udev-164: don't hardcode path to pidof
On 08.03.2012 22:12, Andreas Oberritter wrote: * pidof lives in /bin, search it in $PATH. * Assume pidof's presence. * Remove -e shell option, because pidof may return nonzero. I just noticed that v1 was already merged, so I'll send an incremental patch in a minute. Regards, Andreas ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] packagedata.py: Fix get_subpkgedata_fn for multilib
Signed-off-by: Matthew McClintock m...@freescale.com
---
meta/lib/oe/packagedata.py |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/meta/lib/oe/packagedata.py b/meta/lib/oe/packagedata.py
index a7a40f0..124a49d 100644
--- a/meta/lib/oe/packagedata.py
+++ b/meta/lib/oe/packagedata.py
@@ -27,6 +27,13 @@ def read_pkgdatafile(fn):
def get_subpkgedata_fn(pkg, d):
archs = d.expand(${PACKAGE_ARCHS}).split( )
+mlarchs = d.expand(${MULTILIB_PACKAGE_ARCHS}, d).split( )
+
+for mlarch in mlarchs:
+if _ in mlarch:
+prefix, new_arch = mlarch.split(_)
+archs.append(new_arch)
+
archs.reverse()
pkgdata = d.expand('${TMPDIR}/pkgdata/')
targetdir = d.expand('${TARGET_VENDOR}-${TARGET_OS}/runtime/')
--
1.7.6.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] arch-powerpc.inc: use default value of TUNE_PKGARCH
We can use the default value for TUNE_PKGARCH, and now we just
append -nf if TARGET_FPU is fpu-soft
Signed-off-by: Matthew McClintock m...@freescale.com
---
meta/conf/machine/include/powerpc/arch-powerpc.inc |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/meta/conf/machine/include/powerpc/arch-powerpc.inc
b/meta/conf/machine/include/powerpc/arch-powerpc.inc
index c9b2829..9f588e8 100644
--- a/meta/conf/machine/include/powerpc/arch-powerpc.inc
+++ b/meta/conf/machine/include/powerpc/arch-powerpc.inc
@@ -18,10 +18,8 @@ TARGET_FPU .= ${@bb.utils.contains(TUNE_FEATURES,
fpu-soft, soft, , d)}
ABIEXTENSION = ${@['','spe'][d.getVar('TARGET_FPU', True) in ['ppc-efd',
'ppc-efs']]}
-PPCPKGSFX_FPU = ${@bb.utils.contains(TUNE_FEATURES, fpu-hard , , -nf,
d)}
-
-PPCPKGARCH = ${TUNE_ARCH}${PPCPKGSFX_FPU}
-TUNE_PKGARCH ?= ${PPCPKGARCH}
+PPCPKGSFX_FPU = ${@['', '-nf'][d.getVar('TARGET_FPU',d,1) in ['fpu-soft']]}
+TUNE_PKGARCH_append = ${PPCPKGSFX_FPU}
# Basic tune definitions
AVAILTUNES += powerpc powerpc-nf
--
1.7.6.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH][RFC] bitbake.conf: use empty SRC_URI by default
On 08.03.2012 03:51, Andreas Oberritter wrote:
* Otherwise, recipes that only append to SRC_URI instead of
overwriting it will get the full path of the recipe written
into the Source: field of the package.
Signed-off-by: Andreas Oberritter o...@opendreambox.org
---
* I haven't tested this yet, I don't know whether there
are any caveeats. What's the purpose of having ${FILE}
in there, anyway?
Richard, did you commit this by accident? In the meantime I've started a
clean build with this patch applied and noticed eglibc-locale failing,
because opkg-build complains about a missing Source field.
Regards,
Andreas
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] want to confirm that include/require is a pure textual substitution
currently writing a tutorial involving OE and working up to yocto
and want to verify a couple things. i'm reading the OE manual,
section on include/require:
http://docs.openembedded.org/usermanual/usermanual.html#recipes_require
and want to verify that that is purely a textual inclusion, so that
*anything* that is common across a number of .bb files can be
centralized in a .inc file, correct?
and on that note, a larger question about the OE manual itself. in
that same section, there's a reference to the cherokee package, and
the alleged .bb file:
PR = r7
SRC_URI_append = file://configure.patch \
file://Makefile.in.patch \
file://Makefile.cget.patch \
file://util.patch
require cherokee.inc
do_configure() {
gnu-configize
oe_runconf
sed -i 's:-L\$:-L${STAGING_LIBDIR} -L\$:' ${S}/*libtool
}
unsurprisingly, that's out of date as the current .bb file is
simply:
require cherokee.inc
PR = ${INC_PR}.0
SRC_URI[md5sum] = 21b01e7d45c0e82ecc0c4257a9c27feb
SRC_URI[sha256sum] =
042b5687b1a3db3ca818167548ce5d32c35e227c6640732dcb622a6f4a078b7d
but that's not my point. since i want my tutorial to walk someone
through various files, given the split into the oe-core and
meta-openembedded layers, i'm thinking of using examples strictly out
of oe-core since there's more than enough there. but the cherokee
example is in the meta-openembedded layer, and that distinction
doesn't appear to be made early in the OE manual anywhere.
is there a plan to revise that manual to incorporate the
distinction? is there a newer manual elsewhere?
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] packagedata.py: Fix get_subpkgedata_fn for multilib
Signed-off-by: Matthew McClintock m...@freescale.com
---
meta/lib/oe/packagedata.py |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/meta/lib/oe/packagedata.py b/meta/lib/oe/packagedata.py
index a7a40f0..daee779 100644
--- a/meta/lib/oe/packagedata.py
+++ b/meta/lib/oe/packagedata.py
@@ -27,6 +27,14 @@ def read_pkgdatafile(fn):
def get_subpkgedata_fn(pkg, d):
archs = d.expand(${PACKAGE_ARCHS}).split( )
+mlarchs = bb.data.getVar(MULTILIB_PACKAGE_ARCHS, d) or None
+
+if mlarchs:
+for mlarch in mlarchs.split( ):
+if _ in mlarch:
+prefix, new_arch = mlarch.split(_)
+archs.append(new_arch)
+
archs.reverse()
pkgdata = d.expand('${TMPDIR}/pkgdata/')
targetdir = d.expand('${TARGET_VENDOR}-${TARGET_OS}/runtime/')
--
1.7.6.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] packagedata.py: Fix get_subpkgedata_fn for multilib
Signed-off-by: Matthew McClintock m...@freescale.com
---
meta/lib/oe/packagedata.py |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/meta/lib/oe/packagedata.py b/meta/lib/oe/packagedata.py
index a7a40f0..5759fe6 100644
--- a/meta/lib/oe/packagedata.py
+++ b/meta/lib/oe/packagedata.py
@@ -27,6 +27,14 @@ def read_pkgdatafile(fn):
def get_subpkgedata_fn(pkg, d):
archs = d.expand(${PACKAGE_ARCHS}).split( )
+mlarchs = bb.data.getVar(MULTILIB_PACKAGE_ARCHS, d) or None
+
+if mlarchs:
+for mlarch in mlarchs.split( ):
+if _ in mlarch:
+prefix, split, new_arch = mlarch.partition(_)
+archs.append(new_arch)
+
archs.reverse()
pkgdata = d.expand('${TMPDIR}/pkgdata/')
targetdir = d.expand('${TARGET_VENDOR}-${TARGET_OS}/runtime/')
--
1.7.6.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] a fix to 2067
The following changes since commit 6bd23e0faf329f086bb4885991ce5f5d095dac56: adt-installer: Corrected wrong environment file names. (2012-03-08 12:18:52 -0800) are available in the git repository at: git://git.pokylinux.org/poky-contrib dcui/fix_2067 http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dcui/fix_2067 Dexuan Cui (1): image_types: ensure .rootfs.ext3 is created before vmdk is created. meta/classes/image_types.bbclass |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) -- 1.7.6 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] image_types: ensure .rootfs.ext3 is created before vmdk is created.
In the case of self-hosted-image.bb, IMAGE_FSTYPES = vmdk, so the
variables alltypes and subimages don't contain ext3, and .rootfs.ext3
won't be created, and finally the generated .hddimg and .vmdk don't have
an actual rootfs -- the size of the .vmdk file is only about 9MB.
[YOCTO #2067]
Signed-off-by: Dexuan Cui dexuan@intel.com
---
meta/classes/image_types.bbclass |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 8b82018..e92f519 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -26,13 +26,19 @@ def get_imagecmds(d):
# Live and VMDK images will be processed via inheriting
# bbclass and does not get processed here.
# vmdk depend on live images also depend on ext3 so ensure its present
+# Note: we need to ensure ext3 is in alltypes, otherwise, subimages may
+# not contain ext3 and the .rootfs.ext3 file won't be created.
if vmdk in types:
if ext3 not in types:
types.append(ext3)
+if ext3 not in alltypes:
+alltypes.append(ext3)
types.remove(vmdk)
if live in types:
if ext3 not in types:
types.append(ext3)
+if ext3 not in alltypes:
+alltypes.append(ext3)
types.remove(live)
if d.getVar('IMAGE_LINK_NAME', True):
--
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] [PATCH 1/1] image_types: ensure .rootfs.ext3 is created before vmdk is created.
On 03/08/2012 11:19 PM, Dexuan Cui wrote:
In the case of self-hosted-image.bb, IMAGE_FSTYPES = vmdk, so the
variables alltypes and subimages don't contain ext3, and .rootfs.ext3
won't be created, and finally the generated .hddimg and .vmdk don't have
an actual rootfs -- the size of the .vmdk file is only about 9MB.
[YOCTO #2067]
Signed-off-by: Dexuan Cuidexuan@intel.com
Nice Catch!
Acked-by: Saul Wold s...@linux.intel.com
Sau!
---
meta/classes/image_types.bbclass |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 8b82018..e92f519 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -26,13 +26,19 @@ def get_imagecmds(d):
# Live and VMDK images will be processed via inheriting
# bbclass and does not get processed here.
# vmdk depend on live images also depend on ext3 so ensure its present
+# Note: we need to ensure ext3 is in alltypes, otherwise, subimages may
+# not contain ext3 and the .rootfs.ext3 file won't be created.
if vmdk in types:
if ext3 not in types:
types.append(ext3)
+if ext3 not in alltypes:
+alltypes.append(ext3)
types.remove(vmdk)
if live in types:
if ext3 not in types:
types.append(ext3)
+if ext3 not in alltypes:
+alltypes.append(ext3)
types.remove(live)
if d.getVar('IMAGE_LINK_NAME', True):
___
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] image_types: ensure .rootfs.ext3 is created before vmdk is created.
Saul Wold wrote on 2012-03-09: On 03/08/2012 11:19 PM, Dexuan Cui wrote: In the case of self-hosted-image.bb, IMAGE_FSTYPES = vmdk, so the variables alltypes and subimages don't contain ext3, and .rootfs.ext3 won't be created, and finally the generated .hddimg and .vmdk don't have an actual rootfs -- the size of the .vmdk file is only about 9MB. [YOCTO #2067] Signed-off-by: Dexuan Cuidexuan@intel.com Nice Catch! Acked-by: Saul Wold s...@linux.intel.com BTW, I didn't find the bug in my previous test because I didn't build From scratch, so actually I already had a file tmp/deploy/image/self-hosted-image-qemux86.ext3, and according to bootimg.bbclass's populate(), we used it -- but we should use a new .ext3 file. 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 v2] packagedata.py: Fix get_subpkgedata_fn for multilib
Ugh this is supposed to be v3.
-M
On Fri, Mar 9, 2012 at 12:20 AM, Matthew McClintock m...@freescale.com wrote:
Signed-off-by: Matthew McClintock m...@freescale.com
---
meta/lib/oe/packagedata.py | 8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/meta/lib/oe/packagedata.py b/meta/lib/oe/packagedata.py
index a7a40f0..5759fe6 100644
--- a/meta/lib/oe/packagedata.py
+++ b/meta/lib/oe/packagedata.py
@@ -27,6 +27,14 @@ def read_pkgdatafile(fn):
def get_subpkgedata_fn(pkg, d):
archs = d.expand(${PACKAGE_ARCHS}).split( )
+ mlarchs = bb.data.getVar(MULTILIB_PACKAGE_ARCHS, d) or None
+
+ if mlarchs:
+ for mlarch in mlarchs.split( ):
+ if _ in mlarch:
+ prefix, split, new_arch = mlarch.partition(_)
+ archs.append(new_arch)
+
archs.reverse()
pkgdata = d.expand('${TMPDIR}/pkgdata/')
targetdir = d.expand('${TARGET_VENDOR}-${TARGET_OS}/runtime/')
--
1.7.6.1
___
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
