[07:46] <tsdgeos> Mirv: ping
[08:06] <Mirv> tsdgeos: pong
[08:06] <tsdgeos> Mirv: spoke to thiago yesterday, he's shelving the dbus changes for Qt 5.6
[08:07] <tsdgeos> in case you need to free a silo or something
[08:08] <Mirv> tsdgeos: ok, it'd good to know. I wonder if we can manage without them. we'll notice of course if we get QDBus related crash traces.
[08:13] <tsdgeos> Mirv: i guess we will
[08:19] <tsdgeos> dednick: just tested and commented in https://code.launchpad.net/~nick-dedekind/ubuntu-settings-components/fix-maximumWaitBufferInterval/+merge/257347
[08:19] <tsdgeos> please check i'm not testing the wrong thing :D
[08:19] <dednick> tsdgeos: there's a branch to go with it now. should probably add that to the MP
[08:20] <tsdgeos> please
[08:20] <dednick> tsdgeos: there's a bug in the indicator mock which throws off the AP test
[08:20] <dednick> tsdgeos: done
[08:20] <dednick> https://code.launchpad.net/~nick-dedekind/unity8/fix-laggy-indicators-autopilot/+merge/258411
[08:20] <dednick> tsdgeos: ^
[08:21] <tsdgeos> tx
[08:26] <pstolowski> tsdgeos, hey, i've sent you the proposal for edit widget
[08:26] <tsdgeos> okidoki
[08:28] <tsdgeos> i'll have a look soon-ish
[08:31] <tsdgeos> dednick: unity8.application_lifecycle.tests.test_application_lifecycle.ApplicationLifecycleTests.test_greeter_hides_on_app_open is still failing as autopilot test, did you have a look at it or should we find someone else to?
[08:31] <dednick> tsdgeos: I didn't have a look at that one. only the indicator ones
[08:32] <dednick> tsdgeos: i can take a look at that one as well though
[08:33] <tsdgeos> dednick: that'd be great
[08:33] <tsdgeos> maybe we can get green back \o/
[08:34] <dednick> tsdgeos: lol. for a day or 2 at least ;)
[08:34] <tsdgeos> until the next landing :D
[08:47] <dednick> tsdgeos: um. is the greeter supposed to hide if an app opens?
[08:47] <dednick> tsdgeos: what if you have a password?
[08:48] <dednick> tsdgeos: oh, i think it might just be that the greeter is swiped away, but not "unlocked"
[08:50] <tsdgeos> dednick: right
[08:51] <tsdgeos> which actually the test seems to be doing
[08:51] <tsdgeos> so have to check where it's failing
[08:52] <dednick> tsdgeos: yeah. looks like it can't find the proxy or something. but checking on ubuntu-app-list shows the fake app. will need to look into it in more detail.
[08:53] <dednick> tsdgeos: works if you have the greeter open though :/
[08:53] <dednick> unlocked i mean
[08:54] <tsdgeos> dednick: you mean wihtout password?
[09:04] <tsdgeos> pstolowski: why author?
[09:05] <pstolowski> tsdgeos, i suspect we may want to display your name as we do with existing reviews (i don't have visuals to confirm)?
[09:05] <pstolowski> tsdgeos, but maybe not
[09:05] <tsdgeos> pstolowski: but can't we do that with a text widget or something? that's how we do it now, no?
[09:06] <tsdgeos> maybe not
[09:06] <pstolowski> tsdgeos, now we do it with 'reviews' widget (see the doc i linked to)
[09:06] <tsdgeos> right
[09:06] <pstolowski> tsdgeos, 'reviews' widget takes multiple tuples and has ;'author' for each
[09:07] <tsdgeos> pstolowski: let's have it in there, it won't hurt and then we can decide whether to show it in the ui or not
[09:07] <pstolowski> tsdgeos, +1
[09:08] <tsdgeos> just answered the email for completion
[09:09] <pstolowski> tsdgeos, cool, thanks
[09:12] <dednick> tsdgeos: no, if you enter the password manually while it's "waiting for whatever it is waiting for"
[09:13] <dednick> tsdgeos: nevermind. i'll figure it out ;)
[09:13] <tsdgeos> dednick: that's weird i don't remember that test went past the locker
[09:13] <tsdgeos> dednick: :)
[09:14] <dednick> tsdgeos: it's possible we're suspending the app before AP is able to get the proxy for introspection.
[09:14] <tsdgeos> may be
[09:14] <tsdgeos> afaik this test used to work not very long ago
[09:17] <Saviq> tsdgeos, dednick, https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1446846/comments/2
[09:17] <Saviq> tsdgeos, dednick, I think the problem there is that we're left with the lockscreen after having spawned the app
[09:18] <Saviq> so greeter hides, sure, but the lockscreen's still on
[09:18] <dednick> Saviq, tsdgeos: ubuntu-app-watch says the apps are being paused. both dash and fake app.
[09:19] <Saviq> yup
[09:19] <tsdgeos> Saviq: sure but that's always been the way it worked and i think that test passed "before"
[09:19] <tsdgeos> for some definition of "before"
[09:19] <tsdgeos> obviously way before you filed the bug
[09:20] <dednick> tsdgeos: perhaps we need to modify the test. it's making the assumption that the app is in a "running" state at some arbitrary time after starting
[09:20] <dednick> where that should only definately the case after we unlock the greeter.
[09:21] <dednick> Saviq: ^?
[09:21] <Saviq> dednick, yeah, definitely a test issue
[09:25] <dednick> Saviq, tsdgeos: hm. unfortunately it's autopilot/launcher code that's waiting for the proxy :/
[09:26] <Saviq> tsdgeos, fwiw I think we "fixed" the fact that the apps were getting focused under lockscreen at some point
[09:26] <Saviq> dednick, we might need to trick the lockscreen to go away in this test
[09:26] <Saviq> tsdgeos, *or* the mock lightdm refactor
[09:27]  * Saviq wonders if that test wasn't relying on the "single" lightdm mock
[09:27] <tsdgeos> may be
[09:27] <tsdgeos> dednick: do we have a review checlist for https://code.launchpad.net/~nick-dedekind/ubuntu-settings-components/fix-maximumWaitBufferInterval/+merge/257347 ? or do i use the unity8 one and that's it?
[09:27] <dednick> Saviq: well, we can force the lockscreen open, but that's cheeting a bit ;)
[09:28] <dednick> *cheating
[09:28] <dednick> tsdgeos: yeah, let me add it quick
[09:28] <Saviq> dednick, I think we have the mock lightdm with no password for this use case
[09:28] <dednick> tsdgeos: oh. review. don't think we have one
[09:28] <dednick> just an MP one
[09:29] <tsdgeos> dednick: well the test is about "opening app hides greeter", it's not cheating to put there a greeter that helps us testing
[09:30] <tsdgeos> dednick: oh, i just realized i can't top approve https://code.launchpad.net/~nick-dedekind/ubuntu-settings-components/fix-maximumWaitBufferInterval/+merge/257347 you'll need to find someone that's on the team
[09:30] <dednick> tsdgeos: i meant that it's cheating to force the lock screen open explicitly. since it skips what we're testing. not having a password enabled it's cheating.
[09:30] <tsdgeos> dednick: no no, because having the lock screen is fine
[09:31] <tsdgeos> it's what's it is supposed to do
[09:31] <tsdgeos> swipe the greeter away
[09:31] <tsdgeos> if you have no lock screen then you get the app
[09:31] <tsdgeos> if you have lock screen then you get the lockscreen
[09:31] <Saviq> dednick, tsdgeos, LIBLIGHTDM_MOCK_MODE=single will fix the test I reckon
[09:31] <tsdgeos> so we can either adapt the test to just check that the greeter went away and not test the app is running
[09:32] <tsdgeos> or we can adapt the test to check the greeter went away and the app is running
[09:32] <dednick> cimi: can you add Unity team to the ubuntu-settings-components team?
[09:32] <cimi> dednick, yup
[09:32] <tsdgeos> i have no particular opinion on what's better
[09:33] <dednick> Saviq: how do i set the env var for a single test, or do i need to move it to another test suite?
[09:33] <dednick> since u8 is started by setup
[09:33] <Saviq> dednick, grep for LIGHTDM in tests/autopilot, there's others that do it
[09:33] <cimi> dednick, done
[09:33] <Saviq> even if they're doing it in a hacky way
[09:34] <dednick> answer is to make a new test case :)
[09:44] <tsdgeos> dednick: or that
[09:45] <dednick> tsdgeos: that's the way everything does it. can't launch unity8 before setting the env
[09:47] <tsdgeos> dednick: you lost me there :D but that's fine if you know what you're doing :D
[10:15] <dednick> Saviq: damnit. can't seem to use fake greeter. if we do, we don't get real apps...
[10:18] <dednick> Saviq: i could thread it to unlock while waiting for the proxy :/
[10:36] <Saviq> dednick, you mean that the import path is the same for fake greeter and fake apps?
[10:37] <Saviq> we need to be able to pick'n'choose...
[10:38] <dednick> Saviq: you need to set _qml_mock_enabled apparently
[10:39] <dednick> Saviq: which i think gets all the mocks rather than just lightdm
[10:39] <Saviq> dednick, yeah
[10:40] <dednick> Saviq, tsdgeos: http://pastebin.ubuntu.com/11023987/ :S
[10:41] <dednick> Saviq: thread waits until the greeter is swiped by app open, and unlocks it. :)
[10:41] <Saviq> dednick, that kinda works...
[10:41] <dednick> pretty dodgey
[10:41] <dednick> but will work until we can get selective mock shizzle.
[10:41] <Saviq> dednick, the other way would be to install a copy of the mock lightdm into a separate path (like we do with Unity.Application)...
[10:42] <tsdgeos> dednick: i think it's ok
[10:43] <dednick> I'll put in a FIXME for when we have mock selection.
[10:51] <dednick> tsdgeos: https://code.launchpad.net/~nick-dedekind/unity8/fix-autopilot-failures-1446846/+merge/258411
[10:51] <dednick> i've just updated the original MP.
[10:51] <tsdgeos> k
[11:40] <dednick> tsdgeos: should I get on with the video play back in previews? or were you planning on doing it?
[11:45]  * dednick goes for lunch
[12:38] <tsdgeos> dednick: you can take it
[13:22] <tsdgeos> pstolowski: https://code.launchpad.net/~aacid/unity8/edit_reviews/+merge/258623
[13:23] <pstolowski> tsdgeos, awesome! i'll give it a try with my code
[13:23] <dandrader> mzanetti, is any sort of qml cache present on devel-proposed?
[13:23] <tsdgeos> dandrader: yes
[13:23] <dandrader> mzanetti, I'm getting a very weird behavior that is driving me mad
[13:24] <dandrader> mzanetti, it seems that when I change from DesktopStage to TabletStage or vice-versa
[13:24] <dandrader> mzanetti, the previous stage somehow lives on
[13:24] <tsdgeos> ah that kind of cache, don't know, we have the file cache to speed up startup
[13:24] <mzanetti> dandrader, I think that's still the Loader bug
[13:24] <tsdgeos> but shouldn't affect that
[13:24] <dandrader> mzanetti, although I can't see it. some of its bindings still seem to act
[13:24] <mzanetti> yeah...
[13:25] <mzanetti> there is a bug in the loader, in combination with gsettings-qml
[13:25] <mzanetti> I digged into that for a day... found a workaround, but still haven't understood what's happening
[13:26] <dandrader> ok, so I'm not crazy afterall
[13:26] <mzanetti> if gsettings changes and causes the loader to load something different in the same event loop pass, the loader won't free its memory
[13:26] <mzanetti> workaround is to decouple it with a timer of interval 1 or similar
[13:26] <dandrader> mzanetti, so the workaround is to have a timer to trigger the Loader.source change?
[13:26] <mzanetti> well, actually, lemme find a branch
[13:26] <dandrader> ditto
[13:27] <dandrader> mzanetti, so you don't have a merge proposal with that workaround?
[13:27] <mzanetti> dandrader, this one would fix it too: https://code.launchpad.net/~mzanetti/gsettings-qt/queued-processing/+merge/248224
[13:27] <mzanetti> IMO this one would be nicer as a timer in unity
[13:27] <mzanetti> only problem is: I haven't understood why this is happening
[13:30] <dandrader> mzanetti, this explains why I don't get this issue when playing with "make tryShell"
[13:30] <dandrader> or when running the qml tests
[13:30] <mzanetti> yeah... this was driving me nuts too a while back
[13:32] <dandrader> mzanetti, this is blocking the manual testing of my "app lifecycle logic in  unity8" work. I will have to add the TImer workaround to its branch...
[13:33] <mzanetti> mhm...
[13:33] <mzanetti> I still wonder if we shouldn't land that gsettings patch...
[13:33] <mzanetti> larsu, hey, we're still suffering from this ^^
[13:33] <mzanetti> wdyt, should/can we land this? https://code.launchpad.net/~mzanetti/gsettings-qt/queued-processing/+merge/248224
[13:35] <mzanetti> if so, I'd fix the test that's failing because of the change
[13:41] <pstolowski> tsdgeos, is the editIcon already available on the phone?
[13:42] <tsdgeos> pstolowski: it's part of the theme, so yeah
[13:42] <tsdgeos> should be
[13:42] <pstolowski> ok
[14:20] <dandrader> MacSlow, wow, so we might finally getting a stable shellRotation AP test!!! what was the fix?
[14:22] <MacSlow> dandrader, the "granularity" for the faked sensor-events for "right -up" orientation seems to have been too rough
[14:22] <MacSlow> dandrader, currently at 50 successful runs in a row for "right-up"
[14:23]  * MacSlow really hopes this is the final issue to solve for that branch!!!
[14:26] <MacSlow> dandrader, and that in turn caused qtubuntu-senros to sometimes not recognize the orientation change, because there was not enough change in between
[14:29] <dandrader> mzanetti, the workaround bazaar.launchpad.net/~dandrader/unity8/app-state-handling/revision/1771
[14:30] <mzanetti> yeah... looks similar to what I had
[14:30] <mzanetti> dandrader, IMO we should rather land the gsettings-qml patch than this.... but good you have a way to be unblocked
[14:31] <dandrader> mzanetti, I think too, but having the unity8 workaround unblocks me and removed a dependency on a different project
[14:31] <mzanetti> ack
[15:15] <mzanetti> pstolowski, tsdgeos: seems we have conflict between silo 7 and 39
[15:15] <tsdgeos> fight to death, i'm using popcorn!
[15:16] <tsdgeos> mzanetti: you mean code confligt?
[15:16] <mzanetti> I don't think any of the both has higher priority than the other
[15:16] <mzanetti> let's QA pick one and rebuild the other
[15:17] <tsdgeos> mzanetti: or "conflict because we can't land the same thing twice"?
[15:17] <mzanetti> yeah... if we'd land both as is, the merge between the two wouldn't be tested
[15:17] <tsdgeos> which kind of makes sense
[15:17] <pstolowski> mzanetti, tsdgeos silo 7 is older ;)
[15:17] <mzanetti> ack
[15:17] <mzanetti> wfm
[15:17] <tsdgeos> yeah
[15:27] <mhall119> mzanetti: Saviq: what do I need to do to compile and run Unity8 on utopic?
[15:28] <mzanetti> good question... probably not possible
[15:28] <mzanetti> mhall119, what's the scope? just want to try trunk?
[15:29] <mhall119> mzanetti: yes
[15:29] <Saviq> mhall119, you need to upgrade to vivid ;)
[15:29] <mhall119> Saviq: anything short of that?
[15:29] <mhall119> the unity-team PPA doesn't seem to have anything in it anymore
[15:29] <mzanetti> yeah... you don't want to build all the deps that updated
[15:29] <Saviq> mhall119, backport all the packages we rely on to utopic
[15:30] <mzanetti> mhall119, a vmware vivid install would do too
[15:31] <mhall119> so then, I guess I should update the docs to say devs must be on vivid
[15:32] <tsdgeos> yeah
[15:32] <tsdgeos> just vivid-ize yourself and the docs
[15:32] <mzanetti> mhall119, I would go as far as saying that devs must be on the latest devel
[15:32] <mzanetti> once wily starts rolling it probably won't compile for long on plain vivid any more
[15:33] <mhall119> mzanetti: that's going to make casual contribution nearly impossible
[15:34] <mzanetti> mhall119, so the thing is, there are many libraries outside of unity which just get updates because unity requires them...
[15:35] <mzanetti> you can either update/backport those libraries or use the latest archive
[15:35] <mhall119> mzanetti: I know that backporting those into a PPA is extra work for you guys, but it will make it easier for others to get involved and contribute
[15:36] <mzanetti> I'll think about how much it would be... Can't promise anything though.
[15:36] <mhall119> thanks
[15:36] <mhall119> it's a tradeoff, I know, and if it's not worth it then that's fair
[15:38] <dupingping> Look http://vimeo.com/126505316
[15:40] <mzanetti> mhall119, it would require backporting mir and it's dependencies too... at which point you'd have like half of the archive in that ppa...
[15:40] <mzanetti> its
[15:40] <mzanetti> grr
[15:41] <mhall119> mzanetti: ok, if we can't backport can we get some documentation about how to set it up and run it in a VM? Would the dev have to write the code in the VM or on their host machine? Can we provide regularly updated VM images?
[15:41] <mhall119> anything to lower than barrier to entry
[15:42] <mzanetti> mhall119, you just grab the latest image from the official downloads and do-release-upgrade --devel on it
[15:42] <mzanetti> as of that, just apt-get upgrade to stay up to date
[15:44] <mzanetti> easiest is probably if you develop in there. but nothing prevents you to open the source from a shared folder on the host system and edit away there
[15:45] <mhall119> mzanetti: we're still talking 30-60 minutes of work before somebody can even start poking around in the code :(
[15:45] <mzanetti> mhall119, well, you can always build the revision that is released on your system
[15:46] <mhall119> mzanetti: but that wouldn't help someone wanting to contribute new features or fixes
[15:46] <mzanetti> but how would someone contribute new things if he doesn't want to run the new things?
[15:46] <mhall119> I want to encourage community contributes to get involved in Unity8 development
[15:47] <mhall119> mzanetti: they want to run the new Unity 8, probably in a window under Unity 7, they don't care about the rest of the OS
[15:47] <mzanetti> this is quite a core piece of the software stack we're talking about... it's not an app, it's the thing where apps run inside of
[15:48] <mhall119> mzanetti: again, I'm not saying you have to backport, I'm just looking for ways to make it easier to get started contributing
[15:49] <mzanetti> I think we do publish nightly images, don't we?
[15:49] <mhall119> any additional steps, no matter how logical and necessary they are, are still going to deter some folks
[15:49] <mhall119> mzanetti: of the base distro yes, not something that already has the developer tools and all
[15:49] <dandrader> greyback, https://code.launchpad.net/~dandrader/qtmir/detach-state-from-focus/+merge/258648
[15:50] <mzanetti> mhall119, from the core distro, an apt-get build-dep unity8 should work
[15:54] <greyback> dandrader: 894 lines, wow :)
[15:54] <dandrader> greyback, mostly because of the test I think
[15:55] <greyback> dandrader: yeah it's not as bad as I expected
[15:57] <dandrader> mzanetti, the number of approved branches is getting unwieldy
[15:58] <mzanetti> I know...
[15:58] <mzanetti> dandrader, we have 2 silos waiting for QA testing
[15:58] <dandrader> mzanetti, any news no wily repos?
[15:59] <dandrader> s/no/on
[15:59] <mzanetti> dandrader, no... but I expect to release next week to wily