[OE-core] [PATCH v2 2/2] qemu: fix CVE-2021-3392

[Anuj Mittal]

Signed-off-by: Anuj Mittal 
---
 meta/recipes-devtools/qemu/qemu.inc   |  1 +
 .../qemu/qemu/CVE-2021-3392.patch | 89 +++
 2 files changed, 90 insertions(+)
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2021-3392.patch

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index 810d8b7c8a..384b0c19b0 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -56,6 +56,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
file://CVE-2021-20257.patch \
file://CVE-2020-27821.patch \
file://CVE-2021-20263.patch \
+   file://CVE-2021-3392.patch \
"
 UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
 
diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2021-3392.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2021-3392.patch
new file mode 100644
index 00..af94cff7e8
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2021-3392.patch
@@ -0,0 +1,89 @@
+From 3791642c8d60029adf9b00bcb4e34d7d8a1aea4d Mon Sep 17 00:00:00 2001
+From: Michael Tokarev 
+Date: Mon, 19 Apr 2021 15:42:47 +0200
+Subject: [PATCH] mptsas: Remove unused MPTSASState 'pending' field
+ (CVE-2021-3392)
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+While processing SCSI i/o requests in mptsas_process_scsi_io_request(),
+the Megaraid emulator appends new MPTSASRequest object 'req' to
+the 's->pending' queue. In case of an error, this same object gets
+dequeued in mptsas_free_request() only if SCSIRequest object
+'req->sreq' is initialised. This may lead to a use-after-free issue.
+
+Since s->pending is actually not used, simply remove it from
+MPTSASState.
+
+Cc: qemu-sta...@nongnu.org
+Signed-off-by: Michael Tokarev 
+Reviewed-by: Philippe Mathieu-Daudé 
+Signed-off-by: Philippe Mathieu-Daudé 
+Reported-by: Cheolwoo Myung 
+Message-id: 20210419134247.1467982-1-f4...@amsat.org
+Message-Id: <20210416102243.1293871-1-...@msgid.tls.msk.ru>
+Suggested-by: Paolo Bonzini 
+Reported-by: Cheolwoo Myung 
+BugLink: https://bugs.launchpad.net/qemu/+bug/1914236 (CVE-2021-3392)
+Fixes: e351b826112 ("hw: Add support for LSI SAS1068 (mptsas) device")
+[PMD: Reworded description, added more tags]
+Signed-off-by: Philippe Mathieu-Daudé 
+Reviewed-by: Peter Maydell 
+Signed-off-by: Peter Maydell 
+
+CVE: CVE-2021-3392
+Upstream-Status: Backport 
[https://git.qemu.org/?p=qemu.git;a=commit;h=3791642c8d60029adf9b00bcb4e34d7d8a1aea4d]
+Signed-off-by: Anuj Mittal 
+---
+ hw/scsi/mptsas.c | 6 --
+ hw/scsi/mptsas.h | 1 -
+ 2 files changed, 7 deletions(-)
+
+diff --git a/hw/scsi/mptsas.c b/hw/scsi/mptsas.c
+index 7416e7870614..db3219e7d206 100644
+--- a/hw/scsi/mptsas.c
 b/hw/scsi/mptsas.c
+@@ -251,13 +251,10 @@ static int mptsas_build_sgl(MPTSASState *s, 
MPTSASRequest *req, hwaddr addr)
+ 
+ static void mptsas_free_request(MPTSASRequest *req)
+ {
+-MPTSASState *s = req->dev;
+-
+ if (req->sreq != NULL) {
+ req->sreq->hba_private = NULL;
+ scsi_req_unref(req->sreq);
+ req->sreq = NULL;
+-QTAILQ_REMOVE(>pending, req, next);
+ }
+ qemu_sglist_destroy(>qsg);
+ g_free(req);
+@@ -303,7 +300,6 @@ static int mptsas_process_scsi_io_request(MPTSASState *s,
+ }
+ 
+ req = g_new0(MPTSASRequest, 1);
+-QTAILQ_INSERT_TAIL(>pending, req, next);
+ req->scsi_io = *scsi_io;
+ req->dev = s;
+ 
+@@ -1319,8 +1315,6 @@ static void mptsas_scsi_realize(PCIDevice *dev, Error 
**errp)
+ 
+ s->request_bh = qemu_bh_new(mptsas_fetch_requests, s);
+ 
+-QTAILQ_INIT(>pending);
+-
+ scsi_bus_new(>bus, sizeof(s->bus), >qdev, _scsi_info, 
NULL);
+ }
+ 
+diff --git a/hw/scsi/mptsas.h b/hw/scsi/mptsas.h
+index b85ac1a5fcc7..c046497db719 100644
+--- a/hw/scsi/mptsas.h
 b/hw/scsi/mptsas.h
+@@ -79,7 +79,6 @@ struct MPTSASState {
+ uint16_t reply_frame_size;
+ 
+ SCSIBus bus;
+-QTAILQ_HEAD(, MPTSASRequest) pending;
+ };
+ 
+ void mptsas_fix_scsi_io_endianness(MPIMsgSCSIIORequest *req);
-- 
2.30.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151258): 
https://lists.openembedded.org/g/openembedded-core/message/151258
Mute This Topic: https://lists.openembedded.org/mt/82596027/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH v2 1/2] Revert "qemu: fix CVE-2021-3392"

[Anuj Mittal]

This reverts commit 5e8e08df8b5d0040ad911d3c51f63e7fec1858b4.

This is an incomplete fix.

Signed-off-by: Anuj Mittal 
---
 meta/recipes-devtools/qemu/qemu.inc   |  1 -
 .../qemu/qemu/CVE-2021-3392.patch | 45 ---
 2 files changed, 46 deletions(-)
 delete mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2021-3392.patch

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index 486f404668..810d8b7c8a 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -54,7 +54,6 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
file://CVE-2021-3416_9.patch \
file://CVE-2021-3416_10.patch \
file://CVE-2021-20257.patch \
-  file://CVE-2021-3392.patch \
file://CVE-2020-27821.patch \
file://CVE-2021-20263.patch \
"
diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2021-3392.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2021-3392.patch
deleted file mode 100644
index 1c688827db..00
--- a/meta/recipes-devtools/qemu/qemu/CVE-2021-3392.patch
+++ /dev/null
@@ -1,45 +0,0 @@
-From 3431b01b43584de5f710c40605fe3251f81c0e11 Mon Sep 17 00:00:00 2001
-From: Minjae Kim 
-Date: Tue, 27 Apr 2021 02:09:49 +
-Subject: [PATCH] scsi: mptsas: dequeue request object in case of an error
- (CVE-2021-3392)
-
-From: Prasad J Pandit 
-
-While processing SCSI i/o requests in mptsas_process_scsi_io_request(),
-the Megaraid emulator appends new MPTSASRequest object 'req' to
-the 's->pending' queue. In case of an error, this same object gets
-dequeued in mptsas_free_request() only if SCSIRequest object
-'req->sreq' is initialised. This may lead to a use-after-free issue.
-Unconditionally dequeue 'req' object from 's->pending' to avoid it.
-
-Fixes: CVE-2021-3392
-Buglink: https://bugs.launchpad.net/qemu/+bug/1914236
-Reported-by: Cheolwoo Myung 
-Signed-off-by: Prasad J Pandit 
-
-Upstream-Status: Acepted
-[https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg00488.html]
-CVE: CVE-2021-3392
-Signed-off-by: Minjae Kim 

- hw/scsi/mptsas.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/hw/scsi/mptsas.c b/hw/scsi/mptsas.c
-index f86616544..adff5b0bf 100644
 a/hw/scsi/mptsas.c
-+++ b/hw/scsi/mptsas.c
-@@ -257,8 +257,8 @@ static void mptsas_free_request(MPTSASRequest *req)
- req->sreq->hba_private = NULL;
- scsi_req_unref(req->sreq);
- req->sreq = NULL;
--QTAILQ_REMOVE(>pending, req, next);
- }
-+QTAILQ_REMOVE(>pending, req, next);
- qemu_sglist_destroy(>qsg);
- g_free(req);
- }
--- 
-2.17.1
-
-- 
2.30.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151257): 
https://lists.openembedded.org/g/openembedded-core/message/151257
Mute This Topic: https://lists.openembedded.org/mt/82596026/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [gatesgarth][PATCH] populate_sdk_ext: Avoid copying and producing .pyc files

[Anuj Mittal]

From: Mark Hatle 

Since pyc cache files are really system specific, no real reason to copy or
generate them during the eSDK build process.  Also generating them has the
possibility of re-using inodes that pseudo may have been tracking, leading
a build failure.

