[16:32] <jdstrand> hi!
[16:32] <tyhicks> hello!
[16:32] <mdeslaur> \o
[16:32] <chrisccoulson> hi!
[16:32] <mdeslaur> hiya chrisccoulson!
[16:32] <chrisccoulson> hi mdeslaur
[16:32] <jjohansen> hey
[16:32] <jdstrand> #startmeeting
[16:32] <meetingology> Meeting started Mon Jan  6 16:32:59 2014 UTC.  The chair is jdstrand. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:32] <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
[16:33] <jdstrand> The meeting agenda can be found at:
[16:33] <jdstrand> [LINK] https://wiki.ubuntu.com/SecurityTeam/Meeting
[16:33] <jdstrand> [TOPIC] Announcements
[16:33] <jdstrand> Happy new year! Welcome back and I hope everyone had a nice break :)
[16:33] <mdeslaur> happy new year!
[16:33] <jdstrand> thanks to Jonathan Riddell (Riddell) provided debdiffs for precise-saucy for qt4-x11 (LP: #1259577)
[16:34] <jdstrand> thanks to Jonathan Riddell (Riddell) provided debdiffs for raring-saucy for qtbase-opensource-src (LP: #1259577)
[16:34] <jdstrand> thanks to Stefan Bader (smb) provided debdiffs for precise-saucy for xen
[16:34] <jdstrand> Your work is very much appreciated and will keep Ubuntu users secure. Great job! :)"
[16:35]  * Riddell bows
[16:35] <jdstrand> heh :)
[16:35] <jdstrand> [TOPIC] Weekly stand-up report
[16:35] <jdstrand> I'll go first
[16:36] <jdstrand> I'm apparently in the happy place this week. not sure how I got here, but I'll take it :)
[16:36] <mdeslaur> jdstrand: you won the dice roll :)
[16:36] <chrisccoulson> congratulations!
[16:36] <jdstrand> I have pending updates and work items, though most of the beginning of this week will be working on going through my holiday backlog
[16:36] <jdstrand> \o/
[16:36] <jdstrand> mdeslaur: you're next
[16:36] <mdeslaur> I'm on triage this week
[16:37] <mdeslaur> I have a couple of pending updates I'm testing which should get released this week
[16:37] <mdeslaur> like puppet this afternoon probably
[16:37] <mdeslaur> I also have some catching up to do
[16:37] <mdeslaur> and I think I'm on patch piloting on friday
[16:37] <mdeslaur> that's about it
[16:37] <mdeslaur> sbeattie: you're up
[16:37] <sbeattie> I'm on apparmor again this week
[16:38] <sbeattie> I need to sync up with jjohansen on IPC stuff
[16:38] <sbeattie> I also need to review his dfa minimization patch (and the bug fix for the issue it exposed) as it gives a pretty big policy compilation win.
[16:39] <mdeslaur> oh cool...do we know how big?
[16:39] <jjohansen> it varies with the dfa
[16:39] <jjohansen> but there are several examples
[16:40] <sbeattie> another 20%-ish gain, though for certain things like the evince profile with likewise-open variables added, it shaves 50-60% off of compilation time.
[16:40] <jdstrand> that is the one that doesn't do much for the click apps, correct?
[16:40] <mdeslaur> oh, nice!
[16:40] <sbeattie> (23 seconds down to 9 seconds or so)
[16:40] <jdstrand> or was that something else?
[16:40] <sbeattie> (on my laptop)
[16:40] <jdstrand> btw, these compilation speedups are truly awesome :)
[16:40] <sbeattie> jdstrand: yeah, I didn't see much gain for the click profiles you posted to the list.
[16:40] <jdstrand> ok
[16:41] <jjohansen> jdstrand: no, that is a different one, this one does a little more for the click apps
[16:41] <jdstrand> we got big gains on them in the previously patches though
[16:41] <jdstrand> ah
[16:41] <jjohansen> weather applet profile from ubuntu touch    0.618s   105673 bytes  to    0.432s   89300 bytes
[16:41] <sbeattie> jjohansen: oh? Maybe I'm confused.
[16:41] <jdstrand> well, good :)
[16:41]  * sbeattie kicks monday
[16:41] <sbeattie> anyway, I have some other stuff to catch up on as well.
[16:41] <jjohansen> not a huge improvement but better than the diff-encode which did almost nothin
[16:41] <tyhicks> that improvement should be pretty nice on ARM :)
[16:42] <jdstrand> yeah
[16:42] <jdstrand> and the emulator
[16:42] <tyhicks> good point
[16:42] <sbeattie> Anyway, that's all I have. tyhicks, you're up.
[16:42] <tyhicks> I'm playing catch up this morning
[16:43] <tyhicks> I was disconnected nearly the entire break
[16:43] <tyhicks> I've gotten through most email - the big thread that is coming up next is the kdbus thread
[16:43] <tyhicks> I've got to tie up some loose ends from before the holiday
[16:44] <tyhicks> benchmarking ext4 and ecryptfs on ARM is done - I need to figure out how best to do a LUKS-based partition
[16:44] <jdstrand> nice
[16:44] <mdeslaur> tyhicks: good luck with the kdbus thread
[16:45] <jdstrand> so, since kdbus lit up over the holidays, it occurred to me that it might be wise to send up our apparmor patches to the dbus mailing list
[16:45] <tyhicks> jdstrand: that would be good
[16:45] <jdstrand> that said, I am a few days our of date on said thread
[16:46] <tyhicks> I've kept them in an upstreamable form in our dbus package, so it shouldn't be much work for me to get them organized and sent out
[16:46] <jdstrand> while not completely unsurprised, the tenor of the mailing list discussion is considerably different than what I thought we had with kdbus upstream at plumbers
[16:47] <tyhicks> we only spoke with gregkh at plumbers and I don't think he's been involved in the thread
[16:47] <jdstrand> again, I am out of date, but it seems clear we need to continue having these discussions
[16:47] <tyhicks> agreed
[16:47] <jdstrand> (and thanks to mdeslaur for responding over the holidays)
[16:47] <tyhicks> I'm a little blocked on sending out the yama and config patches for Touch because I don't have a device to run the autopilot tests on (and the emulator doesn't seem to work, either)
[16:48] <jdstrand> tyhicks: what devices do you need?
[16:49] <tyhicks> jdstrand: umm... any of the better supported devices
[16:49] <jdstrand> tyhicks: so, you have grouper? it tests ok there?
[16:49] <tyhicks> jdstrand: I have grouper but that's the old kernel that requires a complete yama backport, which I didn't do
[16:49] <jdstrand> ah
[16:50] <jdstrand> so you need manta and mako, correct?
[16:50] <tyhicks> yes, those would be best
[16:50] <jdstrand> perhaps you could provide test instructions to jjohansen and chrisccoulson, and they can each do one?
[16:50] <tyhicks> ok
[16:51] <tyhicks> I can do that
[16:51] <jdstrand> I have a mako and am running trusty, but it is my dogfood device so I'd rather not break it :) that said, if it is helpful, you can give me the instructions too
[16:51] <tyhicks> it will also probably be a bit of an issue for user data encryption
[16:52] <tyhicks> I'll follow up with the team when I have debs and instructions
[16:52] <tyhicks> that'll probably keep me busy for this week
[16:52] <tyhicks> that's it for me
[16:52] <tyhicks> jjohansen: you're up
[16:52] <jjohansen> well it looks like I'll be testing for tyhicks this week ;)
[16:53] <tyhicks> jjohansen: you're the lucky guy with all the hardware :)
[16:53] <jdstrand> hopefully it will be nearly automatable
[16:53] <jjohansen> there is some catch up to do from vacation and then its back to apparmor
[16:53] <mdeslaur> \m/ AppArmor rocks! \m/
[16:53] <jdstrand> \m/ *rock* \m/
[16:54] <jjohansen> I've got the rest of the dfa stuff I need to push out so that we can start build some new tests
[16:54] <ogra_> that gives metal as a service a totally new meaning
[16:54] <mdeslaur> hehe
[16:54] <sarnold> good idea!
[16:54] <jjohansen> haha
[16:55] <jjohansen> and there is of course the outstanding ipc work
[16:56] <jjohansen> and coordination with sbeattie on tests there
[16:56] <jjohansen> and probably more bludgeoning of ones self against a certain thread
[16:58] <mdeslaur> hehe
[16:58] <jjohansen> I think thats it from /me sarnold your up
[16:58] <jdstrand> jjohansen: oh, thank you for also responding to the thread over the holiday
[16:59] <jdstrand> like I said, I am behind and didn't see that part of the thread
[16:59]  * jjohansen is only sorry he didn't get to it earlier, but then again Amanda would have made /me even sorrier to have responded earlier
[16:59] <jdstrand> heh
[17:00] <jdstrand> we got some responses out-- I think we are ok :)
[17:00] <sarnold> I'm on community this week, it's been a while since I've checked in on email, so I'll have a fair amount of digging-out to be done this week. but don't let that deter anyone from sending in patches :) I know there's some MIR audits needing attention, some old and some new, and iirc some apparmor patches needing review
[17:01] <sarnold> I suspect that'll be the week, but it's getting around time to dust off the old objectives and see how those are going.
[17:02] <sarnold> I think that's it for me, chrisccoulson?
[17:02] <chrisccoulson> hi :)
[17:02] <chrisccoulson> so, i left for vacation with a saucy build of oxide on arm which didn't work, and an attempted build for trusty which didn't succeed ;)
[17:02] <chrisccoulson> i'm fixing those this week
[17:03] <chrisccoulson> i started work over the holiday to remove the run-time dependency on X, which I need to do to make it work on ubuntu touch in any case
[17:04] <chrisccoulson> i don't think there's anything else from me
[17:04] <jdstrand> [TOPIC] Highlighted packages
[17:05] <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.
[17:05] <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.
[17:05] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/pyfribidi.html
[17:05] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/graphite2.html
[17:05] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/libjgroups-java.html
[17:05] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/sleuthkit.html
[17:05] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/mc.html
[17:05] <jdstrand> [TOPIC] Miscellaneous and Questions
[17:05] <jdstrand> Does anyone have any other questions or items to discuss?
[17:08] <jdstrand> mdeslaur, sbeattie, tyhicks, jjohansen, sarnold, ChrisCoulson: thanks!
[17:08] <jdstrand> #endmeeting
[17:08] <meetingology> Meeting ended Mon Jan  6 17:08:39 2014 UTC.
[17:08] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2014/ubuntu-meeting.2014-01-06-16.32.moin.txt
[17:08] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2014/ubuntu-meeting.2014-01-06-16.32.html
[17:08] <mdeslaur> thanks jdstrand!
[17:08] <tyhicks> thanks!
[17:09] <jjohansen> thanks jdstrand
[17:09] <sbeattie> jdstrand: thanks!
[17:10] <sarnold> thanks jdstrand !
[20:59]  * slangasek waves
[21:00] <mdeslaur> o/
[21:00] <infinity> \o
[21:00]  * stgraber waves
[21:01] <slangasek> so, ah - who's in charge? :)
[21:03] <infinity> No idea!
[21:03] <sabdfl> hello folks
[21:03]  * slangasek waves to sabdfl 
[21:03] <sabdfl> evening slangasek
[21:03] <slangasek> I nominate stgraber to chair, since he's here and knows the ropes :)
[21:03] <stgraber> well, we haven't had a meeting in ages, so I think we lost track :)
[21:03] <sabdfl> defrost the book, shall we?
[21:03] <stgraber> #startmeeting Technical Board meeting
[21:03] <meetingology> Meeting started Mon Jan  6 21:03:45 2014 UTC.  The chair is stgraber. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[21:03] <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:04] <stgraber> #topic Action review
[21:04] <stgraber> The last action we had was to get a new TB, which we now have, so I'll drop that one from the agenda!
[21:04] <mdeslaur> \o/
[21:06] <stgraber> now as for meeting chair, I'd suggest we stick to what we used to do, which is to simply go through https://launchpad.net/~techboard/+members
[21:06] <sabdfl> it's late in Cape Town, so i'll just say welcome to the new TB, and thanks
[21:06] <stgraber> so the next meeting chair (20th of January 21 London time) will be infinity
[21:06] <infinity> I'll be sure to hire a secretary before then.
[21:07]  * stgraber tries updating the wiki, gives up (taking way too long) and gets back to the meeting
[21:08] <stgraber> #topic Review our current "provisional" Micro Release Exceptions
[21:08] <slangasek> is there a current list?
[21:08] <stgraber> My vague memory of this is that kees was taking a look at our list of privisional MREs on the wiki and suggesting which should be made permanent exceptions and which should be dropped (because of bad results or because they weren't used)
[21:09] <stgraber> https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
[21:09] <slangasek> ok
[21:10] <slangasek> should we carry this over, since kees isn't here?
[21:10] <stgraber> yep, I believe it was an ongoing thing anyway as it required input from some SRU team members and also from errors.u.c stats (bdmurray)
[21:10] <stgraber> #topic Requiring TB members to be Ubuntu core developers [micahg]
[21:10] <stgraber> micahg_: around by any chance?
[21:11] <slangasek> I know I saw discussion of this on list
[21:11] <infinity> This would be slightly less contentious now that it happens to be true.
[21:11] <slangasek> which makes sense, it was a timely topic before the election, not so much now ;)
[21:12]  * stgraber quickly reads the ML thread again
[21:12] <slangasek> infinity: well, I think there was not consensus about this principle
[21:12] <infinity> slangasek: No, indeed, I can see the argument for people who prefer to recuse themselves to limit upload rights, etc.
[21:13] <slangasek> one of the points made was that if the developers at large hold someone who's not core-dev in such esteem that they choose to elect them to the TB, that it doesn't make sense to block them with a formal rule
[21:13] <infinity> Though, the spirit of the thing--if you're not qualified to be a core-dev, you're not qualified to be on the TB--is likely not contentious.
[21:13] <slangasek> right
[21:13] <sabdfl> i think it was well intentioned but not a sensible constraint
[21:14] <sabdfl> we have good checks and balances in the nomination / voting process already
[21:14] <slangasek> I tend to agree - given that only core-devs were elected this time around (and, IIRC, only core-devs stood for election), this seems like a non-issue and we're better of keeping the status quo
[21:14] <infinity> I think what we're really looking for here is a veto to prevent accidentally electing incompetents, and Mark already holds that power.
[21:14] <sabdfl> and i'd prefer to retain the flexibility that offers
[21:14] <slangasek> s/of/off/
[21:15] <sabdfl> infinity, as do the voting pool in case I make a bum nomination
[21:15] <infinity> sabdfl: ;)
[21:15] <stgraber> status quo seems reasonable to me. I think we should always ensure that the candidate pool is big enough that we don't end up in a situation where the voters have no choice but to elect a non-coredev (or non-developer) but I don't think we need to create policy around that
[21:16] <sabdfl> i thought i replied to micah and cc'd the TB?
[21:16] <mdeslaur> I also agree to the status quo
[21:16] <stgraber> sabdfl: you did
[21:16] <mdeslaur> yes, https://lists.ubuntu.com/archives/technical-board/2013-October/001741.html
[21:16] <slangasek> sabdfl: yes, you did, but then the TB dissolved and there was no formal decision so it was left on the agenda :)
[21:16] <kees> whoops, here now.
[21:16] <slangasek> so, I +1 sabdfl's position
[21:17] <infinity> +1 here too, the status quo seems to be serving well.
[21:17] <mdeslaur> +1
[21:18] <slangasek> (do we want an actual #vote?)
[21:18] <kees> +1. anyone who ends up on TB and isn't core-dev should probably go about getting it. :)
[21:18] <mdeslaur> whoops :)
[21:18] <stgraber> sounds like we have an agreement both from those of the old TB who spoke up on the ML and the current TB to retain status quo, I don't see the need for a formal vote
[21:18] <slangasek> ok
[21:18] <infinity> I've considered a similar topic from the POV of archive/sru teams (which I'll bring up another time), but that was more about archive rights, this isn't.
[21:18] <infinity> (If being on the TB automatically gave you rights to insert packages in the archive, then the core-dev argument would have weight)
[21:19] <stgraber> infinity: being on the TB gives you the technical ability to grant any ACL you wish including any queue privileges and upload privileges
[21:20] <infinity> Let's pretend you didn't say that for now.
[21:20] <mdeslaur> heh
[21:20] <sabdfl> being on the TB suggests you understand the responsibilities, including ACLs
[21:21]  * infinity nods.
[21:22] <slangasek> ok, what else?
[21:22] <stgraber> yep, and it's the same thing we have with the DMB where the DMB is the admin of ~core-dev but we used to have non-coredev members on the board.
[21:22] <slangasek> do we want to double back on the MRE question now that kees is here?
[21:23] <stgraber> kees: hey, so I vaguely remember you were the one looking at those provisional MREs, do you have anything new to share? do we still have some to review at this point? or should that agenda item be dropped for now?
[21:23] <kees> answer is "it's been very time-consuming to evaluate the history of MREs actually executed", and I've been very slowly working on it.
[21:23] <kees> mainly I wanted to do it to kick out any MREs that had 0 (or an arbitrarily small number of) SRUs
[21:24] <sabdfl> do we need a log of those, say a wiki page or set of them, to make such analysis easier in future?
[21:24] <kees> in theory, it should be possible to extract them from LP, and I have a script started to do it, but it had a lot of corner cases.
[21:24] <infinity> +publishinghistory for the source packages in question should be log enough.
[21:24] <sabdfl> i.e. update the process to include a note on that page... ok
[21:25] <kees> infinity: the trouble was ignoring security updates, etc
[21:25] <sabdfl> automated would be better, for sure
[21:25] <slangasek> security updates should be automatically detectable by version number, I guess?
[21:25] <stgraber> and probably also dealing with renamed sources (we used to have a few X packages with provisional MREs)
[21:25] <slangasek> (it's only using the MRE if the upstream version number changes)
[21:25] <kees> slangasek: version number for security updates is the same as that for SRU
[21:25] <infinity> kees: Not the upstream part.
[21:26] <kees> slangasek: eh, that hasn't always been true I don't think.
[21:26] <kees> slangasek: but worth double-checking
[21:26] <mdeslaur> well, it's likely a rare exception if it's happened before
[21:26] <stgraber> slangasek: hmm, someone could upload the same new upstream release as say the dev series and use ubuntu0.1 in that case
[21:26] <stgraber> slangasek: that'd still be a MRE and would have a security-like version number
[21:26] <slangasek> kees: really?  I would be very concerned with anyone using an MRE as a justification for cherry-picking patches instead of pulling a new upstream release
[21:27] <stgraber> though indeed, detecting a bump of the upstream version number should work in most cases
[21:27] <slangasek> stgraber: yes, but the upstream version number in the SRU would be different than the version in the release pocket
[21:27] <infinity> stgraber: His point was that the upstream version changed in the series in question, you can ignore the Debian revision entirely.
[21:28] <kees> here's what I put together: http://bazaar.launchpad.net/~ubuntu-security/ubuntu-cve-tracker/master/view/head:/scripts/pmre-report
[21:29] <kees> on top of just the SRU checking was how many errors/bugs were being filed
[21:29] <kees> (using errors.ubuntu.com)
[21:29] <kees> but that doesn't seem to catch much server stuff
[21:29] <mdeslaur> likely none at all :P
[21:29] <kees> right
[21:29] <kees> so answering the second question "is it causing more bugs?" has been tricky as well.
[21:31] <mdeslaur> if something introduced a bug that was serious enough to get fixed, you'd likely see another upload with the same upstream version number
[21:31] <infinity> Not fool-proof, as that could just be a regular SRU fixing a bug that's existed for years.
[21:31] <mdeslaur> yes, agreed
[21:32] <infinity> But a decent starting point to get a computer to do the grunt work.
[21:32] <kees> now you all feel my pain. :)
[21:32] <mdeslaur> hehe
[21:32] <kees> I think for future pMREs, we should set a specific and trivially measureable "this MRE is working" measurement
[21:33] <slangasek> that makes sense to me; why should the TB spend its time approving a provisional MRE if it's not going to be used
[21:33] <kees> yeah
[21:33] <stgraber> sounds reasonable
[21:33] <slangasek> so we ought to be able to follow up on each pMRE within a month or two of it being originally granted
[21:33] <infinity> Pretty hard to measure.  Since the success of an MRE SRU is "it fixes more bugs than it introduces" and there may not be bugs for all the upstream issues it fixes.
[21:33] <infinity> But if the MRE isn't being used at all, sure, that's clearly not a success.
[21:34] <slangasek> infinity: hmm, I don't consider that the right metric for success
[21:34] <stgraber> kees: do you know or can easily check whether we have obviously unused pMREs? those would be obvious candidates for revocation at least
[21:34] <kees> well, it's a measure of failure
[21:34] <kees> stgraber: I'll make that the new goal :)
[21:34] <infinity> slangasek: Well, the best possible outcome is "it introduces no new bugs", but I'm not that naive.
[21:34] <slangasek> I think MREs aren't different from regular SRUs because we delegate the QA to upstream, not because they're held to a different standard of correctness
[21:35] <slangasek> s/aren't/are/
[21:35] <infinity> Sure, we hold them to the same level of quality, to a degree.  I'm just not naive enough to belive that thousands of lines of changes in mesa couldn't possibly cause a bug while fixing 10.
[21:35] <slangasek> so, I think any MRE that introduces new bugs is one that should be examined carefully - though I think I'm speaking now with my SRU team hat, and don't necessarily think the TB should have to worry about micromanaging this
[21:36] <infinity> (Those bugs should be fixed when found, but they'll be there because humans)
[21:36] <kees> anyway, I'll get a report of "unused MRE" together. that seems simpler.
[21:37] <stgraber> yep, that'd be a good start
[21:37] <stgraber> #action kees to get a list of unused provisional Micro Release Exceptions
[21:37] <meetingology> ACTION: kees to get a list of unused provisional Micro Release Exceptions
[21:39] <stgraber> I think we could probably solve a lot of our concerns by giving a strict period of time during which the provisional MRE is valid and contacting the SRU team about that MRE immediately after approval. If it's only provisional for say 3 months, SRU team members should be able to remember it and be able to give us some feedback when comes the time to make it a permanent MRE.
[21:40] <kees> seems reasonable. means we'll need SRU team involvement in TB meetings
[21:40] <stgraber> I don't want to offload the whole review process to the SRU team, but realistically they are the ones who see all uploads and get subscribed to all tracking bugs, so if we have a sufficiently short list of pMREs, it shouldn't be too hard for them to spot problems with those.
[21:41] <slangasek> kees: we sorta handled that with the last election ;P
[21:41] <kees> slangasek: heh, good point
[21:41] <kees> yay for power consolidation!
[21:42] <infinity> WCPGW?
[21:42] <kees> :)
[21:42] <slangasek> I'm assuming that's Canadian for "one ring to rule them all"
[21:43] <infinity> More or less.
[21:43] <kees> What Could Possibly Go Wrong
[21:43] <mdeslaur> hehe
[21:43] <stgraber> anyway, let's move on :)
[21:43] <stgraber> #topic Scan the mailing list archive for anything we missed (standing item)
[21:44] <slangasek> the only thread I've spotted that seems like we might need to revisit is this one: https://lists.ubuntu.com/archives/technical-board/2013-November/001750.html
[21:44] <slangasek> (SmartScopes)
[21:44] <slangasek> there's also the currently ongoing discussion of hibernate support, dunno if we should discuss that here or just continue on the list?
[21:45] <sabdfl> sorry, forced reboot
[21:45] <kees> slangasek: I say leave hibernation on the list
[21:45] <slangasek> oh, also this one: https://lists.ubuntu.com/archives/technical-board/2013-October/001737.html
[21:46] <stgraber> hmm, I'll have to re-check but I think the libdrm, ... stuff was uploaded (possibly without the MRE)
[21:46] <infinity> I believe it was.
[21:47] <kees> yeah, if it was already done, I say give it a pMRE and recheck in 3 mon
[21:47] <stgraber> yeah, it was and I released some of those to -updates today.
[21:47] <infinity> I believe I pointed out that it didn't need a standing MRE to do a one-time update.
[21:47] <kees> as for smartscope, I don't think that has anything at all to do with the Ubuntu TB. That's all Canonical.
[21:49] <slangasek> infinity, stgraber: right, so it seems RAOF was satisfied that the updates were of sufficiently low risk that he took them with his SRU hat on; no need for an MRE then AFAICS
[21:50] <slangasek> kees: so, you don't think the TB should have a response to the smartscopes question?
[21:50] <stgraber> yeah, in the past I've been granting one-time-use MREs for those (granted and removed from the wiki a couple of days later), so I don't think we have to do anything for those now that they were uploaded
[21:50] <stgraber> (as they are unlikely to get an upstream version bump again)
[21:50] <slangasek> there is an Ubuntu governance question here, which is "is it ok to have features in Ubuntu that depend on closed server-side software"
[21:50] <kees> slangasek: I mean there's nothing TB can do but ask for source too.
[21:50] <infinity> It's not really in the TB's mandate to dictate Canonical software licensing issues.
[21:51] <infinity> I suppose, yes, we could say the scopes aren't suitable for main because they depend on non-free services.
[21:51] <kees> +1
[21:51] <kees> (but everyone knows how I feel)
[21:52] <mdeslaur> so do we get rid of weather applets, the google search box, the flickr integration, etc too?
[21:52] <slangasek> I don't think that's what I would be inclined to say, any more than I would say that using google as the default search engine in the browser isn't suitable because it's a non-free service
[21:52] <slangasek> mdeslaur: right
[21:52] <stgraber> well, the TB could potentially rule that it's not acceptable for core features of our desktop to depend on a closed server and then let Canonical choose to go without the feature or to make the server open source
[21:52] <slangasek> stgraber: (or get us vetoed by sabdfl ;)
[21:52] <stgraber> slangasek: or that :)
[21:53] <infinity> Sure, I didn't mean we would say that, just that that's an option here.  Unlike dictating licensing, which is not an option.
[21:53] <slangasek> anyway, I think it would be better for us to answer that clearly rather than ignoring the question
[21:53] <slangasek> but not in the next 7 minutes
[21:54] <stgraber> so is that something we should deal with on the list or does someone want to bring it up as an agenda item for the next meeting?
[21:54] <slangasek> I'd say list for now
[21:54] <stgraber> sounds good to me
[21:54] <infinity> I don't think there's anything inherently wrong about shipping clients for non-free services (we have tons of them), but it does seem a bit wrong to have them as part of the core desktop experience.
[21:55] <stgraber> ok, moving on then
[21:55] <stgraber> #topic Check up on community bugs (standing item)
[21:55] <stgraber> "
[21:55] <stgraber> There are currently no open bugs.
[21:55] <stgraber> "
[21:55] <infinity> \o/
[21:55] <stgraber> #topic Select a chair for the next meeting
[21:56] <stgraber> that'll be infinity (and I've updated the agenda to hopefully make it clear as to how we choose the chair)
[21:56] <stgraber> #topic AOB
[21:57] <stgraber> maybe just one quick questions for the new members, does the current meeting time work for everyone? every two weeks on Monday at 21 London time (so we move with UK DST)
[21:57] <infinity> Works well enough for me.
[21:57] <infinity> Monday is my "get no useful work done" day.
[21:57] <slangasek> it actually overlaps with a call for infinity and me
[21:57] <slangasek> which he seems to be casually trying to get out of ;)
[21:57] <infinity> Well, there's that call, yes.  But that won't last forever.
[21:57] <mdeslaur> wfm
[21:58] <infinity> We could wiggle the TB meeting 30m later for a few months, if no one (nor the Fridge) objected.
[21:59] <stgraber> I suspect pitti would object as the current meeting time is already quite late for him
[21:59] <mdeslaur> hrm
[21:59] <slangasek> yeah, that makes it later for both sabdfl and pitti
[21:59] <infinity> We had no problems forcing our previous call to 30m, I'm sure we can keep juggling those for a while until it stops.
[22:00] <sabdfl> i am not a regular attendee so  don't block on me if that suits you better
[22:00] <slangasek> today's call naturally ended 30m early with no prompting :)
[22:00] <slangasek> anyway, scheduling is hard
[22:01] <slangasek> so we can just keep the meeting where it is, with the knowledge that infinity and I may be late from time to time for the next couple of months
[22:01] <infinity> But fashionably so.
[22:02] <stgraber> sounds good. We still have quorum without you two and while we shouldn't depend on it, I suspect you're both capable of multi-tasking a bit if needed :)
[22:02] <mdeslaur> sounds good to me
[22:02] <stgraber> and with that settled
[22:02] <stgraber> #endmeeting
[22:02] <meetingology> Meeting ended Mon Jan  6 22:02:50 2014 UTC.
[22:02] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2014/ubuntu-meeting.2014-01-06-21.03.moin.txt
[22:02] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2014/ubuntu-meeting.2014-01-06-21.03.html
[22:03] <slangasek> stgraber: thanks for chairing
[22:03] <infinity> Ta.
[22:03] <stgraber> next meeting will be on the 20th at 21:00 UTC with infinity chairing (or kees if infinity doesn't make it on time)
[22:03] <kees> thanks!
[22:03] <infinity> Way to motivate me to be late.
[22:03] <mdeslaur> thanks!
[22:03] <kees> heh