Re: [OE-core] [RFC][PATCH 0/3] Move rust from meta-rust to oe-core

[Adrian Bunk]

On Wed, Sep 25, 2019 at 01:52:08PM -0400, Randy MacLeod wrote:
> On 9/24/19 6:18 AM, Adrian Bunk wrote:
> > On Mon, Sep 23, 2019 at 10:45:05PM -0400, Randy MacLeod wrote:
>...
> > There are also related topics like how to provide security support
> > for vendored libraries - this is the main reason why vendored libraries
> > shipped by upstream are rarely used by distributions in the C ecosystem.
> 
> Yes, we need to have a plan for security and bug fixes.
> Of course Rust is largely impervious to such 20th century problems.
> (mostly joking!)

vendor/ in the librsvg 2.46.0 tarball are 145 crates (157 MB).
vendor/ in the rust 1.37.0 tarball are 350 crates (308 MB).

>...
> > > 5. make rust-hello-world install for qemuriscv64
> > > https://github.com/meta-rust/meta-rust/issues/252
> > 
> > LLVM in meta-rust is too old for RISC-V.
> 
> Right.
> I'm away Thursday to Sunday but
> I'll work on a fix for that when I'm back.

It needs LLVM 9, plus RISC-V support that is not yet in upstream Rust.

Not sure whether the latter requires more than just a target definition,
but this will likely just work if you wait a few months.

>...
> > Using an own LLVM recipe might makes sense for an external layer, but in
> > oe-core the llvm recipe that is already there should be used instead of
> > another copy of LLVM.
> 
> I agree that the goal should be to have a single llvm package but
> it's an upstream Rust decision.

For upstream it is better to have an own copy of LLVM,
but for a distribution it can be beneficial to avoid having
mesa/rust/clang/... each shipping and building own copies
of LLVM.

> I did look at the differences between the 'forks' and they are significant.

In Debian Rust uses the same LLVM as everything else.

>...
> > 2.44 built for me a few months ago with meta-rust.
> 
> Can you share the recipe so I can use it and update it to 2.46?

Attached, the only other noteworthy change was that upstream
removed rsvg-view.

>...
> > > What have I missed?
> > > ...
> > 
> > 9. Ensure that there are no non-optional dependencies on the target
> > librsvg since users will build for targets not supported by Rust.
> > The one in webkitgtk seems to be optional or obsolete.
>...
> To deal with such targets, we'd keep the old version of librsvg
> around for a while longer. That could cascade into several
> packages with duplicate versions in oe-core so it may be best handled
> with a separate layer.

This sounds unsustainable, similar to meta-gplv2.

Right now the only dependencies on librsvg in oe-core are webkitgtk 
(unused, I'll submit a patch removing it after the Yocto 3.0 branching) 
and an optional dependency in gstreamer1.0-plugins-bad, so likely no 
problem at the moment.

But with software like bzip2 also moving to Rust this is something
that that might need continued attention.

There are people submitting patches for e.g. big endian arm to OE,
and there is value in ensuring that OE stays usable for such usecases.

> > 10. Review the whole contents of the layer.
> >  There are several things where I hope there are better solutions,
> >  and I expect that what will land in oe-core will look quite
> >  different from the current meta-rust.
> >  See item 5 above for an example.
> 
> Yes, if we require separate bitbake recipes for each package
> that would require significant changes to the current layer.

This is not about specific issues.

There are plenty of other cases like for example rust.inc being
the wrong place for OE target -> LLVM target mappings in oe-core, 
if they are needed at all.

> Thanks,
> 
> ../Randy

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

diff --git 
a/meta/recipes-gnome/librsvg/librsvg/0001-Auto-detect-Bsymbolic-fixes-configure-on-macOS.patch
 
b/meta/recipes-gnome/librsvg/librsvg/0001-Auto-detect-Bsymbolic-fixes-configure-on-macOS.patch
deleted file mode 100644
index 954bb60880..00
--- 
a/meta/recipes-gnome/librsvg/librsvg/0001-Auto-detect-Bsymbolic-fixes-configure-on-macOS.patch
+++ /dev/null
@@ -1,35 +0,0 @@
-From b99891e31eb6ce550e7e1cb2ca592095b3050a93 Mon Sep 17 00:00:00 2001
-From: Brion Vibber 
-Date: Sun, 25 Feb 2018 18:42:36 -0800
-Subject: Auto-detect -Bsymbolic, fixes configure on macOS
-
-The -Bsymbolic linker option is ELF-specific, and was breaking
-configure on macOS unless --disable-Bsymbolic was explicitly passed.
-
-Switching the behavior from requiring -Bsymbolic to be available
-by default to just warning and continuing on without.
-
-Fixes https://gitlab.gnome.org/GNOME/librsvg/issues/211
-
-Upstream-Status: Backport
-Signed-off-by: Adrian Bunk 

- configure.ac | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/configure.ac b/configure.ac
-index 15b26b2d..9f8dce29 100644
 a/configure.ac
-+++

Re: [OE-core] [PATCH v2 2/3] apr: Fix configure error for nativesdk

[Robert Yang]

Hi Khem,

On 9/26/19 10:57 AM, Khem Raj wrote:

On Wed, Sep 25, 2019 at 7:52 PM Robert Yang  wrote:


Fixed:
$ bitbake nativesdk-apr
buildconf: libtool not found.
You need libtool version 1.4 or newer installed

Signed-off-by: Robert Yang 
---
  meta/recipes-support/apr/apr_1.7.0.bb | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-support/apr/apr_1.7.0.bb 
b/meta/recipes-support/apr/apr_1.7.0.bb
index 09a65bf..a9d98be 100644
--- a/meta/recipes-support/apr/apr_1.7.0.bb
+++ b/meta/recipes-support/apr/apr_1.7.0.bb
@@ -1,7 +1,7 @@
  SUMMARY = "Apache Portable Runtime (APR) library"
  HOMEPAGE = "http://apr.apache.org/";
  SECTION = "libs"
-DEPENDS = "util-linux"
+DEPENDS = "util-linux libtool"


hmmm packages usually need libtoolize so please check if thats the
case or maybe patch apr to
do so., thereafter you can just DEPEND on libtool-cross


In do_configure:

libtool='${HOST_SYS}-libtool' ./buildconf

So it requires libtool which is x86_64-pokysdk-linux-libtool when build 
nativesdk-apr. The libtool-cross is already in default depends, and it

doesn't work when build nativesdk-apr, so I added libtool to the DEPENDS.

// Robert





  LICENSE = "Apache-2.0"
  LIC_FILES_CHKSUM = "file://LICENSE;md5=4dfd4cd216828c8cae5de5a12f3844c8 \
--
2.7.4

--
___
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] sdk: Install nativesdk locales for all TCLIBC variants

[Khem Raj]

install_locales() here is actually operating on nativesdk and only glibc
is the default library for nativesdk, since thats what most of
desktop/server distros use, therefore bailing out based on TCLIBC is not
needed here, since nativesdk-glibc would be required for all non-glibc
targetting SDKs as well.

Fixes SDK install time error

ERROR:  OE-core's config sanity checker detected a potential misconfiguration.
Either fix the cause of this error or at your own risk disable the checker (see 
sanity.conf).
Following is the list of potential problems / advisories:
Your system needs to support the en_US.UTF-8 locale.
ERROR: SDK preparation failed

Signed-off-by: Khem Raj 
---
 meta/lib/oe/sdk.py | 4 
 1 file changed, 4 deletions(-)

diff --git a/meta/lib/oe/sdk.py b/meta/lib/oe/sdk.py
index b4fbdb799e..d02a274812 100644
--- a/meta/lib/oe/sdk.py
+++ b/meta/lib/oe/sdk.py
@@ -88,10 +88,6 @@ class Sdk(object, metaclass=ABCMeta):
 bb.warn("cannot remove SDK dir: %s" % path)
 
 def install_locales(self, pm):
-# This is only relevant for glibc
-if self.d.getVar("TCLIBC") != "glibc":
-return
-
 linguas = self.d.getVar("SDKIMAGE_LINGUAS")
 if linguas:
 import fnmatch
-- 
2.23.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2 2/3] apr: Fix configure error for nativesdk

[Khem Raj]

On Wed, Sep 25, 2019 at 7:52 PM Robert Yang  wrote:
>
> Fixed:
> $ bitbake nativesdk-apr
> buildconf: libtool not found.
>You need libtool version 1.4 or newer installed
>
> Signed-off-by: Robert Yang 
> ---
>  meta/recipes-support/apr/apr_1.7.0.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-support/apr/apr_1.7.0.bb 
> b/meta/recipes-support/apr/apr_1.7.0.bb
> index 09a65bf..a9d98be 100644
> --- a/meta/recipes-support/apr/apr_1.7.0.bb
> +++ b/meta/recipes-support/apr/apr_1.7.0.bb
> @@ -1,7 +1,7 @@
>  SUMMARY = "Apache Portable Runtime (APR) library"
>  HOMEPAGE = "http://apr.apache.org/";
>  SECTION = "libs"
> -DEPENDS = "util-linux"
> +DEPENDS = "util-linux libtool"

hmmm packages usually need libtoolize so please check if thats the
case or maybe patch apr to
do so., thereafter you can just DEPEND on libtool-cross

>
>  LICENSE = "Apache-2.0"
>  LIC_FILES_CHKSUM = "file://LICENSE;md5=4dfd4cd216828c8cae5de5a12f3844c8 \
> --
> 2.7.4
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2 1/3] expect: Fix configure error for nativesdk

[Robert Yang]

Fixed:
$ bitbake nativesdk-expect
checking for Tcl public headers... configure: error: tcl.h not found.  Please 
specify its location with --with-tclinclude

Signed-off-by: Robert Yang 
---
 meta/recipes-devtools/expect/expect_5.45.4.bb | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-devtools/expect/expect_5.45.4.bb 
b/meta/recipes-devtools/expect/expect_5.45.4.bb
index 96eacd9..5f59083 100644
--- a/meta/recipes-devtools/expect/expect_5.45.4.bb
+++ b/meta/recipes-devtools/expect/expect_5.45.4.bb
@@ -44,9 +44,9 @@ do_install_append() {
 }
 
 # Apparently the public Tcl headers are only in /usr/include/tcl8.6
-# when building for the target.
-TCL_INCLUDE_PATH = ""
-TCL_INCLUDE_PATH_class-target = "--with-tclinclude=${STAGING_INCDIR}/tcl8.6"
+# when building for the target and nativesdk.
+TCL_INCLUDE_PATH = "--with-tclinclude=${STAGING_INCDIR}/tcl8.6"
+TCL_INCLUDE_PATH_class-native = ""
 
 EXTRA_OECONF += "--with-tcl=${STAGING_LIBDIR} \
  --enable-shared \
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2 0/3] meta: 3 fixes for nativesdk

[Robert Yang]

* V2:
  - Fix comments from Ross.

* V1
  - Initial version

// Robert

The following changes since commit 95ad5626296380358c8a502a3e04879dab653d78:

  build-appliance-image: Update to master head revision (2019-09-19 20:32:47 
+0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib rbt/sdk
  http://cgit.openembedded.org/openembedded-core-contrib/log/?h=rbt/sdk

Robert Yang (3):
  expect: Fix configure error for nativesdk
  apr: Fix configure error for nativesdk
  net-tools: Fix installed-vs-shipped for nativesdk

 meta/recipes-devtools/expect/expect_5.45.4.bb| 6 +++---
 meta/recipes-extended/net-tools/net-tools_1.60-26.bb | 2 +-
 meta/recipes-support/apr/apr_1.7.0.bb| 2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2 2/3] apr: Fix configure error for nativesdk

[Robert Yang]

Fixed:
$ bitbake nativesdk-apr
buildconf: libtool not found.
   You need libtool version 1.4 or newer installed

Signed-off-by: Robert Yang 
---
 meta/recipes-support/apr/apr_1.7.0.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-support/apr/apr_1.7.0.bb 
b/meta/recipes-support/apr/apr_1.7.0.bb
index 09a65bf..a9d98be 100644
--- a/meta/recipes-support/apr/apr_1.7.0.bb
+++ b/meta/recipes-support/apr/apr_1.7.0.bb
@@ -1,7 +1,7 @@
 SUMMARY = "Apache Portable Runtime (APR) library"
 HOMEPAGE = "http://apr.apache.org/";
 SECTION = "libs"
-DEPENDS = "util-linux"
+DEPENDS = "util-linux libtool"
 
 LICENSE = "Apache-2.0"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=4dfd4cd216828c8cae5de5a12f3844c8 \
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2 3/3] net-tools: Fix installed-vs-shipped for nativesdk

[Robert Yang]

Fixed:
$ bitbake nativesdk-net-tools
ERROR: nativesdk-net-tools-1.60-26-r0 do_package: QA Issue: 
nativesdk-net-tools: Files/directories were installed but not shipped in any 
package:
  /usr
  /usr/share
  /usr/share/man
[snip]

Signed-off-by: Robert Yang 
---
 meta/recipes-extended/net-tools/net-tools_1.60-26.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-extended/net-tools/net-tools_1.60-26.bb 
