Date   

No UDEV events emitted

Darcy Watkins
 

Hi,

 

I am building a dunfell based system for layerscape using sysvinit as the init system and find that the eudev daemon is not emitting UDEV events.

 

udevadm monitor  --udev --kernel &

 

echo -n “remove” > /sys/devices/platform/soc/3100000.usb3/xhci-hcd.0.auto/usb2/2-1/2-1.1/uevent

 

And then I see…

KERNEL[1742.211692] remove   /devices/platform/soc/3100000.usb3/xhci-hcd.0.auto/usb2/2-1/2-1.1 (usb)

 

In my older daisy based system, I see both…

KERNEL[113501.346970] remove   /devices/platform/soc/3100000.usb3/xhci-hcd.0.auto/usb2/2-1/2-1.1 (usb)

UDEV  [113501.348373] remove   /devices/platform/soc/3100000.usb3/xhci-hcd.0.auto/usb2/2-1/2-1.1 (usb)

 

Can anyone explain why I am not seeing the UDEV events emitted?   (Is this related to using eudev rather than the original udev or what is packaged as part of systemd?)

 

Thanks in advance.

 

 

 

Regards,

 

Darcy

 

Darcy Watkins ::  Senior Staff Engineer, Firmware

 

SIERRA WIRELESS

Direct  +1 604 233 7989   ::  Fax  +1 604 231 1109  ::  Main  +1 604 231 1100

13811 Wireless Way  :: Richmond, BC Canada V6V 3A4

[M4]

dwatkins@... :: www.sierrawireless.com


Re: meta-toolchain, gdb-cross-canadian_9.2 fails due to "no usable python" #toolchain

mmiguelhorta@...
 

Thanks for the tip Raj, it got me into the right track. The error was that "Python.h" missing, but the interesting bit was the path where it was looking for it.
It was searching for it within:
(...)./recipe-sysroot/opt/my-image/my-distro-version/sysroots/(...)
while in the filesystem it existed at
(...)./recipe-sysroot/opt/my-image/3.2.1/sysroots/(...)

From that I deduced that somehow it was picking conflicting values for DISTRO_VERSION, executing the follow commands confirmed my suspicion
bitbake -e gdb-cross-canadian-arm | grep "^DISTRO"; -> DISTRO_VERSION="my-distro-version"
bitbake -e nativesdk-python3| grep "^DISTRO"; -> DISTRO_VERSION="3.2.1"

After digging a bit more I figured why it was happening, "my-distro-version" was defined through an override:
MACHINEOVERRIDES="machine"
DISTRO_VERSION_machine="my-distro-version"

However for nativesdk recipes MACHINEOVERRIDES is empty so it picked up DISTRO_VERSION as defined in poky.conf file, "3.2.1".

Dropping the override and having both DISTRO_VERSION equal solved the issue. Thanks!


Memory tracker in c++

Mauro Ziliani
 

Hi all
I'm looking for a memory track to investigate how many memory my application needs.
The application di made with Qt/Qml 5.6 over a Krogoth on Imx6dl board.

Do you have some suggestion?

I'd initialize the library in the main()
Then I run some function to get  the memory consumption

I try valgrind but it is too heavy for the poor imx

Thanks all

MZ

Sent from Mailspring, the best free email app for work


avahi_0.8 issue with latest version

sateesh m
 

Hi Guys,

 I  have installed avahi_0.8 version using gatesgreath version.  its compiled successfully .but  i am facing issue  with  pid is remove automatically when i restart my service.

 avahi configuration : hostname,domain name, allow ipv4, allow eth0,reflector =yes i did all this avahi-daemon.conf
dependencies: gtk+3,gtk,dbus,avahi-daemon,avahi-utils ,libnss-mdns.
is i miss any configuration or any patchwork work for this packages  please update me i will modify it.

