Date   

[meta-rockchip][PATCH 2/4] wic console device and baud

Trevor Woerner
 

Take the console device and baud settings from the MACHINE configurations and
reuse them in the wic files. This reduces duplication and eliminates a
potential source of mistakes.

Signed-off-by: Trevor Woerner <twoerner@gmail.com>
---
conf/machine/include/rockchip-defaults.inc | 2 +-
wic/firefly-rk3288.wks | 2 +-
wic/rock-pi-4.wks | 2 +-
wic/rock-pi-e.wks | 2 +-
wic/tinker-board.wks | 2 +-
wic/vyasa-rk3288.wks | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/conf/machine/include/rockchip-defaults.inc b/conf/machine/include/rockchip-defaults.inc
index fe4052e..3e7a2f2 100644
--- a/conf/machine/include/rockchip-defaults.inc
+++ b/conf/machine/include/rockchip-defaults.inc
@@ -28,5 +28,5 @@ IMAGE_FSTYPES += "ext4"

# boot device (sd-card/emmc)
RK_BOOT_DEVICE ??= "mmcblk0"
-WICVARS_append = " RK_BOOT_DEVICE"
+WICVARS_append = " RK_BOOT_DEVICE RK_CONSOLE_BAUD RK_CONSOLE_DEVICE"

diff --git a/wic/firefly-rk3288.wks b/wic/firefly-rk3288.wks
index da0067f..7b14d1f 100644
--- a/wic/firefly-rk3288.wks
+++ b/wic/firefly-rk3288.wks
@@ -4,4 +4,4 @@
include rk3288-boot.wks
part / --ondisk ${RK_BOOT_DEVICE} --source rootfs --fstype=ext4 --label root

-bootloader --ptable gpt --append="console=tty1 console=ttyS2,115200n8 rw root=/dev/${RK_BOOT_DEVICE}p7 rootfstype=ext4 init=/sbin/init"
+bootloader --ptable gpt --append="console=tty1 console=${RK_CONSOLE_DEVICE},${RK_CONSOLE_BAUD}n8 rw root=/dev/${RK_BOOT_DEVICE}p7 rootfstype=ext4 init=/sbin/init"
diff --git a/wic/rock-pi-4.wks b/wic/rock-pi-4.wks
index c6174a9..5c02e9f 100644
--- a/wic/rock-pi-4.wks
+++ b/wic/rock-pi-4.wks
@@ -4,4 +4,4 @@
include rk3399-boot.wks
part / --ondisk ${RK_BOOT_DEVICE} --source rootfs --fstype=ext4 --label root

-bootloader --ptable gpt --append="console=tty1 console=ttyS2,1500000n8 rw root=/dev/${RK_BOOT_DEVICE}p7 rootfstype=ext4 init=/sbin/init"
+bootloader --ptable gpt --append="console=tty1 console=${RK_CONSOLE_DEVICE},${RK_CONSOLE_BAUD}n8 rw root=/dev/${RK_BOOT_DEVICE}p7 rootfstype=ext4 init=/sbin/init"
diff --git a/wic/rock-pi-e.wks b/wic/rock-pi-e.wks
index 97f84d1..9c10d90 100644
--- a/wic/rock-pi-e.wks
+++ b/wic/rock-pi-e.wks
@@ -1,4 +1,4 @@
include rk3328-boot.wks
part / --ondisk ${RK_BOOT_DEVICE} --source rootfs --fstype=ext4 --label root

-bootloader --ptable gpt --append="console=tty1 console=ttyS2,1500000n8 rw root=/dev/${RK_BOOT_DEVICE}p7 rootfstype=ext4 init=/sbin/init"
+bootloader --ptable gpt --append="console=tty1 console=${RK_CONSOLE_DEVICE},${RK_CONSOLE_BAUD}n8 rw root=/dev/${RK_BOOT_DEVICE}p7 rootfstype=ext4 init=/sbin/init"
diff --git a/wic/tinker-board.wks b/wic/tinker-board.wks
index 5a63ce0..00ae820 100644
--- a/wic/tinker-board.wks
+++ b/wic/tinker-board.wks
@@ -5,4 +5,4 @@ include rk3288-boot.wks

part / --ondisk ${RK_BOOT_DEVICE} --source rootfs --fstype=ext4 --label root

-bootloader --ptable gpt --append="console=tty1 console=ttyS2,115200n8 rw root=/dev/${RK_BOOT_DEVICE}p7 rootfstype=ext4 init=/sbin/init"
+bootloader --ptable gpt --append="console=tty1 console=${RK_CONSOLE_DEVICE},${RK_CONSOLE_BAUD}n8 rw root=/dev/${RK_BOOT_DEVICE}p7 rootfstype=ext4 init=/sbin/init"
diff --git a/wic/vyasa-rk3288.wks b/wic/vyasa-rk3288.wks
index 5db65df..5346fbd 100644
--- a/wic/vyasa-rk3288.wks
+++ b/wic/vyasa-rk3288.wks
@@ -4,5 +4,5 @@
include rk3288-boot.wks
part / --ondisk ${RK_BOOT_DEVICE} --source rootfs --fstype=ext4 --label root

-bootloader --ptable gpt --append="console=tty1 console=ttyS2,115200n8 rw root=/dev/${RK_BOOT_DEVICE}p7 rootfstype=ext4 init=/sbin/init"
+bootloader --ptable gpt --append="console=tty1 console=${RK_CONSOLE_DEVICE},${RK_CONSOLE_BAUD}n8 rw root=/dev/${RK_BOOT_DEVICE}p7 rootfstype=ext4 init=/sbin/init"

--
2.30.0.rc0


[meta-rockchip][PATCH 1/4] centralize console settings

Trevor Woerner
 

The console settings (baud and device) are scrambled and spread throughout the
MACHINE configurations. Consolidate them and set defaults which are then
overridden only as required.

Signed-off-by: Trevor Woerner <twoerner@gmail.com>
---
conf/machine/include/nanopi-m4.inc | 2 --
conf/machine/include/rk3066.inc | 1 +
conf/machine/include/rk3188.inc | 3 +++
conf/machine/include/rk3288.inc | 2 +-
conf/machine/include/rk3328.inc | 2 --
conf/machine/include/rk3399.inc | 2 --
conf/machine/include/rock-pi-4.inc | 2 --
conf/machine/include/rockchip-defaults.inc | 3 +++
conf/machine/marsboard-rk3066.conf | 1 -
conf/machine/radxarock.conf | 1 -
10 files changed, 8 insertions(+), 11 deletions(-)

diff --git a/conf/machine/include/nanopi-m4.inc b/conf/machine/include/nanopi-m4.inc
index a14b705..8a7c1d9 100644
--- a/conf/machine/include/nanopi-m4.inc
+++ b/conf/machine/include/nanopi-m4.inc
@@ -21,5 +21,3 @@ WKS_FILE_DEPENDS ?= " \
IMAGE_BOOT_FILES ?= "\
${KERNEL_IMAGETYPE} \
"
-
-SERIAL_CONSOLES = "1500000;ttyS2"
diff --git a/conf/machine/include/rk3066.inc b/conf/machine/include/rk3066.inc
index dffbee0..76744ee 100644
--- a/conf/machine/include/rk3066.inc
+++ b/conf/machine/include/rk3066.inc
@@ -7,5 +7,6 @@ require conf/machine/include/tune-cortexa9.inc
require conf/machine/include/soc-family.inc
require conf/machine/include/rockchip-defaults.inc

