Date   

[meta-rockchip][PATCH v2 0/4] kmeta BSP for nanopi-m4

Yann Dirson
 

From: Yann Dirson <yann@blade-group.com>

This second iteration adds support for KBUILD_DEFCONFIG=3D"", as well as
a loosely-related patch to avoid touching KCONFIG_MODE.

Kernel weight:
- standard 11MB
- tiny 5MB
- tiny with no defconfig 2.5MB

Changes in v2:
- added explicit CONFIG_PHYLIB and CONFIG_MMC to support empty defconfig
- added CONFIG_SPI_ROCKCHIP

Yann Dirson (4):
linux-yocto: reduce bbappend duplication
rockchip-defaults: don't force KCONFIG_MODE to alldefconfig
NanoPi-M4: let all variants use the same KMACHINE type
WIP linux-yocto: add a NanoPi-M4 BSP

conf/machine/include/nanopi-m4.inc | 1 +
conf/machine/include/rockchip-defaults.inc | 1 -
...cto-dev.bbappend =3D> linux-yocto%.bbappend} | 6 +++
.../linux/linux-yocto-rt_%.bbappend | 10 ----
.../linux/linux-yocto-tiny_%.bbappend | 10 ----
.../linux-yocto/bsp/nanopi-m4-standard.scc | 7 +++
.../linux/linux-yocto/bsp/nanopi-m4-tiny.scc | 7 +++
.../linux/linux-yocto/bsp/nanopi-m4.cfg | 40 ++++++++++++++
.../linux/linux-yocto/bsp/nanopi-m4.scc | 5 ++
.../linux/linux-yocto/bsp/rk3399.cfg | 50 +++++++++++++++++
.../linux/linux-yocto/bsp/rk3399.scc | 5 ++
.../linux/linux-yocto/bsp/rockchip.cfg | 53 +++++++++++++++++++
.../linux/linux-yocto/bsp/rockchip.scc | 6 +++
recipes-kernel/linux/linux-yocto_%.bbappend | 10 ----
14 files changed, 180 insertions(+), 31 deletions(-)
rename recipes-kernel/linux/{linux-yocto-dev.bbappend =3D> linux-yocto%.=
bbappend} (80%)
delete mode 100644 recipes-kernel/linux/linux-yocto-rt_%.bbappend
delete mode 100644 recipes-kernel/linux/linux-yocto-tiny_%.bbappend
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/nanopi-m4-standa=
rd.scc
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/nanopi-m4-tiny.s=
cc
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/nanopi-m4.cfg
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/nanopi-m4.scc
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/rk3399.cfg
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/rk3399.scc
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/rockchip.cfg
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/rockchip.scc
delete mode 100644 recipes-kernel/linux/linux-yocto_%.bbappend

--=20
2.30.2


[meta-rockchip][PATCH v2 4/4] WIP linux-yocto: add a NanoPi-M4 BSP

Yann Dirson
 

From: Yann Dirson <yann@blade-group.com>

This patch provides "standard" and "tiny" BSP.

There is still much work to be done in dispatching feature to individual
scc files - the more boards we can support the better it will get.
Not all SoC features are covered yet either.

Tiny is not really testable by itself today, I played with it using:

PREFERRED_PROVIDER_virtual/kernel =3D "linux-yocto-tiny"
KERNEL_FEATURES_append =3D "\
ktypes/base/base.scc \
features/debug/printk.scc \
cfg/fs/ext4.scc \
"

Such a tiny build is still using mainline defconfig with lots of hardware
features, and the kernel can be slimmed down even more by using:

KBUILD_DEFCONFIG =3D ""

Kernel weight:
- standard 11MB
- tiny 5MB
- tiny with no defconfig 2.5MB

Changes in v2:
- added explicit CONFIG_PHYLIB and CONFIG_MMC to support empty defconfig
- added CONFIG_SPI_ROCKCHIP
---
recipes-kernel/linux/linux-yocto%.bbappend | 6 +++
.../linux-yocto/bsp/nanopi-m4-standard.scc | 7 +++
.../linux/linux-yocto/bsp/nanopi-m4-tiny.scc | 7 +++
.../linux/linux-yocto/bsp/nanopi-m4.cfg | 40 ++++++++++++++
.../linux/linux-yocto/bsp/nanopi-m4.scc | 5 ++
.../linux/linux-yocto/bsp/rk3399.cfg | 50 +++++++++++++++++
.../linux/linux-yocto/bsp/rk3399.scc | 5 ++
.../linux/linux-yocto/bsp/rockchip.cfg | 53 +++++++++++++++++++
.../linux/linux-yocto/bsp/rockchip.scc | 6 +++
9 files changed, 179 insertions(+)
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/nanopi-m4-standa=
rd.scc
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/nanopi-m4-tiny.s=
cc
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/nanopi-m4.cfg
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/nanopi-m4.scc
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/rk3399.cfg
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/rk3399.scc
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/rockchip.cfg
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/rockchip.scc

