[00:00] <RAOF> I'll fire up the ati system again.
[00:01] <bschaefer> RAOF, thanks, kgunn just wanted another working xmir data point, so for 1 is failing and 2 are working
[00:02] <bschaefer> s/for/far ... geez
[00:05] <RAOF> Heh
[00:08]  * robert_ancell -> lunch
[00:23] <kdub> my 1tb harddrive is 80% full of compiled mir code... bzr -_-
[00:24] <kgunn> RAOF: can you please ping didrocks when he comes online & try to help resolve his ati issue...its our last blocker
[00:24] <RAOF> kgunn: Sure.
[00:25] <RAOF> kdub: cd ~/.bazaar/plugins; bzr branch lp:bzr-removable ; cd ~/Devel/Mir ; for I in $(bzr removable trunk ) ; do rm -r $I ; done ☺
[00:26] <kdub> RAOF, hmm, might give it a try!
[00:27] <RAOF> kdub: bzr-removable adds the "removable" command; in a repository, you give it a branch and it'll tell you all the branches in the repository which have been merged into that branch.
[00:27] <kdub> ah, that would be useful
[00:28] <RAOF> It also adds the "unremovable" command, which does the reverse, and tells you why it's not removable
[00:29]  * RAOF might get around to adding a "-d" option to it, so that ‘bzr removable -d trunk’ would delete all the branches that have been merged into trunk
[00:30]  * RAOF books travel to Boston
[00:31] <RAOF> bschaefer: Yup; My ati box still works with unity-system-compositor
[00:32] <bschaefer> RAOF, thanks
[00:38] <RAOF> Now; does this XMir populate xrandr data?
[00:42] <bschaefer> RAOF, where would one check for this data?
[00:42] <bschaefer> i see this in my syslog: Aug  7 16:30:51 bschaefer-GA-870A-UD3 colord: Device added: xrandr-XMIR-1
[00:45] <RAOF> bschaefer: Oh, your XMir definitely doesn't. I'm just hooking up the new Mir multi-head API.
[00:45] <bschaefer> oo cool, though im not sure what that is :)
[00:48] <RAOF> xrandr will report the full set of modes your outputs can do, rather than just the single mode Mir set on startup :)
[00:49] <bschaefer> RAOF, oo nice, yeah, i've just been stealing mir_connection_get_display_info ... and using the width/height for what I think mir can display
[00:50] <RAOF> Yeah. You'll need to switch to mir_connection_create_display_config() at some point ☺
[00:50] <bschaefer> sweet, yeah I saw that in the egl examples yesterday, now that makes much more sense :)
[00:51] <RAOF> Yeah. Make sure you check the most recent egl examples; I fixed a thinko in them yesterday :)
[00:52] <TheDrums> Sorry for the question, but are there any major changes since the last PPA build in this one?  Drivers, Mir, Xorg u-s-c?  And lastly, I'd guess 0.0.9 is still out several weeks?
[00:52] <bschaefer> cool, yeah I need to go back and update some of my branches... I think the ABI might have changed as well
[00:53] <RAOF> bschaefer: The client ABI shouldn't have changed. If it did, please hit us with a stick.
[00:53] <RAOF> The server ABI is... not yet ☺
[00:53] <bschaefer> RAOF, haha, will do
[00:53] <bschaefer> I think the last time was ... the swap buffers call
[00:54] <bschaefer> it use to be mir_connection_next_buffer or something?
[00:54] <bschaefer> but that was a while ago...
[00:55] <RAOF> Ah, yes. We did change that.
[00:55] <RAOF> That was a while ago.
[00:55] <RAOF> Woot! We have xrandr info.
[00:55] <bschaefer> yes it was, I just haven't re-compiled my branch in sometime :)
[00:55] <bschaefer> :)
[00:55] <RAOF> Although I should probably try it on something that isn't this laptop, as it only supports 1920x1080, which makes the mode list somewhat short!
[00:57] <bschaefer> that could help haha
[01:10] <robert_ancell> duflu, RAOF etc, can you review https://code.launchpad.net/~robert-ancell/mir/vt-switch-keys/+merge/179067?
[01:10] <robert_ancell> would like to knock out the VT issues today
[01:13] <RAOF> robert_ancell: Looks like you've still got some debug printfs in there?
[01:13] <robert_ancell> RAOF, ah, missed one
[01:13] <RAOF> Quite a few, it seems?
[01:14] <RAOF> 51, 87, 126...
[01:14] <robert_ancell> RAOF, ah, no I just didn't push the last commit
[01:14] <robert_ancell> the "clean this up for merging" commit
[01:15] <RAOF> :)
[01:15] <RAOF> Also, what is KEY_L?
[01:15] <duflu> robert_ancell, yep
[01:15] <robert_ancell> RAOF, also debug and also removed
[01:15] <RAOF> Good, good.
[01:15] <robert_ancell> RAOF, I needed to check I wasn't hitting the existing alt+ctrl+Fn keys
[01:15] <RAOF> Yeah, fair suck of the saz.
[01:15] <RAOF> sav
[01:32] <RAOF> robert_ancell: Hm. Why are you explicitly initialising a std::initialiser_list?
[01:33] <robert_ancell> RAOF, because std::make_shared seems to get confused
[01:33] <RAOF> Ah, if you just do ...({vt_filter})?
[01:34] <robert_ancell> RAOF, because the it treats it as a std::initializer_list<std::shared_ptr<VTFilter>> not, std::initializer_list<std::shared_ptr<mi::EventFilter>>
[01:34] <RAOF> Urgh.
[01:35] <robert_ancell> yes
[01:35] <robert_ancell> spent a lot of time trying to understand the error message
[01:38] <RAOF> export CC=clang; export CXX=clang++ in ~/.bashrc makes that much easier :)
[01:59] <duflu> Hey, Ctrl+Alt+Backspace is a much cleaner shutdown than Ctrl+C was. I wonder how much we should still worry about our signal handling...
[02:02] <RAOF> robert_ancell: Hm. That doesn't VT switch correctly for me - or, at least, it does vt switch but then immediately switches back.
[02:02] <RAOF> robert_ancell: Does it require https://code.launchpad.net/~mlankhorst/mir/setsid/+merge/177800 ?
[02:02] <robert_ancell> RAOF, yeah, I saw something similar. It goes away with setsid
[02:04] <duflu> robert_ancell: I knew I would have to test with setsid. Does a prereq somewhere make sense?
[02:04] <RAOF> Yes.
[02:04] <robert_ancell> duflu, I don't think it's strictly required, though I would land it next
[02:05] <duflu> robert_ancell: I'm finding similar issues with three of my branches right now... Behaviourally they are quite dependent, but diff-ly they are separate :/
[02:07] <RAOF> As long as we land both at approximately the same time it's ok.
[02:07] <RAOF> Ideally we'd land setsid and vt-switch-keys atomically, though.
[02:10] <duflu> RAOF: Atomicity can only be guaranteed by telling people not to pull from trunk for a while, I guess
[02:11] <RAOF> No, it can also be guaranteed by merging the two branches and landing them as one?
[02:11] <duflu> RAOF: Other than that, which clearly we're trying to avoid
[02:11] <duflu> That said, I'm already building/testing them together
[02:11] <RAOF> It's not clear to me that we're trying to avoid that?
[02:12] <RAOF> Anyway, +1 on vt-switch-keys and +1 on setsid.
[02:56] <duflu> robert_ancell, hangout?
[02:57] <robert_ancell> duflu, syre
[03:55] <robert_ancell> thomi, weird thing - https://launchpadlibrarian.net/147042471/buildlog_ubuntu-saucy-i386.mir_0.0.8%2B13.10.20130807.3bzr943saucy0_FAILEDTOBUILD.txt.gz
[03:56] <robert_ancell> Fails to build (I saw it locally too). But doesn't occur when the CI builds occur
[03:56] <robert_ancell> And the error seems quite straight forward - just missing #import <iostream>
[03:57] <thomi> hmmmm
[03:57] <thomi> that is odd
[03:57] <thomi> you'd expect them both to fail
[03:58] <robert_ancell> yeah. When I build locally with ./native-compile.sh it works, but not when using debuild
[03:59] <robert_ancell> Maybe debuild sets some cflags and normally it's just  a warning, but for debuild it's an error
[03:59] <robert_ancell> -Wbe-pedantic-about-std-cerr
[03:59] <thomi> robert_ancell: perhaps locally one of the other header files #include's iostream, but the version in the package build env is older, and doesn't?
[04:00] <robert_ancell> hah, looks like I broke it in a previous merge. The CI just didn't pick it up
[04:00] <robert_ancell> actually it was alf, when he finished off my alt+ctrl+backspace branch
[04:03] <thomi> robert_ancell: should we add that flag to the builds?
[04:03] <robert_ancell> thomi, We probably should if you can work it out.
[04:03] <thomi> robert_ancell: or rather, can you add it to the standard compile flags?
[04:03] <robert_ancell> thomi, don't the builds run debuild anyway?
[04:03] <thomi> robert_ancell: yeah, I'm not sure what's going on
[04:03] <thomi> hmmm.. perhaps the pkg builds override CXXFLAGS?
[04:04] <robert_ancell> thomi, can you review https://code.launchpad.net/~robert-ancell/mir/missing-import/+merge/179092
[04:04]  * robert_ancell shrugs
[04:04] <thomi> sure
[04:04] <robert_ancell> guess we wait until it happens a second time before spending too much time fixing it
[04:05] <thomi> robert_ancell: BTW, did you want a copy of my travel plans for Boston -> AKL so you have a travelling companion on the way home?>
[04:05] <thomi> or are you so sick of me now that you'd like my flight details so you can deliberately plan a different route? :P
[04:06] <robert_ancell> heading out - be back in an hour
[04:06] <robert_ancell> thomi, sure, forward them
[04:06] <robert_ancell> ta
[04:10] <thomi> robert_ancell: OK, jobs are all kicked off again for the next test run
[04:28] <tvoss_> good morning :)
[04:29] <thomi> hi tvoss_, how's life?
[04:29] <tvoss_> thomi, pretty good :) how is life on your side?
[04:29] <thomi> tvoss_: still getting over the jetlag, but otherwise good
[04:29] <thomi> thinking about investing in a pottery wheel... ;)
[04:31] <tvoss_> thomi, having a pottery wheel around is always a good idea
[04:31] <tvoss_> ;)
[04:31] <thomi> gotta get some practise in, before the international competition
[04:33] <thomi> I gotta head out, will be back later for late calls.
[04:34] <RAOF> Hm. There is no problem that can't be fixed with another layer of indirection!
[04:34] <tvoss_> RAOF, for sure :)
[04:41] <Mirv> hmm, I wonder if this https://launchpadlibrarian.net/147032204/buildlog_ubuntu-saucy-armhf.mir_0.0.8%2B13.10.20130808-0ubuntu1_FAILEDTOBUILD.txt.gz is something already taken care of?
[04:41] <Mirv> demo_inprocess_surface_client.cpp:58:27: error: 'cerr' is not a member of 'std'
[04:44] <RAOF> Mirv: robert_ancell was just talking about that
[04:45] <Mirv> ah, I see
[04:46] <Mirv> and approved, nice, I'll rerun the stack when it has been merged
[05:00] <Mirv> ok, rerunning
[05:02] <Mirv> well, unity got there first, might take some time..
[05:21] <RAOF> thomi: Could you kindly turn off the autolanding for mesa into the staging ppa.
[05:33] <RAOF> didrocks: Yo!
[05:33] <didrocks> RAOF: hey!
[05:34] <RAOF> didrocks: I understand you've got a kernel backtrace for the ati system of death?
[05:36] <didrocks> RAOF: I don't have a kernel backtrace AFAIK. All the traces were pasted on IRC.
[05:37] <tvoss_> didrocks, jibel pasted the original kernel tr
[05:37] <tvoss_> bt
[05:38] <tvoss_> didrocks, RAOF browser-history ftw: http://paste.ubuntu.com/5959277/
[05:43] <RAOF> Hm. That's interesting.
[05:44] <RAOF> didrocks, tvoss_: So, that backtrace has Xorg as the controlling process of the CPU that wedged; it's calling drm_mode_setcrtc, which means that it's not running under unity-system-compositor.
[05:45] <tvoss_> RAOF, hah
[05:45] <didrocks> RAOF: right, so we had one run with u-s-c
[05:45] <didrocks> which starts, but compiz never finished its init
[05:45] <didrocks> (blocked on opengl plugin)
[05:45] <didrocks> then, we restart without u-s-c/Mir, under raw Xorg
[05:45] <didrocks> and this is what happens ^
[05:46] <tvoss_> didrocks, this is a very wild guess, but could we update the machine's bios?
[05:46] <didrocks> tvoss_: that doesn't change that the previous run failed
[05:46] <didrocks> the machine blocking is a consequence
[05:46] <robert_ancell> could we accidentally drop that machine out the window?
[05:47] <RAOF> didrocks: How do you restart without u-s-c? Is a reboot involved, or a tweak of lightdm.conf.d + a lightdm restart?
[05:47]  * didrocks wants to accidentally drop doko out the window
[05:47] <didrocks> RAOF: new install, other stack to tests
[05:48] <RAOF> didrocks: So, a reboot?
[05:48] <didrocks> RAOF: without any reboot
[05:48] <didrocks> it's a lxc container
[05:48] <RAOF> Ah, ok. Right.
[05:49] <didrocks> so the previous run (with u-s-c failing) was ended
[05:49] <didrocks> then, another one for another stack with regular Xorg
[05:49] <RAOF> So that would mean the blocking problem is likely to be a failure to clean up u-s-c properly on lightdm shutdown.
[05:49] <RAOF> And then there's the problem of u-s-c failing in the first place.
[05:49] <didrocks> right
[05:50] <didrocks> (only on ati)
[05:50] <tvoss_> robert_ancell, +1
[05:50] <didrocks> intel with the same packages works perfectly
[05:50] <robert_ancell> RAOF, could I ask you a favour? I need to do family things before coming back tonight - can you watch https://launchpad.net/~mir-team/+archive/staging/+build/4859513 and when that completes copy (without rebuild) mir 0.0.8+13.10.20130807.3bzr944saucy0  from the staging PPA to the system-compositor-testing PPA?
[05:50] <RAOF> robert_ancell: Ok.
[05:50] <robert_ancell> Then follow up with u-s-c rev 40 when that autolands (with rebuild)
[05:51] <RAOF> Sure.
[05:51] <robert_ancell> I'm in fear that by the time I come back and new revision will have landed and wipe out the build :/
[05:51] <RAOF> :)
[05:57] <RAOF> didrocks: I don't suppose it's possible to log into that box while it's running the test?
[05:57] <didrocks> RAOF: we can, just not now
[05:57] <didrocks> doko broke Qt5…
[05:57] <RAOF> K
[05:57] <didrocks> need to fix that first
[05:59]  * RAOF goes back to xrandr hotplug
[06:08] <duflu> RAOF: I suspect I had the Xdamage/Compiz argument backwards. Some Compiz plugins actually expect and require that they be able to spuriously render outside the damage region, and that it only looks *right* if you show the damage region (hide overdraw).
[06:09] <duflu> So that was mostly fixed when we enabled page flipping. And would be more fixed by using regional logic again
[06:16] <RAOF> duflu: You mean they render *incorrectly* outside the damage region, and expect any rendering outside the damage region to be invisible?
[06:17] <duflu> RAOF: Yes
[06:17] <RAOF> That's messed up.
[06:17] <duflu> RAOF: Most of the obvious occurrences were fixed last year, but not all
[06:17] <duflu> RAOF: unityshell too :P
[06:17] <RAOF> Also, XMir will display any rendering they do.
[06:18] <RAOF> Because XMir sees the damage that *compiz* does.
[06:18] <RAOF> Oh. I guess unless compiz does partial frontbuffer updates.
[06:18] <duflu> RAOF: Yes, that's just a CCSM tickbox away
[06:18] <RAOF> In which case XMir will just see the bits of the frontbuffer you updated.
[06:20] <duflu> RAOF: Just untick everything except sync_to_vblank in CCSM>OpenGL
[06:20] <RAOF> Frankly I'd prefer to just show the broken rendering and fix it.
[06:21] <duflu> RAOF: I don't think you will see any bugs outside of obscure plugins
[06:57] <dholbach> good morning
[07:04] <RAOF> Wow, Mir takes a while to build on arm.
[07:05] <ogra_> RAOF, locally ? or on the buildd
[07:05] <RAOF> On the builld.
[07:05] <ogra_> (we got new buildds yesterday ... )
[07:05] <RAOF> I'm pretty sure I could have had this finished in a qemu schroot in the hour it's taken on the buildd, including the time taken to set up the armhf chroot :)
[07:06] <ogra_> is that a distro buildd or PPA ?
[07:06] <RAOF> PPA.
[07:06] <ogra_> would be worrying if its distro
[07:06] <ogra_> ah
[07:06] <RAOF> I understand we have shiny new caldexa nodes for our distro buildds.
[07:06] <RAOF> That do things like build Mir in less than an hour :)
[07:07] <ogra_> on the distro buildera firefox build takes ~5h now ... was between 20 and 30 before
[07:11] <mlankhorst> RAOF: ping
[07:11] <mlankhorst> https://launchpadlibrarian.net/146986827/buildlog_ubuntu-saucy-powerpc.xserver-xorg-video-ati_1:7.2.0-0ubuntu1_FAILEDTOBUILD.txt.gz
[07:11] <RAOF> mlankhorst: Pong.
[07:11] <RAOF> Gah. Did I fail to push the fixed patch for that
[07:11] <RAOF> +
[07:11] <RAOF> ?
[07:12] <mlankhorst> it has come to this
[07:12] <RAOF> mlankhorst: I fixed that in one of the pre-7.2.0 uploads, but I may not have pushed all of those to alioth :(
[07:13] <mlankhorst> hm reverse debdiff it? :P
[07:14] <mlankhorst> seems you're right
[07:14] <RAOF> git merge to the rescue.
[07:15] <RAOF> robert_ancell: Whoops. Sorry - the armhf build didn't finish before the i386 & amd64 build for the *next* revision. No copy-with-binaries available for us!
[07:16] <RAOF> mlankhorst: I'll fix that up, push to git, and upload.
[07:17] <mlankhorst> git merge is awesome ;P
[07:19] <mlankhorst> do you have dpkg-mergechangelogs set up for git merges too?
[07:28] <RAOF> Indeed I do.
[07:29] <didrocks> RAOF: ok, let me find an archive I can restore
[07:29] <didrocks> are you free to debug Mir?
[07:29] <RAOF> didrocks: Uuur, I'll be doing Zoë's bath in a 10 minutes or so.
[07:30] <RAOF> I can be available later, or if the machine won't be free then I guess I could get Sam to handle Zoë's bath.
[07:33] <alf__> RAOF: quick question: can an output have more than one preferred modes?
[07:33] <RAOF> alf__: I don't believe that makes sense, no.
[07:34] <didrocks> RAOF: should be freed, how long will that take you?
[07:34] <didrocks> to know if I'm going out for exercise now or later
[07:34] <didrocks> or just prepare and block the machine and ping you with the details
[07:35] <RAOF> Probably prepare and block the machine & ping me with the details would be best for me.
[07:35] <RAOF> I'll probably be ready to start debugging in ~1hr or so.
[07:35] <didrocks> RAOF: ok, doing that
[07:36]  * RAOF prepares to set up the VPN on his new laptop
[07:41] <robert_ancell> RAOF, damn!
[07:45] <thomi> RAOF: would you like it turned off forever?
[07:46] <robert_ancell> And the reason mir rebuilt? - didrocks daily landing bumped debian/changelog :)
[07:46] <didrocks> robert_ancell: sorry, was it a question? ;)
[07:46] <robert_ancell> didrocks, :P
[07:47] <thomi> RAOF: I disabled the jenkins job - let me know if/when you want it turned on again
[07:48] <robert_ancell> duflu, have you given up with mir+raring? I want to disable all the raring packages from the staging PPA
[07:48] <duflu> robert_ancell: No, still using it for now. But I know I lost that argument
[07:48] <robert_ancell> duflu, well, it hasn't built for raring in some time, so you must only be building it locally right?
[07:49] <duflu> robert_ancell: Yes, always locally. I guess I need the PPA only for the Mesa/Intel changes
[07:49] <robert_ancell> thomi, can you disable mir and unity-system-compositor raring builds in the staging PPA? (no rush)
[07:50] <robert_ancell> and unity-greeter too I guess
[07:50] <thomi> robert_ancell: can get to that tomorrow, sure.
[07:50] <thomi> robert_ancell: just raring, right>
[07:50] <thomi> ?
[07:50] <robert_ancell> yes
[07:51] <thomi> ok, made a note. Will do that first thing tomorrow.
[08:06] <duflu> ping alf__
[08:40] <robert_ancell> make
[08:40] <robert_ancell> cd
[08:40] <robert_ancell> cd bzligd/sea
[08:40] <robert_ancell> ls
[08:40] <robert_ancell> jetessrter
[08:45] <RAOF> didrocks: Ping? New laptop has a new ssh key :(
[08:46] <seb128> RAOF, he went out for exercice, he should be back in half an hour
[08:47] <RAOF> seb128: Ah. Are you able to shove another ssh key on the box we ssh into?
[08:47] <seb128> robert_ancell, hey, if "jetessrter" is a password of yours, change it :p (you typed that and a bunch of commands in IRC)
[08:47] <seb128> RAOF, I'm afraid I don't know how to do that, maybe jibel can help though
[08:47] <seb128> jibel, ^
[08:48] <jibel> RAOF, which box?
[08:49] <RAOF> Whatever 10.97.0.1 is.
[08:49] <RAOF> (In the QA lab, I think.)
[08:49] <jibel> RAOF, you don't seem to have an account on this box, which user do you use?
[08:50] <RAOF> desktop-team
[08:51] <seb128> RAOF, how is your new laptop btw? you got one of the new system76 ones right? they look quite nice
[08:51] <RAOF> seb128: They are quite nice.
[08:52] <robert_ancell> seb128, heh, must fix that
[08:52] <seb128> robert_ancell, ;-)
[08:52] <RAOF> Not quite the same build quality as a high-end thinkpad, but servicable, with a nicer screen and cheaper :)
[08:53] <seb128> RAOF, it's renewal time for me so I'm looking around, though I'm still happy with my 3 years old latitude ... I might go for an ultrabook (the xps13 looks nice, but glossy screen ...)
[08:54] <RAOF> Matte screen on the galago :)
[08:54] <jibel> RAOF, I re-imported your ssh keys, can you try again?
[08:55] <RAOF> jibel: Works, thanks!
[08:55] <jibel> yw
[09:03] <RAOF> Oh, hello.
[09:03] <RAOF> Why is mir_wait_for blocking indefinitely, I wonder?
[09:05] <RAOF> Wow. unity-system-compositor has 17 threads.
[09:06] <RAOF> duflu: You were playing around in the mir_wait_for pool before - any ideas why mir_wait_for would be blocking indefinitely?
[09:07] <duflu> RAOF: Assuming you don't have a logic error, I do recall the design of mir_wait_for is actually not thread safe :/
[09:09] <duflu> RAOF: Perhaps mir_wait_for_one() ... http://unity.ubuntu.com/mir/group__mir__toolkit.html#ga4f9ee1ace58423c5482e9b3018060252
[09:09] <RAOF> Hm. That's probably not it, because we only mir_wait_for in the xserver mainloop
[09:12] <alf__> duflu: pong, sorry lost in console land
[09:13] <alf__> alan_g: @internal_surface, how come we can call as_internal_surface() without the namespace?
[09:13] <duflu> alf__: I will defer bothering you while I suspect I might have caused the issue :)
[09:13] <alf__> duflu: ok
[09:14] <alan_g> alf__: ADL
[09:17] <alf__> alan_g: ok
[09:19] <RAOF> duflu: Why “while ((!expecting && !received) ” in wait_for_all?
[09:20] <RAOF> duflu: This seems to be a race condition?
[09:20] <duflu> RAOF: Don't know. I thought that was well tested...
[09:21] <duflu> RAOF: It's in a unique_lock, so can't race. Only be misused by callers...
[09:21] <RAOF> It seems to me that if you call mir_wait_for(mir_connection_do_something()); and your timeslice runs out between mir_connection_do_something and mir_wait_for then it's possible for the request to be processed before mir_wait_for *acquires* that lock.
[09:22] <duflu> RAOF: It looks like the kind of situation wait_for_one was invented to solve. The problem with wait_for is that it is unsafe to ever have more than one thread call it
[09:22] <duflu> ... cos if you do, the first will win and starve subsequence threads
[09:22] <RAOF> But this *does* only ever have one thread call it!
[09:23] <duflu> RAOF: Is your received < expecting?
[09:23] <duflu> What is expecting?
[09:23] <RAOF> No; both are 0
[09:24] <duflu> RAOF: That means no result_received yet
[09:24] <RAOF> duflu: Surely it doesn't?
[09:24] <duflu> RAOF: It's pretty clear in mir_wait_handle.cpp
[09:24] <RAOF> I would have thought expecting > received was no result_received.
[09:26] <RAOF> Oh, no; you're quite right.
[09:26] <duflu> RAOF: Any result_received is a result. It's just a matter of how many you expect (are committed to wait for)
[09:26] <RAOF> If it had been received then there'd be non-zero numbers there.
[09:38] <duflu> RAOF: I'm not saying all uses of MirWaitHandle are bug-free, but it looks likely the class itself is.
[09:39] <RAOF> Yeah.
[09:44] <RAOF> Which suggests that the request just hasn't been processed.
[09:46] <RAOF> didrocks: If you need that box back I've probably got enough to think about.
[09:46] <didrocks> RAOF: ok, rebooting it to unscrew it now :)
[09:47] <didrocks> thanks RAOF
[09:50] <RAOF> Bah. Where was that bug again? I should update it.
[09:53] <alf__> RAOF: it seems that KMS supports multiple preferred modes...
[09:53] <RAOF> Huh. You live and learn.
[09:54] <alf__> RAOF: but xrandr hides this, probably selects the first/highest preferred
[09:55] <alf__> RAOF: I wonder how it gets this from EDID information, I thought it had only one preferred mode field?
[09:55] <RAOF> I knew that I could technically set as many "preferred" modes as I liked; it's just a flag I can apply to a mode. I didn't think it would ever have more than one, though.
[09:55] <RAOF> alf__: Likewise.
[09:58] <RAOF> alf__: When you say kms supports multiple preferred modes, what do you mean?
[09:58] <RAOF> Or, rather - have you seen it *return* multiple preferred modes?
[09:58] <alf__> RAOF: I mean that on both my laptop and desktop I get multiple modes with the preferred flag set, yes
[09:58] <RAOF> Oddness.
[09:59] <RAOF> I'm surprised you get more than one mode *at all* on your laptop, frankly :)
[09:59] <alf__> RAOF: actually you are right, lvds screen, gives me just one, it's the external screen that supports more there
[10:30] <RAOF> Ok. It's not clear to me what the hell's happening there.
[10:31] <RAOF> If anyone's got a few cycles spare to be perplexed, https://bugs.launchpad.net/mir/+bug/1204939 is really odd.
[10:39] <tvoss> alan_g, ping
[10:41] <alan_g> tvoss:
[10:55] <alf__> mlankhorst: Hi! Any idea if it's normal for KMS to return multiple "preferred" modes (DRM_MODE_TYPE_PREFERRED set in mode->flags)? A quick survey of the drm kernel code (e.g. for radeon) indicates that this shouldn't happen (unless I missed something).
[10:59] <mlankhorst> alf__: why do you ask?
[11:01] <mlankhorst> first preferred mode would be the correct one, if there is more for the same connector it's probably a bug
[11:10] <duflu> alan_g: The timing failure on N4, is that all the time or intermittent?
[11:11] <alan_g> duflu: happened twice - am increasing sample size
[11:12] <duflu> alan_g: OK, yeah. I think the test is more at fault than the code. I'm going to loosen the test today and work on improving it another day
[11:14] <alan_g> duflu: failed 3 out of 10
[11:14] <duflu> alan_g: What was the highest number reported of the 3?
[11:15] <alan_g> duflu: all 1 vs 1
[11:15] <duflu> alan_g: Right, so worst case was ~1% hiccups. That's the test being too strict, or not running long enough (since I shortened everything today)
[11:17] <duflu> tvoss: Done, methinks
[11:18] <duflu> At least that took long enough that the meat I was meant to cook is fully defrosted for sure
[11:18] <alf__> mlankhorst: on both radeon and intel I get more than one preferred mode for outputs
[11:18]  * alan_g wonders why http://unity.ubuntu.com/mir/using_mir_on_android.html still says "stop" - didn't duflu correct that?
[11:19] <duflu> alan_g: Yes but I don't know how the web gets updated
[11:19] <alan_g> duflu: it ought to be generated from trunk
[11:19] <duflu> alan_g: Wait, no. That's a doc file I forgot to fix
[11:20] <alan_g> Not sure how often
[11:20] <alan_g> duflu: np - go eat
[11:24] <alan_g> tvoss: How do we zap surface flinger in the current image?
[11:53] <alan_g> NM I found https://wiki.ubuntu.com/Touch/Testing/Mir#Switch_from_SurfaceFlinger_to_Mir
[12:21] <mlankhorst> hmz any open bugs I can look at?
[12:29] <kgunn> mlankhorst: if you'd like to pick up where RAOF has left  off https://bugs.launchpad.net/mir/+bug/1204939
[12:32] <didrocks> kgunn: I noticed that unity_support_test tool is stuck in fact
[12:32] <didrocks> (it's launched by compiz)
[12:32] <didrocks> so I guess it's the first gl app which is blocking
[12:39] <mlankhorst> likely
[12:57] <mlankhorst> kgunn: what is that machine btw?
[13:01] <kgunn> mlankhorst: its "otto" which didrocks or jibel can help get you access
[13:03] <mlankhorst> didrocks/jibel: ok, I have no idea what's going on from the logs so if I could get access^
[13:03] <didrocks> mlankhorst: kgunn: the machines are under heavy use right now
[13:03] <mlankhorst> ok
[13:03] <didrocks> kgunn: once we'll have asac's 3h daily release, we won't be able to all to give back access
[13:03] <didrocks> which we are going to plug soon
[13:03] <didrocks> so it's the last calls, this time, please really looks at the logs, later will be too late :)
[13:04] <didrocks> mlankhorst: in ~1h, I should be able to block it
[13:04] <didrocks> will you be around?
[13:04] <didrocks> mlankhorst: you have the VPN access right?
[13:04] <mlankhorst> I'll be here in 1h, I'm on some vpn to qalab
[13:05] <didrocks> mlankhorst: what's your ssh key I should import?
[13:05] <mlankhorst> https://launchpad.net/~mlankhorst/+sshkeys
[13:10] <kgunn> didrocks: understand....but, we've been runnning xmir fine on other ati machines so the problem seems specific to this one
[13:10] <didrocks> kgunn: we know what happens with "specific to this one" which then happens to multiple configs, I'm not that idealist ;)
[13:11] <didrocks> if on one of the 2 machines we have, it happens (and traditional Xorg is working with acceleration), there is probably something that can affect other
[13:11] <kgunn> didrocks: we tried yesterday with 3 others with no problems
[13:11] <kgunn> 3 other ati that is
[13:11] <didrocks> kgunn: as Unity7, I never uploaded a Unity7 that was screwed on my machines at home
[13:11] <didrocks> then… you see that even testing on 4 with the 3 cards were not enough :p
[13:11] <didrocks> so I wish we can settle that down
[13:12] <seb128> didrocks, I don't think anyone is trying to deny there is an issue, it's just harder to debug when the hardware you have local access to doesn't reproduce the issue
[13:12] <kgunn> didrocks: nvmd, our exchange doesn't seem helpful
[13:12] <didrocks> seb128: that exactly why I'm proposing access for the past 2 weeks
[13:13] <kgunn> didrocks: again not helpful
[13:13] <seb128> kgunn, what would be helpful to debug, out of access to the machine we have which hit the issue?
[13:14] <asac> kgunn: didrocks: i guess you might want to align the exact execution environment so you see the same thing
[13:14] <kgunn> seb128: unfortunatley, we're spanning time zones (and we weren't helping ourselves with xorg churn...but we're past that)...so now we need to iterate
[13:15] <kgunn> asac: we've verified multiple environ's on other machines....it could even be the specific card/family at this point
[13:15] <asac> once you are sure you do the exact same thing, investigating difference in behavioru becomes relevant
[13:15] <asac> kgunn: right it could. just want to ensure that we are sure its the different card/family
[13:15] <asac> and not something else we do different still
[13:15] <didrocks> asac: it's passing with the same packages and setup on the intel machine
[13:16] <kgunn> asac: were you on this channel yesterday?
[13:16] <asac> that doesnt mean you run stuff in the exact same way that kgunn is running them
[13:16] <asac> kgunn: i was in this channel, but not following
[13:16] <didrocks> kgunn: wasn't the same with the race issue? you never reproduce it before we spot it as dailies and after that we discovered that a lot of devs got it but juts reboot? (we had the same argument of "we never saw that, it's only you")
[13:17] <didrocks> sorry for being extra cautious, but I think we should understand what's happen before pushing u-s-c
[13:17] <kgunn> didrocks: ok, let's try it otherway around....would you mind setting up lexington machine via robotfuel to be exactly like otto ?
[13:17] <kgunn> this way there is no more questions about setup ?
[13:17] <kgunn> didrocks: that would be helpful....what do you think?
[13:18] <kgunn> didrocks: to be clear...i am not asking you to push u-s-c....i am trying to repro the problem with ott
[13:18] <didrocks> kgunn: first, as we still don't have those 3h-dailies, I'll be able to give access to mlankhorst  and block every stacks on this
[13:18] <kgunn> otto
[13:18] <didrocks> kgunn: I don't know if they have another ati machine with the same card?
[13:18] <mlankhorst> what is that machine btw?
[13:18] <kgunn> didrocks: got it...but i am anticipating we still won't have it solved
[13:18]  * kgunn is a realist
[13:18] <didrocks> mlankhorst: the one I pasted the other day, you will have access
[13:19] <didrocks> kgunn: let's hope we know what happens first, RAOF spent more than 1h on it this morning
[13:19] <robotfuel> kgunn: I don't think we have a system with the same card
[13:19] <didrocks> kgunn: then, yeah, we need a more dynamic QA lab for stuff running on real hardware
[13:20] <kgunn> didrocks robotfuel ....why not make sure the one in lexington lab has the same steup/run of a trademark didrocks run ??
[13:20] <kgunn> who cares if the card is different....
[13:20] <kgunn> this goes back to your post a moment ago about teams claiming that stuff isn't broken only to find out it is
[13:21] <didrocks> jibel: can you install otto on that one? as it seems kgunn and asac may think otto is the cause of this?
[13:21] <didrocks> kgunn: I just wonder as we would have the same issue with intel, or even unity won't even run on traditional Xorg on ati
[13:21] <didrocks> which it does ~20 times a day for multiple hours for the past 5 months
[13:21] <kgunn> didrocks: jibel .....i am more suspicious of it being a potential ati-issue
[13:22] <didrocks> like that driver/card in particular? (completely possible)
[13:22] <mlankhorst> my ati works just fine
[13:22] <kgunn> didrocks: could be a combo - your specific setup + your specific test run + ati driver (general even)
[13:22] <mlankhorst> oh wait PROVE_LOCKING is disabled due to some regression, grrr
[13:23] <kgunn> mlankhorst: yeah...i'm just trying to nail the exact environ + test run eliciting the behavior
[13:24] <didrocks> kgunn: no test are run at this point as the session never successfully fully comes up, but yeah, setup + ati driver
[13:24] <jibel> didrocks, install otto on which one? if there is a box remotely accessible I can deploy the test setup on it of course
[13:24] <didrocks> (knowing that it's working on Xorg + unity/compiz on that card)
[13:24] <didrocks> robotfuel: ^
[13:25] <mlankhorst> hmz :p
[13:26] <mlankhorst>     drm: Don't pass negative delta to ktime_sub_ns()
[13:26] <mlankhorst>     
[13:26] <mlankhorst>     It takes an unsigned value. This happens not to blow up on 64-bit
[13:26] <mlankhorst>     architectures, but it does on 32-bit, causing
[13:26] <mlankhorst>     drm_calc_vbltimestamp_from_scanoutpos() to calculate totally bogus
[13:26] <mlankhorst>     timestamps for vblank events. Which in turn causes e.g. gnome-shell to
[13:26] <mlankhorst>     hang after a DPMS off cycle with current xf86-video-ati Git.
[13:28] <robotfuel> jibel: didrocks you can use ps-radeon-hd6870-he
[13:28] <mlankhorst> makes me wonder if it only happens to blow up on i386 or not ;)
[13:31] <alan_g> alf__: any ideas on how best to progress https://code.launchpad.net/~alan-griffiths/mir/fix-1208774/+merge/178925?
[13:33] <alf__> alan_g: I would be good to find out what the problem is (probably just a linker bug), but I think the workaround is ok for now.
[13:34] <kgunn> robotfuel: jibel didrocks mlankhorst ....the key is to setup & "start" the run on ps-radeon-hd6870-he in exactly the same manner
[13:34] <kgunn> as otto
[13:35] <alan_g> alf__: Feel like voting then?
[13:35] <alf__> alan_g: sure
[13:36] <jibel> kgunn, undertood
[13:36] <mlankhorst> how do I connect to that one btw?
[13:37] <kgunn> robotfuel: ^ ?
[13:38] <robotfuel> mlankhorst: https://wiki.canonical.com/UbuntuEngineering/QA/Lab ctrl-f and search for ps-radeon-hd6870-he
[13:40] <kgunn> jibel: mlankhorst robotfuel ...thanks for all this....heroes you are!
[13:40] <kgunn> or will be :)
[13:43] <mlankhorst> is something supposed to happen when i hit connect?
[13:44] <mlankhorst> oh there we go
[13:50] <mlankhorst> kgunn: hm default xmir works?
[13:54] <kgunn> mlankhorst: ....can we ensure our boot and attempt to programatically run are the exact same to didrocks on otto, e.g. he ran unity_support_test
[13:54] <didrocks> (compiz does in fact)
[13:54] <didrocks> mlankhorst: the machine will be available in 5 minutes
[13:58] <kgunn> didrocks: does it run that every boot regardless? (e.g. we don't need to enable any boot script or something)
[14:00] <didrocks> kgunn: if you start an unity session, it's ran
[14:01] <kgunn> didrocks: :-/....damn, back to otto
[14:02] <kgunn> didrocks: what is the specific card on that again (i'll note it in the bug)
[14:03] <didrocks> kgunn: one sec, launching the tests ASAP and noting it on the bug
[14:05] <mlankhorst> curiously is otto a machine without its outputs connected to anything?
[14:10] <mlankhorst> i suppose I could test that setup locally
[14:19] <mlankhorst> hm my machine died without output connected
[14:19] <tvoss> mlankhorst, kgunn, didrocks any more insight into the ati issue?
[14:20] <mlankhorst> hah
[14:20] <kgunn> tvoss: right now...suddenly seems to work....didrocks suspecting hybris
[14:20] <kgunn> getting solved
[   60.988003] other info that might help us debug this:
[   60.988003]  Possible unsafe locking scenario:
[   60.988003]
[   60.988003]        CPU0
[   60.988003]        ----
[   60.988003]   lock(&mm->mmap_sem);
[   60.988003]   <Interrupt>
[   60.988003]     lock(&mm->mmap_sem);
[   60.988003]
[14:20] <mlankhorst> but no idea wtf is going on there
[14:21] <kgunn> mlankhorst: did i speak too soon....is that otto or your local  ?
[14:21] <mlankhorst> local
[14:21] <didrocks> second run, works…
[14:21] <didrocks> (well started)
[14:21] <didrocks> the machine didn't die
[14:21] <mlankhorst> no idea wtf is going on there
[14:22] <kgunn> tvoss: then didrocks gonna check diff between yesterday & today
[14:22] <kgunn> tvoss: ....enjoying your afternoon off :)
[14:22] <mlankhorst> new mir patch for ati at least
[14:23] <mlankhorst> meh list corruption in nfs here, grrr
[14:25] <mlankhorst> why does nfs have to add a new corruption every time I update my kernel :/
[14:26] <didrocks> kgunn: didn't yet look at it, before yesterday-today: http://paste.ubuntu.com/5962760/
[14:28] <mlankhorst> didrocks: yeah ubuntu2 ati, might have been what fixed it
[14:28] <didrocks> mlankhorst: interesting
[14:29] <mlankhorst> but no idea really what was going on
[14:30] <didrocks> can be that or Mir itself
[14:32] <mlankhorst> hm fun, another crash at a random place in the kernel
[14:42] <mlankhorst> I'm definitely hitting some nasty fd corruption on this linux/master + airlied/drm-fixes kernel
[14:48] <mlankhorst> other machine is fine though :/
[14:50] <didrocks> ok, so can't reproduce anymore
[14:50] <didrocks> after 3 runs
[14:50] <didrocks> and then one run to regular Xorg with another stack
[14:50] <didrocks> no hang
[14:50] <didrocks> no machine getting crazy
[14:50]  * didrocks just removes a flacky test from the list and will push u-s-c to universe
[14:51] <mlankhorst> ok I think it's radeon's fault on my machine at least, I swapped out the card for another one and that machine works
[14:52] <kgunn> jibel: robotfuel didrocks mlankhorst ...thanks for all the help
[14:52] <didrocks> kgunn: yw
[14:52]  * kgunn 's beer/food list is getting long
[14:53] <mlankhorst> my 6570 hangs really badly, 5570 works
[14:53] <mlankhorst> getting really bad kernel memory corruption with the 6570, so I'll have to look at that later
[14:54] <kgunn> mlankhorst: thanks...
[14:54] <jibel> kgunn, yw, thanks to whoever fixed this crash
[14:56] <kgunn> robotfuel: was there a Northern Islands (HD 6xxx) Series ati in lexington working ok ?....just tieing this back to mlankhorst complaint about 6570
[14:57] <robotfuel> kgunn: we have a 6870, but it's not being used on the new server. openarena worked on it before with xmir
[14:58] <mlankhorst> I'm close to upstream though, hm perhaps even ahead of upstream, I'll try without some patches :P
[14:58] <robotfuel> kgunn: it's the one jibel is testing with
[14:58] <mlankhorst> oh i was already testing without those
[14:58] <kgunn> robotfuel: cool....yeah, that's definitely same family
[14:58] <kgunn> seris
[14:58] <kgunn> series
[14:59] <mlankhorst> but in my case it's definitely a kernel corruption
[15:00] <mlankhorst> no way userspace would screw up this badly :P
[15:03] <smartboyhw> mlankhorst, in http://unity.ubuntu.com/mir/using_mir_on_pc.html it says in Running Mir Natively a "some-mir-client" command.
[15:03] <smartboyhw> What does that mean?
[15:05] <smartboyhw> olli_, ^
[15:06] <olli_> smartboyhw, in a meeting, kgunn^
[15:12] <kgunn> smartboyhw: like for instance mir_demo_client_egltriangle
[15:12] <smartboyhw> kgunn, oK
[15:13] <smartboyhw> mir_demo_client_egltriangle
[15:13] <smartboyhw> kgunn, whoa nice!
[15:15] <kgunn> smartboyhw: there's several there
[15:15] <smartboyhw> kgunn, you should provide a list to us:P
[15:34] <alan_g> smartboyhw: ls mir_demo_client*
[15:34] <smartboyhw> alan_g, great, thanks
[15:35] <kgunn> racarr: can you join us ??
[18:07] <kgunn> racarr: ping
[18:26] <kgunn> racarr: ping (sorry...i kept rebooting i know)
[18:42] <racarr> kgunn: pongish
[18:42] <racarr> Hey wait I'm supposed to be racarr|dentist
[18:42] <racarr> what's up?
[18:45] <kgunn> racarr: no worries...hopefully its a "good" dentist experience & not a "painful" one
[18:45] <racarr> medium lol
[18:45] <kgunn> racarr: was just curious...we were wondering on surface configurator if mir is to control the osk visibiltiy with the minimize attribute
[18:45] <kgunn> ?
[18:46] <racarr> kgunn: Yeah! I think that's the idea.
[18:46] <racarr> we need to hook it up to qtubuntu
[18:46] <kgunn> racarr: cool greyback|dinner ...dang he's at dinner ^
[18:46] <racarr> but dandrader was telling me mallit just calls like QWindow show/hide
[18:46] <racarr> so, the surface configurator actually does two things for the OSK:
[18:46] <racarr> 1. Let's it recognize the overlay surface type (and approve/dissaprove setting this) with select_attribute_value
[18:47] <racarr> 2. Implement minimize/restore with the attribute_set interface
[18:47] <kgunn> racarr: that's perfect!
[18:47] <kgunn> thanks for pushing that...
[18:50] <racarr> :D
[18:51] <racarr> I have to go again soon. I failed to bring proof of residence to the DMV yesterday so trying again today
[18:51] <racarr> Drivers license expires tomorrow so if I don't do it today I have to take a driving test ><
[18:51] <racarr> I think, based on kdubs branch though, I can submit a much simpler version of client-focus-notifications
[18:51] <racarr> hopefully this evening or tomorrow
[19:11] <greyback> kgunn: ack, all sounds good to me
[20:05] <kgunn> bschaefer: thanks for the help yesterday!....glad it "resolved itself"
[20:06] <bschaefer> kgunn, haha np, as I am...and I hope it stays that way
[20:06] <bschaefer> and yay u-s-c is in main :)
[20:06] <kgunn> bschaefer: i know....feels naughty!
[20:20] <kdub> yay
[21:10] <robert_ancell> thomi, hey, did you forward that itinery?
[21:10] <racarr> next time you guys come to oakland I can not recommend the california DMV
[21:10] <racarr> for a fun afternoon
[21:11] <kdub> racarr, in lexington next month, i'll show you my license with my dmv picture
[21:11] <kdub> pretty funny how evidently angry i am in it :P
[21:12] <racarr> haha
[21:12] <robert_ancell> kdub, ha!
[21:12] <racarr> apparently when the person yesterday told me I needed a copy nof my birth certificate
[21:12] <racarr> they meant in particular, the original copy
[21:12] <thomi> robert_ancell: we're having trouble finding flights from bos -> SFO or LAX that don't involve a huge stopover. Should have final flights tomorrow
[21:13] <robert_ancell> thomi, k
[21:15] <robert_ancell> thomi, is it faster to go via NYC?
[21:20] <thomi> robert_ancell: NYC is kind of in the wrong direction
[21:20] <thomi> I have faith that BTS will sortit out. Worst case is 10 hours in SFO - maybe time to do a bit of sightseeing :)
[21:23] <racarr> thomi: That's just long enough to get a drivers license at the DMV!
[21:23] <racarr> :p
[21:23] <thomi> racarr: I already ahve two drivers licenses, why would I want a third?
[21:24] <racarr> thomi: :)
[21:24] <jono> hey guys
[21:25] <jono> FYI: to track flavor bugs I am going to ask flavors to tag their bugs with 'flavormirbug'
[21:25] <jono> the resulting search with these bugs is at https://bugs.launchpad.net/bugs/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&fie
[21:25] <jono> ld.tag=flavormirbug&field.tags_combinator=ANY&field.status_upstream-empty-marker=1&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on&search=Search
[21:25] <jono> kgunn, ^
[21:25] <jono> is there any chance we could get #1208250 on a priority list?
[21:25] <thomi> haha, nice URL
[21:25] <jono> oh, it is Critical
[21:26] <jono> but seems not assigned
[21:26] <jono> thomi, seriously
[21:35] <robert_ancell> jono, cheers
[21:35] <jono> robert_ancell, np
[21:35] <jono> they are choosing whether to go with Mir on the 22nd
[21:36] <jono> so I think if we can resolve most of their issues by then, it should encourage the Xubuntu community to ship Mir
[22:11] <thomi> robert_ancell: robotfuel is still hitting this issue in the xmir tests: https://bugs.launchpad.net/xmir/+bug/1209000
[22:12] <robotfuel> thomi: I still need to check if that's the case with the new drivers,  this is the bug I was talking about https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/1209397
[22:13] <thomi> robotfuel: ahhh ok
[22:13] <robotfuel> thomi: it looks like they are related
[22:13] <thomi> robert_ancell: so that card is listed on the xmir go/no-go acceptance criteria
[22:13] <thomi> robert_ancell: so it's needed before we turn xmir on for 13.10
[22:14] <thomi> robert_ancell: I wonder if you can use your team-lead super powers to poke someone to fix this for us?
[22:14] <robert_ancell> thomi, otp
[22:15] <robotfuel> thomi: there is actually a new bug, x crashes now with /usr/bin/X: symbol lookup error: /usr/lib/xorg/modules/drivers/radeon_drv.so: undefined symbol: exaGetPixmapDriverPrivate
[22:16] <thomi> robotfuel: OK, can you please make sure that all the relevant bugs are linked in the SS, so I can keep bugging people until they get fixed?
[22:17] <robotfuel> thomi: yes everything but that bug is to date
[22:18] <thomi> robotfuel: OK, so there's 3 issue, the two bugs in the SS (both linked above), and the third that you've just mentioned?
[22:20] <robotfuel> the 1209000 isn't happening anymore,  now it's undefined symbol: exaGetPixmapDriverPrivate
[22:20] <robotfuel> thomi: I'll ping you when apport is done uploading the bug
[22:20] <thomi> sweet
[22:21] <robert_ancell> thomi, robotfuel, ah, RAOF said that one looked like exa support wasn't loaded
[22:21] <robert_ancell> please assign to RAOF for triaging once its up
[22:21] <robert_ancell> What are the other two issues?
[22:22] <racarr> kdub: Have been going through connect-display-request btw. I like it :)
[22:22] <kdub> oh, great :)
[22:22] <robotfuel> robert_ancell: it's one other issue not 2
[22:22] <racarr> will rework client-focus-notifications on the refactoring there to get rid of the event sink changes
[22:22] <robotfuel> robert_ancell: this is the other issue https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/1209397
[22:22] <racarr> I am starting to wonder though...
[22:22] <racarr> (not for this branch, just in general)
[22:23] <robert_ancell> robotfuel, that card has issues on traditional X right?
[22:23] <racarr> perhaps SessionManager isn't mf::Shell
[22:23] <robotfuel> robert_ancell: yes https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/1209397 is a traditional x bug
[22:23] <racarr> you know? There are kind of different roles between this handle_surface_created, and open_session type stuff
[22:24] <racarr> and I'm more inclined to call the handle_surface_created, etc, the 'shell'
[22:26] <kdub> racarr, yeah, should make picking out right where the focus occurred a bit easier
[22:26] <kdub> and should also let you write an implementation of focus that depends on events
[22:26] <kdub> so it can be like,  z-order based in a simple case, or as complicated a class you can think up
[22:27] <racarr> mm
[22:27] <kdub> being in this part of the system for a bit pointed out to me how the shell's grand data structure
[22:27] <kdub> is the SessionContainer
[22:27] <kdub> with mir's grand data structure being the SurfaceStack
[22:27] <kdub> things are starting to shape up along those lines :)
[22:28] <robotfuel> thomi: spreadsheet is up to date
[22:28] <racarr> Alan thinks the session assosciation should be in the SurfaceStack (SceneGraph)
[22:28] <racarr> and I'm not totally sure yet.
[22:28] <thomi> yhanks
[22:28] <thomi> thanks even
[22:29] <racarr> on one hand it might make certain synchronization issues, and exposing stuff out to the shell, etc, easier and safer
[22:29] <robert_ancell> thomi, did you disable the raring builds from the testing ppa?
[22:29] <racarr> on the other hand 1. I'm not sure how to do it and 2. I kind of like the way that the shell functions as
[22:29] <robotfuel> thomi: I am going to mark https://bugs.launchpad.net/xmir/+bug/1209000 fixed released because it's not happening anymore
[22:29] <racarr> something on top of the SurfaceStack
[22:31] <robotfuel> heh it was already marked fixed release :P
[22:31] <kdub> racarr, i'm not sure either about that, but thats an initial reaction
[22:44] <racarr> kdub: Perhaps part of the session manager is really part of the session container
[22:44] <racarr> and the rest is mf::Shell
[22:44] <racarr> i.e.open_session/close_session anyway
[22:44] <racarr> then the shell gets on_session_opened, on_session_closed sort of stuff
[22:46] <kdub> well, the session manager is being reduced to the session factory
[22:47] <kdub> create_surface_for can be eliminated if we have a "SessionMediator-like" class for our internal clients
[22:48] <RAOF> Gah. Why is BTS 50% more expensive than flights I could book myself?
[23:06] <robert_ancell> RAOF, yeah, I always get that too
[23:06] <robert_ancell> RAOF, we really should have an Australasian travel agent
[23:07] <RAOF> Yeah.
[23:07] <RAOF> Also. UA - just say no.
[23:08] <racarr> kdub: mm. maybe there is a SessionMediator that can work for internal and external client sort of object
[23:08] <racarr> and the RPC also has a "socket mediator" or something
[23:11] <robert_ancell> bbl