[02:21] <robotfuel> x is locking up when using xmir tonight, I was able to grab this right before the machine started a new test http://pastebin.ubuntu.com/6152767/
[02:21] <robotfuel> I'll have a better bug in about an hour
[02:44] <robotfuel> robert_ancell: ping
[02:44] <robert_ancell> robotfuel, hey
[02:45] <robotfuel> robert_ancell: xrandr doesn't say xmir is running when but I see /tmp/mir_socket did that change?
[02:45] <robert_ancell> robotfuel, can you confirm /tmp/mir_socket is owned by u-s-c? Or has this test completed
[02:46] <robert_ancell> robotfuel, /tmp/mir_socket indicates some Mir server is running, which is probably u-s-c
[02:46] <robotfuel> srwxr-xr-x  1 root    root       0 Sep 25 02:21 mir_socket
[02:46] <robert_ancell> robotfuel, run fuser on it
[02:49] <robotfuel> robert_ancell: fuser /tmp/mir_socket returns nothing
[02:50] <robert_ancell> robotfuel, that implies that file is left over from something
[02:50] <robert_ancell> robotfuel, you are checking for that existence of that file to confirm u-s-c is running?
[02:51] <robotfuel> root      1035  1.0  1.0 906132 41188 tty7     Ssl+ 02:21   0:18 /usr/sbin/unity-system-compositor --from-dm-fd 10 --to-dm-fd 13 --vt 7
[02:51] <robotfuel> robert_ancell: shows it's running
[02:51] <robotfuel> robert_ancell: /var/log/Xorg.0.log shows mir stuff in it.
[02:52] <robotfuel> robert_ancell: it's at 10.97.2.151 if you want to log in
[02:52] <robert_ancell> robotfuel, hang on, I'll just restart to confirm the /tmp/mir_socket behaviour
[02:56] <robert_ancell> robotfuel, aha, you have to sudo fuser /tmp/mir_socket since it's root owned
[02:56] <robert_ancell> kind of expected fuser to consider that an error
[02:57] <robert_ancell> robotfuel, right, xrandr outputs now match their old names, so you can't tell if you're running Mir using xrandr
[02:57] <robotfuel> robert_ancell: doh! yes it's being used by u-s-c
[02:57] <robert_ancell> RAOF, there's no X call you know of that can give you information about the driver in use is there?
[02:58] <robotfuel> robert_ancell: ok I'll use mir_socket and fuser to make sure the process id's match instead of xrandr
[02:58] <RAOF> robert_ancell: You can call into DRI2 to get the name of the DRI module to load?
[02:58] <RAOF> robert_ancell: But that's likely not what you want ;)
[02:59] <robert_ancell> RAOF, I was kind of hoping there was some sort of convenient vendor string that an X call returned, but I don't remember anything like that
[02:59] <RAOF> Nope, no dice.
[03:00] <robotfuel> I need to get some sleep thanks robert_ancell and RAOF
[06:00] <robert_ancell> racarr, kdub, hikiko, alf_, kgunn_, meeting
[06:05] <robert_ancell> looks like just me and alf_ here, and his microphone/camera is broken :)
[06:06] <hikiko> still trying to join...
[06:10] <robert_ancell> bye all
[06:10] <hikiko> bye robert_ancell
[06:28] <robert_ancell> didrocks, hey, I noticed the daily releaser did a nice clean up of the changelog. It's nice having guaranteed sane changelogs now :)
[06:28] <didrocks> robert_ancell: oh, daily-release does that from day one FYI ;)
[06:29] <didrocks> robert_ancell: I had to iterate 3 times with Kevin to have the diff you saw already
[06:29] <robert_ancell> didrocks, I wasn't sure if the project version would confuse anything - but if you also can't think of anything I'll update it for consistency
[06:29] <didrocks> so knowing the rest would be cleaned up automatically, I didn't fight more ;)
[06:29] <didrocks> robert_ancell: yeah, just update for consistency, from what I know, it's not picked up by anything
[06:30] <didrocks> so in case you didn't notice, Mir is in the release pocket ;)
[06:30] <didrocks> (had to bribe some release team member to accept the new xorg-server despite the beta freeze)
[06:31] <robert_ancell> didrocks, nice :)
[06:31] <robert_ancell> didrocks, the only place the version is used appears to be the .pc files
[06:33] <didrocks> yeah, and has the deps weren't forced, we should be fine
[08:23] <dandrader> alf_, so commits flow from development_branch (where the real action happens) to trunk (stable branch)?
[08:25] <alf_> dandrader: That's the plan for now. It's not a blocker for branches that don't break the ABI, but keeping merges going in one direction only simplifies the process.
[08:26] <alf_> dandrader: (i.e. no need to merge from trunk back into devel)
[08:29] <dandrader> alf_, kdub, racarr  ok I have resubmitted to the development branch. But now I need you guys to reapprove it, please :)
[08:30] <alf_> dandrader: np, I will reapprove and top-approve when CI is done.
[08:30] <dandrader> alf_, thanks!
[10:07] <alan_g> alf_: I suspect there's no auto-landing job for development-branch (i.e. we have to do the merges ourselves)
[11:44] <alf_> alan_g: hmm, I remember Thomi saying that he could arrange that?
[11:45] <alan_g> alf_: looks as though I was wrong.
[11:46] <alan_g> How do I suppress this: /tmp/buildd/mir-0.0.11+13.10.20130904/examples/basic_server.cpp:49:83: error: ignoring return value of 'int system(const char*)', declared with attribute warn_unused_result [-Werror=unused-result]
[11:46] <alan_g>              (void)system((the_options()->get(launch_child_opt, "") + "&").c_str());
[11:47] <alan_g> Surely casting the result to void isn't ignoring it
[12:02] <alf_> alan_g: In the past I have used an "if (bla()) {}" construct to work around this (in test code), but I guess in this case you might as well do something more useful with the return value.
[12:55] <alan_g> alf_: I've tidied up https://code.launchpad.net/~alan-griffiths/mir/socket-connection/+merge/187326 if you want to take another look
[12:56] <alf_> alan_g: will do
[14:09] <kgunn> oh bravo alan_g..... Thumping Termite
[14:09] <kgunn> thomi: ^
[14:11] <davmor2> kgunn: Teenage-mutant-ninja Turtles is the obvious choice
[14:12] <kgunn> davmor2: dang it...how did we miss that one
[14:12] <alan_g> kgunn: that wasn't intended for publication
[14:12] <kgunn> :))
[14:40] <alan_g> kgunn: are you trying to change the Mir culture of only top-approving when discussion is over? (c.f. https://code.launchpad.net/~alan-griffiths/mir/socket-connection/+merge/187326/comments/427682)
[14:42] <kgunn> alan_g: sorry...i missed that
[14:43] <kgunn> thanks
[14:43] <kgunn> back to needs review
[14:44] <alan_g> kgunn: yw. Just wanted to be sure it was intentional
[14:45] <alan_g> kgunn: and thanks for getting the ci set up for development-branch. Nice
[14:45] <kgunn> alan_g: i know....much better...thank francis :)
[15:04] <kdub> good morning
[15:04] <alan_g> kdub: kgunn hangout?
[15:04] <kdub> sure
[15:04] <kgunn> coming
[15:31] <hikiko> bye
[17:01] <alan_g|EOD> kdub: happy reviewing! (https://code.launchpad.net/~alan-griffiths/mir/socket-connection/+merge/187326/comments/427682)
[17:02] <kdub> alan_g|EOD, could you switch lp:~kdub/mir/fix-1215979 to approve/abstain before you go?
[17:02] <kdub> alan_g|EOD, will review that today
[18:58] <kgunn> kdub: so, do we need to wait for alf_ ? on https://code.launchpad.net/~kdub/mir/fix-1215979/+merge/187346
[18:58] <kgunn> or is ready for ta
[19:00] <kdub> kgunn, comment should be addressed, so it should be okay
[19:01] <kgunn> kdub: ok...i'd like to get it landed tomorrow...only way that happens is to TA right now
[19:01] <kgunn> i'll be doing that now
[19:02] <kdub> kgunn, okay
[19:03] <kdub> kgunn, we'll might get some complaints from the n4 users about worse stuttering if the users have mixed and matched the phablet build and the mir build
[19:04] <kdub> perhaps i should send out a wider email to mir/unity8 folks working on the n4
[19:04] <kgunn> kdub: understand....this just gets it merged onto our dev
[19:04] <kgunn> that's probably a good idea...
[19:04] <kgunn> kdub: does rsalveti already have matching mp's on FB/hwc side ?
[19:04] <kgunn> or ?
[19:05] <kgunn> maybe you put some mp's up?
[19:05] <kdub> according to email, should be in the next image
[19:08] <rsalveti> kdub: kgunn: it's already in today's image
[19:08] <kgunn> hey hey...even better
[19:09]  * kgunn wonders how rsalveti lands stuff so fast
[19:09] <rsalveti> :-)
[19:17] <kgunn> kdub: do you still have a GalaxyNexus?
[19:17] <kdub> yep
[19:17] <kgunn> curious if you think with mir if its usable as a dev device (i know the perf aint great)
[19:19] <kgunn> kdub: one other thing to check my thinking....i should just bump our so name on our dev branch, then push the whole damn thing to trunk....e.g. we want it all w/ history right ?
[19:19] <kgunn> e.g. push --overwrite lp:mir
[19:19] <kdub> not sure what --overwrite does :/
[19:20] <kdub> merging is probably better
[19:20] <kgunn> mmmm...it ignores any conflict, but that would only matter if an mp went in....
[19:20] <kgunn> so i guess thats not right
[19:20] <kgunn> it would be better to merge....but somehow perserve history
[19:21] <kdub> kgunn, what we should do is bump the so in the dev branch, get that landed, and then instruct CI to autoland the revision that has the bump
[19:21] <kdub> well, jenkin's autolander for lp:mir
[19:21] <kgunn> kdub: "get that landed" means onto lp:mir trunk right
[19:22] <kdub> no, land onto the dev branch
[19:22] <kdub> and then merge that into  lp:mir
[19:22] <kgunn> kdub: oh...ok...yeah...we're thinking the same
[19:22] <kgunn> too many "lands"
[19:23] <kgunn> kdub: i'm just wanting to make sure we pull over history per commit with it
[19:24] <kdub> kgunn, after a merge, bzr log -n0 shows the individual revisions in the branch that was merged
[22:37] <robotfuel> robert_ancell: ping
[22:37] <robotfuel> RAOF: ping
[22:37] <robert_ancell> robotfuel, hello
[22:37] <RAOF> robotfuel: Pong
[22:38] <robotfuel> we have this new bug from the xmir stuff that landed last night https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1231084
[22:38] <robotfuel> it's only on intel and only 2 of the 3 intels in the lab
[22:40] <RAOF> Hrm.
[22:40] <RAOF> Does running with MIR_BYPASS=0 fix it?
[22:41]  * RAOF is currently in a moderately interesting XDC talk, so mental bandwidth is low.
[22:45] <robotfuel> RAOF: where do I add MIR_BYPASS=0?
[22:46] <RAOF> robotfuel: Export it from /usr/bin/unity-system-compositor.sleep
[22:49] <RAOF> robotfuel: Ahem. /usr/sbin/unity-system-compositor.sleep
[23:00] <robotfuel> RAOF: MIR_BYPASS=0 fixed the issue. it's actually not freezing when the resolution changes it's freezing when using xrandr --output VGA-0 --off
[23:01] <robotfuel> RAOF: the next step is the resolution change which hangs, but the ui is frozrn after the xrandr --output VGA-0 --off I'll update the bug
[23:01] <RAOF> Ok.
[23:03] <RAOF> I think I've seen that before. We're probably blocking the (Mir) frontend, so messages are no longer being handled.
[23:19] <mlankhorst> RAOF: hm considering you're at XDC (part of me is jealous, but I'm also glad), want me to look at any xmir things?
[23:19] <mlankhorst> any specific
[23:20] <RAOF> mlankhorst: Not that I'm aware of :)
[23:20] <RAOF> mlankhorst: Oh, you could push my xf86-video-ati patch if you felt like it :P
[23:20] <mlankhorst> ah forgot :P
[23:20] <mlankhorst> *writes it down*
[23:21] <mlankhorst> ok will probably do it tomorrow, bedtime for me :P
[23:21] <RAOF> Yeah, no rush.
[23:21] <RAOF> I've applied the most interesting bit in Ubuntu already.
[23:21]  * mlankhorst is in the mood for some triaging tomorrow
[23:31] <RAOF> mlankhorst: Oh, and there's always https://bugs.launchpad.net/mir/+bug/1195811 :)
[23:37] <mlankhorst> RAOF: Yeah no luck there, requires upstream cooperation :/
[23:37] <mlankhorst> I did write a fix that I keep in my tree
[23:38] <mlankhorst> RAOF: oh bug darktama for me please
[23:38] <mlankhorst> pester him as much as you can about high resolution vblank timing
[23:38] <mlankhorst> that patch fixes that issue :P
[23:44] <robert_ancell> racarr, around?