[OE-core] [PATCH 1/2] oeqa/core/utils/concurrencytest.py: Handle exceptions and details

[Nathan Rossi]

Handle the streaming of exception content with details data. The
testtools package allows both 'err' and 'details' kwargs but can only
pass one of them to the parent.

To handle the passing of exception traceback and details data at the
same time, encode the traceback into the details object and remove the
'err' arg from the add* result call. This encodes the traceback similar
to how 'err' is handled without any details object. Decoding is already
done by testtools when the traceback is encoded in the details object.

Signed-off-by: Nathan Rossi 
---
 meta/lib/oeqa/core/utils/concurrencytest.py | 31 +
 1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/meta/lib/oeqa/core/utils/concurrencytest.py 
b/meta/lib/oeqa/core/utils/concurrencytest.py
index 6293cf94ec..0f7b3dcc11 100644
--- a/meta/lib/oeqa/core/utils/concurrencytest.py
+++ b/meta/lib/oeqa/core/utils/concurrencytest.py
@@ -78,29 +78,29 @@ class ProxyTestResult:
 def __init__(self, target):
 self.result = target
 
-def _addResult(self, method, test, *args, **kwargs):
+def _addResult(self, method, test, *args, exception = False, **kwargs):
 return method(test, *args, **kwargs)
 
-def addError(self, test, *args, **kwargs):
-self._addResult(self.result.addError, test, *args, **kwargs)
+def addError(self, test, err = None, **kwargs):
+self._addResult(self.result.addError, test, err, exception = True, 
**kwargs)
 
-def addFailure(self, test, *args, **kwargs):
-self._addResult(self.result.addFailure, test, *args, **kwargs)
+def addFailure(self, test, err = None, **kwargs):
+self._addResult(self.result.addFailure, test, err, exception = True, 
**kwargs)
 
-def addSuccess(self, test, *args, **kwargs):
-self._addResult(self.result.addSuccess, test, *args, **kwargs)
+def addSuccess(self, test, **kwargs):
+self._addResult(self.result.addSuccess, test, **kwargs)
 
-def addExpectedFailure(self, test, *args, **kwargs):
-self._addResult(self.result.addExpectedFailure, test, *args, **kwargs)
+def addExpectedFailure(self, test, err = None, **kwargs):
+self._addResult(self.result.addExpectedFailure, test, err, exception = 
True, **kwargs)
 
-def addUnexpectedSuccess(self, test, *args, **kwargs):
-self._addResult(self.result.addUnexpectedSuccess, test, *args, 
**kwargs)
+def addUnexpectedSuccess(self, test, **kwargs):
+self._addResult(self.result.addUnexpectedSuccess, test, **kwargs)
 
 def __getattr__(self, attr):
 return getattr(self.result, attr)
 
 class ExtraResultsDecoderTestResult(ProxyTestResult):
-def _addResult(self, method, test, *args, **kwargs):
+def _addResult(self, method, test, *args, exception = False, **kwargs):
 if "details" in kwargs and "extraresults" in kwargs["details"]:
 if isinstance(kwargs["details"]["extraresults"], Content):
 kwargs = kwargs.copy()
@@ -114,7 +114,7 @@ class ExtraResultsDecoderTestResult(ProxyTestResult):
 return method(test, *args, **kwargs)
 
 class ExtraResultsEncoderTestResult(ProxyTestResult):
-def _addResult(self, method, test, *args, **kwargs):
+def _addResult(self, method, test, *args, exception = False, **kwargs):
 if hasattr(test, "extraresults"):
 extras = lambda : [json.dumps(test.extraresults).encode()]
 kwargs = kwargs.copy()
@@ -123,6 +123,11 @@ class ExtraResultsEncoderTestResult(ProxyTestResult):
 else:
 kwargs["details"] = kwargs["details"].copy()
 kwargs["details"]["extraresults"] = 
Content(ContentType("application", "json", {'charset': 'utf8'}), extras)
+# if using details, need to encode any exceptions into the details obj,
+# testtools does not handle "err" and "details" together.
+if "details" in kwargs and exception and (len(args) >= 1 and args[0] 
is not None):
+kwargs["details"]["traceback"] = 
testtools.content.TracebackContent(args[0], test)
+args = []
 return method(test, *args, **kwargs)
 
 #
---
2.23.0
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/2] oeqa/core/case.py: Encode binary data of log

[Nathan Rossi]

Do not decode the log content into a string only to re-encode it as
binary data again. Some logs might un-intentionally contain bytes that
do not decode as utf-8, as such preserve the log file content as it was
on disk.

Handle the decoding on the resulttool side, but also handle the failure
to decode the data.

