[03:43] <duflu> RAOF, anyone: Please review this ASAP: https://code.launchpad.net/~mir-team/mir/fix-1364772/+merge/233298
[06:22] <RAOF> Hm. Why doesn't this work?
[06:22] <RAOF> ...checks...
[06:22] <RAOF> return std::shared_ptr<PlatformProbeReport>{};
[06:22] <RAOF> Oh. Yeah. Need to actually implement that :)
[06:23] <duflu> RAOF: Trivial needs fixing ... then we can land it: https://code.launchpad.net/~raof/mir/from-the-neglected-branches-files/+merge/233150
[06:26] <RAOF> Ta, done.
[07:07] <duflu> Saviq: Just starting on your symbol bug now. Is it actually a problem that needs fixing in 0.7 or is a clean ABI bump later in 0.8 enough?
[07:07] <duflu> Because the latter can't be backported to 0.7
[07:08] <Saviq> duflu, I don't think it's a huge problem, as long as it gets resolved, it's rare that people would just install one package (as opposed to a dist-upgrade)
[07:08] <Saviq> duflu, so I think it's fine to do in devel
[07:09] <duflu> Saviq: OK, so long as you don't need a backported fix then it's just an ABI bump. If you do need a backported fix then I need to hunt down symbols and add them into 0.7
[07:09] <Saviq> duflu, no, is fine, it's a corner case, just wanted to make sure it gets addressed
[07:11] <duflu> Saviq: Also, we only introduce the reduced symbol map for each library once. Such bugs can't happen again
[07:11] <Saviq> duflu, kk
[07:11] <duflu> I'm not a fan of symbols.map, but trying to work with it
[07:30] <anpok_> i believe in qtmir we initialize an egl context with gles and only later switch to gl
[07:30] <anpok_> while in qtubuntu we initialize an egl context with eglBindAPI(EGL_OPENGL_API)
[07:31] <anpok_> (on desktop)
[07:32] <anpok_> the interesting part is that mesa on i915 (depending on the gpu) either exposes (es 2.0, GL 2.1) capability
[07:32] <anpok_> or (es 2.0, gl 1.4)
[07:33] <anpok_> and that is actually a workaround introduced for unity7 to make it not use certain effect on i915 systems..
[07:33] <anpok_> *effects
[07:37] <duflu> Sounds likely. I know Unity<=7 always had different code paths in Nux for i915
[07:40] <anpok_> duflu: did unity7 use occulusion query somewhere?
[07:40] <duflu> anpok_: What's that?
[07:41] <anpok_> with that you can query the amount of samples drawn from a primitive
[07:42] <duflu> No idea
[07:42] <anpok_> because thats used somewhere in the logic in mesa..
[07:42] <anpok_> to decide if it is 1.4 or 2.1
[07:43] <anpok_> maybe thats just an awkward check to differ between generations of the gpu and not related to usage..
[07:44] <anpok_> hm I think we could enable unity8 by adding a fallback .. trying to create an 1.4 context and checking that the vertex and fragment program extensions are there..
[07:46] <duflu> Well anything is better than trying to use LLVM on an i945 system :)
[07:46] <duflu> Except of course the third option (a black screen) we have right now
[07:46] <anpok_> well the i915 driver falls back to swrast
[07:46] <anpok_> to implement shaders..
[07:47] <anpok_> afaik
[07:47] <duflu> Yeah. And it works well, last I checked
[07:47] <duflu> Just not in Mir yet
[07:49] <anpok_> maybe my enthusiasm is slightly damped because I always used debuf versions of mesa
[07:49] <anpok_> s/f/g
[13:37] <anpok_> so if we bump mircommon we will run into the rpath linker issues again?
[19:35] <robotfuel> kgunn: ping, can you have someone look at this stacktrace on this crash and see if it's usable? https://bugs.launchpad.net/ubuntu/+source/qtdeclarative-opensource-src/+bug/1365673  maybe it's a client that can't connect? I didn't get video :(
[23:18] <racarr> ah...right...sbuild on armhf fails because of the explicit G++ dependency somehow
[23:19] <racarr> it seems like...
[23:19] <racarr> mir build dependecies pull in
[23:19] <racarr> g++4.9:armhf
[23:19] <racarr> but what the sbuild needs is a
[23:20] <racarr> x86 armhf crosscompiler right?not the armhf binary
[23:20] <racarr>  g++-4.9:armhf : Depends: gcc-4.9:armhf (= 4.9.1-10ubuntu2) but it is not going to be installed
[23:20] <racarr> E: Build-dependencies for sbuild-build-depends-mir-dummy could not be satisfied.
[23:20] <racarr> I wonder if I can do anything about it
[23:22] <racarr> all I see in
[23:22] <racarr> debian/control is g++-4.9...no architecture mention...
[23:23] <racarr> does anyone know someone to be particularly knowledgeable about cross compiling, e.g. maybe they have seen this sort of thing before
[23:26] <racarr> I wonder what other packages explicitly depend on a G++ version
[23:27] <racarr> https://wiki.debian.org/CrossToolchains suggests depending on g++-4.9-for-host
[23:29] <racarr> https://wiki.debian.org/CrossTranslatableBuildDeps
[23:29] <racarr> suggests something else...
[23:29] <racarr> *investigates revision dates*
[23:30] <racarr> oh I see the second one is a proposal
[23:43] <racarr> it kind of seems like its all proposals, aha
[23:52] <racarr> It looks like I could use build profiles but its not clear ubuntu has that?