Drop backport patches:
0001-apparmor-fix-manpage-order.patch
0001-libapparmor-add-missing-include-for-socklen_t.patch
0002-libapparmor-add-aa_features_new_from_file-to-public-.patch
0003-libapparmor-add-_aa_asprintf-to-private-symbols.patch
0001-aa_status-Fix-build-issue-with-musl.patch
0001-parser-Makefile-dont-force-host-cpp-to-detect-reallo.patch

Signed-off-by: Yi Zhao <yi.zhao@...>
---
.../{apparmor_3.0.bb => apparmor_3.0.1.bb} | 8 +---
...Update-make-check-to-select-tools-ba.patch | 2 +-
...-aa_status-Fix-build-issue-with-musl.patch | 31 -------------
.../0001-apparmor-fix-manpage-order.patch | 43 -------------------
...or-add-missing-include-for-socklen_t.patch | 36 ----------------
...dont-force-host-cpp-to-detect-reallo.patch | 37 ----------------
...aa_features_new_from_file-to-public-.patch | 37 ----------------
...-add-_aa_asprintf-to-private-symbols.patch | 34 ---------------
recipes-mac/AppArmor/files/disable_pdf.patch | 33 --------------
9 files changed, 2 insertions(+), 259 deletions(-)
rename recipes-mac/AppArmor/{apparmor_3.0.bb => apparmor_3.0.1.bb} (92%)
delete mode 100644 recipes-mac/AppArmor/files/0001-aa_status-Fix-build-issue-with-musl.patch
delete mode 100644 recipes-mac/AppArmor/files/0001-apparmor-fix-manpage-order.patch
delete mode 100644 recipes-mac/AppArmor/files/0001-libapparmor-add-missing-include-for-socklen_t.patch
delete mode 100644 recipes-mac/AppArmor/files/0001-parser-Makefile-dont-force-host-cpp-to-detect-reallo.patch
delete mode 100644 recipes-mac/AppArmor/files/0002-libapparmor-add-aa_features_new_from_file-to-public-.patch
delete mode 100644 recipes-mac/AppArmor/files/0003-libapparmor-add-_aa_asprintf-to-private-symbols.patch
delete mode 100644 recipes-mac/AppArmor/files/disable_pdf.patch

diff --git a/recipes-mac/AppArmor/apparmor_3.0.bb b/recipes-mac/AppArmor/apparmor_3.0.1.bb
similarity index 92%
rename from recipes-mac/AppArmor/apparmor_3.0.bb
rename to recipes-mac/AppArmor/apparmor_3.0.1.bb
index d9c3e4d..6377683 100644
--- a/recipes-mac/AppArmor/apparmor_3.0.bb
+++ b/recipes-mac/AppArmor/apparmor_3.0.1.bb
@@ -23,16 +23,10 @@ SRC_URI = " \
file://apparmor.service \
file://0001-Makefile.am-suppress-perllocal.pod.patch \
file://run-ptest \
- file://0001-apparmor-fix-manpage-order.patch \
file://0001-Revert-profiles-Update-make-check-to-select-tools-ba.patch \
- file://0001-libapparmor-add-missing-include-for-socklen_t.patch \
- file://0002-libapparmor-add-aa_features_new_from_file-to-public-.patch \
- file://0003-libapparmor-add-_aa_asprintf-to-private-symbols.patch \
- file://0001-aa_status-Fix-build-issue-with-musl.patch \
- file://0001-parser-Makefile-dont-force-host-cpp-to-detect-reallo.patch \
"

-SRCREV = "5d51483bfecf556183558644dc8958135397a7e2"
+SRCREV = "b0f08aa9d678197b8e3477c2fbff790f50a1de5e"
S = "${WORKDIR}/git"

PARALLEL_MAKE = ""
diff --git a/recipes-mac/AppArmor/files/0001-Revert-profiles-Update-make-check-to-select-tools-ba.patch b/recipes-mac/AppArmor/files/0001-Revert-profiles-Update-make-check-to-select-tools-ba.patch
index 791437d..e7abd60 100644
--- a/recipes-mac/AppArmor/files/0001-Revert-profiles-Update-make-check-to-select-tools-ba.patch
+++ b/recipes-mac/AppArmor/files/0001-Revert-profiles-Update-make-check-to-select-tools-ba.patch
@@ -6,7 +6,7 @@ Subject: [PATCH] Revert "profiles: Update 'make check' to select tools based

This reverts commit 6016f931ebf7b61e1358f19453ef262d9d184a4e.

