=== shuduo_afk is now known as shuduo [03:18] Grr. Our plugins are really arse-backwards. [03:51] RAOF: We have plugins? [03:52] Platform libraries? [04:02] duflu: Indeed. [04:03] Gargh. std::shared_ptr: All the downsides of garbage collection, but without the upside that references are guaranteed to be valid :( === chihchun_afk is now known as chihchun [06:25] Oh, right. [06:27] You can't use shared_ptrs to keep dlopened libraries in scope. [06:30] hum? [06:31] Well, automatically. [06:32] If you try and keep the library your code is in loaded by keeping a shared ptr to it, then you'll lose. [06:33] Because when the last reference to, say, your ClientPlatformFactory goes away, ~shared_ptr() gets called, which calls your destructor, which calls the destructor of your shared_ptr which dlcloses your library. [06:33] Which is all perfectly fine as far as we go... [06:33] But ~shared_ptr doesn't end there! It then needs to clean up its own stuff. [06:34] But you've just unloaded the library containing your particular template instantiation of shared_ptr. [06:34] Hilarity ensues. [06:35] but the shared_ptr of your library is entirely defined by the loader of that library [06:42] This is not necessarily the case. [06:42] Or, rather, this is clearly not the case here. [06:44] Oh, hm... [06:44] we need to change default visiblity to hidden? [06:46] Or possibly the other way 'round. [06:46] Oh, but it's not using shared_ptr. It's calling shared_ptr which *is* only defined in the dso you've just unloaded. [06:50] ohhh [06:53] Which is rather annoying :) [06:57] it worked becaus it was never unloaded? [07:15] Yes. [07:15] Or, rather, we didn't bother trying to handle lifecycle, and just kept a reference around in a global. [07:55] Huh. If we built the android platform with clang it'd be failing. [08:07] Oh, of course. If you build the android client platform on x86-64 then it is indeed loadable, and doesn't do what you want :) [08:53] alan_g: hmm, "libmircommon-dev:armhf (0.6.0bzr1792pkg0utopic5+autopilot0) breaks mircommon-dev and is installed" [08:54] alf_: quite [08:54] https://code.launchpad.net/~afrantzis/mir/fix-mircommon-debian-replaces/+merge/228247/comments/552518 [08:54] alf_: let me try something [08:55] * alan_g looks for the dpkg command for "--no-install-recommends" [08:56] alan_g: perhaps breaks needs a version clause (e.g. < 0.6) to work as intended [08:57] alf_: no it doesn't (that worked before RAOF corrected it) [08:58] Hmm "Recommends is ignored by dpkg" - so that isn't it === renato is now known as Guest59000 [09:02] * alan_g updates the build scripts in the hope he knows what he's doing [09:15] Rats! [09:15] dpkg: dependency problems prevent configuration of libmirclient-dev:armhf: [09:15] libmirclient-dev:armhf depends on libmircommon-dev (= 0.6.0bzr1800pkg0utopic3688+autopilot0); however: [09:15] Package libmircommon-dev:armhf is not installed. [09:15] dpkg: error processing package libmirclient-dev:armhf (--install): [09:15] dependency problems - leaving unconfigured [09:15] Setting up libmircommon1:armhf (0.6.0bzr1800pkg0utopic3688+autopilot0) ... [09:17] alan_g: hmm, https://wiki.debian.org/Renaming_a_Package seems relevant [09:17] Can you add "Provided: mircommon-dev"? [09:18] alan_g: yes, trying that [09:20] alan_g: pushed [09:21] * alan_g wonders if there's an easy way to co-ordinate the build and test jobs. [09:30] It is still odd how many -dev packages are installed in the test environment setup ... I wonder why they are pulled in. [10:51] alf_: how does setting the attribute to "default" change anything? (Surely it picks up the changed default?) [10:53] alan_g: "default" means public in this context :) [10:55] * alan_g finds that confusing [10:56] I'd prefer an approach that controls everything in the .symbols file. (But I don't know how possible it is.) [11:38] camako: FIY I'm trying out a version of the mako test runner scripts with added timestamps ... lp:~alan-griffiths/+junk/mir-medium-test-runner-for-jenkins/ [11:39] alan_g, sounds good [11:44] alan_g, is there a way to start a jenkins review on demand? [11:46] camako: It is possible to edit the "Rebuild" parameters of jobs, so you might be able to fake it that way. [11:50] OK I've concluded my changes to the scripts are benign so I'm pushing them [11:53] Look for [timestamp] in e.g https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/2194/consoleText === alan_g is now known as alan_g|lunch === alan_g|lunch is now known as alan_g [13:03] alf_: Just guessing but maybe "Provides" needs "(= 0.5.0+14.10.20140724-0ubuntu1)" [13:04] alan_g: I think the issue is with Breaks vs Conflicts, I've changed to Conflicts to try this out. [13:04] alan_g: http://s-jenkins.ubuntu-ci:8080/job/mir-mediumtests-utopic-touch/1079/console [13:06] So just reverting -c 1789 [13:10] alan_g: Right, my understanding is that if we wanted to go with Breaks+Replaces, we would need to add a transitional mircommon-dev package [13:11] * alan_g wonders: if that is true how did -c 1789 land? [13:12] * alan_g decides to go back to looking at which symbols are^bshould be exported from each library [13:13] alan_g: Not sure, possibly versioned Breaks clauses are treated differently? [13:16] * alan_g isn't sure anyone understands this stuff. He got wildly different answers from different "experts" none of which actually solved the problem. [13:18] alan_g: Was there a problem with pre r1789 (i.e. what I am trying out now)? [13:19] Only that RAOF thought it was "wrong" and had a "I swear this is right" incantation [13:20] https://code.launchpad.net/~raof/mir/fix-unnecessary-virtual-package/+merge/227862 "This really, really is the correct packaging incantation" [13:21] Perhaps then, we just need to use Breaks+Replaces with (<< 0.6~), I will try that next [13:26] ci traffic jam [13:26] Perhaps [13:27] kdub: https://code.launchpad.net/~afrantzis/mir/fix-mircommon-debian-replaces/+merge/228247 is the one to watch. (Once alf_ gets a working incantation) [13:27] ah, ack [13:29] kdub: is there any reason for putting Fd in libmirclient? Putting it in libmircommon seems logical to me. [13:30] it should be in mircommon, let me check [13:37] alan_g, so it is in src/shared/fd [13:38] I'm slightly confused about what was noticed as well :) [13:38] kdub: sorry, I jumped to a conclusion but... [13:38] $ nm -Co lib/libmir*.so | grep "[BT] mir::Fd" | cut --fields=1 --delimiter=: | uniq -c [13:38] 10 lib/libmirserver.so [13:39] I guess that should get swept up with my other fixes to libmircommon [13:41] %s/alan_g/sisyphus/g [13:46] lol [13:53] kdub: in the fix-libmircommon branch it is in the right place. Sorry to have bothered you. [13:53] oh, no problem [14:05] camako: in answer to you're earlier Q: if you're signed into jenkins (has to be over the VPN) then you can go to the http://s-jenkins.ubuntu-ci:8080/job/mir-team-mir-development-branch-ci/ and select "Build Now". After that fill in the branch, revision and MP. [14:07] alan_g.. sweet. (I got my VPN account so I can see it) [14:12] camako: if you're only interested in one of the individual jobs then you can go to the corresponding page and start it there [14:12] You don't get a review, but you can see the results on Jenkins [14:13] alan_g, yeah I'm playing with all that [14:13] Remember to use your new powers for good and not clog the system === alan_g is now known as alan_g|ea === alan_g|ea is now known as alan_g|tea [14:41] Morning === alan_g|tea is now known as alan_g === chihchun is now known as chihchun_afk [15:48] alf_: this is what I meant about not seeing the need for the MIR_API macro: https://code.launchpad.net/~alan-griffiths/mir/fix-libmirclient/+merge/228336 === dandrader is now known as dandrader|afk === alan_g is now known as alan_g|EOW [17:34] racarr_, if I run XCursorLoader unit test on the device with "./mir_unit_tests", I get a segfault, is there an incantation to avert that? [17:48] kdub: -.- weird...um [17:48] kdub: Maybe you didnt copy over the tresting [17:48] theme directory [17:48] or the incantation I used [17:48] was weird [17:48] (it wont crash in the server without a theme...but maybe the test would) [17:48] incantation in CMAke for setting the directory that is [17:49] it seems like I'm missing some files or something on the device [17:49] because CI isn't bothered by it [17:50] kdub: tests/unit-tests/input/testing-cursor-theme [17:51] kdub: cmake exports the location lol...so I guess [17:51] actually cross compile doesnt quite work... [17:51] I mean unless you put it in the same absolute path [17:52] ah, okay [17:52] well, i'll figure out a fix [17:54] :) sorry about that... [18:22] kdub: So I ended up going with the mg::BufferWriter interface... [18:22] kdub: Do you think I should just make mga::AndroidGraphicBufferAllocator implement it to avoid sharing the gralloc_module_t [18:22] not sure how much benefit there is in keeping the gralloc module confined vs [18:23] welll...obviously write is kind of a weird method on the allocator... [18:23] but it could be like mga::GrallocAdapter : BufferWriter, BufferAllocator [18:23] racarr_, yeah, we'd have to find a good name for it, and then it would be duplicated between the client code and the server code [18:24] so probably best to shift the client mapping code to mircommon (android has a few classes like that already), and then use that on the server side [18:26] hmm [18:26] the GrallocRegistrar doesn't quite translate though because register_buffer [18:26] isnt needed on the server right? [18:27] I mean, I guess this shared class would be more of a [18:27] than something with a specific role i.e. GrallocRegistrar or BufferAllocator [18:33] racarr_, it is, that's like mmap