=== chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [03:43] RAOF, anyone: Please review this ASAP: https://code.launchpad.net/~mir-team/mir/fix-1364772/+merge/233298 [06:22] Hm. Why doesn't this work? [06:22] ...checks... [06:22] return std::shared_ptr{}; [06:22] Oh. Yeah. Need to actually implement that :) [06:23] RAOF: Trivial needs fixing ... then we can land it: https://code.launchpad.net/~raof/mir/from-the-neglected-branches-files/+merge/233150 [06:26] Ta, done. [07:07] 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] Because the latter can't be backported to 0.7 [07:08] 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] duflu, so I think it's fine to do in devel [07:09] 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] duflu, no, is fine, it's a corner case, just wanted to make sure it gets addressed === tvoss is now known as tvoss|test === tvoss|test is now known as tvoss [07:11] Saviq: Also, we only introduce the reduced symbol map for each library once. Such bugs can't happen again [07:11] duflu, kk [07:11] I'm not a fan of symbols.map, but trying to work with it [07:30] i believe in qtmir we initialize an egl context with gles and only later switch to gl [07:30] while in qtubuntu we initialize an egl context with eglBindAPI(EGL_OPENGL_API) [07:31] (on desktop) [07:32] the interesting part is that mesa on i915 (depending on the gpu) either exposes (es 2.0, GL 2.1) capability [07:32] or (es 2.0, gl 1.4) [07:33] and that is actually a workaround introduced for unity7 to make it not use certain effect on i915 systems.. [07:33] *effects [07:37] Sounds likely. I know Unity<=7 always had different code paths in Nux for i915 [07:40] duflu: did unity7 use occulusion query somewhere? [07:40] anpok_: What's that? [07:41] with that you can query the amount of samples drawn from a primitive [07:42] No idea [07:42] because thats used somewhere in the logic in mesa.. [07:42] to decide if it is 1.4 or 2.1 [07:43] maybe thats just an awkward check to differ between generations of the gpu and not related to usage.. [07:44] 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] Well anything is better than trying to use LLVM on an i945 system :) [07:46] Except of course the third option (a black screen) we have right now [07:46] well the i915 driver falls back to swrast [07:46] to implement shaders.. [07:47] afaik [07:47] Yeah. And it works well, last I checked [07:47] Just not in Mir yet [07:49] maybe my enthusiasm is slightly damped because I always used debuf versions of mesa [07:49] s/f/g === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader === om26er_ is now known as om26er === zoktar_ is now known as zoktar === infernixx is now known as infernix === ubot5` is now known as ubot5 === om26er is now known as om26er|afk [13:37] so if we bump mircommon we will run into the rpath linker issues again? === dandrader is now known as dandrader|afk === om26er|afk is now known as om26er === dandrader|afk is now known as dandrader === Kaleo_ is now known as Kaleo === om26er_ is now known as om26er [19:35] 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 :( [19:35] Ubuntu bug 1365673 in qtdeclarative-opensource-src (Ubuntu) "/usr/lib/arm-linux-gnueabihf/qt5/bin/qmlscene:6:qt_message_fatal:QMessageLogger::fatal:UbuntuClientIntegration::UbuntuClientIntegration:UbuntuMirClientIntegrationPlugin::create:loadIntegration" [Undecided,New] === nomu is now known as Nothing_Much [23:18] ah...right...sbuild on armhf fails because of the explicit G++ dependency somehow [23:19] it seems like... [23:19] mir build dependecies pull in [23:19] g++4.9:armhf [23:19] but what the sbuild needs is a [23:20] x86 armhf crosscompiler right?not the armhf binary [23:20] g++-4.9:armhf : Depends: gcc-4.9:armhf (= 4.9.1-10ubuntu2) but it is not going to be installed [23:20] E: Build-dependencies for sbuild-build-depends-mir-dummy could not be satisfied. [23:20] I wonder if I can do anything about it [23:22] all I see in [23:22] debian/control is g++-4.9...no architecture mention... [23:23] does anyone know someone to be particularly knowledgeable about cross compiling, e.g. maybe they have seen this sort of thing before [23:26] I wonder what other packages explicitly depend on a G++ version [23:27] https://wiki.debian.org/CrossToolchains suggests depending on g++-4.9-for-host [23:29] https://wiki.debian.org/CrossTranslatableBuildDeps [23:29] suggests something else... [23:29] *investigates revision dates* [23:30] oh I see the second one is a proposal [23:43] it kind of seems like its all proposals, aha [23:52] It looks like I could use build profiles but its not clear ubuntu has that?