kernel/kernel-yocto: consolidated M3 feature pull request

From: Bruce Ashfield <[email protected]>

Witht the approaching EOL of python2, the kernel packages need to be updated to depend on python3.
...

meta/recipes-kernel/linux/files/0001-foo.patch line 4

Quoted 9 lines · On Wed, Aug 28, 2019 at 03:28:36PM -0400, [email protected] wrote:

...

meta/recipes-kernel/linux/files/0001-foo.patch new file +4 -0

@@ -0,0 +1,25 @@
+From 9ddc5e377434e28f1f3c74c9be011b0c9dfb1de4 Mon Sep 17 00:00:00 2001
+From: Bruce Ashfield <[email protected]>
+Date: Fri, 1 Mar 2019 10:09:43 -0500
+Subject: [PATCH] foo
...

Debug change that leaked into the submission,
or missing proper patch description?

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

Quoted 5 lines · On Wed, Aug 28, 2019 at 03:28:38PM -0400, [email protected] wrote:

From: Bruce Ashfield <[email protected]>

Witht the approaching EOL of python2, the kernel packages need to be updated to depend on python3.
...

Yocto 3.0 ships and supports Python 2.7, so there is no urgent need for last-minute Python 2 -> 3 changes.

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

Quoted 5 lines · On Wed, Aug 28, 2019 at 03:28:38PM -0400, [email protected] wrote:

From: Bruce Ashfield <[email protected]>

Witht the approaching EOL of python2, the kernel packages need to be updated to depend on python3.
...

Yocto 3.0 ships and supports Python 2.7, so there is no urgent need for
last-minute Python 2 -> 3 changes.

Quoted 3 lines

Yocto 3.0 ships and supports Python 2.7, so there is no urgent need for
last-minute Python 2 -> 3 changes.

Removal of 2.X dependencies where we can was an objective of 3.0 and 2.X is EOL and will expire in the lifetime of 3.0. I'd say this is therefore quite in keeping with that...

...
There's zero risk to these, and no reason to sit on them.

Bruce

Quoted 2 lines · Bruce Ashfield

...
There's zero risk to these, and no reason to sit on them.

What range of LTS kernels is covered by the "zero risk"?

Quoted 2 lines

Bruce

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

From: Bruce Ashfield <[email protected]>

The upstream kernel can now handle python3 for the perf scripts, coupled
with the impending EOL of python2, we switch the dependencies in perf (scripting) to python3.

Outside of dependency changes, we also pass the following two variables
to the perf build: PYTHON=python3 PYTHON_CONFIG=python3-config. To ensure that our python3 components are used.

For configurations that disable perf scripting, there is no change in behaviour.

[YOCTO #13358]

Signed-off-by Bruce Ashfield <[email protected]>

---
 meta/recipes-kernel/perf/perf.bb | 16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

meta/recipes- renamed from meta/recipes-kernel/perf/perf.bb +0 -0

kernel/perf/perf.bb
index 4e603f1a32..8ac8e7c308 100644

meta/recipes-kernel/perf/perf.bb +0 -1

@@ -13,7 +13,7 @@ PR = "r9"
 
 PACKAGECONFIG ??= "scripting tui libunwind"
 PACKAGECONFIG[dwarf] = ",NO_DWARF=1"
-PACKAGECONFIG[scripting] = ",NO_LIBPERL=1 NO_LIBPYTHON=1,perl

python"
+PACKAGECONFIG[scripting] = ",NO_LIBPERL=1 NO_LIBPYTHON=1,perl python3"

 # gui support was added with kernel 3.6.35
 # since 3.10 libnewt was replaced by slang
 # to cover a wide range of kernel we add both dependencies

meta/recipes-kernel/perf/perf.bb +2 -2

@@ -44,8 +44,8 @@ PROVIDES = "virtual/perf"
 inherit linux-kernel-base kernel-arch manpages
 
 # needed for building the tools/perf Python bindings
-inherit ${@bb.utils.contains('PACKAGECONFIG', 'scripting',
 'pythonnative', '', d)}
-inherit python-dir
+inherit ${@bb.utils.contains('PACKAGECONFIG', 'scripting',
 'python3native', '', d)}
+inherit python3-dir
 export PYTHON_SITEPACKAGES_DIR

#kernel 3.1+ supports WERROR to disable warnings as errors

meta/recipes-kernel/perf/perf.bb +1 -0

@@ -94,6 +94,7 @@ EXTRA_OEMAKE += "\
     'sharedir=${@os.path.relpath(datadir, prefix)}' \
     'mandir=${@os.path.relpath(mandir, prefix)}' \
     'infodir=${@os.path.relpath(infodir, prefix)}' \
+    ${@bb.utils.contains('PACKAGECONFIG', 'scripting',
 'PYTHON=python3 PYTHON_CONFIG=python3-config', '', d)} \
 "
 