diff --git a/recipes-kernel/linux/linux-yocto%.bbappend b/recipes-kernel/=
linux/linux-yocto%.bbappend
index 0bc13d7..99cfc5f 100644
--- a/recipes-kernel/linux/linux-yocto%.bbappend
+++ b/recipes-kernel/linux/linux-yocto%.bbappend
@@ -1,3 +1,9 @@
+FILESEXTRAPATHS_prepend :=3D "${THISDIR}/linux-yocto:"
+
+SRC_URI_append =3D "\
+ file://bsp;type=3Dkmeta;subdir=3Dkernel-meta \
+"
+
COMPATIBLE_MACHINE_marsboard-rk3066 =3D "marsboard-rk3066"
COMPATIBLE_MACHINE_rock2-square =3D "rock2-square"
COMPATIBLE_MACHINE_radxarock =3D "radxarock"
diff --git a/recipes-kernel/linux/linux-yocto/bsp/nanopi-m4-standard.scc =
b/recipes-kernel/linux/linux-yocto/bsp/nanopi-m4-standard.scc
new file mode 100644
index 0000000..5c74d6b
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto/bsp/nanopi-m4-standard.scc
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: MIT
+define KMACHINE nanopi-m4
+define KTYPE standard
+define KARCH arm
+
+include ktypes/standard/standard.scc
+include nanopi-m4.scc
diff --git a/recipes-kernel/linux/linux-yocto/bsp/nanopi-m4-tiny.scc b/re=
cipes-kernel/linux/linux-yocto/bsp/nanopi-m4-tiny.scc
new file mode 100644
index 0000000..6e94d6a
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto/bsp/nanopi-m4-tiny.scc
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: MIT
+define KMACHINE nanopi-m4
+define KTYPE tiny
+define KARCH arm
+
+include ktypes/tiny/tiny.scc
+include nanopi-m4.scc
diff --git a/recipes-kernel/linux/linux-yocto/bsp/nanopi-m4.cfg b/recipes=
-kernel/linux/linux-yocto/bsp/nanopi-m4.cfg
new file mode 100644
index 0000000..5864008
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto/bsp/nanopi-m4.cfg
@@ -0,0 +1,40 @@
+CONFIG_MFD_RK808=3Dy
+CONFIG_COMMON_CLK_RK808=3Dy
+
+# regulators
+CONFIG_REGULATOR_RK808=3Dy
+CONFIG_REGULATOR_FAN53555=3Dy
+
+CONFIG_MMC_BLOCK=3Dy
+
+# audio jack
+CONFIG_SND_SOC_ROCKCHIP_RT5651=3Dm
+
+# BT, maybe some - RFCOMM for headset voice, MSFTEXT ?
+CONFIG_BT=3Dm
+#CONFIG_BT_BCM=3Dm
+#CONFIG_BT_HCIUART_BCM=3Dm
+CONFIG_BT_RFCOMM=3Dm
+CONFIG_BT_RFCOMM_TTY=3Dy
+CONFIG_BT_BNEP=3Dm
+CONFIG_BT_HS=3Dy
+CONFIG_BT_LE=3Dy
+CONFIG_BT_MSFTEXT=3Dy
+CONFIG_BT_DEBUGFS=3Dy
+CONFIG_WIRELESS=3Dy
+CONFIG_RFKILL=3Dm
+
+CONFIG_PHY_ROCKCHIP_DP=3Dy
+
+CONFIG_VIDEO_DEV=3Dm
+CONFIG_V4L_MEM2MEM_DRIVERS=3Dy
+CONFIG_VIDEO_ROCKCHIP_RGA=3Dm
+
+CONFIG_DRM_DW_HDMI_AHB_AUDIO=3Dm
+CONFIG_SND_SOC_RK3288_HDMI_ANALOG=3Dm
+
+CONFIG_V4L2_H264=3Dm
+CONFIG_MEDIA_CONTROLLER_REQUEST_API=3Dy
+CONFIG_VIDEO_HANTRO=3Dm
+CONFIG_VIDEO_HANTRO_ROCKCHIP=3Dy
+CONFIG_VIDEO_ROCKCHIP_VDEC=3Dm
diff --git a/recipes-kernel/linux/linux-yocto/bsp/nanopi-m4.scc b/recipes=
-kernel/linux/linux-yocto/bsp/nanopi-m4.scc
new file mode 100644
index 0000000..f4267aa
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto/bsp/nanopi-m4.scc
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: MIT
+
+kconf hardware nanopi-m4.cfg
+
+include rk3399.scc
diff --git a/recipes-kernel/linux/linux-yocto/bsp/rk3399.cfg b/recipes-ke=
rnel/linux/linux-yocto/bsp/rk3399.cfg
new file mode 100644
index 0000000..b0002f4
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto/bsp/rk3399.cfg
@@ -0,0 +1,50 @@
+# A72 errata, all past revisions
+CONFIG_ARM64_ERRATUM_1319367=3Dy
+# A53 errata, all patched on boot when needed
+CONFIG_ARM64_ERRATUM_826319=3Dy
+CONFIG_ARM64_ERRATUM_827319=3Dy
+CONFIG_ARM64_ERRATUM_824069=3Dy
+CONFIG_ARM64_ERRATUM_819472=3Dy
+
+# cru
+CONFIG_CLK_RK3399=3Dy
+
+CONFIG_PL330_DMA=3Dy
+CONFIG_I2C_RK3X=3Dy
+CONFIG_SERIAL_8250_DW=3Dy
+
+# usb
+CONFIG_PHY_ROCKCHIP_INNO_USB2=3Dy
+CONFIG_PHY_ROCKCHIP_TYPEC=3Dy
+
+# ethernet
+CONFIG_NET_VENDOR_STMICRO=3Dy
+CONFIG_STMMAC_ETH=3Dm
+CONFIG_STMMAC_PLATFORM=3Dm
+CONFIG_DWMAC_ROCKCHIP=3Dm
+CONFIG_PHYLIB=3Dm
+CONFIG_ROCKCHIP_PHY=3Dm
+
+# display
+CONFIG_ROCKCHIP_DW_HDMI=3Dy
+CONFIG_ROCKCHIP_DW_MIPI_DSI=3Dy
+CONFIG_ROCKCHIP_ANALOGIX_DP=3Dy
+CONFIG_ROCKCHIP_CDN_DP=3Dy
+CONFIG_DRM_DW_HDMI=3Dm
+CONFIG_DRM_DW_HDMI_I2S_AUDIO=3Dm
+CONFIG_DRM_DW_HDMI_CEC=3Dm
+CONFIG_DRM_DW_MIPI_DSI=3Dm
+CONFIG_DRM_PANFROST=3Dm
+
+# usb
+CONFIG_USB_DWC2=3Dy
+CONFIG_USB_DWC3=3Dy
+CONFIG_USB_DWC3_DUAL_ROLE=3Dy
+
+# sd/mmc
+CONFIG_MMC=3Dy
+CONFIG_MMC_SDHCI=3Dy
+CONFIG_MMC_SDHCI_PLTFM=3Dy
+CONFIG_MMC_DW=3Dy
+CONFIG_MMC_DW_ROCKCHIP=3Dy
+CONFIG_MMC_SDHCI_OF_ARASAN=3Dy
diff --git a/recipes-kernel/linux/linux-yocto/bsp/rk3399.scc b/recipes-ke=
rnel/linux/linux-yocto/bsp/rk3399.scc
new file mode 100644
index 0000000..9b1a88e
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto/bsp/rk3399.scc
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: MIT
+
+kconf hardware rk3399.cfg
+
+include rockchip.scc
diff --git a/recipes-kernel/linux/linux-yocto/bsp/rockchip.cfg b/recipes-=
kernel/linux/linux-yocto/bsp/rockchip.cfg
new file mode 100644
index 0000000..0c91a1a
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto/bsp/rockchip.cfg
@@ -0,0 +1,53 @@
+CONFIG_ARCH_ROCKCHIP=3Dy
+CONFIG_COMMON_CLK_ROCKCHIP=3Dy
+CONFIG_REGULATOR=3Dy
+CONFIG_REGULATOR_FIXED_VOLTAGE=3Dy
+CONFIG_REGULATOR_PWM=3Dy
+CONFIG_I2C=3Dy
+CONFIG_FW_LOADER=3Dy
+CONFIG_PHY_ROCKCHIP_EMMC=3Dy
+CONFIG_PINCTRL=3Dy
+CONFIG_PINCTRL_ROCKCHIP=3Dy
+CONFIG_ROCKCHIP_IODOMAIN=3Dy
+CONFIG_ROCKCHIP_PM_DOMAINS=3Dy
+
+CONFIG_SPI=3Dy
+CONFIG_SPI_ROCKCHIP=3Dm
+
+CONFIG_PWM=3Dy
+CONFIG_PWM_ROCKCHIP=3Dy
+
+CONFIG_DRM_KMS_HELPER=3Dm
+CONFIG_DRM_FBDEV_EMULATION=3Dy
+CONFIG_ROCKCHIP_IOMMU=3Dy
+CONFIG_DRM_ROCKCHIP=3Dm
+CONFIG_DRM_BRIDGE=3Dy
+
+CONFIG_SND=3Dy
+CONFIG_SND_SOC=3Dy
+CONFIG_SND_HDA_CODEC_HDMI=3Dm
+CONFIG_SND_SOC_ROCKCHIP=3Dm
+CONFIG_SND_SOC_ROCKCHIP_I2S=3Dm
+CONFIG_SND_SOC_ROCKCHIP_SPDIF=3Dm
+
+CONFIG_NVMEM=3Dy
+CONFIG_ROCKCHIP_EFUSE=3Dm
+
+CONFIG_CPU_FREQ=3Dy
+
+# maybe?
+CONFIG_MFD_SYSCON=3Dy
+CONFIG_FB_MODE_HELPERS=3Dy
+
+# possibly for somewhere else
+CONFIG_DRM=3Dm
+CONFIG_DRM_MIPI_DSI=3Dy
+CONFIG_SOUND=3Dy
+CONFIG_USB=3Dy
+CONFIG_SERIAL_8250=3Dy
+CONFIG_SERIAL_8250_CONSOLE=3Dy
+
+# obviously for somewhere else
+CONFIG_MULTIUSER=3Dy
+CONFIG_TTY=3Dy
+CONFIG_SERIAL_EARLYCON=3Dy
diff --git a/recipes-kernel/linux/linux-yocto/bsp/rockchip.scc b/recipes-=
kernel/linux/linux-yocto/bsp/rockchip.scc
new file mode 100644
index 0000000..800f105
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto/bsp/rockchip.scc
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: MIT
+
+kconf hardware rockchip.cfg
+
+include cfg/dmaengine.scc
+include features/mmc/mmc-block.cfg
--=20
2.30.2


