[oe] OE TSC Minutes: 30 January 2012

[Jeff Osier-Mixon]

OpenEmbedded Technical Steering Committee
30 January, 2012

Attending: Khem, Richard, Mark, Tom, Paul
Minutes: Jefro

1. pick a chair
Paul

2. new issues
   a. meta-oe organisation discussion
      too wide in scope, images that work with oe-core break with meta-oe
      discussion ongoing on mailing list
      Paul to ping Koen for feedback

   b. elections
      fray is next, RP will tickle board -> done

   c. distro features
      all to reply to paul's email
=>    Paul to file bug to implement distro features backfill
=>    Paul to file bug to implement psplash issue already discussed

   d. gitpkgv.bbclass merge
      good functionality, needs some work to be accepted

   e. meta-ti working with oe-core
      positive discussion on meta-ti list

3. TSC meetup at ELC
   jefro to set up breakfast Thurs morning 8am -> done
   NOTE: if members can't get there on time, can arrange a later session
=> bring thoughts to ELC for retrospective

4. Status report on oe-core
     better sstate reuse reported by Koen and others
=>   communicate to oe-core list in late Feb, agendize

5. Infrastructure
     melo has retired
     patchwork issues - less value for bitbake & oe-core

6. Action Review:
   Khem/Fray: Flagging on wiki for OE version
   Khem: OE default source mirror


Raw Transcript:


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

-- 
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel http://yoctoproject.org