[18:02] <jdstrand> hi!
[18:02] <mdeslaur> \o
[18:02] <mdeslaur> o/
[18:02] <mdeslaur> \o
[18:02] <mdeslaur> o/
[18:02] <jdstrand> #startmeeting
[18:02] <meetingology> Meeting started Mon Jul 23 18:02:29 2012 UTC.  The chair is jdstrand. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[18: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
[18:02] <jdstrand> The meeting agenda can be found at:
[18:02] <jdstrand> [LINK] https://wiki.ubuntu.com/SecurityTeam/Meeting
[18:02] <jdstrand> [TOPIC] Weekly stand-up report
[18:02] <jdstrand> I'll go first
[18:03] <jdstrand> I will actually not have a short week this week :)
[18:03] <jdstrand> I'm on communuity
[18:03] <jdstrand> am patch piloting today
[18:03] <jdstrand> have some pending updates
[18:03] <jdstrand> and will be reviewing webkit maintenance a bit
[18:03] <jdstrand> mdeslaur: you're up
[18:04] <mdeslaur> I'm in the happy place this week
[18:04] <mdeslaur> I've got a libexif update coming out in a few minutes
[18:04] <mdeslaur> and have an embargoed issue (or two) that I need to work on this week
[18:04] <mdeslaur> and I've worked on "uvt", the python replacement for vmtools
[18:04] <sbeattie> \o/
[18:04] <mdeslaur> I still have a couple of commands to implement before marking off the work item
[18:05] <mdeslaur> I should be done with them today or tomorrow
[18:05] <mdeslaur> and after that, I'll pick some CVEs in the list
[18:05] <mdeslaur> we have a _lot_ of open CVEs, so we need to be picking stuff up
[18:05] <mdeslaur> that's it from me
[18:05] <mdeslaur> sbeattie: you're up
[18:05] <sbeattie> I'm in the happy place this week
[18:06] <sbeattie> I've currently working on an embargoed issue
[18:06] <sbeattie> I'm also poking at a possible regression from the openjdk backports I did around JNI in lucid (LP: #1027122)
[18:07] <sbeattie> jjohansen handed me what he had for dbus/apparmor, so I'll be poking at that as well
[18:07] <sbeattie> otherwise, I'll try to pick up a CVE or two as well
[18:08] <sbeattie> that's all I've got; micahg, you're up
[18:09] <micahg> This week I'm starting the staged rollout of webkit updates to the stable releases, tomorrow, precise-proposed will get 1.8.1 and if there aren't any significant increases in crashes, I'll push that to everyone late Thursday (or Monday if people think that's better)
[18:09] <jdstrand> \o/
[18:09] <micahg> with the rest of the releases hopefully getting to their respective -proposed repo by the end of next week
[18:10]  * jdstrand guesses monday would be best. it is already late so don't cause potential extra work over the weekend
[18:10] <micahg> ok
[18:12] <micahg> that's basically it aside from watching for any issues with the Mozilla updates (have been skimming the bugmail to notify tyhicks if need be), all seems fine
[18:12] <jdstrand> tyhicks: you're up
[18:13] <micahg> oh, right, and trying to process all the mail about thunderbird's future, I hope to have something drafted over the next week or 2
[18:13] <micahg> jdstrand: he's off today :)
[18:13] <jdstrand> ah
[18:13] <jdstrand> jjohansen: you're up
[18:13] <jdstrand> tyhicks: nm
[18:13] <jdstrand> bzr diff
[18:13] <jdstrand> meh
[18:14] <jjohansen> so I need to finish getting dbus stuff to sbeattie, I actually didn't give him the kernel bits yet, and the parser bits don't apply (though I may let him have a crack at fixing that)
[18:15] <jjohansen> I have some more kernel QRT fallout to look at this week, not sure what it is yet just saw the request (/me is suspecting more arm failures)
[18:16]  * jjohansen needs to finish up on the rcu locking rework to fix deadlocking issues in the current apparmor patchset so I can push those out to the list
[18:17] <jdstrand> jjohansen: is that due to upstream churn?
[18:18]  * jdstrand assumes so
[18:18] <jjohansen> jdstrand: no, its due to us doing more and being forced to do GFP_KERNEL allocations indirectly in places where locks are held.  This can cause sleeping at those points but with the way our locking works and the LSM hooks this effectively blocks all execs and several other operations causing system deadlocks
[18:19] <jdstrand> jjohansen: oh, so this affects current kernels?
[18:19] <jjohansen> jdstrand: no just the dev stuff
[18:19] <jdstrand> jjohansen: part of getting rid of the compat work?
[18:20] <jjohansen> jdstrand: not just the compat, its needed for stacking and labeling too
[18:20] <jdstrand> ok
[18:20] <jdstrand> jjohansen: anything else?
[18:20] <jjohansen> basically an extra prereq
[18:21] <jjohansen> hrmm well I plan to review the R stuff floated on the list
[18:21] <jjohansen> oh and I have some 3.5 testing
[18:22]  * jjohansen pushed the compat patches for 3.5 but hasn't actually built or tested against upstream 3.5
[18:22] <jjohansen> but that is minor
[18:22] <jjohansen> jdstrand: thats it back to you
[18:22] <jdstrand> thanks
[18:22] <jdstrand> [TOPIC] Highlighted packages
[18:22] <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:22] <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:22] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/nusoap.html
[18:23] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/phppgadmin.html
[18:23] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/libfile-temp-perl.html
[18:23] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/mplayer2.html
[18:23] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/tangerine.html
[18:24] <jdstrand> [TOPIC] Miscellaneous and Questions
[18:24] <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:24] <jdstrand> Does anyone have any other questions or items to discuss?
[18:32] <jdstrand> mdeslaur, sbeattie, micahg, jjohansen: thanks
[18:32] <jdstrand> #endmeeting
[18:32] <meetingology> Meeting ended Mon Jul 23 18:32:58 2012 UTC.
[18:32] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-07-23-18.02.moin.txt
[18:32] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-07-23-18.02.html
[18:33] <jjohansen> thanks jdstrand
[18:33] <mdeslaur> thanks jdstrand
[18:33] <micahg> thanks jdstrand
[18:33] <sbeattie> thanks
[20:59]  * kees waves
[20:59]  * stgraber waves
[21:11]  * kees looks around for mdz
[21:13] <mdz> sorry, I thought I was in -meeting but I was only in -devel
[21:13] <mdz> who's here for TB?
[21:13] <kees> o/
[21:13]  * stgraber waves
[21:14] <mdz> #startmeeting
[21:14] <meetingology> Meeting started Mon Jul 23 21:14:27 2012 UTC.  The chair is mdz. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[21:14] <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
[21:14] <mdz> #link https://wiki.ubuntu.com/TechnicalBoardAgenda
[21:14] <mdz> https://wiki.ubuntu.com/TechnicalBoardAgenda
[21:14] <mdz> #topic Action review
[21:14] <mdz> soren to continue brainstorm review
[21:15] <mdz> I have no idea about this and soren doesn't seem to be around. anyone know?
[21:15] <mdz> kees to ping LP advocate about LP: #252368
[21:15] <kees> soren's task: I haven't seen any email about it, so I assume it's continuing
[21:15] <kees> I've asked, and it's in limbo.
[21:15] <kees> there doesn't seem to be a sensible way to unlimbo it, either.
[21:15] <kees> already advocated bugs aren't seeing any attention, so it's unlikely this one will either.
[21:16] <mdz> so you asked the advocate about it, and they said there's nothing they can do?
[21:16] <kees> basically, yes.
[21:16] <mdz> that sounds...less than ideal
[21:17] <mdz> is there an escalation path?
[21:17] <kees> the LP team says that to fix bugs, people should do it themselves.
[21:17] <kees> that's not clear.
[21:17] <kees> I'll continue the discussion.
[21:18] <mdz> I could raise it with debian-derivatives
[21:18] <kees> that might work too
[21:18] <mdz> I'm not sure what the barrier to entry is like these days for LP development
[21:18] <mdz> but this sounds pretty non-trivial to implement
[21:18] <kees> yeah
[21:18] <kees> sounds like LP development has stopped?
[21:19] <kees> even the stakeholders don't know where to escalate to.
[21:19] <mdz> I'll send an email about it
[21:19] <mdz> but it sounds like there's no next action for this particular bug
[21:19] <stgraber> yeah, LP is in maintenance-only mode... any feature work should be done outside of the LP team, though one LP squad is usually available for code reviews and helping people contribute
[21:19] <Daviey> Is this really a pressing matter ?
[21:20] <mdz> kees, can you put a comment on the bug with the latest update?
[21:20] <kees> sure
[21:20] <mdz> Daviey, it is pressing enough to warrant some action within 4 years :-)
[21:20] <mdz> its 4th anniversary is coming up
[21:20] <Daviey> It seems to me that the barrier of creating a LP account is so low, that the bother to implement this is crazy use of resources.
[21:21] <mdz> Daviey, that would be a reasonable position for the Launchpad project to take
[21:21] <mdz> and if they took that position, I think we would probably accept it
[21:21] <mdz> but that's a different thing from just letting the request sit
[21:22] <mdz> anyway, moving on
[21:22] <Daviey> right
[21:22] <mdz> #topic Mythbuntu LTS
[21:22] <mdz> it looks like this got three +1s on the mailing list
[21:22] <mdz> and no opposition
[21:22] <Daviey> flacoste,mrevell or cztab is probably the escalation path,
[21:22] <mdz> so I think it's done
[21:23] <mdz> I'm not sure who put it on the agenda
[21:23] <mdz> I think it just needs a rubber stamp
[21:23] <czajkowski> Daviey: sup
[21:23] <mdz> unless anyone disagrees, I'll follow up to the mailing list and stamp it
[21:23] <mdz> czajkowski, do you have a highlight for cztab? :-)
[21:23] <mdz> kees, stgraber, you OK with that?
[21:24] <czajkowski> mdz: oddly enough I do :)
[21:24] <stgraber> mdz: I'm fine with that
[21:24] <mdz> ok
[21:24] <mdz> #topic MRE request for VLC (bdrung)
[21:25] <mdz> bdrung, hi
[21:25] <kees> (/me is fine too)
[21:25] <ScottK> Daviey: When it's come up, it was important to a number of DD's.  It's socially important in our relationships with our primary upstream.  Technically less so.
[21:25] <ScottK> (sorry, missed the discussion earlier)
[21:26] <mdz> bdrung, are you there?
[21:26] <mdz> we'll skip ahead
[21:26] <mdz> #topic Mesa provisional MRE
[21:26] <mdz> #link https://lists.ubuntu.com/archives/technical-board/2012-July/001352.html
[21:27] <mdz> this is from RAOF
[21:27] <bdrung> mdz: hi
[21:27] <mdz> bdrung, hi, we'll come back to your topic in a moment
[21:28] <mdz> kees, stgraber, thoughts on the Mesa request?
[21:28] <kees> if piglet can get run on several HW types, I'd be happy with the MRE
[21:28] <kees> (run and pass, that is)
[21:28] <stgraber> quickly reading the e-mail again, I remember thinking it was a reasonable testing plan
[21:29] <mdz> yes, I think the important thing is that the regression test suite passes, and running it in the proper environment (where that's not the buildd) is a no-brainer
[21:29] <mdz> OK, I'll follow up and ack it
[21:30] <mdz> #topic  MRE request for VLC (bdrung)
[21:30] <stgraber> right, +1 from me with the plan that the regression test runs on all the hardware combination in the lab
[21:30] <mdz> bdrung, go ahead
[21:30] <bdrung> VLC has a maintenance branch (currently 2.0.x) where they mainly apply bug fixes
[21:31] <bdrung> i like to get a MRE that allows getting new 2.0.x versions into precise
[21:32] <mdz> bdrung, what's the regression testing story?
[21:32] <bdrung> the 2.0.2 release closes 9 Launchpad bugs and many more bugs that were not reported on Launchpad
[21:32] <kees> wow, 9.
[21:33] <bdrung> kees: IIRC the 1.1.0 release held the record
[21:33] <kees> I bet :)
[21:34] <bdrung> mdz: the good story: we have a daily PPA for the upstream maintenance branch
[21:34] <bdrung> the bad story: the package has a test suite that is currently not run on compile time (it succeeds locally, but one test fails in the chroot)
[21:35] <bdrung> the test suite is very small and does not cover much of the program
[21:35] <kees> can that test be removed from the suite for the builds? it would be nice to have those tests work in the build
[21:35] <kees> oh
[21:35] <mdz> is the failure a regression, or has it failed before?
[21:35] <mdz> ah
[21:35] <mdz> so the test suite is not very relevant
[21:36] <mdz> bdrung, you mentioned the branch includes "mainly" bug fixes...how "mainly"? :-)
[21:36] <mdz> an MRE would usually imply that their policy is at least as strict as ours
[21:37] <bdrung> upstream makes sure that they keep their ABI stable in their maintenance branch
[21:38] <bdrung> they apply bug fixes, update translations, add new translations
[21:39] <kees> that seems fine
[21:39] <mdz> yes
[21:39] <bdrung> their NEWS files only states fixes
[21:39] <mdz> bdrung, has it been SRUd many times before?
[21:40] <bdrung> the updated libraries and Mac OS changes are irrelevant for us
[21:40] <bdrung> mdz: at least once
[21:40] <mdz> what's the rationale for a standing exception, as opposed to just doing an SRU for 2.0.2?
[21:41] <bdrung> the maintenance branch get security fixes too and it will fix more bugs
[21:42] <kees> seems like a win to me. have there been reports of regressions in past SRUs?
[21:42] <bdrung> i like to get all 2.0.x releases into precise to have a version with no security hole and less bugs
[21:43] <bdrung> kees: i can't remember a regression
[21:43] <mdz> without a regression testing plan/suite, there is certainly a higher risk of regressions
[21:43] <mdz> but the impact of a regression in vlc is smaller than in many other packages
[21:43] <mdz> such as, say, Mesa :-)
[21:43] <kees> right
[21:43] <bdrung> oh wait. there was a pulseaudio output plugin change that causes some trouble
[21:44] <bdrung> this change revealed some pulseaudio/driver bugs IIRC
[21:44] <mdz> were we able to fix the regression promptly?
[21:45] <mdz> or did we have to roll back the whole thing?
[21:46] <bdrung> i think it was bug #805807
[21:48] <mdz> that looks like it's...still open in natty?
[21:48] <mdz> did we regress it and then not fix  the regression?
[21:49] <bdrung> no, it was an upstream regression from one release to another.
[21:50] <mdz> I don't follow
[21:51] <bdrung> the initial problem was bug #743323
[21:51] <mdz> the bug reads like a regression in a stable update
[21:52] <mdz> so far it seems like in favor we have: relatively low impact package, bugfix-only branch
[21:52] <bdrung> yes, seems so
[21:53] <mdz> and against: not much in the way of regression testing
[21:53] <mdz> stgraber, kees, thoughts?
[21:53] <kees> I would be happy to grant a provisional MRE
[21:53] <bdrung> the pulseaudio plugin was rewritten to fix the memory leak, introduces a regression and was later fixed
[21:53] <kees> if the regression stuff repeats, then I'm not sure we can safely do MREs on VLC, even though it fixes so much stuff
[21:54] <kees> and if regressions do get fixed, that's a good sign.
[21:54] <stgraber> provisional sounds reasonable, we can see how ti goes after we get one or two upstream point release in. If we get any regression, we might have to consider more QA before pushing something to updates
[21:54] <mdz> if I were considering whether it makes sense to SRU 2.0.2, I would probably say yes, go for it, and if it regresses, we can just roll it back
[21:54] <mdz> but since I'm supposed to consider whether it should get a standing exception, I'm not so sure
[21:55] <bdrung> 1.1.10 contained the fix and 1.1.12 fixes the regressions
[21:55] <Daviey> wow. push something out, and roll back if it regresses? O_o
[21:55] <Daviey> As an emergency, great.. but as a /plan/?
[21:56] <mdz> Daviey, I'm open to other opinions
[21:56] <mdz> but I don't think it makes sense to apply a blanket approach to all packages
[21:57] <mdz> the fallout from regressions is very severe in some cases, and very little in others
[21:57] <mdz> if the sound in VLC is out of sync for a few days, that's a pretty limited impact
[21:57] <mdz> compared to, say, a graphics driver hang
[21:57] <bdrung> i got two bug reports against the daily-stable PPA package that i could fix (otherwise these bugs could have entered the archive later)
[21:58] <mdz> my only other idea would be to come up with a manual regression testing plan
[21:58] <mdz> which covers the most common/important functionality
[21:58] <mdz> play some streams in various formats, check that it works as expected, that sort of thing
[21:59] <bdrung> i do test the package with some video files, but that do not cover much of vlc
[21:59] <mdz> interesting that it didn't catch the audio sync issue
[21:59] <bdrung> it was connected to the underlying hardware
[21:59] <mdz> ah
[22:00] <bdrung> only some soundcards triggered it
[22:01] <mdz> the policy is that a provisional MRE can be approved by any TB member
[22:01] <mdz> and two have expressed support, so I think there's nothing more to discuss on this specific request
[22:01] <bdrung> what should be done if a new upstream release fixes security bugs?
[22:02] <mdz> I defer to the security team on that
[22:02] <mdz> anything else on this topic before we move on? we're out of time
[22:02] <bdrung> get it SRUed and then copied to -security or a separate fix for -security?
[22:02] <ScottK> bdrung: IME ask the security team and they'll tell you.
[22:02] <bdrung> k
[22:02] <mdz> #topic stable updates exception policy
[22:02] <LordOfTime> bdrung:  you can ask security questions to the security team in #ubuntu-hardened if you want, they might be able to answer
[22:02] <LordOfTime> (sorry for butting in )
[22:03] <mdz> based in part on the discussions in this meeting, I'd like to propose a small clarification
[22:03] <mdz> replace:
[22:03] <mdz>   * regression tests are enabled in the package's build
[22:03] <mdz> with:
[22:03] <mdz>   * regression tests are always run on the update before it is released (e.g. by being enabled in the package's build)
[22:03] <mdz> kees, stgraber, OK with that?
[22:03] <ScottK> That's not always feasible.
[22:03] <ScottK> There are packages that have tests that require a network.
[22:04] <mdz> ScottK, it's a noop for that case
[22:04] <mdz> this is only broadening the criteria, not restricting them further
[22:04] <stgraber> mdz: +1
[22:04]  * kees nods
[22:04] <ScottK> OK.
[22:04] <kees> +1
[22:04] <mdz> done
[22:04] <mdz> #topic closing business
[22:05] <mdz> who's next for chair? soren?
[22:05] <ScottK> mdz: I understand now.  I read it backwards.  Thanks.
[22:05] <kees> I think so, yes. can you email him to remind him?
[22:05] <kees> (since he's not here?)
[22:05] <mdz> will do
[22:05] <mdz> thanks all
[22:05] <mdz> #endmeeting
[22:05] <meetingology> Meeting ended Mon Jul 23 22:05:30 2012 UTC.
[22:05] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-07-23-21.14.moin.txt
[22:05] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-07-23-21.14.html
[22:05] <kees> thanks mdz!
[22:05] <stgraber> thanks mdz!
[22:05] <ScottK> Isn't that how you always get volunteered for stuff (by missing the meeting)?
[22:06] <TheLordOfTime> mdz:  ScottK:  sorry for butting in right at the end with pointing bdrung to the security team's channel, i assumed he wanted fast answers, so i directed him there :)
[22:07] <ScottK> TheLordOfTime: Most Ubuntu developers know about that already, but he's sure to now.
[22:07] <TheLordOfTime> ScottK:  indeed, just wanted to affirm :)
[22:07] <TheLordOfTime> (in case some didnt :P)
[22:08]  * TheLordOfTime returns to what he was originally doing, figuring out why Launchpad doesn't like him today