[meta-rockchip][PATCH v2 3/4] NanoPi-M4: let all variants use the same KMACHINE type

Yann Dirson
 

From: Yann Dirson <yann@blade-group.com>

Signed-off-by: Yann Dirson <yann@blade-group.com>
---
conf/machine/include/nanopi-m4.inc | 1 +
1 file changed, 1 insertion(+)

diff --git a/conf/machine/include/nanopi-m4.inc b/conf/machine/include/na=
nopi-m4.inc
index 74cdae8..603160f 100644
--- a/conf/machine/include/nanopi-m4.inc
+++ b/conf/machine/include/nanopi-m4.inc
@@ -3,6 +3,7 @@
=20
require rk3399.inc
=20
+KMACHINE =3D "nanopi-m4"
KERNEL_DEVICETREE =3D "rockchip/rk3399-nanopi-m4.dtb"
=20
RK_BOOT_DEVICE =3D "mmcblk1"
--=20
2.30.2


[meta-rockchip][PATCH v2 1/4] linux-yocto: reduce bbappend duplication

Yann Dirson
 

From: Yann Dirson <yann@blade-group.com>

Signed-off-by: Yann Dirson <yann@blade-group.com>
---
...{linux-yocto-dev.bbappend =3D> linux-yocto%.bbappend} | 0
recipes-kernel/linux/linux-yocto-rt_%.bbappend | 10 ----------
recipes-kernel/linux/linux-yocto-tiny_%.bbappend | 10 ----------
recipes-kernel/linux/linux-yocto_%.bbappend | 10 ----------
4 files changed, 30 deletions(-)
rename recipes-kernel/linux/{linux-yocto-dev.bbappend =3D> linux-yocto%.=
bbappend} (100%)
delete mode 100644 recipes-kernel/linux/linux-yocto-rt_%.bbappend
delete mode 100644 recipes-kernel/linux/linux-yocto-tiny_%.bbappend
delete mode 100644 recipes-kernel/linux/linux-yocto_%.bbappend

diff --git a/recipes-kernel/linux/linux-yocto-dev.bbappend b/recipes-kern=
el/linux/linux-yocto%.bbappend
similarity index 100%
rename from recipes-kernel/linux/linux-yocto-dev.bbappend
rename to recipes-kernel/linux/linux-yocto%.bbappend
diff --git a/recipes-kernel/linux/linux-yocto-rt_%.bbappend b/recipes-ker=
nel/linux/linux-yocto-rt_%.bbappend
deleted file mode 100644
index 7702e3f..0000000
--- a/recipes-kernel/linux/linux-yocto-rt_%.bbappend
+++ /dev/null
@@ -1,10 +0,0 @@
-COMPATIBLE_MACHINE_marsboard-rk3066 =3D "marsboard-rk3066"
-COMPATIBLE_MACHINE_rock2-square =3D "rock2-square"
-COMPATIBLE_MACHINE_radxarock =3D "radxarock"
-COMPATIBLE_MACHINE_firefly-rk3288 =3D "firefly-rk3288"
-COMPATIBLE_MACHINE_vyasa-rk3288 =3D "vyasa-rk3288"
-COMPATIBLE_MACHINE_tinker-board =3D "tinker-board"
-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"
diff --git a/recipes-kernel/linux/linux-yocto-tiny_%.bbappend b/recipes-k=
ernel/linux/linux-yocto-tiny_%.bbappend
deleted file mode 100644
index 7702e3f..0000000
--- a/recipes-kernel/linux/linux-yocto-tiny_%.bbappend
+++ /dev/null
@@ -1,10 +0,0 @@
-COMPATIBLE_MACHINE_marsboard-rk3066 =3D "marsboard-rk3066"
-COMPATIBLE_MACHINE_rock2-square =3D "rock2-square"
-COMPATIBLE_MACHINE_radxarock =3D "radxarock"
-COMPATIBLE_MACHINE_firefly-rk3288 =3D "firefly-rk3288"
-COMPATIBLE_MACHINE_vyasa-rk3288 =3D "vyasa-rk3288"
-COMPATIBLE_MACHINE_tinker-board =3D "tinker-board"
-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"
diff --git a/recipes-kernel/linux/linux-yocto_%.bbappend b/recipes-kernel=
/linux/linux-yocto_%.bbappend
deleted file mode 100644
index 7702e3f..0000000
--- a/recipes-kernel/linux/linux-yocto_%.bbappend
+++ /dev/null
@@ -1,10 +0,0 @@
-COMPATIBLE_MACHINE_marsboard-rk3066 =3D "marsboard-rk3066"
-COMPATIBLE_MACHINE_rock2-square =3D "rock2-square"
-COMPATIBLE_MACHINE_radxarock =3D "radxarock"
-COMPATIBLE_MACHINE_firefly-rk3288 =3D "firefly-rk3288"
-COMPATIBLE_MACHINE_vyasa-rk3288 =3D "vyasa-rk3288"
-COMPATIBLE_MACHINE_tinker-board =3D "tinker-board"
-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"
--=20
2.30.2


