RAOFClang once again to the rescue, with error messages that are (a) readable on a 1366x768 screen and (b) actually tell you what the error is.01:02
dufluRAOF: Any idea why we have all-the-X-things in staging now? Looks crowded... https://launchpad.net/~mir-team/+archive/staging02:03
RAOFduflu: Because we're about to go through the Xserver 1.14 transition, so I pushed that through staging first.02:06
RAOFAnd you can't just upload the server + any drivers with XMir changes, because the server ABI changed; you need the full enchilada.02:06
RAOFDear filesystem: why is that file 0 bytes?02:08
dufluRAOF: New laptop yet?02:14
RAOFNope. Should be shipping soon.02:14
=== duflu_ is now known as duflu
duflurobert_ancell: Can you add this to 0.0.6? https://bugs.launchpad.net/mir/+bug/113055303:24
ubot5Ubuntu bug 1130553 in Mir "Mir does not support eglSwapInterval(0)" [Medium,Fix released]03:24
robert_ancellduflu, done03:25
=== jono is now known as Guest27980
tvossgood morning :)05:06
dufluMorning tvoss05:33
tvossduflu, hey :) how goes?05:34
duflutvoss: Monday afternoon and still waking up. You?05:34
tvossduflu, Monday morning, mostly awake :)05:34
tvossalthough my caffeine level could be higher05:35
dufluIt could always be higher...05:37
dufluTo about 100 cups a day, which I believe is the lethal dose05:37
didrockstvoss: hey06:25
didrockshow are you?06:26
tvossdidrocks, hey :) quite good, summer here in Germany. How about you?06:26
didrockstvoss: same here, and seems the week will stay on that note ;)06:26
tvossdidrocks, hopefully :) So for Unity and Nux: I will push out those branches shortly06:27
didrockssummer finally \o/ (before apparently not so splending end of July and bad August)06:27
didrockstvoss: excellent, you answered before even I asked! :p06:27
tvossdidrocks, sure :)06:27
didrockstvoss: do you still have my branch somewhere?06:27
tvossdidrocks, let me find it :)06:27
didrocksshould be https://code.launchpad.net/~didrocks/unity/new-gmock06:28
tvossdidrocks, mind pinging me the gmock package location again? would like to check in a chroot06:32
* duflu wonders who "Ken" is06:32
didrocksduflu: kenvandine?06:35
didrocksor kevin duboi?06:35
dufludidrocks: Kidding. I think your meant Kevin... https://code.launchpad.net/~didrocks/mir/use-system-googlemock/+merge/17300806:35
didrocksah Kevin ;)06:36
dufluI think I meant "you", not "your"06:36
didrocksduflu: more than possible, it's coffee-1 here (speaking of which…) ;)06:36
didrockstvoss: https://code.launchpad.net/~didrocks/location-service/devsuggestsdoc/+merge/17313606:37
didrockstvoss: btw, you did approve it, but not globally approve?06:37
tvossdidrocks, done06:37
didrockstvoss: thanks06:37
didrockslet me look for the location service gmock branch06:38
didrockstvoss: https://code.launchpad.net/~didrocks/location-service/build-with-system-gmock06:38
tvossdidrocks, did you see my question for the new gmock package?06:38
tvossdidrocks, wanna propose that location-service branch?06:39
didrockstvoss: we need to upload the gmock package first to distro, but sure, can propose06:40
didrockstvoss: ppa:didrocks/ppa for the gmock package06:40
tvossdidrocks, approved but no top-approve yet06:48
didrockstvoss: perfect, thanks!06:49
duflualf___, hello... ?07:05
alf___duflu: hi!07:06
duflualf___: compositor_buffer(), is that actually latest_complete_buffer() ?07:07
dholbachgood morning07:09
dufluMorning dholbach07:11
dholbachhi duflu07:11
alf___duflu: it's the next buffer to be consumed by the compositor, it may be the latest submitted clien buffer or not (e.g. if the client has submitted two unprocessed buffers it's not the latest)07:11
duflualf___, cool. But it is "complete" either way07:11
alf___duflu: what does complete mean?07:12
duflualf___, I mean the client has finished rendering to it07:12
alf___duflu: yes07:12
alf___duflu: @different-mesa-display-validation-functions, how about mir_server_mesa_egl_display_is_valid(), mir_toolkit_mesa_egl_display_is_valid()?07:15
duflualf___, Argh. I think I prefer "server". We have outstanding tasks/arguments against "toolkit"07:15
alf___duflu: mir_server_mesa_egl_display_is_valid(), mir_client_mesa_egl_display_is_valid() ?07:16
duflualf___, I don't think my review was blocking really07:16
duflualf___, Yup sounds better. I wonder if we're still inconsistent omitting "native". Bu that makes it longer07:17
dufluThat reminds me. I meant to add a typedef for mir_bool to improve the client API readability07:18
alf__duflu: mir_server_mesa_egl_native_display_is_valid(), mir_client_mesa_egl_native_display_is_valid(): perphaps they are not too bad considering only mesa (through dlsym) and a couple of tests will use them.07:33
duflualf__: Yeah I'm undecided about "native". It's more consistent but makes it marginally too long. Abstain.07:34
alf___duflu: (flaky connection may have lost messages) mir_server_mesa_egl_native_display_is_valid(), mir_client_mesa_egl_native_display_is_valid(): perphaps they are not too bad considering only mesa (through dlsym) and a couple of tests will use them.07:48
duflualf___: Yeah I'm undecided about "native". It's more consistent but makes it marginally too long. Abstain.07:49
duflualf___: I will use MPs/email for you from now on :)07:49
=== JoseAntonioR is now known as JoseeAntonioR
greybackalf___: duflu: hi guys, either of you have good understanding of the input stack?08:04
duflugreyback: I have some experience from the client POV08:04
greybackduflu: it's more the server POV I'm asking from. But maybe you'll have an idea08:04
greybackShell is a surface that will always be "on top". I also need shell to receive all input events, even with another surface has focus08:06
greybackso in my shell mir configuration, I can add a EventFilter to the chain of eventFilters - which is the solution I believe08:07
duflugreyback: Yeah InputFilters are meant to do that. But I'm not saying the design is perfect yet. Perhaps we need to marry InputFilters with a particular surface, sometimes08:07
greybackbut what I need to be able to do is pass those Events to the shell input handler itself08:07
duflugreyback: The one from mir_surface_set_event_handler ?08:08
greybackduflu: yep08:08
duflugreyback: We could do that. We already merge multiple event sources into that behind the scenes in libmirclient08:09
duflugreyback: Not sure about specifics. Can you log an enhancement for racarr to look at too?08:09
greybackduflu: will do08:09
dufluNo problems08:09
duflugreyback: So that means you're linking libmirclient and libmirserver?08:10
greybackduflu: no I'm not08:10
greybackit's something I need to do from the server side08:11
greybackduflu: quick terminology check: EventFilter handles events, returns true if accepted, false if not. EventSink similar but always returns true?08:11
greybacki.e. doesn't allow events to propagate08:12
duflugreyback: Argh. I wrote EventSink and don't remember08:12
* duflu checks08:12
duflugreyback: EventSink is unconditional (returns void)08:13
dufluSo that's kind of like true (handled) and false (continue to next sink)08:14
greybackduflu: ok, that's how I expected it.08:14
dufluAlthough AFAIK, we don't yet have chains of EventSinks. It's only ever 1:108:14
greybackthat's ok08:15
greybackreally my issue is, how to get the EventFilter associated with a Surface08:16
duflugreyback: Yeah it's a good question. But there might be architectural considerations racarr can think of before we dive in08:18
tvossgreyback, what are you trying to solve?08:18
greybackduflu: indeed. I'll get his advice08:19
duflugreyback: Actually I had thought of it already, and started. Some events already contain surface IDs. We need more of them to (input events too)08:19
greybacktvoss: the shell surface will always be on top of the application surfaces. I need also that the shell surface receives all events, even if application surfaces have focus.08:20
dufluSo we need a mir_surface_post_event(event_caught_by_my_filter)08:20
tvossgreyback, hmmm, I would propose an event filter implementation that "knows" about the shell surface08:20
greybacktvoss: sounds right, yes08:21
greybackbut the part I'm unable to solve is how to know get the event filter of the shell surface08:21
duflugreyback: How about just letting the filter "requeue" it conditionally and the event trickles down to the surface per usual?08:21
greybackduflu: that could work...08:22
duflugreyback: We should have it already. If filter returns false I would have thought it should go on to the surface... ?08:22
dufluOtherwise, what's the point in returning that bool?08:23
greybackduflu: true. I can't see why it wouldn't. I'll give it a go08:23
duflugreyback: Sounds vaguely like some input bugs I've encountered. So maybe it's just a little broken. But I think it is meant to work like that in theory08:24
dufluOf course, a filter can handle an event and still return false to send it on to the surface too.08:25
greybackduflu: ah there will be times when shell should accept the event, so application doesn't get it08:25
duflugreyback: Yes just return true in that case08:25
dufluOh, I forgot. You need the surface handle still08:26
duflugreyback: So all you want to know is what was the surface that "would have" received the event, had it not been caught in the filter?08:28
dufluOf course, this is why XEvent has the window field :)08:29
greybackduflu: with my current understanding: I want a pointer to the event filter for surface x08:29
greybackbecause I think it makes most sense for me to grab the event filter of the shell, and push it to the start of the EventFilterChain. As is done in demo-shell08:30
tvossgreyback, +108:31
tvossduflu, I think we can save the hassle of hit testing if greyback's filter implementation knows the shell surface and just passes on the event08:32
duflutvoss: Yeah there might be a use case for redirection in future anyway. In which case we just want a send_event(event, surface)08:32
dufluAlthough it would be nice if input events told you the target surface ID too08:33
tvossduflu, later down in the filter chain: yes, definitely.08:33
tvossdidrocks, down to one issue with mismatch between header files and library linked in for unity08:43
didrockstvoss: phew, nice work! It seems they changed the API quite extensively (but not surprising in 2 years)08:44
tvossdidrocks, oh, it's more or less subtle: testing::internal::String is now std::string and the linker gets confused08:44
didrockstvoss: am I the only one to think there are too many internal replications of std types in unity btw?08:45
tvossdidrocks, not sure what you are referring to08:46
didrockstvoss: the glib::string types and all those kinds of mapper08:47
tvossdidrocks, oh yeah, that's ugly, but still: I don't think we should touch that code until absolutely necessary08:47
didrockstvoss: agreed, that's why I wasn't sure the mismatch with latest gmock was due to something like that, I didn't take time to look at it closely TBH08:47
tvossdidrocks, different question: assume that I would like to install test executables. Where would be the most appropriate place to put them?08:56
didrockstvoss: I think we would create a binary -tests package08:57
didrockstvoss: not sure what's the point for non integration tests though08:57
tvossdidrocks, basic smoke testing could benefit from being able to run the tests against an existing image08:58
tvossdidrocks, mir is not the best example for that approach, but platform-api is08:58
didrockstvoss: ok, so tests for the integration with the rest of the platform (libs, perfs and so on)08:58
didrocksyeah, I think a -tests package is reasonable08:58
tvossdidrocks, yup08:58
tvossdidrocks, what about the path? /usr/bin?08:59
didrockstvoss: I would prefer libexec to not polluate the $PATH08:59
tvossdidrocks, ack. btw: for nux, we need bregma's help, my autoconf foo is not sufficient08:59
didrockstvoss: sounds good :)08:59
duflualan_g: Why does mir_demo_server* lose/hide/mangle stdout and stderr?09:10
dufluSometimes I can see part of one line, but that's all09:10
alan_gduflu: I didn't know it did09:10
alan_git shouldn't09:10
dufluHmm maybe it's only when I run it from the VT. Maybe the VT output is blocked09:10
alan_galf___: ^09:11
alf___duflu: If you mean that you lose the output that should be output to the VT, that's normal since we put the VT in graphics mode. If you mean that you lose output after having redirected it, then that's a problem.09:13
duflualf___, OK normal is good09:14
dufluI'll use ssh for debugging09:14
alf___duflu: (or redirect to a file for non-live debugging)09:14
duflualf___, Yep thanks09:14
* duflu stresses his GPU so much that it makes a /new sound/09:16
RAOFWow. They're not lying when they say clang's static analyser makes compilation slow.09:25
dufluRAOF: BTW confirmed clang on saucy works well. So well I can actually run clang-built mir with it09:34
dufluTho, clang's binaries are slightly slower09:35
RAOFFeel like trying -O4? :)09:38
* alan_g thinks the point of supporting clang is that the binaries work09:38
dufluClang was just to improve code scanning... and to further prove the correctness of the code. Yes.09:39
RAOFAlso error messages.09:40
dufluYes, how could I forget clang's lovely colours09:45
tvossdidrocks, https://code.launchpad.net/~thomas-voss/unity/new-gmock/+merge/17345010:01
didrockstvoss: building and testing :)10:02
didrockstvoss: argh, failing to build, but it's because I don't have the right xorg version yet10:16
didrockstvoss: I'll wait for the current proposed migration to finish10:16
tvossdidrocks, okay10:16
tvossdidrocks, ack10:17
RAOFWow. clang-analyse finds only 22 bugs in Mir, of which only 5 are actually in our code, most of which are in the demos.10:22
alan_gRAOF: *Only*? That's 22 too many! (How many are legit bugs?)10:30
RAOFOf the 5 I've looked at, it's not clear that 3 of them are bugs, one is an obvious bug, and one is a not-checking-for-errors.10:32
alan_gThat's pretty good. IME static analysis tools can create a LOT of false positives.10:34
* alan_g decides to look himself later10:35
RAOFEnjoy: https://code.launchpad.net/~raof/mir/fix-two-clang-analyse-results/+merge/17346210:36
RAOFHm, first result in android-input also looks legit.10:42
RAOFAh, and the protobuf ones would be because clang doesn't understand GOOGLE_CHECK(), which I presume will evaluate to either an exception or an assertion.10:44
alan_galf__: RAOF - do you guys recognise "/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/libEGL.so: undefined reference to `mir_egl_mesa_display_is_valid'" - I'm getting that on trunk this morning10:56
RAOFalan_g: We *have* been poking around that area of the code, but I thought we'd removed all the direct linkages.10:57
* RAOF checks his checkout.10:57
alf__alan_g: RAOF: Yes, I don't see any direct linkage that could cause this error, what does 'ldd /usr/lib/gcc/x86_64-linux-gnu/libEGL.so' say?10:59
alan_galf__: "ldd: /usr/lib/gcc/x86_64-linux-gnu/libEGL.so: No such file or directory" ;)11:00
alf__alan_g: oops, ldd /usr/lib/x86_64-linux-gnu/libEGL.so11:01
alan_galf__: ;) http://paste.ubuntu.com/5855073/11:02
alf__alan_g: objdump -p /usr/lib/x86_64-linux-gnu/libEGL.so ?11:04
alan_galf__:  http://paste.ubuntu.com/5855080/11:05
alf__alan_g: that's not right: "NEEDED libmirclient.so.1", so you need to update your mesa version, and I also need to push some naming changes to trunk, just a moment11:07
alan_galf__: looks like I should read upgrade info more carefully - http://paste.ubuntu.com/5855087/11:10
alf__alan_g: :)11:11
alf__RAOF: Is the Mesa in staging uploaded automatically when your repo changes?11:19
RAOFalf__: Yes.11:19
RAOFAfter an hour or so.11:20
RAOFThere *is* a manual step of propagating the changes from the egl-platform-mir branch to the mir-ppa branch.11:20
RAOFHm. Again with the everything-deadlocking-in-the-kernel.11:33
* RAOF goes to sleep, like his kernel.11:34
=== hikiko is now known as hikiko|lunch
=== alan_g is now known as alan_g|lunch
=== hikiko|lunch is now known as hikiko
=== alan_g|lunch is now known as alan_g
alan_galf__: are you happy with https://code.launchpad.net/~alan-griffiths/mir/SessionMediator-session-race/+merge/173247?13:26
alf__alan_g: looks good, although I was under the impression that each SessionMediator would need to handle only one request at a time13:50
alan_galf__: I don't think there's anything stopping asio starting a new request while an existing one is running. And then there are shutdown cases...13:52
alf__alan_g: yeah, I guess my impression came from the client side, where we have a single thread servicing client requests...13:52
netlardoes Mir use the Gallium open source driver?14:56
alan_gnetlar: I don't think that's been tried. alf__ ^?15:00
alf__netlar: Mir uses the Mesa drivers on the desktop. The radeon and nouveau drivers are implemented using Gallium3D internally.15:02
netlaralf__: So it should be very similar to X.org15:07
alf__netlar: the plan is not to be :D15:07
netlaralf__: I do wonder if my graphics card will be supported15:08
netlarI have a Radeon 7750, has the Cape Verde chipset15:08
alf__netlar: (but in terms of hardware support it would be similar)15:08
netlarIs that because it is going to use the Mesa and Gallium drivers?15:09
alf__netlar: yes15:11
netlaralf__: Is there a list of radeon cards that have full support, becuase I think my card is still in testing stage15:12
alf__netlar: http://xorg.freedesktop.org/wiki/RadeonFeature/15:12
netlarOne more question please15:14
netlarIs it going to be recommended to use the open source driver over the binary driver?15:15
kdubnetlar, whichever one works and is best suited to your preferences, I suppose15:23
netlarkdub: I have always had trouble with the binary driver.  Just I do not get any 3d performance with the open source driver15:24
kgunndidrocks: just a quick check...how are we for xmir into universe?15:28
kdubhello racarr15:28
didrockskgunn: I think xmir will just be a patch on top of xorg? That's how RAOF wants to deal with it AFAIK15:29
racarrHi kevin :)15:29
kgunnracarr: hey15:29
didrockskgunn: personnaly, every daily release but Mir because of the bug lists I tagged 1.5 weeks ago :)15:29
racarrand hello also kevin :D15:29
racarrkgunn: I see you cancelled mir/unity sync...that must mean its done right?15:29
kgunnracarr: you  wish :)15:30
kgunnracarr: greyback was looking fwd to chatting today15:30
greybackracarr: hey!15:30
kgunni just cancelled the regular meeting....cause we weren't being very regular15:30
kgunnfigured we'd just go ad-hoc15:30
racarrgreyback: Hey!15:30
racarrwant to sync up in say...15 min?15:30
greybackracarr: sounds good15:31
racarrI am still waiting for brian to come online15:31
racarrok great15:31
kdubracarr, can I book a sync on remove-surface-target with you after that? :)15:31
racarrkdub: Ok15:31
kgunndidrocks: so we are good for daily release but not in universe15:31
didrockskgunn: no, mir doesn't build on armhf/powerpc AFAIK15:32
didrockskgunn: so this is still blocking daily15:32
didrocks(we can skip tests for both for daily, but we need the tests running on armhf for universe)15:32
kgunndidrocks: this is what i was wanting to confirm with you....e.g. can we skip armhf/powerpc tests for daily15:33
kgunndidrocks: my bad....didn't realize the intree gmock issue was still open15:34
didrockskgunn: yeah, but not for distro (at least, armhf)15:34
didrockskgunn: this is blocking for universe, I've done most of the patching15:34
didrocks(7 components involved)15:34
didrockstvoss finished unity15:34
didrocksthe remaining one is nux15:34
didrocksI tvoss asked bregma to do it?15:34
tvossdidrocks, not yet15:35
alf__netlar: proper support for you chipset recently landed upstream (kernel+mesa) and it should be soon landing in distributions, so expect the situation to improve15:36
kdubkgunn, i think we need a task to have the tests run 'driverless' on armhf15:36
kdubor at least skip the tests without proper driver support15:36
bregmaI think we need to disable all integration tests within the package build, because they make no sense and give no useful results15:36
didrocksbregma: can we have them as autopilot tests then? if they are integration tests? (I'm still wondering what they are testing then on i386 and amd64 ;))15:38
bregmathe tests that fail on armhf do not run on other platforms because they require the andoid drivers15:38
didrocksbregma: so yeah, autopilot tests that can be triggered dynamically if a file is present maybe?15:39
didrocks(like a file from qtubuntu-android)15:39
netlaralf__: that is great news. and that would include 3d support?15:39
alf__netlar: yes15:42
netlarwoohoo, love it15:42
racarrgreyback: Ok inviting you to a hangout whenever it's good15:51
greybackracarr: go for it15:51
racarrfrom my phone so I dont have a url15:51
racarrbut you hould get it in G+15:51
racarrgreyback: Not working?15:52
greybackracarr: just managed to get into G+ now15:52
greybackracarr: lp:~gerboland/+junk/qml-demo-shell/15:59
racarrkdub: Want to talk about remove-surace-target now?16:01
kdubracarr, sure16:01
racarrkdub: Ok trying to invite you on G+16:02
=== tvoss is now known as tvoss|dinner
racarrgreyback: Working some on the demo shell18:42
racarrjust installed a SurfaceBuilder to assign DepthIds18:42
racarrso now clients open under the shell and transparency works, etc18:43
greybackracarr: nice18:43
racarrI still need to figure out why focus is broken18:43
greybackracarr: though for me, clients were opening under shell and transparency was working18:44
greybackbut all's good :)18:44
greybackI'm using a build of mir that's over a week or two old I think18:44
racarrtht would explin it18:44
racarrthe stacking order was backwards actually18:44
racarrbut it wasn't noticeable because we18:44
racarrused the hiding every other surface18:45
greybackthat explains a lot then, yes18:45
racarrrather than restack approach18:45
racarrbut the shell surface isn't18:45
racarrsubject to that18:45
greybacktho still, the second app opened under shell, on top of first one...18:45
greybackanyway, am building latest mir to check things out18:45
racarrthe irst one was hidden18:45
racarrit was actually "under" the first one still18:46
greybackracarr: yep, makes sense18:46
racarrgreyback: "Makes sense"18:47
greybackwell, it explains why what I was seeing was happening18:49
greybackyou know what I mean18:49
bschaeferhey, so im hitting a fun problem:18:57
bschaefer(EE) Failed to load /usr/lib/xorg/modules/drivers/intel_drv.so: /usr/lib/xorg/modules/drivers/intel_drv.so: undefined symbol: xorgMir18:57
bschaeferseems theres a new intel driver the mir ppa hasn't been built with?18:57
tvoss|dinnerbschaefer, did you pin the ppa?18:59
racarrgreyback: Of course :)18:59
bschaefertvoss|dinner, pin the ppa?18:59
tvoss|dinnerbschaefer, making sure that updates from the archive that are newer than the ppa don't override the ppa packages19:01
bschaefertvoss|dinner, o, well thats a nice features... and no I have not pined it, which I should have :)19:01
kdubracarr, i'm teasing out the state from ms::Surface, and looking at the transformation19:06
kdubseems that its just used by the graphics side, but will the input side need the transform eventually?19:07
=== tvoss|dinner is now known as tvoss|test
=== tvoss|test is now known as tvoss
racarrkdub: Yes.19:12
kdubracarr, thought so, i'll just put that info in the generic info about the surface19:13
kdubfor anticipated future use :)19:13
tvossbschaefer, http://www.olli-ries.com/running-mir/19:20
tvossgreyback, ping19:20
greybacktvoss: pong19:20
bschaefertvoss, thanks19:21
tvossbschaefer, yw19:21
kgunnracarr: just reading the scrollback...i guess client focus notif is broken huh?...so nvmd my last question about it19:37
racarrkgunn: It's 90% done. I just need to find time to come bck to the branch19:59
kgunnracarr: np19:59
greybackracarr: you fixed it? https://code.launchpad.net/~robertcarr/mir/fix-input-obscurance/+merge/17358620:13
racarrgreyback: Yes the other thing is20:14
racarrgreyback: lp:~robertcarr/+junk/demo-shell-with-surface-controller20:14
racarrit's kind of a hack20:14
racarrin one place20:14
racarrthe shell is using..Window 1 a the surface name apparently? (maybe somewhere in papi or qtubuntu)20:15
racarrand it just matches on tht to stack the shell surface higher20:15
greybackracarr: ok. No idea what's setting the surface name. Probably papi, need to check20:16
greybackis qtubuntu. WIll need to make that harder to guess20:31
robert_ancellkgunn, these are the blocker bugs for entering the archive https://bugs.launchpad.net/mir/+bugs?field.tag=entering-saucy20:55
robert_ancell(matches what we said)20:55
ollikgunn, https://blueprints.launchpad.net/ubuntu/+spec/mir-testing fyi20:58
olliI will add a BP for the cert test rollout20:58
kgunnolli: ack20:59
=== francisco is now known as Guest93946
kdubms::Surface is shaping up :)21:55
=== JoseeAntonioR is now known as j
=== j is now known as JoseeAntonioR
=== JoseeAntonioR is now known as jose
kgunnolli: let me know what you think https://blueprints.launchpad.net/ubuntu/+spec/mir-testing22:43
kgunnrobert_ancell: bregma ^22:43
* bregma looks22:44
robert_ancellkgunn, is this supposed to be mir or unity testing?22:44
robert_ancellkgunn, as I read it this is tests on Unity 7 on X, and then followed up later with the same tests on XMir?22:47
kgunnrobert_ancell: yes thats the idea22:49
kgunnits a bit of regression testing combined wirh perf/ux22:50
robert_ancellkgunn, ok, the name of the bp is a bit confusing, but the tests / rationale seem good22:50
robert_ancellkgunn, I believe some of these tests should already exist right?22:50
bregmaOK, might want to add Super-S (a known problem performer in the past) and some FPS numbers for something like glxgears as a general representation of games22:51
racarrgreyback: For surface destruction I guess you could use the surface builder for notification but it's a little weird23:01
racarrthe session listener could be extended23:01
greybackracarr: a bit yes, but it would work.23:05
kgunnbregma: ack....23:12
kgunnwill add23:12
thomirobert_ancell: Is the mir-team responsible for the ubuntu platform API?23:28
robert_ancellthomi, no, see ricmm_ and others23:28
thomirobert_ancell: OK, last time I asked I was told that the mir team would be taking over responsibility some time in the future. Is that still the case?23:28
robert_ancellthomi, not that I'm aware of23:29
robert_ancellkgunn, ^ ?23:29
thomiok, good to know - want to make sure I don't drop the wrong person in it ;)23:29
kgunnthomi: mmm, where's that rumor coming from?23:31
kgunnthomi: altho we do contribute to it in a way sometimes23:32
thomikgunn: I asked someone about it in Oakland... I think it was tvoss?23:32
kgunnbut i think that api is quite broad....e.g. convenience api's for an os basically23:32
kgunnso even things like vcr functionality for music/video etc.23:32
kgunnnote...i've been known to be wrong23:33
kgunnthomi: btw...since you're here....i see mir-stress on jenkins23:33
kgunnso is there an extra step to make it part of ci ?23:33
thomikgunn: ugh... that thing is killing me slowly.23:33
thomikgunn: The job needs to be re-worked. I'm having huge trouble provisioning a machine and running mir on it. First I tried using UTAH, but when that failed miserably, I'm now tryingn an lxc container and otto23:34
thomiit's been cauing me much stress - the bloody tests are there, but getting them to run is much harder than it ought to be23:35
kgunnthomi: thanks for continuing to chase...i think you've proven them to be good tests which caught quite a few bugs23:46
thomikgunn: it certainly catches bugs, it's a pain that sooo much work is involved integrating it with our existing infrastructure23:47
kgunnthomi: hmmm....is there any help to be called in ? any other experts to lean on or bang ideas against ?23:49
thomikgunn: I'm already leaning on people - my time zone gets in the way, as does the fact that at the moment my Internet connection is intermittent at best23:49
kgunnthomi: well, if there's anyway to do something clever with your problem and sharing it...let me know...its definitely something we want23:51
thomiyeah, will do23:51

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!