Hi, Was I trying to solve the same problem in https://lists.openembedded.org/g/openembedded-core/message/176203 ? I think so. Cheers, -Mikko

I haven't checked yet in dunfell, but in kirkstone this commit merged last week breaks nativesdk-qemu builds. This chunk: +@@ -1486,7 +1505,7 @@ void *qxl_phys2virt(PCIQXLDevice *qxl, QXLPHYSICAL

All, Below is the list as of top 30 bug owners as of the end of WW04 of who have open medium or higher bugs and enhancements against YP 4.2. There are 62 possible work days left until the final

All, The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on

On Mon, 30 Jan 2023 at 21:30, Alexander Kanavin via lists.openembedded.org <alex.kanavin=gmail.com@...> wrote: I sent a patch which does fix the dangling nfsd processes. I'm

This does not actually guarantee that the child runqemu process has completely exited: poll() may return prematurely while the SIGTERM handler in runqemu is still running. This thwarts the rest of the

<richard.purdie@...> wrote: I'm going slightly mad. The trouble occurs in stop() method in meta/lib/oeqa/utils/qemurunner.py. The method sends SIGTERM to runqemu proces, then runs

Grr, incomplete email! Let me resend.

<richard.purdie@...> wrote: I'm going slightly mad. The trouble occurs in stop() method in meta/lib/oeqa/utils/qemurunner.py. The method sends SIGTERM to runqemu proces, then runs

We've done a version bump to 21.1.6 in kirkstone, so you'll need to rework this patch (if it is still necessary) Thanks! Steve

Patches sent (upgrade and ignore). NIST haven’t taken the CPE fixes I sent, re-sent. This was fixed by a patch on the list that was incorrectly labelled as langdale, I’ve reposted it. Both

<xiangyu.chen@...> wrote: This patch is in my current test queue, so if all goes well it will be in the next patchset for both langdale and kirkstone. Steve

For the case of a global shared state cache and a local sstate cache with a mix of signed and un-signed entries, there is a case where a .sig is missing locally, but may exist in the global sstate

Everything we need for `rust-snapshot.inc` exists in `src/stage0.json`, so just read that to generate it. Signed-off-by: Alex Kiernan <alex.kiernan@...> ---

* most xinetd users probably don't need this nowadays and it pulls perl into the images Signed-off-by: Martin Jansa <Martin.Jansa@...> --- meta/recipes-extended/xinetd/xinetd_2.3.15.4.bb | 5

<alex.kanavin@...> wrote: I'm being thick... that was the obvious approach. Will sort it now. -- Alex Kiernan

No, you can simply add it as a task directly into one of the rust recipes. Take a look at what the crate updater class does and add similar functionality into a recipe which has the input json with

<alex.kanavin@...> wrote: Yes, right now it's standalone, I was looking at trying to add it into the devtool upgrade flow, but its so specific, that doesn't seem like a good fit. On the same

FWIW: this change doesn't help in the case I've reported earlier, because the bbclass which was doing the split('-') was also checking that the suffix was one of the supported values. So I'll continue

From: Vivek Kumbhar <vkumbhar@...> Signed-off-by: Vivek Kumbhar <vkumbhar@...> --- .../openssl/openssl/CVE-2022-3996.patch | 43 +++++++++++++++++++ .../openssl/openssl_3.0.7.bb