[16:31] <mdeslaur> \o
[16:32] <tyhicks> hello
[16:32] <jjohansen> o/
[16:32] <mdeslaur> #startmeeting
[16:32] <meetingology> Meeting started Mon May 12 16:32:49 2014 UTC.  The chair is mdeslaur. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:32] <meetingology> Available commands: action commands idea info link nick
[16:32] <mdeslaur> The meeting agenda can be found at:
[16:32] <mdeslaur> [LINK] https://wiki.ubuntu.com/SecurityTeam/Meeting
[16:32] <mdeslaur> [TOPIC] Announcements
[16:32] <mdeslaur> Thanks to the following contributors for their help on security updates last week:
[16:32] <mdeslaur> Otto Kekäläinen (otto) provided debdiffs for trusty for mariadb-5.5 (LP: #1313187)
[16:32] <mdeslaur> James Page (jamespage) provided a debdiff for trusty for mysql-5.6 (LP: #1313566)
[16:32] <mdeslaur> Reinhard Tartler (siretart) provided an updated libav package for trusty (LP: #1277173)
[16:32] <mdeslaur> Your work is very much appreciated and will keep Ubuntu users secure. Great job! :)
[16:32] <mdeslaur> [TOPIC] Review of any previous action items
[16:32] <mdeslaur> none
[16:32] <mdeslaur> [TOPIC] Weekly stand-up report
[16:32] <mdeslaur> I'll go first
[16:33] <mdeslaur> I'm in the happy place this week.
[16:33] <mdeslaur> I'm working on some updates, and I'll probably be doing the embargoed issue tomorrow
[16:33] <mdeslaur> I also have to review blueprints
[16:33] <mdeslaur> and I'm going to plan a meeting to go through them with the rest of you tomorrow
[16:33] <mdeslaur> quite possibly around this time
[16:33] <mdeslaur> well, a half hour later
[16:34] <mdeslaur> that's it from me, sbeattie, you're up
[16:35] <sbeattie> I'm working on compiler hardening stuff again; I'm currently looking through the test results for gcc-4.9 for enabling -fstack-protector-strong by default and fixing the way -Wformat and -Wformat-security were being enabled.
[16:35] <sbeattie> Things on that front are looking good and I'll probably hand off those patches to doko later today.
[16:35] <mdeslaur> sbeattie: cool!
[16:36] <sbeattie> Getting -pie by default for amd64 is looking trickier and will take some more time.
[16:36] <mdeslaur> sbeattie: trickier in what way?
[16:36] <doko> sbeattie, does this mean I get fixes for the testsuite? ;p
[16:36] <sbeattie> Defining specs for per-arch where gcc treats i386/amd64 as the same arch is non-obvious/
[16:37] <mdeslaur> sbeattie: hrm...what about the idea of conditionally patching it based on arch?
[16:37] <sbeattie> doko: not immediately, but yes, I intend to look at those, too; the patches I have reduce the number of failures by a few.
[16:37] <mdeslaur> or is that painful for cross-compilation or something?
[16:38] <doko> is -fpie already decided?
[16:38] <sbeattie> It makes it harder to avoid enabling -pie for -m32 case
[16:39] <mdeslaur> doko: for amd64, pretty much yeah
[16:39]  * doko sees python and cc1 performans going down :-/
[16:40] <mdeslaur> doko: buy a faster machine!
[16:40] <sbeattie> doko: well, once we have a patch to do that, we can see the impact, if it's bad there than we can revisit and/or disable for just those.
[16:42] <sbeattie> anyway. I still need to investigate mod_apparmor and track down some QRT issues with ppc64el this week.
[16:42] <sbeattie> And I guess review blueprints, too.
[16:42] <sbeattie> That's it for me. tyhicks?
[16:43] <tyhicks> I'm wrapping up the dbus merge from debian testing
[16:43] <mdeslaur> ah, right, I probably should tackle some merges too
[16:44] <tyhicks> there's a new test-dbus.py failure (running make check) that I need to make sure isn't caused by the new apparmor mediation patches
[16:44] <tyhicks> then it is back to kdbus (I let the merge and some apparmor testing jump in front of my planned kdbus work from last week)
[16:45] <tyhicks> I also need to review blueprints and prepare for the sprint this week, since I'm out next week
[16:45] <tyhicks> that's it for me
[16:45] <tyhicks> jjohansen: you're up
[16:46] <jjohansen> I am working on apparmor this week. I need to spend some time looking at the upstream cross rename patches, there is a reported regression in apparmor with them.
[16:46] <jjohansen> I need to finish testing the patchset I have for upstream this week so it can land in time for the next kernel merge window.
[16:46] <jjohansen> Hopefully there will be more feedback on the bugs I was poking at last week so I can continue looking at them while the are fresh in my mind
[16:46] <jjohansen> There are some outstanding patches I that need to be reviewed on the mailing lists
[16:46] <jjohansen> bp to look at
[16:46] <jjohansen> and then it will be back to finishing up one of my outstanding patch queues so that it can be kicked out for review
[16:47] <mdeslaur> yay
[16:47] <sarnold> \o/
[16:48] <jjohansen> I think that is it for me, sarnold you're up
[16:48] <sarnold> I'm on triage this week
[16:48] <sarnold> I have an emargoed update this week
[16:48] <sarnold> and I've gotten the test-django script to only 7 instead of 8 failures on trusty, so.. 86% left to go there, I guess
[16:49] <mdeslaur> sarnold: heh, nice. did you get it working with the other apache thingy?
[16:49] <mdeslaur> mod_wsgi
[16:49] <sarnold> mdeslaur: that was the one success :)
[16:49] <mdeslaur> cool :)
[16:50] <sarnold> mdeslaur: now just to figure out why the other seven still don't play along with mod_wsgi -- they might still be faults in configuration or those tests may also need more modification
[16:50] <mdeslaur> sarnold: apache 2.4 moved some stuff around, and required a few more modules
[16:50] <sarnold> it might be simple (django changed some of the routing API, but those changes were easy to adapt..)
[16:50] <mdeslaur> a lot of the other qrt scripts needed adjustments
[16:50] <mdeslaur> it may be related to that
[16:51] <sarnold> mdeslaur: yeah, the auth changes required a bit of fiddling too, but at least it lines up exactly with django's change to wsgi as well..
[16:53] <sarnold> it's been more work than I first expected. :)
[16:53] <sarnold> mdeslaur: back to you :)
[16:53] <mdeslaur> sarnold: that's why I gave it to you instead of doing it myself :)
[16:53] <mdeslaur> slacker++
[16:53] <mdeslaur> [TOPIC] Highlighted packages
[16:53] <mdeslaur> 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.
[16:53] <mdeslaur> 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.
[16:53] <mdeslaur> http://people.canonical.com/~ubuntu-security/cve/pkg/nss-pam-ldapd.html
[16:53] <mdeslaur> http://people.canonical.com/~ubuntu-security/cve/pkg/openjdk-6.html
[16:53] <mdeslaur> http://people.canonical.com/~ubuntu-security/cve/pkg/shibboleth-sp2.html
[16:53] <mdeslaur> http://people.canonical.com/~ubuntu-security/cve/pkg/libcgi-application-perl.html
[16:53] <mdeslaur> http://people.canonical.com/~ubuntu-security/cve/pkg/encfs.html
[16:54] <mdeslaur> [TOPIC] Miscellaneous and Questions
[16:54] <mdeslaur> Does anyone have any other questions or items to discuss?
[16:55] <mdeslaur> zzzz
[16:55] <mdeslaur> Thanks everyone!
[16:55] <mdeslaur> #endmeeting
[16:55] <meetingology> Meeting ended Mon May 12 16:55:34 2014 UTC.
[16:55] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2014/ubuntu-meeting.2014-05-12-16.32.moin.txt
[16:55] <sbeattie> mdeslaur: thanks!
[16:55] <sarnold> thanks mdeslaur!
[16:55] <jjohansen> thanks mdeslaur
[20:01] <mdeslaur> \o
[20:09] <pitti> hello
[20:09] <mdeslaur> hi pitti, infinity
[20:09] <pitti> sorry for being late, I really can't make it any earlier
[20:10] <pitti> did we start already? so stgraber and slangasek sent apologies
[20:10] <infinity> S'ok.  I had a bit of a siesta, and ended up dreaming about the meeting instead of attending it.
[20:10] <mdeslaur> pitti: np, we haven't started or anything.
[20:10] <mdeslaur> heh
[20:11] <pitti> kees: you didn't reply to mdeslaur's meeting time proposal yet?
[20:11] <pitti> so if Tue 17:00 doesn't work for kees, we can try the alternating
[20:12] <pitti> #startmeeting
[20:12] <meetingology> Meeting started Mon May 12 20:12:26 2014 UTC.  The chair is pitti. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[20:12] <meetingology> Available commands: action commands idea info link nick
[20:12] <pitti> (not that we have much of an agenda..)
[20:12] <pitti> #topic action review
[20:12] <pitti> can you help me out here? last report is from Apr 14, without loose ends
[20:12] <pitti> except "slangasek to work with SRU team to get a list of how the provisional MREs have/haven't been used ", but that now went to mail
[20:13] <pitti> was there anything from two weeks ago?
[20:13] <infinity> I think that's about the only outstanding thing we have.
[20:13] <mdeslaur> I don't believe we had anything further
[20:13] <infinity> That and the meeting time.
[20:14] <pitti> there's also sabdfl's "matters approaching", but that rather sounds like taking some good time of thinking and replying by mail; objections?
[20:14] <mdeslaur> nope
[20:15] <infinity> Yeah, I don't think we'll get anywhere discussing that via IRC just yet.
[20:15] <pitti> #topic MRE review
[20:15] <infinity> Some folks will be having heated debates about that in Malta soon.
[20:15] <infinity> (The sabdfl thing, not MREs)
[20:15] <pitti> so, TBH I don't feel like interactively discussing every single one, but we shoudl talk a bit about "in vs. out" criteria
[20:16] <pitti> for all except LibO it's not quite clear whether the "new errors reported" were actual regressions or people just happened to send the first report on the update
[20:16] <infinity> Right, and I think we need to know that.
[20:16] <pitti> but that's hard to automate, I guess we can just ask for a list and do some spot-checks
[20:17] <infinity> If it's a regresison, it's interesting, though we also expect, I think, that MRE's might introduce new bugs (new code has new bugs), and that needs to also be weighed against responsiveness of the people responsible for the MRE in responding to those.
[20:18] <infinity> We don't *want* them to introduce new bugs, but we may have to be realists too.
[20:18] <mdeslaur> is there anything in the list that sticks out?
[20:18] <pitti> at least it seems that the entries on https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions/ProvisionalStatus have all actually been used in practice
[20:19] <pitti> but that is perhaps only packages which actually *have* been updated; it's by far not the complete one from https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
[20:19] <pitti> e. g. firefox is missing, and we update that all the time
[20:19] <pitti> ah sorry, no, these are *just* the provisional ones
[20:20] <infinity> The only thing that immediately jumps out at me is mesa, and it the stickiest one from the POV of "we need this for HWE" and "we know it's going to occasionally introduce new bugs".
[20:20] <pitti> e. g. bug 1316988 doesn't look like a regression
[20:20] <pitti> infinity: yeah, that's pretty much the only one which makes me nervous, too
[20:21] <pitti> the OpenStack bits generally seem to keep their "we don't break stuff" promise
[20:21] <infinity> Well, the openstack bits also get installed on machines without errors submissions, so we're relying on manual LP bug submissions there.
[20:21] <pitti> e. g. ceph, heat, neutron etc. look exemplary
[20:21] <pitti> ah right
[20:21] <mdeslaur> oh, right
[20:22] <infinity> Which is, eg, why vlc looks so bad.  Lots of people use it, and all those people are on desktops with automagic error submission.
[20:22] <infinity> But I suspect almost none of the vlc errors are regressions in VLC.  I'd have to go hunting to confirm that, mind you.
[20:22]  * pitti looks at bug 1189909
[20:23] <pitti> I can't be sure, but at least there's no comment that suggests a regression
[20:23] <infinity> FWIW, openvswitch is also an HWE issue.  They're backporting new versions to be compatible with HWE kernels.
[20:23] <mdeslaur> multimedia stuff crashes all over, it would probably be hard to figure out what are actually regressions
[20:23] <infinity> At the time, we argued that making the old version build would be preferable, but there were claims this ranged from difficult to impossible.
[20:24] <pitti> infinity: yeah, "new errors reported: 183" is almost surely because we dno't offer the LTS->LTS upgrade before releaseing the .1
[20:25] <infinity> #1316988 isn't a package regression, though, it's just a user who removed their headers.
[20:25] <pitti> infinity: right
[20:26] <infinity> So, none of this jumps out at me as either people who don't need their MRE (they're all being used) or people who are abusing them.
[20:26] <pitti> so, so far we don't really have proof that anything actually regressed (except for LibO, I didn't go through all these bugs yet)
[20:26] <pitti> and I'd rather do that ^ off-meeting
[20:26] <infinity> Other than LibreOffice, which is scary as crap.
[20:26] <pitti> yes, but this is also one of these packages which get bug reports all the time :)
[20:26] <infinity> But for mesa, I'd like to perhaps hunt down the desktop team and get some formal commitment from them for regression tracking.
[20:27] <infinity> Since I don't think we can ask them to stop updating mesa, but we don't want to blow up OpenGL desktops like GNOME and Unity.
[20:27] <pitti> bug 1134974
[20:27] <pitti> that almost surely is a regression
[20:27] <mdeslaur> hrm
[20:28] <pitti>  mesa | 9.0-0ubuntu1     | quantal          | source
[20:28] <pitti>  mesa | 9.0.3-0ubuntu0.4 | quantal-updates  | source
[20:28] <pitti> and downgrading to 9.0-0ubuntu1 fixed this
[20:28] <pitti> so, one piece of (bad) proof
[20:29]  * pitti chuckles at bug 1070178
[20:29] <infinity> ...
[20:30] <pitti> but #1134974 is worrying -- it didn't get any triage etc.
[20:30] <infinity> Right.  And it stops mattering in 4 days, but I don't want this to be a pattern.  Those bugs need to be looked at.
[20:30] <pitti> and TBH for LTSes we have the backported stacks now, and for non-LTSes, who bothers -- do we really have OEM customers on 9-month releases? that sounds scary
[20:32] <pitti> so my gut feeling is that we need to inspect the LibO bugs further, revert the mesa one for the time being, and turn the others into "approved" ones
[20:32] <pitti> mdeslaur, infinity: WDYT?
[20:32] <infinity> pitti: The backport stacks have the same issue.  How do you think they come to exist? :P
[20:32] <infinity> libgl1-mesa-dri-lts-quantal:
[20:32] <infinity>   Installed: (none)
[20:32] <infinity>   Candidate: 9.0.3-0ubuntu0.4~precise1
[20:32] <pitti> infinity: yes, but they don't affect existing systems
[20:32] <infinity> No, it's possible 9.0.3 fixed that bug (it was reported against 9.0.2), but no one's looked at it to see.
[20:33] <infinity> s/No/Now/
[20:33] <pitti> if you install from a X.Y.2 image and have a broken system right away, that's much less of a pain than breaking a running productino system
[20:33] <infinity> pitti: They absolutely can affect existing systems.
[20:33] <mdeslaur> pitti: by revert, you mean revoke it's status?
[20:33] <infinity> pitti: If you installed with an lts-q stack with mesa 9.0 and upgraded to a newer backport of the stack, boom.
[20:33] <pitti> infinity: yes, and I want this to stop (as that's the MRE, isn't it?)
[20:34] <pitti> the backported stacks have parallel packages
[20:34] <infinity> pitti: Erm.  I think we're talking past each other?
[20:34] <pitti> as to what backported kernels and X.orgs do, they probably break loads of machines; but dist-upgrade won't automatically get those on existing systems
[20:34] <infinity> pitti: If we revoke the MRE for mesa, we're revoking it for backport stacks too.
[20:35] <infinity> pitti: Precise users would have absolutely gotten this breakage automatically.
[20:35] <pitti> infinity: how so? linux/xorg/etc. don't have an MRE either, and get backported
[20:35] <pitti> infinity: yes, *this* breakage from the bug above (when they upgrade precise to quantal-updates)
[20:35] <pitti> that's what I'd like to stop :)
[20:35] <infinity> pitti: mesa-lts-q started out in the "good" version and was later updated to match Q's new version.
[20:36] <pitti> infinity: ah, because the newer upstream release was backported again?
[20:36] <pitti> yes, that'd be the MRE again
[20:36] <infinity> Anyhow, we do new mesa microreleases for HWE reasons too.  Waiting 6 months for a new backport stack doesn't help.
[20:36] <infinity> I don't think rejecting it outright is the answer, I think the answer is a better bug triage/followup commitment.
[20:36] <infinity> There's been no activity on that bug from the desktop team, nor any piling on "me toos" since 9.0.3 was released.
[20:37] <pitti> well, in order to avoid regressions, you'd have to test on all hw of teh world
[20:37] <infinity> My guess is that 9.0.3 fixed it, but we have no way to know, cause no one's bothered to look.
[20:37] <pitti> triaging bugs after releaseing to -updates is important, but then the damage is done already
[20:37] <pitti> *nod*
[20:37] <infinity> But, if you want to go the more conservative route here, you're an ex-desktopper, you probably have a better handle on what'll work.
[20:38] <pitti> well, it never really worked
[20:38] <infinity> Heh.
[20:38] <pitti> it's an eternal conflict between OEM always wanting teh latest and greatest and existing installs
[20:38] <pitti> (and not having an OEM archive to go on top of that)
[20:38] <infinity> I think about 99% of the things we do in the name of HWE are crazy, but we have to make some concessions for people who insist on buying new computers.
[20:39] <mdeslaur> were those mesa srus done for oem's benefit, or where they to correct issues people were having?
[20:39] <infinity> I doubt it was for OEM.
[20:39] <infinity> Other than the part where OEM likes the latest crack.
[20:39] <infinity> But bringing in mlankhorst to the discussion would be helpful.
[20:39] <pitti> of course we also have -backports now which is enabled by default, so maybe that'd be a better route for these cases
[20:40] <infinity> pitti: Enabled, but you don't install from it.
[20:40] <infinity> pitti: Which, from an HWE perspective, is useless, and from a bugfixing perspective, is almost also so.
[20:40] <pitti> infinity: right, but we own our installer, so there's little which keeps the installer from picking mesa from -backports
[20:41] <pitti> but that again of course only works for the first update
[20:41] <pitti> every subsequent one will again break existing machines
[20:41] <pitti> so, back to square #1
[20:41] <pitti> but still, from a community/TB POV this is a fail
[20:42] <infinity> Right, I think we need to have a chat with Maarten, see why they think they need this MRE, if there's any way it can be done more safely, and if not, drop the whole thing.
[20:42] <infinity> I'll note a new micro-release of mesa landed in trusty-proposed 9h ago. :P
[20:42] <pitti> yay
[20:43] <mdeslaur> heh
[20:43] <pitti> ack, so we need a follow  up with the desktop team here
[20:43] <pitti> I'll do that, as a bit of an apology for missing the last few meetings
[20:43] <infinity> Shiny.
[20:43] <pitti> ACTION: pitti to follow up with Maarten wrt. mesa MRE
[20:43] <infinity> Feel free to miss more in the future, if it leads to you taking all the actions.
[20:43] <pitti> can we review the LibO bugs offline and respond to the mail?
[20:44] <infinity> Yeah, I think LibO is too heavy to dive into on IRC.
[20:44] <pitti> and any objections for the other provisional MREs to become blessed ones?
[20:44] <mdeslaur> not from me
[20:44] <infinity> And also doesn't have the "HWE" excuse going for it, so if it turns out to just completely suck, I doubt anyone would argue dropping the MRE.
[20:44] <infinity> I'm fine with the rest of the list.
[20:44] <pitti> ack
[20:45] <infinity> Maybe a quick scan through VLC crashes would be fun, but I bet it's mostly in underlying libraries and random corrupt media files, etc.
[20:45] <pitti> #agreed promote provisional MREs except LibO and mesa to permanent ones
[20:45] <infinity> Video playback software sucks.
[20:45] <pitti> (meh, neither all-caps nor #-ed ones work; go meetingology)
[20:45] <pitti> ah, right
[20:45] <pitti> I smell a volunteer
[20:45] <pitti> (I'll do the LibO ones in exchange)
[20:46] <infinity> Yeah, I'll have a hunt through a sampling of VLC crashes to confirm (or not) my suspicions there.
[20:46] <pitti> ACTION: infinity to review the vlc MRE bugs
[20:46] <pitti> ACTION: pitti to review the LibO MRE bugs
[20:47] <infinity> Did meetingology give up on life?
[20:47] <mdeslaur> meetingology: wake up
[20:47] <meetingology> mdeslaur: Error: "wake" is not a valid command.
[20:47] <pitti> #halp
[20:47] <infinity> Oh, that should be "#action <blah>"
[20:47] <pitti> I get nothign back in privmsg
[20:47] <infinity> #action pitti to follow up with Maarten wrt. mesa MRE
[20:47] <meetingology> ACTION: pitti to follow up with Maarten wrt. mesa MRE
[20:47] <infinity> Etc.
[20:48] <pitti> yes, but #agreed didn't work either
[20:48] <pitti> anyway, I don't really use that; the real IRC log is fine
[20:48] <infinity> Heh.
[20:48] <pitti> #topic community bugs
[20:48] <pitti> zarro
[20:48] <infinity> Our community is bug-free?
[20:48] <pitti> nothing new on the ML either
[20:49] <pitti> I privmsg'ed kees about meeting time
[20:49] <pitti> #topic AOB
[20:49] <pitti> nothing from me; infinity, mdeslaur?
[20:49] <pitti> 10
[20:49] <mdeslaur> nope
[20:49] <pitti> 5
[20:49] <infinity> I'm good.
[20:50] <pitti> 0 :)
[20:50] <pitti> great
[20:50] <infinity> Not like we have quorum anyway. :P
[20:50] <pitti> so, c'est l'heure de dormier
[20:50] <pitti> thanks and good night! will do the reporting stuff tomorrow morning
[20:50] <mdeslaur> thanks pitti, infinity!
[20:50] <pitti> err, "dormir"
[20:51] <pitti> français est trop difficile
[20:51] <pitti> #endmeeting
[20:51] <meetingology> Meeting ended Mon May 12 20:51:45 2014 UTC.
[20:51] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2014/ubuntu-meeting.2014-05-12-20.12.moin.txt