From: Catalin Enache <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

Ok, this confirms what I am seeing then. Maybe it was discussed and was never implemented. I'll look at where the unihashes.dat is copied over and look to do the export... and then import in the

I know we copy bb_unihashes.dat into the eSDK with code in populate_sdl_ext.bbclass for this reason for hashequiv. We do have prserv export and import code but I'm not sure anyone has integrated

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

Do these new variables need to be exported? As far as I remember a few of the BUILD_xxx variables are "official" autotools variables which some autotools packages may expect to find in the

Signed-off-by: Khem Raj <raj.khem@...> --- 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

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

Add a few more tools to the BUILD_* list, to match the target tool list. Signed-off-by: Ross Burton <ross.burton@...> --- meta/conf/bitbake.conf | 3 +++ 1 file changed, 3 insertions(+) diff

it passes on the host (relatively recent archlinux build x86-64) I just checked on qemu and it miraculously passes. (it seems to be load dependent) My recommendation now would be just take the first

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 quickly like this; the very point of ptest

New test introduced in valgrind 3.17.0. Test fails on both qemuarm64 and qemux64. Signed-off-by: Yi Fan Yu <yifan.yu@...> --- ...orarily-drd-tests-swapcontext.vgtest.patch | 28

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

The typical approach for recipes which build proprietary code is to set LICENSE to "CLOSED" (and not define LIC_FILES_CHKSUM). I'm not sure what the advantages are of creating a license text for

That was exactly what I meant. No idea either if such a mechanism exists. Cheers, Quentin

<quentin.schulz@...> a écrit : Makes sense. You mean, that "commercial" would be whitelisted globally, but then something would exclude ffmpeg from that whitelist ? I'm not aware of

Hi all, I would at least make it commercial_ffmpeg- + cfg. To make it obvious that it belongs to ffmpeg recipe/packages. I guess it breaks backward compatibility, which IMO is fine unless there is a

From: Yann Dirson <yann@...> 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

Is it possible to further split the NONCOMMERCIAL_PACKAGECONFIGS into ones that are enabled and disabled, and use the former in PACKAGECONFIG itself? Alex

From: Yann Dirson <yann@...> 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

From: Ross Burton <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