[OE-core][dunfell 00/16] Pull request (cover letter only)
The following changes since commit 5bfdb6bfbd6f1de10d415228e5a5ebe01a623e2a:
file: add PACKAGECONFIG for auto options (2020-05-14 06:33:16 -1000)
are available in the Git repository at:
git://git.openembedded.org/openembedded-core-contrib stable/dunfell-next
http://cgit.openembedded.org/openembedded-core-contrib/log/?h=stable/dunfell-next
Adrian Bunk (2):
git: Upgrade 2.24.1 -> 2.24.3
wireless-regdb: Upgrade 2019.06.03 -> 2020.04.29
Alexander Kanavin (1):
testresults.json: add duration of the tests as well
Aníbal Limón (3):
recipes-kernel/linux-firmware: Add wlanmdsp.mbn to qcom-modem package
recipes-kernel/linux-firmware: Add adreno-a630 firmware package
linux-firmware: Update to 20200122 -> 20200421
Jan-Simon Moeller (1):
file: add bzip2-replacement-native to DEPENDS to fix sstate issue
Kai Kang (1):
gcr: depends on gnupg-native
Lee Chee Yang (1):
qemu: fix CVE-2020-11869
Marek Vasut (1):
libubootenv: Depend on zlib
Mingli Yu (2):
bison: fix the parallel build
python3-setuptools: add the missing rdepends
Paul Barker (2):
archiver.bbclass: Make do_deploy_archives a recursive dependency
avahi: Don't advertise example services by default
Quentin Schulz (1):
base/insane: Check pkgs lics are subset of recipe lics only once
zhengruoqin (1):
make-mod-scripts: Fix dependence error.
meta/classes/archiver.bbclass | 4 +-
meta/classes/base.bbclass | 13 ---
meta/classes/insane.bbclass | 21 +++-
meta/lib/oeqa/core/runner.py | 6 +-
meta/recipes-bsp/u-boot/libubootenv_0.2.bb| 2 +-
meta/recipes-connectivity/avahi/avahi.inc | 5 +
.../0001-bison-fix-the-parallel-build.patch | 63
meta/recipes-devtools/bison/bison_3.5.3.bb| 1 +
meta/recipes-devtools/file/file_5.38.bb | 2 +-
meta/recipes-devtools/git/git_2.24.1.bb | 11 ---
meta/recipes-devtools/git/git_2.24.3.bb | 9 ++
.../python/python-setuptools.inc | 2 +
meta/recipes-devtools/qemu/qemu.inc | 1 +
.../qemu/qemu/CVE-2020-11869.patch| 97 +++
meta/recipes-gnome/gcr/gcr_3.34.0.bb | 2 +-
...20200122.bb => linux-firmware_20200421.bb} | 12 ++-
.../make-mod-scripts/make-mod-scripts_1.0.bb | 2 +
06.03.bb => wireless-regdb_2020.04.29.bb} | 3 +-
18 files changed, 219 insertions(+), 37 deletions(-)
create mode 100644
meta/recipes-devtools/bison/bison/0001-bison-fix-the-parallel-build.patch
delete mode 100644 meta/recipes-devtools/git/git_2.24.1.bb
create mode 100644 meta/recipes-devtools/git/git_2.24.3.bb
create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2020-11869.patch
rename meta/recipes-kernel/linux-firmware/{linux-firmware_20200122.bb =>
linux-firmware_20200421.bb} (98%)
rename meta/recipes-kernel/wireless-regdb/{wireless-regdb_2019.06.03.bb =>
wireless-regdb_2020.04.29.bb} (91%)
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138834):
https://lists.openembedded.org/g/openembedded-core/message/138834
Mute This Topic: https://lists.openembedded.org/mt/74514985/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] [master][zeus][PATCH] relocatable.bbclass: Avoid an exception if an empty pkgconfig dir exist
*ping* *ping* *ping*
I am not sure why this is being ignored. It is two months since I
first sent it and the third time I ping it. I have not received any
objections, yet it has never made it even to master-next as far as
I know.
This should not be taken as a complaint. I know there has been
problems with the autobuilder and that patch integration has been
slowed, and during this time all other patches I have sent have
been applied on the first try. So it just seems to be this one that
has been left out, and I would like to know if there is a reason or
if it just has fallen between the cracks.
//Peter
PS. The patch of course applies to Dunfell now too in addition to
master and Zeus since it has been released in the meantime.
> -Original Message-
> From: openembedded-core@lists.openembedded.org
> On Behalf Of Peter Kjellerstedt
> Sent: den 25 april 2020 11:17
> To: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [master][zeus][PATCH] relocatable.bbclass: Avoid an
> exception if an empty pkgconfig dir exist
>
> *ping again*
>
> //Peter
>
> > -Original Message-
> > From: openembedded-core@lists.openembedded.org
> > On Behalf Of Peter Kjellerstedt
> > Sent: den 3 april 2020 18:24
> > To: openembedded-core@lists.openembedded.org
> > Subject: Re: [OE-core] [master][zeus][PATCH] relocatable.bbclass: Avoid an
> > exception if an empty pkgconfig dir exist
> >
> > *ping*
> >
> > //Peter
> >
> > > -Original Message-
> > > From: openembedded-core-boun...@lists.openembedded.org
> > > On Behalf Of Peter
> > > Kjellerstedt
> > > Sent: den 20 mars 2020 19:04
> > > To: openembedded-core@lists.openembedded.org
> > > Subject: [OE-core] [master][zeus][PATCH] relocatable.bbclass: Avoid an
> > > exception if an empty pkgconfig dir exist
> > >
> > > Rewrite relocatable_native_pcfiles() so that it can handle that any of
> > > the checked pkgconfig directories are empty without causing an
> > > exception.
> > >
> > > Signed-off-by: Peter Kjellerstedt
> > > ---
> > > meta/classes/relocatable.bbclass | 20 +++-
> > > 1 file changed, 11 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/meta/classes/relocatable.bbclass
> > > b/meta/classes/relocatable.bbclass
> > > index 582812c1cf..af04be5cca 100644
> > > --- a/meta/classes/relocatable.bbclass
> > > +++ b/meta/classes/relocatable.bbclass
> > > @@ -6,13 +6,15 @@ python relocatable_binaries_preprocess() {
> > > rpath_replace(d.expand('${SYSROOT_DESTDIR}'), d)
> > > }
> > >
> > > -relocatable_native_pcfiles () {
> > > - if [ -d ${SYSROOT_DESTDIR}${libdir}/pkgconfig ]; then
> > > - rel=${@os.path.relpath(d.getVar('base_prefix'),
> > > d.getVar('libdir') + "/pkgconfig")}
> > > - sed -i -e "s:${base_prefix}:\${pcfiledir}/$rel:g"
> > > ${SYSROOT_DESTDIR}${libdir}/pkgconfig/*.pc
> > > - fi
> > > - if [ -d ${SYSROOT_DESTDIR}${datadir}/pkgconfig ]; then
> > > - rel=${@os.path.relpath(d.getVar('base_prefix'),
> > > d.getVar('datadir') + "/pkgconfig")}
> > > - sed -i -e "s:${base_prefix}:\${pcfiledir}/$rel:g"
> > > ${SYSROOT_DESTDIR}${datadir}/pkgconfig/*.pc
> > > - fi
> > > +relocatable_native_pcfiles() {
> > > + for dir in ${libdir}/pkgconfig ${datadir}/pkgconfig; do
> > > + files_template=${SYSROOT_DESTDIR}$dir/*.pc
> > > + # Expand to any files matching $files_template
> > > + files=$(echo $files_template)
> > > + # $files_template and $files will differ if any files were found
> > > + if [ "$files_template" != "$files" ]; then
> > > + rel=$(realpath -m --relative-to=$dir ${base_prefix})
> > > + sed -i -e "s:${base_prefix}:\${pcfiledir}/$rel:g" $files
> > > + fi
> > > + done
> > > }
> > > --
> > > 2.21.1
> >
> > //Peter
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138833):
https://lists.openembedded.org/g/openembedded-core/message/138833
Mute This Topic: https://lists.openembedded.org/mt/72396145/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] Issue with qemu and a shared sstate-cache used by different linux distribution supported by yocto
On Wed, May 27, 2020 at 5:29 AM vygu via lists.openembedded.org wrote: > > Hello, > > Since the zeus serie (also with dunfell), we observe an issue with runqemu > when we share the sstate-cache thanks to a mirror between different linux > distribution supported by yocto. > > If we build a sstate-cache on a debian 10 x86_64 buildfarm, and after that > we use it on an ubuntu 18.04 x86_64, runqemu don't find several libs. > > We have reproduced this problem on two different pc with ubuntu 18.04 and > 16.04. > > We don't have this problem, if we use the shared sstate-cache on another > debian. > > In all cases, a ldd on the qemu binary shows us the use of local/host libs, > not the yocto libs. > > Is it an expected behavior? or not? > Runqemu's libs have to come from the linux distribution or from the yocto > build env? There are two cases, depending on whether you have uninative enabled or not. It's disabled by default in oe-core but enabled by default in poky (the distro aimed at testing). With uninative disabled, native binaries link with host libc. Other link dependencies are either native packages provided by OE or they come from the host. In this case, sstate for native packages is stored within a host specific subdirectory of sstate-cache (e.g. sstate-cache/ubuntu-18.04). It should be quite safe to share sstate-cache between different hosts (since different hosts should each use a different subdirectory of sstate-cache). The downside is that because different hosts don't share sstate, build times may be slower. With uninative enabled, native binaries link with uninative libc. Other link dependencies should only be native packages provided by OE (ie they should NOT come directly from the host). In this case, sstate for native packages is stored within a common subdirectory of sstate-cache (ie sstate-cache/universal). The assumption is that because native packages never link with libs from the host, sstate for native packages no longer needs to be host specific. Unfortunately problems happen if uninative is enabled but a link dependency _is_ found from the host. That causes host dependent sstate files to pollute sstate-cache/universal, making it unsafe to reuse between different hosts. This doesn't happen often, but it does happen sometimes, e.g: https://git.openembedded.org/openembedded-core/commit/?id=4a996574464028bd5d57b90920d0887d1a81e9e9 It looks like maybe it's happened in your case too. If you want to share sstate-cache between different hosts the safest way is to disable uninative. If you are happy to test and debug uninative then of course give it a try, but be aware that it's not bug free. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138831): https://lists.openembedded.org/g/openembedded-core/message/138831 Mute This Topic: https://lists.openembedded.org/mt/74498490/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] python3-pathtools: add a recipe
Hello! On Wed, May 27, 2020 at 5:49 AM Richard Purdie < richard.pur...@linuxfoundation.org> wrote: > > On Tue, 2020-05-26 at 01:12 -0400, Maxime Roussin-Bélanger wrote: > > Signed-off-by: Maxime Roussin-Bélanger > > --- > > .../python/python3-pathtools_0.1.2.bb | 13 + > > 1 file changed, 13 insertions(+) > > create mode 100644 meta/recipes-devtools/python/ python3-pathtools_0.1.2.bb > > Should these be in OE-Core or meta-python? I'm always confused by OE-Core, Poky and meta-oe. I think when you are referring to meta-python you mean the sub-directory inside meta-oe. meta-oe might be a better place for them. Thanks, Max. > > Cheers, > > Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138832): https://lists.openembedded.org/g/openembedded-core/message/138832 Mute This Topic: https://lists.openembedded.org/mt/74472477/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] xf86-input-libinput: upgrade 0.29.0 -> 0.30.0
Signed-off-by: Wang Mingyu
---
...input-libinput_0.29.0.bb => xf86-input-libinput_0.30.0.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-graphics/xorg-driver/{xf86-input-libinput_0.29.0.bb =>
xf86-input-libinput_0.30.0.bb} (63%)
diff --git a/meta/recipes-graphics/xorg-driver/xf86-input-libinput_0.29.0.bb
b/meta/recipes-graphics/xorg-driver/xf86-input-libinput_0.30.0.bb
similarity index 63%
rename from meta/recipes-graphics/xorg-driver/xf86-input-libinput_0.29.0.bb
rename to meta/recipes-graphics/xorg-driver/xf86-input-libinput_0.30.0.bb
index f87083e575..d02988caa4 100644
--- a/meta/recipes-graphics/xorg-driver/xf86-input-libinput_0.29.0.bb
+++ b/meta/recipes-graphics/xorg-driver/xf86-input-libinput_0.30.0.bb
@@ -5,7 +5,7 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=5e6b20ea2ef94a998145f0ea3f788ee0"
DEPENDS += "libinput"
-SRC_URI[md5sum] = "d600e8e2e30747b8ce49ec5294ff0ab6"
-SRC_URI[sha256sum] =
"c28b56a21754b972db31798e6a4cf4dc9d69208d08f8fe41701a94def5e94bee"
+SRC_URI[md5sum] = "11dcfa2cc39f790731a9545fcdeea717"
+SRC_URI[sha256sum] =
"f9c7f9fd41ae14061e0e9c3bd45fa170e5e21027a2bc5810034e1e748db996c0"
FILES_${PN} += "${datadir}/X11/xorg.conf.d"
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138830):
https://lists.openembedded.org/g/openembedded-core/message/138830
Mute This Topic: https://lists.openembedded.org/mt/74512600/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] util-linux: upgrade 2.35.1 -> 2.35.2
0001-hwclock-fix-for-glibc-2.31-settimeofday.patch
0001-kill-include-sys-types.h-before-checking-SYS_pidfd_s.patch
0001-libfdisk-script-accept-sector-size-ignore-unknown-he.patch
are removed since they are included in 2.35.2
Signed-off-by: Wang Mingyu
---
...lock-fix-for-glibc-2.31-settimeofday.patch | 112 --
...-types.h-before-checking-SYS_pidfd_s.patch | 64
...accept-sector-size-ignore-unknown-he.patch | 137 --
.../util-linux/util-linux_2.35.1.bb | 16 --
.../util-linux/util-linux_2.35.2.bb | 13 ++
5 files changed, 13 insertions(+), 329 deletions(-)
delete mode 100644
meta/recipes-core/util-linux/util-linux/0001-hwclock-fix-for-glibc-2.31-settimeofday.patch
delete mode 100644
meta/recipes-core/util-linux/util-linux/0001-kill-include-sys-types.h-before-checking-SYS_pidfd_s.patch
delete mode 100644
meta/recipes-core/util-linux/util-linux/0001-libfdisk-script-accept-sector-size-ignore-unknown-he.patch
delete mode 100644 meta/recipes-core/util-linux/util-linux_2.35.1.bb
create mode 100644 meta/recipes-core/util-linux/util-linux_2.35.2.bb
diff --git
a/meta/recipes-core/util-linux/util-linux/0001-hwclock-fix-for-glibc-2.31-settimeofday.patch
b/meta/recipes-core/util-linux/util-linux/0001-hwclock-fix-for-glibc-2.31-settimeofday.patch
deleted file mode 100644
index 0672c3546a..00
---
a/meta/recipes-core/util-linux/util-linux/0001-hwclock-fix-for-glibc-2.31-settimeofday.patch
+++ /dev/null
@@ -1,112 +0,0 @@
-From ee85d3967ea09b215fcea5efdd90bbbf5e74a681 Mon Sep 17 00:00:00 2001
-From: Karel Zak
-Date: Wed, 19 Feb 2020 15:50:47 +0100
-Subject: [PATCH] hwclock: fix for glibc 2.31 settimeofday()
-
-glibc announce:
- ... settimeofday can no longer be used to set the time and the offset
- simultaneously. If both of its two arguments are non-null, the call
- will fail (setting errno to EINVAL).
-
-It means we need to call settimeofday(NULL, tz) and settimeofday(tv, NULL).
-
-Unfortunately, settimeofday(NULL, tz) has very special warp-clock
-semantic if used as the very first settimeofday() call. It means we
-have to be sure that we do not touch warp-clock if we need only need
-to modify system TZ. So, let's always call settimeofday(NULL, 0)
-before settimeofday(NULL, tz) for UTC rtc mode when modify system TZ.
-
-Upstream-Status: Backport
[https://github.com/karelzak/util-linux/commit/ee85d3967ea09b215fcea5efdd90bbbf5e74a681]
-
-CC: J William Piggott
-Signed-off-by: Karel Zak
-Addresses: https://github.com/karelzak/util-linux/issues/957
-Signed-off-by: Liwei Song
- sys-utils/hwclock.c | 49 ++---
- 1 file changed, 28 insertions(+), 21 deletions(-)
-
-diff --git a/sys-utils/hwclock.c b/sys-utils/hwclock.c
-index e736da7179f8..16576bc186ff 100644
a/sys-utils/hwclock.c
-+++ b/sys-utils/hwclock.c
-@@ -658,6 +658,9 @@ display_time(struct timeval hwctime)
- * PCIL: persistent_clock_is_local, sets the "11 minute mode" timescale.
- * firsttime: locks the warp_clock function (initialized to 1 at boot).
- *
-+ * Note that very first settimeofday(NULL, tz) modifies warp-clock as well as
-+ * system TZ.
-+ *
- *
+---+
- * | op | RTC scale | settimeofday calls
|
- *
|-|---|-|
-@@ -675,41 +678,45 @@ set_system_clock(const struct hwclock_control *ctl,
- struct tm broken;
- int minuteswest;
- int rc = 0;
-- const struct timezone tz_utc = { 0 };
-
- localtime_r(_sec, );
- minuteswest = -get_gmtoff() / 60;
-
- if (ctl->verbose) {
-- if (ctl->hctosys && !ctl->universal)
-- printf(_("Calling settimeofday(NULL, %d) to set "
-- "persistent_clock_is_local.\n"), minuteswest);
-- if (ctl->systz && ctl->universal)
-+ if (ctl->universal)
- puts(_("Calling settimeofday(NULL, 0) "
-- "to lock the warp function."));
-+ "to lock the warp function."));
-+ else
-+ printf(_("Calling settimeofday(NULL, %d) to set "
-+ "persistent_clock_is_local and "
-+ "the kernel timezone.\n"), minuteswest);
-+
-+ if (ctl->universal && minuteswest)
-+ printf(_("Calling settimeofday(NULL, %d) to set "
-+ "the kernel timezone.\n"), minuteswest);
-+
- if (ctl->hctosys)
-- printf(_("Calling settimeofday(%ld.%06ld, %d)\n"),
-- newtime.tv_sec, newtime.tv_usec, minuteswest);
-- else {
-- printf(_("Calling settimeofday(NULL, %d) "),
minuteswest);
-- if (ctl->universal)
Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing
On Wed, May 27, 2020 at 3:57 PM Khem Raj wrote: > > On Wed, May 27, 2020 at 3:43 PM Andre McCurdy wrote: > > > > On Wed, May 27, 2020 at 2:52 PM Phil Blundell via > > lists.openembedded.org wrote: > > > > > > On Wed, May 27, 2020 at 02:46:24PM -0700, Khem Raj wrote: > > > > and building userspace against way newer kernel-headers with older > > > > kernel underneath has unintended > > > > consequences. > > > > > > Can you be more specific? If this doesn't work, it's just a bug and > > > should be fixed. What problems are you having? > > > > I don't have an up to date example, but I've been using kernel version > > specific libc headers for all my projects for many years. The issue > > which prompted me to do that was run time crashes from libcap-ng and > > the historical commit message was: > > > > > > > > linux-libc-headers: use 3.3.8 kernel header files for mips platforms > > > > If libcap-ng is unable to probe kernel capabilities at runtime then > > it will assume the kernel supports all features defined by the libc > > kernel headers. Since our default libc kernel headers (linux 3.14) > > define capabilities which are not available in linux 3.3 based > > stblinux kernel used for our MIPS platforms, that causes runtime > > crashes. > > > > As a workaround, force an older version of linux-libc-headers for all > > MIPS platforms to try to remove that discrepancy between the kernel's > > capabilities and those defined in the libc kernel headers. > > > > there are similar issues seen with linput.h using apps. I will dig the reasons > but it does work when kernel and kernel header. versions are same and its > using > mainlne release for kernel headers here, so there is no vendor specific code > perhaps that's breaking APIs > https://github.com/torvalds/linux/commit/052876f8e5aec887d22c4d06e54aa5531ffcec75 this change e.g. in userspace checks for UINPUT_VERSION and decides to use one method or legacy to setup the device but this is really not gonna work with kernels where these ioctls are not available, it perhaps can be fixed to not check for UINPUT_VERSION but then there could be many such cases, how many can we chase. > > > > > > The risk of using bleeding edge linux-libc-headers with an older > > kernel may be low, it's not zero. Since OE testing doesn't appear to > > include any coverage of older kernels, I'm not sure why I should be > > the guinea pig and take the risk! -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138828): https://lists.openembedded.org/g/openembedded-core/message/138828 Mute This Topic: https://lists.openembedded.org/mt/74502640/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-libc-headers: Check for asm/bpf_perf_event.h before multilibbing
On Wed, May 27, 2020 at 10:25:31PM +0100, Richard Purdie wrote: > On Wed, 2020-05-27 at 11:59 -0400, Denys Dmytriyenko wrote: > > On Wed, May 27, 2020 at 08:50:11AM -0700, Khem Raj wrote: > > > asm/bpf_perf_event.h does not exist in older kernels e.g. ( 4.1 ) > > > this helps in using common header across multiple versions of > > > kernel > > > going back > > > > This check should have been there from the beginning and for every > > header > > file. It's big PITA to sync this list up, especially when dealing > > with > > different glibc or kernel than OE-Core, e.g. external toolchains, > > etc. > > > > Any objections to making this check more generic for every entry in > > the list? > > Yes, a strong objection. We don't want to support or encourage every > kernel version out there. > > I also don't understand why people need to change the libc-headers > anyway :( Richard, I already explained my use-case with external toolchains - those usually come with specific set of libc-headers. And when those don't match the list from OE-Core, it causes problems, trying to support some resemblance of multilib. I believe that got disabled completely now for external-toolchains anyway... -- Denys -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138827): https://lists.openembedded.org/g/openembedded-core/message/138827 Mute This Topic: https://lists.openembedded.org/mt/74502640/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-libc-headers: Check for asm/bpf_perf_event.h before multilibbing
On Wed, May 27, 2020 at 3:43 PM Andre McCurdy wrote: > > On Wed, May 27, 2020 at 2:52 PM Phil Blundell via > lists.openembedded.org wrote: > > > > On Wed, May 27, 2020 at 02:46:24PM -0700, Khem Raj wrote: > > > and building userspace against way newer kernel-headers with older > > > kernel underneath has unintended > > > consequences. > > > > Can you be more specific? If this doesn't work, it's just a bug and > > should be fixed. What problems are you having? > > I don't have an up to date example, but I've been using kernel version > specific libc headers for all my projects for many years. The issue > which prompted me to do that was run time crashes from libcap-ng and > the historical commit message was: > > > > linux-libc-headers: use 3.3.8 kernel header files for mips platforms > > If libcap-ng is unable to probe kernel capabilities at runtime then > it will assume the kernel supports all features defined by the libc > kernel headers. Since our default libc kernel headers (linux 3.14) > define capabilities which are not available in linux 3.3 based > stblinux kernel used for our MIPS platforms, that causes runtime > crashes. > > As a workaround, force an older version of linux-libc-headers for all > MIPS platforms to try to remove that discrepancy between the kernel's > capabilities and those defined in the libc kernel headers. > there are similar issues seen with linput.h using apps. I will dig the reasons but it does work when kernel and kernel header. versions are same and its using mainlne release for kernel headers here, so there is no vendor specific code perhaps that's breaking APIs > > > The risk of using bleeding edge linux-libc-headers with an older > kernel may be low, it's not zero. Since OE testing doesn't appear to > include any coverage of older kernels, I'm not sure why I should be > the guinea pig and take the risk! -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138826): https://lists.openembedded.org/g/openembedded-core/message/138826 Mute This Topic: https://lists.openembedded.org/mt/74502640/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-libc-headers: Check for asm/bpf_perf_event.h before multilibbing
On Wed, May 27, 2020 at 2:52 PM Phil Blundell via lists.openembedded.org wrote: > > On Wed, May 27, 2020 at 02:46:24PM -0700, Khem Raj wrote: > > and building userspace against way newer kernel-headers with older > > kernel underneath has unintended > > consequences. > > Can you be more specific? If this doesn't work, it's just a bug and > should be fixed. What problems are you having? I don't have an up to date example, but I've been using kernel version specific libc headers for all my projects for many years. The issue which prompted me to do that was run time crashes from libcap-ng and the historical commit message was: linux-libc-headers: use 3.3.8 kernel header files for mips platforms If libcap-ng is unable to probe kernel capabilities at runtime then it will assume the kernel supports all features defined by the libc kernel headers. Since our default libc kernel headers (linux 3.14) define capabilities which are not available in linux 3.3 based stblinux kernel used for our MIPS platforms, that causes runtime crashes. As a workaround, force an older version of linux-libc-headers for all MIPS platforms to try to remove that discrepancy between the kernel's capabilities and those defined in the libc kernel headers. The risk of using bleeding edge linux-libc-headers with an older kernel may be low, it's not zero. Since OE testing doesn't appear to include any coverage of older kernels, I'm not sure why I should be the guinea pig and take the risk! -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138825): https://lists.openembedded.org/g/openembedded-core/message/138825 Mute This Topic: https://lists.openembedded.org/mt/74502640/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-libc-headers: Check for asm/bpf_perf_event.h before multilibbing
On Wed, May 27, 2020 at 02:46:24PM -0700, Khem Raj wrote: > and building userspace against way newer kernel-headers with older > kernel underneath has unintended > consequences. Can you be more specific? If this doesn't work, it's just a bug and should be fixed. What problems are you having? p. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138824): https://lists.openembedded.org/g/openembedded-core/message/138824 Mute This Topic: https://lists.openembedded.org/mt/74502640/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-libc-headers: Check for asm/bpf_perf_event.h before multilibbing
On Wed, 2020-05-27 at 14:46 -0700, Khem Raj wrote: > On Wed, May 27, 2020 at 2:25 PM Richard Purdie > wrote: > > On Wed, 2020-05-27 at 11:59 -0400, Denys Dmytriyenko wrote: > > > On Wed, May 27, 2020 at 08:50:11AM -0700, Khem Raj wrote: > > > > asm/bpf_perf_event.h does not exist in older kernels e.g. ( 4.1 > > > > ) > > > > this helps in using common header across multiple versions of > > > > kernel > > > > going back > > > > > > This check should have been there from the beginning and for > > > every > > > header > > > file. It's big PITA to sync this list up, especially when dealing > > > with > > > different glibc or kernel than OE-Core, e.g. external toolchains, > > > etc. > > > > > > Any objections to making this check more generic for every entry > > > in > > > the list? > > > > Yes, a strong objection. We don't want to support or encourage > > every > > kernel version out there. > > > > I also don't understand why people need to change the libc-headers > > anyway :( > > building products doesn't mean you are on the latest kernels sadly, > that's just the reality of world > and building userspace against way newer kernel-headers with older > kernel underneath has unintended consequences. Its not supposed to have any consequences, the kernel UAPI is supposed to be backwards compatible. Have you examples where things were broken? > So its always better to use matching UAPIs to the kernel > version to avoid these mismatches This should not be necessary and its actually really bad it it means a totally different userspace for every target :( Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138823): https://lists.openembedded.org/g/openembedded-core/message/138823 Mute This Topic: https://lists.openembedded.org/mt/74502640/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-libc-headers: Check for asm/bpf_perf_event.h before multilibbing
On Wed, May 27, 2020 at 2:25 PM Richard Purdie wrote: > > On Wed, 2020-05-27 at 11:59 -0400, Denys Dmytriyenko wrote: > > On Wed, May 27, 2020 at 08:50:11AM -0700, Khem Raj wrote: > > > asm/bpf_perf_event.h does not exist in older kernels e.g. ( 4.1 ) > > > this helps in using common header across multiple versions of > > > kernel > > > going back > > > > This check should have been there from the beginning and for every > > header > > file. It's big PITA to sync this list up, especially when dealing > > with > > different glibc or kernel than OE-Core, e.g. external toolchains, > > etc. > > > > Any objections to making this check more generic for every entry in > > the list? > > Yes, a strong objection. We don't want to support or encourage every > kernel version out there. > > I also don't understand why people need to change the libc-headers > anyway :( building products doesn't mean you are on the latest kernels sadly, that's just the reality of world and building userspace against way newer kernel-headers with older kernel underneath has unintended consequences. So its always better to use matching UAPIs to the kernel version to avoid these mismatches > > Cheers, > > Richard > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138822): https://lists.openembedded.org/g/openembedded-core/message/138822 Mute This Topic: https://lists.openembedded.org/mt/74502640/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] libexif: upgrade to 0.6.22, change source to GitHub
What are thoughts on applying this version bump to older supported
releases? https://libexif.github.io/ states:
stability / bugfix / security release fixes CVE-2018-20030,
CVE-2020-13114, CVE-2020-13113, CVE-2020-13112, CVE-2020-0093,
CVE-2019-9278, CVE-2020-12767, CVE-2016-6328, CVE-2017-7544,
I say go for it.
-George
On Wed, May 27, 2020 at 8:05 AM Trevor Gamblin
wrote:
>
>
> On 5/27/20 3:59 AM, Alexander Kanavin wrote:
>
> Hardcoding the split version components isn't great (and breaks automated
> updates), I have a patch queued that does this better:
>
> Works for me.
>
> Thanks!
>
>
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=akanavin/package-version-updates=314af89080317673cf91e24537b2e0d9b36747c2
>
> Specifically:
> def version_underscore(v):
> return "_".join(v.split("."))
>
> SRC_URI =
> "https://github.com/libexif/libexif/releases/download/libexif-${@version_underscore("${PV}")}-release/libexif-${PV}.tar.xz
> \
> "
>
> Alex
>
> On Tue, 26 May 2020 at 23:13, Trevor Gamblin
> wrote:
>>
>> Updated libexif to 0.6.22, but needed to change to GitHub as a source,
>> since SourceForge does not yet have 0.6.22 version. The new version
>> includes the fixes for the three patch files that have been removed,
>> as well as other severe CVEs.
>>
>> CVE: CVE-2018-20030
>> CVE: CVE-2020-13114
>> CVE: CVE-2020-13113
>> CVE: CVE-2020-13112
>> CVE: CVE-2020-0093
>> CVE: CVE-2019-9278
>> CVE: CVE-2020-12767
>> CVE: CVE-2016-6328
>> CVE: CVE-2017-7544
>>
>> Signed-off-by: Trevor Gamblin
>> ---
>> .../libexif/libexif/CVE-2016-6328.patch | 64 --
>> .../libexif/libexif/CVE-2017-7544.patch | 40 --
>> .../libexif/libexif/CVE-2018-20030.patch | 115 --
>> .../recipes-support/libexif/libexif_0.6.21.bb | 17 ---
>> .../recipes-support/libexif/libexif_0.6.22.bb | 21
>> 5 files changed, 21 insertions(+), 236 deletions(-)
>> delete mode 100644 meta/recipes-support/libexif/libexif/CVE-2016-6328.patch
>> delete mode 100644 meta/recipes-support/libexif/libexif/CVE-2017-7544.patch
>> delete mode 100644 meta/recipes-support/libexif/libexif/CVE-2018-20030.patch
>> delete mode 100644 meta/recipes-support/libexif/libexif_0.6.21.bb
>> create mode 100644 meta/recipes-support/libexif/libexif_0.6.22.bb
>>
>> diff --git a/meta/recipes-support/libexif/libexif/CVE-2016-6328.patch
>> b/meta/recipes-support/libexif/libexif/CVE-2016-6328.patch
>> deleted file mode 100644
>> index a6f307439b..00
>> --- a/meta/recipes-support/libexif/libexif/CVE-2016-6328.patch
>> +++ /dev/null
>> @@ -1,64 +0,0 @@
>> -CVE: CVE-2016-6328
>> -Upstream-Status: Backport
>> -Signed-off-by: Ross Burton
>> -
>> -From 41bd04234b104312f54d25822f68738ba8d7133d Mon Sep 17 00:00:00 2001
>> -From: Marcus Meissner
>> -Date: Tue, 25 Jul 2017 23:44:44 +0200
>> -Subject: [PATCH] fixes some (not all) buffer overreads during decoding
>> pentax
>> - makernote entries.
>> -
>> -This should fix:
>> -https://sourceforge.net/p/libexif/bugs/125/ CVE-2016-6328
>>
>> - libexif/pentax/mnote-pentax-entry.c | 16 +---
>> - 1 file changed, 13 insertions(+), 3 deletions(-)
>> -
>> -diff --git a/libexif/pentax/mnote-pentax-entry.c
>> b/libexif/pentax/mnote-pentax-entry.c
>> -index d03d159..ea0429a 100644
>> a/libexif/pentax/mnote-pentax-entry.c
>> -+++ b/libexif/pentax/mnote-pentax-entry.c
>> -@@ -425,24 +425,34 @@ mnote_pentax_entry_get_value (MnotePentaxEntry *entry,
>> - case EXIF_FORMAT_SHORT:
>> - {
>> - const unsigned char *data = entry->data;
>> -- size_t k, len = strlen(val);
>> -+ size_t k, len = strlen(val), sizeleft;
>> -+
>> -+ sizeleft = entry->size;
>> - for(k=0; kcomponents; k++) {
>> -+ if (sizeleft < 2)
>> -+ break;
>> - vs = exif_get_short (data, entry->order);
>> - snprintf (val+len, maxlen-len, "%i ", vs);
>> - len = strlen(val);
>> - data += 2;
>> -+ sizeleft -= 2;
>> - }
>> - }
>> - break;
>> - case EXIF_FORMAT_LONG:
>> - {
>> - const unsigned char *data = entry->data;
>> -- size_t k, len = strlen(val);
>> -+ size_t k, len = strlen(val), sizeleft;
>> -+
>> -+ sizeleft = entry->size;
>> - for(k=0; kcomponents; k++) {
>> -+ if (sizeleft < 4)
>> -+ break;
>> - vl = exif_get_long (data, entry->order);
>> - snprintf (val+len, maxlen-len, "%li", (long
>> int) vl);
>> -
Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing
On Wed, 2020-05-27 at 11:59 -0400, Denys Dmytriyenko wrote: > On Wed, May 27, 2020 at 08:50:11AM -0700, Khem Raj wrote: > > asm/bpf_perf_event.h does not exist in older kernels e.g. ( 4.1 ) > > this helps in using common header across multiple versions of > > kernel > > going back > > This check should have been there from the beginning and for every > header > file. It's big PITA to sync this list up, especially when dealing > with > different glibc or kernel than OE-Core, e.g. external toolchains, > etc. > > Any objections to making this check more generic for every entry in > the list? Yes, a strong objection. We don't want to support or encourage every kernel version out there. I also don't understand why people need to change the libc-headers anyway :( Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138820): https://lists.openembedded.org/g/openembedded-core/message/138820 Mute This Topic: https://lists.openembedded.org/mt/74502640/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-libc-headers: Check for asm/bpf_perf_event.h before multilibbing
On Wed, 2020-05-27 at 08:50 -0700, Khem Raj wrote:
> asm/bpf_perf_event.h does not exist in older kernels e.g. ( 4.1 )
> this helps in using common header across multiple versions of kernel
> going back
>
> Signed-off-by: Khem Raj
> ---
> .../recipes-kernel/linux-libc-headers/linux-libc-headers.inc | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
> b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
> index 4481aa430c..933a01ba81 100644
> --- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
> +++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
> @@ -81,8 +81,11 @@ do_install_append_armeb () {
> }
>
> do_install_armmultilib () {
> - oe_multilib_header asm/auxvec.h asm/bitsperlong.h asm/byteorder.h
> asm/fcntl.h asm/hwcap.h asm/ioctls.h asm/kvm.h asm/kvm_para.h asm/mman.h
> asm/param.h asm/perf_regs.h asm/bpf_perf_event.h
> + oe_multilib_header asm/auxvec.h asm/bitsperlong.h asm/byteorder.h
> asm/fcntl.h asm/hwcap.h asm/ioctls.h asm/kvm.h asm/kvm_para.h asm/mman.h
> asm/param.h asm/perf_regs.h
> oe_multilib_header asm/posix_types.h asm/ptrace.h asm/setup.h
> asm/sigcontext.h asm/siginfo.h asm/signal.h asm/stat.h asm/statfs.h
> asm/swab.h asm/types.h asm/unistd.h
> + if [ -f "${D}/${includedir}/asm/bpf_perf_event.h" ]; then
> + oe_multilib_header asm/bpf_perf_event.h
> + fi
> }
Why are people using old linux-libc-headers? This is for the toolchain
so it doesn't need to have anything to do with the target kernel.
I've always assumed that people should be able to use the latest
version here and should not need to customise this. The headers should
be backwards compatible. What am I missing?
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138819):
https://lists.openembedded.org/g/openembedded-core/message/138819
Mute This Topic: https://lists.openembedded.org/mt/74502640/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-libc-headers: Check for asm/bpf_perf_event.h before multilibbing
On Wed, May 27, 2020 at 1:45 PM Khem Raj wrote:
>
> On Wed, May 27, 2020 at 9:00 AM Denys Dmytriyenko wrote:
> >
> > On Wed, May 27, 2020 at 08:50:11AM -0700, Khem Raj wrote:
> > > asm/bpf_perf_event.h does not exist in older kernels e.g. ( 4.1 )
> > > this helps in using common header across multiple versions of kernel
> > > going back
> >
> > This check should have been there from the beginning and for every header
> > file. It's big PITA to sync this list up, especially when dealing with
> > different glibc or kernel than OE-Core, e.g. external toolchains, etc.
> >
> > Any objections to making this check more generic for every entry in the
> > list?
> >
>
> I thought about that, but then realized, there is a check for missing
> headers in the oe_multilib_header function which catches errors nicely
> so if we do this check before calling that function perhaps is going
> to subvert the error message which could be useful, since the
> aftereffect of
> the missing header can be a cryptic build error in applications,
> therefore went for limited edition.
Just as another point of reference, I'm using kernel 3.12.x and both
asm/perf_regs.h and asm/bpf_perf_event.h are missing.
My solution was to downgrade bberror -> bbwarn in multilib_header.bbclass
> > Denys
> >
> >
> > > Signed-off-by: Khem Raj
> > > ---
> > > .../recipes-kernel/linux-libc-headers/linux-libc-headers.inc | 5 -
> > > 1 file changed, 4 insertions(+), 1 deletion(-)
> > >
> > > diff --git
> > > a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
> > > b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
> > > index 4481aa430c..933a01ba81 100644
> > > --- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
> > > +++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
> > > @@ -81,8 +81,11 @@ do_install_append_armeb () {
> > > }
> > >
> > > do_install_armmultilib () {
> > > - oe_multilib_header asm/auxvec.h asm/bitsperlong.h asm/byteorder.h
> > > asm/fcntl.h asm/hwcap.h asm/ioctls.h asm/kvm.h asm/kvm_para.h asm/mman.h
> > > asm/param.h asm/perf_regs.h asm/bpf_perf_event.h
> > > + oe_multilib_header asm/auxvec.h asm/bitsperlong.h asm/byteorder.h
> > > asm/fcntl.h asm/hwcap.h asm/ioctls.h asm/kvm.h asm/kvm_para.h asm/mman.h
> > > asm/param.h asm/perf_regs.h
> > > oe_multilib_header asm/posix_types.h asm/ptrace.h asm/setup.h
> > > asm/sigcontext.h asm/siginfo.h asm/signal.h asm/stat.h asm/statfs.h
> > > asm/swab.h asm/types.h asm/unistd.h
> > > + if [ -f "${D}/${includedir}/asm/bpf_perf_event.h" ]; then
> > > + oe_multilib_header asm/bpf_perf_event.h
> > > + fi
> > > }
> > >
> > > BBCLASSEXTEND = "nativesdk"
> > > --
> > > 2.26.2
> > >
> >
> > >
> >
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138818):
https://lists.openembedded.org/g/openembedded-core/message/138818
Mute This Topic: https://lists.openembedded.org/mt/74502640/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 v3] make-mod-scripts: Fix a rare build race condition
There is a build break which rarely happens but is seen often enough
with 4.1 kernel based builds
/bin/sh: 1: scripts/basic/fixdep: Permission denied
scripts/Makefile.host:124: recipe for target 'scripts/dtc/srcpos.o' failed
make[3]: *** [scripts/dtc/srcpos.o] Error 126
this patch sequences the build targets so it can work reliably with
different kernel versions
Divide the target into scripts_basic scripts is not
strictly necessary and was simply what was used for
testing on kernel 4.1, which is quite an old kernel
perhaps just using scripts is sufficient, but it is not tested to not
known will cause the build race as seen above.
Signed-off-by: Khem Raj
Cc: Bruce Ashfield
---
v2: Improve commit msg
v3: Make commit msg coherent
.../make-mod-scripts/make-mod-scripts_1.0.bb | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
index 0be1422a24..c7edb20ee4 100644
--- a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
+++ b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
@@ -23,7 +23,8 @@ EXTRA_OEMAKE = " HOSTCC="${BUILD_CC} ${BUILD_CFLAGS}
${BUILD_LDFLAGS}" HOSTCPP="
#
do_configure() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
- oe_runmake CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \
- -C ${STAGING_KERNEL_DIR} O=${STAGING_KERNEL_BUILDDIR}
scripts prepare
-
+ for t in prepare scripts_basic scripts; do
+ oe_runmake CC="${KERNEL_CC}" LD="${KERNEL_LD}"
AR="${KERNEL_AR}" \
+ -C ${STAGING_KERNEL_DIR} O=${STAGING_KERNEL_BUILDDIR} $t
+ done
}
--
2.26.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138817):
https://lists.openembedded.org/g/openembedded-core/message/138817
Mute This Topic: https://lists.openembedded.org/mt/74509236/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-libc-headers: Check for asm/bpf_perf_event.h before multilibbing
On Wed, May 27, 2020 at 9:00 AM Denys Dmytriyenko wrote:
>
> On Wed, May 27, 2020 at 08:50:11AM -0700, Khem Raj wrote:
> > asm/bpf_perf_event.h does not exist in older kernels e.g. ( 4.1 )
> > this helps in using common header across multiple versions of kernel
> > going back
>
> This check should have been there from the beginning and for every header
> file. It's big PITA to sync this list up, especially when dealing with
> different glibc or kernel than OE-Core, e.g. external toolchains, etc.
>
> Any objections to making this check more generic for every entry in the list?
>
I thought about that, but then realized, there is a check for missing
headers in the oe_multilib_header function which catches errors nicely
so if we do this check before calling that function perhaps is going
to subvert the error message which could be useful, since the
aftereffect of
the missing header can be a cryptic build error in applications,
therefore went for limited edition.
> --
> Denys
>
>
> > Signed-off-by: Khem Raj
> > ---
> > .../recipes-kernel/linux-libc-headers/linux-libc-headers.inc | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
> > b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
> > index 4481aa430c..933a01ba81 100644
> > --- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
> > +++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
> > @@ -81,8 +81,11 @@ do_install_append_armeb () {
> > }
> >
> > do_install_armmultilib () {
> > - oe_multilib_header asm/auxvec.h asm/bitsperlong.h asm/byteorder.h
> > asm/fcntl.h asm/hwcap.h asm/ioctls.h asm/kvm.h asm/kvm_para.h asm/mman.h
> > asm/param.h asm/perf_regs.h asm/bpf_perf_event.h
> > + oe_multilib_header asm/auxvec.h asm/bitsperlong.h asm/byteorder.h
> > asm/fcntl.h asm/hwcap.h asm/ioctls.h asm/kvm.h asm/kvm_para.h asm/mman.h
> > asm/param.h asm/perf_regs.h
> > oe_multilib_header asm/posix_types.h asm/ptrace.h asm/setup.h
> > asm/sigcontext.h asm/siginfo.h asm/signal.h asm/stat.h asm/statfs.h
> > asm/swab.h asm/types.h asm/unistd.h
> > + if [ -f "${D}/${includedir}/asm/bpf_perf_event.h" ]; then
> > + oe_multilib_header asm/bpf_perf_event.h
> > + fi
> > }
> >
> > BBCLASSEXTEND = "nativesdk"
> > --
> > 2.26.2
> >
>
> >
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138816):
https://lists.openembedded.org/g/openembedded-core/message/138816
Mute This Topic: https://lists.openembedded.org/mt/74502640/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 V2] make-mod-scripts: Fix a rare build race condition
On Wed, May 27, 2020 at 12:46 PM Khem Raj wrote:
>
> There is a build break which often happens whem using 4.1 kernel
Perhaps change "often" to "rarely" to match the title...
> /bin/sh: 1: scripts/basic/fixdep: Permission denied
> scripts/Makefile.host:124: recipe for target 'scripts/dtc/srcpos.o' failed
> make[3]: *** [scripts/dtc/srcpos.o] Error 126
>
> this patch sequences the build targets so it can work reliably with
> different kernel versions
>
> Divide the target into scripts_basic scripts is not
> strictly necessary and was simply what was used for
> testing on kernel 4.1, which is quite an old kernel
>
> perhaps just using scripts is sufficient, but it is not tested to not
> known will cause the build race as seen above.
>
> Signed-off-by: Khem Raj
> Cc: Bruce Ashfield
> ---
> v2: Improve commit msg
>
> .../make-mod-scripts/make-mod-scripts_1.0.bb | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> index 0be1422a24..c7edb20ee4 100644
> --- a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> +++ b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> @@ -23,7 +23,8 @@ EXTRA_OEMAKE = " HOSTCC="${BUILD_CC} ${BUILD_CFLAGS}
> ${BUILD_LDFLAGS}" HOSTCPP="
> #
> do_configure() {
> unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
> - oe_runmake CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \
> - -C ${STAGING_KERNEL_DIR} O=${STAGING_KERNEL_BUILDDIR}
> scripts prepare
> -
> + for t in prepare scripts_basic scripts; do
> + oe_runmake CC="${KERNEL_CC}" LD="${KERNEL_LD}"
> AR="${KERNEL_AR}" \
> + -C ${STAGING_KERNEL_DIR} O=${STAGING_KERNEL_BUILDDIR} $t
> + done
> }
> --
> 2.26.2
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138815):
https://lists.openembedded.org/g/openembedded-core/message/138815
Mute This Topic: https://lists.openembedded.org/mt/74507903/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] [bitbake-devel] Backtrace in bitbake with OE archiver
One more note.. Adding the following and then it works fine: INITRAMFS_IMAGE = "core-image-minimal" I suspect it works simply because the task processing order has changed in some way.. On 5/27/20 2:44 PM, Mark Hatle wrote: > Cross posting cause I'm not sure where the bug is, I suspect bitbake -- but it > could be in OE's archiver class. I have been able to reproduce this in both > Zeus and master. > > When I start a new project, and add the following to the local.conf: > > INHERIT += "archiver" > ARCHIVER_MODE[src] = "original" > COPYLEFT_LICENSE_INCLUDE = "" > COPYLEFT_LICENSE_EXCLUDE = "" > > > Then I run it with: > > bitbake core-image-minimal --runall=deploy_archives > > > and I get a backtrace in bitbake: > > ERROR: Running idle function > Traceback (most recent call last): > File "/scratch1/fray/poky/bitbake/lib/bb/runqueue.py", line 1527, in > RunQueue.execute_runqueue(): > try: > >return self._execute_runqueue() > except bb.runqueue.TaskFailure: > File "/scratch1/fray/poky/bitbake/lib/bb/runqueue.py", line 1444, in > RunQueue._execute_runqueue(): > [43, 967, 4, > 3, > 1, 5, 3, 7, 13, 1, 2, 1, 1, 246, 35, 1, 38, 1, 35, 2, 338, 204, 142, 3, 3, > 37, 244]) > >if self.rqdata.prepare() == 0: > self.state = runQueueComplete > File "/scratch1/fray/poky/bitbake/lib/bb/runqueue.py", line 935, in > RunQueueData.prepare(): > for tid in list(runall_tids): > >mark_active(tid,1) > if self.cooker.configuration.force: > File "/scratch1/fray/poky/bitbake/lib/bb/runqueue.py", line 850, in > mark_active(tid='/scratch1/fray/poky/meta/recipes-core/images/core-image-minimal.bb:do_deploy_archives', > depth=1): > for depend in depends: > >mark_active(depend, depth+1) > > File "/scratch1/fray/poky/bitbake/lib/bb/runqueue.py", line 848, in > mark_active(tid='/scratch1/fray/poky/meta/recipes-core/images/core-image-minimal.bb:do_ar_original', > depth=2): > > >depends = self.runtaskentries[tid].depends > for depend in depends: > KeyError: > '/scratch1/fray/poky/meta/recipes-core/images/core-image-minimal.bb:do_ar_original' > > > As you see above the system in the mark_active function of runqueue.py is > trying > to reference the key of the task core-image-minimal:do_ar_original, and it > can't > find it and crashes out. > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138814): https://lists.openembedded.org/g/openembedded-core/message/138814 Mute This Topic: https://lists.openembedded.org/mt/74507943/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 V2] make-mod-scripts: Fix a rare build race condition
There is a build break which often happens whem using 4.1 kernel
/bin/sh: 1: scripts/basic/fixdep: Permission denied
scripts/Makefile.host:124: recipe for target 'scripts/dtc/srcpos.o' failed
make[3]: *** [scripts/dtc/srcpos.o] Error 126
this patch sequences the build targets so it can work reliably with
different kernel versions
Divide the target into scripts_basic scripts is not
strictly necessary and was simply what was used for
testing on kernel 4.1, which is quite an old kernel
perhaps just using scripts is sufficient, but it is not tested to not
known will cause the build race as seen above.
Signed-off-by: Khem Raj
Cc: Bruce Ashfield
---
v2: Improve commit msg
.../make-mod-scripts/make-mod-scripts_1.0.bb | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
index 0be1422a24..c7edb20ee4 100644
--- a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
+++ b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
@@ -23,7 +23,8 @@ EXTRA_OEMAKE = " HOSTCC="${BUILD_CC} ${BUILD_CFLAGS}
${BUILD_LDFLAGS}" HOSTCPP="
#
do_configure() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
- oe_runmake CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \
- -C ${STAGING_KERNEL_DIR} O=${STAGING_KERNEL_BUILDDIR}
scripts prepare
-
+ for t in prepare scripts_basic scripts; do
+ oe_runmake CC="${KERNEL_CC}" LD="${KERNEL_LD}"
AR="${KERNEL_AR}" \
+ -C ${STAGING_KERNEL_DIR} O=${STAGING_KERNEL_BUILDDIR} $t
+ done
}
--
2.26.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138813):
https://lists.openembedded.org/g/openembedded-core/message/138813
Mute This Topic: https://lists.openembedded.org/mt/74507903/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] Backtrace in bitbake with OE archiver
Cross posting cause I'm not sure where the bug is, I suspect bitbake -- but it could be in OE's archiver class. I have been able to reproduce this in both Zeus and master. When I start a new project, and add the following to the local.conf: INHERIT += "archiver" ARCHIVER_MODE[src] = "original" COPYLEFT_LICENSE_INCLUDE = "" COPYLEFT_LICENSE_EXCLUDE = "" Then I run it with: bitbake core-image-minimal --runall=deploy_archives and I get a backtrace in bitbake: ERROR: Running idle function Traceback (most recent call last): File "/scratch1/fray/poky/bitbake/lib/bb/runqueue.py", line 1527, in RunQueue.execute_runqueue(): try: >return self._execute_runqueue() except bb.runqueue.TaskFailure: File "/scratch1/fray/poky/bitbake/lib/bb/runqueue.py", line 1444, in RunQueue._execute_runqueue(): [43, 967, 4, 3, 1, 5, 3, 7, 13, 1, 2, 1, 1, 246, 35, 1, 38, 1, 35, 2, 338, 204, 142, 3, 3, 37, 244]) >if self.rqdata.prepare() == 0: self.state = runQueueComplete File "/scratch1/fray/poky/bitbake/lib/bb/runqueue.py", line 935, in RunQueueData.prepare(): for tid in list(runall_tids): >mark_active(tid,1) if self.cooker.configuration.force: File "/scratch1/fray/poky/bitbake/lib/bb/runqueue.py", line 850, in mark_active(tid='/scratch1/fray/poky/meta/recipes-core/images/core-image-minimal.bb:do_deploy_archives', depth=1): for depend in depends: >mark_active(depend, depth+1) File "/scratch1/fray/poky/bitbake/lib/bb/runqueue.py", line 848, in mark_active(tid='/scratch1/fray/poky/meta/recipes-core/images/core-image-minimal.bb:do_ar_original', depth=2): >depends = self.runtaskentries[tid].depends for depend in depends: KeyError: '/scratch1/fray/poky/meta/recipes-core/images/core-image-minimal.bb:do_ar_original' As you see above the system in the mark_active function of runqueue.py is trying to reference the key of the task core-image-minimal:do_ar_original, and it can't find it and crashes out. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138812): https://lists.openembedded.org/g/openembedded-core/message/138812 Mute This Topic: https://lists.openembedded.org/mt/74507870/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] make-mod-scripts: Fix a rare build race condition
On Wed, May 27, 2020 at 3:23 PM Khem Raj wrote:
>
> On Wed, May 27, 2020 at 11:05 AM Bruce Ashfield
> wrote:
> >
> > On Wed, May 27, 2020 at 1:46 PM Khem Raj wrote:
> > >
> > > On Wed, May 27, 2020 at 9:57 AM Bruce Ashfield
> > > wrote:
> > > >
> > > > On Wed, May 27, 2020 at 12:03 PM Khem Raj wrote:
> > > > >
> > > > > There is a build break which often happens whem using 4.1 kernel
> > > > >
> > > > > /bin/sh: 1: scripts/basic/fixdep: Permission denied
> > > > > scripts/Makefile.host:124: recipe for target 'scripts/dtc/srcpos.o'
> > > > > failed
> > > > > make[3]: *** [scripts/dtc/srcpos.o] Error 126
> > > > >
> > > > > this patch sequences the build targets so it can work reliably with
> > > > > different kernel versions
> > > > >
> > > > > Signed-off-by: Khem Raj
> > > > > Cc: Bruce Ashfield
> > > > > ---
> > > > > .../make-mod-scripts/make-mod-scripts_1.0.bb | 7
> > > > > ---
> > > > > 1 file changed, 4 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git
> > > > > a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> > > > > b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> > > > > index 0be1422a24..c7edb20ee4 100644
> > > > > --- a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> > > > > +++ b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> > > > > @@ -23,7 +23,8 @@ EXTRA_OEMAKE = " HOSTCC="${BUILD_CC}
> > > > > ${BUILD_CFLAGS} ${BUILD_LDFLAGS}" HOSTCPP="
> > > > > #
> > > > > do_configure() {
> > > > > unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
> > > > > - oe_runmake CC="${KERNEL_CC}" LD="${KERNEL_LD}"
> > > > > AR="${KERNEL_AR}" \
> > > > > - -C ${STAGING_KERNEL_DIR}
> > > > > O=${STAGING_KERNEL_BUILDDIR} scripts prepare
> > > > > -
> > > > > + for t in prepare scripts_basic scripts; do
> > > >
> > > > Last I checked, we don't actually need scripts_basic.
> > > >
> > > > Isn't just sequencing prepare, followed by 'scripts' enough ?
> > > >
> > > > If not, we really should put in the long log why we need that new
> > > > target when sequencing, when we didn't need it before.
> > > >
> > >
> > > in a way you are right that scripts should cover it, but calling it
> > > out explicitly avoids any weird races if any and it does not
> > > hurt until this target is removed. I really have not debugged kernel
> > > build to see what is causing this, so there is not much
> > > details to add other than this that we are handing some race
> > > conditions which ideally should be in the makery
> > >
> >
> > But the race condition is handled with the two targets, no ? I realize
> > it doesn't hurt, but you are implying that you need all three to be
> > sure, but that really isn't the case from what I've seen.
> >
> > I just think simpler is better, but don't take my comments as an objection.
>
> Since it is a random failure that means validating any changes to fix
> it is as hard as reproducing it.
> This solution has worked over a number of builds, testing anything
> else would take as much long and I am reluctant to do that
> without a potential gain.
Minimizing the amount of change is definitely consider a gain by many
(me included).
But I'm happy enough if you can just amend the message to indicate
that it isn't strictly necessary and was simply what was used for
testing.
Since I guarantee, someday, I'll be staring at that change wondering
why it was added :D
Bruce
>
> >
> > Cheers,
> >
> > Bruce
> >
> > > > Bruce
> > > >
> > > > > + oe_runmake CC="${KERNEL_CC}" LD="${KERNEL_LD}"
> > > > > AR="${KERNEL_AR}" \
> > > > > + -C ${STAGING_KERNEL_DIR} O=${STAGING_KERNEL_BUILDDIR}
> > > > > $t
> > > > > + done
> > > > > }
> > > > > --
> > > > > 2.26.2
> > > > >
> > > >
> > > >
> > > > --
> > > > - Thou shalt not follow the NULL pointer, for chaos and madness await
> > > > thee at its end
> > > > - "Use the force Harry" - Gandalf, Star Trek II
> >
> >
> >
> > --
> > - Thou shalt not follow the NULL pointer, for chaos and madness await
> > thee at its end
> > - "Use the force Harry" - Gandalf, Star Trek II
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138811):
https://lists.openembedded.org/g/openembedded-core/message/138811
Mute This Topic: https://lists.openembedded.org/mt/74502989/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] make-mod-scripts: Fix a rare build race condition
On Wed, May 27, 2020 at 11:05 AM Bruce Ashfield
wrote:
>
> On Wed, May 27, 2020 at 1:46 PM Khem Raj wrote:
> >
> > On Wed, May 27, 2020 at 9:57 AM Bruce Ashfield
> > wrote:
> > >
> > > On Wed, May 27, 2020 at 12:03 PM Khem Raj wrote:
> > > >
> > > > There is a build break which often happens whem using 4.1 kernel
> > > >
> > > > /bin/sh: 1: scripts/basic/fixdep: Permission denied
> > > > scripts/Makefile.host:124: recipe for target 'scripts/dtc/srcpos.o'
> > > > failed
> > > > make[3]: *** [scripts/dtc/srcpos.o] Error 126
> > > >
> > > > this patch sequences the build targets so it can work reliably with
> > > > different kernel versions
> > > >
> > > > Signed-off-by: Khem Raj
> > > > Cc: Bruce Ashfield
> > > > ---
> > > > .../make-mod-scripts/make-mod-scripts_1.0.bb | 7 ---
> > > > 1 file changed, 4 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git
> > > > a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> > > > b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> > > > index 0be1422a24..c7edb20ee4 100644
> > > > --- a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> > > > +++ b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> > > > @@ -23,7 +23,8 @@ EXTRA_OEMAKE = " HOSTCC="${BUILD_CC} ${BUILD_CFLAGS}
> > > > ${BUILD_LDFLAGS}" HOSTCPP="
> > > > #
> > > > do_configure() {
> > > > unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
> > > > - oe_runmake CC="${KERNEL_CC}" LD="${KERNEL_LD}"
> > > > AR="${KERNEL_AR}" \
> > > > - -C ${STAGING_KERNEL_DIR}
> > > > O=${STAGING_KERNEL_BUILDDIR} scripts prepare
> > > > -
> > > > + for t in prepare scripts_basic scripts; do
> > >
> > > Last I checked, we don't actually need scripts_basic.
> > >
> > > Isn't just sequencing prepare, followed by 'scripts' enough ?
> > >
> > > If not, we really should put in the long log why we need that new
> > > target when sequencing, when we didn't need it before.
> > >
> >
> > in a way you are right that scripts should cover it, but calling it
> > out explicitly avoids any weird races if any and it does not
> > hurt until this target is removed. I really have not debugged kernel
> > build to see what is causing this, so there is not much
> > details to add other than this that we are handing some race
> > conditions which ideally should be in the makery
> >
>
> But the race condition is handled with the two targets, no ? I realize
> it doesn't hurt, but you are implying that you need all three to be
> sure, but that really isn't the case from what I've seen.
>
> I just think simpler is better, but don't take my comments as an objection.
Since it is a random failure that means validating any changes to fix
it is as hard as reproducing it.
This solution has worked over a number of builds, testing anything
else would take as much long and I am reluctant to do that
without a potential gain.
>
> Cheers,
>
> Bruce
>
> > > Bruce
> > >
> > > > + oe_runmake CC="${KERNEL_CC}" LD="${KERNEL_LD}"
> > > > AR="${KERNEL_AR}" \
> > > > + -C ${STAGING_KERNEL_DIR} O=${STAGING_KERNEL_BUILDDIR} $t
> > > > + done
> > > > }
> > > > --
> > > > 2.26.2
> > > >
> > >
> > >
> > > --
> > > - Thou shalt not follow the NULL pointer, for chaos and madness await
> > > thee at its end
> > > - "Use the force Harry" - Gandalf, Star Trek II
>
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138810):
https://lists.openembedded.org/g/openembedded-core/message/138810
Mute This Topic: https://lists.openembedded.org/mt/74502989/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 v2] sstate.bbclass: When siginfo or sig files are missing, stop fetcher errors
Ping
I noticed this hasn't been integrated or commented on yet.
On 5/13/20 11:12 AM, Mark Hatle wrote:
> From: Mark Hatle
>
> Prior to fetching, the system checks if the sstate file is present
> either locally or on the mirror. If it is, then it goes to the fetch
> stage. Up to three files can be fetched, sstate, sstate.siginfo and
> sstate.sig (if signature validation is enabled).
>
> The previous pstaging_fetch function would iterate over these, and if
> a download error occurred would spew forth a great amount of fetcher
> failure messages as well as stop fetching the next item in the set.
>
> This was resolved by adding a fetcher.checkstatus() call prior to
> the download. If the file isn't present, then the exception will
> be triggered, and no fetcher failure messages will reach the user.
>
> The exception handler is then modified to be a pass so that it will
> loop and pull the rest of the files that that are requested.
>
> Additionally, a check for the existance of the .sig file was added
> to the sstate_installpkg to avoid an error trying to load the .sig
> if it wasn't downloaded.
>
> Signed-off-by: Mark Hatle
> Signed-off-by: Mark Hatle
> ---
>
> v2 - fix a typo in the error message about signature not being
> present.
>
> meta/classes/sstate.bbclass | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
> index aa9c30b4e1..375196ef21 100644
> --- a/meta/classes/sstate.bbclass
> +++ b/meta/classes/sstate.bbclass
> @@ -355,6 +355,9 @@ def sstate_installpkg(ss, d):
> d.setVar('SSTATE_INSTDIR', sstateinst)
>
> if bb.utils.to_boolean(d.getVar("SSTATE_VERIFY_SIG"), False):
> +if not os.path.isfile(sstatepkg + '.sig'):
> +bb.warn("No signature file for sstate package %s, skipping
> acceleration..." % sstatepkg)
> +return False
> signer = get_signer(d, 'local')
> if not signer.verify(sstatepkg + '.sig'):
> bb.warn("Cannot verify signature on sstate package %s, skipping
> acceleration..." % sstatepkg)
> @@ -733,10 +736,11 @@ def pstaging_fetch(sstatefetch, d):
> localdata.setVar('SRC_URI', srcuri)
> try:
> fetcher = bb.fetch2.Fetch([srcuri], localdata, cache=False)
> +fetcher.checkstatus()
> fetcher.download()
>
> except bb.fetch2.BBFetchException:
> -break
> +pass
>
> def sstate_setscene(d):
> shared_state = sstate_state_fromvars(d)
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138809):
https://lists.openembedded.org/g/openembedded-core/message/138809
Mute This Topic: https://lists.openembedded.org/mt/74185410/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] qemurunner: fix ip fallback detection
When falling back from detecting ip from /proc/./cmdline the
output of runqemu is acutally
'Network configuration: ip=192.168.7.2::192.168.7.1::255.255.255.0'
which doesn't match the given regex and leading to run failure, although
IP is detectable.
Fix regex by inserting an optional 'ip=' prefix to first IP
Signed-off-by: Konrad Weihmann
---
meta/lib/oeqa/utils/qemurunner.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/lib/oeqa/utils/qemurunner.py
b/meta/lib/oeqa/utils/qemurunner.py
index 4b74337652..992fff9370 100644
--- a/meta/lib/oeqa/utils/qemurunner.py
+++ b/meta/lib/oeqa/utils/qemurunner.py
@@ -290,7 +290,7 @@ class QemuRunner:
self.logger.debug("qemu cmdline used:\n{}".format(cmdline))
except (IndexError, ValueError):
# Try to get network configuration from runqemu output
-match = re.match(r'.*Network configuration:
([0-9.]+)::([0-9.]+):([0-9.]+)$.*',
+match = re.match(r'.*Network configuration:
(?:ip=)*([0-9.]+)::([0-9.]+):([0-9.]+)$.*',
out, re.MULTILINE|re.DOTALL)
if match:
self.ip, self.server_ip, self.netmask = match.groups()
--
2.20.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138808):
https://lists.openembedded.org/g/openembedded-core/message/138808
Mute This Topic: https://lists.openembedded.org/mt/74505854/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] make-mod-scripts: Fix a rare build race condition
On Wed, May 27, 2020 at 1:46 PM Khem Raj wrote:
>
> On Wed, May 27, 2020 at 9:57 AM Bruce Ashfield
> wrote:
> >
> > On Wed, May 27, 2020 at 12:03 PM Khem Raj wrote:
> > >
> > > There is a build break which often happens whem using 4.1 kernel
> > >
> > > /bin/sh: 1: scripts/basic/fixdep: Permission denied
> > > scripts/Makefile.host:124: recipe for target 'scripts/dtc/srcpos.o' failed
> > > make[3]: *** [scripts/dtc/srcpos.o] Error 126
> > >
> > > this patch sequences the build targets so it can work reliably with
> > > different kernel versions
> > >
> > > Signed-off-by: Khem Raj
> > > Cc: Bruce Ashfield
> > > ---
> > > .../make-mod-scripts/make-mod-scripts_1.0.bb | 7 ---
> > > 1 file changed, 4 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> > > b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> > > index 0be1422a24..c7edb20ee4 100644
> > > --- a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> > > +++ b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> > > @@ -23,7 +23,8 @@ EXTRA_OEMAKE = " HOSTCC="${BUILD_CC} ${BUILD_CFLAGS}
> > > ${BUILD_LDFLAGS}" HOSTCPP="
> > > #
> > > do_configure() {
> > > unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
> > > - oe_runmake CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \
> > > - -C ${STAGING_KERNEL_DIR} O=${STAGING_KERNEL_BUILDDIR}
> > > scripts prepare
> > > -
> > > + for t in prepare scripts_basic scripts; do
> >
> > Last I checked, we don't actually need scripts_basic.
> >
> > Isn't just sequencing prepare, followed by 'scripts' enough ?
> >
> > If not, we really should put in the long log why we need that new
> > target when sequencing, when we didn't need it before.
> >
>
> in a way you are right that scripts should cover it, but calling it
> out explicitly avoids any weird races if any and it does not
> hurt until this target is removed. I really have not debugged kernel
> build to see what is causing this, so there is not much
> details to add other than this that we are handing some race
> conditions which ideally should be in the makery
>
But the race condition is handled with the two targets, no ? I realize
it doesn't hurt, but you are implying that you need all three to be
sure, but that really isn't the case from what I've seen.
I just think simpler is better, but don't take my comments as an objection.
Cheers,
Bruce
> > Bruce
> >
> > > + oe_runmake CC="${KERNEL_CC}" LD="${KERNEL_LD}"
> > > AR="${KERNEL_AR}" \
> > > + -C ${STAGING_KERNEL_DIR} O=${STAGING_KERNEL_BUILDDIR} $t
> > > + done
> > > }
> > > --
> > > 2.26.2
> > >
> >
> >
> > --
> > - Thou shalt not follow the NULL pointer, for chaos and madness await
> > thee at its end
> > - "Use the force Harry" - Gandalf, Star Trek II
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138807):
https://lists.openembedded.org/g/openembedded-core/message/138807
Mute This Topic: https://lists.openembedded.org/mt/74502989/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] make-mod-scripts: Fix a rare build race condition
On Wed, May 27, 2020 at 9:57 AM Bruce Ashfield wrote:
>
> On Wed, May 27, 2020 at 12:03 PM Khem Raj wrote:
> >
> > There is a build break which often happens whem using 4.1 kernel
> >
> > /bin/sh: 1: scripts/basic/fixdep: Permission denied
> > scripts/Makefile.host:124: recipe for target 'scripts/dtc/srcpos.o' failed
> > make[3]: *** [scripts/dtc/srcpos.o] Error 126
> >
> > this patch sequences the build targets so it can work reliably with
> > different kernel versions
> >
> > Signed-off-by: Khem Raj
> > Cc: Bruce Ashfield
> > ---
> > .../make-mod-scripts/make-mod-scripts_1.0.bb | 7 ---
> > 1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> > b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> > index 0be1422a24..c7edb20ee4 100644
> > --- a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> > +++ b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> > @@ -23,7 +23,8 @@ EXTRA_OEMAKE = " HOSTCC="${BUILD_CC} ${BUILD_CFLAGS}
> > ${BUILD_LDFLAGS}" HOSTCPP="
> > #
> > do_configure() {
> > unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
> > - oe_runmake CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \
> > - -C ${STAGING_KERNEL_DIR} O=${STAGING_KERNEL_BUILDDIR}
> > scripts prepare
> > -
> > + for t in prepare scripts_basic scripts; do
>
> Last I checked, we don't actually need scripts_basic.
>
> Isn't just sequencing prepare, followed by 'scripts' enough ?
>
> If not, we really should put in the long log why we need that new
> target when sequencing, when we didn't need it before.
>
in a way you are right that scripts should cover it, but calling it
out explicitly avoids any weird races if any and it does not
hurt until this target is removed. I really have not debugged kernel
build to see what is causing this, so there is not much
details to add other than this that we are handing some race
conditions which ideally should be in the makery
> Bruce
>
> > + oe_runmake CC="${KERNEL_CC}" LD="${KERNEL_LD}"
> > AR="${KERNEL_AR}" \
> > + -C ${STAGING_KERNEL_DIR} O=${STAGING_KERNEL_BUILDDIR} $t
> > + done
> > }
> > --
> > 2.26.2
> >
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138806):
https://lists.openembedded.org/g/openembedded-core/message/138806
Mute This Topic: https://lists.openembedded.org/mt/74502989/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 V2 2/2] u-boot: introduce UBOOT_INITIAL_ENV
On Wed, May 27, 2020 at 07:27:41PM +0200, Ming Liu wrote:
> From: Ming Liu
>
> It defaults to ${PN}-initial-env, no functional changes with current
> implementation, but this allows it to be changed in individual u-boot
> recipes.
This is fine, but as I commented on the previous revision - can you also add a
condition if UBOOT_INITIAL_ENV is empty/undefined to skip u-boot-initial-env
completely - don't build it and don't install/deploy? Thanks.
--
Denys
> The major purpose for introducing this, is that the users might have
> some scripts on targets like:
> ```
> /sbin/fw_setenv -f /etc/u-boot-initial-env
> ```
>
> and it should be able to run against a identical path generated by
> different u-boot recipes.
>
> Signed-off-by: Ming Liu
> ---
> meta/recipes-bsp/u-boot/u-boot.inc | 32 +-
> 1 file changed, 18 insertions(+), 14 deletions(-)
>
> diff --git a/meta/recipes-bsp/u-boot/u-boot.inc
> b/meta/recipes-bsp/u-boot/u-boot.inc
> index 718435f13f..e408549424 100644
> --- a/meta/recipes-bsp/u-boot/u-boot.inc
> +++ b/meta/recipes-bsp/u-boot/u-boot.inc
> @@ -60,6 +60,10 @@ UBOOT_ENV_BINARY ?= "${UBOOT_ENV}.${UBOOT_ENV_SUFFIX}"
> UBOOT_ENV_IMAGE ?= "${UBOOT_ENV}-${MACHINE}-${PV}-${PR}.${UBOOT_ENV_SUFFIX}"
> UBOOT_ENV_SYMLINK ?= "${UBOOT_ENV}-${MACHINE}.${UBOOT_ENV_SUFFIX}"
>
> +# Default name of u-boot initial env, but enable individual recipes to change
> +# this value.
> +UBOOT_INITIAL_ENV ?= "${PN}-initial-env"
> +
> # U-Boot EXTLINUX variables. U-Boot searches for /boot/extlinux/extlinux.conf
> # to find EXTLINUX conf file.
> UBOOT_EXTLINUX_INSTALL_DIR ?= "/boot/extlinux"
> @@ -155,10 +159,10 @@ do_install () {
> ln -sf u-boot-${type}-${PV}-${PR}.${UBOOT_SUFFIX}
> ${D}/boot/${UBOOT_BINARY}
>
> # Install the uboot-initial-env
> -install -D -m 644
> ${B}/${config}/u-boot-initial-env-${type}
> ${D}/${sysconfdir}/${PN}-initial-env-${MACHINE}-${type}-${PV}-${PR}
> -ln -sf ${PN}-initial-env-${MACHINE}-${type}-${PV}-${PR}
> ${D}/${sysconfdir}/${PN}-initial-env-${MACHINE}-${type}
> -ln -sf ${PN}-initial-env-${MACHINE}-${type}-${PV}-${PR}
> ${D}/${sysconfdir}/${PN}-initial-env-${type}
> -ln -sf ${PN}-initial-env-${MACHINE}-${type}-${PV}-${PR}
> ${D}/${sysconfdir}/${PN}-initial-env
> +install -D -m 644
> ${B}/${config}/u-boot-initial-env-${type}
> ${D}/${sysconfdir}/${UBOOT_INITIAL_ENV}-${MACHINE}-${type}-${PV}-${PR}
> +ln -sf
> ${UBOOT_INITIAL_ENV}-${MACHINE}-${type}-${PV}-${PR}
> ${D}/${sysconfdir}/${UBOOT_INITIAL_ENV}-${MACHINE}-${type}
> +ln -sf
> ${UBOOT_INITIAL_ENV}-${MACHINE}-${type}-${PV}-${PR}
> ${D}/${sysconfdir}/${UBOOT_INITIAL_ENV}-${type}
> +ln -sf
> ${UBOOT_INITIAL_ENV}-${MACHINE}-${type}-${PV}-${PR}
> ${D}/${sysconfdir}/${UBOOT_INITIAL_ENV}
> fi
> done
> unset j
> @@ -169,9 +173,9 @@ do_install () {
> ln -sf ${UBOOT_IMAGE} ${D}/boot/${UBOOT_BINARY}
>
> # Install the uboot-initial-env
> -install -D -m 644 ${B}/u-boot-initial-env
> ${D}/${sysconfdir}/${PN}-initial-env-${MACHINE}-${PV}-${PR}
> -ln -sf ${PN}-initial-env-${MACHINE}-${PV}-${PR}
> ${D}/${sysconfdir}/${PN}-initial-env-${MACHINE}
> -ln -sf ${PN}-initial-env-${MACHINE}-${PV}-${PR}
> ${D}/${sysconfdir}/${PN}-initial-env
> +install -D -m 644 ${B}/u-boot-initial-env
> ${D}/${sysconfdir}/${UBOOT_INITIAL_ENV}-${MACHINE}-${PV}-${PR}
> +ln -sf ${UBOOT_INITIAL_ENV}-${MACHINE}-${PV}-${PR}
> ${D}/${sysconfdir}/${UBOOT_INITIAL_ENV}-${MACHINE}
> +ln -sf ${UBOOT_INITIAL_ENV}-${MACHINE}-${PV}-${PR}
> ${D}/${sysconfdir}/${UBOOT_INITIAL_ENV}
> fi
>
> if [ -n "${UBOOT_ELF}" ]
> @@ -243,7 +247,7 @@ PACKAGE_BEFORE_PN += "${PN}-env"
>
> RPROVIDES_${PN}-env += "u-boot-default-env"
> FILES_${PN}-env = " \
> -${sysconfdir}/${PN}-initial-env* \
> +${sysconfdir}/${UBOOT_INITIAL_ENV}* \
> ${sysconfdir}/fw_env.config \
> "
>
> @@ -267,10 +271,10 @@ do_deploy () {
> ln -sf u-boot-${type}-${PV}-${PR}.${UBOOT_SUFFIX}
> ${UBOOT_BINARY}
>
> # Deploy the uboot-initial-env
> -install -D -m 644
> ${B}/${config}/u-boot-initial-env-${type}
> ${DEPLOYDIR}/${PN}-initial-env-${MACHINE}-${type}-${PV}-${PR}
> +install -D -m 644
> ${B}/${config}/u-boot-initial-env-${type}
> ${DEPLOYDIR}/${UBOOT_INITIAL_ENV}-${MACHINE}-${type}-${PV}-${PR}
> cd ${DEPLOYDIR}
> -ln -sf ${PN}-initial-env-${MACHINE}-${type}-${PV}-${PR}
> ${PN}-initial-env-${MACHINE}-${type}
> -ln -sf ${PN}-initial-env-${MACHINE}-${type}-${PV}-${PR}
> ${PN}-initial-env-${type}
> +ln -sf
> ${UBOOT_INITIAL_ENV}-${MACHINE}-${type}-${PV}-${PR}
>
[OE-core] [PATCH V2 2/2] u-boot: introduce UBOOT_INITIAL_ENV
From: Ming Liu
It defaults to ${PN}-initial-env, no functional changes with current
implementation, but this allows it to be changed in individual u-boot
recipes.
The major purpose for introducing this, is that the users might have
some scripts on targets like:
```
/sbin/fw_setenv -f /etc/u-boot-initial-env
```
and it should be able to run against a identical path generated by
different u-boot recipes.
Signed-off-by: Ming Liu
---
meta/recipes-bsp/u-boot/u-boot.inc | 32 +-
1 file changed, 18 insertions(+), 14 deletions(-)
diff --git a/meta/recipes-bsp/u-boot/u-boot.inc
b/meta/recipes-bsp/u-boot/u-boot.inc
index 718435f13f..e408549424 100644
--- a/meta/recipes-bsp/u-boot/u-boot.inc
+++ b/meta/recipes-bsp/u-boot/u-boot.inc
@@ -60,6 +60,10 @@ UBOOT_ENV_BINARY ?= "${UBOOT_ENV}.${UBOOT_ENV_SUFFIX}"
UBOOT_ENV_IMAGE ?= "${UBOOT_ENV}-${MACHINE}-${PV}-${PR}.${UBOOT_ENV_SUFFIX}"
UBOOT_ENV_SYMLINK ?= "${UBOOT_ENV}-${MACHINE}.${UBOOT_ENV_SUFFIX}"
+# Default name of u-boot initial env, but enable individual recipes to change
+# this value.
+UBOOT_INITIAL_ENV ?= "${PN}-initial-env"
+
# U-Boot EXTLINUX variables. U-Boot searches for /boot/extlinux/extlinux.conf
# to find EXTLINUX conf file.
UBOOT_EXTLINUX_INSTALL_DIR ?= "/boot/extlinux"
@@ -155,10 +159,10 @@ do_install () {
ln -sf u-boot-${type}-${PV}-${PR}.${UBOOT_SUFFIX}
${D}/boot/${UBOOT_BINARY}
# Install the uboot-initial-env
-install -D -m 644
${B}/${config}/u-boot-initial-env-${type}
${D}/${sysconfdir}/${PN}-initial-env-${MACHINE}-${type}-${PV}-${PR}
-ln -sf ${PN}-initial-env-${MACHINE}-${type}-${PV}-${PR}
${D}/${sysconfdir}/${PN}-initial-env-${MACHINE}-${type}
-ln -sf ${PN}-initial-env-${MACHINE}-${type}-${PV}-${PR}
${D}/${sysconfdir}/${PN}-initial-env-${type}
-ln -sf ${PN}-initial-env-${MACHINE}-${type}-${PV}-${PR}
${D}/${sysconfdir}/${PN}-initial-env
+install -D -m 644
${B}/${config}/u-boot-initial-env-${type}
${D}/${sysconfdir}/${UBOOT_INITIAL_ENV}-${MACHINE}-${type}-${PV}-${PR}
+ln -sf ${UBOOT_INITIAL_ENV}-${MACHINE}-${type}-${PV}-${PR}
${D}/${sysconfdir}/${UBOOT_INITIAL_ENV}-${MACHINE}-${type}
+ln -sf ${UBOOT_INITIAL_ENV}-${MACHINE}-${type}-${PV}-${PR}
${D}/${sysconfdir}/${UBOOT_INITIAL_ENV}-${type}
+ln -sf ${UBOOT_INITIAL_ENV}-${MACHINE}-${type}-${PV}-${PR}
${D}/${sysconfdir}/${UBOOT_INITIAL_ENV}
fi
done
unset j
@@ -169,9 +173,9 @@ do_install () {
ln -sf ${UBOOT_IMAGE} ${D}/boot/${UBOOT_BINARY}
# Install the uboot-initial-env
-install -D -m 644 ${B}/u-boot-initial-env
${D}/${sysconfdir}/${PN}-initial-env-${MACHINE}-${PV}-${PR}
-ln -sf ${PN}-initial-env-${MACHINE}-${PV}-${PR}
${D}/${sysconfdir}/${PN}-initial-env-${MACHINE}
-ln -sf ${PN}-initial-env-${MACHINE}-${PV}-${PR}
${D}/${sysconfdir}/${PN}-initial-env
+install -D -m 644 ${B}/u-boot-initial-env
${D}/${sysconfdir}/${UBOOT_INITIAL_ENV}-${MACHINE}-${PV}-${PR}
+ln -sf ${UBOOT_INITIAL_ENV}-${MACHINE}-${PV}-${PR}
${D}/${sysconfdir}/${UBOOT_INITIAL_ENV}-${MACHINE}
+ln -sf ${UBOOT_INITIAL_ENV}-${MACHINE}-${PV}-${PR}
${D}/${sysconfdir}/${UBOOT_INITIAL_ENV}
fi
if [ -n "${UBOOT_ELF}" ]
@@ -243,7 +247,7 @@ PACKAGE_BEFORE_PN += "${PN}-env"
RPROVIDES_${PN}-env += "u-boot-default-env"
FILES_${PN}-env = " \
-${sysconfdir}/${PN}-initial-env* \
+${sysconfdir}/${UBOOT_INITIAL_ENV}* \
${sysconfdir}/fw_env.config \
"
@@ -267,10 +271,10 @@ do_deploy () {
ln -sf u-boot-${type}-${PV}-${PR}.${UBOOT_SUFFIX}
${UBOOT_BINARY}
# Deploy the uboot-initial-env
-install -D -m 644
${B}/${config}/u-boot-initial-env-${type}
${DEPLOYDIR}/${PN}-initial-env-${MACHINE}-${type}-${PV}-${PR}
+install -D -m 644
${B}/${config}/u-boot-initial-env-${type}
${DEPLOYDIR}/${UBOOT_INITIAL_ENV}-${MACHINE}-${type}-${PV}-${PR}
cd ${DEPLOYDIR}
-ln -sf ${PN}-initial-env-${MACHINE}-${type}-${PV}-${PR}
${PN}-initial-env-${MACHINE}-${type}
-ln -sf ${PN}-initial-env-${MACHINE}-${type}-${PV}-${PR}
${PN}-initial-env-${type}
+ln -sf ${UBOOT_INITIAL_ENV}-${MACHINE}-${type}-${PV}-${PR}
${UBOOT_INITIAL_ENV}-${MACHINE}-${type}
+ln -sf ${UBOOT_INITIAL_ENV}-${MACHINE}-${type}-${PV}-${PR}
${UBOOT_INITIAL_ENV}-${type}
fi
done
unset j
@@ -285,10 +289,10 @@ do_deploy () {
ln -sf ${UBOOT_IMAGE} ${UBOOT_BINARY}
# Deploy the uboot-initial-env
-install -D -m 644 ${B}/u-boot-initial-env
${DEPLOYDIR}/${PN}-initial-env-${MACHINE}-${PV}-${PR}
+install -D -m 644 ${B}/u-boot-initial-env
[OE-core] [PATCH V2 1/2] u-boot.inc: fix some inconsistent coding style
From: Ming Liu
Signed-off-by: Ming Liu
---
meta/recipes-bsp/u-boot/u-boot.inc | 44 ++
1 file changed, 21 insertions(+), 23 deletions(-)
diff --git a/meta/recipes-bsp/u-boot/u-boot.inc
b/meta/recipes-bsp/u-boot/u-boot.inc
index 80f828df52..718435f13f 100644
--- a/meta/recipes-bsp/u-boot/u-boot.inc
+++ b/meta/recipes-bsp/u-boot/u-boot.inc
@@ -91,19 +91,19 @@ do_configure () {
}
do_compile () {
- if [ "${@bb.utils.filter('DISTRO_FEATURES', 'ld-is-gold', d)}" ]; then
- sed -i 's/$(CROSS_COMPILE)ld$/$(CROSS_COMPILE)ld.bfd/g'
${S}/config.mk
- fi
+if [ "${@bb.utils.filter('DISTRO_FEATURES', 'ld-is-gold', d)}" ]; then
+sed -i 's/$(CROSS_COMPILE)ld$/$(CROSS_COMPILE)ld.bfd/g' ${S}/config.mk
+fi
- unset LDFLAGS
- unset CFLAGS
- unset CPPFLAGS
+unset LDFLAGS
+unset CFLAGS
+unset CPPFLAGS
- if [ ! -e ${B}/.scmversion -a ! -e ${S}/.scmversion ]
- then
- echo ${UBOOT_LOCALVERSION} > ${B}/.scmversion
- echo ${UBOOT_LOCALVERSION} > ${S}/.scmversion
- fi
+if [ ! -e ${B}/.scmversion -a ! -e ${S}/.scmversion ]
+then
+echo ${UBOOT_LOCALVERSION} > ${B}/.scmversion
+echo ${UBOOT_LOCALVERSION} > ${S}/.scmversion
+fi
if [ -n "${UBOOT_CONFIG}" ]
then
@@ -130,16 +130,15 @@ do_compile () {
unset k
fi
done
-unset j
+unset j
done
-unset i
+unset i
else
oe_runmake -C ${S} O=${B} ${UBOOT_MAKE_TARGET}
# Generate the uboot-initial-env
oe_runmake -C ${S} O=${B} u-boot-initial-env
fi
-
}
do_install () {
@@ -162,9 +161,9 @@ do_install () {
ln -sf ${PN}-initial-env-${MACHINE}-${type}-${PV}-${PR}
${D}/${sysconfdir}/${PN}-initial-env
fi
done
-unset j
+unset j
done
-unset i
+unset i
else
install -D -m 644 ${B}/${UBOOT_BINARY} ${D}/boot/${UBOOT_IMAGE}
ln -sf ${UBOOT_IMAGE} ${D}/boot/${UBOOT_BINARY}
@@ -219,9 +218,9 @@ do_install () {
ln -sf ${SPL_IMAGE}-${type}-${PV}-${PR}
${D}/boot/${SPL_BINARYNAME}
fi
done
-unset j
+unset j
done
-unset i
+unset i
else
install -m 644 ${B}/${SPL_BINARY} ${D}/boot/${SPL_IMAGE}
ln -sf ${SPL_IMAGE} ${D}/boot/${SPL_BINARYNAME}
@@ -238,7 +237,6 @@ do_install () {
then
install -Dm 0644 ${UBOOT_EXTLINUX_CONFIG}
${D}/${UBOOT_EXTLINUX_INSTALL_DIR}/${UBOOT_EXTLINUX_CONF_NAME}
fi
-
}
PACKAGE_BEFORE_PN += "${PN}-env"
@@ -275,9 +273,9 @@ do_deploy () {
ln -sf ${PN}-initial-env-${MACHINE}-${type}-${PV}-${PR}
${PN}-initial-env-${type}
fi
done
-unset j
+unset j
done
-unset i
+unset i
else
install -D -m 644 ${B}/${UBOOT_BINARY} ${DEPLOYDIR}/${UBOOT_IMAGE}
@@ -346,9 +344,9 @@ do_deploy () {
ln -sf ${SPL_IMAGE}-${type}-${PV}-${PR}
${DEPLOYDIR}/${SPL_SYMLINK}
fi
done
-unset j
+unset j
done
-unset i
+unset i
else
install -m 644 ${B}/${SPL_BINARY} ${DEPLOYDIR}/${SPL_IMAGE}
rm -f ${DEPLOYDIR}/${SPL_BINARYNAME} ${DEPLOYDIR}/${SPL_SYMLINK}
--
2.26.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138803):
https://lists.openembedded.org/g/openembedded-core/message/138803
Mute This Topic: https://lists.openembedded.org/mt/74504985/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 V2 0/2] Introduce UBOOT_INITIAL_ENV/coding style fixes
From: Ming Liu Changes in V2: 1 Introduce UBOOT_INITIAL_ENV as suggested by Denys Dmytriyenko. 2 Add fix for some inconsistent coding style. Ming Liu (2): u-boot.inc: fix some inconsistent coding style u-boot: introduce UBOOT_INITIAL_ENV meta/recipes-bsp/u-boot/u-boot.inc | 76 +++--- 1 file changed, 39 insertions(+), 37 deletions(-) -- 2.26.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138802): https://lists.openembedded.org/g/openembedded-core/message/138802 Mute This Topic: https://lists.openembedded.org/mt/74504981/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] make-mod-scripts: Fix a rare build race condition
On Wed, May 27, 2020 at 12:03 PM Khem Raj wrote:
>
> There is a build break which often happens whem using 4.1 kernel
>
> /bin/sh: 1: scripts/basic/fixdep: Permission denied
> scripts/Makefile.host:124: recipe for target 'scripts/dtc/srcpos.o' failed
> make[3]: *** [scripts/dtc/srcpos.o] Error 126
>
> this patch sequences the build targets so it can work reliably with
> different kernel versions
>
> Signed-off-by: Khem Raj
> Cc: Bruce Ashfield
> ---
> .../make-mod-scripts/make-mod-scripts_1.0.bb | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> index 0be1422a24..c7edb20ee4 100644
> --- a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> +++ b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> @@ -23,7 +23,8 @@ EXTRA_OEMAKE = " HOSTCC="${BUILD_CC} ${BUILD_CFLAGS}
> ${BUILD_LDFLAGS}" HOSTCPP="
> #
> do_configure() {
> unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
> - oe_runmake CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \
> - -C ${STAGING_KERNEL_DIR} O=${STAGING_KERNEL_BUILDDIR}
> scripts prepare
> -
> + for t in prepare scripts_basic scripts; do
Last I checked, we don't actually need scripts_basic.
Isn't just sequencing prepare, followed by 'scripts' enough ?
If not, we really should put in the long log why we need that new
target when sequencing, when we didn't need it before.
Bruce
> + oe_runmake CC="${KERNEL_CC}" LD="${KERNEL_LD}"
> AR="${KERNEL_AR}" \
> + -C ${STAGING_KERNEL_DIR} O=${STAGING_KERNEL_BUILDDIR} $t
> + done
> }
> --
> 2.26.2
>
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138801):
https://lists.openembedded.org/g/openembedded-core/message/138801
Mute This Topic: https://lists.openembedded.org/mt/74502989/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] libksba: upgrade 1.3.5 -> 1.4.0
I believe we rely on this patch to ensure gnupg builds correctly; have you
checked that it doesn't regress?
I think you need to forward port the patch to new libksba unfortunately.
Alex
On Wed, 27 May 2020 at 17:32, Wang Mingyu wrote:
> ksba-add-pkgconfig-support.patch
> removed since it is not available in 1.4.0
>
> Signed-off-by: Wang Mingyu
> ---
> .../libksba/ksba-add-pkgconfig-support.patch | 152 --
> .../{libksba_1.3.5.bb => libksba_1.4.0.bb}| 7 +-
> 2 files changed, 3 insertions(+), 156 deletions(-)
> delete mode 100644
> meta/recipes-support/libksba/libksba/ksba-add-pkgconfig-support.patch
> rename meta/recipes-support/libksba/{libksba_1.3.5.bb => libksba_1.4.0.bb}
> (78%)
>
> diff --git
> a/meta/recipes-support/libksba/libksba/ksba-add-pkgconfig-support.patch
> b/meta/recipes-support/libksba/libksba/ksba-add-pkgconfig-support.patch
> deleted file mode 100644
> index 5afe6de923..00
> --- a/meta/recipes-support/libksba/libksba/ksba-add-pkgconfig-support.patch
> +++ /dev/null
> @@ -1,152 +0,0 @@
> -Upstream-Status: Denied
> -
> -Add pkgconfig support to libksba.
> -This patch is rejected by upstream for the reason below:
> -They think pkgconfig adds no portability and maintaining them is not
> worthwhile.
> -
> -Signed-off-by: Chen Qi
> -
> -Index: libksba-1.3.5/Makefile.am
> -===
> libksba-1.3.5.orig/Makefile.am
> -+++ libksba-1.3.5/Makefile.am
> -@@ -20,6 +20,9 @@
> -
> - ACLOCAL_AMFLAGS = -I m4 -I gl/m4
> -
> -+pkgconfigdir = ${libdir}/pkgconfig
> -+pkgconfig_DATA = ksba.pc
> -+
> - # (A suitable gitlog-to-changelog script can be found in GnuPG master.)
> - GITLOG_TO_CHANGELOG=gitlog-to-changelog
> -
> -Index: libksba-1.3.5/configure.ac
> -===
> libksba-1.3.5.orig/configure.ac
> -+++ libksba-1.3.5/configure.ac
> -@@ -414,6 +414,7 @@ gl/Makefile
> - src/Makefile
> - src/ksba-config
> - src/versioninfo.rc
> -+ksba.pc
> - tests/Makefile
> - doc/Makefile
> - ])
> -Index: libksba-1.3.5/ksba.pc.in
> -===
> /dev/null
> -+++ libksba-1.3.5/ksba.pc.in
> -@@ -0,0 +1,17 @@
> -+prefix=@prefix@
> -+exec_prefix=@exec_prefix@
> -+libdir=@libdir@
> -+includedir=@includedir@
> -+
> -+# API info
> -+api_version=@KSBA_CONFIG_API_VERSION@
> -+host=@KSBA_CONFIG_HOST@
> -+
> -+Name: ksba
> -+Description: Libksba provides an easy API to create and parse X.509 and
> CMS related objects
> -+Requires:
> -+Version: @VERSION@
> -+Libs: -L${libdir} -lksba
> -+Libs.private: -L${libdir} -lgpg-error
> -+Cflags: -I${includedir}
> -+
> -Index: libksba-1.3.5/src/ksba.m4
> -===
> libksba-1.3.5.orig/src/ksba.m4
> -+++ libksba-1.3.5/src/ksba.m4
> -@@ -22,18 +22,7 @@ dnl with a changed API.
> - dnl
> - AC_DEFUN([AM_PATH_KSBA],
> - [AC_REQUIRE([AC_CANONICAL_HOST])
> -- AC_ARG_WITH(ksba-prefix,
> --AC_HELP_STRING([--with-ksba-prefix=PFX],
> -- [prefix where KSBA is installed (optional)]),
> -- ksba_config_prefix="$withval", ksba_config_prefix="")
> -- if test x$ksba_config_prefix != x ; then
> -- ksba_config_args="$ksba_config_args --prefix=$ksba_config_prefix"
> -- if test x${KSBA_CONFIG+set} != xset ; then
> --KSBA_CONFIG=$ksba_config_prefix/bin/ksba-config
> -- fi
> -- fi
> -
> -- AC_PATH_PROG(KSBA_CONFIG, ksba-config, no)
> - tmp=ifelse([$1], ,1:1.0.0,$1)
> - if echo "$tmp" | grep ':' >/dev/null 2>/dev/null ; then
> - req_ksba_api=`echo "$tmp" | sed 's/\(.*\):\(.*\)/\1/'`
> -@@ -43,48 +32,13 @@ AC_DEFUN([AM_PATH_KSBA],
> - min_ksba_version="$tmp"
> - fi
> -
> -- AC_MSG_CHECKING(for KSBA - version >= $min_ksba_version)
> -- ok=no
> -- if test "$KSBA_CONFIG" != "no" ; then
> --req_major=`echo $min_ksba_version | \
> -- sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\1/'`
> --req_minor=`echo $min_ksba_version | \
> -- sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\2/'`
> --req_micro=`echo $min_ksba_version | \
> -- sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\3/'`
> --ksba_config_version=`$KSBA_CONFIG $ksba_config_args --version`
> --major=`echo $ksba_config_version | \
> -- sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\).*/\1/'`
> --minor=`echo $ksba_config_version | \
> -- sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\).*/\2/'`
> --micro=`echo $ksba_config_version | \
> -- sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\).*/\3/'`
> --if test "$major" -gt "$req_major"; then
> --ok=yes
> --else
> --if test "$major" -eq "$req_major"; then
> --if test "$minor" -gt "$req_minor"; then
> -- ok=yes
> --else
> -- if test "$minor" -eq "$req_minor"; then
>
Re: [OE-core] [PATCH] make-mod-scripts: Fix a rare build race condition
On Wed, May 27, 2020 at 09:03:55AM -0700, Khem Raj wrote:
> There is a build break which often happens whem using 4.1 kernel
>
> /bin/sh: 1: scripts/basic/fixdep: Permission denied
> scripts/Makefile.host:124: recipe for target 'scripts/dtc/srcpos.o' failed
> make[3]: *** [scripts/dtc/srcpos.o] Error 126
>
> this patch sequences the build targets so it can work reliably with
> different kernel versions
Oh, I remember this failure from few years ago. Was it fixed upstream? Any
specifics?
> Signed-off-by: Khem Raj
> Cc: Bruce Ashfield
> ---
> .../make-mod-scripts/make-mod-scripts_1.0.bb | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> index 0be1422a24..c7edb20ee4 100644
> --- a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> +++ b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> @@ -23,7 +23,8 @@ EXTRA_OEMAKE = " HOSTCC="${BUILD_CC} ${BUILD_CFLAGS}
> ${BUILD_LDFLAGS}" HOSTCPP="
> #
> do_configure() {
> unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
> - oe_runmake CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \
> --C ${STAGING_KERNEL_DIR} O=${STAGING_KERNEL_BUILDDIR}
> scripts prepare
> -
> + for t in prepare scripts_basic scripts; do
> + oe_runmake CC="${KERNEL_CC}" LD="${KERNEL_LD}"
> AR="${KERNEL_AR}" \
> + -C ${STAGING_KERNEL_DIR} O=${STAGING_KERNEL_BUILDDIR} $t
> + done
> }
> --
> 2.26.2
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138799):
https://lists.openembedded.org/g/openembedded-core/message/138799
Mute This Topic: https://lists.openembedded.org/mt/74502989/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] make-mod-scripts: Fix a rare build race condition
There is a build break which often happens whem using 4.1 kernel
/bin/sh: 1: scripts/basic/fixdep: Permission denied
scripts/Makefile.host:124: recipe for target 'scripts/dtc/srcpos.o' failed
make[3]: *** [scripts/dtc/srcpos.o] Error 126
this patch sequences the build targets so it can work reliably with
different kernel versions
Signed-off-by: Khem Raj
Cc: Bruce Ashfield
---
.../make-mod-scripts/make-mod-scripts_1.0.bb | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
index 0be1422a24..c7edb20ee4 100644
--- a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
+++ b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
@@ -23,7 +23,8 @@ EXTRA_OEMAKE = " HOSTCC="${BUILD_CC} ${BUILD_CFLAGS}
${BUILD_LDFLAGS}" HOSTCPP="
#
do_configure() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
- oe_runmake CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \
- -C ${STAGING_KERNEL_DIR} O=${STAGING_KERNEL_BUILDDIR}
scripts prepare
-
+ for t in prepare scripts_basic scripts; do
+ oe_runmake CC="${KERNEL_CC}" LD="${KERNEL_LD}"
AR="${KERNEL_AR}" \
+ -C ${STAGING_KERNEL_DIR} O=${STAGING_KERNEL_BUILDDIR} $t
+ done
}
--
2.26.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138798):
https://lists.openembedded.org/g/openembedded-core/message/138798
Mute This Topic: https://lists.openembedded.org/mt/74502989/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-libc-headers: Check for asm/bpf_perf_event.h before multilibbing
On Wed, May 27, 2020 at 08:50:11AM -0700, Khem Raj wrote:
> asm/bpf_perf_event.h does not exist in older kernels e.g. ( 4.1 )
> this helps in using common header across multiple versions of kernel
> going back
This check should have been there from the beginning and for every header
file. It's big PITA to sync this list up, especially when dealing with
different glibc or kernel than OE-Core, e.g. external toolchains, etc.
Any objections to making this check more generic for every entry in the list?
--
Denys
> Signed-off-by: Khem Raj
> ---
> .../recipes-kernel/linux-libc-headers/linux-libc-headers.inc | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
> b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
> index 4481aa430c..933a01ba81 100644
> --- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
> +++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
> @@ -81,8 +81,11 @@ do_install_append_armeb () {
> }
>
> do_install_armmultilib () {
> - oe_multilib_header asm/auxvec.h asm/bitsperlong.h asm/byteorder.h
> asm/fcntl.h asm/hwcap.h asm/ioctls.h asm/kvm.h asm/kvm_para.h asm/mman.h
> asm/param.h asm/perf_regs.h asm/bpf_perf_event.h
> + oe_multilib_header asm/auxvec.h asm/bitsperlong.h asm/byteorder.h
> asm/fcntl.h asm/hwcap.h asm/ioctls.h asm/kvm.h asm/kvm_para.h asm/mman.h
> asm/param.h asm/perf_regs.h
> oe_multilib_header asm/posix_types.h asm/ptrace.h asm/setup.h
> asm/sigcontext.h asm/siginfo.h asm/signal.h asm/stat.h asm/statfs.h
> asm/swab.h asm/types.h asm/unistd.h
> + if [ -f "${D}/${includedir}/asm/bpf_perf_event.h" ]; then
> + oe_multilib_header asm/bpf_perf_event.h
> + fi
> }
>
> BBCLASSEXTEND = "nativesdk"
> --
> 2.26.2
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138797):
https://lists.openembedded.org/g/openembedded-core/message/138797
Mute This Topic: https://lists.openembedded.org/mt/74502640/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-libc-headers: Check for asm/bpf_perf_event.h before multilibbing
asm/bpf_perf_event.h does not exist in older kernels e.g. ( 4.1 )
this helps in using common header across multiple versions of kernel
going back
Signed-off-by: Khem Raj
---
.../recipes-kernel/linux-libc-headers/linux-libc-headers.inc | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
index 4481aa430c..933a01ba81 100644
--- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
+++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
@@ -81,8 +81,11 @@ do_install_append_armeb () {
}
do_install_armmultilib () {
- oe_multilib_header asm/auxvec.h asm/bitsperlong.h asm/byteorder.h
asm/fcntl.h asm/hwcap.h asm/ioctls.h asm/kvm.h asm/kvm_para.h asm/mman.h
asm/param.h asm/perf_regs.h asm/bpf_perf_event.h
+ oe_multilib_header asm/auxvec.h asm/bitsperlong.h asm/byteorder.h
asm/fcntl.h asm/hwcap.h asm/ioctls.h asm/kvm.h asm/kvm_para.h asm/mman.h
asm/param.h asm/perf_regs.h
oe_multilib_header asm/posix_types.h asm/ptrace.h asm/setup.h
asm/sigcontext.h asm/siginfo.h asm/signal.h asm/stat.h asm/statfs.h asm/swab.h
asm/types.h asm/unistd.h
+ if [ -f "${D}/${includedir}/asm/bpf_perf_event.h" ]; then
+ oe_multilib_header asm/bpf_perf_event.h
+ fi
}
BBCLASSEXTEND = "nativesdk"
--
2.26.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138796):
https://lists.openembedded.org/g/openembedded-core/message/138796
Mute This Topic: https://lists.openembedded.org/mt/74502640/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] libyaml: upgrade 0.2.2 -> 0.2.4
-License-Update: file name changed from LICENSE to License.
Copyright year updated to 2020.
Signed-off-by: Zheng Ruoqin
---
.../libyaml/{libyaml_0.2.2.bb => libyaml_0.2.4.bb} | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
rename meta/recipes-support/libyaml/{libyaml_0.2.2.bb => libyaml_0.2.4.bb}
(66%)
diff --git a/meta/recipes-support/libyaml/libyaml_0.2.2.bb
b/meta/recipes-support/libyaml/libyaml_0.2.4.bb
similarity index 66%
rename from meta/recipes-support/libyaml/libyaml_0.2.2.bb
rename to meta/recipes-support/libyaml/libyaml_0.2.4.bb
index 5105ce69db..e1817748bc 100644
--- a/meta/recipes-support/libyaml/libyaml_0.2.2.bb
+++ b/meta/recipes-support/libyaml/libyaml_0.2.4.bb
@@ -5,11 +5,11 @@ HOMEPAGE = "https://pyyaml.org/wiki/LibYAML;
SECTION = "libs/devel"
LICENSE = "MIT"
-LIC_FILES_CHKSUM = "file://LICENSE;md5=a76b4c69bfcf82313bbdc0393b04438a"
+LIC_FILES_CHKSUM = "file://License;md5=7bbd28caa69f81f5cd5f48647236663d"
SRC_URI = "https://pyyaml.org/download/libyaml/yaml-${PV}.tar.gz;
-SRC_URI[md5sum] = "54bf11ccb8bc488b5b3bec931f5b70dc"
-SRC_URI[sha256sum] =
"4a9100ab61047fd9bd395bcef3ce5403365cafd55c1e0d0299cde14958e47be9"
+SRC_URI[md5sum] = "0532bb32548ee92f1c0328aa8a87dec7"
+SRC_URI[sha256sum] =
"d80aeda8747b7c26fbbfd87ab687786e58394a8435ae3970e79cb97882e30557"
S = "${WORKDIR}/yaml-${PV}"
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138795):
https://lists.openembedded.org/g/openembedded-core/message/138795
Mute This Topic: https://lists.openembedded.org/mt/74502309/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] gdb: upgrade 9.1 -> 9.2
Signed-off-by: Zheng Ruoqin
---
meta/recipes-devtools/gdb/{gdb-9.1.inc => gdb-9.2.inc}| 4 ++--
.../{gdb-cross-canadian_9.1.bb => gdb-cross-canadian_9.2.bb} | 0
.../gdb/{gdb-cross_9.1.bb => gdb-cross_9.2.bb}| 0
meta/recipes-devtools/gdb/{gdb_9.1.bb => gdb_9.2.bb} | 0
4 files changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-devtools/gdb/{gdb-9.1.inc => gdb-9.2.inc} (88%)
rename meta/recipes-devtools/gdb/{gdb-cross-canadian_9.1.bb =>
gdb-cross-canadian_9.2.bb} (100%)
rename meta/recipes-devtools/gdb/{gdb-cross_9.1.bb => gdb-cross_9.2.bb} (100%)
rename meta/recipes-devtools/gdb/{gdb_9.1.bb => gdb_9.2.bb} (100%)
diff --git a/meta/recipes-devtools/gdb/gdb-9.1.inc
b/meta/recipes-devtools/gdb/gdb-9.2.inc
similarity index 88%
rename from meta/recipes-devtools/gdb/gdb-9.1.inc
rename to meta/recipes-devtools/gdb/gdb-9.2.inc
index d019e6b384..017b61ef62 100644
--- a/meta/recipes-devtools/gdb/gdb-9.1.inc
+++ b/meta/recipes-devtools/gdb/gdb-9.2.inc
@@ -17,5 +17,5 @@ SRC_URI = "${GNU_MIRROR}/gdb/gdb-${PV}.tar.xz \
file://0010-Fix-invalid-sigprocmask-call.patch \
file://0011-gdbserver-ctrl-c-handling.patch \
"
-SRC_URI[md5sum] = "f7e9f6236c425097d9e5f18a6ac40655"
-SRC_URI[sha256sum] =
"699e0ec832fdd2f21c8266171ea5bf44024bd05164fdf064e4d10cc4cf0d1737"
+SRC_URI[md5sum] = "db95524e554870209ab7d9f8fd8dc557"
+SRC_URI[sha256sum] =
"360cd7ae79b776988e89d8f9a01c985d0b1fa21c767a4295e5f88cb49175c555"
diff --git a/meta/recipes-devtools/gdb/gdb-cross-canadian_9.1.bb
b/meta/recipes-devtools/gdb/gdb-cross-canadian_9.2.bb
similarity index 100%
rename from meta/recipes-devtools/gdb/gdb-cross-canadian_9.1.bb
rename to meta/recipes-devtools/gdb/gdb-cross-canadian_9.2.bb
diff --git a/meta/recipes-devtools/gdb/gdb-cross_9.1.bb
b/meta/recipes-devtools/gdb/gdb-cross_9.2.bb
similarity index 100%
rename from meta/recipes-devtools/gdb/gdb-cross_9.1.bb
rename to meta/recipes-devtools/gdb/gdb-cross_9.2.bb
diff --git a/meta/recipes-devtools/gdb/gdb_9.1.bb
b/meta/recipes-devtools/gdb/gdb_9.2.bb
similarity index 100%
rename from meta/recipes-devtools/gdb/gdb_9.1.bb
rename to meta/recipes-devtools/gdb/gdb_9.2.bb
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138794):
https://lists.openembedded.org/g/openembedded-core/message/138794
Mute This Topic: https://lists.openembedded.org/mt/74502292/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] liburcu: upgrade 0.12.0 -> 0.12.1
Signed-off-by: Wang Mingyu
---
.../liburcu/{liburcu_0.12.0.bb => liburcu_0.12.1.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-support/liburcu/{liburcu_0.12.0.bb => liburcu_0.12.1.bb}
(83%)
diff --git a/meta/recipes-support/liburcu/liburcu_0.12.0.bb
b/meta/recipes-support/liburcu/liburcu_0.12.1.bb
similarity index 83%
rename from meta/recipes-support/liburcu/liburcu_0.12.0.bb
rename to meta/recipes-support/liburcu/liburcu_0.12.1.bb
index 0c20abe6d5..3a5ecbcc2d 100644
--- a/meta/recipes-support/liburcu/liburcu_0.12.0.bb
+++ b/meta/recipes-support/liburcu/liburcu_0.12.1.bb
@@ -9,8 +9,8 @@ LIC_FILES_CHKSUM =
"file://LICENSE;md5=e548d28737289d75a8f1e01ba2fd7825 \
SRC_URI = "http://lttng.org/files/urcu/userspace-rcu-${PV}.tar.bz2;
-SRC_URI[md5sum] = "d923a42ce38e33e883313003c8afd559"
-SRC_URI[sha256sum] =
"409b1be506989e1d26543194df1a79212be990fe5d4fd84f34f019efed989f97"
+SRC_URI[md5sum] = "5e419d7b30d0d98bffe0014c704ae936"
+SRC_URI[sha256sum] =
"bbfaead0345642b97e0de90f889dfbab4b2643a6a5e5c6bb59cd0d26fc0bcd0e"
S = "${WORKDIR}/userspace-rcu-${PV}"
inherit autotools multilib_header
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138793):
https://lists.openembedded.org/g/openembedded-core/message/138793
Mute This Topic: https://lists.openembedded.org/mt/74502273/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] libksba: upgrade 1.3.5 -> 1.4.0
ksba-add-pkgconfig-support.patch
removed since it is not available in 1.4.0
Signed-off-by: Wang Mingyu
---
.../libksba/ksba-add-pkgconfig-support.patch | 152 --
.../{libksba_1.3.5.bb => libksba_1.4.0.bb}| 7 +-
2 files changed, 3 insertions(+), 156 deletions(-)
delete mode 100644
meta/recipes-support/libksba/libksba/ksba-add-pkgconfig-support.patch
rename meta/recipes-support/libksba/{libksba_1.3.5.bb => libksba_1.4.0.bb}
(78%)
diff --git
a/meta/recipes-support/libksba/libksba/ksba-add-pkgconfig-support.patch
b/meta/recipes-support/libksba/libksba/ksba-add-pkgconfig-support.patch
deleted file mode 100644
index 5afe6de923..00
--- a/meta/recipes-support/libksba/libksba/ksba-add-pkgconfig-support.patch
+++ /dev/null
@@ -1,152 +0,0 @@
-Upstream-Status: Denied
-
-Add pkgconfig support to libksba.
-This patch is rejected by upstream for the reason below:
-They think pkgconfig adds no portability and maintaining them is not
worthwhile.
-
-Signed-off-by: Chen Qi
-
-Index: libksba-1.3.5/Makefile.am
-===
libksba-1.3.5.orig/Makefile.am
-+++ libksba-1.3.5/Makefile.am
-@@ -20,6 +20,9 @@
-
- ACLOCAL_AMFLAGS = -I m4 -I gl/m4
-
-+pkgconfigdir = ${libdir}/pkgconfig
-+pkgconfig_DATA = ksba.pc
-+
- # (A suitable gitlog-to-changelog script can be found in GnuPG master.)
- GITLOG_TO_CHANGELOG=gitlog-to-changelog
-
-Index: libksba-1.3.5/configure.ac
-===
libksba-1.3.5.orig/configure.ac
-+++ libksba-1.3.5/configure.ac
-@@ -414,6 +414,7 @@ gl/Makefile
- src/Makefile
- src/ksba-config
- src/versioninfo.rc
-+ksba.pc
- tests/Makefile
- doc/Makefile
- ])
-Index: libksba-1.3.5/ksba.pc.in
-===
/dev/null
-+++ libksba-1.3.5/ksba.pc.in
-@@ -0,0 +1,17 @@
-+prefix=@prefix@
-+exec_prefix=@exec_prefix@
-+libdir=@libdir@
-+includedir=@includedir@
-+
-+# API info
-+api_version=@KSBA_CONFIG_API_VERSION@
-+host=@KSBA_CONFIG_HOST@
-+
-+Name: ksba
-+Description: Libksba provides an easy API to create and parse X.509 and CMS
related objects
-+Requires:
-+Version: @VERSION@
-+Libs: -L${libdir} -lksba
-+Libs.private: -L${libdir} -lgpg-error
-+Cflags: -I${includedir}
-+
-Index: libksba-1.3.5/src/ksba.m4
-===
libksba-1.3.5.orig/src/ksba.m4
-+++ libksba-1.3.5/src/ksba.m4
-@@ -22,18 +22,7 @@ dnl with a changed API.
- dnl
- AC_DEFUN([AM_PATH_KSBA],
- [AC_REQUIRE([AC_CANONICAL_HOST])
-- AC_ARG_WITH(ksba-prefix,
--AC_HELP_STRING([--with-ksba-prefix=PFX],
-- [prefix where KSBA is installed (optional)]),
-- ksba_config_prefix="$withval", ksba_config_prefix="")
-- if test x$ksba_config_prefix != x ; then
-- ksba_config_args="$ksba_config_args --prefix=$ksba_config_prefix"
-- if test x${KSBA_CONFIG+set} != xset ; then
--KSBA_CONFIG=$ksba_config_prefix/bin/ksba-config
-- fi
-- fi
-
-- AC_PATH_PROG(KSBA_CONFIG, ksba-config, no)
- tmp=ifelse([$1], ,1:1.0.0,$1)
- if echo "$tmp" | grep ':' >/dev/null 2>/dev/null ; then
- req_ksba_api=`echo "$tmp" | sed 's/\(.*\):\(.*\)/\1/'`
-@@ -43,48 +32,13 @@ AC_DEFUN([AM_PATH_KSBA],
- min_ksba_version="$tmp"
- fi
-
-- AC_MSG_CHECKING(for KSBA - version >= $min_ksba_version)
-- ok=no
-- if test "$KSBA_CONFIG" != "no" ; then
--req_major=`echo $min_ksba_version | \
-- sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\1/'`
--req_minor=`echo $min_ksba_version | \
-- sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\2/'`
--req_micro=`echo $min_ksba_version | \
-- sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\3/'`
--ksba_config_version=`$KSBA_CONFIG $ksba_config_args --version`
--major=`echo $ksba_config_version | \
-- sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\).*/\1/'`
--minor=`echo $ksba_config_version | \
-- sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\).*/\2/'`
--micro=`echo $ksba_config_version | \
-- sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\).*/\3/'`
--if test "$major" -gt "$req_major"; then
--ok=yes
--else
--if test "$major" -eq "$req_major"; then
--if test "$minor" -gt "$req_minor"; then
-- ok=yes
--else
-- if test "$minor" -eq "$req_minor"; then
-- if test "$micro" -ge "$req_micro"; then
-- ok=yes
-- fi
-- fi
--fi
--fi
--fi
-- fi
-- if test $ok = yes; then
--AC_MSG_RESULT([yes ($ksba_config_version)])
-- else
--AC_MSG_RESULT(no)
-- fi
-+ PKG_CHECK_MODULES(KSBA, [ksba >= $min_ksba_version], [ok=yes], [ok=no])
-+
- if test $ok = yes; then
- # Even if we have a recent libksba, we should check that the
- # API is
[OE-core] [PATCH] less: upgrade 551 -> 562
Signed-off-by: Wang Mingyu
---
meta/recipes-extended/less/{less_551.bb => less_562.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-extended/less/{less_551.bb => less_562.bb} (89%)
diff --git a/meta/recipes-extended/less/less_551.bb
b/meta/recipes-extended/less/less_562.bb
similarity index 89%
rename from meta/recipes-extended/less/less_551.bb
rename to meta/recipes-extended/less/less_562.bb
index a818c68fc7..c900574674 100644
--- a/meta/recipes-extended/less/less_551.bb
+++ b/meta/recipes-extended/less/less_562.bb
@@ -28,8 +28,8 @@ DEPENDS = "ncurses"
SRC_URI = "http://www.greenwoodsoftware.com/${BPN}/${BPN}-${PV}.tar.gz \
"
-SRC_URI[md5sum] = "4ad4408b06d7a6626a055cb453f36819"
-SRC_URI[sha256sum] =
"ff165275859381a63f19135a8f1f6c5a194d53ec3187f94121ecd8ef0795fe3d"
+SRC_URI[md5sum] = "0371a9678cb42f37b9bf9b86e8aa7903"
+SRC_URI[sha256sum] =
"eab470c7c928132441541aa49b1352c0fc699c30f762dfaeb3bf88e6f0fd701b"
UPSTREAM_CHECK_URI = "http://www.greenwoodsoftware.com/less/download.html;
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138791):
https://lists.openembedded.org/g/openembedded-core/message/138791
Mute This Topic: https://lists.openembedded.org/mt/74502262/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] ✗ patchtest: failure for remove unused DEPLOY_DIR_TOOLS variable from bitbake.conf
== Series Details == Series: remove unused DEPLOY_DIR_TOOLS variable from bitbake.conf Revision: 1 URL : https://patchwork.openembedded.org/series/24343/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on the proposed series by patchtest resulting in the following failures: * Patchremove unused DEPLOY_DIR_TOOLS variable from bitbake.conf Issue Shortlog does not follow expected format [test_shortlog_format] Suggested fixCommit shortlog (first line of commit message) should follow the format ": " If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core@lists.openembedded.org) raising your concerns. Otherwise we would appreciate you correcting the issues and submitting a new version of the patchset if applicable. Please ensure you add/increment the version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> [PATCH v3] -> ...). --- Guidelines: https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138790): https://lists.openembedded.org/g/openembedded-core/message/138790 Mute This Topic: https://lists.openembedded.org/mt/74501481/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/5 v2] multilib/recipes: Use new RecipePostKeyExpansion event
Hi Richard,
On Tue, May 26, 2020 at 10:57:21PM +0100, Richard Purdie wrote:
> There are issues with multilib due to the ordering of events where some
> functions see the remapped multilib dependencies and some do not. A
> significant
> problem is that the multilib class needs to make some changes before key
> expansion
> and some afterwards but by using existing event handlers, some code sees
> things
> in a partially translated state, leading to bugs.
>
> This patch changes things to use a new event handler from bitbake which makes
> the
> ordering of the changes explcit.
>
> The challenge in doing this is that it breaks some existing anonymous python
> and
> dyanmic assignments. In some cases these used to be translated and no longer
> are,
> meaning MLPREFIX has to be added. In some cases these are now translated and
> the
> MLPREFIX can be removed.
>
> This change does now make it very clear when MLPREFIX is required and when it
> is
> not, its just the migration path which is harder. The patch changes the small
> number
> of cases where fixes are needed.
>
> In particular, where a variable like RDEPENDS is conditionally extended (e.g.
> with an override), MLPREFIX is now required.
>
> This patch also reverts:
> base: Revert 'base.bbclass: considering multilib when setting
> LICENSE_EXCLUSION'
>
> This reverts 6597130256a1609c3e05ec5891aceaf549c37985 as the changes
> to multilib datastore handling mean its no longer necessary.
>
Is it possible to link the bugzilla entry in the commit log?
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13865
Otherwise, the main question is: do builds actually show warnings or
fail if MLPREFIX is forgotten in some places? I'm thinking about other
layers needing similar changes.
In either case, maybe a proper "note" in the migration steps for the
impacted release would be a good addition I think?
Some nitpicking/cosmetic review:
[...]
> -self.d.setVar(varname, bb.utils.join_deps(newdeps,
> False).replace("EXTENDPKGV", "${EXTENDPKGV}"))
> +if not varname.endswith("_NONML"):
> +#if varname == "DEPENDS":
Is it an actual comment or is it a leftover of some debugging session?
[...]
> diff --git a/meta/recipes-graphics/mesa/mesa.inc
> b/meta/recipes-graphics/mesa/mesa.inc
> index fede691d6ff..bb43a9a8b65 100644
> --- a/meta/recipes-graphics/mesa/mesa.inc
> +++ b/meta/recipes-graphics/mesa/mesa.inc
> @@ -212,18 +212,20 @@ python __anonymous() {
>("gles", "libgles3",)):
> if not p[0] in pkgconfig:
> continue
> -fullp = p[1] + "-mesa"
> -pkgs = " ".join(p[1:])
> +mlprefix = d.getVar("MLPREFIX")
> +fullp = mlprefix + p[1] + "-mesa"
> +mlprefix = d.getVar("MLPREFIX")
Duplicate mlprefix = d.getVar("MLPREFIX"). Any reason for that?
[...]
Thanks a bunch for the patches, I know it was painful.
Quentin
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138789):
https://lists.openembedded.org/g/openembedded-core/message/138789
Mute This Topic: https://lists.openembedded.org/mt/74488041/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] remove unused DEPLOY_DIR_TOOLS variable from bitbake.conf
On Wed, 27 May 2020, Robert P. J. Day wrote: > > Variable DEPLOY_DIR_TOOLS was introduced in 2007: > > commit f751a20152c651a33f08ceda0502fa1d4f11c005 > Author: Richard Purdie > Date: Wed Aug 8 21:02:39 2007 + > > bitbake.conf: Sync with OE.dev > never mind, failed to look in meta-openembedded layer, my bad. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138788): https://lists.openembedded.org/g/openembedded-core/message/138788 Mute This Topic: https://lists.openembedded.org/mt/74500775/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] remove unused DEPLOY_DIR_TOOLS variable from bitbake.conf
On 5/27/20 4:31 PM, Robert P. J. Day wrote:
Variable DEPLOY_DIR_TOOLS was introduced in 2007:
commit f751a20152c651a33f08ceda0502fa1d4f11c005
Author: Richard Purdie
Date: Wed Aug 8 21:02:39 2007 +
bitbake.conf: Sync with OE.dev
apparently never used so get rid of it.
Signed-off-by: Robert P. J. Day
meta-openembedded/meta-oe/recipes-support/dfu-util/dfu-util-native_0.9.bb:do_deploy[sstate-outputdirs]
= "${DEPLOY_DIR_TOOLS}"
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138787):
https://lists.openembedded.org/g/openembedded-core/message/138787
Mute This Topic: https://lists.openembedded.org/mt/74500775/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] Issue with qemu and a shared sstate-cache used by different linux distribution supported by yocto
Runqemu is running qemu binaries from a different location (that of qemu-helper-native sysroot), and on my machine, qemu in that location resolves libraries correctly. Can you try the same please? ak@linux-f9zs:~/development/poky> ldd build-st/tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/qemu-system-aarch64.real linux-vdso.so.1 (0x7ffcf73d9000) libvirglrenderer.so.1 => /home/ak/development/poky/build-st/tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/../lib/libvirglrenderer.so.1 (0x7fdb2efce000) libepoxy.so.0 => /home/ak/development/poky/build-st/tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/../lib/libepoxy.so.0 (0x7fdb2ee9a000) libgbm.so.1 => /home/ak/development/poky/build-st/tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/../lib/libgbm.so.1 (0x7fdb2ee89000) libasound.so.2 => /home/ak/development/poky/build-st/tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/../lib/libasound.so.2 (0x7fdb2ed93000) libSDL2-2.0.so.0 => /home/ak/development/poky/build-st/tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/../lib/libSDL2-2.0.so.0 (0x7fdb2ec5f000) libX11.so.6 => /home/ak/development/poky/build-st/tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/../lib/libX11.so.6 (0x7fdb2eb1f000) libgtk-3.so.0 => /home/ak/development/poky/build-st/tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/../lib/libgtk-3.so.0 (0x7fdb2e44) libgdk-3.so.0 => /home/ak/development/poky/build-st/tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/../lib/libgdk-3.so.0 (0x7fdb2e38c000) (etc, there is a lot of similar lines) Alex On Wed, 27 May 2020 at 15:59, vygu wrote: > For example: > > with the sstate-cache build on a debian, we have: > > $ ldd ../build/ > tmp/work/x86_64-linux/qemu-system-native/4.1.0-r0/sysroot-destdir/home/user/yocto/build/tmp/work/x86_64-linux/qemu-system-native/4.1.0-r0/recipe-sysroot-native/usr/bin/qemu-system-aarch64 > linux-vdso.so.1 (0x7ffe7dbc) > libseccomp.so.2 => /lib/x86_64-linux-gnu/libseccomp.so.2 > (0x7f533d18a000) > libbrlapi.so.0.6 => /lib/x86_64-linux-gnu/libbrlapi.so.0.6 > (0x7f533d17d000) > libvdeplug.so.2 => /lib/libvdeplug.so.2 (0x7f533d175000) > libasound.so.2 => /lib/x86_64-linux-gnu/libasound.so.2 > (0x7f533d074000) > libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f533ce56000) > libnfs.so.8 => /lib/x86_64-linux-gnu/libnfs.so.8 (0x7f533cc1d000) > librbd.so.1 => /lib/x86_64-linux-gnu/librbd.so.1 (0x7f533c8dc000) > librados.so.2 => /lib/x86_64-linux-gnu/librados.so.2 > (0x7f533c76c000) > libacl.so.1 => /lib/x86_64-linux-gnu/libacl.so.1 (0x7f533c761000) > libgfapi.so.0 => /lib/x86_64-linux-gnu/libgfapi.so.0 > (0x7f533c732000) > libglusterfs.so.0 => /lib/x86_64-linux-gnu/libglusterfs.so.0 > (0x7f533c624000) > libgfrpc.so.0 => /lib/x86_64-linux-gnu/libgfrpc.so.0 > (0x7f533c604000) > libgfxdr.so.0 => /lib/x86_64-linux-gnu/libgfxdr.so.0 > (0x7f533c5e4000) > libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f533c5db000) > libpixman-1.so.0 => /lib/x86_64-linux-gnu/libpixman-1.so.0 > (0x7f533c535000) > libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7f533c53) > libfdt.so.1 => /lib/x86_64-linux-gnu/libfdt.so.1 (0x7f533c524000) > libgthread-2.0.so.0 => /lib/x86_64-linux-gnu/libgthread-2.0.so.0 > (0x7f533c51d000) > libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 > (0x7f533c3fe000) > librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f533c3f4000) > libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 > (0x7f533c27) > libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f533c0ed000) > libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 > (0x7f533c0d3000) > libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 > (0x7f533c0b) > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f533beef000) > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f533beea000) > > /home/user/yocto/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2 > => /lib64/ld-linux-x86-64.so.2 (0x7f533e447000) > libceph-common.so.0 => > /usr/lib/x86_64-linux-gnu/ceph/libceph-common.so.0 (0x7f5333422000) > libboost_system.so.1.67.0 => > /lib/x86_64-linux-gnu/libboost_system.so.1.67.0 (0x7f533341b000) > libboost_thread.so.1.67.0 => > /lib/x86_64-linux-gnu/libboost_thread.so.1.67.0 (0x7f5ed000) > libattr.so.1 => /lib/x86_64-linux-gnu/libattr.so.1 (0x7f5e5000) > libtirpc.so.3
[OE-core] [PATCH] remove unused DEPLOY_DIR_TOOLS variable from bitbake.conf
Variable DEPLOY_DIR_TOOLS was introduced in 2007:
commit f751a20152c651a33f08ceda0502fa1d4f11c005
Author: Richard Purdie
Date: Wed Aug 8 21:02:39 2007 +
bitbake.conf: Sync with OE.dev
apparently never used so get rid of it.
Signed-off-by: Robert P. J. Day
---
if there's any actual use of this variable, i can't find it.
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index f7700f1191..9336c244bc 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -410,7 +410,6 @@ DEPLOY_DIR_IPK = "${DEPLOY_DIR}/ipk"
DEPLOY_DIR_RPM = "${DEPLOY_DIR}/rpm"
DEPLOY_DIR_DEB = "${DEPLOY_DIR}/deb"
DEPLOY_DIR_IMAGE ?= "${DEPLOY_DIR}/images/${MACHINE}"
-DEPLOY_DIR_TOOLS = "${DEPLOY_DIR}/tools"
PKGDATA_DIR = "${TMPDIR}/pkgdata/${MACHINE}"
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138785):
https://lists.openembedded.org/g/openembedded-core/message/138785
Mute This Topic: https://lists.openembedded.org/mt/74500775/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] Issue with qemu and a shared sstate-cache used by different linux distribution supported by yocto
For example: with the sstate-cache build on a debian, we have: $ ldd ../build/ tmp/work/x86_64-linux/qemu-system-native/4.1.0-r0/sysroot-destdir/home/user/yocto/build/tmp/work/x86_64-linux/qemu-system-native/4.1.0-r0/recipe-sysroot-native/usr/bin/qemu-system-aarch64 linux-vdso.so.1 (0x7ffe7dbc) libseccomp.so.2 => /lib/x86_64-linux-gnu/libseccomp.so.2 (0x7f533d18a000) libbrlapi.so.0.6 => /lib/x86_64-linux-gnu/libbrlapi.so.0.6 (0x7f533d17d000) libvdeplug.so.2 => /lib/libvdeplug.so.2 (0x7f533d175000) libasound.so.2 => /lib/x86_64-linux-gnu/libasound.so.2 (0x7f533d074000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f533ce56000) libnfs.so.8 => /lib/x86_64-linux-gnu/libnfs.so.8 (0x7f533cc1d000) librbd.so.1 => /lib/x86_64-linux-gnu/librbd.so.1 (0x7f533c8dc000) librados.so.2 => /lib/x86_64-linux-gnu/librados.so.2 (0x7f533c76c000) libacl.so.1 => /lib/x86_64-linux-gnu/libacl.so.1 (0x7f533c761000) libgfapi.so.0 => /lib/x86_64-linux-gnu/libgfapi.so.0 (0x7f533c732000) libglusterfs.so.0 => /lib/x86_64-linux-gnu/libglusterfs.so.0 (0x7f533c624000) libgfrpc.so.0 => /lib/x86_64-linux-gnu/libgfrpc.so.0 (0x7f533c604000) libgfxdr.so.0 => /lib/x86_64-linux-gnu/libgfxdr.so.0 (0x7f533c5e4000) libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f533c5db000) libpixman-1.so.0 => /lib/x86_64-linux-gnu/libpixman-1.so.0 (0x7f533c535000) libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7f533c53) libfdt.so.1 => /lib/x86_64-linux-gnu/libfdt.so.1 (0x7f533c524000) libgthread-2.0.so.0 => /lib/x86_64-linux-gnu/libgthread-2.0.so.0 (0x7f533c51d000) libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x7f533c3fe000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f533c3f4000) libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x7f533c27) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f533c0ed000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f533c0d3000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f533c0b) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f533beef000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f533beea000) /home/user/yocto/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x7f533e447000) libceph-common.so.0 => /usr/lib/x86_64-linux-gnu/ceph/libceph-common.so.0 (0x7f5333422000) libboost_system.so.1.67.0 => /lib/x86_64-linux-gnu/libboost_system.so.1.67.0 (0x7f533341b000) libboost_thread.so.1.67.0 => /lib/x86_64-linux-gnu/libboost_thread.so.1.67.0 (0x7f5ed000) libattr.so.1 => /lib/x86_64-linux-gnu/libattr.so.1 (0x7f5e5000) libtirpc.so.3 => /lib/x86_64-linux-gnu/libtirpc.so.3 (0x7f5b1000) libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x7f53330c8000) libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x7f5333054000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x7f5333038000) libboost_regex.so.1.67.0 => /lib/x86_64-linux-gnu/libboost_regex.so.1.67.0 (0x7f5332f23000) libboost_iostreams.so.1.67.0 => /lib/x86_64-linux-gnu/libboost_iostreams.so.1.67.0 (0x7f5332f05000) libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x7f5332eb) libsmime3.so => /lib/x86_64-linux-gnu/libsmime3.so (0x7f5332e81000) libnss3.so => /lib/x86_64-linux-gnu/libnss3.so (0x7f5332d33000) libnspr4.so => /lib/x86_64-linux-gnu/libnspr4.so (0x7f5332cf) libibverbs.so.1 => /lib/x86_64-linux-gnu/libibverbs.so.1 (0x7f5332cd5000) libboost_atomic.so.1.67.0 => /lib/x86_64-linux-gnu/libboost_atomic.so.1.67.0 (0x7f5332cd) libgssapi_krb5.so.2 => /lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x7f5332c83000) libkrb5.so.3 => /lib/x86_64-linux-gnu/libkrb5.so.3 (0x7f5332ba3000) libk5crypto.so.3 => /lib/x86_64-linux-gnu/libk5crypto.so.3 (0x7f5332b6d000) libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x7f5332b67000) libicudata.so.63 => /lib/x86_64-linux-gnu/libicudata.so.63 (0x7f5331177000) libicui18n.so.63 => /lib/x86_64-linux-gnu/libicui18n.so.63 (0x7f5330e9c000) libicuuc.so.63 => /lib/x86_64-linux-gnu/libicuuc.so.63 (0x7f5330ccd000) libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x7f5330cb8000) libnssutil3.so => /lib/x86_64-linux-gnu/libnssutil3.so (0x7f5330c86000) libplc4.so => /lib/x86_64-linux-gnu/libplc4.so (0x7f5330c7f000) libplds4.so => /lib/x86_64-linux-gnu/libplds4.so (0x7f5330c7a000)
Re: [OE-core] [PATCH] initramfs-framework/udev: remove mount.sh to avoid /run/media/XXX
Hi RP,
I do not directly remove udev-extraconf which provides mount.sh
from initramfs-framework, since it also has other hook scripts
for use (such as network.sh). So I choose to remove mount.sh
before start udev
//Hongxu
On 5/27/20 9:43 PM, hongxu wrote:
The udev invokes script hook mount.sh to mount /run/media/XXX. In
initramfs-framework, if udev was not killed in time, the partition
will be mounted to /run/media/XXX before switch_root.
Signed-off-by: Hongxu Jia
---
meta/recipes-core/initrdscripts/initramfs-framework/udev | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/recipes-core/initrdscripts/initramfs-framework/udev
b/meta/recipes-core/initrdscripts/initramfs-framework/udev
index 8b62080c68..3c4dd0ec9b 100644
--- a/meta/recipes-core/initrdscripts/initramfs-framework/udev
+++ b/meta/recipes-core/initrdscripts/initramfs-framework/udev
@@ -49,6 +49,9 @@ udev_run() {
# Workaround if console=null, systemd-udevd needs valid stdin, stdout
and stderr to work
sh -c "exec 4< /dev/console" || { exec 0> /dev/null; exec 1> /dev/null;
exec 2> /dev/null; }
+ # Avoid /run/media/XXX was mounted by udev
+ rm -f /etc/udev/scripts/mount.sh
+
$_UDEV_DAEMON --daemon
udevadm trigger --action=add
udevadm settle
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138783):
https://lists.openembedded.org/g/openembedded-core/message/138783
Mute This Topic: https://lists.openembedded.org/mt/74499756/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] Issue with qemu and a shared sstate-cache used by different linux distribution supported by yocto
libnfs for example ‐‐‐ Original Message ‐‐‐ On Wednesday 27 May 2020 14:43, Alexander Kanavin wrote: > Can you please provide the lib names which are problematic? > > Alex > > On Wed, 27 May 2020 at 14:29, vygu via lists.openembedded.org > wrote: > >> Hello, >> >> Since the zeus serie (also with dunfell), we observe an issue with runqemu >> when we share the sstate-cache thanks to a mirror between different linux >> distribution supported by yocto. >> >> If we build a sstate-cache on a debian 10 x86_64 buildfarm, and after that >> we use it on an ubuntu 18.04 x86_64, runqemu don't find several libs. >> We have reproduced this problem on two different pc with ubuntu 18.04 and >> 16.04. >> >> We don't have this problem, if we use the shared sstate-cache on another >> debian. >> >> In all cases, a ldd on the qemu binary shows us the use of local/host libs, >> not the yocto libs. >> >> Is it an expected behavior? or not? >> Runqemu's libs have to come from the linux distribution or from the yocto >> build env? >> >> Cordially, >> >> vygu-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138781): https://lists.openembedded.org/g/openembedded-core/message/138781 Mute This Topic: https://lists.openembedded.org/mt/74498490/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] llvm: upgrade 9.0.1 -> 10.0.0
Signed-off-by: Trevor Gamblin
---
meta/recipes-devtools/llvm/llvm_git.bb | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-devtools/llvm/llvm_git.bb
b/meta/recipes-devtools/llvm/llvm_git.bb
index d24ed761bf..787cc3adcf 100644
--- a/meta/recipes-devtools/llvm/llvm_git.bb
+++ b/meta/recipes-devtools/llvm/llvm_git.bb
@@ -19,9 +19,9 @@ inherit cmake pkgconfig
PROVIDES += "llvm${PV}"
-MAJOR_VERSION = "9"
+MAJOR_VERSION = "10"
MINOR_VERSION = "0"
-PATCH_VERSION = "1"
+PATCH_VERSION = "0"
PV = "${MAJOR_VERSION}.${MINOR_VERSION}.${PATCH_VERSION}"
@@ -29,7 +29,7 @@ LLVM_RELEASE = "${PV}"
LLVM_DIR = "llvm${LLVM_RELEASE}"
BRANCH = "release/${MAJOR_VERSION}.x"
-SRCREV = "c1a0a213378a458fbea1a5c77b315c7dce08fd05"
+SRCREV = "d32170dbd5b0d54436537b6b75beaf44324e0c28"
SRC_URI = "git://github.com/llvm/llvm-project.git;branch=${BRANCH} \
file://0006-llvm-TargetLibraryInfo-Undefine-libc-functions-if-th.patch;striplevel=2
\
file://0007-llvm-allow-env-override-of-exe-path.patch;striplevel=2 \
--
2.24.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138782):
https://lists.openembedded.org/g/openembedded-core/message/138782
Mute This Topic: https://lists.openembedded.org/mt/74499834/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] initramfs-framework/udev: remove mount.sh to avoid /run/media/XXX
The udev invokes script hook mount.sh to mount /run/media/XXX. In
initramfs-framework, if udev was not killed in time, the partition
will be mounted to /run/media/XXX before switch_root.
Signed-off-by: Hongxu Jia
---
meta/recipes-core/initrdscripts/initramfs-framework/udev | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/recipes-core/initrdscripts/initramfs-framework/udev
b/meta/recipes-core/initrdscripts/initramfs-framework/udev
index 8b62080c68..3c4dd0ec9b 100644
--- a/meta/recipes-core/initrdscripts/initramfs-framework/udev
+++ b/meta/recipes-core/initrdscripts/initramfs-framework/udev
@@ -49,6 +49,9 @@ udev_run() {
# Workaround if console=null, systemd-udevd needs valid stdin, stdout
and stderr to work
sh -c "exec 4< /dev/console" || { exec 0> /dev/null; exec 1> /dev/null;
exec 2> /dev/null; }
+ # Avoid /run/media/XXX was mounted by udev
+ rm -f /etc/udev/scripts/mount.sh
+
$_UDEV_DAEMON --daemon
udevadm trigger --action=add
udevadm settle
--
2.18.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138780):
https://lists.openembedded.org/g/openembedded-core/message/138780
Mute This Topic: https://lists.openembedded.org/mt/74499756/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] OpenEmbedded Happy Hour
Just a reminder this happens later "today". As always consult: https://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenEmbedded+Happy+Hour+May+27=20200527T21=%3A=1 for the local day and time. Philip On 5/15/20 11:56 AM, Philip Balister wrote: > I've made a wiki page to track these: > > https://www.openembedded.org/wiki/Happy_Hours > > Then next one is scheduled for 2100 UTC on May 27. This is late evening > for Europe and morning for New Zealand, so hopefully we see some > different faces. The meeting info is on the wiki page. > > There is no set agenda, so bring some projects to talk about with the > community. > > > Philip > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138779): https://lists.openembedded.org/g/openembedded-core/message/138779 Mute This Topic: https://lists.openembedded.org/mt/74230229/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] libexif: upgrade to 0.6.22, change source to GitHub
On 5/27/20 3:59 AM, Alexander Kanavin wrote:
Hardcoding the split version components isn't great (and breaks
automated updates), I have a patch queued that does this better:
Works for me.
Thanks!
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=akanavin/package-version-updates=314af89080317673cf91e24537b2e0d9b36747c2
Specifically:
def version_underscore(v):
return "_".join(v.split("."))
SRC_URI =
"https://github.com/libexif/libexif/releases/download/libexif-${@version_underscore("${PV}")}-release/libexif-${PV}.tar.xz
\
"
Alex
On Tue, 26 May 2020 at 23:13, Trevor Gamblin
mailto:trevor.gamb...@windriver.com>>
wrote:
Updated libexif to 0.6.22, but needed to change to GitHub as a source,
since SourceForge does not yet have 0.6.22 version. The new version
includes the fixes for the three patch files that have been removed,
as well as other severe CVEs.
CVE: CVE-2018-20030
CVE: CVE-2020-13114
CVE: CVE-2020-13113
CVE: CVE-2020-13112
CVE: CVE-2020-0093
CVE: CVE-2019-9278
CVE: CVE-2020-12767
CVE: CVE-2016-6328
CVE: CVE-2017-7544
Signed-off-by: Trevor Gamblin mailto:trevor.gamb...@windriver.com>>
---
.../libexif/libexif/CVE-2016-6328.patch | 64 --
.../libexif/libexif/CVE-2017-7544.patch | 40 --
.../libexif/libexif/CVE-2018-20030.patch | 115
--
.../recipes-support/libexif/libexif_0.6.21.bb
| 17 ---
.../recipes-support/libexif/libexif_0.6.22.bb
| 21
5 files changed, 21 insertions(+), 236 deletions(-)
delete mode 100644
meta/recipes-support/libexif/libexif/CVE-2016-6328.patch
delete mode 100644
meta/recipes-support/libexif/libexif/CVE-2017-7544.patch
delete mode 100644
meta/recipes-support/libexif/libexif/CVE-2018-20030.patch
delete mode 100644 meta/recipes-support/libexif/libexif_0.6.21.bb
create mode 100644 meta/recipes-support/libexif/libexif_0.6.22.bb
diff --git
a/meta/recipes-support/libexif/libexif/CVE-2016-6328.patch
b/meta/recipes-support/libexif/libexif/CVE-2016-6328.patch
deleted file mode 100644
index a6f307439b..00
--- a/meta/recipes-support/libexif/libexif/CVE-2016-6328.patch
+++ /dev/null
@@ -1,64 +0,0 @@
-CVE: CVE-2016-6328
-Upstream-Status: Backport
-Signed-off-by: Ross Burton mailto:ross.bur...@intel.com>>
-
-From 41bd04234b104312f54d25822f68738ba8d7133d Mon Sep 17 00:00:00
2001
-From: Marcus Meissner mailto:mar...@jet.franken.de>>
-Date: Tue, 25 Jul 2017 23:44:44 +0200
-Subject: [PATCH] fixes some (not all) buffer overreads during
decoding pentax
- makernote entries.
-
-This should fix:
-https://sourceforge.net/p/libexif/bugs/125/ CVE-2016-6328
- libexif/pentax/mnote-pentax-entry.c | 16 +---
- 1 file changed, 13 insertions(+), 3 deletions(-)
-
-diff --git a/libexif/pentax/mnote-pentax-entry.c
b/libexif/pentax/mnote-pentax-entry.c
-index d03d159..ea0429a 100644
a/libexif/pentax/mnote-pentax-entry.c
-+++ b/libexif/pentax/mnote-pentax-entry.c
-@@ -425,24 +425,34 @@ mnote_pentax_entry_get_value
(MnotePentaxEntry *entry,
- case EXIF_FORMAT_SHORT:
- {
- const unsigned char *data = entry->data;
-- size_t k, len = strlen(val);
-+ size_t k, len = strlen(val), sizeleft;
-+
-+ sizeleft = entry->size;
- for(k=0; kcomponents; k++) {
-+ if (sizeleft < 2)
-+ break;
- vs = exif_get_short (data,
entry->order);
- snprintf (val+len, maxlen-len, "%i
", vs);
- len = strlen(val);
- data += 2;
-+ sizeleft -= 2;
- }
- }
- break;
- case EXIF_FORMAT_LONG:
- {
- const unsigned char *data = entry->data;
-- size_t k, len = strlen(val);
-+ size_t k, len = strlen(val), sizeleft;
-+
-+ sizeleft = entry->size;
- for(k=0; kcomponents; k++) {
-+ if (sizeleft < 4)
-+ break;
- vl = exif_get_long (data,
entry->order);
- snprintf (val+len, maxlen-len,
"%li", (long int) vl);
- len = strlen(val);
-
Re: [OE-core] Issue with qemu and a shared sstate-cache used by different linux distribution supported by yocto
Can you please provide the lib names which are problematic? Alex On Wed, 27 May 2020 at 14:29, vygu via lists.openembedded.org wrote: > Hello, > > Since the zeus serie (also with dunfell), we observe an issue with runqemu > when we share the sstate-cache thanks to a mirror between different linux > distribution supported by yocto. > > If we build a sstate-cache on a debian 10 x86_64 buildfarm, and after > that we use it on an ubuntu 18.04 x86_64, runqemu don't find several libs. > > We have reproduced this problem on two different pc with ubuntu 18.04 and > 16.04. > > We don't have this problem, if we use the shared sstate-cache on another > debian. > > In all cases, a ldd on the qemu binary shows us the use of local/host > libs, not the yocto libs. > > Is it an expected behavior? or not? > Runqemu's libs have to come from the linux distribution or from the yocto > build env? > > Cordially, > > vygu > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138777): https://lists.openembedded.org/g/openembedded-core/message/138777 Mute This Topic: https://lists.openembedded.org/mt/74498490/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] Issue with qemu and a shared sstate-cache used by different linux distribution supported by yocto
Hello, Since the zeus serie (also with dunfell), we observe an issue with runqemu when we share the sstate-cache thanks to a mirror between different linux distribution supported by yocto. If we build a sstate-cache on a debian 10 x86_64 buildfarm, and after that we use it on an ubuntu 18.04 x86_64, runqemu don't find several libs. We have reproduced this problem on two different pc with ubuntu 18.04 and 16.04. We don't have this problem, if we use the shared sstate-cache on another debian. In all cases, a ldd on the qemu binary shows us the use of local/host libs, not the yocto libs. Is it an expected behavior? or not? Runqemu's libs have to come from the linux distribution or from the yocto build env? Cordially, vygu-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138776): https://lists.openembedded.org/g/openembedded-core/message/138776 Mute This Topic: https://lists.openembedded.org/mt/74498490/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] initramfs-framework/udev: umount /run/media/XXX
On 5/27/20 5:52 PM, Richard Purdie wrote: On Mon, 2020-05-25 at 11:06 +0800, hongxu wrote: In initramfs-framework, before swith_root rootfs, if udev have time to run (before being killed), it will invoke hook mount.sh (which is provided by udev-extraconf) to mount /run/media/XXX. Release the mounted disk after udev being killed. This feels like a workaround. Would we be better off not installing the mount scripts into the initramfs in the first place? Follow your suggestion, I just tested it to remove the script, and everything works well, I will remove it in V2 //Hongxu Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138775): https://lists.openembedded.org/g/openembedded-core/message/138775 Mute This Topic: https://lists.openembedded.org/mt/74450071/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] ✗ patchtest: failure for devtool: Add IPv6 deploy targets targets
== Series Details == Series: devtool: Add IPv6 deploy targets targets Revision: 1 URL : https://patchwork.openembedded.org/series/24338/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on the proposed series by patchtest resulting in the following failures: * Patchdevtool: Add IPv6 deploy targets targets Issue Patch is missing Signed-off-by [test_signed_off_by_presence] Suggested fixSign off the patch (either manually or with "git commit --amend -s") If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core@lists.openembedded.org) raising your concerns. Otherwise we would appreciate you correcting the issues and submitting a new version of the patchset if applicable. Please ensure you add/increment the version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> [PATCH v3] -> ...). --- Guidelines: https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138774): https://lists.openembedded.org/g/openembedded-core/message/138774 Mute This Topic: https://lists.openembedded.org/mt/74496682/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][zeus] bind: fix CVE-2020-8616/7
From: Lee Chee Yang
fix CVE-2020-8616 and CVE-2020-8617
Signed-off-by: Lee Chee Yang
---
.../bind/bind/CVE-2020-8616.patch | 206 +
.../bind/bind/CVE-2020-8617.patch | 29 +++
meta/recipes-connectivity/bind/bind_9.11.5-P4.bb | 2 +
3 files changed, 237 insertions(+)
create mode 100644 meta/recipes-connectivity/bind/bind/CVE-2020-8616.patch
create mode 100644 meta/recipes-connectivity/bind/bind/CVE-2020-8617.patch
diff --git a/meta/recipes-connectivity/bind/bind/CVE-2020-8616.patch
b/meta/recipes-connectivity/bind/bind/CVE-2020-8616.patch
new file mode 100644
index 000..8f00231
--- /dev/null
+++ b/meta/recipes-connectivity/bind/bind/CVE-2020-8616.patch
@@ -0,0 +1,206 @@
+Upstream-Status: Backport
[https://downloads.isc.org/isc/bind9/9.11.19/patches/CVE-2020-8616.patch]
+CVE: CVE-2020-8616
+Signed-off-by: Lee Chee Yang
+---
+diff --git a/lib/dns/adb.c b/lib/dns/adb.c
+index 058495f6a5..6b8a9537f0 100644
+--- a/lib/dns/adb.c
b/lib/dns/adb.c
+@@ -404,14 +404,13 @@ static void log_quota(dns_adbentry_t *entry, const char
*fmt, ...)
+ */
+ #define FIND_WANTEVENT(fn) (((fn)->options & DNS_ADBFIND_WANTEVENT) != 0)
+ #define FIND_WANTEMPTYEVENT(fn) (((fn)->options & DNS_ADBFIND_EMPTYEVENT) !=
0)
+-#define FIND_AVOIDFETCHES(fn) (((fn)->options & DNS_ADBFIND_AVOIDFETCHES) \
+- != 0)
+-#define FIND_STARTATZONE(fn)(((fn)->options & DNS_ADBFIND_STARTATZONE) \
+- != 0)
+-#define FIND_HINTOK(fn) (((fn)->options & DNS_ADBFIND_HINTOK) != 0)
+-#define FIND_GLUEOK(fn) (((fn)->options & DNS_ADBFIND_GLUEOK) != 0)
+-#define FIND_HAS_ADDRS(fn) (!ISC_LIST_EMPTY((fn)->list))
+-#define FIND_RETURNLAME(fn) (((fn)->options & DNS_ADBFIND_RETURNLAME) !=
0)
++#define FIND_AVOIDFETCHES(fn) (((fn)->options & DNS_ADBFIND_AVOIDFETCHES) !=
0)
++#define FIND_STARTATZONE(fn) (((fn)->options & DNS_ADBFIND_STARTATZONE) != 0)
++#define FIND_HINTOK(fn) (((fn)->options & DNS_ADBFIND_HINTOK)
!= 0)
++#define FIND_GLUEOK(fn) (((fn)->options & DNS_ADBFIND_GLUEOK)
!= 0)
++#define FIND_HAS_ADDRS(fn)(!ISC_LIST_EMPTY((fn)->list))
++#define FIND_RETURNLAME(fn) (((fn)->options & DNS_ADBFIND_RETURNLAME) != 0)
++#define FIND_NOFETCH(fn) (((fn)->options & DNS_ADBFIND_NOFETCH) != 0)
+
+ /*
+ * These are currently used on simple unsigned ints, so they are
+@@ -3155,21 +3154,26 @@ dns_adb_createfind2(dns_adb_t *adb, isc_task_t *task,
isc_taskaction_t action,
+* Listen to negative cache hints, and don't start
+* another query.
+*/
+- if (NCACHE_RESULT(result) || AUTH_NX(result))
++ if (NCACHE_RESULT(result) || AUTH_NX(result)) {
+ goto fetch;
++ }
+
+- if (!NAME_FETCH_V6(adbname))
++ if (!NAME_FETCH_V6(adbname)) {
+ wanted_fetches |= DNS_ADBFIND_INET6;
++ }
+ }
+
+ fetch:
+ if ((WANT_INET(wanted_addresses) && NAME_HAS_V4(adbname)) ||
+ (WANT_INET6(wanted_addresses) && NAME_HAS_V6(adbname)))
++ {
+ have_address = true;
+- else
++ } else {
+ have_address = false;
+- if (wanted_fetches != 0 &&
+- ! (FIND_AVOIDFETCHES(find) && have_address)) {
++ }
++ if (wanted_fetches != 0 && !(FIND_AVOIDFETCHES(find) && have_address) &&
++ !FIND_NOFETCH(find))
++ {
+ /*
+* We're missing at least one address family. Either the
+* caller hasn't instructed us to avoid fetches, or we don't
+@@ -3177,8 +3181,9 @@ dns_adb_createfind2(dns_adb_t *adb, isc_task_t *task,
isc_taskaction_t action,
+* be acceptable so we have to launch fetches.
+*/
+
+- if (FIND_STARTATZONE(find))
++ if (FIND_STARTATZONE(find)) {
+ start_at_zone = true;
++ }
+
+ /*
+* Start V4.
+diff --git a/lib/dns/include/dns/adb.h b/lib/dns/include/dns/adb.h
+index 63a13c4e41..edf6e54935 100644
+--- a/lib/dns/include/dns/adb.h
b/lib/dns/include/dns/adb.h
+@@ -207,6 +207,10 @@ struct dns_adbfind {
+ * lame for this query.
+ */
+ #define DNS_ADBFIND_OVERQUOTA 0x0400
++/*%
++ *Don't perform a fetch even if there are no address records available.
++ */
++#define DNS_ADBFIND_NOFETCH 0x0800
+
+ /*%
+ * The answers to queries come back as a list of these.
+diff --git a/lib/dns/resolver.c b/lib/dns/resolver.c
+index 7c44478a26..0a40859d08 100644
+--- a/lib/dns/resolver.c
b/lib/dns/resolver.c
+@@ -172,6 +172,14 @@
+ #define DEFAULT_MAX_QUERIES 75
+ #endif
+
++/*
++ * After NS_FAIL_LIMIT attempts to fetch a name server address,
++ * if the number of addresses in the NS RRset exceeds NS_RR_LIMIT,
++ * stop trying to fetch, in
Re: [OE-core] [PATCH] initramfs-framework/udev: umount /run/media/XXX
On Mon, 2020-05-25 at 11:06 +0800, hongxu wrote: > In initramfs-framework, before swith_root rootfs, if udev have time > to > run (before being killed), it will invoke hook mount.sh (which is > provided > by udev-extraconf) to mount /run/media/XXX. > > Release the mounted disk after udev being killed. This feels like a workaround. Would we be better off not installing the mount scripts into the initramfs in the first place? Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138772): https://lists.openembedded.org/g/openembedded-core/message/138772 Mute This Topic: https://lists.openembedded.org/mt/74450071/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] devtool: Add IPv6 deploy targets targets
From: Breno Leitao
Unfortunately devtool is not able to deploy (and undeploy) into IPv6
hosts.
This patch simply adds a way to use IPv6 target address similarly to
ssh/scp, as foo@[:::]:/destdir.
In order to do it, I've created a function that parses the hostname,
user and destdir, and then create a target_ssh (for ssh like parameter
-- foo@xxx:::zzz) and target_scp for scp paramers as
-- foo@[:::zzz]:/destdir. The urlparsing is done by urlparse
module and ip version discovery is done by ipaddress module.
This is the tests I have been using to validate my patch
IPV4_FORMATS="
root@11.11.11.2:/tmp
root@11.11.11.2
11.11.11.2:/tmp
11.11.11.2
"
IPV6_FORMATS="
root@[2620:10d:c0bb:403:dac4:97ff:feda:3325]:/tmp
root@[2620:10d:c0bb:403:dac4:97ff:feda:3325]
[2620:10d:c0bb:403:dac4:97ff:feda:3325]:/tmp
[2620:10d:c0bb:403:dac4:97ff:feda:3325]
"
HOSTNAMES="
r...@foo.bar:/tmp
r...@foo.bar
foo.bar:/tmp
foo.bar
"
for I in $IPV6_FORMATS
do
devtool deploy-target -6 -s mypkg ${I}
devtool undeploy-target -6 -s mypkg ${I}
done
for I in $HOSTNAMES
do
devtool deploy-target -s mypkg ${I}
devtool undeploy-target -s mypkg ${I}
done
for I in $IPV4_FORMATS
do
devtool deploy-target -s mypkg ${I}
devtool undeploy-target -s mypkg ${I}
done
---
scripts/lib/devtool/deploy.py | 61 +++
1 file changed, 47 insertions(+), 14 deletions(-)
diff --git a/scripts/lib/devtool/deploy.py b/scripts/lib/devtool/deploy.py
index 6a997735fc..1580256e2a 100644
--- a/scripts/lib/devtool/deploy.py
+++ b/scripts/lib/devtool/deploy.py
@@ -11,6 +11,8 @@ import os
import shutil
import subprocess
import tempfile
+import urllib
+import ipaddress
import bb.utils
import argparse_oe
@@ -134,6 +136,18 @@ def _prepare_remote_script(deploy, verbose=False,
dryrun=False, undeployall=Fals
return '\n'.join(lines)
+def parse_ip(args):
+t = urllib.parse.urlparse("ssh://" + args.target)
+
+try:
+ip = ipaddress.ip_address(t.hostname)
+version = ip.version
+except ValueError:
+# hostname instead of ip return version 0
+version = None;
+
+return t.username, t.hostname, t.path, version
+
def deploy(args, config, basepath, workspace):
"""Entry point for the devtool 'deploy' subcommand"""
@@ -143,14 +157,7 @@ def deploy(args, config, basepath, workspace):
check_workspace_recipe(workspace, args.recipename, checksrc=False)
-try:
-host, destdir = args.target.split(':')
-except ValueError:
-destdir = '/'
-else:
-args.target = host
-if not destdir.endswith('/'):
-destdir += '/'
+user, host, destdir, ipversion = parse_ip(args)
tinfoil = setup_tinfoil(basepath=basepath)
try:
@@ -235,16 +242,30 @@ def deploy(args, config, basepath, workspace):
f.write('%d\n' % ftotalsize)
for fpath, fsize in filelist:
f.write('%s %d\n' % (fpath, fsize))
+
+# Need to generate target as a scp format
+if ipversion == 6:
+target_scp = "[%s]:%s" % (host, os.path.dirname(tmpscript))
+else:
+target_scp = "%s:%s" % (host, os.path.dirname(tmpscript))
+if user:
+target_scp = "%s@%s" % (user, target_scp)
+
# Copy them to the target
-ret = subprocess.call("scp %s %s %s %s/* %s:%s" % (scp_sshexec,
scp_port, extraoptions, tmpdir, args.target, os.path.dirname(tmpscript)),
shell=True)
+ret = subprocess.call("scp %s %s %s %s/* %s" % (scp_sshexec,
scp_port, extraoptions, tmpdir, target_scp), shell=True)
if ret != 0:
raise DevtoolError('Failed to copy script to %s - rerun with
-s to '
'get a complete error message' % args.target)
finally:
shutil.rmtree(tmpdir)
+if user:
+target_ssh = "%s@%s" % (user, host)
+else:
+target_ssh = host
+
# Now run the script
-ret = exec_fakeroot(rd, 'tar cf - . | %s %s %s %s \'sh %s %s %s %s\''
% (ssh_sshexec, ssh_port, extraoptions, args.target, tmpscript,
args.recipename, destdir, tmpfilelist), cwd=recipe_outdir, shell=True)
+ret = exec_fakeroot(rd, 'tar cf - . | %s %s %s %s \'sh %s %s %s %s\''
% (ssh_sshexec, ssh_port, extraoptions, target_ssh, tmpscript, args.recipename,
destdir, tmpfilelist), cwd=recipe_outdir, shell=True)
if ret != 0:
raise DevtoolError('Deploy failed - rerun with -s to get a
complete '
'error message')
@@ -268,6 +289,8 @@ def undeploy(args, config, basepath, workspace):
elif not args.recipename and not args.all:
raise argparse_oe.ArgumentUsageError('If you don\'t specify a recipe,
you must specify -a/--all', 'undeploy-target')
+user, host,
Re: [OE-core] [PATCH 1/2] python3-pathtools: add a recipe
On Tue, 2020-05-26 at 01:12 -0400, Maxime Roussin-Bélanger wrote: > Signed-off-by: Maxime Roussin-Bélanger > --- > .../python/python3-pathtools_0.1.2.bb | 13 + > 1 file changed, 13 insertions(+) > create mode 100644 meta/recipes-devtools/python/python3-pathtools_0.1.2.bb Should these be in OE-Core or meta-python? Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138770): https://lists.openembedded.org/g/openembedded-core/message/138770 Mute This Topic: https://lists.openembedded.org/mt/74472477/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][dunfell 1/2] bind: fix CVE-2020-8616/7
From: Lee Chee Yang
fix CVE-2020-8616 and CVE-2020-8617
Signed-off-by: Lee Chee Yang
---
.../bind/bind/CVE-2020-8616.patch | 206 +
.../bind/bind/CVE-2020-8617.patch | 29 +++
meta/recipes-connectivity/bind/bind_9.11.13.bb | 2 +
3 files changed, 237 insertions(+)
create mode 100644 meta/recipes-connectivity/bind/bind/CVE-2020-8616.patch
create mode 100644 meta/recipes-connectivity/bind/bind/CVE-2020-8617.patch
diff --git a/meta/recipes-connectivity/bind/bind/CVE-2020-8616.patch
b/meta/recipes-connectivity/bind/bind/CVE-2020-8616.patch
new file mode 100644
index 000..8f00231
--- /dev/null
+++ b/meta/recipes-connectivity/bind/bind/CVE-2020-8616.patch
@@ -0,0 +1,206 @@
+Upstream-Status: Backport
[https://downloads.isc.org/isc/bind9/9.11.19/patches/CVE-2020-8616.patch]
+CVE: CVE-2020-8616
+Signed-off-by: Lee Chee Yang
+---
+diff --git a/lib/dns/adb.c b/lib/dns/adb.c
+index 058495f6a5..6b8a9537f0 100644
+--- a/lib/dns/adb.c
b/lib/dns/adb.c
+@@ -404,14 +404,13 @@ static void log_quota(dns_adbentry_t *entry, const char
*fmt, ...)
+ */
+ #define FIND_WANTEVENT(fn) (((fn)->options & DNS_ADBFIND_WANTEVENT) != 0)
+ #define FIND_WANTEMPTYEVENT(fn) (((fn)->options & DNS_ADBFIND_EMPTYEVENT) !=
0)
+-#define FIND_AVOIDFETCHES(fn) (((fn)->options & DNS_ADBFIND_AVOIDFETCHES) \
+- != 0)
+-#define FIND_STARTATZONE(fn)(((fn)->options & DNS_ADBFIND_STARTATZONE) \
+- != 0)
+-#define FIND_HINTOK(fn) (((fn)->options & DNS_ADBFIND_HINTOK) != 0)
+-#define FIND_GLUEOK(fn) (((fn)->options & DNS_ADBFIND_GLUEOK) != 0)
+-#define FIND_HAS_ADDRS(fn) (!ISC_LIST_EMPTY((fn)->list))
+-#define FIND_RETURNLAME(fn) (((fn)->options & DNS_ADBFIND_RETURNLAME) !=
0)
++#define FIND_AVOIDFETCHES(fn) (((fn)->options & DNS_ADBFIND_AVOIDFETCHES) !=
0)
++#define FIND_STARTATZONE(fn) (((fn)->options & DNS_ADBFIND_STARTATZONE) != 0)
++#define FIND_HINTOK(fn) (((fn)->options & DNS_ADBFIND_HINTOK)
!= 0)
++#define FIND_GLUEOK(fn) (((fn)->options & DNS_ADBFIND_GLUEOK)
!= 0)
++#define FIND_HAS_ADDRS(fn)(!ISC_LIST_EMPTY((fn)->list))
++#define FIND_RETURNLAME(fn) (((fn)->options & DNS_ADBFIND_RETURNLAME) != 0)
++#define FIND_NOFETCH(fn) (((fn)->options & DNS_ADBFIND_NOFETCH) != 0)
+
+ /*
+ * These are currently used on simple unsigned ints, so they are
+@@ -3155,21 +3154,26 @@ dns_adb_createfind2(dns_adb_t *adb, isc_task_t *task,
isc_taskaction_t action,
+* Listen to negative cache hints, and don't start
+* another query.
+*/
+- if (NCACHE_RESULT(result) || AUTH_NX(result))
++ if (NCACHE_RESULT(result) || AUTH_NX(result)) {
+ goto fetch;
++ }
+
+- if (!NAME_FETCH_V6(adbname))
++ if (!NAME_FETCH_V6(adbname)) {
+ wanted_fetches |= DNS_ADBFIND_INET6;
++ }
+ }
+
+ fetch:
+ if ((WANT_INET(wanted_addresses) && NAME_HAS_V4(adbname)) ||
+ (WANT_INET6(wanted_addresses) && NAME_HAS_V6(adbname)))
++ {
+ have_address = true;
+- else
++ } else {
+ have_address = false;
+- if (wanted_fetches != 0 &&
+- ! (FIND_AVOIDFETCHES(find) && have_address)) {
++ }
++ if (wanted_fetches != 0 && !(FIND_AVOIDFETCHES(find) && have_address) &&
++ !FIND_NOFETCH(find))
++ {
+ /*
+* We're missing at least one address family. Either the
+* caller hasn't instructed us to avoid fetches, or we don't
+@@ -3177,8 +3181,9 @@ dns_adb_createfind2(dns_adb_t *adb, isc_task_t *task,
isc_taskaction_t action,
+* be acceptable so we have to launch fetches.
+*/
+
+- if (FIND_STARTATZONE(find))
++ if (FIND_STARTATZONE(find)) {
+ start_at_zone = true;
++ }
+
+ /*
+* Start V4.
+diff --git a/lib/dns/include/dns/adb.h b/lib/dns/include/dns/adb.h
+index 63a13c4e41..edf6e54935 100644
+--- a/lib/dns/include/dns/adb.h
b/lib/dns/include/dns/adb.h
+@@ -207,6 +207,10 @@ struct dns_adbfind {
+ * lame for this query.
+ */
+ #define DNS_ADBFIND_OVERQUOTA 0x0400
++/*%
++ *Don't perform a fetch even if there are no address records available.
++ */
++#define DNS_ADBFIND_NOFETCH 0x0800
+
+ /*%
+ * The answers to queries come back as a list of these.
+diff --git a/lib/dns/resolver.c b/lib/dns/resolver.c
+index 7c44478a26..0a40859d08 100644
+--- a/lib/dns/resolver.c
b/lib/dns/resolver.c
+@@ -172,6 +172,14 @@
+ #define DEFAULT_MAX_QUERIES 75
+ #endif
+
++/*
++ * After NS_FAIL_LIMIT attempts to fetch a name server address,
++ * if the number of addresses in the NS RRset exceeds NS_RR_LIMIT,
++ * stop trying to fetch, in
[OE-core] [PATCH][dunfell 2/2] libexif: fix CVE-2020-13114
From: Lee Chee Yang
Signed-off-by: Lee Chee Yang
---
.../libexif/libexif/CVE-2020-13114.patch | 73 ++
meta/recipes-support/libexif/libexif_0.6.21.bb | 4 +-
2 files changed, 76 insertions(+), 1 deletion(-)
create mode 100644 meta/recipes-support/libexif/libexif/CVE-2020-13114.patch
diff --git a/meta/recipes-support/libexif/libexif/CVE-2020-13114.patch
b/meta/recipes-support/libexif/libexif/CVE-2020-13114.patch
new file mode 100644
index 000..06b8b46
--- /dev/null
+++ b/meta/recipes-support/libexif/libexif/CVE-2020-13114.patch
@@ -0,0 +1,73 @@
+From 47f51be021f4dfd800d4ff4630659887378baa3a Mon Sep 17 00:00:00 2001
+From: Dan Fandrich
+Date: Sat, 16 May 2020 19:32:30 +0200
+Subject: [PATCH] Add a failsafe on the maximum number of Canon MakerNote
+
+ subtags.
+
+A malicious file could be crafted to cause extremely large values in some
+tags without tripping any buffer range checks. This is bad with the libexif
+representation of Canon MakerNotes because some arrays are turned into
+individual tags that the application must loop around.
+
+The largest value I've seen for failsafe_size in a (very small) sample of valid
+Canon files is <5000. The limit is set two orders of magnitude larger to avoid
+tripping up falsely in case some models use much larger values.
+
+Patch from Google.
+
+CVE-2020-13114
+
+Upstream-Status: Backport
[https://github.com/libexif/libexif/commit/e6a38a1a23ba94d139b1fa2cd4519fdcfe3c9bab]
+CVE: CVE-2020-13114
+Signed-off-by: Lee Chee Yang
+---
+ libexif/canon/exif-mnote-data-canon.c | 21 +
+ 1 file changed, 21 insertions(+)
+
+diff --git a/libexif/canon/exif-mnote-data-canon.c
b/libexif/canon/exif-mnote-data-canon.c
+index eb53598..72fd7a3 100644
+--- a/libexif/canon/exif-mnote-data-canon.c
b/libexif/canon/exif-mnote-data-canon.c
+@@ -32,6 +32,9 @@
+
+ #define DEBUG
+
++/* Total size limit to prevent abuse by DoS */
++#define FAILSAFE_SIZE_MAX 100L
++
+ static void
+ exif_mnote_data_canon_clear (ExifMnoteDataCanon *n)
+ {
+@@ -202,6 +205,7 @@ exif_mnote_data_canon_load (ExifMnoteData *ne,
+ ExifMnoteDataCanon *n = (ExifMnoteDataCanon *) ne;
+ ExifShort c;
+ size_t i, tcount, o, datao;
++ long failsafe_size = 0;
+
+ if (!n || !buf || !buf_size) {
+ exif_log (ne->log, EXIF_LOG_CODE_CORRUPT_DATA,
+@@ -280,6 +284,23 @@ exif_mnote_data_canon_load (ExifMnoteData *ne,
+ memcpy (n->entries[tcount].data, buf + dataofs, s);
+ }
+
++ /* Track the size of decoded tag data. A malicious file could
++ * be crafted to cause extremely large values here without
++ * tripping any buffer range checks. This is especially bad
++ * with the libexif representation of Canon MakerNotes because
++ * some arrays are turned into individual tags that the
++ * application must loop around. */
++ failsafe_size +=
mnote_canon_entry_count_values(>entries[tcount]);
++
++ if (failsafe_size > FAILSAFE_SIZE_MAX) {
++ /* Abort if the total size of the data in the tags
extraordinarily large, */
++ exif_mem_free (ne->mem, n->entries[tcount].data);
++ exif_log (ne->log, EXIF_LOG_CODE_CORRUPT_DATA,
++"ExifMnoteCanon", "Failsafe tag size
overflow (%lu > %ld)",
++failsafe_size, FAILSAFE_SIZE_MAX);
++ break;
++ }
++
+ /* Tag was successfully parsed */
+ ++tcount;
+ }
diff --git a/meta/recipes-support/libexif/libexif_0.6.21.bb
b/meta/recipes-support/libexif/libexif_0.6.21.bb
index d847bea..3f6fa32 100644
--- a/meta/recipes-support/libexif/libexif_0.6.21.bb
+++ b/meta/recipes-support/libexif/libexif_0.6.21.bb
@@ -7,7 +7,9 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=243b725d71bb5df4a1e5920b344b86ad"
SRC_URI = "${SOURCEFORGE_MIRROR}/libexif/libexif-${PV}.tar.bz2 \
file://CVE-2017-7544.patch \
file://CVE-2016-6328.patch \
- file://CVE-2018-20030.patch"
+ file://CVE-2018-20030.patch \
+ file://CVE-2020-13114.patch \
+"
SRC_URI[md5sum] = "27339b89850f28c8f1c237f233e05b27"
SRC_URI[sha256sum] =
"16cdaeb62eb3e6dfab2435f7d7bccd2f37438d21c5218ec4e58efa9157d4d41a"
--
2.7.4
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138769):
https://lists.openembedded.org/g/openembedded-core/message/138769
Mute This Topic: https://lists.openembedded.org/mt/74496556/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] bind: fix CVE-2020-8616/7
From: Lee Chee Yang
fix CVE-2020-8616 and CVE-2020-8617
Signed-off-by: Lee Chee Yang
---
.../bind/bind/CVE-2020-8616.patch | 206 +
.../bind/bind/CVE-2020-8617.patch | 29 +++
meta/recipes-connectivity/bind/bind_9.11.13.bb | 2 +
3 files changed, 237 insertions(+)
create mode 100644 meta/recipes-connectivity/bind/bind/CVE-2020-8616.patch
create mode 100644 meta/recipes-connectivity/bind/bind/CVE-2020-8617.patch
diff --git a/meta/recipes-connectivity/bind/bind/CVE-2020-8616.patch
b/meta/recipes-connectivity/bind/bind/CVE-2020-8616.patch
new file mode 100644
index 000..8f00231
--- /dev/null
+++ b/meta/recipes-connectivity/bind/bind/CVE-2020-8616.patch
@@ -0,0 +1,206 @@
+Upstream-Status: Backport
[https://downloads.isc.org/isc/bind9/9.11.19/patches/CVE-2020-8616.patch]
+CVE: CVE-2020-8616
+Signed-off-by: Lee Chee Yang
+---
+diff --git a/lib/dns/adb.c b/lib/dns/adb.c
+index 058495f6a5..6b8a9537f0 100644
+--- a/lib/dns/adb.c
b/lib/dns/adb.c
+@@ -404,14 +404,13 @@ static void log_quota(dns_adbentry_t *entry, const char
*fmt, ...)
+ */
+ #define FIND_WANTEVENT(fn) (((fn)->options & DNS_ADBFIND_WANTEVENT) != 0)
+ #define FIND_WANTEMPTYEVENT(fn) (((fn)->options & DNS_ADBFIND_EMPTYEVENT) !=
0)
+-#define FIND_AVOIDFETCHES(fn) (((fn)->options & DNS_ADBFIND_AVOIDFETCHES) \
+- != 0)
+-#define FIND_STARTATZONE(fn)(((fn)->options & DNS_ADBFIND_STARTATZONE) \
+- != 0)
+-#define FIND_HINTOK(fn) (((fn)->options & DNS_ADBFIND_HINTOK) != 0)
+-#define FIND_GLUEOK(fn) (((fn)->options & DNS_ADBFIND_GLUEOK) != 0)
+-#define FIND_HAS_ADDRS(fn) (!ISC_LIST_EMPTY((fn)->list))
+-#define FIND_RETURNLAME(fn) (((fn)->options & DNS_ADBFIND_RETURNLAME) !=
0)
++#define FIND_AVOIDFETCHES(fn) (((fn)->options & DNS_ADBFIND_AVOIDFETCHES) !=
0)
++#define FIND_STARTATZONE(fn) (((fn)->options & DNS_ADBFIND_STARTATZONE) != 0)
++#define FIND_HINTOK(fn) (((fn)->options & DNS_ADBFIND_HINTOK)
!= 0)
++#define FIND_GLUEOK(fn) (((fn)->options & DNS_ADBFIND_GLUEOK)
!= 0)
++#define FIND_HAS_ADDRS(fn)(!ISC_LIST_EMPTY((fn)->list))
++#define FIND_RETURNLAME(fn) (((fn)->options & DNS_ADBFIND_RETURNLAME) != 0)
++#define FIND_NOFETCH(fn) (((fn)->options & DNS_ADBFIND_NOFETCH) != 0)
+
+ /*
+ * These are currently used on simple unsigned ints, so they are
+@@ -3155,21 +3154,26 @@ dns_adb_createfind2(dns_adb_t *adb, isc_task_t *task,
isc_taskaction_t action,
+* Listen to negative cache hints, and don't start
+* another query.
+*/
+- if (NCACHE_RESULT(result) || AUTH_NX(result))
++ if (NCACHE_RESULT(result) || AUTH_NX(result)) {
+ goto fetch;
++ }
+
+- if (!NAME_FETCH_V6(adbname))
++ if (!NAME_FETCH_V6(adbname)) {
+ wanted_fetches |= DNS_ADBFIND_INET6;
++ }
+ }
+
+ fetch:
+ if ((WANT_INET(wanted_addresses) && NAME_HAS_V4(adbname)) ||
+ (WANT_INET6(wanted_addresses) && NAME_HAS_V6(adbname)))
++ {
+ have_address = true;
+- else
++ } else {
+ have_address = false;
+- if (wanted_fetches != 0 &&
+- ! (FIND_AVOIDFETCHES(find) && have_address)) {
++ }
++ if (wanted_fetches != 0 && !(FIND_AVOIDFETCHES(find) && have_address) &&
++ !FIND_NOFETCH(find))
++ {
+ /*
+* We're missing at least one address family. Either the
+* caller hasn't instructed us to avoid fetches, or we don't
+@@ -3177,8 +3181,9 @@ dns_adb_createfind2(dns_adb_t *adb, isc_task_t *task,
isc_taskaction_t action,
+* be acceptable so we have to launch fetches.
+*/
+
+- if (FIND_STARTATZONE(find))
++ if (FIND_STARTATZONE(find)) {
+ start_at_zone = true;
++ }
+
+ /*
+* Start V4.
+diff --git a/lib/dns/include/dns/adb.h b/lib/dns/include/dns/adb.h
+index 63a13c4e41..edf6e54935 100644
+--- a/lib/dns/include/dns/adb.h
b/lib/dns/include/dns/adb.h
+@@ -207,6 +207,10 @@ struct dns_adbfind {
+ * lame for this query.
+ */
+ #define DNS_ADBFIND_OVERQUOTA 0x0400
++/*%
++ *Don't perform a fetch even if there are no address records available.
++ */
++#define DNS_ADBFIND_NOFETCH 0x0800
+
+ /*%
+ * The answers to queries come back as a list of these.
+diff --git a/lib/dns/resolver.c b/lib/dns/resolver.c
+index 7c44478a26..0a40859d08 100644
+--- a/lib/dns/resolver.c
b/lib/dns/resolver.c
+@@ -172,6 +172,14 @@
+ #define DEFAULT_MAX_QUERIES 75
+ #endif
+
++/*
++ * After NS_FAIL_LIMIT attempts to fetch a name server address,
++ * if the number of addresses in the NS RRset exceeds NS_RR_LIMIT,
++ * stop trying to fetch, in
[OE-core] [PATCH 1/2] re2c: fix CVE-2020-11958
From: Lee Chee Yang
Signed-off-by: Lee Chee Yang
---
.../recipes-support/re2c/re2c/CVE-2020-11958.patch | 41 ++
meta/recipes-support/re2c/re2c_1.3.bb | 4 ++-
2 files changed, 44 insertions(+), 1 deletion(-)
create mode 100644 meta/recipes-support/re2c/re2c/CVE-2020-11958.patch
diff --git a/meta/recipes-support/re2c/re2c/CVE-2020-11958.patch
b/meta/recipes-support/re2c/re2c/CVE-2020-11958.patch
new file mode 100644
index 000..43462e6
--- /dev/null
+++ b/meta/recipes-support/re2c/re2c/CVE-2020-11958.patch
@@ -0,0 +1,41 @@
+From c4603ba5ce229db83a2a4fb93e6d4b4e3ec3776a Mon Sep 17 00:00:00 2001
+From: Ulya Trofimovich
+Date: Fri, 17 Apr 2020 22:47:14 +0100
+Subject: [PATCH] Fix crash in lexer refill (reported by Agostino Sarubbo).
+
+The crash happened in a rare case of a very long lexeme that doen't fit
+into the buffer, forcing buffer reallocation.
+
+The crash was caused by an incorrect calculation of the shift offset
+(it was smaller than necessary). As a consequence, the data from buffer
+start and up to the beginning of the current lexeme was not discarded
+(as it should have been), resulting in less free space for new data than
+expected.
+
+Upstream-Status: Backport
[https://github.com/skvadrik/re2c/commit/c4603ba5ce229db83a2a4fb93e6d4b4e3ec3776a]
+CVE: CVE-2020-11958
+Signed-off-by: Lee Chee Yang
+---
+ src/parse/scanner.cc | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/src/parse/scanner.cc b/src/parse/scanner.cc
+index 1d6e9efa..bd651314 100644
+--- a/src/parse/scanner.cc
b/src/parse/scanner.cc
+@@ -155,13 +155,14 @@ bool Scanner::fill(size_t need)
+ if (!buf) fatal("out of memory");
+
+ memmove(buf, tok, copy);
+-shift_ptrs_and_fpos(buf - bot);
++shift_ptrs_and_fpos(buf - tok);
+ delete [] bot;
+ bot = buf;
+
+ free = BSIZE - copy;
+ }
+
++DASSERT(lim + free <= bot + BSIZE);
+ if (!read(free)) {
+ eof = lim;
+ memset(lim, 0, YYMAXFILL);
diff --git a/meta/recipes-support/re2c/re2c_1.3.bb
b/meta/recipes-support/re2c/re2c_1.3.bb
index 0e1d938..e9053ac 100644
--- a/meta/recipes-support/re2c/re2c_1.3.bb
+++ b/meta/recipes-support/re2c/re2c_1.3.bb
@@ -5,7 +5,9 @@ SECTION = "devel"
LICENSE = "PD"
LIC_FILES_CHKSUM = "file://LICENSE;md5=64eca4d8a3b67f9dc7656094731a2c8d"
-SRC_URI =
"https://github.com/skvadrik/re2c/releases/download/${PV}/${BPN}-${PV}.tar.xz;
+SRC_URI =
"https://github.com/skvadrik/re2c/releases/download/${PV}/${BPN}-${PV}.tar.xz \
+ file://CVE-2020-11958.patch \
+"
SRC_URI[sha256sum] =
"f37f25ff760e90088e7d03d1232002c2c2672646d5844fdf8e0d51a5cd75a503"
UPSTREAM_CHECK_URI = "https://github.com/skvadrik/re2c/releases;
--
2.7.4
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138766):
https://lists.openembedded.org/g/openembedded-core/message/138766
Mute This Topic: https://lists.openembedded.org/mt/74496157/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] libexif: upgrade to 0.6.22, change source to GitHub
Hardcoding the split version components isn't great (and breaks automated
updates), I have a patch queued that does this better:
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=akanavin/package-version-updates=314af89080317673cf91e24537b2e0d9b36747c2
Specifically:
def version_underscore(v):
return "_".join(v.split("."))
SRC_URI = "
https://github.com/libexif/libexif/releases/download/libexif-${@version_underscore("${PV}")}-release/libexif-${PV}.tar.xz
\
"
Alex
On Tue, 26 May 2020 at 23:13, Trevor Gamblin
wrote:
> Updated libexif to 0.6.22, but needed to change to GitHub as a source,
> since SourceForge does not yet have 0.6.22 version. The new version
> includes the fixes for the three patch files that have been removed,
> as well as other severe CVEs.
>
> CVE: CVE-2018-20030
> CVE: CVE-2020-13114
> CVE: CVE-2020-13113
> CVE: CVE-2020-13112
> CVE: CVE-2020-0093
> CVE: CVE-2019-9278
> CVE: CVE-2020-12767
> CVE: CVE-2016-6328
> CVE: CVE-2017-7544
>
> Signed-off-by: Trevor Gamblin
> ---
> .../libexif/libexif/CVE-2016-6328.patch | 64 --
> .../libexif/libexif/CVE-2017-7544.patch | 40 --
> .../libexif/libexif/CVE-2018-20030.patch | 115 --
> .../recipes-support/libexif/libexif_0.6.21.bb | 17 ---
> .../recipes-support/libexif/libexif_0.6.22.bb | 21
> 5 files changed, 21 insertions(+), 236 deletions(-)
> delete mode 100644
> meta/recipes-support/libexif/libexif/CVE-2016-6328.patch
> delete mode 100644
> meta/recipes-support/libexif/libexif/CVE-2017-7544.patch
> delete mode 100644
> meta/recipes-support/libexif/libexif/CVE-2018-20030.patch
> delete mode 100644 meta/recipes-support/libexif/libexif_0.6.21.bb
> create mode 100644 meta/recipes-support/libexif/libexif_0.6.22.bb
>
> diff --git a/meta/recipes-support/libexif/libexif/CVE-2016-6328.patch
> b/meta/recipes-support/libexif/libexif/CVE-2016-6328.patch
> deleted file mode 100644
> index a6f307439b..00
> --- a/meta/recipes-support/libexif/libexif/CVE-2016-6328.patch
> +++ /dev/null
> @@ -1,64 +0,0 @@
> -CVE: CVE-2016-6328
> -Upstream-Status: Backport
> -Signed-off-by: Ross Burton
> -
> -From 41bd04234b104312f54d25822f68738ba8d7133d Mon Sep 17 00:00:00 2001
> -From: Marcus Meissner
> -Date: Tue, 25 Jul 2017 23:44:44 +0200
> -Subject: [PATCH] fixes some (not all) buffer overreads during decoding
> pentax
> - makernote entries.
> -
> -This should fix:
> -https://sourceforge.net/p/libexif/bugs/125/ CVE-2016-6328
>
> - libexif/pentax/mnote-pentax-entry.c | 16 +---
> - 1 file changed, 13 insertions(+), 3 deletions(-)
> -
> -diff --git a/libexif/pentax/mnote-pentax-entry.c
> b/libexif/pentax/mnote-pentax-entry.c
> -index d03d159..ea0429a 100644
> a/libexif/pentax/mnote-pentax-entry.c
> -+++ b/libexif/pentax/mnote-pentax-entry.c
> -@@ -425,24 +425,34 @@ mnote_pentax_entry_get_value (MnotePentaxEntry
> *entry,
> - case EXIF_FORMAT_SHORT:
> - {
> - const unsigned char *data = entry->data;
> -- size_t k, len = strlen(val);
> -+ size_t k, len = strlen(val), sizeleft;
> -+
> -+ sizeleft = entry->size;
> - for(k=0; kcomponents; k++) {
> -+ if (sizeleft < 2)
> -+ break;
> - vs = exif_get_short (data, entry->order);
> - snprintf (val+len, maxlen-len, "%i ", vs);
> - len = strlen(val);
> - data += 2;
> -+ sizeleft -= 2;
> - }
> - }
> - break;
> - case EXIF_FORMAT_LONG:
> - {
> - const unsigned char *data = entry->data;
> -- size_t k, len = strlen(val);
> -+ size_t k, len = strlen(val), sizeleft;
> -+
> -+ sizeleft = entry->size;
> - for(k=0; kcomponents; k++) {
> -+ if (sizeleft < 4)
> -+ break;
> - vl = exif_get_long (data, entry->order);
> - snprintf (val+len, maxlen-len, "%li",
> (long int) vl);
> - len = strlen(val);
> - data += 4;
> -+ sizeleft -= 4;
> - }
> - }
> - break;
> -@@ -455,5 +465,5 @@ mnote_pentax_entry_get_value (MnotePentaxEntry *entry,
> - break;
> - }
> -
> -- return (val);
> -+ return val;
> - }
> diff --git a/meta/recipes-support/libexif/libexif/CVE-2017-7544.patch
> b/meta/recipes-support/libexif/libexif/CVE-2017-7544.patch
> deleted file mode 100644
> index e49481ff84..00
> ---
Re: [OE-core][PATCH] libubootenv: Remove the DEPENDS on mtd-utils
Hi Adrian,
On 27.05.20 08:24, Adrian Bunk wrote:
> It was only used for pulling in zlib, but this is now
> a direct dependency.
>
This is correct - I supposed when I started to implement the library to
link against mtd-utils, but this was not possible due to license's
incompatibility, and mtd-utils is not necessary at all.
> Also move the DEPENDS to a more common location in the file.
>
> Signed-off-by: Adrian Bunk
> ---
> meta/recipes-bsp/u-boot/libubootenv_0.2.bb | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
> b/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
> index fa90a12bf8..ea29b668e8 100644
> --- a/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
> +++ b/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
> @@ -1,5 +1,4 @@
> SUMMARY = "U-Boot libraries and tools to access environment"
> -DEPENDS += "mtd-utils zlib"
>
> DESCRIPTION = "This package contains tools and libraries to read \
> and modify U-Boot environment. \
> @@ -21,6 +20,7 @@ inherit cmake lib_package
>
> EXTRA_OECMAKE = "-DCMAKE_BUILD_TYPE=Release"
>
> +DEPENDS = "zlib"
> PROVIDES += "u-boot-fw-utils"
> RPROVIDES_${PN}-bin += "u-boot-fw-utils"
>
>
Acked-by: Stefano Babic
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138764):
https://lists.openembedded.org/g/openembedded-core/message/138764
Mute This Topic: https://lists.openembedded.org/mt/74494688/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [warrior] Backport 'prservice.py: fix do_package with newer Python in Ubuntu 20.04'
Hi, I just wanted to give people a headsup that I backported OE-Core rev: 4b26eaf7152fb712aba47a0c746333578f58ee8d onto warrior. The issue wasn't ubuntu 20.04 but that we were seeing the same issue on Fedora 30 and it wiped out the rc1 build. I'm trying an rc2 with that applied. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138763): https://lists.openembedded.org/g/openembedded-core/message/138763 Mute This Topic: https://lists.openembedded.org/mt/74494806/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] ✗ patchtest: failure for Add a new bbclass that abstracts the generation of FIT blobs (rev8)
On 2020-05-27 09:32, Patchwork wrote: == Series Details == Series: Add a new bbclass that abstracts the generation of FIT blobs (rev8) Revision: 8 URL : https://patchwork.openembedded.org/series/23431/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on the proposed series by patchtest resulting in the following failures: * Issue Errors in your Python code were encountered [test_pylint] Suggested fixCorrect the lines introduced by your patch Output Please, fix the listed issues: meta/lib/oeqa/selftest/cases/fit_image.py does not exist I don't know how to fix this issue. The file is part of the patchset: create mode 100644 meta/lib/oeqa/selftest/cases/fit_image.py Any suggestions If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core@lists.openembedded.org) raising your concerns. Otherwise we would appreciate you correcting the issues and submitting a new version of the patchset if applicable. Please ensure you add/increment the version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> [PATCH v3] -> ...). --- Guidelines: https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138762): https://lists.openembedded.org/g/openembedded-core/message/138762 Mute This Topic: https://lists.openembedded.org/mt/74494752/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] ✗ patchtest: failure for Add a new bbclass that abstracts the generation of FIT blobs (rev8)
== Series Details == Series: Add a new bbclass that abstracts the generation of FIT blobs (rev8) Revision: 8 URL : https://patchwork.openembedded.org/series/23431/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on the proposed series by patchtest resulting in the following failures: * Issue Errors in your Python code were encountered [test_pylint] Suggested fixCorrect the lines introduced by your patch Output Please, fix the listed issues: meta/lib/oeqa/selftest/cases/fit_image.py does not exist If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core@lists.openembedded.org) raising your concerns. Otherwise we would appreciate you correcting the issues and submitting a new version of the patchset if applicable. Please ensure you add/increment the version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> [PATCH v3] -> ...). --- Guidelines: https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138761): https://lists.openembedded.org/g/openembedded-core/message/138761 Mute This Topic: https://lists.openembedded.org/mt/74494752/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] libubootenv: Remove the DEPENDS on mtd-utils
It was only used for pulling in zlib, but this is now
a direct dependency.
Also move the DEPENDS to a more common location in the file.
Signed-off-by: Adrian Bunk
---
meta/recipes-bsp/u-boot/libubootenv_0.2.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
b/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
index fa90a12bf8..ea29b668e8 100644
--- a/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
+++ b/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
@@ -1,5 +1,4 @@
SUMMARY = "U-Boot libraries and tools to access environment"
-DEPENDS += "mtd-utils zlib"
DESCRIPTION = "This package contains tools and libraries to read \
and modify U-Boot environment. \
@@ -21,6 +20,7 @@ inherit cmake lib_package
EXTRA_OECMAKE = "-DCMAKE_BUILD_TYPE=Release"
+DEPENDS = "zlib"
PROVIDES += "u-boot-fw-utils"
RPROVIDES_${PN}-bin += "u-boot-fw-utils"
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138760):
https://lists.openembedded.org/g/openembedded-core/message/138760
Mute This Topic: https://lists.openembedded.org/mt/74494688/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] libubootenv: Remove the DEPENDS on mtd-utils
It was only used for pulling in zlib, but this is now
a direct dependency.
Also move the DEPENDS to a more common location in the file.
Signed-off-by: Adrian Bunk
---
meta/recipes-bsp/u-boot/libubootenv_0.2.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
b/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
index fa90a12bf8..ea29b668e8 100644
--- a/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
+++ b/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
@@ -1,5 +1,4 @@
SUMMARY = "U-Boot libraries and tools to access environment"
-DEPENDS += "mtd-utils zlib"
DESCRIPTION = "This package contains tools and libraries to read \
and modify U-Boot environment. \
@@ -21,6 +20,7 @@ inherit cmake lib_package
EXTRA_OECMAKE = "-DCMAKE_BUILD_TYPE=Release"
+DEPENDS = "zlib"
PROVIDES += "u-boot-fw-utils"
RPROVIDES_${PN}-bin += "u-boot-fw-utils"
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138759):
https://lists.openembedded.org/g/openembedded-core/message/138759
Mute This Topic: https://lists.openembedded.org/mt/74494688/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 v7 0/3] Add a new bbclass that abstracts the generation of FIT blobs
Description
--
Add a new class and unittest for generating FIT blobs.
Testing
---
1. linux-yocto_5.4.bbappend was modified to have the following
configuration:
```
inherit fit-image
KERNEL_IMAGE_NODE[name] = "kernel"
KERNEL_IMAGE_NODE[description] = "${PF}"
KERNEL_IMAGE_NODE[data] = '/incbin/("./arch/${ARCH}/boot/zImage")'
KERNEL_IMAGE_NODE[type] = "kernel"
KERNEL_IMAGE_NODE[arch] = "${ARCH}"
KERNEL_IMAGE_NODE[os] = "linux"
KERNEL_IMAGE_NODE[compression] = "none"
KERNEL_IMAGE_NODE[load] = "${UBOOT_LOADADDRESS}"
KERNEL_IMAGE_NODE[entry] = "${UBOOT_ENTRYPOINT}"
KERNEL_IMAGE_NODE[hash] = "sha256"
FDT_IMAGE_NODE[name] = "fdt"
FDT_IMAGE_NODE[description] = "FDT blob"
FDT_IMAGE_NODE[data] = '/incbin/("./arch/${ARCH}/boot/dts/am335x-bone.dtb")'
FDT_IMAGE_NODE[type] = "flat_dt"
FDT_IMAGE_NODE[arch] = "${ARCH}"
FDT_IMAGE_NODE[compression] = "none"
FDT_IMAGE_NODE[hash] = "sha256"
CONF1_CONF_NODE[name] = "conf"
CONF1_CONF_NODE[description] = "Linux kernel and FDT blob"
CONF1_CONF_NODE[kernel] = "kernel"
CONF1_CONF_NODE[fdt] = "fdt"
FIT_IMAGES_NODE = "KERNEL_IMAGE_NODE FDT_IMAGE_NODE"
FIT_CONFIGURATIONS_NODE = "CONF1_CONF_NODE"
FIT_CONFIGURATIONS_NODE[default] = "${@d.getVarFlag('CONF1_CONF_NODE',
'name') or ""}"
```
2. Build the kernel: `bitbake virtual/kernel`
3. Verify that `image-fit.itb` is present in the build directory: PASS
4. Disassemble the image using the command: `dtc -I dtb -O dts
image-fit.itb`
5. Verify that the FIT source contains the expected configuration: PASS
6. Run the unittest using the command: `oe-selftest --run-tests
fit_image.FitImage`
7. Verify that is successfully: PASS
```
2020-05-26 16:54:34,996 - oe-selftest - INFO - SUMMARY:
2020-05-26 16:54:34,996 - oe-selftest - INFO - oe-selftest () - Ran 13
tests in 1956.639s
2020-05-26 16:54:34,997 - oe-selftest - INFO - oe-selftest - OK - All
required tests passed (successes=13, skipped=0, failures=0, errors=0)
```
Changes since v1:
- Change the format of short-log to ": "
Changes since v2:
- rename the file from `fit-image` to `fit_image` to successfully export
the class functions.
- adding new sanity checks.
- add missing dependency.
- fix a variable reference in a debug log.
Changes since v3:
- unit-test added
- class updated to support also properties for U-Boot image
Changes since v4:
- remove a wrong patch
Changes since v5:
- something went wrong with generation of the patches. regenerate
Changes since v6:
- fix the shortlog for one of the patches
Nandor Han (3):
python-fdt: add a recipe for `python3-fdt` package
classes: Add a new bbclass that abstracts the generation of FIT blobs
selftest: add a unit-test for fit-image bbclass
.../fit-image-test/files/dt-fake.dtb | 3 +
.../fit-image-test/files/zImage-fake | 3 +
.../fit-image-test/fit-image-test.bb | 17 +
meta/classes/fit_image.bbclass| 387 ++
meta/lib/oeqa/selftest/cases/fit_image.py | 212 ++
.../python/python3-fdt_0.2.0.bb | 14 +
6 files changed, 636 insertions(+)
create mode 100644 meta-selftest/recipes-test/fit-image-test/files/dt-fake.dtb
create mode 100644 meta-selftest/recipes-test/fit-image-test/files/zImage-fake
create mode 100644 meta-selftest/recipes-test/fit-image-test/fit-image-test.bb
create mode 100644 meta/classes/fit_image.bbclass
create mode 100644 meta/lib/oeqa/selftest/cases/fit_image.py
create mode 100644 meta/recipes-devtools/python/python3-fdt_0.2.0.bb
--
2.24.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138755):
https://lists.openembedded.org/g/openembedded-core/message/138755
Mute This Topic: https://lists.openembedded.org/mt/74494471/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 v7 3/3] selftest: add a unit-test for fit-image bbclass
The unit-test will test the basic functionality of `fit-image.bbclass`.
Signed-off-by: Nandor Han
---
.../fit-image-test/files/dt-fake.dtb | 3 +
.../fit-image-test/files/zImage-fake | 3 +
.../fit-image-test/fit-image-test.bb | 17 ++
meta/lib/oeqa/selftest/cases/fit_image.py | 212 ++
4 files changed, 235 insertions(+)
create mode 100644 meta-selftest/recipes-test/fit-image-test/files/dt-fake.dtb
create mode 100644 meta-selftest/recipes-test/fit-image-test/files/zImage-fake
create mode 100644 meta-selftest/recipes-test/fit-image-test/fit-image-test.bb
create mode 100644 meta/lib/oeqa/selftest/cases/fit_image.py
diff --git a/meta-selftest/recipes-test/fit-image-test/files/dt-fake.dtb
b/meta-selftest/recipes-test/fit-image-test/files/dt-fake.dtb
new file mode 100644
index 00..7fa871ff00
--- /dev/null
+++ b/meta-selftest/recipes-test/fit-image-test/files/dt-fake.dtb
@@ -0,0 +1,3 @@
+Z�P�acn�ZWD1\� !΄�l�V
+t(��H����z��jb4.���݁�W;I�ƶb�e���Ñ�5�x� &�9,��g
+�;���!cV
diff --git a/meta-selftest/recipes-test/fit-image-test/files/zImage-fake
b/meta-selftest/recipes-test/fit-image-test/files/zImage-fake
new file mode 100644
index 00..7fa871ff00
--- /dev/null
+++ b/meta-selftest/recipes-test/fit-image-test/files/zImage-fake
@@ -0,0 +1,3 @@
+Z�P�acn�ZWD1\� !΄�l�V
+t(��H����z��jb4.���݁�W;I�ƶb�e���Ñ�5�x� &�9,��g
+�;���!cV
diff --git a/meta-selftest/recipes-test/fit-image-test/fit-image-test.bb
b/meta-selftest/recipes-test/fit-image-test/fit-image-test.bb
new file mode 100644
index 00..c7f325ec8a
--- /dev/null
+++ b/meta-selftest/recipes-test/fit-image-test/fit-image-test.bb
@@ -0,0 +1,17 @@
+SUMMARY = "Recipe for testing the fit_image bbclass"
+LICENSE = "MIT"
+LIC_FILES_CHKSUM =
"file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
+
+DEPENDS += "\
+python3-fdt-native \
+"
+
+SRC_URI = "\
+file://zImage-fake \
+file://dt-fake.dtb \
+"
+
+inherit fit_image
+
+include test_recipe.inc
+
diff --git a/meta/lib/oeqa/selftest/cases/fit_image.py
b/meta/lib/oeqa/selftest/cases/fit_image.py
new file mode 100644
index 00..866e48b20e
--- /dev/null
+++ b/meta/lib/oeqa/selftest/cases/fit_image.py
@@ -0,0 +1,212 @@
+import os
+from oeqa.selftest.case import OESelftestTestCase
+from oeqa.utils.commands import get_bb_var, bitbake, get_bb_vars
+
+class FitImage(OESelftestTestCase):
+
+@classmethod
+def setUpClass(cls):
+super(FitImage, cls).setUpClass()
+cls.recipe_name = 'fit-image-test'
+cls.build_dir = get_bb_var('B', cls.recipe_name)
+cls.fit_blob_path = os.path.join(cls.build_dir, 'image-fit.itb')
+
+bitbake('python3-fdt-native')
+fdt_sitepackage=get_bb_var("S", "python3-fdt-native")
+os.sys.path.append(fdt_sitepackage)
+import fdt
+
+bitbake('{recipe_name} -c
cleanall'.format(recipe_name=cls.recipe_name))
+
+@classmethod
+def tearDownClass(cls):
+bitbake('{recipe_name} -c
cleanall'.format(recipe_name=cls.recipe_name))
+super(FitImage, cls).tearDownClass()
+
+def _get_fit_configuration(self):
+configuration = """
+KERNEL_IMAGE_NODE[name] = "kernel"
+KERNEL_IMAGE_NODE[description] = "${PF}"
+KERNEL_IMAGE_NODE[data] = '/incbin/("${WORKDIR}/zImage-fake")'
+KERNEL_IMAGE_NODE[type] = "kernel"
+KERNEL_IMAGE_NODE[arch] = "arm"
+KERNEL_IMAGE_NODE[os] = "linux"
+KERNEL_IMAGE_NODE[compression] = "none"
+KERNEL_IMAGE_NODE[load] = "0x8400"
+KERNEL_IMAGE_NODE[entry] = "0x8400"
+KERNEL_IMAGE_NODE[hash] = "sha256"
+
+FDT_IMAGE_NODE[name] = "fdt"
+FDT_IMAGE_NODE[description] = "FDT blob"
+FDT_IMAGE_NODE[data] = '/incbin/("${WORKDIR}/dt-fake.dtb")'
+FDT_IMAGE_NODE[type] = "flat_dt"
+FDT_IMAGE_NODE[arch] = "arm"
+FDT_IMAGE_NODE[compression] = "none"
+FDT_IMAGE_NODE[hash] = "sha256"
+
+CONF1_CONF_NODE[name] = "conf"
+CONF1_CONF_NODE[description] = "Linux kernel and FDT blob"
+CONF1_CONF_NODE[kernel] = "kernel"
+CONF1_CONF_NODE[fdt] = "fdt"
+
+FIT_IMAGES_NODE = "KERNEL_IMAGE_NODE FDT_IMAGE_NODE"
+FIT_CONFIGURATIONS_NODE = "CONF1_CONF_NODE"
+FIT_CONFIGURATIONS_NODE[default] = "${@d.getVarFlag('CONF1_CONF_NODE', 'name')
or ""}"
+"""
+return configuration
+
+def setUp(self):
+super(FitImage, self).setUp()
+self.write_recipeinc(self.recipe_name, self._get_fit_configuration())
+
+def tearDown(self):
+self.delete_recipeinc(self.recipe_name)
+super(FitImage, self).tearDown()
+
+def test_fit_source_is_generated_correctly(self):
+ret = bitbake("{recipe} -D -f -c
generate_fit_image".format(recipe=self.recipe_name)).output
+self.logger.info('HN {log}'.format(log=ret))
+
+def test_fit_blob_is_generated_successfully(self):
+"""
+Summary: Able to apply a single patch to the Linux kernel source
+Expected:The README file should exist and the patch changes should
be
+
[OE-core][PATCH v7 1/3] python-fdt: add a recipe for `python3-fdt` package
The package `python3-fdt` is used for parsing and generating DTBs. Signed-off-by: Nandor Han --- meta/recipes-devtools/python/python3-fdt_0.2.0.bb | 14 ++ 1 file changed, 14 insertions(+) create mode 100644 meta/recipes-devtools/python/python3-fdt_0.2.0.bb diff --git a/meta/recipes-devtools/python/python3-fdt_0.2.0.bb b/meta/recipes-devtools/python/python3-fdt_0.2.0.bb new file mode 100644 index 00..040ceba980 --- /dev/null +++ b/meta/recipes-devtools/python/python3-fdt_0.2.0.bb @@ -0,0 +1,14 @@ +SUMMARY = "Library for manipulation of Device Tree Data" +HOMEPAGE = "https://github.com/molejar/pyFDT; +SECTION = "devel/python" +LICENSE = "Apache-2.0" +LIC_FILES_CHKSUM = "file://PKG-INFO;beginline=8;endline=8;md5=9a6ea5b6c346a830f54cc95f6a2a9245" + +SRC_URI[md5sum] = "a91daa36b3216f54feeac74ea8e5a475" +SRC_URI[sha256sum] = "b675139346946115513e27b5eed9aa882628ab74ed500bd5e25e122ee0afa2f6" + +PYPI_PACKAGE = "fdt" + +inherit pypi setuptools3 + +BBCLASSEXTEND = "native" -- 2.24.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138756): https://lists.openembedded.org/g/openembedded-core/message/138756 Mute This Topic: https://lists.openembedded.org/mt/74494473/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 v7 2/3] classes: Add a new bbclass that abstracts the generation of FIT blobs
FIT format is very versatile allowing various combination of booting
sequences. In the same time different U-Boot boot stages can use FIT
blobs to pack various binaries (e.g. SPL supports reading U-Boot from a
FIT blob). Because of the allowed level of customization, the generation
of a FIT blob using a fixed image tree source, becomes challenging and
increase the level of complexity where different configurations and
combinations are needed.
This bbclass will know how to generate a FIT blob, leaving the mechanics
of the process (dependencies, task order...) to be handled by the users
of the bbclass. In the same time will allow to separate the knowledge of
the FIT format leaving the user code cleaner and more readable.
Signed-off-by: Nandor Han
---
meta/classes/fit_image.bbclass | 387 +
1 file changed, 387 insertions(+)
create mode 100644 meta/classes/fit_image.bbclass
diff --git a/meta/classes/fit_image.bbclass b/meta/classes/fit_image.bbclass
new file mode 100644
index 00..2d1451020c
--- /dev/null
+++ b/meta/classes/fit_image.bbclass
@@ -0,0 +1,387 @@
+#
+# The class will facilitate the generation of FIT blobs.
+#
+# Glossary
+#FIT - Flattened uImage Tree
+#
+# Requirements:
+#
+#* The user need to specify the image content using the format specified
in the "FIT Image API" section.
+#
+# FIT Image API
+#
+# The bbclass is using variable and variable flags to declare the FIT image
content.
+#
+#* Sub-Images and Configuration Nodes
+#
+# ** A sub-image node content is declared using the format
`VAR_NODE[] = `.
+# * VAR_NODE - freely selected name of the variable representing a
node.
+# * - a sub-image property (e.g. description, type...).
+# * - the property value.
+# Depending of the property the value can support different
formats.
+# ** Property Values Formats
+#
+#string property
+#---
+#format: "" - in case the property expects a text.
+#(e.g. IMAGE_NODE_KERNEL[type] = "kernel")
+#
+#address property
+#
+#format: "" - in case the property expects an address.
+#(e.g. IMAGE_NODE_KERNEL[entry] = "0xABCDABCD")
+#
+#hash property
+#-
+#format: "" - for hash property the hash type needs to
be specified.
+#(e.g. IMAGE_NODE_KERNEL[hash] = "sha256")
+#
+#sub-image signature property
+#
+#format: ";;" - for image signature node.
+#Both algorithm and key name needs to be provided.
+#(e.g. IMAGE_NODE_KERNEL[signature] = "sha256,rsa2048;kernel;"
+#
+#configuration signature property
+#
+#format: ";;" - for
configuration signature properties algorithm,
+#key name and sub-image nodes needs to be provided.
+#(e.g. CONF_NODE_CONF1[signature] =
"sha256,rsa2048;kernel;"kernel","fdt";")
+#
+# ** Sub-Image and Configuration Nodes Flags
+# See the code for supported flags.
+#
+#* FIT_IMAGES_NODE - contains a list of variables used to declare the
sub-images nodes, separated by space.
+#(e.g. FIT_IMAGES_NODE = "IMAGE_NODE_KERNEL
IMAGE_NODE_FDT")
+#
+#* FIT_CONFIGURATIONS_NODE - contains a list of variables used to declare
the configuration nodes,
+# separated by space. (e.g. FIT_CONFIGURATIONS_NODE =
"CONF_NODE_CONF1")
+#** Flags
+# - "default": used to configure the default configuration node.
+# (e.g. FIT_CONFIGURATIONS_NODE[default] = "conf@0")
+#
+# Example:
+# This is part of a linux_%.bbappend recipe.
+#
+# KERNEL_IMAGE_NODE[name] = "kernel"
+# KERNEL_IMAGE_NODE[description] = "${PF}"
+# KERNEL_IMAGE_NODE[data] = '/incbin/("./arch/${ARCH}/boot/zImage")'
+# KERNEL_IMAGE_NODE[type] = "kernel"
+# KERNEL_IMAGE_NODE[arch] = "${ARCH}"
+# KERNEL_IMAGE_NODE[os] = "linux"
+# KERNEL_IMAGE_NODE[compression] = "none"
+# KERNEL_IMAGE_NODE[load] = "${UBOOT_LOADADDRESS}"
+# KERNEL_IMAGE_NODE[entry] = "${UBOOT_ENTRYPOINT}"
+# KERNEL_IMAGE_NODE[hash] = "sha256"
+#
+# FDT_IMAGE_NODE[name] = "fdt"
+# FDT_IMAGE_NODE[description] = "FDT blob"
+# FDT_IMAGE_NODE[data] = '/incbin/("./arch/${ARCH}/boot/dts/am335x-bone.dtb")'
+# FDT_IMAGE_NODE[type] = "flat_dt"
+# FDT_IMAGE_NODE[arch] = "${ARCH}"
+# FDT_IMAGE_NODE[compression] = "none"
+# FDT_IMAGE_NODE[hash] = "sha256"
+#
+# CONF1_CONF_NODE[name] = "conf"
+# CONF1_CONF_NODE[description] = "Linux kernel and FDT blob"
+# CONF1_CONF_NODE[kernel] = "kernel"
+# CONF1_CONF_NODE[fdt] = "fdt"
+#
+# FIT_IMAGES_NODE = "KERNEL_IMAGE_NODE FDT_IMAGE_NODE"
+# FIT_CONFIGURATIONS_NODE = "CONF1_CONF_NODE"
+# FIT_CONFIGURATIONS_NODE[default] = "${@d.getVarFlag('CONF1_CONF_NODE',
'name') or ""}"
+#
+
+DEPENDS += "\