# During do_configure, we might run a 'make clean'. That often
breaks

meta/recipes-kernel/perf/perf.bb +0 -0

@@ -132,7 +133,7 @@ do_install() {
 	oe_runmake install
 	# we are checking for this make target to be compatible with

older perf versions
if ${@bb.utils.contains('PACKAGECONFIG', 'scripting', 'true',
'false', d)} && grep -q install-python_ext ${S}/tools/perf/Makefile*; then

meta/recipes-kernel/perf/perf.bb +3 -2

-		oe_runmake DESTDIR=${D} install-python_ext
+	    oe_runmake DESTDIR=${D} install-python_ext
 	fi
 }

@@ -233,7 +234,8 @@ do_configure_prepend () {
 
     # use /usr/bin/env instead of version specific python
     for s in `find ${S}/tools/perf/scripts/python/ -name '*.py'`; do
-        sed -i 's,/usr/bin/python2,/usr/bin/env python,' "${s}"
+        sed -i 's,/usr/bin/python2,/usr/bin/env python3,' "${s}"
+        sed -i 's,/usr/bin/env python2,/usr/bin/env python3,' "${s}"
     done
 
     # unistd.h can be out of sync between libc-headers and the

captured version in the perf source

meta/recipes-kernel/perf/perf.bb +0 -0

@@ -252,9 +254,9 @@ PACKAGES =+ "${PN}-archive ${PN}-tests ${PN}-perl 

${PN}-python"

RDEPENDS_${PN} += "elfutils bash" RDEPENDS_${PN}-archive =+ "bash"
-RDEPENDS_${PN}-python =+ "bash python python-modules ${@bb.utils.contains('PACKAGECONFIG', 'audit', 'audit-python', '', d)}"
+RDEPENDS_${PN}-python =+ "bash python3 python3-modules ${@bb.utils.contains('PACKAGECONFIG', 'audit', 'audit-python3', '', d)}"
RDEPENDS_${PN}-perl =+ "bash perl perl-modules"

meta/recipes-kernel/perf/perf.bb +1 -1

-RDEPENDS_${PN}-tests =+ "python"
+RDEPENDS_${PN}-tests =+ "python3"
 
 RSUGGESTS_SCRIPTING = "${@bb.utils.contains('PACKAGECONFIG',

'scripting', '${PN}-perl ${PN}-python', '',d)}"
RSUGGESTS_${PN} += "${PN}-archive ${PN}-tests
${RSUGGESTS_SCRIPTING}"

Signature · 1 line

2.19.1

This is causing failure for 5.0 kernels probably because the attr.py python -> python3 changes are not there ...

ERROR: perf-1.0-r9 do_package_qa: QA Issue: /usr/libexec/perf- core/tests/attr.py contained in package perf-tests requires /usr/bin/python, but no providers found in RDEPENDS_perf-tests? [file- rdeps]
ERROR: perf-1.0-r9 do_package_qa: QA run found fatal errors. Please consider fixing them.
ERROR: Logfile of failure stored in: /home/pokybuild/yocto- worker/genericx86/build/build/tmp/work/genericx86-poky-linux/perf/1.0- r9/temp/log.do_package_qa.36284
NOTE: recipe perf-1.0-r9: task do_package_qa: Failed

https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/975/steps/8/logs/step1b

Thanks,

Anuj

Quoted 106 lines · On Wed, 2019-08-28 at 15:28 -0400, [email protected] wrote:

From: Bruce Ashfield <[email protected]>

