[OE-core] [PATCH] conf/machine: Enable keyboard and mouse on RISC-V machines
From: Alistair Francis Signed-off-by: Alistair Francis Signed-off-by: Khem Raj --- meta/conf/machine/include/riscv/qemuriscv.inc | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/conf/machine/include/riscv/qemuriscv.inc b/meta/conf/machine/include/riscv/qemuriscv.inc index 493124d946..428d28bde1 100644 --- a/meta/conf/machine/include/riscv/qemuriscv.inc +++ b/meta/conf/machine/include/riscv/qemuriscv.inc @@ -35,3 +35,4 @@ QB_ROOTFS_OPT = "-drive id=disk0,file=@ROOTFS@,if=none,format=raw -device virtio QB_SERIAL_OPT = "-device virtio-serial-device -chardev null,id=virtcon -device virtconsole,chardev=virtcon" QB_TCPSERIAL_OPT = " -device virtio-serial-device -chardev socket,id=virtcon,port=@PORT@,host=127.0.0.1 -device virtconsole,chardev=virtcon" QB_GRAPHICS = "-device bochs-display" +QB_OPT_APPEND = "-device virtio-mouse-pci -device virtio-keyboard-pci" -- 2.31.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#150178): https://lists.openembedded.org/g/openembedded-core/message/150178 Mute This Topic: https://lists.openembedded.org/mt/81796082/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] python3: Skip failing ptests due to load variability
Skip tests until load issue is fixed,
most commonly seen on the arm64 builder.
[YOCTO #14296]
Signed-off-by: Yi Fan Yu
---
...sts-due-to-load-variability-on-YP-AB.patch | 53 +++
meta/recipes-devtools/python/python3_3.9.2.bb | 1 +
2 files changed, 54 insertions(+)
create mode 100644
meta/recipes-devtools/python/python3/0001-Skip-failing-tests-due-to-load-variability-on-YP-AB.patch
diff --git
a/meta/recipes-devtools/python/python3/0001-Skip-failing-tests-due-to-load-variability-on-YP-AB.patch
b/meta/recipes-devtools/python/python3/0001-Skip-failing-tests-due-to-load-variability-on-YP-AB.patch
new file mode 100644
index 00..a49d603d47
--- /dev/null
+++
b/meta/recipes-devtools/python/python3/0001-Skip-failing-tests-due-to-load-variability-on-YP-AB.patch
@@ -0,0 +1,53 @@
+From 0b25b66d4f54bd74615c9ff10f3fae8f0d1c548d Mon Sep 17 00:00:00 2001
+From: Yi Fan Yu
+Date: Thu, 1 Apr 2021 13:08:37 -0700
+Subject: [PATCH] Skip failing tests due to load variability on YP AB
+
+
+Skip these tests until AB-INT is solved.
+
+[YOCTO #14296]
+
+Upstream-Status: Inappropriate [OE-Specific]
+
+Signed-off-by: Yi Fan Yu
+---
+ Lib/test/_test_multiprocessing.py | 2 ++
+ Lib/test/test_time.py | 1 +
+ 2 files changed, 3 insertions(+)
+
+diff --git a/Lib/test/_test_multiprocessing.py
b/Lib/test/_test_multiprocessing.py
+index fd3b430..cda29f6 100644
+--- a/Lib/test/_test_multiprocessing.py
b/Lib/test/_test_multiprocessing.py
+@@ -568,6 +568,7 @@ def test_close(self):
+
+ close_queue(q)
+
++@unittest.skip('timing related test, dependent on load')
+ def test_many_processes(self):
+ if self.TYPE == 'threads':
+ self.skipTest('test not appropriate for {}'.format(self.TYPE))
+@@ -4715,6 +4716,7 @@ def signal_and_sleep(cls, sem, period):
+ sem.release()
+ time.sleep(period)
+
++@unittest.skip('timing related test, dependent on load')
+ def test_wait_integer(self):
+ from multiprocessing.connection import wait
+
+diff --git a/Lib/test/test_time.py b/Lib/test/test_time.py
+index 3258298..adcf407 100644
+--- a/Lib/test/test_time.py
b/Lib/test/test_time.py
+@@ -474,6 +474,7 @@ def test_monotonic(self):
+ def test_perf_counter(self):
+ time.perf_counter()
+
++@unittest.skip('timing related test, dependent on load')
+ def test_process_time(self):
+ # process_time() should not include time spend during a sleep
+ start = time.process_time()
+--
+2.17.1
+
diff --git a/meta/recipes-devtools/python/python3_3.9.2.bb
b/meta/recipes-devtools/python/python3_3.9.2.bb
index c5e47eec4f..fd1172335a 100644
--- a/meta/recipes-devtools/python/python3_3.9.2.bb
+++ b/meta/recipes-devtools/python/python3_3.9.2.bb
@@ -30,6 +30,7 @@ SRC_URI =
"http://www.python.org/ftp/python/${PV}/Python-${PV}.tar.xz \
file://0001-Makefile-do-not-compile-.pyc-in-parallel.patch \
file://0020-configure.ac-setup.py-do-not-add-a-curses-include-pa.patch \
file://0001-Lib-sysconfig.py-use-libdir-values-from-configuratio.patch \
+
file://0001-Skip-failing-tests-due-to-load-variability-on-YP-AB.patch \
"
SRC_URI_append_class-native = " \
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150177):
https://lists.openembedded.org/g/openembedded-core/message/150177
Mute This Topic: https://lists.openembedded.org/mt/81789077/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] make-mod-scripts: pass CROSS_COMPILE to configure and build
On 16:52-20210401, Bruce Ashfield wrote: [...] > > Though I still don't understand the rationale why would we not move > > CROSS_COMPILE from kernel.bbclass to kernel-arch.bbclass instead of > > having to duplicate it here? after all KERNEL_CC etc are in that realm > > and would'nt CROSS_COMPILE fall in that bucket? > > It is definitely a valid thing to do as well. > > My only hesitation is the timing. We are very close to release, so I'd > prefer the lightest touch fix, which is this one. > > We can of course revisit in about a month when the release is out. Aah, thanks.. understood. And, thanks for looking closer at this. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#150176): https://lists.openembedded.org/g/openembedded-core/message/150176 Mute This Topic: https://lists.openembedded.org/mt/81764668/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] make-mod-scripts: pass CROSS_COMPILE to configure and build
On Thu, Apr 1, 2021 at 4:31 PM Nishanth Menon wrote:
>
> On 09:22-20210401, Bruce Ashfield wrote:
> > On Wed, Mar 31, 2021 at 8:00 PM Denys Dmytriyenko wrote:
> > >
> > > Fixes:
> > > | CALL
> > > /OE/poky-master/build/tmp/work-shared/qemuarm64/kernel-source/scripts/checksyscalls.sh
> > > | CALL
> > > /OE/poky-master/build/tmp/work-shared/qemuarm64/kernel-source/scripts/atomic/check-atomics.sh
> > > | LDS arch/arm64/kernel/vdso/vdso.lds
> > > | CC arch/arm64/kernel/vdso/vgettimeofday.o
> > > | AS arch/arm64/kernel/vdso/note.o
> > > | AS arch/arm64/kernel/vdso/sigreturn.o
> > > | LD arch/arm64/kernel/vdso/vdso.so.dbg
> > > | VDSOSYM include/generated/vdso-offsets.h
> > > | OBJCOPY arch/arm64/kernel/vdso/vdso.so
> > > | objcopy: Unable to recognise the format of the input file
> > > `arch/arm64/kernel/vdso/vdso.so.dbg'
> > > |
> > > /OE/poky-master/build/tmp/work-shared/qemuarm64/kernel-source/arch/arm64/kernel/vdso/Makefile:61:
> > > recipe for target 'arch/arm64/kernel/vdso/vdso.so' failed
> > >
> > > Cc: Bruce Ashfield
> >
> > I like the lighter touch of this patch. I still can't explain why this
> > isn't necessary on one of my builders, but is on the other .. but that
> > of course isn't relevant to this!
> >
> > I've reviewed and tested this, so no concerns from my end.
> >
> > Queue the cheesy -by lines:
> >
> > Reviewed-by: Bruce Ashfield
> > Acked-by: Bruce Ashfield
> > Tested-by: Bruce Ashfield
> >
>
> Sounds good to me as well.. Thanks for discussing this chain[1].
>
>
> Tested-by: Nishanth Menon
>
>
> Though I still don't understand the rationale why would we not move
> CROSS_COMPILE from kernel.bbclass to kernel-arch.bbclass instead of
> having to duplicate it here? after all KERNEL_CC etc are in that realm
> and would'nt CROSS_COMPILE fall in that bucket?
It is definitely a valid thing to do as well.
My only hesitation is the timing. We are very close to release, so I'd
prefer the lightest touch fix, which is this one.
We can of course revisit in about a month when the release is out.
Bruce
>
> > > Cc: Nishanth Menon
> > > Signed-off-by: Denys Dmytriyenko
> > > ---
> > > meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> > > b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> > > index 92ffa47..b2b50b9 100644
> > > --- a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> > > +++ b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> > > @@ -19,7 +19,7 @@ DEPENDS += "bc-native bison-native"
> > > DEPENDS += "gmp-native"
> > >
> > > EXTRA_OEMAKE = " HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}"
> > > HOSTCPP="${BUILD_CPP}""
> > > -EXTRA_OEMAKE += " HOSTCXX="${BUILD_CXX} ${BUILD_CXXFLAGS}
> > > ${BUILD_LDFLAGS}""
> > > +EXTRA_OEMAKE += " HOSTCXX="${BUILD_CXX} ${BUILD_CXXFLAGS}
> > > ${BUILD_LDFLAGS}" CROSS_COMPILE=${TARGET_PREFIX}"
> > >
> > > # Build some host tools under work-shared. CC, LD, and AR are probably
> > > # not used, but this is the historical way of invoking "make scripts".
> > > --
> > > 2.7.4
> > >
> >
> >
> > --
> > - Thou shalt not follow the NULL pointer, for chaos and madness await
> > thee at its end
> > - "Use the force Harry" - Gandalf, Star Trek II
>
> --
> Regards,
> Nishanth Menon
> Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
> 849D 1736 249D
>
> [1] https://lists.openembedded.org/g/openembedded-core/message/150143
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150175):
https://lists.openembedded.org/g/openembedded-core/message/150175
Mute This Topic: https://lists.openembedded.org/mt/81764668/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] image-live.bbclass: optional depends when ROOTFS empty
`ROOTFS` is optional. It can be empty if the live image doesn't require
a rootfs. In such cases, the build doesn't depend on
`do_image_{LIVE_ROOTFS_TYPE}`.
Signed-off-by: Guillaume Champagne
---
meta/classes/image-live.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/image-live.bbclass b/meta/classes/image-live.bbclass
index 1b2183eadd..8b08305cdb 100644
--- a/meta/classes/image-live.bbclass
+++ b/meta/classes/image-live.bbclass
@@ -30,7 +30,7 @@ do_bootimg[depends] += "dosfstools-native:do_populate_sysroot
\
virtual/kernel:do_deploy \
${MLPREFIX}syslinux:do_populate_sysroot \
syslinux-native:do_populate_sysroot \
-
${PN}:do_image_${@d.getVar('LIVE_ROOTFS_TYPE').replace('-', '_')} \
+${@'%s:do_image_%s' % (d.getVar('PN'),
d.getVar('LIVE_ROOTFS_TYPE').replace('-', '_')) if d.getVar('ROOTFS') else ''} \
"
--
2.20.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150174):
https://lists.openembedded.org/g/openembedded-core/message/150174
Mute This Topic: https://lists.openembedded.org/mt/81787880/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] make-mod-scripts: pass CROSS_COMPILE to configure and build
On 09:22-20210401, Bruce Ashfield wrote:
> On Wed, Mar 31, 2021 at 8:00 PM Denys Dmytriyenko wrote:
> >
> > Fixes:
> > | CALL
> > /OE/poky-master/build/tmp/work-shared/qemuarm64/kernel-source/scripts/checksyscalls.sh
> > | CALL
> > /OE/poky-master/build/tmp/work-shared/qemuarm64/kernel-source/scripts/atomic/check-atomics.sh
> > | LDS arch/arm64/kernel/vdso/vdso.lds
> > | CC arch/arm64/kernel/vdso/vgettimeofday.o
> > | AS arch/arm64/kernel/vdso/note.o
> > | AS arch/arm64/kernel/vdso/sigreturn.o
> > | LD arch/arm64/kernel/vdso/vdso.so.dbg
> > | VDSOSYM include/generated/vdso-offsets.h
> > | OBJCOPY arch/arm64/kernel/vdso/vdso.so
> > | objcopy: Unable to recognise the format of the input file
> > `arch/arm64/kernel/vdso/vdso.so.dbg'
> > |
> > /OE/poky-master/build/tmp/work-shared/qemuarm64/kernel-source/arch/arm64/kernel/vdso/Makefile:61:
> > recipe for target 'arch/arm64/kernel/vdso/vdso.so' failed
> >
> > Cc: Bruce Ashfield
>
> I like the lighter touch of this patch. I still can't explain why this
> isn't necessary on one of my builders, but is on the other .. but that
> of course isn't relevant to this!
>
> I've reviewed and tested this, so no concerns from my end.
>
> Queue the cheesy -by lines:
>
> Reviewed-by: Bruce Ashfield
> Acked-by: Bruce Ashfield
> Tested-by: Bruce Ashfield
>
Sounds good to me as well.. Thanks for discussing this chain[1].
Tested-by: Nishanth Menon
Though I still don't understand the rationale why would we not move
CROSS_COMPILE from kernel.bbclass to kernel-arch.bbclass instead of
having to duplicate it here? after all KERNEL_CC etc are in that realm
and would'nt CROSS_COMPILE fall in that bucket?
> > Cc: Nishanth Menon
> > Signed-off-by: Denys Dmytriyenko
> > ---
> > meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> > b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> > index 92ffa47..b2b50b9 100644
> > --- a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> > +++ b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> > @@ -19,7 +19,7 @@ DEPENDS += "bc-native bison-native"
> > DEPENDS += "gmp-native"
> >
> > EXTRA_OEMAKE = " HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}"
> > HOSTCPP="${BUILD_CPP}""
> > -EXTRA_OEMAKE += " HOSTCXX="${BUILD_CXX} ${BUILD_CXXFLAGS}
> > ${BUILD_LDFLAGS}""
> > +EXTRA_OEMAKE += " HOSTCXX="${BUILD_CXX} ${BUILD_CXXFLAGS}
> > ${BUILD_LDFLAGS}" CROSS_COMPILE=${TARGET_PREFIX}"
> >
> > # Build some host tools under work-shared. CC, LD, and AR are probably
> > # not used, but this is the historical way of invoking "make scripts".
> > --
> > 2.7.4
> >
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
[1] https://lists.openembedded.org/g/openembedded-core/message/150143
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150173):
https://lists.openembedded.org/g/openembedded-core/message/150173
Mute This Topic: https://lists.openembedded.org/mt/81764668/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][dunfell 13/15] packagegroups: delete useless "PROVIDES" lines
On Thu, Apr 1, 2021 at 10:07 AM Andre McCurdy wrote:
>
> On Thu, Apr 1, 2021 at 8:29 AM Steve Sakoman wrote:
> >
> > From: "Robert P. J. Day"
> >
> > There is apparently no functional value to "PROVIDES" lines anymore in
> > packagegroup recipe files, so remove the lonely couple of examples
> > left.
>
> Seems questionable for backporting to a stable release. The bogus
> PROVIDES lines have been there for more than a decade without causing
> any issues (ie removing them isn't fixing a bug).
My rationale for including this was that users often take our recipes
as templates for their own, so best we model good behavior :-)
But I don't feel strongly about it so I'll drop from my pull request.
That's what this review period is for, so thanks for taking a
thoughtful look at the patches!
Steve
> > Signed-off-by: Robert P. J. Day > Signed-off-by:
> > Richard Purdie
> > (cherry picked from commit 6f2c9602bc5fc6794b852ec20f40ea62a55ada1e)
> > Signed-off-by: Steve Sakoman
> > ---
> > meta/recipes-core/packagegroups/packagegroup-base.bb | 1 -
> > meta/recipes-core/packagegroups/packagegroup-core-nfs.bb | 1 -
> > 2 files changed, 2 deletions(-)
> >
> > diff --git a/meta/recipes-core/packagegroups/packagegroup-base.bb
> > b/meta/recipes-core/packagegroups/packagegroup-base.bb
> > index 1f802da09b..c32664917f 100644
> > --- a/meta/recipes-core/packagegroups/packagegroup-base.bb
> > +++ b/meta/recipes-core/packagegroups/packagegroup-base.bb
> > @@ -8,7 +8,6 @@ PACKAGE_ARCH = "${MACHINE_ARCH}"
> >
> > inherit packagegroup
> >
> > -PROVIDES = "${PACKAGES}"
> > PACKAGES = ' \
> > packagegroup-base \
> > packagegroup-base-extended \
> > diff --git a/meta/recipes-core/packagegroups/packagegroup-core-nfs.bb
> > b/meta/recipes-core/packagegroups/packagegroup-core-nfs.bb
> > index b345e314ad..20fe6fc092 100644
> > --- a/meta/recipes-core/packagegroups/packagegroup-core-nfs.bb
> > +++ b/meta/recipes-core/packagegroups/packagegroup-core-nfs.bb
> > @@ -7,7 +7,6 @@ PR = "r2"
> >
> > inherit packagegroup
> >
> > -PROVIDES = "${PACKAGES}"
> > PACKAGES = "${PN}-server ${PN}-client"
> >
> > SUMMARY_${PN}-client = "NFS client"
> > --
> > 2.25.1
> >
> >
> >
> >
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150172):
https://lists.openembedded.org/g/openembedded-core/message/150172
Mute This Topic: https://lists.openembedded.org/mt/81779869/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][dunfell 13/15] packagegroups: delete useless "PROVIDES" lines
On Thu, Apr 1, 2021 at 8:29 AM Steve Sakoman wrote:
>
> From: "Robert P. J. Day"
>
> There is apparently no functional value to "PROVIDES" lines anymore in
> packagegroup recipe files, so remove the lonely couple of examples
> left.
Seems questionable for backporting to a stable release. The bogus
PROVIDES lines have been there for more than a decade without causing
any issues (ie removing them isn't fixing a bug).
> Signed-off-by: Robert P. J. Day > Signed-off-by:
> Richard Purdie
> (cherry picked from commit 6f2c9602bc5fc6794b852ec20f40ea62a55ada1e)
> Signed-off-by: Steve Sakoman
> ---
> meta/recipes-core/packagegroups/packagegroup-base.bb | 1 -
> meta/recipes-core/packagegroups/packagegroup-core-nfs.bb | 1 -
> 2 files changed, 2 deletions(-)
>
> diff --git a/meta/recipes-core/packagegroups/packagegroup-base.bb
> b/meta/recipes-core/packagegroups/packagegroup-base.bb
> index 1f802da09b..c32664917f 100644
> --- a/meta/recipes-core/packagegroups/packagegroup-base.bb
> +++ b/meta/recipes-core/packagegroups/packagegroup-base.bb
> @@ -8,7 +8,6 @@ PACKAGE_ARCH = "${MACHINE_ARCH}"
>
> inherit packagegroup
>
> -PROVIDES = "${PACKAGES}"
> PACKAGES = ' \
> packagegroup-base \
> packagegroup-base-extended \
> diff --git a/meta/recipes-core/packagegroups/packagegroup-core-nfs.bb
> b/meta/recipes-core/packagegroups/packagegroup-core-nfs.bb
> index b345e314ad..20fe6fc092 100644
> --- a/meta/recipes-core/packagegroups/packagegroup-core-nfs.bb
> +++ b/meta/recipes-core/packagegroups/packagegroup-core-nfs.bb
> @@ -7,7 +7,6 @@ PR = "r2"
>
> inherit packagegroup
>
> -PROVIDES = "${PACKAGES}"
> PACKAGES = "${PN}-server ${PN}-client"
>
> SUMMARY_${PN}-client = "NFS client"
> --
> 2.25.1
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150171):
https://lists.openembedded.org/g/openembedded-core/message/150171
Mute This Topic: https://lists.openembedded.org/mt/81779869/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] what are the dangers of adding "out-of-tree" files to FILES_${PN}?
On Thu, Apr 1, 2021 at 6:08 AM Robert P. J. Day wrote:
>
> recently, i've run across a couple layers based on pretty much
> up-to-date OE/YP, where fixed files are being added to a package via
> assignments like this:
>
> FILES_${PN} += "/data"
>
> i already know that's a bad idea, but i'm curious as to what build
> errors might occur when trying something like this.
What's the specific concern? It won't work well for -native recipes
(as discussed in another of these threads), but apart from that it
should work OK.
To be safe for use in a -native recipe you could change it to:
FILES_${PN} += "${base_prefix}/data"
> i was first asked
> about what might have caused a "pseudo abort" error as described here:
>
> https://wiki.yoctoproject.org/wiki/Pseudo_Abort
>
> where the generated error referred to "path mismatch ... ino ###
> db" ... etc etc. my first (admittedly uneducated) guess was that, in
> the midst of installation, some of that external content under /data
> was perhaps being deleted or updated in some way that was changing
> inodes.
I don't think you can corrupt the pseudo database with a packaging rule.
> even if doing something like technically works, can someone explain
> what ugliness might result, i'm assuming from having any of that
> external data change in the middle of a build?
>
> rday
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150170):
https://lists.openembedded.org/g/openembedded-core/message/150170
Mute This Topic: https://lists.openembedded.org/mt/81775911/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] Use shutil.move when os.rename fails
>From 57b633a93bd91b7b1aa21cce5ac7997b958ca917 Mon Sep 17 00:00:00 2001
From: Devendra Tewari
Date: Thu, 1 Apr 2021 16:07:25 -0300
Subject: [PATCH] Use shutil.move when os.rename fails
Incremental build in Docker fails with
OSError: [Errno 18] Invalid cross-device link
When source and destination are on different overlay filesystems.
This change handles error with os.rename and retries with shutil.move.
The reason os.rename is still used is because shutil.move is too slow
for speed sensitive sections of code.
[Yocto #14301]
---
meta/classes/sstate.bbclass | 22 ++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index 8e8efd18d5..60f7a94285 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -384,6 +384,7 @@ def sstate_installpkg(ss, d):
def sstate_installpkgdir(ss, d):
import oe.path
import subprocess
+import shutil
sstateinst = d.getVar("SSTATE_INSTDIR")
d.setVar('SSTATE_FIXMEDIR', ss['fixmedir'])
@@ -401,7 +402,10 @@ def sstate_installpkgdir(ss, d):
for state in ss['dirs']:
prepdir(state[1])
-os.rename(sstateinst + state[0], state[1])
+try:
+os.rename(sstateinst + state[0], state[1])
+except OSError:
+shutil.move(sstateinst + state[0], state[1])
sstate_install(ss, d)
for plain in ss['plaindirs']:
@@ -413,7 +417,10 @@ def sstate_installpkgdir(ss, d):
dest = plain
bb.utils.mkdirhier(src)
prepdir(dest)
-os.rename(src, dest)
+try:
+os.rename(src, dest)
+except OSError:
+shutil.move(src, dest)
return True
@@ -638,6 +645,7 @@ python sstate_hardcode_path () {
def sstate_package(ss, d):
import oe.path
+import shutil
tmpdir = d.getVar('TMPDIR')
@@ -664,7 +672,10 @@ def sstate_package(ss, d):
continue
bb.error("sstate found an absolute path symlink %s
pointing at %s. Please replace this with a relative link." % (srcpath,
link))
bb.debug(2, "Preparing tree %s for packaging at %s" % (state[1],
sstatebuild + state[0]))
-os.rename(state[1], sstatebuild + state[0])
+try:
+os.rename(state[1], sstatebuild + state[0])
+except OSError:
+shutil.move(state[1], sstatebuild + state[0])
workdir = d.getVar('WORKDIR')
sharedworkdir = os.path.join(d.getVar('TMPDIR'), "work-shared")
@@ -674,7 +685,10 @@ def sstate_package(ss, d):
pdir = plain.replace(sharedworkdir, sstatebuild)
bb.utils.mkdirhier(plain)
bb.utils.mkdirhier(pdir)
-os.rename(plain, pdir)
+try:
+os.rename(plain, pdir)
+except OSError:
+shutil.move(plain, pdir)
d.setVar('SSTATE_BUILDDIR', sstatebuild)
d.setVar('SSTATE_INSTDIR', sstatebuild)
--
2.29.2
On Tue, Mar 30, 2021 at 7:39 PM Devendra Tewari
wrote:
> Here's the correct link
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=14301. I'll resubmit
> the patch referencing the bug in the commit message. Thanks.
>
> Em 30 de mar. de 2021, à(s) 18:59, Denys Dmytriyenko
> escreveu:
>
> The link is for a 10-year old bug, probably not what you wanted.
> Also, if a patch fixes existing bug in bugzilla, it needs to reference it
> in
> commit message as well - [YOCTO#1234567]
>
>
> On Mon, Mar 29, 2021 at 12:37:45PM -0300, Devendra Tewari wrote:
>
> Also, this is due to
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=1430.
>
>
> On 29 Mar 2021, at 12:35, Devendra Tewari
> wrote:
>
>
> Sure.
>
>
> Would the following commit message be sufficient?
>
>
> Use shutil.move when os.rename fails
>
>
> Incremental build in Docker fails with
>
>
> OSError: [Errno 18] Invalid cross-device link
>
>
> When source and destination are on different overlay filesystems.
>
>
> This change handles the error with os.rename and retries with
> shutil.move.
>
>
> Thanks,
>
> Devendra
>
>
> On 29 Mar 2021, at 12:23, Konrad Weihmann wrote:
>
>
> Yes please quote a bit from the python manpage [1] - I certainly see the
> difference (and the edge cases where os.rename might fail), but that should
> be documented as part of the commit message
>
>
> [1] https://docs.python.org/3/library/shutil.html#shutil.move
>
>
> On 29.03.21 17:21, Bruce Ashfield wrote:
>
> Can you document the cases that os.rename() is failing ? And also why
>
> would we expect the shutil.move() to work in those cases ?
>
> If a change like this cases issues in the future, we need that extra
>
> information in the commit head for proper triage.
>
> Bruce
>
> On Mon, Mar 29, 2021 at 11:16 AM Devendra Tewari
>
> wrote:
>
>
> ---
>
> meta/classes/sstate.bbclass | 26 ++
>
> 1 file changed, 22 insertions(+), 4 deletions(-)
>
>
> diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
>
> index
[OE-core] [PATCH] uboot: Deploy default symlinks with fitImage
Some image recipes uses ${DEPLOY_DIR_IMAGE}/${UBOOT_BINARY} to create
their images. Force the re-creation of those symlinks pointing to the
u-boot-fitImage in case UBOOT_FITIMAGE_ENABLE is set.
Signed-off-by: Klaus Heinrich Kiwi
---
meta/classes/uboot-sign.bbclass | 9 +
1 file changed, 9 insertions(+)
diff --git a/meta/classes/uboot-sign.bbclass b/meta/classes/uboot-sign.bbclass
index 85304d452e..d11882f90f 100644
--- a/meta/classes/uboot-sign.bbclass
+++ b/meta/classes/uboot-sign.bbclass
@@ -473,6 +473,15 @@ do_deploy_prepend_pn-${UBOOT_PN}() {
}
+do_deploy_append_pn-${UBOOT_PN}() {
+ # If we're creating a u-boot fitImage, point u-boot.bin
+ # symlink since it might get used by image recipes
+ if [ "${UBOOT_FITIMAGE_ENABLE}" = "1" ] ; then
+ ln -sf ${UBOOT_FITIMAGE_IMAGE} ${DEPLOYDIR}/${UBOOT_BINARY}
+ ln -sf ${UBOOT_FITIMAGE_IMAGE} ${DEPLOYDIR}/${UBOOT_SYMLINK}
+ fi
+}
+
python () {
if ( (d.getVar('UBOOT_SIGN_ENABLE') == '1'
or d.getVar('UBOOT_FITIMAGE_ENABLE') == '1')
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150168):
https://lists.openembedded.org/g/openembedded-core/message/150168
Mute This Topic: https://lists.openembedded.org/mt/81783222/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] valgrind: print failed ptest details
Some intermittent failures in valgrind are hard
reproduce.
Printing the difference between actual and expected
will make understanding them slightly easier.
[YOCTO #14294]
Signed-off-by: Yi Fan Yu
---
meta/recipes-devtools/valgrind/valgrind/run-ptest | 10 ++
1 file changed, 10 insertions(+)
diff --git a/meta/recipes-devtools/valgrind/valgrind/run-ptest
b/meta/recipes-devtools/valgrind/valgrind/run-ptest
index 3e0205fe6e..60d243276b 100755
--- a/meta/recipes-devtools/valgrind/valgrind/run-ptest
+++ b/meta/recipes-devtools/valgrind/valgrind/run-ptest
@@ -56,6 +56,16 @@ for i in `cat remove-for-all`; do
mv $i.IGNORE $i.vgtest;
done
+echo "Failed test details..."
+failed_tests=`grep FAIL: ${LOG} | awk '{print $2}'`
+for test in $failed_tests; do
+for diff_results in `ls $test*.diff`; do
+echo $diff_results
+echo ''
+cat $diff_results
+done
+done
+
passed=`grep PASS: ${LOG}|wc -l`
failed=`grep FAIL: ${LOG}|wc -l`
skipped=`grep SKIP: ${LOG}|wc -l`
--
2.29.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150167):
https://lists.openembedded.org/g/openembedded-core/message/150167
Mute This Topic: https://lists.openembedded.org/mt/81782598/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] conf/machine: Enable bochs-display on RISC-V machines
Enable the bochs-display as q QEMU argument when running on RISC-V machines. Signed-off-by: Alistair Francis --- meta/conf/machine/include/riscv/qemuriscv.inc | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/conf/machine/include/riscv/qemuriscv.inc b/meta/conf/machine/include/riscv/qemuriscv.inc index 47d7e9b174..493124d946 100644 --- a/meta/conf/machine/include/riscv/qemuriscv.inc +++ b/meta/conf/machine/include/riscv/qemuriscv.inc @@ -34,3 +34,4 @@ QB_NETWORK_DEVICE = "-device virtio-net-device,netdev=net0,mac=@MAC@" QB_ROOTFS_OPT = "-drive id=disk0,file=@ROOTFS@,if=none,format=raw -device virtio-blk-device,drive=disk0" QB_SERIAL_OPT = "-device virtio-serial-device -chardev null,id=virtcon -device virtconsole,chardev=virtcon" QB_TCPSERIAL_OPT = " -device virtio-serial-device -chardev socket,id=virtcon,port=@PORT@,host=127.0.0.1 -device virtconsole,chardev=virtcon" +QB_GRAPHICS = "-device bochs-display" -- 2.31.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#150166): https://lists.openembedded.org/g/openembedded-core/message/150166 Mute This Topic: https://lists.openembedded.org/mt/81782174/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] make-mod-scripts: Provide the correct objcopy to kernel make
On Thu, Apr 1, 2021 at 11:54 AM Khem Raj wrote:
>
>
>
> On 4/1/21 6:16 AM, Bruce Ashfield wrote:
> > On Wed, Mar 31, 2021 at 8:01 PM Denys Dmytriyenko wrote:
> >>
> >> On Mon, Mar 29, 2021 at 11:14:13AM -0400, Bruce Ashfield wrote:
> >>> On Mon, Mar 29, 2021 at 10:08 AM Nishanth Menon wrote:
>
> On 13:31-20210327, Bruce Ashfield wrote:
> > On Thu, Mar 25, 2021 at 9:13 PM Nishanth Menon via
> > lists.openembedded.org wrote:
> >>
> >> When cross-compiling with v5.12-rc3, prepare fails[1] build of vdso at
> >> the objcopy stage since it seems to be using the local host's objcopy
> >> rather than the cross-compile version we want it to use.
> >>
> >> This can be trivially reproduced in a localbuild of the kernel
> >> following the build parameters provided in the process[2]
> >>
> >> Lets fix this by passing OBJCOPY over to the kernel.
> >>
> >
> > As I mentioned to Denys, I hadn't seen this. Consulting the
> > maintainers file would have found me as a good addition to the cc'.
> >
>
> Sure. understood. Thanks..
>
> > I'm doing some other work on make-mod-scripts dependencies right now,
> > so I've pulled this in and will re-test against all of the active
> > kernel versions in master.
> >
>
>
> Thanks.
>
> > But I don't think that make-mod-scripts is the only place we'd need
> > this, if it is indeed happening on the tip of all the supported
> > versions. There are routes to have the prepare steps run, without a
> > make-mod-scripts dependency.
> >
> > We've already made the mistake of letting the make-mod-scrips and
> > kernel build parameters diverge (see AR=${KERNEL_AR}), so I need to
> > spend a few minutes getting them back in sync.
> >
> > I was just able to build and boot qemuarm64 on 5.12-rc4, so there's
> > something different about your config than my setup. We need to figure
> > that out. It could be a .config triggering different components to be
> > built, but unlikely given vdso being involved.
> >
> > qemuarm64 login: root
> > root@qemuarm64:~# uname -a
> > Linux qemuarm64 5.12.0-rc4-yoctodev-standard #1 SMP PREEMPT Mon Mar 22
> > 18:46:22 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
> > root@qemuarm64:~#
>
> Hmm... only thing I have done is cross compile - see the pastebins.
> >
> >> [1] https://pastebin.ubuntu.com/p/pNcQtb93wr/
> >> [2] https://pastebin.ubuntu.com/p/vZGqgh9Sq5/
> >> Signed-off-by: Nishanth Menon
>
> [...]
> >> diff --git a/meta/classes/kernel-arch.bbclass
> >> b/meta/classes/kernel-arch.bbclass
> >> index 07ec242e63bb..3d25fc7ac531 100644
> >> --- a/meta/classes/kernel-arch.bbclass
> >> +++ b/meta/classes/kernel-arch.bbclass
> >> @@ -60,9 +60,12 @@ TARGET_LD_KERNEL_ARCH ?= ""
> >> HOST_LD_KERNEL_ARCH ?= "${TARGET_LD_KERNEL_ARCH}"
> >> TARGET_AR_KERNEL_ARCH ?= ""
> >> HOST_AR_KERNEL_ARCH ?= "${TARGET_AR_KERNEL_ARCH}"
> >> +TARGET_OBJCOPY_KERNEL_ARCH ?= ""
> >> +HOST_OBJCOPY_KERNEL_ARCH ?= "${TARGET_OBJCOPY_KERNEL_ARCH}"
> >>
> >
> > We shouldn't need this TARGET_OBJCOPY_KERNEL_ARCH ->
> > HOST_OBJCOPY_KERNEL_ARCH, I can't think of how objcopy would be using
> > them.
>
> >
> > Are you setting them to some value in your builds ?
>
> No, I am not. I decided to maintain consistency of usage from LD and AR.
> I could'nt think of a usage either, true.
> >>>
> >>> That's what I figured. I was worried I was missing some sort of
> >>> usecase. No harm in copying the existing pattern, I didn't introduce
> >>> it either, so I wanted to make sure there wasn't something going on
> >>> that I didn't see.
> >>>
>
>
> >
> >> KERNEL_CC = "${CCACHE}${HOST_PREFIX}gcc ${HOST_CC_KERNEL_ARCH}
> >> -fuse-ld=bfd ${DEBUG_PREFIX_MAP}
> >> -fdebug-prefix-map=${STAGING_KERNEL_DIR}=${KERNEL_SRC_PATH}"
> >> KERNEL_LD = "${CCACHE}${HOST_PREFIX}ld.bfd ${HOST_LD_KERNEL_ARCH}"
> >> KERNEL_AR = "${CCACHE}${HOST_PREFIX}ar ${HOST_AR_KERNEL_ARCH}"
> >> +KERNEL_OBJCOPY = "${CCACHE}${HOST_PREFIX}objcopy
> >> ${HOST_OBJCOPY_KERNEL_ARCH}"
> >
> > The main kernel Makefile already defines, and the standard env should
> > already have both CROSS_COMPILE and OBJCOPY defined to be the target
> > version.
> >
> > Makefile:OBJCOPY= $(CROSS_COMPILE)objcopy
>
> OK this is what is confusing me -> I dont see CROSS_COMPILE being set -
> which is what I had expected in the first place. other than
> meta/recipes-kernel/perf/perf.bb, I dont see it set else where -> I was
> really wondering why all the specific usage, when CROSS_COMPILE would
> have just done the job.. Then I was guessing maybe the rationale is for
> some ancient kernel where CROSS_COMPILE is'nt set right?
>
Re: [OE-core] [poky][dunfell][PATCHv2] openssh: fix CVE-2020-14145
On Wed, Mar 31, 2021 at 11:19 PM Sana Kazi wrote:
>
> Hi Steve,
>
> I have verified the patch on dunfell branch and it builds successfully.
Sorry, I tried your patch both locally and on the autobuilder and it
still fails to build:
https://errors.yoctoproject.org/Errors/Details/575272/
Steve
>
> From: Steve Sakoman
> Sent: Wednesday, March 31, 2021 11:31 PM
> To: Sana Kazi
> Cc: Patches and discussions about the oe-core layer
> ; Khem Raj ;
> Nisha Parrakat ; Purushottam Choudhary
> ; Harpritkaur Bhandari
>
> Subject: Re: [OE-core] [poky][dunfell][PATCHv2] openssh: fix CVE-2020-14145
>
> V2 also fails to build:
>
> ERROR: openssh-8.2p1-r0 do_patch: Command Error: 'quilt --quiltrc
> /home/steve/builds/poky-contrib/build/tmp/work/core2-64-poky-linux/openssh/8.2p1-r0/recipe-sysroot-native/etc/quiltrc
> push' exited with 0 Output:
> Applying patch CVE-2020-14145.patch
> patching file sshconnect2.c
> Hunk #1 FAILED at 102.
> Hunk #2 FAILED at 119.
> Hunk #3 FAILED at 159.
> 3 out of 3 hunks FAILED -- rejects in file sshconnect2.c
> Patch CVE-2020-14145.patch does not apply (enforce with -f)
>
> Before submitting please verify that your patches both apply to the
> head of the dunfell branch, and build as well!
>
> Steve
>
>
> On Wed, Mar 31, 2021 at 7:21 AM Sana Kazi wrote:
> >
> > From: Lee Chee Yang
> >
> > (From OE-Core rev: 38482edf1a31ed0735b746cf0ab3e1adda4199d1)
> >
> > Signed-off-by: Lee Chee Yang
> > Signed-off-by: Anuj Mittal
> > Signed-off-by: Richard Purdie
> > Signed-off-by: Sana Kazi
> > ---
> > .../openssh/openssh/CVE-2020-14145.patch | 90 +++
> > .../openssh/openssh_8.2p1.bb | 1 +
> > 2 files changed, 91 insertions(+)
> > create mode 100644
> > meta/recipes-connectivity/openssh/openssh/CVE-2020-14145.patch
> >
> > diff --git a/meta/recipes-connectivity/openssh/openssh/CVE-2020-14145.patch
> > b/meta/recipes-connectivity/openssh/openssh/CVE-2020-14145.patch
> > new file mode 100644
> > index 00..0046ee1a51
> > --- /dev/null
> > +++ b/meta/recipes-connectivity/openssh/openssh/CVE-2020-14145.patch
> > @@ -0,0 +1,90 @@
> > +From b3855ff053f5078ec3d3c653cdaedefaa5fc362d Mon Sep 17 00:00:00 2001
> > +From: "d...@openbsd.org"
> > +Date: Fri, 18 Sep 2020 05:23:03 +
> > +Subject: [PATCH] upstream: tweak the client hostkey preference ordering
> > + algorithm to
> > +
> > +prefer the default ordering if the user has a key that matches the
> > +best-preference default algorithm.
> > +
> > +feedback and ok markus@
> > +
> > +OpenBSD-Commit-ID: a92dd7d7520ddd95c0a16786a7519e6d0167d35f
> > +
> > +Upstream-Status: Backport
> > +[https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenssh%2Fopenssh-portable%2Fcommit%2Fb3855ff053f5078ec3d3c653cdaedefaa5fc362ddata=04%7C01%7CSana.Kazi%40kpit.com%7C4b74e63f0ba745d0e18608d8f46f0bd8%7C3539451eb46e4a26a242ff61502855c7%7C0%7C0%7C637528105076588451%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=FEdHjP9Fp%2BlrVEtby1zBa5W%2BlrkVHHFVJgMOk%2BvDusY%3Dreserved=0]
> > +CVE: CVE-2020-14145
> > +Signed-off-by: Chee Yang Lee
> > +
> > +---
> > + sshconnect2.c | 41 ++---
> > + 1 file changed, 37 insertions(+), 2 deletions(-)
> > +
> > +diff --git a/sshconnect2.c b/sshconnect2.c
> > +index 347e348c60..f64aae66af 100644
> > +--- a/sshconnect2.c
> > b/sshconnect2.c
> > +@@ -102,12 +102,25 @@ verify_host_key_callback(struct sshkey *hostkey,
> > struct ssh *ssh)
> > + return 0;
> > + }
> > +
> > ++/* Returns the first item from a comma-separated algorithm list */
> > ++static char *
> > ++first_alg(const char *algs)
> > ++{
> > ++ char *ret, *cp;
> > ++
> > ++ ret = xstrdup(algs);
> > ++ if ((cp = strchr(ret, ',')) != NULL)
> > ++ *cp = '\0';
> > ++ return ret;
> > ++}
> > ++
> > + static char *
> > + order_hostkeyalgs(char *host, struct sockaddr *hostaddr, u_short port)
> > + {
> > +- char *oavail, *avail, *first, *last, *alg, *hostname, *ret;
> > ++ char *oavail = NULL, *avail = NULL, *first = NULL, *last = NULL;
> > ++ char *alg = NULL, *hostname = NULL, *ret = NULL, *best = NULL;
> > + size_t maxlen;
> > +- struct hostkeys *hostkeys;
> > ++ struct hostkeys *hostkeys = NULL;
> > + int ktype;
> > + u_int i;
> > +
> > +@@ -119,6 +132,26 @@ order_hostkeyalgs(char *host, struct sockaddr
> > *hostaddr, u_short port)
> > + for (i = 0; i < options.num_system_hostfiles; i++)
> > + load_hostkeys(hostkeys, hostname,
> > options.system_hostfiles[i]);
> > +
> > ++ /*
> > ++ * If a plain public key exists that matches the type of the best
> > ++ * preference HostkeyAlgorithms, then use the whole list as is.
> > ++ * Note that we ignore whether the best preference algorithm is a
> > ++ * certificate type, as sshconnect.c will downgrade
Re: [OE-core] [PATCH] make-mod-scripts: Provide the correct objcopy to kernel make
On 4/1/21 6:16 AM, Bruce Ashfield wrote:
On Wed, Mar 31, 2021 at 8:01 PM Denys Dmytriyenko wrote:
On Mon, Mar 29, 2021 at 11:14:13AM -0400, Bruce Ashfield wrote:
On Mon, Mar 29, 2021 at 10:08 AM Nishanth Menon wrote:
On 13:31-20210327, Bruce Ashfield wrote:
On Thu, Mar 25, 2021 at 9:13 PM Nishanth Menon via
lists.openembedded.org wrote:
When cross-compiling with v5.12-rc3, prepare fails[1] build of vdso at
the objcopy stage since it seems to be using the local host's objcopy
rather than the cross-compile version we want it to use.
This can be trivially reproduced in a localbuild of the kernel
following the build parameters provided in the process[2]
Lets fix this by passing OBJCOPY over to the kernel.
As I mentioned to Denys, I hadn't seen this. Consulting the
maintainers file would have found me as a good addition to the cc'.
Sure. understood. Thanks..
I'm doing some other work on make-mod-scripts dependencies right now,
so I've pulled this in and will re-test against all of the active
kernel versions in master.
Thanks.
But I don't think that make-mod-scripts is the only place we'd need
this, if it is indeed happening on the tip of all the supported
versions. There are routes to have the prepare steps run, without a
make-mod-scripts dependency.
We've already made the mistake of letting the make-mod-scrips and
kernel build parameters diverge (see AR=${KERNEL_AR}), so I need to
spend a few minutes getting them back in sync.
I was just able to build and boot qemuarm64 on 5.12-rc4, so there's
something different about your config than my setup. We need to figure
that out. It could be a .config triggering different components to be
built, but unlikely given vdso being involved.
qemuarm64 login: root
root@qemuarm64:~# uname -a
Linux qemuarm64 5.12.0-rc4-yoctodev-standard #1 SMP PREEMPT Mon Mar 22
18:46:22 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
root@qemuarm64:~#
Hmm... only thing I have done is cross compile - see the pastebins.
[1] https://pastebin.ubuntu.com/p/pNcQtb93wr/
[2] https://pastebin.ubuntu.com/p/vZGqgh9Sq5/
Signed-off-by: Nishanth Menon
[...]
diff --git a/meta/classes/kernel-arch.bbclass b/meta/classes/kernel-arch.bbclass
index 07ec242e63bb..3d25fc7ac531 100644
--- a/meta/classes/kernel-arch.bbclass
+++ b/meta/classes/kernel-arch.bbclass
@@ -60,9 +60,12 @@ TARGET_LD_KERNEL_ARCH ?= ""
HOST_LD_KERNEL_ARCH ?= "${TARGET_LD_KERNEL_ARCH}"
TARGET_AR_KERNEL_ARCH ?= ""
HOST_AR_KERNEL_ARCH ?= "${TARGET_AR_KERNEL_ARCH}"
+TARGET_OBJCOPY_KERNEL_ARCH ?= ""
+HOST_OBJCOPY_KERNEL_ARCH ?= "${TARGET_OBJCOPY_KERNEL_ARCH}"
We shouldn't need this TARGET_OBJCOPY_KERNEL_ARCH ->
HOST_OBJCOPY_KERNEL_ARCH, I can't think of how objcopy would be using
them.
Are you setting them to some value in your builds ?
No, I am not. I decided to maintain consistency of usage from LD and AR.
I could'nt think of a usage either, true.
That's what I figured. I was worried I was missing some sort of
usecase. No harm in copying the existing pattern, I didn't introduce
it either, so I wanted to make sure there wasn't something going on
that I didn't see.
KERNEL_CC = "${CCACHE}${HOST_PREFIX}gcc ${HOST_CC_KERNEL_ARCH} -fuse-ld=bfd
${DEBUG_PREFIX_MAP} -fdebug-prefix-map=${STAGING_KERNEL_DIR}=${KERNEL_SRC_PATH}"
KERNEL_LD = "${CCACHE}${HOST_PREFIX}ld.bfd ${HOST_LD_KERNEL_ARCH}"
KERNEL_AR = "${CCACHE}${HOST_PREFIX}ar ${HOST_AR_KERNEL_ARCH}"
+KERNEL_OBJCOPY = "${CCACHE}${HOST_PREFIX}objcopy ${HOST_OBJCOPY_KERNEL_ARCH}"
The main kernel Makefile already defines, and the standard env should
already have both CROSS_COMPILE and OBJCOPY defined to be the target
version.
Makefile:OBJCOPY= $(CROSS_COMPILE)objcopy
OK this is what is confusing me -> I dont see CROSS_COMPILE being set -
which is what I had expected in the first place. other than
meta/recipes-kernel/perf/perf.bb, I dont see it set else where -> I was
really wondering why all the specific usage, when CROSS_COMPILE would
have just done the job.. Then I was guessing maybe the rationale is for
some ancient kernel where CROSS_COMPILE is'nt set right?
It could be, we also wanted to tack on the CCACHE stuff, but generally
speaking .. it is all kind of redundant with new kernels.
So we really have to pass this, when fundamentally it is the same
definition as what the defaults give us.
What does that resolve to in your builds ? In mine, when I dump the
objcopy value from within the kernel build, I get:
| /opt/poky/build/tmp/work-shared/qemuarm64/kernel-source/Makefile:443:
*** objcopy: aarch64-poky-linux-objcopy. Stop.
Which should be doing the job.
x86's objcopy - which is why I was trying to figure out what the heck
went on..
That is indeed strange.
What does bitbake -e tell you ?
CROSS_COMPILE should be exported by kernel.bbclass itself,
it definitely is in my environment dump.
Bruce,
Looks like make-mod-scripts does not inherit kernel.bbclass, but only
kernel-arch.bbclass and hence
[OE-core][dunfell 15/15] image,populate_sdk_base: move 'func' flag setting for sdk command vars
From: Christopher Larson
Setting the 'func' flag on the commands variables ensures that they are parsed
as shell, and therefore that the referenced commands contents are included in
checksums. Doing this only in image.bbclass means that this is missing in
recipes that are not images, but which inherit populate_sdk or populate_sdk_base
directly, so move it to the latter.
[YOCTO #13998]
Signed-off-by: Christopher Larson
Signed-off-by: Richard Purdie
(cherry picked from commit edc28907ce19a7298059dd388933c58a9c6c28b9)
Signed-off-by: Steve Sakoman
---
meta/classes/image.bbclass | 2 +-
meta/classes/populate_sdk_base.bbclass | 7 +++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 42d2886505..79c487ea18 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -115,7 +115,7 @@ def rootfs_command_variables(d):
'IMAGE_PREPROCESS_COMMAND','RPM_PREPROCESS_COMMANDS','RPM_POSTPROCESS_COMMANDS','DEB_PREPROCESS_COMMANDS','DEB_POSTPROCESS_COMMANDS']
python () {
-variables = rootfs_command_variables(d) + sdk_command_variables(d)
+variables = rootfs_command_variables(d)
for var in variables:
if d.getVar(var, False):
d.setVarFlag(var, 'func', '1')
diff --git a/meta/classes/populate_sdk_base.bbclass
b/meta/classes/populate_sdk_base.bbclass
index 6954237596..ca56d803cb 100644
--- a/meta/classes/populate_sdk_base.bbclass
+++ b/meta/classes/populate_sdk_base.bbclass
@@ -324,6 +324,13 @@ def sdk_variables(d):
do_populate_sdk[vardeps] += "${@sdk_variables(d)}"
+python () {
+variables = sdk_command_variables(d)
+for var in variables:
+if d.getVar(var, False):
+d.setVarFlag(var, 'func', '1')
+}
+
do_populate_sdk[file-checksums] += "${TOOLCHAIN_SHAR_REL_TMPL}:True \
${TOOLCHAIN_SHAR_EXT_TMPL}:True"
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150162):
https://lists.openembedded.org/g/openembedded-core/message/150162
Mute This Topic: https://lists.openembedded.org/mt/81779875/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][dunfell 14/15] buildhistory: add missing vardepsexcludes
From: Christopher Larson
For POPULATE_SDK_POST_TARGET_COMMAND, POPULATE_SDK_POST_HOST_COMMAND, and
SDK_POSTPROCESS_COMMAND, the appropriate entries were added to
vardepvalueexclude, but we want them in vardepsexclude as well.
Signed-off-by: Christopher Larson
Signed-off-by: Richard Purdie
(cherry picked from commit 554b17e0bbe5190e4b03121f2ed06f4845012a71)
Signed-off-by: Steve Sakoman
---
meta/classes/buildhistory.bbclass | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/classes/buildhistory.bbclass
b/meta/classes/buildhistory.bbclass
index 8a1359acbe..44a66df962 100644
--- a/meta/classes/buildhistory.bbclass
+++ b/meta/classes/buildhistory.bbclass
@@ -671,13 +671,16 @@ IMAGE_POSTPROCESS_COMMAND[vardepsexclude] +=
"buildhistory_get_imageinfo"
POPULATE_SDK_POST_TARGET_COMMAND_append = "
buildhistory_list_installed_sdk_target;"
POPULATE_SDK_POST_TARGET_COMMAND_append = "
buildhistory_get_sdk_installed_target;"
POPULATE_SDK_POST_TARGET_COMMAND[vardepvalueexclude] .= "|
buildhistory_list_installed_sdk_target;| buildhistory_get_sdk_installed_target;"
+POPULATE_SDK_POST_TARGET_COMMAND[vardepsexclude] +=
"buildhistory_list_installed_sdk_target buildhistory_get_sdk_installed_target"
POPULATE_SDK_POST_HOST_COMMAND_append = "
buildhistory_list_installed_sdk_host;"
POPULATE_SDK_POST_HOST_COMMAND_append = " buildhistory_get_sdk_installed_host;"
POPULATE_SDK_POST_HOST_COMMAND[vardepvalueexclude] .= "|
buildhistory_list_installed_sdk_host;| buildhistory_get_sdk_installed_host;"
+POPULATE_SDK_POST_HOST_COMMAND[vardepsexclude] +=
"buildhistory_list_installed_sdk_host buildhistory_get_sdk_installed_host"
SDK_POSTPROCESS_COMMAND_append = " buildhistory_get_sdkinfo ;
buildhistory_get_extra_sdkinfo; "
SDK_POSTPROCESS_COMMAND[vardepvalueexclude] .= "| buildhistory_get_sdkinfo ;
buildhistory_get_extra_sdkinfo; "
+SDK_POSTPROCESS_COMMAND[vardepsexclude] += "buildhistory_get_sdkinfo
buildhistory_get_extra_sdkinfo"
python buildhistory_write_sigs() {
if not "task" in (d.getVar('BUILDHISTORY_FEATURES') or "").split():
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150161):
https://lists.openembedded.org/g/openembedded-core/message/150161
Mute This Topic: https://lists.openembedded.org/mt/81779872/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][dunfell 13/15] packagegroups: delete useless "PROVIDES" lines
From: "Robert P. J. Day"
There is apparently no functional value to "PROVIDES" lines anymore in
packagegroup recipe files, so remove the lonely couple of examples
left.
Signed-off-by: Robert P. J. Day
Signed-off-by: Richard Purdie
(cherry picked from commit 6f2c9602bc5fc6794b852ec20f40ea62a55ada1e)
Signed-off-by: Steve Sakoman
---
meta/recipes-core/packagegroups/packagegroup-base.bb | 1 -
meta/recipes-core/packagegroups/packagegroup-core-nfs.bb | 1 -
2 files changed, 2 deletions(-)
diff --git a/meta/recipes-core/packagegroups/packagegroup-base.bb
b/meta/recipes-core/packagegroups/packagegroup-base.bb
index 1f802da09b..c32664917f 100644
--- a/meta/recipes-core/packagegroups/packagegroup-base.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-base.bb
@@ -8,7 +8,6 @@ PACKAGE_ARCH = "${MACHINE_ARCH}"
inherit packagegroup
-PROVIDES = "${PACKAGES}"
PACKAGES = ' \
packagegroup-base \
packagegroup-base-extended \
diff --git a/meta/recipes-core/packagegroups/packagegroup-core-nfs.bb
b/meta/recipes-core/packagegroups/packagegroup-core-nfs.bb
index b345e314ad..20fe6fc092 100644
--- a/meta/recipes-core/packagegroups/packagegroup-core-nfs.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-core-nfs.bb
@@ -7,7 +7,6 @@ PR = "r2"
inherit packagegroup
-PROVIDES = "${PACKAGES}"
PACKAGES = "${PN}-server ${PN}-client"
SUMMARY_${PN}-client = "NFS client"
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150160):
https://lists.openembedded.org/g/openembedded-core/message/150160
Mute This Topic: https://lists.openembedded.org/mt/81779869/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][dunfell 12/15] populate_sdk_ext: Avoid copying and producing .pyc files
From: Mark Hatle
Since pyc cache files are really system specific, no real reason to copy or
generate them during the eSDK build process. Also generating them has the
possibility of re-using inodes that pseudo may have been tracking, leading
a build failure.
Signed-off-by: Mark Hatle
Signed-off-by: Richard Purdie
(cherry picked from commit ce8eba263647ae63a722122e28f26af46ae083a0)
Signed-off-by: Steve Sakoman
---
meta/classes/populate_sdk_ext.bbclass | 4 +++-
meta/lib/oe/copy_buildsystem.py | 6 +++---
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/meta/classes/populate_sdk_ext.bbclass
b/meta/classes/populate_sdk_ext.bbclass
index d63abf4f30..aa00d5397c 100644
--- a/meta/classes/populate_sdk_ext.bbclass
+++ b/meta/classes/populate_sdk_ext.bbclass
@@ -247,7 +247,9 @@ python copy_buildsystem () {
# Create a layer for new recipes / appends
bbpath = d.getVar('BBPATH')
-bb.process.run(['devtool', '--bbpath', bbpath, '--basepath', baseoutpath,
'create-workspace', '--create-only', os.path.join(baseoutpath, 'workspace')])
+env = os.environ.copy()
+env['PYTHONDONTWRITEBYTECODE'] = '1'
+bb.process.run(['devtool', '--bbpath', bbpath, '--basepath', baseoutpath,
'create-workspace', '--create-only', os.path.join(baseoutpath, 'workspace')],
env=env)
# Create bblayers.conf
bb.utils.mkdirhier(baseoutpath + '/conf')
diff --git a/meta/lib/oe/copy_buildsystem.py b/meta/lib/oe/copy_buildsystem.py
index 31a84f5b06..d97bf9d1b9 100644
--- a/meta/lib/oe/copy_buildsystem.py
+++ b/meta/lib/oe/copy_buildsystem.py
@@ -20,7 +20,7 @@ def _smart_copy(src, dest):
mode = os.stat(src).st_mode
if stat.S_ISDIR(mode):
bb.utils.mkdirhier(dest)
-cmd = "tar --exclude='.git' --xattrs --xattrs-include='*' -chf - -C %s
-p . \
+cmd = "tar --exclude='.git' --exclude='__pycache__' --xattrs
--xattrs-include='*' -chf - -C %s -p . \
| tar --xattrs --xattrs-include='*' -xf - -C %s" % (src, dest)
subprocess.check_output(cmd, shell=True, stderr=subprocess.STDOUT)
else:
@@ -259,7 +259,7 @@ def create_locked_sstate_cache(lockedsigs,
input_sstate_cache, output_sstate_cac
bb.note('Generating sstate-cache...')
nativelsbstring = d.getVar('NATIVELSBSTRING')
-bb.process.run("gen-lockedsig-cache %s %s %s %s %s" % (lockedsigs,
input_sstate_cache, output_sstate_cache, nativelsbstring, filterfile or ''))
+bb.process.run("PYTHONDONTWRITEBYTECODE=1 gen-lockedsig-cache %s %s %s %s
%s" % (lockedsigs, input_sstate_cache, output_sstate_cache, nativelsbstring,
filterfile or ''))
if fixedlsbstring and nativelsbstring != fixedlsbstring:
nativedir = output_sstate_cache + '/' + nativelsbstring
if os.path.isdir(nativedir):
@@ -286,7 +286,7 @@ def check_sstate_task_list(d, targets, filteroutfile,
cmdprefix='', cwd=None, lo
logparam = '-l %s' % logfile
else:
logparam = ''
-cmd = "%sBB_SETSCENE_ENFORCE=1 PSEUDO_DISABLED=1 oe-check-sstate %s -s -o
%s %s" % (cmdprefix, targets, filteroutfile, logparam)
+cmd = "%sPYTHONDONTWRITEBYTECODE=1 BB_SETSCENE_ENFORCE=1 PSEUDO_DISABLED=1
oe-check-sstate %s -s -o %s %s" % (cmdprefix, targets, filteroutfile, logparam)
env = dict(d.getVar('BB_ORIGENV', False))
env.pop('BUILDDIR', '')
env.pop('BBPATH', '')
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150159):
https://lists.openembedded.org/g/openembedded-core/message/150159
Mute This Topic: https://lists.openembedded.org/mt/81779867/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][dunfell 11/15] libtool: make sure autoheader run before autoconf
From: Mingli Yu
autoheader will update ../libtool-2.4.6/libltdl/config-h.in which
autoconf needs, so there comes a race sometimes as below:
| configure.ac:45: error: required file 'config-h.in' not found
| touch '../libtool-2.4.6/libltdl/config-h.in'
So make sure autoheader run before autoconf to avoid this race.
Signed-off-by: Mingli Yu
Signed-off-by: Richard Purdie
(cherry picked from commit d8451cbef5906b67756582fdfc44eb01ed3512fc)
Signed-off-by: Steve Sakoman
---
.../libtool/libtool-2.4.6.inc | 1 +
...-sure-autoheader-run-before-autoconf.patch | 35 +++
2 files changed, 36 insertions(+)
create mode 100644
meta/recipes-devtools/libtool/libtool/0001-Makefile.am-make-sure-autoheader-run-before-autoconf.patch
diff --git a/meta/recipes-devtools/libtool/libtool-2.4.6.inc
b/meta/recipes-devtools/libtool/libtool-2.4.6.inc
index 8e17b56d46..19a03d4733 100644
--- a/meta/recipes-devtools/libtool/libtool-2.4.6.inc
+++ b/meta/recipes-devtools/libtool/libtool-2.4.6.inc
@@ -21,6 +21,7 @@ SRC_URI = "${GNU_MIRROR}/libtool/libtool-${PV}.tar.gz \
file://unwind-opt-parsing.patch \
file://0001-libtool-Fix-support-for-NIOS2-processor.patch \
file://0001-libtool-Check-for-static-libs-for-internal-compiler-.patch \
+
file://0001-Makefile.am-make-sure-autoheader-run-before-autoconf.patch \
"
SRC_URI[md5sum] = "addf44b646ddb4e3919805aa88fa7c5e"
diff --git
a/meta/recipes-devtools/libtool/libtool/0001-Makefile.am-make-sure-autoheader-run-before-autoconf.patch
b/meta/recipes-devtools/libtool/libtool/0001-Makefile.am-make-sure-autoheader-run-before-autoconf.patch
new file mode 100644
index 00..2e9908725e
--- /dev/null
+++
b/meta/recipes-devtools/libtool/libtool/0001-Makefile.am-make-sure-autoheader-run-before-autoconf.patch
@@ -0,0 +1,35 @@
+From dfbbbd359e43e0a55fbea06f2647279ad8761cb9 Mon Sep 17 00:00:00 2001
+From: Mingli Yu
+Date: Wed, 24 Mar 2021 03:04:13 +
+Subject: [PATCH] Makefile.am: make sure autoheader run before autoconf
+
+autoheader will update ../libtool-2.4.6/libltdl/config-h.in which
+autoconf needs, so there comes a race sometimes as below:
+ | configure.ac:45: error: required file 'config-h.in' not found
+ | touch '../libtool-2.4.6/libltdl/config-h.in'
+
+So make sure autoheader run before autoconf to avoid this race.
+
+Upstream-Status: Submitted [libtool-patc...@gnu.org maillist]
+
+Signed-off-by: Mingli Yu
+---
+ Makefile.am | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/Makefile.am b/Makefile.am
+index 4142c90..fe1a9fc 100644
+--- a/Makefile.am
b/Makefile.am
+@@ -365,7 +365,7 @@ lt_configure_deps = $(lt_aclocal_m4) $(lt_aclocal_m4_deps)
+ $(lt_aclocal_m4): $(lt_aclocal_m4_deps)
+ $(AM_V_GEN)cd '$(srcdir)/$(ltdl_dir)' && $(ACLOCAL) -I ../m4
+
+-$(lt_configure): $(lt_configure_deps)
++$(lt_configure): $(lt_configure_deps) $(lt_config_h_in)
+ $(AM_V_GEN)cd '$(srcdir)/$(ltdl_dir)' && $(AUTOCONF)
+
+ $(lt_config_h_in): $(lt_configure_deps)
+--
+2.29.2
+
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150158):
https://lists.openembedded.org/g/openembedded-core/message/150158
Mute This Topic: https://lists.openembedded.org/mt/81779862/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][dunfell 10/15] bitbake.conf: correct description of HOSTTOOLS_DIR
From: "Robert P. J. Day"
HOSTTOOLS_DIR contains symlinks to host tools, not copies
Signed-off-by: Robert P. J. Day
Signed-off-by: Richard Purdie
(cherry picked from commit fb7692da7faa49b370680decbbaceaeb85b6889d)
Signed-off-by: Steve Sakoman
---
meta/conf/bitbake.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 697956eb49..76942d923b 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -480,7 +480,7 @@ export PATH
# Build utility info.
##
-# Directory where host tools are copied
+# Directory with symlinks to host tools used by build
HOSTTOOLS_DIR = "${TMPDIR}/hosttools"
# Tools needed to run builds with OE-Core
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150157):
https://lists.openembedded.org/g/openembedded-core/message/150157
Mute This Topic: https://lists.openembedded.org/mt/81779861/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][dunfell 08/15] run-postinsts: do not remove postinsts directory.
From: "Anton D. Kachalov"
When running on the systems having read-only rootfs backed by overlayfs,
removing the whole directory lead to create a special char device file
on the upperdir to reflect directory's removal. Once it is required to
upgrade the whole read-only image that might contain new postinsts scripts,
it will be impossible to run such scripts with a "deletion mark" file
on the overlayfs -- the whole directory will be marked as deleted regardless
new files in it.
Signed-off-by: Anton D. Kachalov
Signed-off-by: Richard Purdie
(cherry picked from commit 1a27b62b225ffeecec47c249a0b86cc54d775add)
Signed-off-by: Steve Sakoman
---
.../run-postinsts/run-postinsts/run-postinsts | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts
b/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts
index f84a7e18c8..95dccb9cae 100755
--- a/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts
+++ b/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts
@@ -72,12 +72,12 @@ exec_postinst_scriptlets() {
else
echo "ERROR: postinst $i failed."
[ "$POSTINST_LOGGING" = "1" ] && eval echo "ERROR:
postinst $i failed." $append_log
- remove_pi_dir=0
+ remove_rcsd_link=0
fi
done
}
-remove_pi_dir=1
+remove_rcsd_link=1
if $pm_installed; then
case $pm in
"ipk")
@@ -92,9 +92,7 @@ else
exec_postinst_scriptlets
fi
-# since all postinstalls executed successfully, remove the postinstalls
directory
-# and the rcS.d link
-if [ $remove_pi_dir = 1 ]; then
- rm -rf $pi_dir
+# since all postinstalls executed successfully, remove the rcS.d link
+if [ $remove_rcsd_link = 1 ]; then
remove_rcsd_link
fi
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150155):
https://lists.openembedded.org/g/openembedded-core/message/150155
Mute This Topic: https://lists.openembedded.org/mt/81779857/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][dunfell 09/15] documentation-audit.sh: Fix typo in specifying LICENSE_FLAGS_WHITELIST
From: Khem Raj
Signed-off-by: Khem Raj
Signed-off-by: Richard Purdie
(cherry picked from commit 410a45639d84a3d69a65133593da32062196dd59)
Signed-off-by: Steve Sakoman
---
scripts/contrib/documentation-audit.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/contrib/documentation-audit.sh
b/scripts/contrib/documentation-audit.sh
index 1191f57a8e..f436f9bae0 100755
--- a/scripts/contrib/documentation-audit.sh
+++ b/scripts/contrib/documentation-audit.sh
@@ -27,7 +27,7 @@ fi
echo "REMINDER: you need to build for MACHINE=qemux86 or you won't get useful
results"
echo "REMINDER: you need to set LICENSE_FLAGS_WHITELIST appropriately in
local.conf or "
-echo " you'll get false positives. For example, LICENSE_FLAGS_WHITELIST =
\"Commercial\""
+echo " you'll get false positives. For example, LICENSE_FLAGS_WHITELIST =
\"commercial\""
for pkg in `bitbake -s | awk '{ print \$1 }'`; do
if [[ "$pkg" == "Loading" || "$pkg" == "Loaded" ||
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150156):
https://lists.openembedded.org/g/openembedded-core/message/150156
Mute This Topic: https://lists.openembedded.org/mt/81779859/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][dunfell 07/15] cryptodev-module: fix build failure with kernel v5.10
From: Naveen Saini
zc.c:77:8: error: too many arguments to function 'get_user_pages_remote'
|77 | ret = get_user_pages_remote(task, mm,
| |^
Backported patch to fix it.
Signed-off-by: Naveen Saini
Signed-off-by: Steve Sakoman
---
.../cryptodev/cryptodev-module_1.10.bb| 1 +
.../0001-Fix-build-for-Linux-5.9-rc1.patch| 42 +++
2 files changed, 43 insertions(+)
create mode 100644
meta/recipes-kernel/cryptodev/files/0001-Fix-build-for-Linux-5.9-rc1.patch
diff --git a/meta/recipes-kernel/cryptodev/cryptodev-module_1.10.bb
b/meta/recipes-kernel/cryptodev/cryptodev-module_1.10.bb
index 6474599c45..e4f7d1e372 100644
--- a/meta/recipes-kernel/cryptodev/cryptodev-module_1.10.bb
+++ b/meta/recipes-kernel/cryptodev/cryptodev-module_1.10.bb
@@ -10,6 +10,7 @@ DEPENDS += "cryptodev-linux"
SRC_URI += " \
file://0001-Disable-installing-header-file-provided-by-another-p.patch \
file://0001-Fix-build-for-Linux-5.8-rc1.patch \
+file://0001-Fix-build-for-Linux-5.9-rc1.patch \
"
EXTRA_OEMAKE='KERNEL_DIR="${STAGING_KERNEL_DIR}" PREFIX="${D}"'
diff --git
a/meta/recipes-kernel/cryptodev/files/0001-Fix-build-for-Linux-5.9-rc1.patch
b/meta/recipes-kernel/cryptodev/files/0001-Fix-build-for-Linux-5.9-rc1.patch
new file mode 100644
index 00..cf1c04df9e
--- /dev/null
+++ b/meta/recipes-kernel/cryptodev/files/0001-Fix-build-for-Linux-5.9-rc1.patch
@@ -0,0 +1,42 @@
+From 2f5e08aebf9229599aae7f25db752f74221cd71d Mon Sep 17 00:00:00 2001
+From: Joan Bruguera
+Date: Fri, 14 Aug 2020 00:13:38 +0200
+Subject: [PATCH] Fix build for Linux 5.9-rc1
+
+See also:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=64019a2e467a288a16b65ab55ddcbf58c1b00187
+
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bce617edecada007aee8610fbe2c14d10b8de2f6
+
https://lore.kernel.org/lkml/CAHk-=wj_v2tps2qrmn20_w0ojf9xqnh52xsga42s-zj8y+g...@mail.gmail.com/
+
+Signed-off-by: Joan Bruguera
+
+Upstream-Status: Backport
[https://github.com/cryptodev-linux/cryptodev-linux/commit/2f5e08aebf9229599aae7f25db752f74221cd71d]
+
+Signed-off-by: Naveen Saini
+
+---
+ zc.c | 6 +-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/zc.c b/zc.c
+index a560db5..fdf7da1 100644
+--- a/zc.c
b/zc.c
+@@ -76,10 +76,14 @@ int __get_userbuf(uint8_t __user *addr, uint32_t len, int
write,
+ ret = get_user_pages_remote(task, mm,
+ (unsigned long)addr, pgcount, write ? FOLL_WRITE : 0,
+ pg, NULL);
+-#else
++#elif (LINUX_VERSION_CODE < KERNEL_VERSION(5, 9, 0))
+ ret = get_user_pages_remote(task, mm,
+ (unsigned long)addr, pgcount, write ? FOLL_WRITE : 0,
+ pg, NULL, NULL);
++#else
++ ret = get_user_pages_remote(mm,
++ (unsigned long)addr, pgcount, write ? FOLL_WRITE : 0,
++ pg, NULL, NULL);
+ #endif
+ #if (LINUX_VERSION_CODE < KERNEL_VERSION(5, 8, 0))
+ up_read(>mmap_sem);
+--
+2.17.1
+
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150154):
https://lists.openembedded.org/g/openembedded-core/message/150154
Mute This Topic: https://lists.openembedded.org/mt/81779853/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][dunfell 06/15] cryptodev-module: Backport a patch to fix build failure with kernel v5.8
From: He Zhe
Fix the following build failure with linux-yocto-dev
zc.c:61:17: error: 'struct mm_struct' has no member named 'mmap_sem';
did you mean 'mmap_base'?
61 | down_read(>mmap_sem);
| ^~~~
| mmap_base
zc.c:77:15: error: 'struct mm_struct' has no member named 'mmap_sem';
did you mean 'mmap_base'?
77 | up_read(>mmap_sem);
| ^~~~
| mmap_base
(From OE-Core rev: fe668065ad7ec83aadfa36fe6ba1ced3db2e3cad)
Signed-off-by: He Zhe
Signed-off-by: Richard Purdie
Signed-off-by: Naveen Saini
Signed-off-by: Steve Sakoman
---
.../cryptodev/cryptodev-module_1.10.bb| 1 +
.../0001-Fix-build-for-Linux-5.8-rc1.patch| 49 +++
2 files changed, 50 insertions(+)
create mode 100644
meta/recipes-kernel/cryptodev/files/0001-Fix-build-for-Linux-5.8-rc1.patch
diff --git a/meta/recipes-kernel/cryptodev/cryptodev-module_1.10.bb
b/meta/recipes-kernel/cryptodev/cryptodev-module_1.10.bb
index 552eb6abaa..6474599c45 100644
--- a/meta/recipes-kernel/cryptodev/cryptodev-module_1.10.bb
+++ b/meta/recipes-kernel/cryptodev/cryptodev-module_1.10.bb
@@ -9,6 +9,7 @@ DEPENDS += "cryptodev-linux"
SRC_URI += " \
file://0001-Disable-installing-header-file-provided-by-another-p.patch \
+file://0001-Fix-build-for-Linux-5.8-rc1.patch \
"
EXTRA_OEMAKE='KERNEL_DIR="${STAGING_KERNEL_DIR}" PREFIX="${D}"'
diff --git
a/meta/recipes-kernel/cryptodev/files/0001-Fix-build-for-Linux-5.8-rc1.patch
b/meta/recipes-kernel/cryptodev/files/0001-Fix-build-for-Linux-5.8-rc1.patch
new file mode 100644
index 00..02c721a4f3
--- /dev/null
+++ b/meta/recipes-kernel/cryptodev/files/0001-Fix-build-for-Linux-5.8-rc1.patch
@@ -0,0 +1,49 @@
+From 9e765068582aae3696520346a7500322ca6cc2de Mon Sep 17 00:00:00 2001
+From: Joan Bruguera
+Date: Sat, 13 Jun 2020 19:46:44 +0200
+Subject: [PATCH] Fix build for Linux 5.8-rc1
+
+See also:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9740ca4e95b43b91a4a848694a20d01ba6818f7b
+
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=da1c55f1b272f4bd54671d459b39ea7b54944ef9
+
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d8ed45c5dcd455fc5848d47f86883a1b872ac0d0
+
+Signed-off-by: Joan Bruguera
+
+Upstream-Status: Backport [9e765068582aae3696520346a7500322ca6cc2de]
+
+Signed-off-by: He Zhe
+---
+ zc.c | 8
+ 1 file changed, 8 insertions(+)
+
+diff --git a/zc.c b/zc.c
+index ae464ff..2c286bb 100644
+--- a/zc.c
b/zc.c
+@@ -58,7 +58,11 @@ int __get_userbuf(uint8_t __user *addr, uint32_t len, int
write,
+ return 0;
+ }
+
++#if (LINUX_VERSION_CODE < KERNEL_VERSION(5, 8, 0))
+ down_read(>mmap_sem);
++#else
++ mmap_read_lock(mm);
++#endif
+ #if (LINUX_VERSION_CODE < KERNEL_VERSION(4, 6, 0))
+ ret = get_user_pages(task, mm,
+ (unsigned long)addr, pgcount, write, 0, pg, NULL);
+@@ -74,7 +78,11 @@ int __get_userbuf(uint8_t __user *addr, uint32_t len, int
write,
+ (unsigned long)addr, pgcount, write ? FOLL_WRITE : 0,
+ pg, NULL, NULL);
+ #endif
++#if (LINUX_VERSION_CODE < KERNEL_VERSION(5, 8, 0))
+ up_read(>mmap_sem);
++#else
++ mmap_read_unlock(mm);
++#endif
+ if (ret != pgcount)
+ return -EINVAL;
+
+--
+2.17.1
+
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150153):
https://lists.openembedded.org/g/openembedded-core/message/150153
Mute This Topic: https://lists.openembedded.org/mt/81779852/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][dunfell 05/15] linux-firmware: Fix packaging
From: Michael Trensch
Upstream directory layout has changed after update in commit
3c2f8b750ab9c53773fb5a9a1a874e475740b4ee, resulting in some package to pull in
linux-firmware base package.
This may cause an image size increase of approximately 700MB.
See log.do_packaging:
DEBUG: linux-firmware-bcm43340 contains dangling link
/lib/firmware/cypress/cyfmac43340-sdio.bin
DEBUG: target found in linux-firmware
DEBUG: linux-firmware-bcm43362 contains dangling link
/lib/firmware/cypress/cyfmac43362-sdio.bin
DEBUG: target found in linux-firmware
DEBUG: linux-firmware-bcm4339 contains dangling link
/lib/firmware/cypress/cyfmac4339-sdio.bin
DEBUG: target found in linux-firmware
DEBUG: linux-firmware-bcm43430 contains dangling link
/lib/firmware/cypress/cyfmac43430-sdio.clm_blob
DEBUG: target found in linux-firmware
DEBUG: linux-firmware-bcm43430 contains dangling link
/lib/firmware/cypress/cyfmac43430-sdio.bin
DEBUG: target found in linux-firmware
DEBUG: linux-firmware-bcm43455 contains dangling link
/lib/firmware/cypress/cyfmac43455-sdio.bin
DEBUG: target found in linux-firmware
DEBUG: linux-firmware-bcm43455 contains dangling link
/lib/firmware/cypress/cyfmac43455-sdio.clm_blob
DEBUG: target found in linux-firmware
DEBUG: linux-firmware-bcm4354 contains dangling link
/lib/firmware/cypress/cyfmac4354-sdio.bin
DEBUG: target found in linux-firmware
DEBUG: linux-firmware-bcm4356 contains dangling link
/lib/firmware/cypress/cyfmac4356-sdio.bin
DEBUG: target found in linux-firmware
DEBUG: linux-firmware-bcm4356-pcie contains dangling link
/lib/firmware/cypress/cyfmac4356-pcie.clm_blob
DEBUG: target found in linux-firmware
DEBUG: linux-firmware-bcm4356-pcie contains dangling link
/lib/firmware/cypress/cyfmac4356-pcie.bin
DEBUG: target found in linux-firmware
DEBUG: linux-firmware-bcm43570 contains dangling link
/lib/firmware/cypress/cyfmac43570-pcie.bin
DEBUG: target found in linux-firmware
DEBUG: linux-firmware-bcm4373 contains dangling link
/lib/firmware/cypress/cyfmac4373-sdio.bin
DEBUG: target found in linux-firmware
DEBUG: linux-firmware-netronome contains dangling link
/lib/firmware/netronome/nic/nic_AMDA0099-0001_2x10.nffw
DEBUG: target found in linux-firmware
DEBUG: linux-firmware-netronome contains dangling link
/lib/firmware/netronome/nic/nic_AMDA0099-0001_2x25.nffw
DEBUG: target found in linux-firmware
DEBUG: linux-firmware-netronome contains dangling link
/lib/firmware/netronome/nic/nic_AMDA0081-0001_4x10.nffw
DEBUG: target found in linux-firmware
DEBUG: linux-firmware-netronome contains dangling link
/lib/firmware/netronome/nic/nic_AMDA0097-0001_8x10.nffw
DEBUG: target found in linux-firmware
DEBUG: linux-firmware-netronome contains dangling link
/lib/firmware/netronome/nic/nic_AMDA0099-0001_1x10_1x25.nffw
DEBUG: target found in linux-firmware
DEBUG: linux-firmware-netronome contains dangling link
/lib/firmware/netronome/nic/nic_AMDA0097-0001_2x40.nffw
DEBUG: target found in linux-firmware
DEBUG: linux-firmware-netronome contains dangling link
/lib/firmware/netronome/nic/nic_AMDA0096-0001_2x10.nffw
DEBUG: target found in linux-firmware
DEBUG: linux-firmware-netronome contains dangling link
/lib/firmware/netronome/nic/nic_AMDA0097-0001_4x10_1x40.nffw
DEBUG: target found in linux-firmware
DEBUG: linux-firmware-netronome contains dangling link
/lib/firmware/netronome/nic/nic_AMDA0081-0001_1x40.nffw
DEBUG: target found in linux-firmware
Signed-off-by: Michael Trensch
Signed-off-by: Richard Purdie
(cherry picked from commit cd273c611b03bd5972da8bf4accaba247f7c9c62)
Signed-off-by: Steve Sakoman
---
.../linux-firmware/linux-firmware_20210208.bb | 41 +++
1 file changed, 32 insertions(+), 9 deletions(-)
diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20210208.bb
b/meta/recipes-kernel/linux-firmware/linux-firmware_20210208.bb
index 1881a8e065..78856cbf66 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_20210208.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20210208.bb
@@ -496,6 +496,13 @@ FILES_${PN}-netronome = " \
${nonarch_base_libdir}/firmware/netronome/nic_AMDA0096*.nffw \
${nonarch_base_libdir}/firmware/netronome/nic_AMDA0097*.nffw \
${nonarch_base_libdir}/firmware/netronome/nic_AMDA0099*.nffw \
+ ${nonarch_base_libdir}/firmware/netronome/nic_AMDA0058-0011_2x40.nffw \
+ ${nonarch_base_libdir}/firmware/netronome/nic_AMDA0058-0012_2x40.nffw \
+ ${nonarch_base_libdir}/firmware/netronome/nic_AMDA0078-0011_1x100.nffw \
+ ${nonarch_base_libdir}/firmware/netronome/bpf \
+ ${nonarch_base_libdir}/firmware/netronome/flower \
+ ${nonarch_base_libdir}/firmware/netronome/nic \
+ ${nonarch_base_libdir}/firmware/netronome/nic-sriov \
"
RDEPENDS_${PN}-netronome += "${PN}-netronome-license"
@@ -622,7 +629,9 @@ FILES_${PN}-bcm4329 =
"${nonarch_base_libdir}/firmware/brcm/brcmfmac4329-sdio.bi
FILES_${PN}-bcm4330 =
"${nonarch_base_libdir}/firmware/brcm/brcmfmac4330-sdio.*"
FILES_${PN}-bcm4334 =
[OE-core][dunfell 04/15] linux-yocto/5.4: update to v5.4.107
From: Bruce Ashfield Updating linux-yocto/5.4 to the latest korg -stable release that comprises the following commits: a65e78863443 Linux 5.4.107 5161cc4350de net: dsa: b53: Support setting learning on port ebeefdc3d8ee net: dsa: tag_mtk: fix 802.1ad VLAN egress 6c3d86e6ffde crypto: x86/aes-ni-xts - use direct calls to and 4-way stride ae69c97bb76e crypto: aesni - Use TEST %reg,%reg instead of CMP $0,%reg eeb0899e0073 crypto: x86 - Regularize glue function prototypes 187ae0463653 fuse: fix live lock in fuse_iget() 28e53acd3065 drm/i915/gvt: Fix vfio_edid issue for BXT/APL 5a7c72ffb412 drm/i915/gvt: Fix port number for BDW on EDID region setup 4ab29329668d drm/i915/gvt: Fix virtual display setup for BXT/APL e46f72e1f27c drm/i915/gvt: Fix mmio handler break on BXT/APL. 8cd68991b836 drm/i915/gvt: Set SNOOP for PAT3 on BXT/APL to workaround GPU BB hang 50f83ffc58ab btrfs: scrub: Don't check free space before marking a block group RO 591ea83fd2ce bpf, selftests: Fix up some test_verifier cases for unprivileged 4e4c85404a23 bpf: Add sanity check for upper ptr_limit 524471df8fa9 bpf: Simplify alu_limit masking for pointer arithmetic 2da0540739e4 bpf: Fix off-by-one for area size in creating mask to left ea8fb45eaac1 bpf: Prohibit alu ops for pointer types not defining ptr_limit 010c5bee66bd KVM: arm64: nvhe: Save the SPE context early 0437de26e28d Linux 5.4.106 b802b6ef28d6 xen/events: avoid handling the same event on two cpus at the same time 92aefc62f483 xen/events: don't unmask an event channel when an eoi is pending 43d0b82bb45c xen/events: reset affinity of 2-level event when tearing it down 38563c1ff081 KVM: arm64: Reject VM creation when the default IPA size is unsupported da2e37b55d4c KVM: arm64: Ensure I-cache isolation between vcpus of a same VM 4e2156c0d37b nvme: release namespace head reference on error eb565f052b3e nvme: unlink head after removing last namespace 4535fb9ec5fd KVM: arm64: Fix exclusive limit for IPA size e28b19ca2aeb x86/unwind/orc: Disable KASAN checking in the ORC unwinder, part 2 c0e0ab60d0b1 binfmt_misc: fix possible deadlock in bm_register_write 106fea9ad246 powerpc/64s: Fix instruction encoding for lis in ppc_function_entry() 907f7f2cf0ff sched/membarrier: fix missing local execution of ipi_sync_rq_state() 2306580a95b7 zram: fix return value on writeback_store 29e28a134a49 include/linux/sched/mm.h: use rcu_dereference in in_vfork() 99f1960cae4f stop_machine: mark helpers __always_inline aaf92d0538d2 hrtimer: Update softirq_expires_next correctly after __hrtimer_get_next_event() 88c79851b82d arm64: mm: use a 48-bit ID map when possible on 52-bit VA builds 73aa6f93e1e9 configfs: fix a use-after-free in __configfs_open_file babd55002dd4 block: rsxx: fix error return code of rsxx_pci_probe() 41deefab452a NFSv4.2: fix return value of _nfs4_get_security_label() 86954a52d829 NFS: Don't gratuitously clear the inode cache when lookup failed d29f9aa6a8b2 NFS: Don't revalidate the directory permissions on a lookup failure d5a69ed75931 SUNRPC: Set memalloc_nofs_save() for sync tasks 9c9ea7ac18b2 arm64/mm: Fix pfn_valid() for ZONE_DEVICE based memory 19bb2a20710d sh_eth: fix TRSCER mask for R7S72100 c3c1defad2dd staging: comedi: pcl818: Fix endian problem for AI command data c5916897a6e1 staging: comedi: pcl711: Fix endian problem for AI command data 7d8ec7bef320 staging: comedi: me4000: Fix endian problem for AI command data e70294943c89 staging: comedi: dmm32at: Fix endian problem for AI command data 47a2af64eea3 staging: comedi: das800: Fix endian problem for AI command data 0f2522ec71b6 staging: comedi: das6402: Fix endian problem for AI command data e91490b9edb9 staging: comedi: adv_pci1710: Fix endian problem for AI command data 4d6505edee5a staging: comedi: addi_apci_1500: Fix endian problem for command sample f258c1c26f64 staging: comedi: addi_apci_1032: Fix endian problem for COS sample e644fc4ab7bb staging: rtl8192e: Fix possible buffer overflow in _rtl92e_wx_set_scan 8f586a59829b staging: rtl8712: Fix possible buffer overflow in r8712_sitesurvey_cmd 9fe42273b2c6 staging: ks7010: prevent buffer overflow in ks_wlan_set_scan() ab42f28d5f34 staging: rtl8188eu: fix potential memory corruption in rtw_check_beacon_data() 1a866057e970 staging: rtl8712: unterminated string leads to read overflow da5abe369b03 staging: rtl8188eu: prevent ->ssid overflow in rtw_wx_set_scan() a311b6a7f099 staging: rtl8192u: fix ->ssid overflow in r8192_wx_set_scan() e4b52c7cbaaf misc: fastrpc: restrict user apps from sending kernel RPC messages 9009b59dfd5f misc/pvpanic: Export module FDT device table 0a58a400a93b usbip: fix vudc usbip_sockfd_store races leading to gpf 8a50dda5243e usbip: fix vhci_hcd attach_store() races
[OE-core][dunfell 03/15] openssl: update to 1.1.1k to fix CVE-2021-3450 and CVE-2021-3449
From: Mikko Rapeli
Only security issues fixed in this release according to
https://www.openssl.org/news/cl111.txt
Signed-off-by: Mikko Rapeli
Signed-off-by: Steve Sakoman
---
.../openssl/{openssl_1.1.1j.bb => openssl_1.1.1k.bb}| 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-connectivity/openssl/{openssl_1.1.1j.bb =>
openssl_1.1.1k.bb} (98%)
diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1j.bb
b/meta/recipes-connectivity/openssl/openssl_1.1.1k.bb
similarity index 98%
rename from meta/recipes-connectivity/openssl/openssl_1.1.1j.bb
rename to meta/recipes-connectivity/openssl/openssl_1.1.1k.bb
index f054d2fdba..5f281197c9 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.1.1j.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.1.1k.bb
@@ -23,7 +23,7 @@ SRC_URI_append_class-nativesdk = " \
file://environment.d-openssl.sh \
"
-SRC_URI[sha256sum] =
"aaf2fcb575cdf6491b98ab4829abf78a3dec8402b8b81efc8f23c00d443981bf"
+SRC_URI[sha256sum] =
"892a0875b9872acd04a9fde79b1f943075d5ea162415de3047c327df33fbaee5"
inherit lib_package multilib_header multilib_script ptest
MULTILIB_SCRIPTS = "${PN}-bin:${bindir}/c_rehash"
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150150):
https://lists.openembedded.org/g/openembedded-core/message/150150
Mute This Topic: https://lists.openembedded.org/mt/81779840/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][dunfell 02/15] git: fix CVE-2021-21300
From: Minjae Kim checkout: fix bug that makes checkout follow symlinks in leading path Upstream-Status: Acepted [https://github.com/git/git/commit/684dd4c2b414bcf648505e74498a608f28de4592] CVE: CVE-2021-21300 Signed-off-by: Minjae Kim Signed-off-by: Steve Sakoman --- .../git/files/CVE-2021-21300.patch| 305 ++ meta/recipes-devtools/git/git.inc | 4 +- 2 files changed, 308 insertions(+), 1 deletion(-) create mode 100644 meta/recipes-devtools/git/files/CVE-2021-21300.patch diff --git a/meta/recipes-devtools/git/files/CVE-2021-21300.patch b/meta/recipes-devtools/git/files/CVE-2021-21300.patch new file mode 100644 index 00..9206f711cf --- /dev/null +++ b/meta/recipes-devtools/git/files/CVE-2021-21300.patch @@ -0,0 +1,305 @@ +From 0e9cef2414f0df3fa5b9b56ff9072aa122bef29c Mon Sep 17 00:00:00 2001 +From: Minjae Kim +Date: Sat, 27 Mar 2021 15:18:46 +0900 +Subject: [PATCH] checkout: fix bug that makes checkout follow symlinks in + leading path + +Before checking out a file, we have to confirm that all of its leading +components are real existing directories. And to reduce the number of +lstat() calls in this process, we cache the last leading path known to +contain only directories. However, when a path collision occurs (e.g. +when checking out case-sensitive files in case-insensitive file +systems), a cached path might have its file type changed on disk, +leaving the cache on an invalid state. Normally, this doesn't bring +any bad consequences as we usually check out files in index order, and +therefore, by the time the cached path becomes outdated, we no longer +need it anyway (because all files in that directory would have already +been written). + +But, there are some users of the checkout machinery that do not always +follow the index order. In particular: checkout-index writes the paths +in the same order that they appear on the CLI (or stdin); and the +delayed checkout feature -- used when a long-running filter process +replies with "status=delayed" -- postpones the checkout of some entries, +thus modifying the checkout order. + +When we have to check out an out-of-order entry and the lstat() cache is +invalid (due to a previous path collision), checkout_entry() may end up +using the invalid data and thrusting that the leading components are +real directories when, in reality, they are not. In the best case +scenario, where the directory was replaced by a regular file, the user +will get an error: "fatal: unable to create file 'foo/bar': Not a +directory". But if the directory was replaced by a symlink, checkout +could actually end up following the symlink and writing the file at a +wrong place, even outside the repository. Since delayed checkout is +affected by this bug, it could be used by an attacker to write +arbitrary files during the clone of a maliciously crafted repository. + +Some candidate solutions considered were to disable the lstat() cache +during unordered checkouts or sort the entries before passing them to +the checkout machinery. But both ideas include some performance penalty +and they don't future-proof the code against new unordered use cases. + +Instead, we now manually reset the lstat cache whenever we successfully +remove a directory. Note: We are not even checking whether the directory +was the same as the lstat cache points to because we might face a +scenario where the paths refer to the same location but differ due to +case folding, precomposed UTF-8 issues, or the presence of `..` +components in the path. Two regression tests, with case-collisions and +utf8-collisions, are also added for both checkout-index and delayed +checkout. + +Note: to make the previously mentioned clone attack unfeasible, it would +be sufficient to reset the lstat cache only after the remove_subtree() +call inside checkout_entry(). This is the place where we would remove a +directory whose path collides with the path of another entry that we are +currently trying to check out (possibly a symlink). However, in the +interest of a thorough fix that does not leave Git open to +similar-but-not-identical attack vectors, we decided to intercept +all `rmdir()` calls in one fell swoop. + +This addresses CVE-2021-21300. + +Co-authored-by: Johannes Schindelin +Signed-off-by: Matheus Tavares + +Upstream-Status: Acepted [https://github.com/git/git/commit/684dd4c2b414bcf648505e74498a608f28de4592] +CVE: CVE-2021-21300 +Signed-off-by: Minjae Kim +--- + cache.h | 1 + + compat/mingw.c | 2 ++ + git-compat-util.h | 5 + + symlinks.c | 25 + + t/t0021-conversion.sh | 39 + t/t0021/rot13-filter.pl | 21 ++--- + t/t2006-checkout-index-basic.sh | 40 + + 7 files changed, 130 insertions(+), 3 deletions(-) + +diff --git a/cache.h b/cache.h +index 04cabaa..dda373f 100644 +---
[OE-core][dunfell 01/15] connman: fix CVE-2021-26675, CVE-2021-26676
From: Catalin Enache
A stack-based buffer overflow in dnsproxy in ConnMan before 1.39
could be used by network adjacent attackers to execute code.
gdhcp in ConnMan before 1.39 could be used by network-adjacent.
attackers to leak sensitive stack information, allowing further
exploitation of bugs in gdhcp.
References:
https://nvd.nist.gov/vuln/detail/CVE-2021-26675
https://nvd.nist.gov/vuln/detail/CVE-2021-26676
Upstream patches:
https://git.kernel.org/pub/scm/network/connman/connman.git/commit/?id=e4079a20f617a4b076af503f6e4e8b0304c9f2cb
https://git.kernel.org/pub/scm/network/connman/connman.git/commit/?id=58d397ba74873384aee449690a9070bacd5676fa
https://git.kernel.org/pub/scm/network/connman/connman.git/commit/?id=a74524b3e3fad81b0fd1084ffdf9f2ea469cd9b1
Signed-off-by: Catalin Enache
Signed-off-by: Randy MacLeod
Signed-off-by: Steve Sakoman
---
.../connman/connman/CVE-2021-26675.patch | 62 +
.../connman/connman/CVE-2021-26676-0001.patch | 231 ++
.../connman/connman/CVE-2021-26676-0002.patch | 33 +++
.../connman/connman_1.37.bb | 3 +
4 files changed, 329 insertions(+)
create mode 100644
meta/recipes-connectivity/connman/connman/CVE-2021-26675.patch
create mode 100644
meta/recipes-connectivity/connman/connman/CVE-2021-26676-0001.patch
create mode 100644
meta/recipes-connectivity/connman/connman/CVE-2021-26676-0002.patch
diff --git a/meta/recipes-connectivity/connman/connman/CVE-2021-26675.patch
b/meta/recipes-connectivity/connman/connman/CVE-2021-26675.patch
new file mode 100644
index 00..2648a832ca
--- /dev/null
+++ b/meta/recipes-connectivity/connman/connman/CVE-2021-26675.patch
@@ -0,0 +1,62 @@
+From e4079a20f617a4b076af503f6e4e8b0304c9f2cb Mon Sep 17 00:00:00 2001
+From: Colin Wee
+Date: Thu, 28 Jan 2021 19:41:53 +0100
+Subject: [PATCH] dnsproxy: Add length checks to prevent buffer overflow
+
+Fixes: CVE-2021-26675
+
+Upstream-Status: Backport
+CVE: CVE-2021-26675
+
+Reference to upstream patch:
+https://git.kernel.org/pub/scm/network/connman/connman.git/commit/?id=e4079a20f617a4b076af503f6e4e8b0304c9f2cb
+
+Signed-off-by: Catalin Enache
+---
+ src/dnsproxy.c | 14 +++---
+ 1 file changed, 11 insertions(+), 3 deletions(-)
+
+diff --git a/src/dnsproxy.c b/src/dnsproxy.c
+index a7bf87a1..4f5c897f 100644
+--- a/src/dnsproxy.c
b/src/dnsproxy.c
+@@ -1767,6 +1767,7 @@ static char *uncompress(int16_t field_count, char
*start, char *end,
+ char **uncompressed_ptr)
+ {
+ char *uptr = *uncompressed_ptr; /* position in result buffer */
++ char * const uncomp_end = uncompressed + uncomp_len - 1;
+
+ debug("count %d ptr %p end %p uptr %p", field_count, ptr, end, uptr);
+
+@@ -1787,12 +1788,15 @@ static char *uncompress(int16_t field_count, char
*start, char *end,
+* tmp buffer.
+*/
+
+- ulen = strlen(name);
+- strncpy(uptr, name, uncomp_len - (uptr - uncompressed));
+-
+ debug("pos %d ulen %d left %d name %s", pos, ulen,
+ (int)(uncomp_len - (uptr - uncompressed)), uptr);
+
++ ulen = strlen(name);
++ if ((uptr + ulen + 1) > uncomp_end) {
++ goto out;
++ }
++ strncpy(uptr, name, uncomp_len - (uptr - uncompressed));
++
+ uptr += ulen;
+ *uptr++ = '\0';
+
+@@ -1802,6 +1806,10 @@ static char *uncompress(int16_t field_count, char
*start, char *end,
+* We copy also the fixed portion of the result (type, class,
+* ttl, address length and the address)
+*/
++ if ((uptr + NS_RRFIXEDSZ) > uncomp_end) {
++ debug("uncompressed data too large for buffer");
++ goto out;
++ }
+ memcpy(uptr, ptr, NS_RRFIXEDSZ);
+
+ dns_type = uptr[0] << 8 | uptr[1];
+--
+2.17.1
diff --git
a/meta/recipes-connectivity/connman/connman/CVE-2021-26676-0001.patch
b/meta/recipes-connectivity/connman/connman/CVE-2021-26676-0001.patch
new file mode 100644
index 00..4104e4bfc6
--- /dev/null
+++ b/meta/recipes-connectivity/connman/connman/CVE-2021-26676-0001.patch
@@ -0,0 +1,231 @@
+From 58d397ba74873384aee449690a9070bacd5676fa Mon Sep 17 00:00:00 2001
+From: Colin Wee
+Date: Thu, 28 Jan 2021 19:39:14 +0100
+Subject: [PATCH] gdhcp: Avoid reading invalid data in dhcp_get_option
+
+Upstream-Status: Backport
+CVE: CVE-2021-26676
+
+Reference to upstream patch:
+https://git.kernel.org/pub/scm/network/connman/connman.git/commit/?id=58d397ba74873384aee449690a9070bacd5676fa
+
+Signed-off-by: Catalin Enache
+---
+ gdhcp/client.c | 20 +++-
+ gdhcp/common.c | 24 +++-
+ gdhcp/common.h | 2 +-
+ gdhcp/server.c | 12 +++-
+ 4 files changed, 38 insertions(+), 20 deletions(-)
+
+diff --git a/gdhcp/client.c b/gdhcp/client.c
+index 09dfe5ec..6a5613e7 100644
[OE-core][dunfell 00/15] Patch review
Please review this next set of patches for dunfell and have comments back by
end of day Monday.
Passed a-full on autobuilder:
https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/2019
The following changes since commit 707036d4ec12ef1a260adcef78627b26e32e6540:
linux-yocto/5.4: update to v5.4.105 (2021-03-24 04:30:32 -1000)
are available in the Git repository at:
git://git.openembedded.org/openembedded-core-contrib stable/dunfell-nut
http://cgit.openembedded.org/openembedded-core-contrib/log/?h=stable/dunfell-nut
Anton D. Kachalov (1):
run-postinsts: do not remove postinsts directory.
Bruce Ashfield (1):
linux-yocto/5.4: update to v5.4.107
Catalin Enache (1):
connman: fix CVE-2021-26675, CVE-2021-26676
Christopher Larson (2):
buildhistory: add missing vardepsexcludes
image,populate_sdk_base: move 'func' flag setting for sdk command vars
He Zhe (1):
cryptodev-module: Backport a patch to fix build failure with kernel
v5.8
Khem Raj (1):
documentation-audit.sh: Fix typo in specifying LICENSE_FLAGS_WHITELIST
Mark Hatle (1):
populate_sdk_ext: Avoid copying and producing .pyc files
Michael Trensch (1):
linux-firmware: Fix packaging
Mikko Rapeli (1):
openssl: update to 1.1.1k to fix CVE-2021-3450 and CVE-2021-3449
Mingli Yu (1):
libtool: make sure autoheader run before autoconf
Minjae Kim (1):
git: fix CVE-2021-21300
Naveen Saini (1):
cryptodev-module: fix build failure with kernel v5.10
Robert P. J. Day (2):
bitbake.conf: correct description of HOSTTOOLS_DIR
packagegroups: delete useless "PROVIDES" lines
meta/classes/buildhistory.bbclass | 3 +
meta/classes/image.bbclass| 2 +-
meta/classes/populate_sdk_base.bbclass| 7 +
meta/classes/populate_sdk_ext.bbclass | 4 +-
meta/conf/bitbake.conf| 2 +-
meta/lib/oe/copy_buildsystem.py | 6 +-
.../connman/connman/CVE-2021-26675.patch | 62
.../connman/connman/CVE-2021-26676-0001.patch | 231 +
.../connman/connman/CVE-2021-26676-0002.patch | 33 ++
.../connman/connman_1.37.bb | 3 +
.../{openssl_1.1.1j.bb => openssl_1.1.1k.bb} | 2 +-
.../packagegroups/packagegroup-base.bb| 1 -
.../packagegroups/packagegroup-core-nfs.bb| 1 -
.../git/files/CVE-2021-21300.patch| 305 ++
meta/recipes-devtools/git/git.inc | 4 +-
.../libtool/libtool-2.4.6.inc | 1 +
...-sure-autoheader-run-before-autoconf.patch | 35 ++
.../run-postinsts/run-postinsts/run-postinsts | 10 +-
.../cryptodev/cryptodev-module_1.10.bb| 2 +
.../0001-Fix-build-for-Linux-5.8-rc1.patch| 49 +++
.../0001-Fix-build-for-Linux-5.9-rc1.patch| 42 +++
.../linux-firmware/linux-firmware_20210208.bb | 41 ++-
.../linux/linux-yocto-rt_5.4.bb | 6 +-
.../linux/linux-yocto-tiny_5.4.bb | 8 +-
meta/recipes-kernel/linux/linux-yocto_5.4.bb | 22 +-
scripts/contrib/documentation-audit.sh| 2 +-
26 files changed, 840 insertions(+), 44 deletions(-)
create mode 100644
meta/recipes-connectivity/connman/connman/CVE-2021-26675.patch
create mode 100644
meta/recipes-connectivity/connman/connman/CVE-2021-26676-0001.patch
create mode 100644
meta/recipes-connectivity/connman/connman/CVE-2021-26676-0002.patch
rename meta/recipes-connectivity/openssl/{openssl_1.1.1j.bb =>
openssl_1.1.1k.bb} (98%)
create mode 100644 meta/recipes-devtools/git/files/CVE-2021-21300.patch
create mode 100644
meta/recipes-devtools/libtool/libtool/0001-Makefile.am-make-sure-autoheader-run-before-autoconf.patch
create mode 100644
meta/recipes-kernel/cryptodev/files/0001-Fix-build-for-Linux-5.8-rc1.patch
create mode 100644
meta/recipes-kernel/cryptodev/files/0001-Fix-build-for-Linux-5.9-rc1.patch
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150147):
https://lists.openembedded.org/g/openembedded-core/message/150147
Mute This Topic: https://lists.openembedded.org/mt/81779827/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH] bitbake.conf: Limit the number of OpenMP threads
Limits the number of OpenMP threads to match BB_NUMBER_THREADS. This
prevents OpenMP (libgomp in particular) from falling back to using all
the available CPUs, which behaves poorly when attempting to limit build
usage, especially when attempting to build in a container.
Signed-off-by: Joshua Watt
---
meta/conf/bitbake.conf | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index d87d7cafb6..385fc7dd55 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -810,6 +810,10 @@ XZ_THREADS ?= "${@oe.utils.cpu_count(at_least=2)}"
XZ_DEFAULTS ?= "--memlimit=${XZ_MEMLIMIT} --threads=${XZ_THREADS}"
XZ_DEFAULTS[vardepsexclude] += "XZ_MEMLIMIT XZ_THREADS"
+# Limit the number of threads that OpenMP libraries will use. Otherwise they
+# may fallback to using all CPUs
+export OMP_NUM_THREADS = "${BB_NUMBER_THREADS}"
+
##
# Magic Cookie for SANITY CHECK
##
@@ -891,7 +895,8 @@ BB_HASHEXCLUDE_COMMON ?= "TMPDIR FILE PATH PWD BB_TASKHASH
BBPATH BBSERVER DL_DI
WARN_QA ERROR_QA WORKDIR STAMPCLEAN PKGDATA_DIR BUILD_ARCH SSTATE_PKGARCH \
BB_WORKERCONTEXT BB_LIMITEDDEPS BB_UNIHASH extend_recipe_sysroot
DEPLOY_DIR \
SSTATE_HASHEQUIV_METHOD SSTATE_HASHEQUIV_REPORT_TASKDATA \
-SSTATE_HASHEQUIV_OWNER CCACHE_TOP_DIR BB_HASHSERVE GIT_CEILING_DIRECTORIES"
+SSTATE_HASHEQUIV_OWNER CCACHE_TOP_DIR BB_HASHSERVE GIT_CEILING_DIRECTORIES
\
+OMP_NUM_THREADS"
BB_HASHBASE_WHITELIST ?= "${BB_HASHEXCLUDE_COMMON} PSEUDO_IGNORE_PATHS
BUILDHISTORY_DIR SSTATE_DIR "
BB_HASHCONFIG_WHITELIST ?= "${BB_HASHEXCLUDE_COMMON} DATE TIME SSH_AGENT_PID \
SSH_AUTH_SOCK PSEUDO_BUILD BB_ENV_EXTRAWHITE DISABLE_SANITY_CHECKS \
--
2.30.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150146):
https://lists.openembedded.org/g/openembedded-core/message/150146
Mute This Topic: https://lists.openembedded.org/mt/81778439/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] mesa-gl: Use swrast gallium driver
On Thu, Apr 1, 2021 at 3:19 AM Martin Jansa wrote:
>
> On Wed, Mar 31, 2021 at 03:50:51PM -0700, Khem Raj wrote:
> > Fixes
> > ../mesa-21.0.0/meson.build:21:0: ERROR: Options "swrast" are not in allowed
> > choices: "auto, i915, i965, r100, r200, nouveau"
> >
> > Signed-off-by: Khem Raj
> > Cc: Martin Jansa
> > ---
> > meta/recipes-graphics/mesa/mesa-gl_21.0.0.bb | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-graphics/mesa/mesa-gl_21.0.0.bb
> > b/meta/recipes-graphics/mesa/mesa-gl_21.0.0.bb
> > index e50782be1c..fc8b4f7504 100644
> > --- a/meta/recipes-graphics/mesa/mesa-gl_21.0.0.bb
> > +++ b/meta/recipes-graphics/mesa/mesa-gl_21.0.0.bb
> > @@ -12,4 +12,4 @@ PACKAGECONFIG ??= "opengl dri
> > ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x1
> > PACKAGECONFIG_class-target = "opengl dri
> > ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', 'osmesa', d)}"
> >
> > # When NOT using X11, we need to make sure we have swrast available.
> > -DRIDRIVERS_append = "${@bb.utils.contains('DISTRO_FEATURES', 'x11', '',
> > ',swrast', d)}"
> > +GALLIUMDRIVERS_append = "${@bb.utils.contains('DISTRO_FEATURES', 'x11',
> > '', ',swrast', d)}"
>
> With:
> DISTRO_FEATURES_remove = "x11"
> PREFERRED_PROVIDER_virtual/libgl = "mesa-gl"
> PREFERRED_PROVIDER_virtual/mesa = "mesa-gl"
> in local.conf this is unfortunately still failing, now with:
>
> ../mesa-21.0.0/meson.build:519:4: ERROR: Problem encountered: building dri
> drivers require at least one windowing system
>
> whole log:
> http://errors.yoctoproject.org/Errors/Details/575265/
>
> adding nouveau to DRIDRIVERS like normal mesa doesn't help in this case,
> because I was building for qemux86-64 which already has bunch of
> DRIDRIVERS added by default (but adding at least one DRIDRIVER might be still
> needed for other architectures).
>
classic OSMesa is removed and swrast gallium drivers are needed for osmsa to run
could you also add below patch and try. ?
diff --git a/meta/recipes-graphics/mesa/mesa-gl_21.0.0.bb
b/meta/recipes-graphics/mesa/mesa-gl_21.0.0.bb
index fc8b4f7504..47b14fb97f 100644
--- a/meta/recipes-graphics/mesa/mesa-gl_21.0.0.bb
+++ b/meta/recipes-graphics/mesa/mesa-gl_21.0.0.bb
@@ -8,8 +8,8 @@ S = "${WORKDIR}/mesa-${PV}"
# At least one DRI rendering engine is required to build mesa.
# When no X11 is available, use osmesa for the rendering engine.
-PACKAGECONFIG ??= "opengl dri ${@bb.utils.contains('DISTRO_FEATURES',
'x11', 'x11', 'osmesa', d)}"
-PACKAGECONFIG_class-target = "opengl dri
${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', 'osmesa', d)}"
+PACKAGECONFIG ??= "opengl dri ${@bb.utils.contains('DISTRO_FEATURES',
'x11', 'x11', 'osmesa gallium', d)}"
+PACKAGECONFIG_class-target = "opengl dri
${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', 'osmesa
gallium', d)}"
# When NOT using X11, we need to make sure we have swrast available.
GALLIUMDRIVERS_append = "${@bb.utils.contains('DISTRO_FEATURES',
'x11', '', ',swrast', d)}"
> # $DRIDRIVERS [4 operations]
> # _append[x86_class-target]
> /OE/build/oe-core/openembedded-core/meta/recipes-graphics/mesa/mesa.inc:107
> # ",r100,r200,nouveau,i965,i915"
> # _append[x86-64_class-target]
> /OE/build/oe-core/openembedded-core/meta/recipes-graphics/mesa/mesa.inc:108
> # ",r100,r200,nouveau,i965,i915"
> # override[class-native]:set
> /OE/build/oe-core/openembedded-core/meta/recipes-graphics/mesa/mesa.inc:105
> # "nouveau"
> # override[class-nativesdk]:set
> /OE/build/oe-core/openembedded-core/meta/recipes-graphics/mesa/mesa.inc:106
> # "nouveau"
> # pre-expansion value:
> # ",r100,r200,nouveau,i965,i915"
> DRIDRIVERS=",r100,r200,nouveau,i965,i915"
>
> Reverting Alex's upgrade to 21.0.0 allows to build mesa-gl again and it
> should surely pass AB build :).
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150145):
https://lists.openembedded.org/g/openembedded-core/message/150145
Mute This Topic: https://lists.openembedded.org/mt/81763397/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] make-mod-scripts: pass CROSS_COMPILE to configure and build
On Wed, Mar 31, 2021 at 8:00 PM Denys Dmytriyenko wrote:
>
> Fixes:
> | CALL
> /OE/poky-master/build/tmp/work-shared/qemuarm64/kernel-source/scripts/checksyscalls.sh
> | CALL
> /OE/poky-master/build/tmp/work-shared/qemuarm64/kernel-source/scripts/atomic/check-atomics.sh
> | LDS arch/arm64/kernel/vdso/vdso.lds
> | CC arch/arm64/kernel/vdso/vgettimeofday.o
> | AS arch/arm64/kernel/vdso/note.o
> | AS arch/arm64/kernel/vdso/sigreturn.o
> | LD arch/arm64/kernel/vdso/vdso.so.dbg
> | VDSOSYM include/generated/vdso-offsets.h
> | OBJCOPY arch/arm64/kernel/vdso/vdso.so
> | objcopy: Unable to recognise the format of the input file
> `arch/arm64/kernel/vdso/vdso.so.dbg'
> |
> /OE/poky-master/build/tmp/work-shared/qemuarm64/kernel-source/arch/arm64/kernel/vdso/Makefile:61:
> recipe for target 'arch/arm64/kernel/vdso/vdso.so' failed
>
> Cc: Bruce Ashfield
I like the lighter touch of this patch. I still can't explain why this
isn't necessary on one of my builders, but is on the other .. but that
of course isn't relevant to this!
I've reviewed and tested this, so no concerns from my end.
Queue the cheesy -by lines:
Reviewed-by: Bruce Ashfield
Acked-by: Bruce Ashfield
Tested-by: Bruce Ashfield
> Cc: Nishanth Menon
> Signed-off-by: Denys Dmytriyenko
> ---
> meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> index 92ffa47..b2b50b9 100644
> --- a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> +++ b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> @@ -19,7 +19,7 @@ DEPENDS += "bc-native bison-native"
> DEPENDS += "gmp-native"
>
> EXTRA_OEMAKE = " HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}"
> HOSTCPP="${BUILD_CPP}""
> -EXTRA_OEMAKE += " HOSTCXX="${BUILD_CXX} ${BUILD_CXXFLAGS} ${BUILD_LDFLAGS}""
> +EXTRA_OEMAKE += " HOSTCXX="${BUILD_CXX} ${BUILD_CXXFLAGS} ${BUILD_LDFLAGS}"
> CROSS_COMPILE=${TARGET_PREFIX}"
>
> # Build some host tools under work-shared. CC, LD, and AR are probably
> # not used, but this is the historical way of invoking "make scripts".
> --
> 2.7.4
>
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150144):
https://lists.openembedded.org/g/openembedded-core/message/150144
Mute This Topic: https://lists.openembedded.org/mt/81764668/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] make-mod-scripts: Provide the correct objcopy to kernel make
On Wed, Mar 31, 2021 at 8:01 PM Denys Dmytriyenko wrote:
>
> On Mon, Mar 29, 2021 at 11:14:13AM -0400, Bruce Ashfield wrote:
> > On Mon, Mar 29, 2021 at 10:08 AM Nishanth Menon wrote:
> > >
> > > On 13:31-20210327, Bruce Ashfield wrote:
> > > > On Thu, Mar 25, 2021 at 9:13 PM Nishanth Menon via
> > > > lists.openembedded.org wrote:
> > > > >
> > > > > When cross-compiling with v5.12-rc3, prepare fails[1] build of vdso at
> > > > > the objcopy stage since it seems to be using the local host's objcopy
> > > > > rather than the cross-compile version we want it to use.
> > > > >
> > > > > This can be trivially reproduced in a localbuild of the kernel
> > > > > following the build parameters provided in the process[2]
> > > > >
> > > > > Lets fix this by passing OBJCOPY over to the kernel.
> > > > >
> > > >
> > > > As I mentioned to Denys, I hadn't seen this. Consulting the
> > > > maintainers file would have found me as a good addition to the cc'.
> > > >
> > >
> > > Sure. understood. Thanks..
> > >
> > > > I'm doing some other work on make-mod-scripts dependencies right now,
> > > > so I've pulled this in and will re-test against all of the active
> > > > kernel versions in master.
> > > >
> > >
> > >
> > > Thanks.
> > >
> > > > But I don't think that make-mod-scripts is the only place we'd need
> > > > this, if it is indeed happening on the tip of all the supported
> > > > versions. There are routes to have the prepare steps run, without a
> > > > make-mod-scripts dependency.
> > > >
> > > > We've already made the mistake of letting the make-mod-scrips and
> > > > kernel build parameters diverge (see AR=${KERNEL_AR}), so I need to
> > > > spend a few minutes getting them back in sync.
> > > >
> > > > I was just able to build and boot qemuarm64 on 5.12-rc4, so there's
> > > > something different about your config than my setup. We need to figure
> > > > that out. It could be a .config triggering different components to be
> > > > built, but unlikely given vdso being involved.
> > > >
> > > > qemuarm64 login: root
> > > > root@qemuarm64:~# uname -a
> > > > Linux qemuarm64 5.12.0-rc4-yoctodev-standard #1 SMP PREEMPT Mon Mar 22
> > > > 18:46:22 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
> > > > root@qemuarm64:~#
> > >
> > > Hmm... only thing I have done is cross compile - see the pastebins.
> > > >
> > > > > [1] https://pastebin.ubuntu.com/p/pNcQtb93wr/
> > > > > [2] https://pastebin.ubuntu.com/p/vZGqgh9Sq5/
> > > > > Signed-off-by: Nishanth Menon
> > >
> > > [...]
> > > > > diff --git a/meta/classes/kernel-arch.bbclass
> > > > > b/meta/classes/kernel-arch.bbclass
> > > > > index 07ec242e63bb..3d25fc7ac531 100644
> > > > > --- a/meta/classes/kernel-arch.bbclass
> > > > > +++ b/meta/classes/kernel-arch.bbclass
> > > > > @@ -60,9 +60,12 @@ TARGET_LD_KERNEL_ARCH ?= ""
> > > > > HOST_LD_KERNEL_ARCH ?= "${TARGET_LD_KERNEL_ARCH}"
> > > > > TARGET_AR_KERNEL_ARCH ?= ""
> > > > > HOST_AR_KERNEL_ARCH ?= "${TARGET_AR_KERNEL_ARCH}"
> > > > > +TARGET_OBJCOPY_KERNEL_ARCH ?= ""
> > > > > +HOST_OBJCOPY_KERNEL_ARCH ?= "${TARGET_OBJCOPY_KERNEL_ARCH}"
> > > > >
> > > >
> > > > We shouldn't need this TARGET_OBJCOPY_KERNEL_ARCH ->
> > > > HOST_OBJCOPY_KERNEL_ARCH, I can't think of how objcopy would be using
> > > > them.
> > >
> > > >
> > > > Are you setting them to some value in your builds ?
> > >
> > > No, I am not. I decided to maintain consistency of usage from LD and AR.
> > > I could'nt think of a usage either, true.
> >
> > That's what I figured. I was worried I was missing some sort of
> > usecase. No harm in copying the existing pattern, I didn't introduce
> > it either, so I wanted to make sure there wasn't something going on
> > that I didn't see.
> >
> > >
> > >
> > > >
> > > > > KERNEL_CC = "${CCACHE}${HOST_PREFIX}gcc ${HOST_CC_KERNEL_ARCH}
> > > > > -fuse-ld=bfd ${DEBUG_PREFIX_MAP}
> > > > > -fdebug-prefix-map=${STAGING_KERNEL_DIR}=${KERNEL_SRC_PATH}"
> > > > > KERNEL_LD = "${CCACHE}${HOST_PREFIX}ld.bfd ${HOST_LD_KERNEL_ARCH}"
> > > > > KERNEL_AR = "${CCACHE}${HOST_PREFIX}ar ${HOST_AR_KERNEL_ARCH}"
> > > > > +KERNEL_OBJCOPY = "${CCACHE}${HOST_PREFIX}objcopy
> > > > > ${HOST_OBJCOPY_KERNEL_ARCH}"
> > > >
> > > > The main kernel Makefile already defines, and the standard env should
> > > > already have both CROSS_COMPILE and OBJCOPY defined to be the target
> > > > version.
> > > >
> > > > Makefile:OBJCOPY= $(CROSS_COMPILE)objcopy
> > >
> > > OK this is what is confusing me -> I dont see CROSS_COMPILE being set -
> > > which is what I had expected in the first place. other than
> > > meta/recipes-kernel/perf/perf.bb, I dont see it set else where -> I was
> > > really wondering why all the specific usage, when CROSS_COMPILE would
> > > have just done the job.. Then I was guessing maybe the rationale is for
> > > some ancient kernel where CROSS_COMPILE is'nt set right?
> > >
> >
> > It could be, we also wanted to tack on the CCACHE stuff, but generally
> > speaking .. it is all kind of
[OE-core] what are the dangers of adding "out-of-tree" files to FILES_${PN}?
recently, i've run across a couple layers based on pretty much
up-to-date OE/YP, where fixed files are being added to a package via
assignments like this:
FILES_${PN} += "/data"
i already know that's a bad idea, but i'm curious as to what build
errors might occur when trying something like this. i was first asked
about what might have caused a "pseudo abort" error as described here:
https://wiki.yoctoproject.org/wiki/Pseudo_Abort
where the generated error referred to "path mismatch ... ino ###
db" ... etc etc. my first (admittedly uneducated) guess was that, in
the midst of installation, some of that external content under /data
was perhaps being deleted or updated in some way that was changing
inodes.
even if doing something like technically works, can someone explain
what ugliness might result, i'm assuming from having any of that
external data change in the middle of a build?
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150142):
https://lists.openembedded.org/g/openembedded-core/message/150142
Mute This Topic: https://lists.openembedded.org/mt/81775911/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] mesa-gl: Use swrast gallium driver
On Wed, Mar 31, 2021 at 03:50:51PM -0700, Khem Raj wrote:
> Fixes
> ../mesa-21.0.0/meson.build:21:0: ERROR: Options "swrast" are not in allowed
> choices: "auto, i915, i965, r100, r200, nouveau"
>
> Signed-off-by: Khem Raj
> Cc: Martin Jansa
> ---
> meta/recipes-graphics/mesa/mesa-gl_21.0.0.bb | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-graphics/mesa/mesa-gl_21.0.0.bb
> b/meta/recipes-graphics/mesa/mesa-gl_21.0.0.bb
> index e50782be1c..fc8b4f7504 100644
> --- a/meta/recipes-graphics/mesa/mesa-gl_21.0.0.bb
> +++ b/meta/recipes-graphics/mesa/mesa-gl_21.0.0.bb
> @@ -12,4 +12,4 @@ PACKAGECONFIG ??= "opengl dri
> ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x1
> PACKAGECONFIG_class-target = "opengl dri
> ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', 'osmesa', d)}"
>
> # When NOT using X11, we need to make sure we have swrast available.
> -DRIDRIVERS_append = "${@bb.utils.contains('DISTRO_FEATURES', 'x11', '',
> ',swrast', d)}"
> +GALLIUMDRIVERS_append = "${@bb.utils.contains('DISTRO_FEATURES', 'x11', '',
> ',swrast', d)}"
With:
DISTRO_FEATURES_remove = "x11"
PREFERRED_PROVIDER_virtual/libgl = "mesa-gl"
PREFERRED_PROVIDER_virtual/mesa = "mesa-gl"
in local.conf this is unfortunately still failing, now with:
../mesa-21.0.0/meson.build:519:4: ERROR: Problem encountered: building dri
drivers require at least one windowing system
whole log:
http://errors.yoctoproject.org/Errors/Details/575265/
adding nouveau to DRIDRIVERS like normal mesa doesn't help in this case,
because I was building for qemux86-64 which already has bunch of
DRIDRIVERS added by default (but adding at least one DRIDRIVER might be still
needed for other architectures).
# $DRIDRIVERS [4 operations]
# _append[x86_class-target]
/OE/build/oe-core/openembedded-core/meta/recipes-graphics/mesa/mesa.inc:107
# ",r100,r200,nouveau,i965,i915"
# _append[x86-64_class-target]
/OE/build/oe-core/openembedded-core/meta/recipes-graphics/mesa/mesa.inc:108
# ",r100,r200,nouveau,i965,i915"
# override[class-native]:set
/OE/build/oe-core/openembedded-core/meta/recipes-graphics/mesa/mesa.inc:105
# "nouveau"
# override[class-nativesdk]:set
/OE/build/oe-core/openembedded-core/meta/recipes-graphics/mesa/mesa.inc:106
# "nouveau"
# pre-expansion value:
# ",r100,r200,nouveau,i965,i915"
DRIDRIVERS=",r100,r200,nouveau,i965,i915"
Reverting Alex's upgrade to 21.0.0 allows to build mesa-gl again and it should
surely pass AB build :).
signature.asc
Description: PGP signature
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150141):
https://lists.openembedded.org/g/openembedded-core/message/150141
Mute This Topic: https://lists.openembedded.org/mt/81763397/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [poky][dunfell][PATCHv2] openssh: fix CVE-2020-14145
Hi Steve,
I have verified the patch on dunfell branch and it builds successfully.
Please refer the attached do_patch log.
Thanks & Regards,
Sana Kazi
KPIT Technologies Limited
From: Steve Sakoman
Sent: Wednesday, March 31, 2021 11:31 PM
To: Sana Kazi
Cc: Patches and discussions about the oe-core layer
; Khem Raj ;
Nisha Parrakat ; Purushottam Choudhary
; Harpritkaur Bhandari
Subject: Re: [OE-core] [poky][dunfell][PATCHv2] openssh: fix CVE-2020-14145
V2 also fails to build:
ERROR: openssh-8.2p1-r0 do_patch: Command Error: 'quilt --quiltrc
/home/steve/builds/poky-contrib/build/tmp/work/core2-64-poky-linux/openssh/8.2p1-r0/recipe-sysroot-native/etc/quiltrc
push' exited with 0 Output:
Applying patch CVE-2020-14145.patch
patching file sshconnect2.c
Hunk #1 FAILED at 102.
Hunk #2 FAILED at 119.
Hunk #3 FAILED at 159.
3 out of 3 hunks FAILED -- rejects in file sshconnect2.c
Patch CVE-2020-14145.patch does not apply (enforce with -f)
Before submitting please verify that your patches both apply to the
head of the dunfell branch, and build as well!
Steve
On Wed, Mar 31, 2021 at 7:21 AM Sana Kazi wrote:
>
> From: Lee Chee Yang
>
> (From OE-Core rev: 38482edf1a31ed0735b746cf0ab3e1adda4199d1)
>
> Signed-off-by: Lee Chee Yang
> Signed-off-by: Anuj Mittal
> Signed-off-by: Richard Purdie
> Signed-off-by: Sana Kazi
> ---
> .../openssh/openssh/CVE-2020-14145.patch | 90 +++
> .../openssh/openssh_8.2p1.bb | 1 +
> 2 files changed, 91 insertions(+)
> create mode 100644
> meta/recipes-connectivity/openssh/openssh/CVE-2020-14145.patch
>
> diff --git a/meta/recipes-connectivity/openssh/openssh/CVE-2020-14145.patch
> b/meta/recipes-connectivity/openssh/openssh/CVE-2020-14145.patch
> new file mode 100644
> index 00..0046ee1a51
> --- /dev/null
> +++ b/meta/recipes-connectivity/openssh/openssh/CVE-2020-14145.patch
> @@ -0,0 +1,90 @@
> +From b3855ff053f5078ec3d3c653cdaedefaa5fc362d Mon Sep 17 00:00:00 2001
> +From: "d...@openbsd.org"
> +Date: Fri, 18 Sep 2020 05:23:03 +
> +Subject: [PATCH] upstream: tweak the client hostkey preference ordering
> + algorithm to
> +
> +prefer the default ordering if the user has a key that matches the
> +best-preference default algorithm.
> +
> +feedback and ok markus@
> +
> +OpenBSD-Commit-ID: a92dd7d7520ddd95c0a16786a7519e6d0167d35f
> +
> +Upstream-Status: Backport
> +[https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenssh%2Fopenssh-portable%2Fcommit%2Fb3855ff053f5078ec3d3c653cdaedefaa5fc362ddata=04%7C01%7CSana.Kazi%40kpit.com%7C4b74e63f0ba745d0e18608d8f46f0bd8%7C3539451eb46e4a26a242ff61502855c7%7C0%7C0%7C637528105076588451%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=FEdHjP9Fp%2BlrVEtby1zBa5W%2BlrkVHHFVJgMOk%2BvDusY%3Dreserved=0]
> +CVE: CVE-2020-14145
> +Signed-off-by: Chee Yang Lee
> +
> +---
> + sshconnect2.c | 41 ++---
> + 1 file changed, 37 insertions(+), 2 deletions(-)
> +
> +diff --git a/sshconnect2.c b/sshconnect2.c
> +index 347e348c60..f64aae66af 100644
> +--- a/sshconnect2.c
> b/sshconnect2.c
> +@@ -102,12 +102,25 @@ verify_host_key_callback(struct sshkey *hostkey,
> struct ssh *ssh)
> + return 0;
> + }
> +
> ++/* Returns the first item from a comma-separated algorithm list */
> ++static char *
> ++first_alg(const char *algs)
> ++{
> ++ char *ret, *cp;
> ++
> ++ ret = xstrdup(algs);
> ++ if ((cp = strchr(ret, ',')) != NULL)
> ++ *cp = '\0';
> ++ return ret;
> ++}
> ++
> + static char *
> + order_hostkeyalgs(char *host, struct sockaddr *hostaddr, u_short port)
> + {
> +- char *oavail, *avail, *first, *last, *alg, *hostname, *ret;
> ++ char *oavail = NULL, *avail = NULL, *first = NULL, *last = NULL;
> ++ char *alg = NULL, *hostname = NULL, *ret = NULL, *best = NULL;
> + size_t maxlen;
> +- struct hostkeys *hostkeys;
> ++ struct hostkeys *hostkeys = NULL;
> + int ktype;
> + u_int i;
> +
> +@@ -119,6 +132,26 @@ order_hostkeyalgs(char *host, struct sockaddr
> *hostaddr, u_short port)
> + for (i = 0; i < options.num_system_hostfiles; i++)
> + load_hostkeys(hostkeys, hostname,
> options.system_hostfiles[i]);
> +
> ++ /*
> ++ * If a plain public key exists that matches the type of the best
> ++ * preference HostkeyAlgorithms, then use the whole list as is.
> ++ * Note that we ignore whether the best preference algorithm is a
> ++ * certificate type, as sshconnect.c will downgrade certs to
> ++ * plain keys if necessary.
> ++ */
> ++ best = first_alg(options.hostkeyalgorithms);
> ++ if (lookup_key_in_hostkeys_by_type(hostkeys,
> ++ sshkey_type_plain(sshkey_type_from_name(best)), NULL)) {
> ++ debug3("%s: have matching best-preference key type %s, "
> ++ "using
[OE-core] [poky][master][PATCH] buildhistory.bbclass: store MAINTAINER variable
The maintainer declaration in the buildhistory
is useful for tracking the maintainer of recipes.
This change adds the MAINTAINER variable for
recipes and packages to its buildhistory data.
Signed-off-by: Purushottam Choudhary
---
meta/classes/buildhistory.bbclass | 10 ++
1 file changed, 10 insertions(+)
diff --git a/meta/classes/buildhistory.bbclass
b/meta/classes/buildhistory.bbclass
index 49af61c..23357af 100644
--- a/meta/classes/buildhistory.bbclass
+++ b/meta/classes/buildhistory.bbclass
@@ -119,6 +119,7 @@ python buildhistory_emit_pkghistory() {
self.config = ""
self.src_uri = ""
+self.maintainer = ""
class PackageInfo:
def __init__(self, name):
@@ -131,6 +132,7 @@ python buildhistory_emit_pkghistory() {
self.pkge = ""
self.pkgv = ""
self.pkgr = ""
+self.maintainer = ""
self.size = 0
self.depends = ""
self.rprovides = ""
@@ -167,6 +169,8 @@ python buildhistory_emit_pkghistory() {
pkginfo.pkgv = value
elif name == "PKGR":
pkginfo.pkgr = value
+elif name == "MAINTAINER":
+pkginfo.maintainer = value
elif name == "RPROVIDES":
pkginfo.rprovides = value
elif name == "RDEPENDS":
@@ -220,6 +224,7 @@ python buildhistory_emit_pkghistory() {
pr = d.getVar('PR')
layer = bb.utils.get_file_layer(d.getVar('FILE'), d)
license = d.getVar('LICENSE')
+maintainer = d.getVar('MAINTAINER') or ''
pkgdata_dir = d.getVar('PKGDATA_DIR')
packages = ""
@@ -257,6 +262,7 @@ python buildhistory_emit_pkghistory() {
rcpinfo.pe = pe
rcpinfo.pv = pv
rcpinfo.pr = pr
+rcpinfo.maintainer = maintainer
rcpinfo.depends = sortlist(oe.utils.squashspaces(d.getVar('DEPENDS') or
""))
rcpinfo.packages = packages
rcpinfo.layer = layer
@@ -274,6 +280,7 @@ python buildhistory_emit_pkghistory() {
pkge = localdata.getVar("PKGE") or '0'
pkgv = localdata.getVar("PKGV")
pkgr = localdata.getVar("PKGR")
+pkg_maintainer = localdata.getVar('MAINTAINER_%s' % (pkg,), True) or
maintainer
#
# Find out what the last version was
# Make sure the version did not decrease
@@ -297,6 +304,7 @@ python buildhistory_emit_pkghistory() {
pkginfo.pkge = pkge
pkginfo.pkgv = pkgv
pkginfo.pkgr = pkgr
+pkginfo.maintainer = pkg_maintainer
pkginfo.rprovides =
sortpkglist(oe.utils.squashspaces(localdata.getVar("RPROVIDES") or ""))
pkginfo.rdepends =
sortpkglist(oe.utils.squashspaces(localdata.getVar("RDEPENDS") or ""))
pkginfo.rrecommends =
sortpkglist(oe.utils.squashspaces(localdata.getVar("RRECOMMENDS") or ""))
@@ -375,6 +383,7 @@ def write_recipehistory(rcpinfo, d):
f.write(u"LICENSE = %s\n" % rcpinfo.license)
f.write(u"CONFIG = %s\n" % rcpinfo.config)
f.write(u"SRC_URI = %s\n" % rcpinfo.src_uri)
+f.write(u"MAINTAINER = %s\n" % rcpinfo.maintainer)
write_latest_srcrev(d, pkghistdir)
@@ -393,6 +402,7 @@ def write_pkghistory(pkginfo, d):
f.write(u"PE = %s\n" % pkginfo.pe)
f.write(u"PV = %s\n" % pkginfo.pv)
f.write(u"PR = %s\n" % pkginfo.pr)
+f.write(u"MAINTAINER = %s\n" % pkginfo.maintainer)
if pkginfo.pkg != pkginfo.name:
f.write(u"PKG = %s\n" % pkginfo.pkg)
--
2.7.4
This message contains information that may be privileged or confidential and is
the property of the KPIT Technologies Ltd. It is intended only for the person
to whom it is addressed. If you are not the intended recipient, you are not
authorized to read, print, retain copy, disseminate, distribute, or use this
message or any part thereof. If you receive this message in error, please
notify the sender immediately and delete all copies of this message. KPIT
Technologies Ltd. does not accept any liability for virus infected mails.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150139):
https://lists.openembedded.org/g/openembedded-core/message/150139
Mute This Topic: https://lists.openembedded.org/mt/81770608/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [qa-build-notification] QA notification for completed autobuilder build (yocto-3.2.3.rc1)
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-notificat...@lists.yoctoproject.org notificat...@lists.yoctoproject.org> On Behalf Of Pokybuild User > Sent: Monday, 29 March, 2021 11:49 AM > To: yo...@lists.yoctoproject.org > Cc: qa-build-notificat...@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.pur...@linuxfoundation.org > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#150138): https://lists.openembedded.org/g/openembedded-core/message/150138 Mute This Topic: https://lists.openembedded.org/mt/81691220/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
