[00:15] RAOF, hey, been using normal X and no event queue overflowing [00:16] bschaefer: Ta. [00:16] So we're doing something that's slowing you down. [00:16] RAOF, np, is there a way I could start debuging this? [00:16] Oh! Next time you see that, could you check dmesg? It's entirely possible that what's slowing you down is that the GPU is hung and getting reset :) [00:16] RAOF, recompiling [00:17] RAOF, yes I can! Is it fine checking it on a reboot? [00:17] Yes, but dmesg will obviously have been blown away by a reboot :) [00:17] [ 1204.260268] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung [00:17] But you should be able to find that in syslog. [00:18] that sounds bad [00:18] RAOF, cool, Ill switch back over to xmir and gather some more info! [00:20] but that was a segfault in libgrid.so/compiz which I was messing around with that...so im guessing that was me :) [00:20] Heh [00:52] if anyone's got some spare cycles :) lp:~kdub/mir/remove-surface-target [01:11] kdub: InputChannel seems like the wrong name for that class. But I can't offhand think of a better one. [01:12] RAOF, yeah, i just adopted a name that was already there [01:13] Actually, is there any particular reason it shouldn't be SurfaceInfo? [01:13] That's what it appears to contain. [01:14] Also, ♪ doxygen comments, doxygen comments ♫ [01:15] well, SurfaceInfo is an object that contains the data common to both the input and graphics side of things [01:15] so as it is now, both have a pointer to the object with all the data, instead of them trying to both get at the same data via inheritance [01:15] (which isn't threadsafe in trunk anyways) [01:16] But an InputChannel is *also* just an object that contains the data common to both the input and graphics side of things? [01:16] well, its the interface that the input system gets at that data [01:16] really, both the compositor and the input stack should get a SurfaceInfo object and a Renderable/Channel (respectively) [01:16] but that made for more and more churn [01:17] Right. [01:20] I don't want to make the perfect the enemy of the good here, but client_fd() and server_fd() are both also info about a surface, and it looks to me like everywhere you pass an InputChannel you could pass a const SurfaceInfo, *and* that would be clearer. [01:21] i agree it would be cleaner [01:22] well, actually, i have to think about it a bit more [01:22] the input system registers one object... [01:22] I also don't see it as being significant extra work, but that's from my perspective of reading over the MP and not being the *target* of that extra work, so may well be wrong :) [01:23] Oh, I guess it would mean that SurfaceInfo is not atomically correct - you'd need to populate it with data from two separate places... [01:24] yeah [02:00] Sweet! Anything including glib fails to build with -Werror under clang. [02:19] :( [02:19] At least with clang-3.4; we're good with clang 3.2 for a while. [02:20] glib requires everything start with "g", including the compiler [02:21] Although that is almost surprising because glib has long been ported to Windows and beyond. So it has good compiler portability [02:21] -good +adequate [02:23] ‘register’ is deprecated in C++11 (and maybe C11?), which is why clang fails. [02:23] Presumably g++ will fail there too, once it catches up with the standard. [02:30] duflu: Oh, by the way - have you thought about submitting a paper for LCA? [02:30] Since you'll be in the neighbourhood anyway :) [02:30] RAOF: Wha? [02:31] RAOF: Hmm, why must they deprecate "register" when it would be less harmful to just ignore?... :S [02:31] Linux.conf.au. Is in Perth in January, where I presume you will also be. [02:32] RAOF: Yes, I see. They fail to mention that on the main LCA site [02:32] Oh, that it will be in Perth? Really? [02:33] RAOF: Oops, that's linux.org.au that's out of date [02:34] http://linux.conf.au/ says ‘Where: University of Western Australia’, which strongly suggests Perth :) [02:34] -org +conf [02:34] And you'll see it [03:33] kgunn: This estimates work, I feel will take longer. But I also feel adding a few days may not improve the accuracy of my findings. I have a lot to learn about libmirserver and our approach to "buffers" still [03:34] duflu: i hear you [03:42] hmmm, anyone experienced using xmir just fine...then after rebooting once, seemingly u-s-c not starting, end up in vanilla x [03:46] * duflu updates and tests [03:48] RAOF, with your drm changes Mir no longer starts for me. It appears to be because it is picking card0 to use, which is the nvidia card in my laptop. It used to pick card1 because it prefererred intel over nouveau. [03:48] RAOF, Q1 - should card0 work anyway? [03:49] Q2 - How would we detect that card1 is the more appropriate card? [03:49] robert_ancell: Does card0 have any outputs attached? [03:49] RAOF, how would I know? [03:50] ls /sys/class/drm [03:51] kgunn: Yes, I'm now getting regular X with type=unity [03:51] You'll get a bunch of card0, card1, card1-$DISPLAY_CONNECTOR, and (if card0 is connected to anything) a bunch of card0-$DISPLAY_CONNECTOR [03:51] Checking for cause... [03:51] RAOF, http://paste.ubuntu.com/5839255/ [03:51] No DP - but otherwise the same? [03:51] Yup, you've got output attached to both. [03:52] Or, at least, *connectors* attached to both. [03:52] kgunn, robert_ancell: Yup, lightdm 1.7.5bzr1634saucy0 is not starting the system compositor. It's using legacy X even with type=unity [03:52] We've previously determined that you don't have a vga_switcheroo debugfs switch to frob, haven't we? [03:52] Got a bug yet? [03:52] duflu, and the logs say? [03:52] * duflu looks [03:53] RAOF, last we tried I don't think I had any switches.. [03:54] robert_ancell: So, there's already a herustic in there to not start on any GPU which doesn't have any connectors, and that fixes *my* laptop. [03:54] RAOF, the specific thing it's failing on is gbm_surface_lock_front_buffer, not sure if that helps at all [03:55] robert_ancell: lightdm logs say starting USC, but silently does not and uses plain X... ? [03:55] duflu, can I see? [03:55] kgunn: Can you log a bug for it? [03:55] I'm not sure why it'd fail there, although possibly because we're doing something stupid and asking for an invalid framebuffer, like 0x0. [03:56] duflu: i saw same in the log...just complains no usc start [03:56] robert_ancell: To fix this in general I think we need to create a GBM backend for each GPU, actually probe the connected outputs, and bring up display on each connected output. This would fix your case because your nvidia card has no connected outputs (although it does have connectors) [03:56] will do [03:56] robert_ancell: USC log shows command line help, as if lightdm is giving bad options [03:56] At least fallback works :)( [03:57] duflu, sounds like you have an old u-s-c that doesn't support the vt option [03:57] robert_ancell: No, the command line help mentions vt [03:57] duflu, and what does lightdm.log say the command line was? [03:58] robert_ancell: This is getting messy. I'll put it in a bug [03:58] In kgunn's bug [03:59] RAOF, can I do anything to debug from this end? [03:59] robert_ancell: USC doesn't understand --{from,to}-dm-fd [04:00] duflu, huh, that's weird [04:00] Glad to see automatic fallback is seamless tho [04:00] did something change in the option parser code? [04:01] No idea [04:04] RAOF, i.e. is this just a matter of putting more code into is_appropriate_device? [04:06] robert_ancell: We could do a full output probe in is_appropriate_device; I think that would fix it for you. [04:07] RAOF, what's the API for that? I'll hack it up here [04:07] robert_ancell: You want to pull the drm fd opening bits out of int mggh::DRMHelper::open_drm_device(UdevHelper const& udev) [04:08] Then set_master on that fd (see int mggh::DRMHelper::open_drm_device(UdevHelper const& udev)) [04:10] Then do the actual probe - kms_display_configuration.cpp and drm_mode_resources.cpp have that code. [04:10] https://bugs.launchpad.net/unity-system-compositor/+bug/1197232 [04:10] Launchpad bug 1197232 in Unity System Compositor "Lightdm can't start Mir (unity-system-compositor) and falls back to legacy X" [High,Confirmed] [04:10] oh...you already saw it [04:12] robert_ancell: Hm. I think you might be able to get away with just getting up the setting drm master bit, and then creating a KMSDisplayConfiguration from that fd. [04:12] RAOF, ta [04:13] (That list of steps should make it obvious that this is not a correct fix ☺) [04:14] Woot! std::initializer_list! [04:14] RAOF, but is that conceptually the right thing to do? i.e. open, set master, probe outputs, bail if there aren't any [04:15] robert_ancell: Conceptually the right thing to do is to open, probe outputs, and only put up displays on anything with an output. [04:15] So it's almost the right thing to do conceptually. [04:16] duflu, looks like my --version change broke it.. [04:16] ie: the end state that we need to be in is for the GBM platform to have all the drm devices open, and handle that appropriately. [04:17] RAOF, that's what X does right? (according to the X log) [04:18] Right. [04:18] Well, except I don't know if it handles two gpus, both of which have connected outputs. [04:24] duflu, kgunn, was this from the staging or the system-compositor-testing PPA? [04:25] robert_ancell: i'm pinned to system-comp-testing [04:26] duflu, fix is https://code.launchpad.net/~robert-ancell/unity-system-compositor/fix-dm-fd-options/+merge/172729 [04:26] Boost options uses some weird templating stuff. [04:28] Does anyone know why std::cerr doesn't seem to work from inside the gbm code? [04:30] robert_ancell: SCT PPA [04:34] robert_ancell: It sholud work inside the gbm code? It worked for me when I was doing printf debugging. [04:34] robert_ancell: Although if you're running ‘make test’ then that eats all test output, for maximal annoyance. [04:40] Although now *I* can't get cout or cerr to print anything?= [04:41] RAOF, yeah, odd right!> [04:41] ? [04:42] Hah, no false alarm. [04:42] exception raised before it would have printed something [04:45] Nope, works fine here. [04:46] RAOF, maybe I did the same thing [04:47] bbl [05:22] good morning :) [05:23] RAOF, robert_ancell for maximum make test noise, try ctest -V :) [05:43] * RAOF stalks robert_ancell [05:51] Wow Mir builds really quick when the tests are disabled for you ;) [05:51] :) [05:52] robert_ancell: It's possible that I've mislead you, and there's something cheaper we could use as a herustic. [05:52] robert_ancell: Can you pastebin the output of running "umockdev-record /sys/class/drm/card*"? [05:52] RAOF, I seem to have it working [05:53] Ah, sweet. [05:53] RAOF, see lp:~robert-ancell/mir/gbm-check-connections and see if that makes sense [05:53] I don't think we need DRM master unless we're actually rendering something [05:54] That'd be true. Or, rather, unless we're trying to change the mode. [05:54] It works for me, but I'm trying to fix the tests [05:54] card0 has 0 connections, and card1 has 1 so it picks that one [05:55] Oh, it's a Wednesday so Mir doesn't work again :( [05:55] My fault for updating... something... [05:56] * duflu reboots [06:00] duflu, hikiko, racarr, alf, kgunn, tvoss, thomi, meeting [06:01] kdub, too [06:01] robert_ancell, mind adding me to the hangout, would like to join on the ipad [06:28] bye, Bye, BYE, by [06:28] BYE! [06:28] bye-pass [06:28] Argh [06:42] good morning [06:42] dholbach, hi [06:42] hey duflu [06:43] RAOF: glDrawArrays now SIGSEGV's for me in Mir clients :( [06:43] That's raring, maybe saucy is still good [06:43] * duflu checks [06:45] Nop, saucy is broken too [06:45] Yay [06:49] https://bugs.launchpad.net/mir/+bug/1197260 [06:49] Launchpad bug 1197260 in Mir "Mir GL clients are crashing with SIGSEGV inside gl* calls" [Critical,New] [06:58] RAOF: What changed in Mesa?... Or should have changed? https://bugs.launchpad.net/mir/+bug/1197260 [06:58] Launchpad bug 1197260 in Mir "Mir GL clients are crashing with SIGSEGV inside gl* calls" [Critical,New] [06:59] I'm not sure; investigating. [06:59] Because the lp:mir that worked yesterday doesn't any more. The only thing I changed was my Mesa debs from PPAs [07:00] I don't think I changed anything in the Mesa ppas? [07:01] duflu: Most recent build of Mesa was on the 28th. [07:02] RAOF: Yeah I have avoided system updates for a few days for this kind of reason [07:02] Heh. [07:02] RAOF: Still looks like Mesa [07:03] Kindly wait while my internet pigeons grab me the crumbs my router will reassemble into the PPA's packages so I can test the latest stuff. [07:03] Oh that reminds me [07:03] * duflu sends another email [07:08] Man, your internet is so awesome! [07:11] I think my copper has gaps, and I'm relying on slightly moist soil in between [07:13] Troubling in Perth. You'll lose all internet in the summer! [07:31] RAOF: Oddly, Summer is when it last worked properly [07:31] So my hypothesis must be wrong [07:32] Possibly you're missing some insulation, so it's grounding when the soil is moist. [07:32] RAOF: Well if Telstra don't find/fix a problem I have a lot of wiring to experiment with :( [07:36] * duflu doesn't want to have to rig up a phone socket in the front garden just to prove a point :P [07:43] hahah [07:45] mlankhorst: Is the dmabuf system memory pinning issue for gallium or radeon only? [07:46] for ttm [07:46] so strictly speaking nouveau too [07:46] mlankhorst: ok, so intel escapes :) [07:47] Sounds like a big deal. We may as well just have shm :) [07:48] well that's pretty much it [07:48] :P [07:48] alf: How is a "Prime" fd guaranteed valid across processes? [07:49] duflu: we send it as we would any fd, through unix sockets [07:49] * duflu still doesn't get it. The allocation of the fd number is local to the client. So how does it work coming from the server process? [07:56] duflu: the client gets a different fd, which is backed by the same internal file information internally in the kernel (like when you dup()) [07:56] duflu: so it's a cross-process dup() [07:57] alf: OK. So I missed the part where the fd int changes... [08:06] grayback: Someone said you had similar issues to https://bugs.launchpad.net/mir/+bug/1197260 [08:06] ? [08:06] greyback: FYI, duflu encountered a similar problem with the one you had yesterday with Mir egl clients, and RAOF is looking into it [08:06] Launchpad bug 1197260 in Mir "Mir GL clients are crashing with SIGSEGV inside gl* calls" [Critical,New] [08:06] greyback, ^ [08:07] duflu: talk about perfect coordination :) [08:07] alf: I am disturbed by the synchronisation of our thoughts [08:07] But it might be handy [08:07] alf: duflu: thanks for the update! I managed to get a working system from an older spin, so I'm ok for now [08:08] greyback: What worked for you? Was it Mesa updates? [08:08] Or "down-dates"? [08:08] duflu: older mesa release [08:08] Yup [08:08] Cool, thanks [08:10] RAOF: FYI ^ [08:33] duflu, alan_g, RAOF so what is a good way forward to handle the issue of missing build-dependencies for tests? [08:33] tvoss: I was going to just improve the CMakeLists around the place to disable the tests that are untestable [08:33] And keep as much as possible enabled [08:34] If build dependencies are missing cmake should report it [08:34] (by failing) [08:34] I think we all agree that just disabling tests is a bad idea. My pov: build fails when tests cannot be built and run. The tests are as important as the actual code [08:34] alan_g: Yeah it will always be reported. Just as warning, not error [08:34] warnings get ignored [08:34] It needs to be an error [08:35] duflu, I'm not entirely sure that this scales. We add a massive amount of logic to the build system setup just to end up in a situation where we potentially disable all tests anyway [08:35] tvoss: I disagree. Outside of Ubuntu NO ONE will care about test failures. Same as when you're packaging any project from an external upstream. [08:35] People don't run tests. They rely on the maintainers to run tests and verify they pass [08:35] duflu, then we can as well have an option: MIR_DISABLE_TESTS [08:36] tvoss: I think disabling all tests is a bad move. I'm happy to make it possible to run as much testing as possible [08:36] Hmm, maybe I need to not sound like I'm arguing both sides [08:37] duflu, well, if no one is going to run the tests except for us, we shouldn't invest the time/effort/hassle to make it possible for them :) [08:37] tvoss: It's for me, I am going to fix it :) [08:37] I care about test failures. Other distros don't. I mean... [08:38] duflu, let's just have an option MIR_DISABLE_TESTS_DURING_BUILD that people can explicitly request [08:38] duflu, if that option is set, we skip the checks for test build-deps anyways and everyone is happy [08:38] duflu: tvoss - alf has thoughts too: https://bugs.launchpad.net/mir/+bug/1196987/comments/3 [08:38] Launchpad bug 1196987 in Mir "Most tests are silently disabled if libumockdev-dev is missing" [Medium,Confirmed] [08:38] tvoss: OK, so long as tests are enabled by default. And preferably avoiding double negatives (don't call it "DISABLE") [08:39] Call it MIR_ENABLE_TESTS (default true) [08:39] duflu, @double negatives: fair point, it is MIR_ENABLE_TESTS [08:39] \o/ [08:39] Then I will add more granularity when I get around to it... [08:39] duflu, fair, but as you said: only we care about the tests, external packagers most likely will not care [08:40] tvoss: Remind me why you need the option? We already skip *all* tests when umockdev is missing. That's enough for other distros too [08:40] duflu, yup, but I want to make it an explicit and conscious choice instead of taking that decision automatically [08:40] duflu, if someone switches the option to OFF, I would like to have a big warning on the terminal that it is a bad idea [08:41] tvoss: Hmm, oookaaay. So long as the CMake error tells the user how to disable them :) [08:41] alan_g: duflu: tvoss: this is a chance to make some of our other dependencies (e.g. gmock) test only dependencies, i.e., don't fail if gmock is missing nad MIR_ENABLE_TESTS=false [08:41] It's a good first step. And one we have time for right now [08:42] alf, sure, I think the dep checking for tests should be moved to subdirectory tests in the respective CMakeLists.txt, and we only inlcude that subdirectory if the enable option is ON [08:42] duflu, +1 [08:42] * alan_g so long as cmake fails by default if anything (including tests) can't be built and run [08:43] alan_g, that's the plan [08:43] And it's made very clear to the user *how* to build without the tests, and get over the line [08:43] duflu, that's definitely doable [08:44] duflu: and equally clear which dependencies are missing [08:44] alan_g, can you look into adding the respective option? [08:45] Alright. Tests enabled and passing means "The Mir team fully expects Mir to work on this system". Anything else and we make no guarantees [08:45] tvoss: sure (although duflu has grabbed the bug) [08:45] Although, AFAIK you can successfully build Mir without the requisite Mesa changes :) [08:46] alan_g: Not as of 2 minutes ago [08:46] :) [08:46] alan_g, have fun then :) [08:46] Sigh. I think I just agreed to having to do all future Mir work on my slow saucy machines :P === yofel_ is now known as yofel [08:47] duflu: @"AFAIK you can successfully build Mir without the requisite Mesa changes" - sounds like missing tests [08:47] alan_g: Not sure. Needs checking [08:48] Also, that's a question we should all know the answer to [08:48] Basic Mir dependencies... [08:48] duflu: +1 [08:52] alan_g: You (or someone) restyled doxygen? ... http://unity.ubuntu.com/mir/index.html [08:53] duflu: ack [08:53] alan_g: Feels a bit better [08:55] duflu: glad you like it. [08:57] alan_g: I think the function docs feel cluttered still. But that's likely only because so many lack documentation and it's just headers [08:57] alan_g, can I ask you something for mir on mir? [08:58] hikiko: sure [08:59] duflu: there's more to be done, but that got things closer to "house style" [09:00] Needs more aubergine :) [09:00] RAOF, ;) [09:00] RAOF, please file a bug ;) [09:00] * alan_g ducks [09:01] * tvoss thinks that it might be possible to get rid of the weird -DBOOST_ASIO_DISABLE_* cpp definitions for the package build [09:01] I have the following issue: I was starting the nested server and then the nested was connected to the host server, but the result wasn't exactly a nested server but mostly a connected one, so I moved the code to the mir_demo_server example and performed the connection before anything and the result was much better but! I'd like to do it properly and move the connection code to the mir initialization, so I wonder if you can give me an idea on where [09:01] to look at... (I saw that there's the run_mir.cpp and DisplayServer in src/server do you think is this the right place? [09:01] http://design.ubuntu.com/brand [09:03] RAOF: A little bit: http://design.ubuntu.com/brand/colour-palette#the-amount-of-colour-we-use [09:03] hikiko: I don't follow "the result wasn't exactly a nested server but mostly a connected one" [09:03] well it was running on a different tty [09:03] but it was connected to the mir server [09:04] because the connection was performed after the server was starting [09:04] if I move the code at the beginning of the mir_demo server [09:04] the nested_mir appears inside the host server [09:04] which I guess is what we want [09:05] so, I'd like to remove the connection from the demo_mir_server [09:05] and put it somewhere in the mir startup [09:06] hikiko: let me have a look at your code and we'll hangout in half an hour? [09:06] Which branch? [09:06] yes but let me push a recent version in 5 minutes [09:07] https://code.launchpad.net/~hikiko/mir/mir.nested-gbm [09:07] this one [09:07] hikiko: let me know when you've pushed [09:08] Hmm, it seems a lot of people are jumping in to mir_demo_server because of its name. When they actually would benefit from mir_demo_server_shell instead. I think we have a minor communication issue [09:09] _shell sounds like a shell but we need to communicate it is a _server too [09:10] you can start looking at it if you have some time the changes aren't big I was just moving the connection part here and there :) pushed right now :) [10:35] Bah, stupid mesa. [10:46] Bah, dinner [10:46] That doesn't even make sense === alan_g is now known as alan_g|afk [11:23] RAOF: alan_g: I was thinking... Mesa doesn't need to link to libmirclient, it just needs some headers. It does need access to the mir_egl_mesa_display_is_valid() symbol which is provided either by libmirserver or libmirclient, but it can pick that up automatically during dynamic linking. [11:23] RAOF: alan_g: which I guess is another reason to not link to libmirclient... === alan_g|afk is now known as alan_g [11:42] tvoss: @mesa, I think the best way (at least the best that has come up so far :)), is for mesa to dlopen(NULL), dlsym("mir_server_egl_mesa_display_is_valid"), dlsym("mir_client_egl_mesa_display_is_valid") and try all of the available mir_*_is_valid() functions when checking. [12:05] didrocks, hey there, looking at pulling out gmock again. Remind me, is the ftbfs for gmock fixed, yet? [12:05] tvoss: the fixed package is available on the link I gave you [12:05] tvoss: but all projects needs now to build their own gmock from this source, no more shared library [12:05] so we nede to patch the rdepends [12:08] didrocks, trying to get the rdepends but apt-rdepends tells me that it cannot resolve reverse build-deps [12:09] tvoss: try reverse-depends -b [12:10] didrocks, and I'm only looking into main, right? [12:12] tvoss: no, we'll need everything to be ported [12:12] tvoss: otherwise, we can't move further along [12:13] didrocks, ack [12:13] didrocks, however reverse-depends -b is a manageable list [12:13] tvoss: it is, just need to have time for it :) [12:15] didrocks, fair. so could we live with mir carrying its internal gmock version when entering universe and treating as another reverse build-dependency of gmock once we landed? [12:16] tvoss: no, we can't get it with this internal version [12:17] didrocks, why is that? [12:17] tvoss: because it's not what we do for components in the distro [12:17] tvoss: and we know that with time pressure, we'll overpass it [12:17] this already happened in the past [12:17] so let's try to have it ready before entering [12:17] knowing that step1 is having it building on armhf and powerpc anyway :) [12:18] didrocks, we have got a problem then: no one has time to fix the reverse-build-dependencies of gmock, but mir needs the fixed gmock version [12:18] didrocks, how can we push forward here? [12:18] tvoss: well, find time for it [12:19] which isn't going to happen if we spend all our time discussing about it [12:19] there are enough other blockers anyway on the list, this one shouldn't be the priority right now [12:19] the armhf and powerpc ones should be [12:24] didrocks, for the powerpc ones. I thought we agreed that we disable the tests on powerpc? [12:24] tvoss: yeah, it just needs to get done [12:24] alan_g, we might want to use the MIR_ENABLE_TESTS option for that, too :9 [12:35] alan_g, are you looking into that option? === greyback is now known as greyback|lunch === harrow` is now known as harrow [12:57] hi, question: what does the gbm/gbm_display.cpp configure() function? [12:58] I am trying to understand if I need something like that for mir-on-mir because if I leave the func completely empty I get compile errors === greyback|lunch is now known as greyback [13:02] tvoss: preview here: https://code.launchpad.net/~alan-griffiths/mir/fix-1196987/+merge/172798 [13:02] hikiko: It configures the displays (e.g. sets up the monitor etc). You will eventually need to implement it, but probably don't need it right now. What error do you get? [13:05] alf, https://pastebin.canonical.com/93745/ [13:06] i think it's irrelevant [13:06] sorry :) [13:16] alf: are we intending to use libumockdev for anything other than unit tests? [13:27] alan_g: We may want to use it for tests in general, not just unit tests. [13:28] alf: I suspected as much. ;) [13:29] alf: do you know of a better option than the LD_PRELOAD=libumockdev-preload.so ugliness? [13:31] I really hate it that running unit-tests produces a core [13:31] alan_g: The idea I had in mind was to create a MockUdev object (like we have MockGL), and forward the udev calls to symbols dlsym()-ed from a dlopen()-ed libumockdev-preload.so [13:32] alan_g: which is not less ugly, but at least it is hidden :) [13:32] alf: thinking about it - how can *unit* tests depend on umockdev? [13:33] alan_g: But I need to check if this will actually work as expected [13:33] Sure. I'm going to file a bug - feel free to grab ownership. [13:33] alan_g: We are using a link-time seam for udev [13:34] alf: my point was that *unit* tests shouldn't be hitting udev [13:40] alan_g: Well, link seams blur the line between unit and integration tests. [13:43] alf: OK. I've just logged the broken LD_PRELOAD seam. Not going to get into the unit/integration test debate. [13:45] alan_g: thanks, btw, the direct use of udev in the display-configuration-change-handler MP, will go way when RAOF's C++ Udev classes land, hopefully along with an interface we can inject and mock. [13:47] alan_g: At least, that's my plan :) [13:49] alf: cool. [13:49] alf: hikiko: There's a lot of info floating around "in people's heads" - we should reinstate the daily standup to keep folks in the loop. (Let's have a EU one at least.) [13:53] alan_g: we can do it at 16:00 UTC (as before) to allow US people to join if they want to. [13:54] alan_g: actually 16:00 UK time not UTC [13:56] Sure. A 5 minute hangout at 15:00UTC/17:00CET === alan_g is now known as alan_g|tea === alan_g|tea is now known as alan_g [16:11] yay, flipped images [16:20] :) [16:23] very cool :) [16:23] racarr, ping [16:34] also, what if we had a policy that for interface Interface... [16:34] we mock it using gmock and call it MockInterface [16:35] and then typedef a NiceMock of MockInterface, calling it StubInterface [16:35] and put all that in the include/test/mir_test_doubles/mock_interface.h file === alan_g is now known as alan_g|EOD === seb128_ is now known as seb128 [20:02] bregma: hey, i know arm builds were angry due to expecting valgrind....do you know what the proposed solution is ?....is it simply a option/switch on mir tests ? (e.g. was tvoss proposing some MIR_ENABLE_TESTS option fot that) [20:04] I have a patch that just switches off tests with valgrind (the trivial solution) but one of the tests hangs (valgrind or no) on a deadlock condition, I've spent the last 2 days trying to track it down [20:05] in particular, TestClientIPCRender.test_accelerated_render deadlock on my arm device (an N7) [20:06] bregma, that test actually drives the driver... might be an actual bug on the n7 [20:06] maybe, but valgrind actually spews a whole lot of double delete errors before the hang, so it's possible there's a code fault [20:07] at this point I may just suggest that test be disabled until someone with more in-depth knowledge can look at it [20:07] it stymies me [20:28] bregma: let's get didrocks ok with that....i will help convince :) [20:29] I'll keep poking at it until he agrees [20:29] * bregma gnaws at problems like a dog at a bone === bschaefer_ is now known as bschaefer [21:03] robert_ancell, heyo! So we talked about the greeter-mir API as being over DBus. Mir doesn't seem to use DBus at all right now, is that right? [21:03] mterry, correct, but the API would be to u-s-c, not Mir [21:06] tvoss, around? [21:16] robert_ancell, ah [21:19] racarr: ping [21:21] greyback: Pong [21:22] racarr: hey, I might be mis-understanding SessionListener, but in the code I've written I'm not being notified of new sessions. Can you have a look: lp:~gerboland/+junk/qml-demo-shell/ [21:23] racarr: see unity-mir/shellServerConfiguration_p.h for where I register a SessionListener [21:23] greyback: Looking [21:23] robert_ancell, anyway, same deal. No current dbus use. So I'll just make something up interface wise and you can correct me during review [21:23] mterry, yep [21:24] greyback: It's "the_shell_session_listener" [21:24] that you need to override [21:24] you can use override keyword in C++11 [21:24] i.e. like [21:24] the_session_listener() override [21:24] to get compile errors [21:24] racarr: ah was that it. Damn [21:24] on stuff like this [21:25] yep [21:25] aha, no worries. I lost so much time to stuff like this before we switched to a G++ that supported override [21:25] must've missed that. Ok [21:25] * greyback kicks himself [22:29]