<span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><div>OpenEmbedded Technical Steering Committee Minutes, F2F meeting April 10 2011</div><div>12:00pm - 5:00pm</div>
<div><br></div><div>OE-TSC Attendees:</div><div>Tom Rini (Tartarus)</div><div>Richard Purdie (RP)<br>Khem Raj (khem)</div><div>Koen Kooi (koen)</div><div>Mark Hatle (fray)</div><div><br></div><div>Other Attendees:</div><div>
Denys <span style="font-family: arial, sans-serif; line-height: 15px; ">Dmytriyenko (denix) - OE board</span></div><div><span style="font-family: arial, sans-serif; line-height: 15px; ">Jeff Osier-Mixon (jefro) - secretary</span></div>
<div><span style="font-family: arial, sans-serif; line-height: 15px; "><br></span></div><div>_____________________________________________________________</div><div>Agenda & Action Items</div><div><br></div><div>Note: This was a working meeting rather than a regular status meeting.</div>
<div><div><br></div><div>* BBCLASS_EXTEND and .inc files don't work well with the layer approach</div></div><div><div>==> document, explain why bad idea, don't want to do for x reasons</div></div><div><br></div>
<div><div>* Import xorg structure from OE .dev into meta-oe</div></div><div><div><br></div><div>* Task-boot in meta-angstrom is fit for meta-oe</div></div><div><div><br></div><div>* Angstrom-core-tweaks seems for meta-oe as well</div>
</div><div><div>==> action item for khem - please use LIBC rather than ANGSTROMLIBC</div></div><div><br></div><div><div>* Global poky files need improvement:</div></div><div><div>=> on yocto 1.1 plan - action - document, take action for october (oe-core)</div>
<div><br></div><div>* patchwork instance for layers (e.g. meta-oe/meta-efl/meta-angstrom) & pull requests, need to track</div></div><div><br></div><div><div>* infrastructure</div><div>* Yocto steering group discussion summary (inc BSPs + interest groups)</div>
</div><div><div>==><span style="white-space: pre-wrap; "> </span> //> collaborative charter with Yocto Project</div></div><div><div>==> //> create clearinghouse for bsps/layers & set of mgmt policies (fray) + mirroring</div>
<div>==><span style="white-space: pre-wrap; "> </span> //> denix - clause in contact that oe owns their set of data</div><div>==><span style="white-space: pre-wrap; "> </span> //> rp -> denix: talk to LF to sort infrastructure hosting details</div>
</div><div><br></div><div><div>* Layer tooling brainstorming</div></div><div>==> RP improve addhandler functionality in bitbake to list relative events</div><div><br></div><div>* layer creation tools</div><div><div>==> already works in layer.conf, need documentation</div>
<div><br></div><div>* OECore branding</div></div><div><div><br></div><div>* config options</div></div><div><div><br></div><div>* multilibs</div></div><div>==> continue any discussion needed on ml</div><div><br></div><div>
<div><br></div></div><div>* fixing local.conf</div><div><div><div><div>==> document bbmask</div><div>==> simplify local.conf.sample</div></div><div><br></div><div>other:</div><div>==> getting rid of poky name: poky -> core</div>
</div></div><div><br></div><div>_____________________________________________________________</div><div>Raw notes</div><div><br></div><div>Martin raised some points we should discuss:</div><div><br></div><div>* BBCLASS_EXTEND and .inc files don't work well with the layer approach</div>
<div>// can't do bb append into a .inc file</div><div>// painful to append to a .inc file</div><div>// also bbclass files</div><div>// rp - natural pressure to share core files</div><div>==> document, explain why bad idea, don't want to do for x reasons</div>
<div><br></div><div>* Import xorg structure from OE .dev into meta-oe</div><div>// xserver-xorg, x11 - need to synchronize</div><div>// lots of recipes, need to share common files</div><div>// defer to hackathon session later in evening</div>
<div>// fray working on as part of yocto - synch bits in meta-oe with oe-core</div><div>// koen - import from dev</div><div><br></div><div>* Task-boot in meta-angstrom is fit for meta-oe</div><div>// koen already moved to meta-oe</div>
<div>// defer to hackathon</div><div><br></div><div>* Angstrom-core-tweaks seems for meta-oe as well</div><div>==> action item for khem - please use LIBC rather than ANGSTROMLIBC</div><div>// oe-core may be missing this bit (Tartarus)</div>
<div>// RP suggests : core distro include file "shared libcs" to share libcs within same work dir</div><div>// RP contintued: with specific include file</div><div>// defer implementation to hackathon</div><div><br>
</div><div>* Global poky files need improvement:</div><div>// <JaMa|Wrk> and on ELC meetup, when doing oe-core rebranding, please raise my concern about </div><div>// couple of global poky files, like SRCREVs etc.. I really hate</div>
<div>// openembedded-core/meta/conf/distro/include/poky-default-revisions.inc file included directly </div><div>// from layer.conf as SRCREV_pn-u-boot ??= "v2010.12" there is harder to overwrite from own </div><div>
// u-boot recipe (SRCREV_pn-u-boot works, SRCREV itself doesn't ofc), but enduser will be</div><div>// confused for sure when most recipes have just SRCREV and sometimes it's not enough</div><div><br></div><div>// rp doesn't disagree, but some use case breaks - bb keeps src rev stuff in core config context</div>
<div>// doesn't know about src rev until passing individual recipe</div><div>// mismatch between recipes</div><div>// teach core about revs in individ. recipes, missing code to do this atm</div><div>// bitbake problem</div>
<div>// can add SRC_REV to bbcache but validation timing is at issue wrt cache</div><div>// rp can solve in layers</div><div>// fray: want to get rid of, but must cope with corner cases</div><div>=> on yocto 1.1 plan - action - document, take action for october (oe-core)</div>
<div><span style="white-space: pre-wrap; "> </span></div><div>* patchwork instance for layers (e.g. meta-oe/meta-efl/meta-angstrom) & pull requests, need to track</div><div>// manual intervention needed, need to automate as much as possible</div>
<div>// education issue</div><div>// alternatives are expensive</div><div>// rp first thing, improve hooks</div><div>// go for net improvement (koen) - can include items in patchwork, find individual to monitor </div><div>
// need janitors - koen doing some of this</div><div>// where to put patchwork instance? all on oe currently, falls to oe maintainers</div><div>// koen - <a href="http://patchwork.kernel.org/" target="_blank" style="color: rgb(0, 0, 204); ">patchwork.kernel.org</a> ?</div>
<div>// ** also see infrastructure discussion</div><div><br></div><div>infrastructure</div><div>// resources constrained, but political pressure to keep inside OE</div><div>// rather than depend on corporate support from any corp sponsor</div>
<div><br></div><div><br></div><div>* Yocto steering group discussion summary (inc BSPs + interest groups)</div><div>// don't want manuf bsps hosted on oe - yocto ok, i.e. beagleboard ok, ti boards not ok</div><div>// nor confusion of one manuf saying "this is official for x board"</div>
<div>// can work with yocto to provide hosting for some</div><div>// koen - layers promote silo mentality - hosting elsewhere promotes that mentality</div><div>// rp - if layers spread across infrastructures, hard to see what is there already</div>
<div>// rp - this is why <a href="http://git.yoctoproject.org/" target="_blank" style="color: rgb(0, 0, 204); ">git.yoctoproject.org</a> set up for many repos</div><div>// tartarus - having mirrors only solves the problem once it exists</div>
<div>// koen - want to promote cooperation, oe board should not tell corps to get lost</div><div>// rp - layers have specific owners, koen - if layer owner disappears, oe can deprecate/mark read-only</div><div>// rp - readonly mirror is not a fork</div>
<div>// koen - tsc can resolve a namespace conflict, has charter that covers infrastructure</div><div>// koen re hosting "yes, but", not "no, unless"</div><div>// fray - layers are a planned way to cope with distribution (layers vs repos)</div>
<div><br></div><div>multilayer problem:</div><div> community issues:</div><div> political inside OE</div><div> political with corporations</div><div><span style="white-space: pre-wrap; "> </span>integration with yocto</div>
<div>==><span style="white-space: pre-wrap; "> </span> //> collaborative charter</div><div> technical:</div><div> infrastructure <span style="white-space: pre-wrap; "> </span>- immediate</div><div><span style="white-space: pre-wrap; "> </span> hardware, admin</div>
<div>==> //> create clearinghouse for bsps/layers & set of mgmt policies (fray) + mirroring</div><div>==><span style="white-space: pre-wrap; "> </span> //> denix - clause in contact that oe owns their set of data</div>
<div>==><span style="white-space: pre-wrap; "> </span> //> rp -> denix: talk to LF to sort infrastructure hosting details</div><div><br></div><div>* Layer tooling brainstorming</div><div>// problems today - khem : abi fray: dependencies & versioning, latter no way to specify</div>
<div>// rp have something but very basic</div><div>// fray would like to see layer file, specify url & download layer as a step - possible? desirable?</div><div>// denix - 2 yrs ago trying to enable devteams, update recipes with new versions</div>
<div> instead of making changes in mainline (arago) used recipe specified default version,</div><div><span style="white-space: pre-wrap; "> </span>in component specific branches have config file, pokes values into recipe</div>
<div><span style="white-space: pre-wrap; "> </span>offload recipe updating to the teams, build from internal URL without churning mainline</div><div><span style="white-space: pre-wrap; "> </span>BOM into one config file, create BOM layers for products</div>
<div><span style="white-space: pre-wrap; "> </span>easy to implement, nothing in core infrastructure changed</div><div> fray: wget clones repos until pulled entire tree</div><div> desired: config file to be just downloaded, script to pull layer stuff</div>
<div><span style="white-space: pre-wrap; "> </span>knows that if I ran this, here is where everything went</div><div><span style="white-space: pre-wrap; "> </span>khem: submodules? fray: problem</div><div> koen: want something like that but not actual submodules</div>
<div> fray: ok when want to be locked to version, suck when don't</div><div> mostly want version of some branch</div><div> denix: mvl6 pull compressed layers from different places (single server)</div><div> rp : mv has bitbake run bitbake denix: collections</div>
<div> fray: bitbake fetcher works</div><div> rp: variety of higher level tooling doesn't belong in bitbake - eg qemu, pseudo</div><div> seem to develop more use cases where we need something above bitbake</div>
<div><span style="white-space: pre-wrap; "> </span>fray: as we move fwd, need stage1 then auto downloads of collective data</div><div><span style="white-space: pre-wrap; "> </span> large things</div><div><span style="white-space: pre-wrap; "> </span> have components to do downloads, but no way to structure right now</div>
<div><span style="white-space: pre-wrap; "> </span> have to do this, but lower priority</div><div> rp: leave provisioning for later</div><div><span style="white-space: pre-wrap; "> </span>fray: roadmap item</div><div><span style="white-space: pre-wrap; "> </span>fray: missing sanity checks specific to a layer</div>
<div><span style="white-space: pre-wrap; "> </span>rp: some checks on yocto 1.1 roadmap</div><div><span style="white-space: pre-wrap; "> </span>kk: config file to fetch layers, simple format</div><div><span style="white-space: pre-wrap; "> </span> fray: dependency reordering</div>
<div><span style="white-space: pre-wrap; "> </span>rp: visualizing dependencies between layers</div><div><span style="white-space: pre-wrap; "> </span>fray: flatten tool -> single layer, flattened model</div><div><span style="white-space: pre-wrap; "> </span> tar: should be able to do with something chris published before leaving mv</div>
<div><span style="white-space: pre-wrap; "> </span> may be a virtual flatten</div><div><span style="white-space: pre-wrap; "> </span>(kk: fuse filesystem?)</div><div><span style="white-space: pre-wrap; "> </span>rp: create effective layer repos: layer repo tools to merge layers into a repo, or</div>
<div><span style="white-space: pre-wrap; "> </span> separate respective patches to upstream repos</div><div><span style="white-space: pre-wrap; "> </span>pedigree - genealogy of a layer</div><div><span style="white-space: pre-wrap; "> </span>kk: note deviations from default</div>
<div><span style="white-space: pre-wrap; "> </span> output variable state against given recipe, refer to what pulling in (-e on steroids)</div><div><span style="white-space: pre-wrap; "> </span>additional information inside layers: pedigree, where maintained, which rev</div>
<div><span style="white-space: pre-wrap; "> </span>top of bitbake output, banner that summarizes build - add revisions for each layer</div><div><span style="white-space: pre-wrap; "> </span> addhandler improvement - layer fingerprint </div>
<div><span style="white-space: pre-wrap; "> </span> </div><div>==> RP improve addhandler functionality in bitbake to list relative events</div><div><span style="white-space: pre-wrap; "> </span>currently every handler receives every event - performance issue</div>
<div><span style="white-space: pre-wrap; "> </span>have handlers optionally specify which events to receive</div><div><span style="white-space: pre-wrap; "> </span></div><div><span style="white-space: pre-wrap; "> </span>fray: user's build directory is a layer in wrl</div>
<div><span style="white-space: pre-wrap; "> </span> also "make export" layer</div><div><span style="white-space: pre-wrap; "> </span> very handy for prototyping</div><div><span style="white-space: pre-wrap; "> </span> rp: technically already is, but missing "make export"</div>
<div><span style="white-space: pre-wrap; "> </span> //> verify build dir does act as layer, figure out export tooling</div><div><br></div><div>layer creation tools</div><div> fetching</div><div> easy tool to integrate sstate cache?</div>
<div>==> already works in layer.conf, need documentation</div><div> list of layers constructed from, top layer/bottom layer</div><div> unique id or uses filepath</div><div> internal recipe variable so a component can use it </div>
<div> tool to show recipes shadowing each other</div><div> </div><div>==> continue tooling discussion on ml</div><div><br></div><div>rp: implementation - effective way to create new tooling</div><div> git submodules, repo, "um waitwait..."</div>
<div> fray: reality is people will choose own ways</div><div> khem/rp: have to set own path</div><div> rp: agree to create higher level tooling? tartarus: yes, want to hear real proposal</div><div> look at git submodules, look at repo, but do our own thing</div>
<div> fray: build in discrete stages </div><div> 1 - set up environment</div><div><span style="white-space: pre-wrap; "> </span>2 - download & set up tools, layers</div><div><span style="white-space: pre-wrap; "> </span>3 - ...</div>
<div><span style="white-space: pre-wrap; "> </span>4 - other tools</div><div><span style="white-space: pre-wrap; "> </span>5 - now have everything, run build user asked for</div><div> multiple (recursive?) layers</div><div>
</div><div><br></div><div>* OECore branding</div><div> I'd also like to touch on the various major changes we're thinking about</div><div> for Yocto 1.1 (multilib, config options) and see if there is anything at</div>
<div> the TSC/architecture level we should be touching upon. There are</div><div> proposals on the mailing list about these now.</div><div><br></div><div><br></div><div><br></div><div>* config options</div><div> binary only, package config options, rocket cows (koen)</div>
<div> koen: cascading of changes up the trees, e.g. gcc r4 to r5, dependencies automatically updated</div><div> fray: checksums in wrl</div><div> tar: make moderately painful to add new flags</div><div> fray: flags when defined need defined states</div>
<div> rp: what are criteria for having flags in the first place</div><div> denix: gentoo has local use flags vs global, we are discussing global</div><div> not implement package-specific? fray: generally yes</div><div>
machine feature</div><div> fray: trying to make policy dynamic: system vs package vs machine</div><div> denix: if flag touches 5 or more different recipes.. rp suggests 8 fray: even #</div><div> rp - distro specific thing, e.g. yocto doesn't get rid of x, user can</div>
<div> fray: define default answer, or distro defined?</div><div> oe-core shouldn't require a distro file to be present</div><div> default in most cases is on</div><div> can only provide sane defaults for flags in main layer</div>
<div> complain about flags used but not defined</div><div> avoid bb multistate flags</div><div> avoid arbitrary values</div><div> distro features already binary only</div><div> fray: distro flags part of hash</div>
<div> rp: checksum of distro features variable (denix: sort before hashing)</div><div><span style="white-space: pre-wrap; "> </span></div><div><span style="white-space: pre-wrap; "> </span></div><div>* multilibs</div><div>
all agree that multilib needs to not hinder the non-multilib case</div><div>==> continue any discussion needed on ml</div><div>Minutes</div><div> </div><div>fray: will have a way to separate layer oe-core layers out, but don't have it today</div>
<div> move meta-demo to yocto.. meta-rt stays for now, becomes a seperate repository/layer in the future</div><div><br></div><div>==> getting rid of poky name: poky -> core</div><div><br></div><div>distro conf file included or not? sane defaults to allow to run with no distro</div>
<div>rp: propose to keep yocto config in sync with oe-core amap </div><div> keep defaults matching</div><div> implicitly agree</div><div><br></div><div>rp: poky.lsb override becomes linuxstandardbase</div><div> flag becomes override as well</div>
<div> in distrofeatures becomes override</div><div><br></div><div>pokyimage.bbclass can become coreimage.bbclass</div><div>longer term, merge in</div><div><br></div><div>tasks -> core</div><div><br></div><div>fixing local.conf</div>
<div>==> document bbmask</div><div>==> simplify local.conf.sample</div><br><font color="#888888">-- <br>Jeff Osier-Mixon <a href="http://jefro.net/blog" target="_blank" style="color: rgb(0, 0, 204); ">http://jefro.net/blog</a><div>
Yocto Project Community Manager @Intel <a href="http://yoctoproject.org/" target="_blank" style="color: rgb(0, 0, 204); ">http://yoctoproject.org</a></div><div><br></div></font></span>