Re: [OE-core] [PATCH] Rename 'BRANCH' variable to 'SRC_BRANCH' for clearness
On 2015-08-21 05:58 PM, Otavio Salvador wrote: On Fri, Aug 21, 2015 at 6:49 PM, Khem Raj raj.k...@gmail.com wrote: On Aug 21, 2015, at 2:38 PM, Otavio Salvador ota...@ossystems.com.br wrote: The 'BRANCH' variable name has no explicit relation with the SRC_URI. Using 'SRC_BRANCH' makes it more obvious and easier to identify. Look good to me, just may be avoid ‘_’ and call it SRCBRANCH I did this initially but looking at how it looks in the source code, it seems SRC_BRANCH makes easier to spot the relation with SRC_URI. So I took the second. +1 -- # Randy MacLeod. SMTS, Linux, Wind River Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON, Canada, K2K 2W5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] meta: remove unneeded INSANE_SKIP
The following changes since commit c38acd720b3f6ffbeb544063692eb471dada8593: binconfig-disabled: write an message to stderr to help confused developers (2015-08-19 17:57:58 +0100) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib rbt/insane http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/insane Robert Yang (1): meta: remove unneeded INSANE_SKIP meta/recipes-bsp/grub/grub_2.00.bb |3 --- meta/recipes-bsp/grub/grub_git.bb |3 --- meta/recipes-core/dbus/dbus.inc |2 -- meta/recipes-core/glib-2.0/glib.inc |2 -- meta/recipes-devtools/pseudo/pseudo.inc |2 -- meta/recipes-devtools/syslinux/syslinux_6.03.bb |2 -- meta/recipes-extended/ltp/ltp_20150420.bb |2 -- meta/recipes-kernel/kexec/kexec-tools.inc |2 -- meta/recipes-kernel/lttng/lttng-tools_2.6.0.bb |2 -- 9 files changed, 20 deletions(-) -- 1.7.9.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] uclibc: Add SRCBRANCH for use by SRC_URI
On Thu, Aug 20, 2015 at 11:19 PM, Khem Raj raj.k...@gmail.com wrote:
On Thu, Aug 20, 2015 at 12:32 AM, Yen-Chin Lee coldnew...@gmail.com wrote:
-SRC_URI = git://uclibc.org/uClibc.git;branch=master \
+SRCBRANCH ??= master
+
+SRC_URI = git://uclibc.org/uClibc.git;branch=${SRCBRANCH} \
this is ok. Just call is BRANCH instead of SRCBRANCH
Personally I prefer SRCBRANCH. This is personal option though.
--
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 1/1] meta: remove unneeded INSANE_SKIP
On 08/21/2015 06:24 PM, Robert Yang wrote:
The build works well after remove INSANE_SKIP from the following
recipes:
meta/recipes-bsp/grub/grub_2.00.bb
meta/recipes-bsp/grub/grub_git.bb
meta/recipes-core/dbus/dbus.inc
Sorry, the one for dbus should be kept:
INSANE_SKIP_${PN}-ptest += build-deps
I've updated this in the repo.
// Robert
meta/recipes-core/glib-2.0/glib.inc
meta/recipes-devtools/pseudo/pseudo.inc
meta/recipes-devtools/syslinux/syslinux_6.03.bb
meta/recipes-extended/ltp/ltp_20150420.bb
meta/recipes-kernel/kexec/kexec-tools.inc
meta/recipes-kernel/lttng/lttng-tools_2.6.0.bb
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
meta/recipes-bsp/grub/grub_2.00.bb |3 ---
meta/recipes-bsp/grub/grub_git.bb |3 ---
meta/recipes-core/dbus/dbus.inc |2 --
meta/recipes-core/glib-2.0/glib.inc |2 --
meta/recipes-devtools/pseudo/pseudo.inc |2 --
meta/recipes-devtools/syslinux/syslinux_6.03.bb |2 --
meta/recipes-extended/ltp/ltp_20150420.bb |2 --
meta/recipes-kernel/kexec/kexec-tools.inc |2 --
meta/recipes-kernel/lttng/lttng-tools_2.6.0.bb |2 --
9 files changed, 20 deletions(-)
diff --git a/meta/recipes-bsp/grub/grub_2.00.bb
b/meta/recipes-bsp/grub/grub_2.00.bb
index 88a709e..25b32c7 100644
--- a/meta/recipes-bsp/grub/grub_2.00.bb
+++ b/meta/recipes-bsp/grub/grub_2.00.bb
@@ -12,6 +12,3 @@ EXTRA_OECONF = --with-platform=pc --disable-grub-mkfont
--program-prefix= \
do_install_append () {
install -d ${D}${sysconfdir}/grub.d
}
-
-INSANE_SKIP_${PN} = arch
-INSANE_SKIP_${PN}-dbg = arch
diff --git a/meta/recipes-bsp/grub/grub_git.bb
b/meta/recipes-bsp/grub/grub_git.bb
index c2760c9..c8ea283 100644
--- a/meta/recipes-bsp/grub/grub_git.bb
+++ b/meta/recipes-bsp/grub/grub_git.bb
@@ -45,6 +45,3 @@ INHIBIT_PACKAGE_DEBUG_SPLIT = 1
RDEPENDS_${PN} = diffutils freetype
FILES_${PN}-dbg += ${libdir}/${BPN}/*/.debug
-
-INSANE_SKIP_${PN} = arch
-INSANE_SKIP_${PN}-dbg = arch
diff --git a/meta/recipes-core/dbus/dbus.inc b/meta/recipes-core/dbus/dbus.inc
index 3971081..01066cb 100644
--- a/meta/recipes-core/dbus/dbus.inc
+++ b/meta/recipes-core/dbus/dbus.inc
@@ -166,5 +166,3 @@ do_install_class-nativesdk() {
rm -rf ${D}${localstatedir}/run
}
BBCLASSEXTEND = native nativesdk
-
-INSANE_SKIP_${PN}-ptest += build-deps
diff --git a/meta/recipes-core/glib-2.0/glib.inc
b/meta/recipes-core/glib-2.0/glib.inc
index 072f790..0ef8500 100644
--- a/meta/recipes-core/glib-2.0/glib.inc
+++ b/meta/recipes-core/glib-2.0/glib.inc
@@ -100,5 +100,3 @@ RDEPENDS_${PN}-ptest_append_libc-glibc = \
glibc-charmap-invariant \
glibc-localedata-translit-cjk-variants \
-
-INSANE_SKIP_${PN}-ptest += libdir
diff --git a/meta/recipes-devtools/pseudo/pseudo.inc
b/meta/recipes-devtools/pseudo/pseudo.inc
index fe12258..371b780 100644
--- a/meta/recipes-devtools/pseudo/pseudo.inc
+++ b/meta/recipes-devtools/pseudo/pseudo.inc
@@ -11,8 +11,6 @@ DEPENDS = sqlite3 attr
FILES_${PN} = ${prefix}/lib/pseudo/lib*/libpseudo.so ${bindir}/*
${localstatedir}/pseudo ${prefix}/var/pseudo
FILES_${PN}-dbg += ${prefix}/lib/pseudo/lib*/.debug
-INSANE_SKIP_${PN} += libdir
-INSANE_SKIP_${PN}-dbg += libdir
PROVIDES += virtual/fakeroot
diff --git a/meta/recipes-devtools/syslinux/syslinux_6.03.bb
b/meta/recipes-devtools/syslinux/syslinux_6.03.bb
index ef9ae2f..5b5fa0b 100644
--- a/meta/recipes-devtools/syslinux/syslinux_6.03.bb
+++ b/meta/recipes-devtools/syslinux/syslinux_6.03.bb
@@ -28,8 +28,6 @@ SRC_URI[sha256sum] =
26d3986d2bea109d5dc0e4f8c4822a459276cf021125e8c9f23c3cca5d
COMPATIBLE_HOST = '(x86_64|i.86).*-(linux|freebsd.*)'
# Don't let the sanity checker trip on the 32 bit real mode BIOS binaries
-INSANE_SKIP_${PN}-misc = arch
-INSANE_SKIP_${PN}-chain = arch
EXTRA_OEMAKE = \
BINDIR=${bindir} SBINDIR=${sbindir} LIBDIR=${libdir} \
diff --git a/meta/recipes-extended/ltp/ltp_20150420.bb
b/meta/recipes-extended/ltp/ltp_20150420.bb
index 108ebf1..bec2e12 100644
--- a/meta/recipes-extended/ltp/ltp_20150420.bb
+++ b/meta/recipes-extended/ltp/ltp_20150420.bb
@@ -82,5 +82,3 @@ FILES_${PN} += /opt/ltp/* /opt/ltp/runtest/*
/opt/ltp/scenario_groups/* /opt/lt
INHIBIT_PACKAGE_STRIP = 1
INHIBIT_PACKAGE_DEBUG_SPLIT = 1
# However, test_arch_stripped is already stripped, so...
-INSANE_SKIP_${PN} += already-stripped
-
diff --git a/meta/recipes-kernel/kexec/kexec-tools.inc
b/meta/recipes-kernel/kexec/kexec-tools.inc
index 7797a25..20818e6 100644
--- a/meta/recipes-kernel/kexec/kexec-tools.inc
+++ b/meta/recipes-kernel/kexec/kexec-tools.inc
@@ -16,8 +16,6 @@ inherit autotools
COMPATIBLE_HOST =
'(x86_64.*|i.86.*|arm.*|aarch64.*|powerpc.*|mips.*)-(linux|freebsd.*)'
-INSANE_SKIP_${PN} = arch
-
do_compile_prepend() {
# Remove the '*.d' file to make sure the recompile is OK
for dep in `find ${B} -type f -name '*.d'`; do
diff --git
Re: [OE-core] [RFC PATCH 1/1] classes/whitelist: add class to allow whitelisting recipes from a layer
On Wed, 2015-08-19 at 14:34 +0100, Paul Eggleton wrote: Allow restricting recipes brought from a layer to a specified list. This is similar in operation to blacklist.bbclass, but instead specifies a per-layer whitelist of recipes (matched by BPN) that are able to be built from the layer - anything else is skipped. This is potentially useful where you want to bring in a select set of recipes from a larger layer e.g. meta-oe. Implements [YOCTO #8150]. Signed-off-by: Paul Eggleton paul.eggle...@linux.intel.com --- meta/classes/whitelist.bbclass | 28 1 file changed, 28 insertions(+) create mode 100644 meta/classes/whitelist.bbclass I should go on record as having some pretty strong reservations about this from a philosophical standpoint. Why? I think its going to encourage behaviours which will result in a decrease in layer quality, particularly for meta-oe. Taking a simple example, today if someone breaks parsing in meta-oe, its quickly known about and multiple people can see and resolve the issue. Once people start using this class, many users will simply never see/care about parsing breakage in less maintained parts of the layer. I appreciate Martin will likely notice, however this shouldn't Martin's sole responsibility. Since people's focus will be on to narrow parts of the layer, we'll start to see islands which are well maintained/used and islands which are not. Worse, just looking at the layer, we won't be able to tell which is which. I'm nervous about anything which pushes responsibility onto already overloaded maintainers and encourages behaviour which is a net loss on quality. I've talked to several significant users and they all love the idea of this class and plan to adopt it ASAP over existing tools like combo-layer. I therefore can't see much advantage of not merging the class as people are going to use it regardless. Speaking of it, combo-layer was designed to be an alternative way of dealing with these issues (more pain to use but causing less of a quality impact). Sadly, whilst it has seen some improvements, it still doesn't handle every operation it would need to make it work for some users and isn't widely adopted. I simply don't have the time to go and push it forward. So my objection is on record but that is likely about all I can do, other than hope I'm overly paranoid... Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/5] man-pages: 4.01 - 4.02
On 21 August 2015 at 13:15, Robert Yang liezhi.y...@windriver.com wrote:
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
.../{man-pages_4.01.bb = man-pages_4.02.bb} |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-extended/man-pages/{man-pages_4.01.bb =
man-pages_4.02.bb} (86%)
Maxin sent this patch yesterday already.
- Jussi
diff --git a/meta/recipes-extended/man-pages/man-pages_4.01.bb
b/meta/recipes-extended/man-pages/man-pages_4.02.bb
similarity index 86%
rename from meta/recipes-extended/man-pages/man-pages_4.01.bb
rename to meta/recipes-extended/man-pages/man-pages_4.02.bb
index f6a5c49..1b90a44 100644
--- a/meta/recipes-extended/man-pages/man-pages_4.01.bb
+++ b/meta/recipes-extended/man-pages/man-pages_4.02.bb
@@ -7,8 +7,8 @@ LICENSE = GPLv2+
LIC_FILES_CHKSUM = file://README;md5=8f2a3d43057d458e5066714980567a60
SRC_URI = ${KERNELORG_MIRROR}/linux/docs/${BPN}/Archive/${BP}.tar.gz
-SRC_URI[md5sum] = 575f4e8920166b1433c329bb621819d1
-SRC_URI[sha256sum] =
ba89f3453982fae6c699a877368d51ee27883b4de709e753eee3783b447a8381
+SRC_URI[md5sum] = 93df3279798a3345bb2c709584c83639
+SRC_URI[sha256sum] =
42324f9ed47c89a43cb37b6bb0d5fbcad44838eee45cd394e181c98d038c49ff
RDEPENDS_${PN} = man
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 1/1] classes/whitelist: add class to allow whitelisting recipes from a layer
On Fri, Aug 21, 2015 at 7:45 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Wed, 2015-08-19 at 14:34 +0100, Paul Eggleton wrote: Allow restricting recipes brought from a layer to a specified list. This is similar in operation to blacklist.bbclass, but instead specifies a per-layer whitelist of recipes (matched by BPN) that are able to be built from the layer - anything else is skipped. This is potentially useful where you want to bring in a select set of recipes from a larger layer e.g. meta-oe. Implements [YOCTO #8150]. Signed-off-by: Paul Eggleton paul.eggle...@linux.intel.com --- meta/classes/whitelist.bbclass | 28 1 file changed, 28 insertions(+) create mode 100644 meta/classes/whitelist.bbclass I should go on record as having some pretty strong reservations about this from a philosophical standpoint. Why? I think its going to encourage behaviours which will result in a decrease in layer quality, particularly for meta-oe. Taking a simple example, today if someone breaks parsing in meta-oe, its quickly known about and multiple people can see and resolve the issue. Once people start using this class, many users will simply never see/care about parsing breakage in less maintained parts of the layer. I appreciate Martin will likely notice, however this shouldn't Martin's sole responsibility. Since people's focus will be on to narrow parts of the layer, we'll start to see islands which are well maintained/used and islands which are not. Worse, just looking at the layer, we won't be able to tell which is which. I'm nervous about anything which pushes responsibility onto already overloaded maintainers and encourages behaviour which is a net loss on quality. I've talked to several significant users and they all love the idea of this class and plan to adopt it ASAP over existing tools like combo-layer. I therefore can't see much advantage of not merging the class as people are going to use it regardless. Speaking of it, combo-layer was designed to be an alternative way of dealing with these issues (more pain to use but causing less of a quality impact). Sadly, whilst it has seen some improvements, it still doesn't handle every operation it would need to make it work for some users and isn't widely adopted. I simply don't have the time to go and push it forward. So my objection is on record but that is likely about all I can do, other than hope I'm overly paranoid... I fully support your objection and I also nervous about this one. Often vendors want to narrow their responsibility and focus so this class opens the door for this to be done officially. :-( -- 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/1] meta: remove unneeded INSANE_SKIP
The build works well after remove INSANE_SKIP from the following
recipes:
meta/recipes-bsp/grub/grub_2.00.bb
meta/recipes-bsp/grub/grub_git.bb
meta/recipes-core/dbus/dbus.inc
meta/recipes-core/glib-2.0/glib.inc
meta/recipes-devtools/pseudo/pseudo.inc
meta/recipes-devtools/syslinux/syslinux_6.03.bb
meta/recipes-extended/ltp/ltp_20150420.bb
meta/recipes-kernel/kexec/kexec-tools.inc
meta/recipes-kernel/lttng/lttng-tools_2.6.0.bb
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
meta/recipes-bsp/grub/grub_2.00.bb |3 ---
meta/recipes-bsp/grub/grub_git.bb |3 ---
meta/recipes-core/dbus/dbus.inc |2 --
meta/recipes-core/glib-2.0/glib.inc |2 --
meta/recipes-devtools/pseudo/pseudo.inc |2 --
meta/recipes-devtools/syslinux/syslinux_6.03.bb |2 --
meta/recipes-extended/ltp/ltp_20150420.bb |2 --
meta/recipes-kernel/kexec/kexec-tools.inc |2 --
meta/recipes-kernel/lttng/lttng-tools_2.6.0.bb |2 --
9 files changed, 20 deletions(-)
diff --git a/meta/recipes-bsp/grub/grub_2.00.bb
b/meta/recipes-bsp/grub/grub_2.00.bb
index 88a709e..25b32c7 100644
--- a/meta/recipes-bsp/grub/grub_2.00.bb
+++ b/meta/recipes-bsp/grub/grub_2.00.bb
@@ -12,6 +12,3 @@ EXTRA_OECONF = --with-platform=pc --disable-grub-mkfont
--program-prefix= \
do_install_append () {
install -d ${D}${sysconfdir}/grub.d
}
-
-INSANE_SKIP_${PN} = arch
-INSANE_SKIP_${PN}-dbg = arch
diff --git a/meta/recipes-bsp/grub/grub_git.bb
b/meta/recipes-bsp/grub/grub_git.bb
index c2760c9..c8ea283 100644
--- a/meta/recipes-bsp/grub/grub_git.bb
+++ b/meta/recipes-bsp/grub/grub_git.bb
@@ -45,6 +45,3 @@ INHIBIT_PACKAGE_DEBUG_SPLIT = 1
RDEPENDS_${PN} = diffutils freetype
FILES_${PN}-dbg += ${libdir}/${BPN}/*/.debug
-
-INSANE_SKIP_${PN} = arch
-INSANE_SKIP_${PN}-dbg = arch
diff --git a/meta/recipes-core/dbus/dbus.inc b/meta/recipes-core/dbus/dbus.inc
index 3971081..01066cb 100644
--- a/meta/recipes-core/dbus/dbus.inc
+++ b/meta/recipes-core/dbus/dbus.inc
@@ -166,5 +166,3 @@ do_install_class-nativesdk() {
rm -rf ${D}${localstatedir}/run
}
BBCLASSEXTEND = native nativesdk
-
-INSANE_SKIP_${PN}-ptest += build-deps
diff --git a/meta/recipes-core/glib-2.0/glib.inc
b/meta/recipes-core/glib-2.0/glib.inc
index 072f790..0ef8500 100644
--- a/meta/recipes-core/glib-2.0/glib.inc
+++ b/meta/recipes-core/glib-2.0/glib.inc
@@ -100,5 +100,3 @@ RDEPENDS_${PN}-ptest_append_libc-glibc = \
glibc-charmap-invariant \
glibc-localedata-translit-cjk-variants \
-
-INSANE_SKIP_${PN}-ptest += libdir
diff --git a/meta/recipes-devtools/pseudo/pseudo.inc
b/meta/recipes-devtools/pseudo/pseudo.inc
index fe12258..371b780 100644
--- a/meta/recipes-devtools/pseudo/pseudo.inc
+++ b/meta/recipes-devtools/pseudo/pseudo.inc
@@ -11,8 +11,6 @@ DEPENDS = sqlite3 attr
FILES_${PN} = ${prefix}/lib/pseudo/lib*/libpseudo.so ${bindir}/*
${localstatedir}/pseudo ${prefix}/var/pseudo
FILES_${PN}-dbg += ${prefix}/lib/pseudo/lib*/.debug
-INSANE_SKIP_${PN} += libdir
-INSANE_SKIP_${PN}-dbg += libdir
PROVIDES += virtual/fakeroot
diff --git a/meta/recipes-devtools/syslinux/syslinux_6.03.bb
b/meta/recipes-devtools/syslinux/syslinux_6.03.bb
index ef9ae2f..5b5fa0b 100644
--- a/meta/recipes-devtools/syslinux/syslinux_6.03.bb
+++ b/meta/recipes-devtools/syslinux/syslinux_6.03.bb
@@ -28,8 +28,6 @@ SRC_URI[sha256sum] =
26d3986d2bea109d5dc0e4f8c4822a459276cf021125e8c9f23c3cca5d
COMPATIBLE_HOST = '(x86_64|i.86).*-(linux|freebsd.*)'
# Don't let the sanity checker trip on the 32 bit real mode BIOS binaries
-INSANE_SKIP_${PN}-misc = arch
-INSANE_SKIP_${PN}-chain = arch
EXTRA_OEMAKE = \
BINDIR=${bindir} SBINDIR=${sbindir} LIBDIR=${libdir} \
diff --git a/meta/recipes-extended/ltp/ltp_20150420.bb
b/meta/recipes-extended/ltp/ltp_20150420.bb
index 108ebf1..bec2e12 100644
--- a/meta/recipes-extended/ltp/ltp_20150420.bb
+++ b/meta/recipes-extended/ltp/ltp_20150420.bb
@@ -82,5 +82,3 @@ FILES_${PN} += /opt/ltp/* /opt/ltp/runtest/*
/opt/ltp/scenario_groups/* /opt/lt
INHIBIT_PACKAGE_STRIP = 1
INHIBIT_PACKAGE_DEBUG_SPLIT = 1
# However, test_arch_stripped is already stripped, so...
-INSANE_SKIP_${PN} += already-stripped
-
diff --git a/meta/recipes-kernel/kexec/kexec-tools.inc
b/meta/recipes-kernel/kexec/kexec-tools.inc
index 7797a25..20818e6 100644
--- a/meta/recipes-kernel/kexec/kexec-tools.inc
+++ b/meta/recipes-kernel/kexec/kexec-tools.inc
@@ -16,8 +16,6 @@ inherit autotools
COMPATIBLE_HOST =
'(x86_64.*|i.86.*|arm.*|aarch64.*|powerpc.*|mips.*)-(linux|freebsd.*)'
-INSANE_SKIP_${PN} = arch
-
do_compile_prepend() {
# Remove the '*.d' file to make sure the recompile is OK
for dep in `find ${B} -type f -name '*.d'`; do
diff --git a/meta/recipes-kernel/lttng/lttng-tools_2.6.0.bb
b/meta/recipes-kernel/lttng/lttng-tools_2.6.0.bb
index 6397a98..39ada7b 100644
--- a/meta/recipes-kernel/lttng/lttng-tools_2.6.0.bb
+++
Re: [OE-core] [PATCH 4/5] btrfs-tools: 4.1.1 - 4.1.2
On 21 August 2015 at 13:15, Robert Yang liezhi.y...@windriver.com wrote: Signed-off-by: Robert Yang liezhi.y...@windriver.com --- .../btrfs-tools/btrfs-tools_git.bb |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-devtools/btrfs-tools/btrfs-tools_git.bb b/meta/recipes-devtools/btrfs-tools/btrfs-tools_git.bb index 4ad4b81..15cc3f2 100644 --- a/meta/recipes-devtools/btrfs-tools/btrfs-tools_git.bb +++ b/meta/recipes-devtools/btrfs-tools/btrfs-tools_git.bb @@ -12,7 +12,7 @@ LIC_FILES_CHKSUM = file://COPYING;md5=fcb02dc552a041dee27e4b85c7396067 SECTION = base DEPENDS = util-linux attr e2fsprogs lzo acl -SRCREV = 20be329fdb569fefdf88ba0e4ca1a41488fcbc19 +SRCREV = 7f1328ccb5d159efe850d4eaea9b49bbe8c4181e SRC_URI = git://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git \ file://fix-parallel.patch \ -- Is there no PV change here? 1.7.9.5 -- ___ 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 4/5] btrfs-tools: 4.1.1 - 4.1.2
On 08/21/2015 06:47 PM, Jussi Kukkonen wrote:
On 21 August 2015 at 13:15, Robert Yang liezhi.y...@windriver.com wrote:
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
.../btrfs-tools/btrfs-tools_git.bb |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/btrfs-tools/btrfs-tools_git.bb
b/meta/recipes-devtools/btrfs-tools/btrfs-tools_git.bb
index 4ad4b81..15cc3f2 100644
--- a/meta/recipes-devtools/btrfs-tools/btrfs-tools_git.bb
+++ b/meta/recipes-devtools/btrfs-tools/btrfs-tools_git.bb
@@ -12,7 +12,7 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=fcb02dc552a041dee27e4b85c7396067
SECTION = base
DEPENDS = util-linux attr e2fsprogs lzo acl
-SRCREV = 20be329fdb569fefdf88ba0e4ca1a41488fcbc19
+SRCREV = 7f1328ccb5d159efe850d4eaea9b49bbe8c4181e
SRC_URI =
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git \
file://fix-parallel.patch \
--
Is there no PV change here?
Thanks, I updated in the repo.
diff --git a/meta/recipes-devtools/btrfs-tools/btrfs-tools_git.bb
b/meta/recipes-devtools/btrfs-tools/btrfs-tools_git.bb
index 4ad4b81..ae6c8f4 100644
--- a/meta/recipes-devtools/btrfs-tools/btrfs-tools_git.bb
+++ b/meta/recipes-devtools/btrfs-tools/btrfs-tools_git.bb
@@ -12,7 +12,7 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=fcb02dc552a041dee27e4b85c7396067
SECTION = base
DEPENDS = util-linux attr e2fsprogs lzo acl
-SRCREV = 20be329fdb569fefdf88ba0e4ca1a41488fcbc19
+SRCREV = 7f1328ccb5d159efe850d4eaea9b49bbe8c4181e
SRC_URI = git://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git
\
file://fix-parallel.patch \
@@ -27,6 +27,6 @@ do_configure_prepend() {
S = ${WORKDIR}/git
-PV = 4.1.1+git${SRCPV}
+PV = 4.1.2+git${SRCPV}
// Robert
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/5] man-pages: 4.01 - 4.02
On 08/21/2015 06:45 PM, Jussi Kukkonen wrote:
On 21 August 2015 at 13:15, Robert Yang liezhi.y...@windriver.com wrote:
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
.../{man-pages_4.01.bb = man-pages_4.02.bb} |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-extended/man-pages/{man-pages_4.01.bb =
man-pages_4.02.bb} (86%)
Maxin sent this patch yesterday already.
Thanks, I dropped this one in the repo.
// Robert
- Jussi
diff --git a/meta/recipes-extended/man-pages/man-pages_4.01.bb
b/meta/recipes-extended/man-pages/man-pages_4.02.bb
similarity index 86%
rename from meta/recipes-extended/man-pages/man-pages_4.01.bb
rename to meta/recipes-extended/man-pages/man-pages_4.02.bb
index f6a5c49..1b90a44 100644
--- a/meta/recipes-extended/man-pages/man-pages_4.01.bb
+++ b/meta/recipes-extended/man-pages/man-pages_4.02.bb
@@ -7,8 +7,8 @@ LICENSE = GPLv2+
LIC_FILES_CHKSUM = file://README;md5=8f2a3d43057d458e5066714980567a60
SRC_URI = ${KERNELORG_MIRROR}/linux/docs/${BPN}/Archive/${BP}.tar.gz
-SRC_URI[md5sum] = 575f4e8920166b1433c329bb621819d1
-SRC_URI[sha256sum] =
ba89f3453982fae6c699a877368d51ee27883b4de709e753eee3783b447a8381
+SRC_URI[md5sum] = 93df3279798a3345bb2c709584c83639
+SRC_URI[sha256sum] =
42324f9ed47c89a43cb37b6bb0d5fbcad44838eee45cd394e181c98d038c49ff
RDEPENDS_${PN} = man
--
1.7.9.5
--
___
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] oeqa/oetest.py: add better pkg. search for hasPackage()
Modified hasPackage() to split the content of pkg. manifest file
in containing lines and search at the begining of each line the
existance of the needed pkg.
[YOCTO #8170]
Signed-off-by: Costin Constantin costin.c.constan...@intel.com
---
meta/lib/oeqa/oetest.py | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/meta/lib/oeqa/oetest.py b/meta/lib/oeqa/oetest.py
index dfed3de..9bfc76d 100644
--- a/meta/lib/oeqa/oetest.py
+++ b/meta/lib/oeqa/oetest.py
@@ -99,10 +99,12 @@ class oeTest(unittest.TestCase):
@classmethod
def hasPackage(self, pkg):
-
-if re.search(pkg, oeTest.tc.pkgmanifest):
-return True
-return False
+for item in oeTest.tc.pkgmanifest.split('\n'):
+if re.match(pkg, item):
+return True
+break
+else:
+return False
@classmethod
def hasFeature(self,feature):
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/3] libical: Upgrade 1.0.0 - 1.0.1
On 21 August 2015 at 08:08, Jussi Kukkonen jussi.kukko...@intel.com wrote: It does some fairly simple header autogeneration during build (see src/libical/Makefile.am and scripts/). As far as I can tell it does not require modules other than core -- but I don't know much about perl (especially in OE build) so let me know if there's gotchas I should look out for. In that case we can just the host perl, and don't need perlnative. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V2] systemd: Upgrade 219 - 224
This will help anyone who will make changes to this recipe in the future and will need to find out why certain things were done in the past. yeah, I have added pointers to commits instead. Thanks, it looks much better now! Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] perf: fix the check
On Fri, 2015-08-21 at 14:26 +0100, Burton, Ross wrote:
On 21 August 2015 at 09:06, rongqing...@windriver.com wrote:
+ if [ ${@perf_feature_enabled('perf-scripting', 1, 0,
d)} = 1 ] grep -q install-python_ext
${S}/tools/perf/Makefile; then
So now of course Python gets installed, but not packaged:
ERROR: QA Issue: perf: Files/directories were installed but not
shipped in any package:
/home
/home/pokybuild
/home/pokybuild/yocto-autobuilder
/home/pokybuild/yocto-autobuilder/yocto-worker
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-ppc-lsb
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-ppc-lsb/build
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-ppc-lsb/build/build
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-ppc-lsb/build/build/tmp
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-ppc-lsb/build/build/tmp/sysroots
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-ppc-lsb/build/build/tmp/sysroots/x86_64-linux
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-ppc-lsb/build/build/tmp/sysroots/x86_64-linux/usr
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-ppc-lsb/build/build/tmp/sysroots/x86_64-linux/usr/lib
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-ppc-lsb/build/build/tmp/sysroots/x86_64-linux/usr/lib/python2.7
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-ppc-lsb/build/build/tmp/sysroots/x86_64-linux/usr/lib/python2.7/site-packages
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-ppc-lsb/build/build/tmp/sysroots/x86_64-linux/usr/lib/python2.7/site-packages/perf.so
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-ppc-lsb/build/build/tmp/sysroots/x86_64-linux/usr/lib/python2.7/site-packages/perf-0.1-py2.7.egg-info
Please set FILES such that these items are packaged. Alternatively if
they are unneeded, avoid installing them or delete them within
do_install. [installed-vs-shipped]
Note that this is even more broken since these are native python files,
not suitable for the target. Or at least native directories have been
used for what should be target libraries.
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Try to fix qemu freezing due to full socket buffers
On 21 August 2015 at 14:41, Richard Purdie richard.pur...@linuxfoundation.org wrote: It was meant to fix the issue where qemu hangs and stops responding to network requests. Its a useful datapoint that the systemd issues remain though. Was there a systemd upgrade in mut out of interest (as another data point)? There's still plenty of builds so lets see what happens... There wasn't a systemd in that MUT, no. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] gnutls/nettle/gmp licensing and versions
On 18 August 2015 at 11:35, Martin Jansa martin.ja...@gmail.com wrote:
On Thu, Aug 13, 2015 at 03:42:45PM +0300, Jussi Kukkonen wrote:
On 12 August 2015 at 17:14, Jussi Kukkonen jussi.kukko...@intel.com wrote:
Hi,
I realise I'm a bit late (with the commit in master already) but I'm
looking at upgrading this recipe and had some questions on this patch
and the recipe in general.
On 9 August 2015 at 08:28, Armin Kuster akuster...@gmail.com wrote:
adding the license definitions on the few packages that
deviate from the overall package license.
based on http://www.lysator.liu.se/~nisse/nettle/nettle.html#Copyright
and spot checking files.
Signed-off-by: Armin Kuster akuster...@gmail.com
---
meta/recipes-support/nettle/nettle_2.7.1.bb | 9 +
1 file changed, 9 insertions(+)
diff --git a/meta/recipes-support/nettle/nettle_2.7.1.bb
b/meta/recipes-support/nettle/nettle_2.7.1.bb
index f53afcc..f9d331f 100644
--- a/meta/recipes-support/nettle/nettle_2.7.1.bb
+++ b/meta/recipes-support/nettle/nettle_2.7.1.bb
@@ -2,6 +2,15 @@ SUMMARY = A low level cryptographic library
HOMEPAGE = http://www.lysator.liu.se/~nisse/nettle/;
SECTION = libs
LICENSE = LGPLv2.1 GPLv2
I think this is wrong, whichever version you look at -- our current
version is just LGPLv2.1+, the current upstream release is LGPLv3+
| GPLv2+
I'm going to send a patch upgrading the recipe to the current upstream
release (and setting license to LGPLv3+ | GPLv2+): it might seem
like this makes gnutls effectively LGPLv3 but that actually happened
last year with the gmp upgrade. Comments on this welcome.
Alexander just pointed out to me that there was a discussion on gnutls
and nettle already in July (which I missed in my
back-from-holiday-email-binge). It seems that the consensus was to
preserve LGPLv2 versions.
This is what the current situation looks to me -- please correct if I'm
wrong:
* gmp is GPLv2+ | LGPLv3+
* nettle is LGPLv2.1+ but depends on gmp
* gnutls LGPLv2.1+ but depends on nettle
This effectively makes gnutls GPLv2+ | LGPLv3+ as far as I can see.
If we want to preserve a LGPLv2 gnutls, we need to bring back an older
version of gmp (I think 4.2.1).
I agree, recently we had to downgrade gmp to 4.2.1 in our layer to pass
our license check. Similarly we had to check that all nettle libraries
used in our image are LGPLv2.1 not GPLv2.0 - that's why I've suggested
to package them separately, so that we'll see only LGPLv2.1 nettle
package in our image.
Reading the commit log, it looks like gmp 4.2.1 was removed by
accident (the license problem was not understood at the time).
I've filed https://bugzilla.yoctoproject.org/show_bug.cgi?id=8197 for
this issue: we can continue there.
Bringing back 4.2.1 seems like the least worst option: if you have a
useful patch (other than just a revert of the removal), please let me
know.
Cheers,
Jussi
Regards,
+LICENSE_${PN}-cast = CC0
+LICENSE_${PN}-gosthash = MIT
+
+# both public and GPL license listed
+LICENSE_${PN}-md2 = CC0 LGPLv2.1+
+LICENSE_${PN}-md4 = CC0 LGPLv2.1+
From the reference I had the impression this LICENSE_something
construct would imply there is a package something. But the nettle
recipe does not produce nettle-cast or any of these. What is the
purpose here?
Thanks,
Jussi
+
+
LIC_FILES_CHKSUM =
file://COPYING.LIB;md5=2d5025d4aa3495befef8f17206a5b0a1 \
file://serpent-decrypt.c;beginline=53;endline=67;md5=bcfd4745d53ca57f82907089898e390d
\
file://serpent-set-key.c;beginline=56;endline=70;md5=bcfd4745d53ca57f82907089898e390d
--
2.3.5
--
___
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
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] perf: fix the check
On 21 August 2015 at 09:06, rongqing...@windriver.com wrote:
+ if [ ${@perf_feature_enabled('perf-scripting', 1, 0, d)} = 1
] grep -q install-python_ext ${S}/tools/perf/Makefile; then
So now of course Python gets installed, but not packaged:
ERROR: QA Issue: perf: Files/directories were installed but not shipped in
any package:
/home
/home/pokybuild
/home/pokybuild/yocto-autobuilder
/home/pokybuild/yocto-autobuilder/yocto-worker
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-ppc-lsb
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-ppc-lsb/build
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-ppc-lsb/build/build
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-ppc-lsb/build/build/tmp
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-ppc-lsb/build/build/tmp/sysroots
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-ppc-lsb/build/build/tmp/sysroots/x86_64-linux
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-ppc-lsb/build/build/tmp/sysroots/x86_64-linux/usr
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-ppc-lsb/build/build/tmp/sysroots/x86_64-linux/usr/lib
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-ppc-lsb/build/build/tmp/sysroots/x86_64-linux/usr/lib/python2.7
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-ppc-lsb/build/build/tmp/sysroots/x86_64-linux/usr/lib/python2.7/site-packages
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-ppc-lsb/build/build/tmp/sysroots/x86_64-linux/usr/lib/python2.7/site-packages/perf.so
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-ppc-lsb/build/build/tmp/sysroots/x86_64-linux/usr/lib/python2.7/site-packages/perf-0.1-py2.7.egg-info
Please set FILES such that these items are packaged. Alternatively if they
are unneeded, avoid installing them or delete them within do_install.
[installed-vs-shipped]
Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [poky][PATCH v4 1/2] gstreamer1.0: Fix ticky events haven't been sent out when active track reach EOS
EOS event hasn't been sent to down-element. The resolution is block EOS event
of inactive pad, sending the event after the pad actived.
Signed-off-by: Yuqing Zhu b54...@freescale.com
---
...cky-events-haven-t-send-out-when-ac-1-4-1.patch | 167 +
.../gstreamer/gstreamer1.0_1.4.5.bb| 1 +
2 files changed, 168 insertions(+)
create mode 100755
meta/recipes-multimedia/gstreamer/gstreamer1.0/inputselector-sticky-events-haven-t-send-out-when-ac-1-4-1.patch
diff --git
a/meta/recipes-multimedia/gstreamer/gstreamer1.0/inputselector-sticky-events-haven-t-send-out-when-ac-1-4-1.patch
b/meta/recipes-multimedia/gstreamer/gstreamer1.0/inputselector-sticky-events-haven-t-send-out-when-ac-1-4-1.patch
new file mode 100755
index 000..f50ce6f
--- /dev/null
+++
b/meta/recipes-multimedia/gstreamer/gstreamer1.0/inputselector-sticky-events-haven-t-send-out-when-ac-1-4-1.patch
@@ -0,0 +1,167 @@
+From 83bed90c306ed3185d48febf6441177d638f7341 Mon Sep 17 00:00:00 2001
+From: Song Bing b06...@freescale.com
+Date: Wed, 24 Dec 2014 10:13:51 +0800
+Subject: [PATCH] inputselector: sticky events haven't send out when active
+ track reach EOS
+
+EOS event hasn't been send to down-element. The resolution is block EOS event
+of inactive pad, send the event after the pad actived.
+
+https://bugzilla.gnome.org/show_bug.cgi?id=740949
+
+Upstream-Status: Backport [1.5.1]
+
+Signed-off-by: Song Bing b06...@freescale.com
+---
+ plugins/elements/gstinputselector.c | 58 ++-
+ plugins/elements/gstinputselector.h |1 +
+ 2 files changed, 45 insertions(+), 14 deletions(-)
+
+diff --git a/plugins/elements/gstinputselector.c
b/plugins/elements/gstinputselector.c
+index fb50802..4461f7c 100644
+--- a/plugins/elements/gstinputselector.c
b/plugins/elements/gstinputselector.c
+@@ -440,6 +440,17 @@ gst_selector_pad_iterate_linked_pads (GstPad * pad,
GstObject * parent)
+ }
+
+ static gboolean
++gst_input_selector_eos_wait (GstInputSelector * self, GstSelectorPad * pad)
++{
++ while (!self-eos !self-flushing !pad-flushing) {
++/* we can be unlocked here when we are shutting down (flushing) or when we
++ * get unblocked */
++GST_INPUT_SELECTOR_WAIT (self);
++ }
++ return self-flushing;
++}
++
++static gboolean
+ gst_selector_pad_event (GstPad * pad, GstObject * parent, GstEvent * event)
+ {
+ gboolean res = TRUE;
+@@ -486,6 +497,7 @@ gst_selector_pad_event (GstPad * pad, GstObject * parent,
GstEvent * event)
+ case GST_EVENT_FLUSH_START:
+ /* Unblock the pad if it's waiting */
+ selpad-flushing = TRUE;
++ sel-eos = FALSE;
+ GST_INPUT_SELECTOR_BROADCAST (sel);
+ break;
+ case GST_EVENT_FLUSH_STOP:
+@@ -523,21 +535,12 @@ gst_selector_pad_event (GstPad * pad, GstObject *
parent, GstEvent * event)
+ case GST_EVENT_EOS:
+ selpad-eos = TRUE;
+
+- if (forward) {
+-selpad-eos_sent = TRUE;
+- } else {
+-GstSelectorPad *active_selpad;
+-
+-/* If the active sinkpad is in EOS state but EOS
+- * was not sent downstream this means that the pad
+- * got EOS before it was set as active pad and that
+- * the previously active pad got EOS after it was
+- * active
+- */
+-active_selpad = GST_SELECTOR_PAD (active_sinkpad);
+-forward = (active_selpad-eos !active_selpad-eos_sent);
+-active_selpad-eos_sent = TRUE;
++ if (!forward) {
++/* blocked until active the sind pad or flush */
++gst_input_selector_eos_wait (sel, selpad);
++forward = TRUE;
+ }
++ selpad-eos_sent = TRUE;
+ GST_DEBUG_OBJECT (pad, received EOS);
+ break;
+ case GST_EVENT_GAP:{
+@@ -676,6 +679,12 @@ gst_input_selector_wait_running_time (GstInputSelector *
sel,
+ gst_input_selector_activate_sinkpad (sel, GST_PAD_CAST (selpad));
+ active_selpad = GST_SELECTOR_PAD_CAST (active_sinkpad);
+
++if (sel-eos) {
++ GST_DEBUG_OBJECT (sel, Not waiting because inputselector reach EOS.);
++ GST_INPUT_SELECTOR_UNLOCK (sel);
++ return FALSE;
++}
++
+ if (seg-format != GST_FORMAT_TIME) {
+ GST_DEBUG_OBJECT (selpad,
+ Not waiting because we don't have a TIME segment);
+@@ -971,6 +980,12 @@ gst_selector_pad_chain (GstPad * pad, GstObject * parent,
GstBuffer * buf)
+ GST_TIME_ARGS (GST_BUFFER_TIMESTAMP (buf)));
+
+ GST_INPUT_SELECTOR_LOCK (sel);
++ if (sel-eos) {
++GST_DEBUG_OBJECT (pad, inputselector eos.);
++GST_INPUT_SELECTOR_UNLOCK (sel);
++goto eos;
++ }
++
+ /* wait or check for flushing */
+ if (gst_input_selector_wait (sel, selpad)) {
+ GST_INPUT_SELECTOR_UNLOCK (sel);
+@@ -1151,6 +1166,13 @@ flushing:
+ res = GST_FLOW_FLUSHING;
+ goto done;
+ }
++eos:
++ {
++GST_DEBUG_OBJECT (pad, We are eos, discard buffer %p, buf);
++gst_buffer_unref (buf);
++res = GST_FLOW_EOS;
++goto done;
++ }
+ }
+
+ static
Re: [OE-core] [PATCH 4/5] btrfs-tools: 4.1.1 - 4.1.2
Is there no PV change here?
Thanks, I updated in the repo.
-PV = 4.1.1+git${SRCPV}
+PV = 4.1.2+git${SRCPV}
You can also rename the recipe to btrfs-tools_4.1.2.bb and remove the PV
altogether. The above form is only needed if you're taking something from
git that is not a pristine tagged release (i.e. when it is a tagged
commit+additional commits).
Alex
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Try to fix qemu freezing due to full socket buffers
On Fri, 2015-08-21 at 14:36 +0100, Burton, Ross wrote: On 20 August 2015 at 23:24, Randy Witt randy.e.w...@linux.intel.com wrote: Randy Witt (3): qemurunner.py: Move some class variables that should only be local qemurunner: Make create_socket() return data and use exceptions qemurunner: Use two serial ports and log console with a thread https://autobuilder.yoctoproject.org/main/builders/nightly-qa-systemd/builds/450/steps/Running%20Sanity%20Tests_2/logs/stdio If this was meant to fix the ttyS1 hangs, I'm sorry :( It was meant to fix the issue where qemu hangs and stops responding to network requests. Its a useful datapoint that the systemd issues remain though. Was there a systemd upgrade in mut out of interest (as another data point)? Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Try to fix qemu freezing due to full socket buffers
On 20 August 2015 at 23:24, Randy Witt randy.e.w...@linux.intel.com wrote: Randy Witt (3): qemurunner.py: Move some class variables that should only be local qemurunner: Make create_socket() return data and use exceptions qemurunner: Use two serial ports and log console with a thread https://autobuilder.yoctoproject.org/main/builders/nightly-qa-systemd/builds/450/steps/Running%20Sanity%20Tests_2/logs/stdio If this was meant to fix the ttyS1 hangs, I'm sorry :( Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] oeqa/oetest.py: add better pkg. search for hasPackage()
On 21 August 2015 at 12:37, Costin Constantin costin.c.constan...@intel.com
wrote:
+for item in oeTest.tc.pkgmanifest.split('\n'):
+if re.match(pkg, item):
+return True
+break
+else:
+return False
I just had to look up the for/else syntax as I'd never seen it before.
Whilst this works, the fact that the break statement is never executed (as
it returns beforehand) makes it a bit odd. Personally I'd have done:
for item in ...:
if re.match():
return True
return False
Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] nettle: clean up license information
On 08/21/2015 05:06 AM, Martin Jansa wrote:
On Fri, Aug 21, 2015 at 11:48:30AM +0300, Jussi Kukkonen wrote:
On 18 August 2015 at 11:03, Martin Jansa martin.ja...@gmail.com wrote:
On Sun, Aug 09, 2015 at 10:58:21AM +0530, Armin Kuster wrote:
adding the license definitions on the few packages that
deviate from the overall package license.
based on http://www.lysator.liu.se/~nisse/nettle/nettle.html#Copyright
and spot checking files.
Signed-off-by: Armin Kuster akuster...@gmail.com
---
meta/recipes-support/nettle/nettle_2.7.1.bb | 9 +
1 file changed, 9 insertions(+)
diff --git a/meta/recipes-support/nettle/nettle_2.7.1.bb
b/meta/recipes-support/nettle/nettle_2.7.1.bb
index f53afcc..f9d331f 100644
--- a/meta/recipes-support/nettle/nettle_2.7.1.bb
+++ b/meta/recipes-support/nettle/nettle_2.7.1.bb
@@ -2,6 +2,15 @@ SUMMARY = A low level cryptographic library
HOMEPAGE = http://www.lysator.liu.se/~nisse/nettle/;
SECTION = libs
LICENSE = LGPLv2.1 GPLv2
It would be nice to package GPLv2 files in separate package as well (or
LGPLv2.1 library in seprate package) if you have time to do that.
Forgot to answer this, sorry.
For 2.7.1 what you suggest may work -- there may be some tools that
are GPLv2 that we could separate. But for the new version the strange
LGPLv3+ | GPLv2+ license combo is _not_ a result of the library
being LGPL and some utilities being GPL: the library itself (like a
lot of GNU stuff nowadays) is dual licensed like that.
This means that we need to preserve nettle 2.7.1 for people who cannot
use LGPLv3 (and GPLv2 for libraries).
ok. SO if I resubmit the update, it should be an addition not
replacement. Would I define PREFERRED_VERSION then as well?
- armin
It seems weird but actually makes sense for GNU: It forces all users
to comply with LGPLv3, except the GPLv2 programs that can't easily be
relicensed to GPLv3. Those GPLv2 programs would be incompatible with
the newer LGPLv3 libraries but this dual-licensing lets them off the
hook.
Jussi
+LICENSE_${PN}-cast = CC0
+LICENSE_${PN}-gosthash = MIT
+
+# both public and GPL license listed
+LICENSE_${PN}-md2 = CC0 LGPLv2.1+
+LICENSE_${PN}-md4 = CC0 LGPLv2.1+
+
+
LIC_FILES_CHKSUM = file://COPYING.LIB;md5=2d5025d4aa3495befef8f17206a5b0a1 \
file://serpent-decrypt.c;beginline=53;endline=67;md5=bcfd4745d53ca57f82907089898e390d
\
file://serpent-set-key.c;beginline=56;endline=70;md5=bcfd4745d53ca57f82907089898e390d
--
2.3.5
--
___
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
--
___
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] [poky][PATCH v4 2/2] gstreamer1.0: Fix QoS/lateness checking if subclass implements prepare/prepare_list vfuncs
In function gst_base_sink_chain_unlocked(), it should calculate jitter based
on current media clock, rather than just passing 0.
Or it will drop all the frames when rewind in slow speed, such as -2X.
Signed-off-by: Yuqing Zhu b54...@freescale.com
---
...x-QoS-lateness-checking-if-subclass-imple.patch | 70 ++
.../gstreamer/gstreamer1.0_1.4.5.bb| 1 +
2 files changed, 71 insertions(+)
create mode 100644
meta/recipes-multimedia/gstreamer/gstreamer1.0/0002-basesink-Fix-QoS-lateness-checking-if-subclass-imple.patch
diff --git
a/meta/recipes-multimedia/gstreamer/gstreamer1.0/0002-basesink-Fix-QoS-lateness-checking-if-subclass-imple.patch
b/meta/recipes-multimedia/gstreamer/gstreamer1.0/0002-basesink-Fix-QoS-lateness-checking-if-subclass-imple.patch
new file mode 100644
index 000..b6edda1
--- /dev/null
+++
b/meta/recipes-multimedia/gstreamer/gstreamer1.0/0002-basesink-Fix-QoS-lateness-checking-if-subclass-imple.patch
@@ -0,0 +1,70 @@
+From 6914566ed6a89c96973a578aa5ecd01ee68cdcfd Mon Sep 17 00:00:00 2001
+From: Jian jian...@freescale.com
+Date: Thu, 14 May 2015 15:49:43 +0800
+Subject: [PATCH] basesink: Fix QoS/lateness checking if subclass implements
+ prepare/prepare_list vfuncs
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+In basesink functions gst_base_sink_chain_unlocked(), below code is used to
+checking if buffer is late before doing prepare call to save some effort:
+if (syncable do_sync)
+ late =
+ gst_base_sink_is_too_late (basesink, obj, rstart, rstop,
+ GST_CLOCK_EARLY, 0, FALSE);
+
+if (G_UNLIKELY (late))
+ goto dropped;
+
+But this code has problem, it should calculate jitter based on current media
+clock, rather than just passing 0. I found it will drop all the frames when
+rewind in slow speed, such as -2X.
+
+https://bugzilla.gnome.org/show_bug.cgi?id=749258
+
+Upstream-Status: Backport [1.5.1]
+---
+ libs/gst/base/gstbasesink.c | 26 ++
+ 1 file changed, 22 insertions(+), 4 deletions(-)
+
+diff --git a/libs/gst/base/gstbasesink.c b/libs/gst/base/gstbasesink.c
+index a505695..5fb2d6a 100644
+--- a/libs/gst/base/gstbasesink.c
b/libs/gst/base/gstbasesink.c
+@@ -3369,10 +3369,28 @@ gst_base_sink_chain_unlocked (GstBaseSink * basesink,
GstPad * pad,
+ if (G_UNLIKELY (stepped))
+ goto dropped;
+
+-if (syncable do_sync)
+- late =
+- gst_base_sink_is_too_late (basesink, obj, rstart, rstop,
+- GST_CLOCK_EARLY, 0, FALSE);
++if (syncable do_sync) {
++ GstClock *clock;
++
++ GST_OBJECT_LOCK (basesink);
++ clock = GST_ELEMENT_CLOCK (basesink);
++ if (clock GST_STATE (basesink) == GST_STATE_PLAYING) {
++GstClockTime base_time;
++GstClockTime stime;
++GstClockTime now;
++
++base_time = GST_ELEMENT_CAST (basesink)-base_time;
++stime = base_time + gst_base_sink_adjust_time (basesink, rstart);
++now = gst_clock_get_time (clock);
++GST_OBJECT_UNLOCK (basesink);
++
++late =
++gst_base_sink_is_too_late (basesink, obj, rstart, rstop,
++GST_CLOCK_EARLY, GST_CLOCK_DIFF (stime, now), FALSE);
++ } else {
++GST_OBJECT_UNLOCK (basesink);
++ }
++}
+
+ if (G_UNLIKELY (late))
+ goto dropped;
+--
+1.7.9.5
+
diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.4.5.bb
b/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.4.5.bb
index 902f79d..db58754 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.4.5.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.4.5.bb
@@ -8,6 +8,7 @@ SRC_URI = \
file://0001-Fix-crash-with-gst-inspect.patch \
file://0001-gstinfo-Shorten-__FILE__-on-all-platforms.patch \
file://inputselector-sticky-events-haven-t-send-out-when-ac-1-4-1.patch \
+file://0002-basesink-Fix-QoS-lateness-checking-if-subclass-imple.patch \
SRC_URI[md5sum] = 88a9289c64a4950ebb4f544980234289
SRC_URI[sha256sum] =
40801aa7f979024526258a0e94707ba42b8ab6f7d2206e56adbc4433155cb0ae
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [poky][PATCH v4 0/2] gstreamer1.0: Add patches for Gstreamer 1.4.5
Fix sticky events haven't been sent out when active track reach EOS Fix QoS/lateness checking if subclass implements prepare/prepare_list vfuncs Yuqing Zhu (2): gstreamer1.0: Fix ticky events haven't been sent out when active track reach EOS gstreamer1.0: Fix QoS/lateness checking if subclass implements prepare/prepare_list vfuncs ...x-QoS-lateness-checking-if-subclass-imple.patch | 70 + ...cky-events-haven-t-send-out-when-ac-1-4-1.patch | 167 + .../gstreamer/gstreamer1.0_1.4.5.bb| 2 + 3 files changed, 239 insertions(+) create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0/0002-basesink-Fix-QoS-lateness-checking-if-subclass-imple.patch create mode 100755 meta/recipes-multimedia/gstreamer/gstreamer1.0/inputselector-sticky-events-haven-t-send-out-when-ac-1-4-1.patch -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/4 V2] systemd: Upgrade 219 - 224
On Fri, Aug 21, 2015 at 3:14 AM, ChenQi qi.c...@windriver.com wrote: Hi Khem, I built core-image-minimal for qemuarm64. There's a lot of failures and warnings at boot time and the system boots into rescue mode. Can you paste the boot logs somewhere ? And I also verified 199 has no such problem. Best Regards, Chen Qi On 08/21/2015 09:46 AM, Randy MacLeod wrote: On 2015-08-20 09:17 PM, Khem Raj wrote: On Thu, Aug 20, 2015 at 6:04 AM, Philip Balister phi...@balister.org wrote: On 08/19/2015 10:21 PM, Khem Raj wrote: On Wed, Aug 19, 2015 at 12:55 PM, Burton, Ross ross.bur...@intel.com wrote: On 17 August 2015 at 16:41, Khem Raj raj.k...@gmail.com wrote: There are many reasons, for me its overlay support for systemd-nspawn, networkd has got many new features that is now usable w.r.t. IP forwarding, vxlan etc. and it has many bug fixed in those 2000 odd commits since 219, no different then any other package upgrades we do in general it keep the upgrade workload lower as we roll the releases. Any specific concerns ? Can we get an updated patch with a clearer commit log? I've also heard that as systemd evolves, more binaries are getting added to the base package that should be packaged separately for people interested in small images. I do not have personal experience here, but wanted to pass along the feedback. We should look at buildhistory packaging differences when we do upgrades. Here is the diff between files in 219 and 224, if you want to know more I can paste more info just let me know. https://gist.github.com/kraj/2a066973a5e5cf83ed24 sizes have gone up on daemons, no new daemons besides some new service files and scripts are added ubu-15.10 will use v224 as well: http://cdimage.ubuntu.com/daily-live/current/wily-desktop-amd64.manifest and Arch and a couple other distro are using this version already: http://pkgs.org/download/systemd v224 was released 3 weeks ago: --- $ git log -1 v224 commit b2a0ac5e5b29c73ca7c0da23369a4769d5a91ddd ... Date: Fri Jul 31 18:56:38 2015 +0200 --- Khem's summary of the binaries is reassuring given that there has been lots of churn: $ git log --oneline v219..v224 | wc -l 2167 $ git diff v219..v224 | diffstat | tail -1 1367 files changed, 109907 insertions(+), 166577 deletions(-) I'm skimming the NEWS file from 219-224 and I haven't seen anything that concerns me yet: https://github.com/systemd/systemd/blob/master/NEWS Qi, Please take a closer look at the NEWS file, review Khem's uprev and build and boot qemuarm64, qemuppc when you have time. Send partial feedback today even if you just review the commit and NEWS file. Qi may not be able to do that in the next couple of day due to SDK work. Khem, What testing have you done so far? Any ptest? What toolchain version are you building with, btw? It's late in M3 and we still have the kernel and toolchain coming in but unless we hear of known problems with v224, let's go for it once the new toolchain and kernel have settled. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] nettle: clean up license information
On Fri, Aug 21, 2015 at 07:31:40AM -0700, akuster808 wrote:
On 08/21/2015 05:06 AM, Martin Jansa wrote:
On Fri, Aug 21, 2015 at 11:48:30AM +0300, Jussi Kukkonen wrote:
On 18 August 2015 at 11:03, Martin Jansa martin.ja...@gmail.com wrote:
On Sun, Aug 09, 2015 at 10:58:21AM +0530, Armin Kuster wrote:
adding the license definitions on the few packages that
deviate from the overall package license.
based on http://www.lysator.liu.se/~nisse/nettle/nettle.html#Copyright
and spot checking files.
Signed-off-by: Armin Kuster akuster...@gmail.com
---
meta/recipes-support/nettle/nettle_2.7.1.bb | 9 +
1 file changed, 9 insertions(+)
diff --git a/meta/recipes-support/nettle/nettle_2.7.1.bb
b/meta/recipes-support/nettle/nettle_2.7.1.bb
index f53afcc..f9d331f 100644
--- a/meta/recipes-support/nettle/nettle_2.7.1.bb
+++ b/meta/recipes-support/nettle/nettle_2.7.1.bb
@@ -2,6 +2,15 @@ SUMMARY = A low level cryptographic library
HOMEPAGE = http://www.lysator.liu.se/~nisse/nettle/;
SECTION = libs
LICENSE = LGPLv2.1 GPLv2
It would be nice to package GPLv2 files in separate package as well (or
LGPLv2.1 library in seprate package) if you have time to do that.
Forgot to answer this, sorry.
For 2.7.1 what you suggest may work -- there may be some tools that
are GPLv2 that we could separate. But for the new version the strange
LGPLv3+ | GPLv2+ license combo is _not_ a result of the library
being LGPL and some utilities being GPL: the library itself (like a
lot of GNU stuff nowadays) is dual licensed like that.
This means that we need to preserve nettle 2.7.1 for people who cannot
use LGPLv3 (and GPLv2 for libraries).
ok. SO if I resubmit the update, it should be an addition not
replacement. Would I define PREFERRED_VERSION then as well?
You don't need PREFERRED_VERSION.
Latest will be used by default and setups with incompatible license will
skip the latest and use 2.7.1 one.
- armin
It seems weird but actually makes sense for GNU: It forces all users
to comply with LGPLv3, except the GPLv2 programs that can't easily be
relicensed to GPLv3. Those GPLv2 programs would be incompatible with
the newer LGPLv3 libraries but this dual-licensing lets them off the
hook.
Jussi
+LICENSE_${PN}-cast = CC0
+LICENSE_${PN}-gosthash = MIT
+
+# both public and GPL license listed
+LICENSE_${PN}-md2 = CC0 LGPLv2.1+
+LICENSE_${PN}-md4 = CC0 LGPLv2.1+
+
+
LIC_FILES_CHKSUM =
file://COPYING.LIB;md5=2d5025d4aa3495befef8f17206a5b0a1 \
file://serpent-decrypt.c;beginline=53;endline=67;md5=bcfd4745d53ca57f82907089898e390d
\
file://serpent-set-key.c;beginline=56;endline=70;md5=bcfd4745d53ca57f82907089898e390d
--
2.3.5
--
___
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
--
___
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] [PATCHv2 1/1] screen: Upgrade 4.0.3 - 4.3.1
From: Khem Raj [raj.k...@gmail.com] Sent: Thursday, August 20, 2015 2:41 PM To: BURTON, ROSS Cc: Radzykewycz, T (Radzy); Patches and discussions about the oe-core layer Subject: Re: [OE-core] [PATCHv2 1/1] screen: Upgrade 4.0.3 - 4.3.1 On Thu, Aug 20, 2015 at 2:34 PM, Burton, Ross ross.bur...@intel.com wrote: Basically you need to have a good reason why oe-core should invest the time maintaining both modern screen and ancient screen (4.0.3 was released in 2008). The easiest solution would be for your distro to maintain a copy of ancient screen for people who want screen but also don't want GPLv3. Or, switch to tmux which is BSD licensed. I think this will be common interest for more than one distro or person. It will be good to start moving them into a new layer under meta-openembedded repo, something like meta-gplv2-pinned or somethings, then users who are interested can prioritize this layer over oe-core and there by use these versions easily instead of what comes from oe-core. Thanks. That sounds like a good approach. Now to go investigate tmux -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 5/5] rpm: update to 5.4.15
The autobuilder exploded with failures like: https://autobuilder.yoctoproject.org/main/builders/build-appliance/builds/430/steps/BuildImages_1/logs/stdio which are due to the installed manifest file listing installed packages being empty. After spending some time with this issue I have to give up (for now). Rpm seems to install the packages without any errors, but the database of what is installed isn't updated correctly (rootfs/var/lib/rpm/Packages is empty, but there are also __db.00N files in the same directory which weren't there when the previous rpm version was in use). Then when rpm is later asked to provide a list of installed packages, it returns nothing and image build breaks down. If there are any rpm specialists around, feel free to pick it up: https://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=akanavin/package-version-updates-rpm-db-incomplete Regards, Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Yocto Project Status WW34
Current Dev Position: 1.9 Milestone 3 (M3) Next Deadline: M3 cut off of August 24th at noon GMT SWAT team rotation: Tracy - Alejandro https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team Key Status/Updates: * The autobuilder situation has become problematic as it appears some things we think are being built are not what is actually being built. We're looking into the scope of the issue, we're hoping it's contained within a small subset of builds and the milestone/master releases are not affected but this yet to be confirmed. * We did add automated runtime testing of the SDK (-c testsdk) and automated runtime testing of LSB images which wasn't previously being tested. This significantly increases the automated coverage of project artefacts. * We have a potential fix for the qemu networking hang which turns out to be a qemu serial port issue, thanks to Randy for figuring that out! * We also have a lead on the systemd ttyS0 failure to start (thanks Anibal!) and a way to reproduce it but no fix yet for it. * The autobuilder situation combined with everything else means patches are delaying being merged and the M3 release cutoff/feature freeze will be delayed. * RP is on vacation for the second half of next week. Key YP 1.9 Dates: YP Final - 2.0 Cut off: Sept. 28, 2015 noon GMT 1.9 M3 Release Target: Before Sept. 11 2015 2.0 final Release Target: Before Oct. 30, 2015 Key Status Links for YP: https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.9_Status https://wiki.yoctoproject.org/wiki/Yocto_1.9_Schedule https://wiki.yoctoproject.org/wiki/Yocto_1.9_Features Tracking Metrics: WDD 1950 (last week 1889 ) (https://wiki.yoctoproject.org/charts/combo.html) [If anyone has suggestions for other information you'd like to see on this weekly status update, let us know!] Thanks, Stephen K. Jolley Yocto Project Program Manager INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124 * Work Telephone: (503) 712-0534 *Cell:(208) 244-4460 * Email: stephen.k.jol...@intel.com -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] uclibc: Add SRCBRANCH for use by SRC_URI
On Fri, Aug 21, 2015 at 3:31 AM, Otavio Salvador
otavio.salva...@ossystems.com.br wrote:
On Thu, Aug 20, 2015 at 11:19 PM, Khem Raj raj.k...@gmail.com wrote:
On Thu, Aug 20, 2015 at 12:32 AM, Yen-Chin Lee coldnew...@gmail.com wrote:
-SRC_URI = git://uclibc.org/uClibc.git;branch=master \
+SRCBRANCH ??= master
+
+SRC_URI = git://uclibc.org/uClibc.git;branch=${SRCBRANCH} \
this is ok. Just call is BRANCH instead of SRCBRANCH
Personally I prefer SRCBRANCH. This is personal option though.
consistency is what I wanted here. There is BRANCH used for same
reason in some other recipes, it can be any name I don't have a
preference.
if you prefer SRCBRANCH, propose another patch to rename other
usecases in metadata to use it as well.
--
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] Get patch of all manual changes done in sources.
Hello! Is there any automated way to get diff of all manual changes done in recipe sources? Use case is: 1. bitbake something -c devshell 2. # manually modify sources # 3. bitbake image 4. bitbake something2 -c devshell 5. # manually modify sources # 6. bitbake image ... n. bitbake image And now I would like to automatically generate patch from changes in step #2, #5, and next. Is there any way in oe core to achieve such thing? And if needs to be implemented, do you have any suggestions how to start? (e.g. doing another task, create a bbclass, or? ) Thanks in advance! Bartek -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [poky][PATCH v4 2/2] gstreamer1.0: Fix QoS/lateness checking if subclass implements prepare/prepare_list vfuncs
On Fri, Aug 21, 2015 at 11:29 AM, Yuqing Zhu b54...@freescale.com wrote: In function gst_base_sink_chain_unlocked(), it should calculate jitter based on current media clock, rather than just passing 0. Or it will drop all the frames when rewind in slow speed, such as -2X. Signed-off-by: Yuqing Zhu b54...@freescale.com Acked-by: Otavio Salvador ota...@ossystems.com.br +Carlos for his feedback on this one as well. -- 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] init-install-efi.sh: Avoid /mnt/mtab creation if already present
Hi Leo, this fix looks good to me, can you mention how did you test
this?
On Mon, 2015-08-03 at 15:01 +,
leonardo.sandoval.gonza...@linux.intel.com wrote:
From: Leonardo Sandoval leonardo.sandoval.gonza...@linux.intel.com
The base-files recipe installs /mnt/mtab (it is a softlink of
/proc/mounts),
so if an image includes the latter, there is no new to created it
again inside
the install-efi.sh script, otherwise an error may occur as indicated
on the
bug's site.
[YOCTO #7971]
Signed-off-by: Leonardo Sandoval
leonardo.sandoval.gonza...@linux.intel.com
---
meta/recipes-core/initrdscripts/files/init-install-efi.sh | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-core/initrdscripts/files/init-install
-efi.sh b/meta/recipes-core/initrdscripts/files/init-install-efi.sh
index f339b30..665d04a 100644
--- a/meta/recipes-core/initrdscripts/files/init-install-efi.sh
+++ b/meta/recipes-core/initrdscripts/files/init-install-efi.sh
@@ -109,7 +109,11 @@ rm -f /etc/udev/scripts/mount*
umount ${device}* 2 /dev/null || /bin/true
mkdir -p /tmp
-cat /proc/mounts /etc/mtab
+
+# Create /etc/mtab if not present
+if [ ! -e /etc/mtab ]; then
+cat /proc/mounts /etc/mtab
+fi
disk_size=$(parted ${device} unit mb print | grep Disk | cut -d
-f 3 | sed -e s/MB//)
--
1.8.4.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] bb.utils.movefile: specify dest file name
When moving a file via the python os.rename function it is required to specify the path including the file name at the end. Failure to provide this file name at the destination argument of the os.rename function raises an OSError exception. [YOCTO#8180] Signed-off-by: Benjamin Esquivel benjamin.esqui...@linux.intel.com --- bitbake/lib/bb/utils.py | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/bitbake/lib/bb/utils.py b/bitbake/lib/bb/utils.py index 5b94432..5ed8e01 100644 --- a/bitbake/lib/bb/utils.py +++ b/bitbake/lib/bb/utils.py @@ -741,7 +741,11 @@ def movefile(src, dest, newmtime = None, sstat = None): renamefailed = 1 if sstat[stat.ST_DEV] == dstat[stat.ST_DEV]: try: -os.rename(src, dest) +# os.rename needs to know the destination path with file name +srcfname = os.path.basename(src) +destfname = os.path.join(dest, srcfname) if os.path.isdir(dest) \ +else dest +os.rename(src, destfname) renamefailed = 0 except Exception as e: if e[0] != errno.EXDEV: -- 2.3.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Get patch of all manual changes done in sources.
On 21 August 2015 at 17:04, Kucharczyk, Bartlomiej (Nokia - PL/Wroclaw) bartlomiej.kucharc...@nokia.com wrote: Hello! Is there any automated way to get diff of all manual changes done in recipe sources? Use case is: 1. bitbake something -c devshell 2. # manually modify sources # 3. bitbake image 4. bitbake something2 -c devshell 5. # manually modify sources # 6. bitbake image ... n. bitbake image And now I would like to automatically generate patch from changes in step #2, #5, and next. Is there any way in oe core to achieve such thing? And if needs to be implemented, do you have any suggestions how to start? (e.g. doing another task, create a bbclass, or? ) For this sort of iterative development in a source tree it's best to use devtool instead of the devshell task. There's a section on devtool in the documentation. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 1/1] classes/whitelist: add class to allow whitelisting recipes from a layer
On Fri, Aug 21, 2015 at 3:45 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Wed, 2015-08-19 at 14:34 +0100, Paul Eggleton wrote: Allow restricting recipes brought from a layer to a specified list. This is similar in operation to blacklist.bbclass, but instead specifies a per-layer whitelist of recipes (matched by BPN) that are able to be built from the layer - anything else is skipped. This is potentially useful where you want to bring in a select set of recipes from a larger layer e.g. meta-oe. Implements [YOCTO #8150]. Signed-off-by: Paul Eggleton paul.eggle...@linux.intel.com --- meta/classes/whitelist.bbclass | 28 1 file changed, 28 insertions(+) create mode 100644 meta/classes/whitelist.bbclass I should go on record as having some pretty strong reservations about this from a philosophical standpoint. Why? I think its going to encourage behaviours which will result in a decrease in layer quality, particularly for meta-oe. Taking a simple example, today if someone breaks parsing in meta-oe, its quickly known about and multiple people can see and resolve the issue. Once people start using this class, many users will simply never see/care about parsing breakage in less maintained parts of the layer. I appreciate Martin will likely notice, however this shouldn't Martin's sole responsibility. Since people's focus will be on to narrow parts of the layer, we'll start to see islands which are well maintained/used and islands which are not. Worse, just looking at the layer, we won't be able to tell which is which. I'm nervous about anything which pushes responsibility onto already overloaded maintainers and encourages behaviour which is a net loss on quality. I've talked to several significant users and they all love the idea of this class and plan to adopt it ASAP over existing tools like combo-layer. I therefore can't see much advantage of not merging the class as people are going to use it regardless. Speaking of it, combo-layer was designed to be an alternative way of dealing with these issues (more pain to use but causing less of a quality impact). Sadly, whilst it has seen some improvements, it still doesn't handle every operation it would need to make it work for some users and isn't widely adopted. I simply don't have the time to go and push it forward. So my objection is on record but that is likely about all I can do, other than hope I'm overly paranoid... All points here are valid. We already see this with distro's which use layers verbatim e.g. angstrom I wish everyone derived their distros that way since that respects the layer boundaries, a good chunk of work there is still we send patches to layers to keep them up to date with changes in other layers and there still are patches pending since every layer maintainer doesnt respond in sam time frame, but this sort of facilities if added is just going to worsen that workload. I think amalgmation of layers start with use of combo-tool itself. This patch just takes it a step further. If we want to preserve the layer model's health we have to work towards respecting layer boundaries and I would even go a step further and suggest to discourage use of combo-tool or any sort of layer squashing. 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
Re: [OE-core] [poky][PATCH v4 0/2] gstreamer1.0: Add patches for Gstreamer 1.4.5
Am 2015-08-22 um 00:01 schrieb Otavio Salvador: On Fri, Aug 21, 2015 at 6:57 PM, Carlos Rafael Giani d...@pseudoterminal.org wrote: These are backports, so I do not see a problem with them. However, keep in mind that GStreamer 1.6 will be out in a few days, so I recommend hold off any patches that are not backports. I have recipes prepared for 1.5.90 (= 1.6 release candidate) that I will then send to the mailing list. New patches should be applied on top of that, not 1.4.5. In this case it is better to not merge those and wait for 1.5.90 to be send. This allow for testing and also FSL checking for any other pending fixes. Yes. In fact, several of the present non-backport patches no longer apply. I had to delete them because fixing them was a nontrivial task, and should better be done by the original authors. I already sent a heads up about this to them. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] Rename 'BRANCH' variable to 'SRC_BRANCH' for clearness
The 'BRANCH' variable name has no explicit relation with the
SRC_URI. Using 'SRC_BRANCH' makes it more obvious and easier to
identify.
This patch makes the use consistent across the metadata.
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
meta/recipes-core/glibc/cross-localedef-native_2.22.bb | 4 ++--
meta/recipes-core/glibc/glibc_2.22.bb | 4 ++--
meta/recipes-devtools/mmc/mmc-utils_git.bb | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/meta/recipes-core/glibc/cross-localedef-native_2.22.bb
b/meta/recipes-core/glibc/cross-localedef-native_2.22.bb
index 2153ece..869cb3a 100644
--- a/meta/recipes-core/glibc/cross-localedef-native_2.22.bb
+++ b/meta/recipes-core/glibc/cross-localedef-native_2.22.bb
@@ -14,10 +14,10 @@ inherit autotools
FILESEXTRAPATHS =. ${FILE_DIRNAME}/${PN}:${FILE_DIRNAME}/glibc:
-BRANCH ?= release/${PV}/master
+SRC_BRANCH ?= release/${PV}/master
GLIBC_GIT_URI ?= git://sourceware.org/git/glibc.git
-SRC_URI = ${GLIBC_GIT_URI};branch=${BRANCH};name=glibc \
+SRC_URI = ${GLIBC_GIT_URI};branch=${SRC_BRANCH};name=glibc \
git://github.com/kraj/localedef;branch=master;name=localedef;destsuffix=git/localedef
\
file://fix_for_centos_5.8.patch \
${EGLIBCPATCHES} \
diff --git a/meta/recipes-core/glibc/glibc_2.22.bb
b/meta/recipes-core/glibc/glibc_2.22.bb
index 6aaf722..c02b6c8 100644
--- a/meta/recipes-core/glibc/glibc_2.22.bb
+++ b/meta/recipes-core/glibc/glibc_2.22.bb
@@ -9,11 +9,11 @@ DEPENDS += gperf-native kconfig-frontends-native
SRCREV ?= a34d1c6afc86521d6ad17662a3b5362d8481514c
-BRANCH ?= release/${PV}/master
+SRC_BRANCH ?= release/${PV}/master
GLIBC_GIT_URI ?= git://sourceware.org/git/glibc.git
-SRC_URI = ${GLIBC_GIT_URI};branch=${BRANCH};name=glibc \
+SRC_URI = ${GLIBC_GIT_URI};branch=${SRC_BRANCH};name=glibc \
file://0004-Backport-https-sourceware.org-ml-libc-ports-2007-12-.patch \
file://0005-fsl-e500-e5500-e6500-603e-fsqrt-implementation.patch \
file://0006-readlib-Add-OECORE_KNOWN_INTERPRETER_NAMES-to-known-.patch \
diff --git a/meta/recipes-devtools/mmc/mmc-utils_git.bb
b/meta/recipes-devtools/mmc/mmc-utils_git.bb
index 8950360..c6947e8 100644
--- a/meta/recipes-devtools/mmc/mmc-utils_git.bb
+++ b/meta/recipes-devtools/mmc/mmc-utils_git.bb
@@ -3,12 +3,12 @@ HOMEPAGE =
http://git.kernel.org/cgit/linux/kernel/git/cjb/mmc-utils.git/;
LICENSE = GPLv2
LIC_FILES_CHKSUM =
file://mmc.c;beginline=1;endline=17;md5=d7747fc87f1eb22b946ef819969503f0
-BRANCH ?= master
+SRC_BRANCH ?= master
SRCREV = f4eb241519f8d500ce6068a70d2389be39ac5189
PV = 0.1
-SRC_URI =
git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc-utils.git;branch=${BRANCH}
\
+SRC_URI =
git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc-utils.git;branch=${SRC_BRANCH}
\
file://0001-mmc.h-don-t-include-asm-generic-int-ll64.h.patch
S = ${WORKDIR}/git
--
2.5.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] uclibc: Add SRCBRANCH for use by SRC_URI
On Fri, Aug 21, 2015 at 12:33 PM, Khem Raj raj.k...@gmail.com wrote:
On Fri, Aug 21, 2015 at 3:31 AM, Otavio Salvador
otavio.salva...@ossystems.com.br wrote:
On Thu, Aug 20, 2015 at 11:19 PM, Khem Raj raj.k...@gmail.com wrote:
On Thu, Aug 20, 2015 at 12:32 AM, Yen-Chin Lee coldnew...@gmail.com wrote:
-SRC_URI = git://uclibc.org/uClibc.git;branch=master \
+SRCBRANCH ??= master
+
+SRC_URI = git://uclibc.org/uClibc.git;branch=${SRCBRANCH} \
this is ok. Just call is BRANCH instead of SRCBRANCH
Personally I prefer SRCBRANCH. This is personal option though.
consistency is what I wanted here. There is BRANCH used for same
reason in some other recipes, it can be any name I don't have a
preference.
if you prefer SRCBRANCH, propose another patch to rename other
usecases in metadata to use it as well.
Yes; I sent this for OE-Core but ended using SRC_BRANCH so it clearly
relates to SRC_URI.
--
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] [RFC PATCH 1/1] classes/whitelist: add class to allow whitelisting recipes from a layer
On Fri, Aug 21, 2015 at 2:45 PM, Khem Raj raj.k...@gmail.com wrote: On Fri, Aug 21, 2015 at 3:45 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Wed, 2015-08-19 at 14:34 +0100, Paul Eggleton wrote: Allow restricting recipes brought from a layer to a specified list. This is similar in operation to blacklist.bbclass, but instead specifies a per-layer whitelist of recipes (matched by BPN) that are able to be built from the layer - anything else is skipped. This is potentially useful where you want to bring in a select set of recipes from a larger layer e.g. meta-oe. Implements [YOCTO #8150]. Signed-off-by: Paul Eggleton paul.eggle...@linux.intel.com --- meta/classes/whitelist.bbclass | 28 1 file changed, 28 insertions(+) create mode 100644 meta/classes/whitelist.bbclass I should go on record as having some pretty strong reservations about this from a philosophical standpoint. Why? I think its going to encourage behaviours which will result in a decrease in layer quality, particularly for meta-oe. Taking a simple example, today if someone breaks parsing in meta-oe, its quickly known about and multiple people can see and resolve the issue. Once people start using this class, many users will simply never see/care about parsing breakage in less maintained parts of the layer. I appreciate Martin will likely notice, however this shouldn't Martin's sole responsibility. Since people's focus will be on to narrow parts of the layer, we'll start to see islands which are well maintained/used and islands which are not. Worse, just looking at the layer, we won't be able to tell which is which. I'm nervous about anything which pushes responsibility onto already overloaded maintainers and encourages behaviour which is a net loss on quality. I've talked to several significant users and they all love the idea of this class and plan to adopt it ASAP over existing tools like combo-layer. I therefore can't see much advantage of not merging the class as people are going to use it regardless. Speaking of it, combo-layer was designed to be an alternative way of dealing with these issues (more pain to use but causing less of a quality impact). Sadly, whilst it has seen some improvements, it still doesn't handle every operation it would need to make it work for some users and isn't widely adopted. I simply don't have the time to go and push it forward. So my objection is on record but that is likely about all I can do, other than hope I'm overly paranoid... All points here are valid. We already see this with distro's which use layers verbatim e.g. angstrom I wish everyone derived their distros that way since that respects the layer boundaries, a good chunk of work there is still we send patches to layers to keep them up to date with changes in other layers and there still are patches pending since every layer maintainer doesnt respond in sam time frame, but this sort of facilities if added is just going to worsen that workload. I think amalgmation of layers start with use of combo-tool itself. This patch just takes it a step further. If we want to preserve the layer model's health we have to work towards respecting layer boundaries and I would even go a step further and suggest to discourage use of combo-tool or any sort of layer squashing. I fully agree; in fact Poky itself is a bad example that I often have to explain for vendors. People justify putting several layers together in same repository saying that Poky does that and this is a contradiction which we need to justify as Yocto Project promotes the use of layers as one of most preeminent features but Poky does the opposite ... -- 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] [poky][PATCH v4 0/2] gstreamer1.0: Add patches for Gstreamer 1.4.5
These are backports, so I do not see a problem with them. However, keep in mind that GStreamer 1.6 will be out in a few days, so I recommend hold off any patches that are not backports. I have recipes prepared for 1.5.90 (= 1.6 release candidate) that I will then send to the mailing list. New patches should be applied on top of that, not 1.4.5. Am 2015-08-21 um 16:29 schrieb Yuqing Zhu: Fix sticky events haven't been sent out when active track reach EOS Fix QoS/lateness checking if subclass implements prepare/prepare_list vfuncs Yuqing Zhu (2): gstreamer1.0: Fix ticky events haven't been sent out when active track reach EOS gstreamer1.0: Fix QoS/lateness checking if subclass implements prepare/prepare_list vfuncs ...x-QoS-lateness-checking-if-subclass-imple.patch | 70 + ...cky-events-haven-t-send-out-when-ac-1-4-1.patch | 167 + .../gstreamer/gstreamer1.0_1.4.5.bb| 2 + 3 files changed, 239 insertions(+) create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0/0002-basesink-Fix-QoS-lateness-checking-if-subclass-imple.patch create mode 100755 meta/recipes-multimedia/gstreamer/gstreamer1.0/inputselector-sticky-events-haven-t-send-out-when-ac-1-4-1.patch -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 1/1] classes/whitelist: add class to allow whitelisting recipes from a layer
On Fri, 2015-08-21 at 18:43 -0300, Otavio Salvador wrote: On Fri, Aug 21, 2015 at 2:45 PM, Khem Raj raj.k...@gmail.com wrote: All points here are valid. We already see this with distro's which use layers verbatim e.g. angstrom I wish everyone derived their distros that way since that respects the layer boundaries, a good chunk of work there is still we send patches to layers to keep them up to date with changes in other layers and there still are patches pending since every layer maintainer doesnt respond in sam time frame, but this sort of facilities if added is just going to worsen that workload. I think amalgmation of layers start with use of combo-tool itself. This patch just takes it a step further. If we want to preserve the layer model's health we have to work towards respecting layer boundaries and I would even go a step further and suggest to discourage use of combo-tool or any sort of layer squashing. I fully agree; in fact Poky itself is a bad example that I often have to explain for vendors. People justify putting several layers together in same repository saying that Poky does that and this is a contradiction which we need to justify as Yocto Project promotes the use of layers as one of most preeminent features but Poky does the opposite ... Another way of looking at the issues people are having is that meta-openembedded is simply too large and it really needs to get split up into separate repos so people can get more granularity. That is both technically hard in some ways and controversial and nobody wants to step up and try and form a consensus about doing it though. I would note the internal splits are a good start though and there is some separation of maintainership happened there already. On the subject of poky, right from the start poky was a subset of OpenEmbedded, for good reason if we remember OE from those days. That reason was originally that OpenedHand didn't want to support all of OE for a customer, only some subset. The OSVs using the Yocto Project still have this issue today. The big difference between combo-layer and the whitelist is that in one case you don't ship the recipe. This makes it really clear to the customer what is and what is not supported. This has pros and cons, obviously. I will state for the record that poky only has complete layers in it though, it doesn't pick components of meta-oe, I've actively avoided it. Putting layers together in one accessible form is a different topic in some ways to filtering one layer into a sublayer. Patrick commented that whitelist and combo-layer both have the same drawback to metadata quality and that is probably true, I wasn't trying to suggest otherwise, merely highlight the other options available and their relative merits (which I didn't do a good job of). Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Extensible SDK install errors
Hello, I built the Extensible SDK on Fido (bitbake core-image-minimal -c populate_sdk_ext). During the installation I get this permission error: $ ./poky-glibc-x86_64-core-image-minimal-armv5e-toolchain-ext-1.8.sh Enter target directory for SDK (default: /opt/poky/1.8): You are about to install the SDK to /opt/poky/1.8. Proceed[Y/n]? Extracting SDK...done Setting it up... Extracting buildtools... ./poky-glibc-x86_64-core-image-minimal-armv5e-toolchain-ext-1.8.sh: line 148: /opt/poky/1.8/environment-setup-armv5e-poky-linux-gnueabi: Permission denied ./poky-glibc-x86_64-core-image-minimal-armv5e-toolchain-ext-1.8.sh: line 151: /opt/poky/1.8/environment-setup-armv5e-poky-linux-gnueabi: Permission denied ./poky-glibc-x86_64-core-image-minimal-armv5e-toolchain-ext-1.8.sh: line 155: /opt/poky/1.8/environment-setup-armv5e-poky-linux-gnueabi: Permission denied mv: cannot move ‘x86_64-nativesdk-libc.tar.bz2’ to ‘/opt/poky/1.8/layers/poky/x86_64-nativesdk-libc.tar.bz2’: Permission denied Preparing build system... sh: 1: cannot create preparing_build_system.log: Permission denied SDK preparation failed: see /opt/poky/1.8/preparing_build_system.log It looks like `/opt/poky/1.8/layers/poky` directory belongs to the root user: $ ls -l /opt/poky/1.8/layers/ total 36 drwxrwxr-x 9 root root 4096 Jun 16 10:25 meta-gnome drwxrwxr-x 9 root root 4096 Jun 15 10:44 meta-multimedia drwxrwxr-x 11 root root 4096 Jun 15 10:44 meta-networking drwxrwxr-x 20 root root 4096 Jun 15 10:44 meta-oe drwxrwxr-x 7 root root 4096 Jun 15 10:44 meta-python drwxrwxr-x 5 root root 4096 Jun 15 10:44 meta-ruby drwxrwxr-x 5 root root 4096 Jun 15 10:44 meta-systemd drwxrwxr-x 11 root root 4096 Jun 15 10:44 meta-xfce drwxrwxr-x 13 root root 4096 Aug 21 14:46 poky I may have missed something obvious. Has anyone seen this? Thanks! -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Rename 'BRANCH' variable to 'SRC_BRANCH' for clearness
On Aug 21, 2015, at 2:38 PM, Otavio Salvador ota...@ossystems.com.br wrote:
The 'BRANCH' variable name has no explicit relation with the
SRC_URI. Using 'SRC_BRANCH' makes it more obvious and easier to
identify.
Look good to me, just may be avoid ‘_’ and call it SRCBRANCH
This patch makes the use consistent across the metadata.
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
meta/recipes-core/glibc/cross-localedef-native_2.22.bb | 4 ++--
meta/recipes-core/glibc/glibc_2.22.bb | 4 ++--
meta/recipes-devtools/mmc/mmc-utils_git.bb | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/meta/recipes-core/glibc/cross-localedef-native_2.22.bb
b/meta/recipes-core/glibc/cross-localedef-native_2.22.bb
index 2153ece..869cb3a 100644
--- a/meta/recipes-core/glibc/cross-localedef-native_2.22.bb
+++ b/meta/recipes-core/glibc/cross-localedef-native_2.22.bb
@@ -14,10 +14,10 @@ inherit autotools
FILESEXTRAPATHS =. ${FILE_DIRNAME}/${PN}:${FILE_DIRNAME}/glibc:
-BRANCH ?= release/${PV}/master
+SRC_BRANCH ?= release/${PV}/master
GLIBC_GIT_URI ?= git://sourceware.org/git/glibc.git
-SRC_URI = ${GLIBC_GIT_URI};branch=${BRANCH};name=glibc \
+SRC_URI = ${GLIBC_GIT_URI};branch=${SRC_BRANCH};name=glibc \
git://github.com/kraj/localedef;branch=master;name=localedef;destsuffix=git/localedef
\
file://fix_for_centos_5.8.patch \
${EGLIBCPATCHES} \
diff --git a/meta/recipes-core/glibc/glibc_2.22.bb
b/meta/recipes-core/glibc/glibc_2.22.bb
index 6aaf722..c02b6c8 100644
--- a/meta/recipes-core/glibc/glibc_2.22.bb
+++ b/meta/recipes-core/glibc/glibc_2.22.bb
@@ -9,11 +9,11 @@ DEPENDS += gperf-native kconfig-frontends-native
SRCREV ?= a34d1c6afc86521d6ad17662a3b5362d8481514c
-BRANCH ?= release/${PV}/master
+SRC_BRANCH ?= release/${PV}/master
GLIBC_GIT_URI ?= git://sourceware.org/git/glibc.git
-SRC_URI = ${GLIBC_GIT_URI};branch=${BRANCH};name=glibc \
+SRC_URI = ${GLIBC_GIT_URI};branch=${SRC_BRANCH};name=glibc \
file://0004-Backport-https-sourceware.org-ml-libc-ports-2007-12-.patch \
file://0005-fsl-e500-e5500-e6500-603e-fsqrt-implementation.patch \
file://0006-readlib-Add-OECORE_KNOWN_INTERPRETER_NAMES-to-known-.patch \
diff --git a/meta/recipes-devtools/mmc/mmc-utils_git.bb
b/meta/recipes-devtools/mmc/mmc-utils_git.bb
index 8950360..c6947e8 100644
--- a/meta/recipes-devtools/mmc/mmc-utils_git.bb
+++ b/meta/recipes-devtools/mmc/mmc-utils_git.bb
@@ -3,12 +3,12 @@ HOMEPAGE =
http://git.kernel.org/cgit/linux/kernel/git/cjb/mmc-utils.git/;
LICENSE = GPLv2
LIC_FILES_CHKSUM =
file://mmc.c;beginline=1;endline=17;md5=d7747fc87f1eb22b946ef819969503f0
-BRANCH ?= master
+SRC_BRANCH ?= master
SRCREV = f4eb241519f8d500ce6068a70d2389be39ac5189
PV = 0.1
-SRC_URI =
git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc-utils.git;branch=${BRANCH}
\
+SRC_URI =
git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc-utils.git;branch=${SRC_BRANCH}
\
file://0001-mmc.h-don-t-include-asm-generic-int-ll64.h.patch
S = ${WORKDIR}/git
--
2.5.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
signature.asc
Description: Message signed with OpenPGP using GPGMail
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Rename 'BRANCH' variable to 'SRC_BRANCH' for clearness
On Fri, Aug 21, 2015 at 6:49 PM, Khem Raj raj.k...@gmail.com wrote: On Aug 21, 2015, at 2:38 PM, Otavio Salvador ota...@ossystems.com.br wrote: The 'BRANCH' variable name has no explicit relation with the SRC_URI. Using 'SRC_BRANCH' makes it more obvious and easier to identify. Look good to me, just may be avoid ‘_’ and call it SRCBRANCH I did this initially but looking at how it looks in the source code, it seems SRC_BRANCH makes easier to spot the relation with SRC_URI. So I took the second. -- 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] [poky][PATCH v4 0/2] gstreamer1.0: Add patches for Gstreamer 1.4.5
On Fri, Aug 21, 2015 at 6:57 PM, Carlos Rafael Giani d...@pseudoterminal.org wrote: These are backports, so I do not see a problem with them. However, keep in mind that GStreamer 1.6 will be out in a few days, so I recommend hold off any patches that are not backports. I have recipes prepared for 1.5.90 (= 1.6 release candidate) that I will then send to the mailing list. New patches should be applied on top of that, not 1.4.5. In this case it is better to not merge those and wait for 1.5.90 to be send. This allow for testing and also FSL checking for any other pending fixes. -- 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] [RFC PATCH 1/1] classes/whitelist: add class to allow whitelisting recipes from a layer
On Fri, 2015-08-21 at 11:45 +0100, Richard Purdie wrote: On Wed, 2015-08-19 at 14:34 +0100, Paul Eggleton wrote: Allow restricting recipes brought from a layer to a specified list. This is similar in operation to blacklist.bbclass, but instead specifies a per-layer whitelist of recipes (matched by BPN) that are able to be built from the layer - anything else is skipped. This is potentially useful where you want to bring in a select set of recipes from a larger layer e.g. meta-oe. Implements [YOCTO #8150]. Signed-off-by: Paul Eggleton paul.eggle...@linux.intel.com --- meta/classes/whitelist.bbclass | 28 1 file changed, 28 insertions(+) create mode 100644 meta/classes/whitelist.bbclass I should go on record as having some pretty strong reservations about this from a philosophical standpoint. Why? I think its going to encourage behaviours which will result in a decrease in layer quality, particularly for meta-oe. Taking a simple example, today if someone breaks parsing in meta-oe, its quickly known about and multiple people can see and resolve the issue. Once people start using this class, many users will simply never see/care about parsing breakage in less maintained parts of the layer. I appreciate Martin will likely notice, however this shouldn't Martin's sole responsibility. Since people's focus will be on to narrow parts of the layer, we'll start to see islands which are well maintained/used and islands which are not. Worse, just looking at the layer, we won't be able to tell which is which. I'm nervous about anything which pushes responsibility onto already overloaded maintainers and encourages behaviour which is a net loss on quality. I understand that concern. I don't know whether there are currently users who take the full meta-oe and would stop doing that once this class gets added. But I know that the inverse is also going to happen: not using meta-oe at all, starting to use a subset of it with this whitelist.bbclass. Whether that's a net gain or loss overall I have no idea. Speaking of it, combo-layer was designed to be an alternative way of dealing with these issues (more pain to use but causing less of a quality impact). I disagree here. When using combo-layer with filter to pick desired or supported recipes, you have the exact same effect as with whitelisting (only those recipes get tested). Without filter we have indeed the situation of someone taking the entire meta-oe and activating it, but that's independent of using combo-layer or not. Sadly, whilst it has seen some improvements, it still doesn't handle every operation it would need to make it work for some users and isn't widely adopted. I simply don't have the time to go and push it forward. I'm not sure what improvements you have in mind here. The filter mechanism certainly could be enhanced (filtering out a recipe and adding it later does not work), but that's conceptually the same as whitelisting. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] nettle: clean up license information
On Fri, Aug 21, 2015 at 11:48:30AM +0300, Jussi Kukkonen wrote:
On 18 August 2015 at 11:03, Martin Jansa martin.ja...@gmail.com wrote:
On Sun, Aug 09, 2015 at 10:58:21AM +0530, Armin Kuster wrote:
adding the license definitions on the few packages that
deviate from the overall package license.
based on http://www.lysator.liu.se/~nisse/nettle/nettle.html#Copyright
and spot checking files.
Signed-off-by: Armin Kuster akuster...@gmail.com
---
meta/recipes-support/nettle/nettle_2.7.1.bb | 9 +
1 file changed, 9 insertions(+)
diff --git a/meta/recipes-support/nettle/nettle_2.7.1.bb
b/meta/recipes-support/nettle/nettle_2.7.1.bb
index f53afcc..f9d331f 100644
--- a/meta/recipes-support/nettle/nettle_2.7.1.bb
+++ b/meta/recipes-support/nettle/nettle_2.7.1.bb
@@ -2,6 +2,15 @@ SUMMARY = A low level cryptographic library
HOMEPAGE = http://www.lysator.liu.se/~nisse/nettle/;
SECTION = libs
LICENSE = LGPLv2.1 GPLv2
It would be nice to package GPLv2 files in separate package as well (or
LGPLv2.1 library in seprate package) if you have time to do that.
Forgot to answer this, sorry.
For 2.7.1 what you suggest may work -- there may be some tools that
are GPLv2 that we could separate. But for the new version the strange
LGPLv3+ | GPLv2+ license combo is _not_ a result of the library
being LGPL and some utilities being GPL: the library itself (like a
lot of GNU stuff nowadays) is dual licensed like that.
This means that we need to preserve nettle 2.7.1 for people who cannot
use LGPLv3 (and GPLv2 for libraries).
It seems weird but actually makes sense for GNU: It forces all users
to comply with LGPLv3, except the GPLv2 programs that can't easily be
relicensed to GPLv3. Those GPLv2 programs would be incompatible with
the newer LGPLv3 libraries but this dual-licensing lets them off the
hook.
Jussi
+LICENSE_${PN}-cast = CC0
+LICENSE_${PN}-gosthash = MIT
+
+# both public and GPL license listed
+LICENSE_${PN}-md2 = CC0 LGPLv2.1+
+LICENSE_${PN}-md4 = CC0 LGPLv2.1+
+
+
LIC_FILES_CHKSUM =
file://COPYING.LIB;md5=2d5025d4aa3495befef8f17206a5b0a1 \
file://serpent-decrypt.c;beginline=53;endline=67;md5=bcfd4745d53ca57f82907089898e390d
\
file://serpent-set-key.c;beginline=56;endline=70;md5=bcfd4745d53ca57f82907089898e390d
--
2.3.5
--
___
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
--
___
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
[OE-core] [PATCH 3/3] dump: allow to have datastore vars on dump commands
From: Mariano Lopez mariano.lo...@linux.intel.com
This allows to have datastore variables in the dump
commands and will get the data when a new instance
it's created.
Also this remove special cases from the commands.
[YOCTO #8118]
Signed-off-by: Mariano Lopez mariano.lo...@linux.intel.com
---
meta/classes/testimage.bbclass | 7 +--
meta/lib/oeqa/utils/dump.py| 43 ++
2 files changed, 32 insertions(+), 18 deletions(-)
diff --git a/meta/classes/testimage.bbclass b/meta/classes/testimage.bbclass
index 2131869..6a4b80a 100644
--- a/meta/classes/testimage.bbclass
+++ b/meta/classes/testimage.bbclass
@@ -63,11 +63,14 @@ testimage_dump_target () {
ps
free
df
-_ping
+# The next command will export the default gateway IP
+export DEFAULT_GATEWAY=$(ip route | awk '/default/ { print $3}')
+ping -c3 $DEFAULT_GATEWAY
dmesg
netstat -an
ip address
-_logs
+# Next command will dump logs from /var/log/
+find /var/log/ -type f 2/dev/null -exec echo \;
-exec echo {} \; -exec echo \; -exec cat {} \; -exec
echo \;
}
testimage_dump_host () {
diff --git a/meta/lib/oeqa/utils/dump.py b/meta/lib/oeqa/utils/dump.py
index 1475b27..85bbc7a 100644
--- a/meta/lib/oeqa/utils/dump.py
+++ b/meta/lib/oeqa/utils/dump.py
@@ -11,8 +11,24 @@ def get_host_dumper(d):
class BaseDumper(object):
-def __init__(self, d):
+def __init__(self, d, cmds):
+self.cmds = []
self.parent_dir = d.getVar(TESTIMAGE_DUMP_DIR, True)
+for cmd in cmds.split('\n'):
+cmd = cmd.lstrip()
+if not cmd or cmd[0] == '#':
+continue
+# Replae variables from the datastore
+while True:
+index_start = cmd.find(${)
+if index_start == -1:
+break
+index_start += 2
+index_end = cmd.find(}, index_start)
+var = cmd[index_start:index_end]
+value = d.getVar(var, True)
+cmd = cmd.replace(${%s} % var, value)
+self.cmds.append(cmd)
def create_dir(self, dir_suffix):
dump_subdir = (%s_%s % (
@@ -26,7 +42,7 @@ class BaseDumper(object):
raise err
self.dump_dir = dump_dir
-def write_dump(self, command, output):
+def _write_dump(self, command, output):
if isinstance(self, HostDumper):
prefix = host
elif isinstance(self, TargetDumper):
@@ -45,33 +61,28 @@ class BaseDumper(object):
class HostDumper(BaseDumper):
def __init__(self, d):
-super(HostDumper, self).__init__(d)
-self.host_cmds = d.getVar(testimage_dump_host, True)
+host_cmds = d.getVar(testimage_dump_host, True)
+super(HostDumper, self).__init__(d, host_cmds)
def dump_host(self, dump_dir=):
if dump_dir:
self.dump_dir = dump_dir
-for cmd in self.host_cmds.split('\n'):
-cmd = cmd.lstrip()
-if not cmd or cmd[0] == '#':
-continue
+for cmd in self.cmds:
result = runCmd(cmd, ignore_status=True)
-self.write_dump(cmd.split()[0], result.output)
+self._write_dump(cmd.split()[0], result.output)
class TargetDumper(BaseDumper):
def __init__(self, d, qemurunner):
-super(TargetDumper, self).__init__(d)
-self.target_cmds = d.getVar(testimage_dump_target, True)
+target_cmds = d.getVar(testimage_dump_target, True)
+super(TargetDumper, self).__init__(d, target_cmds)
self.runner = qemurunner
def dump_target(self, dump_dir=):
if dump_dir:
self.dump_dir = dump_dir
-for cmd in self.target_cmds.split('\n'):
-cmd = cmd.lstrip()
-if not cmd or cmd[0] == '#':
-continue
+print (Target cmds %s % self.cmds)
+for cmd in self.cmds:
(status, output) = self.runner.run_serial(cmd)
-self.write_dump(cmd.split()[0], output)
+self._write_dump(cmd.split()[0], output)
--
1.8.4.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/3] Get dumps when qemu fails
From: Mariano Lopez mariano.lo...@linux.intel.com This provides classes for dump logs from the host and the target. This way it's easier to get dumps from the runner or the target and not just from the test. With this now the qemurunner instance get the dumps from the host when qemu fails. This also allows to have datastore vars in the commands and removes the special case commands. This depends on: http://lists.openembedded.org/pipermail/openembedded-core/2015-August/108912.html [YOCTO #8118] Mariano Lopez (3): dump: Created new classes for dump host and target qemurunner: Added host dumps when there are errors dump: allow to have datastore vars on dump commands meta/classes/testimage.bbclass| 14 +-- meta/lib/oeqa/oetest.py | 52 +++ meta/lib/oeqa/targetcontrol.py| 16 +++ meta/lib/oeqa/utils/dump.py | 88 +++ meta/lib/oeqa/utils/qemurunner.py | 15 ++- 5 files changed, 127 insertions(+), 58 deletions(-) create mode 100644 meta/lib/oeqa/utils/dump.py -- 1.8.4.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/3] qemurunner: Added host dumps when there are errors
From: Mariano Lopez mariano.lo...@linux.intel.com
This adds an instance of HostDumper to qemurunner,
with this instance now is possible to get dumps
from the host when there is an error.
This also adds dump points in the next cases:
- runqemu exits before seeing qemu pid
- Fail to get qemu process arguments
- Not reach login banner before timeout
- qemu pid never appears
[YOCTO #8118]
Signed-off-by: Mariano Lopez mariano.lo...@linux.intel.com
---
meta/classes/testimage.bbclass| 2 +-
meta/lib/oeqa/targetcontrol.py| 10 ++
meta/lib/oeqa/utils/qemurunner.py | 15 +--
3 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/meta/classes/testimage.bbclass b/meta/classes/testimage.bbclass
index 824b47f..2131869 100644
--- a/meta/classes/testimage.bbclass
+++ b/meta/classes/testimage.bbclass
@@ -250,7 +250,7 @@ def testimage_main(d):
host_dumper = get_host_dumper(d)
# the robot dance
-target = get_target_controller(d)
+target = get_target_controller(d, host_dumper)
class TestContext(object):
def __init__(self):
diff --git a/meta/lib/oeqa/targetcontrol.py b/meta/lib/oeqa/targetcontrol.py
index 2d58f17..14ba1d9 100644
--- a/meta/lib/oeqa/targetcontrol.py
+++ b/meta/lib/oeqa/targetcontrol.py
@@ -18,11 +18,11 @@ from oeqa.utils.dump import TargetDumper
from oeqa.controllers.testtargetloader import TestTargetLoader
from abc import ABCMeta, abstractmethod
-def get_target_controller(d):
+def get_target_controller(d, host_dumper):
testtarget = d.getVar(TEST_TARGET, True)
# old, simple names
if testtarget == qemu:
-return QemuTarget(d)
+return QemuTarget(d, host_dumper)
elif testtarget == simpleremote:
return SimpleRemoteTarget(d)
else:
@@ -115,7 +115,7 @@ class QemuTarget(BaseTarget):
supported_image_fstypes = ['ext3', 'ext4', 'cpio.gz']
-def __init__(self, d):
+def __init__(self, d, host_dumper):
super(QemuTarget, self).__init__(d)
@@ -124,6 +124,7 @@ class QemuTarget(BaseTarget):
self.origrootfs = os.path.join(d.getVar(DEPLOY_DIR_IMAGE, True),
d.getVar(IMAGE_LINK_NAME, True) + '.' + self.image_fstype)
self.rootfs = os.path.join(self.testdir, d.getVar(IMAGE_LINK_NAME,
True) + '-testimage.' + self.image_fstype)
self.kernel = os.path.join(d.getVar(DEPLOY_DIR_IMAGE, True),
d.getVar(KERNEL_IMAGETYPE, False) + '-' + d.getVar('MACHINE', False) + '.bin')
+self.host_dumper = host_dumper
# Log QemuRunner log output to a file
import oe.path
@@ -151,7 +152,8 @@ class QemuTarget(BaseTarget):
deploy_dir_image = d.getVar(DEPLOY_DIR_IMAGE,
True),
display = d.getVar(BB_ORIGENV,
False).getVar(DISPLAY, True),
logfile = self.qemulog,
-boottime = int(d.getVar(TEST_QEMUBOOT_TIMEOUT,
True)))
+boottime = int(d.getVar(TEST_QEMUBOOT_TIMEOUT,
True)),
+host_dumper = self.host_dumper)
self.target_dumper = TargetDumper(d, self.runner)
diff --git a/meta/lib/oeqa/utils/qemurunner.py
b/meta/lib/oeqa/utils/qemurunner.py
index 0458447..6c17f11 100644
--- a/meta/lib/oeqa/utils/qemurunner.py
+++ b/meta/lib/oeqa/utils/qemurunner.py
@@ -19,7 +19,7 @@ logger = logging.getLogger(BitBake.QemuRunner)
class QemuRunner:
-def __init__(self, machine, rootfs, display, tmpdir, deploy_dir_image,
logfile, boottime):
+def __init__(self, machine, rootfs, display, tmpdir, deploy_dir_image,
logfile, boottime, host_dumper):
# Popen object for runqemu
self.runqemu = None
@@ -37,8 +37,9 @@ class QemuRunner:
self.deploy_dir_image = deploy_dir_image
self.logfile = logfile
self.boottime = boottime
-self.logged = False
+self.host_dumper = host_dumper
+self.logged = False
self.runqemutime = 60
def create_socket(self):
@@ -117,6 +118,7 @@ class QemuRunner:
if self.runqemu.returncode:
# No point waiting any longer
logger.info('runqemu exited with code %d' %
self.runqemu.returncode)
+self._dump_host()
self.stop()
logger.info(Output from runqemu:\n%s % getOutput(output))
return False
@@ -136,6 +138,7 @@ class QemuRunner:
self.server_ip = ips[1]
except IndexError, ValueError:
logger.info(Couldn't get ip from qemu process arguments! Here
is the qemu command line used:\n%s\nand output from runqemu:\n%s % (cmdline,
getOutput(output)))
+self._dump_host()
self.stop()
return False
logger.info(Target IP: %s % self.ip)
@@ -174,6 +177,7 @@ class QemuRunner:
lines =
[OE-core] [PATCH 1/3] dump: Created new classes for dump host and target
From: Mariano Lopez mariano.lo...@linux.intel.com
It makes sense to separate the dump commands from the
oeRuntimeTest class, this way it can be used in all
the test context.
These are the changes included in this patch:
- Created classes: BaseDumper, HostDumper, TargetDumper
- Create an instance of HostDumper in imagetest.bbclass
and add it to TestContext class, this way any class
that have access to the TestContext would be able
to dump logs from the host
- Create an instance of TargetDumper in QemuTarget
class after get the runner, this way it is
accessible during the tests.
[YOCTO #8118]
Signed-off-by: Mariano Lopez mariano.lo...@linux.intel.com
---
meta/classes/testimage.bbclass | 5 +++
meta/lib/oeqa/oetest.py| 52
meta/lib/oeqa/targetcontrol.py | 6 ++--
meta/lib/oeqa/utils/dump.py| 77 ++
4 files changed, 91 insertions(+), 49 deletions(-)
create mode 100644 meta/lib/oeqa/utils/dump.py
diff --git a/meta/classes/testimage.bbclass b/meta/classes/testimage.bbclass
index 1d9464f..824b47f 100644
--- a/meta/classes/testimage.bbclass
+++ b/meta/classes/testimage.bbclass
@@ -231,6 +231,7 @@ def testimage_main(d):
import time
from oeqa.oetest import loadTests, runTests
from oeqa.targetcontrol import get_target_controller
+from oeqa.utils.dump import get_host_dumper
pn = d.getVar(PN, True)
export = oe.utils.conditional(TEST_EXPORT_ONLY, 1, True, False, d)
@@ -245,6 +246,9 @@ def testimage_main(d):
testslist = get_tests_list(d)
testsrequired = [t for t in d.getVar(TEST_SUITES, True).split() if t !=
auto]
+# we need the host dumper in test context
+host_dumper = get_host_dumper(d)
+
# the robot dance
target = get_target_controller(d)
@@ -255,6 +259,7 @@ def testimage_main(d):
self.testsrequired = testsrequired
self.filesdir =
os.path.join(os.path.dirname(os.path.abspath(oeqa.runtime.__file__)),files)
self.target = target
+self.host_dumper = host_dumper
self.imagefeatures = d.getVar(IMAGE_FEATURES, True).split()
self.distrofeatures = d.getVar(DISTRO_FEATURES, True).split()
manifest = os.path.join(d.getVar(DEPLOY_DIR_IMAGE, True),
d.getVar(IMAGE_LINK_NAME, True) + .manifest)
diff --git a/meta/lib/oeqa/oetest.py b/meta/lib/oeqa/oetest.py
index e765c96..b33ca0a 100644
--- a/meta/lib/oeqa/oetest.py
+++ b/meta/lib/oeqa/oetest.py
@@ -11,8 +11,6 @@ import os, re, mmap
import unittest
import inspect
import subprocess
-import datetime
-import commands
import bb
from oeqa.utils.decorators import LogResults
from sys import exc_info, exc_clear
@@ -124,51 +122,13 @@ class oeRuntimeTest(oeTest):
# If a test fails or there is an exception
if not exc_info() == (None, None, None):
exc_clear()
-dump_dir = self.create_dump_dir()
+self.tc.host_dumper.create_dir(self._testMethodName)
+self.target.target_dumper.dump_target(
+self.tc.host_dumper.dump_dir)
+self.tc.host_dumper.dump_host()
print (%s dump data from host and target
-stored in %s % (self._testMethodName, dump_dir))
-self.dump_host_logs(dump_dir)
-self.dump_target_logs(dump_dir)
-
-def create_dump_dir(self):
-dump_sub_dir = (%s_%s % (
-datetime.datetime.now().strftime('%Y%m%d%H%M'),
-self._testMethodName))
-dump_dir = os.path.join(self.target.dump_dir, dump_sub_dir)
-os.makedirs(dump_dir)
-return dump_dir
-
-def dump_host_logs(self, dump_dir):
-for cmd in self.target.dump_host.split('\n'):
-cmd = cmd.lstrip()
-if not cmd:
-continue
-output = commands.getoutput(cmd)
-filename = host_%s % cmd.split()[0]
-with open(os.path.join(dump_dir, filename), 'w') as f:
-f.write(output)
-
-def dump_target_logs(self, dump_dir):
-for cmd in self.target.dump_target.split('\n'):
-cmd = cmd.lstrip()
-if not cmd:
-continue
-# This will ping the host from target
-if cmd == _ping:
- comm = ping -c3 %s % self.target.server_ip
-# This will get all the logs from /var/log/
-elif cmd == _logs:
-comm = 'find /var/log/ -type f 2/dev/null '
-comm = '%s-exec echo %s \\; ' % (comm, '='*20)
-comm = '%s-exec echo {} \\; ' % comm
-comm = '%s-exec echo %s \\; ' % (comm, '='*20)
-comm = '%s-exec cat {} \\; -exec echo \\;' % comm
-else:
-comm = cmd
-(status, output) = self.target.run_serial(comm)
-filename = target_%s % cmd.split()[0]
-with
Re: [OE-core] [PATCH] mtd-utils: add dependency on acl
On Fri, Aug 21, 2015 at 4:28 PM, Andrea Adami andrea.ad...@gmail.com wrote:
After commit 24fde4d do_compile fails:
| mkfs.jffs2.c:70:21: fatal error: sys/acl.h: No such file or directory
| #include sys/acl.h
Adding acl to the list of dependencies fixes the build.
Unconditionally enabling xattr and acl support is OK for the native
build, but for the target both should probably be conditional on their
respective DISTRO_FEATURES.
Signed-off-by: Andrea Adami andrea.ad...@gmail.com
---
meta/recipes-devtools/mtd/mtd-utils_git.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/mtd/mtd-utils_git.bb
b/meta/recipes-devtools/mtd/mtd-utils_git.bb
index 8d4892a..72ce9ed 100644
--- a/meta/recipes-devtools/mtd/mtd-utils_git.bb
+++ b/meta/recipes-devtools/mtd/mtd-utils_git.bb
@@ -5,7 +5,7 @@ LICENSE = GPLv2+
LIC_FILES_CHKSUM = file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3 \
file://include/common.h;beginline=1;endline=17;md5=ba05b07912a44ea2bf81ce409380049c
-DEPENDS = zlib lzo e2fsprogs util-linux
+DEPENDS = zlib lzo e2fsprogs util-linux acl
PV = 1.5.1+git${SRCPV}
--
1.9.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
[OE-core] [PATCH] mtd-utils: add dependency on acl
After commit 24fde4d do_compile fails:
| mkfs.jffs2.c:70:21: fatal error: sys/acl.h: No such file or directory
| #include sys/acl.h
Adding acl to the list of dependencies fixes the build.
Signed-off-by: Andrea Adami andrea.ad...@gmail.com
---
meta/recipes-devtools/mtd/mtd-utils_git.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/mtd/mtd-utils_git.bb
b/meta/recipes-devtools/mtd/mtd-utils_git.bb
index 8d4892a..72ce9ed 100644
--- a/meta/recipes-devtools/mtd/mtd-utils_git.bb
+++ b/meta/recipes-devtools/mtd/mtd-utils_git.bb
@@ -5,7 +5,7 @@ LICENSE = GPLv2+
LIC_FILES_CHKSUM = file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3 \
file://include/common.h;beginline=1;endline=17;md5=ba05b07912a44ea2bf81ce409380049c
-DEPENDS = zlib lzo e2fsprogs util-linux
+DEPENDS = zlib lzo e2fsprogs util-linux acl
PV = 1.5.1+git${SRCPV}
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2 v2] libcap-ng: add package 0.7.7
On 2015-08-21 03:25 AM, Khem Raj wrote:
On Thu, Aug 20, 2015 at 10:38 PM, wenzong@windriver.com wrote:
From: Wenzong Fan wenzong@windriver.com
Pull package from meta-oe to oe-core:
meta-oe commit: bce4dba5546480c8e43c6442959ac7d0a4ef32f6
The libcap-ng library is intended to make programming with posix
capabilities much easier than the traditional libcap library.
It's not a replacement to libcap, it provides different library
(libcap-ng.so) while packages explicitly look for libcap.so. It
could be used by qemu, util-linux, libvirt, audit ...
With adding it to oe-core, the copies from following layers could
be removed:
* meta-oe, meta-selinux, meta-security-framework ...
I am afraid that we are setting a pretext for moving all recipes that
are in multiple layers to be eligible for OE-core now.
meta-oe is common layer for extended recipes, so may be other layers
should have been a bit more vigilant and made sure
there requirements were met with whats in meta-oe.
Meta-oe has far to many recipes for some people to want
to include the entire layer:
meta-oe.git $ find meta-oe/ -name *bb | wc -l
618
We can certainly use the new whitelist layer filtering to
get to a smaller collection of recipes but I'd like to suggest we
need to document and maybe design the layer structure
a bit more. There are lots of different opinions about
how to split collections of packages in to different layers so
unless someone has a dependency-based analysis of all
pacakges in all layers, I don't see much point in a long
discussion on this topic.
Has the idea of creating a new meta-openembedded layer
for widely-used, OS interface libraries been proposed?
These 80 recipes could be considered for inclusion:
$ find meta-oe -name lib*bb | wc -l
80
but more consideration is probably needed.
In the short term (oe-core-1.9 (now 2.0), I guess we leave
things as they are. Sigh...
../Randy
While I'm at it, for reference of layer size:
$ for i in `ls -d meta-*`; do echo -n $i: ; find $i -name *bb | wc
-l; done
meta-efl: 57
meta-filesystems: 16
meta-gnome: 82
meta-gpe: 5
meta-initramfs: 14
meta-multimedia: 51
meta-networking: 115
meta-oe: 618
meta-perl: 30
meta-python: 74
meta-ruby: 4
meta-systemd: 1
meta-webserver: 13
meta-xfce: 67
-
we should ask what core feature does it enable for reference images
and machines.
Signed-off-by: Wenzong Fan wenzong@windriver.com
---
.../libcap-ng/libcap-ng/python.patch | 58 ++
meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb | 39 +++
2 files changed, 97 insertions(+)
create mode 100644 meta/recipes-support/libcap-ng/libcap-ng/python.patch
create mode 100644 meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb
diff --git a/meta/recipes-support/libcap-ng/libcap-ng/python.patch
b/meta/recipes-support/libcap-ng/libcap-ng/python.patch
new file mode 100644
index 000..59591eb
--- /dev/null
+++ b/meta/recipes-support/libcap-ng/libcap-ng/python.patch
@@ -0,0 +1,58 @@
+From b01bb2694f66cd981e6d61523433dc3eb5ed32f2 Mon Sep 17 00:00:00 2001
+From: Li xin lixin.f...@cn.fujitsu.com
+Date: Sat, 18 Jul 2015 23:03:30 +0900
+Subject: [PATCH] configure.ac - Avoid an incorrect check for python.
+ Makefile.am - avoid hard coded host include paths.
+
+Upstream-Status: pending
+
+Signed-off-by: Mark Hatle mark.ha...@windriver.com
+Signed-off-by: Li Xin lixin.f...@cn.fujitsu.com
+---
+ bindings/python/Makefile.am | 3 ++-
+ configure.ac| 15 ++-
+ 2 files changed, 4 insertions(+), 14 deletions(-)
+
+diff --git a/bindings/python/Makefile.am b/bindings/python/Makefile.am
+index 82b9bb8..f9fe7a8 100644
+--- a/bindings/python/Makefile.am
b/bindings/python/Makefile.am
+@@ -23,7 +23,8 @@ SUBDIRS = test
+ CONFIG_CLEAN_FILES = *.loT *.rej *.orig
+ AM_CFLAGS = -fPIC -DPIC
+ PYLIBVER ?= python$(PYTHON_VERSION)
+-AM_CPPFLAGS = -I. -I$(top_builddir) -I@PYINCLUDEDIR@
++PYINC ?= /usr/include/$(PYLIBVER)
++AM_CPPFLAGS = -I. -I$(top_builddir) -I$(PYINC)
+ LIBS = $(top_builddir)/src/libcap-ng.la
+ SWIG_FLAGS = -python
+ SWIG_INCLUDES = ${AM_CPPFLAGS}
+diff --git a/configure.ac b/configure.ac
+index 1d777d5..9d90f64 100644
+--- a/configure.ac
b/configure.ac
+@@ -123,19 +123,8 @@ if test x$use_python = xno ; then
+ else
+ AC_MSG_RESULT(testing)
+ AM_PATH_PYTHON
+-PYINCLUDEDIR=`python${am_cv_python_version} -c from distutils import sysconfig;
print(sysconfig.get_config_var('INCLUDEPY'))`
+-if test -f ${PYINCLUDEDIR}/Python.h ; then
+- python_found=yes
+- AC_SUBST(PYINCLUDEDIR)
+- AC_MSG_NOTICE(Python bindings will be built)
+-else
+- python_found=no
+- if test x$use_python = xyes ; then
+- AC_MSG_ERROR([Python explicitly required and python headers
found])
+- else
+- AC_MSG_WARN(Python headers not found - python bindings will not be
made)
+- fi
+-fi
++python_found=yes
++AC_MSG_NOTICE(Python bindings will
Re: [OE-core] [PATCH 2/2 v2] libcap-ng: add package 0.7.7
On Fri, Aug 21, 2015 at 5:55 PM, Randy MacLeod
randy.macl...@windriver.com wrote:
On 2015-08-21 03:25 AM, Khem Raj wrote:
On Thu, Aug 20, 2015 at 10:38 PM, wenzong@windriver.com wrote:
From: Wenzong Fan wenzong@windriver.com
Pull package from meta-oe to oe-core:
meta-oe commit: bce4dba5546480c8e43c6442959ac7d0a4ef32f6
The libcap-ng library is intended to make programming with posix
capabilities much easier than the traditional libcap library.
It's not a replacement to libcap, it provides different library
(libcap-ng.so) while packages explicitly look for libcap.so. It
could be used by qemu, util-linux, libvirt, audit ...
With adding it to oe-core, the copies from following layers could
be removed:
* meta-oe, meta-selinux, meta-security-framework ...
I am afraid that we are setting a pretext for moving all recipes that
are in multiple layers to be eligible for OE-core now.
meta-oe is common layer for extended recipes, so may be other layers
should have been a bit more vigilant and made sure
there requirements were met with whats in meta-oe.
Meta-oe has far to many recipes for some people to want
to include the entire layer:
meta-oe.git $ find meta-oe/ -name *bb | wc -l
618
I typically include most of the meta-oe layers, but I've never really
given much thought to how many recipes there are.
Is the concern that parsing too many recipes makes bitbake slow? Or is
there another reason why I wouldn't want to include them all?
We can certainly use the new whitelist layer filtering to
get to a smaller collection of recipes but I'd like to suggest we
need to document and maybe design the layer structure
a bit more. There are lots of different opinions about
how to split collections of packages in to different layers so
unless someone has a dependency-based analysis of all
pacakges in all layers, I don't see much point in a long
discussion on this topic.
Has the idea of creating a new meta-openembedded layer
for widely-used, OS interface libraries been proposed?
These 80 recipes could be considered for inclusion:
$ find meta-oe -name lib*bb | wc -l
80
but more consideration is probably needed.
In the short term (oe-core-1.9 (now 2.0), I guess we leave
things as they are. Sigh...
../Randy
While I'm at it, for reference of layer size:
$ for i in `ls -d meta-*`; do echo -n $i: ; find $i -name *bb | wc -l;
done
meta-efl: 57
meta-filesystems: 16
meta-gnome: 82
meta-gpe: 5
meta-initramfs: 14
meta-multimedia: 51
meta-networking: 115
meta-oe: 618
meta-perl: 30
meta-python: 74
meta-ruby: 4
meta-systemd: 1
meta-webserver: 13
meta-xfce: 67
-
we should ask what core feature does it enable for reference images
and machines.
Signed-off-by: Wenzong Fan wenzong@windriver.com
---
.../libcap-ng/libcap-ng/python.patch | 58
++
meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb | 39 +++
2 files changed, 97 insertions(+)
create mode 100644
meta/recipes-support/libcap-ng/libcap-ng/python.patch
create mode 100644 meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb
diff --git a/meta/recipes-support/libcap-ng/libcap-ng/python.patch
b/meta/recipes-support/libcap-ng/libcap-ng/python.patch
new file mode 100644
index 000..59591eb
--- /dev/null
+++ b/meta/recipes-support/libcap-ng/libcap-ng/python.patch
@@ -0,0 +1,58 @@
+From b01bb2694f66cd981e6d61523433dc3eb5ed32f2 Mon Sep 17 00:00:00 2001
+From: Li xin lixin.f...@cn.fujitsu.com
+Date: Sat, 18 Jul 2015 23:03:30 +0900
+Subject: [PATCH] configure.ac - Avoid an incorrect check for python.
+ Makefile.am - avoid hard coded host include paths.
+
+Upstream-Status: pending
+
+Signed-off-by: Mark Hatle mark.ha...@windriver.com
+Signed-off-by: Li Xin lixin.f...@cn.fujitsu.com
+---
+ bindings/python/Makefile.am | 3 ++-
+ configure.ac| 15 ++-
+ 2 files changed, 4 insertions(+), 14 deletions(-)
+
+diff --git a/bindings/python/Makefile.am b/bindings/python/Makefile.am
+index 82b9bb8..f9fe7a8 100644
+--- a/bindings/python/Makefile.am
b/bindings/python/Makefile.am
+@@ -23,7 +23,8 @@ SUBDIRS = test
+ CONFIG_CLEAN_FILES = *.loT *.rej *.orig
+ AM_CFLAGS = -fPIC -DPIC
+ PYLIBVER ?= python$(PYTHON_VERSION)
+-AM_CPPFLAGS = -I. -I$(top_builddir) -I@PYINCLUDEDIR@
++PYINC ?= /usr/include/$(PYLIBVER)
++AM_CPPFLAGS = -I. -I$(top_builddir) -I$(PYINC)
+ LIBS = $(top_builddir)/src/libcap-ng.la
+ SWIG_FLAGS = -python
+ SWIG_INCLUDES = ${AM_CPPFLAGS}
+diff --git a/configure.ac b/configure.ac
+index 1d777d5..9d90f64 100644
+--- a/configure.ac
b/configure.ac
+@@ -123,19 +123,8 @@ if test x$use_python = xno ; then
+ else
+ AC_MSG_RESULT(testing)
+ AM_PATH_PYTHON
+-PYINCLUDEDIR=`python${am_cv_python_version} -c from distutils import
sysconfig; print(sysconfig.get_config_var('INCLUDEPY'))`
+-if test -f ${PYINCLUDEDIR}/Python.h ;
Re: [OE-core] [PATCH 2/2 v2] libcap-ng: add package 0.7.7
On Aug 21, 2015, at 5:55 PM, Randy MacLeod randy.macl...@windriver.com wrote: On 2015-08-21 03:25 AM, Khem Raj wrote: On Thu, Aug 20, 2015 at 10:38 PM, wenzong@windriver.com wrote: From: Wenzong Fan wenzong@windriver.com Pull package from meta-oe to oe-core: meta-oe commit: bce4dba5546480c8e43c6442959ac7d0a4ef32f6 The libcap-ng library is intended to make programming with posix capabilities much easier than the traditional libcap library. It's not a replacement to libcap, it provides different library (libcap-ng.so) while packages explicitly look for libcap.so. It could be used by qemu, util-linux, libvirt, audit ... With adding it to oe-core, the copies from following layers could be removed: * meta-oe, meta-selinux, meta-security-framework ... I am afraid that we are setting a pretext for moving all recipes that are in multiple layers to be eligible for OE-core now. meta-oe is common layer for extended recipes, so may be other layers should have been a bit more vigilant and made sure there requirements were met with whats in meta-oe. Meta-oe has far to many recipes for some people to want to include the entire layer: meta-oe.git $ find meta-oe/ -name *bb | wc -l 618 We can certainly use the new whitelist layer filtering to get to a smaller collection of recipes but I'd like to suggest we need to document and maybe design the layer structure a bit more. There are lots of different opinions about how to split collections of packages in to different layers so unless someone has a dependency-based analysis of all pacakges in all layers, I don't see much point in a long discussion on this topic. if someone wants to ignore certain recipes use BBMASK, I do not think this whitelisting is a good idea, it does not help in maintaining layer quality, and its much better that we maintained layers in good quality collectively may be with some extra recipes in it instead of cannibalizing few recipes from it into private layers or other layer which one happens to use. It seriously dents the layers user base and quality. If meta-oe hosts certain layers that could be a fit in another middleware or topic layer, lets move it to that layer but lets not encourage the behavior of duplicating the recipes or severely crippling the layer before using it. Has the idea of creating a new meta-openembedded layer for widely-used, OS interface libraries been proposed? These 80 recipes could be considered for inclusion: $ find meta-oe -name lib*bb | wc -l 80 but more consideration is probably needed. In the short term (oe-core-1.9 (now 2.0), I guess we leave things as they are. Sigh… number of layers is a delicate balance too. The more you divide them more smaller the userbase will become and complex becomes the distros. ../Randy While I'm at it, for reference of layer size: $ for i in `ls -d meta-*`; do echo -n $i: ; find $i -name *bb | wc -l; done meta-efl: 57 meta-filesystems: 16 meta-gnome: 82 meta-gpe: 5 meta-initramfs: 14 meta-multimedia: 51 meta-networking: 115 meta-oe: 618 meta-perl: 30 meta-python: 74 meta-ruby: 4 meta-systemd: 1 meta-webserver: 13 meta-xfce: 67 - we should ask what core feature does it enable for reference images and machines. Signed-off-by: Wenzong Fan wenzong@windriver.com --- .../libcap-ng/libcap-ng/python.patch | 58 ++ meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb | 39 +++ 2 files changed, 97 insertions(+) create mode 100644 meta/recipes-support/libcap-ng/libcap-ng/python.patch create mode 100644 meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb diff --git a/meta/recipes-support/libcap-ng/libcap-ng/python.patch b/meta/recipes-support/libcap-ng/libcap-ng/python.patch new file mode 100644 index 000..59591eb --- /dev/null +++ b/meta/recipes-support/libcap-ng/libcap-ng/python.patch @@ -0,0 +1,58 @@ +From b01bb2694f66cd981e6d61523433dc3eb5ed32f2 Mon Sep 17 00:00:00 2001 +From: Li xin lixin.f...@cn.fujitsu.com +Date: Sat, 18 Jul 2015 23:03:30 +0900 +Subject: [PATCH] configure.ac - Avoid an incorrect check for python. + Makefile.am - avoid hard coded host include paths. + +Upstream-Status: pending + +Signed-off-by: Mark Hatle mark.ha...@windriver.com +Signed-off-by: Li Xin lixin.f...@cn.fujitsu.com +--- + bindings/python/Makefile.am | 3 ++- + configure.ac| 15 ++- + 2 files changed, 4 insertions(+), 14 deletions(-) + +diff --git a/bindings/python/Makefile.am b/bindings/python/Makefile.am +index 82b9bb8..f9fe7a8 100644 +--- a/bindings/python/Makefile.am b/bindings/python/Makefile.am +@@ -23,7 +23,8 @@ SUBDIRS = test + CONFIG_CLEAN_FILES = *.loT *.rej *.orig + AM_CFLAGS = -fPIC -DPIC + PYLIBVER ?= python$(PYTHON_VERSION) +-AM_CPPFLAGS = -I. -I$(top_builddir) -I@PYINCLUDEDIR@ ++PYINC ?= /usr/include/$(PYLIBVER)
Re: [OE-core] [PATCH 3/3] libical: Upgrade 1.0.0 - 1.0.1
On 20 August 2015 at 19:11, Burton, Ross ross.bur...@intel.com wrote: On 20 August 2015 at 12:39, Jussi Kukkonen jussi.kukko...@intel.com wrote: +inherit cmake perlnative Why perlnative considering it doesn't depend on any native perl modules? It does some fairly simple header autogeneration during build (see src/libical/Makefile.am and scripts/). As far as I can tell it does not require modules other than core -- but I don't know much about perl (especially in OE build) so let me know if there's gotchas I should look out for. Jussi -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/3] libical: Upgrade 1.0.0 - 1.0.1
On 21 August 2015 at 10:08, Jussi Kukkonen jussi.kukko...@intel.com wrote: On 20 August 2015 at 19:11, Burton, Ross ross.bur...@intel.com wrote: On 20 August 2015 at 12:39, Jussi Kukkonen jussi.kukko...@intel.com wrote: +inherit cmake perlnative Why perlnative considering it doesn't depend on any native perl modules? It does some fairly simple header autogeneration during build (see src/libical/Makefile.am and scripts/). As far as I can tell it does not require modules other than core -- but I don't know much about perl (especially in OE build) so let me know if there's gotchas I should look out for. Sorry, not Makefile.am but the cmake files under same directory. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2 v2] libcap-ng: add package 0.7.7
On Thu, Aug 20, 2015 at 10:38 PM, wenzong@windriver.com wrote:
From: Wenzong Fan wenzong@windriver.com
Pull package from meta-oe to oe-core:
meta-oe commit: bce4dba5546480c8e43c6442959ac7d0a4ef32f6
The libcap-ng library is intended to make programming with posix
capabilities much easier than the traditional libcap library.
It's not a replacement to libcap, it provides different library
(libcap-ng.so) while packages explicitly look for libcap.so. It
could be used by qemu, util-linux, libvirt, audit ...
With adding it to oe-core, the copies from following layers could
be removed:
* meta-oe, meta-selinux, meta-security-framework ...
I am afraid that we are setting a pretext for moving all recipes that
are in multiple layers to be eligible for OE-core now.
met-oe is common layer for extended recipes, so may be other layers
should have been a bit more vigilant and made sure
there requirements were met with whats in meta-oe.
we should ask what core feature does it enable for reference images
and machines.
Signed-off-by: Wenzong Fan wenzong@windriver.com
---
.../libcap-ng/libcap-ng/python.patch | 58
++
meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb | 39 +++
2 files changed, 97 insertions(+)
create mode 100644 meta/recipes-support/libcap-ng/libcap-ng/python.patch
create mode 100644 meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb
diff --git a/meta/recipes-support/libcap-ng/libcap-ng/python.patch
b/meta/recipes-support/libcap-ng/libcap-ng/python.patch
new file mode 100644
index 000..59591eb
--- /dev/null
+++ b/meta/recipes-support/libcap-ng/libcap-ng/python.patch
@@ -0,0 +1,58 @@
+From b01bb2694f66cd981e6d61523433dc3eb5ed32f2 Mon Sep 17 00:00:00 2001
+From: Li xin lixin.f...@cn.fujitsu.com
+Date: Sat, 18 Jul 2015 23:03:30 +0900
+Subject: [PATCH] configure.ac - Avoid an incorrect check for python.
+ Makefile.am - avoid hard coded host include paths.
+
+Upstream-Status: pending
+
+Signed-off-by: Mark Hatle mark.ha...@windriver.com
+Signed-off-by: Li Xin lixin.f...@cn.fujitsu.com
+---
+ bindings/python/Makefile.am | 3 ++-
+ configure.ac| 15 ++-
+ 2 files changed, 4 insertions(+), 14 deletions(-)
+
+diff --git a/bindings/python/Makefile.am b/bindings/python/Makefile.am
+index 82b9bb8..f9fe7a8 100644
+--- a/bindings/python/Makefile.am
b/bindings/python/Makefile.am
+@@ -23,7 +23,8 @@ SUBDIRS = test
+ CONFIG_CLEAN_FILES = *.loT *.rej *.orig
+ AM_CFLAGS = -fPIC -DPIC
+ PYLIBVER ?= python$(PYTHON_VERSION)
+-AM_CPPFLAGS = -I. -I$(top_builddir) -I@PYINCLUDEDIR@
++PYINC ?= /usr/include/$(PYLIBVER)
++AM_CPPFLAGS = -I. -I$(top_builddir) -I$(PYINC)
+ LIBS = $(top_builddir)/src/libcap-ng.la
+ SWIG_FLAGS = -python
+ SWIG_INCLUDES = ${AM_CPPFLAGS}
+diff --git a/configure.ac b/configure.ac
+index 1d777d5..9d90f64 100644
+--- a/configure.ac
b/configure.ac
+@@ -123,19 +123,8 @@ if test x$use_python = xno ; then
+ else
+ AC_MSG_RESULT(testing)
+ AM_PATH_PYTHON
+-PYINCLUDEDIR=`python${am_cv_python_version} -c from distutils import
sysconfig; print(sysconfig.get_config_var('INCLUDEPY'))`
+-if test -f ${PYINCLUDEDIR}/Python.h ; then
+- python_found=yes
+- AC_SUBST(PYINCLUDEDIR)
+- AC_MSG_NOTICE(Python bindings will be built)
+-else
+- python_found=no
+- if test x$use_python = xyes ; then
+- AC_MSG_ERROR([Python explicitly required and python headers
found])
+- else
+- AC_MSG_WARN(Python headers not found - python bindings will
not be made)
+- fi
+-fi
++python_found=yes
++AC_MSG_NOTICE(Python bindings will be built)
+ fi
+ AM_CONDITIONAL(HAVE_PYTHON, test ${python_found} = yes)
+
+--
+1.8.4.2
+
diff --git a/meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb
b/meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb
new file mode 100644
index 000..a31d5dc
--- /dev/null
+++ b/meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb
@@ -0,0 +1,39 @@
+SUMMARY = An alternate posix capabilities library
+DESCRIPTION = The libcap-ng library is intended to make programming \
+with POSIX capabilities much easier than the traditional libcap library.
+HOMEPAGE = http://freecode.com/projects/libcap-ng;
+SECTION = base
+LICENSE = GPLv2+ LGPLv2.1+
+LIC_FILES_CHKSUM = file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
+ file://COPYING.LIB;md5=e3eda01d9815f8d24aae2dbd89b68b06
+
+SRC_URI = http://people.redhat.com/sgrubb/libcap-ng/libcap-ng-${PV}.tar.gz \
+ file://python.patch
+
+inherit lib_package autotools pythonnative
+
+SRC_URI[md5sum] = 3d7d126b29e2869a0257c17c8b0d9b2e
+SRC_URI[sha256sum] =
615549ce39b333f6b78baee0c0b4ef18bc726c6bf1cca123dfd89dd963f6d06b
+
+DEPENDS += swig-native python
+
+EXTRA_OECONF += --without-python3
+
+EXTRA_OEMAKE += PYLIBVER='python${PYTHON_BASEVERSION}'
PYINC='${STAGING_INCDIR}/${PYLIBVER}'
+
Re: [OE-core] [PATCH 2/4 V2] systemd: Upgrade 219 - 224
Hi Khem, I built core-image-minimal for qemuarm64. There's a lot of failures and warnings at boot time and the system boots into rescue mode. And I also verified 199 has no such problem. Best Regards, Chen Qi On 08/21/2015 09:46 AM, Randy MacLeod wrote: On 2015-08-20 09:17 PM, Khem Raj wrote: On Thu, Aug 20, 2015 at 6:04 AM, Philip Balister phi...@balister.org wrote: On 08/19/2015 10:21 PM, Khem Raj wrote: On Wed, Aug 19, 2015 at 12:55 PM, Burton, Ross ross.bur...@intel.com wrote: On 17 August 2015 at 16:41, Khem Raj raj.k...@gmail.com wrote: There are many reasons, for me its overlay support for systemd-nspawn, networkd has got many new features that is now usable w.r.t. IP forwarding, vxlan etc. and it has many bug fixed in those 2000 odd commits since 219, no different then any other package upgrades we do in general it keep the upgrade workload lower as we roll the releases. Any specific concerns ? Can we get an updated patch with a clearer commit log? I've also heard that as systemd evolves, more binaries are getting added to the base package that should be packaged separately for people interested in small images. I do not have personal experience here, but wanted to pass along the feedback. We should look at buildhistory packaging differences when we do upgrades. Here is the diff between files in 219 and 224, if you want to know more I can paste more info just let me know. https://gist.github.com/kraj/2a066973a5e5cf83ed24 sizes have gone up on daemons, no new daemons besides some new service files and scripts are added ubu-15.10 will use v224 as well: http://cdimage.ubuntu.com/daily-live/current/wily-desktop-amd64.manifest and Arch and a couple other distro are using this version already: http://pkgs.org/download/systemd v224 was released 3 weeks ago: --- $ git log -1 v224 commit b2a0ac5e5b29c73ca7c0da23369a4769d5a91ddd ... Date: Fri Jul 31 18:56:38 2015 +0200 --- Khem's summary of the binaries is reassuring given that there has been lots of churn: $ git log --oneline v219..v224 | wc -l 2167 $ git diff v219..v224 | diffstat | tail -1 1367 files changed, 109907 insertions(+), 166577 deletions(-) I'm skimming the NEWS file from 219-224 and I haven't seen anything that concerns me yet: https://github.com/systemd/systemd/blob/master/NEWS Qi, Please take a closer look at the NEWS file, review Khem's uprev and build and boot qemuarm64, qemuppc when you have time. Send partial feedback today even if you just review the commit and NEWS file. Qi may not be able to do that in the next couple of day due to SDK work. Khem, What testing have you done so far? Any ptest? What toolchain version are you building with, btw? It's late in M3 and we still have the kernel and toolchain coming in but unless we hear of known problems with v224, let's go for it once the new toolchain and kernel have settled. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/5] Packages Upgrade
The following changes since commit c38acd720b3f6ffbeb544063692eb471dada8593:
binconfig-disabled: write an message to stderr to help confused developers
(2015-08-19 17:57:58 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib rbt/PU
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/PU
Robert Yang (5):
gnupg: 2.1.6 - 2.1.7
man-pages: 4.01 - 4.02
gnu-efi: 3.0.2 - 3.0.3
btrfs-tools: 4.1.1 - 4.1.2
oprofile: 1.0.0 - 1.1.0
.../gnu-efi/{gnu-efi_3.0.2.bb = gnu-efi_3.0.3.bb} |5 ++-
.../btrfs-tools/btrfs-tools_git.bb |2 +-
.../{man-pages_4.01.bb = man-pages_4.02.bb} |4 +-
meta/recipes-kernel/oprofile/oprofile.inc |3 +-
.../oprofile/oprofile/filemode-fix.patch | 41
.../{oprofile_1.0.0.bb = oprofile_1.1.0.bb} |5 +--
.../gnupg/{gnupg_2.1.6.bb = gnupg_2.1.7.bb} |4 +-
7 files changed, 11 insertions(+), 53 deletions(-)
rename meta/recipes-bsp/gnu-efi/{gnu-efi_3.0.2.bb = gnu-efi_3.0.3.bb} (93%)
rename meta/recipes-extended/man-pages/{man-pages_4.01.bb =
man-pages_4.02.bb} (86%)
delete mode 100644 meta/recipes-kernel/oprofile/oprofile/filemode-fix.patch
rename meta/recipes-kernel/oprofile/{oprofile_1.0.0.bb = oprofile_1.1.0.bb}
(44%)
rename meta/recipes-support/gnupg/{gnupg_2.1.6.bb = gnupg_2.1.7.bb} (89%)
--
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] btrfs-tools: 4.1.1 - 4.1.2
Signed-off-by: Robert Yang liezhi.y...@windriver.com --- .../btrfs-tools/btrfs-tools_git.bb |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-devtools/btrfs-tools/btrfs-tools_git.bb b/meta/recipes-devtools/btrfs-tools/btrfs-tools_git.bb index 4ad4b81..15cc3f2 100644 --- a/meta/recipes-devtools/btrfs-tools/btrfs-tools_git.bb +++ b/meta/recipes-devtools/btrfs-tools/btrfs-tools_git.bb @@ -12,7 +12,7 @@ LIC_FILES_CHKSUM = file://COPYING;md5=fcb02dc552a041dee27e4b85c7396067 SECTION = base DEPENDS = util-linux attr e2fsprogs lzo acl -SRCREV = 20be329fdb569fefdf88ba0e4ca1a41488fcbc19 +SRCREV = 7f1328ccb5d159efe850d4eaea9b49bbe8c4181e SRC_URI = git://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git \ file://fix-parallel.patch \ -- 1.7.9.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/5] man-pages: 4.01 - 4.02
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
.../{man-pages_4.01.bb = man-pages_4.02.bb} |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-extended/man-pages/{man-pages_4.01.bb =
man-pages_4.02.bb} (86%)
diff --git a/meta/recipes-extended/man-pages/man-pages_4.01.bb
b/meta/recipes-extended/man-pages/man-pages_4.02.bb
similarity index 86%
rename from meta/recipes-extended/man-pages/man-pages_4.01.bb
rename to meta/recipes-extended/man-pages/man-pages_4.02.bb
index f6a5c49..1b90a44 100644
--- a/meta/recipes-extended/man-pages/man-pages_4.01.bb
+++ b/meta/recipes-extended/man-pages/man-pages_4.02.bb
@@ -7,8 +7,8 @@ LICENSE = GPLv2+
LIC_FILES_CHKSUM = file://README;md5=8f2a3d43057d458e5066714980567a60
SRC_URI = ${KERNELORG_MIRROR}/linux/docs/${BPN}/Archive/${BP}.tar.gz
-SRC_URI[md5sum] = 575f4e8920166b1433c329bb621819d1
-SRC_URI[sha256sum] =
ba89f3453982fae6c699a877368d51ee27883b4de709e753eee3783b447a8381
+SRC_URI[md5sum] = 93df3279798a3345bb2c709584c83639
+SRC_URI[sha256sum] =
42324f9ed47c89a43cb37b6bb0d5fbcad44838eee45cd394e181c98d038c49ff
RDEPENDS_${PN} = man
--
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] oprofile: 1.0.0 - 1.1.0
* Remove backport patch filemode-fix.patch.
* Update --with-kernel=${STAGING_DIR_HOST}/${prefix} to find kernel
headers (linux/*.h) to fix the error:
| checking kernel supports perf_events... unknown -- perf_event.h not found
| ERROR: You requested to build oprofile with
'--with-kernel=/buildarea/lyang1/test_f2/tmp/work-shared/qemux86/kernel-source',
| but headers were not accessible at the given location.
| Be sure you have run the following command from within your kernel source
tree:
| make headers_install INSTALL_HDR_PATH=kernel-hdrs-install-dir
| Then pass kernel-hdrs-install-dir to oprofile's '--with-kernel' configure
option.
| configure: error: Unable to build oprofile. Exiting.
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
meta/recipes-kernel/oprofile/oprofile.inc |3 +-
.../oprofile/oprofile/filemode-fix.patch | 41
.../{oprofile_1.0.0.bb = oprofile_1.1.0.bb} |5 +--
3 files changed, 3 insertions(+), 46 deletions(-)
delete mode 100644 meta/recipes-kernel/oprofile/oprofile/filemode-fix.patch
rename meta/recipes-kernel/oprofile/{oprofile_1.0.0.bb = oprofile_1.1.0.bb}
(44%)
diff --git a/meta/recipes-kernel/oprofile/oprofile.inc
b/meta/recipes-kernel/oprofile/oprofile.inc
index 6b393bc..6ec56e7 100644
--- a/meta/recipes-kernel/oprofile/oprofile.inc
+++ b/meta/recipes-kernel/oprofile/oprofile.inc
@@ -19,7 +19,6 @@ FILES_${PN}-dev += ${libdir}/${BPN}/lib*${SOLIBSDEV}
${libdir}/${BPN}/lib*.la
FILES_${PN}-staticdev += ${libdir}/${BPN}/lib*.a
SRC_URI = ${SOURCEFORGE_MIRROR}/${BPN}/${BPN}-${PV}.tar.gz \
- file://filemode-fix.patch \
file://acinclude.m4 \
file://automake-foreign.patch \
file://oprofile-cross-compile-tests.patch \
@@ -28,7 +27,7 @@ SRC_URI = ${SOURCEFORGE_MIRROR}/${BPN}/${BPN}-${PV}.tar.gz \
inherit autotools pkgconfig ptest
-EXTRA_OECONF = --with-kernel=${STAGING_KERNEL_DIR} --without-x
ac_cv_prog_XSLTPROC=
+EXTRA_OECONF = --with-kernel=${STAGING_DIR_HOST}${prefix} --without-x
ac_cv_prog_XSLTPROC=
do_configure () {
cp ${WORKDIR}/acinclude.m4 ${S}/
autotools_do_configure
diff --git a/meta/recipes-kernel/oprofile/oprofile/filemode-fix.patch
b/meta/recipes-kernel/oprofile/oprofile/filemode-fix.patch
deleted file mode 100644
index f7ebe24..000
--- a/meta/recipes-kernel/oprofile/oprofile/filemode-fix.patch
+++ /dev/null
@@ -1,41 +0,0 @@
-With security_flags.inc:
-
-| In file included from
/media/build1/poky/build/tmp/sysroots/qemumips/usr/include/fcntl.h:302:0,
-| from opjitconv.c:25:
-| In function 'open',
-| inlined from 'copy_dumpfile' at opjitconv.c:219:6:
-|
/media/build1/poky/build/tmp/sysroots/qemumips/usr/include/bits/fcntl2.h:50:4:
error: call to '__open_missing_mode' declared with attribute error: open with
O_CREAT in second argument needs 3 arguments
-| __open_missing_mode ();
-| ^
-| Makefile:440: recipe for target 'opjitconv.o' failed
-
-Why does this only happen on mips? mips has:
-
-O_CREAT = 0x100
-and
-S_IRUSR = 0400
-
-and these (in hex and otcal) are equivalent. Most other platforms
-have O_CREAT = 0100.
-
-http://sourceforge.net/p/oprofile/oprofile/ci/4598ca73b0a367ca46d4a2843261e20e1896773b
-
-The file should not be created, only opened if its present, therefore use
O_RDONLY instead.
-
-RP 2014/11/6
-
-Upstream-Status: Backport
-
-Index: oprofile-1.0.0/opjitconv/opjitconv.c
-===
oprofile-1.0.0.orig/opjitconv/opjitconv.c 2014-09-12 14:39:47.0
+
-+++ oprofile-1.0.0/opjitconv/opjitconv.c 2014-11-06 13:14:25.941639003
+
-@@ -216,7 +216,7 @@
- int file_locked = 0;
- unsigned int usecs_waited = 0;
- int rc = OP_JIT_CONV_OK;
-- int fd = open(dumpfile, S_IRUSR);
-+ int fd = open(dumpfile, O_RDONLY);
- if (fd 0) {
- perror(opjitconv failed to open JIT dumpfile);
- return OP_JIT_CONV_FAIL;
diff --git a/meta/recipes-kernel/oprofile/oprofile_1.0.0.bb
b/meta/recipes-kernel/oprofile/oprofile_1.1.0.bb
similarity index 44%
rename from meta/recipes-kernel/oprofile/oprofile_1.0.0.bb
rename to meta/recipes-kernel/oprofile/oprofile_1.1.0.bb
index b44b5c5..92a94ad 100644
--- a/meta/recipes-kernel/oprofile/oprofile_1.0.0.bb
+++ b/meta/recipes-kernel/oprofile/oprofile_1.1.0.bb
@@ -3,9 +3,8 @@ require oprofile.inc
DEPENDS += virtual/kernel
DEPENDS_append_powerpc64 = libpfm4
-SRC_URI[md5sum] = ba0b340e5c421a93959776c836ed35b3
-SRC_URI[sha256sum] =
847110b4ecdcf8c8353cd38f94c1b704aad4bfcd9453e38b88d112cfb7e3c45a
+SRC_URI[md5sum] = 248c4c069f9476f427fa7195563f9867
+SRC_URI[sha256sum] =
cf759a6de1a6033d5dfc93bda129a9f2e128aecc4238cc657feb0801d1b0366c
S = ${WORKDIR}/oprofile-${PV}
-PR = r1
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
[OE-core] [PATCH 1/5] gnupg: 2.1.6 - 2.1.7
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
.../gnupg/{gnupg_2.1.6.bb = gnupg_2.1.7.bb} |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-support/gnupg/{gnupg_2.1.6.bb = gnupg_2.1.7.bb} (89%)
diff --git a/meta/recipes-support/gnupg/gnupg_2.1.6.bb
b/meta/recipes-support/gnupg/gnupg_2.1.7.bb
similarity index 89%
rename from meta/recipes-support/gnupg/gnupg_2.1.6.bb
rename to meta/recipes-support/gnupg/gnupg_2.1.7.bb
index 59aac37..48c7c96 100644
--- a/meta/recipes-support/gnupg/gnupg_2.1.6.bb
+++ b/meta/recipes-support/gnupg/gnupg_2.1.7.bb
@@ -14,8 +14,8 @@ SRC_URI =
ftp://ftp.gnupg.org/gcrypt/${BPN}/${BPN}-${PV}.tar.bz2 \
file://dirmngr-uses-libgpg-error.patch \
-SRC_URI[md5sum] = cc7345b1d9ada92a0d19f4ae406741b4
-SRC_URI[sha256sum] =
5e599ad542199f3bd733eed2b88a539d1b4c3beda2dbab0ff69f1896f52e92fd
+SRC_URI[md5sum] = ebdf92b15b8bcd8579b643c7f41a3238
+SRC_URI[sha256sum] =
c18a3776d47fec98892d51d28b6574ef16bf0a25eabb0956231058aaf2e7846e
EXTRA_OECONF = --disable-ldap \
--disable-ccid-driver \
--
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] gnu-efi: 3.0.2 - 3.0.3
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
.../gnu-efi/{gnu-efi_3.0.2.bb = gnu-efi_3.0.3.bb} |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
rename meta/recipes-bsp/gnu-efi/{gnu-efi_3.0.2.bb = gnu-efi_3.0.3.bb} (93%)
diff --git a/meta/recipes-bsp/gnu-efi/gnu-efi_3.0.2.bb
b/meta/recipes-bsp/gnu-efi/gnu-efi_3.0.3.bb
similarity index 93%
rename from meta/recipes-bsp/gnu-efi/gnu-efi_3.0.2.bb
rename to meta/recipes-bsp/gnu-efi/gnu-efi_3.0.3.bb
index 9ad258e..8cc22ca 100644
--- a/meta/recipes-bsp/gnu-efi/gnu-efi_3.0.2.bb
+++ b/meta/recipes-bsp/gnu-efi/gnu-efi_3.0.3.bb
@@ -18,8 +18,9 @@ SRC_URI = ${SOURCEFORGE_MIRROR}/${BPN}/${BP}.tar.bz2 \
file://parallel-make-archives.patch \
file://lib-Makefile-fix-parallel-issue.patch \
-SRC_URI[md5sum] = a9db2cabc01a2674715bd6aea2911f01
-SRC_URI[sha256sum] =
194b580ecdb1fad0e41914845ba064c279afb687855960b58693459e5537b4d7
+
+SRC_URI[md5sum] = 15a4bcbc18a9a5e8110ed955970622e6
+SRC_URI[sha256sum] =
c530f21a15fd9c214dd92d29a6caa20fac989289267512020b6da1f5e6f5b4cb
COMPATIBLE_HOST = (x86_64.*|i.86.*|aarch64.*|arm.*)-linux
--
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] nettle: clean up license information
On 18 August 2015 at 11:03, Martin Jansa martin.ja...@gmail.com wrote:
On Sun, Aug 09, 2015 at 10:58:21AM +0530, Armin Kuster wrote:
adding the license definitions on the few packages that
deviate from the overall package license.
based on http://www.lysator.liu.se/~nisse/nettle/nettle.html#Copyright
and spot checking files.
Signed-off-by: Armin Kuster akuster...@gmail.com
---
meta/recipes-support/nettle/nettle_2.7.1.bb | 9 +
1 file changed, 9 insertions(+)
diff --git a/meta/recipes-support/nettle/nettle_2.7.1.bb
b/meta/recipes-support/nettle/nettle_2.7.1.bb
index f53afcc..f9d331f 100644
--- a/meta/recipes-support/nettle/nettle_2.7.1.bb
+++ b/meta/recipes-support/nettle/nettle_2.7.1.bb
@@ -2,6 +2,15 @@ SUMMARY = A low level cryptographic library
HOMEPAGE = http://www.lysator.liu.se/~nisse/nettle/;
SECTION = libs
LICENSE = LGPLv2.1 GPLv2
It would be nice to package GPLv2 files in separate package as well (or
LGPLv2.1 library in seprate package) if you have time to do that.
Forgot to answer this, sorry.
For 2.7.1 what you suggest may work -- there may be some tools that
are GPLv2 that we could separate. But for the new version the strange
LGPLv3+ | GPLv2+ license combo is _not_ a result of the library
being LGPL and some utilities being GPL: the library itself (like a
lot of GNU stuff nowadays) is dual licensed like that.
It seems weird but actually makes sense for GNU: It forces all users
to comply with LGPLv3, except the GPLv2 programs that can't easily be
relicensed to GPLv3. Those GPLv2 programs would be incompatible with
the newer LGPLv3 libraries but this dual-licensing lets them off the
hook.
Jussi
+LICENSE_${PN}-cast = CC0
+LICENSE_${PN}-gosthash = MIT
+
+# both public and GPL license listed
+LICENSE_${PN}-md2 = CC0 LGPLv2.1+
+LICENSE_${PN}-md4 = CC0 LGPLv2.1+
+
+
LIC_FILES_CHKSUM = file://COPYING.LIB;md5=2d5025d4aa3495befef8f17206a5b0a1
\
file://serpent-decrypt.c;beginline=53;endline=67;md5=bcfd4745d53ca57f82907089898e390d
\
file://serpent-set-key.c;beginline=56;endline=70;md5=bcfd4745d53ca57f82907089898e390d
--
2.3.5
--
___
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
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 1/1] classes/whitelist: add class to allow whitelisting recipes from a layer
-Original Message- From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core- boun...@lists.openembedded.org] On Behalf Of Patrick Ohly Sent: Thursday, August 20, 2015 9:47 PM To: Paul Eggleton Cc: openembedded-core@lists.openembedded.org Subject: Re: [OE-core] [RFC PATCH 1/1] classes/whitelist: add class to allow whitelisting recipes from a layer On Wed, 2015-08-19 at 14:34 +0100, Paul Eggleton wrote: Allow restricting recipes brought from a layer to a specified list. This is similar in operation to blacklist.bbclass, but instead specifies a per-layer whitelist of recipes (matched by BPN) that are able to be built from the layer - anything else is skipped. This is potentially useful where you want to bring in a select set of recipes from a larger layer e.g. meta-oe. Worked for all of my tests. I added all layers in meta-openembedded and then white-listed just gmock in meta-oe (aka openembedded-layer): This worked for my tests as well, there are 160 recipes in my whitelist and there are 3 different cases: 1) All recipes are needed: nothing need to be done here. 2) No recipe is needed: PNWHITELIST_efl-layer = Nothing PNWHITELIST_filesystems-layer = Nothing PNWHITELIST_gpe-layer = Nothing PNWHITELIST_meta-initramfs = Nothing PNWHITELIST_multimedia-layer = Nothing PNWHITELIST_ruby-layer = Nothing PNWHITELIST_systemd-layer = Nothing PNWHITELIST_toolchain-layer = Nothing 3) Some of the recipes are whitelisted, take gnome-layer for example: PNWHITELIST_gnome-layer = \ gnome-disk-utility \ gnome-keyring \ gsettings-desktop-schemas \ gvfs \ gvfs-gdu-volume-monitor \ libgnome-keyring \ libgtop \ libwnck \ libwnck3 \ libxklavier \ metacity \ I also test to put some recipes both in whitelist and blacklist, and it turned out that the blacklist's priority is higher than whitelist. INHERIT += whitelist PNWHITELIST_efl-layer = no-recipe-enabled PNWHITELIST_filesystems-layer = no-recipe-enabled PNWHITELIST_gnome-layer = no-recipe-enabled PNWHITELIST_gpe-layer = no-recipe-enabled PNWHITELIST_meta-initramfs = no-recipe-enabled PNWHITELIST_meta-python = no-recipe-enabled PNWHITELIST_multimedia-layer = no-recipe-enabled PNWHITELIST_networking-layer = no-recipe-enabled PNWHITELIST_openembedded-layer = gmock PNWHITELIST_perl-layer = no-recipe-enabled PNWHITELIST_ruby-layer = no-recipe-enabled PNWHITELIST_systemd-layer = no-recipe-enabled PNWHITELIST_toolchain-layer = no-recipe-enabled PNWHITELIST_webserver = no-recipe-enabled PNWHITELIST_xfce-layer = no-recipe-enabled I got warnings for several of the layers, but strangely not for all of them: WARNING: No bb files matched BBFILE_PATTERN_efl-layer '^/work/meta-openembedded/meta-efl/' WARNING: No bb files matched BBFILE_PATTERN_filesystems-layer '^/work/meta- openembedded/meta-filesystems/' WARNING: No bb files matched BBFILE_PATTERN_gpe-layer '^/work/meta-openembedded/meta- gpe/' WARNING: No bb files matched BBFILE_PATTERN_meta-initramfs '^/work/meta- openembedded/meta-initramfs/' WARNING: No bb files matched BBFILE_PATTERN_multimedia-layer '^/work/meta- openembedded/meta-multimedia/' WARNING: No bb files matched BBFILE_PATTERN_networking-layer '^/work/meta- openembedded/meta-networking/' WARNING: No bb files matched BBFILE_PATTERN_perl-layer '^/work/meta-openembedded/meta- perl/' WARNING: No bb files matched BBFILE_PATTERN_meta-python '^/work/meta- openembedded/meta-python/' WARNING: No bb files matched BBFILE_PATTERN_ruby-layer '^/work/meta-openembedded/meta- ruby/' WARNING: No bb files matched BBFILE_PATTERN_webserver '^/work/meta-openembedded/meta- webserver/' WARNING: No bb files matched BBFILE_PATTERN_xfce-layer '^/work/meta-openembedded/meta- xfce/' Note that gnome-layer is not warned about, although none of its recipes are enabled (checked with bitbake-layers show-recipes -f | grep -v '(skipped)' | grep meta-gnome). Any idea why? One more comment: it would be slightly nicer if empty whitelist could be distinguished from no whitelist, with empty meaning enable no recipes. In other words, replace if whitelist with if whitelist is not None. I want to list all PNWHITELIST_xxx values for meta-openembedded, even when the layer is not (yet) in bblayers.sample.conf, in order to be prepared for adding it later. Doing that with an empty string is more readable than with a fake recipe name to make the variable non-empty. I vote for this suggestion, it's better than a fake recipe name. Thanks, Jackie -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ Openembedded-core mailing list
[OE-core] [PATCH] perf: fix the check
From: Roy Li rongqing...@windriver.com
$(grep xxx xxx) never returns 0, it maybe return empty or a string, and
can not compare with 0
Signed-off-by: Roy Li rongqing...@windriver.com
---
meta/recipes-kernel/perf/perf.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb
index 246f1b4..0aff9fb 100644
--- a/meta/recipes-kernel/perf/perf.bb
+++ b/meta/recipes-kernel/perf/perf.bb
@@ -111,7 +111,7 @@ do_install() {
unset CFLAGS
oe_runmake DESTDIR=${D} install
# we are checking for this make target to be compatible with older perf
versions
- if [ ${@perf_feature_enabled('perf-scripting', 1, 0, d)} = 1 -a
$(grep install-python_ext ${S}/tools/perf/Makefile) = 0 ]; then
+ if [ ${@perf_feature_enabled('perf-scripting', 1, 0, d)} = 1 ]
grep -q install-python_ext ${S}/tools/perf/Makefile; then
oe_runmake DESTDIR=${D} install-python_ext
fi
}
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
