Date   

Re: precedence problem with custom xserver-xf86-config_0.1.bbappend recipe

Stefan Seefeld
 


On 2021-05-31 5:09 a.m., Quentin Schulz wrote:
A common mistake would be the forgotten semi-colon and/or _prepend:
FILESEXTRAPATHS_prepend := "${THISDIR}/files"

Another common mistake is to not respect the tree layout of the original
path relative to the original recipe (or for that matter, the one you
want to override coming from the bbappend) for xorg.conf.
In that case, you can see that in meta-yocto-bsp, there's a parent
directory of xorg.conf that is not the one listed in
FILESEXTRAPATHS_prepend. You should add this directory in the path of
your bbappend.

Indeed, I was basing my layout on the original recipe, not on the poky override (which adds the $MACHINE as a subdirectory).

With that adjustment everything appears to be working fine.

https://pretalx.com/media/yocto-project-summit-2021/submissions/WTT3UV/resources/Demystifying_the_OVERRIDES_mechan_no6J6fb.pdf
slides 70 to 80 might help you. The recording should be available in a
few days/weeks.

Thanks a lot, this looks really useful ! 

Stefan
-- 

      ...ich hab' noch einen Koffer in Berlin...


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

Sangeeta Jain
 

Hi all,

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

======= Summary ========
No high milestone defects.

1 new issue found:

BUG id:14414 - [QA 3.1.8 RC1] failure in ptest : strace.printstrn-umoven.gen.test


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

Thanks,
Sangeeta

-----Original Message-----
From: qa-build-notification@... <qa-build-
notification@...> On Behalf Of Pokybuild User
Sent: Wednesday, 26 May, 2021 3:40 AM
To: yocto@...
Cc: qa-build-notification@...
Subject: [qa-build-notification] QA notification for completed autobuilder
build (yocto-3.1.8.rc1)


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


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


Build hash information:

bitbake: 078f3164dcb1de7a141bec3a8fd52631d0362631
meta-arm: 9dadb61b36fdd09a39d8cb755fa29d03928a1116
meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
meta-intel: 2fb89eb85dea00de9446c1cf44ba6a5586f42c84
meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
oecore: ecd636154e7cfc1349a7cfd8026a85eafa219535
poky: 6ebb33bdaccaeadff0c85aab27acf35723df00d8



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







Re: [meta-rockchip][PATCH] Rock64: add machine

Yann Dirson
 

Le lun. 31 mai 2021 à 10:20, Yann Dirson via lists.yoctoproject.org
<yann.dirson=blade-group.com@...> a écrit :

From: Yann Dirson <yann@...>

This is a RK3328 board from Pine64.
Board details at https://wiki.pine64.org/wiki/ROCK64.

Signed-off-by: Yann Dirson <yann@...>
---

This is just basic initial support without a kernel BSP. As is the
board boots with a serial console.
This statement was refering to core-image-minimal. The board does get
working ethernet, usb, hdmi with core-image-base, the only major devices
not handled are audio (not even hdmi-audio by default) and emmc (see
below).


Note I had to create the SoC definition for rk3328, and rather than
setting serial at 115200 there just to have the board definition
override it with rockchip-standard 1500000 I've set the latter right
in rk3328.inc.

conf/machine/include/rk3328.inc | 25 +++++++++++++++++++
conf/machine/rock64.conf | 28 ++++++++++++++++++++++
recipes-kernel/linux/linux-yocto%.bbappend | 1 +
3 files changed, 54 insertions(+)
create mode 100644 conf/machine/include/rk3328.inc
create mode 100644 conf/machine/rock64.conf

