#ubuntu-uds-client-2 2013-11-18
* ChanServ changed the topic of #ubuntu-uds-client-2 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1311/client-2/ - http://irclogs.ubuntu.com/2013/11/18/%23ubuntu-uds-client-2.html
<katrika> /
#ubuntu-uds-client-2 2013-11-19
* ChanServ changed the topic of #ubuntu-uds-client-2 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1311/client-2/ - http://irclogs.ubuntu.com/2013/11/19/%23ubuntu-uds-client-2.html
* ChanServ changed the topic of #ubuntu-uds-client-2 to: Track: Client | Re-enable sidestage for Unity8 on mir | Url: http://summit.ubuntu.com/uds-1311/meeting/22086/client-1311-enable-sidestage/
<ricmm> hi
<kgunn> link ?
<tsimpson-uds> see /topic
<tvoss_> didrocks, o/
<mzanetti> we broke it!
<didrocks> mzanetti: ricmm is broken, that's what I thought :p
<didrocks> hey tvoss_
<tvoss_> ricmm, I think lifecycle shoul dbe handled per stage
<tvoss_> ricmm, I would propose to look into content hub
<tvoss_> too
<tvoss_> didrocks, Saviq, kgunn ^
<Saviq> tvoss_, maybe join the hangout/
<Saviq> ?
<didrocks> tvoss_: what do you mean but looking into content hub?
<didrocks> for clipboard?
<Saviq> tvoss_, but yes, I did think that the hub could be integrated
<tsdgeos_uds> ricmm: what's the plan for the "new sidestage features" for surfaceflinger, will still support them for the other ports that don't use Mir?
<tsdgeos_uds> or should just all other ports just use Mir?
<tvoss_> didrocks, yup, it's the same scenario, content source, destination and actual content
<Saviq> tsdgeos_uds, yeah, that's a very good question, not sure we will be able to answer it here
<tsdgeos_uds> ack, makes sense :-)
<mzanetti> Saviq: will we do this properly soonish then? https://code.launchpad.net/~unity-team/unity8/split-surfaces
<Saviq> mzanetti, possibly, the while scenegraph topic binds into this a lot
<Saviq> mzanetti, more so than the side stage, I'd say
<mzanetti> mhm
<mzanetti> didn't we have a destkop file hint which specifies supported stages?
<Saviq> delivery...
<Saviq> mzanetti, default, not supported
<mzanetti> iirc there was a month or so where we had another one too
<mzanetti> but that one stopped working at some point and was removed from all the apps
<tvoss_> didrocks, Saviq my broadband dropped, resurrecting it now
<mzanetti> games?
<mzanetti> ricmm said there won't be landscape only
<mzanetti> but games might really do that
<mzanetti> so it would run on tablet main stage and phone, but not tablet sidestage
<mzanetti> yes
<mzanetti> yeah... got it
<didrocks> now, the challenge is going to be able to stop ricmm :)
<mzanetti> :D
<sil2100> ;)
* ChanServ changed the topic of #ubuntu-uds-client-2 to: Track: Core | CI Airline | Url: http://summit.ubuntu.com/uds-1311/meeting/22092/core-1311-ci-airline/
<Saviq> ricmm, to make sure you have that: http://pad.ubuntu.com/uds-1311-client-1311-enable-sidestage
<cjwatson> hangout url?
<Ursinha> didrocks, ^
<zyga> hi
<ev> I'll be taking any questions you have on Didier's presentation or the CI Airline on the whole.
<tedg> ev, Will you be serving drinks and roasted nuts as well?
<tsdgeos_uds> did the stream just die for everyone or just me?
<robruds> tsdgeos_uds: works for me
<dobey-uds> tedg: i'm going to need all the rum you have.
<ev> dobey-uds: if you want a speaking slot, there's still space
<ev> tedg: :)
<ev> or anyone else for that matter - we've got plenty of space in the on air hangout
<dobey-uds> ev: i don't want to complain too much in the session :)
<ev> dobey-uds: it's the point of the session
<ev> getting feedback from upstreams
<tedg> It's hard to think of positive feedback :-)
<ev> tedg: feedback on the new idea
<ev> not the current approach
<ev> do feel free to ask questions now. I'll happily queue them up for Didier.
<tedg> QUESTION: You've been talking about updating for changing images, how about changing trunks?
<ev> tedg: can you elaborate on what you mean by changing trunks?
<tedg> ev, Foo app gets new bug fixes on trunk
<cjwatson> This optimises strongly for feature work that requires extensive testing; it's making trade-offs in favour of that.  I really want to make sure that changes where that trade-off isn't justified don't need to go through this, as it would have a very scary effect on velocity if they did.
<dobey-uds> QUESTION: Why the emphasis on anti-isolation?
<cjwatson> While at the same time ensuring that the bells-and-whistles CI facilities are available for the cases where they're needed.
<infinity> +1 to Colin's comments there.
<tedg> I don't know how you can really have a "lock", I mean, there are likely to always be more features landing than we'll have HW to lock everything.
<cjwatson> The "small bug fixes" bit at the beginning of the presentation alludes to that discussion, I think, but that's a substantial policy grey area that I think is worth thinking about.
<ev> cjwatson, infinity: are we talking about the time it takes to run the tests? Because this isn't blocking on human beings, so I'm trying to understand what you're worried will decrease development velocity.
<cjwatson> No, I'm talking about the whole thing.
<cjwatson> There are days when I make 20-30 changes to the archive for build fixes, transitions, and the like.
<dobey-uds> tedg: the pervasive requirement of specific hardware/device testing is definitely a problem
<infinity> ev: The whole end-to-end "register intent to change" all the way to "landing".  It's far too heavy for a simple/small fix/change.
<tedg> Will there be a choice of who gets sign-off on take off?  I'm guessing we don't need design sign off for Upstart features.
<ev> cjwatson: sure, but if you had a simple way of throwing a dsc at this and forgetting about it, would that not work
<cjwatson> No.
<cjwatson> It's far too heavyweight.
<cjwatson> And unnecessary.
<cjwatson> Given that all I actually need for most of that is "does it build and does it pass autopkgtests", which I already have.
<tedg> And most transitions are handled by the proposed handling.
<cjwatson> (Looks like Didier is getting to what I care about now)
<zyga> how does this session relate to people working on ubuntu components patch by patch, can I somehow not maintain my own CI infrastructure?
<ev> cjwatson: okay, I cannot condense that down into a sentence, so after we handle tedg and dobey-uds' questions, may I ask that you raise your concerns?
<cjwatson> Sure
<ev> much appreciated
<ev> zyga: you're free to use whatever you want to verify your code before uploading.
<zyga> ev: uploading? when I'm uploading it has to work already, what I want is something that helps me on the way there, by the time I upload packages it is already too costly or too late to fix something that was broken early on
<ev> zyga: So this is one such approach that allows that continuous feedback
<tedg> ev, Do we have data on how many cross-package mega-features we do per cycle?  I'm guessing 2, perhaps 3.  Worried we're building something for a minority of use-cases.
<ev> tedg: noted
<zyga> ev: so is the intent to use this system to create a package for each patch that lands into ubuntu so that it goes through all of that before landing?
<dobey-uds> tedg: indeed. it feels very TSA to continue the metaphor
 * tedg feels safer now