[meta-rockchip][PATCH v2 2/4] rockchip-defaults: don't force KCONFIG_MODE to alldefconfig

Yann Dirson
 

From: Yann Dirson <yann@blade-group.com>

When using in-kernel defconfig this is already the default, but
linux-yocto defaults to "allnoconfig" mode when a defconfig is
specified in SRC_URI, and there is no reason to override this
globally.
---
conf/machine/include/rockchip-defaults.inc | 1 -
1 file changed, 1 deletion(-)

diff --git a/conf/machine/include/rockchip-defaults.inc b/conf/machine/in=
clude/rockchip-defaults.inc
index a4e2a2c..17d1d0b 100644
--- a/conf/machine/include/rockchip-defaults.inc
+++ b/conf/machine/include/rockchip-defaults.inc
@@ -2,7 +2,6 @@
=20
# kernel
PREFERRED_PROVIDER_virtual/kernel ?=3D "linux-yocto"
-KCONFIG_MODE ?=3D "alldefconfig"
LINUX_VERSION_EXTENSION ?=3D "-rockchip"
=20
# xserver
--=20
2.30.2


BeagleBone Black wig image does not boot

Konstantin Kletschke
 

Hi all,

I successfully compile/create a target image and binaries for a BeagleBone Black:

MACHINE ?= "beaglebone-yocto"

The resulting wic image does not boot, when I write it to a sdcard nor when I write it directly into the internal /dev/mmcblk0. There is no console output despite of some capital "C" sometimes (the internal boot loader-loader failing to find u-boot?).
The image looks rather healthy, though:

fdisk p output:

Disk core-image-base-beaglebone-yocto-20210331083925.rootfs.wic: 1 GiB, 1098599424 bytes, 2145702 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xa63a46ea

Device Boot Start End Sectors Size Id Type
core-image-base-beaglebone-yocto-20210331083925.rootfs.wic1 * 8 49065 49058 24M c W95 FAT32 (LBA)
core-image-base-beaglebone-yocto-20210331083925.rootfs.wic2 49072 2145701 2096630 1023.8M 83 Linux

ls -la of the mounted first boot partition:

insidem2m@konsti ~/Y $ ls -la /mnt
total 8648
drwxr-xr-x 3 root root 16384 Jan 1 1970 .
drwxr-xr-x 17 root root 4096 Mar 4 12:06 ..
-rwxr-xr-x 1 root root 107940 Apr 6 2011 MLO
-rwxr-xr-x 1 root root 59303 Apr 6 2011 am335x-bone.dtb
-rwxr-xr-x 1 root root 62629 Apr 6 2011 am335x-boneblack.dtb
-rwxr-xr-x 1 root root 59567 Apr 6 2011 am335x-bonegreen.dtb
drwxr-xr-x 2 root root 2048 Apr 6 2011 extlinux
-rwxr-xr-x 1 root root 892736 Apr 6 2011 u-boot.img
-rwxr-xr-x 1 root root 7645608 Apr 6 2011 zImage



The strange thing is, when I prepare a sdcard (or the internal flash!) with partitions manually, format manually and copy the same kernel and u-boot binaries into the first and the rootfs into the second partition, the system works fine!


Since the complete Image layout looks fine to me, what could be the culprit of that?

Kind Regards
Konsti


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

Sangeeta Jain
 

Hello All,

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

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

No new issues found


Thanks,
Sangeeta

-----Original Message-----
From: qa-build-notification@lists.yoctoproject.org <qa-build-
notification@lists.yoctoproject.org> On Behalf Of Pokybuild User
Sent: Monday, 29 March, 2021 11:49 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.2.3.rc1)


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


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


Build hash information:

bitbake: 5d02c98489d3a5836676b9c3fb3bd0157449db2b
meta-arm: e219ef606e297b98512887c96522d8d8c536bd6b
meta-gplv2: 6e8e969590a22a729db1ff342de57f2fd5d02d43
meta-intel: 76e0a427e58d068d0758fa052d2d1548067cf592
meta-kernel: 29329d7cacc71595cecfdd05a455a0cfb164564d
meta-mingw: 352d8b0aa3c7bbd5060a4cc2ebe7c0e964de4879
oecore: fdae970656cc421c542af9856bc9ae038c61db13
poky: 08665a81dcd41069eed1468f1587abe6b5893471



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







SYSVINIT_ENABLED_GETTYS dynamic setup

Mauro Ziliani
 

Hi all.

I make two images  image1  image1-installer
In image1 I don't need any getty so i'd like to put SYSVINIT_ENALED_GETTYS := ""

image1.bb give the output image1.sdcard
SYSVINIT_ENABLED_GETTYS := "2"
IMAGE_INSTALL_append = "sysvinit-inittab "

This is /etc/inittab i'd like inside image1.sdcard

2:2345:respawn:/sbin/getty 38400 tty2



In image1-installer I need only getty1 so i'd like to setup SYSVINIT_ENABLED GETTYS := "1"

image1-installer.bb give the output image1-installer.sdcard
SYSVINIT_ENABLED_GETTYS := "1"
IMAGE_INSTALL_append = " sysvinit-inittab "

The  /etc/inittab in image1-installer.sdcard contains

1:2345:respawn:/sbin/getty 38400 tty1