diff --git a/conf/machine/include/rk3328.inc b/conf/machine/include/rk3328.inc
new file mode 100644
index 0000000..7d67627
--- /dev/null
+++ b/conf/machine/include/rk3328.inc
@@ -0,0 +1,25 @@
+# Copyright (C) 2020 Garmin Ltd. or its subsidaries
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+SOC_FAMILY = "rk3328"
+
+DEFAULTTUNE ?= "cortexa53-crypto"
+
+require conf/machine/include/soc-family.inc
+require conf/machine/include/tune-cortexa53.inc
+require conf/machine/include/rockchip-defaults.inc
+
+KBUILD_DEFCONFIG ?= "defconfig"
+KERNEL_CLASSES = "kernel-fitimage"
+KERNEL_IMAGETYPE = "fitImage"
+
+TFA_PLATFORM = "rk3328"
+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/rock64.conf b/conf/machine/rock64.conf
new file mode 100644
index 0000000..88a8434
--- /dev/null
+++ b/conf/machine/rock64.conf
@@ -0,0 +1,28 @@
+# Copyright (C) 2021 Blade SAS
+
+#@TYPE: Machine
+#@NAME: Rock64
+#@DESCRIPTION: Rock64 RK3328 board from Pine64
+
+require include/rk3328.inc
+
+MACHINE_FEATURES += "usbhost serial"
+
+UBOOT_MACHINE = "rock64-rk3328_defconfig"
+KERNEL_DEVICETREE = "rockchip/rk3328-rock64.dtb"
+
+RK_BOOT_DEVICE = "mmcblk0"
I realize now that this part is problematic:
- booting core-image-minimal from sdcard with or without an eMMC
plugged indeed works, as does core-image-base without an eMMC
- booting core-image-base from sdcard with an eMMC plugged gets the sd
as mmcblk1

This seems to indicate that upstream dts lacks "/aliases/mmc*"
statements in the dts, I'll have to dig and see
what the proper aliases should be.


+WKS_FILE ?= "rock-pi-4.wks"
+IMAGE_FSTYPES += "wic wic.bmap"
+
+WKS_FILE_DEPENDS ?= " \
+ mtools-native \
+ dosfstools-native \
+ virtual/bootloader \
+ virtual/kernel \
+ "
+IMAGE_BOOT_FILES ?= "\
+ ${KERNEL_IMAGETYPE} \
+ "
+
+KBUILD_DEFCONFIG = "defconfig"
diff --git a/recipes-kernel/linux/linux-yocto%.bbappend b/recipes-kernel/linux/linux-yocto%.bbappend
index 7702e3f..f453281 100644
--- a/recipes-kernel/linux/linux-yocto%.bbappend
+++ b/recipes-kernel/linux/linux-yocto%.bbappend
@@ -8,3 +8,4 @@ COMPATIBLE_MACHINE_tinker-board-s = "tinker-board-s"
COMPATIBLE_MACHINE_rock-pi-4 = "rock-pi-4"
COMPATIBLE_MACHINE_nanopi-m4 = "nanopi-m4"
COMPATIBLE_MACHINE_nanopi-m4-2gb = "nanopi-m4-2gb"
+COMPATIBLE_MACHINE_rock64 = "rock64"
--
2.30.2




--
Yann Dirson <yann@...>
Blade / Shadow -- http://shadow.tech


Re: precedence problem with custom xserver-xf86-config_0.1.bbappend recipe

Quentin Schulz
 

Hi Stefan,

On Sun, May 30, 2021 at 06:10:48PM -0400, Stefan Seefeld wrote:
Hello,

I'm trying to add a custom `xorg.conf` file to my yocto build, by defining a
`recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend` recipe to
my layer.

However, it seems like I always end up getting the (empty) `xorg.conf` file
from `meta-yocto-bsp/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend`,
even though poky's `meta-yocto-bsp` layer has lower priority (5) than my own
(6).
I do get my own `xorg.conf` file if I remove (or rename) the meta-yocto-bsp
recipe, so this really looks like a precedence problem.

Any idea what I may be missing ?
A common mistake would be the forgotten semi-colon and/or _prepend:
FILESEXTRAPATHS_prepend := "${THISDIR}/files"

Another common mistake is to not respect the tree layout of the original
path relative to the original recipe (or for that matter, the one you
want to override coming from the bbappend) for xorg.conf.
In that case, you can see that in meta-yocto-bsp, there's a parent
directory of xorg.conf that is not the one listed in
FILESEXTRAPATHS_prepend. You should add this directory in the path of
your bbappend.

