[10:10] <Mirv> greyback: hey! you asked for it, so I managed to get so far that I tried building qtmir and qtubuntu against Qt 5.4 beta. qtubuntu succeeded, qtmir bug #1394884
[10:11] <Mirv> I should be able to get UITK build tried soon I believe, which is a prerequisite for eg unity8, but I fully expect UITK to explode
[10:12] <greyback> Mirv: private api change, should be easy fix
[10:20] <Mirv> sounds good, easy fixes are the best fixes
[11:04] <facundobatista> holas
[11:07] <pstolowski> Saviq, tsdgeos hey, do you have a silo already for manage stuff landing? if so we'd like to add to that one (but we will land a bunch of other changes to scopes api and shell plugin with it)
[11:08] <tsdgeos> i think there was something
[11:08] <tsdgeos> not sure tbh
[11:08] <Saviq> I think it got cleared
[11:08] <Saviq> pstolowski, so no, right now we have nothing
[11:08] <pstolowski> Saviq, ok, i'll start a new row then
[11:42] <tsdgeos> mzanetti: lots of qmluitests failing in your wallpaper branch
[11:43] <mzanetti> uh. checking
[12:35] <Saviq> dandrader, hey, what's up with the touch crash?
[12:36] <greyback_> Mirv: https://code.launchpad.net/~gerboland/qtmir/fix-qt5.4/+merge/242485 - builds with my Qt5.4 chroot
[12:37] <dandrader> Saviq, working on that
[12:37] <Saviq> dandrader, ok, I think I'll wait for that with the silo, somehow it's triggering the issue
[12:37] <dandrader> Saviq, still trying to understand what's exactly happening. but I'm able to reproduce it
[12:38] <dandrader> Saviq, yeah, better wait until I have a fix indeed
[12:42] <karni> is there a known issue with video playback on mako that you guys are aware of?
[12:42] <karni> (there's audio, but no/black video)
[12:45] <Mirv> greyback_: \o/ excellent, I'll try pushing that and report back.
[12:48] <Saviq> karni, check with jhodapp, I dunno
[12:49] <karni> Saviq: will, thanks!
[13:09] <jhodapp> karni, that does still occasionally happen, still trying to figure out what causes that
[13:15] <karni> jhodapp|sick: oh.. I'm sorry to see that man. I hope you'll get better :/ ! let me just say on mako that problem persists for all video playback. I'll assign the bug to media-hub. Get better!
[14:14] <Saviq> Cimi, what's going on with lp:~aacid/unity8/photoscopeimprovements ?
[14:39] <kdub> alf, mterry is the reason why u-s-c uses Qprocess to launch spinner because that was the most convenient launching code to use?
[14:40] <kdub> I guess I'm trying to figure out if its worth it to have some mir process-launching-managing functionality
[14:42] <mterry> kdub, yeah I believe it was just convenience
[14:42] <mterry> kdub, we didn't need much fanciness
[14:42] <kdub> mterry, right
[14:43] <kdub> I'm poking around what it would take to get rid of usc's qt dependency
[14:43] <kdub> and there's that launching, and the dbus stuff
[14:48] <mzanetti> dandrader: ping
[14:48] <dandrader> mzanetti, pong
[14:48] <mzanetti> dandrader: I have a failing tests here: test_tapUbuntuIconInLauncherOverAppSpread and I don't really understand why you're doing a touchFlick on the button instead of a click
[14:48] <tsdgeos> larsu: https://code.launchpad.net/~larsu/unity8/stop-using-statusicon/+merge/234502
[14:48]  * tsdgeos hides
[14:49] <dandrader> mzanetti, to simulate the user finger
[14:49] <dandrader> mzanetti, the touch point of moves slightly under the user's finger even for a simple tap
[14:50] <dandrader> mzanetti, it's almost never perfectly still
[14:50] <mzanetti> dandrader: weird thing that it fails if you change in LauncherPanel.qml the inverted from true to false
[14:50] <mzanetti> reading the code it would seem it should still work
[14:51] <larsu> tsdgeos: I knew I forgot something :)
[14:51] <mzanetti> dandrader: are you testing the kraken code with this or why do you do a drag here?
[14:51] <dandrader> mzanetti, didn't get your question
[14:52] <mzanetti> dandrader: I agree that a user tap is mostly not like a perfect mouse click. but why put this code into a random test?
[14:53] <mzanetti> or is it here intentional because you're trying to tap on the left edge drag area and want to make sure the edge recognition stuff works?
[14:53] <dandrader> mzanetti, a regression test for a bug in which the movement of the touch point  played an important role
[14:53] <larsu> tsdgeos: building/testing now to make sure, sorry
[14:54] <mzanetti> dandrader: do you remember which bug? so I can make sure to keep that behavior when fixing the test
[14:54] <mzanetti> or rather adjusting
[14:54] <dandrader> mzanetti, "bzr qblame" it
[14:54] <dandrader> mzanetti, are you thinking about dumbing down that test?
[14:54] <mzanetti> no. need to adjust it because it fails
[14:55] <mzanetti> in one of my branches
[14:56] <mzanetti> ok, yeah, it is for testing the kraken...
[14:58] <mzanetti> ack. got it... thanks.
[15:15] <dandrader> Saviq, the touch crash bug is looking scary. it seems as if the processing of a given touch event is interrupted midway to the processing of further ones and then resumed again. as if touch events were coming from more than one thread or something....
[15:15] <dandrader> I hope I'm wrong
[15:21] <Saviq> ouch
[15:48] <mzanetti> Saviq: is this a real crash? or "just" lost input?
[15:48] <mzanetti> I had that today again :/ left/right edge stopped working
[15:48] <mzanetti> obviously when I was out for shopping
[15:48] <Saviq> mzanetti, no, actual crash
[15:48] <Saviq> well, ABRT
[16:40] <kgunn> robotfuel: with all the recent stability improvements do you see this ?
[16:41] <kgunn> https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1365673
[16:42] <robotfuel> kgunn: I haven't been running the lrt suite nuclearbob is doing that now
[18:34] <dandrader> Saviq, still around?
[18:35] <dandrader> mterry, where do I find -dbg packages?
[18:35] <dandrader> mterry, for mir and libubuntu-app-launch2, for instance
[18:35] <mterry> dandrader, some packages build them automatically and they just exist in the archive
[18:36] <mterry> dandrader, but if you want debug symbols for something that doesn't generate it's own -dbg package...
[18:36] <dandrader> mterry, most of the packages unity8 link against have no -dbg counterpart
[18:36] <dandrader> mterry, apart from qt
[18:36] <mterry> dandrader, https://wiki.ubuntu.com/DebuggingProgramCrash#Debug_Symbol_Packages
[18:36] <mterry> dandrader, that talks about using ddebs.ubuntu.com
[18:37] <mterry> dandrader, which offers -dbgsym packages for everything
[18:37] <dandrader> great
[18:38] <mterry> dandrader, or you just rebuild without stripping symbols :-/
[18:39]  * dandrader not feeling like building everything unity8 links against :)
[19:03] <Saviq> dandrader, am now
[19:03] <Saviq> dandrader, in general http://ddebs.ubuntu.com/ is your starting point for -dbgsym packages
[19:03] <Saviq> dandrader, there are even tarballs from packages built in PPAs
[19:03] <Saviq> in http://ddebs.ubuntu.com/queue/
[19:04] <Saviq> and the same for rtm http://ddebs.ubuntu.com/ubuntu-rtm/
[19:06] <dandrader> Saviq, so, the problem with the touch crash is that events are being processed recursively
[19:08] <dandrader> Saviq, it seems ubuntu-app-launch is spinning the glib main loop that is shared with Qt
[19:11] <dandrader> tedg, ping
[19:28] <Saviq> dandrader, huh!
[19:29] <dandrader> Saviq, it's a sizeable call stack http://paste.ubuntu.com/9154149/
[19:29] <Saviq> dandrader, tedg just filed a branch doing something similar
[19:29] <Saviq> dandrader, https://code.launchpad.net/~ted/ubuntu-app-launch/cgmanager-custom-context/+merge/242378
[19:29] <Saviq> s/doing/related to/
[19:30] <Saviq> dandrader, interesting...
[19:30] <dandrader> Saviq, but maybe TouchRegistry should post events instead of sending them. that might be enought to solve the bug in question
[19:30] <Saviq> dandrader, IIUC it should be possible to share the glib main loop, so this sounds like it should be possible
[19:31] <dandrader> ie., avoiding recursive calls of TouchRegistry::update as it's not reentrant
[19:32] <dandrader> Saviq, from the call stack it definitely looks like ubuntu-app-launch is using the same glib main loop as Qt
[19:32] <Saviq> dandrader, yeah, and I think that should be a valid usecase (sharing the main loop)
[19:33] <Saviq> dandrader, but obviously we need to make sure the above doesn't happen
[19:33] <dandrader> Saviq, not sure whether Qt's input event handling is reentrant
[19:34] <dandrader> Saviq, because maybe that scenario could also happen without TouchRegistry in the picture....
[19:35] <dandrader> 26	- .loop = g_main_loop_new(NULL, FALSE),
[19:35] <dandrader> 27	+ .loop = g_main_loop_new(context, FALSE),
[19:36] <dandrader> Saviq, from the MP you posted. So that looks like it would also avoid the crash we're getting
[19:36] <Saviq> dandrader, yup, that's what I was thinking
[20:00] <dandrader> :qa
[20:05]  * tedg back
[20:05] <tedg> dandrader, So yes, it did, which seemed to cause some issues with flicker as well.
[20:05] <tedg> I changed it to have it's own context, which might solve some other issues as well.
[20:06] <tedg> Really it'd be nice if all the calls could be async, but that's not a "rtm thing"
[20:06] <dandrader> tedg, as long as it doens't spin glib's default main loop (which is what Qt uses) it should be fine
[20:07] <tedg> dandrader, Yeah, it was, the branch Saviq linked to changes that.
[20:10] <mzanetti> tedg: ah, great to know that flicker thing is solved too :)  thanks
[20:15] <tedg> I'm actually still surprised that people notice that much. I really do never use short swipe.
[20:15] <tedg> Never found it that useful, honestly.
[20:19] <Saviq> tedg, probably depends how many apps you leave open, I generally close them all, so swiping between app and dash is something I do a lot
[20:19] <Saviq> tedg, if you leave a lot running, the short swipe not really that useful indeed ;)
[20:20] <tedg> Saviq, Why do you close apps?
[20:20]  * tedg is waiting for the "to use short swipe"
[20:20] <tedg> :-)
[20:44] <Saviq> tedg, OCD, what else
[20:45] <tedg> Perhaps social issues with killing.  Anyone know where that lives?
[23:32] <cwayne1> josharenson: i'd guess notify-osd
[23:32] <cwayne1> but not sure
[23:33] <josharenson> cwayne1, thanks.