| RAOF | kdub_: Pong | 00:08 |
|---|---|---|
| RAOF | Yay! I can boot all the way to X again! | 00:08 |
| kdub_ | RAOF, so, the gbm-cleanup branch is ready to go from the mir side | 00:10 |
| RAOF | And you'd like a review? | 00:11 |
| kdub_ | i guess I'm just trying to figure out how to land the mesa cleanup without disrupting too many people :) | 00:11 |
| RAOF | Which mesa cleanup? Have I accidentally merged something that breaks the world? | 00:11 |
| kdub_ | well, that mp for mesa probably will break things if its pushed to the package | 00:12 |
| RAOF | Oh, really? It didn't look like it, but I didn't actually test that :) | 00:12 |
| kdub_ | ah, well then I should just land ~kdub/mir/gbm-cleanup and everything will be ok then | 00:13 |
| RAOF | It probably isn't in the mesa packaging yet, though; it got merged to egl-platform-mir, which requires an extra step. | 00:15 |
| kdub_ | RAOF, right, i suspect that the packaging hasn't picked up the change | 00:15 |
| RAOF | I can make it so that the packages will do the right thing though. | 00:15 |
| kdub_ | RAOF, well, i guess lets do that | 00:17 |
| RAOF | Yeah. | 00:17 |
| kdub_ | and then land gbm-cleanup right after they hit the ppa | 00:17 |
| kdub_ | really, i think "native_display.h" should probably be 'upstreamed' out of mir at some point | 00:18 |
| kdub_ | RAOF, close to my eod, should we do the transition tomorrow? | 00:55 |
| RAOF | kdub_: I can probably walk it through myself. | 00:55 |
| RAOF | It's just landing gbm-cleanup and the mesa changes at the same time, right? | 00:56 |
| kdub_ | right | 00:56 |
| RAOF | Yeah, I can do that. | 00:57 |
| RAOF | Oh. | 00:57 |
| RAOF | Can you push a commit to gbm-cleanup bumping the version to 0.0.4? If not, I'll do that. | 00:57 |
| kdub_ | ah, sure | 00:58 |
| kdub_ | RAOF, done | 01:04 |
| RAOF | bitchn. | 01:04 |
| duflu | kgunn: Got more details for https://bugs.launchpad.net/mir/+bug/1191937 ? | 01:35 |
| ubot5 | Launchpad bug 1191937 in Mir "loss of x acceleration when xmir is loaded" [Critical,Triaged] | 01:35 |
| kgunn | duflu: only details i have are...bregma was able to run xmir on an intel core w/ amd gpu | 01:36 |
| kgunn | it was super slow, and dash is opaque | 01:36 |
| kgunn | i believe he's still running it....if you needed debug/log info | 01:36 |
| duflu | kgunn: Erm, sounds like Unity falling back rather than Mir. Maybe like https://bugs.launchpad.net/nux/+bug/1066764 | 01:37 |
| ubot5 | Launchpad bug 1066764 in Nux "Unity fails to load on old hardware (compiz enabling LLVMpipe has no effect and Mesa tries to use hardware still)" [High,In progress] | 01:37 |
| kgunn | duflu: could be....altho (this may be a bad assumption on my part) gpu acceleration was there | 01:39 |
| kgunn | prior to loading xmir | 01:39 |
| kgunn | bregma ? ^ | 01:39 |
| duflu | bregma? If you have details please add to https://bugs.launchpad.net/mir/+bug/1191937 | 01:39 |
| ubot5 | Launchpad bug 1191937 in Mir "loss of x acceleration when xmir is loaded" [Critical,Triaged] | 01:39 |
| bregma | I do not have an AMD GPU | 01:40 |
| duflu | That's good news for me :) | 01:40 |
| kgunn | bregma: my bad | 01:42 |
| robert_ancell | RAOF, are you just copying the lightdm package into the system-compositor PPA? | 01:43 |
| RAOF | robert_ancell: Yes. | 01:53 |
| RAOF | bregma: Can you add the output of “LIBGL_DEBUG=verbose glxinfo” to that bug - that'll give some idea of what's failing. (My guess is that it's lightdm failing to set permissions on the dri device properly) | 02:00 |
| bregma | hmm, if I close the lid on this laptop networking goes away and never comes back, that's new... unrelated to Mir, but new in the last couple of days... | 02:06 |
| RAOF | Not super useful :) | 02:08 |
| bregma | done and attached | 02:15 |
| bregma | opening a terminal and using the Unity switcher are painfully slow, more signs of missing hardware acceletration | 02:16 |
| bregma | but flash games run OK in the browser :) | 02:16 |
| === fdr is now known as rafaelfdr | ||
| RAOF | Right. As I suspected, it's a permissions issue on /dev/dri/* | 02:22 |
| === rafaelfdr is now known as fdr | ||
| RAOF | robert_ancell: https://bugs.launchpad.net/mir/+bug/1191937 is a “lightdm failed to set permissions to /dev/dri/* correctly” bug. I remember this happening before, and you fixed it. Do you happen to remember how? :) | 02:28 |
| ubot5 | Launchpad bug 1191937 in Mir "loss of x acceleration when xmir is loaded" [Critical,Triaged] | 02:28 |
| robert_ancell | RAOF, lightdm doesn't set any permissions - we did see similar issues when console kit support wasn't working | 02:29 |
| RAOF | I guess that's what I mean. | 02:29 |
| robert_ancell | and the sympton for that was random session behaviour and erorrs in .xsession-errors | 02:30 |
| RAOF | ConsoleKit would also be setting up the permissions for /dev/dri; they're meant to be rw- for the active session, and --- for everyone else. | 02:31 |
| robert_ancell | RAOF, so it changes permissions on VT switch? | 02:34 |
| RAOF | Correct. | 02:34 |
| RAOF | Oh. | 02:34 |
| RAOF | I see where you're going here :) | 02:34 |
| robert_ancell | RAOF, well, that shouldn't matter for the single login case because there is no VT switch | 02:35 |
| RAOF | Except that it might not set the permissions *at all* if you don't VT switch? | 02:35 |
| robert_ancell | and it's normal for the session to be run by the lightdm user, then the user of the session logged into | 02:35 |
| RAOF | Actually, I don't know whether it changes permissions on VT switch, or whether you can tell it that the current VT is where the logged in user is. | 02:35 |
| robert_ancell | RAOF, so my current /dev/dri is root.video after booting using xmir | 02:36 |
| robert_ancell | Is that what you expect? | 02:36 |
| RAOF | robert_ancell: How about getfacl /dev/dri/card0? | 02:37 |
| RAOF | Because *that's* got user:chris:rw- | 02:37 |
| robert_ancell | # file: dev/dri/card0 | 02:37 |
| robert_ancell | # owner: root | 02:37 |
| robert_ancell | # group: video | 02:37 |
| robert_ancell | user::rw- | 02:37 |
| robert_ancell | group::rw- | 02:37 |
| robert_ancell | other::--- | 02:37 |
| RAOF | Hm. Ok. | 02:38 |
| RAOF | And you presumably don't have any acceleration. | 02:38 |
| robert_ancell | It seems laggily so | 02:38 |
| robert_ancell | What is it on a normal boot? | 02:38 |
| RAOF | I'm in a normal boot, and mine contains user:chris:rw- | 02:39 |
| robert_ancell | RAOF, I can't see anything in the consolekit source that might change this | 02:39 |
| robert_ancell | or GDM | 02:40 |
| RAOF | I know that *something* applies the correct ACL for the user of the active VT. | 02:40 |
| robert_ancell | udev? | 02:40 |
| RAOF | I'm pretty sure that's consolekit (when we're using consolekit, obviously) | 02:40 |
| RAOF | udev doesn't know anything about VT switching. | 02:40 |
| robert_ancell | which we aren't anymore | 02:40 |
| RAOF | Right. Which would presumably be why XMir works for me; I'm on Saucy. | 02:41 |
| robert_ancell | RAOF, but how would the ownership changes be synchronised? | 02:41 |
| RAOF | Oh, are you on saucy now? | 02:41 |
| robert_ancell | yes | 02:41 |
| RAOF | Hm. And it still doesn't work. Odd. | 02:41 |
| robert_ancell | RAOF, this is from a fresh boot, It seems accelerated if I stop lightdm, then start it with xmir | 02:41 |
| robert_ancell | kgunn, are you restarting lightdm from a console or changing lightdm.conf and restarting your machine? | 02:43 |
| kgunn | robert_ancell: so first i try restart lightdm from the console....which just results in the blinking cursor (x console? ) | 02:44 |
| kgunn | then i restart | 02:44 |
| kgunn | (hard boot) | 02:45 |
| kgunn | note, i'm on saucy as well | 02:45 |
| kgunn | when i say "first i try"...meaning right after i change lightdm.conf | 02:46 |
| kgunn | and the hard boot results in the "you're running in low gfx mode" | 02:46 |
| RAOF | Hm, ok. | 02:48 |
| RAOF | I'll let these builds finish and then see if I can reproduce. | 02:48 |
| kgunn | not sure if i said this...but i'm only toggling the lightdm.conf type=unity | 02:49 |
| RAOF | kgunn: Are you running from ppa:mir-team/staging or from ppa:mir-team/system-compositor-testing? | 02:49 |
| kgunn | RAOF: today...changed to the system-compositor-testing | 02:49 |
| kgunn | (which i understand is supposed to be a stable collection) | 02:50 |
| kgunn | (vs the staging that is) | 02:50 |
| RAOF | Correct. | 02:51 |
| RAOF | Ok. I'll pull from there, and see what falls out. | 02:51 |
| RAOF | robert_ancell: Does the lightdm in the archive handle type=unity? | 02:52 |
| robert_ancell | RAOF, no | 02:52 |
| RAOF | Ok. So we need to bump the version of lightdm in the PPAs so that it supersedes the archive version. | 02:53 |
| RAOF | kgunn: What does ‘apt-cache policy lightdm’ say+ | 02:53 |
| RAOF | ? | 02:53 |
| === jono is now known as Guest3821 | ||
| kgunn | RAOF: 1.7.2-0ubuntu1 | 03:10 |
| RAOF | Right. That's why yours isn't working. That version of lightdm doesn't know how to XMir. | 03:11 |
| kgunn | is 1.7.0 the only version? | 03:13 |
| kgunn | RAOF: so i'm confused....shouldn't the system-compositor-testing ppa be dictating my lightdm version? | 03:14 |
| RAOF | Only if you've done the apt-pinning dance. | 03:15 |
| RAOF | I've made it so that all the XMir bits have a higher version than what's in the archive, but I don't have the ability to do the same for lightdm. | 03:15 |
| robert_ancell | kgunn, we should be on 1.7.2 but it looks like jenkins is not CI/autolanding LightDM at the moment | 03:18 |
| kgunn | robert_ancell: confused by your statement....i am on 1.7.2.... | 03:22 |
| robert_ancell | kgunn, you said " is 1.7.0 the only version" | 03:22 |
| RAOF | Right, but the autolanding infrastructure should be autolanding 1.7.2+mir bits into the staging PPA. | 03:23 |
| robert_ancell | RAOF, yeah, but it appears it's not anymore | 03:23 |
| robert_ancell | duflu, have you ever checked the lightdm logs after it fails to start? | 03:25 |
| kgunn | RAOF: robert_ancell ...when you say "1.7.2+mir bits"....do you mean lightdm trunk + lightdm patches just for mir ? or something else ? | 03:26 |
| duflu | robert_ancell: Working through morning jobs and getting xmir on saucy yet | 03:26 |
| duflu | I haven't used xmir for some... months :) | 03:26 |
| RAOF | kgunn: lightdm trunk + lightdm patches for mir. | 03:26 |
| robert_ancell | kgunn, more specifically - lp:~mir-team/lightdm/unity is the branch that has the unity (i.e. mir) support | 03:27 |
| kgunn | RAOF: robert_ancell: thanks...making sense | 03:27 |
| kgunn | robert_ancell: hence your point, ci not picking it up...so whatever is in the ppa is probably old (?) | 03:28 |
| robert_ancell | duflu, ok. That bug has quickly become a "me to" bug for any issue in plymouth/lightdm/xmir/unity-system-compositor | 03:28 |
| robert_ancell | not starting | 03:28 |
| robert_ancell | kgunn, it's one version old | 03:28 |
| robert_ancell | RAOF, do you get a purple box where the launcher should be (if launcher set to autohide) that redraws if you move the mouse over it? | 03:30 |
| RAOF | robert_ancell: In XMir? | 03:30 |
| robert_ancell | yes | 03:31 |
| RAOF | Not last time I tried, but all my builds have now finished and I'm in the process of switching to XMir. So, I can give you an answer soon :) | 03:31 |
| RAOF | However that sounds a lot like the launcher misrendering that I've experienced with llvmpipe. | 03:32 |
| robert_ancell | RAOF, http://imgur.com/S7Ei9iK | 03:32 |
| RAOF | Yup, that's some crazy interaction between llvmpipe, compiz, and damage. | 03:33 |
| RAOF | robert_ancell: Care to review/approve https://code.launchpad.net/~raof/mir/gbm-cleanup-extra/+merge/169972 ? It's a couple of packaging commits on top of https://code.launchpad.net/~kdub/mir/gbm-cleanup/+merge/169306, which has already been approved. | 03:34 |
| robert_ancell | ok | 03:35 |
| robert_ancell | RAOF, why is llvmpipe running? I guess I'm not accelerated? | 03:35 |
| RAOF | Yeah, that would be why. | 03:36 |
| robert_ancell | RAOF, approved - you better land it before the existing trunk is built otherwise it wont make any difference... | 03:37 |
| RAOF | robert_ancell: Whyso? Oh. | 03:38 |
| * RAOF hadn't noticed duflu approving the old branch. | 03:39 | |
| RAOF | Ok. I've un-approved kdub's gbm-cleanup, and it looks like I've done that before the autolander kicked in. | 03:40 |
| kgunn | see you guys tomorrow | 03:46 |
| duflu | Bye kgunn | 03:47 |
| duflu | robert_ancell: I assume that's an important branch if only one reviewer :) | 03:47 |
| RAOF | duflu: It's the branch that got previously reviewed, plus 2 trivial commits. | 03:50 |
| duflu | RAOF: Oh. I recommend setting the prerequisite field in future to clarify that in LP | 03:50 |
| RAOF | Ok. Does that tell everyone “this should land *in stead of* the prerequisite branch”? | 03:51 |
| duflu | RAOF: Nah, no such option :/ | 03:57 |
| duflu | But mebbe at least reject the old one first :) | 03:57 |
| duflu | Otherwise some idiot like me might review and approve it | 03:58 |
| RAOF | :) | 03:58 |
| robert_ancell | RAOF, those dri permissions are very weird. I can confirm it doesn't have 'bob' when I'm using xmir, but it does when I'm using vanilla X. However - if I log in as 'belinda' it still only has 'bob' explicitly listed in the permissions | 04:21 |
| robert_ancell | And it never lists 'lightdm' but the greeter still works | 04:22 |
| RAOF | Does the greeter try to open /dev/dri? | 04:22 |
| RAOF | I wouldn't expect so. | 04:22 |
| robert_ancell | RAOF, so it's only once you try and open a GL app basically? | 04:22 |
| robert_ancell | also, note it added me even though I hadn't logged in | 04:23 |
| RAOF | It only *matters* once you try to open a GL app (as non-root) | 04:24 |
| RAOF | It should be correctly set up first, though. | 04:24 |
| * RAOF goes to see how u-s-c is broken on his system, now that everything's built and installed! | 04:24 | |
| RAOF | Ok. Without rebooting, everything works fine. | 04:27 |
| RAOF | But then again, I still have the correct acl set. | 04:28 |
| RAOF | Somehow. | 04:28 |
| RAOF | Hm. And XMir works fine for me! | 04:35 |
| RAOF | (Modulo the not-starting-on-boot-correctly bit, which I can now reproduce) | 04:35 |
| RAOF | Huh. Possibly because I still have consolekit installed. | 04:38 |
| RAOF | robert_ancell: There's no way to change the parameters given to unity-system-compositor by lightdm without changing the code, is there? | 04:41 |
| robert_ancell | RAOF, no, what would you like to send? | 04:41 |
| RAOF | I'd like to enable error reporting :) | 04:42 |
| RAOF | Because the default appears to be "log nothing" | 04:42 |
| RAOF | I was wondering why /var/log/lightdm/unity-system-compositor.log always seemed to be empty! | 04:43 |
| RAOF | Oh, that's right. There's no autolanding happening for lightdm/unity. | 04:45 |
| RAOF | Huh. | 04:54 |
| robert_ancell | RAOF, I've pinged QA about that, hopefully will be sorted when Martin awakes | 04:55 |
| robert_ancell | RAOF, please do enable reporting! | 04:55 |
| robert_ancell | RAOF, did you see what happened when it wasn't starting on boot?) | 04:56 |
| RAOF | I haven't enabled the reporting yet, I was trying to reproduce the no-permissions problem. | 04:56 |
| robert_ancell | laters | 05:00 |
| tvoss | good morning :) | 05:16 |
| tvoss | RAOF, ping | 05:17 |
| RAOF | tvoss: Pong | 05:17 |
| tvoss | RAOF, hey there :) how is it going? | 05:17 |
| RAOF | Pretty well. | 05:17 |
| tvoss | RAOF, I retriggered builds for some of the packages in system-compositor-testing yesterday, we were hitting a broken builder | 05:17 |
| RAOF | Ah, ok. That's why i386 was built this morning :) | 05:18 |
| RAOF | Thanks! | 05:18 |
| tvoss | RAOF, yw :) however, I'm hitting the plymouth issue with both ppas and unity is running unaccelerated | 05:18 |
| tvoss | RAOF, I can, however, get an accelerated variant in some hackish way | 05:19 |
| RAOF | So, I'm reproducing the unaccelerated bit. | 05:19 |
| RAOF | Which is really odd. | 05:19 |
| RAOF | *Sometimes* when starting lightdm it'll remove you from the acl on /dev/dri/*, which breaks acceleration. | 05:19 |
| tvoss | RAOF, I love these issues | 05:20 |
| * duflu thinks tvoss loves the wrong things about life | 05:20 | |
| RAOF | The first couple of times everything worked! | 05:20 |
| tvoss | RAOF, so the point is: my hackish way to get acceleration is by _not_ restarting after installation but just restarting lightdm | 05:20 |
| duflu | tvoss: Yep that's what I've been doing since January :/ | 05:20 |
| RAOF | Yeah, that should work. Also logging in to a VT and starting lightdm should *sometimes* work. | 05:21 |
| tvoss | RAOF, I *think* lightdm tries to signal plymouthd in some way and does not succeed | 05:21 |
| RAOF | I'm not sure what conditions are required for that to work. Maybe having an ssh connection? | 05:21 |
| tvoss | RAOF, nope, I'm switching to a VT and call sudo service lightdm restart | 05:21 |
| RAOF | Even after a reboot that should sometimes work. | 05:23 |
| RAOF | But sometimes not! | 05:23 |
| tvoss | RAOF, where is the race then? | 05:23 |
| tvoss | RAOF, any gut feeling? | 05:23 |
| RAOF | Oh, you're talking about the possibly plymouth race. I guess that's going to be plymouth not dropping DRM master soon enough, but I'm rebuilding lightdm so that I can get some actual debug logs. | 05:24 |
| RAOF | I was talking about the unaccelerated bits. | 05:24 |
| tvoss | RAOF, let me know if I can help :) I'm pretty fluent in resurrecting my system now | 05:24 |
| tvoss | @unaccelerated: that's weird, why could that even happen? lightdm is setting us up for accel, right? | 05:24 |
| RAOF | No, ish. | 05:25 |
| * tvoss branches kwin | 05:25 | |
| tvoss | RAOF, ish :) | 05:25 |
| RAOF | What *should* be happening is the login process thingy (consolekit or logind) should be setting the correct ACL on /dev/dri/* (ie: the user of the current VT should have access). | 05:26 |
| RAOF | at interacts with lightdm, obviously, as lightdm is doing the login bity. | 05:26 |
| tvoss | RAOF, hmmm ... | 05:27 |
| duflu | Is it right that unity-system-compositor depends on an exact version of libmirserver0? This means whenever the former fails to build, the previous build is uninstallable because libmirserver0's build number has incremented | 05:28 |
| RAOF | (if you run getfacl /dev/dri/card0 you'll get user:tvoss:rw- in the output if everything's working) | 05:28 |
| RAOF | duflu: Yes. Because the alternative is that unity-system-compositor inexplicably segfaults whenever libmirserver changes ABI, which is frequently. | 05:29 |
| tvoss | duflu, that's why we have system-compositor-testing, which is a "snapshot" of staging that avoids that problem | 05:29 |
| duflu | RAOF: Oh yes. I forgot it depends on the less-settled libmirserver rather than client | 05:30 |
| * duflu changes PPAs then | 05:32 | |
| duflu | RAOF: Umm, Jenkins just marked this as complete. Is it really? https://bugs.launchpad.net/mir/+bug/1130553 | 05:43 |
| ubot5 | Launchpad bug 1130553 in Mir "Mir does not support eglSwapInterval(0)" [Medium,Fix committed] | 05:43 |
| RAOF | Once the corresponding mesa has built, yes. | 05:44 |
| tvoss | RAOF, can you give me a status of buffer_age, that is, take a look to what degree we have it wired up? | 05:50 |
| RAOF | tvoss: Looks like it's not exposed to EGL. | 05:52 |
| tvoss | RAOF, okay, thanks | 05:52 |
| duflu | That reminds me... When I wrote fingerpaint and needed single-buffering, I thought a nice alternative might be to have some client-side visibility of aging buffers. It would have been much more efficient if I knew the API would guarantee persistence of some sort...? | 05:52 |
| tvoss | RAOF, is it a huge benefit to wire it up now? | 05:53 |
| duflu | ... that is after-all the intention of buffer_age (http://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_buffer_age.txt) | 05:56 |
| duflu | RAOF: I can deduce that X-something is meant to update the DRI device perms. But what? | 06:37 |
| duflu | It can only know to do that after a user as logged in. So maybe it's a hook in the X graphics driver we broke? | 06:37 |
| duflu | RAOF: I can deduce that X-something is meant to update the DRI device perms. But what? | 06:40 |
| duflu | It can only know to do that after a user as logged in. So maybe it's a hook in the X graphics driver we broke? | 06:40 |
| RAOF | No, it's something to do with our login-tracking infrastructure. | 06:40 |
| RAOF | Because logging in to a VT sets the acl correctly. | 06:41 |
| duflu | RAOF: Where does such infrastructure live? | 06:41 |
| RAOF | logind or consolekit, I believe. | 06:41 |
| duflu | libck-connector0? | 06:41 |
| RAOF | On Saucy we shouldn't be using consolekit, so logind. | 06:42 |
| RAOF | Wooo! | 06:43 |
| RAOF | loginctl is the command to check, I think. | 06:44 |
| RAOF | Hm3. | 06:44 |
| RAOF | I seem to have three login sessions, one of which does not have a SEAT attached. | 06:44 |
| RAOF | So, now that I've got unity-system-compositor doing some loging, I'm going to reboot and see what's happening when it doesn't work on boot. | 06:45 |
| RAOF | Ok. So, unity-system-compositor dies with no output before “I0618 16:52:50.382107 2032 glog_logger.cpp:80] [graphics] Successfully setup native resources.” | 06:55 |
| RAOF | Also, it looks like XMir sessions get registered with logind but not associated with a seat, which is plausibly the reason for the permission problem. | 06:56 |
| RAOF | It's Zoë | 06:56 |
| RAOF | -time, but I'll come back and see what's what when that's done. | 06:56 |
| tvoss | RAOF, thx for the feedback :) can you ping me once back? | 07:44 |
| RAOF | tvoss: Back for 20 minutes or so before the next round of Zoination. | 07:46 |
| tvoss | RAOF, how can we move ahead while you are offline? Trying to get a quick tasklisk down | 07:47 |
| RAOF | tvoss: For the plymouth-doesn't-die-on-boot thing, tracing the code to see what could cause unity-system-compositor to bail *before* it would normally log “[graphics] Successfully setup native resources” would be the way to go. | 07:48 |
| tvoss | RAOF, noted down | 07:48 |
| tvoss | RAOF, got a branch up that people can get started with or is this in trunk? | 07:49 |
| RAOF | For the “No accel in XMir” problem, checking the logind documentation/source to see how/where/why it doesn't set the /dev/dri/* acl. | 07:49 |
| RAOF | Hm, no branch yet. Let me push those up. | 07:49 |
| tvoss | RAOF, ack | 07:50 |
| RAOF | So, getting debugging info out of unity-system-compositor requires lp:~raof/mir/unity-system-compositor-commandline-passing | 07:52 |
| tvoss | RAOF, cool, thanks | 07:52 |
| duflu | tvoss: No accel: https://bugs.launchpad.net/mir/+bug/1191937 | 07:53 |
| ubot5 | Launchpad bug 1191937 in Mir "loss of x acceleration when xmir is loaded" [Critical,In progress] | 07:53 |
| duflu | Plymouth CPU: https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1192051 | 07:53 |
| ubot5 | Launchpad bug 1192051 in plymouth (Ubuntu) "plymouthd spinning at 100% CPU" [High,New] | 07:53 |
| RAOF | tvoss: Also needs lp:~raof/mir/lightdm-enable-u-s-c-logging | 07:53 |
| tvoss | duflu, great, thx | 07:53 |
| RAOF | So, it looks like pam-systemd is responsible for setting up the seat thingies. | 07:59 |
| RAOF | Hm. Or maybe not? | 08:01 |
| tvoss | RAOF, who might be able to clarify here? | 08:02 |
| RAOF | pitti knows systemd best, I think. | 08:02 |
| RAOF | So, I think dumping the dbus traffic to org.freedesktop.login1 would be instructive. | 08:09 |
| tvoss | RAOF, cool | 08:09 |
| tvoss | alan_g, ping | 08:14 |
| RAOF | Gargh, logind. | 08:19 |
| RAOF | VT != session. | 08:19 |
| alf | RAOF: tvoss: duflu: Have you seen any problems with VT switching with Mir in saucy? Every time I try to VT switch my graphics hang... (everything worked fine in raring) :/ | 08:27 |
| duflu | alf: I did have that bug Alan fixed but haven't tested the fix since it landed(?) | 08:28 |
| duflu | alf: Also I logged: https://bugs.launchpad.net/mir/+bug/1189770 | 08:28 |
| ubot5 | Launchpad bug 1189770 in Mir "[regression] Killing Mir with Ctrl+C often leaves the screen blank and difficult to recover " [High,New] | 08:28 |
| duflu | alf: The client's meant to hang right? So you mean your host hangs? | 08:29 |
| alf | duflu: my whole system hangs, sometimes I can't even ssh :/ | 08:30 |
| duflu | alf: I did see one intel GPU hang kernel message (and actual hang) today | 08:30 |
| duflu | But only one | 08:30 |
| duflu | on saucy | 08:30 |
| alan_g | tvoss: pong (sorry missed you) | 08:31 |
| * duflu wonders why we're not considering the bug to be in lightdm as he looks at the lightdm source (seating logic) | 08:38 | |
| duflu | or src/seat-unity.c ;) | 08:42 |
| hikiko | question: | 09:00 |
| Stskeeps | g 21 | 09:00 |
| hikiko | (hello!) | 09:00 |
| hikiko | I am checking the demo_client_accelerated.cpp | 09:01 |
| hikiko | there's no MirDisplay or something? you create windows using egl (EGLDisplay) and pass the egl surface to mir? | 09:01 |
| hikiko | it seems that the client does the rendering using EGL :s but I might be wrong | 09:04 |
| duflu | hikiko: "Window" creation: surface = mir_connection_create_surface_sync(connection, &request_params); | 09:10 |
| hikiko | oh yes there's MirSurface :) sorry! | 09:11 |
| RAOF | Aha! | 09:26 |
| RAOF | get_seat_from_display in systemd/login/pam-module.c | 09:26 |
| tvoss | alan_g, RAOF is looking into the issue, too | 09:27 |
| * alf just recovered from another saucy graphics crash... | 09:27 | |
| alan_g | tvoss: should be move discussion where he can see it? | 09:28 |
| alan_g | *we | 09:28 |
| tvoss | alan_g, sure | 09:28 |
| duflu | alf: Just saw: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/761065/comments/86 | 09:28 |
| ubot5 | Launchpad bug 761065 in linux (Ubuntu Natty) "[Sandybridge] Spurious "*ERROR* Hangcheck timer elapsed... blt ring idle" messages in dmesg when using compiz" [Medium,Fix released] | 09:28 |
| duflu | RAOF: Oh good. I was trying to learn about "seats" and systemd | 09:28 |
| duflu | alan_g, the discussion is open here: https://bugs.launchpad.net/lightdm/+bug/1191937 | 09:30 |
| ubot5 | Launchpad bug 1191937 in Light Display Manager "loss of x acceleration when xmir is loaded" [Undecided,Confirmed] | 09:30 |
| alf | duflu: Thanks, but this happens on radeon. This time I just tried to stop a mir client and server and the whole system froze :(, plus I can't get find any useful log messages about what happened... | 09:30 |
| duflu | Hurray for new kernels and alpha distros | 09:30 |
| RAOF | So, I think I see where it's going wrong. pam-systemd tries to do a reverse-lookup from the DISPLAY socket to the VT, and hence the seat. It does this by looking up the controlling tty of the xserver process. I don't _think_ that will be a VT in the nested case, so this fails. | 09:34 |
| RAOF | And now, dinner. | 09:35 |
| alan_g | RAOF: just been looking at failures in EGLHelper::setup (i.e. before the "Sucessfully setup" log) - the exceptions would be caught in main() and reported to std::cerr. Am I right in thinking this won't be captured? | 09:38 |
| * tvoss is compiling piglit :) | 09:41 | |
| * tvoss notes: running piglits sanity tests results in unity crashing :) | 09:48 | |
| pitti | tvoss: hello | 09:54 |
| tvoss | hey pitti :) | 09:54 |
| tvoss | pitti, we are running into an issue where hardware accel for mir as the system compositor is not working due to the acl for /dev/dri* not being setup correctly | 09:55 |
| tvoss | pitti, RAOF had tracked it down to: <RAOF> So, I think I see where it's going wrong. pam-systemd tries to do a reverse-lookup from the DISPLAY socket to the VT, and hence the seat. It does this by looking up the controlling tty of the xserver process. I don't _think_ that will be a VT in the nested case, so this fails. | 09:55 |
| tvoss | systemd/login/pam-module.c | 09:56 |
| pitti | tvoss: so that's the per-user-session MIR instance? that runs as the user? | 09:57 |
| pitti | or is that the system-wide compositor? | 09:57 |
| tvoss | pitti, nope, that's the system-wide Mir session, being started by ligthdm | 09:57 |
| pitti | which runs as some system user? | 09:57 |
| tvoss | pitti, yup | 09:57 |
| pitti | by lightdm? that sounds strange | 09:57 |
| pitti | I thought we'd have MIR running right from the start, for booting and lightdm | 09:58 |
| tvoss | pitti, that's the goal, right now, it's lightdm starting Mir | 09:58 |
| tvoss | pitti, for that, we have https://launchpad.net/unity-system-compositor | 09:58 |
| tvoss | pitti, which takes over the seat essentially | 09:58 |
| pitti | tvoss: which user is that running as? | 09:58 |
| tvoss | pitti, checking ... | 09:59 |
| pitti | tvoss: i. e. not "root" and not "martin", but it would be a system user like "lightdm" or "mir"? | 09:59 |
| tvoss | pitti, yup | 09:59 |
| pitti | ok, this most likely doesn't have a PAM session | 10:00 |
| RAOF | alan_g: No, stderr should be captured by the log. | 10:00 |
| pitti | and also, session tracking wouldn't really apply to this AFAICS | 10:00 |
| pitti | so it seems to me that it would be prudent to put this system user into the video group? | 10:00 |
| RAOF | http://paste.ubuntu.com/5776654/ | 10:01 |
| RAOF | pitti: c3 is my user XMir session, as started by lightdm. c1 is a VT login. | 10:02 |
| RAOF | pitti: And the problem is that - if I don't have a VT session logged in - my user isn't added to the /dev/dri/* acl, because logind doesn't have it associated with a seat, and logind only sets the acls for seated-things. | 10:03 |
| pitti | right; we don't want ACLs for non-seat logins such as cron or ssh | 10:03 |
| pitti | RAOF: so lightdm starts a session which is basically xmir, which then starts the "real" session (like unity)? | 10:04 |
| RAOF | pitti: lightdm basically starts Xservers as normal. | 10:04 |
| RAOF | pitti: It's just that lightdm *first* starts the system-compositor, doesn't VT switch, and hooks all the Xservers up with unity-system-compositor. | 10:05 |
| pitti | RAOF: ah, so the concept of session tracking via observing VT switches doesn't work any more | 10:06 |
| RAOF | pitti: Correct. | 10:07 |
| RAOF | All the sessions run on the same VT. | 10:07 |
| tvoss | mlankhorst, ping | 10:07 |
| pitti | RAOF: so I guess ATM all sessions are "active" at the same time | 10:09 |
| RAOF | pitti: Correct - as you can see, both my VT session and XMir session are active, because they both happen to be on VT 1. | 10:09 |
| pitti | RAOF: is there an equivalent of $DISPLAY, i. e. how does a Mir-aware program know which session it belongs to? | 10:12 |
| mlankhorst | tvoss: pong | 10:12 |
| pitti | RAOF: I guess we'd need to teach logind about that method then, unless we still have $DISPLAY (that might even be enough for the XMir case) | 10:12 |
| RAOF | pitti: We still have $DISPLAY (as you can see from my output), but I *don't* think you can reverse map $DISPLAY to the VT it's running on. | 10:13 |
| RAOF | pitti: At least, it looks a lot like pam-systemd as it currently stands cannot do that. | 10:13 |
| pitti | right, that's where things go wrong | 10:13 |
| pitti | RAOF: are you sure the problem is in the PAM module? | 10:13 |
| pitti | RAOF: that just tries to separate the cases of "VT given" from "display given", and passes it as two separate arguments to CreateSession | 10:14 |
| mlankhorst | RAOF: can you accept the packages still in new? https://launchpad.net/ubuntu/precise/+queue?queue_state=0 | 10:14 |
| RAOF | pitti: No, but the output of loginctl suggests that the session was set up without a VT set. | 10:14 |
| pitti | RAOF: I had thought the problem is in logind.c itself, in the actual session/seat tracking | 10:14 |
| RAOF | mlankhorst: Do they need to be in main, or universe? | 10:15 |
| mlankhorst | main | 10:15 |
| RAOF | mlankhorst: They need to be in main, don't they. Cool. | 10:15 |
| duflu | pitti: We have hidden the information (clients should pass path NULL) but it is always using /tmp/mir_socket for now | 10:15 |
| duflu | No environment is used | 10:16 |
| RAOF | mlankhorst: Done. | 10:16 |
| mlankhorst | thanks! | 10:17 |
| RAOF | We're likely to end up either with an environment variable or just a well-known path. I think we're more likely to end up with the latter. | 10:17 |
| pitti | RAOF: hm, so we are only ever going to have one VT for everything, we can't use the VT number to track sessions | 10:17 |
| duflu | Possibly both eventually. But I was trying to keep the path a secret to avoid hard-coded chaos | 10:18 |
| RAOF | Indeed. | 10:18 |
| pitti | RAOF: hence my feeling that this needs to be changed in the active session tracking | 10:18 |
| RAOF | Oh, we *also* need to change the active session tracking. | 10:18 |
| RAOF | But we need that to support multi-user. | 10:18 |
| RAOF | We need "actually associate with a seat" for it to work at all ;) | 10:18 |
| pitti | for seat, yes | 10:19 |
| pitti | RAOF: that will only cover devices which have per-seat ACLs though, like /dev/dri | 10:20 |
| pitti | not the per-session ones like audio | 10:20 |
| pitti | (or usb) | 10:20 |
| RAOF | But that's ok because all sessions are treated as active :) | 10:20 |
| pitti | not really | 10:21 |
| pitti | we only want the active session to have access to audio devices, USB sticks, scanners, cameras and the like | 10:21 |
| RAOF | Oh, yes. | 10:21 |
| pitti | otherwise there wouldn't be a clear "owner" of them, and concurrent access | 10:21 |
| RAOF | But for a first go, having a single user have access to those things is nice! | 10:21 |
| * duflu thinks these guys have it under control and goes to make dinner | 10:21 | |
| pitti | yes | 10:21 |
| pitti | RAOF: so the problem there is that the xmir process doesn't have any tty associated to it? | 10:24 |
| RAOF | That is my suspicion. I haven't checked that (and it's 8:30 here, so I'm not likely to tonight :)) | 10:24 |
| pitti | RAOF: you can check the xmir process' /proc/pid/stat | 10:28 |
| pitti | the TTY is the 4th number after the state ('R') | 10:28 |
| RAOF | 0, apparently. | 10:29 |
| RAOF | Which should be a valid TTY. | 10:29 |
| pitti | no, it's "nothing" | 10:29 |
| pitti | that's a device number | 10:29 |
| pitti | i. e. a major/minor in one int | 10:29 |
| pitti | e. g. my bash has 34825, which is major 136, minor 9 | 10:29 |
| pitti | i. e. /dev/pts/9 | 10:30 |
| pitti | tty would be major 4, i. e. 1024+ttynumber | 10:30 |
| RAOF | Ah, right. | 10:30 |
| pitti | my X process has 1031, i. e. tty7 | 10:30 |
| RAOF | Yeah, no tty for xmir. | 10:30 |
| pitti | ok, that's a bit odd | 10:31 |
| pitti | RAOF, tvoss ^ so that seems strange for a process not not have any tty/pty; is that deliberate? | 10:34 |
| pitti | phone, brb | 10:35 |
| tvoss | pitti, wrong person to ask | 10:35 |
| * tvoss that is | 10:35 | |
| RAOF | pitti: No, that actually seems perfectly sane - XMir doesn't open a tty, so it won't have a controlling tty. | 10:42 |
| RAOF | X would normally open a tty in order to do VT switching, but XMir can't do that. | 10:43 |
| pitti | ok, RAOF is gone | 10:48 |
| pitti | so, I'll make some investigations how that could happen; I'm not that proficient in that tty/pty area | 10:49 |
| didrocks | (told the guy knowing on which major block device numbers are using the ttys) | 10:50 |
| didrocks | apart if you cheater with ls -l /dev/tty7, but I would be disappointed :) | 10:50 |
| ogra_ | note that the ubuntu touch kernels largely dont have VT support enabled | 10:57 |
| ogra_ | (there are no /dev/yyz[0-9] at all | 10:57 |
| ogra_ | ) | 10:57 |
| ogra_ | err | 10:57 |
| ogra_ | tty | 10:57 |
| === greyback is now known as greyback|lunch | ||
| alan_g | \o/ My desktop finally booted a saucy image | 12:13 |
| === greyback|lunch is now known as greyback | ||
| === francisco is now known as Guest7324 | ||
| alf | alan_g: Have you tried using clang on saucy? | 13:48 |
| alan_g | alf not yet | 13:48 |
| alf | alan_g: ok, I am getting stddef.h cannot be found errors | 13:49 |
| alan_g | alf: I've just got to the point of being able to build g++/naive on my desktop - will try clang next if it helps | 13:52 |
| alan_g | alf: just a thought - you did vape the cmake cache first? | 13:52 |
| alan_g | Hmm - "4 tests failed" | 13:53 |
| alf | alan_g: no haste, it's not blocking me, just wondering if you had seen it. I did a build in a clean dir, plus just compiling a trivial .c file fails with clang | 13:53 |
| alan_g | sounds like clang isn't installed correctly | 13:54 |
| alan_g | alf: FWIW clang compiles fine for me (tests hang of course) | 14:18 |
| alf | alan_g: thanks, so I guess something went wrong during the upgrade | 14:19 |
| alan_g | alf: I ended up repartitioning my system disk before I got saucy to boot | 14:20 |
| alan_g | So, for once, I've a pretty clean install | 14:20 |
| alf | alan_g: do you have clang 3.2 or 3.3? | 14:21 |
| alan_g | 3.2 | 14:22 |
| alf | alan_g: can you please try and pastebin the output of "clang -v bla.c" (where bla.c includes eg. stdio.h) | 14:23 |
| alan_g | alf: https://pastebin.canonical.com/93010/ | 14:28 |
| alf | alan_g: thanks | 14:29 |
| alf | alan_g: heh, just removing and reinstalling clang fixed things... | 14:43 |
| alan_g | alf: of course. (That's the fun of upgrades) | 14:50 |
| racarr | tMorning | 15:01 |
| kdub_ | morning | 15:03 |
| alan_g | afternoon | 15:07 |
| racarr | ** DONE Land platform API... | 15:23 |
| racarr | that was a todo for...too long | 15:23 |
| tvoss | racarr, it's in? :) | 15:25 |
| racarr | yep, qtubuntu or today | 15:26 |
| racarr | for* | 15:26 |
| tvoss | racarr, not bad :) not bad :) | 15:27 |
| === alan_g is now known as alan_g|afk | ||
| alf | kdub_: IIRC, at some point you proposed some noexcept changes for NiceMock/StrickMock. Any update? (I updated our internal gmock and have come across the same issues again with 4.7... 4.8 works fine without any change) | 15:59 |
| === olli_ is now known as olli | ||
| kdub_ | alf, no, not a lot of movement upstream https://groups.google.com/forum/?fromgroups#!topic/googlemock/ZO4Q1vR7XfM | 16:07 |
| alf | kdub_: ok, I will apply the patch manually then | 16:08 |
| === alan_g|afk is now known as alan_g | ||
| racarr | alan_g: Applied your suggestion (misread them the first time ;)) to https://code.launchpad.net/~robertcarr/mir/improve-input-acceptance/+merge/169483 | 16:40 |
| racarr | if you have time for another review before EOD | 16:40 |
| racarr | I have to write some acceptance tests today and was hoping to use it :D | 16:40 |
| alan_g | racarr: sure | 16:40 |
| racarr | thanks :) | 16:41 |
| === mmrazik is now known as mmrazik|afk | ||
| racarr | I feel like oprah on launchpad today | 17:17 |
| racarr | and you get an approve! and you get an approve! and you get an approve! | 17:17 |
| === alan_g is now known as alan_g|EOD | ||
| racarr | kdub_: Is there any trick for adb shell just...working weird in terms of terminal functionality? i.e. every text editor has some weird glitches | 17:26 |
| racarr | that make it super hard for me to edit files on the phone | 17:26 |
| kdub_ | no, not really... unless i'm investigating kernel crashes or something, i usually ssh in | 17:26 |
| mterry | racarr, I'm trying to follow http://studio.sketchpad.cc/gmY0M6iqeh but ran into a problem with boost | 17:27 |
| racarr | mterry: Of what sort? | 17:27 |
| mterry | racarr, I know! Like nano doesn't like Enter | 17:27 |
| mterry | racarr, I am at the ./build -s step of unity | 17:28 |
| mterry | racarr, and it wants to install libboost1.49-dev, which conflicts with libboost1.53-dev | 17:28 |
| racarr | mterry: hmm | 17:29 |
| racarr | I don't have an immediate guess as to why that happened...but I think | 17:29 |
| racarr | you could find the explicit 1.49 dependency and just make it | 17:29 |
| racarr | non explicit or 1.53 | 17:30 |
| mterry | racarr, I see your platform-api change landed in trunk, but not yet the packaging changes to build with mir? | 17:30 |
| racarr | mterry: Thoe live in lp:~robertcarr/platform-api/mir-with-packaging | 17:30 |
| racarr | we are doing parallel CI | 17:31 |
| racarr | also you can use bzr branch lp:~unity-team/unity/phablet-integrate-mir | 17:31 |
| racarr | instead of phablet-tuesday now | 17:31 |
| racarr | XD | 17:31 |
| racarr | mterry: Im in the process of testing out the qtubuntu packaging build on the phone | 17:32 |
| racarr | but um. had to reimage my phone | 17:32 |
| racarr | and building everything takes a long time | 17:32 |
| racarr | I really enjoy this sketchpad thing | 17:33 |
| racarr | XD | 17:33 |
| mterry | racarr, ah, looks like phablet-integrate-mir needs to merge from trunk. It has boost1.49 in its ./build script, but trunk has fixed that | 17:40 |
| mterry | and by trunk, I mean unity/8.0 | 17:40 |
| racarr | ah probably | 17:42 |
| racarr | I dont think I am in unity-team so you will have to do it locally for now | 17:42 |
| racarr | mterry: ^ | 17:42 |
| racarr | oh | 17:42 |
| racarr | I definitely am | 17:42 |
| racarr | merging and what not | 17:43 |
| racarr | hmm | 17:47 |
| racarr | I need to find a base revision manually apparently | 17:47 |
| racarr | hmm | 17:50 |
| racarr | 91 conflict | 17:50 |
| racarr | all time record | 17:50 |
| racarr | I think I don't understand bzr | 17:58 |
| racarr | I found a base revision but then apparently it becomes a 'reverse cherry pick' and loses branch history | 17:59 |
| racarr | and also I cant use weave merge | 17:59 |
| racarr | oh | 18:04 |
| racarr | I see | 18:04 |
| racarr | they literally have no common ancestory because its | 18:04 |
| racarr | a new repo | 18:04 |
| racarr | -.- | 18:04 |
| kdub_ | android drivers don't like us shuffling the buffers out from underneath them while we ignore their reference requests... | 18:54 |
| === francisco is now known as Guest75516 | ||
| arsson | just manage to install unity-system-compositor and unity was gone but i have two cursors | 20:29 |
| arsson | you do some strange thing in there :) | 20:30 |
| tvoss | arsson, that's expected :) | 20:30 |
| tvoss | arsson, raof is working on getting rid of that, it's only the hw cursor not being wired up to the X side completely, yet | 20:30 |
| tvoss | arsson, please note that you might be running unaccelerated X right now, too, as the acl on /dev/dri* are not setup correctly (being worked upon, too) :) | 20:31 |
| tvoss | arsson, which ppa did you use? | 20:31 |
| arsson | stagein | 20:31 |
| arsson | Mir staging ppa | 20:32 |
| tvoss | arsson, cool, thx | 20:33 |
| arsson | well unity-system-compositor is not installable anymore | 20:33 |
| arsson | that was quik | 20:33 |
| tvoss | arsson, yup, the components in there rev too fast, that's why we have system-compositor-testing ppa, same team | 20:34 |
| arsson | do i dare to try that? | 20:36 |
| tvoss | arsson, not yet, you should wait for the permission issue to be fixed | 20:37 |
| tvoss | arsson, I'm waiting for that, too :)) | 20:37 |
| arsson | ok. lets watch porn then! :) | 20:38 |
| tvoss | arsson, I'd rather prefer wine, but have fun :) | 20:39 |
| kgunn | :) | 20:46 |
| kgunn | robert_ancell: anything i can do here to help debug or try | 20:48 |
| robert_ancell | kgunn, you get the lock up on boot right? | 20:49 |
| kgunn | robert_ancell: depends on definition of lock up.... | 20:50 |
| robert_ancell | fails to get to greeter? | 20:50 |
| kgunn | i was getting to the little gui...."you are running in low gfx mode".....but effectively stuck there | 20:51 |
| kgunn | robert_ancell: for sure...fails to get greeter | 20:51 |
| robert_ancell | kgunn, ugh, I haven't seen that | 20:51 |
| robert_ancell | I'm trying to track down plymouthd using 100% CPU and the system-compositor failing to start | 20:53 |
| kgunn | robert_ancell: yeah...but didn't we determine i had an incompat lightdm mismatched | 20:53 |
| kgunn | robert_ancell: wonder if i need to ppa-purge....start fresh | 20:54 |
| * kdub_ was hoping we didn't have to give android drivers strong refs to their buffers... looks we do though | 20:58 | |
| kdub_ | will get rid of that weird "ensure_no_live_buffers_are_bound()" interface on mg::GLRenderer | 20:59 |
| kdub_ | the whole 'dynamic buffers!' has been good for polishing out some rough edges of the android system | 21:07 |
| kdub_ | maybe even one day, we'll be able to resize ;-) | 21:08 |
| kgunn | kdub_: don't tease | 21:29 |
| racarr | Hmm | 22:39 |
| racarr | so now when I try and build trunk I get warnings that libEGL.so may conlict withw | 22:39 |
| racarr | libmirclient.so | 22:39 |
| racarr | and then check-discover-acceptance-tests | 22:39 |
| racarr | crashes | 22:39 |
| racarr | any ideas? | 22:40 |
| racarr | I guess my mesa needs updating | 22:42 |
| kdub_ | racarr, yep | 23:08 |
| RAOF | Mornin' all. | 23:21 |
| racarr | kdub_: is the mesa I need int he PPA? | 23:21 |
| racarr | I am having series of strange link errors | 23:21 |
| racarr | Morning RAOF :) | 23:22 |
| RAOF | racarr: Grr. Let's have a butchers. | 23:22 |
| racarr | blerp? | 23:23 |
| RAOF | “butcher's hook” → “look” | 23:23 |
| racarr | this seems like | 23:24 |
| racarr | some pretty advanced rhyming slang | 23:24 |
| kdub_ | lets see... | 23:27 |
| RAOF | It's the standard double-indirect cockney rhyming slang! | 23:27 |
| === marlinc is now known as marlinc|away | ||
| RAOF | racarr: The mesa you need is *not* in the PPA, apparently because Launchpad hasn't noticed that libmirclient-dev 0.0.4 has built. | 23:29 |
| racarr | oh | 23:30 |
| racarr | that sounds suspiciously similar to something that would cause the link errors | 23:30 |
| RAOF | Stupid launchpad. It's meant to trigger when the dependencies of a dep-wait package are built! | 23:30 |
| racarr | I am getting | 23:30 |
| RAOF | Anyway, amd64 is now appears to be building, so everything should be peachy soon. | 23:31 |
| RAOF | racarr: What do I have to do to get unity-system-compositor to *not* appear to freeze when pressing <alt>+<left>? | 23:32 |
| RAOF | (Because that's going to the kernel VT subsystem, which is switching VTs, so unity-system-compositor is suspended) | 23:32 |
| racarr | RAOF: I think something like this | 23:34 |
| racarr | https://code.launchpad.net/~robertcarr/mir/disable-sequences-and-add-terminate-handler/+merge/164014 | 23:34 |
| racarr | in particular around here | 23:34 |
| racarr | + int make_raw(int vt_fd) | 23:34 |
| RAOF | Oooh, of course. | 23:37 |
| RAOF | I could totally do that in u-s-c. | 23:37 |
| kdub_ | RAOF, thanks for handling the driver bump, btw | 23:47 |
| RAOF | No probelm. | 23:47 |
| RAOF | Oh, *arse*. | 23:48 |
| RAOF | 0.4 ≠ 0.0.4 | 23:48 |
| RAOF | *That's* why! | 23:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!