The upstream kernel can now handle python3 for the perf scripts, coupled
with the impending EOL of python2, we switch the dependencies in perf (scripting) to python3.

Outside of dependency changes, we also pass the following two variables
to the perf build: PYTHON=python3 PYTHON_CONFIG=python3-config. To ensure that our python3 components are used.

For configurations that disable perf scripting, there is no change in behaviour.

[YOCTO #13358]

Signed-off-by Bruce Ashfield <[email protected]>

---
 meta/recipes-kernel/perf/perf.bb | 16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

meta/recipes- renamed from meta/recipes-kernel/perf/perf.bb +0 -0

kernel/perf/perf.bb
index 4e603f1a32..8ac8e7c308 100644

meta/recipes-kernel/perf/perf.bb +0 -1

@@ -13,7 +13,7 @@ PR = "r9"
 
 PACKAGECONFIG ??= "scripting tui libunwind"
 PACKAGECONFIG[dwarf] = ",NO_DWARF=1"
-PACKAGECONFIG[scripting] = ",NO_LIBPERL=1 NO_LIBPYTHON=1,perl

python"
+PACKAGECONFIG[scripting] = ",NO_LIBPERL=1 NO_LIBPYTHON=1,perl python3"

 # gui support was added with kernel 3.6.35
 # since 3.10 libnewt was replaced by slang
 # to cover a wide range of kernel we add both dependencies

meta/recipes-kernel/perf/perf.bb +2 -2

@@ -44,8 +44,8 @@ PROVIDES = "virtual/perf"
 inherit linux-kernel-base kernel-arch manpages
 
 # needed for building the tools/perf Python bindings
-inherit ${@bb.utils.contains('PACKAGECONFIG', 'scripting',
 'pythonnative', '', d)}
-inherit python-dir
+inherit ${@bb.utils.contains('PACKAGECONFIG', 'scripting',
 'python3native', '', d)}
+inherit python3-dir
 export PYTHON_SITEPACKAGES_DIR

#kernel 3.1+ supports WERROR to disable warnings as errors

meta/recipes-kernel/perf/perf.bb +1 -0

@@ -94,6 +94,7 @@ EXTRA_OEMAKE += "\
     'sharedir=${@os.path.relpath(datadir, prefix)}' \
     'mandir=${@os.path.relpath(mandir, prefix)}' \
     'infodir=${@os.path.relpath(infodir, prefix)}' \
+    ${@bb.utils.contains('PACKAGECONFIG', 'scripting',
 'PYTHON=python3 PYTHON_CONFIG=python3-config', '', d)} \
 "
 

# During do_configure, we might run a 'make clean'. That often
breaks

meta/recipes-kernel/perf/perf.bb +0 -0

@@ -132,7 +133,7 @@ do_install() {
      oe_runmake install
      # we are checking for this make target to be compatible with

older perf versions

      if ${@bb.utils.contains('PACKAGECONFIG', 'scripting', 'true',

'false', d)} && grep -q install-python_ext ${S}/tools/perf/Makefile*; then

meta/recipes-kernel/perf/perf.bb +3 -2

-             oe_runmake DESTDIR=${D} install-python_ext
+         oe_runmake DESTDIR=${D} install-python_ext
      fi
 }

@@ -233,7 +234,8 @@ do_configure_prepend () {
 
     # use /usr/bin/env instead of version specific python
     for s in `find ${S}/tools/perf/scripts/python/ -name '*.py'`; do
-        sed -i 's,/usr/bin/python2,/usr/bin/env python,' "${s}"
+        sed -i 's,/usr/bin/python2,/usr/bin/env python3,' "${s}"
+        sed -i 's,/usr/bin/env python2,/usr/bin/env python3,' "${s}"
     done
 
     # unistd.h can be out of sync between libc-headers and the

captured version in the perf source

meta/recipes-kernel/perf/perf.bb +0 -0

@@ -252,9 +254,9 @@ PACKAGES =+ "${PN}-archive ${PN}-tests ${PN}-perl

${PN}-python"

RDEPENDS_${PN} += "elfutils bash" RDEPENDS_${PN}-archive =+ "bash"
-RDEPENDS_${PN}-python =+ "bash python python-modules ${@bb.utils.contains('PACKAGECONFIG', 'audit', 'audit-python', '', d)}"
+RDEPENDS_${PN}-python =+ "bash python3 python3-modules ${@bb.utils.contains('PACKAGECONFIG', 'audit', 'audit-python3', '', d)}"
RDEPENDS_${PN}-perl =+ "bash perl perl-modules"

meta/recipes-kernel/perf/perf.bb +1 -1

-RDEPENDS_${PN}-tests =+ "python"
+RDEPENDS_${PN}-tests =+ "python3"
 
 RSUGGESTS_SCRIPTING = "${@bb.utils.contains('PACKAGECONFIG',

'scripting', '${PN}-perl ${PN}-python', '',d)}"
RSUGGESTS_${PN} += "${PN}-archive ${PN}-tests
${RSUGGESTS_SCRIPTING}"
--
2.19.1

