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