[OE-core] [PATCH v2] ptest.bblass: Fix package QA issues when disabled
When the ptest distro feature is disabled, a ptest directory is still
created in the install phase, This directory is not cleaned up or
consumed by any package and will throw a QA error, e.g.
ERROR: QA Issue: glib-2.0: Files/directories were installed but not
shipped
/usr/lib/glib-2.0/ptest
ERROR: QA run found fatal errors. Please consider fixing them.
ERROR: Function failed: do_package_qa
This is caused by the do_install_ptest_base[cleandirs] attribute which
is not setup to be conditional on ptest being enabled.
This patch refactors the use of PTEST_ENABLED in the *ptest_base tasks,
replacing the conditional execution with the removal of the tasks from
the build, this prevents any part (including cleandirs) of the ptest
tasks from executing when disabled.
Signed-off-by: Nathan Rossi
---
meta/classes/ptest.bbclass | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/meta/classes/ptest.bbclass b/meta/classes/ptest.bbclass
index ec10f80..e5bbb89 100644
--- a/meta/classes/ptest.bbclass
+++ b/meta/classes/ptest.bbclass
@@ -18,9 +18,7 @@ do_configure_ptest() {
}
do_configure_ptest_base() {
-if [ ${PTEST_ENABLED} = 1 ]; then
-do_configure_ptest
-fi
+do_configure_ptest
}
do_compile_ptest() {
@@ -28,9 +26,7 @@ do_compile_ptest() {
}
do_compile_ptest_base() {
-if [ ${PTEST_ENABLED} = 1 ]; then
-do_compile_ptest
-fi
+do_compile_ptest
}
do_install_ptest() {
@@ -38,14 +34,12 @@ do_install_ptest() {
}
do_install_ptest_base() {
-if [ ${PTEST_ENABLED} = 1 ]; then
-if [ -f ${WORKDIR}/run-ptest ]; then
-install -D ${WORKDIR}/run-ptest ${D}${PTEST_PATH}/run-ptest
-if grep -q install-ptest: Makefile; then
-oe_runmake DESTDIR=${D}${PTEST_PATH} install-ptest
-fi
-do_install_ptest
+if [ -f ${WORKDIR}/run-ptest ]; then
+install -D ${WORKDIR}/run-ptest ${D}${PTEST_PATH}/run-ptest
+if grep -q install-ptest: Makefile; then
+oe_runmake DESTDIR=${D}${PTEST_PATH} install-ptest
fi
+do_install_ptest
fi
}
@@ -58,4 +52,9 @@ addtask install_ptest_base after do_install before
do_package do_populate_sy
python () {
if not bb.data.inherits_class('native', d) and not
bb.data.inherits_class('cross', d):
d.setVarFlag('do_install_ptest_base', 'fakeroot', 1)
+
+# Remove all '*ptest_base' tasks when ptest is not enabled
+if not(d.getVar('PTEST_ENABLED', True) == "1"):
+for i in filter(lambda k: d.getVarFlag(k, "task") and
k.endswith("ptest_base"), d.keys()):
+bb.build.deltask(i, d)
}
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] grub: add PACKAGECONFIG for device-mapper
Avoids it's auto-detected from sysroot, which will lead implicit results. Signed-off-by: Ming Liu --- meta/recipes-bsp/grub/grub_2.00.bb |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/meta/recipes-bsp/grub/grub_2.00.bb b/meta/recipes-bsp/grub/grub_2.00.bb index 84e6193..ff9a7c6 100644 --- a/meta/recipes-bsp/grub/grub_2.00.bb +++ b/meta/recipes-bsp/grub/grub_2.00.bb @@ -37,6 +37,7 @@ inherit gettext PACKAGECONFIG ??= "" PACKAGECONFIG[grub-mount] = "--enable-grub-mount,--disable-grub-mount,fuse" +PACKAGECONFIG[device-mapper] = "--enable-device-mapper,--disable-device-mapper,lvm2" EXTRA_OECONF = "--with-platform=pc --disable-grub-mkfont --program-prefix="" \ --enable-liblzma=no --enable-device-mapper=no --enable-libzfs=no" -- 1.7.1 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] acl: enable ptest support
Install acl test suite and run it as ptest.
nfs test cases need depend on nfs service. So exclude them order to
make ptest all pass.
Signed-off-by: Chong Lu
---
meta/recipes-support/attr/acl.inc | 15 +-
.../attr/acl/acl-make-ptest-pass.patch | 457 +
meta/recipes-support/attr/acl/run-ptest| 5 +
3 files changed, 476 insertions(+), 1 deletion(-)
create mode 100644 meta/recipes-support/attr/acl/acl-make-ptest-pass.patch
create mode 100644 meta/recipes-support/attr/acl/run-ptest
diff --git a/meta/recipes-support/attr/acl.inc
b/meta/recipes-support/attr/acl.inc
index a461232..4bacf80 100644
--- a/meta/recipes-support/attr/acl.inc
+++ b/meta/recipes-support/attr/acl.inc
@@ -9,7 +9,10 @@ LIC_FILES_CHKSUM =
"file://doc/COPYING;md5=c781d70ed2b4d48995b790403217a249 \
file://doc/COPYING.LGPL;md5=9e9a206917f8af112da634ce3ab41764"
DEPENDS = "attr"
-SRC_URI = "http://download.savannah.gnu.org/releases/acl/${BP}.src.tar.gz";
+SRC_URI = "http://download.savannah.gnu.org/releases/acl/${BP}.src.tar.gz \
+ file://acl-make-ptest-pass.patch \
+ file://run-ptest \
+"
require ea-acl.inc
@@ -24,3 +27,13 @@ do_install_append() {
sed -i ${D}${libdir}/libacl.la -e \
s,^libdir=\'${base_libdir}\'$,libdir=\'${libdir}\',
}
+
+inherit ptest
+
+do_install_ptest() {
+ tar -cf - test/ --exclude nfs | ( cd ${D}${PTEST_PATH} && tar -xf - )
+ mkdir ${D}${PTEST_PATH}/include
+ cp ${S}/include/builddefs ${S}/include/buildmacros
${S}/include/buildrules ${D}${PTEST_PATH}/include/
+}
+
+RDEPENDS_${PN}-ptest = "coreutils perl-module-filehandle
perl-module-getopt-std perl-module-posix"
diff --git a/meta/recipes-support/attr/acl/acl-make-ptest-pass.patch
b/meta/recipes-support/attr/acl/acl-make-ptest-pass.patch
new file mode 100644
index 000..89c03c2
--- /dev/null
+++ b/meta/recipes-support/attr/acl/acl-make-ptest-pass.patch
@@ -0,0 +1,457 @@
+acl: make ptest pass
+
+Upstream-Status: Inappropriate [embedded specific]
+
+The daemon user must be a member in the bin group, else permissions.test
+will fail. So add daemon user to bin group.
+Many results of `ls' are incorrect in some test cases, modify them to make
+ptest pass.
+
+Signed-off-by: Chong Lu
+---
+ test/Makefile |2 +-
+ test/cp.test |8 ++---
+ test/misc.test | 86 ++--
+ test/root/permissions.test |2 +-
+ test/root/setfacl.test |2 +-
+ test/sbits-restore.test|6 ++--
+ 6 files changed, 53 insertions(+), 53 deletions(-)
+
+diff --git a/test/Makefile b/test/Makefile
+index d2baac8..6063a56 100644
+--- a/test/Makefile
b/test/Makefile
+@@ -42,7 +42,7 @@ $(NFS):
+ @echo "NFS specific tests"; echo "*** $@ ***"; perl run $@
+
+ $(ROOT):
+- @echo "Note: Tests must run as root"; echo "*** $@ ***"; perl run $@
++ @echo "Note: Tests must run as root"; echo "*** $@ ***"; usermod -G bin
daemon; perl run $@
+
+ .PHONY: $(TESTS) $(NFS) $(ROOT)
+ .NOTPARALLEL:
+diff --git a/test/cp.test b/test/cp.test
+index 0867f63..54bee3b 100644
+--- a/test/cp.test
b/test/cp.test
+@@ -6,16 +6,16 @@ The cp utility should only copy ACLs if `-p' is given.
+ $ touch f
+ $ setfacl -m u:bin:rw f
+ $ ls -l f | awk -- '{ print $1 }'
+- > -rw-rw-r--+
++ > -rw-rw-r--
+
+ $ cp f g
+- $ ls -l g | awk -- '{ print $1 }' | sed 's/\.$//g'
++ $ ls -l g | awk -- '{ print $1 }'
+ > -rw-r--r--
+
+ $ rm g
+ $ cp -p f g
+ $ ls -l f | awk -- '{ print $1 }'
+- > -rw-rw-r--+
++ > -rw-rw-r--
+
+ $ mkdir h
+ $ echo blubb > h/x
+@@ -33,7 +33,7 @@ The cp utility should only copy ACLs if `-p' is given.
+ > other::r--
+ >
+
+- $ cp -rp h i
++ $ cp -a h i
+ $ getfacl --omit-header i/x
+ > user::rw-
+ > user:bin:rwx
+diff --git a/test/misc.test b/test/misc.test
+index 6e98053..83080e2 100644
+--- a/test/misc.test
b/test/misc.test
+@@ -11,7 +11,7 @@ Only change a base ACL:
+ $ setfacl -m u::r f
+ $ setfacl -m u::rw,u:bin:rw f
+ $ ls -dl f | awk '{print $1}'
+- > -rw-rw+
++ > -rw-rw
+
+ $ getfacl --omit-header f
+ > user::rw-
+@@ -26,7 +26,7 @@ Only change a base ACL:
+ $ touch f
+ $ setfacl -m u:bin:rw f
+ $ ls -dl f | awk '{print $1}'
+- > -rw-rw-r--+
++ > -rw-rw-r--
+
+ $ getfacl --omit-header f
+ > user::rw-
+@@ -41,7 +41,7 @@ Only change a base ACL:
+ $ mkdir d
+ $ setfacl -m u:bin:rwx d
+ $ ls -dl d | awk '{print $1}'
+- > drwxrwx---+
++ > drwxrwx---
+
+ $ getfacl --omit-header d
+ > user::rwx
+@@ -56,7 +56,7 @@ Only change a base ACL:
+ $ mkdir d
+ $ setfacl -m u:bin:rwx d
+ $ ls -dl d | awk '{print $1}'
+- > drwxrwxr-x+
++ > drwxrwx
[OE-core] [PATCH 0/1] acl: enable ptest support
The following changes since commit 6ee5d95317de77c1cfb6db6f1ab2de77f5fa085e: bitbake: fetch2/gitannex: Fix function arguments to match bitbake master (2014-01-08 15:27:37 +) are available in the git repository at: git://git.pokylinux.org/poky-contrib chonglu/acl http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=chonglu/acl Chong Lu (1): acl: enable ptest support meta/recipes-support/attr/acl.inc | 15 +- .../attr/acl/acl-make-ptest-pass.patch | 457 + meta/recipes-support/attr/acl/run-ptest| 5 + 3 files changed, 476 insertions(+), 1 deletion(-) create mode 100644 meta/recipes-support/attr/acl/acl-make-ptest-pass.patch create mode 100644 meta/recipes-support/attr/acl/run-ptest -- 1.8.1.2 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [QA Issue] liblto found in wrong location
WARNING: QA Issue: gcc-cross-canadian-i586: found library in wrong location: /opt/cbnl/oecore-sdk/1/sysroots/i686-oecore-linux/usr/libexec/i586-oe-linux/gcc/i586-oe-linux/4.8.2/liblto_plugin.so.0 gcc-cross-canadian-i586: found library in wrong location: /opt/cbnl/oecore-sdk/1/sysroots/i686-oecore-linux/usr/libexec/i586-oe-linux/gcc/i586-oe-linux/4.8.2/liblto_plugin.so.0.0.0 gcc-cross-canadian-i586: found library in wrong location: /opt/cbnl/oecore-sdk/1/sysroots/i686-oecore-linux/usr/libexec/i586-oe-linux/gcc/i586-oe-linux/4.8.2/liblto_plugin.so It seems like the library is being found in an installed SDK on my host? I have no idea where to start with this, the gcc-target.inc specifies it in FILES, but apart from that I can't find any reference to it, maybe due it being a core GCC lib? -- Jack Mitchell (j...@embed.me.uk) Embedded Systems Engineer Cambridgeshire, UK http://www.embed.me.uk -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [dora][PATCH 0/2] Dora backports
On Fri, 2014-01-10 at 14:18 +0800, Robert Yang wrote: > Hi Martin, > > Thanks, please see my comments in line. > > On 01/06/2014 06:21 PM, Martin Jansa wrote: > > The following changes since commit e86622a932bbd0acdea67ecfb15c8b06c27353d8: > > > >libsoup-2.4: add intltool-native to DEPENDS (2013-12-19 14:59:47 +) > > > > are available in the git repository at: > > > >git://git.openembedded.org/openembedded-core-contrib > > jansa/dora-backports2 > > > > http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=jansa/dora-backports2 > > > > Martin Jansa (1): > >ltp: set PREFERRED_PROVIDER and rename runtests_noltp.sh script > > > > I will take this. > > > Richard Purdie (1): > >eglibc-initial.inc: Drop duplicate include > > > > > It seems that this is a trivial fix, I don't think it's a good idea to merge > it to dora. Thanks to one of the bitbake patches we backported, this "trivial" issue is now putting warnings in peoples builds so I think it might be a good idea to fix it. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [dora][PATCH 0/2] Dora backports
On Fri, Jan 10, 2014 at 02:18:51PM +0800, Robert Yang wrote: > > Hi Martin, > > Thanks, please see my comments in line. > > On 01/06/2014 06:21 PM, Martin Jansa wrote: > > The following changes since commit e86622a932bbd0acdea67ecfb15c8b06c27353d8: > > > >libsoup-2.4: add intltool-native to DEPENDS (2013-12-19 14:59:47 +) > > > > are available in the git repository at: > > > >git://git.openembedded.org/openembedded-core-contrib > > jansa/dora-backports2 > > > > http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=jansa/dora-backports2 > > > > Martin Jansa (1): > >ltp: set PREFERRED_PROVIDER and rename runtests_noltp.sh script > > > > I will take this. > > > Richard Purdie (1): > >eglibc-initial.inc: Drop duplicate include > > > > > It seems that this is a trivial fix, I don't think it's a good idea to merge > it to dora. And the warning shown in every dora build since http://git.openembedded.org/bitbake/commit/?h=1.20&id=22e6b1c4c4afb27057689bbc94cbdf1f19f93e3d isn't important enough reason to merge it? > > // Robert > > > meta/conf/distro/include/default-providers.inc | 2 + > > meta/recipes-core/eglibc/eglibc-initial.inc| 2 - > > ...tests_noltp.sh-script-so-have-unique-name.patch | 202 > > + > > meta/recipes-extended/ltp/ltp_20130503.bb | 4 +- > > 4 files changed, 207 insertions(+), 3 deletions(-) > > create mode 100644 > > meta/recipes-extended/ltp/ltp/0001-Rename-runtests_noltp.sh-script-so-have-unique-name.patch > > -- 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] libsoup: Remove libproxy from DEPENDS
On Thu, 2014-01-09 at 12:10 -0200, Otavio Salvador wrote: > On Thu, Jan 9, 2014 at 9:16 AM, Phil Blundell wrote: > > Although libsoup did use to support direct usage of libproxy, > it hasn't > done so for some time. Worse, if libsoup depends on libproxy > then it > is impossible to build libproxy against webkit since webkit > itself > depends on libsoup in some configurations. Fix this by > removing the > extraneous entry from DEPENDS. > > Signed-off-by: Phil Blundell > > > > Does it need a --disable-libproxy or so? No. See the (old) NEWS: Changes in libsoup from 2.33.90 to 2.33.92: * LIBSOUP NO LONGER DEPENDS ON GCONF OR LIBPROXY. (see below). * Updated SoupProxyResolverGNOME to be based on SoupProxyResolverDefault, but explicitly requesting the "gnome" GProxyResolver if it is available [#625898], and removed the old code that used GConf and libproxy directly. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] db compile failure
On 8 January 2014 14:18, Jack Mitchell wrote: > On 08/01/14 14:16, Jack Mitchell wrote: >> On latest master I am running into the following failure: >> >> http://ix.io/9Kh > > This should be the following link: > > http://ix.io/9Ki > I'm hitting the same error building poky at master for raspberrypi, it's just worded slightly differently: | /usr/lib/libstdc++.so: file not recognized: File format not recognized I can't see a '-L/usr/lib' argument anywhere but something seems to be causing the linker to look at my host system's libraries. Running 'bitbake db -c cleansstate' then 'bitbake db' again hits the same error. Any ideas? -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-commits] Richard Purdie : cross-canadian: Handle powerpc linux verses linux-gnuspe
On 2013-11-01 18:49, g...@git.openembedded.org wrote:
Module: openembedded-core.git
Branch: master-next
Commit: a1d6331238982b0c5d39b0a18794f6654b00d46a
URL:
http://git.openembedded.org/?p=openembedded-core.git&a=commit;h=a1d6331238982b0c5d39b0a18794f6654b00d46a
Author: Richard Purdie
Date: Thu Oct 17 12:22:35 2013 +0100
cross-canadian: Handle powerpc linux verses linux-gnuspe
PowerPC toolchains can use the OS "linux" or "linux-gnuspe". This
patch links them together so the one cross-canadian toolchain can support
both.
GCC_FOR_TARGET is set for the GCC recipe as otherwise configure
can pick up an incorrect value.
[YOCTO #5354]
Signed-off-by: Richard Purdie
Signed-off-by: Saul Wold
--- a/meta/classes/cross-canadian.bbclass
+++ b/meta/classes/cross-canadian.bbclass
@@ -15,12 +15,30 @@ STAGING_BINDIR_TOOLCHAIN =
"${STAGING_DIR_NATIVE}${bindir_native}/${SDK_ARCH}${S
# Update BASE_PACKAGE_ARCH and PACKAGE_ARCHS
#
PACKAGE_ARCH = "${SDK_ARCH}-${SDKPKGSUFFIX}"
+CANADIANEXTRAOS = ""
python () {
archs = d.getVar('PACKAGE_ARCHS', True).split()
sdkarchs = []
for arch in archs:
sdkarchs.append(arch + '-${SDKPKGSUFFIX}')
d.setVar('PACKAGE_ARCHS', " ".join(sdkarchs))
+
+# PowerPC can build "linux" and "linux-gnuspe"
+tarch = d.getVar("TARGET_ARCH", True)
+if tarch == "powerpc":
+tos = d.getVar("TARGET_OS", True)
+if (tos != "linux" and tos != "linux-gnuspe"):
+bb.fatal("Building cross-candian powerpc for an unknown TARGET_SYS (%s), please
update cross-canadian.bbclass" % d.getVar("TARGET_SYS", True))
+# Have to expand DEPENDS before we change the extensions
+d.setVar("DEPENDS", d.getVar("DEPENDS", True))
+d.setVar("STAGING_BINDIR_TOOLCHAIN",
d.getVar("STAGING_BINDIR_TOOLCHAIN", True))
+for prefix in ["AR", "AS", "DLLTOOL", "CC", "CXX", "GCC", "LD", "LIPO", "NM", "OBJDUMP",
"RANLIB", "STRIP", "WINDRES"]:
+n = prefix + "_FOR_TARGET"
+d.setVar(n, d.getVar(n, True))
+
+d.setVar("LIBCEXTENSION", "")
+d.setVar("ABIEXTENSION", "")
+d.setVar("CANADIANEXTRAOS", "linux-gnuspe")
}
Hi,
I believe this commit is the cause of some problems I'm seeing with ppc
SDK toolchain tarballs on poky master.
1. Looks like the relocation scripts fails for environments:
~/tests/poky [master]
$ cat /opt/oel/2014-01-01/environment-setup-ppce500v2-oel-linux | grep "#"
export SDKTARGETSYSROOT=##SDKTARGETSYSROOT##
~/tests/poky [master]
$ cat /opt/oel/2014-01-01/environment-setup-ppce500v2-oel-linux-gnuspe |
grep "#"
2. SDK gnuspe compiler does not allow -mabi=spe
ABIEXTENSION is zeroed both for linux-gnuspe and linux
3. Compiler can't create executables.
I think this is due to libgcc_s.so from the SDK target sysroot is in
mabi=spe.
4. -mspe is included in CC var for both linux and gnuspe.
cat /opt/oel/2014-01-01/environment-setup-ppce500v2-oel-linux | grep mabi
export CC="powerpc-oel-linux-gcc -m32 -mcpu=8548 -mabi=spe -mspe
-mfloat-gprs=double --sysroot=$SDKTARGETSYSROOT"
export CXX="powerpc-oel-linux-g++ -m32 -mcpu=8548 -mabi=spe -mspe
-mfloat-gprs=double --sysroot=$SDKTARGETSYSROOT"
export CPP="powerpc-oel-linux-gcc -E -m32 -mcpu=8548 -mabi=spe -mspe
-mfloat-gprs=double --sysroot=$SDKTARGETSYSROOT"
Seems to work in dora though,
Any thoughts on this ?
Br,
David
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] binutils: Also add autoconf-native to DEPENDS
Commit 616354f13732d13c17434d5b60b166f691c25761 is insufficient because
gnu-config-native's gnu-configize script uses perl modules from autoconf
and hence doesn't work unless autoconf-native is staged (which it may
not be if building from sstate).
Ideally g-c-n would itself declare a dependency on autoconf-native but this
is difficult to arrange without creating a dependency loop. autoconf-native
already depends on gnu-config-native (because autoreconf invokes gnu-configize)
and has a build dependency on m4-native, which in turn build-depends on g-c-n
because it configizes itself by steam in do_configure and needs
config.{guess,sub}
to be available. Adding some sort of gnu-config-initial-native recipe would
fix the latter problem, but this would be ugly because it would need
special-casing
in (at least) autotools.bbclass, and in any case this still wouldn't solve
the problem of autoconf itself depending on g-c-n.
So, the easiest solution to the problem at hand is to arrange for those
few recipes that depend on g-c-n but not autoconf-native to gain that
latter dependency as well.
Signed-off-by: Phil Blundell
---
meta/recipes-devtools/binutils/binutils.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/binutils/binutils.inc
b/meta/recipes-devtools/binutils/binutils.inc
index 1259342..b6c9205 100644
--- a/meta/recipes-devtools/binutils/binutils.inc
+++ b/meta/recipes-devtools/binutils/binutils.inc
@@ -11,7 +11,7 @@ BUGTRACKER = "http://sourceware.org/bugzilla/";
SECTION = "devel"
LICENSE = "GPLv3"
-DEPENDS = "flex-native bison-native zlib-native gnu-config-native"
+DEPENDS = "flex-native bison-native zlib-native gnu-config-native
autoconf-native"
inherit autotools gettext multilib_header
--
1.8.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] kernel-module-split: Remove extraneous call to depmod from module postinst
During rootfs construction, image.bbclass will call depmod after all the
modules are installed. There's no need to run it from the postinst when
operating in offline root mode.
Signed-off-by: Phil Blundell
---
meta/classes/kernel-module-split.bbclass | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta/classes/kernel-module-split.bbclass
b/meta/classes/kernel-module-split.bbclass
index 83d9a8f..97b61a0 100644
--- a/meta/classes/kernel-module-split.bbclass
+++ b/meta/classes/kernel-module-split.bbclass
@@ -2,7 +2,9 @@ pkg_postinst_modules () {
if [ -z "$D" ]; then
depmod -a ${KERNEL_VERSION}
else
- depmodwrapper -a -b $D ${KERNEL_VERSION}
+ # image.bbclass will call depmodwrapper after everything is installed,
+ # no need to do it here as well
+ :
fi
}
--
1.8.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] unmaintained layers
> > Hi everyone, > > At the last TSC meeting the topic of unmaintained layers came up. Here > is the sorted list of master layers from the layer index [1], would it > be possible for those in the know to indicate which layers are, or are > suspected of being, unmaintained? > > > > meta-hipos > > is maintained. Mario ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] unmaintained layers
On Thursday 09 January 2014 13:45:23 Trevor Woerner wrote: > At the last TSC meeting the topic of unmaintained layers came up. Here > is the sorted list of master layers from the layer index [1], would it > be possible for those in the know to indicate which layers are, or are > suspected of being, unmaintained? This is all very interesting with people piping up that their layers are maintained, but I'm not sure it helps solve the overall problem. We have some immediate issues with patches to particular layers going unmerged. That's in the process of being resolved. However, looking to the future it was suggested at the TSC meeting it would be nice to have some kind of measure or indication for the layer (ideally in the layer index) as to how well-maintained it is. Is there a practical and objective measurement we can have about the layer's maintenance status? I don't have a good idea of what this would actually mean - how many outstanding patches it has? How recently it has been built/tested? Also, if it does appear that a layer has gone "unmaintained" by popular consensus, what should actually be done about it? Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] package: Keep global pkgfiles[] up to date when snapping library symlinks
Since ca86603607a69a17cc5540d69de0e242b33382d3 we are now calling stat() on
all the pkgfiles[] during emit_pkgdata(). If symlink snapping has removed
some of the files then we will blow up trying to stat a path that no longer
exists. Fix that by ensuring that pkgfiles[] is updated when we process the
list of library renames.
Signed-off-by: Phil Blundell
---
meta/classes/package.bbclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index 08b78db..726a84f 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -1474,6 +1474,8 @@ python package_do_shlibs() {
for (old, new) in renames:
bb.note("Renaming %s to %s" % (old, new))
os.rename(old, new)
+pkgfiles[pkg].remove(old)
+
shlibs_file = os.path.join(shlibswork_dir, pkg + ".list")
shver_file = os.path.join(shlibswork_dir, pkg + ".ver")
if len(sonames):
--
1.8.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] Revert "cross-canadian: Handle powerpc linux verses linux-gnuspe"
The reverted commit seems to introduce some problems for the toolchain tarball
for powerpc.
I see this both in master and on dora.
1. Looks like the relocation scripts fails for environments:
~/tests/poky [master]
$ cat /opt/oel/2014-01-01/environment-setup-ppce500v2-oel-linux | grep "#"
export SDKTARGETSYSROOT=##SDKTARGETSYSROOT##
~/tests/poky [master]
$ cat /opt/oel/2014-01-01/environment-setup-ppce500v2-oel-linux-gnuspe | grep
"#"
2. nativeSDK gnuspe compiler does not allow -mabi=spe
ABIEXTENSION is zeroed both for linux-gnuspe and linux
3. Compiler can't create executables.
I think this is due to libgcc_s.so from the SDK target sysroot is in mabi=spe.
4. -mspe is included in CC var for both linux and gnuspe.
cat /opt/oel/2014-01-01/environment-setup-ppce500v2-oel-linux | grep mabi
export CC="powerpc-oel-linux-gcc -m32 -mcpu=8548 -mabi=spe -mspe
export CXX="powerpc-oel-linux-g++ -m32 -mcpu=8548 -mabi=spe -mspe
export CPP="powerpc-oel-linux-gcc -E -m32 -mcpu=8548 -mabi=spe -mspe
With the commit reverted, I can successfully build target code with the
canadian compiler
from the SDK tarball. Only the gnuspe environment file is generated.
This reverts commit 11d9127ac57514394f8297f9fdfc7b31e163fcb8.
---
meta/classes/cross-canadian.bbclass| 31 --
.../binutils/binutils-cross-canadian.inc | 2 --
meta/recipes-devtools/gcc/gcc-cross-canadian.inc | 5 +---
meta/recipes-devtools/gdb/gdb-cross-canadian.inc | 1 -
4 files changed, 1 insertion(+), 38 deletions(-)
diff --git a/meta/classes/cross-canadian.bbclass
b/meta/classes/cross-canadian.bbclass
index c974212..7181c60 100644
--- a/meta/classes/cross-canadian.bbclass
+++ b/meta/classes/cross-canadian.bbclass
@@ -15,30 +15,12 @@ STAGING_BINDIR_TOOLCHAIN =
"${STAGING_DIR_NATIVE}${bindir_native}/${SDK_ARCH}${S
# Update BASE_PACKAGE_ARCH and PACKAGE_ARCHS
#
PACKAGE_ARCH = "${SDK_ARCH}-${SDKPKGSUFFIX}"
-CANADIANEXTRAOS = ""
python () {
archs = d.getVar('PACKAGE_ARCHS', True).split()
sdkarchs = []
for arch in archs:
sdkarchs.append(arch + '-${SDKPKGSUFFIX}')
d.setVar('PACKAGE_ARCHS', " ".join(sdkarchs))
-
-# PowerPC can build "linux" and "linux-gnuspe"
-tarch = d.getVar("TARGET_ARCH", True)
-if tarch == "powerpc":
-tos = d.getVar("TARGET_OS", True)
-if (tos != "linux" and tos != "linux-gnuspe"):
-bb.fatal("Building cross-candian powerpc for an unknown TARGET_SYS
(%s), please update cross-canadian.bbclass" % d.getVar("TARGET_SYS", True))
-# Have to expand DEPENDS before we change the extensions
-d.setVar("DEPENDS", d.getVar("DEPENDS", True))
-d.setVar("STAGING_BINDIR_TOOLCHAIN",
d.getVar("STAGING_BINDIR_TOOLCHAIN", True))
-for prefix in ["AR", "AS", "DLLTOOL", "CC", "CXX", "GCC", "LD",
"LIPO", "NM", "OBJDUMP", "RANLIB", "STRIP", "WINDRES"]:
-n = prefix + "_FOR_TARGET"
-d.setVar(n, d.getVar(n, True))
-
-d.setVar("LIBCEXTENSION", "")
-d.setVar("ABIEXTENSION", "")
-d.setVar("CANADIANEXTRAOS", "linux-gnuspe")
}
MULTIMACH_TARGET_SYS = "${PACKAGE_ARCH}${HOST_VENDOR}-${HOST_OS}"
@@ -118,16 +100,3 @@ TARGET_ARCH[vardepsexclude] = "TUNE_ARCH"
# points to the wrong place so force it
SHLIBSDIRS = "${PKGDATA_DIR}/nativesdk-shlibs"
SHLIBSWORKDIR = "${PKGDATA_DIR}/nativesdk-shlibs"
-
-cross_canadian_bindirlinks () {
- for i in ${CANADIANEXTRAOS}
- do
- d=${D}${bindir}/../${TARGET_ARCH}${TARGET_VENDOR}-$i
- install -d $d
- for j in `ls ${D}${bindir}`
- do
- p=${TARGET_ARCH}${TARGET_VENDOR}-$i-`echo $j | sed -e
s,${TARGET_PREFIX},,`
- ln -s ../${TARGET_SYS}/$j $d/$p
- done
- done
-}
diff --git a/meta/recipes-devtools/binutils/binutils-cross-canadian.inc
b/meta/recipes-devtools/binutils/binutils-cross-canadian.inc
index 81349c0..2da9017 100644
--- a/meta/recipes-devtools/binutils/binutils-cross-canadian.inc
+++ b/meta/recipes-devtools/binutils/binutils-cross-canadian.inc
@@ -22,8 +22,6 @@ do_install () {
rm -f ${D}${libdir}/libiberty*
rm -f ${D}${libdir}/libopcodes*
rm -f ${D}${includedir}/*.h
-
- cross_canadian_bindirlinks
}
BBCLASSEXTEND = ""
diff --git a/meta/recipes-devtools/gcc/gcc-cross-canadian.inc
b/meta/recipes-devtools/gcc/gcc-cross-canadian.inc
index 900f1e5..64bb6ba 100644
--- a/meta/recipes-devtools/gcc/gcc-cross-canadian.inc
+++ b/meta/recipes-devtools/gcc/gcc-cross-canadian.inc
@@ -29,7 +29,6 @@ export AS_FOR_TARGET = "${TARGET_PREFIX}as"
export DLLTOOL_FOR_TARGET = "${TARGET_PREFIX}dlltool"
export CC_FOR_TARGET = "${TARGET_PREFIX}gcc"
export CXX_FOR_TARGET = "${TARGET_PREFIX}g++"
-export GCC_FOR_TARGET = "${TARGET_PREFIX}gcc"
export LD_FOR_TARGET = "${TARGET_PREFIX}ld"
export LIPO_FOR_TARGET = "${TARGET_PREFIX}lipo"
export NM_FOR_TARGET = "${TARGET_
[OE-core] [PATCH 0/1] terminal.bbclass: do not export PS1
terminal.bbclass: do not export PS1 With a complex PS1 setup, PS1 might not have all characters correctly escaped when terminal.bbclass writes the export. This caused the run.do_terminal.PID to terminate, making it impossible to use the devshell. As the spawned shell will parse e.g. .bashrc (or whatever rc-file is being used), PS1 will be reset in the devshell. The following changes since commit 1028ac813fa9803ebfff6bcfa7f8b67012609b27: sstate: add do_package to the noexec list in setscene_depvalid (2014-01-07 13:58:28 +) are available in the git repository at: git://github.com/darander/oe-core terminal.bbclass https://github.com/darander/oe-core/tree/terminal.bbclass Anders Darander (1): terminal.bbclass: do not export PS1 meta/classes/terminal.bbclass | 4 1 file changed, 4 insertions(+) -- 1.8.5.2 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] terminal.bbclass: do not export PS1
With a complex PS1 setup, PS1 might not have all characters correctly escaped
when terminal.bbclass writes the export. This caused the run.do_terminal.PID to
terminate, making it impossible to use the devshell.
As the spawned shell will parse e.g. .bashrc (or whatever rc-file is being
used), PS1 will be reset in the devshell.
Signed-off-by: Anders Darander
---
meta/classes/terminal.bbclass | 4
1 file changed, 4 insertions(+)
diff --git a/meta/classes/terminal.bbclass b/meta/classes/terminal.bbclass
index 774f055..e577c6d 100644
--- a/meta/classes/terminal.bbclass
+++ b/meta/classes/terminal.bbclass
@@ -64,6 +64,10 @@ def oe_terminal(command, title, d):
envdata.setVar(key, str(value))
envdata.setVarFlag(key, 'export', 1)
+# A complex PS1 might need more escaping of chars.
+# Lets not export PS1 instead.
+envdata.delVar("PS1")
+
# Replace command with an executable wrapper script
command = emit_terminal_func(command, envdata, d)
--
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] Revert "cross-canadian: Handle powerpc linux verses linux-gnuspe"
On Fri, 2014-01-10 at 15:48 +0100, David Nyström wrote: > The reverted commit seems to introduce some problems for the toolchain tarball > for powerpc. > I see this both in master and on dora. > > 1. Looks like the relocation scripts fails for environments: > > ~/tests/poky [master] > $ cat /opt/oel/2014-01-01/environment-setup-ppce500v2-oel-linux | grep "#" > export SDKTARGETSYSROOT=##SDKTARGETSYSROOT## > > ~/tests/poky [master] > $ cat /opt/oel/2014-01-01/environment-setup-ppce500v2-oel-linux-gnuspe | grep > "#" > > 2. nativeSDK gnuspe compiler does not allow -mabi=spe > ABIEXTENSION is zeroed both for linux-gnuspe and linux > > 3. Compiler can't create executables. > I think this is due to libgcc_s.so from the SDK target sysroot is in mabi=spe. > > 4. -mspe is included in CC var for both linux and gnuspe. > cat /opt/oel/2014-01-01/environment-setup-ppce500v2-oel-linux | grep mabi > export CC="powerpc-oel-linux-gcc -m32 -mcpu=8548 -mabi=spe -mspe > export CXX="powerpc-oel-linux-g++ -m32 -mcpu=8548 -mabi=spe -mspe > export CPP="powerpc-oel-linux-gcc -E -m32 -mcpu=8548 -mabi=spe -mspe > > With the commit reverted, I can successfully build target code with the > canadian compiler > from the SDK tarball. Only the gnuspe environment file is generated. Ok, so how do you propose we fix the issues the patch was added to address? Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] terminal.bbclass: do not export PS1
Anders Darander writes: > With a complex PS1 setup, PS1 might not have all characters correctly > escaped I think, this must be solved in other layers (bitbake?). Using 'pipes.quote()' seems to be a proper way to escape things correctly. Enrico ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] unmaintained layers
Op 10 jan. 2014, om 15:01 heeft Paul Eggleton het volgende geschreven: > On Thursday 09 January 2014 13:45:23 Trevor Woerner wrote: >> At the last TSC meeting the topic of unmaintained layers came up. Here >> is the sorted list of master layers from the layer index [1], would it >> be possible for those in the know to indicate which layers are, or are >> suspected of being, unmaintained? > > This is all very interesting with people piping up that their layers are > maintained, but I'm not sure it helps solve the overall problem. > > We have some immediate issues with patches to particular layers going > unmerged. That's in the process of being resolved. > > However, looking to the future it was suggested at the TSC meeting it would > be > nice to have some kind of measure or indication for the layer (ideally in the > layer index) as to how well-maintained it is. Is there a practical and > objective measurement we can have about the layer's maintenance status? I > don't have a good idea of what this would actually mean - how many > outstanding > patches it has? How recently it has been built/tested? Or how long it takes a patch to get applied on average. ___ 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 10 jan. 2014, om 08:48 heeft Arslan, Fahad 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 het
> volgende geschreven:
>
>>
>> Op 7 jan. 2014, om 10:59 heeft Arslan, Fahad 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] Failed to build opkg with curl support
On 9 January 2014 12:04, Yevhen Kyriukha wrote: > I define "curl" in PACKAGECONFIG for opkg. > After that I'm getting circular dependency errors during building opkg. > > Best regards, > Yevhen Sorry, this is a known problem. The update-alternatives script needs to be moved out of opkg, either to opkg-utils or to its own recipe as it is the use of update-alternatives that is causing the circular dependencies. This is what I am planning to work on next as soon as I get some time. This is required for my ongoing development work on opkg so it should get sorted out soon. (Future versions of opkg will depend on libarchive which also indirectly depends on update-alternatives). Related to this is the fact that no other providers of update-alternatives seem to work, again due to circular dependencies. See http://thread.gmane.org/gmane.comp.handhelds.openembedded.core/45321 Thanks, -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] unmaintained layers
Hi Paul,
On 01/10/14 09:01, Paul Eggleton wrote:
> This is all very interesting with people piping up that their layers
> are maintained, but I'm not sure it helps solve the overall problem.
> Also, if it does appear that a layer has gone "unmaintained" by
> popular consensus, what should actually be done about it?
I was hoping I could put together a list of the layers which are no
longer maintained to see if we could find people who might be interested
in stepping up and taking on their maintenance. Or at the very least,
clarifying a given layers' maintenance status.
At the last OE TSC meeting the issue of unmaintained layers was brought
up, I asked several times if people could specify to which layers they
were referring, but nobody replied. So people are concerned about layers
that have no maintainer, but nobody can say which ones (?). In my
opinion I thought it would be easier to solve this problem if we could
at least start by defining it.
As to what can be done about it: if a layer is not maintained, and
nobody cares for the layer, we should drop it from the list or at least
mark it as such ("buyer beware"). If a layer is not maintained, and
people do care, then we'll need to try to find someone to take
responsibility for it (we should, at the very least, make the attempt).
Also I think we should identify layers that people do care about, whose
maintenance is questionable, which are not hosted in a way where the
community can apply necessary patches to easily.
Best regards,
Trevor
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] db failure due to libstdc++.so host contamination
On 8 January 2014 17:56, Jack Mitchell wrote: > do_compile.log: http://ix.io/9Ki > > Speaking on IRC it seems that host systems with /usr/lib/libstdc++.so > present are failing to build db. > > /usr/lib/libstdc++.so is present on at least archlinux in the gcc-libs > and gcc-multilibs package which is a fairly standard package to have > installed. The problem has appeared since commit > a484b35b818768487ff27cf06b8c5d4e128126af in oe-core. > > Will try and find some time to do more debugging but if anyone sees any > tell tale signs then shout up. I'm also on archlinux so that may narrow down the list of systems affected by the bug. I do see the "-rpath /usr/lib" option to libtool but I don't know enough about libtool to determine whether that is safe or not. -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] unmaintained layers
On 01/10/2014 10:51 AM, Trevor Woerner wrote:
> Hi Paul,
>
> On 01/10/14 09:01, Paul Eggleton wrote:
>> This is all very interesting with people piping up that their layers
>> are maintained, but I'm not sure it helps solve the overall problem.
>
>> Also, if it does appear that a layer has gone "unmaintained" by
>> popular consensus, what should actually be done about it?
>
> I was hoping I could put together a list of the layers which are no
> longer maintained to see if we could find people who might be interested
> in stepping up and taking on their maintenance. Or at the very least,
> clarifying a given layers' maintenance status.
>
> At the last OE TSC meeting the issue of unmaintained layers was brought
> up, I asked several times if people could specify to which layers they
> were referring, but nobody replied. So people are concerned about layers
> that have no maintainer, but nobody can say which ones (?). In my
> opinion I thought it would be easier to solve this problem if we could
> at least start by defining it.
BTW, I maintain meta-sdr.
Philip
>
> As to what can be done about it: if a layer is not maintained, and
> nobody cares for the layer, we should drop it from the list or at least
> mark it as such ("buyer beware"). If a layer is not maintained, and
> people do care, then we'll need to try to find someone to take
> responsibility for it (we should, at the very least, make the attempt).
> Also I think we should identify layers that people do care about, whose
> maintenance is questionable, which are not hosted in a way where the
> community can apply necessary patches to easily.
>
> Best regards,
> Trevor
> ___
> 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] unmaintained layers
On 01/10/14 11:02, Philip Balister wrote: > BTW, I maintain meta-sdr. ...and meta-ettus and meta-zynq? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] unmaintained layers
On 01/09/2014 10:45 AM, Trevor Woerner wrote: Hi everyone, At the last TSC meeting the topic of unmaintained layers came up. Here is the sorted list of master layers from the layer index [1], would it be possible for those in the know to indicate which layers are, or are suspected of being, unmaintained? meta-baryon meta-security meta-web-kiosk These are being maintained Sau! Thank you for your input, and best regards, Trevor [1] http://layers.openembedded.org/layerindex/branch/master/layers/ ___ 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] [dora][PATCH 0/2] Dora backports
On 1/10/14, 4:41 AM, Richard Purdie wrote: On Fri, 2014-01-10 at 14:18 +0800, Robert Yang wrote: Hi Martin, Thanks, please see my comments in line. On 01/06/2014 06:21 PM, Martin Jansa wrote: The following changes since commit e86622a932bbd0acdea67ecfb15c8b06c27353d8: libsoup-2.4: add intltool-native to DEPENDS (2013-12-19 14:59:47 +) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib jansa/dora-backports2 http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=jansa/dora-backports2 Martin Jansa (1): ltp: set PREFERRED_PROVIDER and rename runtests_noltp.sh script I will take this. Richard Purdie (1): eglibc-initial.inc: Drop duplicate include It seems that this is a trivial fix, I don't think it's a good idea to merge it to dora. Thanks to one of the bitbake patches we backported, this "trivial" issue is now putting warnings in peoples builds so I think it might be a good idea to fix it. Ya I agree. This is going to cause confusion for people. Being a small 2 line patch, and pretty easy to show that it's "safe". I'd also recommend that that backport be accepted. --Mark Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH][V2 5/5] packagegroup-core-tools-testapps: add Piglit
Respect the OpenGL distro feature and if it's enabled, pull in piglit and
mesa-tools.
Signed-off-by: Ross Burton
---
.../packagegroups/packagegroup-core-tools-testapps.bb |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git
a/meta/recipes-core/packagegroups/packagegroup-core-tools-testapps.bb
b/meta/recipes-core/packagegroups/packagegroup-core-tools-testapps.bb
index 1861ebe..4b8f99b 100644
--- a/meta/recipes-core/packagegroups/packagegroup-core-tools-testapps.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-core-tools-testapps.bb
@@ -24,10 +24,14 @@ KEXECTOOLS_powerpc ?= ""
KEXECTOOLS_e5500-64b ?= ""
KEXECTOOLS_aarch64 ?= ""
+GLTOOLS = "\
+mesa-demos \
+piglit \
+"
+
X11TOOLS = "\
fstests \
owl-video \
-mesa-demos \
x11perf \
xrestop \
xwininfo \
@@ -48,4 +52,5 @@ RDEPENDS_${PN} = "\
ltp \
connman-client \
${@base_contains('DISTRO_FEATURES', 'x11', "${X11TOOLS}", "", d)} \
+${@base_contains('DISTRO_FEATURES', 'opengl', "${GLTOOLS}", "", d)} \
"
--
1.7.10.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH][V2 4/5] piglit: add (from meta-oe)
Piglit is an OpenGL testing tool. This recipe is taken directly from meta-oe.
Signed-off-by: Ross Burton
---
meta/recipes-graphics/piglit/piglit_git.bb | 48
1 file changed, 48 insertions(+)
create mode 100644 meta/recipes-graphics/piglit/piglit_git.bb
diff --git a/meta/recipes-graphics/piglit/piglit_git.bb
b/meta/recipes-graphics/piglit/piglit_git.bb
new file mode 100644
index 000..8616764
--- /dev/null
+++ b/meta/recipes-graphics/piglit/piglit_git.bb
@@ -0,0 +1,48 @@
+SUMMARY = "OpenGL driver testing framework"
+LICENSE = "MIT & LGPLv2+ & GPLv3 & GPLv2+ & BSD-3-Clause"
+LIC_FILES_CHKSUM = "file://COPYING;md5=b2beded7103a3d8a442a2a0391d607b0"
+
+SRC_URI = "git://anongit.freedesktop.org/piglit"
+
+# From 2012/12/30.
+SRCREV = "bbeff5d21b06d37338ad28e42d88f499bef13268"
+# (when PV goes above 1.0 remove the trailing r)
+PV = "1.0+gitr${SRCPV}"
+
+S = "${WORKDIR}/git"
+
+DEPENDS = "virtual/libx11 waffle virtual/libgl libglu python-mako-native
python-numpy-native"
+
+inherit cmake pythonnative
+
+# As piglit doesn't install, enforce in-tree builds so that we can easily copy
+# contents out of $S and $B.
+B="${S}"
+
+# CMake sets the rpath at build time with the source tree, and will reset it at
+# install time. As we don't install this doesn't happen, so force the rpath to
+# what we need.
+EXTRA_OECMAKE = "-DCMAKE_BUILD_WITH_INSTALL_RPATH=1
-DCMAKE_INSTALL_RPATH=${libdir}/piglit/lib"
+
+do_install() {
+ install -d ${D}${bindir}
+ install -m 0755 piglit-*.py ${D}${bindir}
+
+ install -d ${D}${libdir}/piglit/
+
+ install -d ${D}${libdir}/piglit/bin
+ install -m 755 ${S}/bin/* ${D}${libdir}/piglit/bin
+
+ cp -a lib/ ${D}${libdir}/piglit/
+ cp -a framework/ ${D}${libdir}/piglit/
+ cp -a generated_tests/ ${D}${libdir}/piglit/
+ cp -a tests/ ${D}${libdir}/piglit/
+ cp -a templates/ ${D}${libdir}/piglit/
+
+ sed -i -e 's|sys.path.append(.*)|sys.path.append("${libdir}/piglit")|'
${D}${bindir}/piglit-*.py
+ sed -i -e 's|^templatedir = .*$|templatedir =
"${libdir}/piglit/templates"|' ${D}${bindir}/piglit-summary-html.py
+}
+
+FILES_${PN}-dbg += "${libdir}/piglit/*/.debug/"
+
+RDEPENDS_${PN} = "python waffle python-json python-subprocess
python-multiprocessing python-textutils python-netserver python-shell
mesa-demos"
--
1.7.10.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH][V2 2/5] python-mako: add (from meta-oe)
python-mako is needed for Piglit. This recipe is taken directly from meta-oe.
Signed-off-by: Ross Burton
---
meta/recipes-devtools/python/python-mako_0.7.2.bb | 22 +
1 file changed, 22 insertions(+)
create mode 100644 meta/recipes-devtools/python/python-mako_0.7.2.bb
diff --git a/meta/recipes-devtools/python/python-mako_0.7.2.bb
b/meta/recipes-devtools/python/python-mako_0.7.2.bb
new file mode 100644
index 000..1d2bdd7
--- /dev/null
+++ b/meta/recipes-devtools/python/python-mako_0.7.2.bb
@@ -0,0 +1,22 @@
+DESCRIPTION = "Templating library for Python"
+SECTION = "devel/python"
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=da8dd26ed9751ee0cfdf9df1a16bbb54"
+
+PR = "r2"
+
+SRC_URI = "http://www.makotemplates.org/downloads/Mako-${PV}.tar.gz";
+SRC_URI[md5sum] = "e3c0a677aa4216da9e89ef8fa76cbafb"
+SRC_URI[sha256sum] =
"fe8698e845035586bd711a6748e4e40a208a58de276b9138026164700494b68f"
+
+S = "${WORKDIR}/Mako-${PV}"
+
+inherit setuptools
+
+RDEPENDS_${PN} = "python-threading \
+ python-netclient \
+ python-html \
+"
+RDEPENDS_${PN}_class-native = ""
+
+BBCLASSEXTEND = "native nativesdk"
--
1.7.10.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH][V2 3/5] waffle: add (from meta-oe)
Waffle is needed for Piglit. This recipe is taken directly frome meta-oe.
Signed-off-by: Ross Burton
---
meta/recipes-graphics/waffle/files/cflags.patch | 27 ++
meta/recipes-graphics/waffle/waffle_1.2.2.bb| 34 +++
2 files changed, 61 insertions(+)
create mode 100644 meta/recipes-graphics/waffle/files/cflags.patch
create mode 100644 meta/recipes-graphics/waffle/waffle_1.2.2.bb
diff --git a/meta/recipes-graphics/waffle/files/cflags.patch
b/meta/recipes-graphics/waffle/files/cflags.patch
new file mode 100644
index 000..3819756
--- /dev/null
+++ b/meta/recipes-graphics/waffle/files/cflags.patch
@@ -0,0 +1,27 @@
+Upstream-Status: Backport
+Signed-off-by: Ross Burton
+
+From 2abec1cb3c17fa5ec8d945d79acd74a39c38293a Mon Sep 17 00:00:00 2001
+From: Ross Burton
+Date: Wed, 12 Dec 2012 12:57:18 +
+Subject: cmake: respect existing CMAKE_C_FLAGS
+
+When cross-compiling it's not unusual to need specific arguments passed to gcc
+such as --sysroot. Ensure that these are passed on from the toolchain file by
+appending to CMAKE_C_FLAGS instead of overwriting it.
+
+Signed-off-by: Ross Burton
+
+Index: waffle-1.2.2/CMakeLists.txt
+===
+--- waffle-1.2.2.orig/CMakeLists.txt 2012-11-28 00:43:40.0 +
waffle-1.2.2/CMakeLists.txt2013-02-13 11:34:02.476188233 +
+@@ -212,7 +212,7 @@
+ #
--
+
+ # FIXME: Only enable c99 if compiler supports it.
+-set(CMAKE_C_FLAGS "--std=c99 -Wall -Werror=implicit-function-declaration")
++set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} --std=c99 -Wall
-Werror=implicit-function-declaration")
+ if("${CMAKE_SYSTEM_NAME}" STREQUAL "Linux")
+ # On MacOS, the SSE2 headers trigger this error.
+ set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Werror=missing-prototypes")
diff --git a/meta/recipes-graphics/waffle/waffle_1.2.2.bb
b/meta/recipes-graphics/waffle/waffle_1.2.2.bb
new file mode 100644
index 000..4f80191
--- /dev/null
+++ b/meta/recipes-graphics/waffle/waffle_1.2.2.bb
@@ -0,0 +1,34 @@
+SUMMARY = "cross-platform C library to defer selection of GL API and of window
system"
+LICENSE = "BSD-2-Clause"
+LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=4c5154407c2490750dd461c50ad94797 \
+
file://include/waffle/waffle.h;endline=24;md5=61dbf8697f61c78645e75a93c585b1bf"
+
+SRC_URI =
"http://people.freedesktop.org/~chadversary/waffle/files/release/${BPN}-${PV}/${BPN}-${PV}.tar.xz
\
+ file://cflags.patch"
+
+SRC_URI[md5sum] = "fdd07cea7709422fbf72418ee63a285d"
+SRC_URI[sha256sum] =
"7e342c859b58d4e051b347ef3d7740ed2f3b6c506b93daec272724afe7dd1311"
+
+inherit cmake
+
+# This should be overridden per-machine to reflect the capabilities of the GL
+# stack.
+PACKAGECONFIG ??= "glx"
+
+# I say virtual/libgl, actually wants gl.pc
+PACKAGECONFIG[glx] = "-Dwaffle_has_glx=1,,virtual/libgl libx11"
+
+# I say virtual/libgl, actually wants wayland-egl.pc, egl.pc, and the wayland
+# DISTRO_FEATURE.
+PACKAGECONFIG[wayland] = "-Dwaffle_has_wayland=1,,virtual/libgl wayland"
+
+# I say virtual/libgl, actually wants gbm.pc egl.pc
+PACKAGECONFIG[gbm] = "-Dwaffle_has_wayland=1,,virtual/libgl udev"
+
+# I say virtual/libgl, actually wants egl.pc
+PACKAGECONFIG[x11-egl] = "-Dwaffle_has_x11_egl=1,,virtual/libgl libxcb"
+
+# Take the flags added by PACKAGECONFIG and pass them to cmake.
+EXTRA_OECMAKE = "${EXTRA_OECONF}"
+
+FILES_${PN}-dev += "${datadir}/cmake/Modules/FindWaffle.cmake"
--
1.7.10.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH][V2 1/5] python-numpy: add (from meta-oe)
python-numpy is needed for Piglit. This recipe is taken directly from meta-oe.
Signed-off-by: Ross Burton
---
.../python/python-numpy/aarch64/_numpyconfig.h | 30 +
.../python/python-numpy/aarch64/config.h | 139
.../python/python-numpy/arm/config.h | 21 +++
.../python/python-numpy/arm/numpyconfig.h | 17 +++
.../python/python-numpy/armeb/config.h | 21 +++
.../python/python-numpy/armeb/numpyconfig.h| 17 +++
.../python/python-numpy/i586/config.h | 108 +++
.../python/python-numpy/i586/numpyconfig.h | 24
.../python/python-numpy/mipsel/config.h| 21 +++
.../python/python-numpy/mipsel/numpyconfig.h | 17 +++
.../python/python-numpy/trycompile.diff| 33 +
.../python/python-numpy/unbreak-assumptions.diff | 16 +++
.../python/python-numpy/x86-64/_numpyconfig.h | 30 +
.../python/python-numpy/x86-64/config.h| 139
meta/recipes-devtools/python/python-numpy_1.7.0.bb | 78 +++
15 files changed, 711 insertions(+)
create mode 100644
meta/recipes-devtools/python/python-numpy/aarch64/_numpyconfig.h
create mode 100644 meta/recipes-devtools/python/python-numpy/aarch64/config.h
create mode 100644 meta/recipes-devtools/python/python-numpy/arm/config.h
create mode 100644 meta/recipes-devtools/python/python-numpy/arm/numpyconfig.h
create mode 100644 meta/recipes-devtools/python/python-numpy/armeb/config.h
create mode 100644
meta/recipes-devtools/python/python-numpy/armeb/numpyconfig.h
create mode 100644 meta/recipes-devtools/python/python-numpy/i586/config.h
create mode 100644 meta/recipes-devtools/python/python-numpy/i586/numpyconfig.h
create mode 100644 meta/recipes-devtools/python/python-numpy/mipsel/config.h
create mode 100644
meta/recipes-devtools/python/python-numpy/mipsel/numpyconfig.h
create mode 100644 meta/recipes-devtools/python/python-numpy/trycompile.diff
create mode 100644
meta/recipes-devtools/python/python-numpy/unbreak-assumptions.diff
create mode 100644
meta/recipes-devtools/python/python-numpy/x86-64/_numpyconfig.h
create mode 100644 meta/recipes-devtools/python/python-numpy/x86-64/config.h
create mode 100644 meta/recipes-devtools/python/python-numpy_1.7.0.bb
diff --git a/meta/recipes-devtools/python/python-numpy/aarch64/_numpyconfig.h
b/meta/recipes-devtools/python/python-numpy/aarch64/_numpyconfig.h
new file mode 100644
index 000..be57ac2
--- /dev/null
+++ b/meta/recipes-devtools/python/python-numpy/aarch64/_numpyconfig.h
@@ -0,0 +1,30 @@
+#define NPY_HAVE_ENDIAN_H 1
+#define NPY_SIZEOF_SHORT SIZEOF_SHORT
+#define NPY_SIZEOF_INT SIZEOF_INT
+#define NPY_SIZEOF_LONG SIZEOF_LONG
+#define NPY_SIZEOF_FLOAT 4
+#define NPY_SIZEOF_COMPLEX_FLOAT 8
+#define NPY_SIZEOF_DOUBLE 8
+#define NPY_SIZEOF_COMPLEX_DOUBLE 16
+#define NPY_SIZEOF_LONGDOUBLE 16
+#define NPY_SIZEOF_COMPLEX_LONGDOUBLE 32
+#define NPY_SIZEOF_PY_INTPTR_T 8
+#define NPY_SIZEOF_PY_LONG_LONG 8
+#define NPY_SIZEOF_LONGLONG 8
+#define NPY_NO_SMP 0
+#define NPY_HAVE_DECL_ISNAN
+#define NPY_HAVE_DECL_ISINF
+#define NPY_HAVE_DECL_ISFINITE
+#define NPY_HAVE_DECL_SIGNBIT
+#define NPY_USE_C99_COMPLEX 1
+#define NPY_HAVE_COMPLEX_DOUBLE 1
+#define NPY_HAVE_COMPLEX_FLOAT 1
+#define NPY_HAVE_COMPLEX_LONG_DOUBLE 1
+#define NPY_USE_C99_FORMATS 1
+#define NPY_VISIBILITY_HIDDEN __attribute__((visibility("hidden")))
+#define NPY_ABI_VERSION 0x0109
+#define NPY_API_VERSION 0x0007
+
+#ifndef __STDC_FORMAT_MACROS
+#define __STDC_FORMAT_MACROS 1
+#endif
diff --git a/meta/recipes-devtools/python/python-numpy/aarch64/config.h
b/meta/recipes-devtools/python/python-numpy/aarch64/config.h
new file mode 100644
index 000..c30b868
--- /dev/null
+++ b/meta/recipes-devtools/python/python-numpy/aarch64/config.h
@@ -0,0 +1,139 @@
+#define HAVE_ENDIAN_H 1
+#define SIZEOF_PY_INTPTR_T 8
+#define SIZEOF_PY_LONG_LONG 8
+#define MATHLIB m
+#define HAVE_SIN 1
+#define HAVE_COS 1
+#define HAVE_TAN 1
+#define HAVE_SINH 1
+#define HAVE_COSH 1
+#define HAVE_TANH 1
+#define HAVE_FABS 1
+#define HAVE_FLOOR 1
+#define HAVE_CEIL 1
+#define HAVE_SQRT 1
+#define HAVE_LOG10 1
+#define HAVE_LOG 1
+#define HAVE_EXP 1
+#define HAVE_ASIN 1
+#define HAVE_ACOS 1
+#define HAVE_ATAN 1
+#define HAVE_FMOD 1
+#define HAVE_MODF 1
+#define HAVE_FREXP 1
+#define HAVE_LDEXP 1
+#define HAVE_RINT 1
+#define HAVE_TRUNC 1
+#define HAVE_EXP2 1
+#define HAVE_LOG2 1
+#define HAVE_ATAN2 1
+#define HAVE_POW 1
+#define HAVE_NEXTAFTER 1
+#define HAVE_SINF 1
+#define HAVE_COSF 1
+#define HAVE_TANF 1
+#define HAVE_SINHF 1
+#define HAVE_COSHF 1
+#define HAVE_TANHF 1
+#define HAVE_FABSF 1
+#define HAVE_FLOORF 1
+#define HAVE_CEILF 1
+#define HAVE_RINTF 1
+#define HAVE_TRUNCF 1
+#define HAVE_SQRTF 1
+#define HAVE_LOG10F 1
+#define HAVE_LOGF 1
+#define HAVE_LOG1PF 1
+#define HAVE_EXPF 1
+#define HAVE_EXPM1F 1
+#define HAVE_ASINF 1
+#define HAVE_ACOSF 1
+#defin
[OE-core] [PATCH] dbus: Remove stray semicolon from SRC_URI
Signed-off-by: Phil Blundell
---
meta/recipes-core/dbus/dbus.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/dbus/dbus.inc b/meta/recipes-core/dbus/dbus.inc
index 9bdb489..86d6caa 100644
--- a/meta/recipes-core/dbus/dbus.inc
+++ b/meta/recipes-core/dbus/dbus.inc
@@ -11,7 +11,7 @@ RDEPENDS_dbus_class-native = ""
RDEPENDS_dbus_class-nativesdk = ""
SRC_URI = "http://dbus.freedesktop.org/releases/dbus/dbus-${PV}.tar.gz \
- file://tmpdir.patch; \
+ file://tmpdir.patch \
file://dbus-1.init \
file://os-test.patch \
"
--
1.8.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] acl: enable ptest support
On 01/10/2014 01:13 AM, Chong Lu wrote:
Install acl test suite and run it as ptest.
nfs test cases need depend on nfs service. So exclude them order to
make ptest all pass.
Signed-off-by: Chong Lu
---
meta/recipes-support/attr/acl.inc | 15 +-
.../attr/acl/acl-make-ptest-pass.patch | 457 +
meta/recipes-support/attr/acl/run-ptest| 5 +
3 files changed, 476 insertions(+), 1 deletion(-)
create mode 100644 meta/recipes-support/attr/acl/acl-make-ptest-pass.patch
create mode 100644 meta/recipes-support/attr/acl/run-ptest
diff --git a/meta/recipes-support/attr/acl.inc
b/meta/recipes-support/attr/acl.inc
index a461232..4bacf80 100644
--- a/meta/recipes-support/attr/acl.inc
+++ b/meta/recipes-support/attr/acl.inc
@@ -9,7 +9,10 @@ LIC_FILES_CHKSUM =
"file://doc/COPYING;md5=c781d70ed2b4d48995b790403217a249 \
file://doc/COPYING.LGPL;md5=9e9a206917f8af112da634ce3ab41764"
DEPENDS = "attr"
-SRC_URI = "http://download.savannah.gnu.org/releases/acl/${BP}.src.tar.gz";
+SRC_URI = "http://download.savannah.gnu.org/releases/acl/${BP}.src.tar.gz \
+ file://acl-make-ptest-pass.patch \
+ file://run-ptest \
+"
require ea-acl.inc
@@ -24,3 +27,13 @@ do_install_append() {
sed -i ${D}${libdir}/libacl.la -e \
s,^libdir=\'${base_libdir}\'$,libdir=\'${libdir}\',
}
+
+inherit ptest
+
+do_install_ptest() {
+ tar -cf - test/ --exclude nfs | ( cd ${D}${PTEST_PATH} && tar -xf - )
+ mkdir ${D}${PTEST_PATH}/include
+ cp ${S}/include/builddefs ${S}/include/buildmacros
${S}/include/buildrules ${D}${PTEST_PATH}/include/
+}
+
+RDEPENDS_${PN}-ptest = "coreutils perl-module-filehandle perl-module-getopt-std
perl-module-posix"
diff --git a/meta/recipes-support/attr/acl/acl-make-ptest-pass.patch
b/meta/recipes-support/attr/acl/acl-make-ptest-pass.patch
new file mode 100644
index 000..89c03c2
--- /dev/null
+++ b/meta/recipes-support/attr/acl/acl-make-ptest-pass.patch
@@ -0,0 +1,457 @@
+acl: make ptest pass
+
+Upstream-Status: Inappropriate [embedded specific]
+
+The daemon user must be a member in the bin group, else permissions.test
+will fail. So add daemon user to bin group.
+Many results of `ls' are incorrect in some test cases, modify them to make
+ptest pass.
+
This does not seem quite right, you don't just change the tests to "make
ptest pass" What's wrong with the output of ls? Is this because it's
using busybox's ls instead of coreutils version of ls?
If that's the case then we should really have the acl-ptest package have
an RDEPENDS on coreutils.
Sau!
+Signed-off-by: Chong Lu
+---
+ test/Makefile |2 +-
+ test/cp.test |8 ++---
+ test/misc.test | 86 ++--
+ test/root/permissions.test |2 +-
+ test/root/setfacl.test |2 +-
+ test/sbits-restore.test|6 ++--
+ 6 files changed, 53 insertions(+), 53 deletions(-)
+
+diff --git a/test/Makefile b/test/Makefile
+index d2baac8..6063a56 100644
+--- a/test/Makefile
b/test/Makefile
+@@ -42,7 +42,7 @@ $(NFS):
+ @echo "NFS specific tests"; echo "*** $@ ***"; perl run $@
+
+ $(ROOT):
+- @echo "Note: Tests must run as root"; echo "*** $@ ***"; perl run $@
++ @echo "Note: Tests must run as root"; echo "*** $@ ***"; usermod -G bin
daemon; perl run $@
+
+ .PHONY: $(TESTS) $(NFS) $(ROOT)
+ .NOTPARALLEL:
+diff --git a/test/cp.test b/test/cp.test
+index 0867f63..54bee3b 100644
+--- a/test/cp.test
b/test/cp.test
+@@ -6,16 +6,16 @@ The cp utility should only copy ACLs if `-p' is given.
+ $ touch f
+ $ setfacl -m u:bin:rw f
+ $ ls -l f | awk -- '{ print $1 }'
+- > -rw-rw-r--+
++ > -rw-rw-r--
+
+ $ cp f g
+- $ ls -l g | awk -- '{ print $1 }' | sed 's/\.$//g'
++ $ ls -l g | awk -- '{ print $1 }'
+ > -rw-r--r--
+
+ $ rm g
+ $ cp -p f g
+ $ ls -l f | awk -- '{ print $1 }'
+- > -rw-rw-r--+
++ > -rw-rw-r--
+
+ $ mkdir h
+ $ echo blubb > h/x
+@@ -33,7 +33,7 @@ The cp utility should only copy ACLs if `-p' is given.
+ > other::r--
+ >
+
+- $ cp -rp h i
++ $ cp -a h i
+ $ getfacl --omit-header i/x
+ > user::rw-
+ > user:bin:rwx
+diff --git a/test/misc.test b/test/misc.test
+index 6e98053..83080e2 100644
+--- a/test/misc.test
b/test/misc.test
+@@ -11,7 +11,7 @@ Only change a base ACL:
+ $ setfacl -m u::r f
+ $ setfacl -m u::rw,u:bin:rw f
+ $ ls -dl f | awk '{print $1}'
+- > -rw-rw+
++ > -rw-rw
+
+ $ getfacl --omit-header f
+ > user::rw-
+@@ -26,7 +26,7 @@ Only change a base ACL:
+ $ touch f
+ $ setfacl -m u:bin:rw f
+ $ ls -dl f | awk '{print $1}'
+- > -rw-rw-r--+
++ > -rw-rw-r--
+
+ $ getfacl --omit-header f
+ > user::rw-
+@@ -41,7 +41,7 @@ Only change a base ACL:
+
Re: [OE-core] unmaintained layers
Hi, On Jan 9, 2014 8:45 PM, "Trevor Woerner" wrote: > > Hi everyone, > > At the last TSC meeting the topic of unmaintained layers came up. Here > is the sorted list of master layers from the layer index [1], would it > be possible for those in the know to indicate which layers are, or are > suspected of being, unmaintained? > > > meta-aarch64 > meta-acer > meta-ada > meta-android > meta-angstrom > meta-arago-distro > meta-arago-extras > meta-asus > meta-aurora > meta-baryon > meta-beagleboard > meta-beagleboard-extras > meta-browser > meta-bug > meta-buglabs > meta-chicken > meta-chiefriver > meta-clutter > meta-crownbay > meta-crystalforest > meta-cubox > meta-darwin > meta-eca > meta-efikamx > meta-efl > meta-eldk > meta-emenlow > meta-erlang > meta-ettus > meta-filesystems > meta-fri2 > meta-fsl-arm > meta-fsl-arm-extra > meta-fsl-demos > meta-fsl-ppc > meta-fso > meta-games > meta-geeksphone > meta-gir > meta-gnome > meta-gpe > meta-gstreamer10 > meta-guacamayo > meta-gumstix > meta-gumstix-community > meta-gumstix-extras > meta-hamradio > meta-handheld > meta-hipos > meta-htc > meta-igep > meta-initramfs > meta-intel > meta-ivi > meta-jasperforest > meta-java > meta-kde > meta-kernel-dev > meta-kirkwood > meta-linaro > meta-linaro-toolchain > meta-lsi > meta-lxcbench > meta-measured > meta-mentor > meta-micro > meta-mingw > meta-minnow > meta-mono > meta-multimedia > meta-n450 > meta-netbookpro > meta-netmodule > meta-networking > meta-nokia > meta-nslu2 > meta-nuc > meta-oe > meta-openmoko > meta-openpandora > meta-openstack > meta-openstack-compute-deploy > meta-openstack-controller-deploy > meta-openstack-qemu > meta-opie > meta-oracle-java > meta-osmocombb > meta-ouya > meta-palm > meta-perl > meta-picosam9 > meta-qt3 > meta-qt5 > meta-raspberrypi Maintained. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] GCC bugfix backport into Dora
Hello, The Dora branch seems to be affected by a toolchain bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57532 4.8.2 includes this bugfix and I'd like to know if it is planned anything in this direction to Dora or not? Regards, -- 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] [RFC][PATCH][V2] cmake: respect ${S} and ${B}
Hi,
Here is V2 of my cmake ${S}/${B} patch. The class isn't that changed since V1,
apart from the addition of a note if the recipe has set OECMAKE_SOURCEPATH or
_BUILDPATH.
Then there's the choice of what we do with the default for ${B}. One patch sets
${B} in separatebuilddir.inc for libproxy and taglib in oe-core. The
alternative is to set B in cmake.bbclass directly to ${WORKDIR}/build.
Either way, this change to the class isn't backwards-compatible with many
recipes in the wild due to various ways of doing out-of-tree builds in meta-oe.
A branch that fixes up meta-oe (by generally deleting lines) is available in
meta-oe-contrib:ross/cmake for reference. Some recipes are using
OECMAKE_SOURCEPATH/_BUILDPATH, and others are doing out-of-tree builds
"manually" by passing arguments to EXTRA_OECMAKE and doing cd's in
do_compile_prepend. Yuck.
Personally, I'd say we should merge cmake.bbclass with B set inside it by
default. In my testing against meta-oe, only piglit is troublesome and that can
set B=${S}, everything else seems to be working fine once the recipes were
cleaned up.
Ross
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/3] cmake: default to out-of-tree builds
Set B=${WORKDIR}/build in cmake.bbclass so that recipes using cmake.bbclass do
out-of-tree builds by default.
Signed-off-by: Ross Burton
---
meta/classes/cmake.bbclass |1 +
1 file changed, 1 insertion(+)
diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index 1dc406d2..3ac3fcc 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -1,4 +1,5 @@
DEPENDS_prepend = "cmake-native "
+B = "${WORKDIR}/build"
# We need to unset CCACHE otherwise cmake gets too confused
CCACHE = ""
--
1.7.10.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/3] cmake: respect ${S} and ${B}
Instead of the class-specific variables OECMAKE_BUILDPATH and
OECMAKE_SOURCEPATH, just use ${B} and ${S}.
If these two paths are different, delete any existing ${B} before running a
build so that previous builds don't taint the current build.
Note that OECMAKE_SOURCEPATH and OECMAKE_BUILDPATH are not respected, so recipes
that manually set these in the past will need to be updated to either use
something along the lines of separatebuilddir.inc or set B themselves. If the
old variables are set, a warning is displayed.
Signed-off-by: Ross Burton
---
meta/classes/cmake.bbclass | 35 +++
1 file changed, 11 insertions(+), 24 deletions(-)
diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index 30c1792..1dc406d2 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -6,15 +6,6 @@ CCACHE = ""
# We want the staging and installing functions from autotools
inherit autotools
-# Use in-tree builds by default but allow this to be changed
-# since some packages do not support them (e.g. llvm 2.5).
-OECMAKE_SOURCEPATH ?= "."
-
-# If declaring this, make sure you also set EXTRA_OEMAKE to
-# "-C ${OECMAKE_BUILDPATH}". So it will run the right makefiles.
-OECMAKE_BUILDPATH ?= ""
-B="${S}"
-
# C/C++ Compiler (without cpu arch/tune arguments)
OECMAKE_C_COMPILER ?= "`echo ${CC} | sed 's/^\([^ ]*\).*/\1/'`"
OECMAKE_CXX_COMPILER ?= "`echo ${CXX} | sed 's/^\([^ ]*\).*/\1/'`"
@@ -73,10 +64,14 @@ EOF
addtask generate_toolchain_file after do_patch before do_configure
cmake_do_configure() {
- if [ ${OECMAKE_BUILDPATH} ]
- then
- mkdir -p ${OECMAKE_BUILDPATH}
- cd ${OECMAKE_BUILDPATH}
+ if [ "${OECMAKE_BUILDPATH}" -o "${OECMAKE_SOURCEPATH}" ]; then
+ bbnote "cmake.bbclass no longer uses OECMAKE_SOURCEPATH and
OECMAKE_BUILDPATH. This recipe now will do in-tree builds, to do out-of-tree
builds set S and B."
+ fi
+
+ if [ "${S}" != "${B}" ]; then
+ rm -rf ${B}
+ mkdir -p ${B}
+ cd ${B}
fi
# Just like autotools cmake can use a site file to cache result that
need generated binaries to run
@@ -88,7 +83,7 @@ cmake_do_configure() {
cmake \
${OECMAKE_SITEFILE} \
- ${OECMAKE_SOURCEPATH} \
+ ${S} \
-DCMAKE_INSTALL_PREFIX:PATH=${prefix} \
-DCMAKE_INSTALL_SO_NO_EXE=0 \
-DCMAKE_TOOLCHAIN_FILE=${WORKDIR}/toolchain.cmake \
@@ -98,20 +93,12 @@ cmake_do_configure() {
}
cmake_do_compile() {
- if [ ${OECMAKE_BUILDPATH} ]
- then
- cd ${OECMAKE_BUILDPATH}
- fi
-
+ cd ${B}
base_do_compile
}
cmake_do_install() {
- if [ ${OECMAKE_BUILDPATH} ];
- then
- cd ${OECMAKE_BUILDPATH}
- fi
-
+ cd ${B}
autotools_do_install
}
--
1.7.10.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] util-linux: Add fstrim utility
Add "util-linux-fstrim" package, containing /sbin/fstrim, for trimming
unused sectors on SSDs.
---
meta/recipes-core/util-linux/util-linux.inc |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/util-linux/util-linux.inc
b/meta/recipes-core/util-linux/util-linux.inc
index 8a1e78a..10d9501 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -36,7 +36,7 @@ PACKAGES =+ "util-linux-agetty util-linux-fdisk
util-linux-cfdisk util-linux-sfd
util-linux-libblkid-dev util-linux-libuuid util-linux-libuuid-dev
\
util-linux-uuidgen util-linux-lscpu util-linux-fsck
util-linux-blkid \
util-linux-mkfs util-linux-mcookie util-linux-reset
util-linux-uuidd \
- util-linux-mkfs.cramfs util-linux-fsck.cramfs \
+ util-linux-mkfs.cramfs util-linux-fsck.cramfs util-linux-fstrim \
util-linux-partx ${PN}-bash-completion"
SHARED_EXTRA_OECONF = "--disable-use-tty-group \
@@ -63,6 +63,7 @@ FILES_${PN}-doc += "${datadir}/getopt/getopt-*.*"
FILES_util-linux-agetty = "${base_sbindir}/agetty"
FILES_util-linux-fdisk = "${base_sbindir}/fdisk.${BPN}"
+FILES_util-linux-fstrim = "${base_sbindir}/fstrim"
FILES_util-linux-cfdisk = "${base_sbindir}/cfdisk"
FILES_util-linux-sfdisk = "${sbindir}/sfdisk"
FILES_util-linux-swaponoff = "${base_sbindir}/swapon.${BPN}
${base_sbindir}/swapoff.${BPN}"
@@ -130,7 +131,7 @@ do_install () {
mkdir -p ${D}${base_bindir}
sbinprogs="agetty ctrlaltdel cfdisk vipw vigr"
-sbinprogs_a="pivot_root hwclock mkswap mkfs.minix fsck.minix losetup
swapon swapoff fdisk readprofile fsck blkid blockdev"
+sbinprogs_a="pivot_root hwclock mkswap mkfs.minix fsck.minix losetup
swapon swapoff fdisk readprofile fsck blkid blockdev fstrim"
usrbinprogs_a="chfn chsh hexdump last logger mesg newgrp renice
utmpdump wall setsid chrt flock getopt"
binprogs_a="dmesg kill more umount mount login reset su"
--
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/3] separatebuilddir: build libproxy and taglib out of the source tree
Signed-off-by: Ross Burton
---
meta/conf/distro/include/seperatebuilddir.inc |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/conf/distro/include/seperatebuilddir.inc
b/meta/conf/distro/include/seperatebuilddir.inc
index e1a5c6b..a6df6ac 100644
--- a/meta/conf/distro/include/seperatebuilddir.inc
+++ b/meta/conf/distro/include/seperatebuilddir.inc
@@ -320,8 +320,7 @@ B_pn-libpcre = "${SEPB}"
B_pn-libpcre-native = "${SEPB}"
B_pn-libpng = "${SEPB}"
B_pn-libpng-native = "${SEPB}"
-# Needs automatic support in cmake.bbclass
-#B_pn-libproxy = "${SEPB}"
+B_pn-libproxy = "${SEPB}"
B_pn-libpthread-stubs = "${SEPB}"
B_pn-libpthread-stubs-native = "${SEPB}"
B_pn-librsvg = "${SEPB}"
@@ -660,6 +659,7 @@ B_pn-sysprof = "${SEPB}"
B_pn-systemd = "${SEPB}"
B_pn-systemtap = "${SEPB}"
B_pn-systemtap-native = "${SEPB}"
+B_pn-taglib = "${SEPB}"
B_pn-tar = "${SEPB}"
B_pn-tar-replacement-native = "${SEPB}"
B_pn-tcl = "${SEPB}"
--
1.7.10.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] unmaintained layers
Hi, meta-erlang > maintained. -- João Henrique Ferreira de Freitas - joaohf_at_gmail.com Campinas-SP-Brasil ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH][V2 2/5] python-mako: add (from meta-oe)
On 01/10/2014 09:02 AM, Ross Burton wrote:
python-mako is needed for Piglit. This recipe is taken directly from meta-oe.
Signed-off-by: Ross Burton
---
meta/recipes-devtools/python/python-mako_0.7.2.bb | 22 +
1 file changed, 22 insertions(+)
create mode 100644 meta/recipes-devtools/python/python-mako_0.7.2.bb
diff --git a/meta/recipes-devtools/python/python-mako_0.7.2.bb
b/meta/recipes-devtools/python/python-mako_0.7.2.bb
new file mode 100644
index 000..1d2bdd7
--- /dev/null
+++ b/meta/recipes-devtools/python/python-mako_0.7.2.bb
@@ -0,0 +1,22 @@
+DESCRIPTION = "Templating library for Python"
+SECTION = "devel/python"
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=da8dd26ed9751ee0cfdf9df1a16bbb54"
+
+PR = "r2"
+
+SRC_URI = "http://www.makotemplates.org/downloads/Mako-${PV}.tar.gz";
Seems like they might have moved or lost these files since you tested,
the upstream is at 0.9.1 and has moved these files to
https://pypi.python.org/packages/source/M/Mako/Mako-0.7.2.tar.gz
Sau!
+SRC_URI[md5sum] = "e3c0a677aa4216da9e89ef8fa76cbafb"
+SRC_URI[sha256sum] =
"fe8698e845035586bd711a6748e4e40a208a58de276b9138026164700494b68f"
+
+S = "${WORKDIR}/Mako-${PV}"
+
+inherit setuptools
+
+RDEPENDS_${PN} = "python-threading \
+ python-netclient \
+ python-html \
+"
+RDEPENDS_${PN}_class-native = ""
+
+BBCLASSEXTEND = "native nativesdk"
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
