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