https://pretalx.com/media/yocto-project-summit-2021/submissions/WTT3UV/resources/Demystifying_the_OVERRIDES_mechan_no6J6fb.pdf
slides 70 to 80 might help you. The recording should be available in a
few days/weeks.

Cheers,
Quentin


[meta-rockchip][PATCH] Rock64: add machine

Yann Dirson
 

From: Yann Dirson <yann@...>

This is a RK3328 board from Pine64.
Board details at https://wiki.pine64.org/wiki/ROCK64.

Signed-off-by: Yann Dirson <yann@...>
---

This is just basic initial support without a kernel BSP. As is the
board boots with a serial console.

Note I had to create the SoC definition for rk3328, and rather than
setting serial at 115200 there just to have the board definition
override it with rockchip-standard 1500000 I've set the latter right
in rk3328.inc.

conf/machine/include/rk3328.inc | 25 +++++++++++++++++++
conf/machine/rock64.conf | 28 ++++++++++++++++++++++
recipes-kernel/linux/linux-yocto%.bbappend | 1 +
3 files changed, 54 insertions(+)
create mode 100644 conf/machine/include/rk3328.inc
create mode 100644 conf/machine/rock64.conf

diff --git a/conf/machine/include/rk3328.inc b/conf/machine/include/rk332=
8.inc
new file mode 100644
index 0000000..7d67627
--- /dev/null
+++ b/conf/machine/include/rk3328.inc
@@ -0,0 +1,25 @@
+# Copyright (C) 2020 Garmin Ltd. or its subsidaries
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+SOC_FAMILY =3D "rk3328"
+
+DEFAULTTUNE ?=3D "cortexa53-crypto"
+
+require conf/machine/include/soc-family.inc
+require conf/machine/include/tune-cortexa53.inc
+require conf/machine/include/rockchip-defaults.inc
+
+KBUILD_DEFCONFIG ?=3D "defconfig"
+KERNEL_CLASSES =3D "kernel-fitimage"
+KERNEL_IMAGETYPE =3D "fitImage"
+
+TFA_PLATFORM =3D "rk3328"
+TFA_BUILD_TARGET =3D "bl31"
+
+UBOOT_SUFFIX ?=3D "itb"
+UBOOT_ENTRYPOINT ?=3D "0x06000000"
+
+SERIAL_CONSOLES =3D "1500000;ttyS2"
+
+PREFERRED_PROVIDER_virtual/bootloader ?=3D "u-boot"
+SPL_BINARY ?=3D "idbloader.img"
diff --git a/conf/machine/rock64.conf b/conf/machine/rock64.conf
new file mode 100644
index 0000000..88a8434
--- /dev/null
+++ b/conf/machine/rock64.conf
@@ -0,0 +1,28 @@
+# Copyright (C) 2021 Blade SAS
+
+#@TYPE: Machine
+#@NAME: Rock64
+#@DESCRIPTION: Rock64 RK3328 board from Pine64
+
+require include/rk3328.inc
+
+MACHINE_FEATURES +=3D "usbhost serial"
+
+UBOOT_MACHINE =3D "rock64-rk3328_defconfig"
+KERNEL_DEVICETREE =3D "rockchip/rk3328-rock64.dtb"
+
+RK_BOOT_DEVICE =3D "mmcblk0"
+WKS_FILE ?=3D "rock-pi-4.wks"
+IMAGE_FSTYPES +=3D "wic wic.bmap"
+
+WKS_FILE_DEPENDS ?=3D " \
+ mtools-native \
+ dosfstools-native \
+ virtual/bootloader \
+ virtual/kernel \
+ "
+IMAGE_BOOT_FILES ?=3D "\
+ ${KERNEL_IMAGETYPE} \
+ "
+
+KBUILD_DEFCONFIG =3D "defconfig"
diff --git a/recipes-kernel/linux/linux-yocto%.bbappend b/recipes-kernel/=
linux/linux-yocto%.bbappend
index 7702e3f..f453281 100644
--- a/recipes-kernel/linux/linux-yocto%.bbappend
+++ b/recipes-kernel/linux/linux-yocto%.bbappend
@@ -8,3 +8,4 @@ COMPATIBLE_MACHINE_tinker-board-s =3D "tinker-board-s"
COMPATIBLE_MACHINE_rock-pi-4 =3D "rock-pi-4"
COMPATIBLE_MACHINE_nanopi-m4 =3D "nanopi-m4"
COMPATIBLE_MACHINE_nanopi-m4-2gb =3D "nanopi-m4-2gb"
+COMPATIBLE_MACHINE_rock64 =3D "rock64"
--=20
2.30.2


