[01:42] <RAOF> Huh.
[01:42] <RAOF> ProtobufMessageProcessor really is entirely untested.
[05:52] <duflu> Why is it "bzr log FILE" often shows revisions that have nothing to do with FILE?
[06:03] <RAOF> It does?
[06:08] <duflu> RAOF: Yes, more often than not. So bzr log FILE is mostly useless
[06:08] <duflu> Seems like a bug
[06:08] <duflu> If I analyse the revisions it gives me then FILE is not in them
[06:09] <RAOF> Huh. Do you have an example file? I've never seen that.
[06:09] <RAOF> (And I do occasionally do bzr log FILE)
[06:11] <duflu> RAOF:  bzr log src/shared/protobuf/mir_protobuf_wire.proto
[06:12] <RAOF> Hm, quite true.
[06:12] <RAOF> Odd.
[06:12]  * duflu experienced git again for the first time in a long time last night. It was nice :)
[14:12] <tkamppeter> I have submitted a MIR for the "brlaser" printer driver package (bug 1359137). I would like to get it in before FF. The package is super simple and small. Could this be done? I have already posted on #ubuntu-release but did not get any answer.
[14:13] <tkamppeter> I hope this is about "Main Inclusion Request", if not, tell me which channel is the correct one.
[14:16] <greyback> tkamppeter: this channel is about Mir, the display server, not MIRs
[14:16] <greyback> tkamppeter: #ubuntu-devel probably better channel
[14:19] <alan_g> kdub: when you could reproduce lp:1358698 - was it on desktop or phone?
[14:19] <kdub> alan_g, it was on phone
[14:20] <kdub> and I tried bisecting, but at some point the process of updating binaries fixed the problem for me
[14:20] <kdub> i can see if i can reproduce again, seems its giving us a headache
[14:20] <alan_g> kdub: I remember that - just wasn't sure where you were running it
[14:22] <alan_g> kdub: BTW welcome back - I trust you're fully recovered>?
[14:23] <kdub> alan_g,  yeah, enough that cold/flu medicine takes care of the remaining symptoms
[14:42] <tkamppeter> greyback, OK.
[15:20] <alan_g> does anyone know why we dlopen our platform plugins with RTLD_GLOBAL when we're going to use dlsym to resolve the symbols?
[15:22]  * alan_g sees that bzr says alf_ wrote that.
[15:43] <AlbertA2> alan_g: I think I tried removing it once
[15:44] <AlbertA2> and I got loading errors in unity8
[15:44] <AlbertA2> but I can't remember for sure
[15:44] <AlbertA2> I vaguely remember something to do with the fact that unity-mir is also loaded at runtime
[15:47] <alan_g> AlbertA2: It seems strange, but I can wait for an explanation (as it isn't causing the problem).
[15:47] <alan_g> I hope
[15:48]  * alan_g is glad he's not the only one to ever wonder
[15:53] <greyback> AlbertA: unity-mir dead. Qtmir (its replacement) is not dl-loaded
[15:56] <AlbertA2> greyback: right...I was just recalling some months ago when I tried removing RTLD_GLOBAL
[15:57] <AlbertA2> but there may be some other reason it's there
[16:00] <AlbertA2> racarr_: thanks for the help, worked like a charm :) https://code.launchpad.net/~albaguirre/mir/fix-1359264/+merge/231584
[16:03] <greyback> AlbertA: gotcha
[16:03] <AlbertA2> greyback: oh I wanted to ask you where in qtmir is the wait for first frame? curious...
[16:04] <greyback> AlbertA: http://bazaar.launchpad.net/~mir-team/qtmir/trunk/view/head:/src/modules/Unity/Application/mirsurfaceitem.cpp#L384
[16:05] <greyback> AlbertA: which is called by a Mir SurfaceObserver::frame_posted
[16:05] <greyback> http://bazaar.launchpad.net/~mir-team/qtmir/trunk/view/head:/src/modules/Unity/Application/mirsurfaceitem.cpp#L226
[16:06] <AlbertA2> thanks!
[16:07] <greyback> we then have code in MirSurfaceManager to only add the surface to the scene once the first frame is posted
[16:08] <AlbertA2> greyback: and is there an easy way to cross-compile qtmir?
[16:08] <greyback> AlbertA: I sbuild it usually
[16:08] <greyback> or else develop on device, since it's pretty small :)
[16:10] <AlbertA2> so qmake and then make?
[16:11] <greyback> hang on, you need to be careful to use gcc4.9
[16:11] <greyback> qmake "QMAKE_CXX=arm-linux-gnueabihf-g++-4.9" "QMAKE_LINK=arm-linux-gnueabihf-g++-4.9" "QMAKE_LINK_SHLIB=arm-linux-gnueabihf-g++-4.9"
[16:11] <greyback> then make
[16:11] <greyback> make install
[16:12] <AlbertA2> ahh thanks!
[16:22]  * alan_g has managed to reproduce bug 1358698 (and it's only Wednesday!)
[16:25] <kdub> alan_g, yay
[16:35] <alan_g> kdub: I got excited too soon. It happened twice - now with the same *binaries* I can't reproduce.
[16:35] <kdub> hmm, so a fun transient problem
[16:41]  * kdub goes on the case too
[16:42] <alan_g> kdub: I have a theory about the time I got it...
[16:43] <alan_g> The test discovery code died with it
[16:43] <alan_g> and that ran *before* the libmirplatformgraphics library was created
[16:44] <kdub> missed something, before the library was created?
[16:44] <alan_g> so if we load a libmirplatformgraphics which depends upon a *different* version of libmircommon
[16:44] <alan_g> yes
[16:45] <alan_g> There's no dependency in cmake on the platformgraphics library
[16:45] <alan_g> Because that is dlopened
[16:45] <alan_g> and no-one added a rule
[16:45] <alan_g> so if we load a libmirplatformgraphics which depends upon a *different* version of libmircommon
[16:46] <alan_g> then we could be getting two versions of libmircommon in memory
[16:46] <alan_g> *BOOM*
[16:46] <alan_g> But that timing doesn't explain all the CI failures
[16:47] <kdub> yeah, its a reasonable explanation, but I don't see how the problem could be transient
[16:47] <alan_g> Once the libmirplatformgraphics has been built the problem goes away
[16:47] <alan_g> as we pick up the right one
[16:52] <alan_g> Anyway, if that is actually the cause then the latest rev of this ought to pass CI: https://code.launchpad.net/~alan-griffiths/mir/integration-and-unit-tests-link-against-internals/+merge/230810
[16:52] <racarr_> AlbertA2: Yay :) will review
[16:52] <racarr_> *
[16:52] <racarr_> whoops
[16:53] <alan_g> But it doesn't (yet) explain why CI consistently goes wrong and we have a rare intermittent.
[16:54] <kdub> maybe its a fresh install everytime? (trying to think what that could change)
[16:55]  * alan_g is tempted to revert -c1846 just to see if that masks the problem
[16:58] <alan_g> kdub: another MP may shed light (but I expect it to eliminate an idea, not provide a solution): https://code.launchpad.net/~alan-griffiths/mir/fix-1358698/+merge/231423
[16:58] <alan_g> but I'm hitting EOD and hope it to be solved when I get into work tomorrow. ;)
[17:00] <AlbertA2> greyback: what's your incantantion for sbuild - it keeps failing here on getting the dependencies
[17:02] <greyback> AlbertA: hmm let me check here first. I usually do "sbuild -c utopic-amd64-armhf --host=armhf -j3" ut it's been a while
[17:06] <greyback> AlbertA: failed for me on g++4.9 - same for you? I had hoped that was fixed by now.
[17:07] <AlbertA2> greayback: yeah
[17:08] <greyback> https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1353855
[17:09] <greyback> I can't recommend anything else except working on device, sorry
[17:10] <AlbertA2> greyback: thanks...
[17:15] <AlbertA2> greyback: though for me is failing on mor than just g++4.9: http://paste.ubuntu.com/8099543/
[17:15] <AlbertA2> which makes me think I'm missing something else as well
[17:17] <racarr_> you could install the needed dependencies
[17:17] <greyback> hmm. My output for comparison, in case it helps: http://pastebin.ubuntu.com/8099553/
[17:17] <racarr_> in a prepopulated sbuild
[17:17] <racarr_> and then remove all the build-deps from debian/rules before running sbuild
[17:17] <racarr_> lol...
[17:17] <racarr_> ridiculous of course but its become
[17:17] <greyback> back in your cage you!
[17:17] <racarr_> really hard to build on device imo
[17:17] <racarr_> there is barely enough space
[17:17] <racarr_> for mir/qtmir build deps
[17:17] <racarr_> anymore
[17:18] <greyback> true, I just about squeeze it in these days
[17:18] <racarr_> and last time I actually only managed to do it by manually deleting a bunch of stuff from /usr/lib lol
[17:18] <racarr_> but I think I had some stuff
[17:18] <racarr_> left over too
[17:18] <greyback> apt-get clean if your friend
[17:18] <racarr_> lol
[17:18] <racarr_> I know even with rming /var/cache/apt/archives
[17:18] <racarr_> though
[17:18] <racarr_> unless apt-get clean does more
[17:18] <greyback> think it's the same
[17:18] <racarr_> lol, anyway, I hope we can make sbuild work...
[17:18] <greyback> it's been like that for >1 month now
[17:19] <greyback> it'll probably go away if 4.9 made default
[17:41] <AlbertA2> umm the weird part is g++-4.9 is already installed in the chroot
[17:42] <racarr_> it's the cross compile chain v. armhf binary or some such right?
[17:42] <racarr_> (it's->the problem is)
[17:42] <mibofra> AlbertA2, hi :D, recompiling mir wasn't successful xD. And I think you (you as the developers/engineers of the mir's team) do not want to support a chroot environment XD .
[17:44] <AlbertA2> mibofra: log?
[17:46] <AlbertA2> racarr_: oh yeah...
[17:48] <mibofra> AlbertA, the same results of the demos provided by executables on the packages, do you remember them?
[17:49] <AlbertA2> mibofra: oh so you were able to compile fine, just failure at run time again?
[17:49] <greyback> AlbertA: the amd64 g++ is installed, but it's trying to install the armhf one. I tried this cheeky patch: http://pastebin.ubuntu.com/8099582/ but it failed further on with qmake not being found (wrong arch installed)
[17:51] <mibofra> yeah AlbertA2, apart from a compiling issue that I had to fix (the system was an make's assassin xD, so I've free other sources for make and it (make) ran fine).
[17:52] <AlbertA2> mibofra: well if you can step through the egltriangle example with gdb
[17:52] <AlbertA2> mibofra: since the stack trace was pretty useless
[17:52] <AlbertA2> mibofra: it could help us narrow down the issue...
[17:53] <mibofra> yeah it was, let's see
[19:06] <AlbertA2> kgunn_: was there a bug# for the dash flash when opening apps?
[19:07] <kgunn_> uh yeah, i know daniel logged one....lemme look
[19:13] <mibofra> AlbertA2, apart form the stacks what do you find useful/ do you need/ do you debug usually?
[19:13] <AlbertA2> logcat and dmesg...specially if it's a driver issue...
[19:13] <AlbertA2> but in your case it's a client side issue...
[19:15] <mibofra> AlbertA2, we've seen the dmesg, the output of logcat it's regular http://paste.ubuntu.com/8100365/
[19:15] <AlbertA2> right...
[19:15] <AlbertA2> so stepping through does not help?
[19:21] <kdub> our mp's are outta control
[19:21] <AlbertA2> kdub: only 24... ;)
[19:23] <AlbertA2> greyback: so it was indeed the first blank frame causing the dash flash
[19:23] <AlbertA2> greyback: https://code.launchpad.net/~albaguirre/qtmir/ignore-first-frame/+merge/231612
[19:24] <greyback> AlbertA2: yep saw that, but I'm very curious why Mir gives us a "frame drawn" notification, and the first frame we pull is not drawn to
[19:25] <AlbertA2> greyback: I seem to recall, but not entirely sure
[19:25] <AlbertA2> that we are getting a swap buffers from qt...without actual content...so the framework just goes through the motions...
[19:26] <AlbertA2> but I have to check again...so much has changed
[19:26] <racarr_> lol CI went on a crazy run through everytrhing
[19:26] <mibofra> AlbertA2, I've to try every option of gdb xD but if you want I can setup an ssh access so you can try other things (if you want).
[19:27] <AlbertA2> greyback: or it could just be the driver doing that as well...
[19:28] <greyback> AlbertA2: it's Mir's job to try isolate me from driver quirks :)
[19:28] <AlbertA2> mibofra: well if you could narrow it down to a top level call at least, to see if it's just driver setup or a call in mir
[19:28] <greyback> AlbertA2: I'm not against the patch, but IMO it needs a big FIXME/HACK comment and an associated Mir bug
[19:28] <AlbertA2> greyback:  :)=
[19:29] <greyback> AlbertA2: you're sure skipping just 1 frame is enough?
[19:29] <AlbertA2> greyback: yeah I'll dig deeper but for now that should do...
[19:29] <AlbertA2> greyback: yeah it's only the first frame... I tested on n10 and others
[19:31] <AlbertA2> greyback: well the thing I'm not sure it's a mir bug yet, like I said, I think alan or alf suspected Qt calling swap_buffers
[19:31] <AlbertA2> before rendering any content at the begninning
[19:31] <AlbertA2> but this was some months ago
[19:32] <greyback> AlbertA2: hmm first I've heard of that. Is possible
[20:54] <mibofra> AlbertA2, a thing, if you want I can say to you how I've setup my chroot (enviroment)
[20:54] <AlbertA2> mibofra: sure
[20:54] <mibofra> *environment
[20:54] <mibofra> AlbertA2, so you can maybe reproduce it and test it yourself
[21:01] <mibofra> AlbertA2, initially I've used this project: http://botbrew.com/ , and this app https://play.google.com/store/apps/details?id=com.botbrew.basil (with source on https://github.com/jyio/botbrew-gui). Basically it bootstrap a copy of emdebian (not even developed form july), and automatize the chroot process, binding /dev /sys /proc ecc.., so it's simple to replace emdebian with ubuntu touch or other systems.
[21:04] <mibofra> I had some issues with use some functions of the app, like install some parts of emdebian, some parts required some manual interventions that couldn't be done except from an shell with adb or a terminal emulator.
[21:05] <AlbertA2> greyback: so yeah it was a bug in mir: https://bugs.launchpad.net/mir/+bug/1359406
[21:05] <AlbertA2> mibofra: ok... but what is the initial platform?
[21:05] <mibofra> but ubuntu touch it's basically complete for use, so you don't need to fix nothing apart from manually replace the emdebian with ubuntu touch
[21:06] <mibofra> AlbertA2, I really didn't understand you with this question lol
[21:06] <mibofra> what do you mean?
[21:06] <AlbertA2> mibofra: is it a rooted android phone? or you already have ubuntu touch running on it? or something else?
[21:07] <mibofra> AlbertA2, I've said it before, it's an android (cyanogenmod 11) rooted phone.
[21:07] <AlbertA2> oh I see...and android app
[21:07] <AlbertA2> ok...
[21:09] <AlbertA2> mibofra: so the app does all the setup for you?
[21:09] <AlbertA2> mibofra: nothing else needed?
[21:09] <mibofra> AlbertA2, anyway basically only mir doesn't work, pulse works, network manager too, dbus too
[21:12] <mibofra> AlbertA2, yeah it's much less work to do. You've only to use the first option of the app
[21:12] <racarr_> Your problem could relate to...well...
[21:12] <racarr_> if the app is for running debian
[21:12] <racarr_> I dont see why it would bother setting up the appropriate
[21:12] <racarr_> symlinks for /system
[21:12] <racarr_> to the androit root...
[21:13] <AlbertA2> racarr__: but render_to_fb is working though
[21:13] <racarr_> ah damnit
[21:13] <AlbertA2> racarr__: so the server seems ok
[21:13] <racarr_> lol
[21:13] <AlbertA2> it's the client driver context
[21:13] <mibofra> AlbertA2, the deployed system will be under /data/botbrew-basil in default
[21:13] <racarr_> I was going to guess wrong libGL
[21:13] <racarr_> :(
[21:13] <racarr_> hmm
[21:13] <AlbertA2> that crashes
[21:13] <racarr_> I wonder if ubuntu touch runs natively on the device
[21:13] <racarr_> e.g. community port
[21:14] <AlbertA2> mibofra: have you tried runing the egltriangle example with sudo?
[21:14] <AlbertA2> just to rule out permission issues
[21:14] <racarr_> ohhh there isa theory
[21:14] <AlbertA2> mibrofra: ok and then you chroot into that dir?
[21:15] <mibofra> racarr_, the server can load the necessary libraries, http://paste.ubuntu.com/8101160/ and the demo render_to_fb works and I can see the output on the screen.
[21:16] <mibofra> AlbertA2, basically I work with root only at the moment
[21:16] <AlbertA2> mibofra: ok..
[21:16] <mibofra> even if I can add and login with normal users
[21:17] <mibofra> racarr_, there is a port of utouch for my phone (the gt-i9300), without ril support but there is. Anyway the logic is that if I can run ubuntu touch in this way, every user of an arm7 phone/tablet will be able to use ubuntu touch without porting it.
[21:19] <racarr_> mm would be neat
[21:19] <mibofra> (anyway the porting for my phone it's discontinued xD )
[21:20] <mibofra> racarr_, and I like the concept to put an hdmi adaptor, a pair of bluetooth keyboard and mouse and see unity on the screen of my lcd hd TV and use my phone as my desktop pc xD
[21:24] <mibofra> racarr_, yeah think about this, you deploy ubuntu touch under android, and use it without porting and maybe switch between the os by a script that route the hw (start/stop the services on both the os) and you can "dualboot" without rebooting the phone
[21:25] <AlbertA2> mibofra: motorola did that actually a few years ago :)
[21:26] <mibofra> racarr_, and the devices are shared with both the so, so for example, I've used xboxdrv to use the wireless xbox receiver and controller and android seen it and I can use it on android. Or ubuntu touch can use the fm receiver or the nfc chip without developing the support for each device.
[21:27] <mibofra> AlbertA2, yeah and I think it's an intelligent thing
[21:28] <mibofra> AlbertA2, an maybe less pain for you devs/engineers, basically with this approach every arm7 device that runs andorid it's virtually supported
[21:28] <mibofra> :)
[21:28] <AlbertA2> mibofra: well that's the approach we take already...we use the android binary blobs
[21:29] <AlbertA2> for modem, display, etc...
[21:29] <AlbertA2> but the devil is on the details...
[21:29] <AlbertA2> specially display drivers
[21:30] <AlbertA2> they all have different caveats/bugs...
[21:30] <mibofra> AlbertA2, yeah xD . And I hate a thing
[21:31] <mibofra> Basically every linux system can mange the modules with modprobe and the other tools
[21:31] <mibofra> on /system/lib there are the libs ok but there isn't the index lib as on every linux system
[21:32] <mibofra> so if you try a modprobe module that's the response: modprobe: ERROR: ../libkmod/libkmod.c:557 kmod_search_moddep() could not open moddep file '/lib/modules/3.0.64-CM-g8245168/modules.dep.bin'
[21:32] <AlbertA2> well that's an android thing
[21:34] <mibofra> ok AlbertA2 but why don't use an "tested" approach of the modules managing?
[21:35] <AlbertA2> I guess that's a google question :)
[21:36] <mibofra> AlbertA2, I think they have fun to see the devs imprecate porting android on other devices that aren't the nexus series xD.
[21:38] <mibofra> AlbertA2, just a thing I've remembered, where is gone ubuntu for TVs?
[21:43] <mibofra> just to curiosity (yes I'm curious)
[21:43] <AlbertA2> mibofra: I don't know...that's more of a roadmap question...
[21:43] <mibofra> *for
[21:43] <mibofra> ok
[22:24] <mibofra> AlbertA2, anyway I'm here if you have any ideas.