[03:33] <EricPoe> Setting up deja-dup in Ubuntu 14.4. When attempting to connect to my SSH box, deja-dup claims "SSH program unexpectedly exited" Ideas? Know where this is logged?
[03:36] <EricPoe> I can ssh into my SSH box as the same user without a problem.
[08:17] <tsdgeos> Cimi: so what about that issue with carousel?
[08:17] <tsdgeos> dednick: are you doing https://code.launchpad.net/~saviq/unity8/cmake-plugin-cleanup/+merge/218171 as Saviq asked or shall i jump in?
[08:18] <dednick> tsdgeos: ah. i can do.
[08:19] <tsdgeos> dednick: tx
[08:20] <Cimi> tsdgeos, I confirm is with your branch
[08:26] <tsdgeos> ok
[08:30] <tsdgeos> Saviq: so https://codereview.qt-project.org/#change,85437 sent upstream, i'll work in patches to our 5.2.1 packages that use it instead of delegate range and patches to unity8 to use displayMargin instead of delegateRange
[08:42] <tsdgeos> Mirv: ping
[08:43] <Mirv> tsdgeos: hangout pong
[08:43] <dednick> Saviq: that plugin cmake branch. I can't seem to run unity8 on desktop when I removed unity8 system installed folders. "Need to use QMirServerApplication"
[08:44] <dednick> Saviq: works on trunk though
[08:45] <tsdgeos> Mirv: i need to do a patch for our qt 5.2 packages to bring one of the patches we have closer to upstream, what's your preferred way of me doing that change?
[08:45] <Mirv> tsdgeos: LP bug with info on what to do inside current debian/patches/
[08:45] <tsdgeos> Mirv: oki, tx
[08:45] <Mirv> tsdgeos: is that ^ something that'd be nice on 5.3 RC packages, and would it help with the empty scopes? (have you tried the RC packages on device?)
[08:46] <tsdgeos> Mirv: yes
[08:47] <tsdgeos> Mirv: but on the 5.3 packages we'd need a somewhat different patch, i'll work on that too
[08:47] <Mirv> \o/ I'll kick that in, it'd be nice to have something demoable of 5.3 next week
[08:47] <Mirv> tsdgeos: doesn't the codereview on targeted to 5.3 work?
[08:48] <tsdgeos> Mirv: 5.3 is only for "BIG AMAZING VERY URGENT" bugs now only
[08:48] <tsdgeos> so i'm targetting what we miss from upstream to 5.3.1
[08:48] <tsdgeos> so plan is
[08:48] <tsdgeos> bring to our 5.2 packages what would end up in 5.3.1 if they accept my patch
[08:48] <tsdgeos> and then add to our 5.3 packages my small patch
[08:49] <tsdgeos> so it's all in sync
[08:49] <Mirv> tsdgeos: yeah, I just mean that if I add https://codereview.qt-project.org/#change,85437 to 5.3 RC is that joy?
[08:49] <tsdgeos> and we can move unity8 to and from our 5.2/5.3 packages
[08:49] <tsdgeos> Mirv: no, i need to update unity8 too
[08:49] <tsdgeos> Mirv: to use that new property, that's why i want to backport htat new property to 5.2 so i can also change unity8
[08:49] <Mirv> ah, ok right. I can build that meanwhile in the 5.3 test PPA and wait until there's something for unity8 (I can manually patch too the test package)
[08:49] <tsdgeos> and then all is nicely aligned
[08:50] <Mirv> sounds good
[08:58] <greyback> dednick: QMirServerApplication from unity-mir, unity8's main.cpp creates it. The unity-mir QML plugin depend on it (they are teh ones printing that message)
[09:00] <Saviq> tsdgeos, awesome
[09:12] <Cimi> tsdgeos, fixed xvfb tests
[09:15] <tsdgeos> Saviq: so was discussing with Cimi if the shadow for the card carousel we should add it to the carousel code or to the card code
[09:15] <tsdgeos> Saviq: what's your opinion?
[09:15] <Cimi> tsdgeos, in cardCarousel :)
[09:15] <Saviq> tsdgeos, since it's only ever used in carousel
[09:15] <Saviq> tsdgeos, I'd put it in CardCarousel, or Carousel itself even
[09:16] <tsdgeos> ok
[09:16] <Saviq> tsdgeos, it depends on what kind of items we say we support in the Carousel
[09:16] <Cimi> Saviq, carousel no, since it should stay abstract
[09:16] <Saviq> Cimi, maybe yeah
[09:16] <Saviq> having a shadow might be abstract no less, though
[09:16] <Cimi> Saviq, but in the branch I made it quite abstract inside cardCarousel
[09:16] <Saviq> if that's "part of the carousel"
[09:17] <Cimi> Saviq, but it's not a proper shadow
[09:17] <Cimi> Saviq, made with shaders
[09:19] <Saviq> lol ;)
[09:25] <mhr3> Saviq, when will we have new header in dash? :)
[09:26] <karni> since we're on the subject - font color on the card overlay is not legible on some backgrounds. even if someone points I may have written that code (yes, I may have), we have to improve it. often I see dark grey font on dark overlay. don't remember if the font color is dynamic in that widget.
[09:41] <Saviq> karni, I think the only place where it's not readable is when the image itself is not opaque (which is the case for the "unknown" album image)
[09:42] <Saviq> mhr3, we need to look at it indeed, the only problem is you suddenly lose the ability to quickly switch between scopes (at least until we get designs and implement the bottom edge behaviour in the dash)
[09:42] <mhr3> Saviq, not really a problem with 4 scopes, and with 10+ it was a problem anyway :)
[09:43] <Saviq> mhr3, true, true
[09:43] <Saviq> mhr3, but was still easier with the swipable header
[09:43] <Saviq> is
[09:43] <mhr3> right
[09:43] <karni> Saviq: you've got mal
[09:43] <karni> *mail
[09:44] <Saviq> karni, don't show that to designers :P
[09:44] <karni> heh :) but, do you agree we have a small problem there?
[09:45] <Saviq> karni, that depends, I don't think we should have overlay and then summary below, though
[09:45] <karni> I think solid white in overlay mode would be much better.
[09:45] <Saviq> karni, it is solid white, until you turn on background AFAICT
[09:46] <karni> Saviq: well. I showed a couple options to our product manager, and he liked it :D if we can't do that, the shell shouldn't allow it. (FWIW I like the looks, too)
[09:46] <Saviq> karni, the first thing that springs to eyes is the double shape
[09:46] <Saviq> karni, that really shouldn't happen, and yeah, I agree we should prevent that, but right now we don't have any validation in place, really
[09:48] <karni> Too bad, I liked it. I wonder if we could somehow disable the bottom part of ubuntu shape when the summary is present ;D
[09:48] <Saviq> karni, that was the design indeed - art was only shaped at the top, with header and summary below it, within a single shape with a background
[09:49] <karni> Saviq: what did you mean when you said "until you turn on background" - which background? I'm not sending any colors
[09:49] <karni> Saviq: ah I see, very cool then
[09:49] <Saviq> karni, well, how did you get the white background behind the whole card then?
[09:50] <Saviq> hmm do we enable t ourselves? /me looks
[09:50] <karni> Saviq: you tell me :D http://paste.ubuntu.com/7467065/
[09:50] <karni> Saviq: no idea
[09:51] <karni> It just looked nice as it were, I didn't change colors.
[09:51] <Saviq> karni, ok, so I think you should disable the overlay, it wouldn't look nice with the image as designed (square at the bottom) anyway I'd say
[09:52] <Saviq> karni, you could use a mascot there probably
[09:52] <karni> Saviq: I'll send screenshots to product manager and let him know what's up
[09:52] <karni> Saviq: well, the point is, we wanted large images there :) you know, more colors and candy
[09:53] <karni> so I won't replace art for a mascot in this case
[09:53] <Saviq> karni, well, sure, keep the large image
[09:53] <karni> Saviq: what did you mean by mascot then?
[09:53] <karni> it's optional, right?
[09:53] <Saviq> karni, a mascot, if you had it, would break the whole white space below the image
[09:53] <karni> oh
[09:53] <Saviq> because indeed title + subtitle + summary just one under the other will probably not look that great
[09:54] <karni> I get your point now
[09:55] <karni> it's an RSS feed, so.. no mascot candidate :( (site icon wouldn't make sense, all posts from single source)
[09:56] <Saviq> karni, heh, now I looked at tryCard we have exactly the same layout you've shown, just no mascot ;)
[09:57] <Saviq> karni, the weird thing is, though, that the overlay *is* white, and has correct margins
[09:58] <karni> Saviq: i noticed if there's no mascot, right margin is 0, if mascot is there, margins are correct
[09:58] <Saviq> karni, yeah, I disabled mascot
[09:58] <Saviq> karni, are you using latest trunk btw?
[09:58] <karni> Saviq: also, just found a bugzzie: if you have 'overlay': 'false', it still shows the overlay. you have to *remove* the 'overlay' key for the overlay to go away. would you like me to file a bug?
[09:59] <Saviq> karni, again, not the case here
[09:59] <karni> Saviq: you'll kill me now ;P - I flashed on Mon or Tue. I'll do it now.
[09:59] <Saviq> karni, yeah, the whole card mechanism got reworked since then
[09:59] <karni> Saviq: ok, sorry to take your time. I'll re-check that now.
[10:00]  * karni takes note to go back to re-flashing at least each morning
[10:07] <Saviq> karni, no, just use trunk on your desktop for developing scopes ;)
[10:07] <Saviq> karni, only you'd need to upgrade to utopic, but it's about time for that anyway isn't it!
[10:12] <mhr3> Saviq, noticing there's more flicker when searching now, did you see that?
[10:14] <Saviq> mhr3, maybe because it's faster! ;)
[10:14] <Saviq> mhr3, let me see
[10:16] <Saviq> mhr3, AFAICT it's indeed because it's faster, the delegates get destroyed and recreated quicker
[10:17] <mhr3> Saviq, but it feels like there's an extra frame now
[10:17] <mhr3> Saviq, i see it when doing "setting" -> "settings" and back
[10:18] <Saviq> mhr3, well, you give us a complete new set of models
[10:19] <mhr3> Saviq, but i always did :)
[10:19] <Saviq> mhr3, maybe it's because the mascot goes away and back in only when loaded
[10:19] <Saviq> mhr3, right, we're lazy-loading the shapes now
[10:19] <Saviq> mhr3, so the text shows up before the shape does
[10:19] <mhr3> ok, that explains that
[10:19] <Saviq> mhr3, although we should've catered for it
[10:20] <Saviq> or maybe not... we don't know whether the mascot is going to be there or not..
[10:20]  * mhr3 waits for Saviq to mention diffs again
[10:20] <Saviq> oh right!
[10:20] <Saviq> if you didn't reset all our models, all would be fine!
[10:21] <Saviq> mhr3, I was thinking about the departments...
[10:21] <Saviq> arrrgh
[10:21] <Saviq> maybe not
[10:21] <Saviq> ;(
[10:22] <Saviq> we had a plan! and they broke it :/
[10:25] <mhr3> Saviq, i'll get to properly think about them once i finish this docs crap
[10:26] <Saviq> mhr3, pfft!
[10:26] <Saviq> /food
[10:31] <Saviq> mzanetti, btw, what's the status of silo 005? any ETA?
[10:31] <Saviq> /reallyfood
[10:31] <mzanetti> greyback: ^
[10:32] <greyback> Saviq: working on a fix for a bug there
[10:32] <mzanetti> Saviq: well, still that one issue in unity-mir to fix, although I'm not sure any more if its really an issue of that branch. I think I saw the same with the promoted image yesterday night
[10:32] <mzanetti> but it was really late :D
[10:32] <Saviq> greyback, mzanetti, just asking whether I should hijack the silo and land other changes in there, or maybe land other changes separately, or wait?
[10:33]  * greyback doesn't have an opinion
[10:34] <Saviq> ok, food first, then let's see how we are
[10:34] <Saviq> last unity8 promotion took 16h :(, we need to fix that
[10:34] <mzanetti> ok. I'll test in the meantime where the issue is introduced
[10:44] <mzanetti> greyback: Saviq: ok... launching something via url dispatcher seems to be broken in the latest images already
[10:45] <greyback> mzanetti: I can't /really/ land my changes until that's fixed tho. We can't reliably test
[10:45] <mzanetti> yeah. I agree
[10:46] <mzanetti> greyback: so you're saying you want to fix that in the same branch, right?
[10:46] <mzanetti> greyback: assuming its indeed an issue in unity-mir
[10:46] <greyback> mzanetti: unity-mir hasn't changed in some time afaik
[10:47] <mzanetti> ok
[10:47] <greyback> last change was >2 weeks ago, so I doubt unity-mir is to blame (this time)
[10:47] <mzanetti> greyback: any easy to verify that?
[10:48] <mzanetti> +way
[10:48] <greyback> mzanetti: am just reflashing to repro it now
[11:00] <greyback> mzanetti: just flashed phone, it opened settings from the indicators fine
[11:01] <mzanetti> greyback: really...
[11:01] <mzanetti> I tried with the indicators and also launching the browser from tagger after scanning a barcode
[11:01] <mzanetti> greyback: which image did you flash?
[11:01] <mzanetti> which channel
[11:02] <karni> Saviq: yes, it's about time to upgrade :)
[11:02] <greyback> mzanetti: devel-proposed
[11:02] <greyback> image 30
[11:03] <mzanetti> greyback: strange... same here. but I really can't open settings from the indicators
[11:03] <mzanetti> think there might be something in the home directory that breaks it?
[11:03] <greyback> mzanetti: any REJECTED messages in ~/.cache/upstart/unity8.log?
[11:04] <mzanetti> greyback: nope, not a single message printed
[11:05] <greyback> mzanetti: that's also not right...
[11:05] <mzanetti> greyback: well, not a single line when tapping the entry in the indicators
[11:05] <mzanetti> unity8 does print other stuff
[11:05] <greyback> ah ok
[11:06] <mzanetti> I can try to wipe it completely...
[11:06] <tsdgeos> Mirv: Saviq: any idea how we get a silo with https://bugs.launchpad.net/ubuntu/+source/qtdeclarative-opensource-src/+bug/1319777 ?
[11:06] <greyback> mzanetti: there are url dispatcher logs in that directory too
[11:07] <mzanetti> greyback: ah, that's interesting: ** (process:1431): WARNING **: Unable to parse SQL to find url
[11:09] <mzanetti> ok, /me wipes the phone completely
[11:09] <Cimi> tsdgeos, is it possible to access model rules without using listview, gridview etc etc?
[11:10] <mzanetti> Cimi: repeater
[11:10] <Cimi> mzanetti, but I need one of those, right?
[11:10] <Cimi> mzanetti, I mean model[index] or so won't work?
[11:10] <mzanetti> Cimi: usually we add get() methods to the models
[11:11] <mzanetti> Cimi: but if the model doesn't have them no, you can't access it without a Repeater or *View
[11:12] <Cimi> mzanetti, maybe we can add it
[11:12] <Cimi> pete-woods, can we add get methods to the infographics model?
[11:13] <mzanetti> if the items are QObjects, make a "MyItem* get(int index) const"
[11:13] <mzanetti> otherwise I guess "QVariant get(int index, int role) const" would do
[11:14] <pete-woods> Cimi: okay, sure, gimme an example of this pattern and I'll add those methods
[11:14] <tsdgeos> i hate quilt ^_^
[11:15] <tsdgeos> well debian packaging in general
[11:15]  * tsdgeos just compiles and copies stuff over
[11:15] <Cimi> mzanetti, can you guide pete-woods on adding those methods?
[11:15] <mzanetti> pete-woods: if the items are QObjects, make a "MyItem* get(int index) const", otherwise I guess "QVariant get(int index, int role) const" would do
[11:16] <pete-woods> mzanetti: okay, really that simple then
[11:16] <mzanetti> pete-woods: yeah, just make them Q_INVOKABLE and that's it
[11:16] <pete-woods> mzanetti: cool, thanks, I'll get on that
[11:17] <mzanetti> pete-woods: http://bazaar.launchpad.net/~unity-team/unity-api/trunk/view/head:/include/unity/shell/launcher/LauncherModelInterface.h
[11:17] <mzanetti> pete-woods: line 108
[11:18] <Cimi> pete-woods, thank you, that way I can play with the interface more freely
[11:18] <Saviq> tsdgeos, the usual, we talk to Mirv
[11:18] <mzanetti> pete-woods: that's an example where the items are QObjects (which means QML can just use it like this: Model.get(5).roleName
[11:18] <pete-woods> mzanetti: cool, thanks, in my example they are just going to be QStrings
[11:20] <mzanetti> greyback: yep. after wiping the device it works again
[11:20]  * mzanetti adds back silo 5
[11:20] <Saviq> tsdgeos, we'd need the unity8 patch with it, though
[11:20] <tsdgeos> Saviq: sure, working on that
[11:21] <Saviq> tsdgeos, Q: we're not creating any delegates outside of the view (like currentBuffer), do we?
[11:21] <Saviq> erm
[11:21] <Saviq> cacheBuffer
[11:21] <tsdgeos> Saviq: tried to compile the thing properly but gave up and i'm just copying the .so :D
[11:21] <tsdgeos> Saviq: cachebuffer is still taken into account
[11:21] <Saviq> tsdgeos, I mean with delegate ranges it isn't is it?
[11:21] <tsdgeos> it's added at a latter stage
[11:21] <Saviq> tsdgeos, ah
[11:22] <tsdgeos> it should
[11:22] <Saviq> tsdgeos, but we're not setting it in our views are we?
[11:22] <Saviq> ah well, it's set to like 320 by default?
[11:22] <tsdgeos> there's the default value there i understand
[11:22] <Saviq> right
[11:22] <Saviq> ok then
[11:22] <tsdgeos> which is not really helpful with high dpi
[11:23] <Mirv> tsdgeos: maybe it'd be easiest to get tested if I'd land it together with qtpim that's also being planned
[11:25] <tsdgeos> Mirv: maybe :D
[11:25] <Mirv> tsdgeos: so what do I call the patch "Q", what do I disable/remove from current patches etc... or would you rather do a merge request towards  lp:~kubuntu-packagers/kubuntu-packaging/qtdeclarative-opensource-src while at it?
[11:25] <tsdgeos> Mirv: as the bug says, you remove qtquick_delegate_creation_range_itemviews.patch and add Q
[11:26] <Mirv> tsdgeos: and the "QQuickItemView-QQuickPathView-Fix-creation-of-delega.patch" stays as is?
[11:26] <tsdgeos> you can call it qtquick_displayMargin.patch
[11:27] <tsdgeos> Mirv: that's unrelated yes
[11:27] <Mirv> ok, that was the only uncertainty then. and yes, it seems to apply.
[11:29] <tsdgeos> :)
[11:30] <Mirv> tsdgeos: ok, aiming https://code.launchpad.net/~timo-jyrinki/kubuntu-packaging/qtdeclarative_update_delegate_patch_lp1319777/+merge/219686 towards the silo (when I get one) so that I could then test qtpim+qtdeclarative at the same test run
[11:30] <tsdgeos> Mirv: cool :)
[11:30] <tsdgeos> i'm on the unity8 side
[11:30] <tsdgeos> Mirv: will give you a unity8 branch asap
[11:30] <Mirv> tsdgeos: with 5.2, there's however no need on simultaneous unity8 update, is there?
[11:31] <tsdgeos> Mirv: yes there is
[11:31] <Mirv> tsdgeos: oh, ok, so adding _that_ to the landing too then
[11:31] <Mirv> and marking it's not yet ready actually too
[11:31] <mzanetti> Saviq: greyback: rebuilding packages in silo 5. now that url-dispatcher works again I'm confident we can get this through soon
[11:31] <tsdgeos> Mirv: untiy8 is using the "old" property, since we're switching to the new "upstream one" we need to update unity8 code too
[11:31] <Mirv> cool, thanks albert
[11:32] <mardy> greyback: hi! Do I need to add a changelog entry to https://code.launchpad.net/~mardy/unity-mir/signonui-with-oxide/+merge/216845, since there is no bug linked?
[11:32] <Mirv> I added "here-be-unity8" as a placeholder to the MP field
[11:32] <tsdgeos> thank you :)
[11:36] <greyback> mardy: I have no idea. CI train generates the changelog automatically, no? But from what, I don't know
[11:36] <mardy> greyback: OK, I'll try leaving it without one, we'll see
[11:37] <greyback> mardy: yep
[11:38] <asac> sil2100: ^^ you know how the merge back changelog is generated? guess something for our non-existing FAQ :P
[11:38] <Saviq> mzanetti, ok, will wait, thankx
[11:39] <sil2100> mardy, greyback: so, no need for a changelog entry - citrain generates changelog entries from commit messages :)
[11:39] <sil2100> mardy, greyback: so as long as you have commit messages that sound alright, everything should be fine
[11:42] <greyback> sil2100: good to know, thanks
[11:43] <mardy> sil2100: thanks
[11:53]  * greyback goes to reboot router
[12:08] <mhr3> tsdgeos, pushed the docs to -api, pls check
[12:15] <Saviq> and now I need to plough through it :P
[13:03] <tsdgeos> Saviq: you doing it?
[13:03] <kgunn> Saviq: tsdgeos ...a lot of good feedback on the perf improvement, kudos to you guys
[13:03] <Saviq> tsdgeos, the review?
[13:03] <tsdgeos> :)
[13:03] <Saviq> tsdgeos, gotta do something else first
[13:03] <tsdgeos> Saviq: mhr3's docs thing
[13:03] <Saviq> tsdgeos, I think this just needs a review now
[13:03] <tsdgeos> oki
[13:03] <Saviq> tsdgeos, so unless you can make mzanetti review it, I'm it
[13:03] <tsdgeos> he he
[13:04] <mzanetti> review what?
[13:04] <mzanetti> tsdgeos: ^
[13:04] <tsdgeos> mzanetti: https://code.launchpad.net/~unity-team/unity-api/unity-shell-scopes-api/+merge/219379
[13:05] <mzanetti> that's long :D
[13:05] <mzanetti> ok, I guess I can review that
[13:18] <kgunn> looks like app shutdown fix is ready, needs another set of eyes for a double check...
[13:18] <kgunn> https://code.launchpad.net/~gerboland/unity-mir/fix-upstart-closed-apps2/+merge/218721
[14:11] <Cimi> damn allergy
[14:30] <Saviq> dednick, standup
[14:57] <tsdgeos> Mirv: can you add https://code.launchpad.net/~aacid/unity8/useDisplayMargin/+merge/219709 to that new silo for Qt?
[14:57] <Saviq> dednick, fixed cmake cleanup
[15:08] <Saviq> greyback, FWIW, if only webapps got exec()'ed and not forked, we wouldn't have this problem...
[15:08] <Saviq> greyback, so maybe that'd be a better thing to fix?
[15:08] <greyback> Saviq: true, but we do, so gotta deal with it
[15:09] <Saviq> greyback, well, we can make sure that webapps don't fork
[15:09] <Saviq> greyback, I mean that the main process needlessly changes PID, that's the main problem right?
[15:09] <Saviq> greyback, which suggests webbrowser forks, and exits just after
[15:09] <greyback> Saviq: actually I don't think that would fix the issue. It's mainly that unity-mir cannot tell that a session, which comes from a process spawned by the webprocess, is part of that webprocess
[15:10] <Saviq> greyback, well, browser and gmail behaved fine?
[15:10] <greyback> Saviq: instead it hacks around it by simply accepting any session that is a QtWebProcess.
[15:11] <Saviq> greyback, yeah, but... once the container is forked, doesn't the main PID of the upstart app change? does upstart know about it?
[15:12] <greyback> Saviq: I'm not certain tbh
[15:12] <Saviq> greyback, empirically, gmail was special because its main process was "webapp-container" directly
[15:12] <greyback> Saviq: but yes, the PID change does make life harder
[15:12] <Saviq> greyback, so for now we need to enforce that PID doesn't change
[15:13] <greyback> but I don't think fixing it will make all unity-mir's problems go away
[15:13] <Saviq> greyback, same we did when people had bash scripts, made them exec
[15:13] <Saviq> greyback, but will let us not have to carry this workaround for now
[15:13] <greyback> Saviq: right
[15:13] <Saviq> greyback, when the fact that they fork and not exec is unnecessary in any case
[15:13]  * Saviq finds out what upstart things about it
[15:14] <Saviq> *thinks
[15:17] <Saviq> greyback, hmm the PID doesn't change apparently:
[15:17] <Saviq> $ start application-click APP_ID=net.sawicz.michal.jakdojade_example_0.1.1
[15:17] <Saviq> application-click (net.sawicz.michal.jakdojade_example_0.1.1) start/running, process 12199
[15:17] <Saviq> phablet  12199 87.2  2.1 250396 40504 ?        Ssl  17:16   0:03 webapp-container --webapp --enable-back-forward...
[15:17] <Saviq> unless it changes quickly enough that upstart notices
[15:18] <tsdgeos> Saviq: in https://code.launchpad.net/~aacid/unity8/use-unity-api/+merge/219222 you mention "Needs to depend on libunity-api-dev (>= 7.81)"
[15:19] <tsdgeos> Saviq: shall i do that in https://code.launchpad.net/~unity-team/unity-api/unity-shell-scopes-api/+merge/219379 ?
[15:19] <tsdgeos> ah you commented
[15:19] <tsdgeos> :D
[15:19] <Saviq> tsdgeos, ;)
[15:19] <Saviq> greyback, I just worry about WTH does webbrowser and gmail behave fine
[15:20] <greyback> Saviq: I'm more than a little confused by that tbh
[15:20] <Saviq> greyback, could you see that it indeed starts two sessions (or more, actually)?
[15:24] <mhr3> Saviq, eek! forking good, exec bad!
[15:24] <Saviq> mhr3, not yet
[15:24] <mhr3> always! :P
[15:25] <Saviq> mhr3, not until we can group sessions from multiple processes under the same app
[15:25] <Saviq> mhr3, and not until they can't escape it, for that matter :P
[15:25] <greyback> Saviq: starting Jakdojade, 3 sessions are created. Not sure if they're unique. Need more time to dig
[15:25] <mhr3> Saviq, cause we have thousands of apps doing that now? :)
[15:25] <Saviq> mhr3, "doing what"?
[15:26] <mhr3> Saviq, forking after launch
[15:26] <Saviq> mhr3, not on phone we don't
[15:27] <Saviq> greyback, ktx
[15:27] <Saviq> mhr3, except for browser/webapp/something, which behave somewhat weirdly
[15:27] <mhr3> Saviq, so we want to be able to group them properly, while that isn't really necessary at this point, but throwing away the massive speed improvements that fork brings
[15:27] <Saviq> mhr3, I'm not sure what you're here after ;)
[15:28] <mhr3> priorities
[15:28] <Saviq> mhr3, you mean like launch boosting and such?
[15:28] <mhr3> yes
[15:28] <Saviq> greyback, btw, it's probably a lower prio task, if you tell me you don't want to spend time on it now, don't
[15:28] <Saviq> mhr3, we can't do that right now either ;)
[15:29] <mhr3> doesn't mean we should close those doors
[15:29] <Saviq> mhr3, I think you're misunderstanding :)
[15:29] <Saviq> mhr3, it's a current limitation of unity-mir that it only expects a single session under the main upstarted PID
[15:30] <Saviq> mhr3, launch boosters will obviously need something special anyway
[15:30] <Saviq> mhr3, to inject that PID into an upstart / systemd job
[15:30] <Saviq> mhr3, but I'm not talking about "closing doors"
[15:30] <mhr3> indeed, i just saw the exec == good and my alarms went off
[15:31] <Saviq> mhr3, I'm just talking about apps (which are all currently exec'ed anyway - until we get a launch booster at least)
[15:31] <Saviq> mhr3, that break out of app management because they fork and upstart / unity-mir loses track
[15:32] <Saviq> mhr3, where there is no benefit to them forking in that case
[15:32] <Saviq> mhr3, 'cause the process from which they forked was _just_ exec'd a cycle agi
[15:32] <Saviq> ago
[15:32] <mhr3> Saviq, just saying we shouldn't care, let them escape if we can launch them fast for rtm :)
[15:32] <Saviq> mhr3, we can't let them escape, 'cause we lose track of them
[15:33] <mhr3> if they launch fast... meh
[15:33] <mhr3> priorities! :P
[15:33] <elopio> kgunn: are you coming to the meeting?
[15:34] <Saviq> mhr3, we lose track of them, do you get it? DO YOU GET IT? ;)
[15:34] <Cimi> pete-woods-lunch, there are conflicts, launchpad says
[15:34] <Saviq> mhr3, unless upstart tells us that this forked PID is app foo
[15:34] <Cimi> pete-woods-lunch, can you push it to the silo after that?
[15:34] <Saviq> mhr3, we'll reject it
[15:34] <mhr3> Saviq, i have a branch for that ;)
[15:35] <Saviq> mhr3, we have holes poked to allow web renderer processes, signon UI and maliit
[15:35] <mhr3> Saviq, http://bazaar.launchpad.net/~mhr3/unity-mir/authenticate-via-apparmor/revision/216
[15:36] <Saviq> mhr3, right, sure, that'd be one way
[15:37] <mhr3> Saviq, any other concerns? ;)
[15:37] <Saviq> mhr3, the HACK part in there :P
[15:38] <mhr3> it allows apps to launch fast!
[15:38] <mhr3> priorities! :D
[15:38] <Saviq> mhr3, UPSTART
[15:38] <mhr3> will go away
[15:38] <mhr3> finally!
[15:38] <Saviq> mhr3, so will support for non-upstarted apps :P
[15:39] <Saviq> anyway, otp
[15:40] <mhr3> Saviq, you just need to see the magic where apps actually launch instantly and you'll close one eye ;)
[15:42] <Saviq> mhr3, port us to systemd, inject those PIDs into systemd jobs and we'll be fine!
[15:45] <tsdgeos> mterry: if you remove the qscreen include i'll approve https://code.launchpad.net/~mterry/unity8/split/+merge/213149
[15:46] <mterry> tsdgeos, oh duh thanks
[15:47] <pete-woods> Cimi: fixed the conflict, I wish people would stop pushing things to distro without going through the CI train
[15:48] <mhr3> Saviq, and maybe you'll close both eyes :)
[15:48] <greyback> Saviq: somehow oxide based webbrowser only opens 1 Mir session. Whereas QWebProcess-based browsers open multiple sessions
[15:49] <Saviq> greyback, ah so that's the difference...
[15:49] <Saviq> greyback, ok, let's just get this in
[15:49] <greyback> Saviq: +1
[15:49] <mterry> tsdgeos, done
[15:50] <tsdgeos> tx
[15:51] <pete-woods> Saviq: could you trigger a rebuild on the libusermetrics silo when you get a moment?
[15:53] <Cimi> Saviq, I cannot use crossfadeImage for infographics, will implement a new animation
[15:53] <Cimi> Saviq, just tested with crossfadeimage, if I have image A and B
[15:53] <Cimi> what happens between the transition to image B
[15:53] <Cimi> A.opacity is always 1.0
[15:54] <Cimi> then B from 0 becomes 1
[15:54] <Cimi> when B.opacity is 1, A.opacity turns 0
[15:55] <Cimi> what we want here is a crossfade where A.opacity goes from 1 to 0 and B.opacity from 0 to 1 at the same time
[15:55] <Cimi> I am not sure we want to add this to the SDK
[15:55] <tsdgeos> Cimi: can you please open a bug about the thing you foudn in the carousel so i remember for monday?
[15:55] <Cimi> tsdgeos, sure
[15:56] <Cimi> tsdgeos, assigning you?
[15:56] <Cimi> or subscribing?
[15:56] <tsdgeos> Cimi: assign me
[15:57] <Saviq> greyback, and QWebProcess-based things will be phased out in time
[15:57] <Saviq> greyback, so yeah, let's not put work in there any more
[15:57] <greyback> Saviq: so I expect
[15:57] <Saviq> pete-woods, just camera-app?
[15:58] <pete-woods> Saviq: it's just libusermetrics, the camera app shouldn't have changed
[15:58] <Saviq> pete-woods, there's a newer version in distro, so I'll kick both then
[15:58] <Cimi> tsdgeos, https://bugs.launchpad.net/unity8/+bug/1319907
[15:58] <pete-woods> Saviq: I've just pushed an updated version of the camera app, so at least the versions should match
[15:59] <Saviq> pete-woods, it would merge trunk anyway
[15:59] <Saviq> pete-woods, ah but yeah, if there was some kind of stuff like that
[15:59] <Saviq> pete-woods, it probably would've complained
[15:59] <Saviq> Cimi, I think the "style" of the crossfade should be an option
[16:00] <Saviq> Cimi, but a crossfade where they both run at the same time goes to background (black) in the middle, that's why it was made this way
[16:00] <Saviq> Cimi, basically, it doesn't work for opaque images
[16:01] <Saviq> Cimi, in case of infographics we might indeed need them to crossfade like you said
[16:01] <Saviq> Cimi, but I think the same component (CrossFadeImage) should be used, just configured differently
[16:02] <Saviq> greyback, ok, I'll look at the branch first thing tomorrow
[16:11] <mhr3> mhall119, ping?
[16:11] <Saviq> mzanetti, you can invoke rowCount() with no arg to get... the row count ;)
[16:11] <tsdgeos> mhr3: mzanetti did some comments on the unity-api changes, i'm out until monday but if you want to comment/act on them great, otherwise i'll take them when i'm back on monday
[16:12] <mhr3> checking
[16:23] <mhall119> mhr3: pong
[16:23] <mhr3> mhall119, haven't heard back from you about the docs, and they don't seem to be updated, anything still missing?
[16:24] <mhall119> mhr3: no, yesterday I had to update my scripts to get the new UITK docs uploaded because they were broken
[16:26] <mhr3> mhall119, thomas would like to see the mention of server scopes removed from the current docs (which happened in our trunk and is released in U)
[16:26] <mhr3> any chance to get that update to duc?
[16:28] <mhall119> mhr3: removed from the 14.04 docs, or just not included in 14.10 docs?
[16:29] <mhr3> mhall119, both
[16:29] <mhall119> was it in 14.04?
[16:29] <mhall119> http://developer.ubuntu.com/api/scopes/sdk-14.04/
[16:29] <mhr3> yes
[16:29] <mhr3> and it shouldn't
[16:29] <mhall119> then shouldn't it be in the docs for 14.04?
[16:30] <mhall119> heh, answered before I could ask
[16:30] <mzanetti> Saviq: right... still I think a count property would be better in that case. if not for technical reasons, at least to align it with the rest of this and the other apis
[16:31] <mhr3> mhall119, basically, just update the docs on duc from the current U pkg
[16:31] <mhr3> both 14.04 and 14.10
[16:32] <mhr3> we'll deal with sru-ing stuff, and figuring out whether it's really necessary
[16:36] <mhall119> mhr3: you want the 14.10 docs uploaded into the 14.04 docs space?
[16:37] <mhr3> yes
[16:37] <mhr3> mhall119, ^
[16:44] <mhall119> that feels wrong
[16:44] <mhall119> I'll do it, it's your stuff and you guys have to support it, but it feels wrong
[16:51] <Saviq> mhr3, can we get rid of formFactor from scopes API?
[16:55] <kgunn> mhall119: btw, mir had the same problem
[16:55] <kgunn> wrt loading up "new" docs
[16:56] <kgunn> just sharing..
[16:57] <kgunn> greyback: Saviq in your opinions, what are we lacking in terms of being able to upstream our qtubuntu (qt-mir) backend? as i recall there was some interest in this from upstream
[16:57] <Saviq> kgunn, I believe greyback referred to that idea in a "NOOOOOO not yet, it's ugly!" manner
[16:58] <Saviq> kgunn, but QtCS will be a good place to spark a discussion on this
[16:58] <greyback> kgunn: it needs significant cleaning up (still lots of SF code in there). We also need to talk with them to see their opinion on the ubuntu specific bits
[16:58] <mhr3> Saviq, hm, i'm unaware of any scopes actually using it, so theoretically we could, but it is in the api
[16:58] <kgunn> ok, something to take up post Qt comp
[16:58] <mhr3> Saviq, why don't you want to pass it?
[16:59] <Saviq> mhr3, https://docs.google.com/a/canonical.com/presentation/d/1K1oV4vMc-FduKUNYYO62zPUCU5WMb74zjer8KzYzhLg/edit
[16:59] <mhr3> Saviq, formFactor: "with-keyboard"? :)
[17:01] <Saviq> mhr3, don't get me started on "with-keyboard", we just managed to get rid of the need for that in UITK today ;)
[17:01] <mhr3> Saviq, imo we should keep it, it might be interesting for some (mostly server) scopes, but we can say in docs that whatever is there shouldn't matter for most use cases
[17:01] <mhall119> mhr3: in a CC meeting now,  but that's on my list to do when it's over
[17:01] <mhr3> mhall119, thx
[17:01] <Saviq> mhr3, well, we won't *know* the form factor
[17:02] <mhr3> Saviq, hm... ok that sucks
[17:02] <Saviq> mhr3, so sending it will be rather difficult
[17:02] <Saviq> mhr3, basically because it's an abstract and stupid classification
[17:02] <mhall119> mhr3: where are server scopes mentioned currently?
[17:02] <mhr3> Saviq, maybe we can still send something? that is perhaps more ambigous
[17:02] <greyback> kgunn: re silo6 and the platform-api update, I've installed it and it seems to work fine. Which surprises me, as I was expecting the ABI change to break stuff! For safety a qtubuntu rebuild might be needed, just in case.
[17:03] <mhr3> mhall119, in the big tutorial page
[17:03] <Saviq> mhr3, what we *could* send is the 'usage scenario' as described below, and we'll probably need to send more (like device name or something)
[17:03] <mhall119> ah, the wordpress side of things, ok
[17:03] <Saviq> (below in the slide deck)
[17:04] <mhr3> will check the doc properly tomorrow, need to run now
[17:07] <kgunn> greyback: ack i'll add that
[17:52] <code_glitch> hey there! is there anyone who knows a thing or two about unity/compiz with a little time available?
[18:17] <dobey> anyone around that knows anythinga bout unity-scope-tool?
[18:18] <dobey> because i'm getting the error aobut Runtime.ini and i don't know how to get around it :(
[18:18] <code_glitch> nope, im looking for someone who knows something about metacity/compiz/xlib and unity myself...
[18:59] <kgunn> greyback: i'm gonna land the papi resize change....looks good...i found a couple of bugs but seem unrelated
[18:59] <kgunn> (e.g. copy/paste prompt has gone completely awol now)
[19:00] <greyback> kgunn: ok, thanks!
[19:34] <greyback> ted: ping
[19:35] <ted> greyback, Howdy
[19:35] <greyback> ted: hey, quick question: when UAL starts an app, it sets some vars in its environment. Where is the file that sets those?
[19:36] <ted> greyback, http://bazaar.launchpad.net/~indicator-applet-developers/upstart-app-launch/trunk.14.04/view/head:/helpers.c#L493
[19:37] <ted> greyback, Those are the big ones, but there's also the path ones, is that what you're looking for?
[19:37] <greyback> ted: hmm, not what I need. Any idea what would set the MIR_SOCKET?
[19:38] <Saviq> AlbertA, "USC to use default values when no session is active." I don't think that's correct...
[19:38] <ted> greyback, I'm pretty sure the Unity8 upstart job sets it.
[19:38] <Saviq> greyback, ted, it does
[19:38] <AlbertA> Saviq: what should it use?
[19:38] <greyback> ted: Saviq got it, thanks
[19:38] <Saviq> greyback, ted, well it sets it to unity8's socket
[19:38] <Saviq> for clients
[19:38] <Saviq> greyback, ted, it's set to u-s-c's client socket by... something else
[19:39] <Saviq> AlbertA, sure, default values yes, but not "if no session is active", but "if no session was ever active" instead
[19:39] <ted> Saviq, I believe that's the touch-session init script
[19:39] <Saviq> ted, probable yes
[19:39] <AlbertA> Saviq: ok
[19:39] <Saviq> AlbertA, and greeter should not have its own values
[19:39] <ted> But considering greyback's asking about applications, I bet he wants Unity8's socket :-)
[19:40] <apw> larsu, hey ... you seem to have touched notify-osd recently, just found a bug wherein appended notifications go completely missing (bug #1319244) I have a fix for it, but no idea how one goes about handling things in the CI magic
[19:40] <greyback> ted: Saviq: no I'm good, I know where to go from here, thanks!
[19:40]  * greyback had guessed it was set by some user login script
[19:40] <apw> larsu, damn that is bug #1319983
[19:40] <Saviq> AlbertA, flow would be, IMO: phone boots up, defaults are applied, but as soon as you make a session active, values from the session are read and stored in u-s-c until they're overwritten by that, or any other session
[19:40] <AlbertA> Saviq: ok make sense
[19:42] <Saviq> AlbertA, I didn't yet reply to your email, but re: power button - I don't think there needs to be any special communication between shell and usc
[19:42] <Saviq> AlbertA, basically the shell would react after 2s, usc potentially after 5s, lower levels (kernel or hardware) after 10s
[19:43] <Saviq> AlbertA, this way, after 2s the power off dialog would be displayed in shell or greeter, after 5s usc would issue a clean shutdown, after 10s hardware would shut down forcefully
[19:44] <Saviq> AlbertA, no need for comms between layers
[19:44] <AlbertA> Saviq: I see, ok
[19:44] <Saviq> AlbertA, and in case shell, usc don't respond, we still have a fallback down under
[19:45] <AlbertA> Saviq: sure it makes sense. So I'll remove the dbus signal from USC and change the threshold
[19:45] <Saviq> AlbertA, and actually, it's not that it should check the timer on _UP
[19:45] <Saviq> AlbertA, but as soon as the timer triggers it should react
[19:45] <AlbertA> Saviq: yeah that's how I have it implemented
[19:45] <Saviq> AlbertA, so that user sees a reaction
[19:45] <Saviq> AlbertA, ok, I described it wrong in the email
[20:32] <darklight_> ChrisTownsend, have you had a chance to give it a look ?
[20:34] <kgunn> Saviq: in case you're still on, is unity8 AP having issues on the latest image ?
[20:35] <kgunn> greyback: ^ i might have spoke too soon about landing...
[20:35] <kgunn> going to reflash and test the straight image
[20:35] <ChrisTownsend> darklight_: No, not yet.  It's next on my queue, but I'm working on another issue where windows sometimes jump around workspaces when disconnecting/connecting an external monitor.
[20:35] <ChrisTownsend> darklight_: Once I either fix that or get tired of working on it, I'm gonna look at the reset settings issue.
[20:36] <darklight_> ChrisTownsend,  oh i heard of that, just so that I don't bother you too much what's the right bug where I can follow the progress ?
[20:37] <ChrisTownsend> darklight_: The reset setting issue?
[20:37] <Saviq> kgunn, I've seen a few flaky tests recently in our CI
[20:38] <Saviq> kgunn, last I landed was over a day ago
[20:38]  * Saviq flashes
[20:38] <darklight_> ChrisTownsend, yep
[20:40] <ChrisTownsend> darklight_: Hmm, I know there a few different bugs entered for this issue.  I'm going to triage those bugs and dup any I find.  Honestly, I don't know which bug will be The One yet.
[20:41] <darklight_> ChrisTownsend, ok, I'll bother you every once in a while till then :P
[20:42] <ChrisTownsend> darklight_: That's fine:)  Hopefully I will have the bugs straightened out by the next time you poke me.
[20:42] <Saviq> kgunn, smoke is green for unity8 as well, and they didn't report any flakiness there
[20:47] <Saviq> ChrisTownsend, on windows jumping around workspaces... I noticed that if I get an urgent on launcher and press it, the window (sometimes?) gets moved to my external screen
[20:48] <Saviq> ChrisTownsend, I'm not sure it's 100%, but it's happened often enough that I noticed
[20:48] <ChrisTownsend> Saviq: Is the window maximized?
[20:48] <Saviq> ChrisTownsend, yes, was about to mention
[20:48] <ChrisTownsend> Saviq: Yeah, many, many issues with maximized windows in Compiz:-(
[20:49] <Saviq> ChrisTownsend, :|
[20:49] <Saviq> let
[20:49] <Saviq> 's fix that in unity8 then!
[20:49] <ChrisTownsend> Saviq: Indeed!
[20:51] <robru> mterry, hey, had to rebuild telephony-service in silo 2 again due to another landing of that component: https://ci-train.ubuntu.com/job/landing-002-1-build/64/console please land this silo soon ;-)
[20:51] <mterry> robru, naw, don't want to
[20:51] <mterry> :)
[20:51] <robru> :-P
[20:54] <Saviq> mterry, you actually (almost) got ACK from Albert on this didn't you? ;)
[20:54] <Saviq> mterry, just to confirm: AP tests will pass in there will they?
[20:54] <mterry> Saviq, yeah for the root unity8 branch.  But there are fixes elsewhere now I'm waiting on (fallout from upstart fiddling with lightdm)
[20:54] <mterry> Saviq, AP test pass yeah
[20:55] <Saviq> mterry, cool, so sounds like we could get it before Malta?
[20:55] <mhall119> mhr3: stil around?
[20:55] <mterry> Saviq, this is the problem with this branch -- the longer it stays out, the more other pieces of the system break it  :)
[20:55] <mterry> Saviq, I desperately want that
[20:55] <Saviq> mterry, I can imagine
[20:55] <mterry> Saviq, I don't want any conversations in Malta to have the phrase "once split greeter lands, this will be different"
[20:55] <Saviq> :)
[20:56] <Saviq> mterry, let's talk tomorrow on where others can help
[20:56] <Saviq> mterry, and let's get this done early next week
[20:56] <mterry> k
[20:57] <mhr3> mhall119, i am now
[20:58] <mhall119> mhr3: I don't see the word "server" on the scopes tutorial, but I do see it on the overview page
[20:58] <mhall119> http://developer.ubuntu.com/scopes/overview/
[20:58] <mhall119> is that what you meant?
[20:59] <mhall119> mhr3: also can you check the API docs I just uploaded to http://91.189.92.89/api/scopes/sdk-14.10/
[20:59] <mhr3> mhall119, i meant here http://developer.ubuntu.com/api/scopes/sdk-14.04/index/
[20:59] <mhall119> ah, in that case can you confirm that http://91.189.92.89/api/scopes/sdk-14.10/index/ is how you want it?
[20:59] <mhr3> mhall119, ehm, nope looks old
[21:00] <mhall119> oh, you know what, I apt-get downloaded on my box, which is trusty, you want the ones from utopic don'tyou
[21:01] <mhr3> indeed
[21:02] <mhall119> hmmm, how do I easily get a package from another release
[21:02] <mhr3> good question
[21:03] <mhr3> mhall119, https://launchpad.net/ubuntu/+archive/primary/+files/libunity-scopes-doc_0.4.5%2B14.10.20140513-0ubuntu1_all.deb
[21:11] <mhr3> mhall119, looks like you could build that url with the output from rmadison
[21:27] <larsu> apw: thanks! I'll have a look at it tomorrow. Usually we prepare merge request of a bzr branch - but don't worry about that if you don't plan to do that often
[21:29] <mhall119> mhr3: please check http://91.189.92.89/api/scopes/sdk-14.10/ again
[21:32] <mhr3> mhall119, yep, that looks good
[21:35] <Saviq> kgunn, just ran latest proposed test suite, all OK
[21:37] <kgunn> Saviq: damn...it's working here for me too....
[21:37] <kgunn> mmm
[21:37] <kgunn> gonna try that package once more...but not looking good
[21:44] <apw> larsu, sounds good thanks, i have a couple of test sequences i can use to confirm when you have an update ...
[21:44] <larsu> apw: can you post/attach them to the bug as well please?
[21:44] <larsu> we'll need them if we want to SRU it (not sure if that's worth it yet)
[21:46] <mhall119> mhr3: please verify http://developer.ubuntu.com/api/scopes/sdk-14.10/ too
[21:46] <apw> larsu, done ... the bug is pretty significant if you use x-canonical-append:true, which most of the IM integrations do
[21:47] <apw> larsu, as you can completely lose whole sets of notifications
[21:52] <larsu> apw: ah okay. Likley SRU worthy then
[21:53] <larsu> I'll update the bug for that tomorrow and get it into the right hands
[21:53] <larsu> thanks!
[21:56] <apw> larsu, great thanks, spent a very confused day trying to make use of it, and it took me a while to realise i wasn't doing it wrong ...
[23:20] <mhr3> mhall119, looks fine as well