+RK_CONSOLE_BAUD = "115200"
KBUILD_DEFCONFIG = "multi_v7_defconfig"
KERNEL_IMAGETYPE = "zImage"
diff --git a/conf/machine/include/rk3188.inc b/conf/machine/include/rk3188.inc
index 59e65d1..e21bbf7 100644
--- a/conf/machine/include/rk3188.inc
+++ b/conf/machine/include/rk3188.inc
@@ -9,3 +9,6 @@ require conf/machine/include/rockchip-defaults.inc

KBUILD_DEFCONFIG = "multi_v7_defconfig"
KERNEL_IMAGETYPE = "zImage"
+
+RK_CONSOLE_BAUD = "115200"
+RK_CONSOLE_DEVICE = "ttyFIQ0"
diff --git a/conf/machine/include/rk3288.inc b/conf/machine/include/rk3288.inc
index 480e250..2715e73 100644
--- a/conf/machine/include/rk3288.inc
+++ b/conf/machine/include/rk3288.inc
@@ -10,7 +10,7 @@ require conf/machine/include/rockchip-defaults.inc
KBUILD_DEFCONFIG ?= "multi_v7_defconfig"
KERNEL_IMAGETYPE = "zImage"

-SERIAL_CONSOLES = "115200;ttyS2"
+RK_CONSOLE_BAUD = "115200"

PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot"
SPL_BINARY ?= "idbloader.img"
diff --git a/conf/machine/include/rk3328.inc b/conf/machine/include/rk3328.inc
index a4bbc5d..5b11868 100644
--- a/conf/machine/include/rk3328.inc
+++ b/conf/machine/include/rk3328.inc
@@ -19,7 +19,5 @@ TFA_BUILD_TARGET = "bl31"
UBOOT_SUFFIX ?= "itb"
UBOOT_ENTRYPOINT ?= "0x06000000"

-SERIAL_CONSOLES = "1500000;ttyS2"
-
PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot"
SPL_BINARY ?= "idbloader.img"
diff --git a/conf/machine/include/rk3399.inc b/conf/machine/include/rk3399.inc
index f6b7826..9f9f474 100644
--- a/conf/machine/include/rk3399.inc
+++ b/conf/machine/include/rk3399.inc
@@ -19,8 +19,6 @@ TFA_BUILD_TARGET = "bl31"
UBOOT_SUFFIX ?= "itb"
UBOOT_ENTRYPOINT ?= "0x06000000"

-SERIAL_CONSOLES = "115200;ttyS2"
-
PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot"
SPL_BINARY ?= "idbloader.img"

diff --git a/conf/machine/include/rock-pi-4.inc b/conf/machine/include/rock-pi-4.inc
index 9c21084..a3e60c7 100644
--- a/conf/machine/include/rock-pi-4.inc
+++ b/conf/machine/include/rock-pi-4.inc
@@ -17,6 +17,4 @@ IMAGE_BOOT_FILES ?= "\
${KERNEL_IMAGETYPE} \
"

-SERIAL_CONSOLES = "1500000;ttyS2"
-
MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
diff --git a/conf/machine/include/rockchip-defaults.inc b/conf/machine/include/rockchip-defaults.inc
index a4e2a2c..fe4052e 100644
--- a/conf/machine/include/rockchip-defaults.inc
+++ b/conf/machine/include/rockchip-defaults.inc
@@ -21,6 +21,9 @@ XSERVER = " \
"

# misc
+RK_CONSOLE_DEVICE ?= "ttyS2"
+RK_CONSOLE_BAUD ?= "1500000"
+SERIAL_CONSOLES = "${RK_CONSOLE_BAUD};${RK_CONSOLE_DEVICE}"
IMAGE_FSTYPES += "ext4"

# boot device (sd-card/emmc)
diff --git a/conf/machine/marsboard-rk3066.conf b/conf/machine/marsboard-rk3066.conf
index 09414bc..52fd256 100644
--- a/conf/machine/marsboard-rk3066.conf
+++ b/conf/machine/marsboard-rk3066.conf
@@ -8,5 +8,4 @@

require conf/machine/include/rk3066.inc

-SERIAL_CONSOLES = "115200;ttyS2"
KERNEL_DEVICETREE = "rk3066a-marsboard.dtb"
diff --git a/conf/machine/radxarock.conf b/conf/machine/radxarock.conf
index 2036f6a..42d8848 100644
--- a/conf/machine/radxarock.conf
+++ b/conf/machine/radxarock.conf
@@ -9,5 +9,4 @@

require conf/machine/include/rk3188.inc

-SERIAL_CONSOLES = "115200;ttyFIQ0"
KERNEL_DEVICETREE = "rk3188-radxarock.dtb"
--
2.30.0.rc0


[meta-security][PATCH 2/2] apparmor: use its own initscript and service files

Yi Zhao
 

Use initscript and service files provided by apparmor.

Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
---
recipes-mac/AppArmor/apparmor_3.0.1.bb | 33 +--
...x-hardcoded-installation-directories.patch | 51 ++++
...pparmor.debian-add-missing-functions.patch | 57 ++++
recipes-mac/AppArmor/files/apparmor | 226 ---------------
recipes-mac/AppArmor/files/apparmor.rc | 98 -------
recipes-mac/AppArmor/files/apparmor.service | 22 --
recipes-mac/AppArmor/files/functions | 271 ------------------
7 files changed, 118 insertions(+), 640 deletions(-)
create mode 100644 recipes-mac/AppArmor/files/0001-Makefile-fix-hardcoded-installation-directories.patch
create mode 100644 recipes-mac/AppArmor/files/0001-rc.apparmor.debian-add-missing-functions.patch
delete mode 100644 recipes-mac/AppArmor/files/apparmor
delete mode 100644 recipes-mac/AppArmor/files/apparmor.rc
delete mode 100644 recipes-mac/AppArmor/files/apparmor.service
delete mode 100644 recipes-mac/AppArmor/files/functions

diff --git a/recipes-mac/AppArmor/apparmor_3.0.1.bb b/recipes-mac/AppArmor/apparmor_3.0.1.bb
index 6377683..ff5b39b 100644
--- a/recipes-mac/AppArmor/apparmor_3.0.1.bb
+++ b/recipes-mac/AppArmor/apparmor_3.0.1.bb
@@ -15,15 +15,13 @@ DEPENDS = "bison-native apr gettext-native coreutils-native swig-native"

SRC_URI = " \
git://gitlab.com/apparmor/apparmor.git;protocol=https;branch=apparmor-3.0 \
+ file://run-ptest \
file://disable_perl_h_check.patch \
file://crosscompile_perl_bindings.patch \
- file://apparmor.rc \
- file://functions \
- file://apparmor \
- file://apparmor.service \
file://0001-Makefile.am-suppress-perllocal.pod.patch \
- file://run-ptest \
file://0001-Revert-profiles-Update-make-check-to-select-tools-ba.patch \
+ file://0001-Makefile-fix-hardcoded-installation-directories.patch \
+ file://0001-rc.apparmor.debian-add-missing-functions.patch \
"

