[00:00] <bschaefer> sure, that'll be fun
[00:00] <bschaefer> is it a bit different than: ppa:canonical-x/x-staging
[00:01] <bschaefer> oo thats xmirs rebased...nm!
[01:48] <bschaefer> RAOF, Im still dropping a lot of events with the new 1.14 server :(, though it hasnt caused the server to crash yet
[01:48] <RAOF> Hm.
[01:49] <RAOF> Still dropping events in a libdrm-intel ioctl?
[01:49]  * bschaefer looks
[01:50] <bschaefer> seems to be: (EE) 11: /lib/i386-linux-gnu/libc.so.6 (ioctl+0x19) [0xb72160c9]
[01:50] <bschaefer> which is above:
[01:50] <bschaefer> (EE) 13: /usr/lib/i386-linux-gnu/libdrm_intel.so.1 (0xb6aff000+0x5d6c) [0xb6b04d6c]
[01:50] <bschaefer> (EE) 14: /usr/lib/i386-linux-gnu/libdrm_intel.so.1 (drm_intel_bo_subdata+0x28) [0xb6b011f8]
[01:51] <bschaefer> though this time mir isn't mentioned in the stacktraces
[02:09] <RAOF> bschaefer: Do you know if that happens outside of Mir?
[02:12] <bschaefer> RAOF, I have not tested that, but i've not noticed theses things until I swiched to xmir
[02:12] <bschaefer> RAOF, let me see if I can get these problems when just using plain old X
[02:13] <RAOF> Ta.
[02:14] <bschaefer> np, and thanks for looking at the log!
[02:32] <bschaefer> so far, plain X everythings fine...but Ill see what happens with working on it all day tomorrow
[03:10] <RAOF> setup-partial-android-chroot.sh is annoying :(
[03:18] <duflu> RAOF: Yep. Enhancements welcome
[03:19] <duflu> RAOF: How so?
[03:19] <duflu> RAOF: Also, if you're still tinkering in this, please unset Needs review: prober-drm-device-probe
[03:19] <RAOF> duflu: No, should now be good.
[03:19] <RAOF> Should have been good the last go around, but setup-partial-android-chroot.sh broke it.
[03:20] <duflu> ?
[03:20] <duflu> Farq. Another ABI bump?!
[03:20] <RAOF> Because libhybris added a dependency, and setup-partial-android-chroot doesn't use apt.
[03:20] <duflu> Come on people...
[03:21] <RAOF> What? When?
[03:23] <duflu> RAOF: Ahem. Just in the proposal I'm testing. Not as bad as I feared
[03:25] <duflu> RAOF: What's the new dep?
[03:25] <RAOF> libandroid-properties1
[03:25]  * duflu shrugs
[03:25] <RAOF> (Or see the merge proposal)
[03:43] <duflu> RAOF: Hmm, so I can't run any *-tests any more? Is there a compromise possible?
[03:44] <RAOF> I could push down the check so that you can't run any gbm tests, but I'm not sure if that's a good idea.
[03:45] <RAOF> Basically, the further down I push that check, (a) the more complicated it is, and (b) the less obvious it is that you're not running the full test suite.
[03:45] <duflu> RAOF: Yeah that's what I was suggesting originally
[03:46]  * duflu hacks it up
[03:54] <kgunn> since i am xmir'ing now....ran my own data
[03:55] <duflu> ?...
[05:09] <robert_ancell> RAOF, is vladmir the correct branch on https://github.com/RAOF/xserver?
[05:10] <robert_ancell> and egl-platform-mir on https://github.com/RAOF/mesa?
[05:10] <RAOF> robert_ancell: Correct.
[05:41] <RAOF> Anyone want to top-approve https://code.launchpad.net/~raof/mir/prober-drm-device-probe/+merge/170765 ? There have been enough changes since the other two approvals that it's probably worth a second lookover.
[06:01] <tvoss> kgunn, ping
[06:07] <duflu> Hmm 1am. Good luck :)
[06:11] <RAOF> tvoss: Good morning!
[06:12] <tvoss> RAOF, good afternoon :) how goes?
[06:12] <RAOF> tvoss: Feel like top-approving https://code.launchpad.net/~raof/mir/prober-drm-device-probe/+merge/170765 ? :)
[06:12] <tvoss> RAOF, for sure :
[06:12] <tvoss> )
[06:12] <RAOF> Assuming you approve of disabling the whole testsuite when umockdev is not available.
[06:22] <tvoss> RAOF, mind renaming TESTS_ENABLED to MIR_TESTS_ENABLED?
[06:23] <RAOF> Not at all.
[06:23] <mlankhorst> smurf everything
[06:24] <RAOF> tvoss: Anything else?
[06:25]  * duflu thinks mlankhorst might have a valid point
[06:28] <tvoss> RAOF, nope
[06:30] <RAOF> Dear System76 Galago: make with the getting here faster.
[06:33]  * duflu gives in and grabs the Mesa source as *documentation*
[06:36] <RAOF> duflu: Hunting down bypass support? :)
[06:36] <duflu> RAOF: Not even that. Hunting down an understanding of src/server/*
[06:37] <RAOF> Ah.
[06:37] <duflu> Hmm. GBM has documentation but it's buried in the source package as alf mentioned. They really should have put it in the header
[06:38] <RAOF> Or even build it and ship it? :)
[06:39] <duflu> Yeah, shipping the docs would be nice.
[06:54] <duflu> alf: Hello...
[06:54] <alf> duflu: hi :)
[06:54] <duflu> alf: "Schedule the current front buffer object for display" ... how is it GBM doesn't think the "front buffer" is front?
[06:55] <duflu> Or is it just a "new" frontbuffer object each time?
[06:56] <tvoss> duflu, mind if I top-approve the prober-mp?
[06:56] <duflu> tvoss: My eyes are closed.
[06:57] <duflu> .. which means I will mind later when I open them. But that won't be today
[06:57] <tvoss> duflu, ack ;)
[06:58] <alf> duflu: gbm doesn't handle display itself, it just has a surface with two (or conceivably) more buffers. When we swap the buffers we get a new front buffer that we are responsible for displaying if we want.
[06:58] <duflu> alf: I am very confused by that terminology. "Front" usually means the one and only buffer visible right now
[07:03] <alf> duflu: this is the front buffer from the surface's perspective (the one that should be visible, gbm_surface_lock_front_buffer()), independent of what is actually displayed.
[07:05] <duflu> alf: That makes sense. I'm just trying to understand why GBM says you call gbm_surface_lock_front_buffer _after_ swap buffers
[07:06] <duflu> alf: Oh, yes, I see. Because swap buffers is not "visible" either. You still have to flip it (which is another buffer swap of sorts)
[07:07] <alf> duflu: right, the swapping operation is independent of displaying any buffers, it's literally just swapping two buffers.
[07:41] <hikiko> I forgot my objectives :/
[07:44] <tvoss> hikiko, ?
[07:45] <hikiko> I forgot to set them this weekend and now I can't do it anymore
[07:45] <hikiko> :s
[07:51]  * RAOF returns from his impromptu IRC bouncer explosion
[08:12] <alan_g> Good morning all, you've had a busy week and a day!
[08:18] <duflu> alan_g: Hello. Yes it seems to always be busy
[08:18] <duflu> I find myself drawing up a class  diagram for parts of mirserver. Has anyone else does this yet?...
[08:19] <alan_g> hi duflu - I see you've taken on comp-bypass. Got all you need>
[08:19] <alan_g> *?
[08:19] <alan_g> @diagram - only the one in the source tree (which is less granular)
[08:20] <duflu> alan_g: All except about 1 month of learning libmirserver's workings I think
[08:20] <duflu> alan_g: Yeah my diagram is quite disparate to the Architecture.dia
[08:20] <alan_g> Doesn't doygen do diagrams if you've got dot?
[08:21] <duflu> Hmm, I suspect it might
[08:22] <duflu> alan_g: Yes doxygen does one diagram per class. I need more
[08:25] <duflu> Oh, there's a more complete one: http://unity.ubuntu.com/mir/inherits.html
[08:27] <alan_g> If that doesn't suit it ought to be possible to munge the doxygen representation - I know folks do that
[08:33] <duflu> On that note, the doxygen style feels a bit ugly and more difficult to navigate than it should be. Can we configure it for other HTML styles?
[08:35] <alan_g> duflu: there are a lot of config options.  IIRC tvoss found a volunteer to investigate (I don't remember who) but I never heard any more.
[08:35] <tvoss> alan_g, that guy never came back to me :/
[08:35] <tvoss> alan_g, welcome back
[08:36] <alan_g> duflu: here's one starting point: http://www.stack.nl/~dimitri/doxygen/manual/customize.html
[08:37] <duflu> Ah, too technical. I was thinking more like pick and choose a "theme"
[08:38] <alan_g> duflu: I've seen mention of a graphical front-end.
[08:39]  * alan_g doesn't believe it is as easy as wordpress
[08:40] <iceroot> hi
[08:41] <RAOF> hey.
[08:41] <iceroot> i am running MIR at the moment and i dont see a real difference to X11 (just a broken mouse pointer), can you recommend a ressource where i will find examples to test out the advantages of MIR? so it would be easier to understand MIR
[08:43] <RAOF> At the moment the advantages are mostly latent. There are a bunch of demos in the mir-demos package, but nothing particularly "wow"
[08:44] <RAOF> Mostly the advantages are when the shell (ie: unity) becomes the display server as well.
[08:45] <iceroot> maybe there is something like "ssh -X" which is running much better then on old X11
[08:45] <RAOF> Nope; we've got no special remote protocol.
[08:46] <RAOF> What we should have for 13.10 is nicer boot→greeter→login→user switch→shutdown transitions.
[08:48] <iceroot> when my vga is fully supported will i face differences/problems when using games from steam? or is this not realted to MIR but just the display driver itself? the programs dont need a change?
[08:52] <RAOF> The programs don't need to change; we'll support running X11 apps for the forseeable future.
[08:52] <RAOF> (They may get the ability to be more awesome if they do change, though)
[08:56] <duflu> alf: Roughly speaking a DisplayBuffer is presently an output, and "Display" is the set of all outputs, right?
[08:57] <duflu> So in Compiz-speak DisplayBuffer==Output and Display==Screen
[08:57] <duflu> Though it would all sound the same to the casual reader
[08:58] <dholbach> hey, so I'm trying to follow the build instructions for mir, but I run into the following:
[08:58] <dholbach> CMake Error at shared/protobuf/CMakeLists.txt:11 (protobuf_generate_cpp):
[08:58] <dholbach>   Unknown CMake command "protobuf_generate_cpp".
[08:58] <dholbach> ^ any advice?
[09:00] <alf> duflu: correct, with the detail that a DisplayBuffer could be shared by different physical monitors (e.g. if we are cloning), so it's not strictly DisplayBuffer==Output
[09:00] <duflu> alf: Sure. OK thanks
[09:00] <iceroot> RAOF: thank you for the useful info
[09:02] <alan_g> dholbach: that sounds like you're missing the protobuf dependency. Did you get errors running "sudo mk-build-deps --install --tool "apt-get -y" --build-dep debian/control"?
[09:03] <duflu> dholbach: It's actually part of CMake (you need a newer CMake): http://www.cmake.org/cmake/help/v2.8.8/cmake.html#module:FindProtobuf
[09:04] <dholbach> duflu, I'm on saucy - how do we build mir in the ppa then? I didn't see a newer cmake in there
[09:05] <duflu> dholbach: Oh actually seems like we might be missing:
[09:05] <duflu> find_package(Protobuf REQUIRED)
[09:05] <duflu> Which should come before the function
[09:05] <duflu> Not sure why it works for the rest of us
[09:06] <dholbach> so if I install all the build dependencies, should  bzr branch lp:mir; cd mir;mkdir build; cd build; cmake ..  succeed?
[09:06] <duflu> dholbach: Yes. Otherwise it's a bug (which is quite possible)
[09:06] <duflu> dholbach: Actually the top-level CMakeLists.txt gets protobuf, which should be inherited in subdirs
[09:07] <dholbach> ok, nevermind - I got it working now - I had to regenerate the cmake data bits after I installed all the build-deps
[09:07] <dholbach> thanks duflu
[09:07] <duflu> dholbach: Cool. Yes CMake often thinks its cache is clean when it's not :/
[09:09] <NikTh> Hello everyone
[09:10] <NikTh> duflu: available ?
[09:10] <duflu> NikTh, yes?
[09:10] <NikTh> Is it a good idea to re-install the system, make all the updates and activate again the PPA to see what's happen ?
[09:11] <NikTh> Now things are messed up. From 4 reboots, 1 can start the display manager with a corrupted desktop (but as you said this is not xmir's problem) and other 3 cannot even start a display manager, I cannot even switch to a VT.
[09:11] <NikTh> If I re-install the system and things are good, we can close this bug as fix released or invalid.. maybe.
[09:11] <NikTh> What you say ?
[09:11] <NikTh> https://bugs.launchpad.net/mir/+bug/1196355
[09:11] <ubot5> Launchpad bug 1196355 in XMir "After the latest updates, no desktop session - Ubuntu 13.10 (2013/07/01) - XMir dies with signal 6" [High,Incomplete]
[09:13] <duflu> NikTh, I find sometimes with similar issues, I just need to delete ".Xauthority" from the home directory to get my desktop back
[09:13] <duflu> Delete it and then reboot, try again
[09:13] <NikTh> duflu: I have already tried this but to no avail :)
[09:15] <duflu> NikTh: OK, well if it's causing such system-wide issues and you can't debug it further by yourself, then yes I would suggest a full re-install and avoiding all PPAs. Because PPAs are use-at-your-own-risk
[09:16] <NikTh> duflu: The PPA and my own-risk is not the problem. I created this installation to test xmir and help.. (in any way I can- I'm not a programmer)
[09:16] <NikTh> To report bugs.. etc
[09:17] <NikTh> But now, I cannot do much. The system is unusable. If I re-install and after full updates, the same problem occurs, then this is definitely a bug. And you(we) should check it, seriously.
[09:18] <NikTh> But If I re-install and after full updates, this is not happen , maybe we can close this as invalid or something ;)
[09:19] <NikTh> xmir will be the default Display Server in 13.10 as I know. If I (or some other people) cannot install and use 13.10... well I guess this is a problem :)
[09:20] <NikTh> What you suggest. To re-install, or wait for updates ? I can still update the system. I can chroot.
[09:21] <duflu> NikTh: I know it's something that needs wider testing. But at the same time, we can only easily fix the bugs that we (any Mir developer) can reproduce.
[09:22] <duflu> Other bugs are still bugs, certainly, but we can't fix them (knowingly and confidently) without reproducing them
[09:23] <NikTh> hmm.. I think I understand that. Then I guess 13.10 will be a "testing release" for xmir. When you getting in to universe and apport works, It will be easier to report bugs.
[09:25] <duflu> NikTh: Certainly managing bugs will be easier when everyone is using the same installation and updates (13.10)
[09:25] <NikTh> Then I will leave it to your judge to do whatever you want with my report :)
[09:26] <duflu> NikTh: Incomplete can stay so indefinitely. And if more information comes up, even from other people, then it can be re-opened and work continue on that bug
[09:26] <NikTh> More info came from me last night. See the last logs but I don't know if they help.
[09:27] <NikTh> OK, nice talking to you.. I have to leave now. :)
[09:27] <NikTh> duflu: Thanks )
[09:35] <duflu> Hmm, doxygen documents deleted methods. Useful
[10:00] <alf> duflu: @threadsafe-clients, are the locks recursive to handle the protobuf RPC "done" callbacks?
[10:01] <duflu> alf: Actually they're recursive because they used to be around all client callbacks too. But no longer. I'm not sure if there's a remaining need for recursiveness, but that bug is still open
[10:02] <duflu> Good point, but I must go set dinner on fire
=== dholbach_ is now known as dholbach
[10:11] <dholbach> so I just built mir locally and built RAOF's xserver branch with --enable-xmir - it can't seem to find mir_client_library.h though (it was placed in /usr/local/include/mirclient/mir_toolkit/mir_client_library.h) - anything I probably missed somewhere?
[10:11] <dholbach> basically what I ran into was: http://paste.ubuntu.com/5835758/
[11:31] <greyback> hi folks, am having problem with Mir with egl clients. They fail with libegl - unsupported platform (null)
[11:32] <greyback> alan_g: ^ any idea?
[11:34] <alan_g> greyback: on desktop?
[11:34] <greyback> alan_g: yep
[11:35] <alan_g> Last time I had that it was because of a bad mesa version (caused by the repo being messed up)
[11:36] <greyback> alan_g: what mesa package version have you? Are accelerated demo clients working ok for you? I'm using mir staging
[11:38] <alan_g> greyback: I'm about a week out of date - been on vacation and not updated
[11:39] <greyback> ok
[11:39] <alan_g> alf: anything you're aware of ^^
[11:44] <alf> greyback: what version does dpkg -s libegl1-mesa give you?
[11:44] <alf> alan_g: I am not aware of any problems
[11:44] <greyback> alf: 9.2~git20130628.g6b676e6-0ubuntu0+mir1-jenkins83saucy0
[11:45] <alf> greyback: is mir from the ppa too, or are you building from source?
[11:45] <greyback> alf: from mir staging ppa
[11:46] <greyback> as are all the mir-related packages on my machine right now
=== alan_g is now known as alan_g|lunch
[12:15] <greyback> alf: any ideas? My problem or no?
[12:19] <alf> greyback: Does mir server start fine, only clients fail?
[12:22] <greyback> alf: server fine. unaccelerated clients fine. Only those using egl
[12:25] <kgunn> greyback: i would change ppa to be system-compositor-testing
[12:25] <kgunn> http://unity.ubuntu.com/mir/installing_prebuilt_on_pc.html
[12:25] <kgunn> the staging ppa is wild west
[12:26] <greyback> kgunn: apparantly so.
[12:27] <kgunn> greyback: note, if you're running xmir....they moved type==unity to a "unitysystemcompositor" conf file (out of lightdm)
[12:27] <kgunn> just in case you're toggling xmir/x in lightdm....it could trip you up
[12:27] <greyback> kgunn: noted, thanks
[12:31] <greyback> rebooting
=== alan_g|lunch is now known as alan_g
[13:15] <didrocks> kgunn: hey! how are you?
[13:15] <kgunn> didrocks: good (crazy times)
[13:16] <didrocks> kgunn: I'm looking at the progress on https://bugs.launchpad.net/mir/+bugs?field.tag=entering-saucy and it doesn't seem good (the only ones which are fixed committed are the copyright stuff my team worked on with robert)
[13:16] <didrocks> kgunn: FYI, since Thursday, I have nothing I can do more to get mir under dailies, the ball is in your team's camp :)
[13:16] <didrocks> (for daily release and then distro)
[13:16] <didrocks> just as a reminder, the armhf FTBFS is a blocker for dailies
[13:17] <kgunn> didrocks: understood...
[13:17] <didrocks> the rest are blockers for distro
[13:17] <didrocks> kgunn: do you have any idea for a date at least to get dailies?
[13:17] <kgunn> didrocks: yeah, bregma was looking at arm build and it was canadian holiday yesterday
[13:17] <didrocks> kgunn: ok, please keep me in touch :)
[13:18]  * bregma lifts his groggy head
[13:18] <kgunn> :)
[13:44] <kgunn> alan_g: alf question...regarding swapinterval(0), i noticed a caveat on kdub's mp, that it'll work for work for gbm ipc clients only
[13:45] <kgunn> doesn't that only really mean you couldn't get the shell to set it via this mech
[13:45] <kgunn> ?
[13:45] <kgunn> e.g. any other app will work just fine
[13:52] <alf> kgunn: that MP implements SwapInterval support for IPC clients only, native client (e.g. the shell) support hasn't been implemented yet.
[13:53] <kgunn> alf thanks...i was just verifying my thot/understanding. hooray...i understood
[13:54] <kgunn> alf: which also means, we need a cooresponding bit in xmir to pass it through....which probably isn't there yet ?
[13:54] <alf> kgunn: I think the code in Mesa is already hooked up
[13:55] <alf> kgunn: so in theory now eglSwapInterval(0) from a IPC client should work
[13:57] <alan_g> WTF? ctest only runs 2 tests
[13:57] <kgunn> alf: thanks
[13:58] <alf> alan_g: there were some changes while you were away... we decided that TDD isn't worth it after all :D
[13:58]  * alan_g is glad he hasn't signed the new contract
[14:00] <kgunn> :)
[14:03] <alan_g> alf: is it just me? OR has something changed?
[14:05] <alf> alan_g: ctest runs fine for me. I remember having come across a similar situation and the solution was a fresh build in my case.
[14:06] <alan_g> alf: tried that, and deleting the cmake cache and regenerating
[14:06] <alf> alan_g: ahh, got it... apt-get install libumockdev-dev
[14:07] <alan_g> ?
[14:07] <alan_g> That's why my test binaries are old?
[14:09] <alan_g> Couldn't cmake give me a useful message instead of dropping build targets?
[14:09] <alf> alan_g: https://code.launchpad.net/~raof/mir/prober-drm-device-probe/+merge/170765 check comments from 2013-07-01 and on
[14:12]  * alan_g glad he's not the only one not happy with this
[14:12] <kdub> good morning
[14:13] <alan_g> LOL
[14:36] <kdub> welcome back alan_g
[14:36] <alan_g> thanks kdub - looks like fun has been had while I was away
[14:36] <greyback> hey, I'm using the cross-compiler script to build Mir. Is failing with this error: http://pastebin.ubuntu.com/5836380/
[14:37] <greyback> where do I get libandroid-properties.so.1 ?
=== alan_g is now known as alan_g|tea
[14:38] <kdub> greyback, i'll look for it...
[14:38] <kdub> hopefully the script isnt broken
[14:41] <greyback> kdub: thanks!
[14:46] <kdub> greyback, i see the script in lp:mir downloading that dependency... perhaps merge the tip of lp:mir?
[14:46] <kdub> and regenerate the ndk
=== alan_g|tea is now known as alan_g
[14:48] <greyback> kdub: by "regenerate the ndk" you mean what exactly?
[14:49] <kdub> rm the partial-armhf-chroot in the build directory
[14:49] <greyback> gotcha
[14:49] <kdub> greyback, the file appears to be in 'libandroid-properties1', by the way
[14:50] <greyback> kdub: makes sense :)
[14:50] <greyback> it's been downloaded into the chroot anyway
[14:58] <kgunn> rebooting
[15:08] <kdub> doh, my mir-devel mails were ending up in a never checked gmail folder -_-
[15:14] <greyback> oh today is not my day with Mir. I'm on GalaxyNexus, using saucy flipped image, installed the mir-team/staging PPA, now mir_demo_server* fails this this error : http://pastebin.ubuntu.com/5836465/
[15:15] <kdub> greyback, somehow, you look to be loading the mesa drivers
[15:16]  * alf is unhappy that umockdev is leaking memory and his tests fail under valgrind :/
[15:17] <greyback> kdub: sorry to sound like an idiot, but what driver should load?
[15:17] <alan_g> alf should punish those that approved the MP
[15:17] <kdub> greyback, it should link tho the hybris egl implementations, not the mesa ones. check where libEGL.so is resolving into
[15:18] <greyback> alan_g: that's what reverting is for :)
[15:18] <alan_g> alf: ^
[15:18] <alf> greyback: alan_g: that's what whips are for ;)
[15:26] <greyback> kdub: yep is mesa. but no idea where the hybris egl implementation is.
[15:29] <kdub> greyback, i'd make sure you have libhybris installed (although i think its default on phablet)
[15:29] <kdub> /usr/lib/arm-linux-gnueabihf/libhybris-egl/libEGL.so.1.0.0
[15:39] <greyback> kdub: libhybris installed ok, but seems all mir demos are linked to mesa
[16:36]  * alan_g has just lost all his window decorations
=== alan_g is now known as alan_g|reboot
[16:47] <kdub> we have like an 'on air' meeting in a bit?
[16:48] <kdub> is that still true jono? :)
[16:49] <dholbach> kdub, AFAIK it's kgunn, jono, pmcgowan, mramm, thostr_ (and a few others) giving a weekly update on ubuntuonair.com
[16:50] <dholbach> or did kgunn send you as his replacement? :)
[16:50] <kgunn> dholbach: coming....
[16:50] <kdub> dholbach, nah, just made a note of 'mir meeting 5pm utc today' while reading planet ubuntu a while back
[16:51] <dholbach> ahhhh ok
[16:51] <kgunn> work still happens before the weekly ;)
[16:52] <jono> kdub, Mir meeting is after the weekly update
[17:02] <alan_g> Goodbye all
=== alan_g is now known as alan_g|EOD
[17:10] <kdub> english needs more synonyms for 'surface'
[17:22] <kdub> racarr got lucky revno #800
[17:30] <kgunn> kdub: i feel totally challenged....synonyms for surface
[17:30] <kgunn> kdub: skin
[17:35] <baronos> the last daily-live image the ubuntu is already with the mir by default?
[17:42] <ogra_> baronos, images are only built from packages in the ubuntu archive ... Mir is not in the archive yet
[17:42] <baronos> ok, thanks :)
[17:57] <tvoss> RAOF, you about?
[17:58] <RAOF> Yes.
[17:59] <robert_ancell> thomi, there?
[17:59] <tvoss> RAOF, mute mic and cam
[17:59] <tvoss> :)
=== kdub is now known as kdub^lunch
=== ari_ is now known as arsson
[18:56] <thomi> robert_ancell: no, sorry, but I am now
[18:56] <robert_ancell> thomi, np, on air session finishing now.
[19:02] <robert_ancell> thomi, there wasn't any major testing questions for you :)
[19:03] <thomi> robert_ancell: nuts, sorry, I completely forgot. TBH, somehow it never made it on my calendar
[19:03] <thomi> sorry about that
=== kdub^lunch is now known as kdub
[21:56] <kdub> wait... is desktop using boost 1.53?
[21:57] <racarr> Seems so
[21:58] <kdub> doh. android is still using 1.49
[22:00] <kdub> well, rather... if you cross compile using the scripts, its 1.49 (pbuilder probably does the right thing)
[22:07] <racarr> somehow I am not getting a vtable for my interface
[22:08] <racarr> SessionAuthorizer, when I remove the std::string argument
[22:08] <racarr> the method gets inlined and there is no vtable for the whole class as far as I can tell
[22:08] <racarr> what does it mean :
[22:08] <racarr> (
[22:08] <racarr> oh it means I deleted the = 0
[22:38] <robert_ancell> RAOF, ping
[22:50] <robert_ancell> RAOF, It seems the vladmir-ubuntu branch is the correct xserver branch, not vladmir - Is there a way to set up github to use vladmir-ubuntu by default? Or delete the old branch / update it?
[22:51] <racarr> for each acceptance test client that is connecting
[22:51] <racarr> SocketSession::on_new_connection is being called twice
[22:51] <racarr> and it's being added to the
[22:51] <racarr> connected sessions list twice
[22:51] <racarr> except the first time the socket credentials are nonsense
[22:52] <racarr> and the second time they are the correct client PID
[22:52] <racarr> oO
[23:54] <RAOF> robert_ancell: github now shows vladmir-ubuntu by default. I forgot that I'd started to just make changes directly to the ubuntu branch.