[05:22] <mahinda> quit
[05:29] <anuradha> Hello...
[08:01] <anuradha> hello all, is any one here.
[08:03] <MaWaLe> hi anuradha
[08:26] <anuradha> hi, MaWaLe..
[08:26] <anuradha> sorry i ran out a bit.
[08:26] <anuradha> when is the meeting starting? or is it over by now :)
[08:28] <MaWaLe> actually there is no meeting
[08:28] <MaWaLe> the first one will be at 15UTC
[08:29] <anuradha> ah
[08:31] <MaWaLe> you can see the planning here : http://fridge.ubuntu.com/calendar
[08:31] <MaWaLe> and please : can we stop to post here just to keep the log clean : thx
[13:44] <highvoltage> asac: I just read your latest dent. wouldn't it be better to use alternatives for that?
[14:09] <asac> highvoltage: i think its an exceptional situation
[14:09] <asac> due to recent python transition
[14:09] <asac> so i can do that manually  ;)
[14:09] <asac> in general we dont want alternatives for python
[14:10] <asac> as we rely on a certain python being the default
[14:10] <asac> whether that could be done better is a different point ;)
[14:28] <highvoltage> asac: good point
[14:51]  * persia peers about
[14:57] <knome> persia, o/
[14:58] <hito_jp> yes? o/
[14:59] <persia> Well, that's three of the five candidates present.  Now we just need some more board members.
[15:00] <knome> persia, do you really need 'em? ;)
[15:04] <persia> knome, Absolutely.  Without quorum there cannot be an expression of consensus.
[15:05] <knome> :)
[15:20] <persia> Well, 20 minutes past and nobody else here.  Sorry about that.  Let's try again next time.
[15:21] <knome> duh.
[15:21] <nizarus> :(
[15:21] <cody-somerville> :(
[15:22] <knome> that is really sad.
[15:22] <knome> these regional boards are not quite working.
[15:22] <MaWaLe> :( :( :( :( for me
[15:23] <persia> knome, How do you mean?
[15:23] <knome> persia, i've waited to get membership since december 21st. i've missed the emea meeting twice for personal reasons.
[15:23] <knome> persia, and that's it for the meetings of emea this year.
[15:24] <knome> persia, and now when i'm here, i can't get membership because the board members are not here.
[15:24] <knome> persia, so you can maybe see my frustration?
[15:24] <persia> knome, Hrm.  I can see how you are frustrated, but I'm not sure how to advise you.
[15:25] <knome> persia, it's part of our (xubuntu) strategy to get people blogging on planet, but due to this i have been unable to do that.
[15:25] <persia> I'm not familiar with the details of the EMEA board, but meeting only once a month doesn't seem completely unreasonable, depending on the agenda.  Personally, I'd prefer to see twice a month or more, but that might just be me.
[15:25] <knome> persia, it's ok, i've already contacted mdke.
[15:26] <knome> persia, the first one was january 5th and the second one yesterday, so that leaves quite a gap, even if it was once a month.
[15:26] <persia> As for the AsiaOceania board: we're short a couple members, and spread over lots of timezones.  We've been struggling with this, and sometimes everyone can get here early enough/stay up late enough, and sometimes not.
[15:26] <knome> i understand.
[15:26] <persia> knome, Ah, that sounds more like once every two months: yes, that is a bit of a gap.
[15:26] <knome> but maybe you should not announce a meeting if the members can't attend?
[15:27] <knome> because now i've arranged some time from my schedule which i could have used way better.
[15:28] <persia> I'll definitely raise that option with the other members.  We've tried to keep regular meetings, and tried to attend them all, but perhaps it makes more sense to have fewer meetings with more attendance.
[15:29] <knome> yeah. and one thing i think would make big difference in the better way is to inform about these meetings earlier.
[15:30] <persia> How do you mean?
[15:30] <knome> i know this is sometimes impossible and of course hard in the situation you have, but it would be much better for the people who are trying to get the membership.
[15:31] <knome> i've followed the regional board pages on the wiki, and the meetings dates are issued quite late. after that, a bunch of people suddenly adds theirselves in the list.
[15:31] <knome> and that makes the other people wait, because the board members might think that "oh, there's only 3 members pending. let's not keep a meeting"
[15:32] <persia> Actually, we never decide not to have a meeting just because there aren't many applicants.
[15:32] <persia> It's better to have a quick meeting, with 0 or 1 applicants.
[15:33] <knome> yeah, but that might have been the case with emea. i don't know.
[15:33] <persia> More than about three tends to make us go over-time, which is annoying (especially when it's late).
[15:33] <persia> I can't speak for them, but I suspect it's more a matter of feeling pressure from there being many pending applicants than about deciding not to have a meeting because there aren't so many.
[15:34] <knome> yeah. but still everybody who is applying for membership should get into the process as soon as possible.
[15:35] <knome> and not seeing when the next meeting is makes the applier maybe a bit hesitant to add his name to the list, because he might not be able to attend.
[15:35] <persia> I agree to that.
[15:35] <knome> and i've seen those dates appearing under a week before the meeting.
[15:36] <knome> that's a really short timespan.
[15:36]  * charlie-tca thinks they appeared with about 24 hours notice for knome
[15:36] <persia> I'm not sure which is the better model though: the model that AsiaOceania has adopted, where we try to hold regular meetings, and sometimes fail to achieve quorum, or the model where meetings are announced only when they are firm, leading to confusion about the date until the agenda is full.
[15:36] <persia> I believe both are likely frustrating.
[15:37] <knome> yeah. but maybe announce the meeting and then if it looks like you can't make it, then just make a note on the wiki.
[15:37] <knome> and try to keep that meeting as soon as possible after that date.
[15:40] <persia> I guess.  I'm not that fussed whether attendance is decided on the wiki or via email, but I agree it's better not to be surprised.  There ought be some announcement of when a meeting will be cancelled, and we ought know at least before the meeting starts, especially as people from all over the globe might need to attend as part of a set of supporters for a given candidate.
[15:41] <knome> yeah.
[15:41] <persia> Anyway, I'll definitely raise this within AsiaOceania, and we'll see if we can't get better about that.
[15:41] <knome> yeah. thanks. :)
[15:41] <persia> If we find a model that works, we'll surely share with the other boards.
[15:41] <knome> how about the *buntu* co-operation meeting? :)
[15:41] <persia> Someone needs to organise that :)
[15:42] <knome> pick any date.
[15:42] <persia> Maybe in a couple of weeks?  Say around the 18th
[15:43] <knome> March 18th, 16UTC ?
[15:43] <knome> or is that too late for you?
[15:43] <persia> Well, 16 is very late for me, but probably good for most of the people you need to attend.
[15:43] <persia> I wouldn't worry about it if I can't be there.
[15:43] <knome> ok.
[15:43] <persia> Better to focus on the team leads for the various flavour teams.
[15:44] <knome> i'll add it in the fridge. which places would you suggest mailing/etc.?
[15:44] <persia> I know some are in Europe, and some in the US, so 16-20 UTC is probably the right timeframe.
[15:44] <knome> there's already meeting on that day and time.
[15:44] <persia> Probably just ubuntu-devel@: everyone affected ought be subscribed.  You might bcc: the team leads, just to be sure.
[15:45] <knome> how about March 16 ?
[15:45] <persia> Then pick a different day/time :)
[15:45] <persia> Mondays are often a holiday somewhere: check first.
[15:49] <knome> nope. at least my calendar tells so.
[15:50] <knome> i'll add it there then. let's shift it if needed.
[15:53] <persia> knome, Good luck with it.
[15:54] <knome> persia, thanks. hope to see you then :)
[15:59] <sommer> hey all
[15:59] <ivoks> o/
[15:59] <SuperVHS> hello
[15:59]  * mathiaz waves
[15:59] <ttx> \o
[16:01] <mathiaz> anyone else for the server team meeting?
[16:01] <nijaba> o/
[16:01] <mathiaz> allright let's get this started
[16:01] <SuperVHS> yes.. I'm
[16:02] <mathiaz> #startmeeting
[16:02] <MootBot> Meeting started at 10:02. The chair is mathiaz.
[16:02] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[16:02] <mathiaz> ttx: thanks for running the meeting last time
[16:02] <ttx> mathiaz: it was a pleasure.
[16:02] <mathiaz> ttx: and for preparing and sending the minutes out there - very much appreciated :)
[16:03] <mathiaz> Today's agenda: https://wiki.ubuntu.com/ServerTeam/Meeting
[16:03] <mathiaz> last week's minutes: https://wiki.ubuntu.com/MeetingLogs/Server/20090224
[16:03] <mathiaz> [TOPIC] SRU bug tracking
[16:03] <MootBot> New Topic:  SRU bug tracking
[16:03] <mathiaz> ivoks: any news^^?
[16:04] <ivoks> sorry, i didn't have time to prepare topic as i wanted, so i didn't put it on agenda
[16:04] <mathiaz> ivoks: np - still on track to talk about it?
[16:04] <ivoks> so, if it's not a problem to postpone it for next meeting...
[16:04] <mathiaz> ivoks: np
[16:04] <ivoks> mathiaz: sure, i think that's a very important issue
[16:05] <mathiaz> ivoks: it seems that this topic ought to be well prepared
[16:05] <ivoks> of course
[16:05] <mathiaz> ivoks: so we can defer it to the next meeting
[16:05] <ivoks> yes
[16:05] <mathiaz> ivoks: so when you're ready to discuss could you add an item on the agenda?
[16:06] <ivoks> correct
[16:06] <ivoks> err... yes :D
[16:06] <mathiaz> [ACTION] ivoks to add to the server team agenda an item about better SRU bugtracking  when ready
[16:06] <MootBot> ACTION received:  ivoks to add to the server team agenda an item about better SRU bugtracking  when ready
[16:07] <mathiaz> [TOPIC] Postfix and Dovecot integration
[16:07] <MootBot> New Topic:  Postfix and Dovecot integration
[16:07] <mathiaz> ivoks: any news^^?
[16:07] <mathiaz> has some testing been done?
[16:07] <mathiaz> ivoks: or did you receive any feedback on the proposal?
[16:07] <ivoks> well, i didn't recieve any feedback yet :/
[16:08] <ivoks> maybe i should blog about it
[16:08] <ivoks> :)
[16:08] <zul> hello
[16:08] <mathiaz> ivoks: I've seen some blog post about it (from a romanian blog)
[16:08] <ivoks> mathiaz: me too
[16:08] <ivoks> but that's it
[16:08] <mathiaz> ivoks: but yes - blogging about it may be a good idea
[16:09] <mathiaz> ivoks: I've already posted a post on the ubuntu server blog - so doing another one way may not be the best option
[16:09] <mathiaz> ivoks: could do one on your blog?
[16:10] <ivoks> mathiaz: that is the plan
[16:10] <mathiaz> ivoks: great - thanks
[16:10] <mathiaz> [ACTION] ivoks to blog about the postfix dovecot integration
[16:10] <MootBot> ACTION received:  ivoks to blog about the postfix dovecot integration
[16:10] <ivoks> and... we could remove it from roadmap
[16:10] <ivoks> since it has been implemented
[16:12] <mathiaz> ivoks: roadmap updated!
[16:12] <mathiaz> [TOPIC] Ubuntu and EC2
[16:12] <MootBot> New Topic:  Ubuntu and EC2
[16:12] <mathiaz> zul: ^^?
[16:12] <zul> hi
[16:13] <zul> so the second beta2 was relased last week with lots of new features and bug fixes
[16:13] <zul> you can read how to get started at https://help.ubuntu.com/community/EC2StartersGuide
[16:13] <zul> and join the ec2-beta list at the regular place.
[16:14] <zul> oh yeah these are intrepid images and Im working on jaunty and hardy versions i386/amd64 this week
[16:14] <mathiaz> zul: I've seen a couple of request/comments that the program is not free.
[16:14] <mathiaz> zul: it seems that there is some confusion around the fact that you still have to pay for EC2 even though the beta is free.
[16:15] <mathiaz> zul: should the documentation be updated?
[16:15] <zul> mathiaz: thats correct its in the faq
[16:15] <mathiaz> zul: where is the faq?
[16:15] <zul> it costs nothing to use the images but amazon charges you to use the service
[16:16] <mathiaz> zul: right - but it seems that the message doesn't get through since some people on the mailing have complained about it
[16:16] <zul> mathiaz: https://help.ubuntu.com/community/EC2FAQ#How%20much%20does%20it%20cost%20to%20run%20Ubuntu%20on%20EC2?
[16:16] <nijaba> mathiaz: https://help.ubuntu.com/community/EC2FAQ
[16:17] <zul> mathiaz: they arent reading the rtfm hard enough then ;)
[16:17] <mathiaz> nijaba: zul: do you think this aspect of the beta program should be improved?
[16:17] <ivoks> there are also footnotes on https://help.ubuntu.com/community/EC2StartersGuide
[16:18] <nijaba> mathiaz: I do not what to do, we cannot force people to read
[16:18] <nijaba> mathiaz: every page I created mention the cost issue
[16:19] <mathiaz> nijaba: what about adding a note in the welcome message when users join the beta mailing list?
[16:19] <nijaba> mathiaz: what would make them read this more than any other text?
[16:19] <zul> bold it or something
[16:20] <nijaba> mathiaz: plus the beta program is now very open, the images do not require registration anymore
[16:20] <mathiaz> https://help.ubuntu.com/community/EC2StartersGuide still mentions that the kernel/ramdisk aren't public
[16:21] <mathiaz> in the section: Using the Ubuntu Imags
[16:21] <zul> mathiaz: because im in the middle of updating it :)
[16:21] <mathiaz> in the section: Using the Ubuntu Images
[16:21] <mathiaz> zul: oh - ok.
[16:21] <mathiaz> ok - let's move on.
[16:22] <mathiaz> zul: anything else on this front?
[16:22] <zul> mathiaz: nope
[16:23] <mathiaz> [TOPIC] Ubuntu Bug Day: samba
[16:23] <MootBot> New Topic:  Ubuntu Bug Day: samba
[16:23] <mathiaz> so I've talked with the QA team and we're going to have a Bug day about samba next week
[16:24] <ttx> \o/
[16:24] <mathiaz> next Thursday, March 12th
[16:24] <mathiaz> in preparation I've written a debugging samba page
[16:24] <mathiaz> https://wiki.ubuntu.com/DebuggingSamba
[16:24] <zul> yay!
[16:25] <mathiaz> reviews of this page is welcome
[16:25] <mathiaz> if you think about other common situations please add them to it
[16:25] <mathiaz> the QA team will prepare a list of bugs to target during the hug day next week
[16:26] <mathiaz> hm - the bug list will be prepared this week and I'll review it
[16:26] <mathiaz> so that we can leverage the whole bug triagging community to deal with samba bugs
[16:26] <mathiaz> I think we should target NEW and INCOMPLETE bugs
[16:27] <mathiaz> anything else to add related to the samba bug day?
[16:27] <mathiaz> could we coordinate blog posts announcing it?
[16:27] <mathiaz> ttx: ?
[16:27] <ttx> mathiaz: sure.
[16:27] <zul> making sure that the duplicate bugs are taken care of
[16:28] <mathiaz> so there will be a mention of the samba bug day today on the ubuntuserver blog
[16:28] <ttx> Also making sure that confirmed are really confirmed
[16:28] <ttx> mathiaz: ok, I'll echo that
[16:28] <mathiaz> ttx: what about you blogging about the samba bug day this thurday?
[16:28] <zul> also turning up the debug information for the samba logs
[16:29] <ttx> mathiaz: will do. I'll also make sure to review the DebuggingSamba page before that.
[16:29] <mathiaz> ttx: or may be monday?
[16:29] <ttx> Monday is good, unless you have another echo-man
[16:29] <mathiaz> kirkland: ^^?
[16:30] <mathiaz> ttx: I could also echo it on my blog
[16:31] <mathiaz> ttx: so how about that plan:
[16:31] <mathiaz> today: ubuntuserver (via minutes)
[16:31] <mathiaz> thursday: my blog (unique blog post)
[16:31] <mathiaz> monday: ttx blog (unique blog post)
[16:32] <mathiaz> next thursday: ubuntuserver (via minuteS)
[16:32] <mathiaz> next *tuesday*: ubuntuserver (via minuteS)
[16:32] <ttx> worksforme.
[16:32] <mathiaz> next Thursday: ubuntuserver (unique blog post)
[16:32] <mathiaz> plus the normal announcement from the bug team (ubuntu-bugsquad@)
[16:33] <mathiaz> [ACTION] mathiaz to blog about samba bug day on Thursday
[16:33] <MootBot> ACTION received:  mathiaz to blog about samba bug day on Thursday
[16:33] <mathiaz> [ACTION] ttx to blog about samba bug day on Monday
[16:33] <MootBot> ACTION received:  ttx to blog about samba bug day on Monday
[16:33] <mathiaz> and I'm sure we can ask kirkland to do something too :)
[16:34] <nijaba> mathiaz: I can as well if you want
[16:34] <mathiaz> that also mean some of us should hang out with the QA team to help out with bug triaggers next Thursday
[16:35] <mathiaz> nijaba: sure - could you do one next Wednesday?
[16:35] <nijaba> mathiaz: np
[16:35] <mathiaz> [ACTION] nijaba to blog about samba bug day next Wednesday
[16:35] <MootBot> ACTION received:  nijaba to blog about samba bug day next Wednesday
[16:36] <mathiaz> ttx: will you be around next Thursday?
[16:36] <ttx> mathiaz: yes, I will.
[16:36] <mathiaz> ttx: great - could you cover the first part of the hug day?
[16:36] <mathiaz> ttx: I'll take the second one then
[16:37] <ttx> yep
[16:37] <mathiaz> [ACTION] ttx to cover the first part of the samba hug day
[16:37] <MootBot> ACTION received:  ttx to cover the first part of the samba hug day
[16:37] <mathiaz> [ACTION] mathiaz to cover the second part of the samba hug day
[16:37] <MootBot> ACTION received:  mathiaz to cover the second part of the samba hug day
[16:38] <mathiaz> great - that's all for the samba hug day
[16:38] <mathiaz> anything else to add on this topic?
[16:39] <mathiaz> nope - let's move on
[16:40] <mathiaz> [TOPIC] Open discussion
[16:40] <MootBot> New Topic:  Open discussion
[16:40] <nealmcb>  I've been talking with ljl in #ubuntu-ops about the factoid for screen.  The proposal was "Screen is a window manager for terminal sessions, also good for use over ssh.  See https://launchpad.net/screen-profiles for status bars, clocks, notifiers (reboot-required, updates-available), etc.".  Folks there suggested pointing to a wiki page for screen which could point to other related things, like the two links in the current screen factoid, and
[16:40] <nealmcb> !screen
[16:41] <RainCT> nealmcb: your message was cut at "current screen factoid, and"
[16:42] <nealmcb>  and ljl volunteered to set that up.  This url is available, not used now: https://help.ubuntu.com/community/Screen    See also https://help.ubuntu.com/community/DinkelVersus/Screen
[16:42] <seb128> hi
[16:42] <mathiaz> seb128: hi - what's the state of evolution-exchange integration?
[16:42] <seb128> mathiaz: evolution-mapi you mean?
[16:42] <mathiaz> seb128: hm yes
[16:43] <seb128> it's waiting in NEW now
[16:43] <seb128> I will try to convince one of the other archive admin to review it
[16:43] <nijaba> seb128: the openchange mapi integration!!!  great!
[16:43] <mathiaz> seb128: great - once it's in the archive we need some testing done
[16:43] <ivoks> nice
[16:43] <seb128> thanks
[16:44] <mathiaz> so we're looking for testers - having access to an exchange infrastructure is a prerequisite
[16:44] <mathiaz> I don't have access to such a thing, neither seb128
[16:44] <ivoks> how is that related to ubuntu-server?
[16:45] <ivoks> i have access to some exchange setups :)
[16:45] <mathiaz> ivoks: exchange is used in corporate environment
[16:45] <mathiaz> ivoks: I thought it could be usefull to part of our users
[16:45] <nealmcb> what part of the puzzle does evolution-mapi cover?
[16:46] <ivoks> mathiaz: i know that, but exchange support in evolution doesn't quite sounds like ubuntu-server related; unless we provide exchange :)
[16:46] <mathiaz> ivoks: seb128 was looking for testers and I offered to get a call for testing out as our users should have a higher probabilty to have access to such an infrastructure
[16:46] <ivoks> oh, i see
[16:47] <ivoks> i'll test it, i have one exchange environment :/
[16:47] <mathiaz> ivoks: awesome - it's in the NEW queue for now
[16:47] <nealmcb> I'd love to see someone offer a testing infrastructure by giving ubuntu testers access to an exchange/active-directory environment
[16:48] <mathiaz> jdstrand: ^^ - there is some bits in the NEW queue waiting for you :)
[16:49] <jdstrand> mathiaz: I'm on Friday-- kirkland is on tomorrow. I'll be sure to look at it if it is around on Friday :P
[16:49] <ivoks> btw... i use evolution again, after years and years of claws... maybe i'm wrong, but it works muche better than before
[16:50] <seb128> jdstrand: you can look at NEW out of your archive days ;-)
[16:50] <jdstrand> mathiaz: seriously though. if you *must* have it today and the regular admin can't do it, I'll look at it
[16:51] <mathiaz> jdstrand: it's not that urgent
[16:51] <nealmcb> A first version is now up from ljl at https://help.ubuntu.com/community/Screen
[16:51] <mathiaz> jdstrand: friday will be fine
[16:51] <ivoks> jdstrand: i'll be in exchange environment tomorrow, so if i could get that plugin today, that would be great :}
[16:52]  * nijaba needs to run
[16:52] <jdstrand> I'll give it a shot
[16:53] <mathiaz> great - thanks
[16:53] <mathiaz> let's move on
[16:54] <mathiaz> [TOPIC] Agree on next meeting date and time
[16:54] <MootBot> New Topic:  Agree on next meeting date and time
[16:54] <mathiaz> so north america will change hours this weekend
[16:54] <mathiaz> IIRC europe doesn't - ttx?
[16:55]  * ttx confesses ignorance and googles the question
[16:55] <ttx> March 29 here
[16:55] <ivoks> i guess we all change it
[16:56] <ivoks> north america, europe and part of australia
[16:56] <ttx> ivoks: you live in the world where we all use the same AC plugs ?
[16:56] <ivoks> http://hr.wikipedia.org/wiki/Datoteka:DaylightSaving-World-Subdivisions.png
[16:56] <MootBot> LINK received:  http://hr.wikipedia.org/wiki/Datoteka:DaylightSaving-World-Subdivisions.png
[16:57] <ivoks> ttx: hehe
[16:57] <mathiaz> so the question is whether we should move the meeting to 15:00 UTC or stay at 16:00 UTC
[16:57] <ivoks> ttx: same voltage and SI system? :)
[16:58] <ttx> mathiaz: either is fine by me
[16:58] <mathiaz> AFAICT the tech board meeting has been moved back one hour
[16:58] <mathiaz> so we could start the meeting at 15:00 UTC
[16:58] <ttx> 1500 is even better
[16:58] <ivoks> probably, yes
[16:59] <mathiaz> ok - so we'll move the meeting to 15:00 UTC next week (and the week after)
[16:59] <mathiaz> next week, same place at 15:00 UTC
[17:00] <mathiaz> thanks all
[17:00] <mathiaz> #endmeeting
[17:00] <MootBot> Meeting finished at 11:00.
[17:00] <sommer> later all
[17:00] <ivoks> MootBot needs ntpd :)
[17:00] <sconklin> #startmeeting
[17:00] <MootBot> Meeting started at 11:00. The chair is sconklin.
[17:00] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[17:00]  * pgraner waves
[17:01] <sconklin> This is the weekly kernel team meeting
[17:01] <sconklin> pgraner: I'll deal with you later :)
[17:01]  * amitk waves
[17:01]  * smb_tp here
[17:01]  * manjo waves with a USB stick
[17:01]  * apw arrives
[17:01]  * cking here
[17:01] <pgraner> sconklin: just sharing the love
[17:01] <lieb> here
[17:01] <sconklin> :)
[17:01] <cooloney> Hello folks
[17:01]  * ikepanhc1 here too
[17:02] <cooloney> this is Bryan from Shanghai
[17:02] <sconklin> hi cooloney
[17:02] <sconklin> waiting for Bradf
[17:02] <cooloney> so nice to be here
[17:02] <ikepanhc1> Bryan, nice to see you
[17:03] <apw> welcome cooloney
[17:03] <sconklin> Alright, we'll go ahead
[17:03] <cooloney> thanks man
[17:03] <sconklin> First, welcome to the new kernel engineers
[17:03] <pgraner> sconklin: Agenda is here: https://wiki.ubuntu.com/KernelTeam/Meeting
[17:03] <manjo> where is rtg ?
[17:03] <sconklin> [TOPIC] Security and Bugfix kernels
[17:03] <MootBot> New Topic:  Security and Bugfix kernels
[17:03] <rtg> quit bugging me wghile I eat breakfast
[17:03] <smb_tp> Ok
[17:04] <sconklin> Intrepid?
[17:04] <smb_tp> Hardy and Intrepid got new proposed kernels
[17:04] <smb_tp> So the more testing we would get thee the better
[17:04] <smb_tp> sconklin, Yes
[17:04] <smb_tp> Why
[17:04] <pgraner> smb_tp: how big are the changesets?
[17:05] <pgraner> smb_tp: anything in particular we should be asking for testing on?
[17:05] <smb_tp> Intrepid quite big since this is the one last sync with stable and it was 3 or 4 releases
[17:05] <smb_tp> Generic daily usage
[17:05] <smb_tp> Does every one get a X screen...
[17:06] <smb_tp> Like there is one guy that claims he gets only a black screen
[17:06] <apw> does the kernel boot on jaunty userspace for intrepid ones?
[17:06] <sconklin> smb_tp: any webcam support changes that you noticed?
[17:06] <pgraner> smb_tp: I've moved off Intrepid...
[17:06] <smb_tp> Might be close enough to be running from Jaunty.
[17:07] <pgraner> smb_tp: I've seen the regression list grow quite big, any idea why? http://qa.ubuntu.com/reports/ogasawara/kernel-buglist.html
[17:07] <manjo> sconklin, sony vaio webcam still not supported in intrepid
[17:07] <apw> smb_tp, ok will give it a go
[17:07] <smb_tp> But the problem is then, if there are user-space interactions this does not match
[17:07]  * apw notes there are 5 new regressions on the lsit since we looked at it yesterday!
[17:07] <smb_tp> sconklin, I have not all changes in my head. Thee were jsut too many
[17:08] <sconklin> ok, I think we'll have to just try for everyone who can to look at the regressions
[17:08] <apw> smb_tp, we should scheduler another sweep for the am
[17:08] <sconklin> Any other security issues?
[17:08] <pgraner> smb_tp: might be good if before the meeting we identify the big items and talk about them here?
[17:08] <smb_tp> We should do. Seems some are already assign . Maybe some new includes
[17:08] <pgraner> smb_tp: items being changes in -proposed
[17:09] <apw> pgraner, yes that was silly, we didn't look at the list between yesterday and the meeting when it would have updated
[17:09] <smb_tp> Yes, apwand I should schedule a run over the list for Tues
[17:09] <apw> though ogasawara i don't think you should be holding any regressions back
[17:09] <apw> if you find them add them asap
[17:09] <ogasawara> apw: ack, will do
[17:10] <smb_tp> [ACTION] smb and apw schdule regression list call for Tues
[17:10] <pgraner> apw: I was talking about the growth of regressions. We should have NONE
[17:10] <sconklin> [ACTION] smb and apw schdule regression list call for Tues
[17:10] <MootBot> ACTION received:  smb and apw schdule regression list call for Tues
[17:10] <pgraner> apw: not talking about the delta between yesterday and today
[17:10] <apw> pgraner, well they wern't visible trivially before
[17:10] <smb_tp> pgraner, There are a lot on that list that are regression from release to release
[17:11] <pgraner> Ok now were getting somewhere....
[17:11] <apw> so some are coming out of the wood-work as they are processed
[17:11] <apw> ogasawara, some of these are old right?  time wise?
[17:11] <pgraner> I was asking why do we have so many, are they real regressions or suspected regressions
[17:11] <ogasawara> apw: yes
[17:12] <manjo> there are some bugs opened against hardware that are more than 6yrs old ... and cant get hold of such hardware to look at bugs
[17:12] <apw> i think we have always had them, a large number between releases which we didn't track well
[17:12] <smb_tp> That is my feeling as well
[17:12] <apw> though clearly we are not achieving 0 in each update either
[17:12] <pgraner> apw: makes sense... the number has a lot of people asking
[17:12] <sconklin> would it help to categorize why they happened?
[17:13] <smb_tp> There are a few that come through proposed or updates but many throucgh release as well
[17:13] <smb_tp> With the new list that happens
[17:13] <pgraner> ogasawara: another column?
[17:13] <apw> for example i am fixing a bug today which was a hardy->intrepid release regression
[17:13] <smb_tp> There are regression-release and regression-update
[17:13] <apw> triggered by a userspace interaction which was not tracked
[17:13] <ogasawara> pgraner: I do have the tags in bold in the comments field
[17:13] <smb_tp> ogasawara, Do we also have regression-proposed?
[17:14] <ogasawara> smb_tp: no, but I can easily add it
[17:14] <pgraner> ogasawara: they don't tell us why as described above
[17:14] <sconklin> apw: so for example, was it a missed sauce patch, something in our patch directory, a missed commit upstream?
[17:14] <sconklin> apw: nm, you answered
[17:14] <apw> the specific one was a change to our udev, which was not tracked or informed to the kernel (to my knowledge)
[17:15] <apw> and we didn't find out until well into intrepid's release
[17:15] <apw> i don't think we are free of blame, just our bug load is mamoth
[17:15] <sconklin> yeah, so if we find that we have a lot of those userspace interactions, it will help us focus calls for testing in the future
[17:15] <pgraner> Lets take this offline. We can cover this at the sprint and report back to the list as to what came out of it
[17:15] <apw> it does raise the question of whether we did our userspace sync checks right this cycle
[17:16] <sconklin> [ACTION] discuss tracking and reduction of regressions at the sprint
[17:16] <MootBot> ACTION received:  discuss tracking and reduction of regressions at the sprint
[17:16] <apw> ack
[17:16] <smb_tp> ack
[17:16] <pgraner> apw: agreeed
[17:16] <sconklin> any more security issues?
[17:16] <smb_tp> no
[17:16] <sconklin> I'm going to skip the archiving LPIA trees and cover it later during LPIA status
[17:16] <sconklin> [TOPIC] Jaunty status
[17:16] <MootBot> New Topic:  Jaunty status
[17:17] <sconklin> How'd the alpha release go?
[17:17] <apw> we upset the release team by needing to do a kernel upload
[17:17] <apw> for an arm change, the request for which came from outside
[17:18] <rtg> slangasek didn't hassle me too much, so I assume it went fine after that
[17:18] <pgraner> apw: unfortunately this will happen until we the ARM arch established....
[17:18] <sconklin> is there any benefit in adding an embargo to our process for a period preceding a release?
[17:18] <manjo> can we patch drivers under staging ? in jaunty ?
[17:18] <apw> i was going to suggest we perhaps set our own kernel-alpha-N dates in the
[17:18] <apw> diary, to try and get earlier warning from our dependants
[17:18] <apw> by making it clearer it takes 3 days to get our kernel out
[17:18] <pgraner> apw: good point
[17:19] <rtg> sconklin: I typically _don't_ upload the 3-4 days prior to an alpha release
[17:19]  * amitk takes the blame
[17:19] <sconklin> is that another sprint topic?
[17:19] <apw> right and i think we are all aware, but if there was a marker on the calender 2-3 days before each marker
[17:19] <pgraner> sconklin: make sure you add these to the wiki since you have the action list :-)
[17:20] <pgraner> rtg: your favorite kdump and apport reporting... how's it going man?
[17:20] <sconklin> [ACTION] add marker to calendar to show end of outside change acceptance
[17:20] <MootBot> ACTION received:  add marker to calendar to show end of outside change acceptance
[17:20] <rtg> its kind of in an intermediate state.
[17:21] <rtg> we have an update to kexec 2.0.0, but without some of the upstream debian packaging fixes.
[17:21] <rtg> I'll be working on that today
[17:21] <pgraner> rtg: are the debian fixes important? what are we missing?
[17:21] <rtg> then I'll finish my recipe for disaster on the wiki
[17:21] <rtg> pgraner: unknown, other then some armel support
[17:22] <pgraner> amitk: you want kdump?
[17:22] <sconklin> any updates on Jaunty LPIA into the distro kernel? I skipped that agenda item
[17:22] <amitk> pgraner: I don't. But kexec is something close to the hearts of the mobile team
[17:22] <rtg> yeah, ogra and lool are hot for it
[17:22]  * ogra looks up
[17:22] <pgraner> rtg: you going to fold the debian changes in then?
[17:23] <amitk> that might be the only way to get a uniform booting system for arm platforms
[17:23] <rtg> that's my goal
[17:23] <pgraner> rtg: ack
[17:23] <amitk> if we can't get bootloader access
[17:23] <lool> pgraner: At least armel should be listed in the control file, otherwise we can't use it on armel
[17:23] <ogra> right
[17:23] <rtg> amitk: you mean, use kexec for something other then crash analysis?
[17:24] <amitk> rtg: correct. To jump into another kernel
[17:24] <lool> Besides, there was a plethora of packaging issues, which I covered with lieb yesterday
[17:24] <amitk> as a method for booting
[17:24] <ogra> not merging the debian changes will require a massive amount of work in larmic
[17:24] <rtg> amitk: huh, never thought of using it that way.
[17:24] <ogra> *karmic
[17:25] <ogra> better do it proper now than having to do twice the work next round
[17:25] <pgraner> rtg: are you doing the pkging changes? lieb did you pass the notes on to rtg? I don't want this to drop
[17:25] <sconklin> rtg: it allows booting from flash devices where you can't easily change the initial kernel
[17:25] <rtg> pgraner: its not gonna drop.
[17:25] <lieb> pgraner, yes I did wrt what I knew
[17:25] <pgraner> lieb, rtg: great thx
[17:26] <rtg> its been top of ny todo list for 2 weeks
[17:26] <sconklin> anything else on kexec?
[17:26] <sconklin> [TOPIC] call for testing - suspend/resume
[17:26] <MootBot> New Topic:  call for testing - suspend/resume
[17:26] <rtg> not that I know of, just figured out the debug images last night
[17:27] <sconklin> are we seeing inbound bug reports for suspend/resume?
[17:27] <apw> the call went out ...
[17:27] <pgraner> apw: how have we made out with the ones that have been reported?
[17:28] <apw> i think i have only seen one which was a stress test failure
[17:28] <apw> i am still going trhough them and pointing them for first alalysis
[17:28] <apw> not much progress.  workload has made me less responsive there than i would prefer
[17:28] <pgraner> Is nvidia still the pain point?
[17:28] <apw> we have been concentratingin on the regressions and HIGH bugs recently
[17:28] <sconklin> as far as we know the testing scripts are pretty stable and mature now, right?
[17:29] <apw> there are some nvidia reports but not the majority by any means
[17:29] <apw> the testing scripts are pretty solid yes
[17:29] <apw> expecting a public call in a couple of weeks i guess
[17:29] <pgraner> apw: brace for impact
[17:29] <IntuitiveNipple> I've got three active and several yet to examine in detail. One (nvidia MCP78S) looks to be a simple omission of quirk code during resume according to mainline, which is fixable easily.
[17:30] <apw> IntuitiveNipple, thanks for looking at those.  you noted the tag combinations there?
[17:30] <IntuitiveNipple> I've just about finished creating a (sqlite) database for all firmware usage/load instances to check for request_formware() resume delays.
[17:31] <IntuitiveNipple> apw: not that I recall... still getting to grips with them :)
[17:32] <sconklin> ok, anything to report for bugs and bug tracking? We already agreed to have a regression review before this meeting
[17:32] <sconklin> next week
[17:32] <apw> as for incoming volumes generally for suspend/resume i am seeing about 5 a day down from 7
[17:32] <apw> no idea if its a trend yet
[17:32] <pgraner> apw: I suspect it will increase as more and more people start moving to Jaunty
[17:32] <apw> we may sink without a trace
[17:33] <sconklin> at least we have some tools in place
[17:33] <pgraner> according to manjo Jaunty is still eating bunnies
[17:33] <manjo> I am having issues with 64bit
[17:33] <rtg> I thought we agreed it was python that was eating bunnies?
[17:33] <pgraner> rtg: yea pythons like bunnies
[17:34] <manjo> I updated python form the ppa but still have issues
[17:34] <sconklin> manjo: what sort of issues? Is it something that you need help with?
[17:34]  * pgraner wonders if its manjo issues?
[17:34] <manjo> sconklin, yeah we can talk offline
[17:34] <sconklin> manjo: ok
[17:34] <manjo> well apport dies, network manager dies, browser dies,
[17:34] <amitk> PBKAC
[17:35] <sconklin> any more bug issues? ogasawara, anything to add?
[17:35] <manjo> system-preferennces- windows diesw
[17:35] <ogasawara> sconklin: just a few to point out (but seems the majority already have a dev assigned)
[17:35] <manjo> create usb stick dies
[17:35] <ogasawara> bug 336055
[17:35] <ogasawara> seems patches will go upstream for this ^^
[17:36] <apw> that says its fixed?
[17:36] <ogasawara> bug 334994
[17:36] <sconklin> that issue has gotten a huge amount of coverage, we need to get it in quickly
[17:36] <sconklin> 336055 that is
[17:36] <ogasawara> apw: the bot's on crack
[17:36] <apw> :)
[17:37] <ogasawara> then three regressions, bug 331092, bug 255651, bug 258985
[17:37] <ogasawara> two are in progress already so that looks good
[17:38] <apw> ogasawara, if those non-regression bugs are _bad_ could you add the watch tag to them
[17:38] <ogasawara> apw: yes
[17:38] <sbeattie> I need to update the description to make it SRU ready, but I'd like to get bug 329489 in this round of SRUs (needs to go into jaunty as well)
[17:38] <apw> the floppy one should have a 90% fix from keybuk by tommorrow
[17:38] <ogasawara> sbeattie: I'll get it on the list
[17:39] <sbeattie> ogasawara: thanks.
[17:39] <ogasawara> sconklin: that's it for now
[17:39] <sconklin> anything else bug related?
[17:40] <sconklin> haha ok
[17:40] <sconklin> [TOPIC] vanilla kernel builds
[17:40] <MootBot> New Topic:  vanilla kernel builds
[17:40] <Keybuk> (I'm just checking that the kernel is really ok with a module having an unused device table)
[17:40] <apw> the announcement went out, and even made lwn
[17:40] <sconklin> Looks like we're getting some discussion of this as relates to the triage process
[17:40] <sconklin> exactly
[17:41] <apw> in the last week the automation has been upgraded to build them against their base releases
[17:41] <apw> so .24 on hardy etc, and allowing us to turn on things turned off and replaced in lum
[17:41] <sconklin> lwn aside, there seem to be a lot of people happy with having the resource available
[17:41] <rtg> apw: I tried 2.6.15 for dapper, but ran into gcc issues.
[17:41] <cooloney> right, lwn announced it.
[17:41] <apw> other than that, mostly positive except for the "an excuse to Incomplete our bugs" comments
[17:42] <sconklin> ok, nice job apw, we'll just continue to watch this
[17:42] <sconklin> [TOPIC] ARM Tree status
[17:42] <MootBot> New Topic:  ARM Tree status
[17:42] <apw> rtg ahh that makes sense.  we would probabally need dapper chroots for that
[17:42] <cooloney> does that vanilla kernel builds including armel?
[17:42] <rtg> cooloney: x86/x86_64 only
[17:42] <amitk> cooloney: not currently
[17:42] <cooloney> ok, thanks
[17:43] <sconklin> amitk: anything to add?
[17:43] <amitk> not really, we got ixp4xx working last week
[17:43] <amitk> I am working on adding another board support to the tree
[17:44] <sconklin> ok, moving on . . .
[17:44] <sconklin> [TOPIC] LPIA tree status
[17:44] <MootBot> New Topic:  LPIA tree status
[17:44] <sconklin> Here's what I know:
[17:45] <sconklin> Most lpia projects are still working out of the old netbook trees, because of release cycles that made is risky to change over. We will change over to the new trees during the sprint
[17:45] <apw> has there been any touch testing of our tree?
[17:45] <pgraner> sconklin: I know you asked for testing from the OEM team and feedback on the kernels?
[17:45] <sconklin> I missed some patches in the debian patch directories when I brought them over to the new trees. lieb was looking at that
[17:45] <lieb> true
[17:45] <cking> what's the status of the lrm?
[17:46] <sconklin> the OEM team has said a couple of times that they would test, but afaik they have not
[17:46] <apw> we need to try and get them to do at least a touch before we get there
[17:46] <sconklin> apw: agreed.
[17:46] <pgraner> awe: any input?
[17:47] <rtg> sconklin: you could annoy awe about it right now.
[17:47] <cking> sconklin: whats the low down on lpia lrm?
[17:47] <sconklin> lrm still resides in a repo that the OEM group has - we need to figure out at the sprint how to keep it synced with the new kernel trees
[17:47] <awe> pgraner: nope, sconklin let's talk this afternoon.
[17:47] <amitk> sconklin: what do they need from lrm? madwifi?
[17:47] <sconklin> [ACTION] pgraner, sconklin, awe to discuss OEM testing of lpia trees
[17:47] <MootBot> ACTION received:  pgraner, sconklin, awe to discuss OEM testing of lpia trees
[17:48] <cking> amitk: broadcom amongst others
[17:48] <sconklin> amitk: I believe that's correct
[17:48] <amitk> and they have patches to lrm that hardy lrm doesn't?
[17:49] <rtg> amitk: since Leffler published the HAL, we should move madwifi to the kernel package.
[17:49] <sconklin> amitk: I don't know
[17:49] <amitk> rtg: yes
[17:49] <awe> amitk: yes
[17:50] <sconklin> we need to discuss this with the OEM folks participating
[17:50] <awe> rtg: is the *free* version of madwifi stable now?
[17:50] <amitk> rtg: but would you do that move on a LTS?
[17:50] <rtg> awe: danged if I know
[17:50] <rtg> amitk: I think just Jaunty initially
[17:51] <cking> sconklin: perhaps we need to get an idea of what's different in the lrm variants before the sprint
[17:51] <amitk> that makes sense
[17:51] <sconklin> cking: agreed, and I'll put a wiki page up that defines the different strategies we're taking for hardy and post-hardy
[17:51] <cking> cool
[17:52] <sconklin> [ACTION] sconklin to create wiki page showing lpia source structure and repos for various releases
[17:52] <MootBot> ACTION received:  sconklin to create wiki page showing lpia source structure and repos for various releases
[17:52] <sconklin> And I think I just found my sprint presentation topic as well :)
[17:52] <apw> sconklin, be good to make that page generic so we can add ports and the like to it
[17:53] <sconklin> apw: more meta ? OK
[17:53] <sconklin> anything else on lpia?
[17:53] <sconklin> [TOPIC] incoming bugs
[17:53] <MootBot> New Topic:  incoming bugs
[17:53] <sconklin> I think we already covered this
[17:53] <apw> yeah
[17:53] <sconklin> nothing more that's bug related?
[17:53] <sconklin> [TOPIC] open discussion
[17:53] <MootBot> New Topic:  open discussion
[17:54] <sconklin> anything?
[17:54] <amitk> yes
[17:54] <apw> be nice to see the actions from the meeting mailed out
[17:54] <apw> so we don't lose them
[17:54] <sconklin> will do
[17:54] <apw> as a general request for each meeting
[17:54] <amitk> elmo mentioned this morning that 64-bit downloads are a single digit percentage of ubuntu downloads
[17:54] <sconklin> would you like some selected content included or are the actions enough?
[17:55] <apw> for me actions is what i am after
[17:55] <amitk> which was somewhat a surprise
[17:55]  * apw concurs with amitk 
[17:55] <maco> there's still the perception that 64bit means everything breaks
[17:55] <cking> I'm gobsmacked
[17:55] <amitk> perhaps our download pages need rearranging?
[17:55] <pgraner> all I use is 64bit
[17:55] <apw> same here
[17:55] <rtg> perhaps we need to stop build 32 bit?
[17:55] <cooloney> right, i use 64bit on macbook pro
[17:56] <cooloney> jaunty
[17:56]  * pgraner listens to the crickets chirping
[17:56] <apw> sadly there were some compelling reasons to stay 32 bit
[17:56] <maco> i think if the release notes simply said that 64bit flash and java plugins now exist, more people would download 64bit
[17:56] <amitk> rtg: there are still several apps (closed ones mostly) that don't treat 64-bit as first class citizen
[17:56] <manjo> quick question... are we patching drivers under staging for jaunty?
[17:56] <rtg> I know
[17:56] <amitk> flash, skype and google gears are my usecases
[17:56] <amitk> manjo: why can't the patch go directly upstream?
[17:57] <apw> though i use 32 bit skype i think on my 64 bit laptop
[17:57] <manjo> amitk, that is another possiblity
[17:57] <pgraner> apw: I do the same
[17:57] <pgraner> We r about out of time....
[17:57] <amitk> rtg: I guess I am building up a case for restoring the PAE kernels for 32-bit since more people with lots of memory are hanging onto 32-bit
[17:57] <apw> though i believe my experience was that 64 bit is only just hitting ok status
[17:57] <sconklin> any suggested actions for encouraging 64 bit use?
[17:58] <cking> don't call it amd64
[17:58] <rtg> amitk: I've about decided that myself
[17:58] <pgraner> sconklin: I'll blog about it
[17:58] <apw> at least for Jaunty
[17:58] <manjo> sconklin, I dont feel encouraged
[17:58] <maco> cking: good point. intel core 2 users might think it doesn't apply
[17:58] <amitk> sconklin: rearrange the download page :)
[17:58] <cooloney> flash and skype for 64
[17:58] <sconklin> ok then, we need to wrap this up
[17:58] <rtg> amitk:  I _did_ talk to the server team about dropping the 32 bit server flavour.
[17:58] <sconklin> same time and place next week.
[17:58] <apw> ack
[17:58] <amitk> bye all
[17:58] <pgraner> out
[17:59] <apw> we can contnnue on #u-kernel
[17:59] <manjo> out
[17:59] <sconklin> #endmeeting
[17:59] <MootBot> Meeting finished at 11:59.
[17:59]  * rtg beams down to the planet
[17:59] <lieb> bye
[17:59] <cooloney> see you
[17:59] <cooloney> bye
[17:59] <smb_tp> bye
[21:01] <dholbach> hello
[21:01] <dholbach> hi elmo
[21:01] <dholbach> hey Technoviking
[21:01] <dholbach> sabdfl just passed on he won't make it today
[21:02] <mako> greetings
[21:02] <dholbach> hey mako
[21:02] <dholbach> #startmeeting
[21:02] <MootBot> Meeting started at 15:02. The chair is dholbach.
[21:02] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[21:03] <dholbach> we don't have much on the agenda today: https://wiki.ubuntu.com/CommunityCouncilAgenda
[21:03] <dholbach> [TOPIC] people.ubuntu.com
[21:03] <MootBot> New Topic:  people.ubuntu.com
[21:03] <dholbach> nhandler is not here today
[21:04] <dholbach> elmo: do you know anything about the status there? was it specified closer what needs doing there?
[21:04] <elmo> yeah, I know what needs doing; the only hairy part is transitioning the existing contents (obviously, don't want to break URLs)
[21:05] <elmo> oh, and quotas, but we don't need those first thing I guess
[21:05] <dholbach> elmo: should we ask people to prepare a list of stuff that needs moving (and also list what can just go away?)
[21:05] <elmo> beyond that, it's just finding resource/time to write the code, implement it.  I'll try and push that forward as soon as i can
[21:06] <elmo> dholbach: I think we have to keep existing links working, so people.ubuntu.com/~james will 302 to people.canonical.com/~james
[21:06] <elmo> that's only scary in terms of a) the mapping, and b) apt not following redirects
[21:06] <elmo> so, the latter is possibly something I should warn folks about
[21:07] <dholbach> so nothing that people can actually help out with?
[21:07] <elmo> not at this stage, I don't think.  if I find anything that can be done by others, I'll be sure to yell
[21:08] <dholbach> great, thanks a bunch James
[21:08] <dholbach> alright
[21:08] <dholbach> [TOPIC] AOB? :)
[21:08] <MootBot> New Topic:  AOB? :)
[21:09] <mako> hi Burgundavia
[21:09] <Burgundavia> hey mako
[21:09] <dholbach> hi Burgundavia
[21:09] <dholbach> Burgundavia: we're in the "any other business" part of the meeting already :)
[21:10] <Burgundavia> oh
[21:10] <Burgundavia> 9 minutes in and we are already there?
[21:10] <dholbach> I'm all set - what about you guys?
[21:11] <mako> Burgundavia: short meeting, apparently :)
[21:11] <mako> which is fine by me :)
[21:11] <mako> nothing on my end
[21:11] <Burgundavia> I am done
[21:11] <dholbach> perfect.... I'll update the team report then :)
[21:11] <dholbach> thanks a bunch everybody
[21:11] <dholbach> #endmeeting
[21:11] <MootBot> Meeting finished at 15:11.
[21:11] <mako> thanks everyone :)