There is a way to "configure" sysvinit-inittab_%.bb to make a different output using a PACKAGECONFIG o others variables?

By now I have setup SYSVINIT_ENABLED_GETTYS := "" and than add  2:2345:respawn:/sbin/getty 38400 tty2 or 1:2345:respawn:/sbin/getty 38400 tty1 in the recipe


There is another way?


MZ







Sent from Mailspring, the best free email app for work


what is the state of upcoming(?) NXP S32G2xx support; layer, BSP?

Robert P. J. Day
 

i note that the linux-yocto repo has a nxp-s32g2xx branch:


https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/commit/?h=v5.10/standard/nxp-sdk-5.4/nxp-s32g2xx

so wondering about the subsequent BSP layer, from NXP or
elsewhere. thoughts?

rday


Re: Yocto Technical Team Minutes, Engineering Sync, for Mar 30, 2021

Nicolas Dechesne
 

On Wed, Mar 31, 2021 at 4:25 PM Trevor Woerner <twoerner@gmail.com> wrote:

Yocto Technical Team Minutes, Engineering Sync, for March 30, 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, Armin Kuster, Richard Purdie, Randy
MacLeod, Jan-Simon Möller, Trevor Gamblin, Tim Orling, Michael Halstead,
Paul Barker, Jon Mason, Joshua Watt, Steven Sakoman, Saul Wold, Scott
Murray, Khem Raj, Peter Kjellerstedt (saur), Ross Burton, Michael
Opdenacker

== notes ==
- 3.2-m3 released
- -m4 being built this week, no more update patches

== general ==
Randy: got info collection thingy working on AB thanks to help from SS and
integrated into results
RP: have you had a chance to look at my theory
Randy: not yet
RP: io-nice doesn’t change async write (I think AlexK pointed this out). we
do nice levels for all processes and io-nice for things that write, it’s
possible that this is where we’re hitting the io block. we might want to
try doing some builds under qemu (then we can enforce more nice levels) as
a means of investigating this issue


RP: the valgrind stuff seems to be testing well in master-next, but i will
defer those to -m4
RP: the -m4 build date is, technically, monday, anything else to include?
Randy: lttng modules?


Khem: i have gcc-11 patches, probably not for -m4, but if the AB has cycles
can i send them up?
RP: on the one hand i’d prefer to not do multiple things at the same time,
on the other hand i can’t stop people from sending new features
Khem: i can hold off a bit. i could send an RFC. yocto project has already
submitted gcc-11 patches and i’m looking to expand the testing on it
RP: any issues for -native recipes?
Khem: i’ve found a bunch already and upstreamed them, any that weren’t
accepted in the upstream project have been put into oe-core


Peter: what about the covered/not-covered (on runqueue) issue
RP: i have drafted a patch and is in master-next. it doesn’t appear to break
anything, but proving it fixes things is hard. have you seen the problem
after adding that patch?
Peter: no
SS: i had seen it on 3 builds, and haven’t seen them again either
RP: trying to reproduce an exact same build (wrt sstate, runqueues, etc) is
hard, so it’s hard to know if we’ve solved it


Khem: in the past we’ve seen issues with bitbake running forever due to
“make -l” issue. so we removed it. but we still see long builds with
qemarm
Randy: how much longer?
Khem: (guessing) 30%
Randy: qemuarm64 too?
Khem: no, just qemuarm. same number of CPUs, same underlying machine
Jon: qemuarmv5 as well?
Khem: no
Jon: maybe it’s a qemuarm hardfloat issue. i’ll try to reproduce it
Khem: i’m building lots of stuff, not just the basics. mostly doing world
builds, so maybe it’s a particular package
<various>: we can give it a try
RP: maybe by dropping the -l you’ve introduced something else (e.g. swapping)
Khem: but no other qemu’s are affected. most builds finish in 10 hours,
but qemuarm gets killed after 13 hours (due to a timeout) which is why i
notice it (because it gets killed)
RP: it would be interesting to look at the build stats data then compare build
times recipe-to-recipe
Randy: is there a bug filed?
Khem: not yet, i can file a tracking bug


TimO: Ross asked me about splitting meta-python out to standalone layer (from
meta-openembedded). would allow us to use dynamic layers. might help with
ptest coverage. it might might other workflows possible (i.e. move it
to gitlab and use their things). some have offered strong opinions that
it’s just splitting for splitting sake
RP: i think splitting out would be good. there’s lots of burnout and it
would be great to spread the load a bit more (instead of making one person
responsible for all meta-oe)
TrevorG: having to share the support with the rest of meta-oe is hard
TimO: Khem had asked us to move to a PR mechanism
JPEW: this subset feels like the best one to be pulled out (as a test)
TimO: true, meta-perl might be a good candidate too. in any case i would start
with dunfell, but nothing before that
I think this is a really good discussion, but I wonder why you want to
go back in time.. I expect users of dunfell branch (which is an LTS
from YP perspectives) would be rather unhappy to see such a major
change in their stable builds. I think it's a change for master only,
so either now before the next release or a change for the Oct release,
no?

