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