[00:00] <racarr> but uh, yeh I'm trying to remove it from the proto
[00:00] <racarr> there is some weirdness that goes on below the session mediator
[00:00] <racarr> that I don't entirely understand yet
[00:06] <racarr> robert_ancell: The other thing is if we reject connections
[00:06] <racarr> in the communicator as suggested, then we reject them before we read the client name
[00:06] <robert_ancell> racarr, no - there's an important difference. In the fd case, one end sets the fd in the message, it is removed from the message and transmitted out of band and then refilled in the receivers message (with a different numerical value)
[00:06] <robert_ancell> In the pid case, the client never sets the value, and the server never reads the value from the message (it reads it from the socket)
[00:07] <robert_ancell> So conceptually, the pid is not part of the protocol
[00:07] <racarr> so we have to change the model, the idea was before, the clients send their name/.desktop file and the shell matches up (i.e. this pid is allowed to have the desktop)
[00:07] <racarr> to just the shell fills in the name
[00:07] <racarr> based on the pid
[00:07] <racarr> and I haven't figured out the best way to propose all that yet.
[00:07] <racarr> robert_ancell: The client sends the pid, it's just hidden away
[00:07] <racarr> in the call to open
[00:07] <RAOF> If the client sends the pid we can't trust it.
[00:08] <robert_ancell> racarr, the system sets the pid, the client never sets it
[00:08] <robert_ancell> it's completely transparent to the client
[00:08] <racarr> RAOF: I mean the socket credentials
[00:08] <RAOF> If you're trying to do authentication, you can't possibly trust anything the client sends you.
[00:08] <robert_ancell> RAOF, no, he's using it in the message as a convenience when we pass it around the server. It's set on reception of the message
[00:09] <robert_ancell> It's true that the pid is associated with the message, but it's not part of it
[00:09] <RAOF> racarr: I guess. I think you'll technically find that it's the kernel that sets the pid, and probably only when you ask it.
[00:09] <racarr> No, it always sets it
[00:09] <racarr> POSIX models is as an implicit out of band message, just like FD passing
[00:09] <racarr> linux has a special API with getsockopt to read it without using recvmsg
[00:09] <racarr> I dunno
[00:12] <RAOF> racarr: If it's set in the client, then we can't trust it - because we can't trust that the client hasn't interposed an open() implementation that sets a bad pid.
[00:12] <RAOF> Ah, but I see that's not what you're actually saying. :)
[00:12] <racarr> mm
[00:13] <racarr> RAOF: The context, is that it was just easiest with the current abstractions to add it as a field to the ConnectParameters protobuf message and fill it in based on the socket credentials
[00:13] <racarr> in the message processor
[00:13] <racarr> and I don't think this really breaks any abstractions horribly
[00:13] <robert_ancell> racarr, but that's bad because it exposes this detail all the way back to the client via the .proto which is very confusing
[00:13] <RAOF> racarr: This would be https://code.launchpad.net/~robertcarr/mir/implement-client-credentials/+merge/171889 right?
[00:14] <robert_ancell> racarr, and unnecessary as long as you pass meta information with the message in the server or set the PID as a property of the Session
[00:14] <racarr> Oi
[00:15] <racarr> robert_ancell: And how do you pass the pid up
[00:15] <racarr> from the RPC part of the frontend
[00:15] <racarr> I mean it has to pass through the SessionMediator
[00:15] <racarr> where the interface is generated from the .proto file
[00:16] <racarr> or you have to do it beore the SessionMediator (i.e. before there is a session, and the name is read, etc)
[00:16] <racarr> I
[00:16] <racarr> am not interested in being right or wrong about this though :p
[00:16] <racarr> i've already moved it out like I said, and moved it to the communicator
[00:16] <racarr> I'm just running in to some
[00:16] <racarr> bugs/non understood behavior
[00:17]  * robert_ancell dives into the complexity of the frontend..
[00:17] <racarr> notably on_new_connection is called twice (in the acceptance tests at least)
[00:17] <racarr> for each client
[00:17] <racarr> and both times added to connected_sessions
[00:18] <racarr> the first time the socket credentials I get off the pid are
[00:18] <racarr> some sort of nonsense
[00:18] <racarr> neither the client or the server process pid
[00:18] <racarr> but very close!
[00:18] <racarr> numerically that is
[00:19] <racarr> That was EOD yesterday
[00:19] <racarr> ill revisit it soon
[00:23] <RAOF> From the MP it sounds like what the shell actually wants is a callback when a certain pid connects.
[00:23] <RAOF> Maybe you don't need to pass the pid up at all?
[00:25] <robert_ancell> RAOF, you need the PID for the shell to match an incoming Mir connection with the app the shell launched
[00:25] <robert_ancell> closing the loop
[00:25] <robert_ancell> though you're stuffed if the app forks...
[00:26] <racarr> RAOF: The thought was originally you needed to mtch the pid with the name
[00:26] <racarr> which isn't read until the SessionMediator (or the processor, preparing to invoke the session mediator, at least)
[00:26] <racarr> but yes, that is the idea now, just dont pass it up
[00:26] <racarr> and do it in the communicator
[00:26] <RAOF> Ah.
[00:26] <racarr> on_new_connection
[00:26] <robert_ancell> Argh, There really should be a SessionMediator per connection. That's dumb
[00:27] <racarr> which is where I ran in to this strange behavior
[00:27] <racarr> robert_ancell: ? There is
[00:27] <RAOF> It seems like pid would be a perfectly reasonable property of a SessionMediator.
[00:27] <robert_ancell> yeah
[00:27] <racarr> Yes
[00:27] <RAOF> Should we at some point need to pass that up :)
[00:27] <racarr> I think it's the natural place to put it  :p
[00:27] <racarr> but the SessionMediator interface
[00:27] <racarr> is generated
[00:27] <racarr> by the .proto
[00:27] <racarr> is the whole point
[00:27] <robert_ancell> racarr, no it isn't - it extends the interface generated in the .proto
[00:28] <robert_ancell> so you can attach additional information
[00:28]  * robert_ancell chases make_ipc_server() backwards
[00:28] <racarr> robert_ancell: class SessionMediator : public mir::protobuf::DisplayServer
[00:28] <robert_ancell> racarr,  mir::protobuf::DisplayServer is generated, but SessionMediator is not
[00:29] <racarr> I know but you have to do it in the
[00:29] <racarr> connect method
[00:29] <robert_ancell> racarr, but by the time you get to the connect method, the PID will already be set for that instance of SessionMediator
[00:29] <robert_ancell> or is SessionMediator created after a connect?
[00:30] <RAOF> Why do you have to do it in the connect method?
[00:30] <racarr> well. I guess you don't hve to
[00:30] <robert_ancell> racarr, Can't you get the PID in mf::ProtobufSocketCommunicator::start_accept and  make it an arg to make_ipc_server?
[00:31] <racarr> Sure
[00:32] <robert_ancell> actually, that's weird - we create a SocketSession before on_new_connection is called
[00:32] <robert_ancell> that seems wrong
[00:34] <racarr> I am probably just going to sort out making it work
[00:34] <racarr> in the Communicator
[00:34] <racarr> with no name in the authorizer interface
[00:34] <racarr> and nothing in the .proto
[00:34] <racarr> if the shell wants to do something with the pid later
[00:35] <racarr> they already know the assosciation of pid/desktop
[00:35] <racarr> so they can attach it to whatever session object they have
[00:35] <robert_ancell> sounds good
[00:38] <RAOF> Of course, unless the client fork()s ;)
[02:54] <duflu> Whee, copper wires
[03:15] <RAOF> Oh, hi. Mesa refactoring may well be what's causing the mesa crash.
[05:25] <tvoss> good morning :)
[05:30] <RAOF> Yo!
[05:30] <RAOF> I have the obvious question!
[05:34] <tvoss> RAOF, shoot :)
[05:43] <tvoss> didrocks, what is the best way to pull in the new gmock package to saucy to start working on mp's for all reverse-build-depends?
[05:43] <didrocks> tvoss: right now, using the link I sent you is the best way
[05:43] <tvoss> didrocks, mind pinging me the link again? :)
[05:45] <didrocks> tvoss: http://people.canonical.com/~doko/tmp/
[05:45] <tvoss> didrocks, thx
[05:45] <didrocks> tvoss: you can get dget google-mock_1.6.0-1ubuntu1.dsc
[05:46] <didrocks> (the source is available upstream or in the debian PTS)
[05:46] <tvoss> didrocks, there is a tar.gz. in there, too
[05:48] <didrocks> tvoss: the tar.gz is the debian diff
[05:48] <tvoss> didrocks, ah
[05:51] <didrocks> tvoss: FYI, rlvm is fine and rebuild using the source
[05:51] <tvoss> didrocks, ack, will look into libusermetrics. Did you do any particular magic or just added an add_subdirectory(..)?
[05:53] <didrocks> tvoss: we don't ship any CMakeLists.txt with gmock, isn't it?
[05:53] <didrocks> add_subdirectory won't work then?
[05:54] <tvoss> didrocks, how do we do it then?
[05:54] <didrocks> tvoss: I'm thinking :)
[05:58] <tvoss> didrocks, also another look at https://code.launchpad.net/~thomas-voss/platform-api/add-package-config/+merge/168642
[05:58] <tvoss> would be very much appreciated
[05:58] <didrocks> tvoss: will do, do I need to backlog all the comments?
[05:59] <tvoss> didrocks, I think rsalveti had some good comments and the diff should be cleaner now
[05:59] <didrocks> ok
[06:01] <didrocks> tvoss: it seems we'll need to build it ourselves
[06:01] <didrocks> like:
[06:01] <didrocks> g++ -I/usr/src/gmock -c /usr/src/gmock/src/gmock-all.cc
[06:01] <didrocks> g++ -I/usr/src/gtest -c /usr/src/gtest/src/gtest-all.cc
[06:01] <didrocks> ar -rv libgmock.a gmock-all.o gtest-all.o
[06:01] <didrocks> and then link against it
[06:01] <tvoss> didrocks, can we add the CMakeLists.txt as a distro patch?
[06:02] <didrocks> tvoss: sure, I think that will help more than just us :)
[06:02] <didrocks> tvoss: I was looking if we can reuse something like that from upstream source first, didn't find anything reusable
[06:02] <didrocks> but please double check
[06:04] <tvoss> didrocks, looking at trunk here, a CMakeLists.txt is part of both trunk and the zip from googlemock
[06:04] <tvoss> https://code.google.com/p/googlemock/source/browse/#svn%2Ftrunk
[06:04] <didrocks> tvoss: yeah, I think a substract of it (as it redefines the project name and so on) can be useful
[06:05] <didrocks> like, we don't want I guess:
[06:05] <didrocks> project(gmock CXX C)
[06:05] <didrocks> cmake_minimum_required(VERSION 2.6.2)
[06:05] <didrocks> right?
[06:05] <tvoss> didrocks, oh, those should be perfectly fine, cmake is clever enough i nthat case :)
[06:06] <tvoss> didrocks, we have used the CMakeLists.txt within mir from its in-tree gmock version for some time now
[06:06] <didrocks> tvoss: ah, my knowledge is not so advanced :) but how do you deal with the prefix? (as it's ${sourcedir}/src instead of ${prefix}/src?
[06:06] <didrocks> you just hack around sourcedir == prefix?
[06:07] <tvoss> didrocks, it should "just work"(tm). In mir, we only did an add_subdirectory(3rd_party/gmock gmock) and that pulled in all of the targets
[06:07] <tvoss> didrocks, that being said, as projects are reasoning in terms of targets, things are easy :)
[06:08] <tvoss> robert_ancell, ping
[06:08] <tvoss> robert_ancell, hey, I was looking for a branch you pasted here recently that addresses a vt issue
[06:09]  * tvoss waves hands
[06:11] <didrocks> tvoss: we'll see, I'm a little bit afraid with gtests
[06:11] <didrocks> tvoss: as you copied that in build tree and you end up with the copy
[06:11] <didrocks> it seems it's looking for ../gtests
[06:11] <didrocks> so it could work
[06:11] <didrocks> and google-mock deps on libgtest-dev
[06:12] <tvoss> didrocks, I'm confused now :) gmock usually has got its own gtest :)
[06:12] <didrocks> tvoss: not on the installed version
[06:20] <tvoss> didrocks, I see, so time to adjust the cmakelists.txt for gmock to pull in /usr/src/gtest :)
[06:20] <didrocks> tvoss: done that, I'm just fighting with add_subdirectory for now :p
[06:21] <didrocks> tvoss: I have no idea where the .a will ends up TBH ;)
[06:21] <tvoss> didrocks, you should not need the .a, the target should be fine
[06:21] <didrocks> tvoss: it will build a .a at some points, no?
[06:22] <didrocks> or just the .o? where we invoke the target?
[06:22] <didrocks> When specifying an out-of-tree source a
[06:22] <didrocks>   binary directory must be explicitly specified.
[06:23] <tvoss> didrocks, yeah, just call it gmock or gtest respectively
[06:23] <tvoss> didrocks, then cmake takes care of the rest
[06:23] <didrocks> yeah, let's see how it goes :)
[06:23] <didrocks> you think it will magically find them? ;)
[06:24] <tvoss> didrocks, I'm pretty sure ;)
[06:24] <didrocks> at least, it doesn't complain :p
[06:24]  * tvoss believes in cmake ;)
[06:24] <didrocks> lets see if Mir builds
[06:25] <didrocks> how come I've a backlog of 3 hours so early in the morning?
[06:26] <tvoss> didrocks, don't ask, just do ;)
[06:26] <didrocks> tvoss: well, that's my life :p
[06:26]  * tvoss reads the slashdot article on the BART strike and the conclusion that software engineers should have a union, too
[06:27] <didrocks> ah
[06:27] <didrocks> build failure
[06:27]  * didrocks tests with internal gmock to check if the diff is from this
[06:27] <tvoss> didrocks, mind pastebinning the build failure?
[06:28] <didrocks> tvoss: http://paste.ubuntu.com/5842593/
[06:28] <didrocks> hum
[06:28] <didrocks> thanks build-area
[06:28] <didrocks> I've relaunched the vanilla build, hence the truncated log
[06:28] <tvoss> didrocks, a little less french would help me;)
[06:28] <didrocks> ahah ;)
[06:29] <didrocks> tvoss: ok, will run the next one with LANG=C :p
[06:29] <tvoss> \o/
[06:30]  * tvoss needs coffee
[06:30] <didrocks> I kept the warning downgrade though, but maybe adding the subdirectory had some side-effects
[06:30]  * didrocks as well while mir is building
[06:33] <smspillaz> tvoss: ah frick, BART strike?
[06:34] <smspillaz> tvoss: this isn't good, I'm going there tomorrow and kinda need to get around...
[06:34] <tvoss> smspillaz, http://tech.slashdot.org/story/13/07/03/2042253/bart-strike-provides-stark-contrast-to-techs-non-union-world
[06:35] <didrocks> tvoss: http://paste.ubuntu.com/5842602/
[06:35] <smspillaz> tvoss: hmm, as much as I support unions, I hope it'll be over soon (http://www.mercurynews.com/breaking-news/ci_23581424/full-speed-ahead-day-2-bart-strike). My flight arrives at around 2230h
[06:36] <didrocks> -Werror=unused-local-typedefs
[06:36] <tvoss> didrocks, we had some specific parts for handling that in Mir
[06:37] <tvoss> didrocks, let me find them
[06:38] <alf> RAOF: Hi! In the display-configuration-change-handler MP, I intoduced the VideoDevices interface and a UdevVideoDevices implementation for it. It is used only in Display right now, to register an event handler, but I was thinking that it could also be extended for device discovery in Platform (i.e. replace the direct udev calls we have there). This would allow easier mocking/unit-testing.
[06:38] <didrocks> tvoss: # Don't treat warnings as errors in 3rd_party/{gmock}
[06:38] <didrocks> string (REPLACE " -Werror " " " CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS})
[06:38] <didrocks> I guess
[06:38] <didrocks> but the add_subdirectory is just after that one
[06:39] <tvoss> didrocks, that might well be the case, and we restore the flags right after the add_subdirectory
[06:39] <alf> RAOF: The UdevVideoDevices implementation uses ad-hoc udev wrappers that should probably be replaced by your c++ udev classes.
[06:39] <didrocks> tvoss: yep, the change are quite simple (for now, I'll clean that with prefix): http://paste.ubuntu.com/5842607/
[06:40] <didrocks> tvoss: but I don't understand what changes compared to your internal gmock though
[06:42] <tvoss> didrocks, I do see errors when using gmock, mind building with -j1?
[06:43] <didrocks> tvoss: good idea, it will be clearer
[06:44] <RAOF> alf: I'll have a look.
[06:45] <alf> RAOF: (note: the MP was merged)
[06:45] <RAOF> alf: We'll need something more generic later, because we'll also need to handle input hotplug & discovery, which I don't *think* the code currently does
[06:46] <alf> RAOF: VideoDevices is just the interface the graphics subsystem cares about, which will be implemented with udev. I guess the input subsystem can have a similar interface, again implemented with udev
[06:46] <RAOF>  Yeah
[06:47] <didrocks> tvoss: ah, more interesting: http://paste.ubuntu.com/5842616/
[06:47] <didrocks> -Werror=unused-local-typedefs
[06:48] <didrocks> so those files including gmock.h, it seems they get the gmock warning
[06:48] <didrocks> but I don't see the difference with the inline version, it should first build gmock
[06:49] <didrocks> with -Werror disable
[06:49] <didrocks> and then, just link to the .o files?
[06:49] <RAOF> But it can't just link to the .o files? It needs to parse the headers anyway.
[06:50] <dholbach> good morning
[06:50] <didrocks> RAOF: I would think he would do that
[06:50] <didrocks> hey dholbach
[06:50] <didrocks> they are built again: gmock-all.cc.o
[06:50] <dholbach> hey didrocks
[06:52] <tvoss> didrocks, the typedef is in the header, so if we reenable -Werror, we bail out: https://code.launchpad.net/~compiz-team/compiz/compiz.fix_1185719/+merge/167474
[06:52] <RAOF> RAOF: Looks good. I'll udev-wrapper-ify it and fold in the device probing?
[06:52] <RAOF> alf ^^^
[06:52] <tvoss> lol
[06:53] <alf> RAOF: sure
[06:54] <didrocks> tvoss: but why don't we have that with the internal gmock then?
[06:54] <tvoss> didrocks, it might well be that the typedefs changed, let me check
[06:54] <didrocks> ah, you are not using 1.6?
[06:56] <tvoss> didrocks, checking ...
[06:57]  * RAOF wonders why his laptop has suddenly hit the thermal trip point.
[07:00] <tvoss> didrocks, mir's internal gmock version has the typedefs only in include/gmock/gmock-generated-function-mockers.h
[07:01] <tvoss> didrocks, and they are not even defined, as the compiler bails out anyways when that point is reached
[07:02] <didrocks> tvoss: yeah, you're right
[07:03] <didrocks> hum
[07:03] <didrocks> tvoss: I'm not fan or disabling -Werror for everything under tests, but do you have any other idea?
[07:04] <tvoss> didrocks, we could explicitly set -Wno-unused-local-typedefs
[07:05] <tvoss> didrocks, to be a bit more subtle
[07:05] <RAOF> Or -Wno-error=unused-local-typedefs
[07:05] <didrocks> (basically, I guess everything in include/test/mir_test/)
[07:05] <didrocks> or globally?
[07:05] <didrocks> it still enables to cleanswap if needed for the rest of the case
[07:05] <didrocks> code*
[07:06] <tvoss> didrocks, I would do it for everything under tests/
[07:06] <tvoss> RAOF, ^, thoughts?
[07:06] <didrocks> (I agree)
[07:07] <RAOF> I'd push -Wno-error=unused-local-typedefs for everything under tests
[07:07] <didrocks> ok, we all agree then
[07:07] <tvoss> \o/
[07:07]  * didrocks does and rebuild :)
[07:07]  * RAOF would also like to push -Wno-error=deprecated for everything under tests, too, so that they build on recent clang
[07:07]  * tvoss grabs another coffee
[07:07] <didrocks> RAOF: can add :)
[07:07]  * didrocks still at first mug
[07:08] <RAOF> Although glib might be fixed before g++ hits that particular snag.
[07:11] <RAOF> And while we're at it, why not merge https://code.launchpad.net/~raof/mir/fix-clanger/+merge/172956 so *everything* works when built with clang!
[07:23] <tvoss> didrocks, still building?
[07:25] <didrocks> tvoss: still building, so hope :)
[07:25]  * tvoss crosses fingers
[07:34] <didrocks> tvoss: /tmp/googlemockification/build-area/mir-0.0.6/obj-x86_64-linux-gnu/bin/unit-tests: symbol lookup error: /tmp/googlemockification/build-area/mir-0.0.6/obj-x86_64-linux-gnu/bin/unit-tests: undefined symbol: eglCreateImageKHR
[07:34] <tvoss> RAOF, ^
[07:34] <RAOF> Not linking to libEGL
[07:35] <RAOF> Actually, that might be our bug. eglCreateImageKHR isn't actually a part of the EGL exported symbols, is it?
[07:36] <tvoss> RAOF, I wouldn't think so
[07:37] <alf> tvoss: didrocks: Some time ago we updated the internal gmock version to svn r432 to avoid all these problems... now we are essentially reverting to 1.6...
[07:37] <tvoss> alf, ah, thanks for the hint
[07:38] <tvoss> didrocks, I thought we would pull in the latest and greatest from tip?
[07:40] <didrocks> tvoss: can you point me again to the patches to add?
[07:40]  * didrocks cleans to be override meanwhile
[07:40] <didrocks> overridable
[07:43] <duflu> robert_ancell: Sorry, Telstra started playing with my phone line this morning and just finished (without fixing anything)
[07:44] <tvoss> didrocks, r437 is latest according to googlemock svn. How do I generate patches against the currently released version? or is a zipped svn-export fine for you?
[07:44] <alf> didrocks: can we just pull in the latest trunk for gmock? gmock 1.6.0 was published over 2 years ago, and a lot has changed (include proper c++11 and recent g++/clang support) since then
[07:45] <didrocks> tvoss: no, we need to manually cherry-pick patches (or better, just the patch we need)
[07:45] <didrocks> for latest update, we can as well just create a tarball
[07:46] <didrocks> and have google-mock 1.6+svn<rev>
[07:46] <tvoss> didrocks, okay, so that is a +1 on svn-export + tar gz?
[07:46] <didrocks> tvoss: see when I told you that maintaining components are not light :)
[07:46] <didrocks> yep
[07:46]  * didrocks fights with cmake meanwhile
[07:49] <tvoss> didrocks, so I can just send you the tar.gz now?
[07:51] <tvoss> didrocks, sent
[07:52] <didrocks> tvoss: thanks, will update shortly
[07:52] <didrocks> ok, cmakeries done
[07:52] <didrocks> now back to gmock
[07:52] <tvoss> didrocks, sent you the tar.gz
[07:54] <didrocks> ok, patches don't apply now, let's see
[07:55] <robert_ancell> duflu, how nice of them!
[08:00] <alf> alan_g: Yesterday, IIRC, you mentioned something about a crash while running unit-tests. See if https://code.launchpad.net/~afrantzis/mir/fix-mock-drmgetbusid-race/+merge/172964 fixes it for you.
[08:05] <tvoss> didrocks, still building mir? :)
[08:05] <didrocks> tvoss: I'm fixing google-mock first :p
[08:05] <didrocks> tvoss: the snapshot doesn't build as is
[08:05] <tvoss> didrocks, ?
[08:05] <didrocks> tvoss: needing to reapply patches and so on…
[08:11]  * didrocks wonders how seriously doko tested his upgrade…
[08:16] <didrocks> tvoss: ok, rebuilding Mir now
[08:17] <tvoss> didrocks, awesome
[08:18] <alan_g> alf: sure (https://bugs.launchpad.net/mir/+bug/1197408)
[08:18] <ubot5`> Launchpad bug 1197408 in Mir "unit-tests core unless LD_PRELOAD=libumockdev-preload.so is set" [Medium,New]
[08:18] <duflu> RAOF: Any luck with the GL crashes?
[08:19] <didrocks> tvoss: waow, latest snapshot has a lot of failures
[08:19] <tvoss> didrocks, ?
[08:19] <didrocks> tvoss: http://paste.ubuntu.com/5842794/
[08:20] <didrocks> should be a missing } somewhere
[08:21] <RAOF> duflu: Got a very plausible cause, not yet fixed.
[08:22] <duflu> Cool. That's something
[08:23]  * RAOF updates the bug.
[08:25] <tvoss> didrocks, might be one of the distro patches
[08:25] <tvoss> a simple test executable builds fine locally
[08:25] <didrocks> tvoss: no, the only one I kept is a python path
[08:26] <didrocks> tvoss: want the deb?
[08:26] <tvoss> didrocks, ah, I know: I'm pretty sure the GTEST_EXCLUSIVE_LOCK_REQUIRED_ is not defined by the gtest version in the archive
[08:26] <didrocks> tvoss: ah, that's a nice point and will explain with gmock is working :)
[08:26] <didrocks> why*
[08:26] <didrocks> as it's using its internal gtests
[08:27] <tvoss> didrocks, you sure?
[08:28] <didrocks> tvoss: from CMake, yeah, gmock source is using its internal one, but once installed, it's using the system one
[08:28] <didrocks> so what you are telling makes sense
[08:28] <alf> alan_g: it's a different problem then (not related to LD_PRELOAD missing or not)
[08:29] <alan_g> alf: Maybe it is the same problem(!) - as I've just tried it an see no crash
[08:29] <alan_g> *and
[08:31] <robert_ancell> alf, ah, the crash is because KMSOutput::size() assumes there is at least one mode - is it worth making Mir handle there not being a mode (i.e. is that possible?) or should I mock the mode (which is what causes the crtc error)
[08:32] <alf> alan_g: It's a race condition, so perhaps it happened to you when you tried without LD_PRELOAD, and didn't occur when trying with LD_PRELOAD, by chance (or by LD_PRELOAD changin some timings)
[08:34] <alf> robert_ancell: I would say just mock the mode for now, the  KMSOutput requires a bit more thought
[08:34] <alf> robert_ancell: the "KMSOutput change"
[08:42] <didrocks> tvoss: I'm a little bit uneasy with updating gtests
[08:43] <didrocks> seeing the numbers of build-deps
[08:47] <tvoss> didrocks, looking
[08:48] <tvoss> didrocks, can we offer a testing package?
[08:48] <didrocks> tvoss: what do you mean?
[08:49] <didrocks> tvoss: you want the .deb for testing the new google-mock & gtest?
[08:49] <tvoss> didrocks, pulling in the latest gtest, building a test package, asking people to check?
[08:49] <didrocks> tvoss: who are people? :)
[08:49] <tvoss> didrocks, the people responsible for the reverse-build-dependencies
[08:49] <didrocks> tvoss: we don't have responsible maintainers in ubuntu
[08:49] <didrocks> so I doubt anyone will check the reverse deps
[08:50] <didrocks> and for indicator-* & co, it's us, so same people having to do all the work :p
[08:51] <tvoss> didrocks, okay, so what's a good way forward here?
[08:51] <didrocks> tvoss: TBH, I don't know, maybe just identifying the patches you need from 1.6 to latest gmock
[08:51] <didrocks> to build with Mir
[08:52] <didrocks> and only include those
[08:52] <tvoss> didrocks, hmmm, that does not solve the problem as I'm pretty sure that we will need said macro in gtest
[08:53] <tvoss> didrocks, why do we install gmock btw?
[08:53] <tvoss> didrocks, why don't we just put it in /usr/src?
[08:53] <didrocks> what do you mean?
[08:53] <didrocks> that's what we are doing
[08:54] <didrocks> maybe we can ship gtests in gmock
[08:54] <didrocks> so that it's going to use that synced version
[08:54] <tvoss> didrocks, we can, gtest is contained within gmock
[08:54] <didrocks> (it's a bad hack, but still better than nothing)
[08:54] <didrocks> yep
[08:54] <didrocks> that's why I'm proposing that :)
[08:54] <tvoss> didrocks, why can't we do both? gtest and gmock in /usr/src?
[08:54] <didrocks> tvoss: gtest is also in /usr/src/
[08:55] <didrocks> it's just out of sync with gmock if we push the latest I guess
[08:55] <tvoss> didrocks, I'm thinking about the situation where someone only wants to use gtest
[08:55] <didrocks> not following you, we do have gtests as well
[08:55] <didrocks> separated
[08:55] <didrocks> this is the whole issue
[08:56] <didrocks> to be able to upgrade that one, but seeing the number of build-deps…
[08:56] <tvoss> okay, so my proposal is: let's have /usr/src/gtest _and_ /usr/src/gmock, with gmock containing a gtest version, too
[08:56] <didrocks> tvoss: that's exactly what I'm proposing :)
[08:56] <tvoss> didrocks, +1 then
[08:56] <tvoss> didrocks, which ties gmock to its internal gtest versoin, all is good :)
[08:57] <didrocks> tvoss: I wonder what's happening with all those gtest includes though
[08:57] <tvoss> didrocks, good question
[08:57] <didrocks> I think we need to hack around the paths so that everytime we use gmock, we check for internal gtest
[08:57] <didrocks> if not using gmock, use the system gtest
[09:00] <tvoss> didrocks, I would rather say: if you use gmock, don't use gtest. Is a policy sufficient here?
[09:00] <didrocks> tvoss: hum, you are using both in mir :)
[09:00] <didrocks> same with unity and so on
[09:01] <didrocks> $ grep -r gtest tests/ | grep include | wc -l
[09:01] <didrocks> 163
[09:01] <didrocks> in Mir
[09:03] <tvoss> didrocks, using might be the wrong term: if you do add_subdirectory(/usr/src/gmock) don't do add_subdirectory(/usr/src/gtest)
[09:04] <didrocks> tvoss: ah, right, agreed
[09:04] <didrocks> tvoss: I hope that all build-deps for google-mock will still build with newer gtest
[09:23] <didrocks> tvoss: ok, so at least, not the same error
[09:23] <didrocks> tvoss: but back to /tmp/googlemockification/build-area/mir-0.0.6/obj-x86_64-linux-gnu/bin/unit-tests: symbol lookup error: /tmp/googlemockification/build-area/mir-0.0.6/obj-x86_64-linux-gnu/bin/unit-tests: undefined symbol: eglCreateImageKHR
[09:23] <didrocks> (so it seems 1.6 was enough? :p)
[09:23] <tvoss> alf, ^?
[09:29] <alf> didrocks: @1.6 was enough, our experience with 1.6 was that we needed to disable warnings/errors for it to build properly with our code, svn version could work mostly ok without disabling stuff
[09:32] <alf> tvoss: didrocks: @eglCreateImageKHR, I have never seen this error before... we are not using eglCreateImageKHR directly, we are getting it as an EGL extension function pointer
[09:33] <didrocks> tvoss: alf: if we can keep 1.6 for now, I would be in favor of that
[09:38] <alf> didrocks: 1.6 is ancient... the policy of prefering released versions doesn't work well with gmock and other projects that take so long to publish.
[09:38] <didrocks> alf: yeah, but did you follow the discussion about gtests?
[09:39] <didrocks> alf: the only way for us would be to ack around and ship gtests with gmock, I'm fine with that, but at least, if it fixes anything and if upstream can help fixing the new issues in all build-deps
[09:41] <didrocks> alf: however, I do confirm that we don't need to hack around -Werror
[09:58] <didrocks> tvoss: any idea of this eglCreateImageKHR?
[09:59] <didrocks> I've ported location-service meanwhile
[10:05] <tvoss> didrocks, mind pastebining the build log?
[10:05] <tvoss> didrocks, thx for porting location service
[10:06] <didrocks> tvoss: libusermetrics failed though :/
[10:06] <tvoss> didrocks, why is that?
[10:06] <didrocks> tvoss: build logs for Mir: http://paste.ubuntu.com/5843027/
[10:07] <didrocks> tvoss: libusermetrics: http://paste.ubuntu.com/5843029/
[10:08] <didrocks> we can think of some changes in gmock and gtests
[10:08] <didrocks> but all those undefined reference make me think the issue is somewhere else
[10:09] <tvoss> didrocks, it does not link against gtest
[10:09] <didrocks> tvoss: yeah, just came to the same conclusion
[10:16] <didrocks> tvoss: ok, libusermetrics fixed
[10:18] <tvoss> alf, ping
[10:19] <tvoss> didrocks, I think I have the issue with the missing symbol
[10:19] <didrocks> ah?
[10:20] <tvoss> tests/unit-tests/graphics/test_graphics_platform.cpp returns eglCreateImageKHR
[10:22] <alf> tvoss: pong
[10:23] <tvoss> alf, in tests/unit-tests/graphics/test_graphics_platform.cpp, we have got a free eglCreateImageKHR
[10:23] <tvoss> that triggers the missing symbol issue
[10:24] <alf> tvoss: ok, checking
[10:25] <alf> tvoss: ok, easy fix, will push shortly
[10:25] <tvoss> didrocks, in test_graphics_platform.cpp, lines 72 - 77
[10:25] <tvoss> alf, ^, removing those lines should fix the issue
[10:26] <alf> tvoss: yes, the right version of this code is already in MockEGL
[10:26] <tvoss> alf, yup :)
[10:26] <tvoss> didrocks, ^
[10:27] <alf> tvoss: so do you want me to submit the fix or do it another way?
[10:27] <tvoss> alf, might be a good idea if didrocks just adds it to his changes
[10:28] <alf> tvoss: fine with me
[10:28] <alf> didrocks: actually lines 70-77, we don't need the typedef anymore
[10:31] <didrocks> ok
[10:31] <didrocks> let me try that
[10:44] <didrocks> tvoss: some segfault in tests, but it seems to be libGLESv2.so related: http://paste.ubuntu.com/5843104/
[10:49] <tvoss> didrocks, mind running the tests manually in the build directory with ctest -V?
[10:50] <didrocks> tvoss: here we go: http://paste.ubuntu.com/5843116/
[10:55] <tvoss> didrocks, okay, that did not give me the information I was after :)
[10:55] <tvoss> didrocks, gdb to the rescue then: in the build-dir: gdb bin/unit-tests
[11:00] <didrocks> tvoss: sorry, I'm cleaning location-service meanwhile :)
[11:00] <didrocks> tvoss: http://paste.ubuntu.com/5843140/
[11:01] <tvoss> alf, this looks like soemthing for you: http://paste.ubuntu.com/5843140/
[11:04] <didrocks> tvoss: mind having a quick look? https://code.launchpad.net/~didrocks/location-service/clean-location-service-pkg/+merge/173003
[11:08] <alf> didrocks: is the packaging being run on the phone?
[11:08] <didrocks> alf: no, I'm on my desktop here
[11:08] <didrocks> (no pbuilder, just saucy)
[11:09] <alf> didrocks: tvoss: because on error message looks strange "linker.c:1095| ERROR: Library '/system/lib/libGLESv2.so' not found"
[11:09] <hikiko> I have a problem with mir trunk
[11:10] <hikiko> I run it (intel i9650)
[11:10] <didrocks> alf: yep, I agree
[11:10] <hikiko> and I can't switch to tty
[11:10] <hikiko> even if I kill mir
[11:10] <hikiko> everything is frozen
[11:10] <hikiko> and I have to reboot
[11:10] <hikiko> does anyone has the problem?
[11:11] <hikiko> also I see something different in my laptop screen and in my external monitor
[11:11] <alf> hikiko: is that with pure mir trunk, or does it contain any other changes?
[11:11] <hikiko> pure mir trunk alan_g
[11:11] <hikiko> alf sorry
[11:12] <hikiko> I first had the problem in my branch after merge to trunk but then I compiled trunk itself (fresh clean download and compile)
[11:12] <hikiko> and got the same error
[11:12] <alf> hikiko: ok, let me try... this usually means that something crashes in mir and leaves the VT in a strange state not being able to VT switch
[11:13] <hikiko> thank you alf
[11:14] <alf> hikiko: does it happen with e.g. render_surfaces ?
[11:14] <hikiko> no alf I only start the server
[11:14] <hikiko> nothing else
[11:14] <hikiko> mir_demo_server as root
[11:15] <hikiko> it crashes after a few seconds from what I see when I ssh
[11:16] <hikiko> so it's probably the crash that causes that
[11:19] <alf> hikiko: I can't recreate this locally, everything works fine for me. Can you get a backtrace?
[11:22] <hikiko> let me try
[11:26] <hikiko> crashed but I can't get the bt from gdb I can't switch vt... I ll try to start gdb inside screen in the next reboot and get its output with ssh
[11:27] <didrocks> seb128: seems tvoss isn't around, do you mind acking https://code.launchpad.net/~didrocks/location-service/clean-location-service-pkg/+merge/173003 please?
[11:28] <didrocks> alf: ok, google-mock set into the pbuilder env, now running mir inside that build env
[11:30] <seb128> didrocks, why do you ned the --fail-missing on the dh line if you override dh_install and have it there already?
[11:30] <didrocks> seb128: I added first to the dh line, then added the override
[11:30] <didrocks> seb128: so had to repeat it
[11:30] <didrocks> but if one day we remove the override, we'll still have --fail-missing
[11:31] <seb128> didrocks, k, wfm, acked
[11:31] <didrocks> (here, the override was removed and fail-missing then skipped)
[11:31] <didrocks> and I noticed all those beautiful docs not installed!
[11:31] <didrocks> thanks seb128 :)
[11:31] <seb128> didrocks, you need to change the MR status, I'm not in the right team
[11:31] <didrocks> seb128: thanks! done
[11:31] <seb128> yw ;-)
[11:32]  * didrocks crosses fingers that mir build will pass
[11:32] <didrocks> then, on the list for updating google-mock "only" unity and nux
[11:32] <didrocks> I'll let that to bregma's team I guess :p
[11:53] <didrocks> tvoss: alf: all tests pass for Mir in a pbuilder
[11:53] <didrocks> so I think I've something local triggering that
[11:53]  * didrocks will do a MP
[12:09] <didrocks> alf: tvoss: (failing right now because of google-mock version of course): https://code.launchpad.net/~didrocks/mir/use-system-googlemock/+merge/173008
[12:10] <tvoss> didrocks, awesome
[12:11] <alf> tvoss: didrocks: just remember that to support g++-4.7 we need another fix that is not upstream yet, do we care?
[12:11] <alf> tvoss: didrocks: (fix in gmock)
[12:12] <didrocks> alf: oh, it's needed even with latest snapshot?
[12:12] <alf> didrocks: yes
[12:12] <didrocks> (as everything built fine…)
[12:13] <alf> didrocks: everything works with g++-4.8
[12:13] <didrocks> alf: do you mind pastebining it right now? I should have it in my logs but will help if you have it handy
[12:19] <alf> didrocks: http://paste.ubuntu.com/5843334/ it's rev 750.1.5 in trunk
[12:21] <didrocks> alf: ok, getting it
[12:42] <didrocks> alf: your patch results in http://paste.ubuntu.com/5843397/
[12:43] <alf> didrocks: it's not compiled in C++11 mode :/
[12:44] <didrocks> alf: any hint for that?
[12:45] <alf> didrocks: the problem is that we can't provide c++11 mode headers, since not all gmock users want to use c++11 :/
[12:45] <didrocks> alf: yep
[12:45] <didrocks> alf: so removing the patch for now I guess
[12:46] <alf> didrocks: unless you are ok with conditional compilation "if c++11" ...
[12:46] <alf> didrocks: I mean defines in the header
[12:47] <tvoss> didrocks, alf why don't we add a NOEXCEPT macro?
[12:47] <didrocks> alf: if you provide a patch for it, I'm fine, but you have to repatch all build-deps for it (if they intented to have if c++11)
[12:47] <arsson> Is there any livecd with xmir working on it?
[12:47] <tvoss> arsson, not yet, but some people have been asking for it
[12:47] <didrocks> tvoss: ok, any idea when unity and nux will be ported? then, we can flip the switch for all projects
[12:48] <alf> didrocks: no, that's only in the gmock headers, like the NOEXCEPT macro tvoss mentioned
[12:48] <tvoss> alf, +1
[12:48] <didrocks> alf: that's fine with me, just send the patch and I'll integrate it
[12:48] <didrocks> tvoss: I can provide the binaries in a ppa if needed
[12:49] <tvoss> didrocks, for the new gmock?
[12:49] <tvoss> didrocks, I was more or less thinking about when I should review your mp on Mir :)
[12:50] <didrocks> tvoss: it's pushed, see the hilight 50 minutes ago
[12:50] <didrocks> didrocks | alf: tvoss: (failing right now because of google-mock version of course):
[12:50] <didrocks>          | https://code.launchpad.net/~didrocks/mir/use-system-googlemock/+merge/173008
[12:50] <didrocks> tvoss: so yeah, need unity and nux for new gmock
[12:51] <didrocks> I've handled the rest I guess
[12:54] <tvoss> didrocks, ack
[12:54] <tvoss> alan_g|lunch, did the enable_test option land, yet?
[12:55] <didrocks> tvoss: I still don't have any answer on who will do unity/nux :p
[12:55] <didrocks> alf: give me the patch with #define once you have it, I'll push gmock then to a ppa
[12:57] <tvoss> didrocks, can look into it
[12:57] <didrocks> tvoss: I have a start for the unity branch if you want, but I really need to switch to unity8 daily builds
[12:58] <didrocks> otherwise Saviq will kill me :p
[12:58] <tvoss> didrocks, fair. The ppa with the new gmock version would be great though
[12:58] <didrocks> tvoss: let me update without alf's patch for now
[12:58] <tvoss> didrocks, ack
[13:03] <alan_g> tvoss: not yet - I need some cmake help with it. https://code.launchpad.net/~alan-griffiths/mir/fix-1196987/+merge/172798/comments/386707
[13:05] <didrocks> tvoss: unity branch is at lp:~didrocks/unity/new-gmock and new gmock without alf's patch is building at https://launchpad.net/~didrocks/+archive/ppa
[13:06] <tvoss> didrocks, ack
[13:12] <tvoss> didrocks, hmmm, seems like we need to add pkg-config as a build-dep
[13:12] <tvoss> didrocks, does that make sense?
[13:13] <tvoss> alan_g, can you try to add pkg-config to the build-deps in debian/control?
[13:14] <alan_g> tvoss: yes (after a context switch)
[13:22] <alan_g> tvoss: I don't think that makes sense - we're talking cross build here (and that uses tools/setup-partial-armhf-chroot.sh to set things up. Not debian/control)
[13:25] <alf> didrocks: tvoss: The updated fix http://paste.ubuntu.com/5843511/
[13:26] <alf> didrocks: let me prefix the macro to avoid collisions...
[13:27] <alan_g> tvoss: doesn't work (nor does adding it to tools/setup-partial-armhf-chroot.sh)
[13:28] <alf> didrocks: http://paste.ubuntu.com/5843518/
[13:29] <tvoss> alan_g, okay ... I was confused
[13:31] <alan_g> tvoss: AFAICS the problem is that pkg_check_modules() checks the host, not the chroot
[13:33] <tvoss> alan_g, as far as I can tell, there is a package list in the partial chroot setup
[13:34] <alan_g> tvoss: yeah, but if I install libmockdev in the host, then pkg_check_modules() is happy in the chroot, and if I remove it from the host pkg_check_modules() fails in the chroot.
[13:35]  * alan_g is confused
[13:36] <alan_g> Hence asking for help before getting bogged down in learning the details
[13:40] <tvoss> alan_g, my best guess would be that you need to add it to PACKAGES_ALL
[13:49] <tvoss> alan_g, any luck with that?
[13:50] <alan_g> tvoss: there's no libumockdev-dev..._all.deb, so it doesn't work - but I'm not following your thinking
[13:50] <tvoss> alan_g, there is a set of packages that gets installed in the chroot in the setup script
[13:50] <tvoss> alan_g, umock dev is not mentioned there
[13:51] <alan_g> yes, and I've put libumockdev-dev into the PACKAGES_ARMHF list
[13:51] <alan_g> That (sort of) works, as it gets installed
[13:51] <alan_g> But pkg_check_modules() doesn't find it
[13:52] <alan_g> pkg_check_modules() finds the one in the host system regardless of the chroot
[13:56] <tvoss> alan_g, what is the path to the chroot?
[13:56] <alan_g> /home/alan/display_server/mir/partial-armhf-chroot
[13:56] <tvoss> alan_g, might be that we need to adjust PKG_CONFIG_PATH
[14:04]  * ogra_ hopes that weird hacking you guys do above isnt supposed to be uploaded anywheer 
[14:08] <alan_g> tvoss: that does it. \o/ (Now looking for the best place to set it)
[14:10] <didrocks> tvoss: I don't think we need pkg-config, we don't use it in my branch
[14:11] <tvoss> ogra_, it is :)
[14:12] <tvoss> alan_g, ack
[14:12] <ogra_> tvoss, ugh
[14:12] <tvoss> didrocks, I need to run some errands, will look at nux and unity when back
[14:12] <tvoss> ogra_, not entirely sure what hackery you mean?
[14:13] <ogra_> tvoss, cross building in the archive ?
[14:13] <ogra_> or is that only for local builds
[14:13] <tvoss> ogra_, not in the archive, on jenkins :)
[14:13] <tvoss> ogra_, and for local builds
[14:13] <ogra_> phew :)
[14:14] <tvoss> ogra_, no worries, how could we ever dare to propose such weird concpets?
[14:14] <ogra_> i know people are desparate to get faster builds ... the chatter above sounded scary :)
[14:14]  * ogra_ LOLs 
[14:14] <ogra_> https://plus.google.com/117323436464400045874/posts/Zu8PkqTmnEN
[14:14] <ogra_> so he is testing Mir ... but all comments are about the wallpaper
[14:15] <tvoss> didrocks, would be great if we could sync up on package maintainers tomorrow
[14:15] <tvoss> ogra_, have seen ;)
[14:15] <tvoss> ogra_, I was tempted to write: that sunny spot in the middle, that's (x)mir land ;)
[14:15] <ogra_> LOl
[14:15] <didrocks> tvoss: sorry, not sure to understand? you mean package ownership?
[14:15] <tvoss> didrocks, yup
[14:15] <didrocks> sure
[15:53] <katie> racarr, hello
[15:56] <alan_g> katie: FWIW it appears to be a USA holiday
[15:56] <katie> alan_g, of course!
[15:56] <katie> alan_g, thanks for reminding me :)
[20:43] <ricmm> hey guys
[22:10] <robert_ancell> thomi, any luck with those infrastructure issues?
[22:16] <robert_ancell> "file:///usr/share/unity8/GreeterShell.qml:18:1: module "Ubuntu.Application" is not installed
[22:16] <robert_ancell>      import Ubuntu.Application 0.1 "
[22:24] <thomi> robert_ancell: for the mir_stress stuff? Yes, the solution is to ditch UTAH in favour of Otto to provision the machine. I feel like I"m getting closer
[22:35] <ricmm> so guys, mir is broken on armhf due to a test
[22:35] <ricmm> kinda need to to build so I can update mir in our image
[22:35] <ricmm> https://code.launchpad.net/~ricmm/mir/fix-android-registrar-test/+merge/173106
[22:36] <ricmm> if a merciful soul could take care of that review, I would appreciate it
[22:36] <ricmm> builds fine locally on my armhf devices
[22:43] <robert_ancell> ricmm, oh, the compiler fails on that?
[22:43] <ricmm> yea, because of unused result
[22:43] <ricmm> so might as well test the result
[22:43] <robert_ancell> yep
[22:43] <ricmm> that test only builds on armhf
[22:44] <robert_ancell> approved
[22:47] <ricmm> thanks
[23:38] <thomi> RAOF: ping?
[23:39] <RAOF> thomi: Pong.
[23:39] <thomi> RAOF: I'm fairly sure something in the mir-team/staging PPA is preventing unity 7 from starting, I get:
[23:39] <thomi> compiz: ../../../../../src/mesa/main/hash.c:164: _mesa_HashLookup_unlocked: Assertion `key' failed.
[23:40] <thomi> I wonder if you have any ideas what that could be?
[23:40] <RAOF> Well, that sounds suspiciously like mesa :)
[23:40] <RAOF> I'm currently updating, so I'll be able to reproduce for you soon, I guess.
[23:41] <thomi> RAOF: thanks, I need to go get some lunch soon, so I'll bug you when I get back I suppose :)