Khem: have you considered this from the users point of view. obviously we’re
thinking more of the maintenance point of view but let’s not forget to
seek user input
TimO: obviously it’s going to impact users, they’ll need to change URIs
and bblayers
PaulB: just make sure the layer index gets updated and we could leave a stub
behind that points the user to the change
RP: (same)
Khem: i also think it would help if these layers have separate mailing list.
it’s hard for users to know where to send patches (especially poky). so
instead of using mete-oe as a kitchen sink
TimO: i’ve always wished for a separate mailing list. i’ve had to do lots
of filtering but it doesn’t catch everything
Khem: good to bring to TSC and community to get input
TimO: it’s fairly quick to split this out. mechanics aren’t a problem
Armin: looking at layers that depend on meta-python, do you think they would
change to dynamic layers? meta-networking and meta-multimedia depend on
meta-python, so splitting it out would require pulling it in for many
use-cases
RP: i wouldn't get too worried about the details, everything could be
solved, let’s not worry about all possibilities, when only some might
come to pass. i think more layers is good, maybe it opens up the ability
to use the AB for some of this stuff (as stuff gets smaller)
Randy: so the reasons for are:
1. burden on maintainers
2. quality and test coverage
?
TimO: also simplification (if you want some python you don’t need all of
meta-oe)
RP: i see dependency creep in external layers (since you have to pull in
meta-oe for meta-python then we might as well pull in all these other
things too that we’re already getting in meta-oe)
Randy: do we want to see everything in meta-oe split up, or other splits in
oe-core?
RP: case by case, there’s pros and cons
Randy: what about incremental transition vs a full change-over
TimO: i want to make sure all the ptests are in place first, and there’s the
question of review
Khem: why can’t we add ptests now? (i.e. in meta-oe)
TimO: i’d *like* to add more ptests, but doesn’t mean we will/should
Khem: propose it and see what the feedback is. people are making products with
this and we should make sure to move forward in a way the impacts them in
a way they’re happy with
TimO: 10 people will provide 20 opinions
RP: we can do a POC and move forward
TimO: we’ve talked about it so much over the years and we never agree on
trying a change, maybe people can’t see the benefit until they actually
try it
Randy: could this live on git.yoctoproject.org
TimO: maybe git.openembedded.org instead
Randy: would you track bugs on YP bugzilla
RP: where to host is irrelevant, but there are larger issues (such as better
AB usage, maintainer question, burnout, mailing lists)
Khem: lots of people listed as maintainers of individual packages, but little
actual maintainer help. how many maintainers actually review and help?
RP: the same problem exists in oe-core. there are some that are active, but in
the end it’s usually AlexK that does the upgrades
TimO: it could be an issue of timing, sometime you don’t get to it in a
day and someone else does it. with unlimited resources we would use yp
bugzilla, but there are consequences to the members
Randy: do you want more layers removed too?
Khem: yes, that would be great. i’m not maintainer by choice, then i could
sign up to maintain what matters to me
TrevorG: if we do it now with meta-python, then it lets us know if we should
go ahead and do it with others too
RP: yes, good experiment and we can roll it back. meta-python looks like it
would be a good test
TimO: i have tools that make it easy to do, and then easy to roll back. and
the tools are not just meta-python-specific, they could be used for any
sub-layer


TrevorW: there is a Yocto Project related virtual conference being planned:
https://www.yoctoproject.org/yocto-project-virtual-summit-2021/
TrevorW: the CfP is now open:
https://pretalx.com/yocto-project-summit-2021/cfp



Speed up the build

Mauro Ziliani
 

Hi all

I need to speedup the build.
I use package_deb as package method.

I see that the bottlenek is gzip
When yocto runs gzip the cpu runs to 100%, with xz 600% (the pc has 6 core (12threads))

I'd like to use pigz to parallelize "gzip" too.

Is it possible?

MZ
Sent from Mailspring


Yocto Technical Team Minutes, Engineering Sync, for Mar 30, 2021

Trevor Woerner
 

Yocto Technical Team Minutes, Engineering Sync, for March 30, 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, Armin Kuster, Richard Purdie, Randy
MacLeod, Jan-Simon Möller, Trevor Gamblin, Tim Orling, Michael Halstead,
Paul Barker, Jon Mason, Joshua Watt, Steven Sakoman, Saul Wold, Scott
Murray, Khem Raj, Peter Kjellerstedt (saur), Ross Burton, Michael
Opdenacker

== notes ==
- 3.2-m3 released
- -m4 being built this week, no more update patches

== general ==
Randy: got info collection thingy working on AB thanks to help from SS and
integrated into results
RP: have you had a chance to look at my theory
Randy: not yet
RP: io-nice doesn’t change async write (I think AlexK pointed this out). we
do nice levels for all processes and io-nice for things that write, it’s
possible that this is where we’re hitting the io block. we might want to
try doing some builds under qemu (then we can enforce more nice levels) as
a means of investigating this issue


RP: the valgrind stuff seems to be testing well in master-next, but i will
defer those to -m4
RP: the -m4 build date is, technically, monday, anything else to include?
Randy: lttng modules?


Khem: i have gcc-11 patches, probably not for -m4, but if the AB has cycles
can i send them up?
RP: on the one hand i’d prefer to not do multiple things at the same time,
on the other hand i can’t stop people from sending new features
Khem: i can hold off a bit. i could send an RFC. yocto project has already
submitted gcc-11 patches and i’m looking to expand the testing on it
RP: any issues for -native recipes?
Khem: i’ve found a bunch already and upstreamed them, any that weren’t
accepted in the upstream project have been put into oe-core


Peter: what about the covered/not-covered (on runqueue) issue
RP: i have drafted a patch and is in master-next. it doesn’t appear to break
anything, but proving it fixes things is hard. have you seen the problem
after adding that patch?
Peter: no
SS: i had seen it on 3 builds, and haven’t seen them again either
RP: trying to reproduce an exact same build (wrt sstate, runqueues, etc) is
hard, so it’s hard to know if we’ve solved it


Khem: in the past we’ve seen issues with bitbake running forever due to
“make -l” issue. so we removed it. but we still see long builds with
qemarm
Randy: how much longer?
Khem: (guessing) 30%
Randy: qemuarm64 too?
Khem: no, just qemuarm. same number of CPUs, same underlying machine
Jon: qemuarmv5 as well?
Khem: no
Jon: maybe it’s a qemuarm hardfloat issue. i’ll try to reproduce it
Khem: i’m building lots of stuff, not just the basics. mostly doing world
builds, so maybe it’s a particular package
<various>: we can give it a try
RP: maybe by dropping the -l you’ve introduced something else (e.g. swapping)
Khem: but no other qemu’s are affected. most builds finish in 10 hours,
but qemuarm gets killed after 13 hours (due to a timeout) which is why i
notice it (because it gets killed)
RP: it would be interesting to look at the build stats data then compare build
times recipe-to-recipe
Randy: is there a bug filed?
Khem: not yet, i can file a tracking bug