SRCREV = "b0f08aa9d678197b8e3477c2fbff790f50a1de5e"
@@ -79,8 +77,6 @@ do_compile () {
}

do_install () {
- install -d ${D}/${INIT_D_DIR}
- install -d ${D}/lib/apparmor
oe_runmake -C ${B}/libraries/libapparmor DESTDIR="${D}" install
oe_runmake -C ${B}/binutils DESTDIR="${D}" install
oe_runmake -C ${B}/utils DESTDIR="${D}" install
@@ -96,16 +92,16 @@ do_install () {
fi

if ${@bb.utils.contains('DISTRO_FEATURES', 'pam', 'true', 'false', d)}; then
- install -d ${D}/lib/security
oe_runmake -C ${B}/changehat/pam_apparmor DESTDIR="${D}" install
fi

- install -m 755 ${WORKDIR}/apparmor ${D}/${INIT_D_DIR}/apparmor
- install -m 755 ${WORKDIR}/functions ${D}/lib/apparmor
+ if ${@bb.utils.contains('DISTRO_FEATURES','sysvinit','true','false',d)}; then
+ install -d ${D}${sysconfdir}/init.d
+ install -m 755 ${B}/parser/rc.apparmor.debian ${D}${sysconfdir}/init.d/apparmor
+ fi

if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; then
- install -d ${D}${systemd_system_unitdir}
- install -m 0644 ${WORKDIR}/apparmor.service ${D}${systemd_system_unitdir}
+ oe_runmake -C ${B}/parser DESTDIR="${D}" install-systemd
fi
}

@@ -152,15 +148,6 @@ do_install_ptest_arm() {
:
}

-pkg_postinst_ontarget_${PN} () {
-if [ ! -d /etc/apparmor.d/cache ] ; then
- mkdir /etc/apparmor.d/cache
-fi
-}
-
-# We need the init script so don't rm it
-RMINITDIR_class-target_remove = " rm_sysvinit_initddir"
-
INITSCRIPT_PACKAGES = "${PN}"
INITSCRIPT_NAME = "apparmor"
INITSCRIPT_PARAMS = "start 16 2 3 4 5 . stop 35 0 1 6 ."
@@ -171,9 +158,9 @@ SYSTEMD_AUTO_ENABLE ?= "enable"

PACKAGES += "mod-${PN}"

-FILES_${PN} += "/lib/apparmor/ /lib/security/ ${sysconfdir}/apparmor ${nonarch_libdir}/${PYTHON_DIR}/site-packages"
+FILES_${PN} += "${nonarch_base_libdir}/apparmor/ ${base_libdir}/security/ ${sysconfdir}/apparmor ${nonarch_libdir}/${PYTHON_DIR}/site-packages"
FILES_mod-${PN} = "${libdir}/apache2/modules/*"
-FILES_${PN}-dbg += "/lib/security/"
+FILES_${PN}-dbg += "${base_libdir}/security/.debug"

DEPENDS_append_libc-musl = " fts "
RDEPENDS_${PN}_libc-musl += "musl-utils"
diff --git a/recipes-mac/AppArmor/files/0001-Makefile-fix-hardcoded-installation-directories.patch b/recipes-mac/AppArmor/files/0001-Makefile-fix-hardcoded-installation-directories.patch
new file mode 100644
index 0000000..f10acb1
--- /dev/null
+++ b/recipes-mac/AppArmor/files/0001-Makefile-fix-hardcoded-installation-directories.patch
@@ -0,0 +1,51 @@
+From 363114dcd72abf1c0dcd637c66037227b8be229b Mon Sep 17 00:00:00 2001
+From: Yi Zhao <yi.zhao@windriver.com>
+Date: Mon, 21 Jun 2021 14:18:30 +0800
+Subject: [PATCH 1/2] Makefile: fix hardcoded installation directories
+
+Update the installation directories to fix the do_install error for
+multilib and usrmerge.
+
+Upstream-Status: Inappropriate [configuration]
+
+Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
+---
+ changehat/pam_apparmor/Makefile | 2 +-
+ parser/Makefile | 8 ++++----
+ 2 files changed, 5 insertions(+), 5 deletions(-)
+
+diff --git a/changehat/pam_apparmor/Makefile b/changehat/pam_apparmor/Makefile
+index f6ece2d1..0143ae9f 100644
+--- a/changehat/pam_apparmor/Makefile
++++ b/changehat/pam_apparmor/Makefile
+@@ -77,7 +77,7 @@ $(NAME).so: ${OBJECTS}
+
+ # need some better way of determining this
+ DESTDIR=/
+-SECDIR ?= ${DESTDIR}/lib/security
++SECDIR ?= ${DESTDIR}/${base_libdir}/security
+
+ .PHONY: install
+ install: $(NAME).so
+diff --git a/parser/Makefile b/parser/Makefile
+index 8250ac45..cf18bc11 100644
+--- a/parser/Makefile
++++ b/parser/Makefile
+@@ -23,10 +23,10 @@ COMMONDIR=../common/
+ include $(COMMONDIR)/Make.rules
+
+ DESTDIR=/
+-APPARMOR_BIN_PREFIX=${DESTDIR}/lib/apparmor
+-SBINDIR=${DESTDIR}/sbin
+-USR_SBINDIR=${DESTDIR}/usr/sbin
+-SYSTEMD_UNIT_DIR=${DESTDIR}/usr/lib/systemd/system
++APPARMOR_BIN_PREFIX=${DESTDIR}/${nonarch_base_libdir}/apparmor
++SBINDIR=${DESTDIR}/${base_sbindir}
++USR_SBINDIR=${DESTDIR}/${sbindir}
++SYSTEMD_UNIT_DIR=${DESTDIR}/${systemd_system_unitdir}
+ CONFDIR=/etc/apparmor
+ INSTALL_CONFDIR=${DESTDIR}${CONFDIR}
+ LOCALEDIR=/usr/share/locale
+--
+2.17.1
+
diff --git a/recipes-mac/AppArmor/files/0001-rc.apparmor.debian-add-missing-functions.patch b/recipes-mac/AppArmor/files/0001-rc.apparmor.debian-add-missing-functions.patch
new file mode 100644
index 0000000..53bdde8
--- /dev/null
+++ b/recipes-mac/AppArmor/files/0001-rc.apparmor.debian-add-missing-functions.patch
@@ -0,0 +1,57 @@
+From a737c95ac0f887c365fe8f16583ea95da79de1e9 Mon Sep 17 00:00:00 2001
+From: Yi Zhao <yi.zhao@windriver.com>
+Date: Mon, 21 Jun 2021 16:53:39 +0800
+Subject: [PATCH] rc.apparmor.debian: add missing functions
+
+Add missing functions:
+ aa_log_action_start
+ aa_log_action_end
+ aa_log_daemon_msg
+ aa_log_end_msg
+
+Fixes:
+$ /etc/init.d/apparmor start
+/lib/apparmor/rc.apparmor.functions: line 294: aa_log_daemon_msg: command not found
+/lib/apparmor/rc.apparmor.functions: line 214: aa_log_action_start: command not found
+
+Upstream-Status: Pending
+
+Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
+---
+ parser/rc.apparmor.debian | 20 ++++++++++++++++++++
+ 1 file changed, 20 insertions(+)
+
+diff --git a/parser/rc.apparmor.debian b/parser/rc.apparmor.debian
+index 8efd4400..f35124e8 100644
+--- a/parser/rc.apparmor.debian
++++ b/parser/rc.apparmor.debian
+@@ -70,6 +70,26 @@ aa_log_skipped_msg() {
+ echo ": Skipped."
+ }
+
++aa_log_action_start()
++{
++ echo "$@"
++}
++
++aa_log_action_end()
++{
++ printf ""
++}
++
++aa_log_daemon_msg()
++{
++ echo "$@"
++}
++
++aa_log_end_msg()
++{
++ printf ""
++}
++
+ usage() {
+ echo "Usage: $0 {start|stop|restart|try-restart|reload|force-reload|status|kill}"
+ }
+--
+2.17.1
+
diff --git a/recipes-mac/AppArmor/files/apparmor b/recipes-mac/AppArmor/files/apparmor
deleted file mode 100644
index 604e48d..0000000
--- a/recipes-mac/AppArmor/files/apparmor
+++ /dev/null
@@ -1,226 +0,0 @@
-#!/bin/sh
-# ----------------------------------------------------------------------
-# Copyright (c) 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007
-# NOVELL (All rights reserved)
-# Copyright (c) 2008, 2009 Canonical, Ltd.
-#
-# This program is free software; you can redistribute it and/or
-# modify it under the terms of version 2 of the GNU General Public
-# License published by the Free Software Foundation.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program; if not, contact Novell, Inc.
-# ----------------------------------------------------------------------
-# Authors:
-# Steve Beattie <steve.beattie@canonical.com>
-# Kees Cook <kees@ubuntu.com>
-#
-# /etc/init.d/apparmor
-#
-### BEGIN INIT INFO
-# Provides: apparmor
-# Required-Start: $local_fs
-# Required-Stop: umountfs
-# Default-Start: S
-# Default-Stop:
-# Short-Description: AppArmor initialization
-# Description: AppArmor init script. This script loads all AppArmor profiles.
-### END INIT INFO
-
-log_daemon_msg() {
- echo $*
-}
-
-log_end_msg () {
- retval=$1
- if [ $retval -eq 0 ]; then
- echo "."
- else
- echo " failed!"
- fi
- return $retval
-}
-
-. /lib/apparmor/functions
-
-usage() {
- echo "Usage: $0 {start|stop|restart|reload|force-reload|status|recache}"
-}
-
-test -x ${PARSER} || exit 0 # by debian policy
-# LSM is built-in, so it is either there or not enabled for this boot
-test -d /sys/module/apparmor || exit 0
-
-securityfs() {
- # Need securityfs for any mode
- if [ ! -d "${AA_SFS}" ]; then
- if cut -d" " -f2,3 /proc/mounts | grep -q "^${SECURITYFS} securityfs"'$' ; then
- log_daemon_msg "AppArmor not available as kernel LSM."
- log_end_msg 1
- exit 1
- else
- log_daemon_msg "Mounting securityfs on ${SECURITYFS}"
- if ! mount -t securityfs none "${SECURITYFS}"; then
- log_end_msg 1
- exit 1
- fi
- fi
- fi
- if [ ! -w "$AA_SFS"/.load ]; then
- log_daemon_msg "Insufficient privileges to change profiles."
- log_end_msg 1
- exit 1
- fi
-}
-
-handle_system_policy_package_updates() {
- apparmor_was_updated=0
-
- if ! compare_previous_version ; then
- # On snappy flavors, if the current and previous versions are
- # different then clear the system cache. snappy will handle
- # "$PROFILES_CACHE_VAR" itself (on Touch flavors
- # compare_previous_version always returns '0' since snappy
- # isn't available).
- clear_cache_system
- apparmor_was_updated=1
- elif ! compare_and_save_debsums apparmor ; then
- # If the system policy has been updated since the last time we
- # ran, clear the cache to prevent potentially stale binary
- # cache files after an Ubuntu image based upgrade (LP:
- # #1350673). This can be removed once all system image flavors
- # move to snappy (on snappy systems compare_and_save_debsums
- # always returns '0' since /var/lib/dpkg doesn't exist).
- clear_cache
- apparmor_was_updated=1
- fi
-
- if [ -x /usr/bin/aa-clickhook ] || [ -x /usr/bin/aa-profile-hook ] ; then
- # If packages for system policy that affect click packages have
- # been updated since the last time we ran, run aa-clickhook -f
- force_clickhook=0
- force_profile_hook=0
- if ! compare_and_save_debsums apparmor-easyprof-ubuntu ; then
- force_clickhook=1
- fi
- if ! compare_and_save_debsums apparmor-easyprof-ubuntu-snappy ; then
- force_clickhook=1
- fi
- if ! compare_and_save_debsums click-apparmor ; then
- force_clickhook=1
- force_profile_hook=1
- fi
- if [ -x /usr/bin/aa-clickhook ] && ([ $force_clickhook -eq 1 ] || [ $apparmor_was_updated -eq 1 ]) ; then
- aa-clickhook -f
- fi
- if [ -x /usr/bin/aa-profile-hook ] && ([ $force_profile_hook -eq 1 ] || [ $apparmor_was_updated -eq 1 ]) ; then
- aa-profile-hook -f
- fi
- fi
-}
-
-# Allow "recache" even when running on the liveCD
-if [ "$1" = "recache" ]; then
- log_daemon_msg "Recaching AppArmor profiles"
- recache_profiles
- rc=$?
- log_end_msg "$rc"
- exit $rc
-fi
-
-# do not perform start/stop/reload actions when running from liveCD
-test -d /rofs/etc/apparmor.d && exit 0
-
-rc=255
-case "$1" in
- start)
- if test -x /sbin/systemd-detect-virt && \
- systemd-detect-virt --quiet --container && \
- ! is_container_with_internal_policy; then
- log_daemon_msg "Not starting AppArmor in container"
- log_end_msg 0
- exit 0
- fi
- log_daemon_msg "Starting AppArmor profiles"
- securityfs
- # That is only useful for click, snappy and system images,
- # i.e. not in Debian. And it reads and writes to /var, that
- # can be remote-mounted, so it would prevent us from using
- # Before=sysinit.target without possibly introducing dependency
- # loops.
- handle_system_policy_package_updates
- load_configured_profiles
- rc=$?
- log_end_msg "$rc"
- ;;
- stop)
- log_daemon_msg "Clearing AppArmor profiles cache"
- clear_cache
- rc=$?
- log_end_msg "$rc"
- cat >&2 <<EOM
-All profile caches have been cleared, but no profiles have been unloaded.
-Unloading profiles will leave already running processes permanently
-unconfined, which can lead to unexpected situations.
-
-To set a process to complain mode, use the command line tool
-'aa-complain'. To really tear down all profiles, run the init script
-with the 'teardown' option."
-EOM
- ;;
- teardown)
- if test -x /sbin/systemd-detect-virt && \
- systemd-detect-virt --quiet --container && \
- ! is_container_with_internal_policy; then
- log_daemon_msg "Not tearing down AppArmor in container"
- log_end_msg 0
- exit 0
- fi
- log_daemon_msg "Unloading AppArmor profiles"
- securityfs
- running_profile_names | while read profile; do
- if ! unload_profile "$profile" ; then
- log_end_msg 1
- exit 1
- fi
- done
- rc=0
- log_end_msg $rc
- ;;
- restart|reload|force-reload)
- if test -x /sbin/systemd-detect-virt && \
- systemd-detect-virt --quiet --container && \
- ! is_container_with_internal_policy; then
- log_daemon_msg "Not reloading AppArmor in container"
- log_end_msg 0
- exit 0
- fi
- log_daemon_msg "Reloading AppArmor profiles"
- securityfs
- clear_cache
- load_configured_profiles
- rc=$?
- unload_obsolete_profiles
-
- log_end_msg "$rc"
- ;;
- status)
- securityfs
- if [ -x /usr/sbin/aa-status ]; then
- aa-status --verbose
- else
- cat "$AA_SFS"/profiles
- fi
- rc=$?
- ;;
- *)
- usage
- rc=1
- ;;
- esac
-exit $rc
diff --git a/recipes-mac/AppArmor/files/apparmor.rc b/recipes-mac/AppArmor/files/apparmor.rc
deleted file mode 100644
index 1507d7b..0000000
--- a/recipes-mac/AppArmor/files/apparmor.rc
+++ /dev/null
@@ -1,98 +0,0 @@
-description "Pre-cache and pre-load apparmor profiles"
-author "Dimitri John Ledkov <xnox@ubuntu.com> and Jamie Strandboge <jamie@ubuntu.com>"
-
-task
-
-start on starting rc-sysinit
-
-script
- [ -d /rofs/etc/apparmor.d ] && exit 0 # do not load on liveCD
- [ -d /sys/module/apparmor ] || exit 0 # do not load without AppArmor
- [ -x /sbin/apparmor_parser ] || exit 0 # do not load without parser
-
- . /lib/apparmor/functions
-
- systemd-detect-virt --quiet --container && ! is_container_with_internal_policy && exit 0 || true
-
- # Need securityfs for any mode
- if [ ! -d /sys/kernel/security/apparmor ]; then
- if cut -d" " -f2,3 /proc/mounts | grep -q "^/sys/kernel/security securityfs"'$' ; then
- exit 0
- else
- mount -t securityfs none /sys/kernel/security || exit 0
- fi
- fi
-
- [ -w /sys/kernel/security/apparmor/.load ] || exit 0
-
- apparmor_was_updated=0
- if ! compare_previous_version ; then
- # On snappy flavors, if the current and previous versions are
- # different then clear the system cache. snappy will handle
- # "$PROFILES_CACHE_VAR" itself (on Touch flavors
- # compare_previous_version always returns '0' since snappy
- # isn't available).
- clear_cache_system
- apparmor_was_updated=1
- elif ! compare_and_save_debsums apparmor ; then
- # If the system policy has been updated since the last time we
- # ran, clear the cache to prevent potentially stale binary
- # cache files after an Ubuntu image based upgrade (LP:
- # #1350673). This can be removed once all system image flavors
- # move to snappy (on snappy systems compare_and_save_debsums
- # always returns '0' since /var/lib/dpkg doesn't exist).
- clear_cache
- apparmor_was_updated=1
- fi
-
- if [ -x /usr/bin/aa-clickhook ] || [ -x /usr/bin/aa-profile-hook ] ; then
- # If packages for system policy that affect click packages have
- # been updated since the last time we ran, run aa-clickhook -f
- force_clickhook=0
- force_profile_hook=0
- if ! compare_and_save_debsums apparmor-easyprof-ubuntu ; then
- force_clickhook=1
- fi
- if ! compare_and_save_debsums apparmor-easyprof-ubuntu-snappy ; then
- force_clickhook=1
- fi
- if ! compare_and_save_debsums click-apparmor ; then
- force_clickhook=1
- force_profile_hook=1
- fi
- if [ -x /usr/bin/aa-clickhook ] && ([ $force_clickhook -eq 1 ] || [ $apparmor_was_updated -eq 1 ]) ; then
- aa-clickhook -f
- fi
- if [ -x /usr/bin/aa-profile-hook ] && ([ $force_profile_hook -eq 1 ] || [ $apparmor_was_updated -eq 1 ]) ; then
- aa-profile-hook -f
- fi
- fi
-
- if [ "$ACTION" = "teardown" ]; then
- running_profile_names | while read profile; do
- unload_profile "$profile"
- done
- exit 0
- fi
-
- if [ "$ACTION" = "clear" ]; then
- clear_cache
- exit 0
- fi
-
- if [ "$ACTION" = "reload" ] || [ "$ACTION" = "force-reload" ]; then
- clear_cache
- load_configured_profiles
- unload_obsolete_profiles
- exit 0
- fi
-
- # Note: if apparmor-easyprof-ubuntu md5sums didn't match up above,
- # aa-clickhook will have already compiled the policy, generated the cache
- # files and loaded them into the kernel by this point, so reloading click
- # policy from cache, while fairly fast (<2 seconds for 250 profiles on
- # armhf), is redundant. Fixing this would complicate the logic quite a bit
- # and it wouldn't improve the (by far) common case (ie, when
- # 'aa-clickhook -f' is not run).
- load_configured_profiles
-end script
diff --git a/recipes-mac/AppArmor/files/apparmor.service b/recipes-mac/AppArmor/files/apparmor.service
deleted file mode 100644
index e66afe4..0000000
--- a/recipes-mac/AppArmor/files/apparmor.service
+++ /dev/null
@@ -1,22 +0,0 @@
-[Unit]
-Description=AppArmor initialization
-After=local-fs.target
-Before=sysinit.target
-AssertPathIsReadWrite=/sys/kernel/security/apparmor/.load
-ConditionSecurity=apparmor
-DefaultDependencies=no
-Documentation=man:apparmor(7)
-Documentation=http://wiki.apparmor.net/
-
-# Don't start this unit on the Ubuntu Live CD
-ConditionPathExists=!/rofs/etc/apparmor.d
-
-[Service]
-Type=oneshot
-RemainAfterExit=yes
-ExecStart=/etc/init.d/apparmor start
-ExecStop=/etc/init.d/apparmor stop
-ExecReload=/etc/init.d/apparmor reload
-
-[Install]
-WantedBy=sysinit.target
diff --git a/recipes-mac/AppArmor/files/functions b/recipes-mac/AppArmor/files/functions
deleted file mode 100644
index e9e2bbf..0000000
--- a/recipes-mac/AppArmor/files/functions
+++ /dev/null
@@ -1,271 +0,0 @@
-# /lib/apparmor/functions for Debian -*- shell-script -*-
-# ----------------------------------------------------------------------
-# Copyright (c) 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007
-# NOVELL (All rights reserved)
-# Copyright (c) 2008-2010 Canonical, Ltd.
-#
-# This program is free software; you can redistribute it and/or
-# modify it under the terms of version 2 of the GNU General Public
-# License published by the Free Software Foundation.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program; if not, contact Novell, Inc.
-# ----------------------------------------------------------------------
-# Authors:
-# Kees Cook <kees@ubuntu.com>
-
-PROFILES="/etc/apparmor.d"
-PROFILES_CACHE="$PROFILES/cache"
-PROFILES_VAR="/var/lib/apparmor/profiles"
-PROFILES_SNAPPY="/var/lib/snapd/apparmor/profiles"
-PROFILES_CACHE_VAR="/var/cache/apparmor"
-PARSER="/sbin/apparmor_parser"
-SECURITYFS="/sys/kernel/security"
-export AA_SFS="$SECURITYFS/apparmor"
-
-# Suppress warnings when booting in quiet mode
-quiet_arg=""
-[ "${QUIET:-no}" = yes ] && quiet_arg="-q"
-[ "${quiet:-n}" = y ] && quiet_arg="-q"
-
-foreach_configured_profile() {
- rc_all="0"
- for pdir in "$PROFILES" "$PROFILES_VAR" "$PROFILES_SNAPPY" ; do
- if [ ! -d "$pdir" ]; then
- continue
- fi
- num=`find "$pdir" -type f ! -name '*.md5sums' | wc -l`
- if [ "$num" = "0" ]; then
- continue
- fi
-
- cache_dir="$PROFILES_CACHE"
- if [ -d "$PROFILES_CACHE_VAR" ] && [ "$pdir" = "$PROFILES_VAR" ] || [ "$pdir" = "$PROFILES_SNAPPY" ]; then
- cache_dir="$PROFILES_CACHE_VAR"
- fi
- cache_args="--cache-loc=$cache_dir"
- if [ ! -d "$cache_dir" ]; then
- cache_args=
- fi
-
- # LP: #1383858 - expr tree simplification is too slow for
- # Touch policy on ARM, so disable it for now
- cache_extra_args=
- if [ -d "$PROFILES_CACHE_VAR" ] && [ "$pdir" = "$PROFILES_VAR" ] || [ "$pdir" = "$PROFILES_SNAPPY" ]; then
- cache_extra_args="-O no-expr-simplify"
- fi
-
- # If need to compile everything, then use -n1 with xargs to
- # take advantage of -P. When cache files are in use, omit -n1
- # since it is considerably faster on moderately sized profile
- # sets to give the parser all the profiles to load at once
- n1_args=
- num=`find "$cache_dir" -type f ! -name '.features' | wc -l`
- if [ "$num" = "0" ]; then
- n1_args="-n1"
- fi
-
- (ls -1 "$pdir" | egrep -v '(\.dpkg-(new|old|dist|bak)|~)$' | \
- while read profile; do
- if [ -f "$pdir"/"$profile" ]; then
- echo "$pdir"/"$profile"
- fi
- done) | \
- xargs $n1_args -d"\n" -P$(getconf _NPROCESSORS_ONLN) "$PARSER" "$@" $cache_args $cache_extra_args -- || {
- rc_all="$?"
- # FIXME: when the parser properly handles broken
- # profiles (LP: #1377338), remove this if statement.
- # For now, if the xargs returns with error, just run
- # through everything with -n1. (This could be broken
- # out and refactored, but this is temporary so make it
- # easy to understand and revert)
- if [ "$rc_all" != "0" ]; then
- (ls -1 "$pdir" | \
- egrep -v '(\.dpkg-(new|old|dist|bak)|~)$' | \
- while read profile; do
- if [ -f "$pdir"/"$profile" ]; then
- echo "$pdir"/"$profile"
- fi
- done) | \
- xargs -n1 -d"\n" -P$(getconf _NPROCESSORS_ONLN) "$PARSER" "$@" $cache_args $cache_extra_args -- || {
- rc_all="$?"
- }
- fi
- }
- done
- return $rc_all
-}
-
-load_configured_profiles() {
- clear_cache_if_outdated
- foreach_configured_profile $quiet_arg --write-cache --replace
-}
-
-load_configured_profiles_without_caching() {
- foreach_configured_profile $quiet_arg --replace
-}
-
-recache_profiles() {
- clear_cache
- foreach_configured_profile $quiet_arg --write-cache --skip-kernel-load
-}
-
-configured_profile_names() {
- foreach_configured_profile $quiet_arg -N 2>/dev/null | LC_COLLATE=C sort | grep -v '//'
-}
-
-running_profile_names() {
- # Output a sorted list of loaded profiles, skipping libvirt's
- # dynamically generated files
- cat "$AA_SFS"/profiles | sed -e "s/ (\(enforce\|complain\))$//" | egrep -v '^libvirt-[0-9a-f\-]+$' | LC_COLLATE=C sort | grep -v '//'
-}
-
-unload_profile() {
- echo -n "$1" > "$AA_SFS"/.remove
-}
-
-clear_cache() {
- clear_cache_system
- clear_cache_var
-}
-
-clear_cache_system() {
- find "$PROFILES_CACHE" -maxdepth 1 -type f -print0 | xargs -0 rm -f --
-}
-
-clear_cache_var() {
- find "$PROFILES_CACHE_VAR" -maxdepth 1 -type f -print0 | xargs -0 rm -f --
-}
-
-read_features_dir()
-{
- for f in `ls -A "$1"` ; do
- if [ -f "$1/$f" ] ; then
- read -r KF < "$1/$f" || true
- echo -n "$f {$KF } "
- elif [ -d "$1/$f" ] ; then
- echo -n "$f {"
- KF=`read_features_dir "$1/$f"` || true
- echo -n "$KF} "
- fi
- done
-}
-
-clear_cache_if_outdated() {
- if [ -r "$PROFILES_CACHE"/.features ]; then
- if [ -d "$AA_SFS"/features ]; then
- KERN_FEATURES=`read_features_dir "$AA_SFS"/features`
- else
- read -r KERN_FEATURES < "$AA_SFS"/features
- fi
- CACHE_FEATURES=`tr '\n' ' ' < "$PROFILES_CACHE"/.features`
- if [ "$KERN_FEATURES" != "$CACHE_FEATURES" ]; then
- clear_cache
- fi
- fi
-}
-
-unload_obsolete_profiles() {
- # Currently we must re-parse all the profiles to get policy names. :(
- aa_configured=$(mktemp -t aa-XXXXXX)
- configured_profile_names > "$aa_configured" || true
- aa_loaded=$(mktemp -t aa-XXXXXX)
- running_profile_names > "$aa_loaded" || true
- LC_COLLATE=C comm -2 -3 "$aa_loaded" "$aa_configured" | while read profile ; do
- unload_profile "$profile"
- done
- rm -f "$aa_configured" "$aa_loaded"
-}
-
-# If the system debsum differs from the saved debsum, the new system debsum is
-# saved and non-zero is returned. Returns 0 if the two debsums matched or if
-# the system debsum file does not exist. This can be removed when system image
-# flavors all move to snappy.
-compare_and_save_debsums() {
- pkg="$1"
-
- if [ -n $pkg ] && [ -d "$PROFILES_VAR" ]; then
- sums="/var/lib/dpkg/info/${pkg}.md5sums"
- # store saved md5sums in /var/lib/apparmor/profiles since
- # /var/cache/apparmor might be cleared by apparmor
- saved_sums="${PROFILES_VAR}/.${pkg}.md5sums"
-
- if [ -f "$sums" ] && \
- ! diff -q "$sums" "$saved_sums" 2>&1 >/dev/null ; then
- cp -f "$sums" "$saved_sums"
- return 1
- fi
- fi
-
- return 0
-}
-
-compare_previous_version() {
- installed="/usr/share/snappy/security-policy-version"
- previous="/var/lib/snappy/security-policy-version"
-
- # When just $previous doesn't exist, assume this is a new system with
- # no cache and don't do anything special.
- if [ -f "$installed" ] && [ -f "$previous" ]; then
- pv=`grep '^apparmor/' "$previous" | cut -d ' ' -f 2`
- iv=`grep '^apparmor/' "$installed" | cut -d ' ' -f 2`
- if [ -n "$iv" ] && [ -n "$pv" ] && [ "$iv" != "$pv" ]; then
- # snappy updates $previous elsewhere, so just return
- return 1
- fi
- fi
-
- return 0
-}
-
-# Checks to see if the current container is capable of having internal AppArmor
-# profiles that should be loaded. Callers of this function should have already
-# verified that they're running inside of a container environment with
-# something like `systemd-detect-virt --container`.
-#
-# The only known container environments capable of supporting internal policy
-# are LXD and LXC environment.
-#
-# Returns 0 if the container environment is capable of having its own internal
-# policy and non-zero otherwise.
-#
-# IMPORTANT: This function will return 0 in the case of a non-LXD/non-LXC
-# system container technology being nested inside of a LXD/LXC container that
-# utilized an AppArmor namespace and profile stacking. The reason 0 will be
-# returned is because .ns_stacked will be "yes" and .ns_name will still match
-# "lx[dc]-*" since the nested system container technology will not have set up
-# a new AppArmor profile namespace. This will result in the nested system
-# container's boot process to experience failed policy loads but the boot
-# process should continue without any loss of functionality. This is an
-# unsupported configuration that cannot be properly handled by this function.
-is_container_with_internal_policy() {
- local ns_stacked_path="${AA_SFS}/.ns_stacked"
- local ns_name_path="${AA_SFS}/.ns_name"
- local ns_stacked
- local ns_name
-
- if ! [ -f "$ns_stacked_path" ] || ! [ -f "$ns_name_path" ]; then
- return 1
- fi
-
- read -r ns_stacked < "$ns_stacked_path"
- if [ "$ns_stacked" != "yes" ]; then
- return 1
- fi
-
- # LXD and LXC set up AppArmor namespaces starting with "lxd-" and
- # "lxc-", respectively. Return non-zero for all other namespace
- # identifiers.
- read -r ns_name < "$ns_name_path"
- if [ "${ns_name#lxd-*}" = "$ns_name" ] && \
- [ "${ns_name#lxc-*}" = "$ns_name" ]; then
- return 1
- fi
-
- return 0
-}
--
2.25.1


