[linux-yocto] [linux-yocto v5.10] [PATCH] tracing/arm: Have max stack tracer handle the case of return address after data

[Zhang, Qiang]

From: Zqiang 

This change is similar to the following patch,  
it also suitable for arm.

[
Author: Steven Rostedt (VMware)
Email: rost...@goodmis.org
Subject: tracing/arm64: Have max stack tracer handle the case of return address 
after data
Date: Fri, 9 Aug 2019 02:15:05 +

Most archs (well at least x86) store the function call return address on the
stack before storing the local variables for the function. The max stack
tracer depends on this in its algorithm to display the stack size of each
function it finds in the back trace.

Some archs (arm64), may store the return address (from its link register)
just before calling a nested function. There's no reason to save the link
register on leaf functions, as it wont be updated. This breaks the algorithm
of the max stack tracer.

Add a new define ARCH_FTRACE_SHIFT_STACK_TRACER that an architecture may set
if it stores the return address (link register) after it stores the
function's local variables, and have the stack trace shift the values of the
mapped stack size to the appropriate functions.

Link: 20190802094103.163576-1-jiping@windriver.com

Reported-by: Jiping Ma 
Acked-by: Will Deacon 
Signed-off-by: Steven Rostedt (VMware) 
Signed-off-by: Jiping Ma 
]

Signed-off-by: Zqiang 
---
 arch/arm/include/asm/ftrace.h | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/include/asm/ftrace.h b/arch/arm/include/asm/ftrace.h
index 48ec1d0337da..c70f8fb13ae3 100644
--- a/arch/arm/include/asm/ftrace.h
+++ b/arch/arm/include/asm/ftrace.h
@@ -10,6 +10,19 @@
 #define MCOUNT_ADDR((unsigned long)(__gnu_mcount_nc))
 #define MCOUNT_INSN_SIZE   4 /* sizeof mcount call */

+/*
+ * Currently, gcc tends to save the link register after the local variables
+ * on the stack. This causes the max stack tracer to report the function
+ * frame sizes for the wrong functions. By defining
+ * ARCH_FTRACE_SHIFT_STACK_TRACER, it will tell the stack tracer to expect
+ * to find the return address on the stack after the local variables have
+ * been set up.
+ *
+ * Note, this may change in the future, and we will need to deal with that
+ * if it were to happen.
+ */
+#define ARCH_FTRACE_SHIFT_STACK_TRACER 1
+
 #ifndef __ASSEMBLY__
 extern void __gnu_mcount_nc(void);

--
2.29.2

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

Re: [yocto] Yocto Zeus : facing error regarding hostapd #zeus

[Zoran]

>From the log log.do_rootfs.31340 file, there are the following:

[1] ERROR: Postinstall scriptlets of ['hostapd'] have failed.

HOSTAP stands for: HOST Access Point Daemon. I could not conclude too much from:
https://en.wikipedia.org/wiki/Hostapd

It is kind of a hot spot, as my best understanding is.

[2] Details of the failure are in
/home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.

So, my best guess, looking into log.do_rootfs will tell us much more.

Please, attach this one for our review as well.

Thank you,
Zoran
___

On Wed, May 12, 2021 at 5:29 PM rohit jadhav  wrote:
>
> Hi Zoran ,
> I have attached the log file for your reference.
> Thank You
> Regards
> Rohit
>
> On Wed, May 12, 2021 at 7:50 PM Zoran Stojsavljevic 
>  wrote:
>>
>> > Log file in:
>> > /home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/
>> > imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/
>> log.do_rootfs.31340
>>
>> Could you, please, attach a log file?
>>
>> Thank you,
>> Zoran
>> ___
>>
>>
>> On Wed, May 12, 2021 at 2:01 PM rohit jadhav  wrote:
>>>
>>> Facing following issue :
>>> ERROR: core-image-minimal-1.0-r0 do_rootfs: Postinstall scriptlets of 
>>> ['hostapd'] have failed. If the intention is to defer them to first boot,
>>> then please place them into pkg_postinst_ontarget_${PN} ().
>>> Deferring to first boot via 'exit 1' is no longer supported.
>>> Details of the failure are in 
>>> /home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.
>>> ERROR: Logfile of failure stored in: 
>>> /home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.31340
>>> ERROR: Task 
>>> (/home/tel/imx_yocto_bsp_Zeus/Yocto_setup/sources/poky/meta/recipes-core/images/core-image-minimal.bb:do_rootfs)
>>>  failed with exit code '1'
>>>
>>> Please guide me if anyone have any idea to resolve.
>>>
>>> Thanks in advance.
>>> 
>>>

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

Re: [yocto] [meta-raspberrypi][PATCH] 99-com.rules: fix error invalid substitution type

[Khem Raj]

On 5/12/21 8:42 PM, Changqing Li wrote:

From: Changqing Li 

fix below error:
/etc/udev/rules.d/99-com.rules:10 Invalid value "/bin/sh -c
'ALIASES=/proc/device-tree/aliases; if cmp -s $ALIASES/uart0
$ALIASES/serial0; then echo 0;elif cmp -s $ALIASES/uart0
$ALIASES/serial1; then echo 1; else exit 1; fi'" for PROGRAM (char 58:
invalid substitution type)



Can you create a pull request on github for this please.


Signed-off-by: Changqing Li 
---
  recipes-core/udev/udev-rules-rpi/99-com.rules | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/recipes-core/udev/udev-rules-rpi/99-com.rules 
b/recipes-core/udev/udev-rules-rpi/99-com.rules
index 6bf019b..ddd1e17 100644
--- a/recipes-core/udev/udev-rules-rpi/99-com.rules
+++ b/recipes-core/udev/udev-rules-rpi/99-com.rules
@@ -1,8 +1,8 @@
  KERNEL=="ttyAMA[01]", PROGRAM="/bin/sh -c '\
ALIASES=/proc/device-tree/aliases; \
-   if cmp -s $ALIASES/uart0 $ALIASES/serial0; then \
+   if cmp -s $$ALIASES/uart0 $$ALIASES/serial0; then \
echo 0;\
-   elif cmp -s $ALIASES/uart0 $ALIASES/serial1; then \
+   elif cmp -s $$ALIASES/uart0 $$ALIASES/serial1; then \
echo 1; \
else \
exit 1; \
@@ -11,9 +11,9 @@ KERNEL=="ttyAMA[01]", PROGRAM="/bin/sh -c '\
  
  KERNEL=="ttyS0", PROGRAM="/bin/sh -c '\

ALIASES=/proc/device-tree/aliases; \
-   if cmp -s $ALIASES/uart1 $ALIASES/serial0; then \
+   if cmp -s $$ALIASES/uart1 $$ALIASES/serial0; then \
echo 0; \
-   elif cmp -s $ALIASES/uart1 $ALIASES/serial1; then \
+   elif cmp -s $$ALIASES/uart1 $$ALIASES/serial1; then \
echo 1; \
else \
exit 1; \






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

[yocto] [meta-raspberrypi][PATCH] 99-com.rules: fix error invalid substitution type

[Changqing Li]

From: Changqing Li 

fix below error:
/etc/udev/rules.d/99-com.rules:10 Invalid value "/bin/sh -c
'ALIASES=/proc/device-tree/aliases; if cmp -s $ALIASES/uart0
$ALIASES/serial0; then echo 0;elif cmp -s $ALIASES/uart0
$ALIASES/serial1; then echo 1; else exit 1; fi'" for PROGRAM (char 58:
invalid substitution type)

Signed-off-by: Changqing Li 
---
 recipes-core/udev/udev-rules-rpi/99-com.rules | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/recipes-core/udev/udev-rules-rpi/99-com.rules 
