To Krishna I’ sorry that I missed your mail, I’ll try to reproduce your issue. Best regards Lei

Hi Marco I'm sorry, but your patch seems not base on the latest source code. https://git.yoctoproject.org/cgit/cgit.cgi/meta-spdxscanner/tree/classes/fossology-rest.bbclass Best regards Lei

applied to meta-rockchip master

applied to meta-rockchip master

Resend: The list: Yocto discussion list <yocto@...> didn't work and may be dead so switch to: yocto@... <yocto@...> ../Randy YP AB

Hi, I tried to apply without success, looks like the patch is corrupted, can you send it again?, or share a git repo/branch. Regards, Anibal

cc-ing yocto list

Indeed this change doesn't has a direct impact but is fine to me. Applied, Thanks!

Applied, Thanks!,

Hi, In a normal execution this memleak doesn't have a bad effect in practical terms because at end of the program the memory will be free'd. I'm fine to pick this patch. Regards, Anibal

Applied, Thanks!, Anibal.

Hi all, Just replied in other email about this situation, so yes for me is better at least return 1 when any test fails to make it backwards compatible and knows when some test fails. Regards, Anibal

Hi Mitch, You can get systemd into your image... refer to the mega-manual: https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#using-systemd-exclusively Hopefully this resolves your

I have a project I am attempting to migrate from a Debian platform to Yocto. This specific project has a dependency on libsystemd-dev which is a Debian package, but it doesn't seem to build when

Hi guys, i am running yocto (with IMX BSP gatesgarth-5.10.9-1.0.0) inside docker and am getting the below issue which i though to be already fixed by https://patchwork.openembedded.org/patch/174423/.

Hello all, This is the full report for yocto-3.4_M2.rc1: https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults ======= Summary ======== No high

I would favor to keep non-zero exit value if any tests failed. We have relied on exit value since ptest started to support it, others may be doing that as well. This would be backward incompatible

It is not guaranteed to build or work otherwise, and causes update failures in unrelated recipes when building for musl for instance. Signed-off-by: Alexander Kanavin <alex.kanavin@...> ---

The ordering isn't correct here since they have to be added in dependency  order and for some reason this was different to the patch we discussed  previously. I've just gone ahead and fixed

I am worried about those libraries, which are non-PIE libraries by default. My theory is, that they are non-PIE since prelink is able to operate on them. So prelink can "at least" be used a PIE