-Upstream-Statue: OE specific
+Upstream-Status: Inappropriate [OE specific]
These changes cause during packaging with perms changing.

Signed-off-by: Armin Kuster <akuster808@...>
diff --git a/recipes-mac/AppArmor/files/0001-aa_status-Fix-build-issue-with-musl.patch b/recipes-mac/AppArmor/files/0001-aa_status-Fix-build-issue-with-musl.patch
deleted file mode 100644
index 239562a..0000000
--- a/recipes-mac/AppArmor/files/0001-aa_status-Fix-build-issue-with-musl.patch
+++ /dev/null
@@ -1,31 +0,0 @@
-From 2bf15cc68f31c9f41962bb60a669ab2b453a039b Mon Sep 17 00:00:00 2001
-From: Armin Kuster <akuster808@...>
-Date: Wed, 7 Oct 2020 08:27:11 -0700
-Subject: [PATCH] aa_status: Fix build issue with musl
-
-add limits.h
-
-aa_status.c:269:22: error: 'PATH_MAX' undeclared (first use in this function); did you mean 'AF_MAX'?
-| 269 | real_exe = calloc(PATH_MAX + 1, sizeof(char));
-
-Upstream-Status: Pending
-Signed-off-by: Armin Kuster <akuster808@...>
----
- binutils/aa_status.c | 1 +
- 1 file changed, 1 insertion(+)
-
-diff --git a/binutils/aa_status.c b/binutils/aa_status.c
-index 78b03409..41f1954e 100644
---- a/binutils/aa_status.c
-+++ b/binutils/aa_status.c
-@@ -10,6 +10,7 @@
- #include <stdio.h>
- #include <stdlib.h>
- #include <string.h>
-+#include <limits.h>
- #include <sys/types.h>
- #include <sys/stat.h>
- #include <sys/wait.h>
---
-2.17.1
-
diff --git a/recipes-mac/AppArmor/files/0001-apparmor-fix-manpage-order.patch b/recipes-mac/AppArmor/files/0001-apparmor-fix-manpage-order.patch
deleted file mode 100644
index 9f3dce4..0000000
--- a/recipes-mac/AppArmor/files/0001-apparmor-fix-manpage-order.patch
+++ /dev/null
@@ -1,43 +0,0 @@
-From c9baef0c70122e1be33b627874772e6e9a5d7744 Mon Sep 17 00:00:00 2001
-From: Armin Kuster <akuster808@...>
-Date: Fri, 2 Oct 2020 19:43:44 -0700
-Subject: [PATCH] apparmor: fix manpage order
-
-It trys to create a symlink before the man pages are installed.
-
- ln -sf aa-status.8 /(path}/apparmor/3.0-r0/image/usr/share/man/man8/apparmor_status.8
- | ln: failed to create symbolic link '{path}/apparmor/3.0-r0/image/usr/share/man/man8/apparmor_status.8': No such file or directory
-
-Upstream-Status: Pending
-Signed-off-by: Armin Kuster <akuster808@...>
-
-...
-
-install -d /{path}/apparmor/3.0-r0/image/usr/share/man/man8 ; install -m 644 aa-status.8 /{path}/apparmor/3.0-r0/image/usr/share/man/man8;
-
-Signed-off-by: Armin Kuster <akuster@...>
----
- binutils/Makefile | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/binutils/Makefile b/binutils/Makefile
-index 99e54875..3f1d0011 100644
---- a/binutils/Makefile
-+++ b/binutils/Makefile
-@@ -156,12 +156,12 @@ install-arch: arch
- install -m 755 -d ${SBINDIR}
- ln -sf aa-status ${SBINDIR}/apparmor_status
- install -m 755 ${SBINTOOLS} ${SBINDIR}
-- ln -sf aa-status.8 ${DESTDIR}/${MANDIR}/man8/apparmor_status.8
-
- .PHONY: install-indep
- install-indep: indep
- $(MAKE) -C po install NAME=${NAME} DESTDIR=${DESTDIR}
- $(MAKE) install_manpages DESTDIR=${DESTDIR}
-+ ln -sf aa-status.8 ${DESTDIR}/${MANDIR}/man8/apparmor_status.8
-
- ifndef VERBOSE
- .SILENT: clean
---
-2.17.1
-
diff --git a/recipes-mac/AppArmor/files/0001-libapparmor-add-missing-include-for-socklen_t.patch b/recipes-mac/AppArmor/files/0001-libapparmor-add-missing-include-for-socklen_t.patch
deleted file mode 100644
index 2a56d8b..0000000
--- a/recipes-mac/AppArmor/files/0001-libapparmor-add-missing-include-for-socklen_t.patch
+++ /dev/null
@@ -1,36 +0,0 @@
-From 47263a3a74d7973e7a54b17db6aa903701468ffd Mon Sep 17 00:00:00 2001
-From: Patrick Steinhardt <ps@...>
-Date: Sat, 3 Oct 2020 20:37:55 +0200
-Subject: [PATCH] libapparmor: add missing include for `socklen_t`
-
-While `include/sys/apparmor.h` makes use of `socklen_t`, it doesn't
-include the `<sys/socket.h>` header to make its declaration available.
-While this works on systems using glibc via transitive includes, it
-breaks compilation on musl libc.
-
-Fix the issue by including the header.
-
-Signed-off-by: Patrick Steinhardt <ps@...>
-
-Upstream-Status: Backport
-Signed-off-by: Armin Kuster <akuster808@...>
-
----
- libraries/libapparmor/include/sys/apparmor.h | 1 +
- 1 file changed, 1 insertion(+)
-
-diff --git a/libraries/libapparmor/include/sys/apparmor.h b/libraries/libapparmor/include/sys/apparmor.h
-index 32892d06..d70eff94 100644
---- a/libraries/libapparmor/include/sys/apparmor.h
-+++ b/libraries/libapparmor/include/sys/apparmor.h
-@@ -21,6 +21,7 @@
- #include <stdbool.h>
- #include <stdint.h>
- #include <unistd.h>
-+#include <sys/socket.h>
- #include <sys/types.h>
-
- #ifdef __cplusplus
---
-2.17.1
-
diff --git a/recipes-mac/AppArmor/files/0001-parser-Makefile-dont-force-host-cpp-to-detect-reallo.patch b/recipes-mac/AppArmor/files/0001-parser-Makefile-dont-force-host-cpp-to-detect-reallo.patch
deleted file mode 100644
index 9f7ad3c..0000000
--- a/recipes-mac/AppArmor/files/0001-parser-Makefile-dont-force-host-cpp-to-detect-reallo.patch
+++ /dev/null
@@ -1,37 +0,0 @@
-From 965bb9c3e464f756b258a7c259a92bce3cde74e7 Mon Sep 17 00:00:00 2001
-From: Armin Kuster <akuster@...>
-Date: Wed, 7 Oct 2020 20:50:38 -0700
-Subject: [PATCH] parser/Makefile: dont force host cpp to detect reallocarray
-
-In cross build environments, using the hosts cpp gives incorrect
-detection of reallocarray. Change cpp to a variable.
-
-fixes:
-parser_misc.c: In function 'int capable_add_cap(const char*, int, unsigned int, capability_flags)':
-| parser_misc.c:297:37: error: 'reallocarray' was not declared in this scope
-| 297 | tmp = (struct capability_table *) reallocarray(cap_table, sizeof(struct capability_table), cap_table_size+1);
-
-Signed-off-by: Armin Kuster <akuster808@...>
-
-Upstream-Status: Pending
-
----
- parser/Makefile | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/parser/Makefile b/parser/Makefile
-index acef3d77..8250ac45 100644
---- a/parser/Makefile
-+++ b/parser/Makefile
-@@ -54,7 +54,7 @@ endif
- CPPFLAGS += -D_GNU_SOURCE
-
- STDLIB_INCLUDE:="\#include <stdlib.h>"
--HAVE_REALLOCARRAY:=$(shell echo $(STDLIB_INCLUDE) | cpp ${CPPFLAGS} | grep -q reallocarray && echo true)
-+HAVE_REALLOCARRAY:=$(shell echo $(STDLIB_INCLUDE) | ${CPP} ${CPPFLAGS} | grep -q reallocarray && echo true)
-
- WARNINGS = -Wall
- CXX_WARNINGS = ${WARNINGS} ${EXTRA_WARNINGS}
---
-2.17.1
-
diff --git a/recipes-mac/AppArmor/files/0002-libapparmor-add-aa_features_new_from_file-to-public-.patch b/recipes-mac/AppArmor/files/0002-libapparmor-add-aa_features_new_from_file-to-public-.patch
deleted file mode 100644
index 333f40f..0000000
--- a/recipes-mac/AppArmor/files/0002-libapparmor-add-aa_features_new_from_file-to-public-.patch
+++ /dev/null
@@ -1,37 +0,0 @@
-From c9255a03436e6a91bd4e410601da8d43a341ffc2 Mon Sep 17 00:00:00 2001
-From: Patrick Steinhardt <ps@...>
-Date: Sat, 3 Oct 2020 20:58:45 +0200
-Subject: [PATCH] libapparmor: add `aa_features_new_from_file` to public
- symbols
-
-With AppArmor release 3.0, a new function `aa_features_new_from_file`
-was added, but not added to the list of public symbols. As a result,
-it's not possible to make use of this function when linking against
-libapparmor.so.
-
-Fix the issue by adding it to the symbol map.
-
-Signed-off-by: Patrick Steinhardt <ps@...>
-
-Upstream-Status: Backport
-Signed-off-by: Armin Kuster <akuster808@...>
-
----
- libraries/libapparmor/src/libapparmor.map | 1 +
- 1 file changed, 1 insertion(+)
-
-diff --git a/libraries/libapparmor/src/libapparmor.map b/libraries/libapparmor/src/libapparmor.map
-index bbff51f5..1579509a 100644
---- a/libraries/libapparmor/src/libapparmor.map
-+++ b/libraries/libapparmor/src/libapparmor.map
-@@ -117,6 +117,7 @@ APPARMOR_2.13.1 {
-
- APPARMOR_3.0 {
- global:
-+ aa_features_new_from_file;
- aa_features_write_to_fd;
- aa_features_value;
- local:
---
-2.17.1
-
diff --git a/recipes-mac/AppArmor/files/0003-libapparmor-add-_aa_asprintf-to-private-symbols.patch b/recipes-mac/AppArmor/files/0003-libapparmor-add-_aa_asprintf-to-private-symbols.patch
deleted file mode 100644
index 543c7a1..0000000
--- a/recipes-mac/AppArmor/files/0003-libapparmor-add-_aa_asprintf-to-private-symbols.patch
+++ /dev/null
@@ -1,34 +0,0 @@
-From 9a8fee6bf1c79c261374d928b838b5eb9244ee9b Mon Sep 17 00:00:00 2001
-From: Patrick Steinhardt <ps@...>
-Date: Sat, 3 Oct 2020 21:04:57 +0200
-Subject: [PATCH] libapparmor: add _aa_asprintf to private symbols
-
-While `_aa_asprintf` is supposed to be of private visibility, it's used
-by apparmor_parser and thus required to be visible when linking. This
-commit thus adds it to the list of private symbols to make it available
-for linking in apparmor_parser.
-
-Signed-off-by: Patrick Steinhardt <ps@...>
-
-Upstream-Status: Backport
-Signed-off-by: Armin Kuster <akuster808@...>
-
----
- libraries/libapparmor/src/libapparmor.map | 1 +
- 1 file changed, 1 insertion(+)
-
-diff --git a/libraries/libapparmor/src/libapparmor.map b/libraries/libapparmor/src/libapparmor.map
-index 1579509a..41e541ac 100644
---- a/libraries/libapparmor/src/libapparmor.map
-+++ b/libraries/libapparmor/src/libapparmor.map
-@@ -127,6 +127,7 @@ APPARMOR_3.0 {
- PRIVATE {
- global:
- _aa_is_blacklisted;
-+ _aa_asprintf;
- _aa_autofree;
- _aa_autoclose;
- _aa_autofclose;
---
-2.17.1
-
diff --git a/recipes-mac/AppArmor/files/disable_pdf.patch b/recipes-mac/AppArmor/files/disable_pdf.patch
deleted file mode 100644
index c6b4bdd..0000000
--- a/recipes-mac/AppArmor/files/disable_pdf.patch
+++ /dev/null
@@ -1,33 +0,0 @@
-Index: apparmor-2.10.95/parser/Makefile
-===================================================================
---- apparmor-2.10.95.orig/parser/Makefile
-+++ apparmor-2.10.95/parser/Makefile
-@@ -139,17 +139,6 @@ export Q VERBOSE BUILD_OUTPUT
- po/${NAME}.pot: ${SRCS} ${HDRS}
- $(MAKE) -C po ${NAME}.pot NAME=${NAME} SOURCES="${SRCS} ${HDRS}"
-
--techdoc.pdf: techdoc.tex
-- timestamp=$(shell date --utc "+%Y%m%d%H%M%S%z" -r $< );\
-- while pdflatex "\def\fixedpdfdate{$$timestamp}\input $<" ${BUILD_OUTPUT} || exit 1 ; \
-- grep -q "Label(s) may have changed" techdoc.log; \
-- do :; done
--
--techdoc/index.html: techdoc.pdf
-- latex2html -show_section_numbers -split 0 -noinfo -nonavigation -noaddress techdoc.tex ${BUILD_OUTPUT}
--
--techdoc.txt: techdoc/index.html
-- w3m -dump $< > $@
-
- # targets arranged this way so that people who don't want full docs can
- # pick specific targets they want.
-@@ -159,9 +148,7 @@ manpages: $(MANPAGES)
-
- htmlmanpages: $(HTMLMANPAGES)
-
--pdf: techdoc.pdf
--
--docs: manpages htmlmanpages pdf
-+docs: manpages htmlmanpages
-
- indep: docs
- $(Q)$(MAKE) -C po all
--
2.25.1

Hi all,

Intel and WR YP QA is planning for QA execution for YP build yocto-3.1.9.rc1 We are planning to execute following tests for this cycle:

OEQA-manual tests for following module:
1. OE-Core
2. BSP-hw

Runtime auto test for following platforms:
1. MinnowTurbot 32-bit
2. Coffee Lake
3. NUC 7
4. NUC 6
5. Edgerouter
6. Beaglebone

ETA for completion is next Monday, June 28.

Thanks,
Sangeeta

Yocto Technical Team Minutes, Engineering Sync, for June 22, 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 Jolley, Michael Halstead, Paul Barker, Richard
Purdie, Scott Murray, Steve Sakoman, Tony Tascioglu, Trevor Gamblin,
Alejandro Hernandez, Alexandre Belloni, Jan-Simon Möller, Randy MacLeod

== notes ==
- 3.4 m1 (honister) through QA, couple issue found, in review by TSC to decide
on release
- 3.1.9 (dunfell) currently being build then sent to QA
- thanks to PaulG for tracking down null pointer in cgroups mount code (and
others) that have led to solving some AB hangs
- the rcu dump AB vm hangs are still occurring
- 2 new manual sections: reproducible builds, and YP compatible
- multiconfig changes continue to cause issues
- still lots of AB-INT issues, we’re working on trying to define the load
pattern that causes these issues

== general ==
RP: special thanks to Paul Gortmaker for finding the null pointer issue to fix
the LTP builds


PaulB: still working on the pr-server changes. my changes work on my setup but
don’t seem to do well on the AB. if i enable parallelism in my builds
then the oom-killer gets busy. it’s annoying that the output from a test
is buffered until the test is finished, so if a test hangs then i can’t
find out which one is hanging. it looks like we’ll have to dig into
async-io or python parallelism to see if there’s something wrong there
or at least figure out how to get more output before a test finishes
RP: did you look at the trace output i found
PaulB: yes, but not exactly sure what i’m looking at
RP: if bitbake server starts one of the servers, then it’s responsible for
taking it out when it shuts down. so they run individually, but there is
some sharing. that traceback suggests to me that it’s trying to shut down
the pr server at shutdown time but not succeeding. sometimes the sqlite
database takes time to sync to disk for example (especially when there
is high io) but bitbake ends up blocked. it looks like some contention
between the parse threads and the locks. when doing python parallel there
are 2 systems and we have to make sure to not mix the two.
PaulB: in one case it looks like one of the comm sockets is already closed,
but the server is waiting for it to close again, but i would think we’d
get the same traceback every time
RP: maybe it’s stuck somewhere where it shouldn’t be, which makes it skip
some error/exit handling. or maybe add more debug code
PaulB: yes, i think adding timeouts to every wait/callback to see which ones
are timing out
RP: can python give you a dump of what’s in every waitstate?
PaulB: not sure, i’ll have to look at what python provides. bitbake isn’t
what’s telling prserv to exit on the cluster, but it is on my builds
RP: that seems unlikely
PaulB: i can’t generate the same conditions locally as what we’re seeing
on the AB. because of thread contention there seems to be, perhaps, a
resource exhaustion that i can’t reproduce
RP: put a “sleep 5” in the shutdown path in the prserv. it would cause
hashserve to exist longer than bitbake
PaulB: or backout the use of multiprocessing, keep the new json rpc system.
but do a more traditional fork() to start the process up
RP: i suspect we did the fork() for a reason
PaulB: multiprocessing didn’t exist back then
RP: it did, but it was broken. i sent a cooker daemon log which should show
what was running at the time. so we should be able to reverse engineer
what was going on at that time. i’m getting good at reading those, so i
can probably read them and tell you what tests were running at the time
PaulB: if we could just run that one test
RP: i would run just the prserv selftest and put that sleep in there. i’m
convinced it’s one of them
PaulB: i’m afraid i’m going to have to hand this off to someone else.
i’ll give one more push but then i’m out of ideas
RP: okay. it’d be good to get that in because i’m looking forward to it


TrevorW: move to SPDX license identifiers
RP: we have
TrevorW: classes and ptests yes, but not recipes and other places of oecore
RP: any place where we’re writing python we have. it’s a nice cleanup
thing, we’ve been embracing it. we’ve made some of the changes.
we’ve done it with code. the problem with recipes is that if we put that
at the top of the license it’ll get confused with the LICENCE field. so
we’re not quite sure what to do in that case
PaulB: i've been using a linting tool that checks for these identifiers.
again, the problem of what license to put on the recipe and for patches
etc (https://reuse.software/spec)
RP: licenses in patches in something to think about and would make upstreaming
easier. we’ve done the low hanging fruit but need more thought for other
cases. there’s also a standard form for copyright headers too
PaulB: yes, there’s been an update to the copyright format as well
RP: YP now has attained silver status for core infrastructure in LF. to get to
gold we need copyright on all files and many of our recipes don’t
ScottM: if there’s a statement at the top or the repo doesn’t that help
RP: i don’t think it accounts for that. and then we have to decide if these
are oe contributors or yocto contributors. so i left it at that. if anyone
wants to move this forward i’m definitely interested. there are some
questions we need to answer. our code is good at having copyright, but the
problem is with recipes
RP: there are a couple things we need to get gold status: 2-factor auth for
git pushes, some https issues (best practices changed), and licensing


TrevorG: working on the job server. create a dir in tmp to create the fifo,
but not seeing any difference in performance. i’m not sure kea is the
right way to go
RP: it was deleting the fifo
TrevorG: yes, at the end of the day it’s using the one that’s tied to the
user process
RP: that’s the correct way to do it. if it already exists then it should
get an EXISTS error and just go ahead and user it. as long as it’s not
deleting it
TrevorG: i’ve probably left something out, so i’ll look through it and see
RP: it was a POC i had written, but i can't remember how much testing it got.
these rcu issues seem to be related to a peak-load issue, so it’d be
nice to dig in and get to the core of the issue
TrevorG: tl;dr: no definitive results yet
Randy: make has the ability to look at the system load and use that to decide
whether or not to add more load, is there a reason we’re not considering
that
RP: good question. we’ve talked about it before, but i can't remember why we
decided not to go that route


RP: any updates on the rcu things AlexB? we had another one over the weekend
AlexB: right now i don’t have anything to say because i believe this
is something that is stuck in userspace. so i’m debugging, but
unfortunately the kernel we’re using doesn’t have debugging enabled,
so i want to build another kernel with debugging enabled so we can test
with debugging enabled. maybe we can carry a patch for the qemu kernels
on the AB which will enable more debugging. we’re also missing a few
important symbols that will help us see more. so i don't think these core
dump are important as-is.
RP: which debug symbols are you missing? our dumps have a lot of things
enabled
AlexB: debuginfo. there’s the risk that a new kernel will change behaviour
but we should try
RP: because we’re so reproducible, we should be able to debug easier. would
a complete kernel build help
AlexB: config?
RP: x86-64 musl. we should change the qmp code to run the commands that we
found
AlexB: yes. i’m carrying the 2nd qmp socket patch (instead of going through
the close)
RP: it’d be nice to always have this
AlexB: how do we detect the hang
RP: there are timeouts, so if we hit the timeouts then we assume there’s a
hang
AlexB: we do that before killing…
RP: yes. if you have notes about how to set this up with gdb i’d like to try
replicating it
AlexB: okay. i was hoping this was a problem in the kernel and that the answer
would be right there. we’ve also seen the load of qemu going to 300 to
400 then 300 then 400.
RP: it’s like something is waiting for something else to happen
AlexB: you straced it
RP: yes, while pinging it. and we could see the straces going into the ping
AlexB: yes, which means the kernel is still alive, but the rcu is saying that
the kernel is not alive, so something is confused. something seems to be
waiting for something to happen that might never happen
Randy: so no progress on the rcu stalls?
RP: yes. we’ve made progress at poking qemu, and we have this core dump, but
no insight into what is causing it
Randy: has anyone tried to reproduce it? i’ve got a busy system and i’ve
run stress-ng
RP: i haven’t tried that.
Randy: where does it happen
RP: ubuntu 18.04
AlexB: but maybe that’s because that’s what most of our AB is running?
RP: that’s the info we have. if we can reproduce it then that would be
wonderful since that would make it easier to debug. making qmp better is
worth it in any case.


Randy: what about the kernel change PaulG made. i’d like to hammer on it
RP: i’ve done some hammering and haven’t seen any issues yet
Randy: i’ll do some hammering tonight so we can add some stats
RP: we’ve see one arm AB issue reading a message in /proc, but we’ve only
seen it once
Randy: we don’t have any arm builders. what are you using?
RP: ampere (something) and a huawei (something). not sure what the trigger is;
no idea how to reproduce. it’s a hanging read(), but you can still ssh
into the system. we may end up disabling the test


PaulB: back to copyright headers. i’ve pasted the output of a run i’ve
just done looking for licenses. there’s probably some low-hanging fruit
there and some false positives.

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


https://autobuilder.yocto.io/pub/releases/yocto-3.1.9.rc1


Build hash information:

bitbake: 0e0af15b84e07e6763300dcd092b980086b9b9c4
meta-arm: 59974ccd5f1368b2a1c621ba3efd6d2c44c126dd
meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
meta-intel: d8bf86ae6288ae520b8ddd7209a0b448b9693f48
meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
oecore: ac8181d9b9ad8360f7dba03aba8b00f008c6ebb4
poky: 43060f59ba60a0257864f1f7b25b51fac3f2d2cf



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

Hello, I dug further into yocto classes and I think I found what is going on. 

All seems to come from the fact that gcc debug-prefix-map and macro-prefix-map options are statically defined in bitbake.conf to

DEBUG_PREFIX_MAP ?= "-fmacro-prefix-map=${WORKDIR}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR} \

                     -fdebug-prefix-map=${WORKDIR}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR} \

                     -fdebug-prefix-map=${STAGING_DIR_HOST}= \

                     -fdebug-prefix-map=${STAGING_DIR_NATIVE}= \
"

On Sun, 20 Jun 2021, Robert Berger@... wrote:

Hi,

On 20/06/2021 12:55, Robert P. J. Day wrote:

refactoring existing (legacy) code base into more bite-sized
bitbake recipes to speed up build by taking advantage of 6-core
(12-thread) dell laptop ... end result is that i get so much
parallelism that laptop shuts down from overheating.

Sorry for my stupid question;)

If you have 12 threads, it's 12 threads and not more.

I guess there needs to be some kind of dependency between your new recipes.

make -j can use as many cores as you like even with a single recipe.

How would it speed up builds if you break up a recipe into multiple recipes?

What is your refactoring approach?

the (legacy) code base i was handed involves several sizable
makefiles that were not designed to take advantage of parallelism --
apparently, they come from an environment (QNX?) where "make" does not
do parallelism. so rather than design makefiles with parallelism in
mind, many of the makefiles correspond to some large subsystem where
the top-level target has a rule that simply descends into the numerous
sub-component directories one at a time:

fubar:
$(MAKE) -C fubar1
$(MAKE) -C fubar2
...
$(MAKE) -C fubar42

and last i heard, the commands in any rule are definitely processed
serially. so when the local folks started transmogrifying the code
base to use YP, they just used SRC_URI to point at the existing
makefiles (which *must* stay where they are for the purpose of legacy
compatibility). so as a start, there is a recipe "fubar.bb" which just
runs that top-level Makefile, but given its structure, once it starts,
all you see is "fubar compiling" as it serially processes all of its
subcomponents.

now, most of the major components have sub-directories with, say,
the shared libs, the test suite, and so on, and a lot of other
components that allegedly DEPENDS on "fubar" obviously don't need
*all* of fubar to finish compiling, just normally the library
sub-component, but as it is, they have to wait for all of it, so you
normally see "fubar compiling", and nothing else, for several minutes,
and as soon as that finishes, a bunch of deps that have been patiently
waiting finally kick off.

as i refactor the above into smaller recipes, then the dependencies
build much faster and as soon as the shared lib recipe finishes, all
those other recipes can start, so i'm definitely getting way more
parallelism but, as i mentioned, that comes with a price.

now, given my unlimited cleverness into refactoring recipes, most of
my 6 cores (12 threads) are busy, which is driving up the load average
over the course of the build (easily over an hour for the whole
thing), and sometimes the load average peaks at over 130, and the air
vent on this laptop is blowing air so hot, it can actually burn you if
you leave your hand there too long, and every so often, it just locks
up and shuts down.

what irony -- i redesign the recipes to boost parallelism, only to
fall victim to hardware limitations.

rday

Hello,

On 20/06/2021 22:01:48-0700, Amrun Nisha.R wrote:

Hi,

I am using tlv320aic3104 in one of my project, The hardware is wired
in such a way that the I2C lines from tlv320aic3104 is connected to a
separate microprocessor which performs the init.

The SAI lines of tlv320aic3104 are connected to IMX8M SAI lines, I am
running linux in IMX8M. ALSA says no sound cards found.

I would like to know whether this kind of setup where the i2c is used
by a separate processor and using the SAI lines in  a different device
that runs linux will work. Kindly advice

To support that, you will have to write your own card driver or at least
write a device tree sound node with a dummy codec as Linux will not be
configuring it.

See https://bootlin.com/pub/conferences/2020/lee/belloni-alsa-asoc/belloni-alsa-asoc.pdf

--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Hi,

I am using tlv320aic3104 in one of my project, The hardware is wired in such a way that the I2C lines from tlv320aic3104 is connected to a separate microprocessor which performs the init.

The SAI lines of tlv320aic3104 are connected to IMX8M SAI lines, I am running linux in IMX8M. ALSA says no sound cards found.

I would like to know whether this kind of setup where the i2c is used by a separate processor and using the SAI lines in  a different device that runs linux will work. Kindly advice

This sample application provides an example coap-client using the the MBEDTLS library.

Signed-off-by: Amit Kucheria <amit.kucheria.ext@...>
---
recipes-kernel/zephyr-kernel/zephyr-coap-client.bb | 5 +++++
1 file changed, 5 insertions(+)
create mode 100644 recipes-kernel/zephyr-kernel/zephyr-coap-client.bb

diff --git a/recipes-kernel/zephyr-kernel/zephyr-coap-client.bb b/recipes-kernel/zephyr-kernel/zephyr-coap-client.bb
new file mode 100644
index 000000000000..4140c0f89eae
--- /dev/null
+++ b/recipes-kernel/zephyr-kernel/zephyr-coap-client.bb
@@ -0,0 +1,5 @@
+include zephyr-sample.inc
+
+ZEPHYR_SRC_DIR = "${S}/samples/net/sockets/coap_client"
+
+ZEPHYR_MODULES_append = "\;${S}/modules/lib/mbedtls"
--
2.25.1

This sample application provides an example coap-server using the the MBEDTLS library.

Signed-off-by: Amit Kucheria <amit.kucheria.ext@...>
---
recipes-kernel/zephyr-kernel/zephyr-coap-server.bb | 5 +++++
1 file changed, 5 insertions(+)
create mode 100644 recipes-kernel/zephyr-kernel/zephyr-coap-server.bb

diff --git a/recipes-kernel/zephyr-kernel/zephyr-coap-server.bb b/recipes-kernel/zephyr-kernel/zephyr-coap-server.bb
new file mode 100644
index 000000000000..f7d75c04efd4
--- /dev/null
+++ b/recipes-kernel/zephyr-kernel/zephyr-coap-server.bb
@@ -0,0 +1,5 @@
+include zephyr-sample.inc
+
+ZEPHYR_SRC_DIR = "${S}/samples/net/sockets/coap_server"
+
+ZEPHYR_MODULES_append = "\;${S}/modules/lib/mbedtls"
--
2.25.1

merged,

thanks

Signed-off-by: Armin Kuster <akuster808@...>
---
recipes-core/initrdscripts/initramfs-framework_1.0.bbappend | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-core/initrdscripts/initramfs-framework_1.0.bbappend b/recipes-core/initrdscripts/initramfs-framework_1.0.bbappend
index dc74e01..f5d476e 100644
--- a/recipes-core/initrdscripts/initramfs-framework_1.0.bbappend
+++ b/recipes-core/initrdscripts/initramfs-framework_1.0.bbappend
@@ -1 +1 @@
-require ${@bb.utils.contains('IMAGE_CLASSES', 'dm-verity', 'initramfs-framework.inc', '', d)}
+require ${@bb.utils.contains('IMAGE_CLASSES', 'dm-verity-img', 'initramfs-framework.inc', '', d)}
--
2.17.1

series merged.

thanks