Re: [OE-core] Question about nativesdk-qemuwrapper-cross
Hi, Qi
> As far as I know, qemuwrapper-cross should work in such case. You need to use
> qemuwrapper-cross instead of nativesdk-qemuwrapper-cross.
Oh, it seems the solution. Correct qemuwrapper script can now be added into
meta-toolchain. Why did I pay all my attention to nativesdk-qemuwrapper-cross!
Thank you very much for your reply.
Best regards
Lei
> -Original Message-
> From: Chen, Qi
> Sent: Thursday, July 7, 2022 9:30 AM
> To: Lei, Maohui ; Richard Purdie
> ;
> openembedded-core@lists.openembedded.org
> Subject: RE: [OE-core] Question about nativesdk-qemuwrapper-cross
>
> As far as I know, qemuwrapper-cross should work in such case. You need to use
> qemuwrapper-cross instead of nativesdk-qemuwrapper-cross.
>
> Regards,
> Qi
>
> -Original Message-
> From: openembedded-core@lists.openembedded.org
> On Behalf Of leimaohui
> Sent: Thursday, July 7, 2022 9:04 AM
> To: Richard Purdie ;
> openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] Question about nativesdk-qemuwrapper-cross
>
> Hi, Richard
>
> Thanks for your reply.
>
> > A nativesdk-qemuwrapper-cross would run binaries from the SDK under
> > qemu, so if SDKMACHINE was x86-64, that would be correct.
>
> OK, it seems that I didn't get the usage of nativesdk-qemuwrapper-cross every
> well.
>
> > It sounds like you want a qemuwrapper-cross-canadian-${MACHINE} which
> > is something different.
>
> The problem I have is that when I created a rootfs(aarch64) under SDK
> environment by nativesdk-dnf, there were postinstall errors occurred with some
> packages(such as glib-networking) which included postinstall script using
> qemuwrapper.
> So, I added nativesdk-qemuwrapper-cross into meta-toolchain, and hope it can
> work as qemuwrapper-cross under build system. But it seems that
> qemu-${SDK_MACHINE} which nativesdk-qemuwrapper-cross provided can't
> work for aarch64 rootfs.
> I have no good idea how to do. Should I added another qemuwrapper-cross such
> as qemuwrapper-cross-canadian-${MACHINE}?
> I wonder if you can give me some advises?
>
> Best regards
> Lei
>
>
> > -Original Message-
> > From: Richard Purdie
> > Sent: Wednesday, July 6, 2022 5:12 PM
> > To: Lei, Maohui ;
> > openembedded-core@lists.openembedded.org
> > Subject: Re: Question about nativesdk-qemuwrapper-cross
> >
> > On Wed, 2022-07-06 at 03:31 +, leimao...@fujitsu.com wrote:
> > > Hi, Richard
> > >
> > > I added nativesdk- qemuwrapper-cross into my meta-toolchain, and
> > > found the
> > content of nativesdk-qemuwrapper script is like the following:
> > > --
> > > # cat
> > > /opt/poky/4.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/crosssc
> > > ri
> > > pts/nativesdk-qemuwrapper
> > > #!/bin/sh
> > > # Wrapper script to run binaries under qemu user-mode emulation set
> > > -x
> > >
> > > if [ True = False -a "nativesdk-qemuwrapper-cross" !=
> > "nativesdk-qemuwrapper-cross" ]; then
> > > echo "qemuwrapper: qemu usermode is not supported"
> > > exit 1
> > > fi
> > >
> > >
> > > qemu-x86_64 -r 3.2.0 -E
> > LD_LIBRARY_PATH=$D/opt/poky/4.1+snapshot/sysroots/x86_64-pokysdk-linux
> > / usr/lib:$D/opt/poky/4.1+snapshot/sysroots/x86_64-pokysdk-linux/lib
> > "$@"
> > > --
> > >
> > > Reference to qemuwrapper-cross, it seems that nativesdk
> > > qemuwrapper-cross is
> > not correct.
> > > Why the "qemu_binary " is " qemu-x86_64"? Shouldn't it be "qemu-aarch64 "?
> > > Is it better to change nativesdk qemuwrapper-cross to
> > qemuwrapper-cross-canadian-${MACHINE}?
> >
> >
> > A nativesdk-qemuwrapper-cross would run binaries from the SDK under
> > qemu, so if SDKMACHINE was x86-64, that would be correct.
> >
> > It sounds like you want a qemuwrapper-cross-canadian-${MACHINE} which
> > is something different.
> >
> > Cheers,
> >
> > Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#167814):
https://lists.openembedded.org/g/openembedded-core/message/167814
Mute This Topic: https://lists.openembedded.org/mt/92200125/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[oe-core][kirkstone][PATCH] harfbuzz: fix CVE-2022-33068
Backport patch from
https://github.com/harfbuzz/harfbuzz/commit/62e803b36173fd096d7ad460dd1d1db9be542593
The 'tff' file in upstream patch is for testing only which cause error during
do_patch so need be dropped.
File test/fuzzing/fonts/sbix-extents.ttf: git binary diffs are not supported.
Signed-off-by: Wentao Zhang
---
.../harfbuzz/harfbuzz/CVE-2022-33068.patch| 35 +++
.../harfbuzz/harfbuzz_4.0.1.bb| 3 +-
2 files changed, 37 insertions(+), 1 deletion(-)
create mode 100644 meta/recipes-graphics/harfbuzz/harfbuzz/CVE-2022-33068.patch
diff --git a/meta/recipes-graphics/harfbuzz/harfbuzz/CVE-2022-33068.patch
b/meta/recipes-graphics/harfbuzz/harfbuzz/CVE-2022-33068.patch
new file mode 100644
index 00..931b9abe1e
--- /dev/null
+++ b/meta/recipes-graphics/harfbuzz/harfbuzz/CVE-2022-33068.patch
@@ -0,0 +1,35 @@
+From 62e803b36173fd096d7ad460dd1d1db9be542593 Mon Sep 17 00:00:00 2001
+From: Behdad Esfahbod
+Date: Wed, 1 Jun 2022 07:38:21 -0600
+Subject: [PATCH] [sbix] Limit glyph extents
+
+Fixes https://github.com/harfbuzz/harfbuzz/issues/3557
+
+Upstream-Status: Backport
[https://github.com/harfbuzz/harfbuzz/commit/62e803b36173fd096d7ad460dd1d1db9be542593]
+CVE:CVE-2022-33068
+Signed-off-by: Wentao Zhang
+
+---
+ src/hb-ot-color-sbix-table.hh | 6 ++
+ 1 file changed, 6 insertions(+)
+
+diff --git a/src/hb-ot-color-sbix-table.hh b/src/hb-ot-color-sbix-table.hh
+index 9741ebd45..6efae43cd 100644
+--- a/src/hb-ot-color-sbix-table.hh
b/src/hb-ot-color-sbix-table.hh
+@@ -298,6 +298,12 @@ struct sbix
+
+ const PNGHeader = *blob->as();
+
++ if (png.IHDR.height >= 65536 | png.IHDR.width >= 65536)
++ {
++ hb_blob_destroy (blob);
++ return false;
++ }
++
+ extents->x_bearing = x_offset;
+ extents->y_bearing = png.IHDR.height + y_offset;
+ extents->width = png.IHDR.width;
+--
+2.25.1
+
diff --git a/meta/recipes-graphics/harfbuzz/harfbuzz_4.0.1.bb
b/meta/recipes-graphics/harfbuzz/harfbuzz_4.0.1.bb
index bf77a5e56c..81518a53ea 100644
--- a/meta/recipes-graphics/harfbuzz/harfbuzz_4.0.1.bb
+++ b/meta/recipes-graphics/harfbuzz/harfbuzz_4.0.1.bb
@@ -11,7 +11,8 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=6ee0f16281694fb6aa689cca1e0fb3da \
UPSTREAM_CHECK_URI = "https://github.com/${BPN}/${BPN}/releases;
UPSTREAM_CHECK_REGEX = "harfbuzz-(?P\d+(\.\d+)+).tar"
-SRC_URI =
"https://github.com/${BPN}/${BPN}/releases/download/${PV}/${BPN}-${PV}.tar.xz;
+SRC_URI =
"https://github.com/${BPN}/${BPN}/releases/download/${PV}/${BPN}-${PV}.tar.xz\
+ file://CVE-2022-33068.patch"
SRC_URI[sha256sum] =
"98f68777272db6cd7a3d5152bac75083cd52a26176d87bc04c8b3929d33bce49"
inherit meson pkgconfig lib_package gtk-doc gobject-introspection
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#167813):
https://lists.openembedded.org/g/openembedded-core/message/167813
Mute This Topic: https://lists.openembedded.org/mt/92242403/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/14] qemu: add PACKAGECONFIG for capstone
Autobuilder workers were non-deterministically enabling capstone.
Add PACKAGECONFIG for capstone with default off.
Qemu versions in master and kirkstone have removed the capstone
submodule and configure options so this patch is not appropriate
for these branches.
Signed-off-by: Steve Sakoman
---
meta/recipes-devtools/qemu/qemu.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-devtools/qemu/qemu.inc
b/meta/recipes-devtools/qemu/qemu.inc
index 25c2cdef3a..4135619fc6 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -254,6 +254,7 @@ PACKAGECONFIG[xkbcommon] =
"--enable-xkbcommon,--disable-xkbcommon,libxkbcommon"
PACKAGECONFIG[libudev] = "--enable-libudev,--disable-libudev,eudev"
PACKAGECONFIG[libxml2] = "--enable-libxml2,--disable-libxml2,libxml2"
PACKAGECONFIG[seccomp] = "--enable-seccomp,--disable-seccomp,libseccomp"
+PACKAGECONFIG[capstone] = "--enable-capstone,--disable-capstone"
INSANE_SKIP_${PN} = "arch"
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#167812):
https://lists.openembedded.org/g/openembedded-core/message/167812
Mute This Topic: https://lists.openembedded.org/mt/92239648/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/14] IMAGE_LOCALES_ARCHIVE: add option to prevent locale archive creation
From: Jate Sujjavanich
[YOCTO #14851]
Under some circumstances it is not desirable to create a combined locale
archive (/usr/lib/locale/locale-archive).
The new variable IMAGE_LOCALES_ARCHIVE defaults to '1', so the default
behaviour is not changed.
Modified to work with code before move to lib/oe/package_manager
Signed-off-by: Michael Thalmeier
Signed-off-by: Richard Purdie
(cherry picked from commit 8d78b819c2ec33fce3a34254fa90864ee5fa7617)
Signed-off-by: Jate Sujjavanich
Signed-off-by: Steve Sakoman
---
meta/classes/image.bbclass | 5 -
meta/lib/oe/package_manager.py | 13 +++--
2 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 1900eff412..0d77d2f676 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -124,7 +124,7 @@ python () {
def rootfs_variables(d):
from oe.rootfs import variable_depends
variables =
['IMAGE_DEVICE_TABLE','IMAGE_DEVICE_TABLES','BUILD_IMAGES_FROM_FEEDS','IMAGE_TYPES_MASKED','IMAGE_ROOTFS_ALIGNMENT','IMAGE_OVERHEAD_FACTOR','IMAGE_ROOTFS_SIZE','IMAGE_ROOTFS_EXTRA_SPACE',
-
'IMAGE_ROOTFS_MAXSIZE','IMAGE_NAME','IMAGE_LINK_NAME','IMAGE_MANIFEST','DEPLOY_DIR_IMAGE','IMAGE_FSTYPES','IMAGE_INSTALL_COMPLEMENTARY','IMAGE_LINGUAS',
'IMAGE_LINGUAS_COMPLEMENTARY',
+
'IMAGE_ROOTFS_MAXSIZE','IMAGE_NAME','IMAGE_LINK_NAME','IMAGE_MANIFEST','DEPLOY_DIR_IMAGE','IMAGE_FSTYPES','IMAGE_INSTALL_COMPLEMENTARY','IMAGE_LINGUAS',
'IMAGE_LINGUAS_COMPLEMENTARY', 'IMAGE_LOCALES_ARCHIVE',
'MULTILIBRE_ALLOW_REP','MULTILIB_TEMP_ROOTFS','MULTILIB_VARIANTS','MULTILIBS','ALL_MULTILIB_PACKAGE_ARCHS','MULTILIB_GLOBAL_VARIANTS','BAD_RECOMMENDATIONS','NO_RECOMMENDATIONS',
'PACKAGE_ARCHS','PACKAGE_CLASSES','TARGET_VENDOR','TARGET_ARCH','TARGET_OS','OVERRIDES','BBEXTENDVARIANT','FEED_DEPLOYDIR_BASE_URI','INTERCEPT_DIR','USE_DEVFS',
'CONVERSIONTYPES', 'IMAGE_GEN_DEBUGFS', 'ROOTFS_RO_UNNEEDED',
'IMGDEPLOYDIR', 'PACKAGE_EXCLUDE_COMPLEMENTARY',
'REPRODUCIBLE_TIMESTAMP_ROOTFS', 'IMAGE_INSTALL_DEBUGFS']
@@ -176,6 +176,9 @@ IMAGE_LINGUAS ?= "de-de fr-fr en-gb"
LINGUAS_INSTALL ?= "${@" ".join(map(lambda s: "locale-base-%s" % s,
d.getVar('IMAGE_LINGUAS').split()))}"
+# per default create a locale archive
+IMAGE_LOCALES_ARCHIVE ?= '1'
+
# Prefer image, but use the fallback files for lookups if the image ones
# aren't yet available.
PSEUDO_PASSWD = "${IMAGE_ROOTFS}:${STAGING_DIR_NATIVE}"
diff --git a/meta/lib/oe/package_manager.py b/meta/lib/oe/package_manager.py
index db988d9247..502dfbe3ed 100644
--- a/meta/lib/oe/package_manager.py
+++ b/meta/lib/oe/package_manager.py
@@ -611,12 +611,13 @@ class PackageManager(object, metaclass=ABCMeta):
"'%s' returned %d:\n%s" %
(' '.join(cmd), e.returncode,
e.output.decode("utf-8")))
-target_arch = self.d.getVar('TARGET_ARCH')
-localedir = oe.path.join(self.target_rootfs, self.d.getVar("libdir"),
"locale")
-if os.path.exists(localedir) and os.listdir(localedir):
-generate_locale_archive(self.d, self.target_rootfs, target_arch,
localedir)
-# And now delete the binary locales
-self.remove(fnmatch.filter(self.list_installed(),
"glibc-binary-localedata-*"), False)
+if self.d.getVar('IMAGE_LOCALES_ARCHIVE') == '1':
+target_arch = self.d.getVar('TARGET_ARCH')
+localedir = oe.path.join(self.target_rootfs,
self.d.getVar("libdir"), "locale")
+if os.path.exists(localedir) and os.listdir(localedir):
+generate_locale_archive(self.d, self.target_rootfs,
target_arch, localedir)
+# And now delete the binary locales
+self.remove(fnmatch.filter(self.list_installed(),
"glibc-binary-localedata-*"), False)
def deploy_dir_lock(self):
if self.deploy_dir is None:
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#167811):
https://lists.openembedded.org/g/openembedded-core/message/167811
Mute This Topic: https://lists.openembedded.org/mt/92239646/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/14] dropbear: break dependency on base package for -dev package
Otherwise the SDK fails to build as the main openssh and dropbear packages
conflict with each other
Signed-off-by: Steve Sakoman
(cherry picked from commit 4667abcc925ae0c430cccb480ec530506f6201ae)
Signed-off-by: Steve Sakoman
---
meta/recipes-core/dropbear/dropbear.inc | 5 +
1 file changed, 5 insertions(+)
diff --git a/meta/recipes-core/dropbear/dropbear.inc
b/meta/recipes-core/dropbear/dropbear.inc
index b949a9a337..026292230c 100644
--- a/meta/recipes-core/dropbear/dropbear.inc
+++ b/meta/recipes-core/dropbear/dropbear.inc
@@ -12,6 +12,11 @@ DEPENDS = "zlib virtual/crypt"
RPROVIDES_${PN} = "ssh sshd"
RCONFLICTS_${PN} = "openssh-sshd openssh"
+# break dependency on base package for -dev package
+# otherwise SDK fails to build as the main openssh and dropbear packages
+# conflict with each other
+RDEPENDS:${PN}-dev = ""
+
DEPENDS += "${@bb.utils.contains('DISTRO_FEATURES', 'pam', 'libpam', '', d)}"
SRC_URI = "http://matt.ucc.asn.au/dropbear/releases/dropbear-${PV}.tar.bz2 \
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#167810):
https://lists.openembedded.org/g/openembedded-core/message/167810
Mute This Topic: https://lists.openembedded.org/mt/92239645/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/14] openssh: break dependency on base package for -dev package
Otherwise the SDK fails to build as the main openssh and dropbear packages
conflict with each other
Signed-off-by: Steve Sakoman
(cherry picked from commit f90647e9dd95cfd29b5bdb8d7dcd688a10fc060c)
Signed-off-by: Steve Sakoman
---
meta/recipes-connectivity/openssh/openssh_8.2p1.bb | 5 +
1 file changed, 5 insertions(+)
diff --git a/meta/recipes-connectivity/openssh/openssh_8.2p1.bb
b/meta/recipes-connectivity/openssh/openssh_8.2p1.bb
index eaec26cac0..c529d1d060 100644
--- a/meta/recipes-connectivity/openssh/openssh_8.2p1.bb
+++ b/meta/recipes-connectivity/openssh/openssh_8.2p1.bb
@@ -196,6 +196,11 @@ RRECOMMENDS_${PN}-sshd_append_class-target = "\
${@bb.utils.filter('PACKAGECONFIG', 'rng-tools', d)} \
"
+# break dependency on base package for -dev package
+# otherwise SDK fails to build as the main openssh and dropbear packages
+# conflict with each other
+RDEPENDS:${PN}-dev = ""
+
# gdb would make attach-ptrace test pass rather than skip but not worth the
build dependencies
RDEPENDS_${PN}-ptest += "${PN}-sftp ${PN}-misc ${PN}-sftp-server make sed sudo
coreutils"
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#167809):
https://lists.openembedded.org/g/openembedded-core/message/167809
Mute This Topic: https://lists.openembedded.org/mt/92239644/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/14] oe-selftest-image: Ensure the image has sftp as well as dropbear
From: Richard Purdie We need sftp so that scp works with recent openssh. Use the packagegroup instead of a direct dependency to ensure this. Signed-off-by: Richard Purdie (cherry picked from commit 2b76c8e5fc8802bbe54371119e6bf6312bf2a8ec) Signed-off-by: Steve Sakoman --- meta-selftest/recipes-test/images/oe-selftest-image.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta-selftest/recipes-test/images/oe-selftest-image.bb b/meta-selftest/recipes-test/images/oe-selftest-image.bb index 5d4d10eef6..6246aae910 100644 --- a/meta-selftest/recipes-test/images/oe-selftest-image.bb +++ b/meta-selftest/recipes-test/images/oe-selftest-image.bb @@ -1,6 +1,6 @@ SUMMARY = "An image used during oe-selftest tests" -IMAGE_INSTALL = "packagegroup-core-boot dropbear" +IMAGE_INSTALL = "packagegroup-core-boot packagegroup-core-ssh-dropbear" IMAGE_FEATURES = "debug-tweaks" IMAGE_LINGUAS = " " -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#167808): https://lists.openembedded.org/g/openembedded-core/message/167808 Mute This Topic: https://lists.openembedded.org/mt/92239642/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/14] packagegroup-core-ssh-dropbear: Add openssh-sftp-server recommendation
From: Richard Purdie
Seems sad to have to do this but openssh is moving to use sftp instead
of scp to move files. This means scp from Fedora 36 will no longer be
able to move files to/from a dropbear based image. This breaks a number
of our key QA tests and I suspect will cause users pain too.
The sftp server from openssh is small (200kb uncompressed) and standalone
so adding it to the packagegroup seems to be the best way to preserve user
sanity. If people really don't want it, they can just use dropbear instead
of the packageground.
Signed-off-by: Richard Purdie
(cherry picked from commit a98188e83b2c027d99cc38e3367e1ec2a98efbb0)
Signed-off-by: Steve Sakoman
---
.../recipes-core/packagegroups/packagegroup-core-ssh-dropbear.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-core/packagegroups/packagegroup-core-ssh-dropbear.bb
b/meta/recipes-core/packagegroups/packagegroup-core-ssh-dropbear.bb
index 5ec3f6c927..5523f874db 100644
--- a/meta/recipes-core/packagegroups/packagegroup-core-ssh-dropbear.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-core-ssh-dropbear.bb
@@ -4,3 +4,4 @@ PR = "r1"
inherit packagegroup
RDEPENDS_${PN} = "dropbear"
+RRECOMMENDS_${PN} = "openssh-sftp-server"
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#167807):
https://lists.openembedded.org/g/openembedded-core/message/167807
Mute This Topic: https://lists.openembedded.org/mt/92239641/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/14] oeqa/runtime/scp: Disable scp test for dropbear
From: Richard Purdie Fedora is switching to use sftp as the backend for scp. This means the scp test fails on Fedora 36 hosts with a dropbear target as dropbear doesn't support sftp. This change is in the upstream openssh code, other distros have not yet changed the default but probably will follow. The easiest way to resolve test failures in dropbear images is to stop testing this against dropbear as it is no longer expected to work and will likely spread as the change filters through other distros. Signed-off-by: Richard Purdie (cherry picked from commit a71fc7d455400f406b0d607be712a1133fe91166) Signed-off-by: Steve Sakoman --- meta/lib/oeqa/runtime/cases/scp.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/lib/oeqa/runtime/cases/scp.py b/meta/lib/oeqa/runtime/cases/scp.py index 3a5f292152..f2bbc947d6 100644 --- a/meta/lib/oeqa/runtime/cases/scp.py +++ b/meta/lib/oeqa/runtime/cases/scp.py @@ -23,7 +23,7 @@ class ScpTest(OERuntimeTestCase): os.remove(cls.tmp_path) @OETestDepends(['ssh.SSHTest.test_ssh']) -@OEHasPackage(['openssh-scp', 'dropbear']) +@OEHasPackage(['openssh-scp']) def test_scp_file(self): dst = '/tmp/test_scp_file' -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#167806): https://lists.openembedded.org/g/openembedded-core/message/167806 Mute This Topic: https://lists.openembedded.org/mt/92239639/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/14] efivar: change branch name to main
From: Anuj Mittal Upstream has changed branch name to main from master. Change SRC_URI accordingly. Signed-off-by: Anuj Mittal Signed-off-by: Steve Sakoman --- meta/recipes-bsp/efivar/efivar_37.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-bsp/efivar/efivar_37.bb b/meta/recipes-bsp/efivar/efivar_37.bb index fa1fe1ecdf..858c61ae6a 100644 --- a/meta/recipes-bsp/efivar/efivar_37.bb +++ b/meta/recipes-bsp/efivar/efivar_37.bb @@ -7,7 +7,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=6626bb1e20189cfa95f2c508ba286393" COMPATIBLE_HOST = "(i.86|x86_64|arm|aarch64).*-linux" -SRC_URI = "git://github.com/rhinstaller/efivar.git;branch=master;protocol=https \ +SRC_URI = "git://github.com/rhinstaller/efivar.git;branch=main;protocol=https \ file://determinism.patch \ file://no-werror.patch" SRCREV = "c1d6b10e1ed4ba2be07f385eae5bceb694478a10" -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#167805): https://lists.openembedded.org/g/openembedded-core/message/167805 Mute This Topic: https://lists.openembedded.org/mt/92239638/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/14] linux-yocto/5.4: update to v5.4.203
From: Bruce Ashfield Updating to the latest korg -stable release that comprises the following commits: 871cbc208bf0 Linux 5.4.203 572cc34503d4 crypto: arm/ghash-ce - define fpu before fpu registers are referenced 3bf992f9d9a8 crypto: arm - use Kconfig based compiler checks for crypto opcodes 1b43c30cd5d5 ARM: 9029/1: Make iwmmxt.S support Clang's integrated assembler 9e00e5d195ed ARM: OMAP2+: drop unnecessary adrl 3657432a75e3 ARM: 8929/1: use APSR_nzcv instead of r15 as mrc operand 02c200fdba46 ARM: 8933/1: replace Sun/Solaris style flag on section directive 54e6ecd5b7ca crypto: arm/sha512-neon - avoid ADRL pseudo instruction 5e6f80033286 crypto: arm/sha256-neon - avoid ADRL pseudo instruction e120403c0e7c ARM: 8971/1: replace the sole use of a symbol with its definition 0a43679016f0 ARM: 8990/1: use VFP assembler mnemonics in register load/store macros 472671eec98a ARM: 8989/1: use .fpu assembler directives instead of assembler arguments 2bfb0d43a47c net: mscc: ocelot: allow unregistered IP multicast flooding 223d551a6681 kexec_file: drop weak attribute from arch_kexec_apply_relocations[_add] ab3ed204a146 powerpc/ftrace: Remove ftrace init tramp once kernel init is complete 77e2ad091850 drm: remove drm_fb_helper_modinit 9ef3ad40a81f Linux 5.4.202 ceda71d49f6b powerpc/pseries: wire up rng during setup_arch() ece983890287 kbuild: link vmlinux only once for CONFIG_TRIM_UNUSED_KSYMS (2nd attempt) 2a81e813141e random: update comment from copy_to_user() -> copy_to_iter() 80f0038d757e modpost: fix section mismatch check for exported init/exit sections d1359e4129ad ARM: cns3xxx: Fix refcount leak in cns3xxx_init 29ca9c4efacc ARM: Fix refcount leak in axxia_boot_secondary 734a4d15142b soc: bcm: brcmstb: pm: pm-arm: Fix refcount leak in brcmstb_pm_probe f9b77a529375 ARM: exynos: Fix refcount leak in exynos_map_pmu 615907ccc421 ARM: dts: imx6qdl: correct PU regulator ramp delay 93e6137d2a5b powerpc/powernv: wire up rng during setup_arch 97808c781721 powerpc/rtas: Allow ibm,platform-dump RTAS call with null buffer address b6232979320a powerpc: Enable execve syscall exit tracepoint e0701f150b28 parisc: Enable ARCH_HAS_STRICT_MODULE_RWX e5234a9d64a9 xtensa: Fix refcount leak bug in time.c a52972ee706b xtensa: xtfpga: Fix refcount leak bug in setup f0fc7cdf5f19 iio: adc: axp288: Override TS pin bias current for some models 11c7ea38be91 iio: adc: stm32: fix maximum clock rate for stm32mp15x 5e39397d60da iio: trigger: sysfs: fix use-after-free on remove 6d2e68d02171 iio: gyro: mpu3050: Fix the error handling in mpu3050_power_up() 1ad6d668543d iio: accel: mma8452: ignore the return value of reset operation a391bced8404 iio:accel:mxc4005: rearrange iio trigger get and register 23c158caa032 iio:accel:bma180: rearrange iio trigger get and register 8ea16a64aafc iio:chemical:ccs811: rearrange iio trigger get and register 2333db14d875 usb: chipidea: udc: check request status before setting device address 47e41b4dabbf xhci: turn off port power in shutdown d62d1c606db0 iio: adc: vf610: fix conversion mode sysfs node name 741b6c8363c2 s390/cpumf: Handle events cycles and instructions identical 4837d1c81223 gpio: winbond: Fix error code in winbond_gpio_get() bb18ad00c0b7 Revert "net/tls: fix tls_sk_proto_close executed repeatedly" 8c7a32b7c155 virtio_net: fix xdp_rxq_info bug after suspend/resume 28a78414f21e igb: Make DMA faster when CPU is active on the PCIe link a5ed066bc246 regmap-irq: Fix a bug in regmap_irq_enable() for type_in_mask chips 844168a5dabf ice: ethtool: advertise 1000M speeds properly e3a232e57670 afs: Fix dynamic root getattr cacab1e620e0 MIPS: Remove repetitive increase irq_err_count 788c954f194c x86/xen: Remove undefined behavior in setup_features() c7bdaad9cbfe udmabuf: add back sanity check 05c6c36c7931 net/tls: fix tls_sk_proto_close executed repeatedly 02da602bc2f3 erspan: do not assume transport header is always set d1592d3e362c drm/msm/mdp4: Fix refcount leak in mdp4_modeset_init_intf f1f9c2a5a3d9 net/sched: sch_netem: Fix arithmetic in netem_dump() for 32-bit platforms 47d31b97bf47 bonding: ARP monitor spams NETDEV_NOTIFY_PEERS notifiers 104a59b74577 phy: aquantia: Fix AN when higher speeds than 1G are not advertised 8ffe2e50e967 bpf: Fix request_sock leak in sk lookup helpers f074ab253988 USB: serial: option: add Quectel RM500K module support ea7b23eadebc USB: serial: option: add Quectel EM05-G modem 613c849d73df USB: serial: option: add Telit LE910Cx 0x1250 composition ae183969bd66 random: quiet urandom warning ratelimit suppression message 06a24ddba93a dm mirror log: clear log bits up to BITS_PER_LONG boundary 1f350f3cf0c1 dm era: commit metadata in postsuspend after worker stops 0e75acbe1b76 ata: libata: add
[OE-core][dunfell 05/14] linux-yocto/5.4: update to v5.4.199
From: Bruce Ashfield
Updating to the latest korg -stable release that comprises
the following commits:
a31bd366116c Linux 5.4.199
4cc40b1022bb x86/speculation/mmio: Print SMT warning
d49c22094e6f KVM: x86/speculation: Disable Fill buffer clear within guests
d96159263593 x86/speculation/mmio: Reuse SRBDS mitigation for SBDS
bc64f38b5a38 x86/speculation/srbds: Update SRBDS mitigation selection
020ce7495cfc x86/speculation/mmio: Add sysfs reporting for Processor MMIO
Stale Data
8d25482fc96a x86/speculation/mmio: Enable CPU Fill buffer clearing on idle
7f898baa2044 x86/bugs: Group MDS, TAA & Processor MMIO Stale Data
mitigations
0800f1b45bf6 x86/speculation/mmio: Add mitigation for Processor MMIO Stale
Data
ae649e0cbf76 x86/speculation: Add a common function for MD_CLEAR mitigation
update
814ccb673035 x86/speculation/mmio: Enumerate Processor MMIO Stale Data bug
91f8147c8371 Documentation: Add documentation for Processor MMIO Stale Data
1e9f4e8a7aa9 x86/cpu: Add another Alder Lake CPU to the Intel family
45e744de251c x86/cpu: Add Lakefield, Alder Lake and Rocket Lake models to
the to Intel CPU family
79568d551570 x86/cpu: Add Jasper Lake to Intel family
9e2efaa5dd10 cpu/speculation: Add prototype for cpu_show_srbds()
9d6e67bf5090 Linux 5.4.198
602b338e3c3c tcp: fix tcp_mtup_probe_success vs wrong snd_cwnd
b35e08edb2c2 mtd: cfi_cmdset_0002: Use chip_ready() for write on S29GL064N
0c12d7625502 md/raid0: Ignore RAID0 layout if the second zone has only one
device
0c4bc0a2f825 powerpc/32: Fix overread/overwrite of thread_struct via ptrace
3c953d47eb1e Input: bcm5974 - set missing URB_NO_TRANSFER_DMA_MAP urb flag
6ec537c50033 ixgbe: fix unexpected VLAN Rx in promisc mode on VF
24030768a7b4 ixgbe: fix bcast packets Rx on VF after promisc removal
3eca2c42daa4 nfc: st21nfca: fix memory leaks in EVT_TRANSACTION handling
31f9c39b4a37 nfc: st21nfca: fix incorrect validating logic in
EVT_TRANSACTION
4f4ab5004633 mmc: block: Fix CQE recovery reset success
0245434e381e ata: libata-transport: fix {dma|pio|xfer}_mode sysfs files
b651f70ed3a8 cifs: return errors during session setup during reconnects
850965edc861 ALSA: hda/conexant - Fix loopback issue with CX20632
6c04a2ae039b scripts/gdb: change kernel config dumping method
1a36f77dc23c vringh: Fix loop descriptors check in the indirect cases
a3f9b0afd8b4 nodemask: Fix return values to be unsigned
9b306339a511 cifs: version operations for smb20 unneeded when legacy
support disabled
5cb13cdc180a s390/gmap: voluntarily schedule during key setting
69893d6d7f5c nbd: fix io hung while disconnecting device
8a7da4ced236 nbd: fix race between nbd_alloc_config() and module removal
1be608e1ee1f nbd: call genl_unregister_family() first in nbd_cleanup()
045045b522c6 x86/cpu: Elide KCSAN for cpu_has() and friends
460083de66c4 modpost: fix undefined behavior of is_arm_mapping_symbol()
28fd384c78d7 drm/radeon: fix a possible null pointer dereference
9223144fdd64 ceph: allow ceph.dir.rctime xattr to be updatable
7df12bee5415 Revert "net: af_key: add check for pfkey_broadcast in function
pfkey_process"
0331d261c398 scsi: myrb: Fix up null pointer access on myrb_cleanup()
cf6b9316879f md: protect md_unregister_thread from reentrancy
99e4c67a5581 watchdog: wdat_wdt: Stop watchdog when rebooting the system
6fd031799e7b kernfs: Separate kernfs_pr_cont_buf and rename_lock.
19f4b51b836d serial: msm_serial: disable interrupts in __msm_console_write()
52a0d88c3280 staging: rtl8712: fix uninit-value in r871xu_drv_init()
58762f1c63c7 staging: rtl8712: fix uninit-value in usb_read8() and friends
1bcfb95de192 clocksource/drivers/sp804: Avoid error on multiple instances
d472c78cc829 extcon: Modify extcon device to be created after driver data
is set
fa0b2dd6829d misc: rtsx: set NULL intfdata when probe fails
d232ca0bbc7d usb: dwc2: gadget: don't reset gadget's driver->bus
3a7170a3de62 USB: hcd-pci: Fully suspend across freeze/thaw cycle
2dcec0bc142b drivers: usb: host: Fix deadlock in oxu_bus_suspend()
09a5958a2452 drivers: tty: serial: Fix deadlock in sa1100_set_termios()
c91a74b1f0f2 USB: host: isp116x: check return value after calling
platform_get_resource()
64b05fa212c7 drivers: staging: rtl8192e: Fix deadlock in
rtllib_beacons_stop()
1fbe033c5248 drivers: staging: rtl8192u: Fix deadlock in
ieee80211_beacons_stop()
8c014373f178 tty: Fix a possible resource leak in icom_probe
f6e07eb7ebec tty: synclink_gt: Fix null-pointer-dereference in slgt_clean()
1b04c934e1e6 lkdtm/usercopy: Expand size of "out of frame" object
ca2498cce875 iio: st_sensors: Add a local lock for protecting odr
ab75e02366e1 iio: dummy: iio_simple_dummy: check the return value of
kstrdup()
36acb4d9ce55 drm: imx: fix compiler warning with gcc-12
[OE-core][dunfell 04/14] vim: 8.2.5083 -> 9.0.0005
From: Richard Purdie
The license checksum changed due to a major version change in the referenced
file.
Signed-off-by: Richard Purdie
(cherry picked from commit 89f34d8aa4f4572d048dbb732ca4c83d443157fb)
Signed-off-by: Steve Sakoman
---
.../vim/{vim-tiny_8.2.bb => vim-tiny_9.0.bb}| 0
meta/recipes-support/vim/vim.inc| 6 +++---
meta/recipes-support/vim/{vim_8.2.bb => vim_9.0.bb} | 0
3 files changed, 3 insertions(+), 3 deletions(-)
rename meta/recipes-support/vim/{vim-tiny_8.2.bb => vim-tiny_9.0.bb} (100%)
rename meta/recipes-support/vim/{vim_8.2.bb => vim_9.0.bb} (100%)
diff --git a/meta/recipes-support/vim/vim-tiny_8.2.bb
b/meta/recipes-support/vim/vim-tiny_9.0.bb
similarity index 100%
rename from meta/recipes-support/vim/vim-tiny_8.2.bb
rename to meta/recipes-support/vim/vim-tiny_9.0.bb
diff --git a/meta/recipes-support/vim/vim.inc b/meta/recipes-support/vim/vim.inc
index 31a1b57be8..84c2eed4c8 100644
--- a/meta/recipes-support/vim/vim.inc
+++ b/meta/recipes-support/vim/vim.inc
@@ -11,7 +11,7 @@ RSUGGESTS_${PN} = "diffutils"
LICENSE = "vim"
LIC_FILES_CHKSUM = "file://LICENSE;md5=6b30ea4fa660c483b619924bc709ef99 \
-
file://runtime/doc/uganda.txt;md5=daf48235bb824c77fe8ae88d5f575f74"
+
file://runtime/doc/uganda.txt;md5=001ef779f422a0e9106d428c84495b4d"
SRC_URI = "git://github.com/vim/vim.git;branch=master;protocol=https \
file://disable_acl_header_check.patch \
@@ -21,8 +21,8 @@ SRC_URI =
"git://github.com/vim/vim.git;branch=master;protocol=https \
file://racefix.patch \
"
-PV .= ".5083"
-SRCREV = "db77c49401145d76441fbb3d22a1d7d987681c13"
+PV .= ".0005"
+SRCREV = "040674129f3382822eeb7b590380efa5228124a8"
# Remove when 8.3 is out
UPSTREAM_VERSION_UNKNOWN = "1"
diff --git a/meta/recipes-support/vim/vim_8.2.bb
b/meta/recipes-support/vim/vim_9.0.bb
similarity index 100%
rename from meta/recipes-support/vim/vim_8.2.bb
rename to meta/recipes-support/vim/vim_9.0.bb
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#167802):
https://lists.openembedded.org/g/openembedded-core/message/167802
Mute This Topic: https://lists.openembedded.org/mt/92239626/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 03/14] openssl: Minor security upgrade 1.1.1o to 1.1.1p
From: Ranjitsinh Rathod
This security upgrade fixes CVE-2022-2068 as per below link
Link: https://www.openssl.org/news/cl111.txt
Also, remove 73db5d82489b3ec09ccc772dfcee14fef0e8e908.patch and
b7ce611887cfac633aacc052b2e71a7f195418b8.patch as these two are part
1.1.1p now
Signed-off-by: Ranjitsinh Rathod
Signed-off-by: Ranjitsinh Rathod
Signed-off-by: Steve Sakoman
---
...5d82489b3ec09ccc772dfcee14fef0e8e908.patch | 192 --
...611887cfac633aacc052b2e71a7f195418b8.patch | 29 ---
.../{openssl_1.1.1o.bb => openssl_1.1.1p.bb} | 4 +-
3 files changed, 1 insertion(+), 224 deletions(-)
delete mode 100644
meta/recipes-connectivity/openssl/openssl/73db5d82489b3ec09ccc772dfcee14fef0e8e908.patch
delete mode 100644
meta/recipes-connectivity/openssl/openssl/b7ce611887cfac633aacc052b2e71a7f195418b8.patch
rename meta/recipes-connectivity/openssl/{openssl_1.1.1o.bb =>
openssl_1.1.1p.bb} (97%)
diff --git
a/meta/recipes-connectivity/openssl/openssl/73db5d82489b3ec09ccc772dfcee14fef0e8e908.patch
b/meta/recipes-connectivity/openssl/openssl/73db5d82489b3ec09ccc772dfcee14fef0e8e908.patch
deleted file mode 100644
index 438ecdcd32..00
---
a/meta/recipes-connectivity/openssl/openssl/73db5d82489b3ec09ccc772dfcee14fef0e8e908.patch
+++ /dev/null
@@ -1,192 +0,0 @@
-From 73db5d82489b3ec09ccc772dfcee14fef0e8e908 Mon Sep 17 00:00:00 2001
-From: Tomas Mraz
-Date: Wed, 1 Jun 2022 12:47:44 +0200
-Subject: [PATCH] Update expired SCT certificates
-
-Reviewed-by: Matt Caswell
-Reviewed-by: Dmitry Belyavskiy
-(Merged from https://github.com/openssl/openssl/pull/18446)
-
-Upstream-Status: Backport
[https://github.com/openssl/openssl/commit/73db5d82489b3ec09ccc772dfcee14fef0e8e908]
-Signed-off-by: Steve Sakoman
-
- test/certs/embeddedSCTs1-key.pem| 38 -
- test/certs/embeddedSCTs1.pem| 35 ---
- test/certs/embeddedSCTs1.sct| 12
- test/certs/embeddedSCTs1_issuer-key.pem | 15 ++
- test/certs/embeddedSCTs1_issuer.pem | 30 +--
- 5 files changed, 79 insertions(+), 51 deletions(-)
- create mode 100644 test/certs/embeddedSCTs1_issuer-key.pem
-
-diff --git a/test/certs/embeddedSCTs1-key.pem
b/test/certs/embeddedSCTs1-key.pem
-index e3e66d55c510..28dd206dbe8d 100644
a/test/certs/embeddedSCTs1-key.pem
-+++ b/test/certs/embeddedSCTs1-key.pem
-@@ -1,15 +1,27 @@
- -BEGIN RSA PRIVATE KEY-
--MIICWwIBAAKBgQC+75jnwmh3rjhfdTJaDB0ym+3xj6r015a/BH634c4VyVui+A7k
--WL19uG+KSyUhkaeb1wDDjpwDibRc1NyaEgqyHgy0HNDnKAWkEM2cW9tdSSdyba8X
--EPYBhzd+olsaHjnu0LiBGdwVTcaPfajjDK8VijPmyVCfSgWwFAn/Xdh+tQIDAQAB
--AoGAK/daG0vt6Fkqy/hdrtSJSKUVRoGRmS2nnba4Qzlwzh1+x2kdbMFuaOu2a37g
--PvmeQclheKZ3EG1+Jb4yShwLcBCV6pkRJhOKuhvqGnjngr6uBH4gMCjpZVj7GDMf
--flYHhdJCs3Cz/TY0wKN3o1Fldil2DHR/AEOc1nImeSp5/EUCQQDjKS3W957kYtTU
--X5BeRjvg03Ug8tJq6IFuhTFvUJ+XQ5bAc0DmxAbQVKqRS7Wje59zTknVvS+MFdeQ
--pz4dGuV7AkEA1y0X2yarIls+0A/S1uwkvwRTIkfS+QwFJ1zVya8sApRdKAcidIzA
--b70hkKLilU9+LrXg5iZdFp8l752qJiw9jwJAXjItN/7mfH4fExGto+or2kbVQxxt
--9LcFNPc2UJp2ExuL37HrL8YJrUnukOF8KJaSwBWuuFsC5GwKP4maUCdfEQJAUwBR
--83c3DEmmMRvpeH4erpA8gTyzZN3+HvDwhpvLnjMcvBQEdnDUykVqbSBnxrCjO+Fs
--n1qtDczWFVf8Cj2GgQJAQ14Awx32Cn9sF+3M+sEVtlAf6CqiEbkYeYdSCbsplMmZ
--1UoaxiwXY3z+B7epsRnnPR3KaceAlAxw2/zQJMFNOQ==
-+MIIEpQIBAAKCAQEAuIjpA4/iCpDA2mjywI5zG6IBX6bNcRQYDsB7Cv0VonNXtJBw
-+XxMENP4jVpvEmWpJ5iMBknGHV+XWBkngYapczIsY4LGn6aMU6ySABBVQpNOQSRfT
-+48xGGPR9mzOBG/yplmpFOVq1j+b65lskvAXKYaLFpFn3oY/pBSdcCNBP8LypVXAJ
-+b3IqEXsBL/ErgHG9bgIRP8VxBAaryCz77kLzAXkfHL2LfSGIfNONyEKB3xI94S4L
-+eouOSoWL1VkEfJs87vG4G5xoXw3KOHyiueQUUlMnu8p+Bx0xPVKPEsLje3R9k0rG
-+a5ca7dXAn9UypKKp25x4NXpnjGX5txVEYfNvqQIDAQABAoIBAE0zqhh9Z5n3+Vbm
-+tTht4CZdXqm/xQ9b0rzJNjDgtN5j1vuJuhlsgUQSVoJzZIqydvw7BPtZV8AkPagf
-+3Cm/9lb0kpHegVsziRrfCFes+zIZ+LE7sMAKxADIuIvnvkoRKHnvN8rI8lCj16/r
-+zbCD06mJSZp6sSj8ZgZr8wsU63zRGt1TeGM67uVW4agphfzuKGlXstPLsSMwknpF
-+nxFS2TYbitxa9oH76oCpEk5fywYsYgUP4TdzOzfVAgMzNSu0FobvWl0CECB+G3RQ
-+XQ5VWbYkFoj5XbE5kYz6sYHMQWL1NQpglUp+tAQ1T8Nca0CvbSpD77doRGm7UqYw
-+ziVQKokCgYEA6BtHwzyD1PHdAYtOcy7djrpnIMaiisSxEtMhctoxg8Vr2ePEvMpZ
-+S1ka8A1Pa9GzjaUk+VWKWsTf+VkmMHGtpB1sv8S7HjujlEmeQe7p8EltjstvLDmi
-+BhAA7ixvZpXXjQV4GCVdUVu0na6gFGGueZb2FHEXB8j1amVwleJj2lcCgYEAy4f3
-+2wXqJfz15+YdJPpG9BbH9d/plKJm5ID3p2ojAGo5qvVuIJMNJA4elcfHDwzCWVmn
-+MtR/WwtxYVVmy1BAnmk6HPSYc3CStvv1800vqN3fyJWtZ1P+8WBVZWZzIQdjdiaU
-+JSRevPnjQGc+SAZQQIk1yVclbz5790yuXsdIxf8CgYEApqlABC5lsvfga4Vt1UMn
-+j57FAkHe4KmPRCcZ83A88ZNGd/QWhkD9kR7wOsIz7wVqWiDkxavoZnjLIi4jP9HA
-+jwEZ3zER8wl70bRy0IEOtZzj8A6fSzAu6Q+Au4RokU6yse3lZ+EcepjQvhBvnXLu
-+ZxxAojj6AnsHzVf9WYJvlI0CgYEAoATIw/TEgRV/KNHs/BOiEWqP0Co5dVix2Nnk
-+3EVAO6VIrbbE3OuAm2ZWeaBWSujXLHSmVfpoHubCP6prZVI1W9aTkAxmh+xsDV3P
-+o3h+DiBTP1seuGx7tr7spQqFXeR3OH9gXktYCO/W0d3aQ7pjAjpehWv0zJ+ty2MI
-+fQ/lkXUCgYEAgbP+P5UmY7Fqm/mi6TprEJ/eYktji4Ne11GDKGFQCfjF5RdKhdw1
-+5+elGhZes+cpzu5Ak6zBDu4bviT+tRTWJu5lVLEzlHHv4nAU7Ks5Aj67ApH21AnP
-+RtlATdhWOt5Dkdq1WSpDfz5bvWgvyBx9D66dSmQdbKKe2dH327eQll4=
- -END RSA PRIVATE
[OE-core][dunfell 02/14] cve-check: hook cleanup to the BuildCompleted event, not CookerExit
From: Ross Burton
The cve-check class writes temporary files to preserve state across the
build, and cleans them up in a CookerExit handler.
However, in memory-resident builds the cooker won't exit in between
builds, so the state isn't cleared and the CVE report generation fails:
NOTE: Generating JSON CVE summary
ERROR: Error adding the same package twice
Easily solved by hooking to BuildCompleted, instead of CookerExit.
Signed-off-by: Ross Burton
Signed-off-by: Richard Purdie
(cherry picked from commit fccdcfd301de281a427bfee48d8ff47fa07b7259)
Signed-off-by: Steve Sakoman
---
meta/classes/cve-check.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index d0f6970db8..1688fe2dfe 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -164,7 +164,7 @@ python cve_check_cleanup () {
}
addhandler cve_check_cleanup
-cve_check_cleanup[eventmask] = "bb.cooker.CookerExit"
+cve_check_cleanup[eventmask] = "bb.event.BuildCompleted"
python cve_check_write_rootfs_manifest () {
"""
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#167800):
https://lists.openembedded.org/g/openembedded-core/message/167800
Mute This Topic: https://lists.openembedded.org/mt/92239618/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 01/14] cve-extra-exclusions: Clean up and ignore three CVEs (2xqemu and nasm)
From: Richard Purdie Remove obsolete comments/data from the file. Add in three CVEs to ignore. Two are qemu CVEs which upstream aren't particularly intersted in and aren't serious issues. Also ignore the nasm CVE found from fuzzing as this isn't a issue we'd expose from OE. Signed-off-by: Richard Purdie (cherry picked from commit 68291026aab2fa6ee1260ca95198dd1d568521e5) Signed-off-by: Steve Sakoman --- .../distro/include/cve-extra-exclusions.inc | 31 +-- 1 file changed, 15 insertions(+), 16 deletions(-) diff --git a/meta/conf/distro/include/cve-extra-exclusions.inc b/meta/conf/distro/include/cve-extra-exclusions.inc index e02a4d1fde..70442df991 100644 --- a/meta/conf/distro/include/cve-extra-exclusions.inc +++ b/meta/conf/distro/include/cve-extra-exclusions.inc @@ -53,24 +53,23 @@ CVE-2015-4778 CVE-2015-4779 CVE-2015-4780 CVE-2015-4781 CVE-2015-4782 CVE-2015-4 CVE-2015-4785 CVE-2015-4786 CVE-2015-4787 CVE-2015-4788 CVE-2015-4789 CVE-2015-4790 CVE-2016-0682 \ CVE-2016-0689 CVE-2016-0692 CVE-2016-0694 CVE-2016-3418 CVE-2020-2981" - CPE update pending - -# groff:groff-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2000-0803 -# Appears it was fixed in https://git.savannah.gnu.org/cgit/groff.git/commit/?id=07f95f1674217275ed4612f1dcaa95a88435c6a7 -# so from 1.17 onwards. Reported to the database for update by RP 2021/5/9. Update accepted 2021/5/10. -#CVE_CHECK_WHITELIST += "CVE-2000-0803" - - - - Upstream still working on - # qemu:qemu-native:qemu-system-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-20255 # There was a proposed patch https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg06098.html -# however qemu maintainers are sure the patch is incorrect and should not be applied. - -# wget https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-31879 -# https://mail.gnu.org/archive/html/bug-wget/2021-02/msg2.html -# No response upstream as of 2021/5/12 +# qemu maintainers say the patch is incorrect and should not be applied +# Ignore from OE's perspectivee as the issue is of low impact, at worst sitting in an infinite loop rather than exploitable +CVE_CHECK_IGNORE += "CVE-2021-20255" + +# qemu:qemu-native:qemu-system-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-12067 +# There was a proposed patch but rejected by upstream qemu. It is unclear if the issue can +# still be reproduced or where exactly any bug is. +# Ignore from OE's perspective as we'll pick up any fix when upstream accepts one. +CVE_CHECK_IGNORE += "CVE-2019-12067" + +# nasm:nasm-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-18974 +# It is a fuzzing related buffer overflow. It is of low impact since most devices +# wouldn't expose an assembler. The upstream is inactive and there is little to be +# done about the bug, ignore from an OE perspective. +CVE_CHECK_IGNORE += "CVE-2020-18974" -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#167799): https://lists.openembedded.org/g/openembedded-core/message/167799 Mute This Topic: https://lists.openembedded.org/mt/92239616/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 00/14] Patch review
Please review this 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/3880
The following changes since commit b75caf4a985e3c20996531785125eaffdc832104:
insane.bbclass: host-user-contaminated: Correct per package home path
(2022-06-29 05:15:49 -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
Anuj Mittal (1):
efivar: change branch name to main
Bruce Ashfield (2):
linux-yocto/5.4: update to v5.4.199
linux-yocto/5.4: update to v5.4.203
Jate Sujjavanich (1):
IMAGE_LOCALES_ARCHIVE: add option to prevent locale archive creation
Ranjitsinh Rathod (1):
openssl: Minor security upgrade 1.1.1o to 1.1.1p
Richard Purdie (5):
cve-extra-exclusions: Clean up and ignore three CVEs (2xqemu and nasm)
vim: 8.2.5083 -> 9.0.0005
oeqa/runtime/scp: Disable scp test for dropbear
packagegroup-core-ssh-dropbear: Add openssh-sftp-server recommendation
oe-selftest-image: Ensure the image has sftp as well as dropbear
Ross Burton (1):
cve-check: hook cleanup to the BuildCompleted event, not CookerExit
Steve Sakoman (3):
openssh: break dependency on base package for -dev package
dropbear: break dependency on base package for -dev package
qemu: add PACKAGECONFIG for capstone
.../recipes-test/images/oe-selftest-image.bb | 2 +-
meta/classes/cve-check.bbclass| 2 +-
meta/classes/image.bbclass| 5 +-
.../distro/include/cve-extra-exclusions.inc | 31 ++-
meta/lib/oe/package_manager.py| 13 +-
meta/lib/oeqa/runtime/cases/scp.py| 2 +-
meta/recipes-bsp/efivar/efivar_37.bb | 2 +-
.../openssh/openssh_8.2p1.bb | 5 +
...5d82489b3ec09ccc772dfcee14fef0e8e908.patch | 192 --
...611887cfac633aacc052b2e71a7f195418b8.patch | 29 ---
.../{openssl_1.1.1o.bb => openssl_1.1.1p.bb} | 4 +-
meta/recipes-core/dropbear/dropbear.inc | 5 +
.../packagegroup-core-ssh-dropbear.bb | 1 +
meta/recipes-devtools/qemu/qemu.inc | 1 +
.../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 +-
.../vim/{vim-tiny_8.2.bb => vim-tiny_9.0.bb} | 0
meta/recipes-support/vim/vim.inc | 6 +-
.../vim/{vim_8.2.bb => vim_9.0.bb}| 0
20 files changed, 64 insertions(+), 272 deletions(-)
delete mode 100644
meta/recipes-connectivity/openssl/openssl/73db5d82489b3ec09ccc772dfcee14fef0e8e908.patch
delete mode 100644
meta/recipes-connectivity/openssl/openssl/b7ce611887cfac633aacc052b2e71a7f195418b8.patch
rename meta/recipes-connectivity/openssl/{openssl_1.1.1o.bb =>
openssl_1.1.1p.bb} (97%)
rename meta/recipes-support/vim/{vim-tiny_8.2.bb => vim-tiny_9.0.bb} (100%)
rename meta/recipes-support/vim/{vim_8.2.bb => vim_9.0.bb} (100%)
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#167798):
https://lists.openembedded.org/g/openembedded-core/message/167798
Mute This Topic: https://lists.openembedded.org/mt/92239613/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] Linux 5.4.202
My mistake, sorry. Em qui., 7 de jul. de 2022 às 14:19, Otavio Salvador via lists.openembedded.org escreveu: > From: Greg Kroah-Hartman > > Link: > https://lore.kernel.org/r/20220627111927.641837...@linuxfoundation.org > Tested-by: Jon Hunter > Tested-by: Florian Fainelli > Tested-by: Shuah Khan > Tested-by: Guenter Roeck > Tested-by: Sudip Mukherjee > Tested-by: Hulk Robot > Signed-off-by: Greg Kroah-Hartman > --- > Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Makefile b/Makefile > index ae9156f804e5..021878dc23f9 100644 > --- a/Makefile > +++ b/Makefile > @@ -1,7 +1,7 @@ > # SPDX-License-Identifier: GPL-2.0 > VERSION = 5 > PATCHLEVEL = 4 > -SUBLEVEL = 201 > +SUBLEVEL = 202 > EXTRAVERSION = > NAME = Kleptomaniac Octopus > > -- > 2.36.1 > > > > > -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#167797): https://lists.openembedded.org/g/openembedded-core/message/167797 Mute This Topic: https://lists.openembedded.org/mt/92233428/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] Linux 5.4.202
From: Greg Kroah-Hartman Link: https://lore.kernel.org/r/20220627111927.641837...@linuxfoundation.org Tested-by: Jon Hunter Tested-by: Florian Fainelli Tested-by: Shuah Khan Tested-by: Guenter Roeck Tested-by: Sudip Mukherjee Tested-by: Hulk Robot Signed-off-by: Greg Kroah-Hartman --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index ae9156f804e5..021878dc23f9 100644 --- a/Makefile +++ b/Makefile @@ -1,7 +1,7 @@ # SPDX-License-Identifier: GPL-2.0 VERSION = 5 PATCHLEVEL = 4 -SUBLEVEL = 201 +SUBLEVEL = 202 EXTRAVERSION = NAME = Kleptomaniac Octopus -- 2.36.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#167796): https://lists.openembedded.org/g/openembedded-core/message/167796 Mute This Topic: https://lists.openembedded.org/mt/92233382/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 2/2] cargo-cross-canadian: Use SDK's flags during target linking
Signed-off-by: Otavio Salvador
---
.../cargo/cargo-cross-canadian.inc| 20 ++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/cargo/cargo-cross-canadian.inc
b/meta/recipes-devtools/cargo/cargo-cross-canadian.inc
index 7fc22a4128..01ba151d0a 100644
--- a/meta/recipes-devtools/cargo/cargo-cross-canadian.inc
+++ b/meta/recipes-devtools/cargo/cargo-cross-canadian.inc
@@ -39,6 +39,18 @@ do_compile:prepend () {
PKG_CONFIG_PATH="${RECIPE_SYSROOT_NATIVE}/usr/lib/pkgconfig:${PKG_CONFIG_PATH}"
}
+create_sdk_wrapper () {
+file="$1"
+shift
+
+cat <<- EOF > "${file}"
+ #!/bin/sh
+ \$$1 \$@
+ EOF
+
+chmod +x "$file"
+}
+
do_install () {
SYS_BINDIR=$(dirname ${D}${bindir})
install -d "${SYS_BINDIR}"
@@ -47,6 +59,9 @@ do_install () {
chrpath -r "\$ORIGIN/../lib" ${i}
done
+# Uses SDK's CC as linker so linked binaries works out of box.
+create_sdk_wrapper "${SYS_BINDIR}/target-rust-ccld" "CC"
+
ENV_SETUP_DIR=${D}${base_prefix}/environment-setup.d
mkdir "${ENV_SETUP_DIR}"
ENV_SETUP_SH="${ENV_SETUP_DIR}/cargo.sh"
@@ -58,7 +73,10 @@ do_install () {
touch "\$CARGO_HOME/config"
echo "[build]" >> "\$CARGO_HOME/config"
echo 'target = "'${TARGET_SYS}'"' >> "\$CARGO_HOME/config"
-fi
+ echo '# TARGET_SYS' >> "\$CARGO_HOME/config"
+ echo '[target.'${TARGET_SYS}']' >> "\$CARGO_HOME/config"
+ echo 'linker = "target-rust-ccld"' >> "\$CARGO_HOME/config"
+fi
# Keep the below off as long as HTTP/2 is disabled.
export CARGO_HTTP_MULTIPLEXING=false
--
2.36.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#167795):
https://lists.openembedded.org/g/openembedded-core/message/167795
Mute This Topic: https://lists.openembedded.org/mt/92233381/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 1/2] rust-common: Fix use of target definitions for SDK generation
We need full target passed for build so we changed the
rust-cross-canadian to use same code used in regular rust recipes and
added support to use specific llvm-target for the building host.
Fixes: ef566af964 ("rust: fix issue building cross-canadian tools for aarch64
on x86_64")
Fixes: bd36593ba3 ("rust-common: Drop LLVM_TARGET and simplify")
Fixes: 8ed000debb ("rust-common: Fix for target definitions returning
'NoneType' for arm")
Signed-off-by: Otavio Salvador
---
meta/recipes-devtools/rust/rust-common.inc| 21 --
.../rust/rust-cross-canadian-common.inc | 22 ---
2 files changed, 33 insertions(+), 10 deletions(-)
diff --git a/meta/recipes-devtools/rust/rust-common.inc
b/meta/recipes-devtools/rust/rust-common.inc
index ef70c48d0f..f8d365ecf8 100644
--- a/meta/recipes-devtools/rust/rust-common.inc
+++ b/meta/recipes-devtools/rust/rust-common.inc
@@ -119,12 +119,12 @@ def llvm_features(d):
## arm-unknown-linux-gnueabihf
-DATA_LAYOUT[arm] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
-TARGET_ENDIAN[arm] = "little"
-TARGET_POINTER_WIDTH[arm] = "32"
-TARGET_C_INT_WIDTH[arm] = "32"
-MAX_ATOMIC_WIDTH[arm] = "64"
-FEATURES[arm] = "+v6,+vfp2"
+DATA_LAYOUT[arm-eabi] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
+TARGET_ENDIAN[arm-eabi] = "little"
+TARGET_POINTER_WIDTH[arm-eabi] = "32"
+TARGET_C_INT_WIDTH[arm-eabi] = "32"
+MAX_ATOMIC_WIDTH[arm-eabi] = "64"
+FEATURES[arm-eabi] = "+v6,+vfp2"
## armv7-unknown-linux-gnueabihf
DATA_LAYOUT[armv7-eabi] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
@@ -304,12 +304,19 @@ def rust_gen_target(d, thing, wd, features, cpu, arch,
abi=""):
else:
arch_abi = rust_arch
+# When building for the building system we need to return the HOST target
+# or wrong flags are used.
+if thing is "BUILD":
+llvm_target = d.getVar('RUST_HOST_SYS', arch_abi)
+else:
+llvm_target = d.getVar('RUST_TARGET_SYS', arch_abi)
+
features = features or d.getVarFlag('FEATURES', arch_abi) or ""
features = features.strip()
# build tspec
tspec = {}
-tspec['llvm-target'] = d.getVar('RUST_TARGET_SYS', arch_abi)
+tspec['llvm-target'] = llvm_target
tspec['data-layout'] = d.getVarFlag('DATA_LAYOUT', arch_abi)
tspec['max-atomic-width'] = int(d.getVarFlag('MAX_ATOMIC_WIDTH', arch_abi))
tspec['target-pointer-width'] = d.getVarFlag('TARGET_POINTER_WIDTH',
arch_abi)
diff --git a/meta/recipes-devtools/rust/rust-cross-canadian-common.inc
b/meta/recipes-devtools/rust/rust-cross-canadian-common.inc
index 1f21c8af26..eff9212648 100644
--- a/meta/recipes-devtools/rust/rust-cross-canadian-common.inc
+++ b/meta/recipes-devtools/rust/rust-cross-canadian-common.inc
@@ -27,9 +27,23 @@ DEBUG_PREFIX_MAP =
"-fdebug-prefix-map=${WORKDIR}=/usr/src/debug/${PN}/${EXTENDP
python do_rust_gen_targets () {
wd = d.getVar('WORKDIR') + '/targets/'
-rust_gen_target(d, 'TARGET', wd, d.getVar('TARGET_LLVM_FEATURES') or "",
d.getVar('TARGET_LLVM_CPU'), d.getVar('TARGET_ARCH'))
-rust_gen_target(d, 'HOST', wd, "", "generic", d.getVar('HOST_ARCH'))
-rust_gen_target(d, 'BUILD', wd, "", "generic", d.getVar('BUILD_ARCH'))
+# It is important 'TARGET' is last here so that it overrides our less
+# informed choices for BUILD & HOST if TARGET happens to be the same as
+# either of them.
+for thing in ['BUILD', 'HOST', 'TARGET']:
+bb.debug(1, "rust_gen_target for " + thing)
+features = ""
+cpu = "generic"
+arch = d.getVar('{}_ARCH'.format(thing))
+abi = ""
+if thing is "TARGET":
+abi = d.getVar('ABIEXTENSION')
+# arm and armv7 have different targets in llvm
+if arch == "arm" and target_is_armv7(d):
+arch = 'armv7'
+features = d.getVar('TARGET_LLVM_FEATURES') or ""
+cpu = d.getVar('TARGET_LLVM_CPU')
+rust_gen_target(d, thing, wd, features, cpu, arch, abi)
}
INHIBIT_DEFAULT_RUST_DEPS = "1"
@@ -45,6 +59,8 @@ python do_configure:prepend() {
hosts = ["{}-unknown-linux-gnu".format(d.getVar("HOST_ARCH", True))]
}
+INSANE_SKIP:${PN} = "libdir"
+
INSANE_SKIP:${RUSTLIB_TARGET_PN} = "file-rdeps arch ldflags"
SKIP_FILEDEPS:${RUSTLIB_TARGET_PN} = "1"
--
2.36.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#167794):
https://lists.openembedded.org/g/openembedded-core/message/167794
Mute This Topic: https://lists.openembedded.org/mt/92233379/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] ltp: remove open-posix-testsuite build logs
On Thu, Jul 7, 2022 at 12:43 PM Ross Burton wrote:
>
> We don't need to package the open-posix-testsuite build logs. Typically
> these are just lines of "SUCCESS" but sometimes there will be compile
> warnings, which will include build paths.
>
> Signed-off-by: Ross Burton
> ---
> meta/recipes-extended/ltp/ltp_20220527.bb | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/meta/recipes-extended/ltp/ltp_20220527.bb
> b/meta/recipes-extended/ltp/ltp_20220527.bb
> index b3ef8f59105..e3abfd01e1c 100644
> --- a/meta/recipes-extended/ltp/ltp_20220527.bb
> +++ b/meta/recipes-extended/ltp/ltp_20220527.bb
> @@ -79,6 +79,9 @@ do_install(){
> # The controllers memcg_stree test seems to cause us hangs and takes 900s
> # (maybe we expect more regular output?), anyhow, skip it
> sed -e '/^memcg_stress/d' -i ${D}${prefix}/runtest/controllers
> +
> +# We don't need to ship the compile logs that open_posix_testsuite writes
> +rm -f ${D}${prefix}/testcases/open_posix_testsuite/logfile.*
> }
>
i was seeing build QA warnings this should help. Is this the only file
though I wonder since i saw a bunch of messages
> RDEPENDS:${PN} = "\
> --
> 2.34.1
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#167793):
https://lists.openembedded.org/g/openembedded-core/message/167793
Mute This Topic: https://lists.openembedded.org/mt/92232580/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] ltp: remove open-posix-testsuite build logs
We don't need to package the open-posix-testsuite build logs. Typically
these are just lines of "SUCCESS" but sometimes there will be compile
warnings, which will include build paths.
Signed-off-by: Ross Burton
---
meta/recipes-extended/ltp/ltp_20220527.bb | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/recipes-extended/ltp/ltp_20220527.bb
b/meta/recipes-extended/ltp/ltp_20220527.bb
index b3ef8f59105..e3abfd01e1c 100644
--- a/meta/recipes-extended/ltp/ltp_20220527.bb
+++ b/meta/recipes-extended/ltp/ltp_20220527.bb
@@ -79,6 +79,9 @@ do_install(){
# The controllers memcg_stree test seems to cause us hangs and takes 900s
# (maybe we expect more regular output?), anyhow, skip it
sed -e '/^memcg_stress/d' -i ${D}${prefix}/runtest/controllers
+
+# We don't need to ship the compile logs that open_posix_testsuite writes
+rm -f ${D}${prefix}/testcases/open_posix_testsuite/logfile.*
}
RDEPENDS:${PN} = "\
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#167792):
https://lists.openembedded.org/g/openembedded-core/message/167792
Mute This Topic: https://lists.openembedded.org/mt/92232580/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 2/2][dunfell] linux-yocto/5.4: update to v5.4.203
From: Bruce Ashfield Updating to the latest korg -stable release that comprises the following commits: 871cbc208bf0 Linux 5.4.203 572cc34503d4 crypto: arm/ghash-ce - define fpu before fpu registers are referenced 3bf992f9d9a8 crypto: arm - use Kconfig based compiler checks for crypto opcodes 1b43c30cd5d5 ARM: 9029/1: Make iwmmxt.S support Clang's integrated assembler 9e00e5d195ed ARM: OMAP2+: drop unnecessary adrl 3657432a75e3 ARM: 8929/1: use APSR_nzcv instead of r15 as mrc operand 02c200fdba46 ARM: 8933/1: replace Sun/Solaris style flag on section directive 54e6ecd5b7ca crypto: arm/sha512-neon - avoid ADRL pseudo instruction 5e6f80033286 crypto: arm/sha256-neon - avoid ADRL pseudo instruction e120403c0e7c ARM: 8971/1: replace the sole use of a symbol with its definition 0a43679016f0 ARM: 8990/1: use VFP assembler mnemonics in register load/store macros 472671eec98a ARM: 8989/1: use .fpu assembler directives instead of assembler arguments 2bfb0d43a47c net: mscc: ocelot: allow unregistered IP multicast flooding 223d551a6681 kexec_file: drop weak attribute from arch_kexec_apply_relocations[_add] ab3ed204a146 powerpc/ftrace: Remove ftrace init tramp once kernel init is complete 77e2ad091850 drm: remove drm_fb_helper_modinit 9ef3ad40a81f Linux 5.4.202 ceda71d49f6b powerpc/pseries: wire up rng during setup_arch() ece983890287 kbuild: link vmlinux only once for CONFIG_TRIM_UNUSED_KSYMS (2nd attempt) 2a81e813141e random: update comment from copy_to_user() -> copy_to_iter() 80f0038d757e modpost: fix section mismatch check for exported init/exit sections d1359e4129ad ARM: cns3xxx: Fix refcount leak in cns3xxx_init 29ca9c4efacc ARM: Fix refcount leak in axxia_boot_secondary 734a4d15142b soc: bcm: brcmstb: pm: pm-arm: Fix refcount leak in brcmstb_pm_probe f9b77a529375 ARM: exynos: Fix refcount leak in exynos_map_pmu 615907ccc421 ARM: dts: imx6qdl: correct PU regulator ramp delay 93e6137d2a5b powerpc/powernv: wire up rng during setup_arch 97808c781721 powerpc/rtas: Allow ibm,platform-dump RTAS call with null buffer address b6232979320a powerpc: Enable execve syscall exit tracepoint e0701f150b28 parisc: Enable ARCH_HAS_STRICT_MODULE_RWX e5234a9d64a9 xtensa: Fix refcount leak bug in time.c a52972ee706b xtensa: xtfpga: Fix refcount leak bug in setup f0fc7cdf5f19 iio: adc: axp288: Override TS pin bias current for some models 11c7ea38be91 iio: adc: stm32: fix maximum clock rate for stm32mp15x 5e39397d60da iio: trigger: sysfs: fix use-after-free on remove 6d2e68d02171 iio: gyro: mpu3050: Fix the error handling in mpu3050_power_up() 1ad6d668543d iio: accel: mma8452: ignore the return value of reset operation a391bced8404 iio:accel:mxc4005: rearrange iio trigger get and register 23c158caa032 iio:accel:bma180: rearrange iio trigger get and register 8ea16a64aafc iio:chemical:ccs811: rearrange iio trigger get and register 2333db14d875 usb: chipidea: udc: check request status before setting device address 47e41b4dabbf xhci: turn off port power in shutdown d62d1c606db0 iio: adc: vf610: fix conversion mode sysfs node name 741b6c8363c2 s390/cpumf: Handle events cycles and instructions identical 4837d1c81223 gpio: winbond: Fix error code in winbond_gpio_get() bb18ad00c0b7 Revert "net/tls: fix tls_sk_proto_close executed repeatedly" 8c7a32b7c155 virtio_net: fix xdp_rxq_info bug after suspend/resume 28a78414f21e igb: Make DMA faster when CPU is active on the PCIe link a5ed066bc246 regmap-irq: Fix a bug in regmap_irq_enable() for type_in_mask chips 844168a5dabf ice: ethtool: advertise 1000M speeds properly e3a232e57670 afs: Fix dynamic root getattr cacab1e620e0 MIPS: Remove repetitive increase irq_err_count 788c954f194c x86/xen: Remove undefined behavior in setup_features() c7bdaad9cbfe udmabuf: add back sanity check 05c6c36c7931 net/tls: fix tls_sk_proto_close executed repeatedly 02da602bc2f3 erspan: do not assume transport header is always set d1592d3e362c drm/msm/mdp4: Fix refcount leak in mdp4_modeset_init_intf f1f9c2a5a3d9 net/sched: sch_netem: Fix arithmetic in netem_dump() for 32-bit platforms 47d31b97bf47 bonding: ARP monitor spams NETDEV_NOTIFY_PEERS notifiers 104a59b74577 phy: aquantia: Fix AN when higher speeds than 1G are not advertised 8ffe2e50e967 bpf: Fix request_sock leak in sk lookup helpers f074ab253988 USB: serial: option: add Quectel RM500K module support ea7b23eadebc USB: serial: option: add Quectel EM05-G modem 613c849d73df USB: serial: option: add Telit LE910Cx 0x1250 composition ae183969bd66 random: quiet urandom warning ratelimit suppression message 06a24ddba93a dm mirror log: clear log bits up to BITS_PER_LONG boundary 1f350f3cf0c1 dm era: commit metadata in postsuspend after worker stops 0e75acbe1b76 ata: libata: add
[OE-core] [PATCH 1/2][dunfell] linux-yocto/5.4: update to v5.4.199
From: Bruce Ashfield
Updating to the latest korg -stable release that comprises
the following commits:
a31bd366116c Linux 5.4.199
4cc40b1022bb x86/speculation/mmio: Print SMT warning
d49c22094e6f KVM: x86/speculation: Disable Fill buffer clear within guests
d96159263593 x86/speculation/mmio: Reuse SRBDS mitigation for SBDS
bc64f38b5a38 x86/speculation/srbds: Update SRBDS mitigation selection
020ce7495cfc x86/speculation/mmio: Add sysfs reporting for Processor MMIO
Stale Data
8d25482fc96a x86/speculation/mmio: Enable CPU Fill buffer clearing on idle
7f898baa2044 x86/bugs: Group MDS, TAA & Processor MMIO Stale Data
mitigations
0800f1b45bf6 x86/speculation/mmio: Add mitigation for Processor MMIO Stale
Data
ae649e0cbf76 x86/speculation: Add a common function for MD_CLEAR mitigation
update
814ccb673035 x86/speculation/mmio: Enumerate Processor MMIO Stale Data bug
91f8147c8371 Documentation: Add documentation for Processor MMIO Stale Data
1e9f4e8a7aa9 x86/cpu: Add another Alder Lake CPU to the Intel family
45e744de251c x86/cpu: Add Lakefield, Alder Lake and Rocket Lake models to
the to Intel CPU family
79568d551570 x86/cpu: Add Jasper Lake to Intel family
9e2efaa5dd10 cpu/speculation: Add prototype for cpu_show_srbds()
9d6e67bf5090 Linux 5.4.198
602b338e3c3c tcp: fix tcp_mtup_probe_success vs wrong snd_cwnd
b35e08edb2c2 mtd: cfi_cmdset_0002: Use chip_ready() for write on S29GL064N
0c12d7625502 md/raid0: Ignore RAID0 layout if the second zone has only one
device
0c4bc0a2f825 powerpc/32: Fix overread/overwrite of thread_struct via ptrace
3c953d47eb1e Input: bcm5974 - set missing URB_NO_TRANSFER_DMA_MAP urb flag
6ec537c50033 ixgbe: fix unexpected VLAN Rx in promisc mode on VF
24030768a7b4 ixgbe: fix bcast packets Rx on VF after promisc removal
3eca2c42daa4 nfc: st21nfca: fix memory leaks in EVT_TRANSACTION handling
31f9c39b4a37 nfc: st21nfca: fix incorrect validating logic in
EVT_TRANSACTION
4f4ab5004633 mmc: block: Fix CQE recovery reset success
0245434e381e ata: libata-transport: fix {dma|pio|xfer}_mode sysfs files
b651f70ed3a8 cifs: return errors during session setup during reconnects
850965edc861 ALSA: hda/conexant - Fix loopback issue with CX20632
6c04a2ae039b scripts/gdb: change kernel config dumping method
1a36f77dc23c vringh: Fix loop descriptors check in the indirect cases
a3f9b0afd8b4 nodemask: Fix return values to be unsigned
9b306339a511 cifs: version operations for smb20 unneeded when legacy
support disabled
5cb13cdc180a s390/gmap: voluntarily schedule during key setting
69893d6d7f5c nbd: fix io hung while disconnecting device
8a7da4ced236 nbd: fix race between nbd_alloc_config() and module removal
1be608e1ee1f nbd: call genl_unregister_family() first in nbd_cleanup()
045045b522c6 x86/cpu: Elide KCSAN for cpu_has() and friends
460083de66c4 modpost: fix undefined behavior of is_arm_mapping_symbol()
28fd384c78d7 drm/radeon: fix a possible null pointer dereference
9223144fdd64 ceph: allow ceph.dir.rctime xattr to be updatable
7df12bee5415 Revert "net: af_key: add check for pfkey_broadcast in function
pfkey_process"
0331d261c398 scsi: myrb: Fix up null pointer access on myrb_cleanup()
cf6b9316879f md: protect md_unregister_thread from reentrancy
99e4c67a5581 watchdog: wdat_wdt: Stop watchdog when rebooting the system
6fd031799e7b kernfs: Separate kernfs_pr_cont_buf and rename_lock.
19f4b51b836d serial: msm_serial: disable interrupts in __msm_console_write()
52a0d88c3280 staging: rtl8712: fix uninit-value in r871xu_drv_init()
58762f1c63c7 staging: rtl8712: fix uninit-value in usb_read8() and friends
1bcfb95de192 clocksource/drivers/sp804: Avoid error on multiple instances
d472c78cc829 extcon: Modify extcon device to be created after driver data
is set
fa0b2dd6829d misc: rtsx: set NULL intfdata when probe fails
d232ca0bbc7d usb: dwc2: gadget: don't reset gadget's driver->bus
3a7170a3de62 USB: hcd-pci: Fully suspend across freeze/thaw cycle
2dcec0bc142b drivers: usb: host: Fix deadlock in oxu_bus_suspend()
09a5958a2452 drivers: tty: serial: Fix deadlock in sa1100_set_termios()
c91a74b1f0f2 USB: host: isp116x: check return value after calling
platform_get_resource()
64b05fa212c7 drivers: staging: rtl8192e: Fix deadlock in
rtllib_beacons_stop()
1fbe033c5248 drivers: staging: rtl8192u: Fix deadlock in
ieee80211_beacons_stop()
8c014373f178 tty: Fix a possible resource leak in icom_probe
f6e07eb7ebec tty: synclink_gt: Fix null-pointer-dereference in slgt_clean()
1b04c934e1e6 lkdtm/usercopy: Expand size of "out of frame" object
ca2498cce875 iio: st_sensors: Add a local lock for protecting odr
ab75e02366e1 iio: dummy: iio_simple_dummy: check the return value of
kstrdup()
36acb4d9ce55 drm: imx: fix compiler warning with gcc-12
Re: [OE-core] [PATCH] ltp: Remove -mfpmath=sse on x86
On 7 Jul 2022, at 16:10, Khem Raj via lists.openembedded.org wrote: > % gcc -m32 -msse3 -mfpmath=sse -xc /dev/null -c -mno-sse > cc1: warning: SSE instruction set disabled, using 387 arithmetics > [kraj@apollo /tmp] > % clang -m32 -msse3 -mfpmath=sse -xc /dev/null -c -mno-sse > error: the 'sse' unit is not supported with this instruction set So I just built ltp for qemux86-64 on my aarch64 host: | cc1: warning: SSE instruction set disabled, using 387 arithmetics | cc1: warning: SSE instruction set disabled, using 387 arithmetics | AS testcases/kernel/kvm/bootstrap_x86_64.o | make[5]: Nothing to be done for 'all'. | make[5]: Nothing to be done for 'all'. | CC testcases/kernel/kvm/lib_x86.o | CC testcases/kernel/kvm/lib_guest.o | cc1: warning: SSE instruction set disabled, using 387 arithmetics | ld: target elf64-x86-64 not found Looks like it’s also trying to use the host ld? Ross IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#167789): https://lists.openembedded.org/g/openembedded-core/message/167789 Mute This Topic: https://lists.openembedded.org/mt/9167/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core][kirkstone 00/30] Pull request (cover letter only)
The following changes since commit eea52e0c3d24c79464f4afdbc3c397e1cb982231:
build-appliance-image: Update to kirkstone head revision (2022-06-29 07:48:24
+0100)
are available in the Git repository at:
git://git.openembedded.org/openembedded-core-contrib stable/kirkstone-next
http://cgit.openembedded.org/openembedded-core-contrib/log/?h=stable/kirkstone-next
Ahmed Hossam (1):
insane.bbclass: host-user-contaminated: Correct per package home path
Alexander Kanavin (3):
wireless-regdb: upgrade 2022.04.08 -> 2022.06.06
oeqa/sdk: drop the nativesdk-python 2.x test
at: take tarballs from debian
David Bagonyi (1):
sanity.bbclass: Add ftps to accepted URI protocols for mirrors sanity
Jose Quaresma (1):
curl: backport openssl fix CN check error code
Kai Kang (1):
glibc-tests: not clear BBCLASSEXTEND
Lee Chee Yang (1):
ghostscript: fix CVE-2022-2085
Lucas Stach (1):
perf: sort-pmuevents: really keep array terminators
Martin Jansa (1):
wic: fix WicError message
Maxime Roussin-Bélanger (1):
libffi: fix native build being not portable
Muhammad Hamza (1):
initramfs-framework: move storage mounts to actual rootfs
Peter Bergin (1):
rust: fix issue building cross-canadian tools for aarch64 on x86_64
Peter Kjellerstedt (1):
base.bbclass: Correct the test for obsolete license exceptions
Pgowda (1):
binutils : CVE-2019-1010204
Raju Kumar Pothuraju (1):
kernel-uboot.bbclass: Use vmlinux.initramfs when
INITRAMFS_IMAGE_BUNDLE set
Richard Purdie (8):
unzip: Port debian fixes for two CVEs
cve-extra-exclusions: Clean up and ignore three CVEs (2xqemu and nasm)
vim: 8.2.5083 -> 9.0.0005
openssl: Upgrade 3.0.3 -> 3.0.4
coreutils: Tweak packaging variable names for coreutils-dev
oeqa/runtime/scp: Disable scp test for dropbear
packagegroup-core-ssh-dropbear: Add openssh-sftp-server recommendation
oe-selftest-image: Ensure the image has sftp as well as dropbear
Ross Burton (3):
cups: ignore CVE-2022-26691
busybox: fix CVE-2022-30065
cve-check: hook cleanup to the BuildCompleted event, not CookerExit
Steve Sakoman (2):
openssh: break dependency on base package for -dev package
dropbear: break dependency on base package for -dev package
Thomas Roos (1):
recipetool/devtool: Fix python egg whitespace issues in PACKAGECONFIG
.../recipes-test/images/oe-selftest-image.bb | 2 +-
meta/classes/base.bbclass | 4 +-
meta/classes/cve-check.bbclass| 2 +-
meta/classes/insane.bbclass | 2 +-
meta/classes/kernel-uboot.bbclass | 6 ++
meta/classes/sanity.bbclass | 2 +-
.../distro/include/cve-extra-exclusions.inc | 30 +-
meta/lib/oeqa/runtime/cases/scp.py| 2 +-
meta/lib/oeqa/sdk/cases/python.py | 11
meta/lib/oeqa/selftest/cases/devtool.py | 15 -
.../openssh/openssh_8.9p1.bb | 5 ++
...1-Configure-do-not-tweak-mips-cflags.patch | 10 ++--
...sysroot-and-debug-prefix-map-from-co.patch | 20 +++
...ea88c3888cc5cb3ebc94ffcef706c68bc1d2.patch | 55 ---
.../openssl/openssl/afalg.patch | 10 ++--
.../{openssl_3.0.3.bb => openssl_3.0.4.bb}| 3 +-
.../busybox/busybox/CVE-2022-30065.patch | 29 ++
meta/recipes-core/busybox/busybox_1.35.0.bb | 1 +
meta/recipes-core/coreutils/coreutils_9.0.bb | 3 +-
meta/recipes-core/dropbear/dropbear.inc | 5 ++
meta/recipes-core/glibc/glibc-tests_2.35.bb | 5 +-
.../initrdscripts/initramfs-framework/finish | 9 +++
.../packagegroup-core-ssh-dropbear.bb | 1 +
.../binutils/binutils-2.38.inc| 1 +
.../binutils/0014-CVE-2019-1010204.patch | 49 +
meta/recipes-devtools/rust/rust-common.inc| 5 +-
meta/recipes-extended/at/at_3.2.5.bb | 2 +-
meta/recipes-extended/cups/cups.inc | 2 +
.../ghostscript/CVE-2022-2085.patch | 44 +++
.../ghostscript/ghostscript_9.55.0.bb | 1 +
.../unzip/unzip/CVE-2022-0529.patch | 39 +
.../unzip/unzip/CVE-2022-0530.patch | 33 +++
meta/recipes-extended/unzip/unzip_6.0.bb | 2 +
.../perf/perf/sort-pmuevents.py | 5 +-
04.08.bb => wireless-regdb_2022.06.06.bb} | 2 +-
...0001-openssl-fix-CN-check-error-code.patch | 38 +
meta/recipes-support/curl/curl_7.82.0.bb | 1 +
meta/recipes-support/libffi/libffi_3.4.2.bb | 2 +-
.../vim/{vim-tiny_8.2.bb => vim-tiny_9.0.bb} | 0
meta/recipes-support/vim/vim.inc | 6 +-
.../vim/{vim_8.2.bb => vim_9.0.bb}| 0
.../lib/recipetool/create_buildsys_python.py | 13 +
scripts/wic | 2 +-
43 files changed, 353 insertions(+), 126 deletions(-)
delete mode 100644
meta/recipes-connectivity/openssl/openssl/770aea88c3888cc5cb3ebc94ffcef706c68bc1d2.patch
rename
Re: [OE-core] [PATCH 1/2] scripts/oe-setup-builddir: copy site.conf.sample out of template directories (if it exists)
> -Original Message- > From: Alexander Kanavin > Sent: den 7 juli 2022 16:48 > To: Peter Kjellerstedt > Cc: openembedded-core@lists.openembedded.org; Alexander Kanavin > > Subject: Re: [OE-core] [PATCH 1/2] scripts/oe-setup-builddir: copy > site.conf.sample out of template directories (if it exists) > > On Thu, 7 Jul 2022 at 16:38, Peter Kjellerstedt > wrote: > > > And in case you wonder what that wrapper actually does, it creates the > > bblayers.conf.sample file based on all layers that are found in the top > > directory. It also creates a local.conf.sample file by combining > fragment > > files in the layers (i.e., local.conf.sample.XX where XX is a number > > between 00 and 99). The local.conf.sample from meta-poky is considered > > to have XX == 50. The reason for this is that we quickly realized that > > the static templateconf directory setup was unusable for us when we > > want to be able to use layers in different combinations. > > Cheers. I'd say if you need to place lots of customizations into There actually isn't lots of configuration in those fragments. > local.conf that's not a recommended setup to begin with: as said > elsewhere it should have precisely two definitions: distro and > machine, and nothing else. What kind of things are in those fragments? In our BSP layer there is some configuration we want even if our distro layer is not used (e.g., SSTATE_DIR). It also sets a default MACHINE that matches one from our BSPs. In the distro layer, it sets DISTRO. It also adds some extra, commented variables that our users may want to enable in their local.conf files, much like the examples in the local.conf.sample from meta-poky. Part of this is of course related to that we use repo to fetch the layers we need and thus we do not have the luxury of bitbake specific tools like kas and whisk that can add bitbake configuration in addition to the actual layers. On the other hand, our environment is very similar to the default experience with poky from a user's perspective. > Should they be consolidated in machine and distro definitions? > > Alex //Peter -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#167787): https://lists.openembedded.org/g/openembedded-core/message/167787 Mute This Topic: https://lists.openembedded.org/mt/92212803/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] ltp: Remove -mfpmath=sse on x86
There are some tests in ltp where it conflicts especially for tunes used in qemux86, the test adds -mno-sse which does nullify -msse3 but does not nullify -mfpmath=sse and clang is pedantic about it whereas gcc just warns here is ltp cmd cd tmp/work/core2-32-yoe-linux/ltp/20220527-r0/git/testcases/kernel/kvm % ../../../../recipe-sysroot-native/usr/bin/i686-yoe-linux/i686-yoe-linux-clang -target i686-yoe-linux -m32 -march=core2 -mtune=core2 -msse3 -mfpmath=sse -mlittle-endian --dyld-prefix=/usr -Qunused-arguments -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -fmacro-prefix-map=/mnt/b/yoe/master/build/tmp/work/core2-32-yoe-linux/ltp/20220527-r0=/usr/src/debug/ltp/20220527-r0 -fdebug-prefix-map=/mnt/b/yoe/master/build/tmp/work/core2-32-yoe-linux/ltp/20220527-r0=/usr/src/debug/ltp/20220527-r0 -fdebug-prefix-map=/mnt/b/yoe/master/build/tmp/work/core2-32-yoe-linux/ltp/20220527-r0/recipe-sysroot= -fdebug-prefix-map=/mnt/b/yoe/master/build/tmp/work/core2-32-yoe-linux/ltp/20220527-r0/recipe-sysroot-native= -Wl,-z,relro,-z,now -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/mnt/b/yoe/master/build/tmp/work/core2-32-yoe-linux/ltp/20220527-r0/recipe-sysroot -I/mnt/b/yoe/master/build/tmp/work/core2-32-yoe-linux/ltp/20220527-r0/git/testcases/kernel/kvm/include -DCOMPILE_PAYLOAD -ffreestanding -O2 -Wall -fno-asynchronous-unwind-tables -mno-mmx -mno-sse -fno-pie -c -o lib_guest.o lib_guest.c here is a reduced case % gcc -m32 -msse3 -mfpmath=sse -xc /dev/null -c -mno-sse cc1: warning: SSE instruction set disabled, using 387 arithmetics [kraj@apollo /tmp] % clang -m32 -msse3 -mfpmath=sse -xc /dev/null -c -mno-sse error: the 'sse' unit is not supported with this instruction set On Thu, Jul 7, 2022 at 11:05 AM Khem Raj wrote: > > > > On 7/7/22 4:38 AM, Richard Purdie wrote: > > On Wed, 2022-07-06 at 20:59 -0700, Khem Raj wrote: > >> Fixes build errors seen with clang > >> error: the 'sse' unit is not supported with this instruction set > >> > >> Signed-off-by: Khem Raj > >> --- > >> meta/recipes-extended/ltp/ltp_20220527.bb | 1 + > >> 1 file changed, 1 insertion(+) > >> > >> diff --git a/meta/recipes-extended/ltp/ltp_20220527.bb > >> b/meta/recipes-extended/ltp/ltp_20220527.bb > >> index b3ef8f59105..034b62b321e 100644 > >> --- a/meta/recipes-extended/ltp/ltp_20220527.bb > >> +++ b/meta/recipes-extended/ltp/ltp_20220527.bb > >> @@ -19,6 +19,7 @@ EXTRA_OECONF:append:libc-musl = " LIBS=-lfts " > >> # is set to -O0 or frame pointers have been enabled by > >> -fno-omit-frame-pointer > >> # earlier in CFLAGS, etc. > >> CFLAGS:append:x86-64 = " -fomit-frame-pointer" > >> +TUNE_CCARGS:remove:x86 = "-mfpmath=sse" > >> > >> CFLAGS:append:powerpc64 = " -D__SANE_USERSPACE_TYPES__" > >> CFLAGS:append:mipsarchn64 = " -D__SANE_USERSPACE_TYPES__" > > > > I really don't like remove operations in OE-Core. If it is > > incompatible, why is it there in the first place? Does that need to be > > clang only? > > There are some tests in ltp where it conflicts especially for tunes used > in qemux86, the test adds -mno-sse which does nullify -msse3 not nullify > -mfpmath=sse > > > cd tmp/work/core2-32-yoe-linux/ltp/20220527-r0/git/testcases/kernel/kvm > > % > ../../../../recipe-sysroot-native/usr/bin/i686-yoe-linux/i686-yoe-linux-clang > -target i686-yoe-linux -m32 -march=core2 -mtune=core2 -msse3 > -mfpmath=sse -mlittle-endian --dyld-prefix=/usr -Qunused-arguments > -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed > -fmacro-prefix-map=/mnt/b/yoe/master/build/tmp/work/core2-32-yoe-linux/ltp/20220527-r0=/usr/src/debug/ltp/20220527-r0 > > -fdebug-prefix-map=/mnt/b/yoe/master/build/tmp/work/core2-32-yoe-linux/ltp/20220527-r0=/usr/src/debug/ltp/20220527-r0 > > -fdebug-prefix-map=/mnt/b/yoe/master/build/tmp/work/core2-32-yoe-linux/ltp/20220527-r0/recipe-sysroot= > > -fdebug-prefix-map=/mnt/b/yoe/master/build/tmp/work/core2-32-yoe-linux/ltp/20220527-r0/recipe-sysroot-native= > -Wl,-z,relro,-z,now -O2 -D_FORTIFY_SOURCE=2 -Wformat > -Wformat-security -Werror=format-security > --sysroot=/mnt/b/yoe/master/build/tmp/work/core2-32-yoe-linux/ltp/20220527-r0/recipe-sysroot > -I/mnt/b/yoe/master/build/tmp/work/core2-32-yoe-linux/ltp/20220527-r0/git/testcases/kernel/kvm/include > -DCOMPILE_PAYLOAD -ffreestanding -O2 -Wall > -fno-asynchronous-unwind-tables -mno-mmx -mno-sse -fno-pie -c -o > lib_guest.o lib_guest.c > > > > > Cheers, > > > > Richard > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#167786): https://lists.openembedded.org/g/openembedded-core/message/167786 Mute This Topic: https://lists.openembedded.org/mt/9167/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 2/3] oeqa/sysroot.py: Check bitbake return status
After re-thinking this is the correct version of the patch. We need to
ignore_status because we are asserting that it actually fails. Otherwise
the bitbake() will fail the test on the desired failure.
Paulo Neves
On 7/4/22 16:30, Richard Purdie wrote:
On Mon, 2022-07-04 at 16:28 +0200, Paulo Neves wrote:
On 7/4/22 16:16, Richard Purdie wrote:
On Sun, 2022-07-03 at 13:41 +0200, Paulo Neves wrote:
bitbake ran but we incorrectly did not assert the exit status needs to
be non 0. Now all sysroot tests commands expected to fail are verified
to do so.
Signed-off-by: Paulo Neves
---
meta/lib/oeqa/selftest/cases/sysroot.py | 5 +
1 file changed, 5 insertions(+)
diff --git a/meta/lib/oeqa/selftest/cases/sysroot.py
b/meta/lib/oeqa/selftest/cases/sysroot.py
index 588fc8c713..294ba4a4a0 100644
--- a/meta/lib/oeqa/selftest/cases/sysroot.py
+++ b/meta/lib/oeqa/selftest/cases/sysroot.py
@@ -45,6 +45,7 @@ TESTSTRING:pn-sysroot-test-arch2 = "%s"
expected = "maximum shebang size exceeded, the maximum size is 128.
[shebang-size]"
res = bitbake("sysroot-shebang-test-native -c populate_sysroot",
ignore_status=True)
self.assertTrue(expected in res.output, msg=res.output)
+self.assertTrue(res.status != 0)
def test_sysroot_la(self):
"""
I did have a question on this patch. Wouldn't it be simpler to remove
the "ignore_status=True" from the bitbake() call?
Cheers,
Richard
You are right. I guess the assert is more explicit and with the removal
of the ignore_status it becomes implicit. Let me know if you want me to
remove the assert and the ignore status and will submit a v2.
Please, I think that would be cleaner.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#167785):
https://lists.openembedded.org/g/openembedded-core/message/167785
Mute This Topic: https://lists.openembedded.org/mt/92145212/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 1/2] scripts/oe-setup-builddir: copy site.conf.sample out of template directories (if it exists)
On Thu, 7 Jul 2022 at 16:38, Peter Kjellerstedt wrote: > And in case you wonder what that wrapper actually does, it creates the > bblayers.conf.sample file based on all layers that are found in the top > directory. It also creates a local.conf.sample file by combining fragment > files in the layers (i.e., local.conf.sample.XX where XX is a number > between 00 and 99). The local.conf.sample from meta-poky is considered > to have XX == 50. The reason for this is that we quickly realized that > the static templateconf directory setup was unusable for us when we > want to be able to use layers in different combinations. Cheers. I'd say if you need to place lots of customizations into local.conf that's not a recommended setup to begin with: as said elsewhere it should have precisely two definitions: distro and machine, and nothing else. What kind of things are in those fragments? Should they be consolidated in machine and distro definitions? Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#167784): https://lists.openembedded.org/g/openembedded-core/message/167784 Mute This Topic: https://lists.openembedded.org/mt/92212803/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 1/2] scripts/oe-setup-builddir: copy site.conf.sample out of template directories (if it exists)
> -Original Message- > From: openembedded-core@lists.openembedded.org c...@lists.openembedded.org> On Behalf Of Alexander Kanavin > Sent: den 7 juli 2022 15:56 > To: Peter Kjellerstedt > Cc: openembedded-core@lists.openembedded.org; Alexander Kanavin > > Subject: Re: [OE-core] [PATCH 1/2] scripts/oe-setup-builddir: copy > site.conf.sample out of template directories (if it exists) > > On Thu, 7 Jul 2022 at 15:45, Peter Kjellerstedt > wrote: > > > > Setting up a build directory from standard poky > > > or oe-core templates (which I presume is how you set up builds) does > > > not hold a promise that what is being copied will not change in > > > potentially breaking ways. > > > > While I may be able to fix the environment for builds that use some of > > our layers, setting up pure poky builds will no longer work without > > manual intervention. > > Wait. How are you setting up pure poky builds right now, so that your > magic site.conf is correctly inserted into builds? > > Alex Actually, you can forget what I said. I had a look at our wrapper for oe-init-build-env, which is responsible for creating our templateconf directory, and it will of course not be affected by your change. (It was six years since I wrote that code, so my memory was obviously a bit fuzzy.) And in case you wonder what that wrapper actually does, it creates the bblayers.conf.sample file based on all layers that are found in the top directory. It also creates a local.conf.sample file by combining fragment files in the layers (i.e., local.conf.sample.XX where XX is a number between 00 and 99). The local.conf.sample from meta-poky is considered to have XX == 50. The reason for this is that we quickly realized that the static templateconf directory setup was unusable for us when we want to be able to use layers in different combinations. //Peter -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#167783): https://lists.openembedded.org/g/openembedded-core/message/167783 Mute This Topic: https://lists.openembedded.org/mt/92212803/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 1/2] scripts/oe-setup-builddir: copy site.conf.sample out of template directories (if it exists)
On Thu, 7 Jul 2022 at 15:45, Peter Kjellerstedt wrote: > > Setting up a build directory from standard poky > > or oe-core templates (which I presume is how you set up builds) does > > not hold a promise that what is being copied will not change in > > potentially breaking ways. > > While I may be able to fix the environment for builds that use some of > our layers, setting up pure poky builds will no longer work without > manual intervention. Wait. How are you setting up pure poky builds right now, so that your magic site.conf is correctly inserted into builds? Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#167782): https://lists.openembedded.org/g/openembedded-core/message/167782 Mute This Topic: https://lists.openembedded.org/mt/92212803/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] [PATCH] perl: Fix perms to avoid patch fails
On 7/7/22 03:26, Randy MacLeod wrote:
Hi K,
Add oe-core list and move poky to BCC to ensure follow to the main
oe-core code review list.
On 2022-06-17 03:13, K. wrote:
Fix missing write permissions to avoid problems with applying patches
in particular on compressed filesystems:
ERROR: perl-5.34.1-r0 do_patch: Applying patch
'0001-Somehow-this-module-breaks-through-the-perl-wrapper-.patch' on
target directory
'/home/kayo/devel/elpitech/poc/openbmc/build/evb-ast2600/tmp/work/armv7ahf-vfpv4d16-openbmc-linux-gnueabi/perl/5.34.1-r0/perl-5.34.1'
CmdError('quilt --quiltrc
/home/kayo/devel/elpitech/poc/openbmc/build/evb-ast2600/tmp/work/armv7ahf-vfpv4d16-openbmc-linux-gnueabi/perl/5.34.1-r0/recipe-sysroot-native/etc/quiltrc
push', 0, 'stdout: Applying patch
0001-Somehow-this-module-breaks-through-the-perl-wrapper-.patch
File cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Unix.pm is read-only;
trying to patch anyway
patching file cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Unix.pm
Hunk #1 succeeded at 1147 (offset 37 lines).
Hunk #2 succeeded at 2086 (offset 77 lines).
patch: setting attribute btrfs.compression for btrfs.compression:
Permission denied
Patch 0001-Somehow-this-module-breaks-through-the-perl-wrapper-.patch
does not apply (enforce with -f)
Signed-off-by: K
---
meta/recipes-devtools/perl/perl_5.36.0.bb | 7 +++
1 file changed, 7 insertions(+)
diff --git a/meta/recipes-devtools/perl/perl_5.36.0.bb
b/meta/recipes-devtools/perl/perl_5.36.0.bb
index 4456cdbcfb..6374717ab0 100644
--- a/meta/recipes-devtools/perl/perl_5.36.0.bb
+++ b/meta/recipes-devtools/perl/perl_5.36.0.bb
@@ -45,6 +45,13 @@ PACKAGECONFIG[gdbm] = ",-Ui_gdbm,gdbm"
# Don't generate comments in enc2xs output files. They are not
reproducible
export ENC2XS_NO_COMMENTS = "1"
+# Fix missing write permissions to avoid troubles
+# with applying patches on compressed filesystems
+do_fix_perms() {
+ find ${S} -type f ! -perm -u=w -exec chmod u+w {} \;
+}
I've never done a build on btrfs let alone on a compressed btrfs volume.
This does seem like it should affect many patches and not just the
perl ones.
Any idea why only perl was affected and why it only shows up on that
FS type?
This seems like a work-around rather than a proper fix to me so far.
../Randy
+addtask do_fix_perms after do_unpack before do_patch
+
do_configure:prepend() {
cp -rfp ${STAGING_DATADIR_NATIVE}/perl-cross/* ${S}
}
This patch is not needed as the issue has been fixed in open embedded
already in [1]. I think it is not yet in poky though.
[1]
https://github.com/openembedded/openembedded-core/commit/47973fd4f3fbb0af1a0d1bc2c39f2900a963177d
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#167781):
https://lists.openembedded.org/g/openembedded-core/message/167781
Mute This Topic: https://lists.openembedded.org/mt/92220035/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 1/2] scripts/oe-setup-builddir: copy site.conf.sample out of template directories (if it exists)
> -Original Message- > From: Alexander Kanavin > Sent: den 7 juli 2022 15:36 > To: Peter Kjellerstedt > Cc: openembedded-core@lists.openembedded.org; Alexander Kanavin > > Subject: Re: [OE-core] [PATCH 1/2] scripts/oe-setup-builddir: copy > site.conf.sample out of template directories (if it exists) > > On Thu, 7 Jul 2022 at 15:26, Peter Kjellerstedt > wrote: > > > While I can't speak for others, this change will break our build > > environment. > > We have a global site.conf file in an NFS directory that everyone use. It > > contains all proxy settings and similar that are required to build inside > > the > > corporate environment. Copying a dummy site.conf file into the local build > > directory will prevent the global file from being used. > > Then you need to create a configuration template that is specific to > your company first, and there's a convenient command to do that > provided in patch 2/2. While I haven't actually tried your new command, based on what you and others have written, it does not at all seem compatible with how our environment is setup and what it expects from poky. :( > Setting up a build directory from standard poky > or oe-core templates (which I presume is how you set up builds) does > not hold a promise that what is being copied will not change in > potentially breaking ways. While I may be able to fix the environment for builds that use some of our layers, setting up pure poky builds will no longer work without manual intervention. > Alex //Peter -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#167780): https://lists.openembedded.org/g/openembedded-core/message/167780 Mute This Topic: https://lists.openembedded.org/mt/92212803/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 1/2] scripts/oe-setup-builddir: copy site.conf.sample out of template directories (if it exists)
On Thu, 7 Jul 2022 at 15:26, Peter Kjellerstedt wrote: > While I can't speak for others, this change will break our build environment. > We have a global site.conf file in an NFS directory that everyone use. It > contains all proxy settings and similar that are required to build inside the > corporate environment. Copying a dummy site.conf file into the local build > directory will prevent the global file from being used. Then you need to create a configuration template that is specific to your company first, and there's a convenient command to do that provided in patch 2/2. Setting up a build directory from standard poky or oe-core templates (which I presume is how you set up builds) does not hold a promise that what is being copied will not change in potentially breaking ways. Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#167779): https://lists.openembedded.org/g/openembedded-core/message/167779 Mute This Topic: https://lists.openembedded.org/mt/92212803/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 1/2] scripts/oe-setup-builddir: copy site.conf.sample out of template directories (if it exists)
> -Original Message- > From: openembedded-core@lists.openembedded.org c...@lists.openembedded.org> On Behalf Of Alexander Kanavin > Sent: den 6 juli 2022 20:23 > To: openembedded-core@lists.openembedded.org > Cc: Alexander Kanavin > Subject: [OE-core] [PATCH 1/2] scripts/oe-setup-builddir: copy > site.conf.sample out of template directories (if it exists) > > This allows: > > 1. Showing users where and how to define these settings correctly when > setting up > a build from templates in poky (meta-poky/conf/site.conf.sample has commented > out examples and was previously unused). > > 2. Distributing site-specific settings with template configurations in other > layers, > so there's no need to set them up separately. > > Signed-off-by: Alexander Kanavin > --- > scripts/oe-setup-builddir | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/scripts/oe-setup-builddir b/scripts/oe-setup-builddir > index 54048e62ec..5ad6dd4138 100755 > --- a/scripts/oe-setup-builddir > +++ b/scripts/oe-setup-builddir > @@ -64,6 +64,7 @@ if [ -n "$TEMPLATECONF" ]; then > fi > OECORELAYERCONF="$TEMPLATECONF/bblayers.conf.sample" > OECORELOCALCONF="$TEMPLATECONF/local.conf.sample" > +OECORESITECONF="$TEMPLATECONF/site.conf.sample" > OECORENOTESCONF="$TEMPLATECONF/conf-notes.txt" > fi > > @@ -77,9 +78,11 @@ You had no conf/local.conf file. This configuration > file has therefore been > created for you with some default values. You may wish to edit it to, for > example, select a different MACHINE (target hardware). See conf/local.conf > for more information as common configuration options are commented. > - > +Also check conf/site.conf for site specific settings such as proxies and > +download cache locations. > EOM > cp -f "$OECORELOCALCONF" "$BUILDDIR/conf/local.conf" > +cp -f "$OECORESITECONF" "$BUILDDIR/conf/site.conf" || true > SHOWYPDOC=yes > fi > > @@ -107,6 +110,7 @@ fi > # Prevent disturbing a new GIT clone in same console > unset OECORELOCALCONF > unset OECORELAYERCONF > +unset OECORESITECONF > > # Ending the first-time run message. Show the YP Documentation banner. > if [ ! -z "$SHOWYPDOC" ]; then > -- > 2.30.2 While I can't speak for others, this change will break our build environment. We have a global site.conf file in an NFS directory that everyone use. It contains all proxy settings and similar that are required to build inside the corporate environment. Copying a dummy site.conf file into the local build directory will prevent the global file from being used. //Peter -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#167778): https://lists.openembedded.org/g/openembedded-core/message/167778 Mute This Topic: https://lists.openembedded.org/mt/92212803/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][RFC] Layer Setup JSON schema and example
On Thu, Jul 7, 2022 at 5:40 AM Alexander Kanavin wrote: > > On Thu, 7 Jul 2022 at 12:36, Ross Burton wrote: > > > Wait, how is YAML more readable, if JSON is valid YAML? > > > > But YAML is not valid JSON, and YAML is the one which can be readable, > > unlike JSON. > > YAML is also not an included python battery, while JSON is. I'll stick > with JSON for now, if you provide specific examples of how the JSON > that we're defining would look more readable rendered in YAML, that > would be appreciated. I generally agree that YAML is better for humans, but using JSON now allows us to make progress without having to hash out that discussion, and won't exclude using YAML in the future (since YAML is a strict superset of JSON). > > Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16): https://lists.openembedded.org/g/openembedded-core/message/16 Mute This Topic: https://lists.openembedded.org/mt/92214601/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] Build paths/reproduibility issues in master - help requested
On Thu, Jul 7, 2022 at 1:21 PM Richard Purdie wrote: > > On Thu, 2022-07-07 at 12:14 +0100, Alex Kiernan wrote: > > On Wed, Jul 6, 2022 at 5:40 PM Richard Purdie > > wrote: > > > > > > On Mon, 2022-07-04 at 22:28 +0100, Richard Purdie via > > > lists.openembedded.org wrote: > > > > On Mon, 2022-07-04 at 14:34 +0100, Richard Purdie via > > > > > > With docs enabled: > > > > > > stdio: WARNING: lib32-vala-0.56.1-r0 do_package_qa: QA Issue: File > > > > > > /usr/bin/vapigen-wrapper in package lib32-vala contains reference > > > > > > to TMPDIR [buildpaths] > > > > > > stdio: WARNING: rpm-1_4.17.0-r0 do_package_qa: QA Issue: File > > > > > > /usr/lib64/pkgconfig/rpm.pc in package rpm-dev contains reference > > > > > > to TMPDIR [buildpaths] > > > > > > stdio: WARNING: lib32-gtk-doc-1.33.2-r0 do_package_qa: QA Issue: > > > > > > File /usr/share/gtk-doc/python/gtkdoc/config_data.py in package > > > > > > lib32-gtk-doc contains reference to TMPDIR [buildpaths] > > > > > > stdio: WARNING: vala-0.56.1-r0 do_package_qa: QA Issue: File > > > > > > /usr/bin/vapigen-wrapper in package vala contains reference to > > > > > > TMPDIR [buildpaths] > > > > > > stdio: WARNING: gtk-doc-1.33.2-r0 do_package_qa: QA Issue: File > > > > > > /usr/share/gtk-doc/python/gtkdoc/config_data.py in package gtk-doc > > > > > > contains reference to TMPDIR [buildpaths] > > > > > > I think I have fixes out for rpm (via lua) and vala. gtk-doc remains. > > > > > > > > These still remain. In addition we also have: > > > > > > > > > > A musl ltp issue: > > > > > stdio: WARNING: ltp-20220527-r0 do_package_qa: QA Issue: File > > > > > /opt/ltp/testcases/open_posix_testsuite/logfile.conformance-all in > > > > > package ltp contains reference to TMPDIR [buildpaths] > > > > > > Still remaining. > > > > > > > > > > > > > Some multilib issues: > > > > > stdio: WARNING: lib32-vala-0.56.1-r0 do_package_qa: QA Issue: File > > > > > /usr/bin/vapigen-wrapper in package lib32-vala contains reference to > > > > > TMPDIR [buildpaths] > > > > > stdio: WARNING: vala-0.56.1-r0 do_package_qa: QA Issue: File > > > > > /usr/bin/vapigen-wrapper in package vala contains reference to TMPDIR > > > > > [buildpaths] > > > > > stdio: WARNING: rpm-1_4.17.0-r0 do_package_qa: QA Issue: File > > > > > /usr/lib64/pkgconfig/rpm.pc in package rpm-dev contains reference to > > > > > TMPDIR [buildpaths] > > > > > > These are probably fixed. > > > > > > > > qemuarm64: > > > > > stdio: WARNING: kernel-devsrc-1.0-r0 do_package_qa: QA Issue: File > > > > > /lib/modules/5.15.44-yocto-standard/build/include/generated/.vdso-offsets.h.cmd > > > > > in package kernel-devsrc contains reference to TMPDIR [buildpaths] > > > > > > Fix out from Bruce (thanks!) > > > > > > > > > > > > > meta-gplv2 issue: > > > > > stdio: WARNING: mc-4.7.5.2-r3 do_package_qa: QA Issue: File > > > > > /usr/libexec/mc/extfs.d/iso9660 in package mc-helpers contains > > > > > reference to TMPDIR [buildpaths] > > > > > stdio: WARNING: tar-1.17-r3 do_package_qa: QA Issue: File > > > > > /usr/src/debug/tar/1.17-r3/build/lib/string.h in package tar-src > > > > > contains reference to TMPDIR > > > > > > This may be the end of meta-gplv2 since nobody cares. > > > > > > > Much as I'd rather this just wasn't necessary, I'm taking a look. > > Ross has linked to some discussion about it. I'd just delete mc to be > honest, I can't see it being useful there. > > I think we need data on the use cases people are using it for and > seeing whether it really is still necessary or just an easy way out. > gnutls/gmp/nettle is the only set of dependencies I actually care about and having spent some time just now staring at the most recent licenses on them, I'm beginning to wonder if my need of the meta-gplv2 versions is only because meta-gplv2 exists as all three seem to have licenses now which don't give me a problem. -- Alex Kiernan -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#167776): https://lists.openembedded.org/g/openembedded-core/message/167776 Mute This Topic: https://lists.openembedded.org/mt/92128673/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] [RFC PATCH] bitbake-layers: add layer repositories/revisions save and restore tooling (aka 'layer configuration')
On 7/4/22 22:09, Andre McCurdy wrote: On Sat, Jul 2, 2022 at 4:13 AM Richard Purdie wrote: I admit I've been putting off this topic for a long time. I actually wrote up something about it about 5 years ago. I sent it to four people to get some opinions. The six opinions I got back made me despair. i have had a while to think about it though. The challenge is that everyone has a workflow they like today and they will tend to dislike anything that looks different. For that reason I think we need a high level tool which can work with the different approaches. Once we have that, I suspect we'll see some grow stronger and some will wither off, which is probably as it should be through natural evolution. The approach Alex has taken here does head in that direction but I'm not sure it goes quite far enough to get the fraction of users we need on board. I'm not going to comment directly on Alex's proposal at this point, I'd like to put some ideas out there and see what people think of them. I think you'll see that I'm in agreement with the idea/direction but I have a slightly bigger idea of how to do it, which will both be harder to implement but also have a better chance of getting more people on board. So, let me go into a proposal of what I think the tool we need looks like. I propose we create a new tool, lets call it "oe-setup". It is a standalone project in it's own git repo and it's first command would be "init" with a command line looking roughly like: oe-setup init oe-setup init oe-setup init oe-setup init oe-setup init The idea being that the repository has some "pre-canned" idea of certain project names, e.g. poky, yoe and whatever else we decide to support "out the box" (criteria tbd). Those project names have a default pre-canned config, or set of configs (e.g. taking branch/series names) so I'd want to see these all work: My proposal would be to try to reuse Linux kconfig. Users know how to run "make oldconfig", "make menuconfig", etc and I believe all key I'm not sure that is true. Many current users do not come from the kernel dev community so, they are not familiar with how kconfig operates. Philip distro / machine configuration along with which meta layers should be enabled, which branch to use, etc can all be captured within a kconfig .config file. The task at hand would then become writing a tool to translate from a .config file to a set of distro, machine, local.conf config files (and an image recipe?) + drive whichever tool will be used to fetch meta layer git repos. The "pre-canned" knowledge of poky, yoe, etc then just becomes a set of alternative defconfig files. Although if we can generate distro configs on the fly from a defconfig file then separate meta layers to hold distro configs starts to become redundant... As a reminder, here's the Buildroot README: https://github.com/buildroot/buildroot/blob/master/README With those first 2 steps a Buildroot user can effectively create their own custom distro and machine config... all from within the user-friendly menuconfig environment. The OE equivalent (Yocto Quick Start) is not only more complex and only tells a user how to build someone else's preset configurations. Creating a custom distro and machine config in OE is beyond the quick start and requires a full knowledge of bitbake syntax etc, etc. oe-setup init poky . oe-setup init poky dunfell . oe-setup init poky ./my-local-config.json . oe-setup init poky http://someserver/my-remote-config.json . We'd also allow something not in the default like of project names to be used directly with a url, or maybe added with an "add-project" command. This could work against a user local config file, a bit like git does with global config and adding remotes to a repo. You'll note I haven't made any mention of the tooling these use. The reason is that we don't actually care. I'd propose we teach the tool about a few common standards (kas, submodules, repo) in the form of plugins and then hand off to those tools to do the setup. I'd also propose we develop a "native" form where they perhaps aren't needed. the nice thing is we can have several "native" forms if needed so if one approach isn't working or we need to change it, we can. We may also want to consider an optional "sub-config" parameter which gets passed along to the underlying tool. One of my conclusions after thinking about this for a long time is we have a bootstrap problem. If everyone used git and git worked everywhere, things would be easier. They don't and it doesn't. My evidence? The bitbake fetcher. Much of the ugliness the bitbake fetcher deals with applies to layers as well. Some people need proxy support, some need mirror tarballs, some need floating revisions, some need complete lock down and so on. We could simplify the problem and just say those users "can manage". If we do that, we're giving up at the first hurdle on the idea what we can have a (mostly) universal tool. I'm not sure I'm
Re: [OE-core] Build paths/reproduibility issues in master - help requested
On Thu, Jul 7, 2022 at 12:29 PM Ross Burton wrote: > > On 7 Jul 2022, at 12:14, Alex Kiernan via lists.openembedded.org > wrote: > meta-gplv2 issue: > stdio: WARNING: mc-4.7.5.2-r3 do_package_qa: QA Issue: File > /usr/libexec/mc/extfs.d/iso9660 in package mc-helpers contains reference > to TMPDIR [buildpaths] > stdio: WARNING: tar-1.17-r3 do_package_qa: QA Issue: File > /usr/src/debug/tar/1.17-r3/build/lib/string.h in package tar-src > contains reference to TMPDIR > >> > >> This may be the end of meta-gplv2 since nobody cares. > >> > > > > Much as I'd rather this just wasn't necessary, I'm taking a look. > > Is this an admittance that you use meta-gplv2? Do you have an opinion on > this thread? > Sadly, yes, as a dependency through a vendor layer which is (currently) stuck on thud, rather than anything we depend on directly. The value for me is in being able to build with these kind of checks on master and find out what issues we're missing. > https://lists.openembedded.org/g/openembedded-architecture/message/1566 > Honestly I think it's probably the right approach, since keeping it alive perpetuates the problem (now trying to decide if I should just delete the two trivial fixes I have...) -- Alex Kiernan -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#167774): https://lists.openembedded.org/g/openembedded-core/message/167774 Mute This Topic: https://lists.openembedded.org/mt/92128673/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] Build paths/reproduibility issues in master - help requested
On Thu, 2022-07-07 at 12:14 +0100, Alex Kiernan wrote: > On Wed, Jul 6, 2022 at 5:40 PM Richard Purdie > wrote: > > > > On Mon, 2022-07-04 at 22:28 +0100, Richard Purdie via > > lists.openembedded.org wrote: > > > On Mon, 2022-07-04 at 14:34 +0100, Richard Purdie via > > > > > With docs enabled: > > > > > stdio: WARNING: lib32-vala-0.56.1-r0 do_package_qa: QA Issue: File > > > > > /usr/bin/vapigen-wrapper in package lib32-vala contains reference to > > > > > TMPDIR [buildpaths] > > > > > stdio: WARNING: rpm-1_4.17.0-r0 do_package_qa: QA Issue: File > > > > > /usr/lib64/pkgconfig/rpm.pc in package rpm-dev contains reference to > > > > > TMPDIR [buildpaths] > > > > > stdio: WARNING: lib32-gtk-doc-1.33.2-r0 do_package_qa: QA Issue: File > > > > > /usr/share/gtk-doc/python/gtkdoc/config_data.py in package > > > > > lib32-gtk-doc contains reference to TMPDIR [buildpaths] > > > > > stdio: WARNING: vala-0.56.1-r0 do_package_qa: QA Issue: File > > > > > /usr/bin/vapigen-wrapper in package vala contains reference to TMPDIR > > > > > [buildpaths] > > > > > stdio: WARNING: gtk-doc-1.33.2-r0 do_package_qa: QA Issue: File > > > > > /usr/share/gtk-doc/python/gtkdoc/config_data.py in package gtk-doc > > > > > contains reference to TMPDIR [buildpaths] > > > > I think I have fixes out for rpm (via lua) and vala. gtk-doc remains. > > > > > > These still remain. In addition we also have: > > > > > > > > A musl ltp issue: > > > > stdio: WARNING: ltp-20220527-r0 do_package_qa: QA Issue: File > > > > /opt/ltp/testcases/open_posix_testsuite/logfile.conformance-all in > > > > package ltp contains reference to TMPDIR [buildpaths] > > > > Still remaining. > > > > > > > > > > Some multilib issues: > > > > stdio: WARNING: lib32-vala-0.56.1-r0 do_package_qa: QA Issue: File > > > > /usr/bin/vapigen-wrapper in package lib32-vala contains reference to > > > > TMPDIR [buildpaths] > > > > stdio: WARNING: vala-0.56.1-r0 do_package_qa: QA Issue: File > > > > /usr/bin/vapigen-wrapper in package vala contains reference to TMPDIR > > > > [buildpaths] > > > > stdio: WARNING: rpm-1_4.17.0-r0 do_package_qa: QA Issue: File > > > > /usr/lib64/pkgconfig/rpm.pc in package rpm-dev contains reference to > > > > TMPDIR [buildpaths] > > > > These are probably fixed. > > > > > > qemuarm64: > > > > stdio: WARNING: kernel-devsrc-1.0-r0 do_package_qa: QA Issue: File > > > > /lib/modules/5.15.44-yocto-standard/build/include/generated/.vdso-offsets.h.cmd > > > > in package kernel-devsrc contains reference to TMPDIR [buildpaths] > > > > Fix out from Bruce (thanks!) > > > > > > > > > > meta-gplv2 issue: > > > > stdio: WARNING: mc-4.7.5.2-r3 do_package_qa: QA Issue: File > > > > /usr/libexec/mc/extfs.d/iso9660 in package mc-helpers contains > > > > reference to TMPDIR [buildpaths] > > > > stdio: WARNING: tar-1.17-r3 do_package_qa: QA Issue: File > > > > /usr/src/debug/tar/1.17-r3/build/lib/string.h in package tar-src > > > > contains reference to TMPDIR > > > > This may be the end of meta-gplv2 since nobody cares. > > > > Much as I'd rather this just wasn't necessary, I'm taking a look. Ross has linked to some discussion about it. I'd just delete mc to be honest, I can't see it being useful there. I think we need data on the use cases people are using it for and seeing whether it really is still necessary or just an easy way out. Cheers, Richard > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#167773): https://lists.openembedded.org/g/openembedded-core/message/167773 Mute This Topic: https://lists.openembedded.org/mt/92128673/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] gtk-doc: Remove hardcoded buildpath
When api-documentation is enabled, we see a hardcoded build path to xsltproc in
the target python configuration file. We curate PATH carefully so we don't
need the path there, tweak configure to remove it and solve the issue.
Signed-off-by: Richard Purdie
---
meta/recipes-gnome/gtk-doc/gtk-doc_1.33.2.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-gnome/gtk-doc/gtk-doc_1.33.2.bb
b/meta/recipes-gnome/gtk-doc/gtk-doc_1.33.2.bb
index 392913fcc65..150eca92747 100644
--- a/meta/recipes-gnome/gtk-doc/gtk-doc_1.33.2.bb
+++ b/meta/recipes-gnome/gtk-doc/gtk-doc_1.33.2.bb
@@ -18,6 +18,8 @@ PACKAGECONFIG ??= "${@bb.utils.contains("DISTRO_FEATURES",
"api-documentation",
PACKAGECONFIG[working-scripts] = ",,libxslt-native xmlto-native python3-six
python3-pygments"
PACKAGECONFIG[tests] = "--enable-tests,--disable-tests,glib-2.0"
+CACHED_CONFIGUREVARS += "ac_cv_path_XSLTPROC=xsltproc"
+
SRC_URI[archive.sha256sum] =
"cc1b709a20eb030a278a1f9842a362e00402b7f834ae1df4c1998a723152bf43"
SRC_URI += "file://0001-Do-not-hardocode-paths-to-perl-python-in-scripts.patch
\
file://0001-Do-not-error-out-if-xsltproc-is-not-found.patch \
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#167772):
https://lists.openembedded.org/g/openembedded-core/message/167772
Mute This Topic: https://lists.openembedded.org/mt/92226945/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] Build paths/reproduibility issues in master - help requested
On 7 Jul 2022, at 12:14, Alex Kiernan via lists.openembedded.org wrote: meta-gplv2 issue: stdio: WARNING: mc-4.7.5.2-r3 do_package_qa: QA Issue: File /usr/libexec/mc/extfs.d/iso9660 in package mc-helpers contains reference to TMPDIR [buildpaths] stdio: WARNING: tar-1.17-r3 do_package_qa: QA Issue: File /usr/src/debug/tar/1.17-r3/build/lib/string.h in package tar-src contains reference to TMPDIR >> >> This may be the end of meta-gplv2 since nobody cares. >> > > Much as I'd rather this just wasn't necessary, I'm taking a look. Is this an admittance that you use meta-gplv2? Do you have an opinion on this thread? https://lists.openembedded.org/g/openembedded-architecture/message/1566 Cheers, Ross IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#167771): https://lists.openembedded.org/g/openembedded-core/message/167771 Mute This Topic: https://lists.openembedded.org/mt/92128673/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] Build paths/reproduibility issues in master - help requested
On Wed, Jul 6, 2022 at 5:40 PM Richard Purdie wrote: > > On Mon, 2022-07-04 at 22:28 +0100, Richard Purdie via > lists.openembedded.org wrote: > > On Mon, 2022-07-04 at 14:34 +0100, Richard Purdie via > > > > With docs enabled: > > > > stdio: WARNING: lib32-vala-0.56.1-r0 do_package_qa: QA Issue: File > > > > /usr/bin/vapigen-wrapper in package lib32-vala contains reference to > > > > TMPDIR [buildpaths] > > > > stdio: WARNING: rpm-1_4.17.0-r0 do_package_qa: QA Issue: File > > > > /usr/lib64/pkgconfig/rpm.pc in package rpm-dev contains reference to > > > > TMPDIR [buildpaths] > > > > stdio: WARNING: lib32-gtk-doc-1.33.2-r0 do_package_qa: QA Issue: File > > > > /usr/share/gtk-doc/python/gtkdoc/config_data.py in package > > > > lib32-gtk-doc contains reference to TMPDIR [buildpaths] > > > > stdio: WARNING: vala-0.56.1-r0 do_package_qa: QA Issue: File > > > > /usr/bin/vapigen-wrapper in package vala contains reference to TMPDIR > > > > [buildpaths] > > > > stdio: WARNING: gtk-doc-1.33.2-r0 do_package_qa: QA Issue: File > > > > /usr/share/gtk-doc/python/gtkdoc/config_data.py in package gtk-doc > > > > contains reference to TMPDIR [buildpaths] > > I think I have fixes out for rpm (via lua) and vala. gtk-doc remains. > > > > These still remain. In addition we also have: > > > > > > A musl ltp issue: > > > stdio: WARNING: ltp-20220527-r0 do_package_qa: QA Issue: File > > > /opt/ltp/testcases/open_posix_testsuite/logfile.conformance-all in > > > package ltp contains reference to TMPDIR [buildpaths] > > Still remaining. > > > > > > > Some multilib issues: > > > stdio: WARNING: lib32-vala-0.56.1-r0 do_package_qa: QA Issue: File > > > /usr/bin/vapigen-wrapper in package lib32-vala contains reference to > > > TMPDIR [buildpaths] > > > stdio: WARNING: vala-0.56.1-r0 do_package_qa: QA Issue: File > > > /usr/bin/vapigen-wrapper in package vala contains reference to TMPDIR > > > [buildpaths] > > > stdio: WARNING: rpm-1_4.17.0-r0 do_package_qa: QA Issue: File > > > /usr/lib64/pkgconfig/rpm.pc in package rpm-dev contains reference to > > > TMPDIR [buildpaths] > > These are probably fixed. > > > > qemuarm64: > > > stdio: WARNING: kernel-devsrc-1.0-r0 do_package_qa: QA Issue: File > > > /lib/modules/5.15.44-yocto-standard/build/include/generated/.vdso-offsets.h.cmd > > > in package kernel-devsrc contains reference to TMPDIR [buildpaths] > > Fix out from Bruce (thanks!) > > > > > > > meta-gplv2 issue: > > > stdio: WARNING: mc-4.7.5.2-r3 do_package_qa: QA Issue: File > > > /usr/libexec/mc/extfs.d/iso9660 in package mc-helpers contains reference > > > to TMPDIR [buildpaths] > > > stdio: WARNING: tar-1.17-r3 do_package_qa: QA Issue: File > > > /usr/src/debug/tar/1.17-r3/build/lib/string.h in package tar-src contains > > > reference to TMPDIR > > This may be the end of meta-gplv2 since nobody cares. > Much as I'd rather this just wasn't necessary, I'm taking a look. > > > > > > Christopher replied about meta-virt which is much appreciated! > > > > With the .debug checking patch applied, we also see an issue with > > lttng-modules on beaglebone, edgerouter, and qemumips: > > > > stdio: WARNING: lttng-modules-2.13.4-r0 do_package_qa: QA Issue: File > > /lib/modules/5.15.36-yocto-standard/kernel/lttng-modules/lib/.debug/lttng-lib-ring-buffer.ko > > in package lttng-modules-dbg contains reference to TMPDIR > > Still remaining. > > Cheers, > > Richard > > > > -- Alex Kiernan -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#167770): https://lists.openembedded.org/g/openembedded-core/message/167770 Mute This Topic: https://lists.openembedded.org/mt/92128673/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][RFC] Layer Setup JSON schema and example
On Thu, 7 Jul 2022 at 12:36, Ross Burton wrote: > > Wait, how is YAML more readable, if JSON is valid YAML? > > But YAML is not valid JSON, and YAML is the one which can be readable, unlike > JSON. YAML is also not an included python battery, while JSON is. I'll stick with JSON for now, if you provide specific examples of how the JSON that we're defining would look more readable rendered in YAML, that would be appreciated. Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#167769): https://lists.openembedded.org/g/openembedded-core/message/167769 Mute This Topic: https://lists.openembedded.org/mt/92214601/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][RFC] Layer Setup JSON schema and example
> Wait, how is YAML more readable, if JSON is valid YAML? But YAML is not valid JSON, and YAML is the one which can be readable, unlike JSON. Ross IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#167768): https://lists.openembedded.org/g/openembedded-core/message/167768 Mute This Topic: https://lists.openembedded.org/mt/92214601/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] oeqa/selftest/bbtests: Update message lookup for test_git_unpack_nonetwork_fail
From: Alexandre Belloni
bitbake's output changed, update the test
Signed-off-by: Alexandre Belloni
---
meta/lib/oeqa/selftest/cases/bbtests.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/lib/oeqa/selftest/cases/bbtests.py
b/meta/lib/oeqa/selftest/cases/bbtests.py
index cfac7afcf49a..b42bbb651da2 100644
--- a/meta/lib/oeqa/selftest/cases/bbtests.py
+++ b/meta/lib/oeqa/selftest/cases/bbtests.py
@@ -350,4 +350,4 @@ INHERIT:remove = \"report-error\"
self.write_config("DISTROOVERRIDES .= \":gitunpack-enable-recipe\"")
result = bitbake('gitunpackoffline-fail -c fetch', ignore_status=True)
-self.assertTrue("Recipe uses a floating tag/branch without a fixed
SRCREV" in result.output, msg = "Recipe without PV set to SRCPV should have
failed: %s" % result.output)
+self.assertTrue(re.search("Recipe uses a floating tag/branch .* for
repo .* without a fixed SRCREV yet doesn't call bb.fetch2.get_srcrev()",
result.output), msg = "Recipe without PV set to SRCPV should have failed: %s" %
result.output)
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#167767):
https://lists.openembedded.org/g/openembedded-core/message/167767
Mute This Topic: https://lists.openembedded.org/mt/92225505/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] meta: introduce UBOOT_MKIMAGE_KERNEL_TYPE
On 07/07/2022 11:53:19+0200, Ming Liu wrote:
> Hi, Alexandre:
>
> Thanks for the review, I did not quite follow you, you meant the 'type'
> argument being replaced wrongly? I dont see how. Could you share some
> details about your comment?
>
See below...
> //Ming Liu
>
> Alexandre Belloni 於 2022年7月6日 週三 下午4:06寫道：
>
> > Hello,
> >
> > On 06/07/2022 13:10:28+0200, Ming Liu wrote:
> > > From: Ming Liu
> > >
> > > Sometimes an end user might want to choose another kernel type argument
> > > for uboot-mkimage other than "kernel", for instance: "kernel_noload".
> > >
> > > Let's introduce a variable UBOOT_MKIMAGE_KERNEL_TYPE to support that,
> > > and it could be used by BSP layers as well.
> > >
> > > Signed-off-by: Ming Liu
> > > ---
> > > meta/classes/kernel-fitimage.bbclass | 2 +-
> > > meta/classes/kernel-uboot.bbclass| 3 +++
> > > meta/classes/kernel-uimage.bbclass | 2 +-
> > > meta/lib/oeqa/selftest/cases/fitimage.py | 3 ++-
> > > 4 files changed, 7 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/meta/classes/kernel-fitimage.bbclass
> > b/meta/classes/kernel-fitimage.bbclass
> > > index 7e09b075ff..2112ae4cfa 100644
> > > --- a/meta/classes/kernel-fitimage.bbclass
> > > +++ b/meta/classes/kernel-fitimage.bbclass
> > > @@ -148,7 +148,7 @@ fitimage_emit_section_kernel() {
> > > kernel-$2 {
> > > description = "Linux kernel";
> > > data = /incbin/("$3");
> > > -type = "kernel";
> > > +type = "${UBOOT_MKIMAGE_KERNEL_TYPE}";
> > > arch = "${UBOOT_ARCH}";
> > > os = "linux";
> > > compression = "$4";
> > > diff --git a/meta/classes/kernel-uboot.bbclass
> > b/meta/classes/kernel-uboot.bbclass
> > > index 2facade818..1bc98e042d 100644
> > > --- a/meta/classes/kernel-uboot.bbclass
> > > +++ b/meta/classes/kernel-uboot.bbclass
> > > @@ -2,6 +2,9 @@
> > > FIT_KERNEL_COMP_ALG ?= "gzip"
> > > FIT_KERNEL_COMP_ALG_EXTENSION ?= ".gz"
> > >
> > > +# Kernel image type passed to mkimage (i.e. kernel kernel_noload...)
> > > +UBOOT_MKIMAGE_KERNEL_TYPE ?= "kernel"
> > > +
> > > uboot_prep_kimage() {
> > > if [ -e arch/${ARCH}/boot/compressed/vmlinux ]; then
> > > vmlinux_path="arch/${ARCH}/boot/compressed/vmlinux"
> > > diff --git a/meta/classes/kernel-uimage.bbclass
> > b/meta/classes/kernel-uimage.bbclass
> > > index cedb4fa070..e116bf0265 100644
> > > --- a/meta/classes/kernel-uimage.bbclass
> > > +++ b/meta/classes/kernel-uimage.bbclass
> > > @@ -30,6 +30,6 @@ do_uboot_mkimage() {
> > > awk '$3=="${UBOOT_ENTRYSYMBOL}" {print
> > "0x"$1;exit}'`
> > > fi
> > >
> > > - uboot-mkimage -A ${UBOOT_ARCH} -O linux -T kernel -C
> > "${linux_comp}" -a ${UBOOT_LOADADDRESS} -e $ENTRYPOINT -n
> > "${DISTRO_NAME}/${PV}/${MACHINE}" -d linux.bin ${B}/arch/${ARCH}/boot/uImage
> > > + uboot-mkimage -A ${UBOOT_ARCH} -O ${UBOOT_MKIMAGE_KERNEL_TYPE} -T
> > kernel -C "${linux_comp}" -a ${UBOOT_LOADADDRESS} -e $ENTRYPOINT -n
> > "${DISTRO_NAME}/${PV}/${MACHINE}" -d linux.bin ${B}/arch/${ARCH}/boot/uImage
> >
> > I feel like you replace the wrong argument here.
You replace 6O linux by -O ${UBOOT_MKIMAGE_KERNEL_TYPE} while your
commit message suggests you want to replace -T kernel.
> >
> > > rm -f linux.bin
> > > }
> > > diff --git a/meta/lib/oeqa/selftest/cases/fitimage.py
> > b/meta/lib/oeqa/selftest/cases/fitimage.py
> > > index e6bfd1257e..7e6479c9ca 100644
> > > --- a/meta/lib/oeqa/selftest/cases/fitimage.py
> > > +++ b/meta/lib/oeqa/selftest/cases/fitimage.py
> > > @@ -763,6 +763,7 @@ FIT_HASH_ALG = "sha256"
> > >
> > > kernel_load = str(get_bb_var('UBOOT_LOADADDRESS'))
> > > kernel_entry = str(get_bb_var('UBOOT_ENTRYPOINT'))
> > > +kernel_type = str(get_bb_var('UBOOT_MKIMAGE_KERNEL_TYPE'))
> > > kernel_compression = str(get_bb_var('FIT_KERNEL_COMP_ALG'))
> > > uboot_arch = str(get_bb_var('UBOOT_ARCH'))
> > > fit_hash_alg = str(get_bb_var('FIT_HASH_ALG'))
> > > @@ -775,7 +776,7 @@ FIT_HASH_ALG = "sha256"
> > > 'kernel-1 {',
> > > 'description = "Linux kernel";',
> > > 'data = /incbin/("linux.bin");',
> > > -'type = "kernel";',
> > > +'type = "' + kernel_type + '";',
> > > 'arch = "' + uboot_arch + '";',
> > > 'os = "linux";',
> > > 'compression = "' + kernel_compression + '";',
> > > --
> > > 2.25.1
> > >
> >
> > >
> > >
> > >
> >
> >
> > --
> > Alexandre Belloni, co-owner and COO, Bootlin
> > Embedded Linux and Kernel engineering
> > https://bootlin.com
> >
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#167766):
Re: [OE-core][RFC] Layer Setup JSON schema and example
On Thu, 7 Jul 2022 at 12:03, Ross Burton wrote: > JSON is terrible for humans to read or edit, is this intended to be purely > for the machine, or are humans meant to read it too? If humans are meant to > work on the file I’d really prefer something readable like YAML. Wait, how is YAML more readable, if JSON is valid YAML? Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#167765): https://lists.openembedded.org/g/openembedded-core/message/167765 Mute This Topic: https://lists.openembedded.org/mt/92214601/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][RFC] Layer Setup JSON schema and example
> On 6 Jul 2022, at 20:53, Joshua Watt via lists.openembedded.org > wrote: > > Defines a common schema for layer setup that can be consumed by tools to > know how to fetch and assemble layers for end users. Also includes an > example of the layer setup that constructs poky for reference. JSON is terrible for humans to read or edit, is this intended to be purely for the machine, or are humans meant to read it too? If humans are meant to work on the file I’d really prefer something readable like YAML. Ross IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#167764): https://lists.openembedded.org/g/openembedded-core/message/167764 Mute This Topic: https://lists.openembedded.org/mt/92214601/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] meta: introduce UBOOT_MKIMAGE_KERNEL_TYPE
Hi, Alexandre:
Thanks for the review, I did not quite follow you, you meant the 'type'
argument being replaced wrongly? I dont see how. Could you share some
details about your comment?
//Ming Liu
Alexandre Belloni 於 2022年7月6日 週三 下午4:06寫道：
> Hello,
>
> On 06/07/2022 13:10:28+0200, Ming Liu wrote:
> > From: Ming Liu
> >
> > Sometimes an end user might want to choose another kernel type argument
> > for uboot-mkimage other than "kernel", for instance: "kernel_noload".
> >
> > Let's introduce a variable UBOOT_MKIMAGE_KERNEL_TYPE to support that,
> > and it could be used by BSP layers as well.
> >
> > Signed-off-by: Ming Liu
> > ---
> > meta/classes/kernel-fitimage.bbclass | 2 +-
> > meta/classes/kernel-uboot.bbclass| 3 +++
> > meta/classes/kernel-uimage.bbclass | 2 +-
> > meta/lib/oeqa/selftest/cases/fitimage.py | 3 ++-
> > 4 files changed, 7 insertions(+), 3 deletions(-)
> >
> > diff --git a/meta/classes/kernel-fitimage.bbclass
> b/meta/classes/kernel-fitimage.bbclass
> > index 7e09b075ff..2112ae4cfa 100644
> > --- a/meta/classes/kernel-fitimage.bbclass
> > +++ b/meta/classes/kernel-fitimage.bbclass
> > @@ -148,7 +148,7 @@ fitimage_emit_section_kernel() {
> > kernel-$2 {
> > description = "Linux kernel";
> > data = /incbin/("$3");
> > -type = "kernel";
> > +type = "${UBOOT_MKIMAGE_KERNEL_TYPE}";
> > arch = "${UBOOT_ARCH}";
> > os = "linux";
> > compression = "$4";
> > diff --git a/meta/classes/kernel-uboot.bbclass
> b/meta/classes/kernel-uboot.bbclass
> > index 2facade818..1bc98e042d 100644
> > --- a/meta/classes/kernel-uboot.bbclass
> > +++ b/meta/classes/kernel-uboot.bbclass
> > @@ -2,6 +2,9 @@
> > FIT_KERNEL_COMP_ALG ?= "gzip"
> > FIT_KERNEL_COMP_ALG_EXTENSION ?= ".gz"
> >
> > +# Kernel image type passed to mkimage (i.e. kernel kernel_noload...)
> > +UBOOT_MKIMAGE_KERNEL_TYPE ?= "kernel"
> > +
> > uboot_prep_kimage() {
> > if [ -e arch/${ARCH}/boot/compressed/vmlinux ]; then
> > vmlinux_path="arch/${ARCH}/boot/compressed/vmlinux"
> > diff --git a/meta/classes/kernel-uimage.bbclass
> b/meta/classes/kernel-uimage.bbclass
> > index cedb4fa070..e116bf0265 100644
> > --- a/meta/classes/kernel-uimage.bbclass
> > +++ b/meta/classes/kernel-uimage.bbclass
> > @@ -30,6 +30,6 @@ do_uboot_mkimage() {
> > awk '$3=="${UBOOT_ENTRYSYMBOL}" {print
> "0x"$1;exit}'`
> > fi
> >
> > - uboot-mkimage -A ${UBOOT_ARCH} -O linux -T kernel -C
> "${linux_comp}" -a ${UBOOT_LOADADDRESS} -e $ENTRYPOINT -n
> "${DISTRO_NAME}/${PV}/${MACHINE}" -d linux.bin ${B}/arch/${ARCH}/boot/uImage
> > + uboot-mkimage -A ${UBOOT_ARCH} -O ${UBOOT_MKIMAGE_KERNEL_TYPE} -T
> kernel -C "${linux_comp}" -a ${UBOOT_LOADADDRESS} -e $ENTRYPOINT -n
> "${DISTRO_NAME}/${PV}/${MACHINE}" -d linux.bin ${B}/arch/${ARCH}/boot/uImage
>
> I feel like you replace the wrong argument here.
>
> > rm -f linux.bin
> > }
> > diff --git a/meta/lib/oeqa/selftest/cases/fitimage.py
> b/meta/lib/oeqa/selftest/cases/fitimage.py
> > index e6bfd1257e..7e6479c9ca 100644
> > --- a/meta/lib/oeqa/selftest/cases/fitimage.py
> > +++ b/meta/lib/oeqa/selftest/cases/fitimage.py
> > @@ -763,6 +763,7 @@ FIT_HASH_ALG = "sha256"
> >
> > kernel_load = str(get_bb_var('UBOOT_LOADADDRESS'))
> > kernel_entry = str(get_bb_var('UBOOT_ENTRYPOINT'))
> > +kernel_type = str(get_bb_var('UBOOT_MKIMAGE_KERNEL_TYPE'))
> > kernel_compression = str(get_bb_var('FIT_KERNEL_COMP_ALG'))
> > uboot_arch = str(get_bb_var('UBOOT_ARCH'))
> > fit_hash_alg = str(get_bb_var('FIT_HASH_ALG'))
> > @@ -775,7 +776,7 @@ FIT_HASH_ALG = "sha256"
> > 'kernel-1 {',
> > 'description = "Linux kernel";',
> > 'data = /incbin/("linux.bin");',
> > -'type = "kernel";',
> > +'type = "' + kernel_type + '";',
> > 'arch = "' + uboot_arch + '";',
> > 'os = "linux";',
> > 'compression = "' + kernel_compression + '";',
> > --
> > 2.25.1
> >
>
> >
> >
> >
>
>
> --
> Alexandre Belloni, co-owner and COO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#167763):
https://lists.openembedded.org/g/openembedded-core/message/167763
Mute This Topic: https://lists.openembedded.org/mt/92204115/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] ltp: Remove -mfpmath=sse on x86
On Wed, 2022-07-06 at 20:59 -0700, Khem Raj wrote: > Fixes build errors seen with clang > error: the 'sse' unit is not supported with this instruction set > > Signed-off-by: Khem Raj > --- > meta/recipes-extended/ltp/ltp_20220527.bb | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/meta/recipes-extended/ltp/ltp_20220527.bb > b/meta/recipes-extended/ltp/ltp_20220527.bb > index b3ef8f59105..034b62b321e 100644 > --- a/meta/recipes-extended/ltp/ltp_20220527.bb > +++ b/meta/recipes-extended/ltp/ltp_20220527.bb > @@ -19,6 +19,7 @@ EXTRA_OECONF:append:libc-musl = " LIBS=-lfts " > # is set to -O0 or frame pointers have been enabled by > -fno-omit-frame-pointer > # earlier in CFLAGS, etc. > CFLAGS:append:x86-64 = " -fomit-frame-pointer" > +TUNE_CCARGS:remove:x86 = "-mfpmath=sse" > > CFLAGS:append:powerpc64 = " -D__SANE_USERSPACE_TYPES__" > CFLAGS:append:mipsarchn64 = " -D__SANE_USERSPACE_TYPES__" I really don't like remove operations in OE-Core. If it is incompatible, why is it there in the first place? Does that need to be clang only? Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#167762): https://lists.openembedded.org/g/openembedded-core/message/167762 Mute This Topic: https://lists.openembedded.org/mt/9167/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] [meta-oe][master][PATCH 0/2] modemmanager update
Just realized that this went to the wrong mailing list, sorry. Please
ignore.
On Thu, 2022-07-07 at 10:17 +0200, Adrian Freihofer wrote:
> Update modemmanager and libqmi to latest stable.
>
> Adrian Freihofer (2):
> libqmi: upgrade 1.30.4 -> 1.30.8
> modemmanager: upgrade 1.18.8 -> 1.18.10
>
> .../libqmi/{libqmi_1.30.4.bb => libqmi_1.30.8.bb} | 2 +-
> .../{modemmanager_1.18.8.bb => modemmanager_1.18.10.bb} | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
> rename meta-oe/recipes-connectivity/libqmi/{libqmi_1.30.4.bb =>
> libqmi_1.30.8.bb} (95%)
> rename meta-oe/recipes-connectivity/modemmanager/{modemmanager_1.18.8.bb =>
> modemmanager_1.18.10.bb} (97%)
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#167761):
https://lists.openembedded.org/g/openembedded-core/message/167761
Mute This Topic: https://lists.openembedded.org/mt/92224454/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] [meta-oe][PATCH 1/2] libqmi: upgrade 1.30.4 -> 1.30.8
Wrong mailing list, should go to oe-devel.
Alex
On Thu, 7 Jul 2022 at 10:17, Adrian Freihofer
wrote:
>
> Update to latest stable version:
>
> 1.30.8
> * New request/response/indications:
> ** dms: new 'Foxconn FCC authentication v2' request/response.
>
> 1.30.6
> * build:
> ** meson: fix 'export_packages' in GIR setup.
> * libqmi-glib:
> ** net-port-manager: use unaligned netlink attribute length.
>
> Signed-off-by: Adrian Freihofer
> ---
> .../libqmi/{libqmi_1.30.4.bb => libqmi_1.30.8.bb} | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> rename meta-oe/recipes-connectivity/libqmi/{libqmi_1.30.4.bb =>
> libqmi_1.30.8.bb} (95%)
>
> diff --git a/meta-oe/recipes-connectivity/libqmi/libqmi_1.30.4.bb
> b/meta-oe/recipes-connectivity/libqmi/libqmi_1.30.8.bb
> similarity index 95%
> rename from meta-oe/recipes-connectivity/libqmi/libqmi_1.30.4.bb
> rename to meta-oe/recipes-connectivity/libqmi/libqmi_1.30.8.bb
> index 4807244a5..a1cfe29cc 100644
> --- a/meta-oe/recipes-connectivity/libqmi/libqmi_1.30.4.bb
> +++ b/meta-oe/recipes-connectivity/libqmi/libqmi_1.30.8.bb
> @@ -12,7 +12,7 @@ DEPENDS = "glib-2.0 glib-2.0-native"
>
> inherit meson pkgconfig bash-completion gobject-introspection
>
> -SRCREV ?= "f6c2feaf199e0f129a0bde8c5e6cba5f2117b564"
> +SRCREV ?= "95108b6eebfefa6621a1c34565f562eeca9308b9"
> # patch 0001 is on main branch upstream
> SRC_URI = "\
>
> git://gitlab.freedesktop.org/mobile-broadband/libqmi.git;protocol=https;branch=qmi-1-30
> \
> --
> 2.35.3
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#167760):
https://lists.openembedded.org/g/openembedded-core/message/167760
Mute This Topic: https://lists.openembedded.org/mt/92224455/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [meta-oe][PATCH 1/2] libqmi: upgrade 1.30.4 -> 1.30.8
Update to latest stable version:
1.30.8
* New request/response/indications:
** dms: new 'Foxconn FCC authentication v2' request/response.
1.30.6
* build:
** meson: fix 'export_packages' in GIR setup.
* libqmi-glib:
** net-port-manager: use unaligned netlink attribute length.
Signed-off-by: Adrian Freihofer
---
.../libqmi/{libqmi_1.30.4.bb => libqmi_1.30.8.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta-oe/recipes-connectivity/libqmi/{libqmi_1.30.4.bb =>
libqmi_1.30.8.bb} (95%)
diff --git a/meta-oe/recipes-connectivity/libqmi/libqmi_1.30.4.bb
b/meta-oe/recipes-connectivity/libqmi/libqmi_1.30.8.bb
similarity index 95%
rename from meta-oe/recipes-connectivity/libqmi/libqmi_1.30.4.bb
rename to meta-oe/recipes-connectivity/libqmi/libqmi_1.30.8.bb
index 4807244a5..a1cfe29cc 100644
--- a/meta-oe/recipes-connectivity/libqmi/libqmi_1.30.4.bb
+++ b/meta-oe/recipes-connectivity/libqmi/libqmi_1.30.8.bb
@@ -12,7 +12,7 @@ DEPENDS = "glib-2.0 glib-2.0-native"
inherit meson pkgconfig bash-completion gobject-introspection
-SRCREV ?= "f6c2feaf199e0f129a0bde8c5e6cba5f2117b564"
+SRCREV ?= "95108b6eebfefa6621a1c34565f562eeca9308b9"
# patch 0001 is on main branch upstream
SRC_URI = "\
git://gitlab.freedesktop.org/mobile-broadband/libqmi.git;protocol=https;branch=qmi-1-30
\
--
2.35.3
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#167759):
https://lists.openembedded.org/g/openembedded-core/message/167759
Mute This Topic: https://lists.openembedded.org/mt/92224455/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [meta-oe][master][PATCH 0/2] modemmanager update
Update modemmanager and libqmi to latest stable.
Adrian Freihofer (2):
libqmi: upgrade 1.30.4 -> 1.30.8
modemmanager: upgrade 1.18.8 -> 1.18.10
.../libqmi/{libqmi_1.30.4.bb => libqmi_1.30.8.bb} | 2 +-
.../{modemmanager_1.18.8.bb => modemmanager_1.18.10.bb} | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
rename meta-oe/recipes-connectivity/libqmi/{libqmi_1.30.4.bb =>
libqmi_1.30.8.bb} (95%)
rename meta-oe/recipes-connectivity/modemmanager/{modemmanager_1.18.8.bb =>
modemmanager_1.18.10.bb} (97%)
--
2.35.3
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#167758):
https://lists.openembedded.org/g/openembedded-core/message/167758
Mute This Topic: https://lists.openembedded.org/mt/92224454/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
