<zbigniew.bodek@...> wrote: My recommendation would be to pull that patch out and apply it directly on top of v2.5.0 (assuming that is feasible). Maybe even asking the upstream zephyr project

Do we really want to have Zephyr on a release candidate? IMHO, we should never be doing this, as we should want the kernel in meta-zephyr to be as stable as possible. If this is really

Read the generated QEMU conf file, instead of using hard coded values. This allows for machines not conforming to the hard coded values to work with testimage. Signed-off-by: Jon Mason

Current Dev Position: YP 3.4 M1 Next Deadline: 7th June 2021 YP 3.4 M1 build Next Team Meetings: Bug Triage meeting Thursday May 20th at 7:30am PDT

Thanks, I'll give that a go! I'll give do_populate_lic task a look. We're working on this as a part of a workflow that utilizes the SPDX files. Our tool uploads the source code archived by the layer

From: Zbigniew Bodek <zbigniew.bodek@...> Signed-off-by: Zbigniew Bodek <zbigniew.bodek@...> --- recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc | 2 +- 1 file changed, 1

From: Zbigniew Bodek <zbigniew.bodek@...> This version can be selected defining PREFERRED_VERSION_zephyr-kernel ??= "2.6.0-rc1" Signed-off-by: Zbigniew Bodek <zbigniew.bodek@...> ---

From: Wojciech Zmuda <wojciech.zmuda@...> 2.6.0-rc1 has been released 9 days ago and contains a vast number of improvements. Release notes available here:

From: Wojciech Zmuda <wojciech.zmuda@...> Add support for Nordic Semiconductor nRF52840 Development Kit board. This is a generic MACHINE over nRF52 SoC family config plus PyOCD flashing

From: Wojciech Zmuda <wojciech.zmuda@...> The file is so generic anyway it can be targeted for the nRF52 family without any harm. Signed-off-by: Wojciech Zmuda

From: Wojciech Zmuda <wojciech.zmuda@...> This patch set adds support for Nordic Semiconductor nRF5284 Development Kit board. Since there already is nRF52xx family chip support added

I don't have much to go on but guessing, if you run some test and then rerun that test, the second build would come from sstate. If a build comes from sstate, it will  skip tasks that precede the

Hi all, Intel and WR YP QA is planning for QA execution for YP build yocto-3.3.1.rc1. We are planning to execute following tests for this cycle: OEQA-manual tests for following module: 1. OE-Core 2.

That is odd indeed. I need to give it another go. As for accounting for sstate, no, at least not intentionally. Public at https://github.com/doubleopen-project/meta-doubleopen. The usual disclaimers

This seems a little odd since image.bbclass has: do_rootfs[recrdeptask] += "do_packagedata" which means do_rootfs should only happen after all do_packagedata have run. Your task is added before

Hi, I've created a task do_create_spdx that gets some data from packages after do_package. The task is currently added with `addtask do_create_spdx after do_package before do_packagedata` The data is

usually it means lua version mismatch. You might be hitting same issue as reported here https://trac.videolan.org/vlc/ticket/25036 there is a patch attached to that ticket. Please try to apply that

Hi , I am trying to run vlc-3.0.11 media player on my riscv target board. I am facing problem this package [cli] lua interface error: Error loading script /usr/lib/vlc/lua/intf/cli.luac:

Hi , I am trying to run vlc-3.0.11 media player on my riscv target board. I am facing problem this package [cli] lua interface error: Error loading script /usr/lib/vlc/lua/intf/cli.luac:

All, The below were the owners of enhancements or bugs closed during the last week! Who Count randy.macleod@... 7 richard.purdie@... 5 mhalstead@... 1 timothy.t.orling@... 1 Grand