<ev> zyga: you can feed this system a branch or a dsc file
<zyga> ev: so I propose a merge request on launchpad, I go to this boarding system, point it at my branch, what happens next? does it land my branch after I'm done, does it comment on the merge request? can I do that for all the proposals I'm doing?
<zyga> ev: does it go to ubuntu? to my project trunk?
<dobey-uds> this seems all about testing everything all at once together, versus simply pushing developers to write isolated code
<cjwatson> Damnit
<tedg> ev, Feed it a branch?  Isn't that basically what a MR is?  Will MRs be considered "small fixes" by default?
<zyga> cjwatson: how is this different from autopackage tests?
<cjwatson> I was having audio problems yesterday, but I'd hoped they were just with mumble
<cjwatson> Let me try restarting my desktop env
<cjwatson> I'd like to do this by audio, so I'll get back to you
<infinity> ev: Your audio is very choppy.
<ev> boo :(
<ev> infinity: can you carry this one?
<zyga> audio too choppy to understand
<ev> or raise your concerns
<zyga> does the system exist or is this a proposal for something new?
<zyga> ev: ^^
<dobey-uds> too much background noise for ev
<zyga> and how does it tie into UDD (ubuntu distributed development), if any
<Ursinha> didrocks, I wonder if your workflow diagrams cover all these questions?
<ev> Ursinha: do feel free to share them here
<ev> zyga: it's something being built
<Ursinha> ev, it was an honest question, I don't know if they cover these cases (if they don't we might need to extend them)
<ev> oh :)
<zyga> ev: is this something you see being required for all updates to stable ubuntu releases?
<ev> zyga: to be clear, we are not requiring this for core-dev uploads.
<ev> but yes, this system can handle SRUs
<ev> I'll raise that question with didier so he can explain further
<cjohnston> The lock only lasts from the time that a ticket is marked as ready to be merged until it's merged, should be hours at best
<cjohnston> (best meaning most)
<Ursinha> I love the analogies
<zyga> cjwatson: good comparison
<plars> heh
<tedg> In France the change the speed on the highway during holidays?
<cjwatson> As a cyclist, I also don't think that car travel is a good analogy for an efficient system :-)
<tedg> Wow.  That'd never fly in Texas.
<dobey-uds> tedg: many highways in the US do as well, when there are high traffic situations. not just holidays, but during rush hour and such even
<plars> tedg: wait, we have speed limits in Texas? since when?
<tedg> plars, They're listed on the white signs with bullet holes
<cjwatson> Last time I drove in Texas the speed limit was 55mph for a three-hour empty highway ...
<kgunn> plars: 80mph on that tollway near your city it awesome
<arges-uds> (I'm late so this may have already been covered) Does this fundamentally change the SRU process?
<dobey-uds> arges-uds: no
<arges-uds> : )
<didrocks> cjwatson: well, I'm a cyclist as well, but I guess the global speed one is a still giving some help (/me would love that the speed in his city on the road with cyclist line is slower to be safer)
<cjwatson> Right.  But part of the problem is precisely that car travel doesn't scale up; you make roads more efficient for drivers by removing cars (there are studies on this, there's a tipping point where there's a fairly sharp corner in the graph).
<tsdgeos_uds> i'm with tedg here, i don't want nor need this big thing for this MR https://code.launchpad.net/~aacid/unity-mir/nomegaheader/+merge/195823
<vila> the ci system also give access to more hardware than all devs can have on their desktop
<cjwatson> This analogy is getting rather laboured :-)
<dobey-uds> tedg: it's full autowaited
<plars> There seems to have  been some value in the past of tracking what's about to land in the image. Isn't that the motivation for even having patches going through the lightweight process get a "ticket"?
<cjwatson> I dispute that value
<cjwatson> (In the case of lightweight changes)
<ev> cjwatson: please raise that then :)
<cjwatson> I think it has made some people feel more in control, but I think that control is artificial
<cjwatson> Again, and I'm sounding like a broken record: for more substantial feature work, by all means
<dobey-uds> cjwatson: and even then, that work should be incremental, not huge swathing changes, i think
<dobey-uds> who is doing the work to write all the toosl, or fix issues in launchpad?
<infinity> cjwatson: Indeed, "people having control" shouldn't be a goal in itself, unless the control is useful.  In a distributed development environment, often "people having control over landing" is of benefit to exactly no one except that person's ego.
* ChanServ changed the topic of #ubuntu-uds-client-2 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1311/client-2/ - http://irclogs.ubuntu.com/2013/11/19/%23ubuntu-uds-client-2.html
<Ursinha> dobey-uds, that's still being discussed, that would be the ci team, I believe
<dobey-uds> Ursinha: i wonder if any of the work is going to be fixing issues in launchpad to make it more useful for such processes, or just writing weird custom hacks on top of what already exists there (or just using external stuff like google docs to track things)
<Ursinha> infinity, also having a bottleneck is against the principle of continuous integration
<dobey-uds> because custom hacks are not fun
<Ursinha> dobey-uds, I'm suggesting that we use launchpad as the "ticketing system" as we already use a lot of it to other parts of the process, wgrant said he would be happy to discuss other parts that could be fixed in launchpad (like the jenkins part, for instance)
<Ursinha> dobey-uds, that said I agree with you :)
<dobey-uds> and in particular, i don't want someone to go write another custom branch merge/commit solution and reimplementing features poorly, when we have tarmac
<M3kH> is started the Unity8 shell discussion?
<Ursinha> dobey-uds, I believe most people agree on that
<dobey-uds> Ursinha: anyway. i would like to be included in those discussions
<kgunn> M3kH: another hour
<Ursinha> dobey-uds, sure, please join the discussion :) I can point you the documents and we can start to discuss more in the open so other people can join as well
<M3kH> ooh :) cool I have the time for come back home
<dobey-uds> am still a bit in shock from being told last night "oh, we're going to make huge changes to our process again"
<dobey-uds> Ursinha: great. yeah, please e-mail me the links to those docs and ping me to be in discussions when possible :)
<Ursinha> dobey-uds, sure, will do
<dobey-uds> Ursinha: thanks!
<Ursinha> np :)
<dobey-uds> ok. time to get lunch over here
<dobey-uds> later :)
* ChanServ changed the topic of #ubuntu-uds-client-2 to: Track: Client | Unity8 shell discussion | Url: http://summit.ubuntu.com/uds-1311/meeting/22084/unity8-shell-discussion/
<kgunn> just rounding folks up from lunch....bear with us
<kgunn> hangout https://plus.google.com/hangouts/_/72cpjf8uetpdtf0ed3u4t3lm64?authuser=0
<kgunn> the pad saviq is referencing http://pad.ubuntu.com/uds-1311-unity8-shell-discussion
<Saviq> https://wiki.ubuntu.com/Apport
<pstolowski_> I think it's worth mentioning that when you run unity8 on the desktop, it's going to connect to the backend services of the desktop (e.g scopes), so you cannot replicate the exact phone experience. any hints about making it similar to the phone as much as possible while running on the desktop?
<Saviq> https://wiki.ubuntu.com/DebuggingProgramCrash
<Saviq> https://lists.launchpad.net/ubuntu-phone/msg04549.html
<pstolowski_> is cross-compilation possible?
<Saviq> https://wiki.ubuntu.com/SimpleSbuild
<Saviq> https://wiki.ubuntu.com/CrossBuilding
<pstolowski_> awesome, thanks
<Saviq> http://pastebin.ubuntu.com/6444153/
<veebers> Saviq: Could we cover quickly running the tests? qmltests and autopilot etc
<veebers> hmm, does anyone else get a "Proxy Error" from the etherpad?
<kgunn> veebers: yes...seems to be down
<veebers> kgunn: ack, thanks for confirmation
<kgunn> back up now tho
<veebers> You could also, cd tests/autopilot; autopilot run . . .
<kgunn> veebers: feel free to edit etherpad for posterity's sake
<veebers> kgunn: cool, will do when I get access back
 * mzanetti thinks of questions to bug Saviq
