From: Tom Zanussi <tom.zanussi@...> Here are a set of changes that attempt to clean up the BSP Development Manual a bit. Thanks to Robert P. J. Day and Jim Abernathy for their input. I went

I ran into various issues trying to add mtd-utils to an image today. As I worked through the issues, I found after fixing a couple things, I was more guessing and grasping at straws than anything

I'm noticing fetcher failures while my bitbake is working. They are listed as warning. Do I ignore these?? WARNING: Fetcher failure for URL: 'None'. Fetch command export HOME="/home/jim"; export

Making a release announcement on behalf of the pseudo maintainer... pseudo 1.2 is now released. It can be pulled from: Via

Yeah, that's not out of line with expectations. You are using BB_NUMBER_THREADS and PARALLEL make in your local.conf, I assume. I wouldn't pay too much attention to the task numbers themselves -

I'm building on Core i5 desktop with Ubuntu 10.10. One of the odd things I've noticed during the build is it takes the usual long time (couple of hours) to build. However when it get to task ~4000,

That size doesn't sound right. Here's mine: -rw-r--r-- 1 trz trz 358715392 2011-11-01 19:11 core-image-sato-mymachine-20111101223904.hddimg And what kind of machine are you booting it on? Tom

Hi all - this is the announcement that went out on Weds at the Embedded Linux Conference Europe / LinuxCon Europe, in case you haven't seen it. Yocto Project Introduces New Features The Linux

Well, I finally got a "successful" build without erros of the Appendix A example for Crownbay, but the image created was only 216MB in size and kernel panic'ed because it couldn't find a valid root

Yes, they will end up there, as the next paragraph mentions: "I'll be collecting candidate commits for a 1.1 point release there until it's time to cut the 1.1 point release, and will pull those into

From a build perspective, it would be better if these commits ended up in the meta-intel/edison branch. It's generally what we do for poky.git and I'd like to keep meta-intel the same. Also,

Hi, I've created a new meta-intel/edison-next branch to hold commits intended for the upcoming 1.1 point release. I'll be collecting candidate commits for a 1.1 point release there until it's time

The commits in the doc should work - the SRCREV_machine is the last commit on the edison branch for yocto/standard/common-pc/atom-pc and the SRCREV_meta is also valid in edison, though in between the

That's a lot clearer now. So does this mean that If I'm working with edison branch, should I have to change the commits strings at all??? Because the commit strings from your cat'ing of the your

This is part of the confusion I mentioned about this section that needs to be cleaned up. Basically, for this example, to keep things simple, we want to use an already-existing branch in the repo.

... all of tom's stuff snipped ... ok, based on combining everything in the last several posts, my build for core-image-sato for the new "mymachine" bsp just finished successfully on my 64-bit

okay, what you mentioned as the steps below, I agree with, but a couple I don't understand. first, in the linux-yocto_3.0.bbappend file, why is the KMACHINE statement changed to common-pc/atom-pc? If

Right, not strictly needed, only for consistency, so the language should be softened, I agree. That is needed, but the steps that required editing files aren't easily captured in a transcript, so I

Fix the configure script to allow oprofile-server to be built standalone (without needing GTK+ and other X-requiring libraries) Signed-off-by: Paul Eggleton <paul.eggleton@...> ---

just to clarify any overlooked issues ... should one still change the NAME or DESCRIPTION comments in that new mymachine.conf file to reflect "mymachine" as the dev-manual suggests, or can one just