[meta-security][PATCH 1/2] apparmor: upgrade 3.0 -> 3.0.1

Yi Zhao
 

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

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

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

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

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

This reverts commit 6016f931ebf7b61e1358f19453ef262d9d184a4e.

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

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


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

Sangeeta Jain
 

Hi all,

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

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

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

ETA for completion is next Monday, June 28.

Thanks,
Sangeeta

-----Original Message-----
From: qa-build-notification@lists.yoctoproject.org <qa-build-
notification@lists.yoctoproject.org> On Behalf Of Pokybuild User
Sent: Wednesday, 23 June, 2021 12:33 AM
To: yocto@lists.yoctoproject.org
Cc: qa-build-notification@lists.yoctoproject.org
Subject: [qa-build-notification] QA notification for completed autobuilder build
(yocto-3.1.9.rc1)


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


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


Build hash information:

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



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







Yocto Technical Team Minutes, Engineering Sync, for June 22, 2021

Trevor Woerner
 

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

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

== attendees ==
Trevor Woerner, Stephen Jolley, Michael Halstead, Paul Barker, Richard
Purdie, Scott Murray, Steve Sakoman, Tony Tascioglu, Trevor Gamblin,
Alejandro Hernandez, Alexandre Belloni, Jan-Simon Möller, Randy MacLeod

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

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


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


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


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


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


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


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


