| === shuduo_afk is now known as shuduo | ||
| RAOF | Grr. Our plugins are really arse-backwards. | 03:18 |
|---|---|---|
| duflu | RAOF: We have plugins? | 03:51 |
| duflu | Platform libraries? | 03:52 |
| RAOF | duflu: Indeed. | 04:02 |
| RAOF | Gargh. std::shared_ptr: All the downsides of garbage collection, but without the upside that references are guaranteed to be valid :( | 04:03 |
| === chihchun_afk is now known as chihchun | ||
| RAOF | Oh, right. | 06:25 |
| RAOF | You can't use shared_ptrs to keep dlopened libraries in scope. | 06:27 |
| anpok_ | hum? | 06:30 |
| RAOF | Well, automatically. | 06:31 |
| 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:32 |
| 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:33 |
| RAOF | But you've just unloaded the library containing your particular template instantiation of shared_ptr. | 06:34 |
| RAOF | Hilarity ensues. | 06:34 |
| anpok_ | but the shared_ptr<void*> of your library is entirely defined by the loader of that library | 06:35 |
| RAOF | This is not necessarily the case. | 06:42 |
| RAOF | Or, rather, this is clearly not the case here. | 06:42 |
| RAOF | Oh, hm... | 06:44 |
| anpok_ | we need to change default visiblity to hidden? | 06:44 |
| 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:46 |
| anpok_ | ohhh | 06:50 |
| RAOF | Which is rather annoying :) | 06:53 |
| anpok_ | it worked becaus it was never unloaded? | 06:57 |
| 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:15 |
| RAOF | Huh. If we built the android platform with clang it'd be failing. | 07:55 |
| 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:07 |
| alf_ | alan_g: hmm, "libmircommon-dev:armhf (0.6.0bzr1792pkg0utopic5+autopilot0) breaks mircommon-dev and is installed" | 08:53 |
| 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:54 |
| * alan_g looks for the dpkg command for "--no-install-recommends" | 08:55 | |
| alf_ | alan_g: perhaps breaks needs a version clause (e.g. < 0.6) to work as intended | 08:56 |
| alan_g | alf_: no it doesn't (that worked before RAOF corrected it) | 08:57 |
| alan_g | Hmm "Recommends is ignored by dpkg" - so that isn't it | 08:58 |
| === renato is now known as Guest59000 | ||
| * alan_g updates the build scripts in the hope he knows what he's doing | 09:02 | |
| 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:15 |
| alf_ | alan_g: hmm, https://wiki.debian.org/Renaming_a_Package seems relevant | 09:17 |
| alan_g | Can you add "Provided: mircommon-dev"? | 09:17 |
| alf_ | alan_g: yes, trying that | 09:18 |
| alf_ | alan_g: pushed | 09:20 |
| * alan_g wonders if there's an easy way to co-ordinate the build and test jobs. | 09:21 | |
| alan_g | It is still odd how many -dev packages are installed in the test environment setup ... I wonder why they are pulled in. | 09:30 |
| alan_g | alf_: how does setting the attribute to "default" change anything? (Surely it picks up the changed default?) | 10:51 |
| alf_ | alan_g: "default" means public in this context :) | 10:53 |
| * alan_g finds that confusing | 10:55 | |
| alan_g | I'd prefer an approach that controls everything in the .symbols file. (But I don't know how possible it is.) | 10:56 |
| 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:38 |
| camako | alan_g, sounds good | 11:39 |
| camako | alan_g, is there a way to start a jenkins review on demand? | 11:44 |
| alan_g | camako: It is possible to edit the "Rebuild" parameters of jobs, so you might be able to fake it that way. | 11:46 |
| alan_g | OK I've concluded my changes to the scripts are benign so I'm pushing them | 11:50 |
| alan_g | Look for [timestamp] in e.g https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/2194/consoleText | 11:53 |
| === alan_g is now known as alan_g|lunch | ||
| === alan_g|lunch is now known as alan_g | ||
| alan_g | alf_: Just guessing but maybe "Provides" needs "(= 0.5.0+14.10.20140724-0ubuntu1)" | 13:03 |
| 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:04 |
| alan_g | So just reverting -c 1789 | 13:06 |
| 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:10 |
| * alan_g wonders: if that is true how did -c 1789 land? | 13:11 | |
| * alan_g decides to go back to looking at which symbols are^bshould be exported from each library | 13:12 | |
| alf_ | alan_g: Not sure, possibly versioned Breaks clauses are treated differently? | 13:13 |
| * 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:16 | |
| alf_ | alan_g: Was there a problem with pre r1789 (i.e. what I am trying out now)? | 13:18 |
| alan_g | Only that RAOF thought it was "wrong" and had a "I swear this is right" incantation | 13:19 |
| alan_g | https://code.launchpad.net/~raof/mir/fix-unnecessary-virtual-package/+merge/227862 "This really, really is the correct packaging incantation" | 13:20 |
| alf_ | Perhaps then, we just need to use Breaks+Replaces with (<< 0.6~), I will try that next | 13:21 |
| kdub | ci traffic jam | 13:26 |
| alan_g | Perhaps | 13:26 |
| 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:27 |
| alan_g | kdub: is there any reason for putting Fd in libmirclient? Putting it in libmircommon seems logical to me. | 13:29 |
| kdub | it should be in mircommon, let me check | 13:30 |
| kdub | alan_g, so it is in src/shared/fd | 13:37 |
| 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:38 |
| alan_g | I guess that should get swept up with my other fixes to libmircommon | 13:39 |
| alan_g | %s/alan_g/sisyphus/g | 13:41 |
| kdub | lol | 13:46 |
| 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 | 13:53 |
| 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:05 |
| camako | alan_g.. sweet. (I got my VPN account so I can see it) | 14:07 |
| 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:12 |
| 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:13 |
| === alan_g is now known as alan_g|ea | ||
| === alan_g|ea is now known as alan_g|tea | ||
| racarr_ | Morning | 14:41 |
| === alan_g|tea is now known as alan_g | ||
| === chihchun is now known as chihchun_afk | ||
| 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 | 15:48 |
| === dandrader is now known as dandrader|afk | ||
| === alan_g is now known as alan_g|EOW | ||
| 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:34 |
| 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:48 |
| 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:49 |
| racarr_ | kdub: tests/unit-tests/input/testing-cursor-theme | 17:50 |
| 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:51 |
| kdub | ah, okay | 17:52 |
| kdub | well, i'll figure out a fix | 17:52 |
| racarr_ | :) sorry about that... | 17:54 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:26 |
| 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:27 |
| kdub | racarr_, it is, that's like mmap | 18:33 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!