=== ara is now known as Guest80428 === Cimi_ is now known as Cimi [09:43] * duflu wonders if the Atom will finish building Mir today === seb128_ is now known as seb128 === davmor2_ is now known as davmor2 [10:05] 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 === ubot5` is now known as ubot5 [10:09] fast, works - chose any one. :( [10:10] 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] software too [10:11] Any clue about the GL clients failing? [10:13] alan_g: Possibly missing GL extenions (the ones used to load GL images into textures) [10:13] Ah. And Mir is just as fast as LXDE, without the ugly tearing of LXDE :) [10:13] So failing to check result codes is the first thing [10:15] alan_g: Yep [10:15] But another day [10:16] Sure. Nice it works so well otherwise [10:43] slangasek: you were raising a protobuf issue yesterday? [10:45] alan_g: He logged it as https://bugs.launchpad.net/mir/+bug/1275372 [12:15] i have one of those - currently only runnig lxde because all other environments are two slow === larva is now known as Guest59937 === alan_g is now known as alan_g|lunch [13:49] 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] basically we now need mir to work with the android backend on x86 as well === dandrader is now known as dandrader|afk === fginther` is now known as fginther === dandrader|afk is now known as dandrader === 14WAB1TAR is now known as vila [14:58] 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? === alan_g|lunch is now known as alan_g [15:23] 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] bug 1275372 in Mir "mir: FTBFS in trusty-proposed, tests fail against libprotobuf8" [Critical,Triaged] https://launchpad.net/bugs/1275372 [15:24] 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] 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] 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] slangasek: I believe you. (Just makes it hard to guess what's wrong) [15:31] Morning [15:32] racarr: your alarm clock is still broken :) [15:33] wait no now it's 7:33 right [15:33] yes [15:35] alan_g: just sitting here thinking about your discussion with slangasek... [15:36] alan_g: so since we're already in a build pickle with platform-api blocking us... [15:37] alan_g: ok...nvmd...i thot it thru, we just have to merge that back into dev [15:37] actually the whole trunk back into dev [15:37] not as bad as i originally thot [15:40] kgunn: Just think of "dev" as the trunk and "trunk" as a release branch and it feels more normal === xnox_ is now known as xnox === dandrader is now known as dandrader|lunch === larva is now known as Guest59640 [16:59] slangasek: How are you running the tests? https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1275372/comments/1 [16:59] Launchpad bug 1275372 in Mir "mir: FTBFS in trusty-proposed, tests fail against libprotobuf8" [Critical,Triaged] [17:00] alan_g: as part of the package build [17:00] alan_g: reproducible with a native build on x86 === jono is now known as Guest16175 [17:05] slangasek: I've tried on x86 - still CNR - we are doing something differently [17:05] alan_g: output of "dpkg -l '*protobuf*' | grep ^ii" in your build environment? [17:06] alan_g: you aren't passing 'DEB_BUILD_OPTIONS=nocheck' in your environment (because of cross-builds), are you? [17:06] $ dpkg -l '*protobuf*' | grep ^ii [17:06] ii libmirprotobuf-dev:i386 0.1.3+14.04.20140108-0ubuntu1 i386 Display server for Ubuntu - protocol definition [17:06] ii libmirprotobuf0:i386 0.1.3+14.04.20140108-0ubuntu1 i386 Display server for Ubuntu - protocol implementation [17:06] ii libprotobuf-dev:i386 2.5.0-5ubuntu1 i386 protocol buffers C++ library (development files) [17:06] ii libprotobuf-lite8:i386 2.5.0-5ubuntu1 i386 protocol buffers C++ library (lite version) [17:06] ii libprotobuf7:i386 2.4.1-3ubuntu4 i386 protocol buffers C++ library [17:06] ii libprotobuf8:i386 2.5.0-5ubuntu1 i386 protocol buffers C++ library [17:06] ii protobuf-compiler 2.5.0-5ubuntu1 i386 compiler for protocol buffer definition files [17:07] ii python-protobuf 2.5.0-5ubuntu1 all Python bindings for protocol buffers [17:07] slangasek: I'm just doing "make -j4 && ctest" [17:07] alan_g: please use debian/rules build [17:07] slangasek: ok [17:07] alan_g: correction: 'fakeroot debian/rules binary' [17:11] slangasek: running (but that takes a while to run) [17:11] alan_g: yep, understood [17:12] alan_g: fwiw, the relevant test call in debian/rules is this: GTEST_OUTPUT=xml:./ dh_auto_test --max-parallel=1 [17:12] (once the package build has run through once, you should be able to call that directly to iterate) [17:32] alan_g: any luck? [17:33] buiid at 97% [17:33] ok [17:33] * slangasek sits on his hands ;) [17:37] slangasek: it finished successfully. But I don't see any test run in backscroll [17:39] The unit test binary passes (with LD_PRELOAD) [17:40] And so does "GTEST_OUTPUT=xml:./ dh_auto_test --max-parallel=1" [17:41] alan_g: ok, so 'GTEST_OUTPUT=xml:./ dh_auto_test --max-parallel=1' passes without any LD_PRELOAD? [17:42] alan_g: I noticed that you were on i386... I was testing on amd64. Could be that has an effect here [17:42] let me try to reproduce on i386; can you try to reproduce on amd64? [17:43] slangasek: I can try - but EOD for me is 18min away [17:43] mmk [17:47] * alan_g still thinks this would be a very strange effect of protobuf changes === dandrader|lunch is now known as dandrader [18:04] slangasek: left it building - will check back when I get a minute (after supper) === alan_g is now known as alan_g|EOD [18:33] slangasek: works on amd64 [18:33] curious [18:34] my i386 build is still running, let's see what happens === jono is now known as Guest82971 [19:44] Is freenode acting weird? [19:44] No [19:45] racarr, it was for most of the day [19:45] they had a DDOS === quickert is now known as Ranomier === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader === kgunn is now known as Guest438 [21:18] hello mir people. [21:20] how far away is screencasting mir? [21:30] 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] correct details when alf_ is back online :) [21:44] what the what [21:44] https://launchpad.net/ubuntu/+source/mir/0.1.3+14.04.20140108-0ubuntu2 [21:44] why is cmake now broken? [21:45] hmm [21:45] because I uploaded from a dirty tree, sigh [21:45] popey: I am the wrong one to ask [21:46] k [21:47] maybe someone on -unity knows whether thats planned or in progress.. [23:37] popey: it will be a raw vid stream of what's happening on screen, no plan to show where you touched or swiped