<Saviq> mzanetti, too late ;P
<kgunn> mzanetti: i'm pretty sure you know where he works
* ChanServ changed the topic of #ubuntu-uds-client-2 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1311/client-2/ - http://irclogs.ubuntu.com/2013/11/19/%23ubuntu-uds-client-2.html
#ubuntu-uds-client-2 2013-11-20
* ChanServ changed the topic of #ubuntu-uds-client-2 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1311/client-2/ - http://irclogs.ubuntu.com/2013/11/20/%23ubuntu-uds-client-2.html
* ChanServ changed the topic of #ubuntu-uds-client-2 to: Track: Client | Status check on Qt 5 | Url: http://summit.ubuntu.com/uds-1311/meeting/22090/client-1311-stateofqt5/
<didrocks> who is participating to the Qt5 session? :)
<Mirv> welcome anyone to the hangout :) https://plus.google.com/hangouts/_/7ecpjhcv91f5e2g6cvefjmia44
<Mirv> https://plus.google.com/+TimoJyrinki/posts/NeUt19z1V3p
<Riddell> hi
<tsdgeos> hi
<didrocks> hey Riddell
<didrocks> Riddell: wants to join the hangout?
<lool> didrocks: I think I'll drop to another session about cross-compilation now that I raised the main things I wanted to make sure was taken care of; I trust others know better than me about 5.2 issues/bugs to solve etc.
<didrocks> Riddell: nice to see you, welcome! :)
<didrocks> lool: agreed
<didrocks> lool: see you!
<Mirv> thanks everyone, adding some notes still to the pad from discussion
<rsalveti> seems we're done already
<Mirv> rsalveti: yeah, we finished as no new questions or topics were raised.
<Mirv> notes in the pad
<rsalveti> Mirv: thanks
<didrocks> who is going to lead the mediascanner roadmap?
* ChanServ changed the topic of #ubuntu-uds-client-2 to: Track: Client | Mediascanner roadmap | Url: http://summit.ubuntu.com/uds-1311/meeting/22110/client-1311-mediascanner-roadmap/
<satoris> didrocks: that would be me.
<didrocks> satoris: are you joining?
<didrocks> https://plus.google.com/hangouts/_/72cpigmmgnfvmfg8d0qugft72c?authuser=0
<satoris> Feel free to join.
<jdstrand> mediascanner directly usable by apps is useful for application confinement
<jdstrand> since it is out of process, 3rd party music players could just use it
<jdstrand> yes, please do not allow direct access to the sql db. that will limit what 3rd party apps in the app store can do (due to application confinement)
<jamesh> http://bazaar.launchpad.net/~mediascanner-team/mediascanner/v2/view/head:/src/mediascanner/MediaStore.hh
<jdstrand> right now, music-app is unconfined. the apis should support it being confined
<ahayzen> vthompson, we'll still have to store playlists in our db? but could we reduce it just to the file/uri and query the mediascanner for the metadata?
<mhr3> QUESTION: with the new mediascanner, apps open the db themselves, right? how is that going to play with confined apps?
<vthompson> ahayzen,  I believe we'll still need to keep track of playlists. But keeping just the URI might be a way forward. I believe we could do that with grilo as well
<jdstrand> mhr3: it won't (see above comments). we should provide an api so confined apps don't have to do that
<jdstrand> we special cased music-app for 13.10, but it should be confined like everything else
<jdstrand> (unfortunately, I got called to another session)
<ahayzen> vthompson, I would be happy working on reworking our side of things to do tht
<bfiller> QUESTION: is their a library available to do thumbnail generation? we want the mediaplayer-app and gallery-app to use this if so
 * jdstrand is still here if you need me
