[08:49] <tsdgeos> Saviq: 2 days left, do https://code.launchpad.net/~aacid/unity8/suspend_screenshoting/+merge/257119 !
[08:49] <Saviq> tsdgeos, actually flashing my mako now to test
[08:49] <tsdgeos> \o/
[08:50] <Saviq> tsdgeos, SessionGrabber::screenshotGrabbed, don't want ::grabbed?
[08:51] <Saviq> tsdgeos, and re: shared ptr, yeah for the watcher
[08:53] <tsdgeos> Saviq: i think i prefer the extra verbosity there tbh
[08:54] <Saviq> tsdgeos, ah and now I get it I think, the watcher likely registers itself with the future that's on the other thread?
[08:55] <tsdgeos> Saviq: tbh i don't think i need a shared pointer in there
[08:55] <tsdgeos> i can just use a raw pointer as well
[08:56] <Saviq> tsdgeos, /me just looked at the whole .reset() logic and thought it maybe unnecessarily complex
[08:56] <tsdgeos> i just did it because the evil unity-api people created noise on my head about how raw pointers are evil
[08:57] <tsdgeos> let me turn it into a raw pointer
[08:57] <Saviq> :D
[09:03] <tsdgeos> Saviq: pushed
[09:12] <Saviq> tsdgeos, tx, btw, you being in BlueFin it'd make sense to grab someone from design and show them this, ask if maybe they'd like some visual treatment
[09:12] <Saviq> tsdgeos, noticed a visual issue: splash → screenshot has no transition
[09:13] <tsdgeos> hmmm
[09:19] <tsdgeos> Saviq: what transition would you like there
[09:19] <Saviq> tsdgeos, I think we need a fade-in
[09:20] <tsdgeos> Saviq:  "Yeah, but at least it writes in ~/.cache/*unity8*/, not in ~/.cache/ directly ;)"
[09:20] <tsdgeos> well the trello card said to write in .cache directly
[09:20] <tsdgeos> thus is what i did
[09:20] <Saviq> tsdgeos, I don't think the trello card went to such detail :)
[09:20] <Saviq> tsdgeos, so: show splash → fade screenshot in → drop splash → fade app in → drop screenshot
[09:20] <tsdgeos> oh it did
[09:21] <tsdgeos> "Screenshots should be stored on suspend, removed on user-close, in $cacheDir/app_shots/$app_id.png, and loaded from there by the Shell if app has not drawn to a surface yet."
[09:21] <tsdgeos> i guess you can argue that $cacheDir should be .cache/unity8
[09:21] <tsdgeos> tbh i don't care
[09:21] <tsdgeos> i'm just following wht other places of the code want
[09:21] <tsdgeos> if you want me to use QStandardDirs
[09:21] <tsdgeos> i'll do that
[09:22] <Saviq> tsdgeos, I just don't want to pollute ~/.cache/*
[09:44] <Saviq> greyback, https://code.launchpad.net/~unity-team/qtmir/add-qpa-version-depends/+merge/257866
[09:46] <greyback> looks reasonable, testing..
[10:38] <dandrader> Saviq, that's new. adding the ppa and doing dist upgrade always worked
 dandrader, sure, because dist-upgrade upgrades everything