b/recipes-core/udev/udev-rules-rpi/99-com.rules
index 6bf019b..ddd1e17 100644
--- a/recipes-core/udev/udev-rules-rpi/99-com.rules
+++ b/recipes-core/udev/udev-rules-rpi/99-com.rules
@@ -1,8 +1,8 @@
 KERNEL=="ttyAMA[01]", PROGRAM="/bin/sh -c '\
ALIASES=/proc/device-tree/aliases; \
-   if cmp -s $ALIASES/uart0 $ALIASES/serial0; then \
+   if cmp -s $$ALIASES/uart0 $$ALIASES/serial0; then \
echo 0;\
-   elif cmp -s $ALIASES/uart0 $ALIASES/serial1; then \
+   elif cmp -s $$ALIASES/uart0 $$ALIASES/serial1; then \
echo 1; \
else \
exit 1; \
@@ -11,9 +11,9 @@ KERNEL=="ttyAMA[01]", PROGRAM="/bin/sh -c '\
 
 KERNEL=="ttyS0", PROGRAM="/bin/sh -c '\
ALIASES=/proc/device-tree/aliases; \
-   if cmp -s $ALIASES/uart1 $ALIASES/serial0; then \
+   if cmp -s $$ALIASES/uart1 $$ALIASES/serial0; then \
echo 0; \
-   elif cmp -s $ALIASES/uart1 $ALIASES/serial1; then \
+   elif cmp -s $$ALIASES/uart1 $$ALIASES/serial1; then \
echo 1; \
else \
exit 1; \
-- 
2.17.1


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

[linux-yocto][linux-yocto v5.10] kernel code for marvell cn96xx

[Ruiqiang Hao]

Hi Bruce,

Please help to merge this patch into our linux-yocto repo.

repo:
linux-yocto
branch:
v5.10/standard/base

Thanks,
Ruiqiang

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

[linux-yocto] [PATCH] net: Treat __napi_schedule_irqoff() as __napi_schedule() on PREEMPT_RT

[Ruiqiang Hao]

From: Sebastian Andrzej Siewior 

__napi_schedule_irqoff() is an optimized version of __napi_schedule()
which can be used where it is known that interrupts are disabled,
e.g. in interrupt-handlers, spin_lock_irq() sections or hrtimer
callbacks.

On PREEMPT_RT enabled kernels this assumptions is not true. Force-
threaded interrupt handlers and spinlocks are not disabling interrupts
and the NAPI hrtimer callback is forced into softirq context which runs
with interrupts enabled as well.

Chasing all usage sites of __napi_schedule_irqoff() is a whack-a-mole
game so make __napi_schedule_irqoff() invoke __napi_schedule() for
PREEMPT_RT kernels.

The callers of napi_schedule() in the networking core have been
audited and are correct on PREEMPT_RT kernels as well.

Reported-by: Juri Lelli 
Signed-off-by: Sebastian Andrzej Siewior 

