Date   

Re: QA notification for completed autobuilder build (yocto-3.3.rc2)

Sangeeta Jain
 

Hello All,

This is the full report for yocto-3.3.rc2:
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults

======= Summary ========
No high milestone defects.

No new issue found.


Thanks,
Sangeeta

-----Original Message-----
From: yocto@... <yocto@...> On Behalf
Of Pokybuild User
Sent: Wednesday, 7 April, 2021 8:16 PM
To: yocto@...
Cc: qa-build-notification@...
Subject: [yocto] QA notification for completed autobuilder build (yocto-3.3.rc2)


A build flagged for QA (yocto-3.3.rc2) was completed on the autobuilder and is
available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.3.rc2


Build hash information:

bitbake: a1848a481e36b729c8e4130c394b1d462d4b488a
meta-arm: 219fd34b7676ffedd1a1ad3626ec4337391975f4
meta-gplv2: 9e119f333cc8f53bd3cf64326f826dbc6ce3db0f
meta-intel: 01cfc99a8f960917433a8a46b41bb4febb5b1993
meta-kernel: 29329d7cacc71595cecfdd05a455a0cfb164564d
meta-mingw: 422b96cb2b6116442be1f40dfb5bd77447d1219e
oecore: 14241ed09f9ed317045cf75a6d08416d3579bb8d
poky: e1839b58ebe05242a52fe050aa9a08140136aa0a



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@...



Re: [meta-cgl][PATCH] pacemaker: upgrade 2.0.3 -> 2.0.5

Jeremy Puhlman
 

I haven't been doing much with it lately and this got lost in my pile. Its merged to master.


On Mon, Apr 12, 2021 at 7:29 PM Randy MacLeod <randy.macleod@...> wrote:
On 2021-03-05 1:28 a.m., Changqing Li wrote:
> ping

Is this layer alive? :)

