[OE-core] [PATCH v2] coreutils: fix search paths for libstdbuf.so
*fix the following error:
|stdbuf: failed to find 'libstdbuf.so'
*PKGLIBEXECDIR is the search paths for libstdbuf.so
|PKGLIBEXECDIR='$(pkglibexecdir)'
|pkglibexecdir='${libexecdir}/${PACKAGE}'
Signed-off-by: Chunrong Guo b40...@freescale.com
---
meta/recipes-core/coreutils/coreutils_8.22.bb | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/meta/recipes-core/coreutils/coreutils_8.22.bb
b/meta/recipes-core/coreutils/coreutils_8.22.bb
index a26aa02..ba3a0a0 100644
--- a/meta/recipes-core/coreutils/coreutils_8.22.bb
+++ b/meta/recipes-core/coreutils/coreutils_8.22.bb
@@ -22,7 +22,7 @@ SRC_URI[md5sum] = 8fb0ae2267aa6e728958adc38f8163a2
SRC_URI[sha256sum] =
5b3e94998152c017e6c75d56b9b994188eb71bf46d4038a642cb9141f6ff1212
EXTRA_OECONF_class-native = --without-gmp
-EXTRA_OECONF_class-target = --enable-install-program=arch
+EXTRA_OECONF_class-target = --enable-install-program=arch
--libexecdir=${libdir}
# acl is not a default feature
#
@@ -71,8 +71,6 @@ do_install_append() {
# in update-alternatives to fail, therefore use lbracket - the name used
# for the actual source file.
mv ${D}${bindir}/[ ${D}${bindir}/lbracket.${BPN}
- install -d ${D}${libdir}/coreutils
- mv ${D}${libexecdir}/coreutils/libstdbuf.so ${D}${libdir}/coreutils
}
inherit update-alternatives
--
1.8.3.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/1] package_manager.py: delete RPM db locks after calling rpmresolve
Put this on hold. I'll do some more investigations. I want to see what's the deal with those rpm lock DBs and why we don't delete them only once, after the rootfs generation has completely finished (after postprocess commands are called, etc). laurentiu On Thu, Mar 27, 2014 at 06:18:52PM +0200, Laurentiu Palcu wrote: The following changes since commit c4eeaa8e35e926b6d1f633549f76d1ba9ed9278b: bitbake: knotty: Show a link to the logfile for failed setscene tasks (2014-03-27 10:42:08 +) are available in the git repository at: git://git.yoctoproject.org/poky-contrib lpalcu/b6049_do_rootfs_crash http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=lpalcu/b6049_do_rootfs_crash Laurentiu Palcu (1): package_manager.py: delete RPM db locks after calling rpmresolve meta/lib/oe/package_manager.py | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) -- 1.7.9.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/6] initscripts: Avoid restarting rpcbind daemon
From: Yue Tao yue@windriver.com Check whether rpcbind daemon already run before starting it. Signed-off-by: Yue Tao yue@windriver.com Signed-off-by: Robert Yang liezhi.y...@windriver.com Signed-off-by: Jeff Polk jeff.p...@windriver.com Signed-off-by: Hongxu Jia hongxu@windriver.com --- meta/recipes-core/initscripts/initscripts-1.0/mountnfs.sh | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/meta/recipes-core/initscripts/initscripts-1.0/mountnfs.sh b/meta/recipes-core/initscripts/initscripts-1.0/mountnfs.sh index fe6c196..be9f597 100755 --- a/meta/recipes-core/initscripts/initscripts-1.0/mountnfs.sh +++ b/meta/recipes-core/initscripts/initscripts-1.0/mountnfs.sh @@ -67,9 +67,12 @@ if test $rpcbind = yes then if test -x /usr/sbin/rpcbind then - echo -n Starting rpcbind... - start-stop-daemon --start --quiet --exec /usr/sbin/rpcbind - sleep 2 + service rpcbind status /dev/null + if [ $? != 0 ]; then + echo -n Starting rpcbind... + start-stop-daemon --start --quiet --exec /usr/sbin/rpcbind + sleep 2 + fi fi fi -- 1.8.1.2 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/6] kmod: fix O_CLOEXEC not supported on old kernel
From: Robert Yang liezhi.y...@windriver.com
O_CLOEXEC is introduced from Linux 2.6.23, so old kernel doesn't have
it, we need check before use.
This patch is much more like a workaround, since it may need fcntl() use
FD_CLOEXEC to replace.
Signed-off-by: Ting Liu b28...@freescale.com
Signed-off-by: Robert Yang liezhi.y...@windriver.com
Signed-off-by: Hongxu Jia hongxu@windriver.com
---
meta/recipes-kernel/kmod/kmod.inc | 1 +
meta/recipes-kernel/kmod/kmod/fix-O_CLOEXEC.patch | 38 +++
2 files changed, 39 insertions(+)
create mode 100644 meta/recipes-kernel/kmod/kmod/fix-O_CLOEXEC.patch
diff --git a/meta/recipes-kernel/kmod/kmod.inc
b/meta/recipes-kernel/kmod/kmod.inc
index b7e176c..47445eb 100644
--- a/meta/recipes-kernel/kmod/kmod.inc
+++ b/meta/recipes-kernel/kmod/kmod.inc
@@ -25,6 +25,7 @@ SRC_URI =
git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git \
file://run-ptest \
file://ptest.patch \
file://avoid_parallel_tests.patch \
+ file://fix-O_CLOEXEC.patch \
S = ${WORKDIR}/git
diff --git a/meta/recipes-kernel/kmod/kmod/fix-O_CLOEXEC.patch
b/meta/recipes-kernel/kmod/kmod/fix-O_CLOEXEC.patch
new file mode 100644
index 000..8161d61
--- /dev/null
+++ b/meta/recipes-kernel/kmod/kmod/fix-O_CLOEXEC.patch
@@ -0,0 +1,38 @@
+From bd43367eee868059770188fd9e9db38520dc6fff Mon Sep 17 00:00:00 2001
+From: Robert Yang liezhi.y...@windriver.com
+Date: Wed, 22 Jan 2014 01:06:40 -0500
+Subject: [PATCH] libkmod/libkmod-internal.h: check whether O_CLOEXEC is
+ defined or not
+
+O_CLOEXEC is introduced from Linux 2.6.23, so old kernel doesn't have
+it, we need check before use.
+
+This patch is much more like a workaround, since it may need fcntl() use
+FD_CLOEXEC to replace.
+
+This problem was reported by Ting Liu b28...@freescale.com
+Signed-off-by: Robert Yang liezhi.y...@windriver.com
+
+Upstream-Status: Pending
+---
+ libkmod/libkmod-internal.h |4
+ 1 file changed, 4 insertions(+)
+
+diff --git a/libkmod/libkmod-internal.h b/libkmod/libkmod-internal.h
+index 0180124..100b40f 100644
+--- a/libkmod/libkmod-internal.h
b/libkmod/libkmod-internal.h
+@@ -9,6 +9,10 @@
+ #include macro.h
+ #include libkmod.h
+
++#ifndef O_CLOEXEC
++#define O_CLOEXEC 0
++#endif
++
+ static _always_inline_ _printf_format_(2, 3) void
+ kmod_log_null(struct kmod_ctx *ctx, const char *format, ...) {}
+
+--
+1.7.10.4
+
--
1.8.1.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/6] wayland-native: disable unused macro checks to fix build issue on Centos5.x
From: Ting Liu b28...@freescale.com
We only build wayland-native for the scanner, so disable the bits we
don't actually need. This avoid build issue on older distro such as
Centos 5.x:
| error: 'O_CLOEXEC' undeclared (first use in this function)
| error: sys/timerfd.h: No such file or directory
| error: 'CLOCK_MONOTONIC' undeclared (first use in this function)
| error: 'TFD_CLOEXEC' undeclared (first use in this function)
| error: 'SFD_CLOEXEC' undeclared (first use in this function)
Signed-off-by: Ting Liu b28...@freescale.com
Signed-off-by: Robert Yang liezhi.y...@windriver.com
Signed-off-by: Hongxu Jia hongxu@windriver.com
---
...disable-macro-checks-not-used-for-scanner.patch | 50 ++
meta/recipes-graphics/wayland/wayland_1.4.0.bb | 4 +-
2 files changed, 53 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-graphics/wayland/wayland/disable-macro-checks-not-used-for-scanner.patch
diff --git
a/meta/recipes-graphics/wayland/wayland/disable-macro-checks-not-used-for-scanner.patch
b/meta/recipes-graphics/wayland/wayland/disable-macro-checks-not-used-for-scanner.patch
new file mode 100644
index 000..bf499bb
--- /dev/null
+++
b/meta/recipes-graphics/wayland/wayland/disable-macro-checks-not-used-for-scanner.patch
@@ -0,0 +1,50 @@
+disable macro checks not used for scanner
+
+We only build wayland-native for the scanner, so disable the bits we don't
+actually need. This avoid build issue on older distro such as Centos 5.x:
+| error: 'O_CLOEXEC' undeclared (first use in this function)
+| error: sys/timerfd.h: No such file or directory
+| error: 'CLOCK_MONOTONIC' undeclared (first use in this function)
+| error: 'TFD_CLOEXEC' undeclared (first use in this function)
+| error: 'SFD_CLOEXEC' undeclared (first use in this function)
+
+Upstream-Status: Pending
+
+Signed-off-by: Ting Liu b28...@freescale.com
+---
+ configure.ac | 20 ++--
+ 1 file changed, 10 insertions(+), 10 deletions(-)
+
+diff --git a/configure.ac b/configure.ac
+--- a/configure.ac
b/configure.ac
+@@ -41,16 +41,16 @@ AC_SUBST(GCC_CFLAGS)
+
+ AC_CHECK_FUNCS([accept4 mkostemp])
+
+-AC_CHECK_DECL(SFD_CLOEXEC,[],
+-[AC_MSG_ERROR(SFD_CLOEXEC is needed to compile wayland)],
+-[[#include sys/signalfd.h]])
+-AC_CHECK_DECL(TFD_CLOEXEC,[],
+-[AC_MSG_ERROR(TFD_CLOEXEC is needed to compile wayland)],
+-[[#include sys/timerfd.h]])
+-AC_CHECK_DECL(CLOCK_MONOTONIC,[],
+-[AC_MSG_ERROR(CLOCK_MONOTONIC is needed to compile wayland)],
+-[[#include time.h]])
+-AC_CHECK_HEADERS([execinfo.h])
++##AC_CHECK_DECL(SFD_CLOEXEC,[],
++# [AC_MSG_ERROR(SFD_CLOEXEC is needed to compile wayland)],
++# [[#include sys/signalfd.h]])
++#AC_CHECK_DECL(TFD_CLOEXEC,[],
++# [AC_MSG_ERROR(TFD_CLOEXEC is needed to compile wayland)],
++# [[#include sys/timerfd.h]])
++#AC_CHECK_DECL(CLOCK_MONOTONIC,[],
++# [AC_MSG_ERROR(CLOCK_MONOTONIC is needed to compile wayland)],
++# [[#include time.h]])
++#AC_CHECK_HEADERS([execinfo.h])
+
+ AC_ARG_ENABLE([scanner],
+ [AC_HELP_STRING([--disable-scanner],
+--
+1.8.3.2
+
diff --git a/meta/recipes-graphics/wayland/wayland_1.4.0.bb
b/meta/recipes-graphics/wayland/wayland_1.4.0.bb
index 604b7f4..9f6419d 100644
--- a/meta/recipes-graphics/wayland/wayland_1.4.0.bb
+++ b/meta/recipes-graphics/wayland/wayland_1.4.0.bb
@@ -14,7 +14,9 @@ SRC_URI =
http://wayland.freedesktop.org/releases/${BPN}-${PV}.tar.xz;
SRC_URI[md5sum] = 332cf9191837be12638a29265ed7cf46
SRC_URI[sha256sum] =
18f33b9f15b4c8b662fb1968e7636e7926b419dfc48de8a164b3a3d7095c5a58
-SRC_URI_append_class-native = file://just-scanner.patch
+SRC_URI_append_class-native = file://just-scanner.patch \
+file://disable-macro-checks-not-used-for-scanner.patch \
+
EXTRA_OECONF_class-native = --disable-documentation --enable-scanner
inherit autotools pkgconfig
--
1.8.1.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/7][Part II] wr-misc patches
WindRiver patches was sent for YP compliance. There are total 22 patches, and separate them into 4 parts, each part is individual which means there is no dependence between them. //Hongxu The following changes since commit 8c3eb5ee4582b6f6d489549290937657f37fc19e: packagegroup-toolset-native: Update after ocf-linux - cryptodev-linux change (2014-03-27 19:53:30 +) are available in the git repository at: git://git.pokylinux.org/poky-contrib hongxu/wr-misc-patches-2 http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=hongxu/wr-misc-patches-2 Amy Fong (1): native-python: bad interpreter error message Hongxu Jia (1): lttng-ust: add python to lttng-ust's RDEPENDS Hu Yadi (1): libpcap: add PACKAGECONFIG for libnl1 Ming Liu (1): libpam: fix multilib packaging issue for pam-plugins Yue Tao (3): tzcode-native: Replace fixed version with PV guile: add texinfo-native to DEPENDS e2fsprogs: Add e2fsprogs-mke2fs and e2fsprogs-e2fsck as recommend packages meta/classes/distutils.bbclass | 14 ++- meta/recipes-connectivity/libpcap/libpcap.inc | 1 + .../recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bb | 1 + meta/recipes-devtools/guile/guile_2.0.9.bb | 2 +- meta/recipes-extended/pam/libpam_1.1.6.bb | 29 +++--- .../recipes-extended/tzcode/tzcode-native_2013i.bb | 3 ++- meta/recipes-kernel/lttng/lttng-ust_2.3.1.bb | 1 + 7 files changed, 44 insertions(+), 7 deletions(-) -- 1.8.1.2 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/6] qemu: Add addition environment space to boot loader qemu-system-mips
From: Jeff Polk jeff.p...@windriver.com
The qemu mips malta base board boot loader uses environment strings
with a max length of 256 bytes which is not long enough to accommodate
a long NFS path in addition to the normal kernel boot command line
arguments.
The solution is to expand the environment string length to 1024 bytes.
Signed-off-by: Jason Wessel jason.wes...@windriver.com
Signed-off-by: Roy Li rongqing...@windriver.com
Signed-off-by: Jeff Polk jeff.p...@windriver.com
Signed-off-by: Hongxu Jia hongxu@windriver.com
---
.../qemu/files/qemu-enlarge-env-entry-size.patch | 31 ++
meta/recipes-devtools/qemu/qemu_1.7.0.bb | 3 ++-
2 files changed, 33 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-devtools/qemu/files/qemu-enlarge-env-entry-size.patch
diff --git a/meta/recipes-devtools/qemu/files/qemu-enlarge-env-entry-size.patch
b/meta/recipes-devtools/qemu/files/qemu-enlarge-env-entry-size.patch
new file mode 100644
index 000..c7425ab
--- /dev/null
+++ b/meta/recipes-devtools/qemu/files/qemu-enlarge-env-entry-size.patch
@@ -0,0 +1,31 @@
+qemu: Add addition environment space to boot loader qemu-system-mips
+
+Upstream-Status: Inappropriate - OE uses deep paths
+
+If you create a project with very long directory names like 128 characters
+deep and use NFS, the kernel arguments will be truncated. The kernel will
+accept longer strings such as 1024 bytes, but the qemu boot loader defaulted
+to only 256 bytes. This patch expands the limit.
+
+Signed-off-by: Jason Wessel jason.wes...@windriver.com
+Signed-off-by: Roy Li rongqing...@windriver.com
+---
+ hw/mips/mips_malta.c|2 +-
+ 1 files changed, 1 insertions(+), 1 deletions(-)
+
+diff --git a/hw/mips/mips_malta.c b/hw/mips/mips_malta.c
+index 9d521cc..17c0391 100644
+--- a/hw/mips/mips_malta.c
b/hw/mips/mips_malta.c
+@@ -53,7 +53,7 @@
+
+ #define ENVP_ADDR 0x80002000l
+ #define ENVP_NB_ENTRIES 16
+-#define ENVP_ENTRY_SIZE 256
++#define ENVP_ENTRY_SIZE 1024
+
+ /* Hardware addresses */
+ #define FLASH_ADDRESS 0x1e00ULL
+--
+1.7.10.4
+
diff --git a/meta/recipes-devtools/qemu/qemu_1.7.0.bb
b/meta/recipes-devtools/qemu/qemu_1.7.0.bb
index c0e8b55..be6dd51 100644
--- a/meta/recipes-devtools/qemu/qemu_1.7.0.bb
+++ b/meta/recipes-devtools/qemu/qemu_1.7.0.bb
@@ -3,7 +3,8 @@ require qemu.inc
LIC_FILES_CHKSUM = file://COPYING;md5=441c28d2cf86e15a37fa47e15a72fbac \
file://COPYING.LIB;endline=24;md5=c04def7ae38850e7d3ef548588159913
-SRC_URI += file://fxrstorssefix.patch
+SRC_URI += file://fxrstorssefix.patch \
+file://qemu-enlarge-env-entry-size.patch
SRC_URI_prepend = http://wiki.qemu.org/download/qemu-${PV}.tar.bz2;
SRC_URI[md5sum] = 32893941d40d052a5e649efcf06aca06
--
1.8.1.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/6][Part I] wr-misc patches
WindRiver patches was sent for YP compliance. There are total 22 patches, and separate them into 4 parts, each part is individual which means there is no dependence between them. //Hongxu The following changes since commit 8c3eb5ee4582b6f6d489549290937657f37fc19e: packagegroup-toolset-native: Update after ocf-linux - cryptodev-linux change (2014-03-27 19:53:30 +) are available in the git repository at: git://git.pokylinux.org/poky-contrib hongxu/wr-misc-patches http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=hongxu/wr-misc-patches Baogen Shang (1): openssl: Fix pod2man des.pod error on Ubuntu 12.04 Jeff Polk (1): qemu: Add addition environment space to boot loader qemu-system-mips Jiang Lu (1): Qemu:Arm:versatilepb: Add memory size checking Robert Yang (1): kmod: fix O_CLOEXEC not supported on old kernel Ting Liu (1): wayland-native: disable unused macro checks to fix build issue on Centos5.x Yue Tao (1): initscripts: Avoid restarting rpcbind daemon .../openssl-1.0.1e/openssl-fix-des.pod-error.patch | 19 .../recipes-connectivity/openssl/openssl_1.0.1e.bb | 1 + .../initscripts/initscripts-1.0/mountnfs.sh| 9 ++-- ...-Arm-versatilepb-Add-memory-size-checking.patch | 40 + .../qemu/files/qemu-enlarge-env-entry-size.patch | 31 ++ meta/recipes-devtools/qemu/qemu_1.7.0.bb | 4 +- ...disable-macro-checks-not-used-for-scanner.patch | 50 ++ meta/recipes-graphics/wayland/wayland_1.4.0.bb | 4 +- meta/recipes-kernel/kmod/kmod.inc | 1 + meta/recipes-kernel/kmod/kmod/fix-O_CLOEXEC.patch | 38 10 files changed, 192 insertions(+), 5 deletions(-) create mode 100644 meta/recipes-connectivity/openssl/openssl-1.0.1e/openssl-fix-des.pod-error.patch create mode 100644 meta/recipes-devtools/qemu/files/Qemu-Arm-versatilepb-Add-memory-size-checking.patch create mode 100644 meta/recipes-devtools/qemu/files/qemu-enlarge-env-entry-size.patch create mode 100644 meta/recipes-graphics/wayland/wayland/disable-macro-checks-not-used-for-scanner.patch create mode 100644 meta/recipes-kernel/kmod/kmod/fix-O_CLOEXEC.patch -- 1.8.1.2 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/7] native-python: bad interpreter error message
From: Amy Fong amy.f...@windriver.com
On some builds with really long paths, we can end up exceeding the maximum
length line for an interpreter (man execve: A maximum line length of
127 characters is allowed for the first line in a #! executable shell
script.)
To avoid this limit, we use env to execute python, with this, we will
be using python that's first found in our PATH.
The former ${bindir}/env is not a good idea for apps requiring native-python
since coreutil*-native may not have been built (${bindir}/env may not exist)
and with long paths, we can end up running into the same issue, hence we
use /usr/bin/env from the host.
Signed-off-by: Amy Fong amy.f...@windriver.com
Signed-off-by: Robert Yang liezhi.y...@windriver.com
Signed-off-by: Hongxu Jia hongxu@windriver.com
---
meta/classes/distutils.bbclass | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/meta/classes/distutils.bbclass b/meta/classes/distutils.bbclass
index f3da023..1a53ebd 100644
--- a/meta/classes/distutils.bbclass
+++ b/meta/classes/distutils.bbclass
@@ -50,7 +50,13 @@ distutils_do_install() {
for i in ${D}${bindir}/* ; do \
if [ ${PN} != ${BPN}-native ]; then
sed -i -e
s:${STAGING_BINDIR_NATIVE}/python-native/python:${bindir}/env\ python:g $i
- fi
+else
+ # The former ${bindir}/env is not a good idea for apps
requiring native-python
+ # since coreutil*-native may not have been built
(${bindir}/env may not exist)
+ # and with long paths, we can end up running into an
issue where the
+ # interpreter line is too long, hence we use
/usr/bin/env from the host.
+ sed -i -e
s:${STAGING_BINDIR_NATIVE}/python-native/python:/usr/bin/env\ python:g $i
+fi
sed -i -e s:${STAGING_BINDIR_NATIVE}:${bindir}:g $i
done
fi
@@ -59,6 +65,12 @@ distutils_do_install() {
for i in ${D}${sbindir}/* ; do \
if [ ${PN} != ${BPN}-native ]; then
sed -i -e
s:${STAGING_BINDIR_NATIVE}/python-native/python:${bindir}/env\ python:g $i
+else
+ # The former ${bindir}/env is not a good idea for apps
requiring native-python
+ # since coreutil*-native may not have been built
(${bindir}/env may not exist)
+ # and with long paths, we can end up running into an
issue where the
+ # interpreter line is too long, hence we use
/usr/bin/env from the host.
+ sed -i -e
s:${STAGING_BINDIR_NATIVE}/python-native/python:/usr/bin/env\ python:g $i
fi
sed -i -e s:${STAGING_BINDIR_NATIVE}:${bindir}:g $i
done
--
1.8.1.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/7] guile: add texinfo-native to DEPENDS
From: Yue Tao yue@windriver.com Use texinfo-native instead of host command Signed-off-by: Yue Tao yue@windriver.com Signed-off-by: Hongxu Jia hongxu@windriver.com --- meta/recipes-devtools/guile/guile_2.0.9.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-devtools/guile/guile_2.0.9.bb b/meta/recipes-devtools/guile/guile_2.0.9.bb index 60318e7..1e907ba 100644 --- a/meta/recipes-devtools/guile/guile_2.0.9.bb +++ b/meta/recipes-devtools/guile/guile_2.0.9.bb @@ -32,7 +32,7 @@ SRC_URI[sha256sum] = f70a38c8d9751f442679bfe61852bba8545af4d4355d037630997c2f37 inherit autotools gettext BBCLASSEXTEND = native -DEPENDS = libunistring bdwgc gmp libtool libffi +DEPENDS = libunistring bdwgc gmp libtool libffi texinfo-native # add guile-native only to the target recipe's DEPENDS DEPENDS_append_class-target = guile-native libatomics-ops -- 1.8.1.2 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/7] tzcode-native: Replace fixed version with PV
From: Yue Tao yue@windriver.com
Signed-off-by: Yue Tao yue@windriver.com
Signed-off-by: Robert Yang liezhi.y...@windriver.com
Signed-off-by: Jeff Polk jeff.p...@windriver.com
Signed-off-by: Hongxu Jia hongxu@windriver.com
---
meta/recipes-extended/tzcode/tzcode-native_2013i.bb | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-extended/tzcode/tzcode-native_2013i.bb
b/meta/recipes-extended/tzcode/tzcode-native_2013i.bb
index cfedc5b..ea64c97 100644
--- a/meta/recipes-extended/tzcode/tzcode-native_2013i.bb
+++ b/meta/recipes-extended/tzcode/tzcode-native_2013i.bb
@@ -6,7 +6,8 @@ LIC_FILES_CHKSUM =
file://${WORKDIR}/README;md5=0b7570113550eb5d30aa4bd220964b8
# note that we allow for us to use data later than our code version
#
SRC_URI = ftp://ftp.iana.org/tz/releases/tzcode${PV}.tar.gz;name=tzcode \
- ftp://ftp.iana.org/tz/releases/tzdata2013i.tar.gz;name=tzdata;
+ ftp://ftp.iana.org/tz/releases/tzdata${PV}.tar.gz;name=tzdata \
+
SRC_URI[tzcode.md5sum] = 86154c8b0cfb47f4e2027ecaa2ec547a
SRC_URI[tzcode.sha256sum] =
63bba6790afc1cb2ea0af2b998a35fc237e247608140dbe4e08b4216a8c31358
--
1.8.1.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 6/6] openssl: Fix pod2man des.pod error on Ubuntu 12.04
From: Baogen Shang baogen.sh...@windriver.com This is a formatting fix, '=back' is required before '=head1' on Ubuntu 12.04. Signed-off-by: Baogen Shang baogen.sh...@windriver.com Signed-off-by: Jeff Polk jeff.p...@windriver.com Signed-off-by: Hongxu Jia hongxu@windriver.com --- .../openssl-1.0.1e/openssl-fix-des.pod-error.patch| 19 +++ meta/recipes-connectivity/openssl/openssl_1.0.1e.bb | 1 + 2 files changed, 20 insertions(+) create mode 100644 meta/recipes-connectivity/openssl/openssl-1.0.1e/openssl-fix-des.pod-error.patch diff --git a/meta/recipes-connectivity/openssl/openssl-1.0.1e/openssl-fix-des.pod-error.patch b/meta/recipes-connectivity/openssl/openssl-1.0.1e/openssl-fix-des.pod-error.patch new file mode 100644 index 000..de49729 --- /dev/null +++ b/meta/recipes-connectivity/openssl/openssl-1.0.1e/openssl-fix-des.pod-error.patch @@ -0,0 +1,19 @@ +openssl: Fix pod2man des.pod error on Ubuntu 12.04 + +This is a formatting fix, '=back' is required before +'=head1' on Ubuntu 12.04. + +Upstream-Status: Pending +Signed-off-by: Baogen Shang baogen.sh...@windriver.com +diff -urpN a_origin/des.pod b_modify/des.pod +--- a_origin/crypto/des/des.pod2013-08-15 15:02:56.211674589 +0800 b_modify/crypto/des/des.pod2013-08-15 15:04:14.439674580 +0800 +@@ -181,6 +181,8 @@ the uuencoded file to embed in the begin + output. If there is no name specified after the B-u, the name text.des + will be embedded in the header. + ++=back ++ + =head1 SEE ALSO + + ps(1), diff --git a/meta/recipes-connectivity/openssl/openssl_1.0.1e.bb b/meta/recipes-connectivity/openssl/openssl_1.0.1e.bb index 2c3885c..618ba68 100644 --- a/meta/recipes-connectivity/openssl/openssl_1.0.1e.bb +++ b/meta/recipes-connectivity/openssl/openssl_1.0.1e.bb @@ -35,6 +35,7 @@ SRC_URI += file://configure-targets.patch \ file://openssl-avoid-NULL-pointer-dereference-in-dh_pub_encode.patch \ file://initial-aarch64-bits.patch \ file://find.pl \ +file://openssl-fix-des.pod-error.patch \ file://0001-Fix-for-TLS-record-tampering-bug-CVE-2013-4353.patch \ file://0001-Fix-DTLS-retransmission-from-previous-session.patch \ file://0001-Use-version-in-SSL_METHOD-not-SSL-structure.patch \ -- 1.8.1.2 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 6/7] libpam: fix multilib packaging issue for pam-plugins
From: Ming Liu ming@windriver.com
libpam might miss ABI specific dependencies for pam-plugins-*, for RPM uses
generic names to check the packages depending on it and doesn't consider the
arch, which will lead to packaging issues in mulbilib build.
pam_plugin_hook is added because the plugin packages are dynamically
generated, so we need to manually process multilib names by add baselib to
RPROVIDES/RDEPENDS as ABI specific tag.
Signed-off-by: Ming Liu ming@windriver.com
I worked with Ming Liu on this particular issue. You may wonder why
this is necessary let me attempt to explain the underlying causes.
In deb/ipk on a multilib package, the package name has specific multilib
references in it. I.e. the alternative libraries start with something
like lib32-... This was done primarily because deb/ipk do not allow two
packages with the same name (but different architectures) to be
installed at the same time. So the name has to be unique.
In RPM however, the names of the packages and matches with the
architectures and if they are not the same we can do these multilib
installs. This matches the behavior of other RPM based distributions
and in many ways the tools people are used to working with RPM. For the
most part this works fine in multilib configurations because additional
per-file dependencies are added that capture the shared library
dependencies with ABI specific information. This unfortunately fails in
a few cases where plugins are dynamically loaded via dlopen -- such as
libpam.
One possible fix is simply to follow the deb/ipk package naming, but
this causes a design advantage of rpm. When a package has a dependency
on 'bash', we really don't care what bash is installed, only that -a-
bash is installed. In the deb/ipk case, the lib32- packages would end
up with a lib32-bash dependency and you could potentially end up with
two 'bash' packages being installed.
So the fix I recommended for the issue was to add the baselib path to
the internal dependencies. Since we know that the libpam installed in
'lib' needs the modules that were compiled to also work with the 'lib'
version of libpam. While the libpam in 'lib64' need the modules to work
with the 'lib64' version of the plugins.
Existing dependencies are preserved so there is no impact in the ipk/deb
case, the RPM case is resolved as the additional dependency information
is now present for the package manager to select the package we really
want.
If anyone else has a suggestion for an alternative fix, we're interested
-- but this is the best answer we could come up with. (If any of the
above should be added to the commit message, the YP bug, or
documentation, please let me know and I'll make sure it gets added.)
Signed-off-by: Mark Hatle mark.ha...@windriver.com
[YOCTO #4532]
Signed-off-by: Hongxu Jia hongxu@windriver.com
---
meta/recipes-extended/pam/libpam_1.1.6.bb | 29 +
1 file changed, 25 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-extended/pam/libpam_1.1.6.bb
b/meta/recipes-extended/pam/libpam_1.1.6.bb
index 6ddfcf4..61aa0a1 100644
--- a/meta/recipes-extended/pam/libpam_1.1.6.bb
+++ b/meta/recipes-extended/pam/libpam_1.1.6.bb
@@ -62,9 +62,12 @@ FILES_${PN}-xtests = ${datadir}/Linux-PAM/xtests
PACKAGES_DYNAMIC += ^pam-plugin-.*
-RDEPENDS_${PN}-runtime = libpam pam-plugin-deny pam-plugin-permit
pam-plugin-warn pam-plugin-unix
-RDEPENDS_${PN}-xtests = libpam pam-plugin-access pam-plugin-debug
pam-plugin-cracklib pam-plugin-pwhistory pam-plugin-succeed-if pam-plugin-time
coreutils
-RRECOMMENDS_${PN} = libpam-runtime
+RPROVIDES_${PN} += libpam-${baselib}
+RPROVIDES_${PN}-runtime += libpam-runtime-${baselib}
+
+RDEPENDS_${PN}-runtime = libpam-${baselib} pam-plugin-deny-${baselib}
pam-plugin-permit-${baselib} pam-plugin-warn-${baselib}
pam-plugin-unix-${baselib}
+RDEPENDS_${PN}-xtests = libpam-${baselib} pam-plugin-access-${baselib}
pam-plugin-debug-${baselib} pam-plugin-cracklib-${baselib}
pam-plugin-pwhistory-${baselib} pam-plugin-succeed-if-${baselib}
pam-plugin-time-${baselib} coreutils
+RRECOMMENDS_${PN} = libpam-runtime-${baselib}
python populate_packages_prepend () {
def pam_plugin_append_file(pn, dir, file):
@@ -74,12 +77,30 @@ python populate_packages_prepend () {
nf = of + + nf
d.setVar('FILES_' + pn, nf)
+def pam_plugin_hook(file, pkg, pattern, format, basename):
+baselib = d.getVar('baselib', True)
+mlprefix = d.getVar('MLPREFIX', True) or ''
+
+rdeps = d.getVar('RDEPENDS_' + pkg, True)
+if rdeps:
+rdeps = rdeps + + mlprefix + libpam- + baselib
+else:
+rdeps = mlprefix + libpam- + baselib
+d.setVar('RDEPENDS_' + pkg, rdeps)
+
+provides = d.getVar('RPROVIDES_' + pkg, True)
+if provides:
+provides = provides + + pkg + - + baselib
+else:
+provides = pkg + - + baselib
+d.setVar('RPROVIDES_' +
[OE-core] [PATCH 5/6] Qemu:Arm:versatilepb: Add memory size checking
From: Jiang Lu lu.ji...@windriver.com
The machine can not work with memory over 256M, so add a checking
at startup. If the memory size exceed 256M, just stop emulation then
throw out warning about memory limitation.
Signed-off-by: Jiang Lu lu.ji...@windriver.com
Signed-off-by: Robert Yang liezhi.y...@windriver.com
Signed-off-by: Jeff Polk jeff.p...@windriver.com
Signed-off-by: Hongxu Jia hongxu@windriver.com
---
...-Arm-versatilepb-Add-memory-size-checking.patch | 40 ++
meta/recipes-devtools/qemu/qemu_1.7.0.bb | 3 +-
2 files changed, 42 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-devtools/qemu/files/Qemu-Arm-versatilepb-Add-memory-size-checking.patch
diff --git
a/meta/recipes-devtools/qemu/files/Qemu-Arm-versatilepb-Add-memory-size-checking.patch
b/meta/recipes-devtools/qemu/files/Qemu-Arm-versatilepb-Add-memory-size-checking.patch
new file mode 100644
index 000..3834aed
--- /dev/null
+++
b/meta/recipes-devtools/qemu/files/Qemu-Arm-versatilepb-Add-memory-size-checking.patch
@@ -0,0 +1,40 @@
+From 896fa02c24347e6e9259812cfda187b1d6ca6199 Mon Sep 17 00:00:00 2001
+From: Jiang Lu lu.ji...@windriver.com
+Date: Wed, 13 Nov 2013 10:38:08 +0800
+Subject: [PATCH] Qemu:Arm:versatilepb: Add memory size checking
+
+The machine can not work with memory over 256M, so add a checking
+at startup. If the memory size exceed 256M, just stop emulation then
+throw out warning about memory limitation.
+
+Upstream-Status: Pending
+
+Signed-off-by: Jiang Lu lu.ji...@windriver.com
+
+Updated it on 2014-01-15 for rebasing
+
+Signed-off-by: Robert Yang liezhi.y...@windriver.com
+---
+ hw/arm/versatilepb.c |6 ++
+ 1 file changed, 6 insertions(+)
+
+diff --git a/hw/arm/versatilepb.c b/hw/arm/versatilepb.c
+index b48d84c..ad2cd5a 100644
+--- a/hw/arm/versatilepb.c
b/hw/arm/versatilepb.c
+@@ -199,6 +199,12 @@ static void versatile_init(QEMUMachineInitArgs *args, int
board_id)
+ fprintf(stderr, Unable to find CPU definition\n);
+ exit(1);
+ }
++if (ram_size (256 20)) {
++fprintf(stderr,
++qemu: Too much memory for this machine: %d MB, maximum 256
MB\n,
++((unsigned int)ram_size / (1 20)));
++exit(1);
++}
+ memory_region_init_ram(ram, NULL, versatile.ram, args-ram_size);
+ vmstate_register_ram_global(ram);
+ /* ??? RAM should repeat to fill physical memory space. */
+--
+1.7.10.4
+
diff --git a/meta/recipes-devtools/qemu/qemu_1.7.0.bb
b/meta/recipes-devtools/qemu/qemu_1.7.0.bb
index be6dd51..b776ccc 100644
--- a/meta/recipes-devtools/qemu/qemu_1.7.0.bb
+++ b/meta/recipes-devtools/qemu/qemu_1.7.0.bb
@@ -4,7 +4,8 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=441c28d2cf86e15a37fa47e15a72fbac \
file://COPYING.LIB;endline=24;md5=c04def7ae38850e7d3ef548588159913
SRC_URI += file://fxrstorssefix.patch \
-file://qemu-enlarge-env-entry-size.patch
+file://qemu-enlarge-env-entry-size.patch \
+file://Qemu-Arm-versatilepb-Add-memory-size-checking.patch
SRC_URI_prepend = http://wiki.qemu.org/download/qemu-${PV}.tar.bz2;
SRC_URI[md5sum] = 32893941d40d052a5e649efcf06aca06
--
1.8.1.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/7] libpcap: add PACKAGECONFIG for libnl1
From: Hu Yadi yadi...@windriver.com
Add --with-libnl autoconfig parameter and dependency
between libpcap and libnl1.
Disable libnl1 by default to avoid libpcap build error
when libnl1 is involved.
Signed-off-by: Hu Yadi yadi...@windriver.com
Signed-off-by: Hongxu Jia hongxu@windriver.com
---
meta/recipes-connectivity/libpcap/libpcap.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-connectivity/libpcap/libpcap.inc
b/meta/recipes-connectivity/libpcap/libpcap.inc
index 3a08afe..a984e05 100644
--- a/meta/recipes-connectivity/libpcap/libpcap.inc
+++ b/meta/recipes-connectivity/libpcap/libpcap.inc
@@ -13,6 +13,7 @@ DEPENDS = flex-native bison-native libnl
PACKAGECONFIG ??= ${@base_contains('DISTRO_FEATURES', 'bluetooth',
'bluetooth', '', d)}
PACKAGECONFIG[bluetooth] = --enable-bluetooth,--disable-bluetooth,bluez4
PACKAGECONFIG[canusb] = --enable-canusb,--enable-canusb=no,libusb
+PACKAGECONFIG[libnl1] = --with-libnl,--without-libnl,libnl1,libnl1
INC_PR = r5
--
1.8.1.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 7/7] e2fsprogs: Add e2fsprogs-mke2fs and e2fsprogs-e2fsck as recommend packages
From: Yue Tao yue@windriver.com
The mke2fs and e2fsck commands are regular tools of e2fsprogs, so they
should be installed.
Signed-off-by: Yue Tao yue@windriver.com
Signed-off-by: Robert Yang liezhi.y...@windriver.com
Signed-off-by: Jeff Polk jeff.p...@windriver.com
Signed-off-by: Hongxu Jia hongxu@windriver.com
---
meta/recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bb
b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bb
index 75a58b5..3a5d6ee 100644
--- a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bb
+++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bb
@@ -55,6 +55,7 @@ do_install () {
}
RDEPENDS_e2fsprogs = e2fsprogs-badblocks
+RRECOMMENDS_e2fsprogs = e2fsprogs-mke2fs e2fsprogs-e2fsck
PACKAGES =+ e2fsprogs-e2fsck e2fsprogs-mke2fs e2fsprogs-tune2fs
e2fsprogs-badblocks
PACKAGES =+ libcomerr libss libe2p libext2fs
--
1.8.1.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 5/7] lttng-ust: add python to lttng-ust's RDEPENDS
| Note: adding Smart RPM DB channel
|
| Note: to be installed: run-postinsts@x86_64 kernel-modules@qemux86_64
packagegroup-core-boot@qemux86_64 lttng-ust@x86_64
| Loading cache...
| Updating cache...
[100%]
|
| Computing transaction...error: Can't install lttng-ust-2:2.3.0-r0.0@x86_64:
no package provides /usr/bin/python
|
| Saving cache...
|
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_rootfs (log file is located at
tmp/work/qemux86_64-wrs-linux/wrlinux-image-glibc-small/1.0-r1/temp/do_rootfs/log.do_rootfs.13619)
Signed-off-by: Hongxu Jia hongxu@windriver.com
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
meta/recipes-kernel/lttng/lttng-ust_2.3.1.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-kernel/lttng/lttng-ust_2.3.1.bb
b/meta/recipes-kernel/lttng/lttng-ust_2.3.1.bb
index 5e2b04c..44e3e2b 100644
--- a/meta/recipes-kernel/lttng/lttng-ust_2.3.1.bb
+++ b/meta/recipes-kernel/lttng/lttng-ust_2.3.1.bb
@@ -11,6 +11,7 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=c963eb366b781252b0bf0fdf1624d9e9 \
inherit autotools lib_package
DEPENDS = liburcu util-linux
+RDEPENDS_${PN} = python
# For backwards compatibility after rename
RPROVIDES_${PN} = lttng2-ust
--
1.8.1.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/4] nss-3.15.1: fix CVE-2013-5605
From: yanjun.zhu yanjun@windriver.com
Mozilla Network Security Services (NSS) 3.14 before 3.14.5 and
3.15 before 3.15.3 allows remote attackers to cause a denial
of service or possibly have unspecified other impact via
invalid handshake packets.
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-5605
Signed-off-by: yanjun.zhu yanjun@windriver.com
Signed-off-by: Hongxu Jia hongxu@windriver.com
---
.../nss/files/nss-3.15.1-fix-CVE-2013-5605.patch | 18 ++
meta/recipes-support/nss/nss.inc | 1 +
2 files changed, 19 insertions(+)
create mode 100644
meta/recipes-support/nss/files/nss-3.15.1-fix-CVE-2013-5605.patch
diff --git a/meta/recipes-support/nss/files/nss-3.15.1-fix-CVE-2013-5605.patch
b/meta/recipes-support/nss/files/nss-3.15.1-fix-CVE-2013-5605.patch
new file mode 100644
index 000..7203d02
--- /dev/null
+++ b/meta/recipes-support/nss/files/nss-3.15.1-fix-CVE-2013-5605.patch
@@ -0,0 +1,18 @@
+signed-off-by: Ryan Sleevi ryan.sle...@gmail.com
+Upstream-Status: Backport
+reference:https://hg.mozilla.org/projects/nss/rev/e79a09364b5e
+
+--- a/nss/lib/ssl/ssl3con.c
b/nss/lib/ssl/ssl3con.c
+@@ -781,6 +781,11 @@ static SECStatus
+ Null_Cipher(void *ctx, unsigned char *output, int *outputLen, int
maxOutputLen,
+ const unsigned char *input, int inputLen)
+ {
++if (inputLen maxOutputLen) {
++*outputLen = 0; /* Match PK11_CipherOp in setting outputLen */
++PORT_SetError(SEC_ERROR_OUTPUT_LEN);
++return SECFailure;
++}
+ *outputLen = inputLen;
+ if (input != output)
+ PORT_Memcpy(output, input, inputLen);
diff --git a/meta/recipes-support/nss/nss.inc b/meta/recipes-support/nss/nss.inc
index 6364562..404decc 100644
--- a/meta/recipes-support/nss/nss.inc
+++ b/meta/recipes-support/nss/nss.inc
@@ -17,6 +17,7 @@ SRC_URI = \
file://nss-no-rpath-for-cross-compiling.patch \
file://nss-fix-incorrect-shebang-of-perl.patch \
file://nss-3.15.1-fix-CVE-2013-1741.patch \
+file://nss-3.15.1-fix-CVE-2013-5605.patch \
SRC_URI_append_class-target = \
file://nss.pc.in \
--
1.8.1.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/5] packagegroup-self-hosted: Use packagegroup-core-buildessential
From: Mark Hatle mark.ha...@windriver.com Instead of manually specifying build dependencies, use the packagegroup-core-buildessential. This ensures there is only one place that needs to be modified when toolchain items and dependencies change. Signed-off-by: Mark Hatle mark.ha...@windriver.com Signed-off-by: Jeff Polk jeff.p...@windriver.com Signed-off-by: Hongxu Jia hongxu@windriver.com --- meta/recipes-core/packagegroups/packagegroup-self-hosted.bb | 12 +--- 1 file changed, 1 insertion(+), 11 deletions(-) diff --git a/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb b/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb index 5581d8e..fe49fb4 100644 --- a/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb +++ b/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb @@ -66,33 +66,23 @@ RRECOMMENDS_packagegroup-self-hosted-host-tools = \ # eglibc-utils: for rpcgen RDEPENDS_packagegroup-self-hosted-sdk = \ -autoconf \ -automake \ -binutils \ ccache \ coreutils \ -cpp \ distcc \ eglibc-utils \ eglibc-gconv-ibm850 \ file \ findutils \ -g++ \ -gcc \ intltool \ ldd \ less \ libssp \ libssp-dev \ libssp-staticdev \ -libstdc++ \ -libstdc++-dev \ -libtool \ -make \ mktemp \ +packagegroup-core-buildessential \ perl-module-re \ perl-module-text-wrap \ -pkgconfig \ quilt \ sed \ -- 1.8.1.2 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/4] libarchive: fix CVE-2013-0211
From: Baogen Shang baogen.sh...@windriver.com
CVE description:
Integer signedness error in the archive_write_zip_data function in
archive_write_set_format_zip.c in libarchive 3.1.2 and earlier, when running
on 64-bit machines, allows context-dependent attackers to cause a denial of
service (crash) via unspecified vectors, which triggers an improper conversion
between unsigned and signed types, leading to a buffer overflow.
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0211
Signed-off-by: Baogen Shang baogen.sh...@windriver.com
Signed-off-by: Jeff Polk jeff.p...@windriver.com
Signed-off-by: Hongxu Jia hongxu@windriver.com
---
.../libarchive/libarchive-CVE-2013-0211.patch | 38 ++
.../libarchive/libarchive_3.1.2.bb | 1 +
2 files changed, 39 insertions(+)
create mode 100644
meta/recipes-extended/libarchive/libarchive/libarchive-CVE-2013-0211.patch
diff --git
a/meta/recipes-extended/libarchive/libarchive/libarchive-CVE-2013-0211.patch
b/meta/recipes-extended/libarchive/libarchive/libarchive-CVE-2013-0211.patch
new file mode 100644
index 000..126f80e
--- /dev/null
+++ b/meta/recipes-extended/libarchive/libarchive/libarchive-CVE-2013-0211.patch
@@ -0,0 +1,38 @@
+From 2f55d6bd308ea61975558c2469ae349dba297e89 Mon Sep 17 00:00:00 2001
+From: Robert Yang liezhi.y...@windriver.com
+Date: Sat, 22 Feb 2014 14:35:59 +0800
+Subject: [PATCH] Fix CVE-2013-0211
+
+This patch comes
from:https://github.com/libarchive/libarchive/commit/22531545514043e04633e1c015c7540b9de9dbe4
+
+Upstream-Status: Backport
+
+Signed-off-by: Baogen shang baogen.sh...@windriver.com
+
+Update the patch because of uprev on 20140222
+
+Signed-off-by: Robert Yang liezhi.y...@windriver.com
+---
+ libarchive/archive_write.c | 4
+ 1 file changed, 4 insertions(+)
+
+diff --git a/libarchive/archive_write.c b/libarchive/archive_write.c
+index a3d1a33..a323588 100644
+--- a/libarchive/archive_write.c
b/libarchive/archive_write.c
+@@ -671,8 +671,12 @@ static ssize_t
+ _archive_write_data(struct archive *_a, const void *buff, size_t s)
+ {
+ struct archive_write *a = (struct archive_write *)_a;
++ const size_t max_write = INT_MAX;
+ archive_check_magic(a-archive, ARCHIVE_WRITE_MAGIC,
+ ARCHIVE_STATE_DATA, archive_write_data);
++ /* In particular, this catches attempts to pass negative values. */
++ if (s max_write)
++ s = max_write;
+ archive_clear_error(a-archive);
+ return ((a-format_write_data)(a, buff, s));
+ }
+--
+1.8.2.1
+
diff --git a/meta/recipes-extended/libarchive/libarchive_3.1.2.bb
b/meta/recipes-extended/libarchive/libarchive_3.1.2.bb
index 2556dc8..d5599e0 100644
--- a/meta/recipes-extended/libarchive/libarchive_3.1.2.bb
+++ b/meta/recipes-extended/libarchive/libarchive_3.1.2.bb
@@ -26,6 +26,7 @@ PACKAGECONFIG[libxml2] = --with-xml2,--without-xml2,libxml2,
PACKAGECONFIG[expat] = --with-expat,--without-expat,expat,
SRC_URI = http://libarchive.org/downloads/libarchive-${PV}.tar.gz \
+ file://libarchive-CVE-2013-0211.patch \
SRC_URI[md5sum] = efad5a503f66329bb9d2f4308b5de98a
--
1.8.1.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/4] nss-3.15.1: fix CVE-2013-1741
From: yanjun.zhu yanjun@windriver.com
Integer overflow in Mozilla Network Security Services (NSS)
3.15 before 3.15.3 allows remote attackers to cause a denial
of service or possibly have unspecified other impact via a
large size value.
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-1741
Signed-off-by: yanjun.zhu yanjun@windriver.com
Signed-off-by: Hongxu Jia hongxu@windriver.com
---
.../nss/files/nss-3.15.1-fix-CVE-2013-1741.patch | 92 ++
meta/recipes-support/nss/nss.inc | 1 +
2 files changed, 93 insertions(+)
create mode 100644
meta/recipes-support/nss/files/nss-3.15.1-fix-CVE-2013-1741.patch
diff --git a/meta/recipes-support/nss/files/nss-3.15.1-fix-CVE-2013-1741.patch
b/meta/recipes-support/nss/files/nss-3.15.1-fix-CVE-2013-1741.patch
new file mode 100644
index 000..21da0c0
--- /dev/null
+++ b/meta/recipes-support/nss/files/nss-3.15.1-fix-CVE-2013-1741.patch
@@ -0,0 +1,92 @@
+Upstream-Status: backport
+yanjun.zhu yanjun@windriver.com
+--- a/nss/lib/util/secport.c
b/nss/lib/util/secport.c
+@@ -69,13 +69,22 @@ PORTCharConversionFunc ucs4Utf8ConvertFu
+ PORTCharConversionFunc ucs2Utf8ConvertFunc;
+ PORTCharConversionWSwapFunc ucs2AsciiConvertFunc;
+
++/* NSPR memory allocation functions (PR_Malloc, PR_Calloc, and PR_Realloc)
++ * use the PRUint32 type for the size parameter. Before we pass a size_t or
++ * unsigned long size to these functions, we need to ensure it is = half of
++ * the maximum PRUint32 value to avoid truncation and catch a negative size.
++ */
++#define MAX_SIZE (PR_UINT32_MAX 1)
++
+ void *
+ PORT_Alloc(size_t bytes)
+ {
+-void *rv;
++void *rv = NULL;
+
+-/* Always allocate a non-zero amount of bytes */
+-rv = (void *)PR_Malloc(bytes ? bytes : 1);
++if (bytes = MAX_SIZE) {
++ /* Always allocate a non-zero amount of bytes */
++ rv = PR_Malloc(bytes ? bytes : 1);
++}
+ if (!rv) {
+ ++port_allocFailures;
+ PORT_SetError(SEC_ERROR_NO_MEMORY);
+@@ -86,9 +95,11 @@ PORT_Alloc(size_t bytes)
+ void *
+ PORT_Realloc(void *oldptr, size_t bytes)
+ {
+-void *rv;
++void *rv = NULL;
+
+-rv = (void *)PR_Realloc(oldptr, bytes);
++if (bytes = MAX_SIZE) {
++ rv = PR_Realloc(oldptr, bytes);
++}
+ if (!rv) {
+ ++port_allocFailures;
+ PORT_SetError(SEC_ERROR_NO_MEMORY);
+@@ -99,10 +110,12 @@ PORT_Realloc(void *oldptr, size_t bytes)
+ void *
+ PORT_ZAlloc(size_t bytes)
+ {
+-void *rv;
++void *rv = NULL;
+
+-/* Always allocate a non-zero amount of bytes */
+-rv = (void *)PR_Calloc(1, bytes ? bytes : 1);
++if (bytes = MAX_SIZE) {
++ /* Always allocate a non-zero amount of bytes */
++ rv = PR_Calloc(1, bytes ? bytes : 1);
++}
+ if (!rv) {
+ ++port_allocFailures;
+ PORT_SetError(SEC_ERROR_NO_MEMORY);
+@@ -209,6 +222,10 @@ PORT_NewArena(unsigned long chunksize)
+ {
+ PORTArenaPool *pool;
+
++if (chunksize MAX_SIZE) {
++ PORT_SetError(SEC_ERROR_NO_MEMORY);
++ return NULL;
++}
+ pool = PORT_ZNew(PORTArenaPool);
+ if (!pool) {
+ return NULL;
+@@ -224,8 +241,6 @@ PORT_NewArena(unsigned long chunksize)
+ return(pool-arena);
+ }
+
+-#define MAX_SIZE 0x7fffUL
+-
+ void *
+ PORT_ArenaAlloc(PLArenaPool *arena, size_t size)
+ {
+@@ -330,6 +345,11 @@ PORT_ArenaGrow(PLArenaPool *arena, void
+ PORTArenaPool *pool = (PORTArenaPool *)arena;
+ PORT_Assert(newsize = oldsize);
+
++if (newsize MAX_SIZE) {
++ PORT_SetError(SEC_ERROR_NO_MEMORY);
++ return NULL;
++}
++
+ if (ARENAPOOL_MAGIC == pool-magic ) {
+ PZ_Lock(pool-lock);
+ /* Do we do a THREADMARK check here? */
diff --git a/meta/recipes-support/nss/nss.inc b/meta/recipes-support/nss/nss.inc
index a6aeed8..6364562 100644
--- a/meta/recipes-support/nss/nss.inc
+++ b/meta/recipes-support/nss/nss.inc
@@ -16,6 +16,7 @@ SRC_URI = \
file://nss-fix-support-cross-compiling.patch \
file://nss-no-rpath-for-cross-compiling.patch \
file://nss-fix-incorrect-shebang-of-perl.patch \
+file://nss-3.15.1-fix-CVE-2013-1741.patch \
SRC_URI_append_class-target = \
file://nss.pc.in \
--
1.8.1.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/5] packagegroups: Remove toolchain *-symlinks packages
From: Mark Hatle mark.ha...@windriver.com We are no longer producing the *-symlinks packages, so remove the dependencies to those items. Signed-off-by: Mark Hatle mark.ha...@windriver.com Signed-off-by: Jeff Polk jeff.p...@windriver.com Signed-off-by: Hongxu Jia hongxu@windriver.com --- meta/recipes-core/packagegroups/packagegroup-core-buildessential.bb | 4 meta/recipes-core/packagegroups/packagegroup-self-hosted.bb | 4 2 files changed, 8 deletions(-) diff --git a/meta/recipes-core/packagegroups/packagegroup-core-buildessential.bb b/meta/recipes-core/packagegroups/packagegroup-core-buildessential.bb index 74ed247..e21f8c1 100644 --- a/meta/recipes-core/packagegroups/packagegroup-core-buildessential.bb +++ b/meta/recipes-core/packagegroups/packagegroup-core-buildessential.bb @@ -12,13 +12,9 @@ RDEPENDS_packagegroup-core-buildessential = \ autoconf \ automake \ binutils \ -binutils-symlinks \ cpp \ -cpp-symlinks \ gcc \ -gcc-symlinks \ g++ \ -g++-symlinks \ gettext \ make \ libstdc++ \ diff --git a/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb b/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb index 8e3b917..5581d8e 100644 --- a/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb +++ b/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb @@ -69,20 +69,16 @@ RDEPENDS_packagegroup-self-hosted-sdk = \ autoconf \ automake \ binutils \ -binutils-symlinks \ ccache \ coreutils \ cpp \ -cpp-symlinks \ distcc \ eglibc-utils \ eglibc-gconv-ibm850 \ file \ findutils \ g++ \ -g++-symlinks \ gcc \ -gcc-symlinks \ intltool \ ldd \ less \ -- 1.8.1.2 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 5/5] libc-common.bbclass: rename ALL the packages
From: Peter Seebach peter.seeb...@windriver.com
The DEBIAN_NAMES feature renames some of the libc packages to
libc6* names --but only some. A previous patch added the -dbg
package. However, this doesn't cover other packages (such as
the -doc package), and it didn't take multilibs into account.
Signed-off-by: Peter Seebach peter.seeb...@windriver.com
Signed-off-by: Jeff Polk jeff.p...@windriver.com
Signed-off-by: Mark Hatle mark.ha...@windriver.com
Signed-off-by: Hongxu Jia hongxu@windriver.com
---
meta/classes/libc-common.bbclass | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/meta/classes/libc-common.bbclass b/meta/classes/libc-common.bbclass
index daf499d..53bf467 100644
--- a/meta/classes/libc-common.bbclass
+++ b/meta/classes/libc-common.bbclass
@@ -25,12 +25,19 @@ def get_libc_fpu_setting(bb, d):
python populate_packages_prepend () {
if d.getVar('DEBIAN_NAMES', True):
+pkgs = d.getVar('PACKAGES', True).split()
bpn = d.getVar('BPN', True)
-d.setVar('PKG_'+bpn, 'libc6')
-d.setVar('PKG_'+bpn+'-dev', 'libc6-dev')
-d.setVar('PKG_'+bpn+'-dbg', 'libc6-dbg')
+prefix = d.getVar('MLPREFIX', True) or
+# Set the base package...
+d.setVar('PKG_' + prefix + bpn, prefix + 'libc6')
+initial = prefix + bpn + '-'
+for p in pkgs:
+# And all the subpackages.
+if p.startswith(initial):
+renamed = p.replace(bpn, 'libc6', 1)
+d.setVar('PKG_' + p, renamed)
# For backward compatibility with old -dbg package
-d.appendVar('RPROVIDES_' + bpn + '-dbg', ' libc-dbg')
-d.appendVar('RCONFLICTS_' + bpn + '-dbg', ' libc-dbg')
-d.appendVar('RREPLACES_' + bpn + '-dbg', ' libc-dbg')
+d.appendVar('RPROVIDES_' + initial + 'dbg', ' ' + prefix + 'libc-dbg')
+d.appendVar('RCONFLICTS_' + initial + 'dbg', ' ' + prefix + 'libc-dbg')
+d.appendVar('RREPLACES_' + initial + 'dbg', ' ' + prefix + 'libc-dbg')
}
--
1.8.1.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/5] kernel.bbclass: handles symbolic KERNEL_OUTPUT in bundle_initramfs task
From: Ming Liu ming@windriver.com
In many cases, KERNEL_OUTPUT is a symbolic link to the real bootable image,
but in bundle_initramfs task, it's not considered so that the KERNEL_OUTPUT
is being renamed/restored as a regular file, this leads it finally point to
a incorrect target, or even worse, break the bundle_initramfs task for
KERNEL_OUTPUT is not going to be regenerated in case it is a symbolic link
to vmlinux.
Signed-off-by: Ming Liu ming@windriver.com
Signed-off-by: Robert Yang liezhi.y...@windriver.com
Signed-off-by: Jeff Polk jeff.p...@windriver.com
Signed-off-by: Hongxu Jia hongxu@windriver.com
---
meta/classes/kernel.bbclass | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 19b159b..b5e5a85 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -128,13 +128,28 @@ do_bundle_initramfs () {
if [ ! -z ${INITRAMFS_IMAGE} -a x${INITRAMFS_IMAGE_BUNDLE} = x1 ];
then
echo Creating a kernel image with a bundled initramfs...
copy_initramfs
- if [ -e ${KERNEL_OUTPUT} ] ; then
+ # Backuping kernel image relies on its type(regular file or
symbolic link)
+ linkpath=
+ realpath=
+ if [ -h ${KERNEL_OUTPUT} ] ; then
+ linkpath=`readlink -n ${KERNEL_OUTPUT}`
+ realpath=`readlink -fn ${KERNEL_OUTPUT}`
+ mv -f $realpath $realpath.bak
+ elif [ -f ${KERNEL_OUTPUT} ]; then
mv -f ${KERNEL_OUTPUT} ${KERNEL_OUTPUT}.bak
fi
use_alternate_initrd=CONFIG_INITRAMFS_SOURCE=${B}/usr/${INITRAMFS_IMAGE}-${MACHINE}.cpio
kernel_do_compile
- mv -f ${KERNEL_OUTPUT} ${KERNEL_OUTPUT}.initramfs
- mv -f ${KERNEL_OUTPUT}.bak ${KERNEL_OUTPUT}
+ # Restoring kernel image
+ if [ -n $realpath ]; then
+ mv -f $realpath $realpath.initramfs
+ mv -f $realpath.bak $realpath
+ cd ${B}/$(dirname ${KERNEL_OUTPUT})
+ ln -sf $linkpath.initramfs
+ else
+ mv -f ${KERNEL_OUTPUT} ${KERNEL_OUTPUT}.initramfs
+ mv -f ${KERNEL_OUTPUT}.bak ${KERNEL_OUTPUT}
+ fi
# Update install area
echo There is kernel image bundled with initramfs:
${B}/${KERNEL_OUTPUT}.initramfs
install -m 0644 ${B}/${KERNEL_OUTPUT}.initramfs
${D}/boot/${KERNEL_IMAGETYPE}-initramfs-${MACHINE}.bin
--
1.8.1.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/5][Part IV] wr-misc patches
WindRiver patches was sent for YP compliance. There are total 22 patches, and separate them into 4 parts, each part is individual which means there is no dependence between them. //Hongxu The following changes since commit 8c3eb5ee4582b6f6d489549290937657f37fc19e: packagegroup-toolset-native: Update after ocf-linux - cryptodev-linux change (2014-03-27 19:53:30 +) are available in the git repository at: git://git.pokylinux.org/poky-contrib hongxu/wr-misc-patches-4 http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=hongxu/wr-misc-patches-4 Konrad Scherer (1): syslinux.bbclass: Enable additional kernel parameters for syslinux Mark Hatle (2): packagegroups: Remove toolchain *-symlinks packages packagegroup-self-hosted: Use packagegroup-core-buildessential Ming Liu (1): kernel.bbclass: handles symbolic KERNEL_OUTPUT in bundle_initramfs task Peter Seebach (1): libc-common.bbclass: rename ALL the packages meta/classes/kernel.bbclass | 21 ++--- meta/classes/libc-common.bbclass| 19 +-- meta/classes/syslinux.bbclass | 5 + .../packagegroup-core-buildessential.bb | 4 .../packagegroups/packagegroup-self-hosted.bb | 16 +--- 5 files changed, 37 insertions(+), 28 deletions(-) -- 1.8.1.2 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/4] libtiff: fix CVE-2013-4244
From: Baogen Shang baogen.sh...@windriver.com
cve description:
The LZW decompressor in the gif2tiff tool in libtiff 4.0.3 and earlier
allows context-dependent attackers to cause a denial of service
(out-of-bounds write and crash) or possibly execute arbitrary code via
a crafted GIF image.
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-4244
Signed-off-by: Baogen Shang baogen.sh...@windriver.com
Signed-off-by: Hongxu Jia hongxu@windriver.com
---
.../libtiff/files/libtiff-CVE-2013-4244.patch | 19 +++
meta/recipes-multimedia/libtiff/tiff_4.0.3.bb | 3 ++-
2 files changed, 21 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-multimedia/libtiff/files/libtiff-CVE-2013-4244.patch
diff --git a/meta/recipes-multimedia/libtiff/files/libtiff-CVE-2013-4244.patch
b/meta/recipes-multimedia/libtiff/files/libtiff-CVE-2013-4244.patch
new file mode 100644
index 000..1a66830
--- /dev/null
+++ b/meta/recipes-multimedia/libtiff/files/libtiff-CVE-2013-4244.patch
@@ -0,0 +1,19 @@
+This patch comes from:
https://github.com/vadz/libtiff/commit/ce6841d9e41d621ba23cf18b190ee6a23b2cc833
+
+Upstream-Status: Backport
+
+Signed-off-by: Baogen shang baogen.sh...@windriver.com
+--- a/tools/gif2tiff.c 2013-12-17 16:46:02.160814995 +0800
b/tools/gif2tiff.c 2013-12-17 16:52:25.140814949 +0800
+@@ -406,6 +406,11 @@
+ return 0;
+ }
+ if (oldcode == -1) {
++if (code = clear) {
++fprintf(stderr, bad input: code=%d is larger than clear=%d\n,code,
clear);
++return 0;
++ }
++
+ *(*fill)++ = suffix[code];
+ firstchar = oldcode = code;
+ return 1;
diff --git a/meta/recipes-multimedia/libtiff/tiff_4.0.3.bb
b/meta/recipes-multimedia/libtiff/tiff_4.0.3.bb
index 9cb8edf..fb9e0bf 100644
--- a/meta/recipes-multimedia/libtiff/tiff_4.0.3.bb
+++ b/meta/recipes-multimedia/libtiff/tiff_4.0.3.bb
@@ -7,7 +7,8 @@ SRC_URI =
ftp://ftp.remotesensing.org/pub/libtiff/tiff-${PV}.tar.gz \
file://libtool2.patch \
file://libtiff-CVE-2013-1960.patch \
file://libtiff-CVE-2013-4232.patch \
- file://libtiff-CVE-2013-4243.patch
+ file://libtiff-CVE-2013-4243.patch \
+ file://libtiff-CVE-2013-4244.patch
SRC_URI[md5sum] = 051c1068e6a0627f461948c365290410
SRC_URI[sha256sum] =
ea1aebe282319537fb2d4d7805f478dd4e0e05c33d0928baba76a7c963684872
--
1.8.1.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/4][Part III] wr-misc patches
WindRiver patches was sent for YP compliance. There are total 22 patches, and separate them into 4 parts, each part is individual which means there is no dependence between them. //Hongxu The following changes since commit 8c3eb5ee4582b6f6d489549290937657f37fc19e: packagegroup-toolset-native: Update after ocf-linux - cryptodev-linux change (2014-03-27 19:53:30 +) are available in the git repository at: git://git.pokylinux.org/poky-contrib hongxu/wr-misc-patches-3 http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=hongxu/wr-misc-patches-3 Baogen Shang (2): libarchive: fix CVE-2013-0211 libtiff: fix CVE-2013-4244 yanjun.zhu (2): nss-3.15.1: fix CVE-2013-1741 nss-3.15.1: fix CVE-2013-5605 .../libarchive/libarchive-CVE-2013-0211.patch | 38 + .../libarchive/libarchive_3.1.2.bb | 1 + .../libtiff/files/libtiff-CVE-2013-4244.patch | 19 + meta/recipes-multimedia/libtiff/tiff_4.0.3.bb | 3 +- .../nss/files/nss-3.15.1-fix-CVE-2013-1741.patch | 92 ++ .../nss/files/nss-3.15.1-fix-CVE-2013-5605.patch | 18 + meta/recipes-support/nss/nss.inc | 2 + 7 files changed, 172 insertions(+), 1 deletion(-) create mode 100644 meta/recipes-extended/libarchive/libarchive/libarchive-CVE-2013-0211.patch create mode 100644 meta/recipes-multimedia/libtiff/files/libtiff-CVE-2013-4244.patch create mode 100644 meta/recipes-support/nss/files/nss-3.15.1-fix-CVE-2013-1741.patch create mode 100644 meta/recipes-support/nss/files/nss-3.15.1-fix-CVE-2013-5605.patch -- 1.8.1.2 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/5] syslinux.bbclass: Enable additional kernel parameters for syslinux
From: Konrad Scherer konrad.sche...@windriver.com
Add additional parameter 'SYSLINUX_KERNEL_ARGS' in order to allow
for specific kernel parameters to be set when using syslinux.
The extra kernel parameters are added to btype[1] and then written out
as part of the APPEND field.
Signed-off-by: Konrad Scherer konrad.sche...@windriver.com
Signed-off-by: Mark Hatle mark.ha...@windriver.com
Signed-off-by: Hongxu Jia hongxu@windriver.com
---
meta/classes/syslinux.bbclass | 5 +
1 file changed, 5 insertions(+)
diff --git a/meta/classes/syslinux.bbclass b/meta/classes/syslinux.bbclass
index 62d4b7a..8964d3f 100644
--- a/meta/classes/syslinux.bbclass
+++ b/meta/classes/syslinux.bbclass
@@ -15,6 +15,7 @@
# ${SYSLINUX_DEFAULT_CONSOLE} - set to console=ttyX to change kernel boot
default console
# ${SYSLINUX_SERIAL} - Set an alternate serial port or turn off serial with
empty string
# ${SYSLINUX_SERIAL_TTY} - Set alternate console=tty... kernel boot argument
+# ${SYSLINUX_KERNEL_ARGS} - Add additional kernel arguments
do_bootimg[depends] += syslinux:do_populate_sysroot \
syslinux-native:do_populate_sysroot
@@ -162,6 +163,10 @@ python build_syslinux_cfg () {
for btype in btypes:
cfgfile.write('LABEL %s%s\nKERNEL /vmlinuz\n' % (btype[0], label))
+exargs = d.getVar('SYSLINUX_KERNEL_ARGS', True)
+if exargs:
+btype[1] += + exargs
+
append = localdata.getVar('APPEND', True)
initrd = localdata.getVar('INITRD', True)
--
1.8.1.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 10/13] linux-yocto/3.14: introduce versioned recipes
On Thu, 2014-03-27 at 14:25 -0400, Bruce Ashfield wrote:
The release kernel for Yocto 1.5 is the 3.14 kernel, so we introduce
the versioned recipes here.
Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb | 21
meta/recipes-kernel/linux/linux-yocto_3.14.bb | 37
++
2 files changed, 58 insertions(+)
create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
create mode 100644 meta/recipes-kernel/linux/linux-yocto_3.14.bb
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
b/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
new file mode 100644
index ..8faa9584acf0
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
@@ -0,0 +1,21 @@
+require recipes-kernel/linux/linux-yocto.inc
+
+KBRANCH = standard/tiny/base
+LINUX_KERNEL_TYPE = tiny
+KCONFIG_MODE = --allnoconfig
+
+LINUX_VERSION ?= 3.14-rc8
+
+KMETA = meta
+
+SRCREV_machine ?= fecc3fd7d31bd93766ff4f0431fecdbbfa4c3a7c
+SRCREV_meta ?= 3689f99f4d2a051e8d3ff72345a67d4d04a88020
+
+PV = ${LINUX_VERSION}+git${SRCPV}
I'm afraid we can't do this in such a simple way. The big issue is that
according to our version comparison functions (in bitbake and in the
package managers), 3.14-rc8 3.14. This will then break updates
from package feeds.
The traditional way we've worked around this in times gone by is the
rather ugly:
PV = 3.13+3.14-rc8+git${SRCPV}
since in this case 3.14 3.13+3.14-rc8
The better way to handle this would be 3.14~rc8 however not all of our
package backends have support for ~ at this point so we can't do that.
There is a long standing bug open about this.
The same issue also applies to the libc-headers recipe.
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/3] Replace ocf-linux with cryptodev-linux
On Wed, 2014-03-26 at 18:15 +0800, Kai Kang wrote: Replace ocf-linux with cryptodev-linux because linux-yocto use cryptodev-linux to implement /dev/crypto. Build for qemux86 and qemuarm. Test on qemux86. This did break the build: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=8c3eb5ee4582b6f6d489549290937657f37fc19e however I've fixed it. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] coreutils: fix search paths for libstdbuf.so
Hello,
I set ---libexecdir=${libdir} in bb file.
I submit new patch for this issue .
Please review it .
Thanks,
chunrong
-Original Message-
From: Khem Raj [mailto:raj.k...@gmail.com]
Sent: Wednesday, March 26, 2014 1:24 AM
To: Richard Purdie
Cc: Guo Chunrong-B40290; Patches and discussions about the oe-core layer
Subject: Re: [OE-core] [PATCH] coreutils: fix search paths for libstdbuf.so
On Tue, Mar 25, 2014 at 3:55 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
Khem added this back in 2011:
http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/meta/recipes-
core/coreutils?h=rpurdie/t2id=eee0b5aadba34130080df8aebc7e8dd57c7d5cc
b
Khem: Any idea what this was for?
coreutils changed this back in 8.13 timeframe to appease automake which stopped
accepting pkglib_PROGRAMS and it was moved to pkglibexec_PROGRAMS list since
this library is special where you do not link to it directly but preload it to
divert stdio buffers coreutils devs did not classifiy it to be installed in
libdir but in libexecdir instead and if you look stdbuf program which sets up
this preloading is hardwired to look into libexecdir and modifies the preload
search path to include libexecdir in search path, so if we specify
--libexecdir=.. to configure and make sure that this .so lands in same
directory on target then we are ok. did we change global libexecdir ?
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] package_manager.py: leave the __db.00* files in place
Do not delete the __db.00* files in the PackageManager class. Leave this
operation up to the client classes. One side effect of this deletion was
the following message appearing in the output of the next rpm command
executed:
rpmdb: BDB1540 configured environment flags incompatible with existing
environment
We might also gain some time here by not deleting/creating those files
very often.
[YOCTO #6049]
Signed-off-by: Laurentiu Palcu laurentiu.pa...@intel.com
---
meta/lib/oe/package_manager.py |8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/meta/lib/oe/package_manager.py b/meta/lib/oe/package_manager.py
index 764ab72..a8360fe 100644
--- a/meta/lib/oe/package_manager.py
+++ b/meta/lib/oe/package_manager.py
@@ -299,9 +299,6 @@ class RpmPkgsList(PkgsList):
# bb.note(cmd)
tmp_output = subprocess.check_output(cmd,
stderr=subprocess.STDOUT, shell=True).strip()
-rpm_db_locks = glob.glob('%s/var/lib/rpm/__db.*' % self.rootfs_dir)
-for f in rpm_db_locks:
-bb.utils.remove(f, True)
except subprocess.CalledProcessError as e:
bb.fatal(Cannot get the installed packages list. Command '%s'
returned %d:\n%s % (cmd, e.returncode, e.output))
@@ -1101,7 +1098,6 @@ class RpmPM(PackageManager):
output = subprocess.check_output(cmd, stderr=subprocess.STDOUT,
shell=True).strip()
bb.note(output)
os.chmod(saved_dir, 0755)
-self._unlock_rpm_db()
except subprocess.CalledProcessError as e:
bb.fatal(Invoke save_rpmpostinst failed. Command '%s'
returned %d:\n%s % (cmd, e.returncode, e.output))
@@ -1117,14 +1113,12 @@ class RpmPM(PackageManager):
self._invoke_smart('flag --set ignore-recommends %s' % i)
self._invoke_smart('channel --add rpmsys type=rpm-sys -y')
-self._unlock_rpm_db()
-
'''
The rpm db lock files were produced after invoking rpm to query on
build system, and they caused the rpm on target didn't work, so we
need to unlock the rpm db by removing the lock files.
'''
-def _unlock_rpm_db(self):
+def unlock_rpm_db(self):
# Remove rpm db lock files
rpm_db_locks = glob.glob('%s/var/lib/rpm/__db.*' % self.target_rootfs)
for f in rpm_db_locks:
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/2] Don't fool around with rpm __db.00* files
We were deleting/creating those files too many times during the rootfs creation process. That led to various rpmdb related issues. Instead, remove those files at the end of the rootfs creation process which seems the most sane thing to do. laurentiu The following changes since commit 8c3eb5ee4582b6f6d489549290937657f37fc19e: packagegroup-toolset-native: Update after ocf-linux - cryptodev-linux change (2014-03-27 19:53:30 +) are available in the git repository at: git://git.yoctoproject.org/poky-contrib lpalcu/b6049_do_rootfs_crash http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=lpalcu/b6049_do_rootfs_crash Laurentiu Palcu (2): package_manager.py: leave the __db.00* files in place rootfs.py: add new cleanup method meta/lib/oe/package_manager.py |8 +--- meta/lib/oe/rootfs.py | 25 + 2 files changed, 26 insertions(+), 7 deletions(-) -- 1.7.9.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] rootfs.py: add new cleanup method
This commit adds a new _cleanup() internal method that will be called at
the end of rootfs creation, so that each backend can delete various
files that were probably generated during rootfs postprocess execution,
etc.
[YOCTO #6049]
Signed-off-by: Laurentiu Palcu laurentiu.pa...@intel.com
---
meta/lib/oe/rootfs.py | 25 +
1 file changed, 25 insertions(+)
diff --git a/meta/lib/oe/rootfs.py b/meta/lib/oe/rootfs.py
index 0e6c8bc..3eac3c9 100644
--- a/meta/lib/oe/rootfs.py
+++ b/meta/lib/oe/rootfs.py
@@ -50,6 +50,15 @@ class Rootfs(object):
def _handle_intercept_failure(self, failed_script):
pass
+
+The _cleanup() method should be used to clean-up stuff that we don't really
+want to end up on target. For example, in the case of RPM, the DB locks.
+The method is called, once, at the end of create() method.
+
+@abstractmethod
+def _cleanup(self):
+pass
+
def _exec_shell_cmd(self, cmd):
fakerootcmd = self.d.getVar('FAKEROOT', True)
if fakerootcmd is not None:
@@ -117,6 +126,8 @@ class Rootfs(object):
self._generate_kernel_module_deps()
+self._cleanup()
+
def _uninstall_uneeded(self):
if base_contains(IMAGE_FEATURES, package-management,
True, False, self.d):
@@ -358,6 +369,13 @@ class RpmRootfs(Rootfs):
for pkg in registered_pkgs.split():
self.pm.save_rpmpostinst(pkg)
+def _cleanup(self):
+# during the execution of postprocess commands, rpm is called several
+# times to get the files installed, dependencies, etc. This creates the
+# __db.00* (Berkeley DB files that hold locks, rpm specific environment
+# settings, etc.), that should not get into the final rootfs
+self.pm.unlock_rpm_db()
+
class DpkgRootfs(Rootfs):
def __init__(self, d, manifest_dir):
@@ -431,6 +449,9 @@ class DpkgRootfs(Rootfs):
def _log_check(self):
pass
+def _cleanup(self):
+pass
+
class OpkgRootfs(Rootfs):
def __init__(self, d, manifest_dir):
@@ -694,6 +715,10 @@ class OpkgRootfs(Rootfs):
def _log_check(self):
pass
+def _cleanup(self):
+pass
+
+
def create_rootfs(d, manifest_dir=None):
env_bkp = os.environ.copy()
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 5/5] libc-common.bbclass: rename ALL the packages
On Fri, Mar 28, 2014 at 05:43:54PM +0800, Hongxu Jia wrote:
From: Peter Seebach peter.seeb...@windriver.com
The DEBIAN_NAMES feature renames some of the libc packages to
libc6* names --but only some. A previous patch added the -dbg
package. However, this doesn't cover other packages (such as
the -doc package), and it didn't take multilibs into account.
Signed-off-by: Peter Seebach peter.seeb...@windriver.com
Signed-off-by: Jeff Polk jeff.p...@windriver.com
Signed-off-by: Mark Hatle mark.ha...@windriver.com
Signed-off-by: Hongxu Jia hongxu@windriver.com
---
meta/classes/libc-common.bbclass | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/meta/classes/libc-common.bbclass
b/meta/classes/libc-common.bbclass
index daf499d..53bf467 100644
--- a/meta/classes/libc-common.bbclass
+++ b/meta/classes/libc-common.bbclass
@@ -25,12 +25,19 @@ def get_libc_fpu_setting(bb, d):
python populate_packages_prepend () {
if d.getVar('DEBIAN_NAMES', True):
+pkgs = d.getVar('PACKAGES', True).split()
bpn = d.getVar('BPN', True)
-d.setVar('PKG_'+bpn, 'libc6')
-d.setVar('PKG_'+bpn+'-dev', 'libc6-dev')
-d.setVar('PKG_'+bpn+'-dbg', 'libc6-dbg')
+prefix = d.getVar('MLPREFIX', True) or
+# Set the base package...
+d.setVar('PKG_' + prefix + bpn, prefix + 'libc6')
+initial = prefix + bpn + '-'
I would prefer better variable name here, first thing on my mind when
I've seen it was eglibc-initial and I was wondering why should all libc
packages be renamed like that.
+for p in pkgs:
+# And all the subpackages.
+if p.startswith(initial):
+renamed = p.replace(bpn, 'libc6', 1)
+d.setVar('PKG_' + p, renamed)
# For backward compatibility with old -dbg package
-d.appendVar('RPROVIDES_' + bpn + '-dbg', ' libc-dbg')
-d.appendVar('RCONFLICTS_' + bpn + '-dbg', ' libc-dbg')
-d.appendVar('RREPLACES_' + bpn + '-dbg', ' libc-dbg')
+d.appendVar('RPROVIDES_' + initial + 'dbg', ' ' + prefix +
'libc-dbg')
+d.appendVar('RCONFLICTS_' + initial + 'dbg', ' ' + prefix +
'libc-dbg')
+d.appendVar('RREPLACES_' + initial + 'dbg', ' ' + prefix +
'libc-dbg')
}
--
1.8.1.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/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.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] populate_sdk_base: add dependency of do_package_write_* tasks
The following changes since commit 5eceedf0326abaee632b32c7cb7ec74e6ba2d6d7: ocf-linux: remove recipe (2014-03-27 15:46:52 +) are available in the git repository at: git://git.yoctoproject.org/poky-contrib lpalcu/b5900_fix_adt_installer_issue http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=lpalcu/b5900_fix_adt_installer_issue Laurentiu Palcu (1): populate_sdk_base: add dependency of do_package_write_* tasks meta/classes/populate_sdk_base.bbclass |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 1.7.9.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] populate_sdk_base: add dependency of do_package_write_* tasks
nativesdk packages were created only for the first backend listed in
PACKAGE_CLASSES. Hence, if one had it set to package_rpm package_ipk
and did a 'bitbake -c populate_sdk core-image-something', the nativesdk
packages were created only for rpm.
This is particularily bad for adt-installer which is based on opkg
repos.
Credits go to richard.pur...@linuxfoundation.org who suggested me this
fix.
[YOCTO #5900]
Signed-off-by: Laurentiu Palcu laurentiu.pa...@intel.com
---
meta/classes/populate_sdk_base.bbclass |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/populate_sdk_base.bbclass
b/meta/classes/populate_sdk_base.bbclass
index 235d672..81da206 100644
--- a/meta/classes/populate_sdk_base.bbclass
+++ b/meta/classes/populate_sdk_base.bbclass
@@ -333,5 +333,5 @@ populate_sdk_log_check() {
do_populate_sdk[dirs] = ${TOPDIR}
do_populate_sdk[depends] += ${@' '.join([x + ':do_populate_sysroot' for x in
d.getVar('SDK_DEPENDS', True).split()])}
do_populate_sdk[rdepends] = ${@' '.join([x + ':do_populate_sysroot' for x in
d.getVar('SDK_RDEPENDS', True).split()])}
-do_populate_sdk[recrdeptask] += do_packagedata
+do_populate_sdk[recrdeptask] += do_packagedata do_package_write_rpm
do_package_write_ipk do_package_write_deb
addtask populate_sdk
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 5/5] libc-common.bbclass: rename ALL the packages
On 03/28/2014 06:17 PM, Martin Jansa wrote:
On Fri, Mar 28, 2014 at 05:43:54PM +0800, Hongxu Jia wrote:
From: Peter Seebach peter.seeb...@windriver.com
The DEBIAN_NAMES feature renames some of the libc packages to
libc6* names --but only some. A previous patch added the -dbg
package. However, this doesn't cover other packages (such as
the -doc package), and it didn't take multilibs into account.
Signed-off-by: Peter Seebach peter.seeb...@windriver.com
Signed-off-by: Jeff Polk jeff.p...@windriver.com
Signed-off-by: Mark Hatle mark.ha...@windriver.com
Signed-off-by: Hongxu Jia hongxu@windriver.com
---
meta/classes/libc-common.bbclass | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/meta/classes/libc-common.bbclass b/meta/classes/libc-common.bbclass
index daf499d..53bf467 100644
--- a/meta/classes/libc-common.bbclass
+++ b/meta/classes/libc-common.bbclass
@@ -25,12 +25,19 @@ def get_libc_fpu_setting(bb, d):
python populate_packages_prepend () {
if d.getVar('DEBIAN_NAMES', True):
+pkgs = d.getVar('PACKAGES', True).split()
bpn = d.getVar('BPN', True)
-d.setVar('PKG_'+bpn, 'libc6')
-d.setVar('PKG_'+bpn+'-dev', 'libc6-dev')
-d.setVar('PKG_'+bpn+'-dbg', 'libc6-dbg')
+prefix = d.getVar('MLPREFIX', True) or
+# Set the base package...
+d.setVar('PKG_' + prefix + bpn, prefix + 'libc6')
+initial = prefix + bpn + '-'
I would prefer better variable name here, first thing on my mind when
I've seen it was eglibc-initial and I was wondering why should all libc
packages be renamed like that.
Yep, how about 'libcprefix' instead,
s/initial/libcprefix/
//Hongxu
+for p in pkgs:
+# And all the subpackages.
+if p.startswith(initial):
+renamed = p.replace(bpn, 'libc6', 1)
+d.setVar('PKG_' + p, renamed)
# For backward compatibility with old -dbg package
-d.appendVar('RPROVIDES_' + bpn + '-dbg', ' libc-dbg')
-d.appendVar('RCONFLICTS_' + bpn + '-dbg', ' libc-dbg')
-d.appendVar('RREPLACES_' + bpn + '-dbg', ' libc-dbg')
+d.appendVar('RPROVIDES_' + initial + 'dbg', ' ' + prefix + 'libc-dbg')
+d.appendVar('RCONFLICTS_' + initial + 'dbg', ' ' + prefix + 'libc-dbg')
+d.appendVar('RREPLACES_' + initial + 'dbg', ' ' + prefix + 'libc-dbg')
}
--
1.8.1.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] eglibc: powerpc time related syscall malfunction - solved
On Wednesday, March 26, 2014 5:10 PM, Mats Kärrman wrote: Hi, The system is an OE-Core Dora distro-less build for a 32-bit PowerPC MPC5125. Tune file used is tune-ppce300c3.inc. eglibc version 2.18, gcc 4.8.1, binutils 2.23.2 (Dora defaults). The symptom that made me discover the problem was that some programs could not get the correct system time while others could. The failing ones often got the same insane time value every time a specific printout was triggered but different printouts got different time values (i.e. probably uninitialized stack variables). E.g.: date (busybox) works. logger (same busybox binary) does not. Neither does the pppd (syslog too). File access dates are OK. A proprietary program using ftime() is not working. A little test program (see below) gets the correct time when using time() but not when using ftime(). The same HW with SW built on OE-classic 2011.03 does not have this error. Dora on i.MX6 also works OK. I tried different kernels (3.2 and 3.12), and different tunings (hard-float, soft-float, etc.) but the behavior is the same. Tried using strace and found that on the old OE-classic and on i.MX6 I got trace logs for the syscalls to time (OE-classic) or gettimeofday (i.MX6) but for the new system there are no time related calls traced at all, not when it works and not when it fails... Then I tried with gdb. The paths taken by the program depends a lot on the machine tuning options used when building the image and SDK but I believe I have found a common pattern: When it works, a time function invoking a syscall, e.g. __kernel_time, is called but when it doesn't work, instead a gnu_indirect_function is called, returning a pointer to either a vdso or a local function but after that the function isn't called. As I understand it, this should happen through as/ld magic but for some reason it doesn't. As it turned out, this is a known problem with powerpc and eglibc 2.18. In 2.17 the use of vdso and indirect functions was not introduced yet and in 2.19 it is fixed. The fact that the functions are implemented as vdso calls for later kernels also explains why they are not visible to strace (the same is true for x86_64). I will send a patch containing a backport of the fix for Dora / eglibc 2.18 shortly. /M -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] weston : refactor to identify EGL, cairoglesv2 support
On 03/27/2014 08:09 PM, Otavio Salvador wrote:
On Thu, Mar 27, 2014 at 9:30 AM, Valentin Popa valentin.p...@intel.com wrote:
On 03/26/2014 11:07 PM, Otavio Salvador wrote:
From: Prabhu Sundararaj prabhu.sundara...@freescale.com
Signed-off-by: Prabhu Sundararaj prabhu.sundara...@freescale.com
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
meta/recipes-graphics/wayland/weston_1.4.0.bb | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-graphics/wayland/weston_1.4.0.bb
b/meta/recipes-graphics/wayland/weston_1.4.0.bb
index e0c354d..a41b5cd 100644
--- a/meta/recipes-graphics/wayland/weston_1.4.0.bb
+++ b/meta/recipes-graphics/wayland/weston_1.4.0.bb
@@ -23,7 +23,6 @@ EXTRA_OECONF = --enable-setuid-install \
--enable-simple-clients \
--enable-clients \
--enable-demo-clients-install \
---disable-simple-egl-clients \
--disable-libunwind \
--disable-rpi-compositor \
--disable-rdp-compositor
@@ -39,7 +38,7 @@ PACKAGECONFIG ??= ${@base_contains('DISTRO_FEATURES',
'wayland', 'kms fbdev way
# Weston on KMS
PACKAGECONFIG[kms] =
--enable-drm-compositor,--disable-drm-compositor,drm udev virtual/mesa
mtdev
# Weston on Wayland (nested Weston)
-PACKAGECONFIG[wayland] = --enable-wayland-compositor,--disable-egl
--disable-wayland-compositor,virtual/mesa
We need --disable-egl if wayland is not in DISTRO_FEATURES. See bug:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=5867
As egl is not part of PACKAGECONFIG it will do the right thing, no?
Yes, it will. My concerns are about --enable-drm-compositor (kms)
without egl; I know that the user can pass at runtime the --use-pixman
flag, but I think it's more important to keep egl enabled by default in
weston (this is probably the main usecase of wayland/weston). So if
you enable egl, the bug will reproduce.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 10/13] linux-yocto/3.14: introduce versioned recipes
On 14-03-28 05:45 AM, Richard Purdie wrote:
On Thu, 2014-03-27 at 14:25 -0400, Bruce Ashfield wrote:
The release kernel for Yocto 1.5 is the 3.14 kernel, so we introduce
the versioned recipes here.
Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb | 21
meta/recipes-kernel/linux/linux-yocto_3.14.bb | 37 ++
2 files changed, 58 insertions(+)
create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
create mode 100644 meta/recipes-kernel/linux/linux-yocto_3.14.bb
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
b/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
new file mode 100644
index ..8faa9584acf0
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
@@ -0,0 +1,21 @@
+require recipes-kernel/linux/linux-yocto.inc
+
+KBRANCH = standard/tiny/base
+LINUX_KERNEL_TYPE = tiny
+KCONFIG_MODE = --allnoconfig
+
+LINUX_VERSION ?= 3.14-rc8
+
+KMETA = meta
+
+SRCREV_machine ?= fecc3fd7d31bd93766ff4f0431fecdbbfa4c3a7c
+SRCREV_meta ?= 3689f99f4d2a051e8d3ff72345a67d4d04a88020
+
+PV = ${LINUX_VERSION}+git${SRCPV}
I'm afraid we can't do this in such a simple way. The big issue is that
according to our version comparison functions (in bitbake and in the
package managers), 3.14-rc8 3.14. This will then break updates
from package feeds.
The traditional way we've worked around this in times gone by is the
rather ugly:
PV = 3.13+3.14-rc8+git${SRCPV}
since in this case 3.14 3.13+3.14-rc8
The better way to handle this would be 3.14~rc8 however not all of our
package backends have support for ~ at this point so we can't do that.
There is a long standing bug open about this.
The same issue also applies to the libc-headers recipe.
. Since I don't do package feeds, it's never been a problem for me.
Wouldn't PE bump when I go to 3.14 work as well ? Or does that go away
with the PR sever as well ?
I can muck with PV, or we can hold until Linus releases over the
weekend, and I go with the released PVs.
What's your preference ?
Bruce
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] [Dora] eglibc 2.18: powerpc: Fix time related syscalls
Concatenated fix of PowerPC time related system calls in eglibc 2.18 taken from upstream glibc. See credits in patch header. The effect is that some time related system calls returns nothing or garbage. Tested on PowerPC e300c3. Eglibc 2.17 does not have this issue and the patches are already part of 2.19. Signed-off-by: Mats Karrman mats.karr...@tritech.se --- .../ppc-fix-time-related-syscalls.patch| 225 meta/recipes-core/eglibc/eglibc_2.18.bb|1 + 2 files changed, 226 insertions(+) create mode 100644 meta/recipes-core/eglibc/eglibc-2.18/ppc-fix-time-related-syscalls.patch diff --git a/meta/recipes-core/eglibc/eglibc-2.18/ppc-fix-time-related-syscalls.patch b/meta/recipes-core/eglibc/eglibc-2.18/ppc-fix-time-related-syscalls.patch new file mode 100644 index 000..fa1072b --- /dev/null +++ b/meta/recipes-core/eglibc/eglibc-2.18/ppc-fix-time-related-syscalls.patch @@ -0,0 +1,225 @@ +Concatenated fix of PowerPC time related system calls in eglibc 2.18 taken +from upstream glibc. Eglibc 2.17 does not have this issue and the patches are +already part of 2.19. +This compilation includes the following committs: + + +PowerPC: Fix vDSO missing ODP entries + +author Adhemerval Zanella azane...@linux.vnet.ibm.com + Thu, 7 Nov 2013 11:34:22 + (05:34 -0600) + +This patch fixes the vDSO symbol used directed in IFUNC resolver where +they do not have an associated ODP entry leading to undefined behavior +in some cases. It adds an artificial OPD static entry to such cases +and set its TOC to non 0 to avoid triggering lazy resolutions. + + +Update copyright notices with scripts/update-copyrights + +author Allan McRae al...@archlinux.org + Wed, 1 Jan 2014 11:03:15 + (21:03 +1000) + +((Only for files otherwise touched by this patch)) + + +PowerPC: Fix ftime gettimeofday internal call returning bogus data + +author Adhemerval Zanella azane...@linux.vnet.ibm.com + Thu, 16 Jan 2014 12:53:18 + (06:53 -0600) + +This patches fixes BZ#16430 by setting a different symbol for internal +GLIBC calls that points to ifunc resolvers. For PPC32, if the symbol +is defined as hidden (which is the case for gettimeofday and time) the +compiler will create local branches (symbol@local) and linker will not +create PLT calls (required for IFUNC). This will leads to internal symbol +calling the IFUNC resolver instead of the resolved symbol. +For PPC64 this behavior does not occur because a call to a function in +another translation unit might use a different toc pointer thus requiring +a PLT call. + + +PowerPC: Fix gettimeofday ifunc selection + +author Adhemerval Zanella azane...@linux.vnet.ibm.com + Mon, 20 Jan 2014 18:29:51 + (12:29 -0600) + +The IFUNC selector for gettimeofday runs before _libc_vdso_platform_setup where +__vdso_gettimeofday is set. The selector then sets __gettimeofday (the internal +version used within GLIBC) to use the system call version instead of the vDSO one. +This patch changes the check if vDSO is available to get its value directly +instead of rely on __vdso_gettimeofday. + +This patch changes it by getting the vDSO value directly. + +It fixes BZ#16431. + + +--- +diff -pruN libc.orig/sysdeps/unix/sysv/linux/powerpc/bits/libc-vdso.h libc/sysdeps/unix/sysv/linux/powerpc/bits/libc-vdso.h +--- libc.orig/sysdeps/unix/sysv/linux/powerpc/bits/libc-vdso.h libc/sysdeps/unix/sysv/linux/powerpc/bits/libc-vdso.h +@@ -1,5 +1,5 @@ + /* Resolve function pointers to VDSO functions. +- Copyright (C) 2005-2013 Free Software Foundation, Inc. ++ Copyright (C) 2005-2014 Free Software Foundation, Inc. +This file is part of the GNU C Library. + +The GNU C Library is free software; you can redistribute it and/or +@@ -34,12 +34,32 @@ extern void *__vdso_getcpu; + + extern void *__vdso_time; + +-/* This macro is needed for PPC64 to return a skeleton OPD entry of a vDSO +- symbol. This works because _dl_vdso_vsym always return the function +- address, and no vDSO symbols use the TOC or chain pointers from the OPD +- so we can allow them to be garbage. */ + #if defined(__PPC64__) || defined(__powerpc64__) +-#define VDSO_IFUNC_RET(value) ((void *) (value)) ++/* The correct solution is for _dl_vdso_vsym to return the address of the OPD ++ for the kernel VDSO function. That address would then be stored in the ++ __vdso_* variables and returned as the result of the IFUNC resolver function. ++ Yet, the kernel does not contain any OPD entries for the VDSO functions ++ (incomplete implementation). However, PLT relocations for IFUNCs still expect ++ the address of an OPD to be returned from the IFUNC resolver function (since ++ PLT entries on PPC64 are just copies of OPDs). The solution for now is to ++ create an artificial static OPD for each VDSO function returned by a resolver ++ function. The TOC value is set to a non-zero value to avoid triggering lazy ++
Re: [OE-core] [PATCH 10/13] linux-yocto/3.14: introduce versioned recipes
On Fri, Mar 28, 2014 at 08:52:15AM -0400, Bruce Ashfield wrote:
On 14-03-28 05:45 AM, Richard Purdie wrote:
On Thu, 2014-03-27 at 14:25 -0400, Bruce Ashfield wrote:
The release kernel for Yocto 1.5 is the 3.14 kernel, so we introduce
the versioned recipes here.
Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb | 21
meta/recipes-kernel/linux/linux-yocto_3.14.bb | 37
++
2 files changed, 58 insertions(+)
create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
create mode 100644 meta/recipes-kernel/linux/linux-yocto_3.14.bb
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
b/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
new file mode 100644
index ..8faa9584acf0
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
@@ -0,0 +1,21 @@
+require recipes-kernel/linux/linux-yocto.inc
+
+KBRANCH = standard/tiny/base
+LINUX_KERNEL_TYPE = tiny
+KCONFIG_MODE = --allnoconfig
+
+LINUX_VERSION ?= 3.14-rc8
+
+KMETA = meta
+
+SRCREV_machine ?= fecc3fd7d31bd93766ff4f0431fecdbbfa4c3a7c
+SRCREV_meta ?= 3689f99f4d2a051e8d3ff72345a67d4d04a88020
+
+PV = ${LINUX_VERSION}+git${SRCPV}
I'm afraid we can't do this in such a simple way. The big issue is that
according to our version comparison functions (in bitbake and in the
package managers), 3.14-rc8 3.14. This will then break updates
from package feeds.
The traditional way we've worked around this in times gone by is the
rather ugly:
PV = 3.13+3.14-rc8+git${SRCPV}
since in this case 3.14 3.13+3.14-rc8
The better way to handle this would be 3.14~rc8 however not all of our
package backends have support for ~ at this point so we can't do that.
There is a long standing bug open about this.
The same issue also applies to the libc-headers recipe.
. Since I don't do package feeds, it's never been a problem for me.
Wouldn't PE bump when I go to 3.14 work as well ?
yes, but we were trying to use PE bumps only in cases where it's really
needed, using sortable PV as RP suggested is IMHO better
Or does that go away with the PR sever as well ?
no, sewer wont help
I can muck with PV, or we can hold until Linus releases over the
weekend, and I go with the released PVs.
What's your preference ?
Bruce
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/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.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] image.py: check file exists before deleting
The following changes since commit 8c3eb5ee4582b6f6d489549290937657f37fc19e: packagegroup-toolset-native: Update after ocf-linux - cryptodev-linux change (2014-03-27 19:53:30 +) are available in the git repository at: git://git.yoctoproject.org/poky-contrib lpalcu/b6029_ignore_broken_symlinks http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=lpalcu/b6029_ignore_broken_symlinks Laurentiu Palcu (1): image.py: check file exists before deleting meta/lib/oe/image.py |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- 1.7.9.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] image.py: check file exists before deleting
When RM_OLD_IMAGE = 1, we delete old images but we didn't check they
actually exist...
[YOCTO #6029]
Signed-off-by: Laurentiu Palcu laurentiu.pa...@intel.com
---
meta/lib/oe/image.py |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/lib/oe/image.py b/meta/lib/oe/image.py
index a03b73e..c9b9033 100644
--- a/meta/lib/oe/image.py
+++ b/meta/lib/oe/image.py
@@ -192,7 +192,8 @@ class Image(ImageDepGraph):
if img.find(self.d.getVar('IMAGE_LINK_NAME', True)) == 0:
img = os.path.join(deploy_dir, img)
if os.path.islink(img):
-if self.d.getVar('RM_OLD_IMAGE', True) == 1:
+if self.d.getVar('RM_OLD_IMAGE', True) == 1 and \
+os.path.exists(os.path.realpath(img)):
os.remove(os.path.realpath(img))
os.remove(img)
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] weston : refactor to identify EGL, cairoglesv2 support
On 03/28/2014 02:53 PM, Otavio Salvador wrote:
On Fri, Mar 28, 2014 at 9:23 AM, Valentin Popa valentin.p...@intel.com wrote:
On 03/27/2014 08:09 PM, Otavio Salvador wrote:
On Thu, Mar 27, 2014 at 9:30 AM, Valentin Popa valentin.p...@intel.com
wrote:
On 03/26/2014 11:07 PM, Otavio Salvador wrote:
From: Prabhu Sundararaj prabhu.sundara...@freescale.com
Signed-off-by: Prabhu Sundararaj prabhu.sundara...@freescale.com
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
meta/recipes-graphics/wayland/weston_1.4.0.bb | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-graphics/wayland/weston_1.4.0.bb
b/meta/recipes-graphics/wayland/weston_1.4.0.bb
index e0c354d..a41b5cd 100644
--- a/meta/recipes-graphics/wayland/weston_1.4.0.bb
+++ b/meta/recipes-graphics/wayland/weston_1.4.0.bb
@@ -23,7 +23,6 @@ EXTRA_OECONF = --enable-setuid-install \
--enable-simple-clients \
--enable-clients \
--enable-demo-clients-install \
---disable-simple-egl-clients \
--disable-libunwind \
--disable-rpi-compositor \
--disable-rdp-compositor
@@ -39,7 +38,7 @@ PACKAGECONFIG ??= ${@base_contains('DISTRO_FEATURES',
'wayland', 'kms fbdev way
# Weston on KMS
PACKAGECONFIG[kms] =
--enable-drm-compositor,--disable-drm-compositor,drm udev virtual/mesa
mtdev
# Weston on Wayland (nested Weston)
-PACKAGECONFIG[wayland] = --enable-wayland-compositor,--disable-egl
--disable-wayland-compositor,virtual/mesa
We need --disable-egl if wayland is not in DISTRO_FEATURES. See bug:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=5867
As egl is not part of PACKAGECONFIG it will do the right thing, no?
Yes, it will. My concerns are about --enable-drm-compositor (kms) without
egl; I know that the user can pass at runtime the --use-pixman flag, but I
think it's more important to keep egl enabled by default in weston (this is
probably the main usecase of wayland/weston). So if you enable egl, the
bug will reproduce.
The PACKAGECONFIG is for flexibility and so we are using it here as it
is designed. I understand we still don't have a way to map config
dependencies but this is no excuse to say the patch is wrong or
inappropriate.
We are using this in the upcoming i.MX6 Wayland support we sent to
meta-fsl-arm and the only blocker is this patch be accepted.
The patch is not wrong, but disables egl. Looks good to me and if merged
I'll submit a patch to add egl in PACKAGECONFIG.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 10/13] linux-yocto/3.14: introduce versioned recipes
On Fri, 2014-03-28 at 08:52 -0400, Bruce Ashfield wrote:
On 14-03-28 05:45 AM, Richard Purdie wrote:
On Thu, 2014-03-27 at 14:25 -0400, Bruce Ashfield wrote:
The release kernel for Yocto 1.5 is the 3.14 kernel, so we introduce
the versioned recipes here.
Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb | 21
meta/recipes-kernel/linux/linux-yocto_3.14.bb | 37
++
2 files changed, 58 insertions(+)
create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
create mode 100644 meta/recipes-kernel/linux/linux-yocto_3.14.bb
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
b/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
new file mode 100644
index ..8faa9584acf0
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
@@ -0,0 +1,21 @@
+require recipes-kernel/linux/linux-yocto.inc
+
+KBRANCH = standard/tiny/base
+LINUX_KERNEL_TYPE = tiny
+KCONFIG_MODE = --allnoconfig
+
+LINUX_VERSION ?= 3.14-rc8
+
+KMETA = meta
+
+SRCREV_machine ?= fecc3fd7d31bd93766ff4f0431fecdbbfa4c3a7c
+SRCREV_meta ?= 3689f99f4d2a051e8d3ff72345a67d4d04a88020
+
+PV = ${LINUX_VERSION}+git${SRCPV}
I'm afraid we can't do this in such a simple way. The big issue is that
according to our version comparison functions (in bitbake and in the
package managers), 3.14-rc8 3.14. This will then break updates
from package feeds.
The traditional way we've worked around this in times gone by is the
rather ugly:
PV = 3.13+3.14-rc8+git${SRCPV}
since in this case 3.14 3.13+3.14-rc8
The better way to handle this would be 3.14~rc8 however not all of our
package backends have support for ~ at this point so we can't do that.
There is a long standing bug open about this.
The same issue also applies to the libc-headers recipe.
. Since I don't do package feeds, it's never been a problem for me.
Wouldn't PE bump when I go to 3.14 work as well ? Or does that go away
with the PR sever as well ?
A PE bump would work however we try not to use those, they're a last
resort to correct things we can't otherwise fix. The PR server doesn't
help here although in future I do hope we can teach it about PE too.
I can muck with PV, or we can hold until Linus releases over the
weekend, and I go with the released PVs.
What's your preference ?
Might as well wait over the weekend. If Linus does go for a rc9, we'll
need to merge a version with the modified PV though.
In the meantime I might pull this series into master-next for testing
but it will not get added to master in its current form.
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] weston : refactor to identify EGL, cairoglesv2 support
On 03/28/2014 03:35 PM, Otavio Salvador wrote:
On Fri, Mar 28, 2014 at 10:28 AM, Valentin Popa valentin.p...@intel.com wrote:
On 03/28/2014 02:53 PM, Otavio Salvador wrote:
On Fri, Mar 28, 2014 at 9:23 AM, Valentin Popa valentin.p...@intel.com
wrote:
On 03/27/2014 08:09 PM, Otavio Salvador wrote:
On Thu, Mar 27, 2014 at 9:30 AM, Valentin Popa valentin.p...@intel.com
wrote:
On 03/26/2014 11:07 PM, Otavio Salvador wrote:
From: Prabhu Sundararaj prabhu.sundara...@freescale.com
Signed-off-by: Prabhu Sundararaj prabhu.sundara...@freescale.com
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
meta/recipes-graphics/wayland/weston_1.4.0.bb | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-graphics/wayland/weston_1.4.0.bb
b/meta/recipes-graphics/wayland/weston_1.4.0.bb
index e0c354d..a41b5cd 100644
--- a/meta/recipes-graphics/wayland/weston_1.4.0.bb
+++ b/meta/recipes-graphics/wayland/weston_1.4.0.bb
@@ -23,7 +23,6 @@ EXTRA_OECONF = --enable-setuid-install \
--enable-simple-clients \
--enable-clients \
--enable-demo-clients-install \
---disable-simple-egl-clients \
--disable-libunwind \
--disable-rpi-compositor \
--disable-rdp-compositor
@@ -39,7 +38,7 @@ PACKAGECONFIG ??=
${@base_contains('DISTRO_FEATURES',
'wayland', 'kms fbdev way
# Weston on KMS
PACKAGECONFIG[kms] =
--enable-drm-compositor,--disable-drm-compositor,drm udev
virtual/mesa
mtdev
# Weston on Wayland (nested Weston)
-PACKAGECONFIG[wayland] = --enable-wayland-compositor,--disable-egl
--disable-wayland-compositor,virtual/mesa
We need --disable-egl if wayland is not in DISTRO_FEATURES. See bug:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=5867
As egl is not part of PACKAGECONFIG it will do the right thing, no?
Yes, it will. My concerns are about --enable-drm-compositor (kms) without
egl; I know that the user can pass at runtime the --use-pixman flag, but
I
think it's more important to keep egl enabled by default in weston (this
is
probably the main usecase of wayland/weston). So if you enable egl, the
bug will reproduce.
The PACKAGECONFIG is for flexibility and so we are using it here as it
is designed. I understand we still don't have a way to map config
dependencies but this is no excuse to say the patch is wrong or
inappropriate.
We are using this in the upcoming i.MX6 Wayland support we sent to
meta-fsl-arm and the only blocker is this patch be accepted.
The patch is not wrong, but disables egl. Looks good to me and if merged
I'll submit a patch to add egl in PACKAGECONFIG.
If you want, I can add the egl there, and send v2. That's easy.
That would be great. And don't forget to --disable-egl in case wayland
is not in PACKAGECONFIG.
Thanks!
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] populate_sdk_*: Drop now unneeded recrdeptask flags
Now populate_sdk_base has the appropriate flags, we can drop these from the
individual
classes.
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/classes/populate_sdk_deb.bbclass
b/meta/classes/populate_sdk_deb.bbclass
index b96c5ef..acb1f73 100644
--- a/meta/classes/populate_sdk_deb.bbclass
+++ b/meta/classes/populate_sdk_deb.bbclass
@@ -1,6 +1,4 @@
do_populate_sdk[depends] += dpkg-native:do_populate_sysroot
apt-native:do_populate_sysroot bzip2-native:do_populate_sysroot
-do_populate_sdk[recrdeptask] += do_package_write_deb
-
DEB_SDK_ARCH = ${@[d.getVar('SDK_ARCH', True), i386]\
[d.getVar('SDK_ARCH', True) in \
diff --git a/meta/classes/populate_sdk_ipk.bbclass
b/meta/classes/populate_sdk_ipk.bbclass
index e2e3523..8b2cb6d 100644
--- a/meta/classes/populate_sdk_ipk.bbclass
+++ b/meta/classes/populate_sdk_ipk.bbclass
@@ -1,4 +1,3 @@
do_populate_sdk[depends] += opkg-native:do_populate_sysroot
opkg-utils-native:do_populate_sysroot
-do_populate_sdk[recrdeptask] += do_package_write_ipk
do_populate_sdk[lockfiles] += ${WORKDIR}/ipk.lock
diff --git a/meta/classes/populate_sdk_rpm.bbclass
b/meta/classes/populate_sdk_rpm.bbclass
index 0fdef3b..4954d00 100644
--- a/meta/classes/populate_sdk_rpm.bbclass
+++ b/meta/classes/populate_sdk_rpm.bbclass
@@ -11,8 +11,6 @@ do_populate_sdk[depends] += opkg-native:do_populate_sysroot
# Creating the repo info in do_rootfs
do_populate_sdk[depends] += createrepo-native:do_populate_sysroot
-do_populate_sdk[recrdeptask] += do_package_write_rpm
-
rpmlibdir = /var/lib/rpm
do_populate_sdk[lockfiles] += ${DEPLOY_DIR_RPM}/rpm.lock
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] package_*.bbclass: Simplify addtask
The package_write task was previously removed. Remove a remaining superfluous
reference to it.
(From OE-Core rev: 74c48d8ff3502a4d11df05dc70da6b4155e1800d)
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/classes/package_deb.bbclass b/meta/classes/package_deb.bbclass
index 9ae0017..7bc29df 100644
--- a/meta/classes/package_deb.bbclass
+++ b/meta/classes/package_deb.bbclass
@@ -308,7 +308,7 @@ python do_package_write_deb () {
do_package_write_deb[dirs] = ${PKGWRITEDIRDEB}
do_package_write_deb[cleandirs] = ${PKGWRITEDIRDEB}
do_package_write_deb[umask] = 022
-addtask package_write_deb before do_package_write after do_packagedata
do_package
+addtask package_write_deb after do_packagedata do_package
PACKAGEINDEXDEPS += dpkg-native:do_populate_sysroot
diff --git a/meta/classes/package_ipk.bbclass b/meta/classes/package_ipk.bbclass
index aab31e5..2949d1d 100644
--- a/meta/classes/package_ipk.bbclass
+++ b/meta/classes/package_ipk.bbclass
@@ -253,7 +253,7 @@ python do_package_write_ipk () {
do_package_write_ipk[dirs] = ${PKGWRITEDIRIPK}
do_package_write_ipk[cleandirs] = ${PKGWRITEDIRIPK}
do_package_write_ipk[umask] = 022
-addtask package_write_ipk before do_package_write after do_packagedata
do_package
+addtask package_write_ipk after do_packagedata do_package
PACKAGEINDEXDEPS += opkg-utils-native:do_populate_sysroot
PACKAGEINDEXDEPS += opkg-native:do_populate_sysroot
diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass
index 9e63878..1ff2b36 100644
--- a/meta/classes/package_rpm.bbclass
+++ b/meta/classes/package_rpm.bbclass
@@ -723,7 +723,7 @@ python do_package_write_rpm () {
do_package_write_rpm[dirs] = ${PKGWRITEDIRRPM}
do_package_write_rpm[cleandirs] = ${PKGWRITEDIRRPM}
do_package_write_rpm[umask] = 022
-addtask package_write_rpm before do_package_write after do_packagedata
do_package
+addtask package_write_rpm after do_packagedata do_package
PACKAGEINDEXDEPS += rpm-native:do_populate_sysroot
PACKAGEINDEXDEPS += createrepo-native:do_populate_sysroot
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] weston : refactor to identify EGL, cairoglesv2 support
If you want, I can add the egl there, and send v2. That's easy. That would be great. And don't forget to --disable-egl in case wayland is not in PACKAGECONFIG. This is the point I don't agree. I think user needs to drop egl when dropping wayland. I concur. EGL is not just useful for Wayland. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 10/13] linux-yocto/3.14: introduce versioned recipes
On 14-03-28 09:32 AM, Richard Purdie wrote:
On Fri, 2014-03-28 at 08:52 -0400, Bruce Ashfield wrote:
On 14-03-28 05:45 AM, Richard Purdie wrote:
On Thu, 2014-03-27 at 14:25 -0400, Bruce Ashfield wrote:
The release kernel for Yocto 1.5 is the 3.14 kernel, so we introduce
the versioned recipes here.
Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb | 21
meta/recipes-kernel/linux/linux-yocto_3.14.bb | 37
++
2 files changed, 58 insertions(+)
create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
create mode 100644 meta/recipes-kernel/linux/linux-yocto_3.14.bb
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
b/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
new file mode 100644
index ..8faa9584acf0
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
@@ -0,0 +1,21 @@
+require recipes-kernel/linux/linux-yocto.inc
+
+KBRANCH = standard/tiny/base
+LINUX_KERNEL_TYPE = tiny
+KCONFIG_MODE = --allnoconfig
+
+LINUX_VERSION ?= 3.14-rc8
+
+KMETA = meta
+
+SRCREV_machine ?= fecc3fd7d31bd93766ff4f0431fecdbbfa4c3a7c
+SRCREV_meta ?= 3689f99f4d2a051e8d3ff72345a67d4d04a88020
+
+PV = ${LINUX_VERSION}+git${SRCPV}
I'm afraid we can't do this in such a simple way. The big issue is that
according to our version comparison functions (in bitbake and in the
package managers), 3.14-rc8 3.14. This will then break updates
from package feeds.
The traditional way we've worked around this in times gone by is the
rather ugly:
PV = 3.13+3.14-rc8+git${SRCPV}
since in this case 3.14 3.13+3.14-rc8
The better way to handle this would be 3.14~rc8 however not all of our
package backends have support for ~ at this point so we can't do that.
There is a long standing bug open about this.
The same issue also applies to the libc-headers recipe.
. Since I don't do package feeds, it's never been a problem for me.
Wouldn't PE bump when I go to 3.14 work as well ? Or does that go away
with the PR sever as well ?
A PE bump would work however we try not to use those, they're a last
resort to correct things we can't otherwise fix. The PR server doesn't
help here although in future I do hope we can teach it about PE too.
I can muck with PV, or we can hold until Linus releases over the
weekend, and I go with the released PVs.
What's your preference ?
Might as well wait over the weekend. If Linus does go for a rc9, we'll
need to merge a version with the modified PV though.
Sounds good. I'm updating the PVs to the format you showed regardless.
Might as well take a lesson from the comments in the review for next
time, in particular since I'm going to split the versioned recipe a bit
sooner for 1.7.
Cheers,
Bruce
In the meantime I might pull this series into master-next for testing
but it will not get added to master in its current form.
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] weston : refactor to identify EGL, cairoglesv2 support
On Fri, Mar 28, 2014 at 10:37 AM, Valentin Popa valentin.p...@intel.com wrote:
On 03/28/2014 03:35 PM, Otavio Salvador wrote:
On Fri, Mar 28, 2014 at 10:28 AM, Valentin Popa valentin.p...@intel.com
wrote:
On 03/28/2014 02:53 PM, Otavio Salvador wrote:
On Fri, Mar 28, 2014 at 9:23 AM, Valentin Popa valentin.p...@intel.com
wrote:
On 03/27/2014 08:09 PM, Otavio Salvador wrote:
On Thu, Mar 27, 2014 at 9:30 AM, Valentin Popa
valentin.p...@intel.com
wrote:
On 03/26/2014 11:07 PM, Otavio Salvador wrote:
From: Prabhu Sundararaj prabhu.sundara...@freescale.com
Signed-off-by: Prabhu Sundararaj prabhu.sundara...@freescale.com
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
meta/recipes-graphics/wayland/weston_1.4.0.bb | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-graphics/wayland/weston_1.4.0.bb
b/meta/recipes-graphics/wayland/weston_1.4.0.bb
index e0c354d..a41b5cd 100644
--- a/meta/recipes-graphics/wayland/weston_1.4.0.bb
+++ b/meta/recipes-graphics/wayland/weston_1.4.0.bb
@@ -23,7 +23,6 @@ EXTRA_OECONF = --enable-setuid-install \
--enable-simple-clients \
--enable-clients \
--enable-demo-clients-install \
---disable-simple-egl-clients \
--disable-libunwind \
--disable-rpi-compositor \
--disable-rdp-compositor
@@ -39,7 +38,7 @@ PACKAGECONFIG ??=
${@base_contains('DISTRO_FEATURES',
'wayland', 'kms fbdev way
# Weston on KMS
PACKAGECONFIG[kms] =
--enable-drm-compositor,--disable-drm-compositor,drm udev
virtual/mesa
mtdev
# Weston on Wayland (nested Weston)
-PACKAGECONFIG[wayland] = --enable-wayland-compositor,--disable-egl
--disable-wayland-compositor,virtual/mesa
We need --disable-egl if wayland is not in DISTRO_FEATURES. See bug:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=5867
As egl is not part of PACKAGECONFIG it will do the right thing, no?
Yes, it will. My concerns are about --enable-drm-compositor (kms)
without
egl; I know that the user can pass at runtime the --use-pixman flag,
but
I
think it's more important to keep egl enabled by default in weston
(this
is
probably the main usecase of wayland/weston). So if you enable egl,
the
bug will reproduce.
The PACKAGECONFIG is for flexibility and so we are using it here as it
is designed. I understand we still don't have a way to map config
dependencies but this is no excuse to say the patch is wrong or
inappropriate.
We are using this in the upcoming i.MX6 Wayland support we sent to
meta-fsl-arm and the only blocker is this patch be accepted.
The patch is not wrong, but disables egl. Looks good to me and if merged
I'll submit a patch to add egl in PACKAGECONFIG.
If you want, I can add the egl there, and send v2. That's easy.
That would be great. And don't forget to --disable-egl in case wayland is
not in PACKAGECONFIG.
This is the point I don't agree. I think user needs to drop egl when
dropping wayland.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] weston : refactor to identify EGL, cairoglesv2 support
On 03/28/2014 03:55 PM, Otavio Salvador wrote:
On Fri, Mar 28, 2014 at 10:37 AM, Valentin Popa valentin.p...@intel.com wrote:
On 03/28/2014 03:35 PM, Otavio Salvador wrote:
On Fri, Mar 28, 2014 at 10:28 AM, Valentin Popa valentin.p...@intel.com
wrote:
On 03/28/2014 02:53 PM, Otavio Salvador wrote:
On Fri, Mar 28, 2014 at 9:23 AM, Valentin Popa valentin.p...@intel.com
wrote:
On 03/27/2014 08:09 PM, Otavio Salvador wrote:
On Thu, Mar 27, 2014 at 9:30 AM, Valentin Popa
valentin.p...@intel.com
wrote:
On 03/26/2014 11:07 PM, Otavio Salvador wrote:
From: Prabhu Sundararaj prabhu.sundara...@freescale.com
Signed-off-by: Prabhu Sundararaj prabhu.sundara...@freescale.com
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
meta/recipes-graphics/wayland/weston_1.4.0.bb | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-graphics/wayland/weston_1.4.0.bb
b/meta/recipes-graphics/wayland/weston_1.4.0.bb
index e0c354d..a41b5cd 100644
--- a/meta/recipes-graphics/wayland/weston_1.4.0.bb
+++ b/meta/recipes-graphics/wayland/weston_1.4.0.bb
@@ -23,7 +23,6 @@ EXTRA_OECONF = --enable-setuid-install \
--enable-simple-clients \
--enable-clients \
--enable-demo-clients-install \
---disable-simple-egl-clients \
--disable-libunwind \
--disable-rpi-compositor \
--disable-rdp-compositor
@@ -39,7 +38,7 @@ PACKAGECONFIG ??=
${@base_contains('DISTRO_FEATURES',
'wayland', 'kms fbdev way
# Weston on KMS
PACKAGECONFIG[kms] =
--enable-drm-compositor,--disable-drm-compositor,drm udev
virtual/mesa
mtdev
# Weston on Wayland (nested Weston)
-PACKAGECONFIG[wayland] = --enable-wayland-compositor,--disable-egl
--disable-wayland-compositor,virtual/mesa
We need --disable-egl if wayland is not in DISTRO_FEATURES. See bug:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=5867
As egl is not part of PACKAGECONFIG it will do the right thing, no?
Yes, it will. My concerns are about --enable-drm-compositor (kms)
without
egl; I know that the user can pass at runtime the --use-pixman flag,
but
I
think it's more important to keep egl enabled by default in weston
(this
is
probably the main usecase of wayland/weston). So if you enable egl,
the
bug will reproduce.
The PACKAGECONFIG is for flexibility and so we are using it here as it
is designed. I understand we still don't have a way to map config
dependencies but this is no excuse to say the patch is wrong or
inappropriate.
We are using this in the upcoming i.MX6 Wayland support we sent to
meta-fsl-arm and the only blocker is this patch be accepted.
The patch is not wrong, but disables egl. Looks good to me and if merged
I'll submit a patch to add egl in PACKAGECONFIG.
If you want, I can add the egl there, and send v2. That's easy.
That would be great. And don't forget to --disable-egl in case wayland is
not in PACKAGECONFIG.
This is the point I don't agree. I think user needs to drop egl when
dropping wayland.
Makes sens. So you need:
PACKAGECONFIG ??= ${@base_contains('DISTRO_FEATURES', 'wayland', 'egl
kms fbdev wayland', '', d)} \
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] weston : refactor to identify EGL, cairoglesv2 support
On Fri, Mar 28, 2014 at 12:32 PM, Valentin Popa valentin.p...@intel.com wrote:
On 03/28/2014 04:02 PM, Otavio Salvador wrote:
From: Prabhu Sundararaj prabhu.sundara...@freescale.com
Signed-off-by: Prabhu Sundararaj prabhu.sundara...@freescale.com
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
meta/recipes-graphics/wayland/weston_1.4.0.bb | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-graphics/wayland/weston_1.4.0.bb
b/meta/recipes-graphics/wayland/weston_1.4.0.bb
index e0c354d..5213166 100644
--- a/meta/recipes-graphics/wayland/weston_1.4.0.bb
+++ b/meta/recipes-graphics/wayland/weston_1.4.0.bb
@@ -23,13 +23,12 @@ EXTRA_OECONF = --enable-setuid-install \
--enable-simple-clients \
--enable-clients \
--enable-demo-clients-install \
---disable-simple-egl-clients \
--disable-libunwind \
--disable-rpi-compositor \
--disable-rdp-compositor
-PACKAGECONFIG ??= ${@base_contains('DISTRO_FEATURES', 'wayland',
'kms fbdev wayland', '', d)} \
+PACKAGECONFIG ??= ${@base_contains('DISTRO_FEATURES', 'wayland', 'kms
fbdev wayland egl', '', d)} \
${@base_contains('DISTRO_FEATURES', 'x11', 'x11', '',
d)} \
${@base_contains('DISTRO_FEATURES', 'pam', 'launch',
'', d)} \
@@ -39,7 +38,7 @@ PACKAGECONFIG ??= ${@base_contains('DISTRO_FEATURES',
'wayland', 'kms fbdev way
# Weston on KMS
PACKAGECONFIG[kms] =
--enable-drm-compositor,--disable-drm-compositor,drm udev virtual/mesa
mtdev
# Weston on Wayland (nested Weston)
-PACKAGECONFIG[wayland] = --enable-wayland-compositor,--disable-egl
--disable-wayland-compositor,virtual/mesa
+PACKAGECONFIG[wayland] =
--enable-wayland-compositor,--disable-wayland-compositor,virtual/mesa
# Weston on X11
PACKAGECONFIG[x11] =
--enable-x11-compositor,--disable-x11-compositor,virtual/libx11 libxcb
libxcb libxcursor cairo
# Headless Weston
@@ -50,6 +49,10 @@ PACKAGECONFIG[fbdev] =
--enable-fbdev-compositor,--disable-fbdev-compositor,ude
PACKAGECONFIG[launch] =
--enable-weston-launch,--disable-weston-launch,libpam drm
# VA-API desktop recorder
PACKAGECONFIG[vaapi] =
--enable-vaapi-recorder,--disable-vaapi-recorder,libva
+# Weston with EGL support
+PACKAGECONFIG[egl] = --enable-egl
--enable-simple-egl-clients,--disable-egl
--disable-simple-egl-clients,virtual/egl
+# Weston with cairo glesv2 support
+PACKAGECONFIG[cairo-glesv2] =
--with-cairo-glesv2,--with-cairo=image,cairo
do_install_append() {
# Weston doesn't need the .la files to load modules, so wipe them
Looks good to me.
Sorry Otavio for the delay introduced by the discussions. Hope it will be
merged quickly and get your issue solved :)
No problem; it was for the better and ensures we have a full
understanding of it :-) Please 'ack' it if you can.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] weston : refactor to identify EGL, cairoglesv2 support
On 03/28/2014 05:37 PM, Otavio Salvador wrote:
On Fri, Mar 28, 2014 at 12:32 PM, Valentin Popa valentin.p...@intel.com wrote:
On 03/28/2014 04:02 PM, Otavio Salvador wrote:
From: Prabhu Sundararaj prabhu.sundara...@freescale.com
Signed-off-by: Prabhu Sundararaj prabhu.sundara...@freescale.com
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
meta/recipes-graphics/wayland/weston_1.4.0.bb | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-graphics/wayland/weston_1.4.0.bb
b/meta/recipes-graphics/wayland/weston_1.4.0.bb
index e0c354d..5213166 100644
--- a/meta/recipes-graphics/wayland/weston_1.4.0.bb
+++ b/meta/recipes-graphics/wayland/weston_1.4.0.bb
@@ -23,13 +23,12 @@ EXTRA_OECONF = --enable-setuid-install \
--enable-simple-clients \
--enable-clients \
--enable-demo-clients-install \
---disable-simple-egl-clients \
--disable-libunwind \
--disable-rpi-compositor \
--disable-rdp-compositor
-PACKAGECONFIG ??= ${@base_contains('DISTRO_FEATURES', 'wayland',
'kms fbdev wayland', '', d)} \
+PACKAGECONFIG ??= ${@base_contains('DISTRO_FEATURES', 'wayland', 'kms
fbdev wayland egl', '', d)} \
${@base_contains('DISTRO_FEATURES', 'x11', 'x11', '',
d)} \
${@base_contains('DISTRO_FEATURES', 'pam', 'launch',
'', d)} \
@@ -39,7 +38,7 @@ PACKAGECONFIG ??= ${@base_contains('DISTRO_FEATURES',
'wayland', 'kms fbdev way
# Weston on KMS
PACKAGECONFIG[kms] =
--enable-drm-compositor,--disable-drm-compositor,drm udev virtual/mesa
mtdev
# Weston on Wayland (nested Weston)
-PACKAGECONFIG[wayland] = --enable-wayland-compositor,--disable-egl
--disable-wayland-compositor,virtual/mesa
+PACKAGECONFIG[wayland] =
--enable-wayland-compositor,--disable-wayland-compositor,virtual/mesa
# Weston on X11
PACKAGECONFIG[x11] =
--enable-x11-compositor,--disable-x11-compositor,virtual/libx11 libxcb
libxcb libxcursor cairo
# Headless Weston
@@ -50,6 +49,10 @@ PACKAGECONFIG[fbdev] =
--enable-fbdev-compositor,--disable-fbdev-compositor,ude
PACKAGECONFIG[launch] =
--enable-weston-launch,--disable-weston-launch,libpam drm
# VA-API desktop recorder
PACKAGECONFIG[vaapi] =
--enable-vaapi-recorder,--disable-vaapi-recorder,libva
+# Weston with EGL support
+PACKAGECONFIG[egl] = --enable-egl
--enable-simple-egl-clients,--disable-egl
--disable-simple-egl-clients,virtual/egl
+# Weston with cairo glesv2 support
+PACKAGECONFIG[cairo-glesv2] =
--with-cairo-glesv2,--with-cairo=image,cairo
do_install_append() {
# Weston doesn't need the .la files to load modules, so wipe them
Looks good to me.
Sorry Otavio for the delay introduced by the discussions. Hope it will be
merged quickly and get your issue solved :)
No problem; it was for the better and ensures we have a full
understanding of it :-) Please 'ack' it if you can.
Acked-by: valentin.p...@intel.com.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/3] Replace ocf-linux with cryptodev-linux
On Wed, Mar 26, 2014 at 11:42:39AM -0300, Otavio Salvador wrote: Hello Kai, On Wed, Mar 26, 2014 at 7:15 AM, Kai Kang kai.k...@windriver.com wrote: Replace ocf-linux with cryptodev-linux because linux-yocto use cryptodev-linux to implement /dev/crypto. Thanks for handling it; I was going to address same issue this week so we could have it upstreamed and drop the Freescale bbappends for it. So, we also have a recipe of cryptodev for TI builds. But it's not just a header file and we need the actual module to be built and packaged... I'm rather surprised it was merged so quickly w/o further discussion... :( -- Denys -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/3] Replace ocf-linux with cryptodev-linux
On Fri, Mar 28, 2014 at 1:13 PM, Denys Dmytriyenko de...@denix.org wrote: On Wed, Mar 26, 2014 at 11:42:39AM -0300, Otavio Salvador wrote: Hello Kai, On Wed, Mar 26, 2014 at 7:15 AM, Kai Kang kai.k...@windriver.com wrote: Replace ocf-linux with cryptodev-linux because linux-yocto use cryptodev-linux to implement /dev/crypto. Thanks for handling it; I was going to address same issue this week so we could have it upstreamed and drop the Freescale bbappends for it. So, we also have a recipe of cryptodev for TI builds. But it's not just a header file and we need the actual module to be built and packaged... As long as something out of tree can co-exist with in-tree implementations, I don't see a problem with an incremental update that builds the module as well. Bruce I'm rather surprised it was merged so quickly w/o further discussion... :( -- Denys -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/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.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/6] initscripts: Avoid restarting rpcbind daemon
Hi Hongxu, Does this change fix a bug or an inappropriate system behavior? Thanks, Cristian Iorga YP Intel Corporation -Original Message- From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Hongxu Jia Sent: Friday, March 28, 2014 11:43 AM To: openembedded-core@lists.openembedded.org Cc: Wold, Saul Subject: [OE-core] [PATCH 3/6] initscripts: Avoid restarting rpcbind daemon From: Yue Tao yue@windriver.com Check whether rpcbind daemon already run before starting it. Signed-off-by: Yue Tao yue@windriver.com Signed-off-by: Robert Yang liezhi.y...@windriver.com Signed-off-by: Jeff Polk jeff.p...@windriver.com Signed-off-by: Hongxu Jia hongxu@windriver.com --- meta/recipes-core/initscripts/initscripts-1.0/mountnfs.sh | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/meta/recipes-core/initscripts/initscripts-1.0/mountnfs.sh b/meta/recipes-core/initscripts/initscripts-1.0/mountnfs.sh index fe6c196..be9f597 100755 --- a/meta/recipes-core/initscripts/initscripts-1.0/mountnfs.sh +++ b/meta/recipes-core/initscripts/initscripts-1.0/mountnfs.sh @@ -67,9 +67,12 @@ if test $rpcbind = yes then if test -x /usr/sbin/rpcbind then - echo -n Starting rpcbind... - start-stop-daemon --start --quiet --exec /usr/sbin/rpcbind - sleep 2 + service rpcbind status /dev/null + if [ $? != 0 ]; then + echo -n Starting rpcbind... + start-stop-daemon --start --quiet --exec /usr/sbin/rpcbind + sleep 2 + fi fi fi -- 1.8.1.2 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [RFC PATCH] Make ppce300c3 tune hard-float by default
The tuning file for PowerPC e300c3 is soft-float. In OE-classic it was
hard-float
and it should be as the c3 has an fpu. I have modified the tuning file to
include
both a hard-float version (using the existing ppce300c3 name) and an optional
soft-float version (called ppce300c3-nf).
The following patch also passes a --with-cpu=e300c3 argument to GLIBC.
For this to have any effect an Implies file must be added to the glibc/eglibc
source (tested with eglibc 2.18).
./ports/sysdeps/powerpc/powerpc32/e300c3/fpu/Implies:
--
# e300c3 is a variant of 603e so use the same optimizations for sqrt
powerpc/powerpc32/603e/fpu
--
Thanks to Khem Raj and Mark Hatle for their previous comments.
diff --git a/meta/conf/machine/include/tune-ppce300c3.inc
b/meta/conf/machine/include/tune-ppce300c3.inc
index 9431222..d11522b 100644
--- a/meta/conf/machine/include/tune-ppce300c3.inc
+++ b/meta/conf/machine/include/tune-ppce300c3.inc
@@ -2,10 +2,22 @@ DEFAULTTUNE ?= ppce300c3
require conf/machine/include/powerpc/arch-powerpc.inc
+AVAILTUNES += ppce300c3 ppce300c3-nf
+
+# hard-float
TUNEVALID[ppce300c3] = Enable ppce300c3 specific processor optimizations
+TUNE_FEATURES_tune-ppce300c3 = ${TUNE_FEATURES_tune-powerpc} ppce300c3
+TUNE_PKGARCH_tune-ppce300c3 = ppce300c3
+PACKAGE_EXTRA_ARCHS_tune-ppce300c3 = ${PACKAGE_EXTRA_ARCHS_tune-powerpc}
ppce300c3
TUNE_CCARGS .= ${@bb.utils.contains(TUNE_FEATURES, ppce300c3,
-mcpu=e300c3, , d)}
-AVAILTUNES += ppce300c3
-TUNE_FEATURES_tune-ppce300c3 = m32 fpu-soft ppce300c3
-TUNE_PKGARCH_tune-ppce300c3 = ppce300c3
-PACKAGE_EXTRA_ARCHS_tune-ppce300c3 = ${PACKAGE_EXTRA_ARCHS_tune-powerpc-nf}
ppce300c3
+# glibc configure options to make use of 603e specific sqrt/sqrtf routines
+GLIBC_EXTRA_OECONF += ${@bb.utils.contains(TUNE_FEATURES, ppce300c3,
--with-cpu=e300c3, , d)}
+
+# soft-float
+TUNEVALID[ppce300c3-nf] = Enable ppce300c3 specific processor optimizations
(no fpu)
+TUNE_FEATURES_tune-ppce300c3-nf = ${TUNE_FEATURES_tune-powerpc-nf}
ppce300c3-nf
+TUNE_PKGARCH_tune-ppce300c3-nf = ppce300c3-nf
+PACKAGE_EXTRA_ARCHS_tune-ppce300c3-nf =
${PACKAGE_EXTRA_ARCHS_tune-powerpc-nf} ppce300c3-nf
+TUNE_CCARGS .= ${@bb.utils.contains(TUNE_FEATURES, ppce300c3-nf,
-mcpu=e300c3, , d)}
+
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/3] Replace ocf-linux with cryptodev-linux
On Fri, 2014-03-28 at 13:13 -0400, Denys Dmytriyenko wrote: On Wed, Mar 26, 2014 at 11:42:39AM -0300, Otavio Salvador wrote: Hello Kai, On Wed, Mar 26, 2014 at 7:15 AM, Kai Kang kai.k...@windriver.com wrote: Replace ocf-linux with cryptodev-linux because linux-yocto use cryptodev-linux to implement /dev/crypto. Thanks for handling it; I was going to address same issue this week so we could have it upstreamed and drop the Freescale bbappends for it. So, we also have a recipe of cryptodev for TI builds. But it's not just a header file and we need the actual module to be built and packaged... I'm rather surprised it was merged so quickly w/o further discussion... :( From my perspective, the ocf version looked dead and I had several people saying this was the right thing to do with nobody saying otherwise, both here on list and in some conversations I had with people. With the release approaching, it was kind of late to do it equally, it did appear to be the right thing to switch to so I got on and tested and then merged it. I don't consider things set in stone, I think we can build upon this incrementally. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/5] packagegroups: Remove toolchain *-symlinks packages
On Fri, 2014-03-28 at 17:43 +0800, Hongxu Jia wrote: From: Mark Hatle mark.ha...@windriver.com We are no longer producing the *-symlinks packages, so remove the dependencies to those items. Signed-off-by: Mark Hatle mark.ha...@windriver.com Signed-off-by: Jeff Polk jeff.p...@windriver.com Signed-off-by: Hongxu Jia hongxu@windriver.com --- meta/recipes-core/packagegroups/packagegroup-core-buildessential.bb | 4 meta/recipes-core/packagegroups/packagegroup-self-hosted.bb | 4 2 files changed, 8 deletions(-) The binutils-symlinks package was removed however the gcc related ones have not been. This patch is therefore not appropriate until that has happened. Cheers, Richard diff --git a/meta/recipes-core/packagegroups/packagegroup-core-buildessential.bb b/meta/recipes-core/packagegroups/packagegroup-core-buildessential.bb index 74ed247..e21f8c1 100644 --- a/meta/recipes-core/packagegroups/packagegroup-core-buildessential.bb +++ b/meta/recipes-core/packagegroups/packagegroup-core-buildessential.bb @@ -12,13 +12,9 @@ RDEPENDS_packagegroup-core-buildessential = \ autoconf \ automake \ binutils \ -binutils-symlinks \ cpp \ -cpp-symlinks \ gcc \ -gcc-symlinks \ g++ \ -g++-symlinks \ gettext \ make \ libstdc++ \ diff --git a/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb b/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb index 8e3b917..5581d8e 100644 --- a/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb +++ b/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb @@ -69,20 +69,16 @@ RDEPENDS_packagegroup-self-hosted-sdk = \ autoconf \ automake \ binutils \ -binutils-symlinks \ ccache \ coreutils \ cpp \ -cpp-symlinks \ distcc \ eglibc-utils \ eglibc-gconv-ibm850 \ file \ findutils \ g++ \ -g++-symlinks \ gcc \ -gcc-symlinks \ intltool \ ldd \ less \ -- 1.8.1.2 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 10/13] linux-yocto/3.14: introduce versioned recipes
On 14-03-28 09:32 AM, Richard Purdie wrote:
On Fri, 2014-03-28 at 08:52 -0400, Bruce Ashfield wrote:
On 14-03-28 05:45 AM, Richard Purdie wrote:
On Thu, 2014-03-27 at 14:25 -0400, Bruce Ashfield wrote:
The release kernel for Yocto 1.5 is the 3.14 kernel, so we introduce
the versioned recipes here.
Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb | 21
meta/recipes-kernel/linux/linux-yocto_3.14.bb | 37
++
2 files changed, 58 insertions(+)
create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
create mode 100644 meta/recipes-kernel/linux/linux-yocto_3.14.bb
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
b/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
new file mode 100644
index ..8faa9584acf0
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
@@ -0,0 +1,21 @@
+require recipes-kernel/linux/linux-yocto.inc
+
+KBRANCH = standard/tiny/base
+LINUX_KERNEL_TYPE = tiny
+KCONFIG_MODE = --allnoconfig
+
+LINUX_VERSION ?= 3.14-rc8
+
+KMETA = meta
+
+SRCREV_machine ?= fecc3fd7d31bd93766ff4f0431fecdbbfa4c3a7c
+SRCREV_meta ?= 3689f99f4d2a051e8d3ff72345a67d4d04a88020
+
+PV = ${LINUX_VERSION}+git${SRCPV}
I'm afraid we can't do this in such a simple way. The big issue is that
according to our version comparison functions (in bitbake and in the
package managers), 3.14-rc8 3.14. This will then break updates
from package feeds.
The traditional way we've worked around this in times gone by is the
rather ugly:
PV = 3.13+3.14-rc8+git${SRCPV}
since in this case 3.14 3.13+3.14-rc8
The better way to handle this would be 3.14~rc8 however not all of our
package backends have support for ~ at this point so we can't do that.
There is a long standing bug open about this.
The same issue also applies to the libc-headers recipe.
. Since I don't do package feeds, it's never been a problem for me.
Wouldn't PE bump when I go to 3.14 work as well ? Or does that go away
with the PR sever as well ?
A PE bump would work however we try not to use those, they're a last
resort to correct things we can't otherwise fix. The PR server doesn't
help here although in future I do hope we can teach it about PE too.
I can muck with PV, or we can hold until Linus releases over the
weekend, and I go with the released PVs.
What's your preference ?
Might as well wait over the weekend. If Linus does go for a rc9, we'll
need to merge a version with the modified PV though.
In the meantime I might pull this series into master-next for testing
but it will not get added to master in its current form.
FWIW: I just fixed the PVs of libc-headers and linux-yocto_3.14 to be the
3.13+ variety.
All other comments are also incorporated and the branches repushed.
Outside of needing to override the TC libc headers default of 3.14 (that
I left
in, expecting the full update) in local.conf, all builds continue to
work.
Bruce
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] kernel-arch: Always use ld.bfd to link the kernel
On Tue, Apr 23, 2013 at 05:47:29PM +0100, Phil Blundell wrote:
The kernel's penchant for custom linker scripts means that it doesn't
generally get on very well with gold. Make sure we are using the BFD
linker here no matter what the distro default is set to.
Signed-off-by: Phil Blundell ph...@gnu.org
---
meta/classes/kernel-arch.bbclass |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/kernel-arch.bbclass
b/meta/classes/kernel-arch.bbclass
index b3b71ba..4a140eb 100644
--- a/meta/classes/kernel-arch.bbclass
+++ b/meta/classes/kernel-arch.bbclass
@@ -53,6 +53,6 @@ TARGET_AR_KERNEL_ARCH ?=
HOST_AR_KERNEL_ARCH ?= ${TARGET_AR_KERNEL_ARCH}
KERNEL_CC = ${CCACHE}${HOST_PREFIX}gcc ${HOST_CC_KERNEL_ARCH}
-KERNEL_LD = ${CCACHE}${HOST_PREFIX}ld ${HOST_LD_KERNEL_ARCH}
+KERNEL_LD = ${CCACHE}${HOST_PREFIX}ld.bfd ${HOST_LD_KERNEL_ARCH}
KERNEL_AR = ${CCACHE}${HOST_PREFIX}ar ${HOST_AR_KERNEL_ARCH}
I know this is almost a year-old change.
The question I have is - what should one do when using an external toolchain
that doesn't have ld.bfd provided? I know these days with gold vs. BFD linker,
it's common to have ld.bfd, but there could be exceptions...
Should this assignment be conditional, so it's easier to override from
local.conf or distro?
--
Denys
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/3] Replace ocf-linux with cryptodev-linux
On Fri, Mar 28, 2014 at 01:18:32PM -0400, Bruce Ashfield wrote: On Fri, Mar 28, 2014 at 1:13 PM, Denys Dmytriyenko de...@denix.org wrote: On Wed, Mar 26, 2014 at 11:42:39AM -0300, Otavio Salvador wrote: Hello Kai, On Wed, Mar 26, 2014 at 7:15 AM, Kai Kang kai.k...@windriver.com wrote: Replace ocf-linux with cryptodev-linux because linux-yocto use cryptodev-linux to implement /dev/crypto. Thanks for handling it; I was going to address same issue this week so we could have it upstreamed and drop the Freescale bbappends for it. So, we also have a recipe of cryptodev for TI builds. But it's not just a header file and we need the actual module to be built and packaged... As long as something out of tree can co-exist with in-tree implementations, I don't see a problem with an incremental update that builds the module as well. Thanks. So, I already have cryptodev-tests as a separate recipe that builds some tests from the same source, as main cryptodev. I guess I can look into separating module part into cryptodev-module recipe, which can be optional for kernels like linux-yocto that have it already patched in. Will that work? -- Denys -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Features in Yocto Project 1.7
Hello David, On Thu, Mar 27, 2014 at 7:47 AM, David Nyström david.nyst...@enea.com wrote: On 2014-03-25 15:31, David Nyström wrote: On 2014-03-24 17:00, Richard Purdie wrote: As development on 1.6 finishes up, its time to think about what we should be doing in the 1.7 cycle. I think from my perspective, in 1.7 I'd like to see us looking at Developer Workflow. Its a generic topic which I think covered multiple areas (in no particular order): * the ADT/SDK and how it intergrates into the rest of the system * toaster * python devshell * exteralsrc.bbclass * memory resident bitbake * how a standalone app developer might build an image +1 My wishlist: 1. Assembly of an image from a package repository using the SDK. 2. Ability to easily package multiple kernel flavours(builds with different kernel configs) with linux related bbclass:es. 3. layer based repository splitting. -- When having multiple users of a base repository. Ease management of customized repos, by having he ability to mark layers as split layers, this would yield a separate repo per split layer, which would contain packages modified/created by this layer. So you mean: * base package feed * meta-qt5 package feed and in case meta-qt5 adds a bbappend, in a existing recipe, what will be the behavior? Said packages would also be built for the base repo, but without split-layer modifications. A customized distro would use a compound of the base repo + split repo, where the split repo would have higher priority. I guess this could mean one deploy directory per split-layer. This part is easy as all package managers we use has support for it (I think) so it is a matter of proper generating those and add a method to include it in the image, the first part is the most complicated one I think... -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/3] Replace ocf-linux with cryptodev-linux
On Fri, Mar 28, 2014 at 05:22:14PM +, Richard Purdie wrote: On Fri, 2014-03-28 at 13:13 -0400, Denys Dmytriyenko wrote: On Wed, Mar 26, 2014 at 11:42:39AM -0300, Otavio Salvador wrote: Hello Kai, On Wed, Mar 26, 2014 at 7:15 AM, Kai Kang kai.k...@windriver.com wrote: Replace ocf-linux with cryptodev-linux because linux-yocto use cryptodev-linux to implement /dev/crypto. Thanks for handling it; I was going to address same issue this week so we could have it upstreamed and drop the Freescale bbappends for it. So, we also have a recipe of cryptodev for TI builds. But it's not just a header file and we need the actual module to be built and packaged... I'm rather surprised it was merged so quickly w/o further discussion... :( From my perspective, the ocf version looked dead and I had several people saying this was the right thing to do with nobody saying otherwise, both here on list and in some conversations I had with people. With the release approaching, it was kind of late to do it equally, it did appear to be the right thing to switch to so I got on and tested and then merged it. I don't consider things set in stone, I think we can build upon this incrementally. Thanks. I'll try to work an incremental solution, then, so it works for us and doesn't break other use cases - please see my reply to Bruce. -- Denys -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] [Dora] eglibc 2.18: powerpc: Fix time related syscalls
Concatenated fix of PowerPC time related system calls in eglibc 2.18 taken from upstream glibc. See credits in patch header. The effect is that some time related system calls returns nothing or garbage. Fix tested on PowerPC e300c3. Eglibc 2.17 does not have this issue and the patches are already part of 2.19. Upstream-Status: Backport Signed-off-by: Mats Karrman mats.karr...@tritech.se --- .../ppc-fix-time-related-syscalls.patch| 225 meta/recipes-core/eglibc/eglibc_2.18.bb|1 + 2 files changed, 226 insertions(+) create mode 100644 meta/recipes-core/eglibc/eglibc-2.18/ppc-fix-time-related-syscalls.patch V2: Added upstream status. diff --git a/meta/recipes-core/eglibc/eglibc-2.18/ppc-fix-time-related-syscalls.patch b/meta/recipes-core/eglibc/eglibc-2.18/ppc-fix-time-related-syscalls.patch new file mode 100644 index 000..fa1072b --- /dev/null +++ b/meta/recipes-core/eglibc/eglibc-2.18/ppc-fix-time-related-syscalls.patch @@ -0,0 +1,225 @@ +Concatenated fix of PowerPC time related system calls in eglibc 2.18 taken +from upstream glibc. Eglibc 2.17 does not have this issue and the patches are +already part of 2.19. +This compilation includes the following committs: + + +PowerPC: Fix vDSO missing ODP entries + +author Adhemerval Zanella azane...@linux.vnet.ibm.com + Thu, 7 Nov 2013 11:34:22 + (05:34 -0600) + +This patch fixes the vDSO symbol used directed in IFUNC resolver where +they do not have an associated ODP entry leading to undefined behavior +in some cases. It adds an artificial OPD static entry to such cases +and set its TOC to non 0 to avoid triggering lazy resolutions. + + +Update copyright notices with scripts/update-copyrights + +author Allan McRae al...@archlinux.org + Wed, 1 Jan 2014 11:03:15 + (21:03 +1000) + +((Only for files otherwise touched by this patch)) + + +PowerPC: Fix ftime gettimeofday internal call returning bogus data + +author Adhemerval Zanella azane...@linux.vnet.ibm.com + Thu, 16 Jan 2014 12:53:18 + (06:53 -0600) + +This patches fixes BZ#16430 by setting a different symbol for internal +GLIBC calls that points to ifunc resolvers. For PPC32, if the symbol +is defined as hidden (which is the case for gettimeofday and time) the +compiler will create local branches (symbol@local) and linker will not +create PLT calls (required for IFUNC). This will leads to internal symbol +calling the IFUNC resolver instead of the resolved symbol. +For PPC64 this behavior does not occur because a call to a function in +another translation unit might use a different toc pointer thus requiring +a PLT call. + + +PowerPC: Fix gettimeofday ifunc selection + +author Adhemerval Zanella azane...@linux.vnet.ibm.com + Mon, 20 Jan 2014 18:29:51 + (12:29 -0600) + +The IFUNC selector for gettimeofday runs before _libc_vdso_platform_setup where +__vdso_gettimeofday is set. The selector then sets __gettimeofday (the internal +version used within GLIBC) to use the system call version instead of the vDSO one. +This patch changes the check if vDSO is available to get its value directly +instead of rely on __vdso_gettimeofday. + +This patch changes it by getting the vDSO value directly. + +It fixes BZ#16431. + + +--- +diff -pruN libc.orig/sysdeps/unix/sysv/linux/powerpc/bits/libc-vdso.h libc/sysdeps/unix/sysv/linux/powerpc/bits/libc-vdso.h +--- libc.orig/sysdeps/unix/sysv/linux/powerpc/bits/libc-vdso.h libc/sysdeps/unix/sysv/linux/powerpc/bits/libc-vdso.h +@@ -1,5 +1,5 @@ + /* Resolve function pointers to VDSO functions. +- Copyright (C) 2005-2013 Free Software Foundation, Inc. ++ Copyright (C) 2005-2014 Free Software Foundation, Inc. +This file is part of the GNU C Library. + +The GNU C Library is free software; you can redistribute it and/or +@@ -34,12 +34,32 @@ extern void *__vdso_getcpu; + + extern void *__vdso_time; + +-/* This macro is needed for PPC64 to return a skeleton OPD entry of a vDSO +- symbol. This works because _dl_vdso_vsym always return the function +- address, and no vDSO symbols use the TOC or chain pointers from the OPD +- so we can allow them to be garbage. */ + #if defined(__PPC64__) || defined(__powerpc64__) +-#define VDSO_IFUNC_RET(value) ((void *) (value)) ++/* The correct solution is for _dl_vdso_vsym to return the address of the OPD ++ for the kernel VDSO function. That address would then be stored in the ++ __vdso_* variables and returned as the result of the IFUNC resolver function. ++ Yet, the kernel does not contain any OPD entries for the VDSO functions ++ (incomplete implementation). However, PLT relocations for IFUNCs still expect ++ the address of an OPD to be returned from the IFUNC resolver function (since ++ PLT entries on PPC64 are just copies of OPDs). The solution for now is to ++ create an artificial static OPD for each VDSO function returned by a resolver ++ function. The TOC value is
Re: [OE-core] [PATCH v2] weston : refactor to identify EGL, cairoglesv2 support
On 03/28/2014 04:02 PM, Otavio Salvador wrote:
From: Prabhu Sundararaj prabhu.sundara...@freescale.com
Signed-off-by: Prabhu Sundararaj prabhu.sundara...@freescale.com
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
meta/recipes-graphics/wayland/weston_1.4.0.bb | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-graphics/wayland/weston_1.4.0.bb
b/meta/recipes-graphics/wayland/weston_1.4.0.bb
index e0c354d..5213166 100644
--- a/meta/recipes-graphics/wayland/weston_1.4.0.bb
+++ b/meta/recipes-graphics/wayland/weston_1.4.0.bb
@@ -23,13 +23,12 @@ EXTRA_OECONF = --enable-setuid-install \
--enable-simple-clients \
--enable-clients \
--enable-demo-clients-install \
---disable-simple-egl-clients \
--disable-libunwind \
--disable-rpi-compositor \
--disable-rdp-compositor
-PACKAGECONFIG ??= ${@base_contains('DISTRO_FEATURES', 'wayland', 'kms fbdev wayland', '', d)} \
+PACKAGECONFIG ??= ${@base_contains('DISTRO_FEATURES', 'wayland', 'kms fbdev
wayland egl', '', d)} \
${@base_contains('DISTRO_FEATURES', 'x11', 'x11', '', d)} \
${@base_contains('DISTRO_FEATURES', 'pam', 'launch', '',
d)} \
@@ -39,7 +38,7 @@ PACKAGECONFIG ??= ${@base_contains('DISTRO_FEATURES',
'wayland', 'kms fbdev way
# Weston on KMS
PACKAGECONFIG[kms] = --enable-drm-compositor,--disable-drm-compositor,drm udev
virtual/mesa mtdev
# Weston on Wayland (nested Weston)
-PACKAGECONFIG[wayland] = --enable-wayland-compositor,--disable-egl
--disable-wayland-compositor,virtual/mesa
+PACKAGECONFIG[wayland] =
--enable-wayland-compositor,--disable-wayland-compositor,virtual/mesa
# Weston on X11
PACKAGECONFIG[x11] =
--enable-x11-compositor,--disable-x11-compositor,virtual/libx11 libxcb libxcb
libxcursor cairo
# Headless Weston
@@ -50,6 +49,10 @@ PACKAGECONFIG[fbdev] =
--enable-fbdev-compositor,--disable-fbdev-compositor,ude
PACKAGECONFIG[launch] = --enable-weston-launch,--disable-weston-launch,libpam
drm
# VA-API desktop recorder
PACKAGECONFIG[vaapi] =
--enable-vaapi-recorder,--disable-vaapi-recorder,libva
+# Weston with EGL support
+PACKAGECONFIG[egl] = --enable-egl --enable-simple-egl-clients,--disable-egl
--disable-simple-egl-clients,virtual/egl
+# Weston with cairo glesv2 support
+PACKAGECONFIG[cairo-glesv2] = --with-cairo-glesv2,--with-cairo=image,cairo
do_install_append() {
# Weston doesn't need the .la files to load modules, so wipe them
Looks good to me.
Sorry Otavio for the delay introduced by the discussions. Hope it will
be merged quickly and get your issue solved :)
Thanks!
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] [Dora] eglibc 2.18: powerpc: Fix time related syscalls
On Fri, 2014-03-28 at 12:56 +, Mats Kärrman wrote: Concatenated fix of PowerPC time related system calls in eglibc 2.18 taken from upstream glibc. See credits in patch header. The effect is that some time related system calls returns nothing or garbage. Tested on PowerPC e300c3. Eglibc 2.17 does not have this issue and the patches are already part of 2.19. Signed-off-by: Mats Karrman mats.karr...@tritech.se --- .../ppc-fix-time-related-syscalls.patch| 225 meta/recipes-core/eglibc/eglibc_2.18.bb|1 + 2 files changed, 226 insertions(+) create mode 100644 meta/recipes-core/eglibc/eglibc-2.18/ppc-fix-time-related-syscalls.patch diff --git a/meta/recipes-core/eglibc/eglibc-2.18/ppc-fix-time-related-syscalls.patch b/meta/recipes-core/eglibc/eglibc-2.18/ppc-fix-time-related-syscalls.patch new file mode 100644 index 000..fa1072b --- /dev/null +++ b/meta/recipes-core/eglibc/eglibc-2.18/ppc-fix-time-related-syscalls.patch @@ -0,0 +1,225 @@ +Concatenated fix of PowerPC time related system calls in eglibc 2.18 taken +from upstream glibc. Eglibc 2.17 does not have this issue and the patches are +already part of 2.19. +This compilation includes the following committs: + This needs an Upstream-Status: Backport somewhere in there. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/3] Replace ocf-linux with cryptodev-linux
On Fri, Mar 28, 2014 at 1:34 PM, Denys Dmytriyenko de...@denix.org wrote: On Fri, Mar 28, 2014 at 01:18:32PM -0400, Bruce Ashfield wrote: On Fri, Mar 28, 2014 at 1:13 PM, Denys Dmytriyenko de...@denix.org wrote: On Wed, Mar 26, 2014 at 11:42:39AM -0300, Otavio Salvador wrote: Hello Kai, On Wed, Mar 26, 2014 at 7:15 AM, Kai Kang kai.k...@windriver.com wrote: Replace ocf-linux with cryptodev-linux because linux-yocto use cryptodev-linux to implement /dev/crypto. Thanks for handling it; I was going to address same issue this week so we could have it upstreamed and drop the Freescale bbappends for it. So, we also have a recipe of cryptodev for TI builds. But it's not just a header file and we need the actual module to be built and packaged... As long as something out of tree can co-exist with in-tree implementations, I don't see a problem with an incremental update that builds the module as well. Thanks. So, I already have cryptodev-tests as a separate recipe that builds some tests from the same source, as main cryptodev. I guess I can look into separating module part into cryptodev-module recipe, which can be optional for kernels like linux-yocto that have it already patched in. Will that work? Absolutely. It's the same dance we do with lttng-modules, so we are on solid ground. Bruce -- Denys -- 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.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] [Dora] eglibc 2.18: powerpc: Fix time related syscalls
On Fri, 2014-03-28 at 14:41 +, Mats Kärrman wrote: Concatenated fix of PowerPC time related system calls in eglibc 2.18 taken from upstream glibc. See credits in patch header. The effect is that some time related system calls returns nothing or garbage. Fix tested on PowerPC e300c3. Eglibc 2.17 does not have this issue and the patches are already part of 2.19. Upstream-Status: Backport This needs to be in the header of the patch, not the commit message (so that when reading the patch later, someone can understand its status quickly). When I see people removing patches during package upgrades, I can also be happier when I see its a backport. Cheers, Richard Signed-off-by: Mats Karrman mats.karr...@tritech.se --- .../ppc-fix-time-related-syscalls.patch| 225 meta/recipes-core/eglibc/eglibc_2.18.bb|1 + 2 files changed, 226 insertions(+) create mode 100644 meta/recipes-core/eglibc/eglibc-2.18/ppc-fix-time-related-syscalls.patch V2: Added upstream status. diff --git a/meta/recipes-core/eglibc/eglibc-2.18/ppc-fix-time-related-syscalls.patch b/meta/recipes-core/eglibc/eglibc-2.18/ppc-fix-time-related-syscalls.patch new file mode 100644 index 000..fa1072b --- /dev/null +++ b/meta/recipes-core/eglibc/eglibc-2.18/ppc-fix-time-related-syscalls.patch @@ -0,0 +1,225 @@ +Concatenated fix of PowerPC time related system calls in eglibc 2.18 taken +from upstream glibc. Eglibc 2.17 does not have this issue and the patches are +already part of 2.19. +This compilation includes the following committs: + + +PowerPC: Fix vDSO missing ODP entries + +author Adhemerval Zanella azane...@linux.vnet.ibm.com + Thu, 7 Nov 2013 11:34:22 + (05:34 -0600) + +This patch fixes the vDSO symbol used directed in IFUNC resolver where +they do not have an associated ODP entry leading to undefined behavior +in some cases. It adds an artificial OPD static entry to such cases +and set its TOC to non 0 to avoid triggering lazy resolutions. + + +Update copyright notices with scripts/update-copyrights + +author Allan McRae al...@archlinux.org + Wed, 1 Jan 2014 11:03:15 + (21:03 +1000) + +((Only for files otherwise touched by this patch)) + + +PowerPC: Fix ftime gettimeofday internal call returning bogus data + +author Adhemerval Zanella azane...@linux.vnet.ibm.com + Thu, 16 Jan 2014 12:53:18 + (06:53 -0600) + +This patches fixes BZ#16430 by setting a different symbol for internal +GLIBC calls that points to ifunc resolvers. For PPC32, if the symbol +is defined as hidden (which is the case for gettimeofday and time) the +compiler will create local branches (symbol@local) and linker will not +create PLT calls (required for IFUNC). This will leads to internal symbol +calling the IFUNC resolver instead of the resolved symbol. +For PPC64 this behavior does not occur because a call to a function in +another translation unit might use a different toc pointer thus requiring +a PLT call. + + +PowerPC: Fix gettimeofday ifunc selection + +author Adhemerval Zanella azane...@linux.vnet.ibm.com + Mon, 20 Jan 2014 18:29:51 + (12:29 -0600) + +The IFUNC selector for gettimeofday runs before _libc_vdso_platform_setup where +__vdso_gettimeofday is set. The selector then sets __gettimeofday (the internal +version used within GLIBC) to use the system call version instead of the vDSO one. +This patch changes the check if vDSO is available to get its value directly +instead of rely on __vdso_gettimeofday. + +This patch changes it by getting the vDSO value directly. + +It fixes BZ#16431. + + +--- +diff -pruN libc.orig/sysdeps/unix/sysv/linux/powerpc/bits/libc-vdso.h libc/sysdeps/unix/sysv/linux/powerpc/bits/libc-vdso.h +--- libc.orig/sysdeps/unix/sysv/linux/powerpc/bits/libc-vdso.h libc/sysdeps/unix/sysv/linux/powerpc/bits/libc-vdso.h +@@ -1,5 +1,5 @@ + /* Resolve function pointers to VDSO functions. +- Copyright (C) 2005-2013 Free Software Foundation, Inc. ++ Copyright (C) 2005-2014 Free Software Foundation, Inc. +This file is part of the GNU C Library. + +The GNU C Library is free software; you can redistribute it and/or +@@ -34,12 +34,32 @@ extern void *__vdso_getcpu; + + extern void *__vdso_time; + +-/* This macro is needed for PPC64 to return a skeleton OPD entry of a vDSO +- symbol. This works because _dl_vdso_vsym always return the function +- address, and no vDSO symbols use the TOC or chain pointers from the OPD +- so we can allow them to be garbage. */ + #if defined(__PPC64__) || defined(__powerpc64__) +-#define VDSO_IFUNC_RET(value) ((void *) (value)) ++/* The correct solution is for _dl_vdso_vsym to return the address of the OPD ++ for the kernel VDSO function. That address would then be stored in the ++ __vdso_* variables and returned as the result of the
Re: [OE-core] [PATCH 3/5] packagegroup-self-hosted: Use packagegroup-core-buildessential
Hello all, This is an important patch, please make sure that BA still works correctly after this one gets merged (including properly building an image in BA). Thanks, Cristian Iorga YP Intel Corporation -Original Message- From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Hongxu Jia Sent: Friday, March 28, 2014 11:44 AM To: openembedded-core@lists.openembedded.org Cc: Wold, Saul Subject: [OE-core] [PATCH 3/5] packagegroup-self-hosted: Use packagegroup-core-buildessential From: Mark Hatle mark.ha...@windriver.com Instead of manually specifying build dependencies, use the packagegroup-core-buildessential. This ensures there is only one place that needs to be modified when toolchain items and dependencies change. Signed-off-by: Mark Hatle mark.ha...@windriver.com Signed-off-by: Jeff Polk jeff.p...@windriver.com Signed-off-by: Hongxu Jia hongxu@windriver.com --- meta/recipes-core/packagegroups/packagegroup-self-hosted.bb | 12 +--- 1 file changed, 1 insertion(+), 11 deletions(-) diff --git a/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb b/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb index 5581d8e..fe49fb4 100644 --- a/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb +++ b/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb @@ -66,33 +66,23 @@ RRECOMMENDS_packagegroup-self-hosted-host-tools = \ # eglibc-utils: for rpcgen RDEPENDS_packagegroup-self-hosted-sdk = \ -autoconf \ -automake \ -binutils \ ccache \ coreutils \ -cpp \ distcc \ eglibc-utils \ eglibc-gconv-ibm850 \ file \ findutils \ -g++ \ -gcc \ intltool \ ldd \ less \ libssp \ libssp-dev \ libssp-staticdev \ -libstdc++ \ -libstdc++-dev \ -libtool \ -make \ mktemp \ +packagegroup-core-buildessential \ perl-module-re \ perl-module-text-wrap \ -pkgconfig \ quilt \ sed \ -- 1.8.1.2 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] weston : refactor to identify EGL, cairoglesv2 support
From: Prabhu Sundararaj prabhu.sundara...@freescale.com
Signed-off-by: Prabhu Sundararaj prabhu.sundara...@freescale.com
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
meta/recipes-graphics/wayland/weston_1.4.0.bb | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-graphics/wayland/weston_1.4.0.bb
b/meta/recipes-graphics/wayland/weston_1.4.0.bb
index e0c354d..5213166 100644
--- a/meta/recipes-graphics/wayland/weston_1.4.0.bb
+++ b/meta/recipes-graphics/wayland/weston_1.4.0.bb
@@ -23,13 +23,12 @@ EXTRA_OECONF = --enable-setuid-install \
--enable-simple-clients \
--enable-clients \
--enable-demo-clients-install \
---disable-simple-egl-clients \
--disable-libunwind \
--disable-rpi-compositor \
--disable-rdp-compositor
-PACKAGECONFIG ??= ${@base_contains('DISTRO_FEATURES', 'wayland', 'kms fbdev
wayland', '', d)} \
+PACKAGECONFIG ??= ${@base_contains('DISTRO_FEATURES', 'wayland', 'kms fbdev
wayland egl', '', d)} \
${@base_contains('DISTRO_FEATURES', 'x11', 'x11', '', d)} \
${@base_contains('DISTRO_FEATURES', 'pam', 'launch', '',
d)} \
@@ -39,7 +38,7 @@ PACKAGECONFIG ??= ${@base_contains('DISTRO_FEATURES',
'wayland', 'kms fbdev way
# Weston on KMS
PACKAGECONFIG[kms] = --enable-drm-compositor,--disable-drm-compositor,drm
udev virtual/mesa mtdev
# Weston on Wayland (nested Weston)
-PACKAGECONFIG[wayland] = --enable-wayland-compositor,--disable-egl
--disable-wayland-compositor,virtual/mesa
+PACKAGECONFIG[wayland] =
--enable-wayland-compositor,--disable-wayland-compositor,virtual/mesa
# Weston on X11
PACKAGECONFIG[x11] =
--enable-x11-compositor,--disable-x11-compositor,virtual/libx11 libxcb libxcb
libxcursor cairo
# Headless Weston
@@ -50,6 +49,10 @@ PACKAGECONFIG[fbdev] =
--enable-fbdev-compositor,--disable-fbdev-compositor,ude
PACKAGECONFIG[launch] = --enable-weston-launch,--disable-weston-launch,libpam
drm
# VA-API desktop recorder
PACKAGECONFIG[vaapi] = --enable-vaapi-recorder,--disable-vaapi-recorder,libva
+# Weston with EGL support
+PACKAGECONFIG[egl] = --enable-egl --enable-simple-egl-clients,--disable-egl
--disable-simple-egl-clients,virtual/egl
+# Weston with cairo glesv2 support
+PACKAGECONFIG[cairo-glesv2] = --with-cairo-glesv2,--with-cairo=image,cairo
do_install_append() {
# Weston doesn't need the .la files to load modules, so wipe them
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] cryptodev-linux: add recipe
On Wed, Mar 26, 2014 at 06:15:57PM +0800, Kai Kang wrote:
Yocto kernel linux-yocto uses cryptodev-linux to use device /dev/crypto.
So add cryptodev-linux which is one alternative of ocf-linux and then
remove ocf-linux later.
Quick question - is it native-only recipe? Does it expect cryptodev module to
be patched into kernel? Is this what the above description implies -
linux-yocto uses cryptodev-linux?
From the looks of it, the recipe only installs a header and doesn't even build
the out-of-tree module for cryptodev, that cryptodev-linux provides...
Signed-off-by: Kai Kang kai.k...@windriver.com
---
.../openssl/cryptodev-linux_1.6.bb | 22
++
1 file changed, 22 insertions(+)
create mode 100644 meta/recipes-connectivity/openssl/cryptodev-linux_1.6.bb
diff --git a/meta/recipes-connectivity/openssl/cryptodev-linux_1.6.bb
b/meta/recipes-connectivity/openssl/cryptodev-linux_1.6.bb
new file mode 100644
index 000..320716d
--- /dev/null
+++ b/meta/recipes-connectivity/openssl/cryptodev-linux_1.6.bb
@@ -0,0 +1,22 @@
+SUMMARY = A /dev/crypto device driver
+HOMEPAGE = http://cryptodev-linux.org/;
+
+LICENSE = GPLv2
+LIC_FILES_CHKSUM = file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263
+
+SRC_URI = http://download.gna.org/cryptodev-linux/${BPN}-${PV}.tar.gz;
+
+SRC_URI[md5sum] = eade38998313c25fd7934719cdf8a2ea
+SRC_URI[sha256sum] =
75f1425c8ea1f8cae523905a5a046a35092327a6152800b0b86efc4e56fb3e2f
+
+do_compile() {
+ :
+}
+
+# Just install cryptodev.h which is the only header file needed to be
exported
+do_install() {
+ install -D ${S}/crypto/cryptodev.h ${D}${includedir}/crypto/cryptodev.h
+}
+
+ALLOW_EMPTY_${PN} = 1
+BBCLASSEXTEND = native nativesdk
--
1.8.1.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Features in Yocto Project 1.7
On 28 Mar 2014 16:24, Otavio Salvador ota...@ossystems.com.br wrote: Hello David, On Thu, Mar 27, 2014 at 7:47 AM, David Nyström david.nyst...@enea.com wrote: On 2014-03-25 15:31, David Nyström wrote: On 2014-03-24 17:00, Richard Purdie wrote: As development on 1.6 finishes up, its time to think about what we should be doing in the 1.7 cycle. I think from my perspective, in 1.7 I'd like to see us looking at Developer Workflow. Its a generic topic which I think covered multiple areas (in no particular order): * the ADT/SDK and how it intergrates into the rest of the system * toaster * python devshell * exteralsrc.bbclass * memory resident bitbake * how a standalone app developer might build an image +1 My wishlist: 1. Assembly of an image from a package repository using the SDK. 2. Ability to easily package multiple kernel flavours(builds with different kernel configs) with linux related bbclass:es. 3. layer based repository splitting. -- When having multiple users of a base repository. Ease management of customized repos, by having he ability to mark layers as split layers, this would yield a separate repo per split layer, which would contain packages modified/created by this layer. So you mean: * base package feed * meta-qt5 package feed and in case meta-qt5 adds a bbappend, in a existing recipe, what will be the behavior? If bbappending the bash recipe, f.ex. bash packages will be generated without meta-qt5 mods in base repo, and subsequently generated with qt5 mods in the meta-qt5 repo. //DD Said packages would also be built for the base repo, but without split-layer modifications. A customized distro would use a compound of the base repo + split repo, where the split repo would have higher priority. I guess this could mean one deploy directory per split-layer. This part is easy as all package managers we use has support for it (I think) so it is a matter of proper generating those and add a method to include it in the image, the first part is the most complicated one I think... -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libcap 2.22: fix, disable gperf detection
gperf straight invoke is not suitable for cross environment (gperf-native
should be used instead).
Formal patch has been submited to the upstream.
As libcap 2.24 is currently available, I prefer doing this quick fix.
Signed-off-by: Matthieu Crapet matthieu.cra...@ingenico.com
---
meta/recipes-support/libcap/libcap.inc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/recipes-support/libcap/libcap.inc
b/meta/recipes-support/libcap/libcap.inc
index ccc0fde..fef700a 100644
--- a/meta/recipes-support/libcap/libcap.inc
+++ b/meta/recipes-support/libcap/libcap.inc
@@ -24,6 +24,9 @@ do_configure() {
# on what should be replaced with ?=
sed -e 's,:=,?=,g' -i Make.Rules
sed -e 's,^BUILD_CFLAGS ?= $(.*CFLAGS),BUILD_CFLAGS :=
$(BUILD_CFLAGS),' -i Make.Rules
+
+ # disable gperf detection
+ sed -e '/shell gperf/cifeq (,yes)' -i libcap/Makefile
}
EXTRA_OEMAKE = \
--
1.8.5.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] weston : refactor to identify EGL, cairoglesv2 support
On Fri, Mar 28, 2014 at 10:28 AM, Valentin Popa valentin.p...@intel.com wrote:
On 03/28/2014 02:53 PM, Otavio Salvador wrote:
On Fri, Mar 28, 2014 at 9:23 AM, Valentin Popa valentin.p...@intel.com
wrote:
On 03/27/2014 08:09 PM, Otavio Salvador wrote:
On Thu, Mar 27, 2014 at 9:30 AM, Valentin Popa valentin.p...@intel.com
wrote:
On 03/26/2014 11:07 PM, Otavio Salvador wrote:
From: Prabhu Sundararaj prabhu.sundara...@freescale.com
Signed-off-by: Prabhu Sundararaj prabhu.sundara...@freescale.com
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
meta/recipes-graphics/wayland/weston_1.4.0.bb | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-graphics/wayland/weston_1.4.0.bb
b/meta/recipes-graphics/wayland/weston_1.4.0.bb
index e0c354d..a41b5cd 100644
--- a/meta/recipes-graphics/wayland/weston_1.4.0.bb
+++ b/meta/recipes-graphics/wayland/weston_1.4.0.bb
@@ -23,7 +23,6 @@ EXTRA_OECONF = --enable-setuid-install \
--enable-simple-clients \
--enable-clients \
--enable-demo-clients-install \
---disable-simple-egl-clients \
--disable-libunwind \
--disable-rpi-compositor \
--disable-rdp-compositor
@@ -39,7 +38,7 @@ PACKAGECONFIG ??=
${@base_contains('DISTRO_FEATURES',
'wayland', 'kms fbdev way
# Weston on KMS
PACKAGECONFIG[kms] =
--enable-drm-compositor,--disable-drm-compositor,drm udev
virtual/mesa
mtdev
# Weston on Wayland (nested Weston)
-PACKAGECONFIG[wayland] = --enable-wayland-compositor,--disable-egl
--disable-wayland-compositor,virtual/mesa
We need --disable-egl if wayland is not in DISTRO_FEATURES. See bug:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=5867
As egl is not part of PACKAGECONFIG it will do the right thing, no?
Yes, it will. My concerns are about --enable-drm-compositor (kms) without
egl; I know that the user can pass at runtime the --use-pixman flag, but
I
think it's more important to keep egl enabled by default in weston (this
is
probably the main usecase of wayland/weston). So if you enable egl, the
bug will reproduce.
The PACKAGECONFIG is for flexibility and so we are using it here as it
is designed. I understand we still don't have a way to map config
dependencies but this is no excuse to say the patch is wrong or
inappropriate.
We are using this in the upcoming i.MX6 Wayland support we sent to
meta-fsl-arm and the only blocker is this patch be accepted.
The patch is not wrong, but disables egl. Looks good to me and if merged
I'll submit a patch to add egl in PACKAGECONFIG.
If you want, I can add the egl there, and send v2. That's easy.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] weston : refactor to identify EGL, cairoglesv2 support
On Fri, Mar 28, 2014 at 11:02:37AM -0300, Otavio Salvador wrote:
From: Prabhu Sundararaj prabhu.sundara...@freescale.com
Signed-off-by: Prabhu Sundararaj prabhu.sundara...@freescale.com
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
meta/recipes-graphics/wayland/weston_1.4.0.bb | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-graphics/wayland/weston_1.4.0.bb
b/meta/recipes-graphics/wayland/weston_1.4.0.bb
index e0c354d..5213166 100644
--- a/meta/recipes-graphics/wayland/weston_1.4.0.bb
+++ b/meta/recipes-graphics/wayland/weston_1.4.0.bb
@@ -23,13 +23,12 @@ EXTRA_OECONF = --enable-setuid-install \
--enable-simple-clients \
--enable-clients \
--enable-demo-clients-install \
---disable-simple-egl-clients \
--disable-libunwind \
--disable-rpi-compositor \
--disable-rdp-compositor
-PACKAGECONFIG ??= ${@base_contains('DISTRO_FEATURES', 'wayland', 'kms fbdev
wayland', '', d)} \
+PACKAGECONFIG ??= ${@base_contains('DISTRO_FEATURES', 'wayland', 'kms fbdev
wayland egl', '', d)} \
${@base_contains('DISTRO_FEATURES', 'x11', 'x11', '', d)}
\
${@base_contains('DISTRO_FEATURES', 'pam', 'launch', '',
d)} \
@@ -39,7 +38,7 @@ PACKAGECONFIG ??= ${@base_contains('DISTRO_FEATURES',
'wayland', 'kms fbdev way
# Weston on KMS
PACKAGECONFIG[kms] = --enable-drm-compositor,--disable-drm-compositor,drm
udev virtual/mesa mtdev
# Weston on Wayland (nested Weston)
-PACKAGECONFIG[wayland] = --enable-wayland-compositor,--disable-egl
--disable-wayland-compositor,virtual/mesa
+PACKAGECONFIG[wayland] =
--enable-wayland-compositor,--disable-wayland-compositor,virtual/mesa
# Weston on X11
PACKAGECONFIG[x11] =
--enable-x11-compositor,--disable-x11-compositor,virtual/libx11 libxcb
libxcb libxcursor cairo
# Headless Weston
@@ -50,6 +49,10 @@ PACKAGECONFIG[fbdev] =
--enable-fbdev-compositor,--disable-fbdev-compositor,ude
PACKAGECONFIG[launch] =
--enable-weston-launch,--disable-weston-launch,libpam drm
# VA-API desktop recorder
PACKAGECONFIG[vaapi] =
--enable-vaapi-recorder,--disable-vaapi-recorder,libva
+# Weston with EGL support
+PACKAGECONFIG[egl] = --enable-egl --enable-simple-egl-clients,--disable-egl
--disable-simple-egl-clients,virtual/egl
+# Weston with cairo glesv2 support
+PACKAGECONFIG[cairo-glesv2] = --with-cairo-glesv2,--with-cairo=image,cairo
Thanks! This was something I was also looking at recently. I'll give it a shot
in my testing.
--
Denys
do_install_append() {
# Weston doesn't need the .la files to load modules, so wipe them
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] weston : refactor to identify EGL, cairoglesv2 support
On Fri, Mar 28, 2014 at 11:28 AM, Valentin Popa valentin.p...@intel.com wrote:
On 03/28/2014 03:55 PM, Otavio Salvador wrote:
On Fri, Mar 28, 2014 at 10:37 AM, Valentin Popa valentin.p...@intel.com
wrote:
On 03/28/2014 03:35 PM, Otavio Salvador wrote:
On Fri, Mar 28, 2014 at 10:28 AM, Valentin Popa
valentin.p...@intel.com
wrote:
On 03/28/2014 02:53 PM, Otavio Salvador wrote:
On Fri, Mar 28, 2014 at 9:23 AM, Valentin Popa
valentin.p...@intel.com
wrote:
On 03/27/2014 08:09 PM, Otavio Salvador wrote:
On Thu, Mar 27, 2014 at 9:30 AM, Valentin Popa
valentin.p...@intel.com
wrote:
On 03/26/2014 11:07 PM, Otavio Salvador wrote:
From: Prabhu Sundararaj prabhu.sundara...@freescale.com
Signed-off-by: Prabhu Sundararaj prabhu.sundara...@freescale.com
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
meta/recipes-graphics/wayland/weston_1.4.0.bb | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-graphics/wayland/weston_1.4.0.bb
b/meta/recipes-graphics/wayland/weston_1.4.0.bb
index e0c354d..a41b5cd 100644
--- a/meta/recipes-graphics/wayland/weston_1.4.0.bb
+++ b/meta/recipes-graphics/wayland/weston_1.4.0.bb
@@ -23,7 +23,6 @@ EXTRA_OECONF = --enable-setuid-install \
--enable-simple-clients \
--enable-clients \
--enable-demo-clients-install \
---disable-simple-egl-clients \
--disable-libunwind \
--disable-rpi-compositor \
--disable-rdp-compositor
@@ -39,7 +38,7 @@ PACKAGECONFIG ??=
${@base_contains('DISTRO_FEATURES',
'wayland', 'kms fbdev way
# Weston on KMS
PACKAGECONFIG[kms] =
--enable-drm-compositor,--disable-drm-compositor,drm udev
virtual/mesa
mtdev
# Weston on Wayland (nested Weston)
-PACKAGECONFIG[wayland] =
--enable-wayland-compositor,--disable-egl
--disable-wayland-compositor,virtual/mesa
We need --disable-egl if wayland is not in DISTRO_FEATURES. See
bug:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=5867
As egl is not part of PACKAGECONFIG it will do the right thing, no?
Yes, it will. My concerns are about --enable-drm-compositor (kms)
without
egl; I know that the user can pass at runtime the --use-pixman flag,
but
I
think it's more important to keep egl enabled by default in weston
(this
is
probably the main usecase of wayland/weston). So if you enable egl,
the
bug will reproduce.
The PACKAGECONFIG is for flexibility and so we are using it here as it
is designed. I understand we still don't have a way to map config
dependencies but this is no excuse to say the patch is wrong or
inappropriate.
We are using this in the upcoming i.MX6 Wayland support we sent to
meta-fsl-arm and the only blocker is this patch be accepted.
The patch is not wrong, but disables egl. Looks good to me and if
merged
I'll submit a patch to add egl in PACKAGECONFIG.
If you want, I can add the egl there, and send v2. That's easy.
That would be great. And don't forget to --disable-egl in case wayland is
not in PACKAGECONFIG.
This is the point I don't agree. I think user needs to drop egl when
dropping wayland.
Makes sens. So you need:
PACKAGECONFIG ??= ${@base_contains('DISTRO_FEATURES', 'wayland', 'egl kms
fbdev wayland', '', d)} \
I sent the v2; please take a look there.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] [RFC] udev-extraconf: update mount.sh to use /run/media instead of /media
From: Denys Dmytriyenko de...@ti.com
This is done to work around the issue of auto-mounting block devices
(i.e. SD cards) when root filesystem is still in read-only mode and
creating /media/device mount-points by udev is not possible. That
is due to udev (/etc/rcS.d/S03udev) getting started earlier than
checkroot (/etc/rcS.d/S10checkroot.sh) gets a chance to re-mount the
rootfs as read-write.
Although, canonical FHS specifies /media/device as a mount point
for removable media devices, the latest 2.3 version was released in
2004 and since then FreeDesktop/udisks and other tools adopted the
new /run/media/user/device location. That was done to overcome
read-only rootfs limitation, since /run is usually a tmpfs mounted
partition, plus avoid name-clash between users.
For our embedded systems environment we assume single-user operation
and hence simplify mount point to just /run/media/device.
Signed-off-by: Denys Dmytriyenko de...@ti.com
---
meta/recipes-core/udev/udev-extraconf/mount.sh | 14 +++---
meta/recipes-core/udev/udev-extraconf_1.0.bb | 2 +-
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/meta/recipes-core/udev/udev-extraconf/mount.sh
b/meta/recipes-core/udev/udev-extraconf/mount.sh
index cb57e47..3e4f21f 100644
--- a/meta/recipes-core/udev/udev-extraconf/mount.sh
+++ b/meta/recipes-core/udev/udev-extraconf/mount.sh
@@ -20,7 +20,7 @@ done
automount() {
name=`basename $DEVNAME`
- ! test -d /media/$name mkdir -p /media/$name
+ ! test -d /run/media/$name mkdir -p /run/media/$name
# Silent util-linux's version of mounting auto
if [ x`readlink $MOUNT` = x/bin/mount.util-linux ] ;
then
@@ -38,12 +38,12 @@ automount() {
;;
esac
- if ! $MOUNT -t auto $DEVNAME /media/$name
+ if ! $MOUNT -t auto $DEVNAME /run/media/$name
then
- #logger mount.sh/automount $MOUNT -t auto $DEVNAME
\/media/$name\ failed!
- rm_dir /media/$name
+ #logger mount.sh/automount $MOUNT -t auto $DEVNAME
\/run/media/$name\ failed!
+ rm_dir /run/media/$name
else
- logger mount.sh/automount Auto-mount of [/media/$name]
successful
+ logger mount.sh/automount Auto-mount of [/run/media/$name]
successful
touch /tmp/.automount-$name
fi
}
@@ -60,7 +60,7 @@ rm_dir() {
# No ID_FS_TYPE for cdrom device, yet it should be mounted
name=`basename $DEVNAME`
-[ -e /sys/block/$name/device/media ] media_type=`cat
/sys/block/$name/device/media`
+[ -e /sys/block/$name/device/run/media ] media_type=`cat
/sys/block/$name/device/run/media`
if [ $ACTION = add ] [ -n $DEVNAME ] [ -n $ID_FS_TYPE -o
$media_type = cdrom ]; then
if [ -x $PMOUNT ]; then
@@ -87,5 +87,5 @@ if [ $ACTION = remove ] [ -x $UMOUNT ] [ -n
$DEVNAME ]; then
# Remove empty directories from auto-mounter
name=`basename $DEVNAME`
- test -e /tmp/.automount-$name rm_dir /media/$name
+ test -e /tmp/.automount-$name rm_dir /run/media/$name
fi
diff --git a/meta/recipes-core/udev/udev-extraconf_1.0.bb
b/meta/recipes-core/udev/udev-extraconf_1.0.bb
index 3810b28..bae997c 100644
--- a/meta/recipes-core/udev/udev-extraconf_1.0.bb
+++ b/meta/recipes-core/udev/udev-extraconf_1.0.bb
@@ -4,7 +4,7 @@ LICENSE = MIT
LIC_FILES_CHKSUM =
file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d690 \
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420
-PR = r16
+PR = r17
SRC_URI = \
file://automount.rules \
--
1.8.3.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] weston : refactor to identify EGL, cairoglesv2 support
On Fri, Mar 28, 2014 at 9:23 AM, Valentin Popa valentin.p...@intel.com wrote:
On 03/27/2014 08:09 PM, Otavio Salvador wrote:
On Thu, Mar 27, 2014 at 9:30 AM, Valentin Popa valentin.p...@intel.com
wrote:
On 03/26/2014 11:07 PM, Otavio Salvador wrote:
From: Prabhu Sundararaj prabhu.sundara...@freescale.com
Signed-off-by: Prabhu Sundararaj prabhu.sundara...@freescale.com
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
meta/recipes-graphics/wayland/weston_1.4.0.bb | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-graphics/wayland/weston_1.4.0.bb
b/meta/recipes-graphics/wayland/weston_1.4.0.bb
index e0c354d..a41b5cd 100644
--- a/meta/recipes-graphics/wayland/weston_1.4.0.bb
+++ b/meta/recipes-graphics/wayland/weston_1.4.0.bb
@@ -23,7 +23,6 @@ EXTRA_OECONF = --enable-setuid-install \
--enable-simple-clients \
--enable-clients \
--enable-demo-clients-install \
---disable-simple-egl-clients \
--disable-libunwind \
--disable-rpi-compositor \
--disable-rdp-compositor
@@ -39,7 +38,7 @@ PACKAGECONFIG ??= ${@base_contains('DISTRO_FEATURES',
'wayland', 'kms fbdev way
# Weston on KMS
PACKAGECONFIG[kms] =
--enable-drm-compositor,--disable-drm-compositor,drm udev virtual/mesa
mtdev
# Weston on Wayland (nested Weston)
-PACKAGECONFIG[wayland] = --enable-wayland-compositor,--disable-egl
--disable-wayland-compositor,virtual/mesa
We need --disable-egl if wayland is not in DISTRO_FEATURES. See bug:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=5867
As egl is not part of PACKAGECONFIG it will do the right thing, no?
Yes, it will. My concerns are about --enable-drm-compositor (kms) without
egl; I know that the user can pass at runtime the --use-pixman flag, but I
think it's more important to keep egl enabled by default in weston (this is
probably the main usecase of wayland/weston). So if you enable egl, the
bug will reproduce.
The PACKAGECONFIG is for flexibility and so we are using it here as it
is designed. I understand we still don't have a way to map config
dependencies but this is no excuse to say the patch is wrong or
inappropriate.
We are using this in the upcoming i.MX6 Wayland support we sent to
meta-fsl-arm and the only blocker is this patch be accepted.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3 0/7] wic: Add --rootfs option to --source param
On Thu, 2014-03-27 at 19:07 -0300, João Henrique Ferreira de Freitas wrote: Hi, These patchs allows the user create the following directdisk-multi-rootfs.wks file: part /boot --source bootimg-pcbios --ondisk sda --fstype=msdos \ --label boot --active --align 1024 part / --source rootfs --ondisk sda --fstype=ext3 --label primary --align 1024 part /standby --source rootfs --rootfs-dir=special rootfs directory \ --ondisk sda --fstype=ext3 --label secondary --align 1024 bootloader --timeout=0 --append=rootwait rootfstype=ext3 video=vesafb vga=0x318 console=tty0 The special thing is the /standby partition. Which using rootfs with a extra '--rootfs' argument instruct the RootfsPlugin what should be the rootfs directory to be used to create the partition. Besides that, the user can specify a more generic connection between wic command-line --rootfs-dir and what is describing in .wks file. Like this: wic create ... --rootfs-dir rootfs1=/some/rootfs/dir --rootfs-dir rootfs2=/some/other/rootfs/dir part / --source rootfs --rootfs-dir=rootfs1 --ondisk sda --fstype=ext3 --label primary --align 1024 part /standby --source rootfs --rootfs-dir=rootfs2 \ --ondisk sda --fstype=ext3 --label secondary --align 1024 So no hard-coded path is used in .wks. The connection string could be any string that makes a link between the '--rootfs-dir' It is a very simple features that let users to customize your partition setup. I thought in the case where we have two rootfs (like active and standby, e.g used to software update). Or the odd cases when a special partition need to be create to hold whatever files. The workflow of wic use remains the same. All the config needs to be done in .wks file. To test I used special rootfs directory as a rootfs created by 'bitbkae core-image-minimal-dev' (e.g: /srv/build/yocto/master/tmp/work/genericx86-poky-linux/core-image-minimal-dev/1.0-r0/rootfs). Hi João, That helped a lot - I was able to get images generated using both the -e and explicitly specifying all the arguments using the directdisk-multi from before. So these worked fine: [trz@empanada build]$ wic create directdisk-multi -e core-image-minimal [trz@empanada build]$ wic create directdisk-multi -b /home/trz/yocto/master-cur/build/tmp/sysroots/crownbay/usr/share -k /home/trz/yocto/master-cur/build/tmp/sysroots/crownbay/usr/src/kernel -n /home/trz/yocto/master-cur/build/tmp/sysroots/x86_64-linux -r /home/trz/yocto/master-cur/build/tmp/work/crownbay-poky-linux/core-image-minimal/1.0-r0/rootfs/ Creating image(s)... When testing, I noticed a problem I introduced when adding the plugin support - I'll submit a patch for it, but the fix is here: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=tzanussi/wic-bitbake-env-fixid=222d52976466464a3ff184e07c0c884c8f821dbc Moving on to the generic connection versions, however, I still ran into problems. Here's the 'directdisk-multi-indirect-both.wks' file I used for that test: part /boot --source bootimg-pcbios --ondisk sda --fstype=msdos --label boot --active --align 1024 part / --source rootfs --rootfs-dir=rootfs1 --ondisk sda --fstype=ext3 --label platform --align 1024 part /standby --source rootfs --rootfs-dir=rootfs2 --ondisk sda --fstype=ext3 --label secondary --align 1024 bootloader --timeout=0 --append=rootwait rootfstype=ext3 video=vesafb vga=0x318 console=tty0 Both the -e and manual failed in the same way: [trz@empanada build]$ wic create directdisk-multi-indirect-both --rootfs-dir rootfs1=/home/trz/yocto/master-cur/build/tmp/work/crownbay-poky-linux/core-image-minimal/1.0-r0/rootfs/ --rootfs-dir rootfs2=/home/trz/yocto/master-cur/build/tmp/work/crownbay-poky-linux/core-image-minimal/1.0-r0/rootfs/ -e core-image-minimal Checking basic build environment... Done. Creating image(s)... Traceback (most recent call last): File /home/trz/yocto/master-cur/scripts/wic, line 254, in module ret = main() File /home/trz/yocto/master-cur/scripts/wic, line 249, in main invoke_subcommand(args, parser, wic_help_usage, subcommands) File /home/trz/yocto/master-cur/scripts/lib/image/help.py, line 73, in invoke_subcommand subcommands.get(args[0], subcommand_error)[0](args[1:], usage) File /home/trz/yocto/master-cur/scripts/wic, line 199, in wic_create_subcommand image_output_dir, options.debug, options.properties_file) File /home/trz/yocto/master-cur/scripts/lib/image/engine.py, line 246, in wic_create cr.main(direct_args) KeyError: 'ROOTFS_DIR' [trz@empanada build]$ wic create directdisk-multi-indirect-both -b /home/trz/yocto/master-cur/build/tmp/sysroots/crownbay/usr/share -k /home/trz/yocto/master-cur/build/tmp/sysroots/crownbay/usr/src/kernel -n /home/trz/yocto/master-cur/build/tmp/sysroots/x86_64-linux --rootfs-dir rootfs1=/home/trz/yocto/master-cur/build/tmp/work/crownbay-poky-linux/core-image-minimal/1.0-r0/rootfs/
[OE-core] [PATCH 0/1] wic: env-command bugfix
While testing some new wic functionality, I noticed a bug I introduced when adding the plugin support, which this fixes. The following changes since commit 8c3eb5ee4582b6f6d489549290937657f37fc19e: packagegroup-toolset-native: Update after ocf-linux - cryptodev-linux change (2014-03-27 19:53:30 +) are available in the git repository at: git://git.yoctoproject.org/poky-contrib.git tzanussi/wic-bitbake-env-fix http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=tzanussi/wic-bitbake-env-fix Tom Zanussi (1): wic: Fix bitbake_env_command for 'None' case scripts/lib/image/engine.py | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) -- 1.8.3.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] wic: Fix bitbake_env_command for 'None' case
bitbake_env_command will choke if it isn't given an image, make sure it does the right thing in that case. Signed-off-by: Tom Zanussi tom.zanu...@linux.intel.com --- scripts/lib/image/engine.py | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/scripts/lib/image/engine.py b/scripts/lib/image/engine.py index 6cf6169..0643780 100644 --- a/scripts/lib/image/engine.py +++ b/scripts/lib/image/engine.py @@ -65,7 +65,10 @@ def find_bitbake_env_lines(image_name): If image_name is empty, plugins might still be able to use the environment, so set it regardless. -bitbake_env_cmd = bitbake -e %s % image_name +if image_name: +bitbake_env_cmd = bitbake -e %s % image_name +else: +bitbake_env_cmd = bitbake -e rc, bitbake_env_lines = exec_cmd(bitbake_env_cmd) if rc != 0: print Couldn't get '%s' output. % bitbake_env_cmd -- 1.8.3.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v4 0/7] wic: Add --rootfs option to --source param
Hi, These patchs allows the user create the following directdisk-multi-rootfs.wks file: part /boot --source bootimg-pcbios --ondisk sda --fstype=msdos \ --label boot --active --align 1024 part / --source rootfs --ondisk sda --fstype=ext3 --label primary --align 1024 part /standby --source rootfs --rootfs-dir=special rootfs directory \ --ondisk sda --fstype=ext3 --label secondary --align 1024 bootloader --timeout=0 --append=rootwait rootfstype=ext3 video=vesafb vga=0x318 console=tty0 The special thing is the /standby partition. Which using rootfs with a extra '--rootfs' argument instruct the RootfsPlugin what should be the rootfs directory to be used to create the partition. Besides that, the user can specify a more generic connection between wic command-line --rootfs-dir and what is describing in .wks file. Like this: wic create ... --rootfs-dir rootfs1=/some/rootfs/dir --rootfs-dir rootfs2=/some/other/rootfs/dir part / --source rootfs --rootfs-dir=rootfs1 --ondisk sda --fstype=ext3 --label primary --align 1024 part /standby --source rootfs --rootfs-dir=rootfs2 \ --ondisk sda --fstype=ext3 --label secondary --align 1024 So no hard-coded path is used in .wks. The connection string could be any string that makes a link between the '--rootfs-dir' It is a very simple features that let users to customize your partition setup. I thought in the case where we have two rootfs (like active and standby, e.g used to software update). Or the odd cases when a special partition need to be create to hold whatever files. The workflow of wic use remains the same. All the config needs to be done in .wks file. To test I used special rootfs directory as a rootfs created by 'bitbkae core-image-minimal-dev' (e.g: /srv/build/yocto/master/tmp/work/genericx86-poky-linux/core-image-minimal-dev/1.0-r0/rootfs). Use cases and command line: wic create directdisk-multi-rootfs.wks \ -e core-image-minimal --rootfs-dir /srv/build/yocto/master/tmp/work/genericx86-poky-linux/core-image-minimal/1.0-r0/rootfs \ --rootfs-dir rootfs2=/srv/build/yocto/master/tmp/work/genericx86-poky-linux/core-image-minimal-dev/1.0-r0/rootfs \ --rootfs-dir rootfs3=/tmp/fakerootfs directdisk-multi-rootfs.wks: part /boot --source bootimg-pcbios --ondisk sda --fstype=msdos --label boot --active --align 1024 part / --source rootfs --ondisk sda --fstype=ext3 --label primary --align 1024 part /standby --source rootfs --rootfs-dir=rootfs2 --ondisk sda --fstype=ext3 --label secondary --align 1024 part /root --source rootfs --rootfs-dir=rootfs3 --ondisk sda --fstype=ext3 --label root_sec --align 1024 bootloader --timeout=0 --append=rootwait rootfstype=ext3 video=vesafb vga=0x318 console=tty0 wic create directdisk-multi-rootfs-indirect.wks \ -e core-image-minimal \ --rootfs-dir rootfs1=/srv/build/yocto/master/tmp/work/genericx86-poky-linux/core-image-minimal/1.0-r0/rootfs \ --rootfs-dir rootfs2=/srv/build/yocto/master/tmp/work/genericx86-poky-linux/core-image-minimal-dev/1.0-r0/rootfs \ --rootfs-dir rootfs3=/tmp/fakerootfs directdisk-multi-rootfs-indirect.wks: part /boot --source bootimg-pcbios --ondisk sda --fstype=msdos --label boot --active --align 1024 part / --source rootfs --rootfs=rootfs1 --ondisk sda --fstype=ext3 --label primary --align 1024 part /standby --source rootfs --rootfs-dir=rootfs2 --ondisk sda --fstype=ext3 --label secondary --align 1024 part /root --source rootfs --rootfs-dir=rootfs3 --ondisk sda --fstype=ext3 --label root_sec --align 1024 bootloader --timeout=0 --append=rootwait rootfstype=ext3 video=vesafb vga=0x318 console=tty0 changes since previous version: v2: - in .wks syntax change --rootfs to --rootfs-dir - reporting all extra partitions in the output - use a connection string between --rootfs-dir from wic command-line and .wks v3: - fix when wic -e command-line param is used and no --rootfs-dir was passed v4: - fix fstab parser/create when --rootfs-dir connector is used and there was not passed a --rootfs-dir param on wic command line - fix wic command line param when used without --rootfs-dir and only --rootfs-dir connectors are passed João Henrique Ferreira de Freitas (7): wic: Add RootfsPlugin wic: Hook up RootfsPlugin plugin wic: Add rootfs_dir argument to do_prepare_partition() method wic: Use partition label to be part of rootfs filename wic: Add option --rootfs-dir to --source wic: Report all ROOTFS_DIR artifacts wic: Extend --rootfs-dir to connect rootfs-dirs scripts/lib/mic/imager/direct.py | 36 +++ .../lib/mic/kickstart/custom_commands/partition.py | 51 ++-- scripts/lib/mic/pluginbase.py | 2 +- scripts/lib/mic/plugins/imager/direct_plugin.py| 17 +- scripts/lib/mic/plugins/source/bootimg-efi.py | 2 +- scripts/lib/mic/plugins/source/bootimg-pcbios.py | 2 +-
[OE-core] [PATCH v4 1/7] wic: Add RootfsPlugin
Implement RootfsPlugin class. The do_prepare_partition() method is implemented using code in Wic_PartData class. This class have 'rootfs' name, which is the name that should be used in the --source parameters of the .wks partition commands. Signed-off-by: João Henrique Ferreira de Freitas joa...@gmail.com --- scripts/lib/mic/plugins/source/rootfs.py | 58 1 file changed, 58 insertions(+) create mode 100644 scripts/lib/mic/plugins/source/rootfs.py diff --git a/scripts/lib/mic/plugins/source/rootfs.py b/scripts/lib/mic/plugins/source/rootfs.py new file mode 100644 index 000..da7aa0b --- /dev/null +++ b/scripts/lib/mic/plugins/source/rootfs.py @@ -0,0 +1,58 @@ +# ex:ts=4:sw=4:sts=4:et +# -*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*- +# +# Copyright (c) 2014, Intel Corporation. +# All rights reserved. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License version 2 as +# published by the Free Software Foundation. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License along +# with this program; if not, write to the Free Software Foundation, Inc., +# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. +# +# DESCRIPTION +# This implements the 'rootfs' source plugin class for 'wic' +# +# AUTHORS +# Tom Zanussi tom.zanussi (at] linux.intel.com +# Joao Henrique Ferreira de Freitas joaohf (at] gmail.com +# + +import os +import shutil +import re +import tempfile + +from mic import kickstart, chroot, msger +from mic.utils import misc, fs_related, errors, runner, cmdln +from mic.conf import configmgr +from mic.plugin import pluginmgr +from mic.utils.partitionedfs import PartitionedMount +import mic.imager.direct as direct +from mic.pluginbase import SourcePlugin +from mic.utils.oe.misc import * +from mic.imager.direct import DirectImageCreator + +class RootfsPlugin(SourcePlugin): +name = 'rootfs' + +@classmethod +def do_prepare_partition(self, part, cr, cr_workdir, oe_builddir, bootimg_dir, + kernel_dir, rootfs_dir, native_sysroot): + +Called to do the actual content population for a partition i.e. it +'prepares' the partition to be incorporated into the image. +In this case, prepare content for legacy bios boot partition. + +if part.rootfs: +rootfs_dir = part.rootfs + +part.prepare_rootfs(cr_workdir, oe_builddir, rootfs_dir, native_sysroot) + -- 1.8.3.2 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v4 5/7] wic: Add option --rootfs-dir to --source
The '--rootfs-dir' option is optional and only takes efect is a partition is set up like this: part /standby --source rootfs --rootfs-dir=special rootfs ... So '--rootfs-dir' is used instead of bitbake ROOTFS_DIR variable or '-r' param. Signed-off-by: João Henrique Ferreira de Freitas joa...@gmail.com --- scripts/lib/mic/kickstart/custom_commands/partition.py | 6 ++ 1 file changed, 6 insertions(+) diff --git a/scripts/lib/mic/kickstart/custom_commands/partition.py b/scripts/lib/mic/kickstart/custom_commands/partition.py index 8973edc..887195f 100644 --- a/scripts/lib/mic/kickstart/custom_commands/partition.py +++ b/scripts/lib/mic/kickstart/custom_commands/partition.py @@ -45,6 +45,7 @@ class Wic_PartData(Mic_PartData): Mic_PartData.__init__(self, *args, **kwargs) self.deleteRemovedAttrs() self.source = kwargs.get(source, None) +self.rootfs = kwargs.get(rootfs-dir, None) self.source_file = self.size = 0 @@ -53,6 +54,8 @@ class Wic_PartData(Mic_PartData): if self.source: retval += --source=%s % self.source +if self.rootfs: +retval += --rootfs-dir=%s % self.rootfs return retval @@ -332,4 +335,7 @@ class Wic_Partition(Mic_Partition): # and calculate partition size op.add_option(--source, type=string, action=store, dest=source, default=None) +# use specified rootfs path to fill the partition +op.add_option(--rootfs-dir, type=string, action=store, + dest=rootfs, default=None) return op -- 1.8.3.2 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v4 7/7] wic: Extend --rootfs-dir to connect rootfs-dirs
The wic command-line param --rootfs-dir gets generalized to support
multiple directories. Each '--rootfs-dir' could be connected using a
special string, that should be present in .wks. I.e:
wic create ... --rootfs-dir rootfs1=/some/rootfs/dir \
--rootfs-dir rootfs2=/some/other/rootfs/dir
part / --source rootfs --rootfs-dir=rootfs1 --ondisk sda --fstype=ext3 \
--label primary --align 1024
part /standby --source rootfs --rootfs-dir=rootfs2 \
--ondisk sda --fstype=ext3 --label secondary --align 1024
The user could use harded-code directory instead of connectors. Like this:
wic create ... hard-coded-path.wks -r /some/rootfs/dir
part / --source rootfs --ondisk sda --fstype=ext3 --label primary --align 1024
part /standby --source rootfs --rootfs-dir=/some/rootfs/dir \
--ondisk sda --fstype=ext3 --label secondary --align 1024
Signed-off-by: João Henrique Ferreira de Freitas joa...@gmail.com
---
scripts/lib/mic/imager/direct.py| 18 ++-
scripts/lib/mic/plugins/imager/direct_plugin.py | 17 ++-
scripts/lib/mic/plugins/source/rootfs.py| 20 ++---
scripts/wic | 40 +++--
4 files changed, 80 insertions(+), 15 deletions(-)
diff --git a/scripts/lib/mic/imager/direct.py b/scripts/lib/mic/imager/direct.py
index ac63c38..2cf4c8d 100644
--- a/scripts/lib/mic/imager/direct.py
+++ b/scripts/lib/mic/imager/direct.py
@@ -84,17 +84,19 @@ class DirectImageCreator(BaseImageCreator):
self.hdddir = hdddir
self.staging_data_dir = staging_data_dir
-def __write_fstab(self):
+def __write_fstab(self, image_rootfs):
overriden to generate fstab (temporarily) in rootfs. This
is called from mount_instroot, make sure it doesn't get called
from BaseImage.mount()
+if image_rootfs is None:
+return None
-image_rootfs = self.rootfs_dir
+fstab = image_rootfs + /etc/fstab
+if not os.path.isfile(fstab):
+return None
parts = self._get_parts()
-fstab = image_rootfs + /etc/fstab
-
self._save_fstab(fstab)
fstab_lines = self._get_fstab(fstab, parts)
self._update_fstab(fstab_lines, parts)
@@ -126,6 +128,8 @@ class DirectImageCreator(BaseImageCreator):
def _restore_fstab(self, fstab):
Restore the saved fstab in rootfs
+if fstab is None:
+return
shutil.move(fstab + .orig, fstab)
def _get_fstab(self, fstab, parts):
@@ -235,8 +239,6 @@ class DirectImageCreator(BaseImageCreator):
self.__instimage = PartitionedMount(self._instroot)
-fstab = self.__write_fstab()
-
for p in parts:
# as a convenience, set source to the boot partition source
# instead of forcing it to be set via bootloader --source
@@ -263,6 +265,9 @@ class DirectImageCreator(BaseImageCreator):
p.prepare(self, self.workdir, self.oe_builddir, self.rootfs_dir,
self.bootimg_dir, self.kernel_dir, self.native_sysroot)
+fstab = self.__write_fstab(p.get_rootfs())
+self._restore_fstab(fstab)
+
self.__instimage.add_partition(int(p.size),
p.disk,
p.mountpoint,
@@ -273,7 +278,6 @@ class DirectImageCreator(BaseImageCreator):
boot = p.active,
align = p.align,
part_type = p.part_type)
-self._restore_fstab(fstab)
self.__instimage.layout_partitions(self._ptable_format)
self.__imgdir = self.workdir
diff --git a/scripts/lib/mic/plugins/imager/direct_plugin.py
b/scripts/lib/mic/plugins/imager/direct_plugin.py
index e015256..fc7c10c 100644
--- a/scripts/lib/mic/plugins/imager/direct_plugin.py
+++ b/scripts/lib/mic/plugins/imager/direct_plugin.py
@@ -43,6 +43,19 @@ class DirectPlugin(ImagerPlugin):
name = 'direct'
@classmethod
+def __rootfs_dir_to_dict(self, rootfs_dirs):
+
+Gets a string that contain 'connection=dir' splitted by
+space and return a dict
+
+krootfs_dir = {}
+for rootfs_dir in rootfs_dirs.split(' '):
+k, v = rootfs_dir.split('=')
+krootfs_dir[k] = v
+
+return krootfs_dir
+
+@classmethod
def do_create(self, subcmd, opts, *args):
Create direct image, called from creator as 'direct' cmd
@@ -63,11 +76,13 @@ class DirectPlugin(ImagerPlugin):
image_output_dir = args[7]
oe_builddir = args[8]
+krootfs_dir = self.__rootfs_dir_to_dict(rootfs_dir)
+
configmgr._ksconf = ksconf
creator = direct.DirectImageCreator(oe_builddir,
image_output_dir,
-
[OE-core] [PATCH v4 4/7] wic: Use partition label to be part of rootfs filename
When a partition from .wks file is set up like this: part /standby --source rootfs --rootfs-dir=special rootfs ... --label \ --label secondary This means that 'rootfs' must use 'special rootfs' as rootfs and the default partition filename in /var/tmp/wic/build/ will be create using the '--label' as part of the name. E.g: /var/tmp/wic/build/rootfs_secondary.ext3 Signed-off-by: João Henrique Ferreira de Freitas joa...@gmail.com --- scripts/lib/mic/kickstart/custom_commands/partition.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/lib/mic/kickstart/custom_commands/partition.py b/scripts/lib/mic/kickstart/custom_commands/partition.py index c3bb9a5..8973edc 100644 --- a/scripts/lib/mic/kickstart/custom_commands/partition.py +++ b/scripts/lib/mic/kickstart/custom_commands/partition.py @@ -172,7 +172,7 @@ class Wic_PartData(Mic_PartData): image_rootfs = rootfs_dir -rootfs = %s/rootfs.%s % (cr_workdir, self.fstype) +rootfs = %s/rootfs_%s.%s % (cr_workdir, self.label ,self.fstype) du_cmd = du -ks %s % image_rootfs rc, out = exec_cmd(du_cmd) @@ -217,7 +217,7 @@ class Wic_PartData(Mic_PartData): Currently handles ext2/3/4 and btrfs. image_rootfs = rootfs_dir -rootfs = %s/rootfs.%s % (cr_workdir, self.fstype) +rootfs = %s/rootfs_%s.%s % (cr_workdir, self.label, self.fstype) du_cmd = du -ks %s % image_rootfs rc, out = exec_cmd(du_cmd) -- 1.8.3.2 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v4 6/7] wic: Report all ROOTFS_DIR artifacts
When a .wks has more than one ROOTFS_DIR it's better to report all ROOTFS_DIR that was used to create the image. Signed-off-by: João Henrique Ferreira de Freitas joa...@gmail.com --- scripts/lib/mic/imager/direct.py | 18 ++ scripts/lib/mic/kickstart/custom_commands/partition.py | 13 + scripts/lib/mic/plugins/source/rootfs.py | 1 + 3 files changed, 28 insertions(+), 4 deletions(-) diff --git a/scripts/lib/mic/imager/direct.py b/scripts/lib/mic/imager/direct.py index 1f2f8fc..ac63c38 100644 --- a/scripts/lib/mic/imager/direct.py +++ b/scripts/lib/mic/imager/direct.py @@ -321,15 +321,25 @@ class DirectImageCreator(BaseImageCreator): msg = The new image(s) can be found here:\n +parts = self._get_parts() + for disk_name, disk in self.__instimage.disks.items(): full_path = self._full_path(self.__imgdir, disk_name, direct) msg += ' %s\n\n' % full_path msg += 'The following build artifacts were used to create the image(s):\n' -msg += ' ROOTFS_DIR: %s\n' % self.rootfs_dir -msg += ' BOOTIMG_DIR: %s\n' % self.bootimg_dir -msg += ' KERNEL_DIR: %s\n' % self.kernel_dir -msg += ' NATIVE_SYSROOT: %s\n' % self.native_sysroot +for p in parts: +if p.get_rootfs() is None: +continue +if p.mountpoint == '/': +str = ':' +else: +str = '[%s]:' % p.label +msg += ' ROOTFS_DIR%s%s\n' % (str.ljust(20), p.get_rootfs()) + +msg += ' BOOTIMG_DIR: %s\n' % self.bootimg_dir +msg += ' KERNEL_DIR: %s\n' % self.kernel_dir +msg += ' NATIVE_SYSROOT: %s\n' % self.native_sysroot msger.info(msg) diff --git a/scripts/lib/mic/kickstart/custom_commands/partition.py b/scripts/lib/mic/kickstart/custom_commands/partition.py index 887195f..6b575c0 100644 --- a/scripts/lib/mic/kickstart/custom_commands/partition.py +++ b/scripts/lib/mic/kickstart/custom_commands/partition.py @@ -59,6 +59,19 @@ class Wic_PartData(Mic_PartData): return retval +def get_rootfs(self): + +Acessor for rootfs dir + +return self.rootfs + +def set_rootfs(self, rootfs): + +Acessor for actual rootfs dir, which must be set by source +plugins. + +self.rootfs = rootfs + def get_size(self): Accessor for partition size, 0 or --size before set_size(). diff --git a/scripts/lib/mic/plugins/source/rootfs.py b/scripts/lib/mic/plugins/source/rootfs.py index da7aa0b..83aec45 100644 --- a/scripts/lib/mic/plugins/source/rootfs.py +++ b/scripts/lib/mic/plugins/source/rootfs.py @@ -54,5 +54,6 @@ class RootfsPlugin(SourcePlugin): if part.rootfs: rootfs_dir = part.rootfs +part.set_rootfs(rootfs_dir) part.prepare_rootfs(cr_workdir, oe_builddir, rootfs_dir, native_sysroot) -- 1.8.3.2 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v4 3/7] wic: Add rootfs_dir argument to do_prepare_partition() method
The do_prepare_partition() method from RootfsPlugin class need to know what will be the rootfs_dir. This makes sense when .wks file has a partition set up like this: part /standby --source rootfs --rootfs-dir=special rootfs ... then do_prepare_partition() will work with the correct rootfs. Signed-off-by: João Henrique Ferreira de Freitas joa...@gmail.com --- scripts/lib/mic/pluginbase.py| 2 +- scripts/lib/mic/plugins/source/bootimg-efi.py| 2 +- scripts/lib/mic/plugins/source/bootimg-pcbios.py | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/scripts/lib/mic/pluginbase.py b/scripts/lib/mic/pluginbase.py index e26b525..9cf4c62 100644 --- a/scripts/lib/mic/pluginbase.py +++ b/scripts/lib/mic/pluginbase.py @@ -126,7 +126,7 @@ class SourcePlugin(_Plugin): @classmethod def do_prepare_partition(self, part, cr, cr_workdir, oe_builddir, bootimg_dir, - kernel_dir, native_sysroot): + kernel_dir, rootfs_dir, native_sysroot): Called to do the actual content population for a partition i.e. it 'prepares' the partition to be incorporated into the image. diff --git a/scripts/lib/mic/plugins/source/bootimg-efi.py b/scripts/lib/mic/plugins/source/bootimg-efi.py index 1974b06..2cc179a 100644 --- a/scripts/lib/mic/plugins/source/bootimg-efi.py +++ b/scripts/lib/mic/plugins/source/bootimg-efi.py @@ -96,7 +96,7 @@ class BootimgEFIPlugin(SourcePlugin): @classmethod def do_prepare_partition(self, part, cr, cr_workdir, oe_builddir, bootimg_dir, - kernel_dir, native_sysroot): + kernel_dir, rootfs_dir, native_sysroot): Called to do the actual content population for a partition i.e. it 'prepares' the partition to be incorporated into the image. diff --git a/scripts/lib/mic/plugins/source/bootimg-pcbios.py b/scripts/lib/mic/plugins/source/bootimg-pcbios.py index fad150f..1211e5c 100644 --- a/scripts/lib/mic/plugins/source/bootimg-pcbios.py +++ b/scripts/lib/mic/plugins/source/bootimg-pcbios.py @@ -124,7 +124,7 @@ class BootimgPcbiosPlugin(SourcePlugin): @classmethod def do_prepare_partition(self, part, cr, cr_workdir, oe_builddir, bootimg_dir, - kernel_dir, native_sysroot): + kernel_dir, rootfs_dir, native_sysroot): Called to do the actual content population for a partition i.e. it 'prepares' the partition to be incorporated into the image. -- 1.8.3.2 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3 0/7] wic: Add --rootfs option to --source param
Hi Tom, Em 28-03-2014 18:38, Tom Zanussi escreveu: On Thu, 2014-03-27 at 19:07 -0300, João Henrique Ferreira de Freitas wrote: When testing, I noticed a problem I introduced when adding the plugin support - I'll submit a patch for it, but the fix is here: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=tzanussi/wic-bitbake-env-fixid=222d52976466464a3ff184e07c0c884c8f821dbc Do you have any automatic way to test wic? Like a tool to create valid/invalid command line combinations ? Moving on to the generic connection versions, however, I still ran into problems. Here's the 'directdisk-multi-indirect-both.wks' file I used for that test: part /boot --source bootimg-pcbios --ondisk sda --fstype=msdos --label boot --active --align 1024 part / --source rootfs --rootfs-dir=rootfs1 --ondisk sda --fstype=ext3 --label platform --align 1024 part /standby --source rootfs --rootfs-dir=rootfs2 --ondisk sda --fstype=ext3 --label secondary --align 1024 bootloader --timeout=0 --append=rootwait rootfstype=ext3 video=vesafb vga=0x318 console=tty0 Both the -e and manual failed in the same way: [trz@empanada build]$ wic create directdisk-multi-indirect-both --rootfs-dir rootfs1=/home/trz/yocto/master-cur/build/tmp/work/crownbay-poky-linux/core-image-minimal/1.0-r0/rootfs/ --rootfs-dir rootfs2=/home/trz/yocto/master-cur/build/tmp/work/crownbay-poky-linux/core-image-minimal/1.0-r0/rootfs/ -e core-image-minimal Checking basic build environment... Done. Creating image(s)... Traceback (most recent call last): File /home/trz/yocto/master-cur/scripts/wic, line 254, in module ret = main() File /home/trz/yocto/master-cur/scripts/wic, line 249, in main invoke_subcommand(args, parser, wic_help_usage, subcommands) File /home/trz/yocto/master-cur/scripts/lib/image/help.py, line 73, in invoke_subcommand subcommands.get(args[0], subcommand_error)[0](args[1:], usage) File /home/trz/yocto/master-cur/scripts/wic, line 199, in wic_create_subcommand image_output_dir, options.debug, options.properties_file) File /home/trz/yocto/master-cur/scripts/lib/image/engine.py, line 246, in wic_create cr.main(direct_args) KeyError: 'ROOTFS_DIR' [trz@empanada build]$ wic create directdisk-multi-indirect-both -b /home/trz/yocto/master-cur/build/tmp/sysroots/crownbay/usr/share -k /home/trz/yocto/master-cur/build/tmp/sysroots/crownbay/usr/src/kernel -n /home/trz/yocto/master-cur/build/tmp/sysroots/x86_64-linux --rootfs-dir rootfs1=/home/trz/yocto/master-cur/build/tmp/work/crownbay-poky-linux/core-image-minimal/1.0-r0/rootfs/ --rootfs-dir rootfs2=/home/trz/yocto/master-cur/build/tmp/work/crownbay-poky-linux/core-image-minimal/1.0-r0/rootfs/ Creating image(s)... Traceback (most recent call last): File /home/trz/yocto/master-cur/scripts/wic, line 254, in module ret = main() File /home/trz/yocto/master-cur/scripts/wic, line 249, in main invoke_subcommand(args, parser, wic_help_usage, subcommands) File /home/trz/yocto/master-cur/scripts/lib/image/help.py, line 73, in invoke_subcommand subcommands.get(args[0], subcommand_error)[0](args[1:], usage) File /home/trz/yocto/master-cur/scripts/wic, line 153, in wic_create_subcommand rootfs_dir = options.rootfs_dir['ROOTFS_DIR'] KeyError: 'ROOTFS_DIR' Ok, the problem was that no --rootfs-dir (without a connect) was passed. Like this: ... --rootfs-dir /home/trz/yocto/master-cur/build/tmp/work/crownbay-poky-linux/core-image-minimal/1.0-r0/rootfs/ --rootfs-dir rootfs2=/home/trz/yocto/master-cur/build/tmp/work/crownbay-poky-linux/core-image-minimal/1.0-r0/rootfs/ I've fixed the code to get this situation. Thanks. -- João Henrique Ferreira de Freitas - joaohf_at_gmail.com Campinas-SP-Brasil -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] packagegroup-toolset-native: remove it
Remove it since it seems that it is not widely used by oe.
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
.../packagegroups/packagegroup-toolset-native.bb | 230
1 file changed, 230 deletions(-)
delete mode 100644
meta/recipes-gnome/packagegroups/packagegroup-toolset-native.bb
diff --git a/meta/recipes-gnome/packagegroups/packagegroup-toolset-native.bb
b/meta/recipes-gnome/packagegroups/packagegroup-toolset-native.bb
deleted file mode 100644
index 1253800..000
--- a/meta/recipes-gnome/packagegroups/packagegroup-toolset-native.bb
+++ /dev/null
@@ -1,230 +0,0 @@
-#
-# Copyright (C) 2012 Wind River Ltd
-#
-
-SUMMARY = A toolset that contains most of the native packages
-DESCRIPTION = The packagegroup is required to build most native \
-tools, it is useful for testing and collecting the native tools.
-LICENSE = MIT
-LIC_FILES_CHKSUM =
file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d690 \
-
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420
-
-inherit native packagegroup
-
-DEPENDS = \
-acl-native \
-alsa-lib-native \
-apr-native \
-apr-util-native \
-apt-native \
-atk-native \
-attr-native \
-autoconf-native \
-autogen-native \
-automake-native \
-bdwgc-native \
-beecrypt-native \
-bigreqsproto-native \
-binutils-native \
-bison-native \
-boost-native \
-btrfs-tools-native \
-byacc-native \
-bzip2-native \
-cairo-native \
-ccache-native \
-cdrtools-native \
-chrpath-native \
-cmake-native \
-compositeproto-native \
-coreutils-native \
-createrepo-native \
-cross-localedef-native \
-curl-native \
-cwautomacros-native \
-damageproto-native \
-db-native \
-dbus-glib-native \
-dbus-native \
-desktop-file-utils-native \
-docbook-dsssl-stylesheets-native \
-docbook-sgml-dtd-3.1-native \
-docbook-sgml-dtd-4.1-native \
-docbook-sgml-dtd-4.5-native \
-docbook-utils-native \
-dosfstools-native \
-dpkg-native \
-dtc-native \
-e2fsprogs-native \
-elfutils-native \
-expat-native \
-file-native \
-findutils-native \
-fixesproto-native \
-flex-native \
-fontconfig-native \
-fontsproto-native \
-font-util-native \
-freetype-native \
-gconf-native \
-gdbm-native \
-gdk-pixbuf-native \
-gettext-minimal-native \
-gettext-native \
-ghostscript-native \
-git-native \
-glib-2.0-native \
-gmp-native \
-gnome-common-native \
-gnome-doc-utils-native \
-gnu-config-native \
-gnutls-native \
-gperf-native \
-groff-native \
-gtk-doc-stub-native \
-gtk-update-icon-cache-native \
-guile-native \
-guilt-native \
-gzip-native \
-help2man-native \
-icecc-create-env-native \
-icon-naming-utils-native \
-icu-native \
-inputproto-native \
-insserv-native \
-intltool-native \
-jpeg-native \
-kbd-native \
-kbproto-native \
-kconfig-frontends-native \
-kern-tools-native \
-kmod-native \
-ldconfig-native \
-libcap-native \
-libclass-isa-perl-native \
-libconvert-asn1-perl-native \
-libffi-native \
-libfontenc-native \
-libgcrypt-native \
-libgpg-error-native \
-libice-native \
-libmpc-native \
-libpcre-native \
-libpng-native \
-libpod-plainer-perl-native \
-libpthread-stubs-native \
-librsvg-native \
-libsm-native \
-libtasn1-native \
-libtimedate-perl-native \
-libtool-native \
-libunistring-native \
-libusb1-native \
-libusb-compat-native \
-libx11-native \
-libxau-native \
-libxcb-native \
-libxcomposite-native \
-libxcursor-native \
-libxdamage-native \
-libxdmcp-native \
-libxext-native \
-libxfixes-native \
-libxfont-native \
-libxft-native \
-libxkbfile-native \
-libxml2-native \
-libxml-namespacesupport-perl-native \
-libxml-parser-perl-native \
-libxml-sax-perl-native \
-libxml-simple-perl-native \
-libxmu-native \
-libxpm-native \
-libxrandr-native \
-libxrender-native \
-libxslt-native \
-libxt-native \
-linuxdoc-tools-native \
-lzo-native \
-lzop-native \
-m4-native \
-makedepend-native \
-makedevs-native \
-make-native \
-mkelfimage-native \
-mkfontdir-native \
-mkfontscale-native \
-mklibs-native \
-mpfr-native \
-mtd-utils-native \
-mtools-native \
-nasm-native \
-ncurses-native \
-neon-native \
-cryptodev-linux-native \
-openjade-native \
-opensp-native \
-openssl-native \
-opkg-native \
-opkg-utils-native \
-ossp-uuid-native \
-pango-native \
-parted-native \
-pax-utils-native \
-perl-native \
-pigz-native \
-pixman-native \
-pkgconfig-native \
-popt-native \
-prelink-native \
-
[OE-core] [PATCH 0/1] packagegroup-toolset-native: remove it
The following changes since commit b16de9af5c7108396a347e7107c73608a2f8d74f: packagegroup-toolset-native: Update after ocf-linux - cryptodev-linux change (2014-03-27 19:53:07 +) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib rbt/ptn http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/ptn Robert Yang (1): packagegroup-toolset-native: remove it .../packagegroups/packagegroup-toolset-native.bb | 230 1 file changed, 230 deletions(-) delete mode 100644 meta/recipes-gnome/packagegroups/packagegroup-toolset-native.bb -- 1.7.10.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