[RQ: Original patch taken from this linux kernel mailing list archive:
https://lore.kernel.org/lkml/20210512214324.hiaiw3e2tzmsy...@linutronix.de/]

Integrated-by: Ruiqiang Hao 
---
 net/core/dev.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index 64f4c7ec729d..61f78290e590 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -6414,11 +6414,18 @@ EXPORT_SYMBOL(napi_schedule_prep);
  * __napi_schedule_irqoff - schedule for receive
  * @n: entry to schedule
  *
- * Variant of __napi_schedule() assuming hard irqs are masked
+ * Variant of __napi_schedule() assuming hard irqs are masked.
+ *
+ * On PREEMPT_RT enabled kernels this maps to __napi_schedule()
+ * because the interrupt disabled assumption might not be true
+ * due to force-threaded interrupts and spinlock substitution.
  */
 void __napi_schedule_irqoff(struct napi_struct *n)
 {
-   napi_schedule(this_cpu_ptr(_data), n);
+   if (!IS_ENABLED(CONFIG_PREEMPT_RT))
+   napi_schedule(this_cpu_ptr(_data), n);
+   else
+   __napi_schedule(n);
 }
 EXPORT_SYMBOL(__napi_schedule_irqoff);
 
-- 
2.29.2


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

[yocto] [meta-security][PATCH 2/6] ibmtpm2tss: update to tip

[Armin Kuster]

Signed-off-by: Armin Kuster 
---
 meta-tpm/recipes-tpm2/ibmtpm2tss/ibmtpm2tss_1.6.0.bb | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta-tpm/recipes-tpm2/ibmtpm2tss/ibmtpm2tss_1.6.0.bb 
b/meta-tpm/recipes-tpm2/ibmtpm2tss/ibmtpm2tss_1.6.0.bb
index 4d9b554..ae8974b 100644
--- a/meta-tpm/recipes-tpm2/ibmtpm2tss/ibmtpm2tss_1.6.0.bb
+++ b/meta-tpm/recipes-tpm2/ibmtpm2tss/ibmtpm2tss_1.6.0.bb
@@ -17,11 +17,13 @@ DEPENDS = "openssl ibmswtpm2"
 
 inherit autotools pkgconfig
 
-SRCREV = "3e736f712ba53c8f06e66751f60fae428fd2e20f"
+SRCREV = "c4e131e34ec0ed09411aa3bc76f76129ef881573"
 SRC_URI = " git://git.code.sf.net/p/ibmtpm20tss/tss;nobranch=1 \
file://0001-utils-12-Makefile.am-expand-wildcards-in-prereqs.patch \
"
 
+UPSTREAM_CHECK_COMMITS = "1"
+
 EXTRA_OECONF = "--disable-tpm-1.2"
 
 S = "${WORKDIR}/git"
-- 
2.25.1


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

[yocto] [meta-security][PATCH 1/6] ibmswtpm2: update to 1661

[Armin Kuster]

Drop patch now included in updated

Signed-off-by: Armin Kuster 
---
 .../ibmswtpm2/files/fix-wrong-cast.patch  | 27 ---
 .../{ibmswtpm2_1637.bb => ibmswtpm2_1661.bb}  | 10 +++
 2 files changed, 4 insertions(+), 33 deletions(-)
 delete mode 100644 meta-tpm/recipes-tpm2/ibmswtpm2/files/fix-wrong-cast.patch
 rename meta-tpm/recipes-tpm2/ibmswtpm2/{ibmswtpm2_1637.bb => 
ibmswtpm2_1661.bb} (69%)

diff --git a/meta-tpm/recipes-tpm2/ibmswtpm2/files/fix-wrong-cast.patch 
b/meta-tpm/recipes-tpm2/ibmswtpm2/files/fix-wrong-cast.patch
deleted file mode 100644
index f2938e0..000
--- a/meta-tpm/recipes-tpm2/ibmswtpm2/files/fix-wrong-cast.patch
+++ /dev/null
@@ -1,27 +0,0 @@
-Fix strict aliasing issue of gcc10
-
-fixes:
-
-TpmFail.c: In function 'TpmLogFailure':
-TpmFail.c:217:23: error: dereferencing type-punned pointer will break 
strict-aliasing rules [-Werror=strict-aliasing]
-  217 | s_failFunction = *(UINT32 *) /* kgold */
-  |   ^~~
-cc1: all warnings being treated as errors
-
-Upstream-Status: Submitted
-
-Signed-off-by: Jens Rehsack 
-
-Index: src/TpmFail.c
-===
 src.orig/TpmFail.c 2020-09-10 15:43:57.085063875 +0200
-+++ src/TpmFail.c  2020-09-10 15:48:35.563302634 +0200
-@@ -214,7 +214,7 @@
- // On a 64-bit machine, this may truncate the address of the string
- // of the function name where the error occurred.
- #if FAIL_TRACE
--s_failFunction = *(UINT32 *)/* kgold */
-+memcpy(_failFunction, function, sizeof(uint32_t));  /* kgold */
- s_failLine = line;
- #else
- s_failFunction = 0;
diff --git a/meta-tpm/recipes-tpm2/ibmswtpm2/ibmswtpm2_1637.bb 
b/meta-tpm/recipes-tpm2/ibmswtpm2/ibmswtpm2_1661.bb
similarity index 69%
rename from meta-tpm/recipes-tpm2/ibmswtpm2/ibmswtpm2_1637.bb
rename to meta-tpm/recipes-tpm2/ibmswtpm2/ibmswtpm2_1661.bb
index 301980d..7ea40a8 100644
--- a/meta-tpm/recipes-tpm2/ibmswtpm2/ibmswtpm2_1637.bb
+++ b/meta-tpm/recipes-tpm2/ibmswtpm2/ibmswtpm2_1661.bb
@@ -17,13 +17,11 @@ DEPENDS = "openssl"
 
 SRC_URI = "https://sourceforge.net/projects/ibmswtpm2/files/ibmtpm${PV}.tar.gz 
\
file://tune-makefile.patch \
-   file://fix-wrong-cast.patch \
"
-SRC_URI[md5sum] = "43b217d87056e9155633925eb6ef749c"
-SRC_URI[sha256sum] = 
"dd3a4c3f7724243bc9ebcd5c39bbf87b82c696d1c1241cb8e5883534f6e2e327"
-SRC_URI[sha1sum] = "ab4b94079e57a86996991e8a2b749ce063e4ad3e"
-SRC_URI[sha384sum] = 
"bbef16a934853ce78cba7ddc766aa9d7ef3cde3430a322b1be772bf3ad4bd6d413ae9c4de21bc1a4879d17dfe2aadc1d"
-SRC_URI[sha512sum] = 
"007aa415cccf19a2bcf789c426727dc4032dcb04cc9d11eedc231d2add708c1134d3d5ee5cfbe7de68307c95fff7a30bd306fbd8d53c198a5ef348440440a6ed"
+
+SRC_URI[sha256sum] = 
"55145928ad2b24f34be6a0eacf9fb492e10e0ea919b8428c721fa970e85d6147"
+
+UPSTREAM_CHECK_REGEX = "libtpm(?P).tar.gz"
 
 S = "${WORKDIR}/src"
 
-- 
2.25.1


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

[yocto] [meta-security][PATCH 5/6] aide: Add another ids

[Armin Kuster]

Signed-off-by: Armin Kuster 
---
 recipes-ids/aide/aide/aide.conf | 94 +
 recipes-ids/aide/aide_0.17.3.bb | 41 ++
 2 files changed, 135 insertions(+)
 create mode 100644 recipes-ids/aide/aide/aide.conf
 create mode 100644 recipes-ids/aide/aide_0.17.3.bb

diff --git a/recipes-ids/aide/aide/aide.conf b/recipes-ids/aide/aide/aide.conf
new file mode 100644
index 000..2c99e07
--- /dev/null
+++ b/recipes-ids/aide/aide/aide.conf
@@ -0,0 +1,94 @@
+# Example configuration file for AIDE.
+
+@@define DBDIR /usr/lib/aide
+@@define LOGDIR /usr/lib/aide/logs
+
+# The location of the database to be read.
+database_in=file:@@{DBDIR}/aide.db.gz
+
+# The location of the database to be written.
+#database_out=sql:host:port:database:login_name:passwd:table
+#database_out=file:aide.db.new
+database_out=file:@@{DBDIR}/aide.db.gz
+
+# Whether to gzip the output to database
+gzip_dbout=yes
+
+# Default.
+log_level=warning
+
+report_url=file:@@{LOGDIR}/aide.log
+report_url=stdout
+#report_url=stderr
+#NOT IMPLEMENTED report_url=mailto:r...@foo.com
+#NOT IMPLEMENTED report_url=syslog:LOG_AUTH
+
+# These are the default rules.
+#
+#p:  permissions
+#i:  inode:
+#n:  number of links
+#u:  user
+#g:  group
+#s:  size
+#b:  block count
+#m:  mtime
+#a:  atime
+#c:  ctime
+#S:  check for growing size
+#acl:   Access Control Lists
+#selinuxSELinux security context
+#xattrs:Extended file attributes
+#md5:md5 checksum
+#sha1:   sha1 checksum
+#sha256:sha256 checksum
+#sha512:sha512 checksum
+#rmd160: rmd160 checksum
+#tiger:  tiger checksum
+
+#haval:  haval checksum (MHASH only)
+#gost:   gost checksum (MHASH only)
+#crc32:  crc32 checksum (MHASH only)
+#whirlpool: whirlpool checksum (MHASH only)
+
+FIPSR = p+i+n+u+g+s+m+c+acl+selinux+xattrs+sha256
+
+#R: p+i+n+u+g+s+m+c+acl+selinux+xattrs+md5
+#L: p+i+n+u+g+acl+selinux+xattrs
+#E: Empty group
+#>: Growing logfile p+u+g+i+n+S+acl+selinux+xattrs
+
+# You can create custom rules like this.
+# With MHASH...
+# ALLXTRAHASHES = sha1+rmd160+sha256+sha512+whirlpool+tiger+haval+gost+crc32
+ALLXTRAHASHES = sha1+rmd160+sha256+sha512+tiger
+# Everything but access time (Ie. all changes)
+EVERYTHING = R+ALLXTRAHASHES
+
+# Sane, with multiple hashes
+# NORMAL = R+rmd160+sha256+whirlpool
+NORMAL = FIPSR+sha512
+
+# For directories, don't bother doing hashes
+DIR = p+i+n+u+g+acl+selinux+xattrs
+
+# Access control only
+PERMS = p+i+u+g+acl+selinux
+
+# Logfile are special, in that they often change
+LOG = >
+
+# Just do sha256 and sha512 hashes
+LSPP = FIPSR+sha512
+
+# Some files get updated automatically, so the inode/ctime/mtime change
+# but we want to know when the data inside them changes
+DATAONLY =  p+n+u+g+s+acl+selinux+xattrs+sha256
+
+# Next decide what directories/files you want in the database.
+
+# Check only permissions, inode, user and group for /etc, but
+# cover some important files closely.
+/bin NORMAL
+/sbin NORMAL
+/lib NORMAL
diff --git a/recipes-ids/aide/aide_0.17.3.bb b/recipes-ids/aide/aide_0.17.3.bb
new file mode 100644
index 000..522cd85
--- /dev/null
+++ b/recipes-ids/aide/aide_0.17.3.bb
@@ -0,0 +1,41 @@
+SUMMARY = "Advanced Intrusion Detection Environment"
+HOMEPAGE = "https://aide.github.io;
+LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
+LICENSE = "GPL-2.0"
+
+DEPENDS = "bison-native libpcre"
+
+SRC_URI = 
"https://github.com/aide/aide/releases/download/v${PV}/${BPN}-${PV}.tar.gz \
+   file://aide.conf"
+
+SRC_URI[sha256sum] = 
"a2eb1883cafaad056fbe43ee1e8ae09fd36caa30a0bc8edfea5d47bd67c464f8"
+
+inherit autotools pkgconfig
+
+PACKAGECONFIG ??=" mhash zlib e2fsattrs \
+ ${@bb.utils.contains('DISTRO_FEATURES', 'selinux', 'selinux 
audit', '', d)} \
+ ${@bb.utils.contains('DISTRO_FEATURES', 'xattr', 'xattr', '', 
d)} \
+ "
+PACKAGECONFIG[selinux] = "--with-selinux, --without-selinux, libselinux, 
libselinux"
+PACKAGECONFIG[zlib] = "--with-zlib, --without-zlib, zlib, zlib "
+PACKAGECONFIG[xattr] = "--with-xattr, --without-xattr, attr, attr"
+PACKAGECONFIG[curl] = "--with-curl, --without-curl, curl, libcurl"
+PACKAGECONFIG[audit] = "--with-audit, --without-audit,"
+PACKAGECONFIG[gcrypt] = "--with-gcrypt, --without-gcrypt, libgcrypt, libgcrypt"
+PACKAGECONFIG[mhash] = "--with-mhash, --without-mhash, libmhash, libmhash"
+PACKAGECONFIG[e2fsattrs] = "--with-e2fsattrs, --without-e2fsattrs, e2fsprogs, 
e2fsprogs"
+
+do_install_append () {
+install -d ${D}${libdir}/${PN}/logs   
+install -d ${D}${sysconfdir}   
+install ${WORKDIR}/aide.conf ${D}${sysconfdir}/
+}
+
+CONF_FILE = "${sysconfdir}/aide.conf"
+
+FILES_${PN} += "${libdir}/${PN} ${sysconfdir}/aide.conf"
+
+pkg_postinst_ontarget_${PN} () {
+/usr/bin/aide -i
+}
+RDPENDS_${PN} = "bison, libpcre"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You 

[yocto] [meta-security][PATCH 6/6] packagegroup-core-security: add aide and ossec

[Armin Kuster]

Signed-off-by: Armin Kuster 
---
 recipes-core/packagegroup/packagegroup-core-security.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/recipes-core/packagegroup/packagegroup-core-security.bb 
b/recipes-core/packagegroup/packagegroup-core-security.bb
index 54b8297..0bddf64 100644
--- a/recipes-core/packagegroup/packagegroup-core-security.bb
+++ b/recipes-core/packagegroup/packagegroup-core-security.bb
@@ -70,6 +70,8 @@ SUMMARY_packagegroup-security-ids = "Security Intrusion 
Detection systems"
 RDEPENDS_packagegroup-security-ids = " \
 samhain-standalone \
 ${@bb.utils.contains_any("TUNE_FEATURES", "ppc7400 riscv32 riscv64", "", " 