Re: How to switch yocto INIT_MANAGER from systemd to sysvinit #dunfell

Zoran
 

What about the following:
https://docs.yoctoproject.org/ref-manual/migration-3.0.html?highlight=init_manager#init-system-selection

To be enhanced/added with the following:
https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/bbb-releases/bbb-hardknott/README.md

Best Regards,
Zee
_______

On Fri, May 28, 2021 at 3:02 PM Swapna Nannapaneni
<sayinswapna@...> wrote:

Typo. No leading space INIT_MANAGER = "sysvinit".

Thanks,
Priya.

On Fri, May 28, 2021 at 8:55 AM Zoran Stojsavljevic <zoran.stojsavljevic@...> wrote:

you don't want the leading space.
I got the idea from reading
https://docs.yoctoproject.org/ref-manual/migration-3.0.html?highlight=init_manager#init-system-selection

But this is exactly why we need some explicit examples. :-)

Zee
_______

On Fri, May 28, 2021 at 2:45 PM Robert P. J. Day <rpjday@...> wrote:

On Fri, 28 May 2021, Zoran wrote:

Tried setting INIT_MANAGER = " sysvinit" in build/conf/local.conf
Is it INIT_MANAGER = " sysvinit" , or INIT_MANAGER = "sysvinit" (no
blank at the beginning)?

Thank you,
Zee
you don't want the leading space.

rday


precedence problem with custom xserver-xf86-config_0.1.bbappend recipe

Stefan Seefeld
 

Hello,

I'm trying to add a custom `xorg.conf` file to my yocto build, by defining a `recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend` recipe to my layer.

However, it seems like I always end up getting the (empty) `xorg.conf` file from `meta-yocto-bsp/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend`, even though poky's `meta-yocto-bsp` layer has lower priority (5) than my own (6).
I do get my own `xorg.conf` file if I remove (or rename) the meta-yocto-bsp recipe, so this really looks like a precedence problem.

Any idea what I may be missing ?

Thanks !

Stefan
-- 

      ...ich hab' noch einen Koffer in Berlin...


[meta-security][PATCH 5/5] packagegroup-core-security: drop python3-scapy

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@...>
---
recipes-core/packagegroup/packagegroup-core-security.bb | 2 --
1 file changed, 2 deletions(-)

diff --git a/recipes-core/packagegroup/packagegroup-core-security.bb b/recipes-core/packagegroup/packagegroup-core-security.bb
index cf9620f..e7b6d9b 100644
--- a/recipes-core/packagegroup/packagegroup-core-security.bb
+++ b/recipes-core/packagegroup/packagegroup-core-security.bb
@@ -37,7 +37,6 @@ RDEPENDS_packagegroup-security-utils = "\
pinentry \
python3-privacyidea \
python3-fail2ban \
- python3-scapy \
softhsm \
libest \
opendnssec \
@@ -89,7 +88,6 @@ RDEPENDS_packagegroup-meta-security-ptest-packages = "\
ptest-runner \
samhain-standalone-ptest \
libseccomp-ptest \
- python3-scapy-ptest \
suricata-ptest \
python3-fail2ban-ptest \
${@bb.utils.contains("DISTRO_FEATURES", "smack", "smack-ptest", "",d)} \
--
2.24.3


[meta-security][PATCH 4/5] python3-scapy: drop , now in meta-python

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@...>
---
recipes-security/scapy/files/run-ptest | 4 ---
recipes-security/scapy/python3-scapy_2.4.5.bb | 30 -------------------
2 files changed, 34 deletions(-)
delete mode 100644 recipes-security/scapy/files/run-ptest
delete mode 100644 recipes-security/scapy/python3-scapy_2.4.5.bb

