From: Tom Zanussi <tom.zanussi@...> Have fishriver.conf use the common-bsp-* .inc files and remove the open-coded machine settings. Signed-off-by: Tom Zanussi <tom.zanussi@...> ---

From: Tom Zanussi <tom.zanussi@...> Have crownbay.conf and crownbay-noemgd.conf use the common-bsp-* .inc files and remove the open-coded machine settings. Signed-off-by: Tom Zanussi

From: Tom Zanussi <tom.zanussi@...> Have sugarbay.conf use the common-bsp-* .inc files and remove the open-coded machine settings. Signed-off-by: Tom Zanussi <tom.zanussi@...> ---

From: Tom Zanussi <tom.zanussi@...> The meta-intel BSPs currently have a number of machine settings common to all - factor these out into a couple common include files. Signed-off-by: Tom

From: Tom Zanussi <tom.zanussi@...> The meta-intel BSPs have some common settings - this just moves them out int separate .inc files to simplify them and ease maintenance. I compiled and

just so i'm doing this the right way, what is the appropriate way to report bitbake fetch errors? with a fully-updated git repo, i just ran: $ bitbake -c fetchall -k core-image-sato and got fetch

I do have two branches (master and Bernard) in my yocto-docs contrib area. The master branch is used for updates to the upcoming release and is in various states of correctness/completeness. I guess

I agree that the docs in master should reflect the code in master and that the docs on the bernard branch should be the ones which make the bernard references. Which or both can end up on the website

ok, that explains it but it doesn't defend it. IMHO, any single versioned tarball or repository checkout should always be internally consistent, and that includes embedded documentation. when i do

As I understand it documentation repository updates are reflected on the website so the docs tend to reflect the released version. It would be nice to be able to provide development &

From: Yinghai Lu <yinghai@...> commit 8f389a99b652aab5b42297280bd94d95933ad12f upstream. Stefan found nobootmem does not work on his system that has only 8M of RAM. This causes an early

From: Darren Hart <dvhart@...> The following patch from mainline addresses an issues that prevented my qemu testing from booting in less than 17M of memory. With this page, the kernel can

Robert, What release of Yocto Project are you using? Scott

currently, scripts/oe-setup-builddir lists one of the common targets as "core-image-sato", so certainly *something* is out of sync. rday --

Robert, My understanding was that the target for this sample command could not be 'core-image-sato' for the QS version on the website, which supports Bernard. Maybe someone out there has a bit more

maybe i'm misreading something, but the yocto QS guide provides the sample command: $ bitbake -k poky-image-sato however, nothing provides that target. i can see the git log entry: commit

I think we have all the pieces there but someone would have to connect them up... Cheers, Richard

Correct, or at least not that I've used out of the box, and this is what Koen was commenting on. Cheers, Bruce

Ugh, sorry. Bug #1244 to track http://bugzilla.pokylinux.org/show_bug.cgi?id=1244 Yeah, I sucked at designing use cases. This is already filed as bug #1239

Try this: bitbake -u hob -> Python traceback change PARALLEL_MAKE from 'j8' to 'j 8' bitbake -u hob click save Open up recipe in editor -> 'require None.bb' So it looks like creating an image