Re: [OE-core] [PATCH] linux-firmware: Fix packaging

On 16.03.2021 21:24, Michael Trensch wrote: >> Actually it doesn't apply to dunfell either (dunfell and master are >> both at version 20210208) >> >> So best to submit for master and I will cherry-pick to dunfell. >> >> Thanks for fixing this! >> >> Steve > > I think it broke somehow when

Re: [oe-core][PATCH 2/2] valgrind: Disable ptest swapcontext.vgtest

On Wed, 24 Mar 2021 at 00:55, Randy MacLeod wrote: > I had asked Yi to disable the one failing test until we understood more > about it and had a fix. If people prefer to drop the patch that > removes the test, that's fine. > > We'll fix the new test over the coming days/week regardless. > I'm

Re: [oe-core][PATCH 2/2] valgrind: Disable ptest swapcontext.vgtest

On 2021-03-23 5:17 p.m., Yi Fan Yu wrote: On 3/23/21 5:07 PM, Alexander Kanavin wrote: [Please note: This e-mail is from an EXTERNAL e-mail address] On Tue, 23 Mar 2021 at 21:50, Yi Fan Yu mailto:yifan...@windriver.com>> wrote: New test introduced in valgrind 3.17.0. Test fails on both

Re: [OE-core] [dunfell][PATCH] connman: fix CVE-2021-26675, CVE-2021-26676

On 2021-03-23 7:37 p.m., Randy MacLeod wrote: From: Catalin Enache A stack-based buffer overflow in dnsproxy in ConnMan before 1.39 could be used by network adjacent attackers to execute code. gdhcp in ConnMan before 1.39 could be used by network-adjacent. attackers to leak sensitive stack

[OE-core] [dunfell][PATCH] connman: fix CVE-2021-26675, CVE-2021-26676

From: Catalin Enache A stack-based buffer overflow in dnsproxy in ConnMan before 1.39 could be used by network adjacent attackers to execute code. gdhcp in ConnMan before 1.39 could be used by network-adjacent. attackers to leak sensitive stack information, allowing further exploitation of bugs

Re: [OE-core] PR Service and eSDK

On 3/23/21 5:45 PM, Richard Purdie wrote: > On Tue, 2021-03-23 at 17:34 -0500, Mark Hatle wrote: >> For some reason I thought if PR service was enabled, when the eSDK was >> generated >> it would export the pr service information and include it within the eSDK. >> >> I'm not finding the file,

Re: [OE-core] PR Service and eSDK

On Tue, 2021-03-23 at 17:34 -0500, Mark Hatle wrote: > For some reason I thought if PR service was enabled, when the eSDK was > generated > it would export the pr service information and include it within the eSDK. > > I'm not finding the file, or even code that does this. Am I having a fever >

[OE-core] PR Service and eSDK

For some reason I thought if PR service was enabled, when the eSDK was generated it would export the pr service information and include it within the eSDK. I'm not finding the file, or even code that does this. Am I having a fever dream, or is there code that should be doing this? What I'm

Re: [OE-core] [PATCH 1/2] bitbake.conf: ensure BUILD_* tools match target tools

On Tue, Mar 23, 2021 at 2:29 PM Ross Burton wrote: > > Add a few more tools to the BUILD_* list, to match the target tool list. > > Signed-off-by: Ross Burton > --- > meta/conf/bitbake.conf | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/meta/conf/bitbake.conf

[OE-core] [PATCH] image-uefi: Set efi_file for rv32/rv64

Signed-off-by: Khem Raj --- meta/conf/image-uefi.conf | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta/conf/image-uefi.conf b/meta/conf/image-uefi.conf index 882a0e720c..6ef011e23b 100644 --- a/meta/conf/image-uefi.conf +++ b/meta/conf/image-uefi.conf @@ -14,6 +14,8 @@ EFI_ARCH_x86 =

[OE-core] [PATCH 2/2] meson: use native-file instead of environment variables

