[00:02] RAOF, what is wrong with your connection in general? You G+ calls are barely working! [00:04] I don't know. [00:04] I *can* get [00:04] I *can* get > 1MB/sec down from the internode mirror. [00:10] RAOF: I had to try really hard to laugh sometime in the meetings, becaue you would have a conversation with omeone and from my perpective it was about [00:10] 70% machine noise [00:10] and 30% word [00:11] that was why "We only need to care about input when we want to" [00:11] was so hilarious because it came out super clear after about 20 seconds of machine noise [00:11] haha [00:11] Hah [00:11] I got what you were getting at though [00:12] My natural verbosity is leveraged as an error-correcting code. Yay! [00:39] Does anyone know of a method to give properties to a rendering backend? I need to tell the GBM platform to use a specific VT, but there doesn't seem to be any channel for backend properties [00:48] There's currently no channel to do that. [00:55] robert_ancell: I think to do that you'd need to (a) extend DefaultConfiguration to handle a new cmdline parameter, then (b) Extend the interface to create_platform() to pass those configuration options in, and then (c) make the GBMPlatform pass those through to GBMDisplay, and then (d) make GBMDisplay actually act on it. [01:04] RAOF, yeah, I thought that would be likely [01:04] RAOF, though the options might not come from the command line, so I was thinking just key-value paird [01:04] pairs [01:05] The options parser also handles environment variables, so that's close already. [01:06] RAOF, the boost one? [01:06] Whatever one we actually use. It might be the boost one? [01:06] Yep [01:06] each command line option is also [01:07] an enviroment variable, i.e. --foo-bar is MIR_SERVER_FOO_BAR [01:55] Ok. Apparently the reason why unity-system-compositor doesn't give any output for me when it fails on startup is because it never gets to main()‽ [01:58] RAOF: Nice. That would mean either failure to find DSOs, or a DSO is crashing in init (before main) [01:59] Silently! [02:00] RAOF: env LD_DEBUG=all ? [02:00] Wow. That really dumps *all the things*, doesn't it. [02:01] There are alternatives to "all". Try "help" [02:02] * RAOF reboots to give that a whilrlygig. [02:15] Hah. It must be getting SIGKILLed by lightdm for starting slowly :) [02:15] That's not very useful. [02:17] RAOF, It took more than 5 seconds?! [02:17] robert_ancell: Oh, yes. [02:17] You underestimate the boot time of my goddamned laptop. [02:18] RAOF, If you have any clever idea of how to avoid that timeout let me know. I guess there has to be some hard coded value [02:18] RAOF, you can set the timeout on a recent commit in the config file btw [02:18] Yeah, I'll just set that and then be about my business. [02:18] You could probably just wait for the system compositor to respond on its pipes or die; it's *probably* not going to hang. [02:20] RAOF, it's the *probably* we need a catch for otherwise you'll hang forever [02:20] Is there a number low enough for the user not to hard reset but to be pretty much sure the compositor/driver has failed? 30s? 1min? [02:21] Dunno. [02:22] Not hanging is something that we should be able to make the vast majority of cases, so we might just not catch that. [02:22] RAOF, well, then setting it to 5 mins should work [02:22] And rely on the failed-boot mechanics to get the user somewhere sane *next* boot. [02:22] ah, true [02:22] RAOF, it would make the regression tests faster if we drop that feature [02:24] At some point we should be able to just drop it. That point might be now [02:24] What's the config key for the timeout? [02:25] unity-compositor-timeout in [SeatDefaults] [02:26] Ta. [02:27] Well, that's unhelpful. [02:27] Ish. [02:27] Setting that timeout to an insane value makes u-s-c work for me. [02:28] NO BUG REPRODUCTION FOR YOU! [02:29] RAOF, how long does it take? (from lightdm.log) [02:29] HAH! [02:29] 5.36s [02:30] Sorry, 5.26s, 'cause it takes .10s to get to the point of starting u-s-c. [02:30] ! [02:30] default -> 10s? [02:30] Maybe? [02:31] Why not go 60; that's a nice round number, and even the slowest, most degraded btrfs filesystem surely can't take more than 60s to start u-s-c. ☺ [02:32] sure [02:32] RAOF, do you want to do the MP? [02:32] Yeah, I can do that. [02:33] Hm. I wonder why it's saing “Unable to set active session, unknown client name 0”? [02:33] Or, rather, why can't it find that client name. [02:34] RAOF, full log? [02:37] robert_ancell: http://paste.ubuntu.com/5782352/ [02:37] That's startup, switching to a guest session, and back. [02:37] Looks like the session hadn't connected in time [02:37] Yeah. [02:37] Though clearly some more logging is needed.. [02:38] I thought I'd linked up logs to when sessions connected, but apparently didn't find the right class for that.. [02:57] robert_ancell: I was thinking there's a distinct lack of demo/manual test programs for the session stuff. It's a bit slow depending on lightdm to test that externally... [02:58] duflu, not sure what you mean - 1-1 anyway? [02:58] robert_ancell: Yes am online [02:58] Allegedly [03:08] RAOF, I think you merged into the wrong thing - https://code.launchpad.net/~raof/mir/lightdm-longer-u-s-c-timeout/+merge/170478 [03:08] lp:mir instead of lp:unity-system-compositor [03:09] https://code.launchpad.net/~vanvugt/lightdm/fix-1192051/+merge/170362 [03:34] RAOF, lp:~mir-team/lightdm/unity rather [03:35] robert_ancell: Yeah, just retargetting. [03:36] RAOF, can you do the 1-1 earlier, say nowish? [03:37] Sure. [04:51] RAOF, https://code.launchpad.net/~robert-ancell/lightdm/unity-disable-tests/+merge/170485 [04:55] robert_ancell: https://code.launchpad.net/~raof/lightdm/lightdm-longer-u-s-c-timeout/+merge/170486 [05:28] duflu, ping [05:29] tvoss: Pong. Seems I tend to get back from lunch when you log on in the mornings [05:29] duflu, perfect timing then :) [05:29] duflu, we both are sleepy, that is, and long for coffee [05:30] I got a real coffee on the way back from lunch \o/ [05:30] duflu, \o/ [05:47] RAOF: What was your system-compositor exiting problem? [05:49] duflu: It was taking 5.2 seconds to start, and lightdm was sending SIGKILL after 5 seconds. [05:50] RAOF: Oh. Why so slow? [05:50] Because btrfs [05:50] Wow [05:51] It's *significantly* better now than it has been. It takes less than a minute to get to the unity-greeter. [05:51] It used to take more than five. [05:52] RAOF, wow, that's long turnaround time [05:52] btrfs *really* doesn't like snapshots on rotating rust. [05:52] Over time its performance degrades to basically nothing. [05:53] I think my worst-case boot time was 20 minutes to the greeter. [05:53] Which is a pity, because btrfs has a bunch of awesome features. === marlinc is now known as marlinc|away [07:04] robert_ancell: Hey, is there currently any way for XMir to tell when it gains or loses focus? [07:32] RAOF, I don't think so === marlinc|away is now known as marlinc [07:35] I think I could bodge something together by listening for motion events, but it's probably better to actually fix the protocol so that clients can tell when they're focussed. [07:35] racarr? :) [07:40] RAOF, did you confirm the X acceleration is fixed from boot? [07:41] Yup. [07:41] RAOF, i.e. bug 1191937 [07:41] bug 1191937 in Light Display Manager "loss of x acceleration when xmir is loaded" [Undecided,Fix committed] https://launchpad.net/bugs/1191937 [07:41] Nice [07:41] Works For Me™ [07:41] Breaks once you try and do user-switching, of course, but until then, it works fine :) [07:42] I was just thinking that the VT number might be wrong based on the duflu review of my VT branch for mir - I set XDG_VNTR to the number in /dev/ttyN - but VT numbers are off by one [07:42] i.e. tty1 = VT0 [07:42] or duflu has just confused me [07:43] I think duflu might have confused you. [07:43] Well it doesn't look like a Mir bug. We're asking for VT n and it appears on tty n+1 (Alt+(Fn+1)) [07:43] Looks designed that way [07:44] I mean tty n+1 appears on VT n :) [07:44] Which is confusion, even if by design, that we should hide from the user [07:45] duflu, are you sure the mouse pointer has anything to do with that change? I can't see the connection [07:45] robert_ancell: I can't see the connection either but it doesn't happen to trunk [07:45] I think you triggered a side-effect [07:47] RAOF, for focus events: stay tuned, working with ricmm and racarr on that bit [07:47] tvoss: Cool. Presumably they'll come through the event fd, like everything else? [07:47] RAOF, presumably [07:49] RAOF, thanks for the corrections btw :) [07:50] RAOF: Only input comes through the fd. All other events come over the protobuf [07:51] duflu: The things in common/event.h don't all come over the fd? [07:52] RAOF, yup, the input stream is separate right now [07:52] RAOF: Oh, yes. Input events (most of event.h) are on the fd. But MirSurfaceEvent (of which there are multiple sub-types) are on protobuf [07:53] Ah, of course! [07:53] One more thing to send through my thread-to-eventloop mechanism, I guess. [07:54] RAOF, not sure duflu did some experiments with unifying the streams, I did some preliminary investigations and having the event stream separate turned out to be a good idea [07:54] I've been meaning to write a "ping" type benchmark to establish a baseline and we can work from there [07:55] duflu, will dig out my experiemtn I did on the phone [07:55] Eh. I guess XMir will just get a callback on a random thread, I'll send it through the pipe, and pick it up in X's event loop. [07:55] tvoss: Though you can't "ping" with input. Only surface events have simple request/response sequences via the client API... (?) [07:56] RAOF, fair [07:57] RAOF: Most exciting is that *all* event types come to clients in the same callback, regardless of the transport :) [07:57] Yay! [07:57] It gets combined in the client library [07:58] duflu, iirc I tagged the input events with a timestamp [07:58] duflu, but let me find the code :) [07:58] Sure === marlinc is now known as marlinc|away [08:34] mmrazik, ping [08:34] tvoss: pong === mmrazik is now known as mmrazik|afk [08:50] didrocks, o/ [08:50] robert_ancell, hey, how are you? [08:50] seb128, hey, good [08:50] yourself? [08:50] I'm good thanks [08:51] better today that this heat wave is over, I didn't like the 36°C from the past days much :p [08:51] now that* [08:51] seb128, ow, that's hot for you guys! [08:52] indeed [08:52] seb128, lucky you ... we still have it === mmrazik|afk is now known as mmrazik [09:23] RAOF, hey, not sure if you noticed but I added conf.d support to lightdm - so you should be able to make /etc/lightdm/lightdm.conf.d/99-unity-system-compositor.conf and set the seat type in there [09:24] It should work better than lightdm-set-defaults? [09:25] didrocks, ^ actually, do you know if there's anything using lightdm-set-defaults that wouldn't work switched to using the conf.d dir? [09:27] tvoss, good to see I'm not the only one worried about feature freeze :) [09:27] robert_ancell, yup [09:28] RAOF, anyone, can you please kick off a Mesa build for raring? We don't have one since libmirclient0 became libmirclient1 ... https://launchpad.net/~mir-team/+archive/staging/+packages [09:28] Hence the build failures and crashes I mentioned on mir-devel === marlinc|away is now known as marlinc [09:37] duflu, I'm having a look inside Jenkins. I know it can be done, but Jenkins is a little scary [09:38] robert_ancell, no problem. I have a workaround [09:38] But it's ugly [09:38] duflu, for you or for everyone? [09:38] robert_ancell, on mir-devel [09:38] mmrazik, can you help here?^ [09:39] * robert_ancell wonders how close we are to dropping raring in the PPA [09:40] looking [09:40] duflu: what needs to be done? Just dput the mesa into ppa again? [09:40] mmrazik, Maybe. Haven't checked the cause of failure [09:41] hey robert_ancell! [09:41] duflu, robert_ancell: FYI -- the following job takes whatever is in the git repo and dputs into the ppa [09:41] didrocks, hello [09:41] : [09:41] http://10.97.2.10:8080/job/mesa-egl-platform-mir-dput/ [09:41] just triggered it [09:41] robert_ancell: I think they should be fine with using conf.d (it's mostly metapackages generated from the seeds) [09:41] mmrazik, ta [09:41] usually its triggered by git change but if you trigger manually it will do the same [09:42] mmrazik, thanks. Fingers crossed [09:58] robert_ancell, should I spend the time trying to fix plymouth properly or move on to transitions? [09:59] duflu, transitions [09:59] duflu, because we need that to work for the phone [09:59] True [09:59] I might make some dinner instead. 6pm is a bad time to start something new [10:00] :) [10:00] Not to mention 10pm [10:14] duflu: Mesa won't build against libmirclient1 on raring until *Mir* 0.0.4 builds on raring. [10:14] * duflu looks [10:17] RAOF: As it happens, Mir 0.0.4 _can't_ build on raring due to the bug I'm trying to solve... https://launchpadlibrarian.net/142922154/buildlog_ubuntu-raring-amd64.mir_0.0.4bzr760raring0_FAILEDTOBUILD.txt.gz [10:17] And the build won't succeed until it's done against a Mesa that links libmirclient1 :/ [10:17] Chicken or egg? [10:18] duflu, RAOF, robert_ancell do we _need_ raring? [10:18] * duflu does for efficient development [10:18] tvoss, no, just waiting for everything to finish using it [10:19] It's only a PPA problem. We can support raring if only we rebuild Mesa, somehow [10:19] duflu: Why won't the build succeed until it's done against a Mesa that links libmirclient1? [10:20] RAOF: see my emails on mir-devel. Because we link to Mesa libs that use libmirclient0 (PPA) and also link to libmirclient1 locally [10:21] How did we fix it for saucy? [10:21] Should be the same solution [10:22] /usr/bin/ld: warning: libmirclient.so.0, needed by /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libEGL.so, may conflict with libmirclient.so.1 [10:23] * tvoss wonders if it would be a lot of effort to split out the mesa egl into libEGL.so, which is a chim loading libEGL_${PLATFORM}.so [10:24] duflu, RAOF ^? [10:25] tvoss: Not sure. I'm looking at the dependency graph... [10:26] duflu, that would unbreak our build and ease multi-egl-platform support [10:26] Ah it's the client+server being built together that's the problem [10:26] Yes. [10:26] If we split libmirclient out, it would be much easier. [10:27] EGL depends on mirclient. And mirclient depends on nothing important but gets built *with* mirserver which depends on EGL. So we have a dependency cycle we don't really need [10:27] I think hikiko mentioned this before [10:27] duflu, unfuck that please :) [10:27] duflu, oh well, you are eod already :) [10:27] * duflu will try to /action/ that another day [10:27] yup :) [10:28] duflu, sorry :) [10:28] Sounds messy [10:28] tvoss: Looks like separation of source packages :P [10:29] duflu, ack, noted it down to nag you tomorrow my morning :) or is it already friday for you? not sure ... damn tz [10:41] Do we *need* MirMesa on the build system? Could it just build with standard Mesa? [10:41] Have we added any symbols to libEGL for Mir? [10:42] duflu: your sleep is more important [10:43] duflu: We do not need MirMesa on the build system. [10:43] duflu: We can happily build against stock mesa. [10:43] That's a solution then [10:43] if it works [10:43] Well, it's not a long term solution [10:43] We don't want to reach universe with this cycle problem [10:45] bye all [10:46] robert_ancell, bye ) [10:46] :) === marlinc is now known as marlinc|away [11:14] ffs, https://launchpad.net/~mir-team/+archive/system-compositor-testing/+build/4730486 is so slow I want to help the builder with compiling myself [11:14] * tvoss takes out pen and paper ... === marlinc|away is now known as marlinc [11:48] RAOF, if still around: failed to install usc from system-compositor testing unity-system-compositor : Depends: libmirserver0 (= 0.0.4bzr759saucy0) but 0.0.4bzr760saucy0 is to be installed [11:48] tvoss: no!!!! [11:50] alf, mmrazik I think we just need to copy over usc again from staging to system-compositor-testing [11:51] usc? [11:51] mmrazik, unity-system-compositor [11:52] mmrazik, but you might want to wait until mir for i386 completes, although I think we are hitting a hanging builder :/ [11:52] ok [11:52] tvoss: Urgh, right. I shouldn't have copied the binaries for usc from staging. [11:53] tvoss: Yeah, a new copy *without* binaries would work. [11:53] RAOF, just forcing a rebuild against the current mir version, right? [11:53] tvoss: Exactly. Except that it's built successfully before, so you need to bump the version to get launchpad to rebuild it :) [11:54] RAOF, you mind doing that real quick? [11:58] tvoss: Done like a dinner. [11:58] I'll prepare for bed, then check that it's accepted into the PPA, then sleep :) [12:00] RAOF, yup :) \o/ [12:00] RAOF: thnka you [12:00] ....oh and thank you as well [12:00] So is there any ppa for mir that might actually work? [12:03] Good, that's accepted. amd64 will be installable when https://launchpad.net/~mir-team/+archive/system-compositor-testing/+build/4730713 finishes. [12:04] tvoss: Could I get you to babysit https://launchpad.net/~mir-team/+archive/system-compositor-testing/+build/4730715 ? You just need to hit the retry-build button once i386 mir has built. [12:05] …which it looks like it's not going to, because the build has hung again. What is going on with the buildds? [12:05] Anyway, I'm not going to get anything more done tonight. [12:06] RAOF, sure, will look at it [12:06] RAOF, will kill the mir i386 build and retry, too [12:07] retriggered === mmrazik is now known as mmrazik|afk [13:29] ffs [13:30] tvoss: ?! No need for that [13:33] alan_g, the buildd for the testing ppa hangs again === mmrazik|afk is now known as mmrazik [13:35] tvoss: patience is considered a virtue [13:35] alan_g, violence is not a solution but an option? [13:36] tvoss: I usually find a polite request to mmrazik results in a solution [13:37] alan_g: when it comes to ppa/buildd I can't do much :-/ [13:37] I can only help with jenkins [13:37] mmrazik, yup :9 [13:38] * tvoss muses that the buildds are hidden away in a 1.5 dimensional manifold somewhere/sometime [13:39] * alan_g wonders who can be made responsible for that bit of infrastructure [13:41] * kgunn wonders why tvoss keeps mentioning "flash file system" ;) [13:42] * kgunn unfortunately...actually knows why [13:53] * alan_g wonders why someone called a static library "mirsharedandroid" [14:11] alan_g, would you mind checking if a clean mir checkout builds fine with dpkg-buildpackage for you? [14:13] tvoss: I don't mind - but what's the incantation for it? [14:18] alan_g, to rule out that we have something non-buildable in the repo [14:18] tvoss: I mean I don't want to look up how to use it [14:19] in mir's root: dpkg-buildpackage [14:22] running... [14:31] alan_g, thx [14:32] np - but a single process takes a while [14:33] (Tried -j8 but that borked) === olli__ is now known as olli [14:34] alan_g, how long can /build/buildd/mir-0.0.4bzr760saucy0/obj-i686-linux-gnu/bin/acceptance-tests --gtest_list_tests [14:34] take? [14:35] ...run. Finished OK [14:35] tvoss: that depends [14:36] But if it takes more than a few milliseconds you've a very slow box [14:37] real 0m0.012s FWIW === mmrazik is now known as mmrazik|afk [14:59] hello all [15:08] kdub_: Hi! [15:09] hello one [15:12] alan_g: kdub_: Have a moment to take a look at https://code.launchpad.net/~afrantzis/mir/base-stubs-on-null-platform/+merge/170550 ? I have code that depends on this, waiting to be MPed :) [15:12] sure [15:13] * alan_g thinks "this implies a way to avoid seeing those waiting MPs" [15:21] alan_g: yes, so you, as the reviewer, get a double benefit from me doing it like this (and not using dependent branches) 1. you get simpler/cleaner MPs 2. you can control (to a degree) the incoming review queue :) [15:22] alan_g: kdub_: thanks for the quick action === marlinc is now known as marlinc|away [16:00] * tvoss goes to setup an i386 chroot [16:23] Saviq: tvoss: What format do you expect the snapshot pixels to be in? [16:24] tiled 3 planar yuv! [16:25] kdub_: \o/ :) [16:26] greyback: ^ [16:28] alf: rgba probably, but I'm checking === mmrazik|afk is now known as mmrazik [16:29] greyback: ok, r,g,b,a in memory or 0xRRGGBBAA as an int? [16:35] alf: ok, at the moment we read ARGB32 premultiplied, each pixel an unsigned char. === mmrazik is now known as mmrazik|afk [16:39] greyback: can you point me to where you got this information? [16:43] alf: qtubuntu, src/modules/application/application_image.cc, line 63/64 [16:43] greyback: thanks [16:43] alf: that's where the platform api passes us the pixels for the image [16:57] racarr, poke when you've got a moment to talk libhybris crashes [16:59] mterry: I can try and parse :D feeling kind of out of it this morning [16:59] racarr, :-/ suck [16:59] racarr, so remember yesterday, I was seeing a crash in mir_demo_server on the nexus7 [16:59] racarr, I finally got debug versions of libhybris and mir built [16:59] mm [16:59] racarr, this is the full bt: http://pastebin.ubuntu.com/5784142/ [17:00] racarr, seems to actually be in thread 17 when it dies [17:00] racarr, which is in hooks.c in libhybris [17:00] I'm looking at that code now, but it seems hooks.c has an early opt-out for nvidia... [17:02] Goodbye all! === alan_g is now known as alan_g|life [17:03] bye alan [17:03] * kdub_ thinks we might need a 'quirk' system for these closed drivers [17:03] maybe.. :) we should probably try to avoid it [17:08] mterry: I can't really determine anything besides hybris is fucked [17:12] racarr, ah... If I run mir_demo_server under GRAPHICS=NVIDIA, it doesn't segfault [17:12] racarr, so it was just the nvidia_hack not being used [17:12] I'll try to actually run the demo code [17:14] racarr, "Assertion `mir_connection_is_valid(connection)' failed." -- does that mean the server isn't running right [17:16] mterry: Yeah [17:16] mterry: Or say one is running as root and the other is user [17:16] or it crashed on connect [17:17] racarr, still seems to be running as root (same user) [17:18] does the server crash when you try and connect? [17:18] seemingly not, it's still runnig === ari_ is now known as arsson [17:58] I guess i'm running unity-system-compositor. still two cursors but unity de is working. === marlinc|away is now known as marlinc [18:00] I have nouveau installed, should i install nvidia proprietary drivers? [18:12] tearing [18:16] arsson: per the mir instructions.... [18:16] mir only works on open drivers atm [18:16] unity-sys-comp will fallback to standard x (non-xmir) [18:17] if you install proprietary drivers back in === marlinc is now known as marlinc|away [18:35] racarr, how does a client connect to a server? DBus or a socket or something? [18:39] mterry: Socket. [18:40] mterry: /tmp/mir_socket === racarr is now known as racarr|dentist [18:48] racarr|dentist, hmm, it exists. I want a super-verbose mode in Mir [18:56] mterry: weird huh....mir working right....makes you wonder if its working :) === ari_ is now known as arsson [18:59] kgunn, I see your thing above about only working on open drivers. What is our plan for nexus7? [19:00] * mterry has to run out === francisco is now known as Guest74254 [19:10] mterry: ah...that statement is only a desktop thing [19:10] libhybris allows for bins on mobile platforms [19:16] RAOF, ping === kdub_ is now known as kdub^lunch [20:20] cannot change icons. === kdub^lunch is now known as kdub [21:17] RAOF, assuming you're not online yet... [21:34] now if i can just get the driver to stop leaking buffers, i'm in the clear! :) [21:36] robert_ancell: previously, i had been toggling successfully between xmir attempts (& back) simply #commenting out the type=unity [21:36] in theory should that be all that's needed ? [21:36] kgunn, yes [21:38] robert_ancell: ok....so i'm on lightdm for this w/ type=unity commented _out_.....and i hang [21:38] kgunn, check there's not a second entry for type - I have seen that [21:40] kdub, do you need root for mir on android? [21:40] hey guys [21:40] is it possible to run mir/shell as user? [21:40] robert_ancell last i checked, yes [21:40] oh, he already asked [21:41] kdub: do you know the reason? [21:41] ricmm, I know on desktop you need root for the VT stuff [21:42] ricmm, let me try to run as user, i'll see what happens... [21:43] oh, actually... [21:44] getting a segfault in pthreads [21:45] seems ok on the nexus 4 for me [21:49] robert_ancell: just in case https://pastebin.canonical.com/93186/ [21:49] this is my lightdm.conf [21:49] kdub: do you have a maguro at hand? [21:49] kgunn, yeah, you have type=unity on the last line [21:50] ricmm, yeah, i'll fire it up and see [21:50] kdub: thanks! [21:51] robert_ancell: so are the instructions wrong? http://unity.ubuntu.com/mir/using_mir_on_pc.html [21:51] kgunn, sorry, you are trying to enable or disable xmir? [21:51] robert_ancell: nvmd....sorry....i am officially an idiot [21:51] actually....did you do something to auto-magically add that ? [21:52] i dont remember that being there [21:52] kgunn, RAOF made a change so u-s-c adds it on install [21:52] cool [21:52] now i know....sorry for not looking closer [21:52] ricmm, yeah... as far as I can tell, on maguro, you can't drive the display without root [21:52] but it doesn't recognise a quoted out entry, so it adds a new one if you've got a previously disabled one [21:52] kgunn, it caught me out the other day too :) [21:53] kdub: are you seeing the same segfault tho? [21:53] yep [21:53] or is it something else [21:53] right [21:53] well, probably the same one :) [21:54] ;) [21:54] does it happen in pthread_mutex_destroy? [21:56] ricmm, yes [21:56] ok [21:56] I'll look into it, sucks tho, I only have maguro :( [21:57] segfaults in pthread over hybris is rsalveti's land [21:57] ill go cook while he returns === racarr|dentist is now known as racarr [21:57] racarr: welcome back [21:57] Danke. [21:58] now 50% done with teeth repair [21:58] not counting the root canal next week [22:19] Can I get someone to do a quick review of https://code.launchpad.net/~robert-ancell/unity-system-compositor/command-line-options/+merge/170562 and https://code.launchpad.net/~robert-ancell/lightdm/unity-usc-command-line/+merge/170561 [22:19] Fairly small changes, but required to set the VT for XMir [22:23] brb [22:26] kgunn, ok, so I can get into my session from the u-s-c PPA [22:26] robert_ancell: i'm sure its me....somewhere along the line [22:27]