Signed-off-by: Mark Hatle 
Signed-off-by: Richard Purdie 
(cherry picked from commit ce8eba263647ae63a722122e28f26af46ae083a0)
Signed-off-by: Anuj Mittal 
---
 meta/classes/populate_sdk_ext.bbclass | 4 +++-
 meta/lib/oe/copy_buildsystem.py   | 6 +++---
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/meta/classes/populate_sdk_ext.bbclass 
b/meta/classes/populate_sdk_ext.bbclass
index 9112ab6c5e..14689ec6ac 100644
--- a/meta/classes/populate_sdk_ext.bbclass
+++ b/meta/classes/populate_sdk_ext.bbclass
@@ -251,7 +251,9 @@ python copy_buildsystem () {
 
 # Create a layer for new recipes / appends
 bbpath = d.getVar('BBPATH')
-bb.process.run(['devtool', '--bbpath', bbpath, '--basepath', baseoutpath, 
'create-workspace', '--create-only', os.path.join(baseoutpath, 'workspace')])
+env = os.environ.copy()
+env['PYTHONDONTWRITEBYTECODE'] = '1'
+bb.process.run(['devtool', '--bbpath', bbpath, '--basepath', baseoutpath, 
'create-workspace', '--create-only', os.path.join(baseoutpath, 'workspace')], 
env=env)
 
 # Create bblayers.conf
 bb.utils.mkdirhier(baseoutpath + '/conf')
diff --git a/meta/lib/oe/copy_buildsystem.py b/meta/lib/oe/copy_buildsystem.py
index 31a84f5b06..d97bf9d1b9 100644
--- a/meta/lib/oe/copy_buildsystem.py
+++ b/meta/lib/oe/copy_buildsystem.py
@@ -20,7 +20,7 @@ def _smart_copy(src, dest):
 mode = os.stat(src).st_mode
 if stat.S_ISDIR(mode):
 bb.utils.mkdirhier(dest)
-cmd = "tar --exclude='.git' --xattrs --xattrs-include='*' -chf - -C %s 
-p . \
+cmd = "tar --exclude='.git' --exclude='__pycache__' --xattrs 
--xattrs-include='*' -chf - -C %s -p . \
 | tar --xattrs --xattrs-include='*' -xf - -C %s" % (src, dest)
 subprocess.check_output(cmd, shell=True, stderr=subprocess.STDOUT)
 else:
@@ -259,7 +259,7 @@ def create_locked_sstate_cache(lockedsigs, 
input_sstate_cache, output_sstate_cac
 bb.note('Generating sstate-cache...')
 
 nativelsbstring = d.getVar('NATIVELSBSTRING')
-bb.process.run("gen-lockedsig-cache %s %s %s %s %s" % (lockedsigs, 
input_sstate_cache, output_sstate_cache, nativelsbstring, filterfile or ''))
+bb.process.run("PYTHONDONTWRITEBYTECODE=1 gen-lockedsig-cache %s %s %s %s 
%s" % (lockedsigs, input_sstate_cache, output_sstate_cache, nativelsbstring, 
filterfile or ''))
 if fixedlsbstring and nativelsbstring != fixedlsbstring:
 nativedir = output_sstate_cache + '/' + nativelsbstring
 if os.path.isdir(nativedir):
@@ -286,7 +286,7 @@ def check_sstate_task_list(d, targets, filteroutfile, 
cmdprefix='', cwd=None, lo
 logparam = '-l %s' % logfile
 else:
 logparam = ''
-cmd = "%sBB_SETSCENE_ENFORCE=1 PSEUDO_DISABLED=1 oe-check-sstate %s -s -o 
%s %s" % (cmdprefix, targets, filteroutfile, logparam)
+cmd = "%sPYTHONDONTWRITEBYTECODE=1 BB_SETSCENE_ENFORCE=1 PSEUDO_DISABLED=1 
oe-check-sstate %s -s -o %s %s" % (cmdprefix, targets, filteroutfile, logparam)
 env = dict(d.getVar('BB_ORIGENV', False))
 env.pop('BUILDDIR', '')
 env.pop('BBPATH', '')
-- 
2.30.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151256): 
https://lists.openembedded.org/g/openembedded-core/message/151256
Mute This Topic: https://lists.openembedded.org/mt/82595788/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 2/2] qemu: fix CVE-2021-3392

[Anuj Mittal]

Signed-off-by: Anuj Mittal 
---
 meta/recipes-devtools/qemu/qemu.inc   |  1 +
 .../qemu/qemu/CVE-2021-3392.patch | 89 +++
 2 files changed, 90 insertions(+)
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2021-3392.patch

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index 46b784241e..b5995d0e6a 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -54,6 +54,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
file://CVE-2021-3416_9.patch \
file://CVE-2021-3416_10.patch \
file://CVE-2021-20257.patch \
+   file://CVE-2021-3392.patch \
"
 UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
 
diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2021-3392.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2021-3392.patch
new file mode 100644
index 00..af94cff7e8
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2021-3392.patch
@@ -0,0 +1,89 @@
+From 3791642c8d60029adf9b00bcb4e34d7d8a1aea4d Mon Sep 17 00:00:00 2001
+From: Michael Tokarev 
+Date: Mon, 19 Apr 2021 15:42:47 +0200
+Subject: [PATCH] mptsas: Remove unused MPTSASState 'pending' field
+ (CVE-2021-3392)
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+While processing SCSI i/o requests in mptsas_process_scsi_io_request(),
+the Megaraid emulator appends new MPTSASRequest object 'req' to
+the 's->pending' queue. In case of an error, this same object gets
+dequeued in mptsas_free_request() only if SCSIRequest object
+'req->sreq' is initialised. This may lead to a use-after-free issue.
+
+Since s->pending is actually not used, simply remove it from
+MPTSASState.
+
+Cc: qemu-sta...@nongnu.org
+Signed-off-by: Michael Tokarev 
+Reviewed-by: Philippe Mathieu-Daudé 
+Signed-off-by: Philippe Mathieu-Daudé 
+Reported-by: Cheolwoo Myung 
+Message-id: 20210419134247.1467982-1-f4...@amsat.org
+Message-Id: <20210416102243.1293871-1-...@msgid.tls.msk.ru>
+Suggested-by: Paolo Bonzini 
+Reported-by: Cheolwoo Myung 
+BugLink: https://bugs.launchpad.net/qemu/+bug/1914236 (CVE-2021-3392)
+Fixes: e351b826112 ("hw: Add support for LSI SAS1068 (mptsas) device")
+[PMD: Reworded description, added more tags]
+Signed-off-by: Philippe Mathieu-Daudé 
+Reviewed-by: Peter Maydell 
+Signed-off-by: Peter Maydell 
+
+CVE: CVE-2021-3392
+Upstream-Status: Backport 
[https://git.qemu.org/?p=qemu.git;a=commit;h=3791642c8d60029adf9b00bcb4e34d7d8a1aea4d]
+Signed-off-by: Anuj Mittal 
+---
+ hw/scsi/mptsas.c | 6 --
+ hw/scsi/mptsas.h | 1 -
+ 2 files changed, 7 deletions(-)
+
+diff --git a/hw/scsi/mptsas.c b/hw/scsi/mptsas.c
+index 7416e7870614..db3219e7d206 100644
+--- a/hw/scsi/mptsas.c
 b/hw/scsi/mptsas.c
+@@ -251,13 +251,10 @@ static int mptsas_build_sgl(MPTSASState *s, 
MPTSASRequest *req, hwaddr addr)
+ 
+ static void mptsas_free_request(MPTSASRequest *req)
+ {
+-MPTSASState *s = req->dev;
+-
+ if (req->sreq != NULL) {
+ req->sreq->hba_private = NULL;
+ scsi_req_unref(req->sreq);
+ req->sreq = NULL;
+-QTAILQ_REMOVE(>pending, req, next);
+ }
+ qemu_sglist_destroy(>qsg);
+ g_free(req);
+@@ -303,7 +300,6 @@ static int mptsas_process_scsi_io_request(MPTSASState *s,
+ }
+ 
+ req = g_new0(MPTSASRequest, 1);
+-QTAILQ_INSERT_TAIL(>pending, req, next);
+ req->scsi_io = *scsi_io;
+ req->dev = s;
+ 
+@@ -1319,8 +1315,6 @@ static void mptsas_scsi_realize(PCIDevice *dev, Error 
**errp)
+ 
+ s->request_bh = qemu_bh_new(mptsas_fetch_requests, s);
+ 
+-QTAILQ_INIT(>pending);
+-
+ scsi_bus_new(>bus, sizeof(s->bus), >qdev, _scsi_info, 
NULL);
+ }
+ 
+diff --git a/hw/scsi/mptsas.h b/hw/scsi/mptsas.h
+index b85ac1a5fcc7..c046497db719 100644
+--- a/hw/scsi/mptsas.h
 b/hw/scsi/mptsas.h
+@@ -79,7 +79,6 @@ struct MPTSASState {
+ uint16_t reply_frame_size;
+ 
+ SCSIBus bus;
+-QTAILQ_HEAD(, MPTSASRequest) pending;
+ };
+ 
+ void mptsas_fix_scsi_io_endianness(MPIMsgSCSIIORequest *req);
-- 
2.30.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151255): 
https://lists.openembedded.org/g/openembedded-core/message/151255
Mute This Topic: https://lists.openembedded.org/mt/82595766/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 1/2] Revert "qemu: fix CVE-2021-3392"

[Anuj Mittal]

This reverts commit 5e8e08df8b5d0040ad911d3c51f63e7fec1858b4.

This is an incomplete fix.

Signed-off-by: Anuj Mittal 
---
 meta/recipes-devtools/qemu/qemu.inc   |  1 -
 .../qemu/qemu/CVE-2021-3392.patch | 45 ---
 2 files changed, 46 deletions(-)
 delete mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2021-3392.patch

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index 062d7907cf..46b784241e 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -54,7 +54,6 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
file://CVE-2021-3416_9.patch \
file://CVE-2021-3416_10.patch \
file://CVE-2021-20257.patch \
-  file://CVE-2021-3392.patch \
"
 UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
 
diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2021-3392.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2021-3392.patch
deleted file mode 100644
index 1c688827db..00
--- a/meta/recipes-devtools/qemu/qemu/CVE-2021-3392.patch
+++ /dev/null
@@ -1,45 +0,0 @@
-From 3431b01b43584de5f710c40605fe3251f81c0e11 Mon Sep 17 00:00:00 2001
-From: Minjae Kim 
-Date: Tue, 27 Apr 2021 02:09:49 +
-Subject: [PATCH] scsi: mptsas: dequeue request object in case of an error
- (CVE-2021-3392)
-
-From: Prasad J Pandit 
-
-While processing SCSI i/o requests in mptsas_process_scsi_io_request(),
-the Megaraid emulator appends new MPTSASRequest object 'req' to
-the 's->pending' queue. In case of an error, this same object gets
-dequeued in mptsas_free_request() only if SCSIRequest object
-'req->sreq' is initialised. This may lead to a use-after-free issue.
-Unconditionally dequeue 'req' object from 's->pending' to avoid it.
-
-Fixes: CVE-2021-3392
-Buglink: https://bugs.launchpad.net/qemu/+bug/1914236
-Reported-by: Cheolwoo Myung 
-Signed-off-by: Prasad J Pandit 
-
-Upstream-Status: Acepted
-[https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg00488.html]
-CVE: CVE-2021-3392
-Signed-off-by: Minjae Kim 

- hw/scsi/mptsas.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/hw/scsi/mptsas.c b/hw/scsi/mptsas.c
-index f86616544..adff5b0bf 100644
 a/hw/scsi/mptsas.c
-+++ b/hw/scsi/mptsas.c
-@@ -257,8 +257,8 @@ static void mptsas_free_request(MPTSASRequest *req)
- req->sreq->hba_private = NULL;
- scsi_req_unref(req->sreq);
- req->sreq = NULL;
--QTAILQ_REMOVE(>pending, req, next);
- }
-+QTAILQ_REMOVE(>pending, req, next);
- qemu_sglist_destroy(>qsg);
- g_free(req);
- }
--- 
-2.17.1
-
-- 
2.30.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151254): 
https://lists.openembedded.org/g/openembedded-core/message/151254
Mute This Topic: https://lists.openembedded.org/mt/82595765/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Khem Raj]

Changes are here [1]

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

Signed-off-by: Khem Raj 
---
 meta/recipes-devtools/strace/{strace_5.11.bb => strace_5.12.bb} | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-devtools/strace/{strace_5.11.bb => strace_5.12.bb} (96%)

diff --git a/meta/recipes-devtools/strace/strace_5.11.bb 
b/meta/recipes-devtools/strace/strace_5.12.bb
similarity index 96%
rename from meta/recipes-devtools/strace/strace_5.11.bb
rename to meta/recipes-devtools/strace/strace_5.12.bb
index f6a91df1d2..6a8996535b 100644
--- a/meta/recipes-devtools/strace/strace_5.11.bb
+++ b/meta/recipes-devtools/strace/strace_5.12.bb
@@ -15,7 +15,7 @@ SRC_URI = "https://strace.io/files/${PV}/strace-${PV}.tar.xz \
file://uintptr_t.patch \
file://0001-strace-fix-reproducibilty-issues.patch \
"
-SRC_URI[sha256sum] = 
"ffe340b10c145a0f85734271e9cce56457d23f21a7ea5931ab32f8cf4e793879"
+SRC_URI[sha256sum] = 
"29171edf9d252f89c988a4c340dfdec662f458cb8c63d85431d64bab5911e7c4"
 
 inherit autotools ptest
 
-- 
2.31.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151253): 
https://lists.openembedded.org/g/openembedded-core/message/151253
Mute This Topic: https://lists.openembedded.org/mt/82593144/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [yocto] Yocto Project Status WW18`21

[Richard Purdie]

On Tue, 2021-05-04 at 18:38 +0200, Alexander Kanavin wrote:
> On Tue, 4 May 2021 at 16:46, Stephen Jolley  wrote:
> > We are pleased to announce that our April 2022 release (potentially 3.5) 
> > will 
> > be the next LTS as per our original two year schedule. If there are 
> > features 
> > desired in the next LTS, now is the time to get them submitted and 
> > stabilized
> > ready.
> > 
> 
> What will happen to the current LTS at that point? Will support be cut off, 
> will there be a transition window, or is it currently undefined?

We have discussed extending it but we currently only have the funding for the
originally planned 2 years. Discussions are continuing but since we do all 
agree that the next LTS will start then, we decided to at least let people 
plan against that.

Unless funding/support is secured, dunfell would move to community support
if anyone were willing to step up, or become EOL and replaced by the new LTS.
There would likely be some period of overlap of a few months to transition.

There is also concern about pressuring wider community layers for longer support
cycles which is something we need to think about.

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151252): 
https://lists.openembedded.org/g/openembedded-core/message/151252
Mute This Topic: https://lists.openembedded.org/mt/82582269/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] making the meaning of "FILES_${PN}-bin" a little more obvious?

[Robert P. J. Day]

On Tue, 4 May 2021, Richard Purdie wrote:

> On Tue, 2021-05-04 at 16:31 -0400, Robert P. J. Day wrote:
> > On Tue, 4 May 2021, Richard Purdie wrote:
> >
> > > On Tue, 2021-05-04 at 09:31 -0400, Robert P. J. Day wrote:
> > > >   more nitpickery, but i note in OE's current bitbake.conf the
> > > > initially odd definitions:
> > > >
> > > >   FILES_${PN} = "${bindir}/* ${sbindir}/* ...'
> > > >  ... snip ...
> > > >
> > > >   FILES_${PN}-bin = "${bindir}/* ${sbindir}/*"
> > > >
> > > > i say "odd" since someone perusing that file could be confused, first,
> > > > that that "-bin" package definition overlaps with the base package
> > > > file list and, more, that just above that, the definition of PACKAGES
> > > > doesn't include the "-bin" package:
> > > >
> > > >   PACKAGES = "${PN}-src ${PN}-dbg ${PN}-staticdev ${PN}-dev \
> > > >   ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN}"
> > > >
> > > > so anyone currently RTFS is likely to stop and think, "what the heck
> > > > is the '-bin' package defined for if it's not even included in the
> > > > normal package list?"
> > > >
> > > >   of course, one need to consult lib_package.bbclass to finally
> > > > understand what its purpose is:
> > > >
> > > >   PACKAGE_BEFORE_PN = "${PN}-bin"
> > > >
> > > > but if that's the only purpose for that package definition, would it
> > > > not make more sense to just move it to lib_package.bbclass so it's
> > > > next to the variable setting that actually causes it to be processed?
> > > >
> > > >   of course it works as is, it just seems unnecessarily confusing,
> > > > unless there's some subtle ordering requirement happening here.
> > >
> > > I suspect such a change may break as some other recipe may use
> > > ${PN}-bin but not the class. We'd need a careful audit to figure it
> > > out...
> >
> >   i know this seems like a minor point, but i'll expand on this a bit
> > more, then i'll shut the hell up about it.
> >
> >   as i read it, the *only* context where a package called
> > "FILES_${PN}-bin" makes sense is to separate the binaries from an
> > obvious library package, where -- in the overwhelming number of cases
> > -- any binaries that accompany a library package are non-essential
> > executables for things like, say, configuration, or a demo program, or
> > possibly debugging, that sort of thing.
> >
> >   so you're absolutely right -- combining the package definition with
> > its inclusion in the PACKAGES variable in lib_package.bbclass might
> > very well break something, but i submit that that's something that can
> > then be cleaned up, the object being that, whenever anyone sees
> > "FILES_${PN}-bin", they know *exactly* what it's being used for and
> > the code is clearer. if any recipe is using that variable for any
> > other reason, i submit that it's being misused and should be "fixed."
>
> I have no objection to the idea, I just wanted to make it clear there is 
> work that has to be done to do this. If someone steps up and does the work,
> great. What I don't particularly want is an untested patch which breaks 
> things and then I get forced into cleaning up the mess.

  i'll do an audit of a number of layers i have on my system, and if
it looks horrendous, i'll just drop the idea. if not, i'll work on the
patch.

rday

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151251): 
https://lists.openembedded.org/g/openembedded-core/message/151251
Mute This Topic: https://lists.openembedded.org/mt/82577515/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] making the meaning of "FILES_${PN}-bin" a little more obvious?

[Richard Purdie]

On Tue, 2021-05-04 at 16:31 -0400, Robert P. J. Day wrote:
> On Tue, 4 May 2021, Richard Purdie wrote:
> 
> > On Tue, 2021-05-04 at 09:31 -0400, Robert P. J. Day wrote:
> > >   more nitpickery, but i note in OE's current bitbake.conf the
> > > initially odd definitions:
> > > 
> > >   FILES_${PN} = "${bindir}/* ${sbindir}/* ...'
> > >  ... snip ...
> > > 
> > >   FILES_${PN}-bin = "${bindir}/* ${sbindir}/*"
> > > 
> > > i say "odd" since someone perusing that file could be confused, first,
> > > that that "-bin" package definition overlaps with the base package
> > > file list and, more, that just above that, the definition of PACKAGES
> > > doesn't include the "-bin" package:
> > > 
> > >   PACKAGES = "${PN}-src ${PN}-dbg ${PN}-staticdev ${PN}-dev \
> > >   ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN}"
> > > 
> > > so anyone currently RTFS is likely to stop and think, "what the heck
> > > is the '-bin' package defined for if it's not even included in the
> > > normal package list?"
> > > 
> > >   of course, one need to consult lib_package.bbclass to finally
> > > understand what its purpose is:
> > > 
> > >   PACKAGE_BEFORE_PN = "${PN}-bin"
> > > 
> > > but if that's the only purpose for that package definition, would it
> > > not make more sense to just move it to lib_package.bbclass so it's
> > > next to the variable setting that actually causes it to be processed?
> > > 
> > >   of course it works as is, it just seems unnecessarily confusing,
> > > unless there's some subtle ordering requirement happening here.
> > 
> > I suspect such a change may break as some other recipe may use
> > ${PN}-bin but not the class. We'd need a careful audit to figure it
> > out...
> 
>   i know this seems like a minor point, but i'll expand on this a bit
> more, then i'll shut the hell up about it.
> 
>   as i read it, the *only* context where a package called
> "FILES_${PN}-bin" makes sense is to separate the binaries from an
> obvious library package, where -- in the overwhelming number of cases
> -- any binaries that accompany a library package are non-essential
> executables for things like, say, configuration, or a demo program, or
> possibly debugging, that sort of thing.
> 
>   so you're absolutely right -- combining the package definition with
> its inclusion in the PACKAGES variable in lib_package.bbclass might
> very well break something, but i submit that that's something that can
> then be cleaned up, the object being that, whenever anyone sees
> "FILES_${PN}-bin", they know *exactly* what it's being used for and
> the code is clearer. if any recipe is using that variable for any
> other reason, i submit that it's being misused and should be "fixed."

I have no objection to the idea, I just wanted to make it clear there is 
work that has to be done to do this. If someone steps up and does the work,
great. What I don't particularly want is an untested patch which breaks 
things and then I get forced into cleaning up the mess.

Cheers,

Richard





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151250): 
https://lists.openembedded.org/g/openembedded-core/message/151250
Mute This Topic: https://lists.openembedded.org/mt/82577515/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] making the meaning of "FILES_${PN}-bin" a little more obvious?

[Robert P. J. Day]

On Tue, 4 May 2021, Richard Purdie wrote:

> On Tue, 2021-05-04 at 09:31 -0400, Robert P. J. Day wrote:
> >   more nitpickery, but i note in OE's current bitbake.conf the
> > initially odd definitions:
> >
> >   FILES_${PN} = "${bindir}/* ${sbindir}/* ...'
> >  ... snip ...
> >
> >   FILES_${PN}-bin = "${bindir}/* ${sbindir}/*"
> >
> > i say "odd" since someone perusing that file could be confused, first,
> > that that "-bin" package definition overlaps with the base package
> > file list and, more, that just above that, the definition of PACKAGES
> > doesn't include the "-bin" package:
> >
> >   PACKAGES = "${PN}-src ${PN}-dbg ${PN}-staticdev ${PN}-dev \
> >   ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN}"
> >
> > so anyone currently RTFS is likely to stop and think, "what the heck
> > is the '-bin' package defined for if it's not even included in the
> > normal package list?"
> >
> >   of course, one need to consult lib_package.bbclass to finally
> > understand what its purpose is:
> >
> >   PACKAGE_BEFORE_PN = "${PN}-bin"
> >
> > but if that's the only purpose for that package definition, would it
> > not make more sense to just move it to lib_package.bbclass so it's
> > next to the variable setting that actually causes it to be processed?
> >
> >   of course it works as is, it just seems unnecessarily confusing,
> > unless there's some subtle ordering requirement happening here.
>
> I suspect such a change may break as some other recipe may use
> ${PN}-bin but not the class. We'd need a careful audit to figure it
> out...

  i know this seems like a minor point, but i'll expand on this a bit
more, then i'll shut the hell up about it.

  as i read it, the *only* context where a package called
"FILES_${PN}-bin" makes sense is to separate the binaries from an
obvious library package, where -- in the overwhelming number of cases
-- any binaries that accompany a library package are non-essential
executables for things like, say, configuration, or a demo program, or
possibly debugging, that sort of thing.

  so you're absolutely right -- combining the package definition with
its inclusion in the PACKAGES variable in lib_package.bbclass might
very well break something, but i submit that that's something that can
then be cleaned up, the object being that, whenever anyone sees
"FILES_${PN}-bin", they know *exactly* what it's being used for and
the code is clearer. if any recipe is using that variable for any
other reason, i submit that it's being misused and should be "fixed."

  anyway, i'll shut up now and find something else to gripe about. :-)


rday

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151249): 
https://lists.openembedded.org/g/openembedded-core/message/151249
Mute This Topic: https://lists.openembedded.org/mt/82577515/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH v2 3/3] gstreamer1.0: update ptest patch

[Khem Raj]

On Tue, May 4, 2021 at 11:23 AM Jose Quaresma  wrote:
>
> Khem Raj  escreveu no dia terça, 4/05/2021 à(s) 17:00:
> >
> > On Mon, May 3, 2021 at 10:09 AM Jose Quaresma  
> > wrote:
> > >
> > > - rework the ptest patch with a new one that are sent upstream [1].
> > > - it uses the same approach as the existing patch in OE-Core but
> > >   is based on the glib meson installed-tests [2] logic.
> > >
> > > * qemux86-64 ptest-runner result
> > >   SUMMARY: total=105; passed=105; skipped=0; failed=0; user=20.4s; 
> > > system=4.7s; maxrss=9928
> > >
> > > [1] - 
> > > https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/789
> > > [2] - 
> > > https://gitlab.gnome.org/GNOME/glib/-/commit/1bba3276bb3b7a878860ac01483574599b23853c
> > >
> > > Signed-off-by: Jose Quaresma 
> > > ---
> > >  .../gstreamer/gstreamer1.0-ptest.inc  |  23 --
> >
> > there are gstreamer recipes in other layers ( meta-freescale in my
> > case ) which depends on this file
> > how do you propose to fix those recipes ?
>
> meta-freescale has a fork of gstreamer os-core with all the patches [1]
> and one of them is the installed tests [2] that is removed as well.
> Thes installed tests patch on meta-freescale requires the 
> gstreamer1.0-ptest.inc
>
> I think the best solution is add the oe-core gstreamer1.0-ptest.inc on
> meta-freescale.
> I can submit it if this patch is accepted and merged on oe-core master.

please do so, thanks