( avahi-daemon[625]: Process 592 died: No such process; trying to remove PID file. (/run/avahi-daemon//pid))
               

0;1;32m*[[0m avahi-daemon.service - Avahi mDNS/DNS-SD Stack
     Loaded: loaded (/lib/systemd/system/avahi-daemon.service; enabled; vendor preset: enabled)
     Active: [[0;1;32mactive (running)[[0m since Fri 2021-03-05 13:12:17 UTC; 7min ago
TriggeredBy: [[0;1;32m*[[0m avahi-daemon.socket
   Main PID: 625 (avahi-daemon)
     Status: "avahi-daemon 0.8 starting up."
      Tasks: 2 (limit: 9561)
     Memory: 620.0K
     CGroup: /system.slice/avahi-daemon.service
             |-625 avahi-daemon: running [foo.local]
             `-626 avahi-daemon: chroot helper
 
Mar 05 13:12:17 mysystem systemd[1]: Starting Avahi mDNS/DNS-SD Stack...
Mar 05 13:12:17 mysystem avahi-daemon[625]: Process 592 died: No such process; trying to remove PID file. (/run/avahi-daemon//pid)
Mar 05 13:12:17 my system systemd[1]: Started Avahi mDNS/DNS-SD Stack.



root@mysystem:~# pgrep -f -l avahi
192 systemctl
200 systemctl
210 systemctl
216 journalctl
503 systemctl
539 systemctl
547 systemctl
559 systemctl
575 systemctl
582 systemctl
594 systemctl
625 avahi-daemon: running [foo.local]
626 avahi-daemon: chroot helper


Thanks & Regards,
Sateesh



Re: meta-toolchain, gdb-cross-canadian_9.2 fails due to "no usable python" #toolchain

Khem Raj
 

On Fri, Mar 5, 2021 at 4:01 AM <mmiguelhorta@gmail.com> wrote:

Hi,
I have been trying to build meta-toolchain however it fails to compile during gdb-cross-canadian. Follows the relevant output:

| checking for libmpfr... no
| configure: WARNING: MPFR is missing or unusable; some features may be unavailable.
| checking whether to use python... /home/.../workspace/gatesgarth/build/tmp/work/x86_64-nativesdk-pokysdk-linux/gdb-cross-canadian-arm/9.2-r0/python
| checking for python... no
| configure: error: no usable python found at /home/.../workspace/gatesgarth/build/tmp/work/x86_64-nativesdk-pokysdk-linux/gdb-cross-canadian-arm/9.2-r0/python
| make[1]: *** [Makefile:8866: configure-gdb] Error 1
there will be a file called config.log created in gdb build dir which
will have further information as to why it thing python interpreter is
not usable

My host is Ubuntu 20.04, and I'm using yocto/poky gatesgarth as base. Target core-image-minimal builds without issue, only meta-toolchain fails.
Normally I can get a good idea why something is failing from the logs, but this time I'm really left clueless. Any help would be appreciated.

BR,
Miguel


meta-toolchain, gdb-cross-canadian_9.2 fails due to "no usable python" #toolchain

mmiguelhorta@...
 

Hi,
I have been trying to build meta-toolchain however it fails to compile during gdb-cross-canadian. Follows the relevant output:

| checking for libmpfr... no
| configure: WARNING: MPFR is missing or unusable; some features may be unavailable.
| checking whether to use python... /home/.../workspace/gatesgarth/build/tmp/work/x86_64-nativesdk-pokysdk-linux/gdb-cross-canadian-arm/9.2-r0/python
| checking for python... no
| configure: error: no usable python found at /home/.../workspace/gatesgarth/build/tmp/work/x86_64-nativesdk-pokysdk-linux/gdb-cross-canadian-arm/9.2-r0/python
| make[1]: *** [Makefile:8866: configure-gdb] Error 1

My host is Ubuntu 20.04, and I'm using yocto/poky gatesgarth as base. Target core-image-minimal builds without issue, only meta-toolchain fails.
Normally I can get a good idea why something is failing from the logs, but this time I'm really left clueless. Any help would be appreciated.

BR,
Miguel


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

Changqing Li
 

ping

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)




Yocto Technical Team Minutes/Engineering Sync for Mar 2, 2021

Trevor Woerner
 

Yocto Technical Team Minutes, Engineering Sync, for Mar 2, 2021
archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit

== disclaimer ==
Best efforts are made to ensure the below is accurate and valid. However,
errors sometimes happen. If any errors or omissions are found, please feel
free to reply to this email with any corrections.

== attendees ==
Trevor Woerner, Stephen Jolly, Joshua Watt, Peter Kjellerstedt (saur),
Armin Kuster, Scott Murray, Richard Purdie, Michael Halstead, Steve
Sakoman, Paul Eggleton, Jan-Simon Möller, Saul Wold, Steve Sakoman,
Alejandro H, Bruce Ashfied, Tim Orling, Randy MacLeod, Jon Mason, Ross
Burton, Alexandre Belloni

== notes ==
- 3.2.2 and 3.1.6 released last week
- 3.3-m3 due to be built soon
- now in 3.3 feature freeze
- reproducibility improved, exclusion list significantly reduced
- various infrastructure issues (e.g. diffoscope)
- lots of old, stale patches

== general ==
RP: reproducibility: down to about 5 recipes (outside of Go) perf and ovmf
are holdouts (ovmf has a hard-coded path in it), ruby and meson have
intermittent issues (depending on build host). ruby is in ruby-docs. there
are bugzilla entries for these. about 20 of the remaining issues in the
exclusion list are related to Go. there are some sync issues
Ross: meaning?
RP: there are explicit “sync” calls in the test framework, but there are
too many, and this adds enormous I/O load which can affect issues when the
test itself does I/O work
JPEW: running diffoscope on all the output was really slow, if we can
pre-check the directories and prune them out before, it can speed it up
Ross: i tried diffoscope a while back and gave up after 5 hours
JPEW: what version?
Ross: really old
JPEW: lots of improvements, lots and lots, so just pip install the latest and
it should help
RP: found performance issues and upstream happily accepted them
JPEW: if there are 1000’s of files that are different it will just give up
after a while
RP: i was able to get diffocope to give some good results before it gave up
and that was helpful. sometimes it is able to complete, but then the
resulting HTML is huge. it takes a _long_ time for my browser to load :-/
RP: the good news is the AB is producing output in a timely manner

RP: we’re in feature freeze for 3.3, lots of stuff in master-next that i
don’t know what to do with
RP: rust isn’t in yet
Randy: still working on the bugs (a dnf issue)
Scott: if it doesn’t get in, does it block us on python3-cryptography?
Randy: yes
RP: i don’t feel like it’s ready yet. things have been rushed in in the
past with not-so-great results, i think we’ll step back on this one and
wait for it to be more stable, more tested. it should definitely get in
for the next cycle but i’m leaning towards not doing it for this release
(various): agreement on waiting
Randy: there’s an issue with the SDK related to dynamic linking, and
automating the rust compiler test cases

RP: are there any other things that need to go into 3.3? ross: debugd?
Ross: i think the debugd stuff is in master-next
RP: i think there’s some stuff related to docs that needs to be done but we
can hold off on that and fix it up later
Scott: i think PaulB has some stuff he’s trying to get in (read-only hash
equiv, read-only pr)
RP: i think i’ll wait for -m4 for that one. he started with really bad code,
so i expect it’ll take a lot of work/testing before it’s ready
RP: i’m working on making do-install become an sstate task, but getting
weird issues
RP: i did some testing on libuuid, but it blew up
PaulE: okay, i’ll poke Luka today to see what’s the status
RP: i think there’s a lurking sstate management issue, but haven’t proved
or disproved yet
PaulE: we’re not absolutely desperate for it, we can wait a release, don’t
want to cause pain
RP: sstate manifests not behaving, it’s supposed to get cleaned out, but
if there’s an overlap it seems to complain. at that point things get
cleaned up and the next build will succeed (which is probably worse)

PeterK: recipe parsing times seems to have increased significantly compared to
gatesgarth and dunfell
Randy: numbers?
PeterK: with all our layers included in the build:
45s dunfell
48s gatesgarth
1:38 master
RP: (looks at the AB at some metrics graphs (performance worker) to see if
he can see the issue) hmm.. there is definitely a noticeable jump in the
stats. hopefully easy to bisect (gives commit numbers between which the
issue jumped).
Randy: how do we translate between the data on the X-axis?
RP: that’s commits in the poky repository

Randy: any plans for the next release?
RP: just want to get through this one first
RP: i think focusing on the I/O sync issue would be great. like to see that
one sorted out

Bruce: just want to make sure that anyone doing Go stuff outside of the tree,
make sure to do world builds because some fundamental things changed that
you’ll need to fix. i think a lot of them are fetching things in the
background
RP: Go is quite nasty in the sense that it wants to be built in a specific
path and once that path is chosen that’s the place it has to be built
PeterK: i think there’s a way to set the build-id to 0 which is causing the
issue
RP: side-effects?
PeterK: we’ll have to see. bug number?
RP: 14270


Re: [meta-security][dunfell][PATCH 0/9] Some IMA/EVM fixes to dunfell branch

Armin Kuster
 

series in build testing

-armin

On 3/2/21 6:57 AM, liu.ming50@gmail.com wrote:
From: Ming Liu <ming.liu@toradex.com>

Cherry pick some IMA/EVM fixes to LTS dunfell branch, with these
patches applied, I could run a ima enabled image with sysvinit/systemd
on qemuarm/qemuarm64 and some NXP machines.

Ming Liu (9):
ima-evm-utils: set native REQUIRED_DISTRO_FEATURES to empty
initramfs-framework-ima: fix a wrong path
ima-evm-keys: add recipe
initramfs-framework-ima: RDEPENDS on ima-evm-keys
meta: refactor IMA/EVM sign rootfs
README.md: update according to the refactoring in
ima-evm-rootfs.bbclass
initramfs-framework-ima: let ima_enabled return 0
ima-evm-rootfs.bbclass: avoid generating /etc/fstab for wic
ima-policy-hashed: add CGROUP2_SUPER_MAGIC fsmagic

meta-integrity/README.md | 4 ++-
meta-integrity/classes/ima-evm-rootfs.bbclass | 33 +++++++++----------
.../initrdscripts/initramfs-framework-ima.bb | 2 +-
.../initrdscripts/initramfs-framework-ima/ima | 3 +-
.../ima-evm-keys/ima-evm-keys_1.0.bb | 16 +++++++++
.../ima-evm-utils/ima-evm-utils_git.bb | 1 +
.../ima_policy_hashed/files/ima_policy_hashed | 3 ++
7 files changed, 41 insertions(+), 21 deletions(-)
create mode 100644 meta-integrity/recipes-security/ima-evm-keys/ima-evm-keys_1.0.bb


Re: safe escape library for HTML

Randy MacLeod
 

On 2021-03-04 4:01 p.m., sswarnas@gmail.com wrote:
Hi,
Please let me know if we have recipes i can use for HTML sanitization. I want to do this sanitization in C code.
This is a rather vague question so you may not get a specific recommendation. Have you reviewed the list of html related recipes
listed by the layer index:

https://layers.openembedded.org/layerindex/branch/master/recipes/?q=html+

Let us know if you find that useful and if you find a package that
meets your needs.

../Randy

Thanks,
S

--
# Randy MacLeod
# Wind River Linux


Re: How to run the recipe Go tests on Yocto

Javier Tia
 

Found the root cause. The Go UT binaries files generated by the recipes
with ptest or generated manually need to be executed with the same ld
command from the toolchain used to build them. In this case, it is the
default GNU toolchain native provided by poky.

Thanks,

▷ Javier's 🖊

On 3/2/21 5:10 PM, Javier Tia wrote:
Hi,

Is there a way to run the recipe Go tests in Yocto?

I have tried several ways (1. Manually and 2. ptest) with unsuccess.

1. Manually exporting all the toolchain variables:

GOARCH="${BUILD_GOARCH}"
CGO_ENABLED="1"
CFLAGS="${BUILD_CFLAGS}"
LDFLAGS="${BUILD_LDFLAGS}"
CGO_CFLAGS="${BUILD_CFLAGS}"
CGO_LDFLAGS="${BUILD_LDFLAGS}"
CC="${BUILD_CC}"
LD="${BUILD_LD}"

and run it with the Go test native version.


2. Using ptest, and adding to the Go recipe:

do_compile_ptest() {
${GO} test -vet off $(go_list_package_tests)
}

In both cases the error messages are like this:

fork/exec .../recipe_name/1.0-r0/go-tmp/go-build7113/b338/util.test: no
such file or directory
FAIL util 0.000s

It's happening with Yocto Zeus (v3.0.4) and Go v1.4.17


Regards,

▷ Javier's 🖊





Re: [meta-security][PATCH] ima-policy-hashed: add CGROUP2_SUPER_MAGIC fsmagic

Armin Kuster
 

merged.
Thanks,
Armin

On 3/1/21 4:35 AM, liu.ming50@gmail.com wrote:
From: Ming Liu <liu.ming50@gmail.com>

This fixes following systemd boot issues:
[ 7.455580] systemd[1]: Failed to create /init.scope control group: Permission denied
[ 7.457677] systemd[1]: Failed to allocate manager object: Permission denied
[!!!!!!] Failed to allocate manager object.
[ 7.459270] systemd[1]: Freezing execution.

Signed-off-by: Ming Liu <liu.ming50@gmail.com>
---
.../recipes-security/ima_policy_hashed/files/ima_policy_hashed | 3 +++
1 file changed, 3 insertions(+)

diff --git a/meta-integrity/recipes-security/ima_policy_hashed/files/ima_policy_hashed b/meta-integrity/recipes-security/ima_policy_hashed/files/ima_policy_hashed
index 7f89c8d..4d9e4ca 100644
--- a/meta-integrity/recipes-security/ima_policy_hashed/files/ima_policy_hashed
+++ b/meta-integrity/recipes-security/ima_policy_hashed/files/ima_policy_hashed
@@ -53,6 +53,9 @@ dont_measure fsmagic=0x43415d53
# CGROUP_SUPER_MAGIC
dont_appraise fsmagic=0x27e0eb
dont_measure fsmagic=0x27e0eb
+# CGROUP2_SUPER_MAGIC
+dont_appraise fsmagic=0x63677270
+dont_measure fsmagic=0x63677270
# EFIVARFS_MAGIC
dont_appraise fsmagic=0xde5e81e4
dont_measure fsmagic=0xde5e81e4


safe escape library for HTML

sswarnas@...
 

Hi,

Please let me know if we have recipes i can use for HTML sanitization. I want to do this sanitization in C code.

Thanks,
S


Re: #yocto #sdk #yocto #sdk

Khem Raj
 

right, the change seems to be happening in task checksums and that happens if some of bitbake variables change when SDK is built built and when it is being installed ( when it will run parse again ) perhaps the workspace under the hood is still accessible and you can use bitbake-diffsigs to narrow it down the variable that is changing

On Thu, Mar 4, 2021 at 9:38 AM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:

 

I am seeing similar issues on line  for my eSDK install issue, but no resolutions…

 

Can someone advise on best course of action to debug this ?

 

11:10 smonsees@yix490016 /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/deploy/sdk> ./limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4.sh

LIMWS (BAE LIMWS base distro) Extensible SDK installer version 3.0.4

====================================================================

Enter target directory for SDK (default: ~/limws_sdk): /disk0/scratch/smonsees/testSDK

You are about to install the SDK to "/disk0/scratch/smonsees/testSDK". Proceed [Y/n]? Y

Extracting SDK..............................................................................done

Setting it up...

Extracting buildtools...

Preparing build system...

Parsing recipes: 100% |##########################################################################################| Time: 0:01:36

Initialising tasks: 100% |#######################################################################################| Time: 0:00:04

Checking sstate mirror object availability: 100% |###############################################################| Time: 0:00:02

WARNING: The efitools:do_compile sig is computed to be 5851605e22907038837428950427053e22ea655641a08b5dafa39d6d6e1c5e15, but the sig is locked to b81a26e3591c71acd3d22212bfdb70a15a0df49af72e7634e6a39851f16e18b5 in SIGGEN_LOCKEDSIGS_t-corei7-64

The monkeysphere:do_install sig is computed to be 13a65b26dfff91f2432a8064d98003559eafffa214d81c3c6ea112c2dfba0391, but the sig is locked to 2058fc9032b0e7f5c1ea358de4fa8d25ccec7204b73ebc636e79222d8cc00469 in SIGGEN_LOCKEDSIGS_t-corei7-64

The signature:do_compile sig is computed to be ac0c5c19cdbe7484046657ccb7b768c02fbbabb43166befa93b71a85d5fcf55b, but the sig is locked to cf5c3f72489f447b1199aafe4b4148988ff91cecd970422352f2238afb127683 in SIGGEN_LOCKEDSIGS_t-corei7-64

The grub-efi-native:do_clean_grub sig is computed to be 4e16b100c32e9428126eb10864508038527cec795c5e4391208d96a55735c90a, but the sig is locked to a2bd26be0297624af53d6f8cf657d79740fb229db821c446d564c5ee9dc80ea3 in SIGGEN_LOCKEDSIGS_t-x86-64

The grub-efi-native:do_compile sig is computed to be 630cc346f7ececf98c54f9134e8fee546e85c92f1e3c6ac3c258a1cdf24d4565, but the sig is locked to 802bba0874ce26169a9e16dcdb440795e8fa904977b036d637d6c4086ce72de8 in SIGGEN_LOCKEDSIGS_t-x86-64

The grub-efi:do_clean_grub sig is computed to be faf0ae3c9159ef3ebb13d2521ecf51dfeeac0c2c47691cd0aaa80de91187af3c, but the sig is locked to 0075bbd34297bfbc62685ff5477feec11d0dd2bcda6787a151cfb7927a7f39c2 in SIGGEN_LOCKEDSIGS_t-corei7-64

The grub-efi:do_compile sig is computed to be 30c09f3e8db4059b7e1ff23823f208be94d0e622904fc43eda497027be095a71, but the sig is locked to a9e8ddd9ecac11e67c66d9fccbabe23b6eb4a19c5996baef8ff960dfcdc898ed in SIGGEN_LOCKEDSIGS_t-corei7-64

ERROR: Task quilt-native.do_fetch attempted to execute unexpectedly

Task /disk0/scratch/smonsees/testSDK/layers/poky/meta/recipes-support/db/db_5.3.28.bb:do_populate_sysroot, unihash dcfb179ae99ac73583d33eec1357ff5d06fb58f160e5d7285061b6e1c9c3a9c0, taskhash dcfb179ae99ac73583d33eec1357ff5d06fb58f160e5d7285061b6e1c9c3a9c0

Task /disk0/scratch/smonsees/testSDK/layers/poky/meta/recipes-extended/sed/sed_4.2.2.bb:do_package_write_ipk, unihash a37dc1cc0064749d1f6de69d0a9b8eab9ff6ef4089eff28a76e1851f8f8f8fe3, taskhash a37dc1cc0064749d1f6de69d0a9b8eab9ff6ef4089eff28a76e1851f8f8f8fe3

Task /disk0/scratch/smonsees/testSDK/layers/poky/meta/recipes-support/libatomic-ops/libatomic-ops_7.6.10.bb:do_package_qa, unihash 2b17b70b3e1568840e3b39488b9e6470c89d5ffd502f02b2c129331d7609add8, taskhash 2b17b70b3e1568840e3b39488b9e6470c89d5ffd502f02b2c129331d7609add8

Task /disk0/scratch/smonsees/testSDK/layers/poky/meta/recipes-connectivity/openssh/openssh_8.0p1.bb:do_package_qa, unihash 87a24567344a646de9ab6fba50b398e41711ff4d1bca749ebe02d84359c2a155, taskhash 87a24567344a646de9ab6fba50b398e41711ff4d1bca749ebe02d84359c2a155

.

.

 

 

https://www.mail-archive.com/search?l=yocto@...&q=subject:%22Re%5C%3A+%5C%5Byocto%5C%5D+eSDK+install+script+failure%22&o=newest&f=1

 

https://www.yoctoproject.org/pipermail/yocto/2017-August/037359.html

 

https://bugzilla.yoctoproject.org/show_bug.cgi?id=12344

 

 

From: yocto@... <yocto@...> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Thursday, March 4, 2021 8:13 AM
To: Monsees, Steven C (US) <steven.monsees@...>; yocto@...
Subject: Re: [yocto] #yocto #sdk

 

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.

 

 

 

Is there a list of certain classes that might interfere with the ability of the eSDK to lock down the configuratiuon ?
 
Thanks,
Steve

 

 

From: yocto@... <yocto@...> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Tuesday, March 2, 2021 3:26 PM
To: yocto@...
Subject: [yocto] #yocto #sdk

 

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.

 

 

I still appear to be having an issue with the SXT SDK install…

 

Building for zeus/x86_64 Intel based platform…

I build my kernel image clean, fully functional…

Standard SDK builds clean and appears functional…

 

Ext SDK builds clean, but on install I am still seeing Error below…

 

(1)    What is it comparing  between unhash/task hash ?, more sig issues ?

 

(2)    What is meant by “This is usually due to missing setscene tasks” ?

 

(3)    In the local.conf under the SDK they set :

 

SSTATE_MIRRORS += " file://universal/(.*) file://universal-4.9/\1 file://universal-4.9/(.*) file://universal-4.8/\1"

 

Under sdk-extra.conf I set :

 

SSTATE_MIRRORS += file://.* file:///ede/tms/yocto/zeus/sstate_cache/PATH

 

My SSTATE_MIRRIOR is based off the clean builds I mentioned above, is this the correct procedure ?

 

I am trying to figure out how best to debug this issue, it is occurring on the post install, and everything pretty much appears in place.

 

Steve

 

14:43 smonsees@yix490038 /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/deploy/sdk>./limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4.sh

LIMWS (BAE LIMWS base distro) Extensible SDK installer version 3.0.4

====================================================================

Enter target directory for SDK (default: ~/limws_sdk): /disk0/scratch/smonsees/testSDK

You are about to install the SDK to "/disk0/scratch/smonsees/testSDK". Proceed [Y/n]? Y

Extracting SDK..............................................................................done

Setting it up...

Extracting buildtools...

Preparing build system...

Parsing recipes: 100% |###########################################################################################| Time: 0:01:32

Initialising tasks: 100% |########################################################################################| Time: 0:00:04

Checking sstate mirror object availability: 100% |################################################################| Time: 0:00:03

ERROR: Task quilt-native.do_fetch attempted to execute unexpectedly

Task /disk0/scratch/smonsees/testSDK/layers/poky/meta/recipes-support/liburcu/liburcu_0.11.1.bb:do_populate_sysroot, unihash cdb08644b85fa162bd9f88cb00113fe3193cc347e39e33e8f405f9c23f60c601, taskhash cdb08644b85fa162bd9f88cb00113fe3193cc347e39e33e8f405f9c23f60c601

Task /disk0/scratch/smonsees/testSDK/layers/poky/meta/recipes-devtools/python/python3_3.7.8.bb:do_packagedata, unihash 925a72cbe872aad09bd3fbbe74ed1c944e9c19a732e120feae5c4784e6330d4f, taskhash 925a72cbe872aad09bd3fbbe74ed1c944e9c19a732e120feae5c4784e6330d4f

.

.

.

 

This is usually due to missing setscene tasks. Those missing in this build were:

 

<<appears to list every recipe under ./testSDK/layers directory here>>





Re: cc1 binary in final rootfs even when no reference to it

Khem Raj
 

On Thu, Mar 4, 2021 at 10:04 AM Anders Montonen <Anders.Montonen@iki.fi> wrote:

On 4.3.2021 2.06, Khem Raj wrote:
On 3/3/21 11:29 AM, Belisko Marek wrote:
On Wed, Mar 3, 2021 at 6:31 PM Khem Raj <raj.khem@gmail.com> wrote:

this file comes from cpp output package. Can you check if somehow cpp
is being pulled into your image
It turns out that cpp + cpp-symlinks is pulled by python3-pycparser.
It is really necessary to be as runtime dependency in recipe?
it a parser for C language written in python, so my initial thoughts
will be no. but there might be some dependencies on cpp, you might
have to dive a bit deeper.

I've run into this, and from memory cpp is needed if you intend to run
the parser, but since the dependency is added through
RDEPENDS_${PN}_class-target it gets installed even if you're only
running the parser on the host. I ended up removing the target
dependency due to license conflicts, and didn't encounter any problems.
right perhaps its fine to drop this and maybe add it as rsuggests or something

-anders




Re: cc1 binary in final rootfs even when no reference to it

Anders Montonen
 

On 4.3.2021 2.06, Khem Raj wrote:
On 3/3/21 11:29 AM, Belisko Marek wrote:
On Wed, Mar 3, 2021 at 6:31 PM Khem Raj <raj.khem@gmail.com> wrote:

this file comes from cpp output package. Can you check if somehow cpp
is being pulled into your image
It turns out that cpp + cpp-symlinks is pulled by python3-pycparser.
It is really necessary to be as runtime dependency in recipe?
it a parser for C language written in python, so my initial thoughts will be no. but there might be some dependencies on cpp, you might have to dive a bit deeper.

I've run into this, and from memory cpp is needed if you intend to run the parser, but since the dependency is added through RDEPENDS_${PN}_class-target it gets installed even if you're only running the parser on the host. I ended up removing the target dependency due to license conflicts, and didn't encounter any problems.

-anders


Re: #yocto #sdk #yocto #sdk

Monsees, Steven C (US)
 

Nope, just validated...

I build the my kernel image clean and the eSDK image right after, cache should be good, no ?

Not sure how to go about resolving... it occurs on the back end of the eSDK installation. I can actually go to the install and build the kernel image under the umbrella of the eSDK and it builds/runs correctly...

-----Original Message-----
From: yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> On Behalf Of Khem Raj
Sent: Thursday, March 4, 2021 12:18 PM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com>; yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto #sdk

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros. For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.


if you have AUTOREVs e.g. can be problematic, and also using TIME/DATE in recipes which can interfere

On 3/4/21 5:13 AM, Monsees, Steven C (US) via lists.yoctoproject.org wrote:
Is there a list of certain classes that might interfere with the
ability of the eSDK to lock down the configuratiuon ?

Thanks,

Steve

*From:* yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org>
*On Behalf Of *Monsees, Steven C (US) via lists.yoctoproject.org
*Sent:* Tuesday, March 2, 2021 3:26 PM
*To:* yocto@lists.yoctoproject.org
*Subject:* [yocto] #yocto #sdk

*_External Email Alert_*

*This email has been sent from an account outside of the BAE Systems
network.*

Please treat the email with caution, especially if you are requested
to click on a link, decrypt/open an attachment, or enable macros.  For
further information on how to spot phishing, access “Cybersecurity
OneSpace Page” and report phishing by clicking the button “Report
Phishing” on the Outlook toolbar.

I still appear to be having an issue with the SXT SDK install…

Building for zeus/x86_64 Intel based platform…

I build my kernel image clean, fully functional…

Standard SDK builds clean and appears functional…

Ext SDK builds clean, but on install I am still seeing Error below…

(1)What is it comparing  between unhash/task hash ?, more sig issues ?

(2)What is meant by “This is usually due to missing setscene tasks” ?

(3)In the local.conf under the SDK they set :

SSTATE_MIRRORS += " file://universal/(.*) <file://universal/(.*)>
file://universal-4.9/\1 <file://universal-4.9/1>
file://universal-4.9/(.*) <file://universal-4.9/(.*)>
file://universal-4.8/\1 <file://universal-4.8/1>"

Under sdk-extra.conf I set :

SSTATE_MIRRORS += file://.*
file:///ede/tms/yocto/zeus/sstate_cache/PATH
<file://.*%20file:/ede/tms/yocto/zeus/sstate_cache/PATH>

My SSTATE_MIRRIOR is based off the clean builds I mentioned above, is
this the correct procedure ?

I am trying to figure out how best to debug this issue, it is
occurring on the post install, and everything pretty much appears in place.

Steve

14:43 smonsees@yix490038
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/dep
loy/sdk>./limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4
.sh

LIMWS (BAE LIMWS base distro) Extensible SDK installer version 3.0.4

====================================================================

Enter target directory for SDK (default: ~/limws_sdk):
/disk0/scratch/smonsees/testSDK

You are about to install the SDK to "/disk0/scratch/smonsees/testSDK".
Proceed [Y/n]? Y

Extracting
SDK...................................................................
...........done

Setting it up...

Extracting buildtools...

Preparing build system...

Parsing recipes: 100%
|#####################################################################
|######################|
Time: 0:01:32

Initialising tasks: 100%
|#####################################################################
|###################|
Time: 0:00:04

Checking sstate mirror object availability: 100%
|################################################################| Time:
0:00:03

ERROR: Task quilt-native.do_fetch attempted to execute unexpectedly

Task
/disk0/scratch/smonsees/testSDK/layers/poky/meta/recipes-support/libur
cu/liburcu_0.11.1.bb:do_populate_sysroot,
unihash
cdb08644b85fa162bd9f88cb00113fe3193cc347e39e33e8f405f9c23f60c601,
taskhash
cdb08644b85fa162bd9f88cb00113fe3193cc347e39e33e8f405f9c23f60c601

Task
/disk0/scratch/smonsees/testSDK/layers/poky/meta/recipes-devtools/pyth
on/python3_3.7.8.bb:do_packagedata,
unihash
925a72cbe872aad09bd3fbbe74ed1c944e9c19a732e120feae5c4784e6330d4f,
taskhash
925a72cbe872aad09bd3fbbe74ed1c944e9c19a732e120feae5c4784e6330d4f

.

.

.

This is usually due to missing setscene tasks. Those missing in this
build were:

<<appears to list every recipe under ./testSDK/layers directory here>>





Re: #yocto #sdk #yocto #sdk

Monsees, Steven C (US)
 

 

I am seeing similar issues on line  for my eSDK install issue, but no resolutions…

 

Can someone advise on best course of action to debug this ?

 

11:10 smonsees@yix490016 /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/deploy/sdk> ./limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4.sh

LIMWS (BAE LIMWS base distro) Extensible SDK installer version 3.0.4

====================================================================

Enter target directory for SDK (default: ~/limws_sdk): /disk0/scratch/smonsees/testSDK

You are about to install the SDK to "/disk0/scratch/smonsees/testSDK". Proceed [Y/n]? Y

Extracting SDK..............................................................................done

Setting it up...

Extracting buildtools...

Preparing build system...

Parsing recipes: 100% |##########################################################################################| Time: 0:01:36

Initialising tasks: 100% |#######################################################################################| Time: 0:00:04

Checking sstate mirror object availability: 100% |###############################################################| Time: 0:00:02

WARNING: The efitools:do_compile sig is computed to be 5851605e22907038837428950427053e22ea655641a08b5dafa39d6d6e1c5e15, but the sig is locked to b81a26e3591c71acd3d22212bfdb70a15a0df49af72e7634e6a39851f16e18b5 in SIGGEN_LOCKEDSIGS_t-corei7-64

The monkeysphere:do_install sig is computed to be 13a65b26dfff91f2432a8064d98003559eafffa214d81c3c6ea112c2dfba0391, but the sig is locked to 2058fc9032b0e7f5c1ea358de4fa8d25ccec7204b73ebc636e79222d8cc00469 in SIGGEN_LOCKEDSIGS_t-corei7-64

The signature:do_compile sig is computed to be ac0c5c19cdbe7484046657ccb7b768c02fbbabb43166befa93b71a85d5fcf55b, but the sig is locked to cf5c3f72489f447b1199aafe4b4148988ff91cecd970422352f2238afb127683 in SIGGEN_LOCKEDSIGS_t-corei7-64

The grub-efi-native:do_clean_grub sig is computed to be 4e16b100c32e9428126eb10864508038527cec795c5e4391208d96a55735c90a, but the sig is locked to a2bd26be0297624af53d6f8cf657d79740fb229db821c446d564c5ee9dc80ea3 in SIGGEN_LOCKEDSIGS_t-x86-64

The grub-efi-native:do_compile sig is computed to be 630cc346f7ececf98c54f9134e8fee546e85c92f1e3c6ac3c258a1cdf24d4565, but the sig is locked to 802bba0874ce26169a9e16dcdb440795e8fa904977b036d637d6c4086ce72de8 in SIGGEN_LOCKEDSIGS_t-x86-64

The grub-efi:do_clean_grub sig is computed to be faf0ae3c9159ef3ebb13d2521ecf51dfeeac0c2c47691cd0aaa80de91187af3c, but the sig is locked to 0075bbd34297bfbc62685ff5477feec11d0dd2bcda6787a151cfb7927a7f39c2 in SIGGEN_LOCKEDSIGS_t-corei7-64

The grub-efi:do_compile sig is computed to be 30c09f3e8db4059b7e1ff23823f208be94d0e622904fc43eda497027be095a71, but the sig is locked to a9e8ddd9ecac11e67c66d9fccbabe23b6eb4a19c5996baef8ff960dfcdc898ed in SIGGEN_LOCKEDSIGS_t-corei7-64

ERROR: Task quilt-native.do_fetch attempted to execute unexpectedly

Task /disk0/scratch/smonsees/testSDK/layers/poky/meta/recipes-support/db/db_5.3.28.bb:do_populate_sysroot, unihash dcfb179ae99ac73583d33eec1357ff5d06fb58f160e5d7285061b6e1c9c3a9c0, taskhash dcfb179ae99ac73583d33eec1357ff5d06fb58f160e5d7285061b6e1c9c3a9c0

Task /disk0/scratch/smonsees/testSDK/layers/poky/meta/recipes-extended/sed/sed_4.2.2.bb:do_package_write_ipk, unihash a37dc1cc0064749d1f6de69d0a9b8eab9ff6ef4089eff28a76e1851f8f8f8fe3, taskhash a37dc1cc0064749d1f6de69d0a9b8eab9ff6ef4089eff28a76e1851f8f8f8fe3

Task /disk0/scratch/smonsees/testSDK/layers/poky/meta/recipes-support/libatomic-ops/libatomic-ops_7.6.10.bb:do_package_qa, unihash 2b17b70b3e1568840e3b39488b9e6470c89d5ffd502f02b2c129331d7609add8, taskhash 2b17b70b3e1568840e3b39488b9e6470c89d5ffd502f02b2c129331d7609add8

Task /disk0/scratch/smonsees/testSDK/layers/poky/meta/recipes-connectivity/openssh/openssh_8.0p1.bb:do_package_qa, unihash 87a24567344a646de9ab6fba50b398e41711ff4d1bca749ebe02d84359c2a155, taskhash 87a24567344a646de9ab6fba50b398e41711ff4d1bca749ebe02d84359c2a155

.

.

 

 

https://www.mail-archive.com/search?l=yocto@...&q=subject:%22Re%5C%3A+%5C%5Byocto%5C%5D+eSDK+install+script+failure%22&o=newest&f=1

 

https://www.yoctoproject.org/pipermail/yocto/2017-August/037359.html

 

https://bugzilla.yoctoproject.org/show_bug.cgi?id=12344

 

 

From: yocto@... <yocto@...> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Thursday, March 4, 2021 8:13 AM
To: Monsees, Steven C (US) <steven.monsees@...>; yocto@...
Subject: Re: [yocto] #yocto #sdk

 

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.

 

 

 

Is there a list of certain classes that might interfere with the ability of the eSDK to lock down the configuratiuon ?
 
Thanks,
Steve

 

 

From: yocto@... <yocto@...> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Tuesday, March 2, 2021 3:26 PM
To: yocto@...
Subject: [yocto] #yocto #sdk

 

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.

 

 

I still appear to be having an issue with the SXT SDK install…

 

Building for zeus/x86_64 Intel based platform…

I build my kernel image clean, fully functional…

Standard SDK builds clean and appears functional…

 

Ext SDK builds clean, but on install I am still seeing Error below…

 

(1)    What is it comparing  between unhash/task hash ?, more sig issues ?

 

(2)    What is meant by “This is usually due to missing setscene tasks” ?

 

(3)    In the local.conf under the SDK they set :

 

SSTATE_MIRRORS += " file://universal/(.*) file://universal-4.9/\1 file://universal-4.9/(.*) file://universal-4.8/\1"

 

Under sdk-extra.conf I set :

 

SSTATE_MIRRORS += file://.* file:///ede/tms/yocto/zeus/sstate_cache/PATH

 

My SSTATE_MIRRIOR is based off the clean builds I mentioned above, is this the correct procedure ?

 

I am trying to figure out how best to debug this issue, it is occurring on the post install, and everything pretty much appears in place.

 

Steve

 

14:43 smonsees@yix490038 /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/deploy/sdk>./limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4.sh

LIMWS (BAE LIMWS base distro) Extensible SDK installer version 3.0.4

====================================================================

Enter target directory for SDK (default: ~/limws_sdk): /disk0/scratch/smonsees/testSDK

You are about to install the SDK to "/disk0/scratch/smonsees/testSDK". Proceed [Y/n]? Y

Extracting SDK..............................................................................done

Setting it up...

Extracting buildtools...

Preparing build system...

Parsing recipes: 100% |###########################################################################################| Time: 0:01:32

Initialising tasks: 100% |########################################################################################| Time: 0:00:04

Checking sstate mirror object availability: 100% |################################################################| Time: 0:00:03

ERROR: Task quilt-native.do_fetch attempted to execute unexpectedly

Task /disk0/scratch/smonsees/testSDK/layers/poky/meta/recipes-support/liburcu/liburcu_0.11.1.bb:do_populate_sysroot, unihash cdb08644b85fa162bd9f88cb00113fe3193cc347e39e33e8f405f9c23f60c601, taskhash cdb08644b85fa162bd9f88cb00113fe3193cc347e39e33e8f405f9c23f60c601

Task /disk0/scratch/smonsees/testSDK/layers/poky/meta/recipes-devtools/python/python3_3.7.8.bb:do_packagedata, unihash 925a72cbe872aad09bd3fbbe74ed1c944e9c19a732e120feae5c4784e6330d4f, taskhash 925a72cbe872aad09bd3fbbe74ed1c944e9c19a732e120feae5c4784e6330d4f

.

.

.

 

This is usually due to missing setscene tasks. Those missing in this build were:

 

<<appears to list every recipe under ./testSDK/layers directory here>>


Re: #yocto #sdk #yocto #sdk

Khem Raj
 

if you have AUTOREVs e.g. can be problematic, and also using TIME/DATE in recipes which can interfere

On 3/4/21 5:13 AM, Monsees, Steven C (US) via lists.yoctoproject.org wrote:
Is there a list of certain classes that might interfere with the ability of the eSDK to lock down the configuratiuon ?
Thanks,
Steve
*From:* yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> *On Behalf Of *Monsees, Steven C (US) via lists.yoctoproject.org
*Sent:* Tuesday, March 2, 2021 3:26 PM
*To:* yocto@lists.yoctoproject.org
*Subject:* [yocto] #yocto #sdk
*_External Email Alert_*
*This email has been sent from an account outside of the BAE Systems network.*
Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.
I still appear to be having an issue with the SXT SDK install…
Building for zeus/x86_64 Intel based platform…
I build my kernel image clean, fully functional…
Standard SDK builds clean and appears functional…
Ext SDK builds clean, but on install I am still seeing Error below…
(1)What is it comparing  between unhash/task hash ?, more sig issues ?
(2)What is meant by “This is usually due to missing setscene tasks” ?
(3)In the local.conf under the SDK they set :
SSTATE_MIRRORS += " file://universal/(.*) <file://universal/(.*)> file://universal-4.9/\1 <file://universal-4.9/1> file://universal-4.9/(.*) <file://universal-4.9/(.*)> file://universal-4.8/\1 <file://universal-4.8/1>"
Under sdk-extra.conf I set :
SSTATE_MIRRORS += file://.* file:///ede/tms/yocto/zeus/sstate_cache/PATH <file://.*%20file:/ede/tms/yocto/zeus/sstate_cache/PATH>
My SSTATE_MIRRIOR is based off the clean builds I mentioned above, is this the correct procedure ?
I am trying to figure out how best to debug this issue, it is occurring on the post install, and everything pretty much appears in place.
Steve
14:43 smonsees@yix490038 /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/deploy/sdk>./limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4.sh
LIMWS (BAE LIMWS base distro) Extensible SDK installer version 3.0.4
====================================================================
Enter target directory for SDK (default: ~/limws_sdk): /disk0/scratch/smonsees/testSDK
You are about to install the SDK to "/disk0/scratch/smonsees/testSDK". Proceed [Y/n]? Y
Extracting SDK..............................................................................done
Setting it up...
Extracting buildtools...
Preparing build system...
Parsing recipes: 100% |###########################################################################################| Time: 0:01:32
Initialising tasks: 100% |########################################################################################| Time: 0:00:04
Checking sstate mirror object availability: 100% |################################################################| Time: 0:00:03
ERROR: Task quilt-native.do_fetch attempted to execute unexpectedly
Task /disk0/scratch/smonsees/testSDK/layers/poky/meta/recipes-support/liburcu/liburcu_0.11.1.bb:do_populate_sysroot, unihash cdb08644b85fa162bd9f88cb00113fe3193cc347e39e33e8f405f9c23f60c601, taskhash cdb08644b85fa162bd9f88cb00113fe3193cc347e39e33e8f405f9c23f60c601
Task /disk0/scratch/smonsees/testSDK/layers/poky/meta/recipes-devtools/python/python3_3.7.8.bb:do_packagedata, unihash 925a72cbe872aad09bd3fbbe74ed1c944e9c19a732e120feae5c4784e6330d4f, taskhash 925a72cbe872aad09bd3fbbe74ed1c944e9c19a732e120feae5c4784e6330d4f
.
.
.
This is usually due to missing setscene tasks. Those missing in this build were:
<<appears to list every recipe under ./testSDK/layers directory here>>


[auh][PATCH] auh: Add port 465 and 587 client support

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@gmai.com>
---
modules/utils/emailhandler.py | 23 +++++++++++++++++++++--
upgrade-helper.conf | 3 +++
2 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/modules/utils/emailhandler.py b/modules/utils/emailhandler.py
index 8c8b85b..a70bf23 100644
--- a/modules/utils/emailhandler.py
+++ b/modules/utils/emailhandler.py
@@ -27,7 +27,7 @@ import os
import logging as log
from logging import error as E
from logging import info as I
-from smtplib import SMTP
+from smtplib import SMTP, SMTP_SSL
import mimetypes
from email.mime.text import MIMEText
from email.mime.base import MIMEBase
@@ -35,12 +35,14 @@ from email.mime.multipart import MIMEMultipart
from email.generator import Generator
import shutil
from io import StringIO
+import ssl

class Email(object):
def __init__(self, settings):
self.smtp_host = None
self.smtp_port = None
self.from_addr = None
+ self.from_addr_pswd = None
if "smtp" in settings:
smtp_entry = settings["smtp"].split(":")
if len(smtp_entry) == 1:
@@ -57,6 +59,13 @@ class Email(object):
else:
E(" 'From' address not set! Sending emails disabled!")

+ if "email_client_pswd" in settings:
+ self.from_addr_pswd = settings["email_client_pswd"]
+
+ if self.smtp_port != '25':
+ if self.from_addr_pswd == None:
+ E(" Port %s needs a password, None set!" % self.smtp_port)
+
super(Email, self).__init__()

def send_email(self, to_addr, subject, text, files=[], cc_addr=None):
@@ -101,7 +110,17 @@ class Email(object):
msg_text = out.getvalue()

try:
- smtp = SMTP(self.smtp_host, self.smtp_port)
+ if self.smtp_port == '465':
+ smtp = SMTP_SSL(self.smtp_host, self.smtp_port)
+ smtp.login(self.from_addr, self.from_addr_pswd)
+ else:
+ smtp = SMTP(self.smtp_host, self.smtp_port)
+ if self.smtp_port == '587':
+ smtp.ehlo()
+ smtp.starttls(context=ssl.create_default_context())
+ smtp.ehlo()
+ smtp.login(self.from_addr, self.from_addr_pswd)
+
smtp.sendmail(self.from_addr, to_addr, msg_text)
if cc_addr is not None:
smtp.sendmail(self.from_addr, cc_addr, msg_text)
diff --git a/upgrade-helper.conf b/upgrade-helper.conf
index 5696564..3a5b3db 100644
--- a/upgrade-helper.conf
+++ b/upgrade-helper.conf
@@ -25,6 +25,9 @@
# If no port is specified, port 25 is assumed.
#smtp=smtp.my-server.com:25

+# Define a password needed to contect to email server
+#email_client_pswd=
+
# from whom should the e-mails be sent (mandatory if --send-emails is passed).
# Also sets the email address of the author of automated commits.
#from=uh@not.set
--
2.17.1

2881 - 2900 of 55442