<span class="Apple-style-span" style="border-collapse:collapse;color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px"><div>OpenEmbedded Technical Steering Committee</div><div>30 January, 2012</div><div><br></div>
<div>Attending: Khem, Richard, Mark, Tom, Paul</div><div>Minutes: Jefro</div><div><br></div><div>1. pick a chair</div><div>Paul</div><div><br></div><div>2. new issues</div><div> a. meta-oe organisation discussion</div><div>
too wide in scope, images that work with oe-core break with meta-oe</div><div> discussion ongoing on mailing list</div><div> Paul to ping Koen for feedback</div><div><br></div><div> b. elections</div><div>
fray is next, RP will tickle board -> done</div><div><br></div><div> c. distro features</div><div> all to reply to paul's email</div><div>=> Paul to file bug to implement distro features backfill</div>
<div>=> Paul to file bug to implement psplash issue already discussed</div><div><br></div><div> d. gitpkgv.bbclass merge</div><div> good functionality, needs some work to be accepted</div><div><br></div><div>
e. meta-ti working with oe-core</div><div> positive discussion on meta-ti list</div><div><br></div><div>3. TSC meetup at ELC</div><div> jefro to set up breakfast Thurs morning 8am -> done</div><div> NOTE: if members can't get there on time, can arrange a later session</div>
<div>=> bring thoughts to ELC for retrospective</div><div><br></div><div>4. Status report on oe-core</div><div> better sstate reuse reported by Koen and others</div><div>=> communicate to oe-core list in late Feb, agendize</div>
<div><br></div><div>5. Infrastructure</div><div> melo has retired</div><div> patchwork issues - less value for bitbake & oe-core</div><div><br></div><div>6. Action Review:</div><div> Khem/Fray: Flagging on wiki for OE version</div>
<div> Khem: OE default source mirror</div><div><br></div><div><br></div><div>Raw Transcript:</div><div> </div><div> </div>
<div>[17:07] --> You have joined the channel #oe-tsc (~paul@pdpc/supporter/professional/bluelightning).</div><div>[17:07] <fray> :)</div><div>[17:08] *** Channel modes: no colors allowed, no messages from outside, topic protection</div>
<div>[17:08] *** This channel was created on 14/02/2011 14:28.</div><div>[17:08] <RP__> bingo!</div><div>[17:08] <RP__> (full house)</div><div>[17:08] <bluelightning> sorry guys</div><div>[17:08] <khem> on agenda items I would like to add meta-oe organisation discussion</div>
<div>[17:08] <RP__> Jefro: has an agenda at <a href="http://pastebin.com/vef1520V" target="_blank" style="color:rgb(17,85,204)">http://pastebin.com/vef1520V</a></div><div>[17:08] <Jefro> khem: ok</div><div>[17:09] <RP__> we need someone with four legs?</div>
<div>[17:09] <Jefro> should we dive in? who wants to chair?</div><div>[17:09] <RP__> or alternatively, I like chesterfields (as a type of chair)</div><div>[17:10] * fray suggestions bluelightning </div><div>[17:10] <fray> suggests even</div>
<div>[17:10] <bluelightning> ok, I'll do it</div><div>[17:10] * Jefro notes bluelightning as taskmaster</div><div>[17:11] <bluelightning> ok, so we have Khem's item to add to the agenda</div><div>[17:12] <Jefro> bluelightning: agenda in brief: meta-oe, elections, distro features, tsc meetup, oe-core status, infrastructure, deferred items from last time</div>
<div>[17:12] <bluelightning> ok, let's discuss meta-oe then</div><div>[17:12] * RP__ had forgotten to ping the board but has done so now</div><div>[17:13] * Jefro marks that one "done"</div><div>[17:13] <bluelightning> I presume you all saw the discussion on the mailing list which I started?</div>
<div>[17:13] <fray> yes, I did not comment as I saw active participation from others (non TSC others)</div><div>[17:13] <RP__> bluelightning: which list?</div><div>[17:13] <fray> I have no additional comments, I think it looked good..</div>
<div>[17:13] <bluelightning> RP__: oe-devel</div><div>[17:13] <khem> so for experiment I added meta-oe to layers and did a core-image-sato build on oe-core and it did not boot where as pure oe-core works well</div>
<div>[17:13] <fray> (I assume this is the pulseaudio/distro features one correct?)</div><div>[17:14] <khem> fray: meta-oe seems to infringe too much into oe-core</div><div>[17:14] <bluelightning> <a href="http://article.gmane.org/gmane.comp.handhelds.openembedded/50131" target="_blank" style="color:rgb(17,85,204)">http://article.gmane.org/gmane.comp.handhelds.openembedded/50131</a></div>
<div>[17:14] <bluelightning> fray: no, this is another thing</div><div>[17:15] <fray> ohh, no I didn't see that one</div><div>[17:15] <khem> so there is a discussion to divide it down</div><div>[17:15] <bluelightning> khem: it's just an organisation issue as well as the general need to merge/justify items currently in there</div>
<div>[17:15] <fray> I saw the talk of the reorginization of meta-oe.. The original talk from last week was reasonable..</div><div>[17:15] <fray> it's an orginizational issues as well as a "we don't want that to become a dumping ground" issue</div>
<div>[17:15] <khem> yes, we need to reorganize the layer a bit so that it becomes a nicer addon</div><div>[17:16] <khem> and may be split it into different layers</div><div>[17:16] <fray> perhaps the answer is simply we need to keep re-evaluating it at release points of oe-core?</div>
<div>[17:16] <khem> I have locally moved toolchain bits into a separate layer</div><div>[17:16] <khem> fray: yes</div><div>[17:17] <bluelightning> I think that's a good idea</div><div>[17:17] <RP__> I am worried that images that work with oe-core, break with meta-oe</div>
<div>[17:17] <khem> right now it engulfs too much ranging from toolchains to bootloaders</div><div>[17:17] <bluelightning> indeed</div><div>[17:17] <RP__> Do we know why?</div><div>[17:17] <khem> its too wide in its scope</div>
<div>[17:18] <RP__> is the proposal one repo with different elements that can be added in or different repos?</div><div>[17:19] <RP__> I think I'd be in favour of splitting, if it remains one repo</div><div>
[17:19] <khem> one repo with different meta-*</div><div>[17:19] <khem> yes</div><div>[17:19] <RP__> that does seem reasonable given the different functionality areas identified</div><div>[17:19] <bluelightning> RP__: fine with one repo, just multiple layers</div>
<div>[17:19] <fray> multiple layers - one repository?</div><div>[17:19] <khem> I think we need to make meta-retired meta-extra meta-toolchain for sure</div><div>[17:20] <fray> i.e. you check out meta-oe -- and get meta-oe/meta-....</div>
<div>[17:20] <khem> no</div><div>[17:20] <fray> then the user can choose to include all of meta-oe or just components?</div><div>[17:20] <khem> meta-openembedded/meta-*</div><div>[17:20] <khem> fray: they will be independent layers</div>
<div>[17:21] <RP__> fray: I think khem means yes</div><div>[17:21] <fray> what I was thinking is if the bblayers includes meta-openembedded they would get all of the items.. otherwise they could selectively include just the bits they want</div>
<div>[17:21] <khem> just managed unders one repo meta-openemebedded like we do for meta-gnome etc.</div><div>[17:21] <bluelightning> fray: it could be set up to work that way but I'm not sure there's much value in it</div>
<div>[17:21] <khem> fray: meta-openembedded = repo</div><div>[17:21] <fray> ya, I think we're talking the same thing on the repo side..</div><div>[17:21] <khem> not layer</div><div>[17:21] <RP__> fray: bblayers needs a config file and I'm not sure we're tried the "all" approach you've described</div>
<div>[17:21] <fray> bluelightning value is that it doesn't change existing behavior.. but gives more flexibility</div><div>[17:21] <RP__> fray: it could probably be made to work but likely will confuse people</div>
<div>[17:21] <fray> RP__, I thought you could include other files within the one..</div><div>[17:22] <bluelightning> fray: meta-openembedded already consists of multiple layers, of which meta-oe is one (and the one we're discussing here)</div>
<div>[17:22] <fray> so the layers.conf of meta-openembedded would include the ones from the sub layers.. (maybe it's not that easy)</div><div>[17:22] <khem> I am seeing folks asking for recipes on yocto lists which are there in meta-oe</div>
<div>[17:22] <khem> but they can not use it easlity</div><div>[17:22] <fray> ahh, ok.. I understand</div><div>[17:22] <khem> since meta-oe will bring them more than what they need</div><div>[17:22] <bluelightning> yes, it's hard to recommend meta-oe as a layer just for the additional recipes right now</div>
<div>[17:22] <RP__> So why are we discussing this? Is the list at deadlock?</div><div>[17:22] <khem> correct</div><div>[17:22] <fray> what I've done before is pull just the recipes out of meta-oe I need, but I don't normally use the layer as-is</div>
<div>[17:23] <RP__> or did that thread reach a conclusion?</div><div>[17:23] <bluelightning> I'm not sure it is a deadlock</div><div>[17:23] <khem> its not deadlock,</div><div>[17:23] <RP__> the problem is a lack of conclusion?</div>
<div>[17:23] <khem> we need to find someone to look after new layers</div><div>[17:23] <RP__> I'm trying to figure out what our role as the TSC is here</div><div>[17:24] <bluelightning> the thread has largely petered out, but I did not see a response from the current meta-oe maintainer</div>
<div>[17:24] <bluelightning> perhaps I should ping koen</div><div>[17:24] <khem> yes</div><div>[17:24] <RP__> bluelightning: do that and see where we're at</div><div>[17:24] <bluelightning> ok</div>
<div>[17:24] <-- Jefro has left this server (Ping timeout: 240 seconds).</div><div>[17:24] --> Jefro__ has joined this channel (43cb5922@gateway/web/freenode/session).</div><div>[17:24] <Jefro__> sorry all - I'm back now</div>
<div>[17:25] <-- Jefro__ has left this server (Changing host).</div><div>[17:25] --> Jefro__ has joined this channel (43cb5922@gateway/web/freenode/ip.67.203.89.34).</div><div>[17:25] <bluelightning> let's move onto the next item.. elections</div>
<div>[17:25] <khem> ok move on</div><div>[17:25] <fray> I'm up next, RP pinged.. anything else?</div><div>[17:25] <RP__> btw, on a related note, I should give the group a heads up on a discussion on #yocto with otavio recently</div>
<div>[17:26] <khem> RP__: on what topic</div><div>[17:26] <RP__> he wanted to merge gitpkgv.bbclass into oe-core as is. I suggested that some of it should really be integrated with the bitbake fetcher first</div>
<div>[17:26] <bluelightning> ok sounds like the elections issue is done, so let's cover that now</div><div>[17:26] <RP__> He is rather unhappy about this and wants to do that "later"</div></span><span class="Apple-style-span" style="border-collapse:collapse;color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">[17:27] <RP__> He is going to bring this up on the mailing list and if I maintain my stance, probably bring to the TSC</span><span class="Apple-style-span" style="border-collapse:collapse;color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px"><div>
[17:27] <fray> I think it's reasonable for him ot bring it up and do it that way..</div><div>[17:27] <khem> but I think its good idea to have gitpkgv as a functionality</div><div>[17:27] <fray> I'm not familiar with the actual implementation though..</div>
<div>[17:27] <bluelightning> RP__: he did post the patch FYI, not sure if you saw it</div><div>[17:27] <RP__> bluelightning: ok, I need to give feedback then</div><div>[17:28] <RP__> I agree its good functionality, I just think it should be adapted to fit into the fetcher cleanups and other work being done to improve things in OE-Core</div>
<div>[17:28] <khem> RP__: nod</div><div>[17:28] <bluelightning> so onto the next issue - distro features</div><div>[17:28] <RP__> fetcher functionality in one place with a standardised API is a good thing IMO</div>
<div>[17:28] <bluelightning> I agree</div><div>[17:29] <khem> RP__: yes fetchers is right place</div><div>[17:29] <RP__> I just wanted to bring this up here since I suspect there will be some friction</div>
<div>[17:29] <fray> just to verify, point of the code is a smaller (more simpl) PV right?</div><div>[17:29] <RP__> fray: yes</div><div>[17:29] <RP__> bluelightning: where is that at now?</div><div>[17:29] <fray> ok.. I've heard of a lot of requests for that from coworkers.. ;)</div>
<div>[17:30] <RP__> fray: well, its a smaller PV in the output packages</div><div>[17:30] <RP__> fray: The PV used in the build system is still long</div><div>[17:30] <bluelightning> RP__: waiting for "someone" (probably me) to implement it as discussed I think</div>
<div>[17:30] <fray> yes.. thats what people have requested from me before.. (they don't care so much about the internal values)</div><div>[17:30] <RP__> bluelightning: that's what I thought</div><div>
[17:30] <fray> but I agree, start with the fetcher and work toward the package creation is the best approach..</div><div>[17:31] <bluelightning> AR to me - file a bug to implement distro features backfill</div>
<div>[17:31] * Jefro__ notes bluelightning </div><div>[17:31] <bluelightning> another AR - file a bug to implement psplash issue discussed 2 meetings ago as well</div><div>[17:31] <bluelightning> (also to me)</div>
<div>[17:31] <fray> Ahh I thought that had been done already.. :)</div><div>[17:32] * RP__ would like to note for the record the positive thread on the meta-ti list about their layer working with OE-Core and not depending on meta-angstrom/meta-oe</div>
<div>[17:32] <bluelightning> yes, I'm very happy to hear that's being worked on</div><div>[17:32] <RP__> that would be nice progress towards the layer model really starting to work</div><div>[17:33] <fray> very cool..</div>
<div>[17:33] * RP__ thought it worth acknowledging here :)</div><div>[17:33] <bluelightning> ok, let's move onto "TSC meetup"</div><div>[17:33] <khem> yes indeed</div><div>[17:33] <Tartarus> ELC, I'll be there, not for yocto dev day tho</div>
<div>[17:33] <Tartarus> iirc the invite went out for the 15th, AM tho, yes?</div><div>[17:34] <RP__> None of these things made my calender :(</div><div>[17:34] <fray> I'll be at ELC for Yocto Dev Day (Tuesday) through Friday</div>
<div>[17:34] * RP__ notes to self to import them</div><div>[17:34] * bluelightning won't be there but has confirmed the TSC meeting invite assuming teleconf availability</div><div>[17:35] * RP__ will be there Tue-Fri</div>
<div>[17:35] <khem> I am registed starting yocto dday</div><div>[17:36] <RP__> Anything specific we need to discuss?</div><div>[17:36] <Jefro__> you should have a calendar invitation for Weds morning 8am, and I have a room reserved. we can meet earlier for a full breakfast if there is the desire to do so.</div>
<div>[17:36] <fray> Unlike last year, I can't think of anything other then normal meeting stuff..</div><div>[17:36] <Tartarus> I'll probably be there right around 8, depending on airport shuttle, etc</div>
<div>[17:36] <Tartarus> iirc I land 7:15a or so</div><div>[17:36] <fray> if we do want to work on rearranging meta-oe, it might make sense towork on it in person</div><div>[17:37] <khem> I will try to be there by 8 traffic permitting</div>
<div>[17:37] * RP__ will be there by 8 or earlier depending on the jetlag</div><div>[17:37] * RP__ suspects he could make 5 quite easily :/</div><div>[17:37] <khem> heh</div><div>[17:38] <fray> :)</div><div>[17:38] <khem> 5a will be a bit late for me :)</div>
<div>[17:38] <RP__> A kind of retrospective might be useful</div><div>[17:38] <Jefro__> there will be a continental breakfast for those who can eat at the crack of 8</div><div>[17:38] <Jefro__> continental lunch for RP</div>
<div>[17:38] <RP__> What is going well and anything we need to improve</div><div>[17:38] <RP__> Jefro__: :)</div><div>[17:39] <khem> RP__: yes. and any new ideas</div><div>[17:39] <RP__> A lot has happened in the last 18 months :)</div>
<div>[17:39] <khem> RP__: per recipe sysroots e.g. :)</div><div>[17:39] <RP__> khem: there is an ehancement bug for it</div><div>[17:40] <RP__> but it would be good to discuss priorities and so on</div><div>
[17:40] <fray> ya.. I think a recap would be good for the year.. do we have any obligation (or desire) to report to the board/e.V. members what we as the TSC have done/observed for the past year?</div><div>[17:40] <khem> RP__: I would like to see a meta-benchmark</div>
<div>[17:40] <RP__> fray: we have no obligation but nothing to stop us either</div><div>[17:40] <fray> ok.. might be worth us doing...</div><div>[17:40] <bluelightning> khem: feel free to tack that onto the mailing list discussion, there's already recipes-benchmark in meta-oe</div>
<div>[17:40] <fray> bullet points, that kind of thing..</div><div>[17:41] <RP__> AR: Everyone: To bring thoughts to ELC</div><div>[17:41] <fray> yup</div><div>[17:41] <bluelightning> ok, shall we move onto OE-core status?</div>
<div>[17:41] <khem> ok</div><div>[17:42] <RP__> we're pretty green onmaster</div><div>[17:42] <RP__> proposed patches have thrown up regressions so we're trying to fix before merging</div><div>[17:42] <RP__> fixed some nasty useradd+sstate issues last week</div>
<div>[17:42] <RP__> also finally got to the bottom of the machine switching sstate issue</div><div>[17:42] <fray> RP__ the fix was before or after the version bump on bitbake (requires version)</div><div>[17:43] <fray> ?</div>
<div>[17:43] <RP__> Koen+Martin have reported better sstate reuse now</div><div>[17:43] <bluelightning> RP__: excellent!</div><div>[17:43] <khem> I am working on kmod in hiatus</div><div>[17:43] <RP__> fray: after</div>
<div>[17:44] <khem> RP__: I have used sstate quite a bit now its been decent on me</div><div>[17:44] <RP__> khem: great :)</div><div>[17:44] <khem> I actually keep *native* and *cross*</div><div>[17:44] <khem> and delete everything</div>
<div>[17:45] <RP__> Its taking some work but I think its really starting to help</div><div>[17:45] <khem> that just builds the target bits quite fast</div><div>[17:45] <RP__> any questions/concerns on oe-core?</div>
<div>[17:45] <khem> RP__: I wish if I could tell category of recipes to rebuild even when using sstate</div><div>[17:46] <RP__> khem: based on what?</div><div>[17:46] <khem> RP__: may be recipe names</div>
<div>[17:46] <RP__> khem: you can invalidate the sstate cache in interesting ways by changing the checksums</div><div>[17:46] * Jefro__ says time check: 15 mins left</div><div>[17:46] <RP__> khem: you know about -c cleansstate</div>
<div>[17:46] <khem> RP__: yes</div><div>[17:47] <khem> RP__: I guess its not that urgent of a need since stuff I do is not common anyway</div><div>[17:48] <Jefro__> RP__ question - how much of this behavior is documented?</div>
<div>[17:48] <RP__> Jefro__: everything I've talked about</div><div>[17:48] <RP__> Jefro__: I worked with Scott to document sstate</div><div>[17:48] <Jefro__> ok, cool - in yocto docs? will oe folks think to look there?</div>
<div>[17:48] <khem> someone should summarize sstate in detail if not yet done in wiki</div><div>[17:49] <khem> how to use it and how to not use it. etc.</div><div>[17:49] <RP__> khem: its in the manuals</div>
<div>[17:49] <khem> ok</div><div>[17:49] <RP__> khem: based on an email from me</div><div>[17:49] <RP__> so the docs are out there for anyone to find</div><div>[17:49] <RP__> Jefro__: I'd hope they would</div>
<div>[17:50] <RP__> Jefro__: At this point its the most complete manual set on the subject</div><div>[17:50] <bluelightning> ok, remaining issues are "infrastructure" and deferred items from last time ("Flagging on wiki for OE version", "OE default source mirror")</div>
<div>[17:50] <bluelightning> shall we try to cover those in 10mins?</div><div>[17:51] <khem> both my ARs are still open</div><div>[17:51] <RP__> I'm not sure there is much to cover about infrastructure</div>
<div>[17:51] <khem> not much but old melo has retired</div><div>[17:52] <khem> on patchwork I think with bitbake there is a problem</div><div>[17:52] <khem> since it catches bitbake-devel ml and commit mails also go to bitbake-devel</div>
<div>[17:52] <khem> it catches the patches both the times</div><div>[17:53] <khem> it is preferred to have commit mail be sent to bitbake-devel ?</div><div>[17:53] <fray> Hmm.. patchwork doesn't have a way to determine it's the same patch?</div>
<div>[17:53] <khem> fray: no</div><div>[17:53] <khem> although it would be neat</div><div>[17:54] <khem> but there is patch and then commits etc.</div><div>[17:54] <fray> ok.. for some reason I thought it kept an md5sum or something of the patch and used that to correlate original patches and updates..</div>
<div>[17:54] <RP__> Part of the problem is likely that some of us send bitbake patches with a path prefix of bitbake/</div><div>[17:54] <khem> fray: well yes but in this case mail is sent after the patch has been closed</div>
<div>[17:54] <fray> Ahh I see.. ok</div><div>[17:54] <RP__> I just strip it off but it probably confuses patchwork</div><div>[17:55] <fray> would it be possible to tag the patches from Saul/RP that are integration patches (vs original work) and blacklist them?</div>
<div>[17:55] <bluelightning> just filter out "CONSOLIDATED PULL" ?</div><div>[17:56] <bluelightning> I think he always includes that in the subject of 0/x at least</div><div>[17:56] <fray> thats kind of what I was thinking</div>
<div>[17:56] <khem> actually there is less value for bitbake and oe-core in patchwork</div><div>[17:56] <khem> only people refer to them sometimes</div><div>[17:56] <bluelightning> well, oe-core is not handled at all and that means it's full of old patches</div>
<div>[17:56] <khem> only meta-oe uses it effectively to manage patches we can even turn it off for bb and oe-core</div><div>[17:57] <fray> ya, sounds like we either need to filter it for consolidated pulls -- or simply avoid the issue by turning it off as khem says..</div>
<div>[17:58] <khem> I guess I can ask the ml and get opinions on having pw turned on for bb and oe-core</div><div>[17:58] <fray> I don't see a lot of references in the mailing list ot patchwork (for oe-core)..</div>
<div>[17:58] <khem> fray: yes its occasional</div><div>[17:58] <khem> on IRC etc.</div><div>[17:58] <fray> ahh ok..</div><div>[17:59] <fray> I'd sugges tthen we start with the filter approach, and if that doesn't work try something else.. I assume it uses something like procmail to get access to the mail messages..</div>
<div>[17:59] <fray> if so we should be able to filter certain emails easily.. if not, I'm not sure</div><div>[17:59] <khem> I think its useless if its not used there is no point in tracking the patches</div>
<div>[17:59] <RP__> The workflow I've been using doesn't use patchwork</div><div>[17:59] <fray> I think it all comes down to member usage.. if people want to use it, and we can support it.. we should..</div>
<div>[17:59] <khem> but if people think its so critical we can keep it</div><div>[17:59] <khem> RP__: yes thats why</div><div>[18:00] <fray> but we don't current use it -- so in that case, if it's not useful we just disable it</div>
<div>[18:00] <khem> yes</div><div>[18:00] <bluelightning> khem: if we had the commit hook it would be useful so that missed patches can at least be viewed</div><div>[18:00] <bluelightning> otherwise it's more or less worthless</div>
<div>[18:00] <fray> I have no objection to removing it from oe-core/bb other then oe users who want it</div><div>[18:00] * RP__ has pretty good records of missed patches :/</div><div>[18:00] <khem> bluelightning: the way patches flow in ml its hard</div>
<div>[18:01] <RP__> its why my inbox is growing out of control :(</div><div>[18:01] * bluelightning did not mean to cast any aspersions</div><div>[18:01] <khem> since patches go into ml and then Saul picks them and resends them to same ml</div>
<div>[18:01] <khem> its a bit not pw like</div><div>[18:01] <bluelightning> fair enough, if the tool doesn't really work there's not much point in keeping it</div><div>[18:02] <khem> I would think so</div>
<div>[18:02] <bluelightning> I think we have a standing order to evaluate patchwork and tools like it but we haven't got to that yet</div><div>[18:02] <khem> we can keep it only for meta-oe</div><div>[18:02] <khem> since thats handling the patches with it</div>
<div>[18:03] <bluelightning> plus any other layer that uses oe-devel ml for patches (I use it for meta-handheld / meta-opie FWIW)</div><div>[18:03] <bluelightning> or rather, I keep it up-to-date for those layers</div>
<div>[18:03] <khem> yes infact any patches that go into oe-devel are groked</div><div>[18:04] * RP__ needs to go I'm afraid</div><div>[18:04] <RP__> I think we're pretty much done anyway</div><div>[18:04] <RP__> ?</div>
<div>[18:04] <khem> btw. Phil mentioned this on IRC that yocto point to <a href="http://oe.org/" target="_blank" style="color:rgb(17,85,204)">oe.org</a> to obtain sources probably it should use github mirror addy</div>
<div>[18:04] <fray> ya, I think we are..</div><div>[18:05] <bluelightning> I think we've covered our agenda at least</div><div>[18:05] <khem> yes</div><div>[18:05] <khem> adjourned</div><div>[18:05] <fray> khem, I thought that pointer from yocto to <a href="http://oe.org/" target="_blank" style="color:rgb(17,85,204)">oe.org</a> was deliberate, as Yocto is based on oe-core, and OE board? has input into Yocto.. (i.e. consider it joint marketing?)</div>
<div>[18:06] <khem> fray: he meant for git</div><div>[18:06] <Jefro__> cool - could someone please send me the full transcript?</div><div>[18:06] <bluelightning> Jefro__: yep I can do that</div><div>[18:06] <Jefro__> bluelightning thanks</div>
</span><div><br></div>-- <br>Jeff Osier-Mixon <a href="http://jefro.net/blog" target="_blank">http://jefro.net/blog</a><div>Yocto Project Community Manager @Intel <a href="http://yoctoproject.org" target="_blank">http://yoctoproject.org</a></div>
<br>