On Wed, Feb 19, 2020 at 11:01 PM Khem Raj <raj.khem@...> wrote:

On 2/17/20 11:55 PM, Marek Belisko wrote:

Hi,

I'm debugging strange issue that do_rootfs task took ~50 minutes. I
enabled buildstats and from that I learned it's quite long. Any ideas
how to debug this issue? My idea was to add timestamp to do_rootfs
tasks but I'm not sure if it's even possible. Thanks.

how big is the image its creating, might affect the time. Secondly
use some system perf monitor to see which tool is taking so long.

Image is ~1GB so I would say quite
I can see that python3 took ~75-100% cpu when doing do_rootfs. We
tested on 16.04 + 18.04 Ubuntu server it's same.
Which perf monitor you had in mind? Thanks.

BR,

marek

BR,

marek

--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com

Hi,

You'd be better off asking these questions on the meta-virtualization
mailing list. That's where you'll find the Xen folks.

Thanks, I'll direct any follow-up questions regarding Xen there.

But as for the kernel options, it depends on what kernel you are
using, release, etc. Last I checked, the raspberrypi wouldn't
directly use the fragments from meta-virt, so yes, you'd need to
ensure they are set in your own layer/defconfig.

Ahh, thank you, you managed to switch on the light bulb! :)
Checking the kernel recipes I see now that meta-virt has a
linux-yocto_4.19.bbappend file, whereas meta-raspberrypi uses
linux-raspberrypi_4.19.bb; so as you said, the meta-virt configuration
is never applied due to different versions. Being new to yocto I did
not make that connection immediately, I guess I did miss the obvious.
;)

If I understand you correctly, I need to add a
linux-raspberrypi_4.19.bbappend file in my own layer that applies the
Xen configuration fragments.
That makes sense, thanks again!

Best regards,
Aljoscha

Add missing runtime dependencies otherwise /usr/bin/oscapd can not
startup.

Signed-off-by: Yi Zhao <yi.zhao@...>
---
.../openscap-daemon/openscap-daemon_0.1.10.bb | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/meta-security-compliance/recipes-openscap/openscap-daemon/openscap-daemon_0.1.10.bb b/meta-security-compliance/recipes-openscap/openscap-daemon/openscap-daemon_0.1.10.bb
index ca6e030..a775021 100644
--- a/meta-security-compliance/recipes-openscap/openscap-daemon/openscap-daemon_0.1.10.bb
+++ b/meta-security-compliance/recipes-openscap/openscap-daemon/openscap-daemon_0.1.10.bb
@@ -17,4 +17,7 @@ inherit setuptools3

S = "${WORKDIR}/git"

-RDEPENDS_${PN} = "python"
+RDEPENDS_${PN} = "openscap scap-security-guide \
+ python3-core python3-dbus \
+ python3-pygobject \
+ "
--
2.17.1

ping

Hello,

Thud has moved to "Community supported" today.

The older releases have moved to EOL as no one has stepped up to take on
the maintenance of those older branches.


regards,
Armin

dropped patch now included in update

Signed-off-by: Armin Kuster <akuster808@...>
---
...SNR_xxx-instead-of-__NR_xxx-for-sysc.patch | 45 -------------------
...ibseccomp_2.4.2.bb => libseccomp_2.4.3.bb} | 3 +-
2 files changed, 1 insertion(+), 47 deletions(-)
delete mode 100644 recipes-security/libseccomp/files/0001-tests-rely-on-__SNR_xxx-instead-of-__NR_xxx-for-sysc.patch
rename recipes-security/libseccomp/{libseccomp_2.4.2.bb => libseccomp_2.4.3.bb} (90%)