Quoted 1 line

On Wed, Aug 28, 2019 at 8:01 PM Mittal, Anuj <[email protected]>

wrote:
This is causing failure for 5.0 kernels probably because the attr.py

Quoted 15 lines

python -> python3 changes are not there ...

ERROR: perf-1.0-r9 do_package_qa: QA Issue: /usr/libexec/perf- core/tests/attr.py contained in package perf-tests requires /usr/bin/python, but no providers found in RDEPENDS_perf-tests? [file-
rdeps]
ERROR: perf-1.0-r9 do_package_qa: QA run found fatal errors. Please consider fixing them.
ERROR: Logfile of failure stored in: /home/pokybuild/yocto- worker/genericx86/build/build/tmp/work/genericx86-poky- linux/perf/1.0-
r9/temp/log.do_package_qa.36284
NOTE: recipe perf-1.0-r9: task do_package_qa: Failed

Quoted 1 line

https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/975/steps/8/logs/step1b

ote:

trigger

need

Quoted 1 line

unfortunately, I can only cover the active kernels in master with any

Quoted 18 lines · Bruce Ashfield

Quoted 1 line

On Wed, Aug 28, 2019 at 8:01 PM Mittal, Anuj <[email protected]>

wrote:
This is causing failure for 5.0 kernels probably because the attr.py

Quoted 15 lines

python -> python3 changes are not there ...

ERROR: perf-1.0-r9 do_package_qa: QA Issue: /usr/libexec/perf- core/tests/attr.py contained in package perf-tests requires /usr/bin/python, but no providers found in RDEPENDS_perf-tests? [file-
rdeps]
ERROR: perf-1.0-r9 do_package_qa: QA run found fatal errors. Please consider fixing them.
ERROR: Logfile of failure stored in: /home/pokybuild/yocto- worker/genericx86/build/build/tmp/work/genericx86-poky- linux/perf/1.0-
r9/temp/log.do_package_qa.36284
NOTE: recipe perf-1.0-r9: task do_package_qa: Failed

Quoted 2 lines

Quoted 1 line

https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/975/steps/8/logs/step1b

ote:

unfortunately, I can only cover the active kernels in master with any certainty, and I already have a patch to drop 5.0, so I didn't

Quoted 1 line

trigger

this.
I can spin a patch for 5.0 and make sure it is version proofed a ibt, but if anyone else has issues with <insert version here>, they'll

Quoted 3 lines

need

Quoted 1 line

unfortunately, I can only cover the active kernels in master with any

Can we cover at least the kernels in OE-Core master right now affected by this change? So 4.19 as well ...

Thanks,

Anuj

Quoted 28 lines · Anuj

Quoted 18 lines · Bruce Ashfield

Quoted 1 line

On Wed, Aug 28, 2019 at 8:01 PM Mittal, Anuj <[email protected]>

wrote:
This is causing failure for 5.0 kernels probably because the attr.py

Quoted 15 lines

python -> python3 changes are not there ...

