Date   

Variables qualifying for be placed in conf/local.conf

keydi
 

Hi,
From all variables which qualify to be set/modified in conf/local.conf, among others those documented
in conf/local.conf template, are any to be set /modified only in conf/local.conf?

There is one YP document (maybe Reference Manual, maybe some other) with one chapter
listing variables for conf/local.conf. For me it's however unclear if that list addresses question asked here too.
Me was not lucky to had got answer over there.

Regards
k.d.


Yocto Autobuilder: Latency Monitor and AB-INT -- Minutes from: Apr 29, 2021

Randy MacLeod
 

Attendees: Richard, Randy

To Do:
======

Data Collection: (Sakib)
------------------------

1. run iostat if it exists:
iostat -y -z -x 5 1
-y Omit first report with statistics since system boot, if
displaying multiple records at given interval.
-x Display extended statistics.
-z Tell iostat to omit output for any devices for which there
was no activity during the sample period.
5 1: monitor for 5 seconds, run 1 time.

2. use filenames that show what host, the data came from.
Currently we have:
- testresults/pkgman-deb-non-deb/2021-04-28--02-31/host_stats_0_top.txt
- testresults/beaglebone/2021-04-28--01-08/host_stats_2.txt

3. We add the tail of the cooker log but we need to know which
cooker log this softlink comes from so add that as a header
and to be paranoid as a trailer in case the softlink changes while
the collection is underway.

4. Collect the logs produced on error.

5. If the tail of the cooker logs isn't sufficient,
match the start/complete logs and report all tasks that
are not complete:


General topics
--------------

We talked about the job server for make-based recipes. Trevor is going
to look at that and if it goes well, perhaps also look at doing something similar for ninja (or samarai) builds.


Just as we can do co-operative load/compile management for make/ninja builds, we may have to co-ordinate I/O intensive activities.
RP mentioned that there's some task-based process limiting that
is done in the fetcher code. We suspect that the bottleneck is
around writes to sstate-cache and other write operations but we
need either proof from logging or to make a change and wait days
or weeks to see if the error rate has improved. The first option
is preferred.


Why is qemu start-up still slow?
Saul added code to use the Qemu Machine Protocol (QMP) so that
we can monitor/query Qemu. He had a bug where the process seemed
to have started because it's pid (file?) was available but the socket
for communicating with qemu was not yet bound. Adding a loop and some
short sleeps fixes the bug but it's odd that even with things running
from tmpfs, the start-up is slow.
- is there a logging flag or code for monitoring the start-up that we
can use?
- if not, can/should we patch qemu
- do we need to also copy the kernel that qemu is loading into tmpfs?

- Alex was (is?) going to instrument the initial copy into tmpfs
to record how log that takes from beginning to end and perhaps with
additional detail from the middle-end (compiler joke!).

It would be good if Saul can use QMP to help us understand what
is making qemuppc slow or hang on startup.


--
# Randy MacLeod
# Wind River Linux


Re: Hardknott: grub immediately reboots

Tony Battersby
 

On 4/28/21 11:25 PM, Mittal, Anuj wrote:

-----Original Message-----
From: yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> On Behalf Of
Tony Battersby
Sent: Tuesday, April 27, 2021 03:07 AM
To: yocto@lists.yoctoproject.org
Subject: [yocto] Hardknott: grub immediately reboots

After upgrading from Dunfell (YP 3.1) to Hardknott (YP 3.3), our firmware was
unable to boot.  Our target hardware is x86-64 booting in legacy BIOS mode using
grub on a variety of motherboards and CPUs.  The grub menu would never show up;
instead it would reboot immediately, leading to an endless reboot loop.

I have two different workarounds.  Create a bbappend file for grub, and do one of the
following two things:

1) Add the following line:

CFLAGS_remove = "-O2"
I think we should probably remove this. That's what Fedora also seems to be doing so Os is used.

https://src.fedoraproject.org/rpms/grub2/blob/rawhide/f/grub.macros#_19

and what grub configure expects:

https://git.savannah.gnu.org/cgit/grub.git/tree/configure.ac#n41

Thanks,

Anuj
I have opened a Yocto bug here:

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

Tony


Re: Hardknott: grub immediately reboots

Anuj Mittal
 

-----Original Message-----
From: yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> On Behalf Of
Tony Battersby
Sent: Tuesday, April 27, 2021 03:07 AM
To: yocto@lists.yoctoproject.org
Subject: [yocto] Hardknott: grub immediately reboots

After upgrading from Dunfell (YP 3.1) to Hardknott (YP 3.3), our firmware was
unable to boot.  Our target hardware is x86-64 booting in legacy BIOS mode using
grub on a variety of motherboards and CPUs.  The grub menu would never show up;
instead it would reboot immediately, leading to an endless reboot loop.

I have two different workarounds.  Create a bbappend file for grub, and do one of the
following two things:

1) Add the following line:

CFLAGS_remove = "-O2"
I think we should probably remove this. That's what Fedora also seems to be doing so Os is used.

