[03:28] <duflu> camako: Welcome to... Sunday?
[03:29] <duflu> RAOF: Are we really waiting to upstream the latest Mesa patch before putting it in distro?
[03:35] <camako> thanks duflu...
[03:37] <camako> duflu, have you tried running the 0.7.0 silo on the desktop?
[03:39] <duflu> camako: No. Still doing the morning bug triage and refresh of code reviews... And will be into the afternoon
[03:39] <duflu> camako: Hey I notice butter made it in. That's exciting
[03:40] <camako> duflu, yes it did... I wanted to get the privatise-headers too, but not gonna happen in this release
[03:41] <duflu> camako: Well, it got bloated out as I caved into pressure to republish the headers used in examples.
[03:42] <duflu> There's very little risk to landing it though. I have been testing with qtmir and usc
[03:46] <camako> We already did a bunch of testing... finishing it up as we speak.. be greenlighting it unless I find smth majorly wrong
[03:46] <duflu> I was a bit disappointed to find examples/ increased the size of the public SDK so much. But it's given me ideas for slowly trimming it back into the future
[03:46] <duflu> It's just getting harder as time goes by... and complexity increases
[03:48] <duflu> I did spot one potential major chunk of work that might be dead code now. Not sure, will have to investigate
[03:51] <camako> yeah it'd be good to trim it down
[04:01] <RAOF> duflu: No? Why do you think that?
[04:02] <duflu> RAOF: Ah good. Anpok suggested that in a bug
[04:04] <RAOF> Ah.
[04:04] <RAOF> I *have* been somewhat remiss in reviewing and pushing that patch, though :)
[04:04] <duflu> RAOF: Or it seems I misunderstood: https://bugs.launchpad.net/mir/+bug/1275398
[04:04] <ubot5> Ubuntu bug 1275398 in mesa (Ubuntu) "i915 driver/i945 hardware: Mir GL clients are rendered as black or transparent windows when using i945 graphics" [High,In progress]
[04:22]  * RAOF is confused by helgrind reporting tons of ‘unlocked not-locked mutex’ errors in ~unique_lock on armhf. 
[04:52] <duflu> RAOF: It does seem valgrind's ARM support is a bit immature
[04:55] <RAOF> ‘==9897== Thread #38: Bug in libpthread: write lock granted on mutex/rwlock which is currently wr-held by a different thread’
[04:55] <RAOF> Yeah, this might be valgrind being terrible.
[04:57] <duflu> RAOF: Well valgrind is mostly good for armhf, except for the occasional unimplemented instruction. Seems the helgrind plugin needs some attention to be taught what the locking primitives are for ARM
[05:17] <camako> My N7 won't boot!
[05:35] <RAOF> Program received signal SIGILL, Illegal instruction.
[05:35] <RAOF> 0x0044a538 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string()@plt ()
[05:36] <RAOF> GrrrrrrrrrrrARGH.
[05:59] <duflu> RAOF: Oh valgrind+armhf? :)
[06:00] <RAOF> No; gdb + armhf.
[06:01] <RAOF> So, the thing I like most of all is having weird armhf failures because our test harness does something wrong in ways that are never tested on !android.
[06:59] <memeka> hi .... does Mir run on top of libhybris hwcomposer ?
[07:11] <duflu> memeka: Yes it does on Android
[07:12] <memeka> duflu: how about on Linux ?
[07:12] <duflu> memeka: Both are Linux :) On desktop it uses Mesa/DRM
[07:12] <memeka> duflu: can it work with this: https://github.com/mbrasser-jolla/qt5-qpa-hwcomposer-plugin ?
[07:15] <memeka> duflu: I have the min amount of android services working (pvrsrvkm for GPU, android-media-server and android-service-manager) and libhybris - test_hwcomposer works. sound and everything else is all linux non-android (ALSA/pulseaudio, etc...)
[07:15] <memeka> will Mir start on my system?
[07:17] <duflu> memeka: I don't think so. I'm no Android/HWC expert but the intention with Mir is to make Mir the layer between the tookit (Qt) and the hardware (via libhybris). So we don't actually expose HWC for anyone to use. You have to write for Mir
[07:17] <memeka> duflu: I could install qtwayland + the qpa-hwcomposer plugin and then run qml-compositor - under there start a nested weston instance, run qt5 apps etc
[07:18] <memeka> libhybris exposes several EGL_PLATFORM ... does Mir works with all of them
[07:18] <memeka> ?
[07:19] <duflu> memeka: I think you're asking deeper Android questions than I can answer. Maybe try kdub when he comes online.
[07:20] <memeka> duflu: thanks ... I am not sure what I am asking but the main idea is to see if I can run Mir :)
[07:20] <RAOF> You'll be using the qtmir plugin, anyway.
[07:20] <memeka> and Unity8
[07:20] <RAOF> (Qt5 platform plugin, that is)
[07:21] <RAOF> I _think_ the answer is “yes it should, modulo driver weirdness - and there's always driver weirdness” ☺
[07:22] <memeka> RAOF: so I can then install qtwayland + qt5-hwcomposer qpa + qtmir + mir + ... ?
[07:22] <anpok> -qtwayland -qt4-hwcomposer
[07:22] <anpok> then yes..
[07:22] <RAOF> Well, you wouldn't want qtwayland or qt5-hwcomposer.
[07:27] <memeka> RAOF: so, given a libhybris install, and test_hwcomposer running (and showing the pattern on the screen) ... what's next for me to get Mir displaying stuff on screen?
[07:27] <RAOF> memeka: What happens if you try running one of the demo servers? :)
[07:27] <memeka> I haven't any demo server ....
[07:28] <memeka> didn't know what to install :D
[07:28] <RAOF> You want a build of lp:mir/devel on there :)
[07:28] <RAOF> If you've got Ubuntu running then mir-test-tools and mir-demos are the relevant packages.
[07:30] <RAOF> Well, or you could just install the ubuntu-touch metapackage and see if unity8 just works :)
[07:30] <memeka> RAOF: can i just checkout http://bazaar.launchpad.net/~mir-team/mir/development-branch/files and do a dpkg-buildpackage -b ?
[07:30] <RAOF> Yup.
[07:31] <memeka> how old are the ubuntu-touch components in the utopic repo? should i just try that first ?
[07:32] <memeka> RAOF: also is there any X dependency? since X11 won't display anything on my system - since the GPU is android - libhybris ....
[07:32] <RAOF> No X dependency..
[07:33] <memeka> RAOF: oh, the ubuntu-touch meta is only in that ppa
[07:33] <RAOF> Well, no runtime dependency.
[07:34] <memeka> RAOF: still cannot find the ubuntu-touch metapackage ... where is it ?
[07:36] <RAOF> ubuntu-touch:
[07:36] <memeka> RAOF: also, do I need any xf86-video-xxx ? cause there isnt any for my GPU (I don't care about xmir)
[07:36] <RAOF>   Installed: (none)
[07:36] <RAOF>   Candidate: 1.181
[07:36] <RAOF>   Version table:
[07:36] <RAOF>      1.181 0
[07:36] <RAOF>         500 http://mirror.internode.on.net/pub/ubuntu/ubuntu/ utopic/universe amd64 Packages
[07:36] <RAOF>         500 http://archive.ubuntu.com/ubuntu/ utopic/universe amd64 Packages
[07:36] <RAOF> Nope, no X runtime dependencies.
[07:38] <memeka> thanks RAOF ... I will report back after I have finished trying :D
[07:40] <memeka> RAOF: there are no ARM packages. .. looks like i will have to build everything :D
[07:42] <RAOF> http://ports.ubuntu.com/dists/utopic/
[07:42] <RAOF>  http://ports.ubuntu.com/dists/utopic/
[07:42] <RAOF> memeka: You're looking for ports.ubuntu.com
[07:43] <RAOF> Hm. Laaaaaaag.
[07:43] <memeka> RAOF: awesome, thanks! (ther mirror did not have them but they are there)
[07:44] <memeka> cheers
=== _morphis is now known as morphis
[08:16] <RAOF> Woot! One branch (hopefully) fixed on CI!
[08:16] <RAOF> ...mutter mutter stupid android tests mutter mutter...
[08:21] <duflu> Oh fun. I'm getting conflicts from a non-existent file
[08:52] <duflu> Wow. Wacky bzr conflicts. This is very strange
=== chihchun is now known as chihchun_afk
=== ara is now known as Guest71689
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
=== dandrader is now known as dandrader|afk
=== yofel_ is now known as yofel
=== dandrader|afk is now known as dandrader
=== chihchun is now known as chihchun_afk
=== Trevinho_ is now known as Trevinho
=== dandrader is now known as dandrader|lunch
=== Wellark is now known as Wellark|holiday
=== Wellark|holiday is now known as Wellark
=== dandrader|lunch is now known as dandrader
[18:34] <camako> Mir 0.7.0 is now in the archive