<bfiller> cool!
<mhr3> bfiller, i think part of it is already in the SDK
<bfiller> does it require any special codeces?
<bfiller> codecs
<bfiller> i.e. ffmpeg or any -ugly stuff?
<jdstrand> jamesh: I'm back a few minutes in the feed (cause I got pulled out). we *could* allow readonly access to the db in apparmor policy. the sqlite db has to be opened in a very specific way to do that. I kind of hoped the mediascanner library would call out to the mediascanner process and the mediascanner process could give the info rather than direct access to the db
<jdstrand> jamesh: that could be over dbus
<mhr3> bfiller, depends on what you want to thumbnail :)
<mhr3> bfiller, ultimately it just pokes gstreamer
<jamesh> jdstrand: the client library lets you open the database in SQLITE_OPEN_READONLY mode, which should be fine with read only confinement right?
<bfiller> mhr3: thanks makes sense
<jdstrand> jamesh: the confinement could be made to allow that. right now we don't have policy groups for that, but it could be added
<mhr3> jhodapp, shouldn't such test be somewhere in the media stack? thumbnailer just uses gstreamer to get it
<jdstrand> jamesh: we have a similar issues with thumbnails btw
<jhodapp> mhr3, yes, but I'd also like to test it at this level...i think the more tests in different use-cases the better
<mhr3> jhodapp, well it means that thumbnailer will fail only because the media stack will go through a transition
<jdstrand> jamesh, satoris: sorry if I missed this-- will the mediascanner do the thumbnailing and then apps use these thumbnails?
<jhodapp> mhr3, not sure I'm following
<mhr3> jhodapp, if something breaks in media stack, it automatically breaks thumbnailer
<jhodapp> mhr3, yes, that's what I want to catch
<ahayzen> vthompson, is there any other info we need from the mediascanner?
<mhr3> jhodapp, yet thumbnailer is not able to do anything about it
<jhodapp> mhr3, right
<mhr3> jhodapp, that's why i think the test shouldn't be there
<jhodapp> mhr3, I guess that's up to the media scanner team then as I still think it's useful
<jdstrand> QUESTION: what is the hangout url?
<vthompson> ahayzen, so I think we'll need to maintain a 14.04 specific branch for this capability and possible U1 streaming if we tackle that
<jhodapp> https://plus.google.com/hangouts/_/72cpigmmgnfvmfg8d0qugft72c?authuser=0
<ahayzen> vthompson, ok, when is the new mediascanner expected to land?
<vthompson> ahayzen, sounds like we'll have a PPA to access in some soon-ish timeframe
<pstolowski_> QUESTION: is QML bindings something you would consider community could help with, or even drive?
<ahayzen> vthompson, cool, guess we can start doing some things and still use Grilo for the moment?
<vthompson> ahayzen, I believe we'll have to maintain grilo in Saucy.
<jdstrand> jhodapp: thanks for the link btw :)
<pstolowski_> QUESTION ^^ :)
<jhodapp> jdstrand, np
<jdstrand> vthompson: as an aside-- thanks for all the bug fixes for music-app of late :)
<jdstrand> I can't wait to get the new player :)
<vthompson> jdstrand, :) my pleasure
<ahayzen> vthompson, i'm gonna go back home anything u need from me?
<vthompson> ahayzen, nope! Safe travels!
<ahayzen> vthompson, probably speak in ~1hr :)
* ChanServ changed the topic of #ubuntu-uds-client-2 to: Track: Client | Online Accounts features for 14.04 | Url: http://summit.ubuntu.com/uds-1311/meeting/22097/client-1311-online-accounts/
<dbarth> hiya
<didrocks> hey dbarth!
<alex-abreu> oa it is then
<dbarth> who wants to hop on the hangout?
<didrocks> kenvandine: interested?
<dbarth> jdstrand: ?
<dbarth> kenvandine: ?
<kenvandine> yes
<jdstrand> dbarth: I will be in irc. mdeslaur could join the hang out since he is leading this discussion on my team
<dbarth> ah cool
<mmcc> Hi folks :)
<jdstrand> dbarth: if you need me to join, I'm here
<dbarth> ok
<robruds> mardy: friends uses flickr
<ssweeny-uds> is the friends flickr plugin installed on the phone?
<robruds> ssweeny-uds: nope ;-)
<robruds> ssweeny-uds: only twitter and facebook by default.
<ssweeny-uds> robruds: that's what i thought
<robruds> ssweeny-uds: so I'm just realizing right now for the first time that friends-{flickr,instagram,linkedin} are broken on the phone because they're not installable on a readonly image.
<ssweeny-uds> robruds: as a user of third-tier open social networks I've felt pretty marginalized on the phone with no easy way to write friends plugins :)
<ssweeny-uds> robruds: yeah that might be a problem...
<dbarth> ssweeny-uds: that's why we need click hooks
<dbarth> for OA plugins / auth. providers
<ssweeny-uds> dbarth: yeah, OA and friends both need them
<robruds> ssweeny-uds: yeah, there was a session yesterday about the idea of installing plugins with click, so friends will have to be part of that.
<dbarth> ssweeny-uds: but which is currently planned to be a manual process, for partners we can have an audit or agreement with
<ssweeny-uds> robruds: we talked about this a few months ago. you said i think that friends plugins would need to be split up into their own processes to allow confinement
<robruds> ssweeny-uds: well that was based on my understanding of confinement, more than my understanding of friends plugins.
<ssweeny-uds> ah
<robruds> ssweeny-uds: so i could be wrong
<ssweeny-uds> my thinking is if a friends plugin can only access data associated with the account it's "called" with then the security issues aren't so bad
<robruds> ssweeny-uds: the friends plugins are so simple, don't take up any space. i'd like to just have them all installed by default (I was opposed to the original work of splitting them all up into different packages)
<ssweeny-uds> like, as long as the twitter plugin can't access your facebook profile the risk is low
<ssweeny-uds> robruds: that makes sense
<ssweeny-uds> robruds: i'm mostly worried about pushback against click plugins for friends
<robruds> ssweeny-uds: haha, no. the friends plugins are python modules, they have total access to the entire friends infrastructure, they can do anything.
<ssweeny-uds> yeah, that's what i was afraid of
<ssweeny-uds> so there will be security concerns with third-party friends plugins
<robruds> ssweeny-uds: hmmm, yeah, this is a tricky issue i hadn't previously considered.
<ssweeny-uds> there was talk yesterday of manual review for certain types of packages
<ssweeny-uds> this might have to fall under that
 * cwayne and ssweeny-uds started work on a click-hooks for o-a
<cwayne> ~/.local/share
<cwayne> u-s-s-o-a needs to be modified to look for qml-plugins in ~
<didrocks> cwayne: ssweeny-uds: robruds: one of you wanting to join the hangout?
<dbarth> cwayne, ssweeny-uds: do you want to continue the work on that?
<dbarth> the click hook
<robruds> dbarth: mardy: sorry I think ssweeny-uds and i are bit offtopic here
<dbarth> ie, to get that task done in the plan
<ssweeny-uds> dbarth: yes please
<cwayne> dbarth, the click hooks should probably be part of the online-accounts system settings package
<kenvandine> cwayne has been looking at click packages for account plugins
<dbarth> right
<ssweeny-uds> dbarth: i'm about 70% done with the patch to the system-settings part
<dbarth> but mardy welcomes patches, you see ;)
<dbarth> ssweeny-uds: cool!
<dbarth> ssweeny-uds: did that get a cjwatson review yet?
 * cwayne also volunteers to make an sdk template for new online-accounts once we have them as clicks
<dbarth> awesome!
<mardy> http://developer.ubuntu.com/api/qml/sdk-1.0/
<cwayne> i think all we're waiting on re: click hooks is getting this fixed: https://bugs.launchpad.net/ubuntu/+source/click/+bug/1245826
<udsbotu> Launchpad bug 1245826 in click (Ubuntu) "Allow applying a hook to multiple files" [Wishlist,Triaged]
<mmcc> QUESTION: Is there anything currently using signon-ui on ubuntu touch? Our UbuntuOne provider plugin has custom QML UI for login, and needs signon-ui to support QML so we can handle requesting re-authentication for invalidated tokens.
<mardy> http://developer.ubuntu.com/api/qml/sdk-1.0/Ubuntu.OnlineAccounts/
<ssweeny-uds> dbarth: the patch i'm working on now is just to get the settings UI to load stuff from ~/.local/share/
<mmcc> mardy: this is re your comment on bug 1248326
<udsbotu> Ubuntu bug 1248326 in Unity Click Scope "Handle invalidated token in a more user-friendly way" [Undecided,New] https://launchpad.net/bugs/1248326
<ssweeny-uds> this (multiple possible domains) discussion is also useful for things like owncloud or statusnet which don't have a central server
<dbarth> ssweeny-uds: do you have a working model for that?
<dbarth> are you constraining urlpatterns?
<ssweeny-uds> dbarth: i don't know if you can do that. the domain could be anything
<dbarth> ssweeny-uds: oh, meaning, any server where you would host the service?
<ssweeny-uds> yeah
<dbarth> i see
<dbarth> but are you using a webapp container for this one?
<dbarth> or would like to do so
<ssweeny-uds> dbarth: for instance i have statusnet and owncloud services running on my own domain
<dbarth> want to hop on the hangout?
<ssweeny-uds> dbarth: i'm not actually looking to use webapps. i'm talking more generally that i'd like OA to be able to handle decentralized services
<dbarth> thanks everyone for your feedback on the topic
<dbarth> and for the upcoming contributions more importantly!
<dbarth> really appreciated
* ChanServ changed the topic of #ubuntu-uds-client-2 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1311/client-2/ - http://irclogs.ubuntu.com/2013/11/20/%23ubuntu-uds-client-2.html
* ChanServ changed the topic of #ubuntu-uds-client-2 to: Track: Client | Scopes for Unity 8 | Url: http://summit.ubuntu.com/uds-1311/meeting/22099/client-1311-scopes/
<olli> who is running this track?
<olli> got a link to the URL
<olli> lol
<olli> link to the HO
<tvoss_> didrocks, r u running the hangout?
<didrocks> tvoss_: yeah, want to come?
<didrocks> thostr: is going to lead it
<doko> what's the hangout URL?
<didrocks> doko: it's about unity8 scopes
<didrocks> doko: are you sure you are in the right room?
<tvoss_> didrocks, listening in :)
<Saviq> QUESTION: is JavaScript considered less resource hungry than Python/
<Saviq> ?
<olli> QUESTION: what's the situation re security & JS?
<satoris> The basic memory footprint of Python interpreter is 5MB or so.
<mhr3> didrocks, can you mute yourself?
<didrocks> mhr3: sorry, done
<mhr3> thx
<davidcalle> Also, for the record, the memory footprint of a basic running scope is around 9MB.
<davidcalle> Python ^
<facundobatista> davidcalle, that have imported all the gio crazyness, right?
<davidcalle> facundobatista, right
<facundobatista> davidcalle, that's not fair ;)
<jdstrand> fyi, https://wiki.ubuntu.com/SecurityTeam/Specifications/ScopesConfinement
<jdstrand> (I also added ^ to the pad)
<jdstrand> QUESTION: can you comment (for the wider community) on how you've addressed privacy wrt to scopes? (ie, briefly detail the work you've done on disabling internet scopes globally and on a per scope basis, etc)
<jdstrand> (of course the security design feeds in to that too)
<jdstrand> (but you already mentioned that :)
<jdstrand> I know the answer-- but thought others might be interested in it :)
<alecu> regarding the online switch for scopes: the click scope listens to that setting too, and disables getting "suggested apps" from the click webservice when online searches are off. It
<alecu> it still does the search of locally installed apps
<pedronis2> we are also proxying images, so those don't get to the original server either
<fugue88> What's the name of that "global search" ?
<fugue88> David mentioned it.
<Saviq> davidcalle, â
<davidcalle> fugue88, Blippex
<fugue88> Thanks!
<davidcalle> fugue88, np. Here is a few screenshots : https://plus.google.com/+davidcalle/posts/7E1SDPZie9p
<pedronis2> thanks
<fugue88> davidcalle: Cool.  Interesting that they allow you to set "dwell time" and other things.
<davidcalle> fugue88, yes, this is a very interesting search engine.
<tvoss_> didrocks, ping
* ChanServ changed the topic of #ubuntu-uds-client-2 to: Track: Client | Go for client side development | Url: http://summit.ubuntu.com/uds-1311/meeting/22030/client-1311-go-for-client-side-development/
<tvoss_> niemeyer, hey there :) wanna join us on the hangout?
<didrocks> tvoss_: pong
<niemeyer> tvoss_: Sure, link?
<tvoss_> didrocks, got the ho link for me?
<didrocks> tvoss_: I sent you the links 5 minutes ago :p
 * didrocks does again