Meson now supports native-files, which are the same as cross files but describe the native build. By writing and using a native file which describes the tools to use, we can drop the environment variable overriding. Signed-off-by: Ross Burton --- meta/classes/meson.bbclass | 49

[OE-core] [PATCH 1/2] bitbake.conf: ensure BUILD_* tools match target tools

Add a few more tools to the BUILD_* list, to match the target tool list. Signed-off-by: Ross Burton --- meta/conf/bitbake.conf | 3 +++ 1 file changed, 3 insertions(+) diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf index ecd4d1638e..d4bda80736 100644 --- a/meta/conf/bitbake.conf

Re: [oe-core][PATCH 2/2] valgrind: Disable ptest swapcontext.vgtest

On 3/23/21 5:07 PM, Alexander Kanavin wrote: [Please note: This e-mail is from an EXTERNAL e-mail address] On Tue, 23 Mar 2021 at 21:50, Yi Fan Yu mailto:yifan...@windriver.com>> wrote: New test introduced in valgrind 3.17.0. Test fails on both qemuarm64 and qemux64. Fails how? Did you try to

Re: [oe-core][PATCH 2/2] valgrind: Disable ptest swapcontext.vgtest

On Tue, 23 Mar 2021 at 21:50, Yi Fan Yu wrote: > New test introduced in valgrind 3.17.0. > Test fails on both qemuarm64 and qemux64. > Fails how? Did you try to build valgrind on the host and run the test there? I am somewhat concerned that we should not be simply disabling failing tests too

[oe-core][PATCH 2/2] valgrind: Disable ptest swapcontext.vgtest

New test introduced in valgrind 3.17.0. Test fails on both qemuarm64 and qemux64. Signed-off-by: Yi Fan Yu --- ...orarily-drd-tests-swapcontext.vgtest.patch | 28 +++ .../valgrind/valgrind_3.17.0.bb | 1 + 2 files changed, 29 insertions(+) create mode 100644

[oe-core][PATCH 1/2] valgrind: update 3.16.1 -> 3.17.0

Notable changes: * libdir is now libexecdir Added patches: Add musl.supp: missing musl.supp in 3.17.0 Dropped backport patches: * nlcontrolc: found in c79180a3afcf65902e578646c3b716cc749db406 * drd Fedora33: found in 15330adf7c2471fbaa6a0818db07078d81dbff97 Other dropped patches * helgrind

Re: [OE-core] proper (vs weird) way to define proprietary licenses

