Date   

Re: Yocto Zeus : facing error regarding hostapd #zeus

Zoran
 

Hello Rohit,

It is a good find. I also googled for the error, and found this as an
explanation:
https://www.yoctoproject.org/pipermail/yocto/2019-February/044153.html

I included Alex (Kanavin), who created the above mail.

Maybe Alex can give more light on the problem?

In the meantime, you should explore (by similarities) this pointer in
very details:
https://github.com/Xilinx/meta-virtualization/issues/4#issuecomment-590532621

Zoran
_______

On Thu, May 13, 2021 at 8:25 AM rohit jadhav <rohitbjadhav1@...> wrote:

Hi Zoran,
log.do_rootfs.31340is linked to log.do_rootfs I have checked with ls command, So both files are identical.

While surfing I found similar thread but its for different package its as follows :
https://github.com/Xilinx/meta-virtualization/issues/4

Can you please help out with this for our Package Hostapd ?

Thanks and Regards
Rohit

On Thu, May 13, 2021 at 10:18 AM Zoran Stojsavljevic <zoran.stojsavljevic@...> wrote:

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 <rohitbjadhav1@...> 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 <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 <rohitbjadhav1@...> 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.


Re: Yocto Zeus : facing error regarding hostapd #zeus

rohit jadhav
 

Hi Zoran,
   log.do_rootfs.31340is linked to log.do_rootfs I have checked with ls command, So both files are identical.

While surfing I found similar thread but its for different package  its as follows :

Can you please help out with this for our Package Hostapd ?

Thanks and Regards
Rohit


On Thu, May 13, 2021 at 10:18 AM Zoran Stojsavljevic <zoran.stojsavljevic@...> wrote:
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 <rohitbjadhav1@...> 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 <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 <rohitbjadhav1@...> 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.
>>>
>>>


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

Changqing Li
 

On 5/13/21 11:48 AM, Khem Raj wrote:
[Please note: This e-mail is from an EXTERNAL e-mail address]

On 5/12/21 8:42 PM, Changqing Li wrote:
From: Changqing Li <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.
ok

Signed-off-by: Changqing Li <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; \




Re: 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 <rohitbjadhav1@...> 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 <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 <rohitbjadhav1@...> 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.


Re: [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 <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 <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; \


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

Changqing Li
 

From: Changqing Li <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 <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


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

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@...>
---
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


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

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@...>
---
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 0000000..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:root@...
+#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
+#selinux SELinux 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 0000000..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


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

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@...>
---
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


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

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@...>
---
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


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

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@...>
---
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


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

Armin Kuster
 

Drop patch now included in updated

Signed-off-by: Armin Kuster <akuster808@...>
---
.../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..0000000
--- 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 *)&function; /* kgold */
- | ^~~~~~~~~~~~~~~~~~~
-cc1: all warnings being treated as errors
-
-Upstream-Status: Submitted
-
-Signed-off-by: Jens Rehsack <sno@...>
-
-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 *)&function; /* kgold */
-+ memcpy(&s_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<pver>).tar.gz"

S = "${WORKDIR}/src"

--
2.25.1


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

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@...>
---
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


Re: 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 <onyx22574@...> 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




Re: FW: Yocto Distro Testing Plan

Richard Purdie
 

On Wed, 2021-05-12 at 18:48 +0000, 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


Yocto with xtensa

onyx22574@...
 

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


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
<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 <sjolley.yp.pm@...> 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




FW: Yocto Distro Testing Plan

Kraft, George <George.Kraft@...>
 

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.XXXX
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

 


Re: Understanding kernel patching in linux-yocto

Diego Santa Cruz
 

-----Original Message-----
From: yocto@... <yocto@...> On
Behalf Of Bruce Ashfield via lists.yoctoproject.org
Sent: 12 May 2021 16:25
To: Yann Dirson <yann.dirson@...>
Cc: Yocto discussion list <yocto@...>
Subject: Re: [yocto] Understanding kernel patching in linux-yocto

On Wed, May 12, 2021 at 10:07 AM Yann Dirson
<yann.dirson@...> wrote:

Thanks for those clarifications!

Some additional questions below

Le mer. 12 mai 2021 à 15:19, Bruce Ashfield <bruce.ashfield@...> a
écrit :

On Wed, May 12, 2021 at 7:14 AM Yann Dirson <yann.dirson@blade-
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 <version>/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 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 answer is indeed quite useful for a question that may not be that clear
:)

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, patches come in via other feature
blocks or directly on the SRC_URI.

So in your case, just provide the two .scc file with the proper
defines so they can be located, and you'll get the proper branch
located in the tree, and the base configurations picked up for those
kernel types. You'd supply your BSP specific config by making
a common file and including it in both definitions, and patches by
a KERNEL_FEATURE variable or by specifying them directly on
the SRC_URI (via .patch or via a different .scc file).
That's what I was experimenting with at the same time, and something like
this does indeed produce the expected output:

KERNEL_FEATURES_append = " bsp/rockchip/nanopi-m4-
${LINUX_KERNEL_TYPE}.scc"

However, it seems confusing, as that .scc is precisely the one that's
already selected
and used for the .cfg: it really looks like we're overriding the
default "bsp entry point"
with a value that's already the default, but with a different result.
Yes, that's one way that we've structured things as the tools evolved
to balance external BSP definitions being able to pull in the base
configuration but not patches. There are two runs of the tools, one looks
for patches (and excludes that bsp entry point) and one that builds the
config.queue (and uses the entry point). That's the balance of the multi
use nature of the configuration blocks. I could bury something deeper
in the tools to hide a bit of that, but it will break uses cases and time
has shown that it is brittle.


So my gut feeling ATM is that everything should be much more clear if
specifying the default entry point would have the same effect as leaving
the default be used, ie. having patches be applied in both cases.
The variable KMETA_EXTERNAL_BSPS was created as a knob to
allow an external definition to both be used for patches AND configuration.
But that is for fully exernal BSPs that do not include the base kernel
meta-data, since once you turn that on, you are getting all the patches
and all the configuration .. and will have the patches applied twice.
For what its worth I am using KMETA_EXTERNAL_BSPS in a BSP definition file in an in-recipe kernel metadata tree (but I guess it could be off recipe too), and that metadata tree includes scc files from yocto-kernel-cache, the trick is to add the nopatch tag when including scc files from yocto-kernel-cache for which do not want or need the patches.

With KMETA_EXTERNAL_BSPS was added I switched to that and removed the equivalent of your
KERNEL_FEATURES_append = " bsp/rockchip/nanopi-m4-${LINUX_KERNEL_TYPE}.scc"
that is kind of confusing and includes things twice.

--
Diego Santa Cruz, PhD
Technology Architect
spinetix.com


Re: [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 <raj.khem@...>
Cc: Ross Burton <ross.burton@...>
Awesome! Thanks for sorting this one out :-)
Applied to meta-rockchip master.

3941 - 3960 of 57407