[08:58] <alan_g> duflu: your "Needs Info" answered? https://code.launchpad.net/~alan-griffiths/mir/death-to-SurfaceConfigurator/+merge/254796
[08:59]  * duflu looks
[08:59] <duflu> alan_g: Approved
[08:59] <alan_g> thanks
[09:04] <duflu> 2015 might be the year I start using C99 for everything instead of C89
[09:05] <duflu> Although that might have happened in 2010
[09:05] <duflu> Hmm
[10:01] <greyback> where can I find the instructions for the proving shell? i.e. how to resize something
[10:02] <alan_g> greyback: Alt+middle button
[10:03] <greyback> bah, no middle button on my trackpad
[10:03] <greyback> alan_g: thanks
[10:11] <alan_g> greyback: three finger gesture?
[10:16] <greyback> alan_g: perfect, ta
[10:18] <duflu> greyback: For the latest: http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/doc/demo_shell_controls.md
[10:19] <duflu> If anything works with multi-touch-pads, that's partly by accident. Mir doesn't really know about touchpads directly
[10:19] <greyback> duflu: still here? (thanks for the link, always fail to locate that file)
[10:19] <duflu> greyback: Off to make dinner now
[10:19] <greyback> duflu: fair enough, bon appetit
[14:45] <MacSlow> alan_g, greyback: I've sent you an email with the unity8.logs of the (mir-)failures I see (and a comparison for non-failure) in the hope you'll be able to find anything odd that might help in my search for the culprit of the crash.
[14:46] <greyback> MacSlow: did you ascertain if unity8 crashes or not?
[14:47] <greyback> if it does, why not attach gdb with "gdb -p `pidof unity8`"
[14:47] <greyback> that should give you a stacktrace when it crashes
[14:48] <MacSlow> greyback, didn't manage to catch it yet that way
[14:48] <MacSlow> greyback, so I assumed there has to be another way
[14:52] <greyback> MacSlow: none that I know of. Could set any coredump to end up in your $HOME with:
[14:52] <greyback> sudo bash -c 'echo "$HOME/core.%e.%p" > /proc/sys/kernel/core_pattern' && ulimit -c unlimited
[14:57] <MacSlow> greyback, *sigh* when I want it to crash it doesn't :)
[14:57] <MacSlow> greyback, no core file
[15:05] <greyback> MacSlow: can you watch "ps ax" to see if unity8 is indeed restarting?
[15:05] <MacSlow> greyback, one sec...
[15:10] <MacSlow> greyback, no... on /lib/modules is 99% full all other partitions provide still enough free storage
[15:11] <greyback> MacSlow: so unity8 is not restarting during the test case. ok
[15:12] <MacSlow> greyback, I don't get any core dump files... but /var/crash gets some files...
[15:12] <MacSlow> but these are prefixed with _usr_bin_unity8 which is not what I would expect from the AP-test...
[15:12] <MacSlow> as it should run the local unity8 from the source-tree
[15:13] <greyback> MacSlow: I didn't think AP did that
[15:13] <greyback> but I'm not certain
[15:13] <MacSlow> greyback, what start local unity8 or dump to /var/crash ?
[15:13] <greyback> MacSlow: from local unity8
[15:14] <greyback> again, I'm unsure
[15:14] <MacSlow> greyback, I hope you're wrong... otherwise I've been wasting some time
[15:16] <greyback> well it's easy to verify
[15:20] <MacSlow> greyback, just moved /usr/bin/untiy8 and re-ran the AP-test... still works
[15:20] <greyback> MacSlow: ok good
[15:20] <MacSlow> greyback, I would have been very surprised, if that would not have worked
[15:24] <MacSlow> greyback, it failed but did not produce any core or crash-file (in /var/crash)
[15:24] <greyback> MacSlow: ok, it's not a crash, good
[15:25] <MacSlow> I've /usr/bin/unity8 still moved aside
[15:28] <MacSlow> greyback, I wonder if the issue is a DBus one... looking at the failure-output there's an error from DBus right after the autopilot process-helper reported unity8 started/running...
[15:34] <greyback> MacSlow: DBusException: org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus)  <- that does indicate to me AP asked something of unity8, but unity8 has not replied
[15:35] <greyback> does the UI lock up?
[15:36] <greyback> but we're in "launch_unity"
[15:37] <greyback> so unity8 is being launched, but AP unable to contact it on the bus
[15:38] <greyback> "Unable to register object on D-Bus! Testability interface will not be available."
[15:38] <greyback> ok that's a problem
[15:38] <greyback> next question is _why_ it's unable to register on the bus
[15:38] <greyback> is there a previous unity8 instance still alive?
[15:38] <MacSlow> greyback, you see the question-marks above my head get bigger and bigger
[15:39] <MacSlow> greyback, it should not... but let me try soemthing else...
[15:39] <greyback> MacSlow: dbus-monitor show you useful info?
[15:40] <greyback> Testability driver loaded. Wire protocol version is "1.4".
[15:40] <greyback> Testability driver loaded. Wire protocol version is "1.4".
[15:40] <greyback> Unable to register object on D-Bus! Testability interface will not be available.
[15:40] <greyback> why the first line printed twice?
[15:40] <greyback> is hte testability plugin being loaded twice somehow?
[15:40] <greyback> and the second time it fails, as the first time succeeded
[15:41] <greyback> dbus is available, as the clipboard registers ok
[15:41] <MacSlow> greyback, dbus-monitor dumps too much...
[15:42] <greyback> "Signal caught by Mir, stopping Mir server.."
[15:42] <greyback> this log is full of oddness
[15:44] <MacSlow> greyback, one of the AP-folks is currently also looking over this... I hope he's able to make more sense of this