https://src.fedoraproject.org/rpms/grub2/blob/rawhide/f/grub.macros#_19

and what grub configure expects:

https://git.savannah.gnu.org/cgit/grub.git/tree/configure.ac#n41

Thanks,

Anuj


Re: #yocto opencl #yocto

Anuj Mittal
 

-----Original Message-----
From: yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> On Behalf Of
Khem Raj
Sent: Thursday, April 29, 2021 10:07 AM
To: steven.monsees@baesystems.com; yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto opencl



On 4/28/21 10:30 AM, Monsees, Steven C (US) via lists.yoctoproject.org
wrote:
Can someone tell me is this supported under Yocto in any way?

meta-beignet/recipes-opencl at ross * rossburton/meta-beignet * GitHub
<https://github.com/rossburton/meta-beignet/tree/ross/recipes-opencl>

Any docs, or updates ?

Wanted to know if this would work under Zeus, with meta-clang ?

Looking to build opencl shared library support...
meta-intel has it see
https://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/tree/dynamic-layers/clang-
layer/recipes-opencl/opencl-clang?h=zeus
Yes, please see the compute-runtime recipe that builds NEO driver instead for later platforms. More details on the project site:

https://github.com/intel/compute-runtime/blob/master/opencl/doc/FAQ.md

Thanks,

Anuj


Re: #yocto opencl #yocto

Khem Raj
 

On 4/28/21 10:30 AM, Monsees, Steven C (US) via lists.yoctoproject.org wrote:
Can someone tell me is this supported under Yocto in any way?
meta-beignet/recipes-opencl at ross · rossburton/meta-beignet · GitHub <https://github.com/rossburton/meta-beignet/tree/ross/recipes-opencl>
Any docs, or updates ?
Wanted to know if this would work under Zeus, with meta-clang ?
Looking to build opencl shared library support…
meta-intel has it see
https://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/tree/dynamic-layers/clang-layer/recipes-opencl/opencl-clang?h=zeus

Thanks,
Steve


Re: [meta-security] [dunfell] [PATCH 0/3] Backport several IMA fixes to LTS dunfell

Armin Kuster
 

merged.

thanks

On 4/18/21 11:41 PM, liu.ming50@gmail.com wrote:
From: Ming Liu <ming.liu@toradex.com>

Ming Liu (3):
ima-evm-keys: add file-checksums to IMA_EVM_X509
meta: drop IMA_POLICY from policy recipes
initramfs-framework-ima: introduce IMA_FORCE

.../initrdscripts/initramfs-framework-ima.bb | 5 +++++
.../initrdscripts/initramfs-framework-ima/ima | 9 +++++++--
.../recipes-security/ima-evm-keys/ima-evm-keys_1.0.bb | 1 +
.../ima-policy-appraise-all_1.0.bb | 9 ++-------
.../ima_policy_hashed/ima-policy-hashed_1.0.bb | 9 ++-------
.../ima_policy_simple/ima-policy-simple_1.0.bb | 9 ++-------
6 files changed, 19 insertions(+), 23 deletions(-)


Grub embedded config not useful

jbouchard@...
 

When I am looking at the grub embedded configuration I not fully sure I understand how this patch, https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=c981ebba29001b8684e9805515576c2350a4e22b. In most case the search.file ($cmdpath) will only not find anything since cmdpath will contains something like this, (hd0,gpt1)/EFI/BOOT.

Thanks


#yocto opencl #yocto

Monsees, Steven C (US)
 

 

Can someone tell me is this supported under Yocto in any way?

 

meta-beignet/recipes-opencl at ross · rossburton/meta-beignet · GitHub

 

Any docs, or updates ?

 

Wanted to know if this would work under Zeus, with meta-clang ?

Looking to build opencl shared library support…

 

Thanks,

Steve


Re: [meta-mingw] [PATCH] mingw-w64: Check for __builtin_ia32_rdtsc

Khem Raj
 

ping^1

On Tue, Apr 13, 2021 at 7:01 PM Khem Raj <raj.khem@gmail.com> wrote:

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
...rincs-Check-for-__builtin_ia32_rdtsc.patch | 33 +++++++++++++++++++
.../nativesdk-mingw-w64-runtime_7.0.0.bb | 2 ++
2 files changed, 35 insertions(+)
create mode 100644 recipes-devtools/mingw-w64/files/0001-intrincs-Check-for-__builtin_ia32_rdtsc.patch

