Merged to master, thanks. Richard

I'm chasing a bug that looks very like this at the moment. I don't have a proper fix for it yet but you could try and "bitbake linux-yocto -c populate_sysroot -f" and then try and build your image aga

One nice thing on those chart is that the number of high/major/critical bugs went down which is good to see! Cheers, Richard

Just to update on build time at the moment, we did regress pretty badly recently. I'm fairly sure this was down to a useradd change which meant dbus-native was depending on a target package and holdin

To update, qemux86 was 42 minutes so we're definitely looking back on track with parallelism improvements at least. Cheers, Richard

Could you post some logs of the build showing this problem please? Elsewhere you pointed out a recipe with a plain SRC_URI = "ftp://xxx" address which would be the correct way to do this. I suspect yo

Yes, a -native recipe to build the tools and then use those native tools in the cross built is the way to go. Take a look at any of the recipes which have a DEPENDS on a native version of themselves.

I'd like to give the bitbake perspective on this problem. PREFERRED_PROVIDER in images doesn't really make sense to bitbake. Imagine you have: core-image-minimal setting PREFERRED_PROVIDER = "kernelA"

Images aren't the problem, those are easy. Its the packages. How do you represent that kernel-image A is built with configuration X and kernel-image B is built with configuration Y. How do you determi

This might create a little friction with the OE community. What would be the reason for the repository? I'd certainly be happy to see such a branch. It might be more appropriate to call it 2011-1 whic

I think it should be fine to add an appropriate branch to the meta-oe repository itself. Cheers, Richard

There is a 2011-1 branch in oe-core and there is going to be an update policy of bugfixes but not upgrades or new features for that. Cheers, Richard

I think Joshua's response is in line with what I'm thinking. Distro is where all the policy is specified. The image is just a list of pieces of software to include, its not meant to be much more than

I understand the flexibility but I also think we need to consider usability a little. We have people using the system to whom it might not be immediately obvious why building a sato image with the tin

I'm not aware of anyone working on this but I like the idea of a BSP for it and it shouldn't be too hard to do. I'd be happy to ensure we have a repository somewhere on git.yoctoproject.org to support

What's needed is something which results in a "stop the build and force the user to change something to continue" so I'm not sure I see the problem with that. I know exactly how much attention people

Why doesn't something like: """ $meta-yocto/conf/distro$ cat poky-lsb.conf require conf/distro/poky.conf DISTRO = "poky-lsb" DISTROOVERRIDES = "poky:linuxstdbase" """ work? Effectively the above takes

I'd just note that if merged, this would make meta-fri2 depend on meta-tiny since we'd throw parsing errors if the .bbappend is present without the file its appending to. We might want to consider thi

Right, I'd expect you are totally overriding DISTRO_FEATURES anyway. Right now you need to override these things, in future I suspect you're going to want to share them when tiny becomes compatible wi

I suggesting meta-dri2/meta-intel depending on meta-tiny is a problem. Where does meta-yocto come into this? Cheers, Richard