diff --git a/recipes-security/libseccomp/files/0001-tests-rely-on-__SNR_xxx-instead-of-__NR_xxx-for-sysc.patch b/recipes-security/libseccomp/files/0001-tests-rely-on-__SNR_xxx-instead-of-__NR_xxx-for-sysc.patch
deleted file mode 100644
index a53433f..0000000
--- a/recipes-security/libseccomp/files/0001-tests-rely-on-__SNR_xxx-instead-of-__NR_xxx-for-sysc.patch
+++ /dev/null
@@ -1,45 +0,0 @@
-From 1ecdddb2a5b61cf527d1f238f88a9d129239f87a Mon Sep 17 00:00:00 2001
-From: Paul Moore <paul@...>
-Date: Tue, 5 Nov 2019 15:11:11 -0500
-Subject: [PATCH] tests: rely on __SNR_xxx instead of __NR_xxx for syscalls
-
-We recently changed how libseccomp handles syscall numbers that are
-not defined natively, but we missed test #15.
-
-Acked-by: Tom Hromatka <tom.hromatka@...>
-Signed-off-by: Paul Moore <paul@...>
-
-Upstream-Status: Backport
-[https://github.com/seccomp/libseccomp/commit/1ecdddb2a5b61cf527d1f238f88a9d129239f87a]
-
-Signed-off-by: Yi Zhao <yi.zhao@...>
----
- tests/15-basic-resolver.c | 6 +++---
- 1 file changed, 3 insertions(+), 3 deletions(-)
-
-diff --git a/tests/15-basic-resolver.c b/tests/15-basic-resolver.c
-index 6badef1..0c1eefe 100644
---- a/tests/15-basic-resolver.c
-+++ b/tests/15-basic-resolver.c
-@@ -55,15 +55,15 @@ int main(int argc, char *argv[])
- unsigned int arch;
- char *name = NULL;
-
-- if (seccomp_syscall_resolve_name("open") != __NR_open)
-+ if (seccomp_syscall_resolve_name("open") != __SNR_open)
- goto fail;
-- if (seccomp_syscall_resolve_name("read") != __NR_read)
-+ if (seccomp_syscall_resolve_name("read") != __SNR_read)
- goto fail;
- if (seccomp_syscall_resolve_name("INVALID") != __NR_SCMP_ERROR)
- goto fail;
-
- rc = seccomp_syscall_resolve_name_rewrite(SCMP_ARCH_NATIVE, "openat");
-- if (rc != __NR_openat)
-+ if (rc != __SNR_openat)
- goto fail;
-
- while ((arch = arch_list[iter++]) != -1) {
---
-2.17.1
-
diff --git a/recipes-security/libseccomp/libseccomp_2.4.2.bb b/recipes-security/libseccomp/libseccomp_2.4.3.bb
similarity index 90%
rename from recipes-security/libseccomp/libseccomp_2.4.2.bb
rename to recipes-security/libseccomp/libseccomp_2.4.3.bb
index 07db82a..9ca41e6 100644
--- a/recipes-security/libseccomp/libseccomp_2.4.2.bb
+++ b/recipes-security/libseccomp/libseccomp_2.4.3.bb
@@ -4,10 +4,9 @@ SECTION = "security"
LICENSE = "LGPL-2.1"
LIC_FILES_CHKSUM = "file://LICENSE;beginline=0;endline=1;md5=8eac08d22113880357ceb8e7c37f989f"

-SRCREV = "1b6cfd1fc0b7499a28c24299a93a80bd18619563"
+SRCREV = "1dde9d94e0848e12da20602ca38032b91d521427"

SRC_URI = "git://github.com/seccomp/libseccomp.git;branch=release-2.4 \
- file://0001-tests-rely-on-__SNR_xxx-instead-of-__NR_xxx-for-sysc.patch \
file://run-ptest \
"

--
2.17.1

On Sat, Mar 07, 2020 at 08:38:49PM +0000, akuster wrote:

dropped patch now included in update

Do you want to remove the patch?

yeah.. I should.

v2 shortly

thanks,
Armin

Signed-off-by: Armin Kuster <akuster808@...>
---
 .../libseccomp/{libseccomp_2.4.2.bb => libseccomp_2.4.3.bb}    | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
 rename recipes-security/libseccomp/{libseccomp_2.4.2.bb => libseccomp_2.4.3.bb} (90%)

diff --git a/recipes-security/libseccomp/libseccomp_2.4.2.bb b/recipes-security/libseccomp/libseccomp_2.4.3.bb
similarity index 90%
rename from recipes-security/libseccomp/libseccomp_2.4.2.bb
rename to recipes-security/libseccomp/libseccomp_2.4.3.bb
index 07db82a..9ca41e6 100644
--- a/recipes-security/libseccomp/libseccomp_2.4.2.bb
+++ b/recipes-security/libseccomp/libseccomp_2.4.3.bb
@@ -4,10 +4,9 @@ SECTION = "security"
 LICENSE = "LGPL-2.1"
 LIC_FILES_CHKSUM = "file://LICENSE;beginline=0;endline=1;md5=8eac08d22113880357ceb8e7c37f989f"
 
-SRCREV = "1b6cfd1fc0b7499a28c24299a93a80bd18619563"
+SRCREV = "1dde9d94e0848e12da20602ca38032b91d521427"
 
 SRC_URI = "git://github.com/seccomp/libseccomp.git;branch=release-2.4 \
-           file://0001-tests-rely-on-__SNR_xxx-instead-of-__NR_xxx-for-sysc.patch \
            file://run-ptest \
 "
 
-- 
2.17.1

On Sat, Mar 07, 2020 at 08:38:49PM +0000, akuster wrote:

dropped patch now included in update

Do you want to remove the patch?

Signed-off-by: Armin Kuster <akuster808@...>
---
.../libseccomp/{libseccomp_2.4.2.bb => libseccomp_2.4.3.bb} | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
rename recipes-security/libseccomp/{libseccomp_2.4.2.bb => libseccomp_2.4.3.bb} (90%)

diff --git a/recipes-security/libseccomp/libseccomp_2.4.2.bb b/recipes-security/libseccomp/libseccomp_2.4.3.bb
similarity index 90%
rename from recipes-security/libseccomp/libseccomp_2.4.2.bb
rename to recipes-security/libseccomp/libseccomp_2.4.3.bb
index 07db82a..9ca41e6 100644
--- a/recipes-security/libseccomp/libseccomp_2.4.2.bb
+++ b/recipes-security/libseccomp/libseccomp_2.4.3.bb
@@ -4,10 +4,9 @@ SECTION = "security"
LICENSE = "LGPL-2.1"
LIC_FILES_CHKSUM = "file://LICENSE;beginline=0;endline=1;md5=8eac08d22113880357ceb8e7c37f989f"

-SRCREV = "1b6cfd1fc0b7499a28c24299a93a80bd18619563"
+SRCREV = "1dde9d94e0848e12da20602ca38032b91d521427"

SRC_URI = "git://github.com/seccomp/libseccomp.git;branch=release-2.4 \
- file://0001-tests-rely-on-__SNR_xxx-instead-of-__NR_xxx-for-sysc.patch \
file://run-ptest \
"

--
2.17.1

Signed-off-by: Armin Kuster <akuster808@...>
---
recipes-security/sssd/sssd_1.16.4.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-security/sssd/sssd_1.16.4.bb b/recipes-security/sssd/sssd_1.16.4.bb
index d42a455..c5ddd5c 100644
--- a/recipes-security/sssd/sssd_1.16.4.bb
+++ b/recipes-security/sssd/sssd_1.16.4.bb
@@ -41,7 +41,6 @@ PACKAGECONFIG[ssh] = "--with-ssh, --with-ssh=no, "
PACKAGECONFIG[samba] = "--with-samba, --with-samba=no, samba"
PACKAGECONFIG[selinux] = "--with-selinux, --with-selinux=no --with-semanage=no, libselinux"
PACKAGECONFIG[manpages] = "--with-manpages, --with-manpages=no"
-PACKAGECONFIG[python2] = "--with-python2-bindings, --without-python2-bindings, python, python"
PACKAGECONFIG[python3] = "--with-python3-bindings, --without-python3-bindings"
PACKAGECONFIG[nss] = "--with-crypto=nss, ,nss,"
PACKAGECONFIG[crypto] = "--with-crypto=libcrypto, , libcrypto"
@@ -57,6 +56,7 @@ EXTRA_OECONF += " \
--without-ipa-getkeytab \
--without-python2-bindings \
--enable-pammoddir=${base_libdir}/security \
+ --without-python2-bindings \
"

do_configure_prepend() {
--
2.17.1

dropped patch now included in update

Signed-off-by: Armin Kuster <akuster808@...>
---
.../libseccomp/{libseccomp_2.4.2.bb => libseccomp_2.4.3.bb} | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
rename recipes-security/libseccomp/{libseccomp_2.4.2.bb => libseccomp_2.4.3.bb} (90%)

diff --git a/recipes-security/libseccomp/libseccomp_2.4.2.bb b/recipes-security/libseccomp/libseccomp_2.4.3.bb
similarity index 90%
rename from recipes-security/libseccomp/libseccomp_2.4.2.bb
rename to recipes-security/libseccomp/libseccomp_2.4.3.bb
index 07db82a..9ca41e6 100644
--- a/recipes-security/libseccomp/libseccomp_2.4.2.bb
+++ b/recipes-security/libseccomp/libseccomp_2.4.3.bb
@@ -4,10 +4,9 @@ SECTION = "security"
LICENSE = "LGPL-2.1"
LIC_FILES_CHKSUM = "file://LICENSE;beginline=0;endline=1;md5=8eac08d22113880357ceb8e7c37f989f"

-SRCREV = "1b6cfd1fc0b7499a28c24299a93a80bd18619563"
+SRCREV = "1dde9d94e0848e12da20602ca38032b91d521427"

SRC_URI = "git://github.com/seccomp/libseccomp.git;branch=release-2.4 \
- file://0001-tests-rely-on-__SNR_xxx-instead-of-__NR_xxx-for-sysc.patch \
file://run-ptest \
"

--
2.17.1

On Sat, 2020-03-07 at 16:58 +0000, Richard Purdie wrote:

On Fri, 2020-03-06 at 22:53 +0100, Alexander Kanavin wrote:

On Wed, 4 Mar 2020 at 23:42, Richard Purdie <
richard.purdie@...> wrote:

Just FYI I think there may also be a couple of other packages
coreutils
pulls in and they may also have reproducibility issues (gettext-
ptest,
glibc-locale-* and procps*).

Patch for gettext also sent :) glibc-locale and procps I could not
reproduce :-/

Thanks for that fix, it helps!

FWIW, what I'm seeing with glibc-locale is that these files
"disappear"
from the packages in one of my builds:

./usr/share/locale/vi/LC_MESSAGES/libc.mo
./usr/share/locale/ko/LC_MESSAGES/libc.mo
./usr/share/locale/en_GB/LC_MESSAGES/libc.mo
./usr/share/locale/ca/LC_MESSAGES/libc.mo
./usr/share/locale/fr/LC_MESSAGES/libc.mo
./usr/share/locale/pl/LC_MESSAGES/libc.mo
./usr/share/locale/id/LC_MESSAGES/libc.mo
./usr/share/locale/hr/LC_MESSAGES/libc.mo
./usr/share/locale/uk/LC_MESSAGES/libc.mo
./usr/share/locale/ja/LC_MESSAGES/libc.mo
./usr/share/locale/gl/LC_MESSAGES/libc.mo
./usr/share/locale/es/LC_MESSAGES/libc.mo
./usr/share/locale/el/LC_MESSAGES/libc.mo
./usr/share/locale/pt_BR/LC_MESSAGES/libc.mo
./usr/share/locale/sl/LC_MESSAGES/libc.mo
./usr/share/locale/lt/LC_MESSAGES/libc.mo
./usr/share/locale/rw/LC_MESSAGES/libc.mo
./usr/share/locale/sv/LC_MESSAGES/libc.mo
./usr/share/locale/cs/LC_MESSAGES/libc.mo
./usr/share/locale/nl/LC_MESSAGES/libc.mo
./usr/share/locale/zh_CN/LC_MESSAGES/libc.mo
./usr/share/locale/ia/LC_MESSAGES/libc.mo
./usr/share/locale/fi/LC_MESSAGES/libc.mo
./usr/share/locale/be/LC_MESSAGES/libc.mo
./usr/share/locale/ru/LC_MESSAGES/libc.mo
./usr/share/locale/nb/LC_MESSAGES/libc.mo
./usr/share/locale/zh_TW/LC_MESSAGES/libc.mo
./usr/share/locale/tr/LC_MESSAGES/libc.mo
./usr/share/locale/de/LC_MESSAGES/libc.mo
./usr/share/locale/da/LC_MESSAGES/libc.mo
./usr/share/locale/pt/LC_MESSAGES/libc.mo
./usr/share/locale/hu/LC_MESSAGES/libc.mo
./usr/share/locale/eo/LC_MESSAGES/libc.mo
./usr/share/locale/it/LC_MESSAGES/libc.mo
./usr/share/locale/bg/LC_MESSAGES/libc.mo
./usr/share/locale/sk/LC_MESSAGES/libc.mo

I can conform they're not in the glibc stashed-locale sstate object
so
they disappear somewhere before that in the glibc recipe itself.

Quite where/why I don't know as yet.

Just to save anyone digging, the difference is in configure, one has
msgfmt in the sysroot, one does not. It is there later in the build so
its probably task dependencies not being right.

Cheers,

Richard

On Fri, 2020-03-06 at 22:53 +0100, Alexander Kanavin wrote:

On Wed, 4 Mar 2020 at 23:42, Richard Purdie <
richard.purdie@...> wrote:

Just FYI I think there may also be a couple of other packages
coreutils
pulls in and they may also have reproducibility issues (gettext-
ptest,
glibc-locale-* and procps*).

Patch for gettext also sent :) glibc-locale and procps I could not
reproduce :-/

Thanks for that fix, it helps!

FWIW, what I'm seeing with glibc-locale is that these files "disappear"
from the packages in one of my builds:

./usr/share/locale/vi/LC_MESSAGES/libc.mo
./usr/share/locale/ko/LC_MESSAGES/libc.mo
./usr/share/locale/en_GB/LC_MESSAGES/libc.mo
./usr/share/locale/ca/LC_MESSAGES/libc.mo
./usr/share/locale/fr/LC_MESSAGES/libc.mo
./usr/share/locale/pl/LC_MESSAGES/libc.mo
./usr/share/locale/id/LC_MESSAGES/libc.mo
./usr/share/locale/hr/LC_MESSAGES/libc.mo
./usr/share/locale/uk/LC_MESSAGES/libc.mo
./usr/share/locale/ja/LC_MESSAGES/libc.mo
./usr/share/locale/gl/LC_MESSAGES/libc.mo
./usr/share/locale/es/LC_MESSAGES/libc.mo
./usr/share/locale/el/LC_MESSAGES/libc.mo
./usr/share/locale/pt_BR/LC_MESSAGES/libc.mo
./usr/share/locale/sl/LC_MESSAGES/libc.mo
./usr/share/locale/lt/LC_MESSAGES/libc.mo
./usr/share/locale/rw/LC_MESSAGES/libc.mo
./usr/share/locale/sv/LC_MESSAGES/libc.mo
./usr/share/locale/cs/LC_MESSAGES/libc.mo
./usr/share/locale/nl/LC_MESSAGES/libc.mo
./usr/share/locale/zh_CN/LC_MESSAGES/libc.mo
./usr/share/locale/ia/LC_MESSAGES/libc.mo
./usr/share/locale/fi/LC_MESSAGES/libc.mo
./usr/share/locale/be/LC_MESSAGES/libc.mo
./usr/share/locale/ru/LC_MESSAGES/libc.mo
./usr/share/locale/nb/LC_MESSAGES/libc.mo
./usr/share/locale/zh_TW/LC_MESSAGES/libc.mo
./usr/share/locale/tr/LC_MESSAGES/libc.mo
./usr/share/locale/de/LC_MESSAGES/libc.mo
./usr/share/locale/da/LC_MESSAGES/libc.mo
./usr/share/locale/pt/LC_MESSAGES/libc.mo
./usr/share/locale/hu/LC_MESSAGES/libc.mo
./usr/share/locale/eo/LC_MESSAGES/libc.mo
./usr/share/locale/it/LC_MESSAGES/libc.mo
./usr/share/locale/bg/LC_MESSAGES/libc.mo
./usr/share/locale/sk/LC_MESSAGES/libc.mo

I can conform they're not in the glibc stashed-locale sstate object so
they disappear somewhere before that in the glibc recipe itself.

Quite where/why I don't know as yet.

For procps, the timestamps in the output are different, that is the
only difference. That means something is indeterminate with the source
epoch for that recipe. Again, why, I don't know. The two stamps are:

2019-12-08·04:06:03
2019-12-08·04:05:49

This latter one could potentially be a bug in hashequiv (cc Joshua). It
may need that stamps patch I have fixed up to resolve it. The fix it
needs is to make it apply only to certain tasks.

Cheers,

Richard

On 30/10/2019 06:25, star at gmx.li wrote:

Build of image failed, I got strange and long error messages like:

| from distutils.sysconfig import parse_makefile
| ModuleNotFoundError: No module named 'distutils.sysconfig'
| configure: error: Python failed to run; see above error.

a) What goes wrong here and how can this be avoid?