suricata",d)} \
+ossec-hids \
+aide \
 "
 
 SUMMARY_packagegroup-security-mac = "Security Mandatory Access Control systems"
-- 
2.25.1


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

[yocto] [meta-security][PATCH 4/6] Apparmor: fix multi config build issue.

[Armin Kuster]

Signed-off-by: Armin Kuster 
---
 recipes-mac/AppArmor/apparmor_3.0.bb | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/recipes-mac/AppArmor/apparmor_3.0.bb 
b/recipes-mac/AppArmor/apparmor_3.0.bb
index 015205d..d9c3e4d 100644
--- a/recipes-mac/AppArmor/apparmor_3.0.bb
+++ b/recipes-mac/AppArmor/apparmor_3.0.bb
@@ -177,8 +177,9 @@ SYSTEMD_AUTO_ENABLE ?= "enable"
 
 PACKAGES += "mod-${PN}"
 
-FILES_${PN} += "/lib/apparmor/ /lib/security/ ${sysconfdir}/apparmor 
${PYTHON_SITEPACKAGES_DIR}"
+FILES_${PN} += "/lib/apparmor/ /lib/security/ ${sysconfdir}/apparmor 
${nonarch_libdir}/${PYTHON_DIR}/site-packages"
 FILES_mod-${PN} = "${libdir}/apache2/modules/*"
+FILES_${PN}-dbg += "/lib/security/"
 
 DEPENDS_append_libc-musl = " fts "
 RDEPENDS_${PN}_libc-musl +=  "musl-utils"
-- 
2.25.1


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

[yocto] [meta-security][PATCH 3/6] packagegroup-core-security: fix typo for mips

[Armin Kuster]

Signed-off-by: Armin Kuster 
---
 recipes-core/packagegroup/packagegroup-core-security.bb | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/recipes-core/packagegroup/packagegroup-core-security.bb 
b/recipes-core/packagegroup/packagegroup-core-security.bb
index 6d2dd7c..54b8297 100644
--- a/recipes-core/packagegroup/packagegroup-core-security.bb
+++ b/recipes-core/packagegroup/packagegroup-core-security.bb
@@ -79,8 +79,7 @@ RDEPENDS_packagegroup-security-mac = " \
 ${@bb.utils.contains("DISTRO_FEATURES", "smack", "smack", "",d)} \
 "
 
-RDEPENDS_packagegroup-security-mac_remove_mips64 = "apparmor"
-RDEPENDS_packagegroup-security-mac_remove_mips64le = "apparmor"
+RDEPENDS_packagegroup-security-mac_remove_mipsarch = "apparmor"
 
 RDEPENDS_packagegroup-meta-security-ptest-packages = "\
 ptest-runner \
-- 
2.25.1


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

[yocto] [meta-security][v2][PATCH] suricata: 4.1.x add UPSTREAM_CHECK_URI

[Armin Kuster]

Signed-off-by: Armin Kuster 
---
 recipes-ids/suricata/suricata_4.1.10.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/recipes-ids/suricata/suricata_4.1.10.bb 
b/recipes-ids/suricata/suricata_4.1.10.bb
index 3f7beaa..bf08843 100644
--- a/recipes-ids/suricata/suricata_4.1.10.bb
+++ b/recipes-ids/suricata/suricata_4.1.10.bb
@@ -12,6 +12,8 @@ SRC_URI += " \
 file://run-ptest \
 "
 
+UPSTREAM_CHECK_URI = "www.openinfosecfoundation.org/download"
+
 inherit autotools-brokensep pkgconfig python3-dir systemd ptest
 
 CFLAGS += "-D_DEFAULT_SOURCE -fcommon"
-- 
2.25.1


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

Re: [yocto] Yocto with xtensa

[Khem Raj]

Hello Jack,

I think we do not have support for Xtensa architecture working out of
box upstream. Although it should be possible to add it with little
effort, but no one has spun patches to do so
thus far.

Thanks
-Khem

On Wed, May 12, 2021 at 1:29 PM Jack Daniels  wrote:
>
> Dears,
>
> I am looking for a way to include sample code for DSP (xtensa) with 
> Yocto/Linux. what would be the procedure to include such a code and 
> eventually interprocessor communication between xtensa core and CPU under 
> Yocto/Linux?
>
> Thank you.
> BR/J
>
>
> 
>

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

Re: [yocto] FW: Yocto Distro Testing Plan

[Richard Purdie]

On Wed, 2021-05-12 at 18:48 +, Kraft, George wrote:
> Could someone point me to a wiki on how yocto testing/QA/conformance is done?
> The Distro Testing Plan wiki seems outdated, and my inquiry to Jose bounced.

The wiki is a bit out of date, sorry. We have been working on 
documenting our testing in a manual:

http://docs.yoctoproject.org/test-manual/index.html

Short summary is you can see builds here:

https://autobuilder.yoctoproject.org/typhoon/#/

and an example release test report:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.3/testreport.txt

Cheers,

Richard


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

[yocto] Yocto with xtensa

[Jack Daniels]

Dears,

I am looking for a way to include sample code for DSP (xtensa) with
Yocto/Linux. what would be the procedure to include such a code and
eventually interprocessor communication between xtensa core and CPU under
Yocto/Linux?

Thank you.
BR/J

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

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

[Zoran]

> We have discussed extending it but we currently only have the funding
> for the originally planned 2 years.

Really/echt??? Why? ;)

Zoran
___

On Wed, May 5, 2021 at 12:33 AM Richard Purdie
 wrote:
>
> On Tue, 2021-05-04 at 18:38 +0200, Alexander Kanavin wrote:
> > On Tue, 4 May 2021 at 16:46, Stephen Jolley  wrote:
> > > We are pleased to announce that our April 2022 release (potentially 3.5) 
> > > will
> > > be the next LTS as per our original two year schedule. If there are 
> > > features
> > > desired in the next LTS, now is the time to get them submitted and 
> > > stabilized
> > > ready.
> > >
> >
> > What will happen to the current LTS at that point? Will support be cut off,
> > will there be a transition window, or is it currently undefined?
>
> We have discussed extending it but we currently only have the funding for the
> originally planned 2 years. Discussions are continuing but since we do all
> agree that the next LTS will start then, we decided to at least let people
> plan against that.
>
> Unless funding/support is secured, dunfell would move to community support
> if anyone were willing to step up, or become EOL and replaced by the new LTS.
> There would likely be some period of overlap of a few months to transition.
>
> There is also concern about pressuring wider community layers for longer 
> support
> cycles which is something we need to think about.
>
> Cheers,
>
> Richard
>
>
> 
>

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

[yocto] FW: Yocto Distro Testing Plan

[Kraft, George]

Could someone point me to a wiki on how yocto testing/QA/conformance is done?   
The Distro Testing 
Plan 
wiki seems outdated, and my inquiry to Jose bounced.

Thanks,

George (gk4)

From: Kraft, George
Sent: Wednesday, May 12, 2021 8:34 AM
To: jose.
Subject: Yocto Distro Testing Plan

Jose,

I've been reading the Distro Testing 
Plan, 
and I tried following the instructions to git clone 
git.yoctoproject.org/git/yocto-autobuilder, but that repo is empty with just a 
README.   Per the README, when I tried to git clone yocto-autobuilder2 or 
yocto-autobuilder-helper then the connections timed out for each.

Can you tell me what the state of testing is for Yocto?

Thanks,

George Kraft, 
P.E.
Distinguished Member Technical Staff
Dell EMC, ISG Embedded Systems Engineering


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

Re: [yocto] Understanding kernel patching in linux-yocto

[Diego Santa Cruz via lists.yoctoproject.org]

