Re: [OE-core] [PATCH] kernel: Use hardlinks for do_populate_sysroot for speed
On Sat, Nov 9, 2013 at 11:58 PM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Sat, 2013-11-09 at 21:38 +0100, Andrea Adami wrote: On Fri, Nov 8, 2013 at 6:23 PM, Hart, Darren darren.h...@intel.com wrote: On Fri, 2013-11-08 at 16:50 +, Richard Purdie wrote: On Fri, 2013-11-08 at 10:59 -0500, Bruce Ashfield wrote: On 13-11-08 10:55 AM, Richard Purdie wrote: On Fri, 2013-11-08 at 10:41 -0500, Bruce Ashfield wrote: On 13-11-08 10:18 AM, Richard Purdie wrote: The kernel tree is large and doesn't need to be copied. Override the default sysroot handling function to use a hardlink copying function in python. This commit also drops the copying of the /lib directory which just contains the kernel modules. We never use those in the sysroot so there is little point in carrying those around. For linux-yocto this takes the do_populate_sysroot time 24s - 14s. Fantastic. One less thing for me to dig into later. I thought this was already in place, so I'm pleasantly surprised that there was a time savings to be found! I was somewhat surprised too. We still need to optimise what we install in do_install since that is where significant gains can still be made. Agreed. I started some changes in that area right after ELC-e, I'll try and get them out sooner rather than later. I thought I'd share this for people's interest: http://dan.rpsys.net/kernelbuildissue.png Its the output from pybootchart of a bitbake core-image-sato from scratch. I've zoomed out to put some bars in particular into perspective. The pink colour is linux-yocto:do_install, the cyan is linux-yocto:do_package and the blue is linux-yocto:do_populate_sysroot. The uncoloured bar at the bottom is linux-yocto:do_package_write_rpm. So the final thing to build is the kernel by quite some margin, its holding the rest of the build up. Hopefully these patches start to improve that a bit! Yup, linux-yocto do_package is the biggest build-time hindrance for me and something we've wanted to look into for a long time. Great to see some progress. -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core On my old quad core: Before: 95.24 seconds After: 83.25 seconds We have some standard tests we use for comparison purposes as detailed on: https://wiki.yoctoproject.org/wiki/Performance_Test Some numbers from master and a test branch containing the recent speedups: fedora19,master:d6cc7c8ed76c8b1117cf03c7bd4b0742f98f79b3,poky-10.0.0.final-359-gd6cc7c8,1:22:37,12:05.50,1:17:53,4:02.68,0:31.71,0:15.70,0:01.61,26347744,5035816 fedora19,master:d6cc7c8ed76c8b1117cf03c7bd4b0742f98f79b3,poky-10.0.0.final-359-gd6cc7c8,1:22:59,12:09.26,1:17:29,4:06.75,0:31.82,0:15.69,0:01.70,26348556,5035876 fedora19,master:d6cc7c8ed76c8b1117cf03c7bd4b0742f98f79b3,poky-10.0.0.final-359-gd6cc7c8,1:22:21,12:07.23,1:18:21,4:07.44,0:31.79,0:15.63,0:01.62,26351088,5035908 fedora19,master:d6cc7c8ed76c8b1117cf03c7bd4b0742f98f79b3,poky-10.0.0.final-359-gd6cc7c8,1:23:16,12:15.33,1:18:00,4:02.50,0:31.87,0:15.74,0:01.63,26348132,5035848 fedora19,rpurdie/timing:9d8c0ef3349936b3bd0bbf485b50cf81f4feaf80,poky-10.0.0.final-373-g9d8c0ef,1:19:42,10:28.53,1:15:30,4:12.24,0:31.30,0:15.69,0:01.66,26137344,5055628 fedora19,rpurdie/timing2:eb2221d6247c12322ac38b9ac6f24c9de5877e53,poky-10.0.0.final-401-geb2221d,1:18:51,10:44.26,1:16:32,4:13.47,0:31.27,0:15.69,0:01.65,26137828,5055916 So we have 1:23m - 1:19m for overall buildtime and 12.0m - 10.5m for bitbake virtual/kernel from cleansstate. Not too bad :) Thanks to Stefan for running the tests! I am having some trouble with these patches :( The new approach is using the '-n' flag to the 'cp' command. That is not supported on our SuSE11 based system. To be honest, I do not know how portable '-n' is? Some system have it, others seems to provide '-u' instead. I guess by removing '-n' part of the performance gain is lost? Would it be possible to test for error from the 'cp' command and if it fails try '-u' instead (and cache the result)? Or maybe even better, make this configurable in local.conf (or the distro) for the build platforms that does not support '-n' but can instead fall-back to using '-u'. From what I can tell most systems support one or the other, but never both. Thanks. Hans Cheers, Richard ___ 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
[OE-core] [PATCH 1/2] tcl: Install header into 8.6 instead of PN-PV in user/include
This helps in compiling other programs like expect which
depend on private headers but 8.5, 8.6 and so on is enough
granularity and currently we had 8.6.x and so on which
means that expect recipe will need to be touched whenever there
is minor update of tcl.
Additionally the encode creating symlink to shared object in
patch and remove it from recipe
Refresh patches after making changes to Configure.in we
propertly generate configure and not patch is directly as
was the case.
Signed-off-by: Khem Raj raj.k...@gmail.com
---
.../tcltk/tcl/alter-includedir.patch | 39 +
.../tcl/fix_issue_with_old_distro_glibc.patch | 12 ++--
.../tcltk/tcl/fix_non_native_build_issue.patch | 12 ++--
meta/recipes-devtools/tcltk/tcl/no_packages.patch | 16 +++---
.../tcltk/tcl/tcl-add-soname.patch | 64 ++
.../tcl/tcl-remove-hardcoded-install-path.patch| 26 ++---
meta/recipes-devtools/tcltk/tcl_8.6.1.bb | 26 +
7 files changed, 120 insertions(+), 75 deletions(-)
create mode 100644 meta/recipes-devtools/tcltk/tcl/alter-includedir.patch
diff --git a/meta/recipes-devtools/tcltk/tcl/alter-includedir.patch
b/meta/recipes-devtools/tcltk/tcl/alter-includedir.patch
new file mode 100644
index 000..32e63c0
--- /dev/null
+++ b/meta/recipes-devtools/tcltk/tcl/alter-includedir.patch
@@ -0,0 +1,39 @@
+Index: unix/Makefile.in
+===
+--- unix.orig/Makefile.in 2013-11-11 01:00:36.431550403 -0800
unix/Makefile.in 2013-11-11 01:05:09.587557282 -0800
+@@ -53,7 +53,7 @@
+ SCRIPT_INSTALL_DIR= $(INSTALL_ROOT)$(TCL_LIBRARY)
+
+ # Directory in which to install the include file tcl.h:
+-INCLUDE_INSTALL_DIR = $(INSTALL_ROOT)$(includedir)
++INCLUDE_INSTALL_DIR = $(INSTALL_ROOT)$(includedir)/tcl$(VERSION)
+
+ # Path to the private tcl header dir:
+ PRIVATE_INCLUDE_DIR = @PRIVATE_INCLUDE_DIR@
+Index: unix/configure.in
+===
+--- unix.orig/configure.in 2013-11-11 01:00:36.467550403 -0800
unix/configure.in 2013-11-11 01:00:36.503550404 -0800
+@@ -791,7 +791,7 @@
+ eval TCL_LIB_FILE=${TCL_LIB_FILE}
+
+ TCL_LIBRARY='$(libdir)/tcl$(VERSION)'
+-PRIVATE_INCLUDE_DIR='$(includedir)'
++PRIVATE_INCLUDE_DIR='$(includedir)/tcl$(VERSION)'
+ HTML_DIR='$(DISTDIR)/html'
+
+ # Note: in the following variable, it's important to use the absolute
+Index: unix/configure
+===
+--- unix.orig/configure2013-11-11 01:00:36.467550403 -0800
unix/configure 2013-11-11 01:00:36.503550404 -0800
+@@ -19134,7 +19134,7 @@
+ eval TCL_LIB_FILE=${TCL_LIB_FILE}
+
+ TCL_LIBRARY='$(libdir)/tcl$(VERSION)'
+-PRIVATE_INCLUDE_DIR='$(includedir)'
++PRIVATE_INCLUDE_DIR='$(includedir)/tcl$(VERSION)'
+ HTML_DIR='$(DISTDIR)/html'
+
+ # Note: in the following variable, it's important to use the absolute
diff --git
a/meta/recipes-devtools/tcltk/tcl/fix_issue_with_old_distro_glibc.patch
b/meta/recipes-devtools/tcltk/tcl/fix_issue_with_old_distro_glibc.patch
index ed58175..be27341 100644
--- a/meta/recipes-devtools/tcltk/tcl/fix_issue_with_old_distro_glibc.patch
+++ b/meta/recipes-devtools/tcltk/tcl/fix_issue_with_old_distro_glibc.patch
@@ -15,11 +15,11 @@ Fixes tcl target recipe build on old distros which have
glibc older than 2.14
Signed-Off-By: Nitin A Kamble nitin.a.kam...@intel.com
2012/04/26
-diff --git unix.orig/Makefile.in unix/Makefile.in
-index 571d53f..16351f6 100644
unix.orig/Makefile.in
-+++ unix/Makefile.in
-@@ -679,7 +679,7 @@ topDirName:
+Index: unix/Makefile.in
+===
+--- unix.orig/Makefile.in 2013-11-10 23:38:01.787425628 -0800
unix/Makefile.in 2013-11-10 23:37:59.807425578 -0800
+@@ -686,7 +686,7 @@
# tcltest executable gets the build directory burned into its ld search path.
# This keeps tcltest from picking up an already installed version of the Tcl
# library.
@@ -28,7 +28,7 @@ index 571d53f..16351f6 100644
TCLLIBPATH=@abs_builddir@/pkgs \
TCL_LIBRARY=${TCL_BUILDTIME_LIBRARY}
-@@ -705,7 +705,7 @@ test-tcl: ${TCLTEST_EXE}
+@@ -712,7 +712,7 @@
$(SHELL_ENV) ${TCLTEST_EXE} $(TOP_DIR)/tests/all.tcl $(TESTFLAGS)
gdb-test: ${TCLTEST_EXE}
diff --git a/meta/recipes-devtools/tcltk/tcl/fix_non_native_build_issue.patch
b/meta/recipes-devtools/tcltk/tcl/fix_non_native_build_issue.patch
index 80d718c..c60eb75 100644
--- a/meta/recipes-devtools/tcltk/tcl/fix_non_native_build_issue.patch
+++ b/meta/recipes-devtools/tcltk/tcl/fix_non_native_build_issue.patch
@@ -1,10 +1,10 @@
Upstream-Status: Pending
-diff --git unix.orig/Makefile.in unix/Makefile.in
-index df05759..571d53f 100644
unix.orig/Makefile.in
-+++ unix/Makefile.in
-@@ -702,23 +702,23 @@ tcltest-real:
+Index: unix/Makefile.in
[OE-core] [PATCH V7 2/2] expect: Add recipe
From: Mihaela Sendrea mihaela.send...@enea.com
Nedeed for gcc-runtime tests.
Fixed build on multilib and add patch to remove
!/depot/path/expect -f
which caused rpm to puke on rfs generation
Signed-off-by: Mihaela Sendrea mihaela.send...@enea.com
Signed-off-by: Khem Raj raj.k...@gmail.com
---
.../expect/expect/0001-configure.in.patch | 108
.../expect/expect/0002-tcl.m4.patch| 17 +++
.../expect/expect/01-example-shebang.patch | 144 +
meta/recipes-devtools/expect/expect_5.45.bb| 61 +
4 files changed, 330 insertions(+)
create mode 100644 meta/recipes-devtools/expect/expect/0001-configure.in.patch
create mode 100644 meta/recipes-devtools/expect/expect/0002-tcl.m4.patch
create mode 100644 meta/recipes-devtools/expect/expect/01-example-shebang.patch
create mode 100644 meta/recipes-devtools/expect/expect_5.45.bb
diff --git a/meta/recipes-devtools/expect/expect/0001-configure.in.patch
b/meta/recipes-devtools/expect/expect/0001-configure.in.patch
new file mode 100644
index 000..7595a25
--- /dev/null
+++ b/meta/recipes-devtools/expect/expect/0001-configure.in.patch
@@ -0,0 +1,108 @@
+Allow cross compiling.
+
+Signed-off-by: Anders Roxell anders.rox...@enea.com
+Upstream-Status: Pending
+---
+diff -uNr a/configure.in b/configure.in
+--- a/configure.in 2012-12-14 15:31:32.623180450 +0100
b/configure.in 2012-12-14 15:53:34.518233519 +0100
+@@ -481,7 +481,7 @@
+ ,
+ AC_MSG_RESULT(no)
+ ,
+- AC_MSG_ERROR([Expect can't be cross compiled])
++ AC_MSG_RESULT(no)
+ )
+
+ AC_MSG_CHECKING([if any value exists for WNOHANG])
+@@ -506,7 +506,9 @@
+ AC_MSG_RESULT(no)
+ AC_DEFINE(WNOHANG_BACKUP_VALUE, 1)
+ ,
+- AC_MSG_ERROR([Expect can't be cross compiled])
++ AC_MSG_RESULT(yes)
++ AC_DEFINE_UNQUOTED(WNOHANG_BACKUP_VALUE, `cat wnohang`)
++ rm -f wnohang
+ )
+
+ #
+@@ -574,7 +576,8 @@
+ AC_DEFINE(REARM_SIG)
+ ,
+ AC_MSG_RESULT(no)
+-, AC_MSG_WARN([Expect can't be cross compiled])
++,
++ AC_MSG_RESULT(no)
+ )
+
+ # HPUX7 has trouble with the big cat so split it
+@@ -725,7 +728,9 @@
+ ,
+ AC_MSG_RESULT(no)
+ ,
+- AC_MSG_ERROR([Expect can't be cross compiled])
++AC_MSG_RESULT(yes)
++AC_DEFINE(HAVE_SGTTYB)
++PTY_TYPE=sgttyb
+ )
+
+ # mach systems have include files for unimplemented features
+@@ -749,7 +754,9 @@
+ ,
+ AC_MSG_RESULT(no)
+ ,
+- AC_MSG_ERROR([Expect can't be cross compiled])
++AC_DEFINE(HAVE_TERMIO)
++PTY_TYPE=termios
++AC_MSG_RESULT(yes)
+ )
+
+ # now check for the new style ttys (not yet posix)
+@@ -771,7 +778,9 @@
+ ,
+ AC_MSG_RESULT(no)
+ ,
+- AC_MSG_ERROR([Expect can't be cross compiled])
++AC_DEFINE(HAVE_TERMIOS)
++PTY_TYPE=termios
++AC_MSG_RESULT(yes)
+ )
+ fi
+
+@@ -794,7 +803,7 @@
+ ,
+ AC_MSG_RESULT(no)
+ ,
+- AC_MSG_ERROR([Expect can't be cross compiled])
++ AC_MSG_RESULT(no)
+ )
+
+ AC_MSG_CHECKING([if TIOCGWINSZ in termios.h])
+@@ -816,7 +825,7 @@
+ ,
+ AC_MSG_RESULT(no)
+ ,
+- AC_MSG_ERROR([Expect can't be cross compiled])
++ AC_MSG_RESULT(no)
+ )
+
+ # finally check for Cray style ttys
+@@ -837,7 +846,7 @@
+ ,
+ AC_MSG_RESULT(no)
+ ,
+- AC_MSG_ERROR([Expect can't be cross compiled])
++ AC_MSG_RESULT(no)
+ )
+
+ #
+@@ -889,7 +898,8 @@
+ AC_MSG_RESULT(yes),
+ AC_MSG_RESULT(no)
+ ,
+- AC_MSG_ERROR([Expect can't be cross compiled])
++ AC_DEFINE(HAVE_SV_TIMEZONE)
++ AC_MSG_RESULT(yes),
+ )
+
+
diff --git a/meta/recipes-devtools/expect/expect/0002-tcl.m4.patch
b/meta/recipes-devtools/expect/expect/0002-tcl.m4.patch
new file mode 100644
index 000..dc4c6ba
--- /dev/null
+++ b/meta/recipes-devtools/expect/expect/0002-tcl.m4.patch
@@ -0,0 +1,17 @@
+Use proper -L path when cross compiling.
+
+Signed-off-by: Anders Roxell anders.rox...@enea.com
+Upstream-Status: Pending
+---
+diff -uNr a/tclconfig/tcl.m4 b/tclconfig/tcl.m4
+--- a/tclconfig/tcl.m4 2012-12-14 09:16:58.789861281 +0100
b/tclconfig/tcl.m4 2012-12-14 10:55:43.542297010 +0100
+@@ -371,7 +371,7 @@
+ # of TCL_BUILD_LIB_SPEC. An extension should make use of TCL_LIB_SPEC
+ # instead of TCL_BUILD_LIB_SPEC since it will work with both an
+ # installed and uninstalled version of Tcl.
+-if test -f ${TCL_BIN_DIR}/Makefile ; then
++if test -f ${TCL_BIN_DIR}/Makefile || test $cross_compiling = yes;
then
+ TCL_LIB_SPEC=${TCL_BUILD_LIB_SPEC}
+ TCL_STUB_LIB_SPEC=${TCL_BUILD_STUB_LIB_SPEC}
+ TCL_STUB_LIB_PATH=${TCL_BUILD_STUB_LIB_PATH}
diff --git a/meta/recipes-devtools/expect/expect/01-example-shebang.patch
b/meta/recipes-devtools/expect/expect/01-example-shebang.patch
new file mode 100644
index 000..8597f31
--- /dev/null
+++ b/meta/recipes-devtools/expect/expect/01-example-shebang.patch
@@ -0,0 +1,144 @@
+Author: Mike Markley
[OE-core] [PATCH 0/1] sysvinit: fix problem in switching runlevels
From: Chen Qi qi.c...@windriver.com This patch has been tested with the following steps. 1. Build an image with nfs-utils and rpcbind. 2. Add to /etc/fstab an nfs mount point with the following commands. mount -o loop tmp/deploy/images/qemux86/core-image-minimal-qemux86.ext3 root-disk-dir/ mkdir -p root-disk-dir/home/root/test if ! grep -q 'nfs' root-disk-dir/etc/fstab; then echo 192.168.7.1:/home/chenqi/test /home/root/test nfs defaults 0 0 root-disk-dir/etc/fstab fi umount root-disk-dir 3. runqemu qemux86 qemuparams=-serial stdio bootparams=console=ttyS0 4. init 1 (Network interface down and no nfs mount point) 5. init 3 (Network interface up and nfs mount point available) 6. init 5 (Network interface up and nfs mount point available) The following changes since commit 4fdc3d77d4a875b7236536bf78849a4d1f6a7449: kbd: Fix stdarg related errors on uclibc (2013-11-08 17:31:36 +) are available in the git repository at: git://git.pokylinux.org/poky-contrib ChenQi/sysvinit-runlevels http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/sysvinit-runlevels Chen Qi (1): sysvinit: fix problem in switching runlevels .../init-ifupdown/init-ifupdown_1.0.bb |2 +- meta/recipes-core/initscripts/initscripts_1.0.bb |4 ++-- meta/recipes-extended/rpcbind/rpcbind_0.2.0.bb |2 +- 3 files changed, 4 insertions(+), 4 deletions(-) -- 1.7.9.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] sysvinit: fix problem in switching runlevels
From: Chen Qi qi.c...@windriver.com
Previously, if we switch to runlevel 1 and then switch back to runlevel
5, the network interface will be brought down and the NFS service will
not be restarted correctly.
The problem is that the networking and rpcbind services are brought down
in runlevel 1 but not brought up in runlevel 5.
This patch fixes the above problem. It's based on the assumption that
in sysvinit-based system, runlevel 1 does not have networking support.
This patch adjusts some init script parameters used by update-rc.d. It
makes sure that networking starts before rpcbind which in turn starts
before mountnfs.sh. When switching to runlevel 0, 1 and 6, the umountnfs.sh
is run first before stopping rpcbind service, and the network is brought
down afterwards.
[YOCTO #5513]
Signed-off-by: Chen Qi qi.c...@windriver.com
---
.../init-ifupdown/init-ifupdown_1.0.bb |2 +-
meta/recipes-core/initscripts/initscripts_1.0.bb |4 ++--
meta/recipes-extended/rpcbind/rpcbind_0.2.0.bb |2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-core/init-ifupdown/init-ifupdown_1.0.bb
b/meta/recipes-core/init-ifupdown/init-ifupdown_1.0.bb
index 9d3af34..0f4290c 100644
--- a/meta/recipes-core/init-ifupdown/init-ifupdown_1.0.bb
+++ b/meta/recipes-core/init-ifupdown/init-ifupdown_1.0.bb
@@ -9,7 +9,7 @@ PR = r3
inherit update-rc.d
INITSCRIPT_NAME = networking
-INITSCRIPT_PARAMS = start 40 S . stop 40 0 6 1 .
+INITSCRIPT_PARAMS = start 10 2 3 4 5 . stop 80 0 6 1 .
SRC_URI = file://copyright \
file://init \
diff --git a/meta/recipes-core/initscripts/initscripts_1.0.bb
b/meta/recipes-core/initscripts/initscripts_1.0.bb
index 2d58266..d46ba67 100644
--- a/meta/recipes-core/initscripts/initscripts_1.0.bb
+++ b/meta/recipes-core/initscripts/initscripts_1.0.bb
@@ -108,7 +108,7 @@ do_install () {
update-rc.d -r ${D} rmnologin.sh start 99 2 3 4 5 .
update-rc.d -r ${D} sendsigs start 20 0 6 .
update-rc.d -r ${D} urandom start 30 S 0 6 .
- update-rc.d -r ${D} umountnfs.sh start 31 0 6 .
+ update-rc.d -r ${D} umountnfs.sh start 31 0 1 6 .
update-rc.d -r ${D} umountfs start 40 0 6 .
update-rc.d -r ${D} reboot start 90 6 .
update-rc.d -r ${D} halt start 90 0 .
@@ -117,7 +117,7 @@ do_install () {
update-rc.d -r ${D} checkroot.sh start 06 S .
update-rc.d -r ${D} mountall.sh start 03 S .
update-rc.d -r ${D} hostname.sh start 39 S .
- update-rc.d -r ${D} mountnfs.sh start 45 S .
+ update-rc.d -r ${D} mountnfs.sh start 15 2 3 4 5 .
update-rc.d -r ${D} bootmisc.sh start 55 S .
update-rc.d -r ${D} sysfs.sh start 02 S .
update-rc.d -r ${D} populate-volatile.sh start 37 S .
diff --git a/meta/recipes-extended/rpcbind/rpcbind_0.2.0.bb
b/meta/recipes-extended/rpcbind/rpcbind_0.2.0.bb
index a75e4e1..16fb7b7 100644
--- a/meta/recipes-extended/rpcbind/rpcbind_0.2.0.bb
+++ b/meta/recipes-extended/rpcbind/rpcbind_0.2.0.bb
@@ -35,7 +35,7 @@ PACKAGECONFIG ??= tcp-wrappers
PACKAGECONFIG[tcp-wrappers] = --enable-libwrap,--disable-libwrap,tcp-wrappers
INITSCRIPT_NAME = rpcbind
-INITSCRIPT_PARAMS = start 43 S . start 32 0 6 . stop 81 1 .
+INITSCRIPT_PARAMS = start 12 2 3 4 5 . stop 60 0 1 6 .
SYSTEMD_SERVICE_${PN} = rpcbind.service
SYSTEMD_AUTO_ENABLE = disable
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] Fix grep pattern when mklibs collects executables in rootfs
From: Lei Liu lei.l...@windriver.com
File command in some version could print extra space between
LSB and executable - it causes mklibs can't find any executables
using grep LSB executable. Fix the grep pattern to catch
multiple spaces.
Signed-off-by: Lei Liu lei.l...@windriver.com
---
meta/classes/image-mklibs.bbclass |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/classes/image-mklibs.bbclass
b/meta/classes/image-mklibs.bbclass
index 66b0f52..e975f5d 100644
--- a/meta/classes/image-mklibs.bbclass
+++ b/meta/classes/image-mklibs.bbclass
@@ -9,7 +9,7 @@ mklibs_optimize_image_doit() {
du -bs ${WORKDIR}/mklibs/du.before.mklibs.txt
for i in `find .`; do file $i; done \
| grep ELF \
- | grep LSB executable \
+ | grep LSB *executable \
| grep dynamically linked \
| sed s/:.*// \
| sed s+^\./++ \
--
1.7.0.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] kernel: Use hardlinks for do_populate_sysroot for speed
On Mon, 2013-11-11 at 09:06 +0100, Hans Beckérus wrote: I am having some trouble with these patches :( The new approach is using the '-n' flag to the 'cp' command. That is not supported on our SuSE11 based system. To be honest, I do not know how portable '-n' is? Some system have it, others seems to provide '-u' instead. I guess by removing '-n' part of the performance gain is lost? Would it be possible to test for error from the 'cp' command and if it fails try '-u' instead (and cache the result)? Or maybe even better, make this configurable in local.conf (or the distro) for the build platforms that does not support '-n' but can instead fall-back to using '-u'. From what I can tell most systems support one or the other, but never both. Hmm, its been in coreutils since 2009 which I guess isn't that long in the scheme of things: http://git.savannah.gnu.org/cgit/coreutils.git/commit/src/cp.c?id=d01338eb3d30e5634f1b4d4179c229f54eea0b44 Just to double check, is cp on your system provided by coreutils or something else? Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] kernel: Use hardlinks for do_populate_sysroot for speed
On Mon, 2013-11-11 at 09:06 +0100, Hans Beckérus wrote: I am having some trouble with these patches :( The new approach is using the '-n' flag to the 'cp' command. That is not supported on our SuSE11 based system. To be honest, I do not know how portable '-n' is? Some system have it, others seems to provide '-u' instead. I guess by removing '-n' part of the performance gain is lost? Would it be possible to test for error from the 'cp' command and if it fails try '-u' instead (and cache the result)? Or maybe even better, make this configurable in local.conf (or the distro) for the build platforms that does not support '-n' but can instead fall-back to using '-u'. From what I can tell most systems support one or the other, but never both. http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t2id=276b9df3588ecd438c3e2f502d56cd6b9fb24676 Thankfully the above works just as well. I used -n to get rid of an error, then added -l for efficiency. We can get away just with -l. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] kernel: Use hardlinks for do_populate_sysroot for speed
On Mon, Nov 11, 2013 at 10:45 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Mon, 2013-11-11 at 09:06 +0100, Hans Beckérus wrote: I am having some trouble with these patches :( The new approach is using the '-n' flag to the 'cp' command. That is not supported on our SuSE11 based system. To be honest, I do not know how portable '-n' is? Some system have it, others seems to provide '-u' instead. I guess by removing '-n' part of the performance gain is lost? Would it be possible to test for error from the 'cp' command and if it fails try '-u' instead (and cache the result)? Or maybe even better, make this configurable in local.conf (or the distro) for the build platforms that does not support '-n' but can instead fall-back to using '-u'. From what I can tell most systems support one or the other, but never both. http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t2id=276b9df3588ecd438c3e2f502d56cd6b9fb24676 Thankfully the above works just as well. I used -n to get rid of an error, then added -l for efficiency. We can get away just with -l. Great! Will try it asap. Btw, cp was from coreutils back in 2008. cp (GNU coreutils) 6.12 Copyright (C) 2008 Free Software Foundation, Inc. Thanks. Hans Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] bluez: declaration of virtual/bluez and VIRTUAL-RUNTIME_bluez
Hi all,
As far as I have experimented, there is no upgrade path available at the
moment, due to extensive changes into the programming model for BlueZ5 vs
BlueZ4.
At the moment, the last single component that is not officially ready for
BlueZ5 is PulseAudio.
As have asked around, and PA5.0 will* support BlueZ5.
PA5.0 should* be released before EoY2013.
Judging by PA git log, there are extensive changes/updates in order to support
BZ5.
Regards,
Cristian
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Martin
Jansa
Sent: Friday, November 1, 2013 11:35 AM
To: rongqing...@windriver.com
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH v2] bluez: declaration of virtual/bluez and
VIRTUAL-RUNTIME_bluez
On Fri, Nov 01, 2013 at 04:09:28PM +0800, rongqing...@windriver.com wrote:
From: Roy Li rongqing...@windriver.com
We have two version bluez, declare virtual/bluez and
VIRTUAL-RUNTIME_bluez to switch them easily, and set the preferred
provider for bluez as bluez4
+1
I agree that some apps aren't compatible with both versions now, but this gives
easy way to switch between them for DISTRO which cares only about apps which
are compatible with bluez5 already.
BTW: Have someone tried upgrade path on target from bluez4 to bluez5?
I know we discussed it at lengths before bluez5 was merged, but don't know if
someone really tested it.
Signed-off-by: Roy Li rongqing...@windriver.com
---
meta/conf/distro/include/default-providers.inc|5
++---
meta/recipes-connectivity/bluez/bluez4.inc|1 +
meta/recipes-connectivity/bluez5/bluez5.inc |1 +
meta/recipes-connectivity/connman/connman.inc |4 ++--
meta/recipes-connectivity/libpcap/libpcap.inc |2 +-
meta/recipes-connectivity/neard/neard.inc |2 +-
meta/recipes-connectivity/ofono/ofono.inc |2 +-
meta/recipes-core/packagegroups/packagegroup-base.bb |2 +-
meta/recipes-gnome/packagegroups/packagegroup-sdk-gmae.inc|2 +-
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_git.bb |2 +-
meta/recipes-multimedia/pulseaudio/pulseaudio.inc |2 +-
meta/recipes-qt/qt4/qt-mobility_1.2.0.inc |2 +-
12 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/meta/conf/distro/include/default-providers.inc
b/meta/conf/distro/include/default-providers.inc
index d4b9db0..0ec4cd9 100644
--- a/meta/conf/distro/include/default-providers.inc
+++ b/meta/conf/distro/include/default-providers.inc
@@ -14,6 +14,7 @@ PREFERRED_PROVIDER_virtual/update-alternatives ?= opkg
PREFERRED_PROVIDER_virtual/update-alternatives-native ?= opkg-native
PREFERRED_PROVIDER_virtual/libx11 ?= libx11
PREFERRED_PROVIDER_xf86-video-intel ?= xf86-video-intel
+PREFERRED_PROVIDER_virtual/bluez ?= bluez4
#
# Default virtual runtime providers
@@ -21,6 +22,7 @@ PREFERRED_PROVIDER_xf86-video-intel ?= xf86-video-intel
VIRTUAL-RUNTIME_update-alternatives ?= update-alternatives-cworth
VIRTUAL-RUNTIME_apm ?= apm
VIRTUAL-RUNTIME_alsa-state ?= alsa-state
+VIRTUAL-RUNTIME_bluez ?= bluez4
#
# Default recipe providers
@@ -40,6 +42,3 @@ PREFERRED_PROVIDER_console-tools ?= kbd
PREFERRED_PROVIDER_gzip-native ?= pigz-native
PREFERRED_PROVIDER_make ?= make
PREFERRED_PROVIDER_udev ?=
${@base_contains('DISTRO_FEATURES','systemd','systemd','udev',d)}
-# There are issues with runtime packages and PREFERRED_PROVIDER, see
YOCTO #5044 for details -# on this rather strange entry.
-PREFERRED_PROVIDER_bluez4 ?= bluez4
diff --git a/meta/recipes-connectivity/bluez/bluez4.inc
b/meta/recipes-connectivity/bluez/bluez4.inc
index e4f6834..c0babc6 100644
--- a/meta/recipes-connectivity/bluez/bluez4.inc
+++ b/meta/recipes-connectivity/bluez/bluez4.inc
@@ -9,6 +9,7 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e \
file://sbc/sbc.c;beginline=1;endline=25;md5=1a40781ed30d50d8639323a184aeb191
DEPENDS = udev libusb dbus-glib glib-2.0 libcheck readline
RDEPENDS_${PN}-dev = bluez-hcidump
+PROVIDES += virtual/bluez
PACKAGECONFIG ??= \
${@base_contains('DISTRO_FEATURES', 'alsa', 'alsa', '', d)}\ diff
--git a/meta/recipes-connectivity/bluez5/bluez5.inc
b/meta/recipes-connectivity/bluez5/bluez5.inc
index 2e25d86..b3ab131 100644
--- a/meta/recipes-connectivity/bluez5/bluez5.inc
+++ b/meta/recipes-connectivity/bluez5/bluez5.inc
@@ -7,6 +7,7 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e \
file://COPYING.LIB;md5=fb504b67c50331fc78734fed90fb0e09 \
file://src/main.c;beginline=1;endline=24;md5=9bc54b93cd7e17bf03f52513f39f926e
DEPENDS =
[OE-core] [PATCH 1/1] udev: remove libudev-dbg and libgudev-dbg
From: Wenzong Fan wenzong@windriver.com
We don't support multiple -dbg packages, all debug stuffs will be
shipped to 'udev-dbg'.
Signed-off-by: Wenzong Fan wenzong@windriver.com
---
meta/recipes-core/udev/udev.inc |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-core/udev/udev.inc b/meta/recipes-core/udev/udev.inc
index 02cab3b..ec638ea 100644
--- a/meta/recipes-core/udev/udev.inc
+++ b/meta/recipes-core/udev/udev.inc
@@ -45,8 +45,8 @@ EXTRA_OECONF = --disable-introspection \
PACKAGES =+ udev-utils udev-cache
-PACKAGES =+ libudev libudev-dev libudev-dbg
-PACKAGES =+ libgudev libgudev-dev libgudev-dbg
+PACKAGES =+ libudev libudev-dev
+PACKAGES =+ libgudev libgudev-dev
INITSCRIPT_PACKAGES = udev udev-cache
INITSCRIPT_NAME_udev = udev
@@ -63,11 +63,9 @@ FILES_${PN}-dbg += ${base_libdir}/udev/.debug/*
FILES_${PN}-dbg += ${nonarch_base_libdir}/udev/.debug/*
FILES_${PN}-dev = ${datadir}/pkgconfig/udev.pc
FILES_libudev = ${base_libdir}/libudev.so.*
-FILES_libudev-dbg = ${base_libdir}/.debug/libudev.so.*
FILES_libudev-dev = ${includedir}/libudev.h ${libdir}/libudev.so
${libdir}/libudev.la \
${libdir}/libudev.a ${libdir}/pkgconfig/libudev.pc
FILES_libgudev = ${base_libdir}/libgudev*.so.* ${libdir}/libgudev*.so.*
-FILES_libgudev-dbg = ${base_libdir}/.debug/libgudev*.so.*
${libdir}/.debug/libgudev*.so.*
FILES_libgudev-dev = ${includedir}/gudev* ${libdir}/libgudev*.so
${libdir}/libgudev*.la \
${libdir}/libgudev*.a ${libdir}/pkgconfig/gudev*.pc
FILES_udev-cache = ${sysconfdir}/init.d/udev-cache
${sysconfdir}/default/udev-cache
--
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] udev: remove libudev-dbg and libgudev-dbg
From: Wenzong Fan wenzong@windriver.com We don't support multiple -dbg packages, so just remove the libudev-dbg, libgudev-dbg and put all debug stuffs to 'udev-dbg'. The following changes since commit 4fdc3d77d4a875b7236536bf78849a4d1f6a7449: kbd: Fix stdarg related errors on uclibc (2013-11-08 17:31:36 +) are available in the git repository at: git://git.pokylinux.org/poky-contrib wenzong/udev-remove-dbg http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=wenzong/udev-remove-dbg Wenzong Fan (1): udev: remove libudev-dbg and libgudev-dbg meta/recipes-core/udev/udev.inc |6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) -- 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 0/1] udev: ship source files to related dbg package
On 11/08/2013 04:18 PM, Richard Purdie wrote: On Fri, 2013-11-08 at 16:10 +0800, wenzong fan wrote: On 11/07/2013 07:12 PM, Burton, Ross wrote: On 7 November 2013 11:03, wenzong@windriver.com wrote: From: Wenzong Fan wenzong@windriver.com Just ship these sources to their own dbg packages instead of udev-dbg: libudev* - libudev-dbg gudev* - libgudev-dbg others - udev-dbg Why do this? Multiple -dbg packages could make sense in a recipe which builds a multi-gigabyte -dbg package (such as webkit) but what's the rationale for doing this in udev? Actually I don't know clear about why it needs three -dbg packages, looks they have been there since very early commits of udev. I suspect that udev/libudev/libgudev are independent each other, so they are shipped into different packages (base/-dev/-dbg). This patch only ships their source code to -dbg packages accordingly. We don't support multiple -dbg packages and this looks like an error. Ok, another patch for removing the extra -dbg packages has been sent with subject: udev: remove libudev-dbg and libgudev-dbg Thanks Wenzong Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] wanting to confirm understanding of FILESPATH in .bb and .inc files
currently poking around for examples of recipes' use of FILESPATH to
use in class, and i just want to make absolutely sure i understand its
usage since some recipes seem to use it in weird and/or unnecessary
ways. (using the current poky tarball 10.0.0 for this.)
first, i can see the default setting of FILESPATH in base.bbclass:
FILESPATH = ${@base_set_filespath([${FILE_DIRNAME}/${BP},
${FILE_DIRNAME}/${BPN}, ${FILE_DIRNAME}/files], d)}
which, for any recipe, creates a FILESPATH that starts with top-level
subdirectories of ${BP}, ${BPN} and files and, on top of that,
extends each one with further subdirectories as defined by the
variable FILESOVERRIDES. so, as a working example, i can use bb show
to display the value of FILESPATH for, say, the zlib recipe, which
shows me a path with 15 entries (exactly as i expected building for my
beagleboard xm):
FILESPATH=/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/zlib-1.2.8/arm
/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/zlib-1.2.8/armv7a
/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/zlib-1.2.8/beagleboard
/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/zlib-1.2.8/poky
/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/zlib-1.2.8/
/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/zlib/arm
/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/zlib/armv7a
/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/zlib/beagleboard
/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/zlib/poky
/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/zlib/
/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/files/arm
/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/files/armv7a
/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/files/beagleboard
/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/files/poky
/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/files/
so far, so good, and here's where i want the clarification.
as long as a recipe has file:// references that occur exclusively
in any of the directories listed above, there should be no reason to
*need* to override FILESPATH, correct? however, some recipe or include
files clearly do just that, and i want to make sure that what i'm
seeing in files like that is *optional*, and not required due to some
subtlety i'm unaware of.
consider first example:
systemtap_git.inc:FILESPATH = ${FILE_DIRNAME}/systemtap
it would seem that this setting is superfluous since that entry is
already in the default value of FILESPATH for that recipe, so i'm
guessing that the benefit of the above is to simply reduce the size of
FILESPATH for efficiency? i mean, technically, the above didn't need
to be set, did it?
another example is with -native recipes. consider:
qemu-helper-native_1.0.bb:FILESPATH = ${FILE_DIRNAME}/qemu-helper
again, that seems redundant since:
$ bb show -r qemu-helper-native BP BPN
Parsing recipes..done.
# BP=${BPN}-${PV}
BP=qemu-helper-1.0
# BPN=${@base_prune_suffix(d.getVar('PN', True), d.getVar('SPECIAL_PKGSUFFIX',
True).split(), d)}
BPN=qemu-helper
$
so that entry is already part of FILESPATH.
i can see that there are times when a recipe or include file does
need to override the default value of FILESPATH, i just want to
confirm that there are instances in the current oe-core code base that
it appears to be unnecessary. thoughts?
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] one more question about FILESPATH and eglibc, if i might
as one more data point in what looks like weird and sometimes
unnecessary settings of FILESPATH in recipe files, i give you this
from eglibc_2.18.bb:
FILESPATH = ${@base_set_filespath([ '${FILE_DIRNAME}/eglibc-${PV}',
'${FILE_DIRNAME}/eglibc', '${FILE_DIRNAME}/files', '${FILE_DIRNAME}'
], d)}
first, it would seem that the first three elements in that list
match *exactly* what you'd get from the default setting of FILESPATH
from base.bbclass, would it not?
FILESPATH = ${@base_set_filespath([${FILE_DIRNAME}/${BP},
${FILE_DIRNAME}/${BPN}, ${FILE_DIRNAME}/files], d)}
so it's not clear what the point of that explicit setting is.
in addition, what's with the addition of that fourth list entry:
${FILE_DIRNAME}? all that's going to do is extend FILESPATH with the
OVERRIDES-related directories *immediately* under the eglibc
directory, and i don't see what value that has. here's the final value
of FILESPATH for eglibc as displayed by bb show:
FILESPATH=/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/eglibc/eglibc-2.18/arm
/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/eglibc/eglibc-2.18/armv7a
/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/eglibc/eglibc-2.18/beagleboard
/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/eglibc/eglibc-2.18/poky
/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/eglibc/eglibc-2.18/
/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/eglibc/eglibc/arm
/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/eglibc/eglibc/armv7a
/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/eglibc/eglibc/beagleboard
/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/eglibc/eglibc/poky
/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/eglibc/eglibc/
/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/eglibc/files/arm
/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/eglibc/files/armv7a
/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/eglibc/files/beagleboard
/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/eglibc/files/poky
/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/eglibc/files/
/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/eglibc/arm
/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/eglibc/armv7a
/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/eglibc/beagleboard
/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/eglibc/poky
/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/eglibc/
and i don't see the point of those last five entries. is the use of
${FILE_DIRNAME} as a fourth argument to base_set_filespath()
deliberate? and what is it for? thanks for your patience.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/8] Fixes about unsafe-references QA warnings
On 9 November 2013 05:28, qi.c...@windriver.com wrote: This solution is based on the following two principles. 1. With /usr on a seperate partition, system should still boot without any error. 2. Without /usr, system should be able to boot into single user mode with error. Presumably this is with sysvinit. Have you tested systemd with these principles? Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/8] Fixes about unsafe-references QA warnings
On 11/11/2013 07:12 PM, Burton, Ross wrote: On 9 November 2013 05:28, qi.c...@windriver.com wrote: This solution is based on the following two principles. 1. With /usr on a seperate partition, system should still boot without any error. 2. Without /usr, system should be able to boot into single user mode with error. Presumably this is with sysvinit. Have you tested systemd with these principles? Ross Not yet ... I can do such testing in a day or two. I'll then file a bug and make patches if needed. Best Regards, Chen Qi ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/8] udev: fix dependency and location of udevadm
On 11/11/2013 06:53 PM, Phil Blundell wrote:
On Mon, 2013-11-11 at 10:18 +0800, ChenQi wrote:
On 11/10/2013 06:54 AM, Phil Blundell wrote:
On Sat, 2013-11-09 at 13:28 +0800, qi.c...@windriver.com wrote:
+ install -d ${D}${base_bindir}
+ mv ${D}${bindir}/udevadm ${D}${base_bindir}/udevadm
+ rmdir ${D}${bindir}
This will fail if ${bindir} and ${base_bindir} are the same.
p.
In udev recipe, they are not defined as the same one.
Those variables are part of the distro configuration. Individual
recipes don't, in general, set them.
And moving something from bindir to base_bindir doesn't seem uncommon in
OE, you can grep the project using the following command.
grep -Ri 'mv.*bindir.*base_bindir' meta/*
A better command to use would be:
grep -C 4 -Ri 'mv.*bindir.*base_bindir' meta/*
Thanks for pointing it out :)
Currently I'm not sure whether we support configuring ${bindir} to equal
to ${base_bindir}, but maybe we will support this such configuration in
the future.
So I'll send out V2 of this patch.
Thanks,
Chen Qi
which reveals that most of these mv commands are enclosed in a
conditional that checks whether the two directories are indeed different
before trying to move them.
It's true that a few of the things in recipes-extended do appear to be
broken. cpio, for example, was broken by
6dee3050a4a0c4f3cc9fec23a0bc02155d680863; gzip was broken by
e0626a0270fb0f4ff128e761c13d44162723434c; mktemp was broken by
4807d938023ce06f2924c8a0503c32d083be23b5. All of these three patches
seem to be well-intentioned attempts to improve the handling of
update-alternatives and I guess those recipes are obscure enough that
nobody has noticed before now that there is anything wrong with them.
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/8] initscripts: add setup-commands.sh
On Mon, 2013-11-11 at 10:52 +0800, ChenQi wrote:
On 11/10/2013 07:00 AM, Phil Blundell wrote:
1. initscript doesn't obviously rdepend on busybox so it's not obvious
that the latter will always be available;
Yes. Initscript doesn't rdepend on busybox. But note it also doesn't
rdepend on sed or awk or grep.
So I think it's reasonable to assume the presence of busybox.
I think one could argue that it's also a bug that it doesn't rdepend on
the three things you mentioned (and indeed on /bin/sh itself, for
non-rpm systems). However, the usage of grep and sed in particular, and
perhaps to a slightly lesser extent awk, is so deeply ingrained into so
much software that I think it's probably fair to say those utilities
will almost always be present.
By contrast, it is perfectly feasible to build a system which doesn't
use busybox (by using the full GNU implementations of everything that
busybox provides) and indeed I think there might even be a task package
in oe-core which does exactly that. So it seems entirely possible
that /bin/busybox might not be installed unless you have a dependency on
it.
2. it should probably be using ${base_bindir} and ${bindir} rather than
hardcoding absolute paths.
In init scripts, we usually hardcode things, because these scripts
are destined to run on target.
In recipes we try not to hardcode things because the recipe may need
to extend to native or nativesdk.
I'm not quite sure I follow the logic here. Even if the script is
intended to run on the target it still ought to be respecting the values
of ${bindir}, ${sysconfdir} and such like.
3. the whole idea of creating a shadow /usr/bin underneath what's
meant to be a mountpoint seems rather dubious to me.
Agree.
The problem here is that the init scripts under /etc/rcS.d/ need to
execute commands like awk, dirname, and readlink which are from /usr.
As it's not appropriate to move these commands into /bin, basically
there are only two options I can see here. One is to modify these
scripts to use only commands from /bin or /sbin; the other is to make
use of busybox, as busybox is located under /bin as it provides these
commands.
I chose to the latter one because I thought that solution would have
the less impact.
What do you think? Do we need to modify the init scripts? Or any other
solution?
I thought that last time this topic came up on the mailing list, the
eventual conclusion was that Wind River (being more-or-less the only
people who seemed to feel strongly that supporting / and /usr on
different partitions was important) were going to come up with some sort
of overall strategy for solving the whole problem rather than just
fixing up individual bits in a piecemeal fashion. I think that strategy
would need to include a policy for which utilities initscripts can
legitimately expect to be available before /usr is mounted, and if this
set is different from what we have today then it would need to include a
plan for sorting that out.
To answer the particular question at hand it seems that someone would
need to do some analysis of things like:
- how many scripts actually need those commands
- how hard would it be to change them to not need them
- what would be the impact of moving them into ${base_bindir} (for
example, would this cause a whole load of libraries to get dragged into
${base_libdir} as well?)
Offhand I don't know the answer to any of those things.
4. this seems like distro policy and not something that really belongs
in oe-core at all. For systems where ${bindir} and ${base_bindir} are
on the same filesystem (or even are the same directory) this script will
just make bootup slower without achieving anything useful.
If /usr and / are on the same file system, this script has no real
effect because /usr will always be there. So I think it will not take
much time at boot.
Just spawning a new copy of the shell and reading the script does take a
finite (and measureable) time. If you can determine statically at build
time that the script isn't going to do anything useful then I don't
think it's appropriate to install it.
If ${base_bindir} and ${bindir} are the same, that means that there's
no /usr. In this case, there should no /usr/xxx entries
in /etc/busybox.links, so this script should also function correctly
and it will not take much time at boot.
(I just configured ${bindir} and ${base_bindir} to be the same and
performed a build, it failed. I'm not sure whether it's valid to make
such configurations in OE.)
It is a valid configuration, and this is the way that most of the images
I build are configured. It probably is true that there are still some
number of recipes in oe-core that don't support this properly, but I
don't want to see that situation get any worse.
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
[OE-core] [PATCH 0/1] kernel-grub.bbclass: fix update bzImage failed while /boot area within root partition
The following changes since commit f3541226b8b1187e79dec0f6f9f3c58cedf9ac9b: bitbake: hob: do not display the Package list may be incomplete! dialog (2013-11-01 17:59:31 +) are available in the git repository at: git://git.pokylinux.org/poky-contrib hongxu/fix-bzimage http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=hongxu/fix-bzimage Hongxu Jia (1): kernel-grub.bbclass: support /boot area within root partition meta/classes/kernel-grub.bbclass | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) -- 1.8.1.2 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] kernel-grub.bbclass: support /boot area within root partition
Previously, it supported the situation that /boot area with separate boot
partition:
...
menuentry Update bzImage-3.10.10-WR6.0.0.0_standard-3.10 {
set root=(hd0,1)
linux /bzImage-3.10.10-WR6.0.0.0_standard root=/dev/sdb1 rw ip=dhcp
}
...
But didn't consider the situation that /boot within root partition:
...
menuentry Update bzImage-3.10.10-WR6.0.0.0_standard-3.10 {
set root=(hd0,1)
linux /boot/bzImage-3.10.10-WR6.0.0.0_standard root=/dev/sdb1 rw ip=dhcp
}
...
This fix supported them both.
[YOCTO #5514]
Signed-off-by: Hongxu Jia hongxu@windriver.com
---
meta/classes/kernel-grub.bbclass | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/meta/classes/kernel-grub.bbclass b/meta/classes/kernel-grub.bbclass
index 70564f0..85721ff 100644
--- a/meta/classes/kernel-grub.bbclass
+++ b/meta/classes/kernel-grub.bbclass
@@ -40,10 +40,11 @@ pkg_preinst_kernel-image_append () {
pkg_postinst_kernel-image_prepend () {
get_new_grub_cfg() {
grubcfg=$1
+ old_image=$2
title=Update ${KERNEL_IMAGETYPE}-${KERNEL_VERSION}-${PV}
if [ ${grubcfg##*/} = grub.cfg ]; then
rootfs=`grep *linux \+[^ ]\+ \+root= $grubcfg -m 1 |
\
-sed s# *linux \+[^ ]\+ \+root=#linux
/${KERNEL_IMAGETYPE}-${KERNEL_VERSION} root=#`
+sed
s#${old_image}#${old_image%/*}/${KERNEL_IMAGETYPE}-${KERNEL_VERSION}#`
echo menuentry \$title\ {
echo set root=(hd0,1)
@@ -51,7 +52,7 @@ pkg_postinst_kernel-image_prepend () {
echo }
elif [ ${grubcfg##*/} = menu.list ]; then
rootfs=`grep kernel \+[^ ]\+ \+root= $grubcfg -m 1 | \
-sed s#kernel \+[^ ]\+ \+root=#kernel
/${KERNEL_IMAGETYPE}-${KERNEL_VERSION} root=#`
+sed
s#${old_image}#${old_image%/*}/${KERNEL_IMAGETYPE}-${KERNEL_VERSION}#`
echo default 0
echo timeout 30
@@ -79,9 +80,9 @@ pkg_postinst_kernel-image_prepend () {
fi
# Don't update grubcfg at first install while old bzImage doesn't exist.
- if [ -f $D/boot/$old_image ]; then
+ if [ -f $D/boot/${old_image##*/} ]; then
grubcfgtmp=$grubcfg.tmp
- get_new_grub_cfg $grubcfg $grubcfgtmp
+ get_new_grub_cfg $grubcfg $old_image $grubcfgtmp
get_old_grub_cfg $grubcfg $grubcfgtmp
mv $grubcfgtmp $grubcfg
echo Caution! Update kernel may affect kernel-module!
--
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 2/8] initscripts: add setup-commands.sh
On 11 November 2013 02:52, ChenQi qi.c...@windriver.com wrote: The problem here is that the init scripts under /etc/rcS.d/ need to execute commands like awk, dirname, and readlink which are from /usr. Yes. So why do you really need to support split /usr, and why isn't an initramfs a suitable alternative? People seem to insist that split /usr is trivial but these patches are clearly showing it's not. Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] core-image-weston: add SSH and hwcodecs to the image
core-image-sato has these by default so add them here too. 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 187523c..30cc845 100644 --- a/meta/recipes-graphics/images/core-image-weston.bb +++ b/meta/recipes-graphics/images/core-image-weston.bb @@ -1,6 +1,6 @@ DESCRIPTION = A very basic Wayland image with a terminal -IMAGE_FEATURES += splash package-management +IMAGE_FEATURES += splash package-management ssh-server-dropbear hwcodecs LICENSE = MIT -- 1.7.10.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] weston-init: use /run instead of /var/run
/var/run is just a symlink to /run now, so use /run directly. Signed-off-by: Ross Burton ross.bur...@intel.com --- meta/recipes-graphics/wayland/weston-init/init |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-graphics/wayland/weston-init/init b/meta/recipes-graphics/wayland/weston-init/init index 284fd0a..8e662e0 100644 --- a/meta/recipes-graphics/wayland/weston-init/init +++ b/meta/recipes-graphics/wayland/weston-init/init @@ -29,7 +29,7 @@ case $1 in # This is all a nasty hack if test -z $XDG_RUNTIME_DIR; then -export XDG_RUNTIME_DIR=/var/run/user/root +export XDG_RUNTIME_DIR=/run/user/root mkdir --parents $XDG_RUNTIME_DIR chmod 0700 $XDG_RUNTIME_DIR fi -- 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/3] distrodata.bbclass: Add fetch2 handlers to svn case in checkpkg
---
meta/classes/distrodata.bbclass | 43 ---
1 file changed, 17 insertions(+), 26 deletions(-)
diff --git a/meta/classes/distrodata.bbclass b/meta/classes/distrodata.bbclass
index 085575a..e481027 100644
--- a/meta/classes/distrodata.bbclass
+++ b/meta/classes/distrodata.bbclass
@@ -751,34 +751,25 @@ python do_checkpkg() {
if not tmp3:
bb.plain(#DEBUG# Package %s: current
version (%s) doesn't match the usual pattern %(pname, pversion))
elif type == 'svn':
-options = []
-if user:
-options.append(--username %s % user)
-if pswd:
-options.append(--password %s % pswd)
-svnproto = 'svn'
-if 'proto' in parm:
-svnproto = parm['proto']
-if 'rev' in parm:
-pcurver = parm['rev']
-
-svncmd = svn info %s %s://%s%s/%s/ 21 % (
.join(options), svnproto, host, path, parm[module])
-print svncmd
-svninfo = os.popen(svncmd).read()
-if Can't connect to host in svninfo or Connection timed
out in svninfo:
-svncmd = svn info %s %s://%s%s/%s/ 21 % (
.join(options), http,
- host, path, parm[module])
-svninfo = os.popen(svncmd).read()
-for line in svninfo.split(\n):
-if re.search(^Last Changed Rev:, line):
-pupver = line.split( )[-1]
-if pupver in pversion:
-pstatus = MATCH
-else:
-pstatus = UPDATE
+ud = bb.fetch2.FetchData(uri, d)
-if re.match(Err, pstatus):
+svnFetcher = bb.fetch2.svn.Svn(d)
+svnFetcher.urldata_init(ud, d)
+try:
+pupver = svnFetcher.latest_revision(uri, ud, d,
ud.names[0])
+except bb.fetch2.FetchError:
+pstatus = ErrSvnAccess
+
+if pupver:
+if pupver in pversion:
+pstatus = MATCH
+else:
+pstatus = UPDATE
+else:
pstatus = ErrSvnAccess
+
+if 'rev' in ud.parm:
+pcurver = ud.parm['rev']
if pstatus != ErrSvnAccess:
tag = pversion.rsplit(+svn)[0]
--
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 2/8] initscripts: add setup-commands.sh
Hi Phil,
First of all, thank you for your careful review and explanation.
To conclude, you suggest modifying the init scripts and moving commands
around if needed, right?
And please see comments inline.
On 11/11/2013 07:53 PM, Phil Blundell wrote:
On Mon, 2013-11-11 at 10:52 +0800, ChenQi wrote:
On 11/10/2013 07:00 AM, Phil Blundell wrote:
1. initscript doesn't obviously rdepend on busybox so it's not obvious
that the latter will always be available;
Yes. Initscript doesn't rdepend on busybox. But note it also doesn't
rdepend on sed or awk or grep.
So I think it's reasonable to assume the presence of busybox.
I think one could argue that it's also a bug that it doesn't rdepend on
the three things you mentioned (and indeed on /bin/sh itself, for
non-rpm systems). However, the usage of grep and sed in particular, and
perhaps to a slightly lesser extent awk, is so deeply ingrained into so
much software that I think it's probably fair to say those utilities
will almost always be present.
By contrast, it is perfectly feasible to build a system which doesn't
use busybox (by using the full GNU implementations of everything that
busybox provides) and indeed I think there might even be a task package
in oe-core which does exactly that. So it seems entirely possible
that /bin/busybox might not be installed unless you have a dependency on
it.
Agree. I'm gonna drop this patch and try to come up with another solution :)
2. it should probably be using ${base_bindir} and ${bindir} rather than
hardcoding absolute paths.
In init scripts, we usually hardcode things, because these scripts
are destined to run on target.
In recipes we try not to hardcode things because the recipe may need
to extend to native or nativesdk.
I'm not quite sure I follow the logic here. Even if the script is
intended to run on the target it still ought to be respecting the values
of ${bindir}, ${sysconfdir} and such like.
3. the whole idea of creating a shadow /usr/bin underneath what's
meant to be a mountpoint seems rather dubious to me.
Agree.
The problem here is that the init scripts under /etc/rcS.d/ need to
execute commands like awk, dirname, and readlink which are from /usr.
As it's not appropriate to move these commands into /bin, basically
there are only two options I can see here. One is to modify these
scripts to use only commands from /bin or /sbin; the other is to make
use of busybox, as busybox is located under /bin as it provides these
commands.
I chose to the latter one because I thought that solution would have
the less impact.
What do you think? Do we need to modify the init scripts? Or any other
solution?
I thought that last time this topic came up on the mailing list, the
eventual conclusion was that Wind River (being more-or-less the only
people who seemed to feel strongly that supporting / and /usr on
different partitions was important) were going to come up with some sort
of overall strategy for solving the whole problem rather than just
fixing up individual bits in a piecemeal fashion. I think that strategy
would need to include a policy for which utilities initscripts can
legitimately expect to be available before /usr is mounted, and if this
set is different from what we have today then it would need to include a
plan for sorting that out.
Basically we don't have any problem if /usr is going to be mounted,
because the mountall.sh takes place really early.
What I want to achieve here is that we can boot into single user mode
for recovery or repair if /usr is not available (maybe just because the
drive's broken).
To answer the particular question at hand it seems that someone would
need to do some analysis of things like:
- how many scripts actually need those commands
- how hard would it be to change them to not need them
Only init scripts that have links under /etc/rcS.d/ need to be examined,
so that wouldn't be a lot of work.
I'm just not sure whether we should make such a restriction of which
commands could be used and which could not. After all, commands like
`readlink', `dirname' and `awk' are also very commonly used commands.
- what would be the impact of moving them into ${base_bindir} (for
example, would this cause a whole load of libraries to get dragged into
${base_libdir} as well?)
If I can easily modify the init scripts to make things work, I don't
want to move things around.
But I guess statements using awk are hard to be replaced unless I use a
block of codes
Offhand I don't know the answer to any of those things.
4. this seems like distro policy and not something that really belongs
in oe-core at all. For systems where ${bindir} and ${base_bindir} are
on the same filesystem (or even are the same directory) this script will
just make bootup slower without achieving anything useful.
If /usr and / are on the same file system, this script has no real
effect because /usr will always be there. So I think it will not take
much time at boot.
Just
[OE-core] [PATCH 0/4] Recipe upgrades
The following changes since commit eac8cb7cacab7f2fb392128aa5ebc2046ca4a793:
kbd: Fix stdarg related errors on uclibc (2013-11-08 17:31:17 +)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib paule/upgrades
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/upgrades
Paul Eggleton (4):
cmake: upgrade to 2.8.12.1
ethtool: upgrade to 3.12.1
nfs-utils: upgrade to 1.2.9
openssh: upgrade to 6.4p1
.../nfs-utils/{nfs-utils_1.2.8.bb = nfs-utils_1.2.9.bb} | 4 ++--
.../openssh/{openssh-6.3p1 = openssh-6.4p1}/init | 0
.../openssh/{openssh-6.3p1 = openssh-6.4p1}/nostrip.patch| 0
.../{openssh-6.3p1 = openssh-6.4p1}/openssh-CVE-2011-4327.patch | 0
.../openssh/{openssh-6.3p1 = openssh-6.4p1}/ssh_config | 0
.../openssh/{openssh-6.3p1 = openssh-6.4p1}/sshd | 0
.../openssh/{openssh-6.3p1 = openssh-6.4p1}/sshd.socket | 0
.../openssh/{openssh-6.3p1 = openssh-6.4p1}/sshd@.service| 0
.../openssh/{openssh-6.3p1 = openssh-6.4p1}/sshd_config | 0
.../openssh/{openssh-6.3p1 = openssh-6.4p1}/sshdgenkeys.service | 0
.../openssh/{openssh-6.3p1 = openssh-6.4p1}/volatiles.99_sshd| 0
.../openssh/{openssh_6.3p1.bb = openssh_6.4p1.bb}| 4 ++--
.../cmake/{cmake-native_2.8.12.bb = cmake-native_2.8.12.1.bb}| 4 ++--
meta/recipes-devtools/cmake/{cmake_2.8.12.bb = cmake_2.8.12.1.bb}| 4 ++--
.../ethtool/{ethtool-3.11 = ethtool-3.12.1}/run-ptest| 0
meta/recipes-extended/ethtool/{ethtool_3.11.bb = ethtool_3.12.1.bb} | 4 ++--
16 files changed, 10 insertions(+), 10 deletions(-)
rename meta/recipes-connectivity/nfs-utils/{nfs-utils_1.2.8.bb =
nfs-utils_1.2.9.bb} (95%)
rename meta/recipes-connectivity/openssh/{openssh-6.3p1 = openssh-6.4p1}/init
(100%)
rename meta/recipes-connectivity/openssh/{openssh-6.3p1 =
openssh-6.4p1}/nostrip.patch (100%)
rename meta/recipes-connectivity/openssh/{openssh-6.3p1 =
openssh-6.4p1}/openssh-CVE-2011-4327.patch (100%)
rename meta/recipes-connectivity/openssh/{openssh-6.3p1 =
openssh-6.4p1}/ssh_config (100%)
rename meta/recipes-connectivity/openssh/{openssh-6.3p1 = openssh-6.4p1}/sshd
(100%)
rename meta/recipes-connectivity/openssh/{openssh-6.3p1 =
openssh-6.4p1}/sshd.socket (100%)
rename meta/recipes-connectivity/openssh/{openssh-6.3p1 =
openssh-6.4p1}/sshd@.service (100%)
rename meta/recipes-connectivity/openssh/{openssh-6.3p1 =
openssh-6.4p1}/sshd_config (100%)
rename meta/recipes-connectivity/openssh/{openssh-6.3p1 =
openssh-6.4p1}/sshdgenkeys.service (100%)
rename meta/recipes-connectivity/openssh/{openssh-6.3p1 =
openssh-6.4p1}/volatiles.99_sshd (100%)
rename meta/recipes-connectivity/openssh/{openssh_6.3p1.bb =
openssh_6.4p1.bb} (97%)
rename meta/recipes-devtools/cmake/{cmake-native_2.8.12.bb =
cmake-native_2.8.12.1.bb} (58%)
rename meta/recipes-devtools/cmake/{cmake_2.8.12.bb = cmake_2.8.12.1.bb} (88%)
rename meta/recipes-extended/ethtool/{ethtool-3.11 =
ethtool-3.12.1}/run-ptest (100%)
rename meta/recipes-extended/ethtool/{ethtool_3.11.bb = ethtool_3.12.1.bb}
(87%)
--
1.8.1.2
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/4] ethtool: upgrade to 3.12.1
Signed-off-by: Paul Eggleton paul.eggle...@linux.intel.com
---
.../ethtool/{ethtool-3.11 = ethtool-3.12.1}/run-ptest| 0
meta/recipes-extended/ethtool/{ethtool_3.11.bb = ethtool_3.12.1.bb} | 4 ++--
2 files changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-extended/ethtool/{ethtool-3.11 =
ethtool-3.12.1}/run-ptest (100%)
rename meta/recipes-extended/ethtool/{ethtool_3.11.bb = ethtool_3.12.1.bb}
(87%)
diff --git a/meta/recipes-extended/ethtool/ethtool-3.11/run-ptest
b/meta/recipes-extended/ethtool/ethtool-3.12.1/run-ptest
similarity index 100%
rename from meta/recipes-extended/ethtool/ethtool-3.11/run-ptest
rename to meta/recipes-extended/ethtool/ethtool-3.12.1/run-ptest
diff --git a/meta/recipes-extended/ethtool/ethtool_3.11.bb
b/meta/recipes-extended/ethtool/ethtool_3.12.1.bb
similarity index 87%
rename from meta/recipes-extended/ethtool/ethtool_3.11.bb
rename to meta/recipes-extended/ethtool/ethtool_3.12.1.bb
index 1e89800..19bca2f 100644
--- a/meta/recipes-extended/ethtool/ethtool_3.11.bb
+++ b/meta/recipes-extended/ethtool/ethtool_3.12.1.bb
@@ -9,8 +9,8 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
SRC_URI = ${KERNELORG_MIRROR}/software/network/ethtool/ethtool-${PV}.tar.gz \
file://run-ptest
-SRC_URI[md5sum] = b3fba5cc45377b8fc2ead9f1e05c11bd
-SRC_URI[sha256sum] =
a054fd5a318a0a01113952908d2344eb452f4dfd2525fe8b525f7ff2236db38a
+SRC_URI[md5sum] = 5a1058efe8eb4f3473f5028967729078
+SRC_URI[sha256sum] =
45190d70e5ce1b4d87def4f71fb5bf04f8a4f4dc5f9e0f38c49c16c462fb59d9
inherit autotools ptest
RDEPENDS_${PN}-ptest += make
--
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 2/8] initscripts: add setup-commands.sh
On Mon, 2013-11-11 at 20:40 +0800, ChenQi wrote:
Hi Phil,
First of all, thank you for your careful review and explanation.
To conclude, you suggest modifying the init scripts and moving commands
around if needed, right?
Well, I'm not sure that I'm necessarily suggesting any particular
change. What I'm saying is that if we're going to try to solve the
split-/usr problem in oe-core (as opposed to Wind River just doing it in
their internal distro layers) then:
1. It needs to be done in a way that doesn't have any negative impact
for people who don't have a split /usr (or indeed who don't have /usr at
all)
2. The changes need to be presented as a coherent package with the
reasoning clearly explained.
3. We need to be clear that it's solving the whole problem (whatever
that might be) rather than just some part of it.
Could you please share your configuration so that when I make V2 I can
test the case of ${bindir} and ${base_bindir} being the same.
(Currently I really can't build out an image with such configuration ... )
I think it should basically just be a case of setting:
prefix =
exec_prefix =
prefix_native =
in your distro configuration.
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] wanting to confirm understanding of FILESPATH in .bb and .inc files
Hi Robert,
On Monday 11 November 2013 05:34:20 Robert P. J. Day wrote:
currently poking around for examples of recipes' use of FILESPATH to
use in class, and i just want to make absolutely sure i understand its
usage since some recipes seem to use it in weird and/or unnecessary
ways. (using the current poky tarball 10.0.0 for this.)
first, i can see the default setting of FILESPATH in base.bbclass:
FILESPATH = ${@base_set_filespath([${FILE_DIRNAME}/${BP},
${FILE_DIRNAME}/${BPN}, ${FILE_DIRNAME}/files], d)}
which, for any recipe, creates a FILESPATH that starts with top-level
subdirectories of ${BP}, ${BPN} and files and, on top of that,
extends each one with further subdirectories as defined by the
variable FILESOVERRIDES. so, as a working example, i can use bb show
to display the value of FILESPATH for, say, the zlib recipe, which
shows me a path with 15 entries (exactly as i expected building for my
beagleboard xm):
FILESPATH=/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/zlib
-1.2.8/arm
/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/zlib-1.2.8/arm
v7a
/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/zlib-1.2.8/bea
gleboard
/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/zlib-1.2.8/pok
y /home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/zlib-1.2.8/
/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/zlib/arm
/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/zlib/armv7a
/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/zlib/beagleboa
rd /home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/zlib/poky
/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/zlib/
/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/files/arm
/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/files/armv7a
/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/files/beaglebo
ard /home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/files/poky
/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/files/
so far, so good, and here's where i want the clarification.
as long as a recipe has file:// references that occur exclusively
in any of the directories listed above, there should be no reason to
*need* to override FILESPATH, correct? however, some recipe or include
files clearly do just that, and i want to make sure that what i'm
seeing in files like that is *optional*, and not required due to some
subtlety i'm unaware of.
consider first example:
systemtap_git.inc:FILESPATH = ${FILE_DIRNAME}/systemtap
it would seem that this setting is superfluous since that entry is
already in the default value of FILESPATH for that recipe, so i'm
guessing that the benefit of the above is to simply reduce the size of
FILESPATH for efficiency? i mean, technically, the above didn't need
to be set, did it?
I think the reason that is there is because systemtap_git.inc is used in
another recipe which would not have that path included automatically, i.e.
systemtap-uprobes_git.bb. It could be argued that systemtap-uprobes_git.bb
should be extending the path instead, that would also work.
another example is with -native recipes. consider:
qemu-helper-native_1.0.bb:FILESPATH = ${FILE_DIRNAME}/qemu-helper
again, that seems redundant since:
$ bb show -r qemu-helper-native BP BPN
Parsing recipes..done.
# BP=${BPN}-${PV}
BP=qemu-helper-1.0
# BPN=${@base_prune_suffix(d.getVar('PN', True),
d.getVar('SPECIAL_PKGSUFFIX', True).split(), d)} BPN=qemu-helper
$
so that entry is already part of FILESPATH.
Right, that would appear to be redundant.
FWIW, I did open a bug about the general case here:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=4497
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] question about FILE_DIRNAME versus THISDIR when setting FILESPATH
Hi Robert,
On Sunday 10 November 2013 13:02:32 Robert P. J. Day wrote:
probably a simple answer to this, but in examining the way FILESPATH
is created, i notice that, in .bb recipe files, the general form of
setting FILESPATH always seems to involve the use of the FILE_DIRNAME
variable, such as in the default value from base.bbclass:
FILESPATH = ${@base_set_filespath([${FILE_DIRNAME}/${BP},
${FILE_DIRNAME}/${BPN}, ${FILE_DIRNAME}/files], d)}
however, when one is extending FILESPATH in .bbappend files, the
variable used to refer to the current directory is always THISDIR. but
it's not clear what the distinction is.
i'm using bb show and, when i'm referring to the value of
FILESPATH for an overlayed recipe, both FILE_DIRNAME and THISDIR seem
to properly refer to the directory for the bbappend file.
can someone clarify the proper usage of these variables? in
particular, why it's important for .bb files to use FILE_DIRNAME but
.bbappend files to use THISDIR? thanks.
These variables are set in pretty much the same way; the only difference is
that FILE_DIRNAME doesn't expand FILE before running it through
os.path.dirname(); I'm not sure if that is deliberate or not. In practice I
doubt it makes any difference since FILE is set to a full path by BitBake,
although as you note a convention has been established of using THISDIR in
bbappends and FILE_DIRNAME elsewhere.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/8] initscripts: add setup-commands.sh
On 11/11/13, 5:53 AM, Phil Blundell wrote:
On Mon, 2013-11-11 at 10:52 +0800, ChenQi wrote:
On 11/10/2013 07:00 AM, Phil Blundell wrote:
...
I thought that last time this topic came up on the mailing list, the
eventual conclusion was that Wind River (being more-or-less the only
people who seemed to feel strongly that supporting / and /usr on
different partitions was important) were going to come up with some sort
of overall strategy for solving the whole problem rather than just
fixing up individual bits in a piecemeal fashion. I think that strategy
would need to include a policy for which utilities initscripts can
legitimately expect to be available before /usr is mounted, and if this
set is different from what we have today then it would need to include a
plan for sorting that out.
There is a bug open for the Yocto Project 1.6 to explicitly do this. Come up
with an overall strategy for these kinds of things, as well as a test plan to
verify that whatever we end up doing works properly long term.
As you said, busybox is not required on a system -- just something that has a
reasonable set of software packages. Also a lot of this stuff is simply limited
to 'early boot'. At some point we do need to define 'early boot'. (Generally I
define it as until /usr would normally be mounted.)
And unfortunately you will see patches in piecemeal at this point. Until such a
strategy is generated, everything is being done reactively. We see a QA
error/warning and someone is assigned to solve it. Yocto Project Compliance
(and our own internal) guidelines then indicate since we've patched something it
has to go out to the community.
To answer the particular question at hand it seems that someone would
need to do some analysis of things like:
- how many scripts actually need those commands
- how hard would it be to change them to not need them
- what would be the impact of moving them into ${base_bindir} (for
example, would this cause a whole load of libraries to get dragged into
${base_libdir} as well?)
That was my thought exactly. Lets look at moving things -or- stop using them.
Whichever is more reasonable.
Offhand I don't know the answer to any of those things.
4. this seems like distro policy and not something that really belongs
in oe-core at all. For systems where ${bindir} and ${base_bindir} are
on the same filesystem (or even are the same directory) this script will
just make bootup slower without achieving anything useful.
If /usr and / are on the same file system, this script has no real
effect because /usr will always be there. So I think it will not take
much time at boot.
Just spawning a new copy of the shell and reading the script does take a
finite (and measureable) time. If you can determine statically at build
time that the script isn't going to do anything useful then I don't
think it's appropriate to install it.
If ${base_bindir} and ${bindir} are the same, that means that there's
no /usr. In this case, there should no /usr/xxx entries
in /etc/busybox.links, so this script should also function correctly
and it will not take much time at boot.
(I just configured ${bindir} and ${base_bindir} to be the same and
performed a build, it failed. I'm not sure whether it's valid to make
such configurations in OE.)
It is a valid configuration, and this is the way that most of the images
I build are configured. It probably is true that there are still some
number of recipes in oe-core that don't support this properly, but I
don't want to see that situation get any worse.
And yes, all scripts need to (at build time) bind to the bindir and base_bindir
of that distribution. Hardcoding those values into the scripts before build
time is wrong.
--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
Re: [OE-core] [PATCH 2/8] initscripts: add setup-commands.sh
On 11/11/13, 6:12 AM, Burton, Ross wrote: On 11 November 2013 02:52, ChenQi qi.c...@windriver.com wrote: The problem here is that the init scripts under /etc/rcS.d/ need to execute commands like awk, dirname, and readlink which are from /usr. Yes. So why do you really need to support split /usr, and why isn't an initramfs a suitable alternative? People seem to insist that split /usr is trivial but these patches are clearly showing it's not. Just to be clear, I've never said it was trivial -- but what I have said is that it -should- be trivial if people pay attention to this stuff early. The only thing that has to be done for the split is 'early boot'. (See my email response to Phil..) As for why, we still have people developing systems with small per-device memory that need to do the early boot from a small system, then mount the /usr partition from a shared location. (/usr is often times still mounted RO.. and is shared between multiple CPUs within a single device or chasis.) The usage of this is getting less and less, but we do still get issues from customers when things don't work right, so we know people are still doing it. --Mark Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] clutter-gtk-1.0: upgrade to 1.4.4
Signed-off-by: Ross Burton ross.bur...@intel.com --- meta/recipes-graphics/clutter/clutter-gtk-1.0_1.4.2.bb |6 -- meta/recipes-graphics/clutter/clutter-gtk-1.0_1.4.4.bb |6 ++ 2 files changed, 6 insertions(+), 6 deletions(-) delete mode 100644 meta/recipes-graphics/clutter/clutter-gtk-1.0_1.4.2.bb create mode 100644 meta/recipes-graphics/clutter/clutter-gtk-1.0_1.4.4.bb diff --git a/meta/recipes-graphics/clutter/clutter-gtk-1.0_1.4.2.bb b/meta/recipes-graphics/clutter/clutter-gtk-1.0_1.4.2.bb deleted file mode 100644 index 64eb70c..000 --- a/meta/recipes-graphics/clutter/clutter-gtk-1.0_1.4.2.bb +++ /dev/null @@ -1,6 +0,0 @@ -require clutter-gtk-1.0.inc - -LIC_FILES_CHKSUM = file://COPYING;md5=7fbc338309ac38fefcd64b04bb903e34 - -SRC_URI[archive.md5sum] = 842601b584daf4447a46799a4ba88df6 -SRC_URI[archive.sha256sum] = dc3ec6e90bc742c8a68ed7fa4c0d25b9b376828f1a7f013c363fbaf14f3a6974 diff --git a/meta/recipes-graphics/clutter/clutter-gtk-1.0_1.4.4.bb b/meta/recipes-graphics/clutter/clutter-gtk-1.0_1.4.4.bb new file mode 100644 index 000..37a035c --- /dev/null +++ b/meta/recipes-graphics/clutter/clutter-gtk-1.0_1.4.4.bb @@ -0,0 +1,6 @@ +require clutter-gtk-1.0.inc + +LIC_FILES_CHKSUM = file://COPYING;md5=7fbc338309ac38fefcd64b04bb903e34 + +SRC_URI[archive.md5sum] = ef50b52ffc2a18704eb62f13dd8d6198 +SRC_URI[archive.sha256sum] = bc3108594a01a08bb6d9b538afe995e4fd78634a8356064ee8137d87aad51b2e -- 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/2] freetype: upgrade to 2.5.0.1
Add disabled-by-default PACKAGECONFIG for pixmap glyphs (floating dependency on
libpng).
Signed-off-by: Ross Burton ross.bur...@intel.com
---
.../freetype/{freetype_2.4.12.bb = freetype_2.5.0.1.bb} |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
rename meta/recipes-graphics/freetype/{freetype_2.4.12.bb =
freetype_2.5.0.1.bb} (86%)
diff --git a/meta/recipes-graphics/freetype/freetype_2.4.12.bb
b/meta/recipes-graphics/freetype/freetype_2.5.0.1.bb
similarity index 86%
rename from meta/recipes-graphics/freetype/freetype_2.4.12.bb
rename to meta/recipes-graphics/freetype/freetype_2.5.0.1.bb
index 701c629..0b69af9 100644
--- a/meta/recipes-graphics/freetype/freetype_2.4.12.bb
+++ b/meta/recipes-graphics/freetype/freetype_2.5.0.1.bb
@@ -13,12 +13,11 @@ LIC_FILES_CHKSUM =
file://docs/LICENSE.TXT;md5=c017ff17fc6f0794adf93db5559ccd56
SECTION = libs
-
SRC_URI = ${SOURCEFORGE_MIRROR}/freetype/freetype-${PV}.tar.bz2 \
-SRC_URI[md5sum] = 3463102764315eb86c0d3c2e1f3ffb7d
-SRC_URI[sha256sum] =
a78a17486689ab6852a9e1a759b179827ac9dfd7e2f237ddf169c73398c85381
+SRC_URI[md5sum] = c72e9010b1d986d556fc0b2b5fcbf31a
+SRC_URI[sha256sum] =
57bce5b37989577aa8b4a588426839f6bf39bcc3869748cb18f6827df251f4e5
S = ${WORKDIR}/freetype-${PV}
@@ -29,6 +28,9 @@ EXTRA_OEMAKE = 'LIBTOOL=${LIBTOOL}'
EXTRA_OEMAKE_class-native =
EXTRA_OECONF = --without-zlib --without-bzip2 CC_BUILD='${BUILD_CC}'
+PACKAGECONFIG ??=
+PACKAGECONFIG[pixmap] = --with-png,--without-png,libpng
+
do_configure() {
cd builds/unix
libtoolize --force --copy
--
1.7.10.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCHv4] libjson: update to 0.11 and rename to json-c
On 08/11/2013 00:47, Saul Wold wrote:
On 11/07/2013 07:59 AM, Jack Mitchell wrote:
From: Jack Mitchell jmitch...@cbnl.com
libjson is now known as json-c, support for the old namespace is
disabled as it seems to break SEPBUILDDIR configs. Built without
parallel make as it fails, official word is not to bother trying.
Signed-off-by: Jack Mitchell jmitch...@cbnl.com
---
v4:
- add --disable-oldname-compat to try and fix suspected SEPBUILDDIR
issues
Jack,
I hate to ask this, but given this version is also failing, how have you
been testing this recipe?
Just the usual way, standard x86 atom target -c cleansstate and a build
+ build -c populate_sdk. It also gets rebuilt without a clean sstate as
I've been holding this patch in my working tree for weeks now.
I don't really know where to go with this now, I was sure it was going
to be the compat configure functons which were breaking things, but
obviously not. I'll see if I can find some time to tidy up the actual
configure script some, and see if that irons out the issues we're
seeing. I'll also give it a go with SEPBUILDDIR and see if I can get it
failing over here too.
Cheers!
I attached my do_configure log file.
Thanks
Sau!
meta/conf/distro/include/seperatebuilddir.inc | 2 +-
meta/recipes-devtools/json-c/json-c_0.11.bb | 16
meta/recipes-devtools/libjson/libjson_0.9.bb | 14 --
meta/recipes-multimedia/pulseaudio/pulseaudio.inc | 2 +-
4 files changed, 18 insertions(+), 16 deletions(-)
create mode 100644 meta/recipes-devtools/json-c/json-c_0.11.bb
delete mode 100644 meta/recipes-devtools/libjson/libjson_0.9.bb
diff --git a/meta/conf/distro/include/seperatebuilddir.inc
b/meta/conf/distro/include/seperatebuilddir.inc
index c067183..e1a5c6b 100644
--- a/meta/conf/distro/include/seperatebuilddir.inc
+++ b/meta/conf/distro/include/seperatebuilddir.inc
@@ -294,7 +294,7 @@ B_pn-libice = ${SEPB}
B_pn-libice-native = ${SEPB}
B_pn-libid3tag = ${SEPB}
B_pn-libidn = ${SEPB}
-B_pn-libjson = ${SEPB}
+B_pn-json-c = ${SEPB}
B_pn-libksba = ${SEPB}
B_pn-libmad = ${SEPB}
B_pn-libmatchbox = ${SEPB}
diff --git a/meta/recipes-devtools/json-c/json-c_0.11.bb
b/meta/recipes-devtools/json-c/json-c_0.11.bb
new file mode 100644
index 000..59a4b4d
--- /dev/null
+++ b/meta/recipes-devtools/json-c/json-c_0.11.bb
@@ -0,0 +1,16 @@
+SUMMARY = JSON-C implements a reference counting object model that
allows you to easily construct JSON objects in C
+HOMEPAGE = https://github.com/json-c/json-c/wiki;
+LICENSE = MIT
+LIC_FILES_CHKSUM = file://COPYING;md5=de54b60fbbc35123ba193fea8ee216f2
+
+SRC_URI =
https://s3.amazonaws.com/json-c_releases/releases/${BP}.tar.gz;
+
+SRC_URI[md5sum] = aa02367d2f7a830bf1e3376f77881e98
+SRC_URI[sha256sum] =
28dfc65145dc0d4df1dfe7701ac173c4e5f9347176c8983edbfac9149494448c
+
+RPROVIDES_${PN} = libjson
+
+PARALLEL_MAKE =
+EXTRA_OECONF = --disable-oldname-compat
+
+inherit autotools
diff --git a/meta/recipes-devtools/libjson/libjson_0.9.bb
b/meta/recipes-devtools/libjson/libjson_0.9.bb
deleted file mode 100644
index e4951a8..000
--- a/meta/recipes-devtools/libjson/libjson_0.9.bb
+++ /dev/null
@@ -1,14 +0,0 @@
-DESCRIPTION = JSON-C - A JSON implementation in C
-HOMEPAGE = http://oss.metaparadigm.com/json-c/;
-
-LICENSE = MIT
-LIC_FILES_CHKSUM = file://COPYING;md5=30a276a476b02c2dcd0849bde417fb17
-
-SRC_URI = http://oss.metaparadigm.com/json-c/json-c-${PV}.tar.gz;
-SRC_URI[md5sum] = 3a13d264528dcbaf3931b0cede24abae
-SRC_URI[sha256sum] =
702a486c9bf8e19137d484ab5c49b4ad314eb5e1fe37062a72c0a0fa39439475
-
-S = ${WORKDIR}/json-c-${PV}
-
-
-inherit autotools
diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
index 4c10aa9..475da41 100644
--- a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
+++ b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
@@ -11,7 +11,7 @@ LIC_FILES_CHKSUM =
file://GPL;md5=4325afd396febcb659c36b49533135d4 \
DEPENDS = libatomics-ops liboil libsamplerate0 libsndfile1 libtool
# optional
DEPENDS += udev alsa-lib glib-2.0 dbus gconf
-DEPENDS += libjson gdbm speex libxml-parser-perl-native
+DEPENDS += json-c gdbm speex libxml-parser-perl-native
inherit autotools pkgconfig useradd gettext perlnative
--
Jack Mitchell (j...@embed.me.uk)
Embedded Systems Engineer
http://www.embed.me.uk
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] core-image-weston: add SSH and hwcodecs to the image
On Mon, Nov 11, 2013 at 10:21 AM, Ross Burton ross.bur...@intel.com wrote: core-image-sato has these by default so add them here too. Signed-off-by: Ross Burton ross.bur...@intel.com I don't think the right image to compare here would be sato but maybe core-image-x11; I agree about hwcodecs - as we need hw acceleration and like - but ssh seems overkill. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] bluez: declaration of virtual/bluez and VIRTUAL-RUNTIME_bluez
On 11/11/2013 04:30 PM, Rongqing Li wrote:
On 11/11/2013 05:59 PM, Iorga, Cristian wrote:
Hi all,
As far as I have experimented, there is no upgrade path available at
the moment, due to extensive changes into the programming model for
BlueZ5 vs BlueZ4.
At the moment, the last single component that is not officially ready
for BlueZ5 is PulseAudio.
As have asked around, and PA5.0 will* support BlueZ5.
PA5.0 should* be released before EoY2013.
Judging by PA git log, there are extensive changes/updates in order to
support BZ5.
Regards,
Cristian
Thanks.
Saul: Do you think it is ready for merge, our release needs it, thanks.
At this point, I do not think this is an approporate patch, we can't
switch between bluez4 and bluez5 as Cristian points out above, they are
just not compatible. This is a case where we need 2 distinct versions
and once the recipes/upstreams for the things that rely on bluez4 are
updated to bluez5, we will cut over and then likely move the bluez4
stack out of oe-core into meta-oe.
Sau!
-Roy
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
Martin Jansa
Sent: Friday, November 1, 2013 11:35 AM
To: rongqing...@windriver.com
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH v2] bluez: declaration of virtual/bluez
and VIRTUAL-RUNTIME_bluez
On Fri, Nov 01, 2013 at 04:09:28PM +0800, rongqing...@windriver.com
wrote:
From: Roy Li rongqing...@windriver.com
We have two version bluez, declare virtual/bluez and
VIRTUAL-RUNTIME_bluez to switch them easily, and set the preferred
provider for bluez as bluez4
+1
I agree that some apps aren't compatible with both versions now, but
this gives easy way to switch between them for DISTRO which cares only
about apps which are compatible with bluez5 already.
BTW: Have someone tried upgrade path on target from bluez4 to bluez5?
I know we discussed it at lengths before bluez5 was merged, but don't
know if someone really tested it.
Signed-off-by: Roy Li rongqing...@windriver.com
---
meta/conf/distro/include/default-providers.inc
|5 ++---
meta/recipes-connectivity/bluez/bluez4.inc
|1 +
meta/recipes-connectivity/bluez5/bluez5.inc
|1 +
meta/recipes-connectivity/connman/connman.inc
|4 ++--
meta/recipes-connectivity/libpcap/libpcap.inc
|2 +-
meta/recipes-connectivity/neard/neard.inc
|2 +-
meta/recipes-connectivity/ofono/ofono.inc
|2 +-
meta/recipes-core/packagegroups/packagegroup-base.bb
|2 +-
meta/recipes-gnome/packagegroups/packagegroup-sdk-gmae.inc
|2 +-
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_git.bb
|2 +-
meta/recipes-multimedia/pulseaudio/pulseaudio.inc
|2 +-
meta/recipes-qt/qt4/qt-mobility_1.2.0.inc
|2 +-
12 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/meta/conf/distro/include/default-providers.inc
b/meta/conf/distro/include/default-providers.inc
index d4b9db0..0ec4cd9 100644
--- a/meta/conf/distro/include/default-providers.inc
+++ b/meta/conf/distro/include/default-providers.inc
@@ -14,6 +14,7 @@ PREFERRED_PROVIDER_virtual/update-alternatives ?=
opkg
PREFERRED_PROVIDER_virtual/update-alternatives-native ?= opkg-native
PREFERRED_PROVIDER_virtual/libx11 ?= libx11
PREFERRED_PROVIDER_xf86-video-intel ?= xf86-video-intel
+PREFERRED_PROVIDER_virtual/bluez ?= bluez4
#
# Default virtual runtime providers
@@ -21,6 +22,7 @@ PREFERRED_PROVIDER_xf86-video-intel ?=
xf86-video-intel
VIRTUAL-RUNTIME_update-alternatives ?= update-alternatives-cworth
VIRTUAL-RUNTIME_apm ?= apm
VIRTUAL-RUNTIME_alsa-state ?= alsa-state
+VIRTUAL-RUNTIME_bluez ?= bluez4
#
# Default recipe providers
@@ -40,6 +42,3 @@ PREFERRED_PROVIDER_console-tools ?= kbd
PREFERRED_PROVIDER_gzip-native ?= pigz-native
PREFERRED_PROVIDER_make ?= make
PREFERRED_PROVIDER_udev ?=
${@base_contains('DISTRO_FEATURES','systemd','systemd','udev',d)}
-# There are issues with runtime packages and PREFERRED_PROVIDER, see
YOCTO #5044 for details -# on this rather strange entry.
-PREFERRED_PROVIDER_bluez4 ?= bluez4
diff --git a/meta/recipes-connectivity/bluez/bluez4.inc
b/meta/recipes-connectivity/bluez/bluez4.inc
index e4f6834..c0babc6 100644
--- a/meta/recipes-connectivity/bluez/bluez4.inc
+++ b/meta/recipes-connectivity/bluez/bluez4.inc
@@ -9,6 +9,7 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e \
file://sbc/sbc.c;beginline=1;endline=25;md5=1a40781ed30d50d8639323a184aeb191
DEPENDS = udev libusb dbus-glib glib-2.0 libcheck readline
RDEPENDS_${PN}-dev = bluez-hcidump
+PROVIDES += virtual/bluez
PACKAGECONFIG ??= \
${@base_contains('DISTRO_FEATURES', 'alsa', 'alsa', '', d)}\ diff
--git a/meta/recipes-connectivity/bluez5/bluez5.inc
b/meta/recipes-connectivity/bluez5/bluez5.inc
index 2e25d86..b3ab131 100644
--- a/meta/recipes-connectivity/bluez5/bluez5.inc
+++
Re: [OE-core] [PATCH 0/1] udev: remove libudev-dbg and libgudev-dbg
On 11/12/2013 12:05 AM, Mark Hatle wrote: On 11/11/13, 4:10 AM, wenzong@windriver.com wrote: From: Wenzong Fan wenzong@windriver.com We don't support multiple -dbg packages, so just remove the libudev-dbg, libgudev-dbg and put all debug stuffs to 'udev-dbg'. I'm a bit confused, we do support package that want to provide multiple -dbg files to generate them. This way large recipes that provide lots of different bits of functionality can no only segment the packages they create, but keep the side of the -dbg information reasonable as well. (It's not all that commonly used, but it does work with the IMAGE_FEATURES 'dbg-pkgs'.) What issue was being solved by combining the two items back into one? Hi Mark, This is an updated patch for fixing the 'source codes -- -dbg packages' (i.e. which src should be shipped to which -dbg package), details please refer to another thread about: Subject: udev: ship source files to related dbg package As Richard mentioned: We don't support multiple -dbg packages and this looks like an error. - (the udev have there -dbg packages: libudev-dbg/libgudev-dbg/udev-dbg) If I was wrong please correct me. Thanks Wenzong --Mark The following changes since commit 4fdc3d77d4a875b7236536bf78849a4d1f6a7449: kbd: Fix stdarg related errors on uclibc (2013-11-08 17:31:36 +) are available in the git repository at: git://git.pokylinux.org/poky-contrib wenzong/udev-remove-dbg http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=wenzong/udev-remove-dbg Wenzong Fan (1): udev: remove libudev-dbg and libgudev-dbg meta/recipes-core/udev/udev.inc |6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] bluez: declaration of virtual/bluez and VIRTUAL-RUNTIME_bluez
On 13-11-11 08:31 PM, Saul Wold wrote:
On 11/11/2013 04:30 PM, Rongqing Li wrote:
On 11/11/2013 05:59 PM, Iorga, Cristian wrote:
Hi all,
As far as I have experimented, there is no upgrade path available at
the moment, due to extensive changes into the programming model for
BlueZ5 vs BlueZ4.
At the moment, the last single component that is not officially ready
for BlueZ5 is PulseAudio.
As have asked around, and PA5.0 will* support BlueZ5.
PA5.0 should* be released before EoY2013.
Judging by PA git log, there are extensive changes/updates in order to
support BZ5.
Regards,
Cristian
Thanks.
Saul: Do you think it is ready for merge, our release needs it, thanks.
At this point, I do not think this is an approporate patch, we can't
switch between bluez4 and bluez5 as Cristian points out above, they are
just not compatible. This is a case where we need 2 distinct versions
and once the recipes/upstreams for the things that rely on bluez4 are
updated to bluez5, we will cut over and then likely move the bluez4
stack out of oe-core into meta-oe.
Sau!
Okay, thanks for the clarification.
../Randy
-Roy
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
Martin Jansa
Sent: Friday, November 1, 2013 11:35 AM
To: rongqing...@windriver.com
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH v2] bluez: declaration of virtual/bluez
and VIRTUAL-RUNTIME_bluez
On Fri, Nov 01, 2013 at 04:09:28PM +0800, rongqing...@windriver.com
wrote:
From: Roy Li rongqing...@windriver.com
We have two version bluez, declare virtual/bluez and
VIRTUAL-RUNTIME_bluez to switch them easily, and set the preferred
provider for bluez as bluez4
+1
I agree that some apps aren't compatible with both versions now, but
this gives easy way to switch between them for DISTRO which cares only
about apps which are compatible with bluez5 already.
BTW: Have someone tried upgrade path on target from bluez4 to bluez5?
I know we discussed it at lengths before bluez5 was merged, but don't
know if someone really tested it.
Signed-off-by: Roy Li rongqing...@windriver.com
---
meta/conf/distro/include/default-providers.inc
|5 ++---
meta/recipes-connectivity/bluez/bluez4.inc
|1 +
meta/recipes-connectivity/bluez5/bluez5.inc
|1 +
meta/recipes-connectivity/connman/connman.inc
|4 ++--
meta/recipes-connectivity/libpcap/libpcap.inc
|2 +-
meta/recipes-connectivity/neard/neard.inc
|2 +-
meta/recipes-connectivity/ofono/ofono.inc
|2 +-
meta/recipes-core/packagegroups/packagegroup-base.bb
|2 +-
meta/recipes-gnome/packagegroups/packagegroup-sdk-gmae.inc
|2 +-
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_git.bb
|2 +-
meta/recipes-multimedia/pulseaudio/pulseaudio.inc
|2 +-
meta/recipes-qt/qt4/qt-mobility_1.2.0.inc
|2 +-
12 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/meta/conf/distro/include/default-providers.inc
b/meta/conf/distro/include/default-providers.inc
index d4b9db0..0ec4cd9 100644
--- a/meta/conf/distro/include/default-providers.inc
+++ b/meta/conf/distro/include/default-providers.inc
@@ -14,6 +14,7 @@ PREFERRED_PROVIDER_virtual/update-alternatives ?=
opkg
PREFERRED_PROVIDER_virtual/update-alternatives-native ?=
opkg-native
PREFERRED_PROVIDER_virtual/libx11 ?= libx11
PREFERRED_PROVIDER_xf86-video-intel ?= xf86-video-intel
+PREFERRED_PROVIDER_virtual/bluez ?= bluez4
#
# Default virtual runtime providers
@@ -21,6 +22,7 @@ PREFERRED_PROVIDER_xf86-video-intel ?=
xf86-video-intel
VIRTUAL-RUNTIME_update-alternatives ?= update-alternatives-cworth
VIRTUAL-RUNTIME_apm ?= apm
VIRTUAL-RUNTIME_alsa-state ?= alsa-state
+VIRTUAL-RUNTIME_bluez ?= bluez4
#
# Default recipe providers
@@ -40,6 +42,3 @@ PREFERRED_PROVIDER_console-tools ?= kbd
PREFERRED_PROVIDER_gzip-native ?= pigz-native
PREFERRED_PROVIDER_make ?= make
PREFERRED_PROVIDER_udev ?=
${@base_contains('DISTRO_FEATURES','systemd','systemd','udev',d)}
-# There are issues with runtime packages and PREFERRED_PROVIDER, see
YOCTO #5044 for details -# on this rather strange entry.
-PREFERRED_PROVIDER_bluez4 ?= bluez4
diff --git a/meta/recipes-connectivity/bluez/bluez4.inc
b/meta/recipes-connectivity/bluez/bluez4.inc
index e4f6834..c0babc6 100644
--- a/meta/recipes-connectivity/bluez/bluez4.inc
+++ b/meta/recipes-connectivity/bluez/bluez4.inc
@@ -9,6 +9,7 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e \
file://sbc/sbc.c;beginline=1;endline=25;md5=1a40781ed30d50d8639323a184aeb191
DEPENDS = udev libusb dbus-glib glib-2.0 libcheck readline
RDEPENDS_${PN}-dev = bluez-hcidump
+PROVIDES += virtual/bluez
PACKAGECONFIG ??= \
${@base_contains('DISTRO_FEATURES', 'alsa', 'alsa', '', d)}\ diff
--git a/meta/recipes-connectivity/bluez5/bluez5.inc
b/meta/recipes-connectivity/bluez5/bluez5.inc
index 2e25d86..b3ab131 100644
---
Re: [OE-core] [PATCH 1/2] tcl: Install header into 8.6 instead of PN-PV in user/include
On 11/11/2013 01:23 AM, Khem Raj wrote:
This helps in compiling other programs like expect which
depend on private headers but 8.5, 8.6 and so on is enough
granularity and currently we had 8.6.x and so on which
means that expect recipe will need to be touched whenever there
is minor update of tcl.
Additionally the encode creating symlink to shared object in
patch and remove it from recipe
Refresh patches after making changes to Configure.in we
propertly generate configure and not patch is directly as
was the case.
Signed-off-by: Khem Raj raj.k...@gmail.com
---
.../tcltk/tcl/alter-includedir.patch | 39 +
.../tcl/fix_issue_with_old_distro_glibc.patch | 12 ++--
.../tcltk/tcl/fix_non_native_build_issue.patch | 12 ++--
meta/recipes-devtools/tcltk/tcl/no_packages.patch | 16 +++---
.../tcltk/tcl/tcl-add-soname.patch | 64 ++
.../tcl/tcl-remove-hardcoded-install-path.patch| 26 ++---
meta/recipes-devtools/tcltk/tcl_8.6.1.bb | 26 +
7 files changed, 120 insertions(+), 75 deletions(-)
create mode 100644 meta/recipes-devtools/tcltk/tcl/alter-includedir.patch
diff --git a/meta/recipes-devtools/tcltk/tcl/alter-includedir.patch
b/meta/recipes-devtools/tcltk/tcl/alter-includedir.patch
new file mode 100644
index 000..32e63c0
--- /dev/null
+++ b/meta/recipes-devtools/tcltk/tcl/alter-includedir.patch
New patch needs header please.
Thanks
Sau!
@@ -0,0 +1,39 @@
+Index: unix/Makefile.in
+===
+--- unix.orig/Makefile.in 2013-11-11 01:00:36.431550403 -0800
unix/Makefile.in 2013-11-11 01:05:09.587557282 -0800
+@@ -53,7 +53,7 @@
+ SCRIPT_INSTALL_DIR= $(INSTALL_ROOT)$(TCL_LIBRARY)
+
+ # Directory in which to install the include file tcl.h:
+-INCLUDE_INSTALL_DIR = $(INSTALL_ROOT)$(includedir)
++INCLUDE_INSTALL_DIR = $(INSTALL_ROOT)$(includedir)/tcl$(VERSION)
+
+ # Path to the private tcl header dir:
+ PRIVATE_INCLUDE_DIR = @PRIVATE_INCLUDE_DIR@
+Index: unix/configure.in
+===
+--- unix.orig/configure.in 2013-11-11 01:00:36.467550403 -0800
unix/configure.in 2013-11-11 01:00:36.503550404 -0800
+@@ -791,7 +791,7 @@
+ eval TCL_LIB_FILE=${TCL_LIB_FILE}
+
+ TCL_LIBRARY='$(libdir)/tcl$(VERSION)'
+-PRIVATE_INCLUDE_DIR='$(includedir)'
++PRIVATE_INCLUDE_DIR='$(includedir)/tcl$(VERSION)'
+ HTML_DIR='$(DISTDIR)/html'
+
+ # Note: in the following variable, it's important to use the absolute
+Index: unix/configure
+===
+--- unix.orig/configure2013-11-11 01:00:36.467550403 -0800
unix/configure 2013-11-11 01:00:36.503550404 -0800
+@@ -19134,7 +19134,7 @@
+ eval TCL_LIB_FILE=${TCL_LIB_FILE}
+
+ TCL_LIBRARY='$(libdir)/tcl$(VERSION)'
+-PRIVATE_INCLUDE_DIR='$(includedir)'
++PRIVATE_INCLUDE_DIR='$(includedir)/tcl$(VERSION)'
+ HTML_DIR='$(DISTDIR)/html'
+
+ # Note: in the following variable, it's important to use the absolute
diff --git
a/meta/recipes-devtools/tcltk/tcl/fix_issue_with_old_distro_glibc.patch
b/meta/recipes-devtools/tcltk/tcl/fix_issue_with_old_distro_glibc.patch
index ed58175..be27341 100644
--- a/meta/recipes-devtools/tcltk/tcl/fix_issue_with_old_distro_glibc.patch
+++ b/meta/recipes-devtools/tcltk/tcl/fix_issue_with_old_distro_glibc.patch
@@ -15,11 +15,11 @@ Fixes tcl target recipe build on old distros which have
glibc older than 2.14
Signed-Off-By: Nitin A Kamble nitin.a.kam...@intel.com
2012/04/26
-diff --git unix.orig/Makefile.in unix/Makefile.in
-index 571d53f..16351f6 100644
unix.orig/Makefile.in
-+++ unix/Makefile.in
-@@ -679,7 +679,7 @@ topDirName:
+Index: unix/Makefile.in
+===
+--- unix.orig/Makefile.in 2013-11-10 23:38:01.787425628 -0800
unix/Makefile.in 2013-11-10 23:37:59.807425578 -0800
+@@ -686,7 +686,7 @@
# tcltest executable gets the build directory burned into its ld search path.
# This keeps tcltest from picking up an already installed version of the Tcl
# library.
@@ -28,7 +28,7 @@ index 571d53f..16351f6 100644
TCLLIBPATH=@abs_builddir@/pkgs \
TCL_LIBRARY=${TCL_BUILDTIME_LIBRARY}
-@@ -705,7 +705,7 @@ test-tcl: ${TCLTEST_EXE}
+@@ -712,7 +712,7 @@
$(SHELL_ENV) ${TCLTEST_EXE} $(TOP_DIR)/tests/all.tcl $(TESTFLAGS)
gdb-test: ${TCLTEST_EXE}
diff --git a/meta/recipes-devtools/tcltk/tcl/fix_non_native_build_issue.patch
b/meta/recipes-devtools/tcltk/tcl/fix_non_native_build_issue.patch
index 80d718c..c60eb75 100644
--- a/meta/recipes-devtools/tcltk/tcl/fix_non_native_build_issue.patch
+++ b/meta/recipes-devtools/tcltk/tcl/fix_non_native_build_issue.patch
@@ -1,10 +1,10 @@
Upstream-Status: Pending
-diff --git unix.orig/Makefile.in unix/Makefile.in
-index df05759..571d53f 100644
unix.orig/Makefile.in
-+++
[OE-core] [PATCH] mdadm: flag __SANE_USERSPACE_TYPES__ to include int-ll64.h for powerpc64
*PPC64 uses long long for u64 in the kernel, but powerpc's asm/types.h
prevents 64-bit userland from seeing this definition, instead defaulting
to u64 == long in userspace.
*fix the below error
|super-ddf.c:4542:5: error: format '%llu' expects argument of type 'long
long unsigned int',
|but argument 5 has type '__u64' [-Werror=format=]
|dprintf(BVD %u has %08x at %llu\n, 0,
Signed-off-by: Chunrong Guo b40...@freescale.com
---
meta/recipes-extended/mdadm/mdadm_3.3.bb |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/meta/recipes-extended/mdadm/mdadm_3.3.bb
b/meta/recipes-extended/mdadm/mdadm_3.3.bb
index 586e04a..41816bc 100644
--- a/meta/recipes-extended/mdadm/mdadm_3.3.bb
+++ b/meta/recipes-extended/mdadm/mdadm_3.3.bb
@@ -26,6 +26,11 @@ do_configure_prepend () {
}
EXTRA_OEMAKE = CHECK_RUN_DIR=0
+# PPC64 uses long long for u64 in the kernel, but powerpc's asm/types.h
+# prevents 64-bit userland from seeing this definition, instead defaulting
+# to u64 == long in userspace. Define __SANE_USERSPACE_TYPES__ to get
+# int-ll64.h included
+EXTRA_OEMAKE_append_powerpc64 = ' CFLAGS=-D__SANE_USERSPACE_TYPES__'
do_compile() {
oe_runmake
--
1.7.5.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH V2] tcl: Install header into 8.6 instead of PN-PV in user/include
This helps in compiling other programs like expect which
depend on private headers but 8.5, 8.6 and so on is enough
granularity and currently we had 8.6.x and so on which
means that expect recipe will need to be touched whenever there
is minor update of tcl.
Additionally the encode creating symlink to shared object in
patch and remove it from recipe
Refresh patches after making changes to Configure.in we
propertly generate configure and not patch is directly as
was the case.
Signed-off-by: Khem Raj raj.k...@gmail.com
---
.../tcltk/tcl/alter-includedir.patch | 46
.../tcl/fix_issue_with_old_distro_glibc.patch | 12 ++--
.../tcltk/tcl/fix_non_native_build_issue.patch | 12 ++--
meta/recipes-devtools/tcltk/tcl/no_packages.patch | 16 +++---
.../tcltk/tcl/tcl-add-soname.patch | 64 ++
.../tcl/tcl-remove-hardcoded-install-path.patch| 26 ++---
meta/recipes-devtools/tcltk/tcl_8.6.1.bb | 26 +
7 files changed, 127 insertions(+), 75 deletions(-)
create mode 100644 meta/recipes-devtools/tcltk/tcl/alter-includedir.patch
diff --git a/meta/recipes-devtools/tcltk/tcl/alter-includedir.patch
b/meta/recipes-devtools/tcltk/tcl/alter-includedir.patch
new file mode 100644
index 000..f543910
--- /dev/null
+++ b/meta/recipes-devtools/tcltk/tcl/alter-includedir.patch
@@ -0,0 +1,46 @@
+Lets install the include header and private header files into
+usr/include/tcl8.6 when version of tcl is 8.6.x
+
+Upstream-Status: Inappropriate [Configuration Specific]
+
+Signed-off-by: Khem Raj raj.k...@gmai.com
+
+Index: unix/Makefile.in
+===
+--- unix.orig/Makefile.in 2013-11-11 01:00:36.431550403 -0800
unix/Makefile.in 2013-11-11 01:05:09.587557282 -0800
+@@ -53,7 +53,7 @@
+ SCRIPT_INSTALL_DIR= $(INSTALL_ROOT)$(TCL_LIBRARY)
+
+ # Directory in which to install the include file tcl.h:
+-INCLUDE_INSTALL_DIR = $(INSTALL_ROOT)$(includedir)
++INCLUDE_INSTALL_DIR = $(INSTALL_ROOT)$(includedir)/tcl$(VERSION)
+
+ # Path to the private tcl header dir:
+ PRIVATE_INCLUDE_DIR = @PRIVATE_INCLUDE_DIR@
+Index: unix/configure.in
+===
+--- unix.orig/configure.in 2013-11-11 01:00:36.467550403 -0800
unix/configure.in 2013-11-11 01:00:36.503550404 -0800
+@@ -791,7 +791,7 @@
+ eval TCL_LIB_FILE=${TCL_LIB_FILE}
+
+ TCL_LIBRARY='$(libdir)/tcl$(VERSION)'
+-PRIVATE_INCLUDE_DIR='$(includedir)'
++PRIVATE_INCLUDE_DIR='$(includedir)/tcl$(VERSION)'
+ HTML_DIR='$(DISTDIR)/html'
+
+ # Note: in the following variable, it's important to use the absolute
+Index: unix/configure
+===
+--- unix.orig/configure2013-11-11 01:00:36.467550403 -0800
unix/configure 2013-11-11 01:00:36.503550404 -0800
+@@ -19134,7 +19134,7 @@
+ eval TCL_LIB_FILE=${TCL_LIB_FILE}
+
+ TCL_LIBRARY='$(libdir)/tcl$(VERSION)'
+-PRIVATE_INCLUDE_DIR='$(includedir)'
++PRIVATE_INCLUDE_DIR='$(includedir)/tcl$(VERSION)'
+ HTML_DIR='$(DISTDIR)/html'
+
+ # Note: in the following variable, it's important to use the absolute
diff --git
a/meta/recipes-devtools/tcltk/tcl/fix_issue_with_old_distro_glibc.patch
b/meta/recipes-devtools/tcltk/tcl/fix_issue_with_old_distro_glibc.patch
index ed58175..be27341 100644
--- a/meta/recipes-devtools/tcltk/tcl/fix_issue_with_old_distro_glibc.patch
+++ b/meta/recipes-devtools/tcltk/tcl/fix_issue_with_old_distro_glibc.patch
@@ -15,11 +15,11 @@ Fixes tcl target recipe build on old distros which have
glibc older than 2.14
Signed-Off-By: Nitin A Kamble nitin.a.kam...@intel.com
2012/04/26
-diff --git unix.orig/Makefile.in unix/Makefile.in
-index 571d53f..16351f6 100644
unix.orig/Makefile.in
-+++ unix/Makefile.in
-@@ -679,7 +679,7 @@ topDirName:
+Index: unix/Makefile.in
+===
+--- unix.orig/Makefile.in 2013-11-10 23:38:01.787425628 -0800
unix/Makefile.in 2013-11-10 23:37:59.807425578 -0800
+@@ -686,7 +686,7 @@
# tcltest executable gets the build directory burned into its ld search path.
# This keeps tcltest from picking up an already installed version of the Tcl
# library.
@@ -28,7 +28,7 @@ index 571d53f..16351f6 100644
TCLLIBPATH=@abs_builddir@/pkgs \
TCL_LIBRARY=${TCL_BUILDTIME_LIBRARY}
-@@ -705,7 +705,7 @@ test-tcl: ${TCLTEST_EXE}
+@@ -712,7 +712,7 @@
$(SHELL_ENV) ${TCLTEST_EXE} $(TOP_DIR)/tests/all.tcl $(TESTFLAGS)
gdb-test: ${TCLTEST_EXE}
diff --git a/meta/recipes-devtools/tcltk/tcl/fix_non_native_build_issue.patch
b/meta/recipes-devtools/tcltk/tcl/fix_non_native_build_issue.patch
index 80d718c..c60eb75 100644
--- a/meta/recipes-devtools/tcltk/tcl/fix_non_native_build_issue.patch
+++ b/meta/recipes-devtools/tcltk/tcl/fix_non_native_build_issue.patch
@@ -1,10 +1,10 @@
Upstream-Status: Pending
Re: [OE-core] [PATCH 1/2] tcl: Install header into 8.6 instead of PN-PV in user/include
On Mon, Nov 11, 2013 at 7:28 PM, Saul Wold s...@linux.intel.com wrote: On 11/11/2013 01:23 AM, Khem Raj wrote: This helps in compiling other programs like expect which depend on private headers but 8.5, 8.6 and so on is enough granularity and currently we had 8.6.x and so on which means that expect recipe will need to be touched whenever there is minor update of tcl. Additionally the encode creating symlink to shared object in patch and remove it from recipe Refresh patches after making changes to Configure.in we propertly generate configure and not patch is directly as was the case. Signed-off-by: Khem Raj raj.k...@gmail.com --- .../tcltk/tcl/alter-includedir.patch | 39 + .../tcl/fix_issue_with_old_distro_glibc.patch | 12 ++-- .../tcltk/tcl/fix_non_native_build_issue.patch | 12 ++-- meta/recipes-devtools/tcltk/tcl/no_packages.patch | 16 +++--- .../tcltk/tcl/tcl-add-soname.patch | 64 ++ .../tcl/tcl-remove-hardcoded-install-path.patch| 26 ++--- meta/recipes-devtools/tcltk/tcl_8.6.1.bb | 26 + 7 files changed, 120 insertions(+), 75 deletions(-) create mode 100644 meta/recipes-devtools/tcltk/tcl/alter-includedir.patch diff --git a/meta/recipes-devtools/tcltk/tcl/alter-includedir.patch b/meta/recipes-devtools/tcltk/tcl/alter-includedir.patch new file mode 100644 index 000..32e63c0 --- /dev/null +++ b/meta/recipes-devtools/tcltk/tcl/alter-includedir.patch New patch needs header please. sent a V2 just now ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [for-dora][for-master][PATCH] libnl: Fix random segfaults due to memory corruption
This is a backport from upstream fixes a severe problem
w.r.t memory management, where it would result in random
segfaults in applications depending on libnl
Signed-off-by: Khem Raj raj.k...@gmail.com
---
...free-caused-by-freeing-link-af_data-in-rt.patch | 41 ++
meta/recipes-support/libnl/libnl_3.2.22.bb | 4 ++-
2 files changed, 44 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-support/libnl/libnl/0001-fix-double-free-caused-by-freeing-link-af_data-in-rt.patch
diff --git
a/meta/recipes-support/libnl/libnl/0001-fix-double-free-caused-by-freeing-link-af_data-in-rt.patch
b/meta/recipes-support/libnl/libnl/0001-fix-double-free-caused-by-freeing-link-af_data-in-rt.patch
new file mode 100644
index 000..6d2c8ff
--- /dev/null
+++
b/meta/recipes-support/libnl/libnl/0001-fix-double-free-caused-by-freeing-link-af_data-in-rt.patch
@@ -0,0 +1,41 @@
+From 6f37b439af7e96104aadd8ec3ae8d3882df8d102 Mon Sep 17 00:00:00 2001
+From: Jiri Pirko j...@resnulli.us
+Date: Wed, 21 Aug 2013 14:40:34 +0200
+Subject: [PATCH] fix double free caused by freeing link af_data in
+ rtnl_link_set_family()
+
+Introduced by commit 8026fe2e3a9089eff3f5a06ee6e3cc78d96334ed (link:
+Free and realloc af specific data upon rtnl_link_set_family())
+
+link-l_af_data[link-l_af_ops-ao_family] is freed here but not set to
+zero. That leads to double free made by link_free_data-do_foreach_af.
+
+Fix this by setting link-l_af_data[link-l_af_ops-ao_family] to zero
+rigth after free.
+
+Signed-off-by: Jiri Pirko j...@resnulli.us
+Signed-off-by: Thomas Graf tg...@suug.ch
+---
+ lib/route/link.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/lib/route/link.c b/lib/route/link.c
+index a73e1db..0bb90a0 100644
+--- a/lib/route/link.c
b/lib/route/link.c
+@@ -1762,9 +1762,11 @@ void rtnl_link_set_family(struct rtnl_link *link, int
family)
+ link-l_family = family;
+ link-ce_mask |= LINK_ATTR_FAMILY;
+
+- if (link-l_af_ops)
++ if (link-l_af_ops) {
+ af_free(link, link-l_af_ops,
+ link-l_af_data[link-l_af_ops-ao_family], NULL);
++ link-l_af_data[link-l_af_ops-ao_family] = NULL;
++ }
+
+ link-l_af_ops = af_lookup_and_alloc(link, family);
+ }
+--
+1.8.4
+
diff --git a/meta/recipes-support/libnl/libnl_3.2.22.bb
b/meta/recipes-support/libnl/libnl_3.2.22.bb
index 30f85b2..3c31b1a 100644
--- a/meta/recipes-support/libnl/libnl_3.2.22.bb
+++ b/meta/recipes-support/libnl/libnl_3.2.22.bb
@@ -12,7 +12,9 @@ DEPENDS = flex-native bison-native
SRC_URI = http://www.infradead.org/~tgr/${BPN}/files/${BP}.tar.gz \
file://fix-pktloc_syntax_h-race.patch \
file://fix-pc-file.patch \
- file://fix-lib-cache_mngr.c-two-parentheses-bugs.patch
+ file://fix-lib-cache_mngr.c-two-parentheses-bugs.patch \
+
file://0001-fix-double-free-caused-by-freeing-link-af_data-in-rt.patch \
+
SRC_URI[md5sum] = 2e1c889494d274aca24ce5f6a748e66e
SRC_URI[sha256sum] =
c7c5f267dfeae0c1a530bf96b71fb7c8dbbb07d54beef49b6712d8d6166f629b
--
1.8.3.2
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v8] connman: ignore the networking device which nfs for rootfs is working on
From: Roy Li rongqing...@windriver.com
Create connman-evn.service, which will run a script to compute the networking
device when nfs root is on, and pass the result to connman.service
Connmand.service add ExecStartPre into Connmand.service to release
do_configure_append work, use the options which is passed by connman-evn.service
Signed-off-by: Roy Li rongqing...@windriver.com
---
meta/recipes-connectivity/connman/connman.inc | 17 +-
.../connman/connman/connman-env.service| 13
.../connman/connman/connmand-env | 26 +++
...ardcode-and-add-EnvironmentFile-and-Wants.patch | 33
meta/recipes-connectivity/connman/connman_1.19.bb |3 ++
5 files changed, 85 insertions(+), 7 deletions(-)
create mode 100644
meta/recipes-connectivity/connman/connman/connman-env.service
create mode 100644 meta/recipes-connectivity/connman/connman/connmand-env
create mode 100644
meta/recipes-connectivity/connman/connman/replace-hardcode-and-add-EnvironmentFile-and-Wants.patch
diff --git a/meta/recipes-connectivity/connman/connman.inc
b/meta/recipes-connectivity/connman/connman.inc
index 12f3edd..648b9f6 100644
--- a/meta/recipes-connectivity/connman/connman.inc
+++ b/meta/recipes-connectivity/connman/connman.inc
@@ -64,15 +64,9 @@ python __anonymous () {
SYSTEMD_SERVICE_${PN} = connman.service
SYSTEMD_SERVICE_${PN}-vpn = connman-vpn.service
-SYSTEMD_WIRED_SETUP = ExecStartPre=-${libdir}/connman/wired-setup
inherit autotools gtk-doc pkgconfig systemd update-rc.d
-do_configure_append () {
- sed -i s#ExecStart=#${SYSTEMD_WIRED_SETUP}\nExecStart=#
${S}/src/connman.service
-
-}
-
# This allows *everyone* to access ConnMan over DBus, without any access
# control. Really the at_console flag should work, which would mean that
# both this and the xuser patch can be dropped.
@@ -88,6 +82,15 @@ do_install_append() {
sed -i s%@LIBDIR@%${libdir}% ${D}${sysconfdir}/init.d/connman
fi
+ if ${@base_contains('DISTRO_FEATURES','systemd','true','false',d)}; then
+ install -m 0755 ${WORKDIR}/connmand-env ${D}${sbindir}/
+ install -m 0644 ${WORKDIR}/connman-env.service
${D}/${systemd_unitdir}/system/
+ sed -i -e 's,@SBINDIR@,${sbindir},g' \
+ -e 's,@LIBDIR@,${libdir},g' \
+ -e 's,@LOCALSTATEDIR@,${localstatedir},g' \
+ ${D}${systemd_unitdir}/system/*.service
+ fi
+
install -d ${D}${bindir}
install -m 0755 ${S}/tools/*-test ${D}${bindir}
if [ -e ${S}/tools/wispr ]; then
@@ -163,7 +166,7 @@ FILES_${PN} = ${bindir}/* ${sbindir}/* ${libexecdir}/*
${libdir}/lib*.so.* \
${libdir}/connman/plugins \
${sysconfdir} ${sharedstatedir} ${localstatedir} \
${base_bindir}/* ${base_sbindir}/* ${base_libdir}/*.so*
${datadir}/${PN} \
-${datadir}/dbus-1/system-services/*
+${datadir}/dbus-1/system-services/*
${systemd_unitdir}/system/connman-env.service
FILES_${PN}-dbg += ${libdir}/connman/*/.debug
diff --git a/meta/recipes-connectivity/connman/connman/connman-env.service
b/meta/recipes-connectivity/connman/connman/connman-env.service
new file mode 100644
index 000..c4dc278
--- /dev/null
+++ b/meta/recipes-connectivity/connman/connman/connman-env.service
@@ -0,0 +1,13 @@
+[Unit]
+Description=Generate options for connection service
+Before=connman.service
+ConditionKernelCommandLine=root=/dev/nfs
+After=syslog.target
+
+[Service]
+Type=oneshot
+ExecStart=@SBINDIR@/connmand-env
+StandardOutput=null
+
+[Install]
+WantedBy=connman.service
diff --git a/meta/recipes-connectivity/connman/connman/connmand-env
b/meta/recipes-connectivity/connman/connman/connmand-env
new file mode 100644
index 000..9c04d61
--- /dev/null
+++ b/meta/recipes-connectivity/connman/connman/connmand-env
@@ -0,0 +1,26 @@
+#!/bin/sh
+
+EXTRA_PARAM=
+
+NET_DEVS=`cat /proc/net/dev | sed -ne 's/^\([a-zA-Z0-9 ]*\):.*$/\1/p'`
+NET_ADDR=`cat /proc/cmdline | sed -ne 's/^.*ip=\([^ :]*\).*$/\1/p'`
+
+if [ ! -z $NET_ADDR ]; then
+if [ $NET_ADDR = dhcp ]; then
+ethn=`ifconfig | grep ^eth | sed -e s/\(eth[0-9]\)\(.*\)/\1/`
+if [ ! -z $ethn ]; then
+EXTRA_PARAM=-I $ethn
+fi
+else
+for i in $NET_DEVS; do
+ADDR=`ifconfig $i | sed 's/addr://g' | sed -ne 's/^.*inet \([0-9.]*\)
.*$/\1/p'`
+if [ $NET_ADDR = $ADDR ]; then
+EXTRA_PARAM=-I $i
+break
+fi
+done
+fi
+fi
+
+[ ! -d /run/connmand ] mkdir -p /run/connmand
+echo CONNMAND_OPTS=$EXTRA_PARAM/run/connmand/connmand.env
diff --git
a/meta/recipes-connectivity/connman/connman/replace-hardcode-and-add-EnvironmentFile-and-Wants.patch
b/meta/recipes-connectivity/connman/connman/replace-hardcode-and-add-EnvironmentFile-and-Wants.patch
new file mode 100644
index 000..1394335
--- /dev/null
Re: [OE-core] [PATCH 0/1] udev: remove libudev-dbg and libgudev-dbg
On Mon, 2013-11-11 at 10:05 -0600, Mark Hatle wrote: On 11/11/13, 4:10 AM, wenzong@windriver.com wrote: From: Wenzong Fan wenzong@windriver.com We don't support multiple -dbg packages, so just remove the libudev-dbg, libgudev-dbg and put all debug stuffs to 'udev-dbg'. I'm a bit confused, we do support package that want to provide multiple -dbg files to generate them. No, we do not. We don't support multiple -dev packages either. Yes packages can generate them but the system does not correctly handle them and never has. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
