[09:09] <tsdgeos> ah funny
[09:10] <tsdgeos> the qmluitests in tableStage pass here
[09:29] <tsdgeos> meh the autopkg tests branch has degraded into tests not passing again
[09:31] <tsdgeos> at least one i know what it is
[09:31] <ltinkl> tsdgeos, https://code.launchpad.net/~lukas-kde/unity8/globalshortcuts/+merge/269608 merged and conflicts resolved
[09:32] <tsdgeos> ltinkl: ok, i'll let daniel continue the review
[09:32] <ltinkl> tsdgeos, it had been approved already
[09:32] <tsdgeos> ah right
[09:33] <ltinkl> tsdgeos, by mzanetti too
[09:35] <ltinkl> tsdgeos, thx
[10:09] <tsdgeos> wops, testNotifications broke
[10:09]  * tsdgeos fixes
[10:25] <tsdgeos> Saviq: was speaking with someone yesterday that had exactly the same issue with the cropped images as we do
[10:26] <tsdgeos> maybe after a bit of testing we can propose the CroppedImageMinimumSourceSize up to the SDK?
[10:26] <Saviq> tsdgeos, I'd rather we propose a change to the Qt APIs
[10:26] <tsdgeos> Saviq: what would you propose?
[10:26] <Saviq> tsdgeos, not sure yet, sourceSize: minimumSize(200, 300) or something of the sort
[10:26] <Saviq> Qt.minimumSize I mean
[10:27] <Saviq> would be backwards compatible
[10:28] <tsdgeos> i guess it might work
[10:43] <kgunn> pstolowski: hey there, i'm trying to untangle a mess
[10:43] <kgunn> so i understand lp:unity-api and lp:unity-api/trunk-15.04 are different
[10:43] <kgunn> was hoping to just merge trunk15.04 differences into lp:unity-api
[10:44] <kgunn> but heard  you might not think that's kosher
[10:44] <kgunn> is there any reason these are being maintained seperately ?
[11:04] <tsdgeos> :/ qmltestrunner::ShellWithPin::test_longLeftEdgeDrags is unstable
[11:41] <pstolowski> kgunn, hey,
[11:44] <pstolowski> kgunn, that happened during gcc5.0 mayhem. tbh i'm not sure anymore why i branched off unity-api since it doesn't have symbols, we could use a single tree (but we can't have single tree for e.g. shell plugin)
[11:45] <pstolowski> kgunn, having said that, both trunks are equal feature-wise, may have different revisions and commits as i cherry-picked
[11:49] <pstolowski> kgunn, ah, afair it had to do with needing to land stuff for ota6 while dual landing was not possible due to gcc5
[12:23] <Saviq> pstolowski, so we could reconcile now? why is it not possible to have a single tree for the shell plugin? can't do some #ifdefs?
[12:24] <Saviq> pstolowski, they're built separately for wily and v+o after all?
[12:24] <Saviq> or is it about the .symbols file differing between the two?
[12:24] <pstolowski> Saviq, due to symbols
[12:25] <Saviq> that feels dumb, but I feel the pain
[12:26] <Saviq> pstolowski, even if separate branches, landing can be done in sync, right? so it's not like there's actual code differences
[12:26] <pstolowski> Saviq, we can probably try to merge unity-api trunks back (i'm not sure if it poses any problems wrt citrain, but they are probably easy to work out)
[12:26] <Saviq> I mean that the fact that you need two branches there doesn't mean any dependants need to have two
[12:27] <Saviq> pstolowski, that'd be ideal, I'll compile a list of tasks for this to happen
[12:27] <Saviq> thanks
[12:27] <pstolowski> Saviq, correct - but you need to have separate MPs for unity-api, meaning you cannot just dual land
[12:28] <pstolowski> Saviq, okay. for shell plugin it's not easily doable though
[12:28] <pstolowski> Saviq, we have similar problem in unity-scopes-api (symbols)
[12:28] <Saviq> pstolowski, as long as the two (wily and v+o) changes land in sync, we're fine
[12:28] <pstolowski> Saviq, michi has been working on a single-tree beanch for unity-scopes-api, it's huge effort
[12:28] <Saviq> pstolowski, it's only a problem when one lags behind the other
[12:29] <pstolowski> Saviq, yeah. we just need two MPs as before with rtm
[12:29] <pstolowski> feature-wise all trunks should be the same
[12:33] <pstolowski> alecu, ho?
[12:48] <tsdgeos> anyone feels like reviewing https://code.launchpad.net/~aacid/unity8/autopilot_test_search_workaround/+merge/269769 ?
[12:48] <tsdgeos> mterry: https://code.launchpad.net/~aacid/unity8/fixTestNotifications/+merge/269876
[12:49] <mterry> tsdgeos, whoops, will review that  :)
[12:50] <mzanetti> mterry, good morning
[12:50] <mterry> mzanetti, hello!
[12:50] <mzanetti> mterry, when you get a chance, please merge your reboot branch
[12:50] <mterry> mzanetti, will do
[12:50] <mzanetti> ta
[12:59] <kgunn> Saviq if i followed your convo with pstolowski correctly , i think this just needs to be landed in wily first
[12:59] <kgunn> https://code.launchpad.net/~unity-team/unity-api/fwdport-mirsurfaceitem/+merge/269881
[12:59] <kgunn> then...src sync that to vivid+o
[12:59] <kgunn> well...plus qtmir trunk into wily with that unity-api mp ^
[12:59] <kgunn> i'll leave it with you...
[13:00] <Saviq> kgunn, something like that, I need to see the what the actual direction (wily to v+o or the other way round) will be, but in truth we just need the next landing to be dual-targeted and then push to trunks and drop the additional branches
[13:00] <tsdgeos> greyback: any idea of what may be causing the failures in https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-vivid/939/consoleFull ?
[13:01] <tsdgeos> greyback: the tabletStage ones
[13:01] <greyback> Saviq: fyi seems tags have infected qtmir somehow
[13:01] <tsdgeos> greyback: search for "fail!"
[13:01] <Saviq> greyback, yeah, mzanetti told me
[13:01] <mzanetti> still not sure how tho :D
[13:01] <Saviq> yikes
[13:01] <Saviq> "reached maximum number of OpenGL contexts supported by UbuntuShape"
[13:01] <greyback> tsdgeos: "fail!" ?
[13:02] <tsdgeos> greyback: without the quotes
[13:02] <Saviq> and that in DDA test??
[13:02] <tsdgeos> Saviq: SDK
[13:02] <mzanetti> lol
[13:02] <tsdgeos> Saviq: it's already fixed they just need to land it
[13:02] <greyback> tsdgeos: yeah, firefox not seeing it. Ah matching case, sorry
[13:02] <Saviq> ah so that's not the fail you're looking for
[13:02]  * greyback waves hand
[13:02] <tsdgeos> Saviq: no since that's not on the phablet stage ;)
[13:03] <tsdgeos> Saviq: this is the one for the DDA one https://code.launchpad.net/~aacid/ubuntu-ui-toolkit/betterConnectForAboutToBeDestroyed/+merge/268454
[13:03] <Saviq> ktxbai
[13:04] <greyback> tsdgeos: we had this same problem like 2 weeks ago, no?
[13:04] <tsdgeos> greyback: did we?
[13:04] <greyback> yeah. UbuntuShape doing something funky
[13:04] <greyback> I thought there was a fix somewhere, looking
[13:04] <tsdgeos> greyback: yes yes, i'm not speaking about the ubuntushape
[13:04] <Saviq> greyback, look for further fail!
[13:04] <greyback> ah sorry
[13:04] <tsdgeos> greyback: i'm speaking about the tabletstage fails
[13:05] <tsdgeos> greyback: which obviously i can't reproduce here
[13:07] <greyback> tsdgeos: hmm  the test makes sense too
[13:08] <greyback> something racey maybe
[13:08] <greyback> tho this is all single thread I think
[13:11] <greyback> tsdgeos: only thing I can suspect is switchToApp - it looks quite solid tho
[13:11] <tsdgeos> yeah :/
[13:11] <tsdgeos> and is used in other places too i think
[13:11] <greyback> dandrader: good morning, there is a multimonitor update for you
[13:12] <greyback> tsdgeos: I see it used in 2 tests, both are the ones which fail
[13:12] <tsdgeos> ah
[13:12] <tsdgeos> right
[13:12] <tsdgeos> ^_^
[13:12] <tsdgeos> maybe it's that then
[13:12] <dandrader> greyback, ok
[13:13] <greyback> just a guess tho, it runs fine here annoyingly
[13:13] <tsdgeos> i'll try to investigate from there
[13:13] <greyback> would be lovely to get videos of test fails
[13:13] <greyback> ilke AP does
[13:15] <Saviq> greyback, I've a thing doing that in my pipeline
[13:15] <Saviq> as in mostly implemented
[13:16] <greyback> Saviq: glad to hear it. Would be extra super nice if it visualize the cursor/gestures
[13:16] <Saviq> greyback, I'm just using recordmydesktop, should be possible to replace that with something smarter, if that doesn't do it
[13:17] <Saviq> greyback, ah but for QML tests we'd need something in the qmlscene doing that
[13:17] <Saviq> since there's no real input
[13:17] <Saviq> next step
[13:17] <greyback> yeah
[13:18] <greyback> a custom qmlscene might be needed
[13:18] <greyback> anyhoo, video will help muchos
[13:18] <mterry> tsdgeos, you might have some insight on bug 1489076?
[13:19] <tsdgeos> mterry: hmmm think you want dandrader for that?
[13:19] <tsdgeos> i haven't really done much DDA nor windowed work
[13:19] <mterry> tsdgeos, yup, I think I mentally swapped you two  :P
[13:20] <tsdgeos> ok :D
[13:20] <mterry> tsdgeos, which is weird because dandrader even has "DandD" in his name
[13:20] <mterry> dandrader, anyway ^
[13:21] <dandrader> :)
[13:22] <Saviq> mterry, dandrader, shouldn't we just have a MouseArea there for onClicked? DDA doesn't care about mouse events anyway?
[13:22] <dandrader> mterry, I would have to investigate the bug to be able to provide any decent insight
[13:22] <dandrader> Saviq, define "there"
[13:23] <Saviq> dandrader, wherever the DDA is, really
[13:23] <Saviq> wherever we want the click to act ;)
[13:23] <mterry> Saviq, does it pass them through?  that might work then, to extend the MouseArea from the left of the panel to all along the panel, underneath the indicators
[13:23] <dandrader> the indicators bar already has a MouseArea
[13:23] <mterry> dandrader, yeah but it doesn't extend underneath the indicators, as I recall
[13:24] <dandrader> which is why you're able show the indicators panel by simply clicking on the bar
[13:24] <dandrader> mterry, there might be a MouseArea "input eater" over there, I don't lnow
[13:24] <dandrader> know
[13:25] <mterry> dandrader, the indicators panel shows with a click?  ok, good...  Then *something* is eating the mouse event / my quick investigation was wrong
[13:25] <Saviq> mterry, in any case, DDA shouldn't be involved with mouse events
[13:26] <Saviq> there's obviously the problem of mouse events being converted to touch, and vice versa...
[13:26] <mterry> Saviq, (why not?  it conceptually makes sense that it could handle a mouse drag -- just work we haven't done or is it something we think shouldn't be done?)
[13:26] <Saviq> but as long as you accept the event, it shouldn't happen
[13:26] <dandrader> mterry, what do you mean by "indicators panel"? it that this narrow bar at the top of the thing you get when you expand it
[13:26] <Saviq> mterry, mouse gestures need to be different than touch
[13:26] <dandrader> mterry, dednick added a MouseArea in the indicator bar a while ago to handle this call thingy I think
[13:27] <mterry> dandrader, I specifically meant the IndicatorsMenu object
[13:27] <mterry> dandrader, yeah, but it only is on left of IndicatorsMenu
[13:27]  * dandrader not very familiar with the indicator components terminology
[13:27] <mterry> Saviq, yeah but it would be nice if we had a class that abstracted that for us
[13:28] <mterry> and without looking at it's API, DDA strikes me as a possible fit for that
[13:28] <mterry> dandrader, then I meant "the row of icons"
[13:29] <tsdgeos> mterry: https://code.launchpad.net/~aacid/unity8/fixTestNotifications/+merge/269876/comments/679272 up to you, do i do it?
[13:29] <Saviq> mterry, sure, but it wouldn't be DDA but something above it, including a MouseArea, likely ;)
[13:29]  * Saviq away otp
[13:30] <mterry> tsdgeos, I think it's a cleaner branch if we do it.  But I feel bad asking you to do it, since it's my mistake in the first place.  I can propose a merge into your MP today
[13:30] <tsdgeos> mterry: no no, i'll do it
[13:30] <tsdgeos> don't worry
[13:31] <tsdgeos> i'm on test failure hunting today
[13:31] <tsdgeos> mzanetti: can you do https://code.launchpad.net/~aacid/unity8/stabilize_shellwithpin_test/+merge/269913 ?
[13:32] <mzanetti> tsdgeos, sure
[13:46] <tsdgeos> mterry: setStatus pushed
[13:47] <mterry> k
[13:48] <mterry> tsdgeos, that was a few calls indeed  :)
[13:51] <mzanetti> tsdgeos, this seems to have the ability to mess up with the state machine... doesn't it?
[13:52] <tsdgeos> mzanetti: not really i mean the problem is that for some reason we're using a timer to set the state
[13:52] <tsdgeos> so if you do
[13:52] <tsdgeos> starttimer that changes state, change state
[13:52] <tsdgeos> you really need to stop the timer first
[13:52] <tsdgeos> otherwise you may not get the state you wanted
[13:52] <mzanetti> yes, but we don't do "change state"
[13:52] <mzanetti> do we?
[13:53] <tsdgeos> mzanetti: if you we do, i can move that down on the animation code if you prefer
[13:53] <mzanetti> let me understand it better...
[13:53] <mzanetti> tsdgeos, we do... you're right
[13:54] <mzanetti> ok... seems fine then
[13:54] <tsdgeos> maybe it makes more sense to stop the timer just before the
[13:54] <tsdgeos> root.state = "";
[13:54] <tsdgeos> ?
[13:54] <tsdgeos> on the ScriptAction { ?
[13:54] <tsdgeos> i don't mind either
[13:54] <mzanetti> probably... so we don't run into this again
[13:54] <tsdgeos> k, will move it down there
[13:54] <mzanetti> if someone else starts the fadeOut() , which admittedly is unlikely
[13:55] <tsdgeos> i don't even think you can reproduce this in the real world
[13:55] <mzanetti> probably
[14:18] <tsdgeos> mzanetti: moved down
[14:19] <mzanetti> tsdgeos, ta
[14:27] <kgunn> greyback: mzanetti how do twins currently work ? it's been a while...do i have to manually update watch file still ?
[14:27] <kgunn> or just have an mp for -gles and build it in the silo ?
[14:28] <mzanetti> kgunn, yeah, no change
[14:28] <greyback> kgunn: yep
[14:28] <mzanetti> kgunn, debian/watch for the silo number and debian/changelog for the version
[14:28] <kgunn> mzanetti: ack no change except those, got it
[14:28] <greyback> and keep eye out for new dependencies
[14:29] <kgunn> greyback: so compare the control files ? between the twins
[14:29]  * kgunn always wants to think parent-child vs twins
[14:29] <greyback> kgunn: yeah, just in case the 'parent' has something added
[14:30] <mzanetti> if the branch you're releasing changes the control, copy the changes over
[14:30] <kgunn> easy nuff
[14:30] <mzanetti> @unity: standup
[14:30] <kgunn> mzanetti: i'll miss
[14:30] <kgunn> todays
[14:48] <Saviq> @unity, kgunn, pstolowski: here's what I believe we should do to resync trunks between wily and vivid, anything I'm missing? http://pastebin.ubuntu.com/12253846/
[14:48] <Saviq> kgunn, vivid has mir 0.14.1, wily has 0.15.1, what's the plan there?
[14:51] <pstolowski> Saviq, looks good overall, but i think citrain will reject the first step (land a src rebuild of lp:unity-api/trunk-15.04 to wily) without some changelog hackery?
[14:52] <Saviq> pstolowski, I think it shouldn't, the version is higher than what's there in wily
[14:53] <Saviq> pstolowski, ultimately we can skip the train altogether and just upload the package to proposed directly
[14:53] <pstolowski> Saviq, the ...+15.04 part of version string will confuse it
[14:54] <Saviq> pstolowski, don't think it looks that closely, we were dual-landing to rtm and distro before
[14:54] <Saviq> without the -rtm suffix
[14:54] <Saviq> and it was fine
[14:55] <pstolowski> Saviq, ok, we will see :), i fought with something like that not long ago
[14:55] <pstolowski> Saviq, i guess we just need to try
[14:56] <mzanetti> Saviq, looks good to me
[14:56] <Saviq> pstolowski, yup
[14:57] <Saviq> back in ~2.5h
[14:58] <tsdgeos> Saviq: overlay has 0.15 too, no?
[14:58] <tsdgeos> Saviq: ah no, ignore me
[15:40] <mzanetti> greyback, kgunn: what's the ETA for silo0 things to land? I cannot reproduce bug 1488828 but I don't have slimport support and silo0 is out of date
[15:42] <greyback> mzanetti: silo0 more a demo silo than full of actually landable things
[15:42] <greyback> mzanetti: we're taking things a piece at a time
[15:42] <mzanetti> greyback, sure. I'm particularly interested in the slimport support
[15:43] <greyback> mzanetti: well that's probably a bit of https://code.launchpad.net/~gerboland/qtmir/multimonitor/+merge/269906
[15:43] <mzanetti> ah ok
[15:44] <greyback> but there's also some magic in silo0 to automatically use desktop mode if >1 screens available
[15:44] <greyback> which you'll not have
[15:44] <greyback> maybe convert to desktop mode by attaching BT mouse & keyboard, then emulate the call?
[15:46] <dednick> dandrader, mterry: I've commented on 1489076, but need a UX decision.
[15:48] <mzanetti> greyback, that's fine... I can do that
[15:48] <mzanetti> greyback, I've done incoming calls in desktop mode very often lately and didn't have a crash
[15:48] <mzanetti> so the only thing that's different here is the missing slimport
[15:48] <greyback> mzanetti: then it must be silo0 specific
[15:49] <mzanetti> let me try to do the exact same phonesim steps first (I usually use a real phone call)
[15:49] <tsdgeos> mterry: in exchange for fixing the notification thing can you review https://code.launchpad.net/~aacid/unity8/autopilot_test_search_workaround/+merge/269769 ? ;)
[15:49] <mterry> tsdgeos, :)  sure
[15:50] <tsdgeos> cool
[15:58] <tsdgeos> meh all the qmluitests jobs are stuck
[15:58] <tsdgeos> http://s-jenkins.ubuntu-ci:8080/job/unity-phablet-qmluitests-vivid/ :/
[15:59] <tsdgeos> mzanetti: anyone we can ping? ↑
[15:59] <mzanetti> tsdgeos, cihelp in #ubuntu-ci-eng
[16:00] <tsdgeos> k, need to do paperwork
[16:00]  * tsdgeos runs
[16:38] <syeh> Hi, newbie Unity question, how do I check out the code for 14.04?  I think the version I want is 7.2.5+14.04.20150603-0ubuntu1
[16:39] <syeh> I've done a "bzr branch lp:unity" and got a version of source
[16:40] <syeh> But for some reason that version won't start after I've make and "make install"
[16:48] <dednick> syeh: if you want the source for the version which you are currently running, "apt-get source unity"
[16:49] <syeh> dednick:  I am trying to fix a defect, and so I need to get the tree, test it, then push it
[16:51] <dednick> syeh: "bzr branch lp:unity/7.2"
[16:52] <dednick> syeh: https://code.launchpad.net/~unity-team/unity/trusty
[16:52] <syeh> dednick:  Thanks!   Trying that now.
[18:35] <syeh> ChrisTownsend:  in unityshell.cpp, is UNITY_LOW_GFX_MODE supposed to be an override in the case that it is set to "0"
[18:37] <ChrisTownsend> syeh: Right, so if you set UNITY_LOW_GFX_MODE=1 before starting unity, then unity will be started in low graphics mode.
[18:37] <syeh> what if I set it to 0, can I force it to not be in low gfx mode?
[18:37] <syeh> The current code won't allow that, but I'm wondering if that's the intention
[18:40] <ChrisTownsend> syeh: Oh, I see.  If it's being forced into low graphics mode without UNITY_LOW_GFX_MODE being set, it's due to your hardware configuration.  Setting UNITY_LOW_GFX_MODE=0 will not force non-low graphics mode.
[18:41] <syeh> Right, so would it be okay if I make it so that a user can force it to *not* go into low gfx mode?
[18:41] <syeh> A couple of drivers are now reporting "LLVM" in their renderer string.
[18:42] <syeh> I'm working on a Unity patch to fix that, and maybe providing a way to override the behavior if necessary
[18:43] <ChrisTownsend> syeh: Hmm, are they really LLVM drivers or is it a case they just happen to use that string and Unity is not accounting for that?
[18:43] <ChrisTownsend> syeh: I just want to make sure 3d is not enabled for real LLVM drivers and the user experience will be terrible.
[18:45] <syeh> Gallium drivers have a fall back path for certain draw operations (if they need it)
[18:46] <syeh> and the Gallium Draw module can use LLVM if it is available
[18:46] <syeh> it is different from the llvmpipe driver, which is a SW driver
[18:47] <syeh> So I think Unity should check for "llvmpipe" not "LLVM"
[18:48] <ChrisTownsend> syeh: Sure, that makes sense.
[18:48] <syeh> ok.  What about the override path for UNITY_LOW_GFX_MODE = 0?
[18:49] <syeh> Does that make sense or should I leave it the way it currently is?
[18:56] <ChrisTownsend> syeh: I think you should do one merge proposal for the LLVM vs. llvmpipe change.  Then you could do a second one for the override and see if it be accepted.  I no longer work on Unity, so others will have to decide if it should be taken or not.  You may want to discuss that will Trevinho when he's available.
[18:57] <syeh> ok.  Will do.  Thanks.
[19:09] <kgunn> Saviq hey so i'm not getting my way on working around that little unity-api/qtmir
[19:10] <kgunn> any eta on when i might be able to dual land a qtmir again ?
[19:21] <Trevinho> syeh: I'm currently travelling in China so I'll be more reachable next week. If you have a MP ready would be nice.
[19:22] <syeh> Trevinho:  I can't get through the firewall to push my branch, so I've attached it here:
[19:22] <syeh> https://bugs.launchpad.net/unity/+bug/1491555
[19:36] <Saviq> kgunn, I want to prepare a silo with what I wrote in the pastebin tomorrow
[19:37] <Saviq> kgunn, but that might very well be a dual-landing of qtmir, too
[19:41] <Saviq> or well, *will* be, we can add commits to it if you want
[20:19] <kgunn> SAviq i think so...just need to stay in sync with bregma and camako, but yeah, it prolly makes sense to use this
[20:19] <kgunn> https://code.launchpad.net/~mir-team/mir/released-rebuild-for-vivid-overlay/+merge/269918
[20:20] <kgunn> and then there's one for usc
[20:21] <kgunn> or one would need to be made rather....
[20:23] <kgunn> bregma: ^ this is the unity-api sorting, since it's all just no change rebuilds for mir/usc/qtmir this could be done in one shot
[20:24] <bregma> assuming unity-api is fixed properly
[20:30] <kgunn> bregma: precisely the point of Saviq's landing...."it just might work"tm
[20:32] <bregma> we'll get it straightened out while you're gone