Re: [OE-core] [PATCH v2] image_types: add Zstandard conversion support
On Wed, 2019-11-06 at 13:43 +, Stefan Agner wrote:
> From: Stefan Agner
>
> Add Zstandard (or just Zstd) compression support. This allows to
> create Zstd compressed tarballs by using tar.zst as IMAGE_FSTYPES.
>
> Signed-off-by: Stefan Agner
> ---
> meta/classes/image_types.bbclass | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/meta/classes/image_types.bbclass
> b/meta/classes/image_types.bbclass
> index 2eeffbb366..d29b9c5787 100644
> --- a/meta/classes/image_types.bbclass
> +++ b/meta/classes/image_types.bbclass
> @@ -59,6 +59,8 @@ XZ_INTEGRITY_CHECK ?= "crc32"
>
> ZIP_COMPRESSION_LEVEL ?= "-9"
>
> +ZSTD_COMPRESSION_LEVEL ?= "-3"
> +
> JFFS2_SUM_EXTRA_ARGS ?= ""
> IMAGE_CMD_jffs2 = "mkfs.jffs2 --root=${IMAGE_ROOTFS} --faketime
> --output=${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.jffs2
> ${EXTRA_IMAGECMD}"
>
> @@ -269,7 +271,7 @@ IMAGE_TYPES = " \
> hddimg \
> squashfs squashfs-xz squashfs-lzo squashfs-lz4 \
> ubi ubifs multiubi \
> -tar tar.gz tar.bz2 tar.xz tar.lz4 \
> +tar tar.gz tar.bz2 tar.xz tar.lz4 tar.zst \
> cpio cpio.gz cpio.xz cpio.lzma cpio.lz4 \
> wic wic.gz wic.bz2 wic.lzma \
> container \
> @@ -282,7 +284,7 @@ IMAGE_TYPES = " \
> # CONVERSION_CMD/DEPENDS.
> COMPRESSIONTYPES ?= ""
>
> -CONVERSIONTYPES = "gz bz2 lzma xz lz4 lzo zip sum md5sum sha1sum sha224sum
> sha256sum sha384sum sha512sum bmap u-boot vmdk vdi qcow2 base64
> ${COMPRESSIONTYPES}"
> +CONVERSIONTYPES = "gz bz2 lzma xz lz4 lzo zip zst sum md5sum sha1sum
> sha224sum sha256sum sha384sum sha512sum bmap u-boot vmdk vdi qcow2 base64
> ${COMPRESSIONTYPES}"
> CONVERSION_CMD_lzma = "lzma -k -f -7
> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
> CONVERSION_CMD_gz = "gzip -f -9 -n -c --rsyncable
> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.gz"
> CONVERSION_CMD_bz2 = "pbzip2 -f -k ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
> @@ -290,6 +292,7 @@ CONVERSION_CMD_xz = "xz -f -k -c ${XZ_COMPRESSION_LEVEL}
> ${XZ_DEFAULTS} --check=
> CONVERSION_CMD_lz4 = "lz4 -9 -z -l ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}
> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.lz4"
> CONVERSION_CMD_lzo = "lzop -9 ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
> CONVERSION_CMD_zip = "zip ${ZIP_COMPRESSION_LEVEL}
> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.zip
> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
> +CONVERSION_CMD_zst = "zstd -f -k -c ${ZSTD_COMPRESSION_LEVEL}
> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.zst"
> CONVERSION_CMD_sum = "sumtool -i ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}
> -o ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.sum ${JFFS2_SUM_EXTRA_ARGS}"
> CONVERSION_CMD_md5sum = "md5sum ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.md5sum"
> CONVERSION_CMD_sha1sum = "sha1sum ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}
> > ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.sha1sum"
> @@ -310,6 +313,7 @@ CONVERSION_DEPENDS_xz = "xz-native"
> CONVERSION_DEPENDS_lz4 = "lz4-native"
> CONVERSION_DEPENDS_lzo = "lzop-native"
> CONVERSION_DEPENDS_zip = "zip-native"
> +CONVERSION_DEPENDS_zst = "zstd-native"
> CONVERSION_DEPENDS_sum = "mtd-utils-native"
> CONVERSION_DEPENDS_bmap = "bmap-tools-native"
> CONVERSION_DEPENDS_u-boot = "u-boot-tools-native"
I was ok with this despite not having zstd-native in OE-Core however
our automated testing is cleverer than I remembered:
https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/467
so we may need to skip this option in the test...
(oe-selftest -r imagefeatures.ImageFeatures.test_image_fstypes should
reproduce)
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] maintaining sumo (was Re: [PATCH][thud] cve-check: backport rewrite from master)
Hi, On Wed, Nov 06, 2019 at 05:53:27PM +, Richard Purdie wrote: > On Wed, 2019-11-06 at 16:06 +, mikko.rap...@bmw.de wrote: > > Hi, > > > > On Wed, Nov 06, 2019 at 02:59:16PM +, Ryan Harkin wrote: > > > Hi Ross/Richard, > > > > > > I'd like this applied to Sumo also. Should I create a new patch and > > > send it > > > to the list, or is there a process for requesting this is cherry- > > > picked > > > across? > > > > I just posted the port of this and all other CVE scan related changes > > to sumo > > http://lists.openembedded.org/pipermail/openembedded-core/2019-November/288817.html > > > > But the question is valid :) > > Support for sumo officially ended. I can see a case that the broken CVE > tools there are a good reason we could consider merging the patch > series but we do need to be able to test it to merge it to the main > branch. If we can't test, we're merging blind and the quality the > project tries to deliver could be compromised. > > I have made some tweaks to the autobuilder which bring us closer to > being able to test sumo using the workers still around from that > release. > > The things that make me nervous are questions like: > > Which releases do we "open" for such patches? How far back do we go? > Which kinds of patches are acceptable? > > Note that sumo (and earlier) doesn't have much of the QA automation > which we've now built our processes around so we don't get test > reports. > > You mention wanting to change gcc. That means we really do need a full > retest of it to merge that (which is why it never happened originally > from what I remember). > > Also, the LTS proposal stated we needed someone to handle this work. We > have no such person, even if we do somehow find them, they can't be > expected to cover all the old releases and effectively turn all of them > into LTS releases. How can we get the funding to try and get some help > with handling this workload? > > I am probably going to try and make a case for sorting the CVE tooling > on sumo as I agree its bad and we should do something. Where do we draw > the line though. > > Basically, this looks like it could create a lot of extra work without > helping the core project under-resourcing we currently struggle with. > You can therefore see why I might be nervous :/. All this is understood. I need to maintain sumo in a project for a while longer so I can publish that work. The CVE checker patches are just a start. Providing funding for Yocto Project LTS work is possible but a lot harder for me to do. Testing and publishing patches is much easier. Could you clarify Yocto Project side answers to these questions: If I continue to publish patches for sumo, can I continue doing so on oe-core mailing list? If I continue to collect patches for sumo, can I do so using Yocto Project infrastructure, e.g. a sumo-contrib-lts or similar branch in poky git tree? If I continue to test patches, what would be the patch acceptance criteria and required testing? I would assume same as stable release rules, but maybe these need to be even stricter, e.g. only support building on Debian stable, following the LTS proposal. I'm testing in my own project trees and CI with target HW, and doing world builds on pure poky with qemu target. I could some kind of ptest execution to plain poky as well. Would any testing of patches be possible in Yocto Project infrastructure? All of these things I can do also completely outside of Yocto Project, e.g. publish a sumo git tree on github, and rely only on my own testing. But I'd like to see some co-operation here from other users who are stuck with sumo. -Mikko -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH][zeus][master] harfbuzz: split libharfbuzz-subset.so to its own binary package
harfbuzz binary package size increased from 624608 bytes in yocto 2.5 to
1365431 bytes in yocto 3.0. Most of the size increase is in the new
libharfbuzz-subset.so* library, which based on the name seems to
duplicate parts of the libharfbuzz main library, though it
RDEPENDS on harfbuzz which is odd. Split it to its own binary
package which will be installed if anyone needs it. Effect to harfbuzz
binary package size is:
-PKGSIZE = 1476271
+PKGSIZE = 1007424
Signed-off-by: Mikko Rapeli
---
meta/recipes-graphics/harfbuzz/harfbuzz_2.6.1.bb | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-graphics/harfbuzz/harfbuzz_2.6.1.bb
b/meta/recipes-graphics/harfbuzz/harfbuzz_2.6.1.bb
index 99cd4cd..80ab545 100644
--- a/meta/recipes-graphics/harfbuzz/harfbuzz_2.6.1.bb
+++ b/meta/recipes-graphics/harfbuzz/harfbuzz_2.6.1.bb
@@ -21,7 +21,7 @@ PACKAGECONFIG[glib] = "--with-glib,--without-glib,glib-2.0"
PACKAGECONFIG[graphite] = "--with-graphite2,--without-graphite2,graphite2"
PACKAGECONFIG[icu] = "--with-icu,--without-icu,icu"
-PACKAGES =+ "${PN}-icu ${PN}-icu-dev"
+PACKAGES =+ "${PN}-icu ${PN}-icu-dev ${PN}-subset"
LEAD_SONAME = "libharfbuzz.so"
@@ -36,5 +36,6 @@ FILES_${PN}-icu-dev = "${libdir}/libharfbuzz-icu.la \
${libdir}/libharfbuzz-icu.so \
${libdir}/pkgconfig/harfbuzz-icu.pc \
"
+FILES_${PN}-subset = "${libdir}/libharfbuzz-subset.so.*"
BBCLASSEXTEND = "native nativesdk"
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] image_types: add Zstandard conversion support
On 2019-11-07 09:01, Richard Purdie wrote:
> On Wed, 2019-11-06 at 13:43 +, Stefan Agner wrote:
>> From: Stefan Agner
>>
>> Add Zstandard (or just Zstd) compression support. This allows to
>> create Zstd compressed tarballs by using tar.zst as IMAGE_FSTYPES.
>>
>> Signed-off-by: Stefan Agner
>> ---
>> meta/classes/image_types.bbclass | 8 ++--
>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/meta/classes/image_types.bbclass
>> b/meta/classes/image_types.bbclass
>> index 2eeffbb366..d29b9c5787 100644
>> --- a/meta/classes/image_types.bbclass
>> +++ b/meta/classes/image_types.bbclass
>> @@ -59,6 +59,8 @@ XZ_INTEGRITY_CHECK ?= "crc32"
>>
>> ZIP_COMPRESSION_LEVEL ?= "-9"
>>
>> +ZSTD_COMPRESSION_LEVEL ?= "-3"
>> +
>> JFFS2_SUM_EXTRA_ARGS ?= ""
>> IMAGE_CMD_jffs2 = "mkfs.jffs2 --root=${IMAGE_ROOTFS} --faketime
>> --output=${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.jffs2
>> ${EXTRA_IMAGECMD}"
>>
>> @@ -269,7 +271,7 @@ IMAGE_TYPES = " \
>> hddimg \
>> squashfs squashfs-xz squashfs-lzo squashfs-lz4 \
>> ubi ubifs multiubi \
>> -tar tar.gz tar.bz2 tar.xz tar.lz4 \
>> +tar tar.gz tar.bz2 tar.xz tar.lz4 tar.zst \
>> cpio cpio.gz cpio.xz cpio.lzma cpio.lz4 \
>> wic wic.gz wic.bz2 wic.lzma \
>> container \
>> @@ -282,7 +284,7 @@ IMAGE_TYPES = " \
>> # CONVERSION_CMD/DEPENDS.
>> COMPRESSIONTYPES ?= ""
>>
>> -CONVERSIONTYPES = "gz bz2 lzma xz lz4 lzo zip sum md5sum sha1sum sha224sum
>> sha256sum sha384sum sha512sum bmap u-boot vmdk vdi qcow2 base64
>> ${COMPRESSIONTYPES}"
>> +CONVERSIONTYPES = "gz bz2 lzma xz lz4 lzo zip zst sum md5sum sha1sum
>> sha224sum sha256sum sha384sum sha512sum bmap u-boot vmdk vdi qcow2 base64
>> ${COMPRESSIONTYPES}"
>> CONVERSION_CMD_lzma = "lzma -k -f -7
>> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
>> CONVERSION_CMD_gz = "gzip -f -9 -n -c --rsyncable
>> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
>> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.gz"
>> CONVERSION_CMD_bz2 = "pbzip2 -f -k
>> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
>> @@ -290,6 +292,7 @@ CONVERSION_CMD_xz = "xz -f -k -c ${XZ_COMPRESSION_LEVEL}
>> ${XZ_DEFAULTS} --check=
>> CONVERSION_CMD_lz4 = "lz4 -9 -z -l
>> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}
>> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.lz4"
>> CONVERSION_CMD_lzo = "lzop -9 ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
>> CONVERSION_CMD_zip = "zip ${ZIP_COMPRESSION_LEVEL}
>> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.zip
>> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
>> +CONVERSION_CMD_zst = "zstd -f -k -c ${ZSTD_COMPRESSION_LEVEL}
>> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
>> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.zst"
>> CONVERSION_CMD_sum = "sumtool -i ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}
>> -o ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.sum ${JFFS2_SUM_EXTRA_ARGS}"
>> CONVERSION_CMD_md5sum = "md5sum ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
>> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.md5sum"
>> CONVERSION_CMD_sha1sum = "sha1sum ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}
>> > ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.sha1sum"
>> @@ -310,6 +313,7 @@ CONVERSION_DEPENDS_xz = "xz-native"
>> CONVERSION_DEPENDS_lz4 = "lz4-native"
>> CONVERSION_DEPENDS_lzo = "lzop-native"
>> CONVERSION_DEPENDS_zip = "zip-native"
>> +CONVERSION_DEPENDS_zst = "zstd-native"
>> CONVERSION_DEPENDS_sum = "mtd-utils-native"
>> CONVERSION_DEPENDS_bmap = "bmap-tools-native"
>> CONVERSION_DEPENDS_u-boot = "u-boot-tools-native"
>
> I was ok with this despite not having zstd-native in OE-Core however
> our automated testing is cleverer than I remembered:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/467
>
> so we may need to skip this option in the test...
>
> (oe-selftest -r imagefeatures.ImageFeatures.test_image_fstypes should
> reproduce)
Hm, I see, so we could fix that test.
However, how about moving zstd into core? There are already several
recipe in core making use of Zstd (optionally): mtd-utils, btrfs-tools
and squashfs-tools...
--
Stefan
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [OE-Core][PATCH] iproute2: update 5.2.0 -> 5.3.0
Signed-off-by: Changhyeok Bae
---
.../iproute2/{iproute2_5.2.0.bb => iproute2_5.3.0.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-connectivity/iproute2/{iproute2_5.2.0.bb =>
iproute2_5.3.0.bb} (65%)
diff --git a/meta/recipes-connectivity/iproute2/iproute2_5.2.0.bb
b/meta/recipes-connectivity/iproute2/iproute2_5.3.0.bb
similarity index 65%
rename from meta/recipes-connectivity/iproute2/iproute2_5.2.0.bb
rename to meta/recipes-connectivity/iproute2/iproute2_5.3.0.bb
index 1728cd69a1..8a86cbf78c 100644
--- a/meta/recipes-connectivity/iproute2/iproute2_5.2.0.bb
+++ b/meta/recipes-connectivity/iproute2/iproute2_5.3.0.bb
@@ -4,8 +4,8 @@ SRC_URI =
"${KERNELORG_MIRROR}/linux/utils/net/${BPN}/${BP}.tar.xz \
file://0001-libc-compat.h-add-musl-workaround.patch \
"
-SRC_URI[md5sum] = "0cb2736e7bc2f56254a363d3d23703b7"
-SRC_URI[sha256sum] =
"a5b95dec26353fc71dba9bb403e9343fad2a06bd69fb154a22a2aa2914f74da8"
+SRC_URI[md5sum] = "227404413c8d6db649d6188ead1e5a6e"
+SRC_URI[sha256sum] =
"cb1c1e45993a3bd2438543fd4332d70f1726a6e6ff97dc613a8258c993117b3f"
# CFLAGS are computed in Makefile and reference CCOPTS
#
--
2.23.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH RFC CFH][sumo 00/47] CVE check backport
Hi,
On Wed, Nov 06, 2019 at 01:46:09PM -0800, akuster808 wrote:
> Hello Mikko;
> I have collected other patches for sumo and built them locally but I
> have no way to inform Richard they pass an AB builds or automated
> testing for them to get into mainline sumo.
>
> I am placing them into
> https://git.openembedded.org/openembedded-core-contrib/log/?h=stable/sumo-community
Wow, I had no idea of this tree. Looks like the content is quite liberal
with version updates which may be necessary to maintain decent CVE fix status
with the resources at hand.
What is the relationship to thud?
Comparing oe-core sumo branch to contrib/stable/sumo-community shows for
example:
--- a/meta-selftest/conf/layer.conf
+++ b/meta-selftest/conf/layer.conf
@@ -9,4 +9,4 @@ BBFILE_COLLECTIONS += "selftest"
BBFILE_PATTERN_selftest = "^${LAYERDIR}/"
BBFILE_PRIORITY_selftest = "5"
-LAYERSERIES_COMPAT_selftest = "sumo"
+LAYERSERIES_COMPAT_selftest = "thud"
--- a/meta-skeleton/conf/layer.conf
+++ b/meta-skeleton/conf/layer.conf
@@ -14,4 +14,4 @@ LAYERVERSION_skeleton = "1"
LAYERDEPENDS_skeleton = "core"
-LAYERSERIES_COMPAT_skeleton = "sumo"
+LAYERSERIES_COMPAT_skeleton = "thud"
--- a/meta/conf/layer.conf
+++ b/meta/conf/layer.conf
@@ -7,12 +7,12 @@ BBFILE_COLLECTIONS += "core"
BBFILE_PATTERN_core = "^${LAYERDIR}/"
BBFILE_PRIORITY_core = "5"
-LAYERSERIES_CORENAMES = "sumo"
+LAYERSERIES_CORENAMES = "thud"
# This should only be incremented on significant changes that will
# cause compatibility issues with other layers
LAYERVERSION_core = "11"
-LAYERSERIES_COMPAT_core = "sumo"
+LAYERSERIES_COMPAT_core = "thud"
...
Cheers,
-Mikko
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [OE-Core][PATCH] ethtool: update 5.2 -> 5.3
Signed-off-by: Changhyeok Bae
---
.../ethtool/ethtool/avoid_parallel_tests.patch | 6 +++---
.../ethtool/{ethtool_5.2.bb => ethtool_5.3.bb} | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
rename meta/recipes-extended/ethtool/{ethtool_5.2.bb => ethtool_5.3.bb} (88%)
diff --git a/meta/recipes-extended/ethtool/ethtool/avoid_parallel_tests.patch
b/meta/recipes-extended/ethtool/ethtool/avoid_parallel_tests.patch
index 7c5d4f956b..b08b6124c8 100644
--- a/meta/recipes-extended/ethtool/ethtool/avoid_parallel_tests.patch
+++ b/meta/recipes-extended/ethtool/ethtool/avoid_parallel_tests.patch
@@ -1,4 +1,4 @@
-From f8333f7759717b4d163cfe8e3ef8861c5a667324 Mon Sep 17 00:00:00 2001
+From 6aa70c1598451d7c93e55ce5193aac90fe8b2136 Mon Sep 17 00:00:00 2001
From: Tudor Florea
Date: Wed, 28 May 2014 18:59:54 +0200
Subject: [PATCH] ethtool: use serial-tests config needed by ptest.
@@ -15,11 +15,11 @@ Upstream-Status: Inappropriate
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
-index 2127fdb..4910e6f 100644
+index 56e4683..1ac9d61 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2,7 +2,7 @@ dnl Process this file with autoconf to produce a configure
script.
- AC_INIT(ethtool, 5.2, net...@vger.kernel.org)
+ AC_INIT(ethtool, 5.3, net...@vger.kernel.org)
AC_PREREQ(2.52)
AC_CONFIG_SRCDIR([ethtool.c])
-AM_INIT_AUTOMAKE([gnu])
diff --git a/meta/recipes-extended/ethtool/ethtool_5.2.bb
b/meta/recipes-extended/ethtool/ethtool_5.3.bb
similarity index 88%
rename from meta/recipes-extended/ethtool/ethtool_5.2.bb
rename to meta/recipes-extended/ethtool/ethtool_5.3.bb
index 67e7fadee0..401331be39 100644
--- a/meta/recipes-extended/ethtool/ethtool_5.2.bb
+++ b/meta/recipes-extended/ethtool/ethtool_5.3.bb
@@ -11,8 +11,8 @@ SRC_URI =
"${KERNELORG_MIRROR}/software/network/ethtool/ethtool-${PV}.tar.gz \
file://avoid_parallel_tests.patch \
"
-SRC_URI[md5sum] = "79cff0d4af62b030ad28be90414b5c4a"
-SRC_URI[sha256sum] =
"8ad6cb30f6e1767d9d23a5cb5f606f3b51f83e85ebf0153c1506194f6709e90b"
+SRC_URI[md5sum] = "63d1c835b861912ea0dfd52cf66a2da4"
+SRC_URI[sha256sum] =
"cd2d8ea360431a2ea35ff61c276bcf2afee1ad901668a0b50ae9f1c5814756bd"
UPSTREAM_CHECK_URI = "https://www.kernel.org/pub/software/network/ethtool/";
--
2.23.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] tune-riscv: Add support for hard and soft float
On Wed, Nov 06, 2019 at 04:55:05PM -0800, Khem Raj wrote: > On Wed, Nov 6, 2019 at 4:48 PM Alistair Francis > wrote: >... > > -march is another can of worms that I was trying to avoid. I don't have > > a good way of handling the ISA strings at the moment without some crazy > > number of tune options. > > We need to handle that but I think that should be in meta-riscv since I > think for Linux we should just stick to rv64gc ABI and something cross > distro agreed upon abi for riscv32 and bare metal is another story that’s > where probably we need to address the ABIs We have the same problem even worse on arm64, with billions of combinations available. A solution is needed in both cases. 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] [PATCH 0/4] Resulttool minor enhancements
Resulttool minor enhancements - Enable report to use regression_map - Enable report to output raw test results - Enable report to print total test result statistic - Enable store to add extra test environment config data Yeoh Ee Peng (4): scripts/resulttool/report: Enable report to use regression_map scripts/resulttool/report: Enable output raw test results scripts/resulttool/report: Add total statistic to test result. resulttool/store.py: Enable add extra test environment data scripts/lib/resulttool/report.py | 35 ++ scripts/lib/resulttool/resultutils.py | 4 +-- scripts/lib/resulttool/store.py| 5 +++- .../resulttool/template/test_report_full_text.txt | 3 +- 4 files changed, 38 insertions(+), 9 deletions(-) -- 2.7.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libevent: enable OpenSSL unconditionally and update packaging
The original commit describes the reason for disabling openssl
so as to get 'more deterministic build[s]' and size-reduction:
commit 6c36fde6ce2e ("libevent: disable openssl by default"),
commit ad130b97a51a in poky.
Since the introduction of per-recipe sysroots, we always have
deterministic builds.
Size reduction can be achieved by splitting the package into
multiple sub-packages, which each only provide one of the
shared libraries.
Hence there appears no reason anymore to disable OpenSSL
support.
Because this recipe only provides shared libraries which are
handled automatically by bitbake, there is no need to add
the subpackages to the RDEPENDS of PN for backwards
compatibility. The packageing process of dependees will
simply pull in the sub-packages as runtime dependency as
needed.
This also how Debian splits this up.
While updating the packaging, we can also drop event_rpcgen.py
which appears to be a tool for generating rpc bindings, i.e.
something that should normally be in -dev. Given Debian
doesn't package this at all, and given it actually requires
python to run but no runtime dependency is stated at the
moment, it would appear that no users of this exist.
These changes also allow us to build all of nghttp2
out-of-the-box, without affecting existing users.
Signed-off-by: André Draszik
---
meta/recipes-support/libevent/libevent_2.1.11.bb | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-support/libevent/libevent_2.1.11.bb
b/meta/recipes-support/libevent/libevent_2.1.11.bb
index f005ab8bda..c746f22118 100644
--- a/meta/recipes-support/libevent/libevent_2.1.11.bb
+++ b/meta/recipes-support/libevent/libevent_2.1.11.bb
@@ -19,9 +19,6 @@ UPSTREAM_CHECK_URI = "http://libevent.org/";
S = "${WORKDIR}/${BPN}-${PV}-stable"
-PACKAGECONFIG ??= ""
-PACKAGECONFIG[openssl] = "--enable-openssl,--disable-openssl,openssl"
-
inherit autotools
# Needed for Debian packaging
@@ -29,11 +26,19 @@ LEAD_SONAME = "libevent-2.1.so"
inherit ptest multilib_header
-DEPENDS = "zlib"
+DEPENDS = "openssl zlib"
+
+PACKAGES =+ "${PN}-core ${PN}-extra ${PN}-openssl ${PN}-pthreads"
+FILES_${PN}-core = "${libdir}/libevent_core*${SOLIBS}"
+FILES_${PN}-extra = "${libdir}/libevent_extra*${SOLIBS}"
+FILES_${PN}-openssl = "${libdir}/libevent_openssl*${SOLIBS}"
+FILES_${PN}-pthreads = "${libdir}/libevent_pthreads-*${SOLIBS}"
BBCLASSEXTEND = "native nativesdk"
do_install_append() {
+ rm ${D}${bindir}/event_rpcgen.py
+ rmdir ${D}${bindir}
oe_multilib_header event2/event-config.h
}
--
2.23.0.rc1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/4] scripts/resulttool/report: Enable report to use regression_map
By default, report will use the store_map to generate the key
to reference each result set. In some situation when using store_map
with multiple set of tests sharing similar test configurations,
the report will only showing partial result set for results
that having identical result_id (use of multiconfig to run tests
where it generate identical result_id).
Enable report to have the option to use the regression_map (optional)
instead of the default store_map, where it will take larger
set of configurations to generate the key to reference each
result set, this will prevent the report from only showing
partial result set.
Signed-off-by: Yeoh Ee Peng
---
scripts/lib/resulttool/report.py | 16 +++-
scripts/lib/resulttool/resultutils.py | 4 ++--
2 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/scripts/lib/resulttool/report.py b/scripts/lib/resulttool/report.py
index 883b525..d2d4d1b 100644
--- a/scripts/lib/resulttool/report.py
+++ b/scripts/lib/resulttool/report.py
@@ -207,8 +207,11 @@ class ResultsTextReport(object):
maxlen=maxlen)
print(output)
-def view_test_report(self, logger, source_dir, branch, commit, tag):
+def view_test_report(self, logger, source_dir, branch, commit, tag,
use_regression_map):
test_count_reports = []
+configmap = resultutils.store_map
+if use_regression_map:
+configmap = resultutils.regression_map
if commit:
if tag:
logger.warning("Ignoring --tag as --commit was specified")
@@ -216,12 +219,12 @@ class ResultsTextReport(object):
repo = GitRepo(source_dir)
revs = gitarchive.get_test_revs(logger, repo, tag_name,
branch=branch)
rev_index = gitarchive.rev_find(revs, 'commit', commit)
-testresults = resultutils.git_get_result(repo, revs[rev_index][2])
+testresults = resultutils.git_get_result(repo, revs[rev_index][2],
configmap=configmap)
elif tag:
repo = GitRepo(source_dir)
-testresults = resultutils.git_get_result(repo, [tag])
+testresults = resultutils.git_get_result(repo, [tag],
configmap=configmap)
else:
-testresults = resultutils.load_resultsdata(source_dir)
+testresults = resultutils.load_resultsdata(source_dir,
configmap=configmap)
for testsuite in testresults:
for resultid in testresults[testsuite]:
skip = False
@@ -248,7 +251,7 @@ class ResultsTextReport(object):
def report(args, logger):
report = ResultsTextReport()
-report.view_test_report(logger, args.source_dir, args.branch, args.commit,
args.tag)
+report.view_test_report(logger, args.source_dir, args.branch, args.commit,
args.tag, args.use_regression_map)
return 0
def register_commands(subparsers):
@@ -263,3 +266,6 @@ def register_commands(subparsers):
parser_build.add_argument('--commit', help="Revision to report")
parser_build.add_argument('-t', '--tag', default='',
help='source_dir is a git repository, report on
the tag specified from that repository')
+parser_build.add_argument('-m', '--use_regression_map',
action='store_true',
+ help='instead of the default "store_map", use
the "regression_map" for report')
+
diff --git a/scripts/lib/resulttool/resultutils.py
b/scripts/lib/resulttool/resultutils.py
index 7cb85a6..f0ae8ec 100644
--- a/scripts/lib/resulttool/resultutils.py
+++ b/scripts/lib/resulttool/resultutils.py
@@ -177,7 +177,7 @@ def save_resultsdata(results, destdir,
fn="testresults.json", ptestjson=False, p
with open(dst.replace(fn, "ptest-%s.log" % i),
"w+") as f:
f.write(sectionlog)
-def git_get_result(repo, tags):
+def git_get_result(repo, tags, configmap=store_map):
git_objs = []
for tag in tags:
files = repo.run_cmd(['ls-tree', "--name-only", "-r",
tag]).splitlines()
@@ -200,7 +200,7 @@ def git_get_result(repo, tags):
# Optimize by reading all data with one git command
results = {}
for obj in parse_json_stream(repo.run_cmd(['show'] + git_objs + ['--'])):
-append_resultsdata(results, obj)
+append_resultsdata(results, obj, configmap=configmap)
return results
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/4] scripts/resulttool/report: Enable output raw test results
In case of debugging, report user need to acccess the raw
test result. Instead of going back to source file/directory/URL
to manually pull out the raw result, provide alternative
way to let report showing raw test results by providing
the result id (optional).
Signed-off-by: Yeoh Ee Peng
---
scripts/lib/resulttool/report.py | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/scripts/lib/resulttool/report.py b/scripts/lib/resulttool/report.py
index d2d4d1b..0c83fb6 100644
--- a/scripts/lib/resulttool/report.py
+++ b/scripts/lib/resulttool/report.py
@@ -207,7 +207,7 @@ class ResultsTextReport(object):
maxlen=maxlen)
print(output)
-def view_test_report(self, logger, source_dir, branch, commit, tag,
use_regression_map):
+def view_test_report(self, logger, source_dir, branch, commit, tag,
use_regression_map, raw_test):
test_count_reports = []
configmap = resultutils.store_map
if use_regression_map:
@@ -225,6 +225,17 @@ class ResultsTextReport(object):
testresults = resultutils.git_get_result(repo, [tag],
configmap=configmap)
else:
testresults = resultutils.load_resultsdata(source_dir,
configmap=configmap)
+if raw_test:
+raw_results = {}
+for testsuite in testresults:
+result = testresults[testsuite].get(raw_test, {})
+if result:
+raw_results[testsuite] = result
+if raw_results:
+print(json.dumps(raw_results, sort_keys=True, indent=4))
+else:
+print('Could not find raw test result for %s' % raw_test)
+return 0
for testsuite in testresults:
for resultid in testresults[testsuite]:
skip = False
@@ -251,7 +262,8 @@ class ResultsTextReport(object):
def report(args, logger):
report = ResultsTextReport()
-report.view_test_report(logger, args.source_dir, args.branch, args.commit,
args.tag, args.use_regression_map)
+report.view_test_report(logger, args.source_dir, args.branch, args.commit,
args.tag, args.use_regression_map,
+args.raw_test_only)
return 0
def register_commands(subparsers):
@@ -268,4 +280,6 @@ def register_commands(subparsers):
help='source_dir is a git repository, report on
the tag specified from that repository')
parser_build.add_argument('-m', '--use_regression_map',
action='store_true',
help='instead of the default "store_map", use
the "regression_map" for report')
+parser_build.add_argument('-r', '--raw_test_only', default='',
+ help='output raw test result only for the user
provided test result id')
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/4] resulttool/store.py: Enable add extra test environment data
Enable the option to add extra test environment data to the
configuration of each test result (as optional).
Example of optional test environment data include:
- custom packages included for runtime test
- detail machine specification used as target
- detail host environment used for bitbake
Signed-off-by: Yeoh Ee Peng
---
scripts/lib/resulttool/store.py | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/scripts/lib/resulttool/store.py b/scripts/lib/resulttool/store.py
index 79c83dd..e0951f0 100644
--- a/scripts/lib/resulttool/store.py
+++ b/scripts/lib/resulttool/store.py
@@ -24,6 +24,8 @@ def store(args, logger):
configvars = resultutils.extra_configvars.copy()
if args.executed_by:
configvars['EXECUTED_BY'] = args.executed_by
+if args.extra_test_env:
+configvars['EXTRA_TEST_ENV'] = args.extra_test_env
results = {}
logger.info('Reading files from %s' % args.source)
if resultutils.is_url(args.source) or os.path.isfile(args.source):
@@ -98,4 +100,5 @@ def register_commands(subparsers):
help='don\'t error if no results to store are
found')
parser_build.add_argument('-x', '--executed-by', default='',
help='add executed-by configuration to each
result file')
-
+parser_build.add_argument('-t', '--extra-test-env', default='',
+ help='add extra test environment data to each
result file configuration')
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/4] scripts/resulttool/report: Add total statistic to test result.
Add total passed, failed, and skipped statistic to test result.
Signed-off-by: Yeoh Ee Peng
---
scripts/lib/resulttool/report.py | 5 +
scripts/lib/resulttool/template/test_report_full_text.txt | 3 ++-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/scripts/lib/resulttool/report.py b/scripts/lib/resulttool/report.py
index 0c83fb6..692dd7a 100644
--- a/scripts/lib/resulttool/report.py
+++ b/scripts/lib/resulttool/report.py
@@ -186,6 +186,10 @@ class ResultsTextReport(object):
havefailed = True
if line['machine'] not in machines:
machines.append(line['machine'])
+reporttotalvalues = {}
+for k in cols:
+reporttotalvalues[k] = '%s' % sum([line[k] for line in
test_count_reports])
+reporttotalvalues['count'] = '%s' % len(test_count_reports)
for (machine, report) in self.ptests.items():
for ptest in self.ptests[machine]:
if len(ptest) > maxlen['ptest']:
@@ -199,6 +203,7 @@ class ResultsTextReport(object):
if len(ltpposixtest) > maxlen['ltpposixtest']:
maxlen['ltpposixtest'] = len(ltpposixtest)
output = template.render(reportvalues=reportvalues,
+ reporttotalvalues=reporttotalvalues,
havefailed=havefailed,
machines=machines,
ptests=self.ptests,
diff --git a/scripts/lib/resulttool/template/test_report_full_text.txt
b/scripts/lib/resulttool/template/test_report_full_text.txt
index 17c99cb..2efba2e 100644
--- a/scripts/lib/resulttool/template/test_report_full_text.txt
+++ b/scripts/lib/resulttool/template/test_report_full_text.txt
@@ -8,7 +8,8 @@ Test Result Status Summary (Counts/Percentages sorted by
testseries, ID)
{{ report.testseries.ljust(maxlen['testseries']) }} | {{
report.result_id.ljust(maxlen['result_id']) }} | {{
(report.passed|string).ljust(maxlen['passed']) }} | {{
(report.failed|string).ljust(maxlen['failed']) }} | {{
(report.skipped|string).ljust(maxlen['skipped']) }}
{% endfor %}
--
-
+{{ 'Total'.ljust(maxlen['testseries']) }} | {{
reporttotalvalues['count'].ljust(maxlen['result_id']) }} | {{
reporttotalvalues['passed'].ljust(maxlen['passed']) }} | {{
reporttotalvalues['failed'].ljust(maxlen['failed']) }} | {{
reporttotalvalues['skipped'].ljust(maxlen['skipped']) }}
+--
{% for machine in machines %}
{% if ptests[machine] %}
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] maintaining sumo (was Re: [PATCH][thud] cve-check: backport rewrite from master)
On Thu, 7 Nov 2019 at 07:59, wrote: > Hi, > > On Wed, Nov 06, 2019 at 05:53:27PM +, Richard Purdie wrote: > > On Wed, 2019-11-06 at 16:06 +, mikko.rap...@bmw.de wrote: > > > Hi, > > > > > > On Wed, Nov 06, 2019 at 02:59:16PM +, Ryan Harkin wrote: > > > > Hi Ross/Richard, > > > > > > > > I'd like this applied to Sumo also. Should I create a new patch and > > > > send it > > > > to the list, or is there a process for requesting this is cherry- > > > > picked > > > > across? > > > > > > I just posted the port of this and all other CVE scan related changes > > > to sumo > > > > http://lists.openembedded.org/pipermail/openembedded-core/2019-November/288817.html > > > > Thanks Mikko! That's a great help, I guess my question was good timing for our mutual interest in Sumo. > > But the question is valid :) > > > > Support for sumo officially ended. I can see a case that the broken CVE > > tools there are a good reason we could consider merging the patch > > series but we do need to be able to test it to merge it to the main > > branch. If we can't test, we're merging blind and the quality the > > project tries to deliver could be compromised. > > > > I have made some tweaks to the autobuilder which bring us closer to > > being able to test sumo using the workers still around from that > > release. > > > > The things that make me nervous are questions like: > > > > Which releases do we "open" for such patches? How far back do we go? > > Which kinds of patches are acceptable? > > > > Note that sumo (and earlier) doesn't have much of the QA automation > > which we've now built our processes around so we don't get test > > reports. > > > > You mention wanting to change gcc. That means we really do need a full > > retest of it to merge that (which is why it never happened originally > > from what I remember). > > > > Also, the LTS proposal stated we needed someone to handle this work. We > > have no such person, even if we do somehow find them, they can't be > > expected to cover all the old releases and effectively turn all of them > > into LTS releases. How can we get the funding to try and get some help > > with handling this workload? > > > > I am probably going to try and make a case for sorting the CVE tooling > > on sumo as I agree its bad and we should do something. Where do we draw > > the line though. > > > > Basically, this looks like it could create a lot of extra work without > > helping the core project under-resourcing we currently struggle with. > > You can therefore see why I might be nervous :/. > > All this is understood. > Agreed. It's an expensive and tricky task. > I need to maintain sumo in a project for a while longer so I can publish > that work. > The CVE checker patches are just a start. > Yes, the same is true for me. I need to maintain a Sumo distro until mid-2020, at least. It uses the poky merge branch [1]. My support may extend further when the time comes. > > Providing funding for Yocto Project LTS work is possible but a lot harder > for me to do. > Testing and publishing patches is much easier. > Not sure if it helps, but I have a Jenkins job that tests sumo on a trigger (there is one for Warrior also): https://ci.linaro.org/job/warp7-openembedded-sumo/ eg. it was triggered when Armin's patch was merged yesterday. This builds Sumo, based on Linaro's OE-RPB distro for NXP WaRP7 (imx7s-warp). It then runs the build in our LAVA lab (although the boards have gone down recently, they're normally up). Once the boards are up again, I'll add ptest to the job, to give it a more thorough workout. I'll also add the sumo-next branch to the list of build configurations. > Could you clarify Yocto Project side answers to these questions: > > If I continue to publish patches for sumo, can I continue doing so on > oe-core mailing list? > > If I continue to collect patches for sumo, can I do so using Yocto Project > infrastructure, e.g. > a sumo-contrib-lts or similar branch in poky git tree? > > If I continue to test patches, what would be the patch acceptance criteria > and required testing? > I would assume same as stable release rules, but maybe these need to be > even stricter, e.g. > only support building on Debian stable, following the LTS proposal. I'm > testing in my own project > trees and CI with target HW, and doing world builds on pure poky with qemu > target. I could some > kind of ptest execution to plain poky as well. > > Would any testing of patches be possible in Yocto Project infrastructure? > > All of these things I can do also completely outside of Yocto Project, > e.g. publish a sumo > git tree on github, and rely only on my own testing. But I'd like to see > some co-operation here from other users who are stuck with sumo. > > -Mikko [1] http://git.yoctoproject.org/git/poky -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedd
[OE-core] [PATCH] Fix libgcc-initial build issue for cortex-a32
When we try to build images for machine which is tuned for
cortex-a32, then libgcc-initial recipe fails to build with
below error message.
-- snip --
configure:3529: aarch64-poky-linux-gcc -mcpu=cortex-a32+crc
-fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security
-Werror=format-security
--sysroot=.../tmp/work/aarch64-poky-linux/libgcc-initial/9.2.0-r0/recipe-sysroot
-o conftest -O2 -pipe -g -feliminate-unused-debug-types
-fmacro-prefix-map=.../tmp/work/aarch64-poky-linux/libgcc-initial/9.2.0-r0=/usr/src/debug/libgcc-initial/9.2.0-r0
-fdebug-prefix-map=.../tmp/work/aarch64-poky-linux/libgcc-initial/9.2.0-r0=/usr/src/debug/libgcc-initial/9.2.0-r0
-fdebug-prefix-map=.../tmp/work/aarch64-poky-linux/libgcc-initial/9.2.0-r0/recipe-sysroot=
-fdebug-prefix-map=.../tmp/work/aarch64-poky-linux/libgcc-initial/9.2.0-r0/recipe-sysroot-native=
-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -fstack-protector-strong
-Wl,-z,relro,-z,now conftest.c >&5
aarch64-poky-linux-gcc: fatal error: unknown value 'cortex-a32+crc' for '-mcpu'
-- snip --
- Replacing TUNE_FEATURES from aarch64 to armv8a will solve the above
build issue.
- Changed BASE_LIB to 'lib', as cortex-a32 is a 32bit ARMv8a architecture.
The sample machine config file (qemuarma32.conf) used to reproduce
the error looks like:
-- snip --
require conf/machine/include/tune-cortexa32.inc
require conf/machine/include/qemu.inc
KERNEL_IMAGETYPE = "Image"
SERIAL_CONSOLES ?= "115200;ttyAMA0 115200;hvc0"
KMACHINE_qemuarma32 = "qemuarm64"
-- snip --
Signed-off-by: Jagadeesh Krishnanjanappa
---
meta/conf/machine/include/tune-cortexa32.inc | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/meta/conf/machine/include/tune-cortexa32.inc
b/meta/conf/machine/include/tune-cortexa32.inc
index 9c948f1766..3ab1addd91 100644
--- a/meta/conf/machine/include/tune-cortexa32.inc
+++ b/meta/conf/machine/include/tune-cortexa32.inc
@@ -10,9 +10,9 @@ require conf/machine/include/arm/arch-armv8a.inc
AVAILTUNES += "cortexa32 cortexa32-crypto"
ARMPKGARCH_tune-cortexa32 = "cortexa32"
ARMPKGARCH_tune-cortexa32-crypto = "cortexa32"
-TUNE_FEATURES_tune-cortexa32 = "aarch64 cortexa32 crc"
-TUNE_FEATURES_tune-cortexa32-crypto = "aarch64 cortexa32 crc crypto"
+TUNE_FEATURES_tune-cortexa32 = "armv8a cortexa32 crc"
+TUNE_FEATURES_tune-cortexa32-crypto = "armv8a cortexa32 crc crypto"
PACKAGE_EXTRA_ARCHS_tune-cortexa32 =
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa32"
PACKAGE_EXTRA_ARCHS_tune-cortexa32-crypto =
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa32 cortexa32-crypto"
-BASE_LIB_tune-cortexa32 = "lib64"
-BASE_LIB_tune-cortexa32-crypto= "lib64"
+BASE_LIB_tune-cortexa32 = "lib"
+BASE_LIB_tune-cortexa32-crypto= "lib"
--
2.23.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH RFC CFH][sumo 00/47] CVE check backport
On Wed, Nov 06, 2019 at 05:37:15PM +0200, Mikko Rapeli wrote: > Hi, Hi Mikko, >... > I use sumo and due to various reasons like BSP layers, binary > compatibility, contracts etc can't update to newer release > or to master branch. I suspect I'm not alone. I might end up with similar reasons, but for warrior. And might end up doing similar longer term updates for warrior. (not yet 100% certain) >... > The tooling will expose that sumo is severely lacking in security > patches, but the tooling is a start for anyone interested, like me, > to fill the gaps and publish patches for bitbake recipes we care > about. >... Thud is officially still community maintained, as long as this is true the point could be made that everything that gets fixed in sumo should also get fixed in thud. 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
Re: [OE-core] [PATCH][zeus][master] harfbuzz: split libharfbuzz-subset.so to its own binary package
On 07/11/2019 08:13, Mikko Rapeli wrote: harfbuzz binary package size increased from 624608 bytes in yocto 2.5 to 1365431 bytes in yocto 3.0. Most of the size increase is in the new libharfbuzz-subset.so* library, which based on the name seems to duplicate parts of the libharfbuzz main library, though it RDEPENDS on harfbuzz which is odd. Split it to its own binary package which will be installed if anyone needs it. Effect to harfbuzz binary package size is: The subset piece is a library to subset fonts, not a subset of the library itself. https://harfbuzz.github.io/utilities.html#utilities-command-line-hbsubset Can you update the message? Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH RFC CFH][sumo 00/47] CVE check backport
Hi, On Thu, Nov 07, 2019 at 01:13:32PM +0200, Adrian Bunk wrote: > On Wed, Nov 06, 2019 at 05:37:15PM +0200, Mikko Rapeli wrote: > > Hi, > > Hi Mikko, > > >... > > I use sumo and due to various reasons like BSP layers, binary > > compatibility, contracts etc can't update to newer release > > or to master branch. I suspect I'm not alone. > > I might end up with similar reasons, but for warrior. > And might end up doing similar longer term updates for warrior. > (not yet 100% certain) I'm skipping warrior but going to zeus in addition to sumo. After insipiration from Yocto Project Summit I hope to run master branch in some projects with regular updates, and eventually aligning to some stable release again. Hopefully an LTS one :) > >... > > The tooling will expose that sumo is severely lacking in security > > patches, but the tooling is a start for anyone interested, like me, > > to fill the gaps and publish patches for bitbake recipes we care > > about. > >... > > Thud is officially still community maintained, as long as this is true > the point could be made that everything that gets fixed in sumo should > also get fixed in thud. So to keep sumo alive, we should the also keep zeus, warrior and thud, and of course master branch first. For some issues this actually works when the exact same CVE patch applies, but the open question then is testing. How should a developer test a patch before submitting it, or multiple versions of it? I'm testing in project tree with CI and target tests, then compile testing on master. qemu ptest runs would be nice but not sure how to get a stable or useful test set for various branches. To make things more complicated, the project trees sadly contain more backports, fixes and workarounds which are not suitable for upstreaming into stable or even master branches. -Mikko -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libevent: enable OpenSSL unconditionally and update packaging
I would rather keep the option to disable openssl, but simply switch it on
by default.
Alex
On Thu, 7 Nov 2019 at 13:11, André Draszik wrote:
> The original commit describes the reason for disabling openssl
> so as to get 'more deterministic build[s]' and size-reduction:
> commit 6c36fde6ce2e ("libevent: disable openssl by default"),
> commit ad130b97a51a in poky.
>
> Since the introduction of per-recipe sysroots, we always have
> deterministic builds.
>
> Size reduction can be achieved by splitting the package into
> multiple sub-packages, which each only provide one of the
> shared libraries.
>
> Hence there appears no reason anymore to disable OpenSSL
> support.
>
> Because this recipe only provides shared libraries which are
> handled automatically by bitbake, there is no need to add
> the subpackages to the RDEPENDS of PN for backwards
> compatibility. The packageing process of dependees will
> simply pull in the sub-packages as runtime dependency as
> needed.
>
> This also how Debian splits this up.
>
> While updating the packaging, we can also drop event_rpcgen.py
> which appears to be a tool for generating rpc bindings, i.e.
> something that should normally be in -dev. Given Debian
> doesn't package this at all, and given it actually requires
> python to run but no runtime dependency is stated at the
> moment, it would appear that no users of this exist.
>
> These changes also allow us to build all of nghttp2
> out-of-the-box, without affecting existing users.
>
> Signed-off-by: André Draszik
> ---
> meta/recipes-support/libevent/libevent_2.1.11.bb | 13 +
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/meta/recipes-support/libevent/libevent_2.1.11.bb
> b/meta/recipes-support/libevent/libevent_2.1.11.bb
> index f005ab8bda..c746f22118 100644
> --- a/meta/recipes-support/libevent/libevent_2.1.11.bb
> +++ b/meta/recipes-support/libevent/libevent_2.1.11.bb
> @@ -19,9 +19,6 @@ UPSTREAM_CHECK_URI = "http://libevent.org/";
>
> S = "${WORKDIR}/${BPN}-${PV}-stable"
>
> -PACKAGECONFIG ??= ""
> -PACKAGECONFIG[openssl] = "--enable-openssl,--disable-openssl,openssl"
> -
> inherit autotools
>
> # Needed for Debian packaging
> @@ -29,11 +26,19 @@ LEAD_SONAME = "libevent-2.1.so"
>
> inherit ptest multilib_header
>
> -DEPENDS = "zlib"
> +DEPENDS = "openssl zlib"
> +
> +PACKAGES =+ "${PN}-core ${PN}-extra ${PN}-openssl ${PN}-pthreads"
> +FILES_${PN}-core = "${libdir}/libevent_core*${SOLIBS}"
> +FILES_${PN}-extra = "${libdir}/libevent_extra*${SOLIBS}"
> +FILES_${PN}-openssl = "${libdir}/libevent_openssl*${SOLIBS}"
> +FILES_${PN}-pthreads = "${libdir}/libevent_pthreads-*${SOLIBS}"
>
> BBCLASSEXTEND = "native nativesdk"
>
> do_install_append() {
> + rm ${D}${bindir}/event_rpcgen.py
> + rmdir ${D}${bindir}
> oe_multilib_header event2/event-config.h
> }
>
> --
> 2.23.0.rc1
>
> --
> ___
> 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] ✗ patchtest: failure for Fix libgcc-initial build issue for cortex-a32
== Series Details == Series: Fix libgcc-initial build issue for cortex-a32 Revision: 1 URL : https://patchwork.openembedded.org/series/21007/ 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: * PatchFix libgcc-initial build issue for cortex-a32 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
Re: [OE-core] [PATCH][zeus][master] harfbuzz: split libharfbuzz-subset.so to its own binary package
On Thu, Nov 07, 2019 at 10:54:23AM +, Ross Burton wrote: > On 07/11/2019 08:13, Mikko Rapeli wrote: > > harfbuzz binary package size increased from 624608 bytes in yocto 2.5 to > > 1365431 bytes in yocto 3.0. Most of the size increase is in the new > > libharfbuzz-subset.so* library, which based on the name seems to > > duplicate parts of the libharfbuzz main library, though it > > RDEPENDS on harfbuzz which is odd. Split it to its own binary > > package which will be installed if anyone needs it. Effect to harfbuzz > > binary package size is: > > > The subset piece is a library to subset fonts, not a subset of the library > itself. > > https://harfbuzz.github.io/utilities.html#utilities-command-line-hbsubset > > Can you update the message? Thanks, v2 coming. -Mikko -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2][zeus][master] harfbuzz: split libharfbuzz-subset.so to its own binary package
harfbuzz binary package size increased from 624608 bytes in yocto 2.5 to
1365431 bytes in yocto 3.0. Most of the size increase is in the new
libharfbuzz-subset.so* library
https://harfbuzz.github.io/utilities.html#utilities-command-line-hbsubset
Split it to its own binary package which will be installed if anyone needs it.
Effect to harfbuzz binary package size is:
-PKGSIZE = 1476271
+PKGSIZE = 1007424
Signed-off-by: Mikko Rapeli
---
meta/recipes-graphics/harfbuzz/harfbuzz_2.6.1.bb | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
v2: update commit message with subset link
v1:
http://lists.openembedded.org/pipermail/openembedded-core/2019-November/23.html
diff --git a/meta/recipes-graphics/harfbuzz/harfbuzz_2.6.1.bb
b/meta/recipes-graphics/harfbuzz/harfbuzz_2.6.1.bb
index 99cd4cd..80ab545 100644
--- a/meta/recipes-graphics/harfbuzz/harfbuzz_2.6.1.bb
+++ b/meta/recipes-graphics/harfbuzz/harfbuzz_2.6.1.bb
@@ -21,7 +21,7 @@ PACKAGECONFIG[glib] = "--with-glib,--without-glib,glib-2.0"
PACKAGECONFIG[graphite] = "--with-graphite2,--without-graphite2,graphite2"
PACKAGECONFIG[icu] = "--with-icu,--without-icu,icu"
-PACKAGES =+ "${PN}-icu ${PN}-icu-dev"
+PACKAGES =+ "${PN}-icu ${PN}-icu-dev ${PN}-subset"
LEAD_SONAME = "libharfbuzz.so"
@@ -36,5 +36,6 @@ FILES_${PN}-icu-dev = "${libdir}/libharfbuzz-icu.la \
${libdir}/libharfbuzz-icu.so \
${libdir}/pkgconfig/harfbuzz-icu.pc \
"
+FILES_${PN}-subset = "${libdir}/libharfbuzz-subset.so.*"
BBCLASSEXTEND = "native nativesdk"
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libevent: enable OpenSSL unconditionally and update packaging
On Thu, 2019-11-07 at 13:26 +0100, Alexander Kanavin wrote:
> I would rather keep the option to disable openssl, but simply switch it on by
> default
Why complicate things, what's the use-case? If libevent_openssl.so is not
used by anything, that library will not be pulled in, as it is a
separate package now.
Cheers,
A.
> .
>
> Alex
>
> On Thu, 7 Nov 2019 at 13:11, André Draszik wrote:
> > The original commit describes the reason for disabling openssl
> > so as to get 'more deterministic build[s]' and size-reduction:
> > commit 6c36fde6ce2e ("libevent: disable openssl by default"),
> > commit ad130b97a51a in poky.
> >
> > Since the introduction of per-recipe sysroots, we always have
> > deterministic builds.
> >
> > Size reduction can be achieved by splitting the package into
> > multiple sub-packages, which each only provide one of the
> > shared libraries.
> >
> > Hence there appears no reason anymore to disable OpenSSL
> > support.
> >
> > Because this recipe only provides shared libraries which are
> > handled automatically by bitbake, there is no need to add
> > the subpackages to the RDEPENDS of PN for backwards
> > compatibility. The packageing process of dependees will
> > simply pull in the sub-packages as runtime dependency as
> > needed.
> >
> > This also how Debian splits this up.
> >
> > While updating the packaging, we can also drop event_rpcgen.py
> > which appears to be a tool for generating rpc bindings, i.e.
> > something that should normally be in -dev. Given Debian
> > doesn't package this at all, and given it actually requires
> > python to run but no runtime dependency is stated at the
> > moment, it would appear that no users of this exist.
> >
> > These changes also allow us to build all of nghttp2
> > out-of-the-box, without affecting existing users.
> >
> > Signed-off-by: André Draszik
> > ---
> > meta/recipes-support/libevent/libevent_2.1.11.bb | 13 +
> > 1 file changed, 9 insertions(+), 4 deletions(-)
> >
> > diff --git a/meta/recipes-support/libevent/libevent_2.1.11.bb
> > b/meta/recipes-support/libevent/libevent_2.1.11.bb
> > index f005ab8bda..c746f22118 100644
> > --- a/meta/recipes-support/libevent/libevent_2.1.11.bb
> > +++ b/meta/recipes-support/libevent/libevent_2.1.11.bb
> > @@ -19,9 +19,6 @@ UPSTREAM_CHECK_URI = "http://libevent.org/";
> >
> > S = "${WORKDIR}/${BPN}-${PV}-stable"
> >
> > -PACKAGECONFIG ??= ""
> > -PACKAGECONFIG[openssl] = "--enable-openssl,--disable-openssl,openssl"
> > -
> > inherit autotools
> >
> > # Needed for Debian packaging
> > @@ -29,11 +26,19 @@ LEAD_SONAME = "libevent-2.1.so"
> >
> > inherit ptest multilib_header
> >
> > -DEPENDS = "zlib"
> > +DEPENDS = "openssl zlib"
> > +
> > +PACKAGES =+ "${PN}-core ${PN}-extra ${PN}-openssl ${PN}-pthreads"
> > +FILES_${PN}-core = "${libdir}/libevent_core*${SOLIBS}"
> > +FILES_${PN}-extra = "${libdir}/libevent_extra*${SOLIBS}"
> > +FILES_${PN}-openssl = "${libdir}/libevent_openssl*${SOLIBS}"
> > +FILES_${PN}-pthreads = "${libdir}/libevent_pthreads-*${SOLIBS}"
> >
> > BBCLASSEXTEND = "native nativesdk"
> >
> > do_install_append() {
> > + rm ${D}${bindir}/event_rpcgen.py
> > + rmdir ${D}${bindir}
> > oe_multilib_header event2/event-config.h
> > }
> >
> > --
> > 2.23.0.rc1
> >
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libevent: enable OpenSSL unconditionally and update packaging
On Thu, 2019-11-07 at 14:01 +, André Draszik wrote: > On Thu, 2019-11-07 at 13:26 +0100, Alexander Kanavin wrote: > > I would rather keep the option to disable openssl, but simply > > switch it on by default > > Why complicate things, what's the use-case? If libevent_openssl.so is > not > used by anything, that library will not be pulled in, as it is a > separate package now. Build time dependencies and hence build speed? It sounds trivial but all these inter-dependencies do mount up so if we don't need it, keeping things minimal has advantages. If there is a security issue in openssl, its one more thing that would have to be regenerated if a CVE fix were added too... Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH RFC CFH][sumo 00/47] CVE check backport
On Thu, Nov 07, 2019 at 12:13:51PM +, mikko.rap...@bmw.de wrote: > Hi, Hi Mikko, > On Thu, Nov 07, 2019 at 01:13:32PM +0200, Adrian Bunk wrote: > > On Wed, Nov 06, 2019 at 05:37:15PM +0200, Mikko Rapeli wrote: > > > Hi, > > > > Hi Mikko, > > > > >... > > > I use sumo and due to various reasons like BSP layers, binary > > > compatibility, contracts etc can't update to newer release > > > or to master branch. I suspect I'm not alone. > > > > I might end up with similar reasons, but for warrior. > > And might end up doing similar longer term updates for warrior. > > (not yet 100% certain) > > I'm skipping warrior but going to zeus in addition to sumo. After > insipiration from Yocto Project Summit I hope to run master branch > in some projects with regular updates, and eventually aligning to > some stable release again. Hopefully an LTS one :) everyone is currently running projects on different releases. Let's hope LTS will happen, and that with a properly communicated LTS schedule most distributions and users will switch to the LTS releases just like what happened with Ubuntu. > > >... > > > The tooling will expose that sumo is severely lacking in security > > > patches, but the tooling is a start for anyone interested, like me, > > > to fill the gaps and publish patches for bitbake recipes we care > > > about. > > >... > > > > Thud is officially still community maintained, as long as this is true > > the point could be made that everything that gets fixed in sumo should > > also get fixed in thud. > > So to keep sumo alive, we should the also keep zeus, warrior and thud, and > of course master branch first. For some issues this actually works when > the exact same CVE patch applies, but the open question then is testing. >... When a branch is EOL it is documented to be dead. But upgrading to a more recent non-EOL branch, e.g. sumo to thud, should not result in losing (security) fixes. The root problem is that "community support" for a stable branch in practice often means "no support". If sumo is supported but thud is not, this should at least be made visible to users. > -Mikko 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] [PATCH v2] tune-cortexa32: Fix libgcc-initial build issue for cortex-a32
When we try to build images for machine which is tuned for
cortex-a32, then libgcc-initial recipe fails to build with
below error message.
-- snip --
configure:3529: aarch64-poky-linux-gcc -mcpu=cortex-a32+crc
-fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security
-Werror=format-security
--sysroot=.../tmp/work/aarch64-poky-linux/libgcc-initial/9.2.0-r0/recipe-sysroot
-o conftest -O2 -pipe -g -feliminate-unused-debug-types
-fmacro-prefix-map=.../tmp/work/aarch64-poky-linux/libgcc-initial/9.2.0-r0=/usr/src/debug/libgcc-initial/9.2.0-r0
-fdebug-prefix-map=.../tmp/work/aarch64-poky-linux/libgcc-initial/9.2.0-r0=/usr/src/debug/libgcc-initial/9.2.0-r0
-fdebug-prefix-map=.../tmp/work/aarch64-poky-linux/libgcc-initial/9.2.0-r0/recipe-sysroot=
-fdebug-prefix-map=.../tmp/work/aarch64-poky-linux/libgcc-initial/9.2.0-r0/recipe-sysroot-native=
-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -fstack-protector-strong
-Wl,-z,relro,-z,now conftest.c >&5
aarch64-poky-linux-gcc: fatal error: unknown value 'cortex-a32+crc' for '-mcpu'
-- snip --
- Replacing TUNE_FEATURES from aarch64 to armv8a will solve the above
build issue.
- Changed BASE_LIB to 'lib', as cortex-a32 is a 32bit ARMv8a architecture.
The sample machine config file (qemuarma32.conf) used to reproduce
the error looks like:
-- snip --
require conf/machine/include/tune-cortexa32.inc
require conf/machine/include/qemu.inc
KERNEL_IMAGETYPE = "Image"
SERIAL_CONSOLES ?= "115200;ttyAMA0 115200;hvc0"
KMACHINE_qemuarma32 = "qemuarm64"
-- snip --
Signed-off-by: Jagadeesh Krishnanjanappa
---
meta/conf/machine/include/tune-cortexa32.inc | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/meta/conf/machine/include/tune-cortexa32.inc
b/meta/conf/machine/include/tune-cortexa32.inc
index 9c948f1766..3ab1addd91 100644
--- a/meta/conf/machine/include/tune-cortexa32.inc
+++ b/meta/conf/machine/include/tune-cortexa32.inc
@@ -10,9 +10,9 @@ require conf/machine/include/arm/arch-armv8a.inc
AVAILTUNES += "cortexa32 cortexa32-crypto"
ARMPKGARCH_tune-cortexa32 = "cortexa32"
ARMPKGARCH_tune-cortexa32-crypto = "cortexa32"
-TUNE_FEATURES_tune-cortexa32 = "aarch64 cortexa32 crc"
-TUNE_FEATURES_tune-cortexa32-crypto = "aarch64 cortexa32 crc crypto"
+TUNE_FEATURES_tune-cortexa32 = "armv8a cortexa32 crc"
+TUNE_FEATURES_tune-cortexa32-crypto = "armv8a cortexa32 crc crypto"
PACKAGE_EXTRA_ARCHS_tune-cortexa32 =
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa32"
PACKAGE_EXTRA_ARCHS_tune-cortexa32-crypto =
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa32 cortexa32-crypto"
-BASE_LIB_tune-cortexa32 = "lib64"
-BASE_LIB_tune-cortexa32-crypto= "lib64"
+BASE_LIB_tune-cortexa32 = "lib"
+BASE_LIB_tune-cortexa32-crypto= "lib"
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH RFC CFH][sumo 00/47] CVE check backport
On Wed, 2019-11-06 at 13:46 -0800, akuster808 wrote: > On 11/6/19 7:37 AM, Mikko Rapeli wrote: > QA resources have been a donation from Intel and Windriver above > their membership fees. I don't fee right asking them to run QA. > > patches aiming at yocto 2.5 sumo. If not, would be really nice if > > someone could collect patches into sumo-next or sumo-contrib branch > > where us > > users could be in charge of all Quality Assurance. > > I have collected other patches for sumo and built them locally but I > have no way to inform Richard they pass an AB builds or automated > testing for them to get into mainline sumo. Given the discussions around LTS and the fact we'd need to do *something* with the autobuilder to help support it, I've been experimenting. I created a sumo-next branch with a uninative update and Mikko's patches and then managed to get it to build (and pass) on the autobuilder. I did directly merge a bitbake fix to the 1.38 branch to avoid test failures too. The autobuilder successfully builds a-full for sumo-next. Compared to a normal build the differences are: * unsupported workers are removed from the pool for sumo so it only builds on a subset of the infrastructure * no buildperf tests * there are no supported fedora workers left so no oe-selftest-fedora * no ptest image execution (we never did this with sumo) * no test result output (wasn't present in sumo and never backported) I'm prepared to merge sumo-next on the basis of these results and use it as a model for how we could continue to get critical patches into older releases. More work would be needed to see if any older releases could work. At this point the TSC needs to discuss LTS and what our branch policy may be going forward but this does add useful data to that discussion and may help influence those discussions. [For reference I did have to seek advice from upstream buildbot on how to avoid a bug and its taken quite some experimenting to find the magic to make this work. I did have to update the autobuilder-helper sumo branch to be in sync too]. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] rm_work: Simplify logic for setscene promotion
* Instead of overwriting the stamp name with 'dummy', handle
setscene promotion in the default case block
* Merge '*do_image_complete_setscene*' and '*do_image_qa_setscene*'
case handling
Signed-off-by: Jacob Kroon
---
meta/classes/rm_work.bbclass | 49 +++-
1 file changed, 15 insertions(+), 34 deletions(-)
diff --git a/meta/classes/rm_work.bbclass b/meta/classes/rm_work.bbclass
index 0bbc450100..01c2ab1c78 100644
--- a/meta/classes/rm_work.bbclass
+++ b/meta/classes/rm_work.bbclass
@@ -47,39 +47,26 @@ do_rm_work () {
cd `dirname ${STAMP}`
for i in `basename ${STAMP}`*
do
-# By default we'll delete the stamp, unless $i is changed by the inner
loop
-# (i=dummy does this)
-
case $i in
*sigdata*|*sigbasedata*)
# Save/skip anything that looks like a signature data file.
-i=dummy
;;
-*do_image_complete_setscene*)
-# Ensure we don't 'stack' setscene extensions to this stamp with
the section below
-i=dummy
+*do_image_complete_setscene*|*do_image_qa_setscene*)
+# Ensure we don't 'stack' setscene extensions to these stamps with
the sections below
;;
*do_image_complete*)
# Promote do_image_complete stamps to setscene versions (ahead of
*do_image* below)
mv $i `echo $i | sed -e
"s#do_image_complete#do_image_complete_setscene#"`
-i=dummy
-;;
-*do_image_qa_setscene*)
-# Ensure we don't 'stack' setscene extensions to this stamp with
the section below
-i=dummy
;;
*do_image_qa*)
# Promote do_image_qa stamps to setscene versions (ahead of
*do_image* below)
mv $i `echo $i | sed -e "s#do_image_qa#do_image_qa_setscene#"`
-i=dummy
;;
*do_package_write*|*do_rootfs*|*do_image*|*do_bootimg*|*do_write_qemuboot_conf*|*do_build*)
-i=dummy
;;
*do_addto_recipe_sysroot*)
# Preserve recipe-sysroot-native if do_addto_recipe_sysroot has
been used
excludes="$excludes recipe-sysroot-native"
-i=dummy
;;
*do_package|*do_package.*|*do_package_setscene.*)
# We remove do_package entirely, including any
@@ -87,30 +74,24 @@ do_rm_work () {
# such as 'packages' and 'packages-split' and these can be large.
No end
# of chain tasks depend directly on do_package anymore.
rm -f $i;
-i=dummy
;;
*_setscene*)
# Skip stamps which are already setscene versions
-i=dummy
;;
+*)
+# For everything else: if suitable, promote the stamp to a setscene
+# version, otherwise remove it
+for j in ${SSTATETASKS} do_shared_workdir
+do
+case $i in
+*$j|*$j.*)
+mv $i `echo $i | sed -e "s#${j}#${j}_setscene#"`
+break
+;;
+esac
+done
+rm -f $i
esac
-
-for j in ${SSTATETASKS} do_shared_workdir
-do
-case $i in
-dummy)
-break
-;;
-*$j|*$j.*)
-# Promote the stamp to a setscene version
-mv $i `echo $i | sed -e "s#${j}#${j}_setscene#"`
-i=dummy
-break
-;;
-esac
-done
-
-rm -f $i
done
cd ${WORKDIR}
--
2.21.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] libevent: update packaging (one package per shared library)
libevent produces several libraries that might or might not
be used in the end. We can prevent those potentially unused
libraries from being pulled into a file-system by splitting
the individual shared libraries into individual packages.
Because this recipe only provides shared libraries which are
handled automatically by bitbake (shlibs), there is no need
to add the subpackages to the RDEPENDS of PN for backwards
compatibility. The packaging process of dependees will
simply pull in the sub-packages as runtime dependency as
needed.
This also how Debian splits this up.
While updating the packaging, we can also drop event_rpcgen.py
which appears to be a tool for generating rpc bindings, i.e.
something that should normally be in -dev. Given Debian
doesn't package this at all, and given it actually requires
python to run but no runtime dependency is stated at the
moment, it would appear that no users of this exist.
Signed-off-by: André Draszik
---
v2: keep SSL support turned-off by default
---
meta/recipes-support/libevent/libevent_2.1.11.bb | 8
1 file changed, 8 insertions(+)
diff --git a/meta/recipes-support/libevent/libevent_2.1.11.bb
b/meta/recipes-support/libevent/libevent_2.1.11.bb
index f005ab8bda..8c7c49e7dd 100644
--- a/meta/recipes-support/libevent/libevent_2.1.11.bb
+++ b/meta/recipes-support/libevent/libevent_2.1.11.bb
@@ -31,9 +31,17 @@ inherit ptest multilib_header
DEPENDS = "zlib"
+PACKAGES_DYNAMIC = "^${PN}-.*$"
+python split_libevent_libs () {
+do_split_packages(d, '${libdir}', r'^libevent_([a-z]*)-.*\.so\..*',
'${PN}-%s', '${SUMMARY} (%s)', prepend=True, allow_links=True)
+}
+PACKAGESPLITFUNCS_prepend = "split_libevent_libs "
+
BBCLASSEXTEND = "native nativesdk"
do_install_append() {
+ rm ${D}${bindir}/event_rpcgen.py
+ rmdir ${D}${bindir}
oe_multilib_header event2/event-config.h
}
--
2.23.0.rc1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libevent: enable OpenSSL unconditionally and update packaging
On Thu, 2019-11-07 at 14:08 +, Richard Purdie wrote: > On Thu, 2019-11-07 at 14:01 +, André Draszik wrote: > > On Thu, 2019-11-07 at 13:26 +0100, Alexander Kanavin wrote: > > > I would rather keep the option to disable openssl, but simply > > > switch it on by default > > > > Why complicate things, what's the use-case? If libevent_openssl.so is > > not > > used by anything, that library will not be pulled in, as it is a > > separate package now. > > Build time dependencies and hence build speed? > > It sounds trivial but all these inter-dependencies do mount up so if we > don't need it, keeping things minimal has advantages. > > If there is a security issue in openssl, its one more thing that would > have to be regenerated if a CVE fix were added too... What about helping make network connections more secure by enabling ssl by default? Is yocto really advocating the use of unencrypted connections? If build time is the argument, why is stack protection enabled by default in the compiler? Why do other packages have OpenSSL support enabled by default? I could go on, but I don't care enough, v2 sent :-) Cheers, Andre' -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH RFC CFH][sumo 00/47] CVE check backport
On 11/7/19 7:03 AM, Richard Purdie wrote: > On Wed, 2019-11-06 at 13:46 -0800, akuster808 wrote: >> On 11/6/19 7:37 AM, Mikko Rapeli wrote: >> QA resources have been a donation from Intel and Windriver above >> their membership fees. I don't fee right asking them to run QA. >>> patches aiming at yocto 2.5 sumo. If not, would be really nice if >>> someone could collect patches into sumo-next or sumo-contrib branch >>> where us >>> users could be in charge of all Quality Assurance. >> I have collected other patches for sumo and built them locally but I >> have no way to inform Richard they pass an AB builds or automated >> testing for them to get into mainline sumo. > Given the discussions around LTS and the fact we'd need to do > *something* with the autobuilder to help support it, I've been > experimenting. > > I created a sumo-next branch with a uninative update and Mikko's > patches and then managed to get it to build (and pass) on the > autobuilder. > > I did directly merge a bitbake fix to the 1.38 branch to avoid test > failures too. > > The autobuilder successfully builds a-full for sumo-next. Compared to a > normal build the differences are: > > * unsupported workers are removed from the pool for sumo so it only > builds on a subset of the infrastructure > * no buildperf tests > * there are no supported fedora workers left so no oe-selftest-fedora > * no ptest image execution (we never did this with sumo) > * no test result output (wasn't present in sumo and never backported) > > I'm prepared to merge sumo-next on the basis of these results and use > it as a model for how we could continue to get critical patches into > older releases. Are you taking the other patches also submitted for sumo ? - armin > More work would be needed to see if any older releases > could work. > > At this point the TSC needs to discuss LTS and what our branch policy > may be going forward but this does add useful data to that discussion > and may help influence those discussions. > > [For reference I did have to seek advice from upstream buildbot on how > to avoid a bug and its taken quite some experimenting to find the magic > to make this work. I did have to update the autobuilder-helper sumo > branch to be in sync too]. > > Cheers, > > Richard > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] oeqa: reproducible: Add option to capture bad packages
Adds an option that can be used to copy the offending packages to a temp
directory for later evaluation. This is useful on the Autobuilder to
investigate failures.
Signed-off-by: Joshua Watt
---
meta/lib/oeqa/selftest/cases/reproducible.py | 20
1 file changed, 20 insertions(+)
diff --git a/meta/lib/oeqa/selftest/cases/reproducible.py
b/meta/lib/oeqa/selftest/cases/reproducible.py
index c235c139ed1..a9110565a94 100644
--- a/meta/lib/oeqa/selftest/cases/reproducible.py
+++ b/meta/lib/oeqa/selftest/cases/reproducible.py
@@ -5,11 +5,16 @@
from oeqa.selftest.case import OESelftestTestCase
from oeqa.utils.commands import runCmd, bitbake, get_bb_var, get_bb_vars
+import bb.utils
import functools
import multiprocessing
import textwrap
import json
import unittest
+import tempfile
+import shutil
+import stat
+import os
MISSING = 'MISSING'
DIFFERENT = 'DIFFERENT'
@@ -74,6 +79,7 @@ def compare_file(reference, test, diffutils_sysroot):
class ReproducibleTests(OESelftestTestCase):
package_classes = ['deb', 'ipk']
images = ['core-image-minimal']
+save_results = False
def setUpLocal(self):
super().setUpLocal()
@@ -117,9 +123,18 @@ class ReproducibleTests(OESelftestTestCase):
self.extrasresults['reproducible']['files'].setdefault(package_class,
{})[name] = [
{'reference': p.reference, 'test': p.test} for p in packages]
+def copy_file(self, source, dest):
+bb.utils.mkdirhier(os.path.dirname(dest))
+shutil.copyfile(source, dest)
+
def test_reproducible_builds(self):
capture_vars = ['DEPLOY_DIR_' + c.upper() for c in
self.package_classes]
+if self.save_results:
+save_dir = tempfile.mkdtemp(prefix='oe-reproducible-')
+os.chmod(save_dir, stat.S_IRWXU | stat.S_IRGRP | stat.S_IXGRP |
stat.S_IROTH | stat.S_IXOTH)
+self.logger.info('Non-reproducible packages will be copied to %s',
save_dir)
+
# Build native utilities
self.write_config('')
bitbake("diffutils-native -c addto_recipe_sysroot")
@@ -176,6 +191,11 @@ class ReproducibleTests(OESelftestTestCase):
self.write_package_list(package_class, 'different',
result.different)
self.write_package_list(package_class, 'same', result.same)
+if self.save_results:
+for d in result.different:
+self.copy_file(d.reference, '/'.join([save_dir,
d.reference]))
+self.copy_file(d.test, '/'.join([save_dir, d.test]))
+
if result.missing or result.different:
self.fail("The following %s packages are missing or
different: %s" %
(c, ' '.join(r.test for r in (result.missing +
result.different
--
2.23.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH RFC CFH][sumo 00/47] CVE check backport
On Thu, 2019-11-07 at 07:55 -0800, akuster808 wrote: > > On 11/7/19 7:03 AM, Richard Purdie wrote: > > On Wed, 2019-11-06 at 13:46 -0800, akuster808 wrote: > > > On 11/6/19 7:37 AM, Mikko Rapeli wrote: > > > QA resources have been a donation from Intel and Windriver above > > > their membership fees. I don't fee right asking them to run QA. > > > > patches aiming at yocto 2.5 sumo. If not, would be really nice > > > > if > > > > someone could collect patches into sumo-next or sumo-contrib > > > > branch > > > > where us > > > > users could be in charge of all Quality Assurance. > > > I have collected other patches for sumo and built them locally > > > but I > > > have no way to inform Richard they pass an AB builds or > > > automated > > > testing for them to get into mainline sumo. > > Given the discussions around LTS and the fact we'd need to do > > *something* with the autobuilder to help support it, I've been > > experimenting. > > > > I created a sumo-next branch with a uninative update and Mikko's > > patches and then managed to get it to build (and pass) on the > > autobuilder. > > > > I did directly merge a bitbake fix to the 1.38 branch to avoid test > > failures too. > > > > The autobuilder successfully builds a-full for sumo-next. Compared > > to a > > normal build the differences are: > > > > * unsupported workers are removed from the pool for sumo so it > > only > > builds on a subset of the infrastructure > > * no buildperf tests > > * there are no supported fedora workers left so no oe-selftest- > > fedora > > * no ptest image execution (we never did this with sumo) > > * no test result output (wasn't present in sumo and never > > backported) > > > > I'm prepared to merge sumo-next on the basis of these results and > > use > > it as a model for how we could continue to get critical patches > > into > > older releases. > Are you taking the other patches also submitted for sumo ? I am worried about what the bigger picture for this looks like but we could try testing them. I think the TSC needs to discuss this. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] OpenEmbedded event at FOSDEM20
OpenEmbedded is considering creating a mini-conference attached to FOSDEM 2020 (https://fosdem.org/2020/), and we would like your help. Please fill out this short, 10 question, survey to determine the viability of such an effort. https://www.surveymonkey.com/r/9QP76CL Thank you, The OpenEmbedded Board -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] initscripts/sysfs.sh: Mount /sys/firmware/efi/efivars when possible
Without this change, efibootmgr is unable to recover BootOrder if lost during a previous write operation, e.g. exceeded storage capacity. This is problematic using EFI to manage boot flow from Linux (E.g. via RAUC). https://www.kernel.org/doc/Documentation/filesystems/efivarfs.txt Signed-off-by: Haris Okanovic --- meta/recipes-core/initscripts/initscripts-1.0/sysfs.sh | 4 1 file changed, 4 insertions(+) diff --git a/meta/recipes-core/initscripts/initscripts-1.0/sysfs.sh b/meta/recipes-core/initscripts/initscripts-1.0/sysfs.sh index f5b5b9904b..4871ee94e5 100644 --- a/meta/recipes-core/initscripts/initscripts-1.0/sysfs.sh +++ b/meta/recipes-core/initscripts/initscripts-1.0/sysfs.sh @@ -26,6 +26,10 @@ if [ -e /sys/kernel/config ] && grep -q configfs /proc/filesystems; then mount -t configfs configfs /sys/kernel/config fi +if [ -e /sys/firmware/efi/efivars ] && grep -q efivarfs /proc/filesystems; then + mount -t efivarfs efivarfs /sys/firmware/efi/efivars +fi + if ! [ -e /dev/zero ] && [ -e /dev ] && grep -q devtmpfs /proc/filesystems; then mount -n -t devtmpfs devtmpfs /dev fi -- 2.24.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] isoimage-isohybrid.py: Parameterize ESP label
Add "esp_label" plugin parameter so that caller may override default
ESP partition label 'EFIimg'.
Signed-off-by: Haris Okanovic
---
scripts/lib/wic/plugins/source/isoimage-isohybrid.py | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
b/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
index 24299c1ece..95a54a09d2 100644
--- a/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
+++ b/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
@@ -347,8 +347,10 @@ class IsoImagePlugin(SourcePlugin):
# dosfs image for EFI boot
bootimg = "%s/efi.img" % isodir
-dosfs_cmd = 'mkfs.vfat -n "EFIimg" -S 512 -C %s %d' \
-% (bootimg, blocks)
+esp_label = source_params.get('esp_label', 'EFIimg')
+
+dosfs_cmd = 'mkfs.vfat -n \'%s\' -S 512 -C %s %d' \
+% (esp_label, bootimg, blocks)
exec_native_cmd(dosfs_cmd, native_sysroot)
mmd_cmd = "mmd -i %s ::/EFI" % bootimg
--
2.24.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] isoimage-isohybrid.py: Parameterize ESP partition size
Add "esp_extra_blocks" plugin parameter so that caller may change
ESP's free space from the default 100 blocks.
Signed-off-by: Haris Okanovic
---
scripts/lib/wic/plugins/source/isoimage-isohybrid.py | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
b/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
index 95a54a09d2..11326a274b 100644
--- a/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
+++ b/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
@@ -336,11 +336,13 @@ class IsoImagePlugin(SourcePlugin):
(img_iso_dir, isodir)
exec_cmd(install_cmd)
else:
+# Default to 100 blocks of extra space for file system overhead
+esp_extra_blocks = int(source_params.get('esp_extra_blocks',
'100'))
+
du_cmd = "du -bks %s/EFI" % isodir
out = exec_cmd(du_cmd)
blocks = int(out.split()[0])
-# Add some extra space for file system overhead
-blocks += 100
+blocks += esp_extra_blocks
logger.debug("Added 100 extra blocks to %s to get to %d "
"total blocks", part.mountpoint, blocks)
--
2.24.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] buildhistory: fix "version went backwards" QA error message
On Wed, 2019-11-06 at 20:12 -0500, Denys Dmytriyenko wrote: > From: Denys Dmytriyenko > > Fix parentheses placement in the message from: > Package version for package X went backwards which would break package feeds > from (Y to Z) > to this one: > Package version for package X went backwards which would break package feeds > (from Y to Z) > > Signed-off-by: Denys Dmytriyenko I did really appreciate that you fixed the test in the commit, however the autobuilder disagrees: https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/470 :/. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] pseudo: Add statx support to fix fedora30 issues
Modern distros (e.g. fedora30) are starting to use the new statx() syscall
through
the newly exposed glibc wrapper function in software like coreutils (e.g. the ls
command). Add support to intercept this to pseudo.
Signed-off-by: Richard Purdie
---
.../pseudo/files/0001-Add-statx.patch | 107 ++
meta/recipes-devtools/pseudo/pseudo_git.bb| 1 +
2 files changed, 108 insertions(+)
create mode 100644 meta/recipes-devtools/pseudo/files/0001-Add-statx.patch
diff --git a/meta/recipes-devtools/pseudo/files/0001-Add-statx.patch
b/meta/recipes-devtools/pseudo/files/0001-Add-statx.patch
new file mode 100644
index 000..49abc2e0277
--- /dev/null
+++ b/meta/recipes-devtools/pseudo/files/0001-Add-statx.patch
@@ -0,0 +1,107 @@
+From 4e41a05de1f34ba00a68ca4f20fb49c4d1cbd2d0 Mon Sep 17 00:00:00 2001
+From: Richard Purdie
+Date: Wed, 6 Nov 2019 12:17:46 +
+Subject: [PATCH] Add statx glibc/syscall support
+
+Modern distros (e.g. fedora30) are starting to use the new statx() syscall
through
+the newly exposed glibc wrapper function in software like coreutils (e.g. the
ls
+command). Add support to intercept this to pseudo.
+
+Signed-off-by: Richard Purdie
+Upstream-Status: Submitted [Emailed to seebs]
+---
+ ports/linux/guts/statx.c | 48
+ ports/linux/portdefs.h | 1 +
+ ports/linux/wrapfuncs.in | 1 +
+ 3 files changed, 50 insertions(+)
+ create mode 100644 ports/linux/guts/statx.c
+
+diff --git a/ports/linux/statx/guts/statx.c b/ports/linux/statx/guts/statx.c
+new file mode 100644
+index 000..a3259c4
+--- /dev/null
b/ports/linux/statx/guts/statx.c
+@@ -0,0 +1,43 @@
++/*
++ * Copyright (c) 2019 Linux Foundation
++ * Author: Richard Purdie
++ *
++ * SPDX-License-Identifier: LGPL-2.1-only
++ *
++ * int
++ * statx(int dirfd, const char *pathname, int flags, unsigned int mask,
struct statx *statxbuf) {
++ * wrap___fxstat64(int ver, int fd, struct stat64 *buf) {
++ *int rc = -1;
++ */
++ pseudo_msg_t *msg;
++ PSEUDO_STATBUF buf;
++ int save_errno;
++
++ rc = real_statx(dirfd, pathname, flags, mask, statxbuf);
++ save_errno = errno;
++ if (rc == -1) {
++ return rc;
++ }
++
++ buf.st_uid = statxbuf->stx_uid;
++ buf.st_gid = statxbuf->stx_gid;
++ buf.st_dev = makedev(statxbuf->stx_dev_major, statxbuf->stx_dev_minor);
++ buf.st_ino = statxbuf->stx_ino;
++ buf.st_mode = statxbuf->stx_mode;
++ buf.st_rdev = makedev(statxbuf->stx_rdev_major,
statxbuf->stx_rdev_minor);
++ buf.st_nlink = statxbuf->stx_nlink;
++ msg = pseudo_client_op(OP_STAT, 0, -1, dirfd, pathname, &buf);
++ if (msg && msg->result == RESULT_SUCCEED) {
++ pseudo_debug(PDBGF_FILE, "statx(path %s), flags %o, stat rc %d,
stat uid %o\n", pathname, flags, rc, statxbuf->stx_uid);
++ statxbuf->stx_uid = msg->uid;
++ statxbuf->stx_gid = msg->gid;
++ statxbuf->stx_mode = msg->mode;
++ statxbuf->stx_rdev_major = major(msg->rdev);
++ statxbuf->stx_rdev_minor = minor(msg->rdev);
++ } else {
++ pseudo_debug(PDBGF_FILE, "statx(path %s) failed, flags %o, stat
rc %d, stat uid %o\n", pathname, flags, rc, statxbuf->stx_uid);
++ }
++ errno = save_errno;
++/*return rc;
++ * }
++ */
+diff --git a/ports/linux/statx/portdefs.h b/ports/linux/statx/portdefs.h
+new file mode 100644
+index 000..bf934dc
+--- /dev/null
b/ports/linux/statx/portdefs.h
+@@ -0,0 +1,6 @@
++/*
++ * SPDX-License-Identifier: LGPL-2.1-only
++ *
++ */
++#include
++#include
+diff --git a/ports/linux/statx/wrapfuncs.in b/ports/linux/statx/wrapfuncs.in
+new file mode 100644
+index 000..c9cd4c3
+--- /dev/null
b/ports/linux/statx/wrapfuncs.in
+@@ -0,0 +1 @@
++int statx(int dirfd, const char *pathname, int flags, unsigned int mask,
struct statx *statxbuf);
+diff --git a/ports/linux/subports b/ports/linux/subports
+index a29044a..49081bf 100755
+--- a/ports/linux/subports
b/ports/linux/subports
+@@ -54,3 +54,13 @@ else
+ fi
+ rm -f dummy.c dummy.o
+
++cat > dummy.c <
++struct statx x;
++EOF
++if ${CC} -c -o dummy.o dummy.c >/dev/null 2>&1; then
++ echo "linux/statx"
++fi
++rm -f dummy.c dummy.o
++
+--
+2.17.1
+
diff --git a/meta/recipes-devtools/pseudo/pseudo_git.bb
b/meta/recipes-devtools/pseudo/pseudo_git.bb
index 78500e1cc6d..1f2df4a427e 100644
--- a/meta/recipes-devtools/pseudo/pseudo_git.bb
+++ b/meta/recipes-devtools/pseudo/pseudo_git.bb
@@ -7,6 +7,7 @@ SRC_URI = "git://git.yoctoproject.org/pseudo \
file://moreretries.patch \
file://toomanyfiles.patch \
file://0001-maketables-wrappers-use-Python-3.patch \
+ file://0001-Add-statx.patch \
"
SRCREV = "060058bb29f70b244e685b3c704eb0641b736f73"
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
htt
[OE-core] [pseudo][PATCH] Add statx glibc/syscall support
Modern distros (e.g. fedora30) are starting to use the new statx() syscall
through
the newly exposed glibc wrapper function in software like coreutils (e.g. the ls
command). Add support to intercept this to pseudo.
Signed-off-by: Richard Purdie
---
ports/linux/guts/statx.c | 48
ports/linux/portdefs.h | 1 +
ports/linux/wrapfuncs.in | 1 +
3 files changed, 50 insertions(+)
create mode 100644 ports/linux/guts/statx.c
diff --git a/ports/linux/statx/guts/statx.c b/ports/linux/statx/guts/statx.c
new file mode 100644
index 000..a3259c4
--- /dev/null
+++ b/ports/linux/statx/guts/statx.c
@@ -0,0 +1,42 @@
+/*
+ * Copyright (c) 2019 Linux Foundation
+ * Author: Richard Purdie
+ *
+ * SPDX-License-Identifier: LGPL-2.1-only
+ *
+ * int
+ * statx(int dirfd, const char *pathname, int flags, unsigned int mask, struct
statx *statxbuf) {
+ * int rc = -1;
+ */
+ pseudo_msg_t *msg;
+ PSEUDO_STATBUF buf;
+ int save_errno;
+
+ rc = real_statx(dirfd, pathname, flags, mask, statxbuf);
+ save_errno = errno;
+ if (rc == -1) {
+ return rc;
+ }
+
+ buf.st_uid = statxbuf->stx_uid;
+ buf.st_gid = statxbuf->stx_gid;
+ buf.st_dev = makedev(statxbuf->stx_dev_major, statxbuf->stx_dev_minor);
+ buf.st_ino = statxbuf->stx_ino;
+ buf.st_mode = statxbuf->stx_mode;
+ buf.st_rdev = makedev(statxbuf->stx_rdev_major,
statxbuf->stx_rdev_minor);
+ buf.st_nlink = statxbuf->stx_nlink;
+ msg = pseudo_client_op(OP_STAT, 0, -1, dirfd, pathname, &buf);
+ if (msg && msg->result == RESULT_SUCCEED) {
+ pseudo_debug(PDBGF_FILE, "statx(path %s), flags %o, stat rc %d,
stat uid %o\n", pathname, flags, rc, statxbuf->stx_uid);
+ statxbuf->stx_uid = msg->uid;
+ statxbuf->stx_gid = msg->gid;
+ statxbuf->stx_mode = msg->mode;
+ statxbuf->stx_rdev_major = major(msg->rdev);
+ statxbuf->stx_rdev_minor = minor(msg->rdev);
+ } else {
+ pseudo_debug(PDBGF_FILE, "statx(path %s) failed, flags %o, stat
rc %d, stat uid %o\n", pathname, flags, rc, statxbuf->stx_uid);
+ }
+ errno = save_errno;
+/* return rc;
+ * }
+ */
diff --git a/ports/linux/statx/portdefs.h b/ports/linux/statx/portdefs.h
new file mode 100644
index 000..bf934dc
--- /dev/null
+++ b/ports/linux/statx/portdefs.h
@@ -0,0 +1,6 @@
+/*
+ * SPDX-License-Identifier: LGPL-2.1-only
+ *
+ */
+#include
+#include
diff --git a/ports/linux/statx/wrapfuncs.in b/ports/linux/statx/wrapfuncs.in
new file mode 100644
index 000..c9cd4c3
--- /dev/null
+++ b/ports/linux/statx/wrapfuncs.in
@@ -0,0 +1 @@
+int statx(int dirfd, const char *pathname, int flags, unsigned int mask,
struct statx *statxbuf);
diff --git a/ports/linux/subports b/ports/linux/subports
index a29044a..49081bf 100755
--- a/ports/linux/subports
+++ b/ports/linux/subports
@@ -54,3 +54,13 @@ else
fi
rm -f dummy.c dummy.o
+cat > dummy.c <
+struct statx x;
+EOF
+if ${CC} -c -o dummy.o dummy.c >/dev/null 2>&1; then
+ echo "linux/statx"
+fi
+rm -f dummy.c dummy.o
+
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] ✗ patchtest: failure for Add statx glibc/syscall support
== Series Details == Series: Add statx glibc/syscall support Revision: 1 URL : https://patchwork.openembedded.org/series/21022/ 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: * Issue Series does not apply on top of target branch [test_series_merge_on_head] Suggested fixRebase your series on top of targeted branch Targeted branch master (currently at ae6e7dd19b) * Patch[pseudo] Add statx glibc/syscall support 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
Re: [OE-core] [PATCH] pseudo: Add statx support to fix fedora30 issues
On Thu, 7 Nov 2019 20:04:44 + Richard Purdie wrote: > Modern distros (e.g. fedora30) are starting to use the new statx() > syscall through the newly exposed glibc wrapper function in software > like coreutils (e.g. the ls command). Add support to intercept this > to pseudo. I think this should be okay. If there's no real statx() wrapper, the real_statx() call probably fails, but also things probably won't have thought it existed/worked. Worth double-checking that things still run with this in place on a system that doesn't have a statx wrapper, when configuring and building things like coreutils that will check for it. -s -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] pseudo: Add statx support to fix fedora30 issues
On Thu, 2019-11-07 at 14:34 -0600, Seebs wrote: > On Thu, 7 Nov 2019 20:04:44 + > Richard Purdie wrote: > > > Modern distros (e.g. fedora30) are starting to use the new statx() > > syscall through the newly exposed glibc wrapper function in > > software > > like coreutils (e.g. the ls command). Add support to intercept this > > to pseudo. > > I think this should be okay. If there's no real statx() wrapper, the > real_statx() call probably fails, but also things probably won't have > thought it existed/worked. That was my thinking... > Worth double-checking that things still run with this in place on a > system that doesn't have a statx wrapper, when configuring and > building things like coreutils that will check for it. coreutils looks to be using a standard configure check for the statx function. Even in OE, we'd not want to configure/compile with pseudo loaded and active so I think we should be ok... Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/3] glibc: move ldconfig to its own package
Only recommend its installation, if it's enabled in distro features.
Signed-off-by: Andreas Oberritter
---
meta/recipes-core/glibc/glibc-package.inc | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/meta/recipes-core/glibc/glibc-package.inc
b/meta/recipes-core/glibc/glibc-package.inc
index d7037c5cce..9dd5a0d403 100644
--- a/meta/recipes-core/glibc/glibc-package.inc
+++ b/meta/recipes-core/glibc/glibc-package.inc
@@ -1,6 +1,6 @@
INHIBIT_SYSROOT_STRIP = "1"
-PACKAGES = "${PN}-dbg catchsegv sln nscd ldd tzcode glibc-thread-db ${PN}-pic
libcidn libmemusage libnss-db libsegfault ${PN}-pcprofile libsotruss ${PN}
${PN}-utils glibc-extra-nss ${PN}-dev ${PN}-staticdev ${PN}-doc"
+PACKAGES = "${PN}-dbg catchsegv sln nscd ldd tzcode glibc-thread-db ${PN}-pic
libcidn libmemusage libnss-db libsegfault ${PN}-pcprofile libsotruss ${PN}
${PN}-utils glibc-extra-nss ${PN}-dev ${PN}-staticdev ${PN}-doc ldconfig"
# The ld.so in this glibc supports the GNU_HASH
RPROVIDES_${PN} = "eglibc rtld(GNU_HASH)"
@@ -23,7 +23,9 @@ ARCH_DYNAMIC_LOADER_aarch64 = "ld-linux-${TARGET_ARCH}.so.1"
libc_baselibs_append = " ${@oe.utils.conditional('ARCH_DYNAMIC_LOADER', '',
'', '${root_prefix}/lib/${ARCH_DYNAMIC_LOADER}', d)}"
INSANE_SKIP_${PN}_append_aarch64 = " libdir"
-FILES_${PN} = "${libc_baselibs} ${libexecdir}/* ${base_sbindir}/ldconfig
${sysconfdir}/ld.so.conf"
+FILES_${PN} = "${libc_baselibs} ${libexecdir}/*"
+RRECOMMENDS_${PN} = "${@bb.utils.filter('DISTRO_FEATURES', 'ldconfig', d)}"
+FILES_ldconfig = "${base_sbindir}/ldconfig ${sysconfdir}/ld.so.conf"
FILES_ldd = "${bindir}/ldd"
FILES_libsegfault = "${base_libdir}/libSegFault*"
FILES_libcidn = "${base_libdir}/libcidn-*.so ${base_libdir}/libcidn.so.*"
@@ -107,11 +109,6 @@ do_install_append () {
}
do_install_append_class-target() {
- if ! ${@bb.utils.contains('DISTRO_FEATURES', 'ldconfig', 'true',
'false', d)}; then
- # The distro doesn't want these files so let's not install them
- rm -f ${D}${sysconfdir}/ld.so.conf
- rm -f ${D}${base_sbindir}/ldconfig
- fi
if ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'true', 'false',
d)}; then
install -d ${D}${sysconfdir}/tmpfiles.d
echo "d /run/nscd 755 root root -" \
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/3] package.bbclass: Always include ldconfig fragment
Now that ldconfig may get installed from a feed, use it when it's
available on the target.
Signed-off-by: Andreas Oberritter
---
meta/classes/package.bbclass | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index f955df..e0d6ff6701 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -1731,8 +1731,6 @@ python package_do_shlibs() {
else:
snap_symlinks = False
-use_ldconfig = bb.utils.contains('DISTRO_FEATURES', 'ldconfig', True,
False, d)
-
needed = {}
shlib_provider = oe.package.read_shlib_providers(d)
@@ -1791,7 +1789,7 @@ python package_do_shlibs() {
if s[0] not in shlib_provider:
shlib_provider[s[0]] = {}
shlib_provider[s[0]][s[1]] = (pkg, pkgver)
-if needs_ldconfig and use_ldconfig:
+if needs_ldconfig:
bb.debug(1, 'adding ldconfig call to postinst for %s' % pkg)
postinst = d.getVar('pkg_postinst_%s' % pkg)
if not postinst:
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/3] systemd: Add runtime dependency on new ldconfig package
Signed-off-by: Andreas Oberritter --- meta/recipes-core/systemd/systemd_243.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-core/systemd/systemd_243.bb b/meta/recipes-core/systemd/systemd_243.bb index 6e7f95693b..54fcc6a5d1 100644 --- a/meta/recipes-core/systemd/systemd_243.bb +++ b/meta/recipes-core/systemd/systemd_243.bb @@ -139,7 +139,7 @@ PACKAGECONFIG[importd] = "-Dimportd=true,-Dimportd=false" PACKAGECONFIG[iptc] = "-Dlibiptc=true,-Dlibiptc=false,iptables" PACKAGECONFIG[journal-upload] = "-Dlibcurl=true,-Dlibcurl=false,curl" PACKAGECONFIG[kmod] = "-Dkmod=true,-Dkmod=false,kmod" -PACKAGECONFIG[ldconfig] = "-Dldconfig=true,-Dldconfig=false" +PACKAGECONFIG[ldconfig] = "-Dldconfig=true,-Dldconfig=false,,ldconfig" PACKAGECONFIG[libidn] = "-Dlibidn=true,-Dlibidn=false,libidn" PACKAGECONFIG[localed] = "-Dlocaled=true,-Dlocaled=false" PACKAGECONFIG[logind] = "-Dlogind=true,-Dlogind=false" -- 2.17.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libevent: enable OpenSSL unconditionally and update packaging
On Thu, 2019-11-07 at 15:41 +, André Draszik wrote: > On Thu, 2019-11-07 at 14:08 +, Richard Purdie wrote: > > On Thu, 2019-11-07 at 14:01 +, André Draszik wrote: > > > On Thu, 2019-11-07 at 13:26 +0100, Alexander Kanavin wrote: > > > > I would rather keep the option to disable openssl, but simply > > > > switch it on by default > > > > > > Why complicate things, what's the use-case? If > > > libevent_openssl.so is > > > not > > > used by anything, that library will not be pulled in, as it is a > > > separate package now. > > > > Build time dependencies and hence build speed? > > > > It sounds trivial but all these inter-dependencies do mount up so > > if we > > don't need it, keeping things minimal has advantages. > > > > If there is a security issue in openssl, its one more thing that > > would > > have to be regenerated if a CVE fix were added too... > > What about helping make network connections more secure by enabling > ssl by default? Is yocto really advocating the use of unencrypted > connections? No. Information like that about impact would help sway this discussion and should probably be in the commit message. Its a question of why as well as what and how. > If build time is the argument, why is stack protection enabled by > default in the compiler? > Why do other packages have OpenSSL support enabled by default? > > I could go on, but I don't care enough, v2 sent :-) It is important, I suspect the commit message needs more info to help ensure we make informed decisions... Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] gnupg: Split gpg and gpg-agent into a minimal gnupg-gpg package
Add minimal "gnupg-gpg" package containing just enough binaries to run
gpg and gpg-agent. Add dependency in normal "gnupg" package to preserve
old behavior.
Some applications like opkg don't need all functionality provided by
normal gnupg installations. This minimal package provides just enough
functionality to verify and manage keys in opkg, in order to minimize
disk overhead.
Signed-off-by: Haris Okanovic
---
meta/recipes-support/gnupg/gnupg_2.2.17.bb | 15 +++
1 file changed, 15 insertions(+)
diff --git a/meta/recipes-support/gnupg/gnupg_2.2.17.bb
b/meta/recipes-support/gnupg/gnupg_2.2.17.bb
index 689cf8a75e..ab19a1ad11 100644
--- a/meta/recipes-support/gnupg/gnupg_2.2.17.bb
+++ b/meta/recipes-support/gnupg/gnupg_2.2.17.bb
@@ -29,6 +29,21 @@ EXTRA_OECONF = "--disable-ldap \
--with-readline=${STAGING_LIBDIR}/.. \
--enable-gpg-is-gpg2 \
"
+
+# A minimal package containing just enough to run gpg+gpgagent (E.g. use gpgme
in opkg)
+PACKAGES =+ "${PN}-gpg"
+FILES_${PN}-gpg = " \
+ ${bindir}/gpg \
+ ${bindir}/gpg2 \
+ ${bindir}/gpg-agent \
+"
+
+# Normal package (gnupg) should depend on minimal package (gnupg-gpg)
+# to ensure all tools are included. This is done only in non-native
+# builds. Native builds don't have sub-packages, so appending RDEPENDS
+# in this case breaks recipe parsing.
+RDEPENDS_${PN} += "${@ "" if ("native" in d.getVar("PN")) else (d.getVar("PN")
+ "-gpg")}"
+
RRECOMMENDS_${PN} = "pinentry"
do_configure_prepend () {
--
2.24.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] opkg: RDEPEND "gnupg-gpg" instead of "gnupg"
gnupg-gpg is a minimal installation of gnupg with enough functionality
to verify signatures and manage keys. Use this package instead of full
gnupg to slim down opkg installations with "--enable-gpg".
Signed-off-by: Haris Okanovic
---
meta/recipes-devtools/opkg/opkg_0.4.1.bb | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/opkg/opkg_0.4.1.bb
b/meta/recipes-devtools/opkg/opkg_0.4.1.bb
index 104f07fda8..149ee3ca19 100644
--- a/meta/recipes-devtools/opkg/opkg_0.4.1.bb
+++ b/meta/recipes-devtools/opkg/opkg_0.4.1.bb
@@ -32,7 +32,10 @@ OPKGLIBDIR ??= "${target_localstatedir}/lib"
PACKAGECONFIG ??= "libsolv"
-PACKAGECONFIG[gpg] = "--enable-gpg,--disable-gpg,gpgme libgpg-error,gnupg"
+PACKAGECONFIG[gpg] = "--enable-gpg,--disable-gpg,\
+gnupg gpgme libgpg-error,\
+${@ "gnupg" if ("native" in d.getVar("PN")) else "gnupg-gpg"}\
+"
PACKAGECONFIG[curl] = "--enable-curl,--disable-curl,curl"
PACKAGECONFIG[ssl-curl] = "--enable-ssl-curl,--disable-ssl-curl,curl openssl"
PACKAGECONFIG[openssl] = "--enable-openssl,--disable-openssl,openssl"
--
2.24.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] gnupg/libksba/npth/pinentry: Add nativesdk to BBCLASSEXTEND
Enable nativesdk builds of gnupg and it's dependencies (libksba, npth,
and pinentry) to fix builds of nativesdk-opkg.
This is necessary on distribution which enable gpg signature
verification in opkg and also build SDK images that include opkg.
Signed-off-by: Haris Okanovic
---
meta/recipes-support/gnupg/gnupg_2.2.17.bb | 2 +-
meta/recipes-support/libksba/libksba_1.3.5.bb | 2 +-
meta/recipes-support/npth/npth_1.6.bb | 2 +-
meta/recipes-support/pinentry/pinentry_1.1.0.bb | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-support/gnupg/gnupg_2.2.17.bb
b/meta/recipes-support/gnupg/gnupg_2.2.17.bb
index ab19a1ad11..bb8885f1c8 100644
--- a/meta/recipes-support/gnupg/gnupg_2.2.17.bb
+++ b/meta/recipes-support/gnupg/gnupg_2.2.17.bb
@@ -70,4 +70,4 @@ PACKAGECONFIG ??= "gnutls"
PACKAGECONFIG[gnutls] = "--enable-gnutls, --disable-gnutls, gnutls"
PACKAGECONFIG[sqlite3] = "--enable-sqlite, --disable-sqlite, sqlite3"
-BBCLASSEXTEND = "native"
+BBCLASSEXTEND = "native nativesdk"
diff --git a/meta/recipes-support/libksba/libksba_1.3.5.bb
b/meta/recipes-support/libksba/libksba_1.3.5.bb
index 4deda1843f..336d7f8177 100644
--- a/meta/recipes-support/libksba/libksba_1.3.5.bb
+++ b/meta/recipes-support/libksba/libksba_1.3.5.bb
@@ -27,4 +27,4 @@ do_configure_prepend () {
rm -f ${S}/m4/gpg-error.m4
}
-BBCLASSEXTEND = "native"
+BBCLASSEXTEND = "native nativesdk"
diff --git a/meta/recipes-support/npth/npth_1.6.bb
b/meta/recipes-support/npth/npth_1.6.bb
index 8310efb106..233e0dc4a4 100644
--- a/meta/recipes-support/npth/npth_1.6.bb
+++ b/meta/recipes-support/npth/npth_1.6.bb
@@ -24,4 +24,4 @@ do_install_append() {
oe_multilib_header npth.h
}
-BBCLASSEXTEND = "native"
+BBCLASSEXTEND = "native nativesdk"
diff --git a/meta/recipes-support/pinentry/pinentry_1.1.0.bb
b/meta/recipes-support/pinentry/pinentry_1.1.0.bb
index fb529d25d6..8c500dcadc 100644
--- a/meta/recipes-support/pinentry/pinentry_1.1.0.bb
+++ b/meta/recipes-support/pinentry/pinentry_1.1.0.bb
@@ -35,4 +35,4 @@ EXTRA_OECONF = " \
--disable-rpath \
"
-BBCLASSEXTEND = "native"
+BBCLASSEXTEND = "native nativesdk"
--
2.24.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] meta/lib/oe/package_manager.py: Enable sha256 checksums in opkg indexer
Pass `--checksum md5` and `--checksum sha256` to opkg-make-index.
Sha256 checksum enables more reliable install-time validation of IPKs.
This is particularly useful when installing from signed feeds --
I.e. feeds using signed Packages index files that deliver otherwise
unsigned IPKs. Such feeds rely on hash validation of enclosed IPKs to
thwart tampering. After download, opkg verifies IPK's checksum against
the (signed) Packages index file. Weak hashes like md5 are prone to
collision and therefore tampering.
The md5 checksum is purely for backward compatibility. Sha256 validation
was recently added to opkg. Newer builds of opkg will use it. Older
builds still look for an md5 checksum. Md5 is deprecated and should be
removed once old build are phased out.
Testing: I ran `bitbake package-index` after building a few IPKs and
verified MD5Sum and SHA256sum attributes are present in Packages.
Using opkg-utils 0.4.0.
Performance Impact: It takes about 40 seconds to cleanly re-index 8000
IPKs on an Intel Xeon E5-1620 machine. This was previously about
20 seconds.
NOTE: It's recommended to delete all Packages* files after applying this
patch. Otherwise, some IPKs won't have sha256.
Signed-off-by: Haris Okanovic
---
meta/lib/oe/package_manager.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/lib/oe/package_manager.py b/meta/lib/oe/package_manager.py
index c7135ce918..4ff19cf09c 100644
--- a/meta/lib/oe/package_manager.py
+++ b/meta/lib/oe/package_manager.py
@@ -217,7 +217,7 @@ class OpkgIndexer(Indexer):
if not os.path.exists(pkgs_file):
open(pkgs_file, "w").close()
-index_cmds.add('%s -r %s -p %s -m %s' %
+index_cmds.add('%s --checksum md5 --checksum sha256 -r %s -p
%s -m %s' %
(opkg_index_cmd, pkgs_file, pkgs_file,
pkgs_dir))
index_sign_files.add(pkgs_file)
--
2.24.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] dhcp: Workaround busybox limitation in Linux dhclient-script
Busybox's implementation of chown and chmod doesn't provide a
"--reference" option used in the latest version of dhclient-script.
This change works around that limitation by using stat to read
ownership and permissions flags and simple chown/chmod calls
supported in both coreutils and busybox.
Patch submitted upstream to ISC, tracked as bug 48771.
Signed-off-by: Haris Okanovic
---
...-limitation-in-linux-dhclient-script.patch | 64 +++
meta/recipes-connectivity/dhcp/dhcp_4.4.1.bb | 1 +
2 files changed, 65 insertions(+)
create mode 100644
meta/recipes-connectivity/dhcp/dhcp/0001-workaround-busybox-limitation-in-linux-dhclient-script.patch
diff --git
a/meta/recipes-connectivity/dhcp/dhcp/0001-workaround-busybox-limitation-in-linux-dhclient-script.patch
b/meta/recipes-connectivity/dhcp/dhcp/0001-workaround-busybox-limitation-in-linux-dhclient-script.patch
new file mode 100644
index 00..fa07c5ad5e
--- /dev/null
+++
b/meta/recipes-connectivity/dhcp/dhcp/0001-workaround-busybox-limitation-in-linux-dhclient-script.patch
@@ -0,0 +1,64 @@
+From eec0503cfc36f63d777f5cb3f2719cecedcb8468 Mon Sep 17 00:00:00 2001
+From: Haris Okanovic
+Date: Mon, 7 Jan 2019 13:22:09 -0600
+Subject: [PATCH] Workaround busybox limitation in Linux dhclient-script
+
+Busybox is a lightweight implementation of coreutils commonly used on
+space-constrained embedded Linux distributions. It's implementation of
+chown and chmod doesn't provide a "--reference" option added to
+client/scripts/linux as of commit 9261cb14. This change works around
+that limitation by using stat to read ownership and permissions flags
+and simple chown/chmod calls supported in both coreutils and busybox.
+
+ modified: client/scripts/linux
+
+Upstream-Status: Pending [ISC-Bugs #48771]
+---
+ client/scripts/linux | 17 +
+ 1 file changed, 13 insertions(+), 4 deletions(-)
+
+diff --git a/client/scripts/linux b/client/scripts/linux
+index 0c429697..2435a44b 100755
+--- a/client/scripts/linux
b/client/scripts/linux
+@@ -32,6 +32,17 @@
+ # if your system holds ip tool in a non-standard location.
+ ip=/sbin/ip
+
++chown_chmod_by_reference() {
++local reference_file="$1"
++local target_file="$2"
++
++local owner=$(stat -c "%u:%g" "$reference_file")
++local perm=$(stat -c "%a" "$reference_file")
++
++chown "$owner" "$target_file"
++chmod "$perm" "$target_file"
++}
++
+ # update /etc/resolv.conf based on received values
+ # This updated version mostly follows Debian script by Andrew Pollock et al.
+ make_resolv_conf() {
+@@ -74,8 +85,7 @@ make_resolv_conf() {
+ fi
+
+ if [ -f /etc/resolv.conf ]; then
+- chown --reference=/etc/resolv.conf $new_resolv_conf
+- chmod --reference=/etc/resolv.conf $new_resolv_conf
++ chown_chmod_by_reference /etc/resolv.conf $new_resolv_conf
+ fi
+ mv -f $new_resolv_conf /etc/resolv.conf
+ # DHCPv6
+@@ -101,8 +111,7 @@ make_resolv_conf() {
+ fi
+
+ if [ -f /etc/resolv.conf ]; then
+-chown --reference=/etc/resolv.conf $new_resolv_conf
+-chmod --reference=/etc/resolv.conf $new_resolv_conf
++ chown_chmod_by_reference /etc/resolv.conf $new_resolv_conf
+ fi
+ mv -f $new_resolv_conf /etc/resolv.conf
+ fi
+--
+2.20.0
+
diff --git a/meta/recipes-connectivity/dhcp/dhcp_4.4.1.bb
b/meta/recipes-connectivity/dhcp/dhcp_4.4.1.bb
index 275961a603..020777b8f2 100644
--- a/meta/recipes-connectivity/dhcp/dhcp_4.4.1.bb
+++ b/meta/recipes-connectivity/dhcp/dhcp_4.4.1.bb
@@ -11,6 +11,7 @@ SRC_URI +=
"file://0001-define-macro-_PATH_DHCPD_CONF-and-_PATH_DHCLIENT_CON.pat
file://0013-fixup_use_libbind.patch \
file://0001-master-Added-includes-of-new-BIND9-compatibility-hea.patch \
file://0001-Fix-a-NSUPDATE-compiling-issue.patch \
+
file://0001-workaround-busybox-limitation-in-linux-dhclient-script.patch \
"
SRC_URI[md5sum] = "18c7f4dcbb0a63df25098216d47b1ede"
--
2.24.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] ✗ patchtest: failure for dhcp: Workaround busybox limitation in Linux dhclient-script
== Series Details == Series: dhcp: Workaround busybox limitation in Linux dhclient-script Revision: 1 URL : https://patchwork.openembedded.org/series/21031/ 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: * Issue A patch file has been added, but does not have a Signed-off-by tag [test_signed_off_by_presence] Suggested fixSign off the added patch file (meta/recipes-connectivity/dhcp/dhcp/0001-workaround-busybox-limitation-in-linux-dhclient-script.patch) 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] [PATCH] systemd: Fix invalid argument of pstore log entry
Fix "systemd-pstore: Failed to log pstore entry: Invalid argument"
by backporting 1b3156edd291e0882d80a695d035dd30521345d1 from upstream.
Signed-off-by: Yongxin Liu
---
.../systemd/0001-pstore-fix-use-after-free.patch | 39 ++
meta/recipes-core/systemd/systemd_243.bb | 1 +
2 files changed, 40 insertions(+)
create mode 100644
meta/recipes-core/systemd/systemd/0001-pstore-fix-use-after-free.patch
diff --git
a/meta/recipes-core/systemd/systemd/0001-pstore-fix-use-after-free.patch
b/meta/recipes-core/systemd/systemd/0001-pstore-fix-use-after-free.patch
new file mode 100644
index 00..fd147a18be
--- /dev/null
+++ b/meta/recipes-core/systemd/systemd/0001-pstore-fix-use-after-free.patch
@@ -0,0 +1,39 @@
+From 1b3156edd291e0882d80a695d035dd30521345d1 Mon Sep 17 00:00:00 2001
+From: Michael Olbrich
+Date: Fri, 6 Sep 2019 15:04:01 +0200
+Subject: [PATCH] pstore: fix use after free
+
+The memory is still needed in the sd_journal_sendv() after the 'if' block.
+
+(cherry picked from commit 1e19f5ac0d680a63eccae7ef1fc6ce225dca0bbf)
+
+Upstream-Status: Backport
+
+Signed-off-by: Yongxin Liu
+---
+ src/pstore/pstore.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/pstore/pstore.c b/src/pstore/pstore.c
+index c760b3e899..8ffe523830 100644
+--- a/src/pstore/pstore.c
b/src/pstore/pstore.c
+@@ -117,6 +117,7 @@ static int compare_pstore_entries(const void *_a, const
void *_b) {
+
+ static int move_file(PStoreEntry *pe, const char *subdir) {
+ _cleanup_free_ char *ifd_path = NULL, *ofd_path = NULL;
++_cleanup_free_ void *field = NULL;
+ const char *suffix, *message;
+ struct iovec iovec[2];
+ int n_iovec = 0, r;
+@@ -138,7 +139,6 @@ static int move_file(PStoreEntry *pe, const char *subdir) {
+ iovec[n_iovec++] = IOVEC_MAKE_STRING(message);
+
+ if (pe->content_size > 0) {
+-_cleanup_free_ void *field = NULL;
+ size_t field_size;
+
+ field_size = strlen("FILE=") + pe->content_size;
+--
+2.14.4
+
diff --git a/meta/recipes-core/systemd/systemd_243.bb
b/meta/recipes-core/systemd/systemd_243.bb
index 6e7f95693b..88069546a2 100644
--- a/meta/recipes-core/systemd/systemd_243.bb
+++ b/meta/recipes-core/systemd/systemd_243.bb
@@ -24,6 +24,7 @@ SRC_URI += "file://touchscreen.rules \
file://0005-rules-watch-metadata-changes-in-ide-devices.patch \
file://0001-unit-file.c-consider-symlink-on-filesystems-like-NFS.patch \
file://99-default.preset \
+ file://0001-pstore-fix-use-after-free.patch \
"
# patches needed by musl
--
2.14.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] eSDK w/o buildtools
This allows the eSDK w/o integrated builtools. Enabled with: SDK_INCLUDE_BUILDTOOLS = '0' qemux86-64 - core-image-minimal - eSDK sizes Regular eSDK - 838 MB Minimal eSDK - 34 MB Min w/o bts - 11 MB So it's a fairly significant drop in download size for the eSDK. Mark Hatle (1): populate_sdk_ext.bbclass: Make integrated buildtools optional meta/classes/populate_sdk_ext.bbclass | 41 ++- 1 file changed, 27 insertions(+), 14 deletions(-) -- 2.17.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] populate_sdk_ext.bbclass: Make integrated buildtools optional
If the host system is expected to have enough capabilities that the
buildtools-tarball is not required, we don't need to bundle it.
This can save some significant space, especially when using with a minimal
eSDK.
minimal eSDK - core-image-minimal-qemux86-64
with buildtools-tarball - 34 MB installer - 281 MB installed
without buildtoools-tarball - 11 MB installer - 48 MB installed
Signed-off-by: Mark Hatle
---
meta/classes/populate_sdk_ext.bbclass | 41 ++-
1 file changed, 27 insertions(+), 14 deletions(-)
diff --git a/meta/classes/populate_sdk_ext.bbclass
b/meta/classes/populate_sdk_ext.bbclass
index 9fda1c9e78..05cfc1cc15 100644
--- a/meta/classes/populate_sdk_ext.bbclass
+++ b/meta/classes/populate_sdk_ext.bbclass
@@ -21,6 +21,7 @@ SDK_EXT_TYPE ?= "full"
SDK_INCLUDE_PKGDATA ?= "0"
SDK_INCLUDE_TOOLCHAIN ?= "${@'1' if d.getVar('SDK_EXT_TYPE') == 'full' else
'0'}"
SDK_INCLUDE_NATIVESDK ?= "0"
+SDK_INCLUDE_BUILDTOOLS ?= '1'
SDK_RECRDEP_TASKS ?= ""
@@ -94,6 +95,7 @@ python write_target_sdk_ext_manifest () {
real_target_multimach = d.getVar('REAL_MULTIMACH_TARGET_SYS')
pkgs = {}
+os.makedirs(os.path.dirname(d.getVar('SDK_EXT_TARGET_MANIFEST')),
exist_ok=True)
with open(d.getVar('SDK_EXT_TARGET_MANIFEST'), 'w') as f:
for fn in extra_info['filesizes']:
info = fn.split(':')
@@ -535,8 +537,12 @@ def get_sdk_required_utilities(buildtools_fn, d):
sanity_required_utilities = (d.getVar('SANITY_REQUIRED_UTILITIES') or
'').split()
sanity_required_utilities.append(d.expand('${BUILD_PREFIX}gcc'))
sanity_required_utilities.append(d.expand('${BUILD_PREFIX}g++'))
-buildtools_installer = os.path.join(d.getVar('SDK_DEPLOY'), buildtools_fn)
-filelist, _ = bb.process.run('%s -l' % buildtools_installer)
+if buildtools_fn:
+buildtools_installer = os.path.join(d.getVar('SDK_DEPLOY'),
buildtools_fn)
+filelist, _ = bb.process.run('%s -l' % buildtools_installer)
+else:
+buildtools_installer = None
+filelist = ""
localdata = bb.data.createCopy(d)
localdata.setVar('SDKPATH', '.')
sdkpathnative = localdata.getVar('SDKPATHNATIVE')
@@ -579,7 +585,9 @@ install_tools() {
touch ${SDK_OUTPUT}/${SDKPATH}/.devtoolbase
# find latest buildtools-tarball and install it
- install ${SDK_DEPLOY}/${SDK_BUILDTOOLS_INSTALLER}
${SDK_OUTPUT}/${SDKPATH}
+ if [ -n "${SDK_BUILDTOOLS_INSTALLER}" ]; then
+ install ${SDK_DEPLOY}/${SDK_BUILDTOOLS_INSTALLER}
${SDK_OUTPUT}/${SDKPATH}
+ fi
install -m 0644 ${COREBASE}/meta/files/ext-sdk-prepare.py
${SDK_OUTPUT}/${SDKPATH}
}
@@ -629,16 +637,18 @@ sdk_ext_postinst() {
printf "\nExtracting buildtools...\n"
cd $target_sdk_dir
env_setup_script="$target_sdk_dir/environment-setup-${REAL_MULTIMACH_TARGET_SYS}"
- printf "buildtools\ny" | ./${SDK_BUILDTOOLS_INSTALLER} > buildtools.log
|| { printf 'ERROR: buildtools installation failed:\n' ; cat buildtools.log ;
echo "printf 'ERROR: this SDK was not fully installed and needs
reinstalling\n'" >> $env_setup_script ; exit 1 ; }
+if [ -n "${SDK_BUILDTOOLS_INSTALLER}" ]; then
+ printf "buildtools\ny" | ./${SDK_BUILDTOOLS_INSTALLER} >
buildtools.log || { printf 'ERROR: buildtools installation failed:\n' ; cat
buildtools.log ; echo "printf 'ERROR: this SDK was not fully installed and
needs reinstalling\n'" >> $env_setup_script ; exit 1 ; }
- # Delete the buildtools tar file since it won't be used again
- rm -f ./${SDK_BUILDTOOLS_INSTALLER}
- # We don't need the log either since it succeeded
- rm -f buildtools.log
+ # Delete the buildtools tar file since it won't be used again
+ rm -f ./${SDK_BUILDTOOLS_INSTALLER}
+ # We don't need the log either since it succeeded
+ rm -f buildtools.log
- # Make sure when the user sets up the environment, they also get
- # the buildtools-tarball tools in their path.
- echo ". $target_sdk_dir/buildtools/environment-setup*" >>
$env_setup_script
+ # Make sure when the user sets up the environment, they also get
+ # the buildtools-tarball tools in their path.
+ echo ". $target_sdk_dir/buildtools/environment-setup*" >>
$env_setup_script
+ fi
# Allow bitbake environment setup to be ran as part of this sdk.
echo "export OE_SKIP_SDK_CHECK=1" >> $env_setup_script
@@ -654,7 +664,7 @@ sdk_ext_postinst() {
# Warn if trying to use external bitbake and the ext SDK together
echo "(which bitbake > /dev/null 2>&1 && echo 'WARNING: attempting to
use the extensible SDK in an environment set up to run bitbake - this may lead
to unexpected results. Please source this script in a new shell session
instead.') || true" >> $env_setup_script
- if [ "$prepare_buildsystem" != "no" ]; then
+ if
[OE-core] [PATCH 4/5] cve-check: we don't actually need to unpack to check
The patch scanner works with patch files in the layer, not in the workdir, so it
doesn't need to unpack.
Signed-off-by: Ross Burton
---
meta/classes/cve-check.bbclass | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index 1c8b2223a20..3326944d791 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -62,7 +62,7 @@ python do_cve_check () {
}
-addtask cve_check after do_unpack before do_build
+addtask cve_check before do_build
do_cve_check[depends] = "cve-update-db-native:do_populate_cve_db"
do_cve_check[nostamp] = "1"
@@ -70,7 +70,6 @@ python cve_check_cleanup () {
"""
Delete the file used to gather all the CVE information.
"""
-
bb.utils.remove(e.data.getVar("CVE_CHECK_TMP_FILE"))
}
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/5] acpica: upgrade to 20191018
The upstream tarballs now have a unified source license of Intel|BSD|GPLv2 and
the old BSD|GPLv2 tarballs are deprecated.
Add the Intel license to the license collection, update the LICENSE field, and
update the license checksum to actually point at a license fragment.
Signed-off-by: Ross Burton
---
meta/files/common-licenses/Intel | 105 ++
...{acpica_20190816.bb => acpica_20191018.bb} | 12 +-
2 files changed, 111 insertions(+), 6 deletions(-)
create mode 100644 meta/files/common-licenses/Intel
rename meta/recipes-extended/acpica/{acpica_20190816.bb => acpica_20191018.bb}
(75%)
diff --git a/meta/files/common-licenses/Intel b/meta/files/common-licenses/Intel
new file mode 100644
index 000..29ddf57a8c2
--- /dev/null
+++ b/meta/files/common-licenses/Intel
@@ -0,0 +1,105 @@
+1. Copyright Notice
+
+Some or all of this work - Copyright (c) 1999 - 2017, Intel Corp.
+All rights reserved.
+
+2. License
+
+2.1. This is your license from Intel Corp. under its intellectual property
+rights. You may have additional license terms from the party that provided
+you this software, covering your right to use that party's intellectual
+property rights.
+
+2.2. Intel grants, free of charge, to any person ("Licensee") obtaining a
+copy of the source code appearing in this file ("Covered Code") an
+irrevocable, perpetual, worldwide license under Intel's copyrights in the
+base code distributed originally by Intel ("Original Intel Code") to copy,
+make derivatives, distribute, use and display any portion of the Covered
+Code in any form, with the right to sublicense such rights; and
+
+2.3. Intel grants Licensee a non-exclusive and non-transferable patent
+license (with the right to sublicense), under only those claims of Intel
+patents that are infringed by the Original Intel Code, to make, use, sell,
+offer to sell, and import the Covered Code and derivative works thereof
+solely to the minimum extent necessary to exercise the above copyright
+license, and in no event shall the patent license extend to any additions
+to or modifications of the Original Intel Code. No other license or right
+is granted directly or by implication, estoppel or otherwise;
+
+The above copyright and patent license is granted only if the following
+conditions are met:
+
+3. Conditions
+
+3.1. Redistribution of Source with Rights to Further Distribute Source.
+Redistribution of source code of any substantial portion of the Covered
+Code or modification with rights to further distribute source must include
+the above Copyright Notice, the above License, this list of Conditions,
+and the following Disclaimer and Export Compliance provision. In addition,
+Licensee must cause all Covered Code to which Licensee contributes to
+contain a file documenting the changes Licensee made to create that Covered
+Code and the date of any change. Licensee must include in that file the
+documentation of any changes made by any predecessor Licensee. Licensee
+must include a prominent statement that the modification is derived,
+directly or indirectly, from Original Intel Code.
+
+3.2. Redistribution of Source with no Rights to Further Distribute Source.
+Redistribution of source code of any substantial portion of the Covered
+Code or modification without rights to further distribute source must
+include the following Disclaimer and Export Compliance provision in the
+documentation and/or other materials provided with distribution. In
+addition, Licensee may not authorize further sublicense of source of any
+portion of the Covered Code, and must include terms to the effect that the
+license from Licensee to its licensee is limited to the intellectual
+property embodied in the software Licensee provides to its licensee, and
+not to intellectual property embodied in modifications its licensee may
+make.
+
+3.3. Redistribution of Executable. Redistribution in executable form of any
+substantial portion of the Covered Code or modification must reproduce the
+above Copyright Notice, and the following Disclaimer and Export Compliance
+provision in the documentation and/or other materials provided with the
+distribution.
+
+3.4. Intel retains all right, title, and interest in and to the Original
+Intel Code.
+
+3.5. Neither the name Intel nor any other trademark owned or controlled by
+Intel shall be used in advertising or otherwise to promote the sale, use or
+other dealings in products derived from or relating to the Covered Code
+without prior written authorization from Intel.
+
+4. Disclaimer and Export Compliance
+
+4.1. INTEL MAKES NO WARRANTY OF ANY KIND REGARDING ANY SOFTWARE PROVIDED
+HERE. ANY SOFTWARE ORIGINATING FROM INTEL OR DERIVED FROM INTEL SOFTWARE
+IS PROVIDED "AS IS," AND INTEL WILL NOT PROVIDE ANY SUPPORT, ASSISTANCE,
+INSTALLATION, TRAINING OR OTHER SERVICES. INTEL WILL NOT PROVIDE ANY
+UPDATES, ENHANCEMENTS OR EXTENSIONS. INTEL SPECIFICALLY DISCLAIMS ANY
+IMPLIED WARRANTIES OF MERCHANTABILITY, NONINFRINGEMEN
[OE-core] [PATCH 3/5] ovmf: unify DEPENDS
Instead of depending on iasl-native, depend on ovmf-native as iasl was merged
into that recipe some time ago.
bc-native doesn't appear to be a build requirement anymore, and for clarity
merge two overridden DEPENDS into a single DEPENDS.
Signed-off-by: Ross Burton
---
meta/recipes-core/ovmf/ovmf_git.bb | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/meta/recipes-core/ovmf/ovmf_git.bb
b/meta/recipes-core/ovmf/ovmf_git.bb
index 3b5a05e51e6..ff2b2a530ad 100644
--- a/meta/recipes-core/ovmf/ovmf_git.bb
+++ b/meta/recipes-core/ovmf/ovmf_git.bb
@@ -29,10 +29,7 @@ PARALLEL_MAKE = ""
S = "${WORKDIR}/git"
-DEPENDS_class-native="util-linux-native iasl-native"
-DEPENDS_class-target="ovmf-native bc-native"
-
-DEPENDS_append = " nasm-native"
+DEPENDS = "nasm-native acpica-native ovmf-native util-linux-native"
EDK_TOOLS_DIR="edk2_basetools"
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/5] libsoup: update patch upstream status
This has been merged to master now, so mark as a backport. Signed-off-by: Ross Burton --- ...01-Do-not-enforce-no-introspection-when-cross-building.patch | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-support/libsoup/libsoup-2.4/0001-Do-not-enforce-no-introspection-when-cross-building.patch b/meta/recipes-support/libsoup/libsoup-2.4/0001-Do-not-enforce-no-introspection-when-cross-building.patch index cd6de853e5a..d534457e72c 100644 --- a/meta/recipes-support/libsoup/libsoup-2.4/0001-Do-not-enforce-no-introspection-when-cross-building.patch +++ b/meta/recipes-support/libsoup/libsoup-2.4/0001-Do-not-enforce-no-introspection-when-cross-building.patch @@ -3,7 +3,7 @@ From: Alexander Kanavin Date: Fri, 15 Feb 2019 14:21:06 +0100 Subject: [PATCH] Do not enforce no-introspection when cross-building -Upstream-Status: Pending +Upstream-Status: Backport [https://gitlab.gnome.org/GNOME/libsoup/commit/7ef5ec60c33e254bcd915936bea3f04ba0fe2273] Signed-off-by: Alexander Kanavin Signed-off-by: Alistair Francis --- -- 2.20.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 5/5] cve-update-db-native: don't refresh more than once an hour
We already fetch the yearly CVE metadata and check that for updates before
downloading the full data, but we can speed up CVE checking further by only
checking the CVE metadata once an hour.
Signed-off-by: Ross Burton
---
meta/recipes-core/meta/cve-update-db-native.bb | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-core/meta/cve-update-db-native.bb
b/meta/recipes-core/meta/cve-update-db-native.bb
index 2c427a5884f..19875a49b1c 100644
--- a/meta/recipes-core/meta/cve-update-db-native.bb
+++ b/meta/recipes-core/meta/cve-update-db-native.bb
@@ -31,8 +31,16 @@ python do_populate_cve_db() {
db_dir = os.path.join(d.getVar("DL_DIR"), 'CVE_CHECK')
db_file = os.path.join(db_dir, 'nvdcve_1.0.db')
json_tmpfile = os.path.join(db_dir, 'nvd.json.gz')
-proxy = d.getVar("https_proxy")
+# Don't refresh the database more than once an hour
+try:
+import time
+if time.time() - os.path.getmtime(db_file) < (60*60):
+return
+except OSError:
+pass
+
+proxy = d.getVar("https_proxy")
if proxy:
# instantiate an opener but do not install it as the global
# opener unless if we're really sure it's applicable for all
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] tune-riscv: Add support for hard and soft float
On Wed, Nov 6, 2019 at 11:33 PM Nathan Rossi wrote:
>
> On Thu, 7 Nov 2019 at 09:34, Adrian Bunk wrote:
> >
> > On Wed, Nov 06, 2019 at 10:18:18AM -0800, Alistair Francis wrote:
> > >...
> > > +TUNE_CCARGS_riscv64 .= "${@bb.utils.contains('TUNE_FEATURES',
> > > 'riscv64-f', ' -mabi=lp64d', ' -mabi=lp64', d)}"
> > > +TUNE_CCARGS_riscv32 .= "${@bb.utils.contains('TUNE_FEATURES',
> > > 'riscv32-f', ' -mabi=ilp32f', ' -mabi=ilp32', d)}"
> > >...
> >
> > That looks wrong, what would you put in TUNE_FEATURES
> > for -mabi=lp64f when -mabi=lp64d is called riscv64-f?
> >
> > Also note that this is only the floating point calling convention,
> > whether the compiler emits floating point instructions is defined
> > by -march.
> >
> > It would be good if this would start with a plan how to handle
> > all possible combination of RISC-V ISA extensions, ideally better
> > than the arm mess.
>
> I am keen to see this as well, since I am currently directly
> hardcoding -march/-mabi in the machine conf.
>
> It would be nice to see the ISA tunes available in oe-core, even if
> that is just the tune features and not predefined tunes (e.g. like
> microblaze).
I think this idea as well. Some generic way of generating tunes from
ISA stings would be great!
Does anyone have any ideas on the best way to do this?
Alistair
>
> Regards,
> Nathan
>
> >
> > 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
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/3] systemd: Add runtime dependency on new ldconfig package
On Thu, Nov 7, 2019 at 12:55 PM Andreas Oberritter wrote: > > Signed-off-by: Andreas Oberritter > --- > meta/recipes-core/systemd/systemd_243.bb | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/meta/recipes-core/systemd/systemd_243.bb > b/meta/recipes-core/systemd/systemd_243.bb > index 6e7f95693b..54fcc6a5d1 100644 > --- a/meta/recipes-core/systemd/systemd_243.bb > +++ b/meta/recipes-core/systemd/systemd_243.bb > @@ -139,7 +139,7 @@ PACKAGECONFIG[importd] = "-Dimportd=true,-Dimportd=false" > PACKAGECONFIG[iptc] = "-Dlibiptc=true,-Dlibiptc=false,iptables" > PACKAGECONFIG[journal-upload] = "-Dlibcurl=true,-Dlibcurl=false,curl" > PACKAGECONFIG[kmod] = "-Dkmod=true,-Dkmod=false,kmod" > -PACKAGECONFIG[ldconfig] = "-Dldconfig=true,-Dldconfig=false" > +PACKAGECONFIG[ldconfig] = "-Dldconfig=true,-Dldconfig=false,,ldconfig" Is this necessary? The implication of adding it is that you want to support situations where ldconfig is disabled in DISTRO_FEATURES (ie the new ldconfig package is not pulled in via a runtime dependency from glibc) but then manually added to systemd PACKAGECONFIG (ie ignoring DISTRO_FEATURES). That just seems like a misconfiguration and not something we should try to support. > PACKAGECONFIG[libidn] = "-Dlibidn=true,-Dlibidn=false,libidn" > PACKAGECONFIG[localed] = "-Dlocaled=true,-Dlocaled=false" > PACKAGECONFIG[logind] = "-Dlogind=true,-Dlogind=false" > -- > 2.17.1 > > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3] libtirpc: create the symbol link for rpc header files
On Wed, Nov 6, 2019 at 9:54 PM Zhixiong Chi wrote:
>
> Since the Sun RPC is deprecated in glibc, the rpc header files
> are not provided any more, but it allows alternative RPC
> implementations, such as TIRPC or rpcsvc-proto, to be used.
>
> So we create the symbol link for rpc header files for tirpc to
> be more compatible with the glibc version and the application usage.
>
https://errors.yoctoproject.org/Errors/Details/275527/
seems to be related to this update
> Signed-off-by: Zhixiong Chi
> ---
> meta/recipes-extended/libtirpc/libtirpc_1.1.4.bb | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/meta/recipes-extended/libtirpc/libtirpc_1.1.4.bb
> b/meta/recipes-extended/libtirpc/libtirpc_1.1.4.bb
> index e73ffe7b17..a284521c1e 100644
> --- a/meta/recipes-extended/libtirpc/libtirpc_1.1.4.bb
> +++ b/meta/recipes-extended/libtirpc/libtirpc_1.1.4.bb
> @@ -23,6 +23,20 @@ EXTRA_OECONF = "--disable-gssapi"
>
> do_install_append() {
> chown root:root ${D}${sysconfdir}/netconfig
> +install -d ${D}${includedir}/rpc
> +install -d ${D}${includedir}/rpcsvc
> +for link_header in ${D}${includedir}/tirpc/rpc/*; do
> +if [ -f $link_header -a ! -e ${D}/${includedir}/rpc/$(basename
> $link_header) ]; then
> +ln -sf ../tirpc/rpc/$(basename $link_header)
> ${D}${includedir}/rpc/$(basename $link_header)
> +fi
> +done
> +for link_header in ${D}${includedir}/tirpc/rpcsvc/*; do
> +if [ -f $link_header -a ! -e
> ${D}/${includedir}/rpcsvc/$(basename $link_header) ]; then
> +ln -sf ../tirpc/rpc/$(basename $link_header)
> ${D}${includedir}/rpcsvc/$(basename $link_header)
> +fi
> +done
> +ln -sf tirpc/netconfig.h ${D}/${includedir}/netconfig.h
> +
> }
>
> BBCLASSEXTEND = "native nativesdk"
> --
> 2.23.0
>
> --
> ___
> 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] libnsl2: Update to latest master
Get following patches
Detect recursive lock between yp_all() and do_ypcall()
Detect recursive NIS calls
Signed-off-by: Khem Raj
---
meta/recipes-extended/libnsl/libnsl2_git.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-extended/libnsl/libnsl2_git.bb
b/meta/recipes-extended/libnsl/libnsl2_git.bb
index c3a24face1..28c84af7ad 100644
--- a/meta/recipes-extended/libnsl/libnsl2_git.bb
+++ b/meta/recipes-extended/libnsl/libnsl2_git.bb
@@ -12,7 +12,7 @@ DEPENDS = "libtirpc"
PV = "1.2.0+git${SRCPV}"
-SRCREV = "37c5ffe3038d42e9fa9ed232ad2cbca4d8f14681"
+SRCREV = "4a062cf4180d99371198951e4ea5b4550efd58a3"
SRC_URI = "git://github.com/thkukuk/libnsl \
"
--
2.24.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] wic: beautify 'wic help'
From: Chee Yang Lee
The Wic help returned to the user is unreadable.
Use a custom ArgumentParser to override argparse help message.
change help message as suggest in
https://bugzilla.yoctoproject.org/show_bug.cgi?id=12205
[YOCTO #12205]
changes applies to 'wic help', 'wic -h', 'wic --h' and 'wic --help'
Signed-off-by: Chee Yang Lee
---
scripts/lib/wic/help.py | 56 +
scripts/wic | 8 +++---
2 files changed, 61 insertions(+), 3 deletions(-)
diff --git a/scripts/lib/wic/help.py b/scripts/lib/wic/help.py
index af7d0576e2..968cc0ed6f 100644
--- a/scripts/lib/wic/help.py
+++ b/scripts/lib/wic/help.py
@@ -1046,3 +1046,59 @@ NAME
DESCRIPTION
Specify a help topic to display it. Topics are shown above.
"""
+
+
+wic_help = """
+Creates a customized OpenEmbedded image.
+
+Usage: wic [--version]
+wic help [COMMAND or TOPIC]
+wic COMMAND [ARGS]
+
+usage 1: Returns the current version of Wic
+usage 2: Returns detailed help for a COMMAND or TOPIC
+usage 3: Executes COMMAND
+
+
+COMMAND:
+
+list - List available canned images and source plugins
+ls - List contents of partitioned image or partition
+rm - Remove files or directories from the vfat or ext* partitions
+help - Show help for a wic COMMAND or TOPIC
+write - Write an image to a device
+cp - Copy files and directories to the vfat or ext* partitions
+create - Create a new OpenEmbedded image
+
+
+TOPIC:
+overview - Presents an overall overview of Wic
+plugins - Presents an overview and API for Wic plugins
+kickstart - Presents a Wic kicstart file reference
+
+
+Examples:
+
+$ wic --version
+
+Returns the current version of Wic
+
+
+$ wic help cp
+
+Returns the SYNOPSIS and DESCRIPTION for the Wic "cp" command.
+
+
+$ wic list images
+
+Returns the list of canned images (i.e. *.wks files located in
+the /scripts/lib/wic/canned-wks directory.
+
+
+$ wic create mkefidisk -e core-image-minimal
+
+Creates an EFI disk image from artifacts used in a previous
+core-image-minimal build in standard BitBake locations
+(e.g. Cooked Mode).
+
+"""
diff --git a/scripts/wic b/scripts/wic
index 1d89fb2eda..1a717300f5 100755
--- a/scripts/wic
+++ b/scripts/wic
@@ -495,14 +495,18 @@ def init_parser(parser):
subparser = subparsers.add_parser(subcmd, help=subcommands[subcmd][2])
subcommands[subcmd][3](subparser)
+class WicArgumentParser(argparse.ArgumentParser):
+ def format_help(self):
+ return hlp.wic_help
def main(argv):
-parser = argparse.ArgumentParser(
+parser = WicArgumentParser(
description="wic version %s" % __version__)
init_parser(parser)
args = parser.parse_args(argv)
+
if args.debug:
logger.setLevel(logging.DEBUG)
@@ -510,8 +514,6 @@ def main(argv):
if args.command == "help":
if args.help_topic is None:
parser.print_help()
-print()
-print("Please specify a help topic")
elif args.help_topic in helptopics:
hlpt = helptopics[args.help_topic]
hlpt[0](hlpt[1], hlpt[2])
--
2.22.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3] libtirpc: create the symbol link for rpc header files
On 2019年11月08日 09:33, Khem Raj wrote:
On Wed, Nov 6, 2019 at 9:54 PM Zhixiong Chi wrote:
Since the Sun RPC is deprecated in glibc, the rpc header files
are not provided any more, but it allows alternative RPC
implementations, such as TIRPC or rpcsvc-proto, to be used.
So we create the symbol link for rpc header files for tirpc to
be more compatible with the glibc version and the application usage.
https://errors.yoctoproject.org/Errors/Details/275527/
seems to be related to this update
It seems the root cause is that gtkwave configure find the rpc/types.h
and rpc/xdr.h because
of the commit "libtirpc: create the symbol link for rpc header files",
but it hasn't the option "--with-tirpc". So the RPC_LDADD still uses
"-lrpc" other than "-ltirpc".
So I will generate update patch to add the option for gtkwave and send it to
meta-openembedded layer.
Thanks.
Signed-off-by: Zhixiong Chi
---
meta/recipes-extended/libtirpc/libtirpc_1.1.4.bb | 14 ++
1 file changed, 14 insertions(+)
diff --git a/meta/recipes-extended/libtirpc/libtirpc_1.1.4.bb
b/meta/recipes-extended/libtirpc/libtirpc_1.1.4.bb
index e73ffe7b17..a284521c1e 100644
--- a/meta/recipes-extended/libtirpc/libtirpc_1.1.4.bb
+++ b/meta/recipes-extended/libtirpc/libtirpc_1.1.4.bb
@@ -23,6 +23,20 @@ EXTRA_OECONF = "--disable-gssapi"
do_install_append() {
chown root:root ${D}${sysconfdir}/netconfig
+install -d ${D}${includedir}/rpc
+install -d ${D}${includedir}/rpcsvc
+for link_header in ${D}${includedir}/tirpc/rpc/*; do
+if [ -f $link_header -a ! -e ${D}/${includedir}/rpc/$(basename
$link_header) ]; then
+ln -sf ../tirpc/rpc/$(basename $link_header)
${D}${includedir}/rpc/$(basename $link_header)
+fi
+done
+for link_header in ${D}${includedir}/tirpc/rpcsvc/*; do
+if [ -f $link_header -a ! -e ${D}/${includedir}/rpcsvc/$(basename
$link_header) ]; then
+ln -sf ../tirpc/rpc/$(basename $link_header)
${D}${includedir}/rpcsvc/$(basename $link_header)
+fi
+done
+ln -sf tirpc/netconfig.h ${D}/${includedir}/netconfig.h
+
}
BBCLASSEXTEND = "native nativesdk"
--
2.23.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
-
Thanks,
Zhixiong Chi
Tel: +86-10-8477-7036
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3] libtirpc: create the symbol link for rpc header files
Ok, thanks.
On Thu, Nov 7, 2019 at 8:50 PM Zhixiong Chi wrote:
>
>
>
> On 2019年11月08日 09:33, Khem Raj wrote:
> > On Wed, Nov 6, 2019 at 9:54 PM Zhixiong Chi
> > wrote:
> >> Since the Sun RPC is deprecated in glibc, the rpc header files
> >> are not provided any more, but it allows alternative RPC
> >> implementations, such as TIRPC or rpcsvc-proto, to be used.
> >>
> >> So we create the symbol link for rpc header files for tirpc to
> >> be more compatible with the glibc version and the application usage.
> >>
> > https://errors.yoctoproject.org/Errors/Details/275527/
> >
> > seems to be related to this update
> It seems the root cause is that gtkwave configure find the rpc/types.h
> and rpc/xdr.h because
> of the commit "libtirpc: create the symbol link for rpc header files",
> but it hasn't the option "--with-tirpc". So the RPC_LDADD still uses
> "-lrpc" other than "-ltirpc".
> So I will generate update patch to add the option for gtkwave and send it to
> meta-openembedded layer.
>
> Thanks.
>
> >
> >> Signed-off-by: Zhixiong Chi
> >> ---
> >> meta/recipes-extended/libtirpc/libtirpc_1.1.4.bb | 14 ++
> >> 1 file changed, 14 insertions(+)
> >>
> >> diff --git a/meta/recipes-extended/libtirpc/libtirpc_1.1.4.bb
> >> b/meta/recipes-extended/libtirpc/libtirpc_1.1.4.bb
> >> index e73ffe7b17..a284521c1e 100644
> >> --- a/meta/recipes-extended/libtirpc/libtirpc_1.1.4.bb
> >> +++ b/meta/recipes-extended/libtirpc/libtirpc_1.1.4.bb
> >> @@ -23,6 +23,20 @@ EXTRA_OECONF = "--disable-gssapi"
> >>
> >> do_install_append() {
> >> chown root:root ${D}${sysconfdir}/netconfig
> >> +install -d ${D}${includedir}/rpc
> >> +install -d ${D}${includedir}/rpcsvc
> >> +for link_header in ${D}${includedir}/tirpc/rpc/*; do
> >> +if [ -f $link_header -a ! -e
> >> ${D}/${includedir}/rpc/$(basename $link_header) ]; then
> >> +ln -sf ../tirpc/rpc/$(basename $link_header)
> >> ${D}${includedir}/rpc/$(basename $link_header)
> >> +fi
> >> +done
> >> +for link_header in ${D}${includedir}/tirpc/rpcsvc/*; do
> >> +if [ -f $link_header -a ! -e
> >> ${D}/${includedir}/rpcsvc/$(basename $link_header) ]; then
> >> +ln -sf ../tirpc/rpc/$(basename $link_header)
> >> ${D}${includedir}/rpcsvc/$(basename $link_header)
> >> +fi
> >> +done
> >> +ln -sf tirpc/netconfig.h ${D}/${includedir}/netconfig.h
> >> +
> >> }
> >>
> >> BBCLASSEXTEND = "native nativesdk"
> >> --
> >> 2.23.0
> >>
> >> --
> >> ___
> >> Openembedded-core mailing list
> >> Openembedded-core@lists.openembedded.org
> >> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
> --
> -
> Thanks,
> Zhixiong Chi
> Tel: +86-10-8477-7036
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