diff --git a/recipes-security/scapy/files/run-ptest b/recipes-security/scapy/files/run-ptest
deleted file mode 100644
index 797d8ec..0000000
--- a/recipes-security/scapy/files/run-ptest
+++ /dev/null
@@ -1,4 +0,0 @@
-#!/bin/sh
-UTscapy3 -t regression.uts -f text -l -C \
- -o @PTEST_PATH@/scapy_ptest_$(date +%Y%m%d-%H%M%S).log \
- 2>&1 | sed -e 's/^passed None/PASS:/' -e 's/^failed None/FAIL:/'
diff --git a/recipes-security/scapy/python3-scapy_2.4.5.bb b/recipes-security/scapy/python3-scapy_2.4.5.bb
deleted file mode 100644
index 8f36520..0000000
--- a/recipes-security/scapy/python3-scapy_2.4.5.bb
+++ /dev/null
@@ -1,30 +0,0 @@
-SUMMARY = "Network scanning and manipulation tool"
-DESCRIPTION = "Scapy is a powerful interactive packet manipulation program. It is able to forge or decode packets of a wide number of protocols, send them on the wire, capture them, match requests and replies, and much more. It can easily handle most classical tasks like scanning, tracerouting, probing, unit tests, attacks or network discovery (it can replace hping, 85% of nmap, arpspoof, arp-sk, arping, tcpdump, tethereal, p0f, etc.). It also performs very well at a lot of other specific tasks that most other tools can't handle, like sending invalid frames, injecting your own 802.11 frames, combining technics (VLAN hopping+ARP cache poisoning, VOIP decoding on WEP encrypted channel, ...), etc."
-SECTION = "security"
-LICENSE = "GPLv2"
-
-LIC_FILES_CHKSUM = "file://LICENSE;md5=b234ee4d69f5fce4486a80fdaf4a4263"
-
-SRCREV = "32cd7eb0f620d9adf171c48d55514e8326a538d7"
-SRC_URI = "git://github.com/secdev/scapy.git \
- file://run-ptest"
-
-S = "${WORKDIR}/git"
-
-UPSTREAM_CHECK_COMMITS = "1"
-
-inherit setuptools3 ptest
-
-do_install_append() {
- mv ${D}${bindir}/scapy ${D}${bindir}/scapy3
- mv ${D}${bindir}/UTscapy ${D}${bindir}/UTscapy3
-}
-
-do_install_ptest() {
- install -m 0644 ${S}/test/regression.uts ${D}${PTEST_PATH}
- sed -i 's,@PTEST_PATH@,${PTEST_PATH},' ${D}${PTEST_PATH}/run-ptest
-}
-
-RDEPENDS_${PN} = "tcpdump ${PYTHON_PN}-compression ${PYTHON_PN}-cryptography ${PYTHON_PN}-netclient \
- ${PYTHON_PN}-netserver ${PYTHON_PN}-pydoc ${PYTHON_PN}-pkgutil ${PYTHON_PN}-shell \
- ${PYTHON_PN}-threading ${PYTHON_PN}-numbers ${PYTHON_PN}-pycrypto"
--
2.24.3


[meta-security][PATCH 3/5] initramfs-framework: fix YCL issue.

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@...>
---
.../initrdscripts/initramfs-framework.inc | 16 ++++++++++++++++
.../initramfs-framework_1.0.bbappend | 17 +----------------
2 files changed, 17 insertions(+), 16 deletions(-)
create mode 100644 recipes-core/initrdscripts/initramfs-framework.inc