<tvoss_> didrocks, don't have it :/
<tvoss_> didrocks, this time it worked
<tvoss_> niemeyer, https://plus.google.com/hangouts/_/72cpi68tob23aag0bfji9amh30?authuser=0
<didrocks> tvoss_: I sent it to him already FYI ;)
<tvoss_> jdstrand, wanna join the hangout, too?
<tvoss_> jdstrand, https://plus.google.com/hangouts/_/72cpi68tob23aag0bfji9amh30?authuser=0
<jdstrand> tvoss_: actually, I was going to attend a different session and have two people here if you need comments from the security team
<tvoss_> jdstrand, would like to have someone on the hangout, yes
<jdstrand> tvoss_: if you feel my input is required, I'll attend
<tvoss_> jdstrand, not necessary, as long as someone from security is here
<zyga> hi
<lool> tvoss_: do we have someone representing SDK team?
<tvoss_> lool, nope, can you pull zoltan over?
<lool> tvoss_: poked him
<pmcgowan> lool, I will join for now
<fugue88> QUESTION: By client side, do you mean GUI, or more generic than just GUI?
<tvoss_> fugue88, more generic than just UI
<fugue88> On the other hand, with gcc *maybe* making gccgo a default, it might get some more popularity.
<fugue88> Of course, we don't have a crystal ball.
<cjwatson> can I have the hangout url?
<tvoss_> fugue88, look at https://launchpad.net/usensord for example
<tvoss_> cjwatson, https://plus.google.com/hangouts/_/72cpi68tob23aag0bfji9amh30?authuser=0
<Saviq> cjwatson, https://plus.google.com/hangouts/_/72cpi68tob23aag0bfji9amh30?authuser=0
<cjwatson> ta
<zyga> IIRC linaro was doing some work on porting go to aarch64
<zyga> https://groups.google.com/forum/#!topic/golang-dev/MLaz62sHUc0
<zyga> one of the people there is actually working for canonical
<tedg> jdstrand, Why is compiling every application an issue?  Tooling?
<zyga> tedg: upgrades probably
<Saviq> tedg, no, we don't have the sources
<zyga> tedg: imagine if everything is in go :-(
<Saviq> tedg, think of all the apps in the store - all would need to be recompiled
<zyga> tedg: 10GB upgrade for each security issue?
<zyga> ah, store argument is important too
<tedg> Well, the store is different.
<zyga> I don't think go is designed to work well there
<tedg> We can't apply security updates to store things mostly.
<tedg> It's all BYOD (Bring your own deps)
<Saviq> tedg, that's why we're talking about "go's stdlib"
<Saviq> tedg, which would be provided by us
<zyga> tedg: but we can ship fixed libraries (ssl, etc)
<tedg> Plus things in click packages are confined.  We don't care about security anymore ;-)
<fugue88> If an app dev has bundled their own crypto library in the click-package, the distro couldn't handle that anyway, right?
<zyga> tedg: mmaaybe
<Saviq> tedg, see, Jamie is responding right now ;0
<Saviq> damn shift...
<cjwatson> fugue88: their own, sure, but they should be able to use the crypto library in the stdlib without having to update their app every time there's a security vulnerability found in it
<fugue88> cjwatson: Well, I certainly agree about that, but some things will be bundled and have security concerns nonetheless.
<fugue88> But the burden on app devs to recompile every time the platform shifts is a big one.
<cjwatson> the perfect must not be the enemy of the good
<cjwatson> just because some things will end up being bundled doesn't mean we shouldn't make efforts to avoid bundling the stdlib with everything
<fugue88> No no, I agree.
<cjwatson> tedg: that only means the application can't compromise the rest of the system, not that it cannot be compromised itself
<tedg> cjwatson, Sure, but that means that the attack surface is much smaller.
<tedg> cjwatson, And the consequences of the attack.
<cjwatson> yes, but not that it should be ignored
<cjwatson> I don't think it would be responsible for us to ignore it
<tedg> I'm not saying it should be ignored, but I am saying that it may not be a blocker considering its size.
<Saviq> QUESTION: when talking Go/QML, QML in itself is very modular, allows for easy reusability between projects, would a Go QML extension/module be usable outside of a Go application?
<kardianos> Go support hard float
<kardianos> (It works on rpi)
<lool> thanks for the confirmation
<tvoss_> thx
<jdstrand> weird, I dropped out (connection was lost)
<lool> that's why you looked so static
<Saviq> niemeyer, thanks, I'm game :)
<kardianos> Go gc I'm fairly sure now generates PIC as a precursor for generating so objects. They are still attempting to fill the whole shared object story, no timeline yet, but the story is being developed.
<cjwatson> Would this be easier if using gccgo?
<niemeyer> kardianos: Right, and that's not even about Go 1.2..
<kardianos> Correct
<kardianos> I don't think it will be easier then gccgo, but I could be mistaken. Just the runtime story just haven't  been finished.
<cjwatson> Well, I ask because I understand (at second hand) that one can already build Go shared objects with gccgo
<Saviq> lool, no, reusable - and yes - IIUC niemeyer said it's possible - not yet, though
<kardianos> You could be correct there.
<kardianos> Not anymore
<kardianos> There is no longer any runtime code generation.
<Saviq> tvoss_, also, the main() for QML apps is usually minimal (if any), and porting that to Go wouldn't be a substantial task, if needed
<tvoss_> Saviq, yup, +1
<Saviq> so, yeah, goqmlscene would be enough in most cases
<Saviq> as qmlscene is enough in most cases now
<Saviq> QUESTION: any estimate on what could the overhead of a .so with the Go runtime be when used from a C++ application? I assume there would have to be a runtime-per-extension?
 * Saviq poking holes, sorry
<niemeyer> Saviq: A bit early to tell
<Saviq> niemeyer, right, thanks
<sergiusens> lool, Mike is using https://code.launchpad.net/~jamesh/go-dbus/trunk
<lool> thanks
<lool> it's listed in the bp already
<lool> actually the topic I wanted to open were which go library bindings we missed
<lool> but it seems dbus is not a problem anymore
<sergiusens> lool, I'm also trying to get these into debian (as well as niemeyer's gocheck)
<sergiusens> lool, I jsut noticed I'm not 'live' :-/
<sergiusens> sorry :-)
<lool> np
* ChanServ changed the topic of #ubuntu-uds-client-2 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1311/client-2/ - http://irclogs.ubuntu.com/2013/11/20/%23ubuntu-uds-client-2.html
<Saviq> session has ended â tvoss_ beer
<tvoss_> Saviq, yup :)
<didrocks> yeah, but jdstrand had a disruptive not intending to be disruptive but which can be seen as disruptive question :p
<pmcgowan> out of battery
<didrocks> oh, the excuse from Pat to drink beers :)
<lool> well it's Pat's battery
<lool> it needs beer to recharge
<didrocks> heh
<lool> he didn't say his *laptop* ran out  ;-)
<ogra_> thats was a fast beer
<lool> :-)
<Azendale> I'm interested in learning about any bindings from Qt to Go. (Last time I looked, it didn't seem like there really was anything). Can anyone point me in a direction?
<ogra_> beer injection :)
<Saviq> Azendale, here's what niemeyer is working on https://github.com/niemeyer/qml
<Azendale> Saviq: Thanks!
<Saviq> o/
#ubuntu-uds-client-2 2013-11-21
* ChanServ changed the topic of #ubuntu-uds-client-2 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1311/client-2/ - http://irclogs.ubuntu.com/2013/11/21/%23ubuntu-uds-client-2.html
* ChanServ changed the topic of #ubuntu-uds-client-2 to: Track: Core | Make click apps runnable from the Unity7 dash | Url: http://summit.ubuntu.com/uds-1311/meeting/22035/core-1311-clicks-in-unity7/
<dholbach> hey hey
<dholbach> so who wants to join in on this one?
<cjwatson> I'll be along soon, but you should just paste the hangout URL in here :-)
<cjwatson> (still having lunch)
<dholbach> https://plus.google.com/hangouts/_/7ecpjgq5mep8il0idsc30qv9eo
<dholbach> alecu, are you going to join as well? ^
<mdeslaur> o/
<dholbach> anyone else who wants to join in?
<beuno> dholbach, I'm around in case I'm needed, but I think this doesn't concern the store atm
<beuno> I'll listen in and feel free to drag me in if needed
<beuno> dholbach, you look cold
<tedg> beuno, It seems everyone in Germany wares scarfs.  Not sure I'm comfortable visiting anymore.
<beuno> +1
<mdeslaur> hehe
<Saviq> lol
<dholbach> notes are here: http://pad.ubuntu.com/uds-1311-core-1311-clicks-in-unity7
<dholbach> beuno, yep, got a cold :)
<dholbach> but it's all right
<asac> yes, we should not risk our "click store reputation" on security
<tedg> We should run through XVnc and then back through a VNC client.
<tedg> Most of the integrations are via DBus, so aa-exec-click would secure those.
<dobey> tedg: under an xvfb that's 480x960 px to match common phone res?
<tedg> dobey, On it!
<tedg> Sounds like a command line only GSettings key
<dobey> alecu, dholbach: also there's the work on the emulator, for developers to use
<dholbach> dobey, yep, that's right
<tedg> bregma, No, not really.  Clicks are per-user, so we won't put the desktop files in.
<tedg> bregma, They binaries are there, but no desktop file.
<dholbach> can somebody help a bit with taking notes? http://pad.ubuntu.com/uds-1311-core-1311-clicks-in-unity7
<tedg> Is the nested X stuff driver dependent?
<tedg> I thought there was some issues on nvidia?
<dobey> glx inside nested X can be a problem
<tedg> My thoughts are that it's interesting, but probably not worth the time.
<dobey> driver doesn't matter
<jdstrand> glx in nested X was a problem the last time I looked
<tedg> dobey, It's X, drivers are tied to everything :-)
<jdstrand> xpra has bugs open to make it better, but back then, they were already open for a long time
<dobey> tedg: doesn't matter which driver you are using though. glx in nested X is a problem with all of them :)
<jdstrand> I am not up to date
<Saviq> ~/.local/share/applications
<Saviq> ââ
<Saviq> unity7 does pick those up
<tedg> Wait, so where do we want to put the click package desktop file?
<tedg> It seems to me it either needs to be in ~/.local/share/applications or not exist.
<dobey> nowhere different to where we put them now
<cjwatson> Sounds like the consensus was leave them in the same place but add X-Only-Show-In or whatever it is
<dobey> OnlyShowIn/NotShowIn
<tedg> What would that OnlyShowIn be for?  Unity 8?
<dobey> yes, presuming "Unity8" is a different valid name, from "Unity"
<tedg> Then why don't we just not create it?  It seems like Unity8 could just put the data in a small cache better than building a desktop file.
<dobey> which would be a bit weird when we get to the point of not having unity7 any more
<dholbach> can somebody please help with summarising of what Colin just said? I was a bit busy taking some other notes: http://pad.ubuntu.com/uds-1311-core-1311-clicks-in-unity7
<cjwatson> doing so
<alecu> cjwatson, dobey: there's a X-Ubuntu-Touch=true in apps installed from the click store. Perhaps we should just ignore those in the unity7 app scope?
<cjwatson> alecu: there are other desktops to consider too
<cjwatson> it seems that it might be safer to use something affirmative rather than negative
<tedg> I'm confused why we want desktop files at all if they're OnlyShowIn=Unity8
<dobey> i don't think NotShowIn/OnlyShowIn will be usable here
<cjwatson> we still use them for unity8, don't we?
<cjwatson> even if they mostly shunt through to upstart-app-launch
<tedg> cjwatson, Kinda, but we coudl just move the desktop hook to build the cache for the apps scope instead of the desktop file.
<cjwatson> dobey: why not OnlyShowIn?
<tedg> The desktop file itself is an inefficient connection point.
<cjwatson> well, if we aren't using desktop files the whole thing's moot; but I'm unclear as to whether we should couple this work to that?
<dobey> cjwatson: because there's no difference between "Unity" and "Unity8" and it would probably be a lot of work to add it.
<dobey> cjwatson: currently there is only "Unity" as an option there
<tedg> cjwatson, It seems like the WI's could be "drop desktop hook from UAL" and then "put desktop hook to build cache for Unity8"
<dobey> i don't see why we should bother hiding the click apps at all though. if they're installed, they should be discoverable
<dobey> tedg: i'd really not want to do that. it means rewriting a large portion of the click scope
<dobey> jdstrand: +1 on keeping desktop files
<tedg> dobey, The first step could be writing the desktop files to ~/.local/click-scope/applications and then migrating to something more sophisticated over time.
<jdstrand> what about other DEs that move to mir?
<tedg> Not sure.  It's an interesting question.
<jdstrand> they need to then adjust for this click path too
<tedg> We'd need a way to know that they're running Mir.
<tedg> Otherwise we get back to the "nobody trusts us anymore" problem.
<mdeslaur> in our fallback wrapper that is being used in the desktop file, we detect X and print a warning dialog if it's running
<alecu> mdeslaur: so, that would be if we don't move them out of  ~/.local/click-scope/applications, right?
<dobey> mdeslaur: only because X is insecure in the context of confining click apps?
<mdeslaur> dobey: yes
<tedg> Security: It'll never catch on.
<tedg> No, but I'm kinda unclear what we decided.
<alecu> "This app may be insecure. You may run it slowly under xephyr. [don't run it] [run under xephyr] [run it normally anyway]"
<dobey> can we make the click scope just not be used by unity7, too?
<tedg> Basically allow them to comment out the block in aa-exec-click.
<alecu> dobey: it's currently being used on unity7, remember that most of unity-lens-app was merged into it.
<tedg> # Comment out this line if you want to give all your data to everyone
<cjwatson> Or similar :-)
<dobey> alecu: only if you install it, will it be used by unity7 currently
<dobey> alecu: the switch to use it exclusively for apps was only on the touch image for saucy at least
<tedg> mdeslaur, If we don't, askubuntu will.
<alecu> dobey: ah, right
<cjwatson> it's in universe right now so I'm pretty sure it isn't being used in unity7 by default :)
<tedg> mdeslaur, Better to give them with appropriate scariness included.
<dobey> also, what about click apps that are just links to web sites? should those be confied to requiring Mir or the touch browser?
<dobey> or should they work and run firefox/chrome/whatever
<mdeslaur> dobey: links to web sites?
<dobey> mdeslaur: the click "web apps"
<alecu> dobey: there's no way of telling web apps from standard apps as far as the scope is concerned
<mdeslaur> dobey: oh, those run confined too
<dobey> mdeslaur: so they'd require the touch browser?
<Saviq> cjwatson, but then if you install unity8, that would pull the click scope - and it would then show in unity7 as well
<cjwatson> Saviq: oh, I see
<cjwatson> Yeah, via Recommends, hmm
<cjwatson> What would you suggest then?
<Saviq> cjwatson, or wait
<Saviq> cjwatson, we're re-doing the scope backend for unity8
<Saviq> cjwatson, so if there's no click scope for the old backend, it's just not there
<Saviq> cjwatson, so we should actually be fine here
<cjwatson> What's the timeline on that?
 * cjwatson switches to IRC to avoid lag