ERROR: perf-1.0-r9 do_package_qa: QA Issue: /usr/libexec/perf- core/tests/attr.py contained in package perf-tests requires /usr/bin/python, but no providers found in RDEPENDS_perf-tests? [file-
rdeps]
ERROR: perf-1.0-r9 do_package_qa: QA run found fatal errors. Please consider fixing them.
ERROR: Logfile of failure stored in: /home/pokybuild/yocto- worker/genericx86/build/build/tmp/work/genericx86-poky- linux/perf/1.0-
r9/temp/log.do_package_qa.36284
NOTE: recipe perf-1.0-r9: task do_package_qa: Failed

Quoted 2 lines

Quoted 1 line

https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/975/steps/8/logs/step1b

ote:

unfortunately, I can only cover the active kernels in master with any certainty, and I already have a patch to drop 5.0, so I didn't

Quoted 1 line

trigger

this.
I can spin a patch for 5.0 and make sure it is version proofed a ibt, but if anyone else has issues with <insert version here>, they'll

Quoted 6 lines

Quoted 3 lines

need

Quoted 1 line

unfortunately, I can only cover the active kernels in master with any

Can we cover at least the kernels in OE-Core master right now affected by this change? So 4.19 as well ...

Consider 5.0 to be not there. It is going to be deleted in about a day. My hands are very full, so I'm not able to spend much time on it at the moment.

4.19 did work in my earlier testing, but I will have a look ASAP (probably next week, since my cycles are largely spoken for at the moment).

Bruce

Quoted 4 lines

Thanks,

Anuj

--
- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

From: Bruce Ashfield <[email protected]>

In the 5.3+ perf builds, there are multiple unistd.h files that need to be kept in sync. So not only do we update one, we update both to ensure that libc-headers and the perf build are in sync.

perf checks some key files itself to be sure they are in sync, and bits.h can be out of sync. There's no build error that results with bits.h at the moment, but we still make sure they are in sync to avoid the configure/compile warning.

Signed-off-by Bruce Ashfield <[email protected]>

---
 meta/recipes-kernel/perf/perf.bb | 4 ++++
 1 file changed, 4 insertions(+)

meta/recipes-kernel/perf/perf.bb +0 -0

index 8ac8e7c308..58543c73d8 100644

meta/recipes-kernel/perf/perf.bb +2 -1

