[OE-core] [oe-core][PATCH 2/2] kernel.bbclass: unify white spaces
* indentation was with spaces and tabs, unify to use tabs instead of
spaces, because python populate_packages expects tabs (or 8 spaces)
and we're doing populate_packages_preppend here
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
meta/classes/kernel.bbclass | 38 +++---
1 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 8cd5fc7..f1494b1 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -11,15 +11,15 @@ INITRAMFS_IMAGE ?=
INITRAMFS_TASK ?=
python __anonymous () {
-kerneltype = d.getVar('KERNEL_IMAGETYPE', True) or ''
-if kerneltype == 'uImage':
- depends = d.getVar(DEPENDS, True)
- depends = %s u-boot-mkimage-native % depends
- d.setVar(DEPENDS, depends)
-
-image = d.getVar('INITRAMFS_IMAGE', True)
-if image:
-d.setVar('INITRAMFS_TASK', '${INITRAMFS_IMAGE}:do_rootfs')
+ kerneltype = d.getVar('KERNEL_IMAGETYPE', True) or ''
+ if kerneltype == 'uImage':
+ depends = d.getVar(DEPENDS, True)
+ depends = %s u-boot-mkimage-native % depends
+ d.setVar(DEPENDS, depends)
+
+ image = d.getVar('INITRAMFS_IMAGE', True)
+ if image:
+ d.setVar('INITRAMFS_TASK', '${INITRAMFS_IMAGE}:do_rootfs')
}
inherit kernel-arch deploy
@@ -91,7 +91,7 @@ kernel_do_compile() {
do_compile_kernelmodules() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
if (grep -q -i -e '^CONFIG_MODULES=y$' .config); then
- oe_runmake ${PARALLEL_MAKE} modules CC=${KERNEL_CC}
LD=${KERNEL_LD}
+ oe_runmake ${PARALLEL_MAKE} modules CC=${KERNEL_CC}
LD=${KERNEL_LD}
else
bbnote no modules to compile
fi
@@ -115,7 +115,7 @@ kernel_do_install() {
#
# Install various kernel output (zImage, map file, config, module
support files)
- #
+ #
install -d ${D}/${KERNEL_IMAGEDEST}
install -d ${D}/boot
install -m 0644 ${KERNEL_OUTPUT}
${D}/${KERNEL_IMAGEDEST}/${KERNEL_IMAGETYPE}-${KERNEL_VERSION}
@@ -188,7 +188,7 @@ kernel_do_install() {
bin_files=arch/powerpc/boot/addnote arch/powerpc/boot/hack-coff \
arch/powerpc/boot/mktree
for entry in $bin_files; do
- rm -f $kerneldir/$entry
+ rm -f $kerneldir/$entry
done
}
@@ -386,10 +386,10 @@ python populate_packages_prepend () {
return deps
def get_dependencies(file, pattern, format):
-# file no longer includes PKGD
+ # file no longer includes PKGD
file = file.replace(d.getVar('PKGD', True) or '', '', 1)
-# instead is prefixed with /lib/modules/${KERNEL_VERSION}
-file = file.replace(/lib/modules/%s/ %
d.getVar('KERNEL_VERSION', True) or '', '', 1)
+ # instead is prefixed with /lib/modules/${KERNEL_VERSION}
+ file = file.replace(/lib/modules/%s/ %
d.getVar('KERNEL_VERSION', True) or '', '', 1)
if module_deps.has_key(file):
import re
@@ -493,11 +493,11 @@ python populate_packages_prepend () {
do_sizecheck() {
if [ ! -z ${KERNEL_IMAGE_MAXSIZE} ]; then
size=`ls -l ${KERNEL_OUTPUT} | awk '{ print $5}'`
- if [ $size -ge ${KERNEL_IMAGE_MAXSIZE} ]; then
+ if [ $size -ge ${KERNEL_IMAGE_MAXSIZE} ]; then
rm ${KERNEL_OUTPUT}
- die This kernel (size=$size
${KERNEL_IMAGE_MAXSIZE}) is too big for your device. Please reduce the size of
the kernel by making more of it modular.
- fi
- fi
+ die This kernel (size=$size ${KERNEL_IMAGE_MAXSIZE})
is too big for your device. Please reduce the size of the kernel by making more
of it modular.
+ fi
+ fi
}
addtask sizecheck before do_install after do_compile
--
1.7.8.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] qt4: move from 4.8.0 to 4.8.1
Hi Andreas,
I have one question about the qt-x11-free, is it possible to enable
the -sm -accessibility in oe-core, please? There is a meta-kde
layer which requires the -sm -accessibility, but they are disabled
in oe-core currently:
QT_DISTRO_FLAGS ?= -no-accessibility -no-sm
So there is a qt4-x11-free_4.8.0.bbappend in meta-kde, once the
the oe-core upgrade to 4.8.1, then the meta-kde has to uprade again.
I checked the log of the qt4, can't find the relative log for
-no-accessibility -no-sm.
If it is possible to enable them in oe-core, I'd like to send a patch for
them.
// Robert
On 03/29/2012 03:46 AM, Andreas Oberritter wrote:
* No changes other than source checksums and PR at recipe level.
* DEFAULT_PREFERENCE still set to -1
Signed-off-by: Andreas Oberrittero...@opendreambox.org
---
* Considering that OE-core is in a stabilization phase, updating
Qt may be a bad idea. However, version 4.8.0 has D_P=-1, so
4.7.4 still gets built by default.
* Even if this won't get applied now, other people might be
interested in testing this version and giving feedback.
* This recipe has been compile-tested on x86 and x86_64
for mips32el (qt4-native and qt4-embedded).
meta/recipes-qt/qt4/{qt-4.8.0.inc = qt-4.8.1.inc} |4 ++--
.../0001-Added-Openembedded-crossarch-option.patch |0
.../{qt-4.8.0 = qt-4.8.1}/configure-lflags.patch |0
.../configure_oe_compiler.patch|0
.../{qt-4.8.0 = qt-4.8.1}/fix-translations.patch |0
.../recipes-qt/qt4/{qt-4.8.0 = qt-4.8.1}/g++.conf |0
.../hack-out-pg2-4.7.0.patch |0
.../qt4/{qt-4.8.0 = qt-4.8.1}/linux.conf |0
.../{qt-4.8.0 = qt-4.8.1}/pulseaudio-config.patch |0
.../{qt-4.8.0 = qt-4.8.1}/qmake_cxx_eval.patch|0
.../{qt-4.8.0 = qt-4.8.1}/qmake_pri_fixes.patch |0
...qt4-embedded_4.8.0.bb = qt4-embedded_4.8.1.bb} |2 +-
.../{qt4-native_4.8.0.bb = qt4-native_4.8.1.bb} |4 ++--
meta/recipes-qt/qt4/qt4-tools-nativesdk_4.8.0.bb | 10 --
meta/recipes-qt/qt4/qt4-tools-nativesdk_4.8.1.bb | 10 ++
...qt4-x11-free_4.8.0.bb = qt4-x11-free_4.8.1.bb} |2 +-
16 files changed, 16 insertions(+), 16 deletions(-)
rename meta/recipes-qt/qt4/{qt-4.8.0.inc = qt-4.8.1.inc} (93%)
rename meta/recipes-qt/qt4/{qt-4.8.0 =
qt-4.8.1}/0001-Added-Openembedded-crossarch-option.patch (100%)
rename meta/recipes-qt/qt4/{qt-4.8.0 = qt-4.8.1}/configure-lflags.patch
(100%)
rename meta/recipes-qt/qt4/{qt-4.8.0 =
qt-4.8.1}/configure_oe_compiler.patch (100%)
rename meta/recipes-qt/qt4/{qt-4.8.0 = qt-4.8.1}/fix-translations.patch
(100%)
rename meta/recipes-qt/qt4/{qt-4.8.0 = qt-4.8.1}/g++.conf (100%)
rename meta/recipes-qt/qt4/{qt-4.8.0 = qt-4.8.1}/hack-out-pg2-4.7.0.patch
(100%)
rename meta/recipes-qt/qt4/{qt-4.8.0 = qt-4.8.1}/linux.conf (100%)
rename meta/recipes-qt/qt4/{qt-4.8.0 = qt-4.8.1}/pulseaudio-config.patch
(100%)
rename meta/recipes-qt/qt4/{qt-4.8.0 = qt-4.8.1}/qmake_cxx_eval.patch (100%)
rename meta/recipes-qt/qt4/{qt-4.8.0 = qt-4.8.1}/qmake_pri_fixes.patch
(100%)
rename meta/recipes-qt/qt4/{qt4-embedded_4.8.0.bb = qt4-embedded_4.8.1.bb}
(89%)
rename meta/recipes-qt/qt4/{qt4-native_4.8.0.bb = qt4-native_4.8.1.bb} (60%)
delete mode 100644 meta/recipes-qt/qt4/qt4-tools-nativesdk_4.8.0.bb
create mode 100644 meta/recipes-qt/qt4/qt4-tools-nativesdk_4.8.1.bb
rename meta/recipes-qt/qt4/{qt4-x11-free_4.8.0.bb = qt4-x11-free_4.8.1.bb}
(90%)
diff --git a/meta/recipes-qt/qt4/qt-4.8.0.inc b/meta/recipes-qt/qt4/qt-4.8.1.inc
similarity index 93%
rename from meta/recipes-qt/qt4/qt-4.8.0.inc
rename to meta/recipes-qt/qt4/qt-4.8.1.inc
index c0d90cd..cd78401 100644
--- a/meta/recipes-qt/qt4/qt-4.8.0.inc
+++ b/meta/recipes-qt/qt4/qt-4.8.1.inc
@@ -22,8 +22,8 @@ SRC_URI =
http://get.qt.nokia.com/qt/source/qt-everywhere-opensource-src-${PV}.
file://linux.conf \
-SRC_URI[md5sum] = e8a5fdbeba2927c948d9f477a6abe904
-SRC_URI[sha256sum] =
9392b74e485e15f75a3e07a527547d4f6747eaf55ebce71ba0e863a9fd320b6e
+SRC_URI[md5sum] = 7960ba8e18ca31f0c6e4895a312f92ff
+SRC_URI[sha256sum] =
ef851a36aa41b4ad7a3e4c96ca27eaed2a629a6d2fa06c20f072118caed87ae8
S = ${WORKDIR}/qt-everywhere-opensource-src-${PV}
diff --git
a/meta/recipes-qt/qt4/qt-4.8.0/0001-Added-Openembedded-crossarch-option.patch
b/meta/recipes-qt/qt4/qt-4.8.1/0001-Added-Openembedded-crossarch-option.patch
similarity index 100%
rename from
meta/recipes-qt/qt4/qt-4.8.0/0001-Added-Openembedded-crossarch-option.patch
rename to
meta/recipes-qt/qt4/qt-4.8.1/0001-Added-Openembedded-crossarch-option.patch
diff --git a/meta/recipes-qt/qt4/qt-4.8.0/configure-lflags.patch
b/meta/recipes-qt/qt4/qt-4.8.1/configure-lflags.patch
similarity index 100%
rename from meta/recipes-qt/qt4/qt-4.8.0/configure-lflags.patch
rename to meta/recipes-qt/qt4/qt-4.8.1/configure-lflags.patch
diff --git
[OE-core] [PATCH] libc-packgae.bbclass: Add i686 support in locale_arch_options
From: Noor Ahsan noor_ah...@mentor.com
* While building for i686 architectre an error was coming that
locale_arch_options does not have support for i686. Add missing support.
* Verified on intel architecture.
Signed-off-by: Noor Ahsan noor_ah...@mentor.com
---
meta/classes/libc-package.bbclass |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/meta/classes/libc-package.bbclass
b/meta/classes/libc-package.bbclass
index 4acf91a..957243d 100644
--- a/meta/classes/libc-package.bbclass
+++ b/meta/classes/libc-package.bbclass
@@ -271,6 +271,7 @@ python package_do_split_gconvs () {
mips: --uint32-align=4 --big-endian ,
\
mipsel: --uint32-align=4 --little-endian
, \
i586: --uint32-align=4 --little-endian
, \
+ i686: --uint32-align=4 --little-endian
, \
x86_64: --uint32-align=4 --little-endian
}
if target_arch in locale_arch_options:
--
1.7.9
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] qt4: move from 4.8.0 to 4.8.1
2012/3/29 Robert Yang liezhi.y...@windriver.com:
Hi Andreas,
I have one question about the qt-x11-free, is it possible to enable
the -sm -accessibility in oe-core, please? There is a meta-kde
layer which requires the -sm -accessibility, but they are disabled
in oe-core currently:
QT_DISTRO_FLAGS ?= -no-accessibility -no-sm
So there is a qt4-x11-free_4.8.0.bbappend in meta-kde, once the
the oe-core upgrade to 4.8.1, then the meta-kde has to uprade again.
I checked the log of the qt4, can't find the relative log for
-no-accessibility -no-sm.
If it is possible to enable them in oe-core, I'd like to send a patch for
them.
// Robert
On 03/29/2012 03:46 AM, Andreas Oberritter wrote:
* No changes other than source checksums and PR at recipe level.
* DEFAULT_PREFERENCE still set to -1
Signed-off-by: Andreas Oberrittero...@opendreambox.org
---
* Considering that OE-core is in a stabilization phase, updating
Qt may be a bad idea. However, version 4.8.0 has D_P=-1, so
4.7.4 still gets built by default.
* Even if this won't get applied now, other people might be
interested in testing this version and giving feedback.
* This recipe has been compile-tested on x86 and x86_64
for mips32el (qt4-native and qt4-embedded).
meta/recipes-qt/qt4/{qt-4.8.0.inc = qt-4.8.1.inc} | 4 ++--
.../0001-Added-Openembedded-crossarch-option.patch | 0
.../{qt-4.8.0 = qt-4.8.1}/configure-lflags.patch | 0
.../configure_oe_compiler.patch | 0
.../{qt-4.8.0 = qt-4.8.1}/fix-translations.patch | 0
.../recipes-qt/qt4/{qt-4.8.0 = qt-4.8.1}/g++.conf | 0
.../hack-out-pg2-4.7.0.patch | 0
.../qt4/{qt-4.8.0 = qt-4.8.1}/linux.conf | 0
.../{qt-4.8.0 = qt-4.8.1}/pulseaudio-config.patch | 0
.../{qt-4.8.0 = qt-4.8.1}/qmake_cxx_eval.patch | 0
.../{qt-4.8.0 = qt-4.8.1}/qmake_pri_fixes.patch | 0
...qt4-embedded_4.8.0.bb = qt4-embedded_4.8.1.bb} | 2 +-
.../{qt4-native_4.8.0.bb = qt4-native_4.8.1.bb} | 4 ++--
meta/recipes-qt/qt4/qt4-tools-nativesdk_4.8.0.bb | 10 --
meta/recipes-qt/qt4/qt4-tools-nativesdk_4.8.1.bb | 10 ++
...qt4-x11-free_4.8.0.bb = qt4-x11-free_4.8.1.bb} | 2 +-
16 files changed, 16 insertions(+), 16 deletions(-)
rename meta/recipes-qt/qt4/{qt-4.8.0.inc = qt-4.8.1.inc} (93%)
rename meta/recipes-qt/qt4/{qt-4.8.0 =
qt-4.8.1}/0001-Added-Openembedded-crossarch-option.patch (100%)
rename meta/recipes-qt/qt4/{qt-4.8.0 = qt-4.8.1}/configure-lflags.patch
(100%)
rename meta/recipes-qt/qt4/{qt-4.8.0 =
qt-4.8.1}/configure_oe_compiler.patch (100%)
rename meta/recipes-qt/qt4/{qt-4.8.0 = qt-4.8.1}/fix-translations.patch
(100%)
rename meta/recipes-qt/qt4/{qt-4.8.0 = qt-4.8.1}/g++.conf (100%)
rename meta/recipes-qt/qt4/{qt-4.8.0 =
qt-4.8.1}/hack-out-pg2-4.7.0.patch (100%)
rename meta/recipes-qt/qt4/{qt-4.8.0 = qt-4.8.1}/linux.conf (100%)
rename meta/recipes-qt/qt4/{qt-4.8.0 =
qt-4.8.1}/pulseaudio-config.patch (100%)
rename meta/recipes-qt/qt4/{qt-4.8.0 = qt-4.8.1}/qmake_cxx_eval.patch
(100%)
rename meta/recipes-qt/qt4/{qt-4.8.0 = qt-4.8.1}/qmake_pri_fixes.patch
(100%)
rename meta/recipes-qt/qt4/{qt4-embedded_4.8.0.bb =
qt4-embedded_4.8.1.bb} (89%)
rename meta/recipes-qt/qt4/{qt4-native_4.8.0.bb = qt4-native_4.8.1.bb}
(60%)
delete mode 100644 meta/recipes-qt/qt4/qt4-tools-nativesdk_4.8.0.bb
create mode 100644 meta/recipes-qt/qt4/qt4-tools-nativesdk_4.8.1.bb
rename meta/recipes-qt/qt4/{qt4-x11-free_4.8.0.bb =
qt4-x11-free_4.8.1.bb} (90%)
diff --git a/meta/recipes-qt/qt4/qt-4.8.0.inc
b/meta/recipes-qt/qt4/qt-4.8.1.inc
similarity index 93%
rename from meta/recipes-qt/qt4/qt-4.8.0.inc
rename to meta/recipes-qt/qt4/qt-4.8.1.inc
index c0d90cd..cd78401 100644
--- a/meta/recipes-qt/qt4/qt-4.8.0.inc
+++ b/meta/recipes-qt/qt4/qt-4.8.1.inc
@@ -22,8 +22,8 @@ SRC_URI =
http://get.qt.nokia.com/qt/source/qt-everywhere-opensource-src-${PV}.
file://linux.conf \
-SRC_URI[md5sum] = e8a5fdbeba2927c948d9f477a6abe904
-SRC_URI[sha256sum] =
9392b74e485e15f75a3e07a527547d4f6747eaf55ebce71ba0e863a9fd320b6e
+SRC_URI[md5sum] = 7960ba8e18ca31f0c6e4895a312f92ff
+SRC_URI[sha256sum] =
ef851a36aa41b4ad7a3e4c96ca27eaed2a629a6d2fa06c20f072118caed87ae8
S = ${WORKDIR}/qt-everywhere-opensource-src-${PV}
diff --git
a/meta/recipes-qt/qt4/qt-4.8.0/0001-Added-Openembedded-crossarch-option.patch
b/meta/recipes-qt/qt4/qt-4.8.1/0001-Added-Openembedded-crossarch-option.patch
similarity index 100%
rename from
meta/recipes-qt/qt4/qt-4.8.0/0001-Added-Openembedded-crossarch-option.patch
rename to
meta/recipes-qt/qt4/qt-4.8.1/0001-Added-Openembedded-crossarch-option.patch
diff --git a/meta/recipes-qt/qt4/qt-4.8.0/configure-lflags.patch
b/meta/recipes-qt/qt4/qt-4.8.1/configure-lflags.patch
similarity index 100%
rename from meta/recipes-qt/qt4/qt-4.8.0/configure-lflags.patch
rename to
[OE-core] [PATCH] docbook-utils-native: fix syntax problem in jw.in
Fix runtime error occurred e.g. with docbook-to-man calls:
grep: character class syntax is [[:space:]], not [:space:]
grep: character class syntax is [[:space:]], not [:space:]
jw: There is no frontend called /docbook/utils-0.6.14/frontends/docbook.
See also:
https://qa.mandriva.com/show_bug.cgi?id=61127
Signed-off-by: Steffen Sledz sl...@dresearch-fe.de
---
.../docbook-utils/docbook-utils-0.6.14/re.patch| 15 +++
.../docbook-utils/docbook-utils-native_0.6.14.bb |7 +--
2 files changed, 20 insertions(+), 2 deletions(-)
create mode 100644
meta/recipes-devtools/docbook-utils/docbook-utils-0.6.14/re.patch
diff --git a/meta/recipes-devtools/docbook-utils/docbook-utils-0.6.14/re.patch
b/meta/recipes-devtools/docbook-utils/docbook-utils-0.6.14/re.patch
new file mode 100644
index 000..1e53389
--- /dev/null
+++ b/meta/recipes-devtools/docbook-utils/docbook-utils-0.6.14/re.patch
@@ -0,0 +1,15 @@
+diff -Nurd docbook-utils-0.6.14-orig/bin/jw.in docbook-utils-0.6.14/bin/jw.in
+--- docbook-utils-0.6.14-orig/bin/jw.in2012-03-29 07:50:00.789564826
+0200
docbook-utils-0.6.14/bin/jw.in 2012-03-29 07:52:10.371302967 +0200
+@@ -80,9 +80,9 @@
+ SGML_CATALOGS_DIR=/etc/sgml
+ if [ -f $SGML_CONF ]
+ then
+- RE='^[:space:]*SGML_BASE_DIR[:space:]*=[:space:]*'
++ RE='^[[:space:]]*SGML_BASE_DIR[[:space:]]*=[[:space:]]*'
+ SGML_BASE_DIR=`grep $RE $SGML_CONF | sed s/$RE//`
+- RE='^[:space:]*SGML_CATALOGS_DIR[:space:]*=[:space:]*'
++ RE='^[[:space:]]*SGML_CATALOGS_DIR[[:space:]]*=[[:space:]]*'
+ SGML_CATALOGS_DIR=`grep $RE $SGML_CONF | sed s/$RE//`
+ fi
+
diff --git a/meta/recipes-devtools/docbook-utils/docbook-utils-native_0.6.14.bb
b/meta/recipes-devtools/docbook-utils/docbook-utils-native_0.6.14.bb
index c2ccef3..47a6167 100644
--- a/meta/recipes-devtools/docbook-utils/docbook-utils-native_0.6.14.bb
+++ b/meta/recipes-devtools/docbook-utils/docbook-utils-native_0.6.14.bb
@@ -7,9 +7,12 @@ LICENSE = GPLv2
LIC_FILES_CHKSUM = file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f
DEPENDS = openjade-native sgmlspl-native docbook-dsssl-stylesheets-native
docbook-sgml-dtd-3.1-native
-PR = r1
+PR = r2
-SRC_URI =
ftp://sources.redhat.com/pub/docbook-tools/new-trials/SOURCES/docbook-utils-${PV}.tar.gz;
+SRC_URI = \
+
ftp://sources.redhat.com/pub/docbook-tools/new-trials/SOURCES/docbook-utils-${PV}.tar.gz
\
+ file://re.patch \
+
SRC_URI[md5sum] = 6b41b18c365c01f225bc417cf632d81c
SRC_URI[sha256sum] =
48faab8ee8a7605c9342fb7b906e0815e3cee84a489182af38e8f7c0df2e92e9
--
1.7.7
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/6] self-hosted-image: pre-populate the builder user with poky source
Saul Wold wrote on 2012-03-29: On 03/28/2012 08:35 AM, Cui, Dexuan wrote: Hi Saul, Did you test bitbake core-image-minimal inside the vmware guest? I got the following ERROR immediately: Pseudo is not functioning correctly, which will cause failures I suspect in the guest, pseudo is not setup properly? This should be addressed by the 5/6 patch that adds the correct PSEUDO_* setup into the minix session script. I guess that you tried to run this on the command line and as you might notice I modified the bashrc, but for some reason that did not get picked up when the shell started up, I think we need to force the builder user to get /bin/bash as a shell not /bin/sh Hi Saul, I'm sorry -- this is actually a false alarm -- I didn't use the updated branch... With the latest poky master, bitbake in cmd line can work fine. Hob is automatically started and can work fine, too. 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 1/1] virtual/libgl: switch back to mesa-xlib for qemuarm/qemumips
On Thu, Mar 29, 2012 at 05:37:35AM +0200, Martin Jansa wrote: On Thu, Mar 29, 2012 at 09:31:28AM +0800, Zhai, Edwin wrote: On Wed, Mar 28, 2012 at 12:58:37PM +0200, Martin Jansa wrote: On Wed, Mar 28, 2012 at 06:10:26PM +0800, edwin.z...@intel.com wrote: From: Martin Jansa martin.ja...@gmail.com I don't think I've ever sent something like this. Actually I've sent patch: default-providers: switch virtual/libgl from mesa-xlib to mesa-dri * to match default virtual/xserver Yes, this is just a revert to fix the GL failure. Sorry, I don't notice that git keep the original author when you revert:( FWIW: It doesn't keep the original author here, but maybe you have different git.. Could you pls. explain why mesa-xlib doesn't match xserver-xorg? see: http://patches.openembedded.org/patch/13631/ I see. But this build failure should occur on qemux86 or other BSP, not qemuarm/qemumips/qemuppc, right? qemuarm/mips/ppc use xorg-kdrive instead. So can we add following to avoid wrong COMPATIBLE_MACHINE: PREFERRED_PROVIDER_virtual/libgl ?= mesa-xlib in meta/conf/machine/include/qemu.inc and PEFERRED_PROVIDER_virtual/libgl ?= mesa-dri in meta/conf/machine/qemux86.conf/qemux86-64.conf Thanks, Edwin Thanks, Edwin ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 5/9] archiver.bbclass: New bbclass for archiving sources, patches, logs and scripts
Thanks for your suggestion very much. I think I understand what you
said. The new patches will be pushed to OE-core this week according to
your suggestion.
On 2012年03月28日 05:27, Chris Larson wrote:
On Mon, Mar 26, 2012 at 7:24 PM, Xiaofeng Yan
xiaofeng@windriver.com wrote:
From: Xiaofeng Yanxiaofeng@windriver.com
1 Archive sources in ${S} in the different stage
(do_unpack,do_patch,do_configure).
2 Archive patches including series
3 Archive logs including scripts (.bb and .inc files)
4 dump environment resources which show all variable and functions
used to xxx.showdata.dump when running a task
5 dump all content in 's' including patches to file xxx.diff.gz
All archiving packages will be deployed to ${DEPLOY_DIR}/sources/
[YOCTO #1977]
Signed-off-by: Xiaofeng Yanxiaofeng@windriver.com
---
meta/classes/archiver.bbclass | 460 +
1 files changed, 460 insertions(+), 0 deletions(-)
create mode 100644 meta/classes/archiver.bbclass
diff --git a/meta/classes/archiver.bbclass b/meta/classes/archiver.bbclass
new file mode 100644
index 000..471430e
--- /dev/null
+++ b/meta/classes/archiver.bbclass
@@ -0,0 +1,460 @@
+# This file is used for archiving sources ,patches,and logs to tarball.
+# It also output building environment to xxx.dump.data and create xxx.diff.gz
to record
+# all content in ${S} to a diff file.
+
+EXCLUDE_FROM ?= .pc autom4te.cache
+ARCHIVE_TYPE ?= TAR SRPM
+DISTRO ?= poky
+PATCHES_ARCHIVE_WITH_SERIES = 'TRUE'
I'm a bit concerned about the variable names here. Perhaps we should
prefix them with ARCHIVER_? EXCLUDE_FROM is a bit generic.
+def parse_var(d,var):
+ ''' parse variable like ${PV} in require xxx_${PV}.inc to a real value. for example,
change require xxx_${PV}.inc to require xxx_1.2.inc '''
+ import re
+ pat = re.compile('.*\$({(.*)}).*')
+ if '$' not in var and '/' not in var:
+ return var
+ else:
+ if '/' in var:
+ return [i for i in var.split('/') if
i.endswith('.inc')][0]
+ elif '$' in var:
+ m = pat.match(var)
+ patstr = '\$' + m.group(1)
+ var_str = m.group(2)
+ return re.sub(patstr,d.getVar(var_str,True),var)
+ else:
+ return var
Why not using bb.data.expand(), which is designed for this? I see one
usage of parse_var here which has access to 'd', so I see no reason
not to use the standard mechanisms.
+def get_bb_inc(d):
+ '''create a directory script-logs including .bb and .inc file in
${WORKDIR}'''
+ import re
+ import os
+ import shutil
+
+ bbinc = []
+ pat=re.compile('require\s*([^\s]*\.*)(.*)')
+ file_dir = d.getVar('FILE', True)
+ bbdir = os.path.dirname(file_dir)
+ work_dir = d.getVar('WORKDIR', True)
+ os.chdir(work_dir)
I'd recommend against using chdir() unless there's no way around it.
I'd suggest working with the absolute paths instead.
+ bb.mkdirhier(script-logs)
+ os.chdir(bbdir)
+ bbfile = os.path.basename(file_dir)
+ bbinc.append(bbfile)
+
+ def get_inc (file):
+ f = open(file,'r')
+ for line in f.readlines():
+ if 'require' not in line:
+ bbinc.append(file)
+ else:
+ try:
+ incfile = pat.match(line).group(1)
+ incfile = parse_var(d,incfile)
+ bbinc.append(incfile)
+ get_inc(incfile)
+ except (IOError,AttributeError):
+ pass
+ get_inc(bbfile)
+ os.chdir(work_dir)
+ for root, dirs, files in os.walk(bbdir):
+ for file in bbinc:
+ if file in files:
+ shutil.copy(root + '/' + file,'script-logs')
+ oe.path.copytree('temp', 'script-logs')
+ return work_dir + '/script-logs'
+
+def get_all_patches(d):
+ '''copy patches and series file to a pointed directory which will be
archived to tarball in ${WORKDIR}'''
This claims to be working with a series file, but I don't see anything
here which does anything of the sort. Further, as you aren't
determining what is and is not a patch, this will capture more than
just patches, also config files, etc, which makes either the function
name or its implementation wrong, depending on which is correct.
+ import shutil
+
+ src_patches=[]
+ pf = d.getVar('PF', True)
+ work_dir = d.getVar('WORKDIR', True)
+ s = d.getVar('S',True)
+ dest = os.path.join(work_dir, pf + '-patches')
+ shutil.rmtree(dest, ignore_errors=True)
+ bb.mkdirhier(dest)
+
+
Re: [OE-core] [PATCH] qt4: move from 4.8.0 to 4.8.1
On Thu, Mar 29, 2012 at 03:51, Robert Yang liezhi.y...@windriver.com wrote: If it is possible to enable them in oe-core, I'd like to send a patch for them. If you're going to change it please do it in a separate patch to allow easy revertion of it if need and to easy identification of this change in SCM log -- 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] libc-packgae.bbclass: Add i686 support in locale_arch_options
Typo in commit log; please fix it and resend.
On Thu, Mar 29, 2012 at 03:48, Noor, Ahsan noor_ah...@mentor.com wrote:
From: Noor Ahsan noor_ah...@mentor.com
* While building for i686 architectre an error was coming that
locale_arch_options does not have support for i686. Add missing support.
* Verified on intel architecture.
Signed-off-by: Noor Ahsan noor_ah...@mentor.com
---
meta/classes/libc-package.bbclass | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/meta/classes/libc-package.bbclass
b/meta/classes/libc-package.bbclass
index 4acf91a..957243d 100644
--- a/meta/classes/libc-package.bbclass
+++ b/meta/classes/libc-package.bbclass
@@ -271,6 +271,7 @@ python package_do_split_gconvs () {
mips: --uint32-align=4 --big-endian ,
\
mipsel: --uint32-align=4 --little-endian
, \
i586: --uint32-align=4 --little-endian
, \
+ i686: --uint32-align=4 --little-endian
, \
x86_64: --uint32-align=4 --little-endian
}
if target_arch in locale_arch_options:
--
1.7.9
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
--
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] opkg-make-index cache failing
On Tue, Nov 29, 2011 at 12:40:52PM +0100, Martin Jansa wrote:
On Fri, Nov 25, 2011 at 08:59:06PM +0100, Koen Kooi wrote:
Op 25 nov. 2011, om 19:15 heeft Koen Kooi het volgende geschreven:
Op 25 nov. 2011, om 17:53 heeft Richard Purdie het volgende geschreven:
On Fri, 2011-11-25 at 16:38 +0100, Koen Kooi wrote:
In OE-classic the opkg-make-index cache was working pretty well,
do_rootfs only spent a few seconds doing opkg-make-index on
incremental builds. In the OE-core world the situation is different,
opkg-make-index will reindex every package on each do_rootfs run, so
after a while building images starts taking *really* long, on my
systemd (work/ on ssd, deploy on rotating media) it now takes
±7minutes just do refresh the opkg indices.
Since I can't blame sstate for this I suspect that pseudo gets in the
way of the naive caching logic. Is there a simple way to turn off
pseudo when running opkg-make-index?
With a relatively small deploy:
real 6m14.611s
user 2m45.909s
sys 0m43.674s
You could try:
PSEUDO_DISABLED=1 opkg-make-index
real 5m25.920s
user 2m41.279s
sys 0m41.681s
or even
PSEUDO_UNLOAD=1 opkg-make-index
real 5m5.699s
user 2m37.283s
sys 0m37.508s
Now I need to double check to see if the patches are really having
effect on the opkg caching instead of just not having pseudo overhead.
Retesting without PSEUDO changes:
real5m18.412s
user2m40.736s
sys 0m41.374s
So the PSEUDO changes don't seem to do much :(
I can confirm this change here too:
OE om-gta02@shr ~/shr-core $ time /usr/bin/python2.7 \
/OE/shr-core/tmp/sysroots/x86_64-linux/usr/bin/opkg-make-index \
-r /OE/shr-core/tmp/deploy/ipk/armv4t/Packages \
-p /OE/shr-core/tmp/deploy/ipk/armv4t/Packages \
-l /OE/shr-core/tmp/deploy/ipk/armv4t/Packages.filelist \
-m /OE/shr-core/tmp/deploy/ipk/armv4t/
real11m47.949s
user4m13.848s
sys 0m17.917s
It hurts even more when someone is building ie for spitz and
linux-kexecboot depends on initramfs image which calls another
opkg-make-index with every image build.
If I replace opkg-make-index from oe-core with old oe-classic version, I
get a lot of messages like:
Lost field license, MIT-X
but the time is similar
real10m23.953s
user4m10.940s
sys 0m15.833s
And if I do the same completely in shr-unstable (based on OE-classic)
OE om-gta02@shr ~/shr-unstable $ time /usr/bin/python2.7 \
/OE/shr-unstable/tmp/sysroots/x86_64-linux/usr/bin/opkg-make-index \
-r /OE/shr-unstable/tmp/deploy/ipk/armv4t/Packages \
-p /OE/shr-unstable/tmp/deploy/ipk/armv4t/Packages \
-l /OE/shr-unstable/tmp/deploy/ipk/armv4t/Packages.filelist \
-m /OE/shr-unstable/tmp/deploy/ipk/armv4t/
real0m6.469s
user0m6.056s
sys 0m0.400s
Another difference seems to be in Packages.filelist which were empty in
OE-classic:
OE om-gta02@shr ~/shr-core $ find tmp/deploy/ipk/ -name Packages.filelist
-exec wc -l {} \;
1173 tmp/deploy/ipk/palmpre2/Packages.filelist
1254 tmp/deploy/ipk/palmpre/Packages.filelist
107346 tmp/deploy/ipk/armv4t/Packages.filelist
110557 tmp/deploy/ipk/armv7a-vfp-neon/Packages.filelist
0 tmp/deploy/ipk/Packages.filelist
1365 tmp/deploy/ipk/nokia900/Packages.filelist
812 tmp/deploy/ipk/all/Packages.filelist
1643 tmp/deploy/ipk/om_gta02/Packages.filelist
OE om-gta02@shr ~/shr-core $ cd ../shr-unstable/
OE om-gta02@shr ~/shr-unstable $ find tmp/deploy/ipk/ -name Packages.filelist
-exec wc -l {} \;
0 tmp/deploy/ipk/armv7a/Packages.filelist
0 tmp/deploy/ipk/om-gta01/Packages.filelist
0 tmp/deploy/ipk/om-gta02/Packages.filelist
0 tmp/deploy/ipk/palmpre2/Packages.filelist
0 tmp/deploy/ipk/armv6/Packages.filelist
0 tmp/deploy/ipk/palmpre/Packages.filelist
0 tmp/deploy/ipk/armv4t/Packages.filelist
0 tmp/deploy/ipk/armv4/Packages.filelist
0 tmp/deploy/ipk/armv6-novfp/Packages.filelist
0 tmp/deploy/ipk/Packages.filelist
0 tmp/deploy/ipk/htcdream/Packages.filelist
0 tmp/deploy/ipk/nokia900/Packages.filelist
0 tmp/deploy/ipk/all/Packages.filelist
0 tmp/deploy/ipk/armv7/Packages.filelist
But that's not the cause, because even without Packages.filelist
generation it takes about 3 min (better but it still writes info for
every package).
Weird is that there is only small diff between new and old
opkg.py/opkg-make-index
--- /OE/shr-unstable/tmp/sysroots/x86_64-linux/usr/bin/opkg.py 2011-05-27
18:35:03.0 +0200
+++ /OE/shr-core/tmp/sysroots/x86_64-linux/usr/bin/opkg.py 2011-09-01
16:36:35.0 +0200
@@ -145,6 +145,7 @@
self.priority = None
self.tags = None
self.fn = fn
+self.license = None
if fn:
# see if it is deb format
@@ -319,6 +320,12 @@
def get_section(self, section):
return self.section
+def
[OE-core] why use both IMAGE_FEATURES and EXTRA_IMAGE_FEATURES in a single .bb file?
given the recent excitement over += and =+, i thought i'd point
out again the occasional weirdness like this snippet from
core-image-sato-sdk.bb:
IMAGE_FEATURES += apps-console-core ${SATO_IMAGE_FEATURES} dev-pkgs tools-sdk
qt4-pkgs
EXTRA_IMAGE_FEATURES += tools-debug tools-profile tools-testapps debug-tweaks
that just seems ... odd.
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
Re: [OE-core] [PATCH] qt4: move from 4.8.0 to 4.8.1
On 03/29/2012 03:00 PM, Samuel Stirtzel wrote: 2012/3/29 Robert Yangliezhi.y...@windriver.com: Hi Andreas, I have one question about the qt-x11-free, is it possible to enable the -sm -accessibility in oe-core, please? There is a meta-kde layer which requires the -sm -accessibility, but they are disabled in oe-core currently: QT_DISTRO_FLAGS ?= -no-accessibility -no-sm So there is a qt4-x11-free_4.8.0.bbappend in meta-kde, once the the oe-core upgrade to 4.8.1, then the meta-kde has to uprade again. I checked the log of the qt4, can't find the relative log for -no-accessibility -no-sm. If it is possible to enable them in oe-core, I'd like to send a patch for them. // Robert On 03/29/2012 03:46 AM, Andreas Oberritter wrote: Hi Robert, this question was already discussed before (see [1]), but then I came up with the .bbappend (as I had to change other things too). If you still wand to send a patch to the qt4.inc, it should be no problem as the previous thread had no negative feedback. Cool, I will send a separate patch after enough testing. Enable both -sm and -accessibility. // Robert [1] http://lists.linuxtogo.org/pipermail/openembedded-core/2012-February/017792.html ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] why use both IMAGE_FEATURES and EXTRA_IMAGE_FEATURES in a single .bb file?
On Thu, Mar 29, 2012 at 04:11:57AM -0400, Robert P. J. Day wrote:
given the recent excitement over += and =+, i thought i'd point
out again the occasional weirdness like this snippet from
core-image-sato-sdk.bb:
IMAGE_FEATURES += apps-console-core ${SATO_IMAGE_FEATURES} dev-pkgs
tools-sdk qt4-pkgs
EXTRA_IMAGE_FEATURES += tools-debug tools-profile tools-testapps
debug-tweaks
sometimes this is usefull to define base in IMAGE_FEATURES and then
stuff which people tend to override in .bbappend put in EXTRA_IMAGE_FEATURES
Maybe that's not the case here.. but separate variables are good even if
it looks weird in .bb alone
FOO = blah
BAR = base ${FOO}
allows to remove/replace blah very easy with .bbappend.
Cheers,
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] opkg-make-index cache failing
On Thu, 2012-03-29 at 09:58 +0200, Martin Jansa wrote:
Today I did some more tests and started using simple bash script to
reindex all Packages files just once (instead of rebuilding common arch
many times with bitbake package-index).
OPKG_MAKE_INDEX=~/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/opkg-make-index
DEPLOY_IPK=~/shr-core/tmp-eglibc/deploy/ipk/
for PACKAGE_FILE in `find ${DEPLOY_IPK} -name Packages`; do
PACKAGE_DIR=`dirname ${PACKAGE_FILE}`
touch ${PACKAGE_FILE}
echo Regenerating ${PACKAGE_FILE}
time flock ${PACKAGE_FILE}.flock -c ${OPKG_MAKE_INDEX} -r ${PACKAGE_FILE}
-p ${PACKAGE_FILE} -l ${PACKAGE_FILE}.filelist -m ${PACKAGE_DIR}/
done
And on my machine it takes really long to finish
real26m40.108s
user23m6.673s
sys 0m14.464s
So I'll look into opkg-make-index changes again and to make it easier I would
like
to move all oe-core local patches:
http://git.openembedded.org/openembedded-core/tree/meta/recipes-devtools/opkg-utils/opkg-utils
to yocto git repo:
http://git.yoctoproject.org/cgit/cgit.cgi/opkg-utils/
should I send pull-request for opkg-utils repo here or somewhere else? e.g.
yocto ML?
I've been advising people to do that kind of thing on the Yocto mailing
list since there is already lots of patch traffic on OE-Core...
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] why use both IMAGE_FEATURES and EXTRA_IMAGE_FEATURES in a single .bb file?
On Thu, 29 Mar 2012, Martin Jansa wrote:
On Thu, Mar 29, 2012 at 04:11:57AM -0400, Robert P. J. Day wrote:
given the recent excitement over += and =+, i thought i'd point
out again the occasional weirdness like this snippet from
core-image-sato-sdk.bb:
IMAGE_FEATURES += apps-console-core ${SATO_IMAGE_FEATURES} dev-pkgs
tools-sdk qt4-pkgs
EXTRA_IMAGE_FEATURES += tools-debug tools-profile tools-testapps
debug-tweaks
sometimes this is usefull to define base in IMAGE_FEATURES and then
stuff which people tend to override in .bbappend put in EXTRA_IMAGE_FEATURES
Maybe that's not the case here.. but separate variables are good even if
it looks weird in .bb alone
FOO = blah
BAR = base ${FOO}
allows to remove/replace blah very easy with .bbappend.
ok, i can see that. but that's the sort of thing that should be
explained somewhere in the basic OE documentation so users understand
what it means when they run across it.
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
Re: [OE-core] [PATCH] bc: use update-alternatives to make dc play nice with busybox
On Wed, 2012-03-28 at 19:35 -0400, Denys Dmytriyenko wrote:
On Wed, Mar 28, 2012 at 09:38:04AM +0100, Richard Purdie wrote:
On Wed, 2012-03-28 at 02:11 -0400, Denys Dmytriyenko wrote:
-inherit autotools
+do_install_append () {
+ mv ${D}${bindir}/dc ${D}${bindir}/dc.${PN}
+}
+
+inherit autotools update-alternatives
+
+ALTERNATIVE_NAME = dc
+ALTERNATIVE_LINK = ${bindir}/dc
+ALTERNATIVE_PATH = ${bindir}/dc.${PN}
+ALTERNATIVE_PRIORITY = 100
I think you should just be able to do:
ALTERNATIVE_LINKS = ${bindir}/dc
ALTERNATIVE_PRIORITY = 100
inherit autotools update-alternatives
Yes, quite right. I see plenty of other recipes do it the hard way though...
All the more reason to get some better examples out there! :)
Thanks for resending.
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] qemu.inc: Use '=' for IMAGE_FSTYPES
On Wed, 2012-03-28 at 16:29 -0700, Tom Rini wrote: On Wed, Mar 28, 2012 at 10:11:44PM +0100, Richard Purdie wrote: On Wed, 2012-03-28 at 14:54 -0400, Denys Dmytriyenko wrote: On Mon, Mar 26, 2012 at 05:56:16PM +0100, Richard Purdie wrote: On Mon, 2012-03-26 at 09:25 -0700, Tom Rini wrote: So, what is the subtle difference between += that we started with and =+ that you recommended at the end? I realize those are for append and prepend, but are they handled any different? Was your recommendation to use =+ at the end, instead of += that was used originally, based on some specifics? Thanks. I'm using += and =+ interchangeably. The contrast was with ?= which I argued against. Order in this case doesn't matter and I have no preference over += or =+, it simply doesn't matter. So I guess I'll spin everything one more time and drop the meta-intel version and we'll just use += since that's the common one. Sounds good. Sorry about the churn on this one, I thought it was clear += and =+ were equivalent in this context. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][PATCH 2/2] kernel.bbclass: unify white spaces
On Thu, 2012-03-29 at 08:24 +0200, Martin Jansa wrote: * indentation was with spaces and tabs, unify to use tabs instead of spaces, because python populate_packages expects tabs (or 8 spaces) and we're doing populate_packages_preppend here Signed-off-by: Martin Jansa martin.ja...@gmail.com --- meta/classes/kernel.bbclass | 38 +++--- 1 files changed, 19 insertions(+), 19 deletions(-) FWIW, we're supposed to be using tabs for shell code and spaces (4) for python. Unfortunately populate_package() is special due to the number of places we append/prepend it and the need to be consistent with whitespace. I'm therefore not sure it makes sense to re-indent the anonymous python. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Problem with perl upstream link
On Wed, 2012-03-28 at 21:02 +0300, Andrei Gherzan wrote: From time to time my build crashes after trying to unpack the downloaded perl package: Check the log here: ERROR: Logfile of failure stored in: BUILD/tmp-eglibc-eglibc/work/i686-linux/perl-native-5.14.2-r0/temp/log.do_unpack.14775 Log data follows: | NOTE: Unpacking BUILD/tmp-eglibc-eglibc/work/i686-linux/perl-native-5.14.2-r0/ | | gzip: stdin: invalid compressed data--crc error | tar: Child returned status 1 | tar: Error is not recoverable: exiting now | ERROR: Function failed: Unpack failure for URL: 'http://www.cpan.org/src/5.0/perl-5.14.2.tar.gz'. Unpack command PATH=... tar xz --no-same-owner -f DOWNLOADS/perl-5.14.2.tar.gz failed with return value 2 NOTE: package perl-native-5.14.2-r0: task do_unpack: Failed To check the remote i did a simple test: wget http://www.cpan.org/src/5.0/perl-5.14.2.tar.gz --2012-03-28 21:09:11-- http://www.cpan.org/src/5.0/perl-5.14.2.tar.gz Resolving www.cpan.org... 207.171.7.177, 199.15.176.140, 2620:101:d000:8::140:1, ... Connecting to www.cpan.org|207.171.7.177|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 15223598 (15M) [application/octet-stream] Saving to: `perl-5.14.2.tar.gz' 100%[===] 15,223,598 1.07M/s in 99s 2012-03-28 21:10:52 (151 KB/s) - `perl-5.14.2.tar.gz' saved [15223598/15223598] tar xz --no-same-owner -f /media/HDD-WRS/yocto/2012-03-28-18-49-yocto-ve/../downloads/perl-5.14.2.tar.gz gzip: stdin: invalid compressed data--crc error tar: Child returned status 1 tar: Exiting with failure status due to previous errors Anybody knows about this issue? I tried the above and it seems to be ok for me. Several things come to mind: a) Is the checksum of the file ok? b) what versions of tar and gzip do you have? If the checksum is ok, I suspect the problem is in b). We do have some workarounds in the system to deal with broken versions of tar and gzip. You'd have to see the logs to see which versions were problematic. We do usually avoid problems but there was recently a regression in that code which was subsequently fixed which might have exposed you to this. If the checksum is not ok, I'd have to wonder why the fetch didn't fail with a bad checksum. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] Fetching code via git over ssh.
Hi, as I have set up a git server on one of my PCs and secured it with ssh. I tried to use the repository in a recipe, cloning via git clone ssh://user@server/~/repo.git works. But bitbake tries to fetch the repository via scp instead of git (also if I add protocol=git). Tried something like this in my recipe: SRC_URI = ssh://user@server/~/repo.git;protocol=git;branch=master (note: the git repository is in the home directory of the user, so the tilde is not causing an error) Anyone else tried to fetch a repository on a ssh secured git server via bitbake? -- Regards Samuel ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][PATCH 2/2] kernel.bbclass: unify white spaces
On Thu, Mar 29, 2012 at 11:05:47AM +0100, Richard Purdie wrote: On Thu, 2012-03-29 at 08:24 +0200, Martin Jansa wrote: * indentation was with spaces and tabs, unify to use tabs instead of spaces, because python populate_packages expects tabs (or 8 spaces) and we're doing populate_packages_preppend here Signed-off-by: Martin Jansa martin.ja...@gmail.com --- meta/classes/kernel.bbclass | 38 +++--- 1 files changed, 19 insertions(+), 19 deletions(-) FWIW, we're supposed to be using tabs for shell code and spaces (4) for python. Unfortunately populate_package() is special due to the number of places we append/prepend it and the need to be consistent with whitespace. I'm therefore not sure it makes sense to re-indent the anonymous python. Agreed, but that anonymous python used spaces and tabs in the same function which is ugly. Cheers, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] Python egg-info/pth
Hi,
many python packages install egg-info files or directories and/or pth
files inside the site-packages directory.
AFAICT, egg-info is used to provide multiple versions of python
site packages, if required, if no package manager like opkg is
involved. Since this is not the case in OE, it only serves as a way
for python programs to depend on specific versions of a python site
package. This doesn't make much sense, because package version
dependencies should already be handled by opkg (or rpm or deb).
So I'd like to understand whether it's useful to ship them at all or
to package them separately. For example, python-twisted installs the
following files:
WARNING: /usr/lib/python2.7/site-packages/Twisted-12.0.0-py2.7.egg-info
WARNING:
/usr/lib/python2.7/site-packages/Twisted-12.0.0-py2.7.egg-info/top_level.txt
WARNING:
/usr/lib/python2.7/site-packages/Twisted-12.0.0-py2.7.egg-info/requires.txt
WARNING:
/usr/lib/python2.7/site-packages/Twisted-12.0.0-py2.7.egg-info/SOURCES.txt
WARNING:
/usr/lib/python2.7/site-packages/Twisted-12.0.0-py2.7.egg-info/PKG-INFO
WARNING:
/usr/lib/python2.7/site-packages/Twisted-12.0.0-py2.7.egg-info/dependency_links.txt
WARNING:
/usr/lib/python2.7/site-packages/Twisted-12.0.0-py2.7.egg-info/not-zip-safe
Twisted gets split into many sub-packages and an empty meta package.
If the egg-info gets packaged into the meta package, it wouldn't be
available if someone just installed twisted-web, for example.
Long story short: I don't see how egg-info can be useful in OE. How
about removing egg-info in setuptools.bbclass or moving it to ${PN}-metadata
for all python packages?
How about pth files? Are they meaningful in an OE environment?
Regards,
Andreas
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Fetching code via git over ssh.
On 29.03.2012 14:13, Samuel Stirtzel wrote: Hi, as I have set up a git server on one of my PCs and secured it with ssh. I tried to use the repository in a recipe, cloning via git clone ssh://user@server/~/repo.git works. But bitbake tries to fetch the repository via scp instead of git (also if I add protocol=git). Tried something like this in my recipe: SRC_URI = ssh://user@server/~/repo.git;protocol=git;branch=master (note: the git repository is in the home directory of the user, so the tilde is not causing an error) Anyone else tried to fetch a repository on a ssh secured git server via bitbake? Use git://user@server/path;protocol=ssh ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][PATCH 1/2] kernel.bbclass: merge uboot_mkimage improvements from meta-oe
On Thu, Mar 29, 2012 at 2:24 AM, Martin Jansa martin.ja...@gmail.com wrote:
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
meta/classes/kernel.bbclass | 39 +++
1 files changed, 23 insertions(+), 16 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 3519e7c..8cd5fc7 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -502,32 +502,39 @@ do_sizecheck() {
addtask sizecheck before do_install after do_compile
-KERNEL_IMAGE_BASE_NAME ?=
${KERNEL_IMAGETYPE}-${PV}-${PR}-${MACHINE}-${DATETIME}
-# Don't include the DATETIME variable in the sstate package signatures
-KERNEL_IMAGE_BASE_NAME[vardepsexclude] = DATETIME
-KERNEL_IMAGE_SYMLINK_NAME ?= ${KERNEL_IMAGETYPE}-${MACHINE}
-
-kernel_do_deploy() {
- install -m 0644 ${KERNEL_OUTPUT}
${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
- if (grep -q -i -e '^CONFIG_MODULES=y$' .config); then
- tar -cvzf
${DEPLOYDIR}/modules-${KERNEL_VERSION}-${PR}-${MACHINE}.tgz -C ${D} lib
- fi
-
+do_uboot_mkimage() {
if test x${KERNEL_IMAGETYPE} = xuImage ; then
- if test -e arch/${ARCH}/boot/uImage ; then
- cp arch/${ARCH}/boot/uImage
${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
We continually try and remove this, but it is a valid use case where some
people do want the kernel's uImage to be used and not regenerate it outside
of the kernel build process.
The last time this was discussed, it concluded that rather than making this
a simple test, we should do it via a flag .. and I'm still of the
opinion that would
be the right approach here. There's no reason to break either use case.
Cheers,
Bruce
- elif test -e arch/${ARCH}/boot/compressed/vmlinux ; then
+ ENTRYPOINT=${UBOOT_ENTRYPOINT}
+ if test -n ${UBOOT_ENTRYSYMBOL}; then
+ ENTRYPOINT=`${HOST_PREFIX}nm ${S}/vmlinux | \
+ awk '$3==${UBOOT_ENTRYSYMBOL} {print $1}'`
+ fi
+ if test -e arch/${ARCH}/boot/compressed/vmlinux ; then
${OBJCOPY} -O binary -R .note -R .comment -S
arch/${ARCH}/boot/compressed/vmlinux linux.bin
- uboot-mkimage -A ${ARCH} -O linux -T kernel -C none
-a ${UBOOT_ENTRYPOINT} -e ${UBOOT_ENTRYPOINT} -n
${DISTRO_NAME}/${PV}/${MACHINE} -d linux.bin
${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
+ uboot-mkimage -A ${UBOOT_ARCH} -O linux -T kernel -C
none -a ${UBOOT_LOADADDRESS} -e $ENTRYPOINT -n
${DISTRO_NAME}/${PV}/${MACHINE} -d linux.bin arch/${ARCH}/boot/uImage
rm -f linux.bin
else
${OBJCOPY} -O binary -R .note -R .comment -S vmlinux
linux.bin
rm -f linux.bin.gz
gzip -9 linux.bin
- uboot-mkimage -A ${ARCH} -O linux -T kernel -C gzip
-a ${UBOOT_ENTRYPOINT} -e ${UBOOT_ENTRYPOINT} -n
${DISTRO_NAME}/${PV}/${MACHINE} -d linux.bin.gz
${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
+ uboot-mkimage -A ${UBOOT_ARCH} -O linux -T kernel -C
gzip -a ${UBOOT_LOADADDRESS} -e $ENTRYPOINT -n
${DISTRO_NAME}/${PV}/${MACHINE} -d linux.bin.gz arch/${ARCH}/boot/uImage
rm -f linux.bin.gz
fi
fi
+}
+
+addtask uboot_mkimage before do_install after do_compile
+
+KERNEL_IMAGE_BASE_NAME ?=
${KERNEL_IMAGETYPE}-${PV}-${PR}-${MACHINE}-${DATETIME}
+# Don't include the DATETIME variable in the sstate package signatures
+KERNEL_IMAGE_BASE_NAME[vardepsexclude] = DATETIME
+KERNEL_IMAGE_SYMLINK_NAME ?= ${KERNEL_IMAGETYPE}-${MACHINE}
+
+kernel_do_deploy() {
+ install -m 0644 ${KERNEL_OUTPUT}
${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
+ if (grep -q -i -e '^CONFIG_MODULES=y$' .config); then
+ tar -cvzf
${DEPLOYDIR}/modules-${KERNEL_VERSION}-${PR}-${MACHINE}.tgz -C ${D} lib
+ fi
cd ${DEPLOYDIR}
rm -f ${KERNEL_IMAGE_SYMLINK_NAME}.bin
--
1.7.8.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
--
Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][PATCH 2/2] kernel.bbclass: unify white spaces
On Thu, 2012-03-29 at 14:16 +0200, Martin Jansa wrote: On Thu, Mar 29, 2012 at 11:05:47AM +0100, Richard Purdie wrote: On Thu, 2012-03-29 at 08:24 +0200, Martin Jansa wrote: * indentation was with spaces and tabs, unify to use tabs instead of spaces, because python populate_packages expects tabs (or 8 spaces) and we're doing populate_packages_preppend here Signed-off-by: Martin Jansa martin.ja...@gmail.com --- meta/classes/kernel.bbclass | 38 +++--- 1 files changed, 19 insertions(+), 19 deletions(-) FWIW, we're supposed to be using tabs for shell code and spaces (4) for python. Unfortunately populate_package() is special due to the number of places we append/prepend it and the need to be consistent with whitespace. I'm therefore not sure it makes sense to re-indent the anonymous python. Agreed, but that anonymous python used spaces and tabs in the same function which is ugly. I'm fine with cleaning that up but lets continue to use tabs for shell and spaces for python where at all possible, then we're consistent :) Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Fetching code via git over ssh.
2012/3/29 Andreas Oberritter o...@opendreambox.org: On 29.03.2012 14:13, Samuel Stirtzel wrote: Hi, as I have set up a git server on one of my PCs and secured it with ssh. I tried to use the repository in a recipe, cloning via git clone ssh://user@server/~/repo.git works. But bitbake tries to fetch the repository via scp instead of git (also if I add protocol=git). Tried something like this in my recipe: SRC_URI = ssh://user@server/~/repo.git;protocol=git;branch=master (note: the git repository is in the home directory of the user, so the tilde is not causing an error) Anyone else tried to fetch a repository on a ssh secured git server via bitbake? Use git://user@server/path;protocol=ssh Thanks it works. -- Regards Samuel ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [oe-core][PATCHv2 1/2] kernel.bbclass: merge uboot_mkimage improvements from meta-oe
* allows to detect ENTRYPOINT from kernel binary marked with UBOOT_ENTRYSYMBOL
used e.g. by ben-nanonote
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
meta/classes/kernel.bbclass | 41 +
1 files changed, 25 insertions(+), 16 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 3519e7c..0ae9bed 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -507,28 +507,37 @@ KERNEL_IMAGE_BASE_NAME ?=
${KERNEL_IMAGETYPE}-${PV}-${PR}-${MACHINE}-${DATETIME
KERNEL_IMAGE_BASE_NAME[vardepsexclude] = DATETIME
KERNEL_IMAGE_SYMLINK_NAME ?= ${KERNEL_IMAGETYPE}-${MACHINE}
+do_uboot_mkimage() {
+ if test x${KERNEL_IMAGETYPE} = xuImage ; then
+ if test ! -e arch/${ARCH}/boot/uImage ; then
+ ENTRYPOINT=${UBOOT_ENTRYPOINT}
+ if test -n ${UBOOT_ENTRYSYMBOL}; then
+ ENTRYPOINT=`${HOST_PREFIX}nm ${S}/vmlinux | \
+ awk '$3==${UBOOT_ENTRYSYMBOL} {print
$1}'`
+ fi
+ if test -e arch/${ARCH}/boot/compressed/vmlinux ; then
+ ${OBJCOPY} -O binary -R .note -R .comment -S
arch/${ARCH}/boot/compressed/vmlinux linux.bin
+ uboot-mkimage -A ${UBOOT_ARCH} -O linux -T
kernel -C none -a ${UBOOT_LOADADDRESS} -e $ENTRYPOINT -n
${DISTRO_NAME}/${PV}/${MACHINE} -d linux.bin arch/${ARCH}/boot/uImage
+ rm -f linux.bin
+ else
+ ${OBJCOPY} -O binary -R .note -R .comment -S
vmlinux linux.bin
+ rm -f linux.bin.gz
+ gzip -9 linux.bin
+ uboot-mkimage -A ${UBOOT_ARCH} -O linux -T
kernel -C gzip -a ${UBOOT_LOADADDRESS} -e $ENTRYPOINT -n
${DISTRO_NAME}/${PV}/${MACHINE} -d linux.bin.gz arch/${ARCH}/boot/uImage
+ rm -f linux.bin.gz
+ fi
+ fi
+ fi
+}
+
+addtask uboot_mkimage before do_install after do_compile
+
kernel_do_deploy() {
install -m 0644 ${KERNEL_OUTPUT}
${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
if (grep -q -i -e '^CONFIG_MODULES=y$' .config); then
tar -cvzf
${DEPLOYDIR}/modules-${KERNEL_VERSION}-${PR}-${MACHINE}.tgz -C ${D} lib
fi
- if test x${KERNEL_IMAGETYPE} = xuImage ; then
- if test -e arch/${ARCH}/boot/uImage ; then
- cp arch/${ARCH}/boot/uImage
${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
- elif test -e arch/${ARCH}/boot/compressed/vmlinux ; then
- ${OBJCOPY} -O binary -R .note -R .comment -S
arch/${ARCH}/boot/compressed/vmlinux linux.bin
- uboot-mkimage -A ${ARCH} -O linux -T kernel -C none -a
${UBOOT_ENTRYPOINT} -e ${UBOOT_ENTRYPOINT} -n ${DISTRO_NAME}/${PV}/${MACHINE}
-d linux.bin ${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
- rm -f linux.bin
- else
- ${OBJCOPY} -O binary -R .note -R .comment -S vmlinux
linux.bin
- rm -f linux.bin.gz
- gzip -9 linux.bin
- uboot-mkimage -A ${ARCH} -O linux -T kernel -C gzip -a
${UBOOT_ENTRYPOINT} -e ${UBOOT_ENTRYPOINT} -n ${DISTRO_NAME}/${PV}/${MACHINE}
-d linux.bin.gz ${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
- rm -f linux.bin.gz
- fi
- fi
-
cd ${DEPLOYDIR}
rm -f ${KERNEL_IMAGE_SYMLINK_NAME}.bin
ln -sf ${KERNEL_IMAGE_BASE_NAME}.bin ${KERNEL_IMAGE_SYMLINK_NAME}.bin
--
1.7.8.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [oe-core][PATCHv2 2/2] kernel.bbclass: unify white spaces
* indentation was with spaces and tabs, unify to use tabs instead of
spaces, for shell code and populate_packages_preppend,
because python populate_packages expects tabs (or 8 spaces)
* and use 4 spaces for anonymous python
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
meta/classes/kernel.bbclass | 26 +-
1 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 0ae9bed..cf060c6 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -13,9 +13,9 @@ INITRAMFS_TASK ?=
python __anonymous () {
kerneltype = d.getVar('KERNEL_IMAGETYPE', True) or ''
if kerneltype == 'uImage':
- depends = d.getVar(DEPENDS, True)
- depends = %s u-boot-mkimage-native % depends
- d.setVar(DEPENDS, depends)
+depends = d.getVar(DEPENDS, True)
+depends = %s u-boot-mkimage-native % depends
+d.setVar(DEPENDS, depends)
image = d.getVar('INITRAMFS_IMAGE', True)
if image:
@@ -91,7 +91,7 @@ kernel_do_compile() {
do_compile_kernelmodules() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
if (grep -q -i -e '^CONFIG_MODULES=y$' .config); then
- oe_runmake ${PARALLEL_MAKE} modules CC=${KERNEL_CC}
LD=${KERNEL_LD}
+ oe_runmake ${PARALLEL_MAKE} modules CC=${KERNEL_CC}
LD=${KERNEL_LD}
else
bbnote no modules to compile
fi
@@ -115,7 +115,7 @@ kernel_do_install() {
#
# Install various kernel output (zImage, map file, config, module
support files)
- #
+ #
install -d ${D}/${KERNEL_IMAGEDEST}
install -d ${D}/boot
install -m 0644 ${KERNEL_OUTPUT}
${D}/${KERNEL_IMAGEDEST}/${KERNEL_IMAGETYPE}-${KERNEL_VERSION}
@@ -188,7 +188,7 @@ kernel_do_install() {
bin_files=arch/powerpc/boot/addnote arch/powerpc/boot/hack-coff \
arch/powerpc/boot/mktree
for entry in $bin_files; do
- rm -f $kerneldir/$entry
+ rm -f $kerneldir/$entry
done
}
@@ -386,10 +386,10 @@ python populate_packages_prepend () {
return deps
def get_dependencies(file, pattern, format):
-# file no longer includes PKGD
+ # file no longer includes PKGD
file = file.replace(d.getVar('PKGD', True) or '', '', 1)
-# instead is prefixed with /lib/modules/${KERNEL_VERSION}
-file = file.replace(/lib/modules/%s/ %
d.getVar('KERNEL_VERSION', True) or '', '', 1)
+ # instead is prefixed with /lib/modules/${KERNEL_VERSION}
+ file = file.replace(/lib/modules/%s/ %
d.getVar('KERNEL_VERSION', True) or '', '', 1)
if module_deps.has_key(file):
import re
@@ -493,11 +493,11 @@ python populate_packages_prepend () {
do_sizecheck() {
if [ ! -z ${KERNEL_IMAGE_MAXSIZE} ]; then
size=`ls -l ${KERNEL_OUTPUT} | awk '{ print $5}'`
- if [ $size -ge ${KERNEL_IMAGE_MAXSIZE} ]; then
+ if [ $size -ge ${KERNEL_IMAGE_MAXSIZE} ]; then
rm ${KERNEL_OUTPUT}
- die This kernel (size=$size
${KERNEL_IMAGE_MAXSIZE}) is too big for your device. Please reduce the size of
the kernel by making more of it modular.
- fi
- fi
+ die This kernel (size=$size ${KERNEL_IMAGE_MAXSIZE})
is too big for your device. Please reduce the size of the kernel by making more
of it modular.
+ fi
+ fi
}
addtask sizecheck before do_install after do_compile
--
1.7.8.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][PATCHv2 1/2] kernel.bbclass: merge uboot_mkimage improvements from meta-oe
On 12-03-29 10:08 AM, Martin Jansa wrote:
* allows to detect ENTRYPOINT from kernel binary marked with UBOOT_ENTRYSYMBOL
used e.g. by ben-nanonote
Nice to see the big benefit called out, definitely helps the
casual reader :)
Looks like we've got all the use cases preserved, so I have no objections.
Acked-by: Bruce Ashfield bruce.ashfi...@windriver.com
Cheers,
Bruce
Signed-off-by: Martin Jansamartin.ja...@gmail.com
---
meta/classes/kernel.bbclass | 41 +
1 files changed, 25 insertions(+), 16 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 3519e7c..0ae9bed 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -507,28 +507,37 @@ KERNEL_IMAGE_BASE_NAME ?=
${KERNEL_IMAGETYPE}-${PV}-${PR}-${MACHINE}-${DATETIME
KERNEL_IMAGE_BASE_NAME[vardepsexclude] = DATETIME
KERNEL_IMAGE_SYMLINK_NAME ?= ${KERNEL_IMAGETYPE}-${MACHINE}
+do_uboot_mkimage() {
+ if test x${KERNEL_IMAGETYPE} = xuImage ; then
+ if test ! -e arch/${ARCH}/boot/uImage ; then
+ ENTRYPOINT=${UBOOT_ENTRYPOINT}
+ if test -n ${UBOOT_ENTRYSYMBOL}; then
+ ENTRYPOINT=`${HOST_PREFIX}nm ${S}/vmlinux | \
+ awk '$3==${UBOOT_ENTRYSYMBOL} {print
$1}'`
+ fi
+ if test -e arch/${ARCH}/boot/compressed/vmlinux ; then
+ ${OBJCOPY} -O binary -R .note -R .comment -S
arch/${ARCH}/boot/compressed/vmlinux linux.bin
+ uboot-mkimage -A ${UBOOT_ARCH} -O linux -T kernel -C none
-a ${UBOOT_LOADADDRESS} -e $ENTRYPOINT -n ${DISTRO_NAME}/${PV}/${MACHINE} -d
linux.bin arch/${ARCH}/boot/uImage
+ rm -f linux.bin
+ else
+ ${OBJCOPY} -O binary -R .note -R .comment -S
vmlinux linux.bin
+ rm -f linux.bin.gz
+ gzip -9 linux.bin
+ uboot-mkimage -A ${UBOOT_ARCH} -O linux -T kernel -C gzip
-a ${UBOOT_LOADADDRESS} -e $ENTRYPOINT -n ${DISTRO_NAME}/${PV}/${MACHINE} -d
linux.bin.gz arch/${ARCH}/boot/uImage
+ rm -f linux.bin.gz
+ fi
+ fi
+ fi
+}
+
+addtask uboot_mkimage before do_install after do_compile
+
kernel_do_deploy() {
install -m 0644 ${KERNEL_OUTPUT}
${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
if (grep -q -i -e '^CONFIG_MODULES=y$' .config); then
tar -cvzf
${DEPLOYDIR}/modules-${KERNEL_VERSION}-${PR}-${MACHINE}.tgz -C ${D} lib
fi
- if test x${KERNEL_IMAGETYPE} = xuImage ; then
- if test -e arch/${ARCH}/boot/uImage ; then
- cp arch/${ARCH}/boot/uImage
${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
- elif test -e arch/${ARCH}/boot/compressed/vmlinux ; then
- ${OBJCOPY} -O binary -R .note -R .comment -S
arch/${ARCH}/boot/compressed/vmlinux linux.bin
- uboot-mkimage -A ${ARCH} -O linux -T kernel -C none -a
${UBOOT_ENTRYPOINT} -e ${UBOOT_ENTRYPOINT} -n ${DISTRO_NAME}/${PV}/${MACHINE}
-d linux.bin ${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
- rm -f linux.bin
- else
- ${OBJCOPY} -O binary -R .note -R .comment -S vmlinux
linux.bin
- rm -f linux.bin.gz
- gzip -9 linux.bin
- uboot-mkimage -A ${ARCH} -O linux -T kernel -C gzip -a
${UBOOT_ENTRYPOINT} -e ${UBOOT_ENTRYPOINT} -n ${DISTRO_NAME}/${PV}/${MACHINE}
-d linux.bin.gz ${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
- rm -f linux.bin.gz
- fi
- fi
-
cd ${DEPLOYDIR}
rm -f ${KERNEL_IMAGE_SYMLINK_NAME}.bin
ln -sf ${KERNEL_IMAGE_BASE_NAME}.bin ${KERNEL_IMAGE_SYMLINK_NAME}.bin
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] gstreamer: Provide easy way to enable runtime debugging
The gstreamer framework has a very useful debugging setup which is
essential for debugging pipelines and plugins. This patch makes
it simple to enable this (disabled by default). To enable debugging,
just add this line to local.conf
GSTREAMER_DEBUG = --enable-debug
Signed-off-by: Gary Thomas g...@mlbassoc.com
---
.../gstreamer/gst-ffmpeg_0.10.13.bb|3 ++-
meta/recipes-multimedia/gstreamer/gst-fluendo.inc |3 ++-
meta/recipes-multimedia/gstreamer/gst-plugins.inc |3 ++-
.../gstreamer/gstreamer_0.10.36.bb |3 ++-
4 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-multimedia/gstreamer/gst-ffmpeg_0.10.13.bb
b/meta/recipes-multimedia/gstreamer/gst-ffmpeg_0.10.13.bb
index 5ee5066..92cd349 100644
--- a/meta/recipes-multimedia/gstreamer/gst-ffmpeg_0.10.13.bb
+++ b/meta/recipes-multimedia/gstreamer/gst-ffmpeg_0.10.13.bb
@@ -25,7 +25,8 @@ SRC_URI[sha256sum] =
76fca05b08e00134e3cb92fa347507f42cbd48ddb08ed3343a912def18
PR = r1
-EXTRA_OECONF = --with-ffmpeg-extra-configure=\--target-os=linux\
+GSTREAMER_DEBUG ?= --disable-debug
+EXTRA_OECONF = --with-ffmpeg-extra-configure=\--target-os=linux\
${GSTREAMER_DEBUG}
# yasm not found, use --disable-yasm for a crippled build for libav
EXTRA_OECONF_append_x86-64 = --disable-yasm
diff --git a/meta/recipes-multimedia/gstreamer/gst-fluendo.inc
b/meta/recipes-multimedia/gstreamer/gst-fluendo.inc
index 8b24cf7..b2c7eea 100644
--- a/meta/recipes-multimedia/gstreamer/gst-fluendo.inc
+++ b/meta/recipes-multimedia/gstreamer/gst-fluendo.inc
@@ -11,4 +11,5 @@ FILES_${PN} += ${libdir}/gstreamer-0.10/*.so
FILES_${PN}-dbg += ${libdir}/gstreamer-0.10/.debug
FILES_${PN}-dev += ${libdir}/gstreamer-0.10/*.la ${libdir}/gstreamer-0.10/*.a
-EXTRA_OECONF = --disable-debug --disable-valgrind
+GSTREAMER_DEBUG ?= --disable-debug
+EXTRA_OECONF = ${GSTREAMER_DEBUG} --disable-valgrind
diff --git a/meta/recipes-multimedia/gstreamer/gst-plugins.inc
b/meta/recipes-multimedia/gstreamer/gst-plugins.inc
index f11a4af..ccb81b3 100644
--- a/meta/recipes-multimedia/gstreamer/gst-plugins.inc
+++ b/meta/recipes-multimedia/gstreamer/gst-plugins.inc
@@ -10,7 +10,8 @@ FILESPATH =. ${FILE_DIRNAME}/gst-plugins:
SRC_URI = http://gstreamer.freedesktop.org/src/${BPN}/${BPN}-${PV}.tar.bz2;
-EXTRA_OECONF = --disable-valgrind --disable-debug --disable-examples
+GSTREAMER_DEBUG ?= --disable-debug
+EXTRA_OECONF = --disable-valgrind ${GSTREAMER_DEBUG} --disable-examples
acpaths = -I ${S}/common/m4 -I ${S}/m4
diff --git a/meta/recipes-multimedia/gstreamer/gstreamer_0.10.36.bb
b/meta/recipes-multimedia/gstreamer/gstreamer_0.10.36.bb
index 3c03c0d..278c20e 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer_0.10.36.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer_0.10.36.bb
@@ -20,7 +20,8 @@ SRC_URI[sha256sum] =
e556a529e0a8cf1cd0afd0cab2af5488c9524e7c3f409de29b5d82bb41
inherit autotools pkgconfig gettext
-EXTRA_OECONF = --disable-docs-build --disable-dependency-tracking
--with-check=no --disable-examples --disable-tests --disable-valgrind
--disable-debug
+GSTREAMER_DEBUG ?= --disable-debug
+EXTRA_OECONF = --disable-docs-build --disable-dependency-tracking
--with-check=no --disable-examples --disable-tests --disable-valgrind
${GSTREAMER_DEBUG}
#do_compile_prepend () {
# mv ${WORKDIR}/gstregistrybinary.[ch] ${S}/gst/
--
1.7.7.6
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][PATCH 1/2] kernel.bbclass: merge uboot_mkimage improvements from meta-oe
On 12-03-29 02:24 AM, Martin Jansa wrote:
Signed-off-by: Martin Jansa martin.ja...@gmail.com
A commit log here would have been nice. Since it isn't apparently
clear what the improvements are to myself or others.
I especially don't understand these cases where people start manually
running mkimage vs. taking the uImage from the kernel build. If there
is magic address foo needed to make a useful uImage for the platform,
then why isn't this data in the kernel Makefiles, vs. being squirrelled
off in some recipe? At a minimum, some comments in the recipe indicating
what the need for the custom mkimage call was about, and why it differed
from the default kernel uImage would be good.
Thanks,
Paul.
---
meta/classes/kernel.bbclass | 39 +++
1 files changed, 23 insertions(+), 16 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 3519e7c..8cd5fc7 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -502,32 +502,39 @@ do_sizecheck() {
addtask sizecheck before do_install after do_compile
-KERNEL_IMAGE_BASE_NAME ?=
${KERNEL_IMAGETYPE}-${PV}-${PR}-${MACHINE}-${DATETIME}
-# Don't include the DATETIME variable in the sstate package signatures
-KERNEL_IMAGE_BASE_NAME[vardepsexclude] = DATETIME
-KERNEL_IMAGE_SYMLINK_NAME ?= ${KERNEL_IMAGETYPE}-${MACHINE}
-
-kernel_do_deploy() {
- install -m 0644 ${KERNEL_OUTPUT}
${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
- if (grep -q -i -e '^CONFIG_MODULES=y$' .config); then
- tar -cvzf
${DEPLOYDIR}/modules-${KERNEL_VERSION}-${PR}-${MACHINE}.tgz -C ${D} lib
- fi
-
+do_uboot_mkimage() {
if test x${KERNEL_IMAGETYPE} = xuImage ; then
- if test -e arch/${ARCH}/boot/uImage ; then
- cp arch/${ARCH}/boot/uImage
${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
- elif test -e arch/${ARCH}/boot/compressed/vmlinux ; then
+ ENTRYPOINT=${UBOOT_ENTRYPOINT}
+ if test -n ${UBOOT_ENTRYSYMBOL}; then
+ ENTRYPOINT=`${HOST_PREFIX}nm ${S}/vmlinux | \
+ awk '$3==${UBOOT_ENTRYSYMBOL} {print $1}'`
+ fi
+ if test -e arch/${ARCH}/boot/compressed/vmlinux ; then
${OBJCOPY} -O binary -R .note -R .comment -S
arch/${ARCH}/boot/compressed/vmlinux linux.bin
- uboot-mkimage -A ${ARCH} -O linux -T kernel -C none -a
${UBOOT_ENTRYPOINT} -e ${UBOOT_ENTRYPOINT} -n
${DISTRO_NAME}/${PV}/${MACHINE} -d linux.bin
${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
+ uboot-mkimage -A ${UBOOT_ARCH} -O linux -T kernel -C
none -a ${UBOOT_LOADADDRESS} -e $ENTRYPOINT -n
${DISTRO_NAME}/${PV}/${MACHINE} -d linux.bin arch/${ARCH}/boot/uImage
rm -f linux.bin
else
${OBJCOPY} -O binary -R .note -R .comment -S vmlinux
linux.bin
rm -f linux.bin.gz
gzip -9 linux.bin
- uboot-mkimage -A ${ARCH} -O linux -T kernel -C gzip -a
${UBOOT_ENTRYPOINT} -e ${UBOOT_ENTRYPOINT} -n
${DISTRO_NAME}/${PV}/${MACHINE} -d linux.bin.gz
${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
+ uboot-mkimage -A ${UBOOT_ARCH} -O linux -T kernel -C
gzip -a ${UBOOT_LOADADDRESS} -e $ENTRYPOINT -n
${DISTRO_NAME}/${PV}/${MACHINE} -d linux.bin.gz arch/${ARCH}/boot/uImage
rm -f linux.bin.gz
fi
fi
+}
+
+addtask uboot_mkimage before do_install after do_compile
+
+KERNEL_IMAGE_BASE_NAME ?=
${KERNEL_IMAGETYPE}-${PV}-${PR}-${MACHINE}-${DATETIME}
+# Don't include the DATETIME variable in the sstate package signatures
+KERNEL_IMAGE_BASE_NAME[vardepsexclude] = DATETIME
+KERNEL_IMAGE_SYMLINK_NAME ?= ${KERNEL_IMAGETYPE}-${MACHINE}
+
+kernel_do_deploy() {
+ install -m 0644 ${KERNEL_OUTPUT}
${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
+ if (grep -q -i -e '^CONFIG_MODULES=y$' .config); then
+ tar -cvzf
${DEPLOYDIR}/modules-${KERNEL_VERSION}-${PR}-${MACHINE}.tgz -C ${D} lib
+ fi
cd ${DEPLOYDIR}
rm -f ${KERNEL_IMAGE_SYMLINK_NAME}.bin
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] Southeast LinuxFest
This is only a few hours from me (aka relatively close by US standards). Would anyone be interested in having an OpenEmbedded table here? http://www.southeastlinuxfest.org/ Philip ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/3] powerpc: define TUNE_PKGARCH for powerpc/powerpc-nf
On 3/28/12 11:54 PM, Chris Larson wrote: On Wed, Mar 28, 2012 at 9:47 PM, McClintock Matthew-B29882 b29...@freescale.com wrote: On Tue, Mar 27, 2012 at 5:16 PM, Chris Larsonclar...@kergoth.com wrote: If you can explain why the override isn't overriding the default TUNE_PKGARCH (and it's intentional and not a bug), and we can consistently modify all of the elements... I'm happy to accept the changes to all of the tunings. See above. It's not an override. And plenty of files already specify TUNE_PKGARCH_tune-tune, so I don't see how it'd be inconsistent to do so for the defaults, personally. If no one else has complained so far it makes me believe they are not missing any TUNE_PKGARCH_tune-tune then. I don't understand the point you're attempting to make here. Just an FYI -- I've not forgotten about this.. I'm going to look into what is currently implemented and figure out how to get it to be consistent.. things have definitely changed since the initial implementation, and things are no longer consistent. Hopefully I'll have an update later today. --Mark ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/3] powerpc: define TUNE_PKGARCH for powerpc/powerpc-nf
On Thu, Mar 29, 2012 at 8:38 AM, Mark Hatle mark.ha...@windriver.com wrote: On 3/28/12 11:54 PM, Chris Larson wrote: On Wed, Mar 28, 2012 at 9:47 PM, McClintock Matthew-B29882 b29...@freescale.com wrote: On Tue, Mar 27, 2012 at 5:16 PM, Chris Larsonclar...@kergoth.com wrote: If you can explain why the override isn't overriding the default TUNE_PKGARCH (and it's intentional and not a bug), and we can consistently modify all of the elements... I'm happy to accept the changes to all of the tunings. See above. It's not an override. And plenty of files already specify TUNE_PKGARCH_tune-tune, so I don't see how it'd be inconsistent to do so for the defaults, personally. If no one else has complained so far it makes me believe they are not missing any TUNE_PKGARCH_tune-tune then. I don't understand the point you're attempting to make here. Just an FYI -- I've not forgotten about this.. I'm going to look into what is currently implemented and figure out how to get it to be consistent.. things have definitely changed since the initial implementation, and things are no longer consistent. Understood, thanks. It's good that someone with a better grasp of the entirety of the implementation and its goals take that on. This particular patch isn't particularly important to me, the other two were, but I'm very curious as to how you'll address this, since as I mentioned before it seems that the non-override based implementation is a problem for archs that explicitly set TUNE_PKGARCH. Thanks for looking into this. -- Christopher Larson ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] runqemu change to show early boot messages
Hello, This pull request sets console=ttyS0 in the kernel options when booting images with the nographic option to runqemu. It is a bugfix for [YOCTO #1475]. I have runtime tested it on all 5 of our QEMU architectures using core-image-minimal, both for standard boot cases as well as booting via NFS. Scott The following changes since commit 8fe53bdc807184bc41469d8587368b31192e6252: ghostscript: Fix remaining CP_ prallel make races (2012-03-29 09:44:36 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib sgarman/runqemu-fix-oe http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=sgarman/runqemu-fix-oe Scott Garman (1): runqemu: set console=ttyS0 when running with nographic option scripts/runqemu |1 + 1 files changed, 1 insertions(+), 0 deletions(-) -- 1.7.5.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] runqemu: set console=ttyS0 when running with nographic option
When passing the nograhic option to the runqemu script, set console=ttyS0 in the kernel options so the user can view the kernel boot messages. This fixes [YOCTO #1475] Signed-off-by: Scott Garman scott.a.gar...@intel.com --- scripts/runqemu |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/scripts/runqemu b/scripts/runqemu index c349de0..caabf61 100755 --- a/scripts/runqemu +++ b/scripts/runqemu @@ -135,6 +135,7 @@ while [ $i -le $# ]; do ;; nographic) SCRIPT_QEMU_OPT=$SCRIPT_QEMU_OPT -nographic +SCRIPT_KERNEL_OPT=$SCRIPT_KERNEL_OPT console=ttyS0 ;; serial) SCRIPT_QEMU_OPT=$SCRIPT_QEMU_OPT -serial stdio -- 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 3/3] powerpc: define TUNE_PKGARCH for powerpc/powerpc-nf
On Thu, Mar 29, 2012 at 10:38 AM, Mark Hatle mark.ha...@windriver.com wrote:
On 3/28/12 11:54 PM, Chris Larson wrote:
On Wed, Mar 28, 2012 at 9:47 PM, McClintock Matthew-B29882
b29...@freescale.com wrote:
On Tue, Mar 27, 2012 at 5:16 PM, Chris Larsonclar...@kergoth.com
wrote:
If you can explain why the override isn't overriding the default
TUNE_PKGARCH (and it's intentional and not a bug), and we can
consistently
modify all of the elements... I'm happy to accept the changes to all of
the
tunings.
See above. It's not an override. And plenty of files already specify
TUNE_PKGARCH_tune-tune, so I don't see how it'd be inconsistent to
do so for the defaults, personally.
If no one else has complained so far it makes me believe they are not
missing any TUNE_PKGARCH_tune-tune then.
I don't understand the point you're attempting to make here.
Just an FYI -- I've not forgotten about this.. I'm going to look into what
is currently implemented and figure out how to get it to be consistent..
things have definitely changed since the initial implementation, and things
are no longer consistent.
Hopefully I'll have an update later today.
Just for some background:
I added the TUNEPKG_ARCH = TUNE_PKGARCH_tune-$DEFAULTTUNE bit because
it seemed to make sense and it was missing from this list:
meta/conf/bitbake.conf:TUNE_FEATURES ??= ${TUNE_FEATURES_tune-${DEFAULTTUNE}}
meta/conf/bitbake.conf:PACKAGE_EXTRA_ARCHS ??=
${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
Also it seemed silly (at the time admittedly) to set TUNE_PKGARCH
based off a value in TUNE_FEATURES and using bb functions to do this
when the way I went with was simply setting a value. I did miss that
the default case no longer works properly unless you have a
TUNE_PKGARCH_tune-{powerpc,powerpc-nf,powerpc64} =
{powerpc,powerpc-nf,powerpc64} set in the default arch files.
Anyways, I'm not stuck on one particular method at the time I was
trying to get ppce5500 multilib working properly.
-M
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] DEPENDS not extended to -native for BBCLASSEXTENDS when added by PACKAGECONFIG
Hi, on my colleagues's build machine ( Ubuntu 11.04 / Angstrom based / target overo / pullled all layers yesterday ) image building fails for gtk+native with | configure: error: *** libX11 not found. Check 'config.log' for more details. and in config.log | /usr/bin/ld: cannot find -lXrender After manually building libxrender-native build continues without issues. Seems this issue is same as mentioned in [1] without result. Martin: how did you fix that on your environment? Andreas [1] http://lists.linuxtogo.org/pipermail/openembedded-core/2012-February/018293.html ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/3] powerpc: define TUNE_PKGARCH for powerpc/powerpc-nf
(This is going to be a bit rambling I'm afraid.. I'm working my way through
investigation and a possible solution.. so be sure to look all the way to the
end..)
On 3/29/12 10:58 AM, McClintock Matthew-B29882 wrote:
On Thu, Mar 29, 2012 at 10:38 AM, Mark Hatlemark.ha...@windriver.com wrote:
On 3/28/12 11:54 PM, Chris Larson wrote:
On Wed, Mar 28, 2012 at 9:47 PM, McClintock Matthew-B29882
b29...@freescale.comwrote:
On Tue, Mar 27, 2012 at 5:16 PM, Chris Larsonclar...@kergoth.com
wrote:
If you can explain why the override isn't overriding the default
TUNE_PKGARCH (and it's intentional and not a bug), and we can
consistently
modify all of the elements... I'm happy to accept the changes to all of
the
tunings.
See above. It's not an override. And plenty of files already specify
TUNE_PKGARCH_tune-tune, so I don't see how it'd be inconsistent to
do so for the defaults, personally.
If no one else has complained so far it makes me believe they are not
missing any TUNE_PKGARCH_tune-tunethen.
I don't understand the point you're attempting to make here.
Just an FYI -- I've not forgotten about this.. I'm going to look into what
is currently implemented and figure out how to get it to be consistent..
things have definitely changed since the initial implementation, and things
are no longer consistent.
Hopefully I'll have an update later today.
Just for some background:
I added the TUNEPKG_ARCH = TUNE_PKGARCH_tune-$DEFAULTTUNE bit because
it seemed to make sense and it was missing from this list:
meta/conf/bitbake.conf:TUNE_FEATURES ??= ${TUNE_FEATURES_tune-${DEFAULTTUNE}}
meta/conf/bitbake.conf:PACKAGE_EXTRA_ARCHS ??=
${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
Also it seemed silly (at the time admittedly) to set TUNE_PKGARCH
based off a value in TUNE_FEATURES and using bb functions to do this
when the way I went with was simply setting a value. I did miss that
the default case no longer works properly unless you have a
TUNE_PKGARCH_tune-{powerpc,powerpc-nf,powerpc64} =
{powerpc,powerpc-nf,powerpc64} set in the default arch files.
Anyways, I'm not stuck on one particular method at the time I was
trying to get ppce5500 multilib working properly.
Ok, that makes a bit more sense.. What I see right now is:
TUNE_PKGARCH ??= ${TUNE_PKGARCH_tune-${DEFAULTTUNE}}
(This was originally designed that TUNE_PKGARCH was defined based on the
overrides... note, not only has the above affected that, but it's not consistent
in the other architectures either.. so it was wrong, and is still likely wrong...)
Arm defines it as:
TUNE_PKGARCH = ${@d.getVar('ARMPKGARCH',
True)}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}
That way the ARMPKGARCH is the base of the configuration, while the DSP, ABI,
Endian and FPU are added dynamically based on the feature flags (and associated
settings)..
IA defines is as:
TUNE_PKGARCH ?= ${@bb.utils.contains(TUNE_FEATURES, m32, x86, x86_64,
d)}
TUNE_PKGARCH .= ${@bb.utils.contains(TUNE_FEATURES, mx32, _x32, , d)}
And then some (c3, core2, i586) override that, but not all of them.. again this
is likely wrong as well..
MIPS defines it as:
TUNE_PKGARCH ?= ${TUNE_ARCH}${MIPSPKGSFX_FPU}${MIPSPKGSFX_ABI}
TUNE_ARCH as:
TUNE_ARCH = mips${MIPSPKGSFX_BYTE}${MIPSPKGSFX_ENDIAN}
and finally powerpc:
There is NO TUNE_PKGARCH defined.. but there is an append:
TUNE_PKGARCH_append = ${PPCPKGSFX_FPU}
And each of the tunings:
tune-ppc603e.inc:TUNE_PKGARCH_tune-ppc603e = ppc603e
tune-ppce300c2.inc:TUNE_PKGARCH_tune-ppce300c2 = ppce300c2
tune-ppce500.inc:TUNE_PKGARCH_tune-ppce500 = ppce500
tune-ppce500mc.inc:TUNE_PKGARCH_tune-ppce500mc = ppce500mc
tune-ppce500v2.inc:TUNE_PKGARCH_tune-ppce500v2 = ppce500v2
tune-ppce5500.inc:TUNE_PKGARCH_tune-ppce5500 = ppce5500
tune-ppce5500.inc:TUNE_PKGARCH_tune-ppc64e5500 = ppc64e5500
so somehow we need to figure out a more consistent approach. Personally I
prefer the ARM/MIPS style approach. Build up the format using a consistent set
of features/arguments.
The one thing I'm still struggling with though is what is the final purpose of
these variables. I may be able to make a better determination as to the right
values if I truly understood the difference. Below is my attempt at
understanding this... (let me know if this is correct or if you have corrections)
DEFAULTTUNE - The default tuning for a given machine or build
[multilib build uses overrides to change the DEFAULTTUNE setting], tune values
are defined by the conf/machine/include/* items
TUNE_FEATURES_tune-tune - Should not be manually modified (i.e. not in
local.conf, only specified by a tune file), but inherited via the DEFAULTTUNE
value -- this defines the set of tuning variables that a given tuning uses to
setup cflags, pkgarch, abi, etc..
TUNE_CCARGS - Setup the cflags based on the TUNE_FEATURES settings. These
should be additive when defined using +=. All items in this list should be
dynamic!
[OE-core] chasing mirrors
How do I determine which mirror was/is being used to download a particular component? I'm expecting some info in a log, or from the output of bitbake -D, but I'm not finding it. And from a glance at the code I don't see any message statements around the mirror iterations although I could easily be missing it. --rich ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] chasing mirrors
On Thu, 2012-03-29 at 09:45 -0700, Rich Pixley wrote: How do I determine which mirror was/is being used to download a particular component? I'm expecting some info in a log, or from the output of bitbake -D, but I'm not finding it. And from a glance at the code I don't see any message statements around the mirror iterations although I could easily be missing it. It would appear in the do_fetch logs in WORKDIR/temp for the build in question. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] pseudo failing with cc1: error: unrecognized command line option '-m32'
The pseudo build fails on both 32 and 64 bit build machines. I am building for arm (omap). Not sure if this is related to the recent pseudo recipes changes, but here are the details: NOTE: package pseudo-1.3-r7: task do_compile: Started ERROR: Function failed: do_compile (see /media/Work/yocto/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/pseudo-1.3-r7/temp/log.do_compile.26657 for further information) ERROR: Logfile of failure stored in: /media/Work/yocto/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/pseudo-1.3-r7/temp/log.do_compile.26657 Log data follows: | ERROR: Function failed: do_compile (see /media/Work/yocto/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/pseudo-1.3-r7/temp/log.do_compile.26657 for further information) | SQLite header for version 3007010 found. | NOTE: make -j 8 -e MAKEFLAGS= | mkdir -p lib/pseudo/lib | ./makewrappers | ./maketables enums/*.in | mkdir -p bin | enums/msg_type.in: type: msg_type_t (prefix 'PSEUDO_MSG_ENUM') |ping shutdown op ack |nak | | enums/op.in: type: op_t (prefix 'OP_ENUM') |chdir chmod chown chroot |close creat dupfchmod |fchown fstat link mkdir |mknod open rename stat |unlink symlinkexec may-unlink |did-unlink cancel-unlink | | enums/query_field.in: type: query_field_t (prefix 'PSQF_ENUM') |access client devfd |ftype gidid inode |mode op order path |perm programresult severity |stamp tagtext type |uid | | enums/query_type.in: type: query_type_t (prefix 'PSQT_ENUM') | extra column: sql (default 'LITTLE BOBBY TABLES') |exact less greaterbitand |notequal like notlikesqlpat | | enums/res.in: type: res_t (prefix 'RESULT_ENUM') |succeedfail error | | enums/sev.in: type: sev_t (prefix 'SEVERITY_ENUM') |debug info warn error |critical | | Writing datatypes... done. Cleaning up. | ccache arm-poky-linux-gnueabi-gcc -march=armv7-a -fno-tree-vectorize -mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 --sysroot=/media/Work/yocto/tmp/sysroots/omap4-multi -O2 -pipe -g -feliminate-unused-debug-types -pipe -std=gnu99 -Wall -W -Wextra -fPIC -D_LARGEFILE64_SOURCE -D_ATFILE_SOURCE -m32 -DPSEUDO_PREFIX='/usr' -DPSEUDO_SUFFIX='' -DPSEUDO_BINDIR='bin' -DPSEUDO_LIBDIR='lib/pseudo/lib' -DPSEUDO_LOCALSTATEDIR='var/pseudo' -DPSEUDO_VERSION='1.3' -O2 -g -L/media/Work/yocto/tmp/sysroots/omap4-multi/usr/lib -I/media/Work/yocto/tmp/sysroots/omap4-multi/usr/include -Wl,-R/media/Work/yocto/tmp/sysroots/omap4-multi/usr/lib -c -o pseudo_tables.o pseudo_tables.c | cc1: error: unrecognized command line option '-m32' | make: *** [pseudo_tables.o] Error 1 | make: *** Waiting for unfinished jobs | Checking for old/new clone mechanics...New clone. | ports/common/wrapfuncs.in: ... | ports/linux/wrapfuncs.in: . | ports/unix/wrapfuncs.in: . | ports/uids_generic/wrapfuncs.in: | ports/linux/newclone/wrapfuncs.in: . | Writing functions... Warning: lchown from linux overriding unix | done. Cleaning up. | ERROR: oe_runmake failed NOTE: package pseudo-1.3-r7: task do_compile: Failed ERROR: Task 7 (/home/sakoman/source/yocto/poky/meta/recipes-devtools/pseudo/pseudo_1.3.bb, do_compile) failed with exit code '1' Steve ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] comments and actual PACKAGE_CROUPs in core-image.bbclass don't match
yes, yes, more pedantry but if one examines core-image.bbclass, the explanatory comments for the IMAGE_FEATURES/PACKAGE_GROUP lines don't sync up exactly (for example, no comment line for qt4-pkgs). i'll let someone higher up the food chain decide if that's worth tweaking. 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
Re: [OE-core] [PATCH 3/3] powerpc: define TUNE_PKGARCH for powerpc/powerpc-nf
On Thu, Mar 29, 2012 at 9:40 AM, Mark Hatle mark.ha...@windriver.com wrote:
(This is going to be a bit rambling I'm afraid.. I'm working my way through
investigation and a possible solution.. so be sure to look all the way to
the end..)
On 3/29/12 10:58 AM, McClintock Matthew-B29882 wrote:
On Thu, Mar 29, 2012 at 10:38 AM, Mark Hatlemark.ha...@windriver.com
wrote:
On 3/28/12 11:54 PM, Chris Larson wrote:
On Wed, Mar 28, 2012 at 9:47 PM, McClintock Matthew-B29882
b29...@freescale.com wrote:
On Tue, Mar 27, 2012 at 5:16 PM, Chris Larsonclar...@kergoth.com
wrote:
If you can explain why the override isn't overriding the default
TUNE_PKGARCH (and it's intentional and not a bug), and we can
consistently
modify all of the elements... I'm happy to accept the changes to all
of
the
tunings.
See above. It's not an override. And plenty of files already specify
TUNE_PKGARCH_tune-tune, so I don't see how it'd be inconsistent to
do so for the defaults, personally.
If no one else has complained so far it makes me believe they are not
missing any TUNE_PKGARCH_tune-tune then.
I don't understand the point you're attempting to make here.
Just an FYI -- I've not forgotten about this.. I'm going to look into
what
is currently implemented and figure out how to get it to be consistent..
things have definitely changed since the initial implementation, and
things
are no longer consistent.
Hopefully I'll have an update later today.
Just for some background:
I added the TUNEPKG_ARCH = TUNE_PKGARCH_tune-$DEFAULTTUNE bit because
it seemed to make sense and it was missing from this list:
meta/conf/bitbake.conf:TUNE_FEATURES ??=
${TUNE_FEATURES_tune-${DEFAULTTUNE}}
meta/conf/bitbake.conf:PACKAGE_EXTRA_ARCHS ??=
${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
Also it seemed silly (at the time admittedly) to set TUNE_PKGARCH
based off a value in TUNE_FEATURES and using bb functions to do this
when the way I went with was simply setting a value. I did miss that
the default case no longer works properly unless you have a
TUNE_PKGARCH_tune-{powerpc,powerpc-nf,powerpc64} =
{powerpc,powerpc-nf,powerpc64} set in the default arch files.
Anyways, I'm not stuck on one particular method at the time I was
trying to get ppce5500 multilib working properly.
Ok, that makes a bit more sense.. What I see right now is:
TUNE_PKGARCH ??= ${TUNE_PKGARCH_tune-${DEFAULTTUNE}}
(This was originally designed that TUNE_PKGARCH was defined based on the
overrides... note, not only has the above affected that, but it's not
consistent in the other architectures either.. so it was wrong, and is still
likely wrong...)
Arm defines it as:
TUNE_PKGARCH = ${@d.getVar('ARMPKGARCH',
True)}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}
That way the ARMPKGARCH is the base of the configuration, while the DSP,
ABI, Endian and FPU are added dynamically based on the feature flags (and
associated settings)..
IA defines is as:
TUNE_PKGARCH ?= ${@bb.utils.contains(TUNE_FEATURES, m32, x86,
x86_64, d)}
TUNE_PKGARCH .= ${@bb.utils.contains(TUNE_FEATURES, mx32, _x32, ,
d)}
And then some (c3, core2, i586) override that, but not all of them.. again
this is likely wrong as well..
MIPS defines it as:
TUNE_PKGARCH ?= ${TUNE_ARCH}${MIPSPKGSFX_FPU}${MIPSPKGSFX_ABI}
TUNE_ARCH as:
TUNE_ARCH = mips${MIPSPKGSFX_BYTE}${MIPSPKGSFX_ENDIAN}
and finally powerpc:
There is NO TUNE_PKGARCH defined.. but there is an append:
TUNE_PKGARCH_append = ${PPCPKGSFX_FPU}
And each of the tunings:
tune-ppc603e.inc:TUNE_PKGARCH_tune-ppc603e = ppc603e
tune-ppce300c2.inc:TUNE_PKGARCH_tune-ppce300c2 = ppce300c2
tune-ppce500.inc:TUNE_PKGARCH_tune-ppce500 = ppce500
tune-ppce500mc.inc:TUNE_PKGARCH_tune-ppce500mc = ppce500mc
tune-ppce500v2.inc:TUNE_PKGARCH_tune-ppce500v2 = ppce500v2
tune-ppce5500.inc:TUNE_PKGARCH_tune-ppce5500 = ppce5500
tune-ppce5500.inc:TUNE_PKGARCH_tune-ppc64e5500 = ppc64e5500
so somehow we need to figure out a more consistent approach.
Personally I prefer the ARM/MIPS style approach. Build up the format using
a consistent set of features/arguments.
That seems reasonable to me. I personally don't care much about which
approach is used as long as we're consistent about it :)
The one thing I'm still struggling with though is what is the final purpose
of these variables. I may be able to make a better determination as to the
right values if I truly understood the difference. Below is my attempt at
understanding this... (let me know if this is correct or if you have
corrections)
DEFAULTTUNE - The default tuning for a given machine or build
[multilib build uses overrides to change the DEFAULTTUNE setting], tune
values are defined by the conf/machine/include/* items
TUNE_FEATURES_tune-tune - Should not be manually modified (i.e. not in
local.conf, only specified by a tune file), but inherited via the
DEFAULTTUNE value
Re: [OE-core] pseudo failing with cc1: error: unrecognized command line option '-m32'
It appears you are trying to build pseudo for the target right? We've not really validated pseudo on non-x86 hosts. I'm guessing a patch to remove the -m32/-m64 hard coded flags may be necessary. (I've cc'd the pseudo maintainer...) --Mark On 3/29/12 1:30 PM, Steve Sakoman wrote: The pseudo build fails on both 32 and 64 bit build machines. I am building for arm (omap). Not sure if this is related to the recent pseudo recipes changes, but here are the details: NOTE: package pseudo-1.3-r7: task do_compile: Started ERROR: Function failed: do_compile (see /media/Work/yocto/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/pseudo-1.3-r7/temp/log.do_compile.26657 for further information) ERROR: Logfile of failure stored in: /media/Work/yocto/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/pseudo-1.3-r7/temp/log.do_compile.26657 Log data follows: | ERROR: Function failed: do_compile (see /media/Work/yocto/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/pseudo-1.3-r7/temp/log.do_compile.26657 for further information) | SQLite header for version 3007010 found. | NOTE: make -j 8 -e MAKEFLAGS= | mkdir -p lib/pseudo/lib | ./makewrappers | ./maketables enums/*.in | mkdir -p bin | enums/msg_type.in: type: msg_type_t (prefix 'PSEUDO_MSG_ENUM') |ping shutdown op ack |nak | | enums/op.in: type: op_t (prefix 'OP_ENUM') |chdir chmod chown chroot |close creat dupfchmod |fchown fstat link mkdir |mknod open rename stat |unlink symlinkexec may-unlink |did-unlink cancel-unlink | | enums/query_field.in: type: query_field_t (prefix 'PSQF_ENUM') |access client devfd |ftype gidid inode |mode op order path |perm programresult severity |stamp tagtext type |uid | | enums/query_type.in: type: query_type_t (prefix 'PSQT_ENUM') | extra column: sql (default 'LITTLE BOBBY TABLES') |exact less greaterbitand |notequal like notlikesqlpat | | enums/res.in: type: res_t (prefix 'RESULT_ENUM') |succeedfail error | | enums/sev.in: type: sev_t (prefix 'SEVERITY_ENUM') |debug info warn error |critical | | Writing datatypes... done. Cleaning up. | ccache arm-poky-linux-gnueabi-gcc -march=armv7-a -fno-tree-vectorize -mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 --sysroot=/media/Work/yocto/tmp/sysroots/omap4-multi -O2 -pipe -g -feliminate-unused-debug-types -pipe -std=gnu99 -Wall -W -Wextra -fPIC -D_LARGEFILE64_SOURCE -D_ATFILE_SOURCE -m32 -DPSEUDO_PREFIX='/usr' -DPSEUDO_SUFFIX='' -DPSEUDO_BINDIR='bin' -DPSEUDO_LIBDIR='lib/pseudo/lib' -DPSEUDO_LOCALSTATEDIR='var/pseudo' -DPSEUDO_VERSION='1.3' -O2 -g -L/media/Work/yocto/tmp/sysroots/omap4-multi/usr/lib -I/media/Work/yocto/tmp/sysroots/omap4-multi/usr/include -Wl,-R/media/Work/yocto/tmp/sysroots/omap4-multi/usr/lib -c -o pseudo_tables.o pseudo_tables.c | cc1: error: unrecognized command line option '-m32' | make: *** [pseudo_tables.o] Error 1 | make: *** Waiting for unfinished jobs | Checking for old/new clone mechanics...New clone. | ports/common/wrapfuncs.in: ... | ports/linux/wrapfuncs.in: . | ports/unix/wrapfuncs.in: . | ports/uids_generic/wrapfuncs.in: | ports/linux/newclone/wrapfuncs.in: . | Writing functions... Warning: lchown from linux overriding unix | done. Cleaning up. | ERROR: oe_runmake failed NOTE: package pseudo-1.3-r7: task do_compile: Failed ERROR: Task 7 (/home/sakoman/source/yocto/poky/meta/recipes-devtools/pseudo/pseudo_1.3.bb, do_compile) failed with exit code '1' Steve ___ 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] pseudo failing with cc1: error: unrecognized command line option '-m32'
On Thu, Mar 29, 2012 at 11:39 AM, Mark Hatle mark.ha...@windriver.com wrote: It appears you are trying to build pseudo for the target right? We've not really validated pseudo on non-x86 hosts. I'm guessing a patch to remove the -m32/-m64 hard coded flags may be necessary. (I've cc'd the pseudo maintainer...) Yes, I figured it would be interesting to see what would happen with task-self-hosted on arm :-) Clearly not something a sane person would do . . . Steve On 3/29/12 1:30 PM, Steve Sakoman wrote: The pseudo build fails on both 32 and 64 bit build machines. I am building for arm (omap). Not sure if this is related to the recent pseudo recipes changes, but here are the details: NOTE: package pseudo-1.3-r7: task do_compile: Started ERROR: Function failed: do_compile (see /media/Work/yocto/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/pseudo-1.3-r7/temp/log.do_compile.26657 for further information) ERROR: Logfile of failure stored in: /media/Work/yocto/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/pseudo-1.3-r7/temp/log.do_compile.26657 Log data follows: | ERROR: Function failed: do_compile (see /media/Work/yocto/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/pseudo-1.3-r7/temp/log.do_compile.26657 for further information) | SQLite header for version 3007010 found. | NOTE: make -j 8 -e MAKEFLAGS= | mkdir -p lib/pseudo/lib | ./makewrappers | ./maketables enums/*.in | mkdir -p bin | enums/msg_type.in: type: msg_type_t (prefix 'PSEUDO_MSG_ENUM') | ping shutdown op ack | nak | | enums/op.in: type: op_t (prefix 'OP_ENUM') | chdir chmod chown chroot | close creat dup fchmod | fchown fstat link mkdir | mknod open rename stat | unlink symlink exec may-unlink | did-unlink cancel-unlink | | enums/query_field.in: type: query_field_t (prefix 'PSQF_ENUM') | access client dev fd | ftype gid id inode | mode op order path | perm program result severity | stamp tag text type | uid | | enums/query_type.in: type: query_type_t (prefix 'PSQT_ENUM') | extra column: sql (default 'LITTLE BOBBY TABLES') | exact less greater bitand | notequal like notlike sqlpat | | enums/res.in: type: res_t (prefix 'RESULT_ENUM') | succeed fail error | | enums/sev.in: type: sev_t (prefix 'SEVERITY_ENUM') | debug info warn error | critical | | Writing datatypes... done. Cleaning up. | ccache arm-poky-linux-gnueabi-gcc -march=armv7-a -fno-tree-vectorize -mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 --sysroot=/media/Work/yocto/tmp/sysroots/omap4-multi -O2 -pipe -g -feliminate-unused-debug-types -pipe -std=gnu99 -Wall -W -Wextra -fPIC -D_LARGEFILE64_SOURCE -D_ATFILE_SOURCE -m32 -DPSEUDO_PREFIX='/usr' -DPSEUDO_SUFFIX='' -DPSEUDO_BINDIR='bin' -DPSEUDO_LIBDIR='lib/pseudo/lib' -DPSEUDO_LOCALSTATEDIR='var/pseudo' -DPSEUDO_VERSION='1.3' -O2 -g -L/media/Work/yocto/tmp/sysroots/omap4-multi/usr/lib -I/media/Work/yocto/tmp/sysroots/omap4-multi/usr/include -Wl,-R/media/Work/yocto/tmp/sysroots/omap4-multi/usr/lib -c -o pseudo_tables.o pseudo_tables.c | cc1: error: unrecognized command line option '-m32' | make: *** [pseudo_tables.o] Error 1 | make: *** Waiting for unfinished jobs | Checking for old/new clone mechanics...New clone. | ports/common/wrapfuncs.in: ... | ports/linux/wrapfuncs.in: . | ports/unix/wrapfuncs.in: . | ports/uids_generic/wrapfuncs.in: | ports/linux/newclone/wrapfuncs.in: . | Writing functions... Warning: lchown from linux overriding unix | done. Cleaning up. | ERROR: oe_runmake failed NOTE: package pseudo-1.3-r7: task do_compile: Failed ERROR: Task 7 (/home/sakoman/source/yocto/poky/meta/recipes-devtools/pseudo/pseudo_1.3.bb, do_compile) failed with exit code '1' Steve ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list
[OE-core] a bit more confusing commentary in core-image.bbclass
=== excerpt
# IMAGE_FEATURES control content of the core reference images
#
# By default we install task-core-boot and task-base packages - this gives us
# working (console only) rootfs.
#
# Available IMAGE_FEATURES:
... snip ...
CORE_IMAGE_BASE_INSTALL = '\
task-core-boot \
task-base-extended \
\
${CORE_IMAGE_EXTRA_INSTALL} \
'
CORE_IMAGE_EXTRA_INSTALL ?=
IMAGE_INSTALL ?= ${CORE_IMAGE_BASE_INSTALL}
=== excerpt
first, the early comment refers to task-base when what's included
is actually task-base-extended. (perhaps it's worth adding a
pointer to where one can read the definition of that task as well?)
and second, the early comment claims that IMAGE_FEATURES controls
the content of the core reference images but says nothing about the
user having control with CORE_IMAGE_EXTRA_INSTALL as well. and
there's no mention of EXTRA_IMAGE_FEATURES anywhere there, either.
all in all, that's kind of a confusing file to RTFS.
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
Re: [OE-core] [PATCH 3/3] powerpc: define TUNE_PKGARCH for powerpc/powerpc-nf
On Thu, Mar 29, 2012 at 1:38 PM, Chris Larson clar...@kergoth.com wrote:
Does the above seem reasonable? If so I'll try to get started on that...
That seems reasonable to me, for what that's worth. I could see
simplifying the way the powerpc stuff works in the future, but at
least we'd have something functional for now as well. It keeps primary
responsibility for TUNE_PKGARCH in arch-powerpc*.inc, which is as it
should be -- the arch knows best how to manage it. I'm curious to hear
Matthew's perspective on this.
This is fine with me, I just did not like setting
TUNE_FEATURES = foo
only to have
TUNE_ARCH = ${@bb.utils.contains(TUNE_FEATURES, foo, foo,
${PPCPKGARCH}, d)}
when it seemed better to just
TUNE_ARCH = foo
At least I think that was my thought logic, then it went a step
further and thought we could just use TUNE_PKGARCH_tune-$DEFAULTTUNE
since these would be available from multilib anyways...
-M
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] argh ... _append versus += and IMAGE_INSTALL confusion
forgive me for free associating for just a few minutes, but here's
something that has the potential to be massively confusing for
beginners.
starting with core-image.bbclass, this is just a coding philosophy
but i'm not crazy about this:
CORE_IMAGE_BASE_INSTALL = '\
task-core-boot \
task-base-extended \
\
${CORE_IMAGE_EXTRA_INSTALL} \
'
CORE_IMAGE_EXTRA_INSTALL ?=
IMAGE_INSTALL ?= ${CORE_IMAGE_BASE_INSTALL}
at a glance, it looks weird that IMAGE_INSTALL is simply assigned
the value of CORE_IMAGE_BASE_INSTALL, and it's only when you look up
that you notice there's a CORE_IMAGE_EXTRA_INSTALL that you can use
which is buried inside the assignment to CORE_IMAGE_BASE_INSTALL.
doing it that way forces a reader to follow the chain of assignments
to see what's happening.
it would be much clearer to write (if it's equivalent):
CORE_IMAGE_BASE_INSTALL = '\
task-core-boot \
task-base-extended \
'
CORE_IMAGE_EXTRA_INSTALL ?=
IMAGE_INSTALL ?= ${CORE_IMAGE_BASE_INSTALL} ${CORE_IMAGE_EXTRA_INSTALL}
there. now in the space of that single line, i can see that the
*final* value for IMAGE_INSTALL comes from two other values. and i
can even see which one appears to be the one *i* should mess with --
the one containing EXTRA. that construct is almost self-explanatory
and, for me, much clearer than the first one. but wait, there's more.
in the current *released* reference manual, there is a suggestion
for how to create custom images:
For example, if a developer wants to add strace into the
core-image-sato image, they can use the following recipe:
require core-image-sato.bb
IMAGE_INSTALL += strace
ok, but what's the point of having CORE_IMAGE_EXTRA_INSTALL if you
don't tell people to use it?
require core-image-sato.bb
CORE_IMAGE_EXTRA_INSTALL = strace
are those two definitions equivalent? is there any advantage to one
over the other?
and finally, in the *development* version of the reference manual,
you find the new content:
file:///home/rpjday/yocto/yocto-docs/documentation/poky-ref-manual/poky-ref-manual.html#var-IMAGE_INSTALL
When you use this variable, it is best to use it as follows:
IMAGE_INSTALL_append = package-name
argh. so what's wrong with using CORE_IMAGE_EXTRA_INSTALL? numerous
oe-core .bb files don't take that advice -- see
core-image-minimal-mtdutils.bb:
require core-image-minimal.bb
... snip ...
IMAGE_INSTALL += mtd-utils
so what is best practise here?
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
Re: [OE-core] argh ... _append versus += and IMAGE_INSTALL confusion
Le Thu, 29 Mar 2012 15:23:20 -0400 (EDT), Robert P. J. Day rpj...@crashcourse.ca a écrit : so what is best practise here? for this one you have an answer on OE's wiki : http://www.openembedded.org/wiki/I_want_an_image_with_package_XYZ_installed Eric ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] argh ... _append versus += and IMAGE_INSTALL confusion
On Thu, 29 Mar 2012, Eric Bénard wrote: Le Thu, 29 Mar 2012 15:23:20 -0400 (EDT), Robert P. J. Day rpj...@crashcourse.ca a écrit : so what is best practise here? for this one you have an answer on OE's wiki : http://www.openembedded.org/wiki/I_want_an_image_with_package_XYZ_installed despite the fact that the current reference manual *explicitly* says this? Using IMAGE_INSTALL with the += operator from the /conf/local.conf file or from within an image recipe is not recommended as it can cause ordering issues. i actually did my research before i asked that question, you know. 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
Re: [OE-core] argh ... _append versus += and IMAGE_INSTALL confusion
Le Thu, 29 Mar 2012 15:35:10 -0400 (EDT), Robert P. J. Day rpj...@crashcourse.ca a écrit : On Thu, 29 Mar 2012, Eric Bénard wrote: Le Thu, 29 Mar 2012 15:23:20 -0400 (EDT), Robert P. J. Day rpj...@crashcourse.ca a écrit : so what is best practise here? for this one you have an answer on OE's wiki : http://www.openembedded.org/wiki/I_want_an_image_with_package_XYZ_installed despite the fact that the current reference manual *explicitly* says this? Using IMAGE_INSTALL with the += operator from the /conf/local.conf file or from within an image recipe is not recommended as it can cause ordering issues. i actually did my research before i asked that question, you know. fine, sorry for trying to give an answer to your question. Eric ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] argh ... _append versus += and IMAGE_INSTALL confusion
On Thu, Mar 29, 2012 at 12:35 PM, Robert P. J. Day rpj...@crashcourse.ca wrote: On Thu, 29 Mar 2012, Eric Bénard wrote: Le Thu, 29 Mar 2012 15:23:20 -0400 (EDT), Robert P. J. Day rpj...@crashcourse.ca a écrit : so what is best practise here? for this one you have an answer on OE's wiki : http://www.openembedded.org/wiki/I_want_an_image_with_package_XYZ_installed despite the fact that the current reference manual *explicitly* says this? Using IMAGE_INSTALL with the += operator from the /conf/local.conf file or from within an image recipe is not recommended as it can cause ordering issues. i actually did my research before i asked that question, you know. The two aren't conflicting. The wiki page talks about creating an image or using bbappend, where += works fine. You have to use _append in local.conf because it's postponed, occurs at the end of the parse. If you use += there, the recipe will then set IMAGE_INSTALL, blowing away the global value you +='d to. -- Christopher Larson ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] argh ... _append versus += and IMAGE_INSTALL confusion
On Thu, 29 Mar 2012, Chris Larson wrote: On Thu, Mar 29, 2012 at 12:35 PM, Robert P. J. Day rpj...@crashcourse.ca wrote: On Thu, 29 Mar 2012, Eric Bénard wrote: Le Thu, 29 Mar 2012 15:23:20 -0400 (EDT), Robert P. J. Day rpj...@crashcourse.ca a écrit : so what is best practise here? for this one you have an answer on OE's wiki : http://www.openembedded.org/wiki/I_want_an_image_with_package_XYZ_installed despite the fact that the current reference manual *explicitly* says this? Using IMAGE_INSTALL with the += operator from the /conf/local.conf file or from within an image recipe is not recommended as it can cause ordering issues. i actually did my research before i asked that question, you know. The two aren't conflicting. The wiki page talks about creating an image or using bbappend, where += works fine. You have to use _append in local.conf because it's postponed, occurs at the end of the parse. If you use += there, the recipe will then set IMAGE_INSTALL, blowing away the global value you +='d to. i'm confused ... the current ref manual specifically (as you can read above) discourages the use of += from within an image recipe, which is *precisely* what the wiki page is advocating. so, yes, it *is* conflicting advice. 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
Re: [OE-core] DEPENDS not extended to -native for BBCLASSEXTENDS when added by PACKAGECONFIG
On Thu, Mar 29, 2012 at 06:10:46PM +0200, Andreas Müller wrote: Hi, on my colleagues's build machine ( Ubuntu 11.04 / Angstrom based / target overo / pullled all layers yesterday ) image building fails for gtk+native with | configure: error: *** libX11 not found. Check 'config.log' for more details. and in config.log | /usr/bin/ld: cannot find -lXrender Yes it does fail like this since PACKAGECONFIG was added to gtk+.. After manually building libxrender-native build continues without issues. Seems this issue is same as mentioned in [1] without result. Martin: how did you fix that on your environment? by this patchset for oe-core http://lists.linuxtogo.org/pipermail/openembedded-core/2012-March/019619.html and this for meta-oe http://lists.linuxtogo.org/pipermail/openembedded-devel/2012-March/038711.html both regulary updated in shr branches in oe-core-contrib/meta-oe-contrib Cheers, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] Fetch time optimization (svn : gcc/eglibc - git : linux-yocto)
Hi, I noticed in from scratch builds for qemuarm that the longest time is taken in fetching sources, especially those fetched using git (linux-yocto for example) svn (gcc, eglibc co). To reduce the fetch time would that make sense to - fetch gcc/glibc co from the archive of a stable version and then apply patches on top of it (maybe patches stored in an archive fetched from oe's website and applied in bulk or patches stored in OE) - do the same thing for the linux-yocto kernel or add a --reference option to the git fetcher so that we can provide a local tree as a reference ? Do you have other ideas (appart from using a local mirror) to optimize the fetch time ? Thanks, Eric ___ 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] runqemu: set console=ttyS0 when running with nographic option
On Thu, 2012-03-29 at 08:57 -0700, Scott Garman wrote: When passing the nograhic option to the runqemu script, set console=ttyS0 in the kernel options so the user can view the kernel boot messages. This fixes [YOCTO #1475] Signed-off-by: Scott Garman scott.a.gar...@intel.com --- scripts/runqemu |1 + 1 files changed, 1 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] gstreamer: Provide easy way to enable runtime debugging
On Thu, 2012-03-29 at 08:40 -0600, Gary Thomas wrote: The gstreamer framework has a very useful debugging setup which is essential for debugging pipelines and plugins. This patch makes it simple to enable this (disabled by default). To enable debugging, just add this line to local.conf GSTREAMER_DEBUG = --enable-debug Signed-off-by: Gary Thomas g...@mlbassoc.com --- .../gstreamer/gst-ffmpeg_0.10.13.bb|3 ++- meta/recipes-multimedia/gstreamer/gst-fluendo.inc |3 ++- meta/recipes-multimedia/gstreamer/gst-plugins.inc |3 ++- .../gstreamer/gstreamer_0.10.36.bb |3 ++- 4 files changed, 8 insertions(+), 4 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] libc-packgae.bbclass: Add i686 support in locale_arch_options
On Thu, 2012-03-29 at 11:48 +0500, Noor, Ahsan wrote: From: Noor Ahsan noor_ah...@mentor.com * While building for i686 architectre an error was coming that locale_arch_options does not have support for i686. Add missing support. * Verified on intel architecture. Signed-off-by: Noor Ahsan noor_ah...@mentor.com --- meta/classes/libc-package.bbclass |1 + 1 files changed, 1 insertions(+), 0 deletions(-) I merged this to master with the typo fixed. 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] license.bbclass: remove existing license.manifest before appending new data
On Thu, 2012-03-29 at 14:22 +0200, Eric Bénard wrote: without this fix, we append license each time we build again the same image, ending with a large not up to date file. Signed-off-by: Eric Bénard e...@eukrea.com --- meta/classes/license.bbclass |4 1 files changed, 4 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] pseudo failing with cc1: error: unrecognized command line option '-m32'
On Thu, Mar 29, 2012 at 11:57 AM, Peter Seebach peter.seeb...@windriver.com wrote: On Thu, 29 Mar 2012 11:53:23 -0700 Steve Sakoman sako...@gmail.com wrote: Clearly not something a sane person would do . . . Now that is a persuasive argument in favor of making it work if I've ever heard one! I'm doing too many things right now to fix this, but if you want to try to fix it, I'd be interested in seeing patches. I did a simple patch to omit the -m option on arm. The package now builds without error -- haven't run tested it yet . . . Steve ___ 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] ghostscript: fix parallel make issue
On Wed, 2012-03-28 at 17:41 +0800, Kang Kai wrote: [Yocto 1202] Update ghostscript-9.02-parallel-make.patch to fix parallel make failure. Bump up PR. Signed-off-by: Kang Kai kai.k...@windriver.com --- .../ghostscript-9.02-parallel-make.patch | 13 + .../ghostscript/ghostscript_9.05.bb|2 +- 2 files changed, 14 insertions(+), 1 deletions(-) Sadly the makefiles are littered with CP_ races. I've merged a patch which hopefully addresses them all rather than fixing them up one by one as they occur. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Fetch time optimization (svn : gcc/eglibc - git : linux-yocto)
On Thu, 2012-03-29 at 22:53 +0200, Eric Bénard wrote: I noticed in from scratch builds for qemuarm that the longest time is taken in fetching sources, especially those fetched using git (linux-yocto for example) svn (gcc, eglibc co). Are you timing these as fetches from the source control systems or from the mirror tarballs of the repositories. The tarballs should be faster... To reduce the fetch time would that make sense to - fetch gcc/glibc co from the archive of a stable version and then apply patches on top of it (maybe patches stored in an archive fetched from oe's website and applied in bulk or patches stored in OE) Unfortunately the patches tend to get unwieldy. The tarballs of the svn repos on the mirror should be about equal in size to the upstream archive in this case. - do the same thing for the linux-yocto kernel or add a --reference option to the git fetcher so that we can provide a local tree as a reference ? This is effectively how the repositories in DL_DIR are used. If you place a tree in the right place there, it should reuse references... Do you have other ideas (appart from using a local mirror) to optimize the fetch time ? I'd be interested firstly to understand if you're using the SCM directly or using the mirror tarballs as that should make a big difference. In the standard configuration it should be using mirror tarballs... Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/1] genext2fs: support large files and filesystems without using large amounts of memor
On Thu, 2012-03-29 at 00:51 +0800, Dexuan Cui wrote: Hi RP, Saul, Paul, Darren, Mark, Josh and joaohf and all, please comment. Let's figure out if this big patch is accepatable or not... With this patch, I can successfully create a 8.5GB .ext3 file with genext2fs. The speed is slow -- I spent about 1.5 hours. If these patches solved all the problems and made things work wonderfully I'd probably say we'd take them. Unfortunately I don't consider taking 1.5 hours to build am 8GB filesystem wonderful, its rather worrying and I don't think its performing any where need fast enough for our needs :(. Patching genext2fs at this point in the cycle is a rather risky undertaking too and I'm getting very concerned about this. We might have to look at alternative ways to solve this problem. I think Darren said he might help look at this and has some other ideas. Darren? Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/1] genext2fs: support large files and filesystems without using large amounts of memor
On Thu, Mar 29, 2012 at 5:07 PM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Thu, 2012-03-29 at 00:51 +0800, Dexuan Cui wrote: Hi RP, Saul, Paul, Darren, Mark, Josh and joaohf and all, please comment. Let's figure out if this big patch is accepatable or not... With this patch, I can successfully create a 8.5GB .ext3 file with genext2fs. The speed is slow -- I spent about 1.5 hours. If these patches solved all the problems and made things work wonderfully I'd probably say we'd take them. Unfortunately I don't consider taking 1.5 hours to build am 8GB filesystem wonderful, its rather worrying and I don't think its performing any where need fast enough for our needs :(. Patching genext2fs at this point in the cycle is a rather risky undertaking too and I'm getting very concerned about this. We might have to look at alternative ways to solve this problem. I think Darren said he might help look at this and has some other ideas. Darren? Can fuse offer some option here? -M ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] Remove redundant reference to task-self-hosted from self-hosted-image.bb
This recipe already includes task-self-hosted in the IMAGE_INSTALL
line:
IMAGE_INSTALL = task-core-boot task-core-apps-console task-core-ssh-openssh
task-self-hosted
so there's no apparent need to include it again further down.
Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca
---
diff --git a/meta/recipes-core/images/self-hosted-image.bb
b/meta/recipes-core/images/self-hosted-image.bb
index 5aa670d..f1f3e57 100644
--- a/meta/recipes-core/images/self-hosted-image.bb
+++ b/meta/recipes-core/images/self-hosted-image.bb
@@ -6,10 +6,6 @@ LIC_FILES_CHKSUM =
file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3
PR = r6
-CORE_IMAGE_EXTRA_INSTALL = \
-task-self-hosted \
-
-
IMAGE_FEATURES += x11-mini package-management
# Ensure there's enough space to do a core-image-minimal build, with rm_work
enabled
--
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
Re: [OE-core] [PATCH 0/1] genext2fs: support large files and filesystems without using large amounts of memor
On 03/29/2012 03:07 PM, Richard Purdie wrote: On Thu, 2012-03-29 at 00:51 +0800, Dexuan Cui wrote: Hi RP, Saul, Paul, Darren, Mark, Josh and joaohf and all, please comment. Let's figure out if this big patch is accepatable or not... With this patch, I can successfully create a 8.5GB .ext3 file with genext2fs. The speed is slow -- I spent about 1.5 hours. If these patches solved all the problems and made things work wonderfully I'd probably say we'd take them. Unfortunately I don't consider taking 1.5 hours to build am 8GB filesystem wonderful, its rather worrying and I don't think its performing any where need fast enough for our needs :(. Patching genext2fs at this point in the cycle is a rather risky undertaking too and I'm getting very concerned about this. We might have to look at alternative ways to solve this problem. I think Darren said he might help look at this and has some other ideas. Darren? Without having looked into this very far, I seem to recall this was generating sparse files. This means every time we copy something into the filesystem it has to allocate the space on the drive. This is great for building big filesystems that will be mostly empty - but for big filesystems that we plan to mostly populate, I believe we would be better off doing pre-allocation (I'm taking this from my experience creating VMs in virtmanager). However, since using dd to create the file would require mounting it in order to copy files across (and we want to avoid requiring root permissions during build), this may not be an option. Have we tried without the -z option? (-z allows holes in files - I presume this means sparse files). Depending on how much of the 8.5 GB image we are filling, we may get a significant speed increase by first generating a smaller image and then using resize2fs to grow it to the desired size (referencing http://landley.livejournal.com/47024.html). A quick test without passing an initial rootfs showed no difference between -z and no -z. It may still be worth trying with the actual population to see if that makes a difference. -- 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] license.bbclass: remove existing license.manifest before appending new data
On Thu, Mar 29, 2012 at 5:22 AM, Eric Bénard e...@eukrea.com wrote:
without this fix, we append license each time we build again the same image,
ending with a large not up to date file.
Signed-off-by: Eric Bénard e...@eukrea.com
---
meta/classes/license.bbclass | 4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/meta/classes/license.bbclass b/meta/classes/license.bbclass
index 394a6d4..c85233c 100644
--- a/meta/classes/license.bbclass
+++ b/meta/classes/license.bbclass
@@ -79,6 +79,10 @@ license_create_manifest() {
# Get list of installed packages
list_installed_packages | grep -v locale |sort
${LICENSE_DIRECTORY}/${IMAGE_NAME}/package.manifest
INSTALLED_PKGS=`cat
${LICENSE_DIRECTORY}/${IMAGE_NAME}/package.manifest`
+ # remove existing license.manifest file
+ if [ -f ${LICENSE_DIRECTORY}/${IMAGE_NAME}/license.manifest ]; then
+ rm ${LICENSE_DIRECTORY}/${IMAGE_NAME}/license.manifest
+ fi
# list of installed packages is broken for deb
Probably not a concern in this particular case, but in general you
should avoid this sort of construct, as it's racy.
--
Christopher Larson
___
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] virtual/libgl: switch back to mesa-xlib for qemuarm/qemumips
On Thu, Mar 29, 2012 at 08:54:59AM +0800, Zhai, Edwin wrote: On Wed, Mar 28, 2012 at 12:34:43PM +0100, Richard Purdie wrote: I'd like to understand why dri can't work under qemu too though. I think this requires: emulated graphic HW capability in qemumips/qemuarm, and an drm driver to match the emulated HW. With them, we can turn on enable-dri for mesa-dri and fight the build issue. Sorry, I mean Xfbdev. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core -- best rgds, edwin ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core -- best rgds, edwin ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Fetch time optimization (svn : gcc/eglibc - git : linux-yocto)
On Thu, Mar 29, 2012 at 6:03 PM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Thu, 2012-03-29 at 22:53 +0200, Eric Bénard wrote: I noticed in from scratch builds for qemuarm that the longest time is taken in fetching sources, especially those fetched using git (linux-yocto for example) svn (gcc, eglibc co). Are you timing these as fetches from the source control systems or from the mirror tarballs of the repositories. The tarballs should be faster... To reduce the fetch time would that make sense to - fetch gcc/glibc co from the archive of a stable version and then apply patches on top of it (maybe patches stored in an archive fetched from oe's website and applied in bulk or patches stored in OE) Unfortunately the patches tend to get unwieldy. The tarballs of the svn repos on the mirror should be about equal in size to the upstream archive in this case. - do the same thing for the linux-yocto kernel or add a --reference option to the git fetcher so that we can provide a local tree as a reference ? This is effectively how the repositories in DL_DIR are used. If you place a tree in the right place there, it should reuse references... Agreed .. they definitely do here. Richard probably recalls me asking for a --reference option several years ago as well .. but in the end, at some point the initial fetch happens and then the blobs are re-used. So setting up local mirrors, or pre-fetching are options to make sure that the first download is primed and ready to go. For most builds I do, any time fetching just happens in the background and doesn't get in the way. Do you have other ideas (appart from using a local mirror) to optimize the fetch time ? I'd be interested firstly to understand if you're using the SCM directly or using the mirror tarballs as that should make a big difference. In the standard configuration it should be using mirror tarballs... As would I, since there are some ideas, but they either break workflows, don't follow best practices or compromise the completeness of the data. Cheers, Bruce Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core -- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gstreamer: Provide easy way to enable runtime debugging
Op 29 mrt. 2012, om 14:19 heeft Richard Purdie het volgende geschreven: On Thu, 2012-03-29 at 08:40 -0600, Gary Thomas wrote: The gstreamer framework has a very useful debugging setup which is essential for debugging pipelines and plugins. This patch makes it simple to enable this (disabled by default). To enable debugging, just add this line to local.conf GSTREAMER_DEBUG = --enable-debug Signed-off-by: Gary Thomas g...@mlbassoc.com --- .../gstreamer/gst-ffmpeg_0.10.13.bb|3 ++- meta/recipes-multimedia/gstreamer/gst-fluendo.inc |3 ++- meta/recipes-multimedia/gstreamer/gst-plugins.inc |3 ++- .../gstreamer/gstreamer_0.10.36.bb |3 ++- 4 files changed, 8 insertions(+), 4 deletions(-) Merged to master, thanks. Awesome, more magic variables. Where's the matching documentation for this one? And why isn't this using PACKAGE_CONFIG? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] virtual/libgl: use mesa-xlib for qemuarm/qemumips/qemuppc
From: Zhai Edwin edwin.z...@intel.com Still need mesa-xlib for emulation of GLX interface on qemuarm/mips/ppc, where mesa-dri doesn't work for pure qemu emulator. [YOCTO #2066] fixed. Signed-off-by: Zhai Edwin edwin.z...@intel.com --- meta/conf/machine/include/qemu.inc |1 + meta/conf/machine/qemux86-64.conf |1 + meta/conf/machine/qemux86.conf |1 + 3 files changed, 3 insertions(+), 0 deletions(-) diff --git a/meta/conf/machine/include/qemu.inc b/meta/conf/machine/include/qemu.inc index 10ab76e..4ca4753 100644 --- a/meta/conf/machine/include/qemu.inc +++ b/meta/conf/machine/include/qemu.inc @@ -1,5 +1,6 @@ PCMCIA_MANAGER = pcmciautils PREFERRED_PROVIDER_virtual/xserver ?= xserver-kdrive +PREFERRED_PROVIDER_virtual/libgl ?= mesa-xlib MACHINE_FEATURES = apm alsa pcmcia bluetooth irda usbgadget screen diff --git a/meta/conf/machine/qemux86-64.conf b/meta/conf/machine/qemux86-64.conf index 73a4043..129fe9f 100644 --- a/meta/conf/machine/qemux86-64.conf +++ b/meta/conf/machine/qemux86-64.conf @@ -3,6 +3,7 @@ #@DESCRIPTION: Machine configuration for running a common x86 PREFERRED_PROVIDER_virtual/xserver ?= xserver-xorg +PREFERRED_PROVIDER_virtual/libgl ?= mesa-dri require conf/machine/include/tune-x86_64.inc require conf/machine/include/qemu.inc diff --git a/meta/conf/machine/qemux86.conf b/meta/conf/machine/qemux86.conf index 3edfe29..246d5a0 100644 --- a/meta/conf/machine/qemux86.conf +++ b/meta/conf/machine/qemux86.conf @@ -3,6 +3,7 @@ #@DESCRIPTION: Machine configuration for running a common x86 PREFERRED_PROVIDER_virtual/xserver ?= xserver-xorg +PREFERRED_PROVIDER_virtual/libgl ?= mesa-dri require conf/machine/include/tune-i586.inc require conf/machine/include/qemu.inc -- 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 GL failure on qemuarm/mips/ppc, V2, Mar32, 2012
From: Zhai Edwin edwin.z...@intel.com This is the V2 version after Martin and RP's comments: no COMPATIBLE_MACHINE, and no change for global default preferred virtual/libgl. Pls. review. Thanks, Edwin The following changes since commit 265903bdffb10c95ceaf7a892151a50b67939c71: procps: don't print error message with kernel 3.0+ (2012-03-28 10:16:30 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib gzhai/fix2 http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=gzhai/fix2 Zhai Edwin (1): virtual/libgl: use mesa-xlib for qemuarm/qemumips/qemuppc meta/conf/machine/include/qemu.inc |1 + meta/conf/machine/qemux86-64.conf |1 + meta/conf/machine/qemux86.conf |1 + 3 files changed, 3 insertions(+), 0 deletions(-) -- 1.7.5.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] qt4-x11-free: enable -accessibility and -sm
Is it possible to enable the -sm -accessibility in oe-core, please?
There is a meta-kde layer which requires the -sm -accessibility, but
they are disabled in meta/recipes-qt/qt4/qt4.inc:
QT_DISTRO_FLAGS ?= -no-accessibility -no-sm
I checked the log of the qt4, can't find the related log for
-no-accessibility -no-sm.
Another way is use the bbappend, but it would be great if it can be
enabled in oe-core.
This only enables for qt4-x11, doesn't enable for qt4-embedded, and
have done testing on: qemux86, qemuarm, qemumips, qemuppc.
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
meta/recipes-qt/qt4/qt4-x11-free.inc |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/meta/recipes-qt/qt4/qt4-x11-free.inc
b/meta/recipes-qt/qt4/qt4-x11-free.inc
index 072c522..a59198d 100644
--- a/meta/recipes-qt/qt4/qt4-x11-free.inc
+++ b/meta/recipes-qt/qt4/qt4-x11-free.inc
@@ -13,6 +13,9 @@ QT_GLFLAGS_qemuppc = -opengl
QT_CONFIG_FLAGS += -no-xinerama -no-xkb
QT_BASE_LIB ?= libqt
+# required by kdelibs4
+QT_DISTRO_FLAGS = -accessibility -sm
+
inherit qt4x11
do_install_append() {
--
1.7.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] qt4-x11-free: enable -accessibility and -sm
The following changes since commit c8afc79b5d3205355ad61d2589221bf8babe8395: libc-packgae.bbclass: Add i686 support in locale_arch_options (2012-03-29 22:22:58 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib robert/qt4 http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=robert/qt4 Robert Yang (1): qt4-x11-free: enable -accessibility and -sm meta/recipes-qt/qt4/qt4-x11-free.inc |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