TimO: Ross asked me about splitting meta-python out to standalone layer (from
meta-openembedded). would allow us to use dynamic layers. might help with
ptest coverage. it might might other workflows possible (i.e. move it
to gitlab and use their things). some have offered strong opinions that
it’s just splitting for splitting sake
RP: i think splitting out would be good. there’s lots of burnout and it
would be great to spread the load a bit more (instead of making one person
responsible for all meta-oe)
TrevorG: having to share the support with the rest of meta-oe is hard
TimO: Khem had asked us to move to a PR mechanism
JPEW: this subset feels like the best one to be pulled out (as a test)
TimO: true, meta-perl might be a good candidate too. in any case i would start
with dunfell, but nothing before that
Khem: have you considered this from the users point of view. obviously we’re
thinking more of the maintenance point of view but let’s not forget to
seek user input
TimO: obviously it’s going to impact users, they’ll need to change URIs
and bblayers
PaulB: just make sure the layer index gets updated and we could leave a stub
behind that points the user to the change
RP: (same)
Khem: i also think it would help if these layers have separate mailing list.
it’s hard for users to know where to send patches (especially poky). so
instead of using mete-oe as a kitchen sink
TimO: i’ve always wished for a separate mailing list. i’ve had to do lots
of filtering but it doesn’t catch everything
Khem: good to bring to TSC and community to get input
TimO: it’s fairly quick to split this out. mechanics aren’t a problem
Armin: looking at layers that depend on meta-python, do you think they would
change to dynamic layers? meta-networking and meta-multimedia depend on
meta-python, so splitting it out would require pulling it in for many
use-cases
RP: i wouldn't get too worried about the details, everything could be
solved, let’s not worry about all possibilities, when only some might
come to pass. i think more layers is good, maybe it opens up the ability
to use the AB for some of this stuff (as stuff gets smaller)
Randy: so the reasons for are:
1. burden on maintainers
2. quality and test coverage
?
TimO: also simplification (if you want some python you don’t need all of
meta-oe)
RP: i see dependency creep in external layers (since you have to pull in
meta-oe for meta-python then we might as well pull in all these other
things too that we’re already getting in meta-oe)
Randy: do we want to see everything in meta-oe split up, or other splits in
oe-core?
RP: case by case, there’s pros and cons
Randy: what about incremental transition vs a full change-over
TimO: i want to make sure all the ptests are in place first, and there’s the
question of review
Khem: why can’t we add ptests now? (i.e. in meta-oe)
TimO: i’d *like* to add more ptests, but doesn’t mean we will/should
Khem: propose it and see what the feedback is. people are making products with
this and we should make sure to move forward in a way the impacts them in
a way they’re happy with
TimO: 10 people will provide 20 opinions
RP: we can do a POC and move forward
TimO: we’ve talked about it so much over the years and we never agree on
trying a change, maybe people can’t see the benefit until they actually
try it
Randy: could this live on git.yoctoproject.org
TimO: maybe git.openembedded.org instead
Randy: would you track bugs on YP bugzilla
RP: where to host is irrelevant, but there are larger issues (such as better
AB usage, maintainer question, burnout, mailing lists)
Khem: lots of people listed as maintainers of individual packages, but little
actual maintainer help. how many maintainers actually review and help?
RP: the same problem exists in oe-core. there are some that are active, but in
the end it’s usually AlexK that does the upgrades
TimO: it could be an issue of timing, sometime you don’t get to it in a
day and someone else does it. with unlimited resources we would use yp
bugzilla, but there are consequences to the members
Randy: do you want more layers removed too?
Khem: yes, that would be great. i’m not maintainer by choice, then i could
sign up to maintain what matters to me
TrevorG: if we do it now with meta-python, then it lets us know if we should
go ahead and do it with others too
RP: yes, good experiment and we can roll it back. meta-python looks like it
would be a good test
TimO: i have tools that make it easy to do, and then easy to roll back. and
the tools are not just meta-python-specific, they could be used for any
sub-layer


TrevorW: there is a Yocto Project related virtual conference being planned:
https://www.yoctoproject.org/yocto-project-virtual-summit-2021/
TrevorW: the CfP is now open:
https://pretalx.com/yocto-project-summit-2021/cfp


Re: How can I use old Package version with latest Yocto version. #cups #zeus

rohit jadhav
 

Thanks @Khem Raj for your valuable response.

As Zeus is not supported with meta-printing Layer . is it feasible to use Zeus in this Scenario?

And For Opencv Package version to use from Krogoth is with zeus is compilable?


[meta-security][PATCH 4/4] swtpm: file pip3 issue

Armin Kuster
 

need native pip3, was using host's

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
meta-tpm/recipes-tpm/swtpm/swtpm_0.5.2.bb | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/meta-tpm/recipes-tpm/swtpm/swtpm_0.5.2.bb b/meta-tpm/recipes-tpm/swtpm/swtpm_0.5.2.bb
index b7ff2ad..c0bd35e 100644
--- a/meta-tpm/recipes-tpm/swtpm/swtpm_0.5.2.bb
+++ b/meta-tpm/recipes-tpm/swtpm/swtpm_0.5.2.bb
@@ -7,7 +7,7 @@ DEPENDS = "libtasn1 coreutils-native expect socat glib-2.0 net-tools-native libt

# configure checks for the tools already during compilation and
# then swtpm_setup needs them at runtime
-DEPENDS += "tpm-tools-native expect-native socat-native"
+DEPENDS += "tpm-tools-native expect-native socat-native python3-pip-native"

SRCREV = "e59c0c1a7b4c8d652dbb280fd6126895a7057464"
SRC_URI = "git://github.com/stefanberger/swtpm.git;branch=stable-0.5 \
@@ -18,7 +18,6 @@ PE = "1"
S = "${WORKDIR}/git"

inherit autotools pkgconfig python3-dir
-PARALLEL_MAKE = ""

TSS_USER="tss"
TSS_GROUP="tss"
--
2.17.1


[meta-security][PATCH 3/4] swtpm: now need python-cryptography, pull in layer

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
meta-tpm/conf/layer.conf | 1 +
1 file changed, 1 insertion(+)

diff --git a/meta-tpm/conf/layer.conf b/meta-tpm/conf/layer.conf
index 65788eb..1b766cb 100644
--- a/meta-tpm/conf/layer.conf
+++ b/meta-tpm/conf/layer.conf
@@ -13,6 +13,7 @@ LAYERSERIES_COMPAT_tpm-layer = "hardknott"
LAYERDEPENDS_tpm-layer = " \
core \
openembedded-layer \
+ meta-python \
"
BBLAYERS_LAYERINDEX_NAME_tpm-layer = "meta-tpm"

--
2.17.1


[meta-security][PATCH 2/4] clamav: fix systemd service install

Armin Kuster
 

ERROR: clamav-0.104.0-r0 do_package: QA Issue: clamav: Files/directories were installed but not shipped in any package:
/lib/systemd/system/clamav-daemon.service
/lib/systemd/system/clamav-clamonacc.service

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
recipes-scanners/clamav/clamav_0.104.0.bb | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/recipes-scanners/clamav/clamav_0.104.0.bb b/recipes-scanners/clamav/clamav_0.104.0.bb
index 9e50466..ba036b0 100644
--- a/recipes-scanners/clamav/clamav_0.104.0.bb
+++ b/recipes-scanners/clamav/clamav_0.104.0.bb
@@ -105,7 +105,10 @@ FILES_${PN}-daemon = "${bindir}/clamconf ${bindir}/clamdtop ${sbindir}/clamd \
/usr/etc/clamd.conf* \
${systemd_unitdir}/system/clamav-daemon/* \
${docdir}/clamav-daemon/* ${sysconfdir}/clamav-daemon \
- ${sysconfdir}/logcheck/ignore.d.server/clamav-daemon "
+ ${sysconfdir}/logcheck/ignore.d.server/clamav-daemon \
+ ${systemd_unitdir}/system/clamav-daemon.service \
+ ${systemd_unitdir}/system/clamav-clamonacc.service \
+ "

