[07:15] <MacSlow> Saviq, did you manage to get back to try lp:~macslow/unity-notifications/modal-snap-decisions and lp:~macslow/unity-notifications/modal-snap-decisions again after the conflict-fix with mterry' greeter-ux-fixes branch for unity8?
[07:18] <Saviq> MacSlow, will do today
[07:21] <MacSlow> Saviq, ok... I'll turn to combobutton and the sms-class2/timeout stuff again then
[08:12] <tsdgeos> Saviq: so it's not the last change that broke the carousel, removing it is still broken
[08:12] <tsdgeos> and i can't go back enough to make it work again :S
[08:12] <Saviq> tsdgeos, are we sure it did work?
[08:12] <tsdgeos> which is very weird since i remember it clearly working
[08:13] <tsdgeos> but it may be just fake memories
[08:13] <Saviq> tsdgeos, right
[08:13] <Cimi> tsdgeos, what's the bug?
[08:13] <tsdgeos> ok, let's fix it anyway
[08:13] <tsdgeos> Cimi: second carusel is just not drawn at all
[08:13] <Cimi> tsdgeos, scopes bug?
[08:13] <tsdgeos> no
[08:14] <tsdgeos> make tryGenericScopeView
[08:14] <tsdgeos> scroll down
[08:14] <tsdgeos> nice empty space where teh carousel should be
[08:14] <tsdgeos> scroll up again
[08:14] <tsdgeos> you even lost the first carousel that was correctly shown before ^_^
[08:15] <Cimi> tsdgeos, lswph?
[08:15] <Cimi> lvwph
[08:15] <tsdgeos> can be
[08:15] <Cimi> qt 5.2
[08:15] <tsdgeos> but i've reverted the changes i did lately and didn't fix it
[08:15] <tsdgeos> i have memories of it working but it just doesn't
[08:15] <tsdgeos> so yes, let's stop saying names and i'll have a look ;)
[08:17] <Saviq> tsdgeos, it's not about the second carousel even
[08:17] <Saviq> tsdgeos, just one is enough, as long as it's culled
[08:17] <tsdgeos> yes
[08:17] <Saviq> k
[08:17] <tsdgeos> it's the second carousel in that test
[08:18] <Saviq> yeah ok
[08:19] <Cimi> tsdgeos, increasing cachebuffer affects?
[08:20] <tsdgeos> uh?
[08:20] <Cimi> tsdgeos, of the scrollable
[08:20] <Cimi> not the carousel
[08:21] <tsdgeos> let me work on it :) i'll come back when i've no more ideas
[08:22] <tsdgeos> but no, that's not the problem
[08:23] <tsdgeos> the carousel is being created
[08:23] <tsdgeos> as needed
[08:33] <Saviq> tsdgeos, sounds like another 5.2 fallout?
[08:34] <tsdgeos> Saviq: so i know what's wrong
[08:34] <tsdgeos> but i don't know what's wrong :D
[08:34] <tsdgeos> i mean
[08:34] <tsdgeos> if we replace
[08:34] <tsdgeos> delegate: tileWidth > 0 && tileHeight > 0 ? loaderComponent : undefined
[08:34] <tsdgeos> with
[08:34] <tsdgeos> delegate: loaderComponent
[08:34] <tsdgeos> it'll work again
[08:34] <Saviq> oh
[08:34] <tsdgeos> but i've no idea why
[08:34] <tsdgeos> since tileWidth and tileHeight are correctly > 0
[08:35] <tsdgeos> trying to find out a bit more
[08:35] <Saviq> ok, not distracting you then
[08:35] <Saviq> :)
[08:37] <mhr3> Saviq, wondering if we should land latest music scope, as it makes that bug quite obvious
[08:37] <Saviq> mhr3, tsdgeos'll fix it, don't worry there :)
[08:38] <Saviq> mhr3, anyway we can reproduce it fine
[08:38] <mhr3> Saviq, like your "no pressure" attitude :)
[08:38] <mhr3> but very well
[08:38] <Saviq> mhr3, unless your question was rather "should we _not_ land it", then yeah, ideally we'd wait a bit
[08:39] <Saviq> and land it together/after unity8 fix
[08:41] <mhr3> alrighty
[08:41] <mhr3> not landing until there's a fix
[08:42] <mhr3> that branch waited for a month, it can wait few more days :P
[08:42] <Saviq> ;D
[08:42] <Saviq> mhr3, can we get rid of the useless "Songs" carousel from there?
[08:43] <mhr3> Saviq, ask design :P
[08:43] <Saviq> mhr3, I did! :P
[08:43] <mhr3> s/ask/convince/
[08:43] <Saviq> bug #1237970
[08:43]  * Saviq bugs mikenagle
[08:43] <Saviq> slacker, not around
[08:44] <Saviq> ooh apt has a cool progress bar :D
[08:45] <Saviq> ooh and unity crashed...
[08:46] <mhr3> Saviq, iirc displaying songs was a bandaid fix for not being able to do proper album queries, so you might get your wish afterall
[08:46] <Saviq> mhr3, I know ;)
[08:46] <Saviq> mhr3, but then the visuals do list "Songs" as the first category in a carousel
[08:47] <mhr3> the visuals need updating too from time to time ;)
[08:53] <MacSlow> Saviq, the apt-progressbar is the bling of the day :)
[08:53] <Saviq> indeed ;)
[08:54] <Saviq> oh and one more u7 crash yay
[09:19] <asac> greyback: hey. i think we are seeing a noticalbe performance hit comparing our image 250 (previous promotion) to yesterdays promotion; are ou guys aware of something that could have caused this?
[09:19] <asac> thats on mako
[09:19] <asac> didrocks and popey can give more details
[09:19] <didrocks> it was mentionned in the landing email IIRC
[09:20] <asac> better ask directly. maybe its known and worked on
[09:20] <greyback> asac: nothing that I'm aware of :(
[09:20] <asac> hmm
[09:21] <asac> didrocks: popey: anything special to trigger that slowdown?
[09:21] <greyback> quite a few moving parts have changed since 250
[09:21] <asac> didrocks: popey: is it all over the place or some specific user interaction that is slow?
[09:22] <asac> greyback: in general, or also on MIR?
[09:22] <greyback> I'm using 293 on nexus4 - I hadn't noticed any perf hit
[09:22] <asac> didrocks: popey: maybe explain where you see that perf hit. thx
[09:22] <greyback> asac: well mostly mir, but unity has gained the new scopes which does impact scrolling performance in the dash
[09:22] <didrocks> asac: using the phone…
[09:22] <didrocks> really, just use it
[09:22] <didrocks> and compare to 250
[09:23] <greyback> didrocks: is there anything killing CPU?
[09:23] <didrocks> greyback: no, and no full memory
[09:23] <didrocks> just use it for few minutes and you will clearly see it
[09:23] <didrocks> even once the cache should be full
[09:24] <asac> new scopes were in 250, no?
[09:24] <didrocks> no
[09:24] <asac> ok well that could indeed be contributing here then
[09:24] <asac> but if its not CPU bound
[09:24] <asac> then sounds really more MIR'ish, but what do i know :)
[09:25] <didrocks> we had a Mir and an unity8 release meanwhile
[09:25] <didrocks> we already started to get a closer image bisect range
[09:26] <asac> didrocks: who is bisecting?
[09:27] <didrocks> asac: nobody *is*
[09:27] <didrocks> asac: when we started that, I was asked to stop
[09:27] <didrocks> last time we did we got to:
[09:27] <didrocks> Purely anecdotal, but #269 certainly felt much snappier than my #274
[09:27] <didrocks> or #275 builds in doing very simple things like swiping away the
[09:27] <didrocks> welcome screen, and swiping up and down the apps scope.
[09:27] <didrocks> landing email
[09:27] <didrocks> (from popey)
[09:30] <didrocks> I don't find any bug report though, let's see if popey got one, I thought he did, my search is probably just sucking
[09:30] <mzanetti> didrocks: there are 2 places I know of where performance has decreased
[09:30] <Saviq> MacSlow, (how) can I mimic a modal snap decision with the create-notification.py script?
[09:30] <didrocks> mzanetti: ah?
[09:30] <mzanetti> didrocks: for one the new-scopes, which we are aware of and working on improving it
[09:31] <didrocks> mzanetti: so, unity8 rendering/threading with new-scopes?
[09:31] <mzanetti> didrocks: and the other is a bug that came with Qt 5.2 which impacts all sorted lists (in apps for example)
[09:31] <didrocks> (seems to match the landing timeframe)
[09:31] <didrocks> mzanetti: ok, here, alan is only talking about the new scopes
[09:31] <didrocks> as #250 had 5.2
[09:31] <mzanetti> didrocks: yeah, new-scopes still scroll badly. but we know why
[09:32] <Saviq> and have the first optims in store already
[09:32] <mzanetti> really? I thought 250 wasn't 5.2 yet
[09:32] <didrocks> mzanetti: any fix/workaround in progress? (I think no as it would have been done for long, right?)
[09:32] <didrocks> mzanetti: it was 5.2
[09:32] <MacSlow> Saviq, from AP-tests?
[09:32] <didrocks> just not new scopes
[09:32] <Saviq> MacSlow, I just want to manually test it
[09:32] <popey> didrocks: no, didn't file a bug as I had no science, just anecdote
[09:32]  * Saviq looks in the MP
[09:33] <didrocks> mzanetti: is there a bug for that one?
[09:33] <MacSlow> Saviq, just any snap-decision will do... as long as it's not happening while the greeter is shown... e.g. call yourself... without the dialer being open
[09:33] <Saviq> MacSlow, kk
[09:33] <MacSlow> Saviq, or use any of the snap-decision examples from lp:unity-notifications/examples
[09:34] <Saviq> MacSlow, right, k
[09:34] <popey> asac: sorry, was afk, didrocks has explained it fully enough from my pov
[09:35] <mzanetti> popey: do we have a LP bug for the QSortFilterProxyModel that hits us in the Reminders app?
[09:35]  * mzanetti only knows about the upstream qt bug
[09:36] <didrocks> mzanetti: I'm talking about the unity8 perf optimization needed (the one popey and I noticed, not linked to 5.2)
[09:36] <Saviq> MacSlow, so, I should be unable to interact with the dash while ./sd-example-incoming-call.py is happening, should I?
[09:36] <popey> bug 1303746 ?
[09:38] <MacSlow> Saviq, correct
[09:38] <Saviq> MacSlow, then it's not working... let me try calling myself
[09:38] <MacSlow> Saviq, there should be a tinted background swallowing all input
[09:38] <MacSlow> Saviq, hm...
[09:38] <mzanetti> didrocks: don't think there is one
[09:39] <didrocks> mzanetti: mind filing one with the details? Would be easier to track
[09:39] <didrocks> (as you have more details than us)
[09:39] <Saviq> MacSlow, you can branch from http://people.canonical.com/~didrocks/citrain/silos/landing-001/unity8/
[09:39] <Saviq> MacSlow, or take the packages from https://launchpad.net/~ci-train-ppa-service/+archive/landing-001/
[09:39] <Saviq> MacSlow, but let me verify
[09:40] <MacSlow> Saviq, and that has https://code.launchpad.net/~macslow/unity8/modal-snap-decisions/+merge/210988 ?
[09:40] <MacSlow> Saviq, it's not marked as "Merged"
[09:40] <Saviq> MacSlow, sure it's not, it's only in the silo
[09:40] <Saviq> MacSlow, it's only Merged when it's in trunk
[09:40] <MacSlow> Saviq, ah ok
[09:40] <Saviq> MacSlow, I'm just testing before ACKing the silo
[09:41] <Saviq> MacSlow, yeah, no worky, again - conflict with mterry's branch I'd say
[09:42] <Saviq> MacSlow, please rebase yours on his branch and verify everything's working (and that the tests are correct... since they pass, and should catch this)
[09:42] <MacSlow> ok
[09:42] <Saviq> MacSlow, https://code.launchpad.net/~mterry/unity8/greeter-ux-fixes/+merge/210042
[09:43] <Saviq> biab, testing autopilot
[09:44] <mzanetti> didrocks: https://bugs.launchpad.net/unity8/+bug/1307959
[09:44] <didrocks> mzanetti: thanks!
[10:02] <greyback> wow, not sure if true, but seemed that router got into a state that it was sending packets to my laptop that make the wireless driver crash
[10:02] <greyback> asac: didrocks: sorry I dropped offline just over 30 mins ago
[10:03] <didrocks> greyback: basically, we are talking about https://bugs.launchpad.net/unity8/+bug/1307959
[10:03] <greyback> didrocks: okay, thanks for update
[10:04] <greyback> if I can help in any way, let me know
[10:21] <MacSlow> Saviq, I'm not sure if it's related... but I've added ppy:ci-train-ppa-service/landing-001 to my N4 setup and unity-notifications is nowhere to be found
[10:25] <MacSlow> Saviq, that said... modal snap-decisions do work for me though using that landing-001 silo-ppa
[10:26] <MacSlow> Saviq, non-blocking when on the greeter... blocking when greeter isn't shown... just as design requested
[10:26] <mhr3> it always freaks me out when i run unity8 on desktop and i start receiving all notifications in there :)
[10:27] <MacSlow> mhr3, yeah.. .that's odd indeed :)
[10:34] <MacSlow> Saviq, ignore the mentioned issue with the unity-notifications... after a reboot of the phone they did show up via "apt-cache policy ..."
[10:35] <Cimi> tsdgeos, I am testing your branch
[10:35] <Cimi> tsdgeos, but it seems I probably found other bugs
[10:35] <tsdgeos> like?
[10:35] <Cimi> tsdgeos, with your branch I mean the position at beginning
[10:35] <tsdgeos> yes
[10:35] <Cimi> tsdgeos, for example, I am in app scope
[10:35] <tsdgeos> like which bugs?
[10:36] <Cimi> tsdgeos, I expand apps and scroll down to hide the header
[10:36] <Cimi> tsdgeos, then I swipe from right to left to change to music scope
[10:36] <Cimi> tsdgeos, the header lags then it appears
[10:36] <Cimi> tsdgeos, I go back to apps scope and redo the same thing, the header is partially shown
[10:36] <tsdgeos> ?
[10:37] <tsdgeos> what do you mean with "lags"?
[10:37] <Cimi> tsdgeos, I see it skipping frames
[10:37] <Cimi> animate maybe
[10:38] <Cimi> tsdgeos, sending on whatsapp
[10:39] <tsdgeos> Cimi: well, just see if it happens without my patch
[10:39] <tsdgeos> or not
[10:39] <Cimi> tsdgeos, it does with and without
[10:40] <tsdgeos> i sincerely don't see any lagging :D
[10:40] <tsdgeos> minute:second?
[10:40] <Cimi> tsdgeos, not now, just first run
[10:40] <Saviq> MacSlow|lunch, hmmpf
[10:40] <Cimi> tsdgeos, anyway, you see it is not fully shown
[10:40] <Cimi> tsdgeos, see last seconds when I scroll down
[10:41] <Cimi> and the header fully appears
[10:41] <tsdgeos> i see
[10:41] <Saviq> MacSlow|lunch, oh, I think I know why... I didn't upgrade the notifications plugin...
[10:41] <Cimi> tsdgeos, also
[10:41] <tsdgeos> that may be because of my patch, not sure
[10:41] <Cimi> tsdgeos, another bug
[10:41] <Cimi> tsdgeos, go in scopes scope
[10:42] <tsdgeos> previously we were showing all the headers and now i only show the one of the list we are seeing
[10:42] <Cimi> tsdgeos, run an app from launcher, like system settings
[10:42] <tsdgeos> that is the one you care about in reality
[10:42] <Cimi> tsdgeos, reveal launcher and tap the home button
[10:42] <Cimi> tsdgeos, the header shows "app scope" but we're still in the scopes scope
[10:44] <tsdgeos> Cimi: please check if those happen or not without my patch and write it in the MR so i remember what i have to fix
[10:44] <tsdgeos> otherwise i'll forget :)
[10:44] <tsdgeos> if they still happen with my patch, open a bug so i don't forget about those either :D
[10:45] <Saviq> mzanetti, https://code.launchpad.net/~macslow/unity-api/expose-notification-data-roles-to-qml/+merge/212581 should've had an unity-notifications- version bump, please remember about those
[10:46] <Saviq> mzanetti, in the .pc file
[10:46] <mzanetti> oh... :/ sorry. yes, will try to remember
[10:47] <Cimi> tsdgeos, sent you the video of the second bug
[10:47] <Cimi> tsdgeos, whatsapp encodes automatically, handy :)
[10:48] <Saviq> mzanetti, as punishment, you get to try and reproduce bug #1307634 ;)
[10:48] <Saviq> mzanetti, since the one I thrown at you yesterday got snatched by mterry
[10:48] <Cimi> Saviq, throw me bugs
[10:48] <mzanetti> ah nice.
[10:49] <Saviq> Cimi, bug #1301038 for you
[10:53] <Saviq> tsdgeos, sorry, you'll have to remind me again on why we did not want LANG=C for tests ↑? ;D
[10:53] <Saviq> tsdgeos, and ideally comment on the bug?
[10:53] <tsdgeos> Saviq: you mean why you did not want it :D
[10:54] <Saviq> tsdgeos, we're a team!
[10:54] <Saviq> ;P
[10:54] <tsdgeos> Saviq: ;.)
[10:54] <tsdgeos> Saviq: it's not that we did not want it
[10:54] <mzanetti> fyi: jenkins does export this to workaround an issue with autopilot debug prints
[10:54] <mzanetti> not sure if its still required
[10:54] <tsdgeos> Saviq: it's that we could not decide wheter to put it as env in the make call or as setenv in the code itself
[10:54] <tsdgeos> Saviq: so we statusquo'ed by doing nothing
[10:54] <Saviq> tsdgeos, right ;)
[10:57] <Saviq> MacSlow|lunch, ok, darkening I have, but I can still tap apps behind the darkening
[10:58]  * Saviq writes stuff down on the MPs
[11:07] <tsdgeos> ok, qt bug found
[11:07] <tsdgeos> \o/
[11:07] <tsdgeos> now i only need to create a testcase bla bla bla
[11:17] <Saviq> tsdgeos, tried with 5.3?
[11:18] <tsdgeos> bug is still there in the code
[11:18] <tsdgeos> in 5.3
[11:18] <Saviq> ok
[11:18] <tsdgeos> it's an obvious mistake after you read the code
[11:18] <tsdgeos> i have that right in the LVWPH code
[11:19] <tsdgeos> they are basically not accounting for setting a delegate to null on creation and non null after everything has been setup
[11:19] <tsdgeos> need the test though
[11:19] <tsdgeos> working on that now
[11:19] <Cimi> tsdgeos, so the header scrolling bug is present with the devel proposed image as well
[11:20] <Cimi> tsdgeos, not the second one with the scope
[11:20] <Cimi> testing
[11:20] <tsdgeos> interesting
[11:23] <Cimi> tsdgeos, cannot reproduce it anymore
[11:23] <Cimi> tsdgeos, but you saw the video :)
[11:23] <tsdgeos> Cimi: i think it is this
[11:24] <tsdgeos> https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1297770
[11:24] <tsdgeos> or similar
[11:31] <tsdgeos> and the testcase http://paste.ubuntu.com/7254748/
[11:33] <om26er> Trevinho, hi
[11:33] <om26er> Trevinho, there seems to be some problem with window placement, the titlebar often appears below the top panel
[11:33] <om26er> bug 1308005
[11:40] <om26er> andyrock, ^
[11:49] <Cimi> tsdgeos, same bug
[11:49] <Cimi> tsdgeos, I can launch an app
[11:50] <Cimi> tsdgeos, from the scopes when the header is shown but I scrolled down
[11:50] <Cimi> tsdgeos, and I can see only the header changing
[11:51] <mhr3> Saviq, hm, seems like the slowness of scrolling in apps is partially caused by the art rescaling
[11:51] <mhr3> plus masking
[11:51] <Saviq> mhr3, well, sure
[11:51] <Saviq> mhr3, all the complexity of the card has impact
[11:52] <mhr3> Saviq, it's just odd that when the icon is smaller the perf is worse
[11:53] <Saviq> mhr3, that's because there's more of them on screen probably
[11:53] <Saviq> since a smaller art means less vertical space taken by any given card
[11:55] <mhr3> Saviq, dunno, feels like there's more to it
[11:55] <Saviq> mhr3, what we need to do is just build a library of smallest-possible card configurations to cater for all the supported cases (which we ~wanted anyway)
[11:56] <Saviq> mhr3, this way they won't be as complex
[11:57] <mhr3> it's also taking away the power for scope authors
[11:58] <Saviq> mhr3, no no
[11:59] <Saviq> mhr3, nothing would change scope-side
[11:59] <Saviq> mhr3, we need to build a library that really supports all the possible combinations (that we support, not as in the ones listed in dash spec, but basically all)
[12:00] <Saviq> mhr3, we'd still accept the configuration as it is now (and optionally a choice from a library later)
[12:00] <Saviq> mhr3, and well, ultimately we can just leave Card as is, and fall back to it
[12:00] <Saviq> mhr3, while selecting simpler delegates for the ones we want it makes sense to
[12:01] <mhr3> hm, so js workaround?
[12:01] <Saviq> mhr3, not a workaround ;)
[12:01] <mhr3> totally a workaround :P
[12:01] <Saviq> mhr3, no, not a workaround
[12:02] <Saviq> in an app card
[12:02] <Saviq> we have: mascot, subtitle, summary, emblem → all invisible
[12:02] <Saviq> but existent nevertheless
[12:02] <Saviq> background, too
[12:03] <Saviq> which means they are consuming resources, even though we know they'll never be used
[12:03] <mhr3> but none of those are used, there should be 0 overhead for such things
[12:03] <Saviq> mhr3, but there can't be
[12:03] <Saviq> mhr3, they need to be created
[12:03] <Saviq> mhr3, sure, they're not uploaded to the GPU
[12:04] <Saviq> mhr3, but they're still objects in the QML tree, their properties are still evaluated
[12:04] <mzanetti> Saviq: hmm... so, I can reproduce the black screen with outdated launcher entries, however it doesn't crash unity here but recovers on any edge gesture
[12:04] <Saviq> mhr3, sure, the first thing we do is: https://code.launchpad.net/~aacid/unity8/card_optimizations/+merge/213660
[12:04] <mzanetti> couldn't get anything out of the attached crash file. (crashes GDB here when trying to load :D )
[12:04] <Saviq> mhr3, making it so that they're not loaded, shaving off ½ off the time for an app tile creation
[12:05] <Saviq> mzanetti, yeah, the .crash files are stupid
[12:05] <Saviq> mzanetti, so... tried devel (not -proposed) image?
[12:05] <Saviq> mzanetti, as that's what Rick was using, and I believe that's where Dave confirmed the crash
[12:06] <mzanetti> ah.. right... that might be one revision lower
[12:06] <mhr3> Saviq, so shouldn't that solution be good enough?
[12:06] <Saviq> mhr3, depends, we'll have to compare how much overhead is there for just the Loaders
[12:06]  * mzanetti tries to reproduce on the dogfooding phone
[12:06] <mhr3> Saviq, i mean, clearly it isn't, but that just makes me think we're missing something
[12:07] <Saviq> mzanetti, devel is 250
[12:07] <Saviq> mzanetti, not "one revision lower"
[12:07] <Saviq> but some 38 revisions lower
[12:07] <mzanetti> Saviq: no.. not any more
[12:07] <Saviq> mzanetti, oh, so we got a promoted image did we?
[12:07] <Saviq> mzanetti, still, that was 250 Rick got it on
[12:07] <mzanetti> Saviq: and how I read the bug it happened after upgrading from 250 to the new promoted one
[12:07] <Saviq> oh ok
[12:07] <mzanetti> which explains the outdated launcher entries
[12:08] <Saviq> kinda
[12:08] <mzanetti> I recreated them manually by writing account-settings
[12:08] <Saviq> click updates are unrelated to image updates
[12:08] <mzanetti> can reproduce the black screen he's talking about
[12:08] <mzanetti> but doesn't crash it
[12:08] <Saviq> mhr3, well "clearly it isn't" we don't know yet, we need to compare how much overhead is that to a plan image + text tile
[12:09] <Saviq> mhr3, and then try to shave off even more
[12:09] <Saviq> mhr3, so all in all, yes, it needs investigation still, but saying "invisible things should have 0 overhead" is rather extreme ;)
[12:10] <Saviq> i.e. impossible to achieve :P
[12:10] <mhr3> Saviq, i like setting "proper" goals ;)
[12:10] <Saviq> unless invisible == nonexistent
[12:10] <Saviq> «proper»
[12:13] <Saviq> mzanetti, try with image 250, I really think that's where it happened
[12:13] <Saviq> mzanetti, the bug was filed before the new image was promoted, AFAICT
[12:14] <Saviq> mzanetti, or well, the .crash could have been unrelated / previous
[12:15] <Saviq> mzanetti, but https://bugs.launchpad.net/unity8/+bug/1307634/comments/4 does mention #250
[12:16] <Saviq> jeez /me really needs to land this thing...
[12:30] <Saviq> elopio, hey, can you please run http://people.canonical.com/~msawicz/unity8/strip-u8-tags.sh on lp:~elopio/unity8/error_on_missing_url-dispatcher
[12:31] <Saviq> alesage, and you, can you please run http://people.canonical.com/~msawicz/unity8/strip-u8-tags.sh on lp:~allanlesage/unity8/dash-apps-visible-ordering
[12:31] <Saviq> dednick, ↑ same on lp:~nick-dedekind/unity8/remove-indicatormanager-upstart
[12:31] <Saviq> oh elopio, one more of yours: lp:~elopio/unity8/use_fake_instead_of_messaging
[12:52] <tsdgeos> Cimi: maybe comment it on the bug too just in case when we fix it ?
[12:55] <Cimi> I'll test again when we will have a branch with the fix
[12:55] <Cimi> to make sure both work
[12:55] <tsdgeos> do you guys use imap for the canonical email?
[12:56] <tsdgeos> suddenly it's failing for me
[12:56] <tsdgeos> says invalid credentials
[12:58] <Saviq> tsdgeos, I am, not through gmail, though
[12:59] <tsdgeos> right
[13:02] <tsdgeos> what?
[13:02] <tsdgeos> works now
[13:02] <tsdgeos> with my old password for canonical
[13:02]  * tsdgeos confused
[13:03] <paulliu> greyback_: Is there any reason we don't use qdbusxml2cpp to generate the interface?
[13:04] <paulliu> greyback_: from dbus xml -> cpp
[13:04] <greyback_> paulliu: tsdgeos is the author of that bit of code, best ask him.
[13:05] <greyback_> I'm assuming you're asking about the dbus interface in unity-mir
[13:08] <paulliu> tsdgeos: ^^^^
[13:09] <tsdgeos> Cimi: ; added
[13:09] <Cimi> tsdgeos, th
[13:09] <Cimi> x
[13:10] <tsdgeos> paulliu: which interface?
[13:11] <paulliu> tsdgeos: I'm adding a new dbus methods for people to use. But I noticed that the dbuswindowstack.cpp is coded by hand.
[13:11] <paulliu> tsdgeos: So I'm wondering that if there's any policy that we want to code it by hand rather than using the generator.
[13:11] <tsdgeos> paulliu: what is "by hand"?
[13:12] <paulliu> tsdgeos: qdbusxml2cpp can read the dbus xml file and generate an interface.cpp for it. So if we add more methods we can just add it to the xml file.
[13:13] <tsdgeos> paulliu: what code of dbuswindowstack.cpp would you save implementing by doing so?
[13:15] <tsdgeos> besides do we have a dbus xml file for that interface?
[13:16] <paulliu> tsdgeos: No code saving I think. But would be easier to use the generator. Especially it generates the Introspection which can be used for qdbus command line.
[13:16] <paulliu> tsdgeos: no.
[13:16] <paulliu> tsdgeos: So if it is not forbidden. Can I use that tool to generate the interface?
[13:16] <paulliu> tsdgeos: Because I got the an xml file from unity7.
[13:17] <tsdgeos> paulliu: i'm not maintener of that code :D
[13:17] <paulliu> tsdgeos: ok
[13:17] <tsdgeos> i can not see any need to do so for the dbuswindowstack.cpp
[13:17] <tsdgeos> if you see a reason for the new code you're doing and can justify it in a review request
[13:17] <tsdgeos> i don't see why not
[13:18] <paulliu> tsdgeos: ok. thanks~
[13:18] <tsdgeos> but again i'm not deciding on that piece of code, that's gerry ;)
[13:19] <tsdgeos> paulliu: there was some argument in the past
[13:19] <tsdgeos> over if we wanted to have the file that qdbusxml2cpp generates commited in the bzr or created on runtime
[13:19] <tsdgeos> not sure how that ended though
[13:19] <greyback> paulliu: I don't have a strong opinion on it. I'll welcome using qdbusxml2cpp if you write it :)
[13:20] <tsdgeos> note unity8 uses qdbusxml2cpp already
[13:20] <tsdgeos> see ./plugins/Ubuntu/DownloadDaemonListener/interface/downloadtrackeradaptor.cpp
[13:30] <Cimi> Saviq, on https://bugs.launchpad.net/unity8/+bug/1301038 tsdgeos is right we do have a caveat in the CODING file, to run make test with LC_ALL=C
[13:31] <Saviq> Cimi, sure he's right, but that's the thing - we shouldn't have it there ;)
[13:31] <Saviq> Cimi, and also this doesn't work for autopilot tests, which are launched under whatever locale is in the upstart session
[13:31] <Cimi> Saviq, I see
[13:31] <Cimi> Saviq, do we need a better way to export that lang?
[13:32] <Saviq> Cimi, for autopilot we need to pass it to upstart when starting unity8
[13:32] <Cimi> or we need to hardcode locales?
[13:33] <Saviq> Cimi, so a change in process_helpers.py should be enough
[13:33] <Cimi> Saviq, for qmltests not though
[13:33] <Saviq> Cimi, for QML tests some change to the CMake modules we have
[13:33] <Cimi> Saviq, so the answer is, yes, let's hardcode
[13:33] <Saviq> Cimi, oh yes
[13:33] <Cimi> ok
[13:34] <Saviq> Cimi, basically, I shouldn't have to read CODING to be able to run the suite
[13:34] <Cimi> Saviq, lazy :P !
[13:35] <Saviq> Cimi, it should be enough to add to qmltest_DEFAULT_PROPERTIES in tests/qmltests/CMakeLists.txt or so
[13:36] <Saviq> and to whatever overrides that
[13:36] <Saviq> I don't think we should hardcode in QmlTest.cmake
[13:56] <kgunn_> hey mterry, had some ap3 failures on desktop afterall...just a few, gonna purge and retest to see if its a regression or now
[13:56] <kgunn_> or not even...
[13:56] <mterry> kgunn, maybe another missing dep?
[13:57] <mterry> kgunn, hmm, these are missing /dev file stuff.  shouldn't be python3 deps missing I wouldn't think...  Curious
[14:00] <kgunn> AlbertA: would you mind taking a peek at https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1308055
[14:01] <kgunn> sounds like unity-mir animations, but wonder, if we change something around mir snapshotting?
[14:02] <Cimi> Saviq, this does the trick too http://paste.ubuntu.com/7255449/
[14:02] <Cimi> for the timeformattertest
[14:02] <Cimi> depends what we want to do...
[14:02] <Saviq> Cimi, yeah, I think we should just default to C
[14:02] <Saviq> Cimi, globally
[14:02] <Saviq> Cimi, and make any that require otherwise exceptions
[14:02] <Saviq> (none at the moment)
[14:04] <Cimi> Saviq, how do I add a variable to all make tests?
[14:04] <Cimi> s/add/set/
[14:05] <Cimi> because command for running timeformattertest is not using our macros
[14:05] <Cimi> but just make timeformattertest
[14:07] <Saviq> Cimi, run_tests is a macro there
[14:07] <Saviq> Cimi, use http://www.cmake.org/cmake/help/cmake2.6docs.html#command:set_tests_properties to set the ENVIRONMENT property on them
[14:07] <Saviq> inside the macro
[14:07] <tsdgeos> Mirv: we need another qtdeclarative patch ^_^
[14:07] <tsdgeos> Mirv: https://bugs.launchpad.net/ubuntu/+source/qtdeclarative-opensource-src/+bug/1307578
[14:07] <tsdgeos> Saviq: ↑↑↑↑
[14:07] <Saviq> Cimi, in tests/Utils/CMakeLists.txt
[14:07] <Saviq> tsdgeos, thankx
[14:08] <Cimi> Saviq, sure but at this point is better to hardcode inside the test
[14:08] <Saviq> tsdgeos, wrong link to the patch, btw
[14:08] <Cimi> Saviq, when we do use locale sensitive things, we set in the real code
[14:08] <tsdgeos> really?
[14:08] <Saviq> Cimi, not true, there's 4 tests in there that use the macro
[14:08] <Cimi> so is independent to cmake or qmake or whatever
[14:08] <tsdgeos> oh yes
[14:08] <tsdgeos> double copy &paste
[14:08] <Cimi> Saviq, but only timeformatter is sensitive to locale
[14:08] <Saviq> Cimi, right now
[14:09] <Cimi> Saviq, and forever
[14:09] <Saviq> Cimi, I mean that it's the only right now, that's sensitive, others will definitely come
[14:09] <Saviq> as they have for autopilot already
[14:10] <Cimi> I got that but instead of putting it inside the cmake, I'd put it inside the real code, so it's always working regardless of the makefile you use
[14:10] <Cimi> autopilot is different story
[14:10] <Cimi> since it's a script
[14:10] <Cimi> maybe editing the emulator is enough
[14:11] <Saviq> Cimi, and then you'll put the setenv in every test where it's required? how is that better?
[14:11] <Saviq> Cimi, when *the* way to run tests is make test?
[14:16] <AlbertA> kgunn: ack
[14:21] <Saviq> dandrader, would you be able to have a look at bug #1305128 in greyback's stead?
[14:21] <greyback> Saviq: I'm actually at it now
[14:22] <dandrader> phew...
[14:22] <Saviq> greyback, ah ok, thought you'd still be on the event loop
[14:22] <Saviq> tx
[14:22] <greyback> Saviq: have patch ready, but waiting for a fix from alf before I can test it properly
[14:22] <Saviq> kk
[14:25] <mhr3> tsdgeos, ah, i see there's a patch now for the missing carousel, feel free to add it to silo 015
[14:25] <tsdgeos> mhr3: no idea how to do that ^^
[14:26] <alesage> Saviq hi, willdo
[14:26] <Saviq> alesage, thanks!
[14:26] <tsdgeos> mhr3: the patch is against qt
[14:26] <mhr3> tsdgeos, tell that to Mirv then :)
[14:26] <tsdgeos> i told him
[14:26] <tsdgeos> he's just too far right and probably not working anymore today
[14:26] <elopio> Saviq: I had already run the script on my branches, but I'll do it again on those two.
[14:27] <Saviq> elopio, looks like it missed it, thanks
[14:27] <Saviq> elopio, maybe you still have the tags locally and pushed them?
[14:27] <Saviq> elopio, unfortunately with bzr tags are rather viral...
[14:30] <elopio> yes, something went wrong because it's deleting some more tags.
[14:31] <MacSlow> Saviq, pushed the needed fix for modal snap-decisions... works now also for apps as expected
[14:31] <Saviq> MacSlow, thanks
[14:32] <MacSlow> Saviq, I just don't know how to test/verify this within an AP-test
[14:32] <MacSlow> Saviq, I mean start "a random app" and test blocked input
[14:33] <Cimi> Saviq, installed suomi language :D
[14:34] <Saviq> MacSlow, right, qml test would be easier...
[14:34] <Cimi> Saviq, tried this but doesn't work http://paste.ubuntu.com/7255605/
[14:35] <Cimi> Saviq, any clue? documentation is bad
[14:35] <Saviq> Cimi, weird, should work...
[14:39] <Cimi> Saviq, I have no idea
[14:39] <Cimi> Saviq, google doesn't say much
[14:41] <dednick> Saviq: removed tags from lp:~nick-dedekind/unity8/remove-indicatormanager-upstart
[14:44] <Cimi> everything is in suomi \o/
[14:44] <Cimi> help
[14:44] <Cimi> ahahah
[14:52] <kgunn> mterry: ha!...i reverted back to whats sitting in archive...had 6 failures (vs the 5 for the one in silo!)
[14:53] <mterry> kgunn, heh.  good?   I just ran the unity8 autopilot and it worked fine yeah.  Playing with device seems good so far
[14:54] <Saviq> kgunn, mterry, I've confirmed unity8 and UITK pass fine, got one reliable failure of autopilot, but that was due to my screen size
[14:54] <Saviq> (assuming you're talking landing 008?)
[14:54] <mterry> I was
[14:54] <kgunn> Saviq: yes
[14:55] <Saviq> kgunn, mterry, I've ACK'ed it already, QA is doing another run
[14:55] <kgunn> Saviq: told thomi we'd run the full suite tho :-/
[14:55] <Saviq> kgunn, "full suite"?
[14:55] <kgunn> yeah...its thomi's test plan
[14:55] <kgunn> for releasing
[14:56] <Saviq> yeah, and it _doesn't_ say to test all apps :P
[14:56]  * Saviq is arguing the same in -ci-eng...
[14:56] <Saviq> "Run at least one click app autopilot suite"
[14:56] <MacSlow> Saviq, I don't really know how to make a qmltest for the input-blocking checks of modal snap-decisions, since the blocking snap-decision background has to live in Shell.qml
[14:56] <kgunn> Saviq: right, i read it _exactly_ the same way...but then he told me on irc last night its all
[14:56] <kgunn> btw, he updated the wiki last night :)
[14:57] <Saviq> kgunn, then it should be ran on http://q-jenkins:8080/job/autopilot-release-gatekeeper/
[14:57] <MacSlow> bzr status
[14:57] <Saviq> it's madness for multiple people to spend 4 hours running the suites manually on their devices
[14:57] <MacSlow> crap
[14:57] <kgunn> Saviq: ah-ha...yes...didn't realize he put that in...agreed
[14:57] <Saviq> MacSlow, bzr: ERROR: Not a branch: "#ubuntu-unity".
[14:58] <MacSlow> Saviq, I figured :)
[14:58] <kgunn> i love the fact we have to hold to this high standard to test our infrastructure that comes with this warning "You'll need to watch the job. Devices often become stuck, or fail to boot."
[15:02] <Cimi> Saviq, which is the autopilot test supposed to fail with locale?
[15:02] <Saviq> Cimi, indicators, but it only runs on the phone
[15:03] <Cimi> Saviq, ah ok, so I need new locale on the phone
[15:03] <Saviq> Cimi, unity8.indicators.tests.test_indicators.IndicatorPageTitleMatchesWidgetTestCase.test_indicator_page_title_matches_widget
[15:03] <Saviq> Cimi, there's plenty of locales on the phone
[15:03] <Cimi> Saviq, indeed was testing it on the desktop, but no failure
[15:03] <Cimi> that's why
[15:03] <Saviq> Cimi, no nothing, in that case ;)
[15:03] <Saviq> heh, doesn't report they're skipped
[15:03] <Saviq> stoppid ap
[15:09] <paulliu> Saviq: Is unity8 depends on unity-mir?
[15:09] <Saviq> paulliu, yes, it does
[15:10] <paulliu> Saviq: if I ldd builddir/src/unity. I didn't see it linked to unity-mir. Not sure what happend.
[15:10] <Saviq> paulliu, it's not linked
[15:10] <Saviq> paulliu, it's dlopen'ed
[15:10] <paulliu> Saviq: ah. got it.
[15:11] <Saviq> paulliu, otherwise we couldn't run it on X11
[15:12] <paulliu> Saviq: So for the logout bug. Let me elaborate again. So I added a RequestLogout and Logout methods in unity-mir. If anyone calls RequestLogout, I then emit a signal LogoutRequested. And unity8 shell should display a dialog for that. And if user accepts to logout. The shell calls Logout methods.
[15:12] <paulliu> Saviq: And then I'll use the ApplicationManager to shut the apps down. Right?
[15:13] <paulliu> Saviq: And then emit another signal. And unity8 Shell quit.
[15:13] <Saviq> paulliu, yeah, no need for unity8 to be part of that
[15:13] <Saviq> paulliu, sounds about right, yea
[15:13] <paulliu> Saviq: Why? Is there any other services does the dialog part?
[15:14] <Saviq> paulliu, I mean no need for unity8 to be part of the "shut down apps" logic
[15:14] <paulliu> Saviq: yeah.. I'll do that in the Logout method.
[15:14] <Saviq> paulliu, all you've written sounds good, greyback can you double-check ↑?
[15:15] <Saviq> paulliu, you're updating the interfaces in http://bazaar.launchpad.net/~unity-team/unity-api/trunk/files/head:/include/unity/shell/application/ ?
[15:15] <paulliu> Saviq: yes. I added three source file for that.
[15:16] <paulliu> Saviq: com.canonical.Unity8.Session provides Logout RequestLogout methods and LogoutRequested signal and LogoutReady signal.
[15:17] <paulliu> RequestLogout is for people to call. Logout is for unity8 after confirm.
[15:18] <greyback> reading up...
[15:23] <greyback> paulliu: all makes sense to me, except are you saying that "Logout" is also a dbus method?
[15:23] <paulliu> greyback: yes.
[15:23] <paulliu> greyback: or it shouldn't be a dbus method?
[15:24] <greyback> paulliu: what is the use-case for that? To log out without asking the user's permission?
[15:24] <paulliu> greyback: yes..
[15:24] <paulliu> greyback: And unity8 can call it after confirm. If user cancelled. unity8 don't call it.
[15:24] <paulliu> greyback: or we should hide that methods?
[15:24] <paulliu> greyback: But in unity7, it is there.
[15:24] <greyback> paulliu: I just don't see the use of a method a third party can call to immediately log out a user, without their permission
[15:25] <paulliu> greyback: people can use dbus methods to logout without any confirm.
[15:26] <greyback> Saviq: what do you think? Is there a use for a method to immediately log out a user without asking their permission?
[15:26] <paulliu> greyback: yeah. But we can decide to hide it or not after fixing the bugs we want. Because in Gnome and KDE there are same stuff. User can use dbus-method to logout without confirmation.
[15:26] <greyback> dbus method
[15:27] <greyback> paulliu: other comment: unity-mir could broadcast a signal to say "logout request cancelled/succeeded" as I'm sure some utils would care about that. What you think?
[15:29] <Saviq> greyback, maybe shutdown?
[15:29] <Saviq> greyback, for the "log out now"
[15:29] <Saviq> but it won't be waiting for the sessions to finish I don't think, not sure
[15:29] <Saviq> we're getting into traditional session mgmt topics that I don't know much about, we should probably talk to desktop folk
[15:34] <Cimi> Saviq, my devices are extremely unhappy of the bug you assigned me
[15:35] <greyback> Saviq: yeah, me too
[15:35] <Saviq> Cimi, you just don't understand them :P
[15:36] <Cimi> Saviq, system settings crashes for me
[15:36] <Cimi> after I changed to spanish
[15:36] <Cimi> and phablet test run hangs
[15:36] <Cimi> this on the phone
[15:36] <Cimi> on the pc, I have everything in suomi which is driving me crazy :)
[15:37] <Cimi> and the cmake edit we think should work is not
[15:37] <greyback> paulliu: overall I agree with your approach. We can discuss the Logout method at a later time, when we've more info
[15:37] <Saviq> Cimi, I *think* you'd be better off with Italian ;D
[15:37] <Cimi> Saviq, there's no italian on the phone
[15:37] <Saviq> Cimi, orly?
[15:37] <Cimi> yep
[15:37] <Saviq> Cimi, I knew there was no pl_PL, but it...
[15:38] <Cimi> it's not about understanding, but about it crashing
[15:38] <Saviq> Cimi, yeah, I know, trying here
[15:38] <Cimi> Saviq, what I did was setting from the system settings spanish
[15:38] <Cimi> Saviq, then rebooting
[15:38] <paulliu> greyback: ok thanks.
[15:38] <Saviq> Cimi, are you passing -n to p-t-r?
[15:39] <Cimi> Saviq, then running phablet-test-run -n -p unity8-autopilot nity8.indicators.tests.test_indicators.IndicatorPageTitleMatchesWidgetTestCase.test_indicator_page_title_matches_widget
[15:39] <Saviq> Cimi, "nity8"?
[15:39] <Cimi> Saviq, then running phablet-test-run -n -p unity8-autopilot unity8.indicators.tests.test_indicators.IndicatorPageTitleMatchesWidgetTestCase.test_indicator_page_title_matches_widget
[15:39] <Saviq> Cimi, just did the same
[15:39] <Cimi> Saviq, unity hangs here
[15:39] <Saviq> Cimi, can't confirm what you're seeing
[15:39] <Saviq> Cimi, ah let it
[15:39] <Saviq> Cimi, it does hang on exit up to a minute...
[15:39] <Cimi> so I was restoring english to see
[15:40] <Cimi> but when I touch system settings the app exits
[15:40] <olli_> Saviq, popey is helping us to get more apps running in u8/preview, but we'd like to understand the impact of the changes better
[15:40] <Saviq> Cimi, I hope your unity-mir patch to improve that
[15:40] <Saviq> olli_, sure, how can I help?
[15:40] <Cimi> Saviq, I'm currently reflashing the device
[15:40] <olli_> Saviq, changes being either "add exec" to the wrapper script or "add -qt5" to the desktop file
[15:40] <Cimi> but it had a build of this morning :\
[15:41] <olli_> Saviq, who can help validate the impact of such a change for U8 (phone), U7 (desktop) and U8(desktop)
[15:41] <olli_> U7 I can figure myself
[15:41] <olli_> but I am not sure how such a change relates to click packages etc
[15:42] <Saviq> olli_, adding exec to the wrapper script should have no impact, not unless the script wants to do something with the return value, which it can't get
[15:42] <Saviq> olli_, so basically as long as there's nothing past the exec line in the wrapper, nothing happens
[15:43] <Saviq> olli_, not sure what you mean by "adding -qt5 to the desktop file"
[15:44] <olli_> Saviq, bregma suggested that on the desktop where 2 different qt versions are installed you need to tell u8 to use qt5 via qmlscene -qt5 ...
[15:45] <Saviq> olli_, there was no qmlscene prior to qt5, the only impact that has is that it will actually select the right binary
[15:46] <greyback> Cimi: I've had a comment on https://code.launchpad.net/~cimi/unity-mir/unity-mir.stop-server_wizard/+merge/214983 for a while now, it's simple to change...
[15:46] <Saviq> olli_, otherwise it'd complain with:
[15:46] <Saviq> qmlscene: could not exec '/usr/lib/x86_64-linux-gnu/qt4/bin/qmlscene': No such file or directory
[15:46] <olli_> Saviq, yeah, maybe that's what Stephen tried to fix
[15:46] <Saviq> olli_, there was "qmlviewer" before qt5, but our SDK is incompatible with qt4 anyway
[15:46] <Cimi> greyback, thx
[15:46] <olli_> dunno, sorry wrong channel too
[15:47] <Saviq> olli_, another solution is to export QT_SELECT=qt5 or install qt5-default
[15:47] <Saviq> olli_, but adding -qt5 to the call is probably the cleanest indeed
[15:48] <Saviq> olli_, the whole thing is due to qt4 and qt5 being coinstallable
[15:48] <olli_> popey, ^
[15:48] <Saviq> which means you could have qmlviewer from both qt4 and qt5 (not qmlscene, as it wasn't there)
[15:48] <Saviq> and all qt things in /usr/bin are actually links to qtchooser
[15:48] <popey> we already have a merge for adding -qt5 to them all
[15:48] <popey> olli_: probably easiest to just land that
[15:48] <olli_> popey, probably
[15:49] <Saviq> which is a wrapper that then execs the correct version
[15:49] <Saviq> so yeah, both exec and -qt5 have minimal impact (limes 0)
[15:50] <Saviq> or well, a version of "-qt5" is actually required for U7 session, too
[15:50] <Saviq> we only don't have it on the phone due to QT_SELECT being exported... which kind of protected us from this issue
[15:50] <AlbertA> kgunn: on https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1308055
[15:51] <AlbertA> kgunn: don't notice any jerkiness either
[15:51] <AlbertA> kgunn: the only thing is sometimes I see flashes of black screen or other content while clicking the home button
[15:52] <kgunn> @unity ^ anyone else seeing any new jerkiness in the latest image ?
[15:52] <mterry> A little bit yeah, scrolling scope to scope and such
[15:53] <kgunn> yeah...besides scopes tho....that responsive changes alot....original bug we were dicussing was "shell" generically
[15:54] <tsdgeos> kgunn: so latest image is ceirtainly slower if we compare with the previous "approved" image that didn't use new-scopes code yet (didn't even use Qt 5.2 afaik) but not against yesterdays
[15:55] <davmor2> AlbertA: kgunn: I see it
[15:56] <kgunn> where?
[15:56] <Saviq> kgunn, I duped that bug already
[15:57] <davmor2> kgunn: goto the apps scope, click on My Apps scroll slowly to the bottom then flick scroll to the top, it's like it skips the middle if you have a few apps installed
[15:57] <Saviq> kgunn, it's due to new scopes, we have a first instalment of a fix MP'd already
[15:58] <davmor2> kgunn: you also get missing icons that are then drawn after etc etc etc
[15:58] <kgunn> Saviq: davmor2 ...right i'm trying to avoid being _that_ guy_ dismissing a bug too early, original bug was "shell" not dash...e.g. jerky dismiss of lockscreen
[15:58] <kgunn> davmor2: right...dash, we got people on it...not worried about dash
[15:58] <Saviq> kgunn, yeah, shell == dash until we split it out ;)
[15:58] <tedg> Saviq, This tag stripping takes forever, you sure you don't want to keep them? :-)
[15:58] <kgunn> well right :P but i'm already mentally there
[15:59] <Saviq> kgunn, single UI thread, gets blocked by dash changes, all shell gets jerky
[15:59] <Saviq> tedg, rofl, yes :D
[15:59] <davmor2> kgunn: the lockscreen did have issues.  I think the big issue there is if it is still updating due to the QT bug while swiping it
[15:59] <kgunn> Saviq: davmor2 ...ok, now i can be that guy, thanks for the explanation
[15:59] <Saviq> davmor2, I don't think you'd be able to swipe it before it's processed all of the queued events
[16:00] <Saviq> kgunn, we'll get there - splitting the dash into app will help, splitting the greeter will help, improving dash performance will help, but the underlying problem is the same
[16:01] <AlbertA> kgunn: it's hard interpreting subjetive matter - but the only thing I would consider "jerky" is a flash of
[16:02] <AlbertA> kgunn: of another app's content is shown (not the one you have open) as it transitions to the dash
[16:03] <AlbertA> kgunn: this is using the devel r294 as in the bug report
[16:13] <Cimi> Saviq, did u try?
[16:13] <Saviq> AlbertA, right, that's another thing, it's apps launching slowly and the dash going out of the way too soon
[16:13] <Saviq> AlbertA, will be gone with Qt compositing
[16:14] <Saviq> s/the dash going away/the shell going away/
[16:14] <Saviq> Cimi, in Spanish 4 tests out of 7 failed for me (for the ap test)
[16:15] <Saviq> Cimi, no crash of settings
[16:15]  * Saviq waves
[16:17] <Cimi> Saviq, ok. I told you my phone doesn't like spanish :P
[16:24] <mhr3> Saviq, is there a way to enable the perfomance overlay graph in the shell itself?
[16:30] <Saviq> mhr3, haven't tried, didn't know that landed...
[16:32] <mhr3> Saviq, i tried setting the envvar, but no dice
[16:33] <Saviq> mhr3, we don't use the MainView, might be would need a lower-level access
[16:33] <elopio> Saviq: the script has finished with my two branches, remote and local.
[16:34] <Saviq> elopio, thanks!
[16:34] <elopio> I hope I won't introduce any more tags.
[16:34] <Saviq> elopio, no worries, I'll be monitoring and clearing things up as needed for some time ahead
[16:34] <mhr3> Saviq, would be very nice to have
[16:34] <fginther> bschaefer, hey do you happen to know how to suppress the 'Report a problem...' dialog windows.
[16:34] <fginther> for example: https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty-autopilot/116/artifact/results/autopilot/artifacts/autopilot.tests.unit.test_testcase.InnerTest.test_foo.ogv
[16:35]  * bschaefer looks
[16:35] <Saviq> mhr3, thinking aloud... will be difficult to fit in the launcher and panel surfaces, once those become separate ;)
[16:35] <bschaefer> fginther, i do not :(
[16:35] <Saviq> mhr3, but yeah
[16:35] <bschaefer> fginther, i would love to know though
[16:35] <Saviq> mhr3, file a bug please?
[16:38] <fginther> bschaefer, if I find out, I'll pass it on
[16:38] <mhr3> Saviq, https://bugs.launchpad.net/unity8/+bug/1308150
[16:38] <bschaefer> fginther, thanks! Im not sure who to poke...possibly someone in desktop?
[16:38] <bschaefer> seb128, ?
 bschaefer, hey do you happen to know how to suppress the 'Report a problem...' dialog windows.
[16:39] <Saviq> mhr3, cheers
[16:39] <seb128> fginther, bschaefer: edit /etc/default/apport and change the enabled to 0?
[16:39] <seb128> fginther, bschaefer: why do you want to do that though?
[16:39] <bschaefer> seb128, that sounds to reasonable :)
[16:39] <bschaefer> seb128, its causing a test to fail
[16:39] <fginther> seb128, the windows interfeer with autopilot tests
[16:39] <bschaefer> fginther> for example: https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty-autopilot/116/artifact/results/autopilot/artifacts/autopilot.tests.unit.test_testcase.InnerTest.test_foo.ogv
[16:39] <seb128> oh, ok
[16:40] <seb128> so yeah, turn apport off
[16:40] <fginther> seb128, thanks, I've had apport issues on this test setup before, maybe I fixed them and didn't realize it
[16:41] <bschaefer> seb128, thanks!
[16:41] <seb128> yw!
[16:43] <Saviq> mterry, when you have a moment: bug #1308139
[16:43] <mterry> Saviq, noted
[16:44] <Saviq> popey, you're crazy ↑ :P
[16:44] <popey> Thank you.
[16:44] <popey> That's the nicest thing anyone has said to me all day.
[16:45] <Saviq> ;D
[16:48] <davmor2> popey: that's not fair I said Hello earlier :D
[16:51] <Saviq> davmor2, na na na na na, na na na na naa na
[16:52] <Cimi> Saviq, I (wrongly) thought that doing import locale, then adding locale.setlocale(locale.LC_ALL, "C") would do the trick for the autopilot tests
[16:53] <Cimi> Saviq, I put it inside __init__.py of the shell emulator, no luck
[16:53] <Cimi> Saviq, you have better recommendation where to put it?
[16:53] <Saviq> Cimi, as said, you need to put it in process_helpers
[16:54] <Saviq> Cimi, how could python's internal locale setting affect that of unity8?
[16:54] <Saviq> Cimi, not to mention that unity8 in autopilot runs under upstart
[16:54] <Cimi> Saviq, thought that the emulator was running unity8
[16:55] <Cimi> ok
[16:55] <Saviq> Cimi, what do you mean by "emulator running unity8"?
[16:55] <Cimi> shell emulator was running the process
[16:55] <Cimi> I will do with process helpers
[16:56] <Saviq> Cimi, even if it did, .setlocale() does nothing with the environment
[16:56] <Saviq> Cimi, it only affects the current python process
[16:57] <Cimi> Saviq, so I need to run unity with the variable?
[16:57] <Saviq> Cimi, not "you", but upstart
[16:58] <Saviq> Cimi, you need to tell upstart to run unity8 with LC_ALL=C
[16:58] <Saviq> Cimi, read through process_helpers.py, you should easily find out what's happening
[17:05] <mzanetti> mhr3: http://i.imgur.com/Yfw9fL9.png
[17:05] <mhr3> mzanetti, wooo, how?
[17:06] <mzanetti> mhr3: I've just imported "import Ubuntu.PerformanceMetrics 0.1" in Shell.qml and added PerformanceOverlay { active: true } at the bottom
[17:06] <mzanetti> seems to just work
[17:06] <mzanetti> altough I'm not entirely sure how to read it yet
[17:07] <mhr3> mzanetti, isn't it cpu usage + time to render a frame?
[17:07] <mzanetti> mhr3: yeah seems so. it also only moves if there's activity. which I find nice :)
[17:08] <mzanetti> heh, you can even drag it around.
[17:08] <mzanetti> what an awesome toy
[17:11] <mhr3> Saviq, ^ now just integrate somehow ;)
[17:18] <Cimi> Saviq, which function is called when the tests end?
[17:18] <Cimi> Saviq, I can set the env variable, but I need to unset it after
[17:19] <mzanetti> Cimi: cleanupTestcasE()
[17:19] <Cimi> mzanetti, and if user does ctrl c?
[17:20] <mzanetti> then you're screwed I guess
[17:20] <mzanetti> hmm... let me think
[17:20] <Cimi> mzanetti, ops, I meant autopilot
[17:20] <Saviq> Cimi, you don't need to unset it
[17:20] <Cimi> Saviq, I added a
[17:21] <Cimi> subprocess.call(['/sbin/initctl', 'set-env', 'LC_ALL=C'])
[17:21] <Cimi> before calling initctl start7 unity8
[17:21] <Saviq> Cimi, you can't do that
[17:21] <Cimi> ok
[17:21] <Cimi> wow
[17:22] <Saviq> Cimi, without --global, this only affects the current job, but you're not inside any job
[17:22] <Saviq> Cimi, you just need "args" to include "LC_ALL=C"
[17:25] <Cimi> Saviq, that works - I thought I should have run upstart with that
[17:26] <Saviq> Cimi, "run upstart" is not what you're doing
[17:27] <Saviq> Cimi, you need to understand, upstart is a process (just one) that runs across your login session
[17:27] <Cimi> Saviq, I know that
[17:27] <Saviq> Cimi, initctl just tells that process to run some job
[17:27] <Cimi> Saviq, I mean starting the job obviusly
[17:27] <Saviq> Cimi, but initctl doesn't actually start the process
[17:27] <Saviq> Cimi, it just tells the already running upstart process to launch another
[17:27] <Cimi> I didn't know this then
[17:28] <Cimi> I thought initctl was running it
[17:28] <Cimi> so like, set the variable before initctl starts my process
[17:28] <Saviq> no, this way the upstart process would know nothing about it, would not handle its environment etc
[17:30] <Cimi> nope
[17:30] <Cimi> doesn't work this way
[17:30] <Cimi> tried with command = ['/sbin/initctl', 'start', 'unity8', 'LC_ALL=C'] + list(args)
[17:31] <Cimi> it worked with my way
[17:31] <Cimi> subprocess.call(['/sbin/initctl', 'set-env', 'LC_ALL=C'])
[17:33] <Cimi> with         args += ("LC_ALL=C",)
[17:33] <Cimi>         command = ['/sbin/initctl', 'start', 'unity8'] + list(args) seems to work
[17:33] <Cimi> nope
[17:39] <Cimi> Saviq, the bloody indicators are in different locale
[17:40] <Cimi> Saviq, I think we need set env
[17:40] <Cimi> anyway I'm fine if we want to talk tomorrow morning, we're both past our EOD
[17:47] <Saviq> Cimi, ah crap you're right, those strings come straight from indicators...
[17:47] <Saviq> Cimi, so yeah, this needs a initctl set-env --global LC_ALL=C
[17:48] <Saviq> Cimi, a initctl emit indicator-services-end
[17:48] <Saviq> Cimi, and revert of the env...
[17:48] <Saviq> this is rather big
[17:53] <Saviq> Cimi, ok, leave it for now, sorry for putting you on a wild goose chase, we'll have to think a bit more about this
[17:53] <Saviq> Cimi, please comment on the bug with your findings
[17:54] <Saviq> Cimi, and well, we can make the qml tests happen, but will need more work on ap ones
[18:44] <Saviq> popey, show off!
[18:44] <Saviq> https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1307052/comments/6 ;)
[18:44] <popey> ☻
[18:55] <mterry> kgunn, Saviq: could one of you please update silo 002 to drop platform-api & unity-mir?  And leave the only mir branch as lp:~mterry/mir/no-nested-display-config ?  (i.e. no longer include Mir 0.1.8)
[18:55] <mterry> (that mir branch doesn't change API/ABI, so it's fine to build by itself)
[18:56] <mterry> (and is already targeted against lp:mir not mir/devel)
[18:56] <mterry> I suppose USC also needs a rekick to get a higher version
[18:59] <Saviq> mterry, so down to http://pastebin.ubuntu.com/7256944/
[18:59] <Saviq> mterry, original list: http://pastebin.ubuntu.com/7256948/
[18:59] <mterry> Saviq, can drop ~kgunn72/unity-system-compositor/usc-rebuild-mir0.1.8
[19:00] <Saviq> mterry, ah right, there's a branch already
[19:00] <mterry> Saviq, but yeah, looks right
[19:00] <Saviq> robru, could you please drop unity-mir and platform-api from landing-002 ppa (just the packages)
[19:02] <robru> Saviq, done
[19:02] <Saviq> robru, thanks
[19:02] <robru> Saviq, you're welcome
[19:04] <mterry> Saviq, robru: awesome ytb
[19:04]  * Saviq looks up ytb
[19:04] <Saviq> :)
[19:06] <robru> mterry, haha, thanks
[19:07] <mterry> :)  you guys need to be told you're the best more often clearly
[21:31] <Saviq> alesage, can you please run https://code.launchpad.net/~allanlesage/unity8/dash-apps-visible-ordering/+merge/213913/comments/511725 somewhere in a terminal? and make sure to run it on your local checkout, too, so they don't get uploaded again?
[21:32] <alesage> Saviq, sure one sec
[21:32] <Saviq> alesage, it'll take a 5 minutes or so for the remote branch
[21:32] <alesage> Saviq, sorry I missed that earlier :/ , one min (or 5)
[21:32] <Saviq> alesage, 5
[21:32] <Saviq> alesage, at least
[21:33] <Saviq> alesage, it has to call into launchpad separately for each of 300+ tags we inadvertently brought with us from lp:unity...
[21:36] <alesage> Saviq, running now
[21:37] <Saviq> alesage, great, thanks
[21:42] <alesage> Saviq, quick q: do you have any idea where this lp:unity8/cmake/modules/ParseArguments.cmake came from?
[21:42] <alesage> Saviq, I'm being asked to package up some coverage bits and the licensing is possibly problematic
[21:43] <Saviq> alesage, AFAICT http://www.cmake.org/Wiki/CMakeMacroParseArguments
[21:44] <alesage> Saviq many thanks
[21:44] <Saviq> alesage, looks like it might be obsolete, too...
[21:44] <Saviq> alesage, in favour of http://www.cmake.org/cmake/help/v2.8.9/cmake.html#module:CMakeParseArguments
[21:44] <alesage> Saviq aha even better thx
[21:44] <Saviq> :)
[21:56] <thomi> kgunn: any luck with the release yesterday?
[21:57] <kgunn> thomi: yes, all tested ok & QA +1'd
[21:57] <Saviq> thomi, it's in distro already
[21:57] <thomi> Saviq: kgunn: aswesome, thanks guys
[21:57] <Saviq> thomi, we even abused your release gatekeeper job
[21:57] <thomi> :)
[21:57] <Saviq> one flaky fail there
[22:00] <kgunn> thomi: yeah on desktop...6 failures for ap3 before (e.g. existing archive) and only 5 failures on ap3 with our packages
[22:00] <kgunn> is that just a sign of more flakiness
[22:00] <kgunn> ?
[22:01] <thomi> kgunn: normally yes. We usually do some pretty exhaustive investigation at that point and make sure we can reproduce the failures with the older release
[22:09] <kgunn> josharenson: just curious, any luck with glmark2 as part of ci today ?
[22:11] <alesage> Saviq, pushed tag-stripping for dash-apps-visible-ordering
[22:11] <Saviq> alesage, oh noes, did you strip locally first?
[22:12] <alesage> Saviq, yes
[22:12] <Saviq> alesage, ok
[22:12] <Saviq> alesage, well... whatever you did...
[22:12] <Saviq> alesage, the tags are back on your branch :|
[22:12] <alesage> Saviq, ugh
[22:12] <Saviq> alesage, you must've just pushed them... I saw them down to 14, now back to 364...
[22:13] <Saviq> alesage, you can point the script at multiple places at once, it will go through them
[22:13] <Saviq> alesage, local or remote
[22:13] <Saviq> alesage, tags in bzr are not transferred with commits, they're completely separate entity
[22:13] <alesage> Saviq, ok sorry--I was fuzzy on how the script works, will re-do :/
[22:14] <Saviq> alesage, that's why it's such a pain to make them go away, as soon as you pull them from somewhere / push them somewhere, the whole set is back...
[22:14] <alesage> Saviq, sorry for the extra trouble, must be late for you
[22:14] <Saviq> alesage, no worries :)
[22:15] <Saviq> alesage, so what happened was: running the script with lp:foo deleted all the tags in lp:foo, but you had them stored in your local checkout, and they got brought back when you pushed...
[22:15] <alesage> Saviq, yes I realize now, should've investigated
[22:15] <Saviq> alesage, you can probably see in your terminal history - "350 tags updated" or so
[22:16] <alesage> Saviq, yep exactly as you say
[22:16] <Saviq> alesage, no worries, please let me know when that's done again :)
[22:16] <alesage> Saviq, ok willdo
[22:24] <josharenson> kgunn: I have created a new category (performance test) and there are compile time checks that look for the binary before building the test.
[22:25] <josharenson> kgunn: I don't know how to make the build system install the package automatically though
[22:26] <josharenson> kgunn: since the compile time check is built in, I will propose it for merging after I clean it and test it, as there is no risk.
[22:33] <kgunn> josharenson: great, thanks
[22:33] <kgunn> oh so closer to the goal on that one...
[22:50] <alesage> so Saviq, having run the stripping-tags script remotely, is a commit and push necessary?
[22:50] <Saviq> alesage, no, commit/push has no bearing on tags
[22:50] <Saviq> alesage, just make sure you run it on any local checkouts
[22:50] <Saviq> alesage, it will be much quicker
[22:51] <alesage> Saviq, ok then I'll just take my fingers off the keys now and slowly step backward
[22:51] <Saviq> :)
[22:51] <Saviq> alesage, just bzr tags | wc -l, if there's more than 19 - run the script
[22:51] <Saviq> alesage, as 19 is what's currently in trunk
[22:51] <alesage> Saviq, ok will do in future
[22:51] <Saviq> alesage, I'll be keeping an eye on that, too, so will let you know in case they creep up again
[22:52] <alesage> Saviq, ok thanks for your help