>
> [1] - 
> https://git.yoctoproject.org/cgit/cgit.cgi/meta-freescale/tree/recipes-multimedia/gstreamer/gstreamer1.0*
> [2] - 
> https://git.yoctoproject.org/cgit/cgit.cgi/meta-freescale/tree/recipes-multimedia/gstreamer/gstreamer1.0/0004-meson-Add-option-for-installed-tests.patch
>
> >
> > >  ...meson-Add-option-for-installed-tests.patch | 257 --
> > >  ...spect-the-idententaion-used-in-meson.patch |  36 +++
> > >  ...ts-add-support-for-install-the-tests.patch | 110 
> > >  ...s-use-a-dictionaries-for-environment.patch |  48 
> > >  ...-the-environment-for-installed_tests.patch |  58 
> > >  .../gstreamer/gstreamer1.0/run-ptest  |   2 +
> > >  .../gstreamer/gstreamer1.0_1.18.4.bb  |  10 +-
> > >  8 files changed, 261 insertions(+), 283 deletions(-)
> > >  delete mode 100644 
> > > meta/recipes-multimedia/gstreamer/gstreamer1.0-ptest.inc
> > >  delete mode 100644 
> > > meta/recipes-multimedia/gstreamer/gstreamer1.0/0004-meson-Add-option-for-installed-tests.patch
> > >  create mode 100644 
> > > meta/recipes-multimedia/gstreamer/gstreamer1.0/0004-tests-respect-the-idententaion-used-in-meson.patch
> > >  create mode 100644 
> > > meta/recipes-multimedia/gstreamer/gstreamer1.0/0005-tests-add-support-for-install-the-tests.patch
> > >  create mode 100644 
> > > meta/recipes-multimedia/gstreamer/gstreamer1.0/0006-tests-use-a-dictionaries-for-environment.patch
> > >  create mode 100644 
> > > meta/recipes-multimedia/gstreamer/gstreamer1.0/0007-tests-install-the-environment-for-installed_tests.patch
> > >  create mode 100755 
> > > meta/recipes-multimedia/gstreamer/gstreamer1.0/run-ptest
> > >
> > > diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-ptest.inc 
> > > b/meta/recipes-multimedia/gstreamer/gstreamer1.0-ptest.inc
> > > deleted file mode 100644
> > > index b698067041..00
> > > --- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-ptest.inc
> > > +++ /dev/null
> > > @@ -1,23 +0,0 @@
> > > -inherit ptest-gnome
> > > -
> > > -TEST_FILES_PATH = "${datadir}/installed-tests/gstreamer-1.0/test-files"
> > > -RUN_PTEST_FILE = "${D}${PTEST_PATH}/run-ptest"
> > > -
> > > -EXTRA_OEMESON += "-Dtest-files-path=${TEST_FILES_PATH}"
> > > -
> > > -GST_TEST_SUITE_NAME ?= "gstreamer-1.0"
> > > -
> > > -# Using do_install_ptest_base instead of do_install_ptest, since
> > > -# the default do_install_ptest_base is hardcoded to expect Makefiles.
> > > -do_install_ptest_base() {
> > > -# Generate run-ptest file
> > > -echo "#!/usr/bin/env sh" > "${RUN_PTEST_FILE}"
> > > -echo "gnome-desktop-testing-runner ${GST_TEST_SUITE_NAME}" >> 
> > > "${RUN_PTEST_FILE}"
> > > -chmod 0755 "${RUN_PTEST_FILE}"
> > > -
> > > -# Install additional files required by tests
> > > -if [ -d "${S}/tests/files" ] ; then
> > > -install -d "${D}/${TEST_FILES_PATH}"
> > > -install -m 0644 "${S}/tests/files"/* "${D}/${TEST_FILES_PATH}"
> > > -fi
> > > -}
> > > diff --git 
> > > a/meta/recipes-multimedia/gstreamer/gstreamer1.0/0004-meson-Add-option-for-installed-tests.patch
> > >  
> > > b/meta/recipes-multimedia/gstreamer/gstreamer1.0/0004-meson-Add-option-for-installed-tests.patch
> > > deleted file mode 100644
> > > index bf5e57249c..00
> > > --- 
> > > a/meta/recipes-multimedia/gstreamer/gstreamer1.0/0004-meson-Add-option-for-installed-tests.patch
> > > +++ /dev/null
> > > @@ -1,257 +0,0 @@
> > > -From cf8077a7e3ab0ae236ebde79b7fc0b02eac658de Mon Sep 17 00:00:00 2001
> > > -From: Carlos Rafael Giani 
> > > -Date: Fri, 25 

Re: [OE-core] [PATCH v2 3/3] gstreamer1.0: update ptest patch

[Jose Quaresma]

Khem Raj  escreveu no dia terça, 4/05/2021 à(s) 17:00:
>
> On Mon, May 3, 2021 at 10:09 AM Jose Quaresma  wrote:
> >
> > - rework the ptest patch with a new one that are sent upstream [1].
> > - it uses the same approach as the existing patch in OE-Core but
> >   is based on the glib meson installed-tests [2] logic.
> >
> > * qemux86-64 ptest-runner result
> >   SUMMARY: total=105; passed=105; skipped=0; failed=0; user=20.4s; 
> > system=4.7s; maxrss=9928
> >
> > [1] - 
> > https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/789
> > [2] - 
> > https://gitlab.gnome.org/GNOME/glib/-/commit/1bba3276bb3b7a878860ac01483574599b23853c
> >
> > Signed-off-by: Jose Quaresma 
> > ---
> >  .../gstreamer/gstreamer1.0-ptest.inc  |  23 --
>
> there are gstreamer recipes in other layers ( meta-freescale in my
> case ) which depends on this file
> how do you propose to fix those recipes ?

meta-freescale has a fork of gstreamer os-core with all the patches [1]
and one of them is the installed tests [2] that is removed as well.
Thes installed tests patch on meta-freescale requires the gstreamer1.0-ptest.inc

I think the best solution is add the oe-core gstreamer1.0-ptest.inc on
meta-freescale.
I can submit it if this patch is accepted and merged on oe-core master.

[1] - 
https://git.yoctoproject.org/cgit/cgit.cgi/meta-freescale/tree/recipes-multimedia/gstreamer/gstreamer1.0*
[2] - 
https://git.yoctoproject.org/cgit/cgit.cgi/meta-freescale/tree/recipes-multimedia/gstreamer/gstreamer1.0/0004-meson-Add-option-for-installed-tests.patch

>
> >  ...meson-Add-option-for-installed-tests.patch | 257 --
> >  ...spect-the-idententaion-used-in-meson.patch |  36 +++
> >  ...ts-add-support-for-install-the-tests.patch | 110 
> >  ...s-use-a-dictionaries-for-environment.patch |  48 
> >  ...-the-environment-for-installed_tests.patch |  58 
> >  .../gstreamer/gstreamer1.0/run-ptest  |   2 +
> >  .../gstreamer/gstreamer1.0_1.18.4.bb  |  10 +-
> >  8 files changed, 261 insertions(+), 283 deletions(-)
> >  delete mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0-ptest.inc
> >  delete mode 100644 
> > meta/recipes-multimedia/gstreamer/gstreamer1.0/0004-meson-Add-option-for-installed-tests.patch
> >  create mode 100644 
> > meta/recipes-multimedia/gstreamer/gstreamer1.0/0004-tests-respect-the-idententaion-used-in-meson.patch
> >  create mode 100644 
> > meta/recipes-multimedia/gstreamer/gstreamer1.0/0005-tests-add-support-for-install-the-tests.patch
> >  create mode 100644 
> > meta/recipes-multimedia/gstreamer/gstreamer1.0/0006-tests-use-a-dictionaries-for-environment.patch
> >  create mode 100644 
> > meta/recipes-multimedia/gstreamer/gstreamer1.0/0007-tests-install-the-environment-for-installed_tests.patch
> >  create mode 100755 meta/recipes-multimedia/gstreamer/gstreamer1.0/run-ptest
> >
> > diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-ptest.inc 
> > b/meta/recipes-multimedia/gstreamer/gstreamer1.0-ptest.inc
> > deleted file mode 100644
> > index b698067041..00
> > --- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-ptest.inc
> > +++ /dev/null
> > @@ -1,23 +0,0 @@
> > -inherit ptest-gnome
> > -
> > -TEST_FILES_PATH = "${datadir}/installed-tests/gstreamer-1.0/test-files"
> > -RUN_PTEST_FILE = "${D}${PTEST_PATH}/run-ptest"
> > -
> > -EXTRA_OEMESON += "-Dtest-files-path=${TEST_FILES_PATH}"
> > -
> > -GST_TEST_SUITE_NAME ?= "gstreamer-1.0"
> > -
> > -# Using do_install_ptest_base instead of do_install_ptest, since
> > -# the default do_install_ptest_base is hardcoded to expect Makefiles.
> > -do_install_ptest_base() {
> > -# Generate run-ptest file
> > -echo "#!/usr/bin/env sh" > "${RUN_PTEST_FILE}"
> > -echo "gnome-desktop-testing-runner ${GST_TEST_SUITE_NAME}" >> 
> > "${RUN_PTEST_FILE}"
> > -chmod 0755 "${RUN_PTEST_FILE}"
> > -
> > -# Install additional files required by tests
> > -if [ -d "${S}/tests/files" ] ; then
> > -install -d "${D}/${TEST_FILES_PATH}"
> > -install -m 0644 "${S}/tests/files"/* "${D}/${TEST_FILES_PATH}"
> > -fi
> > -}
> > diff --git 
> > a/meta/recipes-multimedia/gstreamer/gstreamer1.0/0004-meson-Add-option-for-installed-tests.patch
> >  
> > b/meta/recipes-multimedia/gstreamer/gstreamer1.0/0004-meson-Add-option-for-installed-tests.patch
> > deleted file mode 100644
> > index bf5e57249c..00
> > --- 
> > a/meta/recipes-multimedia/gstreamer/gstreamer1.0/0004-meson-Add-option-for-installed-tests.patch
> > +++ /dev/null
> > @@ -1,257 +0,0 @@
> > -From cf8077a7e3ab0ae236ebde79b7fc0b02eac658de Mon Sep 17 00:00:00 2001
> > -From: Carlos Rafael Giani 
> > -Date: Fri, 25 Oct 2019 00:06:26 +0200
> > -Subject: [PATCH 3/3] meson: Add option for installed tests
> > -
> > -This adds an option for producing installed versions of the unit tests.
> > -These versions don't need meson to run (only a small shell script). This
> > -makes it easier to run cross compiled tests on a 

Re: [OE-core] [PATCH 4/7] oeqa/selftest: transition to weston images

[Alexander Kanavin]

On Tue, 4 May 2021 at 19:01, Ross Burton  wrote:

> Hi Alex,
>
> First, I love to see this. :)
>
> However, using this as a convenient starting point: if both nodistro
> and Poky have OpenGL enabled then there's no test cases for the non-GL
> configuration anymore, which is important for headless systems, of
> which there are many.  Whilst I agree that graphical systems that
> don't support modern rendering in some way are on the way out, this
> trend isn't across all of our target platforms.
>
> Can you add a configuration to the autobuilder along the like of
> poky-altconfig that does at least one build without GL?
> core-image-base as a *minimum* but a core-image-sato should continue
> to work.
>

I already have a companion patchset for the autobuilder:
http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-helper/log/?h=contrib/akanavin/transition-to-weston

I don't think it has the non-opengl build yet, but I could easily add that.
Can you take a look at the patches and maybe propose something specific to
add? I can simply add a patch to my set if you write one.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151246): 
https://lists.openembedded.org/g/openembedded-core/message/151246
Mute This Topic: https://lists.openembedded.org/mt/82317824/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 4/7] oeqa/selftest: transition to weston images

[Ross Burton]

Hi Alex,

First, I love to see this. :)

However, using this as a convenient starting point: if both nodistro
and Poky have OpenGL enabled then there's no test cases for the non-GL
configuration anymore, which is important for headless systems, of
which there are many.  Whilst I agree that graphical systems that
don't support modern rendering in some way are on the way out, this
trend isn't across all of our target platforms.

Can you add a configuration to the autobuilder along the like of
poky-altconfig that does at least one build without GL?
core-image-base as a *minimum* but a core-image-sato should continue
to work.

Ross

On Fri, 23 Apr 2021 at 19:03, Alexander Kanavin  wrote:
>
> For readonly rootfs tests core-image-weston
> is appended; everywhere else it replaces core-image-sato.
>
> Signed-off-by: Alexander Kanavin 
> ---
>  meta/lib/oeqa/selftest/cases/_sstatetests_noauto.py |  4 ++--
>  meta/lib/oeqa/selftest/cases/buildoptions.py|  4 ++--
>  meta/lib/oeqa/selftest/cases/imagefeatures.py   |  6 +++---
>  meta/lib/oeqa/selftest/cases/runtime_test.py|  2 --
>  meta/lib/oeqa/selftest/cases/sstatetests.py | 10 +-
>  5 files changed, 12 insertions(+), 14 deletions(-)
>
> diff --git a/meta/lib/oeqa/selftest/cases/_sstatetests_noauto.py 
> b/meta/lib/oeqa/selftest/cases/_sstatetests_noauto.py
> index f7c356ad09..7ac03f0cec 100644
> --- a/meta/lib/oeqa/selftest/cases/_sstatetests_noauto.py
> +++ b/meta/lib/oeqa/selftest/cases/_sstatetests_noauto.py
> @@ -90,7 +90,7 @@ class RebuildFromSState(SStateBase):
>  self.assertFalse(failed_cleansstate, msg="The following recipes have 
> failed cleansstate(all others have passed both cleansstate and rebuild from 
> sstate tests): %s" % ' '.join(map(str, failed_cleansstate)))
>
>  def test_sstate_relocation(self):
> -self.run_test_sstate_rebuild(['core-image-sato-sdk'], relocate=True, 
> rebuild_dependencies=True)
> +self.run_test_sstate_rebuild(['core-image-weston-sdk'], 
> relocate=True, rebuild_dependencies=True)
>
>  def test_sstate_rebuild(self):
> -self.run_test_sstate_rebuild(['core-image-sato-sdk'], 
> relocate=False, rebuild_dependencies=True)
> +self.run_test_sstate_rebuild(['core-image-weston-sdk'], 
> relocate=False, rebuild_dependencies=True)
> diff --git a/meta/lib/oeqa/selftest/cases/buildoptions.py 
> b/meta/lib/oeqa/selftest/cases/buildoptions.py
> index 1859d3222a..754b77defd 100644
> --- a/meta/lib/oeqa/selftest/cases/buildoptions.py
> +++ b/meta/lib/oeqa/selftest/cases/buildoptions.py
> @@ -50,9 +50,9 @@ class ImageOptionsTests(OESelftestTestCase):
>  def test_read_only_image(self):
>  distro_features = get_bb_var('DISTRO_FEATURES')
>  if not ('x11' in distro_features and 'opengl' in distro_features):
> -self.skipTest('core-image-sato requires x11 and opengl in distro 
> features')
> +self.skipTest('core-image-sato/weston requires x11 and opengl in 
> distro features')
>  self.write_config('IMAGE_FEATURES += "read-only-rootfs"')
> -bitbake("core-image-sato")
> +bitbake("core-image-sato core-image-weston")
>  # do_image will fail if there are any pending postinsts
>
>  class DiskMonTest(OESelftestTestCase):
> diff --git a/meta/lib/oeqa/selftest/cases/imagefeatures.py 
> b/meta/lib/oeqa/selftest/cases/imagefeatures.py
> index 6723a8198f..5d4330b48f 100644
> --- a/meta/lib/oeqa/selftest/cases/imagefeatures.py
> +++ b/meta/lib/oeqa/selftest/cases/imagefeatures.py
> @@ -240,8 +240,8 @@ USERADD_GID_TABLES += "files/static-group"
>
>  def test_no_busybox_base_utils(self):
>  config = """
> -# Enable x11
> -DISTRO_FEATURES_append += "x11"
> +# Enable wayland
> +DISTRO_FEATURES_append += "pam opengl wayland"
>
>  # Switch to systemd
>  DISTRO_FEATURES += "systemd"
> @@ -262,7 +262,7 @@ PNBLACKLIST[busybox] = "Don't build this"
>  """
>  self.write_config(config)
>
> -bitbake("--graphviz core-image-sato")
> +bitbake("--graphviz core-image-weston")
>
>  def test_image_gen_debugfs(self):
>  """
> diff --git a/meta/lib/oeqa/selftest/cases/runtime_test.py 
> b/meta/lib/oeqa/selftest/cases/runtime_test.py
> index b20c5b427b..84c2cb77e8 100644
> --- a/meta/lib/oeqa/selftest/cases/runtime_test.py
> +++ b/meta/lib/oeqa/selftest/cases/runtime_test.py
> @@ -128,7 +128,6 @@ class TestImage(OESelftestTestCase):
>  features += 'TEST_SUITES = "ping ssh selftest"\n'
>  self.write_config(features)
>
> -# Build core-image-sato and testimage
>  bitbake('core-image-full-cmdline socat')
>  bitbake('-c testimage core-image-full-cmdline')
>
> @@ -164,7 +163,6 @@ class TestImage(OESelftestTestCase):
>  features += 'PSEUDO_IGNORE_PATHS .= ",%s"\n' % self.gpg_home
>  self.write_config(features)
>
> -# Build core-image-sato and testimage
>  bitbake('core-image-full-cmdline socat')
>  

Re: [OE-core] Development of fwupd recipe

[Ross Burton]

I've prototype recipes for meta-oe but haven't yet sent them out.  I
should be doing this shortly though.

Ross

On Fri, 23 Apr 2021 at 09:52, Norbert Kamiński
 wrote:
>
> Hi all,
>
> We (3mdeb Team) are interested in fwupd recipe development. We saw that
> Ross Burton did some great work on this topic (fixing fwupd
> dependencies), and we would like to know if there is any work in
> progress that we could help with. Currently, we are porting fwupd
> to *BSDs, so if you have any questions or troubles with the fwupd recipe,
> feel free to ask.
>
> Best regards,
>
> Norbert Kamiński
> Embedded Systems Engineer
> http://3mdeb.com | @3mdeb_com
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151244): 
https://lists.openembedded.org/g/openembedded-core/message/151244
Mute This Topic: https://lists.openembedded.org/mt/82306310/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [yocto] Yocto Project Status WW18`21

[Alexander Kanavin]

On Tue, 4 May 2021 at 16:46, Stephen Jolley  wrote:

> We are pleased to announce that our April 2022 release (potentially 3.5)
> will be the next LTS as per our original two year schedule. If there are
> features desired in the next LTS, now is the time to get them submitted and
> stabilized ready.
>

What will happen to the current LTS at that point? Will support be cut off,
will there be a transition window, or is it currently undefined?

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151243): 
https://lists.openembedded.org/g/openembedded-core/message/151243
Mute This Topic: https://lists.openembedded.org/mt/82582269/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH v2 3/3] gstreamer1.0: update ptest patch

[Khem Raj]

On Mon, May 3, 2021 at 10:09 AM Jose Quaresma  wrote:
>
> - rework the ptest patch with a new one that are sent upstream [1].
> - it uses the same approach as the existing patch in OE-Core but
>   is based on the glib meson installed-tests [2] logic.
>
> * qemux86-64 ptest-runner result
>   SUMMARY: total=105; passed=105; skipped=0; failed=0; user=20.4s; 
> system=4.7s; maxrss=9928
>
> [1] - https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/789
> [2] - 
> https://gitlab.gnome.org/GNOME/glib/-/commit/1bba3276bb3b7a878860ac01483574599b23853c
>
> Signed-off-by: Jose Quaresma 
> ---
>  .../gstreamer/gstreamer1.0-ptest.inc  |  23 --

there are gstreamer recipes in other layers ( meta-freescale in my
case ) which depends on this file
how do you propose to fix those recipes ?

>  ...meson-Add-option-for-installed-tests.patch | 257 --
>  ...spect-the-idententaion-used-in-meson.patch |  36 +++
>  ...ts-add-support-for-install-the-tests.patch | 110 
>  ...s-use-a-dictionaries-for-environment.patch |  48 
>  ...-the-environment-for-installed_tests.patch |  58 
>  .../gstreamer/gstreamer1.0/run-ptest  |   2 +
>  .../gstreamer/gstreamer1.0_1.18.4.bb  |  10 +-
>  8 files changed, 261 insertions(+), 283 deletions(-)
>  delete mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0-ptest.inc
>  delete mode 100644 
> meta/recipes-multimedia/gstreamer/gstreamer1.0/0004-meson-Add-option-for-installed-tests.patch
>  create mode 100644 
> meta/recipes-multimedia/gstreamer/gstreamer1.0/0004-tests-respect-the-idententaion-used-in-meson.patch
>  create mode 100644 
> meta/recipes-multimedia/gstreamer/gstreamer1.0/0005-tests-add-support-for-install-the-tests.patch
>  create mode 100644 
> meta/recipes-multimedia/gstreamer/gstreamer1.0/0006-tests-use-a-dictionaries-for-environment.patch
>  create mode 100644 
> meta/recipes-multimedia/gstreamer/gstreamer1.0/0007-tests-install-the-environment-for-installed_tests.patch
>  create mode 100755 meta/recipes-multimedia/gstreamer/gstreamer1.0/run-ptest
>
> diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-ptest.inc 
> b/meta/recipes-multimedia/gstreamer/gstreamer1.0-ptest.inc
> deleted file mode 100644
> index b698067041..00
> --- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-ptest.inc
> +++ /dev/null
> @@ -1,23 +0,0 @@
> -inherit ptest-gnome
> -
> -TEST_FILES_PATH = "${datadir}/installed-tests/gstreamer-1.0/test-files"
> -RUN_PTEST_FILE = "${D}${PTEST_PATH}/run-ptest"
> -
> -EXTRA_OEMESON += "-Dtest-files-path=${TEST_FILES_PATH}"
> -
> -GST_TEST_SUITE_NAME ?= "gstreamer-1.0"
> -
> -# Using do_install_ptest_base instead of do_install_ptest, since
> -# the default do_install_ptest_base is hardcoded to expect Makefiles.
> -do_install_ptest_base() {
> -# Generate run-ptest file
> -echo "#!/usr/bin/env sh" > "${RUN_PTEST_FILE}"
> -echo "gnome-desktop-testing-runner ${GST_TEST_SUITE_NAME}" >> 
> "${RUN_PTEST_FILE}"
> -chmod 0755 "${RUN_PTEST_FILE}"
> -
> -# Install additional files required by tests
> -if [ -d "${S}/tests/files" ] ; then
> -install -d "${D}/${TEST_FILES_PATH}"
> -install -m 0644 "${S}/tests/files"/* "${D}/${TEST_FILES_PATH}"
> -fi
> -}
> diff --git 
> a/meta/recipes-multimedia/gstreamer/gstreamer1.0/0004-meson-Add-option-for-installed-tests.patch
>  
> b/meta/recipes-multimedia/gstreamer/gstreamer1.0/0004-meson-Add-option-for-installed-tests.patch
> deleted file mode 100644
> index bf5e57249c..00
> --- 
> a/meta/recipes-multimedia/gstreamer/gstreamer1.0/0004-meson-Add-option-for-installed-tests.patch
> +++ /dev/null
> @@ -1,257 +0,0 @@
> -From cf8077a7e3ab0ae236ebde79b7fc0b02eac658de Mon Sep 17 00:00:00 2001
> -From: Carlos Rafael Giani 
> -Date: Fri, 25 Oct 2019 00:06:26 +0200
> -Subject: [PATCH 3/3] meson: Add option for installed tests
> -
> -This adds an option for producing installed versions of the unit tests.
> -These versions don't need meson to run (only a small shell script). This
> -makes it easier to run cross compiled tests on a target machine.
> -
> -Upstream-Status: Pending
> -
> -Signed-off-by: Carlos Rafael Giani 
> 
> - build-aux/gen-installed-test-desc.py | 18 ++
> - build-aux/gen-installed-test-shscript.py | 25 
> - meson_options.txt|  2 +
> - tests/check/meson.build  | 46 +-
> - tests/files/testfile | 80 
> - 5 files changed, 170 insertions(+), 1 deletion(-)
> - create mode 100644 build-aux/gen-installed-test-desc.py
> - create mode 100644 build-aux/gen-installed-test-shscript.py
> - create mode 100644 tests/files/testfile
> -
> -diff --git a/build-aux/gen-installed-test-desc.py 
> b/build-aux/gen-installed-test-desc.py
> -new file mode 100644
> -index 0..69e8a0faf
>  /dev/null
> -+++ b/build-aux/gen-installed-test-desc.py
> -@@ -0,0 +1,18 @@
> -+import sys
> -+import os
> -+import 

[OE-core] [PATCH] Revert "perl: fix startperl configuration option for perl-native"

[Richard Purdie]

This reverts commit f2d1523b19cb066a4a06609f036822fe4a8b43f0.

We've reports of a number of failures from this, it causes pod2man to
reference full paths to perl rather than nativeperl from the environment.
I've also seen this issue locally now. Revert until we can find a solution
which works for everyone.

Signed-off-by: Richard Purdie 
---
 meta/recipes-devtools/perl/perl_5.32.1.bb | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-devtools/perl/perl_5.32.1.bb 
b/meta/recipes-devtools/perl/perl_5.32.1.bb
index 73d66f66568..b28040c7fb0 100644
--- a/meta/recipes-devtools/perl/perl_5.32.1.bb
+++ b/meta/recipes-devtools/perl/perl_5.32.1.bb
@@ -95,7 +95,6 @@ do_configure_class-nativesdk() {
 do_configure_class-native() {
 ./configure --prefix=${prefix} \
 -Dbin=${bindir}/perl-native \
--Dperlpath=${bindir}/perl-native/perl \
 -Duseshrplib \
 -Dsoname=libperl.so.5 \
 -Dvendorprefix=${prefix} \
@@ -172,8 +171,8 @@ do_install_append_class-native () {
 create_wrapper ${D}${bindir}/perl-native/perl 
PERL5LIB='$PERL5LIB:${STAGING_LIBDIR}/perl5/site_perl/${PV}:${STAGING_LIBDIR}/perl5/vendor_perl/${PV}:${STAGING_LIBDIR}/perl5/${PV}'
 
 # Use /usr/bin/env nativeperl for the perl script.
-for f in `grep -Il '#! *${bindir}/perl-native.*/perl' ${D}/${bindir}/*`; do
-sed -i -e 's|${bindir}/perl-native.*/perl|/usr/bin/env 
nativeperl|' $f
+for f in `grep -Il '#! *${bindir}/perl' ${D}/${bindir}/*`; do
+sed -i -e 's|${bindir}/perl|/usr/bin/env nativeperl|' $f
 done
 }
 