diff --git a/recipes-core/initrdscripts/initramfs-framework.inc b/recipes-core/initrdscripts/initramfs-framework.inc
new file mode 100644
index 0000000..dad9c96
--- /dev/null
+++ b/recipes-core/initrdscripts/initramfs-framework.inc
@@ -0,0 +1,16 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+SRC_URI_append = "\
+ file://dmverity \
+"
+
+do_install_append() {
+ # dm-verity
+ install ${WORKDIR}/dmverity ${D}/init.d/80-dmverity
+}
+
+PACKAGES_append = " initramfs-module-dmverity"
+
+SUMMARY_initramfs-module-dmverity = "initramfs dm-verity rootfs support"
+RDEPENDS_initramfs-module-dmverity = "${PN}-base"
+FILES_initramfs-module-dmverity = "/init.d/80-dmverity"
diff --git a/recipes-core/initrdscripts/initramfs-framework_1.0.bbappend b/recipes-core/initrdscripts/initramfs-framework_1.0.bbappend
index dad9c96..dc74e01 100644
--- a/recipes-core/initrdscripts/initramfs-framework_1.0.bbappend
+++ b/recipes-core/initrdscripts/initramfs-framework_1.0.bbappend
@@ -1,16 +1 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
-
-SRC_URI_append = "\
- file://dmverity \
-"
-
-do_install_append() {
- # dm-verity
- install ${WORKDIR}/dmverity ${D}/init.d/80-dmverity
-}
-
-PACKAGES_append = " initramfs-module-dmverity"
-
-SUMMARY_initramfs-module-dmverity = "initramfs dm-verity rootfs support"
-RDEPENDS_initramfs-module-dmverity = "${PN}-base"
-FILES_initramfs-module-dmverity = "/init.d/80-dmverity"
+require ${@bb.utils.contains('IMAGE_CLASSES', 'dm-verity', 'initramfs-framework.inc', '', d)}
--
2.24.3


[meta-security][PATCH 2/5] linux-%_5.%.bbappend: drop recipe

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@...>
---
recipes-kernel/linux/linux-%_5.%.bbappend | 4 ----
1 file changed, 4 deletions(-)
delete mode 100644 recipes-kernel/linux/linux-%_5.%.bbappend

diff --git a/recipes-kernel/linux/linux-%_5.%.bbappend b/recipes-kernel/linux/linux-%_5.%.bbappend
deleted file mode 100644
index 6bc40cd..0000000
--- a/recipes-kernel/linux/linux-%_5.%.bbappend
+++ /dev/null
@@ -1,4 +0,0 @@
-KERNEL_FEATURES_append = " ${@bb.utils.contains("DISTRO_FEATURES", "apparmor", " features/apparmor/apparmor.scc", "" ,d)}"
-KERNEL_FEATURES_append = " ${@bb.utils.contains("DISTRO_FEATURES", "smack", " features/smack/smack.scc", "" ,d)}"
-KERNEL_FEATURES_append = " ${@bb.utils.contains("DISTRO_FEATURES", "yama", " features/yama/yama.scc", "" ,d)}"
-KERNEL_FEATURES_append = " ${@bb.utils.contains("IMAGE_CLASSES", "dm-verity-img", " features/device-mapper/dm-verity.scc", "" ,d)}"
--
2.24.3


[meta-security][PATCH 1/5] busybox: drop as libsecomp is in core

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@...>
---
recipes-core/busybox/busybox/head.cfg | 1 -
recipes-core/busybox/busybox_%.bbappend | 1 -
recipes-core/busybox/busybox_libsecomp.inc | 3 ---
3 files changed, 5 deletions(-)
delete mode 100644 recipes-core/busybox/busybox/head.cfg
delete mode 100644 recipes-core/busybox/busybox_%.bbappend
delete mode 100644 recipes-core/busybox/busybox_libsecomp.inc

diff --git a/recipes-core/busybox/busybox/head.cfg b/recipes-core/busybox/busybox/head.cfg
deleted file mode 100644
index 16017ea..0000000
--- a/recipes-core/busybox/busybox/head.cfg
+++ /dev/null
@@ -1 +0,0 @@
-CONFIG_FEATURE_FANCY_HEAD=y
diff --git a/recipes-core/busybox/busybox_%.bbappend b/recipes-core/busybox/busybox_%.bbappend
deleted file mode 100644
index 27a2482..0000000
--- a/recipes-core/busybox/busybox_%.bbappend
+++ /dev/null
@@ -1 +0,0 @@
-require ${@bb.utils.contains('DISTRO_FEATURES', 'ptest', 'busybox_libsecomp.inc', '', d)}
diff --git a/recipes-core/busybox/busybox_libsecomp.inc b/recipes-core/busybox/busybox_libsecomp.inc
deleted file mode 100644
index 4af22ce..0000000
--- a/recipes-core/busybox/busybox_libsecomp.inc
+++ /dev/null
@@ -1,3 +0,0 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/busybox:"
-
-SRC_URI_append = " file://head.cfg"
--
2.24.3


