=== robbiew is now known as robbiew_ === emma_ is now known as emma [10:02] hi [10:02] persia, elky, lifeless, Hi [10:03] Oh ok! [10:03] Hey [10:03] lifeless: you there? [10:04] perhaps s: [10:04] :P [10:04] quorum! [10:04] Hey folks,. [10:04] TheMuso, Hi [10:05] i see no duluu [10:05] om26er, Hi [10:05] There's an om26er_ though. Shall we start? [10:05] amachu, hello [10:05] sure lets go [10:06] elky, yep [10:06] om26er, please introduce yourself [10:07] elky, my name is omer akram I live in pakistan spend most of the time at launchpad I am 19 [10:07] om26er_, what do you do on launchpad? [10:07] I very much enjoy triaging [10:08] elky, triage bugs for empathy, gwibber indicator-* a bit software center etc [10:09] Before coming to triaging I used to help people at #ubutnu [10:10] om26er_, are you part of Ubuntu Pakistan Loco? [10:11] amachu, no I just joined the team, [10:11] actually people here use computer in english [10:11] om26er_, just? How long? [10:11] om26er_, there's still things locos can do even in english-using places. === Tonio__ is now known as Tonio_ [10:12] the ubuntu-pk channel only have a few people there [10:12] om26er_, well more now that you're there ;) [10:12] hi all [10:13] freeflying, welcome [10:13] elky: thx [10:14] lifeless: persia, TheMuso, questions for om26er_? [10:14] no [10:15] do you have anyone here to cheer for you? [10:15] om26er_: Your wiki page has no testimonials. Have you tried to solicit some from fellow triagers? [10:16] persia, I am a little shy in that area [10:17] om26er_, i'm sure we could find you a mentor :) [10:17] elky, yes I was considering that [10:19] Shall we go to vote, or are there further questions? [10:19] I think +0 for me at this point. You have made a good start, but I would like to see more sustained contributions. [10:20] * persia is ready to vote [10:20] om26er_: how long have you been triaging? [10:20] om26er_, would like to see testimonials, more links to substantiate what has been said, have give +0 this time.. [10:21] lifeless, three months [10:21] persia, lifeless ? [10:21] so, 200 a month or so [10:21] jcastro, can you please have testimonial [10:21] +1 from me [10:21] -1 from me. Most activity is in triaging, but mixed comments in -bugs and no testimonials. [10:22] persia, what kind of contribution can a person in a country where people dont mostly use computers [10:22] +0 from me, 3 months is really short these days. I'd like to see you get a mentor for a bit and come back to us. [10:22] I cant create a loco here [10:23] om26er_: I'm not looking for a loco. Bugwork is great. I'd just like to see support from other people involved in the same area you're working in, especially because I see some negative commentary in the -bugs channel sometimes. [10:24] om26er_, karma in launchpad is good.. keep up the good work.. [10:24] thanks all [10:24] nigelb, Hi [10:25] shall I introduce myself? [10:25] nigelb, sure, go ahead [10:25] Hi, I'm Nigel from India. My contribution to Ubuntu includes participation with Beginners Team, Bug Squad, Ubuntu Community Learning Project, Classroom Team, and User Days Team. [10:25] I'm learning to fix bugs and moving towards joining MOTU. As part of the Bug Squad, I've adopted Rhythmbox package - triaging the bugs and coordinating with upstream. I also created an apport hook for Rhythmbox for easier triaging. [10:25] Recently, I've been thinking of joining the Ubuntu Reviewers to help deal with 2K+ bugs with patches. I've already started working on a few. [10:25] Please see more details of my contributions at my wiki page https://wiki.ubuntu.com/NigelBabu [10:26] Unfortunately no one to cheer me because most of the people I have worked with for a long time are in US timezone [10:27] But, I guess leoquant is here :) [10:27] since we have quorum and then some, I'm going to recuse myself from this vote and provide a testimonial for nigelb instead. [10:27] I'll cheer for nigelb, even though I failed to add a testimonial. [10:27] +1 for nigelb [10:27] nigelb, has also been a great encourager of the ubuntu-women team. [10:27] thanks elky [10:27] great effort/contribution==>ubuntu user days [10:29] I didn't mention UW because I wasn't sure if I was doing too much to help there, except help issyl when she wanted help with triaging and of course encouraging :) [10:29] nigelb, mentoring issyl0 is a wonderful help, and so is being encouraging [10:29] elky: :) [10:30] nigelb: So, how do you manage to spend so much time on Ubuntu? [10:31] persia: I dont spend so much time. I spend only around 2 hours a day, except when I'm trying to fix a bug and flounder around [10:31] most of the time, my laptop is on and connected but I'll be away studying [10:31] Ah, you have achieved the trick of visibility :) [10:32] persia: well, from you ;) [10:32] he's lying. i theorise he has an rj45 socket, matrix style. [10:32] haha. I lead a busy life. I work and study. In fact I've taken an hour off from work for this meeting [10:32] i suppose an unanimous +1 for nigelb [10:33] We should vote. [10:33] * lifeless is still looking [10:33] nigelb++ [10:33] thanks AlanBell :) [10:33] njpatel: great job, congrats :) [10:33] ok, ready to vote [10:34] +1 [10:34] +1 [10:35] +1 [10:35] +1 [10:35] +1 [10:35] * elky recused. [10:36] welcome nigelb [10:36] yeah, great congrats nigelb \o/ [10:36] yay! [10:36] amachu: thank you :) [10:36] I'm honored :) [10:37] dul* isn't here [10:38] lifeless, yep [10:38] elky: meta: 3 months is reasonably sustained IMO - its more than a school holiday kindof thing. Not saying its enough either; just don't think its particularly short. [10:38] seems not. has anyone actually ever laid eyes on him [10:39] lifeless, these days I find it to be short. however it wasnt the only factor, everyone else already said the rest [10:39] elky: right, I'm not bothered about the rest :P [10:40] tough :P [10:40] lifeless, true.. [10:40] * persia tends to balance "significant" and "sustained" such that a higher volume of work takes less time (but 2-3 months feels like a minimum) [10:40] .c [10:40] persia, on the expiry of team? [10:40] amachu: The CC is currently finishing the debate about how we get reelected. That ought be resolved within a couple weeks. [10:40] elky: I don't think we should be moving the goalposts is what I'm saying. [10:41] With luck we'll be able to solicit guidance after the next CC meeting. [10:41] lifeless, did you read the recent emails? [10:41] elky: which ones [10:41] persia, Ok [10:41] btw, my main reason for 0 was that i'd like to see some mentoring [10:41] I think the outcome was appropriate [10:41] I have /no/ issue with it [10:42] so we shall meet 22 Mar 10, 10.00 UTC [10:42] 23 March 10 [10:42] lifeless, the threads dholbach has been involved in [10:43] I'll be asleep then : I fly in thata morning at 7am. [10:43] eh? [10:44] dholbach, the mails between the member-granting councils/boards re membership criteria [10:45] elky: if its the thread I think it was, I commented in it [10:45] elky: Do you have a subject for those? I'm not sure I've read that sort of thing recently. [10:45] persia, clarification: attaining membership [10:45] all the feedback I got was massaged into https://wiki.ubuntu.com/Membership (in December) [10:45] they discussed duration of contribution, so it's not /us/ moving the goalposts as lifeless suggested [10:46] (my only reason for mentioning it) [10:48] Re-reading that thread (sorry for the confusion, I don't consider 3 months ago recent), I'm not sure there was consensus on timing. [10:49] Personally speaking, I don't consider less than two months sufficient, and don't tend to give extra points for > 6 months except under exceptional circumstances. [10:49] persia, well, it was published to the /Membership wikipage [10:50] * elky shrugs [10:50] * persia looks again [10:50] and it was no "they" and "us" discussion - all membership boards were in the discussion [10:50] elky: Indeed. I missed that edit when reviewing the discussion. I concur. [10:51] do you think we should have the discussion about timespan again? [10:51] dholbach: There is no "they" and "us" in Ubuntu generally. [10:53] elky: so yes, I provided the wording that is on /Membership in fact [10:54] Anyway, let's move on. I think we can all agree that the wording at /Membership is correct (or raise that in a wider thread). [10:54] so if necessary, I'm happy to participate in another discussion about it - do you need anything else from me? :) [10:54] dholbach, there is an us in this discussion -- the people on this board at this meeting involved in that decision. [10:54] Some of us may be willing to accept some folk with less time, under some conditions. Complete approval is likely to remain "rare". [10:55] gnight [10:55] elky: sorry, I probably could have been clearer - I just meant to clarify that all the membership boards plus the CC were in that discussion back then [10:55] persia, true [10:55] persia, sure. [10:55] dholbach, i'm aware. [10:55] elky: dholbach: Could we agree that "the threads discussed ... and "us" as in this board? [10:55] there's contexts, yes. [10:56] * persia is temporarily annoyed at English overloading the same word to indicate a collection of objects and a connetion of people [10:56] s/nn/ll/ [10:57] Do we have anything else? [10:59] not from my side [12:59] o/ [13:00] o\ [13:00] meep [13:00] moo [13:00] * ogra quickly gets a coffee ... missed that [13:00] * asac too [13:01] * persia waits for the wiki page to finish saving [13:01] back i am [13:01] * plars hangs another bag of caffeine on the I.V. and cranks up the drip [13:01] hello [13:02] #startmeeting [13:02] Meeting started at 07:02. The chair is NCommander. [13:02] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [13:02] * NCommander coughs [13:02] umm, no action items from last week? [13:02] hi NCommander ;) [13:02] * GrueMaster digs for #2 toothpicks and inserts them under eyelids. [13:02] [link] https://wiki.ubuntu.com/MobileTeam/Meeting/2010/20100309 [13:02] LINK received: https://wiki.ubuntu.com/MobileTeam/Meeting/2010/20100309 [13:03] JamieBennett: shoud i add ogras AR? [13:03] i think i saw that in mail ;) [13:03] * JamieBennett didn't see that [13:03] re [13:03] seems i dreamt that ;) [13:04] ok lets start i guess :) [13:04] * ogra didnt send it yet ... there was a discussion about logs that kept me from sending it :P [13:04] [LINK] http://people.canonical.com/~pitti/workitems/canonical-mobile-ubuntu-10.04-beta-1.html [13:04] LINK received: http://people.canonical.com/~pitti/workitems/canonical-mobile-ubuntu-10.04-beta-1.html [13:04] [topic] Standing Items [13:04] New Topic: Standing Items [13:04] ogra: feel free to add to wiki directly ;) [13:04] will do [13:04] [topic] Kernel Status (cooloney, ericm) [13:04] New Topic: Kernel Status (cooloney, ericm) [13:05] NCommander: slow down ;) [13:05] dude [13:05] Anything to comment on for work items? [13:05] where are they ? [13:05] so for beta [13:05] besides from office/email ... what can we do for the other specs? [13:05] powermanagement has two bugs somehow [13:05] that stops it from being finished [13:05] * cooloney waves at ogra [13:05] (the action items from last meeting i mean) [13:05] ogra: ? are those valid to block this spec? [13:06] NCommander: roll back [13:06] we are at standing items review of beta work itmes ;) [13:06] [topic] Beta Work Items [13:06] New Topic: Beta Work Items [13:06] There, now we're all on the same page :-) [13:06] for fsl-imx51, kernel just applied one patch to fix an subtle kernel oops bug found by jeremy kerr [13:06] lol [13:07] bug #531696 [13:07] Launchpad bug 531696 in linux-fsl-imx51 "mc13892 LED driver oopses on trigger action" [High,In progress] https://launchpad.net/bugs/531696 [13:07] asac, regulators -> complete FSL patch missing ... not sure we *need* the fix actually ... based on FSL [13:08] and i did not get any feedback about one of my patch to fix the bsp building error [13:08] asac, numbers for idle case -> depends on vendors and we wont do any code changes based on it -> DROP [13:08] i think we forward it to fls [13:08] fsl [13:08] asac, what other tiems are you referring to in that spec ? [13:09] *items [13:09] ok i had a reconnect :( [13:09] can someone paste me the scroll back [13:09] and cross fingers that i stay up now [13:10] asac_: http://pastebin.ubuntu.com/391746/ [13:10] to late [13:10] sorry folks. please run the meeting not relying on me [13:11] Or your ISP [13:11] asac_, http://pastebin.ubuntu.com/391746/ [13:11] :D === asac_ is now known as asac [13:11] ok cross fingers [13:11] * ogra crosses fingers [13:11] id dint get the paste before either [13:11] OK, back to work items [13:11] asac: http://pastebin.ubuntu.com/391746/ [13:11] asac, so what items were you referring to in the spec ? [13:11] ok so should those bugs be linked to spec? [13:12] imho we can set them all to dropped unless something comes from FSL [13:12] or just tracked as bugs? [13:12] imo i would think that feature bugs should be linked [13:12] to specs, but not real bugs [13:12] which bugs exactly ? [13:12] ok lets unlink them [13:12] hmm wasnt powermanagement spec linked to bugs? [13:12] yes [13:13] sadly the spec page gives no overview about the bug status :( [13:13] i think most of them are fix released [13:13] * NCommander has the action items for this week once ogra releases the wiki page lock [13:14] bug 509006 [13:14] Launchpad bug 509006 in linux-mvl-dove "[dove] hibernation failed to resume" [High,Confirmed] https://launchpad.net/bugs/509006 [13:14] i dont do anything on the page [13:14] thats still open [13:14] NCommander, grab it [13:14] -> unlink [13:14] ? [13:14] fix rather ? [13:14] that's not fixed [13:14] I think GrueMaster said he tested that yesterday, and that it was still broken [13:14] right. my question was if we should make specs for bug tracking [13:14] well, we'Re in kernel freeze ? [13:14] if we cant close a spec if there are bugs left we can never finalize it for a milestone [13:15] action items up [13:15] asac, which spec depends on hibernation? [13:15] I tested both apw's kernel and the latest image. [13:15] well, then unlink [13:15] if we say: its ok to be behind because we track bugs that come out of specs thats fine [13:15] we'll do those once we finish Standing Items [13:15] ericm_: power management [13:15] https://blueprints.launchpad.net/ubuntu/+spec/mobile-lucid-arm-per-soc-powermanagement [13:15] apw's kernel failed, but the latest image worked fine. [13:15] GrueMaster, did you tell that apw ? [13:15] ok lets move on to another spec ;) [13:15] can we just unlink it, as I know hibernation shouldn't block power management [13:15] in other aspects [13:15] yes. It should be in the irc log. [13:16] lets screw it ... i will approach you individually after the meeting ;) [13:16] unlinked [13:16] too many reconnects ;) [13:16] ogra: thanks [13:16] asac: ++ [13:16] NCommander: lets go on with standing items [13:16] ;) [13:17] asac, action items first :) [13:17] right [13:17] those were not there when i last looked ;) [13:17] whoops ... i didnt do mine :( [13:17] asac, our chair is slacking :) [13:18] [topic] Kernel Status (cooloney, ericm) [13:18] New Topic: Kernel Status (cooloney, ericm) [13:18] NCommander, action items please [13:18] [topic] Action Item review [13:18] New Topic: Action Item review [13:18] [topic] asac to talk to team about training session [13:18] New Topic: asac to talk to team about training session [13:18] i started to write on alpha-3 stuff ... i think -efl bugs are not yet done [13:18] * NCommander was dealing with a very persistant cat [13:18] NCommander: i lost context on training session ;) [13:18] we did one [13:18] that was the thumb2 session [13:18] that was about the thumb2? [13:18] yup [13:19] yeah then that was done two weeks ago ;) [13:19] so strike [13:19] asac: (these action items are from 2 weeks ago) [13:19] [topic] asac and JamieBennett to triage netbook-launcher-efl bugs [13:19] New Topic: asac and JamieBennett to triage netbook-launcher-efl bugs [13:19] keep bloggin and -efl bugs [13:19] cf [13:19] asac: cf? [13:19] carry forward [13:19] carry forward [13:19] carry forward [13:19] * NCommander hears an echo [13:19] or creepy fish [13:19] no need to make topics for each of the items ;) [13:19] but go ahead [13:20] [topic] ogra to file a bug on LP not tracking bug links to blueprints or sending emails [13:20] New Topic: ogra to file a bug on LP not tracking bug links to blueprints or sending emails [13:20] co [13:20] [topic] NCommander to investigate KDE FTBFS issues [13:20] New Topic: NCommander to investigate KDE FTBFS issues [13:20] tuxdavis took this one over, and found the kdebindings crash [13:20] the fix you mean? [13:20] yeah, seems its fixed [13:20] s/crash/fix [13:20] right. last i looked there were not so many issues [13:20] its not on the ftbfs list since some days [13:20] kdeedu was still unhappy [13:20] I'll look at it sometime this week [13:21] so I guess c/o on this one too [13:21] [topic] GrueMaster to produce a daily report on image testing and add that to the weekly meeting page [13:21] New Topic: GrueMaster to produce a daily report on image testing and add that to the weekly meeting page [13:21] WIP [13:21] co? [13:21] are you adding it atm ? [13:21] Started this week [13:21] thats fixed also [13:21] right GrueMaster and me discussed this and its moving ;) [13:22] i dont think we need to carry that forward [13:22] [topic] everyone to try rootstock GUI once its in the archive [13:22] New Topic: everyone to try rootstock GUI once its in the archive [13:22] * ogra had feedback from asac so far on rootstock ui testing [13:22] we will see that when checking it [13:22] i tested it quite a bit [13:22] though not to full image ;) [13:22] the rest of the team are slackers ! [13:22] because of the qemu hangs [13:22] right [13:22] i'm hoping the recent upload changes something in qemu [13:22] is that fixed now ? [13:22] no [13:23] hmm so the new image format didnt help? [13:23] and i cant test until glib is built and promoted [13:23] I was told by ogra to wait for his fix :) [13:23] on the KDE compile failure tuxdavis concluded its a fault in the toolchain causing the segfault. kdebindings, kdeedu and other non kde packages are affected. I've worked out it in kdebindings by not compiling smoke on ARM [13:23] nope, but there was a fix for disk IO tonight [13:23] ogra: you should really make alocal mirror out of a apt-cache [13:23] plars, you can test minimal images once glib is there [13:23] Riddell: thanks! [13:23] Riddell: is that ok? [13:23] or a bad hack=? [13:23] sadly glib breaks debootstrap atm [13:24] (we now pull glib into minimal builds since recently ) [13:24] Argh [13:24] ew [13:24] * ogra waits whan gtk will enter too [13:24] * StevenK didn't want to hear that bit [13:24] I just ate, damn it [13:24] hmm glib in minimal? what is pulling that? [13:24] send flowers to plymouth :) [13:24] * NCommander seconds StevenK's emotion [13:24] oh [13:24] ok [13:24] !ohmy [13:24] Please remember that all Ubuntu IRC channels share the same attitude of providing friendly and polite interaction with all users of all ages and cultures. Basically, this means no foul language and no abuse towards others. [13:24] ok lets move on [13:25] summary: qemu is in bad state still :/ no idea whats going on [13:25] right [13:25] [topic] Kernel Status (cooloney, ericm)
 [13:25] New Topic: Kernel Status (cooloney, ericm)) [13:25] asac: it'll do for kdebindings but the problem is likely to reappear elsewhere [13:25] well, i have a better idea [13:25] ogra: please try the file writing/reading loop [13:25] ;) [13:25] right, [13:25] in a qemu to check if its reproducible by that [13:25] it is our turn? [13:25] asac, next aftzer stracing apt [13:25] cooloney: go ahead [13:25] for fsl-imx51, kernel just applied one patch to fix an subtle kernel oops bug found by jeremy kerr [13:25] bug #531696 [13:25] Launchpad bug 531696 in linux-fsl-imx51 "mc13892 LED driver oopses on trigger action" [High,In progress] https://launchpad.net/bugs/531696 [13:26] i think i sent this patch to ogra [13:26] yeah, i need to forward it to paul still [13:26] it should be included in fsl's bsp [13:26] wil do that before the call today [13:26] ogra: ok, thanks [13:26] and how about the regulator issue? [13:27] given that next BSP is only plannae dfor end of may its not that urgent i think ... [13:27] ok so that patch came from fsl? [13:27] cooloney, last call was skipped [13:27] i'll bring it up today [13:27] ok [13:27] ogra: right, understand [13:27] whats the status on regulators? [13:27] FSL is definately aware [13:27] we had enough mails on that [13:27] still missing a patch? [13:27] yeah [13:27] a part of the patch is missing [13:28] right. lets bring it up today [13:28] right [13:28] thats the plan [13:28] right, i just got one patch will will break our kernel [13:28] * ogra would still looooove to see a fix for bug 457878 [13:28] Launchpad bug 457878 in linux-fsl-imx51 "imx51 on board ethernet plug/unplug events not detected" [Medium,Confirmed] https://launchpad.net/bugs/457878 [13:28] and i also sent out a patch to fix the building error before [13:28] [ACTION] ogra and asac raise regulator patch issue again with fsl [13:28] +1 ogra [13:28] is that any feedback [13:28] [ACTION] ogra and asac raise regulator patch issue again with fsl [13:28] ACTION received: ogra and asac raise regulator patch issue again with fsl [13:28] but i'm not having high hopes [13:29] ogra: i am working on that [13:29] cooloney: do you have any idea? [13:29] * ogra humps cooloney's leg [13:29] and is preparing a patch to add phylib support into fec.c [13:29] or waiting on fsl input? [13:29] becuase the upstream also like to see that [13:29] asac, we know whats wrong, its just a hell lot of work [13:29] yeah, [13:30] but if we switched to generic phylib [13:30] it is better for every one who use fec.c [13:30] and FSL just didnt do it yet [13:30] * ericm_ wonders why fec.c still hasn't been linked with phylib [13:30] ericm_: no idea [13:30] ericm_, especially since that bug is known since jaunty [13:30] * persia doesn't press the ohmy button again, as it's too soon, but ... [13:30] ok. if there is info you need from fsl to work on this let us know offline [13:30] asac: no problem [13:30] anything else on imx51? [13:30] persia, what for would you pressi it ? [13:31] oh, we found necessary patches for kexec [13:31] interesting. how intrusive are those? [13:31] but still need finalize [13:31] ok. is there a place to track that ? [13:31] asac, they are in already as i understood [13:31] (kexec patches) [13:31] cooloney, what's there still need finanlize? [13:32] back ported 5 patches to add kexec supporting for our armv7 [13:32] ericm_: we still need patch kexec-tools [13:32] oh from .32 to .31 [13:32] or just kexec vmlinux [13:32] need a solution [13:32] note that its fine to have but we wont do anything for lucid with kexec [13:32] when is the deadline for getting this in? [13:32] ogra: no, backport from .33 to .32 and .31 [13:32] we will do a lot with it in L+1 if its there though [13:32] so versatile, dove and imx51 can support that [13:33] Cool! [13:33] since NCommander will revive softbootloader then [13:33] cooloney, ah right - we might need an updated kexec-tools [13:33] so dont put kexec on higher prio than the other bugs please [13:33] ogra: I already had managed to get softbootloader working on dove partially weeks ago. I shelved the work this cycle after talking with asac [13:33] and i think ericm_ already pushed the kexec to lucid [13:33] i agree with ogra, lets not drop other stuff for kexec [13:34] i will do that later [13:34] ok [13:34] they RC bugs are more important [13:34] cooloney: when is the last upload deadline? [13:34] 11th is the deadline for kernel freeze [13:34] i think that was today [13:34] or yesterday [13:34] ericm_: right, thanks [13:34] apw said 8th [13:34] to get everything ready before freeze [13:35] oh, I'm lucky then send him the git pull yesterday [13:35] ok so on imx51 we wait for regular patch, work on carrier detect for fec and look into kexec backports [13:35] anything else? [13:35] (for packaging and testing etc) [13:35] so i need to do that soon, [13:35] at least for kexec patches [13:35] regulator [13:35] asac: good summary [13:35] right [13:35] ok ericm_ ;) ... your turn! [13:35] cooloney, right - we might want to get the basic stuffs in - anything broken can be fixed later [13:36] ericm_: exactly [13:36] freeze is thursday ... to get things up and built before then i 'closed' yesterday [13:36] ok, Marvell made another drop of patchset this week, and I was able to get them in in the git-pull to apw yesterday [13:36] is there something i am missing whcih is needed for freeze [13:36] basically, there will be three parts of changes [13:36] apw: so i missed that [13:36] apw, yeah, we decided to switch FSL to .33 :P [13:37] * apw dies [13:37] * ogra hides [13:37] heh [13:37] kexec + basic Android support (not necessarily turned on in our kernel but to keep our code as close as possible to theirs) [13:37] apw: nothing planned, but you never know ;) [13:37] + BMM (a block memory management for physically contiguous memory allocation for their GPU/VPU acceleration) [13:37] ericm_: basic android support? what size is that patch? [13:37] and turning off OABI_COMPAT as discussed [13:38] right. thanks for that [13:38] ;) [13:38] asac, it's a series of patches [13:38] asac, but we didn't turn on any Android related options - so to keep the impact to minimized [13:39] ericm_: right. wonder what size are those patches? [13:39] whats the topic? powermanagement? [13:39] asac, it's not much, lemme check [13:40] asac, < 1M, oh my [13:41] ok [13:41] lets take that offline [13:41] any important issues outstanding for dove? [13:41] what about bug 528524: pulseaudio "Sound not working in all apps on dove" [13:41] Launchpad bug 528524 in totem "Sound not working in all apps on dove" [High,New] https://launchpad.net/bugs/528524 [13:41] * ogra saw something similar for imx51 today ? [13:42] plars: is it really a regression compared to x86? [13:42] mmm.. and mplayer crashes in sound as well - Marvell is working on this [13:42] ok so thats still on the radar? [13:42] Yes. But it may be driver related. [13:42] asac: it seems specific to that board [13:42] ok good [13:43] asac: but we have another similar (but different) pulseaudio issue on imx51 [13:43] let me add the kernel package [13:43] just in case [13:43] Bug 534815 [13:43] Launchpad bug 534815 in pulseaudio "imx51 some audio files play, others do not" [Medium,Confirmed] https://launchpad.net/bugs/534815 [13:43] ericm_: do you know where they want to fix it? in kernel? [13:43] ogra: some audio files? e.g. codecs? [13:43] or apps? [13:43] asac, the crash looks like a kernel bug, so yes - most likely [13:43] asac, no idea, not my bug [13:43] ogra: right [13:43] I spent a good deal of time looking at that one yesterday [13:44] the mplayer crash on dove is definitely kernel related. mplayer segfaults when opening the audio device. [13:44] plars: so on imx51 all apps play sound ... just some codec/format/frequency doesnt work well? [13:45] GrueMaster: ok thanks. so the dove thing is kernelish ... done. [13:45] ogra: never looked at that bug before [13:45] asac: actually that seems to be the case on both boards, but the sampling rates at which they will play is different [13:45] hmm [13:45] cooloney, reported 11h ago :) [13:45] cooloney, nobody expected you to look yet :) [13:46] interesting bug. we should keep that on the radar [13:46] ++ [13:46] targetted for lucid [13:46] ogra: oh, thanks, [13:47] ok anthing else for dove? [13:47] asac, nope [13:47] lets move on ;) [13:47] NCommander: ^ [13:47] [topic] QA Status (GrueMaster, plars) [13:47] New Topic: QA Status (GrueMaster, plars) [13:47] Image builds continue to be hit and miss. Currently, 3/7 is the last image built. [13:47] Tested hibernate multiple times on Dove with latest available image, no issues to report. [13:47] Tested image install on Babbage 3, no immediate issues seen during imaging. Sound still appears to be an issue. System sounds are ok, but no playback from alsa tools. [13:48] That's all from yesterday. [13:48] Looks like the suspend/resume tests may go into checkbox main, but I have some things to fix/cleanup on it based on a review I got back from Marc yesterday, so I'll be taking a look at that this week [13:48] how about test kernels (which are due to be uploaded today) [13:48] I need to backtrack and put some notes together for last week. [13:48] if you get such things it would make sense to add them to the report [13:48] ok [13:48] GrueMaster: today we had no image? [13:49] Nope. [13:49] what is currently out of sync? [13:49] asac, see the page :) [13:49] i reported it [13:49] under image status [13:49] kk [13:49] ok thanks plars and GrueMaster [13:49] plars: will check with you on the final work items of suspend resume [13:49] offline ;) [13:50] sounds good [13:50] ok next [13:50] NCommander: ^^ [13:50] [topic] ARM Application status (JamieBennett, dyfet) [13:50] New Topic: ARM Application status (JamieBennett, dyfet) [13:50] I also spent a good chunk of Sunday trying to get likewise working. First order is to get it working on x86. Still no luck, even with the help of a Windows guru. [13:50] Looking OK, netbook-launcher-efl has a few bugs but nothing out of the ordinary [13:50] GrueMaster: do you have a win server for likewise testing? [13:50] GrueMaster, thats been moved to the server team last week [13:51] yes [13:51] ok cool. i dont think its high priority though [13:51] GrueMaster, please coordinate with them and comment on the bug if you test it [13:51] Does the server team have access to arm? [13:51] what we want to tes tis whether it doesnt crash ;) [13:51] GrueMaster: we can run the tests for them if they make a proper server setup available with instructions how to setup the client [13:51] ;) [13:51] GrueMaster, we offered them help so if you have a setup that would be good [13:51] so we dont need to fiddle until x86 works first [13:51] ok [13:52] but let them know and ask what they need [13:52] Client side is easy. Getting an NT server going is hard. [13:52] [ACTION] ogra to check with ttx on what server team needs to help likewise testing on arm [13:52] NCommander, ^^ [13:53] [topic] [13:53] New Topic: [13:53] er [13:53] heh [13:53] [topic] ARM Porting/FTBFS status (NCommander, dyfet) [13:53] New Topic: ARM Porting/FTBFS status (NCommander, dyfet) [13:53] C&P fail [13:53] err [13:53] libplist -> i have that fixed for armel [13:53] [ACTION] ogra to check with ttx on what server team needs to help likewise testing on arm [13:53] ACTION received: ogra to check with ttx on what server team needs to help likewise testing on arm [13:53] [ACTION] ogra to check with ttx on what server team needs to help likewise testing on arm [13:53] thanks [13:53] squid i havent done yet [13:53] asac, oh, dyfet wanted to look at squid and libpt [13:53] err libplist [13:53] i did plist over the weekend [13:54] i can keep it private ;) [13:54] right, dyfet whats the status for squid then ? [13:54] anyway, there are plenty of ftbfs so fix [13:54] libpst [13:54] iirc [13:54] right, last week there were only these two pressing [13:54] ogra: sorry, missed squid... [13:54] libgtk2-perl and libpst [13:55] dyfet: can you work on one of these today? [13:55] and squid ;) [13:55] asac: yes, I can [13:55] libtommath libtunepimp and ossp-uuid [13:55] great [13:55] also look like worthwhile candidates [13:56] ok lets move on [13:56] Not sure if it is helpful (and I don't have all the details), but apparently there is a fix for gcc for the -fPic issue. [13:57] i think the image status is quite well documented on the wiki [13:57] i dont have questions. anyone? [13:57] upstream in svn. [13:57] GrueMaster: which -fPIC issue? [13:57] [topic] ARM Image Status (ogra, persia)
 [13:57] New Topic: ARM Image Status (ogra, persia)) [13:57] GrueMaster, talk to doko ? [13:57] 4:57 < asac> i think the image status is quite well documented on the wiki [13:57] 14:57 < asac> i dont have questions. anyone? [13:57] * ogra doesnt :P [13:57] * StevenK neither [13:57] [topic] Any Other Business [13:57] New Topic: Any Other Business [13:58] We only currently have server images, but expect to have Ubuntu netbook ones tomorrow. [13:58] * ogra wonmders how server could build [13:58] No glib gets dragged in [13:58] if basic debootstrapping doesnt work [13:58] weird [13:58] ogra: Ah, because the server is alternate [13:58] server uses plymouth [13:59] yeah. alternate probably does the trick [13:59] do we still produce them? [13:59] server [13:59] It would fail to install, but it would still build [13:59] asac: Yes [13:59] yeah, right [13:59] anyway, we'Re at AOB ... [13:59] did anyone have an idea for gSoC [14:00] or do we have intrested students attending that would like to run a gSoC project ? [14:00] (and look for a mentor in the mobile/arm area) [14:00] porting the rest of thumb2 ;) [14:00] * ogra was pondering to put rootstock up for gSoC [14:00] asac, that doesnt fit the timeframe :) [14:01] gSoC will be L+1 [14:01] 3 month? full time ;)? [14:01] ogra: universe will have plenty of stuff left [14:01] Too bad it is restricted to current students. I have someone that would be interested otherwise, but won't be going to college until fall. [14:01] GrueMaster, i'm not sure its restricted that closely [14:01] Neither [14:01] It is, we checked. [14:01] probably its enough to prove that you are starting to study soon [14:02] gah [14:02] i think a "flexible image building" project would be helpful ... or softbootloader maybe [14:02] Need to be enrolled. [14:02] elasitc images, heh [14:02] Does that mean they bounce back after a hard crash? [14:02] yeah ! [14:03] ok [14:03] well, doesnt look like we have anything concrete yet [14:03] so one more thing: next week part of the team will be in london for training [14:03] so probably out of office from mon to wed [14:03] yeah [14:03] i think persia likes the idea to write meeting minutes ;) [14:03] or someone else :) [14:04] out of office will be asac, jamie and ogra [14:04] I think them to have been written. I'll write them if nobody else does, but it's easier to write when people stay on topic. [14:04] s/think/like/ [14:05] * persia doesn't really like writing minutes in the middle of the night [14:05] persia: for today? i mean next week when we are in london ;) [14:05] ok. i think thats it ;) [14:05] Oh that's fine. Have fun :) [14:05] lets go back working/sleeping ;) [14:06] zzzzZZZZ [14:06] whatever is appropriate for the timezone you are in ;) [14:06] damned [14:06] * ogra had hopes [14:07] * persia hopes the chair will exercise the MootBot command soon [14:07] * StevenK too [14:07] NCommander: ^^ #endmeeting please, sir [14:07] * ogra thinks the chair is not looking [14:08] NCommander, E N D M E E T I N G !!!!!!!!!!!!!!!!!!!! [14:09] #endmeeting [14:09] Meeting finished at 08:09. [14:09] heh [14:09] * GrueMaster pinged his cell. [14:09] hahaha [14:09] * NCommander isn't quite here this morning :-/ [14:10] And that is different from other days because... === robbiew_ is now known as robbiew [14:55] \o [14:59] hi [15:02] o/ [15:02] heya pitti. you, cjwatson, and myself so far. [15:02] I'm here [15:03] and Keybuk! :) [15:05] mdz: here? [15:06] * cjwatson pokes sabdfl [15:07] ok, so just awaiting mdz [15:07] Keybuk: you're the chair, why am I doing this? :-) [15:07] mdz is on holiday [15:07] ok [15:07] cjwatson: I can't be the chair, again nobody has told me that I am [15:08] Keybuk: you don't read the meeting minutes? :) [15:08] It was in the -devel-announce mail [15:08] kees: I am so far behind with my e-mail, I'm close to bankrupcy [15:09] Keybuk: heh [15:10] so, looks like https://wiki.ubuntu.com/TechnicalBoardAgenda isn't current, right? [15:10] * pitti tries to find what should be there [15:10] i'll chair [15:10] Why isn't it current? Lots from last meeting, but that ran out of time. [15:10] pitti: it should be current; I removed all the stuff from last time. [15:11] thanks [15:11] ah, ok [15:11] what's the magic incantation to start the mootbot? [15:11] I thought the sponsoring merge was by and large done and discussed [15:11] "#startmeeting" [15:11] the sponsors item can be dropped from it [15:11] dholbach: Thanks. [15:11] it's blocked on an RT ticket [15:11] dholbach: it hasn't been implemented yet; is that on your queue? [15:11] ah [15:11] that RT ticket is done [15:11] it's on my queue, yes [15:12] (sorry to be a pain, but I'm so behind on everything at the moment, that I'd spend half the chair time trying to find things) [15:12] cjwatson: 37728 isn't afaics [15:12] oh, sorry, I'm thinking of a different RT ticket. you mean https://rt.admin.canonical.com/Ticket/Display.html?id=37728 [15:12] I was thinking of the -reviews one [15:12] #startmeeting [15:12] Meeting started at 09:12. The chair is sabdfl. [15:12] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [15:13] cjwatson: thanks - I'll see that I can find somebody to look into it [15:13] [TOPIC] Archive reorganisation (standing item; ColinWatson) [15:13] New Topic: Archive reorganisation (standing item; ColinWatson) [15:13] DanielHolbach: merge ubuntu-universe-sponsors and ubuntu-main-sponsors (Discussion) [15:13] dholbach: status? [15:13] dholbach: is there anything else you want to push forward here other than the -sponsors merge? [15:13] sabdfl: see above :-) [15:13] sabdfl: waiting on https://rt.admin.canonical.com/Ticket/Display.html?id=37728 [15:13] the rest will be pretty straight-forward [15:13] * persia makes a pro-forma statement about how this shouldn't need TB action [15:14] ok [15:14] it can be moved off the agenda [15:14] persia: ? [15:14] emmet hikory mailed about developer permissions, ubuntu membership, and the web of interlinked teams they represent [15:14] cjwatson: That merging the sponsors queue shouldn't require TB approval. I wrote a longer mail about it. [15:14] oh right [15:14] It doesn't matter, because it's getting done (and all support it) [15:14] persia: are you clearer now about the requirements? [15:15] sabdfl: I'm clear about the requirements. I need to think I bit about infographics and documentation, and I'll send a new proposal. [15:15] okdokey [15:15] sabdfl: one moment [15:15] sabdfl: I'd like to enquire about your statement "the ability to participate as a developer before fully qualifying for membership" [15:15] sabdfl: by that, do you mean a contributor whose changes are reviewed, rather than somebody with upload permissions? [15:16] or do you mean somebody with upload permissions? [15:16] per-package upload permissions should not depend on having made a significant and sustained contribution to ubuntu, they should depend on one's credible skills to do that work [15:17] i want to decouple the allocation of membership to the allocation of permissions [15:17] it would be up to teams how they handled that [15:17] Hmm. I have a disagreement with that lurking around somewhere, but I can hold it off until I figure out how to articulate it :-) [15:17] okdokey [15:17] We may need to change how we handle those to meet that requirement. Our current model expects both credibility and significant&sustained (and considers those folk polity for TB&DMB selection) [15:17] as I see it, there will be several ways to participate in development: [15:18] sabdfl: so you would give someone PPU permission to a person that doesn't qualify for membership? [15:18] - proposed merges to relevant branches [15:18] - commit to relevant branches [15:18] - upload to a package, or package set [15:18] - join one of the generalist upload teams (core, motu) [15:18] geser: yes [15:18] an example for this would be a DD who wants to upload his packages to Ubuntu as well [15:18] consider a DD, who is perfectly competent to manage... yes [15:19] I have no strong opinion whether we'd require membership before approving PPU [15:19] So we'd drop the expectation that that DD had shown activity in Ubuntu for some time, to meet the significant&sustained guideline? [15:19] of course, people do need to *understand* certain things about our development process [15:19] persia: yes [15:19] but it would feel a bit sad to reject the courtesy [15:19] we don't want people who will break freezes or policy [15:20] pitti: if you mean, we should take the opportunity to collaborate immediately, and not wait for someone to demonstrate a deep commitment to ubuntu specifically rather than the quality of the package, i agree [15:20] * persia thinks it takes a full cycle to learn freezes and policy, and that anyone continuing to do stuff actively that long tends to qualify for significant&sustained [15:20] i think folks' enjoyment and appreciation for ubuntu will grow from there [15:21] OTOH we don't really expect ubuntu members to understand our freeze policy either? [15:21] anyhow - TB is responsible for developer guidelines and permissions, CC for membership and governance [15:22] I'll write something up based on the guidelines, and CC+TB can discuss in that mail thread. [15:22] in this intersection, i'm comfortable taking this path. TB and it's delegated decision makers (the leaders of various teams responsible for package sets) get to structure permissions to get the most efficient participation and quality [15:22] persia: a picture would be worth well north of 1000 words in this case :-) [15:22] any other comments on archive-reorg? [15:22] sabdfl: I've been working with an artist, so I'll attach a graphic as well next time. [15:23] ok, next [15:24] [TOPIC] https://wiki.kubuntu.org/Kubuntu/UpdatesPolicy upstream is http://techbase.kde.org/Policies/Minor_Point_Release_Policy/Draft [15:24] New Topic: https://wiki.kubuntu.org/Kubuntu/UpdatesPolicy upstream is http://techbase.kde.org/Policies/Minor_Point_Release_Policy/Draft [15:24] still no change upstram I'm afraid [15:24] are we pushing, or waiting? [15:24] it mostly needs me to tidy it up and get agreement [15:25] let's move on then [15:26] Riddell: this looks good, can i ask what the blocker is upstream? [15:26] sabdfl: I just need to find time to answer some people's queries and make the changes they suggested [15:27] was the idea put forward by them, or us? [15:27] by me [15:28] in general, i think it's brilliant to sync on SRU policies, and do a mutual commitment: they do good updates, we ship 'em [15:28] upstream has an unwritten policy and it seems to make sense to get that written down [15:28] ok, sounds good [15:28] [TOPIC] Units policy - Check up on feedback from Debian TC [15:28] New Topic: Units policy - Check up on feedback from Debian TC [15:29] nothing new here [15:29] bdale sent it on, but it hasn't gotten any traction. [15:29] [ACTION] Riddell to get agreement with KDE on point release criteria [15:29] ACTION received: Riddell to get agreement with KDE on point release criteria [15:29] (i think that will be recorded in the wrong topic, sorry) [15:29] is there anything we can do to catalyse the discussion? [15:30] i think we need to just move forward with the policy on our end. [15:30] file bugs? [15:30] +1 to moving forward [15:30] I believe we agreed to move on if we didn't get feedback within a few weeks [15:30] I think if we tracked the Debian bugs (and obviously our fixes) on the Units wiki page, we'd have something to show Debian if they ask about our status/progress. [15:31] why do we always end up doing the work on both sides? [15:31] we don't [15:31] this is just perception bias [15:32] Keybuk: is the policy as it is okay for you? I thought you had an objection against the "add --si option to CLI programs" part? [15:32] we do end up doing more work for things we care about and other folks don't, but that's sort of natural :) [15:32] pitti: I do, but I've given up with it [15:33] let's just tag the bugs a particular way, and put a link in the wiki [15:34] ok, quick poll [15:34] current https://wiki.ubuntu.com/UnitsPolicy looks great to me [15:35] yeah, I'm good with it [15:35] [VOTE] Ubuntu will move forward on the https://wiki.ubuntu.com/UnitsPolicy and track bugs with a tag so Debian can find and follow them quickly [15:35] Please vote on: Ubuntu will move forward on the https://wiki.ubuntu.com/UnitsPolicy and track bugs with a tag so Debian can find and follow them quickly. [15:35] Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0 to MootBot [15:35] E.g. /msg MootBot +1 #ubuntu-meeting [15:35] I'd perhaps add a third "file size" possibility to just show base-10 [15:35] +1 [15:35] +1 [15:35] +1 received from sabdfl. 1 for, 0 against. 0 have abstained. Count is now 1 [15:35] +1 received from kees. 2 for, 0 against. 0 have abstained. Count is now 2 [15:35] +1 [15:35] +1 received from pitti. 3 for, 0 against. 0 have abstained. Count is now 3 [15:36] +0 - I don't like the "must" in there for command-line applications any more than Keybuk does, but we can always revise in the future and I don't want to get in the way of the desktop work [15:36] Abstention received from cjwatson. 3 for, 0 against. 1 have abstained. Count is now 3 [15:36] (tracking bugs with a tag seems obviously sane) [15:36] -1 still [15:36] -1 received from Keybuk. 3 for, 1 against. 1 have abstained. Count is now 2 [15:37] whose votes would change in what way if we changed must -> may? [15:37] mdz is away, i can't see any more expected votes [15:37] under "Exception" [15:37] cjwatson: +1.1 from me :) [15:38] heh [15:38] (but oh well, ls, du, df, etc. already have that) [15:38] I would rather have consensus if we can achieve it [15:38] me too [15:38] but so far we just voted about "move forward without waiting on debian" [15:38] Keybuk: what would it take for you to support the proposal? [15:39] is there an estimate in the proposal of how long the string is, for main? [15:39] "the string"? [15:39] and is there a "core subset" that would represent the main, meaningful, useful set [15:39] pitti: how much work it is to be done [15:39] sabdfl: I don't really like most of it, but since it's clear the rest of the board are happy, it's not worth me holding it up [15:39] I don't think anyone has attempted to work out how many packages are involved [15:40] * sabdfl thinks that this could gain momentum if we commit to it [15:40] I don't think we should drop everything to comb the archive for violations of that, but we should encourage testers to file appropriately tagged bugs, so that we can start pointing ot the policy in upstream bug reports, etc. [15:40] the policy is as rational as one could expect [15:40] we could socialise it with GNU, for example [15:40] there is a long discussion in an upstream glib report, for example [15:40] does it reference our wiki page? [15:41] not yet (since it's not official yet) [15:41] or is there a similar, canonical as it were, policy :-) [15:41] but the arguments of the various ML discussions [15:41] If we (as "Ubuntu") would just go ahead and change it, it might be a bit more convincing [15:41] I would be surprised if GNU followed a marketing standard (disk sizes as advertised by hard disk manufacturers) over a prior technical standard [15:41] personally [15:41] it's not their style [15:42] i would prefer that we follow GNU, if they develop a policy, than get into a standoff [15:42] they might be persuaded to use consistent terms for each of the units [15:42] most of the GNU packages concerned fall under the "Exception" section, though [15:42] i don't know that it's fair to call it a "marketing standard", though, since it's consistent and rigorous, isn't it? [15:42] it's a standard initiated by hard disk manufacturers wishing to make their disks sound larger [15:43] I think it's an entirely fair name :) [15:43] I don't know the history on network bandwidth so am not qualified to comment there [15:44] I never ever saw base-2 units in networking [15:44] My (dredged) memory on that is that it was related to 1bit/cycle in early wire protocols, so 1MHz ~ 1Mbit [15:44] this is not me saying that we shouldn't pick standard units for these things in desktop-visible parts of Ubuntu, just saying that there is no point being overly hopeful [15:44] starting from my old 33.6 kBaud modem up to 100Mbit ethenet [15:45] we could at least fix nautilus [15:45] I'm happy with the policy with the exception that I think it's a waste of time to declare a "must" for a bunch of shell scripts that output file sizes :) [15:45] or whatever [15:45] hence my query above about a modification [15:45] it's currently a bit ridiculous to have the computer place show an "80 GB disk" and then you open it and see a 76.32whatnot GB volume [15:45] agreed [15:46] cjwatson: s/must/may/ sounds good to me [15:46] I also propose to add a third and preferred file size possibility to just show base-10 [15:46] adding options everywhere doesn't seem practical nor desirable to me [15:47] I think I agree with you [15:47] persia: yeah, it's from baud, which was always base-10. [15:47] Keybuk: with above two changes, would you feel better about it? [15:48] it wouldn't be as bad yeah [15:49] * pitti edits page [15:51] https://wiki.ubuntu.com/UnitsPolicy?action=diff&rev2=21&rev1=20 [15:51] https://wiki.ubuntu.com/UnitsPolicy?action=diff&rev2=22&rev1=21 [15:52] sabdfl: hm, so maybe we should vote about the actual policy here, now that we decided to unblock on Debian? [15:52] cjwatson: if we say MAY then it's NOTABUG [15:52] sabdfl: yup [15:52] if we say MUST, then it's a low importance bug [15:52] *blink* [15:52] sabdfl: well, it could be a wishlist bug [15:52] if we want it to be a bug but low-importance, that's "should" [15:52] "must" to me denotes an assertion failure [15:52] I'd prefer that we adopt a policy that says MUST, but say that the bugs can be low importance [15:53] ok, i'd be happier with SHOULD then [15:53] in many cases I think this change would be actively undesirable [15:53] it is better to leave small programs robust and simple than to add complexity to them, in many cases [15:53] hence why I think MUST would be a bug in the policy [15:53] i would be happy for the policy to say that, too [15:53] * pitti would go with MAY, start fixing GUIs first, and then perhaps adjusting it later on [15:54] i. e. start small [15:55] ok, so it's more an attempt to harmonise, than a standard [15:55] ok, that's fine, i'd +1 that [15:55] harmonising the GUI is a lot more important than the rest of it, I think [15:55] how do i finish the existing vote? [15:56] [/VOTE] [15:56] nup [15:56] [ENDVOTE] or #endvote, I can never remember which [15:56] "#endvote" or "[ENDVOTE]" [15:56] [ENDVOTE] [15:56] Final result is 3 for, 1 against. 1 abstained. Total: 2 [15:56] https://wiki.ubuntu.com/ScribesTeam/MootBot [15:56] "/msg #irc-ops please k-line mootbot" works, I find :p [15:56] [VOTE] Ubuntu will adopt https://wiki.ubuntu.com/UnitsPolicy [15:57] Please vote on: Ubuntu will adopt https://wiki.ubuntu.com/UnitsPolicy. [15:57] Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0 to MootBot [15:57] E.g. /msg MootBot +1 #ubuntu-meeting [15:57] +1 [15:57] +1 received from sabdfl. 1 for, 0 against. 0 have abstained. Count is now 1 [15:57] +1 [15:57] +1 received from pitti. 2 for, 0 against. 0 have abstained. Count is now 2 [15:57] +1 [15:57] +1 received from Keybuk. 3 for, 0 against. 0 have abstained. Count is now 3 [15:57] +1 [15:57] +1 received from cjwatson. 4 for, 0 against. 0 have abstained. Count is now 4 [15:57] (on the basis the policy currently says "may") [15:57] ^ it does now [15:59] kees? [15:59] +1 [15:59] +1 received from kees. 5 for, 0 against. 0 have abstained. Count is now 5 [16:00] sabdfl: looks unanimous :) [16:00] [ENDVOTE] [16:00] Final result is 5 for, 0 against. 0 abstained. Total: 5 [16:00] phew [16:00] thanks all [16:00] motion carried [16:00] * pitti removes the "draft" [16:00] https://bugs.edge.launchpad.net/ubuntu-community/+bugs?field.assignee=techboard [16:00] only the one, about my position [16:01] dholbach, what's the url for the leadership-appointment page, which mentions this? [16:02] https://wiki.ubuntu.com/CommunityCouncil/RestaffingProposal [16:02] sabdfl: I hope that's the one you meant? [16:02] that page isn't final, but it mentions this special-case [16:02] can i close the bug? [16:03] sounds good to me [16:03] sounds fine [16:03] I'll ping everybody for a round of feedback on the document again, then we can go and approve it [16:04] ok, dholbach will you close the bug when it's approved? [16:04] effectively it's what "we've been doing all the time", so another round of feedback and renaming the doc should be fine [16:04] sabdfl: I can do that too, sure [16:04] [ACTION] dholbach to finalise LeadershipAppointment page, and close bug on sabdfl role in TB [16:04] ACTION received: dholbach to finalise LeadershipAppointment page, and close bug on sabdfl role in TB [16:04] [TOPIC] Discuss https://lists.ubuntu.com/archives/edubuntu-devel/2010-February/003323.html [16:04] New Topic: Discuss https://lists.ubuntu.com/archives/edubuntu-devel/2010-February/003323.html [16:05] why do they need to do this: "The ~ubuntu-core-dev[5] and ~developer-membership-board[6] teams have [16:05] been invited to join the ~edubuntu-dev team." [16:05] ? [16:05] standard practice for delegated teams [16:05] is that a soyuz permissions limitation, that requires clusterfscking the teams? [16:06] two different issues [16:06] u-core-dev is good to have for being able to commit to their branches [16:06] ~developer-membership-board should be able to administer all the delegated teams (we agreed a while back) [16:06] and what pitti said [16:06] so DMB is added as an admin [16:06] the branch commit thing seems like something that could be fixed in LP [16:07] sabdfl: eventually it will, with the auto-imports [16:07] I think it mostly works already [16:07] ok [16:07] but right now it's still required for manually created branches [16:07] but there are some edge cases, like seeds, that are difficult to address === yofel_ is now known as yofel [16:07] I agree that it is a workaround [16:07] [VOTE] Edubuntu Council to assume responsibility for edubuntu-dev as per https://lists.ubuntu.com/archives/edubuntu-devel/2010-February/003323.html [16:07] Please vote on: Edubuntu Council to assume responsibility for edubuntu-dev as per https://lists.ubuntu.com/archives/edubuntu-devel/2010-February/003323.html. [16:07] Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0 to MootBot [16:07] E.g. /msg MootBot +1 #ubuntu-meeting [16:07] +1 [16:07] +1 received from sabdfl. 1 for, 0 against. 0 have abstained. Count is now 1 [16:08] let's just be explicit, this is also a request for edubuntu-dev to be allowed to upload to packages in the edubuntu package set, yes? [16:08] yes [16:08] I just noticed that that was mentioned nowhere explicitly in the mail, but there isn't much point otherwise :) [16:08] at least, that's my understanding, if that's what kubuntu-dev does [16:08] it is [16:09] +1 (looks to me like the right set of people in that council) [16:09] +1 received from kees. 2 for, 0 against. 0 have abstained. Count is now 2 [16:09] +1 [16:09] +1 received from Keybuk. 3 for, 0 against. 0 have abstained. Count is now 3 [16:09] I'm happy with the request, Edubuntu has been quite active of late and it's good to see them getting organised like this [16:09] I know three members from the current team pretty well, and I trust stgraber to pick good developers (he is also in the DMB after all) [16:09] +1 [16:09] +1 received from cjwatson. 4 for, 0 against. 0 have abstained. Count is now 4 [16:09] thus [16:09] +1 [16:09] +1 received from pitti. 5 for, 0 against. 0 have abstained. Count is now 5 [16:09] [ENDVOTE] [16:09] Final result is 5 for, 0 against. 0 abstained. Total: 5 [16:09] yay! [16:10] motion carried, congratulations, edubuntu [16:10] I'll implement [16:10] alright, on the chair, may I suggest we rotate alphabetically? [16:10] by first name? that would be mdz next then [16:10] [ACTION] cjwatson to implement edubuntu-dev delegations [16:10] ACTION received: cjwatson to implement edubuntu-dev delegations [16:10] thanks [16:10] i don't mind on what basis, could be last letter of first name :-) [16:10] or by nick, in which case I think it would be me [16:11] nick it is [16:11] that way, we can spend less time wondering [16:11] BRAIN FILLED WITH IRC [16:11] ok [16:11] folks can arrange substitutions, but the skeleton is fixed [16:11] thanks colin [16:11] and thanks all, apologies for tardy timekeeping [16:11] #endmeeting [16:11] Meeting finished at 10:11. [16:11] One piece of OB [16:11] Can I quickly ask that you guys respond to my CLI/mono mail? [16:11] we didn't start until :12 anyway :-) [16:12] Laney: our bad, will do [16:12] for the purposes of appropriate notification, I'm considering stepping down from this board [16:12] I haven't made a decision yet, but will do so before the next meeting [16:13] :o [16:59] o/ [17:00] \o [17:00] o/ [17:00] yo [17:00] * pgraner o/ [17:00] Roll Call [17:01] .. [17:01] \o [17:01] #startmeeting [17:01] Meeting started at 11:01. The chair is bjf. [17:01] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [17:01] * apw zones in [17:01] [LINK] https://wiki.ubuntu.com/KernelTeam/Meeting [17:01] [LINK] https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Lucid [17:01] LINK received: https://wiki.ubuntu.com/KernelTeam/Meeting [17:01] LINK received: https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Lucid [17:01] NOTE: '..' indicates that you are finished with your input. [17:01] [TOPIC] Open Action Item: None [17:01] * smb holds up his cup of tea in a greeting gesture [17:01] New Topic: Open Action Item: None [17:02] [TOPIC] Release Metrics: (JFo) [17:02] New Topic: Release Metrics: (JFo) [17:02] Release Meeting Bugs (4 bugs, 7 blueprints) [17:02] === [17:02] Beta 1 Milestoned Bugs (74 bugs against all packages (up 12)) [17:02] * 9 linux kernel bugs (up 1) [17:02] * 1 linux-fsl-imx51 bugs (no change) [17:02] * 1 linux-ec2 bug (no change) [17:02] * 1 linux-mvl-dove bugs (up 1) [17:02] === [17:02] Release Targeted Bugs (207 bugs against all packages (up 43)) [17:02] * 24 linux kernel bugs (up 6) [17:02] * 1 linux-fsl-imx51 bugs (no change) [17:02] * 1 linux-ec2 bug (no change) [17:02] * 2 linux-mvl-dove bugs (up 2) [17:02] === [17:02] Milestoned Features - [17:02] * 0 blueprints [17:02] .. [17:02] [TOPIC] Blueprints: kernel-lucid-bug-handling (JFo) [17:02] [LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-bug-handling [17:02] New Topic: Blueprints: kernel-lucid-bug-handling (JFo) [17:02] LINK received: https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-bug-handling [17:02] * I'm almost done with my analysis of the X debugging pages. I will update the team on the current state of the Kernel Team pages and my initial draft of recommended changes to the structure and layout via the e-mail list. [17:02] * I'll have the arsenal scripts running (not in dry run mode) by the end of this week. [17:02] .. [17:03] [TOPIC] Blueprints: kernel-lucid-kernel-config-review (apw) [17:03] [LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-kernel-config-review [17:03] New Topic: Blueprints: kernel-lucid-kernel-config-review (apw) [17:03] LINK received: https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-kernel-config-review [17:03] We have pulled out the HID devices to modular. Discussions on other drivers still pending, any changes will have to occur post beta-1 now. [17:03] .. [17:03] [TOPIC] Blueprints: kernel-lucid-kms (sconklin / apw) [17:03] [LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-kms [17:03] New Topic: Blueprints: kernel-lucid-kms (sconklin / apw) [17:03] LINK received: https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-kms [17:03] We have committed to the v2.6.33 drm backport which is now uploaded to the archive. Re-testing of graphics issues now to be requested. [17:03] .. [17:03] .. [17:04] [TOPIC] Blueprints: kernel-lucid-suspend-resume (manjo) [17:04] [LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-suspend-resume [17:04] New Topic: Blueprints: kernel-lucid-suspend-resume (manjo) [17:04] LINK received: https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-suspend-resume [17:04] .. [17:04] [TOPIC] Blueprints: kernel-lucid-apparmor-development (jjohansen) [17:04] [LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-apparmor-development [17:04] New Topic: Blueprints: kernel-lucid-apparmor-development (jjohansen) [17:04] LINK received: https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-apparmor-development [17:04] Editing text for another push to LKML [17:04] bjf, JFo: we need to put out a CFT for the .33 drm stack asap [17:04] * JFo makes a note [17:05] pgraner, i think that X are meant to be doing that, so you might want to check [17:05] CFT? [17:05] call for testing [17:05] Call For Testing [17:05] bjf, wonders why I'm being told that [17:05] k [17:05] .. [17:05] bjf: for an action item, no more [17:05] [ACTION] we need to put out a CFT for the .33 drm stack asap [17:05] ACTION received: we need to put out a CFT for the .33 drm stack asap [17:06] JFo: pls check with Bryce on the X testing [17:06] pgraner, ack [17:06] I still have a few LSM audit issues to attend to and we will see how the __d_path discussions play out. Currently trying to keep the 2 pushes separate [17:06] .. [17:07] [TOPIC] Blueprints: kernel-lucid-boot-performance (apw, csurbhi) [17:07] [LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-boot-performance [17:07] New Topic: Blueprints: kernel-lucid-boot-performance (apw, csurbhi) [17:07] LINK received: https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-boot-performance [17:07] Nothing to report. [17:07] .. [17:07] [TOPIC] Other Release Tasks: Lucid Audio Support (bjf) [17:07] New Topic: Other Release Tasks: Lucid Audio Support (bjf) [17:07] Nothing new this week. [17:07] .. [17:07] [TOPIC] Other Release Tasks: Lucid Better Power Mgt (amitk) [17:07] New Topic: Other Release Tasks: Lucid Better Power Mgt (amitk) [17:07] Pushed some power policy scripts to https://code.edge.launchpad.net/~amitk/ubuntu/lucid/pm-utils-powersave-policy/amit [17:08] will prepare a package in PPA and issue call for testing tomorrow [17:08] pitti is going to review them in the mean while, but other comments welcome [17:08] .. [17:09] [TOPIC] Other Release Tasks: EC2 Lucid Kernel Status (jjohansen) [17:09] New Topic: Other Release Tasks: EC2 Lucid Kernel Status (jjohansen) [17:09] Bug #527208 is still outstanding [17:09] Launchpad bug 527208 in linux-ec2 "ec2 instance fails boot, no console output on c1.xlarge" [High,Confirmed] https://launchpad.net/bugs/527208 [17:10] other than that no known issues [17:10] however it may be affecting more than just c1.xlarge kernels [17:10] just not reliably [17:11] and of course its one of those bugs we get no, debugging info for [17:11] .. [17:11] [TOPIC] Status: Lucid (apw) [17:11] New Topic: Status: Lucid (apw) [17:11] Lucid remains at stable v2.6.32.9. As mentioned above we have taken the v2.6.33 DRM backport as this greatly improves stability and removes the need for the Nouveau LBM module, cleaning up installs. We have also incorporated building the kernel perf tool. [17:12] All of the main kernel (linux, linux-fsl-imx51, linux-mvl-dove, and linux-qcm-msm) are now closed for the Beta-1, uploaded and building, linux-ec2 has been tested and pending a build-test is ready to upload. Anything which requires a kernel change will have to wait until after beta-1 and will have to pass the abbreviated SRU process (2 acks required). [17:12] .. [17:12] [TOPIC] Security & bugfix kernels - Karmic/Jaunty/Intrepid/Hardy/Others (gnarl/smb) [17:12] New Topic: Security & bugfix kernels - Karmic/Jaunty/Intrepid/Hardy/Others (gnarl/smb) [17:12] Dapper: 2.6.15-55.82 (security) [17:12] Hardy: 2.6.24-27.65 (security) [17:12] 2.6.24-27.67 (proposed)[15] 1/ 3 verifications done (+0) [17:12] Intrepid: 2.6.27-17.45 (security) [17:12] Jaunty: 2.6.28-18.59 (security) [17:12] Karmic: 2.6.31-20.57 (updates) [17:12] - LBM 2.6.31-20.22 (updates) [17:12] - mvl-dove 2.6.31-211.22 (security) [17:12] 2.6.31-211.23 (waiting for acceptance) [17:12] - fsl-imx51 2.6.31-108.21 (security) [17:12] 2.6.31-108.23 (proposed)[5] 0/ 1 verifications done (+0) [17:13] - ec2 2.6.31-304.11 (updates) [17:13] Hardy is just about to move to updates. [17:13] Coming up another security update, then final big upload for Karmic. [17:13] .. [17:13] [TOPIC] Incoming Bugs: Regressions (JFo) [17:13] New Topic: Incoming Bugs: Regressions (JFo) [17:13] Incoming Bugs [17:13] 280 Lucid Bugs (up 95) [17:13] Current regression stats (broken down by release): [17:13] ==== regression-potential (up 29) ==== [17:13] * 86 lucid bugs [17:13] ==== regression-update (up 1) ==== [17:13] * 11 karmic bugs [17:13] * 5 jaunty bugs [17:13] * 2 intrepid bugs [17:13] * 1 hardy bug [17:13] ==== regression-release (down 2) ==== [17:13] * 56 karmic bugs [17:13] * 22 jaunty bugs [17:13] * 11 intrepid bugs [17:13] * 4 hardy bugs [17:13] ==== regression-proposed (no change) ==== [17:13] * 1 karmic bug [17:13] .. [17:13] [TOPIC] Incoming Bugs: Bug day report (JFo) [17:14] New Topic: Incoming Bugs: Bug day report (JFo) [17:14] There was no bug day last week. This is a gentle reminder that we have decided to hold a weekly Kernel Bug Day to deal with regression bugs. What this means is that for one day a week we would like for the kernel team to focus on addressing 'regression-' tagged bugs. We'd like to see a significant reduction in the numbers reported above. [17:14] https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.tag=regression-potential+regression-release+regression-proposed+regression-updates&field.tags_combinator=ANY [17:14] The plan, as I see it, is to implement this up to release and then discuss the continued utility of having a Kernel Team Bug Day much like the Bug Days we have now with the community. [17:14] The next Bug Day will be next Tuesday. The focus will be on Bugs with patches attached. As usual, all are welcome to help, and all help is greatly appreciated. :) [17:14] any thoughts? [17:15] seems good, we want a real focus on regressions in lucid [17:15] I think this is a good start [17:15] we can refine as needed [17:15] I'd also like to keep the community focussed bug day stuff [17:15] unless any of you feel that is too much [17:16] JFo, Did yo mention here when that kernel team day will be? [17:16] smb, tue [17:16] I don't think I did here smb [17:16] manjo, THought that is community day [17:16] The Kernel Bug Day will be on Tuesday of every week until release [17:16] ok, so same day [17:17] normally we have a community section [17:17] The community bug days will be scheduled for Tuesdays as well unless we think it should be moved. [17:17] I am flexible on that [17:17] we can discuss offline. [17:17] .. [17:17] [TOPIC] Open Discussion or Questions: Anyone have anything? [17:17] New Topic: Open Discussion or Questions: Anyone have anything? [17:18] o/ [17:18] I do... [17:18] go apw [17:18] We are now basically frozen for Beta-1 (barring kitten killers), I will be pushing out any tasks which required kernel changes to Beta-2 shortly, there is almost nothing in this category. The remainder of our non-release tasks for Beta-1 need focus, and if they aren't going to make it I want to know. [17:18] Several links that you may find useful: [17:18] https://bugs.edge.launchpad.net/~kernel-bugs/+packagebugs [17:18] https://bugs.edge.launchpad.net/~kernel-bugs/+patches?start=50&batch=50 [17:18] .. [17:18] the first is a breakdown of bugs by package [17:18] the second is a view created by the Launchpad team of bugs with patches by age [17:18] the chair has not yet recognized JFo :-) [17:18] apw, when is the last upload you are doing ? before kernel freeze ? [17:18] whoops :) [17:19] manjo, they are already in the pipe [17:19] with a 6 hour build time one needs a days slack [17:20] JFo, you now have the floor [17:20] heh, sorry about that [17:20] cost you a beer for everyone [17:20] the only other thing I have on the above is the fact that the second link is not completely accurate yet [17:20] 192 beers ouch [17:20] :) [17:20] bjf, I'm ok with that for the kernel team ;) [17:21] .. [17:21] anyone else? [17:21] thanks everyone [17:21] #endmeeting [17:21] Meeting finished at 11:21. [17:21] * manjo thanks bjf [17:21] bjf, Ta [17:21] thanks bjf [17:21] thanks bjf [17:21] ta bjf [17:21] apw, my apologies for stomping on your remarks [17:21] :) [17:21] jfo np === mcasadevall is now known as NCommander === jamie is now known as Guest26145 === Guest26145 is now known as JamieBennett === mcasadevall is now known as NCommander === dutchie_ is now known as dutchie === Claudinux_ is now known as Claudinux