BitBake always runs with pseudo loaded but disabled. When we fork a child, we decide whether to enable it or not and setup the environment to either bring pseudo to life, or unload it from memory enti

This is pretty much what we do at the moment, it gets unset after we load. Pseudo is of course disabled at this point. I guess we just got lucky to this point and avoided "Bad Things"? Cheers, Richard

This is why I'm not saying lets just set PSEUDO_PREFIX. Its bothering me too. Obviously :). Except the code does this and I've watched it happen. I'm not claiming to understand it... When we poke new

BBMASK removes recipes from being parsed. It does not remove them from images although that would I guess be an indirect result since you could no longer build them. Its designed so that if you for ex

I hadn't realised Scott had added this to the customising images section of the manual. This is not what its designed for and we need to move this to somewhere less confusing. Scott: This is going to

In the interests of clarity, as Tracey will tell you there is no "Yocto" (which is an SI prefix), only the "Yocto Project" :). I know some of us have bad habits but since we're trying to ensure we're

I was surprised to hear that but its easy enough to test: diff -ur bitbake/ ../bitbake/ Only in bitbake//bin: bitbake-runtask Only in ../bitbake/: classes Only in ../bitbake/: conf Only in ../bitbake/

Merged to master, thanks. Richard

I don't think there is common ground in this area to work with. There is a certain class of users who really need a single repo with all the pieces in to get started with. Poky and some of the solutio

If the user has used "=" in their configuration files, hob needs to deal with this. It is not acceptable to patch the world to revolve around hob. So, no, I'm not going to take this patch, sorry. Chee

Let me jump in here since I've looked at the rpm code paths in question before. RPM basically works its way through the install manifest so if you have for example: base-passwd shadow dbus-1 libc then

Note the key here is that for a system with large amounts of memory, you can effectively keep the build in memory due to the long commit time. All the tests I've done show we are not IO bound anyway.

Merged to master, thanks. Richard

So just to follow up here too for the list archives: This “craziness” does have a rational explanation. “native” targets are meant to run on the system they’re built on and run in the location they’re

This sounds like a host contamination issue, we shoudn't be looking at files like that during the build. We probably need to stop the system looking at those files but I'm not familiar with boost to k

I had a thought about this: diff --git a/meta/conf/distro/include/default-distrovars.inc b/meta/conf/distro/include/default-distrovars.inc index 16b3108..f770919 100644 --- a/meta/conf/distro/include/

I've merged these, thanks. and I've passed this on to Scott to handle. Cheers, Richard

_append variables stack so if you do: A_append = "x" A_append = "y" A_append = "z" You'll end up with A = "xyz". You can do something a little more ugly to work around it like: do_install_append () {

We're going to need to get out of this habit since it breaks for multilibs :( Cheers, Richard

I screwed up and accidentally merged the above in another commit. Thankfully the code actually works and I'm therefore not going to revert it and it will go into the release. I tried a quick build wit