On Tue, Mar 23, 2021 at 3:13 AM Robert P. J. Day wrote: > > once again into the code base i'm poring over, and this time, it's > about defining proprietary licenses for internal recipes. The typical approach for recipes which build proprietary code is to set LICENSE to "CLOSED" (and not define

Re: [OE-core] [PATCH] [RFC] ffmpeg: make LICENSE_FLAGS fine-grained

On Tue, Mar 23, 2021 at 07:02:43PM +0100, Yann Dirson wrote: > Le mar. 23 mars 2021 à 18:27, Quentin Schulz > a écrit : > > > > Hi all, > > > > On Tue, Mar 23, 2021 at 05:42:20PM +0100, Alexander Kanavin wrote: > > > Is it possible to further split the NONCOMMERCIAL_PACKAGECONFIGS into ones > > >

Re: [OE-core] [PATCH] [RFC] ffmpeg: make LICENSE_FLAGS fine-grained

Le mar. 23 mars 2021 à 18:27, Quentin Schulz a écrit : > > Hi all, > > On Tue, Mar 23, 2021 at 05:42:20PM +0100, Alexander Kanavin wrote: > > Is it possible to further split the NONCOMMERCIAL_PACKAGECONFIGS into ones > > that are enabled and disabled, and use the former in PACKAGECONFIG itself? >

Re: [OE-core] [PATCH] [RFC] ffmpeg: make LICENSE_FLAGS fine-grained

Hi all, On Tue, Mar 23, 2021 at 05:42:20PM +0100, Alexander Kanavin wrote: > Is it possible to further split the NONCOMMERCIAL_PACKAGECONFIGS into ones > that are enabled and disabled, and use the former in PACKAGECONFIG itself? > > Alex > > On Tue, 23 Mar 2021 at 17:38, Yann Dirson > wrote: >

[OE-core] [PATCH] gstreamer1.0-libav: remove explicit LICENSE_FLAGS

From: Yann Dirson This flag does not describe the gst-libav package, but ffmpeg instead. It gets in the way of using finer-grained LICENSE_FLAGS in ffmpeg. It is above all not needed, the real problem is even more clear without it: ffmpeg was skipped: because it has a restricted license

Re: [OE-core] [PATCH] [RFC] ffmpeg: make LICENSE_FLAGS fine-grained

Is it possible to further split the NONCOMMERCIAL_PACKAGECONFIGS into ones that are enabled and disabled, and use the former in PACKAGECONFIG itself? Alex On Tue, 23 Mar 2021 at 17:38, Yann Dirson wrote: > From: Yann Dirson > > The rationale here is that if the user can only whitelist

[OE-core] [PATCH] [RFC] ffmpeg: make LICENSE_FLAGS fine-grained

From: Yann Dirson The rationale here is that if the user can only whitelist "commercial" to use any part of ffmpeg, even it the list of features is carefully reviewed when switching the whitelisting on, there was nothing to guard from inadvertently activating a new feature that would not have

[OE-core] [PATCH] ffmpeg: disable GPL features by default

From: Yann Dirson --disable-gpl is the upstream default, and using GPL features violates the license when linking into non-GPL programs. Enabling it by default breaks user expectations, may cause people to violate the GPL by mistake. Signed-off-by: Yann Dirson ---

[OE-core] [PATCH 1/2] lib/oe/utils: add directory size function

From: Ross Burton For the purpose of image construction using du on a rootfs directory isn't entirely satisfactory. Bare "du" will report the actual disk usage so file systems which can compress the data will report less than the actual space required. Using "du --apparent-size" will report

[OE-core] [PATCH 2/2] classes/image: use oe.utils.directory_size() instead of du

From: Ross Burton Instead of using du (which has issues as disussed in the previous commit), use the new oe.utils.directory_size() function. Signed-off-by: Ross Burton --- meta/classes/image.bbclass | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git

Re: [OE-core] [PATCH] linux-yocto/5.10: update qemuriscv32 v5.10.23

On Tue, Mar 23, 2021 at 8:51 AM Bruce Ashfield wrote: > > On Tue, Mar 23, 2021 at 11:48 AM Khem Raj wrote: > > > > > > > > On 3/23/21 5:16 AM, Bruce Ashfield wrote: > > > On Tue, Mar 23, 2021 at 12:29 AM Khem Raj wrote: > > >> > > >> > > >> > > >> On 3/22/21 11:44 AM, Bruce Ashfield wrote: > >

Re: [OE-core] [PATCH] linux-yocto/5.10: update qemuriscv32 v5.10.23

On Tue, Mar 23, 2021 at 11:48 AM Khem Raj wrote: > > > > On 3/23/21 5:16 AM, Bruce Ashfield wrote: > > On Tue, Mar 23, 2021 at 12:29 AM Khem Raj wrote: > >> > >> > >> > >> On 3/22/21 11:44 AM, Bruce Ashfield wrote: > >>> From: Bruce Ashfield > >>> > >>> The kernel SRCREV updates were missing

Re: [OE-core] [PATCH] linux-yocto/5.10: update qemuriscv32 v5.10.23

On 3/23/21 5:16 AM, Bruce Ashfield wrote: On Tue, Mar 23, 2021 at 12:29 AM Khem Raj wrote: On 3/22/21 11:44 AM, Bruce Ashfield wrote: From: Bruce Ashfield The kernel SRCREV updates were missing riscv32, so stayed back on 5.10.21, which causes build issues as PV is out of sync with the

Re: [OE-core] [PATCH v4] grub: upgrade 2.04 -> 2.06~rc1

I am seeing a build regression on riscv32 see https://errors.yoctoproject.org/Errors/Details/574356/ any ideas? On Fri, Mar 19, 2021 at 10:33 AM Richard Purdie wrote: > > On Fri, 2021-03-19 at 10:04 -0700, Khem Raj wrote: > > I think renaming recipe to drop PV from its name is not a good as

Re: [OE-core] [PATCH] kernel-yocto: stop converting remote branches to local branches

>On Tue, Mar 23, 2021 at 10:22 AM Tomasz Dziendzielski > wrote: >> >> From: Wladislav Wiebe >> >> Introduced poky upstream commit: >> 14df6d53b6 linux-yocto: improve checkout error handling and reporting >> >> Converts all remote branches to local branches. >> Our Linux repo has ~4500 remote

[OE-core] Yocto Project Status WW11`21

Current Dev Position: YP 3.3 M4 (Feature Freeze) Next Deadline: 5th April 2021 YP 3.3 M4 build Next Team Meetings: * Bug Triage meeting Thursday Mar. 25th at 7:30am PDT (

Re: [OE-core] [PATCH] kernel-yocto: stop converting remote branches to local branches

On Tue, Mar 23, 2021 at 10:22 AM Tomasz Dziendzielski wrote: > > From: Wladislav Wiebe > > Introduced poky upstream commit: > 14df6d53b6 linux-yocto: improve checkout error handling and reporting > > Converts all remote branches to local branches. > Our Linux repo has ~4500 remote branches: >

[OE-core] [PATCH] kernel-yocto: stop converting remote branches to local branches

From: Wladislav Wiebe Introduced poky upstream commit: 14df6d53b6 linux-yocto: improve checkout error handling and reporting Converts all remote branches to local branches. Our Linux repo has ~4500 remote branches: git branch -a | grep remotes |wc -l -> 4575 This costs our best workstations

Re: [OE-core] [PATCH v2] rootfs.py: mask run-postinsts systemd service when unneeded

Could you please look into logs. Seems that path cause failures. https://autobuilder.yoctoproject.org/typhoon/#/builders/101/builds/2114/steps/13/logs/stdio *** Central error: 2021-03-23T02:03:58+ ERROR Error in POSTIN scriptlet in rpm package run-postinsts

Re: [OE-core] [PATCH] linux-yocto/5.10: update qemuriscv32 v5.10.23

On Tue, Mar 23, 2021 at 12:29 AM Khem Raj wrote: > > > > On 3/22/21 11:44 AM, Bruce Ashfield wrote: > > From: Bruce Ashfield > > > > The kernel SRCREV updates were missing riscv32, so stayed back on > > 5.10.21, which causes build issues as PV is out of sync with the > > actual kernel version. >

[OE-core] [PATCH] sstate: Add documentation for eventhandlers and tweak naming

Signed-off-by: Richard Purdie --- meta/classes/sstate.bbclass | 27 +-- 1 file changed, 21 insertions(+), 6 deletions(-) diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass index 1fa8a63d174..8e8efd18d58 100644 --- a/meta/classes/sstate.bbclass +++

Re: [OE-core] [PATCH v3 1/2] gettext-minimal: Disable the unnecessary check in iconv.m4

On Tue, 2021-03-23 at 14:25 +0800, Yu, Mingli wrote: > > On 3/22/21 11:24 PM, Richard Purdie wrote: > > [Please note: This e-mail is from an EXTERNAL e-mail address] > > > > On Mon, 2021-03-22 at 11:29 +0300, Alexander Kanavin wrote: > > > Note that this m4 file is copied verbatim from upstream

Re: [OE-core] [poky][PATCH] package_manager: install versioned postinst scripts

Yes, this use case makes sense. Then the reliable way is to cleanup upperdir of overlayfs during image upgrade and make postinsts scripts re-entrant. On Tue, Mar 23, 2021, 07:56 Mike Looijmans wrote: > So it's something exclusively for OpenBMC. > > As for running the scripts, you cannot simply

[OE-core] personal naming convention for tasks versus functions

more a style thing than anything else, but i've noticed in the layer i'm perusing a number of examples of the form: do_something() { ... doing something ... } do_unpack[postfuncs] += "do_something" i mention this only because my preference is to reserve the "do_" prefix for

[OE-core] proper (vs weird) way to define proprietary licenses

once again into the code base i'm poring over, and this time, it's about defining proprietary licenses for internal recipes. turns out the meta-boundary layer has a nice example of what i'm sure is the right way to do this (i've rarely had to do this myself), wherein the layer's "layer.conf"

Re: [OE-core] curious about weirdness in some FILES_${PN} settings

On Tue, 23 Mar 2021, Damian Wrobel wrote: > On Mon, 22 Mar 2021 20:27:42 +0100 Andre McCurdy > wrote > > On Mon, Mar 22, 2021 at 11:43 AM Robert P. J. Day > wrote: > > > (warning: i've just been handed an existing OE code base, and i'm > > > going to ask some questions about

Re: [OE-core] really strange usage of FILESPATH and FILESEXTRAPATHS

On Tue, Mar 23, 2021 at 05:00:07AM -0400, Robert P. J. Day wrote: > On Tue, 23 Mar 2021, Quentin Schulz wrote: > > > On Mon, Mar 22, 2021 at 03:18:30PM -0700, Andre McCurdy wrote: > > > On Mon, Mar 22, 2021 at 2:29 PM Robert P. J. Day > > > wrote: > > > > > > > > here's the next

Re: [OE-core] really strange usage of FILESPATH and FILESEXTRAPATHS

On Tue, 23 Mar 2021, Quentin Schulz wrote: > On Mon, Mar 22, 2021 at 03:18:30PM -0700, Andre McCurdy wrote: > > On Mon, Mar 22, 2021 at 2:29 PM Robert P. J. Day > > wrote: > > > > > > here's the next head-scratching oddity i just ran across in the > > > current layer (and there's more

Re: [OE-core] curious about weirdness in some FILES_${PN} settings

On Mon, 22 Mar 2021 20:27:42 +0100 Andre McCurdy wrote > On Mon, Mar 22, 2021 at 11:43 AM Robert P. J. Day > wrote: > > (warning: i've just been handed an existing OE code base, and i'm > > going to ask some questions about some head-scratching things i'm > > finding in

Re: [OE-core] really strange usage of FILESPATH and FILESEXTRAPATHS

On Mon, Mar 22, 2021 at 03:18:30PM -0700, Andre McCurdy wrote: > On Mon, Mar 22, 2021 at 2:29 PM Robert P. J. Day > wrote: > > > > here's the next head-scratching oddity i just ran across in the > > current layer (and there's more weirdness on its way). > > > > perusing a recipe only to see:

Re: [OE-core] [poky][PATCH] package_manager: install versioned postinst scripts

So it's something exclusively for OpenBMC. As for running the scripts, you cannot simply conclude that a script doesn't need to run if its contents did not change. It may very well call the executable from its package to do the actual work and that may have changed as well. Met

Re: [OE-core] [PATCH v3 1/2] gettext-minimal: Disable the unnecessary check in iconv.m4

On 3/22/21 11:24 PM, Richard Purdie wrote: [Please note: This e-mail is from an EXTERNAL e-mail address] On Mon, 2021-03-22 at 11:29 +0300, Alexander Kanavin wrote: Note that this m4 file is copied verbatim from upstream gettext, and will be again overwritten on next gettext upgrade. You