[00:03] kgunn: it doesn't save that information in the logs [00:03] kgunn: I will rerun the tests to get that info, it goes to stdout [00:06] kgunn: I don't notice any tearing, but open arena is always moving it would be hard to see [00:07] kgunn: I'll watch again and get back to you. brb [00:27] kgunn: openarena runs too fast to tell if it's tearing [00:31] run non xmir openarena with vblank_mode=0 openarena? [00:31] xorg had a segfault on intel with xmir http://10.97.2.10:8080/job/utah-xmir-troubleshooting/ws/results/Xorg.0.log [05:08] RAOF, ping [05:27] hi. now there're two mir PPAs, which one to use? installing_prebuilt_mir_on_pc.md suggests using system-compositor-testing ppa. but i find packages in Mir staging ppa are newer. [05:28] sgx1, yup, but staging revs too fast and system-compositor-testing is the save alternative so far :) [05:28] sgx1, we cherry-pick over to system-compositor-testing on a regular basis [05:28] tvoss_: Pong. [05:58] RAOF, duflu, alf__, hikiko, racarr, kdub, kgunn, meeting time! [05:58] thomi too! [05:58] hi [05:59] joining in a sec robert_ancell [06:06] kdub: you around? [06:25] didrocks, ping [06:29] tvoss_: pong [06:29] didrocks, got a branch for you to test on the ati machine :) [06:30] tvoss_: yeah! there are two ways: building it locally (but I don't have any i386 machines ready) [06:30] tvoss_: or pushing that to the ppa manually [06:30] I'm in favor of #2 [06:31] didrocks, so what do you need from me? just the branch? [06:31] tvoss_: yep, the branch is fine [06:32] didrocks, lp: ~thomas-voss/mir/default-to-null-input-by-default [06:32] tvoss_: branching, pushing, building [06:32] then will rerun [06:32] didrocks, ack [07:05] didrocks, status? [07:06] didrocks, I need to step out at 10 my time (in ~55 minute) to run some errands [07:06] tvoss_: well, it's building in the ppa right now [07:06] tvoss_: and as there is an ABI break, regarding to latest version, I have to rebuild u-s-c as well [07:07] so waiting for mir to publish first [07:07] didrocks, ack ... which ppa are you using? [07:09] tvoss_: daily-build-next [07:09] didrocks, ack and thx [07:09] yw ;) [07:09] will keep you posted [07:38] didrocks, stepping out now, back in ~1 hour [07:38] tvoss_: ok, u-s-c is building now [07:38] didrocks, ack [07:46] good morning [08:03] didrocks: ping [08:05] mlankhorst: pong [08:05] didrocks: on that non-working machine, could you post the full logs from /var/log/lightdm and full dmesg? [08:06] mlankhorst: I are running a rerun from tvoss first [08:06] mlankhorst: so wait for it I would say ;) [08:06] currently running, so shold have results soon [08:07] yeah my own test machine fails with std::exception::what: Failed to set the current VT mode [08:07] * mlankhorst doesn't have plymouth or splash enabled, might be why [08:13] hm seems to be https://bugs.launchpad.net/mir/+bug/1195509 [08:13] Launchpad bug 1195509 in Unity System Compositor "System compositor fails to start - Failed to set the current VT mode: Input/output error (5)" [Critical,Triaged] === dholbach_ is now known as dholbach [08:31] mlankhorst: do you start it from lightdm? [08:31] yeah [08:31] weird === seb128_ is now known as seb128 [08:33] does lightdm switch to the console before letting unity-system-compositor configure it? [08:37] and can I use strace on ust somehow, to figure this one out [08:37] mlankhorst: I can answer on the second one [08:38] mlankhorst: /etc/lightdm/lightdm.conf.d/ [08:38] you have a file shipped by usc [08:38] you can put a command [08:38] like: system-compositor=strace unity-system-compositor [08:40] yeah [08:40] hm of course that works.. [08:49] didrocks: who spawns the xserver, unity-system-compositor or lightdm? [08:51] mlankhorst: ligthdm AFAIK [08:52] but I can be wrong [08:54] hm seems to be a plymouth race :P [09:38] didrocks, ping [09:38] tvoss: wb! [09:38] tvoss: so passed \o/ [09:39] tvoss: please file a MP ;) [09:39] (I'm still rerunning to ensure we don't get any race, but should be good) [09:40] didrocks, \o/ [09:40] RAOF, any more insight? any handover tasks I should look into? [09:40] looks like it's still failing locally, I'll try to figure out why :p [09:41] tvoss: I'm still hooking up exposing the buffer id to the client. Once that's done, I'll instrument everything and give it a run. [09:41] RAOF, awesome, thank you :) [09:43] greyback, ping [09:45] alf__, didrocks https://code.launchpad.net/~thomas-voss/mir/default-to-null-input-by-default/+merge/176638 [09:48] tvoss: pong [10:00] tvoss: what's the driving force behind default-to-null-input-by-default ? [10:01] alf__, first: it saves us a bunch of wakeups per second in the system compositor scenario. Second: it solves issues with booting up on certain ATI HW where creating a bo for the hw cursor results in an exception [10:02] tvoss: can't the system compositor turn this off, instead of making it the default? [10:02] alf__, possible, too [10:20] tvoss: should I rebuild Mir without your patch and be ready to take the new system-compositor in? [10:20] tvoss: ran 4 times, with full test suit and pass [10:23] I think I understand the bug, but not the fix yet :P [10:23] mlankhorst, which one exactly? the ati one? [10:23] https://bugs.launchpad.net/mir/+bug/1195509 [10:23] Launchpad bug 1195509 in Unity System Compositor "System compositor fails to start - Failed to set the current VT mode: Input/output error (5)" [Critical,Triaged] [10:23] mlankhorst, \o/ I have been looking at that, too [10:23] didrocks, yup, but might take me some time, an hour or so [10:24] tvoss: ok, I can rebuild Mir meanwhile [10:24] to not loose time [10:24] tvoss: or will you have Mir changes? [10:24] (to expose an API or so on…) [10:24] tvoss: well it's a dumb bug [10:25] didrocks, most likely no mir changes, at least I hope so [10:25] tvoss: ok, let me do a preventive build then :) [10:27] mlankhorst: Something involving plymouth is a dumb bug? Say it ain't so! [10:28] I don't get why plymouth is killed by lightdm *after* xserver started.. [10:28] or mir [10:31] mlankhorst: I think for smooth transitioning? (just a guess) [10:35] anyway the io comes from the TTY having hung up [10:35] No, that shouldn't be it. [10:35] I'm guessing it is being opened too early, while plymouth still has control over it [10:36] mlankhorst: How's that mir-plymouth branch goin? :) [10:36] RAOF: blocking on the same thing as I want to block Xmir for, the separate thread is ugly [10:37] mlankhorst: Indeed it is; bug tvoss about that :) [10:37] but I did a control WARN_ON(1), and I did get that unity-system-compositor had a WARN_ONn hung_up_tty_ioctl+0x27/0x50 [10:38] so it looks like this is the issue here [10:38] mlankhorst, RAOF happy to adjust the separate thread, but can we fix the bug without me on the critical path? [10:39] tvoss: erm sure, just postpone opening the fd or patch lightdm some more [10:39] mlankhorst, cool [10:39] I can do the latter [10:39] tvoss: Yeah, it's fixable. It's just that there wouldn't be an opportunity for this bug to exist if we weren't doing the stupidly fragile plymouth dance. [10:40] RAOF, help me understand, what is the fragile plymouth dance? :) [10:40] tty handover from plymouth [10:41] Plymouth starts, grabs the display. We then ask plymouth to die but hide its dying, and then X starts up, grabs the display, and takes the contents of the framebuffer. [10:42] well it looks like a workaround here might be to use VT_SETACTIVE instead of VT_ACTIVATE [10:42] erm VT_SETACTIVATE * [10:43] * duflu goes to find food [10:43] * tvoss loves those subtle differences for VT_* ;) [10:43] duflu, good luck [10:43] * duflu rolls eyes at those identifiers [10:43] we'd snatch the terminal away from plymouth, if it's still active :P [10:43] RAOF, so in an ideal world, plymouth would just be a mir client, right? [10:43] Correct! [10:44] meh lets see if it works.. [10:44] mlankhorst: Can we just nuke the whole VT subsystem? [10:48] RAOF, would disconnecting from the controlling tty for Mir help here? [10:49] lets see if this works... [10:49] tvoss: when touching the modes of the controlling tty, you want to not be attached to the tty? [10:49] mlankhorst, random idea :) [10:52] I guess not touching the tty at all could work though :p [10:53] * tvoss mutters something about process group leaders and setsid [11:05] alf__, I set the status of https://code.launchpad.net/~thomas-voss/mir/fix_process_waitpid_approach_to_correctly_setup_tracing/+merge/176367 [11:05] back to needs review [11:05] I'm quite sure I can fix the heisenbug :) [11:09] tvoss: actually it might need setsid for this to work correctly.. [11:11] is unity-system-compositor run as root? [11:11] mlankhorst, I think so [11:12] tvoss: as you like, I figured that since this MP was not related to the problem that cause the failure, we might as well merge it [11:13] mlankhorst: Yes, u-s-c is run as root. [11:13] blergh, looks like we need to do setpgid, setsid, before opening console [11:14] after that when /dev/tty is opened it automatically becomes ours, or in the worst case we need to claim it for ourselves [11:15] alf__, fair point, I will repropose under a different name [11:25] I now know more about job control than I cared for :p [11:41] tvoss: I'm off to bed; I've not yet managed to run a fully instrumented stack, so I'm not sure what I'll find. [11:44] RAOF, ack, thanks [11:45] meh got a fix, I think [11:46] http://paste.debian.net/18230/ [11:47] the TIOCSCTTY needs to be uncommented if the setsid is not enough.. [11:50] but it's kind of rude since it means snatching the tty away from someone else :p [11:54] mlankhorst, well, that's the consequence of our plymouth dance, right? :) [11:54] I guess so, what is the sleep for btw [11:54] it seems to work fine without [11:55] mlankhorst, didrocks was seeing some races iirc :) didrocks ^? [11:58] apart from some gpu stall everything works fine I guess [11:58] and the stall might be related to changes in my own tree [12:02] meh the remainder seems to be related to my card being flaky [12:05] mlankhorst, \o/ [12:05] mlankhorst, wanna come up with an mp? [12:07] what branch is base? [12:08] mlankhorst, trunk, bzr branch lp:mir [12:08] ok [12:12] lets see if this works [12:17] alf__, didrocks https://code.launchpad.net/~thomas-voss/mir/fix_process_waitpid_approach_to_correctly_setup_tracing/+merge/176367 [12:17] hm, I need a better git-bzr === JoseeAntonioR is now known as jose [12:30] mzanetti, could you retrigger CI for https://code.launchpad.net/~thomas-voss/mir/fix_process_waitpid_approach_to_correctly_setup_tracing/+merge/176367 [12:30] ? [12:30] didrocks, you around? [12:30] tvoss: sure. If you want I can give you permissions to retrigger jobs [12:31] mzanetti, I have, still need to setup my vpn :) [12:31] again :) [12:31] tvoss: actually, in this case its enough to re-set the MR to "Approved" and Jenkins will pick it up again [12:32] mzanetti, top-state? [12:32] tvoss: yeah [12:32] tvoss: back now [12:32] didrocks, https://code.launchpad.net/~thomas-voss/mir/fix_process_waitpid_approach_to_correctly_setup_tracing/+merge/176367 [12:33] didrocks, that's not the usc adjustment [12:33] ok, looking for the additional commit [12:35] tvoss: ok, a little bit complex. What I would suggest is that we get the ATI fix first, then, having that running (with the workaround) a couple of day, and then, removing the sleep workaround, thoughts? [12:36] didrocks, not sure I do get you :) the mr I pasted is not connected to the ati issue ;) [12:36] tvoss: right, what I meant is: [12:36] let's not try to remove the race workaround for now [12:37] your fix is to avoid this issue, right? ^ [12:37] didrocks, where do you see that I remove it? [12:37] nope :) [12:37] look I don't think that this is ready for universe if it requires a sleep workaround.. [12:37] didrocks, mlankhorst might have a fix for the sleep workaround [12:37] tvoss: ah, I thought the waitpid would help that case as well, but maybe not enough context in the diff and it would be better than I download the whole file :) [12:38] ah good ;) [12:38] didrocks, yeah, this should fix the armhf races [12:38] but I would suggest that we keep the sleep for a couple of days (even if we have the fix) [12:38] to get things flowing [12:38] and then, trying to removing it and testing several rounds [12:39] didrocks, for disabling the input: can we pass additional command-line arguments to usc via lightdm? [12:40] tvoss: it seems to be possible, you just can't use shell expansion or && for instance [12:40] but command --option seems to work [12:40] (as "strace unity-system-compositor" worked) [12:41] didrocks, okay, then you can just pass --enable-input=false to usc :) [12:42] tvoss: this is already implemented? [12:42] didrocks, yup [12:42] hum, grep isn't my friend [12:42] didrocks, usc uses mir's DefaultServerConfiguration, which in turn respects that command-line option [12:42] ah ok ;) [12:43] didrocks, you need to fgrep in mir [12:43] yeah, makes sense [12:43] src/server/default_server_configuration.cpp [12:43] indeed, saw it :) [12:45] tvoss: https://code.launchpad.net/~didrocks/unity-system-compositor/fix-for-ati/+merge/176674 [12:45] I'll then rebuild once in trunk and ensure with multiple test runs it's reliable [12:46] and again that needs fixing too :P [12:48] https://code.launchpad.net/~mlankhorst/mir/setsid/+merge/176676 [12:50] didrocks, mind filing a bug against usc to make sure that we reenable hw pointer functioanlity shortly? [12:50] tvoss: sure [12:50] didrocks, thx [12:51] I don't think papering around it is a good thing though, that bug should be fixed first [12:51] mlankhorst: we have deadlines as well, we can't be idealistic when working on time constraints [12:51] as long as bugs are logged in, I don't think we should hold off [12:52] if we know that the workaround is reliably working [12:52] yeah but you want to land a random git snapshot of mesa, some xorg patches and some other stuff and then put mir in universe? [12:52] mlankhorst: mir will be in main I guess [12:52] to be able to build xorg [12:52] as it's a build-dep, right? [12:52] yes [12:52] so Mir in main, but not enabled by default [12:53] just a technology snapshot to get people trying it [12:53] and if it's in main it means I have to support it, including the mir bits. So open bugs that are not understood become a lot more important to me then.. [12:54] Does anyone know how I change the resolution in xmir? xrandr doesn't work [12:54] mlankhorst: you're welcome to give a hand to properly resolving them promptly consequently [12:54] tvoss: https://bugs.launchpad.net/mir/+bug/1204505 [12:54] Launchpad bug 1204505 in Mir "unity-system-compositor needs to have hw pointer functionality enabled back" [Undecided,New] [12:55] didrocks, thx [12:55] tvoss: not sure how you want to prioritize it [12:55] didrocks, not sure yet, put it high, please [12:55] doing so [13:11] Sarvatt: I tried openarena with vblank_mode=0 in xmir, it still was a lot faster than x [13:12] bregma, ping [13:12] tvoss, hi [13:14] tvoss: thank for all your help overnight! [13:15] bregma, I looked into the acceptance tests, input-related ones specifically, and came up with an MP [13:15] https://code.launchpad.net/~thomas-voss/mir/fix_process_waitpid_approach_to_correctly_setup_tracing/+merge/176367 [13:15] robotfuel: if that weird "better on xmir than x" only happening on ati gpu ? or e.g. on my intel i did not see this...i saw a 10% drop [13:15] bregma, it contains a pipe-based cross-process sync appraoch and adds a timeout to wait_for_termination [13:15] kgunn: yes this is only ati [13:15] robotfuel: wondering if its related to ati video driver [13:16] tvoss, will it handle the case where a server child process is waiting for a client child process and the client child process exits without sending a synch message? [13:16] * kgunn wonders if intel is vsync'ing properly...and ati is unhinge from vsync [13:16] kgunn: we also can't to xmir benchmarks at 800x600 until this bug is fixed https://bugs.launchpad.net/mir/+bug/1196239 [13:16] Launchpad bug 1196239 in Mir "Cannot change display resolution" [Critical,Triaged] [13:17] kgunn: we can get the default resolution for the monitor though [13:18] robotfuel, that's fine for now [13:19] robotfuel: hmmm & that bug is only on ati as well correct ?...again, i get different #s on my intel when i run 600x800 vs native res, meaning...my intel numbers all look sane [13:20] kgunn: it might be, intel isn't working for me right now, it has the driver bug [13:21] kgunn: can you delete xserver-xorg-video-intel package version 2:2.21.9+xmir5870-1~saucy1 from the mir-team/system-compositor-testing ppa? [13:22] kgunn: the 0~saucy1 driver is suppose to work [13:23] robotfuel: lemme see [13:28] tvoss: so, robotfuel asked for me to roll back intel driver to 0~saucy1....but before i venture off, do you know why raof manually updated it ? do you have some context ? (is this for sna ?) [13:29] kgunn, I actually copied it over, it's the driver with sna enabled [13:29] robotfuel, are you sure that you have the ppa pinned? the driver is working perfectly fine here [13:31] robotfuel: confirmed...its working on mine for past few days as well [13:31] i was tvoss guinea pig & just left it installed [13:42] tvoss: kgunn https://bugs.launchpad.net/xmir/+bug/1203776 a lot of people have a problem with the 1~saucy driver [13:42] Launchpad bug 1203776 in XMir "X crashes w/ latest xserver intel driver from System Compositor Testing PPA" [Undecided,New] [13:43] robotfuel, are we sure that those people did pin the ppa correctly? [13:43] robotfuel, can you try the intel driver from staging real quick on the machine? [13:44] tvoss: I'll try the one from the staging ppa, RAOF's looked at the bug and verified it. [13:45] robotfuel, ack and thx [13:45] tvoss: ok, unity-system-compositor starts and hang (remember that it's with Mir trunk rebuilt from the last couple of hours) [13:45] tvoss: dm_connection_start [13:45] Failed to read header [13:46] didrocks, dm_connection talks to lightdm [13:46] robotfuel, if your issue is fixed with the intel driver, I will copy it over to the testing-ppa [13:46] kgunn, ^ [13:47] tvoss: new xorg-server in distro… [13:47] I bet that's it [13:47] * didrocks looks at the version [13:47] argh [13:49] tvoss: didrocks http://10.97.2.10:8080/job/utah-xmir-troubleshooting/3/artifact/results/dpkg-list.log has the versions of everything installed when the xorg crash happens [13:49] tvoss: yeah, I bet it's the xorg issue [13:49] tvoss: I'll just apt-get source the old one [13:49] didrocks, for the dm_connection thingy? [13:49] and update with it [13:49] tvoss: yeah, it's a consequence [13:50] xorg doesn't have -mir option [13:50] didrocks, ack [13:50] didrocks, ah ... [13:50] so, /me apt-get source, fake a bump changelog and reupload to daily-buid-next ppa [13:51] mlankhorst: would be nice to coordinate with us and not make the whole thing more painful :p [13:53] didrocks: so we're not dead yet, once you update daily-build-next ppa we get another shot at tvoss "disable input" for the ati bug? [13:54] kgunn: right [13:54] kgunn: I have faith, his fix in mir directly worked with multiple runs [13:54] kgunn: I think if the option in unity-system-compositor is correctly wired up, it shouldn't make a difference and should pass as well [13:54] didrocks: that's good news... [13:54] thanks [13:55] Morning edge people [13:57] mlankhorst: actually, it was doko on that one… [14:00] robotfuel, did you install the driver, yet? [14:01] tvoss: no not yet, I'll do it now. [14:02] robotfuel, ack [14:07] alf__: ping [14:10] tvoss: FYI the drivers in the latest drivers staging ppa failed to build https://launchpad.net/~mir-team/+archive/staging/+packages [14:12] greyback: pong [14:12] alf__: hey, the snapshot API is working great, thank you [14:14] greyback: Great news! Thanks for letting me know. [14:14] alf__: I've one question however. I grab a snapshot just after the application surface is created, which is a touch too early as I guess the application hasn't drawn to it yet (i.e. I get black snapshot). Would there be a way to detect if an app has actually drawn to it's surface [14:14] alf__: this is nothing at all major (for now I just delay snapshot with a timer), but would be nice for later [14:15] greyback, I think we should postpone that discussion until we have cleaned the scenegraph-conglomerat within mir [14:16] tvoss: the lastest successful build from the staging ppa is already installed on the system. It doesn't work [14:16] greyback: We have such a mechanism internally, but I don't think it is exposed in any way to the shell. [14:22] alf__: I see. I'll keep it in mind. I might log a bug for it. Thanks! [14:23] greyback: np [14:38] tvoss: I have some other intel systems that didn't have an xorg crash [14:38] tvoss: I am retrying to see if it's a race condition. [14:38] robotfuel, ack [14:45] kgunn: resolution changes do work on intel, not on radeon. :) [14:46] robotfuel: i am so frustrated with the ati... [14:46] :-/ [14:59] didrocks, status? [14:59] tvoss: 3 runs until now, it's all green [14:59] tvoss: the xmir crash on intel is race condition [14:59] tvoss: I'm waiting for the 4th to finish [14:59] robotfuel, where? [14:59] to send an email :) [14:59] didrocks, ack and thx [14:59] tvoss: yw! thanks to you! [15:01] tvoss: https://bugs.launchpad.net/xmir/+bug/1203776 [15:01] Launchpad bug 1203776 in XMir "X crashes w/ latest xserver intel driver from System Compositor Testing PPA" [Undecided,New] [15:03] robotfuel, no, I meant where in the code ;) [15:03] tvoss: I haven't looked in to it. [15:05] robotfuel, okay, thx [15:05] Hi all. I maintain Chromium browser, and I received a pointer from upstream to a doc about their efforts to abstract some of the display interface. We may find it interesting. https://sites.google.com/a/chromium.org/dev/developers/design-documents/ozone [15:08] qengho, hey there :) [15:08] tvoss: yo. [15:11] qengho, I recently read it, quite interesting :) [15:12] alf__, revno 881 works better: I see the mouse pointer but I can't move it [15:15] tvoss: Thanks. [15:16] qengho, thanks for keeping us posted [16:15] bregma, ping [16:26] tvoss, pong [16:26] bregma, so my local testing reveals some issues under valgrind, still trying to digest all of the information [16:28] .... [16:28] bregma, thought I would handover, as your mail suggested to me that you are looking into the issue, too [16:29] sure === om26er is now known as om26er_afk === om26er_afk is now known as om26er [17:46] kgunn, ping [17:48] kdub: pong [18:53] lol...whoops [18:53] I just found a unit-test file which is missing from cMakeLists.txt [18:53] after spending 5 minutes like oh god how does this compile [18:53] do I even understand C++ [18:53] what is happening [18:53] etc [18:53] haha [18:54] (missing from CMakeLists in trunk) [18:54] for who knows how long [18:54] because the API it uses is quite old [18:54] thats ok though its a lame test [18:54] *makes new branch* [18:55] I wonder if I should write a failing test that all our test files are built :p [19:04] omg [19:04] more dead files [19:04] this is embarassing -.- [19:05] which tests? [19:08] kdub: test_android_input_registrar [19:08] and mock_input_configuration.h which it includes [19:08] what [19:08] its been this way for at least [19:08] 3 months [19:08] because Ir emember I rebuilt the input configuration [19:08] when I still lived at my old place [19:08] we could use bzr blame but it's almost certainly my fault so [19:08] :p [19:09] ah, i thought you said another registrar test that I was sure was working lately :) [19:59] I hate using droidinput::Vector [19:59] s/hate/have a strong distaste [20:11] https://code.launchpad.net/~robertcarr/mir/support-monitor-input-channels/+merge/176775 whee [20:12] good news, unity is done [20:12] *closes eyes and begins to sleep* [20:12] :p [20:16] racarr, droidinput::Vector can't be as bad as writing new classes that support android::sp :) [20:17] kdub: Ah, android::sp [20:18] you know the input stack still isnt the most beautiful code [20:18] but we have come a long way since [20:18] android::sp in DefaultServerConfiguration [20:18] XD [20:36] oh yeah, much better now :) [20:36] mir on the whole is much better [20:36] remember back in the day, when we wrapped std::thread/mutex/chrono with boost? :) [20:56] kdub: Oh god [20:56] that led to the most fucked up compiler errors. [20:57] I just remember, coming on to the Mir team, in the past I had been a perpetual C++ skeptic but I was like [20:57] ok well I guess if they are doing C++ carefully and the right way it seems pretty good and well lets try it [20:57] then I ran in to some stuff from the std::thread stuff and mir::std and I was just like [20:57] oh god.... [21:00] Back soon === racarr is now known as racarrlunch [21:24] robert_ancell, ping [21:27] olli, hello [21:27] hey robert_ancell [21:27] quick q, I am trying to understand the new dashboard gema announced recently [21:28] from there it looks like we are building u-s-c without running any tests [21:28] http://91.189.93.67/staging/merger/unity-system-compositor/ [21:29] kgunn, ^ [21:30] olli, u-s-c doesn't have any tests currently [21:30]