Re: #yocto ASUS ROG STRIX Z390-I #yocto

Yocto
 

use meta-intel build for a core-i7 I also have an ASUS ROG board running yocto.

On 5/30/21 6:15 PM, a.elgammal2019@... wrote:
Hello,

I have a ROG STRIX Z390-I motherboard with an Intel® Z390 chipset. And I want to create a custom BSP Layer for it. Where should I start? I did not find any yocto community for ASUS. So, Any guides would be helpful. Thank you



#Tesla T4 Support #tesla

Abdelrahman El-Gammal <a.elgammal2019@...>
 

I am building a custom image for 

ASUS ROG STRIX Z390-I, with Tesla T4

I will build on meta-intel. But the problem is that I am also using Tesla T4 GPU, which requires CUDA toolkit to install. And CUDA requires a supported linux distribution. So, how to setup and use the T4 drivers?


#yocto ASUS ROG STRIX Z390-I #yocto

a.elgammal2019@...
 

Hello,

I have a ROG STRIX Z390-I motherboard with an Intel® Z390 chipset. And I want to create a custom BSP Layer for it. Where should I start? I did not find any yocto community for ASUS. So, Any guides would be helpful.
Thank you


Re: [poky][master][PATCH} VirGL: depends on virtual/gbm

Joel Winarske
 

It looks like a Mesa dependency is looming for NVIDIA:  https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9902

Thanks

On Fri, May 28, 2021 at 1:30 PM Alexander Kanavin <alex.kanavin@...> wrote:
Thanks, it took me a moment to understand that this still does not mean that nvidia supports gbm somehow, somewhere, but rather that virgl needs to be explicit about needing gbm.

The patch should be going to the oe-core list.

Alex

On Fri, 28 May 2021 at 21:16, Joel Winarske <joel.winarske@...> wrote:

This addresses cases where the platform doesn't depend on Mesa.  Tegra is one example.

From 427d6248379bf37f5522d4bb1013b8c0b7a26b5b Mon Sep 17 00:00:00 2001
From: Joel Winarske <joel.winarske@...>
Date: Fri, 28 May 2021 12:10:46 -0700
Subject: [PATCH] VirGL depends on gbm.h

Signed-off-by: Joel Winarske <joel.winarske@...>
---
 meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb b/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb
index 3991895823..65bd1af942 100644
--- a/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb
+++ b/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb
@@ -8,7 +8,7 @@ HOMEPAGE = "https://virgil3d.github.io/"
 LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://COPYING;md5=c81c08eeefd9418fca8f88309a76db10"
 
-DEPENDS = "libdrm virtual/libgl libepoxy"
+DEPENDS = "libdrm virtual/libgl virtual/libgbm libepoxy"
 SRCREV = "363915595e05fb252e70d6514be2f0c0b5ca312b"
 SRC_URI = "git://anongit.freedesktop.org/virglrenderer;branch=branch-0.9.1 \
            file://0001-meson.build-use-python3-directly-for-python.patch \
--
2.30.2






Re: [poky][master][PATCH} VirGL: depends on virtual/gbm

Alexander Kanavin
 

Thanks, it took me a moment to understand that this still does not mean that nvidia supports gbm somehow, somewhere, but rather that virgl needs to be explicit about needing gbm.

The patch should be going to the oe-core list.

Alex


On Fri, 28 May 2021 at 21:16, Joel Winarske <joel.winarske@...> wrote:

This addresses cases where the platform doesn't depend on Mesa.  Tegra is one example.

From 427d6248379bf37f5522d4bb1013b8c0b7a26b5b Mon Sep 17 00:00:00 2001
From: Joel Winarske <joel.winarske@...>
Date: Fri, 28 May 2021 12:10:46 -0700
Subject: [PATCH] VirGL depends on gbm.h

