[18:12] <jdstrand> hi!
[18:12] <jjohansen> o/
[18:12]  * sbeattie waves
[18:12] <tyhicks> Hello
[18:12] <mdeslaur> o/
[18:12] <jdstrand> #startmeeting
[18:12] <meetingology> Meeting started Mon Sep 17 18:12:43 2012 UTC.  The chair is jdstrand. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[18:12] <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:12] <jdstrand> The meeting agenda can be found at:
[18:12] <jdstrand> [LINK] https://wiki.ubuntu.com/SecurityTeam/Meeting
[18:12] <jdstrand> [TOPIC] Announcements
[18:15]  * jdstrand is waiting for one more person
[18:16] <sarnold> jdstrand: pong
[18:16] <jdstrand> sarnold: fyi, The meeting agenda can be found at: https://wiki.ubuntu.com/SecurityTeam/Meeting
[18:17] <sarnold> (sorry friends, I was unaware that #ubuntu-* was the shorthand for "find it on freendoe")
[18:17] <jdstrand> so, only announcement this week is welcoming sarnold to the ubuntu-security team :)
[18:17] <mdeslaur> sarnold: welcome! (again!)
[18:17] <jdstrand> sarnold: welcome! :)
[18:17] <jjohansen> Welcome sarnold
[18:17] <sarnold> thank you all :)
[18:18] <jdstrand> [TOPIC] Weekly stand-up report
[18:18] <jdstrand> I'll go first
[18:19] <jdstrand> I'm on triage this week and am also patch piloting. I am supposed to do that today, but may need to reschedule... we'll see
[18:19] <jdstrand> I've got quite a bit of backlog from last week that I need to get through
[18:19] <jdstrand> and also follow-ups surrounding the manager's sprint
[18:20] <jdstrand> I also figure I'll be helping sarnold come up to speed a bit
[18:20] <jdstrand> I've also got some audits to do, and hopefully get to some updates
[18:20] <jdstrand> mdeslaur: you're up
[18:21] <mdeslaur> I just published some updates
[18:21] <mdeslaur> and am working on testing dhcp and dbus updates
[18:21] <mdeslaur> I need to investigate some gpg key issues
[18:21] <mdeslaur> and then will pick something else from the list
[18:21] <mdeslaur> that's it from me
[18:21] <mdeslaur> sbeattie: you're up
[18:22] <sbeattie> I'm on community this week
[18:22] <sbeattie> I'm briefly looking at a regression fix for openjdk-7 for doko
[18:23] <sbeattie> I've also got glibc on my plate
[18:23] <sbeattie> I've still got the apparmor/dbus stuff to upload to a ppa
[18:24] <sbeattie> after that, I'll try to pick up another update or two
[18:24] <sbeattie> that's it for me.
[18:24] <tyhicks> I'm up since Micah is out today
[18:24] <tyhicks> I'm in the happy place again this week
[18:24] <tyhicks> I'll be submitting the fix for bug 1051892 to upstream OpenSSL today for their comments
[18:25] <tyhicks> Then I'll proceed with preparing updates for rubygems and ruby1.9.1
[18:25] <tyhicks> With the kernel merge window coming up soon, I need to get through all of my eCryptfs patch review backlog
[18:25] <tyhicks> I'm also in the process of getting the latest AppArmor introspection interface patches from jjohansen to start work on my related work items
[18:25] <tyhicks> jjohansen: You're up
[18:25] <jjohansen> I have an apparmor QRT failure happening on the QA machines but not locally to finish tracking down. The IMA config and YAMA upstream sync to finish up.
[18:25] <jjohansen> I still have to get together with sbeattie/tyhicks over apparmor dbus stuff
[18:25] <jjohansen> And then its back to apparmor labeling/stacking
[18:26] <jjohansen> thats it for me, jdstrand back to you
[18:28] <jdstrand> sarnold: you're up
[18:28] <jdstrand> jjohansen: jeez, already ignoring the new guy :P
[18:28] <jjohansen> oops
[18:28] <sarnold> new-employee handling; I think I've just about finished making launchpad happy
[18:29] <sarnold> I downloaded the magic cve tool but I was a bit shocked at how many CVE entries from three years ago appear to still need work -- are those for real? :)
[18:29] <jdstrand> yes, they are
[18:29] <sarnold> oh. my.
[18:29] <jdstrand> Canonical-supported CVEs should not really be above 'low' though
[18:30] <jdstrand> community supported packages are in various states of up-to-dateness
[18:30] <sarnold> so, CVE-2008-2004 isn't 'low' but it does have a handful of 'needed'... is that waiting on upstream?
[18:30] <jdstrand> (of course, we have some mediums to do, but you'll see more of that this week)
[18:31] <jdstrand> sarnold: without looking, xen-3.3 userspace is in universe and community supported
[18:31] <sarnold> ah!
[18:32] <sarnold> so the situation is not as dire as it first looked. Thanks.
[18:32] <sarnold> jdstrand: I think that covers me for now. :) Thanks.
[18:32] <jdstrand> well, not for canonical supported stuff anyway :)
[18:32] <jdstrand> np
[18:32] <jdstrand> which brings me to our next topic
[18:32] <jdstrand> [TOPIC] Highlighted packages
[18:32] <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:33] <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:33] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/sun-javadb.html
[18:33] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/osc.html
[18:33] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/ejabberd.html
[18:33] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/pure-ftpd.html
[18:33] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/libdbd-pg-perl.html
[18:33] <jdstrand> [TOPIC] Miscellaneous and Questions
[18:33] <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:33] <jdstrand> Does anyone have any other questions or items to discuss?
[18:37] <jdstrand> #endmeeting
[18:37] <meetingology> Meeting ended Mon Sep 17 18:37:44 2012 UTC.
[18:37] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-09-17-18.12.moin.txt
[18:37] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-09-17-18.12.html
[18:37] <mdeslaur> thanks jdstrand!
[18:37] <jdstrand> mdeslaur, sbeattie, tyhicks, jjohansen, sarnold: thanks!
[18:38] <jjohansen> thanks jdstrand
[18:38] <tyhicks> thanks!
[18:38] <sbeattie> thanks jdstrand
[18:39] <sarnold> jdstrand: btw, the /Meeting agenda page has two times listed for the meetings; both 1700 UTC and 1800 UTC. Is one more common than the other?
[18:39] <jdstrand> sarnold: no, that is an error
[18:39]  * jdstrand adjusts
[18:40] <jdstrand> sarnold: fixed! it will always be 1800 UTC, DST or no
[18:41] <sarnold> jdstrand: thanks
[18:41] <jdstrand> sarnold: nice eye :)
[20:00] <mdz> cjwatson, TB today?
[20:00]  * pitti waves
[20:01] <mdz> o/
[20:02] <cjwatson> hi
[20:02] <cjwatson> I think I was due to be chair last time but was absent
[20:02] <cjwatson> or the meeting didn't happen or something
[20:02] <cjwatson> we do actually have an agenda this time
[20:03] <cjwatson> kees,stgraber,soren_: around?
[20:04] <stgraber> yep
[20:05] <stgraber> I believe I (and maybe some others) missed last meeting because I was just getting back from Linux Plumbers and it was a public holiday in the US and Canada
[20:08] <cjwatson> #startmeeting
[20:08] <meetingology> Meeting started Mon Sep 17 20:08:51 2012 UTC.  The chair is cjwatson. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[20:08] <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:08] <cjwatson> I guess we have quorum
[20:09] <cjwatson> #topic action review
[20:09] <cjwatson> The last minutes I see are ancient: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2012-May/000958.html
[20:09] <cjwatson> So I'm going to assume that we've just been quiet for that long and have no actions to review at this point; shout if that's untrue
[20:10] <cjwatson> #topic nvidia/fglrx expedited SRUs (bryce)
[20:10] <pitti> didn't we have some brainstorm review pending?
[20:10] <cjwatson> I'll have a look and get back to that later, then
[20:11] <cjwatson> #topic action review
 #action stgraber to try and find all the places to update the TB meeting time to 20:00 UTC
