[11:42] <xnox> Laney: =))) i'll be that another person nagging about FFes, can you take a look at bug #1292458 and check if it at all requires FFe or not.
[11:42] <ubot2> Launchpad bug 1292458 in plymouth (Ubuntu) "[FFe] a bunch of updates to plymouth" [Undecided,New] https://launchpad.net/bugs/1292458
[11:42] <Laney> xnox: swap for you looking at that cmake patch
[11:42] <xnox> Laney: there are a few changes, some bigger than others, but it is mostly code cleanup and long standing (upstart) bug fixing.
[11:43] <xnox> Laney: the one building on the buildds? https://launchpad.net/ubuntu/+source/cmake/2.8.12.2-0ubuntu3 =)))
[11:43] <Laney> damn
[11:43] <Laney> swap for you reviewing libtimezonemap MPs!
[11:43] <xnox> shoot, yeah, I have installer work to do before going away for a week.
[11:44]  * xnox is not looking forward to trying to force ubiquity to use "Beijing and Montreal" instead of "Shanghai and Toronto"
[11:45]  * Laney hands xnox dch --maintmaint
[11:46] <xnox> Laney: *sigh* so in debian they tell me _not_ to use --maintmaint, and in ubuntu i should....
[11:46] <xnox> Laney: the whole trailer line is pointless, we should have no name there, and only multi maintainer changelog lines.
[11:46] <Laney> haha
[11:47] <Laney> It'd have meant that I got emailed when you uploaded it :P
[11:47] <Laney> anyway, I think those fixes are arguably bug fix
[11:47] <xnox> Laney: but i had to maintain the information miss-balance to trick you into reviewing my FFe ;-)
[11:47] <Laney> If that set of reviewers all approve it then do it
[11:48] <Laney> or some decent subset of them anyway, what evs
[11:48] <xnox> Laney: *evil* =) well jodh reviewed unofficially but pointed at cjwatson. slangasek is very busy at the moment. Right.
[11:57] <xnox> ..
[11:59] <xnox> infinity: ^ is an empty package =) just depends on sources of others and compiles toolchain for x86-bionic/android needed to start building x86 emulator images. (covered by touch FFe)
[12:00] <xnox> with correct target component ^
[12:13] <knome> stgraber, as promised: bug 1294619
[12:13] <ubot2> Launchpad bug 1294619 in ubiquity-slideshow-ubuntu (Ubuntu) "[UIFe] Update the Ubiquity slideshow (Xubuntu)" [Undecided,New] https://launchpad.net/bugs/1294619
[12:13] <knome> stgraber, subscribing the release team whatsoever. :)
[12:41] <ginggs> Hi release team, anyone able to look at a FFe please? LP: #1289463
[12:41] <ubot2> Launchpad bug 1289463 in starpu-contrib (Ubuntu) "[FFe] Merge nvidia-cuda-toolkit 5.5 from Debian, transition to libcuda 5.5" [Undecided,New] https://launchpad.net/bugs/1289463
[13:02] <stgraber> knome: approved. Let me know when it's all done, I'll make sure your and zequence changes are all in there and will upload a new version.
[13:05] <ScottK> I'll self reject ^^^
[13:13] <knome> stgraber, we're done with xubuntu for good :)
[13:13] <knome> stgraber, all of it is in the branch
[13:13] <knome> want me to merge?
[13:15] <stgraber> knome: yep, go ahead
[13:16] <ScottK> Riddell: ^^^
[13:16] <Riddell> awooga
[13:17] <Riddell> thanks ScottK
[13:17] <caribou> ScottK: what's wrong with the clamav ?
[13:18] <ScottK> Uploaded for the wrong release.
[13:18] <knome> stgraber, done
[13:18] <caribou> ScottK: ah, ok
[13:41] <mlankhorst> oops
[13:41] <mlankhorst> did I upload that git snapshot to the archive? can it be removed? :P
[14:16] <Riddell> mlankhorst: snapshot of what?
[14:18] <mlankhorst> nm :
[14:20] <Riddell> mlankhorst: "network manager" or "never mind"?
[14:21] <mlankhorst> never mind :)
[14:21] <mlankhorst> uploaded mesa to ubuntu instead of a testing ppa
[19:31] <sergiusens> cjwatson, hey, can you take a look at https://bugs.launchpad.net/ubuntu/+bug/1290360 ?
[19:31] <ubot2> Launchpad bug 1290360 in Ubuntu "[FFe] New Ubuntu Touch specific package: media-hub" [Undecided,New]
[19:50] <seb128> stgraber, infinity, slangasek: can we get somebody reviewing https://launchpad.net/bugs/1293677 (sorry to ping but it feels like Laney has been picking up on most review and it feels wrong to keep piling on him because he has been responsive)
[19:50] <ubot2> Launchpad bug 1293677 in indicator-sound (Ubuntu) "FFE: Export data to accounts service" [Undecided,New]
[19:52] <infinity> How is this a desirable feature?
[19:52] <infinity> Having media player access from a greeter is an information leak.
[19:52] <infinity> It also means the greeter is reading the user's files.
[19:52] <infinity> I don't like the security implications in that.
[19:53] <infinity> jdstrand: Can you have someone in your team look at #1293677 and pronounce on whether or not it's crack?
[19:53] <infinity> jdstrand: Seems pretty sketchy to me to have the greeter peeking in on users.
[19:54] <infinity> (I realise this is pretty standard for phone lock screens, but phones are also traditionally single-user... And even then, it needs to be configurable to NOT do that)
[19:54] <jdstrand> I think mdeslaur might've been involved in those conversations. mdeslaur? ^
[19:56] <mdeslaur> I wasn't involved in those conversations, no
[19:56] <jdstrand> hmm, I wonder what I was thinking of
[19:56]  * jdstrand wasn't either
[19:56] <mdeslaur> Is there a design for this documented somewhere?
[19:57] <seb128> https://lists.launchpad.net/ubuntu-phone/msg06773.html
[19:57] <jdstrand> I don't know-- my first hearing of this was 30 seconds before you
[19:57] <seb128> do we go back to that discussion?
[19:57] <seb128> that's for the phone and to have e.g the current playing song on the user lock screen
[19:57] <jdstrand> I remember volume controls
[19:58] <mdeslaur> seb128: is there a design document somewhere that we can review?
[19:58] <seb128> well, unity8 wants to share stuff like what is playing
[19:59] <seb128> notifications (I think)
[19:59] <seb128> e.g what you would expect to be able to do on your phone from the lock screen
[19:59] <mdeslaur> right, but lock screen != greeter
[19:59] <seb128> on the phone not
[19:59] <jdstrand> conceptually, I don't think this is a privacy issue cause if the music is playing, you can hear it
[20:00]  * jdstrand is talking about displaying the info generally
[20:00] <mdeslaur> right, but the bug mentions "controlling the media player"
[20:00] <seb128> mdeslaur, we had that discussion on the desktop as well
[20:00] <stgraber> jdstrand: it really depends on what's the scope of this, if you can skip songs from the greeter, then you can access information which you wouldn't see otherwise
[20:01] <seb128> if a song is playing, should you be able to pause it from the lock screen?
[20:01] <jdstrand> true
[20:01] <seb128> oh, a ted_
[20:01] <ted_> Woot!
[20:01] <seb128> ted_, hey
[20:01] <ted_> This IRC protocol is too complex
[20:01] <jdstrand> but if you let it keep going, you'll eventually get to it :) that said, I could see how people would prefer that to be togglable
[20:01] <seb128> so, people want a link to a design spec for the greeter, to see what info are going to end up there
[20:02] <ted_> It's actually in the individual indicator specs.
[20:02] <mdeslaur> the bug is kind of unclear on what exactly is involved from a technical point of vue...
[20:02] <mdeslaur> ted_: can you add some links to the bug, perhaps, so we know what we're agreeing on?
[20:03] <ted_> Sure. I mean are the MR's useful?
[20:03] <ted_> Or is that TMI?
[20:04] <ted_> For this one it's: Current Trackname, artist and album. Playername and icon. And volume/mute.
[20:05] <mdeslaur> sure, you can add those...but is there a document that explains the transition to using the greeter as a lock screen? it seems to me to be a pretty odd thing to do, with insurmountable problems
[20:05] <stgraber> jdstrand: ok, say moving back to the previously played song, that's not going to happen on its own ;)
[20:05] <seb128> mdeslaur, you have been commenting/arguing on that discussion on the list :p
[20:05] <jdstrand> stgraber: right, which is why I said I can understand why people might want it togglable
[20:05] <ted_> mdeslaur, That mterry's domain, let me see if there's something overarching.
[20:06] <mdeslaur> seb128: yes, I have been saying that the lock screen needs to be in the user session
[20:06] <seb128> right
[20:06] <mdeslaur> seb128: but I didn't follow the rest of the discussion
[20:06] <seb128> seems there are pro&con for each side, but the leading opinion is that greeter=lock is better
[20:07] <seb128> mterry and mpt tried to argue in that sense on the list
[20:07] <seb128> well, I'm unsure that adding the framework to indicator-sound to put datas in accountsservice should hold on the outcome of the greeter discussion
[20:07] <seb128> we already put stuff in a-s (e.g the background, or ringtone on the phone)
[20:08] <seb128> those changes only refactor the code to allow doing that (and to be testable with another backend), they don't include the actual user of the framework to publish specific info
[20:08] <mdeslaur> right, I don't mind commenting on a specific thing, such as indicator-sound putting stuff in accountsservice...it's further down the line that it's going to be complicated and there may be showstoppers
[20:09] <mdeslaur> like, how are you going to make the greeter be able to _control_ the media player?
[20:09] <seb128> right, I'm unsure the ubuntu-phone discussion came to a conclusion
[20:10] <seb128> yeah, I agree
[20:10] <seb128> the recent discussions made me thing that having the lock being in-session is maybe the best way
[20:10] <seb128> that has issues as well (mostly code duplication)
[20:10] <ted_> mdeslaur, So I think that if you've got issues you should try it, mterry is getting ready to land that. Instructions here: https://code.launchpad.net/~mterry/unity8/split/+merge/210664
[20:11] <ted_> mdeslaur, For signaling back we're using unity-greeter-session-broadcast. http://bazaar.launchpad.net/~indicator-applet-developers/unity-greeter-session-broadcast/trunk.14.04/view/head:/README
[20:12] <mdeslaur> ted_: ok, so the media player (or indicator-sound) is listening to broadcasts from the greeter on the system bus?
[20:13] <ted_> mdeslaur, Correct
[20:13] <ted_> mdeslaur, indicator-sound to be specific
[20:13] <ted_> mdeslaur, It then translates that to MPRIS
[20:13] <mdeslaur> ok, let me add that link to the bug, one sec
[20:14] <mdeslaur> ted_: do you have the indicator-sound/accountsservice MR somewhere?
[20:14] <seb128> mdeslaur, https://code.launchpad.net/indicator-sound/+activereviews
[20:15] <ted_> mdeslaur, And the greeter broadcast: https://code.launchpad.net/~ted/unity-greeter-session-broadcast/sound-control/+merge/208894
[20:17] <mdeslaur> ok, adding details to bug, one sec
[20:21]  * infinity has only been skimming backscroll...
[20:22] <infinity> mdeslaur: lockscreen in the user session is a huge broken no-no for desktop convergence, isn't it?  Unless the switch user bit still works sanely.
[20:23] <mdeslaur> infinity: sure it can work, it just needs to bump you back to the real greeter or something
[20:23] <mdeslaur> but there's two things here: 1- design, and 2- security...and a solution to both needs to be thought out
[20:23] <mdeslaur> anyway, I'm commenting on the bug now
[20:23] <infinity> ted_: How does any of this behave in a multi-user environment?  What if my roommate and I both lock the screen with an active playlist?  Does bouncing between our names on the greeter give us control to fight over each others' media players?
[20:24] <infinity> mdeslaur: I'm less concerned about design from the FFe perspective (though I may have lots of opinions), but mostly concerned about security.
[20:24] <mdeslaur> infinity: ok, go read my comment
[20:24] <infinity> Phones that display every damned thing on the lock screen without the option to remove all the data are fundamentally broken.  We shouldn't follow down that path.
[20:25] <ted_> infinity, Yes, but the reality is that today, on the desktop you both can't have the audio output. So it basically doesn't work unless logind changed the audio permissions based on the greeter.
[20:25] <mdeslaur> it gets complicated once you want home directory encryption
[20:25] <ted_> infinity, The way we end up getting around that on the phone is that the phablet user is in the audio group.
[20:25] <mdeslaur> ugh
[20:26] <ted_> The long term is that we'll have a subset of info on the lock screen. And options to reduce that subset.
[20:26] <ted_> This is kinda the first use case (mostly due to staffing) but it's a long term design pattern.
[20:27] <infinity> I'm cool with super-featurful and super-informative lockscreens, so long as I can turn every last bit of it off if I have a fine collection of tinfoil hats.
[20:27] <mdeslaur> ted_, seb128: can you read my comment in the bug and see if I've adequately understood it?
[20:27]  * ted_ refreshes
[20:27] <mdeslaur> infinity: yes, I completely agree, there needs to be a privacy switch for that stuff, which I've required in the bug
[20:28] <infinity> mdeslaur: And the assumption that "exposing song titles doesn't expose anything" isn't true.
[20:28] <mdeslaur> (hidden or exposed in the gui, whatever design prefers)
[20:28] <mdeslaur> infinity: well, if it's playing, it's minimal
[20:28] <mdeslaur> infinity: if you name your songs after your ex-girlfriends, you may want to flip the privacy switch
[20:29] <infinity> mdeslaur: You could have cool-song-from-my-girlfriend-anita.mp3 without ID3 tags playing, and the audio would be "Kickstart my Heart", but the info displayed is that you have a girlfriend named Anita.
[20:29] <mdeslaur> infinity: yes, I agree
[20:29] <ted_> infinity, Hopefully Anita is the only one reaching in your pocket to get your phone to find out ;-)
[20:30] <infinity> (Also, your girlfriend Anita has horrible musical taste dude, seriously.  Motly Crue?)
[20:30] <mdeslaur> just like you can have a wallpaper with personal information in it currently and it gets displayed in the greeter
[20:31] <infinity> ted_: I do hope that's entirely a joke.  I've met too many people who assume "phones don't need security because they're always on your person".
[20:31] <ted_> mdeslaur, Looks fine. I'm sure we do #1. I'll make sure to get #2 in.
[20:31] <infinity> s/assume/assert/
[20:31] <ted_> infinity, Yes, but generally they're more closely held devices than for instance a desktop in an office or server in the cloud.
[20:31] <mdeslaur> ted_: that's just my 2c, you still need to convince infinity not to name his mp3 based on his mood
[20:32] <infinity> mdeslaur: Well, #2 addresses my poor file naming schemes.
[20:32] <ted_> infinity, That doesn't mean "no security" but it means the defaults can be different.
[20:32] <infinity> So, assuming they do #2, I'm cool with it.
[20:32] <infinity> ted_: Absolutely agreed that the *defaults* on phones can, and arguably should, be different.
[20:33] <infinity> ted_: Just that they also need the facility to be locked down as hard as that corporate desktop.
[20:33] <mdeslaur> just having the song titles leak outside of the encrypted home directory may be an issue for some people, so the privacy toggle switch is important there
[20:33] <infinity> (And for Ubuntu, this is even more important, as we aim to make our phone our desktop and our desktop our phone)
[20:34] <ted_> I do agree.
[20:37] <infinity> Okay, bug commented on.
[20:40] <ted_> Thanks folks. Will make sure they're addressed.
[20:41] <mdeslaur> thanks ted_, infinity
[20:41] <ted_> Also, there's an open question of url-dispatcher being in the Touch FFE. It was proposed by slangasek to no objection, but didn't get in the list.
[20:41] <ted_> Can I just add it? Or do I need to do something there?
[20:42] <ted_> I think it's just an administrative oversight, but didn't feel like I could just edit the list :-)
[20:43] <infinity> ted_: Well, it's in a ton of desktop seeds, and an rdep of a bunch of indicators, but a restricted FFe demanding it doesn't break ABI would be fine by me.
[20:44] <infinity> ted_: If you need to break ABI, I'd probably want a separate FFe filed with impact analysis.
[20:45] <ted_> So, I agree, but I don't know how to express that, just "url-dispatcher (no ABI changes)" ?
[20:46] <infinity> ted_: Works for me.
[20:47] <ted_> infinity, Great, thanks!
[21:08] <slangasek> ted_: proposed *by* me?
[21:09] <ted_> slangasek, https://bugs.launchpad.net/ubuntu/+bug/1208989/comments/7
[21:09] <ubot2> Launchpad bug 1208989 in Ubuntu "[FFe] standing freeze exception for Ubuntu Touch-specific packages" [Undecided,Confirmed]
[21:10] <slangasek> ted_: when I made the comment in the bug log, it was in the context of "touch-specific"; this is now in the desktop seed
[21:10] <ted_> slangasek, It is touch specific though, we don't *use* it on the desktop, it gets pulled in by converged indicators that use it on touch.
[21:11] <ted_> I'd have to check, but I think only the lib gets pulled in, not the service.
[21:11] <slangasek> yeah, just confirmed that
[21:12] <slangasek> so if we're sure that lib isn't used except on touch, then yeah, that all sounds reasonable
[21:12] <ted_> I'm reasonably certain that it isn't used, and if it is, it's a bug we should fix.
[21:15] <ted_> Hmm, I could use the Upstart dbus bridge to file a recoverable error… ;-)
[21:17] <sergiusens> ted_, fwiw I was required to create separate items for things that were missed out from the list
[21:17] <infinity> slangasek: Well, the lib is *linked* on the desktop, hence why I demanded they avoid breaking ABI. :P
[21:20] <cjwatson> sergiusens: is this expected to be only on the phone for 14.04, or desktop too?
[21:22] <sergiusens> cjwatson, only phone/tablet(touch), not desktop
[21:23] <sergiusens> desktop is 14.10
[21:23]  * sergiusens rephrases, desktop is a 14.10 target for media-hub
[21:24] <cjwatson> sergiusens: ok, so this isn't really much to do with the ffe, but for my curiosity, in which direction does this make the qtmultimedia-opensource-src-touch thing better? :)
[21:25] <sergiusens> cjwatson, we won't need it; so we can rid of that package for starters
[21:25] <cjwatson> sergiusens: oh, and does this imply an ABI change for apps?
[21:26] <sergiusens> jhodapp (not here) can provide the nitty details
[21:26] <cjwatson> ok, I never actually knew what qtmultimedia-opensource-src-touch was for
[21:26] <cjwatson> don't feel the need to drag them in - as I say it was just a curiosity thing
[21:26] <sergiusens> cjwatson, they can work together
[21:26] <sergiusens> what media hub does is provide a dbus interface to say 'play this'
[21:27] <cjwatson> if it's for touch only for 14.04, I consider it essentially covered by bug 1282590 anyway, even though it's not explicitly on that list
[21:27] <ubot2> Launchpad bug 1282590 in Ubuntu "[FFe] standing freeze exception in trusty for Ubuntu Touch-specific packages" [Undecided,Confirmed] https://launchpad.net/bugs/1282590
[21:27] <sergiusens> ah, I was asked to create individual bug reports for the stuff that missed the list
[21:28] <cjwatson> ok - well, I don't see anything to be concerned about here at least
[21:28] <cjwatson> and there still seems to be adequate time to make it work if you're basically ready to land it
[21:28] <sergiusens> it's ready to land
[21:28] <cjwatson> confirmed the bug
[21:29] <sergiusens> thanks
[21:31] <rsalveti> cjwatson: qtmultimedia-opensource-src-touch is just a forked version that uses gst1.0 instead of gst0.10
[21:31] <ScottK> rsalveti: Do you know when 1.0 support lands upstream?
[21:32] <cjwatson> rsalveti: so how does media-hub obsolete that?  do we effectively go back to gst0.10; or is it using gst1.0 via some path other than qtmultimedia?
[21:32] <rsalveti> ScottK: would need to check, last time I did there was still a lot of work to be done (just video playback was done, but camera had to be ported still)
[21:33] <ScottK> I see.  Thanks.
[21:33] <rsalveti> cjwatson: not using gst at all, we just need to change our video layer (qtvideo-node and others) to request video playback using media-hub, via dbus
[21:34] <rsalveti> media-hub will still use gst1.0, but just at the server side
[21:35] <cjwatson> yeah, that's what I meant
[21:35] <cjwatson> so it's doing so not via qtmultimedia
[21:35] <rsalveti> yeah
[21:35] <cjwatson> and qtmultimedia isn't in the set we currently expose to apps?
[21:35] <cjwatson> or will this be a 14.04-dev2?
[21:37] <rsalveti> I think we might be exporting that api yeah, need to check first with the sdk team to see how we will do the transition
[21:44] <cjwatson> rsalveti: ok, if we are then please let's coordinate that first and make sure Jamie and I are around when you're trying to land it
[21:44] <rsalveti> cjwatson: sure
[21:59] <sergiusens> it shouldn't be seeded anytime soon
[22:30] <JackYu> hi release team, would you please review the FFE request at bug #1293299?
[22:30] <ubot2> Launchpad bug 1293299 in Ubuntu "[FFE]upload ubuntu-kylin-software-center into archive" [Undecided,Confirmed] https://launchpad.net/bugs/1293299
[23:06] <darkxst> do we need a UIFe for Ubuntu GNOME community wallpapers package?