[OE-core] [PATCH 0/1] cairo: fix build error
From: Roy.Li rongqing...@windriver.com The following changes since commit cf59801be372bda962a94e6a406e97d20744ae45: licences: Add SGI license (2013-06-17 16:44:36 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib roy/cairo http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=roy/cairo Roy.Li (1): cairo: fix build error since toolchain has not get_feature command ...-check-stderr-when-test-compiling-in-conf.patch | 39 meta/recipes-graphics/cairo/cairo_1.12.14.bb |3 +- 2 files changed, 41 insertions(+), 1 deletion(-) create mode 100644 meta/recipes-graphics/cairo/cairo/cairo-don-t-check-stderr-when-test-compiling-in-conf.patch -- 1.7.10.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] cairo: fix build error since toolchain has not get_feature command
From: Roy.Li rongqing...@windriver.com
Signed-off-by: Roy.Li rongqing...@windriver.com
---
...-check-stderr-when-test-compiling-in-conf.patch | 39
meta/recipes-graphics/cairo/cairo_1.12.14.bb |3 +-
2 files changed, 41 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-graphics/cairo/cairo/cairo-don-t-check-stderr-when-test-compiling-in-conf.patch
diff --git
a/meta/recipes-graphics/cairo/cairo/cairo-don-t-check-stderr-when-test-compiling-in-conf.patch
b/meta/recipes-graphics/cairo/cairo/cairo-don-t-check-stderr-when-test-compiling-in-conf.patch
new file mode 100644
index 000..e04c3b2
--- /dev/null
+++
b/meta/recipes-graphics/cairo/cairo/cairo-don-t-check-stderr-when-test-compiling-in-conf.patch
@@ -0,0 +1,39 @@
+From 1581e5373c5917ed8ff6f7129c51160594c927d1 Mon Sep 17 00:00:00 2001
+From: Song.Li song...@windriver.com
+Date: Mon, 30 Jul 2012 16:38:02 +0800
+Subject: [PATCH] cairo:don't check stderr when test compiling in configure
+
+Upstream-Status: Pending
+
+cairo configure use a special macro to test compiling feature.
+It'll require no any warnings or errors in stderr.That is too strict.
+for example, when there is no get_feature in gcc,
+gcc will print no get_feature in stderr, but that is not a real error.
+so let cairo don't check stderr,just check the return value of compiling
+is enough.
+
+Signed-off-by: Song.Li song...@windriver.com
+---
+ build/aclocal.cairo.m4 |6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/build/aclocal.cairo.m4 b/build/aclocal.cairo.m4
+index 592e168..4de3b26 100644
+--- a/build/aclocal.cairo.m4
b/build/aclocal.cairo.m4
+@@ -106,9 +106,9 @@ AC_DEFUN([CAIRO_CC_TRY_LINK_WITH_ENV_SILENT],[dnl
+ [cairo_cc_stderr=`test -f conftest.err cat conftest.err`
+cairo_cc_flag=no])
+
+- if test x$cairo_cc_stderr != x; then
+- cairo_cc_flag=no
+- fi
++dnl if test x$cairo_cc_stderr != x; then
++dnl cairo_cc_flag=no
++dnl fi
+
+ if test x$cairo_cc_flag = xyes; then
+ ifelse([$3], , :, [$3])
+--
+1.7.9.5
+
diff --git a/meta/recipes-graphics/cairo/cairo_1.12.14.bb
b/meta/recipes-graphics/cairo/cairo_1.12.14.bb
index 40aa169..5c8c9cd 100644
--- a/meta/recipes-graphics/cairo/cairo_1.12.14.bb
+++ b/meta/recipes-graphics/cairo/cairo_1.12.14.bb
@@ -5,7 +5,8 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=e73e999e0c72b5ac9012424fa157ad77
PR = r0
SRC_URI = http://cairographics.org/releases/cairo-${PV}.tar.xz \
- file://png.patch
+ file://png.patch \
+ file://cairo-don-t-check-stderr-when-test-compiling-in-conf.patch
SRC_URI[md5sum] = 27b634113d0f52152d60ae8e2ec7daa7
SRC_URI[sha256sum] =
96d0d1e3f9b74d2ca3469ff187c5e5f25649b1ad35cf06f4f3a83847dff4ac13
--
1.7.10.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] base-files: create /usr/lib/locale dir
From: Roy.Li rongqing...@windriver.com
Lsbtest shows that /usr/lib/locale dir is lost, so create it
Signed-off-by: Roy.Li rongqing...@windriver.com
---
meta/recipes-core/base-files/base-files_3.0.14.bb |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/base-files/base-files_3.0.14.bb
b/meta/recipes-core/base-files/base-files_3.0.14.bb
index ac85ed9..fa1cc58 100644
--- a/meta/recipes-core/base-files/base-files_3.0.14.bb
+++ b/meta/recipes-core/base-files/base-files_3.0.14.bb
@@ -36,7 +36,7 @@ dirs2775 = /home ${prefix}/src ${localstatedir}/local
dirs755 = /bin /boot /dev ${sysconfdir} ${sysconfdir}/default \
${sysconfdir}/skel /lib /mnt /proc ${ROOT_HOME} /run /sbin \
${prefix} ${bindir} ${docdir} /usr/games ${includedir} \
- ${libdir} ${sbindir} ${datadir} \
+ ${libdir} /usr/lib/locale ${sbindir} ${datadir} \
${datadir}/common-licenses ${datadir}/dict ${infodir} \
${mandir} ${datadir}/misc ${localstatedir} \
${localstatedir}/backups ${localstatedir}/lib \
--
1.7.10.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] base-files: create /usr/lib/locale dir
From: Roy.Li rongqing...@windriver.com The following changes since commit cf59801be372bda962a94e6a406e97d20744ae45: licences: Add SGI license (2013-06-17 16:44:36 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib roy/base-files http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=roy/base-files Roy.Li (1): base-files: create /usr/lib/locale dir meta/recipes-core/base-files/base-files_3.0.14.bb |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 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 1/1] base-files: create /usr/lib/locale dir
On Tue, 2013-06-18 at 15:19 +0800, rongqing...@windriver.com wrote:
- ${libdir} ${sbindir} ${datadir} \
+ ${libdir} /usr/lib/locale ${sbindir} ${datadir} \
This is bogus for a number of reasons. If the only reason for having it
is for lsbtest, can't it go in some LSB recipe?
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/1] base-files: create /usr/lib/locale dir
On Tuesday, 18 June 2013, wrote:
- ${libdir} ${sbindir} ${datadir} \
+ ${libdir} /usr/lib/locale ${sbindir} ${datadir} \
What Phil said, but also please don't hard-code paths - the rest of the
variable uses ${libdir} for a reason.
Ross
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] matchbox-panel: bump SRCREV for linkage fixes
Newer toolchains are stricter with linking. Patches have been merged upstream
so bump the SRCREV to use them.
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/recipes-sato/matchbox-panel-2/matchbox-panel-2_git.bb |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-sato/matchbox-panel-2/matchbox-panel-2_git.bb
b/meta/recipes-sato/matchbox-panel-2/matchbox-panel-2_git.bb
index 1160b87..ba2780b 100644
--- a/meta/recipes-sato/matchbox-panel-2/matchbox-panel-2_git.bb
+++ b/meta/recipes-sato/matchbox-panel-2/matchbox-panel-2_git.bb
@@ -11,7 +11,7 @@ DEPENDS = gnome-common gtk+ startup-notification dbus
dbus-glib
DEPENDS += ${@base_contains(MACHINE_FEATURES, acpi, libacpi, ,d)}
DEPENDS += ${@base_contains(MACHINE_FEATURES, apm, apmd, ,d)}
-SRCREV = c03234512784b78a95b5aa9ca445d05836b9d51a
+SRCREV = 26a3a67b41c50e0ae163d8fe86ccf7a0f0a671ae
PV = 2.0+git${SRCPV}
PR = r0
--
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] sato-screenshot: bump SRCREV for linkage fixes
Newer toolchains are stricter with linking. Patches have been merged upstream
so bump the SRCREV to use them.
fix_ldadd_order was also merged upstream, so delete it.
Signed-off-by: Ross Burton ross.bur...@intel.com
---
.../sato-screenshot/files/fix_ldadd_order.patch | 15 ---
.../recipes-sato/sato-screenshot/sato-screenshot_git.bb |5 ++---
2 files changed, 2 insertions(+), 18 deletions(-)
delete mode 100644
meta/recipes-sato/sato-screenshot/files/fix_ldadd_order.patch
diff --git a/meta/recipes-sato/sato-screenshot/files/fix_ldadd_order.patch
b/meta/recipes-sato/sato-screenshot/files/fix_ldadd_order.patch
deleted file mode 100644
index 7d9689e..000
--- a/meta/recipes-sato/sato-screenshot/files/fix_ldadd_order.patch
+++ /dev/null
@@ -1,15 +0,0 @@
-Fix the ordering of LDADD options to fix a compilation failure.
-
-Signed-off-by: Scott Garman scott.a.gar...@intel.com
-
-Upstream-Status: Inappropriate [configuration]
-
-diff -urN screenshot.orig//Makefile.am screenshot/Makefile.am
screenshot.orig//Makefile.am 2010-06-29 11:55:00.0 -0700
-+++ screenshot/Makefile.am 2011-03-01 11:09:01.215813968 -0800
-@@ -23,4 +23,4 @@
- # A standalone tool for running from a terminal and scripts
- bin_PROGRAMS = screenshot
- screenshot_SOURCES = main.c
--screenshot_LDADD = $(GTK_LIBS) libshot.la
-+screenshot_LDADD = libshot.la $(GTK_LIBS)
diff --git a/meta/recipes-sato/sato-screenshot/sato-screenshot_git.bb
b/meta/recipes-sato/sato-screenshot/sato-screenshot_git.bb
index ff92142..3bad853 100644
--- a/meta/recipes-sato/sato-screenshot/sato-screenshot_git.bb
+++ b/meta/recipes-sato/sato-screenshot/sato-screenshot_git.bb
@@ -8,12 +8,11 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
file://screenshot-ui.h;endline=9;md5=638d9ffa83e9325a36df224166ed6ad0
DEPENDS = matchbox-panel-2
-SRCREV = c792e4edc758bab21e0b01814979eacf0b1af945
+SRCREV = 3a9688e8a01b63a78f402b4e7c0b8b005fcdfa29
PV = 0.1+git${SRCPV}
PR = r2
-SRC_URI = git://git.yoctoproject.org/screenshot;protocol=git \
- file://fix_ldadd_order.patch
+SRC_URI = git://git.yoctoproject.org/screenshot;protocol=git
S = ${WORKDIR}/git
--
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 0/1] base-files: create /usr/lib/locale dir
On 06/18/2013 04:24 PM, Burton, Ross wrote:
On Tuesday, 18 June 2013, wrote:
- ${libdir} ${sbindir} ${datadir} \
+ ${libdir} /usr/lib/locale ${sbindir} ${datadir} \
What Phil said, but also please don't hard-code paths - the rest of the
variable uses ${libdir} for a reason.
${libdir}/locale can be /usr/lib/locale, or /usr/lib64/locale,
but localedef only thinks /usr/lib/locale as its default
outputpath(man localedef), can not /usr/lib64/locale, or
other.
-Roy
Ross
--
Best Reagrds,
Roy | RongQing Li
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] base-files: create /usr/lib/locale dir
On 06/18/2013 04:07 PM, Phil Blundell wrote:
On Tue, 2013-06-18 at 15:19 +0800, rongqing...@windriver.com wrote:
- ${libdir} ${sbindir} ${datadir} \
+ ${libdir} /usr/lib/locale ${sbindir} ${datadir} \
This is bogus for a number of reasons. If the only reason for having it
is for lsbtest, can't it go in some LSB recipe?
p.
Thanks, How about put it into do_install_append_linuxstdbase
diff --git a/meta/recipes-core/base-files/base-files_3.0.14.bb
b/meta/recipes-core/base-files/base-files_3.0.14.bb
index fa1cc58..84663e3 100644
--- a/meta/recipes-core/base-files/base-files_3.0.14.bb
+++ b/meta/recipes-core/base-files/base-files_3.0.14.bb
@@ -139,6 +139,7 @@ do_install_append_linuxstdbase() {
for d in ${dirs4775}; do
install -m 2755 -d ${D}$d
done
+ install -m 755 -d ${D}/usr/lib/locale
}
PACKAGES = ${PN}-doc ${PN} ${PN}-dev ${PN}-dbg
-Roy
--
Best Reagrds,
Roy | RongQing Li
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] base-files: create /usr/lib/locale dir
On Tue, 2013-06-18 at 16:42 +0800, Rongqing Li wrote:
diff --git a/meta/recipes-core/base-files/base-files_3.0.14.bb
b/meta/recipes-core/base-files/base-files_3.0.14.bb
index fa1cc58..84663e3 100644
--- a/meta/recipes-core/base-files/base-files_3.0.14.bb
+++ b/meta/recipes-core/base-files/base-files_3.0.14.bb
@@ -139,6 +139,7 @@ do_install_append_linuxstdbase() {
for d in ${dirs4775}; do
install -m 2755 -d ${D}$d
done
+ install -m 755 -d ${D}/usr/lib/locale
Thanks, that looks better. Could you not just add it to ${dirs3755}
though? (Despite the confusing/misleading name, this variable appears
to be a list of LSB directories that should be created with mode 0755,
cf ${dirs4755} which is apparently directories to be created with mode
2755.)
In a stylistic sense it might be better to use ${prefix}/lib/locale (or
whatever eglibc uses), but in practice LSB requires ${prefix}==/usr,
and presumably lsbtest is looking for /usr/lib/locale specifically, so
I don't think it will actually make any functional difference in this
specific case.
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] core-image-weston: add weston-examples to the image
Signed-off-by: Ross Burton ross.bur...@intel.com --- meta/recipes-graphics/images/core-image-weston.bb |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-graphics/images/core-image-weston.bb b/meta/recipes-graphics/images/core-image-weston.bb index e49b205..cb9d7c7 100644 --- a/meta/recipes-graphics/images/core-image-weston.bb +++ b/meta/recipes-graphics/images/core-image-weston.bb @@ -6,4 +6,4 @@ LICENSE = MIT inherit core-image -CORE_IMAGE_BASE_INSTALL += weston weston-init gtk+3-demo +CORE_IMAGE_BASE_INSTALL += weston weston-init weston-examples gtk+3-demo -- 1.7.10.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [CONSOLIDATED PULL 00/37] Updates and some fixes
Hi,
Could you please consider following commits for dylan branch?
Muhammad Shakeel (1):
ofono: Add run time dependency for ofono test scripts
meta/recipes-connectivity/ofono/ofono.inc | 2 +-
Without this patch we will see run time error while executing some of the ofono
tests and this can be considered as bug fix.
Muhammad Shakeel (1):
openssl: Add fix for cipher des-ede3-cfb1
.../openssl-1.0.1e/fix-cipher-des-ede3-cfb1.patch | 22 ++
.../recipes-connectivity/openssl/openssl_1.0.1e.bb | 1 +
Without this patch we will see functional error if this cipher is used.
Sorry for not mentioning it on initial subject line.
Best Regards,
Shakeel
From: openembedded-core-boun...@lists.openembedded.org
[openembedded-core-boun...@lists.openembedded.org] on behalf of Saul Wold
[s...@linux.intel.com]
Sent: Thursday, June 13, 2013 9:19 PM
To: openembedded-core@lists.openembedded.org
Subject: [OE-core] [CONSOLIDATED PULL 00/37] Updates and some fixes
Richard,
This is a group of updates and some patches that have been
pulled together and built on the Autobuilder
There's a Chris patch to sstate.bbclass that needs your eyes.
Thanks
Sau!
The following changes since commit 74158c2e99c6d8631800ae80025d1cc9f19336d2:
tune-cortexa*.inc: fix tunings for cortex a5, a7, a8, a9, a15 machines.
(2013-06-12 17:54:28 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib sgw/stage
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=sgw/stage
Andrei Dinu (1):
gzip : upgrade to 1.6
Christopher Larson (2):
sstate.bbclass: brute force silence fetch errors
libnewt: split python module into libnewt-python
Felipe F. Tonello (1):
qt: update qmake2 class to export qconfig.pri mkspec
Jonathan Liu (2):
util-linux: update to 2.23.1
classes/qmake_base: allow parallel make
Khem Raj (1):
gcc: Upgrade to 4.8.1
Laurentiu Palcu (7):
xf86-input-synaptics: upgrade to 1.7.1
xkeyboard-config: upgrade to 2.9
xdpyinfo: upgrade to 1.3.1
xf86-video-intel: upgrade to 2.21.9
xwininfo: upgrade to 1.1.3
libdrm: upgrade to 2.4.45
libxt: upgrade to 1.1.4
Muhammad Shakeel (1):
ofono: Add run time dependency for ofono test scripts
Riku Voipio (1):
qemu: update to 1.5.0
Ross Burton (6):
runqemu: when tunctl can't be found, say what package builds it
site: add more alignment values for at-spi2-core
dpkg: drop the usage of create_wrapper
python-native: add nativepython symlink
createrepo: drop the usage of create_wrapper
gnome-doc-utils: drop the usage of create_wrapper
Roy.Li (2):
wpa-supplicant: Enable EXTRA_CFLAGS
latencytop: Deprecate tracing_enabled for tracing_on
Saul Wold (11):
socat: Update to 1.7.2.2
cmake: Update to 2.8.11.1
help2man: Update to 1.43.2
cracklib: Update to 2.9.0
cups: Update to 1.6.2
libidn: Update to 1.27
lsbinitscripts: Update to 9.47
sysstat: Update to 10.1.6
libxkbcommon: Update to 0.3.1
libusb: Update tp 0.1.5
nspr: Update to 4.10
Stefan Stanacar (2):
scripts/contrib/build-perf-test.sh: add branch name and sizes to
results
scripts/contrib/build-perf-test.sh: fix passing arguments
meta/classes/qmake2.bbclass| 1 +
meta/classes/qmake_base.bbclass| 2 +-
meta/classes/sstate.bbclass| 5 +
meta/conf/distro/include/tcmode-default.inc| 2 +-
meta/recipes-connectivity/ofono/ofono.inc | 2 +-
.../socat/{socat_1.7.2.1.bb = socat_1.7.2.2.bb} | 11 +-
.../wpa-supplicant/wpa-supplicant-2.0.inc | 1 +
...-fix-loopcxt_check_size-to-work-with-blkd.patch | 60 --
...etup-use-warn_size-for-regular-files-only.patch | 29 ---
.../{util-linux_2.23.bb = util-linux_2.23.1.bb} | 7 +-
.../cmake/cmake-native_2.8.11.1.bb | 5 +
meta/recipes-devtools/cmake/cmake-native_2.8.11.bb | 5 -
.../cmake/{cmake_2.8.11.bb = cmake_2.8.11.1.bb} | 4 +-
meta/recipes-devtools/dpkg/dpkg.inc| 10 +-
meta/recipes-devtools/gcc/gcc-4.8.inc | 8 +-
...-native_1.41.2.bb = help2man-native_1.43.2.bb} | 5 +-
.../recipes-devtools/python/python-native_2.7.3.bb | 6 +
...x-texinfo-table-markup-in-qemu-options.hx.patch | 213 -
...x-generating-qemu-doc.html-with-texinfo-5.patch | 54 --
...re_vga-Add-back-some-info-in-local-state-.patch | 114 ---
meta/recipes-devtools/qemu/files/arm-bgr.patch | 30 ---
.../files/fallback-to-safe-mmap_min_addr.patch | 39
.../recipes-devtools/qemu/files/linker-flags.patch | 25 ---
meta/recipes-devtools/qemu/qemu.inc| 7 +-
.../qemu/{qemu_1.4.1.bb = qemu_1.5.0.bb} | 4 +-
.../{cracklib_2.8.22.bb = cracklib_2.9.0.bb} | 5 +-
meta/recipes-extended/cups/cups16.inc | 2 +-
.../cups/{cups_1.6.1.bb = cups_1.6.2.bb} | 4 +-
[OE-core] [oe-core][patch] sanity.bbclass: correct the gcc_arch check logic
The gcc arch check result is incorrect when gcc version is older than 4.5.
Sanity checker requests user to add -march=native into BUILD_CFLAGS even if
the flag is not supported by host gcc.
The status is 0 when -march=native is supported by host gcc, so set result to
True, otherwise set result to False, the compare express is changed to be more
explicit.
Signed-off-by: Zhenhua Luo zhenhua@freescale.com
---
meta/classes/sanity.bbclass |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index 3b9934b..047baa5 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -325,7 +325,7 @@ def check_gcc_march(sanity_data):
if status != 0:
# Check if GCC could work with march
status,result = oe.utils.getstatusoutput(${BUILD_PREFIX}gcc
-march=native gcc_test.c -o gcc_test)
-if status != 0:
+if status == 0:
result = True
else:
result = False
@@ -485,7 +485,7 @@ def check_sanity(sanity_data):
if not check_app_exists(qemu-arm, sanity_data):
messages = messages + qemu-native was in ASSUME_PROVIDED but the
QEMU binaries (qemu-arm) can't be found in PATH
-if check_gcc_march(sanity_data):
+if check_gcc_march(sanity_data) == True:
messages = messages + Your gcc version is older than 4.5, please add
the following param to local.conf\n \
BUILD_CFLAGS_append = \ -march=native\\n
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][patch] sanity.bbclass: correct the gcc_arch check logic
On 18 June 2013 11:55, Zhenhua Luo zhenhua@freescale.com wrote: -if check_gcc_march(sanity_data): +if check_gcc_march(sanity_data) == True: Unless there's something I've forgotten about Python, these two are exactly equivalent. -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] xinput-calibrator: move it from meta-oe to oe-core
On Mon, Jun 17, 2013 at 04:15:58PM +0100, Burton, Ross wrote: On 17 June 2013 13:26, Laurentiu Palcu laurentiu.pa...@intel.com wrote: People using xserver-xorg that need to calibrate their touchscreen devices would also need meta-oe. Bringing the recipes to oe-core will make it easier for them. Aditionaly, drop xterm RDEPENDS. Terminal is not needed to run the menu item. I don't really like how there's a xdg-autostart desktop file and a systemd service file for loading the calibration and performing calibration - a single xsession file as xtscal does will be sufficient and actually work in Sato as it can block the rest of the UI before continuing. I'm not sure I understand what's wrong with using xdg-autostart. Xsession parses each .desktop file in xdg/autostart and executes the application listed in 'Exec'. Having a separate xsession file created in /etc/X11/Xsession.d (like xtscal does) is, basically, the same thing. Only the moment of execution differs. Or, maybe, I misunderstood your point. Also persistent calibration doesn't work with non-root X users, so maybe the tool should use ~/.pointercal.xinput if it can't write to /etc. We could easily change xinput_calibrator_once.sh to save/read the calibration data either to/from /etc or ~. Laurentiu Apart from that I've got a touchscreen that isn't X-axis-reversed now. :) Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Fix for kernel 3.8/gcc-4.8 segfault on qemuarm
On Tue, Jun 18, 2013 at 1:25 AM, Khem Raj raj.k...@gmail.com wrote: On Jun 17, 2013, at 9:58 PM, Bruce Ashfield bruce.ashfi...@windriver.com wrote: On 13-06-18 12:41 AM, Khem Raj wrote: On Jun 17, 2013, at 9:37 PM, Bruce Ashfield bruce.ashfi...@windriver.com wrote: On 13-06-17 11:30 PM, Khem Raj wrote: Hi Bruce and All Finally after a long innings I have diagnosed the mystery behind the below segfault that we see on kernel 3.8 which compiled with gcc 4.8 but don't show when compiled with gcc 4.7 There also seems to be a follow up patch: commit 418df63adac56841ef6b0f1fcf435bc64d4ed177 Author: Nicolas Pitre nicolas.pi...@linaro.org Date: Tue Mar 12 13:00:42 2013 +0100 ARM: 7670/1: fix the memset fix Commit 455bd4c430b0 (ARM: 7668/1: fix memset-related crashes caused by recent GCC (4.7.2) optimizations) attempted to fix a compliance issue with the memset return value. However the memset itself became broken by that patch for misaligned pointers. This fixes the above by branching over the entry code from the misaligned fixup code to avoid reloading the original pointer. Also, because the function entry alignment is wrong in the Thumb mode compilation, that fixup code is moved to the end. While at it, the entry instructions are slightly reworked to help dual issue pipelines. Signed-off-by: Nicolas Pitre n...@linaro.org Tested-by: Alexander Holler hol...@ahsoftware.de Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk :100644 100644 d912e73... 94b0650... M arch/arm/lib/memset.S I've staged it as well, and will do a boot test in the morning once my build has completed. Time to call it a night here. I did not need anything other than the first patch to get over the segfault. but yes it completes the fix so having both is better So very strange. I got one segfault, and then this: Linux version 3.8.13-yocto-standard (bruce@yow-bashfiel-d2) (gcc version 4.8.1 (GCC) ) #2 PREEMPT Tue Jun 18 00:36:55 EDT 2013 snip qemuarm login: root root@qemuarm:~# uname -a Linux qemuarm 3.8.13-yocto-standard #2 PREEMPT Tue Jun 18 00:36:55 EDT 2013 armv5tejl GNU/Linux Which means I may have just been unlucky on my testing with 3.10, or something else is going on. Well I have been booting latest linus's (3.10-rc6) master compiled with gcc 4.8 just one patch from linux-yocto see below Very odd. I would have just done the bisection myself, but my starting known point good point .. was a fail. So I've instead been looking at assembly dumps of memory management routines. http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.8/commit/?h=standard/arm-versatile-926ejsid=351d133943b50a9dfeee07661d44254722a19f04 I wonder why this patch hasn't made upstream yet. It was sent upstream, and rmk wanted to go to ARM ltd to rework the patch after getting some boards specs. Looks like the process is still ongoing. Cheers, Bruce ___ 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 1/2] strace: update depends
On 2013年06月17日 23:11, Richard Purdie wrote:
On Sun, 2013-06-16 at 22:16 +0800, Kai Kang wrote:
Build strace with libaio and acl to support more features. Because no
native libaio package, just add dependencies for target.
Signed-off-by: Kai Kang kai.k...@windriver.com
---
meta/recipes-devtools/strace/strace_4.7.bb |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
Shouldn't this be implemented like the other packages as PACKAGECONFIG
options? That is how acl is handled elsewhere at least...
Yes, PACKAGECONFIG is the right way. I'll send V2.
Thanks,
Kai
Cheers,
Richard
diff --git a/meta/recipes-devtools/strace/strace_4.7.bb
b/meta/recipes-devtools/strace/strace_4.7.bb
index e360e63..bcc7bd9 100644
--- a/meta/recipes-devtools/strace/strace_4.7.bb
+++ b/meta/recipes-devtools/strace/strace_4.7.bb
@@ -5,6 +5,8 @@ LICENSE = BSD
LIC_FILES_CHKSUM = file://COPYRIGHT;md5=124500c21e856f0912df29295ba104c7
PR = r4
+DEPENDS_class-target += libaio acl
+
SRC_URI = ${SOURCEFORGE_MIRROR}/strace/strace-${PV}.tar.xz \
file://0003-util-fix-building-when-glibc-has-a-stub-process_vm_r.patch \
file://0014-x32-update-syscall-table.patch \
--
Regards,
Neil | Kai Kang
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V2 1/9] busybox: remove the postinst part of the recipe
On Mon, Jun 17, 2013 at 10:37 PM, ChenQi qi.c...@windriver.com wrote:
On 06/18/2013 01:52 AM, Otavio Salvador wrote:
On Mon, Jun 17, 2013 at 2:49 AM, qi.c...@windriver.com wrote:
From: Chen Qi qi.c...@windriver.com
Remove the pkg_postinst_${PN} from this recipe, as it's redundant.
It basically wants to do the same thing as the update-alternatives
does. But it doesn't do it well.
Signed-off-by: Chen Qi qi.c...@windriver.com
Most of patch 1 and 2 should be merged; here you should drop the
postinst and convert these to the update-alternative way so we don't
have the tree broken after this patch and allow for bisect to be
used.
Hi Otavio,
Maybe there's some misunderstanding here.
To be clear, patch 1 and patch 2 do two different things.
Patch 1 removes postinst, it has nothing to do with patch 2, which fix
busybox.inc to support the FEATURE_INDIVIDUAL.
And after this patch (patch 1), the tree is not broken. The busybox still
works as it has been working so far.
[
And I just did a simple test to confirm this. On the lastest master, I
removed the postinst part of busybox.inc, and built a core-image-minimal, it
worked out well. Here's some output.
root@qemuarm:~# ls -l /bin/ | grep busybox
lrwxrwxrwx1 root root12 Jun 18 01:31 ash - /bin/busybox
-rwsr-xr-x1 root root556824 Jun 18 01:27 busybox
lrwxrwxrwx1 root root12 Jun 18 01:31 cat - /bin/busybox
lrwxrwxrwx1 root root12 Jun 18 01:31 chattr -
/bin/busybox
lrwxrwxrwx1 root root12 Jun 18 01:31 chgrp -
/bin/busybox
lrwxrwxrwx1 root root12 Jun 18 01:31 chmod -
/bin/busybox
lrwxrwxrwx1 root root12 Jun 18 01:31 chown -
/bin/busybox
lrwxrwxrwx1 root root12 Jun 18 01:31 cp - /bin/busybox
]
Oh I see.
So I have no objection for the patch :-)
Thanks by letting me know.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://projetos.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 1/1] init-live.sh: fix automount failed occasionally
Reboot system repeatedly, occasionally found usb automount failed, a
low probability but it happens.
$ df
Filesystem 1K-blocks Used Available Use% Mounted on
none 1024972 4 1024968 0% /dev
/dev/sda3 7689384 3540940 3757840 49% /media/sda3
/dev/sda2146127424 1238432 137466120 1% /media/sda2
/dev/sda117845 14570 2354 86% /media/sda1
/dev/sdb293400288560 4840 98% /media/sdb
/dev/sdc4 45763232457600 0% /media/sdc4
/dev/sdc1 475018 2321447749 1% /media/sdc1
/dev/sdd 1382298 1382298 0 100% /media/sdd
/dev/sdc2 475694 2320448374 1% /media/sdc2
/dev/loop0 270649181249 75644 71% /
df: /media/sdc3: No such file or directory
tmpfs 1029352 0 1029352 0% /dev/shm
tmpfs 1029352 2816 1026536 0% /run
tmpfs 1029352 0 1029352 0% /sys/fs/cgroup
tmpfs 1029352 4 1029348 0% /tmp
tmpfs 1029352 0 1029352 0% /media/ram
tmpfs 1029352 116 1029236 0% /var/volatile
When boot media has been found, udev will be killed. If udev is busy
to mount other medias at the killing time (especially medias is many),
the above issue will occur occasionally.
Invoke `udevadm settle' before killing udev will resolve this
issue, it watches the udev event queue, and exits if all current
events are handled.
Use variable `_UDEV_DAEMON' to replace hardcoded `udevd' to keep
consistent with previous.
[YOCTO #4745]
Signed-off-by: Hongxu Jia hongxu@windriver.com
---
meta/recipes-core/initrdscripts/files/init-live.sh | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-core/initrdscripts/files/init-live.sh
b/meta/recipes-core/initrdscripts/files/init-live.sh
index 804e16e..82042bf 100644
--- a/meta/recipes-core/initrdscripts/files/init-live.sh
+++ b/meta/recipes-core/initrdscripts/files/init-live.sh
@@ -75,7 +75,9 @@ read_args() {
}
boot_live_root() {
-killall udevd 2/dev/null
+# Watches the udev event queue, and exits if all current events are handled
+udevadm settle --timeout=3 --quiet
+killall ${_UDEV_DAEMON##*/} 2/dev/null
# Move the mount points of some filesystems over to
# the corresponding directories under the real root filesystem.
--
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/1]init-live.sh: fix automount failed occasionally
The following changes since commit 1dd643b142c69ac9035e29bff11d02201638dc65: licences: Add SGI license (2013-06-17 16:45:37 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib hongxu/fix-coldplug http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=hongxu/fix-coldplug Hongxu Jia (1): init-live.sh: fix automount failed occasionally meta/recipes-core/initrdscripts/files/init-live.sh | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) -- 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/1] systemd-udevd: fix invoking init script failed
root@emenlow-noemgd:~# /etc/init.d/systemd-udevd restart
Stopping udevd
Starting udev
corrupt queue file
root@emenlow-noemgd:~# /etc/init.d/systemd-udevd status
udevd is stopped
root@emenlow-noemgd:~# ps
3805 root 8728 S/lib/systemd/systemd-udevd
The process name is systemd-udevd rather than udev which is
used in systemd-udevd's init script.
[YOCTO #4746]
Signed-off-by: Hongxu Jia hongxu@windriver.com
---
meta/recipes-core/systemd/systemd/init | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/systemd/systemd/init
b/meta/recipes-core/systemd/systemd/init
index 7e67a50..41c4136 100644
--- a/meta/recipes-core/systemd/systemd/init
+++ b/meta/recipes-core/systemd/systemd/init
@@ -83,7 +83,7 @@ case $1 in
;;
stop)
echo Stopping udevd
-start-stop-daemon --stop --name udevd --quiet
+start-stop-daemon --stop --name systemd-udevd --quiet
;;
restart)
$0 stop
@@ -91,7 +91,7 @@ case $1 in
$0 start
;;
status)
-status udevd
+status systemd-udevd
;;
*)
echo Usage: $0 {start|stop|status|restart}
--
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/1]systemd-udevd: fix invoking init script failed
The following changes since commit 1dd643b142c69ac9035e29bff11d02201638dc65: licences: Add SGI license (2013-06-17 16:45:37 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib hongxu/fix-systemd-udevd http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=hongxu/fix-systemd-udevd Hongxu Jia (1): systemd-udevd: fix invoking init script failed meta/recipes-core/systemd/systemd/init | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- 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 1/1] systemd-udevd: fix invoking init script failed
On 18 June 2013 13:25, Hongxu Jia hongxu@windriver.com wrote: root@emenlow-noemgd:~# /etc/init.d/systemd-udevd restart Stopping udevd Starting udev corrupt queue file root@emenlow-noemgd:~# /etc/init.d/systemd-udevd status udevd is stopped root@emenlow-noemgd:~# ps 3805 root 8728 S/lib/systemd/systemd-udevd The process name is systemd-udevd rather than udev which is used in systemd-udevd's init script. [YOCTO #4746] Signed-off-by: Ross Burton ross.bur...@intel.com Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [oe-core][patch v2] sanity.bbclass: correct the gcc_arch check logic
The gcc arch check result is incorrect when gcc version is older than 4.5.
Sanity checker requests user to add -march=native into BUILD_CFLAGS even if
the flag is not supported by host gcc.
The status is 0 when -march=native is supported by host gcc, so set result to
True, otherwise set result to False.
Signed-off-by: Zhenhua Luo zhenhua@freescale.com
---
meta/classes/sanity.bbclass |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index 3b9934b..ee09679 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -325,7 +325,7 @@ def check_gcc_march(sanity_data):
if status != 0:
# Check if GCC could work with march
status,result = oe.utils.getstatusoutput(${BUILD_PREFIX}gcc
-march=native gcc_test.c -o gcc_test)
-if status != 0:
+if status == 0:
result = True
else:
result = False
--
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 1/1] xinput-calibrator: move it from meta-oe to oe-core
On 18 June 2013 11:58, Laurentiu Palcu laurentiu.pa...@intel.com wrote: I'm not sure I understand what's wrong with using xdg-autostart. Xsession parses each .desktop file in xdg/autostart and executes the application listed in 'Exec'. Having a separate xsession file created in /etc/X11/Xsession.d (like xtscal does) is, basically, the same thing. Only the moment of execution differs. Or, maybe, I misunderstood your point. XDG autostart doesn't block the app, so the rest of the system starts up. Really calibration should pause the startup and only when the input is calibrated, continue. Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][patch v2] sanity.bbclass: correct the gcc_arch check logic
On Tue, 2013-06-18 at 21:08 +0800, Zhenhua Luo wrote:
The gcc arch check result is incorrect when gcc version is older than 4.5.
Sanity checker requests user to add -march=native into BUILD_CFLAGS even if
the flag is not supported by host gcc.
The status is 0 when -march=native is supported by host gcc, so set result to
True, otherwise set result to False.
Signed-off-by: Zhenhua Luo zhenhua@freescale.com
---
meta/classes/sanity.bbclass |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index 3b9934b..ee09679 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -325,7 +325,7 @@ def check_gcc_march(sanity_data):
if status != 0:
# Check if GCC could work with march
status,result = oe.utils.getstatusoutput(${BUILD_PREFIX}gcc
-march=native gcc_test.c -o gcc_test)
-if status != 0:
+if status == 0:
result = True
else:
result = False
Can you and Randy please sort out what the correct value is here please.
This appears to directly revert
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=ad276d7d89190c57a152867d7278ee18f784ff2c
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/2] Update strace and fix autogen-native build failure
The following changes since commit 1dd643b142c69ac9035e29bff11d02201638dc65: licences: Add SGI license (2013-06-17 16:45:37 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib kangkai/update-strace http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=kangkai/update-strace Kai Kang (2): autogen-native: fix build failure on overloaded hosts strace: update to 4.8 .../autogen/autogen-native_5.17.4.bb |3 +- .../autogen/files/increase-timeout-limit.patch | 33 + ...ilding-when-glibc-has-a-stub-process_vm_r.patch | 54 - .../strace-4.7/0014-x32-update-syscall-table.patch | 91 - ...-x32-update-g-s-etsockopt-syscall-numbers.patch | 43 - .../0024-x32-add-64bit-annotation-too.patch| 231 -- .../0025-Add-e-trace-memory-option.patch | 2898 ...ew-errno-values-for-EPROBE_DEFER-and-EOPE.patch | 36 - .../0027-Add-AArch64-support-to-strace.patch | 542 .../0028-Enhance-quotactl-decoding.patch | 391 --- ...029-Filter-out-redundant-32-ioctl-entries.patch | 145 - ...neric-ioctl-definitions-to-linux-ioctlent.patch | 571 ...-for-tracing-32-bit-ARM-EABI-binaries-on-.patch | 963 --- .../0032-Fix-kernel-release-string-parsing.patch | 38 - .../strace/strace-4.8/git-version-gen | 225 ++ meta/recipes-devtools/strace/strace_4.7.bb | 34 - meta/recipes-devtools/strace/strace_4.8.bb | 32 + 17 files changed, 292 insertions(+), 6038 deletions(-) create mode 100644 meta/recipes-devtools/autogen/files/increase-timeout-limit.patch delete mode 100644 meta/recipes-devtools/strace/strace-4.7/0003-util-fix-building-when-glibc-has-a-stub-process_vm_r.patch delete mode 100644 meta/recipes-devtools/strace/strace-4.7/0014-x32-update-syscall-table.patch delete mode 100644 meta/recipes-devtools/strace/strace-4.7/0018-x32-update-g-s-etsockopt-syscall-numbers.patch delete mode 100644 meta/recipes-devtools/strace/strace-4.7/0024-x32-add-64bit-annotation-too.patch delete mode 100644 meta/recipes-devtools/strace/strace-4.7/0025-Add-e-trace-memory-option.patch delete mode 100644 meta/recipes-devtools/strace/strace-4.7/0026-linux-add-new-errno-values-for-EPROBE_DEFER-and-EOPE.patch delete mode 100644 meta/recipes-devtools/strace/strace-4.7/0027-Add-AArch64-support-to-strace.patch delete mode 100644 meta/recipes-devtools/strace/strace-4.7/0028-Enhance-quotactl-decoding.patch delete mode 100644 meta/recipes-devtools/strace/strace-4.7/0029-Filter-out-redundant-32-ioctl-entries.patch delete mode 100644 meta/recipes-devtools/strace/strace-4.7/0030-Move-asm-generic-ioctl-definitions-to-linux-ioctlent.patch delete mode 100644 meta/recipes-devtools/strace/strace-4.7/0031-Add-support-for-tracing-32-bit-ARM-EABI-binaries-on-.patch delete mode 100644 meta/recipes-devtools/strace/strace-4.7/0032-Fix-kernel-release-string-parsing.patch create mode 100755 meta/recipes-devtools/strace/strace-4.8/git-version-gen delete mode 100644 meta/recipes-devtools/strace/strace_4.7.bb create mode 100644 meta/recipes-devtools/strace/strace_4.8.bb -- 1.7.5.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] autogen-native: fix build failure on overloaded hosts
On some overloaded hosts, shell commands of autogen may can not
finish in 5 secs. This has caused many build failures, so increase
the timeout limit to fix this.
Signed-off-by: Kai Kang kai.k...@windriver.com
---
.../autogen/autogen-native_5.17.4.bb |3 +-
.../autogen/files/increase-timeout-limit.patch | 33
2 files changed, 35 insertions(+), 1 deletions(-)
create mode 100644
meta/recipes-devtools/autogen/files/increase-timeout-limit.patch
diff --git a/meta/recipes-devtools/autogen/autogen-native_5.17.4.bb
b/meta/recipes-devtools/autogen/autogen-native_5.17.4.bb
index e5234c2..230c3a7 100644
--- a/meta/recipes-devtools/autogen/autogen-native_5.17.4.bb
+++ b/meta/recipes-devtools/autogen/autogen-native_5.17.4.bb
@@ -9,7 +9,8 @@ LICENSE = GPLv3
LIC_FILES_CHKSUM = file://COPYING;md5=d32239bcb673463ab874e80d47fae504
SRC_URI = ${GNU_MIRROR}/autogen/rel${PV}/autogen-${PV}.tar.gz \
- file://guile.patch
+ file://guile.patch \
+ file://increase-timeout-limit.patch
SRC_URI[md5sum] = 09f074cba57610bf4ef1147e01c8ae90
SRC_URI[sha256sum] =
cd2585f4794d0e9d7f2cb0b9af4f2bd429946e718473edf1cf8c49f081ca71ed
diff --git a/meta/recipes-devtools/autogen/files/increase-timeout-limit.patch
b/meta/recipes-devtools/autogen/files/increase-timeout-limit.patch
new file mode 100644
index 000..3d4c1d6
--- /dev/null
+++ b/meta/recipes-devtools/autogen/files/increase-timeout-limit.patch
@@ -0,0 +1,33 @@
+Subject: [PATCH] autogen: increase timeout limit for shell commands
+
+On some overloaded hosts, shell commands of autogen may can not
+finish in 5 secs. This has caused many build failures, so increase
+the timeout limit to fix this.
+
+Upstream-Status: Inappropriate [configuration]
+
+Signed-off-by: Xin Ouyang xin.ouy...@windriver.com
+---
+ configure.ac |6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/configure.ac b/configure.ac
+index 0af7c18..5544f59 100644
+--- a/configure.ac
b/configure.ac
+@@ -175,9 +175,9 @@ config_end_time=`date +%s 2/dev/null`
+ time_delta=`expr ${config_end_time} - ${config_start_time} 2/dev/null`
+
+ if test -z ${time_delta}
+-then time_delta=10
+-elif test ${time_delta} -lt 5
+-then time_delta=5 ; fi
++then time_delta=60
++elif test ${time_delta} -lt 30
++then time_delta=30 ; fi
+
+ AG_TIMEOUT=${time_delta}
+ ]
+--
+1.7.9.5
+
--
1.7.5.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][patch v2] sanity.bbclass: correct the gcc_arch check logic
Hi Randy,
During the test on my machine with gcc-4.1.2, if -march=native is not supported
by host gcc, a non-zero value(256) returns, otherwise 0 returns.
[LOG]
status is 256
result is gcc_test.c:1: error: bad value (native) for -march= switch
gcc_test.c:1: error: bad value (native) for -mtune= switch
Please confirm if this is same as your result.
Best Regards,
Zhenhua
-Original Message-
From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
Sent: Tuesday, June 18, 2013 9:04 PM
To: Luo Zhenhua-B19537; Randy MacLeod
Cc: openembedded-core@lists.openembedded.org; Yu Zongchun-B40527
Subject: Re: [OE-core] [oe-core][patch v2] sanity.bbclass: correct the
gcc_arch check logic
On Tue, 2013-06-18 at 21:08 +0800, Zhenhua Luo wrote:
The gcc arch check result is incorrect when gcc version is older than
4.5.
Sanity checker requests user to add -march=native into BUILD_CFLAGS
even if the flag is not supported by host gcc.
The status is 0 when -march=native is supported by host gcc, so set
result to True, otherwise set result to False.
Signed-off-by: Zhenhua Luo zhenhua@freescale.com
---
meta/classes/sanity.bbclass |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index 3b9934b..ee09679 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -325,7 +325,7 @@ def check_gcc_march(sanity_data):
if status != 0:
# Check if GCC could work with march
status,result =
oe.utils.getstatusoutput(${BUILD_PREFIX}gcc -march=native gcc_test.c -o
gcc_test)
-if status != 0:
+if status == 0:
result = True
else:
result = False
Can you and Randy please sort out what the correct value is here please.
This appears to directly revert
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=ad276d7d89190c57a152
867d7278ee18f784ff2c
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] cairo: fix build error since toolchain has not get_feature command
On 6/18/13 1:02 AM, rongqing...@windriver.com wrote:
From: Roy.Li rongqing...@windriver.com
Signed-off-by: Roy.Li rongqing...@windriver.com
---
...-check-stderr-when-test-compiling-in-conf.patch | 39
meta/recipes-graphics/cairo/cairo_1.12.14.bb |3 +-
2 files changed, 41 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-graphics/cairo/cairo/cairo-don-t-check-stderr-when-test-compiling-in-conf.patch
diff --git
a/meta/recipes-graphics/cairo/cairo/cairo-don-t-check-stderr-when-test-compiling-in-conf.patch
b/meta/recipes-graphics/cairo/cairo/cairo-don-t-check-stderr-when-test-compiling-in-conf.patch
new file mode 100644
index 000..e04c3b2
--- /dev/null
+++
b/meta/recipes-graphics/cairo/cairo/cairo-don-t-check-stderr-when-test-compiling-in-conf.patch
@@ -0,0 +1,39 @@
+From 1581e5373c5917ed8ff6f7129c51160594c927d1 Mon Sep 17 00:00:00 2001
+From: Song.Li song...@windriver.com
+Date: Mon, 30 Jul 2012 16:38:02 +0800
+Subject: [PATCH] cairo:don't check stderr when test compiling in configure
+
+Upstream-Status: Pending
+
+cairo configure use a special macro to test compiling feature.
+It'll require no any warnings or errors in stderr.That is too strict.
+for example, when there is no get_feature in gcc,
+gcc will print no get_feature in stderr, but that is not a real error.
FYI -- 'get_feature' is something specific to Wind River. The patch is still
reasonable, but the commit description might need some cleanup for people not
familiar with some of our internal tools.
I'd suggest just removing the example part.
--Mark
+so let cairo don't check stderr,just check the return value of compiling
+is enough.
+
+Signed-off-by: Song.Li song...@windriver.com
+---
+ build/aclocal.cairo.m4 |6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/build/aclocal.cairo.m4 b/build/aclocal.cairo.m4
+index 592e168..4de3b26 100644
+--- a/build/aclocal.cairo.m4
b/build/aclocal.cairo.m4
+@@ -106,9 +106,9 @@ AC_DEFUN([CAIRO_CC_TRY_LINK_WITH_ENV_SILENT],[dnl
+ [cairo_cc_stderr=`test -f conftest.err cat conftest.err`
+cairo_cc_flag=no])
+
+- if test x$cairo_cc_stderr != x; then
+- cairo_cc_flag=no
+- fi
++dnl if test x$cairo_cc_stderr != x; then
++dnl cairo_cc_flag=no
++dnl fi
+
+ if test x$cairo_cc_flag = xyes; then
+ ifelse([$3], , :, [$3])
+--
+1.7.9.5
+
diff --git a/meta/recipes-graphics/cairo/cairo_1.12.14.bb
b/meta/recipes-graphics/cairo/cairo_1.12.14.bb
index 40aa169..5c8c9cd 100644
--- a/meta/recipes-graphics/cairo/cairo_1.12.14.bb
+++ b/meta/recipes-graphics/cairo/cairo_1.12.14.bb
@@ -5,7 +5,8 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=e73e999e0c72b5ac9012424fa157ad77
PR = r0
SRC_URI = http://cairographics.org/releases/cairo-${PV}.tar.xz \
- file://png.patch
+ file://png.patch \
+ file://cairo-don-t-check-stderr-when-test-compiling-in-conf.patch
SRC_URI[md5sum] = 27b634113d0f52152d60ae8e2ec7daa7
SRC_URI[sha256sum] =
96d0d1e3f9b74d2ca3469ff187c5e5f25649b1ad35cf06f4f3a83847dff4ac13
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] base-files: create /usr/lib/locale dir
On 6/18/13 4:12 AM, Phil Blundell wrote:
On Tue, 2013-06-18 at 16:42 +0800, Rongqing Li wrote:
diff --git a/meta/recipes-core/base-files/base-files_3.0.14.bb
b/meta/recipes-core/base-files/base-files_3.0.14.bb
index fa1cc58..84663e3 100644
--- a/meta/recipes-core/base-files/base-files_3.0.14.bb
+++ b/meta/recipes-core/base-files/base-files_3.0.14.bb
@@ -139,6 +139,7 @@ do_install_append_linuxstdbase() {
for d in ${dirs4775}; do
install -m 2755 -d ${D}$d
done
+ install -m 755 -d ${D}/usr/lib/locale
Thanks, that looks better. Could you not just add it to ${dirs3755}
though? (Despite the confusing/misleading name, this variable appears
to be a list of LSB directories that should be created with mode 0755,
cf ${dirs4755} which is apparently directories to be created with mode
2755.)
In a stylistic sense it might be better to use ${prefix}/lib/locale (or
whatever eglibc uses), but in practice LSB requires ${prefix}==/usr,
and presumably lsbtest is looking for /usr/lib/locale specifically, so
I don't think it will actually make any functional difference in this
specific case.
FYI, I agree ${prefix}/lib/locale is likely the correct directory to reference.
It preserves the semantics of the OE way of declaring paths, supports the move
of prefix to somewhere else, and will still work in an LSB compliant configuration.
--Mark
p.
___
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: magic libtool .la removal
Hi, Looking at another recipe that deletes .la files reminded me that every six months or so I look at this and never actually get anything done. Let's try attempt three! My proposal is that we integrate .la-removal into a core class. autotools.bbclass should cover 99% of instances as libtool is normally used in conjunction with auto*. Have a variable, REMOVE_LIBTOOL_LA, which controls the behaviour post-install. none. For this recipe, don't remove any .la files. libdir. For this recipe, remove .la files in $base_libdir and $libdir non-recursively, keeping the .la files in any subdirectories. This is for packages that use libltdt to load modules, which I believe needs .la files to work. all. For this recipe, remove all .la files. I've not written any code yet, but it shouldn't be hard. Any thoughts? Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: magic libtool .la removal
On Tue, 2013-06-18 at 15:31 +0100, Burton, Ross wrote: My proposal is that we integrate .la-removal into a core class. autotools.bbclass should cover 99% of instances as libtool is normally used in conjunction with auto*. Have a variable, REMOVE_LIBTOOL_LA, which controls the behaviour post-install. FWIW, I still have the patch from: http://lists.openembedded.org/pipermail/openembedded-core/2012-October/069912.html in my local tree and it seems to be working fine (although I don't have any particular interest in libltdt so it's conceivable that this might be broken). Looking back at that old thread it seems that you asked me to split into two patches, I said ok, but apparently I never did anything further about it. It's possible I might have been put off by Paul not liking the name or something, I don't really recall. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/4] connman: use PACKAGECONFIG for WISPr support
On Monday 10 June 2013 18:06:19 Otavio Salvador wrote: This seems safe for backporting to 1.4.2 and would allow for more control on connman build; Paul? At the moment we don't seem to have the other PACKAGECONFIG options for connman in dylan so this patch doesn't apply cleanly. If people are especially keen to have them I can backport these options, but I'd rather not just take them on a whim as these are more of an optimisation than a bug fix. 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] RFC: magic libtool .la removal
On 18 June 2013 15:42, Phil Blundell p...@pbcl.net wrote: FWIW, I still have the patch from: http://lists.openembedded.org/pipermail/openembedded-core/2012-October/069912.html in my local tree and it seems to be working fine (although I don't have any particular interest in libltdt so it's conceivable that this might be broken). I also remember discussion with Colin Walters about ostree, which at one point only removed from $libdir itself (my libdir argument) but now removes all .la files. Colin, the commit that changed the la killing to recurse didn't have a rationale - can you clarify this? If ostree can get away with removing all, them maybe we don't need the libdir option at all. Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: magic libtool .la removal
On Tue, 2013-06-18 at 15:56 +0100, Burton, Ross wrote:
I also remember discussion with Colin Walters about ostree, which at
one point only removed from $libdir itself (my libdir argument) but
now removes all .la files. Colin, the commit that changed the la
killing to recurse didn't have a rationale - can you clarify this? If
ostree can get away with removing all, them maybe we don't need the
libdir option at all.
The relevant data I have on hand are:
https://bugzilla.gnome.org/show_bug.cgi?id=654013
https://git.gnome.org/browse/jhbuild/commit/?id=965c8d5ceda9d1c5d6021ef2c534e0a7f68ca976
I think the executive summary is that libltdl knows how to load .so
files directly (at least currently), so there's no reason to have even
${libdir}/modulename/plugins/foo.la.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: magic libtool .la removal
On 18 June 2013 16:00, Colin Walters walt...@verbum.org wrote:
The relevant data I have on hand are:
https://bugzilla.gnome.org/show_bug.cgi?id=654013
https://git.gnome.org/browse/jhbuild/commit/?id=965c8d5ceda9d1c5d6021ef2c534e0a7f68ca976
I think the executive summary is that libltdl knows how to load .so
files directly (at least currently), so there's no reason to have even
${libdir}/modulename/plugins/foo.la.
Thanks Colin. Let's ignore the libdir option so this is a
per-package keep-or-wipe option. I'd like to default it to removing
all by default after a verification that the build results are
identical.
Ross
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] linux-yocto/3.8: fix gcc 4.8 ARM boot issues
Updating the linux-yocto-3.8 SRCREVs to fix a boot issue with ARM boards
when gcc 4.8 is used.
Without the following mainline backports:
f200475 ARM: 7670/1: fix the memset fix
8215b0e ARM: 7668/1: fix memset-related crashes caused by recent GCC (4.7.2)
optimizations
The following trap will be seen on boot:
[c00fc3b8] (kmem_cache_alloc_trace+0x54/0x210) from [c039f074]
(con_insert_unipair+0xcc/0x11c)
[c039f074] (con_insert_unipair+0xcc/0x11c) from [c039fec8]
(con_set_default_unimap+0xfc/0x198)
[c039fec8] (con_set_default_unimap+0xfc/0x198) from [c07ee258]
(console_map_init+0x44/0x58)
[c07ee258] (console_map_init+0x44/0x58) from [c07ee738]
(vty_init+0x16c/0x1b0)
[c07ee738] (vty_init+0x16c/0x1b0) from [c07edb68] (tty_init+0x108/0x148)
[c07edb68] (tty_init+0x108/0x148) from [c07eead0]
(chr_dev_init+0xb4/0xd8)
[c07eead0] (chr_dev_init+0xb4/0xd8) from [c0008a18]
(do_one_initcall+0x11c/0x18c)
[c0008a18] (do_one_initcall+0x11c/0x18c) from [c07d89d0]
(kernel_init_freeable+0x16c/0x254)
[c07d89d0] (kernel_init_freeable+0x16c/0x254) from [c05a3810]
(kernel_init+0x18/0x160)
[c05a3810] (kernel_init+0x18/0x160) from [c000e530]
(ret_from_fork+0x14/0x20)
Code: e593a000 e35a 0a20 e5943014 (e79a1003)
---[ end trace e6c62de166779f86 ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b
Moderate stress and board testing shows the fix to hold, and it is good for
broader testing.
[YOCTO #4549]
Signed-off-by: Khem Raj raj.k...@gmail.com
Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/recipes-kernel/linux/linux-yocto-rt_3.8.bb |6 +++---
meta/recipes-kernel/linux/linux-yocto-tiny_3.8.bb |4 ++--
meta/recipes-kernel/linux/linux-yocto_3.8.bb | 14 +++---
3 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.8.bb
b/meta/recipes-kernel/linux/linux-yocto-rt_3.8.bb
index c156be7..a3001ac 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_3.8.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.8.bb
@@ -8,9 +8,9 @@ LINUX_KERNEL_TYPE = preempt-rt
KMETA = meta
-SRCREV_machine ?= e0ac9992f1bf4830de49df884a3d2f273d02637b
-SRCREV_machine_qemuppc ?= ea4de76a916dd3620e74e565ff42fafb5bb40843
-SRCREV_meta ?= edd6461602f6c2fc27bc72997e4437f422a9dccd
+SRCREV_machine ?= 4fb187301ca153d496b2a96293dffde34d3b1a56
+SRCREV_machine_qemuppc ?= 547c4ea570933ab7ece9f10d2c46875b460cd337
+SRCREV_meta ?= c0851dfb8535635e1e31d4a5146d3f021e30506c
PR = ${INC_PR}.1
PV = ${LINUX_VERSION}+git${SRCPV}
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_3.8.bb
b/meta/recipes-kernel/linux/linux-yocto-tiny_3.8.bb
index 2073ee3..d9cc82a 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_3.8.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_3.8.bb
@@ -12,8 +12,8 @@ LINUX_VERSION ?= 3.8.13
KMETA = meta
-SRCREV_machine ?= 1f973c0fc8eea9a8f9758f47cf689ba89dbe9a25
-SRCREV_meta ?= edd6461602f6c2fc27bc72997e4437f422a9dccd
+SRCREV_machine ?= f20047520a57322f05d95a18a5fbd082fb15cb87
+SRCREV_meta ?= c0851dfb8535635e1e31d4a5146d3f021e30506c
PR = ${INC_PR}.1
PV = ${LINUX_VERSION}+git${SRCPV}
diff --git a/meta/recipes-kernel/linux/linux-yocto_3.8.bb
b/meta/recipes-kernel/linux/linux-yocto_3.8.bb
index 1517f40..0c21f7b 100644
--- a/meta/recipes-kernel/linux/linux-yocto_3.8.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_3.8.bb
@@ -3,13 +3,13 @@ require recipes-kernel/linux/linux-yocto.inc
KBRANCH_DEFAULT = standard/base
KBRANCH = ${KBRANCH_DEFAULT}
-SRCREV_machine_qemuarm ?= e267fe88798892416828d89bde7f778380b87a90
-SRCREV_machine_qemumips ?= 813bae2e17db9310f220935e87d168c8e52fafaf
-SRCREV_machine_qemuppc ?= f90923775f9bcec3ce23246e8fb59d8f9551e566
-SRCREV_machine_qemux86 ?= 1f973c0fc8eea9a8f9758f47cf689ba89dbe9a25
-SRCREV_machine_qemux86-64 ?= 1f973c0fc8eea9a8f9758f47cf689ba89dbe9a25
-SRCREV_machine ?= 1f973c0fc8eea9a8f9758f47cf689ba89dbe9a25
-SRCREV_meta ?= edd6461602f6c2fc27bc72997e4437f422a9dccd
+SRCREV_machine_qemuarm ?= aa76cc28408376814752bd36fb0dcf0e25aa5ba3
+SRCREV_machine_qemumips ?= aa0affda03c955678b26b2fb586f1d9505127871
+SRCREV_machine_qemuppc ?= 698eada61d9385b42dd117858b943655b565084b
+SRCREV_machine_qemux86 ?= f20047520a57322f05d95a18a5fbd082fb15cb87
+SRCREV_machine_qemux86-64 ?= f20047520a57322f05d95a18a5fbd082fb15cb87
+SRCREV_machine ?= f20047520a57322f05d95a18a5fbd082fb15cb87
+SRCREV_meta ?= c0851dfb8535635e1e31d4a5146d3f021e30506c
SRC_URI =
git://git.yoctoproject.org/linux-yocto-3.8.git;protocol=git;bareclone=1;branch=${KBRANCH},${KMETA};name=machine,meta
--
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 0/1]
Apologies for the no subject email. The rest is fine, just the guy typing it up had an itchy trigger finger! Cheers, Bruce On Tue, Jun 18, 2013 at 11:20 AM, Bruce Ashfield bruce.ashfi...@windriver.com wrote: Richard/Saul, Here's the integration of a change from Khem to fix the gcc 4.8 ARM boot issues. I'm still seeing some quasi random issues, but this definitely fixes the issue at hand, gets us up and running and is much better than what we had before. The patch pretty much says everything else: linux-yocto/3.8: fix gcc 4.8 ARM boot issues Updating the linux-yocto-3.8 SRCREVs to fix a boot issue with ARM boards when gcc 4.8 is used. Without the following mainline backports: f200475 ARM: 7670/1: fix the memset fix 8215b0e ARM: 7668/1: fix memset-related crashes caused by recent GCC (4.7.2) optimizations The following trap will be seen on boot: [c00fc3b8] (kmem_cache_alloc_trace+0x54/0x210) from [c039f074] (con_insert_unipair+0xcc/0x11c) [c039f074] (con_insert_unipair+0xcc/0x11c) from [c039fec8] (con_set_default_unimap+0xfc/0x198) [c039fec8] (con_set_default_unimap+0xfc/0x198) from [c07ee258] (console_map_init+0x44/0x58) [c07ee258] (console_map_init+0x44/0x58) from [c07ee738] (vty_init+0x16c/0x1b0) [c07ee738] (vty_init+0x16c/0x1b0) from [c07edb68] (tty_init+0x108/0x148) [c07edb68] (tty_init+0x108/0x148) from [c07eead0] (chr_dev_init+0xb4/0xd8) [c07eead0] (chr_dev_init+0xb4/0xd8) from [c0008a18] (do_one_initcall+0x11c/0x18c) [c0008a18] (do_one_initcall+0x11c/0x18c) from [c07d89d0] (kernel_init_freeable+0x16c/0x254) [c07d89d0] (kernel_init_freeable+0x16c/0x254) from [c05a3810] (kernel_init+0x18/0x160) [c05a3810] (kernel_init+0x18/0x160) from [c000e530] (ret_from_fork+0x14/0x20) Code: e593a000 e35a 0a20 e5943014 (e79a1003) ---[ end trace e6c62de166779f86 ]--- Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b Moderate stress and board testing shows the fix to hold, and it is good for broader testing. [YOCTO #4549] Signed-off-by: Khem Raj raj.k...@gmail.com Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com Cheers, Bruce The following changes since commit 1dd643b142c69ac9035e29bff11d02201638dc65: licences: Add SGI license (2013-06-17 16:45:37 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib zedd/kernel http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel Bruce Ashfield (1): linux-yocto/3.8: fix gcc 4.8 ARM boot issues meta/recipes-kernel/linux/linux-yocto-rt_3.8.bb |6 +++--- meta/recipes-kernel/linux/linux-yocto-tiny_3.8.bb |4 ++-- meta/recipes-kernel/linux/linux-yocto_3.8.bb | 14 +++--- 3 files changed, 12 insertions(+), 12 deletions(-) -- 1.7.10.4 ___ 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
[OE-core] [PATCH 0/1]
Richard/Saul, Here's the integration of a change from Khem to fix the gcc 4.8 ARM boot issues. I'm still seeing some quasi random issues, but this definitely fixes the issue at hand, gets us up and running and is much better than what we had before. The patch pretty much says everything else: linux-yocto/3.8: fix gcc 4.8 ARM boot issues Updating the linux-yocto-3.8 SRCREVs to fix a boot issue with ARM boards when gcc 4.8 is used. Without the following mainline backports: f200475 ARM: 7670/1: fix the memset fix 8215b0e ARM: 7668/1: fix memset-related crashes caused by recent GCC (4.7.2) optimizations The following trap will be seen on boot: [c00fc3b8] (kmem_cache_alloc_trace+0x54/0x210) from [c039f074] (con_insert_unipair+0xcc/0x11c) [c039f074] (con_insert_unipair+0xcc/0x11c) from [c039fec8] (con_set_default_unimap+0xfc/0x198) [c039fec8] (con_set_default_unimap+0xfc/0x198) from [c07ee258] (console_map_init+0x44/0x58) [c07ee258] (console_map_init+0x44/0x58) from [c07ee738] (vty_init+0x16c/0x1b0) [c07ee738] (vty_init+0x16c/0x1b0) from [c07edb68] (tty_init+0x108/0x148) [c07edb68] (tty_init+0x108/0x148) from [c07eead0] (chr_dev_init+0xb4/0xd8) [c07eead0] (chr_dev_init+0xb4/0xd8) from [c0008a18] (do_one_initcall+0x11c/0x18c) [c0008a18] (do_one_initcall+0x11c/0x18c) from [c07d89d0] (kernel_init_freeable+0x16c/0x254) [c07d89d0] (kernel_init_freeable+0x16c/0x254) from [c05a3810] (kernel_init+0x18/0x160) [c05a3810] (kernel_init+0x18/0x160) from [c000e530] (ret_from_fork+0x14/0x20) Code: e593a000 e35a 0a20 e5943014 (e79a1003) ---[ end trace e6c62de166779f86 ]--- Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b Moderate stress and board testing shows the fix to hold, and it is good for broader testing. [YOCTO #4549] Signed-off-by: Khem Raj raj.k...@gmail.com Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com Cheers, Bruce The following changes since commit 1dd643b142c69ac9035e29bff11d02201638dc65: licences: Add SGI license (2013-06-17 16:45:37 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib zedd/kernel http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel Bruce Ashfield (1): linux-yocto/3.8: fix gcc 4.8 ARM boot issues meta/recipes-kernel/linux/linux-yocto-rt_3.8.bb |6 +++--- meta/recipes-kernel/linux/linux-yocto-tiny_3.8.bb |4 ++-- meta/recipes-kernel/linux/linux-yocto_3.8.bb | 14 +++--- 3 files changed, 12 insertions(+), 12 deletions(-) -- 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 1/1] cairo: fix build error since toolchain has not get_feature command
On Jun 18, 2013, at 7:17 AM, Mark Hatle mark.ha...@windriver.com wrote:
On 6/18/13 1:02 AM, rongqing...@windriver.com wrote:
From: Roy.Li rongqing...@windriver.com
Signed-off-by: Roy.Li rongqing...@windriver.com
---
...-check-stderr-when-test-compiling-in-conf.patch | 39
meta/recipes-graphics/cairo/cairo_1.12.14.bb |3 +-
2 files changed, 41 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-graphics/cairo/cairo/cairo-don-t-check-stderr-when-test-compiling-in-conf.patch
diff --git
a/meta/recipes-graphics/cairo/cairo/cairo-don-t-check-stderr-when-test-compiling-in-conf.patch
b/meta/recipes-graphics/cairo/cairo/cairo-don-t-check-stderr-when-test-compiling-in-conf.patch
new file mode 100644
index 000..e04c3b2
--- /dev/null
+++
b/meta/recipes-graphics/cairo/cairo/cairo-don-t-check-stderr-when-test-compiling-in-conf.patch
@@ -0,0 +1,39 @@
+From 1581e5373c5917ed8ff6f7129c51160594c927d1 Mon Sep 17 00:00:00 2001
+From: Song.Li song...@windriver.com
+Date: Mon, 30 Jul 2012 16:38:02 +0800
+Subject: [PATCH] cairo:don't check stderr when test compiling in configure
+
+Upstream-Status: Pending
+
+cairo configure use a special macro to test compiling feature.
+It'll require no any warnings or errors in stderr.That is too strict.
+for example, when there is no get_feature in gcc,
+gcc will print no get_feature in stderr, but that is not a real error.
FYI -- 'get_feature' is something specific to Wind River. The patch is still
reasonable, but the commit description might need some cleanup for people not
familiar with some of our internal tools.
I am still confused what does it fix in existing build
I'd suggest just removing the example part.
--Mark
+so let cairo don't check stderr,just check the return value of compiling
+is enough.
+
+Signed-off-by: Song.Li song...@windriver.com
+---
+ build/aclocal.cairo.m4 |6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/build/aclocal.cairo.m4 b/build/aclocal.cairo.m4
+index 592e168..4de3b26 100644
+--- a/build/aclocal.cairo.m4
b/build/aclocal.cairo.m4
+@@ -106,9 +106,9 @@ AC_DEFUN([CAIRO_CC_TRY_LINK_WITH_ENV_SILENT],[dnl
+[cairo_cc_stderr=`test -f conftest.err cat conftest.err`
+ cairo_cc_flag=no])
+
+-if test x$cairo_cc_stderr != x; then
+-cairo_cc_flag=no
+-fi
++dnlif test x$cairo_cc_stderr != x; then
++dnlcairo_cc_flag=no
++dnlfi
+
+if test x$cairo_cc_flag = xyes; then
+ifelse([$3], , :, [$3])
+--
+1.7.9.5
+
diff --git a/meta/recipes-graphics/cairo/cairo_1.12.14.bb
b/meta/recipes-graphics/cairo/cairo_1.12.14.bb
index 40aa169..5c8c9cd 100644
--- a/meta/recipes-graphics/cairo/cairo_1.12.14.bb
+++ b/meta/recipes-graphics/cairo/cairo_1.12.14.bb
@@ -5,7 +5,8 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=e73e999e0c72b5ac9012424fa157ad77
PR = r0
SRC_URI = http://cairographics.org/releases/cairo-${PV}.tar.xz \
- file://png.patch
+ file://png.patch \
+
file://cairo-don-t-check-stderr-when-test-compiling-in-conf.patch
SRC_URI[md5sum] = 27b634113d0f52152d60ae8e2ec7daa7
SRC_URI[sha256sum] =
96d0d1e3f9b74d2ca3469ff187c5e5f25649b1ad35cf06f4f3a83847dff4ac13
___
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] RFC: magic libtool .la removal
On Tue, 2013-06-18 at 16:05 +0100, Burton, Ross wrote:
On 18 June 2013 16:00, Colin Walters walt...@verbum.org wrote:
The relevant data I have on hand are:
https://bugzilla.gnome.org/show_bug.cgi?id=654013
https://git.gnome.org/browse/jhbuild/commit/?id=965c8d5ceda9d1c5d6021ef2c534e0a7f68ca976
I think the executive summary is that libltdl knows how to load .so
files directly (at least currently), so there's no reason to have even
${libdir}/modulename/plugins/foo.la.
Thanks Colin. Let's ignore the libdir option so this is a
per-package keep-or-wipe option. I'd like to default it to removing
all by default after a verification that the build results are
identical.
The thing which really worries me about this is that we'll start to
deviate quite massively with how upstream expect us to use autotools.
As things stand, we have a number of sysroot fixes for the sysroot
support in libtool which is basically broken out the box. I have tried
discussing them with upstream and was ignored, mainly as we patch
libtool and we're supposed to use it unpatched.
I worry that if we go this route, the builds will stop working without
the .la file removal and that we'll lose any chance of being able to
resolve our patchset with libtool upstream. We might as well throw away
libtool at that point and save the overhead. It also means we will have
bigger problems working on something like darwin (which I've had work in
the past).
So I don't see the pressing need to set us off down a path on our own.
Yes the .la files are annoying but they're not that much of a problem,
are they?
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: magic libtool .la removal
On 18 June 2013 16:47, Richard Purdie richard.pur...@linuxfoundation.org wrote: So I don't see the pressing need to set us off down a path on our own. Yes the .la files are annoying but they're not that much of a problem, are they? Whilst the separate build directory work is a massive improvement, there's plenty of packages that don't do B!=S and use libtool. We're not alone, at least Fedora and OSTree both wipe out all .la files. As B!=S should solve this problem and others I can see the argument for spending time making that work more comprehensively though. Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: magic libtool .la removal
On Tue, 2013-06-18 at 16:47 +0100, Richard Purdie wrote: We might as well throw away libtool That sounds like an excellent plan to me. I wonder how hard it would be to invent a libtool-dummy script which took the same arguments but basically just invoked the compiler and linker without any of the extra craziness. Yes the .la files are annoying but they're not that much of a problem, are they? I do recall that I was moved to write my original patch because the .la files were causing me an actual problem rather than just being a nuisance. I can't remember the details offhand unfortunately, though I guess I could try re-enabling them again locally and see what breaks. Also, the patch that I posted in the first place did use a DISTRO_FEATURE to control whether you get .la files or not (and the default was still to have them) so you would be welcome to keep them on for poky if you wanted. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: magic libtool .la removal
On 18 June 2013 16:54, Phil Blundell p...@pbcl.net wrote: On Tue, 2013-06-18 at 16:47 +0100, Richard Purdie wrote: We might as well throw away libtool That sounds like an excellent plan to me. I wonder how hard it would be to invent a libtool-dummy script which took the same arguments but basically just invoked the compiler and linker without any of the extra craziness. That would be DOLT. Yes the .la files are annoying but they're not that much of a problem, are they? I do recall that I was moved to write my original patch because the .la files were causing me an actual problem rather than just being a nuisance. I can't remember the details offhand unfortunately, though I guess I could try re-enabling them again locally and see what breaks. FWIW, I've never seen a .la break anything where a clean doesn't solve it, the problems are always due to rebuilds. Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: magic libtool .la removal
On Tue, 2013-06-18 at 16:47 +0100, Richard Purdie wrote: The thing which really worries me about this is that we'll start to deviate quite massively with how upstream expect us to use autotools. I just consider upstream wrong, and so do others: http://wiki.debian.org/ReleaseGoals/LAFileRemoval http://fedoraproject.org/wiki/Packaging:Guidelines (search for .la) http://blog.flameeyes.eu/2008/04/what-about-those-la-files (the one mostly sane Gentoo guy) As things stand, we have a number of sysroot fixes for the sysroot support in libtool which is basically broken out the box. I have tried discussing them with upstream and was ignored, mainly as we patch libtool and we're supposed to use it unpatched. Yeah, I dunno...maybe someone needs to fork libtool. I worry that if we go this route, the builds will stop working without the .la file removal and that we'll lose any chance of being able to resolve our patchset with libtool upstream. We might as well throw away libtool at that point Or that... and save the overhead. It also means we will have bigger problems working on something like darwin (which I've had work in the past). I don't have any experience with Darwin myself. So I don't see the pressing need to set us off down a path on our own. Yes the .la files are annoying but they're not that much of a problem, are they? Depends; I don't have a lot of first-hand experience with problems they cause in the OE context. But .la files completely break jhbuild. Certainly, one could call jhbuild a hack, and it is. But it's a tool with absolutely essential properties for people contributing to GNOME. Basically jhbuild allows one to e.g.: $ jhbuild buildone gtk+ $ jhbuild run gedit Now you have your system version of /usr/bin/gedit linked against the latest gtk+ from git in /opt/gnome/lib/libgtk.so. This two layer model is essential for allowing developers to test new code without risking their /. The root feature of .la files where it can say if you link against me, also link against these other libraries that causes this is much better implemented by pkg-config. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] OE, the TSC and the future
I think its fair to say that OpenEmbedded has changed quite a bit over the last few years. Prior to the Yocto Project, OE struggled to figure out how to engage with the commercial side of the ecosystem and how to scale and I think there have been many positive changes in the way everything works, not least with the layers approach and the pull model for changes. Whilst the ecosystem has changed, the structures that make up OE such as the TSC have not changed that much. They were setup to address problems which in some cases no longer exist for example. We're coming up to the next round of TSC elections, the board is aware of this but have asked that we figure out the TSC's role going forward before those elections. There has been limited discussion about this on the members list previously, it was met with a lot of silence but I do think the time is right to think about things a bit. I should note that whilst I did take an action from the TSC to start a discussion and that the TSC does have some ideas in mind, I'm primarily expressing personal views here, not those of the TSC. Other TSC members are more than capable of expressing their own views! In brief summary the TSC has been doing two main things, acting as a task force and also being able to make a decision when needed. The latter has not happened much at all, the main work was as a task force on various issues, firstly engaging with the Yocto Project and figuring that out, more recently dealing with infrastructure issues and generally ensuring the health of OE. I don't think the task force should be limited to the TSC members although it can be lead by them (or delegated). As such I think the TSC would like to see that element get opened up to a public IRC meeting, maybe monthly at a set time when people get together and discuss those topics. The TSC members could be responsible for giving that process and meeting some kind of structure but it would be open to all. The decision making element of the TSC would remain with them, likely done by calling a special meeting as needed (we haven't needed many official decisions). At this point I'll open that to discussion. Any objections or other proposals? Speaking of TSC elections, I know I'm due for re-election first. I'm also due to be away for a few weeks shortly so I'd like to make it known that I would like to stand for re-election. I've hopefully done some good for OE over what amounts to nearly a decade (scary when put like that!) and I'm not quite done yet! :) Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: magic libtool .la removal
On Tue, 2013-06-18 at 12:05 -0400, Colin Walters wrote: Yeah, I dunno...maybe someone needs to fork libtool. I should follow up to this; the thing is, libtool is at the intersection of so many cross-cutting issues: * RPM-style multilib vs Debian-style multiarch * Supporting libraries that use pkg-config vs those that still sadly don't * Windows vs Darwin vs GNU/Linux (in all its variations) * Cross vs native builds * sysroot support * Plugins: libltdl (and how that interacts with other cross-platform module loaders like e.g. GModule) * Component-internal build system vs external interaction; specifically libtool makes it easy to run *uninstalled* binaries, which is quite useful, and to do that inside the tree does require extra metadata in .la files So when I say .la files are worthless and broken, I really mean just for GNU/Linux systems (generally native builds, but likely also cross), and where things I care about know how to find .so files instead of .la, and only for *external* build system interaction; having .la files *inside* the build tree for a single component is fine, etc. I can't say for sure myself that having libtool unilaterally stop installing .la files wouldn't break anything; maybe there's some library out there that doesn't use pkg-config and relies on consumers using dependency_libs. But I do think it's at best unnecessary for the use case above; so maybe it should come down to an option, or something. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] sanity.bbclass: Check for the known broken version of make
See GNU Savannah bug 30612 -- make 3.82 is known to be broken. A number of vendors are providing a modified version, so checking for just the version string is not enough. We also need to check if the patch for the issue has been applied. We use a modified version of the reproduced to check for the issue. Signed-off-by: Mark Hatle mark.ha...@windriver.com --- meta/classes/sanity.bbclass | 39 +++ 1 file changed, 39 insertions(+) diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass index 3b9934b..b7f3673 100644 --- a/meta/classes/sanity.bbclass +++ b/meta/classes/sanity.bbclass @@ -336,6 +336,41 @@ def check_gcc_march(sanity_data): return result +# Unpatched version of make 3.82 are known to be broken. See GNU Savannah Bug 30612. +# Use the reproducer from http://savannah.gnu.org/bugs/?30612 +def check_make_version(sanity_data, loosever): +status, result = oe.utils.getstatusoutput(make --version) +if status != 0: +return Unable to execute make --version, exit code %s\n % status +version = result.split()[3] +if not (loosever(version) loosever(3.82) and loosever(version) loosever(3.82)): +# Construct a test file +f = open(makefile_test, w) +f.write(makefile_test.a: makefile_test_a.c makefile_test_b.c makefile_test.a( makefile_test_a.c makefile_test_b.c)\n) +f.write(\n) +f.write(makefile_test_a.c:\n) +f.write( touch $@\n) +f.write(\n) +f.write(makefile_test_b.c:\n) +f.write( touch $@\n) +f.close() + +# Check if make 3.82 has been patched +status,result = oe.utils.getstatusoutput(make -f makefile_test) + +os.remove(makefile_test) +if os.path.exists(makefile_test_a.c): +os.remove(makefile_test_a.c) +if os.path.exists(makefile_test_b.c): +os.remove(makefile_test_b.c) +if os.path.exists(makefile_test_a): +os.remove(makefile_test.a) + +if status != 0: +return Your version of make 3.82 is broken. Please revert to 3.81 or install a patched version.\n +return None + + # Tar version 1.24 and onwards handle overwriting symlinks correctly # but earlier versions do not; this needs to work properly for sstate def check_tar_version(sanity_data, loosever): @@ -407,6 +442,10 @@ def check_sanity(sanity_data): messages = messages + 'Please set a MACHINE in your local.conf or environment\n' machinevalid = False +makemsg = check_make_version(sanity_data, LooseVersion) +if makemsg: +messages = messages + makemsg + tarmsg = check_tar_version(sanity_data, LooseVersion) if tarmsg: messages = messages + tarmsg -- 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] sanity.bbclass: Check for the known broken version of make
On 6/18/13 2:11 PM, Mark Hatle wrote: See GNU Savannah bug 30612 -- make 3.82 is known to be broken. A number of vendors are providing a modified version, so checking for just the version string is not enough. We also need to check if the patch for the issue has been applied. We use a modified version of the reproduced to check for the issue. This was meant to go out as an RFC. The patch still hasn't been fully verified. Please don't merge it, but feedback would be appreciated! --Mark Signed-off-by: Mark Hatle mark.ha...@windriver.com --- meta/classes/sanity.bbclass | 39 +++ 1 file changed, 39 insertions(+) diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass index 3b9934b..b7f3673 100644 --- a/meta/classes/sanity.bbclass +++ b/meta/classes/sanity.bbclass @@ -336,6 +336,41 @@ def check_gcc_march(sanity_data): return result +# Unpatched version of make 3.82 are known to be broken. See GNU Savannah Bug 30612. +# Use the reproducer from http://savannah.gnu.org/bugs/?30612 +def check_make_version(sanity_data, loosever): +status, result = oe.utils.getstatusoutput(make --version) +if status != 0: +return Unable to execute make --version, exit code %s\n % status +version = result.split()[3] +if not (loosever(version) loosever(3.82) and loosever(version) loosever(3.82)): +# Construct a test file +f = open(makefile_test, w) +f.write(makefile_test.a: makefile_test_a.c makefile_test_b.c makefile_test.a( makefile_test_a.c makefile_test_b.c)\n) +f.write(\n) +f.write(makefile_test_a.c:\n) +f.write( touch $@\n) +f.write(\n) +f.write(makefile_test_b.c:\n) +f.write( touch $@\n) +f.close() + +# Check if make 3.82 has been patched +status,result = oe.utils.getstatusoutput(make -f makefile_test) + +os.remove(makefile_test) +if os.path.exists(makefile_test_a.c): +os.remove(makefile_test_a.c) +if os.path.exists(makefile_test_b.c): +os.remove(makefile_test_b.c) +if os.path.exists(makefile_test_a): +os.remove(makefile_test.a) + +if status != 0: +return Your version of make 3.82 is broken. Please revert to 3.81 or install a patched version.\n +return None + + # Tar version 1.24 and onwards handle overwriting symlinks correctly # but earlier versions do not; this needs to work properly for sstate def check_tar_version(sanity_data, loosever): @@ -407,6 +442,10 @@ def check_sanity(sanity_data): messages = messages + 'Please set a MACHINE in your local.conf or environment\n' machinevalid = False +makemsg = check_make_version(sanity_data, LooseVersion) +if makemsg: +messages = messages + makemsg + tarmsg = check_tar_version(sanity_data, LooseVersion) if tarmsg: messages = messages + tarmsg ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] nostromo: make SRC_URI work for multilib builds.
Signed-off-by: Randy MacLeod randy.macl...@windriver.com
---
meta-webserver/recipes-httpd/nostromo/nostromo_1.9.5.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-webserver/recipes-httpd/nostromo/nostromo_1.9.5.bb
b/meta-webserver/recipes-httpd/nostromo/nostromo_1.9.5.bb
index e66676e..f729e6a 100644
--- a/meta-webserver/recipes-httpd/nostromo/nostromo_1.9.5.bb
+++ b/meta-webserver/recipes-httpd/nostromo/nostromo_1.9.5.bb
@@ -3,7 +3,7 @@ HOMEPAGE = http://www.nazgul.ch/dev_nostromo.html;
LICENSE = MIT
LIC_FILES_CHKSUM =
file://src/nhttpd/main.c;beginline=2;endline=14;md5=e5ec3fa723b29b7d59d205afd8d36938
-SRC_URI = http://www.nazgul.ch/dev/${PN}-${PV}.tar.gz \
+SRC_URI = http://www.nazgul.ch/dev/nostromo-${PV}.tar.gz \
file://0001-GNUmakefile-add-possibility-to-override-variables.patch
\
file://nhttpd.conf \
file://volatiles \
--
1.8.2.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1 v2] sanity.bbclass: Check for the known broken version of make
See GNU Savannah bug 30612 -- make 3.82 is known to be broken. A number of vendors are providing a modified version, so checking for just the version string is not enough. We also need to check if the patch for the issue has been applied. We use a modified version of the reproduced to check for the issue. Signed-off-by: Mark Hatle mark.ha...@windriver.com --- meta/classes/sanity.bbclass | 39 +++ 1 file changed, 39 insertions(+) diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass index 3b9934b..012c40d 100644 --- a/meta/classes/sanity.bbclass +++ b/meta/classes/sanity.bbclass @@ -336,6 +336,41 @@ def check_gcc_march(sanity_data): return result +# Unpatched versions of make 3.82 are known to be broken. See GNU Savannah Bug 30612. +# Use a modified reproducer from http://savannah.gnu.org/bugs/?30612 to validate. +def check_make_version(sanity_data, loosever): +status, result = oe.utils.getstatusoutput(make --version) +if status != 0: +return Unable to execute make --version, exit code %s\n % status +version = result.split()[2] +if loosever(version) == loosever(3.82): +# Construct a test file +f = open(makefile_test, w) +f.write(makefile_test.a: makefile_test_a.c makefile_test_b.c makefile_test.a( makefile_test_a.c makefile_test_b.c)\n) +f.write(\n) +f.write(makefile_test_a.c:\n) +f.write( touch $@\n) +f.write(\n) +f.write(makefile_test_b.c:\n) +f.write( touch $@\n) +f.close() + +# Check if make 3.82 has been patched +status,result = oe.utils.getstatusoutput(make -f makefile_test) + +os.remove(makefile_test) +if os.path.exists(makefile_test_a.c): +os.remove(makefile_test_a.c) +if os.path.exists(makefile_test_b.c): +os.remove(makefile_test_b.c) +if os.path.exists(makefile_test.a): +os.remove(makefile_test.a) + +if status != 0: +return Your version of make 3.82 is broken. Please revert to 3.81 or install a patched version.\n +return None + + # Tar version 1.24 and onwards handle overwriting symlinks correctly # but earlier versions do not; this needs to work properly for sstate def check_tar_version(sanity_data, loosever): @@ -407,6 +442,10 @@ def check_sanity(sanity_data): messages = messages + 'Please set a MACHINE in your local.conf or environment\n' machinevalid = False +makemsg = check_make_version(sanity_data, LooseVersion) +if makemsg: +messages = messages + makemsg + tarmsg = check_tar_version(sanity_data, LooseVersion) if tarmsg: messages = messages + tarmsg -- 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] nostromo: make SRC_URI work for multilib builds.
On 6/18/13 2:21 PM, Randy MacLeod wrote:
Wrong list. This should have gone to the oe-devel list, and been tagged with
[networking] in the subject.
Also one thing below:
Signed-off-by: Randy MacLeod randy.macl...@windriver.com
---
meta-webserver/recipes-httpd/nostromo/nostromo_1.9.5.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-webserver/recipes-httpd/nostromo/nostromo_1.9.5.bb
b/meta-webserver/recipes-httpd/nostromo/nostromo_1.9.5.bb
index e66676e..f729e6a 100644
--- a/meta-webserver/recipes-httpd/nostromo/nostromo_1.9.5.bb
+++ b/meta-webserver/recipes-httpd/nostromo/nostromo_1.9.5.bb
@@ -3,7 +3,7 @@ HOMEPAGE = http://www.nazgul.ch/dev_nostromo.html;
LICENSE = MIT
LIC_FILES_CHKSUM =
file://src/nhttpd/main.c;beginline=2;endline=14;md5=e5ec3fa723b29b7d59d205afd8d36938
-SRC_URI = http://www.nazgul.ch/dev/${PN}-${PV}.tar.gz \
+SRC_URI = http://www.nazgul.ch/dev/nostromo-${PV}.tar.gz \
You can also use '${BPN}' to refer to the original recipe name, not the multilib
name.
--Mark
file://0001-GNUmakefile-add-possibility-to-override-variables.patch \
file://nhttpd.conf \
file://volatiles \
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [RFC] eglibc / glibc and option-groups being deprecated?
Recently on the eglibc mailing list there has been a discussion about removing the option groups. See: http://www.eglibc.org/archives/patches/msg01268.html For folks who don't know what option-groups are, it's a patch that went into eglibc a number of years ago that allows you to disable various components (effectively altering the API) in order to shrink the size of glibc. It was created as an attempt to get into glibc the same type of configuration ability that uclibc has. In OpenEmbedded Core, it is currently being used to enable the ability to shrink the LibC footprint to a smaller size. The Yocto Project's Poky-tiny distribution uses it as part of the mechanism to create a smaller filesystem. I encourage you to read the original thread, and if it affects you, please speak up. The following is my attempt at summarizing the thread. Currently the maintainer(s) of eglibc are working on syncing up glibc and eglibc to the point that there will no longer be a need for eglibc. (See http://www.eglibc.org/archives/patches/msg01261.html) EGlibc was originally developed to house various architecture ports and other embedded friendly features were not allowed into glibc. The majority of the differences between eglibc and glibc have disappeared, with only a few major exceptions. One of which is the option-groups support. This item is taking a significant amount of resources to keep up to date, and it's unclear as to the number of users for this functionality. The belief of the maintainers is that the days of truly small footprint systems, where even 1 MB of storage was a large number are coming to an end. As such, the time and effort to maintain the option groups is likely not worth the effort. I expect that between OpenEmbedded and the Yocto Project, a large percentage of the users would be represented in some way. But beyond that, I don't have any idea as to how many people actually benefit from this technology. During the discussion the results were that either assistance with maintaining the option-groups is needed, or the feature will be deprecated and eventually removed. The last part of the thread it was suggested that in eglibc 2.19 it would be deprecated, and then removed in 2.20. --Mark ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1 v2] sanity.bbclass: Check for the known broken version of make
Just an FYI -- this fails (correctly I might add) on many Fedora systems. It turns out that their version of make 3.82 is only partially patched. The specific check we look for looks for two different problems. The first is a target that includes target(dep1 dep2 dep3). The second is a target that starts with leading spaces. From what I can tell, most Fedora 3.82 versions are patched for the first problem, but not the second. There are other problems with 3.82, but this patch appears to detect the most broken of 3.82 versions in common use. (And no, this is no longer an RFC. I think this is the correct patch!) --Mark On 6/18/13 3:17 PM, Mark Hatle wrote: See GNU Savannah bug 30612 -- make 3.82 is known to be broken. A number of vendors are providing a modified version, so checking for just the version string is not enough. We also need to check if the patch for the issue has been applied. We use a modified version of the reproduced to check for the issue. Signed-off-by: Mark Hatle mark.ha...@windriver.com --- meta/classes/sanity.bbclass | 39 +++ 1 file changed, 39 insertions(+) diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass index 3b9934b..012c40d 100644 --- a/meta/classes/sanity.bbclass +++ b/meta/classes/sanity.bbclass @@ -336,6 +336,41 @@ def check_gcc_march(sanity_data): return result +# Unpatched versions of make 3.82 are known to be broken. See GNU Savannah Bug 30612. +# Use a modified reproducer from http://savannah.gnu.org/bugs/?30612 to validate. +def check_make_version(sanity_data, loosever): +status, result = oe.utils.getstatusoutput(make --version) +if status != 0: +return Unable to execute make --version, exit code %s\n % status +version = result.split()[2] +if loosever(version) == loosever(3.82): +# Construct a test file +f = open(makefile_test, w) +f.write(makefile_test.a: makefile_test_a.c makefile_test_b.c makefile_test.a( makefile_test_a.c makefile_test_b.c)\n) +f.write(\n) +f.write(makefile_test_a.c:\n) +f.write( touch $@\n) +f.write(\n) +f.write(makefile_test_b.c:\n) +f.write( touch $@\n) +f.close() + +# Check if make 3.82 has been patched +status,result = oe.utils.getstatusoutput(make -f makefile_test) + +os.remove(makefile_test) +if os.path.exists(makefile_test_a.c): +os.remove(makefile_test_a.c) +if os.path.exists(makefile_test_b.c): +os.remove(makefile_test_b.c) +if os.path.exists(makefile_test.a): +os.remove(makefile_test.a) + +if status != 0: +return Your version of make 3.82 is broken. Please revert to 3.81 or install a patched version.\n +return None + + # Tar version 1.24 and onwards handle overwriting symlinks correctly # but earlier versions do not; this needs to work properly for sstate def check_tar_version(sanity_data, loosever): @@ -407,6 +442,10 @@ def check_sanity(sanity_data): messages = messages + 'Please set a MACHINE in your local.conf or environment\n' machinevalid = False +makemsg = check_make_version(sanity_data, LooseVersion) +if makemsg: +messages = messages + makemsg + tarmsg = check_tar_version(sanity_data, LooseVersion) if tarmsg: messages = messages + tarmsg ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1 v2] sanity.bbclass: Check for the known broken version of make
On 6/18/13 4:09 PM, Mark Hatle wrote: Just an FYI -- this fails (correctly I might add) on many Fedora systems. It turns out that their version of make 3.82 is only partially patched. From the best that I can tell, Fedora 16 and newer are all broken. (And I checked OE-Core, and it's also missing the second part of the fix. I should be sending a patch for that soon.) Fedora Bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=975597 If necessary we can relax the check I added by removing the 'space' on the makefile_test.a: ... line. Obviously it hasn't been failing for the oe-core (and likely meta-oe) builds. But it is still broken. --Mark The specific check we look for looks for two different problems. The first is a target that includes target(dep1 dep2 dep3). The second is a target that starts with leading spaces. From what I can tell, most Fedora 3.82 versions are patched for the first problem, but not the second. There are other problems with 3.82, but this patch appears to detect the most broken of 3.82 versions in common use. (And no, this is no longer an RFC. I think this is the correct patch!) --Mark On 6/18/13 3:17 PM, Mark Hatle wrote: See GNU Savannah bug 30612 -- make 3.82 is known to be broken. A number of vendors are providing a modified version, so checking for just the version string is not enough. We also need to check if the patch for the issue has been applied. We use a modified version of the reproduced to check for the issue. Signed-off-by: Mark Hatle mark.ha...@windriver.com --- meta/classes/sanity.bbclass | 39 +++ 1 file changed, 39 insertions(+) diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass index 3b9934b..012c40d 100644 --- a/meta/classes/sanity.bbclass +++ b/meta/classes/sanity.bbclass @@ -336,6 +336,41 @@ def check_gcc_march(sanity_data): return result +# Unpatched versions of make 3.82 are known to be broken. See GNU Savannah Bug 30612. +# Use a modified reproducer from http://savannah.gnu.org/bugs/?30612 to validate. +def check_make_version(sanity_data, loosever): +status, result = oe.utils.getstatusoutput(make --version) +if status != 0: +return Unable to execute make --version, exit code %s\n % status +version = result.split()[2] +if loosever(version) == loosever(3.82): +# Construct a test file +f = open(makefile_test, w) +f.write(makefile_test.a: makefile_test_a.c makefile_test_b.c makefile_test.a( makefile_test_a.c makefile_test_b.c)\n) +f.write(\n) +f.write(makefile_test_a.c:\n) +f.write( touch $@\n) +f.write(\n) +f.write(makefile_test_b.c:\n) +f.write( touch $@\n) +f.close() + +# Check if make 3.82 has been patched +status,result = oe.utils.getstatusoutput(make -f makefile_test) + +os.remove(makefile_test) +if os.path.exists(makefile_test_a.c): +os.remove(makefile_test_a.c) +if os.path.exists(makefile_test_b.c): +os.remove(makefile_test_b.c) +if os.path.exists(makefile_test.a): +os.remove(makefile_test.a) + +if status != 0: +return Your version of make 3.82 is broken. Please revert to 3.81 or install a patched version.\n +return None + + # Tar version 1.24 and onwards handle overwriting symlinks correctly # but earlier versions do not; this needs to work properly for sstate def check_tar_version(sanity_data, loosever): @@ -407,6 +442,10 @@ def check_sanity(sanity_data): messages = messages + 'Please set a MACHINE in your local.conf or environment\n' machinevalid = False +makemsg = check_make_version(sanity_data, LooseVersion) +if makemsg: +messages = messages + makemsg + tarmsg = check_tar_version(sanity_data, LooseVersion) if tarmsg: messages = messages + tarmsg ___ 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] OE TSC Minutes 18 June 2013
OpenEmbedded Technical Steering Committee 18 June 2013 Attendees: Koen (koen) Fray (fray) Paul (bluelightning) Khem (khem) Richard (RP) Apologies: Notes: Jefro Agenda at a glance: 1. pick a chair 2. new issues 3. lingering issues a. role of the TSC b. elections 4. projects in progress - status a. oe-core release b. meta-oe appends/overlayed recipes RFC c. python 3 d. release status notification 5. infrastructure a. oe.org flooded 6. projects deferred a. raise awareness of janitor list, QA bugs b. document whitespace changes to the shell c. raise ntp with the Yocto Project [RP] Agenda Results 1. pick a chair bluelightning ___ 2. new issues a. eglibc http://www.eglibc.org/archives/patches/msg01268.html maintainers (Mentor) removing differences btw eglibc, upstream glibc would like to deprecate remove option groups then unable to configure items out potentially ruining poky-tiny and others -poll users to see if actually being used alternatively, find someone willing to maintain khem proposes replacing option groups with pure kconfig =raise eglibc issues on mailing list (fray) =get kconfig stuff discussed and proposed to glibc (khem) ___ 3. lingering issues a. role of the TSC (http://lists.linuxtogo.org/pipermail/openembedded-core/2013-April/038756.html) proposal: monthly IRC meeting to replace one of the bi-weekly TSC meetings, open to all split the TSC role in two.. have a infrastructure, etc TSC similar to now.. as well as 'resolve technical conflicts' defer vote = post RFC on mailing list (RP) - drafted reviewed, sent to mailing lists b. elections =jefro to flag the board, recommend defer elections until after 3a (DONE) ___ 4. projects in progress - status a. oe-core release release status emails very well received -Khem seems to have found part of the problem w/ gcc 4.8 (and ARM) -also a gcc 4.8 patch from Bruce into M2 now bitbake wrapper script removed python 2.7 now required - problem for CentOS 6.4 mitigated by buildtools-tarball, will cover in docs b. meta-oe appends/overlayed recipes RFC still remaining: busybox and gst-ffmpeg bbappends, xserver-nodm-init Warning: PRINC is deprecated, the use of the PR server is recommended, see ... =issue warning, plan to make it an error in 1.5, revisit before release (RP) =document PRINC - PR server migration steps (fray) =proposal: error and a disable flag, revise RFC patch (fray) RFC switching wholeheartedly to libav (bluelightning) sent, a few responses -two bbappends left: gst-ffmpeg (bluelightning) and busybox (khem) also tslib (overlay), bluelightning pinging kergoth c. python 3 need to start informing people of it -now- -currently tackling 2.7.3 first probably 2.7.3 in 1.5, move to python 3 in 1.6 d. release status notification =maintain a wiki page to summarize release goals (jefro) ___ 5. infrastructure a. oe.org flooded = investigate YP hosting, kernel.org mirror (jefro) reporting system when there are issues, make sure the appropriate people are notified monitor for now -investigation underway recommendation made ___ 6. projects deferred a. raise awareness of janitor list, QA bugs defer to after 1.4 b. document whitespace changes to the shell http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines http://www.openembedded.org/wiki/Styleguide https://wiki.yoctoproject.org/wiki/Recipe_%26_Patch_Style_Guide = still need to de-dup these, need a volunteer ask for volunteers after 1.4 (jefro) c. raise ntp with the Yocto Project [RP] immediate need addressed, reasonable default needed use LICENSE_FLAGS - non-commercial no default set after Paul's changes RP raised with YP AB = going to mailing lists someone should write a proposal = fray will send to list after 1.4 Raw Transcript (9:00:19 AM) fray: Hello (9:00:26 AM) Jefro: good morning (9:00:27 AM) koen: hi (9:00:31 AM) RP: Hi all (9:00:50 AM) Jefro: looks like we are just waiting for khem - agenda is at http://pastebin.com/jeeGWbYu (9:01:35 AM) bluelightning: hi all (9:03:18 AM) Jefro: no response from khem, he may be driving - give him a few mins? (9:07:21 AM) ***fray reads the libtool 'hate' threads and approves.. (9:07:52 AM) fray: I just wonder if removing the .la (and even libtool) what repurcussions that may have in changes in the way the build works.. :( (9:08:05 AM) fray: another couple minutes or should we get going? (9:08:40 AM) koen: it might break AIX versions from the early 1990s (9:08:49 AM) bluelightning: Jefro: FYI I think you need to
Re: [OE-core] [PATCH 2/2] strace: update to 4.8
On 2013?06?18? 21:05, Kai Kang wrote: Update strace to 4.8. * Update License file. * Remove the backport patches which are already in version 4.8. * Add file git-version-gen from git repo. Without this file configure fails. * Add libaio and acl to PACKAGECONFIG for target package. Make libaio as a dependency by default which could be covered easily. Signed-off-by: Kai Kang kai.k...@windriver.com --- ...ilding-when-glibc-has-a-stub-process_vm_r.patch | 54 - .../strace-4.7/0014-x32-update-syscall-table.patch | 91 - ...-x32-update-g-s-etsockopt-syscall-numbers.patch | 43 - .../0024-x32-add-64bit-annotation-too.patch| 231 -- .../0025-Add-e-trace-memory-option.patch | 2898 ...ew-errno-values-for-EPROBE_DEFER-and-EOPE.patch | 36 - .../0027-Add-AArch64-support-to-strace.patch | 542 .../0028-Enhance-quotactl-decoding.patch | 391 --- ...029-Filter-out-redundant-32-ioctl-entries.patch | 145 - ...neric-ioctl-definitions-to-linux-ioctlent.patch | 571 ...-for-tracing-32-bit-ARM-EABI-binaries-on-.patch | 963 --- .../0032-Fix-kernel-release-string-parsing.patch | 38 - .../strace/strace-4.8/git-version-gen | 225 ++ meta/recipes-devtools/strace/strace_4.7.bb | 34 - meta/recipes-devtools/strace/strace_4.8.bb | 32 + 15 files changed, 257 insertions(+), 6037 deletions(-) delete mode 100644 meta/recipes-devtools/strace/strace-4.7/0003-util-fix-building-when-glibc-has-a-stub-process_vm_r.patch delete mode 100644 meta/recipes-devtools/strace/strace-4.7/0014-x32-update-syscall-table.patch delete mode 100644 meta/recipes-devtools/strace/strace-4.7/0018-x32-update-g-s-etsockopt-syscall-numbers.patch delete mode 100644 meta/recipes-devtools/strace/strace-4.7/0024-x32-add-64bit-annotation-too.patch delete mode 100644 meta/recipes-devtools/strace/strace-4.7/0025-Add-e-trace-memory-option.patch delete mode 100644 meta/recipes-devtools/strace/strace-4.7/0026-linux-add-new-errno-values-for-EPROBE_DEFER-and-EOPE.patch delete mode 100644 meta/recipes-devtools/strace/strace-4.7/0027-Add-AArch64-support-to-strace.patch delete mode 100644 meta/recipes-devtools/strace/strace-4.7/0028-Enhance-quotactl-decoding.patch delete mode 100644 meta/recipes-devtools/strace/strace-4.7/0029-Filter-out-redundant-32-ioctl-entries.patch delete mode 100644 meta/recipes-devtools/strace/strace-4.7/0030-Move-asm-generic-ioctl-definitions-to-linux-ioctlent.patch delete mode 100644 meta/recipes-devtools/strace/strace-4.7/0031-Add-support-for-tracing-32-bit-ARM-EABI-binaries-on-.patch delete mode 100644 meta/recipes-devtools/strace/strace-4.7/0032-Fix-kernel-release-string-parsing.patch create mode 100755 meta/recipes-devtools/strace/strace-4.8/git-version-gen delete mode 100644 meta/recipes-devtools/strace/strace_4.7.bb create mode 100644 meta/recipes-devtools/strace/strace_4.8.bb diff --git a/meta/recipes-devtools/strace/strace-4.7/0003-util-fix-building-when-glibc-has-a-stub-process_vm_r.patch b/meta/recipes-devtools/strace/strace-4.7/0003-util-fix-building-when-glibc-has-a-stub-process_vm_r.patch deleted file mode 100644 index 2fd80ec..000 --- a/meta/recipes-devtools/strace/strace-4.7/0003-util-fix-building-when-glibc-has-a-stub-process_vm_r.patch +++ /dev/null @@ -1,54 +0,0 @@ -Upstream-Status: Backport - -From 24ee60b836ad33bb4ac694ca99d6c94a8cc5ff92 Mon Sep 17 00:00:00 2001 -From: Mike Frysinger vap...@gentoo.org -Date: Fri, 4 May 2012 19:37:29 -0400 -Subject: [PATCH 03/31] util: fix building when glibc has a stub - process_vm_readv - -If you have a newer glibc which provides process_vm_readv, but it is built -against older kernel headers which lack __NR_process_vm_readv, the library -will contain a stub implementation that just returns ENOSYS. Autoconf -checks for this case explicitly and will declare it as unavailable. So we -end up in a case where the headers provide the prototype, but autoconf has -not defined HAVE_PROCESS_VM_READV, so we hit the same build failure again: - -util.c:738:16: error: static declaration of 'process_vm_readv' follows non-static declaration -/usr/include/bits/uio.h:58:16: note: previous declaration of 'process_vm_readv' was here - -So rename our local function to something unique, and add a define so the -callers all hit the right place. - -* util.c (strace_process_vm_readv): Rename from process_vm_readv. -(process_vm_readv): Define to strace_process_vm_readv. - -Signed-off-by: Mike Frysinger vap...@gentoo.org - util.c | 4 +++- - 1 file changed, 3 insertions(+), 1 deletion(-) - ... snip ... diff --git a/meta/recipes-devtools/strace/strace_4.7.bb b/meta/recipes-devtools/strace/strace_4.7.bb deleted file mode 100644 index e360e63..000 --- a/meta/recipes-devtools/strace/strace_4.7.bb +++ /dev/null @@ -1,34 +0,0 @@ -DESCRIPTION = strace is a system call tracing tool. -HOMEPAGE =
[OE-core] Problem with buildtools-tarball / nativesdk-ncurses / nativesdk-python
My host system's python version is too old due to the recent changes. So I built a temporary python 2.7.3 version. Built the 'buildtools-tarball' and then installed it. When I switch to the included python it no longer works. I did some digging, the problem in the end is related to ncurses within the nativesdk. Running the following: py_v26_check=`python -c 'import sys; print sys.version_info = (2,6,3)'` which python echo $py_v26_check | od -c if [ $py_v26_check != True ]; then echo BitBake requires Python 2.7.3 or later exit 1 fi You can see the difference in behavior: TERM=xterm /home/lmhatle/build-qemux86_64-2/buildtools/sysroots/x86_64-wrlinuxsdk-linux/usr/bin/python 000 033 [ ? 1 0 3 4 h T r u e \n 015 BitBake requires Python 2.7.3 or later - TERM=vt100 /home/lmhatle/build-qemux86_64-2/buildtools/sysroots/x86_64-wrlinuxsdk-linux/usr/bin/python 000 T r u e \n 005 - So as you can see specifying a different terminal type is happily changing the output of python. When I use my locally built version, I don't get the same behavior. I always get the second version. So is there a problem with the nativesdk python, nativesdk ncurses or??? (I've not yet filed a bug on this, but I will if I can't figure it out soon.) --Mark ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1]wget:fix do_configure failed
The following changes since commit 1dd643b142c69ac9035e29bff11d02201638dc65: licences: Add SGI license (2013-06-17 16:45:37 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib hongxu/fix-wget http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=hongxu/fix-wget Hongxu Jia (1): wget:fix do_configure failed meta/recipes-extended/wget/wget.inc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 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/1] wget:fix do_configure failed
Create a new build enviroment, build wget failed ... configure:34512: checking for libssl configure:34542: i586-poky-linux-gcc -m32 -march=i586 --sysroot=/home/jiahongxu/yocto/build-20130613-qemu/tmp/sysroots/qemux86 -o conftest - O2 -pipe -g -feliminate-unused-debug-types -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed conftest.c -ldl -lssl /home/jiahongxu/yocto/build- 20130613-qemu/tmp/sysroots/qemux86/lib/libcrypto.so -lz 5 /home/jiahongxu/yocto/build-20130613-qemu/tmp/sysroots/x86_64-linux/usr/libexec/i586-poky-linux/gcc/i586-poky-linux/4.7.2/ld: cannot find -lz collect2: error: ld returned 1 exit status ... From log as we known, the reason is link zlib failed, it isn't explicitly in wget's DEPENDS. Add zlib to wget's DEPENDS. [YOCTO #4749] Signed-off-by: Hongxu Jia hongxu@windriver.com --- meta/recipes-extended/wget/wget.inc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-extended/wget/wget.inc b/meta/recipes-extended/wget/wget.inc index ba37a87..de9b620 100644 --- a/meta/recipes-extended/wget/wget.inc +++ b/meta/recipes-extended/wget/wget.inc @@ -2,7 +2,7 @@ DESCRIPTION = A console URL download utility featuring HTTP, FTP, and more. SECTION = console/network LICENSE = GPLv3 LIC_FILES_CHKSUM = file://COPYING;md5=d32239bcb673463ab874e80d47fae504 -DEPENDS = openssl +DEPENDS = openssl zlib INC_PR = r16 -- 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 1/1] cairo: fix build error since toolchain has not get_feature command
On 06/18/2013 10:17 PM, Mark Hatle wrote:
On 6/18/13 1:02 AM, rongqing...@windriver.com wrote:
From: Roy.Li rongqing...@windriver.com
Signed-off-by: Roy.Li rongqing...@windriver.com
---
...-check-stderr-when-test-compiling-in-conf.patch | 39
meta/recipes-graphics/cairo/cairo_1.12.14.bb |3 +-
2 files changed, 41 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-graphics/cairo/cairo/cairo-don-t-check-stderr-when-test-compiling-in-conf.patch
diff --git
a/meta/recipes-graphics/cairo/cairo/cairo-don-t-check-stderr-when-test-compiling-in-conf.patch
b/meta/recipes-graphics/cairo/cairo/cairo-don-t-check-stderr-when-test-compiling-in-conf.patch
new file mode 100644
index 000..e04c3b2
--- /dev/null
+++
b/meta/recipes-graphics/cairo/cairo/cairo-don-t-check-stderr-when-test-compiling-in-conf.patch
@@ -0,0 +1,39 @@
+From 1581e5373c5917ed8ff6f7129c51160594c927d1 Mon Sep 17 00:00:00 2001
+From: Song.Li song...@windriver.com
+Date: Mon, 30 Jul 2012 16:38:02 +0800
+Subject: [PATCH] cairo:don't check stderr when test compiling in
configure
+
+Upstream-Status: Pending
+
+cairo configure use a special macro to test compiling feature.
+It'll require no any warnings or errors in stderr.That is too strict.
+for example, when there is no get_feature in gcc,
+gcc will print no get_feature in stderr, but that is not a real error.
FYI -- 'get_feature' is something specific to Wind River. The patch is
still reasonable, but the commit description might need some cleanup for
people not familiar with some of our internal tools.
I'd suggest just removing the example part.
--Mark
I will drop this patch until the build failure happens on oe-core.
-Roy
+so let cairo don't check stderr,just check the return value of compiling
+is enough.
+
+Signed-off-by: Song.Li song...@windriver.com
+---
+ build/aclocal.cairo.m4 |6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/build/aclocal.cairo.m4 b/build/aclocal.cairo.m4
+index 592e168..4de3b26 100644
+--- a/build/aclocal.cairo.m4
b/build/aclocal.cairo.m4
+@@ -106,9 +106,9 @@ AC_DEFUN([CAIRO_CC_TRY_LINK_WITH_ENV_SILENT],[dnl
+ [cairo_cc_stderr=`test -f conftest.err cat conftest.err`
+ cairo_cc_flag=no])
+
+-if test x$cairo_cc_stderr != x; then
+-cairo_cc_flag=no
+-fi
++dnlif test x$cairo_cc_stderr != x; then
++dnlcairo_cc_flag=no
++dnlfi
+
+ if test x$cairo_cc_flag = xyes; then
+ ifelse([$3], , :, [$3])
+--
+1.7.9.5
+
diff --git a/meta/recipes-graphics/cairo/cairo_1.12.14.bb
b/meta/recipes-graphics/cairo/cairo_1.12.14.bb
index 40aa169..5c8c9cd 100644
--- a/meta/recipes-graphics/cairo/cairo_1.12.14.bb
+++ b/meta/recipes-graphics/cairo/cairo_1.12.14.bb
@@ -5,7 +5,8 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=e73e999e0c72b5ac9012424fa157ad77
PR = r0
SRC_URI = http://cairographics.org/releases/cairo-${PV}.tar.xz \
- file://png.patch
+ file://png.patch \
+
file://cairo-don-t-check-stderr-when-test-compiling-in-conf.patch
SRC_URI[md5sum] = 27b634113d0f52152d60ae8e2ec7daa7
SRC_URI[sha256sum] =
96d0d1e3f9b74d2ca3469ff187c5e5f25649b1ad35cf06f4f3a83847dff4ac13
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Best Reagrds,
Roy | RongQing Li
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] procps: fix that top will quit after cpu offline
From: Wenzong Fan wenzong@windriver.com top utiliy fails to read /proc/stat after cpu offline, because Cpu_tot is still the original cpu numbers when calling cpus_refresh, in which it is trying to read and sscanf Cpu_tot times /proc/stat. The patch is from procps-3.2.8-2.fc12.src.rpm The following changes since commit 590010a6525b0e1bc1de73e794764e23404591df: core-image-weston: add weston-examples to the image (2013-06-18 17:33:17 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib wenzong/procps http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=wenzong/procps Wenzong Fan (1): procps: fix that top will quit after cpu offline .../procps-3.2.8/procps-3.2.7-top-remcpu.patch | 111 meta/recipes-extended/procps/procps_3.2.8.bb |1 + 2 files changed, 112 insertions(+) create mode 100644 meta/recipes-extended/procps/procps-3.2.8/procps-3.2.7-top-remcpu.patch -- 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] procps: fix that top will quit after cpu offline
From: Wenzong Fan wenzong@windriver.com
top utiliy fails to read /proc/stat after cpu offline, because Cpu_tot
is still the original cpu numbers when calling cpus_refresh, in which
it is trying to read and sscanf Cpu_tot times /proc/stat.
The patch is from procps-3.2.8-2.fc12.src.rpm
Signed-off-by: Wenzong Fan wenzong@windriver.com
---
.../procps-3.2.8/procps-3.2.7-top-remcpu.patch | 111
meta/recipes-extended/procps/procps_3.2.8.bb |1 +
2 files changed, 112 insertions(+)
create mode 100644
meta/recipes-extended/procps/procps-3.2.8/procps-3.2.7-top-remcpu.patch
diff --git
a/meta/recipes-extended/procps/procps-3.2.8/procps-3.2.7-top-remcpu.patch
b/meta/recipes-extended/procps/procps-3.2.8/procps-3.2.7-top-remcpu.patch
new file mode 100644
index 000..0306c8d
--- /dev/null
+++ b/meta/recipes-extended/procps/procps-3.2.8/procps-3.2.7-top-remcpu.patch
@@ -0,0 +1,111 @@
+Upstream-Status: Pending
+
+fix that top will quit after cpu offline
+
+top utiliy fails to read /proc/stat after cpu offline, because Cpu_tot
+is still the original cpu numbers when calling cpus_refresh, in which
+it is trying to read and sscanf Cpu_tot times /proc/stat.
+
+The patch is from procps-3.2.8-2.fc12.src.rpm
+
+Signed-off-by: Wenzong Fan wenzong@windriver.com
+
+---
+--- procps-3.2.7/top.c.remcpu 2006-07-10 10:41:11.0 +0200
procps-3.2.7/top.c 2006-07-10 10:41:35.0 +0200
+@@ -912,6 +912,7 @@
+ static CPU_t *cpus_refresh (CPU_t *cpus)
+ {
+static FILE *fp = NULL;
++ static int cpu_max;
+int i;
+int num;
+// enough for a /proc/stat CPU line (not the intr line)
+@@ -926,24 +927,29 @@
+can hold tics representing the /proc/stat cpu summary (the
first
+line read) -- that slot supports our View_CPUSUM toggle */
+ cpus = alloc_c((1 + Cpu_tot) * sizeof(CPU_t));
++ cpu_max = Cpu_tot;
+}
++ else if (cpu_max Cpu_tot)
++ /* move saved CUPs summary to cpu_max possition */
++ memcpy(cpus[cpu_max], cpus[Cpu_tot], sizeof(CPU_t));
++
+rewind(fp);
+fflush(fp);
+
+// first value the last slot with the cpu summary line
+if (!fgets(buf, sizeof(buf), fp)) std_err(failed /proc/stat read);
+- cpus[Cpu_tot].x = 0; // FIXME: can't tell by kernel version number
+- cpus[Cpu_tot].y = 0; // FIXME: can't tell by kernel version number
+- cpus[Cpu_tot].z = 0; // FIXME: can't tell by kernel version number
++ cpus[cpu_max].x = 0; // FIXME: can't tell by kernel version number
++ cpus[cpu_max].y = 0; // FIXME: can't tell by kernel version number
++ cpus[cpu_max].z = 0; // FIXME: can't tell by kernel version number
+num = sscanf(buf, cpu %Lu %Lu %Lu %Lu %Lu %Lu %Lu %Lu,
+- cpus[Cpu_tot].u,
+- cpus[Cpu_tot].n,
+- cpus[Cpu_tot].s,
+- cpus[Cpu_tot].i,
+- cpus[Cpu_tot].w,
+- cpus[Cpu_tot].x,
+- cpus[Cpu_tot].y,
+- cpus[Cpu_tot].z
++ cpus[cpu_max].u,
++ cpus[cpu_max].n,
++ cpus[cpu_max].s,
++ cpus[cpu_max].i,
++ cpus[cpu_max].w,
++ cpus[cpu_max].x,
++ cpus[cpu_max].y,
++ cpus[cpu_max].z
+);
+if (num 4)
+ std_err(failed /proc/stat read);
+@@ -955,7 +961,7 @@
+}
+
+// now value each separate cpu's tics
+- for (i = 0; 1 Cpu_tot i Cpu_tot; i++) {
++ for (i = 0; ; i++) {
+ if (!fgets(buf, sizeof(buf), fp)) std_err(failed /proc/stat read);
+ cpus[i].x = 0; // FIXME: can't tell by kernel version number
+ cpus[i].y = 0; // FIXME: can't tell by kernel version number
+@@ -964,9 +970,35 @@
+ cpus[i].id,
+ cpus[i].u, cpus[i].n, cpus[i].s, cpus[i].i, cpus[i].w,
cpus[i].x, cpus[i].y, cpus[i].z
+ );
+- if (num 4)
+-std_err(failed /proc/stat read);
++ if (num 4) {
++ Cpu_tot = i;
++ break;
++ }
++ if (i == cpu_max - 1) {
++ // Bump cpu_max and extend cpus
++ cpu_max++;
++ cpus = realloc(cpus, (1 + cpu_max) * sizeof(CPU_t));
++ if (!cpus) std_err(realloc failed);
++ memcpy(cpus[cpu_max], cpus[cpu_max-1], sizeof(CPU_t));
++ }
++ }
++
++ if (cpu_max Cpu_tot)
++ memcpy(cpus[Cpu_tot], cpus[cpu_max], sizeof(CPU_t));
++
++ // and just in case we're 2.2.xx compiled without SMP support...
++ if (Cpu_tot == 1) {
++ cpus[0].id = cpus[1].id = 0;
++ cpus[0].u = cpus[1].u;
++ cpus[0].n = cpus[1].n;
++ cpus[0].s = cpus[1].s;
++ cpus[0].i = cpus[1].i;
++ cpus[0].w = cpus[1].w;
++ cpus[0].x = cpus[1].x;
++ cpus[0].y = cpus[1].y;
++ cpus[0].z = cpus[1].z;
+}
++
+return cpus;
+ }
+
diff --git a/meta/recipes-extended/procps/procps_3.2.8.bb
b/meta/recipes-extended/procps/procps_3.2.8.bb
index 7533859..8436d4a 100644
--- a/meta/recipes-extended/procps/procps_3.2.8.bb
+++ b/meta/recipes-extended/procps/procps_3.2.8.bb
@@ -9,6 +9,7 @@ SRC_URI += file://procmodule.patch \
[OE-core] [PATCH 1/1] libpam: Fix for CVE-2010-4708
From: Wenzong Fan wenzong@windriver.com
Change default for user_readenv to 0 and document the
new default for user_readenv.
This fix from:
http://pam.cvs.sourceforge.net/viewvc/pam/Linux-PAM/modules/pam_env
/pam_env.c?r1=1.22r2=1.23view=patch
http://pam.cvs.sourceforge.net/viewvc/pam/Linux-PAM/modules/pam_env
/pam_env.8.xml?r1=1.7r2=1.8view=patch
Signed-off-by: Wenzong Fan wenzong@windriver.com
---
.../pam/libpam/libpam-fix-for-CVE-2010-4708.patch | 41
meta/recipes-extended/pam/libpam_1.1.6.bb |1 +
2 files changed, 42 insertions(+)
create mode 100644
meta/recipes-extended/pam/libpam/libpam-fix-for-CVE-2010-4708.patch
diff --git
a/meta/recipes-extended/pam/libpam/libpam-fix-for-CVE-2010-4708.patch
b/meta/recipes-extended/pam/libpam/libpam-fix-for-CVE-2010-4708.patch
new file mode 100644
index 000..5d2b69a
--- /dev/null
+++ b/meta/recipes-extended/pam/libpam/libpam-fix-for-CVE-2010-4708.patch
@@ -0,0 +1,41 @@
+Upstream-Status: Backport
+
+Fix for CVE-2010-4708
+
+Change default for user_readenv to 0 and document the
+new default for user_readenv.
+
+This fix is got from:
+http://pam.cvs.sourceforge.net/viewvc/pam/Linux-PAM/modules/pam_env
+/pam_env.c?r1=1.22r2=1.23view=patch
+http://pam.cvs.sourceforge.net/viewvc/pam/Linux-PAM/modules/pam_env
+/pam_env.8.xml?r1=1.7r2=1.8view=patch
+
+Signed-off-by: Wenzong Fan wenzong@windriver.com
+
+---
+--- a/modules/pam_env/pam_env.c2012-09-05 13:57:47.0 +0800
b/modules/pam_env/pam_env.c2012-09-05 13:58:05.0 +0800
+@@ -10,7 +10,7 @@
+ #define DEFAULT_READ_ENVFILE1
+
+ #define DEFAULT_USER_ENVFILE.pam_environment
+-#define DEFAULT_USER_READ_ENVFILE 1
++#define DEFAULT_USER_READ_ENVFILE 0
+
+ #include config.h
+
+--- a/modules/pam_env/pam_env.8.xml2012-09-05 13:58:24.0 +0800
b/modules/pam_env/pam_env.8.xml2012-09-05 13:59:36.0 +0800
+@@ -147,7 +147,10 @@
+ listitem
+ para
+ Turns on or off the reading of the user specific environment
+-file. 0 is off, 1 is on. By default this option is on.
++file. 0 is off, 1 is on. By default this option is off as user
++supplied environment variables in the PAM environment could affect
++behavior of subsequent modules in the stack without the consent
++of the system administrator.
+ /para
+ /listitem
+ /varlistentry
diff --git a/meta/recipes-extended/pam/libpam_1.1.6.bb
b/meta/recipes-extended/pam/libpam_1.1.6.bb
index 73a8f88..94101d4 100644
--- a/meta/recipes-extended/pam/libpam_1.1.6.bb
+++ b/meta/recipes-extended/pam/libpam_1.1.6.bb
@@ -22,6 +22,7 @@ SRC_URI =
http://linux-pam.org/library/Linux-PAM-${PV}.tar.bz2 \
file://fixsepbuild.patch \
file://reflect-the-enforce_for_root-semantics-change-in-pam.patch \
file://add-checks-for-crypt-returning-NULL.patch \
+ file://libpam-fix-for-CVE-2010-4708.patch \
SRC_URI[md5sum] = 7b73e58b7ce79ffa321d408de06db2c4
SRC_URI[sha256sum] =
bab887d6280f47fc3963df3b95735a27a16f0f663636163ddf3acab5f1149fc2
--
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/1] libpam: Fix for CVE-2010-4708
From: Wenzong Fan wenzong@windriver.com Change default for user_readenv to 0 and document the new default for user_readenv. This fix from: http://pam.cvs.sourceforge.net/viewvc/pam/Linux-PAM/modules/pam_env /pam_env.c?r1=1.22r2=1.23view=patch http://pam.cvs.sourceforge.net/viewvc/pam/Linux-PAM/modules/pam_env /pam_env.8.xml?r1=1.7r2=1.8view=patch The following changes since commit 590010a6525b0e1bc1de73e794764e23404591df: core-image-weston: add weston-examples to the image (2013-06-18 17:33:17 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib wenzong/libpam http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=wenzong/libpam Wenzong Fan (1): libpam: Fix for CVE-2010-4708 .../pam/libpam/libpam-fix-for-CVE-2010-4708.patch | 41 meta/recipes-extended/pam/libpam_1.1.6.bb |1 + 2 files changed, 42 insertions(+) create mode 100644 meta/recipes-extended/pam/libpam/libpam-fix-for-CVE-2010-4708.patch -- 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] V2: Update strace and fix autogen-native build failure
V2: update PACKAGECONFIG default definition of strace The following changes since commit 1dd643b142c69ac9035e29bff11d02201638dc65: licences: Add SGI license (2013-06-17 16:45:37 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib kangkai/update-strace http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=kangkai/update-strace Kai Kang (2): autogen-native: fix build failure on overloaded hosts strace: update to 4.8 .../autogen/autogen-native_5.17.4.bb |3 +- .../autogen/files/increase-timeout-limit.patch | 33 + ...ilding-when-glibc-has-a-stub-process_vm_r.patch | 54 - .../strace-4.7/0014-x32-update-syscall-table.patch | 91 - ...-x32-update-g-s-etsockopt-syscall-numbers.patch | 43 - .../0024-x32-add-64bit-annotation-too.patch| 231 -- .../0025-Add-e-trace-memory-option.patch | 2898 ...ew-errno-values-for-EPROBE_DEFER-and-EOPE.patch | 36 - .../0027-Add-AArch64-support-to-strace.patch | 542 .../0028-Enhance-quotactl-decoding.patch | 391 --- ...029-Filter-out-redundant-32-ioctl-entries.patch | 145 - ...neric-ioctl-definitions-to-linux-ioctlent.patch | 571 ...-for-tracing-32-bit-ARM-EABI-binaries-on-.patch | 963 --- .../0032-Fix-kernel-release-string-parsing.patch | 38 - .../strace/strace-4.8/git-version-gen | 225 ++ meta/recipes-devtools/strace/strace_4.7.bb | 34 - meta/recipes-devtools/strace/strace_4.8.bb | 32 + 17 files changed, 292 insertions(+), 6038 deletions(-) create mode 100644 meta/recipes-devtools/autogen/files/increase-timeout-limit.patch delete mode 100644 meta/recipes-devtools/strace/strace-4.7/0003-util-fix-building-when-glibc-has-a-stub-process_vm_r.patch delete mode 100644 meta/recipes-devtools/strace/strace-4.7/0014-x32-update-syscall-table.patch delete mode 100644 meta/recipes-devtools/strace/strace-4.7/0018-x32-update-g-s-etsockopt-syscall-numbers.patch delete mode 100644 meta/recipes-devtools/strace/strace-4.7/0024-x32-add-64bit-annotation-too.patch delete mode 100644 meta/recipes-devtools/strace/strace-4.7/0025-Add-e-trace-memory-option.patch delete mode 100644 meta/recipes-devtools/strace/strace-4.7/0026-linux-add-new-errno-values-for-EPROBE_DEFER-and-EOPE.patch delete mode 100644 meta/recipes-devtools/strace/strace-4.7/0027-Add-AArch64-support-to-strace.patch delete mode 100644 meta/recipes-devtools/strace/strace-4.7/0028-Enhance-quotactl-decoding.patch delete mode 100644 meta/recipes-devtools/strace/strace-4.7/0029-Filter-out-redundant-32-ioctl-entries.patch delete mode 100644 meta/recipes-devtools/strace/strace-4.7/0030-Move-asm-generic-ioctl-definitions-to-linux-ioctlent.patch delete mode 100644 meta/recipes-devtools/strace/strace-4.7/0031-Add-support-for-tracing-32-bit-ARM-EABI-binaries-on-.patch delete mode 100644 meta/recipes-devtools/strace/strace-4.7/0032-Fix-kernel-release-string-parsing.patch create mode 100755 meta/recipes-devtools/strace/strace-4.8/git-version-gen delete mode 100644 meta/recipes-devtools/strace/strace_4.7.bb create mode 100644 meta/recipes-devtools/strace/strace_4.8.bb -- 1.7.5.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] autogen-native: fix build failure on overloaded hosts
On some overloaded hosts, shell commands of autogen may can not
finish in 5 secs. This has caused many build failures, so increase
the timeout limit to fix this.
Signed-off-by: Kai Kang kai.k...@windriver.com
---
.../autogen/autogen-native_5.17.4.bb |3 +-
.../autogen/files/increase-timeout-limit.patch | 33
2 files changed, 35 insertions(+), 1 deletions(-)
create mode 100644
meta/recipes-devtools/autogen/files/increase-timeout-limit.patch
diff --git a/meta/recipes-devtools/autogen/autogen-native_5.17.4.bb
b/meta/recipes-devtools/autogen/autogen-native_5.17.4.bb
index e5234c2..230c3a7 100644
--- a/meta/recipes-devtools/autogen/autogen-native_5.17.4.bb
+++ b/meta/recipes-devtools/autogen/autogen-native_5.17.4.bb
@@ -9,7 +9,8 @@ LICENSE = GPLv3
LIC_FILES_CHKSUM = file://COPYING;md5=d32239bcb673463ab874e80d47fae504
SRC_URI = ${GNU_MIRROR}/autogen/rel${PV}/autogen-${PV}.tar.gz \
- file://guile.patch
+ file://guile.patch \
+ file://increase-timeout-limit.patch
SRC_URI[md5sum] = 09f074cba57610bf4ef1147e01c8ae90
SRC_URI[sha256sum] =
cd2585f4794d0e9d7f2cb0b9af4f2bd429946e718473edf1cf8c49f081ca71ed
diff --git a/meta/recipes-devtools/autogen/files/increase-timeout-limit.patch
b/meta/recipes-devtools/autogen/files/increase-timeout-limit.patch
new file mode 100644
index 000..3d4c1d6
--- /dev/null
+++ b/meta/recipes-devtools/autogen/files/increase-timeout-limit.patch
@@ -0,0 +1,33 @@
+Subject: [PATCH] autogen: increase timeout limit for shell commands
+
+On some overloaded hosts, shell commands of autogen may can not
+finish in 5 secs. This has caused many build failures, so increase
+the timeout limit to fix this.
+
+Upstream-Status: Inappropriate [configuration]
+
+Signed-off-by: Xin Ouyang xin.ouy...@windriver.com
+---
+ configure.ac |6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/configure.ac b/configure.ac
+index 0af7c18..5544f59 100644
+--- a/configure.ac
b/configure.ac
+@@ -175,9 +175,9 @@ config_end_time=`date +%s 2/dev/null`
+ time_delta=`expr ${config_end_time} - ${config_start_time} 2/dev/null`
+
+ if test -z ${time_delta}
+-then time_delta=10
+-elif test ${time_delta} -lt 5
+-then time_delta=5 ; fi
++then time_delta=60
++elif test ${time_delta} -lt 30
++then time_delta=30 ; fi
+
+ AG_TIMEOUT=${time_delta}
+ ]
+--
+1.7.9.5
+
--
1.7.5.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