> -Original Message-
> From: yocto@lists.yoctoproject.org  On
> Behalf Of Bruce Ashfield via lists.yoctoproject.org
> Sent: 12 May 2021 16:25
> To: Yann Dirson 
> Cc: Yocto discussion list 
> Subject: Re: [yocto] Understanding kernel patching in linux-yocto
> 
> On Wed, May 12, 2021 at 10:07 AM Yann Dirson
>  wrote:
> >
> > Thanks for those clarifications!
> >
> > Some additional questions below
> >
> > Le mer. 12 mai 2021 à 15:19, Bruce Ashfield  a
> écrit :
> > >
> > > On Wed, May 12, 2021 at 7:14 AM Yann Dirson  group.com> wrote:
> > > >
> > > > I am currently working on a kmeta BSP for the rockchip-based NanoPI
> M4
> > > > [1], and I'm wondering how I should be providing kernel patches, as
> > > > just add ing "patch" directives in the .scc does not get them applied
> > > > unless the particular .scc gets included in KERNEL_FEATURES (see [2]).
> > > >
> > > > From an old thread [3] I understand that the patches from the standard
> > > > kmeta snippets are already applied to the tree, and that to get the
> > > > patches from my BSP I'd need to reference it explicitly in SRC_URI
> > > > (along with using "nopatch" in the right places to avoid the
> > > > already-applied patches to get applied twice).
> > > >
> > > > I have the feeling that I'm lacking the rationale behind this, and
> > > > would need to understand this better to make things right in this BSP.
> > > > Especially:
> > > > - at first sight, having the patches both applied to linux-yocto and
> > > > referenced in yocto-kernel-cache just to be skipped on parsing looks
> > > > like both information duplication and parsing of unused lines
> > >
> > > At least some of this is mentioned in the advanced section of the
> > > kernel-dev manual, but I can summarize/reword things here, and
> > > I'm also doing a presentation related to this in the Yocto summit at
> > > the end of this month.
> > >
> > > The big thing to remember, is that the configuration and changes
> > > you see in that repository, are not only for yocto purposes. The
> > > concepts and structure pre-date when they were first brought in
> > > to generate reference kernels over 10 years ago (the implementation
> > > has changed, but the concepts are still the same). To this day,
> > > there still are cases that they are used with just a kernel tree and
> > > cross toolchain.
> > >
> > > With that in mind, the meta-data is used for many different things
> > >
> > >  - It organizes patches / features and their configuration into
> > >reusable blocks. At the same time documenting the changes
> > >that we have applied to a tree
> > >  - It makes those patches and configuration blocks available to
> > >other kernel trees (for whatever reason).
> > >  - It configures the tree during the build process, reusing both
> > >configuration only and patch + configuration blocks
> >
> > >  - It is used to generate a history clean tree from scratch for
> > >each new supported kernel. Which is what I do when creating
> > >new linux-yocto-dev references, and the new /standard/*
> > >branches in linux-yocto.
> >
> > I'd think (and I take your further remarks about workflow as confirming
> > this), that when upgrading the kernel the best tool would be git-rebase.
> > Then, regenerating the linux-yocto branches would only be a akin to a
> > check that the metadata is in sync with the new tree you rebased ?
> 
> The best of anything is a matter of opinion. I heavily use git-rebase and
> sure, you could use it to do something similar here. But the result is
> the same. There's still heavy use of quilt in kernel circles. Workflows
> don't change easily, and as long as they work for the maintainer, they
> tend to stay put. Asking someone to change their workflow, rarely goes
> over well.
> 
> >
> > If that conclusion is correct, wouldn't it be possible to avoid using the
> > linux-yocto branches directly, and let all the patches be applied at
> > do_patch time ?  That would be much more similar to the standard
> > package workflow (and thus lower the barrier for approaching the
> > kernel packages).
> 
> That's something we did in the past, and sure, you can do anything.
> But patching hundreds of changes at build time means constant
> failures .. again, I've been there and done that. We use similar patches
> in many different contexts and optional stackings. You simply cannot
> maintain them and stay sane by whacking patches onto the SRC_URI.
> The last impression you want when someone builds your kernel is that
> they can't even get past the patch phase.  So that's a hard no, to how
> the reference kernels are maintained (and that hard no has been around
> for 11 years now).
> 
> Also, we maintain contributed reference BSPs in that same tree, that
> are yanking in SDKs from vendors, etc, they are in the thousands of
> patches. So you need the tree and the BSP branches to support that.
> 
> >
> >
> > > So why not just drop all the patches in the SRC_URI ? Been there,
> 

Re: [yocto] [meta-rockchip][PATCH] trusted-firmware-a: Fix rk3399 build with gcc11

[Trevor Woerner]

On Tue 2021-05-11 @ 12:14:24 PM, Khem Raj wrote:
> Signed-off-by: Khem Raj 
> Cc: Ross Burton 

Awesome! Thanks for sorting this one out :-)
Applied to meta-rockchip master.

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

Re: [yocto] Yocto Zeus : facing error regarding hostapd #zeus

[Zoran]

> Log file in:
> /home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/
> imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/
*log.do_rootfs.31340*

Could you, please, attach a log file?

Thank you,
Zoran
___


On Wed, May 12, 2021 at 2:01 PM rohit jadhav 
wrote:

> Facing following issue :
> ERROR: core-image-minimal-1.0-r0 do_rootfs: Postinstall scriptlets of
> ['hostapd'] have failed. If the intention is to defer them to first boot,
> then please place them into pkg_postinst_ontarget_${PN} ().
> Deferring to first boot via 'exit 1' is no longer supported.
> Details of the failure are in
> /home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.
> ERROR: Logfile of failure stored in:
> /home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.31340
> ERROR: Task
> (/home/tel/imx_yocto_bsp_Zeus/Yocto_setup/sources/poky/meta/recipes-core/images/core-image-minimal.bb:do_rootfs)
> failed with exit code '1'
>
> Please guide me if anyone have any idea to resolve.
>
> Thanks in advance.
> 
>
>

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

Re: [yocto] Understanding kernel patching in linux-yocto

[Yann Dirson]

Le mer. 12 mai 2021 à 16:25, Bruce Ashfield  a écrit :
>
> On Wed, May 12, 2021 at 10:07 AM Yann Dirson
>  wrote:
> >
> > Thanks for those clarifications!
> >
> > Some additional questions below
> >
> > Le mer. 12 mai 2021 à 15:19, Bruce Ashfield  a 
> > écrit :
> > >
> > > On Wed, May 12, 2021 at 7:14 AM Yann Dirson  
> > > wrote:
> > > >
> > > > I am currently working on a kmeta BSP for the rockchip-based NanoPI M4
> > > > [1], and I'm wondering how I should be providing kernel patches, as
> > > > just add ing "patch" directives in the .scc does not get them applied
> > > > unless the particular .scc gets included in KERNEL_FEATURES (see [2]).
> > > >
> > > > From an old thread [3] I understand that the patches from the standard
> > > > kmeta snippets are already applied to the tree, and that to get the
> > > > patches from my BSP I'd need to reference it explicitly in SRC_URI
> > > > (along with using "nopatch" in the right places to avoid the
> > > > already-applied patches to get applied twice).
> > > >
> > > > I have the feeling that I'm lacking the rationale behind this, and
> > > > would need to understand this better to make things right in this BSP.
> > > > Especially:
> > > > - at first sight, having the patches both applied to linux-yocto and
> > > > referenced in yocto-kernel-cache just to be skipped on parsing looks
> > > > like both information duplication and parsing of unused lines
> > >
> > > At least some of this is mentioned in the advanced section of the
> > > kernel-dev manual, but I can summarize/reword things here, and
> > > I'm also doing a presentation related to this in the Yocto summit at
> > > the end of this month.
> > >
> > > The big thing to remember, is that the configuration and changes
> > > you see in that repository, are not only for yocto purposes. The
> > > concepts and structure pre-date when they were first brought in
> > > to generate reference kernels over 10 years ago (the implementation
> > > has changed, but the concepts are still the same). To this day,
> > > there still are cases that they are used with just a kernel tree and
> > > cross toolchain.
> > >
> > > With that in mind, the meta-data is used for many different things
> > >
> > >  - It organizes patches / features and their configuration into
> > >reusable blocks. At the same time documenting the changes
> > >that we have applied to a tree
> > >  - It makes those patches and configuration blocks available to
> > >other kernel trees (for whatever reason).
> > >  - It configures the tree during the build process, reusing both
> > >configuration only and patch + configuration blocks
> >
> > >  - It is used to generate a history clean tree from scratch for
> > >each new supported kernel. Which is what I do when creating
> > >new linux-yocto-dev references, and the new /standard/*
> > >branches in linux-yocto.
> >
> > I'd think (and I take your further remarks about workflow as confirming
> > this), that when upgrading the kernel the best tool would be git-rebase.
> > Then, regenerating the linux-yocto branches would only be a akin to a
> > check that the metadata is in sync with the new tree you rebased ?
>
> The best of anything is a matter of opinion. I heavily use git-rebase and
> sure, you could use it to do something similar here. But the result is
> the same. There's still heavy use of quilt in kernel circles. Workflows
> don't change easily, and as long as they work for the maintainer, they
> tend to stay put. Asking someone to change their workflow, rarely goes
> over well.
>
> >
> > If that conclusion is correct, wouldn't it be possible to avoid using the
> > linux-yocto branches directly, and let all the patches be applied at
> > do_patch time ?  That would be much more similar to the standard
> > package workflow (and thus lower the barrier for approaching the
> > kernel packages).
>
> That's something we did in the past, and sure, you can do anything.
> But patching hundreds of changes at build time means constant
> failures .. again, I've been there and done that. We use similar patches
> in many different contexts and optional stackings. You simply cannot
> maintain them and stay sane by whacking patches onto the SRC_URI.
> The last impression you want when someone builds your kernel is that
> they can't even get past the patch phase.  So that's a hard no, to how
> the reference kernels are maintained (and that hard no has been around
> for 11 years now).
>
> Also, we maintain contributed reference BSPs in that same tree, that
> are yanking in SDKs from vendors, etc, they are in the thousands of
> patches. So you need the tree and the BSP branches to support that.

That pretty much clarifies the whole thing, thanks for taking the time for this!

>
> >
> >
> > > So why not just drop all the patches in the SRC_URI ? Been there,
> > > done that. It fails spectacularly when you are managing queues of
> > > hundreds of potentially conflicting patches (rt, yaffs, aufs, 

Re: [yocto] Understanding kernel patching in linux-yocto

[Bruce Ashfield]

On Wed, May 12, 2021 at 10:07 AM Yann Dirson
 wrote:
>
> Thanks for those clarifications!
>
> Some additional questions below
>
> Le mer. 12 mai 2021 à 15:19, Bruce Ashfield  a 
> écrit :
> >
> > On Wed, May 12, 2021 at 7:14 AM Yann Dirson  
> > wrote:
> > >
> > > I am currently working on a kmeta BSP for the rockchip-based NanoPI M4
> > > [1], and I'm wondering how I should be providing kernel patches, as
> > > just add ing "patch" directives in the .scc does not get them applied
> > > unless the particular .scc gets included in KERNEL_FEATURES (see [2]).
> > >
> > > From an old thread [3] I understand that the patches from the standard
> > > kmeta snippets are already applied to the tree, and that to get the
> > > patches from my BSP I'd need to reference it explicitly in SRC_URI
> > > (along with using "nopatch" in the right places to avoid the
> > > already-applied patches to get applied twice).
> > >
> > > I have the feeling that I'm lacking the rationale behind this, and
> > > would need to understand this better to make things right in this BSP.
> > > Especially:
> > > - at first sight, having the patches both applied to linux-yocto and
> > > referenced in yocto-kernel-cache just to be skipped on parsing looks
> > > like both information duplication and parsing of unused lines
> >
> > At least some of this is mentioned in the advanced section of the
> > kernel-dev manual, but I can summarize/reword things here, and
> > I'm also doing a presentation related to this in the Yocto summit at
> > the end of this month.
> >
> > The big thing to remember, is that the configuration and changes
> > you see in that repository, are not only for yocto purposes. The
> > concepts and structure pre-date when they were first brought in
> > to generate reference kernels over 10 years ago (the implementation
> > has changed, but the concepts are still the same). To this day,
> > there still are cases that they are used with just a kernel tree and
> > cross toolchain.
> >
> > With that in mind, the meta-data is used for many different things
> >
> >  - It organizes patches / features and their configuration into
> >reusable blocks. At the same time documenting the changes
> >that we have applied to a tree
> >  - It makes those patches and configuration blocks available to
> >other kernel trees (for whatever reason).
> >  - It configures the tree during the build process, reusing both
> >configuration only and patch + configuration blocks
>
> >  - It is used to generate a history clean tree from scratch for
> >each new supported kernel. Which is what I do when creating
> >new linux-yocto-dev references, and the new /standard/*
> >branches in linux-yocto.
>
> I'd think (and I take your further remarks about workflow as confirming
> this), that when upgrading the kernel the best tool would be git-rebase.
> Then, regenerating the linux-yocto branches would only be a akin to a
> check that the metadata is in sync with the new tree you rebased ?

The best of anything is a matter of opinion. I heavily use git-rebase and
sure, you could use it to do something similar here. But the result is
the same. There's still heavy use of quilt in kernel circles. Workflows
don't change easily, and as long as they work for the maintainer, they
tend to stay put. Asking someone to change their workflow, rarely goes
over well.

>
> If that conclusion is correct, wouldn't it be possible to avoid using the
> linux-yocto branches directly, and let all the patches be applied at
> do_patch time ?  That would be much more similar to the standard
> package workflow (and thus lower the barrier for approaching the
> kernel packages).

That's something we did in the past, and sure, you can do anything.
But patching hundreds of changes at build time means constant
failures .. again, I've been there and done that. We use similar patches
in many different contexts and optional stackings. You simply cannot
maintain them and stay sane by whacking patches onto the SRC_URI.
The last impression you want when someone builds your kernel is that
they can't even get past the patch phase.  So that's a hard no, to how
the reference kernels are maintained (and that hard no has been around
for 11 years now).

Also, we maintain contributed reference BSPs in that same tree, that
are yanking in SDKs from vendors, etc, they are in the thousands of
patches. So you need the tree and the BSP branches to support that.

>
>
> > So why not just drop all the patches in the SRC_URI ? Been there,
> > done that. It fails spectacularly when you are managing queues of
> > hundreds of potentially conflicting patches (rt, yaffs, aufs, ... etc, etc)
> > and then attempting to constantly merge -stable and other kernel
> > trees into the repository. git is the tool for managing that, not stacks
> > of patches. You spend your entire life fixing patch errors and refreshing
> > fuzz (again, been there, done that).
> >
> > So why not just keep a history and 

Re: [yocto] Understanding kernel patching in linux-yocto

[Yann Dirson]

Thanks for those clarifications!

Some additional questions below

Le mer. 12 mai 2021 à 15:19, Bruce Ashfield  a écrit :
>
> On Wed, May 12, 2021 at 7:14 AM Yann Dirson  
> wrote:
> >
> > I am currently working on a kmeta BSP for the rockchip-based NanoPI M4
> > [1], and I'm wondering how I should be providing kernel patches, as
> > just add ing "patch" directives in the .scc does not get them applied
> > unless the particular .scc gets included in KERNEL_FEATURES (see [2]).
> >
> > From an old thread [3] I understand that the patches from the standard
> > kmeta snippets are already applied to the tree, and that to get the
> > patches from my BSP I'd need to reference it explicitly in SRC_URI
> > (along with using "nopatch" in the right places to avoid the
> > already-applied patches to get applied twice).
> >
> > I have the feeling that I'm lacking the rationale behind this, and
> > would need to understand this better to make things right in this BSP.
> > Especially:
> > - at first sight, having the patches both applied to linux-yocto and
> > referenced in yocto-kernel-cache just to be skipped on parsing looks
> > like both information duplication and parsing of unused lines
>
> At least some of this is mentioned in the advanced section of the
> kernel-dev manual, but I can summarize/reword things here, and
> I'm also doing a presentation related to this in the Yocto summit at
> the end of this month.
>
> The big thing to remember, is that the configuration and changes
> you see in that repository, are not only for yocto purposes. The
> concepts and structure pre-date when they were first brought in
> to generate reference kernels over 10 years ago (the implementation
> has changed, but the concepts are still the same). To this day,
> there still are cases that they are used with just a kernel tree and
> cross toolchain.
>
> With that in mind, the meta-data is used for many different things
>
>  - It organizes patches / features and their configuration into
>reusable blocks. At the same time documenting the changes
>that we have applied to a tree
>  - It makes those patches and configuration blocks available to
>other kernel trees (for whatever reason).
>  - It configures the tree during the build process, reusing both
>configuration only and patch + configuration blocks

>  - It is used to generate a history clean tree from scratch for
>each new supported kernel. Which is what I do when creating
>new linux-yocto-dev references, and the new /standard/*
>branches in linux-yocto.

I'd think (and I take your further remarks about workflow as confirming
this), that when upgrading the kernel the best tool would be git-rebase.
Then, regenerating the linux-yocto branches would only be a akin to a
check that the metadata is in sync with the new tree you rebased ?

If that conclusion is correct, wouldn't it be possible to avoid using the
linux-yocto branches directly, and let all the patches be applied at
do_patch time ?  That would be much more similar to the standard
package workflow (and thus lower the barrier for approaching the
kernel packages).


> So why not just drop all the patches in the SRC_URI ? Been there,
> done that. It fails spectacularly when you are managing queues of
> hundreds of potentially conflicting patches (rt, yaffs, aufs, ... etc, etc)
> and then attempting to constantly merge -stable and other kernel
> trees into the repository. git is the tool for managing that, not stacks
> of patches. You spend your entire life fixing patch errors and refreshing
> fuzz (again, been there, done that).
>
> So why not just keep a history and constantly merge new versions
> into it ? Been there, done that. You end up with an absolute garbage
> history of octopus merges and changes that are completely hidden,
> non-obvious and useless for collaborating with other kernel projects.
> Try merging a new kernel version into those same big features, it's
> nearly impossible and you have a franken-kernel that you end up trying
> to support and fix yourself. All the bugs are yours and yours alone.
>
> So that's why there's a repository that tracks the patches and the
> configuration and is used for multiple purposes. Keeping the patches
> and config blocks separate would just lead to even more errors as
> I update one and forget the other, etc, etc. There have been various
> incarnations of the tools that also did different things with the patches,
> and they weren't skipped, but detected as applied or not on-the-fly,
> so there are other historical reasons for the structure as well.
>
> > - kernel-yocto.bbclass does its own generic job of locating a proper
> > BSP using the KMACHINE/KTYPE/KARCH tags in BSP, it looks like
> > specifying a specific BSP file would just defeat of this: how should I
> > deal with this case where I'm providing both "standard" and "tiny"
> > KTYPE's ?
>
> I'm not quite following the question here, so I can try to answer badly
> and you can clarify based 

Re: [yocto] [bitbake-devel] Git Fetcher Branch Default

[Martin Jansa]

On Wed, May 12, 2021 at 05:51:24AM -0700, Chuck Wolber wrote:
> I got a fetcher failure on go-systemd today, which puzzled me. That
> recipe has not changed in ages, and the SRCPV hash is clearly visible
> in the repository.
> 
> After looking at it closer, it seems that github.com/coreos/go-systemd
> has changed its default branch from master to main about six days ago.
> This appears to break a fundamental assumption on the part of the
> fetcher when looking for SRCREV and SRCPV hashes.
> 
> Looking at lib/bb/fetch2/git.py makes it evident that this is the
> case. I can trivially fix this with a .bbappend, but it seems to me
> that the fundamental default branch assumption needs to be updated.
> 
> Has anyone discussed adding main to the list of default branches to
> try? If not, I may be able to come up with a patch, but the code does
> process default branches as a list, so I will need to think a bit on
> the best way to approach this. Any guidance would be appreciated.

I agree it's a bit annoying that some projects have chosen to rename the
existing branches instead of just adopting "main" to be the default
branch only for new projects (as the defaults changed e.g. on github).

I've already added explicit branch=main in 10+ recipes in various layers
for dunfell and newer branches (ostree in meta-oe just today or e.g.
https://github.com/ros/meta-ros/pull/846 yesterday).

Luckily it's easy to fix with local bbappend, so even people using
unsupported release (zeus and older) can do so or finally upgrade to
some supported release which might have this fix already.

It was also discussed shortly in #yocto yeasterday:

22:38 < zeddii> RP: did we come up with a policy on anything we can do
with the fetcher to make "main" be a fallback default to master. Or was
the end decision to just add explicit branch statements everywhere ?
23:21 < RP> zeddii: I'm open to patch proposals or we just set the
branch on urls
23:23 < RP> zeddii: being explicit is perhaps the better option that
magic in the fetcher

And I agree with RP, especially because fetcher magic won't get
backported to old bitbake used in zeus and older anyway, so it won't
help there and backporting fetcher change locally will be more risky
than backporting simple SRC_URI change for individual recipes which need
it.

Regards,


signature.asc
Description: PGP signature

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

Re: [yocto] [bitbake-devel] Git Fetcher Branch Default

[Konrad Weihmann]

On 12 May 2021 14:51, Chuck Wolber  wrote:I got a fetcher failure on go-systemd today, which puzzled me. That

recipe has not changed in ages, and the SRCPV hash is clearly visible

in the repository.



After looking at it closer, it seems that github.com/coreos/go-systemd

has changed its default branch from master to main about six days ago.

This appears to break a fundamental assumption on the part of the

fetcher when looking for SRCREV and SRCPV hashes.



Looking at lib/bb/fetch2/git.py makes it evident that this is the

case. I can trivially fix this with a .bbappend, but it seems to me

that the fundamental default branch assumption needs to be updated.Iirc there has been the same discussion already last year or the year before... and the agreement was to leave it as it is. IMHO most of the used projects still go with master instead of main, so a patch of yours would create a lot of work for the majority of the recipes.And as there is the branch attribute for the git fetcher already available (and widely used for especially these cases) I personally don't see the need for such a patch, unless it provides full backward compatibility



Has anyone discussed adding main to the list of default branches to

try? If not, I may be able to come up with a patch, but the code does

process default branches as a list, so I will need to think a bit on

the best way to approach this. Any guidance would be appreciated.



..Ch:W..





-- 

"Perfection must be reached by degrees; she requires the slow hand of

time." - Voltaire









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

Re: [yocto] Understanding kernel patching in linux-yocto

[Bruce Ashfield]

On Wed, May 12, 2021 at 7:14 AM Yann Dirson  wrote:
>
> I am currently working on a kmeta BSP for the rockchip-based NanoPI M4
> [1], and I'm wondering how I should be providing kernel patches, as
> just add ing "patch" directives in the .scc does not get them applied
> unless the particular .scc gets included in KERNEL_FEATURES (see [2]).
>
> From an old thread [3] I understand that the patches from the standard
> kmeta snippets are already applied to the tree, and that to get the
> patches from my BSP I'd need to reference it explicitly in SRC_URI
> (along with using "nopatch" in the right places to avoid the
> already-applied patches to get applied twice).
>
> I have the feeling that I'm lacking the rationale behind this, and
> would need to understand this better to make things right in this BSP.
> Especially:
> - at first sight, having the patches both applied to linux-yocto and
> referenced in yocto-kernel-cache just to be skipped on parsing looks
> like both information duplication and parsing of unused lines

At least some of this is mentioned in the advanced section of the
kernel-dev manual, but I can summarize/reword things here, and
I'm also doing a presentation related to this in the Yocto summit at
the end of this month.

The big thing to remember, is that the configuration and changes
you see in that repository, are not only for yocto purposes. The
concepts and structure pre-date when they were first brought in
to generate reference kernels over 10 years ago (the implementation
has changed, but the concepts are still the same). To this day,
there still are cases that they are used with just a kernel tree and
cross toolchain.

With that in mind, the meta-data is used for many different things

 - It organizes patches / features and their configuration into
   reusable blocks. At the same time documenting the changes
   that we have applied to a tree
 - It makes those patches and configuration blocks available to
   other kernel trees (for whatever reason).
 - It configures the tree during the build process, reusing both
   configuration only and patch + configuration blocks
 - It is used to generate a history clean tree from scratch for
   each new supported kernel. Which is what I do when creating
   new linux-yocto-dev references, and the new /standard/*
   branches in linux-yocto.

So why not just drop all the patches in the SRC_URI ? Been there,
done that. It fails spectacularly when you are managing queues of
hundreds of potentially conflicting patches (rt, yaffs, aufs, ... etc, etc)
and then attempting to constantly merge -stable and other kernel
trees into the repository. git is the tool for managing that, not stacks
of patches. You spend your entire life fixing patch errors and refreshing
fuzz (again, been there, done that).

So why not just keep a history and constantly merge new versions
into it ? Been there, done that. You end up with an absolute garbage
history of octopus merges and changes that are completely hidden,
non-obvious and useless for collaborating with other kernel projects.
Try merging a new kernel version into those same big features, it's
nearly impossible and you have a franken-kernel that you end up trying
to support and fix yourself. All the bugs are yours and yours alone.

So that's why there's a repository that tracks the patches and the
configuration and is used for multiple purposes. Keeping the patches
and config blocks separate would just lead to even more errors as
I update one and forget the other, etc, etc. There have been various
incarnations of the tools that also did different things with the patches,
and they weren't skipped, but detected as applied or not on-the-fly,
so there are other historical reasons for the structure as well.

> - kernel-yocto.bbclass does its own generic job of locating a proper
> BSP using the KMACHINE/KTYPE/KARCH tags in BSP, it looks like
> specifying a specific BSP file would just defeat of this: how should I
> deal with this case where I'm providing both "standard" and "tiny"
> KTYPE's ?

I'm not quite following the question here, so I can try to answer badly
and you can clarify based on my terrible answer.

The tools can locate your "bsp entry point" / "bsp definition" in
your layer. Either provided by something on the SRC_URI or something
in a kmeta repository (also specified on the SRC_URI).  Since
both of those are added to the search paths they check. Those
are just .scc files with a specified KMACHINE/KTYPE that match, and
as you could guess from my first term I used, they are the entry
point into building the configuration queue.

That's where you start inheriting the base configuration(s) and including
feature blocks, etc. Those definitions are exactly the same as the
internal ones in the kernel-cache repository. By default, that located
BSP definition is excluded from inheriting patches .. because as you
noted, it would start trying to re-apply changes to the tree. It is there
to get the configuration blocks, 

[yocto] Git Fetcher Branch Default

[Chuck Wolber]

I got a fetcher failure on go-systemd today, which puzzled me. That
recipe has not changed in ages, and the SRCPV hash is clearly visible
in the repository.

After looking at it closer, it seems that github.com/coreos/go-systemd
has changed its default branch from master to main about six days ago.
This appears to break a fundamental assumption on the part of the
fetcher when looking for SRCREV and SRCPV hashes.

Looking at lib/bb/fetch2/git.py makes it evident that this is the
case. I can trivially fix this with a .bbappend, but it seems to me
that the fundamental default branch assumption needs to be updated.

Has anyone discussed adding main to the list of default branches to
try? If not, I may be able to come up with a patch, but the code does
process default branches as a list, so I will need to think a bit on
the best way to approach this. Any guidance would be appreciated.

..Ch:W..


-- 
"Perfection must be reached by degrees; she requires the slow hand of
time." - Voltaire

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

[yocto] Yocto Zeus : facing error regarding hostapd #zeus

[rohit jadhav]

Facing following issue :
ERROR: core-image-minimal-1.0-r0 do_rootfs: Postinstall scriptlets of 
['hostapd'] have failed. If the intention is to defer them to first boot,
then please place them into pkg_postinst_ontarget_${PN} ().
Deferring to first boot via 'exit 1' is no longer supported.
Details of the failure are in 
/home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.
ERROR: Logfile of failure stored in: 
/home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.31340
ERROR: Task 
(/home/tel/imx_yocto_bsp_Zeus/Yocto_setup/sources/poky/meta/recipes-core/images/core-image-minimal.bb:do_rootfs)
 failed with exit code '1'

Please guide me if anyone have any idea to resolve.

Thanks in advance.

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

[yocto] Understanding kernel patching in linux-yocto

[Yann Dirson]

I am currently working on a kmeta BSP for the rockchip-based NanoPI M4
[1], and I'm wondering how I should be providing kernel patches, as
just add ing "patch" directives in the .scc does not get them applied
unless the particular .scc gets included in KERNEL_FEATURES (see [2]).

>From an old thread [3] I understand that the patches from the standard
kmeta snippets are already applied to the tree, and that to get the
patches from my BSP I'd need to reference it explicitly in SRC_URI
(along with using "nopatch" in the right places to avoid the
already-applied patches to get applied twice).

I have the feeling that I'm lacking the rationale behind this, and
would need to understand this better to make things right in this BSP.
Especially:
- at first sight, having the patches both applied to linux-yocto and
referenced in yocto-kernel-cache just to be skipped on parsing looks
like both information duplication and parsing of unused lines
- kernel-yocto.bbclass does its own generic job of locating a proper
BSP using the KMACHINE/KTYPE/KARCH tags in BSP, it looks like
specifying a specific BSP file would just defeat of this: how should I
deal with this case where I'm providing both "standard" and "tiny"
KTYPE's ?

[1] https://lists.yoctoproject.org/g/yocto/message/53454
[2] https://lists.yoctoproject.org/g/yocto/message/53452
[3] https://lists.yoctoproject.org/g/yocto/topic/61340326

Best regards,
-- 
Yann Dirson 
Blade / Shadow -- http://shadow.tech

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

Re: [yocto] [qa-build-notification] QA notification for completed autobuilder build (yocto-3.2.4.rc1)

[Sangeeta Jain]

Hello All,

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

=== Summary 
No high milestone defects.

One new issue found:

Bug 14392 - [QA 3.2.4 RC1] failure in ptest : ptestresult.lttng-tools.tools


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

Thanks,
Sangeeta

> -Original Message-
> From: qa-build-notificat...@lists.yoctoproject.org  notificat...@lists.yoctoproject.org> On Behalf Of Pokybuild User
> Sent: Friday, 7 May, 2021 12:06 AM
> To: yocto@lists.yoctoproject.org
> Cc: qa-build-notificat...@lists.yoctoproject.org
> Subject: [qa-build-notification] QA notification for completed autobuilder 
> build
> (yocto-3.2.4.rc1)
> 
> 
> A build flagged for QA (yocto-3.2.4.rc1) was completed on the autobuilder and 
> is
> available at:
> 
> 
> https://autobuilder.yocto.io/pub/releases/yocto-3.2.4.rc1
> 
> 
> Build hash information:
> 
> bitbake: e05d79a6ed92c9ce17b90fd5fb6186898a7b3bf8
> meta-arm: 39bc4076b2d9a662111beaa0621ee9c1e37f56ea
> meta-gplv2: 6e8e969590a22a729db1ff342de57f2fd5d02d43
> meta-intel: c325d3e2eab9952dc175a38f31b78fecdcdd0fcc
> meta-kernel: 4b288396eff43fe9b1a233aed1ce9b48329a2eb6
> meta-mingw: 352d8b0aa3c7bbd5060a4cc2ebe7c0e964de4879
> oecore: d47b7cdc3508343349f3bb3eacb2dc3227dd94d2
> poky: 60c8482769f38a4db6f38d525405c887794511a9
> 
> 
> 
> This is an automated message from the Yocto Project Autobuilder
> Git: git://git.yoctoproject.org/yocto-autobuilder2
> Email: richard.pur...@linuxfoundation.org
> 
> 
> 
> 
> 
> 
> 


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

Re: [yocto] Recipe Grep'ing

[Chuck Wolber]

On Sat, May 8, 2021 at 6:25 PM Robert Joslyn
 wrote:

> There is the oe-stylize.py script that attempts to format recipes
> according to the style guide:
> https://git.openembedded.org/meta-openembedded/tree/contrib/oe-stylize.py
>
> Last time I played with it, I was a bit disappointed with some of the
> changes it makes, some of which are different than what devtool does.
> When I need to introduce new developers to bitbake, I'd love to be able
> to hand them oe-stylize or something similar and just tell them to run
> it before committing to make sure everything is formatted consistently.
>
> I've had updating oe-stylize.py on my TODO list for a while, but more
> important things always come up.

Given what I have seen so far, I am wondering if that is the right
place to start.

To summarize:

There appears to be general agreement that the idea is a good one, but a large
patch wall is considered rather objectionable by at least Bruce Ashfield.

Khem Raj brought up a good point that a big change like the one I am proposing
needs some sort of tooling to make sure we do not regress.

And the above reply from Robert Joslyn has me wondering if there is already
something in place to do the linting Khem Raj is referring to, or if
oe-stylize.py
would form the basis for such a tool if we added it to an automated system.

So taking a step back, does it make sense to update the guidance on the
styleguide (https://www.openembedded.org/wiki/Styleguide) page first?

If so, I would be happy to make the updates. I requested an account,
but I got an
error - "Error sending mail: Unknown error in PHP's mail() function."

..Ch:W..

-- 
"Perfection must be reached by degrees; she requires the slow hand of
time." - Voltaire

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