Signed-off-by: Nathan Rossi 
---
 meta/lib/oeqa/core/case.py| 4 ++--
 scripts/lib/resulttool/resultutils.py | 6 +-
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/meta/lib/oeqa/core/case.py b/meta/lib/oeqa/core/case.py
index 180635ac6c..aae451fef2 100644
--- a/meta/lib/oeqa/core/case.py
+++ b/meta/lib/oeqa/core/case.py
@@ -59,7 +59,7 @@ class OEPTestResultTestCase:
 """
 @staticmethod
 def _compress_log(log):
-logdata = log.encode("utf-8")
+logdata = log.encode("utf-8") if isinstance(log, str) else log
 logdata = zlib.compress(logdata)
 logdata = base64.b64encode(logdata).decode("utf-8")
 return {"compressed" : logdata}
@@ -80,7 +80,7 @@ class OEPTestResultTestCase:
 if log is not None:
 sections[section]["log"] = self._compress_log(log)
 elif logfile is not None:
-with open(logfile, "r") as f:
+with open(logfile, "rb") as f:
 sections[section]["log"] = self._compress_log(f.read())
 
 if duration is not None:
diff --git a/scripts/lib/resulttool/resultutils.py 
b/scripts/lib/resulttool/resultutils.py
index 177fb25f93..7cb85a6aa9 100644
--- a/scripts/lib/resulttool/resultutils.py
+++ b/scripts/lib/resulttool/resultutils.py
@@ -126,7 +126,11 @@ def decode_log(logdata):
 if "compressed" in logdata:
 data = logdata.get("compressed")
 data = base64.b64decode(data.encode("utf-8"))
-return zlib.decompress(data).decode("utf-8")
+data = zlib.decompress(data)
+try:
+return data.decode("utf-8")
+except UnicodeDecodeError:
+return data
 return None
 
 def ptestresult_get_log(results, section):
---
2.23.0
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] classes/image-live.bbclass: Don't hardcode cpio.gz

[Böszörményi Zoltán via Openembedded-core]

2019. 09. 26. 23:02 keltezéssel, richard.pur...@linuxfoundation.org írta:

On Thu, 2019-09-26 at 19:09 +0200, Böszörményi Zoltán wrote:

2019. 09. 26. 19:02 keltezéssel, Böszörményi Zoltán via Openembedded-
core írta:

2019. 09. 26. 18:50 keltezéssel, Böszörményi Zoltán via
Openembedded-core írta:

2019. 09. 26. 17:45 keltezéssel, Richard Purdie írta:


I'm a little worried that INITRAMFS_FSTYPES can contain
multiple values
by the sounds of its name...


  From the looks of the current value, it's already contains
multiple values
delimited by that dot. "cpio" + "gz".

Also, according to meta/conf/documentation.conf, line 228:

INITRAMFS_FSTYPES[doc] = "Defines the format for the output image
of an initial RAM disk
(initramfs), which is used during boot."


Also, image-live.bbclass uses this variable this way:

INITRD_LIVE ?= "${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_LIVE}-
${MACHINE}.${INITRAMFS_FSTYPES}"

The initrd/initramfs file name would definitely look strange if
this variable could contain multiple space delimited settings.


Also, openembedded-core/scripts/lib/wic/plugins/source/isoimage-
isohybrid.py
has that _build_initramfs_path function from line 143. The usage of
the same variable in this python function also points back to the
documentation line, i.e. it's a filename suffix and not multiple
settings delimited by space.


This does look ok given the above. Thanks for confirming.


Thanks for merging it into master-next.

I have also sent a patch for warrior separately with [warrior][PATCH]
yesterday, as I experienced the error there first.
Can you please apply it to warrior-next so I won't have to carry
the patch locally for long?

Thanks in advance,
Zoltán Böszörményi



Cheers,

Richard





--
___
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

[akuster808]

On 9/25/19 2:32 AM, Bedel, Alban wrote:
> 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.

Thank you for the additional information.  This will help me in making
my decision in backporting this commit

- armin
> Alban

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

Re: [OE-core] [PATCH] lighttpd: remove fam as a PACKAGECONFIG option

[Trevor Gamblin]

On 9/26/19 4:33 PM, Richard Purdie wrote:

On Mon, 2019-09-23 at 21:16 +0100, Ross Burton wrote:

On 23/09/2019 19:01, Trevor Gamblin wrote:

From: Trevor Gamblin

lighttpd builds fail if "fam" (and therefore gamin) is enabled.

In conf/local.conf:

  CORE_IMAGE_EXTRA_INSTALL += "lighttpd"
  PACKAGECONFIG_append_pn-lighttpd = " fam"

bitbake error:

  ERROR: Nothing PROVIDES 'gamin' (but /yow-lpggp31/tgamblin/oe-
core.git/meta/recipes-extended/lighttpd/lighttpd_1.4.54.bb DEPENDS
on or otherwise requires it)
  NOTE: Runtime target 'lighttpd' is unbuildable, removing...
  Missing or unbuildable dependency chain was: ['lighttpd',
'gamin']
  ERROR: Required build target 'core-image-minimal' has no
buildable providers.
  Missing or unbuildable dependency chain was: ['core-image-
minimal', 'lighttpd', 'gamin']

Since gamin doesn't appear to have a recipe and hasn't been
maintained for several years, this should be removed from the
list of lighttpd PACKAGECONFIG options.

Non-default PACKAGECONFIGs are allowed to depend on recipes that are
not
in core, plenty of recipes do this.  Otherwise there'd be no way to
turn
on options that have dependencies in other layers.

However, the fact that Gamin is very much dead is a good reason to
remove the PACKAGECONFIG and simply hardcode --without-fam for good
measure.

Agreed, can we have a v2 with --without-fam hardcoded in EXTRA_OECONF
please?

Cheers,

Richard


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

[OE-core] [oe-core][PATCH v2] lighttpd: remove fam as a PACKAGECONFIG option

[Trevor Gamblin]

From: Trevor Gamblin 

lighttpd builds fail if "fam" (and therefore gamin) is enabled.

In conf/local.conf:

CORE_IMAGE_EXTRA_INSTALL += "lighttpd"
PACKAGECONFIG_append_pn-lighttpd = " fam"

bitbake error:

ERROR: Nothing PROVIDES 'gamin' (but 
/yow-lpggp31/tgamblin/oe-core.git/meta/recipes-extended/lighttpd/lighttpd_1.4.54.bb
 DEPENDS on or otherwise requires it)
NOTE: Runtime target 'lighttpd' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['lighttpd', 'gamin']
ERROR: Required build target 'core-image-minimal' has no buildable 
providers.
Missing or unbuildable dependency chain was: ['core-image-minimal', 
'lighttpd', 'gamin']

Since gamin hasn't been maintained for several years, this should
be removed from the list of lighttpd PACKAGECONFIG options.
--without-fam is hard-coded in EXTRA_OECONF for good measure.

Signed-off-by: Trevor Gamblin 
---
 meta/recipes-extended/lighttpd/lighttpd_1.4.54.bb | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/meta/recipes-extended/lighttpd/lighttpd_1.4.54.bb 
b/meta/recipes-extended/lighttpd/lighttpd_1.4.54.bb
index 72990d02e5..2e83c821a6 100644
--- a/meta/recipes-extended/lighttpd/lighttpd_1.4.54.bb
+++ b/meta/recipes-extended/lighttpd/lighttpd_1.4.54.bb
@@ -39,14 +39,13 @@ PACKAGECONFIG[krb5] = "--with-krb5,--without-krb5,krb5"
 PACKAGECONFIG[pcre] = "--with-pcre,--without-pcre,libpcre"
 PACKAGECONFIG[zlib] = "--with-zlib,--without-zlib,zlib"
 PACKAGECONFIG[bzip2] = "--with-bzip2,--without-bzip2,bzip2"
-PACKAGECONFIG[fam] = "--with-fam,--without-fam,gamin"
 PACKAGECONFIG[webdav-props] = 
"--with-webdav-props,--without-webdav-props,libxml2 sqlite3"
 PACKAGECONFIG[webdav-locks] = 
"--with-webdav-locks,--without-webdav-locks,util-linux"
 PACKAGECONFIG[gdbm] = "--with-gdbm,--without-gdbm,gdbm"
 PACKAGECONFIG[memcache] = "--with-memcached,--without-memcached,libmemcached"
 PACKAGECONFIG[lua] = "--with-lua,--without-lua,lua"
 
-EXTRA_OECONF += "--enable-lfs"
+EXTRA_OECONF += "--enable-lfs --without-fam"
 
 inherit autotools pkgconfig update-rc.d gettext systemd
 
-- 
2.21.0

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

[OE-core] [PATCH] gdb: Bump from 8.3 to 8.3.1

[Alistair Francis]

Signed-off-by: Alistair Francis 
---
 .../gdb/{gdb-8.3.inc => gdb-8.3.1.inc}|  5 +-
 ...ian_8.3.bb => gdb-cross-canadian_8.3.1.bb} |  0
 .../{gdb-cross_8.3.bb => gdb-cross_8.3.1.bb}  |  0
 .../gdb/gdb/CVE-2017-9778.patch   | 98 ---
 .../gdb/{gdb_8.3.bb => gdb_8.3.1.bb}  |  0
 5 files changed, 2 insertions(+), 101 deletions(-)
 rename meta/recipes-devtools/gdb/{gdb-8.3.inc => gdb-8.3.1.inc} (85%)
 rename meta/recipes-devtools/gdb/{gdb-cross-canadian_8.3.bb => 
gdb-cross-canadian_8.3.1.bb} (100%)
 rename meta/recipes-devtools/gdb/{gdb-cross_8.3.bb => gdb-cross_8.3.1.bb} 
(100%)
 delete mode 100644 meta/recipes-devtools/gdb/gdb/CVE-2017-9778.patch
 rename meta/recipes-devtools/gdb/{gdb_8.3.bb => gdb_8.3.1.bb} (100%)

diff --git a/meta/recipes-devtools/gdb/gdb-8.3.inc 
b/meta/recipes-devtools/gdb/gdb-8.3.1.inc
similarity index 85%
rename from meta/recipes-devtools/gdb/gdb-8.3.inc
rename to meta/recipes-devtools/gdb/gdb-8.3.1.inc
index 070c17d4a1..39f1c48cc7 100644
--- a/meta/recipes-devtools/gdb/gdb-8.3.inc
+++ b/meta/recipes-devtools/gdb/gdb-8.3.1.inc
@@ -16,7 +16,6 @@ SRC_URI = "${GNU_MIRROR}/gdb/gdb-${PV}.tar.xz \
file://0009-Change-order-of-CFLAGS.patch \
file://0010-resolve-restrict-keyword-conflict.patch \
file://0011-Fix-invalid-sigprocmask-call.patch \
-   file://CVE-2017-9778.patch \
"
-SRC_URI[md5sum] = "bbd95b2f9b34621ad7a19a3965476314"
-SRC_URI[sha256sum] = 
"802f7ee309dcc547d65a68d61ebd6526762d26c3051f52caebe2189ac1ffd72e"
+SRC_URI[md5sum] = "73b6a5d8141672c62bf851cd34c4aa83"
+SRC_URI[sha256sum] = 
"1e55b4d7cdca7b34be12f4ceae651623aa73b2fd640152313f9f66a7149757c4"
diff --git a/meta/recipes-devtools/gdb/gdb-cross-canadian_8.3.bb 
b/meta/recipes-devtools/gdb/gdb-cross-canadian_8.3.1.bb
similarity index 100%
rename from meta/recipes-devtools/gdb/gdb-cross-canadian_8.3.bb
rename to meta/recipes-devtools/gdb/gdb-cross-canadian_8.3.1.bb
diff --git a/meta/recipes-devtools/gdb/gdb-cross_8.3.bb 
b/meta/recipes-devtools/gdb/gdb-cross_8.3.1.bb
similarity index 100%
rename from meta/recipes-devtools/gdb/gdb-cross_8.3.bb
rename to meta/recipes-devtools/gdb/gdb-cross_8.3.1.bb
diff --git a/meta/recipes-devtools/gdb/gdb/CVE-2017-9778.patch 
b/meta/recipes-devtools/gdb/gdb/CVE-2017-9778.patch
deleted file mode 100644
index f142ed00d7..00
--- a/meta/recipes-devtools/gdb/gdb/CVE-2017-9778.patch
+++ /dev/null
@@ -1,98 +0,0 @@
-From 6ad3791f095cfc1b0294f62c4b3a524ba735595e Mon Sep 17 00:00:00 2001
-From: Sandra Loosemore 
-Date: Thu, 25 Apr 2019 07:27:02 -0700
-Subject: [PATCH] Detect invalid length field in debug frame FDE header.
-
-GDB was failing to catch cases where a corrupt ELF or core file
-contained an invalid length value in a Dwarf debug frame FDE header.
-It was checking for buffer overflow but not cases where the length was
-negative or caused pointer wrap-around.
-
-In addition to the additional validity check, this patch cleans up the
-multiple signed/unsigned conversions on the length field so that an
-unsigned representation is used consistently throughout.
-
-This patch fixes CVE-2017-9778 and PR gdb/21600.
-
-2019-04-25  Sandra Loosemore  
-   Kang Li 
-
-   PR gdb/21600
-
-   * dwarf2-frame.c (read_initial_length): Be consistent about using
-   unsigned representation of length.
-   (decode_frame_entry_1): Likewise.  Check for wraparound of
-   end pointer as well as buffer overflow.
-
-Upstream-Status: Backport
-CVE: CVE-2017-9778
-Signed-off-by: Anuj Mittal 

- gdb/ChangeLog  | 10 ++
- gdb/dwarf2-frame.c | 14 +++---
- 2 files changed, 17 insertions(+), 7 deletions(-)
-
-diff --git a/gdb/ChangeLog b/gdb/ChangeLog
-index 1c125de..d028d2b 100644
 a/gdb/ChangeLog
-+++ b/gdb/ChangeLog
-@@ -1,3 +1,13 @@
-+2019-04-25  Sandra Loosemore  
-+  Kang Li 
-+
-+  PR gdb/21600
-+
-+  * dwarf2-frame.c (read_initial_length): Be consistent about using
-+  unsigned representation of length.
-+  (decode_frame_entry_1): Likewise.  Check for wraparound of
-+  end pointer as well as buffer overflow.
-+
- 2019-05-11  Joel Brobecker  
- 
-   * version.in: Set GDB version number to 8.3.
-diff --git a/gdb/dwarf2-frame.c b/gdb/dwarf2-frame.c
-index 178ac44..dc5d3b3 100644
 a/gdb/dwarf2-frame.c
-+++ b/gdb/dwarf2-frame.c
-@@ -1488,7 +1488,7 @@ static ULONGEST
- read_initial_length (bfd *abfd, const gdb_byte *buf,
-unsigned int *bytes_read_ptr)
- {
--  LONGEST result;
-+  ULONGEST result;
- 
-   result = bfd_get_32 (abfd, buf);
-   if (result == 0x)
-@@ -1789,7 +1789,7 @@ decode_frame_entry_1 (struct comp_unit *unit, const 
gdb_byte *start,
- {
-   struct gdbarch *gdbarch = get_objfile_arch (unit->objfile);
-   const gdb_byte *buf, *end;
--  LONGEST length;
-+  ULONGEST length;
-   unsigned int bytes_read;
-   int dwarf64_p;
-   ULONGEST cie_id;
-@@ -1800,15 +1800,15 @@ decode_frame_entry_1 (struct 

Re: [OE-core] bash-completion

[Khem Raj]

On Thu, Sep 26, 2019 at 4:17 PM Slater, Joseph  wrote:
>
> I see a bbclass for this, but no IMAGE_FEATURE to get the resultant packages 
> into an image.  Is there, or should there, be one?  I also see reference to 
> various similar packages, like *-dbg in an sdk bbclass, but have not found 
> how any of this stuff actually gets put into a target image.  Any pointers 
> would be appreciated.

I guess an IMAGE_FEATURE wont hurt.

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

Re: [OE-core] [oe-core][PATCH] unzip: Fix CVE-2019-13232

[akuster808]

Dan,


On 9/26/19 4:11 PM, 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 +

Thanks for this fix. If I am not mistaken, this fix should also apply to
warrior and thud.

- armin
>  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 {
> ++

[OE-core] bash-completion

[Slater, Joseph]

I see a bbclass for this, but no IMAGE_FEATURE to get the resultant packages 
into an image.  Is there, or should there, be one?  I also see reference to 
various similar packages, like *-dbg in an sdk bbclass, but have not found how 
any of this stuff actually gets put into a target image.  Any pointers would be 
appreciated.

Joe

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

[OE-core] [oe-core][PATCH] 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 

[OE-core] [oe-core][warrior][PATCH] 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 

[OE-core] [PATCH] packagegroups: All groups are not allarch

[Khem Raj]

Some of the packagegroups violate the allarch policy therefore the ones
which do so, should be marked as TUNE specific

Fixes QA errors
packagegroup-self-hosted-1.0: Package version for package 
packagegroup-self-hosted-graphics went backwards which would break package 
feeds from (0:1.0-r13.12 to 0:1.0-r13.9) [version-going-backwards]

Signed-off-by: Khem Raj 
---
 .../packagegroups/packagegroup-core-standalone-sdk-target.bb| 2 ++
 .../recipes-core/packagegroups/packagegroup-core-tools-debug.bb | 2 ++
 meta/recipes-core/packagegroups/packagegroup-self-hosted.bb | 2 ++
 3 files changed, 6 insertions(+)

diff --git 
a/meta/recipes-core/packagegroups/packagegroup-core-standalone-sdk-target.bb 
b/meta/recipes-core/packagegroups/packagegroup-core-standalone-sdk-target.bb
index f5b2d69cef..2a54f1ca3e 100644
--- a/meta/recipes-core/packagegroups/packagegroup-core-standalone-sdk-target.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-core-standalone-sdk-target.bb
@@ -1,6 +1,8 @@
 SUMMARY = "Target packages for the standalone SDK"
 PR = "r8"
 
+PACKAGE_ARCH = "${TUNE_PKGARCH}"
+
 inherit packagegroup
 
 RDEPENDS_${PN} = "\
diff --git a/meta/recipes-core/packagegroups/packagegroup-core-tools-debug.bb 
b/meta/recipes-core/packagegroups/packagegroup-core-tools-debug.bb
index 9fc2b0ef4d..81fbdf4608 100644
--- a/meta/recipes-core/packagegroups/packagegroup-core-tools-debug.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-core-tools-debug.bb
@@ -4,6 +4,8 @@
 
 SUMMARY = "Debugging tools"
 
+PACKAGE_ARCH = "${TUNE_PKGARCH}"
+
 inherit packagegroup
 
 PR = "r3"
diff --git a/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb 
b/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb
index 9b0ae0d1c2..ee9d0636f2 100644
--- a/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb
@@ -6,6 +6,8 @@ SUMMARY = "Self-hosting"
 DESCRIPTION = "Packages required to run the build system"
 PR = "r13"
 
+PACKAGE_ARCH = "${TUNE_PKGARCH}"
+
 inherit packagegroup  distro_features_check
 # rdepends on libx11-dev
 REQUIRED_DISTRO_FEATURES = "x11"
-- 
2.23.0

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

[OE-core] [PATCH] strace: Upgrade to 5.3

[Khem Raj]

Detailed features are here [1]

[1] https://github.com/strace/strace/releases/tag/v5.3

Signed-off-by: Khem Raj 
---
 .../strace/strace/disable-git-version-gen.patch| 10 +-
 .../strace/{strace_5.2.bb => strace_5.3.bb}|  4 ++--
 2 files changed, 7 insertions(+), 7 deletions(-)
 rename meta/recipes-devtools/strace/{strace_5.2.bb => strace_5.3.bb} (93%)

diff --git a/meta/recipes-devtools/strace/strace/disable-git-version-gen.patch 
b/meta/recipes-devtools/strace/strace/disable-git-version-gen.patch
index d6354bf4b6..5fefff33e9 100644
--- a/meta/recipes-devtools/strace/strace/disable-git-version-gen.patch
+++ b/meta/recipes-devtools/strace/strace/disable-git-version-gen.patch
@@ -1,4 +1,4 @@
-From ed30a4fc4dc264ce5f5881462e03ae13c921bfed Mon Sep 17 00:00:00 2001
+From 3bc47502ab011ea8d7c9cd724b25174ecd9506bc Mon Sep 17 00:00:00 2001
 From: Andre McCurdy 
 Date: Mon, 18 Jan 2016 13:33:50 -0800
 Subject: [PATCH] strace: remove need for scripts
@@ -16,20 +16,20 @@ Signed-off-by: Anuj Mittal 
  1 file changed, 3 insertions(+), 3 deletions(-)
 
 diff --git a/configure.ac b/configure.ac
-index 8045ebd..4319709 100644
+index 949b058..4ba989c 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -12,12 +12,12 @@
  
  AC_PREREQ(2.57)
  AC_INIT([strace],
--  m4_esyscmd([./git-version-gen .tarball-version]),
+-  st_esyscmd_s([./git-version-gen .tarball-version]),
 +  m4_esyscmd_s([cat .tarball-version]),
[strace-de...@lists.strace.io],
[strace],
[https://strace.io])
--m4_define([copyright_year], m4_esyscmd([./copyright-year-gen .year]))
--m4_define([manpage_date], m4_esyscmd([./file-date-gen strace.1.in]))
+-m4_define([copyright_year], st_esyscmd_s([./copyright-year-gen .year]))
+-m4_define([manpage_date], st_esyscmd_s([./file-date-gen strace.1.in]))
 +m4_define([copyright_year], m4_esyscmd_s([cat .year]))
 +m4_define([manpage_date], m4_esyscmd_s([cat .strace.1.in.date]))
  AC_COPYRIGHT([Copyright (c) 1999-]copyright_year[ The strace developers.])
diff --git a/meta/recipes-devtools/strace/strace_5.2.bb 
b/meta/recipes-devtools/strace/strace_5.3.bb
similarity index 93%
rename from meta/recipes-devtools/strace/strace_5.2.bb
rename to meta/recipes-devtools/strace/strace_5.3.bb
index a16c3b8598..775a22fc62 100644
--- a/meta/recipes-devtools/strace/strace_5.2.bb
+++ b/meta/recipes-devtools/strace/strace_5.3.bb
@@ -15,8 +15,8 @@ SRC_URI = "https://strace.io/files/${PV}/strace-${PV}.tar.xz \

file://0001-tests-sigaction-Check-for-mips-and-alpha-before-usin.patch \
file://ptest-spacesave.patch \
"
-SRC_URI[md5sum] = "b9c02b07dcde5125498ce7da69b77baf"
-SRC_URI[sha256sum] = 
"d513bc085609a9afd64faf2ce71deb95b96faf46cd7bc86048bc655e4e4c24d2"
+SRC_URI[md5sum] = "84f5e72de813c9b1bb6057ee8ab428d8"
+SRC_URI[sha256sum] = 
"6c131198749656401fe3efd6b4b16a07ea867e8f530867ceae8930bbc937a047"
 
 inherit autotools ptest
 
-- 
2.23.0

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

Re: [OE-core] [PATCH] classes/image-live.bbclass: Don't hardcode cpio.gz

[richard . purdie]

On Thu, 2019-09-26 at 19:09 +0200, Böszörményi Zoltán wrote:
> 2019. 09. 26. 19:02 keltezéssel, Böszörményi Zoltán via Openembedded-
> core írta:
> > 2019. 09. 26. 18:50 keltezéssel, Böszörményi Zoltán via
> > Openembedded-core írta:
> > > 2019. 09. 26. 17:45 keltezéssel, Richard Purdie írta:
> > > > 
> > > > I'm a little worried that INITRAMFS_FSTYPES can contain
> > > > multiple values
> > > > by the sounds of its name...
> > > 
> > >  From the looks of the current value, it's already contains
> > > multiple values
> > > delimited by that dot. "cpio" + "gz".
> > > 
> > > Also, according to meta/conf/documentation.conf, line 228:
> > > 
> > > INITRAMFS_FSTYPES[doc] = "Defines the format for the output image
> > > of an initial RAM disk 
> > > (initramfs), which is used during boot."
> > 
> > Also, image-live.bbclass uses this variable this way:
> > 
> > INITRD_LIVE ?= "${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_LIVE}-
> > ${MACHINE}.${INITRAMFS_FSTYPES}"
> > 
> > The initrd/initramfs file name would definitely look strange if
> > this variable could contain multiple space delimited settings.
> 
> Also, openembedded-core/scripts/lib/wic/plugins/source/isoimage-
> isohybrid.py
> has that _build_initramfs_path function from line 143. The usage of
> the same variable in this python function also points back to the
> documentation line, i.e. it's a filename suffix and not multiple
> settings delimited by space.

This does look ok given the above. Thanks for confirming.

Cheers,

Richard


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

Re: [OE-core] [bitbake-devel] Keeping multiconfig config files in sync

[Richard Purdie]

Hi Chris,

On Tue, 2019-09-24 at 18:21 +, chris.laplante--- via bitbake-devel
wrote:
> Thanks to Richard and others recent hard work, multiconfig is poised
> to become much more practical in YP 3.0.
>  
> One thing I’m not clear on, however, is how it will work in a team
> environment. If I have recipes with multiconfig dependencies, then I
> must ensure that anyone else using those recipes has the exact same
> set of multiconfig config files defined in their
> build/conf/multiconfig/ directory. Or at least, compatible
> multiconfigs with matching names.
>  
> Since these files are under build/conf/, it’s not immediately clear
> how one might version control these. Unless I’m mistaken and there is
> a better way, as a workaround I will probably put the multiconfigs in
> a layer and instruct developers to symlink build/conf/multiconfig to
> there.
>  
> Any insight?

This has bugged me since we first created multiconfig. It was always
intended we'd have configs you could reference. It turned out to be
hard to code and we (well, I) decided to "come back to it". That hasn't
happened yet.

I'd welcome proposals on how it could work (its harder than it first
appears). It'd be good to check we do have a bug open for it too.

So yes, its an issue, I know about it, I don't have a good fix but
would like to see some kind of improvement.

Cheers,

Richard

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

Re: [OE-core] [PATCH] lighttpd: remove fam as a PACKAGECONFIG option

[Richard Purdie]

On Mon, 2019-09-23 at 21:16 +0100, Ross Burton wrote:
> On 23/09/2019 19:01, Trevor Gamblin wrote:
> > From: Trevor Gamblin
> > 
> > lighttpd builds fail if "fam" (and therefore gamin) is enabled.
> > 
> > In conf/local.conf:
> > 
> >  CORE_IMAGE_EXTRA_INSTALL += "lighttpd"
> >  PACKAGECONFIG_append_pn-lighttpd = " fam"
> > 
> > bitbake error:
> > 
> >  ERROR: Nothing PROVIDES 'gamin' (but /yow-lpggp31/tgamblin/oe-
> > core.git/meta/recipes-extended/lighttpd/lighttpd_1.4.54.bb DEPENDS
> > on or otherwise requires it)
> >  NOTE: Runtime target 'lighttpd' is unbuildable, removing...
> >  Missing or unbuildable dependency chain was: ['lighttpd',
> > 'gamin']
> >  ERROR: Required build target 'core-image-minimal' has no
> > buildable providers.
> >  Missing or unbuildable dependency chain was: ['core-image-
> > minimal', 'lighttpd', 'gamin']
> > 
> > Since gamin doesn't appear to have a recipe and hasn't been
> > maintained for several years, this should be removed from the
> > list of lighttpd PACKAGECONFIG options.
> 
> Non-default PACKAGECONFIGs are allowed to depend on recipes that are
> not 
> in core, plenty of recipes do this.  Otherwise there'd be no way to
> turn 
> on options that have dependencies in other layers.
> 
> However, the fact that Gamin is very much dead is a good reason to 
> remove the PACKAGECONFIG and simply hardcode --without-fam for good
> measure.

Agreed, can we have a v2 with --without-fam hardcoded in EXTRA_OECONF
please?

Cheers,

Richard

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

Re: [OE-core] [PATCH 0/1] Add new mirror archiver mode

[Richard Purdie]

On Tue, 2019-09-24 at 10:06 +0100, Paul Barker wrote:
> This patch allows the creation of a full source mirror using the
> archiver
> bbclass. Using the archiver allows us to make use of copyleft license
> filtering, recipe type filtering and other features that are not
> available if
> we just copy the contents of the downloads directory itself to create
> a
> mirror. We also get the advantage of sstate caching and we don't have
> to
> throw away the entire downloads directory before building to keep
> sources for
> other builds out of our mirror.
> 
> The resulting mirror may be published and used as an entry in
> PREMIRRORS or
> MIRRORS for a subsequent build. The functionality is explained in
> more detail
> in the patch commit message and the additions to the documentation
> comments.
> 
> We've been using this patch in our Oryx Linux distro for a few months
> now to
> confirm that it works as expected. All feedback is welcome,
> especially from
> people who have worked on the archiver bbclass before.
> 
> Mirror creation was tested with the following additions to
> local.conf:
> 
> INHERIT += "archiver"
> BB_GENERATE_MIRROR_TARBALLS = "1"
> ARCHIVER_MODE[src] = "mirror"
> ARCHIVER_MODE[mirror] = "combined"
> ARCHIVER_MIRROR_EXCLUDE = "file://"
> COPYLEFT_LICENSE_INCLUDE = "*"
> 
> The resulting mirror directory was moved out of the tmpdir and a
> rebuild was
> tested with the following additions to local.conf:
> 
> BB_NO_NETWORK = "1"
> INHERIT += "own-mirrors"
> SOURCE_MIRROR_URL = "file://${TOPDIR}/mirror"
> 
> Paul Barker (1):
>   archiver.bbclass: Add new mirror archiver mode
> 
>  meta/classes/archiver.bbclass | 136 +---
> --
>  1 file changed, 117 insertions(+), 19 deletions(-)

This is coming in a bit late to be in 3.0 as we're way past feature
freeze. Have you given thought to regression testing? I'd also really
like to see some tests. There are some already:

meta/lib/oeqa/selftest/cases/archiver.py 

and whilst I'd not going to claim they're wonderful, it would be good
to extend as we add new functionality.

Cheers,

Richard

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

[OE-core] [PATCH v2] classes/reproducible_build: Move SDE deploy to another directory

[Joshua Watt]

The deployment of the source date epoch file had a race condition where
any task attempting to read from the file would race with creation of
the sstate archive for the do_deploy_source_date_epoch task. The
creation of the sstate archive requires moving the directory to a
temporary location, then moving it back. This means that the file
disappears for a short period of time, which will cause a failure if any
other task is running and trying to open the file to get the current
source date epoch.

The solution is to copy the source date epoch file to a separate
directory when deploying so the file never disappears. When the file is
restored from sstate, it is moved to the correct location after being
extracted.

[YOCTO #13501]

Signed-off-by: Joshua Watt 
---
 meta/classes/reproducible_build.bbclass | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/meta/classes/reproducible_build.bbclass 
b/meta/classes/reproducible_build.bbclass
index 8788ad7145c..99b749a9ee2 100644
--- a/meta/classes/reproducible_build.bbclass
+++ b/meta/classes/reproducible_build.bbclass
@@ -39,19 +39,27 @@ inherit 
${@oe.utils.ifelse(d.getVar('BUILD_REPRODUCIBLE_BINARIES') == '1', 'repr
 
 SDE_DIR ="${WORKDIR}/source-date-epoch"
 SDE_FILE = "${SDE_DIR}/__source_date_epoch.txt"
+SDE_DEPLOYDIR = "${WORKDIR}/deploy-source-date-epoch"
 
 SSTATETASKS += "do_deploy_source_date_epoch"
 
 do_deploy_source_date_epoch () {
 echo "Deploying SDE to ${SDE_DIR}."
+mkdir -p ${SDE_DEPLOYDIR}
+if [ -e ${SDE_FILE} ]; then
+cp -p ${SDE_FILE} ${SDE_DEPLOYDIR}/__source_date_epoch.txt
+fi
 }
 
 python do_deploy_source_date_epoch_setscene () {
 sstate_setscene(d)
+sde_file = os.path.join(d.getVar('SDE_DEPLOYDIR'), 
'__source_date_epoch.txt')
+if os.path.exists(sde_file):
+os.rename(sde_file, d.getVar('SDE_FILE'))
 }
 
-do_deploy_source_date_epoch[dirs] = "${SDE_DIR}"
-do_deploy_source_date_epoch[sstate-plaindirs] = "${SDE_DIR}"
+do_deploy_source_date_epoch[dirs] = "${SDE_DEPLOYDIR}"
+do_deploy_source_date_epoch[sstate-plaindirs] = "${SDE_DEPLOYDIR}"
 addtask do_deploy_source_date_epoch_setscene
 addtask do_deploy_source_date_epoch before do_configure after do_patch
 
-- 
2.21.0

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

Re: [OE-core] [PATCH] classes/image-live.bbclass: Don't hardcode cpio.gz

[Böszörményi Zoltán via Openembedded-core]

2019. 09. 26. 19:02 keltezéssel, Böszörményi Zoltán via Openembedded-core írta:

2019. 09. 26. 18:50 keltezéssel, Böszörményi Zoltán via Openembedded-core írta:

2019. 09. 26. 17:45 keltezéssel, Richard Purdie írta:

On Thu, 2019-09-26 at 11:05 +0200, Böszörményi Zoltán via Openembedded-
core wrote:

There's INITRAMFS_FSTYPES that can be set differently.

Signed-off-by: Böszörményi Zoltán 
---

With the hardcoded initrd filename suffix but INITRAMFS_FSTYPES
set to cpio.lzma, this error occurs:

ERROR: sicom-pos-image-1.0-r0 do_bootimg:
.../deploy/glibc/images/intel-core2-32/core-image-minimal-initramfs-
intel-core2-32.cpio.lzma is invalid. initrd image creation failed.
ERROR: sicom-pos-image-1.0-r0 do_bootimg: Function failed:
build_hddimg (log file is located at .../tmp-sicom-
glibc/work/intel_core2_32-sicom-linux/sicom-pos-image/1.0-
r0/temp/log.do_bootimg.32210)
ERROR: Logfile of failure stored in: .../tmp-sicom-
glibc/work/intel_core2_32-sicom-linux/sicom-pos-image/1.0-
r0/temp/log.do_bootimg.32210
ERROR: Task (.../layers/meta-sicom/images/sicom-pos-
image.bb:do_bootimg) failed with exit code '1'

  meta/classes/image-live.bbclass | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/image-live.bbclass b/meta/classes/image-
live.bbclass
index af71be5093..54058b350d 100644
--- a/meta/classes/image-live.bbclass
+++ b/meta/classes/image-live.bbclass
@@ -37,7 +37,7 @@ do_bootimg[depends] += "dosfstools-
native:do_populate_sysroot \
  LABELS_LIVE ?= "boot install"
  ROOT_LIVE ?= "root=/dev/ram0"
  INITRD_IMAGE_LIVE ?= "${MLPREFIX}core-image-minimal-initramfs"
-INITRD_LIVE ?= "${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_LIVE}-
${MACHINE}.cpio.gz"
+INITRD_LIVE ?= "${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_LIVE}-
${MACHINE}.${INITRAMFS_FSTYPES}"
  LIVE_ROOTFS_TYPE ?= "ext4"
  ROOTFS ?= "${IMGDEPLOYDIR}/${IMAGE_LINK_NAME}.${LIVE_ROOTFS_TYPE}"


I'm a little worried that INITRAMFS_FSTYPES can contain multiple values
by the sounds of its name...


 From the looks of the current value, it's already contains multiple values
delimited by that dot. "cpio" + "gz".

Also, according to meta/conf/documentation.conf, line 228:

INITRAMFS_FSTYPES[doc] = "Defines the format for the output image of an initial RAM disk 
(initramfs), which is used during boot."


Also, image-live.bbclass uses this variable this way:

INITRD_LIVE ?= 
"${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_LIVE}-${MACHINE}.${INITRAMFS_FSTYPES}"

The initrd/initramfs file name would definitely look strange if
this variable could contain multiple space delimited settings.


Also, openembedded-core/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
has that _build_initramfs_path function from line 143. The usage of
the same variable in this python function also points back to the
documentation line, i.e. it's a filename suffix and not multiple
settings delimited by space.





Defines the "format", singular. Maybe the variable is a slight misnomer.

Cheers,
Zoltán Böszörményi




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

[OE-core] ✗ patchtest: failure for linux-yocto/5.2: update to v5.2.17

[Patchwork]

== Series Details ==

Series: linux-yocto/5.2: update to v5.2.17
Revision: 1
URL   : https://patchwork.openembedded.org/series/20191/
State : failure

== Summary ==


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



* Issue Series does not apply on top of target branch 
[test_series_merge_on_head] 
  Suggested fixRebase your series on top of targeted branch
  Targeted branch  master (currently at 95ad562629)



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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

Re: [OE-core] [PATCH] classes/image-live.bbclass: Don't hardcode cpio.gz

[Böszörményi Zoltán via Openembedded-core]

2019. 09. 26. 18:50 keltezéssel, Böszörményi Zoltán via Openembedded-core írta:

2019. 09. 26. 17:45 keltezéssel, Richard Purdie írta:

On Thu, 2019-09-26 at 11:05 +0200, Böszörményi Zoltán via Openembedded-
core wrote:

There's INITRAMFS_FSTYPES that can be set differently.

Signed-off-by: Böszörményi Zoltán 
---

With the hardcoded initrd filename suffix but INITRAMFS_FSTYPES
set to cpio.lzma, this error occurs:

ERROR: sicom-pos-image-1.0-r0 do_bootimg:
.../deploy/glibc/images/intel-core2-32/core-image-minimal-initramfs-
intel-core2-32.cpio.lzma is invalid. initrd image creation failed.
ERROR: sicom-pos-image-1.0-r0 do_bootimg: Function failed:
build_hddimg (log file is located at .../tmp-sicom-
glibc/work/intel_core2_32-sicom-linux/sicom-pos-image/1.0-
r0/temp/log.do_bootimg.32210)
ERROR: Logfile of failure stored in: .../tmp-sicom-
glibc/work/intel_core2_32-sicom-linux/sicom-pos-image/1.0-
r0/temp/log.do_bootimg.32210
ERROR: Task (.../layers/meta-sicom/images/sicom-pos-
image.bb:do_bootimg) failed with exit code '1'

  meta/classes/image-live.bbclass | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/image-live.bbclass b/meta/classes/image-
live.bbclass
index af71be5093..54058b350d 100644
--- a/meta/classes/image-live.bbclass
+++ b/meta/classes/image-live.bbclass
@@ -37,7 +37,7 @@ do_bootimg[depends] += "dosfstools-
native:do_populate_sysroot \
  LABELS_LIVE ?= "boot install"
  ROOT_LIVE ?= "root=/dev/ram0"
  INITRD_IMAGE_LIVE ?= "${MLPREFIX}core-image-minimal-initramfs"
-INITRD_LIVE ?= "${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_LIVE}-
${MACHINE}.cpio.gz"
+INITRD_LIVE ?= "${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_LIVE}-
${MACHINE}.${INITRAMFS_FSTYPES}"
  LIVE_ROOTFS_TYPE ?= "ext4"
  ROOTFS ?= "${IMGDEPLOYDIR}/${IMAGE_LINK_NAME}.${LIVE_ROOTFS_TYPE}"


I'm a little worried that INITRAMFS_FSTYPES can contain multiple values
by the sounds of its name...


 From the looks of the current value, it's already contains multiple values
delimited by that dot. "cpio" + "gz".

Also, according to meta/conf/documentation.conf, line 228:

INITRAMFS_FSTYPES[doc] = "Defines the format for the output image of an initial RAM disk 
(initramfs), which is used during boot."


Also, image-live.bbclass uses this variable this way:

INITRD_LIVE ?= 
"${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_LIVE}-${MACHINE}.${INITRAMFS_FSTYPES}"

The initrd/initramfs file name would definitely look strange if
this variable could contain multiple space delimited settings.



Defines the "format", singular. Maybe the variable is a slight misnomer.

Cheers,
Zoltán Böszörményi


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

[OE-core] [PATCH] linux-yocto/5.2: update to v5.2.17

[bruce . ashfield]

From: Bruce Ashfield 

Updating linux-yocto/5.2 to the latest korg -stable release that comprises
the following commits:

5e408889e4af Linux 5.2.17
12434939ba58 vfs: Fix refcounting of filenames in fs_parser
d4911cc1f4b6 media: technisat-usb2: break out of loop at end of buffer
19ad4c4fe19c floppy: fix usercopy direction
d7aa8c546ab9 ovl: fix regression caused by overlapping layers detection
52f2aba47d71 Revert "arm64: Remove unnecessary ISBs from set_{pte,pmd,pud}"
785ca708a908 iommu/amd: Fix race in increase_address_space()
ed52f6cf0e84 iommu/amd: Flush old domains in kdump kernel
24962eb0edd0 keys: Fix missing null pointer check in 
request_key_auth_describe()
16ed4b9b7bf7 dmaengine: rcar-dmac: Fix DMACHCLR handling if iommu is mapped
d604a12cc6d5 dmaengine: sprd: Fix the DMA link-list configuration
d5898d2f06fc iommu/vt-d: Remove global page flush support
5df0a5fd4d1c x86/hyper-v: Fix overflow bug in fill_gva_list()
4bdb9988ad38 x86/uaccess: Don't leak the AC flags into __get_user() 
argument evaluation
4dabe50389c4 dmaengine: ti: omap-dma: Add cleanup in omap_dma_probe()
9de496fe242a dmaengine: ti: dma-crossbar: Fix a memory leak bug
4b898223a979 arm64: dts: renesas: r8a77995: draak: Fix backlight regulator 
name
4ad64281e4d3 net: seeq: Fix the function used to release some memory in an 
error handling path
0275857577e5 enetc: Add missing call to 'pci_free_irq_vectors()' in probe 
and remove functions
d18638671b96 net: dsa: microchip: add KSZ8563 compatibility string
05172612ab3a net: aquantia: fix out of memory condition on rx side
95acd66ba70a net: aquantia: linkstate irq should be oneshot
e4d1449ca4a5 net: aquantia: reapply vlan filters on up
6a6e09b7a519 net: aquantia: fix removal of vlan 0
b5789a160c2d tools/power turbostat: Fix CPU%C1 display value
54f4f3b38133 tools/power turbostat: Add Ice Lake NNPI support
8bae84e5203b tools/power turbostat: Fix Haswell Core systems
0926ee9f5327 tools/power turbostat: fix buffer overrun
94132aca9472 tools/power turbostat: fix file descriptor leaks
0a1ba2cd9d62 tools/power turbostat: fix leak of file descriptor on error 
return path
caab8b8b3aca tools/power x86_energy_perf_policy: Fix argument parsing
edf8ba32bc2b tools/power x86_energy_perf_policy: Fix "uninitialized 
variable" warnings at -O2
e9e492c92d8c netfilter: nf_flow_table: clear skb tstamp before xmit
27264af16969 amd-xgbe: Fix error path in xgbe_mod_init()
8b7bf7b1b2dd i2c: mediatek: disable zero-length transfers for mt8183
316c15048f40 i2c: iproc: Stop advertising support of SMBUS quick cmd
9027939cc8f7 perf/x86/amd/ibs: Fix sample bias for dispatched micro-ops
e1efdaaa9b46 perf/x86/intel: Restrict period on Nehalem
1ffda54f0546 i2c: designware: Synchronize IRQs when unregistering slave 
client
0910434c455d sky2: Disable MSI on yet another ASUS boards (P6Xxxx)
cd6901e723fc ibmvnic: Do not process reset during or after device removal
3ee4ed9cd3a0 ARM: 8901/1: add a criteria for pfn_valid of arm
eaaa11a4f8d0 RISC-V: Fix FIXMAP area corruption on RV32 systems
22c521335522 usb: host: xhci-tegra: Set DMA mask correctly
97b1d81abc61 libceph: don't call crypto_free_sync_skcipher() on a NULL tfm
b8632186884a cifs: Use kzfree() to zero out the password
8db988a98290 cifs: set domainName when a domain-key is used in multiuser
a8bf51b5c6f5 drm/amd/powerplay: correct Vega20 dpm level related settings
f5c6d0245f97 netfilter: conntrack: make sysctls per-namespace again
6612f6edf1f1 kallsyms: Don't let kallsyms_lookup_size_offset() fail on 
retrieving the first symbol
7c1a4283b606 NFS: remove set but not used variable 'mapping'
de932b20ed88 NFSv2: Fix write regression
646d295fdded NFSv2: Fix eof handling
16986c7cf8b5 netfilter: nf_conntrack_ftp: Fix debug output
0dec70d3c249 netfilter: xt_physdev: Fix spurious error message in 
physdev_mt_check
e3813a30bd6f drm/amdgpu: fix dma_fence_wait without reference
9b914306b0f7 NFS: Fix writepage(s) error handling to not report errors twice
78f0f9007523 NFS: Fix spurious EIO read errors
fa38f165c78a pNFS/flexfiles: Don't time out requests on hard mounts
7999b21e2224 x86/apic: Fix arch_dynirq_lower_bound() bug for DT enabled 
machines
c19a0d7ef095 r8152: Set memory to all 0xFFs on failed reg reads
f1b6d7c8de4c bpf: allow narrow loads of some sk_reuseport_md fields with 
offset > 0
5e0251d82954 flow_dissector: Fix potential use-after-free on BPF_PROG_DETACH
31320b857d13 batman-adv: Only read OGM2 tvlv_len after buffer len check
9ae47d48cd2d ARM: 8874/1: mm: only adjust sections of valid mm structures
b77b8c17df13 drm/virtio: use virtio_max_dma_size
5a2ffd1ffa54 drm/omap: Fix port lookup for SDI output
fc45ccc7b85b qed: Add cleanup in qed_slowpath_start()
304a65866fbe selftests/bpf: add config fragment 

Re: [OE-core] [PATCH] classes/image-live.bbclass: Don't hardcode cpio.gz

[Böszörményi Zoltán via Openembedded-core]

2019. 09. 26. 17:45 keltezéssel, Richard Purdie írta:

On Thu, 2019-09-26 at 11:05 +0200, Böszörményi Zoltán via Openembedded-
core wrote:

There's INITRAMFS_FSTYPES that can be set differently.

Signed-off-by: Böszörményi Zoltán 
---

With the hardcoded initrd filename suffix but INITRAMFS_FSTYPES
set to cpio.lzma, this error occurs:

ERROR: sicom-pos-image-1.0-r0 do_bootimg:
.../deploy/glibc/images/intel-core2-32/core-image-minimal-initramfs-
intel-core2-32.cpio.lzma is invalid. initrd image creation failed.
ERROR: sicom-pos-image-1.0-r0 do_bootimg: Function failed:
build_hddimg (log file is located at .../tmp-sicom-
glibc/work/intel_core2_32-sicom-linux/sicom-pos-image/1.0-
r0/temp/log.do_bootimg.32210)
ERROR: Logfile of failure stored in: .../tmp-sicom-
glibc/work/intel_core2_32-sicom-linux/sicom-pos-image/1.0-
r0/temp/log.do_bootimg.32210
ERROR: Task (.../layers/meta-sicom/images/sicom-pos-
image.bb:do_bootimg) failed with exit code '1'

  meta/classes/image-live.bbclass | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/image-live.bbclass b/meta/classes/image-
live.bbclass
index af71be5093..54058b350d 100644
--- a/meta/classes/image-live.bbclass
+++ b/meta/classes/image-live.bbclass
@@ -37,7 +37,7 @@ do_bootimg[depends] += "dosfstools-
native:do_populate_sysroot \
  LABELS_LIVE ?= "boot install"
  ROOT_LIVE ?= "root=/dev/ram0"
  INITRD_IMAGE_LIVE ?= "${MLPREFIX}core-image-minimal-initramfs"
-INITRD_LIVE ?= "${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_LIVE}-
${MACHINE}.cpio.gz"
+INITRD_LIVE ?= "${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_LIVE}-
${MACHINE}.${INITRAMFS_FSTYPES}"
  
  LIVE_ROOTFS_TYPE ?= "ext4"

  ROOTFS ?= "${IMGDEPLOYDIR}/${IMAGE_LINK_NAME}.${LIVE_ROOTFS_TYPE}"


I'm a little worried that INITRAMFS_FSTYPES can contain multiple values
by the sounds of its name...


From the looks of the current value, it's already contains multiple values
delimited by that dot. "cpio" + "gz".

Also, according to meta/conf/documentation.conf, line 228:

INITRAMFS_FSTYPES[doc] = "Defines the format for the output image of an initial RAM disk 
(initramfs), which is used during boot."


Defines the "format", singular. Maybe the variable is a slight misnomer.

Cheers,
Zoltán Böszörményi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] classes/image-live.bbclass: Don't hardcode cpio.gz

[Richard Purdie]

On Thu, 2019-09-26 at 11:05 +0200, Böszörményi Zoltán via Openembedded-
core wrote:
> There's INITRAMFS_FSTYPES that can be set differently.
> 
> Signed-off-by: Böszörményi Zoltán 
> ---
> 
> With the hardcoded initrd filename suffix but INITRAMFS_FSTYPES
> set to cpio.lzma, this error occurs:
> 
> ERROR: sicom-pos-image-1.0-r0 do_bootimg:
> .../deploy/glibc/images/intel-core2-32/core-image-minimal-initramfs-
> intel-core2-32.cpio.lzma is invalid. initrd image creation failed.
> ERROR: sicom-pos-image-1.0-r0 do_bootimg: Function failed:
> build_hddimg (log file is located at .../tmp-sicom-
> glibc/work/intel_core2_32-sicom-linux/sicom-pos-image/1.0-
> r0/temp/log.do_bootimg.32210)
> ERROR: Logfile of failure stored in: .../tmp-sicom-
> glibc/work/intel_core2_32-sicom-linux/sicom-pos-image/1.0-
> r0/temp/log.do_bootimg.32210
> ERROR: Task (.../layers/meta-sicom/images/sicom-pos-
> image.bb:do_bootimg) failed with exit code '1'
> 
>  meta/classes/image-live.bbclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/classes/image-live.bbclass b/meta/classes/image-
> live.bbclass
> index af71be5093..54058b350d 100644
> --- a/meta/classes/image-live.bbclass
> +++ b/meta/classes/image-live.bbclass
> @@ -37,7 +37,7 @@ do_bootimg[depends] += "dosfstools-
> native:do_populate_sysroot \
>  LABELS_LIVE ?= "boot install"
>  ROOT_LIVE ?= "root=/dev/ram0"
>  INITRD_IMAGE_LIVE ?= "${MLPREFIX}core-image-minimal-initramfs"
> -INITRD_LIVE ?= "${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_LIVE}-
> ${MACHINE}.cpio.gz"
> +INITRD_LIVE ?= "${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_LIVE}-
> ${MACHINE}.${INITRAMFS_FSTYPES}"
>  
>  LIVE_ROOTFS_TYPE ?= "ext4"
>  ROOTFS ?= "${IMGDEPLOYDIR}/${IMAGE_LINK_NAME}.${LIVE_ROOTFS_TYPE}"

I'm a little worried that INITRAMFS_FSTYPES can contain multiple values
by the sounds of its name...

Cheers,

Richard

-- 
___
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 10:51 PM Robert Yang  wrote:
>
> 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.
>

perhaps something like this might be interesting
https://sources.debian.org/src/apr/1.6.5-1/debian/patches/fix_apr-config.patch/
https://sources.debian.org/src/apr/1.6.5-1/debian/patches/libtoolize_check.patch/

> // 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

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

[Ross Burton]

On 26/09/2019 09:40, Diego Rondini wrote:

Hi Ross,

On Wed, Sep 25, 2019 at 9:40 PM Ross Burton > wrote:


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 mailto:diego.rond...@kynetics.com>>
 > ---
 >   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


I've seen ntpath has been added back to python3-core with this commit:
http://git.openembedded.org/openembedded-core/commit/meta/recipes-devtools/python/python3/python3-manifest.json?id=9ff61fa83a0a4f2a7b5b0376b6c48fb1173c9ac7
so my change makes sense only in warrior.

Can you please explain how you trigger that error?


I tried building an image that depended on bmap-tools-native.

Ross

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

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

[Jason Wessel]

This looks correct now with the two patches merged.

Thanks,
Jason.

On 9/26/19 4:35 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. Moreover the size of a provided directory with
--rootfs-dir="" in the .wks file should always be computed on the fly,
else every partition will be constrained to be the same size as what
ever value was in ROOTFS_SIZE.

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

diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
index 2a71d7b1d6..d809408e1a 100644
--- a/scripts/lib/wic/partition.py
+++ b/scripts/lib/wic/partition.py
@@ -212,13 +212,24 @@ 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')
+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,
+# 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)



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

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

[Ross Burton]

On 26/09/2019 01:54, Oleksandr Kravchuk wrote:

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

Signed-off-by: Oleksandr Kravchuk 


This is in ross/mut so it won't get lost, but we're freezing for release 
so this won't be merged until 3.0 is done.


Ross

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

[OE-core] [PATCH v2] 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. Moreover the size of a provided directory with
--rootfs-dir="" in the .wks file should always be computed on the fly,
else every partition will be constrained to be the same size as what
ever value was in ROOTFS_SIZE.

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

diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
index 2a71d7b1d6..d809408e1a 100644
--- a/scripts/lib/wic/partition.py
+++ b/scripts/lib/wic/partition.py
@@ -212,13 +212,24 @@ 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')
+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,
+# 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

Re: [OE-core] ✗ patchtest: failure for rpm: make rpm work in toolchain. (rev4)

[Zheng, Ruoqin]

Hi

I found meta/recipes-devtools/rpm/files/rpm-setup.py is in my patch.

But the automated test results have an error message as follows:

  Output   Please, fix the listed issues:
   meta/recipes-devtools/rpm/files/rpm-setup.py does not exist

Does anyone have any suggestion?

--
Zheng Ruoqin
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
ADDR.: No.6 Wenzhu Road, Software Avenue,
   Nanjing, 210012, China
MAIL : zhengrq.f...@cn.fujistu.com

> -Original Message-
> From: Patchwork [mailto:patchw...@patchwork.openembedded.org]
> Sent: Wednesday, September 25, 2019 8:02 AM
> To: Zheng, Ruoqin/郑 若钦 
> Cc: openembedded-core@lists.openembedded.org
> Subject: ✗ patchtest: failure for rpm: make rpm work in toolchain. (rev4)
> 
> == Series Details ==
> 
> Series: rpm: make rpm work in toolchain. (rev4)
> Revision: 4
> URL   : https://patchwork.openembedded.org/series/19789/
> 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 Errors in your Python code were encountered [test_pylint]
>   Suggested fixCorrect the lines introduced by your patch
>   Output   Please, fix the listed issues:
>meta/recipes-devtools/rpm/files/rpm-setup.py does not exist
> 
> 
> 
> If you believe any of these test results are incorrect, please reply to the 
> mailing
> list (openembedded-core@lists.openembedded.org) raising your concerns.
> Otherwise we would appreciate you correcting the issues and submitting a new
> version of the patchset if applicable. Please ensure you add/increment the
> version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
> [PATCH v3] -> ...).
> 
> ---
> Guidelines:
> https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
> Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
> Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe
> 
> 



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

[OE-core] [PATCH] classes/image-live.bbclass: Don't hardcode cpio.gz

[Böszörményi Zoltán via Openembedded-core]

There's INITRAMFS_FSTYPES that can be set differently.

Signed-off-by: Böszörményi Zoltán 
---

With the hardcoded initrd filename suffix but INITRAMFS_FSTYPES
set to cpio.lzma, this error occurs:

ERROR: sicom-pos-image-1.0-r0 do_bootimg: 
.../deploy/glibc/images/intel-core2-32/core-image-minimal-initramfs-intel-core2-32.cpio.lzma
 is invalid. initrd image creation failed.
ERROR: sicom-pos-image-1.0-r0 do_bootimg: Function failed: build_hddimg (log 
file is located at 
.../tmp-sicom-glibc/work/intel_core2_32-sicom-linux/sicom-pos-image/1.0-r0/temp/log.do_bootimg.32210)
ERROR: Logfile of failure stored in: 
.../tmp-sicom-glibc/work/intel_core2_32-sicom-linux/sicom-pos-image/1.0-r0/temp/log.do_bootimg.32210
ERROR: Task (.../layers/meta-sicom/images/sicom-pos-image.bb:do_bootimg) failed 
with exit code '1'

 meta/classes/image-live.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/image-live.bbclass b/meta/classes/image-live.bbclass
index af71be5093..54058b350d 100644
--- a/meta/classes/image-live.bbclass
+++ b/meta/classes/image-live.bbclass
@@ -37,7 +37,7 @@ do_bootimg[depends] += "dosfstools-native:do_populate_sysroot 
\
 LABELS_LIVE ?= "boot install"
 ROOT_LIVE ?= "root=/dev/ram0"
 INITRD_IMAGE_LIVE ?= "${MLPREFIX}core-image-minimal-initramfs"
-INITRD_LIVE ?= "${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_LIVE}-${MACHINE}.cpio.gz"
+INITRD_LIVE ?= 
"${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_LIVE}-${MACHINE}.${INITRAMFS_FSTYPES}"
 
 LIVE_ROOTFS_TYPE ?= "ext4"
 ROOTFS ?= "${IMGDEPLOYDIR}/${IMAGE_LINK_NAME}.${LIVE_ROOTFS_TYPE}"
-- 
2.21.0

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

[OE-core] [warrior][PATCH] classes/image-live.bbclass: Don't hardcode cpio.gz

[Böszörményi Zoltán via Openembedded-core]

There's INITRAMFS_FSTYPES that can be set differently.

Signed-off-by: Böszörményi Zoltán 
---

With the hardcoded initrd filename suffix but INITRAMFS_FSTYPES
set to cpio.lzma, this error occurs:

ERROR: sicom-pos-image-1.0-r0 do_bootimg: 
.../deploy/glibc/images/intel-core2-32/core-image-minimal-initramfs-intel-core2-32.cpio.lzma
 is invalid. initrd image creation failed.
ERROR: sicom-pos-image-1.0-r0 do_bootimg: Function failed: build_hddimg (log 
file is located at 
.../tmp-sicom-glibc/work/intel_core2_32-sicom-linux/sicom-pos-image/1.0-r0/temp/log.do_bootimg.32210)
ERROR: Logfile of failure stored in: 
.../tmp-sicom-glibc/work/intel_core2_32-sicom-linux/sicom-pos-image/1.0-r0/temp/log.do_bootimg.32210
ERROR: Task (.../layers/meta-sicom/images/sicom-pos-image.bb:do_bootimg) failed 
with exit code '1'

 meta/classes/image-live.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/image-live.bbclass b/meta/classes/image-live.bbclass
index af71be5093..54058b350d 100644
--- a/meta/classes/image-live.bbclass
+++ b/meta/classes/image-live.bbclass
@@ -37,7 +37,7 @@ do_bootimg[depends] += "dosfstools-native:do_populate_sysroot 
\
 LABELS_LIVE ?= "boot install"
 ROOT_LIVE ?= "root=/dev/ram0"
 INITRD_IMAGE_LIVE ?= "${MLPREFIX}core-image-minimal-initramfs"
-INITRD_LIVE ?= "${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_LIVE}-${MACHINE}.cpio.gz"
+INITRD_LIVE ?= 
"${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_LIVE}-${MACHINE}.${INITRAMFS_FSTYPES}"
 
 LIVE_ROOTFS_TYPE ?= "ext4"
 ROOTFS ?= "${IMGDEPLOYDIR}/${IMAGE_LINK_NAME}.${LIVE_ROOTFS_TYPE}"
-- 
2.21.0

-- 
___
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

[Diego Rondini]

Hi Ross,

On Wed, Sep 25, 2019 at 9:40 PM Ross Burton  wrote:

> 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
>

I've seen ntpath has been added back to python3-core with this commit:
http://git.openembedded.org/openembedded-core/commit/meta/recipes-devtools/python/python3/python3-manifest.json?id=9ff61fa83a0a4f2a7b5b0376b6c48fb1173c9ac7
so my change makes sense only in warrior.

Can you please explain how you trigger that error?

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

Re: [OE-core] [PATCH v2 4/4] weston: Set depends to the virtual needed not explicitly on Mesa

[Stefan Agner]

On 2019-09-17 15:10, Andrew F. Davis via Openembedded-core wrote:
> The dependency is for EGL and GLES2 libraries. On some systems these
> are not provided by Mesa, list what is actually needed so the system
> can choose the correct provider.

Unfortunately I saw that a bit late, but this is breaking our use case.

Weston works perfectly fine on non-GPU systems without EGL/OpenGL ES
using pixman renderer. Currently libgbm is still a compile time
dependency, but I have a merge request pending which should drop this
dependency, then the DRM backend can be compiled fine with only KMS
support.

--
Stefan


> 
> Signed-off-by: Andrew F. Davis 
> Acked-by: Denys Dmytriyenko 
> ---
> 
> Changes from v1:
>  - s/gles2/libgles2
> 
>  meta/recipes-graphics/wayland/weston_7.0.0.bb | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/recipes-graphics/wayland/weston_7.0.0.bb
> b/meta/recipes-graphics/wayland/weston_7.0.0.bb
> index 5d2a9336f3..f9efdbd20a 100644
> --- a/meta/recipes-graphics/wayland/weston_7.0.0.bb
> +++ b/meta/recipes-graphics/wayland/weston_7.0.0.bb
> @@ -36,9 +36,9 @@ PACKAGECONFIG ??=
> "${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 'kms fbdev
>  # Compositor choices
>  #
>  # Weston on KMS
> -PACKAGECONFIG[kms] = "-Dbackend-drm=true,-Dbackend-drm=false,drm udev
> virtual/mesa virtual/libgbm mtdev"
> +PACKAGECONFIG[kms] = "-Dbackend-drm=true,-Dbackend-drm=false,drm udev
> virtual/egl virtual/libgles2 virtual/libgbm mtdev"
>  # Weston on Wayland (nested Weston)
> -PACKAGECONFIG[wayland] =
> "-Dbackend-wayland=true,-Dbackend-wayland=false,virtual/mesa"
> +PACKAGECONFIG[wayland] =
> "-Dbackend-wayland=true,-Dbackend-wayland=false,virtual/egl
> virtual/libgles2"
>  # Weston on X11
>  PACKAGECONFIG[x11] =
> "-Dbackend-x11=true,-Dbackend-x11=false,virtual/libx11 libxcb libxcb
> libxcursor cairo"
>  # Headless Weston
> -- 
> 2.17.1
-- 
___
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

[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