-- 
2.30.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151241): 
https://lists.openembedded.org/g/openembedded-core/message/151241
Mute This Topic: https://lists.openembedded.org/mt/82579592/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] Yocto Project Status WW18`21

[Stephen Jolley]

Current Dev Position: YP 3.4 M1

Next Deadline: 7th June 2021 YP 3.4 M1 build

 

Next Team Meetings:

*   Bug Triage meeting Thursday May 6th at 7:30am PDT (

https://zoom.us/j/454367603?pwd=ZGxoa2ZXL3FkM3Y0bFd5aVpHVVZ6dz09)
*   Monthly Project Meeting Tuesday May 4th at 8am PDT (

https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09
 )
*   Weekly Engineering Sync Tuesday May 11th at 8am PDT (

https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09
 )
*   Twitch -  See https://www.twitch.tv/theyoctojester

 

Key Status/Updates:

*   YP 3.2.4 is due to build this week which would be the final release
in the 3.2 series.
*   We are pleased to announce that our April 2022 release (potentially
3.5) will be the next LTS as per our original two year schedule. If there
are features desired in the next LTS, now is the time to get them submitted
and stabilized ready.
*   Patches are now flowing into master for 3.4 for M1 which is now
undergoing active development.
*   We upgraded to gcc 11, thanks Khem for a lot of work in getting up
ready to do that!
*   A couple of key fixes for multiconfig builds were added to bitbake.
*   A new uninative version was released to address issues found in
patchelf with some native binaries, particularly when gold was used as a
linker due to differing note section alignment values.
*   Intermittent autobuilder issues continue to occur and are now at a
record high level. You  can see the list of failures we're continuing to see
by searching for the "AB-INT" tag in bugzilla:

https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT

We are working to identify the load pattern on the infrastructure that seems
to trigger these.

 

Ways to contribute:

*   There are bugs identified as possible for newcomers to the project:

https://wiki.yoctoproject.org/wiki/Newcomers
*   There are bugs that are currently unassigned for YP 3.4. See:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_3.4_Unassigned_Enhan
cements.2FBugs
*   We'd welcome new maintainers for recipes in OE-Core. Please see the
list at:

http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/distro/include/main
tainers.inc and discuss with the existing maintainer, or ask on the OE-Core
mailing list. We will likely move a chunk of these to "Unassigned" soon to
help facilitate this.

 

YP 3.4 Milestone Dates:

*   YP 3.4 M1 build date 2021/06/07
*   YP 3.4 M1 Release date 2021/06/18
*   YP 3.4 M2 build date 2021/07/12
*   YP 3.4 M2 Release date 2021/07/23
*   YP 3.4 M3 build date 2021/08/23
*   YP 3.4 M3 Release date 2021/09/03
*   YP 3.4 M4 build date 2021/10/04
*   YP 3.4 M4 Release date 2021/10/29

 

Planned upcoming dot releases:

*   YP 3.2.4 build date 2021/05/3
*   YP 3.2.4 release date 2021/05/14
*   YP 3.3.1 build date 2021/05/17
*   YP 3.3.1 release date 2021/05/28
*   YP 3.1.8 build date 2021/05/24
*   YP 3.1.8 release date 2021/06/04
*   YP 3.1.9 build date 2021/06/21
*   YP 3.1.9 release date 2021/07/02
*   YP 3.3.2 build date 2021/07/19
*   YP 3.3.2 release date 2021/07/30
*   YP 3.1.10 build date 2021/07/26
*   YP 3.1.10 release date 2021/08/06
*   YP 3.1.11 build date 2021/09/13
*   YP 3.1.11 release date 2021/9/24

 

Tracking Metrics:

*   WDD 2659 (last week 2645) (

https://wiki.yoctoproject.org/charts/combo.html)
*   OE-Core/Poky Patch Metrics

*   Total patches found: 1322 (last week 1314)
*   Patches in the Pending State: 499 (38%) [last week 496 (38%)]

 

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

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151240): 

Re: [OE-core] making the meaning of "FILES_${PN}-bin" a little more obvious?

[Richard Purdie]

On Tue, 2021-05-04 at 09:31 -0400, Robert P. J. Day wrote:
>   more nitpickery, but i note in OE's current bitbake.conf the
> initially odd definitions:
> 
>   FILES_${PN} = "${bindir}/* ${sbindir}/* ...'
>  ... snip ...
> 
>   FILES_${PN}-bin = "${bindir}/* ${sbindir}/*"
> 
> i say "odd" since someone perusing that file could be confused, first,
> that that "-bin" package definition overlaps with the base package
> file list and, more, that just above that, the definition of PACKAGES
> doesn't include the "-bin" package:
> 
>   PACKAGES = "${PN}-src ${PN}-dbg ${PN}-staticdev ${PN}-dev \
>   ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN}"
> 
> so anyone currently RTFS is likely to stop and think, "what the heck
> is the '-bin' package defined for if it's not even included in the
> normal package list?"
> 
>   of course, one need to consult lib_package.bbclass to finally
> understand what its purpose is:
> 
>   PACKAGE_BEFORE_PN = "${PN}-bin"
> 
> but if that's the only purpose for that package definition, would it
> not make more sense to just move it to lib_package.bbclass so it's
> next to the variable setting that actually causes it to be processed?
> 
>   of course it works as is, it just seems unnecessarily confusing,
> unless there's some subtle ordering requirement happening here.

I suspect such a change may break as some other recipe may use ${PN}-bin
but not the class. We'd need a careful audit to figure it out...

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151239): 
https://lists.openembedded.org/g/openembedded-core/message/151239
Mute This Topic: https://lists.openembedded.org/mt/82577515/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core][dunfell 00/10] Pull request (cover letter only)