[10:42] <Saviq>  dandrader, but if you `apt-get install unity8`, it will only upgrade unity8 and explicit deps
[10:43] <Saviq> dandrader, without those explicit deps we might end up in a situation where, say, ubuntu-keyboard gets released into distro, but unity8 is held back for whatever reason
[10:44] <Saviq> and people will dist-upgrade ubuntu-keyboard and find stuff broken
[10:47] <Saviq> dandrader, so we really need to remember to encode real dependencies between packages
[10:49] <dandrader> Saviq, and what dependency tree (or mesh) do you suggest?
[10:49] <Saviq> dandrader, depends on what reality is
[10:50] <Saviq> dandrader, if qtubuntu breaks unity8, it should say so, same for ubuntu-keyboard, if either unity8 or qtubuntu breaks it, it should have a Breaks
[10:50] <Saviq> or
[10:50] <Saviq> if ubuntu-keyboard depends on qtubuntu or unity8 at certain versions
[10:50] <Saviq> then u-k should have a Depends
[10:51] <dandrader> Saviq, so you wanna make ubuntu-keyboard depend on unity8?
[10:52] <Saviq> dandrader, no, but unity8 might Breaks: ubuntu-keyboard (<< foo)
[10:53] <dandrader> Saviq, unity8 will break the current dialer-app as it will be rotated to landscape and look horrible. should unity8 package also have Breaks: dialer-app << foo?
[10:54] <dandrader> Saviq, I'm not sure we should go down that road...
[10:54] <Saviq> dandrader, "look horrible" is ~fine
[10:55] <Saviq> dandrader, I'm talking about real breakage, like stuff won't boot / work
[10:55] <Saviq> dandrader, you can fix dialer by rotating to portrait, you can't fix a keyboard that doesn't launch
[10:56] <dandrader> Saviq, in that case I don't think there's a need to tie unity8 with ubuntu-keyboard
[10:56] <Saviq> dandrader, sure, I'm not saying there is, I'm just asking to consider it
[10:58] <Saviq> dandrader, basically what I'm saying is, consider what would be the impact of only intalling ubuntu-keyboard or only unity8, or only qtubuntu, or any two of those
[10:58] <Saviq> dandrader, and if in some case stuff gets really broken, we need to prevent it from happening
[11:00] <dandrader> Saviq, but how realistic are those scenarios?
[11:00] <Saviq> dandrader, quite
[11:00] <Saviq> dandrader, when publishing stuff from a silo, they land together in proposed
[11:00] <Saviq> dandrader, then, DEP-8 tests are run on them all
[11:00] <dandrader> Saviq, what's DEP-8?
[11:02] <Saviq> dandrader, autopkgtest
[11:02] <Saviq> dandrader, http://packaging.ubuntu.com/html/auto-pkg-test.html
[11:03] <Saviq> dandrader, if one of the DEP-8 tests fails for whatever reason, the rest of the packages will still migrate to the main archive
[11:03] <Saviq> dandrader, an image can be built in that situation and break people's phones
[11:04] <Saviq> dandrader, doesn't really matter what the reason might be for the migration to be delayed, it might even just be a test suite taking longer
[11:05] <Saviq> and appropriate dependencies are the only way to prevent that
[11:46] <tsdgeos> @unity: what do you guys think about https://code.launchpad.net/~aacid/unity8/add_override/+merge/257865 ?
[11:46] <sidi> hmkay so, my unity started playing up and crashing on start for no apparent reason (literally I just changed a static string I use for debug). I reverted my change, and it would then refuse to compile because of an alleged missing type in tests/gnome-session-manager.c (which I've obviously never touched). It would compile if I removed the tests/ subdir but immediately crash on launch. --advanced-debug showed various "graceful" shutdowns, sigaborts, si
[11:46] <sidi> gsegvs, usually when the GMainLoop starts or CompWindow code is touched. Then, I reverted *all* my code back to the original lp branch you guys maintain. I removed my ~/staging dir. I purged /usr/local just in case. I reinstalled compiz and unity from the package manager. I even grepped for "staging" in /usr/bin in case the unity script still refers to something long gone. It still crashes every time i try to log in. What can that be?
[12:05] <greyback> tsdgeos: a +1 from me. I didn't know clang could do that
[12:31] <tsdgeos> greyback: yeah it's great, it has some other stuff
[12:31] <tsdgeos> like turning the correct 0 to nullptr
[12:32] <tsdgeos> and some other stuff
[12:32] <greyback> nice
[12:32] <tsdgeos> but i find the override one to be most usefull really
[12:32] <tsdgeos> since 0 to nullptr is "mostly" "stylistic"
[12:32] <tsdgeos> and the override stuff is actually helping if stuff chnges
[12:39] <dandrader> Saviq, so qtubuntu/shellRotation is backwards compatible
[12:41] <Saviq> MacSlow, saw my comment on your shellRotation MP?
[12:41] <MacSlow> Saviq, have not looked at shellRotation today... but will do later today
[12:41] <Saviq> k
[12:43] <MacSlow> Saviq, hm... that's odd... this missing _ for get_unity_pid() I did fix... I'll sort it out before my EOD
[13:10] <Saviq> mzanetti, tsdgeos, I'm not sure https://code.launchpad.net/~aacid/unity8/fixruntests/+merge/257745 is right... it means that a failed test will result in FAILURE, not UNSTABLE as today
[13:11] <tsdgeos> Saviq: it does, yes
[13:11] <Saviq> and so the job won't even collect the test results
[13:11] <Saviq> so we basically lose a state, we're only left with SUCCESS and FAILURE
[13:12] <tsdgeos> that's right
[13:12] <tsdgeos> didn't realize we were losing test results
[13:13] <tsdgeos> Saviq: it's a bit ugly though, it will help us when things go bad like now where we were not running the dbus-launch tests
[13:13] <tsdgeos> and it was all green
[13:13] <tsdgeos> i'm open to another sugestion on how to fix that if you have one
[13:14] <tsdgeos> or i can try to be smarter and see if it's xvfb-run failing or make failing
[13:14] <tsdgeos> and then return an error or not
[13:15] <Saviq> tsdgeos, we need to speak with fginther on what's the right approach there
[13:15] <tsdgeos> not sure how fragile that is
[13:15] <Saviq> and what can jenkins do for us
[13:17] <Saviq> tsdgeos, so that's where the ~100 new tests come from?
[13:17] <tsdgeos> i guess
[13:18] <tsdgeos> we had a dbus-launch'ed tests that just didn't happen
[13:18] <tsdgeos> switched them to dbus-test-runner
[13:18] <Saviq> https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-vivid/test/
[13:18] <Saviq> tsdgeos, yeah, on that note, I just dropped it all in the qmltest refactor...
[13:18] <tsdgeos> dropped what?
[13:18] <Saviq> tsdgeos, well, refactored QmlTest.cmake
[13:19] <tsdgeos> k
[13:19] <tsdgeos> i'll have a look
[13:19] <Saviq> tsdgeos, so your change from dbus-launch to dbus-test-runner died (but I did make the dbus tests work)
[13:30] <tsdgeos> Saviq: ok
[13:41] <tsdgeos> Saviq: pushed QStandardPaths stuff
[13:42] <Saviq> tsdgeos, tx
[15:41] <tsdgeos> mterry_: is there a test we could add for https://code.launchpad.net/~unity-team/qmenumodel/nullify-state-variant/+merge/257902 ?
[15:49] <tsdgeos> larsu: can you quick review https://code.launchpad.net/~unity-team/qmenumodel/nullify-state-variant/+merge/257902 ?
[15:52] <larsu> tsdgeos: done. obivous. thanks.
[15:52] <larsu> *obvious
[15:57] <tsdgeos> larsu: thanks :)
[16:03] <tsdgeos> Saviq: if you have some extra 5 minutes, maybe try https://code.launchpad.net/~mterry/unity8/cancel-pam-harder/+merge/251174 ?
[16:09] <mterry_> tsdgeos, sorry, was afk
[16:09] <tsdgeos> mterry_: no worries, we've already top approved it :D
[16:10] <mterry_> tsdgeos, yeah ok  :)
[16:10] <tsdgeos> mterry_: now we need someone to launch it though
[16:10] <mterry_> tsdgeos, it was a simple fix, barely test worthy
[16:10] <tsdgeos> mterry_: don't know, sure the fix is obvious, but having a test exercising the function may still be worth in case it breaks somewhere else, but yeah
[16:10] <tsdgeos> don't worry
[16:11] <tsdgeos> just get someone to silo it :D
[16:11] <mterry_> tsdgeos, fair
[16:11] <mterry_> tsdgeos, the interaction was complicated, I didn't track down the exact repo steps that a test would need
[16:11] <mterry_> tsdgeos, eh, it will get rolled up in the next qmenumodel release, eh?
[16:11] <tsdgeos> understand
[16:11] <mterry_> or do other teams not do release days like unity8?
[16:12] <tsdgeos> mterry_: i don't think qmenumodel release will happen unless we make it happen D
[16:12] <tsdgeos> like last release is from 3 months ago
[16:12] <tsdgeos> http://bazaar.launchpad.net/~indicator-applet-developers/qmenumodel/trunk/changes/116?start_revid=116
[16:12] <tsdgeos> and it just had 1 change
[16:12] <mterry_> fair
[16:12] <tsdgeos> so i think we need to find someone to do it or do it ourselves
[16:36] <tsdgeos> greyback: dednick: https://bugs.launchpad.net/ubuntu/+source/qtmir/+bug/1450377 any idea?
[16:38] <dednick> tsdgeos: not off-hand. would need to look into it
[16:52] <Saviq> tsdgeos, hehe fun, I managed to suspend browser before it drawn, so I had an appshot of the splash screen ;)
[16:52] <tsdgeos> lol
[16:53] <Saviq> tsdgeos, only issue I can see is activity indicator moving up'n'down between splashscreen and screenshot, but I won't block on that
[16:53] <tsdgeos> yeah i didn't really love that either, hard to fix though tbh
[16:54] <tsdgeos> since the activity indicator of the splash can be in various places
[16:54] <tsdgeos> the other thing about the screenshot is weird
[16:54] <Saviq> well, we tell it where to be, so in theory we could tell it over splash screen too
[16:54] <tsdgeos> since  property bool needToTakeScreenshot: has  sessionContainer.surface && d.surfaceInitialized
[16:54] <Saviq> s/splash screen/screenshot/
[16:56] <Saviq> tsdgeos, hmm, could it be that surface was initialized but not drawn to?
[16:57] <tsdgeos> may be, not really deep on qtmir's knowledge at that level tbh
[16:57] <Saviq> greyback, ↑?
[16:58] <Saviq> tsdgeos, I think we'll later need to tweak it so that if splash screen is shown at all (well, it will always be shown, right?) it will be shown for at least 200ms or something
[16:59] <Saviq> tsdgeos, because now the splash screen shows but is covered by screenshot before it reaches the screen
[16:59] <Saviq> but again, not a blocker
[16:59] <tsdgeos> makes sense
[17:03]  * greyback back, was chatting
[17:05] <greyback> Saviq: tsdgeos: surface (i.e. the mirsurfaceitem) will only appear in qml when it has the first frame drawn
[17:05] <Saviq> wierd
[17:06] <greyback> but it may be that the first frame mir gives us is not the frame the app drew
[17:06] <greyback> that is a theory I have had for while now
[17:07] <greyback> so I think there's a delaying timer before we hide the screenshot/splashscreen
[20:58] <mhall119> Saviq: mzanetti: can one of you help answer http://askubuntu.com/questions/615917/unity8-development-install-troubleshooting/616561#616561