distutils.sysconfig is part of the standard Python library. What
distribution are you using? It's possible that you've only got a
'minimal' Python installed instead of the full thing.

I came across this old thread when trying "bitbake world" in really
minimalistic docker container with ubuntu-18.04 where I've installed
only the dependencies explicitly checked by sanity check and HOSTTOOLS.

And indeed python3 package in ubuntu doesn't depend on
python3-distutils, I don't know how "standard Python library" is
defined, but this wasn't explicitly "minimal" python, just the default
what you get with python3 in ubuntu.

Maybe it would be worth adding python3native in icu to catch issues like
this?

Luckily it's needed only in zeus, because icu 65.1 currently in
dunfell/master doesn't depend on python3-distutils anymore since:
https://github.com/unicode-org/icu/commit/b4d41b0561b6e8de38b99850ce0e4be8ef536bb1

There is only one more recipe with this issue (at least in the layers i
was testing and that's:
openembedded-core/meta/recipes-core/ovmf/ovmf_git.bb
in zeus as well as master which is explicitly using python3 from host:
export PYTHON_COMMAND = "${HOSTTOOLS_DIR}/python3"

and then fails with:
| Python reported: "No module named 'distutils.util"
|
| GNUmakefile:11: recipe for target 'test' failed

Hello Armin,

On Thu, Mar 5, 2020 at 4:18 PM akuster808 <akuster808@...> wrote:

On 3/5/20 4:47 AM, Jonatan Pålsson wrote:

Fixes the following build error:

.. snip ..
| checking for python2... no
| checking for python3... (cached) python3.8
| configure: error:
| The program python2 was not found in search path.
| Please ensure that it is installed and its directory is included in the search
| path. It is required for building python2 bindings. If you do not want to build
| them please use argument --without-python2-bindings when running configure.
| WARNING: exit code 1 from a shell command.

Signed-off-by: Jonatan Pålsson <jonatan.p@...>
---
recipes-security/sssd/sssd_1.16.4.bb | 1 +
1 file changed, 1 insertion(+)

diff --git a/recipes-security/sssd/sssd_1.16.4.bb b/recipes-security/sssd/sssd_1.16.4.bb
index c381c32..9feba14 100644
--- a/recipes-security/sssd/sssd_1.16.4.bb
+++ b/recipes-security/sssd/sssd_1.16.4.bb
@@ -33,6 +33,7 @@ PACKAGECONFIG[ssh] = "--with-ssh, --with-ssh=no, "
PACKAGECONFIG[samba] = "--with-samba, --with-samba=no, samba"
PACKAGECONFIG[selinux] = "--with-selinux, --with-selinux=no --with-semanage=no, libselinux"
PACKAGECONFIG[manpages] = "--with-manpages, --with-manpages=no"
+PACKAGECONFIG[python2] = "--with-python2-bindings, --without-python2-bindings, python, python"

Python2 is not supported in Master so maybe append EXTRA_OECONF with --without-python2-binding.

Ah, I see. I'll prepare a new patch with this.

I can take this for zeus thou.

For zeus, a PACKAGECONFIG entry for python2 is available, but the
RDEPENDS and DEPENDS entries are missing. I'll prepare a patch to add
those entries.

Thanks,
Jonatan

We do not necessarily match the major version of kernel recipe and update
it every time oe-core upgrades kernel.

Signed-off-by: He Zhe <zhe.he@...>
---
.../linux/{linux-yocto_4.%.bbappend => linux-yocto_%.bbappend} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename meta-cgl-common/recipes-kernel/linux/{linux-yocto_4.%.bbappend => linux-yocto_%.bbappend} (100%)

diff --git a/meta-cgl-common/recipes-kernel/linux/linux-yocto_4.%.bbappend b/meta-cgl-common/recipes-kernel/linux/linux-yocto_%.bbappend
similarity index 100%
rename from meta-cgl-common/recipes-kernel/linux/linux-yocto_4.%.bbappend
rename to meta-cgl-common/recipes-kernel/linux/linux-yocto_%.bbappend
--
2.7.4

From: André Draszik <git@...>

As linux-yocto upgraded to 5.x in oe-core, update
the bbappend to 5.x to remove the warning

ERROR: No recipes available for:
.../meta-security/meta-tpm/recipes-kernel/linux/linux-yocto_4.%.bbappend

This patch hasn't been verified any further than allowing bitbake
to complete with a non-linux-yocto kernel. In particular options could
be different, or new ones needed / desired.

Signed-off-by: André Draszik <git@...>
---
.../linux/{linux-yocto_4.%.bbappend => linux-yocto_5.%.bbappend} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename meta-tpm/recipes-kernel/linux/{linux-yocto_4.%.bbappend => linux-yocto_5.%.bbappend} (100%)

diff --git a/meta-tpm/recipes-kernel/linux/linux-yocto_4.%.bbappend b/meta-tpm/recipes-kernel/linux/linux-yocto_5.%.bbappend
similarity index 100%
rename from meta-tpm/recipes-kernel/linux/linux-yocto_4.%.bbappend
rename to meta-tpm/recipes-kernel/linux/linux-yocto_5.%.bbappend
--
2.23.0.rc1