diff --git a/recipes-devtools/mingw-w64/files/0001-intrincs-Check-for-__builtin_ia32_rdtsc.patch b/recipes-devtools/mingw-w64/files/0001-intrincs-Check-for-__builtin_ia32_rdtsc.patch
new file mode 100644
index 0000000..ce4ba81
--- /dev/null
+++ b/recipes-devtools/mingw-w64/files/0001-intrincs-Check-for-__builtin_ia32_rdtsc.patch
@@ -0,0 +1,33 @@
+From 346de7591f58015d111f4d4f3b001382c04d5557 Mon Sep 17 00:00:00 2001
+From: Khem Raj <raj.khem@gmail.com>
+Date: Tue, 13 Apr 2021 18:44:25 -0700
+Subject: [PATCH] intrincs: Check for __builtin_ia32_rdtsc
+
+on modern gcc ( >=4.6 ) __rdtsc function is implemented using
+special builtin function called __builtin_ia32_rdtsc, its actually
+a define in gcc, so __has_builtin check fails for __rdtsc even
+though it is defined to imply __builtin_ia32_rdtsc(), therefore
+check for existence of __builtin_ia32_rdtsc as well
+
+Upstream-Status: Pending
+Signed-off-by: Khem Raj <raj.khem@gmail.com>
+---
+ mingw-w64-crt/intrincs/rdtsc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/mingw-w64-crt/intrincs/rdtsc.c b/mingw-w64-crt/intrincs/rdtsc.c
+index bf9c03b..df04711 100644
+--- a/mingw-w64-crt/intrincs/rdtsc.c
++++ b/mingw-w64-crt/intrincs/rdtsc.c
+@@ -11,7 +11,7 @@
+ #define __has_builtin(x) 0
+ #endif
+
+-#if !__has_builtin(__rdtsc)
++#if !__has_builtin(__rdtsc) && !__has_builtin(__builtin_ia32_rdtsc)
+ unsigned __int64 __rdtsc(void)
+ {
+ #ifdef _WIN64
+--
+2.31.1
+
diff --git a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-runtime_7.0.0.bb b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-runtime_7.0.0.bb
index 9f79ffe..0368841 100644
--- a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-runtime_7.0.0.bb
+++ b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-runtime_7.0.0.bb
@@ -2,6 +2,8 @@ DESCRIPTION = "Runtime libraries from MinGW-w64 project"

require mingw-w64.inc

+SRC_URI += "file://0001-intrincs-Check-for-__builtin_ia32_rdtsc.patch;striplevel=2"
+
S = "${WORKDIR}/mingw-w64-v${PV}/mingw-w64-crt"
B = "${WORKDIR}/build-${TARGET_SYS}"

--
2.31.1


[PATCH yocto-autobuilder2 2/2] meta-arm doesn't use meta-kernel anymore

Ross Burton
 

Signed-off-by: Ross Burton <ross.burton@arm.com>
---
config.py | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/config.py b/config.py
index a723e3f..520de47 100644
--- a/config.py
+++ b/config.py
@@ -10,14 +10,14 @@ buildertorepos =3D {
"a-quick": ["poky", "meta-intel", "oecore", "bitbake",
"meta-mingw", "meta-gplv2"],
"a-full": ["poky", "meta-intel", "oecore", "bitbake",
- "meta-mingw", "meta-gplv2", "meta-arm", "meta-kernel"],
+ "meta-mingw", "meta-gplv2", "meta-arm"],
"non-gpl3": ["poky", "meta-gplv2"],
"meta-mingw": ["poky", "meta-mingw"],
"qa-extras": ["poky", "meta-mingw"],
"meta-oe": ["poky", "meta-openembedded"],
"meta-virt": ["poky", "meta-openembedded", "meta-virtualization"],
"meta-intel": ["poky", "meta-intel"],
- "meta-arm": ["poky", "meta-arm", "meta-kernel"],
+ "meta-arm": ["poky", "meta-arm"],
"meta-agl-core": ["poky", "meta-agl"],
"meta-aws": ["poky", "meta-aws", "meta-openembedded"],
"qemuarm-oecore": ["oecore", "bitbake"],
@@ -54,7 +54,6 @@ repos =3D {
"meta-gplv2": ["git://git.yoctoproject.org/meta-gplv2", "master"],
"meta-openembedded": ["git://git.openembedded.org/meta-openembedded"=
, "master"],
"meta-virtualization": ["git://git.yoctoproject.org/meta-virtualizat=
ion", "master"],
- "meta-kernel": ["https://gitlab.com/openembedded/community/meta-kern=
el.git", "master"],
"yocto-docs": ["git://git.yoctoproject.org/yocto-docs", "master"]
}
=20
--=20
2.25.1


[PATCH yocto-autobuilder2 1/2] meta-arm has a hardknott branch now

Ross Burton
 

Signed-off-by: Ross Burton <ross.burton@arm.com>
---
schedulers.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/schedulers.py b/schedulers.py
index 8b166e0..93b8f34 100644
--- a/schedulers.py
+++ b/schedulers.py
@@ -206,7 +206,7 @@ def parent_scheduler(target):
'branch': 'hardknott',
'branch_poky': 'hardknott',
'branch_bitbake': '1.50',
- 'branch_meta-arm': 'master',
+ 'branch_meta-arm': 'hardknott',
'branch_meta-gplv2': 'hardknott',
'branch_meta-intel': 'hardknott',
'branch_meta-mingw': 'hardknott',
--=20
2.25.1


Re: Bitbake build failures?

Ross Burton
 

Because your networking is broken in some way and you cannot fetch
from downloads.yoctoproject.org.

Outside of bitbake, try:

wget http://downloads.yoctoproject.org/releases/uninative/3.0/x86_64-nativesdk-libc.tar.xz

Ross

On Tue, 27 Apr 2021 at 23:01, jchludzinski via lists.yoctoproject.org
<jchludzinski=vivaldi.net@lists.yoctoproject.org> wrote:

When I trying using bitbake to build openembedded Linux kernel, it dies with these download failures:

NOTE: Fetching uninative binary shim http://downloads.yoctoproject.org/releases/uninative/3.0/x86_64-nativesdk-libc.tar.xz;sha256sum=5ec5a9276046e7eceeac749a18b175667384e1f445cd4526300a41404d985a5b (will check PREMIRRORS first)
WARNING: Failed to fetch URL http://downloads.yoctoproject.org/releases/uninative/3.0/x86_64-nativesdk-libc.tar.xz;sha256sum=5ec5a9276046e7eceeac749a18b175667384e1f445cd4526300a41404d985a5b, attempting MIRRORS if available
ERROR: Fetcher failure: Fetch command export PSEUDO_DISABLED=1; export DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus"; export SSH_AUTH_SOCK="/run/user/1000/keyring/ssh"; export PATH="/home/jski/poky/scripts:/home/jski/poky/build/tmp/work/core2-64-poky-linux/defaultpkgname/1.0-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux:/home/jski/poky/build/tmp/work/core2-64-poky-linux/defaultpkgname/1.0-r0/recipe-sysroot/usr/bin/crossscripts:/home/jski/poky/build/tmp/work/core2-64-poky-linux/defaultpkgname/1.0-r0/recipe-sysroot-native/usr/sbin:/home/jski/poky/build/tmp/work/core2-64-poky-linux/defaultpkgname/1.0-r0/recipe-sysroot-native/usr/bin:/home/jski/poky/build/tmp/work/core2-64-poky-linux/defaultpkgname/1.0-r0/recipe-sysroot-native/sbin:/home/jski/poky/build/tmp/work/core2-64-poky-linux/defaultpkgname/1.0-r0/recipe-sysroot-native/bin:/home/jski/poky/bitbake/bin:/home/jski/poky/build/tmp/hosttools"; export HOME="/home/jski"; /usr/bin/env wget -t 2 -T 30 --passive-ftp --no-check-certificate -P /home/jski/poky/build/downloads/uninative/5ec5a9276046e7eceeac749a18b175667384e1f445cd4526300a41404d985a5b 'http://downloads.yoctoproject.org/releases/uninative/3.0/x86_64-nativesdk-libc.tar.xz' --progress=dot -v failed with exit code 4, output:
--2021-04-27 01:49:09-- http://downloads.yoctoproject.org/releases/uninative/3.0/x86_64-nativesdk-libc.tar.xz
Resolving downloads.yoctoproject.org (downloads.yoctoproject.org)... failed: Connection timed out.
wget: unable to resolve host address ‘downloads.yoctoproject.org’

WARNING: Disabling uninative as unable to fetch uninative tarball: Fetcher failure for URL: 'http://downloads.yoctoproject.org/releases/uninative/3.0/x86_64-nativesdk-libc.tar.xz;sha256sum=5ec5a9276046e7eceeac749a18b175667384e1f445cd4526300a41404d985a5b'. Unable to fetch URL from any source.
WARNING: To build your own uninative loader, please bitbake uninative-tarball and set UNINATIVE_TARBALL appropriately.

Why do I ALWAYS get these download failures?




Re: AppArmor with BusyBox

Quentin Schulz
 

Hi Khem,

On Tue, Apr 27, 2021 at 08:33:08PM -0700, Khem Raj wrote:
On Tue, Apr 27, 2021 at 3:34 PM Konstantin Aladyshev <aladyshev22@gmail.com>
wrote:

I've added `IMAGE_INSTALL += "findutils"` to my `conf/local.conf`
file, and it seems like it was enough. There weren't any build
conflicts.

Should the AppArmor recipe be upgraded in some way to indicate that it
needs a full-featured findutils package instead of a busybox one?

I think it will be useful to dig a bit further and find out what option
does it need from findutils package sometimes this could be solved by using
compatible options etc
Not sure to really understand the question, but the -d option of xargs
is for specifying a delimiter different than the default space.

There is no support for such a thing in Busybox implementation of
xargs. Usually options for tools in Busybox are specified at the
beginning of the C file:
https://git.busybox.net/busybox/tree/findutils/xargs.c
Line 17 to 71.

If one looks for delimiter keyword in the file, nothing configurable is
available, it's either space or EOF that is matched.

I'm naive enough to think it might be not too hard to add this option to\
Busybox implementation.

Cheers,
Quentin


Re: AppArmor with BusyBox

Armin Kuster
 

On 4/27/21 8:33 PM, Khem Raj wrote:


On Tue, Apr 27, 2021 at 3:34 PM Konstantin Aladyshev
<aladyshev22@gmail.com <mailto:aladyshev22@gmail.com>> wrote:

I've added `IMAGE_INSTALL += "findutils"` to my `conf/local.conf`
file, and it seems like it was enough. There weren't any build
conflicts.

Should the AppArmor recipe be upgraded in some way to indicate that it
needs a full-featured findutils package instead of a busybox one?


I think it will be useful to dig a bit further and find out what
option does it need from findutils package sometimes this could be
solved by using compatible options etc 

If we find out that it has hard dependency on findutils then it should
be added to apparmor recipe RDEPENDS
You are using systemd.

There is a comment regarding coreutils and findutils

|# Add coreutils and findutils only if sysvinit scripts are in use

Patches welcome.

- Armin


|



Best regards,
Konstantin Aladyshev

On Mon, Apr 26, 2021 at 5:08 PM Quentin Schulz
<quentin.schulz@streamunlimited.com
<mailto:quentin.schulz@streamunlimited.com>> wrote:
>
> Hi Konstantin,
>
> On Mon, Apr 26, 2021 at 01:45:30PM +0300, Konstantin Aladyshev
wrote:
> > I'm using the OpenBMC system
(https://github.com/openbmc/openbmc) and
> > I've tried to enable AppArmor functionality from the
'meta-security'
> > layer.
> >
> > To achieve this I've added these strings to my local.conf file:
> > DISTRO_FEATURES_append = " apparmor"
> > IMAGE_INSTALL += "apparmor"
> >
> > The AppArmor functionality was installed to my image, but
> > unfortunately I've come to this issue:
> >
> > kernel: AppArmor: AppArmor initialized
> > kernel: AppArmor: AppArmor Filesystem Enabled
> > kernel: AppArmor: AppArmor sha1 policy hashing enabled
> > systemd[1]: systemd 247.3+ running in system mode. (+PAM -AUDIT
> > -SELINUX -IMA -APPARMOR -SMACK +SYSVINIT -UTMP -LIBCRYPTSETUP
-GCRYPT
> > -GNUTLS -ACL +XZ -LZ4 -ZSTD -SECCOMP +BLKID -ELFUTILS +KMOD
-IDN2 -IDN
> > -PCRE2 default-hierarchy=hybrid)
> > systemd[1]: Starting AppArmor initialization...
> > apparmor[113]: Starting AppArmor profiles
> > apparmor[128]: xargs: invalid option -- 'd'
>
> Busybox implementation of xargs does not support specifying a
delimiter.
>
> I suggest you to install the full-featured xargs which is
provided by
> the findutils recipe.
>
> You probably need to disable xargs Busybox implementation otherwise
> there'll be a conflict (you'll know, Yocto won't create the image).
>
> Cheers,
> Quentin






Re: [OE-core] [PATCH 6/7] default-distrovars.inc: add wayland/opengl to default distro features

Kevin Hao
 

On Tue, Apr 27, 2021 at 12:09:51PM -0400, Randy MacLeod wrote:
Cross-posting to yocto since this is of general interest.

On 2021-04-23 2:02 p.m., Alexander Kanavin wrote:
This puts them on equal terms with x11 distro feature
(which I think is due).

Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
---
meta/conf/distro/include/default-distrovars.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/distro/include/default-distrovars.inc b/meta/conf/distro/include/default-distrovars.inc
index 9fcc10f83a..384ee7fc98 100644
--- a/meta/conf/distro/include/default-distrovars.inc
+++ b/meta/conf/distro/include/default-distrovars.inc
@@ -10,7 +10,7 @@ LOCALE_UTF8_ONLY ?= "0"
LOCALE_UTF8_IS_DEFAULT ?= "1"
LOCALE_UTF8_IS_DEFAULT_class-nativesdk = "0"
-DISTRO_FEATURES_DEFAULT ?= "acl alsa argp bluetooth debuginfod ext2 ipv4 ipv6 largefile pcmcia usbgadget usbhost wifi xattr nfs zeroconf pci 3g nfc x11 vfat"
+DISTRO_FEATURES_DEFAULT ?= "acl alsa argp bluetooth debuginfod ext2 ipv4 ipv6 largefile pcmcia usbgadget usbhost wifi xattr nfs zeroconf pci 3g nfc x11 vfat wayland opengl"
DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT}"
IMAGE_FEATURES ?= ""
We (Wind River) already drop the x11 DF from some of our distros and
we'd likely do the same for wayland and opengl so while this seems
like the wrong change for headless systems it is one we could deal with.

There was some discussion about this topic on the tech call today and
people were concerned about BSP support for opengl since the software
rendering in mesa is horridly slow.

Kevin, Bryan,
Can you comment if you think we'd have any show-stopper problems
with opengl support for BSPs?
Thanks for the notice. Hmm, it seems that we have done little validation
for the weston image on the Yocto BSPs, I got a boot failure with the
weston image on my beaglebone black board. I will try to figure out what is
wrong there. But I don't think it should block the change in this patch.

Thanks,
Kevin


Joshua said that weston has a usable RDP (remote desktop backend) but
I'm not sure how usable it is especially for single application sharing.
This contrasts with x11 where you can use X11 forwarding over
ssh trivially for whole desktops or an application.

In conclusion, I see the value in pushing yocto forward but we may need
to wait for agreement from BSP folks so let's see what they say.

../Randy






--
# Randy MacLeod
# Wind River Linux


Yocto Technical Team Minutes, Engineering Sync, for April 27, 2021

Trevor Woerner
 

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

== announcements ==
The upcoming Yocto Project Summit is taking place May 25-26 2021
details: https://www.yoctoproject.org/yocto-project-virtual-summit-2021/
registration: https://www.cvent.com/d/yjq4dr/4W?ct=868bfddd-ca91-46bb-aaa5-62d2b61b2501

== 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 Jolly, Trevor Gamblin, Jan-Simon Möller, Steve
Sakoman, Joshua Watt, Richard Purdie, Bruce Ashfield, Jere Kiikari, Scott
Murray, Randy MacLeod, Armin Kuster, Saul Wold, Michael Opdenacker, Michael
Halstead, Alejandro H, Jon Mason, Tim Orling

== notes ==
- 3.1.7 released last week
- patches flowing into master 3.4-m1
- added checking for key layers on AB (i.e. member layers)
- libseccomp moved to oe-core
- add opengl to default DISTRO_FEATURES proposal
- 2 OE positions available on TSC

== general ==
TW: OEHH is tomorrow


RP: adding more layers and layer checks for heavily-used layers (e.g.
meta-virtualization). we’re currently testing 8 layers, last week only 2
passed, now (i believe) they’re all passing the various checks
TW: what tests?
RP: yocto check-layer test, e.g. is there a README file, e.g. pass through the
metadata without the layer, add the layer, repass through the metadata and
verify that sstate checksums don’t change
TW: any building?
RP: no, just parsing. also does sub-layer testing too (e.g.
meta-openembedded). led to finding a bug in the script


RP: adding libseccomp in core unblocks meta-virtualization


RP: AlexK is pushing hard to drop x11. not seeing any objections on the
mailing list (hard to believe)
Randy: are we covered if we switch?
RP: i don’t think that’s entirely possible
ScottM: software rendering is painfully slow (e.g. testing)
Randy: okay, performance is slow, but full support?
JPEW: isn’t this change just changing package building options?
ScottM: mostly. i think it should be okay, what if someone enables both
wayland and x11?
RP: i’m concerned that there are BSP layers that don’t support opengl,
this makes it a requirement for all BSP layers
TW: i believe there a case in meta-raspberrypi if the user chooses VC graphics
Armin: what do you mean “dropping x11”? removing x11 entirely?
RP: if AlexK gets his way
Armin: can we move it to meta-oe?
RP: i don’t think removing it is on the table?
Randy: so removing x11 server and replacing it with wayland-x11 server
ScottM: it’ll have to happen sooner or later. many desktop distros are
moving to wayland and away from x11
TimO: so a good drop before the next LTS?
ScottM: that’s what i was thinking, maybe a tsc decision
RP: opengl is a requirement for wayland?
JPEW: not a hard requirement, but in practice…
RP: uncomfortable about making opengl a default
RP: uncomfortable with making this a DISTRO_FEATURE when maybe “graphics”
is a BSP question
TW: what about headless builds?
J-SM: shouldn’t a headless build not need graphics things?
TW: there’s probably some package that builds differently with opengl on or
off but would be pulled into a headless build
JPEW: opengl DISTRO_FEATURE is not the right thing to check for this
RP: dbus builds differently depending on x11
ScottM: i’d like to look at how AlexK has implemented it, need to make sure
the wayland features support the existing x11 features
RP: nobody’s commented on the mailing list. the change has already been made
in poky and nobody said anything and nothing blew up
ScottM: are you going to switch away from core-image-sato to something weston
RP: we’ll have to come up with something
Armin: i know the mali stuff is hard to get working. Khem does a lot of builds
with graphics stuff, so he’ll probably be the first one to say something
if we switch. the blob drivers lag so far behind
ScottM: true, there were some cases where we couldn’t update for a long time
because we had to wait for vendor blobs to catch up and release weston
things
Randy: is remote desktop possible (ssh -X)?
ScottM: there’s nothing built-in, but there are things that are being worked
on, there are a couple options, mostly over pipewire
JPEW: weston has an RDP backend
ScottM: not as easy as the old ssh -X, but it works
JPEW: with weston there’s the possibility to just forward 1 app instead of
the entire server (rootless)
TimO: we’re in an intermediate phase and vendor support is hard
Armin: it’s like the python2 → python3 change
TW: does that mean a meta-x11?
Armin: probably, not sure if it’ll be public, but somebody’s going to have
to solve that problem (MV, WR, …)
RP: client vs server
JPEW: depends on what you’re trying to do. if an app does crazy things with
the server (e.g. send key events to another app) then wayland doesn’t
permit that
TimO: sato and matchbox are looking clunky these days
JPEW: phosh might be a possibility. i built it recently and it seems good.
uses a lot of gnome (meta-gnome) but it does build and work
TrevorG: i played with it recently too, seemed okay


TW: any umn patches?
RP: actually i did check, didn’t see anything


Saul: qmp. i think there’s a delay in the socket being created on CentOS
RP: i checked and tested your patch and it seemed to work, so i merged it into
master. Thank you for getting it there
Saul: now we’ll see if it triggers, and if it does, then we can add to what
it does. ping me when you see a failure and we’ll look at it
Randy: do we have to pick up the logs manually?
Saul: yea, they’re dumped into a directory (same place as other logs)
Randy: hook it up to the latency monitoring things?
Saul: possibly
RP: there’s an env var set to a path for reproducible build pages generated.
same place Randy is putting some logging and dd test. so we should teach
qmp about that path as a place to put things if’when things go wrong
Saul: part of OE-qa?
RP: yes, the env var makes it into the datastore as a place to put things if
set (OEQA_DEBUGGING_SAVED_OUTPUT). the only tricky part is we’re not
setting it for all builds, but we can look into it


Randy: with this last release (hardknott) the timing for when the branches
were created (hardknott) in various layers was different this time around
and it messed up our (WR) release schedule. could we have a policy on it
RP: individual layers are up to individual maintainers, can’t create a
policy
Randy: i think the one for meta-oe got created a bit too early. could we make
sure that doesn’t happen again?
Armin: maybe ask Khem
RP: with core we start the release branch early but then it only splits when
there’s a diverging commit. then we also tag releases
Armin: it was quite early with meta-oe this time
TimO: it was noticed
Bruce: we had to do some dancing this time
Armin: there are lots of layers that don’t branch, so you just have to
qualify against a specific SHA of their master, but then that can break
when things move on
RP: we have a tagging policy that has a “yocto” prefix and the hope was
that layers would use those tags and that it would be uniform over the
ecosystem
Armin: use the yocto- ones or the hardknott-25 one?
RP: not the hardknott-25 one, that’s linked to poky. it's something i've
wanted to clean up for a while
TW: couldn’t we link all layers _and_ bitbake too? why isn’t there a
hardknott layer in bitbake? i thought i had asked about this in the past
and was told that it couldn’t be done because they’re independent projects
RP: you're thinking poky release numbering vs bitbake versioning. i’d like
to get rid of the poky version numbers, that’s true, but we have been
keeping up with separate between the layers and the tool (bitbake).
Randy: there are tags between them
RP: not sure why the point releases aren’t there in the bitbake tags.
MichaelH maybe we could look into this?
MichaelH: okay, we’re still following procedures from a while ago, so
there’s no reason the procedures can’t be updated. we’ll look into
adding the point release yocto tags into bitbake
RP: then you'll find that there are "yocto-"-prefixed tags throughout the
ecosystem (e.g. oe-core, bitbake, etc) i'm hoping all layers follow suit


Re: AppArmor with BusyBox

Khem Raj
 



On Tue, Apr 27, 2021 at 3:34 PM Konstantin Aladyshev <aladyshev22@...> wrote:
I've added `IMAGE_INSTALL += "findutils"` to my `conf/local.conf`
file, and it seems like it was enough. There weren't any build
conflicts.

Should the AppArmor recipe be upgraded in some way to indicate that it
needs a full-featured findutils package instead of a busybox one?

I think it will be useful to dig a bit further and find out what option does it need from findutils package sometimes this could be solved by using compatible options etc 

If we find out that it has hard dependency on findutils then it should be added to apparmor recipe RDEPENDS 



Best regards,
Konstantin Aladyshev

On Mon, Apr 26, 2021 at 5:08 PM Quentin Schulz
<quentin.schulz@...> wrote:
>
> Hi Konstantin,
>
> On Mon, Apr 26, 2021 at 01:45:30PM +0300, Konstantin Aladyshev wrote:
> > I'm using the OpenBMC system (https://github.com/openbmc/openbmc) and
> > I've tried to enable AppArmor functionality from the 'meta-security'
> > layer.
> >
> > To achieve this I've added these strings to my local.conf file:
> > DISTRO_FEATURES_append = " apparmor"
> > IMAGE_INSTALL += "apparmor"
> >
> > The AppArmor functionality was installed to my image, but
> > unfortunately I've come to this issue:
> >
> > kernel: AppArmor: AppArmor initialized
> > kernel: AppArmor: AppArmor Filesystem Enabled
> > kernel: AppArmor: AppArmor sha1 policy hashing enabled
> > systemd[1]: systemd 247.3+ running in system mode. (+PAM -AUDIT
> > -SELINUX -IMA -APPARMOR -SMACK +SYSVINIT -UTMP -LIBCRYPTSETUP -GCRYPT
> > -GNUTLS -ACL +XZ -LZ4 -ZSTD -SECCOMP +BLKID -ELFUTILS +KMOD -IDN2 -IDN
> > -PCRE2 default-hierarchy=hybrid)
> > systemd[1]: Starting AppArmor initialization...
> > apparmor[113]: Starting AppArmor profiles
> > apparmor[128]: xargs: invalid option -- 'd'
>
> Busybox implementation of xargs does not support specifying a delimiter.
>
> I suggest you to install the full-featured xargs which is provided by
> the findutils recipe.
>
> You probably need to disable xargs Busybox implementation otherwise
> there'll be a conflict (you'll know, Yocto won't create the image).
>
> Cheers,
> Quentin




Re: Can layer maintainers add yocto-X.Y tags for yocto-3.3 and later?

Randy MacLeod
 

Adding Robert, Hongxu and Qi who are likely interested in this topic
for future releases.

On 2021-04-27 3:03 p.m., akuster808 wrote:
On 4/27/21 9:48 AM, Randy MacLeod wrote:
Hi,


I've CCed some of the maintainers of more widely used Yocto layers
to get comments on about tagging. Please add in people who I may
have missed.


For a while now, oe-core has had a yocto-X.Y tag in addition to the
release branch name. This helps users easily find the exact commit
that corresponds to the say 3.3 GA release. There have been some
omissions in tagging but Michael and Richard are adjusting the
release process so that tagging will happen more consistently.

Most yocto layers have not adopted the tagging perhaps because they
weren't aware of it so that's why I'm writing this email. Tagging
will make it easy to find the first commit for a specific release
independent of what the branching policy of a layer is. Layer
maintainers sometimes create the release branch in advance of
when oe-core is released and by adding the tag, it would make it
clear when the layer considers content to be officially released.
So the official starting point is what you are looking for?
Yes. It's always bothered me that the tag wasn't there and now
that oe-core/bitbake/... have been doing it, it would be nice to see
other layers add the start-of-release tag. Usually, it's clear
since you can find the first commit that is unique to the branch.
It's often an update to a README or a layer.conf file that you can find
using 'git merge-base' but the tag will make it simple to locate and
in the case of meta-oe, where the branch came well before the oe-core release, the tag may not be the first commit on the 'hardknott' branch.



Is there any
expectation to tag for dot release alignment?
It would be really nice to have but it's less important to me at least.
What do you think of tagging dot upcoming releases for
meta-oe/dunfell Armin?


Of course it's up to users to decide if they are going to follow
the HEAD of a branch or, for some reason, stick with a tagged commit
or private branch off that commit.
What's more important, tag or branch? Many layers hosted on git.yp.org
don't have the 'hardknott' branch.  If the discipline to create a new
branch is not their, I have a hard time believing 'tagging' will be high
on their list.
I don't expect 100% of layers to do this but hopefully maintatiner will
listen users/submitters we'll get some traction. Also for those layers
that don't want to maintain a branch they *might* not mind adding
the tag to at least record where they were when Yocto branched.



Are there any concerns about attempting to do this for yocto-3.3
and later?
Tagging in Poky has a meaning of a fully QA set of sources at a given
point of time.  It may be interpreted by users that if a tag showed up
in other layers, those layers are also fully tested.
I suppose but once people are around for a while, they'll come to
understand how other layers don't go through the same QA cycle.



Should we make it a requirement for yocto compliance?
I think you mean 'Yocto Compatible'.
Right.

Branching is already a requirement
IIRC as the program is against a specific branch.
Yes, this would be an additional requirement or request.
The benefits that I see I've mostly already explained but
I also like having a numerical uniform string that I can us
to remember the pseudo-random branch names! :)


Thanks for the comments Armin.

../Randy

-armin

Should it be a feature tested by the yocto compliance script?



Here's what's in oe-core and bitbake now:
$ cd .../oe-core.git
$ git tag -l | grep yocto-3
yocto-3.0
yocto-3.1
yocto-3.1.7
yocto-3.2
yocto-3.2.1
yocto-3.3

$ cd bitbake/
$ git tag -l | grep yocto-3
yocto-3.0
yocto-3.1
yocto-3.2

--
# Randy MacLeod
# Wind River Linux


[PATCH yocto-autobuilder-helper] config.json: update variable for change in buildstats.bbclass

sakib.sajal@...
 

Signed-off-by: Sakib Sajal <sakib.sajal@windriver.com>
---
config.json | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/config.json b/config.json
index fc83012..f82664c 100644
--- a/config.json
+++ b/config.json
@@ -59,7 +59,7 @@
"RUNQEMU_TMPFS_DIR = '/home/pokybuild/tmp'",
"BB_HEARTBEAT_EVENT = '60'",
"BB_LOG_HOST_STAT_ON_INTERVAL = '1'",
- "BB_LOG_HOST_STAT_CMDS = 'oe-time-dd-test.sh 100'"
+ "BB_LOG_HOST_STAT_CMDS_INTERVAL = 'oe-time-dd-test.sh 100'"
]
},
"templates" : {
--
2.25.1

1781 - 1800 of 55069