Re: [OE-core] [PATCH 6/8] xcb-util: upgrade from 0.3.6 to 0.3.8
On Wed, Nov 30, 2011 at 10:12:32PM +0800, Dexuan Cui wrote: updated LIC_FILES_CHKSUM since the code was re-organized, but the license remains the same. Signed-off-by: Dexuan Cui dexuan@intel.com --- meta/recipes-graphics/xcb/xcb-util_0.3.6.bb | 18 -- meta/recipes-graphics/xcb/xcb-util_0.3.8.bb |9 + 2 files changed, 9 insertions(+), 18 deletions(-) delete mode 100644 meta/recipes-graphics/xcb/xcb-util_0.3.6.bb create mode 100644 meta/recipes-graphics/xcb/xcb-util_0.3.8.bb Because there is only one .so lib now after: http://cgit.freedesktop.org/xcb/util/commit/?id=118a3c86b3d3b2fab20f365e4a5703e40ad2e1b1 the resulting package is renamed from Package xcb-util (0.3.6-r0) is installed on root and has the following files: /usr/lib/libxcb-aux.so.0 /usr/lib/libxcb-keysyms.so.1 /usr/lib/libxcb-icccm.so.1 /usr/lib/libxcb-image.so.0.0.0 /usr/lib/libxcb-atom.so.1.0.0 /usr/lib/libxcb-icccm.so.1.0.0 /usr/lib/libxcb-event.so.1 /usr/lib/libxcb-reply.so.1.0.0 /usr/lib/libxcb-property.so.1.0.0 /usr/lib/libxcb-render-util.so.0.0.0 /usr/lib/libxcb-property.so.1 /usr/lib/libxcb-reply.so.1 /usr/lib/libxcb-image.so.0 /usr/lib/libxcb-atom.so.1 /usr/lib/libxcb-event.so.1.0.0 /usr/lib/libxcb-render-util.so.0 /usr/lib/libxcb-aux.so.0.0.0 /usr/lib/libxcb-keysyms.so.1.0.0 Now it's libxcb-util0, because of only one .so packages-split/xcb-util packages-split/xcb-util/usr packages-split/xcb-util/usr/lib packages-split/xcb-util/usr/lib/libxcb-util.so.0.0.0 packages-split/xcb-util/usr/lib/libxcb-util.so.0 So we need at least PR bumps for recipes which were RDEPENDing on xcb-util (ie because of shlibs). I'll send patches later for recipes which are failing for me now.. Cheers, diff --git a/meta/recipes-graphics/xcb/xcb-util_0.3.6.bb b/meta/recipes-graphics/xcb/xcb-util_0.3.6.bb deleted file mode 100644 index 1057b34..000 --- a/meta/recipes-graphics/xcb/xcb-util_0.3.6.bb +++ /dev/null @@ -1,18 +0,0 @@ -require xcb-util.inc - -LICENSE = MIT -LIC_FILES_CHKSUM = file://xcb-util-common.h;endline=30;md5=6c74595925fd773cc8cf387ff7bc53c7 \ - file://reply/reply.c;endline=27;md5=f9a1d6b55bba632d349949cbf33cd635 \ - file://aux/xcb_aux.c;endline=30;md5=ae305b9c2a38f9ba27060191046a6460 \ - file://renderutil/xcb_renderutil.h;endline=24;md5=d0ddab3052dd4949c93cfcb0891c96df \ - file://event/xcb_event.h;endline=27;md5=627be355aee59e1b8ade80d5bd90fad9 \ - file://property/xcb_property.h;endline=27;md5=f5890866ee0c655c36ef1c6c738fee6b \ - file://keysyms/keysyms.c;endline=30;md5=2f8de023ed823bb92f0b47900574ea9e \ - file://image/xcb_pixel.h;beginline=4;endline=27;md5=48cd25ae55e7de525fe1e1a3a7672e1c - - -PR = r0 - - -SRC_URI[md5sum] = dd8968b8ee613cb027a8ef1fcbdc8fc9 -SRC_URI[sha256sum] = ffb8ee11ab015858a970ab7edd56bd2436b281657596561d8429d4a90df60e57 diff --git a/meta/recipes-graphics/xcb/xcb-util_0.3.8.bb b/meta/recipes-graphics/xcb/xcb-util_0.3.8.bb new file mode 100644 index 000..b7eff29 --- /dev/null +++ b/meta/recipes-graphics/xcb/xcb-util_0.3.8.bb @@ -0,0 +1,9 @@ +require xcb-util.inc + +LICENSE = MIT +LIC_FILES_CHKSUM = file://src/xcb_aux.c;endline=30;md5=ae305b9c2a38f9ba27060191046a6460 \ + file://src/xcb_event.h;endline=27;md5=627be355aee59e1b8ade80d5bd90fad9 +PR = r0 + +SRC_URI[md5sum] = 8ce019c4bbf20dce246b98f177cfccff +SRC_URI[sha256sum] = c1eed9284750bc09352e60654df77bb585dbbe7673fdcc675e58b7f3a0b447b9 -- 1.7.6 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH][oe-core 2/3] matchbox-panel-2: bump PR, because of xcb-util was renamed to libxcb-util0
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
.../matchbox-panel-2/matchbox-panel-2_git.bb |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-sato/matchbox-panel-2/matchbox-panel-2_git.bb
b/meta/recipes-sato/matchbox-panel-2/matchbox-panel-2_git.bb
index c1da0cf..41ba8e1 100644
--- a/meta/recipes-sato/matchbox-panel-2/matchbox-panel-2_git.bb
+++ b/meta/recipes-sato/matchbox-panel-2/matchbox-panel-2_git.bb
@@ -13,7 +13,7 @@ DEPENDS += ${@base_contains(MACHINE_FEATURES, apm,
apmd, ,d)}
SRCREV = cdf7a22716b87468f10573f622d5c7a58a684e35
PV = 0.0+git${SRCPV}
-PR = r0
+PR = r1
RPROVIDES_${PN} = matchbox-panel
RREPLACES_${PN} = matchbox-panel
--
1.7.8.rc4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH][oe-core 3/3] matchbox-panel-2: add unpackaged .la files to PN-dev to fix QA warning
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
.../matchbox-panel-2/matchbox-panel-2_git.bb |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-sato/matchbox-panel-2/matchbox-panel-2_git.bb
b/meta/recipes-sato/matchbox-panel-2/matchbox-panel-2_git.bb
index 41ba8e1..78111f7 100644
--- a/meta/recipes-sato/matchbox-panel-2/matchbox-panel-2_git.bb
+++ b/meta/recipes-sato/matchbox-panel-2/matchbox-panel-2_git.bb
@@ -13,7 +13,7 @@ DEPENDS += ${@base_contains(MACHINE_FEATURES, apm,
apmd, ,d)}
SRCREV = cdf7a22716b87468f10573f622d5c7a58a684e35
PV = 0.0+git${SRCPV}
-PR = r1
+PR = r2
RPROVIDES_${PN} = matchbox-panel
RREPLACES_${PN} = matchbox-panel
@@ -32,5 +32,6 @@ FILES_${PN} += ${libdir}/matchbox-panel/*.so \
${datadir}/matchbox-panel/brightness/*.png \
${datadir}/matchbox-panel/startup/*.png
FILES_${PN}-dbg += ${libdir}/matchbox-panel/.debug
+FILES_${PN}-dev += ${libdir}/matchbox-panel/*.la
inherit autotools pkgconfig
--
1.7.8.rc4
___
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 some recipes check upstream version issue
Hi all, Some recipes(like rt-tests,clutter-box2d,iproute2) didn't check the right upstream version because lack of protocal declaration. Fix this by add their upstream protocal at the end of SRC_URI. Thanks, Lei The following changes since commit f4efaa0f472b4bf0ba0a0297cc9ecc8b5a671f72: Martin Jansa (1): squashfs-tools: fix PR, those should start with 'r' are available in the git repository at: git://git.pokylinux.org/poky-contrib lmei3/fix-upver-check http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=lmei3/fix-upver-check Mei Lei (1): Fix some recipes upstream version check issue .../iproute2/iproute2_3.1.0.bb |2 +- meta/recipes-graphics/clutter/clutter-box2d_git.bb |2 +- meta/recipes-rt/rt-tests/rt-tests_0.83.bb |2 +- 3 files changed, 3 insertions(+), 3 deletions(-) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] Fix some recipes upstream version check issue
Some recipes didn't declare what protocal they use to check the upstream
version, this will due to some errors.
Fix this by add the protocal at the end of the SRC_URI.
Signed-off-by: Mei Lei lei@intel.com
---
.../iproute2/iproute2_3.1.0.bb |2 +-
meta/recipes-graphics/clutter/clutter-box2d_git.bb |2 +-
meta/recipes-rt/rt-tests/rt-tests_0.83.bb |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-connectivity/iproute2/iproute2_3.1.0.bb
b/meta/recipes-connectivity/iproute2/iproute2_3.1.0.bb
index 0b47046..52e40e1 100644
--- a/meta/recipes-connectivity/iproute2/iproute2_3.1.0.bb
+++ b/meta/recipes-connectivity/iproute2/iproute2_3.1.0.bb
@@ -2,7 +2,7 @@ require iproute2.inc
#v3.1.0 tag
SRCREV = 9cbe6bc337a35b91882f92599eefeb161f3e776e
-SRC_URI =
git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git \
+SRC_URI =
git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git;protocol=git
\
file://configure-cross.patch
S = ${WORKDIR}/git
diff --git a/meta/recipes-graphics/clutter/clutter-box2d_git.bb
b/meta/recipes-graphics/clutter/clutter-box2d_git.bb
index 554ce81..7a1dc8e 100644
--- a/meta/recipes-graphics/clutter/clutter-box2d_git.bb
+++ b/meta/recipes-graphics/clutter/clutter-box2d_git.bb
@@ -6,7 +6,7 @@ SRCREV = de5452e56b537a11fd7f9453d048ff4b4793b5a2
PV = 0.12.1+git${SRCPV}
PR = r0
-SRC_URI = git://git.gnome.org/clutter-box2d.git
+SRC_URI = git://git.gnome.org/clutter-box2d.git;protocol=git
S = ${WORKDIR}/git
diff --git a/meta/recipes-rt/rt-tests/rt-tests_0.83.bb
b/meta/recipes-rt/rt-tests/rt-tests_0.83.bb
index 78d51b3..7e64032 100644
--- a/meta/recipes-rt/rt-tests/rt-tests_0.83.bb
+++ b/meta/recipes-rt/rt-tests/rt-tests_0.83.bb
@@ -12,7 +12,7 @@ SRCREV = 5f1e84f8b015df3ff950056494134eca3f640d70
# git - 0.83 needs a PE bump
PE = 1
-SRC_URI = git://github.com/clrkwllms/rt-tests.git
+SRC_URI = git://github.com/clrkwllms/rt-tests.git;protocol=git
S = ${WORKDIR}/git
--
1.7.0.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/3] make: expand MAKEFLAGS before we re-exec after rebuilding makefiles.
This patch was got from the upstream cvs repo of make to fix the bug of make-3.82: http://savannah.gnu.org/bugs/?30723 Signed-off-by: Dexuan Cui dexuan@intel.com --- .../make/make-3.82/expand_MAKEFLAGS.patch | 39 meta/recipes-devtools/make/make_3.82.bb|4 ++- 2 files changed, 42 insertions(+), 1 deletions(-) create mode 100644 meta/recipes-devtools/make/make-3.82/expand_MAKEFLAGS.patch diff --git a/meta/recipes-devtools/make/make-3.82/expand_MAKEFLAGS.patch b/meta/recipes-devtools/make/make-3.82/expand_MAKEFLAGS.patch new file mode 100644 index 000..4184937 --- /dev/null +++ b/meta/recipes-devtools/make/make-3.82/expand_MAKEFLAGS.patch @@ -0,0 +1,39 @@ +Upstream-Status: Inappropriate [The fix is already in upstream cvs repo, but not in the stable release] + +When working on the self-hosted-image work, I found in the target +bitbake eglibc-initial -c install always failed: + +make[1]: Entering directory `/raid/pe2/build/tmp/work/i586-poky-linux/eglibc-initial-2.13-r18+svnr14157/eglibc-2_13/libc' +/usr/bin/install -c -m 644 include/limits.h /usr/include/limits.h +/usr/bin/install: cannot remove `/usr/include/limits.h': Permission denied +make[1]: *** [/usr/include/limits.h] Error 1 +make[1]: Leaving directory `/raid/pe2/build/tmp/work/i586-poky-linux/eglibc-initial-2.13-r18+svnr14157/eglibc-2_13/libc' +make: *** [install-headers] Error 2 +ERROR: oe_runmake faile + +Debugging shows the install_root variable in eglibc's makefiles is strangely +reset at some place. + +Further investigation shows this is a bug of make-3.82: + +http://savannah.gnu.org/bugs/?30723 +http://cvs.savannah.gnu.org/viewvc/make/main.c?root=maker1=1.243r2=1.244 +http://old.nabble.com/-bug--30723--implicit-re-executing-of-subdirs-breaks-$(origin)-with-make-3.82-td29394353.html + +The patch was got from the second link above(the upstream cvs repo of make). + +Thu Dec 1 16:05:59 CST 2011 +Signed-off-by: Dexuan Cui dexuan@intel.com + +diff -Nru make-3.82.orig//main.c make-3.82/main.c +--- make-3.82.orig//main.c 2010-07-19 15:10:53.0 +0800 make-3.82/main.c 2011-12-01 16:04:11.818522186 +0800 +@@ -2093,7 +2093,7 @@ + const char *pv = define_makeflags (1, 1); + char *p = alloca (sizeof (MAKEFLAGS=) + strlen (pv) + 1); + sprintf (p, MAKEFLAGS=%s, pv); +-putenv (p); ++putenv (allocated_variable_expand (p)); + } + + if (ISDB (DB_BASIC)) diff --git a/meta/recipes-devtools/make/make_3.82.bb b/meta/recipes-devtools/make/make_3.82.bb index 61fbb32..bea3339 100644 --- a/meta/recipes-devtools/make/make_3.82.bb +++ b/meta/recipes-devtools/make/make_3.82.bb @@ -1,8 +1,10 @@ -PR = r0 +PR = r1 LICENSE=GPLv3LGPLv2 LIC_FILES_CHKSUM = file://tests/COPYING;md5=d32239bcb673463ab874e80d47fae504 \ file://glob/COPYING.LIB;md5=4a770b67e6be0f60da244beb2de0fce4 require make.inc +SRC_URI += file://expand_MAKEFLAGS.patch + SRC_URI[md5sum] = 1a11100f3c63fcf5753818e59d63088f SRC_URI[sha256sum] = e2c1a73f179c40c71e2fe8abf8a8a0688b8499538512984da4a76958d0402966 -- 1.7.6 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/3] 3 new patches for the self-hosted-image work
The following changes since commit d7cd934376ae1edaf7055ec635eb3c85fdbf58b3: squashfs-tools: fix PR, those should start with 'r' (2011-11-30 23:37:44 +) are available in the git repository at: git://git.pokylinux.org/poky-contrib dcui/self-hosted-v4 http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dcui/self-hosted-v4 Dexuan Cui (3): make: expand MAKEFLAGS before we re-exec after rebuilding makefiles. task-self-hosted: install sudo, tun.ko, iptables, libgl and libgl-dev into the target runqemu-ifup, runqemu-internal: be wiser when locating the network tools meta/recipes-core/tasks/task-self-hosted.bb| 14 +-- .../make/make-3.82/expand_MAKEFLAGS.patch | 39 meta/recipes-devtools/make/make_3.82.bb|4 ++- scripts/runqemu-ifup |8 +++-- scripts/runqemu-internal |3 +- 5 files changed, 59 insertions(+), 9 deletions(-) create mode 100644 meta/recipes-devtools/make/make-3.82/expand_MAKEFLAGS.patch -- 1.7.6 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/3] task-self-hosted: install sudo, tun.ko, iptables, libgl and libgl-dev into the target
sudo, kernel-module-tun and iptables are needed by runqemu.
strace has appeared in RDEPENDS_task-self-hosted-debug, so let's remove it
from RDEPENDS_task-self-hosted-extended.
install libglu and libgl-dev rather than mesa-dri and mesa-dri-dev due to the
recent commit mesa: package gl/egl/osmesa to separate packages.
Signed-off-by: Dexuan Cui dexuan@intel.com
Signed-off-by: Zhai Edwin edwin.z...@intel.com
---
meta/recipes-core/tasks/task-self-hosted.bb | 14 ++
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-core/tasks/task-self-hosted.bb
b/meta/recipes-core/tasks/task-self-hosted.bb
index c218f43..b3a68b4 100644
--- a/meta/recipes-core/tasks/task-self-hosted.bb
+++ b/meta/recipes-core/tasks/task-self-hosted.bb
@@ -3,7 +3,7 @@
#
DESCRIPTION = Create Basic Image Tasks
-PR = r0
+PR = r1
LICENSE = MIT
LIC_FILES_CHKSUM =
file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420
@@ -142,8 +142,8 @@ RDEPENDS_task-self-hosted-extended = \
rpm \
screen \
setserial \
-strace \
subversion \
+sudo \
sysstat \
tar \
gzip \
@@ -159,13 +159,19 @@ RDEPENDS_task-self-hosted-extended = \
zip \
zlib \
cpio \
+iptables \
+kernel-module-tun \
+kernel-module-iptable-raw \
+kernel-module-iptable-nat \
+kernel-module-iptable-mangle \
+kernel-module-iptable-filter \
RDEPENDS_task-self-hosted-graphics = \
python-pygtk \
-mesa-dri \
-mesa-dri-dev \
+libgl \
+libgl-dev \
libglu \
libglu-dev \
libsdl \
--
1.7.6
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/3] runqemu-ifup, runqemu-internal: be wiser when locating the network tools
When working on the self-hosted-image work, I found the PATH variable in the
Level-1 target doesn't have /sbin and /usr/sbin, so runqemu can't
run properly since the tools are installeld at
/sbin/ifconfig
/sbin/route
/usr/sbin/iptables
The patch is used to fix the issue by setting a temp PATH when running which.
Signed-off-by: Dexuan Cui dexuan@intel.com
---
scripts/runqemu-ifup |8 +---
scripts/runqemu-internal |3 ++-
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/scripts/runqemu-ifup b/scripts/runqemu-ifup
index 870cb6b..9e697a8 100755
--- a/scripts/runqemu-ifup
+++ b/scripts/runqemu-ifup
@@ -64,7 +64,9 @@ if [ $STATUS -ne 0 ]; then
exit 1
fi
-IFCONFIG=`which ifconfig 2 /dev/null`
+PATH_TMP=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
+
+IFCONFIG=`{ PATH=$PATH:$PATH_TMP; which ifconfig 2 /dev/null; }`
if [ x$IFCONFIG = x ]; then
# better than nothing...
IFCONFIG=/sbin/ifconfig
@@ -74,7 +76,7 @@ if [ ! -x $IFCONFIG ]; then
exit 1
fi
-ROUTE=`which route`
+ROUTE=`{ PATH=$PATH:$PATH_TMP; which route 2/dev/null; }`
if [ x$ROUTE = x ]; then
# better than nothing...
ROUTE=/sbin/route
@@ -84,7 +86,7 @@ if [ ! -x $ROUTE ]; then
exit 1
fi
-IPTABLES=`which iptables 2 /dev/null`
+IPTABLES=`{ PATH=$PATH:$PATH_TMP; which iptables 2 /dev/null; }`
if [ x$IPTABLES = x ]; then
IPTABLES=/sbin/iptables
fi
diff --git a/scripts/runqemu-internal b/scripts/runqemu-internal
index 2968ed9..3214fde 100755
--- a/scripts/runqemu-internal
+++ b/scripts/runqemu-internal
@@ -141,7 +141,8 @@ if [ ! -d $LOCKDIR ]; then
chmod 777 $LOCKDIR
fi
-IFCONFIG=`which ifconfig 2 /dev/null`
+PATH_TMP=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
+IFCONFIG=`{ PATH=$PATH:$PATH_TMP; which ifconfig 2 /dev/null; }`
if [ -z $IFCONFIG ]; then
IFCONFIG=/sbin/ifconfig
fi
--
1.7.6
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] Fix some recipes upstream version check issue
Op 1 dec. 2011, om 09:54 heeft Mei Lei het volgende geschreven: Some recipes didn't declare what protocal they use to check the upstream version, this will due to some errors. Fix this by add the protocal at the end of the SRC_URI. Signed-off-by: Mei Lei lei@intel.com Which version of bitbake are you usung? IIRC the default was changed from rsync to git a few weeks ago. regards, Koen signature.asc Description: Message signed with OpenPGP using GPGMail ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Feedback on building openembedded-core for qemuarm. Excerpts from buildlog
On Wed, 2011-11-30 at 17:52 -0800, Khem Raj wrote: On (29/11/11 16:03), Richard Purdie wrote: Assuming your statement is true, why isn't the hash style fixed in the .inc? Meta-oe uses the ones from OE-core, so if the include files are sane, the toolchain for meta-oe is sane. Its fixed by a patch so someone needs to backport that patch to the gcc 4.5 patch set. I have intentionally not ported the patch back to 4.5 but let me see if I can find some spare hours Don't take my comments as a request to do so btw, personally speaking I don't see it as a problem. I just wanted to be clear about what was missing. 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][oe-core 1/2] gst-plugins-good: bump PR for gdbm SOVERSION change
On Thu, 2011-12-01 at 08:00 +0100, Martin Jansa wrote: Signed-off-by: Martin Jansa martin.ja...@gmail.com --- .../gstreamer/gst-plugins-good_0.10.30.bb |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Merged to master (along with 2/2), 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][oe-core 1/3] startup-notification: bump PR, because of xcb-util was renamed to libxcb-util0
On Thu, 2011-12-01 at 09:46 +0100, Martin Jansa wrote: Signed-off-by: Martin Jansa martin.ja...@gmail.com --- .../startup-notification_0.12.bb |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Merged to master (along with patches 2 and 3), thanks. Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC 3/4] pulseaudio 1.1: convert to useradd.bbclass
Op 29 nov. 2011, om 22:25 heeft Koen Kooi het volgende geschreven: The only thing that got lost in the conversion is the Pulse Audio daemon description: root@beagleboard:~# grep pulse /etc/passwd /etc/group /etc/passwd:pulse:x:999:1000::/var/run/pulse:/bin/false /etc/group:audio:x:29:pulse /etc/group:pulse:x:1000:pulse Signed-off-by: Koen Kooi k...@dominion.thruhere.net No objections in the past 2 days, so I guess it's ready to go in. I'll send a rebased v2 in a minute. regards, Koen signature.asc Description: Message signed with OpenPGP using GPGMail ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] make: expand MAKEFLAGS before we re-exec after rebuilding makefiles.
On Thu, 2011-12-01 at 10:22 +0100, Koen Kooi wrote: Op 1 dec. 2011, om 10:21 heeft Dexuan Cui het volgende geschreven: This patch was got from the upstream cvs repo of make to fix the bug of make-3.82: http://savannah.gnu.org/bugs/?30723 Signed-off-by: Dexuan Cui dexuan@intel.com --- .../make/make-3.82/expand_MAKEFLAGS.patch | 39 meta/recipes-devtools/make/make_3.82.bb|4 ++- 2 files changed, 42 insertions(+), 1 deletions(-) create mode 100644 meta/recipes-devtools/make/make-3.82/expand_MAKEFLAGS.patch diff --git a/meta/recipes-devtools/make/make-3.82/expand_MAKEFLAGS.patch b/meta/recipes-devtools/make/make-3.82/expand_MAKEFLAGS.patch new file mode 100644 index 000..4184937 --- /dev/null +++ b/meta/recipes-devtools/make/make-3.82/expand_MAKEFLAGS.patch @@ -0,0 +1,39 @@ +Upstream-Status: Inappropriate [The fix is already in upstream cvs repo, but not in the stable release] Isn't 'backport' a better description than 'inappropriate'? Agreed, I've taken this patch but changed the patch status to backport. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/3] task-self-hosted: install sudo, tun.ko, iptables, libgl and libgl-dev into the target
On Thu, 2011-12-01 at 17:21 +0800, Dexuan Cui wrote: sudo, kernel-module-tun and iptables are needed by runqemu. strace has appeared in RDEPENDS_task-self-hosted-debug, so let's remove it from RDEPENDS_task-self-hosted-extended. install libglu and libgl-dev rather than mesa-dri and mesa-dri-dev due to the recent commit mesa: package gl/egl/osmesa to separate packages. Signed-off-by: Dexuan Cui dexuan@intel.com Signed-off-by: Zhai Edwin edwin.z...@intel.com --- meta/recipes-core/tasks/task-self-hosted.bb | 14 ++ 1 files changed, 10 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
[OE-core] RFC: On-screen- / virtual-keyboard
Hi, some devices like the Nokia N900 or the OpenPandora provide a hardware keyboard, other devices need USB keyboards to operate, but how could a user input text into a touchscreen-only device? #1. The situation Portable devices with a touchscreen usually provide virtual keyboards, looking around in OE-dev and OE-Core, there is illume-keyboard but i doubt it can be used with XFCE that easily. To tell the user that he has to buy a (small) hardware keyboard to use a touchscreen device isn't an appropriate solution, if you know what I mean ;) #2. What was already discovered There are plenty of virtual keyboards out there, for example: -gok (gnome on-screen keyboard) [1] -kvkbd (kde virtual keyboard) [2] -illume-keyboard (e17 enlightenment on-screen-keyboard add-on) [3] -onboard (generic on-screen keyboard) [4] -(Qt) Colibri (in application virtual keyboard) [5] -(Qt/Gtk2/Gtk3) Maliit (in application virtual keyboard) [6] But they all have some limitations: Either they only work with one window manager, or they don't have support for different keyboard layouts. In application keyboards have major drawbacks too, the user can't enter text into other applications (eg. terminals). The onboard virtual keyboard needs GObject-Introspection which is somehow cumbersome to build (or did someone succeed to build it?). #3. What is needed Most likely suitable would be a virtual keyboard that can be used across distributions (or at least within OE-Core), and it should work independent from the window manager. Using a virtual keyboard (library / plug-in) that is bound to the code of the applications would also be possible, but it is very limiting. Of course the keyboard needs some functionality, like switching the keyboard layout to the preferred localization, resizing properly, it should look nice. The best would be, if the keyboard features usability enhancements, something like: The user can see the button that he pressed hovering above his finger or the like (just these iWhatever features). If the user needs to use a pen for the keyboard, that would be no problem. But if the user has to re-type every second letter because of an unusable layout, then I would prefer to ship speech recognition software :) (on a mobile phone I could just do that, but on industrial devices it would not be accepted that easily). #4. Working towards the solution Porting onboard could work out well, but GObject-Introspection is not that trivial. If you have any other idea, or know about any software that would be interesting, it would help much. There is no problem if the software is incomplete / currently in active development, or in a beta stage. (As long as it is already usable). #5. Appendix [1] gok: http://www.gok.ca/ [2] kvkbd: http://kde-apps.org/content/show.php?content=94374 [3] illume: http://wiki.openmoko.org/wiki/Illume [4] onboard: https://launchpad.net/onboard [5] colibri: https://projects.developer.nokia.com/colibri (note: site currently in maintenance) [6] maliit: https://wiki.maliit.org/Main_Page -- Regards Samuel ___ 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] runqemu-ifup, runqemu-internal: be wiser when locating the network tools
On Thu, 2011-12-01 at 17:21 +0800, Dexuan Cui wrote:
When working on the self-hosted-image work, I found the PATH variable in the
Level-1 target doesn't have /sbin and /usr/sbin, so runqemu can't
run properly since the tools are installeld at
/sbin/ifconfig
/sbin/route
/usr/sbin/iptables
The patch is used to fix the issue by setting a temp PATH when running which.
Signed-off-by: Dexuan Cui dexuan@intel.com
---
scripts/runqemu-ifup |8 +---
scripts/runqemu-internal |3 ++-
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/scripts/runqemu-ifup b/scripts/runqemu-ifup
index 870cb6b..9e697a8 100755
--- a/scripts/runqemu-ifup
+++ b/scripts/runqemu-ifup
@@ -64,7 +64,9 @@ if [ $STATUS -ne 0 ]; then
exit 1
fi
-IFCONFIG=`which ifconfig 2 /dev/null`
+PATH_TMP=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
+
+IFCONFIG=`{ PATH=$PATH:$PATH_TMP; which ifconfig 2 /dev/null; }`
if [ x$IFCONFIG = x ]; then
# better than nothing...
IFCONFIG=/sbin/ifconfig
I don't really like this, its getting hard to understand whats going on.
Can we abstract this to a function which tries PATH, then tries our own
PATH_TMP? This would reduce code duplication and makes it clearer what
the code is doing...
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: On-screen- / virtual-keyboard
Op 1 dec. 2011, om 11:47 heeft Samuel Stirtzel het volgende geschreven: Hi, some devices like the Nokia N900 or the OpenPandora provide a hardware keyboard, other devices need USB keyboards to operate, but how could a user input text into a touchscreen-only device? #1. The situation Portable devices with a touchscreen usually provide virtual keyboards, looking around in OE-dev and OE-Core, there is illume-keyboard but i doubt it can be used with XFCE that easily. To tell the user that he has to buy a (small) hardware keyboard to use a touchscreen device isn't an appropriate solution, if you know what I mean ;) #2. What was already discovered There are plenty of virtual keyboards out there, for example: -gok (gnome on-screen keyboard) [1] -kvkbd (kde virtual keyboard) [2] -illume-keyboard (e17 enlightenment on-screen-keyboard add-on) [3] -onboard (generic on-screen keyboard) [4] -(Qt) Colibri (in application virtual keyboard) [5] -(Qt/Gtk2/Gtk3) Maliit (in application virtual keyboard) [6] Don't forget matchbox-keyboard and matchbox-keyboard2 :) signature.asc Description: Message signed with OpenPGP using GPGMail ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: On-screen- / virtual-keyboard
On Thu, 2011-12-01 at 11:47 +0100, Samuel Stirtzel wrote: Hi, some devices like the Nokia N900 or the OpenPandora provide a hardware keyboard, other devices need USB keyboards to operate, but how could a user input text into a touchscreen-only device? #1. The situation Portable devices with a touchscreen usually provide virtual keyboards, looking around in OE-dev and OE-Core, there is illume-keyboard but i doubt it can be used with XFCE that easily. To tell the user that he has to buy a (small) hardware keyboard to use a touchscreen device isn't an appropriate solution, if you know what I mean ;) #2. What was already discovered There are plenty of virtual keyboards out there, for example: -gok (gnome on-screen keyboard) [1] -kvkbd (kde virtual keyboard) [2] -illume-keyboard (e17 enlightenment on-screen-keyboard add-on) [3] -onboard (generic on-screen keyboard) [4] -(Qt) Colibri (in application virtual keyboard) [5] -(Qt/Gtk2/Gtk3) Maliit (in application virtual keyboard) [6] OE-Core also includes matchbox-keyboard as part of sato. Its not perfect but worth including in your list... Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/3] A few more updates
On Thu, 2011-12-01 at 11:40 +0100, Koen Kooi wrote: Op 1 dec. 2011, om 06:12 heeft Saul Wold het volgende geschreven: Richard, This address the missing checksums and patches from my last set. Also added here is libffi. Are there any objections to making missing checksums a fatal error? Not from me, I thought we'd done this a long time ago... 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] trace-cmd: Update to version 1.2
On Wed, 2011-11-30 at 16:48 -0800, Darren Hart wrote: The following changes since commit f4efaa0f472b4bf0ba0a0297cc9ecc8b5a671f72: squashfs-tools: fix PR, those should start with 'r' (2011-11-30 23:37:40 +) are available in the git repository at: git://git.yoctoproject.org/user-contrib/dvhart/oe-core updates http://git.yoctoproject.org/cgit.cgi/user-contrib/dvhart/oe-core/log/?h=updates Darren Hart (1): trace-cmd: Update to 1.2 (includes kernelshark) Merged to master, thanks! Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: On-screen- / virtual-keyboard
2011/12/1 Koen Kooi k...@dominion.thruhere.net: Op 1 dec. 2011, om 11:47 heeft Samuel Stirtzel het volgende geschreven: Hi, some devices like the Nokia N900 or the OpenPandora provide a hardware keyboard, other devices need USB keyboards to operate, but how could a user input text into a touchscreen-only device? #1. The situation Portable devices with a touchscreen usually provide virtual keyboards, looking around in OE-dev and OE-Core, there is illume-keyboard but i doubt it can be used with XFCE that easily. To tell the user that he has to buy a (small) hardware keyboard to use a touchscreen device isn't an appropriate solution, if you know what I mean ;) #2. What was already discovered There are plenty of virtual keyboards out there, for example: -gok (gnome on-screen keyboard) [1] -kvkbd (kde virtual keyboard) [2] -illume-keyboard (e17 enlightenment on-screen-keyboard add-on) [3] -onboard (generic on-screen keyboard) [4] -(Qt) Colibri (in application virtual keyboard) [5] -(Qt/Gtk2/Gtk3) Maliit (in application virtual keyboard) [6] Don't forget matchbox-keyboard and matchbox-keyboard2 :) Right I forgot about it, sorry. So the new list is as follows: #2. What was already discovered There are plenty of virtual keyboards out there, for example: -gok (gnome on-screen keyboard) [1] -kvkbd (kde virtual keyboard) [2] -illume-keyboard (e17 enlightenment on-screen-keyboard add-on) [3] -onboard (generic on-screen keyboard) [4] -(Qt) Colibri (in application virtual keyboard) [5] -(Qt/Gtk2/Gtk3) Maliit (in application virtual keyboard) [6] -matchbox-keyboards (matchbox wm virtual keyboard) [7] #5. Appendix [1] gok: http://www.gok.ca/ [2] kvkbd: http://kde-apps.org/content/show.php?content=94374 [3] illume: http://wiki.openmoko.org/wiki/Illume [4] onboard: https://launchpad.net/onboard [5] colibri: https://projects.developer.nokia.com/colibri (note: site currently in maintenance) [6] maliit: https://wiki.maliit.org/Main_Page [7] matchbox-keyboard: http://matchbox-project.org/ (note: the site seems to currently get reworked, so I got no direct link) -- Regards Samuel ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] Coordinating inter-layer dependencies
Hi, During the past month there have been a number of updates to OE-core recipes that triggered parsing errors due to bbappend in other layers. A small seleciton: * netbase * libdrm * xserver-xorg * clutter My view is that layer maintainers need to keep an eye on potential breakage and have updates ready when patches land into OE-core. Looking back I can see that while the situation is improving a bit, it's still not working. The problem with slow updates to layers is that (with my angstrom hat on) users (and with my TI hat on) customers and coworkers can't do builds without rm'ing the bbappends or disabling the layer. This is bad for a number of reasons: 1) It creates unmanaged local diffs 2) it can cause PR to fluctuate back and forth if you rm is a bit overzealous or if you disable the complete layer. My proposal is that OE-core recipe upgrades with known bbappends look like this: 1) add new version with a warning about bbappends 2) wait a N days (2 N 7) 3) delete old version To avoid stressing out RP and Sau! I would strongly urge layer maintainers to respond to recipe update patches with I have a bbappend, but my review process needs time, please use the above proposal if you need time to test and update your bbappends. We're all human in the end and timezone differences aren't always helping with these kinds of problems, so let's work together to minimize parsing breakage. Related to that: Please include information on how to send patches upstream in your layer/repo README. The meta-intel/emenlow lacks that and the top level README doesn't mention that there are sublevel READMEs. regards, Koen signature.asc Description: Message signed with OpenPGP using GPGMail ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH][oe-core 0/4] Small fixes for sysstat, shadow, coreutils, gconf
sysstat and gconf are fixed version of previous patches (which were also sent to ML, resending now just to be clear that they are also in branch and pull-request). The following changes since commit 6ef79ede361c42e11e78d4afcff11295a3144055: pulseaudio 1.1: add filter-apply and filter-heuristics to pulseaudio-server RDEPENDS, it won't start without (2011-12-01 10:53:27 +) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib jansa/pull http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=jansa/pull Martin Jansa (4): sysstat: don't run populate-volatile.sh update in do_rootfs or without populate-volatile.sh gconf: add polkit to DEPENDS only for target recipe and disable default-service for native shadow: use u-a for /usr/bin/groups coreutils: fix u-a for base64, mktemp and df meta/recipes-core/coreutils/coreutils_8.14.bb | 20 ++-- meta/recipes-extended/shadow/shadow_4.1.4.3.bb |5 +++-- meta/recipes-extended/sysstat/sysstat.inc |7 ++- meta/recipes-extended/sysstat/sysstat_10.0.2.bb |2 +- meta/recipes-gnome/gnome/gconf_3.2.3.bb | 10 +++--- 5 files changed, 31 insertions(+), 13 deletions(-) -- 1.7.8.rc4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH][oe-core 1/4] sysstat: don't run populate-volatile.sh update in do_rootfs or without populate-volatile.sh
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
meta/recipes-extended/sysstat/sysstat.inc |7 ++-
meta/recipes-extended/sysstat/sysstat_10.0.2.bb |2 +-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-extended/sysstat/sysstat.inc
b/meta/recipes-extended/sysstat/sysstat.inc
index 2936f96..ca40ab5 100644
--- a/meta/recipes-extended/sysstat/sysstat.inc
+++ b/meta/recipes-extended/sysstat/sysstat.inc
@@ -22,7 +22,12 @@ do_install() {
}
pkg_postinst_${PN} () {
-/etc/init.d/populate-volatile.sh update
+if [ -n $D ]; then
+exit 1
+fi
+if [ -e /etc/init.d/populate-volatile.sh ]; then
+/etc/init.d/populate-volatile.sh update
+fi
}
diff --git a/meta/recipes-extended/sysstat/sysstat_10.0.2.bb
b/meta/recipes-extended/sysstat/sysstat_10.0.2.bb
index bd559d8..7b57bc8 100644
--- a/meta/recipes-extended/sysstat/sysstat_10.0.2.bb
+++ b/meta/recipes-extended/sysstat/sysstat_10.0.2.bb
@@ -2,7 +2,7 @@ require sysstat.inc
LIC_FILES_CHKSUM = file://COPYING;md5=8ca43cbc842c2336e835926c2166c28b
-PR = r0
+PR = r1
--
1.7.8.rc4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH][oe-core 2/4] gconf: add polkit to DEPENDS only for target recipe and disable default-service for native
* gnome-common-native is needed because gnomebase.bbclass does only
DEPENDS += gnome-common
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
meta/recipes-gnome/gnome/gconf_3.2.3.bb | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-gnome/gnome/gconf_3.2.3.bb
b/meta/recipes-gnome/gnome/gconf_3.2.3.bb
index aa9da78..cdc7a35 100644
--- a/meta/recipes-gnome/gnome/gconf_3.2.3.bb
+++ b/meta/recipes-gnome/gnome/gconf_3.2.3.bb
@@ -3,9 +3,10 @@ SECTION = x11/gnome
LICENSE = LGPLv2+
LIC_FILES_CHKSUM = file://COPYING;md5=55ca817ccb7d5b5b66355690e9abc605
-DEPENDS = glib-2.0 dbus dbus-glib libxml2 intltool-native
+DEPENDS = glib-2.0 dbus dbus-glib libxml2 intltool-native polkit
+DEPENDS_virtclass-native = glib-2.0-native dbus-native dbus-glib-native
libxml2-native intltool-native gnome-common-native
-PR = r1
+PR = r2
inherit gnomebase
@@ -18,7 +19,10 @@ SRC_URI[archive.sha256sum] =
52008a82a847527877d9e1e549a351c86cc53cada4733b8a70
S = ${WORKDIR}/GConf-${PV}
-EXTRA_OECONF = --disable-gtk-doc --disable-gtk --enable-shared
--disable-static --enable-debug=yes --disable-introspection --disable-orbit
--with-openldap=no
+POLKIT_OECONF = --enable-defaults-service
+POLKIT_OECONF_virtclass-native = --disable-defaults-service
+EXTRA_OECONF = --disable-gtk-doc --disable-gtk --enable-shared
--disable-static --enable-debug=yes \
+--disable-introspection --disable-orbit --with-openldap=no
${POLKIT_OECONF}
do_configure_prepend () {
touch gtk-doc.make
--
1.7.8.rc4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH][oe-core 3/4] shadow: use u-a for /usr/bin/groups
* otherwise coreutils upgrade fails with
update-alternatives: Error: not linking //usr/bin/groups to groups.coreutils
since //usr/bin/groups exists and is not a link
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
meta/recipes-extended/shadow/shadow_4.1.4.3.bb |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-extended/shadow/shadow_4.1.4.3.bb
b/meta/recipes-extended/shadow/shadow_4.1.4.3.bb
index 25330a4..dddac2c 100644
--- a/meta/recipes-extended/shadow/shadow_4.1.4.3.bb
+++ b/meta/recipes-extended/shadow/shadow_4.1.4.3.bb
@@ -9,7 +9,7 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=08c553a87d4e51bbed50b20e0adcaede \
DEPENDS = ${@base_contains('DISTRO_FEATURES', 'pam', 'libpam', '', d)}
RDEPENDS_${PN} = ${@base_contains('DISTRO_FEATURES', 'pam', '${PAM_PLUGINS}',
'', d)}
-PR = r5
+PR = r6
SRC_URI = http://pkg-shadow.alioth.debian.org/releases/${BPN}-${PV}.tar.bz2 \
file://login_defs_pam.sed \
@@ -88,7 +88,7 @@ do_install_append() {
sed -i '/^CREATE_MAIL_SPOOL/ s:^:#:' ${D}${sysconfdir}/default/useradd
install -d ${D}${sbindir} ${D}${base_sbindir} ${D}${base_bindir}
- for i in passwd chfn newgrp chsh ; do
+ for i in passwd chfn newgrp chsh groups ; do
mv ${D}${bindir}/$i ${D}${bindir}/$i.${PN}
done
@@ -123,6 +123,7 @@ pkg_postinst_${PN} () {
update-alternatives --install ${bindir}/chfn chfn chfn.${PN} 200
update-alternatives --install ${bindir}/newgrp newgrp newgrp.${PN} 200
update-alternatives --install ${bindir}/chsh chsh chsh.${PN} 200
+ update-alternatives --install ${bindir}/groups groups groups.${PN} 200
update-alternatives --install ${base_bindir}/login login login.${PN} 200
update-alternatives --install ${base_sbindir}/vipw vipw vipw.${PN} 200
update-alternatives --install ${base_sbindir}/vigr vigr vigr.${PN} 200
--
1.7.8.rc4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH][oe-core 4/4] coreutils: fix u-a for base64, mktemp and df
* busybox installs mktemp and df to base_bindir not bindir
SHR root@gjama ~ $ ll /bin/df /bin/mktemp /bin/base64
lrwxrwxrwx 1 root root 7 Nov 10 15:44 /bin/df - busybox
lrwxrwxrwx 1 root root 7 Nov 10 15:44 /bin/mktemp - busybox
lrwxrwxrwx 1 root root 7 Nov 28 15:48 /bin/base64 - busybox
* so u-a for coreutils fails:
update-alternatives: Error: cannot register alternative base64 to
/usr/bin/base64 since it is already registered to /bin/base64
update-alternatives: Error: cannot register alternative mktemp to
/usr/bin/mktemp since it is already registered to /bin/mktemp
update-alternatives: Error: cannot register alternative df to /usr/bin/df
since it is already registered to /bin/df
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
meta/recipes-core/coreutils/coreutils_8.14.bb | 20 ++--
1 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/meta/recipes-core/coreutils/coreutils_8.14.bb
b/meta/recipes-core/coreutils/coreutils_8.14.bb
index 01face0..cc05d88 100644
--- a/meta/recipes-core/coreutils/coreutils_8.14.bb
+++ b/meta/recipes-core/coreutils/coreutils_8.14.bb
@@ -7,7 +7,7 @@ BUGTRACKER = http://debbugs.gnu.org/coreutils;
LICENSE = GPLv3+
LIC_FILES_CHKSUM = file://COPYING;md5=d32239bcb673463ab874e80d47fae504\
file://src/ls.c;startline=5;endline=16;md5=e1a509558876db58fb6667ba140137ad
-PR = r1
+PR = r2
DEPENDS = gmp
DEPENDS_virtclass-native =
@@ -21,13 +21,13 @@ SRC_URI[sha256sum] =
0d120817c19292edb19e92ae6b8eac9020e03d51e0af9cb116cf82b65d
EXTRA_OECONF_virtclass-native = --without-gmp
-# [ gets a special treatment and is not included in this
-bindir_progs = base64 basename chcon cksum comm csplit cut dir dircolors
dirname du \
+# [ df mktemp base64 gets a special treatment and is not included in this
+bindir_progs = basename chcon cksum comm csplit cut dir dircolors dirname du \
env expand expr factor fmt fold groups head hostid id install \
-join link logname md5sum mkfifo mktemp nice nl nohup nproc od
paste pathchk \
+join link logname md5sum mkfifo nice nl nohup nproc od paste
pathchk \
pinky pr printenv printf ptx readlink runcon seq sha1sum
sha224sum sha256sum \
sha384sum sha512sum shred shuf sort split stat stdbuf sum tac
tail tee test timeout\
-tr truncate tsort tty unexpand uniq unlink uptime users vdir
wc who whoami yes df
+tr truncate tsort tty unexpand uniq unlink uptime users vdir
wc who whoami yes
# hostname gets a special treatment and is not included in this
base_bindir_progs = cat chgrp chmod chown cp date dd echo false kill ln ls
mkdir \
@@ -36,7 +36,7 @@ base_bindir_progs = cat chgrp chmod chown cp date dd echo
false kill ln ls mkdi
sbindir_progs= chroot
do_install_append() {
- for i in ${bindir_progs}; do mv ${D}${bindir}/$i
${D}${bindir}/$i.${PN}; done
+ for i in ${bindir_progs} df mktemp base64; do mv ${D}${bindir}/$i
${D}${bindir}/$i.${PN}; done
install -d ${D}${base_bindir}
for i in ${base_bindir_progs}; do mv ${D}${bindir}/$i
${D}${base_bindir}/$i.${PN}; done
@@ -61,6 +61,11 @@ pkg_postinst_${PN} () {
# Special cases. [ needs to be treated separately.
update-alternatives --install '${bindir}/[' '[' 'lbracket.${PN}' 100
+
+ # Special cases. base64, mktemp and df need to be treated separately,
because busybox have them in base_binding not bindir
+ update-alternatives --install ${base_bindir}/base64 base64
${bindir}/base64.${PN} 100;
+ update-alternatives --install ${base_bindir}/mktemp mktemp
${bindir}/mktemp.${PN} 100;
+ update-alternatives --install ${base_bindir}/df df ${bindir}/df.${PN}
100;
}
pkg_prerm_${PN} () {
@@ -74,6 +79,9 @@ pkg_prerm_${PN} () {
update-alternatives --remove hostname hostname.${PN}
update-alternatives --remove uptime uptime.${PN}
update-alternatives --remove '[' 'lbracket.${PN}'
+ update-alternatives --remove base64 ${bindir}/base64.${PN}
+ update-alternatives --remove mktemp ${bindir}/mktemp.${PN}
+ update-alternatives --remove df ${bindir}.df.${PN}
}
BBCLASSEXTEND = native
--
1.7.8.rc4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] layer priorities?
Just a few short questions about the layer priorities. May be there is an faq answering them, but i could not find it. What is the policy assigning a priority to a layer? Do multiple layers with the same priority are allowed? How is this handled? Would it make sense to add an *Layer prio* column to http://www.openembedded.org/wiki/LayerIndex? Steffen -- DResearch Fahrzeugelektronik GmbH Otto-Schmirgal-Str. 3, 10319 Berlin, Germany Tel: +49 30 515932-237 mailto:sl...@dresearch-fe.de Fax: +49 30 515932-299 Geschäftsführer: Dr. Michael Weber, Werner Mögle; Amtsgericht Berlin Charlottenburg; HRB 130120 B; Ust.-IDNr. DE273952058 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/5][PULL] Recipe upgrades for glib and telepathy-*.
On Thu, 2011-12-01 at 07:21 +0800, Dongxiao Xu wrote: Hi Saul, This pull request upgrades some recipes. Please help to review and pull. Thanks, Dongxiao The following changes since commit 36654d6d393cb8c8a545835184a96be4ae0c885d: grub: Use COMPATIBLE_HOST (2011-11-30 22:21:53 +) are available in the git repository at: git://git.pokylinux.org/poky-contrib dxu4/upgrade http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dxu4/upgrade Dongxiao Xu (5): telepathy-idle: upgrade to version 0.1.11 telepathy-glib: upgrade to version 0.17.0 glib-2.0: upgrade to version 2.30.1 telepathy-mission-control: upgrade to version 5.10.1 distro_trakcing_fields: update for glib, telepathy-idle, etc 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][oe-core 0/4] Small fixes for sysstat, shadow, coreutils, gconf
On Thu, 2011-12-01 at 13:01 +0100, Martin Jansa wrote: sysstat and gconf are fixed version of previous patches (which were also sent to ML, resending now just to be clear that they are also in branch and pull-request). The following changes since commit 6ef79ede361c42e11e78d4afcff11295a3144055: pulseaudio 1.1: add filter-apply and filter-heuristics to pulseaudio-server RDEPENDS, it won't start without (2011-12-01 10:53:27 +) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib jansa/pull http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=jansa/pull Martin Jansa (4): sysstat: don't run populate-volatile.sh update in do_rootfs or without populate-volatile.sh gconf: add polkit to DEPENDS only for target recipe and disable default-service for native shadow: use u-a for /usr/bin/groups coreutils: fix u-a for base64, mktemp and df I have a question on the sysstat change, I merged the others, thanks. Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Coordinating inter-layer dependencies
On Thu, Dec 01, 2011 at 12:23:08PM +0100, Koen Kooi wrote: Hi, During the past month there have been a number of updates to OE-core recipes that triggered parsing errors due to bbappend in other layers. A small seleciton: * netbase * libdrm * xserver-xorg * clutter My view is that layer maintainers need to keep an eye on potential breakage and have updates ready when patches land into OE-core. Looking back I can see that while the situation is improving a bit, it's still not working. The problem with slow updates to layers is that (with my angstrom hat on) users (and with my TI hat on) customers and coworkers can't do builds without rm'ing the bbappends or disabling the layer. This is bad for a number of reasons: 1) It creates unmanaged local diffs 2) it can cause PR to fluctuate back and forth if you rm is a bit overzealous or if you disable the complete layer. My proposal is that OE-core recipe upgrades with known bbappends look like this: 1) add new version with a warning about bbappends 2) wait a N days (2 N 7) 3) delete old version To avoid stressing out RP and Sau! I would strongly urge layer maintainers to respond to recipe update patches with I have a bbappend, but my review process needs time, please use the above proposal if you need time to test and update your bbappends. We're all human in the end and timezone differences aren't always helping with these kinds of problems, so let's work together to minimize parsing breakage. That's exactly the reason why I'm using contrib/shr branches and my setup scripts are updating only from contrib/shr, so I can push changes to all related branches almost at once and when they are ready. Sometimes it means extra patches in contrib/shr which are not yet in master (and sometimes they are on ML already) sometimes it means that I'm waiting with pulling newer master to shr branch before I prepare corresponding changes in meta-smartphone (this was the case ie for last libdrm upgrade). But to test corresponding changes sometimes takes many hours to even build it... A while back I've proposed to make .bbappend without corresponding .bb only big fat warning, but not fatal to parse. Now you cannot even build eglibc if there is libdrm bbappend you don't care at all about.. Of course if someone ignores big fat warning and build libdrm without bbappend and then his mesa build is failing, he has to go back and cleansstate libdrm to build it again properly. Regards, -- 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] layer priorities?
On Thu, 2011-12-01 at 13:17 +0100, Steffen Sledz wrote: Just a few short questions about the layer priorities. May be there is an faq answering them, but i could not find it. What is the policy assigning a priority to a layer? Do multiple layers with the same priority are allowed? How is this handled? Would it make sense to add an *Layer prio* column to http://www.openembedded.org/wiki/LayerIndex? We had a bit of discussion around this a few months ago. See the longish thread at: http://lists.linuxtogo.org/pipermail/openembedded-core/2011-August/007387.html My view remains that the right place to be setting the priority is in bblayers.conf rather than in the layer itself, but there didn't seem to be any clear consensus last time it was discussed. Multiple layers with the same priority will have undefined results if they overlap. You probably don't want to allow that situation to occur. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Coordinating inter-layer dependencies
On Thu, 2011-12-01 at 10:59 -0200, Otavio Salvador wrote: On Thu, Dec 1, 2011 at 10:37, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Thu, 2011-12-01 at 13:24 +0100, Martin Jansa wrote: A while back I've proposed to make .bbappend without corresponding .bb only big fat warning, but not fatal to parse. Now you cannot even build eglibc if there is libdrm bbappend you don't care at all about.. You can do this by setting: BB_DANGLINGAPPENDS_WARNONLY This is even worse; you end up with a package without the changes done on the bbappend and as most bbappend files do not change PR, adding it later won't force a package update. Which is why its off by default. My point is you can do with Martin is suggesting, its just not without its drawbacks. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Coordinating inter-layer dependencies
On Thu, Dec 01, 2011 at 01:02:38PM +, Richard Purdie wrote: On Thu, 2011-12-01 at 10:59 -0200, Otavio Salvador wrote: On Thu, Dec 1, 2011 at 10:37, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Thu, 2011-12-01 at 13:24 +0100, Martin Jansa wrote: A while back I've proposed to make .bbappend without corresponding .bb only big fat warning, but not fatal to parse. Now you cannot even build eglibc if there is libdrm bbappend you don't care at all about.. You can do this by setting: BB_DANGLINGAPPENDS_WARNONLY Good to know, thanks. This is even worse; you end up with a package without the changes done on the bbappend and as most bbappend files do not change PR, adding it later won't force a package update. Which is why its off by default. My point is you can do with Martin is suggesting, its just not without its drawbacks. I think the main advantage of this is that you're allowed to build stuff which doesn't use those dangling appends. Ie start build of eglibc if you know that nothing is bbappending to eglibc and to its dependency tree. And when .bbaappends are fixed you can disable BB_DANGLINGAPPENDS_WARNONLY and build the rest. But waiting for _all_ recipes in _all_ layers to get their .bbappends right can sometimes a bit long.. 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] Feedback on building openembedded-core for qemuarm. Excerpts from buildlog
On 11/29/2011 03:06 PM, Koen Kooi wrote: Op 29 nov. 2011, om 20:36 heeft Ulf Samuelsson het volgende geschreven: On 2011-11-29 16:03, Richard Purdie wrote: 2.ftp://elsie.nci.nih.gov/pub/tzcode2011i.tar.gz; is no longer available. tzdata , same problem. The recipe is located in two places. meta-openembedded/meta-oe/recipes-extended/tz*/tz*.bb have the problem This is what the build uses. This is something to raise with the meta-oe maintainers. I think there isn't a problem in OECore. Since we now have a large number of layers, maybe it is a good idea to define in each layer, how the git send email should behave in by providing a better .git/config file in the trunk? I.E: [sendemail] to = openembedded-core@lists.openembedded.org or meta-angstrom/.git/config [sendemail] to = angstrom-distro-de...@linuxtogo.org [format] subjectprefix = [meta-angstrom] No need to look in the README file with this. That assumes git-send-email is the preferred way, which it isn;'t for a lot of layers Even if it is not the preferred way, it would direct the discussion to the appropriate list. This would reduce the number of mis-directed emails to this list. And we know that no one reads the README's :) Philip ___ 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] Reproducible build problem with BB_NUMBER_THREADS=8
On Thu, Dec 1, 2011 at 7:48 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: When you restart the build is the problem persistent or does it work the second time? I set BB_NUMBER_THREADS = 2 (was 4 when failing) I tried to restart the build and cleanall just the failing package, and it still failed. I then ran: bitbake -c cleanall gcc-cross gcc-cross-initial gcc-cross-intermediate gcc-runtime and after that, everything worked. Does someone have a complete console log for a build that failed with this they could share? I'll restart the build and collect one. So you just want the output of the console for bitbake? Thanks, Cliff -- = http://bec-systems.com ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Coordinating inter-layer dependencies
On Thu, Dec 1, 2011 at 6:13 AM, Martin Jansa martin.ja...@gmail.com wrote: On Thu, Dec 01, 2011 at 01:02:38PM +, Richard Purdie wrote: On Thu, 2011-12-01 at 10:59 -0200, Otavio Salvador wrote: On Thu, Dec 1, 2011 at 10:37, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Thu, 2011-12-01 at 13:24 +0100, Martin Jansa wrote: A while back I've proposed to make .bbappend without corresponding .bb only big fat warning, but not fatal to parse. Now you cannot even build eglibc if there is libdrm bbappend you don't care at all about.. You can do this by setting: BB_DANGLINGAPPENDS_WARNONLY Good to know, thanks. This is even worse; you end up with a package without the changes done on the bbappend and as most bbappend files do not change PR, adding it later won't force a package update. People use bbappends without changing PR? I've been doing a PR .= .1 or whatever in every bbappend I've created since they were added to bitbake, and used to do the same with amend.inc. It can result in some long PR values, but I'd rather that than the alternative.. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Feedback on building openembedded-core for qemuarm. Excerpts from buildlog
On 2011-11-30 18:30, Scott Garman wrote: On 11/29/2011 01:18 PM, Ulf Samuelsson wrote: Seen a couple of errors as well. 1. ERROR: Function 'useradd_sysroot' failed Tried to access /etc/group but this was locked. Problem disappeared the next time I rebuilt. Can you file a bug about this problem please. I think we need to go through the code paths in shadow and ensure its locking is sane. I took a quick look at the code and was left wondering what lckpwdf() does for example. Scott, could you take a look at this? Bugzilla is out of service, so bugs cannot be filed. I have filed a bug for this, and have been trying to reproduce it without success: http://bugzilla.pokylinux.org/show_bug.cgi?id=1794 Haven't seen the issue since then so it is hard to give any details. I used very high BB_NUMBER_THREADS = 24. I do have access to a system with a lot of cores, and have been doing builds on it. I'd just like to confirm that when you saw this, it was a build from scratch (e.g, not using sstate cache from a previous build). And also, you *weren't* building this from a remote filesystem (NFS), correct? Thanks, Scott No NFS for sure. I think this was the first build, but only 99% sure. It disappered when I restarted the build. Have not seen this problem repeated, but then, the build on this machine has other problems Packages tend to fail since the c++ compiler seems to ignore --sysroot Machine = Ubuntu-11.10 x64. This is with BB_NUMBER_THREADS = 4 If I change this, then the same problem occur, but in a different package. (Tried with 4 AND 24) BR Ulf -- Best Regards Ulf Samuelsson eMagii ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Tinylogin or shadow?
Op 1 dec. 2011, om 14:01 heeft Martin Jansa het volgende geschreven:
On Tue, Sep 06, 2011 at 07:30:31PM +0100, Phil Blundell wrote:
On Tue, 2011-09-06 at 11:20 +0200, Martin Jansa wrote:
Hi,
if someone wants to use only shadow as login manager, then all postinst
calling adduser (instead of useradd) are failing ie:
recipes-connectivity/avahi/avahi.inc: grep ^avahi: /etc/passwd
/dev/null || adduser --disabled-password --system --home
/var/run/avahi-daemon --no-create-home avahi --ingroup avahi -g Avahi
recipes-connectivity/avahi/avahi.inc: grep ^avahi-autoipd: /etc/passwd
/dev/null || adduser --disabled-password --system --home
/var/lib/avahi-autoipd --no-create-home avahi-autoipd --ingroup
avahi-autoipd -g Avahi autoip daemon
recipes-connectivity/openssh/openssh_5.8p2.bb: adduser --system
--home /var/run/sshd --no-create-home --disabled-password --ingroup sshd -s
/bin/false sshd
recipes-connectivity/ppp-dialin/ppp-dialin_0.1.bb: adduser --system
--home /dev/null --no-create-home --empty-password --ingroup nogroup -s
${sbindir}/ppp-dialin ppp
recipes-core/dbus/dbus.inc: adduser --system --home
$MESSAGEHOME --no-create-home --disabled-password \
recipes-devtools/distcc/distcc_2.18.3.bb: grep distcc
/etc/passwd || adduser --system --home /dev/null --no-create-home
--empty-password --ingroup nogroup distcc
recipes-graphics/x11-common/xserver-nodm-init.bb:adduser
--disabled-password $username
recipes-multimedia/pulseaudio/pulseaudio.inc:adduser
--disabled-password --home=/var/run/pulse --system \
recipes-support/hal/hal.inc:grep haldaemon /etc/passwd || adduser
--disabled-password --system --home /var/run/hald --no-create-home
haldaemon --ingroup haldaemon -g HAL
What is preferred fix,
I guess the first part of any preferred fix is going to have to be to
get the postinsts to be consistent about what mechanism they use for
adding users, rather than the mélange of different approaches that we
seem to have today. Ideally I think that would be by means of making
the recipes in question use useradd.bbclass. It might also be
reasonable to extend useradd.bbclass to work with tinylogin and/or
busybox's implementations of useradd if it doesn't already.
If there are recipes which can't use useradd.bbclass for whatever reason
then I guess they should be adjusted to call useradd rather than
adduser, since the former is the more standardized of the two.
As for tinylogin's adduser, I am inclined to say that it should probably
just go away in favour of a wrapper around (ideally a generic) useradd.
just small update on this, from my original list only 2 recipes are
still not using useradd.bbclass:
recipes-connectivity/avahi/avahi.inc: grep ^avahi: /etc/passwd
/dev/null || adduser --disabled-password --system --home
/var/run/avahi-daemon --no-create-home avahi --ingroup avahi -g Avahi
recipes-connectivity/avahi/avahi.inc: grep ^avahi-autoipd: /etc/passwd
/dev/null || adduser --disabled-password --system --home
/var/lib/avahi-autoipd --no-create-home avahi-autoipd --ingroup avahi-autoipd
-g Avahi autoip daemon
recipes-devtools/distcc/distcc_2.18.3.bb: grep distcc
/etc/passwd || adduser --system --home /dev/null --no-create-home
--empty-password --ingroup nogroup distcc
Is someone using them? Any volunteer to migrate them and test them?
I'm in java hell right now, but I'll try to fix those after that. But it would
be nice if someone beats me to it :)
regards,
Koen
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] zlib 1.2.5: install pkgconfig file, needed for e.g. modern webkit
Op 1 dec. 2011, om 14:01 heeft Richard Purdie het volgende geschreven: On Wed, 2011-11-30 at 19:15 +0100, Koen Kooi wrote: Op 30 nov. 2011, om 18:52 heeft Richard Purdie het volgende geschreven: On Wed, 2011-11-30 at 14:40 +0100, Koen Kooi wrote: Upstream has grown cmake support which would allow us to dump the OE autotools hack, but the cmakefile doesn't install the .pc file either and breaks with zlib-native Also remove unused site config file How did you determine this was unused? By removing it and rebuilding zlib(-native) and zlib dependant apps. In case it does turn out to be needed we should switch to cmake. I'm OK with having a OE hack for autotools, but a broken OE hack I don't think you understand what that site_config file triggers. It triggers code in siteconfig.bbclass which saves the *results* of the zlib configure for use in speeding up subsequent configure tasks. Does that change the need to remove it? I honestly don't know, I've never dealt with that part of siteconfig. If the file is needed I'll gladly respin the patch. regards, Koen signature.asc Description: Message signed with OpenPGP using GPGMail ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Coordinating inter-layer dependencies
Op 1 dec. 2011, om 14:13 heeft Martin Jansa het volgende geschreven: On Thu, Dec 01, 2011 at 01:02:38PM +, Richard Purdie wrote: On Thu, 2011-12-01 at 10:59 -0200, Otavio Salvador wrote: On Thu, Dec 1, 2011 at 10:37, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Thu, 2011-12-01 at 13:24 +0100, Martin Jansa wrote: A while back I've proposed to make .bbappend without corresponding .bb only big fat warning, but not fatal to parse. Now you cannot even build eglibc if there is libdrm bbappend you don't care at all about.. You can do this by setting: BB_DANGLINGAPPENDS_WARNONLY Good to know, thanks. This is even worse; you end up with a package without the changes done on the bbappend and as most bbappend files do not change PR, adding it later won't force a package update. Which is why its off by default. My point is you can do with Martin is suggesting, its just not without its drawbacks. I think the main advantage of this is that you're allowed to build stuff which doesn't use those dangling appends. Ie start build of eglibc if you know that nothing is bbappending to eglibc and to its dependency tree. And when .bbaappends are fixed you can disable BB_DANGLINGAPPENDS_WARNONLY and build the rest. But waiting for _all_ recipes in _all_ layers to get their .bbappends right can sometimes a bit long.. Which is why I sent this proposal, to give slow layers like meta-intel time to fix their stuff without breaking everyones build for 2 days till RP gets fed up and fixes it himself. I don't have the time to maintain forks of every layer like you do with SHR and frankly speaking, it shouldn't be needed. I understand that things like review cycles take some time which is why the proposal tries to workaround the delays in layers in OE-core itself instead of angrily demanding maintainers to act quicker. regards, Koen signature.asc Description: Message signed with OpenPGP using GPGMail ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Feedback on building openembedded-core for qemuarm. Excerpts from buildlog
Op 1 dec. 2011, om 14:16 heeft Philip Balister het volgende geschreven: On 11/29/2011 03:06 PM, Koen Kooi wrote: Op 29 nov. 2011, om 20:36 heeft Ulf Samuelsson het volgende geschreven: On 2011-11-29 16:03, Richard Purdie wrote: 2.ftp://elsie.nci.nih.gov/pub/tzcode2011i.tar.gz; is no longer available. tzdata , same problem. The recipe is located in two places. meta-openembedded/meta-oe/recipes-extended/tz*/tz*.bb have the problem This is what the build uses. This is something to raise with the meta-oe maintainers. I think there isn't a problem in OECore. Since we now have a large number of layers, maybe it is a good idea to define in each layer, how the git send email should behave in by providing a better .git/config file in the trunk? I.E: [sendemail] to = openembedded-core@lists.openembedded.org or meta-angstrom/.git/config [sendemail] to = angstrom-distro-de...@linuxtogo.org [format] subjectprefix = [meta-angstrom] No need to look in the README file with this. That assumes git-send-email is the preferred way, which it isn;'t for a lot of layers Even if it is not the preferred way, it would direct the discussion to the appropriate list. This would reduce the number of mis-directed emails to this list. You can't fix stupid, sadly. signature.asc Description: Message signed with OpenPGP using GPGMail ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] zlib 1.2.5: install pkgconfig file, needed for e.g. modern webkit
On Thu, 2011-12-01 at 15:58 +0100, Koen Kooi wrote: Op 1 dec. 2011, om 14:01 heeft Richard Purdie het volgende geschreven: On Wed, 2011-11-30 at 19:15 +0100, Koen Kooi wrote: Op 30 nov. 2011, om 18:52 heeft Richard Purdie het volgende geschreven: On Wed, 2011-11-30 at 14:40 +0100, Koen Kooi wrote: Upstream has grown cmake support which would allow us to dump the OE autotools hack, but the cmakefile doesn't install the .pc file either and breaks with zlib-native Also remove unused site config file How did you determine this was unused? By removing it and rebuilding zlib(-native) and zlib dependant apps. In case it does turn out to be needed we should switch to cmake. I'm OK with having a OE hack for autotools, but a broken OE hack I don't think you understand what that site_config file triggers. It triggers code in siteconfig.bbclass which saves the *results* of the zlib configure for use in speeding up subsequent configure tasks. Does that change the need to remove it? I honestly don't know, I've never dealt with that part of siteconfig. If the file is needed I'll gladly respin the patch. That file does make sense so please do :) Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] zlib 1.2.5: install pkgconfig file, needed for e.g. modern webkit
Upstream has grown cmake support which would allow us to dump the OE autotools
hack, but the cmakefile doesn't install the .pc file either and breaks with
zlib-native
Also remove unused site config file
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
meta/recipes-core/zlib/zlib_1.2.5.bb | 18 --
1 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/zlib/zlib_1.2.5.bb
b/meta/recipes-core/zlib/zlib_1.2.5.bb
index bca400c..b5756d9 100644
--- a/meta/recipes-core/zlib/zlib_1.2.5.bb
+++ b/meta/recipes-core/zlib/zlib_1.2.5.bb
@@ -7,12 +7,12 @@ LICENSE = Zlib
LIC_FILES_CHKSUM =
file://zlib.h;beginline=4;endline=23;md5=084e9c30e4e6272c3b057b13c6467f3d
DEPENDS = libtool-cross
-PR = r1
+PR = r3
SRC_URI = http://www.zlib.net/${BPN}-${PV}.tar.bz2 \
file://configure.ac \
file://Makefile.am \
- file://fix.inverted.LFS.logic.patch
+ file://fix.inverted.LFS.logic.patch
SRC_URI[md5sum] = be1e89810e66150f5b0327984d8625a0
SRC_URI[sha256sum] =
239aead2f22f16bfcfa6a6a5150dcbd6d6f2e4d1eaa8727b5769ea014120b307
@@ -24,4 +24,18 @@ do_configure_prepend () {
cp ${WORKDIR}/Makefile.am ${S}/
}
+do_install_append () {
+ sed \
+ -e 's:@prefix@:${prefix}:' \
+ -e 's:@exec_prefix@:${exec_prefix}:' \
+ -e 's:@libdir@:${libdir}:' \
+ -e 's:@sharedlibdir@:${libdir}:' \
+ -e 's:@includedir@:${includedir}:' \
+ -e 's:@VERSION@:${PV}:' \
+ zlib.pc.in zlib.pc
+
+ install -d ${D}${libdir}/pkgconfig
+ install -m 0644 zlib.pc ${D}${libdir}/pkgconfig/
+}
+
BBCLASSEXTEND = native nativesdk
--
1.7.2.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Coordinating inter-layer dependencies
On Thu, Dec 01, 2011 at 04:36:40PM +0100, Koen Kooi wrote: Op 1 dec. 2011, om 14:13 heeft Martin Jansa het volgende geschreven: On Thu, Dec 01, 2011 at 01:02:38PM +, Richard Purdie wrote: On Thu, 2011-12-01 at 10:59 -0200, Otavio Salvador wrote: On Thu, Dec 1, 2011 at 10:37, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Thu, 2011-12-01 at 13:24 +0100, Martin Jansa wrote: A while back I've proposed to make .bbappend without corresponding .bb only big fat warning, but not fatal to parse. Now you cannot even build eglibc if there is libdrm bbappend you don't care at all about.. You can do this by setting: BB_DANGLINGAPPENDS_WARNONLY Good to know, thanks. This is even worse; you end up with a package without the changes done on the bbappend and as most bbappend files do not change PR, adding it later won't force a package update. Which is why its off by default. My point is you can do with Martin is suggesting, its just not without its drawbacks. I think the main advantage of this is that you're allowed to build stuff which doesn't use those dangling appends. Ie start build of eglibc if you know that nothing is bbappending to eglibc and to its dependency tree. And when .bbaappends are fixed you can disable BB_DANGLINGAPPENDS_WARNONLY and build the rest. But waiting for _all_ recipes in _all_ layers to get their .bbappends right can sometimes a bit long.. Which is why I sent this proposal, to give slow layers like meta-intel time to fix their stuff without breaking everyones build for 2 days till RP gets fed up and fixes it himself. I don't have the time to maintain forks of every layer like you do with SHR and frankly speaking, it shouldn't be needed. I understand that things like review cycles take some time which is why the proposal tries to workaround the delays in layers in OE-core itself instead of angrily demanding maintainers to act quicker. But the problem is that we cannot even push newer .bbappend in advance, I would be happy to push libdrm-2.4.27.bbappend to master branch if it doesn't break my builds which were still on 2.4.26. Would be nice to be able to push danglings bbappends for stuff which is only sitting on ML for review just in case I'll be at daywork or on holidays or whatever when it gets applied to ie oe-core and someone just hits update button.. I think the problem is not with *big* layers like oe-core and meta-oe where is only 1 main maintainer but at least having full time job related to maintaining it. But to maintain some hobbyist or community layer in general in free time is sometimes pretty demanding just to stay compatible with the rest of world (not breaking the rest of world if they just want some BSP layer available from it). I wouldn't be surprised if meta-smartphone BSP layers get disabled in layerman next time I leave for month long holiday... Just my 2c -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] zlib 1.2.5: install pkgconfig file, needed for e.g. modern webkit
On Thu, Dec 01, 2011 at 04:48:36PM +0100, Koen Kooi wrote:
Upstream has grown cmake support which would allow us to dump the OE
autotools hack, but the cmakefile doesn't install the .pc file either and
breaks with zlib-native
Also remove unused site config file
^^ this is not true anymore..
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
meta/recipes-core/zlib/zlib_1.2.5.bb | 18 --
1 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/zlib/zlib_1.2.5.bb
b/meta/recipes-core/zlib/zlib_1.2.5.bb
index bca400c..b5756d9 100644
--- a/meta/recipes-core/zlib/zlib_1.2.5.bb
+++ b/meta/recipes-core/zlib/zlib_1.2.5.bb
@@ -7,12 +7,12 @@ LICENSE = Zlib
LIC_FILES_CHKSUM =
file://zlib.h;beginline=4;endline=23;md5=084e9c30e4e6272c3b057b13c6467f3d
DEPENDS = libtool-cross
-PR = r1
+PR = r3
SRC_URI = http://www.zlib.net/${BPN}-${PV}.tar.bz2 \
file://configure.ac \
file://Makefile.am \
-file://fix.inverted.LFS.logic.patch
+ file://fix.inverted.LFS.logic.patch
SRC_URI[md5sum] = be1e89810e66150f5b0327984d8625a0
SRC_URI[sha256sum] =
239aead2f22f16bfcfa6a6a5150dcbd6d6f2e4d1eaa8727b5769ea014120b307
@@ -24,4 +24,18 @@ do_configure_prepend () {
cp ${WORKDIR}/Makefile.am ${S}/
}
+do_install_append () {
+ sed \
+ -e 's:@prefix@:${prefix}:' \
+ -e 's:@exec_prefix@:${exec_prefix}:' \
+ -e 's:@libdir@:${libdir}:' \
+ -e 's:@sharedlibdir@:${libdir}:' \
+ -e 's:@includedir@:${includedir}:' \
+ -e 's:@VERSION@:${PV}:' \
+ zlib.pc.in zlib.pc
+
+ install -d ${D}${libdir}/pkgconfig
+ install -m 0644 zlib.pc ${D}${libdir}/pkgconfig/
+}
+
BBCLASSEXTEND = native nativesdk
--
1.7.2.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Coordinating inter-layer dependencies
Op 1 dec. 2011, om 16:56 heeft Martin Jansa het volgende geschreven: On Thu, Dec 01, 2011 at 04:36:40PM +0100, Koen Kooi wrote: Op 1 dec. 2011, om 14:13 heeft Martin Jansa het volgende geschreven: On Thu, Dec 01, 2011 at 01:02:38PM +, Richard Purdie wrote: On Thu, 2011-12-01 at 10:59 -0200, Otavio Salvador wrote: On Thu, Dec 1, 2011 at 10:37, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Thu, 2011-12-01 at 13:24 +0100, Martin Jansa wrote: A while back I've proposed to make .bbappend without corresponding .bb only big fat warning, but not fatal to parse. Now you cannot even build eglibc if there is libdrm bbappend you don't care at all about.. You can do this by setting: BB_DANGLINGAPPENDS_WARNONLY Good to know, thanks. This is even worse; you end up with a package without the changes done on the bbappend and as most bbappend files do not change PR, adding it later won't force a package update. Which is why its off by default. My point is you can do with Martin is suggesting, its just not without its drawbacks. I think the main advantage of this is that you're allowed to build stuff which doesn't use those dangling appends. Ie start build of eglibc if you know that nothing is bbappending to eglibc and to its dependency tree. And when .bbaappends are fixed you can disable BB_DANGLINGAPPENDS_WARNONLY and build the rest. But waiting for _all_ recipes in _all_ layers to get their .bbappends right can sometimes a bit long.. Which is why I sent this proposal, to give slow layers like meta-intel time to fix their stuff without breaking everyones build for 2 days till RP gets fed up and fixes it himself. I don't have the time to maintain forks of every layer like you do with SHR and frankly speaking, it shouldn't be needed. I understand that things like review cycles take some time which is why the proposal tries to workaround the delays in layers in OE-core itself instead of angrily demanding maintainers to act quicker. But the problem is that we cannot even push newer .bbappend in advance, I would be happy to push libdrm-2.4.27.bbappend to master branch if it doesn't break my builds which were still on 2.4.26. I thnk that either a) becomes a matter of PREFERRED_VERSION of your distro b) DEFAULT_PREFERENCE = -1 for the update in the grace period. Would be nice to be able to push danglings bbappends for stuff which is only sitting on ML for review just in case I'll be at daywork or on holidays or whatever when it gets applied to ie oe-core and someone just hits update button.. Which is where the grace period comes in :) I think the problem is not with *big* layers like oe-core and meta-oe where is only 1 main maintainer but at least having full time job related to maintaining it. But to maintain some hobbyist or community layer in general in free time is sometimes pretty demanding just to stay compatible with the rest of world (not breaking the rest of world if they just want some BSP layer available from it). I wouldn't be surprised if meta-smartphone BSP layers get disabled in layerman next time I leave for month long holiday... That's an unfortunate side effect of having a low busfactor. I'll put that in the shit happens bin. The proposal won't fix every breakage, but it would make all our lives a lot easier for most upgrades. Maybe after a while we'll realize that tracking OE-core is too painfull with a full set of slow layers, but I'd like to try this proposal first before giving up[1]. regards, Koen [1] Translation: I'm too lazy to add an automated 'lock layer' button to layerman right now signature.asc Description: Message signed with OpenPGP using GPGMail ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] zlib 1.2.5: install pkgconfig file, needed for e.g. modern webkit
/me puts on dunce cap
Op 1 dec. 2011, om 17:01 heeft Martin Jansa het volgende geschreven:
On Thu, Dec 01, 2011 at 04:48:36PM +0100, Koen Kooi wrote:
Upstream has grown cmake support which would allow us to dump the OE
autotools hack, but the cmakefile doesn't install the .pc file either and
breaks with zlib-native
Also remove unused site config file
^^ this is not true anymore..
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
meta/recipes-core/zlib/zlib_1.2.5.bb | 18 --
1 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/zlib/zlib_1.2.5.bb
b/meta/recipes-core/zlib/zlib_1.2.5.bb
index bca400c..b5756d9 100644
--- a/meta/recipes-core/zlib/zlib_1.2.5.bb
+++ b/meta/recipes-core/zlib/zlib_1.2.5.bb
@@ -7,12 +7,12 @@ LICENSE = Zlib
LIC_FILES_CHKSUM =
file://zlib.h;beginline=4;endline=23;md5=084e9c30e4e6272c3b057b13c6467f3d
DEPENDS = libtool-cross
-PR = r1
+PR = r3
SRC_URI = http://www.zlib.net/${BPN}-${PV}.tar.bz2 \
file://configure.ac \
file://Makefile.am \
- file://fix.inverted.LFS.logic.patch
+ file://fix.inverted.LFS.logic.patch
SRC_URI[md5sum] = be1e89810e66150f5b0327984d8625a0
SRC_URI[sha256sum] =
239aead2f22f16bfcfa6a6a5150dcbd6d6f2e4d1eaa8727b5769ea014120b307
@@ -24,4 +24,18 @@ do_configure_prepend () {
cp ${WORKDIR}/Makefile.am ${S}/
}
+do_install_append () {
+sed \
+-e 's:@prefix@:${prefix}:' \
+-e 's:@exec_prefix@:${exec_prefix}:' \
+-e 's:@libdir@:${libdir}:' \
+-e 's:@sharedlibdir@:${libdir}:' \
+-e 's:@includedir@:${includedir}:' \
+-e 's:@VERSION@:${PV}:' \
+zlib.pc.in zlib.pc
+
+install -d ${D}${libdir}/pkgconfig
+install -m 0644 zlib.pc ${D}${libdir}/pkgconfig/
+}
+
BBCLASSEXTEND = native nativesdk
--
1.7.2.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3] zlib 1.2.5: install pkgconfig file, needed for e.g. modern webkit
Upstream has grown cmake support which would allow us to dump the OE autotools
hack, but the cmakefile doesn't install the .pc file either and breaks with
zlib-native
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
meta/recipes-core/zlib/zlib_1.2.5.bb | 18 --
1 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/zlib/zlib_1.2.5.bb
b/meta/recipes-core/zlib/zlib_1.2.5.bb
index bca400c..b5756d9 100644
--- a/meta/recipes-core/zlib/zlib_1.2.5.bb
+++ b/meta/recipes-core/zlib/zlib_1.2.5.bb
@@ -7,12 +7,12 @@ LICENSE = Zlib
LIC_FILES_CHKSUM =
file://zlib.h;beginline=4;endline=23;md5=084e9c30e4e6272c3b057b13c6467f3d
DEPENDS = libtool-cross
-PR = r1
+PR = r3
SRC_URI = http://www.zlib.net/${BPN}-${PV}.tar.bz2 \
file://configure.ac \
file://Makefile.am \
- file://fix.inverted.LFS.logic.patch
+ file://fix.inverted.LFS.logic.patch
SRC_URI[md5sum] = be1e89810e66150f5b0327984d8625a0
SRC_URI[sha256sum] =
239aead2f22f16bfcfa6a6a5150dcbd6d6f2e4d1eaa8727b5769ea014120b307
@@ -24,4 +24,18 @@ do_configure_prepend () {
cp ${WORKDIR}/Makefile.am ${S}/
}
+do_install_append () {
+ sed \
+ -e 's:@prefix@:${prefix}:' \
+ -e 's:@exec_prefix@:${exec_prefix}:' \
+ -e 's:@libdir@:${libdir}:' \
+ -e 's:@sharedlibdir@:${libdir}:' \
+ -e 's:@includedir@:${includedir}:' \
+ -e 's:@VERSION@:${PV}:' \
+ zlib.pc.in zlib.pc
+
+ install -d ${D}${libdir}/pkgconfig
+ install -m 0644 zlib.pc ${D}${libdir}/pkgconfig/
+}
+
BBCLASSEXTEND = native nativesdk
--
1.7.2.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] trace-cmd: Add blktrace_api compatibility for TC_BARRIER
From: Darren Hart dvh...@linux.intel.com
Newer kernels replace TC_BARRIER with TC_FLUSH. Ensure trace-cmd
can build regardless of the linux-kernel-headers version.
This is intended as a stop-gap to get the builds working again. A
proper fix will need to be discussed with the trace-cmd community.
Signed-off-by: Darren Hart dvh...@linux.intel.com
---
meta/recipes-kernel/trace-cmd/kernelshark_1.2.bb |3 +-
.../trace-cmd/blktrace-api-compatibility.patch | 29
meta/recipes-kernel/trace-cmd/trace-cmd_1.2.bb |3 +-
3 files changed, 33 insertions(+), 2 deletions(-)
create mode 100644
meta/recipes-kernel/trace-cmd/trace-cmd/blktrace-api-compatibility.patch
diff --git a/meta/recipes-kernel/trace-cmd/kernelshark_1.2.bb
b/meta/recipes-kernel/trace-cmd/kernelshark_1.2.bb
index aa070a9..beb203f 100644
--- a/meta/recipes-kernel/trace-cmd/kernelshark_1.2.bb
+++ b/meta/recipes-kernel/trace-cmd/kernelshark_1.2.bb
@@ -14,7 +14,8 @@ inherit pkgconfig
SRC_URI =
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/trace-cmd.git;protocol=git
\
file://addldflags.patch \
- file://make-docs-optional.patch
+ file://make-docs-optional.patch \
+ file://trace-cmd/blktrace-api-compatibility.patch
S = ${WORKDIR}/git
EXTRA_OEMAKE = 'CC=${CC}' 'AR=${AR}' 'prefix=${prefix}' gui
diff --git
a/meta/recipes-kernel/trace-cmd/trace-cmd/blktrace-api-compatibility.patch
b/meta/recipes-kernel/trace-cmd/trace-cmd/blktrace-api-compatibility.patch
new file mode 100644
index 000..0789e9f
--- /dev/null
+++ b/meta/recipes-kernel/trace-cmd/trace-cmd/blktrace-api-compatibility.patch
@@ -0,0 +1,29 @@
+trace-cmd: Add blktrace_api compatibility for TC_BARRIER
+
+Newer kernels replace TC_BARRIER with TC_FLUSH. Ensure trace-cmd
+can build regardless of the linux-kernel-headers version.
+
+Upstream-Status: Innapropriate [Stop gap]
+
+Signed-off-by: Darren Hart dvh...@linux.intel.com
+
+diff --git a/plugin_blk.c b/plugin_blk.c
+index 9327b17..c8e5e1c 100644
+--- a/plugin_blk.c
b/plugin_blk.c
+@@ -44,6 +44,15 @@ struct blk_data {
+ unsigned short pdu_len;
+ };
+
++/*
++ * Newer kernels don't define BLK_TC_BARRIER and have replaced it with
++ * BLK_TC_FLUSH. In this case, define it here and report FLUSHES as BARRIERS
as
++ * a workaround, as described in:
++ *
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=c09c47caedc9854d59378d6e34c989e51cfdd2b4
++ */
++#ifndef BLK_TC_BARRIER
++#define BLK_TC_BARRIER 12
++#endif
+ static void fill_rwbs(char *rwbs, int action, unsigned int bytes)
+ {
+ int i = 0;
diff --git a/meta/recipes-kernel/trace-cmd/trace-cmd_1.2.bb
b/meta/recipes-kernel/trace-cmd/trace-cmd_1.2.bb
index 1b9231b..38bfbb5 100644
--- a/meta/recipes-kernel/trace-cmd/trace-cmd_1.2.bb
+++ b/meta/recipes-kernel/trace-cmd/trace-cmd_1.2.bb
@@ -11,7 +11,8 @@ inherit pkgconfig
SRC_URI =
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/trace-cmd.git;protocol=git
\
file://addldflags.patch \
- file://make-docs-optional.patch
+ file://make-docs-optional.patch \
+ file://trace-cmd/blktrace-api-compatibility.patch
S = ${WORKDIR}/git
EXTRA_OEMAKE = 'prefix=${prefix}'
--
1.7.6.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] trace-cmd: Fix build failure due to blktrace_api change
From: Darren Hart dvh...@linux.intel.com The following changes since commit 2ebfb9d9ed7554180c3c077b14291a1853f8e2ef: puzzles: Ensure to link against libm for math functions (2011-12-01 14:30:49 +) are available in the git repository at: git://git.yoctoproject.org/user-contrib/dvhart/oe-core trace-cmd http://git.yoctoproject.org/cgit.cgi/user-contrib/dvhart/oe-core/log/?h=trace-cmd Darren Hart (1): trace-cmd: Add blktrace_api compatibility for TC_BARRIER meta/recipes-kernel/trace-cmd/kernelshark_1.2.bb |3 +- .../trace-cmd/blktrace-api-compatibility.patch | 29 meta/recipes-kernel/trace-cmd/trace-cmd_1.2.bb |3 +- 3 files changed, 33 insertions(+), 2 deletions(-) create mode 100644 meta/recipes-kernel/trace-cmd/trace-cmd/blktrace-api-compatibility.patch -- 1.7.6.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Feedback on building openembedded-core for qemuarm. Excerpts from buildlog
2011-12-01 16:37, Koen Kooi skrev: Op 1 dec. 2011, om 14:16 heeft Philip Balister het volgende geschreven: On 11/29/2011 03:06 PM, Koen Kooi wrote: Op 29 nov. 2011, om 20:36 heeft Ulf Samuelsson het volgende geschreven: On 2011-11-29 16:03, Richard Purdie wrote: 2.ftp://elsie.nci.nih.gov/pub/tzcode2011i.tar.gz; is no longer available. tzdata , same problem. The recipe is located in two places. meta-openembedded/meta-oe/recipes-extended/tz*/tz*.bb have the problem This is what the build uses. This is something to raise with the meta-oe maintainers. I think there isn't a problem in OECore. Since we now have a large number of layers, maybe it is a good idea to define in each layer, how the git send email should behave in by providing a better .git/config file in the trunk? I.E: [sendemail] to = openembedded-core@lists.openembedded.org or meta-angstrom/.git/config [sendemail] to = angstrom-distro-de...@linuxtogo.org [format] subjectprefix = [meta-angstrom] No need to look in the README file with this. That assumes git-send-email is the preferred way, which it isn;'t for a lot of layers Even if it is not the preferred way, it would direct the discussion to the appropriate list. This would reduce the number of mis-directed emails to this list. You can't fix stupid, sadly. Tend to disagree. The whole purpose of OE is to make it possible for people, stupid or not, to go off and make things which they would not be able to do on their own. As I see it, it is no real drawback of adding this, and at least some benefit. As for not beeing the preferred way, I think that people that engage themselves in a layer should adopt the preferred way. Anyone seeing a bad layer, applicable only to a small subset of users, interfering with their build should not be expected to put a lof of effort into the fix, except reporting it. Then the mailing list is probably the easiest thing to use. If this is not there, expect them to send it to the official list. BR Ulf ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core -- Best Regards Ulf Samuelsson eMagii ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] lzop-1.03: add recipe
This is needed by some kernels when CONFIG_KERNEL_LZO=y (specifically, given
the current defconfig, this affects linux-omap4 2.6 in the meta-ti layer).
Signed-off-by: Christopher Larson chris_lar...@mentor.com
---
meta/recipes-support/lzop/lzop/acinclude.m4 | 390
+++
meta/recipes-support/lzop/lzop_1.03.bb | 25 ++
2 files changed, 415 insertions(+), 0 deletions(-)
create mode 100644 meta/recipes-support/lzop/lzop/acinclude.m4
create mode 100644 meta/recipes-support/lzop/lzop_1.03.bb
diff --git a/meta/recipes-support/lzop/lzop/acinclude.m4
b/meta/recipes-support/lzop/lzop/acinclude.m4
new file mode 100644
index 000..0029c19
--- /dev/null
+++ b/meta/recipes-support/lzop/lzop/acinclude.m4
@@ -0,0 +1,390 @@
+
+AC_DEFUN([mfx_ACC_CHECK_ENDIAN], [
+AC_C_BIGENDIAN([AC_DEFINE(ACC_ABI_BIG_ENDIAN,1,[Define to 1 if your
machine is big endian.])],[AC_DEFINE(ACC_ABI_LITTLE_ENDIAN,1,[Define to
1 if your machine is little endian.])])
+])#
+
+AC_DEFUN([mfx_ACC_CHECK_HEADERS], [
+AC_HEADER_TIME
+AC_CHECK_HEADERS([assert.h ctype.h dirent.h errno.h fcntl.h float.h
limits.h malloc.h memory.h setjmp.h signal.h stdarg.h stddef.h stdint.h
stdio.h stdlib.h string.h strings.h time.h unistd.h utime.h sys/stat.h
sys/time.h sys/types.h sys/wait.h])
+])#
+
+AC_DEFUN([mfx_ACC_CHECK_FUNCS], [
+AC_CHECK_FUNCS(access alloca atexit atoi atol chmod chown ctime
difftime fstat gettimeofday gmtime localtime longjmp lstat memcmp memcpy
memmove memset mktime qsort raise setjmp signal snprintf strcasecmp
strchr strdup strerror strftime stricmp strncasecmp strnicmp strrchr
strstr time umask utime vsnprintf)
+])#
+
+
+AC_DEFUN([mfx_ACC_CHECK_SIZEOF], [
+AC_CHECK_SIZEOF(short)
+AC_CHECK_SIZEOF(int)
+AC_CHECK_SIZEOF(long)
+
+AC_CHECK_SIZEOF(long long)
+AC_CHECK_SIZEOF(__int16)
+AC_CHECK_SIZEOF(__int32)
+AC_CHECK_SIZEOF(__int64)
+
+AC_CHECK_SIZEOF(void *)
+AC_CHECK_SIZEOF(size_t)
+AC_CHECK_SIZEOF(ptrdiff_t)
+])#
+
+
+# /***
+# // Check for ACC_conformance
+# /
+
+AC_DEFUN([mfx_ACC_ACCCHK], [
+mfx_tmp=$1
+mfx_save_CPPFLAGS=$CPPFLAGS
+dnl in Makefile.in $(INCLUDES) will be before $(CPPFLAGS), so we mimic
this here
+test X$mfx_tmp = X || CPPFLAGS=$mfx_tmp $CPPFLAGS
+
+AC_MSG_CHECKING([whether your compiler passes the ACC conformance test])
+
+AC_LANG_CONFTEST([AC_LANG_PROGRAM(
+[[#define ACC_CONFIG_NO_HEADER 1
+#include acc/acc.h
+#include acc/acc_incd.h
+#undef ACCCHK_ASSERT
+#define ACCCHK_ASSERT(expr) ACC_COMPILE_TIME_ASSERT_HEADER(expr)
+#include acc/acc_chk.ch
+#undef ACCCHK_ASSERT
+static void test_acc_compile_time_assert(void) {
+#define ACCCHK_ASSERT(expr) ACC_COMPILE_TIME_ASSERT(expr)
+#include acc/acc_chk.ch
+#undef ACCCHK_ASSERT
+}
+#undef NDEBUG
+#include assert.h
+static int test_acc_run_time_assert(int r) {
+#define ACCCHK_ASSERT(expr) assert(expr);
+#include acc/acc_chk.ch
+#undef ACCCHK_ASSERT
+return r;
+}
+]], [[
+test_acc_compile_time_assert();
+if (test_acc_run_time_assert(1) != 1) return 1;
+]]
+)])
+
+mfx_tmp=FAILED
+_AC_COMPILE_IFELSE([], [mfx_tmp=yes])
+rm -f conftest.$ac_ext conftest.$ac_objext
+
+CPPFLAGS=$mfx_save_CPPFLAGS
+
+AC_MSG_RESULT([$mfx_tmp])
+case x$mfx_tmp in
+ xpassed | xyes) ;;
+ *)
+AC_MSG_NOTICE([])
+AC_MSG_NOTICE([Your compiler failed the ACC conformance test - for
details see ])
+AC_MSG_NOTICE([`config.log'. Please check that log file and
consider sending])
+AC_MSG_NOTICE([a patch or bug-report to ${PACKAGE_BUGREPORT}.])
+AC_MSG_NOTICE([Thanks for your support.])
+AC_MSG_NOTICE([])
+AC_MSG_ERROR([ACC conformance test failed. Stop.])
+dnlAS_EXIT
+;;
+esac
+])# mfx_ACC_ACCCHK
+
+
+# /***
+# // Check for ACC_conformance
+# /
+
+AC_DEFUN([mfx_MINIACC_ACCCHK], [
+mfx_tmp=$1
+mfx_save_CPPFLAGS=$CPPFLAGS
+dnl in Makefile.in $(INCLUDES) will be before $(CPPFLAGS), so we mimic
this here
+test X$mfx_tmp = X || CPPFLAGS=$mfx_tmp $CPPFLAGS
+
+AC_MSG_CHECKING([whether your compiler passes the ACC conformance test])
+
+AC_LANG_CONFTEST([AC_LANG_PROGRAM(
+[[#define ACC_CONFIG_NO_HEADER 1
+#define ACC_WANT_ACC_INCD_H 1
+#include $2
+
+#define ACC_WANT_ACC_CHK_CH 1
+#undef ACCCHK_ASSERT
+#define ACCCHK_ASSERT(expr) ACC_COMPILE_TIME_ASSERT_HEADER(expr)
+#include $2
+
+#define ACC_WANT_ACC_CHK_CH 1
+#undef ACCCHK_ASSERT
+#define ACCCHK_ASSERT(expr) ACC_COMPILE_TIME_ASSERT(expr)
+static void test_acc_compile_time_assert(void) {
+#include $2
+}
+
+#undef NDEBUG
+#include assert.h
+#define ACC_WANT_ACC_CHK_CH 1
+#undef ACCCHK_ASSERT
+#define ACCCHK_ASSERT(expr) assert(expr);
+static int test_acc_run_time_assert(int r) {
+#include $2
+return r;
+}
+]], [[
+test_acc_compile_time_assert();
+if (test_acc_run_time_assert(1) != 1) return 1;
Re: [OE-core] [PATCH 1/4] gmp: also generate the libgmpcxx library package it properly
On Tue, 2011-11-29 at 14:51 -0800, Kamble, Nitin A wrote: Thank you for the explanation. BTW where can I find official rules about signed-off-by line The Signed-off-by idiom originated with the kernel people and Documentation/SubmittingPatches in the linux source tree contains a fairly good description of what it means to them. I'm not sure that there are any official rules about its use in OE apart from what's in the Commit Patch Message Guidelines (see the wiki). p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] metacity: bump PR for xcb-util change
Signed-off-by: Koen Kooi k...@dominion.thruhere.net --- meta/recipes-gnome/gnome/metacity_2.30.3.bb |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/meta/recipes-gnome/gnome/metacity_2.30.3.bb b/meta/recipes-gnome/gnome/metacity_2.30.3.bb index b9ffce0..a464b72 100644 --- a/meta/recipes-gnome/gnome/metacity_2.30.3.bb +++ b/meta/recipes-gnome/gnome/metacity_2.30.3.bb @@ -5,7 +5,7 @@ LIC_FILES_CHKSUM = file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \ file://src/include/main.h;endline=24;md5=c2242df552c880280315989bab626b90 DEPENDS = startup-notification gtk+ gconf gdk-pixbuf-native libcanberra gnome-doc-utils -PR = r2 +PR = r3 inherit gnome update-alternatives -- 1.7.2.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] linux-yocto: consolidated pull request
On Thu, Dec 1, 2011 at 12:25 AM, Saul Wold saul.w...@intel.com wrote: On 11/30/2011 04:36 PM, Bruce Ashfield wrote: Richard/Saul, FYI: I can't get git-send email to work over the hotel wifi, so I can't chain the patches to this email. If you want me to send the patches separately, let me know. But for now, this is the best I can do. This pull request represents a collection of changes that were part of yocto M1 work, and that set the stage for more updates that will follow in the not too distant future. I've bumped the 3.0 kernel to the 3.0.10 baseline (3.0.11 is out, but not in this merge request) and updated our -rt patches to the latest upstream -rt series. This also drops the 2.6.34 recipe and leaves it to be supported in previous releases. If there's somewhere else I should be putting it, let me know and I'll put it there. The kernel revision updates have been built and boot tested by Tom and myself. And we have't seen any problems. Also included in this are some changes to kernel tools that prepare to move the kernel tools into the kernel tree itself. They also move us to doing configuration auditing using the merge_config script that Darren and John Stultz have been working on. And finally there's a small tweak to install the kernel tools via Makefile in the package itself, something that I recall Richard mentioning to me over 2 years ago a meeting .. so I thought I'd finally get to it. Cheers, brucedvh...@linux.intel.com cc: Tom Zanussi tom.zanu...@intel.com cc: Darren Hart dvh...@linux.intel.com The following changes since commit d7cd934376ae1edaf7055ec635eb3c85fdbf58b3: squashfs-tools: fix PR, those should start with 'r' (2011-11-30 23:37:44 +) are available in the git repository at: git://git.pokylinux.org/poky-contrib zedd/kernel http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel Bruce Ashfield (7): kern-tools: add pre_config and merge_config.sh to the list of tools kernel-yocto: support allnoconfig base configuration linux-yocto: remove 2.6.34 recipes linux-yocto: v3.0.9 + enhancements linux-yocto: v3.0.10 + rt27 linux-yocto: prefer in-tree tools to external ones kern-tools: use Makefile provided install rules meta/classes/kernel-yocto.bbclass | 24 +- .../kern-tools/kern-tools-native_git.bb | 15 ++ meta/recipes-kernel/linux/linux-yocto-rt_2.6.34.bb | 38 --- meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb | 8 ++-- meta/recipes-kernel/linux/linux-yocto_2.6.34.bb | 49 meta/recipes-kernel/linux/linux-yocto_3.0.bb | 18 6 files changed, 39 insertions(+), 113 deletions(-) delete mode 100644 meta/recipes-kernel/linux/linux-yocto-rt_2.6.34.bb delete mode 100644 meta/recipes-kernel/linux/linux-yocto_2.6.34.bb I had a problem with this change set, it gave me the following: NOTE: Error expanding variable do_kernel_checkout | ETA: 00:00:07 ERROR: Unable to parse /intel/poky/distro/meta/recipes-kernel/linux-libc-headers/linux-libc-headers-yocto_git.bb Aha. None of my BSPs use this, so I didn't see it. I'll have to re-send this post M1, since I'll be on a plane soon and can't resend this before next week. Cheers, Bruce during parsing. Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core -- 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 1/4] gmp: also generate the libgmpcxx library package it properly
On Thu, 2011-12-01 at 16:57 +, Phil Blundell wrote: On Tue, 2011-11-29 at 14:51 -0800, Kamble, Nitin A wrote: Thank you for the explanation. BTW where can I find official rules about signed-off-by line The Signed-off-by idiom originated with the kernel people and Documentation/SubmittingPatches in the linux source tree contains a fairly good description of what it means to them. I'm not sure that there are any official rules about its use in OE apart from what's in the Commit Patch Message Guidelines (see the wiki). The yocto docs do mention what the specific meaning of the line is. Nobody should be adding that line unless they understand what it means. Its based off the kernel's model. http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#how-to-submit-a-change Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/4] gmp: also generate the libgmpcxx library package it properly
Op 1 dec. 2011, om 18:17 heeft Richard Purdie het volgende geschreven: On Thu, 2011-12-01 at 16:57 +, Phil Blundell wrote: On Tue, 2011-11-29 at 14:51 -0800, Kamble, Nitin A wrote: Thank you for the explanation. BTW where can I find official rules about signed-off-by line The Signed-off-by idiom originated with the kernel people and Documentation/SubmittingPatches in the linux source tree contains a fairly good description of what it means to them. I'm not sure that there are any official rules about its use in OE apart from what's in the Commit Patch Message Guidelines (see the wiki). The yocto docs do mention what the specific meaning of the line is. pedantic modeBut this is oe-core./pedantic mode. Shall we all agree it's the same for OE-core as well? signature.asc Description: Message signed with OpenPGP using GPGMail ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/1] trace-cmd: Fix build failure due to blktrace_api change
On Thu, 2011-12-01 at 08:22 -0800, Darren Hart wrote: From: Darren Hart dvh...@linux.intel.com The following changes since commit 2ebfb9d9ed7554180c3c077b14291a1853f8e2ef: puzzles: Ensure to link against libm for math functions (2011-12-01 14:30:49 +) are available in the git repository at: git://git.yoctoproject.org/user-contrib/dvhart/oe-core trace-cmd http://git.yoctoproject.org/cgit.cgi/user-contrib/dvhart/oe-core/log/?h=trace-cmd Darren Hart (1): trace-cmd: Add blktrace_api compatibility for TC_BARRIER I tested this and found it needed a couple of tweaks (fix the SRC_URI and add PR bumps). I fixed that and have merged it. 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 v3] zlib 1.2.5: install pkgconfig file, needed for e.g. modern webkit
On Thu, 2011-12-01 at 17:04 +0100, Koen Kooi wrote: Upstream has grown cmake support which would allow us to dump the OE autotools hack, but the cmakefile doesn't install the .pc file either and breaks with zlib-native Signed-off-by: Koen Kooi k...@dominion.thruhere.net --- meta/recipes-core/zlib/zlib_1.2.5.bb | 18 -- 1 files changed, 16 insertions(+), 2 deletions(-) Merged to master, thanks. Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Reproducible build problem with BB_NUMBER_THREADS=8
# source='libcg_ba.cpp' object='libcg_ba.o' libtool=no
arm-angstrom-linux-gnueabi-g++ -march=armv5te -mno-thumb -mthumb-interwork
-mtune=arm926ej-s -mthumb-interwork -mno-thumb
--sysroot=/media/SSD/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/qemuarm
-DHAVE_CONFIG_H -I. -I.. -I../include-O2 -pipe -g
-feliminate-unused-debug-types -fpermissive -fvisibility-inlines-hidden
-fvisibility-inlines-hidden -c -o libcg_ba.o libcg_ba.cpp
libcg_ba.cpp:18:18: fatal error: string: No such file or directory
compilation terminated.
Hi Ulf,
that does not look like the BB_THREAD bug. It is more the wrong c++ include
dir bug, when --sysroot is not used.
Problem is in gcc-cross-configure.inc:
EXTRA_OECONF_PATHS =
--with-local-prefix=${STAGING_DIR_TARGET}${target_exec_prefix} \
--with-gxx-include-dir=${target_includedir}/c++ \
which results in c++ defaultheadersearchdir ./usr/bin/usr/include/c++ and
so the the string c++ header is not found.
Bye Henning
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/4] gmp: also generate the libgmpcxx library package it properly
On 01/12/11 09:26, Koen Kooi wrote: Op 1 dec. 2011, om 18:17 heeft Richard Purdie het volgende geschreven: On Thu, 2011-12-01 at 16:57 +, Phil Blundell wrote: On Tue, 2011-11-29 at 14:51 -0800, Kamble, Nitin A wrote: Thank you for the explanation. BTW where can I find official rules about signed-off-by line The Signed-off-by idiom originated with the kernel people and Documentation/SubmittingPatches in the linux source tree contains a fairly good description of what it means to them. I'm not sure that there are any official rules about its use in OE apart from what's in the Commit Patch Message Guidelines (see the wiki). The yocto docs do mention what the specific meaning of the line is. pedantic modeBut this is oe-core./pedantic mode. Shall we all agree it's the same for OE-core as well? Isn't that the standard mode? ;-) I expect folks have the same understanding as stated in the kernel and Yocto docs when using SOB - I see no reason for OE Core to introduce ambiguity. Joshua -- Joshua Lock Yocto Project Johannes factotum Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/4] gmp: also generate the libgmpcxx library package it properly
Op 1 dec. 2011, om 19:37 heeft Joshua Lock het volgende geschreven: On 01/12/11 09:26, Koen Kooi wrote: Op 1 dec. 2011, om 18:17 heeft Richard Purdie het volgende geschreven: On Thu, 2011-12-01 at 16:57 +, Phil Blundell wrote: On Tue, 2011-11-29 at 14:51 -0800, Kamble, Nitin A wrote: Thank you for the explanation. BTW where can I find official rules about signed-off-by line The Signed-off-by idiom originated with the kernel people and Documentation/SubmittingPatches in the linux source tree contains a fairly good description of what it means to them. I'm not sure that there are any official rules about its use in OE apart from what's in the Commit Patch Message Guidelines (see the wiki). The yocto docs do mention what the specific meaning of the line is. pedantic modeBut this is oe-core./pedantic mode. Shall we all agree it's the same for OE-core as well? Isn't that the standard mode? ;-) It actually is, glad someone noticed :) I expect folks have the same understanding as stated in the kernel and Yocto docs when using SOB - I see no reason for OE Core to introduce ambiguity. Joshua -- Joshua Lock Yocto Project Johannes factotum Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core signature.asc Description: Message signed with OpenPGP using GPGMail ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Coordinating inter-layer dependencies
On Thu, Dec 1, 2011 at 8:33 AM, Chris Larson clar...@kergoth.com wrote: This is even worse; you end up with a package without the changes done on the bbappend and as most bbappend files do not change PR, adding it later won't force a package update. People use bbappends without changing PR? I've been doing a PR .= .1 or whatever in every bbappend I've created since they were added to bitbake, and used to do the same with amend.inc. It can result in some long PR values, but I'd rather that than the alternative.. It would be nice to have something that WARNS or FATALS if there is no PR modification in the bbappend. This should be required IMO but I guess there could be some other issues that this would cause. -M ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Coordinating inter-layer dependencies
On Thu, Dec 1, 2011 at 5:23 AM, Koen Kooi k...@dominion.thruhere.net wrote: Hi, During the past month there have been a number of updates to OE-core recipes that triggered parsing errors due to bbappend in other layers. A small seleciton: * netbase * libdrm * xserver-xorg * clutter My view is that layer maintainers need to keep an eye on potential breakage and have updates ready when patches land into OE-core. Looking back I can see that while the situation is improving a bit, it's still not working. The problem with slow updates to layers is that (with my angstrom hat on) users (and with my TI hat on) customers and coworkers can't do builds without rm'ing the bbappends or disabling the layer. This is bad for a number of reasons: 1) It creates unmanaged local diffs 2) it can cause PR to fluctuate back and forth if you rm is a bit overzealous or if you disable the complete layer. My proposal is that OE-core recipe upgrades with known bbappends look like this: 1) add new version with a warning about bbappends 2) wait a N days (2 N 7) 3) delete old version To avoid stressing out RP and Sau! I would strongly urge layer maintainers to respond to recipe update patches with I have a bbappend, but my review process needs time, please use the above proposal if you need time to test and update your bbappends. We're all human in the end and timezone differences aren't always helping with these kinds of problems, so let's work together to minimize parsing breakage. Related to that: Please include information on how to send patches upstream in your layer/repo README. The meta-intel/emenlow lacks that and the top level README doesn't mention that there are sublevel READMEs. Why don't we make a version of bbappend that applies to all packages with the same name? This would fix the constant changing netbase_vXYZ.bbappend issue. -M ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Coordinating inter-layer dependencies
On Thu, Dec 1, 2011 at 12:55 PM, McClintock Matthew-B29882 b29...@freescale.com wrote: To avoid stressing out RP and Sau! I would strongly urge layer maintainers to respond to recipe update patches with I have a bbappend, but my review process needs time, please use the above proposal if you need time to test and update your bbappends. We're all human in the end and timezone differences aren't always helping with these kinds of problems, so let's work together to minimize parsing breakage. Related to that: Please include information on how to send patches upstream in your layer/repo README. The meta-intel/emenlow lacks that and the top level README doesn't mention that there are sublevel READMEs. Why don't we make a version of bbappend that applies to all packages with the same name? This would fix the constant changing netbase_vXYZ.bbappend issue. I'm pretty sure going by filename was a conscious design decision in bitbake, to keep things simple and avoid the need to parse up front before being able to determine the appends to use. RP would know the details. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Coordinating inter-layer dependencies
On Thu, 2011-12-01 at 14:07 +0100, Martin Jansa wrote:
On Thu, Dec 01, 2011 at 10:59:03AM -0200, Otavio Salvador wrote:
On Thu, Dec 1, 2011 at 10:37, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Thu, 2011-12-01 at 13:24 +0100, Martin Jansa wrote:
A while back I've proposed to make .bbappend without corresponding .bb
only big fat warning, but not fatal to parse. Now you cannot even build
eglibc if there is libdrm bbappend you don't care at all about..
You can do this by setting:
BB_DANGLINGAPPENDS_WARNONLY
This is even worse; you end up with a package without the changes done on
the bbappend and as most bbappend files do not change PR, adding it later
won't force a package update.
If we find a way to allow PRINC in multiple bbappends for same .bb then
we can say that every .bbappend should use PRINC.
For record I'll include my discussion about PRINC with RP and kergoth:
10:47 JaMa RP__: is there any way to improve PRINC concept to allow
multiple increments for same recipe while parsing multiple layers?
10:48 RP__ JaMa: PRINC_append = .1 ?
10:49 JaMa RP__: ie when meta-openmoko sets PRINC = 1 and meta-shr sets
PRINC = 2 then if you're unlucky meta-openmoko is parsed later and bumping
PRINC in meta-shr won't help
10:49 RP__ JaMa: I wonder if you could do PRINC := ${PRINC + 1}
10:50 JaMa and do we have default PRINC = 0 somewhere?
10:50 RP__ JaMa: you might need to add that
10:50 JaMa ok, I'll try this, thanks
10:51 JaMa currently I'm moving PRINC only to meta-shr layer.. but that
breaks stuff if someone is using any BSP layer from meta-smartphone..
14:53 JaMa RP__: btw that PRINC trick didn't work (int type didn't like
expresion :/)
15:13 RP__ JaMa: ah, try PRINC := ${int(PRINC) + 1}
15:21 JaMa RP__: still ValueError: invalid literal for int() with base 10:
'${int(PRINC) + 1}'
15:21 JaMa with added PRINC := 0 to bitbake.conf
15:22 RP__ PRINC := ${int(d.getVar(PRINC)) + 1} ? :/
15:22 JaMa whole log http://paste.pocoo.org/show/514437/
15:22 * RP__ was trying to be too clever I suspect
15:23 JaMa ValueError: invalid literal for int() with base 10:
'${int(d.getVar(PRINC)) + 1}'
15:41 kergoth PRINC is unquoted there, so it tries to get a value for a
key of None
16:24 RP__ kergoth: right, trying to do too many things at once :/
16:24 RP__ kergoth: any thoughts on that knotty change to add the footer?
17:05 JaMa kergoth: something like this? ValueError: invalid literal for
int() with base 10: ${int(d.getVar('PRINC')) + 1}
Maybe someone else has better idea?
Looking at that I was missing something obvious. Try:
PRINC := ${@int(PRINC) + 1}
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/4] Misc recipe fixes
On Tue, 2011-11-29 at 11:30 -0800, nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com Earlier libtool commit is reworked to keep the SUMMARY line and clean up the white space changes gmp commit is also reworked to simplify the changes as per Phils feedback. Nitin The following changes since commit cf02474bda67f4f1043b2e95e1b371b2354585a7: qt-mobility: Add missing patch (2011-11-29 14:36:18 +) are available in the git repository at: git://git.pokylinux.org/poky-contrib nitin/misc http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=nitin/misc Nitin A Kamble (4): gmp: also generate the libgmpcxx library package it properly binutils: fix for .debug files QA warnings libtool: Upgrade from 2.4 - 2.4.2 libx11-trip_1.4.4: fix the source tarall checksums Merged to master (apart from the libx11 change which I'd already merged a different patch for), thanks. Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Reproducible build problem with BB_NUMBER_THREADS=8
On Thu, 2011-12-01 at 18:34 +0100, Henning Heinold wrote:
# source='libcg_ba.cpp' object='libcg_ba.o' libtool=no
arm-angstrom-linux-gnueabi-g++ -march=armv5te -mno-thumb
-mthumb-interwork -mtune=arm926ej-s -mthumb-interwork -mno-thumb
--sysroot=/media/SSD/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/qemuarm
-DHAVE_CONFIG_H -I. -I.. -I../include-O2 -pipe -g
-feliminate-unused-debug-types -fpermissive -fvisibility-inlines-hidden
-fvisibility-inlines-hidden -c -o libcg_ba.o libcg_ba.cpp
libcg_ba.cpp:18:18: fatal error: string: No such file or directory
compilation terminated.
that does not look like the BB_THREAD bug. It is more the wrong c++ include
dir bug, when --sysroot is not used.
Problem is in gcc-cross-configure.inc:
EXTRA_OECONF_PATHS =
--with-local-prefix=${STAGING_DIR_TARGET}${target_exec_prefix} \
--with-gxx-include-dir=${target_includedir}/c++ \
which results in c++ defaultheadersearchdir ./usr/bin/usr/include/c++
and so the the string c++ header is not found.
but in the above, --sysroot is clearly being specified?
I don't understand why it sometimes fails and sometimes does not :/
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/4] binutils: upgrade from 2.21.1a to 2.22
On (28/11/11 16:36), nitin.a.kam...@intel.com wrote:
From: Nitin A Kamble nitin.a.kam...@intel.com
And rebase the patches to the newer source code
This patch is upstream hence deleting it from the recipe.
binutils/110-arm-eabi-conf.patch
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
---
meta/conf/distro/include/tcmode-default.inc|2 +-
..._2.21.1a.bb = binutils-cross-canadian_2.22.bb} |2 +-
...ils-cross_2.21.1a.bb = binutils-cross_2.22.bb} |0
...osssdk_2.21.1a.bb = binutils-crosssdk_2.22.bb} |2 +-
.../binutils/binutils/110-arm-eabi-conf.patch | 24 -
.../binutils/binutils-2.19.1-ld-sysroot.patch | 10 +-
.../binutils/binutils/binutils-poison.patch| 84 ++-
.../binutils/binutils/binutils-powerpc-e5500.patch | 52 +-
.../binutils/binutils-uclibc-100-uclibc-conf.patch | 40 +-
...binutils-uclibc-300-001_ld_makefile_patch.patch | 16 +-
...binutils-uclibc-300-006_better_file_error.patch |9 +-
...ils-uclibc-300-012_check_ldrunpath_length.patch | 12 +-
.../binutils/binutils-uclibc-gas-needs-libm.patch | 11 +-
.../binutils/binutils-x86_64_i386_biarch.patch | 10 +-
.../binutils/binutils/clone-shadow.patch | 18 +-
.../binutils/binutils/libiberty_path_fix.patch |8 +-
.../binutils/binutils/libtool-2.4-update.patch | 803
++--
.../binutils/binutils/libtool-rpath-fix.patch | 11 +-
.../{binutils_2.21.1a.bb = binutils_2.22.bb} |7 +-
19 files changed, 543 insertions(+), 578 deletions(-)
rename meta/recipes-devtools/binutils/{binutils-cross-canadian_2.21.1a.bb =
binutils-cross-canadian_2.22.bb} (86%)
rename meta/recipes-devtools/binutils/{binutils-cross_2.21.1a.bb =
binutils-cross_2.22.bb} (100%)
rename meta/recipes-devtools/binutils/{binutils-crosssdk_2.21.1a.bb =
binutils-crosssdk_2.22.bb} (96%)
delete mode 100644
meta/recipes-devtools/binutils/binutils/110-arm-eabi-conf.patch
rename meta/recipes-devtools/binutils/{binutils_2.21.1a.bb =
binutils_2.22.bb} (84%)
diff --git a/meta/conf/distro/include/tcmode-default.inc
b/meta/conf/distro/include/tcmode-default.inc
index ed722be..c22e7dc 100644
--- a/meta/conf/distro/include/tcmode-default.inc
+++ b/meta/conf/distro/include/tcmode-default.inc
@@ -18,7 +18,7 @@ PREFERRED_PROVIDER_virtual/gettext ??= gettext
GCCVERSION ?= 4.6%
SDKGCCVERSION ?= 4.6%
-BINUVERSION ?= 2.21.1a
+BINUVERSION ?= 2.22
EGLIBCVERSION ?= 2.13
UCLIBCVERSION ?= 0.9.32
LINUXLIBCVERSION ?= 3.1
What changes does 2.22 bring in, it would be nice to have a little
summary e.g.
http://cygwin.com/ml/binutils/2011-08/msg00129.html
changes default behaviour of linker which needs some mention in such
upgrades since it will bite many packages which dont have proper
dependencies specified.
And I think it would be better to leave the older release recipes in for a while
for at least toolchain components while the new versions gets soaked
in. Given now we have layers its better that way to give some time for
other layers also to test the new version
Thanks
-Khem
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Reproducible build problem with BB_NUMBER_THREADS=8
On Thu, Dec 01, 2011 at 09:17:39PM +, Richard Purdie wrote:
On Thu, 2011-12-01 at 18:34 +0100, Henning Heinold wrote:
# source='libcg_ba.cpp' object='libcg_ba.o' libtool=no
arm-angstrom-linux-gnueabi-g++ -march=armv5te -mno-thumb
-mthumb-interwork -mtune=arm926ej-s -mthumb-interwork -mno-thumb
--sysroot=/media/SSD/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/qemuarm
-DHAVE_CONFIG_H -I. -I.. -I../include-O2 -pipe -g
-feliminate-unused-debug-types -fpermissive -fvisibility-inlines-hidden
-fvisibility-inlines-hidden -c -o libcg_ba.o libcg_ba.cpp
libcg_ba.cpp:18:18: fatal error: string: No such file or directory
compilation terminated.
that does not look like the BB_THREAD bug. It is more the wrong c++
include dir bug, when --sysroot is not used.
Problem is in gcc-cross-configure.inc:
EXTRA_OECONF_PATHS =
--with-local-prefix=${STAGING_DIR_TARGET}${target_exec_prefix} \
--with-gxx-include-dir=${target_includedir}/c++ \
which results in c++ defaultheadersearchdir ./usr/bin/usr/include/c++
and so the the string c++ header is not found.
but in the above, --sysroot is clearly being specified?
I don't understand why it sometimes fails and sometimes does not :/
Cheers,
Richard
Um stpuid me.
Bye Henning
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] linux-yocto: consolidated pull request
On Thu, Dec 1, 2011 at 12:25 AM, Saul Wold saul.w...@intel.com wrote: On 11/30/2011 04:36 PM, Bruce Ashfield wrote: Richard/Saul, FYI: I can't get git-send email to work over the hotel wifi, so I can't chain the patches to this email. If you want me to send the patches separately, let me know. But for now, this is the best I can do. This pull request represents a collection of changes that were part of yocto M1 work, and that set the stage for more updates that will follow in the not too distant future. I've bumped the 3.0 kernel to the 3.0.10 baseline (3.0.11 is out, but not in this merge request) and updated our -rt patches to the latest upstream -rt series. This also drops the 2.6.34 recipe and leaves it to be supported in previous releases. If there's somewhere else I should be putting it, let me know and I'll put it there. The kernel revision updates have been built and boot tested by Tom and myself. And we have't seen any problems. Also included in this are some changes to kernel tools that prepare to move the kernel tools into the kernel tree itself. They also move us to doing configuration auditing using the merge_config script that Darren and John Stultz have been working on. And finally there's a small tweak to install the kernel tools via Makefile in the package itself, something that I recall Richard mentioning to me over 2 years ago a meeting .. so I thought I'd finally get to it. Cheers, brucedvh...@linux.intel.com cc: Tom Zanussi tom.zanu...@intel.com cc: Darren Hart dvh...@linux.intel.com The following changes since commit d7cd934376ae1edaf7055ec635eb3c85fdbf58b3: squashfs-tools: fix PR, those should start with 'r' (2011-11-30 23:37:44 +) are available in the git repository at: git://git.pokylinux.org/poky-contrib zedd/kernel http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel Bruce Ashfield (7): kern-tools: add pre_config and merge_config.sh to the list of tools kernel-yocto: support allnoconfig base configuration linux-yocto: remove 2.6.34 recipes linux-yocto: v3.0.9 + enhancements linux-yocto: v3.0.10 + rt27 linux-yocto: prefer in-tree tools to external ones kern-tools: use Makefile provided install rules meta/classes/kernel-yocto.bbclass | 24 +- .../kern-tools/kern-tools-native_git.bb | 15 ++ meta/recipes-kernel/linux/linux-yocto-rt_2.6.34.bb | 38 --- meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb | 8 ++-- meta/recipes-kernel/linux/linux-yocto_2.6.34.bb | 49 meta/recipes-kernel/linux/linux-yocto_3.0.bb | 18 6 files changed, 39 insertions(+), 113 deletions(-) delete mode 100644 meta/recipes-kernel/linux/linux-yocto-rt_2.6.34.bb delete mode 100644 meta/recipes-kernel/linux/linux-yocto_2.6.34.bb I had a problem with this change set, it gave me the following: NOTE: Error expanding variable do_kernel_checkout | ETA: 00:00:07 ERROR: Unable to parse /intel/poky/distro/meta/recipes-kernel/linux-libc-headers/linux-libc-headers-yocto_git.bb Looking at this some more before I head for travel, I can't see how my change set caused this. I haven't touched the 2.6.37 kernel (where that SRC_URI points by default) and I haven't touched any of the include files that it depends on. What machine were you building for ? I can't reproduce it here, so I'm looking for more information to properly debug the problem! Cheers, Bruce during parsing. Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core -- 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] Reproducible build problem with BB_NUMBER_THREADS=8
On (01/12/11 16:59), Ulf Samuelsson wrote: 2011-12-01 15:12, Cliff Brake skrev: On Thu, Dec 1, 2011 at 7:48 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: When you restart the build is the problem persistent or does it work the second time? I set BB_NUMBER_THREADS = 2 (was 4 when failing) I tried to restart the build and cleanall just the failing package, and it still failed. I then ran: bitbake -c cleanall gcc-cross gcc-cross-initial gcc-cross-intermediate gcc-runtime and after that, everything worked. Does someone have a complete console log for a build that failed with this they could share? I'll restart the build and collect one. So you just want the output of the console for bitbake? Thanks, Cliff Here is my buildlog, creating the failure. The C++ compiler cannot find string, even though it is in sysroot/usr/include/c++ This probably might have something to do with-gxx-include settings I will see if I can reproduce it here ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] sstate.bbclass: add option to use alternate compression in lieu of gzip
The savings can be substantial. The resutls below are for a
core-image-minimal type image:
gzip:1.1G sstate-cache
xz 714M sstate-cache
Signed-off-by: Matthew McClintock m...@freescale.com
---
meta/classes/sstate.bbclass | 19 +++
1 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index 3d259f0..16c4b43 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -18,6 +18,9 @@ SSTATE_MANMACH ?= ${SSTATE_PKGARCH}
SSTATEPOSTINSTFUNCS ?=
+SSTATE_PKG_SUFFIX = tgz
+SSTATE_PKG_TAROPT = z
+
python () {
if bb.data.inherits_class('native', d):
bb.data.setVar('SSTATE_PKGARCH', bb.data.getVar('BUILD_ARCH', d), d)
@@ -155,7 +158,7 @@ def sstate_installpkg(ss, d):
oe.path.remove(dir)
sstateinst = bb.data.expand(${WORKDIR}/sstate-install-%s/ % ss['name'],
d)
-sstatepkg = bb.data.getVar('SSTATE_PKG', d, True) + '_' + ss['name'] +
.tgz
+sstatepkg = bb.data.getVar('SSTATE_PKG', d, True) + '_' + ss['name'] +
.${SSTATE_PKG_SUFFIX}
if not os.path.exists(sstatepkg):
pstaging_fetch(sstatepkg, d)
@@ -206,7 +209,7 @@ def sstate_clean_cachefile(ss, d):
import oe.path
sstatepkgdir = bb.data.getVar('SSTATE_DIR', d, True)
-sstatepkgfile = sstatepkgdir + '/' + bb.data.getVar('SSTATE_PKGSPEC', d,
True) + *_ + ss['name'] + .tgz*
+sstatepkgfile = sstatepkgdir + '/' + bb.data.getVar('SSTATE_PKGSPEC', d,
True) + *_ + ss['name'] + .${SSTATE_PKG_SUFFIX}*
bb.note(Removing %s % sstatepkgfile)
oe.path.remove(sstatepkgfile)
@@ -351,7 +354,7 @@ def sstate_package(ss, d):
tmpdir = bb.data.getVar('TMPDIR', d, True)
sstatebuild = bb.data.expand(${WORKDIR}/sstate-build-%s/ % ss['name'], d)
-sstatepkg = bb.data.getVar('SSTATE_PKG', d, True) + '_'+ ss['name'] +
.tgz
+sstatepkg = bb.data.getVar('SSTATE_PKG', d, True) + '_'+ ss['name'] +
.${SSTATE_PKG_SUFFIX}
bb.mkdirhier(sstatebuild)
bb.mkdirhier(os.path.dirname(sstatepkg))
for state in ss['dirs']:
@@ -448,9 +451,9 @@ sstate_create_package () {
cd ${SSTATE_BUILDDIR}
# Need to handle empty directories
if [ $(ls -A) ]; then
- tar -czf ${SSTATE_PKG} *
+ tar -cf${SSTATE_PKG_TAROPT} ${SSTATE_PKG} *
else
- tar -cz --file=${SSTATE_PKG} --files-from=/dev/null
+ tar -c${SSTATE_PKG_TAROPT} --file=${SSTATE_PKG}
--files-from=/dev/null
fi
cd ${WORKDIR}
@@ -463,7 +466,7 @@ sstate_create_package () {
sstate_unpack_package () {
mkdir -p ${SSTATE_INSTDIR}
cd ${SSTATE_INSTDIR}
- tar -xvzf ${SSTATE_PKG}
+ tar -xvf${SSTATE_PKG_TAROPT} ${SSTATE_PKG}
}
BB_HASHCHECK_FUNCTION = sstate_checkhashes
@@ -483,7 +486,7 @@ def sstate_checkhashes(sq_fn, sq_task, sq_hash, sq_hashfn,
d):
}
for task in range(len(sq_fn)):
-sstatefile = bb.data.expand(${SSTATE_DIR}/ + sq_hashfn[task] + _ +
mapping[sq_task[task]] + .tgz, d)
+sstatefile = bb.data.expand(${SSTATE_DIR}/ + sq_hashfn[task] + _ +
mapping[sq_task[task]] + .${SSTATE_PKG_SUFFIX}, d)
sstatefile = sstatefile.replace(${BB_TASKHASH}, sq_hash[task])
if os.path.exists(sstatefile):
bb.debug(2, SState: Found valid sstate file %s % sstatefile)
@@ -508,7 +511,7 @@ def sstate_checkhashes(sq_fn, sq_task, sq_hash, sq_hashfn,
d):
if task in ret:
continue
-sstatefile = bb.data.expand(${SSTATE_DIR}/ + sq_hashfn[task] +
_ + mapping[sq_task[task]] + .tgz, d)
+sstatefile = bb.data.expand(${SSTATE_DIR}/ + sq_hashfn[task] +
_ + mapping[sq_task[task]] + .${SSTATE_PKG_SUFFIX}, d)
sstatefile = sstatefile.replace(${BB_TASKHASH}, sq_hash[task])
srcuri = file:// + os.path.basename(sstatefile)
--
1.7.6.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] sstate.bbclass: add option to use alternate compression in lieu of gzip
On Thu, Dec 1, 2011 at 5:33 PM, Matthew McClintock m...@freescale.com wrote: The savings can be substantial. The resutls below are for a core-image-minimal type image: gzip: 1.1G sstate-cache xz 714M sstate-cache Signed-off-by: Matthew McClintock m...@freescale.com Ugh, ignore this it does not actually work... -M ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/4] gmp: also generate the libgmpcxx library package it properly
On 12/01/2011 12:26 PM, Koen Kooi wrote: Op 1 dec. 2011, om 18:17 heeft Richard Purdie het volgende geschreven: On Thu, 2011-12-01 at 16:57 +, Phil Blundell wrote: On Tue, 2011-11-29 at 14:51 -0800, Kamble, Nitin A wrote: Thank you for the explanation. BTW where can I find official rules about signed-off-by line The Signed-off-by idiom originated with the kernel people and Documentation/SubmittingPatches in the linux source tree contains a fairly good description of what it means to them. I'm not sure that there are any official rules about its use in OE apart from what's in the Commit Patch Message Guidelines (see the wiki). The yocto docs do mention what the specific meaning of the line is. pedantic modeBut this is oe-core./pedantic mode. Shall we all agree it's the same for OE-core as well? Yes. No sense having the same phrases mean different things in different layers. Philip ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/6] More Updates
The following changes since commit aa0cb889a4ef883235dc3f3e1d76ee4a556ae03a:
libtool: Upgrade from 2.4 - 2.4.2 (2011-12-01 20:39:11 +)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib sgw/updates
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=sgw/updates
Saul Wold (6):
resolvconf: Update to 1.62
psmisc: Update to 22.14
sysstat: Update to 10.0.3
sqlite3: Update to 3.7.9
less: Update to 444
distro tracking updates
.../conf/distro/include/distro_tracking_fields.inc | 100 ++-
.../{resolvconf_1.61.bb = resolvconf_1.62.bb} |6 +-
.../less/{less_443.bb = less_444.bb} |5 +-
.../psmisc/files/libintl-link.patch| 22 +++--
meta/recipes-extended/psmisc/psmisc.inc|8 +-
.../psmisc/{psmisc_22.13.bb = psmisc_22.14.bb}|6 +-
.../{sysstat_10.0.2.bb = sysstat_10.0.3.bb} |6 +-
meta/recipes-support/sqlite/sqlite3_3.7.7.1.bb | 10 --
meta/recipes-support/sqlite/sqlite3_3.7.9.bb | 11 ++
9 files changed, 92 insertions(+), 82 deletions(-)
rename meta/recipes-connectivity/resolvconf/{resolvconf_1.61.bb =
resolvconf_1.62.bb} (78%)
rename meta/recipes-extended/less/{less_443.bb = less_444.bb} (87%)
rename meta/recipes-extended/psmisc/{psmisc_22.13.bb = psmisc_22.14.bb} (42%)
rename meta/recipes-extended/sysstat/{sysstat_10.0.2.bb = sysstat_10.0.3.bb}
(42%)
delete mode 100644 meta/recipes-support/sqlite/sqlite3_3.7.7.1.bb
create mode 100644 meta/recipes-support/sqlite/sqlite3_3.7.9.bb
--
1.7.6.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/6] sqlite3: Update to 3.7.9
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta/recipes-support/sqlite/sqlite3_3.7.7.1.bb | 10 --
meta/recipes-support/sqlite/sqlite3_3.7.9.bb | 11 +++
2 files changed, 11 insertions(+), 10 deletions(-)
delete mode 100644 meta/recipes-support/sqlite/sqlite3_3.7.7.1.bb
create mode 100644 meta/recipes-support/sqlite/sqlite3_3.7.9.bb
diff --git a/meta/recipes-support/sqlite/sqlite3_3.7.7.1.bb
b/meta/recipes-support/sqlite/sqlite3_3.7.7.1.bb
deleted file mode 100644
index fd03780..000
--- a/meta/recipes-support/sqlite/sqlite3_3.7.7.1.bb
+++ /dev/null
@@ -1,10 +0,0 @@
-require sqlite3.inc
-
-LIC_FILES_CHKSUM =
file://sqlite3.h;endline=11;md5=65f0a57ca6928710b418c094b3570bb0
-
-SRC_URI = http://www.sqlite.org/sqlite-autoconf-3070701.tar.gz;
-S = ${WORKDIR}/sqlite-autoconf-3070701
-PR = r1
-
-SRC_URI[md5sum] = 554026fe7fac47b1cf61c18d5fe43419
-SRC_URI[sha256sum] =
7dcc36b25f7bcbe2938d0ea2baea5b706f0af93473d02a3f612d7ab39e386edf
diff --git a/meta/recipes-support/sqlite/sqlite3_3.7.9.bb
b/meta/recipes-support/sqlite/sqlite3_3.7.9.bb
new file mode 100644
index 000..f6c2f9e
--- /dev/null
+++ b/meta/recipes-support/sqlite/sqlite3_3.7.9.bb
@@ -0,0 +1,11 @@
+require sqlite3.inc
+
+PR = r0
+
+LIC_FILES_CHKSUM =
file://sqlite3.h;endline=11;md5=65f0a57ca6928710b418c094b3570bb0
+
+SRC_URI = http://www.sqlite.org/sqlite-autoconf-3070900.tar.gz;
+S = ${WORKDIR}/sqlite-autoconf-3070900
+
+SRC_URI[md5sum] = dce303524736fe89a76b8ed29d566352
+SRC_URI[sha256sum] =
7be6cdb375505e5d9a4aee88b2ddb6ea0d9d29c9545114ff77b345e1fa812439
--
1.7.6.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/6] psmisc: Update to 22.14
* Create psmisc-extras for unpackaged binaries
* rebase patch
* set LICENSE to GPLv2
Signed-off-by: Saul Wold s...@linux.intel.com
---
.../psmisc/files/libintl-link.patch| 22 ++-
meta/recipes-extended/psmisc/psmisc.inc|8 +-
.../psmisc/{psmisc_22.13.bb = psmisc_22.14.bb}|6 ++--
3 files changed, 21 insertions(+), 15 deletions(-)
rename meta/recipes-extended/psmisc/{psmisc_22.13.bb = psmisc_22.14.bb} (42%)
diff --git a/meta/recipes-extended/psmisc/files/libintl-link.patch
b/meta/recipes-extended/psmisc/files/libintl-link.patch
index 698d98a..e42592c 100644
--- a/meta/recipes-extended/psmisc/files/libintl-link.patch
+++ b/meta/recipes-extended/psmisc/files/libintl-link.patch
@@ -6,25 +6,27 @@ default. The configure script correctly figures out if this
is needed, but
doesn't actually link to the libraries it decides on. This makes it link to
them if they are needed:
psmisc-22.13/src/Makefile.am
-+++ psmisc-22.13/src/Makefile.am
-@@ -25,16 +25,17 @@ endif
+Index: psmisc-22.14/src/Makefile.am
+===
+--- psmisc-22.14.orig/src/Makefile.am 2011-06-20 04:59:44.0 -0700
psmisc-22.14/src/Makefile.am 2011-12-01 10:19:55.792680654 -0800
+@@ -26,15 +26,17 @@
+ fuser_SOURCES = fuser.c comm.h signals.c signals.h i18n.h fuser.h lists.h
- fuser_SOURCES = fuser.c comm.h signals.c signals.h i18n.h fuser.h
+fuser_LDADD = @INTLLIBS@
-
++
killall_SOURCES = killall.c comm.h signals.c signals.h i18n.h
-
+
-killall_LDADD = @SELINUX_LIB@
+killall_LDADD = @SELINUX_LIB@ @INTLLIBS@
-
+
peekfd_SOURCES = peekfd.c
-
+
pstree_SOURCES = pstree.c comm.h i18n.h
-
+
-pstree_LDADD = @TERMCAP_LIB@ @SELINUX_LIB@
+pstree_LDADD = @TERMCAP_LIB@ @SELINUX_LIB@ @INTLLIBS@
-
+
prtstat_SOURCES = prtstat.c prtstat.h
diff --git a/meta/recipes-extended/psmisc/psmisc.inc
b/meta/recipes-extended/psmisc/psmisc.inc
index 77047cc..9e281d5 100644
--- a/meta/recipes-extended/psmisc/psmisc.inc
+++ b/meta/recipes-extended/psmisc/psmisc.inc
@@ -1,4 +1,3 @@
-LICENSE = GPL
SUMMARY = Utilities for managing processes on your system
DESCRIPTION = The psmisc package contains utilities for managing processes on
your \
system: pstree, killall and fuser. The pstree command displays a tree \
@@ -8,6 +7,7 @@ processes identified by name. The fuser command identifies the
PIDs \
of processes that are using specified files or filesystems.
SECTION = base
DEPENDS = ncurses virtual/libintl
+LICENSE = GPLv2
SRC_URI = ${SOURCEFORGE_MIRROR}/psmisc/psmisc-${PV}.tar.gz \
file://libintl-link.patch
@@ -17,7 +17,8 @@ inherit autotools gettext
ALLOW_EMPTY = 1
-PACKAGES =+ fuser fuser-doc killall killall-doc pstree pstree-doc
+PACKAGES =+ fuser fuser-doc killall killall-doc pstree pstree-doc
+PACKAGES += psmisc-extras
FILES_${PN} =
RDEPENDS_${PN} = fuser killall pstree
@@ -31,6 +32,9 @@ FILES_killall-doc = ${mandir}/man1/killall*
FILES_pstree = ${bindir}/pstree
FILES_pstree-doc = ${mandir}/man1/pstree*
+FILES_psmisc-extras = ${bindir}
+FILES_psmisc-extras-doc = ${mandir}
+
do_install_append() {
mv ${D}${bindir}/killall ${D}${bindir}/killall.${PN}
mv ${D}${bindir}/fuser ${D}${bindir}/fuser.${PN}
diff --git a/meta/recipes-extended/psmisc/psmisc_22.13.bb
b/meta/recipes-extended/psmisc/psmisc_22.14.bb
similarity index 42%
rename from meta/recipes-extended/psmisc/psmisc_22.13.bb
rename to meta/recipes-extended/psmisc/psmisc_22.14.bb
index 757e097..4f89672 100644
--- a/meta/recipes-extended/psmisc/psmisc_22.13.bb
+++ b/meta/recipes-extended/psmisc/psmisc_22.14.bb
@@ -1,7 +1,7 @@
require psmisc.inc
LICENSE = GPLv2
LIC_FILES_CHKSUM = file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3
-PR = r1
+PR = r0
-SRC_URI[md5sum] = e2c339e6b65b730042084023784a729e
-SRC_URI[sha256sum] =
06d25e8ebb4722dbcede98a787c39a9ed341f8e58fde10c0b2d6b35990b35daa
+SRC_URI[md5sum] = ba3f4e971895c92bba7770d81c981503
+SRC_URI[sha256sum] =
22bbf4561837af475c0d8d14e3b9cab453998c787212c107fac7faf2f281e26e
--
1.7.6.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/6] resolvconf: Update to 1.62
* remove unneeded directory that does not get packaged
Signed-off-by: Saul Wold s...@linux.intel.com
---
.../{resolvconf_1.61.bb = resolvconf_1.62.bb} |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
rename meta/recipes-connectivity/resolvconf/{resolvconf_1.61.bb =
resolvconf_1.62.bb} (78%)
diff --git a/meta/recipes-connectivity/resolvconf/resolvconf_1.61.bb
b/meta/recipes-connectivity/resolvconf/resolvconf_1.62.bb
similarity index 78%
rename from meta/recipes-connectivity/resolvconf/resolvconf_1.61.bb
rename to meta/recipes-connectivity/resolvconf/resolvconf_1.62.bb
index c924fe0..af72199 100644
--- a/meta/recipes-connectivity/resolvconf/resolvconf_1.61.bb
+++ b/meta/recipes-connectivity/resolvconf/resolvconf_1.62.bb
@@ -14,8 +14,8 @@ PR = r0
SRC_URI = ${DEBIAN_MIRROR}/main/r/resolvconf/resolvconf_${PV}.tar.gz
-SRC_URI[md5sum] = ac1cfa1abc7c690f1d8917f746ad80a5
-SRC_URI[sha256sum] =
0eaa97fa29f8e30a541d549abe76766e5e4edfa841721529c85616d7c0089908
+SRC_URI[md5sum] = 5d9656c9d7a2e1304d9d41ed13cf54a4
+SRC_URI[sha256sum] =
cd00b3757fc73d2729be6e2532ca033ddd5542c4deff451929695bcc3af97c61
inherit allarch
@@ -24,7 +24,7 @@ do_compile () {
}
do_install () {
- install -d ${D}${sysconfdir} ${D}${sbindir} ${D}${base_sbindir}
${D}${localstatedir}/volatile/run/resolvconf/interface
+ install -d ${D}${sysconfdir} ${D}${base_sbindir}
${D}${localstatedir}/volatile/run/resolvconf/interface
install -d ${D}${mandir}/man8 ${D}${docdir}/${P}
cp -pPR etc/* ${D}${sysconfdir}/
chown -R root:root ${D}${sysconfdir}/
--
1.7.6.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/6] sysstat: Update to 10.0.3
Signed-off-by: Saul Wold s...@linux.intel.com
---
.../{sysstat_10.0.2.bb = sysstat_10.0.3.bb} |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
rename meta/recipes-extended/sysstat/{sysstat_10.0.2.bb = sysstat_10.0.3.bb}
(42%)
diff --git a/meta/recipes-extended/sysstat/sysstat_10.0.2.bb
b/meta/recipes-extended/sysstat/sysstat_10.0.3.bb
similarity index 42%
rename from meta/recipes-extended/sysstat/sysstat_10.0.2.bb
rename to meta/recipes-extended/sysstat/sysstat_10.0.3.bb
index bd559d8..d445e88 100644
--- a/meta/recipes-extended/sysstat/sysstat_10.0.2.bb
+++ b/meta/recipes-extended/sysstat/sysstat_10.0.3.bb
@@ -4,7 +4,5 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=8ca43cbc842c2336e835926c2166c28b
PR = r0
-
-
-SRC_URI[md5sum] = 0253058fed65e9394c49255821b8803e
-SRC_URI[sha256sum] =
c89c7baa904f47aa62f3829a90f87509207bfc26ce11c3c4ec415d027ed3f78a
+SRC_URI[md5sum] = 0e1ed5200f31f69a3b90ff1e81c07745
+SRC_URI[sha256sum] =
7c0dd172f09edaff100b33db29ef502e15e71867b505c6d519f76a24fabcc1f5
--
1.7.6.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 5/6] less: Update to 444
Signed-off-by: Saul Wold s...@linux.intel.com
---
.../less/{less_443.bb = less_444.bb} |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
rename meta/recipes-extended/less/{less_443.bb = less_444.bb} (87%)
diff --git a/meta/recipes-extended/less/less_443.bb
b/meta/recipes-extended/less/less_444.bb
similarity index 87%
rename from meta/recipes-extended/less/less_443.bb
rename to meta/recipes-extended/less/less_444.bb
index 0928ad4..c78dbaa 100644
--- a/meta/recipes-extended/less/less_443.bb
+++ b/meta/recipes-extended/less/less_444.bb
@@ -15,9 +15,8 @@ PR = r0
SRC_URI = http://www.greenwoodsoftware.com/${BPN}/${BPN}-${PV}.tar.gz;
-SRC_URI[md5sum] = 47db098fb3cdaf847b3c4be05ee954fc
-SRC_URI[sha256sum] =
a4c3e8af81fd0944941ee7c74eecc7759422a227df52335e899e69de5eae30ca
-
+SRC_URI[md5sum] = 56f9f76ffe13f70155f47f6b3c87d421
+SRC_URI[sha256sum] =
be64ad3e22d6d4aa19fe7024d998563a1ce1671ee3625f8851d26b16dedcdeeb
inherit autotools update-alternatives
--
1.7.6.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 6/6] distro tracking updates
Signed-off-by: Saul Wold s...@linux.intel.com --- .../conf/distro/include/distro_tracking_fields.inc | 100 ++- 1 files changed, 53 insertions(+), 47 deletions(-) diff --git a/meta/conf/distro/include/distro_tracking_fields.inc b/meta/conf/distro/include/distro_tracking_fields.inc index 073521f..d6f5217 100644 --- a/meta/conf/distro/include/distro_tracking_fields.inc +++ b/meta/conf/distro/include/distro_tracking_fields.inc @@ -109,7 +109,7 @@ RECIPE_MAINTAINER_pn-run-postinsts = Dongxiao Xu dongxiao...@intel.com RECIPE_STATUS_pn-subversion = green RECIPE_LATEST_VERSION_pn-subversion = 1.6.15 -RECIPE_MANUAL_CHECK_DATE_pn-subversion = Jan 25, 2011 +RECIPE_MANUAL_CHECK_DATE_pn-subversion = Jan 25, 2011 RECIPE_MAINTAINER_pn-subversion = Nitin A Kamble nitin.a.kam...@intel.com RECIPE_STATUS_pn-trace-cmd = green @@ -475,7 +475,6 @@ RECIPE_LATEST_VERSION_pn-openssl = 1.0.0e RECIPE_LATEST_RELEASE_DATE_pn-openssl = Sep 06, 2010 RECIPE_LAST_UPDATE_pn-openssl = Nov 28, 2011 RECIPE_MAINTAINER_pn-openssl = Saul Wold s...@linux.intel.com -RECIPE_NO_UPDATE_REASON_pn-openssl = compatibility and stability concerns on new major release RECIPE_INTEL_SECTION_pn-openssl = base libs RECIPE_STATUS_pn-libnss-mdns = green @@ -502,15 +501,15 @@ RECIPE_INTEL_SECTION_pn-popt = base libs RECIPE_LATEST_RELEASE_DATE_pn-popt = May 01, 2010 RECIPE_STATUS_pn-sqlite3 = green # need upgrade -RECIPE_LAST_UPDATE_pn-sqlite3 = Nov 24, 2010 +RECIPE_LATEST_VERSION_pn-sqlite3 = 3.7.9 +RECIPE_LATEST_RELEASE_DATE_pn-sqlite3 = Nov 01, 2011 +RECIPE_LAST_UPDATE_pn-sqlite3 = Dec 01, 2011 +RECIPE_MANUAL_CHECK_DATE_pn-sqlite3= Dec 01, 2011 RECIPE_MAINTAINER_pn-sqlite3 = Saul Wold s...@linux.intel.com RECIPE_DEPENDENCY_CHECK_pn-sqlite3 = not done -RECIPE_LATEST_VERSION_pn-sqlite3 = 3.7.7.1 RECIPE_INTEL_SECTION_pn-sqlite3 = base libs RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn-sqlite3 = 1 month -RECIPE_LATEST_RELEASE_DATE_pn-sqlite3 = Oct 01, 2010 RECIPE_COMMENTS_pn-sqlite3 = -RECIPE_MANUAL_CHECK_DATE_pn-sqlite3= Jul 01, 2011 RECIPE_STATUS_pn-libpthread-stubs = green RECIPE_LAST_UPDATE_pn-libpthread-stubs = Jul 6, 2010 @@ -590,7 +589,7 @@ RECIPE_DEPENDENCY_CHECK_pn-libcheck = done RECIPE_LATEST_VERSION_pn-libcheck = 0.9.8 RECIPE_LATEST_RELEASE_DATE_pn-libcheck = Sep 23, 2009 RECIPE_LAST_UPDATE_pn-libcheck = Aug 20, 2010 -RECIPE_MANUAL_CHECK_DATE_pn-libcheck = Nov 8, 2011 +RECIPE_MANUAL_CHECK_DATE_pn-libcheck = Dec 01, 2011 RECIPE_MAINTAINER_pn-libcheck = Saul Wold s...@linux.intel.com RECIPE_INTEL_SECTION_pn-libcheck = base libs RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn-libcheck = 9 months @@ -611,6 +610,7 @@ DISTRO_PN_ALIAS_pn-augeas = Ubuntu=libaugeas0 Debian=libaugeas0 RECIPE_STATUS_pn-sat-solver = green RECIPE_DEPENDENCY_CHECK_pn-sat-solver = done RECIPE_LATEST_VERSION_pn-sat-solver = git +RECIPE_MANUAL_CHECK_DATE_pn-sat-solver = Dec 01, 2011 RECIPE_INTEL_SECTION_pn-sat-solver = base libs DISTRO_PN_ALIAS_pn-sat-solver = OSPDT OpenSuSE=satsolver-tools RECIPE_COMMENTS_pn-sat-solver = @@ -1288,7 +1288,7 @@ RECIPE_LATEST_VERSION_pn-console-tools = 0.3.2 RECIPE_LAST_UPDATE_pn-console-tools = Jul 21, 2006 RECIPE_MAINTAINER_pn-console-tools = Saul Wold s...@linux.intel.com DISTRO_PN_ALIAS_pn-console-tools = Debian=console-tools Ubuntu=console-tools -RECIPE_MANUAL_CHECK_DATE_pn-console-tools= Jul 01, 2011 +RECIPE_MANUAL_CHECK_DATE_pn-console-tools= Dec 01, 2011 RECIPE_STATUS_pn-fuse = red RECIPE_LATEST_VERSION_pn-fuse = 2.8.4 @@ -1327,15 +1327,17 @@ RECIPE_LAST_UPDATE_pn-pm-utils = Nov 18, 2010 RECIPE_MAINTAINER_pn-pm-utils = Dongxiao Xu dongxiao...@intel.com RECIPE_STATUS_pn-psmisc = red -RECIPE_LATEST_VERSION_pn-psmisc = 22.13 -RECIPE_LAST_UPDATE_pn-psmisc = Jan 18, 2008 +RECIPE_LATEST_VERSION_pn-psmisc = 22.14 +RECIPE_LATEST_RELEASE_DATE_pn-psmisc = Jun 20, 2011 +RECIPE_LAST_UPDATE_pn-psmisc = Dec 01, 2011 +RECIPE_MANUAL_CHECK_DATE_pn-psmisc = Dec 01, 2011 RECIPE_MAINTAINER_pn-psmisc = Saul Wold s...@linux.intel.com RECIPE_STATUS_pn-boost = yellow RECIPE_LATEST_VERSION_pn-boost = 1.47.0 RECIPE_LATEST_RELEASE_DATE_pn-boost = Jul 12, 2011 RECIPE_LAST_UPDATE_pn-boost = Aug 19, 2010 -RECIPE_MANUAL_CHECK_DATE_pn-boost = Nov 08, 2011 +RECIPE_MANUAL_CHECK_DATE_pn-boost = Dec 01, 2011 RECIPE_MAINTAINER_pn-boost = Saul Wold s...@linux.intel.com RECIPE_STATUS_pn-boost-jam-native = green @@ -1455,7 +1457,7 @@ RECIPE_COMMENTS_pn-bash = RECIPE_STATUS_pn-syslinux = yellow# need mangling on LDFLAGS RECIPE_LAST_UPDATE_pn-syslinux = Nov 16, 2010 -RECIPE_MAINTAINER_pn-syslinux = Saul Wold s...@linux.intel.com +RECIPE_MAINTAINER_pn-syslinux = Darren Hart dvh...@linux.intel.com RECIPE_DEPENDENCY_CHECK_pn-syslinux = not done RECIPE_LATEST_VERSION_pn-syslinux = 3.86 RECIPE_PATCH_pn-syslinux+cross-build = use poky toolchain instead of host @@ -1482,7 +1484,7 @@ RECIPE_LAST_UPDATE_pn-sysfsutils = Jun 18, 2010 RECIPE_DEPENDENCY_CHECK_pn-sysfsutils = not done
[OE-core] [PATCH 1/3] kernel-yocto: fix extra CR in do_kernel_checkout
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta/classes/kernel-yocto.bbclass |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/meta/classes/kernel-yocto.bbclass
b/meta/classes/kernel-yocto.bbclass
index ad14aac..79f82e3 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -53,8 +53,7 @@ do_patch() {
}
do_kernel_checkout() {
- if [ -d $
-{WORKDIR}/git/.git/refs/remotes/origin ]; then
+ if [ -d ${WORKDIR}/git/.git/refs/remotes/origin ]; then
echo Fixing up git directory for
${LINUX_KERNEL_TYPE}/${KMACHINE}
rm -rf ${S}
mkdir ${S}
--
1.7.6.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Reproducible build problem with BB_NUMBER_THREADS=8
On 2011-12-02 00:08, Khem Raj wrote: On (01/12/11 16:59), Ulf Samuelsson wrote: 2011-12-01 15:12, Cliff Brake skrev: On Thu, Dec 1, 2011 at 7:48 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: When you restart the build is the problem persistent or does it work the second time? I set BB_NUMBER_THREADS = 2 (was 4 when failing) I tried to restart the build and cleanall just the failing package, and it still failed. I then ran: bitbake -c cleanall gcc-cross gcc-cross-initial gcc-cross-intermediate gcc-runtime and after that, everything worked. Does someone have a complete console log for a build that failed with this they could share? I'll restart the build and collect one. So you just want the output of the console for bitbake? Thanks, Cliff Here is my buildlog, creating the failure. The C++ compiler cannot find string, even though it is in sysroot/usr/include/c++ This probably might have something to do with-gxx-include settings I will see if I can reproduce it here I have seen the problem on the following machine Core i7 980X (hexa core) @ 3.33 GHz 12 GB RAM Ubuntu 11.10 x64 Build on Intel 510 120 GB SSD disk PARALLEL_MAKE = 24 | 4 BB_NUMBER_THREADS = 24 | 4. I have not seen the problem on the following machine Core i7 920 @ 2.67 GHz 4 GB RAM. Ubuntu 11.04 x64 WD Black 1TB SATA-II PARALLEL_MAKE = 4 BB_NUMBER_THREADS = 4. The problem comes in two flavours. The one in the log, but also when building tiff. tiff bombs with another C++ include. Someone else had a similar problem, so I cleaned out the build directory, built tiff, and then console-image, which completed. I changed my build script to first build tiff, and then console-image for the next clean build. This time the c++ include problem reappeared. I guess there is some race condition somewhere. BR Ulf Samuelsson ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core -- Best Regards Ulf Samuelsson eMagii ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [RFC PATCH 1/2] classes/buildhistory: add new output history collection class
Create a new build output history reporting class, using testlab.bbclass
from meta-oe as a base. This records information from images produced by
the build process in text files structured suitably for tracking within
a git repository, thus enabling monitoring of changes over time.
Build history collection can be enabled simply by adding the following
to your local.conf:
INHERIT += buildhistory
The output after a build can then be found in BUILDHISTORY_DIR (defaults to
TMPDIR/buildhistory). If you set up this directory as a git repository and
set BUILDHISTORY_COMMIT to 1 in local.conf, the build history data will
be committed on every build.
Signed-off-by: Paul Eggleton paul.eggle...@linux.intel.com
---
meta/classes/buildhistory.bbclass | 105 +
meta/classes/rootfs_ipk.bbclass | 27 +-
meta/classes/rootfs_rpm.bbclass | 41 +--
3 files changed, 167 insertions(+), 6 deletions(-)
create mode 100644 meta/classes/buildhistory.bbclass
diff --git a/meta/classes/buildhistory.bbclass
b/meta/classes/buildhistory.bbclass
new file mode 100644
index 000..79a074c
--- /dev/null
+++ b/meta/classes/buildhistory.bbclass
@@ -0,0 +1,105 @@
+#
+# Records history of build output in order to detect regressions
+#
+# Based in part on testlab.bbclass
+#
+# Copyright (C) 2011 Intel Corporation
+# Copyright (C) 2007, 2008 Koen Kooi k...@openembedded.org
+#
+
+BUILDHISTORY_DIR ?= ${TMPDIR}/buildhistory
+BUILDHISTORY_DIR_IMAGE =
${BUILDHISTORY_DIR}/images/${MACHINE_ARCH}/${TCLIBC}/${IMAGE_BASENAME}
+BUILDHISTORY_COMMIT ?= 0
+BUILDHISTORY_COMMIT_AUTHOR ?= buildhistory buildhistory@${DISTRO}
+BUILDHISTORY_PUSH_REPO ?=
+
+buildhistory_get_image_installed() {
+ # Anything requiring the use of the packaging system should be done in
here
+ # in case the packaging files are going to be removed for this image
+
+ mkdir -p ${BUILDHISTORY_DIR_IMAGE}
+
+ # Get list of installed packages
+ list_installed_packages | sort
${BUILDHISTORY_DIR_IMAGE}/installed-package-names.txt
+ INSTALLED_PKGS=`cat
${BUILDHISTORY_DIR_IMAGE}/installed-package-names.txt`
+
+ # Produce installed package file and size lists and dependency graph
+ echo -n ${BUILDHISTORY_DIR_IMAGE}/installed-packages.txt
+ echo -n ${BUILDHISTORY_DIR_IMAGE}/installed-package-sizes.tmp
+ echo -e digraph depends {\nnode [shape=plaintext]
${BUILDHISTORY_DIR_IMAGE}/depends.dot
+ for pkg in $INSTALLED_PKGS; do
+ pkgfile=`get_package_filename $pkg`
+ echo `basename $pkgfile`
${BUILDHISTORY_DIR_IMAGE}/installed-packages.txt
+ if [ -f $pkgfile ] ; then
+ pkgsize=`du -k $pkgfile | head -n1 | awk '{ print $1 }'`
+ echo $pkgsize $pkg
${BUILDHISTORY_DIR_IMAGE}/installed-package-sizes.tmp
+ fi
+
+ deps=`list_package_depends $pkg`
+ for dep in $deps ; do
+ echo $pkg OPP $dep; | sed -e 's:-:_:g' -e 's:\.:_:g'
-e 's:+::g' | sed 's:OPP:-:g' ${BUILDHISTORY_DIR_IMAGE}/depends.dot
+ done
+
+ recs=`list_package_recommends $pkg`
+ for rec in $recs ; do
+ echo $pkg OPP $rec [style=dotted]; | sed -e 's:-:_:g'
-e 's:\.:_:g' -e 's:+::g' | sed 's:OPP:-:g'
${BUILDHISTORY_DIR_IMAGE}/depends.dot
+ done
+ done
+ echo } ${BUILDHISTORY_DIR_IMAGE}/depends.dot
+
+ cat ${BUILDHISTORY_DIR_IMAGE}/installed-package-sizes.tmp | sort -n -r
| awk '{print $1 \tKiB $2}'
${BUILDHISTORY_DIR_IMAGE}/installed-package-sizes.txt
+ rm ${BUILDHISTORY_DIR_IMAGE}/installed-package-sizes.tmp
+
+ # Produce some cut-down graphs (for readability)
+ grep -v kernel_image ${BUILDHISTORY_DIR_IMAGE}/depends.dot | grep -v
kernel_2 | grep -v kernel_3 ${BUILDHISTORY_DIR_IMAGE}/depends-nokernel.dot
+ grep -v libc6 ${BUILDHISTORY_DIR_IMAGE}/depends-nokernel.dot | grep -v
libgcc ${BUILDHISTORY_DIR_IMAGE}/depends-nokernel-nolibc.dot
+ grep -v update_ ${BUILDHISTORY_DIR_IMAGE}/depends-nokernel-nolibc.dot
${BUILDHISTORY_DIR_IMAGE}/depends-nokernel-nolibc-noupdate.dot
+ grep -v kernel_module
${BUILDHISTORY_DIR_IMAGE}/depends-nokernel-nolibc-noupdate.dot
${BUILDHISTORY_DIR_IMAGE}/depends-nokernel-nolibc-noupdate-nomodules.dot
+
+ # Workaround for broken shell function dependencies
+ if false ; then
+ get_package_filename
+ list_package_depends
+ list_package_recommends
+ fi
+}
+
+buildhistory_get_imageinfo() {
+ # List the files in the image, but exclude date/time etc.
+ # This awk script is somewhat messy, but handles where the size is not
printed for device files under pseudo
+ find ${IMAGE_ROOTFS} -ls | awk '{ if ( $7 ~ /[0-9]/ ) printf %s %10-s
%10-s %10s %s %s %s\n, $3, $5, $6, $7, $11, $12, $13 ; else printf %s %10-s
%10-s
[OE-core] [RFC PATCH 0/2] introduce buildhistory.bbclass
Here is the initial version of buildhistory.bbclass. It provides (most of) the functionality of testlab.bbclass and all functionality of packagehistory.bbclass. Changes/improvements over testlab: * Supports both rpm and ipk-based images * Works even if packaging data is removed in the final image * File listing is tidier and excludes date/time info so changes are more obvious * Produces a separate package list with just the package names (i.e. not the full file name). * Optional git commit occurs at the end of the build and is done outside of fakeroot * Can optionally push git commit to a remote repository Todo items: * There is no recording of licenses into the build history, in favour of Beth Flanagan's upcoming work on license.bbclass. I appreciate some may want this tracked in buildhistory - please comment. Could be something to add afterwards when Beth's work is integrated. * Deb-based packaging is not supported because I am unable to test it (see Yocto bug #1802). Note that an earlier version of this was merged accidentally to OE-core; this was subsequently reverted to allow proper review. Please review the following changes for suitability for inclusion. If you have any objections or suggestions for improvement, please respond to the patches. If you agree with the changes, please provide your Acked-by. The following changes since commit e57935dc18d576feb1003b48e7cdc72a444131b8: Revert classes/buildhistory: add new output history collection class (2011-12-01 23:00:52 +) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib paule/buildhistory http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/buildhistory Paul Eggleton (2): classes/buildhistory: add new output history collection class classes/buildhistory: merge in package history functionality meta/classes/buildhistory.bbclass | 359 + meta/classes/rootfs_ipk.bbclass | 27 +++- meta/classes/rootfs_rpm.bbclass | 41 - 3 files changed, 421 insertions(+), 6 deletions(-) create mode 100644 meta/classes/buildhistory.bbclass -- 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] [RFC PATCH 2/2] classes/buildhistory: merge in package history functionality
Include package history collection from packagehistory.bbclass (thus
superseding it), with the following changes:
* Store package history under BUILDHISTORY_DIR/packages
* Disable storing package history as version named files unless
BUILDHISTORY_KEEP_VERSIONS is set to 1; otherwise the adds of these
files that duplicate what is already in git anyway is just noise in
the git log.
* Rename emit_pkghistory to buildhistory_emit_pkghistory
Implements [YOCTO #1565].
Signed-off-by: Paul Eggleton paul.eggle...@linux.intel.com
---
meta/classes/buildhistory.bbclass | 256 -
1 files changed, 255 insertions(+), 1 deletions(-)
diff --git a/meta/classes/buildhistory.bbclass
b/meta/classes/buildhistory.bbclass
index 79a074c..9303486 100644
--- a/meta/classes/buildhistory.bbclass
+++ b/meta/classes/buildhistory.bbclass
@@ -1,7 +1,7 @@
#
# Records history of build output in order to detect regressions
#
-# Based in part on testlab.bbclass
+# Based in part on testlab.bbclass and packagehistory.bbclass
#
# Copyright (C) 2011 Intel Corporation
# Copyright (C) 2007, 2008 Koen Kooi k...@openembedded.org
@@ -9,10 +9,264 @@
BUILDHISTORY_DIR ?= ${TMPDIR}/buildhistory
BUILDHISTORY_DIR_IMAGE =
${BUILDHISTORY_DIR}/images/${MACHINE_ARCH}/${TCLIBC}/${IMAGE_BASENAME}
+BUILDHISTORY_DIR_PACKAGE =
${BUILDHISTORY_DIR}/packages/${MULTIMACH_TARGET_SYS}/${PN}
BUILDHISTORY_COMMIT ?= 0
BUILDHISTORY_COMMIT_AUTHOR ?= buildhistory buildhistory@${DISTRO}
BUILDHISTORY_PUSH_REPO ?=
+# Must inherit package first before changing PACKAGEFUNCS
+inherit package
+PACKAGEFUNCS += buildhistory_emit_pkghistory
+
+#
+# Called during do_package to write out metadata about this package
+# for comparision when writing future packages
+#
+python buildhistory_emit_pkghistory() {
+ import re
+
+ pkghistdir = d.getVar('BUILDHISTORY_DIR_PACKAGE', True)
+
+ class RecipeInfo:
+ def __init__(self, name):
+ self.name = name
+ self.pe = 0
+ self.pv = 0
+ self.pr = r0
+ self.depends =
+ self.packages =
+
+ class PackageInfo:
+ def __init__(self, name):
+ self.name = name
+ self.pe = 0
+ self.pv = 0
+ self.pr = r0
+ self.size = 0
+ self.depends =
+ self.rdepends =
+ self.rrecommends =
+ self.files =
+ self.filelist =
+
+ # Should check PACKAGES here to see if anything removed
+
+ def getpkgvar(pkg, var):
+ val = bb.data.getVar('%s_%s' % (var, pkg), d, 1)
+ if val:
+ return val
+ val = bb.data.getVar('%s' % (var), d, 1)
+
+ return val
+
+ def readRecipeInfo(pn, histfile):
+ rcpinfo = RecipeInfo(pn)
+ f = open(histfile, r)
+ try:
+ for line in f:
+ lns = line.split('=')
+ name = lns[0].strip()
+ value = lns[1].strip( \t\r\n).strip('')
+ if name == PE:
+ rcpinfo.pe = value
+ elif name == PV:
+ rcpinfo.pv = value
+ elif name == PR:
+ rcpinfo.pr = value
+ elif name == DEPENDS:
+ rcpinfo.depends = value
+ elif name == PACKAGES:
+ rcpinfo.packages = value
+ finally:
+ f.close()
+ return rcpinfo
+
+ def readPackageInfo(pkg, histfile):
+ pkginfo = PackageInfo(pkg)
+ f = open(histfile, r)
+ try:
+ for line in f:
+ lns = line.split('=')
+ name = lns[0].strip()
+ value = lns[1].strip( \t\r\n).strip('')
+ if name == PE:
+ pkginfo.pe = value
+ elif name == PV:
+ pkginfo.pv = value
+ elif name == PR:
+ pkginfo.pr = value
+ elif name == RDEPENDS:
+ pkginfo.rdepends = value
+ elif name == RRECOMMENDS:
+ pkginfo.rrecommends = value
+ elif name == PKGSIZE:
+
Re: [OE-core] [PATCH][oe-core 1/4] sysstat: don't run populate-volatile.sh update in do_rootfs or without populate-volatile.sh
On Thu, Dec 01, 2011 at 01:41:46PM +0100, Martin Jansa wrote:
On Thu, Dec 01, 2011 at 12:18:09PM +, Richard Purdie wrote:
On Thu, 2011-12-01 at 13:02 +0100, Martin Jansa wrote:
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
meta/recipes-extended/sysstat/sysstat.inc |7 ++-
meta/recipes-extended/sysstat/sysstat_10.0.2.bb |2 +-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-extended/sysstat/sysstat.inc
b/meta/recipes-extended/sysstat/sysstat.inc
index 2936f96..ca40ab5 100644
--- a/meta/recipes-extended/sysstat/sysstat.inc
+++ b/meta/recipes-extended/sysstat/sysstat.inc
@@ -22,7 +22,12 @@ do_install() {
}
pkg_postinst_${PN} () {
-/etc/init.d/populate-volatile.sh update
+if [ -n $D ]; then
+exit 1
+fi
I'm confused. Can't we exit 0 here since the system will have run
populate-volatile.sh update at rootfs time or first boot as needed so we
don't need to run it again?
See recipes-core/dbus/dbus.inc or pulseaudio for similar examples.
Ah I didn't know about importance of return value in this case and I was
looking at
meta/classes/module.bbclass
meta/recipes-connectivity/avahi/avahi.inc
for similar examples.
I'll learn how it's changing behavior and why avahi has exit 1 in 2/3
and exit 0 in 1/3 postinst and then I'll send updated patch if needed,
but now I'm 5 hours late to daywork.. :).
Now after reading
3.1.6. Post Install Scripts
in manual
http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#usingpoky-extend-addpkg-postinstalls
I'm confused too and wondering if dbus and pulseaudio are best examples..
dbus:
pkg_postinst_dbus() {
if [ -z $D ] [ -e /etc/init.d/populate-volatile.sh ] ; then
/etc/init.d/populate-volatile.sh update
fi
}
so it this will succeed every time in do_rootfs (even with test expression
false), so it will be marked as installed
and postinst won't be called on first boot, but will be called after every
upgrade. Is that what we really want?
pulseaudio:
pkg_postinst_${PN}-server() {
# can't do this offline
if [ x$D != x ]; then
exit 1
fi
if [ -e ${sysconfdir}/init.d/populate-volatile.sh ] ; then
${sysconfdir}/init.d/populate-volatile.sh update
fi
}
this looks the same as my postinst in sysstat (only difference is 'x$D !=
x' instead of shorter '-n $D')
and if I understand it right now, then this is better then what's in dbus.inc,
because
during rootfs we maybe have /etc/init.d/populate-volatile.sh in $D but do we
want to call
/etc/init.d/populate-volatile.sh on host? Or does it automagically prepend $D
to every path
when it's executing postinst scripts in do_rootfs or does it some sort of
chroot to $D?
Even if we prefix the path with $D in postinst like:
$D${sysconfdir}/init.d/populate-volatile.sh update
the populate-volatile.sh script has hardcoded paths like '/etc/volatile.cache'
and '/etc/ld.so.cache'
inside, so it won't work very well when executed on host (without chrooting)
and we should postpone it
to be executed really on target and that's why we need 'exit 1'.
If I'm wrong please correct me and update 3.1.6. Post Install Scripts to be
more clear about this issues.
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] linux-yocto: consolidated pull request
On 12/01/2011 01:58 PM, Bruce Ashfield wrote: On Thu, Dec 1, 2011 at 12:25 AM, Saul Woldsaul.w...@intel.com wrote: On 11/30/2011 04:36 PM, Bruce Ashfield wrote: Richard/Saul, FYI: I can't get git-send email to work over the hotel wifi, so I can't chain the patches to this email. If you want me to send the patches separately, let me know. But for now, this is the best I can do. This pull request represents a collection of changes that were part of yocto M1 work, and that set the stage for more updates that will follow in the not too distant future. I've bumped the 3.0 kernel to the 3.0.10 baseline (3.0.11 is out, but not in this merge request) and updated our -rt patches to the latest upstream -rt series. This also drops the 2.6.34 recipe and leaves it to be supported in previous releases. If there's somewhere else I should be putting it, let me know and I'll put it there. The kernel revision updates have been built and boot tested by Tom and myself. And we have't seen any problems. Also included in this are some changes to kernel tools that prepare to move the kernel tools into the kernel tree itself. They also move us to doing configuration auditing using the merge_config script that Darren and John Stultz have been working on. And finally there's a small tweak to install the kernel tools via Makefile in the package itself, something that I recall Richard mentioning to me over 2 years ago a meeting .. so I thought I'd finally get to it. Cheers, brucedvh...@linux.intel.com cc: Tom Zanussitom.zanu...@intel.com cc: Darren Hartdvh...@linux.intel.com The following changes since commit d7cd934376ae1edaf7055ec635eb3c85fdbf58b3: squashfs-tools: fix PR, those should start with 'r' (2011-11-30 23:37:44 +) are available in the git repository at: git://git.pokylinux.org/poky-contrib zedd/kernel http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel Bruce Ashfield (7): kern-tools: add pre_config and merge_config.sh to the list of tools kernel-yocto: support allnoconfig base configuration linux-yocto: remove 2.6.34 recipes linux-yocto: v3.0.9 + enhancements linux-yocto: v3.0.10 + rt27 linux-yocto: prefer in-tree tools to external ones kern-tools: use Makefile provided install rules meta/classes/kernel-yocto.bbclass | 24 +- .../kern-tools/kern-tools-native_git.bb | 15 ++ meta/recipes-kernel/linux/linux-yocto-rt_2.6.34.bb | 38 --- meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb | 8 ++-- meta/recipes-kernel/linux/linux-yocto_2.6.34.bb | 49 meta/recipes-kernel/linux/linux-yocto_3.0.bb | 18 6 files changed, 39 insertions(+), 113 deletions(-) delete mode 100644 meta/recipes-kernel/linux/linux-yocto-rt_2.6.34.bb delete mode 100644 meta/recipes-kernel/linux/linux-yocto_2.6.34.bb I had a problem with this change set, it gave me the following: NOTE: Error expanding variable do_kernel_checkout | ETA: 00:00:07 ERROR: Unable to parse /intel/poky/distro/meta/recipes-kernel/linux-libc-headers/linux-libc-headers-yocto_git.bb Looking at this some more before I head for travel, I can't see how my change set caused this. I haven't touched the 2.6.37 kernel (where that SRC_URI points by default) and I haven't touched any of the include files that it depends on. What machine were you building for ? I can't reproduce it here, so I'm looking for more information to properly debug the problem! Problem found and solved, I will be sending this patchset in later today with a consolidated pull. Sau! Cheers, Bruce during parsing. Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/8] libxfont: upgrade from 1.4.3 to 1.4.4
Khem Raj wrote on 2011-12-01:
On Wed, Nov 30, 2011 at 6:12 AM, Dexuan Cui dexuan@intel.com
wrote:
updated LIC_FILES_CHKSUM:
only Copyright holder change in COPYING -- no actual license change.
Signed-off-by: Dexuan Cui dexuan@intel.com ---
.../{libxfont_1.4.3.bb = libxfont_1.4.4.bb} | 8 +++- 1
files changed, 3 insertions(+), 5 deletions(-) rename
meta/recipes-graphics/xorg-lib/{libxfont_1.4.3.bb = libxfont_1.4.4.bb}
(62%)
diff --git a/meta/recipes-graphics/xorg-lib/libxfont_1.4.3.bb
b/meta/recipes-graphics/xorg-lib/libxfont_1.4.4.bb similarity index 62%
rename from meta/recipes-graphics/xorg-lib/libxfont_1.4.3.bb rename to
meta/recipes-graphics/xorg-lib/libxfont_1.4.4.bb index 43a628e..8af0ac9
100644 --- a/meta/recipes-graphics/xorg-lib/libxfont_1.4.3.bb +++
b/meta/recipes-graphics/xorg-lib/libxfont_1.4.4.bb @@ -7,7 +7,7 @@ such
as freetype). require xorg-lib-common.inc
LICENSE= MIT MIT-style BSD -LIC_FILES_CHKSUM =
file://COPYING;md5=d1c29f32ca774cecf0c83b46bb5c +LIC_FILES_CHKSUM
= file://COPYING;md5=a46c8040f2f737bcd0c435feb2ab1c2c
DEPENDS += freetype fontcacheproto xtrans fontsproto libfontenc
PROVIDES = xfont
@@ -15,11 +15,9 @@ PROVIDES = xfont
PR = r0
PE = 1
-#SRC_URI += file://no-scalable-crash.patch
-
Please rm the patch as well.
Thanks for the reminder! I didn't find the patch somehow... sorry.
I'll send a new commit to remove the patch.
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 3/8] lzo: upgrade from 2.05 to the latest version 2.06
Khem Raj wrote on 2011-12-01:
On Wed, Nov 30, 2011 at 6:12 AM, Dexuan Cui dexuan@intel.com
wrote:
Signed-off-by: Dexuan Cui dexuan@intel.com
---
.../lzo/{lzo-2.05 = lzo-2.06}/acinclude.m4 | 0
.../lzo/{lzo-2.05 = lzo-2.06}/autoconf.patch | 9 -
---
diff --git a/configure.ac b/configure.ac
index 650749a..2a78845 100644
@@ -16,6 +23,6 @@ index 650749a..2a78845 100644
-AC_PREREQ(2.67)
+AC_PREREQ(2.65)
is this patch needed still. We use newer autoconf so why do we go back
to 2.65 in this case ?
Hi Khem,
Thanks a lot for the reminder!
You're correct. We don't need the patch any longer according to my test.
I'll send a new commit to remove the patch.
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 6/8] xcb-util: upgrade from 0.3.6 to 0.3.8
Khem Raj wrote on 2011-12-01: On Wed, Nov 30, 2011 at 6:12 AM, Dexuan Cui dexuan@intel.com wrote: updated LIC_FILES_CHKSUM since the code was re-organized, but the license remains the same. --- /dev/null +++ b/meta/recipes-graphics/xcb/xcb-util_0.3.8.bb @@ -0,0 +1,9 @@ +file://src/xcb_aux.c;endline=30;md5=ae305b9c2a38f9ba27060191046a64 60 +\ + file://src/xcb_event.h;endline=27;md5=627be35 5aee59e1b8ade80d5bd90fad9 if license remains same then why do we not check for the remaining files from there new location wherever they moved to after code reorg ? Some files in 0.3.6 doesn't exist in 0.3.8. According the Changelog, they seem to be demo code, or obsolete code. I reserved the 2 files of LIC_FILES_CHKSUM since they're still in 0.3.8, but with a different directory. The other files don't exist now. 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 3/3] runqemu-ifup, runqemu-internal: be wiser when locating the network tools
Richard Purdie wrote on 2011-12-01:
On Thu, 2011-12-01 at 17:21 +0800, Dexuan Cui wrote:
When working on the self-hosted-image work, I found the PATH
variable in the
Level-1 target doesn't have /sbin and /usr/sbin, so runqemu can't
run properly since the tools are installeld at /sbin/ifconfig
/sbin/route /usr/sbin/iptables
The patch is used to fix the issue by setting a temp PATH when running
which.
Signed-off-by: Dexuan Cui dexuan@intel.com
---
scripts/runqemu-ifup |8 +---
scripts/runqemu-internal |3 ++-
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/scripts/runqemu-ifup b/scripts/runqemu-ifup index
870cb6b..9e697a8 100755
--- a/scripts/runqemu-ifup
+++ b/scripts/runqemu-ifup
@@ -64,7 +64,9 @@ if [ $STATUS -ne 0 ]; then
exit 1
fi
-IFCONFIG=`which ifconfig 2 /dev/null`
+PATH_TMP=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
+
+IFCONFIG=`{ PATH=$PATH:$PATH_TMP; which ifconfig 2 /dev/null; }`
if [ x$IFCONFIG = x ]; then
# better than nothing...
IFCONFIG=/sbin/ifconfig
I don't really like this, its getting hard to understand whats going on.
Can we abstract this to a function which tries PATH, then tries our
own PATH_TMP? This would reduce code duplication and makes it clearer
what the code is doing...
Good suggestion!
I'll re-make the patch and re-send it out.
BTW, since I'll be on leave later today, I might not be able to finish this
today.
I discussed with Saul and he could kindly help me to finish this. :-)
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/3] make: expand MAKEFLAGS before we re-exec after rebuilding makefiles.
Richard Purdie wrote on 2011-12-01: On Thu, 2011-12-01 at 10:22 +0100, Koen Kooi wrote: Op 1 dec. 2011, om 10:21 heeft Dexuan Cui het volgende geschreven: This patch was got from the upstream cvs repo of make to fix the bug of make-3.82: http://savannah.gnu.org/bugs/?30723 Signed-off-by: Dexuan Cui dexuan@intel.com --- .../make/make-3.82/expand_MAKEFLAGS.patch | 39 meta/recipes-devtools/make/make_3.82.bb |4 ++- 2 files changed, 42 insertions(+), 1 deletions(-) create mode 100644 meta/recipes-devtools/make/make-3.82/expand_MAKEFLAGS.patch diff --git a/meta/recipes-devtools/make/make-3.82/expand_MAKEFLAGS.patch b/meta/recipes-devtools/make/make-3.82/expand_MAKEFLAGS.patch new file mode 100644 index 000..4184937 --- /dev/null +++ b/meta/recipes-devtools/make/make-3.82/expand_MAKEFLAGS.patch @@ -0,0 +1,39 @@ +Upstream-Status: Inappropriate [The fix is already in upstream +cvs repo, but not in the stable release] Isn't 'backport' a better description than 'inappropriate'? Agreed, I've taken this patch but changed the patch status to backport. Thanks a lot, Richard and Koen! 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 6/8] xcb-util: upgrade from 0.3.6 to 0.3.8
Martin Jansa wrote on 2011-12-01: On Wed, Nov 30, 2011 at 10:12:32PM +0800, Dexuan Cui wrote: updated LIC_FILES_CHKSUM since the code was re-organized, but the license remains the same. meta/recipes-graphics/xcb/xcb-util_0.3.6.bb | 18 -- meta/recipes-graphics/xcb/xcb-util_0.3.8.bb |9 + 2 files changed, 9 insertions(+), 18 deletions(-) delete mode 100644 meta/recipes-graphics/xcb/xcb-util_0.3.6.bb create mode 100644 meta/recipes-graphics/xcb/xcb-util_0.3.8.bb Because there is only one .so lib now after: http://cgit.freedesktop.org/xcb/util/commit/?id=118a3c86b3d3b2fab20f36 5e4a5703e40ad2e1b1 the resulting package is renamed from Package xcb-util (0.3.6-r0) is installed on root and has the following files: /usr/lib/libxcb-aux.so.0 /usr/lib/libxcb-keysyms.so.1 /usr/lib/libxcb-icccm.so.1 /usr/lib/libxcb-image.so.0.0.0 /usr/lib/libxcb-atom.so.1.0.0 /usr/lib/libxcb-icccm.so.1.0.0 /usr/lib/libxcb-event.so.1 /usr/lib/libxcb-reply.so.1.0.0 /usr/lib/libxcb-property.so.1.0.0 /usr/lib/libxcb-render-util.so.0.0.0 /usr/lib/libxcb-property.so.1 /usr/lib/libxcb-reply.so.1 /usr/lib/libxcb-image.so.0 /usr/lib/libxcb-atom.so.1 /usr/lib/libxcb-event.so.1.0.0 /usr/lib/libxcb-render-util.so.0 /usr/lib/libxcb-aux.so.0.0.0 /usr/lib/libxcb-keysyms.so.1.0.0 Now it's libxcb-util0, because of only one .so packages-split/xcb-util packages-split/xcb-util/usr packages-split/xcb-util/usr/lib packages-split/xcb-util/usr/lib/libxcb-util.so.0.0.0 packages-split/xcb-util/usr/lib/libxcb-util.so.0 So we need at least PR bumps for recipes which were RDEPENDing on xcb-util (ie because of shlibs). I'll send patches later for recipes which are failing for me now.. Hi Martin, thanks very much for helping on this! :-) 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 0/8] [Dexuan]: upgrades for 7 recipes
Richard Purdie wrote on 2011-12-01: On Wed, 2011-11-30 at 22:12 +0800, Dexuan Cui wrote: The following changes since commit 00d121aad3a4263bc0e3a004a3a479e6352e063d: clutter-box2d: drop unbuildable clutter-box2d-1.6_0.10.0 (2011-11-30 22:06:00 +0800) are available in the git repository at: git://git.pokylinux.org/poky-contrib dcui/master http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dcui/master Dexuan Cui (8): pixman: upgrade from 0.22.0 to the latest stable 0.24.0 libxrandr: upgrade from 1.3.1 to the latest version 1.3.2 lzo: upgrade from 2.05 to the latest version 2.06 libxfont: upgrade from 1.4.3 to 1.4.4 libxcursor: upgrade from 1.1.11 to 1.1.12 xcb-util: upgrade from 0.3.6 to 0.3.8 I merged these, thanks. inputproto: upgrade from 2.0.2 to the latest stable 2.0.99.1 I was a bit worried about this one - is 20.0.99.1 stable or a prerelease version? Should we just wait for the final release of that one? Thanks for the remind! It's a development snapshot of 2.1. 2.1.x (like 2.1.99.1) is not stable yet, either. So, I think we can use the current 2.0.2 until 2.2 is out. I'll update the RECIPE_NO_UPDATE_REASON field in distro_tracking_fields.inc. distro_tracking_fields.inc: update the info This failed to apply. Could you rebase and resubmit please? I don't know the cause, but it did apply in my side, against poky master, or oe-core master. Anyway, I'll rebase it against poky master(I'll also ensure it can apply fine against oe-core master). Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] bootimage: Use ${S} explicitly for generated config files
The syslinux and grub-efi classes were generating config files in the current
working directory. This caused a failure due to a race in the creation of the
directories leading to cwd changing and the build failing to find the config
files. While this has been addressed in bitbake, it is better to use an
explicit path.
While ${WORKDIR} may seem a more appropriate place, the recipe
already uses ${S} for the hdd and cd construction, so we use ${S}
here to keep things consolidated and consistent and address the issue
with minimal change.
Signed-off-by: Darren Hart dvh...@linux.intel.com
---
meta/classes/grub-efi.bbclass |8 +++-
meta/classes/syslinux.bbclass |4 ++--
2 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/meta/classes/grub-efi.bbclass b/meta/classes/grub-efi.bbclass
index 333e6c5..36b5831 100644
--- a/meta/classes/grub-efi.bbclass
+++ b/meta/classes/grub-efi.bbclass
@@ -16,7 +16,7 @@
do_bootimg[depends] += grub-efi-${TARGET_ARCH}-native:do_deploy
-GRUBCFG = grub.cfg
+GRUBCFG = ${S}/grub.cfg
GRUB_TIMEOUT ?= 10
#FIXME: build this from the machine config
GRUB_OPTS ?= serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1
@@ -56,7 +56,7 @@ grubefi_iso_populate() {
# FIXUP the EFIDIR token in the config
# FIXME: This can be dropped once mkdosfs is fixed
- sed -i s@EFIDIR@${EFIDIR}@g ${GRUB_ISODIR}/${GRUBCFG}
+ sed -i s@EFIDIR@${EFIDIR}@g ${GRUB_ISODIR}/$(basename ${GRUBCFG})
}
grubefi_hddimg_populate() {
@@ -64,7 +64,7 @@ grubefi_hddimg_populate() {
# FIXUP the EFIDIR token in the config
# FIXME: This can be dropped once mkdosfs is fixed
- sed -i s@EFIDIR@@g ${GRUB_HDDDIR}/${GRUBCFG}
+ sed -i s@EFIDIR@@g ${GRUB_HDDDIR}/$(basename ${GRUBCFG})
}
# FIXME: The EFIDIR token can be replaced with ${EFIDIR} once the
@@ -90,8 +90,6 @@ python build_grub_cfg() {
if not cfile:
raise bb.build.FuncFailed('Unable to read GRUBCFG')
-#bb.mkdirhier(os.path.dirname(cfile))
-
try:
cfgfile = file(cfile, 'w')
except OSError:
diff --git a/meta/classes/syslinux.bbclass b/meta/classes/syslinux.bbclass
index 6eb804b..91c4275 100644
--- a/meta/classes/syslinux.bbclass
+++ b/meta/classes/syslinux.bbclass
@@ -15,8 +15,8 @@
do_bootimg[depends] += syslinux:do_populate_sysroot \
syslinux-native:do_populate_sysroot
-SYSLINUXCFG = syslinux.cfg
-SYSLINUXMENU = menu
+SYSLINUXCFG = ${S}/syslinux.cfg
+SYSLINUXMENU = ${S}/menu
SYSLINUX_ISODIR = ${ISODIR}/isolinux
SYSLINUX_HDDDIR = ${HDDDIR}
--
1.7.6.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
