Re: [OE-core] [PATCH V2] tcl: Install header into 8.6 instead of PN-PV in user/include
On 11/12/2013 12:07 PM, 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 | 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)
+
Hi Khem,
I think that the tcl headers like tcl.h wass installed to:
/usr/include/tcl.h
with this patch, it will be installed:
/usr/include/tcl8.6/tcl.h
The problem is that, the tcl.h can't be found normally now, it breaks
the recipe which depends on tcl, the recipe which depends on tcl
has to use something like:
--with-tclinclude=${STAGING_INCDIR}/tcl8.6
once we upgrade the tcl to 8.7, then the recipe has to use:
--with-tclinclude=${STAGING_INCDIR}/tcl8.7
Seems that this is not good, can we change it back, please ?
// Robert
+ # 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
Re: [OE-core] [PATCH V2] tcl: Install header into 8.6 instead of PN-PV in user/include
On 01/16/2014 04:31 PM, Robert Yang wrote:
On 11/12/2013 12:07 PM, 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.
+ # Directory in which to install the include file tcl.h:
+-INCLUDE_INSTALL_DIR= $(INSTALL_ROOT)$(includedir)
++INCLUDE_INSTALL_DIR= $(INSTALL_ROOT)$(includedir)/tcl$(VERSION)
+
Hi Khem,
I think that the tcl headers like tcl.h wass installed to:
/usr/include/tcl.h
with this patch, it will be installed:
/usr/include/tcl8.6/tcl.h
And what's worse is that some recipe like rrdtool may use:
#include tcl.h
will fail to, it has to use #include tcl8.6/tcl.h or something else similar.
I think that we'd better change it back, I'd like to send a patch for this if
you are fine with it.
// Robert
The problem is that, the tcl.h can't be found normally now, it breaks
the recipe which depends on tcl, the recipe which depends on tcl
has to use something like:
--with-tclinclude=${STAGING_INCDIR}/tcl8.6
once we upgrade the tcl to 8.7, then the recipe has to use:
--with-tclinclude=${STAGING_INCDIR}/tcl8.7
Seems that this is not good, can we change it back, please ?
// Robert
+ # Path to the private tcl header dir:
+ PRIVATE_INCLUDE_DIR= @PRIVATE_INCLUDE_DIR@
+Index: unix/configure.in
+===
+--- unix.orig/configure.in2013-11-11 01:00:36.467550403 -0800
unix/configure.in2013-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/configure2013-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.in2013-11-10 23:38:01.787425628 -0800
unix/Makefile.in2013-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
+===
+--- unix.orig/Makefile.in2013-11-10 23:37:34.243424934 -0800
unix/Makefile.in2013-11-10 23:37:34.243424934 -0800
+@@ -709,23 +709,23 @@
test: test-tcl test-packages
test-tcl: ${TCLTEST_EXE}
@@ -32,7 +32,7 @@ index df05759..571d53f 100644
# The following target generates the shared libraries in dltest/ that are
used
# for testing; they are included as part of the tcltest target (via the
-@@ -736,23 +736,23 @@ dltest.marker: ${STUB_LIB_FILE}
+@@ -743,23 +743,23 @@
# This
Re: [OE-core] [PATCH 0/5] refactor the archive*.bbcalss
On Thu, Jan 16, 2014 at 10:14:30AM +0800, Robert Yang wrote:
On 01/16/2014 12:55 AM, Martin Jansa wrote:
On Tue, Jan 14, 2014 at 12:20:14AM +0800, Robert Yang wrote:
* The archive*.bbclass didn't work, and there were a few problems, for
example:
1) There were a few duplicated code
2) There was no src_dir.org (or orig), but the diff command still use
it, and it is not easy to fix this issue if we don't change a lot
of the code.
3) It didn't archive the source for the native or gcc
4) The work flow is not very well
5) The subprocess.call('fakeroot cp ' should be removed
6) And others ...
* So that we have to refactor it, the benefits are:
1) Fix the problems and make it work well.
2) Reduce more than 400 lines in total.
3) Make it easy to use.
// Robert
The following changes since commit
1b636173ca88e5ccca1992f9a12367a1189fa674:
bitbake: toaster: Toaster GUI, generic search, filter and order
(2014-01-10 15:20:26 +)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib rbt/archiver
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=rbt/archiver
Can you send pull-request for oe-core?
Here it is:
git://git.pokylinux.org/poky-contrib rbt/ar_oe
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=rbt/ar_oe
This still looks like poky-contrib (so it will download whole
poky-contrib when I add it as remote to oe-core repo).
// Robert
Robert Yang (5):
classes/archive*.bbclass: remove archive-*-source.bbclass
archiver.bbclass: refactor it
package_rpm.bbclass: archive the source to srpm package
archiver.bbclass: move a few code to copyleft_compliance.bbclass
local.conf.sample.extended: update for the archiver
meta-yocto/conf/local.conf.sample.extended | 72 +--
meta/classes/archive-configured-source.bbclass | 65 ---
meta/classes/archive-original-source.bbclass | 65 ---
meta/classes/archive-patched-source.bbclass| 65 ---
meta/classes/archiver.bbclass | 723
-
meta/classes/copyleft_compliance.bbclass | 55 +-
meta/classes/package_rpm.bbclass | 31 +-
7 files changed, 316 insertions(+), 760 deletions(-)
delete mode 100644 meta/classes/archive-configured-source.bbclass
delete mode 100644 meta/classes/archive-original-source.bbclass
delete mode 100644 meta/classes/archive-patched-source.bbclass
--
1.8.3.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] grub git: workaround debugedit problems for 64 bit targets
On 01/15/2014 12:22 PM, Otavio Salvador wrote:
On Wed, Jan 15, 2014 at 8:15 AM, Koen Kooi koen.k...@linaro.org
mailto:koen.k...@linaro.org wrote:
I've limited it to 64bit targets, but to be honest debug splitting
doesn't make sense for grub since it won't run in your rootfs and
attaching gdb is pretty much impossible.
Signed-off-by: Koen Kooi koen.k...@linaro.org
mailto:koen.k...@linaro.org
I'd prefer to remove the debug systems than skip the split. What others
think?
I'm not sure what you mean by that, do you mean using
INHIBIT_PACKAGE_STRIP or something else?
regards,
Koen
---
meta/recipes-bsp/grub/grub_git.bb http://grub_git.bb | 5 +
1 file changed, 5 insertions(+)
diff --git a/meta/recipes-bsp/grub/grub_git.bb http://grub_git.bb
b/meta/recipes-bsp/grub/grub_git.bb http://grub_git.bb
index 1796e7f..bc79cfa 100644
--- a/meta/recipes-bsp/grub/grub_git.bb http://grub_git.bb
+++ b/meta/recipes-bsp/grub/grub_git.bb http://grub_git.bb
@@ -51,8 +51,13 @@ do_configure_prepend() {
do_install_append () {
install -d ${D}${sysconfdir}/grub.d
install -m 0755 ${WORKDIR}/40_custom
${D}${sysconfdir}/grub.d/40_custom
+
}
Please remove this.
+# debugedit chokes on 64 bit platforms
+INHIBIT_PACKAGE_DEBUG_SPLIT_aarch64 = 1
+INHIBIT_PACKAGE_DEBUG_SPLIT_x86-64 = 1
+
RDEPENDS_${PN} = diffutils freetype
FILES_${PN}-dbg += ${libdir}/${BPN}/*/.debug
--
1.8.4.2
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
mailto:Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
--
Koen Kooi
Builds and Baselines | Release Manager
Linaro.org | Open source software for ARM SoCs
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/5] refactor the archive*.bbcalss
On 01/16/2014 05:25 PM, Martin Jansa wrote:
On Thu, Jan 16, 2014 at 10:14:30AM +0800, Robert Yang wrote:
On 01/16/2014 12:55 AM, Martin Jansa wrote:
On Tue, Jan 14, 2014 at 12:20:14AM +0800, Robert Yang wrote:
* The archive*.bbclass didn't work, and there were a few problems, for
example:
1) There were a few duplicated code
2) There was no src_dir.org (or orig), but the diff command still use
it, and it is not easy to fix this issue if we don't change a lot
of the code.
3) It didn't archive the source for the native or gcc
4) The work flow is not very well
5) The subprocess.call('fakeroot cp ' should be removed
6) And others ...
* So that we have to refactor it, the benefits are:
1) Fix the problems and make it work well.
2) Reduce more than 400 lines in total.
3) Make it easy to use.
// Robert
The following changes since commit 1b636173ca88e5ccca1992f9a12367a1189fa674:
bitbake: toaster: Toaster GUI, generic search, filter and order (2014-01-10
15:20:26 +)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib rbt/archiver
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=rbt/archiver
Can you send pull-request for oe-core?
Here it is:
git://git.pokylinux.org/poky-contrib rbt/ar_oe
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=rbt/ar_oe
This still looks like poky-contrib (so it will download whole
poky-contrib when I add it as remote to oe-core repo).
Sorry, I can't create repo on oe-contrib, seems that I lost my key.
How about:
git fetch git://git.pokylinux.org/poky-contrib rbt/ar_oe
// Robert
// Robert
Robert Yang (5):
classes/archive*.bbclass: remove archive-*-source.bbclass
archiver.bbclass: refactor it
package_rpm.bbclass: archive the source to srpm package
archiver.bbclass: move a few code to copyleft_compliance.bbclass
local.conf.sample.extended: update for the archiver
meta-yocto/conf/local.conf.sample.extended | 72 +--
meta/classes/archive-configured-source.bbclass | 65 ---
meta/classes/archive-original-source.bbclass | 65 ---
meta/classes/archive-patched-source.bbclass| 65 ---
meta/classes/archiver.bbclass | 723
-
meta/classes/copyleft_compliance.bbclass | 55 +-
meta/classes/package_rpm.bbclass | 31 +-
7 files changed, 316 insertions(+), 760 deletions(-)
delete mode 100644 meta/classes/archive-configured-source.bbclass
delete mode 100644 meta/classes/archive-original-source.bbclass
delete mode 100644 meta/classes/archive-patched-source.bbclass
--
1.8.3.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/3] cmake: default to out-of-tree builds
Am 10.01.2014 18:54, schrieb Ross Burton:
Set B=${WORKDIR}/build in cmake.bbclass so that recipes using cmake.bbclass do
out-of-tree builds by default.
You should update the note to reflect the new behaviour.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] grub git: workaround debugedit problems for 64 bit targets
On Thu, Jan 16, 2014 at 7:27 AM, Koen Kooi koen.k...@linaro.org wrote: On 01/15/2014 12:22 PM, Otavio Salvador wrote: On Wed, Jan 15, 2014 at 8:15 AM, Koen Kooi koen.k...@linaro.org mailto:koen.k...@linaro.org wrote: I've limited it to 64bit targets, but to be honest debug splitting doesn't make sense for grub since it won't run in your rootfs and attaching gdb is pretty much impossible. Signed-off-by: Koen Kooi koen.k...@linaro.org mailto:koen.k...@linaro.org I'd prefer to remove the debug systems than skip the split. What others think? I'm not sure what you mean by that, do you mean using INHIBIT_PACKAGE_STRIP or something else? Yes and be sure it has been stripped during build. -- 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] grub git: workaround debugedit problems for 64 bit targets
Op 16 jan. 2014, om 11:38 heeft Otavio Salvador ota...@ossystems.com.br het volgende geschreven: On Thu, Jan 16, 2014 at 7:27 AM, Koen Kooi koen.k...@linaro.org wrote: On 01/15/2014 12:22 PM, Otavio Salvador wrote: On Wed, Jan 15, 2014 at 8:15 AM, Koen Kooi koen.k...@linaro.org mailto:koen.k...@linaro.org wrote: I've limited it to 64bit targets, but to be honest debug splitting doesn't make sense for grub since it won't run in your rootfs and attaching gdb is pretty much impossible. Signed-off-by: Koen Kooi koen.k...@linaro.org mailto:koen.k...@linaro.org I'd prefer to remove the debug systems than skip the split. What others think? I'm not sure what you mean by that, do you mean using INHIBIT_PACKAGE_STRIP or something else? Yes and be sure it has been stripped during build. That seems to be a lot more work for the same effect. Stripping isn't the problem, it's debugedit trying to do its magic that fails. regards, Koen ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] grub git: workaround debugedit problems for 64 bit targets
On Thu, Jan 16, 2014 at 8:46 AM, Koen Kooi koen.k...@linaro.org wrote: Op 16 jan. 2014, om 11:38 heeft Otavio Salvador ota...@ossystems.com.br het volgende geschreven: On Thu, Jan 16, 2014 at 7:27 AM, Koen Kooi koen.k...@linaro.org wrote: On 01/15/2014 12:22 PM, Otavio Salvador wrote: On Wed, Jan 15, 2014 at 8:15 AM, Koen Kooi koen.k...@linaro.org mailto:koen.k...@linaro.org wrote: I've limited it to 64bit targets, but to be honest debug splitting doesn't make sense for grub since it won't run in your rootfs and attaching gdb is pretty much impossible. Signed-off-by: Koen Kooi koen.k...@linaro.org mailto:koen.k...@linaro.org I'd prefer to remove the debug systems than skip the split. What others think? I'm not sure what you mean by that, do you mean using INHIBIT_PACKAGE_STRIP or something else? Yes and be sure it has been stripped during build. That seems to be a lot more work for the same effect. Stripping isn't the problem, it's debugedit trying to do its magic that fails. Well, if not stripped the symbols will be left in the binaries which is not expected. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] allarch.bbclass: set SDK_ARCH and SDK_CC_ARCH to none
allarch packages shouldn't use these variables.
[YOCTO #5396]
Signed-off-by: Laurentiu Palcu laurentiu.pa...@intel.com
---
meta/classes/allarch.bbclass |2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/classes/allarch.bbclass b/meta/classes/allarch.bbclass
index 5e13a5b..3ef1e9c 100644
--- a/meta/classes/allarch.bbclass
+++ b/meta/classes/allarch.bbclass
@@ -23,6 +23,8 @@ python () {
d.setVar(TARGET_LD_ARCH, none)
d.setVar(TARGET_AS_ARCH, none)
d.setVar(PACKAGE_EXTRA_ARCHS, )
+d.setVar(SDK_ARCH, none)
+d.setVar(SDK_CC_ARCH, none)
# No need to do shared library processing or debug symbol handling
d.setVar(EXCLUDE_FROM_SHLIBS, 1)
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/2] SDK build related fixes
The following changes since commit cea75f9c8c083d76ad8c45127be332665ef09d06: ltp: fix makefile race (2014-01-15 17:26:50 +) are available in the git repository at: git://git.yoctoproject.org/poky-contrib lpalcu/b5396_issue_switch_sdk_host http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=lpalcu/b5396_issue_switch_sdk_host Laurentiu Palcu (2): allarch.bbclass: set SDK_ARCH and SDK_CC_ARCH to none nativesdk-packagegroup-sdk-host: reverse inherit order meta/classes/allarch.bbclass |2 ++ .../nativesdk-packagegroup-sdk-host.bb |2 +- 2 files changed, 3 insertions(+), 1 deletion(-) -- 1.7.9.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] nativesdk-packagegroup-sdk-host: reverse inherit order
Currently, tow successive toolchain builds for different hosts, will issue a warning: WARNING: The recipe nativesdk-packagegroup-sdk-host is trying to install files into a shared area when those files already exist. Those files and their manifest location are: /ssd/work/yp1/build/tmp/deploy/ipk/all/nativesdk-packagegroup-sdk-host_1.0-r11_all.ipk Matched in manifest-x86_64-nativesdk-packagegroup-sdk-host.package_write_ipk Please verify which package should provide the above files. That's because packagegroup is manually inherited after nativesdk which is usually a BBCLASSEXTEND operation, done last. [YOCTO #5396] Signed-off-by: Laurentiu Palcu laurentiu.pa...@intel.com --- .../nativesdk-packagegroup-sdk-host.bb |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb b/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb index 9581ef3..1065f30 100644 --- a/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb +++ b/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb @@ -6,7 +6,7 @@ SUMMARY = Host packages for the standalone SDK or external toolchain PR = r11 LICENSE = MIT -inherit nativesdk packagegroup +inherit packagegroup nativesdk PACKAGEGROUP_DISABLE_COMPLEMENTARY = 1 -- 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] pulseaudio: rescale input being passed to float method of speex
It's also 10-50x slower on ARM, so always enabling float is a bad option. Just
patch it to work, no matter what upstream says :)
Seems I misunderstood the statement earlier. So to confirm, do you mean I
should submit patch here for original bug in Speex source code?
From: Koen Kooi [k...@dominion.thruhere.net]
Sent: Friday, January 10, 2014 8:33 PM
To: Arslan, Fahad
Cc: Saul Wold; openembedded-core@lists.openembedded.org; Marcin Juszkiewicz
Subject: Re: [OE-core] [PATCH] pulseaudio: rescale input being passed to float
method of speex
Op 10 jan. 2014, om 08:48 heeft Arslan, Fahad fahad_ars...@mentor.com het
volgende geschreven:
def get_speex_fpu_setting(bb, d):
if bb.data.getVar('TARGET_FPU', d, 1) in [ 'soft' ]:
return --enable-fixed-point --disable-float-api --disable-vbr
return
If we are using Pulseaudio with default settings (speex-float-1) and
the if condition in above method is evaluated true, we will end up facing
the original issue: streams that need to be resampled are not playedback
since input to speex is zeroed out when float input passed by Pulseaudio
in range of +/-1 is converted to int.
So isn't Case 2 appropriate, thoughts?
It's also 10-50x slower on ARM, so always enabling float is a bad option. Just
patch it to work, no matter what upstream says :)
Regards,
Fahad
From: Koen Kooi [k...@dominion.thruhere.net]
Sent: Tuesday, January 07, 2014 3:22 PM
To: Arslan, Fahad
Cc: Saul Wold; openembedded-core@lists.openembedded.org; mar...@juszkiewicz.pl
Subject: Re: [OE-core] [PATCH] pulseaudio: rescale input being passed to
float method of speex
Marcins linaro mail address has expired, adding the other one
Op 7 jan. 2014, om 11:03 heeft Koen Kooi k...@dominion.thruhere.net het
volgende geschreven:
Op 7 jan. 2014, om 10:59 heeft Arslan, Fahad fahad_ars...@mentor.com het
volgende geschreven:
What affect does it have on the overall size of speex
If we enable floating point support, there is decrease in size of libs.
libspeexdsp.so is ~480 KB in fixed point configuration
libspeexdsp.so is ~220 KB in floating point configuration
Further details are shown below:
Case-1 (current configuration)
==
EXTRA_OECONF = --enable-fixed-point
--with-ogg-libraries=${STAGING_LIBDIR} \
--disable-float-api --disable-vbr \
--with-ogg-includes=${STAGING_INCDIR} --disable-oggtest
build$
build$ ls -l src/.libs/speex*
-rwxr-xr-x 1 farslan farslan 75112 Jan 7 14:09 src/.libs/speexdec
-rwxr-xr-x 1 farslan farslan 76989 Jan 7 14:09 src/.libs/speexenc
build$ file src/.libs/speex*
src/.libs/speexdec: ELF 32-bit LSB executable, ARM, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.16, not stripped
src/.libs/speexenc: ELF 32-bit LSB executable, ARM, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.16, not stripped
build$
build$
build$ ls -l libspeex/.libs/libspeex*.so.1.5.0
-rwxr-xr-x 1 farslan farslan 484940 Jan 7 14:09
libspeex/.libs/libspeexdsp.so.1.5.0
-rwxr-xr-x 1 farslan farslan 370309 Jan 7 14:09
libspeex/.libs/libspeex.so.1.5.0
build$
build$ file libspeex/.libs/libspeex*.so.1.5.0
libspeex/.libs/libspeexdsp.so.1.5.0: ELF 32-bit LSB shared object, ARM,
version 1 (SYSV), dynamically linked, not stripped
libspeex/.libs/libspeex.so.1.5.0:ELF 32-bit LSB shared object, ARM,
version 1 (SYSV), dynamically linked, not stripped
build$
Case-2 (suggested configuration)
==
EXTRA_OECONF = --with-ogg-libraries=${STAGING_LIBDIR} \
--enable-float-api --disable-vbr \
--with-ogg-includes=${STAGING_INCDIR} --disable-oggtest
Or case 3, which I implemented 3 years ago in
https://github.com/openembedded/openembedded/commit/e06553979d23531397af3dd71870abb80718c681
:
def get_speex_fpu_setting(bb, d):
if bb.data.getVar('TARGET_FPU', d, 1) in [ 'soft' ]:
return --enable-fixed-point --disable-float-api --disable-vbr
return
EXTRA_OECONF += ${@get_speex_fpu_setting(bb, d)}
That OE-classic recipe also has support for arm asm which speed things up a
lot.
regards,
Koen
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] avahi + latest airplay release from apple
I'm attempting to use avahi (0.6.31) with the latest airplay release from apple. Is anyone else attempting the same thing ? There are some issues - avahi dns_sd.h is missing a few defines needed by airplay (patch attached) DNSServiceGetAddrInfo doesn't exist in avahi and is called from airplay avahi HEAD doesn't seem to implement this function either and there doesn't seem to have been much activity since the 0.6.31 release Any advice ? Thanks John fix-airplay-compile-errors.patch Description: Binary data ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] lib/oeqa: allow a layer to provide it's own TEST_TARGET class
Allows a layer to define new classes in layer/lib/oeqa/utils/controllers.py and completely control or extend deployment of a target. (core currently has QemuTarget and SimpleRemoteTarget). The value of TEST_TARGET must be the name of the new class. Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com --- meta/lib/oeqa/targetcontrol.py | 23 +++ meta/lib/oeqa/utils/__init__.py | 3 +++ 2 files changed, 22 insertions(+), 4 deletions(-) diff --git a/meta/lib/oeqa/targetcontrol.py b/meta/lib/oeqa/targetcontrol.py index dee38ec..757f9d3 100644 --- a/meta/lib/oeqa/targetcontrol.py +++ b/meta/lib/oeqa/targetcontrol.py @@ -8,18 +8,33 @@ import os import shutil import subprocess import bb - +import traceback from oeqa.utils.sshcontrol import SSHControl from oeqa.utils.qemurunner import QemuRunner def get_target_controller(d): -if d.getVar(TEST_TARGET, True) == qemu: +testtarget = d.getVar(TEST_TARGET, True) +# old, simple names +if testtarget == qemu: return QemuTarget(d) -elif d.getVar(TEST_TARGET, True) == simpleremote: +elif testtarget == simpleremote: return SimpleRemoteTarget(d) else: -bb.fatal(Please set a valid TEST_TARGET) +# use the class name +try: +# is it a core class defined here? +controller = getattr(__name__, testtarget) +except AttributeError: +# nope, perhaps a layer defined one +try: +module = __import__(oeqa.utils.controllers, globals(), locals(), [testtarget]) +controller = getattr(module, testtarget) +except ImportError as e: +bb.fatal(Failed to import oeqa.utils.controllers:\n%s % traceback.format_exc()) +except AttributeError: +bb.fatal(\%s\ is not a valid value for TEST_TARGET % testtarget) +return controller(d) class BaseTarget(object): diff --git a/meta/lib/oeqa/utils/__init__.py b/meta/lib/oeqa/utils/__init__.py index e69de29..8eda927 100644 --- a/meta/lib/oeqa/utils/__init__.py +++ b/meta/lib/oeqa/utils/__init__.py @@ -0,0 +1,3 @@ +# Enable other layers to have modules in the same named directory +from pkgutil import extend_path +__path__ = extend_path(__path__, __name__) -- 1.8.4.2 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/3] opkg: No longer PROVIDES update-alternatives
On 15 January 2014 22:37, Saul Wold s...@linux.intel.com wrote: On 01/15/2014 08:13 AM, Paul Barker wrote: On 15 January 2014 15:12, Saul Wold s...@linux.intel.com wrote: On 01/14/2014 06:17 PM, Paul Barker wrote: The new provider is the opkg-utils recipe. This seems to have triggered a failure on the AB: | Computing transaction...error: Can't install nativesdk-shadow-4.1.4.3-r13@i686_nativesdk: no package provides nativesdk-update-alternatives-opkg I've not really done much with nativesdk, but my guess is I just need to change BBCLASSEXTEND = native to BBCLASSEXTEND = native nativesdk in the opkg-utils recipe so that nativesdk-* packages are built for that recipe. Does that sound correct? If so, I'll re-spin the patches with that change. Yup, that's it, aslo why did you locate opkg-utils in a separate directory from opkgs itself? Is there a reason they can't co-locate? I've just modified the existing recipes, I haven't moved anything. They can probably be merged into one directory if that's beneficial. Cheers, -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] glib-2.0: fix mapped file ptest
The mappedfile ptest was attempting to write into directories that may not exist
on a non-Sato image. Instead, write into TMPDIR.
Signed-off-by: Ross Burton ross.bur...@intel.com
---
.../glib-2.0/glib-2.0/ptest-paths.patch| 30
meta/recipes-core/glib-2.0/glib-2.0_2.38.2.bb |1 +
2 files changed, 31 insertions(+)
create mode 100644 meta/recipes-core/glib-2.0/glib-2.0/ptest-paths.patch
diff --git a/meta/recipes-core/glib-2.0/glib-2.0/ptest-paths.patch
b/meta/recipes-core/glib-2.0/glib-2.0/ptest-paths.patch
new file mode 100644
index 000..f3be027
--- /dev/null
+++ b/meta/recipes-core/glib-2.0/glib-2.0/ptest-paths.patch
@@ -0,0 +1,30 @@
+Instead of writing the temporary mapping files in the mappedfile test to the
+user runtime directory, write them to $TMP. The runtime directory may not
+currently exist if the test is executed on a non-desktop system and the test
+doesn't attempt to create the directory structure.
+
+Upstream-Status: Pending
+Signed-off-by: Ross Burton ross.bur...@intel.com
+
+diff --git a/glib/tests/mappedfile.c b/glib/tests/mappedfile.c
+index 40e0e60..27a24be 100644
+--- a/glib/tests/mappedfile.c
b/glib/tests/mappedfile.c
+@@ -81,7 +81,7 @@ test_writable (void)
+ const gchar *new = abcdefghijklmnopqrstuvxyz;
+ gchar *tmp_copy_path;
+
+- tmp_copy_path = g_build_filename (g_get_user_runtime_dir (),
glib-test-4096-random-bytes, NULL);
++ tmp_copy_path = g_build_filename (g_get_tmp_dir (),
glib-test-4096-random-bytes, NULL);
+
+ g_file_get_contents (g_test_get_filename (G_TEST_DIST, 4096-random-bytes,
NULL), contents, len, error);
+ g_assert_no_error (error);
+@@ -125,7 +125,7 @@ test_writable_fd (void)
+ int fd;
+ gchar *tmp_copy_path;
+
+- tmp_copy_path = g_build_filename (g_get_user_runtime_dir (),
glib-test-4096-random-bytes, NULL);
++ tmp_copy_path = g_build_filename (g_get_tmp_dir (),
glib-test-4096-random-bytes, NULL);
+
+ g_file_get_contents (g_test_get_filename (G_TEST_DIST, 4096-random-bytes,
NULL), contents, len, error);
+ g_assert_no_error (error);
diff --git a/meta/recipes-core/glib-2.0/glib-2.0_2.38.2.bb
b/meta/recipes-core/glib-2.0/glib-2.0_2.38.2.bb
index a5bfc70..9745a9e 100644
--- a/meta/recipes-core/glib-2.0/glib-2.0_2.38.2.bb
+++ b/meta/recipes-core/glib-2.0/glib-2.0_2.38.2.bb
@@ -12,6 +12,7 @@ SRC_URI = ${GNOME_MIRROR}/glib/${SHRT_VER}/glib-${PV}.tar.xz
\
file://run-ptest \
file://0001-gio-Fix-Werror-format-string-errors-from-mismatched-.patch \
file://ptest-dbus.patch \
+ file://ptest-paths.patch \
SRC_URI_append_class-native = file://glib-gettextize-dir.patch
--
1.7.10.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] glib-2.0: fix the dbus-appinfo test when running outside of X
This test was attempting to connect to a session bus and hanging if it couldn't.
Take a patch from upstream to correctly use a private bus.
[ YOCTO #5696 ]
Signed-off-by: Ross Burton ross.bur...@intel.com
---
.../glib-2.0/glib-2.0/ptest-dbus.patch | 65
meta/recipes-core/glib-2.0/glib-2.0_2.38.2.bb |1 +
2 files changed, 66 insertions(+)
create mode 100644 meta/recipes-core/glib-2.0/glib-2.0/ptest-dbus.patch
diff --git a/meta/recipes-core/glib-2.0/glib-2.0/ptest-dbus.patch
b/meta/recipes-core/glib-2.0/glib-2.0/ptest-dbus.patch
new file mode 100644
index 000..0db8fd1
--- /dev/null
+++ b/meta/recipes-core/glib-2.0/glib-2.0/ptest-dbus.patch
@@ -0,0 +1,65 @@
+Fix dbus-appinfo from attempting to use the session's bus, and hanging if there
+isn't one present.
+
+Upstream-Status: Backport
+Signed-off-by: Ross Burton ross.bur...@intel.com
+
+From 940fa98290812789d095d93ff1c550cd86fb2428 Mon Sep 17 00:00:00 2001
+From: Xavier Claessens xavier.claess...@collabora.co.uk
+Date: Mon, 28 Oct 2013 21:18:54 +
+Subject: Tests: add session_bus_run() and use it where possible
+
+This is to avoid having again the subtil bug in dbus-appinfo.c:
+session_bus_down() was called before g_test_run() so the test was
+running on the user's dbus session.
+
+https://bugzilla.gnome.org/show_bug.cgi?id=697348
+---
+diff --git a/gio/tests/dbus-appinfo.c b/gio/tests/dbus-appinfo.c
+index ca11e98..7698429 100644
+--- a/gio/tests/dbus-appinfo.c
b/gio/tests/dbus-appinfo.c
+@@ -280,11 +280,7 @@ main (int argc, char **argv)
+ {
+ g_test_init (argc, argv, NULL);
+
+- session_bus_up ();
+-
+ g_test_add_func (/appinfo/dbusappinfo, test_dbus_appinfo);
+
+- session_bus_down ();
+-
+- return g_test_run ();
++ return session_bus_run ();
+ }
+diff --git a/gio/tests/gdbus-sessionbus.c b/gio/tests/gdbus-sessionbus.c
+index 68c4449..13c2edb 100644
+--- a/gio/tests/gdbus-sessionbus.c
b/gio/tests/gdbus-sessionbus.c
+@@ -47,3 +47,14 @@ session_bus_down (void)
+ g_clear_object (singleton);
+ }
+
++gint
++session_bus_run (void)
++{
++ gint ret;
++
++ session_bus_up ();
++ ret = g_test_run ();
++ session_bus_down ();
++
++ return ret;
++}
+diff --git a/gio/tests/gdbus-sessionbus.h b/gio/tests/gdbus-sessionbus.h
+index 7ef3abd..284cd00 100644
+--- a/gio/tests/gdbus-sessionbus.h
b/gio/tests/gdbus-sessionbus.h
+@@ -30,6 +30,7 @@ G_BEGIN_DECLS
+ void session_bus_up (void);
+ void session_bus_stop (void);
+ void session_bus_down (void);
++gint session_bus_run (void);
+
+ G_END_DECLS
+
diff --git a/meta/recipes-core/glib-2.0/glib-2.0_2.38.2.bb
b/meta/recipes-core/glib-2.0/glib-2.0_2.38.2.bb
index 02730f1..a5bfc70 100644
--- a/meta/recipes-core/glib-2.0/glib-2.0_2.38.2.bb
+++ b/meta/recipes-core/glib-2.0/glib-2.0_2.38.2.bb
@@ -11,6 +11,7 @@ SRC_URI = ${GNOME_MIRROR}/glib/${SHRT_VER}/glib-${PV}.tar.xz
\
file://glib-2.0-configure-readlink.patch \
file://run-ptest \
file://0001-gio-Fix-Werror-format-string-errors-from-mismatched-.patch \
+ file://ptest-dbus.patch \
SRC_URI_append_class-native = file://glib-gettextize-dir.patch
--
1.7.10.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] wpa-supplicant-2.0: don't exit in pkg_postinst
Exiting explicitly in pkg_postinst makes it impossible to use the
update-rc.d class in a .bbappend because the link creation is appended
to the pkg_postinst script.
Signed-off-by: Alexandre Belloni alexandre.bell...@free-electrons.com
---
meta/recipes-connectivity/wpa-supplicant/wpa-supplicant-2.0.inc | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant-2.0.inc
b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant-2.0.inc
index ce669a1ffa4f..ba28c6bd4528 100644
--- a/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant-2.0.inc
+++ b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant-2.0.inc
@@ -82,9 +82,8 @@ do_install () {
pkg_postinst_wpa-supplicant () {
# If we're offline, we don't need to do this.
- if [ x$D != x ]; then
- exit 0
+ if [ x$D = x ]; then
+ killall -q -HUP dbus-daemon || true
fi
- killall -q -HUP dbus-daemon || true
}
--
1.8.3.2
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] lib/oe/patch.py: Prefer git am over git apply when applying git patches
Hi everyone, the patch was sent about three weeks ago, and I have not seen any objections so far. What is the issue for progressing? Please let me know. Cheers, L. On Thu, Jan 9, 2014 at 4:53 PM, Laszlo Papp lp...@kde.org wrote: On Tue, Jan 7, 2014 at 12:16 PM, Koen Kooi k...@dominion.thruhere.net wrote: Op 6 jan. 2014, om 23:10 heeft Saul Wold s...@linux.intel.com het volgende geschreven: On 12/31/2013 06:18 AM, Laszlo Papp wrote: Ping? Alternatively, the system could also have an option for further fine-tuning what to do with git patches On Tue, Dec 24, 2013 at 12:44 PM, Laszlo Papp lp...@kde.org wrote: It is better to use git am when possible to preserve the commit messages and the mail format in general for patches when those are present. A typical use case is when developers would like to keep the changes on top of the latest upstream, and they may occasionally need to rebase. This is not possible with git diff and diff generated patches. Since this is not always the case, the fallback would be the git apply operation which is currently available. Looking at this, is it possible to detect a git patch and only then use git am? Since most of the patches carried in oe-core and other layers the 'git am' will typically fail All the patches I add are git am'able since I use a patch similar to this :) Cool. A big timesaver is to check for a .git/ in $WORKDIR otherwise git am will try to use a top level git tree (e.g. combo repo) and that's not what we want. Hmm, yeah, I agree. However, I do not have time currently for this, nor is this high-priority for me since it just works for me, and I am happy with that. Would it be possible to optimize it later? Failing that, what is the best practice to keep my changes separate from Yocto? I am referring to changes that are not upstreamed for whatever reason, like the maintainer saying that here it could be a performance regression (although non-measured at this point). Cheers ... ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] avahi + latest airplay release from apple
Hello, By Airplay released by Apple, are you referring to an SDK or something like that to build devices with Airplay (sinker) support? In my opinion, I think your question should be better directed to the avahi developers. Regards, Cristian Iorga YP Intel From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of John Stirling Sent: Thursday, January 16, 2014 2:46 PM To: openembedded-core@lists.openembedded.org Subject: [OE-core] avahi + latest airplay release from apple I'm attempting to use avahi (0.6.31) with the latest airplay release from apple. Is anyone else attempting the same thing ? There are some issues - avahi dns_sd.h is missing a few defines needed by airplay (patch attached) DNSServiceGetAddrInfo doesn't exist in avahi and is called from airplay avahi HEAD doesn't seem to implement this function either and there doesn't seem to have been much activity since the 0.6.31 release Any advice ? Thanks John ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] RFC: Maintain backwards compatibility or not for module-base.bbclass
Background: Back in September, Richard made a commit to
linux-libc-headers.inc describing why one should not fork the
linux-libc-headers recipe:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=babbf7a46acaefd9b36031483cafce053f607e66
As a result I created a local bbclass for our layer called
kernel-headers, which provides a recipe with kernel headers
that match the actually used version of the Linux kernel.
This was needed for packages that need to access hardware
specific features that are not present in the generic kernel
headers provided by linux-libc-headers.
My intention for this class was that it should be generic
enough to be able to upstream it to OE Core.
Now, the other day a colleague of mine had a build failure due
to this class. It turned out that even though the class adds a
dependency on virtual/kernel and then uses the files that are
installed to ${STAGING_KERNEL_DIR} when running oe_runmake
headers_install, the command could fail because the
${STAGING_KERNEL_DIR}/scripts was not populated. After asking
Richard about this, I learned that this is due to problems
with the sstate cache and not knowing whether a 32 bit host or
a 64 bit host was used to generate the files. Thus I also
learned that the scripts are actually built as a result of
building modules.
Since I did not want my class to depend on modules having been
built, I looked into modules.bbclass and modules-base.bbclass.
There I found the function do_make_scripts() which is
responsible for building the kernel scripts. However, the
current setup doesn't lend itself very well to use the
modules-base.bbclass for something other than modules.
My idea then was to break this part out into a separate class,
kernel-scripts, which I did. You can find both the
kernel-scripts and kernel-headers classes here:
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=pkj/kernel-headers
When I showed this to Richard he noted that my change was not
backwards compatible (as I no longer provide the
do_make_scripts() function from the module-base.bbclass).
However, there is nothing besides module.bbclass in OE Core
and meta-oe that use the module-base.bbclass.
Anyway, I made a modified version that does maintain backwards
compatibility for module-base.bbclass here:
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=pkj/kernel-headers-backwards-compatible
This time Richard complained about the extra class
(kernel-scripts-base.bbclass), and noted that there was no
way to win... He then suggested that I take the question of
whether we need to maintain backwards compatibility for
modules-base.bbclass to the mailing list.
So, here I am now. I do not know who else use the
do_make_scripts() function from module-base.bbclass and in what
way, and whether restructuring the functionality into the new
kernel-scripts.bbclass without maintaining backwards
compatibility would be a problem. If you know anything about
this, please let me know.
Any comments appreciated.
//Peter
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] x11vnc: fix CAPS_LOCK issues
The following changes since commit cea75f9c8c083d76ad8c45127be332665ef09d06: ltp: fix makefile race (2014-01-15 17:26:50 +) are available in the git repository at: git://git.yoctoproject.org/poky-contrib lpalcu/b4149_vnc_caps_lock http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=lpalcu/b4149_vnc_caps_lock Laurentiu Palcu (1): x11vnc: fix CAPS_LOCK issues .../x11vnc/files/starting-fix.patch|6 +- 1 file changed, 5 insertions(+), 1 deletion(-) -- 1.7.9.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] avahi + latest airplay release from apple
Yes, this is the airplay source release from apple that will allow us to support airplay on our devices. It needs a bonjour port but looks like avahi does not implement the full API required. I expect you're right - I will try the avahi lists as well. But if anyone is trying to do the same thing let me know. Thanks John On 16 January 2014 13:43, Iorga, Cristian cristian.io...@intel.com wrote: Hello, By Airplay released by Apple, are you referring to an SDK or something like that to build devices with Airplay (sinker) support? In my opinion, I think your question should be better directed to the avahi developers. Regards, Cristian Iorga YP Intel *From:* openembedded-core-boun...@lists.openembedded.org [mailto: openembedded-core-boun...@lists.openembedded.org] *On Behalf Of *John Stirling *Sent:* Thursday, January 16, 2014 2:46 PM *To:* openembedded-core@lists.openembedded.org *Subject:* [OE-core] avahi + latest airplay release from apple I'm attempting to use avahi (0.6.31) with the latest airplay release from apple. Is anyone else attempting the same thing ? There are some issues - avahi dns_sd.h is missing a few defines needed by airplay (patch attached) DNSServiceGetAddrInfo doesn't exist in avahi and is called from airplay avahi HEAD doesn't seem to implement this function either and there doesn't seem to have been much activity since the 0.6.31 release Any advice ? Thanks John ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 0/2] RFC: Implement deterministic uid/gid
On 1/9/14, 1:49 PM, Mark Hatle wrote: I have updated the git://git.yoctoproject.org/poky-contrib mhatle/uidgid to the latest oe-core master. I haven't seen any comments on this RFC yet. Does anyone have any opinion either way on the code referenced here? I'm confident patch 01/02 should be added to master. The patch 02/02 works properly in all of my testing and does implement support for 'deterministic uid/gid' with dynamic passwd/group file construction during package install. The code is only activated if USERADD_REWRITE_PARAMS is set to '1', so it's low risk -- but it does add a fairly large chunk of code to be maintained over time. I'm replying to myself on behalf of an external reviewer who is not on this mailing list. They identified one item that they would like to see: Looking at how to override the passwd fields, it seems like it's an 'all-or-nothing' scenario for each user? E.g., if you specify a passwd line for a user, all fields has to be set and will be overridden? Look at lines like 227 and 248-252 in the patched file (I looked at http://git.yoctoproject.org/cgit.cgi/poky-contrib/tree/meta/classes/useradd.bbclass?h=mhatle/uidgidid=21a7d772b9aee15d16ee8e29cb00a22e5fe21aac ). We've discussed the possibility to have this kind of scenario where we only want to e.g. override the default shell for the user (that is, not override uid, comment, etc). Is it maybe possible to e.g. add some kind of special marker to fields that should be discarded in the overridden file (like username:#:#:#:#:#:/bin/tcsh). That way we can automatically track upstream changes of the user but still override the shell. It should be pretty easy for me to generate a third commit that implements this type of functional. Does anyone have any opinions on a proper marker to indicate re-use the dynamic value? (I'd like to stay away from a blank, as there are valid reasons to set fields to blank. They're suggesting in the above a single '#' statement -- does this seem reasonable? --Mark --Mark On 12/10/13, 12:31 PM, Mark Hatle wrote: The following series implements the deterministic uid/gid setting for a distribution. Currently when a filesystem is generated the uid/gid values are generally set at install time, so the install order determines what the actual uid/gid values become. In order to create a deterministic uid/gid set, that still dynamically constructs the passwd/group file, we add an option to read a special passwd/group file to allow the system to determine the values. It uses the existing parameters, and the values from the special passwd/group files to reconstruct the parameter set to ensure these items are fully defined with static values. The first patch (01/02) is generally applicable. It fixes a real bug in the way the user/group adds occur today within the system. Patch 02/02 implements the new functionality. The following changes since commit 8505f0fa48cc79d51616b923c6e2c778c4b46a44: libmatchbox: use PACKAGECONFIG (2013-12-10 14:13:01 +) are available in the git repository at: git://git.yoctoproject.org/poky-contrib mhatle/uidgid http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=mhatle/uidgid Mark Hatle (2): useradd.bbclass: Fix build time install issues useradd.bbclass: Add ability to select a static uid/gid automatically meta/classes/useradd.bbclass | 247 ++- meta/conf/local.conf.sample.extended | 24 2 files changed, 265 insertions(+), 6 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
[OE-core] [PATCH v2 0/3] Change update-alternatives provider
The update-alternatives script has been copied from opkg to opkg-utils so the openembedded recipe for opkg-utils is updated accordingly. Changing the default provider of update-alternatives to opkg-utils allows dependencies to be added to the opkg recipe without causing circular dependency loops. This series partially solves Yocto Project issue 4836. Changes in v2: - Reordered variables in opkg-utils recipe - Added nativesdk class to opkg-utils Paul Barker (3): opkg-utils: Upgrade to latest git HEAD default-providers: Change update-alternatives provider to opkg-utils opkg: No longer PROVIDES update-alternatives meta/conf/distro/include/default-providers.inc | 6 +++--- meta/recipes-devtools/opkg-utils/opkg-utils_git.bb | 9 +++-- meta/recipes-devtools/opkg/opkg.inc| 12 +++- 3 files changed, 13 insertions(+), 14 deletions(-) -- 1.8.5.2 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 1/3] opkg-utils: Upgrade to latest git HEAD
The latest version of opkg-utils PROVIDES virtual/update-alternatives via a
script copied from opkg, packaged as update-alternatives-opkg.
The nativesdk class is added to the recipe to ensure that
nativesdk-update-alternatives-opkg is built.
Signed-off-by: Paul Barker p...@paulbarker.me.uk
---
meta/recipes-devtools/opkg-utils/opkg-utils_git.bb | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
b/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
index 714fc51..eb54a81 100644
--- a/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
+++ b/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
@@ -4,8 +4,9 @@ HOMEPAGE = http://code.google.com/p/opkg/;
LICENSE = GPLv2+
LIC_FILES_CHKSUM = file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
file://opkg.py;beginline=1;endline=18;md5=15917491ad6bf7acc666ca5f7cc1e083
+PROVIDES += virtual/update-alternatives
-SRCREV = 757a1664a440c60e8126443bf984e4bdf374c327
+SRCREV = fd4a3a4c20ada47b19e89849ddb6ff87904f01d2
PV = 0.1.8+git${SRCPV}
SRC_URI = git://git.yoctoproject.org/opkg-utils
@@ -21,7 +22,11 @@ do_install() {
# Avoid circular dependencies from package_ipk.bbclass
PACKAGES_class-native =
+PACKAGES =+ update-alternatives-opkg
+FILES_update-alternatives-opkg = ${bindir}/update-alternatives
+
RDEPENDS_${PN} = python python-shell python-io python-math python-crypt
python-logging python-fcntl python-subprocess python-pickle python-compression
python-textutils python-stringold
RDEPENDS_${PN}_class-native =
+RPROVIDES_update-alternatives-opkg = update-alternatives
-BBCLASSEXTEND = native
+BBCLASSEXTEND = native nativesdk
--
1.8.5.2
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 3/3] opkg: No longer PROVIDES update-alternatives
The new provider is the opkg-utils recipe.
Signed-off-by: Paul Barker p...@paulbarker.me.uk
---
meta/recipes-devtools/opkg/opkg.inc | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/meta/recipes-devtools/opkg/opkg.inc
b/meta/recipes-devtools/opkg/opkg.inc
index c9fb505..527fe5d 100644
--- a/meta/recipes-devtools/opkg/opkg.inc
+++ b/meta/recipes-devtools/opkg/opkg.inc
@@ -39,17 +39,13 @@ EXTRA_OECONF = \
--with-opkglibdir=${OPKGLIBDIR} \
-PROVIDES += virtual/update-alternatives
-RPROVIDES_update-alternatives-cworth += update-alternatives
-RCONFLICTS_update-alternatives-cworth = update-alternatives-dpkg
RDEPENDS_${PN} = ${VIRTUAL-RUNTIME_update-alternatives} opkg-config-base
RDEPENDS_${PN}_class-native =
RDEPENDS_${PN}_class-nativesdk =
RREPLACES_${PN} = opkg-nogpg
-PACKAGES =+ libopkg-dev libopkg-staticdev libopkg update-alternatives-cworth
+PACKAGES =+ libopkg-dev libopkg-staticdev libopkg
-FILES_update-alternatives-cworth = ${bindir}/update-alternatives
FILES_libopkg-dev = ${libdir}/*.la ${libdir}/*.so ${includedir}/libopkg
FILES_libopkg-staticdev = ${libdir}/*.a
FILES_libopkg = ${libdir}/*.so.* ${OPKGLIBDIR}/opkg/
@@ -74,10 +70,8 @@ do_install_append() {
ln -sf opkg-cl ${D}${bindir}/opkg
}
-do_install_append_class-native() {
- if [ ${PREFERRED_PROVIDER_virtual/update-alternatives-native} !=
${PN} ]; then
- rm ${D}${bindir}/update-alternatives
- fi
+do_install_append() {
+ rm ${D}${bindir}/update-alternatives
}
pkg_postinst_${PN} () {
--
1.8.5.2
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 2/3] default-providers: Change update-alternatives provider to opkg-utils
This allows dependencies to be added to the opkg recipe without causing circular dependency loops. As opkg-utils has minimal dependencies it is the best recipe to provide update-alternatives. This partially solves Yocto Project issue 4836. More work is still needed for a complete solution. Signed-off-by: Paul Barker p...@paulbarker.me.uk --- meta/conf/distro/include/default-providers.inc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/meta/conf/distro/include/default-providers.inc b/meta/conf/distro/include/default-providers.inc index e2b0892..419ffcd 100644 --- a/meta/conf/distro/include/default-providers.inc +++ b/meta/conf/distro/include/default-providers.inc @@ -10,15 +10,15 @@ PREFERRED_PROVIDER_virtual/libgl ?= mesa PREFERRED_PROVIDER_virtual/libgles1 ?= mesa PREFERRED_PROVIDER_virtual/libgles2 ?= mesa PREFERRED_PROVIDER_virtual/mesa ?= mesa -PREFERRED_PROVIDER_virtual/update-alternatives ?= opkg -PREFERRED_PROVIDER_virtual/update-alternatives-native ?= opkg-native +PREFERRED_PROVIDER_virtual/update-alternatives ?= opkg-utils +PREFERRED_PROVIDER_virtual/update-alternatives-native ?= opkg-utils-native PREFERRED_PROVIDER_virtual/libx11 ?= libx11 PREFERRED_PROVIDER_xf86-video-intel ?= xf86-video-intel # # Default virtual runtime providers # -VIRTUAL-RUNTIME_update-alternatives ?= update-alternatives-cworth +VIRTUAL-RUNTIME_update-alternatives ?= update-alternatives-opkg VIRTUAL-RUNTIME_apm ?= apm VIRTUAL-RUNTIME_alsa-state ?= alsa-state -- 1.8.5.2 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] weston: depend on drm for 'launch' packageconfig enabled
configure fails with: | configure:15654: checking for WESTON_LAUNCH | configure:15661: $PKG_CONFIG --exists --print-errors libdrm | Package libdrm was not found in the pkg-config search path. | Perhaps you should add the directory containing `libdrm.pc' | to the PKG_CONFIG_PATH environment variable | No package 'libdrm' found | configure:15664: $? = 1 | configure:15678: $PKG_CONFIG --exists --print-errors libdrm | Package libdrm was not found in the pkg-config search path. | Perhaps you should add the directory containing `libdrm.pc' | to the PKG_CONFIG_PATH environment variable | No package 'libdrm' found | configure:15681: $? = 1 | configure:15695: result: no | No package 'libdrm' found | configure:15711: error: Package requirements (libdrm) were not met: | | No package 'libdrm' found and configure.ac says: | if test x$enable_weston_launch == xyes; then | PKG_CHECK_MODULES(WESTON_LAUNCH, [libdrm]) Signed-off-by: Andreas Müller schnitzelt...@googlemail.com --- meta/recipes-graphics/wayland/weston_1.3.1.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-graphics/wayland/weston_1.3.1.bb b/meta/recipes-graphics/wayland/weston_1.3.1.bb index 8e555ee..585de66 100644 --- a/meta/recipes-graphics/wayland/weston_1.3.1.bb +++ b/meta/recipes-graphics/wayland/weston_1.3.1.bb @@ -47,7 +47,7 @@ PACKAGECONFIG[headless] = --enable-headless-compositor,--disable-headless-compo # Weston on framebuffer PACKAGECONFIG[fbdev] = --enable-fbdev-compositor,--disable-fbdev-compositor,udev mtdev # weston-launch -PACKAGECONFIG[launch] = --enable-weston-launch,--disable-weston-launch,libpam +PACKAGECONFIG[launch] = --enable-weston-launch,--disable-weston-launch,libpam drm # VA-API desktop recorder PACKAGECONFIG[vaapi] = --enable-vaapi-recorder,--disable-vaapi-recorder,libva -- 1.8.3.1 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: Maintain backwards compatibility or not for module-base.bbclass
On Thu, Jan 16, 2014 at 8:58 AM, Peter Kjellerstedt
peter.kjellerst...@axis.com wrote:
Background: Back in September, Richard made a commit to
linux-libc-headers.inc describing why one should not fork the
linux-libc-headers recipe:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=babbf7a46acaefd9b36031483cafce053f607e66
As a result I created a local bbclass for our layer called
kernel-headers, which provides a recipe with kernel headers
that match the actually used version of the Linux kernel.
This was needed for packages that need to access hardware
specific features that are not present in the generic kernel
headers provided by linux-libc-headers.
My intention for this class was that it should be generic
enough to be able to upstream it to OE Core.
Now, the other day a colleague of mine had a build failure due
to this class. It turned out that even though the class adds a
dependency on virtual/kernel and then uses the files that are
installed to ${STAGING_KERNEL_DIR} when running oe_runmake
headers_install, the command could fail because the
${STAGING_KERNEL_DIR}/scripts was not populated. After asking
Richard about this, I learned that this is due to problems
with the sstate cache and not knowing whether a 32 bit host or
a 64 bit host was used to generate the files. Thus I also
learned that the scripts are actually built as a result of
building modules.
Since I did not want my class to depend on modules having been
built, I looked into modules.bbclass and modules-base.bbclass.
There I found the function do_make_scripts() which is
responsible for building the kernel scripts. However, the
current setup doesn't lend itself very well to use the
modules-base.bbclass for something other than modules.
My idea then was to break this part out into a separate class,
kernel-scripts, which I did. You can find both the
kernel-scripts and kernel-headers classes here:
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=pkj/kernel-headers
When I showed this to Richard he noted that my change was not
backwards compatible (as I no longer provide the
do_make_scripts() function from the module-base.bbclass).
However, there is nothing besides module.bbclass in OE Core
and meta-oe that use the module-base.bbclass.
Anyway, I made a modified version that does maintain backwards
compatibility for module-base.bbclass here:
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=pkj/kernel-headers-backwards-compatible
This time Richard complained about the extra class
(kernel-scripts-base.bbclass), and noted that there was no
way to win... He then suggested that I take the question of
whether we need to maintain backwards compatibility for
modules-base.bbclass to the mailing list.
FWIW: I agree that have to many small, single purpose
kernel-*.bbclasses is a pain,
since it provides granularity, but more opportunity for varying behaviour during
kernel builds.
I have uses of the module-base.bbclass and an expectation that it will generate
the scripts, largely around the SDK and some custom kernel recipes. So they
only inherit module.bbclass, and would be impacted if that functionality was
changed to require another inherit.
Speaking of that, we through something like this late last year with
automatically
restoring the scripts into the sysroot, which ended up being reverted:
see b2c948d56241ff7cdea2e9e68b740f305c72f5ca in oe-core
At least the module (and your scripts) class avoid the sstate problems and
compiler dependencies that we hit with that solution.
What are the alternatives to more classes, isn't this something that could be
a .inc routine ? And modules simply includes it, and you can do the same ..
but I suppose a .inc versus a class inherit is largely semantics in
the difference.
bottom line, my rambling says that backwards compatibility matters here, and
that if we can avoid a new class, that would also be a good thing.
Cheers,
Bruce
So, here I am now. I do not know who else use the
do_make_scripts() function from module-base.bbclass and in what
way, and whether restructuring the functionality into the new
kernel-scripts.bbclass without maintaining backwards
compatibility would be a problem. If you know anything about
this, please let me know.
Any comments appreciated.
//Peter
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] pulseaudio: rescale input being passed to float method of speex
Op 16 jan. 2014, om 13:08 heeft Arslan, Fahad fahad_ars...@mentor.com het
volgende geschreven:
It's also 10-50x slower on ARM, so always enabling float is a bad option.
Just patch it to work, no matter what upstream says :)
Seems I misunderstood the statement earlier. So to confirm, do you mean I
should submit patch here for original bug in Speex source code?
Whatever allows us to use fixed-point mode on fpuless systems
From: Koen Kooi [k...@dominion.thruhere.net]
Sent: Friday, January 10, 2014 8:33 PM
To: Arslan, Fahad
Cc: Saul Wold; openembedded-core@lists.openembedded.org; Marcin Juszkiewicz
Subject: Re: [OE-core] [PATCH] pulseaudio: rescale input being passed to
float method of speex
Op 10 jan. 2014, om 08:48 heeft Arslan, Fahad fahad_ars...@mentor.com het
volgende geschreven:
def get_speex_fpu_setting(bb, d):
if bb.data.getVar('TARGET_FPU', d, 1) in [ 'soft' ]:
return --enable-fixed-point --disable-float-api --disable-vbr
return
If we are using Pulseaudio with default settings (speex-float-1) and
the if condition in above method is evaluated true, we will end up facing
the original issue: streams that need to be resampled are not playedback
since input to speex is zeroed out when float input passed by Pulseaudio
in range of +/-1 is converted to int.
So isn't Case 2 appropriate, thoughts?
It's also 10-50x slower on ARM, so always enabling float is a bad option.
Just patch it to work, no matter what upstream says :)
Regards,
Fahad
From: Koen Kooi [k...@dominion.thruhere.net]
Sent: Tuesday, January 07, 2014 3:22 PM
To: Arslan, Fahad
Cc: Saul Wold; openembedded-core@lists.openembedded.org;
mar...@juszkiewicz.pl
Subject: Re: [OE-core] [PATCH] pulseaudio: rescale input being passed to
float method of speex
Marcins linaro mail address has expired, adding the other one
Op 7 jan. 2014, om 11:03 heeft Koen Kooi k...@dominion.thruhere.net het
volgende geschreven:
Op 7 jan. 2014, om 10:59 heeft Arslan, Fahad fahad_ars...@mentor.com het
volgende geschreven:
What affect does it have on the overall size of speex
If we enable floating point support, there is decrease in size of libs.
libspeexdsp.so is ~480 KB in fixed point configuration
libspeexdsp.so is ~220 KB in floating point configuration
Further details are shown below:
Case-1 (current configuration)
==
EXTRA_OECONF = --enable-fixed-point
--with-ogg-libraries=${STAGING_LIBDIR} \
--disable-float-api --disable-vbr \
--with-ogg-includes=${STAGING_INCDIR} --disable-oggtest
build$
build$ ls -l src/.libs/speex*
-rwxr-xr-x 1 farslan farslan 75112 Jan 7 14:09 src/.libs/speexdec
-rwxr-xr-x 1 farslan farslan 76989 Jan 7 14:09 src/.libs/speexenc
build$ file src/.libs/speex*
src/.libs/speexdec: ELF 32-bit LSB executable, ARM, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.16, not stripped
src/.libs/speexenc: ELF 32-bit LSB executable, ARM, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.16, not stripped
build$
build$
build$ ls -l libspeex/.libs/libspeex*.so.1.5.0
-rwxr-xr-x 1 farslan farslan 484940 Jan 7 14:09
libspeex/.libs/libspeexdsp.so.1.5.0
-rwxr-xr-x 1 farslan farslan 370309 Jan 7 14:09
libspeex/.libs/libspeex.so.1.5.0
build$
build$ file libspeex/.libs/libspeex*.so.1.5.0
libspeex/.libs/libspeexdsp.so.1.5.0: ELF 32-bit LSB shared object, ARM,
version 1 (SYSV), dynamically linked, not stripped
libspeex/.libs/libspeex.so.1.5.0:ELF 32-bit LSB shared object, ARM,
version 1 (SYSV), dynamically linked, not stripped
build$
Case-2 (suggested configuration)
==
EXTRA_OECONF = --with-ogg-libraries=${STAGING_LIBDIR} \
--enable-float-api --disable-vbr \
--with-ogg-includes=${STAGING_INCDIR} --disable-oggtest
Or case 3, which I implemented 3 years ago in
https://github.com/openembedded/openembedded/commit/e06553979d23531397af3dd71870abb80718c681
:
def get_speex_fpu_setting(bb, d):
if bb.data.getVar('TARGET_FPU', d, 1) in [ 'soft' ]:
return --enable-fixed-point --disable-float-api --disable-vbr
return
EXTRA_OECONF += ${@get_speex_fpu_setting(bb, d)}
That OE-classic recipe also has support for arm asm which speed things up a
lot.
regards,
Koen
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: Maintain backwards compatibility or not for module-base.bbclass
Op 16 jan. 2014, om 14:58 heeft Peter Kjellerstedt
peter.kjellerst...@axis.com het volgende geschreven:
Background: Back in September, Richard made a commit to
linux-libc-headers.inc describing why one should not fork the
linux-libc-headers recipe:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=babbf7a46acaefd9b36031483cafce053f607e66
As a result I created a local bbclass for our layer called
kernel-headers, which provides a recipe with kernel headers
that match the actually used version of the Linux kernel.
This was needed for packages that need to access hardware
specific features that are not present in the generic kernel
headers provided by linux-libc-headers.
My intention for this class was that it should be generic
enough to be able to upstream it to OE Core.
Now, the other day a colleague of mine had a build failure due
to this class. It turned out that even though the class adds a
dependency on virtual/kernel and then uses the files that are
installed to ${STAGING_KERNEL_DIR} when running oe_runmake
headers_install, the command could fail because the
${STAGING_KERNEL_DIR}/scripts was not populated. After asking
Richard about this, I learned that this is due to problems
with the sstate cache and not knowing whether a 32 bit host or
a 64 bit host was used to generate the files. Thus I also
learned that the scripts are actually built as a result of
building modules.
Since I did not want my class to depend on modules having been
built, I looked into modules.bbclass and modules-base.bbclass.
There I found the function do_make_scripts() which is
responsible for building the kernel scripts. However, the
current setup doesn't lend itself very well to use the
modules-base.bbclass for something other than modules.
My idea then was to break this part out into a separate class,
kernel-scripts, which I did. You can find both the
kernel-scripts and kernel-headers classes here:
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=pkj/kernel-headers
When I showed this to Richard he noted that my change was not
backwards compatible (as I no longer provide the
do_make_scripts() function from the module-base.bbclass).
However, there is nothing besides module.bbclass in OE Core
and meta-oe that use the module-base.bbclass.
Can't do_make_script run as an sstate post function?
regards,
Koen
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] ** bug squashing weekend - Jan 17 to 20, 2014
Hopefully some of you have had the time to peruse the bugzilla database and have chosen a bug or two you'd like to quash this weekend. The bug hunt starts Friday Jan 16 and runs until Monday. If you're looking for more ideas there are some janitorial tasks outlined here: https://wiki.yoctoproject.org/wiki/Janitors ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: Maintain backwards compatibility or not for module-base.bbclass
On Thu, 2014-01-16 at 14:58 +0100, Peter Kjellerstedt wrote: So, here I am now. I do not know who else use the do_make_scripts() function from module-base.bbclass and in what way, and whether restructuring the functionality into the new kernel-scripts.bbclass without maintaining backwards compatibility would be a problem. If you know anything about this, please let me know. I'm not entirely clear why you couldn't maintain compatibility by moving the task in question to a new class but keeping its name the same (i.e. refrain from renaming do_make_scripts to do_kernel_scripts) and having module-base.bbclass simply inherit the newly-added class. That seems like it ought to be fairly straightforward and uncontroversial. That said, though, I don't think there is any pressing need to maintain backwards compatibility around module-base.bbclass. In fact, I think it would probably be fine for module-base.bbclass to simply go away altogether and have its functionality subsumed into module.bbclass; the split between those two classes is mostly a relic of yesteryear and I can't think of any good purpose that it serves nowadays. So I would be happy enough to see that (and the tangly mess that is the kernel classes in general) cleaned up irrespective of what happens with do_make_scripts. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] linux-yocto-dev: update to 3.13-rc8+
Richard/Saul, I've bumped the linux-yocto-dev kernel to 3.13-rcX, so it is worthwhile having the version of the recipe reflect that. I case anyone is wondering, I've built and booted all the reference boards with this -dev kernel (minimal and sato) and everything is in order for my tests. Other version bumps like libc-headers will follow in the future. Cheers, Bruce The following changes since commit cfd1520b4b492ab27b2900ba3510abe6f288097e: oe-selftest: separated the SStateBase and SStateTests in different modules (2014-01-16 12:18:52 +) are available in the git repository at: git://git.pokylinux.org/poky-contrib zedd/kernel http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel Bruce Ashfield (1): linux-yocto-dev: bump version to 3.13+ meta/recipes-kernel/linux/linux-yocto-dev.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 1.8.1.2 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] linux-yocto-dev: bump version to 3.13+
Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/recipes-kernel/linux/linux-yocto-dev.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb
b/meta/recipes-kernel/linux/linux-yocto-dev.bb
index e8d14b966d84..2b8c0556d0ed 100644
--- a/meta/recipes-kernel/linux/linux-yocto-dev.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-dev.bb
@@ -43,7 +43,7 @@ python () {
d.setVar(SRCREV_meta, ${AUTOREV})
}
-LINUX_VERSION ?= 3.10+
+LINUX_VERSION ?= 3.13+
LINUX_VERSION_EXTENSION ?= -yoctodev-${LINUX_KERNEL_TYPE}
PV = ${LINUX_VERSION}+git${SRCPV}
--
1.8.1.2
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] lib/oe: copyhardlinktree - detect mount points Add function getmount to detect the mount point of the path, as os.stat(path).st_dev in copyhardlinktree fails in lxc containers to det
Signed-off-by: Jason Plum jp...@devonit.com --- meta/lib/oe/path.py | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/meta/lib/oe/path.py b/meta/lib/oe/path.py index 1310e38..f1905c3 100644 --- a/meta/lib/oe/path.py +++ b/meta/lib/oe/path.py @@ -90,7 +90,7 @@ def copyhardlinktree(src, dst): if os.path.isdir(src) and not len(os.listdir(src)): return -if (os.stat(src).st_dev == os.stat(dst).st_dev): +if (getmount(src) == getmount(dst)): # Need to copy directories only with tar first since cp will error if two # writers try and create a directory at the same time cmd = 'cd %s; find . -type d -print | tar -cf - -C %s -p --files-from - | tar -xf - -C %s' % (src, src, dst) @@ -259,3 +259,12 @@ def realpath(file, root, use_physdir = True, loop_cnt = 100, assume_dir = False) raise return file + +def getmount(path): + Returns the mount point of the path, using realpath +path = realpath(path) +while path != os.path.sep: +if os.path.ismount(path): +return path +path = os.path.abspath(os.path.join(path, os.pardir)) +return path -- 1.8.5.2 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V2] tcl: Install header into 8.6 instead of PN-PV in user/include
On 01/16/2014 11:24 PM, Khem Raj wrote:
On Thu, Jan 16, 2014 at 12:42 AM, Robert Yang liezhi.y...@windriver.com wrote:
On 01/16/2014 04:31 PM, Robert Yang wrote:
On 11/12/2013 12:07 PM, 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.
+ # Directory in which to install the include file tcl.h:
+-INCLUDE_INSTALL_DIR= $(INSTALL_ROOT)$(includedir)
++INCLUDE_INSTALL_DIR= $(INSTALL_ROOT)$(includedir)/tcl$(VERSION)
+
Hi Khem,
I think that the tcl headers like tcl.h wass installed to:
/usr/include/tcl.h
with this patch, it will be installed:
/usr/include/tcl8.6/tcl.h
And what's worse is that some recipe like rrdtool may use:
#include tcl.h
will fail to, it has to use #include tcl8.6/tcl.h or something else
similar.
I think that we'd better change it back, I'd like to send a patch for this
if
you are fine with it.
from build aspect it might sound like that but you will have runtime problems
if you silently upgraded tcl many applications don't upgrade to newer
versions immediately. compile failures are easier to detect then
runtime
issues. But if all apps that we have use 8.6 right now and you are sure
that as you move to 8.7 all of them will work with it. I am fine with moving
it back to /usr/include
I just took it as an example, I won't upgrade it, the currently affected recipes
are expect which has used this:
--with-tclinclude=${STAGING_INCDIR}/tcl8.6
And the rrdtools from the meta-openembedded is failed since it uses:
#include tcl.h
, now it should be tcl8.6/tcl.h.
I looked at Fedora 19 and Ubuntu 13.04, while F19 puts in /usr/include/tcl.h,
and Ubuntu to /usr/include/tcl8.5/tcl.h, I think that Ubuntu does this because
it provides multi versions tcl (8.5 and 8.4), we only provide 8.6, according
to these, I think that we'd better put it to /usr/include/tcl.h
// Robert
// Robert
The problem is that, the tcl.h can't be found normally now, it breaks
the recipe which depends on tcl, the recipe which depends on tcl
has to use something like:
--with-tclinclude=${STAGING_INCDIR}/tcl8.6
once we upgrade the tcl to 8.7, then the recipe has to use:
--with-tclinclude=${STAGING_INCDIR}/tcl8.7
Seems that this is not good, can we change it back, please ?
// Robert
+ # Path to the private tcl header dir:
+ PRIVATE_INCLUDE_DIR= @PRIVATE_INCLUDE_DIR@
+Index: unix/configure.in
+===
+--- unix.orig/configure.in2013-11-11 01:00:36.467550403 -0800
unix/configure.in2013-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/configure2013-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.in2013-11-10 23:38:01.787425628 -0800
unix/Makefile.in2013-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
Re: [OE-core] unable to use bitbake -c populate_sdk core-image-minimal on dora
Hi Shane, Thanks for reporting this, I will try to figure it out. And Nicolas, I'm very sorry that I missed your email. // Robert On 01/15/2014 09:16 PM, Shane Volpe wrote: I believe I'm also having the same problem Nicolas has reported in this thread, here is my output: Issue 1: update-alternatives: Error: cannot register alternative opkg to /usr/local/oecore-i686/sysroots/i686-angstromsdk-linux/usr/bin/opkg since it is already registered to /usr/bin/opkg Issue 2: update-alternatives: Error: cannot register alternative passwd to /usr/local/oecore-i686/sysroots/i686-angstromsdk-linux/usr/bin/passwd since it is already registered to /usr/bin/passwd update-alternatives: Error: cannot register alternative chfn to /usr/local/oecore-i686/sysroots/i686-angstromsdk-linux/usr/bin/chfn since it is already registered to /usr/bin/chfn update-alternatives: Error: cannot register alternative newgrp to /usr/local/oecore-i686/sysroots/i686-angstromsdk-linux/usr/bin/newgrp since it is already registered to /usr/bin/newgrp update-alternatives: Error: cannot register alternative chsh to /usr/local/oecore-i686/sysroots/i686-angstromsdk-linux/usr/bin/chsh since it is already registered to /usr/bin/chsh update-alternatives: Error: cannot register alternative groups to /usr/local/oecore-i686/sysroots/i686-angstromsdk-linux/usr/bin/groups since it is already registered to /usr/bin/groups update-alternatives: Error: cannot register alternative chpasswd to /usr/local/oecore-i686/sysroots/i686-angstromsdk-linux/usr/sbin/chpasswd since it is already registered to /usr/sbin/chpasswd update-alternatives: Error: cannot register alternative login to /usr/local/oecore-i686/sysroots/i686-angstromsdk-linux/bin/login since it is already registered to /bin/login update-alternatives: Error: cannot register alternative vipw to /usr/local/oecore-i686/sysroots/i686-angstromsdk-linux/sbin/vipw since it is already registered to /sbin/vipw update-alternatives: Error: cannot register alternative vigr to /usr/local/oecore-i686/sysroots/i686-angstromsdk-linux/sbin/vigr since it is already registered to /sbin/vigr update-alternatives: Error: cannot register alternative su to /usr/local/oecore-i686/sysroots/i686-angstromsdk-linux/bin/su since it is already registered to /bin/su ___ 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 0/1 V2] sstate.bbclass: remove previous version's stamp
* V2: (Fix RP's comments) - Use STAMPCLEAN instead of STAMP - Respect to the extrainf // Robert The following changes since commit e81f2a5d7c45ad4056154d748cb28a00626e96a5: local.conf.sample.extended: update for the archiver (2014-01-16 15:33:42 +0800) are available in the git repository at: git://git.pokylinux.org/poky-contrib rbt/clean_stamp http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=rbt/clean_stamp Robert Yang (1): sstate.bbclass: remove previous version's stamp meta/classes/sstate.bbclass | 22 +- 1 file changed, 13 insertions(+), 9 deletions(-) -- 1.8.3.1 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] sstate.bbclass: remove previous version's stamp
There is a potential problem if we don't remove the previous version's
stamp, for example:
The depend chain is:
libtool-native - autoconf-native - m4-native
We have two m4-native: 1.4.9 and 1.4.7
1) Clean all of them to make a fresh build so that we can reproduce the
problem
$ bitbake m4-native autoconf-native libtool-native -ccleansstate
2) Build libtool-native so that the m4-native_1.4.17 will be built
$ bitbake libtool-native
3) Set PREFERRED_VERSION_m4-native = 1.4.9 and build again
$ bitbake libtool-native
4) Set PREFERRED_VERSION_m4-native = 1.4.17 and build again
$ bitbake libtool-native -ccleansstate bitbake libtool-native
Then the build will fail:
[snip]
| m4: unrecognized option '--gnu'
| Try `m4 --help' for more information.
| autom4te: m4 failed with exit status: 1
[snip]
The is because when we change m4-native to 1.4.17 and build
libtool-native again:
5) libtool-native depends on autoconf-native, and autoconf-native's
version isn't change, so it can remove the current stamp and mirror
the sstate (the one depends on m4-native_1.4.9) from the SSTATE_DIR
correctly.
6) The mirrored autoconf-native depends on m4-native_1.4.17's
do_populate_sysroot, and the stamp is already there (which is made
by step 2), so it would do nothing, but this is incorrect, since
the one that really in the sysroot is m4-native_1.4.9, then the
error happens.
Remove previous version's stamp in sstate_clean() will fix the problem.
[YOCTO #5422]
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
meta/classes/sstate.bbclass | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index 35c3f85..bad8b78 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -331,11 +331,18 @@ def sstate_clean_manifest(manifest, d):
def sstate_clean(ss, d):
import oe.path
+import glob
+import re
d2 = d.createCopy()
+stamp_clean = d.getVar(STAMPCLEAN, True)
extrainf = d.getVarFlag(do_ + ss['task'], 'stamp-extra-info', True)
if extrainf:
d2.setVar(SSTATE_MANMACH, extrainf)
+wildcard_stfile = %s.do_%s*.%s % (stamp_clean, ss['task'], extrainf)
+else:
+wildcard_stfile = %s.do_%s* % (stamp_clean, ss['task'])
+
manifest = d2.expand(${SSTATE_MANFILEPREFIX}.%s % ss['name'])
if os.path.exists(manifest):
@@ -350,15 +357,12 @@ def sstate_clean(ss, d):
for lock in locks:
bb.utils.unlockfile(lock)
-stfile = d.getVar(STAMP, True) + .do_ + ss['task']
-oe.path.remove(stfile)
-oe.path.remove(stfile + _setscene)
-if extrainf:
-oe.path.remove(stfile + .* + extrainf)
-oe.path.remove(stfile + _setscene + .* + extrainf)
-else:
-oe.path.remove(stfile + .*)
-oe.path.remove(stfile + _setscene + .*)
+# Remove the current and previous stamps, but keep the sigdata
+re_sigdata = .*\.do_%s\.sigdata\. % ss['task']
+for stfile in glob.glob(wildcard_stfile):
+# Keep the sigdata
+if not re.match(re_sigdata, stfile):
+oe.path.remove(stfile)
CLEANFUNCS += sstate_cleanall
--
1.8.3.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/5] dropbear: add systemd unit files
This patch mainly comes from meta-systemd with a few modifications.
The purpose is to get rid of the LSB init scripts in systemd images.
[YOCTO #4420]
Signed-off-by: Chen Qi qi.c...@windriver.com
---
meta/recipes-core/dropbear/dropbear.inc| 17 -
.../recipes-core/dropbear/dropbear/dropbear.socket | 10 ++
.../dropbear/dropbear/dropbear@.service| 11 +++
.../dropbear/dropbear/dropbearkey.service |8
4 files changed, 45 insertions(+), 1 deletion(-)
create mode 100644 meta/recipes-core/dropbear/dropbear/dropbear.socket
create mode 100644 meta/recipes-core/dropbear/dropbear/dropbear@.service
create mode 100644 meta/recipes-core/dropbear/dropbear/dropbearkey.service
diff --git a/meta/recipes-core/dropbear/dropbear.inc
b/meta/recipes-core/dropbear/dropbear.inc
index e85a9e6..d5fceec 100644
--- a/meta/recipes-core/dropbear/dropbear.inc
+++ b/meta/recipes-core/dropbear/dropbear.inc
@@ -19,17 +19,22 @@ SRC_URI =
http://matt.ucc.asn.au/dropbear/releases/dropbear-${PV}.tar.bz2 \
file://0004-fix-2kb-keys.patch \
file://0007-dropbear-fix-for-x32-abi.patch \
file://init \
+ file://dropbearkey.service \
+ file://dropbear@.service \
+ file://dropbear.socket \
${@base_contains('DISTRO_FEATURES', 'pam', '${PAM_SRC_URI}', '',
d)}
PAM_SRC_URI = file://0005-dropbear-enable-pam.patch \
file://0006-dropbear-configuration-file.patch \
file://dropbear
-inherit autotools update-rc.d
+inherit autotools update-rc.d systemd
INITSCRIPT_NAME = dropbear
INITSCRIPT_PARAMS = defaults 10
+SYSTEMD_SERVICE_${PN} = dropbear.socket
+
CFLAGS_prepend = -I.
LD = ${CC}
@@ -66,6 +71,16 @@ do_install() {
install -d ${D}${sysconfdir}/pam.d
install -m 0644 ${WORKDIR}/dropbear ${D}${sysconfdir}/pam.d/
fi
+
+ # deal with systemd unit files
+ install -d ${D}${systemd_unitdir}/system
+ install -m 0644 ${WORKDIR}/dropbearkey.service
${D}${systemd_unitdir}/system
+ install -m 0644 ${WORKDIR}/dropbear@.service
${D}${systemd_unitdir}/system
+ install -m 0644 ${WORKDIR}/dropbear.socket ${D}${systemd_unitdir}/system
+ sed -i -e 's,@BASE_BINDIR@,${base_bindir},g' \
+ -e 's,@BINDIR@,${bindir},g' \
+ -e 's,@SBINDIR@,${sbindir},g' \
+ ${D}${systemd_unitdir}/system/dropbear.socket
${D}${systemd_unitdir}/system/*.service
}
inherit update-alternatives
diff --git a/meta/recipes-core/dropbear/dropbear/dropbear.socket
b/meta/recipes-core/dropbear/dropbear/dropbear.socket
new file mode 100644
index 000..e5c61b7
--- /dev/null
+++ b/meta/recipes-core/dropbear/dropbear/dropbear.socket
@@ -0,0 +1,10 @@
+[Unit]
+Conflicts=dropbear.service
+
+[Socket]
+ListenStream=22
+Accept=yes
+
+[Install]
+WantedBy=sockets.target
+Also=dropbearkey.service
diff --git a/meta/recipes-core/dropbear/dropbear/dropbear@.service
b/meta/recipes-core/dropbear/dropbear/dropbear@.service
new file mode 100644
index 000..6fe9942
--- /dev/null
+++ b/meta/recipes-core/dropbear/dropbear/dropbear@.service
@@ -0,0 +1,11 @@
+[Unit]
+Description=SSH Per-Connection Server
+Wants=dropbearkey.service
+After=syslog.target dropbearkey.service
+
+[Service]
+EnvironmentFile=-/etc/default/dropbear
+ExecStart=-@SBINDIR@/dropbear -i -r /etc/dropbear/dropbear_rsa_host_key
$DROPBEAR_EXTRA_ARGS
+ExecReload=@BASE_BINDIR@/kill -HUP $MAINPID
+StandardInput=socket
+KillMode=process
diff --git a/meta/recipes-core/dropbear/dropbear/dropbearkey.service
b/meta/recipes-core/dropbear/dropbear/dropbearkey.service
new file mode 100644
index 000..ccc21d5
--- /dev/null
+++ b/meta/recipes-core/dropbear/dropbear/dropbearkey.service
@@ -0,0 +1,8 @@
+[Unit]
+Description=SSH Key Generation
+ConditionPathExists=|!/etc/dropbear/dropbear_rsa_host_key
+
+[Service]
+Type=oneshot
+ExecStart=@SBINDIR@/dropbearkey -t rsa -f /etc/dropbear/dropbear_rsa_host_key
+RemainAfterExit=yes
--
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/5] systemd: add 'less' to its RDEPENDS
The less command provided by busybox cannot interpret the control
character, resulting in obscure output of the journalctl command
in a systemd based image.
Add the 'less' package to systemd's RDEPENDS so that the output
of 'journalctl' looks clear to users.
[YOCTO #5723]
Signed-off-by: Chen Qi qi.c...@windriver.com
---
meta/recipes-core/systemd/systemd_208.bb |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-core/systemd/systemd_208.bb
b/meta/recipes-core/systemd/systemd_208.bb
index 6590235..3659abd 100644
--- a/meta/recipes-core/systemd/systemd_208.bb
+++ b/meta/recipes-core/systemd/systemd_208.bb
@@ -217,7 +217,8 @@ FILES_${PN} = ${base_bindir}/* \
FILES_${PN}-dbg += ${rootlibdir}/.debug ${systemd_unitdir}/.debug
${systemd_unitdir}/*/.debug ${base_libdir}/security/.debug/
FILES_${PN}-dev += ${base_libdir}/security/*.la ${datadir}/dbus-1/interfaces/
${sysconfdir}/rpm/macros.systemd
-RDEPENDS_${PN} += kmod dbus util-linux-mount
+# less package is needed to correctly display the contents of 'journalctl'
+RDEPENDS_${PN} += kmod dbus util-linux-mount less
RRECOMMENDS_${PN} += systemd-serialgetty systemd-compat-units \
util-linux-agetty \
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/5] distcc: add systemd support
Add systemd support for distcc.
These unit files mainly use the same files in Fedora 20 as a reference.
[YOCTO #4420]
Signed-off-by: Chen Qi qi.c...@windriver.com
---
meta/recipes-devtools/distcc/distcc_3.1.bb | 14 +++---
meta/recipes-devtools/distcc/files/default |5 +
meta/recipes-devtools/distcc/files/distccd.service | 11 +++
3 files changed, 27 insertions(+), 3 deletions(-)
create mode 100644 meta/recipes-devtools/distcc/files/distccd.service
diff --git a/meta/recipes-devtools/distcc/distcc_3.1.bb
b/meta/recipes-devtools/distcc/distcc_3.1.bb
index e351a58..c3cbd05 100644
--- a/meta/recipes-devtools/distcc/distcc_3.1.bb
+++ b/meta/recipes-devtools/distcc/distcc_3.1.bb
@@ -22,12 +22,13 @@ SRC_URI =
http://distcc.googlecode.com/files/${BPN}-${PV}.tar.bz2 \
file://separatebuilddir.patch \
file://default \
file://distccmon-gnome.desktop \
- file://distcc
+ file://distcc \
+ file://distccd.service
SRC_URI[md5sum] = a1a9d3853df7133669fffec2a9aab9f3
SRC_URI[sha256sum] =
f55dbafd76bed3ce57e1bbcdab1329227808890d90f4c724fcd2d53f934ddd89
-inherit autotools pkgconfig update-rc.d useradd
+inherit autotools pkgconfig update-rc.d useradd systemd
EXTRA_OECONF += --disable-Werror PYTHON=/dev/null
@@ -40,11 +41,17 @@ USERADD_PARAM_${PN} = --system \
INITSCRIPT_NAME = distcc
+SYSTEMD_PACKAGES = ${PN}
+SYSTEMD_SERVICE_${PN} = distccd.service
+
do_install_append() {
install -d ${D}${sysconfdir}/init.d/
install -d ${D}${sysconfdir}/default
install -m 0755 ${WORKDIR}/distcc ${D}${sysconfdir}/init.d/
install -m 0755 ${WORKDIR}/default ${D}${sysconfdir}/default/distcc
+install -d ${D}${systemd_unitdir}/system/
+install -m 0644 ${WORKDIR}/distccd.service ${D}${systemd_unitdir}/system
+sed -i -e 's,@BINDIR@,${bindir},g'
${D}${systemd_unitdir}/system/distccd.service
${DESKTOPINSTALL}
}
DESKTOPINSTALL =
@@ -58,7 +65,8 @@ FILES_${PN} = ${sysconfdir} \
${bindir}/distcc \
${bindir}/lsdistcc \
${bindir}/distccd \
- ${bindir}/distccmon-text
+ ${bindir}/distccmon-text \
+ ${systemd_unitdir}/system/distccd.service
FILES_distcc-distmon-gnome = ${bindir}/distccmon-gnome \
${datadir}/distcc
diff --git a/meta/recipes-devtools/distcc/files/default
b/meta/recipes-devtools/distcc/files/default
index 95290f8..63c4159 100644
--- a/meta/recipes-devtools/distcc/files/default
+++ b/meta/recipes-devtools/distcc/files/default
@@ -17,3 +17,8 @@ STARTDISTCC=true
# ALLOWEDNETS=127.0.0.1
ALLOWEDNETS=192.168.7.0/24
+
+#
+# OPTIONS is used for the systemd service file
+#
+OPTIONS=--allow 192.168.7.0/24
diff --git a/meta/recipes-devtools/distcc/files/distccd.service
b/meta/recipes-devtools/distcc/files/distccd.service
new file mode 100644
index 000..0253ddf
--- /dev/null
+++ b/meta/recipes-devtools/distcc/files/distccd.service
@@ -0,0 +1,11 @@
+[Unit]
+Description=Distccd A Distributed Compilation Server
+After=network.target
+
+[Service]
+User=distcc
+EnvironmentFile=-/etc/default/distcc
+ExecStart=@BINDIR@/distccd --verbose --no-detach --daemon $OPTIONS
+
+[Install]
+WantedBy=multi-user.target
--
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/5] systemd misc fixes
The following changes since commit cfd1520b4b492ab27b2900ba3510abe6f288097e: oe-selftest: separated the SStateBase and SStateTests in different modules (2014-01-16 12:18:52 +) are available in the git repository at: git://git.pokylinux.org/poky-contrib ChenQi/systemd-misc-fixes http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/systemd-misc-fixes Chen Qi (5): systemd: add 'less' to its RDEPENDS dropbear: add systemd unit files openssh: fixes for systemd distcc: add systemd support at: add systemd support .../openssh/openssh-6.4p1/sshd.socket |1 - .../openssh/openssh-6.4p1/sshd@.service|1 + .../openssh/openssh-6.4p1/sshdgenkeys.service |8 meta/recipes-connectivity/openssh/openssh_6.4p1.bb |4 ++-- meta/recipes-core/dropbear/dropbear.inc| 17 - .../recipes-core/dropbear/dropbear/dropbear.socket | 10 ++ .../dropbear/dropbear/dropbear@.service| 11 +++ .../dropbear/dropbear/dropbearkey.service |8 meta/recipes-core/systemd/systemd_208.bb |3 ++- meta/recipes-devtools/distcc/distcc_3.1.bb | 14 +++--- meta/recipes-devtools/distcc/files/default |5 + meta/recipes-devtools/distcc/files/distccd.service | 11 +++ meta/recipes-extended/at/at_3.1.14.bb | 10 +- meta/recipes-extended/at/files/atd.service |9 + 14 files changed, 99 insertions(+), 13 deletions(-) create mode 100644 meta/recipes-core/dropbear/dropbear/dropbear.socket create mode 100644 meta/recipes-core/dropbear/dropbear/dropbear@.service create mode 100644 meta/recipes-core/dropbear/dropbear/dropbearkey.service create mode 100644 meta/recipes-devtools/distcc/files/distccd.service create mode 100644 meta/recipes-extended/at/files/atd.service -- 1.7.9.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 5/5] at: add systemd support
Add systemd support for at.
This patch mainly comes from meta-systemd.
[YOCTO #4420]
Signed-off-by: Chen Qi qi.c...@windriver.com
---
meta/recipes-extended/at/at_3.1.14.bb | 10 +-
meta/recipes-extended/at/files/atd.service |9 +
2 files changed, 18 insertions(+), 1 deletion(-)
create mode 100644 meta/recipes-extended/at/files/atd.service
diff --git a/meta/recipes-extended/at/at_3.1.14.bb
b/meta/recipes-extended/at/at_3.1.14.bb
index 0a13157..480e732 100644
--- a/meta/recipes-extended/at/at_3.1.14.bb
+++ b/meta/recipes-extended/at/at_3.1.14.bb
@@ -22,6 +22,7 @@ SRC_URI = ${DEBIAN_MIRROR}/main/a/at/at_${PV}.orig.tar.gz \
file://posixtm.h \
file://file_replacement_with_gplv2.patch \
file://S99at \
+file://atd.service \
${@base_contains('DISTRO_FEATURES', 'pam', '${PAM_SRC_URI}', '', d)}
PAM_SRC_URI = file://pam.conf.patch \
@@ -37,7 +38,9 @@ EXTRA_OECONF += ac_cv_path_SENDMAIL=/bin/true \
--with-atspool=/var/spool/at/spool \
ac_cv_header_security_pam_appl_h=${@base_contains('DISTRO_FEATURES', 'pam',
'yes', 'no', d)}
-inherit autotools
+inherit autotools systemd
+
+SYSTEMD_SERVICE_${PN} = atd.service
PARALLEL_MAKE =
@@ -53,6 +56,11 @@ do_install () {
install -m 0755${WORKDIR}/S99at
${D}${sysconfdir}/init.d/atd
ln -sf ../init.d/atd ${D}${sysconfdir}/rcS.d/S99at
+ # install systemd unit files
+ install -d ${D}${systemd_unitdir}/system
+ install -m 0644 ${WORKDIR}/atd.service ${D}${systemd_unitdir}/system
+ sed -i -e 's,@SBINDIR@,${sbindir},g'
${D}${systemd_unitdir}/system/atd.service
+
if [ ${@base_contains('DISTRO_FEATURES', 'pam', 'pam', '', d)} =
pam ]; then
install -D -m 0644 ${WORKDIR}/${BP}/pam.conf
${D}${sysconfdir}/pam.d/atd
fi
diff --git a/meta/recipes-extended/at/files/atd.service
b/meta/recipes-extended/at/files/atd.service
new file mode 100644
index 000..6dc8445
--- /dev/null
+++ b/meta/recipes-extended/at/files/atd.service
@@ -0,0 +1,9 @@
+[Unit]
+Description=Job spooling tools
+After=syslog.target
+
+[Service]
+ExecStart=@SBINDIR@/atd -f
+
+[Install]
+WantedBy=multi-user.target
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/5] openssh: fixes for systemd
This patch contains a few fixes for the systemd unit files of openssh.
The fixes use the same unit files in Fedora 20 as a reference.
1) Remove sshdgenkeys.service and sshd@.service from SYSTEMD_SERVICE.
2) Fix the dependency and logic of sshdgenkeys.service.
Signed-off-by: Chen Qi qi.c...@windriver.com
---
.../openssh/openssh-6.4p1/sshd.socket |1 -
.../openssh/openssh-6.4p1/sshd@.service|1 +
.../openssh/openssh-6.4p1/sshdgenkeys.service |8
meta/recipes-connectivity/openssh/openssh_6.4p1.bb |4 ++--
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/meta/recipes-connectivity/openssh/openssh-6.4p1/sshd.socket
b/meta/recipes-connectivity/openssh/openssh-6.4p1/sshd.socket
index d19ab2a..12c39b2 100644
--- a/meta/recipes-connectivity/openssh/openssh-6.4p1/sshd.socket
+++ b/meta/recipes-connectivity/openssh/openssh-6.4p1/sshd.socket
@@ -8,4 +8,3 @@ Accept=yes
[Install]
WantedBy=sockets.target
-Also=sshdgenkeys.service
diff --git a/meta/recipes-connectivity/openssh/openssh-6.4p1/sshd@.service
b/meta/recipes-connectivity/openssh/openssh-6.4p1/sshd@.service
index 64e009f..4eda659 100644
--- a/meta/recipes-connectivity/openssh/openssh-6.4p1/sshd@.service
+++ b/meta/recipes-connectivity/openssh/openssh-6.4p1/sshd@.service
@@ -1,5 +1,6 @@
[Unit]
Description=OpenSSH Per-Connection Daemon
+Wants=sshdgenkeys.service
After=sshdgenkeys.service
[Service]
diff --git
a/meta/recipes-connectivity/openssh/openssh-6.4p1/sshdgenkeys.service
b/meta/recipes-connectivity/openssh/openssh-6.4p1/sshdgenkeys.service
index 2fd8a9a..c21d70b 100644
--- a/meta/recipes-connectivity/openssh/openssh-6.4p1/sshdgenkeys.service
+++ b/meta/recipes-connectivity/openssh/openssh-6.4p1/sshdgenkeys.service
@@ -1,10 +1,10 @@
[Unit]
-Description=SSH Key Generation
+Description=OpenSSH Key Generation
+ConditionPathExists=|!/etc/ssh/ssh_host_rsa_key
+ConditionPathExists=|!/etc/ssh/ssh_host_dsa_key
+ConditionPathExists=|!/etc/ssh/ssh_host_ecdsa_key
[Service]
ExecStart=@BINDIR@/ssh-keygen -A
Type=oneshot
RemainAfterExit=yes
-
-[Install]
-WantedBy=multi-user.target
diff --git a/meta/recipes-connectivity/openssh/openssh_6.4p1.bb
b/meta/recipes-connectivity/openssh/openssh_6.4p1.bb
index c61d16f..1f78566 100644
--- a/meta/recipes-connectivity/openssh/openssh_6.4p1.bb
+++ b/meta/recipes-connectivity/openssh/openssh_6.4p1.bb
@@ -44,7 +44,7 @@ INITSCRIPT_NAME_${PN}-sshd = sshd
INITSCRIPT_PARAMS_${PN}-sshd = defaults 9
SYSTEMD_PACKAGES = ${PN}-sshd
-SYSTEMD_SERVICE_${PN}-sshd = sshd.socket sshd@.service sshdgenkeys.service
+SYSTEMD_SERVICE_${PN}-sshd = sshd.socket
PACKAGECONFIG ??= tcp-wrappers
PACKAGECONFIG[tcp-wrappers] = --with-tcp-wrappers,,tcp-wrappers
@@ -114,7 +114,7 @@ ALLOW_EMPTY_${PN} = 1
PACKAGES =+ ${PN}-keygen ${PN}-scp ${PN}-ssh ${PN}-sshd ${PN}-sftp ${PN}-misc
${PN}-sftp-server
FILES_${PN}-scp = ${bindir}/scp.${BPN}
FILES_${PN}-ssh = ${bindir}/ssh.${BPN} ${sysconfdir}/ssh/ssh_config
-FILES_${PN}-sshd = ${sbindir}/sshd ${sysconfdir}/init.d/sshd
+FILES_${PN}-sshd = ${sbindir}/sshd ${sysconfdir}/init.d/sshd
${systemd_unitdir}/system
FILES_${PN}-sshd += ${sysconfdir}/ssh/moduli ${sysconfdir}/ssh/sshd_config
${sysconfdir}/ssh/sshd_config_readonly ${sysconfdir}/default/volatiles/99_sshd
FILES_${PN}-sftp = ${bindir}/sftp
FILES_${PN}-sftp-server = ${libexecdir}/sftp-server
--
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 V2] tcl: Install header into 8.6 instead of PN-PV in user/include
On 01/17/2014 10:28 AM, Robert Yang wrote:
On 01/16/2014 11:24 PM, Khem Raj wrote:
On Thu, Jan 16, 2014 at 12:42 AM, Robert Yang liezhi.y...@windriver.com wrote:
On 01/16/2014 04:31 PM, Robert Yang wrote:
On 11/12/2013 12:07 PM, 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.
+ # Directory in which to install the include file tcl.h:
+-INCLUDE_INSTALL_DIR= $(INSTALL_ROOT)$(includedir)
++INCLUDE_INSTALL_DIR= $(INSTALL_ROOT)$(includedir)/tcl$(VERSION)
+
Hi Khem,
I think that the tcl headers like tcl.h wass installed to:
/usr/include/tcl.h
with this patch, it will be installed:
/usr/include/tcl8.6/tcl.h
And what's worse is that some recipe like rrdtool may use:
#include tcl.h
will fail to, it has to use #include tcl8.6/tcl.h or something else
similar.
I think that we'd better change it back, I'd like to send a patch for this
if
you are fine with it.
from build aspect it might sound like that but you will have runtime problems
if you silently upgraded tcl many applications don't upgrade to newer
versions immediately. compile failures are easier to detect then
runtime
issues. But if all apps that we have use 8.6 right now and you are sure
that as you move to 8.7 all of them will work with it. I am fine with moving
it back to /usr/include
I just took it as an example, I won't upgrade it, the currently affected recipes
are expect which has used this:
--with-tclinclude=${STAGING_INCDIR}/tcl8.6
And the rrdtools from the meta-openembedded is failed since it uses:
#include tcl.h
, now it should be tcl8.6/tcl.h.
I looked at Fedora 19 and Ubuntu 13.04, while F19 puts in /usr/include/tcl.h,
and Ubuntu to /usr/include/tcl8.5/tcl.h, I think that Ubuntu does this because
it provides multi versions tcl (8.5 and 8.4), we only provide 8.6, according
to these, I think that we'd better put it to /usr/include/tcl.h
Hi Khem,
I'd like to fix TCL_INCLUDE_SPEC rather than change it back since
meta-openembedded had removed the tcl from rrdtools, and otherwise we need do
more testing.
I will send a patch to fix the TCL_INCLUDE_SPEC sooner.
// Robert
// Robert
// Robert
The problem is that, the tcl.h can't be found normally now, it breaks
the recipe which depends on tcl, the recipe which depends on tcl
has to use something like:
--with-tclinclude=${STAGING_INCDIR}/tcl8.6
once we upgrade the tcl to 8.7, then the recipe has to use:
--with-tclinclude=${STAGING_INCDIR}/tcl8.7
Seems that this is not good, can we change it back, please ?
// Robert
+ # Path to the private tcl header dir:
+ PRIVATE_INCLUDE_DIR= @PRIVATE_INCLUDE_DIR@
+Index: unix/configure.in
+===
+--- unix.orig/configure.in2013-11-11 01:00:36.467550403 -0800
unix/configure.in2013-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/configure2013-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.in2013-11-10 23:38:01.787425628 -0800
unix/Makefile.in2013-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