[ANNOUNCEMENT]Milestone 1 for Yocto Project 3.4 (yocto-3.4_M1) now available

Vineela
 

Hello,

 

We are pleased to announce the first milestone release for Yocto Project 3.4 (yocto-3.4_M1) is now available for download.

 

Download:

 

http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-3.4_M1

 

bitbake: 398a1686176c695d103591089a36e25173f9fd6e

meta-arm: 6c3d62c776fc45b4bae47d178899e84b17248b31

meta-gplv2: 1ee1a73070d91e0c727f9d0db11943a61765c8d9

meta-intel: 0937728bcd98dd13d2c6829e1cd604ea2e53e5cd

meta-mingw: bfd22a248c0db4c57d5a72d675979d8341a7e9c1

oecore: 3b2903ccc791d5dedd84c75227f38ae4c8d29251

poky: 59d93693bf24e02ca0f05fe06d96a46f4f0f1bf8

 

Full Test Report:

 

http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-3.4_M1/testreport.txt

 

Thank you.

 

Vineela Tummalapalli,

Yocto Project Build and Release

vineela.tummalapalli@...

 


QA notification for completed autobuilder build (yocto-3.1.9.rc1)

Pokybuild User <pokybuild@...>
 

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


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


Build hash information:

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



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


Yocto Project Status WW25`21

Stephen Jolley
 

Current Dev Position: YP 3.4 M2

Next Deadline: 12th July 2021 YP 3.4 M2 build

 

Next Team Meetings:

 

Key Status/Updates:

  • YP 3.4 M1 has been through QA pending release approval with two QA issues highlighted.
  • YP 3.1.9 is being built ready for QA.
  • Big thanks to Paul Gortmaker for tracking down the cause of an LTP null pointer dereference (and other errors) within the cgroups mount code which was responsible for several of our LTP hangs. The issue was introduced in new code between 5.0 and 5.1 in the kernel and had been present for a while. The fix is now making its way through various kernel trees upstream.
  • Sadly, the above fix did not resolve the “rcu” autobuilder VM hangs we are seeing occasionally. These are odd in that they affect kvm and non-kvm builds (x86 and arm seen on x86-64 hosts), they pin the VM at 300-400% CPU usage and the VM will respond to pings but no ssh or console output. The rcu dumps from the kernel are likely a symptom that something is wrong rather than the cause and often look incomplete. It is as if some instantaneous host load breaks timers in a way the guest cannot recover or continue execution from. We’re continuing to try and narrow this down but it is proving elusive and progress is slow, any insight anyone may have would be welcome.
  • There are new manual sections that have recently been added on Reproducible Builds and Yocto Project Compatible.
  • We continue to deal with an issue with centos8 kernels having what looks like bad bounds checking on the utimensat_time64 32 bit syscalls where the syscall was backported into a kernel point release. We’re working on reporting it upstream.
  • We have a 10th anniversary T-shirt and some other Yocto Project items (hoody, stickers, mugs etc.) now available at https://yoctoproject.org/shop (EU and Americas sources)
  • The multiconfig changes in bitbake continue to cause problems, we still need simpler test cases to reproduce issues rather than huge builds. The existing patches seem to fix some workloads and break others. Richard is trying to fix but trying to fix autobuilder issues and other problems and these are slow builds to debug.
  • Intermittent autobuilder issues continue to occur and continue to be at record high levels. You can see the list of failures we’re continuing to see by searching for the “AB-INT” tag in bugzilla: https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT

We are working to identify the load pattern on the infrastructure that seems to trigger these.

 

Ways to contribute:

 

YP 3.4 Milestone Dates:

  • YP 3.4 M1 is in review by the TSC
  • YP 3.4 M2 build date 2021/07/12
  • YP 3.4 M2 Release date 2021/07/23
  • YP 3.4 M3 build date 2021/08/23 (Feature Freeze)
  • YP 3.4 M3 Release date 2021/09/03
  • YP 3.4 M4 build date 2021/10/04
  • YP 3.4 M4 Release date 2021/10/29

 

Planned upcoming dot releases:

  • YP 3.1.9 is being built
  • YP 3.1.9 release date 2021/07/02
  • YP 3.3.2 build date 2021/07/19
  • YP 3.3.2 release date 2021/07/30
  • YP 3.1.10 build date 2021/07/26
  • YP 3.1.10 release date 2021/08/06
  • YP 3.1.11 build date 2021/09/13
  • YP 3.1.11 release date 2021/9/24

 

Tracking Metrics:

 

The Yocto Project’s technical governance is through its Technical Steering Committee, more information is available at:

https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!]

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Update APTCONF_TARGET manually

Mauro Ziliani
 

Hi all
I move all TMPDIR in another folder
The EXTRA_DISTRO_FETAURES += "package_managent"
PACKAGE_CLASS := " package_deb "

When I build the image the package_manager try to find the debs in the older folder.

I see that this problem is in apt/apt.conf of image working dir.

How can I change manually the value of APTCONF_TARGET?

Where the APTCONF_TARGET value is stored?

Best regards,
  MZ

Sent from Mailspring, the best free email app for work


Re: Empty source package when using devtool

Frederic Martinsons
 

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

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

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

I'll took an example to try to be clearer. Let's say that I devtool modify the glib-2.0 package. Without any configuration, sources will be extracted in ${BDIR}/workspace/sources/glib-2.0.
Build directory is set by externalsrc.bbclass to ${BDIR}/tmp/work/${arch}-${distro}/glib-2.0/${PN}/${EXTENDPE}${PV}-${PR}/${BPN}/${BPN}-${PV} (the real path doesn't matter, what is matter is that B is not under devtool spaces).

This lead to have pretty long relative path in gcc compilation line (sotheming like  -c ../../../../../../../../worspace/sources/glib-2.0/glib/gmain.c for example). Hence the debug-prefix-map could not be appplied.
After the compilation stage, package.bbclass (via splitdebuginfo), there is an extraction of sources path via dwarf format parsing. We ended up parsing something like

- /workspace/sources/glib-2.0/glib/gmain.c

instead of

- /usr/src/debug/glib-2.0/1_2.58.3-r0.2/glib-2.58.3/glib/gmain.c

I patch externalsrc.bbclass to dynamically caculate correct debug-prefix-map and prepend to DEBUG_PREFIX_MAP variable, I also patch the package.bbclass to add a condition when EXTERNALSRC is defined to change the way the sources are found and copied to packages-split/${pkg}-src.

I would greatly appreciate if there is a yocto guru around there to tell me what he thinks about all of this (bug or wrong configuration ?) and if my assumptions are correct (I assume this was a compiling/packaging problem instead of a pure devtool one) 


M+ & H bugs with Milestone Movements WW25

Stephen Jolley
 

All,

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

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

Medium+

11385

poky-container: clarify that meta-data should be checked out using native tools that run the host and not with tools in container

timothy.t.orling@...

timothy.t.orling@...

3.4 M1

3.4 M2

 

13123

package.PackageTests.test_gdb_hardlink_debug failed

randy.macleod@...

randy.macleod@...

3.4 M1

3.4 M2

 

13411

ptest-perl.bbclass run-ptest is too greedy for SKIP

timothy.t.orling@...

timothy.t.orling@...

3.4 M1

3.4 M2

 

13690

runqemu with slirp, forwarded host ports are not available on host

timothy.t.orling@...

timothy.t.orling@...

3.4 M1

3.4 M2

 

13938

devtool modify virtual/kernel fails when EXTRAVERSION field is empty in Makefile

timothy.t.orling@...

timothy.t.orling@...

3.4 M1

3.4 M2

 

13975

cve-checker: save to alternate file format like JSON

timothy.t.orling@...

chee.yang.lee@...

3.4 M1

3.4 M2

 

14127

cve-check falsely indicates a vulnerabily to be patched

timothy.t.orling@...

chee.yang.lee@...

3.4 M1

3.4 M2

 

14342

Setscene tasks in both covered and notcovered errors at the end of build

richard.purdie@...

richard.purdie@...

3.4 M1

3.4 M2

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Enhancements/Bugs closed WW25!

Stephen Jolley
 

All,

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

Who

Count

randy.macleod@...

2

ross@...

1

mhalstead@...

1

richard.purdie@...

1

Grand Total

5

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Current high bug count owners for Yocto Project 3.4

Stephen Jolley
 

All,

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

Who

Count

richard.purdie@...

33

ross@...

31

michael.opdenacker@...

26

david.reyna@...

22

bruce.ashfield@...

21

JPEWhacker@...

12

bluelightning@...

12

akuster808@...

12

timothy.t.orling@...

11

trevor.gamblin@...

11

randy.macleod@...

10

sakib.sajal@...

10

kai.kang@...

9

tony.tascioglu@...

8

Qi.Chen@...

6

hongxu.jia@...

6

mingli.yu@...

6

yi.zhao@...

5

chee.yang.lee@...

5

raj.khem@...

5

alexandre.belloni@...

4

mostthingsweb@...

3

pokylinux@...

2

mshah@...

2

ydirson@...

2

jaewon@...

2

yf3yu@...

2

kexin.hao@...

2

alejandro@...

2

yoctoproject@...

1

mark.hatle@...

1

liezhi.yang@...

1

nicolas.dechesne@...

1

stacygaikovaia@...

1

dl9pf@...

1

douglas.royds@...

1

open.source@...

1

naveen.kumar.saini@...

1

Martin.Jansa@...

1

shachar@...

1

jon.mason@...

1

mister_rs@...

1

kergoth@...

1

john.kaldas.enpj@...

1

jeanmarie.lemetayer@...

1

devendra.tewari@...

1

aehs29@...

1

diego.sueiro@...

1

matthewzmd@...

1

thomas.perrot@...

1

saul.wold@...

1

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Yocto Project Newcomer & Unassigned Bugs - Help Needed

Stephen Jolley
 

All,

 

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

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

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

 

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

 

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

 

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

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Re: the downside of parallelism

Robert P. J. Day
 

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

Hi,

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

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

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

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

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

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

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

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

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

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

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

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

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

rday


Re: TLV320AIC3104: tlv320aic3104 #kernel #yocto

Alexandre Belloni
 

Hello,

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

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

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

I would like to know whether this kind of setup where the i2c is used
by a separate processor and using the SAI lines in  a different device
that runs linux will work. Kindly advice
To support that, you will have to write your own card driver or at least
write a device tree sound node with a dummy codec as Linux will not be
configuring it.

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

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


TLV320AIC3104: tlv320aic3104 #kernel #yocto

Amrun Nisha.R
 

Hi,

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

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

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


[meta-zephyr][PATCH 2/2] zephyr-coap-client: Add recipe for CoAP client

Amit Kucheria
 

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

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

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


[meta-zephyr][PATCH 1/2] zephyr-coap-server: Add recipe for CoAP server

Amit Kucheria
 

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

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

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

1141 - 1160 of 55050