[02:59] <RAOF> racarr: Just to be clear - you'd like https://code.launchpad.net/~rocket-scientists/mir/mesa-egl-platform-mir-native-display to land, yes?
[03:32] <RAOF> racarr: Ok, so where do I get mir_client_library_mesa_egl.h from?
[03:34] <duflu> RAOF: It used to be proposed here but has since vanished or been renamed... https://code.launchpad.net/~robertcarr/mir/prepare-for-inprocess-egl-clients/+merge/153889
[03:38] <RAOF> Ah, seems it got renamed to native_display.h
[03:39] <RAOF> Not a big fan of that header name.
[03:47] <thomi> kdub: hey, still around?
[04:44] <RAOF> racarr: Ok, so my hacks to make https://code.launchpad.net/~rocket-scientists/mir/mesa-egl-platform-mir-native-display buildable against lp:~robertcarr/mir/prepare-for-inprocess-egl-clients don't result in a working mesa.
[04:56] <bcbc2> Running mir ppa on Raring. When I add type=mir to lightdm.conf I get a terminal login. This is the lightdm.log: http://paste.ubuntu.com/5636106/ Any ideas? PS the mir_egltriangle runs correctly in the separate test
[04:59] <RAOF> bcbc2: XMir currently isn't in the PPA, so those steps won't work.
[05:00] <bcbc2> RAOF: ah ok. So I need to compile from source?
[05:00] <RAOF> bcbc2: XMir & the associated drivers will land after I've landed https://code.launchpad.net/~raof/mir/use-dma-buf/+merge/153267 and the associated changes.
[05:02] <RAOF> bcbc2: Yeah, you can build from source if you want; the necessary code is on github - https://github.com/RAOF/xserver and the associated driver from xf86-video-{ati,intel,nouveau}
[05:02] <RAOF> (Note, I don't think nouveau's currently working)
[05:02] <RAOF> bcbc2: It's pretty boring, too (as long as it works) - everything looks exactly like it currently does, with the exception that colour management doesn't work :)
[05:03] <bcbc2> RAOF: ok thanks. I'll probably wait a bit then. yeah it's boring IF it works ;)
[06:37] <duflu> mmrazik: Would it be possible to make Jenkins CI build Mir against clang?
[06:37] <duflu> Test cases don't work yet, and it requires a custom cmake command, but the static analysis is very useful
[06:38] <RAOF> Does input build yet?
[06:38] <mmrazik> duflu: sure. what is the cmake command?
[06:38] <duflu> RAOF: No. And not for the foreseeable future. There are "errors" in code we have to keep :P
[06:38] <RAOF> Boo.
[06:38] <duflu> mmrazik: https://code.launchpad.net/~vanvugt/mir/clang/+merge/153984
[06:39] <duflu> RAOF: But there's a chance the offending code can be worked around by moving pieces. Have not looked in detail
[06:40] <mmrazik> duflu: does the build fail with those commands? I see input is disabled but what about the tests?
[06:40] <duflu> mmrazik: Yeah tests fail. We expect that into the near future at least. Just testing it builds with clang is enough
[06:41] <mmrazik> duflu: oh.. they fail during execution, not during compile?
[06:41] <duflu> mmrazik: Yeah execution fails. It all builds (without input)
[06:42] <mmrazik> ok
[06:57] <tvoss> duflu, RAOF is the clang build step optional for CI then?
[06:58] <duflu> tvoss: It's non-existent right now. But I think it should be compulsory due to the high value of its static analysis
[06:58] <duflu> And we pass the clang test now. So nothing to be fixed
[06:58] <tvoss> duflu, for the static analysis: I do agree, but: we need gcc, too, especially to be able to execute the tests, right?
[06:59] <duflu> tvoss: Of course. gcc still builds and runs tests
[06:59] <tvoss> duflu, okay, then I'm fine
[06:59] <duflu> Hah. No I'm not suggesting drop tests from CI :)
[07:01] <tvoss> duflu, just tried to clarify on the backlog :)
[07:02] <duflu> Man, even when I was reviewing hundreds of bugs per day, I never tried keeping up with IRC backlogs...
[07:03] <tvoss> duflu, I sometimes do :)
[07:07] <RAOF> For high-value channels, sometimes.
[07:08] <duflu> RAOF: They exist?
[07:08] <RAOF> Heh.
[07:08]  * duflu -> coffee
[07:09] <RAOF> Channels like #debian-x and #debian-cli are quite low traffic, so they have a signal/noise that makes backscroll sometimes a worthwhile investment.
[07:15] <tvoss> tvoss -> coffee
=== mmrazik is now known as mmrazik|afl
=== mmrazik|afl is now known as mmrazik|afk
[07:16] <RAOF> Let's see if this mesa lets me use lp:~raof/mir/use-dma-buf
[07:26] <Cheery> has anything new happened recently?
[07:27] <duflu> Cheery: New code is landing in Mir every day. But I don't think any of the recent changes are interesting to users (yet)
[07:27] <Cheery> anything new about nvidia drivers?
[07:30] <Cheery> apparently.. no
[07:32] <tvoss> Cheery, I think the easiest way to stay up to date is to subscribe to the mir mailing list (see https://wiki.ubuntu.com/Mir)
[07:40] <alf_> tvoss: pong
[07:43] <RAOF> Cheery: I wouldn't hold my breath for news on the nvidia front; my guess is that it'll be a while before we('re allowed to ☺) have anything interesting to reveal.
=== mmrazik|afk is now known as mmrazik
=== alan_g is now known as alan_g|afk
=== alan_g|afk is now known as alan_g
[09:11] <alan_g> alf_: tvoss: Another day without progress on "Include directory structure, and installation packages" :(
[09:47] <duflu> Awesome. I now realise the past few hours work needs to be partially redesigned from scratch. And 13 minutes to weekend.
[09:48] <alan_g> duflu: I hear your pain
[09:54] <duflu> Oh dear. Over-stimulation and too many ideas for a Friday evening. Better go open some wine and make dinner.
[10:12] <smspillaz> mmm wine
[10:24] <alan_g> alf_: got time for a review? https://code.launchpad.net/~robertcarr/mir/send-input-to-clients/+merge/154221
[10:25] <alf_> alan_g: I thought I had already reviewed that, but it turned out I forgot to actually press the button :)
[10:25] <alan_g> LOL
[10:26] <alan_g> Good job I reminded you
[10:27] <alf_> alan_g: The poor review... it was patiently waiting for me in a forgotten browser tab :)
[10:27] <alf_> alan_g: you saved it from it's pain
[10:27] <alf_> alan_g: s/it's/its/
[10:30] <alan_g> alf_: I'm going to fix lp:~robertcarr/mir/prepare-for-inprocess-egl-clients in a trivially different branch so we might get it landed too
[10:31] <alf_> alan_g: ok
[10:45] <alan_g> alf_: https://code.launchpad.net/~alan-griffiths/mir/prepare-for-inprocess-egl-clients/+merge/154909
=== mmrazik is now known as mmrazik|lunch
[11:29] <alan_g> alf_: does this look like the bug you were fixing? Or is it a new problem?
[11:29] <alan_g> https://jenkins.qa.ubuntu.com/job/mir-quantal-amd64-ci/173/console
[11:33] <alf_> alan_g: It's in the same code, but I don't think it's related. It seems similar to the one we are getting in VM builds (some client/server process synchronization issue).
[11:35] <alan_g> alf_: thanks, for looking
[11:41] <alf_> alan_g: aha, I have managed to recreate it locally at last! I had to sufficiently overload/slow down my computer to recreate it...
[11:42] <alf_> alan_g: well, at least I have recreate some problem, hopefully the same as the one we are seeing
[11:42] <alan_g> alf_: Does that mean I can leave it to you?
[11:42] <alan_g> At least for now
[11:42] <alf_> alan_g: sure, I will try to take a look today
[11:45] <alf_> alan_g: is this problem happening consistently or sporadically for normal (non-VM) CI (i.e. is it blocking our CI)?
[11:46] <alan_g> alf_: I've only seen this instance
[11:46] <alan_g> I'll set it approved again and see what happens
[11:47] <alf_> alan_g: ok, if it proves to be a blocker, I will take a look now
=== mmrazik|lunch is now known as mmrazik
[12:21] <alan_g> alf_: Looks like it is an intermittent problem. The worst ones to prove are fix. :(
[12:22] <alan_g> *fixed
=== kgunnAFK is now known as kgunn
[13:46] <alan_g> mmrazik: do you know what caused this? https://jenkins.qa.ubuntu.com/job/mir-android-raring-i386-build/95/console
[13:48] <mmrazik> alan_g: looking...
[13:49] <alan_g> alf_: are you happy with this? https://code.launchpad.net/~kdub/mir/android-display-factory/+merge/153907
[13:52] <alf_> alan_g: checking
[13:54] <mmrazik> alan_g: I think it was a network error. Let me retry
[13:54] <mmrazik> bzr error messages are not particularly helpful :-/
[13:54] <alan_g> mmrazik: I'd be happy to switch to git
[14:00] <mmrazik> alan_g: seems to be reproducable. I have a call now but will check afterwards
[14:01] <alan_g> mmrazik: thanks
[14:04] <mmrazik> alan_g: oh.. its because the branch is private
[14:04] <alan_g> mmrazik: oops
[14:06] <alan_g> mmrazik: Do I need to create a new branch?
=== mmrazik is now known as mmrazik|otp
[14:21] <alf_> alan_g: reviewed ("needs fixing")
[14:22] <alan_g> alf_: ta
=== mmrazik|otp is now known as mmrazik
[14:25] <mmrazik> alan_g: I made it public
[14:26] <mmrazik> let me re-run the job
[14:26] <alan_g> mmrazik: thanks
[14:36] <alf_> alan_g: @CI error, I don't see anything suspicious, it's probably just the server being late. We should increase the wait time to a sufficiently large value, e.g., 10 seconds, and see if it helps. The VM builds are consistently failing, so, if this works, we will get an indication that we are solving the right problem.
[14:37] <alan_g> alf_: ok
[15:15] <kdub> good morning
[15:21] <kdub> hey mmrazik, for the android ci builds, could we add the phablet-team's armhf ppa (with libhybris packages) to the jenkins pbuilder setup?
[15:21] <kdub> it will help with this failure https://code.launchpad.net/~mir-team/mir/consolidate-crossbuild-scripts/+merge/154762
[15:21] <mmrazik> kdub: sure. ppa:phablet-team/ppa ?
[15:22] <kdub> yep, thats the one
[15:25] <mmrazik> kdub: done + I queued a rebuild
[15:25] <kdub> thanks mmrazik
[15:25] <mmrazik> btw. there is a clang build enabled in addition
[15:30] <alan_g> are we supporting clang?
[15:35] <mmrazik> alan_g: is the question "do we care about clang errors" or "can we compile lp:mir with clang"?
[15:35] <mmrazik> the later is true
[15:35] <mmrazik> duflu asked me to have clang job in jenkins earlier today
[15:36] <mmrazik> this is what the jenkins job is doing: cmake .. -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DMIR_DISABLE_INPUT=ON
[15:36] <alan_g> mmrazik: the question is "does spending time on clang help deliver what we promised"
[15:36] <mmrazik> right
[15:36] <mmrazik> alan_g: can't answer
[15:37] <mmrazik> shall I drop an e-mail to mir-devel ?
[15:38] <mmrazik> I thought you guys care given you approved the MP
[15:41] <alan_g> AFAIK clang isn't a supported platform (just a nice to have).
[15:44] <kdub> alan_g, +1
[15:44] <kdub> alf_, re-review of android-display-factory? :)
[15:44] <alf_> kdub: on it
[15:47] <mmrazik> kdub, alan_g: so you are -1 on clang blocking the ci/autolanding
[15:48] <mmrazik> what if I keep it for ci and remove for autolanding? I.e. you will be able to merge code even if clang fails
[15:48] <alan_g> mmrazik: yep
[15:49] <kdub> mmrazik, yes, at least until we figure get our gcc arm compiles to a nice point
[15:50] <mmrazik> so should I remove clang completely?
[15:50] <alan_g> mmrazik: g++ arm is a supported platform
[15:50] <mmrazik> shall I translate g++ arm as building natively on arm (like we do in ppa)?
[15:51] <alan_g> mmrazik: clang shouldn't distract you or us from what we are trying to deliver
[15:51]  * mmrazik is removing the clang job
[16:02] <mmrazik> kdub: your branch compiles on android again
[16:02] <kdub> i just saw, thanks mmrazik
=== mmrazik is now known as mmrazik|afk
=== rafalm_ is now known as rafalm
[16:13] <alan_g> kgunn: hangout to find a way forward on the include directories question: https://plus.google.com/hangouts/_/fa5325fabc3ebf8c432cbc427c9f78b02e2a6806b8?authuser=0&hl=en-GB (alf_ kdub racarr - you're welcome to join in)
[16:13] <kgunn> thanks alan_g !!
[16:14] <kgunn> alf_: racarr kdub ^ if you want to join
[16:14] <alf_> kgunn: thanks, coming
[16:31] <racarr> morning
[16:33] <alan_g> racarr: ^^
[16:33] <racarr> still going on?
[16:34] <alan_g> ack
[16:35] <racarr> ok just a sec
[16:37] <alf_> kgunn: http://www.timeanddate.com/worldclock/meeting.html
[16:52] <racarr> merged trunk on send-input-to-clients :)
[16:53] <alan_g> racarr: looking
[17:28] <racarr> alan_g: Have you seen anything in andoid with
[17:29] <racarr> Compat.h and redefinition of lseek64 and _FILE_OFFSET_BITS < 64?
[17:29] <racarr> It happens when trying to include the fake_event_hub in my new acceptance test
[17:29] <racarr> am guessing it only works in other places because of some header included previously
[17:29] <racarr> or some such
=== yofel_ is now known as yofel
[17:30] <alan_g> racarr: it isn't something I remember (but why would I try)
[17:30] <alan_g> I usually stuff #error in the offending header to get an include backtrace
[17:30] <racarr> No idea, just not sure if you had seen it come up in the process of refactoring :)
[17:30] <racarr> mm
[17:31] <racarr> its like AndroidConfig.h isnt being included
[17:32] <racarr> ah
[17:32] <racarr> I did not know about the uses_android_input macro
[17:32] <racarr> in CMake
[17:40] <alan_g> alf_: re earlier discussion about separating run_mir () for reuse - it is done in https://code.launchpad.net/~mir-team/mir/misc-code-cleanup/+merge/155018
[17:42] <alan_g> racarr: "Fixed the comments" - did you push the changes?
[17:44] <racarr> apparently now!
[17:44] <racarr> not
[17:44] <racarr> it looks like I did now :)
[17:44] <racarr> alan_g: ^
[17:44] <alan_g> racarr: I didn't want to set "Approved" and then have you remember. ;)
[17:45] <racarr> thanks :)
=== alan_g is now known as alan_g|eow
=== kgunn is now known as kgunnAFK
[19:15] <_NerdyMe_> hey guys is there a chance for a question about a possible use case about MIR which (if technically possible) would save compositing overhead...
[19:20] <_NerdyMe_> the idea is (as it is server allocation) for the case of a cell phone: apps normally run maximised. so they use the whole screen except the top panel. the compositor has a buffer which includes the "whole" screen and when the client asks for the buffer in a state that it has the focus then you pass a reference to a subset of that very same compositor buffer. so that way you never have to copy anything around etc.... and when you bring in the launche
[19:20] <_NerdyMe_> r it will render directly over that very same buffer... is that possible?
=== mhall119_ is now known as mhall
=== kgunnAFK is now known as kgunn
[19:41] <kgunn> _NerdyMe_: yes
[19:42] <kgunn> _NerdyMe_: this is what is known as "bypass composition" in the mobile industry
[19:43] <kgunn> _NerdyMe_: it should be "for free", this kind of logic....along with some other goodies
[19:43] <kgunn> _NerdyMe_: is supported by hw vendors in hwc hal
[19:43] <kgunn> _NerdyMe_: and on gpu fallback path....its fairly simple logic
[19:44] <kgunn> _NerdyMe_: all in all....yes....its something we know we'll do
[19:44] <kgunn> _NerdyMe_: support
[19:44] <_NerdyMe_> kgunn: thank you. the thing is I have no clue how that buffering stuff actually works, just had my thought on it. that makes feel good, like even I could make my own display server hahaha let's call it ISS. great, thx for the info. wish you all good luck!
[19:45] <kgunn> _NerdyMe_: ISS...good one
[19:47] <kgunn> racarr: hey, where do i look for test output (like aggregate run rate/pass rate stuff) ?
[19:47] <kgunn> racarr: as well, tested code coverage data
[19:50] <racarr> kgunn: I am trying to find where it went since jenkins moved around
[19:50] <kgunn> racarr: thanks for the help
[22:32] <racarr> Anyone around?
[22:32] <racarr> Trying to figure out how to test the input receiver polling logic...
[22:34] <sturmflut> I tried to write my own Mir client but the include files in the current PPA packages seem to be borked. I #include <mir/client/mir_toolkit/mir_client_library.h> but it tries to #include "mir_toolkit/c_types.h" and there is no mir_toolkit/c_types.h in the default path
[22:37] <racarr> sturmflut: I guess there is something wrong with the pkgconfig...will make a note. for now -I/usr/include/mir (you should have mir_toolkit/c_types.h in there) should do it
[22:37] <racarr> though...um...if c_types.h landed that means a branch landed that wasn't supposed to land yet
[22:38] <racarr> and mesa will be out of sync and not working ;)
[22:39] <racarr> kdub: Ping?
[22:39] <kdub> pong
[22:42] <kdub> racarr^^
[22:42] <racarr> kdub: Prepare-for-inprocess-egl landed accidentally
[22:42] <racarr> so I guess things will be broken
[22:42] <racarr> because i havent pushed the mesa changes
[22:42] <racarr> trying to figure out what to do...
[22:44] <kdub> racarr, broken how?
[22:47] <kdub> racarr, android seems ok
[22:48] <racarr> kdub: Will be broken on mesa...well
[22:48] <racarr> I guess you can just pass the MirConnection as the EGLNativeDisplayType
[22:48] <racarr> and nit will work
[22:48] <racarr> but mir_connection_get_egl_native_display
[22:48] <racarr> will return the
[22:48] <racarr> new struct that mesa cant handle yet
[22:48] <racarr> I guess mir_connection_is_valid (called by old mesa)
[22:48] <racarr> will then return 0 and it will just fail
[22:51] <kdub> well, if there's a quick fix, let's mp it.... if not backing out the change seems like the way to go
[22:55] <RAOF> racarr: And I couldn't get your mesa changes to work :)
[22:57] <sturmflut> Anyone working in a Mir backend for SDL? Being able to run games on Mir would be awesome
[23:01] <tehcloud> sturmflut, have you run ANYTHING on Mir yet?
[23:02] <sturmflut> tehcloud: The demo clients from the repository, yes
[23:02] <tehcloud> I suspect the Mir devs are focussing on getting it on par at least with Wayland, before committing resources to SDL
[23:03] <tehcloud> and I think the SDL devs are not working on it either, since they are trying to release 2.0
[23:04] <racarr> sturmflut: Afaik no one has touched SDL yet :)
[23:04] <racarr> RAOF: Oh you are here.
[23:05] <racarr> Hmm. I am kind of engrossed in input but should fix this.
[23:05] <racarr> so if you have time to review something in 30 minutes or so I could make an updated patch
[23:05] <RAOF> racarr: Because, during my morning walk with Zoë, I realised why my mesa changes to support use-dma-buf only half worked :)
[23:05] <racarr> where did mesa repo move since everything went public?
[23:05] <RAOF> github
[23:05] <racarr> RAOF: Aha. The mesa mind virus
[23:05] <RAOF> racarr: Enjoy.
[23:05] <RAOF> racarr: https://github.com/RAOF/mesa
[23:07] <racarr> RAOF: Ok between checking out and building a fresh copy and all will take a while
[23:07] <racarr> but will get back to you soon
[23:47] <RAOF> racarr: Question re: mir_connection_is_valid and your native_display patch - couldn't you just pass a MirConnection in to mesa and have mesa pull the native display out of that? Then you could keep using mir_connection_is_valid.
[23:49] <RAOF> There are two hard problems in computing: cache invalidation, naming things, and off-by-one errors.
[23:49] <RAOF> Mesa was a cache invalidation problem :)
[23:50] <racarr> RAOF: http://paste.ubuntu.com/5638637/ should work
[23:50] <racarr> but there is a little cleanup to be done perhaps
[23:51] <racarr> RAOF: Can't pass a MirConnection as the
[23:51] <racarr> display type because there is no
[23:51] <racarr> MirConnection ont he server side