=== chihchun_afk is now known as chihchun | ||
=== chihchun is now known as chihchun_afk | ||
duflu | RAOF, anyone: Please review this ASAP: https://code.launchpad.net/~mir-team/mir/fix-1364772/+merge/233298 | 03:43 |
---|---|---|
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:22 |
duflu | RAOF: Trivial needs fixing ... then we can land it: https://code.launchpad.net/~raof/mir/from-the-neglected-branches-files/+merge/233150 | 06:23 |
RAOF | Ta, done. | 06:26 |
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:07 |
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:08 |
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:09 |
=== tvoss is now known as tvoss|test | ||
=== tvoss|test is now known as tvoss | ||
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:11 |
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:30 |
anpok_ | (on desktop) | 07:31 |
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:32 |
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:33 |
duflu | Sounds likely. I know Unity<=7 always had different code paths in Nux for i915 | 07:37 |
anpok_ | duflu: did unity7 use occulusion query somewhere? | 07:40 |
duflu | anpok_: What's that? | 07:40 |
anpok_ | with that you can query the amount of samples drawn from a primitive | 07:41 |
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:42 |
anpok_ | maybe thats just an awkward check to differ between generations of the gpu and not related to usage.. | 07:43 |
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:44 |
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:46 |
anpok_ | afaik | 07:47 |
duflu | Yeah. And it works well, last I checked | 07:47 |
duflu | Just not in Mir yet | 07:47 |
anpok_ | maybe my enthusiasm is slightly damped because I always used debuf versions of mesa | 07:49 |
anpok_ | s/f/g | 07:49 |
=== 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 | ||
anpok_ | so if we bump mircommon we will run into the rpath linker issues again? | 13:37 |
=== 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 | ||
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 :( | 19:35 |
ubot5 | 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] | 19:35 |
=== nomu is now known as Nothing_Much | ||
racarr | ah...right...sbuild on armhf fails because of the explicit G++ dependency somehow | 23:18 |
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:19 |
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:20 |
racarr | all I see in | 23:22 |
racarr | debian/control is g++-4.9...no architecture mention... | 23:22 |
racarr | does anyone know someone to be particularly knowledgeable about cross compiling, e.g. maybe they have seen this sort of thing before | 23:23 |
racarr | I wonder what other packages explicitly depend on a G++ version | 23:26 |
racarr | https://wiki.debian.org/CrossToolchains suggests depending on g++-4.9-for-host | 23:27 |
racarr | https://wiki.debian.org/CrossTranslatableBuildDeps | 23:29 |
racarr | suggests something else... | 23:29 |
racarr | *investigates revision dates* | 23:29 |
racarr | oh I see the second one is a proposal | 23:30 |
racarr | it kind of seems like its all proposals, aha | 23:43 |
racarr | It looks like I could use build profiles but its not clear ubuntu has that? | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!