I'm good w/just using the main yocto list for now until traffic gets to a point we think it makes sense to split it off - k

Hmm, I completely forgot about that list, and apparently everybody else has too (no messages in it). It's also not linked to from anywhere on the Yocto site that I can see e.g. Community | Mailing

What I'm envisioning as a start is we'd offer a meta layer on yocto sites for the upstream supported boards & feature set. I'm still looking at what we do for a FSL delivered BSP (via freescale.com)

Ok, same model would work for meta-fsl-ppc. The one question I have is if it make sense to migrate such patches over to 'yocto-bsp@...' list. - k

So just to put what Bruce says into other words, there isn't any hard requirement to use linux-yocto but we are asking people to try it and if it doesn't work, at least tell us why. I understand

Hi Kumar, For meta-intel, it's pretty simple and is summarized by this blurb from the meta-intel MAINTAINERS file: "Please submit any patches against meta-intel BSPs to the Yocto mailing list

Hi Kumar, As you know, I've been working on several kernel efforts around the FSL parts as well (in particular the ones that have enough pieces upstream to work out of the box). I definitely don't

Maintainership would be straight forward. Not sure about submissions process, what is done for meta-intel today? BSP would be for Freescale PowerPC SoC and the reference designs produced by FSL for

This list is as good a place as any! :) Its relatively easy to arrange for a git repository. The main things we ask are that it has clearly defined maintainership (a clear maintainer and submission

Who is the best person to ask about adding new BSPs into yocto. What I mean by this is having a meta layer hosted on git.yoctoproject.org like meta-intel and the mechanics associated with this

A previous patch changed the default TERM to use xterm. This updates local.conf.sample to match the change Signed-off-by: Matthew McClintock <msm@...> --- meta-yocto/conf/local.conf.sample

Several builds are using perl on the host instead of perl built by poky. This fixes the issue for several packages. Signed-off-by: Matthew McClintock <msm@...> ---

Check the display setup. In my case, my old U-Boot (which works great) was using dvimode=1024x768-24@60 and the new U-Boot is using dvimode=1024x768MR-16@60 When I switch back to the old setting,

No, but I'll be testing out a new build soon -- haven't been able to for a bit. Yes -- Yocto/Poky/Sato vs. Angstrom. I doubt they're running the same version of U-Boot, but I don't know the version

Did you ever find out what is causing this? When you say that it works on one system (Poky?) vs another (Angstrom?) are they both running the same version of U-Boot? I'm seeing this same behaviour

From: Tom Zanussi <tom.zanussi@...> Switch sugarbay to the 3.0 kernel, lock it down, and update kernel SRCREVs. Signed-off-by: Tom Zanussi <tom.zanussi@...> ---

From: Tom Zanussi <tom.zanussi@...> Built and booted into sato - basic testing shows everything works as expected. The following changes since commit 96c247dad88b9fc0159b2a929216876d9fbb06dc:

Attendees: Saul, Tom, Paul, Jessica, Rahul, Koen, Joshua, Mark, Denys, Richard, Bruce, Song   Action Item List:

Hi, All This is the weekly test report for Yocto1.1 20110723 build. There is one new bug found. The qemuppc and qemumips images can not boot up due to kernel update to 3.0. Standby and I2C issue

All, We are pleased to announce the second milestone of the coming October release of Yocto 1.1. This milestone release is available