mirror of
https://git.yoctoproject.org/poky
synced 2026-06-16 16:53:48 +02:00
f163fd8ec4
nativesdk-gpgme fails package_qa when setting PACKAGE_DEBUG_SPLIT_STYLE = "debug-with-srcpkg". ERROR: nativesdk-gpgme-1.10.0-r0 do_package_qa: QA Issue: non debug package contains .debug directory: nativesdk-python3-gpg path /work/x86_64-nativesdk-oesdk-linux/nativesdk-gpgme/1.10.0-r0/packages-split/nativesdk-python3-gpg/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/python3.5/site-packages/gpg/.debug/_gpgme.cpython-35m-x86_64-linux-gnu.so [debug-files] This turns out to be because the automatic moving of the -dbg package to the beginning of the package list is disabled in that case, so the python3-gpg packages that the recipe prepends to PACKAGES ends up before the -dbg package. It's not clear why the "and not split_source_package" was added when debug-with-srcpkg was introduced. Presumably the intention was to prevent the -dbg package to end up before the -src package, which we of course need to. But at the same time, we still need -dbg packages to end up before all other packages. Using list.insert(0, ...) also means that if there happens to more than one -dbg package, their relative ordering gets inverted in the new list. This tries to fix these issues by sorting the packages by (priority, original position), where priority is 10 for -src, 30 for -dbg and 50 for everything else. That guarantees that packages of the same "type" preserve their relative ordering, while also ensuring that -dbg always preceed other packages. This scheme is also quite extensible, and, should the need arise, one could even expose the priorities as a knob the recipe author could use to ensure specific orderings of packages instead of the somewhat fragile and coarse-grained method of "prepend or append, and ensure you do that in a proper order". Probably the autodebug condition needs to stay, but I think the split_source_package condition in the preceding elif should be removed, so that that logic applies to all packages called -src, not just the one we might have created a few lines above. (From OE-Core rev: 805edbc7dc9ceae00d991f9b4e185bbbe1d3ba45) Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
QEMU Emulation Targets ====================== To simplify development, the build system supports building images to work with the QEMU emulator in system emulation mode. Several architectures are currently supported in 32 and 64 bit variants: * ARM (qemuarm + qemuarm64) * x86 (qemux86 + qemux86-64) * PowerPC (qemuppc only) * MIPS (qemumips + qemumips64) Use of the QEMU images is covered in the Yocto Project Reference Manual. The appropriate MACHINE variable value corresponding to the target is given in brackets.