[Steve Sakoman]

The following changes since commit 2cc9e06807026b86038db88c2175c626feadc0be:

  linux-yocto/5.4: fix arm defconfig warnings (2021-04-22 06:23:22 -1000)

are available in the Git repository at:

  git://git.openembedded.org/openembedded-core-contrib stable/dunfell-next
  
http://cgit.openembedded.org/openembedded-core-contrib/log/?h=stable/dunfell-next

Alexander Kanavin (2):
  oeqa: tear down oeqa decorators if one of them raises an exception in
setup
  meta/lib/oeqa/core/tests/cases/timeout.py: add a testcase for the
previous fix

Diego Sueiro (1):
  oeqa/selftest/bblayers: Add test case for bitbake-layers
layerindex-show-depends

Konrad Weihmann (1):
  cve-update-db-native: skip on empty cpe23Uri

Marek Vasut (1):
  linux-firmware: Package RSI 911x WiFi firmware

Reto Schneider (2):
  license_image.bbclass: Detect broken symlinks
  license_image.bbclass: Fix symlink to generic license files

Richard Purdie (1):
  yocto-check-layer: Avoid bug when iterating and autoadding
dependencies

Vinay Kumar (1):
  Binutils: Fix CVE-2021-20197

Zhang Qiang (1):
  kernel.bbclass: Configuration for environment with HOSTCXX

 meta/classes/kernel.bbclass   |   2 +
 meta/classes/license_image.bbclass|  20 +-
 meta/lib/oeqa/core/case.py|   9 +-
 meta/lib/oeqa/core/decorator/oetimeout.py |   5 +-
 meta/lib/oeqa/core/tests/cases/timeout.py |  13 +
 meta/lib/oeqa/core/tests/test_decorators.py   |   6 +
 meta/lib/oeqa/selftest/cases/bblayers.py  |   5 +
 .../recipes-core/meta/cve-update-db-native.bb |   7 +-
 .../binutils/binutils-2.34.inc|   1 +
 .../binutils/binutils/CVE-2021-20197.patch| 572 ++
 .../linux-firmware/linux-firmware_20210208.bb |  11 +
 scripts/yocto-check-layer |   3 +
 12 files changed, 645 insertions(+), 9 deletions(-)
 create mode 100644 meta/recipes-devtools/binutils/binutils/CVE-2021-20197.patch

-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151238): 
https://lists.openembedded.org/g/openembedded-core/message/151238
Mute This Topic: https://lists.openembedded.org/mt/82578450/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] making the meaning of "FILES_${PN}-bin" a little more obvious?

[Robert P. J. Day]

  more nitpickery, but i note in OE's current bitbake.conf the
initially odd definitions:

  FILES_${PN} = "${bindir}/* ${sbindir}/* ...'
 ... snip ...

  FILES_${PN}-bin = "${bindir}/* ${sbindir}/*"

i say "odd" since someone perusing that file could be confused, first,
that that "-bin" package definition overlaps with the base package
file list and, more, that just above that, the definition of PACKAGES
doesn't include the "-bin" package:

  PACKAGES = "${PN}-src ${PN}-dbg ${PN}-staticdev ${PN}-dev \
  ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN}"

so anyone currently RTFS is likely to stop and think, "what the heck
is the '-bin' package defined for if it's not even included in the
normal package list?"

  of course, one need to consult lib_package.bbclass to finally
understand what its purpose is:

  PACKAGE_BEFORE_PN = "${PN}-bin"

but if that's the only purpose for that package definition, would it
not make more sense to just move it to lib_package.bbclass so it's
next to the variable setting that actually causes it to be processed?

  of course it works as is, it just seems unnecessarily confusing,
unless there's some subtle ordering requirement happening here.

rday

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151237): 
https://lists.openembedded.org/g/openembedded-core/message/151237
Mute This Topic: https://lists.openembedded.org/mt/82577515/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] oe-buildenv-internal: add BitBake's library to PYTHONPATH

[Ross Burton]

There are many Python scripts in oe-core that want to use Tinfoil, and
right now they have to know where they are to work out where BitBake is
likely to be.

This is suboptimal as BitBake could be somewhere else, so this
approach doesn't scale to other layers at all.

Solve this by adding BITBAKEDIR/lib to PYTHONPATH in oe-buildenv-internal,
so that Python has BitBake on its search path once the build system is
configured.

Signed-off-by: Ross Burton 
---
 scripts/oe-buildenv-internal | 4 
 1 file changed, 4 insertions(+)

diff --git a/scripts/oe-buildenv-internal b/scripts/oe-buildenv-internal
index ba0a9b44d6f..e0d920f2fc2 100755
--- a/scripts/oe-buildenv-internal
+++ b/scripts/oe-buildenv-internal
@@ -88,6 +88,10 @@ if [ ! -d "$BITBAKEDIR" ]; then
 return 1
 fi
 
+# Add BitBake's library to PYTHONPATH
+PYTHONPATH=$BITBAKEDIR/lib:$PYTHONPATH
+export PYTHONPATH
+
 # Make sure our paths are at the beginning of $PATH
 for newpath in "$BITBAKEDIR/bin" "$OEROOT/scripts"; do
 # Remove any existences of $newpath from $PATH
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151236): 
https://lists.openembedded.org/g/openembedded-core/message/151236
Mute This Topic: https://lists.openembedded.org/mt/82576778/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH v2] ccache: add packageconfig docs option

[Bastian Krause]

Before, ccache's configure stage built HTML documentation and man pages
depending on if asciidoc is installed. This patch makes it configurable.

Pass the new cmake option BUILD_DOCS along and add the asciidoc
dependency if necessary.