../Randy
>
> On 12/9/20 2:01 PM, Yi Zhao wrote:
>> Drop backported patches:
>> 0001-Mark-declaration-with-extern.patch
>> 0006-Fix-tools-Fix-definition-of-curses_indented_printf.patch
>>
>> Rebase patches:
>> 0001-Fix-python3-usage.patch
>> 0001-pacemaker-fix-compile-error-of-musl-libc.patch
>>
>> Remove /var/log directory in do_install and create /var/log/pacemaker
>> directory in volatile file.
>>
>> Signed-off-by: Yi Zhao<yi.zhao@...>
>> ---
>>   .../recipes-cgl/pacemaker/files/tmpfiles      |  3 +-
>>   .../recipes-cgl/pacemaker/files/volatiles     |  1 +
>>   .../pacemaker/0001-Fix-python3-usage.patch    | 34 ++++----------
>>   .../0001-Mark-declaration-with-extern.patch   | 46 -------------------
>>   ...maker-fix-compile-error-of-musl-libc.patch | 39 +++-------------
>>   ...definition-of-curses_indented_printf.patch | 30 ------------
>>   ...{pacemaker_2.0.3.bb => pacemaker_2.0.5.bb} |  5 +-
>>   7 files changed, 21 insertions(+), 137 deletions(-)
>>   mode change 100755 => 100644 meta-cgl-common/recipes-cgl/pacemaker/files/tmpfiles
>>   mode change 100755 => 100644 meta-cgl-common/recipes-cgl/pacemaker/files/volatiles
>>   delete mode 100644 meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-Mark-declaration-with-extern.patch
>>   delete mode 100644 meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0006-Fix-tools-Fix-definition-of-curses_indented_printf.patch
>>   rename meta-cgl-common/recipes-cgl/pacemaker/{pacemaker_2.0.3.bb => pacemaker_2.0.5.bb} (96%)
>>
>> diff --git a/meta-cgl-common/recipes-cgl/pacemaker/files/tmpfiles b/meta-cgl-common/recipes-cgl/pacemaker/files/tmpfiles
>> old mode 100755
>> new mode 100644
>> index 979db47..765ee0d
>> --- a/meta-cgl-common/recipes-cgl/pacemaker/files/tmpfiles
>> +++ b/meta-cgl-common/recipes-cgl/pacemaker/files/tmpfiles
>> @@ -3,4 +3,5 @@ d /var/lib/pacemaker/cib 0750 hacluster haclient -
>>   d /var/lib/pacemaker/cores 0750 hacluster haclient -
>>   d /var/lib/pacemaker/pengine 0750 hacluster haclient -
>>   d /var/lib/pacemaker/blackbox 0750 hacluster haclient -
>> -d /var/run/crm 0750 hacluster haclient -
>> +d /run/crm 0750 hacluster haclient -
>> +d /var/log/pacemaker 0750 hacluster haclient -
>> diff --git a/meta-cgl-common/recipes-cgl/pacemaker/files/volatiles b/meta-cgl-common/recipes-cgl/pacemaker/files/volatiles
>> old mode 100755
>> new mode 100644
>> index 1700a69..eca3002
>> --- a/meta-cgl-common/recipes-cgl/pacemaker/files/volatiles
>> +++ b/meta-cgl-common/recipes-cgl/pacemaker/files/volatiles
>> @@ -4,3 +4,4 @@ d hacluster haclient 0750 /var/lib/pacemaker/cores none
>>   d hacluster haclient 0750 /var/lib/pacemaker/pengine none
>>   d hacluster haclient 0750 /var/lib/pacemaker/blackbox none
>>   d hacluster haclient 0750 /var/run/crm none
>> +d hacluster haclient 0750 /var/log/pacemaker none
>> diff --git a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-Fix-python3-usage.patch b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-Fix-python3-usage.patch
>> index 05d7a76..2095227 100644
>> --- a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-Fix-python3-usage.patch
>> +++ b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-Fix-python3-usage.patch
>> @@ -1,4 +1,4 @@
>> -From fdefa9efc726fe704238d462a3dc207e0282fb9e Mon Sep 17 00:00:00 2001
>> +From f470884e0b990676685c8740b5c7d6f094267e4f Mon Sep 17 00:00:00 2001
>>   From: Jeremy Puhlman<jpuhlman@...>
>>   Date: Sun, 15 Mar 2020 21:09:33 +0000
>>   Subject: [PATCH] Fix python3 usage
>> @@ -18,12 +18,11 @@ Upstream-Status: Pending
>>    cts/pacemaker-cts-dummyd.in                   | 2 +-
>>    daemons/fenced/fence_legacy.in                | 2 +-
>>    doc/Pacemaker_Development/en-US/Ch-Python.txt | 2 +-
>> - doc/Pacemaker_Development/pot/Ch-Python.pot   | 2 +-
>>    tools/pcmk_simtimes.in                        | 2 +-
>> - 14 files changed, 14 insertions(+), 14 deletions(-)
>> + 13 files changed, 13 insertions(+), 13 deletions(-)
>>   
>>   diff --git a/cts/CTSlab.py.in b/cts/CTSlab.py.in
>> -index f4ae60dc1..55a0d4ecf 100644
>> +index 4bae93515..f09f71c66 100644
>>   --- a/cts/CTSlab.py.in
>>   +++ b/cts/CTSlab.py.in
>>   @@ -1,4 +1,4 @@
>> @@ -43,10 +42,10 @@ index 81a5da8c0..bbadf938a 100644
>>    '''OCF IPaddr/IPaddr2 Resource Agent Test'''
>>   
>>   diff --git a/cts/cluster_test.in b/cts/cluster_test.in
>> -index e0d28509d..f982be05a 100755
>> +index 38f941d3e..5a289e3fc 100755
>>   --- a/cts/cluster_test.in
>>   +++ b/cts/cluster_test.in
>> -@@ -171,4 +171,4 @@ printf "\nAll set to go for %d iterations!\n" "$CTS_numtests"
>> +@@ -172,4 +172,4 @@ printf "\nAll set to go for %d iterations!\n" "$CTS_numtests"
>>        || echo "+ To use a different configuration, remove ~/.cts and re-run cts (or edit it manually)."
>>   
>>    echo Now paste the following command into this shell:
>> @@ -63,7 +62,7 @@ index 592d850b4..9a653a442 100644
>>    """
>>   
>>   diff --git a/cts/cts-fencing.in b/cts/cts-fencing.in
>> -index 2d9999ca0..8e3fb7203 100644
>> +index 444402438..0270c99ce 100644
>>   --- a/cts/cts-fencing.in
>>   +++ b/cts/cts-fencing.in
>>   @@ -1,4 +1,4 @@
>> @@ -83,7 +82,7 @@ index 28f4efe7f..b4ed5024f 100644
>>   
>>    Reads a specified number of lines from the supplied offset
>>   diff --git a/cts/cts-scheduler.in b/cts/cts-scheduler.in
>> -index 8fa16fb69..d4306b02b 100644
>> +index 23e6a919f..09058ce22 100644
>>   --- a/cts/cts-scheduler.in
>>   +++ b/cts/cts-scheduler.in
>>   @@ -1,4 +1,4 @@
>> @@ -93,7 +92,7 @@ index 8fa16fb69..d4306b02b 100644
>>    """
>>   
>>   diff --git a/cts/environment.py b/cts/environment.py
>> -index db9d3db16..9d103fda9 100644
>> +index 6a97b1289..39e89fa6f 100644
>>   --- a/cts/environment.py
>>   +++ b/cts/environment.py
>>   @@ -639,7 +639,7 @@ class Environment(object):
>> @@ -106,7 +105,7 @@ index db9d3db16..9d103fda9 100644
>>   
>>            sys.exit(status)
>>   diff --git a/cts/fence_dummy.in b/cts/fence_dummy.in
>> -index a2692b1e0..f1d111205 100644
>> +index 8b0dd5165..9e8624bd9 100644
>>   --- a/cts/fence_dummy.in
>>   +++ b/cts/fence_dummy.in
>>   @@ -1,4 +1,4 @@
>> @@ -148,19 +147,6 @@ index 42d35b649..467e1c524 100644
>>    ----
>>    ====
>>    which will be replaced with the appropriate python executable when Pacemaker is
>> -diff --git a/doc/Pacemaker_Development/pot/Ch-Python.pot b/doc/Pacemaker_Development/pot/Ch-Python.pot
>> -index ed71331ce..27c7e22e5 100644
>> ---- a/doc/Pacemaker_Development/pot/Ch-Python.pot
>> -+++ b/doc/Pacemaker_Development/pot/Ch-Python.pot
>> -@@ -39,7 +39,7 @@ msgstr ""
>> -
>> - #. Tag: screen
>> - #, no-c-format
>> --msgid "#!@PYTHON@"
>> -+msgid "#!/usr/bin/env python3"
>> - msgstr ""
>> -
>> - #. Tag: para
>>   diff --git a/tools/pcmk_simtimes.in b/tools/pcmk_simtimes.in
>>   index 6e362243b..28009f499 100644
>>   --- a/tools/pcmk_simtimes.in
>> @@ -172,5 +158,5 @@ index 6e362243b..28009f499 100644
>>    """
>>   
>>   --
>> -2.23.0
>> +2.17.1
>>   
>> diff --git a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-Mark-declaration-with-extern.patch b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-Mark-declaration-with-extern.patch
>> deleted file mode 100644
>> index 5729447..0000000
>> --- a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-Mark-declaration-with-extern.patch
>> +++ /dev/null
>> @@ -1,46 +0,0 @@
>> -From e1abd3b7c7a0122813e4d0abdb079df10104882c Mon Sep 17 00:00:00 2001
>> -From: Mingli Yu<mingli.yu@...>
>> -Date: Thu, 3 Sep 2020 04:44:09 +0000
>> -Subject: [PATCH] Mark declaration with extern
>> -
>> -Fixes build with gcc 10+
>> -
>> -Upstream-Status: Pending
>> -
>> -Signed-off-by: Mingli Yu<mingli.yu@...>
>> ----
>> - daemons/attrd/pacemaker-attrd.h | 4 ++--
>> - daemons/execd/pacemaker-execd.h | 2 +-
>> - 2 files changed, 3 insertions(+), 3 deletions(-)
>> -
>> -diff --git a/daemons/attrd/pacemaker-attrd.h b/daemons/attrd/pacemaker-attrd.h
>> -index cc8e29ee1..76778915e 100644
>> ---- a/daemons/attrd/pacemaker-attrd.h
>> -+++ b/daemons/attrd/pacemaker-attrd.h
>> -@@ -106,8 +106,8 @@ typedef struct attribute_value_s {
>> -         gboolean seen;
>> - } attribute_value_t;
>> -
>> --crm_cluster_t *attrd_cluster;
>> --GHashTable *attributes;
>> -+extern crm_cluster_t *attrd_cluster;
>> -+extern GHashTable *attributes;
>> -
>> - #define attrd_send_ack(client, id, flags) \
>> -     crm_ipcs_send_ack((client), (id), (flags), "ack", __FUNCTION__, __LINE__)
>> -diff --git a/daemons/execd/pacemaker-execd.h b/daemons/execd/pacemaker-execd.h
>> -index 4a52d9183..dab3ccdbe 100644
>> ---- a/daemons/execd/pacemaker-execd.h
>> -+++ b/daemons/execd/pacemaker-execd.h
>> -@@ -20,7 +20,7 @@
>> - #    include <gnutls/gnutls.h>
>> - #  endif
>> -
>> --GHashTable *rsc_list;
>> -+extern GHashTable *rsc_list;
>> -
>> - typedef struct lrmd_rsc_s {
>> -     char *rsc_id;
>> ---
>> -2.26.2
>> -
>> diff --git a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-pacemaker-fix-compile-error-of-musl-libc.patch b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-pacemaker-fix-compile-error-of-musl-libc.patch
>> index f8cbb7e..a10e8cd 100644
>> --- a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-pacemaker-fix-compile-error-of-musl-libc.patch
>> +++ b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-pacemaker-fix-compile-error-of-musl-libc.patch
>> @@ -1,4 +1,4 @@
>> -From 51b0df9242bb1e3eb41362381472a00727910f64 Mon Sep 17 00:00:00 2001
>> +From ba9e4810a09893521d28f6c699fb7f213d4a4b34 Mon Sep 17 00:00:00 2001
>>   From: Changqing Li<changqing.li@...>
>>   Date: Fri, 10 Aug 2018 15:08:31 +0800
>>   Subject: [PATCH] pacemaker: fix compile error of musl libc
>> @@ -7,28 +7,14 @@ Upstream-Status: Pending
>>   
>>   Signed-off-by: Changqing Li<changqing.li@...>
>>   ---
>> - include/crm/stonith-ng.h | 1 +
>> - lib/cib/cib_remote.c     | 3 ---
>> - tools/crm_mon.c          | 2 +-
>> - 3 files changed, 2 insertions(+), 4 deletions(-)
>> + lib/cib/cib_remote.c | 3 ---
>> + 1 file changed, 3 deletions(-)
>>   
>> -diff --git a/include/crm/stonith-ng.h b/include/crm/stonith-ng.h
>> -index 56c1ec7..a637b47 100644
>> ---- a/include/crm/stonith-ng.h
>> -+++ b/include/crm/stonith-ng.h
>> -@@ -28,6 +28,7 @@
>> - #  include <dlfcn.h>
>> - #  include <errno.h>
>> - #  include <stdbool.h>
>> -+#  include <time.h>
>> -
>> - /* TO-DO: Work out how to drop this requirement */
>> - #  include <libxml/tree.h>
>>   diff --git a/lib/cib/cib_remote.c b/lib/cib/cib_remote.c
>> -index 4d7b93b..8be8ecc 100644
>> +index 4de0a0f7b..7686637db 100644
>>   --- a/lib/cib/cib_remote.c
>>   +++ b/lib/cib/cib_remote.c
>> -@@ -53,9 +53,6 @@ typedef void gnutls_session_t;
>> +@@ -45,9 +45,6 @@ typedef void gnutls_session_t;
>>    #endif
>>   
>>    #include <arpa/inet.h>
>> @@ -38,19 +24,6 @@ index 4d7b93b..8be8ecc 100644
>>   
>>    #define DH_BITS 1024
>>   
>> -diff --git a/tools/crm_mon.c b/tools/crm_mon.c
>> -index 7c63803..1ae6c21 100644
>> ---- a/tools/crm_mon.c
>> -+++ b/tools/crm_mon.c
>> -@@ -553,7 +553,7 @@ main(int argc, char **argv)
>> -
>> - #if !defined (ON_DARWIN) && !defined (ON_BSD)
>> -     /* prevent zombies */
>> --    signal(SIGCLD, SIG_IGN);
>> -+    signal(SIGCHLD, SIG_IGN);
>> - #endif
>> -
>> -     if (crm_ends_with_ext(argv[0], ".cgi") == TRUE) {
>>   --
>> -2.7.4
>> +2.17.1
>>   
>> diff --git a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0006-Fix-tools-Fix-definition-of-curses_indented_printf.patch b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0006-Fix-tools-Fix-definition-of-curses_indented_printf.patch
>> deleted file mode 100644
>> index f5e1829..0000000
>> --- a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0006-Fix-tools-Fix-definition-of-curses_indented_printf.patch
>> +++ /dev/null
>> @@ -1,30 +0,0 @@
>> -From 426f06cc088d11d6db0c45b434e5ce6b69da78b4 Mon Sep 17 00:00:00 2001
>> -From: Chris Lumens<clumens@...>
>> -Date: Thu, 2 Jan 2020 15:08:58 -0500
>> -Subject: [PATCH 006/207] Fix: tools: Fix definition of curses_indented_printf.
>> -
>> -The placeholder version that is built if curses is not enabled does not
>> -have a type that matches the header file.  Correct that.
>> -
>> -Signed-off-by: Jeremy A. Puhlman<jpuhlman@...>
>> -Upstream-Status: Backport[git]
>> ----
>> - tools/crm_mon_curses.c | 2 +-
>> - 1 file changed, 1 insertion(+), 1 deletion(-)
>> -
>> -diff --git a/tools/crm_mon_curses.c b/tools/crm_mon_curses.c
>> -index c0dbedbf0..ecd0584fe 100644
>> ---- a/tools/crm_mon_curses.c
>> -+++ b/tools/crm_mon_curses.c
>> -@@ -368,7 +368,7 @@ curses_indented_vprintf(pcmk__output_t *out, const char *format, va_list args) {
>> -
>> - G_GNUC_PRINTF(2, 3)
>> - void
>> --curses_indented_printf(pcmk__output_t *out, const char *format, va_list args) {
>> -+curses_indented_printf(pcmk__output_t *out, const char *format, ...) {
>> -     return;
>> - }
>> -
>> ---
>> -2.23.0
>> -
>> diff --git a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker_2.0.3.bb b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker_2.0.5.bb
>> similarity index 96%
>> rename from meta-cgl-common/recipes-cgl/pacemaker/pacemaker_2.0.3.bb
>> rename to meta-cgl-common/recipes-cgl/pacemaker/pacemaker_2.0.5.bb
>> index 8576f18..6cfa057 100644
>> --- a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker_2.0.3.bb
>> +++ b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker_2.0.5.bb
>> @@ -14,9 +14,7 @@ LIC_FILES_CHKSUM ="file://COPYING;md5=000212f361a81b100d9d0f0435040663"
>>   DEPENDS = "corosync libxslt libxml2 gnutls resource-agents libqb python3-native"
>>   
>>   SRC_URI = "git://github.com/ClusterLabs/${BPN}.git \
>> -file://0006-Fix-tools-Fix-definition-of-curses_indented_printf.patch  \
>>              file://0001-Fix-python3-usage.patch  \
>> -file://0001-Mark-declaration-with-extern.patch  \
>>              file://0001-pacemaker-set-OCF_ROOT_DIR-to-libdir-ocf.patch  \
>>              file://volatiles  \
>>              file://tmpfiles  \
>> @@ -26,7 +24,7 @@ CFLAGS += "-I${STAGING_INCDIR}/heartbeat"
>>   CPPFLAGS +="-I${STAGING_INCDIR}/heartbeat"
>>   SRC_URI_append_libc-musl ="file://0001-pacemaker-fix-compile-error-of-musl-libc.patch"
>>   
>> -SRCREV = "4b1f869f0f64ef0d248b6aa4781d38ecccf83318"
>> +SRCREV = "ba59be71228fed04f78ab374dfac748d314d0e89"
>>   
>>   inherit autotools-brokensep pkgconfig systemd python3native python3-dir useradd
>>   
>> @@ -78,6 +76,7 @@ do_install_append() {
>>   
>>       rm -rf ${D}${localstatedir}/lib/heartbeat
>>       rm -rf ${D}${localstatedir}/run
>> +    rm -rf ${D}${localstatedir}/log
>>   
>>       # remove buildpath
>>       tempdirs=$(grep -Rn ${RECIPE_SYSROOT_NATIVE} ${D}/* | awk -F: '{print $1}' | uniq)
>>
>
>
>
>


--
# Randy MacLeod
# Wind River Linux


--
Jeremy Puhlman
Montavista Software, LLC.


Re: [meta-cgl][PATCH] pacemaker: upgrade 2.0.3 -> 2.0.5

Randy MacLeod
 

On 2021-03-05 1:28 a.m., Changqing Li wrote:
ping
Is this layer alive? :)

../Randy
On 12/9/20 2:01 PM, Yi Zhao wrote:
Drop backported patches:
0001-Mark-declaration-with-extern.patch
0006-Fix-tools-Fix-definition-of-curses_indented_printf.patch

Rebase patches:
0001-Fix-python3-usage.patch
0001-pacemaker-fix-compile-error-of-musl-libc.patch

Remove /var/log directory in do_install and create /var/log/pacemaker
directory in volatile file.

Signed-off-by: Yi Zhao<yi.zhao@...>
---
.../recipes-cgl/pacemaker/files/tmpfiles | 3 +-
.../recipes-cgl/pacemaker/files/volatiles | 1 +
.../pacemaker/0001-Fix-python3-usage.patch | 34 ++++----------
.../0001-Mark-declaration-with-extern.patch | 46 -------------------
...maker-fix-compile-error-of-musl-libc.patch | 39 +++-------------
...definition-of-curses_indented_printf.patch | 30 ------------
...{pacemaker_2.0.3.bb => pacemaker_2.0.5.bb} | 5 +-
7 files changed, 21 insertions(+), 137 deletions(-)
mode change 100755 => 100644 meta-cgl-common/recipes-cgl/pacemaker/files/tmpfiles
mode change 100755 => 100644 meta-cgl-common/recipes-cgl/pacemaker/files/volatiles
delete mode 100644 meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-Mark-declaration-with-extern.patch
delete mode 100644 meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0006-Fix-tools-Fix-definition-of-curses_indented_printf.patch
rename meta-cgl-common/recipes-cgl/pacemaker/{pacemaker_2.0.3.bb => pacemaker_2.0.5.bb} (96%)

diff --git a/meta-cgl-common/recipes-cgl/pacemaker/files/tmpfiles b/meta-cgl-common/recipes-cgl/pacemaker/files/tmpfiles
old mode 100755
new mode 100644
index 979db47..765ee0d
--- a/meta-cgl-common/recipes-cgl/pacemaker/files/tmpfiles
+++ b/meta-cgl-common/recipes-cgl/pacemaker/files/tmpfiles
@@ -3,4 +3,5 @@ d /var/lib/pacemaker/cib 0750 hacluster haclient -
d /var/lib/pacemaker/cores 0750 hacluster haclient -
d /var/lib/pacemaker/pengine 0750 hacluster haclient -
d /var/lib/pacemaker/blackbox 0750 hacluster haclient -
-d /var/run/crm 0750 hacluster haclient -
+d /run/crm 0750 hacluster haclient -
+d /var/log/pacemaker 0750 hacluster haclient -
diff --git a/meta-cgl-common/recipes-cgl/pacemaker/files/volatiles b/meta-cgl-common/recipes-cgl/pacemaker/files/volatiles
old mode 100755
new mode 100644
index 1700a69..eca3002
--- a/meta-cgl-common/recipes-cgl/pacemaker/files/volatiles
+++ b/meta-cgl-common/recipes-cgl/pacemaker/files/volatiles
@@ -4,3 +4,4 @@ d hacluster haclient 0750 /var/lib/pacemaker/cores none
d hacluster haclient 0750 /var/lib/pacemaker/pengine none
d hacluster haclient 0750 /var/lib/pacemaker/blackbox none
d hacluster haclient 0750 /var/run/crm none
+d hacluster haclient 0750 /var/log/pacemaker none
diff --git a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-Fix-python3-usage.patch b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-Fix-python3-usage.patch
index 05d7a76..2095227 100644
--- a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-Fix-python3-usage.patch
+++ b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-Fix-python3-usage.patch
@@ -1,4 +1,4 @@
-From fdefa9efc726fe704238d462a3dc207e0282fb9e Mon Sep 17 00:00:00 2001
+From f470884e0b990676685c8740b5c7d6f094267e4f Mon Sep 17 00:00:00 2001
From: Jeremy Puhlman<jpuhlman@...>
Date: Sun, 15 Mar 2020 21:09:33 +0000
Subject: [PATCH] Fix python3 usage
@@ -18,12 +18,11 @@ Upstream-Status: Pending
cts/pacemaker-cts-dummyd.in | 2 +-
daemons/fenced/fence_legacy.in | 2 +-
doc/Pacemaker_Development/en-US/Ch-Python.txt | 2 +-
- doc/Pacemaker_Development/pot/Ch-Python.pot | 2 +-
tools/pcmk_simtimes.in | 2 +-
- 14 files changed, 14 insertions(+), 14 deletions(-)
+ 13 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/cts/CTSlab.py.in b/cts/CTSlab.py.in
-index f4ae60dc1..55a0d4ecf 100644
+index 4bae93515..f09f71c66 100644
--- a/cts/CTSlab.py.in
+++ b/cts/CTSlab.py.in
@@ -1,4 +1,4 @@
@@ -43,10 +42,10 @@ index 81a5da8c0..bbadf938a 100644
'''OCF IPaddr/IPaddr2 Resource Agent Test'''
diff --git a/cts/cluster_test.in b/cts/cluster_test.in
-index e0d28509d..f982be05a 100755
+index 38f941d3e..5a289e3fc 100755
--- a/cts/cluster_test.in
+++ b/cts/cluster_test.in
-@@ -171,4 +171,4 @@ printf "\nAll set to go for %d iterations!\n" "$CTS_numtests"
+@@ -172,4 +172,4 @@ printf "\nAll set to go for %d iterations!\n" "$CTS_numtests"
|| echo "+ To use a different configuration, remove ~/.cts and re-run cts (or edit it manually)."
echo Now paste the following command into this shell:
@@ -63,7 +62,7 @@ index 592d850b4..9a653a442 100644
"""
diff --git a/cts/cts-fencing.in b/cts/cts-fencing.in
-index 2d9999ca0..8e3fb7203 100644
+index 444402438..0270c99ce 100644
--- a/cts/cts-fencing.in
+++ b/cts/cts-fencing.in
@@ -1,4 +1,4 @@
@@ -83,7 +82,7 @@ index 28f4efe7f..b4ed5024f 100644
Reads a specified number of lines from the supplied offset
diff --git a/cts/cts-scheduler.in b/cts/cts-scheduler.in
-index 8fa16fb69..d4306b02b 100644
+index 23e6a919f..09058ce22 100644
--- a/cts/cts-scheduler.in
+++ b/cts/cts-scheduler.in
@@ -1,4 +1,4 @@
@@ -93,7 +92,7 @@ index 8fa16fb69..d4306b02b 100644
"""
diff --git a/cts/environment.py b/cts/environment.py
-index db9d3db16..9d103fda9 100644
+index 6a97b1289..39e89fa6f 100644
--- a/cts/environment.py
+++ b/cts/environment.py
@@ -639,7 +639,7 @@ class Environment(object):
@@ -106,7 +105,7 @@ index db9d3db16..9d103fda9 100644
sys.exit(status)
diff --git a/cts/fence_dummy.in b/cts/fence_dummy.in
-index a2692b1e0..f1d111205 100644
+index 8b0dd5165..9e8624bd9 100644
--- a/cts/fence_dummy.in
+++ b/cts/fence_dummy.in
@@ -1,4 +1,4 @@
@@ -148,19 +147,6 @@ index 42d35b649..467e1c524 100644
----
====
which will be replaced with the appropriate python executable when Pacemaker is
-diff --git a/doc/Pacemaker_Development/pot/Ch-Python.pot b/doc/Pacemaker_Development/pot/Ch-Python.pot
-index ed71331ce..27c7e22e5 100644
---- a/doc/Pacemaker_Development/pot/Ch-Python.pot
-+++ b/doc/Pacemaker_Development/pot/Ch-Python.pot
-@@ -39,7 +39,7 @@ msgstr ""
-
- #. Tag: screen
- #, no-c-format
--msgid "#!@PYTHON@"
-+msgid "#!/usr/bin/env python3"
- msgstr ""
-
- #. Tag: para
diff --git a/tools/pcmk_simtimes.in b/tools/pcmk_simtimes.in
index 6e362243b..28009f499 100644
--- a/tools/pcmk_simtimes.in
@@ -172,5 +158,5 @@ index 6e362243b..28009f499 100644
"""
--
-2.23.0
+2.17.1
diff --git a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-Mark-declaration-with-extern.patch b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-Mark-declaration-with-extern.patch
deleted file mode 100644
index 5729447..0000000
--- a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-Mark-declaration-with-extern.patch
+++ /dev/null
@@ -1,46 +0,0 @@
-From e1abd3b7c7a0122813e4d0abdb079df10104882c Mon Sep 17 00:00:00 2001
-From: Mingli Yu<mingli.yu@...>
-Date: Thu, 3 Sep 2020 04:44:09 +0000
-Subject: [PATCH] Mark declaration with extern
-
-Fixes build with gcc 10+
-
-Upstream-Status: Pending
-
-Signed-off-by: Mingli Yu<mingli.yu@...>
----
- daemons/attrd/pacemaker-attrd.h | 4 ++--
- daemons/execd/pacemaker-execd.h | 2 +-
- 2 files changed, 3 insertions(+), 3 deletions(-)
-
-diff --git a/daemons/attrd/pacemaker-attrd.h b/daemons/attrd/pacemaker-attrd.h
-index cc8e29ee1..76778915e 100644
---- a/daemons/attrd/pacemaker-attrd.h
-+++ b/daemons/attrd/pacemaker-attrd.h
-@@ -106,8 +106,8 @@ typedef struct attribute_value_s {
- gboolean seen;
- } attribute_value_t;
-
--crm_cluster_t *attrd_cluster;
--GHashTable *attributes;
-+extern crm_cluster_t *attrd_cluster;
-+extern GHashTable *attributes;
-
- #define attrd_send_ack(client, id, flags) \
- crm_ipcs_send_ack((client), (id), (flags), "ack", __FUNCTION__, __LINE__)
-diff --git a/daemons/execd/pacemaker-execd.h b/daemons/execd/pacemaker-execd.h
-index 4a52d9183..dab3ccdbe 100644
---- a/daemons/execd/pacemaker-execd.h
-+++ b/daemons/execd/pacemaker-execd.h
-@@ -20,7 +20,7 @@
- # include <gnutls/gnutls.h>
- # endif
-
--GHashTable *rsc_list;
-+extern GHashTable *rsc_list;
-
- typedef struct lrmd_rsc_s {
- char *rsc_id;
---
-2.26.2
-
diff --git a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-pacemaker-fix-compile-error-of-musl-libc.patch b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-pacemaker-fix-compile-error-of-musl-libc.patch
index f8cbb7e..a10e8cd 100644
--- a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-pacemaker-fix-compile-error-of-musl-libc.patch
+++ b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-pacemaker-fix-compile-error-of-musl-libc.patch
@@ -1,4 +1,4 @@
-From 51b0df9242bb1e3eb41362381472a00727910f64 Mon Sep 17 00:00:00 2001
+From ba9e4810a09893521d28f6c699fb7f213d4a4b34 Mon Sep 17 00:00:00 2001
From: Changqing Li<changqing.li@...>
Date: Fri, 10 Aug 2018 15:08:31 +0800
Subject: [PATCH] pacemaker: fix compile error of musl libc
@@ -7,28 +7,14 @@ Upstream-Status: Pending
Signed-off-by: Changqing Li<changqing.li@...>
---
- include/crm/stonith-ng.h | 1 +
- lib/cib/cib_remote.c | 3 ---
- tools/crm_mon.c | 2 +-
- 3 files changed, 2 insertions(+), 4 deletions(-)
+ lib/cib/cib_remote.c | 3 ---
+ 1 file changed, 3 deletions(-)
-diff --git a/include/crm/stonith-ng.h b/include/crm/stonith-ng.h
-index 56c1ec7..a637b47 100644
---- a/include/crm/stonith-ng.h
-+++ b/include/crm/stonith-ng.h
-@@ -28,6 +28,7 @@
- # include <dlfcn.h>
- # include <errno.h>
- # include <stdbool.h>
-+# include <time.h>
-
- /* TO-DO: Work out how to drop this requirement */
- # include <libxml/tree.h>
diff --git a/lib/cib/cib_remote.c b/lib/cib/cib_remote.c
-index 4d7b93b..8be8ecc 100644
+index 4de0a0f7b..7686637db 100644
--- a/lib/cib/cib_remote.c
+++ b/lib/cib/cib_remote.c
-@@ -53,9 +53,6 @@ typedef void gnutls_session_t;
+@@ -45,9 +45,6 @@ typedef void gnutls_session_t;
#endif
#include <arpa/inet.h>
@@ -38,19 +24,6 @@ index 4d7b93b..8be8ecc 100644
#define DH_BITS 1024
-diff --git a/tools/crm_mon.c b/tools/crm_mon.c
-index 7c63803..1ae6c21 100644
---- a/tools/crm_mon.c
-+++ b/tools/crm_mon.c
-@@ -553,7 +553,7 @@ main(int argc, char **argv)
-
- #if !defined (ON_DARWIN) && !defined (ON_BSD)
- /* prevent zombies */
-- signal(SIGCLD, SIG_IGN);
-+ signal(SIGCHLD, SIG_IGN);
- #endif
-
- if (crm_ends_with_ext(argv[0], ".cgi") == TRUE) {
--
-2.7.4
+2.17.1
diff --git a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0006-Fix-tools-Fix-definition-of-curses_indented_printf.patch b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0006-Fix-tools-Fix-definition-of-curses_indented_printf.patch
deleted file mode 100644
index f5e1829..0000000
--- a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0006-Fix-tools-Fix-definition-of-curses_indented_printf.patch
+++ /dev/null
@@ -1,30 +0,0 @@
-From 426f06cc088d11d6db0c45b434e5ce6b69da78b4 Mon Sep 17 00:00:00 2001
-From: Chris Lumens<clumens@...>
-Date: Thu, 2 Jan 2020 15:08:58 -0500
-Subject: [PATCH 006/207] Fix: tools: Fix definition of curses_indented_printf.
-
-The placeholder version that is built if curses is not enabled does not
-have a type that matches the header file. Correct that.
-
-Signed-off-by: Jeremy A. Puhlman<jpuhlman@...>
-Upstream-Status: Backport[git]
----
- tools/crm_mon_curses.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/tools/crm_mon_curses.c b/tools/crm_mon_curses.c
-index c0dbedbf0..ecd0584fe 100644
---- a/tools/crm_mon_curses.c
-+++ b/tools/crm_mon_curses.c
-@@ -368,7 +368,7 @@ curses_indented_vprintf(pcmk__output_t *out, const char *format, va_list args) {
-
- G_GNUC_PRINTF(2, 3)
- void
--curses_indented_printf(pcmk__output_t *out, const char *format, va_list args) {
-+curses_indented_printf(pcmk__output_t *out, const char *format, ...) {
- return;
- }
-
---
-2.23.0
-
diff --git a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker_2.0.3.bb b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker_2.0.5.bb
similarity index 96%
rename from meta-cgl-common/recipes-cgl/pacemaker/pacemaker_2.0.3.bb
rename to meta-cgl-common/recipes-cgl/pacemaker/pacemaker_2.0.5.bb
index 8576f18..6cfa057 100644
--- a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker_2.0.3.bb
+++ b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker_2.0.5.bb
@@ -14,9 +14,7 @@ LIC_FILES_CHKSUM ="file://COPYING;md5=000212f361a81b100d9d0f0435040663"
DEPENDS = "corosync libxslt libxml2 gnutls resource-agents libqb python3-native"
SRC_URI = "git://github.com/ClusterLabs/${BPN}.git \
-file://0006-Fix-tools-Fix-definition-of-curses_indented_printf.patch \
file://0001-Fix-python3-usage.patch \
-file://0001-Mark-declaration-with-extern.patch \
file://0001-pacemaker-set-OCF_ROOT_DIR-to-libdir-ocf.patch \
file://volatiles \
file://tmpfiles \
@@ -26,7 +24,7 @@ CFLAGS += "-I${STAGING_INCDIR}/heartbeat"
CPPFLAGS +="-I${STAGING_INCDIR}/heartbeat"
SRC_URI_append_libc-musl ="file://0001-pacemaker-fix-compile-error-of-musl-libc.patch"
-SRCREV = "4b1f869f0f64ef0d248b6aa4781d38ecccf83318"
+SRCREV = "ba59be71228fed04f78ab374dfac748d314d0e89"
inherit autotools-brokensep pkgconfig systemd python3native python3-dir useradd
@@ -78,6 +76,7 @@ do_install_append() {
rm -rf ${D}${localstatedir}/lib/heartbeat
rm -rf ${D}${localstatedir}/run
+ rm -rf ${D}${localstatedir}/log
# remove buildpath
tempdirs=$(grep -Rn ${RECIPE_SYSROOT_NATIVE} ${D}/* | awk -F: '{print $1}' | uniq)

--
# Randy MacLeod
# Wind River Linux


M+ & H bugs with Milestone Movements WW15

Stephen Jolley
 

All,

YP M+ or high bugs which moved to a new milestone in WW15 are listed below:

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

Medium+

5389

bitbake/lib/bb/fetch2: filename too long

randy.macleod@...

unassigned@...

3.3 M4

3.4 M1

 

10061

Ctrl+C during BB_HASHCHECK_FUNCTION execution does not interrupt processing nicely

randy.macleod@...

unassigned@...

3.3 M4

3.4 M1

 

12023

bitbake-layers show-layers doesn't show layer if it doesn't append itself to BBFILE_COLLECTIONS

randy.macleod@...

unassigned@...

3.3 M4

3.4 M1

 

12290

cross recipe kernel module dependency generation stopped working

randy.macleod@...

unassigned@...

3.3 M4

3.4 M1

 

12367

moving or removing tmp breaks persistent bitbake server

randy.macleod@...

unassigned@...

3.3 M4

3.4 M1

 

13054

oe-selftest oelib.utils.TestMultiprocessLaunch.test_multiprocesslaunch failure

randy.macleod@...

trevor.gamblin@...

3.3 M4

3.4 M1

 

13123

package.PackageTests.test_gdb_hardlink_debug failed

randy.macleod@...

randy.macleod@...

3.3 M4

3.4 M1

 

13288

pseudo should not follow symlinks in /proc

randy.macleod@...

sakib.sajal@...

3.3 M1

3.4 M1

 

13802

ltp tests fail with ssh connection lost  error intermittently

randy.macleod@...

sakib.sajal@...

3.3 M4

3.4 M1

 

13897

POSTINST_INTERCEPTS_DIR broken by undocumented POSTINST_INTERCEPTS_PATHS since thud

randy.macleod@...

unassigned@...

3.3 M4

3.4 M1

 

13910

Intermittent host UID contamination highlighted by devtool tests

randy.macleod@...

unassigned@...

3.3 M4

3.4 M1

 

13920

uninative tarball license compliance in ESDK

randy.macleod@...

unassigned@...

3.3 M4

3.4 M1

 

13935

Intermittent  taskhash mismatch errors on autobuilder

randy.macleod@...

JPEWhacker@...

3.3 M4

3.4 M1

 

13950

Intermittent qemu connection failures during oe-selftest on autobuilder

randy.macleod@...

sakib.sajal@...

3.3 M4

3.4 M1

 

13976

gdb8.3 do compile with musl is error

randy.macleod@...

unassigned@...

3.3 M4

3.4 M1

 

13992

qemumips testimage keeps failing

randy.macleod@...

victor.kamensky7@...

3.3 M4

3.4 M1

 

13999

do_packagedata setscene file race

randy.macleod@...

ross@...

3.3 M4

3.4 M1

 

14002

ssh connection failure during stap testing on qemuarm

randy.macleod@...

saul.wold@...

3.3 M4

3.4 M1

 

14010

qemumips-alt systemd boot unit failure on fedora32-ty-1

randy.macleod@...

akuster808@...

3.3 M4

3.4 M1

 

14028

Autobuilder buildtools run fails with "Qemu ended unexpectedly"

randy.macleod@...

unassigned@...

3.3 M4

3.4 M1

 

14041

qemuarm-alt  failed to load rpcbind

randy.macleod@...

kai.kang@...

3.3 M4

3.4 M1

 

14095

signing selftest failure in test_signing_sstate_archive  debina9-ty-2

randy.macleod@...

saul.wold@...

3.3 M4

3.4 M1

 

14096

perl install race (pod2text)

randy.macleod@...

unassigned@...

3.3 M4

3.4 M1

 

14090

devtool.DevtoolExtractTests.test_devtool_deploy_target selftest failure

randy.macleod@...

stacygaikovaia@...

3.3 M4

3.4 M1

 

14123

Intermittent FileNotFound error on autobuilder oe-selftest-debian

randy.macleod@...

richard.purdie@...

3.3 M4

3.4 M1

 

14128

qemuppc failed to shutdown

randy.macleod@...

unassigned@...

3.3 M4

3.4 M1

 

14158

tinfoil.TinfoilTests.test_wait_event times out

randy.macleod@...

yifan.yu@...

3.3 M4

3.4 M1

 

14163

libevent arm ptest intermittent failure

randy.macleod@...

yifan.yu@...

3.3 M4

3.4 M1

 

14170

glib-2.0 codegen ptest failure

randy.macleod@...

yifan.yu@...

3.3 M4

3.4 M1

 

14184

udev ram3 timeout and RCU preempt stall

randy.macleod@...

bruce.ashfield@...

3.3 M4

3.4 M1

 

14190

qa-extra2 failing on AB with dnf checksum failures

randy.macleod@...

ross@...

3.3 M4

3.4 M1

 

14200

autobuilder failure for edk2-firmware 201911

randy.macleod@...

jon.mason@...

3.3 M4

3.4 M1

 

14197

strace ptest intermittent failure in delay.test

randy.macleod@...

randy.macleod@...

3.3 M4

3.4 M1

 

14201

Bitbake server intermittent timeout

randy.macleod@...

unassigned@...

3.3 M4

3.4 M1

 

14213

gawk ptest intermittent failure

randy.macleod@...

yifan.yu@...

3.3 M4

3.4 M1

 

14214

rpm-native: do_configure failed

randy.macleod@...

hongxu.jia@...

3.3 M4

3.4 M1

 

14227

Intermittent oe-selftest fails with bash 5.1 do_compile

randy.macleod@...

richard.purdie@...

3.3 M4

3.4 M1

 

14230

qemuarm testimage shows serial login warning

randy.macleod@...

saul.wold@...

3.3 M4

3.4 M1

 

14244

util-linux script:_size ptest failure

randy.macleod@...

unassigned@...

3.3 M4

3.4 M1

 

14246

devtool test failures: github tls timeout

randy.macleod@...

unassigned@...

3.3 M4

3.4 M1

 

14250

core-image-sato.bb:do_testimage failure at systemd.SystemdBasicTests.test_systemd_failed

randy.macleod@...

kai.kang@...

3.3 M4

3.4 M1

 

14251

core-image-sato-1.0-r0:do_testimage FAILED when starting qemu

randy.macleod@...

unassigned@...

3.3 M4

3.4 M1

 

14257

gstreamer1.0 ptest intermittent failure

randy.macleod@...

unassigned@...

3.3 M4

3.4 M1

 

14258

perl ptest intermittent failure

randy.macleod@...

timothy.t.orling@...

3.3 M4

3.4 M1

 

14262

runcmd.RunCmdTests.test_stdin_timeout times out

randy.macleod@...

unassigned@...

3.3 M4

3.4 M1

 

14263

lttng-tools ptest intermittent failure

randy.macleod@...

unassigned@...

3.3 M4

3.4 M1

 

14273

qemu CPU starvation triggers rcu_preempt stall detection

randy.macleod@...

unassigned@...

3.3 M4

3.4 M1

 

14259

NFS mounting issue on  qemux64 oe-selftest glibc.GlibcSelfTestSystemEmulated.test_glibc

randy.macleod@...

unassigned@...

3.3 M4

3.4 M1

 

14272

qemumips64 testimage systemd didnt reach login prompt

randy.macleod@...

unassigned@...

3.3 M4

3.4 M1

 

14275

qemuarm64 parselogs fail due to udev taking to much time

randy.macleod@...

unassigned@...

3.3 M4

3.4 M1

 

14284

strace ptest intermittent failure in strace--relative-timestamps-us.gen.test

randy.macleod@...

randy.macleod@...

3.3 M4

3.4 M1

 

14289

failure in the command 'bitbake  glibc-testsuite -c check'

randy.macleod@...

unassigned@...

3.3 M4

3.4 M1

 

14290

golang TLS hanshake timeout

randy.macleod@...

raj.khem@...

3.3 M4

3.4 M1

 

14294

valgrind memcheck/tests/linux/timerfd-syscall ptest intermittent failure

randy.macleod@...

yifan.yu@...

3.3 M4

3.4 M1

 

14296

python3 ptest intermittent failure

randy.macleod@...

yifan.yu@...

3.3 M4

3.4 M1

 

14300

libtool-cross parallelism build failure

randy.macleod@...

unassigned@...

3.3 M4

3.4 M1

 

14299

failure in the command 'bitbake  gcc-runtime -c check'

randy.macleod@...

unassigned@...

3.3 M4

3.4 M1

 

14310

xz / liblzma memory allocation failure during reproducible build testing

randy.macleod@...

changqing.li@...

3.3 M4

3.4 M1

 

14311

valgrind drd/tests ptest intermittent failure

randy.macleod@...

yifan.yu@...

3.3 M4

3.4 M1

 

14328

Mitigate AB ptest intermittent failure

randy.macleod@...

richard.purdie@...

3.3 M4

3.4 M1

 

14331

Memory issues during oe-selftest

randy.macleod@...

trevor.gamblin@...

3.3 M4

3.4 M1

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Enhancements/Bugs closed WW15!

Stephen Jolley
 

All,

The below were the owners of enhancements or bugs closed during the last week!

Who

Count

randy.macleod@...

5

limon.anibal@...

2

mhalstead@...

1

steve@...

1

Grand Total

9

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Current high bug count owners for Yocto Project 3.3

Stephen Jolley
 

All,

Below is the list as of top 37 bug owners as of the end of WW15 of who have open medium or higher bugs and enhancements against YP 3.3.   There are 13 possible work days left until the final release candidates for YP 3.3 needs to be released.

Who

Count

ross@...

17

bluelightning@...

14

richard.purdie@...

9

mark.morton@...

7

JPEWhacker@...

6

akuster808@...

4

raj.khem@...

4

Qi.Chen@...

3

timothy.t.orling@...

3

idadelm@...

3

trevor.gamblin@...

3

mostthingsweb@...

3

alejandro@...

2

matthewzmd@...

2

jeanmarie.lemetayer@...

2

chee.yang.lee@...

2

jaewon@...

2

ydirson@...

2

randy.macleod@...

2

yoctoproject@...

1

hongxu.jia@...

1

aehs29@...

1

sakib.sajal@...

1

mhalstead@...

1

open.source@...

1

devendra.tewari@...

1

twoerner@...

1

mark.hatle@...

1

kergoth@...

1

dorindabassey@...

1

nicolas.dechesne@...

1

mister_rs@...

1

mshah@...

1

john.kaldas.enpj@...

1

bruce.ashfield@...

1

pokylinux@...

1

matt.ranostay@...

1

Grand Total

108

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Yocto Project Newcomer & Unassigned Bugs - Help Needed

Stephen Jolley
 

All,

 

The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs  Also please review: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and how to create a bugzilla account at: https://bugzilla.yoctoproject.org/createaccount.cgi

The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project.  If anyone can help, please take ownership of the bug and send patches!  If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 356 unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out with these.  Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system.  There are also roughly four different "priority" classes right now, “3.2”, “3.3, "3.99" and "Future", the more pressing/urgent issues being in "3.2" and then “3.3”.

 

Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp.pm@...) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account).  The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Re: bitbake controlling memory use

Gmane Admin
 

Op 12-04-2021 om 10:13 schreef Robert Berger@...:
Hi,
My comments are in-line.
On 11/04/2021 18:23, Gmane Admin wrote:
My build machine has 8 cores + HT so bitbake enthusiastically assumes 16. However I have (only?) 16GB of RAM (+24GB swap space).

16GB of RAM has always been more then enough with 4 core + HT, but now building certain recipes (nodejs, but rust will probably do it as well) eats up more memory then there actually is RAM causing excessive swapping.
The RAM usage depends heavily on what you are building ;) - It could be some crazy C++ stuff ;)
Yeah, C++. But apearently it's during the LTO phase where it eat my memory.

Is Linux your build host?
Yup.

Then you can use cgroups to limit resources like memory.
So then it would just fail the build?

Do you use a build container? It uses cgroups underneath.
Nope.

e.g. docker:
https://docs.docker.com/config/containers/resource_constraints/
Regards,
Robert


Re: bitbake controlling memory use

Gmane Admin
 

Hi,

Op 12-04-2021 om 04:25 schreef ChenQi:
I think you write a script to do all the WATCH-STOP-CONTINUE stuff.
e.g.
memwatch bitbake core-image-minimal
Options could be added.
e.g.
memwatch --interval 5 --logfile test.log bitbake core-image-minimal
This script first becomes a session leader, then forks to start the 'bitbake' command as its child process.
Then, every several seconds (say 10s by default), it checks the current memory usage, and according to its policy, determines whether to stop/continue some process or not.
For stopping the process, you can first get all its child process by simply using the 'ps' command.
e.g.
$ ps o vsize,comm,pid -s 28303 | sort -n -r
317284 emacs           12883
 28912 ps              36302
 26248 sort            36303
 21432 man             24797
 17992 bash            28303
  9852 pager           24807
   VSZ COMMAND           PID
Then skip the bitbake processes, stop the first one that uses the largest memory, record its PID.
For continuing processes, just start it according to the records. Maybe using FILO by default?
Best Regards,
Chen Qi
Yeah, so we would be having memwatch as a baby sitter.

I would be nicer to have it built into bitbake, but this would work too.

On 04/11/2021 11:23 PM, Gmane Admin wrote:
My build machine has 8 cores + HT so bitbake enthusiastically assumes 16. However I have (only?) 16GB of RAM (+24GB swap space).

16GB of RAM has always been more then enough with 4 core + HT, but now building certain recipes (nodejs, but rust will probably do it as well) eats up more memory then there actually is RAM causing excessive swapping.

In fact the swapping is so excessive that just this single recipe determines largely the total image build time. However restricting bitbake (or actually parallel make) to use only 4 cores + HT sounds also like a waste.

I know this has been looked at in the past, but I think it needs fundamental resolving (other then, hé, why not add just another stick of memory).

What I do manually when I run into swapping so bad my desktop becomes unresponsive is ssh from another machine and then stop (not kill) the processes that use the most memory.

These then get swapped out, but not back in, allowing the remaining tasks to complete without swapping. Then when sufficient memory becomes free again I continue the stopped processes.

Isn't this something that could be added to bitbake to automate using memory efficiently?




[meta-security][PATCH] Clearly define clang toolchain in Parsec recipes

Anton Antonov
 

Signed-off-by: Anton Antonov <Anton.Antonov@...>
---
.../recipes-parsec/parsec-service/parsec-service_0.7.0.bb | 4 ++--
meta-parsec/recipes-parsec/parsec-tool/parsec-tool_0.3.0.bb | 3 +--
2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/meta-parsec/recipes-parsec/parsec-service/parsec-service_0.7.0.bb b/meta-parsec/recipes-parsec/parsec-service/parsec-service_0.7.0.bb
index b3f7b21..0e14955 100644
--- a/meta-parsec/recipes-parsec/parsec-service/parsec-service_0.7.0.bb
+++ b/meta-parsec/recipes-parsec/parsec-service/parsec-service_0.7.0.bb
@@ -10,8 +10,8 @@ SRC_URI += "crate://crates.io/parsec-service/${PV} \
file://parsec-tmpfiles.conf \
"

-DEPENDS = "clang-native tpm2-tss"
-INSANE_SKIP_${PN} += "dev-deps"
+DEPENDS = "tpm2-tss"
+TOOLCHAIN = "clang"

CARGO_BUILD_FLAGS += " --features all-providers,cryptoki/generate-bindings,tss-esapi/generate-bindings"

diff --git a/meta-parsec/recipes-parsec/parsec-tool/parsec-tool_0.3.0.bb b/meta-parsec/recipes-parsec/parsec-tool/parsec-tool_0.3.0.bb
index 939e771..35c65c0 100644
--- a/meta-parsec/recipes-parsec/parsec-tool/parsec-tool_0.3.0.bb
+++ b/meta-parsec/recipes-parsec/parsec-tool/parsec-tool_0.3.0.bb
@@ -7,8 +7,7 @@ inherit cargo
SRC_URI += "crate://crates.io/parsec-tool/${PV} \
"

-DEPENDS = "clang-native"
-INSANE_SKIP_${PN} += "dev-deps"
+TOOLCHAIN = "clang"

do_install() {
install -d ${D}/${bindir}
--
2.20.1


Re: #golang: go fetches dependencies in compile phase

Alexander Kanavin
 

I'd suggest you place that tarball into some artefact storage, and have it listed in SRC_URI. Then the standard Yocto mechanism for fetching, checksumming, caching and unpacking tarballs kicks in, so you only need to make sure the tree is set up correctly after unpacking, maybe with some simple post-processing.

Alex


On Mon, 12 Apr 2021 at 16:02, Juergen Landwehr <juergen.landwehr@...> wrote:
Hi Alex,

OK, understood.

If the "local download cache path" is well-known (this is not by any chance $DL_DIR?), then we could create a tar from the vendor directory (which is created when you call "go mod vendor" and contains all the downloaded dependencies) and put this tar file into the download cache.

Before actually calling "go mod vendor", we would first check, if there is a tar file for the vendor directory in the download cache and if so simply unpack the tar.

Does this make sense, or am I too naive and this is just nonsense?

Jürgen



#golang: go fetches dependencies in compile phase

Juergen Landwehr
 

Hi Alex,

OK, understood.

If the "local download cache path" is well-known (this is not by any chance $DL_DIR?), then we could create a tar from the vendor directory (which is created when you call "go mod vendor" and contains all the downloaded dependencies) and put this tar file into the download cache.

Before actually calling "go mod vendor", we would first check, if there is a tar file for the vendor directory in the download cache and if so simply unpack the tar.

Does this make sense, or am I too naive and this is just nonsense?

Jürgen


Re: #golang: go fetches dependencies in compile phase

Alexander Kanavin
 

On Mon, 12 Apr 2021 at 13:47, Juergen Landwehr <juergen.landwehr@...> wrote:
But dependency management in go is not that arbitrary as it may seem. Dependencies and their version is stored in "go.mod". To ensure reproducable builds, hashes for each dependency and version are stored in "go.sum". Both files are in git and together with a local golang proxy, this should ensure reproducable builds, right?

Reproducibility means anyone can run a build at any point in the future even if the upstream repositories are gone, so all inputs must be stored in a local download cache, which is the other thing SRC_URI guarantees, in addition to verifying integrity of the inputs.

Alex


#golang: go fetches dependencies in compile phase

Juergen Landwehr
 

Hi Robert,

thanks for your thoughts.

I see your point and the last thing I want is "NOT reproducable builds".

But dependency management in go is not that arbitrary as it may seem. Dependencies and their version is stored in "go.mod". To ensure reproducable builds, hashes for each dependency and version are stored in "go.sum". Both files are in git and together with a local golang proxy, this should ensure reproducable builds, right?

To ensure that licences are valid and did not change over time, we developed a little tool, that goes through all dependencies and creates the following output, which we insert into our recipe:

LICENSE = "Apache-2.0 & MIT & MIT & BSD-2-Clause & BSD-3-Clause & ...

LIC_FILES_CHKSUM = " \
file://${S}/src/${GO_IMPORT}/vendor/github.com/coreos/go-oidc/LICENSE;md5=d2794c0df5b907fdace235a619d80314 \
file://${S}/src/${GO_IMPORT}/vendor/github.com/go-playground/locales/LICENSE;md5=3ccbda375ee345400ad1da85ba522301 \
file://${S}/src/${GO_IMPORT}/vendor/github.com/go-playground/universal-translator/LICENSE;md5=2e2b21ef8f61057977d27c727c84bef1 \
file://${S}/src/${GO_IMPORT}/vendor/github.com/godbus/dbus/v5/LICENSE;md5=09042bd5c6c96a2b9e45ddf1bc517eed \
file://${S}/src/${GO_IMPORT}/vendor/github.com/golang/gddo/LICENSE;md5=4c728948788b1a02f33ae4e906546eef \
...
This is a manual step and whenever dependencies change we have to create this list again and add it to the recipe, but it contains all the required license information and makes them visible in the recipe.

It might pollute the recipe a bit, but luckily we do not have thousands of dependencies like some npm projects. So I think it is still manageable. And is it much less work, than defining a recipe for each dependency.

So we would
* guarantee reproducable builds
* use the programming language (in our case golang) to handle dependency management
* ensure that licenses are visible and correct

I mean it is not perfect and still a compromise, but it should work without breaking reproducable builds or causing license issues?
What do you think?

Regards,
Jürgen

PS: Thanks for the link. I was not aware of this discussion (it is quite a bit to read:))


Re: #golang: go fetches dependencies in compile phase

Robert Berger
 

On 09/04/2021 16:53, Juergen Landwehr wrote:
Hi,
we are developing an application in go and use the "go-mod" bb-class from poky. This works fine.
However, the problem is, that the dependencies in go.mod are now fetched in the compile phase and not in the fetch phase.
Alexander (whom you cc'ed here as well) wrote a long time ago on the mailing list[1] about this stuff.

We have a couple of issues with those "modern" languages like go, which behave quite differently from good old Unix stuff. So the paradigm on which the whole Bitbake/OpenEmbedded/Yocto system was built does not quite apply for those.

Don't get me wrong, you can also do stupidities like git clone via make or cmake, but this is most likely not the way those tools should be used.

1) "Guaranteed __NOT__ reproducible builds"(C)

Go pulls in dependencies by itself, which might explain why it's in the compile phase and not it the fetch phase.

This leads to many interesting issues, like "guaranteed __NOT__ reproducible builds"(C). The problem is, that you don't have any influence on dependencies of dependencies. Someone changes somewhere a dependency on github and the party starts.

1.1) One sane solution to "please give me always the same input" is what Konrad already mentioned in combination with a local golang proxy.

2) Open Source License Compliance

If you pull in all those funny dependencies and also link things statically, like with go, Open Source License Compliance is getting very interesting.

People typically just use the license of the top level "main" entry point. In reality you would need to check all the dependency tree for licenses. You should also check if it's legally allowed to combine the licenses and in case it's allowed what are implications of GPLvx, LGPLv2, LGPLv3 without exceptions for your product.

[1] https://www.yoctoproject.org/pipermail/yocto/2017-March/035028.html

Regards,

Robert


#golang: go fetches dependencies in compile phase

Juergen Landwehr
 

Hello Konrad,

thanks for your reply.

It is interesting that you mention vendoring, because we tried this approach as well. We started to develop a "go-mod-vendor.bbclass", which retrieves the
application source code in "do_fetch_append" and then calls "go mod vendor".

The big problem was, that in that phase there is not yet a go executable available for the recipe, so we downloaded our own go version, which makes this approach a bit ugly.

But there is already a go version installed on the build host, right? In "poky/meta/recipes-devtools/go" I found a "go-native_1.14.bb" recipe.
So can we use this go exectuable somehow by adding a dependency (e.g. DEPENDS="go-native") and then use a path to the go exectuable that is guaranteed to work?

The other alternative (defining a recipe for each dependent go module) sounds really painful. Especially as we have quite a few dependencies, which have dependencies as well.
I see the point, that doing it that way makes it more visible and more Yocto like, but thinking about it gives me headaches already :)

Thanks again.


Re: bitbake controlling memory use

Mike Looijmans
 

Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijmans@...
W: www.topic.nl

Please consider the environment before printing this e-mail
On 11-04-2021 17:23, Gmane Admin via lists.yoctoproject.org wrote:
My build machine has 8 cores + HT so bitbake enthusiastically assumes 16. However I have (only?) 16GB of RAM (+24GB swap space).
Been there, done that (8/16 cores with 8GB RAM).

The major cause is that bitbake will not just spawn 16 compiler threads, it will actually spawn up to 16 "do_compile" tasks which may spawn 16 compiler processes each, thus you'll be running a whopping 256 compilers. Bitbake may spawn a total of n^2 threads by default with "n" the detected number of cores.

The workaround I used was to limit the number of bitbake threads but leave the make threads at 16. Since most software these days is using parallel make, the impact on the build time of reducing the bb threads to 8 or 4 is negligible.

As for translating this into a bitbake feature, an implementation that comes to mind is to add a "weight" to each task. Most tasks would get a weight of just "1", but a (multithreaded) compile would be weighted "8" (some formula involving the number of CPUs) or so. This would stop bitbake spawning more processes early so that you don't get into the n^2 threads problem, and the number of processed that bitbake will spawn will be close to linear agin instead of quadratic as is is now.

Recipes that have excessive memory loads (usually C++ template meta-programming) can then just increase the weighting for the compile task.


--
Mike Looijmans


Re: bitbake controlling memory use

Robert Berger
 

Hi,

My comments are in-line.

On 11/04/2021 18:23, Gmane Admin wrote:
My build machine has 8 cores + HT so bitbake enthusiastically assumes 16. However I have (only?) 16GB of RAM (+24GB swap space).
16GB of RAM has always been more then enough with 4 core + HT, but now building certain recipes (nodejs, but rust will probably do it as well) eats up more memory then there actually is RAM causing excessive swapping.
The RAM usage depends heavily on what you are building ;) - It could be some crazy C++ stuff ;)

Is Linux your build host?

Then you can use cgroups to limit resources like memory.

Do you use a build container? It uses cgroups underneath.

e.g. docker:

https://docs.docker.com/config/containers/resource_constraints/

Regards,

Robert


Re: bitbake controlling memory use

Chen Qi
 

I think you write a script to do all the WATCH-STOP-CONTINUE stuff.
e.g.
memwatch bitbake core-image-minimal
Options could be added.
e.g.
memwatch --interval 5 --logfile test.log bitbake core-image-minimal

This script first becomes a session leader, then forks to start the 'bitbake' command as its child process.
Then, every several seconds (say 10s by default), it checks the current memory usage, and according to its policy, determines whether to stop/continue some process or not.

For stopping the process, you can first get all its child process by simply using the 'ps' command.
e.g.
$ ps o vsize,comm,pid -s 28303 | sort -n -r
317284 emacs           12883
 28912 ps              36302
 26248 sort            36303
 21432 man             24797
 17992 bash            28303
  9852 pager           24807
   VSZ COMMAND           PID

Then skip the bitbake processes, stop the first one that uses the largest memory, record its PID.

For continuing processes, just start it according to the records. Maybe using FILO by default?

Best Regards,
Chen Qi

On 04/11/2021 11:23 PM, Gmane Admin wrote:
My build machine has 8 cores + HT so bitbake enthusiastically assumes 16. However I have (only?) 16GB of RAM (+24GB swap space).

16GB of RAM has always been more then enough with 4 core + HT, but now building certain recipes (nodejs, but rust will probably do it as well) eats up more memory then there actually is RAM causing excessive swapping.

In fact the swapping is so excessive that just this single recipe determines largely the total image build time. However restricting bitbake (or actually parallel make) to use only 4 cores + HT sounds also like a waste.

I know this has been looked at in the past, but I think it needs fundamental resolving (other then, hé, why not add just another stick of memory).

What I do manually when I run into swapping so bad my desktop becomes unresponsive is ssh from another machine and then stop (not kill) the processes that use the most memory.

These then get swapped out, but not back in, allowing the remaining tasks to complete without swapping. Then when sufficient memory becomes free again I continue the stopped processes.

Isn't this something that could be added to bitbake to automate using memory efficiently?







Re: bitbake controlling memory use

Alexander Kanavin
 

make already has -l option for limiting new instances if load average is too high, so it's only natural to add a RAM limiter too.

  -l [N], --load-average[=N], --max-load[=N]
                              Don't start multiple jobs unless load is below N.

In any case, patches welcome :)

Alex


On Sun, 11 Apr 2021 at 18:08, Gmane Admin <gley-yocto@m.gmane-mx.org> wrote:
Op 11-04-2021 om 17:55 schreef Alexander Kanavin:
> On Sun, 11 Apr 2021 at 17:49, Gmane Admin <gley-yocto@m.gmane-mx.org
> <mailto:gley-yocto@m.gmane-mx.org>> wrote:
>
>     Yes, and make project doesn't care, because make is called with -j
>     16 so
>     that is what it does.
>
>     So here's my pitch: bitbake can stop processes spawned by make, because
>     it knows that it started make on 4 recipies, each with -j 16. The
>     individual makes don't know about each other.
>
>
> And neither they should. They can simply abstain from spawning new
> compilers if used RAM is, say, at 90% total. Then bitbake does not have
> to get involved in babysitting those makes.
>
> Alex
Bitbake does a lot of babysitting anyway :-) And is pretty good at it too.

To me, fixing make et al. is more work and less effective then adding a
feature to bitbake. The only way to know how much memory the compiler
will use for each spawned compiler is to let it run. And then it's too late.

This memory issue is all over our eco system and nobody cares (kernel,
make etc.) The only thing moving is systemd's oom killer will arrive and
start killing processes. So that will just stop our builds from completing.

Yeah, I prefer a babysitter over a child murderer :-)

Ferry




4721 - 4740 of 57778