FILES_${PN}-freshclam = "${bindir}/freshclam \
${sysconfdir}/freshclam.conf* \
--
2.17.1


[meta-security][PATCH 1/4] python3-privacyidea: upgrade 3.5.1 -> 3.5.2

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
...ython3-privacyidea_3.5.1.bb => python3-privacyidea_3.5.2.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename recipes-security/mfa/{python3-privacyidea_3.5.1.bb => python3-privacyidea_3.5.2.bb} (96%)

diff --git a/recipes-security/mfa/python3-privacyidea_3.5.1.bb b/recipes-security/mfa/python3-privacyidea_3.5.2.bb
similarity index 96%
rename from recipes-security/mfa/python3-privacyidea_3.5.1.bb
rename to recipes-security/mfa/python3-privacyidea_3.5.2.bb
index fb84411..cd0acf8 100644
--- a/recipes-security/mfa/python3-privacyidea_3.5.1.bb
+++ b/recipes-security/mfa/python3-privacyidea_3.5.2.bb
@@ -6,7 +6,7 @@ LICENSE = "AGPL-3.0"
LIC_FILES_CHKSUM = "file://LICENSE;md5=c0acfa7a8a03b718abee9135bc1a1c55"

PYPI_PACKAGE = "privacyIDEA"
-SRC_URI[sha256sum] = "c10f8e9ec681af4cb42fde70864c2b9a4b47e2bcccfc1290f83c1283748772c6"
+SRC_URI[sha256sum] = "26aeb0d353af1f212c4df476202516953c20f7f31566cfe0b67cbb553de04763"

inherit pypi setuptools3

--
2.17.1


Re: How can I use old Package version with latest Yocto version. #cups #zeus

Khem Raj
 

On 3/30/21 12:42 AM, rohitbjadhav1@gmail.com wrote:
Hi
   I was using very old version of Yocto i.e. Krogoth. In that version I am able to use following packages with respective version:
    Package name   Version
   Cups                     2.2.4
   Cups-filter            1.14.0
   qpdf                      6.0.0
   Opencv                 2.4
It was working fine. But When I switch to any other version of Yocto like  Zeus [which I have tried on ].
Specifically for cups-filter pakage observed following errors while compilation and generation of rootfs
ERROR: cups-filters-1.14.0-r0 do_compile: oe_runmake failed
ERROR: cups-filters-1.14.0-r0 do_compile: Execution of '/home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/cortexa7t2hf-neon-poky-linux-gnueabi/cups-filters/1.14.0-r0/temp/run.do_compile.17590' failed with exit code 1:
It is observed due to wrong c standard while compilation as some log says as follow:
warning: ISO C99 doesn't support unnamed structs/unions [-Wpedantic]
warning: ' LPT #' directive output may be truncated writing 6 bytes into a region of size between 1 and 1024 [-Wformat-truncation=]
warning: 'strncpy' specified bound 1024 equals destination size [-Wstringop-truncation]
filter/pdftoopvp/oprs/OPVPSplash.h:53:3: error: 'GBool' does not name a type
it seems you are locking above said packages to revisions you want, but they also have additional dependencies, eg. the one which is causing issue here is poppler, since poppler version in zeus is 0.80.0 and krogoth has 0.41, however poppler switched to using standard types for bool starting 0.71,

my suggestion is to use the versions that come with zeus release and forward port your app to consume them or second option is to fork versions then you must look at what would be the right set of packages you need to lock to older versions in-order for you to keep things going forward.

Just Need some guideline to resolve this issue.
Please also suggest is there any way to use old pakage of Yocto version to latest Yocto version.
Thanks and Regards
Rohit


Re: eula-downloads.yoctoproject.org down???

Michael Halstead
 

After further discussion we've decided to take the site offline again as recommended. This check was removed on Jan 29 2016 and any systems still performing the check need to be updated.


On Tue, Mar 30, 2021 at 8:29 AM Michael Halstead via lists.yoctoproject.org <mhalstead=linuxfoundation.org@...> wrote:
I have restored https://eula-downloads.yoctoproject.org/index.php since these connectivity checks rely on it. The driver binaries are not available any longer so I will alter the site to indicate that.

On Tue, Mar 30, 2021 at 1:02 AM Josef Holzmayr <jester@...> wrote:
Am Di., 30. März 2021 um 05:22 Uhr schrieb anthony.l via
lists.yoctoproject.org <anthony.l=axxin.com@...>:
>
> Getting a message today
> Fetcher failure for URL: 'https://eula-downloads.yoctoproject.org/index.php'. URL https://eula-downloads.yoctoproject.org/index.php doesn't work. Please ensure your network is configured correctly.
>
> Can't ping the url?  Anyone have an ETA on this being back up?  Just trying to get some urgent builds done today.

Please see https://www.yoctoproject.org/pipermail/poky/2016-January/010357.html

If you are experiencing problems, you can override the connectivity
check, and then please revisit your versions and/or third party
layers.

Greetz

>
> Many thanks.
> Anthony
>
>





--
Michael Halstead
Linux Foundation / Yocto Project
Systems Operations Engineer





--
Michael Halstead
Linux Foundation / Yocto Project
Systems Operations Engineer


Re: No significant diff b/w qemux86 and qemuarm poky build of core-image-minimal

Khem Raj
 

On 3/30/21 1:48 PM, Ross Burton wrote:
On Tue, 30 Mar 2021 at 20:41, Khem Raj <raj.khem@gmail.com> wrote:
Thanks for this infor Randy, really appreciated, I think I will also
look at the h/w angle.
Khem: if you can reproduce this on demand with a clean build (ie
oe-init-build-env with a clean build directory, just set DL_DIR) then
enabling buildstats would give some interesting metrics.
buildstats-diff can compare two build runs and tell you what the
differences are.
yeah this is doing world build of not only core but several other layers included a usual build takes around 10 hrs for this machine config, I am planning to

1. Collect build stats
2. buiid another qemu machine on this VM

it could very well be rotting hardware underneath the VM.

Ross

2181 - 2200 of 55143