Signed-off-by: Joel Winarske <joel.winarske@...>
---
 meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb b/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb
index 3991895823..65bd1af942 100644
--- a/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb
+++ b/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb
@@ -8,7 +8,7 @@ HOMEPAGE = "https://virgil3d.github.io/"
 LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://COPYING;md5=c81c08eeefd9418fca8f88309a76db10"
 
-DEPENDS = "libdrm virtual/libgl libepoxy"
+DEPENDS = "libdrm virtual/libgl virtual/libgbm libepoxy"
 SRCREV = "363915595e05fb252e70d6514be2f0c0b5ca312b"
 SRC_URI = "git://anongit.freedesktop.org/virglrenderer;branch=branch-0.9.1 \
            file://0001-meson.build-use-python3-directly-for-python.patch \
--
2.30.2






[poky][master][PATCH} VirGL: depends on virtual/gbm

Joel Winarske
 


This addresses cases where the platform doesn't depend on Mesa.  Tegra is one example.

From 427d6248379bf37f5522d4bb1013b8c0b7a26b5b Mon Sep 17 00:00:00 2001
From: Joel Winarske <joel.winarske@...>
Date: Fri, 28 May 2021 12:10:46 -0700
Subject: [PATCH] VirGL depends on gbm.h

Signed-off-by: Joel Winarske <joel.winarske@...>
---
 meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb b/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb
index 3991895823..65bd1af942 100644
--- a/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb
+++ b/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb
@@ -8,7 +8,7 @@ HOMEPAGE = "https://virgil3d.github.io/"
 LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://COPYING;md5=c81c08eeefd9418fca8f88309a76db10"
 
-DEPENDS = "libdrm virtual/libgl libepoxy"
+DEPENDS = "libdrm virtual/libgl virtual/libgbm libepoxy"
 SRCREV = "363915595e05fb252e70d6514be2f0c0b5ca312b"
 SRC_URI = "git://anongit.freedesktop.org/virglrenderer;branch=branch-0.9.1 \
            file://0001-meson.build-use-python3-directly-for-python.patch \
--
2.30.2



Re: How to switch yocto INIT_MANAGER from systemd to sysvinit #dunfell

Swapna Nannapaneni
 

Typo. No leading space  INIT_MANAGER = "sysvinit".

Thanks,
Priya.


On Fri, May 28, 2021 at 8:55 AM Zoran Stojsavljevic <zoran.stojsavljevic@...> wrote:
> you don't want the leading space.

I got the idea from reading
https://docs.yoctoproject.org/ref-manual/migration-3.0.html?highlight=init_manager#init-system-selection

But this is exactly why we need some explicit examples. :-)

Zee
_______

On Fri, May 28, 2021 at 2:45 PM Robert P. J. Day <rpjday@...> wrote:
>
> On Fri, 28 May 2021, Zoran wrote:
>
> > > Tried setting  INIT_MANAGER  = " sysvinit" in build/conf/local.conf
> >
> > Is it INIT_MANAGER  = " sysvinit" , or INIT_MANAGER  = "sysvinit" (no
> > blank at the beginning)?
> >
> > Thank you,
> > Zee
>
>   you don't want the leading space.
>
> rday


Re: How to switch yocto INIT_MANAGER from systemd to sysvinit #dunfell

Zoran
 

you don't want the leading space.
I got the idea from reading
https://docs.yoctoproject.org/ref-manual/migration-3.0.html?highlight=init_manager#init-system-selection

But this is exactly why we need some explicit examples. :-)

Zee
_______

On Fri, May 28, 2021 at 2:45 PM Robert P. J. Day <rpjday@...> wrote:

On Fri, 28 May 2021, Zoran wrote:

Tried setting INIT_MANAGER = " sysvinit" in build/conf/local.conf
Is it INIT_MANAGER = " sysvinit" , or INIT_MANAGER = "sysvinit" (no
blank at the beginning)?

Thank you,
Zee
you don't want the leading space.

rday

3741 - 3760 of 57417