[09:46] <lifeless> StevenK: do you stillhave my mini usb adapter?
[09:46] <lifeless> mini-ide--usb that is
[09:50] <StevenK> That's an awfully good question ...
[09:50] <StevenK> I thought I returned it
[09:51] <lifeless> Did I give you the plastic cover, or jsut the guts?
[09:51] <lifeless> reason I ask, isn't because I need it back - I don't atm
[09:51] <lifeless> but because i'm tifying up, if I just gave you the guts and I find a plastic outer, I'll know what to do with it :)
[09:55] <StevenK> You gave me the plastic cover and the guts
[09:56] <lifeless> ok cool
[10:04] <TheMuso> amachu: Hi
[10:06] <persia> Oh, it's a fourth week, isn't it.
[10:07] <lifeless> yah
[10:10] <persia> So we just need freeflying amachu and elky ?
[10:10] <lifeless> that would give us 6
[10:10] <lifeless> what is quora
[10:10] <persia> We've been operating on 4
[10:10] <persia> So any one of them.
[10:11]  * persia has no idea as to the actual determinants or rules, and is loosely guided by the "everyone has veto except when they don't" model
[10:12] <lifeless> only vish is here
[10:12] <lifeless> elky: ping
[10:12] <lifeless> freeflying: ping
[10:12] <lifeless> amachu: ping
[10:13] <persia> Does the string "ping" actually do anything in te default configurations of any clients?
[10:13] <lifeless> annoys people
[10:13] <lifeless> I don't know of a client where it does something special
[10:13] <persia> Well, sure, but how is it different from hilighting in other ways?
[10:14] <persia> Well, I've seen plugins where it automatically gets rejected, sometimes with a contentless-pong response.
[10:14] <lifeless> persia: its not
[10:14] <lifeless> persia: the main thing was <nick>: which is all some clients highlight on
[10:14] <persia> Ah.
[10:26] <TheMuso> so...
[10:26] <freeflying> lifeless: pong
[10:27] <freeflying> lifeless: sorry, for late
[10:27] <persia> lifeless: You remembered about it: you're chair :)
[10:27] <lifeless> persia: amachu emailed us
[10:27] <lifeless> vish: are you there?
[10:27] <vish> hi.
[10:28] <lifeless> persia: do you know how to drive mootbot ?
[10:28] <lifeless> vish: tell us about yourself and your contributions to Ubuntu
[10:28] <vish> Hi.. I'm Vishnoo from Chennai , India. I mainly do artwork , mockups for Ubuntu projects and Triage bug reports in launchpad.
[10:29] <persia> lifeless: You start with "startmeeting" proceeded by '#'
[10:29] <persia> And it gives you instructions in /query
[10:29] <lifeless> #startmeeting
[10:29] <MootBot> Meeting started at 04:29. The chair is lifeless.
[10:29] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[10:30] <vish> A list of the Ubuntu projects for which I'v made contributions are listed in the wiki page. https://wiki.ubuntu.com/vish
[10:30] <vish> Initially, when I started contributing , it more because I was surprised that Ubuntu OS was a community project, and wondered if i could _really_ help make a difference to an OS.
[10:30] <vish> As i got more involved , I got more familiar with the projects ,people and noticed that my contributions were warmly welcomed , appreciated and encouraged.
[10:31] <vish> I started contributing more.
[10:31] <vish> And nowadays I spend a few hours of my day working on Ubuntu projects
[10:31] <lifeless> persia: freeflying: TheMuso: I've got enough; if you have questions for vish please ask away.
[10:32] <lifeless> back in a sec, grabbing more water
[10:32] <amachu> back
[10:32]  * persia is very familiar with vish, and has no specific questions
[10:32] <amachu> got out on a important issue
[10:34] <persia> Hrm, actually, I do have a question.
[10:34] <persia> vish: Why did you not ask for people to support you in this meeting in some of the IRC channels and mailing lists in which you are most active?
[10:34] <lifeless> amachu: no worries, we're doing the do
[10:34] <persia> (or even announce your membership intent)
[10:35] <lifeless> persia: looks like vish got testamonials organised for the meeting - today even
[10:35] <sagaci> is this a membership interview or a public meeting
[10:35] <lifeless> sagaci: yes
[10:36] <vish> persia: oh.. I never knew the memberships need to be announced on mailing lists. I told the people who were most aware of my work to submit testimonials , since I wasnt sure of the timings
[10:37] <persia> vish: Fair enough.  I just didn't see anything about it, but it seems to have worked for you.
[10:37] <lifeless> vish: they don't :P
[10:37] <persia> There's certainly no protocol, but often there's public requests for help in some forum.
[10:37] <lifeless> freeflying: TheMuso: any comments/questions?
[10:38] <TheMuso> not from me.
[10:39] <lifeless> freeflying: if you don't have questions shortly I'll suggest we move to voting
[10:44] <freeflying> lifeless: no
[10:44] <lifeless> so, votes
[10:44] <lifeless> +1 from me
[10:45] <TheMuso> +1 from me also.
[10:45] <persia> +1 : great work.  membership is long overdue.
[10:46]  * persia points out that the nifty [VOTE] feature could be used.
[10:46] <lifeless> persia: you had the chance to organise :P
[10:47] <lifeless> so #stopmeeting
[10:47] <persia> end
[10:47] <lifeless> #stopmeeting
[10:47] <lifeless> #end
[10:47] <lifeless> #endmeeting
[10:47] <MootBot> Meeting finished at 04:47.
[10:47] <persia> But we're looking for another vote.
[10:47] <lifeless> #needsabetterUI
[10:47] <persia> Yes :)
[10:47] <amachu> +1 vish
[10:48] <lifeless> amachu: will you do the group adding and notification ?
[10:48] <amachu> ya ya
[10:48] <amachu> lifeless: sure
[10:48] <lifeless> sweet
[10:48] <vish> thanks all.. :)
[10:48] <lifeless> vish: congrats
[10:49] <hyperair> congrats vish =)
[10:49] <persia> vish: Welcome!
[10:49] <vish> thank you :)
[12:56] <vish> persia: usually how many days does it take to reflect new Ubuntu membership on user's lp teams?
[12:56] <persia> Zero to one.
[12:57] <persia> You're just waiting on amachu to organise things.
[12:57] <vish> ah , ok.. thanks..
[12:57] <persia> Is there something urgent that needs it done *now*?
[12:57] <vish> persia: nah , just curiosity ;)
[12:58] <persia> The entire process of getting membership and all the cascade things usually takes a week or so.
[12:58] <persia> And then you have to go through all the voluntary steps (like arranging and ordering your cards, etc.)
[12:58] <persia> That's usually another week.
[12:58] <vish> yeah..
[12:58] <persia> But there's another meeting about to start.  If you want to discuss more, please /query
[12:59]  * ogra waves
[12:59] <asac> o/
[13:01]  * StevenK shores
[13:01]  * GrueMaster nods
[13:02] <asac> ok guess ncommander isnt here ;)
[13:02] <asac> lets wait another minute or so
[13:02] <ogra> yeah
[13:02] <asac> theni will take the meeting
[13:03] <StevenK> Where will you take it too?
[13:03] <ogra> to the END !
[13:03] <asac> #endmeeting :-P
[13:03] <ogra> heh
[13:04] <asac> plars: persia: dyfet: ping
[13:04] <asac> (persia seems to be here)
[13:04] <plars> hello :)
[13:04] <ogra> plars too :)
[13:04] <asac> dmart: also here?
[13:04] <asac> cooloney: ericm?
[13:04] <dmart> Yeah, hi there
[13:04] <asac> cool. almost complete ;)
[13:04]  * cooloney waves to asac 
[13:05] <asac> #startmeeting
[13:05] <cooloney> eric is in Beijing for business trip.
[13:05] <MootBot> Meeting started at 07:05. The chair is asac.
[13:05] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[13:05] <asac> [LINK] https://wiki.ubuntu.com/MobileTeam/Meeting/2010/20100223
[13:05] <MootBot> LINK received:  https://wiki.ubuntu.com/MobileTeam/Meeting/2010/20100223
[13:05] <asac> [TOPIC] Action Items from February 16th, 2010
[13:05] <MootBot> New Topic:  Action Items from February 16th, 2010
[13:06] <asac> *  * asac to arrange the next thumb2 team sprint. * asac to blog about the ARM alpha-3 release. * asac and JamieBennett to discuss the web office spec and come up with a way of moving it forward. * NCommander to link power management spec to dove bugs * GrueMaster to produce a daily report on image testing and add that to the weekly meeting page. * ogra to produce a rootstock test plan.
[13:06] <asac>  * NCmmander to in vestigate KDE FTBFS issues. * Team to add individual summaries to standing items before meetings.
[13:06] <asac> ooops ;)
[13:06] <asac>  * asac to arrange the next thumb2 team sprint.
[13:06] <ogra> https://wiki.ubuntu.com/ARM/RootstockTestplan
[13:06] <asac>  * asac to blog about the ARM alpha-3 release.
[13:06] <asac>  * asac and JamieBennett to discuss the web office spec and come up with a way of moving it forward.
[13:06]  * persia rushes to try to complete the last of those quick-like
[13:06] <asac>  * NCommander to link power management spec to dove bugs
[13:06] <asac>  * GrueMaster to produce a daily report on image testing and add that to the weekly meeting page.
[13:06] <asac>  * ogra to produce a rootstock test plan.
[13:06] <asac>  * NCommander to investigate KDE FTBFS issues.
[13:06] <asac>  * Team to add individual summaries to standing items before meetings.
[13:06] <asac> ok ... so thumb2 team sprint
[13:07] <asac> i wanted to get a confirm of time before sending out mail to mobile ... 1100 UTC is what i have
[13:07] <asac> on Thu
[13:07] <asac> does that match what we discussed?
[13:07] <persia> Yes, although we were going to do it last week :)
[13:07] <asac> no
[13:07] <ogra> yeah
[13:07] <ogra> matches
[13:07] <dyfet> yep
[13:08] <asac> ok i will send the reminder out right after
[13:08] <asac> [ACTION] asac to blog about the ARM alpha-3 release.
[13:08] <MootBot> ACTION received:  asac to blog about the ARM alpha-3 release.
[13:08] <asac> this week is a3
[13:08] <asac> so that matches
[13:08] <asac> * asac and JamieBennett to discuss the web office spec and come up with a way of moving it forward.
[13:08] <ogra> friday is blogging day then :)
[13:08] <asac> -> we discussed this and found a good compromise using zoho viewer api
[13:08] <asac> stay tuned
[13:09] <asac> * NCommander to link power management spec to dove bugs
[13:09] <asac> -> did this happen, ogra?
[13:09]  * NCommander kills his laptop
[13:09] <asac> hi NCommander
[13:09]  * ogra checks
[13:09] <NCommander> hey asac, sorry for being late
[13:09] <asac> no problem ;) ... now i am the lead ;)
[13:09] <NCommander> needs a c/o
[13:09]  * StevenK waits for -!- NCommander has quit [Ping timeout]
[13:09] <asac> StevenK: done
[13:09] <ogra> NCommander, did you add the dove PM bugs to https://blueprints.edge.launchpad.net/ubuntu/+spec/mobile-lucid-arm-per-soc-powermanagement ?
[13:09] <ogra> i dont see them there
[13:09] <NCommander> ogra: no, it needs a c/o
[13:10] <ogra> (and didnt get a notification)
[13:10] <asac> [ACTION] NCommander to link power management spec to dove bugs
[13:10] <MootBot> ACTION received:  NCommander to link power management spec to dove bugs
[13:10] <ogra> NCommander, do it now, its three clicks ;)
[13:10] <asac> * GrueMaster to produce a daily report on image testing and add that to the weekly meeting page.
[13:10] <asac> ?
[13:10] <GrueMaster> C/o
[13:10]  * asac carries that over
[13:10] <asac> can we get that for next week?
[13:11] <asac> [ACTION] GrueMaster to produce a daily report on image testing and add that to the weekly meeting page
[13:11] <MootBot> ACTION received:  GrueMaster to produce a daily report on image testing and add that to the weekly meeting page
[13:11] <asac> * ogra to produce a rootstock test plan.
[13:11] <asac> -> seems to be done
[13:11] <ogra> https://wiki.ubuntu.com/ARM/RootstockTestplan
[13:11] <asac> 14:06 < ogra> https://wiki.ubuntu.com/ARM/RootstockTestplan
[13:11] <asac> right
[13:11] <ogra> promoted to plars and GrueMaster last night
[13:11] <asac> * NCommander to investigate KDE FTBFS issues.
[13:11] <asac> NCommander: any progress on kde?
[13:11] <NCommander> asac: its a segfault in kdebindings, but I haven't managed to run it down due to lack of time last week
[13:12] <asac> ok ... makes sense to keep it on your list?
[13:12] <ogra> asac, there are more urgent FTBFS since beginning of the week
[13:12] <persia> NCommander: Riddell specifically asked that it be sorted soon, or smoke disabled for armel in the run up to alpha 3.
[13:12] <ogra> (which i asked NCommander to look at with help from dyfet )
[13:12] <persia> NCommander: Needs to be today for a decision because of the freeze.
[13:12] <ogra> we need these to be fixed for A3
[13:12] <ogra> they are all apps that are on the images
[13:12] <asac> so basically today
[13:13] <NCommander> probably best to disable smoke for kdebindings then
[13:13] <ogra> thats why i asked NCommander early :)
[13:13] <asac> ogra: whats the package list blocking a3 atm?
[13:13] <ogra> but i still see all of them
[13:13] <asac> evince i guess
[13:13] <persia> NCommander: Please do that then :)
[13:13] <asac> eog
[13:13] <asac> wow
[13:13] <ogra> asac, keyring and two indicators are FTBFS
[13:13] <ogra> beyond that gtk is our of sync but should be fine soon
[13:13] <ogra> *out
[13:13] <asac> eog is an out of synx thing
[13:14] <persia> I looked at a lot of these earlier: most of them are failed detections of gtk+2.0 depwait
[13:14] <ogra> yeah
[13:14] <asac> ogra: ok. are the gtk bits there? maybe just give back
[13:14] <persia> squid is the big one, but zul is on it.
[13:14] <ogra> right
[13:14] <persia> (with help from lool)
[13:14] <asac> ogra: gtk failed to build
[13:14] <ogra> keyring and the two indicators are the issues
[13:14] <asac> https://launchpad.net/ubuntu/+source/gtk+2.0/2.19.5-1ubuntu5/+build/1526418/+files/buildlog_ubuntu-lucid-armel.gtk+2.0_2.19.5-1ubuntu5_FAILEDTOBUILD.txt.gz
[13:14] <asac> so top prio is gtk
[13:14] <ogra> indeed
[13:14] <asac> seg fault
[13:14] <asac> try again
[13:14] <ogra> though there was just an upload 1/2h ago
[13:14] <asac> really?
[13:15]  * asac goes and kicks seb
[13:15] <ogra> ubuntu6
[13:15] <ogra> its bratches fault :)
[13:15] <persia> seb128 seems to be all over the gtk stuff, in good ways.
[13:15] <ogra> *bratsche
[13:15] <asac> done
[13:15] <ogra> seb is only uploading
[13:15] <asac> right. seb could hold it back next time
[13:15] <persia> Well, and paying attention to failures and complaining at folks :)
[13:15] <ogra> asac, no, he couldnt
[13:16] <ogra> there was a bad bug that made many desktops freeze
[13:16] <ogra> he and bratsche worked on it for days now
[13:16]  * ogra was affected 
[13:16] <ogra> Bug 523949
[13:17] <ogra> so the upload was essential
[13:17] <asac> ogra: right
[13:17] <asac> ok
[13:17] <ogra> lets see if ubuntu6 gets through
[13:17] <ogra> i'll catherd it
[13:17] <asac> so we need to work on gtk and then wrap up the ftbfs list from there
[13:17] <asac> ogra: you said indicators are really failing to build?
[13:17] <ogra> NCommander, dyfet please take a look at gnome-keyring and the two indicators
[13:17] <persia> gtk and kdebindings should handle most of it.
[13:17] <ogra> asac, indicator-sound at least
[13:17] <ogra> i think there was another one
[13:17]  * ogra looks
[13:18] <asac> checking for SOUNDSERVICE... configure: error: Package requirements (dbusmenu-glib >= 0.1.1 indicator >= 0.3.0 libpulse-mainloop-glib >= 0.9.19
[13:18] <asac> feels like something out of date
[13:18] <dyfet> NCommander: ok
[13:18] <ogra> ah, only -sound now
[13:18] <persia> That's probably related to the recent pulse update.
[13:19] <persia> (press the shiny button)
[13:19] <ogra> i gave it back already once
[13:19] <asac> ok I look into gtk and indicator build failures with dyfet and maybe NCommander
[13:19] <asac> lets move on
[13:19] <asac> *  Team to add individual summaries to standing items before meetings.
[13:19] <ogra> i'll care for gtk
[13:19] <asac> reminder: please do that ;)
[13:19]  * NCommander did :-)
[13:19] <StevenK> Hint: it's no longer before the meeting
[13:19] <ogra> next time, sorry ... /me missed
[13:19] <asac> everyone  missed.
[13:20] <asac> so whip cracking: that would be really cool to have ;)
[13:20] <asac> you can also include that in the AR mail if you send one
[13:20] <asac> befor the meeting
[13:20] <asac> NCommander: yes. you are great!!
[13:20] <ogra> good idea
[13:20] <asac> [TOPIC] Standing items
[13:20] <MootBot> New Topic:  Standing items
[13:20] <ogra> bah, lots of red
[13:20] <asac> lets take a last look at alpha-3 thing
[13:21] <asac> [LINK] http://people.canonical.com/~pitti/workitems/canonical-mobile-lucid-alpha-3.html
[13:21] <MootBot> LINK received:  http://people.canonical.com/~pitti/workitems/canonical-mobile-lucid-alpha-3.html
[13:21] <asac> so last week before release meeting i bumped a bunch o items to beta-1
[13:21] <asac> http://people.canonical.com/~pitti/workitems/canonical-mobile-ubuntu-10.04-beta-1.html
[13:21] <MootBot> LINK received:  http://people.canonical.com/~pitti/workitems/canonical-mobile-ubuntu-10.04-beta-1.html
[13:21] <asac> i made have made a mistake in syntax here and there
[13:22] <asac> please ensure that all of the work items for alpha-3 are moved to ubuntu-10.04-beta-1
[13:22] <asac> [ACTION] everyone to move work items not finished for alpha-3 to ubnutu-10.04-beta-1
[13:22] <MootBot> ACTION received:  everyone to move work items not finished for alpha-3 to ubnutu-10.04-beta-1
[13:22] <asac> the main two specs for beta-1 are webservice email/office.
[13:22]  * ogra notes that apw just did that on the powermanagement one 
[13:22]  * ogra hugs apw 
[13:23] <asac> those will need to be finished by end of this week/early next week ... otherwise release team will kick me ;)
[13:23] <ogra> what about the browser ?
[13:23] <ogra> still has many open items
[13:23] <asac> i have to check if they dropped the final comment
[13:24] <asac> security team that is
[13:24] <ogra> was there a decision now ?
[13:24] <asac> as it stands now we consider chromium not supportable
[13:24] <ogra> ok
[13:24] <asac> we will try to support it in universe and learn from it
[13:24] <asac> if all goes well, we can go for it next cycle
[13:24] <persia> asac: You're keeping the MIR bug up to date about that?
[13:24] <ogra> ++
[13:24]  * persia knows that several external groups are subscribed
[13:24] <asac> persia: that was the idea
[13:25] <persia> Cool!
[13:25] <asac> persia: i asked kees to give a final statement from security team - which was supposed to happen on friday
[13:25] <asac> i have to check if that happened
[13:25]  * persia checks the bug
[13:25] <asac> so yeah ... all the browser items will get done once that decision is there
[13:25] <persia> ( bug #522645 for those who wish to follow along )
[13:25] <asac> everything left there in my book was blocked by decision
[13:26] <asac> ok anything else on work itesm? anyone feels like they are out of work?
[13:26] <ogra> once rootstock is done i'll have some spare cycles
[13:26] <ogra> i should be doen fully by end of the week with the GUI
[13:26] <asac> good. with some luck those will be directly consumed by a new project ;)
[13:26] <ogra> so feel free to put something up for me
[13:26] <dholbach> if anybody feels like they are out of work, I'd like to remind everybody of: http://people.canonical.com/~dholbach/sponsoring/ - it really needs some hands on deck no
[13:27] <dholbach> (and it lists unr packages too)
[13:27]  * ogra tickles dholbach 
[13:27]  * dholbach hugs ogra
[13:27] <StevenK> It isn't UNR
[13:27] <asac> dholbach: can you ensure that sponsored uploads without bugs also get in the company sponsoring report ;)?
[13:27] <asac> that reminds me ... dholbach was looking for open week contributions
[13:27] <dholbach> asac: sponsored uploads should get there
[13:27] <asac> cool
[13:27] <dholbach> https://wiki.ubuntu.com/Packaging/Training
[13:27] <asac> maybe we can run a session on how to develop for arm using qemu static etc.?
[13:27] <dholbach> StevenK: sorry, I meant the 'unr' packageset
[13:28] <asac> dholbach: would that help?
[13:28] <dholbach> StevenK: which overlaps with other sets
[13:28] <dholbach> asac: that'd be cool
[13:28] <dholbach> asac: and I'll talk to bdrung too
[13:28] <asac> [ACTION] asac to talk to team about training session
[13:28] <MootBot> ACTION received:  asac to talk to team about training session
[13:29] <asac> ok moving on ;) ...
[13:29] <dholbach> thanks a lot everybody! and I hope there's many good fixes for *mobile* in the sponsoring queue
[13:29] <asac> [TOPIC] Standing Items - Kernel Status (cooloney, ericm)
[13:29] <MootBot> New Topic:  Standing Items - Kernel Status (cooloney, ericm)
[13:29] <cooloney> for imx51 kernel,
[13:29] <cooloney> we updated to latest fsl bsp release
[13:29] <ogra> works fine :)
[13:30] <cooloney> after fixing a compiling error (i sent that patch to fsl)
[13:30] <ogra> though i'D still like to see bug 457878 fixed before release
[13:30] <cooloney> it was uploaded alreayd
[13:30] <ogra> cooloney, a fix for that bug ?
[13:30] <plars> cooloney: did it make it in time for the A3 image?
[13:30] <cooloney> and apw also applied 2 VFP sig patches
[13:31] <ogra> then it didnt work ... at least not in my tests
[13:31] <ogra> i still dont see any plug/unplug events for the NIC
[13:31] <cooloney> ogra and plars, oh, it needs some work for a3
[13:31] <cooloney> i don't think we can make it
[13:31] <asac> cooloney: dodes that fix bug 507503 ?
[13:31] <ogra> well, i'm not concerned about A3
[13:31] <plars> we will retest in the following daily images then
[13:31] <ogra> but would like it for final
[13:32] <cooloney> this bug is because fsl fec driver does not support link status change
[13:32] <ogra> right
[13:32] <cooloney> yeah, that VFP signal bug should be fixed in latest uploads
[13:33] <asac> cooloney: so VFP is in a3 ... bug 457878 is waiting for upstream fix?
[13:33] <ogra> cooloney, did that also go into the SRU for karmic ?
[13:33] <cooloney> ogra: actually, i have not been thinking about karmic for a long time, heh
[13:34] <ogra> well, there was an SRU last week
[13:34] <ogra> for the NEON stuff
[13:34] <cooloney> ogra: that is another bug
[13:34] <persia> Well, except bug #507416 only contains half the fix for NEON, so it's not enough.
[13:34] <cooloney> bug 507416
[13:34] <ogra> right, but wouldnt it affect karmic as well if NEON is used ?
[13:35] <persia> Since we have to get something else into -proposed anyway, we may as well see if 457878 can be included then.
[13:35] <cooloney> persia: i just talked with dmart
[13:35] <persia> cooloney: And?
[13:35] <asac> cooloney: according to bug 507503 ... the VFP thing isnt fixed in current archive version ... what was uploaded by apw ?
[13:35] <cooloney> for the 2nd patch, we found our workaround method does not work on imx51 A8 based soc
[13:35] <ogra> asac, we just got as test request from him
[13:35] <cooloney> because we can not disable NEON hardware in kernel
[13:36] <cooloney> by setting ASEDIS bit
[13:36] <cooloney> ASEDIS is only available in A9 processor
[13:36] <dmart> But since karmic didn't have that anyway, we're not making it worse.
[13:36]  * JamieBennett appears with new tires :)
[13:36] <persia> OK.  So 507416 doesn't fix the issue, but there's no regression potential?
[13:37] <dmart> There's no regression.
[13:37] <dmart> this is a preexisting issue
[13:37] <cooloney> right,
[13:38] <cooloney> so i think currently we can't do anymore to workaround this issue on old silicon
[13:38] <persia> OK.  Someone (who understands better than I) needs to update the bug with a comment explaining that it's unfixable with the current approach, but that the patch doesn't cause regressions, otherwise it will block the rest of the SRU kernel.
[13:38] <asac> cooloney: so you are saying tha the VFP part of 507503 is fixed , but NEON is not? maybe we should split this bug up so we can close the first half?
[13:38] <asac> (talking about lucid here)
[13:39] <cooloney> persia: no problem, i will do that.
[13:39] <cooloney> asac: yeah, patches are applied and kernel was uploaded
[13:39] <dmart> asac: 507503 is not neon-specific, it's just an issue common to NEON and VFP
[13:39] <asac> cooloney: why wasnt the bug closed in the upload then?
[13:40] <cooloney> asac: that is because the 2 patches is from upstream
[13:40] <asac> cooloney: ok, so lets close the bug?
[13:40] <cooloney> we applied them and don't want to change their description by adding our syntax such as BugLink
[13:40] <asac> kk
[13:41] <cooloney> so if there is no such BugLink, it will not be closed automatically
[13:41] <cooloney> i will close it manually.
[13:41] <asac> thanks
[13:41] <asac> ok ericm isnt here
[13:41] <asac> so we skip dove for now (maybe he will appear later)
[13:41] <cooloney> no, he is on a business trip
[13:42] <asac> ah right.
[13:42] <asac> [TOPIC] ARM Application status (JamieBennett, dyfet)
[13:42] <MootBot> New Topic:  ARM Application status (JamieBennett, dyfet)
[13:42] <cooloney> but if you guys have something, can tell me
[13:42] <asac> cooloney: thx
[13:42] <cooloney> i will talk with him, since we are in the same TZ
[13:42] <asac> so think on the application front we are fine MINUS the webservices specs
[13:42] <JamieBennett> 2D launcher fun
[13:42] <asac> netbook-launcher even has 2d fallback
[13:42] <asac> ah right ... go ahead JamieBennett
[13:43] <JamieBennett> 2D launcher respawn problem is there
[13:43] <asac> right
[13:43] <asac> thats bug #525854
[13:43] <JamieBennett> web office services have initial code available
[13:43] <asac> ak ... will review it today
[13:43] <JamieBennett> needs a little more work and integration
[13:44] <JamieBennett> otherwise looking semi-ok package wise
[13:44] <JamieBennett> getting quite a few 2D launcher bugs though
[13:44] <asac> JamieBennett: oh, you already have packaging even?
[13:44] <JamieBennett> not for web office meant image packages in general
[13:45] <asac> right
[13:45] <asac> ok
[13:45] <JamieBennett> I'll package web office on Friday
[13:45] <asac> JamieBennett: so what are the most pressing bugs for launcher (besides the respawn issue)
[13:45] <ogra> yeah 2D launcher will need a lot of work
[13:45] <ogra> bugs are piling up
[13:45] <asac> i assume the scroll bar thing is one ... whats the bug id?
[13:45] <ogra> https://bugs.launchpad.net/ubuntu/+source/netbook-launcher-efl
[13:45] <ogra> 15 open bugs now
[13:46] <JamieBennett> I've seen log out bugs, the respawn, mounting issues (although there was a fix available for this)
[13:46] <ogra> over the last week we got 10 new ones
[13:46] <asac> we have 15 bugs there ;) ... piling up is different term ;)
[13:46] <JamieBennett> yeah
[13:46] <asac> ok
[13:46] <JamieBennett> maybe we need to review them one by one
[13:46] <JamieBennett> and decide what are blockers
[13:46] <asac> [ACTION] asac and JamieBennett to triage netbook-launcher-efl bugs
[13:46] <MootBot> ACTION received:  asac and JamieBennett to triage netbook-launcher-efl bugs
[13:47] <asac> and forward accordingly
[13:47] <JamieBennett> indeed or help mterry out
[13:47] <asac> [LINK] https://bugs.launchpad.net/ubuntu/+source/netbook-launcher-efl
[13:47] <MootBot> LINK received:  https://bugs.launchpad.net/ubuntu/+source/netbook-launcher-efl
[13:47] <asac> ok ... anything else on app?
[13:47] <JamieBennett> no, move on
[13:48] <asac> i think i missed the previous one ...
[13:48] <asac> [TOPIC] QA Status (GrueMaster, plars)
[13:48] <MootBot> New Topic:  QA Status (GrueMaster, plars)
[13:48] <plars> A3 alpha testing should start real soon
[13:48] <plars> there's a desktop image listed out there right now, please ignore
[13:48] <ogra> asac, skipping FTBFS ?
[13:48] <asac> ogra: i moved backwards
[13:48] <plars> netbook images should be available soon (?) anyone looking at the libgtk2.0 issue?
[13:48] <ogra> ah
[13:49] <StevenK> Which will no longer work, since I just purged it off cdimage
[13:49] <GrueMaster> Couple of issues with the installer last week.  Hopefully they are fixed with the new images.  Fix was uploaded last night but I couldn't download all the packages to test due to availability.
[13:49] <asac> plars: do you have a link to the right qa tracker?
[13:49] <ogra> plars, no issue just catherding the build, its on my list
[13:49] <plars> asac: it should still be under the armel section on iso tracker
[13:49] <plars> http://iso.qa.ubuntu.com
[13:49] <MootBot> LINK received:  http://iso.qa.ubuntu.com
[13:49] <plars> specifically: http://iso.qa.ubuntu.com/qatracker/build/ubuntuarm/all
[13:50] <NCommander> (indiciator-sound is available for ARM now)
[13:50] <asac> GrueMaster: ok. maybe add a list of not yet fixed installer bugs to the QA status after the meeting
[13:50] <asac> GrueMaster: or after testing ;)
[13:50] <asac> NCommander: thanks!
[13:50] <GrueMaster> Yes, after testing.
[13:51] <asac> was there progress on all-pairs testing?
[13:51] <ogra> NCommander, cool, leaves only keyring ...
[13:51] <GrueMaster> Read my status.
[13:51] <NCommander> ogra: looking at keyring now
[13:51] <GrueMaster> Or AR
[13:51] <asac> GrueMaster: we are here to report that ;)
[13:51] <asac> unless its added to the QA status
[13:51] <GrueMaster> Ok.  No progress due to ubiquity issues.
[13:52] <asac> Bug 524169
[13:52] <asac> GrueMaster: that bug wsa discovered by all-pairs?
[13:53] <asac> e.g. it doesnt show up in our normal image testing?
[13:53] <GrueMaster> That bug was discovered before getting to the all-pairs selections.
[13:53] <asac> ok
[13:53] <GrueMaster> I.e. That bug shows up in EVERY install test.
[13:53] <asac> anything else on QA?
[13:54] <asac> ok lets move on ...
[13:54] <asac> thanks GrueMaster, plars
[13:54] <GrueMaster> X0 kernel fixed several bugs.  I retested several bugs filed prior to Sprint and marked them closed.
[13:54] <asac> great. thanks a lot
[13:54] <asac> i see that in your AR now
[13:54] <asac> [TOPIC] ARM Porting/FTBFS status (NCommander, dyfet)
[13:54] <MootBot> New Topic:  ARM Porting/FTBFS status (NCommander, dyfet)
[13:54] <NCommander> indicator-sound fixed, looking at gnome-keyring
[13:55] <asac> NCommander: added it to the wiki
[13:55] <asac> and we already discussed a bit on gtk etc. above
[13:55] <asac> anything else?
[13:55] <NCommander> w.r.t. to openoffice.org, I'm looking at bisecting binutils
[13:55] <asac> NCommander: did you create a wiki page for ooo?
[13:55] <NCommander> asac: no
[13:55] <asac> we should really document all the things we tried
[13:55] <NCommander> asac: that's what the bug is for
[13:55] <asac> [ACTION] NCommander to create wiki page to track actions taken to evaluate ooo/uno issues
[13:55] <MootBot> ACTION received:  NCommander to create wiki page to track actions taken to evaluate ooo/uno issues
[13:56] <ogra> the bug didnt have updates either :)
[13:56] <asac> NCommander: we want more than the bug imo ... unless you want to post all the steps done there even if they have no positive outcome
[13:56]  * NCommander needs more external HDDs :-/
[13:56] <NCommander> asac: that's the point of Launchpad; and having a bug. Take a look what I already posted
[13:57] <asac> ok
[13:57] <NCommander> Anyway, bisecting the toolchain has proven difficult on lucid due to thumb2 support lacking in binutils 2.19
[13:57] <NCommander> So I'm going to work against karmic on this
[13:57] <ogra> one comment
[13:57] <ogra> which was declined by doko
[13:58] <NCommander> ogra: you should also check the OOo bugtracker. I'll make sure to cross-post better
[13:58] <ogra> right, on the bug itself there isnt much ...
[13:58] <ogra> so the wikipage really makes sense
[13:58] <asac> NCommander: ok. so you are trying to bisect binutils now ... any other lead?
[13:59] <asac> NCommander: please keep everything in th elaunchpad bug
[13:59] <asac> NCommander: in the end we need to prove that we tried everything. i want all the bits together in one place
[13:59] <NCommander> asac: well, I determined that we're dealing with some sorta stack corruption
[13:59] <asac> whats the bug id? (would like to have it as link)
[14:00] <ogra> Bug 417009
[14:00] <NCommander> You can call into uno all you want, the abort comes when a process quits or something pops far enough in the stack to hit the corruption
[14:00] <asac> [TOPIC] openoffce uno issues
[14:00] <MootBot> New Topic:  openoffce uno issues
[14:00] <asac> https://launchpad.net/bugs/417009
[14:00] <asac> [LINK] https://launchpad.net/bugs/417009
[14:00] <MootBot> LINK received:  https://launchpad.net/bugs/417009
[14:01] <asac> ok ...anything else on ftbfs? (i think everything else needs to be discussed offline on ooo)
[14:01] <asac> [TOPIC] ARM Image Status (ogra, persia)
[14:01] <MootBot> New Topic:  ARM Image Status (ogra, persia)
[14:01] <ogra> image from 22th looked ok ...
[14:01] <ogra> todays failed because of gtk
[14:02] <persia> For *all* the imags tha tbuilt.
[14:02] <persia> But why don't we have ubuntu-* or xubntu-* images for dove?
[14:02] <asac> wasnt xubuntu disabled?
[14:02] <ogra> yeah
[14:02] <persia> I had thought so, but it seems to have come back.
[14:02] <asac> also i thought we wanted to stop producing ubuntu-
[14:02] <GrueMaster> Image from the 22nd had the installer bug.  Bug 524169
[14:02] <ogra> we'Re really short on livefs builder time
[14:02] <dmart> 20100222 has some issues (installer doesn't work and rsyslogd hogs the CPU) but I don't think those are armel-specific.
[14:03] <ogra> dmart, the latter is
[14:03] <asac> rsyslogd?
[14:03] <ogra> and the last kernel upload has a fix for rsyslogd
[14:03] <persia> Well, it's kernel-specific to the armel kernel.
[14:03] <ogra> yeah
[14:03] <asac> really? i was told it was not arm specific ... rather old kernel
[14:03] <persia> But not otherwise arch-specific.
[14:03] <ogra> asac, right, imx51 is .31
[14:03] <dmart> ok; non-armel people were reporting it, but maybe on old kernels
[14:03] <asac> anyone has the bug number for rsyslogd?
[14:03] <ogra> it needed a feature backported
[14:04] <ogra> bug 523610
[14:04] <asac> [LINK] https://launchpad.net/bugs/523610
[14:04] <MootBot> LINK received:  https://launchpad.net/bugs/523610
[14:04] <ogra> apw is the hero that fixed it on the go :)
[14:04] <persia> dmart: Yes.  There's a few folk running .31 kernels (especially realtime users)
[14:04] <ogra> persia, which isnt supported anyway by words of Keybuk
[14:05] <asac> so anyone takes action to investigate why xubuntu etc. are built again?
[14:05] <ogra> StevenK, ^^^ ?
[14:05] <persia> ogra: I've been told the opposite by rtg.  I suspect we need to bring them together.
[14:05] <asac> [ACTION] StevenK and persia to ensure that xubuntu- ubuntu- images are not produced for armel anymore
[14:05] <MootBot> ACTION received:  StevenK and persia to ensure that xubuntu- ubuntu- images are not produced for armel anymore
[14:05] <StevenK> Don't bother, I just fixed it
[14:05] <ogra> asac, -desktop was completely ripped out right before the meeting
[14:05] <StevenK> Like, ten minutes ago
[14:05] <ogra> StevenK, xubuntu too ?
[14:05] <persia> asac: Can we add kubuntu-desktop to that list, and only do *-netbook and server images?
[14:06] <StevenK> ogra: I didn't bin the images, but I can
[14:06] <ogra> yeah, they will be hevily outdated
[14:06] <ogra> persia, ++
[14:06] <asac> [ACTION] StevenK and persia to also get rid of kubuntu-desktop aka everything != server | netbook
[14:06] <MootBot> ACTION received:  StevenK and persia to also get rid of kubuntu-desktop aka everything != server | netbook
[14:07] <asac> anything else on image?
[14:07] <ogra> not from me
[14:07] <asac> [TOPIC] AOB
[14:07] <MootBot> New Topic:  AOB
[14:07] <asac> anyone?
[14:07] <ogra> please test the GUI after my next rootstock upload  :)
[14:08] <asac> [ACTION] everyone to try rootstock GUI once its in the archive
[14:08] <MootBot> ACTION received:  everyone to try rootstock GUI once its in the archive
[14:08] <ogra> it is in the archive :)
[14:08] <asac> latest
[14:08] <GrueMaster> ogra: I have it on my todo for after Aplha 3.
[14:08] <ogra> try the 0.2.0 release :)
[14:08] <asac> good. anything else?
[14:08] <ogra> right, that upload wont happen during freeze anyway
[14:09] <asac> ogra: rootstock is in main?
[14:09] <asac> on CD?
[14:09] <ogra> nope
[14:09] <asac> just upload
[14:09] <ogra> and i dont want it in main yet :)
[14:09] <asac> its not covered by freeze then
[14:09] <ogra> asac, indeed, but i'm busy with A3 stuff anyway
[14:09] <asac> thought its ready?
[14:10] <asac> anyway. do it when you have time ;)
[14:10] <asac> anything else for AOB?
[14:10] <asac> 3
[14:10] <asac> 2
[14:10] <asac> 1
[14:10] <asac> #endmeeting
[14:10] <MootBot> Meeting finished at 08:10.
[14:10] <asac> thanks all
[14:11] <asac> Logs available at http://www.novarata.net/mootbot/
[14:57] <kees> \o
[14:58] <cjwatson> hi
[14:58] <cjwatson> sabdfl sent apologies via randa
[14:59] <cjwatson> mdz sent notification of attention being partially elsewhere
[14:59] <cjwatson> and Keybuk hasn't been seen around on IRC for a while
[14:59] <pitti> o/
[14:59] <pitti> hm, 3 is not quorum yet, is it?
[15:00] <cjwatson> I think the TB has traditionally considered 50% as quorum
[15:00] <cjwatson> with any luck mdz will be available for votes
[15:01] <mdz> cjwatson, maybe
[15:01] <mdz> IMO 3 is a quorum though
[15:01] <kees> we'd never have meetings if we didn't consider 50% as quorum.  :P
[15:02] <cjwatson> Keybuk isn't around, and I don't think I can effectively chair - too much of my head is occupied trying to work out this crazy memory corruption in d-i
[15:03] <kees> cjwatson: I can chair; I just can't find the Feb 9th meeting notes ... looking still
[15:03] <cjwatson> thanks
[15:03] <pitti> hm, I'm fairly sure I put them in, hang on
[15:04] <kees> pitti: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2010-February/000673.html
[15:04] <cjwatson> I am getting further and further down rabbit-holes here - current one is that newt doesn't seem to build for me
[15:04] <kees> pitti: I didn't see them in https://wiki.ubuntu.com/TeamReports/February2010 though
[15:04] <kees> anyway,
[15:04] <kees> #startmeeting
[15:04] <pitti> kees: https://wiki.ubuntu.com/TechnicalBoard/TeamReports/Current
[15:04] <MootBot> Meeting started at 09:04. The chair is kees.
[15:04] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[15:04] <cjwatson> the agenda didn't seem to get flushed from last time
[15:04] <cjwatson> moment while I edit it?
[15:04] <kees> pitti: "current" should be a link to the per-month report
[15:04] <cjwatson> err, highvoltage has it open
[15:05] <highvoltage> cjwatson: closing...
[15:05] <highvoltage> cjwatson: ok done
[15:05] <cjwatson> the first two items under archivereorg were done, anyway
[15:05] <kees> pitti: i.e. echnicalBoard/TeamReports/10/February
[15:05] <cjwatson> thanks
[15:05] <kees> +T
[15:06] <kees> cjwatson: let me know when you're done with it
[15:06] <cjwatson> ok, done with the agenda now
[15:06] <kees> heh ok
[15:06] <cjwatson> https://wiki.ubuntu.com/TechnicalBoard/TeamReports/Current has been busted
[15:06] <cjwatson> it used to be a redirect
[15:06] <mdz> cjwatson, kees, pitti, please mention me if you need my input on something, otherwise my attention will be on the phone
[15:06] <pitti> mdz: unterstood, thanks
[15:06] <cjwatson> cf. https://wiki.ubuntu.com/TechnicalBoard/TeamReports/Current?action=diff&rev2=11&rev1=8
[15:06] <cjwatson> I will go and fix it up
[15:06] <kees> [TOPIC] Review actions from last meeting
[15:06] <MootBot> New Topic:  Review actions from last meeting
[15:07] <kees> * kees to follow up with Debian TC on units policy
[15:07] <kees> I haven't heard anything new from bdale
[15:07] <kees> * cjwatson to follow up with mythbuntu-dev to get ubuntu-core-dev added
[15:08] <cjwatson> done ages ago
[15:08] <kees> * ScottK to update Kubuntu/UpdatesPolicy based on Kubuntu upstream feedback
[15:08] <kees> looks like this happened?
[15:08] <kees> http://techbase.kde.org/Policies/Minor_Point_Release_Policy/Draft
[15:08] <MootBot> LINK received:  http://techbase.kde.org/Policies/Minor_Point_Release_Policy/Draft
[15:08] <Riddell> kees: still needs approval upstream
[15:09] <kees> Riddell: ah, okay.
[15:09] <kees> * sabdfl to propose to CC that the TB is a CC delegate, and clarify his role
[15:09] <cjwatson> I've fixed the team reports stuff
[15:09] <kees> cjwatson: cool, thanks
[15:09] <kees> I don't know what happens at CC, so I don't know if the CC delegate thing has happened yet
[15:10] <kees> were there other actions?  that's all I see from the last report
[15:10] <pitti> AFAIK these were the pending ones
[15:11] <kees> okay, cool
[15:11] <kees> [TOPIC] Have delegated teams become responsible for security of their packagesets
[15:11] <MootBot> New Topic:  Have delegated teams become responsible for security of their packagesets
[15:11] <kees> so, this came up while trying to figure out how motu-swat (the MOTU security team) fits into archive-reorg
[15:11] <cjwatson> are you including, say, ubuntu-core-dev? :-)
[15:11] <kees> cjwatson: possibly, yes.
[15:12] <cjwatson> well, I was just wondering what was left for the security team to do then ;-)
[15:12] <kees> they idea here is that teams should be responsible for security issues in their packagesets.
[15:12] <kees> well, I was thinking that the Ubuntu security team still tracks CVEs globally, but would benefit from fixing help.
[15:13] <cjwatson> it makes sense for teams to be paying attention to such things in a more organised fashion than right now; I'm not sure "responsible" is the right word, since I think the security team still has to be ultimate buck-stops-here
[15:13] <kees> yes, agreed; that language should change.
[15:13] <mdz> kees: I reordered the agenda to put the new topics ahead of the old; hope that's OK
[15:13] <pitti> kees: I was going to say that I don't think it's very efficient to split tracking into multiple teams
[15:13] <kees> I think the idea was to try to spur more involvement.
[15:13] <kees> mdz: saw that, it's fine.
[15:14] <pitti> because then the CVE triage would be done five times instead of once?
[15:14] <cjwatson> and I like the idea of having somebody from each team actively engaged with the security team, provided that the security team assists them with tools
[15:14]  * kees has chosen poorly wrt language here.
[15:14] <pitti> kees: so you propose central tracking/distributed fixing? or distributed tracking as well?
[15:14] <kees> I would like to see delegated teams being _aware_ of CVEs in their packagesets.
[15:15] <cjwatson> perhaps it would make sense for the security team to explicitly put things onto delegated teams' work lists, after triage?
[15:15] <pitti> kees: aware == tracking, though?
[15:15] <kees> pitti: yes, central tracking/distributed fixing.  especially true for non-seeded packages.
[15:15] <pitti> it's a huge difference between "dear desktop team can you please upload a fix for CVE-1234" or "please go find all that we need to fix"
[15:16] <kees> pitti: I need to find language for "is aware of the CVE and thinking about how to fix it once the CVE has been identified by the security team, or the team becomes aware of a security issue and communicates it to the security team"
[15:16] <pitti> and my gut feeling is that centralized tracking is more efficient
[15:16] <cjwatson> so, what specifically needs to change?  somebody in each team (default: team lead) should take responsibility for liaising with the security team, and is expected to have mail filters such that they see CVEs as a priority, something like that?
[15:16] <pitti> kees: ok, understood you
[15:16] <kees> I do not want the teams CVE-hunting; there is a good centralized process for that.  at the same time, I don't want them to ignore new security issies if they just happen to not yet have a CVE.
[15:17] <kees> cjwatson: I'm looking to define what needs to be changed so that there is more team involvement, yes.
[15:18] <cjwatson> presumably responsible people are doing much of this already, with the exception of actively turning up to security team meetings
[15:18] <cjwatson> are there groups of people who are being less responsible whom you're trying to address with this?
[15:18] <kees> cjwatson: perferrably, they would watch the exported package CVE lists and take action when CVEs appear.  e.g. http://people.canonical.com/~ubuntu-security/cve/pkg/linux.html
[15:19] <kees> no, it's to better define how security is handled once the main/universe distinction fades.  from there, it seems like the ubuntu-security-sponsors (or some other team like motu-swat) would become responsible for unseeded packages
[15:20] <kees> that said, there isn't a lot of interest in backporting fixes beyond the latest stable by devel teams, which I understand.
[15:20] <kees> but that's where the U.S.T. does more of its work too
[15:21] <cjwatson> so you'd be most interested in teams basically looking down the right-hand column of the CVE lists?
[15:21] <cjwatson> i.e. lucid
[15:21] <kees> well, I'd prefer they look at the entire table.  right now, most devel teams are only interested in the right-hand column; I'd like to fix that.
[15:21] <pitti> that seems to tie in with the question how long (and in which releases) a particular package gets security updates in the first place; this varies for each delegated archive area
[15:22] <kees> right
[15:22] <pitti> in main/universe this is very clear
[15:22] <pitti> in the new world, we could say that the Canonical security team only covers core ("foundations")/desktop/kubuntu
[15:22] <pitti> ../server
[15:23] <pitti> together with appropriate EOL dates
[15:23] <cjwatson> right, products we ship as a company.
[15:23] <pitti> this would keep the intention that what we call "universe" today still doesn't get under the umbrella of 18 month support
[15:24] <cjwatson> so I think this is good as a general idea, but it could use work on the presentation, and probably refinement with individual teams
[15:24] <cjwatson> kees: have you spoken to any of the delegated teams in question as yet, aside from motu-swat?
[15:24] <kees> anyway, I'm not sure the best language for making a recommendation, but wanted to bring up the idea.
[15:25] <pitti> I certainly would like to avoid getting into a situation where we (as in "all Ubuntu developers") have to support the entire archive for 18/36/60 months
[15:25] <kees> cjwatson: I have not, no.  the idea formed yesterday with persia at the UST meeting
[15:25] <kees> cjwatson: what do you recommend as the best forum for discussing this further?
[15:26] <cjwatson> not sure.  either speaking with teams one at a time, or ubuntu-devel, I suppose
[15:26] <cjwatson> it might be a good idea to talk individually with some of the biggest teams (e.g. Kubuntu) first?
[15:26] <cjwatson> and see what they make of it in practice
[15:26] <kees> did the list of delegated teams end up in the wiki at some point?  /me has a memory of this
[15:27] <pitti> kees: it's on https://wiki.ubuntu.com/DeveloperMembershipBoard
[15:27] <pitti> #Delegation
[15:27] <pitti> plus MOTU
[15:27] <kees> ah-ha, thanks.  okay, I've burned plenty of time, I'll email teams and ubuntu-devel.
[15:27] <kees> [topic] Package set for CLI packages (Iain Lane)
[15:27] <MootBot> New Topic:  Package set for CLI packages (Iain Lane)
[15:28] <kees> Laney: you're up
[15:28] <cjwatson> just a nitpick, perhaps we can call this CLI/Mono or something?  I keep looking at it and thinking "command-line interface"
[15:28]  * kees too.
[15:28] <Laney> Hiya
[15:29] <kees> I'm generally in favor of a dedicated CLI/Mono team
[15:29] <Laney> I don't know if the process is at the stage where we can have teams like this
[15:29] <Laney> but I thought I'd put it out there
[15:29] <Laney> CLI/Mono is alright with me if it makes things clear (we could conceivably get other runtimes in the future though)
[15:30] <cjwatson> we'll be inventing process a bit on the fly since this would be the first team of this category on this scale, but that's OK, we always meant to do it anyway
[15:30] <Laney> sure
[15:30] <cjwatson> one or two of the individual packages listed seemed a bit odd; isn't antlr a Java thing? and launchpad-integration is pretty core, even if it does have a -cli bit
[15:30] <Laney> Yeah. It's just a list of rdeps which I pruned a bit (removing OOo and some others). We can take out various ones which provide just b indings
[15:31] <kees> gmime* is probably another one
[15:31] <cjwatson> I think I'd like to remove the ones that have a single CLI binary package among lots of other bits; but I'm comfortable with the general idea
[15:31] <Laney> we've previously had to touch gmime in the past, but yeah. gmime*, indicator-application, lp-i, antlr
[15:32] <Laney> those are the ones I see immediately that might be questionable
[15:32] <pitti> cjwatson: just to ensure, packages can be in arbitrarily many package sets, right?
[15:33] <cjwatson> yes
[15:33] <Laney> Will the set of uploaders be the union of the uploaders to the sets?
[15:33] <cjwatson> I'm also comfortable with all of the individuals listed
[15:33] <cjwatson> Laney: yes
[15:33] <Laney> Good, that's what I thought
[15:33] <pitti> like, tomboy could be in both desktop and cli/mono
[15:33] <cjwatson> (modulo details about "restricted sets", of which there are currently none unless I miss my guess)
[15:33] <Laney> I don't know if anyone is uncomfortable about mono, f-spot and the like though
[15:33] <Laney> hopefully not...
[15:34] <cjwatson> I don't know who else would maintain mono in practice if it weren't the set of people I see listed here
[15:34] <pitti> cjwatson: reason I ask is that it becomes a bit confusing when we need to define the support status of that set (since there's both unsupported and desktop-supported bits in there
[15:34] <Laney> yes, and that is how it has been done in practice, albeit with core-devs gatekeeping
[15:34] <cjwatson> pitti: we're allowed to have package sets that are just for upload purposes, and don't have a homogeneous support status
[15:34] <pitti> great
[15:35] <Laney> I don't see it changing the support status indeed
[15:35] <kees> sounds like next steps are: prune the package list more, then vote on the delegation? so perhaps iterate via email?
[15:35] <cjwatson> ok, subject to a revised package list from Laney, there seems no substantial disagreement
[15:35] <cjwatson> shall we just vote pending that?
[15:35] <Laney> membership procedure?
[15:35] <Laney> Is there a policy for this already?
[15:35] <cjwatson> your comment about delegating to the DMB seemed reasonable
[15:36] <Laney> I guess it would just extend the PPU policy
[15:36] <cjwatson> the DMB can handle it like other applications (motu, core-dev)
[15:36] <Laney> cool
[15:36] <cjwatson> with appropriate revision of expectations
[15:36] <Laney> and what about adding packages in the future. Can this be done informally?
[15:36] <cjwatson> question: who should handle extensions of the package set (as opposed to the uploader set)?
[15:36] <Laney> snap
[15:36] <cjwatson> snap
[15:37] <persia> TB
[15:37] <cjwatson> there is no particular precedent for this
[15:37] <persia> Err, TB+~ubuntu-archive
[15:37] <cjwatson> well
[15:37] <cjwatson> for the kernel, and I think for printing, we named the category of packages quite explicitly, and so it's straightforward for an archive admin to add packages based on that understanding
[15:37] <pitti> conceptually it seems similar to adding people as PPUs
[15:38] <cjwatson> for instance it's entirely clear that linux-backport-modules-2.6.32 should have been added to the kernel package set to go alongside linux-backports-modules-2.6.31, and I did that without seeking confirmation
[15:38] <kees> two votes now, then?  "creation of CLI/Mono team with [members], pending TB agreement on delegated package list" and "CLI/Mono team membership is delegated to DMB" ?
[15:38] <cjwatson> I'm not sure that we can do that quite so clearly here, and thus having TB confirmation seems reasonable for now; we could do it by mail rather than in meetings though
[15:39] <Laney> there is, for example, an upload of Docky which will happen soon (was rejected yesterday). This is clearly something for the set to have.
[15:39] <cjwatson> any yea/nay on my made-up-on-the-spot process summary?
[15:39] <cjwatson> we could make it DMB confirmation rather than TB confirmation if people prefer
[15:39] <cjwatson> although that constitutes the DMB extending its own delegation, so maybe not
[15:39] <pitti> I'd be fine with either of them
[15:39] <kees> me too
[15:40] <pitti> since DMB can already approve PPU
[15:40] <Laney> maybe TB email confirmation?
[15:40] <Laney> I don't have a real opinion
[15:40] <cjwatson> let's go with TB e-mail confirmation for now, and we can revisit as necessary?
[15:40] <pitti> but most additions should be quite obvious, so a simple confirmation ought to be enough
[15:40] <cjwatson> kees: votes> sounds good
[15:40] <pitti> cjwatson: sounds good
[15:40] <kees> okay, three votes, adding "packageset extension of CLI/Mono team done via TB e-mail confirmation"
[15:41] <kees> [vote] creation of CLI/Mono team with sebner directhex raof hyperair laney, pending TB agreement on delegated package list
[15:41] <MootBot> Please vote on:  creation of CLI/Mono team with sebner directhex raof hyperair laney, pending TB agreement on delegated package list.
[15:41] <MootBot> 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:41] <MootBot> E.g. /msg MootBot +1 #ubuntu-meeting
[15:41] <pitti> +1
[15:41] <MootBot> +1 received from pitti. 1 for, 0 against. 0 have abstained. Count is now 1
[15:41] <kees> mdz: this is to vote on the membership listed in https://lists.ubuntu.com/archives/technical-board/2010-February/000094.html
[15:41] <kees> +1
[15:41] <MootBot> +1 received from kees. 2 for, 0 against. 0 have abstained. Count is now 2
[15:41]  * hyperair wonders if i can vote
[15:42] <cjwatson> +1
[15:42] <MootBot> +1 received from cjwatson. 3 for, 0 against. 0 have abstained. Count is now 3
[15:42] <kees> hyperair: mootbot will count you, but it doesn't count in the TB vote-count.  :)
[15:42] <hyperair> heheh okay =p
[15:42] <kees> we can check in with mdz later
[15:43] <kees> [endvote]
[15:43] <MootBot> Final result is 3 for, 0 against. 0 abstained. Total: 3
[15:43] <kees> [vote] CLI/Mono team membership is delegated to DMB
[15:43] <MootBot> Please vote on:  CLI/Mono team membership is delegated to DMB.
[15:43] <MootBot> 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:43] <MootBot> E.g. /msg MootBot +1 #ubuntu-meeting
[15:43] <mdz> kees: given I'm not paying attention, I abstain
[15:43] <kees> mdz: ok
[15:43] <kees> +1
[15:43] <MootBot> +1 received from kees. 1 for, 0 against. 0 have abstained. Count is now 1
[15:43] <pitti> +1
[15:43] <MootBot> +1 received from pitti. 2 for, 0 against. 0 have abstained. Count is now 2
[15:43] <mdz> this one is a general governance question, so I'll vote
[15:43] <mdz> and I'm +1
[15:43] <mdz> +1
[15:43] <MootBot> +1 received from mdz. 3 for, 0 against. 0 have abstained. Count is now 3
[15:44] <cjwatson> +1
[15:44] <MootBot> +1 received from cjwatson. 4 for, 0 against. 0 have abstained. Count is now 4
[15:44] <kees> [endvote]
[15:44] <MootBot> Final result is 4 for, 0 against. 0 abstained. Total: 4
[15:44] <kees> [vote] packageset extension of CLI/Mono team done via TB e-mail confirmation
[15:44] <MootBot> Please vote on:  packageset extension of CLI/Mono team done via TB e-mail confirmation.
[15:44] <MootBot> 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:44] <MootBot> E.g. /msg MootBot +1 #ubuntu-meeting
[15:44] <kees> +1
[15:44] <MootBot> +1 received from kees. 1 for, 0 against. 0 have abstained. Count is now 1
[15:44] <cjwatson> +1
[15:44] <MootBot> +1 received from cjwatson. 2 for, 0 against. 0 have abstained. Count is now 2
[15:44] <pitti> +1
[15:44] <MootBot> +1 received from pitti. 3 for, 0 against. 0 have abstained. Count is now 3
[15:44] <kees> [endvote]
[15:44] <MootBot> Final result is 3 for, 0 against. 0 abstained. Total: 3
[15:44] <cjwatson> hooray for unanimity
[15:44] <kees> wheee, cli/mono team!
[15:44] <pitti> Laney: thanks for bringing this up
[15:45] <directhex> well that was pretty painless. my thanks, ladies & gents
[15:45] <Laney> that was smooth, thanks guys
[15:45] <hyperair> \o/
[15:45] <pitti> Laney: this seems to be an exemplary team wrt. Debian/Ubuntu cooperation :)
[15:45] <directhex> especially to Laney for writing the proposal
[15:45] <Laney> pitti: we do try hard to achieve this
[15:45]  * hyperair agrees with directhex
[15:45] <cjwatson> pitti: agreed, I've been very impressed indeed
[15:46] <kees> ok, so, we'll continue the package list via email.  I'm going to run the agenda ahead, as we're going to run out of time.
[15:46] <kees> [topic] Ubuntu IRC Council Access level in #ubuntu-devel (Jussi Schultink)
[15:46] <MootBot> New Topic:  Ubuntu IRC Council Access level in #ubuntu-devel (Jussi Schultink)
[15:46] <jussi01> o/
[15:46] <jussi01> SO, after the email, any questions?
[15:47] <mdz> looks like folks are reading it :-)
[15:47] <kees> this seems clear to me.  I don't think we need a vote, just someone with perms to make it happen.
[15:47] <mdz> [link] https://lists.ubuntu.com/archives/technical-board/2010-February/000095.html
[15:47] <MootBot> LINK received:  https://lists.ubuntu.com/archives/technical-board/2010-February/000095.html
[15:47] <cjwatson> I have no particular problem with this; IIRC last time there were some problems with the IRCC, but all that seems to have quietened down
[15:48] <cjwatson> I can implement it if the TB is in agreement
[15:48] <pitti> no objection here
[15:48] <kees> [vote] implement IRC Council Access on IRC
[15:48] <MootBot> Please vote on:  implement IRC Council Access on IRC.
[15:48] <MootBot> 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:48] <MootBot> E.g. /msg MootBot +1 #ubuntu-meeting
[15:48] <kees> +1
[15:48] <MootBot> +1 received from kees. 1 for, 0 against. 0 have abstained. Count is now 1
[15:48] <cjwatson> +1
[15:48] <MootBot> +1 received from cjwatson. 2 for, 0 against. 0 have abstained. Count is now 2
[15:48] <pitti> +0
[15:48] <MootBot> Abstention received from pitti. 2 for, 0 against. 1 have abstained. Count is now 2
[15:49] <pitti> (admittedly I don't understand how the IRC administration works, abstaining)
[15:49] <jussi01> Do we need something from mdz then?
[15:49]  * kees hopes mdz agrees
[15:49] <mdz> +0
[15:49] <MootBot> Abstention received from mdz. 2 for, 0 against. 2 have abstained. Count is now 2
[15:49] <pitti> but to me it didn't seem to be something that TB needs to vote on in the first place
[15:49] <kees> [endvote]
[15:49] <MootBot> Final result is 2 for, 0 against. 2 abstained. Total: 2
[15:49] <cjwatson> out of curiosity, how does the "UbuntuIrcCouncil" mask work?
[15:50] <cjwatson> i.e. how does one see what Freenode considers that to mean?
[15:50] <cjwatson> is it just a shared account or something?
[15:50] <jussi01> cjwatson: its a registered nick that is identifyable to, and ubottu can identify to it to change things if a change is made on the LP team
[15:50] <kees> iiuc, it's a nick, so anyone with access to it?
[15:51] <cjwatson> ok
[15:51] <cjwatson> I've implemented the requested change now
[15:51] <jussi01> thank you
[15:51] <Pici> Only the IRCC has the password.
[15:51] <kees> thanks!
[15:51] <kees> [topic] Review UEC/Images/RefreshPolicy
[15:51] <MootBot> New Topic:  Review UEC/Images/RefreshPolicy
[15:51] <cjwatson> I assume you change it when the IRCC membership changes
[15:52] <Pici> cjwatson: Yes.
[15:52] <jussi01> cjwatson: of course
[15:52] <jussi01> :)
[15:52] <smoser> I hope that everyone has had a chance to read https://wiki.ubuntu.com/UEC/Images/RefreshPolicy
[15:52] <kees> [link] https://wiki.ubuntu.com/UEC/Images/RefreshPolicy
[15:52] <MootBot> LINK received:  https://wiki.ubuntu.com/UEC/Images/RefreshPolicy
[15:52] <smoser> it has been here once before, and I believe that all points brought up were addressed.
[15:53] <smoser> (I had sent an email on Feb 11 to technical-board with info also)
[15:53] <cjwatson> I have one query, which probably just reflects my ignorance: are people likely to have built their own AMIs based on those we ship (is that possible)?  in other words, would those people essentially be expected to refresh their AMIs once a month?
[15:53] <smoser> it is possible and likely
[15:54] <mdz> cjwatson, it is possible, but we are finding it more common/preferable that they are deriving "on the fly"
[15:54] <smoser> cjwatson, for those people, the only time when they'd need to use a new image is when the updates were not possible via 'apt-get upgrade'
[15:54] <mdz> i.e. the instance boots our vanilla image, and is customized at boot time using puppet, chef, or similar
[15:54] <mdz> that way, it is easy to swap out the underlying base image for updates
[15:55] <mdz> that seems to be the more popular approach in the community today
[15:55] <cjwatson> ok, thanks for the clarification
[15:55] <mdz> people will create their own AMIs as well, but I think they're more or less on their own at that point
[15:55] <smoser> and, as mdz points out, if they're rebundling hopefully their rebundling process takes a AMI as input and works from that, so they could just drop in the new reference image.
[15:56] <cjwatson> you seem to have covered all the bases I can think of
[15:56] <cjwatson> how often do daily builds for lucid fail?
[15:56] <mdz> it looks good to me
[15:56] <cjwatson> IOW how much handholding does it tend to need?
[15:57] <smoser> cjwatson, they're fairly good. i'd say over 90% is a conserviative success rate guess
[15:57] <kees> this all reads well to me.  I like the query tree on uec-images.u.c.  a few questions: 1) will cloud-utils be backported to hardy?  (does it need to be?)  2) should there be a mailing list to send details of the updates to? (like the USN mailing list for security updates?)
[15:57] <cjwatson> that's actually very good compared to e.g. CD image builds
[15:57] <cjwatson> I guess you have a smaller software base going into them
[15:57] <smoser> kees, i have no plans to backport the cloud-utils to hardy or karmic, but it is very light and could be easily done.
[15:57] <smoser> the "updates notification" was a new feature for lucid.
[15:58]  * kees nods
[15:58] <smoser> cjwatson, yeah, the "desktop" build fails more often.
[15:58] <smoser> kees, for number 2, once we get all this solidified and the QA team takes over, the intent is to announce on the Release blog, if that suitable
[15:59] <smoser> and very easily we can send that same message to appropriate mailing lists.
[15:59] <kees> sounds fine
[15:59] <kees> should we vote on this, or was the intention to just have TB review it?
[16:00] <smoser> mdz, ?^
[16:00] <mdz> kees: we should vote on it
[16:00] <mdz> smoser brought it here for approval
[16:00] <kees> ok, the agenda just said "review", I wasn't sure.
[16:01] <kees> [vote] approve the UEC/Images/RefreshPolicy
[16:01] <MootBot> Please vote on:  approve the UEC/Images/RefreshPolicy.
[16:01] <MootBot> 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:01] <MootBot> E.g. /msg MootBot +1 #ubuntu-meeting
[16:01] <kees> +1
[16:01] <MootBot> +1 received from kees. 1 for, 0 against. 0 have abstained. Count is now 1
[16:01] <mdz> +1
[16:01] <MootBot> +1 received from mdz. 2 for, 0 against. 0 have abstained. Count is now 2
[16:01] <pitti> +1
[16:01] <MootBot> +1 received from pitti. 3 for, 0 against. 0 have abstained. Count is now 3
[16:01] <mdz> cjwatson, ?
[16:01] <cjwatson> +1
[16:01] <MootBot> +1 received from cjwatson. 4 for, 0 against. 0 have abstained. Count is now 4
[16:02] <kees> [endvote]
[16:02] <MootBot> Final result is 4 for, 0 against. 0 abstained. Total: 4
[16:02] <kees> okay, we're out of time today.  chair for next meeting, is, I assume, Keybuk again?
[16:02] <highvoltage> any chance we could get feedback from the edubuntu-dev application by e-mail?
[16:03] <dholbach> and the sponsoring bits :)
[16:03] <cjwatson> highvoltage: I'll try to do that
[16:03] <cjwatson> (at least)
[16:04] <highvoltage> cjwatson: thank you
[16:04] <kees> okay, thanks everyone. sorry for not getting through everything; we can continue some of it in email.
[16:04] <kees> #endmeeting
[16:04] <MootBot> Meeting finished at 10:04.
[16:05] <pitti> thanks everyone
[16:11] <pace_t_zulu> man...
[16:11] <pace_t_zulu> i missed that meeting
[17:02] <bjf> Roll Call
[17:02]  * ogasawara waves
[17:02]  * smb waves
[17:03]  * tgardner pops in
[17:03]  * amitk stumbles in
[17:03]  * cking waves too
[17:03] <bjf> #startmeeting
[17:03] <MootBot> Meeting started at 11:03. The chair is bjf.
[17:03] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[17:03]  * jjohansen waves
[17:03] <bjf> [LINK] https://wiki.ubuntu.com/KernelTeam/Meeting
[17:03] <MootBot> LINK received:  https://wiki.ubuntu.com/KernelTeam/Meeting
[17:03] <bjf> [LINK] https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Lucid
[17:03] <MootBot> LINK received:  https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Lucid
[17:03] <bjf> NOTE: '..' indicates that you are finished with your input.
[17:04] <bjf> NOTE: JFo is not joining us today. However, I have his data for the topics he is responsible for.
[17:04] <bjf> [TOPIC] Open Action Item: None
[17:04] <MootBot> New Topic:  Open Action Item: None
[17:04] <bjf> [TOPIC] Release Metrics:
[17:04] <MootBot> New Topic:  Release Metrics:
[17:04] <bjf> Bugs (Release Meeting Bugs / RC Milestoned Bugs / Release Targeted Bugs)
[17:04] <bjf> Release Meeting Bugs (4 bugs, 5 blueprints)
[17:04] <bjf> [17:04] <bjf> Alpha 3 Milestoned Bugs (24 bugs against all packages (down 1))
[17:04] <bjf>  * 2 linux kernel bugs (up 1)
[17:04] <bjf>  * 3 linux-fsl-imx51 bugs (no change)
[17:04] <bjf>  * 0 linux-ec2 bug (no change)
[17:04] <bjf>  * 1 linux-mvl-dove bugs (down 1)
[17:04] <bjf> [17:04] <bjf> Release Targeted Bugs (137 bugs against all packages (up 5))
[17:04] <bjf>  * 15 linux kernel bugs (up 1)
[17:04] <bjf>  * 3 linux-fsl-imx51 bugs (down 1)
[17:04] <bjf>  * 0 linux-ec2 bug (no change)
[17:04] <bjf>  * 1 linux-mvl-dove bugs (down 1)
[17:04] <bjf> [17:05] <bjf> Milestoned Features -
[17:05] <bjf>  * 0 blueprints
[17:05] <bjf> [17:05] <bjf> Bugs with Patches Attached:112 (not counting Fix Committed)(up 5)
[17:05] <bjf> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.has_patch=on
[17:05] <bjf> Breakdown by status:
[17:05] <bjf> http://qa.ubuntu.com/reports/ogasawara/csv-stats/bugs-with-patches/linux/
[17:05] <MootBot> LINK received:  http://qa.ubuntu.com/reports/ogasawara/csv-stats/bugs-with-patches/linux/
[17:05] <bjf> == Blueprints ==
[17:05] <bjf> kernel-lucid-bug-handling:
[17:05] <bjf>  * No update, all items are still in progress.
[17:05] <bjf> [TOPIC] Blueprints: kernel-lucid-bug-handling (JFo)
[17:05] <MootBot> New Topic:  Blueprints: kernel-lucid-bug-handling (JFo)
[17:05] <bjf> [LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-bug-handling
[17:05] <MootBot> LINK received:  https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-bug-handling
[17:05] <bjf>  * No update, all items are still in progress.
[17:05] <bjf> [TOPIC] Blueprints: kernel-lucid-review-of-ubuntu-delta (apw)
[17:05] <MootBot> New Topic:  Blueprints: kernel-lucid-review-of-ubuntu-delta (apw)
[17:05] <bjf> [LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-review-of-ubuntu-delta
[17:05] <MootBot> LINK received:  https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-review-of-ubuntu-delta
[17:05] <apw> drbd confirmed no longer in user with the server team and dropped from the kernel.  Awaiting testing on the Lenovo driver combination which should close the last item here.
[17:05] <apw> ..
[17:06] <bjf> [TOPIC] Blueprints: kernel-lucid-kernel-config-review (apw)
[17:06] <bjf> [LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-kernel-config-review
[17:06] <MootBot> New Topic:  Blueprints: kernel-lucid-kernel-config-review (apw)
[17:06] <MootBot> LINK received:  https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-kernel-config-review
[17:06] <apw> It seems we require SECCOMP enabled for Lucid, this is there for the distro kernels but under investigation for ARM.
[17:06] <apw> ..
[17:06] <bjf> [TOPIC] Blueprints: kernel-lucid-kms (sconklin / apw)
[17:06] <bjf> [LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-kms
[17:06] <MootBot> New Topic:  Blueprints: kernel-lucid-kms (sconklin / apw)
[17:06] <MootBot> LINK received:  https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-kms
[17:07] <apw> Upstream for DRM and upstream for the main drivers of interest, i915 and ATI, are all disavowing 2.6.32 indicating there is no hope of getting this working.  As we are already backporting Nouveau from 2.6.33 we are now examining the feasability of a wholesale DRM backport as a better starting point.  Testing ongoing, though all new issues are being shown up by this combination.
[17:07] <apw> ..
[17:07] <sconklin> sconklin ..
[17:07] <bjf> [TOPIC] Blueprints: kernel-lucid-suspend-resume (manjo)
[17:07] <bjf> [LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-suspend-resume
[17:07] <MootBot> New Topic:  Blueprints: kernel-lucid-suspend-resume (manjo)
[17:07] <MootBot> LINK received:  https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-suspend-resume
[17:08] <bjf> skipping for now
[17:08] <bjf> [TOPIC] Blueprints: kernel-lucid-apparmor-development (jjohansen)
[17:08] <bjf> [LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-apparmor-development
[17:08] <MootBot> New Topic:  Blueprints: kernel-lucid-apparmor-development (jjohansen)
[17:08] <MootBot> LINK received:  https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-apparmor-development
[17:08] <jjohansen> Finally got another push to LKML out, working through the feedback.
[17:08] <apw> your update is now in the archive in lucid
[17:09] <jjohansen> thanks
[17:09] <amitk> so we basically run AA-crack-of-the-day in lucid?
[17:09] <jjohansen> I should have another pull request this week
[17:09] <apw> AA upstream version is what we have
[17:09]  * amitk realises that sounded negative, it wasn't meant to be
[17:09] <jjohansen> amitk: well mostly crack of the day, is cleanups and code transforms requested by upstream
[17:10] <apw> so we are testing whatever jj is pushing
[17:10] <amitk> cool
[17:10] <amitk> ..
[17:10] <jjohansen> ..
[17:10] <bjf> [TOPIC] Blueprints: kernel-lucid-suspend-resume (manjo)
[17:10] <bjf> [LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-suspend-resume
[17:10] <MootBot> New Topic:  Blueprints: kernel-lucid-suspend-resume (manjo)
[17:10] <MootBot> LINK received:  https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-suspend-resume
[17:10] <manjo> nothing more from last week
[17:10] <manjo> ..
[17:10] <bjf> [TOPIC] Blueprints: kernel-lucid-boot-performance (apw, csurbhi)
[17:10] <bjf> [LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-boot-performance
[17:10] <MootBot> New Topic:  Blueprints: kernel-lucid-boot-performance (apw, csurbhi)
[17:10] <MootBot> LINK received:  https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-boot-performance
[17:11] <apw> We remain around the 1.6s to rootfs mark.  khubd fixes are now uploaded and looking good.
[17:11] <apw> ..
[17:11] <bjf> [TOPIC] Other Release Tasks: Lucid Audio Support (bjf)
[17:11] <MootBot> New Topic:  Other Release Tasks: Lucid Audio Support (bjf)
[17:11] <bjf> nothing new from last week
[17:11] <bjf> ..
[17:11] <bjf> [TOPIC] Other Release Tasks: Lucid Better Power Mgt (amitk)
[17:11] <MootBot> New Topic:  Other Release Tasks: Lucid Better Power Mgt (amitk)
[17:11] <amitk> no progress
[17:11] <amitk> ..
[17:12] <bjf> [TOPIC] Other Release Tasks: EC2 Lucid Kernel Status (jjohansen)
[17:12] <MootBot> New Topic:  Other Release Tasks: EC2 Lucid Kernel Status (jjohansen)
[17:12] <jjohansen> well I poked at running a pv-ops kernel again briefly, it looks promising but I need to make sure I run through all zones, and regions
[17:13] <jjohansen> what do we want to do if the pv-ops kernel is working?
[17:13] <bjf> [TOPIC] Status: Lucid (apw)
[17:13] <MootBot> New Topic:  Status: Lucid (apw)
[17:13] <apw> Lucid is at stable v2.6.32.8, the khubd fixes have now hit the archive and boot times are looking better.  We have potential issues with the HDA beep being discordant and loud, but this seems to be codec specific and not the nightmare screech issue we have had before, investigation ongoing.  We also have graphics issues as discussed above, a decision will have to be taken in the next week as to direction.
[17:13] <bjf> sorry, still with jjohansen
[17:14] <apw> .... screech
[17:14] <apw> jjohansen, i presume that is much closer to the normal kernel?
[17:14] <jjohansen> it would be nice to dump the xen patchset but it is getting aweful late
[17:14] <apw> so we could get rid of the -ec2 kerenls?
[17:14] <jjohansen> possibly
[17:14] <jjohansen> I still need to do a lot more testing to be sure
[17:14] <apw> we might need to FF the change, but if it means we don't need more than a flavour then its worth it
[17:15] <jjohansen> I redid pv-ops with some of the configs that we learned are problematic disabled
[17:15] <jjohansen> well we would need a flavour but not a topic branch
[17:15] <apw> right a flavour is much less maintenance overhead ... a _lot_
[17:15] <jjohansen> right
[17:16] <apw> so when can we get a definative answer as to whether its psosible
[17:16] <apw> i recon we'd need to make the decision at least a week before b-1
[17:16] <jjohansen> well I can make it high priority and know in a couple days
[17:16] <jjohansen> will also want to discuss with the server team
[17:16] <apw> next week sounds fine to me ... yeah lets get the people who care in a room and make them test it
[17:17] <jjohansen> okay, will do there is a server team meeting tomorrow
[17:17] <jjohansen> ..
[17:17] <bjf> apw, back to you and Lucid status
[17:17]  * apw repeats for sanity
[17:18] <apw> Lucid is at stable v2.6.32.8, the khubd fixes have now hit the archive and boot times are looking better.  We have potential issues with the HDA beep being discordant and loud, but this seems to be codec specific and not the nightmare screech issue we have had before, investigation ongoing.  We also have graphics issues as discussed above, a decision will have to be taken in the next week as to direction.
[17:18] <apw> Progress has been pretty solid the last week, with us nearly hitting the trend-line for a day.  The new issues above have pushed us back a little.  I have been through the remaining Alpha-3 items and pushed any that are clearly not release critical out to ubuntu-10.04-beta-1, these include the apport changes etc which can easily be done after kerenel freeze.  If I have pushed your items out and they are kernel related we do need something soon; be
[17:18] <apw> ta-1 is only 3 weeks out.
[17:18] <apw> ..
[17:18] <bjf> [TOPIC] Security & bugfix kernels - Karmic/Jaunty/Intrepid/Hardy/Others (gnarl/smb)
[17:18] <MootBot> New Topic:  Security & bugfix kernels - Karmic/Jaunty/Intrepid/Hardy/Others (gnarl/smb)
[17:19] <smb> Dapper:      2.6.15-55.82  (security)
[17:19] <smb> Hardy:       2.6.24-27.65  (security)
[17:19] <smb>              2.6.24-27.67  (proposed)[0]   0/ 3 verifications done (+0)
[17:19] <smb> Intrepid:    2.6.27-17.45  (security)
[17:19] <smb> Jaunty:      2.6.28-18.59  (security)
[17:19] <smb> Karmic:      2.6.31-19.56  (security)
[17:19] <smb>              2.6.31-20.57  (proposed)[15]  5/19 verifications done (+0)
[17:19] <smb>  - LBM       2.6.31-20.22  (proposed)[15]  0/ 2 verifications done (+0)
[17:19] <smb>  - mvl-dove  2.6.31-211.22 (security)
[17:19] <smb>              2.6.31-211.23 (waiting for acceptance)
[17:19] <smb>  - fsl-imx51 2.6.31-108.21 (security)
[17:19] <smb>              2.6.31-108.22 (proposed)[6]   0/ 1 verifications done (+0)
[17:19] <smb>  - ec2       2.6.31-304.10 (security)
[17:19] <smb>              2.6.31-304.11 (proposed)[6]   0/ 1 verifications done (+0)
[17:19] <smb> The mvl-dove upload is not processed, yet as there were questions about its
[17:19] <smb> impact by pitti which have not been answered.
[17:19] <smb> Working on getting a few more changes in Karmic proposed being verified.
[17:19] <smb> Likewise fsl-imx51 and ec2 interested parties should report back on the
[17:19] <smb> bugs in question.
[17:19] <smb> ..
[17:19] <apw> whats the outstanfing Q?
[17:19] <apw> on mvl-dove?
[17:20] <smb> apw, Why it is needed. What the impact is
[17:20] <apw> that contained the VFP stuff yes?
[17:21] <smb> Something about needing more memory
[17:21] <smb> I asked Eric in email to comment on it
[17:21] <apw> ok ... thanks ... will look at the thread     ..
[17:21] <smb> ..
[17:21] <bjf> [TOPIC] Incoming Bugs: Regressions (JFo)
[17:21] <MootBot> New Topic:  Incoming Bugs: Regressions (JFo)
[17:21] <bjf> Incoming Bugs
[17:21] <bjf> 160 Lucid Bugs (up 30)
[17:21] <bjf> Current regression stats (broken down by release):
[17:21] <bjf> [17:21] <bjf>   * 51 lucid bugs
[17:21] <bjf> [17:21] <bjf>   * 9 karmic bugs
[17:22] <bjf>   * 5 jaunty bugs
[17:22] <bjf>   * 2 intrepid bugs
[17:22] <bjf>   * 1 hardy bug
[17:22] <bjf> [17:22] <bjf>   * 55 karmic bugs
[17:22] <bjf>   * 23 jaunty bugs
[17:22] <bjf>   * 11 intrepid bugs
[17:22] <bjf>   * 4 hardy bugs
[17:22] <bjf> [17:22] <bjf>   * 1 karmic bug
[17:22] <bjf> [TOPIC] Incoming Bugs: Bug day report (JFo)
[17:22] <MootBot> New Topic:  Incoming Bugs: Bug day report (JFo)
[17:22] <bjf> Last week's BugDay was a success. Stats are available at:
[17:22] <bjf> http://qa.ubuntu.com/reports/jfo/kernel-bugday/20100216.html
[17:22] <MootBot> LINK received:  http://qa.ubuntu.com/reports/jfo/kernel-bugday/20100216.html
[17:22] <bjf> The next Kernel BugDay is scheduled for next Tuesday the 2nd of March. The focus will be Bugs with patches attached.
[17:22] <bjf> [TOPIC] Open Discussion or Questions: Anyone have anything?
[17:22] <MootBot> New Topic:  Open Discussion or Questions: Anyone have anything?
[17:23]  * apw notes beta-1 is nearly here ...
[17:23] <bjf> once...
[17:23] <apw> those of you with investigate tasks will find they are moot pretty soon
[17:23] <apw> ..
[17:23] <bjf> twice...
[17:24] <bjf> thanks everyone
[17:24] <bjf> #endmeeting
[17:24] <MootBot> Meeting finished at 11:24.
[17:24] <cking> thanks bjf
[17:24] <csurbhi> thanks bjf
[17:24] <amitk> thanks bjf