[20:11] <cjwatson> now that I found the IRC logs
[20:11] <cjwatson> stgraber: did that happen?
[20:11] <stgraber> yep, fridge was updated and wiki too, not aware of any other place to change
[20:12] <cjwatson> OK
[20:12] <cjwatson> soren_: so, this brainstorm review ...
[20:12] <cjwatson> (async ping as he doesn't seem to be here)
[20:13] <cjwatson> #topic nvidia/fglrx expedited SRUs (bryce)
[20:14] <cjwatson> bryceh: would you like to hash this out any more here?  we don't seem to have consensus yet on the issue of unsubstantiated regressions
[20:14] <pitti> this was discussed on the ML for a bit already, but the fundamental stability vs. fast turnaround conflict remains
[20:14] <bryceh> hi
[20:14] <cjwatson> I'm not sure I see that as the principal conflict :)
[20:14] <pitti> but I think the whole point of this request was to get leniency on stability there, so I guess we should rather discuss how to get back to the "normal" driver as quickly as possible?
[20:14] <bryceh> cjwatson, yeah I was distracted writing a reply to that email
[20:14] <cjwatson> well, I did only send my reply earlier today
[20:15] <cjwatson> in general I'm supportive of being able to be a bit more relaxed about -updates SRUs, but I want to ensure that we aren't causing problems by doing o
[20:15] <cjwatson> *so
[20:15]  * bryceh nods
[20:15] <mdz> yes, I understood the goal to be to offer an alternative update stream which users could opt in to, with a greater tolerance for possible regressions in favor of compatibility with newer apps
[20:16] <cjwatson> right, *if* users understand that that's what they're opting into
[20:16] <mdz> yes
[20:16] <mdz> a warning would be appropriate
[20:16] <cjwatson> my concern is that if nvidia-current is busted for a user and nvidia-current-updates works, then their perception will be "this is the one that works" and will be discombobulated when it breaks
[20:16] <pitti> at the time when they need it, they probably won't have much incentive to not use it
[20:17] <cjwatson> this would be a lot easier if we could start things off this way as of (say) quantal, with update-manager having reset people to non-updates on upgrade
[20:17] <cjwatson> is that a feasible thing to do, or do we really really need this for precise?
[20:17] <pitti> bryceh: I did understand that for -experimental we do want to get back to the "regular" driver on every dist-upgrade; is that planned for -updates as well?
[20:17] <bryceh> mdz, we are adding a warning for the nvidia-experimental package; currently there is no warning on nvidia-current-updates, although I think we could use the same mechanism to add one.
[20:18] <pitti> well, I do think that regression reports for -updates should at least hold the line, as usual for SRUs; for -experimental, being quick is the very point of the exercise, so that's where the leniency comes in, no?
[20:19] <bryceh> pitti, right, plan is that we're doing that for -experimental.  Whether to do that for -updates is open for discussion.
[20:19] <cjwatson> I'm not sure I see how the mechanism pitti proposes will achieve this
[20:19] <cjwatson> the proposal is that, at release time, -experimental is an empty transitional package depending on nvidia-current
[20:19] <pitti> cjwatson: I'm mostly concerned about enabling this for your favorite game of the day, and then forgetting about it, so that you keep having the risk for all eternity
[20:20] <cjwatson> and that later -experimental becomes a real package and drops the Depends
[20:20] <cjwatson> But that doesn't help, because everyone who had -experimental installed earlier still has it installed, transitional package or not
[20:20] <cjwatson> So the upgrade will turn it from transitional to real and we have the same problem
[20:20] <pitti> that would only work for dist-upgrades until there is a newer -experimental in the newer release, yes
[20:20] <pitti> so that does need u-m support
[20:21] <cjwatson> The only way I can see this working properly is bryceh's suggestion of changing package names for each nvidia series
[20:21] <cjwatson> Which is somewhat inelegant, but perhaps the best we can do?
[20:21] <bryceh> cjwatson, to your earlier question, yes it's strongly wanted for the LTS
[20:21] <pitti> we did have that in the past, and for some reason that was changed to the -current name; but yes, -NNN would ceratainly make these upgrades work with pure apt
[20:22] <cjwatson> -current makes more sense for "the one we want most people to use"
[20:22] <bryceh> yep
[20:23] <bryceh> one question I don't have a good opinion on, so would like advice:
[20:23] <cjwatson> so yes - if we can start from a clean slate, and ensure that anyone who installs the given package has seen a warning (or had to go to effort to preseed it away), then I'm moderately sanguine about some reasonable approach to handle regressions that we can't substantiate with reasonable effort
[20:24] <bryceh> once the beta is done and an official version is released by NVIDIA, should we update nvidia-experimental to the release version or leave it at whatever old beta driver it was on?
[20:24] <cjwatson> nvidia-NNN-experimental, no?
[20:24] <cjwatson> (or similar naming)
[20:24] <bryceh> or nvidia-experimental-NNN
[20:25] <cjwatson> there doesn't seem much point in leaving it at a beta version for the sake of it, really
[20:25] <cjwatson> assuming that in general official > earlier-versioned-beta ...
[20:26] <pitti> why do we need both "-experimental" and "-NNN"? I thought -NNN would suffice?
[20:26] <bryceh> cjwatson, so like if we have nvidia-experimental-123, and 123.11, 123.22, 123.33 are the beta version, with 123.44 being the official release, should we leave it to 123.33 or go to 123.44 (which would also presumably appear in nvidia-current-updates at some point)
[20:26] <cjwatson> is there a reason why people might want 123.33 not 123.44?
[20:26] <pitti> I think we should update betas to finals
[20:27] <pitti> chances are that some games need the fixes anyway?
[20:27] <bryceh> yeah that's what I'm thinking...
[20:27] <ScottK> Make nvidia-experimental-123 transitional and have it depend on nvidia-current-updates once the release is done.
[20:27] <pitti> and if we don't release beta->final to experimental due to caution, why would we do that for -updates?
[20:27] <cjwatson> right, I have trouble thinking of a reason why we wouldn't; although I wonder whether that should be done by depending on nvidia-current-updates (thus making it mean ">= 123") or freezing it at a particular 123 subversion
[20:27] <cjwatson> IYSWIM
[20:27] <bryceh> ok great
[20:28] <pitti> so why do we need the "-experimental" suffix if we already have a -NNN? am I missing something?
[20:28] <pitti> I think we do need the -NNN for ensuring that upgrades always reset to the stable one
[20:28]  * bryceh ponders
[20:29] <cjwatson> I'm not fussed about -experimental if there's a warning saying as much
[20:29] <bryceh> there is some messaging value to -experimental, for people who might not read the warning but would see the package name, however technically I don't see any reason to favor that over just -NNN
[20:30] <bryceh> if it is -NNN then people may expect us to update it with post-release updates of the driver
[20:30] <bryceh> whereas I'd sort of prefer to be done with the package once the beta is over
[20:30] <cjwatson> compare gcc-snapshot
[20:31] <cjwatson> different audience there of course
[20:31] <pitti> ok, if it's just for the warning effect (not for some dependency magic), I'm fine with that
[20:33] <bryceh> pitti, fine with that being to keep -experimental or exclude it?
[20:33] <pitti> bryceh: with either really; I was mostly curious for what exactly we need the -experimental suffix
[20:33] <pitti> actually
[20:34] <pitti> it's helpful to have it for ubuntu-drivers-common
[20:34] <bryceh> ok
[20:34] <pitti> it currently filters "experimental" on the package name to sort it last in the "recommended version" list
[20:34] <bryceh> aha, good.
[20:34] <cjwatson> so, is there any remaining dissent here which we need to vote on, or do you think we're good to go on this?
[20:34] <pitti> so that it only ever installs that if no other version supports your card
[20:35] <pitti> do we have consent on the SRU verification? cjwatson's last mail sums it up pretty well IMHO
[20:38] <cjwatson> ScottK: does this discussion meet the concerns you expressed on the list - that is, weaken handling of hard-to-substantiate regressions (but don't ignore them entirely) for nvidia/fglrx packages where users have previously been warned about potential instability?
[20:38] <cjwatson> (which is about the best one-sentence summary I can come up with)
[20:39] <ScottK> cjwatson: I'm concerned that if we make a special rule for unsubstantiated regressions for one package, it'll spread.
[20:39] <ScottK> I'd much rather say for this one package, a certain degree of regression is OK.
[20:40] <ScottK> It's a binary blob video driver, so we can't fix it anyway, it's optional, and video drivers very rarely are 100% improvement for alll hardware.
[20:41] <cjwatson> So you'd rather not include a rationale with the policy in case it's taken as a general example, basically?
[20:41] <cjwatson> I can live with that.
[20:42] <pitti> yeah, fine for me as well; if we say "this package will always be the latest beta driver", this states it's very reason of existance, and implicitly contains that it won't stop upgrading
[20:43] <cjwatson> Or "the latest beta driver in series NNN" or whatever.
[20:43] <cjwatson> I think I'm happy to leave that part up to the teams dealing with it.
[20:44] <bryceh> this all sounds great :-)
[20:48] <cjwatson> OK, let's move on
[20:48] <cjwatson> #topic Scan the mailing list archive for anything we missed
[20:49] <cjwatson> Edubuntu Sponsorship Process
[20:49] <cjwatson> Has a couple of +1s although I concur with Mark's comment that this is more a matter for trademark@
[20:50] <cjwatson> highvoltage: ^- if you feel this needs more, please follow up
[20:50] <cjwatson> Extension of term lengths - done
[20:50] <cjwatson> And I don't see anything else of any note
[20:50] <pitti> neither do I
[20:50] <pitti> the rest was handled by mail
[20:51] <Laney> transferring the kernel packageset
[20:51] <Laney> I didn't see any comment on that in my mail
[20:51] <Laney> admittedly it was tacked on to the end
[20:51] <cjwatson> community bugs, just the usual takes-ages-to-resolve
[20:51] <cjwatson> Laney: URL?
[20:51] <highvoltage> cjwatson: ah, it's been handled by mail, thanks
[20:51] <Laney> http://mid.gmane.org/20120827200048.GB14343@orangesquash.org.uk
[20:51] <Laney> if that works
[20:51] <highvoltage> (at least, I believe so)
[20:52] <stgraber> Laney: well, we first need a way of actually doing that ;)
[20:52] <Laney> that'll be landed soon
[20:52] <Laney> if changing owner is a part of that branch
[20:53] <stgraber> not sure what's in the branch, ideally we'd need to have the delete function mapped and make all the attributes read/write
[20:53] <Laney> so, if you could agree it then someone can JFDI when it becomes possible
[20:53] <Laney> if this is in that branch then great, otherwise SMOP
[20:55] <cjwatson> Makes sense to me for DMB to own the kernel set
[20:56] <cjwatson> Once possible
[20:56] <cjwatson> If it's urgent for some reason we could try to arrange for manual SQL, but I'd really rather not
[20:56] <stgraber> nah, not urgent. I'll do any update the DMB needs to do to it as I have both DMB and TB hats.
[20:56] <cjwatson> OK
[20:56] <cjwatson> #topic AOB
[20:57] <cjwatson> anything else?  we have three minutes
[20:57] <bryceh> cjwatson, regarding the nvidia proposals, did the discussion above qualify as a vote or does a formal vote still need to be held?
[20:58] <cjwatson> AFAICT there was consensus and therefore no need for a vote
[20:58] <bryceh> awesome, thanks.
[20:58] <pitti> *agree*
[21:00] <cjwatson> #endmeeting
[21:00] <meetingology> Meeting ended Mon Sep 17 21:00:50 2012 UTC.
[21:00] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-09-17-20.08.moin.txt
[21:00] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-09-17-20.08.html
[21:00] <cjwatson> Thanks all
[21:01] <pitti> thanks everyone!
[21:01] <pitti> and good night
[21:01] <cjwatson> I'll sort out minutes in a bit
[21:01] <cjwatson> In a shocking departure from routine
[21:04] <stgraber> thanks