[00:25] <Trevinho> beidl: yeah, that's true and that should happen... But it's something I'll try to fix asap
[01:29] <mhall119> is mirscreencast available on i386?
[01:30] <mhall119> nvm, found it
[02:10] <mhall119> hmm, doesn't work though, or I'm doing something wrong
[06:18] <beidl> Trevinho: I'm a detail guy, so that's why I noticed that thing pretty early on, and I'd love if this gets fixed. But I can understand if there are more important things to work on. :)
[07:44] <tsdgeos> i see green
[07:44] <tsdgeos> and don't believe it :D
[07:48] <tsdgeos> Mirv: you there?
[07:59] <mzanetti> greyback: https://code.launchpad.net/~mzanetti/unity-mir/quit-manually-started-procs/+merge/214013
[07:59] <beidl> Trevinho: is Launcher.cpp:DragOutProgress() supposed to get called when dragging the launcher *out* using 4 fingers? because it's not, only when pushing it back to the left to hide it.
[08:11] <tsdgeos> Mirv: if you have time maybe this makes sense to have https://bugs.launchpad.net/ubuntu/+source/qtdeclarative-opensource-src/+bug/1304248
[08:13] <Cimi> greyback, Saviq how can I debug the keyboard not always popping in in the wizard?
[08:13] <Cimi> sometimes I have to restart it, otherwise it doesn't work
[08:15] <Saviq> greyback, bug #1287736
[08:16] <Saviq> Cimi, TBH sounds like wrong z-ordering
[08:22] <Saviq> Cimi, you need a debug-enabled build of libunity-mir1
[08:23] <Saviq> Cimi, so build unity-mir with CMAKE_BUILD_TYPE=debug
[08:23] <Saviq> Cimi, and that will print quite some debug output
[08:24] <Saviq> greyback, we should think about moving to http://blog.qt.digia.com/blog/2014/03/11/qt-weekly-1-categorized-logging/ - I'm tired of non-runtime logging configuration...
[08:24] <Mirv> tsdgeos: probably makes sense, although updating qtdeclarative this late in the cycle tends to raise eyebrows
[08:24] <greyback> Saviq: +100
[08:25] <tsdgeos> Mirv: sure i understand
[08:25] <Mirv> tsdgeos: LP bug would help though in justifying the changelog entry
[08:26] <tsdgeos> Mirv: didn't i already do a LP bug? /me confused
[08:27] <Mirv> tsdgeos: correct! I swiftly moved to the Qt project pages and closed the LP one it seems.
[08:27] <tsdgeos> Mirv: :D
[08:27] <Mirv> ok, I'll try about getting it built and the usual "run all AP:s" run
[08:39] <larsu> Saviq: the sound indicator is supposed to be red for 5 seconds after the last sound has played. It stays red indefintely for you?
[08:39] <larsu> Saviq: is pavucontrol showing any sound sources in the first tab?
[08:43] <Saviq> larsu, looking
[08:43] <Saviq> larsu, yeah it stays permanently red
[08:44] <Saviq> larsu, hmm I have 5 speech-dispatchers... and a firefox audiostream
[08:44] <Saviq> larsu, but nothing's actually playing
[08:45] <Saviq> larsu, killed firefox, s-d, back to normal now...
[08:45] <Saviq> larsu, feel free to mark invalid
[08:45] <larsu> Saviq: are they muted? Otherwise I'm afraid there's not much I can do...
[08:45] <larsu> it's red when pulse reports any active sources
[08:46] <Saviq> larsu, wonder what the definition of "active" is, though
[08:46] <larsu> Saviq: available and not muted?!
[08:46] <larsu> I think ...
[08:47] <Saviq> larsu, I think it's more smart, like is there actually stuff going through
[08:47] <Saviq> larsu, or maybe not
[08:47] <Saviq> anyway, back to grey
[08:47] <seb128> Saviq, do you use java softwares?
[08:48] <larsu> seb128: speech dispatcher seems to have been the problem
[08:48] <seb128> Saviq, the other report we got mentioned that it happens when using java
[08:48] <Saviq> seb128, yeah, but it's not playing sound
[08:48] <seb128> larsu, hum, k
[08:48] <Saviq> seb128, yeah, s-d was the problem it seems
[08:49] <Saviq> greyback, bug #1304257, too
[08:50] <Saviq> mardy, because of ↑ we can't do what you want for the signon ui - Mir doesn't have a quit signal yet
[08:50]  * mardy reads the backlog
[08:50] <Saviq> mardy, just the bug
[08:50] <Saviq> mardy, think you could make it quit on "Back" straight away? and maybe also openUrlExternally so that settings app is brought to front first?
[08:51] <Saviq> mardy, otherwise https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings-online-accounts/+bug/1287736/comments/11 happens
[08:53] <mardy> Saviq: my understanding is that trusted sessions are not too far away, I would wait for them rather then implementing hacks over hacks
[08:54] <mardy> Saviq: by the way, what is a Mir session? Is it analogue to an XCB xonnection or an XCB window?
[08:54] <mardy> *connection
[08:55] <Saviq> mardy, connection
[08:55] <Saviq> mardy, one session can have multiple surfaces
[08:56] <mardy> Saviq: but when the user taps on the "X" button over a window, why quit the session? I would expect that only that window gets closed
[08:56] <mardy> Saviq: the difference is probably irrelevant for the phone, but will be important in the desktop
[08:58] <Saviq> mardy, there is no "windows" on the phone
[08:59] <mardy> Saviq: surface? :-)
[08:59] <Saviq> mardy, every session currently only has one surface
[08:59] <Saviq> mardy, in desktop world, yeah it will just send a quit signal to that window, and the app will do what it considers right for it
[09:00] <Saviq> mardy, but until then we have a 1:1 mapping between sessions and surfaces as greyback said
[09:00] <mardy> Saviq: OK, I was probably misled by the "quit" word
[09:01] <Saviq> mardy, but yeah, for touch pressing X should equal the app shutting down - right now we're just sending SIGTERM (and then SIGKILL, in the case of upstart, after 5s)
[09:17] <tsdgeos> Hmmmm
[09:17] <tsdgeos> anyone knows what _StringException means in http://s-jenkins.ubuntu-ci:8080/job/autopilot-testrunner-otto-trusty/3957/console ?
[09:18] <tsdgeos> that autpilot log looks different that how it looked before
[09:18] <tsdgeos> doesn't it?
[09:22] <Saviq> seb128, so... stuff changed in the datetime settings did they... I have UTC+1 in the settings, but indicator still shows UTC+2
[09:22] <Saviq> seb128, `date` reports the correct time, apparently the indicator service doesn't?
[09:23] <seb128> Saviq, we are speaking about touch/phone?
[09:23] <Saviq> seb128, yes
[09:23] <seb128> Saviq, the indicator is off by an hour compared to the settings/system?
[09:23] <Saviq> seb128, yes
[09:24] <seb128> weird :/
[09:24] <Saviq> seb128, it looks like just the label is wrong
[09:24] <Saviq> seb128, events are in BST I think
[09:24] <seb128> I don't think that code changed recently :/
[09:24] <Saviq> seb128, yeah, events are bst
[09:24]  * Saviq restarts indicator
[09:24] <seb128> seems like an unity8 issue to me :p
[09:25] <Saviq> hmm hmm
[09:31] <Saviq> seb128, dbus-monitor disagrees... http://pastebin.ubuntu.com/7220842/
[09:32] <seb128> Saviq, the time looks fine there?
[09:32] <seb128> Saviq, or are you in London?
[09:32] <Saviq> seb128, I'm in London ;)
[09:32] <Saviq> seb128, see `date` at the bottom
[09:33] <seb128> :-(
[09:33] <seb128> Saviq, cat /etc/timezone?
[09:34] <Saviq> seb128, indeed, not update
[09:34] <seb128> how did you change the tz?
[09:35] <Saviq> seb128, system-settings
[09:35]  * Saviq tries to re-set it
[09:35] <seb128> :/
[09:35] <seb128> we use datetimed
[09:35] <seb128> that smells like another issue with the bindmount hackery to get stuff rw on the ro system
[09:35] <seb128> do you have any datetimed error in the system logs?
[09:36] <Saviq> seb128, must've happened some time ago
[09:36] <Saviq> seb128, resetting to Warsaw and back to London worked
[09:36] <seb128> if you change it again in system-settings, does it work?
[09:36] <seb128> :-(
[09:37] <seb128> the logs might still have an error in you grep
[09:37] <seb128> (they are rotated)
[09:37] <Saviq> seb128, so something broke there, will report again if happens
[09:37] <Saviq> seb128, where am I looking?
[09:38] <Cimi> Saviq, I have another problem, the osk does not touch the bottom edge, it's like 1gu higher (like the panel height)
[09:38] <seb128> Saviq, zgrep timedated /var/log/*.gz ?
[09:38] <Saviq> Cimi, it looks like unity-mir does not recognize the osk surface
[09:39] <Saviq> Cimi, debug-enabled unity-mir will help
[09:39] <Saviq> oh goodness, netsplit
[09:52] <larsu> Saviq: do you mind if gsettings-qml doesn't crash you process anymore when you give it an uninstalled schema?
[09:52] <larsu> Saviq: but instead simply returns invalid for all keys?
[09:53] <larsu> (it's not even printing a warning)
[09:54] <Saviq> larsu, YES PLEASE
[09:54] <Saviq> larsu, ideally there'd be an error / status prop
[09:55] <Saviq> larsu, but I'm fine with it not being there to start with
[09:55] <Saviq> mhr3_, ↑
[09:56] <mhr3_> Saviq, the schema will have a isValid prop, and be false if schema isn't installed
[09:56] <mhr3_> that would be the status
[09:58] <larsu> Saviq: I thought you'd say something along those lines. Thanks!
[09:58] <larsu> mhr3_: approved
[09:59] <mhr3_> larsu, thx, will update my branches to dep on it and land it
[09:59] <mhr3_> larsu, gsettings-qt is on desktop too? ie does it need ffe?
[09:59] <mhr3_> although ultimately it's a bugix :)
[09:59] <mhr3_> bugfix
[10:00] <Cimi> Saviq, can I create a package with debuild and debug?
[10:00] <Saviq> mhr3_, larsu, isValid is rather low resolution data, but I think that's probably fine
[10:00] <Cimi> like
[10:00] <Cimi> CMAKE_BUILD_TYPE=debug debuild will work?
[10:01] <Saviq> Cimi, no, you'd have to change debian/rules to include override_dh_configure or so
[10:01] <Cimi> Saviq, ok
[10:01] <Saviq> Cimi, but if you tell me you're doing that on device and waiting for it to build, I might become grumpy
[10:01] <Saviq> Cimi, it's cross-building just fine
[10:02] <Cimi> Saviq, hello grumpy man!
[10:02] <larsu> mhr3_: yes let's treat it as a bugfix if seb128 is fine with that
[10:02] <Cimi> Saviq, hah
[10:02] <Cimi> I didn't think it was long to build like the system settings
[10:02] <seb128> larsu, wfm
[10:04] <Cimi> Saviq, https://wiki.ubuntu.com/CrossBuilding ?
[10:04] <Saviq> Cimi, and https://wiki.ubuntu.com/SimpleSbuild
[10:04] <Saviq> Cimi, set it all up as per SimpleSbuild, then just mk-sbuild --target=armhf
[10:06] <josharenson> I receive the following error when building unity8 ":CMake Error at CMakeLists.txt:64 (message):
[10:06] <josharenson>   Could not determine plugin installation dir." I've tried exporting SHELL_PLUGINDIR=plugins to no avail. Please advise.
[10:11] <tsdgeos> josharenson: did you run ./run -s ?
[10:12] <tsdgeos> Saviq: i've a fix for the dead areas thing, but looking at the debug output it should still work (i.e the code of the fix is good but should not be needed) so i'm going to investigate a bit moar
[10:16] <josharenson> tsdgeos: fixed.. had to purge the mir-team/staging ppa and re-run config
[10:17] <tsdgeos> good :)
[10:24] <Saviq> tsdgeos, kk
[10:28] <mzanetti> dandrader: http://paste.ubuntu.com/7220995
[10:40] <Saviq> greyback, bug #1304315
[10:41] <Saviq> https://bugs.launchpad.net/ubuntu/+source/unity-mir/+bug/1304315
[10:50] <Cimi> Saviq, wiki is missing something
[10:50] <Cimi> E: 10mount: mount: special device /home/cimi/ubuntu/scratch does not exist
[10:50] <Saviq> Cimi, well, yeah, you have to mkdir that ;)
[10:50] <Cimi> shall I create the dir
[10:50] <Saviq> Cimi, add it to the wiki if you think useful
[10:51] <Cimi> Saviq, it is, because I wasn't sure was the dir missing or "special device"
[10:52] <Saviq> Cimi, yeah ok, although for a mount -o bind, the directory has to be there, is all
[10:52] <Saviq> Cimi, but yeah, add
[11:02] <Saviq> xnox, hey, what's the best way for an if() in CMake that would check if we're cross building?
[11:07] <xnox> Saviq: standard variable is CMAKE_CROSSCOMPILING, if that is TRUE, we are cross-compiling.
[11:07] <Saviq> xnox, yup, found it, thanks
[11:07] <Cimi>  libc6-dev:armhf : Depends: libc6:armhf (= 2.19-0ubuntu3) but it is not going to be installed
[11:07] <xnox> Saviq: and our multiarch cross-compilation machinery does set it.
[11:07] <Cimi> Saviq, did you come across this issue?
[11:08] <Saviq> Cimi, not sure what you did
[11:08] <Saviq> xnox, mir has a MIR_ENABLE_TESTS option, think we should just disable it if crosscompiling in debian/rules?
[11:08] <Cimi> Saviq, mk-sbuild --target=armhf trusty
[11:08] <Saviq> Cimi, looks like an archive issue, let me try
[11:09] <Cimi> Saviq, I rerun update after that
[11:09] <Cimi> Saviq, in fact, but no luck
[11:10] <Saviq> Cimi, trying here
[11:10] <Saviq> Cimi, doesn't matter that you rerun update on your host, everything happens in the chroot anyway
[11:11] <Cimi> Saviq, I updated the package cache
[11:11] <Cimi> but yeah you're right
[11:11] <Cimi> it does that too if I scroll back
[11:16] <Saviq> Cimi, built fine here
[11:16] <Saviq> Cimi, try removing the /var/lib/ thing and try again
[11:17] <Saviq> Cimi, I mean /var/lib/schroot/chroots/trusty-amd64-armhf or so
[11:22] <Cimi> Saviq, I did that
[11:26] <Saviq> Cimi, and still no go?
[11:26] <Cimi> nope
[11:26] <Cimi> Saviq, I did chroot here
[11:27] <Saviq> Cimi, don't
[11:27] <Cimi> schroot -c trusty-amd64-armhf -u root
[11:27] <Cimi> ah ok
[11:27] <Saviq> Cimi, if debootstrap failed, scrap the chroot and try again
[11:31] <Cimi> Saviq, no way :(
[11:31] <Cimi> Saviq, I did
[11:31] <Cimi> sudo rm -r /etc/schroot/chroot.d/*
[11:32] <Cimi> sudo rm -rf /var/lib/schroot/chroots/*
[11:32] <Cimi> re-run
[11:32] <Cimi> and still error
[11:35] <xnox> Saviq: if they are executed, then yeah you should disable them. If they are compile tests (e.g. it's a pass if it compiles) you should compile them.
[11:56] <Cimi> I don't seem to be able to compile with debug
[11:56] <Cimi> I am doing
[11:56] <Cimi> cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_VERBOSE_MAKEFILE=ON .. in my builddir
[11:56] <Cimi> and I cannot see
[11:57] <Cimi> -DNDEBUG while compiling
[12:01] <Cimi> however
[12:01] <Cimi> root@ubuntu-phablet:/home/phablet/unity-mir/build# cmake -L .. | grep CMAKE_BUILD_TYPE
[12:01] <Cimi> CMAKE_BUILD_TYPE:STRING=Debug
[12:19] <Saviq> Cimi, what's -DNDEBUG?
[12:32] <mhr3_> Cimi, NDEBUG is defined to compile *out* all asserts
[12:33] <Cimi> Saviq, how do I see debug now?
[12:33] <Cimi> still have to run the new unity mir with debug, just checking
[12:35] <Saviq> Cimi, just run it
[12:35] <Saviq> Cimi, you'll get debug output in the upstart log
[12:36] <Cimi> Saviq, ok so the debuilt version does not have it
[12:36] <Saviq> Cimi, did you restart the wizard?
[12:36] <Cimi> Saviq, I restarted the device
[12:36] <Cimi> Saviq, for debuild, I edited CMakeLists and I added set(CMAKE_BUILD ...)
[12:37] <Cimi> Saviq, maybe it is overridden?
[12:38] <Saviq> Cimi, should not be
[12:38] <Cimi> weird then
[12:42] <Cimi> Saviq, ok I built a local build as said before
[12:42] <Cimi> Saviq, I even overwrite in /usr/lib/armsomething
[12:42] <Saviq> you did what?
[12:42] <Cimi> Saviq, I ran the wizard, no extra debug
[12:42] <Cimi> Saviq, http://paste.ubuntu.com/7221424/
[12:44] <Cimi> oh no I have something
[12:45] <Cimi> InputArea::geometryChanged (this=0xae6e4140)
[12:45] <Cimi> it's just not enough
[12:45] <Cimi> @unity someone can help me with osk debugging and mir?
[12:47] <dandrader> Cimi, I can try
[12:47] <Saviq> Cimi, read SurfaceFactory::create_surface
[12:47] <Saviq> Cimi, see what it *should* debug
[12:47] <Saviq> Cimi, and what it doesn't
[12:48] <Cimi> creating surface at (0, 0) with size (768, 1280) with title 'System Settings Wizard'SurfaceFactory::create_surface
[12:48] <Cimi> creating surface at (0, 0) with size (768, 1280) with title 'System Settings Wizard'SurfaceFactory::create_surface
[12:48] <Saviq> Cimi, here's your problem
[12:48] <Cimi> Saviq, I should see osk?
[12:49] <Saviq> Cimi, no, you should see Qml Phone Shell
[12:49] <Saviq> Cimi, so that it's the bottom-most surface
[12:49] <Saviq> Cimi, basically your window title is wrong
[12:49] <Cimi> Saviq, I should really fake to be the shell then
[12:49] <Saviq> Cimi, yes, Gerry told you that befoer
[12:51] <Cimi> Saviq, I thought he was referring to the general calls to unity-mir, fine
[12:51]  * Cimi tries
[12:54] <paulliu> Cimi: https://code.launchpad.net/~paulliu/unity8/zoomImage/+merge/207941
[12:56] <Cimi> paulliu, better thanks!
[12:56] <Cimi> paulliu, few things
[12:56] <Cimi> paulliu, move the data function of test_pinch just before test_pinch(data)
[12:57] <paulliu> Cimi: ok.
[12:57] <Cimi> paulliu, I'd add a couple of extra data here, maybe a pinch out, and an extra pinch in
[12:57] <Cimi> paulliu, jus the data
[12:57] <Cimi> so we test more cases
[12:57] <Cimi> mzanetti, do you remember what you said about testing pinch to zoom here? ^
[12:59] <paulliu> Cimi: ok..
[12:59] <mzanetti> Cimi: hmm... iirc I just said that it could make sense to have a test for the pinching
[13:07] <Cimi> Saviq, on the crossbuild topic
[13:07] <Cimi> I did sudo rm -r /etc/schroot/chroot.d/* and sudo rm -rf /var/lib/schroot/chroots/*
[13:07] <Cimi> Saviq, I rerun it but I always have this error
[13:08] <Cimi> Saviq, which archives do you have in /var/lib/schroot/chroots/trusty-amd64-armhf/etc/apt/sources.list ?
[13:08] <Saviq> Cimi, can't touch this ;P
[13:09] <Saviq> Cimi, why would you want to touch that?
[13:09] <Cimi> Saviq, to see if you have polish mirrors
[13:09] <Saviq> Cimi, probably not
[13:09] <Saviq> Cimi, nope, global ones - but that's fine, unless you really know about one that's faster for you
[13:10] <Cimi> Saviq, was not for this
[13:10] <Saviq> Cimi, what do you mean?
[13:10] <Cimi> Saviq, maybe you had polish and they haven't been rsync'ed
[13:10] <Saviq> Cimi, well, I'm in the office
[13:10] <Saviq> Cimi, so I'm definitely behind some cache
[13:11] <Cimi> I can try in a different machine
[13:11] <Saviq> Cimi, did a amd64 chroot work?
[13:11] <Cimi> Saviq, I haven't tried amd64
[13:11] <Cimi> Saviq, I am already amd64, shall I try i386?
[13:11] <Cimi> or saucy
[13:12] <Saviq> Cimi, no, try amd64
[13:12] <Saviq> Cimi, it's a chroot, it doesn't care what you have locally
[13:13] <Cimi> trying saucy armhf, will do amd64 soon
[13:13] <Cimi> I have 125Mb/s here, no problem in downloading stuff B-)
[13:15] <Cimi> Saviq, saucy works
[13:15] <Cimi> Saviq, so it's issue with the archive
[13:16] <Saviq> Cimi, yeah I thought so
[13:16] <Saviq> Cimi, still, apt-cacher-ng FTW
[13:16] <Saviq> Cimi, you'll have 1Gb ;)
[13:18] <Cimi> Saviq, 4Gb
[13:18] <Cimi> Saviq, I have SSD here ;)
[13:22] <Cimi> Saviq, works for trusty too now, definitely temp issue
[13:30] <Cimi> Saviq, then to build for this?
[13:31] <Cimi> Saviq, the recommended command after creating the schroot was different than the one in the wiki
[13:32] <Saviq> Cimi, well, I was thinking networked
[13:33] <Saviq> Cimi, "recommended command"?
[13:33] <Saviq> Cimi, again, update the wiki, it's a wiki after all :)
[13:33] <Cimi> Saviq, I am running the one on the wiki
[13:33] <Cimi> after I checked man sbuild
[13:34] <Saviq> Cimi, not sure which one you mean :)
[13:34] <Cimi> Saviq, basically I run debuild, then sbuild --build=amd64 --host=armhf -d trusty ubuntu-system-settings....dsc
[13:34] <Saviq> Cimi, ahg
[13:34] <Cimi> and it's fetching deps etc
[13:34] <Saviq> Cimi, same thing
[13:35] <Saviq> Cimi, --build -d just "compiles" a chroot name
[13:35] <Saviq> Cimi, i.e. --build=amd64 -d trusty == -c trusty-amd64-armhf
[13:35] <Cimi> let's hope it does -j8 without having to specify
[13:35] <Saviq> Cimi, it doesn't
[13:35] <Saviq> Cimi, unless you have DEB_BUILD_OPTIONS added
[13:35] <Cimi> ouch
[13:36] <Saviq> exported, that is
[13:36] <Saviq> Cimi, but it's not sbuild's "fault"
[13:39] <tsdgeos> Saviq: who reviews https://code.launchpad.net/~aacid/unity8/delegateRangeNeedsOriginY/+merge/214757 ?
[13:40] <Cimi> Saviq, export DEB_BUILD_OPTIONS=parallel=8  ?
[13:43] <Cimi> Saviq, greyback nope, still no luck with the osk not being at bottom of the screen
[13:44] <Saviq> tsdgeos, damn ;)
[13:44] <Saviq> tsdgeos, the old origin...
[13:44] <tsdgeos> yeap
[13:44] <Cimi> creating surface at (0, 0) with size (768, 1280) with title 'Qml Phone Shell'SurfaceFactory::create_surface
[13:44] <greyback> Cimi: did you turn on debug output from unity-mir? Build with "cmake -DCMAKE_BUILD_TYPE=Debug" and install & restart
[13:44] <tsdgeos> Saviq: i never thought we'd need it in here since the grids are always static, but since we're jumping around in the view it seems we do indeed need it
[13:44] <Cimi> greyback, I did
[13:45] <Cimi> greyback, I have debug in /home/phablet/.cache/upstart/ubuntu-system-settings-wizard.log
[13:45] <Saviq> greyback, does it then say "Shell depth"?
[13:45] <Saviq> greyback, and does it say "OSK depth" for the maliit surface?
[13:46] <Saviq> Cimi, I meant you ↑↑
[13:46] <Cimi> I cleaned the file, rerunning
[13:46] <greyback> Cimi: please pastebin the file
[13:46] <Cimi> greyback, that's exactly why I cleaned the file :)
[13:53] <Saviq> elopio, does that say anything to you https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty/3957/testReport/junit/unity8.shell.tests.test_emulators/DashEmulatorTestCase/test_open_applications_scope_Desktop_Nexus_4_/ ?
[13:53] <Saviq> brb
[13:57] <Cimi> Saviq, greyback http://paste.ubuntu.com/7221698/
[13:58] <Saviq> Cimi, there's no debug there
[13:58] <Cimi> Saviq, greyback maliit is start by the upstart job before
[13:58] <Cimi> Saviq, ah
[13:58] <Saviq> Cimi, hmm or wait
[13:59] <Saviq> Cimi, which upstart job, how is it started/
[13:59] <Saviq> Cimi, it can't be started before unity8
[13:59] <Saviq> or well, before the mir server
[13:59] <Cimi> Saviq, http://paste.ubuntu.com/7221706/
[13:59] <Cimi> Saviq, so it doesn't play
[14:00] <Saviq> Cimi, that's why it's broken
[14:00] <Cimi> Saviq, I need to start maliit inside the main.cpp?
[14:00] <Saviq> Cimi, no
[14:00] <Saviq> Cimi, you need to start it on welcome wizard started
[14:00] <Saviq> Cimi, so that welcome wizard is ready
[14:00] <Cimi> Saviq, edit maliit-server upstart file?
[14:00] <Saviq> Cimi, short term
[14:01] <Saviq> Cimi, move the "start maliit-server" to post-start script
[14:01] <Cimi> Saviq, or running it from main.cpp?
[14:01] <Saviq> Cimi, NO
[14:01] <Cimi> system("start maliit-server")
[14:01] <Saviq> _NO NO NNONN ON ONO NON ON ON ON O|
[14:01] <Cimi> ahahah
[14:01] <Saviq> Cimi, you will really get a slap for proposing such a thing
[14:02] <Saviq> Cimi, start it in post-start, stop it in pre-stop
[14:02] <Cimi> Saviq, editing the upstart job of maliit doesn't seem nice to me either
[14:02] <Cimi> Saviq, but what guarantees me that post-start is after mir initialization?
[14:02] <Saviq> Cimi, it's much nicer, really - only it should be a generic event, but for a short-term solution the above will work
[14:03] <Saviq> Cimi, "expect stop" will
[14:03] <Saviq> Cimi, so you need to add that too
[14:03] <Saviq> Cimi, you really need more there, too, how does maliit-server know which mir socket to connect to
[14:03] <Saviq> Cimi, I'm rather sure it tries to connect to the system compositor one
[14:04] <Saviq> Cimi, which is not good
[14:04] <Saviq> Cimi, you need to copy most of the unity8 job
[14:04] <Saviq> Cimi, re: mir sockets and such
[14:04] <Saviq> mterry, can you help Cimi with that ↑?
[14:04]  * mterry reads
[14:05] <Cimi> this is current maliit job http://paste.ubuntu.com/7221724/
[14:05] <mterry> Cimi, you are trying to make maliit work nice with the wizard?
[14:05] <Cimi> mterry, yup
[14:05] <Saviq> Cimi, leave maliit for now
[14:05] <Cimi> ok
[14:06] <mterry> Cimi, don't stress about it.  My plan was to integrate it into the unity8-greeter-wrapper launch script.   Which starts init & maliit
[14:06] <Cimi> mterry, well. I want to have it working now
[14:07] <mterry> I've been meaning to get the greeter & mir branches stabilized so I can add that support
[14:07] <mterry> Cimi, OK.  Did I see that you had a short term solution above?
[14:08] <Saviq> mterry, remember maliit needs to be started *after* mir is ready
[14:09] <Saviq> mterry, I think that leaving this to the upstart jobs is actually the right way
[14:09] <Cimi> mterry, we have     if (system("stop maliit-server") != 0) {} in main.cpp
[14:09] <Cimi> mterry, why we're not using upstart for that?
[14:09] <mterry> Saviq, still?  Weird.  I remember it working for me in testing with the split greeter
[14:09] <Saviq> mterry, i.e. maliit-server should have start on start-keyboard; stop on stop-keyboard or so
[14:09] <Saviq> mterry, otherwise it tries to connect to the system compositor
[14:10] <mterry> Saviq, I don't remember it having those events, but if it does, that's easy enough
[14:10] <Saviq> mterry, it doesn't, it should ;)
[14:10] <mterry> Saviq, well if your concern is just MIR_SOCKET being set, then my script handles that
[14:10] <Saviq> mterry, not just that
[14:10] <Saviq> mterry, then, if that socket isn't ready
[14:10] <Saviq> mterry, there's nothing to connect to
[14:10] <Saviq> mterry, and sure, it might even die and respawn
[14:11] <mterry> humph...  maliit-server should be smarter
[14:11] <Saviq> mterry, it's not maliit
[14:11] <Saviq> mterry, it's libmirclient
[14:11] <mterry> humph, libmirclient should allow for waiting
[14:11] <Saviq> mterry, file a bug
[14:11] <elopio> Saviq: it says nothing at all. That exception doesn't come from autopilot. Maybe dbus failing and then failing to attach the trace?
[14:12] <mterry> Cimi, I believe because I didn't want to edit any other upstart jobs to support the wizard (especially since running in user session was temporary)
[14:12] <Saviq> elopio, no idea ;|
[14:12] <Saviq> mterry, ok so that's an important data point
[14:12] <Saviq> mterry, when / where is the wifi wizard supposed to run?
[14:13] <Cimi> mterry, but we could have done this inside the wizard upstart job, no?
[14:13] <mterry> Saviq, before the user sees anything.  Which for convenience sake, probably means in the same session as the greeter the first boot
[14:13] <Cimi> mterry, inside the post-stop script
[14:14] <Saviq> Cimi, post-start
[14:14] <mterry> Cimi, yeah, but I was trying to avoid a "gap" between processes where the screen went black
[14:14] <mterry> Cimi, USC in split greeter mode handles that more gracefully by having a spinner
[14:14] <Saviq> mterry, ok then, which mir socket did you think the OSK would connect to?
[14:14] <mterry> Cimi, so that's a problem that will go away
[14:15] <mterry> Saviq, well that was an open problem we were discussing the other day.  Cimi, where did we land on that?  I think making the wizard a mini-server?
[14:15] <Cimi> Saviq, in the current code, we have system("stop maliit-server") at qt ::quit
[14:15] <Cimi> Saviq, it's a different thing
[14:15] <mterry> Cimi, right, because at least a while ago, maliit-server couldn't handle having two masters (two shells it talked to)
[14:15] <Saviq> mterry, yes, hence, maliit-server needs to start/stop when wizard is ready / before it's stopping
[14:15] <Saviq> mterry, it's not meant to
[14:16] <Saviq> mterry, what two shells? greeter and wizard?
[14:16] <mterry> Saviq, well, two processes yeah
[14:16] <Saviq> mterry, don't they run under different users?
[14:16] <mterry> Saviq, agreed that maliit-server needs some bring-up / bring-down around the wizard
[14:16] <Saviq> mterry, so basically two separate maliit-servers?
[14:17] <mterry> Saviq, I'm getting a little confused on whether we are talking about current user-wizard or future greeter-wizard
[14:17] <Cimi> Saviq, mterry how does this look to you?
[14:17] <Cimi>  http://paste.ubuntu.com/7221764/
[14:18] <Saviq> mterry, whatever the welcome wizard Cimi is working on?
[14:18] <elopio> Saviq: it seems autopilot there is not running with -v. That should give more info.
[14:18] <Saviq> Cimi, UNITY_MIR_SOCKET - don't use that
[14:18] <mterry> Cimi, what's wrong with the current in-code way of doing that?
[14:18] <MacSlow> mterry, hey there... does our new-gl-screen branch for u-s-c have  a new testing silo-ppa?
[14:18] <MacSlow> mterry, the old 004 one is still dead I assume
[14:18] <mterry> MacSlow, then we moved to 002 and now we got kicked out of that one
[14:19] <Saviq> mterry, you don't know when mir is ready
[14:19] <Saviq> mterry, in main
[14:19] <Saviq> mterry, hence expect stop
[14:19] <Saviq> but crap...
[14:19] <Cimi> Saviq, http://paste.ubuntu.com/7221778/ ?
[14:19] <MacSlow> mterry, hm... I don't want to push my last commits untested.
[14:19] <mterry> Saviq, the welcome wizard cimi is working on is the same wizard, but as of this second, it's designed to run in user's session before unity8 appears.  But once we split greeter, we need to move it into the greeter session
[14:19] <Saviq>     if (qgetenv("UPSTART_JOB") == "unity8") {
[14:19] <Saviq>         raise(SIGSTOP);
[14:20] <Saviq> Cimi, you'd have to make that ↑ include the wifi wizard
[14:20] <Cimi> ok
[14:20] <mterry> So all this upstart integration stuff will need to be adjusted a bit.  Which is why I haven't stressed about making it perfect
[14:20] <Saviq> Cimi, that's in unity-mir
[14:20] <Saviq> mterry, well, sure, Cimi's just fighting with it a few days now
[14:21] <Cimi> fight fight fight
[14:21] <mterry> Fair.  I'm just saying, don't shy from doing things the short-term way
[14:21] <Saviq> mterry, and when it moves to the greeter session, it's the greeter that's gonna be the mir server will it?
[14:21] <Saviq> mterry, and handle maliit and all?
[14:21] <mterry> Saviq, no...  Probably not.  Because we don't want the greeter to appear before this wizard
[14:21] <mterry> Saviq, so we still need wizard to handle OSK itself
[14:21] <Cimi> Saviq, good thing I am learning LOT
[14:21] <Saviq> mterry, so right, it needs to be a mini-server still
[14:21] <mterry> Saviq, yar
[14:22] <Saviq> mterry, unless u-s-c will composite OSK with session, which I don't think is desirable?
[14:22] <mterry> Saviq, that was another way we could go, but that support would only be used by the wizard.  Didn't seem useful enough to warrant complexity
[14:22] <Saviq> mterry, yeah, ok, so welcome wizard will still run at its own job, won't it?
[14:23] <Saviq> we probably need to change the UPSTART_JOB check for a MIR_EXPECT_STOP or something
[14:24] <mterry> Saviq, well.  The greeter's relationship with upstart isn't so clear cut as unity8
[14:24] <Saviq> so that we can use it in different clients
[14:24] <Saviq> mterry, greeter isn't launched by upstart?
[14:24] <mterry> Saviq, not exactly.  We have a wrapper script that starts upstart and the greeter and points them at each other.  And I envisioned probably sticking the wizard launch bits in there too
[14:25] <mterry> Saviq, the reason for that setup is that lightdm keeps some sockets open to talk to the greeter with
[14:25] <mterry> Saviq, so we can't just tell lightdm to launch init, because those sockets won't get to the greeeter
[14:26] <mterry> not sockets
[14:26] <mterry> sorry, fds
[14:26] <Saviq> mterry, mhm
[14:26] <Saviq> mterry, so yeah, in that case it'd have to be the wrapper script that waits for SIGSTOP
[14:27] <Saviq> mterry, before starting maliit
[14:27] <Cimi> btw how do I re-generate .dsc files and source without re-running whole debuild?
[14:27] <Saviq> whether it'd be the greeter or the wizard
[14:27] <Saviq> Cimi, you don't need .dsc
[14:27] <Saviq> Cimi, and well, you go debuild -S
[14:27] <Saviq> Cimi, but just do sbuild in source tree
[14:27] <Cimi> Saviq, to build crossplatform
[14:27] <Cimi> ok
[14:27] <mterry> Saviq, well...  right now maliit just starts (and probably dies and restarts).  For making it Right, we could have wizard/greeter just kick off a 'start maliit-server' somewhere
[14:27] <Saviq> Cimi, sbuild will do it for you, just don't pass a path to .dsc, run in source tree
[14:28]  * MacSlow hates to say it...
[14:28] <Saviq> mterry, it's not even that it dies/restarts
[14:28] <MacSlow> ... but I can't connect to mumble still :/
[14:28] <Saviq> mterry, the problem now is that it runs, but connects to u-s-c
[14:28] <Saviq> mterry, AFAICT
[14:28] <mterry> MacSlow, I see you in the room...
[14:28] <mterry> Saviq, naw naw.  The wrapper script sets up MIR_SOCKET for it
[14:29] <Saviq> mterry, oh ok, then it doesn't seem like it restarts
[14:29] <mterry> Saviq, since it knows what the socket the greeter will use
[14:29] <MacSlow> mterry, here I only see the mumble process eating up on of my CPU-cores and the its window is greyed out
[14:29] <Saviq> Cimi, what does ~/.cache/upstart/maliit-server.log say?
[14:29] <Cimi> Saviq, so if I store qgetenv("UPSTART_JOB"), is that a QString?
[14:29] <mterry> Saviq, why do you say that?  I'm guessing you're talking about cimi's problems, which are just with running the wizard in the user session.  None of this greeter nonsense
[14:30] <MacSlow> and the server side is still using heartbleed-bug affected pre 1.0.1g OpenSSL -> "OpenSSL Support: 1 (OpenSSL 1.0.1f 6 Jan 2014)"
[14:30] <Saviq> mterry, right, possible, but then he should have MIR_SOCKET set correctly, too, but for some reason it doesn't reconnect apparently
[14:30] <Saviq> Cimi, waits
[14:31] <Saviq> RTFM
[14:31] <mterry> Saviq, he might not.  unity8 job sets MIR_SOCKET
[14:31] <mterry> Saviq, but I think it sets it to the same path that Mir defaults to anyway
[14:31] <Cimi> Saviq, QByteArray ?
[14:31] <Saviq> Cimi, dunno
[14:31] <MacSlow> but maybe/hopefully it's using the patched version
[14:31] <mterry> Saviq, oh, but if unity8 job hasn't run yet, then MIR_SOCKET will indeed point ot USC
[14:32] <Saviq> mterry, yeah, but there is a MIR_SOCKET in env - probably pointing at usc
[14:32] <Saviq> mterry, exactly
[14:32] <mterry> Cimi, so hardcode changing MIR_SOCKET to the one unity8 uses then  :)
[14:32] <mterry> that integration will change anyway, so we don't need to make it perfect
[14:33] <Saviq> mterry, Cimi, yeah, so just copy most of unity8.conf and add post-start / pre-stop to start/stop maliit, correct?
[14:33] <Saviq> @unity standup
[14:33] <mhall119> in the Unity 8 preview on desktop, how can I get more apps to show up in the dash?
[14:34] <mterry> Cimi, Saviq: maybe...?  sure
[14:34] <Cimi> I'm testing this for unity mir http://paste.ubuntu.com/7221833/
[14:35] <Saviq> mhall119, bug #1300925
[14:43] <elopio> The number of branches we have waiting for review is growing bigger. Now we have 6.
[14:43] <elopio> https://code.launchpad.net/~elopio/unity8/
[14:43] <elopio> https://code.launchpad.net/~allanlesage/unity8/
[14:43] <elopio> Saviq, can you help us getting reviewers for them?
[14:43] <Cimi> Saviq, what happens in ~/ubuntu/scratch? seems empty here
[14:43] <Saviq> Cimi, depends, did you mount it?
[14:43] <Cimi> Saviq, nope
[14:43] <Saviq> Cimi, from the fstab?
[14:44] <Saviq> Cimi, then nothing will happen there ;)
[14:44] <Cimi> Saviq, it's from sbuild internal fstab
[14:44] <Cimi> Saviq, what it's supposed to be doing?
[14:45] <Saviq> Cimi, I've logs, the build dir mounted there and such
[14:45] <Cimi> sorry got logged out
[14:46] <Saviq>  Cimi, I've logs, the build dir mounted there and such
[14:50] <Cimi> Saviq, I have two in /var/lib/schroot/mount/
[14:50] <Cimi> Saviq, maybe an old one
[14:51] <Saviq> Cimi, schroot -l --all-sessions
[14:52] <Cimi> cimi@draco:~/Development/unity-mir/unity-mir$ schroot -l --all-sessions
[14:52] <Cimi> session:trusty-amd64-armhf-30b0db8e-447f-4c36-8afe-6ef6ad499d62
[14:52] <Cimi> session:trusty-amd64-armhf-a9a1080a-31da-406f-9065-bbfbecb39d89
[14:52] <Saviq> Cimi, and https://wiki.ubuntu.com/SimpleSbuild#Expiring_active_schroot_sessions
[14:52] <Cimi> yeah, my pc is called draco
[14:52] <Saviq> …
[14:53] <Cimi> Saviq, every pc has a name of a constellation
[14:53] <Saviq> Cimi, nothing to do with Draco Malfoy, eh? ;)
[14:53] <Cimi> Saviq, doing almost all of them :P
[14:53] <Cimi> Saviq, nope
[14:53] <Cimi> Saviq, that sbuild made my day
[14:53] <Cimi> SOOO FAST
[14:54] <Saviq> Cimi, enable ccache and shm, you'll see what's fast
[14:54] <Cimi> and no more bloody no more space available on devide
[14:58] <Cimi> Saviq, think I did something wrong
[14:59] <Cimi> black screen
[15:00] <Saviq> Cimi, read the logs
[15:00] <Cimi> Saviq, no logs for system wizard
[15:00] <Cimi> think I compiled without debug
[15:00] <Cimi> I am recompiling indeed
[15:01] <Cimi> Saviq, but everytime I run sbuild it fetches all packages?
[15:01] <Cimi> ok that I have fast internet but...
[15:02] <Saviq> Cimi, that's because it's meant to be clean
[15:02] <Saviq> Cimi, if you want, you can prep a separate chroot
[15:02] <Saviq> Cimi, and build-dep -aarmhf inside
[15:02] <Saviq> Cimi, as root
[15:02] <Cimi> I see
[15:02] <Cimi> but internet is fast enough, thx anyway
[15:08] <Saviq> Cimi, internet might be fast
[15:08] <Saviq> Cimi, but it's not about downloading
[15:08] <Saviq> Cimi, it's about installing, still takes a lot of time
[15:11] <Cimi> Saviq, WOFOOO
[15:11] <Cimi> hoo
[15:11] <Cimi> Saviq, osk working correctly and notifications
[15:11] <Cimi> now I'm working on the post quit
[15:11] <Cimi> see why the wizard is not quitting
[15:28] <Cimi> Saviq, mterry is this correct for stop? http://paste.ubuntu.com/7222036/
[15:29] <Cimi> also http://paste.ubuntu.com/7222044/
[15:30] <Cimi> main.cpp
[15:33] <mterry> Cimi, you probably don't need "initctl emit indicator-services-start" in the script
[15:33] <Cimi> mterry, why?
[15:33] <mterry> Cimi, wizard doesn't use indicators
[15:33] <Cimi> mterry, wifi
[15:33] <mterry> Cimi, it needs the indicator?  It doesn't just talk to NM?
[15:33] <mterry> OK
[15:34] <Cimi> mterry, it doesn't quit though
[15:34] <mterry> Cimi, but those indicators are going to want to be restarted for proper unity8 session I bet...
[15:35] <Cimi> mterry, an idea why it does not quit?
[15:35] <Cimi> can it be main.cpp?
[15:35] <mterry> Cimi, sorry, what what doesn't quit?
[15:36] <Cimi> mterry, I always see the spinner
[15:37] <Cimi> mterry, also, how can I stop the upstart job?
[15:37] <mterry> Oh..  You know.  Maybe just skip start_xsession altogether for now.  Just do a QApplicationCore::quit() or whatever the method is
[15:37] <Cimi> root@ubuntu-phablet:~# stop ubuntu-system-settings-wizard
[15:37] <Cimi> stop: Unknown job: ubuntu-system-settings-wizard
[15:37] <mterry> Cimi, I did that so the spinner page would stay up until unity8 is ready
[15:37] <mterry> Cimi, but once we eventually move to split greeter, USC will show a spinner for us
[15:37] <Cimi> ok
[15:37] <mterry> Cimi, so that whole "not really quitting" logic can go
[15:37] <Cimi> cool
[15:39] <Cimi> I'm rebuilding
[16:02] <Cimi> mterry, Signal QQmlEngine::quit() emitted, but no receivers connected to handle it.
[16:02] <mterry> Cimi, right.  Instead of connecting start_xsession, connect QCoreApplication::quit
[16:02] <Cimi> yeah, just wanted configm
[16:02] <Cimi> confirm
[16:04] <Cimi> mterry, qcore or qgui?
[16:04] <mterry> Cimi, just qcore
[16:04] <mterry> I mean, doesn't matter really.  Both do same thing
[16:31] <mterry> kgunn, when the next unity8 release happens, do you gather all Approved branches or do I need to specially ask for lp:~mterry/unity8/unlock-script to be included?
[16:31] <kgunn> probably need to ask...
[16:31] <kgunn> actually...
[16:34] <Cimi> mterry, difficulties in closing app
[16:34] <Cimi> mterry, I have     QObject::connect(view->engine(), SIGNAL(quit()), QCoreApplication::instance(), SLOT(quit()));
[16:34] <Cimi> but it hangs
[16:35] <mterry> hangs huh...
[16:35] <mterry> I would expect that to do something
[16:37] <mterry> Cimi, can you gdb it?
[16:38] <Cimi> mterry, I've connected to application now instead qcore
[16:38] <Cimi> i'm recompiling
[16:46] <Cimi> mterry, ok I'm connected with gdb
[16:46] <Cimi> what shall I see?
[16:47] <mterry> Cimi, you connected while it's hung?
[16:47] <Cimi> mterry, I think it's stuck
[16:47] <mterry> Cimi, a stacktrace with 'bt' ?
[16:47] <Cimi> mterry, http://paste.ubuntu.com/7222383/
[16:47] <Cimi> mterry, qml emits qt.quit
[16:47] <Cimi> mterry, that is handled via
[16:48] <Cimi>     QObject::connect(view->engine(), SIGNAL(quit()), application, SLOT(quit()));
[16:48] <Cimi> and that is the bt
[16:49] <mterry> Cimi, maybe we want to do just an exit(0) instead of fancy QCoreApplication::quit().  mir seems to not care that we quit Qt.  Is that because we are multithreaded with Qt in one thread?
[16:49] <Cimi> mterry, so instead of SLOT(quit()) I replace exit(0)?
[16:50] <Saviq_> mterry, Cimi, look at unity8's main
[16:50] <Saviq_> mterry, Cimi, we have some joins there to close gracefully
[16:50] <mterry> perfect, makes sense
[16:51] <Saviq_> or actually unity-mir?
[16:51]  * Saviq_ was sure we had something special in u8...
[16:51] <Saviq_> brb
[16:52] <Saviq> mterry, Cimi ah, not joins, but we have the deletes at the end of startShell
[16:52] <Saviq> that was needed for proper shutdown
[16:53] <Cimi> Saviq, so I delete the app?
[16:53] <Saviq> Cimi, not the app, but the objects ;)
[16:53] <Cimi> Saviq, qml calls qt.quit
[16:53] <Cimi> now how do I close gracefully?
[16:53] <Saviq> Cimi, that's when application->exec() returns
[16:54] <Cimi> Saviq, so I don't add any connection?
[16:54] <Cimi> let me try
[16:54] <Saviq> Cimi, yes you need to add a connection indeed
[16:54] <Cimi> Saviq, so which one?
[16:55] <Saviq> Cimi, http://qt-project.org/doc/qt-5/qqmlengine.html#quit
[16:55] <Cimi> Saviq, I added  QObject::connect(view->engine(), SIGNAL(quit()), application, SLOT(quit()));
[16:56] <Cimi> Saviq, but doesn't seem to work
[16:58] <Saviq> Cimi, do you see the signal being emitted? did you try calling QApplication::quit() in a singleshot timer in main.cpp?
[16:58] <Saviq> Cimi, do you see QApplication::exec() returning?
[16:58] <Cimi> Saviq, I see InputArea::~InputArea (this=0xaeae3bc8)
[16:58] <Cimi> MirSurfaceManager::~MirSurfaceManager (this=0xaeaef6b8)
[16:59] <Cimi> Saviq, so something happens
[16:59] <Saviq> Cimi, btw, bug #1301309 still awaits you
[17:00] <Saviq> Cimi, yes, set it to grey explicitly for now
[17:00] <Cimi> ok
[17:05] <mzanetti> dandrader: greyback: https://code.launchpad.net/~unity-team/unity-api/add-surfacemanager-and-item/+merge/214809
[17:06] <Cimi> Saviq, you think textarea might suffer of the same issue?
[17:06] <Saviq> Cimi, not sure
[17:08] <Cimi> Saviq, reading code, it should have bg
[17:08] <Cimi> Saviq, I'll skip textarea for now
[17:09] <Saviq> Cimi, you could check ;)
[17:09] <olli_> has anyone seen bregma around?
[17:09] <Saviq> Cimi, but yeah, I think it's fine
[17:11] <Cimi> Saviq, https://code.launchpad.net/~cimi/unity8/lp1301309/+merge/214810
[17:15] <Cimi> Saviq, so basically I just need to connect to the right signal
[17:15] <Cimi> Saviq, but I don't know which one in this case
[17:15] <Cimi> Saviq, googling returned the one I used before QObject::connect(view->engine(), SIGNAL(quit()), application, SLOT(quit()));
[18:48] <mterry> kgunn, I'm looking at silo 005, and while I did say we don't need changes for USC, we do need to recompile it.  So your lp:~kgunn72/unity-system-compositor/usc-mir-0.1.8 should be fine
[19:19] <mterry> Saviq, ^ can you add USC to silo 005 there?