[00:00] racarr: When jenkins picks up the new commits to mesa you'll have a mesa that actually builds in the PPA. [00:00] RAOF: Yay, thanks, in the interim I justs purged the ppa [00:00] dont need to run mir right now just build it XD [00:01] :) [00:26] What the what, launchpad? [00:28] In what way is 0.0.4bzr756saucy0 not >= 0.0.4? === RAOF_ is now known as RAOF [01:08] ??? And mesa is building on armhf for some reason? [01:14] RAOF, can you clarify the purpose of the system-compositor-testing PPA? What is different over the testing PPA (just that the packages are manually synchronized?) [01:14] robert_ancell: That is exactly the difference, yes. [01:15] ok [01:15] robert_ancell: It's to avoid https://bugs.launchpad.net/unity-system-compositor/+bug/1191338 [01:15] Launchpad bug 1191338 in Unity System Compositor "Dependency on libmirserver is brittle" [Undecided,Confirmed] [01:15] * duflu reboots [01:15] yeah, thought so [01:16] RAOF any more info on the dri permissions? I was wondering if it might be a side-effect of the DRM going via the system compositor (wild speculation here) [01:17] robert_ancell: logind doesn't associate XMir sessions with a seat, so doesn't set up the dri permissions. [01:17] RAOF, ok cool. So I need to track down why logind isn't happy [01:17] And it fails to associate the XMir session with a seat because the XMir server doesn't have a controlling tty. [01:17] We could set XDG_SEAT="seat0" in the pam environment. [01:18] RAOF, but we don't do that for the VT+X case and that works [01:18] right? [01:19] Correct, but in that case X is opening a tty (because it needs to do VT manipulation) and so logind can do a reverse-lookup from $DISPLAY to seat. [01:19] ah [01:19] yay for hacks behind the scene [01:20] Ding! [01:21] Is that info in the bug report? [01:21] Yes [01:36] Further to my last point it's then ironic that ppa:mir-team/staging just broke my system :/ [01:37] Hah! [01:38] robert_ancell: Can we please make sure type!=unity for the staging PPA by default? It means our dev environments could become unusable at the first sign of any system compositor/lightdm problems [01:38] duflu: I can flip the default. [01:38] duflu, yeah, that seems fair [01:39] robert_ancell: Also, when I went back to vanilla lightdm... it just does nothing on type=unity instead of defaulting to something that works. Is that intentional? [01:40] duflu, correct - if the seat type is unknown it stops (and failsafe X should work) [01:40] duflu: You can run “dpkg-reconfigure unity-system-compositor” and select “no” to undefault. [01:40] No failsafe. Just VT console [01:40] Ta RAOF [01:46] Try again... === jono is now known as Guest14995 [02:29] duflu: That worked, right? [02:29] RAOF: Didn't have to. After I reinstalled I have lightdm being kept back again ;) [02:29] Heh. [02:30] Hence no unity-system-compositor to reconfigure [02:49] thomi: Are you here? What's happening with mesa autolanding? [02:52] RAOF: Where did the discussion end with pitti last night? [02:53] That logind needs to learn that VTs are not the same as sessions, and that he'll look into that. [02:54] RAOF: Hmm, might be dangerous to assume there's nothing we need to do. Are you sure he's doing it? Should we? [02:54] Oh, we *also* need to tell logind about the seat. [02:55] RAOF: I tried a system-wide XDG_SEAT=seat0 last night but obviously that was too wishful [02:55] Or the environment got clobbered [02:55] It needs to be in the pam environment; I'm not sure if you can influence that with /etc/environment. [02:56] I'm heading out for lunch; back in an hour or so, whereupon I shall investimigate further. [02:56] RAOF: Tell logind precisely in what form? [02:56] OK, bye [03:34] That's weird. My xmir login on top of unity-system-compositor appears on every second (even) VT... F2, F4, F6 [03:34] robert_ancell, ^ [03:34] duflu, odd [04:24] RAOF, aw yeah, that XDG_SEAT does the trick! [04:28] <92AAAUIMO> robert_ancell: Woo! One down. [04:28] 92AAAUIMO, new nick? [04:28] <92AAAUIMO> …I did not notice that. === 92AAAUIMO is now known as RAOF [05:10] god morning gentlemen :) [05:10] +o, obviously [05:10] RAOF, ping [05:10] tvoss: Pong. [05:10] RAOF, any luck with the dri permissions? [05:11] Yes; Robert's setting XDG_SEAT from lightdm, and that unconfuses logind. [05:13] \o/ [05:13] RAOF, does that solve the plymouth issue, too? [05:13] No. [05:14] RAOF, hmmm, do we have any idea for the plymouth issue, then? [05:14] Alan was looking at that last night. I don't know if he found anything because my IRC bouncer died. [05:16] RAOF, ah okay, will grab alan then [05:17] RAOF, piglit running in the lab: https://jenkins.qa.ubuntu.com/view/All/job/piglit-nvidia-gt440-le-daily/1/artifact/results/html/index.html [05:17] https://jenkins.qa.ubuntu.com/view/All/job/piglit-intel-2500-le-daily/15/artifact/results/html/index.html [05:17] https://jenkins.qa.ubuntu.com/view/All/job/piglit-radeon-hd7450-le-daily/1/artifact/results/html/index.html [05:17] running a daily cadence [05:18] I thought about running selected phoronix tests on the infrastructure against XMir, too [05:18] makes sense? [05:18] Yeah, that could work. [05:20] tvoss: I was going to investigate the plymouth spin momentarily [05:20] * duflu wishes people would mark things as in progress so we don't all work on the same bugs [05:22] duflu, +1 [05:22] duflu, might make sense to sync with alan [05:22] duflu, with the plymouth out of the way, we would have something dogfoodable and runnable in the lab at scale [05:24] robert_ancell, good morning/evening :) [05:24] tvoss, hello [05:28] robert_ancell, how goes? [05:28] RAOF, does XMir definitely not use any VTs? I seem to have the compositor running on 7 but XMir was on 8 [05:28] tvoss, busy with change in priorities [05:29] robert_ancell, I can imagine :) [05:29] robert_ancell: I'm pretty sure XMir doesn't do any VT things; let me check again. [05:34] RAOF, I notice I'm actually setting 'vt7' as an arg to the X server, not sure if that would have any effect [05:34] I believe that it won't. [05:39] robert_ancell: Yeah, xorgMir => xorgHWOpenConsole == FALSE => dontVTSwitch == TRUE. [05:39] RAOF, but does it allocate a VT? [05:40] There is a -novtswitch option that will stop it automatically switching to a VT, but that doesn't stop it running on one [05:41] robert_ancell: It doesn't call xf86OpenConsole, so it shouldn't allocate a VT. [05:41] ok [05:44] tvoss: phoronix does make sense, got to thinking late yesterday....we need something sub 60fps specifically for xmir [05:44] i added a work item for it in the xorg bp for when we have accel x back [05:44] kgunn, yup, that's what I'm thinking, and I think that we should get started broadly and focus on specific benchmarks as we see issues arising [05:45] tvoss: the nexuiz wasn't too long in terms of run time (at least shorter than openarena) [05:46] and it was 21fps avg [05:46] kgunn, on what kind of system? [05:46] on my i5 w/ sandybridge [05:46] kgunn, let's leave runtime considerations aside for the moment, that's a luxury issue to solve/optimize when we have the stuff running on a cadence [05:47] kgunn: Actually, we don't need < 60 fps for xmir, because xmir doesn't support vblankd swapbuffers. [05:48] RAOF: it is 1am...do you mean its not vsync'd (it tears) ? [05:48] kgunn: Correct. Plus, because of this, it's not capped to 60fps. [05:48] Although the *output* is, because unity-system-compositor is locked to 60fps. [05:49] glxgears: 11785 frames in 5.0 seconds = 2356.963 FPS [05:50] RAOF: actually that's perfect....and still what we want [05:51] technically, if there is any overhead to xmir, it would still show up [05:51] It would indeed. [05:51] in a benchmark that's already running sub 60fps due to load [05:51] and i think that would answer the faq that will come from people [05:52] "how much will xmir cost me in perf" [05:52] I accidently awake. Happy almost weekly meeting :) [05:52] racarr: happy almost weekly meeting to you too....you shouldn't have :) [05:53] * kgunn set alarm for 12:30....worried he might be in semi dream state [05:53] kgunn, couldn't we adjust the cadence on a bi-weekly basis to make it mutually less painful for the different timezones? [05:54] kgunn: I lost track of time reading [05:54] tvoss: spent time looking at this once...and basically not realistically....pretty well the only time if [05:54] kgunn, ah okay [05:54] I had the idea the other day that maybe there are two parts to the benefits of the weekly meeting [05:55] 1. High bandwidth communication [05:55] you want west coast, aus, nz, euro [05:55] but also 2. Cadence [05:55] so maybe having some sort of document [05:55] that we try and like do a "rolling" weekly meeting in (raising issues and people respond, etc) then we try and wrap up in to a consensus once a week [05:56] racarr, kdub_, alf, RAOF, duflu, meeting [05:56] hikiko, meeting [05:56] and kgunn too today :) [05:57] robert_ancell, joining in a minute [06:05] We take this opportunity for unity-system-compositor to lock up the GPU. [06:06] RAOF, :) === marlinc|away is now known as marlinc === marlinc is now known as marlinc|away [06:40] I dropped [06:41] rejoining isnt working [06:43] kgunn, alan_g might be a good match for the multi-monitor now [06:44] * duflu dropped too [06:44] Only the hangout died [06:46] Gah. The hangout is just silent [06:46] What's going on? [06:46] duflu: Thats all I can see too [06:46] duflu: INTERNETS! [06:47] I has internets [06:48] I give up. I have no video or audio now. I only see the chat [06:54] http://unity.ubuntu.com/mir/modules.html [06:55] good nightmorning :) [06:55] alan_g: You just missed the xmir party of the century [06:56] So good we broke the hangout [06:56] Someone please let me know if I missed anything important from the end of the hangout. It refuses to work now [06:56] * duflu runs to the post office [07:04] kgunn, ping...still around? [07:17] alan_g, duflu is anyone of you looking into profiling mir with callgrind right now? [07:18] tvoss: I did so just before Oakland. I will email you the results as a reminder [07:18] duflu, thanks, got the full call tree around? [07:18] tvoss: No. Those things go out of date within hours [07:18] duflu, agreed :) [07:19] duflu, do you think it makes sense for the both of us to look into that deeply? [07:20] tvoss: I was, and would like to again. But have been given different tasks for now [07:20] duflu, okay [07:20] duflu, if you can hand over your setup to me, I'm happy to have a look [07:22] tvoss: Email sent. I can't remember any specific setup other than callgrind a mir server while a client is rendering at a full 60 FPS [07:22] duflu, cool, thx [07:35] Gah! [07:36] Who knows how the saucy autolanding stuff for mesa is supposed to work? Also, why isn't it? [07:36] Or, rather, why did it work yesterday but not today? [07:37] RAOF: Didn't someone say they kicked it off manually yesterday? [07:38] tvoss: I did some callgrind a few weeks ago, but none ATM. [07:38] alan_g, ack [07:38] It kicked off automatically this morning, but only for raring. [07:38] mmrazik, ping [07:40] mmrazik, can you help us figuring out why the mesa autolanding for saucy has issues? === alan_g is now known as alan_g|afk [07:47] tvoss: do we have autolanding for mesa? [07:47] or you mean the job that just polls the git repo and dputs the newest version? [07:49] RAOF, ^? I assume the latter? [07:49] RAOF: you say it used to work? [07:50] mmrazik: I mean the latter. [07:50] well.. actually you are right [07:50] it worked [07:50] For Raring; not for saucy. [07:50] Raring pulled -mir3 (which would build if mir wasn't FTBFS on raring), but Saucy hasn't. [07:51] I think the job is broken. There is some conflict in the naming and saucy was rejected from the ppa [07:51] File mesa_9.2~git20130611.761320b1-0ubuntu0+mir3-jenkins76.tar.gz already exists in Mir staging ppa, but uploaded version has different contents. See more information about this error in https://help.launchpad.net/Packaging/UploadErrors. [07:51] Oh, right! [07:51] I think I just need to append saucy/raring to the version string [07:51] There's no release-specific string in the version. [07:51] Yeah. [07:51] uh oh [07:51] thomi was creative (if it was he) in the job :) [07:53] RAOF: the source for raring and mesa is exactly the same, right? [07:53] i.e. the same repo and everything [07:56] RAOF, mmrazik why don't we use https://launchpad.net/mesa [07:56] ? [07:56] it is synced frequently to the mesa git, too [07:58] tvoss: I don't know [07:58] I was told to use the git [07:58] mmrazik, okay [08:02] mmrazik: Yes, exactly the same for raring and saucy. [08:03] tvoss: I don't use lp:mesa because we don't have any tooling to handle git branches in bzr, and it's a huge impedence mismatch if I try. === alan_g|afk is now known as alan_g [08:05] RAOF, cool, thx for clarifying [08:19] RAOF, tvoss: I believe I fixed the mesa issues and triggered a new dput to both raring and saucy [08:19] mmrazik, awesome, thank you [08:28] mmrazik: btw, would it be possible to move our -ci and -autolanding builders to saucy? [08:29] alf: sure. We can just switch or is there anything else I need to do? [08:29] mmrazik: hopefully everything will work, just a moment to confirm with others [08:30] alan_g: duflu: tvoss: ^^ Any concerns/blockers? [08:30] alf: No I think we are saucy-ready [08:30] Other than your kernel :( [08:31] alf: I've not tested everything on saucy - but don't know of any blockers [08:31] mmrazik: ok, let's do it then [08:31] alf: Haven't tried building _on_ saucy-android [08:31] But cross compiling from saucy to saucy is all good [08:31] And saucy-desktop is very good [08:32] actually good point [08:32] I tend to forget about android [08:32] let me check if it is easy to switch it too [08:32] Umm, I mean building on saucy-panda ;) [08:33] duflu: mmrazik: is android -ci a native build? I thought it was cross-compiling? [08:33] alf: its crosscompile in pbuilder chroot [08:33] so it should be easy to switch [08:33] Cool. That's tested and working then [08:33] I'm just not sure the saucy base image is on that host but that should be easy to create [08:33] alf: I don't think we are compiling on panda at all [08:33] mmrazik, yeah the tests will fail if not built on a saucy host [08:34] duflu ^ [08:34] so let me first change the "native" raring builds [08:34] mmrazik, in summary, everything must be saucy, or nothing [08:35] duflu: even the android part? [08:35] I think it is running on a box with precise installed [08:35] duflu: mmrazik: I just saw that our vm-ci build is still quantal :) [08:36] alf: you sure? It seems its raring [08:36] changing to saucy anyway [08:37] mir-vm-* is saucy now [08:37] mmrazik, Just that running on saucy-armhf fails tests unless it was built with gcc-4.8 :/ [08:39] mmrazik: sorry, could be, I think I may have been misled by a stale link I had [08:39] I vaguely remember you pinged me about it not-so-long ago and I changed to raring [08:40] btw. I'm changing qmir, lightdm-mir, etc to saucy as well [08:40] Excellent. [08:40] [08:41] mmrazik: yes, I remembered now [08:41] RAOF: ? [08:42] duflu: Imagine me steepling my long, yellow fingers. [08:42] mmrazik: when all is done, feel free to retrigger e.g. https://code.launchpad.net/~afrantzis/mir/stream-multiple-lock-back-buffer/+merge/169841 [08:43] alf: ok. thanks [08:43] only the android is missing now [08:43] RAOF: Oh, you mean Eeeeexcellent [08:44] duflu: Indeed. But I decided that post-hoc. [08:44] mmrazik: can we also do an autolanding build e.g. for the branch mentioned above, that doesn't actually perform the final landing? Otherwise, no problem waiting for something actually to land to try -autolanding. [08:45] RAOF: can you accept the libdrm sru in precise/raring/quantal? [08:45] alf: the -ci and -autolanding jobs should be the same [08:45] in could be done without the autolanding part but I would need to clone the job and modify it [08:45] easier to either wait or re-trigger an existing MP [08:45] * duflu searches for an edition of "Increase your wordiness" [08:46] mmrazik: ok, no problem then, I didn't remember if CI builds branches independently or merges trunk first [08:46] alf: they merge trunk to detect conflicts early [08:47] mmrazik: ok [08:49] * alf is about to try out some code in a VT... let's see if this will lead to another reboot... [09:03] https://code.launchpad.net/~hikiko/mir/mir.dest-tmp/+merge/168934 triggered a new build on saucy so we will see :-) [09:03] only the android part will be raring [09:03] * mmrazik is still building the saucy chroots [09:04] too bad. Conflict there. [09:13] I didn't switch to saucy yet, do I have to? (My laptop is my main pc as well) [09:16] hikiko: you don't have to to please jenkins or something similar (although it might be easier to debug compile issues on saucy if jenkins finds some) [09:17] RAOF: heads up about mesa build failure https://launchpad.net/~mir-team/+archive/staging/+build/4727075 [09:17] btw. everything is on saucy now. I tested the clang job (works) and now I'm trying the android one [09:18] I assume the rest will just work [09:19] alf, mentioned in the meeting that he has some issues with mir, gpu and unity freezing on saucy I think that's why I am afraid to dist-upgrade does everything works fine for you? [09:22] hikiko: I will recheck soon and will let you know [09:23] thank you alf ! [09:28] alf: re the quantal links for mir-vm-ci-builds... the thing is that we re-created mir-ci (started with build #1) while the mir-vm-ci-build job is there for a while without any big change [09:28] not jenkins has some relations between upstream and downstream job [09:28] but the relation only cares about job name and build number [09:28] no unique ID [09:28] mmrazik: alf has gone (forced reboot I think) [09:28] and apparently the mir-ci job build #s are now high enough to make jenkins think that some older mir-vm-ci builds were triggered by mir-ci [09:29] alan_g: oh.. .thanks. didn't notice the quite [09:29] s/quite/quit/ [09:33] alf: welcome back [09:34] hikiko: Despite appearances, it works better for me now :) Note, though, that latest mir trunk needs latest mesa-mir, and there have been some mesa package build failures [09:34] alan_g: glad to be back ;) [09:35] alan_g: It seems that the problem is not the graphics after all. It is lttng that's crashing the system [09:37] alf: unfortunate [09:38] alan_g: Yes and no... at least I can do some useful work now :) [09:51] alf: https://code.launchpad.net/~afrantzis/mir/stream-multiple-lock-back-buffer/+merge/169841/comments/379114 [09:52] and the mir-vm-ci/quantal build link seems to be gone too [09:54] mmrazik: Great, thanks! [09:55] katie, ping [09:56] tvoss, hi [09:56] katie, can we postpone our sync-up by 30 minutes? [09:56] tvoss, sure [09:57] katie, awesome, thanks [10:05] * RAOF fixes stupid mesa build failure. [10:06] Note: you don't (or shouldn't) need that mesa to build Mir. [10:27] alf: I was looking at something else, but noticed something that seems wrong and think you probably know the answer. It seems wrong that both the_compositor() and the_compositing_strategy() depend on the_renderables(). Are they actually using disjoint subsets of that interface? (Implying that there's an interface missing.) [10:30] alan_g: yes, the_compositor just needs to know when the renderables change so it can schedule a redraw, the compositing strategy just needs to access to all the renderables [10:32] alf: that's what I thought. Thanks. [10:32] alan_g: IIRC, it's something we were aware of this from the beginning, but decided to use the same interface nonetheless [10:33] tvoss, ready? if you need more time, we can postpone and use the time with matthew tomorrow to discuss [10:33] katie, that would be great [10:34] tvoss, gives me more time to respond to your comments :) [10:34] tvoss, see you tomorrow [10:34] katie, yup :) [10:34] katie, ttyt [10:35] alan_g: You were looking into why unity-system-compositor wasn't starting up yesterday? Get anywhere? [10:38] RAOF: no. (I was mostly answering tvoss asking what could go wrong before"Successfully setup native resources") [10:39] RAOF: I'm still trying to stabilize after upgrading to saucy, so I've not tried to reproduce [10:39] alan_g: Ah, ok. That's tomorrow morning's work then. [10:41] RAOF: sorry to disappoint [10:42] * alan_g needs to reboot [10:46] * alan_g wonders why he gets "libEgl ... unsupported platform" today [10:47] Probably because mesa's currently building past the API change. [10:47] Ah, so it will probably sort itself out later. [10:48] * alan_g hates the cascade of issues following upgrading stuff [10:48] RAOF: is there anything I can look at to help with USC? [10:50] Working out why it doesn't start, and gives no output even on stderr. [10:51] That, or why, when it succeeds, it goes all “Unable to set active session, unknown client name 0” [10:54] will the above mesa problem stop it getting that far? [10:56] Probably, yes. [10:57] Jenkins should pick up the fixed mesa in the next 15 minutes, or you can build from github locally. [10:57] alan_g: https://bugs.launchpad.net/mir/+bug/1161206 [10:57] Launchpad bug 1161206 in Mir "Mir EGL demos output error: libEGL warning: unsupported platform (null)" [Low,Triaged] [10:58] I'll leave it to jenkins - it should be done by the time I've finished lunch [11:03] duflu: ta === hikiko is now known as hikiko|lunch [11:36] alan_g: @fix-1188451, is the dead client caught only when we try to communicate with it, or is there some internal keep-alive mechanism in asio? [11:41] alf: asio detects that read won't block and tries to read. If it can't read then the reason that read won't block is that the connection died [11:42] I'm having trouble testing it properly ATM as I can't run clients without them dying [11:42] (I think that relates to mesa incomparability) [11:45] alf: we're almost always waiting on a call from the client [11:48] alan_g: I forgot to ask; aren't there traditional unix ways to detect the other end of a socket is dead? [11:49] I haven't checked the library... [11:49] alan_g: I am not sure how what you describe would work. Why would a read from a connected (from the server's perspective), but abruptly killed client, not block? [11:50] alan_g: do unix sockets handle this differently from network sockets? [11:56] alf: I'm no expert on sockets, but I think it pretty standard to detect "events" (which can be data or closed). [11:56] Be back later === alan_g is now known as alan_g|lunch === greyback is now known as greyback|lunch [12:10] alan_g|lunch: Indeed, I was thinking in terms of the whole system dying, in which case the network stack wouldn't be able to to send the TCP close sequence. We don't have that problem here, though. === hikiko|lunch is now known as hikiko [12:49] alf: What would you expect with multiple processes doing drmSetMaster ? [12:49] Hmm, never mind. The answer probably doesn't change the solution [12:50] duflu: I would expect all but the first (assuming it succeeds) to fail to get drm master [12:51] alf: I mean would you ever expect EIO particularly? [12:51] I would have thought EBUSY/EAGAIN/something else === alan_g|lunch is now known as alan_g [12:57] duflu: right, EIO seems unlikely (I think it actually returns EINVAL) [12:57] alf: Yeah I hadn't nailed down which function it was [12:59] alf: yep. (I did find some system vs TCP sockets differences while investigating.) [13:14] \o/ Updated with the new libs etc from ppa and lots of problems went away. === mmrazik is now known as mmrazik|afk [13:18] kgunn, would it make sense to move the task to alan's plate with a lower prio? [13:18] kgunn, @switchable backends [13:19] alan_g: great! [13:19] tvoss: might make sense since we are going to need that much sooner than we previously tht [13:20] * alan_g wonders if he's being stitched up by references to "alan" [13:20] alan_g: we just assigned it all to you :) [13:21] kgunn: http://www.dilbert.com/fast/2013-06-19/ [13:22] :) === greyback|lunch is now known as greyback === mmrazik|afk is now known as mmrazik [13:45] kgunn: plymouth fixed, kind of, https://code.launchpad.net/~vanvugt/lightdm/fix-1192051/+merge/170362 [13:45] duflu: \0/ THANKS! [13:45] And now it's late [13:45] * duflu vanishes [13:45] GOTO BED [14:35] undefined label 'bed' [14:35] mlankhorst, :) [15:06] hello folks. status, noticed that when the android clients have to drop a deleted buffer (as is common in transitioning from triple buffered to double buffered), the android drivers are not happy [15:32] status: MPd a fix for bug 1188451 - working to improve reporting and tests around it [15:32] bug 1188451 in Mir "Mir server leaks surfaces from dead clients" [High,In progress] https://launchpad.net/bugs/1188451 === marlinc|away is now known as marlinc [15:36] status: More work on session snapshots, getting closer [15:36] racarr: greyback ....coming ? [15:50] saucy's libhybris sure is chatty [16:09] Morning [16:11] afternoon [16:12] evening === mmrazik is now known as mmrazik|afk [17:00] Bye all! [17:22] I think we should not build [17:22] mirclient mesa on ARM [17:22] becaue we don't use it and now things are broken because if you install it on the phone (i.e. add the ppa) [17:22] because it expects mir_mesa_egl_display_is_valid in [17:23] libmiorclient which isnt there on android [18:26] I am still running in to weird conlicts [18:27] between my mesa and mirclient ending with double frees in static initializers and sadness [18:28] ah perhaps I had a ghost libEGL.so === dpm is now known as dpm-afk [18:51] mterry: would you feel qualified to review https://code.launchpad.net/~vanvugt/lightdm/fix-1192051/+merge/170362 [18:51] * mterry looks [18:54] kgunn, robert_ancell might be better for that one [18:55] (just in terms of potential fallout from messing with VTs) [18:56] mterry: ok....shot in dark....its something i just want to hustle along...but roberts aware also [18:56] Have we [18:56] intentionally dropped support for raring? [18:56] there doesn't seem to be any mesa with the latest API/ABI changes that [18:56] builds against the drm in raring [18:57] racarr, pfft, raring is old hat [18:58] I know, I just can't find a time where I have a few hours to lose to upgrade yet [18:59] ill upgrade while im at the dentist tomorrow XD [18:59] and build drm myself right now [19:02] mterry: Oh. -DCMAKE_BUILD_TYPE=Debug [19:02] is not on for default by mir [19:02] even when building yourself [19:05] err, and now the mir-ppa branch of mesa on github [19:05] doesn't contain platorm_mir.c [19:11] racarr, thanks for the tip [19:24] *crosses fingers for a flawless dist-upgrade* [19:58] undefined reference to `std::chrono::steady_clock::now()'. I guess I have to wait for [19:58] the upgrade to finish :( [20:09] racarr, building mir takes forever [20:10] its true [20:10] you can skip the tests and build from src/ and examples/ directly [20:10] but if anything goes wrong we will want the tests anyway === yofel_ is now known as yofel [20:55] During the proces of upgrading from raring to saucy my battery-not-having desktop went from 1% battery power to 70 [20:55] % [20:55] XD [21:12] Hi guys! I Just upgraded to Ubuntu 13.10 Saucy Salamander and it seems like something called 'mir [21:12] ' has broken my lightdm [21:13] and X [21:13] jk :p, except about the broken :( [21:17] racarr, someone mentioned that you have to remove the line type=unity in /etc/lightdm/lightdm.conf to boot from an xsession (which seemed to work for me!) [21:19] err [21:19] ok I got X but things were pretty bad [21:19] and then it crashed [21:19] haha, yeah I had to do startx to get around the lightdm problem...removing that line fixed it for me [21:24]