[09:43]  * duflu wonders if the Atom will finish building Mir today
[10:05] <duflu> Awesome. Mir on an old Intel Atom is super-responsive, compositing at 60FPS. If only it wasn't also suffering a bug; https://bugs.launchpad.net/mir/+bug/1275398
[10:09] <alan_g> fast, works - chose any one. :(
[10:10] <duflu> alan_g: Well, moving sofrware surfaces around is faster and smoother than anything I've ever seen on a old netbook. It's kind of exciting
[10:10] <duflu> software too
[10:11] <alan_g> Any clue about the GL clients failing?
[10:13] <duflu> alan_g: Possibly missing GL extenions (the ones used to load GL images into textures)
[10:13] <duflu> Ah. And Mir is just as fast as LXDE, without the ugly tearing of LXDE :)
[10:13] <alan_g> So failing to check result codes is the first thing
[10:15] <duflu> alan_g: Yep
[10:15] <duflu> But another day
[10:16] <alan_g> Sure. Nice it works so well otherwise
[10:43] <alan_g> slangasek: you were raising a protobuf issue yesterday?
[10:45] <duflu> alan_g: He logged it as https://bugs.launchpad.net/mir/+bug/1275372
[12:15] <anpok> i have one of those - currently only runnig lxde because all other environments are two slow
[13:49] <rsalveti> alf_: hey, remember we discussed a way to dynamically load a mir backend instead of making that decision in build-time? this was part of the emulator discussion https://blueprints.launchpad.net/ubuntu/+spec/core-1311-ubuntu-touch-for-x86
[13:49] <rsalveti> basically we now need mir to work with the android backend on x86 as well
[14:58] <dandrader> alan_g|lunch, so to add my own messages on top of the regular ones in the mir socket I've to extend ProtobufSessionCreator and ProtobufMessageProcessor?
[15:23] <slangasek> alan_g: hi there - yes, I've inadvertently started a Mir-affecting protobuf transition in trusty; and mir doesn't pass its test suite with the new one (bug #1275372). Is this something you could help with fixing, so we can go forward instead of backwards with the protobuf transition?
[15:24] <slangasek> alan_g: (if not, then the right thing to do is to back out the protobuf transition so it doesn't block mir landings)
[15:25] <alan_g> slangasek: yes. I'll help. Been wondering what the easiest way to grab the protobuf update to test without breaking other work (the error just looks unrelated)
[15:26] <slangasek> alan_g: well, you can grab the new protobuf from trusty-proposed; as for it looking unrelated, I did a test build with protobuf as the only difference, and it passed with the old one and fails with the new
[15:27] <alan_g> slangasek: I believe you. (Just makes it hard to guess what's wrong)
[15:31] <racarr> Morning
[15:32] <kgunn> racarr: your alarm clock is still broken :)
[15:33] <racarr> wait no now it's 7:33 right
[15:33] <racarr> yes
[15:35] <kgunn> alan_g: just sitting here thinking about your discussion with slangasek...
[15:36] <kgunn> alan_g: so since we're already in a build pickle with platform-api blocking us...
[15:37] <kgunn> alan_g: ok...nvmd...i thot it thru, we just have to merge that back into dev
[15:37] <kgunn> actually the whole trunk back into dev
[15:37] <kgunn> not as bad as i originally thot
[15:40] <alan_g> kgunn: Just think of "dev" as the trunk and "trunk" as a release branch and it feels more normal
[16:59] <alan_g> slangasek: How are you running the tests? https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1275372/comments/1
[17:00] <slangasek> alan_g: as part of the package build
[17:00] <slangasek> alan_g: reproducible with a native build on x86
[17:05] <alan_g> slangasek: I've tried on x86 - still CNR - we are doing something differently
[17:05] <slangasek> alan_g: output of "dpkg -l '*protobuf*' | grep ^ii" in your build environment?
[17:06] <slangasek> alan_g: you aren't passing 'DEB_BUILD_OPTIONS=nocheck' in your environment (because of cross-builds), are you?
[17:06] <alan_g> $ dpkg -l '*protobuf*' | grep ^ii
[17:06] <alan_g> ii  libmirprotobuf-dev:i386                               0.1.3+14.04.20140108-0ubuntu1          i386         Display server for Ubuntu - protocol definition
[17:06] <alan_g> ii  libmirprotobuf0:i386                                  0.1.3+14.04.20140108-0ubuntu1          i386         Display server for Ubuntu - protocol implementation
[17:06] <alan_g> ii  libprotobuf-dev:i386                                  2.5.0-5ubuntu1                         i386         protocol buffers C++ library (development files)
[17:06] <alan_g> ii  libprotobuf-lite8:i386                                2.5.0-5ubuntu1                         i386         protocol buffers C++ library (lite version)
[17:06] <alan_g> ii  libprotobuf7:i386                                     2.4.1-3ubuntu4                         i386         protocol buffers C++ library
[17:06] <alan_g> ii  libprotobuf8:i386                                     2.5.0-5ubuntu1                         i386         protocol buffers C++ library
[17:06] <alan_g> ii  protobuf-compiler                                     2.5.0-5ubuntu1                         i386         compiler for protocol buffer definition files
[17:07] <alan_g> ii  python-protobuf                                       2.5.0-5ubuntu1                         all          Python bindings for protocol buffers
[17:07] <alan_g> slangasek: I'm just doing "make -j4 && ctest"
[17:07] <slangasek> alan_g: please use debian/rules build
[17:07] <alan_g> slangasek: ok
[17:07] <slangasek> alan_g: correction: 'fakeroot debian/rules binary'
[17:11] <alan_g> slangasek: running (but that takes a while to run)
[17:11] <slangasek> alan_g: yep, understood
[17:12] <slangasek> alan_g: fwiw, the relevant test call in debian/rules is this: GTEST_OUTPUT=xml:./ dh_auto_test --max-parallel=1
[17:12] <slangasek> (once the package build has run through once, you should be able to call that directly to iterate)
[17:32] <slangasek> alan_g: any luck?
[17:33] <alan_g> buiid at 97%
[17:33] <slangasek> ok
[17:33]  * slangasek sits on his hands ;)
[17:37] <alan_g> slangasek: it finished successfully. But I don't see any test run in backscroll
[17:39] <alan_g> The unit test binary passes (with LD_PRELOAD)
[17:40] <alan_g> And so does "GTEST_OUTPUT=xml:./ dh_auto_test --max-parallel=1"
[17:41] <slangasek> alan_g: ok, so 'GTEST_OUTPUT=xml:./ dh_auto_test --max-parallel=1' passes without any LD_PRELOAD?
[17:42] <slangasek> alan_g: I noticed that you were on i386... I was testing on amd64.  Could be that has an effect here
[17:42] <slangasek> let me try to reproduce on i386; can you try to reproduce on amd64?
[17:43] <alan_g> slangasek: I can try - but EOD for me is 18min away
[17:43] <slangasek> mmk
[17:47]  * alan_g still thinks this would be a very strange effect of protobuf changes
[18:04] <alan_g> slangasek: left it building - will check back when I get a minute (after supper)
[18:33] <alan_g|EOD> slangasek: works on amd64
[18:33] <slangasek> curious
[18:34] <slangasek> my i386 build is still running, let's see what happens
[19:44] <racarr> Is freenode acting weird?
[19:44] <racarr> No
[19:45] <ogra_> racarr, it was for most of the day
[19:45] <ogra_> they had a DDOS
[21:18] <popey> hello mir people.
[21:20] <popey> how far away is screencasting mir?
[21:30] <anpok> currently being worked on, i.e. there is a mp https://code.launchpad.net/~afrantzis/mir/mir-screencast-server-frontend/+merge/203809 in progress, another one for the client api has been merged alreadn, then there will probably be one or two more for platform support
[21:31] <anpok> correct details when alf_ is back online :)
[21:44] <slangasek> what the what
[21:44] <slangasek> https://launchpad.net/ubuntu/+source/mir/0.1.3+14.04.20140108-0ubuntu2
[21:44] <slangasek> why is cmake now broken?
[21:45] <slangasek> hmm
[21:45] <slangasek> because I uploaded from a dirty tree, sigh
[21:45] <anpok> popey: I am the wrong one to ask
[21:46] <popey> k
[21:47] <anpok> maybe someone on -unity knows whether thats planned or in progress..
[23:37] <Guest438> popey: it will be a raw vid stream of what's happening on screen, no plan to show where you touched or swiped