This fixes an issue when ccache's configure stage found asciidoc/a2x on
the system outside of the sysroot (e.g. installed via 'apt install
asciidoc'). ccache would then decide to build docs and manual pages, but
would fail during compilation: the system's a2x could not find the
system's asciidoc because it did not reside in the set PATH.

By enabling/disabling docs/man page generation explicitly and adding
asciidoc to DEPENDS as necessary, this is no longer an issue.

Signed-off-by: Bastian Krause 
---
Changes since (implicit) v1:
- fixed patch's "Upstream-Status" ("Submitted" instead of "Pending"),
  thanks to Konrad Weihmann 
---
 ...w-disabling-docs-man-page-generation.patch | 161 ++
 meta/recipes-devtools/ccache/ccache_4.2.1.bb  |   6 +-
 2 files changed, 166 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-devtools/ccache/ccache/0001-doc-allow-disabling-docs-man-page-generation.patch

diff --git 
a/meta/recipes-devtools/ccache/ccache/0001-doc-allow-disabling-docs-man-page-generation.patch
 
b/meta/recipes-devtools/ccache/ccache/0001-doc-allow-disabling-docs-man-page-generation.patch
new file mode 100644
index 00..51ca0e82f6
--- /dev/null
+++ 
b/meta/recipes-devtools/ccache/ccache/0001-doc-allow-disabling-docs-man-page-generation.patch
@@ -0,0 +1,161 @@
+From aebabafe085dd1b84027a1e31e5566c82528bd62 Mon Sep 17 00:00:00 2001
+From: Bastian Krause 
+Date: Tue, 4 May 2021 11:41:56 +0200
+Subject: [PATCH] doc: allow disabling docs/man page generation
+
+The assumption that HTML documentation and manual pages should be
+generated if the required tools (asciidoc) are present is not always
+true. So add a cmake option that allows disabling the docs/man page
+generation. The default is to generate docs/man pages like before.
+
+Origin: https://github.com/ccache/ccache/pull/844
+Upstream-Status: Submitted
+Signed-off-by: Bastian Krause 
+---
+ doc/CMakeLists.txt | 128 +++--
+ 1 file changed, 66 insertions(+), 62 deletions(-)
+
+diff --git a/doc/CMakeLists.txt b/doc/CMakeLists.txt
+index c5ce224d..74b7831b 100644
+--- a/doc/CMakeLists.txt
 b/doc/CMakeLists.txt
+@@ -1,70 +1,74 @@
++option(BUILD_DOCS "Indicates whether HTML documentation and manual pages 
should be built or not" ON)
++
+ find_program(ASCIIDOC_EXE asciidoc)
+ mark_as_advanced(ASCIIDOC_EXE) # Don't show in CMake UIs
+ 
+-if(NOT ASCIIDOC_EXE)
+-  message(WARNING "Could not find asciidoc; documentation will not be 
generated")
+-else()
+-  #
+-  # HTML documentation
+-  #
+-  function(generate_html adoc_file)
+-get_filename_component(base_name "${adoc_file}" NAME_WE)
+-set(html_file "${base_name}.html")
+-add_custom_command(
+-  OUTPUT "${html_file}"
+-  COMMAND
+-${ASCIIDOC_EXE}
+-  -o "${html_file}"
+-  -a revnumber="${CCACHE_VERSION}"
+-  -a toc
+-  -b xhtml11
+-  "${CMAKE_SOURCE_DIR}/${adoc_file}"
+-  MAIN_DEPENDENCY "${CMAKE_SOURCE_DIR}/${adoc_file}"
+-)
+-set(html_files "${html_files}" "${html_file}" PARENT_SCOPE)
+-  endfunction()
++if (BUILD_DOCS)
++  if(NOT ASCIIDOC_EXE)
++message(WARNING "Could not find asciidoc; documentation will not be 
generated")
++  else()
++#
++# HTML documentation
++#
++function(generate_html adoc_file)
++  get_filename_component(base_name "${adoc_file}" NAME_WE)
++  set(html_file "${base_name}.html")
++  add_custom_command(
++OUTPUT "${html_file}"
++COMMAND
++  ${ASCIIDOC_EXE}
++-o "${html_file}"
++-a revnumber="${CCACHE_VERSION}"
++-a toc
++-b xhtml11
++"${CMAKE_SOURCE_DIR}/${adoc_file}"
++MAIN_DEPENDENCY "${CMAKE_SOURCE_DIR}/${adoc_file}"
++  )
++  set(html_files "${html_files}" "${html_file}" PARENT_SCOPE)
++endfunction()
+ 
+-  generate_html(LICENSE.adoc)
+-  generate_html(doc/AUTHORS.adoc)
+-  generate_html(doc/MANUAL.adoc)
+-  generate_html(doc/NEWS.adoc)
++generate_html(LICENSE.adoc)
++generate_html(doc/AUTHORS.adoc)
++generate_html(doc/MANUAL.adoc)
++generate_html(doc/NEWS.adoc)
+ 
+-  add_custom_target(doc-html DEPENDS "${html_files}")
+-  set(doc_files "${html_files}")
++add_custom_target(doc-html DEPENDS "${html_files}")
++set(doc_files "${html_files}")
+ 
+-  #
+-  # Man page
+-  #
+-  find_program(A2X_EXE a2x)
+-  mark_as_advanced(A2X_EXE) # Don't show in CMake UIs
+-  if(NOT A2X_EXE)
+-message(WARNING "Could not find a2x; man page will not be generated")
+-  else()
+-# MANUAL.adoc -> MANUAL.xml -> man page
+-add_custom_command(
+-  OUTPUT MANUAL.xml
+-  COMMAND
+-${ASCIIDOC_EXE}
+-  -o -
+-  -a 

Re: [OE-core] [PATCH] ccache: add packageconfig docs option

[Bastian Krause]

On 5/4/21 1:24 PM, Konrad Weihmann wrote:
> 
> 
> On 04.05.21 13:20, Bastian Krause wrote:
>> Before, ccache's configure stage built HTML documentation and man pages
>> depending on if asciidoc is installed. This patch makes it configurable.
>>
>> Pass the new cmake option BUILD_DOCS along and add the asciidoc
>> dependency if necessary.
>>
>> This fixes an issue when ccache's configure stage found asciidoc/a2x on
>> the system outside of the sysroot (e.g. installed via 'apt install
>> asciidoc'). ccache would then decide to build docs and manual pages, but
>> would fail during compilation: the system's a2x could not find the
>> system's asciidoc because it did not reside in the set PATH.
>>
>> By enabling/disabling docs/man page generation explicitly and adding
>> asciidoc to DEPENDS as necessary, this is no longer an issue.
>>
>> Signed-off-by: Bastian Krause 
>> ---
>>   ...w-disabling-docs-man-page-generation.patch | 161 ++
>>   meta/recipes-devtools/ccache/ccache_4.2.1.bb  |   6 +-
>>   2 files changed, 166 insertions(+), 1 deletion(-)
>>   create mode 100644
>> meta/recipes-devtools/ccache/ccache/0001-doc-allow-disabling-docs-man-page-generation.patch
>>
>>
>> diff --git
>> a/meta/recipes-devtools/ccache/ccache/0001-doc-allow-disabling-docs-man-page-generation.patch
>> b/meta/recipes-devtools/ccache/ccache/0001-doc-allow-disabling-docs-man-page-generation.patch
>>
>> new file mode 100644
>> index 00..11176e3039
>> --- /dev/null
>> +++
>> b/meta/recipes-devtools/ccache/ccache/0001-doc-allow-disabling-docs-man-page-generation.patch
>>
>> @@ -0,0 +1,161 @@
>> +From e87d882e8c31e4c6b90e770643c0d176c2455a01 Mon Sep 17 00:00:00 2001
>> +From: Bastian Krause 
>> +Date: Tue, 4 May 2021 11:41:56 +0200
>> +Subject: [PATCH] doc: allow disabling docs/man page generation
>> +
>> +The assumption that HTML documentation and manual pages should be
>> +generated if the required tools (asciidoc) are present is not always
>> +true. So add a cmake option that allows disabling the docs/man page
>> +generation. The default is to generate docs/man pages like before.
>> +
>> +Origin: https://github.com/ccache/ccache/pull/844
>> +Upstream-Status: Pending
> 
> Just some nitpick, but shouldn't that be Submitted instead - as I see a
> PR open for this feature at the mentioned upstream repo
> 
> (see https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines)

You're right. Thanks for pointing that out. I'll fix this in a v2.

Regards,
Bastian

> 
>> +Signed-off-by: Bastian Krause 
>> +---
>> + doc/CMakeLists.txt | 128 +++--
>> + 1 file changed, 66 insertions(+), 62 deletions(-)
>> +
>> +diff --git a/doc/CMakeLists.txt b/doc/CMakeLists.txt
>> +index c5ce224d..74b7831b 100644
>> +--- a/doc/CMakeLists.txt
>>  b/doc/CMakeLists.txt
>> +@@ -1,70 +1,74 @@
>> ++option(BUILD_DOCS "Indicates whether HTML documentation and manual
>> pages should be built or not" ON)
>> ++
>> + find_program(ASCIIDOC_EXE asciidoc)
>> + mark_as_advanced(ASCIIDOC_EXE) # Don't show in CMake UIs
>> +
>> +-if(NOT ASCIIDOC_EXE)
>> +-  message(WARNING "Could not find asciidoc; documentation will not
>> be generated")
>> +-else()
>> +-  #
>> +-  # HTML documentation
>> +-  #
>> +-  function(generate_html adoc_file)
>> +-    get_filename_component(base_name "${adoc_file}" NAME_WE)
>> +-    set(html_file "${base_name}.html")
>> +-    add_custom_command(
>> +-  OUTPUT "${html_file}"
>> +-  COMMAND
>> +-    ${ASCIIDOC_EXE}
>> +-  -o "${html_file}"
>> +-  -a revnumber="${CCACHE_VERSION}"
>> +-  -a toc
>> +-  -b xhtml11
>> +-  "${CMAKE_SOURCE_DIR}/${adoc_file}"
>> +-  MAIN_DEPENDENCY "${CMAKE_SOURCE_DIR}/${adoc_file}"
>> +-    )
>> +-    set(html_files "${html_files}" "${html_file}" PARENT_SCOPE)
>> +-  endfunction()
>> ++if (BUILD_DOCS)
>> ++  if(NOT ASCIIDOC_EXE)
>> ++    message(WARNING "Could not find asciidoc; documentation will not
>> be generated")
>> ++  else()
>> ++    #
>> ++    # HTML documentation
>> ++    #
>> ++    function(generate_html adoc_file)
>> ++  get_filename_component(base_name "${adoc_file}" NAME_WE)
>> ++  set(html_file "${base_name}.html")
>> ++  add_custom_command(
>> ++    OUTPUT "${html_file}"
>> ++    COMMAND
>> ++  ${ASCIIDOC_EXE}
>> ++    -o "${html_file}"
>> ++    -a revnumber="${CCACHE_VERSION}"
>> ++    -a toc
>> ++    -b xhtml11
>> ++    "${CMAKE_SOURCE_DIR}/${adoc_file}"
>> ++    MAIN_DEPENDENCY "${CMAKE_SOURCE_DIR}/${adoc_file}"
>> ++  )
>> ++  set(html_files "${html_files}" "${html_file}" PARENT_SCOPE)
>> ++    endfunction()
>> +
>> +-  generate_html(LICENSE.adoc)
>> +-  generate_html(doc/AUTHORS.adoc)
>> +-  generate_html(doc/MANUAL.adoc)
>> +-  generate_html(doc/NEWS.adoc)
>> ++    generate_html(LICENSE.adoc)
>> ++    generate_html(doc/AUTHORS.adoc)
>> ++    generate_html(doc/MANUAL.adoc)
>> ++    

Re: [OE-core] [PATCH] ccache: add packageconfig docs option

[Konrad Weihmann]

On 04.05.21 13:20, Bastian Krause wrote:

Before, ccache's configure stage built HTML documentation and man pages
depending on if asciidoc is installed. This patch makes it configurable.

Pass the new cmake option BUILD_DOCS along and add the asciidoc
dependency if necessary.

This fixes an issue when ccache's configure stage found asciidoc/a2x on
the system outside of the sysroot (e.g. installed via 'apt install
asciidoc'). ccache would then decide to build docs and manual pages, but
would fail during compilation: the system's a2x could not find the
system's asciidoc because it did not reside in the set PATH.

By enabling/disabling docs/man page generation explicitly and adding
asciidoc to DEPENDS as necessary, this is no longer an issue.

Signed-off-by: Bastian Krause 
---
  ...w-disabling-docs-man-page-generation.patch | 161 ++
  meta/recipes-devtools/ccache/ccache_4.2.1.bb  |   6 +-
  2 files changed, 166 insertions(+), 1 deletion(-)
  create mode 100644 
meta/recipes-devtools/ccache/ccache/0001-doc-allow-disabling-docs-man-page-generation.patch

diff --git 
a/meta/recipes-devtools/ccache/ccache/0001-doc-allow-disabling-docs-man-page-generation.patch
 
b/meta/recipes-devtools/ccache/ccache/0001-doc-allow-disabling-docs-man-page-generation.patch
new file mode 100644
index 00..11176e3039
--- /dev/null
+++ 
b/meta/recipes-devtools/ccache/ccache/0001-doc-allow-disabling-docs-man-page-generation.patch
@@ -0,0 +1,161 @@
+From e87d882e8c31e4c6b90e770643c0d176c2455a01 Mon Sep 17 00:00:00 2001
+From: Bastian Krause 
+Date: Tue, 4 May 2021 11:41:56 +0200
+Subject: [PATCH] doc: allow disabling docs/man page generation
+
+The assumption that HTML documentation and manual pages should be
+generated if the required tools (asciidoc) are present is not always
+true. So add a cmake option that allows disabling the docs/man page
+generation. The default is to generate docs/man pages like before.
+
+Origin: https://github.com/ccache/ccache/pull/844
+Upstream-Status: Pending


Just some nitpick, but shouldn't that be Submitted instead - as I see a 
PR open for this feature at the mentioned upstream repo


(see https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines)


+Signed-off-by: Bastian Krause 
+---
+ doc/CMakeLists.txt | 128 +++--
+ 1 file changed, 66 insertions(+), 62 deletions(-)
+
+diff --git a/doc/CMakeLists.txt b/doc/CMakeLists.txt
+index c5ce224d..74b7831b 100644
+--- a/doc/CMakeLists.txt
 b/doc/CMakeLists.txt
+@@ -1,70 +1,74 @@
++option(BUILD_DOCS "Indicates whether HTML documentation and manual pages should be 
built or not" ON)
++
+ find_program(ASCIIDOC_EXE asciidoc)
+ mark_as_advanced(ASCIIDOC_EXE) # Don't show in CMake UIs
+
+-if(NOT ASCIIDOC_EXE)
+-  message(WARNING "Could not find asciidoc; documentation will not be 
generated")
+-else()
+-  #
+-  # HTML documentation
+-  #
+-  function(generate_html adoc_file)
+-get_filename_component(base_name "${adoc_file}" NAME_WE)
+-set(html_file "${base_name}.html")
+-add_custom_command(
+-  OUTPUT "${html_file}"
+-  COMMAND
+-${ASCIIDOC_EXE}
+-  -o "${html_file}"
+-  -a revnumber="${CCACHE_VERSION}"
+-  -a toc
+-  -b xhtml11
+-  "${CMAKE_SOURCE_DIR}/${adoc_file}"
+-  MAIN_DEPENDENCY "${CMAKE_SOURCE_DIR}/${adoc_file}"
+-)
+-set(html_files "${html_files}" "${html_file}" PARENT_SCOPE)
+-  endfunction()
++if (BUILD_DOCS)
++  if(NOT ASCIIDOC_EXE)
++message(WARNING "Could not find asciidoc; documentation will not be 
generated")
++  else()
++#
++# HTML documentation
++#
++function(generate_html adoc_file)
++  get_filename_component(base_name "${adoc_file}" NAME_WE)
++  set(html_file "${base_name}.html")
++  add_custom_command(
++OUTPUT "${html_file}"
++COMMAND
++  ${ASCIIDOC_EXE}
++-o "${html_file}"
++-a revnumber="${CCACHE_VERSION}"
++-a toc
++-b xhtml11
++"${CMAKE_SOURCE_DIR}/${adoc_file}"
++MAIN_DEPENDENCY "${CMAKE_SOURCE_DIR}/${adoc_file}"
++  )
++  set(html_files "${html_files}" "${html_file}" PARENT_SCOPE)
++endfunction()
+
+-  generate_html(LICENSE.adoc)
+-  generate_html(doc/AUTHORS.adoc)
+-  generate_html(doc/MANUAL.adoc)
+-  generate_html(doc/NEWS.adoc)
++generate_html(LICENSE.adoc)
++generate_html(doc/AUTHORS.adoc)
++generate_html(doc/MANUAL.adoc)
++generate_html(doc/NEWS.adoc)
+
+-  add_custom_target(doc-html DEPENDS "${html_files}")
+-  set(doc_files "${html_files}")
++add_custom_target(doc-html DEPENDS "${html_files}")
++set(doc_files "${html_files}")
+
+-  #
+-  # Man page
+-  #
+-  find_program(A2X_EXE a2x)
+-  mark_as_advanced(A2X_EXE) # Don't show in CMake UIs
+-  if(NOT A2X_EXE)
+-message(WARNING "Could not find a2x; man page will not be generated")
+-  else()
+-# MANUAL.adoc -> MANUAL.xml -> man page
+-

[OE-core] [PATCH] ccache: add packageconfig docs option

[Bastian Krause]

Before, ccache's configure stage built HTML documentation and man pages
depending on if asciidoc is installed. This patch makes it configurable.

Pass the new cmake option BUILD_DOCS along and add the asciidoc
dependency if necessary.

This fixes an issue when ccache's configure stage found asciidoc/a2x on
the system outside of the sysroot (e.g. installed via 'apt install
asciidoc'). ccache would then decide to build docs and manual pages, but
would fail during compilation: the system's a2x could not find the
system's asciidoc because it did not reside in the set PATH.

By enabling/disabling docs/man page generation explicitly and adding
asciidoc to DEPENDS as necessary, this is no longer an issue.

Signed-off-by: Bastian Krause 
---
 ...w-disabling-docs-man-page-generation.patch | 161 ++
 meta/recipes-devtools/ccache/ccache_4.2.1.bb  |   6 +-
 2 files changed, 166 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-devtools/ccache/ccache/0001-doc-allow-disabling-docs-man-page-generation.patch

diff --git 
a/meta/recipes-devtools/ccache/ccache/0001-doc-allow-disabling-docs-man-page-generation.patch
 
b/meta/recipes-devtools/ccache/ccache/0001-doc-allow-disabling-docs-man-page-generation.patch
new file mode 100644
index 00..11176e3039
--- /dev/null
+++ 
b/meta/recipes-devtools/ccache/ccache/0001-doc-allow-disabling-docs-man-page-generation.patch
@@ -0,0 +1,161 @@
+From e87d882e8c31e4c6b90e770643c0d176c2455a01 Mon Sep 17 00:00:00 2001
+From: Bastian Krause 
+Date: Tue, 4 May 2021 11:41:56 +0200
+Subject: [PATCH] doc: allow disabling docs/man page generation
+
+The assumption that HTML documentation and manual pages should be
+generated if the required tools (asciidoc) are present is not always
+true. So add a cmake option that allows disabling the docs/man page
+generation. The default is to generate docs/man pages like before.
+
+Origin: https://github.com/ccache/ccache/pull/844
+Upstream-Status: Pending
+Signed-off-by: Bastian Krause 
+---
+ doc/CMakeLists.txt | 128 +++--
+ 1 file changed, 66 insertions(+), 62 deletions(-)
+
+diff --git a/doc/CMakeLists.txt b/doc/CMakeLists.txt
+index c5ce224d..74b7831b 100644
+--- a/doc/CMakeLists.txt
 b/doc/CMakeLists.txt
+@@ -1,70 +1,74 @@
++option(BUILD_DOCS "Indicates whether HTML documentation and manual pages 
should be built or not" ON)
++
+ find_program(ASCIIDOC_EXE asciidoc)
+ mark_as_advanced(ASCIIDOC_EXE) # Don't show in CMake UIs
+ 
+-if(NOT ASCIIDOC_EXE)
+-  message(WARNING "Could not find asciidoc; documentation will not be 
generated")
+-else()
+-  #
+-  # HTML documentation
+-  #
+-  function(generate_html adoc_file)
+-get_filename_component(base_name "${adoc_file}" NAME_WE)
+-set(html_file "${base_name}.html")
+-add_custom_command(
+-  OUTPUT "${html_file}"
+-  COMMAND
+-${ASCIIDOC_EXE}
+-  -o "${html_file}"
+-  -a revnumber="${CCACHE_VERSION}"
+-  -a toc
+-  -b xhtml11
+-  "${CMAKE_SOURCE_DIR}/${adoc_file}"
+-  MAIN_DEPENDENCY "${CMAKE_SOURCE_DIR}/${adoc_file}"
+-)
+-set(html_files "${html_files}" "${html_file}" PARENT_SCOPE)
+-  endfunction()
++if (BUILD_DOCS)
++  if(NOT ASCIIDOC_EXE)
++message(WARNING "Could not find asciidoc; documentation will not be 
generated")
++  else()
++#
++# HTML documentation
++#
++function(generate_html adoc_file)
++  get_filename_component(base_name "${adoc_file}" NAME_WE)
++  set(html_file "${base_name}.html")
++  add_custom_command(
++OUTPUT "${html_file}"
++COMMAND
++  ${ASCIIDOC_EXE}
++-o "${html_file}"
++-a revnumber="${CCACHE_VERSION}"
++-a toc
++-b xhtml11
++"${CMAKE_SOURCE_DIR}/${adoc_file}"
++MAIN_DEPENDENCY "${CMAKE_SOURCE_DIR}/${adoc_file}"
++  )
++  set(html_files "${html_files}" "${html_file}" PARENT_SCOPE)
++endfunction()
+ 
+-  generate_html(LICENSE.adoc)
+-  generate_html(doc/AUTHORS.adoc)
+-  generate_html(doc/MANUAL.adoc)
+-  generate_html(doc/NEWS.adoc)
++generate_html(LICENSE.adoc)
++generate_html(doc/AUTHORS.adoc)
++generate_html(doc/MANUAL.adoc)
++generate_html(doc/NEWS.adoc)
+ 
+-  add_custom_target(doc-html DEPENDS "${html_files}")
+-  set(doc_files "${html_files}")
++add_custom_target(doc-html DEPENDS "${html_files}")
++set(doc_files "${html_files}")
+ 
+-  #
+-  # Man page
+-  #
+-  find_program(A2X_EXE a2x)
+-  mark_as_advanced(A2X_EXE) # Don't show in CMake UIs
+-  if(NOT A2X_EXE)
+-message(WARNING "Could not find a2x; man page will not be generated")
+-  else()
+-# MANUAL.adoc -> MANUAL.xml -> man page
+-add_custom_command(
+-  OUTPUT MANUAL.xml
+-  COMMAND
+-${ASCIIDOC_EXE}
+-  -o -
+-  -a revnumber=${CCACHE_VERSION}
+-  -d manpage
+-  -b docbook "${CMAKE_SOURCE_DIR}/doc/MANUAL.adoc"
+-| perl -pe 's!\(.*?\)!\\1!g'

[OE-core] [PATCH] kernel-fitimage.bbclass: fix a wrong conditional check

[Ming Liu]

From: Ming Liu 

It should check if "${UBOOT_SIGN_ENABLE}" equals to "1" instead of
checking if "${UBOOT_SIGN_ENABLE}" is not empty since it could be "0".

Signed-off-by: Ming Liu 
---
 meta/classes/kernel-fitimage.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/kernel-fitimage.bbclass 
b/meta/classes/kernel-fitimage.bbclass
index 5cfd8af99d..993e159c75 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -331,7 +331,7 @@ fitimage_emit_section_config() {
 
conf_csum="${FIT_HASH_ALG}"
conf_sign_algo="${FIT_SIGN_ALG}"
-   if [ -n "${UBOOT_SIGN_ENABLE}" ] ; then
+   if [ "${UBOOT_SIGN_ENABLE}" = "1" ] ; then
conf_sign_keyname="${UBOOT_SIGN_KEYNAME}"
fi
 
-- 
2.29.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151231): 
https://lists.openembedded.org/g/openembedded-core/message/151231
Mute This Topic: https://lists.openembedded.org/mt/82574447/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] how to add a "-dev" package to host SDK?

[Robert P. J. Day]

On Mon, 3 May 2021, Denys Dmytriyenko wrote:

... snip ...

> By default, ${PN}-dev RDEPENDS on ${PN} automatically, if not changed:
>
> https://git.openembedded.org/openembedded-core/tree/meta/conf/bitbake.conf#n321

  yup, that's the line i was looking for, thanks.

rday

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151230): 
https://lists.openembedded.org/g/openembedded-core/message/151230
Mute This Topic: https://lists.openembedded.org/mt/82553343/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-