[00:00] <racarr_> ok really is there a script to update the sha1sums file? it turns out to be easy to make a mistake lol
[00:00] <racarr_> for example find include | grep -v client | egrep "\.h$" | xargs sha1sum
[00:00] <racarr_> will accidentally skip internal_client.h :p
[00:04] <racarr_> It seems like there are already
[00:04] <racarr_> a bunch of missing files from
[00:04] <racarr_> the sha1sum file?
[00:18] <RAOF> That would not be surprising.
[03:44] <duflu> RAOF: Mesa isn't talking to libmirclient any more. Does it need rebuilding or did we break the client ABI? (https://bugs.launchpad.net/mir/+bug/1350163)
[03:45] <RAOF> duflu: Oh, that works if you set EGL_PLATFORM=mir
[03:46] <duflu> RAOF: So what changed? Isn't it a bug that a process with no $DISPLAY is trying to use X?
[03:46] <RAOF> Dunno, haven't looked into it yet.
[03:47] <RAOF> FWIW, X11 is the fallback when autodetect fails; it might be falling there.
[03:47] <RAOF> To luncheon!
[03:47] <duflu> RAOF: Well Mesa hasn't changed in a month. So I guess we removed/changed a symbol used in detection of libmirclient
[04:38] <RAOF> Uuuum.
[04:38] <RAOF> Does nothing actually link with libmirplatform?
[10:02] <alf_> alan_g: https://code.launchpad.net/~kdub/mir/fd-refcount/+merge/228306/comments/553483, something missing?
[10:03] <alan_g> alf_: no
[10:03] <alan_g> Those lines can be replaced with nothing
[10:05] <alf_> alan_g: ok, it's not very clear from the comment :)
[10:06]  * alan_g was in a minimalist mood when he wrote it
[10:06] <alf_> alan_g: but I see kdub got the point
[14:22] <groot> hello all
[14:23] <groot> kdub, I tried but didn't able to figure out how to debug hwcomposer with gdb. Now I'm trying to use ALOGE to print those information you requested. Can you check if it's the correct way ?
[14:23] <groot> http://paste.ubuntu.com/7905245/
[14:25] <kdub> groot, lets log the opposite, eg
[14:25] <kdub> if (ctx->dev.common.module != NULL) ALOGE("ctx->dev.common.module is not NULL");
[14:26] <kdub> that way we can see if it hits those lines at all, so we can rule out problems in lines 7-10
[14:26] <groot> kdub, all right. I'll compile and test.
[14:27] <kdub> groot, cool
[14:28] <groot> kdub, I forgot you also mentioned that i can do this by printing :). This seems much easier.
[14:29] <kdub> groot, that should work too
[14:29]  * kdub bequeaths groot with the community helper of the month award
[14:30] <groot> kdub, :P
[14:36] <groot> kdub, here's the output. I also enabled printing from libhardware.so to see if modules are loaded. Last lines seems interesting to me.
[14:36] <groot> http://paste.ubuntu.com/7905383/
[14:38] <kdub> groot, could you pastebin the .c file again?
[14:39] <groot> kdub, you mean hwcomposer.c ? It's here https://github.com/AndroidOpenSourceXperia/android_hardware_ste-sony/blob/master/display/libhwcomposer/hwcomposer.c
[14:39] <kdub> right, but with your modifications
[14:39] <kdub> for the logging
[14:40] <groot> kdub, here it is http://paste.ubuntu.com/7905418/
[14:41] <kdub> groot, okay, one more thing.. lets log the return value
[14:46] <groot> kdub, how can I do that? something like  ALOGE("%d", ctx->dev.prepare); ?
[14:48] <groot> hmm, they are functions so this'll not work probably
[14:50] <kdub> groot, so down there at lines 1762-1776, the function can return a few different values, lets make sure it returns the 0 at line 1765
[14:54] <groot> kdub, I don't know which file calls this function :(
[14:55] <kdub> groot, so what i mean is put printf("the return code was 0"); in line 1764
[14:56] <groot> kdub, Ahh, I'm a fool. Will do now and compile.
[15:02] <groot> kdub, seems it returns zero. http://paste.ubuntu.com/7905563/
[15:03] <kdub> groot, okay, seems like we've hit a dead end... have to think of other things to try
[15:09] <groot> kdub, allright. I'll try to do some more debugging in the mean time.
[15:46] <racarr> Morning
[15:47] <kdub> hola
[18:49] <robotfuel> kgunn: ping, https://bugs.launchpad.net/mir/+bug/1347053 is a serious bug, someone should be assigned to fix it.
[19:15] <racarr> annd back
[19:49] <racarr> what is the latest progress on software opengl
[19:49] <racarr> one of the problems in qtmir testing is it's difficult to mock/stub out/separate
[19:51] <racarr> the QtSG and the QML engine and its tying together with the QWindows and
[19:51] <racarr> to test a convincing amount of hte code without Qt going and rendering some opengl for you ;)
[19:51] <racarr> or at least trying to make sure a context iws valid etc
[20:57] <racarr> Is there a special qmake incantation to get qtmir to build against a local install of mir I tried
[20:57] <racarr> bzr clean-tree, exporting PKG_CONFIG_PATH, qmake, make
[20:57] <racarr> and I see the include directories get thrown in to the path, etc
[20:57] <racarr> except something is apparently still linking against my old system mir because
[20:57] <racarr> it cant find
[20:57] <racarr> Rectangles
[21:11] <racarr> well so much for keeping my system install clean :p
[21:12] <racarr> ill build packages at least
[21:45] <racarr> ...Rectangles had nothing to do with the versioning
[21:45] <racarr> it just can't find it...why would that be...
[21:48] <racarr> ah
[21:48] <racarr> it needs to link explicitly against mircommon
[21:48] <racarr> the Appliucation plugin
[21:49] <racarr> Why am I having to link it against mircommon but other people are able to build it...
[21:49] <racarr> anyway going to propose a change to mircommon pc that includes the link flag
[21:50] <racarr> this is literally a brand new install too so I dont think its anything messed up on my system...
[22:02] <racarr> anyway...https://code.launchpad.net/~mir-team/mir/mircommon-link-flag/+merge/228950 :)
[22:08] <racarr> back soon
[22:20] <racarr> back
[22:21] <racarr> time to wrestle some qmake
[22:27] <racarr> trying out the existing qtmir tests...
[22:27] <racarr> [libprotobuf ERROR google/protobuf/descriptor_database.cc:57] File already exists in database: mir_protobuf_wire.proto
[22:27] <racarr> familiar?
[22:30] <racarr> I guess im linking against libmirprotobuf twice
[22:30] <racarr> because of this mircommon linkage...
[23:20] <racarr> Sharing ServerRunner and InProcessServer out of mir_test_framework seems like such a pain that its almost better just
[23:20] <racarr> copied to qtmir...
[23:20] <racarr> i.e. do we really want to publish a new library in any shape or form
[23:20] <racarr> probably not :p