[OE-core] [PATCH] vte: upgrade 0.56.3 -> 0.58.2
* they moved to meson build
* all autotools specific patches must go
* although not inheriting gettext dependency on intltool-native can go
* tested with all variants of PACKAGECONFIG
* need it for gnome-terminal 3.34
Signed-off-by: Andreas Müller
---
.../vte/vte/0001-Add-m4-vapigen.m4.patch | 119 --
...t-enable-stack-protection-by-default.patch | 29 -
...XITCODE-macro-for-non-glibc-systems.patch} | 0
.../vte/{vte_0.56.3.bb => vte_0.58.2.bb} | 25 ++--
4 files changed, 12 insertions(+), 161 deletions(-)
delete mode 100644 meta/recipes-support/vte/vte/0001-Add-m4-vapigen.m4.patch
delete mode 100644
meta/recipes-support/vte/vte/0001-Don-t-enable-stack-protection-by-default.patch
rename
meta/recipes-support/vte/vte/{0001-Add-W_EXITCODE-macro-for-non-glibc-systems.patch
=> 0002-Add-W_EXITCODE-macro-for-non-glibc-systems.patch} (100%)
rename meta/recipes-support/vte/{vte_0.56.3.bb => vte_0.58.2.bb} (60%)
diff --git a/meta/recipes-support/vte/vte/0001-Add-m4-vapigen.m4.patch
b/meta/recipes-support/vte/vte/0001-Add-m4-vapigen.m4.patch
deleted file mode 100644
index 1c5630ed9c..00
--- a/meta/recipes-support/vte/vte/0001-Add-m4-vapigen.m4.patch
+++ /dev/null
@@ -1,119 +0,0 @@
-From 08ca1c48b25c332b75bba2a6b5d757da006e955b Mon Sep 17 00:00:00 2001
-From: Jussi Kukkonen
-Date: Fri, 7 Oct 2016 16:27:57 +0300
-Subject: [PATCH] Add m4/vapigen.m4
-
-Building without vala will fail if we don't have a vapigen.m4.
-
-Upstream-Status: Pending
-Signed-off-by: Jussi Kukkonen
- m4/vapigen.m4 | 96 +++
- 1 file changed, 96 insertions(+)
- create mode 100644 m4/vapigen.m4
-
-diff --git a/m4/vapigen.m4 b/m4/vapigen.m4
-new file mode 100644
-index 000..f2df12f
/dev/null
-+++ b/m4/vapigen.m4
-@@ -0,0 +1,96 @@
-+dnl vapigen.m4
-+dnl
-+dnl Copyright 2012 Evan Nemerson
-+dnl
-+dnl This library is free software; you can redistribute it and/or
-+dnl modify it under the terms of the GNU Lesser General Public
-+dnl License as published by the Free Software Foundation; either
-+dnl version 2.1 of the License, or (at your option) any later version.
-+dnl
-+dnl This library is distributed in the hope that it will be useful,
-+dnl but WITHOUT ANY WARRANTY; without even the implied warranty of
-+dnl MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-+dnl Lesser General Public License for more details.
-+dnl
-+dnl You should have received a copy of the GNU Lesser General Public
-+dnl License along with this library; if not, write to the Free Software
-+dnl Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
USA
-+
-+# VAPIGEN_CHECK([VERSION], [API_VERSION], [FOUND-INTROSPECTION], [DEFAULT])
-+# --
-+# Check vapigen existence and version
-+#
-+# See http://live.gnome.org/Vala/UpstreamGuide for detailed documentation
-+AC_DEFUN([VAPIGEN_CHECK],
-+[
-+ AC_BEFORE([GOBJECT_INTROSPECTION_CHECK],[$0])
-+ AC_BEFORE([GOBJECT_INTROSPECTION_REQUIRE],[$0])
-+
-+ AC_ARG_ENABLE([vala],
-+[AS_HELP_STRING([--enable-vala[=@<:@no/auto/yes@:>@]],[build Vala
bindings @<:@default=]ifelse($4,,auto,$4)[@:>@])],,[
-+ AS_IF([test "x$4" = "x"], [
-+ enable_vala=auto
-+], [
-+ enable_vala=$4
-+])
-+])
-+
-+ AS_CASE([$enable_vala], [no], [enable_vala=no],
-+ [yes], [
-+AS_IF([test "x$3" != "xyes" -a "x$found_introspection" != "xyes"], [
-+AC_MSG_ERROR([Vala bindings require GObject Introspection])
-+ ])
-+ ], [auto], [
-+AS_IF([test "x$3" != "xyes" -a "x$found_introspection" != "xyes"], [
-+enable_vala=no
-+ ])
-+ ], [
-+AC_MSG_ERROR([Invalid argument passed to --enable-vala, should be one
of @<:@no/auto/yes@:>@])
-+ ])
-+
-+ AS_IF([test "x$2" = "x"], [
-+ vapigen_pkg_name=vapigen
-+], [
-+ vapigen_pkg_name=vapigen-$2
-+])
-+ AS_IF([test "x$1" = "x"], [
-+ vapigen_pkg="$vapigen_pkg_name"
-+], [
-+ vapigen_pkg="$vapigen_pkg_name >= $1"
-+])
-+
-+ PKG_PROG_PKG_CONFIG
-+
-+ PKG_CHECK_EXISTS([$vapigen_pkg], [
-+ AS_IF([test "$enable_vala" = "auto"], [
-+ enable_vala=yes
-+])
-+], [
-+ AS_CASE([$enable_vala], [yes], [
-+ AC_MSG_ERROR([$vapigen_pkg not found])
-+], [auto], [
-+ enable_vala=no
-+])
-+])
-+
-+ AC_MSG_CHECKING([for vala])
-+
-+ AS_CASE([$enable_vala],
-+[yes], [
-+ VAPIGEN=`$PKG_CONFIG --variable=vapigen vapigen`
-+ VAPIGEN_MAKEFILE=`$PKG_CONFIG --variable=datadir
vapigen`/vala/Makefile.vapigen
-+ AS_IF([test "x$2" = "x"], [
-+ VAPIGEN_VAPIDIR=`$PKG_CONFIG --variable=vapidir vapigen`
-+], [
-+ VAPIGEN_VAPIDIR=`$PKG_CONFIG --variable=vapidir_versioned vapigen`
-+])
-+])
-+
-+ AC_MSG_RESULT([$enable_vala])
-+
-+ AC_SUBST([VAPIGEN])
-+ AC_SUBST([VAPIGEN_VAPIDIR])
Re: [OE-core] [RFC 1/1] coreutils: add ptest
On 11/1/19 11:37 AM, Trevor Gamblin wrote:
From: Trevor Gamblin
For the non-RFC you need a longer log including
the current test results on qemux86-64/arm64.
Signed-off-by: Trevor Gamblin
---
.../coreutils/coreutils/run-ptest | 21 ++
meta/recipes-core/coreutils/coreutils_8.31.bb | 39 +++
2 files changed, 60 insertions(+)
create mode 100755 meta/recipes-core/coreutils/coreutils/run-ptest
diff --git a/meta/recipes-core/coreutils/coreutils/run-ptest
b/meta/recipes-core/coreutils/coreutils/run-ptest
new file mode 100755
index 00..07f34a8d3e
--- /dev/null
+++ b/meta/recipes-core/coreutils/coreutils/run-ptest
@@ -0,0 +1,21 @@
+#!/bin/bash
+
+COREUTILSLIB=/usr/lib/coreutils
+LOG="${COREUTILSLIB}/ptest/coreutils_ptest_$(date +%Y%m%d-%H%M%S).log"
+
+addgroup usergroup1
[add|del][group|user] programs are friendlier perl scripts
[group|user][add|del] programs are native executables.
It's probably better to use the smaller executables unless you already
need perl to run the tests.
+sleep 1
hmmm
+adduser --ingroup usergroup1 tester
+chmod -R 777 ../ptest
+sleep 2
ugh!
Why did you add the sleeps?
It's not much of a delay given how long the ptests take to run
but it's odd to see and none of the run-ptests in oe-core or meta-oe
call sleep so it would be setting a bad precedent.
+
+su tester -c "make check-TESTS top_srcdir=. srcdir=." | tee -a ${LOG}
+sleep 1
nix.
+deluser tester
+delgroup usergroup1
+
+passed=`grep PASS ${LOG}|wc -l`
+failed=`grep FAIL ${LOG}|wc -l`
+skipped=`grep -E SKIP ${LOG}|wc -l`
+all=$((passed + failed + skipped))
+
diff --git a/meta/recipes-core/coreutils/coreutils_8.31.bb
b/meta/recipes-core/coreutils/coreutils_8.31.bb
index 57b2c1bdba..c9c9df0cfa 100644
--- a/meta/recipes-core/coreutils/coreutils_8.31.bb
+++ b/meta/recipes-core/coreutils/coreutils_8.31.bb
@@ -143,3 +143,42 @@ python __anonymous() {
}
BBCLASSEXTEND = "native nativesdk"
+
+inherit ptest
+
+FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+
+SRC_URI += "file://run-ptest"
+RDEPENDS_${PN}-ptest += "bash gdb perl gawk strace perl-module-file-stat
libconvert-asn1-perl liberror-perl libmodule-build-perl libtimedate-perl liburi-perl"
+
+do_install_ptest () {
+ install -d ${D}${PTEST_PATH}/tests
+ cp -r ${S}/tests/* ${D}${PTEST_PATH}/tests
+ sed -i 's/ginstall/install/g' `grep -R ginstall
${D}${PTEST_PATH}/tests | awk -F: '{print $1}' | uniq`
+ install -d ${D}${PTEST_PATH}/build-aux
+ install ${S}/build-aux/test-driver ${D}${PTEST_PATH}/build-aux/
+ cp ${B}/Makefile ${D}${PTEST_PATH}/
+ cp ${S}/init.cfg ${D}${PTEST_PATH}/
+ cp -r ${B}/src ${D}${PTEST_PATH}/
+ cp -r ${S}/src/*.c ${D}${PTEST_PATH}/src
+ cd ${D}${PTEST_PATH}
+ tar -czvf ${D}${PTEST_PATH}/src.tar.gz ./src
+ cd -
+ rm -rf ${D}${PTEST_PATH}/src
+ sed -i '/^VPATH/s/= .*$/= ./g' ${D}${PTEST_PATH}/Makefile
+ sed -i '/^PROGRAMS/s/^/#/g' ${D}${PTEST_PATH}/Makefile
+ sed -i '/^Makefile: /s/^.*$/Makefile:/g' ${D}${PTEST_PATH}/Makefile
+ sed -i '/^abs_srcdir/s/= .*$/= \$\{PWD\}/g' ${D}${PTEST_PATH}/Makefile
+ sed -i '/^abs_top_builddir/s/= .*$/= \$\{PWD\}/g'
${D}${PTEST_PATH}/Makefile
+ sed -i '/^abs_top_srcdir/s/= .*$/= \$\{PWD\}/g'
${D}${PTEST_PATH}/Makefile
+ sed -i '/^built_programs/s/ginstall/install/g'
${D}${PTEST_PATH}/Makefile
+
+ # Disable subcase stty-pairs.sh, it will cause test framework hang
+ sed -i '/stty-pairs.sh/d' ${D}${PTEST_PATH}/Makefile
+ install ${B}/src/getlimits ${D}/${bindir}
+}
+
+FILES_${PN}-ptest += "${bindir}/getlimits"
+
+INSANE_SKIP_${PN}-ptest += "ldflags"
+INSANE_SKIP_${PN}-ptest += "rpaths"
I think it's a good start for ptests in coreutils.
--
# Randy MacLeod
# Wind River Linux
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC] [PATCH] Provide users with project support status
On Fri, Nov 01, 2019 at 07:46:38PM +0100, Ruslan Bilovol wrote: > When OE/Yocto project goes through its lifecycle, there > is no any way to identify where it is other than go > to a Yocto wiki and look at current status. The status in the wiki can be updated. > Moreover, change from maintained to community maintained > end EOLing happens silently so users not always know > about that. > > This patch aims to remove this gap. The status should > be changed so users can clearly identify at which point > it is now: > Development -> Stable -> Community supported -> End Of Life > > It is now printed during the build. >... What is printed is the status at the point in the (sometime distant) past when a release was made. It is not uncommon for hardware to come with an example BSP based on an older release like for example Yocto 2.0.3 (sic) today. The Yocto 2.0.3 release shipped as part of this distribution would never print "End Of Life". cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] ✗ patchtest: failure for Provide users with project support status
== Series Details == Series: Provide users with project support status Revision: 1 URL : https://patchwork.openembedded.org/series/20873/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on the proposed series by patchtest resulting in the following failures: * Patch[RFC] Provide users with project support status Issue Shortlog does not follow expected format [test_shortlog_format] Suggested fixCommit shortlog (first line of commit message) should follow the format ": " If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core@lists.openembedded.org) raising your concerns. Otherwise we would appreciate you correcting the issues and submitting a new version of the patchset if applicable. Please ensure you add/increment the version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> [PATCH v3] -> ...). --- Guidelines: https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [RFC] [PATCH] Provide users with project support status
When OE/Yocto project goes through its lifecycle, there
is no any way to identify where it is other than go
to a Yocto wiki and look at current status.
Moreover, change from maintained to community maintained
end EOLing happens silently so users not always know
about that.
This patch aims to remove this gap. The status should
be changed so users can clearly identify at which point
it is now:
Development -> Stable -> Community supported -> End Of Life
It is now printed during the build.
It will be also captured in the git history and
may be discussed over mailing lists during such a patch
reviews.
In the future this can be extended also to LTS when
we will have it
Signed-off-by: Ruslan Bilovol
---
meta/conf/bitbake.conf | 5 -
meta/conf/documentation.conf | 1 +
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 263d8aea4f..795dd3d5fb 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -6,6 +6,9 @@
# files may also need changes to keep in sync.
#
+# Project support level
+SUPPORT_LEVEL = "Development"
+
# Used by multilib code to change the library paths
baselib = "${BASELIB}"
baselib[vardepvalue] = "${baselib}"
@@ -701,7 +704,7 @@ PREFERRED_PROVIDER_virtual/fakeroot-native ?=
"pseudo-native"
# Pre-build configuration output
BUILDCFG_HEADER = "Build Configuration:"
-BUILDCFG_VARS = "BB_VERSION BUILD_SYS NATIVELSBSTRING TARGET_SYS MACHINE
DISTRO DISTRO_VERSION TUNE_FEATURES TARGET_FPU"
+BUILDCFG_VARS = "SUPPORT_LEVEL BB_VERSION BUILD_SYS NATIVELSBSTRING TARGET_SYS
MACHINE DISTRO DISTRO_VERSION TUNE_FEATURES TARGET_FPU"
BUILDCFG_VARS[type] = "list"
BUILDCFG_NEEDEDVARS = "TARGET_ARCH TARGET_OS"
BUILDCFG_NEEDEDVARS[type] = "list"
diff --git a/meta/conf/documentation.conf b/meta/conf/documentation.conf
index 550df20b0f..3efef4b18b 100644
--- a/meta/conf/documentation.conf
+++ b/meta/conf/documentation.conf
@@ -392,6 +392,7 @@ STAGING_KERNEL_DIR[doc] = "The directory with kernel
headers that are required t
STAMP[doc] = "Specifies the base path used to create recipe stamp files. The
path to an actual stamp file is constructed by evaluating this string and then
appending additional information."
STAMPS_DIR[doc] = "Specifies the base directory in which the OpenEmbedded
build system places stamps."
SUMMARY[doc] = "The short (80 characters or less) summary of the binary
package for packaging systems such as opkg, rpm or dpkg. By default, SUMMARY is
used to define the DESCRIPTION variable if DESCRIPTION is not set in the
recipe."
+SUPPORT_LEVEL[doc] = "Specifies the project support level which can be one of
'Development', 'Stable', 'Community supported' or 'End Of Life'."
SVNDIR[doc] = "The directory where Subversion checkouts will be stored."
SYSLINUX_DEFAULT_CONSOLE[doc] = "Specifies the kernel boot default console."
SYSLINUX_OPTS[doc] = "Lists additional options to add to the syslinux file."
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [RFC 0/1] ptest additions for coreutils
From: Trevor Gamblin coreutils has a large number of tests, and potential RDEPENDS to be added to support them, along with the flags RUN_EXPENSIVE_TESTS and RUN_VERY_EXPENSIVE_TESTS that will add time and coverage. The RUN_VERY_EXPENSIVE_TESTS=yes flag has been omitted from the run-ptest script to reduce run time and issues with timeouts on qemuarm64, even though this increases an already high SKIP count in the results. Similarly, adding valgrind to RDEPENDS will allow additional tests to pass, but this hasn't been included. Of the tests marked SKIP, there are 30 tests that are currently counted as SKIP because they require sudo permissions, and another 21 that require membership in multiple groups. Additionally, there is an issue with the "make check-TESTS" call finishing clearly during the ptest. Despite these issues, upstream input was desired before doing further development on the ptest additions. Signed-off-by: Trevor Gamblin Trevor Gamblin (1): coreutils: add ptest .../coreutils/coreutils/run-ptest | 22 +++ meta/recipes-core/coreutils/coreutils_8.31.bb | 39 +++ 2 files changed, 61 insertions(+) create mode 100755 meta/recipes-core/coreutils/coreutils/run-ptest -- 2.21.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [RFC 1/1] coreutils: add ptest
From: Trevor Gamblin
Signed-off-by: Trevor Gamblin
---
.../coreutils/coreutils/run-ptest | 21 ++
meta/recipes-core/coreutils/coreutils_8.31.bb | 39 +++
2 files changed, 60 insertions(+)
create mode 100755 meta/recipes-core/coreutils/coreutils/run-ptest
diff --git a/meta/recipes-core/coreutils/coreutils/run-ptest
b/meta/recipes-core/coreutils/coreutils/run-ptest
new file mode 100755
index 00..07f34a8d3e
--- /dev/null
+++ b/meta/recipes-core/coreutils/coreutils/run-ptest
@@ -0,0 +1,21 @@
+#!/bin/bash
+
+COREUTILSLIB=/usr/lib/coreutils
+LOG="${COREUTILSLIB}/ptest/coreutils_ptest_$(date +%Y%m%d-%H%M%S).log"
+
+addgroup usergroup1
+sleep 1
+adduser --ingroup usergroup1 tester
+chmod -R 777 ../ptest
+sleep 2
+
+su tester -c "make check-TESTS top_srcdir=. srcdir=." | tee -a ${LOG}
+sleep 1
+deluser tester
+delgroup usergroup1
+
+passed=`grep PASS ${LOG}|wc -l`
+failed=`grep FAIL ${LOG}|wc -l`
+skipped=`grep -E SKIP ${LOG}|wc -l`
+all=$((passed + failed + skipped))
+
diff --git a/meta/recipes-core/coreutils/coreutils_8.31.bb
b/meta/recipes-core/coreutils/coreutils_8.31.bb
index 57b2c1bdba..c9c9df0cfa 100644
--- a/meta/recipes-core/coreutils/coreutils_8.31.bb
+++ b/meta/recipes-core/coreutils/coreutils_8.31.bb
@@ -143,3 +143,42 @@ python __anonymous() {
}
BBCLASSEXTEND = "native nativesdk"
+
+inherit ptest
+
+FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+
+SRC_URI += "file://run-ptest"
+RDEPENDS_${PN}-ptest += "bash gdb perl gawk strace perl-module-file-stat
libconvert-asn1-perl liberror-perl libmodule-build-perl libtimedate-perl
liburi-perl"
+
+do_install_ptest () {
+ install -d ${D}${PTEST_PATH}/tests
+ cp -r ${S}/tests/* ${D}${PTEST_PATH}/tests
+ sed -i 's/ginstall/install/g' `grep -R ginstall
${D}${PTEST_PATH}/tests | awk -F: '{print $1}' | uniq`
+ install -d ${D}${PTEST_PATH}/build-aux
+ install ${S}/build-aux/test-driver ${D}${PTEST_PATH}/build-aux/
+ cp ${B}/Makefile ${D}${PTEST_PATH}/
+ cp ${S}/init.cfg ${D}${PTEST_PATH}/
+ cp -r ${B}/src ${D}${PTEST_PATH}/
+ cp -r ${S}/src/*.c ${D}${PTEST_PATH}/src
+ cd ${D}${PTEST_PATH}
+ tar -czvf ${D}${PTEST_PATH}/src.tar.gz ./src
+ cd -
+ rm -rf ${D}${PTEST_PATH}/src
+ sed -i '/^VPATH/s/= .*$/= ./g' ${D}${PTEST_PATH}/Makefile
+ sed -i '/^PROGRAMS/s/^/#/g' ${D}${PTEST_PATH}/Makefile
+ sed -i '/^Makefile: /s/^.*$/Makefile:/g' ${D}${PTEST_PATH}/Makefile
+ sed -i '/^abs_srcdir/s/= .*$/= \$\{PWD\}/g' ${D}${PTEST_PATH}/Makefile
+ sed -i '/^abs_top_builddir/s/= .*$/= \$\{PWD\}/g'
${D}${PTEST_PATH}/Makefile
+ sed -i '/^abs_top_srcdir/s/= .*$/= \$\{PWD\}/g'
${D}${PTEST_PATH}/Makefile
+ sed -i '/^built_programs/s/ginstall/install/g'
${D}${PTEST_PATH}/Makefile
+
+ # Disable subcase stty-pairs.sh, it will cause test framework hang
+ sed -i '/stty-pairs.sh/d' ${D}${PTEST_PATH}/Makefile
+ install ${B}/src/getlimits ${D}/${bindir}
+}
+
+FILES_${PN}-ptest += "${bindir}/getlimits"
+
+INSANE_SKIP_${PN}-ptest += "ldflags"
+INSANE_SKIP_${PN}-ptest += "rpaths"
--
2.21.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [warrior 18/19] go: fix CVE-2019-16276
On Fri, Nov 1, 2019 at 7:12 PM Martin Jansa wrote: > > I've reported the same yesterday: > http://lists.openembedded.org/pipermail/openembedded-core/2019-October/288638.html > > and sent upgrade to match the minor version used in warrior to the one in > zeus (which resolves the patch to apply cleanly): > http://lists.openembedded.org/pipermail/openembedded-core/2019-October/288656.html I've actually just found your upgrade patches from yesterday, and they should solve the issue. I guess it was just the fact that upgrade to 1.12.9 didn't make it to warrior yet - I've ended up with the state where I had 1.12.1 in warrior for recipe, and patch from 1.12.9. Once your patches would land in warrior repo - this hunk would be resolved, since the patch is actually made for 1.12.9 and that is why there are no complaints from master now. > > I don't use go for anything, but go 1.11 was also updated in thud: > http://lists.openembedded.org/pipermail/openembedded-core/2019-October/287724.html > so I was assuming that this minor upgrade in 1.12 should be safe enough for > warrior as well. > > Regards, > > On Fri, Nov 1, 2019 at 6:40 PM Khem Raj wrote: >> >> On Fri, Nov 1, 2019 at 10:33 AM Andrey Zhizhikin wrote: >> > >> > Hello Armin, >> > >> > On Tue, Oct 29, 2019 at 10:50 AM Armin Kuster wrote: >> > > >> > > From: Chen Qi >> > > >> > > Signed-off-by: Chen Qi >> > > Signed-off-by: Richard Purdie >> > > (cherry picked from commit e31f87e289dfd3bbca961e927447a9c7ba816d3f) >> > > Signed-off-by: Armin Kuster >> > > (cherry picked from commit e02e8fa2e82cceaaa6a433466f52f97b0984762a) >> > > Signed-off-by: Armin Kuster >> > > --- >> > >> > This patch didn't apply clean on warrior, but same patch on master >> > seems to be OK. I got a hunk in transport_test.go which has been >> > resolved by build, but since this is security-related patch I wanted >> > to bring some attention here. >> > >> >> if its failing in testcase as a last report we can drop that if that >> hunk is not backportable. >> > > >> > > -- >> > > ___ >> > > Openembedded-core mailing list >> > > Openembedded-core@lists.openembedded.org >> > > http://lists.openembedded.org/mailman/listinfo/openembedded-core >> > >> > -- >> > Regards, >> > Andrey. >> > -- >> > ___ >> > 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 -- Regards, Andrey. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [warrior 18/19] go: fix CVE-2019-16276
I've reported the same yesterday: http://lists.openembedded.org/pipermail/openembedded-core/2019-October/288638.html and sent upgrade to match the minor version used in warrior to the one in zeus (which resolves the patch to apply cleanly): http://lists.openembedded.org/pipermail/openembedded-core/2019-October/288656.html I don't use go for anything, but go 1.11 was also updated in thud: http://lists.openembedded.org/pipermail/openembedded-core/2019-October/287724.html so I was assuming that this minor upgrade in 1.12 should be safe enough for warrior as well. Regards, On Fri, Nov 1, 2019 at 6:40 PM Khem Raj wrote: > On Fri, Nov 1, 2019 at 10:33 AM Andrey Zhizhikin > wrote: > > > > Hello Armin, > > > > On Tue, Oct 29, 2019 at 10:50 AM Armin Kuster > wrote: > > > > > > From: Chen Qi > > > > > > Signed-off-by: Chen Qi > > > Signed-off-by: Richard Purdie > > > (cherry picked from commit e31f87e289dfd3bbca961e927447a9c7ba816d3f) > > > Signed-off-by: Armin Kuster > > > (cherry picked from commit e02e8fa2e82cceaaa6a433466f52f97b0984762a) > > > Signed-off-by: Armin Kuster > > > --- > > > > This patch didn't apply clean on warrior, but same patch on master > > seems to be OK. I got a hunk in transport_test.go which has been > > resolved by build, but since this is security-related patch I wanted > > to bring some attention here. > > > > if its failing in testcase as a last report we can drop that if that > hunk is not backportable. > > > > > > -- > > > ___ > > > Openembedded-core mailing list > > > Openembedded-core@lists.openembedded.org > > > http://lists.openembedded.org/mailman/listinfo/openembedded-core > > > > -- > > Regards, > > Andrey. > > -- > > ___ > > 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 > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/6] oe-selftest: extend virgl gtk test to also check the SDL option
Same failures on the Debian 10 worker: https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/778 Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [warrior 18/19] go: fix CVE-2019-16276
On Fri, Nov 1, 2019 at 10:33 AM Andrey Zhizhikin wrote: > > Hello Armin, > > On Tue, Oct 29, 2019 at 10:50 AM Armin Kuster wrote: > > > > From: Chen Qi > > > > Signed-off-by: Chen Qi > > Signed-off-by: Richard Purdie > > (cherry picked from commit e31f87e289dfd3bbca961e927447a9c7ba816d3f) > > Signed-off-by: Armin Kuster > > (cherry picked from commit e02e8fa2e82cceaaa6a433466f52f97b0984762a) > > Signed-off-by: Armin Kuster > > --- > > This patch didn't apply clean on warrior, but same patch on master > seems to be OK. I got a hunk in transport_test.go which has been > resolved by build, but since this is security-related patch I wanted > to bring some attention here. > if its failing in testcase as a last report we can drop that if that hunk is not backportable. > > > > -- > > ___ > > Openembedded-core mailing list > > Openembedded-core@lists.openembedded.org > > http://lists.openembedded.org/mailman/listinfo/openembedded-core > > -- > Regards, > Andrey. > -- > ___ > 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] [warrior 18/19] go: fix CVE-2019-16276
Hello Armin, On Tue, Oct 29, 2019 at 10:50 AM Armin Kuster wrote: > > From: Chen Qi > > Signed-off-by: Chen Qi > Signed-off-by: Richard Purdie > (cherry picked from commit e31f87e289dfd3bbca961e927447a9c7ba816d3f) > Signed-off-by: Armin Kuster > (cherry picked from commit e02e8fa2e82cceaaa6a433466f52f97b0984762a) > Signed-off-by: Armin Kuster > --- This patch didn't apply clean on warrior, but same patch on master seems to be OK. I got a hunk in transport_test.go which has been resolved by build, but since this is security-related patch I wanted to bring some attention here. > > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- Regards, Andrey. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] conf/image-uefi: fix building images for multilib case
From: Dmitry Eremin-Solenikov
Building live images for lib32-core-minimal-image will fail because
image target override won't match grub's override. Fix this by
introducing anonymous python function. A proper fix should be to
introduce multilib overrides, but it will be more intrusive.
Signed-off-by: Dmitry Eremin-Solenikov
---
meta/conf/image-uefi.conf | 11 +--
meta/conf/image-uefi.inc | 23 +++
2 files changed, 28 insertions(+), 6 deletions(-)
create mode 100644 meta/conf/image-uefi.inc
diff --git a/meta/conf/image-uefi.conf b/meta/conf/image-uefi.conf
index aaeff12ccb80..57fd18f02742 100644
--- a/meta/conf/image-uefi.conf
+++ b/meta/conf/image-uefi.conf
@@ -8,9 +8,8 @@ EFI_PREFIX ?= "/boot"
# Location inside rootfs.
EFI_FILES_PATH = "${EFI_PREFIX}${EFIDIR}"
-# Determine name of bootloader image
-EFI_BOOT_IMAGE ?= "bootINVALID.efi"
-EFI_BOOT_IMAGE_x86-64 = "bootx64.efi"
-EFI_BOOT_IMAGE_x86 = "bootia32.efi"
-EFI_BOOT_IMAGE_aarch64 = "bootaa64.efi"
-EFI_BOOT_IMAGE_arm = "bootarm.efi"
+# Parsing python anonymous functions in .conf files does not work, so move it
+# to .inc file
+require conf/image-uefi.inc
+
+EFI_BOOT_IMAGE ?= "boot${EFI_ARCH}.efi"
diff --git a/meta/conf/image-uefi.inc b/meta/conf/image-uefi.inc
new file mode 100644
index ..94c5813494cb
--- /dev/null
+++ b/meta/conf/image-uefi.inc
@@ -0,0 +1,23 @@
+# Determine name of bootloader image
+python () {
+import re
+if d.getVar("MLPREFIX") != "":
+target = d.getVar("TARGET_ARCH_MULTILIB_ORIGINAL")
+else:
+target = d.getVar("TARGET_ARCH")
+
+if target == "x86_64":
+arch = "x64"
+elif re.match('i.86', target):
+arch = "ia32"
+elif re.match('aarch64', target):
+arch = "aa64"
+elif re.match('arm', target):
+arch = "arm"
+else:
+raise bb.parse.SkipRecipe("image-uefi is incompatible with target %s"
% target)
+
+d.setVar("EFI_ARCH", arch)
+}
+
+
--
2.23.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] multilib.conf: add systemd-boot to non-multilib recipes list
From: Dmitry Eremin-Solenikov
Add systemd-boot to NON_MULTILIB_RECIPES so that it won't be built for multilib
targets.
Signed-off-by: Dmitry Eremin-Solenikov
---
meta/conf/multilib.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/conf/multilib.conf b/meta/conf/multilib.conf
index cfed3fbbd07f..c734a121e12d 100644
--- a/meta/conf/multilib.conf
+++ b/meta/conf/multilib.conf
@@ -29,4 +29,4 @@ PKG_CONFIG_PATH[vardepvalueexclude] =
":${WORKDIR}/recipe-sysroot/${datadir}/pkg
# These recipes don't need multilib variants, the ${BPN} PROVDES/RPROVDES
# ${MLPREFIX}${BPN}
-NON_MULTILIB_RECIPES = "grub grub-efi make-mod-scripts ovmf"
+NON_MULTILIB_RECIPES = "grub grub-efi systemd-boot make-mod-scripts ovmf"
--
2.23.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/2] fix multilib issues with UEFI bootloaders
Last UEFI patchset that went in broke building not-native multilib images (like lib32-core-image-minimal). Fix this issue by listing systemd-boot as non-multilib recipe and by fixing UEFI app naming in multilib cases. -- With best wishes Dmitry -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libksba: Fix license specification
The tools (e.g. build system, tests) & manual are licensed as GPLv3+ and
the library itself is GPLv2+ | LGPLv3+.
This is documented in libksba/AUTHORS:
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libksba.git;a=blob;f=AUTHORS;h=c161951281f2a432ad0ff112111f70a83e1d93fa;hb=3df0cd32e3b21b7da96a93d1f84d6cb6a77b89be
Signed-off-by: Alexander Hirsch
---
On the side, while looking where/how to send a patch I looked at this page:
https://www.yoctoproject.org/community/
The link "Submit A Patch" links to the style-guide instead of the
"How to submit a patch"-Page on the Wiki. Is this intended?
meta/recipes-support/libksba/libksba_1.3.5.bb | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-support/libksba/libksba_1.3.5.bb
b/meta/recipes-support/libksba/libksba_1.3.5.bb
index a7ea53f..4deda18 100644
--- a/meta/recipes-support/libksba/libksba_1.3.5.bb
+++ b/meta/recipes-support/libksba/libksba_1.3.5.bb
@@ -1,6 +1,8 @@
SUMMARY = "Easy API to create and parse X.509 and CMS related objects"
HOMEPAGE = "http://www.gnupg.org/related_software/libksba/;
-LICENSE = "GPLv2+ | LGPLv3+ | GPLv3+"
+LICENSE = "GPLv3+ & (GPLv2+ | LGPLv3+)"
+LICENSE_${PN} = "GPLv2+ | LGPLv3+"
+LICENSE_${PN}-doc = "GPLv3+"
LIC_FILES_CHKSUM = "file://COPYING;md5=fd541d83f75d038c4e0617b672ed8bda \
file://COPYING.GPLv2;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
file://COPYING.GPLv3;md5=2f31b266d3440dd7ee50f92cf67d8e6c \
--
2.7.4
--
G.i.N. Gesellschaft f�r industrielle Netzwerke GmbH
Raiffeisenstr. 15
D-64347 Griesheim
Telefon: +49 6155 - 8259 - 0
Telefax: +49 6155 - 8259 - 11
E-Mail: alexander.hir...@gin.de
Internet: www.gin.de
Sitz: Griesheim
Registergericht: Amtsgericht Darmstadt, HRB 5068
Gerichtsstand: Darmstadt
USt.-ID-Nr. DE 111633284
WEEE-Reg.-Nr. DE 20824942
Gesch�ftsf�hrer:
Dipl.-Inform. Andreas Schoenberg
Dipl.-Ing. (FH) Kay Wuttke
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] archiver: avoid empty incfile in ar_recipe
Hi,
On 01/11/2019 07:10, grygorii tertychnyi via Openembedded-core wrote:
> do_ar_recipe fails on perf recipe on line:
>
> include ${@bb.utils.contains('PACKAGECONFIG', 'scripting', 'perf-perl.inc',
> '', d)}
>
> 1. "${...}" part expands into empty string
> 2. bb.utils.which() takes empty string and returns first directory name from
> bbpath
This doesn't sound sane. If the include directive has no argument,
incfile should end up None. That's what the code "assumes" at this
point. I would fix it either at the regex expression level or
stripping the matched string. I reckon the former makes more sense
(.*).
--
Andrei Gherzan
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] linux-dummy: Add package kernel
On Thu, Oct 31, 2019 at 10:01 PM He Zhe wrote:
>
>
>
> On 10/31/19 6:57 PM, Bruce Ashfield wrote:
> > On Thu, Oct 31, 2019 at 6:20 AM wrote:
> >> From: He Zhe
> >>
> >> Some package like packagegroup-core-boot may ask for package kernel. Let
> >> linux-dummy rprovide package kernel to fix the following build failure.
> >>
> >> ERROR: Nothing RPROVIDES 'kernel' (but
> >> .../meta/recipes-core/packagegroups/packagegroup-core-boot.bb RDEPENDS on
> >> or
> >> otherwise requires it)
> > Can you expand on what the higher level use case is that something is
> > using packagegroup-core-boot (or whatever), but also linux-dummy ?
> >
> > It seems like this is going to hide misconfigurations .. since you may
> > want something bootable, but yet are not properly configured.
> >
> > If there's part of that packagroup you need, why not split it up,
> > rather than masking the symptom seen here ?
>
> It's the "efi" in MACHINE_FEATURES who asks for "kernel".
> https://git.openembedded.org/openembedded-core/tree/meta/recipes-core/packagegroups/packagegroup-core-boot.bb#n31
>
Right. But the question is, why is the image that is being built
trying to install packagegroup-core boot when it has linux-dummy as
the kernel ? It's basically a misconfiguration, and I'm trying to
understand the details.
If this was provided by linux-dummy, I'd think that we'd at least want
a bbwarning to let the user know that they've asked for something
bootable, but will not end up with something that can boot.
> I thought the user would take care of the kernel himself, so simply added it
> to
> linux-dummy. I'm not quite sure what you mean by "split it up".
Meaning, make that part of the packagegroup into a new/separate
packagegroup that could be conditionally included by a variable (and
that way the configuration you are talking about could still depend on
packagegroup-core-boot, and not get the kernel dependency ... hence no
need for linux-dummy to provide it at all). Or alternately, just have
that entry in the package group be a variable, that another layer can
bbappend and clear (and again, remove the dependency).
i.e. if this (packagroup-core-boot) is being pulled in by something
like a container image build, there are already variables that control
the kernel dependency and other ways to avoid it.
Bruce
>
> Regards,
> Zhe
>
> >
> > Bruce
> >
> >> Signed-off-by: He Zhe
> >> ---
> >> meta/recipes-kernel/linux/linux-dummy.bb | 7 +--
> >> 1 file changed, 5 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/meta/recipes-kernel/linux/linux-dummy.bb
> >> b/meta/recipes-kernel/linux/linux-dummy.bb
> >> index 62cf6f5ea6..20d7ed815d 100644
> >> --- a/meta/recipes-kernel/linux/linux-dummy.bb
> >> +++ b/meta/recipes-kernel/linux/linux-dummy.bb
> >> @@ -8,19 +8,22 @@ LICENSE = "GPLv2"
> >> LIC_FILES_CHKSUM =
> >> "file://${WORKDIR}/COPYING.GPL;md5=751419260aa954499f7abaabaa882bbe"
> >>
> >> PROVIDES += "virtual/kernel"
> >> +RPROVIDES_${PN} += "kernel lib32-kernel"
> >>
> >> PACKAGES_DYNAMIC += "^kernel-module-.*"
> >> PACKAGES_DYNAMIC += "^kernel-image-.*"
> >> PACKAGES_DYNAMIC += "^kernel-firmware-.*"
> >>
> >> -PACKAGES += "kernel-modules kernel-vmlinux"
> >> +PACKAGES += "kernel-modules kernel-vmlinux kernel"
> >> FILES_kernel-modules = ""
> >> ALLOW_EMPTY_kernel-modules = "1"
> >> DESCRIPTION_kernel-modules = "Kernel modules meta package"
> >> FILES_kernel-vmlinux = ""
> >> ALLOW_EMPTY_kernel-vmlinux = "1"
> >> DESCRIPTION_kernel-vmlinux = "Kernel vmlinux meta package"
> >> -
> >> +FILES_kernel = ""
> >> +ALLOW_EMPTY_kernel = "1"
> >> +DESCRIPTION_kernel = "Kernel meta package"
> >>
> >> INHIBIT_DEFAULT_DEPS = "1"
> >>
> >> --
> >> 2.17.1
> >>
> >> --
> >> ___
> >> Openembedded-core mailing list
> >> Openembedded-core@lists.openembedded.org
> >> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >
> >
>
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] archiver: avoid empty incfile in ar_recipe
Hi,
On 01/11/2019 07:10, grygorii tertychnyi via Openembedded-core wrote:
do_ar_recipe fails on perf recipe on line:
include ${@bb.utils.contains('PACKAGECONFIG', 'scripting', 'perf-perl.inc', '',
d)}
1. "${...}" part expands into empty string
2. bb.utils.which() takes empty string and returns first directory name from
bbpath
This doesn't sound sane. If the include directive has no argument,
incfile should end up None. That's what the code "assumes" at this
point. I would fix it either at the regex expression level or strip the
match. I reckon former would make more sense. It sounds like the match
expression should use * (none or more).
3. shutil.copy() fails on copying directory:
Exception: IsADirectoryError: [Errno 21] Is a directory: ..
Hence, check "incfile" variable on each step.
Signed-off-by: grygorii tertychnyi
---
meta/classes/archiver.bbclass | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/meta/classes/archiver.bbclass b/meta/classes/archiver.bbclass
index 093e2d95af..7c46cff91f 100644
--- a/meta/classes/archiver.bbclass
+++ b/meta/classes/archiver.bbclass
@@ -441,9 +441,10 @@ python do_ar_recipe () {
incfile = include_re.match(line).group(1)
if incfile:
incfile = d.expand(incfile)
+if incfile:
incfile = bb.utils.which(bbpath, incfile)
-if incfile:
-shutil.copy(incfile, outdir)
+if incfile:
+shutil.copy(incfile, outdir)
create_tarball(d, outdir, 'recipe', d.getVar('ARCHIVER_OUTDIR'))
bb.utils.remove(outdir, recurse=True)
--
Andrei Gherzan
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] archiver: avoid empty incfile in ar_recipe
do_ar_recipe fails on perf recipe on line:
include ${@bb.utils.contains('PACKAGECONFIG', 'scripting', 'perf-perl.inc', '',
d)}
1. "${...}" part expands into empty string
2. bb.utils.which() takes empty string and returns first directory name from
bbpath
3. shutil.copy() fails on copying directory:
Exception: IsADirectoryError: [Errno 21] Is a directory: ..
Hence, check "incfile" variable on each step.
Signed-off-by: grygorii tertychnyi
---
meta/classes/archiver.bbclass | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/meta/classes/archiver.bbclass b/meta/classes/archiver.bbclass
index 093e2d95af..7c46cff91f 100644
--- a/meta/classes/archiver.bbclass
+++ b/meta/classes/archiver.bbclass
@@ -441,9 +441,10 @@ python do_ar_recipe () {
incfile = include_re.match(line).group(1)
if incfile:
incfile = d.expand(incfile)
+if incfile:
incfile = bb.utils.which(bbpath, incfile)
-if incfile:
-shutil.copy(incfile, outdir)
+if incfile:
+shutil.copy(incfile, outdir)
create_tarball(d, outdir, 'recipe', d.getVar('ARCHIVER_OUTDIR'))
bb.utils.remove(outdir, recurse=True)
--
2.23.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] scripts/oe-pkgdata-util: Enable list-pkgs to print ordered packages
The list-pkgs currently print packages in unordered format.
Enable list-pkgs to print ordered packages that will ease
viewing.
Signed-off-by: Yeoh Ee Peng
---
scripts/oe-pkgdata-util | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/scripts/oe-pkgdata-util b/scripts/oe-pkgdata-util
index 9cc78d1..93220e3 100755
--- a/scripts/oe-pkgdata-util
+++ b/scripts/oe-pkgdata-util
@@ -389,21 +389,16 @@ def list_pkgs(args):
return False
return True
+pkglist = []
if args.recipe:
packages = get_recipe_pkgs(args.pkgdata_dir, args.recipe,
args.unpackaged)
if args.runtime:
-pkglist = []
runtime_pkgs = lookup_pkglist(packages, args.pkgdata_dir, False)
for rtpkgs in runtime_pkgs.values():
pkglist.extend(rtpkgs)
else:
pkglist = packages
-
-for pkg in pkglist:
-if matchpkg(pkg):
-found = True
-print("%s" % pkg)
else:
if args.runtime:
searchdir = 'runtime-reverse'
@@ -414,9 +409,13 @@ def list_pkgs(args):
for fn in files:
if fn.endswith('.packaged'):
continue
-if matchpkg(fn):
-found = True
-print("%s" % fn)
+pkglist.append(fn)
+
+for pkg in sorted(pkglist):
+if matchpkg(pkg):
+found = True
+print("%s" % pkg)
+
if not found:
if args.pkgspec:
logger.error("Unable to find any package matching %s" %
args.pkgspec)
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
