This converts the layer to the new override syntax. This was done using <oe-core>/scripts/contrib/convert-overrides.py <this-layer> with no manual fixes. Signed-off-by: Richard Purdie <richard.purdie@

This marks the layers as compatible with honister now they use the new override syntax. Signed-off-by: Richard Purdie <richard.purdie@...> --- conf/layer.conf | 2 +- 1 file changed, 1

These haven't been used for a long time and can therefore be removed. Signed-off-by: Richard Purdie <richard.purdie@...> --- recipes-core/gettext/gettext_0.16.1.bb | 8 -- .../uclibc-su

Signed-off-by: Richard Purdie <richard.purdie@...> --- conf/layer.conf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/conf/layer.conf b/conf/layer.conf index 194a55d

This converts the two layers to the new override syntax. This was done using <oe-core>/scripts/contrib/convert-overrides.py <this-layer> Signed-off-by: Richard Purdie <richard.purdie@...

Fix a coupld of mis-converted lines from the automated override conversion script. Signed-off-by: Richard Purdie <richard.purdie@...> --- recipes-devtools/gcc/gcc-runtime_%.bbappend |

A build flagged for QA (yocto-3.1.10.rc1) was completed on the autobuilder and is available at: https://autobuilder.yocto.io/pub/releases/yocto-3.1.10.rc1 Build hash information: bitbake: 0e0af15b84e0

A build flagged for QA (yocto-3.3.2.rc2) was completed on the autobuilder and is available at: https://autobuilder.yocto.io/pub/releases/yocto-3.3.2.rc2 Build hash information: bitbake: 731fb52eb03338

To help with the conversion, switch the core configurations to use the new syntax since this allows testing with the new syntax only. Signed-off-by: Richard Purdie <richard.purdie@...>

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 it. Cheers,

I can't see the patch in the mailing list archives: https://lists.yoctoproject.org/g/yocto/topics? only your reply: https://lists.yoctoproject.org/g/yocto/topic/patch/84387478? so I don't think the or

A build flagged for QA (yocto-3.4_M2.rc1) was completed on the autobuilder and is available at: https://autobuilder.yocto.io/pub/releases/yocto-3.4_M2.rc1 Build hash information: bitbake: 13e2855bff6a

I don't have the skills to review this in detail but it sounds like a good step forward for many different reasons, thanks! Cheers, Richard

How is your container filesystem setup/configured? It looks like the filesystem isn't liking the build trying to create hardlinked files. It is odd it would get as far as gmp-native before having prob

Rather than just ppc/mips, use the pregen-hostkeys on all the qemu targets since this is using a lot of time on the autobuilders when we don't really need to. This should avoid some of the testing fai

We'd normally expect the bug owner to update the status of the bug since it isn't really possible for me or the triage team to track and update them all. We can close this one with a link to the commi

http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/classes/report-error.bbclass?id=8b299a62c55aa8d1583aff4b8428f16def7231b7 It appears to have merged 5 months ago? Also, looking at the patch that i

You're used to poking around things in buildroot, OE doesn't quite like you doing that so much :) You shouldn't really be poking around DEPLOY_DIR without letting the build system know what you're doi

In OE, the equivalent for that is probably the image types code. See http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/image_types.bbclass You can define your own custom image types to exten

The issue you describe does sound strange. I was a little unclear about exactly which combinations were passing/failing. Are you saying that some versions of buildtools let the system work but some do