<dobey> mdeslaur: all the webapp APIs are just dbus calls exposed via JS right? so the dbus confinement should be enough?
<Saviq> cjwatson, 14.04
<jdstrand> dobey: they will use a 'webapp container' which is based on the touch browser
<mdeslaur> dobey: I can't answer that question without thinking about the implications of running it under x
<jdstrand> right
<jdstrand> it might be acceptable. it might not
<dobey> mdeslaur: sure. just trying to raise the question and help clarify it :)
<Saviq> o/
<jdstrand> mdeslaur: I wonder if it makes a difference on if it is stuff we ship (ie, the Canonical webapps) vs arbitrary webapps in the store
* ChanServ changed the topic of #ubuntu-uds-client-2 to: Track: Client | Design and implement a media service for Ubuntu | Url: http://summit.ubuntu.com/uds-1311/meeting/22088/client-1311-media-service/
<jdstrand> mdeslaur: because, as it is, there is no confinement at all for webapps when running under chromium or firefox
<dobey> and there's obvious duplication between click webapps and webapps as packaged in the webapps deb
<jdstrand> so this could improve the situation there, even if there are some potential gaps. but yeah, would want to think about it cause there is also the reputation of click at stake
<jdstrand> anyhoo, food for thought :)
<dobey> yep
<dobey> and on to the next session :)
<dobey> thanks
<diwic> hangout link for the media service session?
<didrocks> diwic: https://plus.google.com/hangouts/_/7acpjrath88ccmnne2ldam7qog?authuser=0
<jhodapp> diwic, feel free to speak up as much as you want since you helped with the music-hub implementation
<tvoss> hello :)
<jdstrand> may I join the fishbowl?
<rsalveti> sure
<jdstrand> what is the url? I just joined so missed it if it was pasted
<rsalveti> https://plus.google.com/hangouts/_/7acpjrath88ccmnne2ldam7qog?authuser=0
<jdstrand> thanks
<sergiusens> tvoss, jhodapp by playlist I think he means, hey, play this list of songs while I'm suspended
<tvoss> sergiusens, that will be supported for sure
<tvoss> sergiusens, we have a play queue right now that the app can fill
<vthompson> sergiusens, that's implemented in the trackList
<vthompson> I assume
<tvoss> thompson, yup, tracklist/playqueue, cannot remember how I called it :)
<sergiusens> sorry, joined late :-)
<sergiusens> shuffling between two sessions
<ricmm> vthompson: I think you meant mediascanner looking up for "playlists" on the fs
<ricmm> however I dont know how the mediascanner could have a concept of a playlist if it hasnt been user created in a predefined format thats storable to disk
<vthompson> ricmm, correct
<thostr> don't think that common format of playlist makes a lot of sense as 3rd party players usually already have their own format
<vthompson> I was only asking the question as to have a reason for the the mediascanner and media service to be a single component
<Elleo> tvoss: presumably whitelisting still needs to be available in general, as there are some apps that can't use the media service (e.g. my spotify clients)
<ricmm> rsalveti: for a QML application its a matter of updating your play status when you go from Qt.application.inactive -> active
<ricmm> so a state transition handler
<ricmm> theres no concept of being resurrected or what not at that high level
<tvoss> Elleo, sure, not talking about general whitelisting
<Elleo> tvoss: okay, cool
<rsalveti> ricmm: right, I was just thinking about the user experience for that
<ricmm> rsalveti: got it
<rsalveti> but guess that depends on how the app is done
<tvoss> Elleo, although we are discouraging whitelisting :)
<Elleo> tvoss: yeah, I don't really have much choice though; I don't have any sort of stream I can pass off to other services
<Elleo> I'm tied to the way libspotify does things
<ricmm> jhodapp: rsalveti tvoss will we be sandwiching this with the platform-API before hitting the client (QtMultimedia) plugin?
<jhodapp> ricmm, in what way?
<ricmm> or is it expected to be direct from QtMultimedia to the service over dbus
<tvoss> ricmm, direct so far
<jhodapp> ricmm, to my understanding, direct
<ricmm> ok
<ricmm> weshould still have a long standing item to integrate it at the p-api level imo
<ricmm> for native apps centralization, but later on of course
<ricmm> not right away
<jhodapp> ricmm, can you give an example?
<rsalveti> right
<rsalveti> in this case we're saying that our media service is kind of our platform-api
<rsalveti> over dbus
<rsalveti> but yeah, would be nice to abstract that properly
<tvoss> ricmm, ideally, we would model it in the papi and expose openmax profiles
<rsalveti> openmax profiles?
<jdstrand> vthompson: btw, music-app needs to move to use mediascanner too, correct? if so, when you are done with that you can ping me to test it under apparmor policy so I can adjust it
<vthompson> jdstrand, we'd use the current mediascanner... we'd need to use the new mediascanner API that will be made for 14.04
<jdstrand> vthompson: if you track your work in bugs, then just add an apparmor-easyprof-ubuntu task for both the mediascanner and media service
<vthompson> jdstrand, *we currently use the existing API
<jdstrand> right
<jdstrand> I mean, when you change, ping me and I can get the apparmor policy together
<jdstrand> since I think music-app is the only to-be-confined consumer of these things right now :)
<vthompson> Sounds good. I'll do so.
<jdstrand> awesome, thanks! :)
<ricmm> jhodapp: what about development practices? considering this is very hardware specific (for the gstreamer backend) there are things that will work differently across devices
<sergiusens> you can't top approve or HApprove ;-)
<jhodapp> lol
<jhodapp> ricmm, good question, sorry I missed it
<tvoss> rsalveti, support openmax ;)
<ogra_> thanks
<jhodapp> ricmm, there are, but if I do my job with the plugins and the media hybris layer, this shouldn't matter
<tvoss> Elleo, just looking at the spotify api: How do you output the frames that are coming via the callback?
<rsalveti> tvoss: right, but why would that be a platform-api thing?
<rsalveti> if we want to abstract the media service itself
<ricmm> why the C api to then abstract another C api
<ricmm> is rsalveti's question I think
<rsalveti> my question is why our api needs to have anything specific to openmax :-)
<ricmm> whats the benefit of an openmax profile instead of direct usage of the platform-api natively
<tvoss> ricmm, rsalveti what I'm trying to say is: let's have the platform API, clean C, easily reusable. And over time, if/when we support openmax, we can use the papi to provide an implementation
<tvoss> rsalveti, it does not have to, that's what I'm saying, too. We are in violent agreement
<rsalveti> but don't we want to the platform-api to use the service?
<rsalveti> which in this case would be dbus
<ricmm> platform-api will use the service and expose itself
<rsalveti> so app -> platform-api -> dbus -> media-service?
<ricmm> I think what tvoss is saying is an example analogue to SDL for example
<ricmm> yes
<tvoss> ricmm, +1
<rsalveti> or app -> qtmultimedia -> qtubuntu-media -> platform-api ->...
<tvoss> rsalveti, yup
<tvoss> rsalveti, that's what I'm saying, too :)
<rsalveti> right, ok :-)
<ricmm> well native its direct, the Qt model if course goes through the chain
<rsalveti> so many abstractions
<rsalveti> ricmm: direct how?
<ricmm> direct to platform-api for native
<ricmm> not direct to service
<rsalveti> right, sure
<ricmm> sorry, miswording
<rsalveti> but no one, besides the platform-api, should be using the service api
<rsalveti> right?
<rsalveti> otherwise we end up supporting 2 different apis for the same thing
<ricmm> indeed
<ricmm> no one but the platform api should know the service implementation
<ricmm> which then allows us to change behind scenes for all types of apps
<ricmm> anyways, DONE with this session, next
<rsalveti> jhodapp: ^
<rsalveti> right
<jhodapp> rsalveti, sorry, had to run quickly
* ChanServ changed the topic of #ubuntu-uds-client-2 to: Track: Client | Need to find alternatives for the SRU process | Url: http://summit.ubuntu.com/uds-1311/meeting/22100/client-1311-webapps-sru-alternatives/
<dbarth> hi
<dbarth> didrocks: are your running this one?
<greyback> o/
<didrocks> dbarth: robru is going to
<didrocks> dbarth: https://plus.google.com/hangouts/_/76cpiqsrkccej2hpsej2g4bim0?authuser=0
<dbarth> cool
<dbarth> we're on
<cjwatson> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-March/000550.html
<cjwatson> found it at last
<cjwatson> the phrasing was for things that come from upstream, but ...
<cjwatson> my example of a currently-outstanding failure is bug 1097833, which I appreciate was for quantal
<udsbotu> Ubuntu bug 1097833 in webapps-applications (Ubuntu Raring) "GooglePlus.js test fails" [Undecided,New] https://launchpad.net/bugs/1097833
<cjwatson> (in fact, that one has failed twice)
<Laney> The process should apply to all webapps, not just the ones that Canonical provides support for
<Laney> yeah, that
<robru> didrocks, we are wrapping up soon
<didrocks> robru: ok
<Laney> you already covered that
<Laney> don't know how much lag I have
<robru> Laney, there's usually a couple minutes lag I think. was just trying to be responsive to IRC ;-)
<dbarth> i am incorrigible, i know...
* ChanServ changed the topic of #ubuntu-uds-client-2 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1311/client-2/ - http://irclogs.ubuntu.com/2013/11/21/%23ubuntu-uds-client-2.html
* ChanServ changed the topic of #ubuntu-uds-client-2 to: Track: Client | Desktop Web Apps | Url: http://summit.ubuntu.com/uds-1311/meeting/22074/client-1311-desktop-webapps/
<dbarth> https://docs.google.com/a/canonical.com/presentation/d/10vetdx3_muY4MCneztuKYD55RtifkryNNmfxwMVObXc/edit#slide=id.g1246cfde2_07
<qengho> hi, D.
<oSoMoN> didrocks, can you send me the link to the hangout?
<alex-abreu> qengho, hey !
<alex-abreu> oSoMoN, https://plus.google.com/hangouts/_/7acpimdnnn05mhnr489us6bccc?authuser=0
<didrocks> alex is so fast!
<alex-abreu> oSoMoN, hoefully that's the right one
<alex-abreu> oSoMoN, yeah efficiency is the key for T ! :)
<alex-abreu> oops
<alex-abreu> didrocks, ^
<oSoMoN> alex-abreu, thanks
<didrocks> yep ;)
<qengho> YAY
<chrisccoulson> hah :)
<qengho> It dies in Cr32, I am pretty sure.
<qengho> NPAPI^
<qengho> Or 33? Something.
<qengho> Yes, soon.  The current Dev channel, I think.
<qengho> Now +2
<qengho> I do not think that we didn't say would stop Phoronix from reporting it.
<chrisccoulson> in that case, we're switching to w3m
<alex-abreu> qengho, now it is mentioned in the irc logs at least ! ...
<qengho> I heard the DEFAULT WEB BROWSER is going to be XEMACS.
<chrisccoulson> lol
<robru> dbarth, yep, i can review
<dbarth> robru: cool
<dbarth> thanks everyone
<alex-abreu> thx
* ChanServ changed the topic of #ubuntu-uds-client-2 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1311/client-2/ - http://irclogs.ubuntu.com/2013/11/21/%23ubuntu-uds-client-2.html
