Re: [OE-core] [PATCH V3 1/1] dbus: fix a hard dependency about dbus-ptest
On 04/04/2014 04:31 AM, Saul Wold wrote:
On 03/18/2014 07:00 PM, Chong Lu wrote:
If image contains dbus and ptest is in DISTRO_FEATURES, dbus-ptest
package
is installed, regardless of whether ptest-pkgs is in IMAGE_FEATURES.
This
issue will increase size for most small images.
This patch fixes this problem.
[YOCTO #5702]
Signed-off-by: Chong Lu
---
meta/recipes-core/dbus/{dbus-ptest_1.6.18.bb =>
dbus-test_1.6.18.bb} | 0
meta/recipes-core/dbus/dbus.inc | 4 +++-
2 files changed, 3 insertions(+), 1 deletion(-)
rename meta/recipes-core/dbus/{dbus-ptest_1.6.18.bb =>
dbus-test_1.6.18.bb} (100%)
diff --git a/meta/recipes-core/dbus/dbus-ptest_1.6.18.bb
b/meta/recipes-core/dbus/dbus-test_1.6.18.bb
similarity index 100%
rename from meta/recipes-core/dbus/dbus-ptest_1.6.18.bb
rename to meta/recipes-core/dbus/dbus-test_1.6.18.bb
diff --git a/meta/recipes-core/dbus/dbus.inc
b/meta/recipes-core/dbus/dbus.inc
index 677ff78..6059e7c 100644
--- a/meta/recipes-core/dbus/dbus.inc
+++ b/meta/recipes-core/dbus/dbus.inc
@@ -6,9 +6,11 @@ LICENSE = "AFL-2 | GPLv2+"
LIC_FILES_CHKSUM =
"file://COPYING;md5=10dded3b58148f3f1fd804b26354af3e \
file://dbus/dbus.h;beginline=6;endline=20;md5=7755c9d7abccd5dbd25a6a974538bb3c"
DEPENDS = "expat virtual/libintl"
-RDEPENDS_dbus = "${@base_contains('DISTRO_FEATURES', 'ptest',
'dbus-ptest-ptest', '', d)}"
RDEPENDS_dbus_class-native = ""
RDEPENDS_dbus_class-nativesdk = ""
+PACKAGES += "${@base_contains('DISTRO_FEATURES', 'ptest',
'dbus-ptest', '', d)}"
+ALLOW_EMPTY_dbus-ptest = "1"
+RDEPENDS_dbus-ptest = "dbus-test-ptest"
Seems like this is still causing some issues
ERROR: Nothing RPROVIDES 'nativesdk-dbus-test-ptest' (but
virtual:nativesdk:/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-intel-gpl/build/meta/recipes-core/dbus/dbus_1.6.18.bb
RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'nativesdk-dbus-test-ptest' is unbuildable,
removing...
Missing or unbuildable dependency chain was:
['nativesdk-dbus-test-ptest']
ERROR: Required build target 'nativesdk-qt4-tools' has no buildable
providers.
Missing or unbuildable dependency chain was: ['nativesdk-qt4-tools',
'nativesdk-dbus', 'nativesdk-dbus-test-ptest']
As seen in this AB Failure:
http://autobuilder.yoctoproject.org/main/builders/nightly-intel-gpl/builds/30/steps/BuildImages/logs/stdio
Sau!
Hi Saul,
I built core-image-sato-sdk after applied my patch. I didn't see error.
Can you tell me how to reproduce your building errors?
Best Regards
Chong
SRC_URI =
"http://dbus.freedesktop.org/releases/dbus/dbus-${PV}.tar.gz \
file://tmpdir.patch \
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] mesa: build fix for gallium-egl
From: Valentin Popa
(*) add MESA_EGL_NO_X11_HEADERS to defines
(*) avoid altering eglplatform.h from {top_srcdir}/include
using an alternative to
0003-EGL-Mutate-NativeDisplayType-depending-on-config
patch.
[YOCTO #5882]
Signed-off-by: Valentin Popa
Signed-off-by: Robert Yang
---
...01-Add-MESA_EGL_NO_X11_HEADERS-to-defines.patch | 41 +++
...ate-NativeDisplayType-depending-on-config.patch | 359
meta/recipes-graphics/mesa/mesa_9.1.6.bb | 10 +-
meta/recipes-graphics/mesa/mesa_git.bb | 10 +-
4 files changed, 59 insertions(+), 361 deletions(-)
create mode 100644
meta/recipes-graphics/mesa/mesa/0001-Add-MESA_EGL_NO_X11_HEADERS-to-defines.patch
delete mode 100644
meta/recipes-graphics/mesa/mesa/0003-EGL-Mutate-NativeDisplayType-depending-on-config.patch
diff --git
a/meta/recipes-graphics/mesa/mesa/0001-Add-MESA_EGL_NO_X11_HEADERS-to-defines.patch
b/meta/recipes-graphics/mesa/mesa/0001-Add-MESA_EGL_NO_X11_HEADERS-to-defines.patch
new file mode 100644
index 000..c66bf17
--- /dev/null
+++
b/meta/recipes-graphics/mesa/mesa/0001-Add-MESA_EGL_NO_X11_HEADERS-to-defines.patch
@@ -0,0 +1,41 @@
+From 63d5b4ec7a5853bbbae2e1963d406bb09e77dd60 Mon Sep 17 00:00:00 2001
+From: Valentin Popa
+Date: Thu, 27 Feb 2014 10:32:17 +0200
+Subject: [PATCH] Add MESA_EGL_NO_X11_HEADERS to defines
+
+MESA_EGL_NO_X11_HEADERS is used in eglplatform.h
+but the preprocessor doesn't know about it.
+Define MESA_EGL_NO_X11_HEADERS for builds without
+x11 in DISTRO_FEATURES.
+
+Backport from 9.2.5.
+
+Upstream-Status: Backport
+
+Signed-off-by: Valentin Popa
+---
+ configure.ac | 8
+ 1 file changed, 8 insertions(+)
+
+diff --git a/configure.ac b/configure.ac
+index 2acf579..a1a8487 100644
+--- a/configure.ac
b/configure.ac
+@@ -1568,6 +1568,14 @@ AC_SUBST([EGL_NATIVE_PLATFORM])
+ AC_SUBST([EGL_PLATFORMS])
+ AC_SUBST([EGL_CFLAGS])
+
++# If we don't have the X11 platform, set this define so we don't try
++# to include
++# the X11 headers.
++if ! echo "$egl_platforms" | grep -q 'x11'; then
++DEFINES="$DEFINES -DMESA_EGL_NO_X11_HEADERS"
++GL_PC_CFLAGS="$GL_PC_CFLAGS -DMESA_EGL_NO_X11_HEADERS"
++fi
++
+ AC_ARG_WITH([egl-driver-dir],
+ [AS_HELP_STRING([--with-egl-driver-dir=DIR],
+ [directory for EGL drivers [[default=${libdir}/egl]]])],
+--
+1.8.3.2
+
diff --git
a/meta/recipes-graphics/mesa/mesa/0003-EGL-Mutate-NativeDisplayType-depending-on-config.patch
b/meta/recipes-graphics/mesa/mesa/0003-EGL-Mutate-NativeDisplayType-depending-on-config.patch
deleted file mode 100644
index 8a83f4b..000
---
a/meta/recipes-graphics/mesa/mesa/0003-EGL-Mutate-NativeDisplayType-depending-on-config.patch
+++ /dev/null
@@ -1,359 +0,0 @@
-From 8d31ae23683394617c49301b039b3a069b9ea436 Mon Sep 17 00:00:00 2001
-From: Daniel Stone
-Date: Fri, 24 May 2013 17:20:27 +0100
-Subject: [PATCH 3/4] EGL: Mutate NativeDisplayType depending on config
-
-If we go through ./configure without enabling X11 anywhere, then set the
-fallback types for EGL NativeDisplay and friends, rather than assuming
-X11/Xlib.
-
-Upstream-Status: Backport (slightly different solution was applied in master
-https://bugs.freedesktop.org/show_bug.cgi?id=64959)
-
-Signed-off-by: Daniel Stone
-Signed-off-by: Martin Jansa
- configure.ac | 5 ++
- include/EGL/eglplatform.h| 146 ---
- include/EGL/eglplatform.h.in | 146 +++
- 3 files changed, 151 insertions(+), 146 deletions(-)
- delete mode 100644 include/EGL/eglplatform.h
- create mode 100644 include/EGL/eglplatform.h.in
-
-diff --git a/configure.ac b/configure.ac
-index 67b8c40..afc3217 100644
a/configure.ac
-+++ b/configure.ac
-@@ -1499,6 +1499,9 @@ EGL_PLATFORMS="$egl_platforms"
-
- if echo "$egl_platforms" | grep 'x11' >/dev/null 2>&1; then
- NEED_WINSYS_XLIB=yes
-+MESA_EGL_NO_X11_HEADERS=0
-+else
-+MESA_EGL_NO_X11_HEADERS=1
- fi
- AM_CONDITIONAL(HAVE_EGL_PLATFORM_X11, echo "$egl_platforms" | grep 'x11'
>/dev/null 2>&1)
- AM_CONDITIONAL(HAVE_EGL_PLATFORM_WAYLAND, echo "$egl_platforms" | grep
'wayland' >/dev/null 2>&1)
-@@ -1512,6 +1515,7 @@ AM_CONDITIONAL(HAVE_EGL_DRIVER_GLX, test
"x$HAVE_EGL_DRIVER_GLX" != "x")
- AC_SUBST([EGL_NATIVE_PLATFORM])
- AC_SUBST([EGL_PLATFORMS])
- AC_SUBST([EGL_CFLAGS])
-+AC_SUBST([MESA_EGL_NO_X11_HEADERS])
-
- AC_ARG_WITH([egl-driver-dir],
- [AS_HELP_STRING([--with-egl-driver-dir=DIR],
-@@ -1991,6 +1995,7 @@ CXXFLAGS="$CXXFLAGS $USER_CXXFLAGS"
-
- dnl Substitute the config
- AC_CONFIG_FILES([Makefile
-+ include/EGL/eglplatform.h
- src/Makefile
- src/egl/Makefile
- src/egl/drivers/Makefile
-diff --git a/include/EGL/eglplatform.h b/include/EGL/eglplatform.h
-deleted file mode 100644
-index 17fdc61..000
a/include/EGL/eglplatform.h
-+++ /dev/null
-@@ -1,146 +0,0 @@
--#ifndef __eglplatform_h_
--#define __eglpla
[OE-core] [PATCH 2/2] eglibc 2.18: powerpc: Fix time related syscalls
From: Mats Kärrman 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. Signed-off-by: Mats Karrman Signed-off-by: Robert Yang --- .../ppc-fix-time-related-syscalls.patch| 227 meta/recipes-core/eglibc/eglibc_2.18.bb|1 + 2 files changed, 228 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..c2373c5 --- /dev/null +++ b/meta/recipes-core/eglibc/eglibc-2.18/ppc-fix-time-related-syscalls.patch @@ -0,0 +1,227 @@ +Upstream-Status: Backport + +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 + 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 + 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 + 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 + 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 ++ symbol resolution via .glink0/.plt0 for a zero TOC (requires thread-safe P
[OE-core] [dora] [PATCH 0/2] two fixes for dora
Hi RP, Here are two fixes which are sent by Mats Karrman and Valentin Popa for dora. // Robert The following changes since commit ec8ae16e35fd7db6a5bb12412d50ab6f355b0f6e: image_types.bbclass: use 4096 instead of 8192 bytes-per-inode (2014-03-26 09:43:52 +) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib robert/dora-next http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=robert/dora-next Mats Kärrman (1): eglibc 2.18: powerpc: Fix time related syscalls Valentin Popa (1): mesa: build fix for gallium-egl .../ppc-fix-time-related-syscalls.patch| 227 + meta/recipes-core/eglibc/eglibc_2.18.bb|1 + ...01-Add-MESA_EGL_NO_X11_HEADERS-to-defines.patch | 41 +++ ...ate-NativeDisplayType-depending-on-config.patch | 359 meta/recipes-graphics/mesa/mesa_9.1.6.bb | 10 +- meta/recipes-graphics/mesa/mesa_git.bb | 10 +- 6 files changed, 287 insertions(+), 361 deletions(-) create mode 100644 meta/recipes-core/eglibc/eglibc-2.18/ppc-fix-time-related-syscalls.patch create mode 100644 meta/recipes-graphics/mesa/mesa/0001-Add-MESA_EGL_NO_X11_HEADERS-to-defines.patch delete mode 100644 meta/recipes-graphics/mesa/mesa/0003-EGL-Mutate-NativeDisplayType-depending-on-config.patch -- 1.7.10.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] nss: avoid to use the hardcode kernel version
On 2014年04月03日 20:00, Richard Purdie wrote:
On Wed, 2014-04-02 at 10:35 +0800, Kang Kai wrote:
On 2014年03月31日 22:20, Kai Kang wrote:
From: Roy Li
When native package is built, use the uname to return the kernel version.
When target is built, read kernel version from
${STAGING_KERNEL_DIR}/kernel-abiversion
to avoid to use the hardcode kernel version.
Signed-off-by: Roy Li
Signed-off-by: Kai Kang
---
meta/recipes-support/nss/nss.inc | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-support/nss/nss.inc b/meta/recipes-support/nss/nss.inc
index 404decc..f24da68 100644
--- a/meta/recipes-support/nss/nss.inc
+++ b/meta/recipes-support/nss/nss.inc
@@ -26,6 +26,7 @@ SRC_URI_append_class-target = "\
inherit siteinfo
PR = "r0"
DEPENDS = "sqlite3 nspr zlib nss-native"
+DEPENDS_append_class-target += "virtual/kernel"
DEPENDS_class-native = "sqlite3-native nspr-native zlib-native"
RDEPENDS_${PN} = "perl"
@@ -37,12 +38,24 @@ TARGET_CC_ARCH += "${LDFLAGS}"
do_compile_prepend_class-native() {
export NSPR_INCLUDE_DIR=${STAGING_INCDIR_NATIVE}
export NSPR_LIB_DIR=${STAGING_LIBDIR_NATIVE}
+export OS_RELEASE=`uname -r`
}
do_compile_prepend_class-nativesdk() {
export LDFLAGS=""
}
+do_compile_prepend_class-target() {
+export OS_RELEASE=`cat ${STAGING_KERNEL_DIR}/kernel-abiversion|sed
's/-.*//'`
+}
+
+do_install_prepend_class-native() {
+export OS_RELEASE=`uname -r`
+}
+
+do_install_prepend_class-target() {
+export OS_RELEASE=`cat ${STAGING_KERNEL_DIR}/kernel-abiversion|sed
's/-.*//'`
+}
do_compile() {
export CROSS_COMPILE=1
export NATIVE_CC="gcc"
@@ -57,7 +70,6 @@ do_compile() {
export NSS_USE_SYSTEM_SQLITE=1
export NSS_ENABLE_ECC=1
-export OS_RELEASE=3.4
How about use var LINUXLIBCVERSION:
export OS_RELEASE="${@d.getVar('LINUXLIBCVERSION', True)}"
it should be the same value with kernel version, right?
As others have replied, that is usually much more recent than the oldest
kernel we support. What does nss do with this value? Is it about the
header versions? Would something run on an older kernel with a newer
value for OS_RELEASE?
I misunderstanding the usage of LINUXLIBCVERSION. What nss needs is just
current kernel version to export for build:
-export OS_RELEASE=3.4
Currently it is a fix string, and I think it is a problem.
Regards,
Kai
We also have the OLDEST_KERNEL variable (currently at 2.6.16) FWIW.
Cheers,
Richard
--
Regards,
Neil | Kai Kang
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] sysvinit: fix the bootlogd init script header
From: Roy Li fix the bootlogd init script header, to make chkconfig be able to work on bootlogd Signed-off-by: Roy Li --- meta/recipes-core/sysvinit/sysvinit/bootlogd.init | 18 +++--- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/meta/recipes-core/sysvinit/sysvinit/bootlogd.init b/meta/recipes-core/sysvinit/sysvinit/bootlogd.init index b181357..7d6518d 100755 --- a/meta/recipes-core/sysvinit/sysvinit/bootlogd.init +++ b/meta/recipes-core/sysvinit/sysvinit/bootlogd.init @@ -1,12 +1,16 @@ #! /bin/sh +### BEGIN INIT INFO +# Provides: bootlogd +# Required-Start: +# Required-Stop: +# Default-Start: S +# Default-Stop: 2 3 4 5 +# Short-Description: One of the first scripts to be executed. Starts or stops +# the bootlogd log program. If this script is called as +# "stop-bootlogd", it will stop the daemon instead of +# starting it even when called with the "start" argument. # -# bootlogd One of the first scripts to be executed. Starts or stops -# the bootlogd log program. If this script is called as -# "stop-bootlogd", it will stop the daemon instead of -# starting it even when called with the "start" argument. -# -# Version: @(#)bootlogd 2.85-12 21-Mar-2004 miqu...@cistron.nl -# +### END INIT INFO PATH=/sbin:/bin:/usr/sbin:/usr/bin DAEMON=/sbin/bootlogd -- 1.7.10.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] busybox: Specify '-nostdlib' when linking to a .o file.
Ensure that linking to the built-in.a file uses the 'nostlib'
option. Submitted to busybox mailing list here:
http://lists.busybox.net/pipermail/busybox/2014-March/080730.html
This has been accepted into upstream busybox so it will not be needed
for future versions.
Signed-off-by: Drew Moseley
---
...m-Specify-nostldlib-when-linking-to-.o-fi.patch | 40
meta/recipes-core/busybox/busybox_1.22.1.bb|1 +
2 files changed, 41 insertions(+)
create mode 100644
meta/recipes-core/busybox/busybox/0001-build-system-Specify-nostldlib-when-linking-to-.o-fi.patch
diff --git
a/meta/recipes-core/busybox/busybox/0001-build-system-Specify-nostldlib-when-linking-to-.o-fi.patch
b/meta/recipes-core/busybox/busybox/0001-build-system-Specify-nostldlib-when-linking-to-.o-fi.patch
new file mode 100644
index 000..3da38bb
--- /dev/null
+++
b/meta/recipes-core/busybox/busybox/0001-build-system-Specify-nostldlib-when-linking-to-.o-fi.patch
@@ -0,0 +1,40 @@
+From 28389e59701c2408e87e886c358f8e1766c677f7 Mon Sep 17 00:00:00 2001
+From: Drew Moseley
+Date: Sat, 29 Mar 2014 11:13:16 -0400
+Subject: [PATCH] build system: Specify '-nostldlib' when linking to .o files.
+
+For certain cross build scenarios the LD variable is overridden
+to use the gcc executive to ensure all the target tuning parameters
+are used. In these cases, the executive errors out as shown below
+but since this step is only linking to a .o file the standard libs
+are not needed.
+
+$ make LD=gcc applets/built-in.o
+ LD applets/built-in.o
+/usr/bin/ld: cannot find -lgcc_s
+/usr/bin/ld: cannot find -lgcc_s
+collect2: ld returned 1 exit status
+make[1]: *** [applets/built-in.o] Error 1
+make: *** [applets_dir] Error 2
+
+Signed-off-by: Drew Moseley
+---
+ scripts/Makefile.build |2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/scripts/Makefile.build b/scripts/Makefile.build
+index 5685b5b..eba69f6 100644
+--- a/scripts/Makefile.build
b/scripts/Makefile.build
+@@ -256,7 +256,7 @@ ifdef builtin-target
+ quiet_cmd_link_o_target = LD $@
+ # If the list of objects to link is empty, just create an empty built-in.o
+ cmd_link_o_target = $(if $(strip $(obj-y)),\
+- $(LD) $(ld_flags) -r -o $@ $(filter $(obj-y), $^),\
++ $(LD) -nostdlib $(ld_flags) -r -o $@ $(filter $(obj-y), $^),\
+ rm -f $@; $(AR) rcs $@)
+
+ $(builtin-target): $(obj-y) FORCE
+--
+1.7.9.5
+
diff --git a/meta/recipes-core/busybox/busybox_1.22.1.bb
b/meta/recipes-core/busybox/busybox_1.22.1.bb
index ffc9435..782752c 100644
--- a/meta/recipes-core/busybox/busybox_1.22.1.bb
+++ b/meta/recipes-core/busybox/busybox_1.22.1.bb
@@ -27,6 +27,7 @@ SRC_URI =
"http://www.busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \
file://inetd.conf \
file://inetd \
file://login-utilities.cfg \
+
file://0001-build-system-Specify-nostldlib-when-linking-to-.o-fi.patch \
"
SRC_URI[tarball.md5sum] = "337d1a15ab1cb1d4ed423168b1eb7d7e"
--
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/2] busybox: Use CCLD
Use the CCLD variable to ensure proper tuning parameters.
Notably when building on a x86-64 host with an i686 toolchain
there is an error building built-in.o because it is trying to
link 32-bit and 64-bit object files:
i686-pc-linux-gnu-ld
--sysroot=/work/dmoseley/Mentor/amd-2014.05/build.genericx86-64-external/tmp/sysroots/genericx86-64
-r -o applets/built-in.o applets/ap
i686-pc-linux-gnu-ld: Relocatable linking with relocations from format
elf64-x86-64 (applets/applets.o) to format elf32-i386 (applets/built-in.o) is
not support
make[1]: *** [applets/built-in.o] Error 1
Signed-off-by: Drew Moseley
---
meta/recipes-core/busybox/busybox.inc |1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-core/busybox/busybox.inc
b/meta/recipes-core/busybox/busybox.inc
index 69b9b0c..eedbe46 100644
--- a/meta/recipes-core/busybox/busybox.inc
+++ b/meta/recipes-core/busybox/busybox.inc
@@ -17,6 +17,7 @@ BUSYBOX_SPLIT_SUID ?= "1"
export EXTRA_CFLAGS = "${CFLAGS}"
export EXTRA_LDFLAGS = "${LDFLAGS}"
+export EXTRA_OEMAKE += "'LD=${CCLD}'"
PACKAGES =+ "${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog ${PN}-mdev
${PN}-hwclock"
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [dora][PATCH] opkg-utils: Update to latest git master
On Thu, Apr 03, 2014 at 12:23:12PM -0400, Denys Dmytriyenko wrote:
> On Tue, Apr 01, 2014 at 02:04:03PM +0100, Paul Barker wrote:
> > On 1 April 2014 13:29, Paul Barker wrote:
> > > On 1 April 2014 01:58, Denys Dmytriyenko wrote:
> > >> From: Denys Dmytriyenko
> > >>
> > >> The latest commit in opkg-utils allows packages created by opkg-build to
> > >> be read
> > >> by dpkg-deb again.
> > >>
> > >> (Based on OE-Core master rev: 219944af2700ce9dbc425fac384cd32b0a802123,
> > >> but all of the update-alternative fixes from master are skipped)
> > >>
> > >> Signed-off-by: Denys Dmytriyenko
> > >> Cc: Paul Barker
> > >> ---
> > >> meta/recipes-devtools/opkg-utils/opkg-utils_git.bb | 2 +-
> > >> 1 file changed, 1 insertion(+), 1 deletion(-)
> > >>
> > >> diff --git a/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
> > >> b/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
> > >> index 279cb74..fef0d13 100644
> > >> --- a/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
> > >> +++ b/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
> > >> @@ -6,7 +6,7 @@ LIC_FILES_CHKSUM =
> > >> "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
> > >>
> > >> file://opkg.py;beginline=1;endline=18;md5=15917491ad6bf7acc666ca5f7cc1e083"
> > >> RDEPENDS_${PN} = "python python-shell python-io python-math
> > >> python-crypt python-logging python-fcntl python-subprocess python-pickle
> > >> python-compression python-textutils python-stringold"
> > >> RDEPENDS_${PN}_class-native = ""
> > >> -SRCREV = "757a1664a440c60e8126443bf984e4bdf374c327"
> > >> +SRCREV = "c33b217016ee911718b10c9d57f9912935baf5a9"
> > >> PV = "0.1.8+git${SRCPV}"
> > >>
> > >> SRC_URI = "git://git.yoctoproject.org/opkg-utils \
> > >> --
> > >> 1.9.1
> > >>
> > >
> > > Personally I would prefer rebasing the existing patch and fixing the
> > > merge conflict, maintaining the patch author and existing sign offs
> > > and adding your sign off to the end. I don't know if there's a policy
> > > on this for Yocto Project.
>
> Of course you would, wouldn't you? :) I'm not looking for any extra credit
> here, but it wasn't trivial to merge the existing commit while backporting to
> dora and re-creating it was much easier. There were past precedents of that,
> where backport fixes were "based on" the commit, instead of the actual direct
> merge or cherry-pick of it...
>
>
> > > I've Cc'd Robert Yang as he's the stable branch maintainer for Dora as
> > > per https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance
> > >
> >
> > Infact, NACK on this. opkg-utils/Makefile @
> > c33b217016ee911718b10c9d57f9912935baf5a9 lists update-alternatives to
> > be installed on 'make install'.
> >
> > If you want just this fix, you need to keep SRCREV as is and add the
> > change from c33b217016ee911718b10c9d57f9912935baf5a9 as a new patch
> > within oe-core.
>
> Well, I've been using this patch in dora for some time now and it works just
> fine. But I understand there might be a conflict between update-alternatives,
> so one of the possible workarounds would be to remove the new binary from the
> package. Although that would make it even less of a backport and rather a new
> implementation on its own... Anyway, this dpkg-deb strictness is just so
> annoying!
I haven't read whole discussion, but the idea of adding just one needed
patch from the repo into oe-core metadata seems reasonable to me (unless
someone wants to create dora branch in opkg-utils repo and cherry-pick
just that one required commit there + update SRC_URI + SRCREV
accordingly).
It's imho better than creating new "less-tested" combination of all
changes from opkg-utils with only some changes for opkg-utils recipes.
--
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
Re: [OE-core] [PATCH 1/1] useradd_base.bbclass: sleep more and more seconds (up to 10)
On 04/03/2014 02:59 AM, Robert Yang wrote:
Currently, it would sleep 1 second when fail to add the user, this maybe
not enough when we use the sstate cache, as my test shows below, nearly
all the useradd actions are doing in the same minute when mirror from
ssate cache, and it would fail when the load is high, I got these time
by adding strace before the useradd for debugging:
2014-03-31 14:48:22.978079781 +0800 /tmp/log/pulseaudio.4.c
2014-03-31 14:48:22.028079813 +0800 /tmp/log/pulseaudio.1.c
2014-03-31 14:48:21.949079816 +0800 /tmp/log/pulseaudio.3.c
2014-03-31 14:48:20.903079852 +0800 /tmp/log/pulseaudio.2.c
2014-03-31 14:48:20.006079883 +0800 /tmp/log/nfs-utils.9.c
2014-03-31 14:48:18.876079923 +0800 /tmp/log/xuser-account.9.c
2014-03-31 14:48:18.824079924 +0800 /tmp/log/pulseaudio.0.c
2014-03-31 14:48:17.826079959 +0800 /tmp/log/xuser-account.8.c
2014-03-31 14:48:17.766079961 +0800 /tmp/log/nfs-utils.8.c
2014-03-31 14:48:16.794079995 +0800 /tmp/log/xuser-account.7.c
2014-03-31 14:48:16.735079997 +0800 /tmp/log/nfs-utils.7.c
2014-03-31 14:48:14.719080066 +0800 /tmp/log/xuser-account.5.c
2014-03-31 14:48:14.677080068 +0800 /tmp/log/nfs-utils.5.c
2014-03-31 14:48:12.621080139 +0800 /tmp/log/nfs-utils.3.c
2014-03-31 14:48:11.589080175 +0800 /tmp/log/nfs-utils.2.c
2014-03-31 14:48:10.242080221 +0800 /tmp/log/builder.0.c
2014-03-31 14:48:09.523080246 +0800 /tmp/log/nfs-utils.0.c
2014-03-31 14:48:09.488080248 +0800 /tmp/log/openssh.0.c
2014-03-31 14:48:09.485080248 +0800 /tmp/log/rpcbind.1.c
2014-03-31 14:48:07.590080313 +0800 /tmp/log/rpcbind.0.c
2014-03-31 14:28:15.437121590 +0800 /tmp/log/avahi.0.c
2014-03-31 14:18:19.067142238 +0800 /tmp/log/dbus.0.c
The nfs-utils and xuser-account are failed to add the user.
The useradd command needs two locks, passwd.lock and group.lock, it may
get one, but can't get another one if we look into these .c files, sleep
1 second is not enough, it needs more seconds, the reason is that, if
succeed, it doesn't have any side effects, if failed, we need wait for
more seconds rather than make it more crowding.
I've tried to use "sleep 5", but it didn't make much better since they
would sleep and wake up nearly at the same time, I also tried to use
"sleep ", that didn't make much better
,either.
I think that a better ways is sleep more and more seconds (up to 10
seconds) when failed, this can't fix the problem that they may do the
actions at the same time, but the logic is: if it is not crowding, sleep
less time should be OK, otherwise sleep more and more time.
Here is the testing result which seems much better:
2014-04-03 14:09:56.605185284 +0800 dbus.0.c
2014-04-03 14:09:39.899185862 +0800 rpcbind.5.c
2014-04-03 14:09:38.400185914 +0800 distcc.4.c
2014-04-03 14:09:35.206186025 +0800 pulseaudio.1.c
2014-04-03 14:09:33.979186067 +0800 rpcbind.4.c
2014-04-03 14:09:33.364186089 +0800 pulseaudio.0.c
2014-04-03 14:09:33.360186089 +0800 distcc.3.c
2014-04-03 14:09:30.996186171 +0800 avahi-ui.0.c
2014-04-03 14:09:30.298186195 +0800 distcc.2.c
2014-04-03 14:09:29.905186208 +0800 rpcbind.3.c
2014-04-03 14:09:29.410186226 +0800 avahi-ui.2.c
2014-04-03 14:09:28.239186266 +0800 distcc.1.c
2014-04-03 14:09:27.298186299 +0800 xuser-account.0.c
2014-04-03 14:09:27.032186308 +0800 distcc.0.c
2014-04-03 14:09:26.836186315 +0800 rpcbind.2.c
2014-04-03 14:09:25.846186349 +0800 nfs-utils.1.c
2014-04-03 14:09:25.752186352 +0800 avahi-ui.1.c
2014-04-03 14:09:24.779186386 +0800 builder.0.c
2014-04-03 14:09:24.746186387 +0800 rpcbind.1.c
2014-04-03 14:09:23.916186416 +0800 openssh.1.c
2014-04-03 14:09:23.848186418 +0800 nfs-utils.0.c
2014-04-03 14:09:23.594186427 +0800 rpcbind.0.c
2014-04-03 14:09:22.609186461 +0800 ppp-dialin.0.c
2014-04-03 14:09:21.817186488 +0800 openssh.0.c
[YOCTO #6085]
Signed-off-by: Robert Yang
---
meta/classes/useradd_base.bbclass | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/meta/classes/useradd_base.bbclass
b/meta/classes/useradd_base.bbclass
index 7aafe29..01d2e99 100644
--- a/meta/classes/useradd_base.bbclass
+++ b/meta/classes/useradd_base.bbclass
@@ -24,7 +24,7 @@ perform_groupadd () {
group_exists="`grep "^$groupname:" $rootdir/etc/group ||
true`"
if test "x$group_exists" = "x"; then
bbwarn "groupadd command did not succeed.
Retrying..."
- sleep 1
+ sleep `expr $count + 1`
Why not move the count assignment that is below the fi (not visible in
this diff) to above the test and then check for count > retries, this
will save one call to expr.
Sau!
else
break
fi
@@ -52,7 +52,7 @@ perform_useradd () {
user_exists="`grep "^$username:" $rootdir/etc/passwd ||
true`"
if test "x$user_exists" = "x"; then
bbwarn "useradd command
Re: [OE-core] [PATCH V3 1/1] dbus: fix a hard dependency about dbus-ptest
On 03/18/2014 07:00 PM, Chong Lu wrote:
If image contains dbus and ptest is in DISTRO_FEATURES, dbus-ptest package
is installed, regardless of whether ptest-pkgs is in IMAGE_FEATURES. This
issue will increase size for most small images.
This patch fixes this problem.
[YOCTO #5702]
Signed-off-by: Chong Lu
---
meta/recipes-core/dbus/{dbus-ptest_1.6.18.bb => dbus-test_1.6.18.bb} | 0
meta/recipes-core/dbus/dbus.inc | 4 +++-
2 files changed, 3 insertions(+), 1 deletion(-)
rename meta/recipes-core/dbus/{dbus-ptest_1.6.18.bb => dbus-test_1.6.18.bb}
(100%)
diff --git a/meta/recipes-core/dbus/dbus-ptest_1.6.18.bb
b/meta/recipes-core/dbus/dbus-test_1.6.18.bb
similarity index 100%
rename from meta/recipes-core/dbus/dbus-ptest_1.6.18.bb
rename to meta/recipes-core/dbus/dbus-test_1.6.18.bb
diff --git a/meta/recipes-core/dbus/dbus.inc b/meta/recipes-core/dbus/dbus.inc
index 677ff78..6059e7c 100644
--- a/meta/recipes-core/dbus/dbus.inc
+++ b/meta/recipes-core/dbus/dbus.inc
@@ -6,9 +6,11 @@ LICENSE = "AFL-2 | GPLv2+"
LIC_FILES_CHKSUM = "file://COPYING;md5=10dded3b58148f3f1fd804b26354af3e \
file://dbus/dbus.h;beginline=6;endline=20;md5=7755c9d7abccd5dbd25a6a974538bb3c"
DEPENDS = "expat virtual/libintl"
-RDEPENDS_dbus = "${@base_contains('DISTRO_FEATURES', 'ptest', 'dbus-ptest-ptest',
'', d)}"
RDEPENDS_dbus_class-native = ""
RDEPENDS_dbus_class-nativesdk = ""
+PACKAGES += "${@base_contains('DISTRO_FEATURES', 'ptest', 'dbus-ptest', '',
d)}"
+ALLOW_EMPTY_dbus-ptest = "1"
+RDEPENDS_dbus-ptest = "dbus-test-ptest"
Seems like this is still causing some issues
ERROR: Nothing RPROVIDES 'nativesdk-dbus-test-ptest' (but
virtual:nativesdk:/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-intel-gpl/build/meta/recipes-core/dbus/dbus_1.6.18.bb
RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'nativesdk-dbus-test-ptest' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['nativesdk-dbus-test-ptest']
ERROR: Required build target 'nativesdk-qt4-tools' has no buildable providers.
Missing or unbuildable dependency chain was: ['nativesdk-qt4-tools',
'nativesdk-dbus', 'nativesdk-dbus-test-ptest']
As seen in this AB Failure:
http://autobuilder.yoctoproject.org/main/builders/nightly-intel-gpl/builds/30/steps/BuildImages/logs/stdio
Sau!
SRC_URI = "http://dbus.freedesktop.org/releases/dbus/dbus-${PV}.tar.gz \
file://tmpdir.patch \
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [dora][PATCH] opkg-utils: Update to latest git master
On Tue, Apr 01, 2014 at 02:04:03PM +0100, Paul Barker wrote:
> On 1 April 2014 13:29, Paul Barker wrote:
> > On 1 April 2014 01:58, Denys Dmytriyenko wrote:
> >> From: Denys Dmytriyenko
> >>
> >> The latest commit in opkg-utils allows packages created by opkg-build to
> >> be read
> >> by dpkg-deb again.
> >>
> >> (Based on OE-Core master rev: 219944af2700ce9dbc425fac384cd32b0a802123,
> >> but all of the update-alternative fixes from master are skipped)
> >>
> >> Signed-off-by: Denys Dmytriyenko
> >> Cc: Paul Barker
> >> ---
> >> meta/recipes-devtools/opkg-utils/opkg-utils_git.bb | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
> >> b/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
> >> index 279cb74..fef0d13 100644
> >> --- a/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
> >> +++ b/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
> >> @@ -6,7 +6,7 @@ LIC_FILES_CHKSUM =
> >> "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
> >>
> >> file://opkg.py;beginline=1;endline=18;md5=15917491ad6bf7acc666ca5f7cc1e083"
> >> RDEPENDS_${PN} = "python python-shell python-io python-math python-crypt
> >> python-logging python-fcntl python-subprocess python-pickle
> >> python-compression python-textutils python-stringold"
> >> RDEPENDS_${PN}_class-native = ""
> >> -SRCREV = "757a1664a440c60e8126443bf984e4bdf374c327"
> >> +SRCREV = "c33b217016ee911718b10c9d57f9912935baf5a9"
> >> PV = "0.1.8+git${SRCPV}"
> >>
> >> SRC_URI = "git://git.yoctoproject.org/opkg-utils \
> >> --
> >> 1.9.1
> >>
> >
> > Personally I would prefer rebasing the existing patch and fixing the
> > merge conflict, maintaining the patch author and existing sign offs
> > and adding your sign off to the end. I don't know if there's a policy
> > on this for Yocto Project.
Of course you would, wouldn't you? :) I'm not looking for any extra credit
here, but it wasn't trivial to merge the existing commit while backporting to
dora and re-creating it was much easier. There were past precedents of that,
where backport fixes were "based on" the commit, instead of the actual direct
merge or cherry-pick of it...
> > I've Cc'd Robert Yang as he's the stable branch maintainer for Dora as
> > per https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance
> >
>
> Infact, NACK on this. opkg-utils/Makefile @
> c33b217016ee911718b10c9d57f9912935baf5a9 lists update-alternatives to
> be installed on 'make install'.
>
> If you want just this fix, you need to keep SRCREV as is and add the
> change from c33b217016ee911718b10c9d57f9912935baf5a9 as a new patch
> within oe-core.
Well, I've been using this patch in dora for some time now and it works just
fine. But I understand there might be a conflict between update-alternatives,
so one of the possible workarounds would be to remove the new binary from the
package. Although that would make it even less of a backport and rather a new
implementation on its own... Anyway, this dpkg-deb strictness is just so
annoying!
--
Denys
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] RFC, DO-NOT-MERGE gcc-cross: don't create symlinks for tools which don't exist
* RFC only, because it maybe doesn't fix any real issue (I've noticed
only because I was comparing 2 sysroots debuging some other issues and
was wondering why we have so many dangling symlinks).
* first symlink is bypassing sstate (created in
${STAGING_DIR_NATIVE} instead of ${D}${STAGING_DIR_NATIVE}) this is
maybe worth fixing
* was g++ omitted intentionally from symlinks?
* should binutils provided tools be created by binutils recipes? Or was
it simplified like this, so that binutils don't need to know gcc's BINV?
* the same does apply to gcc-cross-initial and gcc-cross-canadian, so if
we decide to implement this or something similar it should cover all 3
* g77 and gfortran aren't created by default, so it was creating dangling
symlinks, which probably doesn't hurt
* I've tested that resulting image/ looks the same before and after this
patch with exception of g++ link (and possibly gfortran one when
enabled).
Signed-off-by: Martin Jansa
---
meta/recipes-devtools/gcc/gcc-cross.inc | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-devtools/gcc/gcc-cross.inc
b/meta/recipes-devtools/gcc/gcc-cross.inc
index 777c970..c99923f 100644
--- a/meta/recipes-devtools/gcc/gcc-cross.inc
+++ b/meta/recipes-devtools/gcc/gcc-cross.inc
@@ -148,14 +148,22 @@ do_install () {
# Link gfortran to g77 to satisfy not-so-smart configure or hard coded
g77
# gfortran is fully backwards compatible. This is a safe and practical
solution.
- ln -sf
${STAGING_DIR_NATIVE}${prefix_native}/bin/${TARGET_PREFIX}gfortran
${STAGING_DIR_NATIVE}${prefix_native}/bin/${TARGET_PREFIX}g77 || true
-
+ if [ -f
${D}${STAGING_DIR_NATIVE}${prefix_native}/bin/${MULTIMACH_TARGET_SYS}/${TARGET_PREFIX}gfortran
] ; then
+ ln -sf
${STAGING_DIR_NATIVE}${prefix_native}/bin/${TARGET_PREFIX}gfortran
${D}${STAGING_DIR_NATIVE}${prefix_native}/bin/${TARGET_PREFIX}g77 || true
+ fi
# Insert symlinks into libexec so when tools without a prefix are
searched for, the correct ones are
# found. These need to be relative paths so they work in different
locations.
dest=${D}${libexecdir}/gcc/${TARGET_SYS}/${BINV}/
install -d $dest
- for t in ar as ld nm objcopy objdump ranlib strip g77 gcc cpp gfortran;
do
+ for t in g77 gcc g++ cpp gfortran; do
+ if [ -f
${D}${STAGING_DIR_NATIVE}${prefix_native}/bin/${MULTIMACH_TARGET_SYS}/${TARGET_PREFIX}$t
] ; then
+ ln -sf ${BINRELPATH}/${TARGET_PREFIX}$t $dest$t
+ ln -sf ${BINRELPATH}/${TARGET_PREFIX}$t
${dest}${TARGET_PREFIX}$t
+ fi
+ done
+ # these aren't provided by gcc, so add them without existence check
+ for t in ar as ld nm objcopy objdump ranlib strip; do
ln -sf ${BINRELPATH}/${TARGET_PREFIX}$t $dest$t
ln -sf ${BINRELPATH}/${TARGET_PREFIX}$t
${dest}${TARGET_PREFIX}$t
done
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] State of bitbake world, Failed tasks 2014-04-03
On Thu, Apr 3, 2014 at 3:06 PM, Martin Jansa wrote: > On Sun, Mar 30, 2014 at 01:28:00AM +0100, Martin Jansa wrote: >> Be aware that I plan to run test-dependencies script for next few days, >> so changes to meta-oe will be delayed until it's finished and I can use >> jenkins again to test incoming changes. > > I've just started this long test-dependencies build so jenkins will be busy > for next 14 days or so, but I'll send complete qa.log in advance as soon as > it finishes building world from scratch. > > The report looks a lot better, thanks to everybody who sent patches! Be aware > that qemuarm still shows a lot more failures, that's because only last > qemux86-64 > build contained all fixes from ML. > > Here is just qemux86-64 build: > meta-qt5/recipes-qt/qt5/qtbase_5.2.1.bb, do_configure > meta-browser/recipes-mozilla/firefox/firefox_10.0.11esr.bb, do_compile > openembedded-core/meta/recipes-bsp/grub/grub_2.00.bb, do_package > meta-openembedded/meta-oe/recipes-connectivity/daq/daq_2.0.2.bb, do_install > > meta-openembedded/meta-oe/recipes-connectivity/libimobiledevice/libimobiledevice_1.1.4.bb, > do_configure > meta-openembedded/meta-gnome/recipes-gnome/abiword/abiword_3.0.0.bb, > do_compile > meta-openembedded/meta-oe/recipes-support/emacs/emacs_23.4.bb, do_compile > > meta-openembedded/meta-multimedia/recipes-multimedia/openal/openal-soft_1.15.1.bb, > do_compile > > meta-openembedded/meta-gnome/recipes-gnome/gnome-backgrounds/gnome-backgrounds_2.32.0.bb, > do_configure > meta-openembedded/meta-oe/recipes-devtools/tcltk/tk_8.6.0.bb, do_compile > meta-openembedded/meta-gnome/recipes-gnome/devilspie/devilspie2_0.24.bb, > do_compile > openembedded-core/meta/recipes-multimedia/gstreamer/gst-ffmpeg_0.10.13.bb, > do_configure > meta-openembedded/meta-multimedia/recipes-mediacentre/xbmc/xbmc_git.bb, > do_configure > meta-openembedded/meta-oe/recipes-devtools/cloud9/cloud9_0.6.bb, do_compile > meta-openembedded/meta-xfce/recipes-apps/mousepad/mousepad_0.3.0.bb, > do_configure > > qtbase was broken by one patch from oe-devel ML, I've removed it for now. > > abiword was upgraded to fix failure, but will need some more changes. After a short look into build log make me guessing that -PARALLEL_MAKE = "" was not a good idea... Will send a follow up patch this evening Andreas -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [dora][PATCH] opkg-utils: Update to latest git master
On 04/01/2014 09:04 PM, Paul Barker wrote:
On 1 April 2014 13:29, Paul Barker wrote:
On 1 April 2014 01:58, Denys Dmytriyenko wrote:
From: Denys Dmytriyenko
The latest commit in opkg-utils allows packages created by opkg-build to be read
by dpkg-deb again.
(Based on OE-Core master rev: 219944af2700ce9dbc425fac384cd32b0a802123,
but all of the update-alternative fixes from master are skipped)
Signed-off-by: Denys Dmytriyenko
Cc: Paul Barker
---
meta/recipes-devtools/opkg-utils/opkg-utils_git.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
b/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
index 279cb74..fef0d13 100644
--- a/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
+++ b/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
@@ -6,7 +6,7 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
file://opkg.py;beginline=1;endline=18;md5=15917491ad6bf7acc666ca5f7cc1e083"
RDEPENDS_${PN} = "python python-shell python-io python-math python-crypt
python-logging python-fcntl python-subprocess python-pickle python-compression
python-textutils python-stringold"
RDEPENDS_${PN}_class-native = ""
-SRCREV = "757a1664a440c60e8126443bf984e4bdf374c327"
+SRCREV = "c33b217016ee911718b10c9d57f9912935baf5a9"
PV = "0.1.8+git${SRCPV}"
SRC_URI = "git://git.yoctoproject.org/opkg-utils \
--
1.9.1
Personally I would prefer rebasing the existing patch and fixing the
merge conflict, maintaining the patch author and existing sign offs
and adding your sign off to the end. I don't know if there's a policy
on this for Yocto Project.
I think that keep the patch in the git repo is preferred if it has been
merged by the upstream.
But usually, we don't update the recipe (package) for the stable branch,
so I'm sorry to say that I'm afraid we can't take this patch unless there
are strong reasons.
Thanks for taking care of this.
// Robert
I've Cc'd Robert Yang as he's the stable branch maintainer for Dora as
per https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance
Infact, NACK on this. opkg-utils/Makefile @
c33b217016ee911718b10c9d57f9912935baf5a9 lists update-alternatives to
be installed on 'make install'.
If you want just this fix, you need to keep SRCREV as is and add the
change from c33b217016ee911718b10c9d57f9912935baf5a9 as a new patch
within oe-core.
Thanks,
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] nss: avoid to use the hardcode kernel version
On Thursday 03 April 2014 14:49:05 Phil Blundell wrote: > On Thu, 2014-04-03 at 14:13 +0100, Paul Eggleton wrote: > > Incidentally, I think maybe for 1.7 it's time we bumped OLDEST_KERNEL. > > What a sensible minimum would be though I'm not sure. The minimum version > > for udev 182 would be one choice, but I believe there are people still > > using older kernels even than that. > > What would be the advantages of bumping it up? I could be wrong, but my understanding was that EGLIBC functionality specific to a particular kernel version or later is enabled / disabled based upon this value. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] nss: avoid to use the hardcode kernel version
On Thu, 2014-04-03 at 14:13 +0100, Paul Eggleton wrote: > Incidentally, I think maybe for 1.7 it's time we bumped OLDEST_KERNEL. What a > sensible minimum would be though I'm not sure. The minimum version for udev > 182 would be one choice, but I believe there are people still using older > kernels even than that. What would be the advantages of bumping it up? p. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] nss: avoid to use the hardcode kernel version
On Thursday 03 April 2014 13:00:09 Richard Purdie wrote:
> On Wed, 2014-04-02 at 10:35 +0800, Kang Kai wrote:
> > On 2014年03月31日 22:20, Kai Kang wrote:
> > > From: Roy Li
> > >
> > > When native package is built, use the uname to return the kernel
> > > version.
> > >
> > > When target is built, read kernel version from
> > > ${STAGING_KERNEL_DIR}/kernel-abiversion to avoid to use the hardcode
> > > kernel version.
> > >
> > > Signed-off-by: Roy Li
> > > Signed-off-by: Kai Kang
> > > ---
> > >
> > > meta/recipes-support/nss/nss.inc | 15 +--
> > > 1 file changed, 13 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/meta/recipes-support/nss/nss.inc
> > > b/meta/recipes-support/nss/nss.inc index 404decc..f24da68 100644
> > > --- a/meta/recipes-support/nss/nss.inc
> > > +++ b/meta/recipes-support/nss/nss.inc
> > > @@ -26,6 +26,7 @@ SRC_URI_append_class-target = "\
> > >
> > > inherit siteinfo
> > > PR = "r0"
> > > DEPENDS = "sqlite3 nspr zlib nss-native"
> > >
> > > +DEPENDS_append_class-target += "virtual/kernel"
> > >
> > > DEPENDS_class-native = "sqlite3-native nspr-native zlib-native"
> > > RDEPENDS_${PN} = "perl"
> > >
> > > @@ -37,12 +38,24 @@ TARGET_CC_ARCH += "${LDFLAGS}"
> > >
> > > do_compile_prepend_class-native() {
> > >
> > > export NSPR_INCLUDE_DIR=${STAGING_INCDIR_NATIVE}
> > > export NSPR_LIB_DIR=${STAGING_LIBDIR_NATIVE}
> > >
> > > +export OS_RELEASE=`uname -r`
> > >
> > > }
> > >
> > > do_compile_prepend_class-nativesdk() {
> > >
> > > export LDFLAGS=""
> > >
> > > }
> > >
> > > +do_compile_prepend_class-target() {
> > > +export OS_RELEASE=`cat ${STAGING_KERNEL_DIR}/kernel-abiversion|sed
> > > 's/-.*//'` +}
> > > +
> > > +do_install_prepend_class-native() {
> > > +export OS_RELEASE=`uname -r`
> > > +}
> > > +
> > > +do_install_prepend_class-target() {
> > > +export OS_RELEASE=`cat ${STAGING_KERNEL_DIR}/kernel-abiversion|sed
> > > 's/-.*//'` +}
> > >
> > > do_compile() {
> > >
> > > export CROSS_COMPILE=1
> > > export NATIVE_CC="gcc"
> > >
> > > @@ -57,7 +70,6 @@ do_compile() {
> > >
> > > export NSS_USE_SYSTEM_SQLITE=1
> > > export NSS_ENABLE_ECC=1
> > >
> > > -export OS_RELEASE=3.4
> >
> > How about use var LINUXLIBCVERSION:
> >
> > export OS_RELEASE="${@d.getVar('LINUXLIBCVERSION', True)}"
> >
> > it should be the same value with kernel version, right?
>
> As others have replied, that is usually much more recent than the oldest
> kernel we support. What does nss do with this value? Is it about the
> header versions? Would something run on an older kernel with a newer
> value for OS_RELEASE?
>
> We also have the OLDEST_KERNEL variable (currently at 2.6.16) FWIW.
Incidentally, I think maybe for 1.7 it's time we bumped OLDEST_KERNEL. What a
sensible minimum would be though I'm not sure. The minimum version for udev
182 would be one choice, but I believe there are people still using older
kernels even than that.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] State of bitbake world, Failed tasks 2014-04-03
On Sun, Mar 30, 2014 at 01:28:00AM +0100, Martin Jansa wrote: > Be aware that I plan to run test-dependencies script for next few days, > so changes to meta-oe will be delayed until it's finished and I can use > jenkins again to test incoming changes. I've just started this long test-dependencies build so jenkins will be busy for next 14 days or so, but I'll send complete qa.log in advance as soon as it finishes building world from scratch. The report looks a lot better, thanks to everybody who sent patches! Be aware that qemuarm still shows a lot more failures, that's because only last qemux86-64 build contained all fixes from ML. Here is just qemux86-64 build: meta-qt5/recipes-qt/qt5/qtbase_5.2.1.bb, do_configure meta-browser/recipes-mozilla/firefox/firefox_10.0.11esr.bb, do_compile openembedded-core/meta/recipes-bsp/grub/grub_2.00.bb, do_package meta-openembedded/meta-oe/recipes-connectivity/daq/daq_2.0.2.bb, do_install meta-openembedded/meta-oe/recipes-connectivity/libimobiledevice/libimobiledevice_1.1.4.bb, do_configure meta-openembedded/meta-gnome/recipes-gnome/abiword/abiword_3.0.0.bb, do_compile meta-openembedded/meta-oe/recipes-support/emacs/emacs_23.4.bb, do_compile meta-openembedded/meta-multimedia/recipes-multimedia/openal/openal-soft_1.15.1.bb, do_compile meta-openembedded/meta-gnome/recipes-gnome/gnome-backgrounds/gnome-backgrounds_2.32.0.bb, do_configure meta-openembedded/meta-oe/recipes-devtools/tcltk/tk_8.6.0.bb, do_compile meta-openembedded/meta-gnome/recipes-gnome/devilspie/devilspie2_0.24.bb, do_compile openembedded-core/meta/recipes-multimedia/gstreamer/gst-ffmpeg_0.10.13.bb, do_configure meta-openembedded/meta-multimedia/recipes-mediacentre/xbmc/xbmc_git.bb, do_configure meta-openembedded/meta-oe/recipes-devtools/cloud9/cloud9_0.6.bb, do_compile meta-openembedded/meta-xfce/recipes-apps/mousepad/mousepad_0.3.0.bb, do_configure qtbase was broken by one patch from oe-devel ML, I've removed it for now. abiword was upgraded to fix failure, but will need some more changes. openal-soft, gst-ffmpeg and xbmc are failing because now world builds set P_V for libav to use version 9 needed by newer mplayer (which was failing before because of live555), xbmc was always failing, now it only fails a bit sooner in do_configure when checking ffmpeg. emacs is failing because of segfault in qemu, the same symptoms as before: http://git.openembedded.org/meta-openembedded/commit/?id=72e02b4625dceb0cc72e1edfc28215786c7de63a maybe some something was lost in transition to oe-core, or there is new issue in pixman or somewhere else: http://git.openembedded.org/openembedded-core/tree/meta/recipes-graphics/xorg-lib/pixman/0001-ARM-qemu-related-workarounds-in-cpu-features-detecti.patch I'll look into gnome-backgrounds and mousepad, because I have pending patches for them which probably don't fix it completely. Other recipes are still "free" for fixing, please fix them and send reply to this thread when you start looking into it, so that nobody duplicates work. http://www.openembedded.org/wiki/Bitbake_World_Status == Failed tasks 2014-04-03 == === common (7) === * meta-openembedded/meta-gnome/recipes-gnome/gnome-backgrounds/gnome-backgrounds_2.32.0.bb, do_configure * meta-openembedded/meta-multimedia/recipes-mediacentre/xbmc/xbmc_git.bb, do_configure * meta-openembedded/meta-multimedia/recipes-multimedia/openal/openal-soft_1.15.1.bb, do_compile * meta-openembedded/meta-oe/recipes-devtools/cloud9/cloud9_0.6.bb, do_compile * meta-openembedded/meta-oe/recipes-devtools/tcltk/tk_8.6.0.bb, do_compile * meta-openembedded/meta-xfce/recipes-apps/mousepad/mousepad_0.3.0.bb, do_configure * openembedded-core/meta/recipes-multimedia/gstreamer/gst-ffmpeg_0.10.13.bb, do_configure === common-x86 (5) === * meta-browser/recipes-mozilla/firefox/firefox_10.0.11esr.bb, do_compile * meta-openembedded/meta-gnome/recipes-gnome/devilspie/devilspie2_0.24.bb, do_compile * meta-openembedded/meta-oe/recipes-support/emacs/emacs_23.4.bb, do_compile * meta-qt5/recipes-qt/qt5/qtbase_5.2.1.bb, do_configure * openembedded-core/meta/recipes-bsp/grub/grub_2.00.bb, do_package === qemuarm (15) === * meta-openembedded/meta-oe/recipes-extended/gnuplot/gnuplot_4.4.4.bb, do_compile * meta-openembedded/meta-oe/recipes-extended/mml-widget/gtkmathview_0.8.0.bb, do_compile * meta-openembedded/meta-oe/recipes-navigation/monav/monav_0.3.bb, do_compile * meta-openembedded/meta-oe/recipes-support/asio/asio_1.4.1.bb, do_compile * meta-openembedded/meta-oe/recipes-support/inih/libinih_git.bb, do_install * meta-openembedded/meta-oe/recipes-support/mongodb/mongodb_git.bb, do_compile * meta-openembedded/meta-oe/recipes-support/open-vcdiff/open-vcdiff_0.8.3.bb, do_configure * meta-openembedded/meta-xfce/recipes-apps/xarchiver/xarchiver_git.bb, do_configure * meta-openembedded/meta-xfce/recipes-apps/xfce4-task
Re: [OE-core] [PATCH] nss: avoid to use the hardcode kernel version
On Wed, 2014-04-02 at 10:35 +0800, Kang Kai wrote:
> On 2014年03月31日 22:20, Kai Kang wrote:
> > From: Roy Li
> >
> > When native package is built, use the uname to return the kernel version.
> >
> > When target is built, read kernel version from
> > ${STAGING_KERNEL_DIR}/kernel-abiversion
> > to avoid to use the hardcode kernel version.
> >
> > Signed-off-by: Roy Li
> > Signed-off-by: Kai Kang
> > ---
> > meta/recipes-support/nss/nss.inc | 15 +--
> > 1 file changed, 13 insertions(+), 2 deletions(-)
> >
> > diff --git a/meta/recipes-support/nss/nss.inc
> > b/meta/recipes-support/nss/nss.inc
> > index 404decc..f24da68 100644
> > --- a/meta/recipes-support/nss/nss.inc
> > +++ b/meta/recipes-support/nss/nss.inc
> > @@ -26,6 +26,7 @@ SRC_URI_append_class-target = "\
> > inherit siteinfo
> > PR = "r0"
> > DEPENDS = "sqlite3 nspr zlib nss-native"
> > +DEPENDS_append_class-target += "virtual/kernel"
> > DEPENDS_class-native = "sqlite3-native nspr-native zlib-native"
> > RDEPENDS_${PN} = "perl"
> >
> > @@ -37,12 +38,24 @@ TARGET_CC_ARCH += "${LDFLAGS}"
> > do_compile_prepend_class-native() {
> > export NSPR_INCLUDE_DIR=${STAGING_INCDIR_NATIVE}
> > export NSPR_LIB_DIR=${STAGING_LIBDIR_NATIVE}
> > +export OS_RELEASE=`uname -r`
> > }
> >
> > do_compile_prepend_class-nativesdk() {
> > export LDFLAGS=""
> > }
> >
> > +do_compile_prepend_class-target() {
> > +export OS_RELEASE=`cat ${STAGING_KERNEL_DIR}/kernel-abiversion|sed
> > 's/-.*//'`
> > +}
> > +
> > +do_install_prepend_class-native() {
> > +export OS_RELEASE=`uname -r`
> > +}
> > +
> > +do_install_prepend_class-target() {
> > +export OS_RELEASE=`cat ${STAGING_KERNEL_DIR}/kernel-abiversion|sed
> > 's/-.*//'`
> > +}
> > do_compile() {
> > export CROSS_COMPILE=1
> > export NATIVE_CC="gcc"
> > @@ -57,7 +70,6 @@ do_compile() {
> > export NSS_USE_SYSTEM_SQLITE=1
> > export NSS_ENABLE_ECC=1
> >
> > -export OS_RELEASE=3.4
>
> How about use var LINUXLIBCVERSION:
>
> export OS_RELEASE="${@d.getVar('LINUXLIBCVERSION', True)}"
>
> it should be the same value with kernel version, right?
As others have replied, that is usually much more recent than the oldest
kernel we support. What does nss do with this value? Is it about the
header versions? Would something run on an older kernel with a newer
value for OS_RELEASE?
We also have the OLDEST_KERNEL variable (currently at 2.6.16) FWIW.
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] cmake-native also depends on acl-native (was Re: cmake-native: Depend on ncurses-native too)
On Tuesday 01 April 2014 at 21:59:34 -0700, Khem Raj wrote:
> On Tue, Apr 1, 2014 at 3:11 AM, Mike Crowe wrote:
> > It seems to be possible to disable building the "CursesDialog" component to
> > remove the need for ncurses but I couldn't immediately see how to do that
> > for a bootstrap build.
> >
> > The non-native cmake recipe depends on ncurses even though it passes
> > -DBUILD_CursesDialog=0.
>
> you need to disable it completely in CMakefile.txt, just that define
> does not suffice you might try something like
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-util/cmake/files/cmake-2.8.10-libform.patch?diff_format=f&view=markup
>
It appears that a similar problem occurs if cmake-native is built at the
same time as acl-native:
Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/http_chunks.c.o
[ 30%]
/home/jenkins/workspace/nightly-brightsign-master/MACHINE/source/label/nightly/build-bcm7425/source-release-test-build/brightsign-oe/build-bcm7425/tmp-eglibc/work/x86_64-linux/cmake-native/2.8.12.2-r0/cmake-2.8.12.2/Utilities/cmlibarchive/libarchive/archive_read_disk_entry_from_file.c:38:21:fatal
error: sys/acl.h: No such file or directory
compilation terminated.
cmake detects sys/acl.h but by the time the compiler tries to include it
the file has been unstaged from the sysroot.
This one is harder to patch out. Do you object to me adding acl{,-native}
to DEPENDS?
Thanks.
Mike.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] useradd_base.bbclass: sleep more and more seconds (up to 10)
Currently, it would sleep 1 second when fail to add the user, this maybe
not enough when we use the sstate cache, as my test shows below, nearly
all the useradd actions are doing in the same minute when mirror from
ssate cache, and it would fail when the load is high, I got these time
by adding strace before the useradd for debugging:
2014-03-31 14:48:22.978079781 +0800 /tmp/log/pulseaudio.4.c
2014-03-31 14:48:22.028079813 +0800 /tmp/log/pulseaudio.1.c
2014-03-31 14:48:21.949079816 +0800 /tmp/log/pulseaudio.3.c
2014-03-31 14:48:20.903079852 +0800 /tmp/log/pulseaudio.2.c
2014-03-31 14:48:20.006079883 +0800 /tmp/log/nfs-utils.9.c
2014-03-31 14:48:18.876079923 +0800 /tmp/log/xuser-account.9.c
2014-03-31 14:48:18.824079924 +0800 /tmp/log/pulseaudio.0.c
2014-03-31 14:48:17.826079959 +0800 /tmp/log/xuser-account.8.c
2014-03-31 14:48:17.766079961 +0800 /tmp/log/nfs-utils.8.c
2014-03-31 14:48:16.794079995 +0800 /tmp/log/xuser-account.7.c
2014-03-31 14:48:16.735079997 +0800 /tmp/log/nfs-utils.7.c
2014-03-31 14:48:14.719080066 +0800 /tmp/log/xuser-account.5.c
2014-03-31 14:48:14.677080068 +0800 /tmp/log/nfs-utils.5.c
2014-03-31 14:48:12.621080139 +0800 /tmp/log/nfs-utils.3.c
2014-03-31 14:48:11.589080175 +0800 /tmp/log/nfs-utils.2.c
2014-03-31 14:48:10.242080221 +0800 /tmp/log/builder.0.c
2014-03-31 14:48:09.523080246 +0800 /tmp/log/nfs-utils.0.c
2014-03-31 14:48:09.488080248 +0800 /tmp/log/openssh.0.c
2014-03-31 14:48:09.485080248 +0800 /tmp/log/rpcbind.1.c
2014-03-31 14:48:07.590080313 +0800 /tmp/log/rpcbind.0.c
2014-03-31 14:28:15.437121590 +0800 /tmp/log/avahi.0.c
2014-03-31 14:18:19.067142238 +0800 /tmp/log/dbus.0.c
The nfs-utils and xuser-account are failed to add the user.
The useradd command needs two locks, passwd.lock and group.lock, it may
get one, but can't get another one if we look into these .c files, sleep
1 second is not enough, it needs more seconds, the reason is that, if
succeed, it doesn't have any side effects, if failed, we need wait for
more seconds rather than make it more crowding.
I've tried to use "sleep 5", but it didn't make much better since they
would sleep and wake up nearly at the same time, I also tried to use
"sleep ", that didn't make much better
,either.
I think that a better ways is sleep more and more seconds (up to 10
seconds) when failed, this can't fix the problem that they may do the
actions at the same time, but the logic is: if it is not crowding, sleep
less time should be OK, otherwise sleep more and more time.
Here is the testing result which seems much better:
2014-04-03 14:09:56.605185284 +0800 dbus.0.c
2014-04-03 14:09:39.899185862 +0800 rpcbind.5.c
2014-04-03 14:09:38.400185914 +0800 distcc.4.c
2014-04-03 14:09:35.206186025 +0800 pulseaudio.1.c
2014-04-03 14:09:33.979186067 +0800 rpcbind.4.c
2014-04-03 14:09:33.364186089 +0800 pulseaudio.0.c
2014-04-03 14:09:33.360186089 +0800 distcc.3.c
2014-04-03 14:09:30.996186171 +0800 avahi-ui.0.c
2014-04-03 14:09:30.298186195 +0800 distcc.2.c
2014-04-03 14:09:29.905186208 +0800 rpcbind.3.c
2014-04-03 14:09:29.410186226 +0800 avahi-ui.2.c
2014-04-03 14:09:28.239186266 +0800 distcc.1.c
2014-04-03 14:09:27.298186299 +0800 xuser-account.0.c
2014-04-03 14:09:27.032186308 +0800 distcc.0.c
2014-04-03 14:09:26.836186315 +0800 rpcbind.2.c
2014-04-03 14:09:25.846186349 +0800 nfs-utils.1.c
2014-04-03 14:09:25.752186352 +0800 avahi-ui.1.c
2014-04-03 14:09:24.779186386 +0800 builder.0.c
2014-04-03 14:09:24.746186387 +0800 rpcbind.1.c
2014-04-03 14:09:23.916186416 +0800 openssh.1.c
2014-04-03 14:09:23.848186418 +0800 nfs-utils.0.c
2014-04-03 14:09:23.594186427 +0800 rpcbind.0.c
2014-04-03 14:09:22.609186461 +0800 ppp-dialin.0.c
2014-04-03 14:09:21.817186488 +0800 openssh.0.c
[YOCTO #6085]
Signed-off-by: Robert Yang
---
meta/classes/useradd_base.bbclass | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/meta/classes/useradd_base.bbclass
b/meta/classes/useradd_base.bbclass
index 7aafe29..01d2e99 100644
--- a/meta/classes/useradd_base.bbclass
+++ b/meta/classes/useradd_base.bbclass
@@ -24,7 +24,7 @@ perform_groupadd () {
group_exists="`grep "^$groupname:" $rootdir/etc/group
|| true`"
if test "x$group_exists" = "x"; then
bbwarn "groupadd command did not succeed.
Retrying..."
- sleep 1
+ sleep `expr $count + 1`
else
break
fi
@@ -52,7 +52,7 @@ perform_useradd () {
user_exists="`grep "^$username:" $rootdir/etc/passwd ||
true`"
if test "x$user_exists" = "x"; then
bbwarn "useradd command did not succeed.
Retrying..."
- sleep 1
+ sleep `expr $count + 1`
else
break
fi
@@ -90,7 +90
[OE-core] [PATCH 0/1] useradd_base.bbclass: sleep more and more seconds (up to 10)
The following changes since commit c1ba851727a9c0d2c075f2fba7980913280e84da: gtk+3: set proper FLAGS for native (2014-04-03 17:27:18 +0800) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib rbt/sleep http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/sleep Robert Yang (1): useradd_base.bbclass: sleep more and more seconds (up to 10) meta/classes/useradd_base.bbclass | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) -- 1.8.3.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] gtk+3: set proper FLAGS for native
On 03/31/2014 10:07 PM, Burton, Ross wrote:
On 30 March 2014 11:30, Robert Yang wrote:
++CFLAGS = @CFLAGS_FOR_BUILD@
++CPPFLAGS = @CPPFLAGS_FOR_BUILD@
++LDFLAGS = @LDFLAGS_FOR_BUILD@
So the problem is that the environment is providing a CFLAGS variable
that automake is then using for native builds alongside
CFLAGS_FOR_BUILD. Instead of replicating the variables, which this
will do, would it be better to unset CFLAGS/CPPFLAGS/LDFLAGS in this
makefile so the environment variables are not used? (as makefile
assignments override environment assignments).
Sounds good, updated:
git://git.openembedded.org/openembedded-core-contrib rbt/gtk
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/gtk
diff --git a/meta/recipes-gnome/gtk+/gtk+3/fix-flags-for-native.patch
b/meta/recipes-gnome/gtk+/gtk+3/fix-flags-for-native.patch
new file mode 100644
index 000..9ae1088
--- /dev/null
+++ b/meta/recipes-gnome/gtk+/gtk+3/fix-flags-for-native.patch
@@ -0,0 +1,33 @@
+From 5e16904f94b5f5961f8f6e75716e6d7d228de119 Mon Sep 17 00:00:00 2001
+From: Robert Yang
+Date: Fri, 28 Mar 2014 03:10:12 +
+Subject: [PATCH] gtk/native/Makefile.am: unset target FLAGS for native build
+
+The target gtk+3 does a native build in its "native" directory, we need
+unset the target FLAGS for native build, otherwise, there might be build
+failures.
+
+Upstream-Status: Pending
+
+Signed-off-by: Robert Yang
+---
+ gtk/native/Makefile.am | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/gtk/native/Makefile.am b/gtk/native/Makefile.am
+index 64899e9..a1c814a 100644
+--- a/gtk/native/Makefile.am
b/gtk/native/Makefile.am
+@@ -3,6 +3,9 @@ AM_CFLAGS = @CFLAGS_FOR_BUILD@
+ CPP = @CPP_FOR_BUILD@
+ AM_CPPFLAGS = @CPPFLAGS_FOR_BUILD@
+ AM_LDFLAGS = @LDFLAGS_FOR_BUILD@
++CFLAGS =
++CPPFLAGS =
++LDFLAGS =
+
+ if CROSS_COMPILING
+ if !USE_EXTERNAL_ICON_CACHE
+--
+1.8.3.4
+
diff --git a/meta/recipes-gnome/gtk+/gtk+3_3.10.7.bb
b/meta/recipes-gnome/gtk+/gtk+3_3.10.7.bb
index 9f8c6ab..d0174f6 100644
--- a/meta/recipes-gnome/gtk+/gtk+3_3.10.7.bb
+++ b/meta/recipes-gnome/gtk+/gtk+3_3.10.7.bb
@@ -4,7 +4,9 @@ MAJ_VER = "${@oe.utils.trim_version("${PV}", 2)}"
SRC_URI =
"http://ftp.gnome.org/pub/gnome/sources/gtk+/${MAJ_VER}/gtk+-${PV}.tar.xz \
file://hardcoded_libtool.patch \
- file://fix-build-when-wayland-backend-enabled.patch"
+ file://fix-build-when-wayland-backend-enabled.patch \
+ file://fix-flags-for-native.patch \
+ "
SRC_URI[md5sum] = "18a81944a8506231529a76bf2b68372b"
SRC_URI[sha256sum] =
"b7e9de15385031cff43897e7e59f6692eaabf500f36eef80e6b9d6486ad49427"
--
1.8.3.1
// Robert
Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] selftest/sstatetests.py: Added 'populate_lic' to ignore_patterns
Because the sstate-cache-management script does not remove populate_lic
sstate files, we should ignore them when checking for removed files.
Signed-off-by: Corneliu Stoicescu
---
meta/lib/oeqa/selftest/sstatetests.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/lib/oeqa/selftest/sstatetests.py
b/meta/lib/oeqa/selftest/sstatetests.py
index 27561ca..35ff28b 100644
--- a/meta/lib/oeqa/selftest/sstatetests.py
+++ b/meta/lib/oeqa/selftest/sstatetests.py
@@ -153,7 +153,7 @@ class SStateTests(SStateBase):
target_config = []
global_config.append('')
target_config.append('PR = "0"')
-self.run_test_sstate_cache_management_script('m4', global_config,
target_config)
+self.run_test_sstate_cache_management_script('m4', global_config,
target_config, ignore_patterns=['populate_lic'])
def test_sstate_cache_management_script_using_pr_2(self):
global_config = []
@@ -162,7 +162,7 @@ class SStateTests(SStateBase):
target_config.append('PR = "0"')
global_config.append('')
target_config.append('PR = "1"')
-self.run_test_sstate_cache_management_script('m4', global_config,
target_config)
+self.run_test_sstate_cache_management_script('m4', global_config,
target_config, ignore_patterns=['populate_lic'])
def test_sstate_cache_management_script_using_pr_3(self):
global_config = []
--
1.8.3.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] relocate_sdk.py: Possible bug, /lib64/ld-linux-x86-64.so.2 not relocated
Hi Stefan,
Can you please have a look at the binaries before relocation? Just to
make sure...
So, for that, run the installer with -R option:
./your_toolchain_installer.sh -R
Here, I'm interested which is the default suggested path (see below):
Enter target directory for SDK (default: /opt/poky/1.5+snapshot):
Then, run 'readelf -p ".interp"' on those binaries. They should all start
with the "default" prefix.
laurentiu
On Thu, Apr 03, 2014 at 09:59:34AM +0200, Stefan Agner wrote:
> Hi Laurentiu,
>
> Am 2014-03-03 09:38, schrieb Laurentiu Palcu:
> > This is the correct behavior. We shouldn't relocate binaries that use
> > host's dynamic loader.
> >
> >> When I install the SDK with -S (copy the relocate scripts), and
> >> remove the condition around line 95, the binaries work as expected.
> > Can you please run the installer script with "-R" so it doesn't perform
> > any relocation on binaries, and then:
> >
> > readelf -p ".interp"
> > /usr/local/oecore-x86_64/sysroots/x86_64-angstromsdk-linux/usr/bin/armv7ahf-vfp-neon-angstrom-linux-gnueabi/arm-angstrom-linux-gnueabi-gcc
> >
> > It looks like the default dynamic loader path of the toolchain binaries
> > start with /lib* or /usr/lib* which is not quite right... It should be:
> > ${SDKPATH}/sysroots/${SDK_SYS}.
>
> $ readelf -p ".interp"
> /usr/local/oecore-x86_64-non-reloc/sysroots/x86_64-angstromsdk-linux/usr/bin/armv7ahf-vfp-neon-angstrom-linux-gnueabi/arm-angstrom-linux-gnueabi-gcc
>
> String dump of section '.interp':
> [ 0] /lib64/ld-linux-x86-64.so.2
>
>
> So this looks wrong then, right?
>
> I also get the same for python and qmake:
> $ readelf -p ".interp"
> /usr/local/oecore-x86_64-new/sysroots/x86_64-angstromsdk-linux/usr/bin/python2
>
> String dump of section '.interp':
> [ 0] /lib64/ld-linux-x86-64.so.2
>
> $ readelf -p ".interp"
> /usr/local/oecore-x86_64-new/sysroots/x86_64-angstromsdk-linux/usr/bin/qmake2
>
>
> String dump of section '.interp':
> [ 0] /lib64/ld-linux-x86-64.so.2
>
> How can I make sure all those binaries get linked against the SDK link
> loader?
>
> --
> Stefan
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] relocate_sdk.py: Possible bug, /lib64/ld-linux-x86-64.so.2 not relocated
Hi Laurentiu,
Am 2014-03-03 09:38, schrieb Laurentiu Palcu:
> This is the correct behavior. We shouldn't relocate binaries that use
> host's dynamic loader.
>
>> When I install the SDK with -S (copy the relocate scripts), and
>> remove the condition around line 95, the binaries work as expected.
> Can you please run the installer script with "-R" so it doesn't perform
> any relocation on binaries, and then:
>
> readelf -p ".interp"
> /usr/local/oecore-x86_64/sysroots/x86_64-angstromsdk-linux/usr/bin/armv7ahf-vfp-neon-angstrom-linux-gnueabi/arm-angstrom-linux-gnueabi-gcc
>
> It looks like the default dynamic loader path of the toolchain binaries
> start with /lib* or /usr/lib* which is not quite right... It should be:
> ${SDKPATH}/sysroots/${SDK_SYS}.
$ readelf -p ".interp"
/usr/local/oecore-x86_64-non-reloc/sysroots/x86_64-angstromsdk-linux/usr/bin/armv7ahf-vfp-neon-angstrom-linux-gnueabi/arm-angstrom-linux-gnueabi-gcc
String dump of section '.interp':
[ 0] /lib64/ld-linux-x86-64.so.2
So this looks wrong then, right?
I also get the same for python and qmake:
$ readelf -p ".interp"
/usr/local/oecore-x86_64-new/sysroots/x86_64-angstromsdk-linux/usr/bin/python2
String dump of section '.interp':
[ 0] /lib64/ld-linux-x86-64.so.2
$ readelf -p ".interp"
/usr/local/oecore-x86_64-new/sysroots/x86_64-angstromsdk-linux/usr/bin/qmake2
String dump of section '.interp':
[ 0] /lib64/ld-linux-x86-64.so.2
How can I make sure all those binaries get linked against the SDK link
loader?
--
Stefan
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC][PATCH] files/device_table-minimal.txt: cleanup
Hi Richard, > If I remember correctly, mmc devices are dynamically allocated numbers. Well, in my work experience, I always used this. However, according to include/uapi/linux/major.h: #define MMC_BLOCK_MAJOR 179 > I only see ttyS, not S0 or S1? According to file: /dev/ttyS c 640 roottty 4 64 0 1 2 This will create ttyS0 and ttyS1. Matt -Message d'origine- De : Richard Purdie [mailto:richard.pur...@linuxfoundation.org] Envoyé : jeudi 3 avril 2014 09:27 À : Matthieu CRAPET Cc : openembedded-core@lists.openembedded.org Objet : Re: [OE-core] [RFC][PATCH] files/device_table-minimal.txt: cleanup On Wed, 2014-04-02 at 18:46 +0200, Matthieu Crapet wrote: > This device list is only used if USE_DEVFS is set to '0' (which is NOT > the default since 2013-12-14, see commit > f54fdd6673a136ee1cee1f3263a8a7820de43ca3) and if IMAGE_DEVICE_TABLE and > IMAGE_DEVICE_TABLES are not set. > > This is, of course a very subjective list but minimal with 62 (special) files. > However, you should be able to boot correctly a lot of embedded linux around. > > Changes: > - add sda, sdb, sda[1234], sdb[1234] > - add mmcblk0, mmcblk0p[1234] If I remember correctly, mmc devices are dynamically allocated numbers. Can we guarantee these are going to be correct? > - add rtc0, rtc1 > - restrict maximum hdaX from 19 to 4 (pata is old) > - add ttyS1 I only see ttyS, not S0 or S1? > - remove initctl, apm_bios, tty8, ttySA > - sorted entries Cheers, Richard > Signed-off-by: Matthieu Crapet > --- > meta/files/device_table-minimal.txt | 26 +++--- > 1 file changed, 15 insertions(+), 11 deletions(-) > > diff --git a/meta/files/device_table-minimal.txt > b/meta/files/device_table-minimal.txt > index 56c74bb..e4891cc 100644 > --- a/meta/files/device_table-minimal.txt > +++ b/meta/files/device_table-minimal.txt > @@ -9,23 +9,27 @@ > #p Fifo (named pipe) > > /dev d 755 rootroot- - - - > - > -/dev/initctl p 600 rootroot- - - - > - > -/dev/apm_biosc 660 rootplugdev 10 134 - > - - > +/dev/console c 662 roottty 5 1 - - > - > /dev/fb0 c 600 rootroot29 0 - - > - > /dev/hda b 660 rootdisk3 0 - - > - > -/dev/hda b 660 rootdisk3 1 1 1 > 19 > +/dev/hda b 660 rootdisk3 1 1 1 > 4 > /dev/kmemc 640 rootkmem1 2 - - > - > /dev/kmsgc 600 rootroot1 11 - - > - > /dev/mem c 640 rootkmem1 1 - - > - > -/dev/nullc 666 rootroot1 3 - - > - > -/dev/ram b 640 rootroot1 0 0 1 > 4 > -/dev/tty c 662 roottty 5 0 - - > - > -/dev/tty c 666 roottty 4 0 0 1 > 9 > -/dev/ttySc 640 roottty 4 64 0 1 > 1 > -/dev/ttySA c 640 roottty 204 5 0 1 > 1 > -/dev/zeroc 644 rootroot1 5 - - > - > +/dev/mmcblk0 b 660 rootdisk179 0 - - > - > +/dev/mmcblk0pb 660 rootdisk179 1 1 > 1 4 > /dev/mtd c 660 rootdisk90 0 0 2 > 8 > /dev/mtdblockb 640 rootroot31 0 0 > 1 8 > -/dev/console c 662 roottty 5 1 - - > - > +/dev/nullc 666 rootroot1 3 - - > - > +/dev/ram b 640 rootroot1 0 0 1 > 4 > /dev/random c 644 rootroot1 8 - - > - > +/dev/rtc c 644 rootroot254 0 0 1 > 2 > +/dev/sda b 660 rootdisk8 0 - - > - > +/dev/sda b 660 rootdisk8 1 1 1 > 4 > +/dev/sdb b 660 rootdisk8 16 - - > - > +/dev/sdb b 660 rootdisk8 17 1 1 > 4 > +/dev/tty c 662 roottty 5 0 - - > - > +/dev/tty c 666 roottty 4 0 0 1 > 8 > +/dev/ttySc 640 roottty 4 64 0 1 > 2 > /dev/urandom c 644 rootroot1 9 - - > - > +/dev/zeroc 644 root
[OE-core] [PATCH 1/1] python: fix build error with Readline 6.3
Backport two patches from upstream:
use new readline function types (closes #20374)
Issue #20374: Avoid compiler warnings when compiling readline with libedit.
[YOCTO #6107]
Signed-off-by: Chong Lu
---
.../recipes-devtools/python/python-native_2.7.3.bb | 1 +
.../python-fix-build-error-with-Readline-6.3.patch | 62 ++
.../python/python3-native_3.3.3.bb | 1 +
...python3-fix-build-error-with-Readline-6.3.patch | 62 ++
meta/recipes-devtools/python/python3_3.3.3.bb | 1 +
meta/recipes-devtools/python/python_2.7.3.bb | 1 +
6 files changed, 128 insertions(+)
create mode 100644
meta/recipes-devtools/python/python/python-fix-build-error-with-Readline-6.3.patch
create mode 100644
meta/recipes-devtools/python/python3/python3-fix-build-error-with-Readline-6.3.patch
diff --git a/meta/recipes-devtools/python/python-native_2.7.3.bb
b/meta/recipes-devtools/python/python-native_2.7.3.bb
index 6b87a16..0c66d27 100644
--- a/meta/recipes-devtools/python/python-native_2.7.3.bb
+++ b/meta/recipes-devtools/python/python-native_2.7.3.bb
@@ -17,6 +17,7 @@ SRC_URI += "\
file://add-md5module-support.patch \
file://builddir.patch \
file://parallel-makeinst-create-bindir.patch \
+ file://python-fix-build-error-with-Readline-6.3.patch \
"
S = "${WORKDIR}/Python-${PV}"
diff --git
a/meta/recipes-devtools/python/python/python-fix-build-error-with-Readline-6.3.patch
b/meta/recipes-devtools/python/python/python-fix-build-error-with-Readline-6.3.patch
new file mode 100644
index 000..b84f8c3
--- /dev/null
+++
b/meta/recipes-devtools/python/python/python-fix-build-error-with-Readline-6.3.patch
@@ -0,0 +1,62 @@
+python: fix build error with Readline 6.3
+
+Backport two patches from upstream:
+
+use new readline function types (closes #20374)
+Issue #20374: Avoid compiler warnings when compiling readline with libedit.
+
+Upstream-Status: Backport
+
+Signed-off-by: Chong Lu
+---
+ Modules/readline.c | 15 ---
+ 1 file changed, 12 insertions(+), 3 deletions(-)
+
+diff --git a/Modules/readline.c b/Modules/readline.c
+index b5e258d..d3f52aa 100644
+--- a/Modules/readline.c
b/Modules/readline.c
+@@ -735,15 +735,24 @@ on_hook(PyObject *func)
+ return result;
+ }
+
++
+ static int
++#if defined(_RL_FUNCTION_TYPEDEF)
+ on_startup_hook(void)
++#else
++on_startup_hook()
++#endif
+ {
+ return on_hook(startup_hook);
+ }
+
+ #ifdef HAVE_RL_PRE_INPUT_HOOK
+ static int
++#if defined(_RL_FUNCTION_TYPEDEF)
+ on_pre_input_hook(void)
++#else
++on_pre_input_hook()
++#endif
+ {
+ return on_hook(pre_input_hook);
+ }
+@@ -886,12 +895,12 @@ setup_readline(void)
+ rl_bind_key_in_map ('\t', rl_complete, emacs_meta_keymap);
+ rl_bind_key_in_map ('\033', rl_complete, emacs_meta_keymap);
+ /* Set our hook functions */
+-rl_startup_hook = (Function *)on_startup_hook;
++rl_startup_hook = (rl_hook_func_t *)on_startup_hook;
+ #ifdef HAVE_RL_PRE_INPUT_HOOK
+-rl_pre_input_hook = (Function *)on_pre_input_hook;
++rl_pre_input_hook = (rl_hook_func_t *)on_pre_input_hook;
+ #endif
+ /* Set our completion function */
+-rl_attempted_completion_function = (CPPFunction *)flex_complete;
++rl_attempted_completion_function = (rl_completion_func_t *)flex_complete;
+ /* Set Python word break characters */
+ rl_completer_word_break_characters =
+ strdup(" \t\n`~!@#$%^&*()-=+[{]}\\|;:'\",<>/?");
+--
+1.7.9.5
+
diff --git a/meta/recipes-devtools/python/python3-native_3.3.3.bb
b/meta/recipes-devtools/python/python3-native_3.3.3.bb
index df8f28b..7238eaf 100644
--- a/meta/recipes-devtools/python/python3-native_3.3.3.bb
+++ b/meta/recipes-devtools/python/python3-native_3.3.3.bb
@@ -25,6 +25,7 @@ file://unixccompiler.patch \
file://fix-ast.h-dependency.patch \
file://makerace.patch \
${DISTRO_SRC_URI} \
+file://python3-fix-build-error-with-Readline-6.3.patch \
"
SRC_URI[md5sum] = "f3ebe34d4d8695bf889279b54673e10c"
SRC_URI[sha256sum] =
"e526e9b612f623888364d30cc9f3dfc34dcef39065c713bdbcddf47df84d8dcb"
diff --git
a/meta/recipes-devtools/python/python3/python3-fix-build-error-with-Readline-6.3.patch
b/meta/recipes-devtools/python/python3/python3-fix-build-error-with-Readline-6.3.patch
new file mode 100644
index 000..44e2b7e
--- /dev/null
+++
b/meta/recipes-devtools/python/python3/python3-fix-build-error-with-Readline-6.3.patch
@@ -0,0 +1,62 @@
+python3: fix build error with Readline 6.3
+
+Backport two patches from upstream:
+
+use new readline function types (closes #20374)
+Issue #20374: Avoid compiler warnings when compiling readline with libedit.
+
+Upstream-Status: Backport
+
+Signed-off-by: Chong Lu
+---
+ Modules/readline.c | 15 ---
+ 1 file changed, 12 insertions(+), 3 deletions(-)
+
+diff --git a/Modules/readline.c b/Modules/readline.c
+index 096c6d1..1646ef8 100644
+--- a/Modules/readline.c
b/Modules/readline.c
+@@ -7
[OE-core] [PATCH 0/1] python: fix build error with Readline 6.3
The following changes since commit a5775abb1951ec6cdc7afacd1ae87189e398cff8: bitbake: user-manual-metadata.xml: Added new section on mapping functions. (2014-04-02 14:15:35 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib chonglu/python http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=chonglu/python Chong Lu (1): python: fix build error with Readline 6.3 .../recipes-devtools/python/python-native_2.7.3.bb | 1 + .../python-fix-build-error-with-Readline-6.3.patch | 62 ++ .../python/python3-native_3.3.3.bb | 1 + ...python3-fix-build-error-with-Readline-6.3.patch | 62 ++ meta/recipes-devtools/python/python3_3.3.3.bb | 1 + meta/recipes-devtools/python/python_2.7.3.bb | 1 + 6 files changed, 128 insertions(+) create mode 100644 meta/recipes-devtools/python/python/python-fix-build-error-with-Readline-6.3.patch create mode 100644 meta/recipes-devtools/python/python3/python3-fix-build-error-with-Readline-6.3.patch -- 1.8.1.2 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC][PATCH] files/device_table-minimal.txt: cleanup
On Wed, 2014-04-02 at 18:46 +0200, Matthieu Crapet wrote: > This device list is only used if USE_DEVFS is set to '0' (which is NOT the > default since 2013-12-14, > see commit f54fdd6673a136ee1cee1f3263a8a7820de43ca3) and if > IMAGE_DEVICE_TABLE and IMAGE_DEVICE_TABLES are not set. > > This is, of course a very subjective list but minimal with 62 (special) files. > However, you should be able to boot correctly a lot of embedded linux around. > > Changes: > - add sda, sdb, sda[1234], sdb[1234] > - add mmcblk0, mmcblk0p[1234] If I remember correctly, mmc devices are dynamically allocated numbers. Can we guarantee these are going to be correct? > - add rtc0, rtc1 > - restrict maximum hdaX from 19 to 4 (pata is old) > - add ttyS1 I only see ttyS, not S0 or S1? > - remove initctl, apm_bios, tty8, ttySA > - sorted entries Cheers, Richard > Signed-off-by: Matthieu Crapet > --- > meta/files/device_table-minimal.txt | 26 +++--- > 1 file changed, 15 insertions(+), 11 deletions(-) > > diff --git a/meta/files/device_table-minimal.txt > b/meta/files/device_table-minimal.txt > index 56c74bb..e4891cc 100644 > --- a/meta/files/device_table-minimal.txt > +++ b/meta/files/device_table-minimal.txt > @@ -9,23 +9,27 @@ > #p Fifo (named pipe) > > /dev d 755 rootroot- - - - > - > -/dev/initctl p 600 rootroot- - - - > - > -/dev/apm_biosc 660 rootplugdev 10 134 - > - - > +/dev/console c 662 roottty 5 1 - - > - > /dev/fb0 c 600 rootroot29 0 - - > - > /dev/hda b 660 rootdisk3 0 - - > - > -/dev/hda b 660 rootdisk3 1 1 1 > 19 > +/dev/hda b 660 rootdisk3 1 1 1 > 4 > /dev/kmemc 640 rootkmem1 2 - - > - > /dev/kmsgc 600 rootroot1 11 - - > - > /dev/mem c 640 rootkmem1 1 - - > - > -/dev/nullc 666 rootroot1 3 - - > - > -/dev/ram b 640 rootroot1 0 0 1 > 4 > -/dev/tty c 662 roottty 5 0 - - > - > -/dev/tty c 666 roottty 4 0 0 1 > 9 > -/dev/ttySc 640 roottty 4 64 0 1 > 1 > -/dev/ttySA c 640 roottty 204 5 0 1 > 1 > -/dev/zeroc 644 rootroot1 5 - - > - > +/dev/mmcblk0 b 660 rootdisk179 0 - - > - > +/dev/mmcblk0pb 660 rootdisk179 1 1 > 1 4 > /dev/mtd c 660 rootdisk90 0 0 2 > 8 > /dev/mtdblockb 640 rootroot31 0 0 > 1 8 > -/dev/console c 662 roottty 5 1 - - > - > +/dev/nullc 666 rootroot1 3 - - > - > +/dev/ram b 640 rootroot1 0 0 1 > 4 > /dev/random c 644 rootroot1 8 - - > - > +/dev/rtc c 644 rootroot254 0 0 1 > 2 > +/dev/sda b 660 rootdisk8 0 - - > - > +/dev/sda b 660 rootdisk8 1 1 1 > 4 > +/dev/sdb b 660 rootdisk8 16 - - > - > +/dev/sdb b 660 rootdisk8 17 1 1 > 4 > +/dev/tty c 662 roottty 5 0 - - > - > +/dev/tty c 666 roottty 4 0 0 1 > 8 > +/dev/ttySc 640 roottty 4 64 0 1 > 2 > /dev/urandom c 644 rootroot1 9 - - > - > +/dev/zeroc 644 rootroot1 5 - - > - > -- > 1.8.5.4 > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-commits] Bruce Ashfield : linux-yocto/3.10: fix drm build failure
On Wed, 2014-04-02 at 19:07 +0200, Martin Jansa wrote: > On Mon, Mar 31, 2014 at 11:51:05PM +0200, Martin Jansa wrote: > > > I can confirm that that is the right revision. I wonder what the fetcher > > > is doing, or is something in the infrastructure caching and older > > > revision ? > > > > Sorry for noise, it was after all our mirror not getting updates > > anymore, fetching it manually works. > > I've noticed one more thing: > > When fetch fails, the checkout in > downloads/git2/git.yoctoproject.org.linux-yocto-3.14.git > is removed and then git cloned again: > > This is what I did: > > # check that checkout is there: > OE qemux86@ ~/build/oe-core $ ll downloads/git2/*linux-yocto-3.14* > -rw-r--r-- 1 bitbake bitbake0 Apr 1 14:38 > downloads/git2/git.yoctoproject.org.linux-yocto-3.14.git.done > > downloads/git2/git.yoctoproject.org.linux-yocto-3.14.git: > total 156 > drwxr-xr-x 6 bitbake bitbake 4096 Apr 1 14:38 ./ > drwxr-xr-x 210 bitbake bitbake 36864 Apr 2 17:29 ../ > -rw-r--r-- 1 bitbake bitbake 42799 Apr 1 14:38 FETCH_HEAD > -rw-r--r-- 1 bitbake bitbake23 Mar 29 21:18 HEAD > -rw-r--r-- 1 bitbake bitbake 163 Apr 1 14:38 config > -rw-r--r-- 1 bitbake bitbake73 Mar 29 20:57 description > drwxr-xr-x 2 bitbake bitbake 4096 Mar 29 20:57 hooks/ > drwxr-xr-x 2 bitbake bitbake 4096 Mar 29 20:57 info/ > drwxr-xr-x 4 bitbake bitbake 4096 Mar 29 20:57 objects/ > -rw-r--r-- 1 bitbake bitbake 40375 Mar 29 21:18 packed-refs > drwxr-xr-x 4 bitbake bitbake 4096 Mar 29 20:57 refs/ > > # create backup just in case: > OE qemux86@ ~/build/oe-core $ cp -ra > downloads/git2/git.yoctoproject.org.linux-yocto-3.14.git > downloads/git2/git.yoctoproject.org.linux-yocto-3.14.git-backup > > # put wrong SRCREV > OE qemux86@ ~/build/oe-core $ vi > openembedded-core/meta/recipes-kernel/linux/linux-yocto_3.14.bb > > # try to build it: > OE qemux86@ ~/build/oe-core $ bitbake linux-yocto > NOTE: Started PRServer with DBfile: /OE/build/oe-core/cache/prserv.sqlite3, > IP: 127.0.0.1, PORT: 40335, PID: 8726 > Loading cache: 100% > |#| > ETA: 00:00:00... > NOTE: Preparing runqueue > NOTE: Executing SetScene Tasks > NOTE: Executing RunQueue Tasks > WARNING: Failed to fetch URL > git://git.yoctoproject.org/linux-yocto-3.14.git;bareclone=1;branch=standard/common-pc/base,meta;name=machine,meta, > attempting MIRRORS if available > Currently 2 running tasks (238 of 551): > 0: linux-yocto-3.14+gitAUTOINC+fc8c30398d_0143c6ebb4-r0 do_fetch (pid 10446) > 1: binutils-cross-2.24-r0 do_compile (pid 15509) > ERROR: Logfile of failure stored in: > /OE/build/oe-core/tmp-eglibc/work/qemux86-oe-linux/linux-yocto/3.14+gitAUTOINC+fc8c30398d_0143c6ebb4-r0/temp/log.do_fetch.10446 > > > Currently 1 running tasks (238 of 551): > NOTE: Tasks Summary: Attempted 239 tasks of which 67 didn't need to be rerun > and 1 failed. > NOTE: Writing buildhistory > Waiting for 0 running tasks to finish: > > Summary: 1 task failed: > > /OE/build/oe-core/openembedded-core/meta/recipes-kernel/linux/linux-yocto_3.14.bb, > do_fetch > Summary: There was 1 WARNING message shown. > Summary: There were 2 ERROR messages shown, returning a non-zero exit code. > > It was removed and then created again (this isn't good proof, but I was > checking while the build was > running and the directory was gone): > > drwxr-xr-x 4 bitbake bitbake 4096 Apr 2 18:56 > downloads/git2/git.yoctoproject.org.linux-yocto-3.14.git > drwxr-xr-x 6 bitbake bitbake 4096 Apr 1 14:38 > downloads/git2/git.yoctoproject.org.linux-yocto-3.14.git-backup > > It's because fetcher is calling clean() before trying the MIRRORS, but I > think in this special case it's > a bit sad, because for very big repos the first thing I want to do is "git > branch -a --contains $SRCREV" > in downloads/git2/repo and it's already gone > > It can also increase the load we create on git servers, but I don't know if > we can correctly recover from > old kinds of fetcher issues without actually doing the clean(). E.g. if it > failed because of wrong permissions > on some directory... I think this is due to the use of mirror tarballs. If it finds a mirror tarball, it will try and use it however it has to clean the previous directory out the way to be able to extract the tarball. Its hard to know in advance if a mirror tarball will contain what we want but if it hasn't been able to fetch it through an update (git pull), it will try. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3] rootfs.py: introduce USE_DEVFS check
Since commit a83144bac8d67704ff66f5dc0fc56f5b63979694 (2014-02-11), USE_DEVFS
is not considered anymore.
For compatibility, let's restore USE_DEVFS semantic.
Also add USE_DEVFS to documentation.conf.
Signed-off-by: Matthieu Crapet
---
meta/conf/documentation.conf | 1 +
meta/lib/oe/rootfs.py| 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta/conf/documentation.conf b/meta/conf/documentation.conf
index 4d49a02..9d6e78f 100644
--- a/meta/conf/documentation.conf
+++ b/meta/conf/documentation.conf
@@ -436,6 +436,7 @@ UBOOT_MACHINE[doc] = "Specifies the value passed on the
make command line when b
UBOOT_MAKE_TARGET[doc] = "Specifies the target called in the Makefile."
UBOOT_SUFFIX[doc] = "Points to the generated U-Boot extension."
UBOOT_TARGET[doc] = "Specifies the target used for building U-Boot."
+USE_DEVFS[doc] = "When building images, specifies to populate or not /dev.
This variable defaults to '1' (leave directory empty, surely because devtmpfs
do the job). Set it to '0' to use makedevs (or consider using a custom file
with IMAGE_DEVICE_TABLES)."
USER_CLASSES[doc] = "List of additional classes to use when building images
that enable extra features."
USERADD_PACKAGES[doc] = "When a recipe inherits the useradd class, this
variable specifies the individual packages within the recipe that require users
and/or groups to be added."
USERADD_PARAM[doc] = "When a recipe inherits the useradd class, this variable
specifies for a package what parameters should be passed to the useradd command
if you wish to add a user to the system when the package is installed."
diff --git a/meta/lib/oe/rootfs.py b/meta/lib/oe/rootfs.py
index 3eac3c9..dddbef4 100644
--- a/meta/lib/oe/rootfs.py
+++ b/meta/lib/oe/rootfs.py
@@ -116,7 +116,8 @@ class Rootfs(object):
"offline and rootfs is read-only: %s" %
delayed_postinsts)
-self._create_devfs()
+if self.d.getVar('USE_DEVFS', True) != "1":
+self._create_devfs()
self._uninstall_uneeded()
--
1.8.5.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
