[02:13] <gagita> my karmic doesn't detect sound hardware in compaq nc6230
[02:13] <gagita> anybody can help me please ??
[02:15] <nhandler> gagita: You should try #ubuntu for support
[02:15] <gagita> nhandler: okay
[10:09] <czajkowski> baffling how folks end up in here for support
[10:46] <FFEMTcJ> hehe czajkowski
[10:46] <czajkowski> FFEMTcJ: hi
[10:47] <FFEMTcJ> mornin
[16:58] <liel> Hello
[16:58] <FFEMTcJ> hi
[18:02] <kees> jdstrand_, mdeslaur: ready to do meeting?
[18:03] <jdstrand_> sure
[18:03] <mdeslaur> sure
[18:03] <kees> okidoky.  I'm on vacation this week.  should we swap with the 2009-12-14 week for duties?
[18:03] <kees> or is there some other way we should handle it?
[18:04] <jdstrand_> kees: mdeslaur said he'd take triage
[18:04] <jdstrand_> I'll take community
[18:04] <mdeslaur> yep
[18:04] <mdeslaur> I don't think we need to officially swap
[18:05] <jdstrand_> kees: we can fight it out next week
[18:05] <kees> right, which is the 2009-12-14 week's schedule.  I want to make sure I don't just skip out on doing triage
[18:05] <kees> er, ok
[18:05] <kees> I'll triage next week then
[18:05] <jdstrand_> ok, I'll continue with community next week then
[18:05] <kees> I'll likely be doing a kernel publication this week some time too
[18:06] <kees> I love my vague definition of "on holiday"  :P
[18:06] <mdeslaur> hehe
[18:06] <kees> can someone coordinate with lamont on bind9 too?  I'd really like a PoC for that.
[18:07]  * lamont looks up
[18:07] <kees> lamont: bind9 is public now. do you know of any PoC we can use for testing?
[18:07] <lamont> I haven't found any reproducer script at all
[18:08] <lamont> not sure but what it might have been theoretical, maybe?
[18:08] <kees> oh.  hm, ok
[18:08] <lamont> though from the writeup, I expect it was seen somewhere, just not with an attack per se
[18:08] <lamont> i'll poke upstream again
[18:08] <kees> have you had a chance to do hardy and newer packages?  mdeslaur prepared the dapper backport
[18:11] <kees> I'll assume not.  :)
[18:11] <kees> mdeslaur: do you want to continue with bind9 since you've done the dapper bit already?
[18:12] <mdeslaur> kees: yeah, sure
[18:12] <kees> jdstrand_: you still there?  saw drop/reconnect there..
[18:12] <jdstrand_> I am here
[18:12] <kees> ok, cool
[18:12] <kees> just checking.  :)
[18:13] <mdeslaur> so, I'm working on lucid php5 now, and will start bind9 after
[18:13] <mdeslaur> also, I'm on triage
[18:14] <mdeslaur> that's all for now
[18:15] <jdstrand_> I am on community this week
[18:15] <jdstrand_> I plan to look over the fake sync stuff and coordinate with stefanlsd as needed
[18:16] <jdstrand_> beyond that, I have a libvirt merge, ufw SRU, apparmor for ff branches (I now have commit access) and get back to rhc
[18:16] <kees> cool.
[18:17] <kees> alright, so, lucid planning.  we've got a bunch of blueprints, but we didn't really show our "TODO" items, since we didn't know bloueprints would be turned into the burn-down chart stuff.
[18:17] <jdstrand_> I am almost caught up on email, and need to do irc backscroll
[18:17] <jdstrand_> beyond that, I need to go through all the blueprints (which I think we are going to discuss next)
[18:18] <kees> cool, yeah, shall we do that?
[18:18] <kees> https://blueprints.edge.launchpad.net/ubuntu/lucid?searchtext=security
[18:19] <mdeslaur> sure
[18:19] <jdstrand> kees: sure
[18:20] <kees> ok, so, I think we have two things to cover:
[18:20] <kees> 1) what is *not* shown in blueprints that should be represented by our burndown chart?
[18:20] <kees> 2) what priorities should we set for blueprints?
[18:21] <kees> with #1, I know of sVirt and ufw work.
[18:21] <kees> and I've got mmap_min_addr work, and more PIE work
[18:22] <mdeslaur> should we just add them to the catchall blueprint?
[18:22] <kees> the PIE and mmap_min_addr work probably should go there, yeah
[18:23] <kees> but it feels like sVirt and ufw might be better served by being separate.  jdstrand: is the sVirt stuff already shown in the lxc blueprint?
[18:23] <jdstrand> I finally read https://wiki.ubuntu.com/WorkItemsHowto this morning, which helped
[18:23] <kees> heh
[18:23] <jdstrand> kees: I'm not doing lxc
[18:23] <jdstrand> kees: there was some confusion there I think
[18:24] <kees> jdstrand: right, absolutely.  I guess I meant the "bug 480478" item
[18:24]  * kees goes to read that bug
[18:24] <jdstrand> kees: there is no sVirt support for lxc, so it would require a *lot* of resources that we don't have (not to mention, upstream coordination for selinux)
[18:24] <jdstrand> kees: oh, that'll be fixed fast
[18:24] <kees> right, totally, I don't mean that -- that's totally unscoped.
[18:25] <kees> ok.  is there any sVirt work beyond that bug?
[18:25] <jdstrand> kees: the sVirt stuff is <backingstore>, hostdev and state files
[18:25] <kees> ah! right, I remember now.
[18:25] <kees> ok, I think that since sVirt and ufw work both have long lists of things you want to get done, they should have their own blueprints.  is that cool with you?
[18:25] <jdstrand> that all requires work, but I don't think anything crazy
[18:26] <jdstrand> kees: it is, though I am not completely sure on the approach
[18:26] <jdstrand> kees: eg, I have 3 libvirt items (see above)
[18:26] <jdstrand> I also need to do a merge and do regular maintenance of the driver
[18:26] <jdstrand> I guess the merge is TODO
[18:27] <jdstrand> but the other shouldn't be tracked
[18:27] <kees> yeah, basically every action you can reasonably imagine at this point should get broken out into a work item.
[18:27] <kees> why shouldn't the other be tracked?
[18:27] <jdstrand> kees: cause 'regular maintenance' is a 'forever item'
[18:27] <kees> ok, fair enough
[18:27] <jdstrand> we track something that I can't close?
[18:27] <jdstrand> s/we/why/
[18:28] <kees> yeah, good way to test a workitem.
[18:28] <jdstrand> I am not asserting that position-- I just don't have a firm grip on the new bp process
[18:28] <jdstrand> (though, it seems to make sense)
[18:28] <kees> no, I think that's correct.  regular maint work hasn't shown up in anyone else's burndown chart, I don't think.
[18:29] <jdstrand> ok
[18:29] <jdstrand> so, with ufw, perhaps I'll just add the stuff to a new bp that I plan to work on?
[18:29] <jdstrand> mark it all TODO
[18:29] <kees> ok, so if you can create security-lucid-libvirt-devel (or something) and security-lucid-ufw-devel (or appropriate) and add the items, we'll be good
[18:29] <jdstrand> then the rest stays in the roadmap
[18:29]  * jdstrand nods
[18:29] <kees> sounds good.
[18:30] <kees> I just want our burn-down charts to do a reasonable job of approximating our devel work.
[18:30] <jdstrand> I do need to add firefox/apparmor to that list then
[18:30] <jdstrand> (the catchall)
[18:30] <jdstrand> since I need to get it going in the 3.6 and 3.7 branches
[18:30] <kees> the odd bit is how our team deals with devel work, though, and for that we need robbiew to tell us what a burndown chart means for us when we can't commit to all our devel tasks.
[18:30]  * kees nods
[18:31] <robbiew> hmm
[18:31] <jdstrand> we at least can't commit to the strict time frames of the burndown
[18:31] <robbiew> not sure if the burndown chart applies, but having the work items explicitly listed does
[18:32] <jdstrand> there are some things we can commit to, surely, but it won't be the pretty diagonal line
[18:32] <robbiew> also the Status view on the report.html file is a quick way to get a pulse on the progress
[18:32] <kees> our chart, btw, is here: http://piware.de/workitems/security/lucid/report.html
[18:32]  * robbiew doesn't expect to see a pretty dotted line ;)
[18:33] <robbiew> that is, no one is dinged for having to make tradeoffs between nice-to-have development work and required security updates ;)
[18:33]  * kees wishes there was "essential" in addition to "open", "finished", and "postponed"
[18:34] <jdstrand> yeah, that would help express our situation better
[18:35] <jdstrand> the burndown, doesn't have priorities at all
[18:35] <jdstrand> (maybe that is by design, I don't know)
[18:35]  * kees nods
[18:35] <jdstrand> kees: so, as for '1'-- there may be a few things I'll add as I go through the bps
[18:35] <kees> rather, I nod in agreement with not knowing
[18:35] <jdstrand> kees: I can't think of anything else otoh
[18:35] <kees> jdstrand: right, totally.  I expect we'll hit stuff we didn't consider.
[18:36] <jdstrand> kees: so, 2'? (priorities)
[18:36] <kees> jdstrand: I tried to be conservative with items, "present fscaps to Debian", "refactor with Debian feedback", etc.
[18:36] <kees> right, so, for 2.  there was confusion in email about this.
[18:37] <kees> the biggest issue, is, I think, the catchall priority, as some things are essential, and some are low, etc
[18:37] <jdstrand> yeah, I saw some of that-- I'll read through it all and try to try to be appropriate ;)
[18:38] <jdstrand> kees: well, maybe we should break out the essential items into its own bp?
[18:38] <jdstrand> security-lucid-catchall-essential or some such
[18:38] <kees> jdstrand: I was pondering such a thing, yeah.  robbiew, does that make sense?  it also smells like overkill
[18:39] <mdeslaur> why not just prefix each item there with a priority
[18:40] <kees> mdeslaur: that seems like a better middle-ground for now.
[18:40] <jdstrand> will that mess up the scripting?
[18:40] <kees> mdeslaur: it'll capture the information, and if we need to break out, we can do it mechanically
[18:40] <jdstrand> maybe:
[18:40] <mdeslaur> well, something like [mdeslaur] low - do this and that: TODO
[18:40] <robbiew> kees: +1
[18:40] <kees> right
[18:40] <jdstrand> [nick] (essential) text..: TODO
[18:41] <robbiew> after reviewing it last night, I felt the same about breaking it out
[18:41] <robbiew> but didn't want to freak anyone out by making that request ;)
[18:41] <kees> robbiew: +1 to separate blueprints?
[18:41] <robbiew> yes
[18:41] <robbiew> sorry
[18:41] <kees> ok
[18:41] <mdeslaur> ok
[18:42]  * robbiew is doing too much multitasking :/
[18:42] <kees> heh
[18:42] <jdstrand> kees: so should we go through the catchall list for what should be essential?
[18:42] <kees> jdstrand: yes, though it sounds like we should make ...-catchall-essential, ...-catchall-high, etc,
[18:42] <kees> and move stuff appropriately.
[18:43] <jdstrand> that's fine
[18:43] <jdstrand> kees: if we decide the prioritiies, I'll shuffle everything around
[18:43] <kees> jdstrand: ok
[18:44] <jdstrand> clean up on pam_apparmor: medium?
[18:44] <kees> yeah
[18:44] <jdstrand> upstartify apparmor:  essential?
[18:44] <mdeslaur> yes
[18:44] <kees> yeah
[18:44] <kees> (i'll take notes)
[18:44] <jdstrand> split apparmor profile loading to separate packages: ?
[18:45] <kees> essential
[18:45] <jdstrand> what does this mean exactly?
[18:45] <kees> it's technically part of AA upstartification, but it'll take a while
[18:45] <kees> aa itself needs to be upstartified, which includes changes to mountall (to get the securityfs mounted)
[18:45] <jdstrand> is this the kernel saying "oh, I have a profile for this executable, let's load it?"
[18:45] <jdstrand> s/?"/"?/
[18:45] <kees> and the individual profiles should be loaded before starting various services.
[18:46] <jdstrand> sure, ok
[18:46] <kees> no, not kernel-triggered loading, but just upstart loading
[18:46] <jdstrand> switch Firefox profile on for Lucid dev cycle: ?
[18:46] <kees> i.e. load dhcp profile in the pre-start to interface-up
[18:46] <jdstrand> for dev, essential
[18:46] <jdstrand> for release, err, 'not essential'?
[18:46] <jdstrand> :)
[18:47] <kees> yeah
[18:47] <jdstrand> well, I tweaked that to say 'dev' anyway
[18:47] <kees> for the evince/firefox bits, I think "high" for the tests, "medium" for the doing it
[18:47] <jdstrand> ok, next...
[18:47] <jdstrand> k
[18:47] <kees> I'll split the fscaps between High and medium, I think
[18:48] <jdstrand> kees: why don't you take this next batch, since it is all assigned to you
[18:48] <kees> k
[18:48] <kees> execution blocking: high
[18:48] <kees> mmap_min_addr: medium
[18:48] <kees> mono stack: low
[18:48] <kees> execstack list: essential
[18:48] <jdstrand> kees: hold on
[18:49] <jdstrand> execution blocking: high -- is that EXE or nautlius, or both?
[18:49] <jdstrand> (and jar, et al)
[18:49] <kees> it's making sure that neither wine nor nautilus runs stuff
[18:49] <kees> exe is wine, desktop is nautilus
[18:49] <kees> (there are 3 tasks)
[18:49] <jdstrand> right, ok
[18:50] <jdstrand> 'high'
[18:50]  * kees nods
[18:50] <kees> what is "obtain a list of distros partner vendor apps support" ?
[18:50] <jdstrand> ah
[18:51] <jdstrand> that was seeing if a vendor just supports ubuntu and redhat, say, and then we tell them "oh, well, then you can enable these compiler flags, since we both already do that"
[18:51] <mdeslaur> yes
[18:51] <mdeslaur> kees: that was your idea :P
[18:51] <kees> ah! right.
[18:52] <kees> uhm, medium.
[18:52]  * jdstrand wonders about the difference between medium and low...
[18:52] <jdstrand> anyhoo, medium sounds fine
[18:52] <kees> low is "hah, yeah, won't that be nice"
[18:53] <kees> at least, that's my take on it
[18:53] <jdstrand> heh, ok
[18:54] <kees> should early EOL go to mvo?
[18:54] <jdstrand> I would think so
[18:54] <kees> UUSN: low
[18:54] <kees> early EOL: high? med?
[18:54] <jdstrand> push clamav from -backports to -security: essential (but a < lucid task)
[18:55] <jdstrand> kees: medium?
[18:55] <jdstrand> kees: but it feels weird assigning a priority for someone else
[18:55] <kees> right, but this is just our starting plan.  we can adjust.
[18:55] <jdstrand> ok
[18:56] <kees> motu process update: essential (since it is easy) ?
[18:56]  * jdstrand nods
[18:56] <mdeslaur> sure
[18:56] <kees> ok, I've rearranged catchall by priority and added tasks for creating the other blueprints.
[18:56] <kees> so, "create essential: TODO" followed by all the essential stuff to move there.
[18:57] <jdstrand> kees: sounds good-- this is in the whiteboard?
[18:57] <kees> yup.  that way the burndown chart will still work until the bps exist
[18:59] <jdstrand> ok-- I assigned them to me for now
[18:59] <jdstrand> I plan to do the bp stuff today
[18:59] <kees> cool
[18:59] <kees> alrighty, are the other bps prioritized appropriately?
[18:59] <kees> https://blueprints.edge.launchpad.net/ubuntu/lucid?searchtext=security
[19:00] <jdstrand> kees: screenlocking is the wiki page creation?
[19:00] <kees> jdstrand: correct
[19:00] <kees> jdstrand: a usable way to triage screenlocking issues.
[19:00] <kees> it is not getting the bugs fixed.
[19:00] <kees> though tedg made it sound like many were fixed in karmic.
[19:00] <jdstrand> right
[19:01] <jdstrand> I think security-lucid-apparmor-usability is essential
[19:01] <kees> wow, really?  there were some big features in there.
[19:01]  * jdstrand looks again
[19:01] <kees> I wasn't really comfortable committing to them all.
[19:01] <jdstrand> oh
[19:02] <jdstrand> I was speaking of likewise and tunables as essential
[19:02] <kees> I don't see those items, should they go in the abstractions bp?
[19:03] <jdstrand>  * dealing with tunables and likewise-open
[19:03] <kees> I'm confused, where is that from?
[19:03] <jdstrand> https://blueprints.edge.launchpad.net/ubuntu/+spec/security-lucid-apparmor-usability
[19:04] <jdstrand> first item
[19:04] <kees> oh! in the description.
[19:04] <kees> erm... it's not in the workitems list.  :P
[19:04] <jdstrand> ah right
[19:04] <jdstrand> I haven't gone through my bps yet
[19:04] <jdstrand> sorry
[19:05] <kees> I would say either move to workitem and leave it as "high", or move it to the catchall-essential.
[19:05] <jdstrand> maybe I will break out tunables to another bp, eg security-lucid-apparmor-tunables
[19:05] <jdstrand> then mark that essential?
[19:05] <kees> that sounds fine to me
[19:06] <jdstrand> seems fine
[19:06] <jdstrand> security-lucid-ubuntu-and-debian seems maybe 'medium', but low is ok if others think that is fine
[19:06] <jdstrand> (it isn't difficult anyway)
[19:07] <mdeslaur> i think low until we find someone from debian who wants to help
[19:07] <kees> it's not difficult, but when compared against other stuff, it seemed like a "low".  if I'm in the minority there, we can raise it, I don't object to "med"
[19:07] <jdstrand> I don't care
[19:07] <jdstrand> :)
[19:07] <kees> low it is.  :)
[19:08] <jdstrand> ok, so that should be it then, no?
[19:08] <kees> yeah, I think we're good.
[19:08] <jdstrand> cool
[19:08] <kees> robbiew: did you already do your "here's what we're doing" report, or is that still pending?
[19:08] <jdstrand> kees: so yeah, enjoy your time off and don't worry about blueprints this week :)
[19:08] <kees> jdstrand: awesome!  :)
[19:09] <robbiew> did it for Foundations only
[19:09] <kees> ok
[19:09] <robbiew> provided a link to mark for security
[19:09]  * kees nods
[19:09] <robbiew> but doubt he's had a chance to look through it today
[19:09] <jdstrand> robbiew: I'll work on the security team ones today
[19:09] <robbiew> cool, thnx
[19:10] <kees> alrighty, thanks guys.  :)
[19:10] <mdeslaur> c ya kees!
[19:11] <jdstrand> o/
[19:11] <kees> \o
[19:47] <Seeker`> #startmeeting
[19:47] <MootBot> Meeting started at 13:47. The chair is Seeker`.
[19:47] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[19:48] <Seeker`> [topic] Test, please work!
[19:48] <MootBot> New Topic:  Test, please work!
[19:48] <Seeker`> #endmeeting
[19:48] <MootBot> Meeting finished at 13:48.
[19:54] <ScottK> Unless someone else was planning on using this channel (it's unscheduled), we'll hold a kubuntu-dev application meeting here in 5 minutes.
[19:56] <st33med> I was going to use it to talk to people about switching to Windows </sarcasm>
[20:00] <Tm_T> st33med: we had that meeting earlier this month I think
[20:00] <JontheEchidna> heh
[20:00] <st33med> Oh, I guess I missed it
[20:01] <st33med> :)
[20:01] <ScottK> \o
[20:01] <st33med> Bill gates will not be happy with me
[20:01] <st33med> >.>
[20:01] <ScottK> #startmeeting
[20:01] <MootBot> Meeting started at 14:01. The chair is ScottK.
[20:01] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[20:02] <ScottK> apachelogger, Riddell, nixternal ?
[20:02] <apachelogger> ahoy ahoy
[20:02] <ScottK> OK.  That's two.  We need three for a quorum.
[20:05] <nixternal> oi
[20:05] <ScottK> JontheEchidna are you here?  That's all we need.
[20:05] <JontheEchidna> yay, 3
[20:05] <JontheEchidna> yup
[20:05] <ScottK> OK.  It's been 5 minutes and we have a quorum, let's stary.
[20:05] <ScottK> JontheEchidna: Where's you're application?
[20:05] <JontheEchidna> https://wiki.kubuntu.org/JonathanThomas/KubuntuDevApplication
[20:06] <ScottK> [LINK] https://wiki.kubuntu.org/JonathanThomas/KubuntuDevApplication
[20:06] <MootBot> LINK received:  https://wiki.kubuntu.org/JonathanThomas/KubuntuDevApplication
[20:06] <ScottK> apachelogger and nixternal: You've reviewed this, right?
[20:06] <apachelogger> aye
[20:06]  * ScottK goes straight to questions ...
[20:06] <Tonio__> hi
[20:06] <JontheEchidna> o/
[20:06] <ScottK> Excellent.  Hello Tonio_.
[20:07] <ScottK> Tonio_: https://wiki.kubuntu.org/JonathanThomas/KubuntuDevApplication
[20:07] <ScottK> JontheEchidna: If you're a kubuntu-dev, you'll have access to Kubuntu's seeds.  Any thoughts on that?  Have you done anything with seed changes?
[20:08] <JontheEchidna> I have done some work with the Kubuntu seeds. let me see if I can find the bzr branch
[20:08] <JontheEchidna> https://code.edge.launchpad.net/~echidnaman/ubuntu-seeds/mykubuntu
[20:08] <JontheEchidna> ^as part of the gtk-qt-engine -> kde-style-qtcurve transition
[20:08] <ScottK> [LINK] https://code.edge.launchpad.net/~echidnaman/ubuntu-seeds/mykubuntu
[20:08] <MootBot> LINK received:  https://code.edge.launchpad.net/~echidnaman/ubuntu-seeds/mykubuntu
[20:09] <ScottK> OK.
[20:09] <nixternal> JontheEchidna: how closely are you working with Debian with the KDE packages? Are you contributing directly back to Debian in such cases?
[20:10] <JontheEchidna> In all honesty, working with Debian is not a strong point for me. I do, however, work with the Debian maintainer of the konq-plugins package
[20:10] <JontheEchidna> we subscribe to the feeds to each others' vcs-es for the packaging
[20:10] <ScottK> JontheEchidna: After your seed change gets applied, how to you get the metapackage change in the archive?
[20:11] <JontheEchidna> Hmm.. let me see if I can remember
[20:12]  * Tonio_ has an improvised network meeting... grrrrrrr... brb
[20:12] <JontheEchidna> I know Tonio sponsored a lot of my packages during the transition
[20:12] <ScottK> JontheEchidna: It isn't essential.  If you don't know, that's fine.
[20:13] <JontheEchidna> Yeah, Tonio sponsored the changes I believe
[20:13] <ScottK> JontheEchidna: What should we be doing differently.  We advertised kubunut-dev has having a voice in technical direction of Kubuntu.  What would you change?
[20:13] <JontheEchidna> If more developers would look at the bug tracker more often, then that would be great.
[20:14] <JontheEchidna> Sometimes I feel that bugs fall by the wayside because nobody ever looks at them
[20:14] <JontheEchidna> I know we have a limited pool of resources, but it gets frustrating at times
[20:14] <rgreening> JontheEchidna: Do you have a proposal to make bug triage, solving more accessible for new entrants?
[20:14]  * ScottK nods.
[20:14] <rgreening> :)
[20:15] <JontheEchidna> hmm
[20:15] <ScottK> I don't have any more questions.
[20:15] <JontheEchidna> well in general it's not so much the triage, but what happens (or doesn't) after that
[20:16] <nixternal> JontheEchidna: speaking of bugs, when you upload a new package, do you see if the new upload may close already open bugs? I think many developers not doing this, is the reason for so many stale bugs that may no longer be an issue
[20:16] <JontheEchidna> Yeah, as one of the primary bug triagers I keep a close eye on bugs that new uploads release
[20:17] <JontheEchidna> since I wear both developer and bug triager hats
[20:17] <nixternal> JontheEchidna: do you test every package for regressions prior to uploading? if so, what kind of process do you go through when testing?
[20:18] <JontheEchidna> After I pbuild the package I install it to make sure it installs fine, then do simple stuff with the application
[20:18]  * nixternal appologizes for not endorsing, I am bad at that for some reason
[20:18] <ScottK> nixternal: It's OK.  There's more tension if not everyone with a vote has pre-endorsed the application.
[20:18] <nixternal> true, that means I can play bad cop then :p
[20:18] <ScottK> Tonio_ or apachelogger: Questions?
[20:19] <apachelogger> nothing here
[20:19] <Tonio_> ScottK: not for me...
[20:19] <ScottK> nixternal: Any more from you?
[20:19] <apachelogger> nixternal is bad cop so must have some more bad cop questions
[20:19] <apachelogger> :D
[20:19] <nixternal> JontheEchidna: ScottK stated in the areas of imporvement -> "As with anyone, he could sometimes stand to be a bit more careful..." what are you doing now to be more careful that you might not have previously?
[20:19] <nixternal> of course I always have questions
[20:20] <nixternal> you get good at this stuff after doing membership stuff for more than 2 years in the development arena :)
[20:20] <nixternal> plus dholbach and persia` aren't around, so they can't beat me to a question :)
[20:20] <JontheEchidna> for the example here: http://bazaar.launchpad.net/~kubuntu-members/kdelibs/ubuntu/revision/130
[20:20] <apachelogger> nixternal: lol
[20:20] <nixternal> JontheEchidna: what text editor do you use?
[20:21] <JontheEchidna> I could have paid more attention to what debuild was saying
[20:21] <nixternal> I know with vim, it will highlight mistakes like that in the changelog
[20:21] <JontheEchidna> nixternal: nano
[20:21] <apachelogger> Oo
[20:21]  * nixternal giggles a bit
[20:21] <apachelogger> that just made me shiver
[20:21] <apachelogger> oh my
[20:21] <ScottK> You totally should not have admitted that until after we voted.
[20:21] <nixternal> emacs has the mistake highlighting as well
[20:21] <JontheEchidna> ha
[20:21] <nixternal> ScottK: haha, I was thinking the same exact thing
[20:21]  * apachelogger needs to become bad cop now
[20:21] <nixternal> hahahaha
[20:21]  * nixternal hands the club over to apachelogger...get to beatin'!
[20:22]  * apachelogger is not going to tell the story about MS engineer praising emacs now
[20:22]  * rgreening will miss the Kubuntu icon.. 
[20:22] <apachelogger> I think we should get to a vote before everyone realises that JontheEchidna uses nano :P
[20:22] <ScottK> OK, any more questions before we vote?
[20:22] <nixternal> none here
[20:22] <nixternal> nano here rather :p
[20:22] <JontheEchidna> lol
[20:22]  * apachelogger actually read nano :P
[20:22] <ScottK> [VOTE] JontheEchidna for kubuntu-dev (please only vote if you're in kubuntu-dev)
[20:22] <MootBot> Please vote on:  JontheEchidna for kubuntu-dev (please only vote if you're in kubuntu-dev).
[20:22] <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
[20:22] <MootBot> E.g. /msg MootBot +1 #ubuntu-meeting
[20:23] <nixternal> +1
[20:23] <MootBot> +1 received from nixternal. 1 for, 0 against. 0 have abstained. Count is now 1
[20:23] <apachelogger> MootBot: +1
[20:23] <ScottK> +1
[20:23] <MootBot> +1 received from ScottK. 2 for, 0 against. 0 have abstained. Count is now 2
[20:23] <apachelogger> +1
[20:23] <MootBot> +1 received from apachelogger. 3 for, 0 against. 0 have abstained. Count is now 3
[20:23]  * ScottK looks at Tonio_
[20:24] <Tonio_> +1 :)
[20:24] <MootBot> +1 received from Tonio_. 4 for, 0 against. 0 have abstained. Count is now 4
[20:24] <Tonio_> of course
[20:24] <JontheEchidna> :)
[20:24]  * apachelogger is wondering why we vote anyway :P
[20:24] <ScottK> [ENDVOTE]
[20:24] <MootBot> Final result is 4 for, 0 against. 0 abstained. Total: 4
[20:24] <nixternal> woo, congrats JontheEchidna \o/
[20:24] <apachelogger> congrats JontheEchidna
[20:24] <JontheEchidna> \o/
[20:24] <ScottK> JontheEchidna: Congratulations.
[20:24] <Mamarok> Congratulations, JontheEchidna!
[20:24] <JontheEchidna> Thanks
[20:24] <jussi01> congrats JontheEchidna
[20:24] <rgreening> gratz
[20:24] <nixternal> any other business?
[20:25]  * JontheEchidna edits his next changelog in notepad.exe
[20:25] <nixternal> hahaha
[20:25] <rgreening> ouch
[20:25] <nixternal> vi vi vi
[20:25] <rgreening> wine notepad.exe
[20:25] <nixternal> the sign of the devil!
[20:25] <JontheEchidna> haha
[20:25] <apachelogger> JontheEchidna: that is going to get you into newline hell
[20:25] <JontheEchidna> I kid :P
[20:25]  * apachelogger reports bug about nano
[20:25] <nixternal> ScottK: you gonna send out the email to all of the lists?
[20:25] <ScottK> [ENDMEETING]
[20:26] <ScottK> nixternal: Sure.
[20:26] <JontheEchidna> ScottK: thanks a lot for organizing everything
[20:26] <nixternal> kubuntu-devel, ubuntu-devel, CC, TB, with a cc: sabdfl
[20:26] <rgreening> thanks ScottK :)
[20:26] <nixternal> oh, ScottK and ubuntu-news :)
[20:26] <apachelogger> cookies to ScottK!
[20:26]  * nixternal gets the dog from outside before it freezes
[20:27] <ScottK> #endmeeting
[20:27] <MootBot> Meeting finished at 14:26.