[03:35] hi there [03:36] Does anyone also have the issue https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch/+bug/1397801 ? [03:36] Launchpad bug 1397801 in goget-ubuntu-touch (Ubuntu) "Emulator shows black screen after booting up" [Undecided,Confirmed] [08:22] ypwong, we've seen this issue when people did not have virtualization enabled - bug #1396919 [08:22] bug 1396919 in unity8 (Ubuntu) "unity8 display blank in emulator when virtualization disabled" [Medium,Confirmed] https://launchpad.net/bugs/1396919 [08:23] Saviq, we confirmed that the machine already has virtualization enabled in bios [08:25] ypwong, ah, this would be bug #1394208 then [08:25] bug 1394208 in qtmir (Ubuntu) "Unity8 unable to find the dash, which is also running in the background" [High,Triaged] https://launchpad.net/bugs/1394208 [08:27] CI is back \o/ [08:27] or is it? [08:27] tsdgeos, partly [08:28] this is weird [08:28] https://code.launchpad.net/~aacid/unity8/autopilot_drag_more/+merge/243367/comments/602515 [08:29] Saviq, looks like it is the same issue. Is there an ETA for a fix? [08:29] failed, but everything inside is success? [08:29] tsdgeos, there's None in two jobs [08:29] tsdgeos, that's a fail [08:30] ypwong, not atm [08:30] Saviq: what about https://code.launchpad.net/~mzanetti/unity8/fix-left-edge-on-spread/+merge/243400/comments/602513 then? [08:30] tsdgeos, Waiting for the completion of unity-phablet-qmluitests-vivid [08:31] ERROR: unity-phablet-qmluitests-vivid aborted. [08:34] Saviq: hey, just saw your update on the bug I filed earlier(1401361), quick query is there a quick way to close the browser perhaps using initctl etc. ? [08:35] veebers, autopilot should talk to UAL to find the running apps and stop them all [08:35] veebers, there are GI bindings for it [08:36] veebers, other than that there's command line utils "ubuntu-app-*" [08:36] Saviq: right, I'm pretty sure it already closes (or kills as a last resort) any apps it launches from within a test, this test I'm writing at the moment actually taps it open from the scope [08:37] Saviq: sweet, thanks. that gives me a start now :-) [08:39] veebers, I'll mark the bug invalid then, ok? [08:39] Saviq: sure, I'll let you know if I still hit the issue. Thanks again for the insight [09:44] greyback: so yeah, there's never a frame_posted happening when the splash screen stays there forever [09:44] greyback: what should trigger a frame_posted that i can put a debug in? === dandrader is now known as dandrader|afk [10:00] tsdgeos: when the application swaps a frame, frame_posted is called for shell. Has the app swapped? QSG_RENDER_TIMING=1 will print after a swap [10:01] void UbuntuOpenGLContext::swapBuffers(QPlatformSurface* surface) [10:01] looks like a good place to put a debug [10:01] yep [10:01] that's the client side, right? [10:01] yep, in qtubuntu === dandrader|afk is now known as dandrader [10:22] greyback: so buffers swap happens [10:22] what never happens is a handleSurfaceResize [10:23] which makes it bad it seems [10:23] now i need to find out who is supposed to call that handleSurfaceResize :D [10:23] tsdgeos: is frame_posted called in shell? [10:23] greyback: no [10:25] tsdgeos: if frame_posted not called in qtmir, qtmir hasn't added it to the qml scene yet. Only when its added to QML scene is it resized to suit [10:29] what sort of client are you testing? Can I have a try? [10:32] greyback: you mean unity8 ? :D [10:32] unity8-dash [10:32] sure you can have a try [10:32] remove all scopes [10:33] greyback_: got my answers? [10:35] tsdgeos: no, please repeat them [10:35] [11:29:44] what sort of client are you testing? Can I have a try? [10:35] [11:32:00] greyback: you mean unity8 ? :D [10:35] [11:32:03] unity8-dash [10:35] [11:32:24] sure you can have a try [10:35] [11:32:29] remove all scopes [10:37] tsdgeos: stupid question but: how do I remove all scopes? [10:37] their packages? [10:37] greyback_: you open the dash manager and unfavorite them all [10:37] bottom swipe [10:38] vivid [10:38] ah vivid [10:38] greyback_, on rtm you can force a gsetting [10:39] greyback_: who/what is calling setWidth on the MirSurfaceItems? [10:41] tsdgeos: qml is. MirSurfaceItem inherits QQuickItem. When the surface swaps a frame, that surface added to a model, which is eventually parented inside SurfaceContainer.qml [10:41] Binding { target: surface; property: "anchors.fill"; value: root } [10:44] i guess i'm still missing what in the client tells the server that a frame has been swapped [10:44] UbuntuOpenGLContext::swapBuffers doesn't seem to do much to tell the server [10:45] unless eglSwapBuffers is telling the server [10:45] tsdgeos: the call eglSwapBuffers does it [10:46] well that's what I've always thought [10:46] he he [10:48] Saviq, what MPs are coming on the next unity8 landing? when do you expect it to happen? [10:48] dandrader, http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=landing-003 [10:48] greyback_: shall we ask some mir guys? [10:49] tsdgeos: gimme 2 mins until my phone boots and I can try [10:49] ok [10:49] Saviq, and the "when"? :) [10:49] dandrader, I just rebuilt it, testing [10:50] dandrader, so, unless something else broke, soon [10:50] Saviq, not adding https://code.launchpad.net/~dandrader/unity8/greeterRefactoring/+merge/243823 ? [10:51] dandrader, no, wanted to leave that for the next silo [10:51] tsdgeos: all scopes unfavourited, restarted shell, I see the dash wallpaper now. You are stuck at the dash loading screen? [10:52] greyback_: phablet-shell [10:52] and start/stop unity8-dash a few times [10:53] Saviq, should runtests.sh work? [10:53] eventually you will get stuck in the splash screen [10:53] trying... [10:54] yeah got it [10:55] dandrader, it should, in theory [10:55] Saviq, do you or CI use it? [10:55] dandrader, didn't try for a while locally, but CI does [10:55] greyback_: so thing is UbuntuOpenGLContext::swapBuffers is happening but MirSurfaceObserver::frame_posted not [10:56] greyback_: i can continue pulling strings if you give me some lead [10:58] tsdgeos: qtmir.surfaces: MirSurfaceManager::onSurfaceAttributeChanged - surface= 0xaf206998 visibility=occluded [10:59] I get that, do you? [11:00] yeah something is weird here [11:01] let me see, that when fails, no? [11:01] possibly, am trying to boot correctly to compare [11:01] yeah [11:01] qtmir.surfaces: MirSurfaceManager::onSurfaceAttributeChanged - surface= 0xad5b1bb8 visibility=occluded [11:01] sometimes happens on boot too [11:01] it's not a "restart only" scenario [11:02] mzanetti, bug #1401488 - I retraced the random u-s-c crash [11:02] Error: Launchpad bug 1401488 could not be found [11:02] mhm [11:03] greyback_: i get the occluded too when works [11:03] only that after i get a [11:03] qtmir.surfaces: MirSurfaceManager::onSurfaceAttributeChanged - surface= 0xa909e0b0 focus=focused [11:03] ok [11:03] and not when it fails [11:03] focus shouldn't impact visibility [11:05] you're right in that it does appear that dash has drawn a frame, but our frame_posted callback didn't fire [11:05] perhaps qtmir registers that callback a little too late? [11:07] maybe [11:07] for a trivial qml file Rectangle { color: "blue"} - it displays ok [11:08] it draws a frame and get a focus & resize event just after that [11:08] QSG_RENDER_TIMING=1 qmlscene blue.qml --desktop_file_hint=/usr/share/applications/mediaplayer-app.desktop [11:08] makes tat easy to see [11:11] yep [11:12] but if I run dash manually, it doesn't appear [11:12] yep [11:13] if you run it enough times [11:13] it'll appear eventually [11:14] I've a theory [11:14] I'm watching the QSG_RENDER_TIMING output [11:15] if I see 2 "Render Thread" messages, I don't see dash appearing [11:15] if I see, I do [11:15] if you see what? [11:15] if I see 3, I do [11:16] no that doesn't explain anything though [11:16] :D [11:19] Holas [11:20] tsdgeos: the simple qml file working makes me think Mir is ok [11:21] tsdgeos: try something for me - comment out the Dash's DashCommunicator thingy [11:21] greyback_: i disagree, if you can code a client that breaks mir, mir is wrong [11:21] it's not like unity8-dash is doing much at that stage [11:22] greyback_: out from unity8-dash or from unity8? [11:22] tsdgeos: dash [11:25] greyback_: that seems to fix it [11:25] greyback_: but now explain me how this is not a mir/qtmir/qtubuntu problem === _salem is now known as salem_ [11:26] tsdgeos: yeah, I was fighting with something like this earlier in the week, for slightly different reason [11:27] tsdgeos: my suspicion is that when dash's dbus service comes up, Qt's GUI thread blocks a bit while introspecting dash's service [11:27] that doesn't mean it's not qtmir's fault though [11:29] where those frame posted events go to, I don't know. They shouldn't be lost [11:30] greyback_: you're going off branches i say [11:31] UbuntuOpenGLContext::swapBuffers proves there's frames posted [11:31] and there is no MirSurfaceObserver::frame_posted calls [11:31] that's the problem [11:31] tsdgeos: because qtmir might be blocking the mir thread that calls frame_posted [11:32] why is dash special? Why would it behave differently to a simple qml app? [11:32] because it takes more time to start [11:32] the only differene I'm aware of is that it communicates with shell via dbus [11:33] and it races [11:36] if I remove DashCommunicator from the shell, and restore it to the Dash, Dash starts up ok too [11:37] sure [11:37] you're workarounding the problem [11:37] not fixing it [11:38] greyback_: because if you re-add scopes [11:39] it will work with the dashcommunicator too [11:40] my guess is that with scopes enabled, dash draws more frames after that shell thread is unblocked. only guess tho [11:41] sure, I'm not handing you a solution, but if qtmir can't rely on the GUI thread being unblocked, then yeah weird things can happen [11:41] in which case, will have to redesign the qtmir threading model [11:43] tsdgeos: this is a patch I use to work around something similar: http://pastebin.ubuntu.com/9475014/ - would it help by any chance? [11:46] greyback_: that patch is unnecessarily complicated [11:46] you can just change a false to true in ./plugins/Unity/DashCommunicator/dbusdashcommunicatorservice.cpp [11:47] and i will still claim that is a workaround and the real problem will still come and bite us [11:48] but let's see if it helps [11:49] I'd genuinely appreciate insight into the real problem, if you see anything plain wrong [11:49] let me know [11:50] well [11:50] i know nothing on how mir calls frame_posted [11:50] and you told me not to ask the mir guys [11:51] so i can very well spend a few days on this [11:51] you're welcome to ask mir guys [11:55] eh :D [11:55] funnily [11:55] - UnityDBusObject("/com/canonical/UnityDash", "com.canonical.UnityDash", false, parent) [11:55] + UnityDBusObject("/com/canonical/UnityDash", "com.canonical.UnityDash", true, parent) [11:55] deadlocks everything [11:57] ouch [11:59] may actually even be a good thing [11:59] let me bt [12:04] if i only had more space in / [12:06] tsdgeos, I usually apt-get download dbgsyms (and actually keep them around) [12:07] i guess i need to change to compiling in chroots as you mentioned [12:11] tsdgeos: how can I add scopes back? bottom edge swipe does nothing [12:11] greyback_: muhahahahahaha [12:11] XD [12:11] http://www.nooooooooooooooo.com/ [12:11] greyback_: https://code.launchpad.net/~aacid/unity8/bottom_list_no_favorites/+merge/244169 [12:11] there's some gsetting call to add one back [12:12] but i don't know exactly the syntacx [12:12] np, will look [12:13] greyback_, gsettings reset com.canonical.Unity.Dash favorite-scopes [12:13] Saviq: ta, almost had it ;) === dandrader is now known as dandrader|afk === alan_g is now known as alan_g|lunch [13:04] Saviq: hey, getting those packaging changes in to vivid [13:05] Wellark, coolz, thanks [13:05] is that enough, or do we need them on rtm as well? [13:05] Saviq: as messing with the packaging on rtm is quite scary [13:05] Wellark, no, that's enough [13:05] Saviq: great! :) [13:05] it's not like we can cross-build rtm anyway :P [13:05] and it doesn't seem to be a problem otherwise [13:14] dandrader|afk, could https://code.launchpad.net/~dandrader/unity8/properInSceneDialogs/+merge/243998 impact the shutdown dialog? reboot doesn't work with the silo :/ [13:15] yeah, looks like it, I'm pulling from the silo === dandrader|afk is now known as dandrader [13:38] Saviq, how do I get to the shutdown dialog on the device? [13:39] Saviq, ah... it's missing one diff chunk from shellRotation [13:40] Saviq, could you wait a minute? :-) === alan_g|lunch is now known as alan_g [13:40] Saviq, problem is that the mock service used in the test doesn't match the real one [13:42] Saviq, pushed the plugins/Unity/Session/dbusunitysessionservice.h change make them both match [13:42] s/make/that makes [13:44] dandrader, it's almost built now, will have to wait until the next landing [13:44] noooooooooooooooo.com [13:45] dandrader, that's not noooooooooooooooo.com [13:45] who clicks on those URLs anyway ;) [13:45] that's nooooooooooooooo.com [13:45] I do! [13:46] it doesn't work on my browser. lousy website [13:46] * dandrader clicks that button and nothing happens [13:48] dandrader, speakers on [13:48] ? [13:48] * dandrader refuses to reply [13:50] http://www.dramabutton.com/ [13:50] Cimi, what's up with https://code.launchpad.net/~aacid/unity8/moreAsyncDash/+merge/241524 ? [13:50] mterry, guess what [13:51] Saviq, tags? I saw your comment [13:51] :D [13:51] dude :D [13:51] mterry, yeah, really, where do you take them from [13:51] Saviq, ah, now it works. I had some kind of blocker refusing to load the audio thingy [13:51] Saviq, "I'm *guessing* my use of a "bzr repository" is causing tags to stay around even when local branches are clean? -- I tested and stripped tags from this local branch and remote version. Then pushed my local to this remote. And tags appeared again. When done with my current MPs I'm just going to nuke my whole unity8 directory." [13:52] mterry: you just need to run the script on *every* branch. that's it [13:52] every == local and remote [13:52] mzanetti, I do and have [13:53] mzanetti, I suspect I'm the only one using these "bzr repos", so that may likely be the cause [13:53] mzanetti, he user a "bzr repository" thingy which is not the "bzr branch lp:foo" we layman people use [13:53] might be... never heard of that [13:53] mzanetti, bzr help repositories [13:53] mzanetti, it's a way to save space and time when dealing with a lot of branches off the same trunk [13:54] mzanetti, and a way to never let tags die I guess [13:54] and a way to keep tags forever :) [13:54] :) [13:54] :) [13:54] mterry: anyways, I have a AS based launcher backend mostly ready [13:54] mterry: hwever, AS is really slow [13:54] mterry, yeah, sounds like it [13:54] mterry: it blocks for 0.25 secs or so to update that key in AS [13:55] mterry, I'm using colo [13:55] mzanetti, we can't use async? [13:55] probably, yes [13:55] mterry, *and* repositories are the reason we have the tags in the first place [13:55] haven't tried it yet. just got it working properly with the sync approach [13:55] mterry, lp:unity and lp:unity/8.0 were put in the same repo, resulting in shared tags ;/ [13:55] mzanetti, cool [13:56] Saviq, what is colo? colocating offered by bzr directly or something else? [13:57] mterry, it's a plugin [13:58] mterry, lets you manage branches git-style [13:59] Saviq, ah, my brain is bzr native, so I'm not sure that would help me === dpm_ is now known as dpm [13:59] mterry, ;) [14:04] Cimi, for wizard-passphrase-osk, did you mean to approve as well? [14:05] mterry, Cimi doesn't seem to top-approve recently :P [14:06] push ups! [14:06] Saviq, or even bottom approve now [14:07] oh.. new fancy qt docs webpage [14:07] Just leaves checklists [14:07] And disappears into the night [14:07] mterry: using async calls would help a lot. think there is a problem with switching AccountsServiceDBusAdaptor::setUserProperty to use async always? [14:07] mzanetti, I think we'd need to look at all cases that use it now to verify they don't expect sync semantics [14:08] mzanetti, some people might assume change is made after set [14:08] mterry: I could introduce a setUserPropertyAsync... [14:08] mzanetti, heh that would probably be easier :) [14:08] ack [14:13] am I the only one to find that the new style of the qt docs makes it way harder to read? [14:21] dandrader: not just you [14:22] and all my history is b0rked again is it? [14:22] yep [14:23] http://doc-snapshot.qt-project.org/qt5-5.3/index.html [14:23] no actually history seems fine [14:23] at least that [14:23] true. You just get 5.4 docs now [14:23] better than the broken links from last time [14:24] Saviq, asked yesteday which silo is for that [14:24] mterry, ci is broken, can we rerun it? [14:25] Cimi, I don't know what the status of CI is now. I've been running things locally generally [14:25] Saviq, heya, how can I make a preview text widget collapsible? [14:26] cwayne_, you need to put it in a collapsible widget [14:26] or rather, an expandable one [14:26] oh "expanadble: [14:26] when did that happen? [14:27] is that new? [14:27] cwayne_, nope, it's been there for months [14:27] cwayne_, when mhr3 was still with us [14:27] i swear to god i never saw it in the list of preview widget types [14:27] damn [14:27] ok [14:27] btw table still isn't documented :) [14:33] cwayne_, you know where these docs come from ;P [14:34] when a mommy doc and a daddy doc love each other very much... [14:58] Saviq, is there a plugin to read dbus from qml? [14:58] Cimi, we generally build small purpose-built plugins for that [14:58] ok [15:02] charles, hey, was this by design that I can't dismiss calendar reminders now? [15:02] charles, they only last a few seconds, so that's kinda better than before [15:03] charles, but then not being able to snooze or dismiss.. [15:21] Saviq, it's intentional that they're temporary rather than looping audio + requiring manual dismissal by user [15:21] Saviq, this was a hallway discussion in DC, afaik there's no design writeup saying what the notifications should look like [15:23] charles, yeah, temporary, sure, but not interactive at all [15:23] Saviq: i built a chroot in the phone home, but now everything i build there seems to be incompatible with the phone, any idea why that may be? [15:24] tsdgeos, how did you create the chroot? [15:24] tsdgeos, sure it's rtm? [15:24] Saviq: vivid [15:24] but it's a vivid phone [15:24] tsdgeos, oh, interesting [15:25] tsdgeos, any chance your phone is not updated? [15:25] Saviq: debootstrap [15:25] no image is from today [15:25] tsdgeos, hmm hmm, and incompatible in what way? [15:25] Saviq: so i copied the libqpa-ubuntumirclient.so i just compiled to the proper place [15:25] and when starting unity8 i get [15:26] Ubuntu Platform API: Unable to load selected module. -- Aborting [15:26] tsdgeos, I wonder, permissions? [15:27] Saviq: nah [15:28] it is weird [15:29] tsdgeos, could probably use a more interesting output... I'd try building a .deb maybe [15:30] will try [15:30] tsdgeos, -nc to not clean, btw [15:34] Saviq: yep i know [15:45] Saviq: interestingly the deb package works :D [15:46] mterry: maybe your loader -> slow is because there's lots of other stuff in not a loader happening and thus the loader gets postponed? [15:46] Cimi: there's qt connectivyty thing [15:46] we mantain [15:46] ok [15:46] tsdgeos, it's possible. :( loader is happening when screen is turning off, and I naively wouldn't expect too much going on then. But maybe I'm wrong [15:46] tsdgeos, does this give a state of wifi connection? [15:48] Cimi: no, only if there's connection or not [15:48] tsdgeos, you mean if is connected or not? [15:49] Cimi: i mean if the phone can access the interwebs or not (either via phone stuff or wifi) [15:50] tsdgeos, mmm that's not what I need [15:51] ah, ok [15:51] tsdgeos, I need to see if I am connected via wifi [16:29] tsdgeos, hey, have you seen the update to https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1400762 ? [16:29] Launchpad bug 1400762 in unity8 (Ubuntu) "Manage Dash allows to unfavourite all scopes and leave you with a blank page" [Critical,Triaged] [16:30] pstolowski: yeah i'll do tomorrow first thing morning [16:30] now i have my mind somewhere else [16:30] tsdgeos, sure, np, i'll also add the restriction in the plugin back [16:31] oki === facundobatista is now known as dodhalhdlahfae === facundobatista_ is now known as facundobatista === dpm is now known as dpm-afk === alan_g is now known as alan_g|EOD [19:37] What might cause tryCompare to fail even if it spits out a warning that seems to show actual and expected as true? (i've tested type and both are booleans) === dpm-afk is now known as dpm [20:05] mterry, an exception? [20:05] mterry, hmm no wait [20:06] it says "expected": "true"; "actual": "true" and still fails? [20:06] FAIL! : qmltestrunner::DashContent::test_altNavigation() [20:06] Actual (): true [20:06] Expected (): true [20:06] Loc: [/home/mike/Work/code/unity8/greeter-refactor/tests/qmltests/Dash/tst_DashContent.qml(74)] [20:06] Saviq, ^ only warnings beforehand are binding loop warnings [20:06] mterry, you really sure they are both bools? one of them isn't a string? [20:06] Saviq, I printed typeof and it said boolean [20:06] mterry, yikes [20:07] Saviq, it's not on trunk, only my refactor branch. So I'm sure I did something weird [20:07] just don't know how to figure out what [20:07] I didn't even touch the Dash [20:07] mterry, can I see a branch? [20:07] Saviq, it's a huge diff right now [20:08] but sure [20:08] mterry, I just wanna try, not gonna read [20:08] Saviq, heh [20:08] Saviq, lp:~mterry/unity8/greeter-refactor (probably will infect you with tags, knowing me) [20:08] mterry, at least we know where they're coming from again [20:09] brb [20:11] mterry, testDashContent passed here [20:16] mterry, I looped it, that test went fine like 20 times [20:22] Saviq, oh [20:22] Saviq, good? Maybe my checkout is bonkers. Will blow away builddir and try agani [20:23] Saviq, thanks for trying [20:23] mterry, sounds like a good idea, otherwise I'd start looking sideways at the HW ;P [20:40] yay, it passed [20:40] Stupid cosmic rays === dpm is now known as dpm-afk [20:50] good evening. i am thrilled to try unity8-in-lxc to help with QA [20:50] however, this blocks me from doing anything at all: bug 1391815 [20:50] bug 1391815 in unity8-lxc (Ubuntu) "unity8 processes uses 100% cpu, desktop frozen" [Undecided,New] https://launchpad.net/bugs/1391815 [20:52] dkessel: Hi, I saw your bug update and added the unity8-lxc task. However, looking at the description, it seems this occurs for you on a live image as well. Is that correct? [20:53] ChrisTownsend: well, yes it did in november. i guess it would still do that. [20:55] dkessel: fyi, there is a known limitation when using the LXC version that vt switching currently doesn't work, as you pointed out. Is it possible for you to try the live image again just to be sure so we can rule out the LXC part of this? [20:56] dkessel: Also, what graphics is on your machine? Intel, Nvidia, or AMD? [20:58] ChrisTownsend: ok, will try the current live image. graphics: Intel + Nvidia (you know... "Optimus" hybrid) [21:00] dkessel: Ok, thanks. Since you originally said unity8 was spinning at 100%, I'm suspecting an issue somewhere in that stack. It might be good to try to reproduce this on the live image and then switch to a VT and then break in to the unity8 process with gdb and get a stacktrace to see maybe where it's getting stuck. [21:01] dkessel: Once we get a bit more info in the bug, then we can add the unity8 task. [21:03] dkessel: I'm also wondering if Mir is having fits with your graphics. Any way to just force Intel in the BIOS or unload the Nvidia driver? [21:03] dkessel: As I say that though, you probably wouldn't see the desktop at all. [21:05] ChrisTownsend: hmm thanks for trying to help. too bad my downlink speed is really unstable today - i don't think i will be able to download that image today :/ [21:05] but i will come back! [21:05] or we can try something else if there could be any logs, for example... [21:06] dkessel: Ok, no problem. Feel free to update the bug if/when you have more info. Umm, yeah, logs... [21:06] dkessel: You could try attaching ~/.cache/upstart/unity8.log after this occurs and see if it's spewing anything. [21:13] ChrisTownsend: ok, will try doing that [21:15] dkessel: ok, thanks === salem_ is now known as _salem