[00:24] kgunn, kdub - anything holding up https://code.launchpad.net/~robert-ancell/mir/dev-branch-abi/+merge/187613? [00:24] robert_ancell, yes, i think i should clear that fence before updating the packages [00:24] kdub, ah, ok [00:25] I was looking at landing https://code.launchpad.net/~alan-griffiths/mir/socket-connection/+merge/187326 [00:25] since Jenkins got confused [01:43] good grief jenkins takes a long time to come around and merge it === chihchun_afk is now known as chihchun [04:31] RAOF, heya [04:31] Good evening! [04:54] bbl [06:33] kgunn_: Mir FTBFS in i386 [06:33] robert_ancell: hey, can you help with that? [06:33] https://launchpadlibrarian.net/151501033/buildlog_ubuntu-saucy-i386.mir_0.0.12%2B13.10.20130926-0ubuntu1_FAILEDTOBUILD.txt.gz [06:33] (as there is the ABI break, we are going to be in a state with everything being blocked) [06:36] it passed on other archs… [06:56] anyone on the Mir team? this is quite a blocker? ^ [06:56] alf_: ? ^ [06:57] didrocks: already looking, setting up a i386 chroot to try out solutions [06:57] thanks [07:31] alf_: any hope? ;) [07:31] didrocks: a build is in progress [07:32] didrocks: (I mean locally) [07:32] alf_: I hope the build will fail in your env as well ;) [07:32] alf_: keep us posted please [07:32] didrocks: sure [07:52] didrocks, alf_, back now. Any progress on the i386 build? [07:52] didrocks: robert_ancell: problem reproduced locally, investigating probable solutions [07:52] s/probable/possible/g [07:52] alf_, awesome, thanks! [07:53] * didrocks crosses fingers [07:53] didrocks, that passed in Jenkins right? [07:53] robert_ancell: I think jenkins build are amd64, it only fails on i386 [07:53] of course all -dev packages are blocked, so we have a huge pile of dominos failing (unity-mir, unity8…) [07:57] didrocks, :( [07:57] didrocks, it looks like we do an android build on i386 but not a normal build (https://code.launchpad.net/~mir-team/mir/development-branch/+merge/187640/comments/428486) [07:57] robert_ancell: that's the story on being on top? ;) [07:57] didrocks, the story? [07:57] robert_ancell: s/story/faith/ (being on top of all the dominos) [07:58] don't know that one [07:58] robert_ancell: indeed, only an android build on i386 in jenkins, weird [07:58] robert_ancell: I think upstream-merger should really use the distro builders, we won't end up in all that jazyness [07:59] didrocks, agreed [08:00] alf_, do you have the proposed fix pushed somewhere? [08:00] robert_ancell: not yet, I am trying it out still [08:02] didrocks, yeah, virtual functions in C++ ABI are a pita :) [08:03] oh yeah ;) [08:10] robert_ancell: didrocks: ok I have a reasonable fix, trying amd64 build to ensure nothing broke there. Will ping with MP url. [08:11] alf_: excellent! thanks :) [08:11] alf_, nice! [08:11] didrocks, you don't know any magic to make MPs land any faster do you :) [08:12] robert_ancell: I will push to development-branch and then lp:mir to not break our flow [08:12] robert_ancell: I mean the MP will be for development-branch [08:12] robert_ancell: I do know, it's called bzr push :p [08:12] robert_ancell: how long a MP is taking to hit trunk for Mir? [08:13] in average [08:14] didrocks, 1hr or so [08:14] alf_: why for development-branch? can we target trunk? [08:14] didrocks, I'm thinking this probably counts as a good case for just doing a push if it's holding things up and a fairly simple change [08:14] ah ok, you have a 2 stage thing [08:14] didrocks, we need it to land on both [08:14] robert_ancell: agreed [08:15] as we will rebuild in daily just afterwards [08:15] so i'm in favor as well as pushing to trunk [08:15] didrocks, yes [08:15] alf_, we'll review the MP but just do the push manually [08:16] robert_ancell: np [08:20] robert_ancell: didrocks: https://code.launchpad.net/~afrantzis/mir/fix-i386-build/+merge/187681 [08:20] alf_, some sort of merge conflict? [08:20] robert_ancell: didrocks: hmm something went wrong in the MP [08:20] yeah, seeing conflicts as well [08:21] alf_: also, if you take the same branch and show against trunk, are we fine? [08:21] robert_ancell: didrocks: let me repush cleanly... it's a one line change.. [08:21] alf_: I would prefer to see the diff against trunk itself [08:21] didrocks: trunk == development branch atm [08:22] alf_: well, we are taking lp:mir for releasing [08:22] alf_: I just want to ensure that we only have your changes in [08:22] nothing else [08:22] alf_, do two MPs please [08:23] robert_ancell: ok [08:27] robert_ancell: didrocks: https://code.launchpad.net/~afrantzis/mir/fix-i386-build/+merge/187682 [08:27] robert_ancell: didrocks: https://code.launchpad.net/~afrantzis/mir/fix-i386-build/+merge/187683 [08:27] ah good ;) [08:27] alf_: robert_ancell: so, mind pushing the merge to trunk directly? [08:28] the other one can use the usual process I guess [08:28] (trunk being for me lp:mir) [08:28] alf_, They make sense to me so feel free to push directly [08:29] g'day [08:29] robert_ancell: didrocks: In that case I'd rather follow the usual process, push to development-branch, and merge that into lp:mir [08:29] alf_: no, everything is blocked on lp:mir [08:29] alf_: nothing can release anymore [08:29] hence we need to direct push to lp:mir [08:29] alf_, I can push if you want me to take responsibility for it [08:30] so that we can rebuild mir [08:30] didrocks: we still get the same effect,1. push to development-branch 2. Merge devel into lp:mir [08:30] alf_: devel contains more [08:30] than lp:mir [08:31] didrocks: no [08:31] and right now, we are blocked on having the code in lp:mir [08:31] didrocks: lp:mir == devel at the moment [08:31] ah, I'm not sure about your devel branch ;) [08:31] what I mean is that, we need to bzr push the fix to lp:mir now [08:31] and then, I can rekick a build [08:32] didrocks: sure, there won't be a delay, let me do it [08:32] alf_, oh, I see what you mean [08:32] ok, ping me please once done :) [08:35] robert_ancell: I guess we don't need to bump ABI right? [08:35] alf_, no [08:37] didrocks: robert_ancell: pushed to both devel and lp:mir [08:37] alf_: thanks \o/ [08:37] I'm relaunching the mir stack build [08:38] didrocks, how long does it take to rebuild? [08:39] robert_ancell: ~30 minutes for Mir [09:09] didrocks, rebuilt ok? [09:09] robert_ancell: did you have timer set for exactly 30 minutes? :) [09:09] alf_, only my built-in timer :) [09:11] robert_ancell: still building [09:26] robert_ancell: Mir successfully built! [09:26] thanks [09:26] thanks alf_ ;) [09:26] yay! [09:26] alf_ to the rescue [09:26] didrocks: robert_ancell: np, yw [09:29] bye all [09:29] have a good night robert_ancell :) [10:28] got any complicated bugs for me to look at? :P [10:30] mlankhorst: do you want to admire them or fix them? [10:36] fix [10:37] or at least find the cause [10:41] mlankhorst: I don't think alf_ or RAOF got much further with the Mir-on-Mir problems with GBM you were helping with a week or so back. Fixing that would be great [10:43] hm non-trivial though :P [10:43] meh lets just pretend in that case mir is not used to create the egl screen [10:43] what could possibly break.. [10:44] you want complicated and trivial?! [10:45] alan_g: imo the mir backend should be killed from mesa, and mir should use the normal dri api. :P [10:47] mlankhorst: That doesn't sound like it solves the use case, but maybe I've misunderstood you [10:48] well it would automatically fix nesting [10:48] We intend one system compositor that "owns" the hardware, and multiple session compositors that talk to it. And you mean to kill the system compositor? [10:48] not really [10:52] but it looks like we simply need something like done in platform_drm [10:54] alan_g: in any case it probably makes more sense to prohibit nesting and only have 1 compositor :P [10:58] really! [10:59] but knowing that won't happen, meh [10:59] * alan_g would like to be able to run a development mir under a mir stack. (And some others want to run unity in a session compositor process) [11:00] Anyway, you asked for something complicated. ;^) [11:01] fine I'll see if I can suck up the information from gbm somehow [11:01] my life would be so much easier with client side allocation though [11:03] I'm told that doesn't work so well on the android stack. [11:05] how do you want to nest, then? [11:05] on android [11:08] That already works - I turned my N4 into a hand-warmer my having 6 levels of mir nested. [11:09] need to go deeper [11:14] alan_g: seems that for platform_drm (which you want to use in this case), wayland has something like EGLBoolean eglBindWaylandDisplayWL(EGLDisplay dpy, [11:14] struct wl_display *display); [11:14] an extension [11:15] * alan_g is out of his depth [11:15] I guess it's to handle nested too [11:15] Does that mean you can make it work? [11:16] there's the option of creating a EGL buffer from a wayland buffer too, afaict [11:18] hm I'm not sure yet [11:24] bad raof, using colour when the rest of the code uses color [11:28] alan_g: hm looks like the fix is in the tree I was using though? "mir: Reuse the dri2 screen from the gbm device if available" [11:28] although it still uses dup which is bad [11:28] oh nm that was the good callsite :P [11:28] Hi guys [11:29] I seem to be having problems running any autopilot tests on mako with Mir running [11:29] kgunn_: ^ [11:30] it's done in a very hacky way, but it looks like it should work theoretically.. [11:30] The problem seems to be happening both when using phablet-test-run and when directly running autopilot by SSH [11:30] Do I have to do anything differently than when using surfaceflinger? [11:33] alf_: you managed to make that mesa stuff work right? [11:35] sil2100: does the test script take any screenshots? Other than that I don't think any should be different other the the wait time maybe, windows can load slower on mir on maguro at least [11:38] alan_g: from what I can tell alf_'s lp:~afrantzis/mir/spike-nested-gbm-egl-image-hack + https://github.com/afrantzis/mesa.git egl-platform-mir-egl-image-i965-experiment [11:38] would work nested [11:38] davmor2: no, since I tried running many different test cases [11:39] davmor2: none of them even start - the applications under test are not even starting [11:39] mlankhorst: My understanding is that it doesn't, he talked to RAOF about it last week - but they didn't get time to figure it out. [11:39] davmor2: have you already try it? [11:40] I confirm what sil2100 sees [11:40] alan_g: meh I'll take a look then [11:41] sil2100, didrocks: no worries just trying to rule out anything obvious with the tests before continuing to debug software itself, those were the 2 obvious things that I could think of. [11:43] alan_g: I see platform_drm pulling a bunch of stuff from gbm, which might be related [11:49] actually seems more like it might be overriding a bunch of stuff in gbm [11:49] :P [11:50] Sounds complicated [11:50] well they're intertwined [11:51] so not really surprising === alan_g is now known as alan_g|lunch [12:00] mlankhorst: alan_g: I tried various approaches, including trying to imitate what platform_drm does (i.e. use the dri screen from the gbm device instead of creating a new one, plus duplicating the dri2 image from gbm buffer), but I couldn't get it to work. It is in RAOF's hands now, but I haven't heard any news about it lately. [12:03] alf_: ok I'll poke it some more then [12:03] what you have in your mir/mesa branch looks like it oculd work, though === hikiko is now known as hikiko|lunch [12:13] alf_: what exactly is the failure mode? I just finished compiling now [12:16] mlankhorst: I don't remember exactly for what is in the branch right now :/ [12:17] some hack to slurp the screen from gbm [12:20] hm it's doing SOMETHING :P [12:33] mlankhorst: yeah, that's a wicked hack... wanted to get something asap [12:34] didrocks, from scrollback, looks like mir landed ok, but now....autopilot seems busted ? [12:34] kgunn_: yeah, we let it throught as it doesn't block the main experience, but autopilot tests can't be run with Mir enabled on the phone [12:34] kgunn_: you can check with Saviq, he has the bug references [12:35] sil2100, did you confirm that if you remove /home/phablet/.display-mir that autopilot starts working as expected ? [12:35] on the same exact image that is [12:36] kgunn_: I did that and right, it's working on SF [12:45] kgunn_: yep [12:47] alf_: hm, I'm not getting any information about failure, just getting terrible fps on intel and garbage on radeon === alan_g|lunch is now known as alan_g [12:58] kgunn_, yeah, ap is broken with mir currently: bug #1226234 and bug #1226227 [12:58] bug 1226234 in Unity 8 "QT_LOAD_TESTABILITY=1 does not work for loading the testability driver under mir" [Undecided,Incomplete] https://launchpad.net/bugs/1226234 [12:58] bug 1226227 in Mir "libmirserver parses arguments and fails if it's not something it understands" [Medium,Triaged] https://launchpad.net/bugs/1226227 === hikiko|lunch is now known as hikiko [13:20] alf_: heh.. swrast :P [13:21] mlankhorst: swrast FTW, GPUs are overrated! :) [13:22] that explains the 1 fps i was getting at least [13:22] no idea why it's USING swrast, but still.. [13:28] sil2100, any other probs other than the AP tests on mir ?? [13:28] sil2100, trying to parse rumor from reality :) [13:29] sil2100, some say you found "other issues"...i'd like to track those as bugs if we can [13:29] kgunn_: there were some slowdowns happening when using it for a while, but not sure if that is a known issue [13:29] kgunn_: like, if you open up some applications then close them, everything is moving slower and slower [13:29] kgunn_: not tragically, just slower ;) [13:29] sil2100, mmm....ok....we definitely need a bug on that tho [13:29] sil2100, i'll test here and [13:29] kgunn_: I'll fill it in too [13:29] then file [13:30] Oh ok [13:30] sil2100, it should be pending image right ? [13:30] kgunn_: I think all packages are in -proposed, not sure where the image is at [13:32] kgunn_: btw. https://bugs.launchpad.net/mir/+bug/1231452 [13:32] Ubuntu bug 1231452 in Mir "Autopilot tests not working Mir-driven touch devices" [High,New] [13:56] I am trying to run qmltestrunner on a phone with mir enabled and I am getting an error of http://pastebin.ubuntu.com/6158739/, has anyone tried this? it works when I run it on the phone with surface flinger [13:57] greyback: ^? [13:58] sil2100: so, how can i flash what you guys are testing ? ....e.g. is there a url i can point at ? [13:59] kgunn: what do you mean..? [13:59] kgunn: I'm using the latest cdimage-system + mir from daily-build [14:00] robotfuel_: that's failing as unity8 is rejecting the application, as it has no desktop file specified. If you append "--desktop_file_hint=/usr/share/applications/notes-app.desktop" it should work [14:00] sil2100: ok [14:01] sil2100: so the mir we pushed last night is all built in? ....or i have to installed packages from proposed? [14:01] sil2100: sorry to pester...just trying to figure out which end is up [14:01] kgunn: I think it's in -proposed now, so you can simply use daily-build PPA to get it as well [14:10] alf_: hm I'm trying to understand thism but what is basically happening now is that I believe that window allocations are forwarded :P [14:11] mlankhorst: I am not sure what this means [14:12] MORNING [14:12] alf_: afaict, what would happen before is that when bo's were allocated through gbm they would be allocated from the current drm node [14:12] East coast to west coast jet lag is great [14:13] what happens now is that they are allocated the same way that they would as if they were allocated through egl.. [14:19] greyback: I've started looking at the "clients hang when the server dies" scenario. You were going to provide a bit of info about handling it (a signal or call to save state IIRC). Anyway, the first slice is here: https://code.launchpad.net/~alan-griffiths/mir/client-dies-without-server/+merge/187797 [14:22] Afternoon [14:23] hm afaict it should be identical, meh [14:24] racarr: Are you OK with https://code.launchpad.net/~dandrader/mir/ainput-log-filtering/+merge/187466? === alan_g is now known as alan_g|tea [14:24] alan_g: I will ask you to chat with ricmm about sending the "save state" signal to clients from Mir itself. He's wrote that code, so would know it better [14:28] alan_g|tea: Let it land! [14:30] alf_: hm btw it seems valgrind is complaining, in the cleanup do you uninitialize gbm before or after uninitializing egl? :P [14:30] * mlankhorst is guessing before === alan_g|tea is now known as alan_g [14:36] mlankhorst: I think that gbm is uninitialized after EGL. [14:40] ricmm: I'm looking at allowing mir clients to shutdown cleanly after the server dies. greyback tells me there's a mechanism to instruct them to save state and that you're the guy to tell me what's involved. [14:43] alan_g: sending clients a LifecycleEvent that sets the state to mir_lifecycle_state_will_suspend should be enough to trigger it [14:43] alf_: hm fun interactions between gbm and mir :/ [14:44] alan_g: we could add another field to the LifecycleEvent message to specify not a state transition (as these refer to the client) but a server-death signal [14:44] server/shell exiting signal [14:45] ricmm: not "exiting" but "gone" - this is from the client library when the server goes AWOL. ;) [14:46] But OK, a lifecycle callback seems a sensible [14:46] s/a // [14:46] ok server gone is valid, we can clean up in the app and decide if we want it to quit itself [14:47] is this to fix the fact that clients need to die before the server process dies completely? [14:48] ricmm: It might fix that as a side effect. Which bug is that? [14:49] well on the phone at least when the server segfaults or something, if clients are still connected then the server process blocks to die... even tho it segfaulted [14:49] and it holds a frame in the FB too [14:49] have to manually kill client processes and once the last is gone, then the server process disappears and the fb is released [14:49] I think we should have server exiting and gone [14:50] in server exiting (normally), the correct case is almost certainly for the clients to just die as cleanly as possible [14:50] but in server gone (abnormally) [14:50] that probably means unity/mir crashed and is coming back so lets get ready to set things back up [14:52] ricmm: I'll have to try reproducing to understand why the server hangs after segfault. But that needs fixing server-side. [14:53] alf_: hm, you get a fd from display_get_platform .. do you have to close that one when you call the function? [14:53] or does it have to stay open [14:54] and if you call it repeatedly do you get the same fd? [15:00] greyback: qmltestrunner doesn't like --desktop_file_hint=/usr/share/applications/notes-app.desktop appended to it. I also tryed modifying a .desktop file to run the qmltestrunner without success. [15:01] robotfuel_: ok, please log a bug and I'll investigate asap [15:01] robotfuel_: the output of .cache/upstart/unity8.log would be useful for me [15:01] greyback: ok [15:02] mlankhorst: you get the same fd each time, you shouldn't close it, it's closed when the mir connection is released [15:13] kk [15:19] greyback: I figured it out qmltestrunner needs to do -import --desktop_file_hint=/usr/share/applications/notes-app.desktop [15:19] bye everyone! [15:19] robotfuel_: uhhh, weird. Perhaps a "qmltestrunner -- --desktop_file_hint=..." might work/be cleaner?? [15:29] greyback: no qmltestrunner needs -import to append the --desktop_file_hint [15:31] robotfuel_: weird [15:31] but if it works.. [15:43] alf_: hm, anyway my guess is that to the best of my knowledge things actually work, because they seem to be. but the nested server is messing something up so only garbage gets copied back [15:43] :P === mzanetti is now known as mzanettifd [16:01] maybe try without bypass? [16:01] gone === mzanettifd is now known as mzanetti [16:09] kgunn_: http://paste.ubuntu.com/6159306/ seems to think I don't have opengl 3.2 or higher installed from my gfx card so doesn't start. [16:15] alan_g: The refactoring to socket-messenger-race ends up not being trivial because of ProtobufMessageProcessor::send_response(mir::protobuf::Surface* response) [16:15] which relies on being able to call send_fds, twice and send two messages for the client library [16:16] Wondering if you have any ideas on how that should reshape... [16:17] racarr: If it were trivial it would have happened before. 8^/ [16:17] davmor2, so you're running closed source drivers with just X? [16:18] kgunn_: xmir on intel [16:18] racarr: I suspect we should pass in some sort of aggregate [16:18] davmor2, ? hmm...so, the intel driver is open source and it should be xserver-xorg-video-intel [16:18] one day i'll learn how to stop upstart [16:18] which should start up [16:19] alan_g: Mm. I'm trying to figure out how to avoid overload explosion though...it seems nasty to have like [16:19] so...looks like your app is the one complaining [16:19] kgunn_: once I've migrated all the apps I'll be trying it again without xmir, and then again on nvidia 319 [16:19] send (body) send body(fds), send body(fd aggregate) [16:19] err...I dont know how to use parenthesis [16:19] but the idea should be clear [16:20] davmor2, hmmm...weird...yeah, let me hear what you get from playing mix-and-match [16:20] kgunn_: it might take a while about 790-ish apps left to migrate :) [16:21] racarr: just send(body, {}), send(body, {fds}), send(body, {fds, more_fds}) [16:21] maybe just rely on the caller to produce the aggregate with {} [16:21] Mm [16:23] send(Body const&, initializer_list const&> const&) [16:27] alan_g: Why use std::initializer_list over vector ? [16:27] looks the same to the caller [16:28] racarr: and to the callee - but the initializer_list gets constructed anyway to initialize the vector. [16:30] Mm, but why have the callee have to use the initializer list rather than just [16:30] implicitly construct the vector at the call site? [16:31] the callee just does "for(auto const& fds : fd_list)" in both cases? [16:34] hmm yeah [16:34] but isn't initializer_list kind of a misnomer then? [16:34] If nothing is being initialized... [16:35] I have had continual issues trying to understand the nature of initializer_list, heh] [16:37] racarr: using better_name = std::initializer_list [16:38] haha [16:38] ok [16:38] racarr: Or typedef initializer_list const&> better_name [16:39] Yes. === chihchun is now known as chihchun_afk [16:40] Just because WG21 were thinking about initialization doesn't mean we are restricted in how to use what they built [16:42] kgunn_: mir definitely has issues with Critter Cascade the app starts up fine but the entire screen flashes like crazy [16:42] xmir even [16:45] kgunn_: that is a free app, so should be available in a bit in software-center so you can try it for yourself, I don't know how much useful data you can get from it. [16:45] davmor2, ok [16:56] kgunn_: critter cascade should be installable now [16:57] alright [16:58] Updated to a typedef :) === alan_g is now known as alan_g|EOD === dandrader is now known as dandrader|lunch [17:10] Final dentist appointment *success fist* be back after lunch [17:11] iterated on socket-messenger-reporting and race [17:11] focus-tell-dont-ask when I get back [18:05] join #ubuntu-touch === dandrader|lunch is now known as dandrader [18:10] kgunn_: dale hardshovel hd has the same strobe light effect as critter cascade so I'm wondering if all the unity-3d games will [18:14] kgunn_: dare_up_wing suit is unity-3d too and has the strobe so I'm guessing so :( [18:17] davmor2, that's interesting....we run phoronix & glmark2...all the time, they never strobe [18:17] those are definitely gl [18:18] davmor2, is it the entire screen or just a window (if you can run windows [18:18] windowed) [18:19] kgunn_: 2 are already windowed and 1 is fullscreen [18:20] davmor2, for the windowed cases, is the flicker occuring fullscreen or just inside the window? [18:20] kgunn_: Fullscreen [19:01] kgunn_: darwinia has an odd glitch it's like 1 frame gets dropped, i.e. if it is meant to run 25 frames a second it's running 24 I'll share a video shortly [19:04] Could that be what alf just fixed? [19:04] Also back :) [19:09] kgunn_: http://ubuntuone.com/0pvNLyVZrb2VohlRflSbu3 [19:09] davmor2, thanks [19:09] * kgunn_ gets popcorn ready [19:10] kgunn_: it's not that long a video :) you'll see it flicker twice though :) [19:15] good grief...download sooooo sloooowww [19:18] kgunn_: I just got a video of the strobe effect too for you just waiting for it to land [19:21] kgunn_: http://ubuntuone.com/0siU1JGmj5VkKEOu13MXKE that's the strobe effect from the unity-3d apps [19:29] robotfuel: ^ by the way they might interest you too :) [19:29] davmor2: what videocard? [19:29] robotfuel: intel [19:31] davmor2: do you have a bug with the xorg logs in it? [19:32] robotfuel: Nope, but I'll try and throw one together before I knock off [19:36] robotfuel, kgunn_: oh that's interesting I wonder if it is the hybrid that is playing up. This box is an intel/nvidia box without the nvidia bit being enabled so just running on the intel part. On a pure intel box I have there is no flash [19:37] davmor2: I've seen different results with different intel chips? are they the same type? [19:37] robotfuel: I don't think so I'm grabing the info now [19:42] robotfuel: flashy one is 3rd gen core processor graphics controller + Nvidia GK107M[Geforce GTX 660M], none flashy one is Core processor integrated grraphics card. Both intel drivers are the i915 [19:43] davmor2: I have a core processor with hybrid graphics I can try tomorrow in lexington [19:43] davmor2: can try a 3rd gen core processor now [19:46] robotfuel: I'll write up a bug tomorrow I'll have a fairly fresh xorg then. [19:47] davmor2: ok, I'll email you if I can reproduce and write a bug before your morning [19:47] robotfuel: okay cool I need to get off I didn't realise it was that late :D [19:48] davmor2: thanks for your help [19:57] kgunn_: is the ubuntu-unity-experimental-prevalidation ppa suppose to be working now? [19:57] robotfuel, i don't think so [19:57] i think its defunct [19:58] kgunn_: let me know when I should start testing it :) [19:58] or if there is a new proposed ppa I can run test on [19:58] robotfuel, actually what [19:59] is in trunk is effectively in archive [19:59] is there some proposed stuff before trunk that I can run tests on? so we find them before they land in trunk? [20:00] kgunn_: we have a few benchmarks failing after the new stuff landed in archive the other day. [20:00] robotfuel, ok...that's interesting [20:00] which ones? [20:01] and by fail do you mean...not running or perf drop ? [20:01] 2 intel machines have x freezing when I turn of a display. [20:02] robotfuel, oh yes...that is known... alf_ actuallyl has solutions, but simply hasn't proposed yet [20:05] kdub, racarr have either of you seen a black screen occur with latest mir ? e.g. unity8 getting killed and nothing displayed [20:07] no, but I havent run it today [20:07] and didnt update yesterday I dont think [20:07] gerrys DPMS changes landed and the DPMS API landed wonder if something went wrong [20:08] well, that's the other frustrating thing....this is all from a bunch of ppa's [20:08] still no image with it all in [20:08] kgunn_: You can reproduce it? [20:09] no was about to try...supposedly ogra hit it....but, still, with ppa's i get kind of suspicious [20:09] i'd prefer a nice imag [20:10] what did i hit ? cna i help ? [20:10] *can [20:11] ogra_, heard you were seeing black screen with mir...can you elaborate ? [20:11] sorry if its a repeat conversation [20:11] (is there a bug maybe ?) [20:11] hmm, no, that was someone else [20:11] geeze i love the rumors :) [20:11] lool, ^ [20:12]