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