[18:03] <jdstrand> hi!
[18:03] <mdeslaur> \o
[18:03] <mdeslaur> o/
[18:03] <mdeslaur> \o
[18:04] <jdstrand> mdeslaur is eager to start, clearly :)
[18:04] <jdstrand> #startmeeting
[18:04] <meetingology> Meeting started Mon Oct  1 18:04:29 2012 UTC.  The chair is jdstrand. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[18:04] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[18:04] <jdstrand> [LINK] https://wiki.ubuntu.com/SecurityTeam/Meeting
[18:04] <jdstrand> [TOPIC] Weekly stand-up report
[18:04] <jdstrand> I'll go first
[18:05] <jdstrand> I'm in the happy place this week
[18:05] <jdstrand> I've been working on some lightdm apparmor fixes this morning for 12.10, and am almost done
[18:05] <jdstrand> I've got some pending updates that I am working on
[18:05] <jdstrand> that's it from me
[18:06] <jdstrand> mdeslaur: you're up
[18:06] <mdeslaur> I just released software-properties updates
[18:06] <mdeslaur> and I have qemu-kvm and devscripts updates to test
[18:06] <mdeslaur> I'm on triage this week
[18:06] <mdeslaur> and I'm on community too
[18:06] <mdeslaur> wednesday, I have patch piloting
[18:06] <mdeslaur> and after that, I'll pick something else to poke at
[18:07] <mdeslaur> that's it for me
[18:07] <mdeslaur> sbeattie: you're up
[18:07] <sbeattie> I'm finally finishing up glibc testing, that will go out later today
[18:07] <sbeattie> After that, I'm moving on to apparmor stuff
[18:08] <sbeattie> will pick up jjohansen's coredump testcase patch for quantal
[18:08] <sbeattie> that's pretty much it for me.
[18:08] <sbeattie> tyhicks: you're up (since micahg's off)
[18:09] <tyhicks> I have a libgssglue update to test and publish
[18:09] <tyhicks> I also need to attach a fix to the openssl bug I opened a couple weeks ago
[18:09] <tyhicks> It isn't getting any attention upstream
[18:09] <tyhicks> But there's two plausible, simple fixes for it
[18:10]  * tyhicks will be sure to have that ready by at least mdeslaur's patch piloting on wednesday
[18:10] <mdeslaur> hrm :P
[18:10] <tyhicks> Then I'll be starting on apparmor stuff when I get the green light from jjohansen
[18:10] <tyhicks> mdeslaur: you're welcome ;)
[18:10] <tyhicks> jjohansen: that's it, you're up
[18:10] <jdstrand> heh
[18:10] <jjohansen> tyhicks: green light
[18:11] <tyhicks> oh, nice! :)
[18:11] <jjohansen> So I am dumping some docs, on tyhicks and sbeattie
[18:11] <jjohansen> and getting them moving on some apparmor items
[18:12] <jjohansen> I still have some fixing of the dbus parser patch so it works with 2.8 that I a plan to finish up today
[18:12] <jjohansen> I have a yama qrt failure to finish looking into
[18:12] <jjohansen> and more apparmor debugging
[18:13] <jjohansen> of the kernel.
[18:13] <jjohansen> I also need to push the current set of bug fixes upstream for 3.7 release window
[18:14] <jjohansen> sarnold: your up
[18:15] <jjohansen> oh and I guess this is a short week for me I am off friday
[18:15] <sarnold> I think I've got my buildenvironment and testenvironment all built; this week we'll find what I missed and hopefully get around to fixing some packages. :)
[18:15] <sarnold> I'm also going to be paying attention to the community role, woo.
[18:15] <sarnold> jdstrand: you're up
[18:17] <jdstrand> [TOPIC] Highlighted packages
[18:17] <jdstrand> The Ubuntu Security team will highlight some community-supported packages that might be good candidates for updating and or triaging. If you would like to help Ubuntu and not sure where to start, this is a great way to do so.
[18:17] <jdstrand> See https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures for details and if you have any questions, feel free to ask in #ubuntu-security. To find out other ways of helping out, please see https://wiki.ubuntu.com/SecurityTeam/GettingInvolved.
[18:17] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/smsclient.html
[18:17] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/libyaml-libyaml-perl.html
[18:17] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/libdbd-pg-perl.html
[18:17] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/mcrypt.html
[18:17] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/otrs2.html
[18:17] <jdstrand> [TOPIC] Miscellaneous and Questions
[18:17] <jdstrand> There are a lot of merge opportunities for packages listed in http://people.canonical.com/~ubuntu-security/d2u/. Performing these updates is a great way to help Ubuntu and bolster your developer application.
[18:18] <jdstrand> mdeslaur (or possibly jjohansen): I see some 'high' kernel CVEs. what is the status of those?
[18:18] <jjohansen> jdstrand: oh, hrmm I haven't checked this morning yet
[18:19] <mdeslaur> jjohansen: it's been at high for a while now
[18:19] <mdeslaur> CVE-2012-3520
[18:21] <mdeslaur> it's in the -proposed kernel, so should be out soon
[18:21] <mdeslaur> jdstrand: ^
[18:21] <jjohansen> jdstrand, mdeslaur: yep
[18:22] <jdstrand> mdeslaur: awesome, thanks
[18:22] <jdstrand> Does anyone have any other questions or items to discuss?
[18:23] <sarnold> jdstrand: wrt the lightdm, one of our users was looking for a way to allow the guest profile to launch chromium-browser but not have the lightdm profile itself known about all the exceptions to its profile
[18:24] <sarnold> jdstrand: this seemed like a reasonable idea to me, I've got a feeling that an #include <lightdm.d> may be useful for handling future cases similar to chromium-browser
[18:24] <sarnold> s/itself known/itself know/
[18:25] <jdstrand> sarnold: yeah-- I saw the bug. I am doing something similar
[18:26] <jdstrand> lightdm.d would be good, but I'd like to get upstream consensus on our .d directories. in the meantime, I have split out all of the lightdm rules into abstractions/lightdm. the guest and remote sessions can use that
[18:26] <sarnold> jdstrand: cool :) (he wanted to pick up a bug he thought he could handle, but the nuances of named profile transitions are subtle enough that I think it makes sense for you to work on that one full-speed-ahead. But I did like his idea of isolating exceptions in their own pile of included files.
[18:26] <jdstrand> cause right now the freerdp and uccsconfigure profiles are profile copies
[18:27] <jdstrand> then I am adding a separate lightdm_chromium-browser abstraction that will itself include the lightdm abstraction
[18:27] <jdstrand> bug it will have the additional rules to get chromium running
[18:27] <sarnold> aha, that sounds good. :) Thanks
[18:28] <jdstrand> so we achieve the same. if we need another special-cased profile, then we can add the lightdm.d dir
[18:32] <jdstrand> #endmeeting
[18:32] <meetingology> Meeting ended Mon Oct  1 18:32:52 2012 UTC.
[18:32] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-10-01-18.04.moin.txt
[18:32] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-10-01-18.04.html
[18:33] <sbeattie> jdstrand: thanks!
[18:33] <jdstrand> mdeslaur, sbeattie, tyhicks, jjohansen, sarnold: thanks!
[18:33] <mdeslaur> thanks jdstrand!
[18:33] <sarnold> thanks jdstrand :)
[18:33] <jjohansen> jdstrand: thanks
[19:55] <kees> \o
[19:56]  * stgraber waves
[19:56] <bryceh> hiho
[19:57] <pitti> bonne nuit mes amis
[19:57] <cjwatson> Hi
[19:58] <cjwatson> Do we have a non-trivial agenda?
[19:58] <pitti> "New/MIR processing for new nvidia-experimental-NNN packages: bryce
[19:58] <pitti> ["
[19:58] <pitti> AFAICS
[19:59] <pitti> (at first sight that sounds more like an operational problem though rather than policy)
[19:59] <bryceh> (it's a small point of clarification needed from last week's discussion, hopefully quick)
[20:00] <kees> pitti: you can't trick me! you're not french! :)
[20:01] <pitti> kees: j'apprends le français maintenant
[20:01] <pitti> kees: c'est la faute de seb128 et duolingo.com :)
[20:01] <kees> haha
[20:02] <mdz> hi
[20:02] <pitti> who's chairing today? cjwatson chaired last time, so kees now?
[20:02] <pitti> hey mdz
[20:02] <kees> sure, I'm happy to do it.
[20:02] <kees> #startmeeting
[20:02] <meetingology> Meeting started Mon Oct  1 20:02:25 2012 UTC.  The chair is kees. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[20:02] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[20:02] <kees> looks like no action review
[20:02] <kees> so, let's move right along...
[20:03] <kees> [topic] New/MIR processing for new nvidia-experimental-NNN packages: bryce
[20:03] <cjwatson> There was one action but I did it
[20:03] <cjwatson> (Followed up to the lists)
[20:03] <bryceh> thanks again for the new policy regarding the experimental drivers.
[20:03] <kees> cool, saw that just now.
[20:03] <kees> bryceh: sure! seems like a good plan.
[20:04] <bryceh> the issue is that I think there was some uncertainty by reviewers on what that means, so in practice it has not been speeding things up very much.
[20:04] <cjwatson> Have you actually had pushback, or is it just that all the reviewers are busy?
[20:04] <pitti> new processing seems to be rather simple to me, I guess these drivers look all alike?
[20:04] <bryceh> but the specific issue I need help with is when we get a new beta driver, it needs to go through several steps:  New review, MIR, then SRU
[20:04] <cjwatson> There's enough overlap between -sru and -release that release timing can cause issues
[20:05] <pitti> I don't see much purpose in an explicit MIR
[20:05] <bryceh> what i'm finding is that while each review is quick, it can take several days to catch someone's attention and do the review.
[20:05] <pitti> we don't usually do that for other cases either (libfoo2 vs. libfoo3 or so)
[20:05] <bryceh> cjwatson, busy/vacation/offline yeah
[20:05]  * soren stumbles in
[20:05] <soren> Sorry I'm late.
[20:06] <pitti> I had expected the cycle to be "upload to -proposed queue" and u-sru NEWs it into -restricted
[20:06] <pitti> hey soren
[20:06] <bryceh> anyway, currently it appears I need to go to three separate individuals to do the review steps.  It would be nice if one person (the SRU admin, ala RAOF) could handle all approvals in one go.
[20:07] <cjwatson> So, RAOF has technical access to do both NEW and SRU (normally he'd only process the UNAPPROVED queue, but there's nothing actually stopping him from doing NEW for a stable series and in this case it seems reasonable)
[20:07] <cjwatson> I think then all we would need to do is agree that he has a class-action MIR?
[20:08] <kees> seems fine to me. I think that was the original intent, yes?
[20:08] <cjwatson> i.e. that the "main" (well, restricted) review for the mainline nvidia/fglrx drivers covers these variants too
[20:08] <cjwatson> Does the package need to go into the development series as well as part of this?
[20:09] <bryceh> cjwatson, yes we will always have the development series updated too.
[20:09] <kees> good, yeah. I would have expected that to be happening.
[20:09] <bryceh> although technically they're probably orthogonal since we move them back to nvidia-current on upgrade
[20:09] <bryceh> er, move people back
[20:10] <cjwatson> That's a problem because in general -sru does not have any queue admin access to the development series
[20:10] <cjwatson> If the person you were dealing with were in -archive then this wouldn't be a problem though
[20:10] <cjwatson> And actually RAOF is - not fully trained I think but he's expressed an interest in that and it's just waiting for me to get round to it
[20:10] <cjwatson> If I'm thinking of the right person
[20:11] <pitti> but I guess the time-sensitive part is actually precise-proposed?
[20:11] <stgraber> having RAOF do both the AA work for the current dev release and the SRU review would make sense as he's probably the one person who's the most clue about the package anyway
[20:11] <bryceh> pitti, that's correct
[20:11] <pitti> i. e. if the equivalent dev release NEWing takes some days longer, that's not a big deal?
[20:12] <bryceh> having it in quantal is really only important in order to proceed with doing the SRU
[20:12] <pitti> if it helps archive/SRU folks, I wouldn't mind to extend the MRE with some verbiage about delegating the SRU NEWing for nvidia-* to ubuntu-sru
[20:12] <bryceh> pitti, yeah, if we could do the precise-proposed and quantal as two separate processes then if getting it into quantal takes a while longer, that'd be ok
[20:13] <pitti> we've had wholly new drivers SRUed without any dev release counterpart
[20:13] <cjwatson> I think NEW authorisation where necessary for SRUs is implicit in the general delegation to -sru
[20:13] <cjwatson> Personally
[20:14] <pitti> it doesn't happen often (fortunately!), so I guess there's some uncertainty involved
[20:15] <bryceh> ok, thanks, yes it may be just that it needed some extra clarification what was permitted.  thanks
[20:16] <kees> do we have a specific action to take out of this? update documentation?
[20:17] <bryceh> kees, I have been documenting the process at https://wiki.ubuntu.com/X/DriverUpdates and will make sure it's clearly stated and referenced on that page
[20:17] <kees> bryceh: okay, that sounds good to me.
[20:18] <cjwatson> Yep, we don't seem to have any dissent here
[20:19] <kees> bryceh: did this cover everything for you?
[20:19] <bryceh> kees, yes thank you!
[20:19] <kees> cool
[20:19] <kees> [topic] Scan the mailing list archive for anything we missed (standing item)
[20:20] <kees> I don't see anything outstanding on the list. anyone see anything I'm not?
[20:20] <pitti> neither do I
[20:20] <soren> Nope.
[20:21] <stgraber> nope
[20:21] <kees> [topic] Check up on community bugs (standing item)
[20:21] <pitti> I changed my mutt config to show  TB mail in a different color now, and nothing jumps at me :)
[20:21] <kees> we have https://bugs.launchpad.net/ubuntu-community/+bug/174375 still showing, but it looks like we should unassign TB from it, based on discussion.
[20:22] <kees> (or mark it fix-released)
[20:22] <kees> what do others think?
[20:23] <pitti> I'd close it now
[20:24] <pitti> if there are specific issues left, they should get more focussed bugs
[20:24] <cjwatson> Yeah, let's close it.  We don't gain much from it at this point.
[20:24] <kees> done.
[20:24] <pitti> but "may need redesign" sounds like a dead horse now
[20:24] <kees> [topic] Other business
[20:24] <kees> anything else we need to go over before picking the next chair?
[20:24] <cjwatson> As a point of reference, ~ubuntu-release now has queue admin access and still contains ~ubuntu-release-nominators (though that was mostly oversight), and to the best of my knowledge there's been zero abuse.
[20:24] <pitti> "There are currently no open bugs." \o/
[20:24] <cjwatson> Probably because it's not exactly something you can run into by accident.
[20:24] <kees> pitti: :)
[20:25] <cjwatson> (And if we cared, we could invert the team structure as I suggested, but I don't think I really care.)
[20:26] <kees> [topic] Select a chair for the next meeting
[20:26] <kees> okay, who's next?
[20:26] <pitti> that would be me, I think
[20:26] <soren> I won't be able to make it.
[20:26] <kees> mdz, no?
[20:26] <pitti> Oct 15 sounds ok
[20:26] <stgraber> yeah, as long as there's no abuse, status quo is fine. I'd still love to have that audit trail implemented though :)
[20:27] <mdz> I'm available October 15th I think
[20:27] <pitti> I'm going in the order at https://launchpad.net/~techboard/+members
[20:27] <kees> ah!
[20:27] <pitti> but I don't mind much
[20:27] <mdz> but pitti's suggestion is fine too ;-)
[20:27] <pitti> I'm just less sure about Oct 29, with UDS and such
[20:27] <cjwatson> Oct 15 is fine by me
[20:27] <kees> okay, we'll do first-name then, not nick. pitti it is
[20:27] <mdz> oct 29 is no problem for me
[20:28] <cjwatson> Oct 29 will be, er, either 2200 or 2300 at UDS (haven't looked up DST)
[20:28] <pitti> welcome to my world :)
[20:28] <cjwatson> Which I doubt I can make
[20:28] <pitti> 2200
[20:28] <cjwatson> (My family will be with me so I don't think I'll be doing lots of late-night hacking)
[20:28] <pitti> assuming that we readjust back to winter time
[20:29] <stgraber> yeah, the UDS meeting seems rather unlikely to happen as we'll likely be busy with other things
[20:29] <kees> nice and quick meeting, just under 30 min. :)
[20:29] <kees> #endmeeting
[20:29] <meetingology> Meeting ended Mon Oct  1 20:29:46 2012 UTC.
[20:29] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-10-01-20.02.moin.txt
[20:29] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-10-01-20.02.html
[20:30] <pitti> merci kees, à demain!
[20:30] <kees> hehe