b/meta/recipes-extended/net-tools/net-tools_1.60-26.bb
index b565fd0..5a376e7 100644
--- a/meta/recipes-extended/net-tools/net-tools_1.60-26.bb
+++ b/meta/recipes-extended/net-tools/net-tools_1.60-26.bb
@@ -95,7 +95,7 @@ do_compile() {
 
 do_install() {
# We don't need COPTS or LOPTS, but let's be consistent.
-   oe_runmake COPTS="$CFLAGS" LOPTS="$LDFLAGS" 'BASEDIR=${D}' install
+   oe_runmake COPTS="$CFLAGS" LOPTS="$LDFLAGS" BASEDIR=${D} 
INSTALLNLSDIR=${D}${datadir}/locale mandir=${mandir} install
 
if [ "${base_bindir}" != "/bin" ]; then
mkdir -p ${D}/${base_bindir}
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Yocto Project Status WW39’19

[akuster808]

On 9/24/19 6:50 PM, ChenQi wrote:
> On 09/24/2019 10:50 PM, Stephen K Jolley wrote:
>>
>> Current Dev Position: YP 2.8 M4 Feature Freeze
>>
>> Next Deadline: YP 3.0 Final Release 25th Oct
>>
>>
>> SWAT Team Rotation:
>>
>>  *
>>
>> SWAT lead is currently: Amanda 
>>
>>  *
>>
>> SWAT team rotation: Amanda -> Chen on Sept. 27, 2019
>>
>>  *
>>
>> SWAT team rotation: Chen -> Armin on Oct. 4, 2019
>>
>>  *
>>
>> https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team
>>
>>
>
> Hi Armin and Anju,

I will take that week.
>
> I want to switch the rotation with you two.
> Because Oct. 1st is our National Day. We'll have a one-week holiday to
> celebrate it.

Enjoy your week off.

- armin


>
> I've updated
> https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team#Members
> for now.
> If you have any concern, please let me know.
> Thanks in advance.
>
> Best Regards,
> Chen Qi
>
>
>
>> Next Team Meetings:
>>
>>  *
>>
>> Bug Triage meeting Thursday Sept 26th at 7:30am PDT
>> (https://zoom.us/j/454367603)
>>
>>  *
>>
>> Monthly Project Meeting Tuesday Oct. 1st at 8am PDT
>> (https://zoom.us/j/990892712) 
>>
>>  *
>>
>> Weekly Engineering Sync Tuesday Sept. 24th at 8am PDT
>> (https://zoom.us/j/990892712) 
>>
>>  *
>>
>> Twitch - Next event is Tuesday Octt. 8th at 8am PDT
>> (https://www.twitch.tv/yocto_project)
>>
>>
>> Key Status/Updates:
>>
>>  *
>>
>> We’re now in feature freeze for 3.0 and working on bug fixing for
>> final release
>>
>>  *
>>
>> We have built M3 and this is due from QA on Thursday
>>
>>  *
>>
>> The main unresolved issue for 3.0 is with the hash equivalence
>> server causing problems with the eSDK and this issue is being
>> investigated but can’t be reproduced as yet.
>>
>>  *
>>
>> We also want to find a better solution to the systemd timeout
>> problem before final release.
>>
>>  *
>>
>> A significant performance problem has been found on the
>> autobuilder where some builds are scaling in time badly as the
>> sstate cache grows, taking 12 hours or more in some cases.
>> Unfortunately nobody seems motivated to help work on this kind of
>> issue.
>>
>>  *
>>
>> The plan for M4 is to resolve the above issues and any issues
>> raised from M3 QA, then proceed with the main release rc builds.
>> The first M4 build is scheduled for next week.
>>
>>  *
>>
>> If anyone has any status items for the project they’d like to add
>> to the weekly reports, please email Richard+Stephen.
>>
>>
>> Planned Releases for YP 3.0 {2.8}:
>>
>>  *
>>
>> M3 Release 6th Sept
>>
>>  *
>>
>> M4 Cutoff 30th Sept - this will be YP 3.0.
>>
>>  *
>>
>> YP 3.0 {2.8 (M4)} Final Release 25th Oct
>>
>>
>> Planned upcoming dot releases:
>>
>>  *
>>
>> YP 2.7.2 (Warrior) is planned for after YP 3.0 release.
>>
>>  *
>>
>> YP 2.6.4 (Thud) is planned for after YP 2.7.2  release.
>>
>>
>> Tracking Metrics:
>>
>>  *
>>
>> WDD 2505 (last week
>> 2449)(https://wiki.yoctoproject.org/charts/combo.html)
>>
>>  *
>>
>> Poky Patch Metrics  
>>
>>  o
>>
>> Total patches found: 1427 (last week 1424)
>>
>>  o
>>
>> Patches in the Pending State: 587 (41%) [last week 587 (41%)]
>>
>>
>> Key Status Links for YP:
>>
>> https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.8_Status
>>
>> https://wiki.yoctoproject.org/wiki/Yocto_2.8_Schedule
>>
>> https://wiki.yoctoproject.org/wiki/Yocto_2.8_Features
>>
>>
>> The Yocto Project’s technical governance is through its Technical
>> Steering Committee, more information is available at:
>>
>> https://wiki.yoctoproject.org/wiki/TSC
>>
>>
>> The Status reports are now stored on the wiki at:
>> https://wiki.yoctoproject.org/wiki/Weekly_Status
>>
>>
>> [If anyone has suggestions for other information you’d like to see on
>> this weekly status update, let us know!]
>>
>>
>> -- 
>>
>> Thanks,
>>
>>  
>>
>> */Stephen K. Jolley/*
>>
>> *Yocto Project Program Manager*
>>
>> *7867 SW Bayberry Dr., Beaverton, OR 97007*
>>
>> (*Cell*:    (208) 244-4460
>>
>> * *Email*: _stephen.k.jol...@intel.com
>> _
>>
>>
>>
>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] u-boot: add CVE patches for u-boot

[Meng.Li]

From: Limeng 

Add 9 patches to fix below CVE issues.
CVE-2019-13103
CVE-2019-13104
CVE-2019-13105
CVE-2019-13106
CVE-2019-14192
CVE-2019-14193
CVE-2019-14194
CVE-2019-14195
CVE-2019-14196
CVE-2019-14197
CVE-2019-14198
CVE-2019-14199
CVE-2019-14200
CVE-2019-14201
CVE-2019-14202
CVE-2019-14203
CVE-2019-14204

Signed-off-by: Meng Li 
---
 .../u-boot/files/0001-CVE-2019-13103.patch| 69 +++
 .../u-boot/files/0002-CVE-2019-13104.patch| 49 +
 .../u-boot/files/0003-CVE-2019-13105.patch| 37 ++
 .../u-boot/files/0004-CVE-2019-13106.patch| 56 +++
 .../0005-CVE-2019-14192-14193-14199.patch | 43 
 ...-14197-14200-14201-14202-14203-14204.patch | 44 
 .../files/0007-CVE-2019-14194-14198.patch | 42 +++
 .../u-boot/files/0008-CVE-2019-14195.patch| 42 +++
 .../u-boot/files/0009-CVE-2019-14196.patch| 48 +
 meta/recipes-bsp/u-boot/u-boot-common.inc | 12 +++-
 10 files changed, 441 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-bsp/u-boot/files/0001-CVE-2019-13103.patch
 create mode 100644 meta/recipes-bsp/u-boot/files/0002-CVE-2019-13104.patch
 create mode 100644 meta/recipes-bsp/u-boot/files/0003-CVE-2019-13105.patch
 create mode 100644 meta/recipes-bsp/u-boot/files/0004-CVE-2019-13106.patch
 create mode 100644 
meta/recipes-bsp/u-boot/files/0005-CVE-2019-14192-14193-14199.patch
 create mode 100644 
meta/recipes-bsp/u-boot/files/0006-CVE-2019-14197-14200-14201-14202-14203-14204.patch
 create mode 100644 
meta/recipes-bsp/u-boot/files/0007-CVE-2019-14194-14198.patch
 create mode 100644 meta/recipes-bsp/u-boot/files/0008-CVE-2019-14195.patch
 create mode 100644 meta/recipes-bsp/u-boot/files/0009-CVE-2019-14196.patch

diff --git a/meta/recipes-bsp/u-boot/files/0001-CVE-2019-13103.patch 
b/meta/recipes-bsp/u-boot/files/0001-CVE-2019-13103.patch
new file mode 100644
index 00..1a5d1eb996
--- /dev/null
+++ b/meta/recipes-bsp/u-boot/files/0001-CVE-2019-13103.patch
@@ -0,0 +1,69 @@
+From 39a759494f734c4cdc3e2b919671bfb3134b41ae Mon Sep 17 00:00:00 2001
+From: Paul Emge 
+Date: Mon, 8 Jul 2019 16:37:03 -0700
+Subject: [PATCH 1/9] CVE-2019-13103: disk: stop infinite recursion in DOS
+ Partitions
+
+part_get_info_extended and print_partition_extended can recurse infinitely
+while parsing a self-referential filesystem or one with a silly number of
+extended partitions. This patch adds a limit to the number of recursive
+partitions.
+
+Signed-off-by: Paul Emge 
+
+Upstream-Status: Backport[http://git.denx.de/?p=u-boot.git;a=commit;
+ h=232e2f4fd9a24bf08215ddc8c53ccadffc841fb5]
+
+CVE: CVE-2019-13103
+
+Signed-off-by: Meng Li 
+---
+ disk/part_dos.c | 18 ++
+ 1 file changed, 18 insertions(+)
+
+diff --git a/disk/part_dos.c b/disk/part_dos.c
+index 936cee0d36..aae9d95906 100644
+--- a/disk/part_dos.c
 b/disk/part_dos.c
+@@ -23,6 +23,10 @@
+ 
+ #define DOS_PART_DEFAULT_SECTOR 512
+ 
++/* should this be configurable? It looks like it's not very common at all
++ * to use large numbers of partitions */
++#define MAX_EXT_PARTS 256
++
+ /* Convert char[4] in little endian format to the host format integer
+  */
+ static inline unsigned int le32_to_int(unsigned char *le32)
+@@ -126,6 +130,13 @@ static void print_partition_extended(struct blk_desc 
*dev_desc,
+   dos_partition_t *pt;
+   int i;
+ 
++  /* set a maximum recursion level */
++  if (part_num > MAX_EXT_PARTS)
++  {
++  printf("** Nested DOS partitions detected, stopping **\n");
++  return;
++}
++
+   if (blk_dread(dev_desc, ext_part_sector, 1, (ulong *)buffer) != 1) {
+   printf ("** Can't read partition table on %d:" LBAFU " **\n",
+   dev_desc->devnum, ext_part_sector);
+@@ -191,6 +202,13 @@ static int part_get_info_extended(struct blk_desc 
*dev_desc,
+   int i;
+   int dos_type;
+ 
++  /* set a maximum recursion level */
++  if (part_num > MAX_EXT_PARTS)
++  {
++  printf("** Nested DOS partitions detected, stopping **\n");
++  return -1;
++}
++
+   if (blk_dread(dev_desc, ext_part_sector, 1, (ulong *)buffer) != 1) {
+   printf ("** Can't read partition table on %d:" LBAFU " **\n",
+   dev_desc->devnum, ext_part_sector);
+-- 
+2.17.1
+
diff --git a/meta/recipes-bsp/u-boot/files/0002-CVE-2019-13104.patch 
b/meta/recipes-bsp/u-boot/files/0002-CVE-2019-13104.patch
new file mode 100644
index 00..de122b27d0
--- /dev/null
+++ b/meta/recipes-bsp/u-boot/files/0002-CVE-2019-13104.patch
@@ -0,0 +1,49 @@
+From 1d36545e43003f4b1bb3a303a3b468abd482fa2f Mon Sep 17 00:00:00 2001
+From: Paul Emge 
+Date: Mon, 8 Jul 2019 16:37:05 -0700
+Subject: [PATCH 2/9] CVE-2019-13104: ext4: check for underflow in
+ ext4fs_read_file
+
+in ext4fs_read_file, it is possible for a broken/malicious file
+system to cause a memcpy of a negative number of b

[OE-core] [yocto] : u-boot: add CVE patches for u-boot

[Meng.Li]

From: Limeng 

Add 9 patches to fix below CVE issues.
CVE-2019-13103
CVE-2019-13104
CVE-2019-13105
CVE-2019-13106
CVE-2019-14192
CVE-2019-14193
CVE-2019-14194
CVE-2019-14195
CVE-2019-14196
CVE-2019-14197
CVE-2019-14198
CVE-2019-14199
CVE-2019-14200
CVE-2019-14201
CVE-2019-14202
CVE-2019-14203
CVE-2019-14204

Detail patches as below:

0001-u-boot-add-CVE-patches-for-u-boot.patch

 files/0001-CVE-2019-13103.patch   |   69 ++
 files/0002-CVE-2019-13104.patch   |   49 +++
 files/0003-CVE-2019-13105.patch   |   37 +
 files/0004-CVE-2019-13106.patch   |   56 
 files/0005-CVE-2019-14192-14193-14199.patch   |   43 ++
 files/0006-CVE-2019-14197-14200-14201-14202-14203-14204.patch |   44 ++
 files/0007-CVE-2019-14194-14198.patch |   42 ++
 files/0008-CVE-2019-14195.patch   |   42 ++
 files/0009-CVE-2019-14196.patch   |   48 ++
 u-boot-common.inc |   12 +
 10 files changed, 441 insertions(+), 1 deletion(-)


thanks,
Limeng

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [thud][PATCH v2] pango: Security fix for CVE

[Muminul Islam]

Signed-off-by: Muminul Islam 
---
 .../pango/pango/CVE-2019-1010238.patch| 39 +++
 meta/recipes-graphics/pango/pango_1.42.4.bb   |  1 +
 2 files changed, 40 insertions(+)
 create mode 100644 meta/recipes-graphics/pango/pango/CVE-2019-1010238.patch

diff --git a/meta/recipes-graphics/pango/pango/CVE-2019-1010238.patch 
b/meta/recipes-graphics/pango/pango/CVE-2019-1010238.patch
new file mode 100644
index 00..309ff2d083
--- /dev/null
+++ b/meta/recipes-graphics/pango/pango/CVE-2019-1010238.patch
@@ -0,0 +1,39 @@
+From 7e3b9e1c88799a4da39da5d3a4a6dd652d859201 Mon Sep 17 00:00:00 2001
+From: Matthias Clasen 
+Date: Wed, 10 Jul 2019 20:26:23 -0400
+Subject: [PATCH] bidi: Be safer against bad input
+Reply-To: muis...@microsoft.com
+
+Don't run off the end of an array that we
+allocated to certain length.
+
+Closes: https://gitlab.gnome.org/GNOME/pango/issues/342
+Signed-off-by: Muminul Islam 
+
+CVE: CVE-2019-1010238
+Upstream-Status: Backport
+---
+ pango/pango-bidi-type.c | 7 +--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+diff --git a/pango/pango-bidi-type.c b/pango/pango-bidi-type.c
+index a49e06d9..d169525e 100644
+--- a/pango/pango-bidi-type.c
 b/pango/pango-bidi-type.c
+@@ -179,8 +179,11 @@ pango_log2vis_get_embedding_levels (const gchar*text,
+   for (i = 0, p = text; p < text + length; p = g_utf8_next_char(p), i++)
+ {
+   gunichar ch = g_utf8_get_char (p);
+-  FriBidiCharType char_type;
+-  char_type = fribidi_get_bidi_type (ch);
++  FriBidiCharType char_type = fribidi_get_bidi_type (ch);
++
++  if (i == n_chars)
++break;
++
+   bidi_types[i] = char_type;
+   ored_types |= char_type;
+   if (FRIBIDI_IS_STRONG (char_type))
+-- 
+2.23.0
+
diff --git a/meta/recipes-graphics/pango/pango_1.42.4.bb 
b/meta/recipes-graphics/pango/pango_1.42.4.bb
index 22fe3af15d..34732fdd4b 100644
--- a/meta/recipes-graphics/pango/pango_1.42.4.bb
+++ b/meta/recipes-graphics/pango/pango_1.42.4.bb
@@ -15,6 +15,7 @@ inherit gnomebase gtk-doc ptest-gnome 
upstream-version-is-even gobject-introspec
 
 SRC_URI += "file://run-ptest \
 
file://0001-Enforce-recreation-of-docs-pango.types-it-is-build-c.patch \
+file://CVE-2019-1010238.patch \
 "
 SRC_URI[archive.md5sum] = "deb171a31a3ad76342d5195a1b5bbc7c"
 SRC_URI[archive.sha256sum] = 
"1d2b74cd63e8bd41961f2f8d952355aa0f9be6002b52c8aa7699d9f5da597c9d"
-- 
2.23.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] ell: update to 0.23

[Oleksandr Kravchuk]

Changelog:
- Add support for checking if uintset is empty.

Signed-off-by: Oleksandr Kravchuk 
---
 meta/recipes-core/ell/{ell_0.22.bb => ell_0.23.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-core/ell/{ell_0.22.bb => ell_0.23.bb} (83%)

diff --git a/meta/recipes-core/ell/ell_0.22.bb 
b/meta/recipes-core/ell/ell_0.23.bb
similarity index 83%
rename from meta/recipes-core/ell/ell_0.22.bb
rename to meta/recipes-core/ell/ell_0.23.bb
index b3942fc30e..f6e91ef6fd 100644
--- a/meta/recipes-core/ell/ell_0.22.bb
+++ b/meta/recipes-core/ell/ell_0.23.bb
@@ -14,8 +14,8 @@ DEPENDS = "dbus"
 inherit autotools pkgconfig
 
 SRC_URI = 
"https://mirrors.edge.kernel.org/pub/linux/libs/${BPN}/${BPN}-${PV}.tar.xz";
-SRC_URI[md5sum] = "a4e7d74404f11e71775b89f53a8f1c33"
-SRC_URI[sha256sum] = 
"3c1d6d997e17dfcbe4ebcd1331d9a7be5c64f2f0a0813bc223790e570d8da2e3"
+SRC_URI[md5sum] = "be8214ff5b37012c4314343c8e6bcf15"
+SRC_URI[sha256sum] = 
"2efd9f7cdf57dedb9f1ba81bec534a3e0432476b1cb35ec0bc69973772a5f89b"
 
 do_configure_prepend () {
 mkdir -p ${S}/build-aux
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] ✗ patchtest: failure for pango: Security fix for CVE

[Patchwork]

== Series Details ==

Series: pango: Security fix for CVE 
Revision: 1
URL   : https://patchwork.openembedded.org/series/20176/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Patch[thud] pango: Security fix for CVE 
 Issue Missing or incorrectly formatted CVE tag in included patch 
file [test_cve_tag_format] 
  Suggested fixCorrect or include the CVE tag on cve patch with format: 
"CVE: CVE--"

* Issue Added patch file is missing Upstream-Status in the header 
[test_upstream_status_presence_format] 
  Suggested fixAdd Upstream-Status:  to the header of 
meta/recipes-graphics/pango/pango/CVE-2019-1010238.patch
  Standard format  Upstream-Status: 
  Valid status Pending, Accepted, Backport, Denied, Inappropriate [reason], 
Submitted [where]



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] [thud][PATCH] pango: Security fix for CVE

[Muminul Islam]

Signed-off-by: Muminul Islam 
---
 .../pango/pango/CVE-2019-1010238.patch| 36 +++
 meta/recipes-graphics/pango/pango_1.42.4.bb   |  1 +
 2 files changed, 37 insertions(+)
 create mode 100644 meta/recipes-graphics/pango/pango/CVE-2019-1010238.patch

diff --git a/meta/recipes-graphics/pango/pango/CVE-2019-1010238.patch 
b/meta/recipes-graphics/pango/pango/CVE-2019-1010238.patch
new file mode 100644
index 00..6f51490c31
--- /dev/null
+++ b/meta/recipes-graphics/pango/pango/CVE-2019-1010238.patch
@@ -0,0 +1,36 @@
+From 9fbb967a52c6a38bc5bc8612427e805b8bf276bd Mon Sep 17 00:00:00 2001
+From: Matthias Clasen 
+Date: Wed, 10 Jul 2019 20:26:23 -0400
+Subject: [PATCH] bidi: Be safer against bad input
+Reply-To: muis...@microsoft.com
+
+Don't run off the end of an array that we
+allocated to certain length.
+
+Closes: https://gitlab.gnome.org/GNOME/pango/issues/342
+Signed-off-by: Muminul Islam 
+---
+ pango/pango-bidi-type.c | 7 +--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+diff --git a/pango/pango-bidi-type.c b/pango/pango-bidi-type.c
+index a49e06d9..d169525e 100644
+--- a/pango/pango-bidi-type.c
 b/pango/pango-bidi-type.c
+@@ -179,8 +179,11 @@ pango_log2vis_get_embedding_levels (const gchar*text,
+   for (i = 0, p = text; p < text + length; p = g_utf8_next_char(p), i++)
+ {
+   gunichar ch = g_utf8_get_char (p);
+-  FriBidiCharType char_type;
+-  char_type = fribidi_get_bidi_type (ch);
++  FriBidiCharType char_type = fribidi_get_bidi_type (ch);
++
++  if (i == n_chars)
++break;
++
+   bidi_types[i] = char_type;
+   ored_types |= char_type;
+   if (FRIBIDI_IS_STRONG (char_type))
+-- 
+2.23.0
+
diff --git a/meta/recipes-graphics/pango/pango_1.42.4.bb 
b/meta/recipes-graphics/pango/pango_1.42.4.bb
index 22fe3af15d..34732fdd4b 100644
--- a/meta/recipes-graphics/pango/pango_1.42.4.bb
+++ b/meta/recipes-graphics/pango/pango_1.42.4.bb
@@ -15,6 +15,7 @@ inherit gnomebase gtk-doc ptest-gnome 
upstream-version-is-even gobject-introspec
 
 SRC_URI += "file://run-ptest \
 
file://0001-Enforce-recreation-of-docs-pango.types-it-is-build-c.patch \
+file://CVE-2019-1010238.patch \
 "
 SRC_URI[archive.md5sum] = "deb171a31a3ad76342d5195a1b5bbc7c"
 SRC_URI[archive.sha256sum] = 
"1d2b74cd63e8bd41961f2f8d952355aa0f9be6002b52c8aa7699d9f5da597c9d"
-- 
2.23.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][thud][PATCH v3] unzip: fix CVE-2019-13232

[Mittal, Anuj]

This applies as-is to master and warrior too since the versions there
are same. Can this be merged there too please since those branches are
also affected?

Thanks,

Anuj

On Wed, 2019-09-25 at 23:30 +, msft.dant...@gmail.com wrote:
> From: Dan Tran 
> 
> Signed-off-by: Dan Tran 
> ---
>  .../unzip/unzip/CVE-2019-13232_p1.patch   |  33 ++
>  .../unzip/unzip/CVE-2019-13232_p2.patch   | 356
> ++
>  .../unzip/unzip/CVE-2019-13232_p3.patch   | 121 ++
>  meta/recipes-extended/unzip/unzip_6.0.bb  |   3 +
>  4 files changed, 513 insertions(+)
>  create mode 100644 meta/recipes-extended/unzip/unzip/CVE-2019-
> 13232_p1.patch
>  create mode 100644 meta/recipes-extended/unzip/unzip/CVE-2019-
> 13232_p2.patch
>  create mode 100644 meta/recipes-extended/unzip/unzip/CVE-2019-
> 13232_p3.patch
> 
> diff --git a/meta/recipes-extended/unzip/unzip/CVE-2019-
> 13232_p1.patch b/meta/recipes-extended/unzip/unzip/CVE-2019-
> 13232_p1.patch
> new file mode 100644
> index 00..d485a1bd6e
> --- /dev/null
> +++ b/meta/recipes-extended/unzip/unzip/CVE-2019-13232_p1.patch
> @@ -0,0 +1,33 @@
> +From 080d52c3c9416c731f637f9c6e003961ef43f079 Mon Sep 17 00:00:00
> 2001
> +From: Mark Adler 
> +Date: Mon, 27 May 2019 08:20:32 -0700
> +Subject: [PATCH 1/3] Fix bug in undefer_input() that misplaced the
> input
> + state.
> +
> +CVE: CVE-2019-13232
> +Upstream-Status: Backport
> +[
> https://github.com/madler/unzip/commit/41beb477c5744bc396fa1162ee0c14218ec12213
> ]
> +
> +Signed-off-by: Dan Tran 
> +---
> + fileio.c | 4 +++-
> + 1 file changed, 3 insertions(+), 1 deletion(-)
> +
> +diff --git a/fileio.c b/fileio.c
> +index 7605a29..14460f3 100644
> +--- a/fileio.c
>  b/fileio.c
> +@@ -532,8 +532,10 @@ void undefer_input(__G)
> +  * This condition was checked when G.incnt_leftover was set
> > 0 in
> +  * defer_leftover_input(), and it is NOT allowed to touch
> G.csize
> +  * before calling undefer_input() when (G.incnt_leftover >
> 0)
> +- * (single exception: see read_byte()'s  "G.csize <= 0"
> handling) !!
> ++ * (single exception: see readbyte()'s  "G.csize <= 0"
> handling) !!
> +  */
> ++if (G.csize < 0L)
> ++G.csize = 0L;
> + G.incnt = G.incnt_leftover + (int)G.csize;
> + G.inptr = G.inptr_leftover - (int)G.csize;
> + G.incnt_leftover = 0;
> +-- 
> +2.22.0.vfs.1.1.57.gbaf16c8
> diff --git a/meta/recipes-extended/unzip/unzip/CVE-2019-
> 13232_p2.patch b/meta/recipes-extended/unzip/unzip/CVE-2019-
> 13232_p2.patch
> new file mode 100644
> index 00..41037a8e24
> --- /dev/null
> +++ b/meta/recipes-extended/unzip/unzip/CVE-2019-13232_p2.patch
> @@ -0,0 +1,356 @@
> +From 1aae47fa8935654a84403768f32c03ecbb1be470 Mon Sep 17 00:00:00
> 2001
> +From: Mark Adler 
> +Date: Tue, 11 Jun 2019 22:01:18 -0700
> +Subject: [PATCH 2/3] Detect and reject a zip bomb using overlapped
> entries.
> +
> +This detects an invalid zip file that has at least one entry that
> +overlaps with another entry or with the central directory to the
> +end of the file. A Fifield zip bomb uses overlapped local entries
> +to vastly increase the potential inflation ratio. Such an invalid
> +zip file is rejected.
> +
> +See https://www.bamsoftware.com/hacks/zipbomb/ for David Fifield's
> +analysis, construction, and examples of such zip bombs.
> +
> +The detection maintains a list of covered spans of the zip files
> +so far, where the central directory to the end of the file and any
> +bytes preceding the first entry at zip file offset zero are
> +considered covered initially. Then as each entry is decompressed
> +or tested, it is considered covered. When a new entry is about to
> +be processed, its initial offset is checked to see if it is
> +contained by a covered span. If so, the zip file is rejected as
> +invalid.
> +
> +This commit depends on a preceding commit: "Fix bug in
> +undefer_input() that misplaced the input state."
> +
> +CVE: CVE-2019-13232
> +Upstream-Status: Backport
> +[
> https://github.com/madler/unzip/commit/47b3ceae397d21bf822bc2ac73052a4b1daf8e1c
> ]
> +
> +Signed-off-by: Dan Tran 
> +---
> + extract.c | 190
> +-
> + globals.c |   1 +
> + globals.h |   3 +
> + process.c |  10 +++
> + unzip.h   |   1 +
> + 5 files changed, 204 insertions(+), 1 deletion(-)
> +
> +diff --git a/extract.c b/extract.c
> +index 24db2a8..2bb72ba 100644
> +--- a/extract.c
>  b/extract.c
> +@@ -321,6 +321,125 @@ static ZCONST char Far UnsupportedExtraField[]
> =
> +   "\nerror:  unsupported extra-field compression type (%u)
> --skipping\n";
> + static ZCONST char Far BadExtraFieldCRC[] =
> +   "error [%s]:  bad extra-field CRC %08lx (should be %08lx)\n";
> ++static ZCONST char Far NotEnoughMemCover[] =
> ++  "error: not enough memory for bomb detection\n";
> ++static ZCONST char Far OverlappedComponents[] =
> ++  "error: invalid zip file with overlapped components (possible zip

Re: [OE-core] [master][PATCH v3] esdk: Introduce mechanism to keep nativesdk* sstate in esdk

[Khem Raj]

actually this is not the culprit but setting SDK_INCLUDE_NATIVESDK =
"1" does help avoid this issue, the problem is in master I dont have
time to bisect it but it worked fine few weeks ago. For now I will
just set SDK_INCLUDE_NATIVESDK and move on

On Wed, Sep 25, 2019 at 3:21 PM Khem Raj  wrote:
>
> I think this is the reason why extensible sdk is not building for me,
> key is I am not setting SDK_INCLUDE_NATIVESDK
>
> The file local.conf.bak that it is not able to find to copy is
> actually inside sdk-ext/image/tmp-renamed-sdk/conf, So I wonder if
> renaming is happening inbetween copying ?
>
> Summary: 1 task failed:
>   
> /mnt/b/yoe/build/tmp/work/qemuriscv64-yoe-linux-musl/yoe-simple-image/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/openembedded-core/meta/recipes-core/meta/package-index.bb:do_package_index
> Summary: There was 1 ERROR message shown, returning a non-zero exit code.
> ERROR: yoe-simple-image-1.0-r0 do_populate_sdk_ext: Error executing a
> python function in exec_python_func() autogenerated:
>
> The stack trace of python calls that resulted in this exception/failure was:
> File: 'exec_python_func() autogenerated', lineno: 2, function: 
>  0001:
>  *** 0002:copy_buildsystem(d)
>  0003:
> File: 
> '/mnt/b/yoe/sources/openembedded-core/meta/classes/populate_sdk_ext.bbclass',
> lineno: 444, function: copy_buildsystem
>  0440:sdk_ext_type = d.getVar('SDK_EXT_TYPE')
>  0441:if (sdk_ext_type != 'minimal' or sdk_include_toolchain
> or derivative) and not sdk_include_nativesdk:
>  0442:# Create the filtered task list used to generate the
> sstate cache shipped with the SDK
>  0443:tasklistfn = d.getVar('WORKDIR') + '/tasklist.txt'
>  *** 0444:create_filtered_tasklist(d, baseoutpath, tasklistfn,
> conf_initpath)
>  0445:else:
>  0446:tasklistfn = None
>  0447:
>  0448:if os.path.exists(builddir + '/cache/bb_unihashes.dat'):
> File: 
> '/mnt/b/yoe/sources/openembedded-core/meta/classes/populate_sdk_ext.bbclass',
> lineno: 180, function: create_filtered_tasklist
>  0176:# Clean out residue of running bitbake, which
> check_sstate_task_list()
>  0177:# will effectively do
>  0178:clean_esdk_builddir(d, sdkbasepath)
>  0179:finally:
>  *** 0180:os.replace(sdkbasepath + '/conf/local.conf.bak',
> sdkbasepath + '/conf/local.conf')
>  0181:
>  0182:python copy_buildsystem () {
>  0183:import re
>  0184:import shutil
> Exception: FileNotFoundError: [Errno 2] No such file or directory:
> '/mnt/b/yoe/build/tmp/work/qemuriscv64-yoe-linux-musl/yoe-simple-image/1.0-r0/sdk-ext/image//opt/yoe/3.0/conf/local.conf.bak'
> -> 
> '/mnt/b/yoe/build/tmp/work/qemuriscv64-yoe-linux-musl/yoe-simple-image/1.0-r
> 0/sdk-ext/image//opt/yoe/3.0/conf/local.conf'
>
> ERROR: Logfile of failure stored in:
> /mnt/b/yoe/build/tmp/work/qemuriscv64-yoe-linux-musl/yoe-simple-image/1.0-r0/temp/log.do_populate_sdk_ext.1484013
>
> On Wed, Sep 18, 2019 at 10:43 AM Jaewon Lee  wrote:
> >
> > When doing a devtool build-sdk from within an esdk all nativesdk
> > components would be rebuilt. This patch introduces SDK_INCLUDE_NATIVESDK
> > flag to toggle the inclusion of nativesdk packages when creating the
> > esdk sstate
> >
> > Currently locked-sigs.inc is generated during do_sdk_depends which
> > doesn't pull in nativesdk packages. Generating another locked-sigs.inc
> > in do_populate_sdk_ext and pruning it to only nativesdk* packages by
> > using a modified version of the already existing function
> > prune_locked_sigs and merging it with the current locked-sigs.inc
> > Also adding SDK_INCLUDE_NATIVESDK tasklistfn to the logic surrounding
> > setting tasklist file to not prune esdk sstate during creation
> >
> > Fixes [YOCTO #13261]
> >
> > Signed-off-by: Jaewon Lee 
> > ---
> > changes in v2:
> > change to commit message to include reason
> > got rid of some tabs
> > rebased to apply on master
> > changes in v3:
> > fix patchwork failure for format of short commit message
> > ---
> >  meta/classes/populate_sdk_ext.bbclass | 28 +++-
> >  meta/lib/oe/copy_buildsystem.py   |  8 ++--
> >  2 files changed, 33 insertions(+), 3 deletions(-)
> >
> > diff --git a/meta/classes/populate_sdk_ext.bbclass 
> > b/meta/classes/populate_sdk_ext.bbclass
> > index 800e117..086f55d 100644
> > --- a/meta/classes/populate_sdk_ext.bbclass
> > +++ b/meta/classes/populate_sdk_ext.bbclass
> > @@ -20,6 +20,7 @@ SDK_EXT_task-populate-sdk-ext = "-ext"
> >  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_RECRDEP_TASKS ?= ""
> >
> > @@ -401,9 +402,27 @@ python copy_buildsystem () {
> >  excluded_targets = get_sdk_install_targets(d, images_only=True)
> >  sigfile = d.getVar('WORKDIR') + '/locked-sigs.inc'
> >  

[OE-core] [oe-core][thud][PATCH v3] unzip: fix CVE-2019-13232

[msft . dantran]

From: Dan Tran 

Signed-off-by: Dan Tran 
---
 .../unzip/unzip/CVE-2019-13232_p1.patch   |  33 ++
 .../unzip/unzip/CVE-2019-13232_p2.patch   | 356 ++
 .../unzip/unzip/CVE-2019-13232_p3.patch   | 121 ++
 meta/recipes-extended/unzip/unzip_6.0.bb  |   3 +
 4 files changed, 513 insertions(+)
 create mode 100644 meta/recipes-extended/unzip/unzip/CVE-2019-13232_p1.patch
 create mode 100644 meta/recipes-extended/unzip/unzip/CVE-2019-13232_p2.patch
 create mode 100644 meta/recipes-extended/unzip/unzip/CVE-2019-13232_p3.patch

diff --git a/meta/recipes-extended/unzip/unzip/CVE-2019-13232_p1.patch 
b/meta/recipes-extended/unzip/unzip/CVE-2019-13232_p1.patch
new file mode 100644
index 00..d485a1bd6e
--- /dev/null
+++ b/meta/recipes-extended/unzip/unzip/CVE-2019-13232_p1.patch
@@ -0,0 +1,33 @@
+From 080d52c3c9416c731f637f9c6e003961ef43f079 Mon Sep 17 00:00:00 2001
+From: Mark Adler 
+Date: Mon, 27 May 2019 08:20:32 -0700
+Subject: [PATCH 1/3] Fix bug in undefer_input() that misplaced the input
+ state.
+
+CVE: CVE-2019-13232
+Upstream-Status: Backport
+[https://github.com/madler/unzip/commit/41beb477c5744bc396fa1162ee0c14218ec12213]
+
+Signed-off-by: Dan Tran 
+---
+ fileio.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/fileio.c b/fileio.c
+index 7605a29..14460f3 100644
+--- a/fileio.c
 b/fileio.c
+@@ -532,8 +532,10 @@ void undefer_input(__G)
+  * This condition was checked when G.incnt_leftover was set > 0 in
+  * defer_leftover_input(), and it is NOT allowed to touch G.csize
+  * before calling undefer_input() when (G.incnt_leftover > 0)
+- * (single exception: see read_byte()'s  "G.csize <= 0" handling) !!
++ * (single exception: see readbyte()'s  "G.csize <= 0" handling) !!
+  */
++if (G.csize < 0L)
++G.csize = 0L;
+ G.incnt = G.incnt_leftover + (int)G.csize;
+ G.inptr = G.inptr_leftover - (int)G.csize;
+ G.incnt_leftover = 0;
+-- 
+2.22.0.vfs.1.1.57.gbaf16c8
diff --git a/meta/recipes-extended/unzip/unzip/CVE-2019-13232_p2.patch 
b/meta/recipes-extended/unzip/unzip/CVE-2019-13232_p2.patch
new file mode 100644
index 00..41037a8e24
--- /dev/null
+++ b/meta/recipes-extended/unzip/unzip/CVE-2019-13232_p2.patch
@@ -0,0 +1,356 @@
+From 1aae47fa8935654a84403768f32c03ecbb1be470 Mon Sep 17 00:00:00 2001
+From: Mark Adler 
+Date: Tue, 11 Jun 2019 22:01:18 -0700
+Subject: [PATCH 2/3] Detect and reject a zip bomb using overlapped entries.
+
+This detects an invalid zip file that has at least one entry that
+overlaps with another entry or with the central directory to the
+end of the file. A Fifield zip bomb uses overlapped local entries
+to vastly increase the potential inflation ratio. Such an invalid
+zip file is rejected.
+
+See https://www.bamsoftware.com/hacks/zipbomb/ for David Fifield's
+analysis, construction, and examples of such zip bombs.
+
+The detection maintains a list of covered spans of the zip files
+so far, where the central directory to the end of the file and any
+bytes preceding the first entry at zip file offset zero are
+considered covered initially. Then as each entry is decompressed
+or tested, it is considered covered. When a new entry is about to
+be processed, its initial offset is checked to see if it is
+contained by a covered span. If so, the zip file is rejected as
+invalid.
+
+This commit depends on a preceding commit: "Fix bug in
+undefer_input() that misplaced the input state."
+
+CVE: CVE-2019-13232
+Upstream-Status: Backport
+[https://github.com/madler/unzip/commit/47b3ceae397d21bf822bc2ac73052a4b1daf8e1c]
+
+Signed-off-by: Dan Tran 
+---
+ extract.c | 190 +-
+ globals.c |   1 +
+ globals.h |   3 +
+ process.c |  10 +++
+ unzip.h   |   1 +
+ 5 files changed, 204 insertions(+), 1 deletion(-)
+
+diff --git a/extract.c b/extract.c
+index 24db2a8..2bb72ba 100644
+--- a/extract.c
 b/extract.c
+@@ -321,6 +321,125 @@ static ZCONST char Far UnsupportedExtraField[] =
+   "\nerror:  unsupported extra-field compression type (%u)--skipping\n";
+ static ZCONST char Far BadExtraFieldCRC[] =
+   "error [%s]:  bad extra-field CRC %08lx (should be %08lx)\n";
++static ZCONST char Far NotEnoughMemCover[] =
++  "error: not enough memory for bomb detection\n";
++static ZCONST char Far OverlappedComponents[] =
++  "error: invalid zip file with overlapped components (possible zip bomb)\n";
++
++
++
++
++
++/* A growable list of spans. */
++typedef zoff_t bound_t;
++typedef struct {
++bound_t beg;/* start of the span */
++bound_t end;/* one past the end of the span */
++} span_t;
++typedef struct {
++span_t *span;   /* allocated, distinct, and sorted list of spans */
++size_t num; /* number of spans in the list */
++size_t max; /* allocated number of spans (num <= max) */
++} cover_t;
++
++/*
++ * Return the index of the first sp

Re: [OE-core] [oe-core][thud][PATCH v2] unzip: fix CVE-2019-13232

[Mittal, Anuj]

We should probably take this as well:

https://github.com/madler/unzip/commit/6d351831be705cc26d897db44f878a978f4138fc

See:

https://github.com/madler/unzip/commit/47b3ceae397d21bf822bc2ac73052a4b1daf8e1c#commitcomment-34460988

Debian has also applied all three patches.

Thanks,

Anuj

On Wed, 2019-09-25 at 22:41 +, msft.dant...@gmail.com wrote:
> From: Dan Tran 
> 
> Signed-off-by: Dan Tran 
> ---
>  .../unzip/unzip/CVE-2019-13232.patch  | 388
> ++
>  meta/recipes-extended/unzip/unzip_6.0.bb  |   1 +
>  2 files changed, 389 insertions(+)
>  create mode 100644 meta/recipes-extended/unzip/unzip/CVE-2019-
> 13232.patch
> 
> diff --git a/meta/recipes-extended/unzip/unzip/CVE-2019-13232.patch
> b/meta/recipes-extended/unzip/unzip/CVE-2019-13232.patch
> new file mode 100644
> index 00..08512bb0b1
> --- /dev/null
> +++ b/meta/recipes-extended/unzip/unzip/CVE-2019-13232.patch
> @@ -0,0 +1,388 @@
> +From 080d52c3c9416c731f637f9c6e003961ef43f079 Mon Sep 17 00:00:00
> 2001
> +From: Mark Adler 
> +Date: Mon, 27 May 2019 08:20:32 -0700
> +Subject: [PATCH 1/2] Fix bug in undefer_input() that misplaced the
> input
> + state.
> +
> +Signed-off-by: Dan Tran 
> +---
> + fileio.c | 4 +++-
> + 1 file changed, 3 insertions(+), 1 deletion(-)
> +
> +diff --git a/fileio.c b/fileio.c
> +index 7605a29..14460f3 100644
> +--- a/fileio.c
>  b/fileio.c
> +@@ -532,8 +532,10 @@ void undefer_input(__G)
> +  * This condition was checked when G.incnt_leftover was set
> > 0 in
> +  * defer_leftover_input(), and it is NOT allowed to touch
> G.csize
> +  * before calling undefer_input() when (G.incnt_leftover >
> 0)
> +- * (single exception: see read_byte()'s  "G.csize <= 0"
> handling) !!
> ++ * (single exception: see readbyte()'s  "G.csize <= 0"
> handling) !!
> +  */
> ++if (G.csize < 0L)
> ++G.csize = 0L;
> + G.incnt = G.incnt_leftover + (int)G.csize;
> + G.inptr = G.inptr_leftover - (int)G.csize;
> + G.incnt_leftover = 0;
> +-- 
> +2.22.0.vfs.1.1.57.gbaf16c8
> +
> +
> +From 1aae47fa8935654a84403768f32c03ecbb1be470 Mon Sep 17 00:00:00
> 2001
> +From: Mark Adler 
> +Date: Tue, 11 Jun 2019 22:01:18 -0700
> +Subject: [PATCH 2/2] Detect and reject a zip bomb using overlapped
> entries.
> +
> +This detects an invalid zip file that has at least one entry that
> +overlaps with another entry or with the central directory to the
> +end of the file. A Fifield zip bomb uses overlapped local entries
> +to vastly increase the potential inflation ratio. Such an invalid
> +zip file is rejected.
> +
> +See https://www.bamsoftware.com/hacks/zipbomb/ for David Fifield's
> +analysis, construction, and examples of such zip bombs.
> +
> +The detection maintains a list of covered spans of the zip files
> +so far, where the central directory to the end of the file and any
> +bytes preceding the first entry at zip file offset zero are
> +considered covered initially. Then as each entry is decompressed
> +or tested, it is considered covered. When a new entry is about to
> +be processed, its initial offset is checked to see if it is
> +contained by a covered span. If so, the zip file is rejected as
> +invalid.
> +
> +This commit depends on a preceding commit: "Fix bug in
> +undefer_input() that misplaced the input state."
> +
> +CVE: CVE-2019-13232
> +Upstream-Status: Backport
> +[
> https://github.com/madler/unzip/commit/47b3ceae397d21bf822bc2ac73052a4b1daf8e1c
> ]
> +
> +Signed-off-by: Dan Tran 
> +---
> + extract.c | 190
> +-
> + globals.c |   1 +
> + globals.h |   3 +
> + process.c |  10 +++
> + unzip.h   |   1 +
> + 5 files changed, 204 insertions(+), 1 deletion(-)
> +
> +diff --git a/extract.c b/extract.c
> +index 24db2a8..2bb72ba 100644
> +--- a/extract.c
>  b/extract.c
> +@@ -321,6 +321,125 @@ static ZCONST char Far UnsupportedExtraField[]
> =
> +   "\nerror:  unsupported extra-field compression type (%u)
> --skipping\n";
> + static ZCONST char Far BadExtraFieldCRC[] =
> +   "error [%s]:  bad extra-field CRC %08lx (should be %08lx)\n";
> ++static ZCONST char Far NotEnoughMemCover[] =
> ++  "error: not enough memory for bomb detection\n";
> ++static ZCONST char Far OverlappedComponents[] =
> ++  "error: invalid zip file with overlapped components (possible zip
> bomb)\n";
> ++
> ++
> ++
> ++
> ++
> ++/* A growable list of spans. */
> ++typedef zoff_t bound_t;
> ++typedef struct {
> ++bound_t beg;/* start of the span */
> ++bound_t end;/* one past the end of the span */
> ++} span_t;
> ++typedef struct {
> ++span_t *span;   /* allocated, distinct, and sorted list of
> spans */
> ++size_t num; /* number of spans in the list */
> ++size_t max; /* allocated number of spans (num <= max)
> */
> ++} cover_t;
> ++
> ++/*
> ++ * Return the index of the first span in cover whose beg is greater
> than val.
> ++ * If there 

[OE-core] [oe-core][thud][PATCH v2] unzip: fix CVE-2019-13232

[msft . dantran]

From: Dan Tran 

Signed-off-by: Dan Tran 
---
 .../unzip/unzip/CVE-2019-13232.patch  | 388 ++
 meta/recipes-extended/unzip/unzip_6.0.bb  |   1 +
 2 files changed, 389 insertions(+)
 create mode 100644 meta/recipes-extended/unzip/unzip/CVE-2019-13232.patch

diff --git a/meta/recipes-extended/unzip/unzip/CVE-2019-13232.patch 
b/meta/recipes-extended/unzip/unzip/CVE-2019-13232.patch
new file mode 100644
index 00..08512bb0b1
--- /dev/null
+++ b/meta/recipes-extended/unzip/unzip/CVE-2019-13232.patch
@@ -0,0 +1,388 @@
+From 080d52c3c9416c731f637f9c6e003961ef43f079 Mon Sep 17 00:00:00 2001
+From: Mark Adler 
+Date: Mon, 27 May 2019 08:20:32 -0700
+Subject: [PATCH 1/2] Fix bug in undefer_input() that misplaced the input
+ state.
+
+Signed-off-by: Dan Tran 
+---
+ fileio.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/fileio.c b/fileio.c
+index 7605a29..14460f3 100644
+--- a/fileio.c
 b/fileio.c
+@@ -532,8 +532,10 @@ void undefer_input(__G)
+  * This condition was checked when G.incnt_leftover was set > 0 in
+  * defer_leftover_input(), and it is NOT allowed to touch G.csize
+  * before calling undefer_input() when (G.incnt_leftover > 0)
+- * (single exception: see read_byte()'s  "G.csize <= 0" handling) !!
++ * (single exception: see readbyte()'s  "G.csize <= 0" handling) !!
+  */
++if (G.csize < 0L)
++G.csize = 0L;
+ G.incnt = G.incnt_leftover + (int)G.csize;
+ G.inptr = G.inptr_leftover - (int)G.csize;
+ G.incnt_leftover = 0;
+-- 
+2.22.0.vfs.1.1.57.gbaf16c8
+
+
+From 1aae47fa8935654a84403768f32c03ecbb1be470 Mon Sep 17 00:00:00 2001
+From: Mark Adler 
+Date: Tue, 11 Jun 2019 22:01:18 -0700
+Subject: [PATCH 2/2] Detect and reject a zip bomb using overlapped entries.
+
+This detects an invalid zip file that has at least one entry that
+overlaps with another entry or with the central directory to the
+end of the file. A Fifield zip bomb uses overlapped local entries
+to vastly increase the potential inflation ratio. Such an invalid
+zip file is rejected.
+
+See https://www.bamsoftware.com/hacks/zipbomb/ for David Fifield's
+analysis, construction, and examples of such zip bombs.
+
+The detection maintains a list of covered spans of the zip files
+so far, where the central directory to the end of the file and any
+bytes preceding the first entry at zip file offset zero are
+considered covered initially. Then as each entry is decompressed
+or tested, it is considered covered. When a new entry is about to
+be processed, its initial offset is checked to see if it is
+contained by a covered span. If so, the zip file is rejected as
+invalid.
+
+This commit depends on a preceding commit: "Fix bug in
+undefer_input() that misplaced the input state."
+
+CVE: CVE-2019-13232
+Upstream-Status: Backport
+[https://github.com/madler/unzip/commit/47b3ceae397d21bf822bc2ac73052a4b1daf8e1c]
+
+Signed-off-by: Dan Tran 
+---
+ extract.c | 190 +-
+ globals.c |   1 +
+ globals.h |   3 +
+ process.c |  10 +++
+ unzip.h   |   1 +
+ 5 files changed, 204 insertions(+), 1 deletion(-)
+
+diff --git a/extract.c b/extract.c
+index 24db2a8..2bb72ba 100644
+--- a/extract.c
 b/extract.c
+@@ -321,6 +321,125 @@ static ZCONST char Far UnsupportedExtraField[] =
+   "\nerror:  unsupported extra-field compression type (%u)--skipping\n";
+ static ZCONST char Far BadExtraFieldCRC[] =
+   "error [%s]:  bad extra-field CRC %08lx (should be %08lx)\n";
++static ZCONST char Far NotEnoughMemCover[] =
++  "error: not enough memory for bomb detection\n";
++static ZCONST char Far OverlappedComponents[] =
++  "error: invalid zip file with overlapped components (possible zip bomb)\n";
++
++
++
++
++
++/* A growable list of spans. */
++typedef zoff_t bound_t;
++typedef struct {
++bound_t beg;/* start of the span */
++bound_t end;/* one past the end of the span */
++} span_t;
++typedef struct {
++span_t *span;   /* allocated, distinct, and sorted list of spans */
++size_t num; /* number of spans in the list */
++size_t max; /* allocated number of spans (num <= max) */
++} cover_t;
++
++/*
++ * Return the index of the first span in cover whose beg is greater than val.
++ * If there is no such span, then cover->num is returned.
++ */
++static size_t cover_find(cover, val)
++cover_t *cover;
++bound_t val;
++{
++size_t lo = 0, hi = cover->num;
++while (lo < hi) {
++size_t mid = (lo + hi) >> 1;
++if (val < cover->span[mid].beg)
++hi = mid;
++else
++lo = mid + 1;
++}
++return hi;
++}
++
++/* Return true if val lies within any one of the spans in cover. */
++static int cover_within(cover, val)
++cover_t *cover;
++bound_t val;
++{
++size_t pos = cover_find(cover, val);
++return pos > 0 && val < cover->span[pos - 1].end;
++}

Re: [OE-core] [master][PATCH v3] esdk: Introduce mechanism to keep nativesdk* sstate in esdk

[Khem Raj]

I think this is the reason why extensible sdk is not building for me,
key is I am not setting SDK_INCLUDE_NATIVESDK

The file local.conf.bak that it is not able to find to copy is
actually inside sdk-ext/image/tmp-renamed-sdk/conf, So I wonder if
renaming is happening inbetween copying ?

Summary: 1 task failed:
  
/mnt/b/yoe/build/tmp/work/qemuriscv64-yoe-linux-musl/yoe-simple-image/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/openembedded-core/meta/recipes-core/meta/package-index.bb:do_package_index
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
ERROR: yoe-simple-image-1.0-r0 do_populate_sdk_ext: Error executing a
python function in exec_python_func() autogenerated:

The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: 
 0001:
 *** 0002:copy_buildsystem(d)
 0003:
File: 
'/mnt/b/yoe/sources/openembedded-core/meta/classes/populate_sdk_ext.bbclass',
lineno: 444, function: copy_buildsystem
 0440:sdk_ext_type = d.getVar('SDK_EXT_TYPE')
 0441:if (sdk_ext_type != 'minimal' or sdk_include_toolchain
or derivative) and not sdk_include_nativesdk:
 0442:# Create the filtered task list used to generate the
sstate cache shipped with the SDK
 0443:tasklistfn = d.getVar('WORKDIR') + '/tasklist.txt'
 *** 0444:create_filtered_tasklist(d, baseoutpath, tasklistfn,
conf_initpath)
 0445:else:
 0446:tasklistfn = None
 0447:
 0448:if os.path.exists(builddir + '/cache/bb_unihashes.dat'):
File: 
'/mnt/b/yoe/sources/openembedded-core/meta/classes/populate_sdk_ext.bbclass',
lineno: 180, function: create_filtered_tasklist
 0176:# Clean out residue of running bitbake, which
check_sstate_task_list()
 0177:# will effectively do
 0178:clean_esdk_builddir(d, sdkbasepath)
 0179:finally:
 *** 0180:os.replace(sdkbasepath + '/conf/local.conf.bak',
sdkbasepath + '/conf/local.conf')
 0181:
 0182:python copy_buildsystem () {
 0183:import re
 0184:import shutil
Exception: FileNotFoundError: [Errno 2] No such file or directory:
'/mnt/b/yoe/build/tmp/work/qemuriscv64-yoe-linux-musl/yoe-simple-image/1.0-r0/sdk-ext/image//opt/yoe/3.0/conf/local.conf.bak'
-> '/mnt/b/yoe/build/tmp/work/qemuriscv64-yoe-linux-musl/yoe-simple-image/1.0-r
0/sdk-ext/image//opt/yoe/3.0/conf/local.conf'

ERROR: Logfile of failure stored in:
/mnt/b/yoe/build/tmp/work/qemuriscv64-yoe-linux-musl/yoe-simple-image/1.0-r0/temp/log.do_populate_sdk_ext.1484013

On Wed, Sep 18, 2019 at 10:43 AM Jaewon Lee  wrote:
>
> When doing a devtool build-sdk from within an esdk all nativesdk
> components would be rebuilt. This patch introduces SDK_INCLUDE_NATIVESDK
> flag to toggle the inclusion of nativesdk packages when creating the
> esdk sstate
>
> Currently locked-sigs.inc is generated during do_sdk_depends which
> doesn't pull in nativesdk packages. Generating another locked-sigs.inc
> in do_populate_sdk_ext and pruning it to only nativesdk* packages by
> using a modified version of the already existing function
> prune_locked_sigs and merging it with the current locked-sigs.inc
> Also adding SDK_INCLUDE_NATIVESDK tasklistfn to the logic surrounding
> setting tasklist file to not prune esdk sstate during creation
>
> Fixes [YOCTO #13261]
>
> Signed-off-by: Jaewon Lee 
> ---
> changes in v2:
> change to commit message to include reason
> got rid of some tabs
> rebased to apply on master
> changes in v3:
> fix patchwork failure for format of short commit message
> ---
>  meta/classes/populate_sdk_ext.bbclass | 28 +++-
>  meta/lib/oe/copy_buildsystem.py   |  8 ++--
>  2 files changed, 33 insertions(+), 3 deletions(-)
>
> diff --git a/meta/classes/populate_sdk_ext.bbclass 
> b/meta/classes/populate_sdk_ext.bbclass
> index 800e117..086f55d 100644
> --- a/meta/classes/populate_sdk_ext.bbclass
> +++ b/meta/classes/populate_sdk_ext.bbclass
> @@ -20,6 +20,7 @@ SDK_EXT_task-populate-sdk-ext = "-ext"
>  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_RECRDEP_TASKS ?= ""
>
> @@ -401,9 +402,27 @@ python copy_buildsystem () {
>  excluded_targets = get_sdk_install_targets(d, images_only=True)
>  sigfile = d.getVar('WORKDIR') + '/locked-sigs.inc'
>  lockedsigs_pruned = baseoutpath + '/conf/locked-sigs.inc'
> +#nativesdk-only sigfile to merge into locked-sigs.inc
> +sdk_include_nativesdk = (d.getVar("SDK_INCLUDE_NATIVESDK") == '1')
> +nativesigfile = d.getVar('WORKDIR') + '/locked-sigs_nativesdk.inc'
> +nativesigfile_pruned = d.getVar('WORKDIR') + 
> '/locked-sigs_nativesdk_pruned.inc'
> +
> +if sdk_include_nativesdk:
> +oe.copy_buildsystem.prune_lockedsigs([],
> + exclude

[OE-core] [PATCH] qemuriscv: Do not blacklist clang anymore

[Khem Raj]

clang 9.x ( which is now default in meta-clang ) supports riscv

Signed-off-by: Khem Raj 
---
 meta/conf/machine/include/riscv/qemuriscv.inc | 13 -
 1 file changed, 13 deletions(-)

diff --git a/meta/conf/machine/include/riscv/qemuriscv.inc 
b/meta/conf/machine/include/riscv/qemuriscv.inc
index df35f2808f..a42346f361 100644
--- a/meta/conf/machine/include/riscv/qemuriscv.inc
+++ b/meta/conf/machine/include/riscv/qemuriscv.inc
@@ -36,16 +36,3 @@ QB_TCPSERIAL_OPT = " -device virtio-serial-device -chardev 
socket,id=virtcon,por
 # Add the 'virtio-rng-pci' device otherwise the guest may run out of entropy
 QB_OPT_APPEND = " -object rng-random,filename=/dev/urandom,id=rng0 -device 
virtio-rng-device,rng=rng0"
 
-BAD_RECOMMENDATIONS += "\
-libcxx-dev \
-libcxx-staticdev \
-compiler-rt-dev \
-compiler-rt-staticdev \
-"
-
-ASSUME_PROVIDED += "\
-libcxx-dev \
-libcxx-staticdev \
-compiler-rt-dev \
-compiler-rt-staticdev \
-"
-- 
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/1] openssl: make OPENSSL_ENGINES match install path

[Khem Raj]

On Wed, Sep 25, 2019 at 2:30 PM George McCollister
 wrote:
>
> On Wed, Sep 25, 2019 at 1:34 PM Khem Raj  wrote:
> >
> > On 9/25/19 11:13 AM, George McCollister wrote:
> > > On Wed, Sep 25, 2019 at 11:08 AM Mark Hatle
> > >  wrote:
> > >>
> > >> On 9/25/19 6:52 AM, George McCollister wrote:
> > >>> Set OPENSSL_ENGINES to the path where engines are actually installed.
> > >>>
> > >>> Signed-off-by: George McCollister 
> > >>> ---
> > >>>   meta/recipes-connectivity/openssl/openssl_1.1.1d.bb | 2 +-
> > >>>   1 file changed, 1 insertion(+), 1 deletion(-)
> > >>>
> > >>> diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb 
> > >>> b/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
> > >>> index 072f727e0b..8819e19ec4 100644
> > >>> --- a/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
> > >>> +++ b/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
> > >>> @@ -148,7 +148,7 @@ do_install_append_class-native () {
> > >>>OPENSSL_CONF=${libdir}/ssl-1.1/openssl.cnf \
> > >>>SSL_CERT_DIR=${libdir}/ssl-1.1/certs \
> > >>>SSL_CERT_FILE=${libdir}/ssl-1.1/cert.pem \
> > >>> - OPENSSL_ENGINES=${libdir}/ssl-1.1/engines
> > >>> + OPENSSL_ENGINES=${libdir}/engines-1.1
> > >>
> > >> Is this a bug in the openssl recipe (it's placing engines in the wrong 
> > >> place),
> > >> or a bug in the recipes providing acceleration engines and THEY are 
> > >> going into
> > >> the wrong place?
> > >
> > > This recipe installs:
> > > packages-split/openssl-engines/usr/lib/engines-1.1/afalg.so
> > > packages-split/openssl-engines/usr/lib/engines-1.1/padlock.so
> > > packages-split/openssl-engines/usr/lib/engines-1.1/capi.so
> > >
> > > libp11 in meta-oe installs these:
> > > packages-split/libp11/usr/lib/engines-1.1
> > > packages-split/libp11/usr/lib/engines-1.1/pkcs11.so
> > > packages-split/libp11-dev/usr/lib/engines-1.1
> > > packages-split/libp11-dev/usr/lib/engines-1.1/libpkcs11.so
> > >
> > >>
> > >> The ssl-1.1/engines makes more sense to me..  as /usr/lib/engines-1.1 
> > >> obscures
> > >> that they are OpenSSL related.
> > >
> > > I don't have a strong opinion either way but ssl-1.1/engines does make
> > > a bit more sense.
> > > Debian appears to install them in engines-1.1 though:
> > >   https://packages.debian.org/buster/amd64/libssl1.1/filelist
> > >
> > > I do need this fixed in warrior though and wonder if anyone would
> > > gripe about changing where they are installed post release.
> > >
> > > How shall we proceed? Does anyone else want to chime in?
> > >
> >
> > Using /usr/lib/ is known jargon and lets use it. I think doing
> > it the way other distros are doing it and how upstream defaults are is
> > also helpful. it reduced one more thing to worry about. Release branches
> > should not be an issue as long as we have them packages in same output
> > package.
>
> It looks like Fedora is also using engines-1.1:
> https://apps.fedoraproject.org/packages/openssl-libs/
>
> I've found there is no Configure switch to set the engines directory.
> I believe it will require a patch to changes 3 - 4 lines in
> Configurations/unix-Makefile.tmpl.
> meta-oe/recipes-support/libp11/libp11_0.4.10.bb would also need to be
> changed to use the new path.
>
> Is carrying a custom patch to deviate from the upstream package and
> major distribution behavior really wise?
>

right. so lets not do it.

> If there is somewhat of a consensus to go that way knowing it requires
> a custom patch I'll send a patch for openssl and then one to fix
> libp11 (which the first patch will break).
>
> >
> > >>
> > >> --Mark
> > >>
> > >>>   }
> > >>>
> > >>>   do_install_append_class-nativesdk () {
> > >>>
> > >>
> > >> --
> > >> ___
> > >> Openembedded-core mailing list
> > >> Openembedded-core@lists.openembedded.org
> > >> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> > >
> > > -George
> > >
> >
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] openssl: make OPENSSL_ENGINES match install path

[George McCollister]

On Wed, Sep 25, 2019 at 1:34 PM Khem Raj  wrote:
>
> On 9/25/19 11:13 AM, George McCollister wrote:
> > On Wed, Sep 25, 2019 at 11:08 AM Mark Hatle
> >  wrote:
> >>
> >> On 9/25/19 6:52 AM, George McCollister wrote:
> >>> Set OPENSSL_ENGINES to the path where engines are actually installed.
> >>>
> >>> Signed-off-by: George McCollister 
> >>> ---
> >>>   meta/recipes-connectivity/openssl/openssl_1.1.1d.bb | 2 +-
> >>>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb 
> >>> b/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
> >>> index 072f727e0b..8819e19ec4 100644
> >>> --- a/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
> >>> +++ b/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
> >>> @@ -148,7 +148,7 @@ do_install_append_class-native () {
> >>>OPENSSL_CONF=${libdir}/ssl-1.1/openssl.cnf \
> >>>SSL_CERT_DIR=${libdir}/ssl-1.1/certs \
> >>>SSL_CERT_FILE=${libdir}/ssl-1.1/cert.pem \
> >>> - OPENSSL_ENGINES=${libdir}/ssl-1.1/engines
> >>> + OPENSSL_ENGINES=${libdir}/engines-1.1
> >>
> >> Is this a bug in the openssl recipe (it's placing engines in the wrong 
> >> place),
> >> or a bug in the recipes providing acceleration engines and THEY are going 
> >> into
> >> the wrong place?
> >
> > This recipe installs:
> > packages-split/openssl-engines/usr/lib/engines-1.1/afalg.so
> > packages-split/openssl-engines/usr/lib/engines-1.1/padlock.so
> > packages-split/openssl-engines/usr/lib/engines-1.1/capi.so
> >
> > libp11 in meta-oe installs these:
> > packages-split/libp11/usr/lib/engines-1.1
> > packages-split/libp11/usr/lib/engines-1.1/pkcs11.so
> > packages-split/libp11-dev/usr/lib/engines-1.1
> > packages-split/libp11-dev/usr/lib/engines-1.1/libpkcs11.so
> >
> >>
> >> The ssl-1.1/engines makes more sense to me..  as /usr/lib/engines-1.1 
> >> obscures
> >> that they are OpenSSL related.
> >
> > I don't have a strong opinion either way but ssl-1.1/engines does make
> > a bit more sense.
> > Debian appears to install them in engines-1.1 though:
> >   https://packages.debian.org/buster/amd64/libssl1.1/filelist
> >
> > I do need this fixed in warrior though and wonder if anyone would
> > gripe about changing where they are installed post release.
> >
> > How shall we proceed? Does anyone else want to chime in?
> >
>
> Using /usr/lib/ is known jargon and lets use it. I think doing
> it the way other distros are doing it and how upstream defaults are is
> also helpful. it reduced one more thing to worry about. Release branches
> should not be an issue as long as we have them packages in same output
> package.

It looks like Fedora is also using engines-1.1:
https://apps.fedoraproject.org/packages/openssl-libs/

I've found there is no Configure switch to set the engines directory.
I believe it will require a patch to changes 3 - 4 lines in
Configurations/unix-Makefile.tmpl.
meta-oe/recipes-support/libp11/libp11_0.4.10.bb would also need to be
changed to use the new path.

Is carrying a custom patch to deviate from the upstream package and
major distribution behavior really wise?

If there is somewhat of a consensus to go that way knowing it requires
a custom patch I'll send a patch for openssl and then one to fix
libp11 (which the first patch will break).

>
> >>
> >> --Mark
> >>
> >>>   }
> >>>
> >>>   do_install_append_class-nativesdk () {
> >>>
> >>
> >> --
> >> ___
> >> Openembedded-core mailing list
> >> Openembedded-core@lists.openembedded.org
> >> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >
> > -George
> >
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] nativesdk-dnf: ensure installed systemd files are shipped

[Ross Burton]

On 25/09/2019 20:17, Trevor Gamblin wrote:

On 9/24/19 12:15 PM, Ross Burton wrote:


On 24/09/2019 15:01, Trevor Gamblin wrote:

From: Trevor Gamblin 

"bitbake nativesdk-dnf" throws a QA warning if the contents of
${base_libdir}/systemd/system/ are not shipped, so add them.


Looks like a bug in systemd.bbclass, not this recipe.  For example if 
I enable nativesdk for acpid:


Can you clarify what you meant? Did you mean that the class should be 
doing the cleanup of the systemd service files?


If the intention is that unit files don't get installed/managed/etc in 
nativesdk, then yes the class should be removing them.


Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] bmap-tools: add missing python3-misc dependency

[Ross Burton]

On 25/09/2019 15:49, Diego Rondini wrote:

Add runtime dependency on python3-misc as bmaptool depends on ntpath.

Signed-off-by: Diego Rondini 
---
  meta/recipes-support/bmap-tools/bmap-tools_3.5.bb | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-support/bmap-tools/bmap-tools_3.5.bb 
b/meta/recipes-support/bmap-tools/bmap-tools_3.5.bb
index 7c4db85b32..6be07d7f9c 100644
--- a/meta/recipes-support/bmap-tools/bmap-tools_3.5.bb
+++ b/meta/recipes-support/bmap-tools/bmap-tools_3.5.bb
@@ -17,7 +17,7 @@ PV .= "+git${SRCPV}"
  
  UPSTREAM_CHECK_GITTAGREGEX = "v(?P\d+(\.\d+)+)"
  
-RDEPENDS_${PN} = "python3-core python3-compression python3-mmap python3-setuptools python3-fcntl python3-six"

+RDEPENDS_${PN} = "python3-core python3-compression python3-mmap python3-setuptools 
python3-fcntl python3-six python3-misc"
  
  inherit python3native

  inherit setuptools3



ERROR: Nothing RPROVIDES 'python3-misc-native' (but 
virtual:native:/home/ross/Yocto/poky/meta/recipes-support/bmap-tools/bmap-tools_3.5.bb 
RDEPENDS on or otherwise requires it)


Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] wic: Using the right rootfs size during prepare_rootfs

[Jason Wessel]

This definitely doesn't work as is, for the case where you use additional 
rootfs-dir variables in the .wks.in file.

I made a sample .wks.in file with the following and build core-image-minimal.

bootloader --ptable gpt
part / --source rootfs --ondisk sda --fstype=ext4 --label otaboot1 --align 4
part / --source rootfs --rootfs-dir=${WORKDIR}/rootfs_ota --ondisk sda 
--fstype=ext4 --label otaboot --align 4
part / --source rootfs --rootfs-dir=${WORKDIR}/rootfs_boot --ondisk sda 
--fstype=ext4 --label otaroot --align 4
part / --source rootfs --rootfs-dir=${WORKDIR}/rootfs_ota --ondisk sda 
--fstype=ext4 --label otaboot_b --align 4
part / --source rootfs --rootfs-dir=${WORKDIR}/rootfs_boot --ondisk sda 
--fstype=ext4 --label otaroot_b --align 4

The first time through it will die because we don't have a bbclass which is 
creating and populating the directories, so I just filled the directories with 
some random contents since I wasn't going to boot this image.

mkdir -p tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/rootfs_boot
mkdir -p tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/rootfs_ota

To see how it worked for your case, I left the first partition as a default with the standard 
"rootfs" and updated the IMAGE_ROOT_SIZE = "1024000".  That caused wic to 
create five 1.3 gig partitions.

I created a patch on top of what you provided which seems to address the 
problem the new patch creates.


diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
index 81df15f71b..d809408e1a 100644
--- a/scripts/lib/wic/partition.py
+++ b/scripts/lib/wic/partition.py
@@ -216,7 +216,8 @@ class Partition():
 # The rootfs size is not set in .ks file so try to get it
 # from bitbake variable
 rsize_bb = get_bitbake_var('ROOTFS_SIZE')
-if rsize_bb:
+rdir = get_bitbake_var('IMAGE_ROOTFS')
+if rsize_bb and rdir == rootfs_dir:
 # Bitbake variable ROOTFS_SIZE is calculated in
 # Image._get_rootfs_size method from meta/lib/oe/image.py
 # using IMAGE_ROOTFS_SIZE, IMAGE_ROOTFS_ALIGNMENT,





Using the patch above, plus your patch, I can see the resulting image computes 
the size automatically for the other partitions.


% fdisk -l tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.wic
Disklabel type: gpt
Disk identifier: C024DE9A-1213-4D0B-8FEB-1C97CFB36FC1

DeviceStart End 
Sectors   Size Type
tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.wic1  40 2673089 
2673050   1.3G Linux filesystem
tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.wic2 2673096 3291271 
 618176 301.9M Linux filesystem
tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.wic3 3291272 3317907 
  2663613M Linux filesystem
tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.wic4 3317912 3936087 
 618176 301.9M Linux filesystem
tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.wic5 3936088 3962723 
  2663613M Linux filesystem

---

If you wish to submit your patch, please either merge in my patch, which is 
attached, or submit both patches together, else it will regress the automatic 
partition sizing fixes.

Thanks,
Jason.


On 9/25/19 10:05 AM, Alessio Igor Bogani wrote:

The commit 8e48b4d6c4 makes wic ignores IMAGE_ROOTFS_SIZE for rootfs
size and makes it uses the computed one only. Re-add support for
IMAGE_ROOTFS_SIZE variable and compute roots size only if the former
is not defined.

Signed-off-by: Alessio Igor Bogani 
---
  scripts/lib/wic/partition.py | 22 --
  1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
index 2a71d7b1d6..81df15f71b 100644
--- a/scripts/lib/wic/partition.py
+++ b/scripts/lib/wic/partition.py
@@ -212,13 +212,23 @@ class Partition():
  if os.path.isfile(rootfs):
  os.remove(rootfs)
  
-# If size is not specified compute it from the rootfs_dir size

  if not self.size and real_rootfs:
-# Use the same logic found in get_rootfs_size()
-# from meta/classes/image.bbclass
-du_cmd = "du -ks %s" % rootfs_dir
-out = exec_cmd(du_cmd)
-self.size = int(out.split()[0])
+# The rootfs size is not set in .ks file so try to get it
+# from bitbake variable
+rsize_bb = get_bitbake_var('ROOTFS_SIZE')
+if rsize_bb:
+# Bitbake variable ROOTFS_SIZE is calculated in
+# Image._get_rootfs_size method from meta/lib/oe/image.py
+# using IMAGE_ROOTFS_SIZE, IMAGE_ROOTFS_ALIGNMENT,
+# IMAGE_OVERHEAD_FACTOR and IMAGE_ROOTFS_EXTRA_SPACE
+self.size = int(round(float(rsize_bb)))
+else:
+# Bitbake variable ROOTFS_SIZE is not defined so compute i

Re: [OE-core] [PATCH 1/1] openssl: make OPENSSL_ENGINES match install path

[Andre McCurdy]

On Wed, Sep 25, 2019 at 12:13 PM George McCollister
 wrote:
> On Wed, Sep 25, 2019 at 1:37 PM Andre McCurdy  wrote:
> >
> > On Wed, Sep 25, 2019 at 11:13 AM George McCollister
> >  wrote:
> > > On Wed, Sep 25, 2019 at 11:08 AM Mark Hatle
> > >  wrote:
> > > > On 9/25/19 6:52 AM, George McCollister wrote:
> > > > > Set OPENSSL_ENGINES to the path where engines are actually installed.
> > > > >
> > > > > Signed-off-by: George McCollister 
> > > > > ---
> > > > >  meta/recipes-connectivity/openssl/openssl_1.1.1d.bb | 2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb 
> > > > > b/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
> > > > > index 072f727e0b..8819e19ec4 100644
> > > > > --- a/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
> > > > > +++ b/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
> > > > > @@ -148,7 +148,7 @@ do_install_append_class-native () {
> > > > >   OPENSSL_CONF=${libdir}/ssl-1.1/openssl.cnf \
> > > > >   SSL_CERT_DIR=${libdir}/ssl-1.1/certs \
> > > > >   SSL_CERT_FILE=${libdir}/ssl-1.1/cert.pem \
> > > > > - OPENSSL_ENGINES=${libdir}/ssl-1.1/engines
> > > > > + OPENSSL_ENGINES=${libdir}/engines-1.1
> > > >
> > > > Is this a bug in the openssl recipe (it's placing engines in the wrong 
> > > > place),
> > > > or a bug in the recipes providing acceleration engines and THEY are 
> > > > going into
> > > > the wrong place?
> > >
> > > This recipe installs:
> > > packages-split/openssl-engines/usr/lib/engines-1.1/afalg.so
> > > packages-split/openssl-engines/usr/lib/engines-1.1/padlock.so
> > > packages-split/openssl-engines/usr/lib/engines-1.1/capi.so
> > >
> > > libp11 in meta-oe installs these:
> > > packages-split/libp11/usr/lib/engines-1.1
> > > packages-split/libp11/usr/lib/engines-1.1/pkcs11.so
> > > packages-split/libp11-dev/usr/lib/engines-1.1
> > > packages-split/libp11-dev/usr/lib/engines-1.1/libpkcs11.so
> > >
> > > >
> > > > The ssl-1.1/engines makes more sense to me..  as /usr/lib/engines-1.1 
> > > > obscures
> > > > that they are OpenSSL related.
> > >
> > > I don't have a strong opinion either way but ssl-1.1/engines does make
> > > a bit more sense.
> > > Debian appears to install them in engines-1.1 though:
> > >  https://packages.debian.org/buster/amd64/libssl1.1/filelist
> >
> > It would be interesting to know when the path in the -native wrapper
> > script stopped matching the path where the engines plugins are
> > installed. ie was the wrapper script always wrong? Did the default
> > install path used by openssl change at some point?
>
> It's been wrong on and off with openssl 1.0 and I believe always wrong
> with openssl 1.1.
>
> >
> > > I do need this fixed in warrior though and wonder if anyone would
> > > gripe about changing where they are installed post release.
> > >
> > > How shall we proceed? Does anyone else want to chime in?
> >
> > The change being proposed is for the openssl-native wrapper script, so
> > won't affect anything on the target.
> >
> > I'm curious why openssl-native needs engines plugins at all?
>
> I need the pkcs11 engine for pkcs11 signing with an HSM. Unfortunately
> for me most people won't notice if the wrapper doesn't match the
> installed plugin path.

OK. Not a use case which others are very likely to see, but good to
have it fixed anyway.

Note that (for unknown historical reasons) native and nativesdk use
different approaches to ensuring that these paths are correctly
defined. Native uses a wrapper script and nativesdk exports
environment variables globally via the SDK environment-setup script.
They probably both need fixing.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] nativesdk-dnf: ensure installed systemd files are shipped

[Trevor Gamblin]

On 9/24/19 12:15 PM, Ross Burton wrote:


On 24/09/2019 15:01, Trevor Gamblin wrote:

From: Trevor Gamblin 

"bitbake nativesdk-dnf" throws a QA warning if the contents of
${base_libdir}/systemd/system/ are not shipped, so add them.


Looks like a bug in systemd.bbclass, not this recipe.  For example if 
I enable nativesdk for acpid:


Can you clarify what you meant? Did you mean that the class should be 
doing the cleanup of the systemd service files?




ERROR: nativesdk-acpid-2.0.32-r0 do_package: QA Issue: 
nativesdk-acpid: Files/directories were installed but not shipped in 
any package:

  /opt/poky/2.7+snapshot/sysroots/x86_64-pokysdk-linux/lib
  /opt/poky/2.7+snapshot/sysroots/x86_64-pokysdk-linux/lib/systemd
/opt/poky/2.7+snapshot/sysroots/x86_64-pokysdk-linux/lib/systemd/system

/opt/poky/2.7+snapshot/sysroots/x86_64-pokysdk-linux/lib/systemd/system/acpid.service 



Ross

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] openssl: make OPENSSL_ENGINES match install path

[George McCollister]

On Wed, Sep 25, 2019 at 1:37 PM Andre McCurdy  wrote:
>
> On Wed, Sep 25, 2019 at 11:13 AM George McCollister
>  wrote:
> > On Wed, Sep 25, 2019 at 11:08 AM Mark Hatle
> >  wrote:
> > > On 9/25/19 6:52 AM, George McCollister wrote:
> > > > Set OPENSSL_ENGINES to the path where engines are actually installed.
> > > >
> > > > Signed-off-by: George McCollister 
> > > > ---
> > > >  meta/recipes-connectivity/openssl/openssl_1.1.1d.bb | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb 
> > > > b/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
> > > > index 072f727e0b..8819e19ec4 100644
> > > > --- a/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
> > > > +++ b/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
> > > > @@ -148,7 +148,7 @@ do_install_append_class-native () {
> > > >   OPENSSL_CONF=${libdir}/ssl-1.1/openssl.cnf \
> > > >   SSL_CERT_DIR=${libdir}/ssl-1.1/certs \
> > > >   SSL_CERT_FILE=${libdir}/ssl-1.1/cert.pem \
> > > > - OPENSSL_ENGINES=${libdir}/ssl-1.1/engines
> > > > + OPENSSL_ENGINES=${libdir}/engines-1.1
> > >
> > > Is this a bug in the openssl recipe (it's placing engines in the wrong 
> > > place),
> > > or a bug in the recipes providing acceleration engines and THEY are going 
> > > into
> > > the wrong place?
> >
> > This recipe installs:
> > packages-split/openssl-engines/usr/lib/engines-1.1/afalg.so
> > packages-split/openssl-engines/usr/lib/engines-1.1/padlock.so
> > packages-split/openssl-engines/usr/lib/engines-1.1/capi.so
> >
> > libp11 in meta-oe installs these:
> > packages-split/libp11/usr/lib/engines-1.1
> > packages-split/libp11/usr/lib/engines-1.1/pkcs11.so
> > packages-split/libp11-dev/usr/lib/engines-1.1
> > packages-split/libp11-dev/usr/lib/engines-1.1/libpkcs11.so
> >
> > >
> > > The ssl-1.1/engines makes more sense to me..  as /usr/lib/engines-1.1 
> > > obscures
> > > that they are OpenSSL related.
> >
> > I don't have a strong opinion either way but ssl-1.1/engines does make
> > a bit more sense.
> > Debian appears to install them in engines-1.1 though:
> >  https://packages.debian.org/buster/amd64/libssl1.1/filelist
>
> It would be interesting to know when the path in the -native wrapper
> script stopped matching the path where the engines plugins are
> installed. ie was the wrapper script always wrong? Did the default
> install path used by openssl change at some point?

It's been wrong on and off with openssl 1.0 and I believe always wrong
with openssl 1.1.

>
> > I do need this fixed in warrior though and wonder if anyone would
> > gripe about changing where they are installed post release.
> >
> > How shall we proceed? Does anyone else want to chime in?
>
> The change being proposed is for the openssl-native wrapper script, so
> won't affect anything on the target.
>
> I'm curious why openssl-native needs engines plugins at all?

I need the pkcs11 engine for pkcs11 signing with an HSM. Unfortunately
for me most people won't notice if the wrapper doesn't match the
installed plugin path.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] openssl: make OPENSSL_ENGINES match install path

[Andre McCurdy]

On Wed, Sep 25, 2019 at 11:13 AM George McCollister
 wrote:
> On Wed, Sep 25, 2019 at 11:08 AM Mark Hatle
>  wrote:
> > On 9/25/19 6:52 AM, George McCollister wrote:
> > > Set OPENSSL_ENGINES to the path where engines are actually installed.
> > >
> > > Signed-off-by: George McCollister 
> > > ---
> > >  meta/recipes-connectivity/openssl/openssl_1.1.1d.bb | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb 
> > > b/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
> > > index 072f727e0b..8819e19ec4 100644
> > > --- a/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
> > > +++ b/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
> > > @@ -148,7 +148,7 @@ do_install_append_class-native () {
> > >   OPENSSL_CONF=${libdir}/ssl-1.1/openssl.cnf \
> > >   SSL_CERT_DIR=${libdir}/ssl-1.1/certs \
> > >   SSL_CERT_FILE=${libdir}/ssl-1.1/cert.pem \
> > > - OPENSSL_ENGINES=${libdir}/ssl-1.1/engines
> > > + OPENSSL_ENGINES=${libdir}/engines-1.1
> >
> > Is this a bug in the openssl recipe (it's placing engines in the wrong 
> > place),
> > or a bug in the recipes providing acceleration engines and THEY are going 
> > into
> > the wrong place?
>
> This recipe installs:
> packages-split/openssl-engines/usr/lib/engines-1.1/afalg.so
> packages-split/openssl-engines/usr/lib/engines-1.1/padlock.so
> packages-split/openssl-engines/usr/lib/engines-1.1/capi.so
>
> libp11 in meta-oe installs these:
> packages-split/libp11/usr/lib/engines-1.1
> packages-split/libp11/usr/lib/engines-1.1/pkcs11.so
> packages-split/libp11-dev/usr/lib/engines-1.1
> packages-split/libp11-dev/usr/lib/engines-1.1/libpkcs11.so
>
> >
> > The ssl-1.1/engines makes more sense to me..  as /usr/lib/engines-1.1 
> > obscures
> > that they are OpenSSL related.
>
> I don't have a strong opinion either way but ssl-1.1/engines does make
> a bit more sense.
> Debian appears to install them in engines-1.1 though:
>  https://packages.debian.org/buster/amd64/libssl1.1/filelist

It would be interesting to know when the path in the -native wrapper
script stopped matching the path where the engines plugins are
installed. ie was the wrapper script always wrong? Did the default
install path used by openssl change at some point?

> I do need this fixed in warrior though and wonder if anyone would
> gripe about changing where they are installed post release.
>
> How shall we proceed? Does anyone else want to chime in?

The change being proposed is for the openssl-native wrapper script, so
won't affect anything on the target.

I'm curious why openssl-native needs engines plugins at all?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] openssl: make OPENSSL_ENGINES match install path

[Khem Raj]

On 9/25/19 11:13 AM, George McCollister wrote:

On Wed, Sep 25, 2019 at 11:08 AM Mark Hatle
 wrote:


On 9/25/19 6:52 AM, George McCollister wrote:

Set OPENSSL_ENGINES to the path where engines are actually installed.

Signed-off-by: George McCollister 
---
  meta/recipes-connectivity/openssl/openssl_1.1.1d.bb | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb 
b/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
index 072f727e0b..8819e19ec4 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
@@ -148,7 +148,7 @@ do_install_append_class-native () {
   OPENSSL_CONF=${libdir}/ssl-1.1/openssl.cnf \
   SSL_CERT_DIR=${libdir}/ssl-1.1/certs \
   SSL_CERT_FILE=${libdir}/ssl-1.1/cert.pem \
- OPENSSL_ENGINES=${libdir}/ssl-1.1/engines
+ OPENSSL_ENGINES=${libdir}/engines-1.1


Is this a bug in the openssl recipe (it's placing engines in the wrong place),
or a bug in the recipes providing acceleration engines and THEY are going into
the wrong place?


This recipe installs:
packages-split/openssl-engines/usr/lib/engines-1.1/afalg.so
packages-split/openssl-engines/usr/lib/engines-1.1/padlock.so
packages-split/openssl-engines/usr/lib/engines-1.1/capi.so

libp11 in meta-oe installs these:
packages-split/libp11/usr/lib/engines-1.1
packages-split/libp11/usr/lib/engines-1.1/pkcs11.so
packages-split/libp11-dev/usr/lib/engines-1.1
packages-split/libp11-dev/usr/lib/engines-1.1/libpkcs11.so



The ssl-1.1/engines makes more sense to me..  as /usr/lib/engines-1.1 obscures
that they are OpenSSL related.


I don't have a strong opinion either way but ssl-1.1/engines does make
a bit more sense.
Debian appears to install them in engines-1.1 though:
  https://packages.debian.org/buster/amd64/libssl1.1/filelist

I do need this fixed in warrior though and wonder if anyone would
gripe about changing where they are installed post release.

How shall we proceed? Does anyone else want to chime in?



Using /usr/lib/ is known jargon and lets use it. I think doing 
it the way other distros are doing it and how upstream defaults are is 
also helpful. it reduced one more thing to worry about. Release branches 
should not be an issue as long as we have them packages in same output 
package.




--Mark


  }

  do_install_append_class-nativesdk () {



--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


-George



--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] openssl: make OPENSSL_ENGINES match install path

[George McCollister]

On Wed, Sep 25, 2019 at 11:08 AM Mark Hatle
 wrote:
>
> On 9/25/19 6:52 AM, George McCollister wrote:
> > Set OPENSSL_ENGINES to the path where engines are actually installed.
> >
> > Signed-off-by: George McCollister 
> > ---
> >  meta/recipes-connectivity/openssl/openssl_1.1.1d.bb | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb 
> > b/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
> > index 072f727e0b..8819e19ec4 100644
> > --- a/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
> > +++ b/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
> > @@ -148,7 +148,7 @@ do_install_append_class-native () {
> >   OPENSSL_CONF=${libdir}/ssl-1.1/openssl.cnf \
> >   SSL_CERT_DIR=${libdir}/ssl-1.1/certs \
> >   SSL_CERT_FILE=${libdir}/ssl-1.1/cert.pem \
> > - OPENSSL_ENGINES=${libdir}/ssl-1.1/engines
> > + OPENSSL_ENGINES=${libdir}/engines-1.1
>
> Is this a bug in the openssl recipe (it's placing engines in the wrong place),
> or a bug in the recipes providing acceleration engines and THEY are going into
> the wrong place?

This recipe installs:
packages-split/openssl-engines/usr/lib/engines-1.1/afalg.so
packages-split/openssl-engines/usr/lib/engines-1.1/padlock.so
packages-split/openssl-engines/usr/lib/engines-1.1/capi.so

libp11 in meta-oe installs these:
packages-split/libp11/usr/lib/engines-1.1
packages-split/libp11/usr/lib/engines-1.1/pkcs11.so
packages-split/libp11-dev/usr/lib/engines-1.1
packages-split/libp11-dev/usr/lib/engines-1.1/libpkcs11.so

>
> The ssl-1.1/engines makes more sense to me..  as /usr/lib/engines-1.1 obscures
> that they are OpenSSL related.

I don't have a strong opinion either way but ssl-1.1/engines does make
a bit more sense.
Debian appears to install them in engines-1.1 though:
 https://packages.debian.org/buster/amd64/libssl1.1/filelist

I do need this fixed in warrior though and wonder if anyone would
gripe about changing where they are installed post release.

How shall we proceed? Does anyone else want to chime in?

>
> --Mark
>
> >  }
> >
> >  do_install_append_class-nativesdk () {
> >
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-George
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC][PATCH 0/3] Move rust from meta-rust to oe-core

[Randy MacLeod]

On 9/24/19 6:18 AM, Adrian Bunk wrote:

On Mon, Sep 23, 2019 at 10:45:05PM -0400, Randy MacLeod wrote:

I moved the Rust support from meta-rust to oe-core.

As you'd expect, it's still building rust-hello-world for all qemus
(except riscv64 which may never have worked).
Rust-hello-world runs for me on qemu:
x86-64, arm, arm64
It may run on other machines but that's what I've tested so far.

We need a list of meta-rust issues that should be resolved
in order to get the code accepted in oe-core. I opened an issue
to track that:
https://github.com/meta-rust/meta-rust/issues/251
but there haven't been any comments yet. I'd rather track
issues in github than in the YP Bugzilla:
   https://bugzilla.yoctoproject.org/show_bug.cgi?id=12675

Here, in no particular order, are some of
the defects that I believe need to be fixed:

1. build system is assumed to be linux-x86_64
https://github.com/meta-rust/meta-rust/issues/23

2. Make rust-native build in parallel (it's very slow!)
(meta-rust issue/PR to be created by Randy)

3. Document developer workflows such as cargo-bitbake.


Is there consensus on how libraries should be handled in general for
various ecosystems?

Precedent with C, Python and Perl are recipes for each library,
but vendoring seems to be a popular option now.


I'm not sure what vendoring means here.
I assume that you don't want the list of crates to be part of
package FOO's SRC_URI but instead want recipes for each crate.
For languages that do dynamic module linking by default, this saves
storage space, build time and maintenance. Rust is not such a language
by default but I need to learn more about it's dynamic
linking support:  https://doc.rust-lang.org/reference/linkage.html

I'm not sure if storage would be duplicated with the cargo
class managing downloads for Rust packages. I'll check on that.
Separate recipes would be significantly more work but we certainly
need to understand how to fix a bug in one crate and have that
applied to all N users of the crate without modifying N recipes.

Doug Goldstein, wrote most of cargo-bitbake,
so it would be good to hear his point of view.

FYI: Cargo-bitbake ( https://github.com/cardoe/cargo-bitbake )
is a "cargo extension that can generate BitBake recipes
  utilizing the classes from meta-rust"
There is a 'simple' example in:
  https://github.com/cardoe/cargo-bitbake/blob/master/README.md



There are also related topics like how to provide security support
for vendored libraries - this is the main reason why vendored libraries
shipped by upstream are rarely used by distributions in the C ecosystem.


Yes, we need to have a plan for security and bug fixes.
Of course Rust is largely impervious to such 20th century problems.
(mostly joking!)




4. Build offline ( BB_NO_NETWORK = '1' )

5. make rust-hello-world install for qemuriscv64
https://github.com/meta-rust/meta-rust/issues/252


LLVM in meta-rust is too old for RISC-V.


Right.
I'm away Thursday to Sunday but
I'll work on a fix for that when I'm back.



Using an own LLVM recipe might makes sense for an external layer, but in
oe-core the llvm recipe that is already there should be used instead of
another copy of LLVM.


I agree that the goal should be to have a single llvm package but
it's an upstream Rust decision. I did look at the differences between
the 'forks' and they are significant. The good news is that  the
llvm-rust code is maintained on it's own branch with the master
branch being pristine so it's possible that we could use the rust
repo to save on download time and storage and have the different recipes
checkout their respective branches until the unification takes place.
See: https://github.com/llvm/llvm-project/branches




6. ... build rustc and cargo for target (nice to have, only).
https://github.com/meta-rust/meta-rust/issues/81

7. Bootstrap from C as an option?
See: https://bugzilla.yoctoproject.org/show_bug.cgi?id=12675#c2

8. Update librsvg to latest (2.46) which uses rust.


2.44 built for me a few months ago with meta-rust.


Can you share the recipe so I can use it and update it to 2.46?




What have I missed?
...


9. Ensure that there are no non-optional dependencies on the target
librsvg since users will build for targets not supported by Rust.
The one in webkitgtk seems to be optional or obsolete.


I don't understand what you are referring to. Perhaps a link to a line
in your 2.44 recipe, would help.

Good point about Rust's more limited target support:
   https://forge.rust-lang.org/release/platform-support.html
To get started in oe-core, we just need to fix riscv64 it seems.

To deal with such targets, we'd keep the old version of librsvg
around for a while longer. That could cascade into several
packages with duplicate versions in oe-core so it may be best handled
with a separate layer.


10. Review the whole contents of the layer.
 There are several things where I hope there are better solutions,
 and I expect that w

[OE-core] [warrior][PATCH] qemu: Fix CVE-2019-8934

[msft . dantran]

From: Dan Tran 

Signed-off-by: Dan Tran 
---
 meta/recipes-devtools/qemu/qemu.inc   |   3 +-
 .../qemu/qemu/CVE-2019-8934.patch | 215 ++
 2 files changed, 217 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2019-8934.patch

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index e503aa866d..1f8c1b3135 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -30,7 +30,8 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
file://0018-fix-CVE-2018-20191.patch \
file://0019-fix-CVE-2018-20216.patch \
file://CVE-2019-3812.patch \
-   "
+  file://CVE-2019-8934.patch \
+  "
 UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
 
 SRC_URI[md5sum] = "fb687ce0b02d3bf4327e36d3b99427a8"
diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2019-8934.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2019-8934.patch
new file mode 100644
index 00..d1d7d23968
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2019-8934.patch
@@ -0,0 +1,215 @@
+From 8c2e30a92d95d89e2cf45d229bce274881026cf7 Mon Sep 17 00:00:00 2001
+From: Prasad J Pandit 
+Date: Mon, 18 Feb 2019 23:43:49 +0530
+Subject: [PATCH] ppc: add host-serial and host-model machine attributes
+ (CVE-2019-8934)
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+On ppc hosts, hypervisor shares following system attributes
+
+  - /proc/device-tree/system-id
+  - /proc/device-tree/model
+
+with a guest. This could lead to information leakage and misuse.[*]
+Add machine attributes to control such system information exposure
+to a guest.
+
+[*] https://wiki.openstack.org/wiki/OSSN/OSSN-0028
+
+Reported-by: Daniel P. Berrangé 
+Fix-suggested-by: Daniel P. Berrangé 
+Signed-off-by: Prasad J Pandit 
+Message-Id: <20190218181349.23885-1-ppan...@redhat.com>
+Reviewed-by: Daniel P. Berrangé 
+Reviewed-by: Greg Kurz 
+Signed-off-by: David Gibson 
+
+CVE: CVE-2019-8934
+Upstream-Status: Backport
+[https://github.com/qemu/qemu/commit/27461d69a0f108dea756419251acc3ea65198f1b]
+
+Signed-off-by: Dan Tran 
+---
+ hw/ppc/spapr.c | 128 ++---
+ include/hw/ppc/spapr.h |   2 +
+ 2 files changed, 123 insertions(+), 7 deletions(-)
+
+diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
+index 7afd1a175b..bcee7c162d 100644
+--- a/hw/ppc/spapr.c
 b/hw/ppc/spapr.c
+@@ -1244,13 +1244,30 @@ static void *spapr_build_fdt(sPAPRMachineState *spapr,
+  * Add info to guest to indentify which host is it being run on
+  * and what is the uuid of the guest
+  */
+-if (kvmppc_get_host_model(&buf)) {
+-_FDT(fdt_setprop_string(fdt, 0, "host-model", buf));
+-g_free(buf);
++if (spapr->host_model && !g_str_equal(spapr->host_model, "none")) {
++if (g_str_equal(spapr->host_model, "passthrough")) {
++/* -M host-model=passthrough */
++if (kvmppc_get_host_model(&buf)) {
++_FDT(fdt_setprop_string(fdt, 0, "host-model", buf));
++g_free(buf);
++}
++} else {
++/* -M host-model= */
++_FDT(fdt_setprop_string(fdt, 0, "host-model", spapr->host_model));
++}
+ }
+-if (kvmppc_get_host_serial(&buf)) {
+-_FDT(fdt_setprop_string(fdt, 0, "host-serial", buf));
+-g_free(buf);
++
++if (spapr->host_serial && !g_str_equal(spapr->host_serial, "none")) {
++if (g_str_equal(spapr->host_serial, "passthrough")) {
++/* -M host-serial=passthrough */
++if (kvmppc_get_host_serial(&buf)) {
++_FDT(fdt_setprop_string(fdt, 0, "host-serial", buf));
++g_free(buf);
++}
++} else {
++/* -M host-serial= */
++_FDT(fdt_setprop_string(fdt, 0, "host-serial", 
spapr->host_serial));
++}
+ }
+ 
+ buf = qemu_uuid_unparse_strdup(&qemu_uuid);
+@@ -3031,6 +3048,73 @@ static void spapr_set_vsmt(Object *obj, Visitor *v, 
const char *name,
+ visit_type_uint32(v, name, (uint32_t *)opaque, errp);
+ }
+ 
++static char *spapr_get_ic_mode(Object *obj, Error **errp)
++{
++sPAPRMachineState *spapr = SPAPR_MACHINE(obj);
++
++if (spapr->irq == &spapr_irq_xics_legacy) {
++return g_strdup("legacy");
++} else if (spapr->irq == &spapr_irq_xics) {
++return g_strdup("xics");
++} else if (spapr->irq == &spapr_irq_xive) {
++return g_strdup("xive");
++} else if (spapr->irq == &spapr_irq_dual) {
++return g_strdup("dual");
++}
++g_assert_not_reached();
++}
++
++static void spapr_set_ic_mode(Object *obj, const char *value, Error **errp)
++{
++sPAPRMachineState *spapr = SPAPR_MACHINE(obj);
++
++if (SPAPR_MACHINE_GET_CLASS(spapr)->legacy_irq_allocation) {
++error_setg(errp, "This machine only uses the legacy XICS backen

Re: [OE-core] [PATCH 1/1] openssl: make OPENSSL_ENGINES match install path

[Mark Hatle]

On 9/25/19 6:52 AM, George McCollister wrote:
> Set OPENSSL_ENGINES to the path where engines are actually installed.
> 
> Signed-off-by: George McCollister 
> ---
>  meta/recipes-connectivity/openssl/openssl_1.1.1d.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb 
> b/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
> index 072f727e0b..8819e19ec4 100644
> --- a/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
> +++ b/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
> @@ -148,7 +148,7 @@ do_install_append_class-native () {
>   OPENSSL_CONF=${libdir}/ssl-1.1/openssl.cnf \
>   SSL_CERT_DIR=${libdir}/ssl-1.1/certs \
>   SSL_CERT_FILE=${libdir}/ssl-1.1/cert.pem \
> - OPENSSL_ENGINES=${libdir}/ssl-1.1/engines
> + OPENSSL_ENGINES=${libdir}/engines-1.1

Is this a bug in the openssl recipe (it's placing engines in the wrong place),
or a bug in the recipes providing acceleration engines and THEY are going into
the wrong place?

The ssl-1.1/engines makes more sense to me..  as /usr/lib/engines-1.1 obscures
that they are OpenSSL related.

--Mark

>  }
>  
>  do_install_append_class-nativesdk () {
> 

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] wic: Using the right rootfs size during prepare_rootfs

[Alessio Igor Bogani]

The commit 8e48b4d6c4 makes wic ignores IMAGE_ROOTFS_SIZE for rootfs
size and makes it uses the computed one only. Re-add support for
IMAGE_ROOTFS_SIZE variable and compute roots size only if the former
is not defined.

Signed-off-by: Alessio Igor Bogani 
---
 scripts/lib/wic/partition.py | 22 --
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
index 2a71d7b1d6..81df15f71b 100644
--- a/scripts/lib/wic/partition.py
+++ b/scripts/lib/wic/partition.py
@@ -212,13 +212,23 @@ class Partition():
 if os.path.isfile(rootfs):
 os.remove(rootfs)
 
-# If size is not specified compute it from the rootfs_dir size
 if not self.size and real_rootfs:
-# Use the same logic found in get_rootfs_size()
-# from meta/classes/image.bbclass
-du_cmd = "du -ks %s" % rootfs_dir
-out = exec_cmd(du_cmd)
-self.size = int(out.split()[0])
+# The rootfs size is not set in .ks file so try to get it
+# from bitbake variable
+rsize_bb = get_bitbake_var('ROOTFS_SIZE')
+if rsize_bb:
+# Bitbake variable ROOTFS_SIZE is calculated in
+# Image._get_rootfs_size method from meta/lib/oe/image.py
+# using IMAGE_ROOTFS_SIZE, IMAGE_ROOTFS_ALIGNMENT,
+# IMAGE_OVERHEAD_FACTOR and IMAGE_ROOTFS_EXTRA_SPACE
+self.size = int(round(float(rsize_bb)))
+else:
+# Bitbake variable ROOTFS_SIZE is not defined so compute it
+# from the rootfs_dir size using the same logic found in
+# get_rootfs_size() from meta/classes/image.bbclass
+du_cmd = "du -ks %s" % rootfs_dir
+out = exec_cmd(du_cmd)
+self.size = int(out.split()[0])
 
 prefix = "ext" if self.fstype.startswith("ext") else self.fstype
 method = getattr(self, "prepare_rootfs_" + prefix)
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] bmap-tools: add missing python3-misc dependency

[Diego Rondini]

Add runtime dependency on python3-misc as bmaptool depends on ntpath.

Signed-off-by: Diego Rondini 
---
 meta/recipes-support/bmap-tools/bmap-tools_3.5.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-support/bmap-tools/bmap-tools_3.5.bb 
b/meta/recipes-support/bmap-tools/bmap-tools_3.5.bb
index 7c4db85b32..6be07d7f9c 100644
--- a/meta/recipes-support/bmap-tools/bmap-tools_3.5.bb
+++ b/meta/recipes-support/bmap-tools/bmap-tools_3.5.bb
@@ -17,7 +17,7 @@ PV .= "+git${SRCPV}"
 
 UPSTREAM_CHECK_GITTAGREGEX = "v(?P\d+(\.\d+)+)"
 
-RDEPENDS_${PN} = "python3-core python3-compression python3-mmap 
python3-setuptools python3-fcntl python3-six"
+RDEPENDS_${PN} = "python3-core python3-compression python3-mmap 
python3-setuptools python3-fcntl python3-six python3-misc"
 
 inherit python3native
 inherit setuptools3
-- 
2.21.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH][thud] cve-check: backport rewrite from master

[Ross Burton]

As detailed at [1] the XML feeds provided by NIST are being discontinued on
October 9th 2019.  As cve-check-tool uses these feeds, cve-check.bbclass will be
inoperable after this date.

To ensure that cve-check continues working, backport the following commits from
master to move away from the unmaintained cve-check-tool to our own Python code
that fetches the JSON:

546d14135c5 cve-update-db: New recipe to update CVE database
bc144b028f6 cve-check: Remove dependency to cve-check-tool-native
7f62a20b32a cve-check: Manage CVE_PRODUCT with more than one name
3bf63bc6084 cve-check: Consider CVE that affects versions with less than 
operator
c0eabd30d7b cve-update-db: Use std library instead of urllib3
27eb839ee65 cve-check: be idiomatic
09be21f4d17 cve-update-db: Manage proxy if needed.
975793e3825 cve-update-db: do_populate_cve_db depends on do_fetch
0325dd72714 cve-update-db: Catch request.urlopen errors.
4078da92b49 cve-check: Depends on cve-update-db-native
f7676e9a38d cve-update-db: Use NVD CPE data to populate PRODUCTS table
bc0195be1b1 cve-check: Update unpatched CVE matching
c807c2a6409 cve-update-db-native: Skip recipe when cve-check class is not 
loaded.
07bb8b25e17 cve-check: remove redundant readline CVE whitelisting
5388ed6d137 cve-check-tool: remove
270ac00cb43 cve-check.bbclass: initialize to_append
e6bf9000987 cve-check: allow comparison of Vendor as well as Product
91770338f76 cve-update-db-native: use SQL placeholders instead of format strings
7069302a4cc cve-check: Replace CVE_CHECK_CVE_WHITELIST by CVE_CHECK_WHITELIST
78de2cb39d7 cve-update-db-native: Remove hash column from database.
4b301030cf9 cve-update-db-native: use os.path.join instead of +
f0d822fad2a cve-update-db: actually inherit native
b309840b6aa cve-update-db-native: use executemany() to optimise CPE insertion
bb4e53af33d cve-update-db-native: improve metadata parsing
94227459792 cve-update-db-native: clean up JSON fetching
95438d52b73 cve-update-db-native: fix https proxy issues
1f9a963b9ff glibc: exclude child recipes from CVE scanning

[1] https://nvd.nist.gov/General/News/XML-Vulnerability-Feed-Retirement

Signed-off-by: Ross Burton 
---
 meta/classes/cve-check.bbclass| 142 +++-
 meta/conf/distro/include/maintainers.inc  |   1 +
 meta/recipes-core/glibc/glibc-locale.inc  |   3 +
 meta/recipes-core/glibc/glibc-mtrace.inc  |   3 +
 meta/recipes-core/glibc/glibc-scripts.inc |   3 +
 .../recipes-core/meta/cve-update-db-native.bb | 195 
 .../cve-check-tool/cve-check-tool_5.6.4.bb|  62 -
 ...x-freeing-memory-allocated-by-sqlite.patch |  50 
 ...erriding-default-CA-certificate-file.patch | 215 --
 ...s-in-percent-when-downloading-CVE-db.patch | 135 ---
 ...omputed-vs-expected-sha256-digit-str.patch |  52 -
 ...heck-for-malloc_trim-before-using-it.patch |  51 -
 12 files changed, 292 insertions(+), 620 deletions(-)
 create mode 100644 meta/recipes-core/meta/cve-update-db-native.bb
 delete mode 100644 meta/recipes-devtools/cve-check-tool/cve-check-tool_5.6.4.bb
 delete mode 100644 
meta/recipes-devtools/cve-check-tool/files/0001-Fix-freeing-memory-allocated-by-sqlite.patch
 delete mode 100644 
meta/recipes-devtools/cve-check-tool/files/0001-curl-allow-overriding-default-CA-certificate-file.patch
 delete mode 100644 
meta/recipes-devtools/cve-check-tool/files/0001-print-progress-in-percent-when-downloading-CVE-db.patch
 delete mode 100644 
meta/recipes-devtools/cve-check-tool/files/0001-update-Compare-computed-vs-expected-sha256-digit-str.patch
 delete mode 100644 
meta/recipes-devtools/cve-check-tool/files/check-for-malloc_trim-before-using-it.patch

diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index 743bc08a4f9..c00d2910be1 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -26,7 +26,7 @@ CVE_PRODUCT ??= "${BPN}"
 CVE_VERSION ??= "${PV}"
 
 CVE_CHECK_DB_DIR ?= "${DL_DIR}/CVE_CHECK"
-CVE_CHECK_DB_FILE ?= "${CVE_CHECK_DB_DIR}/nvd.db"
+CVE_CHECK_DB_FILE ?= "${CVE_CHECK_DB_DIR}/nvdcve_1.0.db"
 
 CVE_CHECK_LOG ?= "${T}/cve.log"
 CVE_CHECK_TMP_FILE ?= "${TMPDIR}/cve_check"
@@ -37,32 +37,33 @@ CVE_CHECK_COPY_FILES ??= "1"
 CVE_CHECK_CREATE_MANIFEST ??= "1"
 
 # Whitelist for packages (PN)
-CVE_CHECK_PN_WHITELIST = "\
-glibc-locale \
-"
+CVE_CHECK_PN_WHITELIST ?= ""
 
-# Whitelist for CVE and version of package
-CVE_CHECK_CVE_WHITELIST = "{\
-'CVE-2014-2524': ('6.3','5.2',), \
-}"
+# Whitelist for CVE. If a CVE is found, then it is considered patched.
+# The value is a string containing space separated CVE values:
+# 
+# CVE_CHECK_WHITELIST = 'CVE-2014-2524 CVE-2018-1234'
+# 
+CVE_CHECK_WHITELIST ?= ""
 
 python do_cve_check () {
 """
 Check recipe for patched and unpatched CVEs
 """
 
-if os.path.exists(d.getVar("CVE_CHECK_TMP_FILE")):
+if os.path.exists(d.getVar("CVE_CHECK_DB_FILE")):
 patched_cves = get_patches_cves(d)
 patched, 

[OE-core] [PATCH 1/1] openssl: make OPENSSL_ENGINES match install path

[George McCollister]

Set OPENSSL_ENGINES to the path where engines are actually installed.

Signed-off-by: George McCollister 
---
 meta/recipes-connectivity/openssl/openssl_1.1.1d.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb 
b/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
index 072f727e0b..8819e19ec4 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
@@ -148,7 +148,7 @@ do_install_append_class-native () {
OPENSSL_CONF=${libdir}/ssl-1.1/openssl.cnf \
SSL_CERT_DIR=${libdir}/ssl-1.1/certs \
SSL_CERT_FILE=${libdir}/ssl-1.1/cert.pem \
-   OPENSSL_ENGINES=${libdir}/ssl-1.1/engines
+   OPENSSL_ENGINES=${libdir}/engines-1.1
 }
 
 do_install_append_class-nativesdk () {
-- 
2.22.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/1] make OPENSSL_ENGINES match install path

[George McCollister]

Set OPENSSL_ENGINES in the openssl 1.1 recipe to the path where engines
are actually installed. This should be cherry-picked to warrior and
probably anything older with an openssl 1.1 recipe. I've not tested it
with anything older than warrior so someone else can make that call.

George McCollister (1):
  openssl: make OPENSSL_ENGINES match install path

 meta/recipes-connectivity/openssl/openssl_1.1.1d.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.22.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH][warrior] cve-check: backport rewrite from master

[Ross Burton]

As detailed at [1] the XML feeds provided by NIST are being discontinued on
October 9th 2019.  As cve-check-tool uses these feeds, cve-check.bbclass will be
inoperable after this date.

To ensure that cve-check continues working, backport the following commits from
master to move away from the unmaintained cve-check-tool to our own Python code
that fetches the JSON:

546d14135c5 cve-update-db: New recipe to update CVE database
bc144b028f6 cve-check: Remove dependency to cve-check-tool-native
7f62a20b32a cve-check: Manage CVE_PRODUCT with more than one name
3bf63bc6084 cve-check: Consider CVE that affects versions with less than 
operator
c0eabd30d7b cve-update-db: Use std library instead of urllib3
27eb839ee65 cve-check: be idiomatic
09be21f4d17 cve-update-db: Manage proxy if needed.
975793e3825 cve-update-db: do_populate_cve_db depends on do_fetch
0325dd72714 cve-update-db: Catch request.urlopen errors.
4078da92b49 cve-check: Depends on cve-update-db-native
f7676e9a38d cve-update-db: Use NVD CPE data to populate PRODUCTS table
bc0195be1b1 cve-check: Update unpatched CVE matching
c807c2a6409 cve-update-db-native: Skip recipe when cve-check class is not 
loaded.
07bb8b25e17 cve-check: remove redundant readline CVE whitelisting
5388ed6d137 cve-check-tool: remove
270ac00cb43 cve-check.bbclass: initialize to_append
e6bf9000987 cve-check: allow comparison of Vendor as well as Product
91770338f76 cve-update-db-native: use SQL placeholders instead of format strings
7069302a4cc cve-check: Replace CVE_CHECK_CVE_WHITELIST by CVE_CHECK_WHITELIST
78de2cb39d7 cve-update-db-native: Remove hash column from database.
4b301030cf9 cve-update-db-native: use os.path.join instead of +
f0d822fad2a cve-update-db: actually inherit native
b309840b6aa cve-update-db-native: use executemany() to optimise CPE insertion
bb4e53af33d cve-update-db-native: improve metadata parsing
94227459792 cve-update-db-native: clean up JSON fetching
95438d52b73 cve-update-db-native: fix https proxy issues
1f9a963b9ff glibc: exclude child recipes from CVE scanning

[1] https://nvd.nist.gov/General/News/XML-Vulnerability-Feed-Retirement

Signed-off-by: Ross Burton 
---
 meta/classes/cve-check.bbclass| 142 +++-
 meta/conf/distro/include/maintainers.inc  |   1 +
 meta/recipes-core/glibc/glibc-locale.inc  |   3 +
 meta/recipes-core/glibc/glibc-mtrace.inc  |   3 +
 meta/recipes-core/glibc/glibc-scripts.inc |   3 +
 .../recipes-core/meta/cve-update-db-native.bb | 195 
 .../cve-check-tool/cve-check-tool_5.6.4.bb|  62 -
 ...x-freeing-memory-allocated-by-sqlite.patch |  50 
 ...erriding-default-CA-certificate-file.patch | 215 --
 ...s-in-percent-when-downloading-CVE-db.patch | 135 ---
 ...omputed-vs-expected-sha256-digit-str.patch |  52 -
 ...heck-for-malloc_trim-before-using-it.patch |  51 -
 12 files changed, 292 insertions(+), 620 deletions(-)
 create mode 100644 meta/recipes-core/meta/cve-update-db-native.bb
 delete mode 100644 meta/recipes-devtools/cve-check-tool/cve-check-tool_5.6.4.bb
 delete mode 100644 
meta/recipes-devtools/cve-check-tool/files/0001-Fix-freeing-memory-allocated-by-sqlite.patch
 delete mode 100644 
meta/recipes-devtools/cve-check-tool/files/0001-curl-allow-overriding-default-CA-certificate-file.patch
 delete mode 100644 
meta/recipes-devtools/cve-check-tool/files/0001-print-progress-in-percent-when-downloading-CVE-db.patch
 delete mode 100644 
meta/recipes-devtools/cve-check-tool/files/0001-update-Compare-computed-vs-expected-sha256-digit-str.patch
 delete mode 100644 
meta/recipes-devtools/cve-check-tool/files/check-for-malloc_trim-before-using-it.patch

diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index 743bc08a4f9..c00d2910be1 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -26,7 +26,7 @@ CVE_PRODUCT ??= "${BPN}"
 CVE_VERSION ??= "${PV}"
 
 CVE_CHECK_DB_DIR ?= "${DL_DIR}/CVE_CHECK"
-CVE_CHECK_DB_FILE ?= "${CVE_CHECK_DB_DIR}/nvd.db"
+CVE_CHECK_DB_FILE ?= "${CVE_CHECK_DB_DIR}/nvdcve_1.0.db"
 
 CVE_CHECK_LOG ?= "${T}/cve.log"
 CVE_CHECK_TMP_FILE ?= "${TMPDIR}/cve_check"
@@ -37,32 +37,33 @@ CVE_CHECK_COPY_FILES ??= "1"
 CVE_CHECK_CREATE_MANIFEST ??= "1"
 
 # Whitelist for packages (PN)
-CVE_CHECK_PN_WHITELIST = "\
-glibc-locale \
-"
+CVE_CHECK_PN_WHITELIST ?= ""
 
-# Whitelist for CVE and version of package
-CVE_CHECK_CVE_WHITELIST = "{\
-'CVE-2014-2524': ('6.3','5.2',), \
-}"
+# Whitelist for CVE. If a CVE is found, then it is considered patched.
+# The value is a string containing space separated CVE values:
+# 
+# CVE_CHECK_WHITELIST = 'CVE-2014-2524 CVE-2018-1234'
+# 
+CVE_CHECK_WHITELIST ?= ""
 
 python do_cve_check () {
 """
 Check recipe for patched and unpatched CVEs
 """
 
-if os.path.exists(d.getVar("CVE_CHECK_TMP_FILE")):
+if os.path.exists(d.getVar("CVE_CHECK_DB_FILE")):
 patched_cves = get_patches_cves(d)
 patched, 

Re: [OE-core] [PATCH 2/3] expect: Fix configure error for nativesdk

[Robert Yang]

On 9/25/19 5:47 PM, Ross Burton wrote:

On 25/09/2019 10:30, Robert Yang wrote:

  TCL_INCLUDE_PATH = ""
  TCL_INCLUDE_PATH_class-target = "--with-tclinclude=${STAGING_INCDIR}/tcl8.6"
+TCL_INCLUDE_PATH_class-nativesdk = "--with-tclinclude=${STAGING_INCDIR}/tcl8.6"


Did you test just always passing --with-tclinclude=... in all classes?


I tried it just now, it didn't work for native, I will make it simpler in V2:

# Apparently the public Tcl headers are only in /usr/include/tcl8.6
# when building for the target and nativesdk.
TCL_INCLUDE_PATH = "--with-tclinclude=${STAGING_INCDIR}/tcl8.6"
TCL_INCLUDE_PATH_class-native = ""

// Robert



Ross

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/3] apr: Fix configure error for nativesdk

[Robert Yang]

On 9/25/19 5:48 PM, Ross Burton wrote:

On 25/09/2019 10:30, Robert Yang wrote:

Fixed:
$ bitbake nativesdk-expect


You meant nativesdk-apr


  DEPENDS = "util-linux"
+DEPENDS_class-nativesdk = "nativesdk-libtool"


As we're explicitly calling libtool, why not just DEPEND on libtool always?


Thanks, all of these are good suggestions, I will send a V2.

// Robert



Ross

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/3] apr: Fix configure error for nativesdk

[Ross Burton]

On 25/09/2019 10:30, Robert Yang wrote:

Fixed:
$ bitbake nativesdk-expect


You meant nativesdk-apr


  DEPENDS = "util-linux"
  
+DEPENDS_class-nativesdk = "nativesdk-libtool"


As we're explicitly calling libtool, why not just DEPEND on libtool always?

Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/3] expect: Fix configure error for nativesdk

[Ross Burton]

On 25/09/2019 10:30, Robert Yang wrote:

  TCL_INCLUDE_PATH = ""
  TCL_INCLUDE_PATH_class-target = "--with-tclinclude=${STAGING_INCDIR}/tcl8.6"
+TCL_INCLUDE_PATH_class-nativesdk = "--with-tclinclude=${STAGING_INCDIR}/tcl8.6"


Did you test just always passing --with-tclinclude=... in all classes?

Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/3] net-tools: Fix installed-vs-shipped for nativesdk

[Ross Burton]

On 25/09/2019 10:30, Robert Yang wrote:

Fixed:
$ bitbake nativesdk-net-tools
ERROR: nativesdk-net-tools-1.60-26-r0 do_package: QA Issue: 
nativesdk-net-tools: Files/directories were installed but not shipped in any 
package:
   /usr
   /usr/share
   /usr/share/man
[snip]

Signed-off-by: Robert Yang 
---
  meta/recipes-extended/net-tools/net-tools_1.60-26.bb | 8 
  1 file changed, 8 insertions(+)

diff --git a/meta/recipes-extended/net-tools/net-tools_1.60-26.bb 
b/meta/recipes-extended/net-tools/net-tools_1.60-26.bb
index b565fd0..0be9913 100644
--- a/meta/recipes-extended/net-tools/net-tools_1.60-26.bb
+++ b/meta/recipes-extended/net-tools/net-tools_1.60-26.bb
@@ -109,6 +109,14 @@ do_install() {
fi
  }
  
+do_install_append_class-nativesdk() {

+install -d ${D}${datadir}
+src_dir="${D}${target_datadir}"
+mv $src_dir/* ${D}${datadir}
+par_dir=`dirname $src_dir`
+rmdir $src_dir $par_dir
+}
+


Isn't this solved better by fixing the currently hardcoded value in 
man/Makefile:


mandir=/usr/share/man

Ross

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] systemd: mark /etc as updated to avoid unnecessary services to run

[Ross Burton]

On 25/09/2019 04:07, Chen Qi wrote:

We have updated hwdb via postinstall, updated systemd users via
'systemd_create_users', so there's no need to update /etc. Mark it
as updated to avoid unnecessary services like systemd-hwdb-update.service
to run.

This would solve timeout problem on qemumips. So also remove the
timeout change for systemd-hwdb-update.service.


I was going to send almost this exact patch, *but* I don't think it's right.

Arbitrary service files can use ConditionNeedsUpdate, and marking /etc 
as updated because we don't want hwdb-update to run also means we don't 
execute ldconfig.service, systemd-sysusers.server, or any other service 
files that were added and expected to be ran on first boot.


Some other distributions rip out systemd-hwdb-update entirely and use 
traditional postinsts to handle it:


Debian: 
https://salsa.debian.org/systemd-team/systemd/blob/master/debian/rules#L221
Clear: 
https://github.com/clearlinux-pkgs/systemd/blob/master/systemd.spec#L419


I believe that we should do the same.

Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [warrior][PATCH] kernel-uboot: compress arm64 kernels

[Bedel, Alban]

On Wed, 2019-09-25 at 08:49 +, Bonnans, Laurent wrote:
> On 9/25/19 2:23 AM, akuster808 wrote:
> 
> > On 9/24/19 12:23 AM, Bedel, Alban wrote:
> > > On Tue, 2019-09-03 at 09:41 +, Bedel, Alban wrote:
> > > > On Wed, 2019-07-31 at 13:53 +, Bedel, Alban wrote:
> > > > > AArch64 images are not self-decompressing, thus usually much
> > > > > larger.
> > > > > Boot times can be reduced by compressing them in FIT and
> > > > > uImages.
> > > > > 
> > > > > This commit is a backport of commit a725d188b5 (kernel-uboot:
> > > > > compress
> > > > > arm64 kernels) and commit 60bc7e180e (kernel-uboot: remove
> > > > > useless
> > > > > special casing of arm64 Image) from master. Both commit were
> > > > > melted
> > > > > into one to avoid some useless churn.
> > > > Was this patch overlooked, or is there a reason it is not
> > > > considered
> > > > in
> > > > the next round of update for warrior? Without this patch kernel
> > > > images
> > > > are too large to fit in the flash of the system I'm using.
> > > > Furthermore
> > > > it is not trivial to fix this in my own layer.
> > > Please, I really like to get an answer here. I'm fine if there is
> > > a
> > > reason why this patch is not considered for warrior, but just
> > > getting
> > > ignored is very frustrating.
> > This appears to be a performance enhancement which does not fall
> > into
> > the criteria for back porting to a stable branch.
> > 
> > - armin
> 
> Just to bring all the elements on the table:
> 
> It's possible to argue that it is more of a fix for a performance 
> regression, as the sub-optimal approach was introduced in
> 1aa417df604d2627c56232a7a2c396c6b085d74b and  the patch
> in question is equivalent to a revert.

Also it is not a question of performance, but of storage space. This
commit effectively broke every board which doesn't have enough storage
for an uncompressed kernel.

> For example, the pyro branch does not seem to have the issue.
> 
> I don't know if it makes a difference in terms of criteria for a 
> backport but I agree that the problem is indeed made worse because it
> is quite hard to override in user layers.

That's exactly my problem, I really don't see how that could be fixed
in my own layer. Furthermore, unlike ARM or X86, ARM64 doesn't support
self decompressing kernel, so that can't be workarounded from the
kernel itself.

Alban


signature.asc
Description: This is a digitally signed message part
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/3] expect: Fix configure error for nativesdk

[Robert Yang]

Fixed:
$ bitbake nativesdk-expect
checking for Tcl public headers... configure: error: tcl.h not found.  Please 
specify its location with --with-tclinclude

Signed-off-by: Robert Yang 
---
 meta/recipes-devtools/expect/expect_5.45.4.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/expect/expect_5.45.4.bb 
b/meta/recipes-devtools/expect/expect_5.45.4.bb
index 96eacd9..de8e141 100644
--- a/meta/recipes-devtools/expect/expect_5.45.4.bb
+++ b/meta/recipes-devtools/expect/expect_5.45.4.bb
@@ -47,6 +47,7 @@ do_install_append() {
 # when building for the target.
 TCL_INCLUDE_PATH = ""
 TCL_INCLUDE_PATH_class-target = "--with-tclinclude=${STAGING_INCDIR}/tcl8.6"
+TCL_INCLUDE_PATH_class-nativesdk = "--with-tclinclude=${STAGING_INCDIR}/tcl8.6"
 
 EXTRA_OECONF += "--with-tcl=${STAGING_LIBDIR} \
  --enable-shared \
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 3/3] apr: Fix configure error for nativesdk

[Robert Yang]

Fixed:
$ bitbake nativesdk-expect
buildconf: libtool not found.
   You need libtool version 1.4 or newer installed

Signed-off-by: Robert Yang 
---
 meta/recipes-support/apr/apr_1.7.0.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-support/apr/apr_1.7.0.bb 
b/meta/recipes-support/apr/apr_1.7.0.bb
index 09a65bf..02df068 100644
--- a/meta/recipes-support/apr/apr_1.7.0.bb
+++ b/meta/recipes-support/apr/apr_1.7.0.bb
@@ -3,6 +3,8 @@ HOMEPAGE = "http://apr.apache.org/";
 SECTION = "libs"
 DEPENDS = "util-linux"
 
+DEPENDS_class-nativesdk = "nativesdk-libtool"
+
 LICENSE = "Apache-2.0"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=4dfd4cd216828c8cae5de5a12f3844c8 \
 
file://include/apr_lib.h;endline=15;md5=823b3d1a7225df8f7b68a69c3c2b4c71"
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/3] net-tools: Fix installed-vs-shipped for nativesdk

[Robert Yang]

Fixed:
$ bitbake nativesdk-net-tools
ERROR: nativesdk-net-tools-1.60-26-r0 do_package: QA Issue: 
nativesdk-net-tools: Files/directories were installed but not shipped in any 
package:
  /usr
  /usr/share
  /usr/share/man
[snip]

Signed-off-by: Robert Yang 
---
 meta/recipes-extended/net-tools/net-tools_1.60-26.bb | 8 
 1 file changed, 8 insertions(+)

diff --git a/meta/recipes-extended/net-tools/net-tools_1.60-26.bb 
b/meta/recipes-extended/net-tools/net-tools_1.60-26.bb
index b565fd0..0be9913 100644
--- a/meta/recipes-extended/net-tools/net-tools_1.60-26.bb
+++ b/meta/recipes-extended/net-tools/net-tools_1.60-26.bb
@@ -109,6 +109,14 @@ do_install() {
fi
 }
 
+do_install_append_class-nativesdk() {
+install -d ${D}${datadir}
+src_dir="${D}${target_datadir}"
+mv $src_dir/* ${D}${datadir}
+par_dir=`dirname $src_dir`
+rmdir $src_dir $par_dir
+}
+
 inherit update-alternatives
 
 base_sbindir_progs = "arp ifconfig ipmaddr iptunnel mii-tool nameif plipconfig 
rarp route slattach"
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/3] meta: 3 fixes for nativesdk

[Robert Yang]

The following changes since commit 95ad5626296380358c8a502a3e04879dab653d78:

  build-appliance-image: Update to master head revision (2019-09-19 20:32:47 
+0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib rbt/sdk
  http://cgit.openembedded.org/openembedded-core-contrib/log/?h=rbt/sdk

Robert Yang (3):
  net-tools: Fix installed-vs-shipped for nativesdk
  expect: Fix configure error for nativesdk
  apr: Fix configure error for nativesdk

 meta/recipes-devtools/expect/expect_5.45.4.bb| 1 +
 meta/recipes-extended/net-tools/net-tools_1.60-26.bb | 8 
 meta/recipes-support/apr/apr_1.7.0.bb| 2 ++
 3 files changed, 11 insertions(+)

-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [warrior][PATCH] kernel-uboot: compress arm64 kernels

[Bonnans, Laurent]

On 9/25/19 2:23 AM, akuster808 wrote:

> On 9/24/19 12:23 AM, Bedel, Alban wrote:
>> On Tue, 2019-09-03 at 09:41 +, Bedel, Alban wrote:
>>> On Wed, 2019-07-31 at 13:53 +, Bedel, Alban wrote:
 AArch64 images are not self-decompressing, thus usually much
 larger.
 Boot times can be reduced by compressing them in FIT and uImages.

 This commit is a backport of commit a725d188b5 (kernel-uboot:
 compress
 arm64 kernels) and commit 60bc7e180e (kernel-uboot: remove useless
 special casing of arm64 Image) from master. Both commit were melted
 into one to avoid some useless churn.
>>> Was this patch overlooked, or is there a reason it is not considered
>>> in
>>> the next round of update for warrior? Without this patch kernel
>>> images
>>> are too large to fit in the flash of the system I'm using.
>>> Furthermore
>>> it is not trivial to fix this in my own layer.
>> Please, I really like to get an answer here. I'm fine if there is a
>> reason why this patch is not considered for warrior, but just getting
>> ignored is very frustrating.
> This appears to be a performance enhancement which does not fall into
> the criteria for back porting to a stable branch.
>
> - armin

Just to bring all the elements on the table:

It's possible to argue that it is more of a fix for a performance 
regression, as the sub-optimal
approach was introduced in 1aa417df604d2627c56232a7a2c396c6b085d74b and 
the patch
in question is equivalent to a revert.

For example, the pyro branch does not seem to have the issue.

I don't know if it makes a difference in terms of criteria for a 
backport but I agree that the
problem is indeed made worse because it is quite hard to override in 
user layers.


Laurent

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] e2fsprogs:upgrade 1.45.3 -> 1.45.4

[Zang Ruochen]

Signed-off-by: Zang Ruochen 
---
 .../e2fsprogs/{e2fsprogs_1.45.3.bb => e2fsprogs_1.45.4.bb}  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-devtools/e2fsprogs/{e2fsprogs_1.45.3.bb => 
e2fsprogs_1.45.4.bb} (99%)

diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.45.3.bb 
b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.45.4.bb
similarity index 99%
rename from meta/recipes-devtools/e2fsprogs/e2fsprogs_1.45.3.bb
rename to meta/recipes-devtools/e2fsprogs/e2fsprogs_1.45.4.bb
index fdc9454..90db71d 100644
--- a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.45.3.bb
+++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.45.4.bb
@@ -11,7 +11,7 @@ SRC_URI_append_class-native = " 
file://e2fsprogs-fix-missing-check-for-permissio
 file://quiet-debugfs.patch \
 "
 
-SRCREV = "1f56fb81236fe3e25e2c60c1e89ea0aa7cb36260"
+SRCREV = "984ff8d6a0a1d5dc300505f67b38ed5047d51dac"
 UPSTREAM_CHECK_GITTAGREGEX = "v(?P\d+\.\d+(\.\d+)*)$"
 
 EXTRA_OECONF += "--libdir=${base_libdir} --sbindir=${base_sbindir} \
-- 
2.7.4



-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] ✗ patchtest: failure for musl: Fix riscv64 CAS functions

[Patchwork]

== Series Details ==

Series: musl: Fix riscv64 CAS functions
Revision: 1
URL   : https://patchwork.openembedded.org/series/20146/
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 Upstream-Status is Submitted, but it is not mentioned where 
[test_upstream_status_presence_format] 
  Suggested fixInclude where 
0001-correct-the-operand-specifiers-in-the-riscv64-CAS-ro.patch was submitted
  Current  Upstream-Status: Submitted
  Standard format  Upstream-Status: Submitted [where]



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