+    # bits.h can have the same issuen as unistd.h, so we make the tools variant take precedence
+    install -D -m0644 ${S}/tools/include/linux/bits.h ${S}/include/linux/bits.h
 }
 
 python do_package_prepend() {
--

2.19.1

Quoted 37 lines · Bruce Ashfield

Quoted 28 lines · Anuj

Quoted 18 lines · Bruce Ashfield

Quoted 1 line

On Wed, Aug 28, 2019 at 8:01 PM Mittal, Anuj <[email protected]>

wrote:
This is causing failure for 5.0 kernels probably because the attr.py

Quoted 15 lines

python -> python3 changes are not there ...

ERROR: perf-1.0-r9 do_package_qa: QA Issue: /usr/libexec/perf- core/tests/attr.py contained in package perf-tests requires /usr/bin/python, but no providers found in RDEPENDS_perf-tests? [file-
rdeps]
ERROR: perf-1.0-r9 do_package_qa: QA run found fatal errors. Please consider fixing them.
ERROR: Logfile of failure stored in: /home/pokybuild/yocto- worker/genericx86/build/build/tmp/work/genericx86-poky- linux/perf/1.0-
r9/temp/log.do_package_qa.36284
NOTE: recipe perf-1.0-r9: task do_package_qa: Failed

Quoted 2 lines

Quoted 1 line

https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/975/steps/8/logs/step1b

ote:

unfortunately, I can only cover the active kernels in master with any certainty, and I already have a patch to drop 5.0, so I didn't

Quoted 1 line

trigger

this.
I can spin a patch for 5.0 and make sure it is version proofed a ibt, but if anyone else has issues with <insert version here>, they'll

Quoted 6 lines

Quoted 3 lines

need

Quoted 1 line

unfortunately, I can only cover the active kernels in master with any

Can we cover at least the kernels in OE-Core master right now affected by this change? So 4.19 as well ...

Quoted 7 lines

Consider 5.0 to be not there. It is going to be deleted in about a day. My hands are very full, so I'm not able to spend much time on it at the moment.

4.19 did work in my earlier testing, but I will have a look ASAP (probably next week, since my cycles are largely spoken for at the moment).

.. but I will visually check 4.19 for any other scripts that reference just 'python' visually and make sure my tests are broad enough. It is more builder and boot cycles that I don't have easily accessible. It shouldn't be too hard to make the fixes generic and broad enough to cover it.

Bruce

Quoted 6 lines

Bruce

Quoted 3 lines

Thanks,

Quoted 8 lines

Quoted 1 line

Anuj

--
- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

--
- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Quoted 17 lines · On Wed, Aug 28, 2019 at 3:28 PM <[email protected]> wrote:

From: Bruce Ashfield <[email protected]>

In the 5.3+ perf builds, there are multiple unistd.h files that need to be kept in sync. So not only do we update one, we update both to ensure that libc-headers and the perf build are in sync.

perf checks some key files itself to be sure they are in sync, and bits.h can be out of sync. There's no build error that results with bits.h at the moment, but we still make sure they are in sync to avoid the configure/compile warning.

Signed-off-by Bruce Ashfield <[email protected]>

---
 meta/recipes-kernel/perf/perf.bb | 4 ++++
 1 file changed, 4 insertions(+)

meta/recipes-kernel/perf/perf.bb do_configure_prepend () { · line 245

Quoted 10 lines

meta/recipes-kernel/perf/perf.bb +2 -0

index 8ac8e7c308..58543c73d8 100644
@@ -241,6 +241,10 @@ do_configure_prepend () {
     # unistd.h can be out of sync between libc-headers and the captured version in the perf source
     # so we copy it from the sysroot unistd.h to the perf unistd.h
     install -D -m0644 ${STAGING_INCDIR}/asm-generic/unistd.h ${S}/tools/include/uapi/asm-generic/unistd.h
+    install -D -m0644 ${STAGING_INCDIR}/asm-generic/unistd.h ${S}/include/uapi/asm-generic/unistd.h
+

I just realized this may not be safe across all the kernel versions. I'll submit a new version (if required), after I've tested my python3 changes to perf.

Cheers,

Bruce

Quoted 8 lines

meta/recipes-kernel/perf/perf.bb +2 -1

+    # bits.h can have the same issuen as unistd.h, so we make the tools variant take precedence
+    install -D -m0644 ${S}/tools/include/linux/bits.h ${S}/include/linux/bits.h
 }
 
 python do_package_prepend() {
--

2.19.1

--
- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Quoted 6 lines · Adrian Bunk

Quoted 2 lines · Bruce Ashfield

...
There's zero risk to these, and no reason to sit on them.

What range of LTS kernels is covered by the "zero risk"?

It has nothing to do with LTS kernels.

Cheers,

Bruce

Quoted 6 lines · Bruce Ashfield

Quoted 5 lines · Adrian Bunk

Quoted 2 lines · Bruce Ashfield

...
There's zero risk to these, and no reason to sit on them.

Quoted 3 lines

Quoted 1 line

What range of LTS kernels is covered by the "zero risk"?

It has nothing to do with LTS kernels.

virtual/kernel is special since real products have this provided by a BSP layer instead of using the kernels for the reference platforms that ship with Yocto.

How do your changes interact with a BSP layer that provides the upstream maintained LTS kernel 4.4?

Quoted 4 lines

Cheers,

Bruce

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

Quoted 10 lines · Adrian Bunk

Quoted 8 lines · Bruce Ashfield

Quoted 6 lines · Adrian Bunk

Quoted 2 lines · Bruce Ashfield

...
There's zero risk to these, and no reason to sit on them.

What range of LTS kernels is covered by the "zero risk"?

Quoted 1 line

Quoted 1 line

It has nothing to do with LTS kernels.

...

Quoted 2 lines

How do your changes interact with a BSP layer that provides the upstream maintained LTS kernel 4.4?

As mentioned in other parts of the threads, we test against the reference kernel's in master. Other versions can either bbappend, or send patches. That's unfortunately how it has to be.

Cheers,

Bruce

It is an unexpected meaning of "zero risk" when this excludes breakages with kernels other than the ones in master.

One of the non-python changes to perf blew up the build for me even when trying with a kernel that is only a few months behind on the 4.19 branch, so there's some patches for me to send next month.