=== jhodapp is now known as jhodapp|afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [04:39] one interesting issue when checking mir with nexus 10 [04:39] bug 1203268 [04:39] bug 1203268 in Mir "Mir fails to start on Nexus 10 as display is already unblanked" [Medium,Triaged] https://launchpad.net/bugs/1203268 [04:39] mir_demo_server_basic fails because unblank returns an error (already unblanked) [04:39] which shouldn't be fatal [04:58] Mmm. 21s latency to google.com. My internet really knows how to party recently. [04:59] This bodes excellently for the upcoming hangout! [05:02] RAOF, ping [05:04] tvoss: Pong [05:30] Perhaps the copper is jealous of the approaching fibre? [05:31] Mayhap [05:33] Whereas my copper now needs to last till the next Labour government. [05:34] Or something === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [06:11] RAOF, hikiko hangout? [06:12] racarr? [06:13] * duflu assumes no kdub this time of day [06:19] Hm. missed the hangout? [06:20] RAOF: just cancelled [06:20] My audio is dead and no one other than alf turned up [07:30] hey guys [07:30] alf_, for https://code.launchpad.net/~afrantzis/mir/server-started-notification/+merge/191134 [07:30] alf_, should we not have ABI / version bump there? so that we can depend on it? [07:32] Saviq: no, we bump the ABI once when we merge from development-branch into lp:mir, to avoid ABI bump races (e.g. two branches increasing the ABI to the same value etc) [08:00] RAOF: have you looked at my patch? :P [08:14] alf_, yeah that's fine, I'm not asking straight away, but there will be a bump, yeah :) [08:15] alf_, any idea what can we put in Build-Depends: libmirserver-dev (>= ???) then? [08:16] alf_, we've >= 0.0.14 now [08:19] RAOF: but yeah using gbm as 'native' backend would be preferred for create pixmap/lookup image [08:19] makes life easiser [08:19] -s [08:19] my patch simply makes gbm creating screen not run into weird pointer issues [08:20] Saviq: my guess is that we will go to 0.0.16 and libmirserver8, but kgunn should have a definitive answer [08:20] alf_, k thanks [08:27] duflu: btw, we could reduce coupling by using a NiceMock, so that we could just expect glEnable(GL_BLEND) = 0 times glDisable(GL_BLEND) = 1 time (and perhaps expect glDrawArrays() to ensure we Disable before drawing) [08:28] alf_: Umm, redesign the GLRenderer tests to be nicer, separately? It's done now [08:28] duflu: ok [08:43] alan_g, ping [08:43] tvoss: hi [08:44] alan_g, hey there, do you keep on digging into why mir/u8 becomes slow after the uitk tests? [08:47] tvoss: yes, getting back to that [08:48] alan_g, thx [08:50] * alan_g has broadband problems again :( [09:02] alf_: oh btw finally got around to testing nested mir, works unsurprisingly [09:03] mlankhorst: \o/, excellent, thanks! [09:15] mlankhorst: I have indeed looked at your patch. [09:16] RAOF: well any work done should be on top of that as base, because it's the minimum to get gbm working ;) [09:17] mlankhorst: Yeah. [09:17] mlankhorst: I just still not convinced that getting gbm working is the appropriate goal :) [09:17] RAOF: well not sure how you want to get nested mir working otherwise.. [09:18] You pass in a gbm_bo to create_image_pixmap_khr, you pull the __DRIImage out of it, and you dupImage() it? [09:19] RAOF: and hit the intel bug again? [09:19] or maybe similar bugs in radeon/nouveau [09:19] Of course, that doesn't actually *work*, but I don't see a good reason why it *shouldn't* work ☺ [09:19] because you create 2 instances of screen [09:19] which each have separate tracking [09:19] for the same drm fd [09:20] and there is no refcounting for gem, it's create/destroy only [09:20] Right, but there *is* refcounting for __DRIImage [09:20] ok fine [09:20] I've traced it down, and the appropriate intel_region is reffed. [09:20] libdrm/intel/intel_bufmgr_gem.c [09:20] that is where the problem was [09:21] sec [09:21] you create 2 separate drm_intel_bufmgr_gems for the same fd [09:21] create a bo against one, and validate it in the other [09:22] Aaaah. [09:22] this breaks down in drm_intel_add_validate_buffer2 [09:22] *That* makes more sense. [09:22] specifically the line drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *)bo->bufmgr; [09:22] and drm_intel_bufmgr_gem has its own dirty etc tracking that a your solution wouldn't cover, but i guess you get the point ;) [09:23] Boo. [09:23] Passing in the gbm_device is annoyingly ugly :( [09:24] it's the only solution :P [09:25] RAOF: or we could make a gbm mir backend and use platform_drm? :P [09:25] I was actually thinking about that. [09:25] Although, you know what would be easier? [09:26] dno? [09:26] An EGL extension inverting the problem! [09:26] creating a gbm from egl? [09:26] ie: rather than trying to import foreign buffers, export a buffer. [09:26] erm you still hit the same issue [09:26] same fd, can't validate it [09:27] No, you'd end up with it imported on a different fd. [09:27] meh just don't make life even harder, go with the solution I wrote. :S [09:27] Yeah. [09:28] Actually... isn't there already an "Export EGL image to dma-buf fd" jobby? [09:28] i thought only importing [09:28] tvoss: alan_g: another data point about unity8 slowness after AP tests: it seems that the whole system has become slower, especially I/O. For example, apt-get install progresses awfully slowly when "Reading package lists". Stopping unity8 restores performance. So my guess is something IO related is going on. [09:28] Yeah. [09:28] You're right. [09:29] alf_, interesting. can you strace unity8? I think we will see some waits/polls there that shouldn't be there [09:29] alf_: checked the memory footprint? [09:29] fix XMir to work seamlessly first. ;) [09:29] tvoss: I will, that what the apt-get install was for :) [09:29] mlankhorst: Yeah, yeah... :) [09:29] alf_, ;) [09:29] You still have 4 months or so. ;D [09:30] * RAOF really really EODs [09:30] RAOF, bye [09:30] and good night ;) [09:30] alan_g: tvoss:good idea, and you are probably right... I see: 980m 624m 581m [09:31] alf_, of unity8? [09:31] tvoss: yes [09:31] wow [09:31] hmmm, valgrinding on the phone? :) [09:32] tvoss: normal usage (before AP tests) is 425m 83m 48m [09:33] aha [09:33] alf_, mako or maguro? [09:33] tvoss: mako [09:38] tvoss: I've played around with unity8 for a while without seeing any surfaces leaked. (Now to work out how to run the tests) [09:39] alan_g, ack, thx [09:40] alan_g: tvoss: the memory piles up as new tests are being run. However, opening/closing apps manually seems to release memory normally (looking at top output). So perhaps there is something in the way that autopilot works that is causing the leaks? [09:41] alf_, normal = opening/closing apps from the launcher ? [09:42] tvoss: alan_g: Yes. Although, arguably, unity8 should not allow autopilot to cause leaks even if it misbehaves. [09:42] alf_, it might be due to the upstart based app launching [09:42] alf_, can you try invoking apps from the cmdline, please? [09:42] tvoss: through upstart? [09:43] alf_, yup, we start applications via the user upstart session nowadays [09:43] alf_, that's how ap starts apps [09:49] tvoss: hmm, so how do you actually start an app with upstart? 'start ' doesn't work [09:50] popey, can you help alf_ real quick?^ [09:51] * popey arrives [09:51] you need APP_ID [09:51] popey: ok, where do I get that from? [09:51] start application APP_ID=music-app [09:51] something like that I think [09:52] it's the bit of the .desktop file [09:52] often found in /usr/share/applications or ~/.local/share/applications [09:53] popey: great, thanks [09:54] popey: can I use upstart to also stop an application? [09:56] never tried ☻ [10:01] popey: well, 'stop ...' doesn't work so I guess not [10:02] alan_g: tvoss: aha, when killing (i.e. SIGTERM) an app, memory in unity8 is not released! [10:02] oof [10:03] alf_, that is, the friendly: please kill yourself SIGTERM is not registered by unity? [10:04] alf_: does the server see the client has died? (connector report ought to say) [10:05] tvoss, alf_, did memory usage increase enough to cause the slow down? i.e. are we swapping or somethng? [10:05] alan_g: haven't checked yet, will start unity8 with MIR logging... [10:05] Saviq, pre-test 425MB, post: 980MB [10:05] tvoss, ok, yeah, that's bad [10:06] tvoss: that's just virtual, resident was: 83m -> 624m [10:06] alf_: and does the app actually exit? [10:06] alf_, okay, that's even worse :) [10:06] alan_g: yes === chihchun is now known as chihchun_afk [10:17] alan_g: tvoss: http://paste.ubuntu.com/6244872/ (ignore UbuntuKeyboardInfo - socket error, I am starting unity8 manually without maliit) [10:18] alan_g: tvoss: the app drops the connection abruptly, so perhaps we are not cleaning up resources properly in this case? [10:21] tvoss: So if autopilot stops apps like this, it would explain the leak. Can we find out how autopilot stops the test apps? [10:21] alf_, good question. asac, can you help here? [10:22] asac, alf_ I would assume first SIGTERM and SIGKILL if nothing happens [10:23] would go for #qa [10:23] and check with folks if anyone with autopilot know how is around... also you can check with osmonon [10:23] and Saviq ... those have used autopilot a lot as well [10:23] (and would at leaast have an idea how to find out) [10:24] tvoss: alf_: ^^ [10:25] tvoss, alf_, asac, it doesn't SIGKILL them [10:25] tvoss, alf_, if the app under test is hanging, it will go "Killing app blah..." indefinitely [10:26] Saviq: does it SIGTERM, thought? [10:26] -t [10:26] alf_, I imagine so, yes, how else? [10:26] alf_: i think this might be the code: http://paste.ubuntu.com/6244898/ [10:26] hmm. or not [10:27] check out lp:autopilot ... testcase.py [10:27] autopilot/testcase.py [10:27] ok, so it never SIGKILLed for me... [10:27] http://bazaar.launchpad.net/~autopilot/autopilot/trunk/view/head:/autopilot/testcase.py [10:28] Saviq: did you see processes not getting TERM'ed? [10:28] SIGTERM [10:28] and it didnt KILL? feels like a bug then [10:29] tvoss, AP does a SIGTERM/SIGKILL to terminate applications [10:29] but i dont think this is what we see here? [10:29] jibel, so sigterm first, then sigkill? [10:29] see the code. seems like it ... yes [10:29] after 9 seconds :) [10:29] asac, yeah, unity8 has an issue on TERM when it gets stuck if still animating [10:29] tvoss, yes, that's in the code asac found [10:30] Saviq: so the kill code didnt work? [10:30] asac, it didn't seem to indeed [10:30] err ... never happened? [10:30] Saviq: sure it was autopilot that was hanging and not unity? [10:30] err ignore [10:30] asac, with upstart it's working (assume upstart is SIGKILLing) [10:30] well. hard to say without being able to reproduce [10:30] asac, yeah, had to kill -9 unity8 [10:30] maybe this is not the code that is getting run though [10:31] asac, I expect it is - I saw the "Killing process..." indefinitely when unity8 hung [10:31] there is also one hit for TERM in autopilot code here: [10:31] bin/autopilot-sandbox-run:trap on_exit EXIT INT QUIT ABRT PIPE TERM [10:31] err ignore [10:31] not sure what that sandbox is and when its used though [10:31] tvoss: asac: ok, so we have found when the unity8/mir leaks happen. Now to find out why unity8/mir doesn't clean up if a connection is terminated abruptly... on it... [10:31] alf_, +1 [10:32] after lunch :) [10:32] alf_, enjoy === alf_ is now known as alf|lunch [10:32] asac, that's for developer to run their code locally, not for production use [10:33] asac, it runs AP test inside xvfb or xephyr instead of using the active session [10:33] ic ... thanks [10:33] alf|lunch: what is exactly leaking? [10:33] some resources related to maliit i figure? [10:34] asac: no idea yet === alan_g is now known as alan_g|afk === hikiko is now known as hikiko|lunch === alan_g|afk is now known as alan_g [11:23] t1mp, alf|lunch and tvoss are looking into the uitk ap failures [11:23] great, thanks [11:24] and overall system slowdown after it [11:24] alf|lunch, tvoss, Saviq so now it seems that individual tests pass if we run them after a reboot [11:24] but if we run all the tests, or if we run a single test a lot of times (like 10-20), then they start to fail [11:24] and after they fail, also qmlscene segfaults [11:24] so it seems like an issue with cleaning up processes [11:25] ^^ I cannot always see them, but sometimes I see the dash filling up with thumbnails after those test runs [11:25] I'm guessing apparmor prevents me from "seeing" it in ps [11:25] t1mp, yup, alf|lunch is tracking that down [11:25] tvoss: great. please keep us informed also :) [11:26] and let us know if we can help [11:26] t1mp, please stay around here :) [11:26] sure === alf|lunch is now known as alf_ [11:29] alf_: hello. I hope you enjoyed your lunch :) as you can see, SDK people are invading this channel so we can bug/help you with the UITK autopilot failures [11:30] t1mp: ok, I am currently investigating the mir part of it, will let you know [11:30] alf_: ok, great. [11:31] alf_: are there other parts to it besides the mir part? [11:32] t1mp: I am not sure yet. It seems that if an app is SIGTERMinated, not all resources are released properly, looking into what exactly is happening there. [11:33] t1mp: => resources in the server, causing leaks === hikiko|lunch is now known as hikiko [11:53] alf_: ok [12:00] alf_: I've been playing - Mir doesn't see (e.g. terminal) drop the connection if I send it a SIGTERM. [12:02] * alan_g was looking at this sort of issue in the client side comms before interrupt (and planning to look at same on the server next) === alan_g is now known as alan_g|lunch [12:03] alan_g|lunch: I am getting server messages like "connection dropped without disconnect [12:04] alan_g|lunch: aren't you getting any messages at all? === alan_g|lunch is now known as alan_g [12:44] alf_: I'm getting the connection messages, but nothing about disconnect - but maybe I've a slightly different scenario. [12:47] alan_g: (Have you enabled all the REPORTS properly?) In my case, investigation shows that the shell::ApplicationSession is never destroyed, because unity-mir is keeping a strong handle to it, keeping the 'application' alive... [12:47] alf_: (I'm starting the terminal from the u8 GUI and killing it from an adb shell) [12:47] alf_: I've got DebugSurfaces report and connector report [12:49] alan_g: FWIW, "connection dropped without disconnect" is a SessionMediatior report message [12:49] alf_: adding it now [12:50] alan_g: btw, we should change the connector report to use "Connector" instead of "SessionMediator" [12:50] alf_: True [12:54] alf_: I still don't see the server noticing the disconnect... [12:59] alf_: my bad - it was on stderr, not stdout [13:03] alf_: You're ahead of me here. (I'll go fix the report. ) [13:04] alan_g: ok [13:43] greyback: could you please explaing the logic of ApplicationManager::onSessionStopping() in unity-mir/src/modules/Unity/Application/application_manager.cpp ? [14:12] tvoss: did you get any progress on the slowdown that we can trigger easily after running the ubuntuuitoolkit AP tests? [14:14] didrocks, see backlog, alf_ and alan_g are looking into the issue and it seems to be a memory leak [14:14] any ETA? [14:15] alf_, alan_g ^ [14:15] didrocks: tvoss: alf_ is the man [14:16] didrocks: tomorrow for sure, maybe today but no promises [14:17] alf_: ok, to be in finale, we need to avoid an ABI break though FYI (we just rejected the sigstop one because of that) [14:19] just keep in mind that this has been preventing uitk releases for days, no fix isn't exactly an option [14:19] kalikiana, strong words don't help here, let alf_ keep on working [14:20] if didrocks talks about rejecting fixes those are strong words for me [14:20] kalikiana, well, that's didrocks department and decision in the end. I'm pretty sure alf_ will try to avoid an ABI break [14:22] (hence why I prefer to warn in advance) [14:26] alf_: If Mir reports an application has stopped, but shell/upstart wasn't one to stop it, we assume the lifecycle management killed it, so set the application state as "Stopped" - keeping the app in the list of running apps [14:26] alf_: that what you wanted to know? [14:26] greyback, why would the lifecycle mgmt do something without unity/mir knowing? === dandrader is now known as dandrader|afk [14:28] greyback, the point is: how do you distinguish from autopilot sigterm'ing a test app? [14:28] tvoss: well nothing is telling unity/mir that the OOM has killed an app [14:29] tvoss: yep that's a problem. AP should really be using upstart, not relying on the desktop_file_hint hack [14:30] greyback, what would need to be changed? [14:30] tvoss: well first, is this really a problem? Is it breaking anything? [14:31] greyback, it causes u8 to slow down to a crawl [14:31] tvoss: second, AP would need to launch apps using upstart-app-launch === dandrader|afk is now known as dandrader [14:46] tvoss: @"how do you distinguish from autopilot sigterm'ing a test app?" why would you need to? [14:47] tvoss: nm - I just understood the context [14:47] alan_g, killed by lifecycle is a valid reason to keep the app as "running" around in the shell, killed by autopilot is not a valid reason [14:47] tvoss: yeah. But the Mir resources still need to be cleaned up [14:48] *session resources [14:48] alan_g, yup, alf_ and greyback are on it [14:50] * alan_g thinks that is should be as simple as using a weak_ptr to the sh::Session instead of a shared_ptr [14:50] (From 50.000m) [14:52] alf_, ^ [14:52] ;) [14:54] alan_g: possibly, although I think this may be too risky a change at this point for unity-mir (but I am not very familiar with the unity-mir internals). [14:54] greyback: ^^? [14:55] alf_: yep, that's too big a change right now. I'm keeping it simple [15:03] hikiko: kgunn: racarr: stand up [15:04] alf_: gonna miss today...let me know if you got any questions [16:04] alf_: care to have a look? https://code.launchpad.net/~gerboland/unity-mir/fix-leaks/+merge/191449 [16:04] greyback: looking [16:11] greyback, did you try that patch with the uitk testsuite? [16:11] tvoss: no, I ran through the steps in the bug. [16:12] tvoss: but I'll do that, just to check [16:12] greyback, yup [16:14] greyback: I lack the surrounding context - but why is the delete only when "application == m_focusedApplication"? [16:15] greyback: tested successfully on phone, now running uitk too [16:16] greyback: (phone == single app case) [16:16] alan_g: if app not in forefront, and it dies, we are pretending the app is still alive. If the user then requests that app, we will launch it again, hopefully restore its state, and give that to the user [16:16] alan_g: so ideally they'll not realise the app was dead [16:18] greyback: would it make sense to also add application->setSession(nullptr); to some cases in ApplicationManager::onProcessStopped() ? [16:18] greyback: Is there another line that releases the sh::Session pointer? setSession()? [16:20] alf_: actually yeah, there's one place, nice spot [16:21] alan_g: is it the Application object that's holding the sh::Session pointer. Calling setSession(nullptr) deletes that shared pointer [16:22] greyback: I get it [16:24] greyback: tvoss: verified ubuntuuitoolkit tests run fine, system fluid after tests [16:24] alf_: yep here too [16:25] alf_: fixed? [16:25] alf_: pushed one other fix [16:25] asac: yes, with greyback's MP: https://code.launchpad.net/~gerboland/unity-mir/fix-leaks/+merge/191449 [16:26] alf_: do you feel the issue is fully understood now? [16:26] and this is a clean fix? [16:26] or rather a hack in the hope of ... :)? [16:27] and is it the only fix? [16:27] right :) [16:27] also that [16:27] alf_: greyback: ^^ [16:27] asac: didrocks: clean fix, plugging a memory leak [16:27] asac: didrocks: what do you mean by only fix? [16:28] alf_: is this the only patch we need to take? [16:28] alf_: like this is the cause of all the slowliness we see after launching ubuntuuitoolkit AP tests? [16:28] compared to 99 [16:28] asac: was my bug, problem clear, fix is correct [16:29] asac: my bug as in I introduced the bug :) [16:29] asac: yes, slowness was because unity8 process ended up taking up 700MB resident memory, including graphics surfaces [16:29] greyback: well, so what else was committed to mir branch after 99 image content [16:29] err unity-mir [16:29] didrocks: maybe check and make a call :) [16:29] I'm checking [16:29] the patch looks good [16:29] yeah [16:29] asac: an OOM value setter by tvoss [16:29] didrocks: we would take the OOM anyway? [16:30] i remember seeing it on landing [16:30] asac: yeah, but unity-mir wasn't part of the landing ask [16:30] so not that part [16:30] * didrocks looks at the code [16:31] hum, I don't like it [16:31] (rev 127) [16:31] greyback: did you test with that one? [16:31] didrocks: yes, it works [16:32] greyback: trusting you on rev 127 then (the OOM one) :) [16:33] didrocks: ack [16:34] didrocks: check with tvoss [16:34] tvoss: http://bazaar.launchpad.net/~mir-team/unity-mir/trunk/revision/127 [16:45] asac, didrocks waiting for lool to revisit https://code.launchpad.net/~thomas-voss/unity-mir/less-aggressive-scores/+merge/191440 [16:45] asac, didrocks making the oom score adjustments more conservative [16:45] tvoss: So do we want to test this too? [16:45] tvoss: I started looking, but to land this we'd also want to test the OOM again [16:46] lool: is this really wanted for finale? ^ [16:46] didrocks: well mu [16:46] didrocks: I personally think it can come in an update [16:46] I don't want pushing the finale cut forever [16:46] ok, let's get that tomorrow, once we are happy with the image [16:47] we have tested OOM, it has a small bug [16:47] this version will be cleaner, but it can land in a couple of days [16:48] didrocks: we could ask folks for the performance fix isolated [16:48] backing out the oom commit [16:48] so we can take it [16:48] ... just saying that that is an option [16:48] (not saying we should do that... leave that to you) [16:49] asac: greyback tested with the oom commit [16:49] asac: I have full trust on him :) [16:49] tvoss: Hmm why file.open(QIODevice::WriteOnly | QIODevice::Text) on the adjuster's oom file? [16:49] asac: otherwise, I would have ask for a revert TBH [16:50] tvoss: dont we want ReadOnly? [16:52] lool, oh, good point [16:53] tvoss: let's not rush this in; we could even take the time to write tests along side, the way you've split the functions is very nice for testability actually [16:54] lool, yup, happy to iterate [16:54] lool, that said, I will look into it tomorrow again [16:54] lool, fine for you? [16:54] tvoss: Not being very good on the C++ side, I dont understand whether int * float to int will be nice [16:54] tvoss: Sure, I can review tomorrow, dont think we will land tomorrow though [16:54] friday rather [16:54] lool, ack [16:54] greyback, alan_g, alf_ thanks for the fix :) [16:54] tvoss: so I would have written * 80 / 100 rather than * 0.8 [16:55] but perhaps that's ridiculous given what the compiler already knows [16:55] lool, yup [16:55] * tvoss grabs dinner [16:55] back in ~30 mintues === dandrader is now known as dandrader|lunch [16:58] I will slowly walk away [16:58] might take a sneak peek to see if last landings come in nicely [16:58] but everything for image #100 is set [17:09] lool, thanks :) [17:10] * greyback eod [17:10] greyback, o/ [17:50] alf_: any news for the uitk autopilot tests? [17:51] t1mp: https://code.launchpad.net/~gerboland/unity-mir/fix-leaks/+merge/191449 [17:51] but haven't tested it myself yet [17:51] (eod for me) [17:51] kalikiana: at least the name of the branch sounds good :D [17:51] if it fixes our issues that's awesome :) [17:51] but yeah, I'll also see tomorrow. eod time [17:52] t1mp: yes, tested it fixes the slowness after uitk [17:52] alf_: and the uitk autopilot tests run then? [17:53] t1mp: I have run the full uitk twice without problems with this branch [17:53] t1mp: (60 tests) [17:53] wow. super :D [17:53] alf_: thanks! [17:53] ah greyback is offline, I'll thank him tomorrow :) [17:56] tvoss, kgunn: http://ubuntuone.com/0Vem5WU2FOKaY5QVVnnmcC sorry for the sideways view bit of weirdness with android videoing, but you should at least be able to tell that it is much snappier now :) [18:01] I'm concerned that the ui toolkit tests [18:01] passed yesterday? and failed today :* [18:01] :(* [18:03] racarr: passed yesterday? they are failing since last week. [18:07] t1mp: You mean the autopilot tests? [18:07] tvoss, kgunn: that is image 99 by the way :) feels a much nicer place to be :) [18:08] I think I looked [18:08] at the wrong report yesterday a bit :p ignore me [18:08] racarr: yes [18:08] racarr: ok :) [18:08] davmor2, thx :) [18:09] racarr: I was talking about this https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1239646 [18:09] Ubuntu bug 1239646 in Ubuntu UI Toolkit "CI fails most tests on UITK trunk" [Critical,In progress] [18:09] I don't understand the failures up there though.... [18:09] racarr: might be fixed in mir now [18:09] racarr, I'm pretty sure things are fixed now [18:09] t1mp, in unity-mir [18:09] Ok [18:10] how to interpret test failures like http://reports.qa.ubuntu.com/smokeng/saucy/touch_mir/mako/99:20131015.2:20131015/4749/ubuntu-ui-toolkit-autopilot/491077/ [18:10] though [18:11] oh is it the OOM killer [18:11]