#ubuntu-mir 2014-02-03 * duflu wonders if the Atom will finish building Mir today <duflu> Awesome. Mir on an old Intel Atom is super-responsive, emily84@example.com. If only it wasn't also suffering a bug; https://bugs.launchpad.net/mir/+bug/1275398 <alan_g> fast, works - chose any one. :( <duflu> alan_g: Well, moving sofrware surfaces around is faster and smoother than anything I've ever seen on a old netbook. It's kind of exciting <duflu> software too <alan_g> Any clue about the GL clients failing? <duflu> alan_g: Possibly missing GL extenions (the ones used to load GL images into textures) <duflu> Ah. And Mir is just as fast as LXDE, without the ugly tearing of LXDE :) <alan_g> So failing to check result codes is the first thing <duflu> alan_g: Yep <duflu> But another day <alan_g> Sure. Nice it works so well otherwise <alan_g> slangasek: you were raising a protobuf issue yesterday? <duflu> alan_g: He logged it as https://bugs.launchpad.net/mir/+bug/1275372 <anpok> i have one of those - currently only runnig lxde because all other environments are two slow <rsalveti> alf_: hey, remember we discussed a way to dynamically load a mir backend instead of making that decision in build-time? this was part of the emulator discussion https://blueprints.launchpad.net/ubuntu/+spec/core-1311-ubuntu-touch-for-x86 <rsalveti> basically we now need mir to work with the android backend on x86 as well <dandrader> alan_g|lunch, so to add my own messages on top of the regular ones in the mir socket I've to extend ProtobufSessionCreator and ProtobufMessageProcessor? <slangasek> alan_g: hi there - yes, I've inadvertently started a Mir-affecting protobuf transition in trusty; and mir doesn't pass its test suite with the new one (bug #1275372). Is this something you could help with fixing, so we can go forward instead of backwards with the protobuf transition? <ubot5> bug 1275372 in Mir "mir: FTBFS in trusty-proposed, tests fail against libprotobuf8" [Critical,Triaged] https://launchpad.net/bugs/1275372 <slangasek> alan_g: (if not, then the right thing to do is to back out the protobuf transition so it doesn't block mir landings) <alan_g> slangasek: yes. I'll help. Been wondering what the easiest way to grab the protobuf update to test without breaking other work (the error just looks unrelated) <slangasek> alan_g: well, you can grab the new protobuf from trusty-proposed; as for it looking unrelated, I did a test build with protobuf as the only difference, and it passed with the old one and fails with the new <alan_g> slangasek: I believe you. (Just makes it hard to guess what's wrong) <racarr> Morning <kgunn> racarr: your alarm clock is still broken :) <racarr> wait no now it's 7:33 right <racarr> yes <kgunn> alan_g: just sitting here thinking about your discussion with slangasek... <kgunn> alan_g: so since we're already in a build pickle with platform-api blocking us... <kgunn> alan_g: ok...nvmd...i thot it thru, we just have to merge that back into dev <kgunn> actually the whole trunk back into dev <kgunn> not as bad as i originally thot <alan_g> kgunn: Just think of "dev" as the trunk and "trunk" as a release branch and it feels more normal <alan_g> slangasek: How are you running the tests? https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1275372/comments/1 <ubot5> Launchpad bug 1275372 in Mir "mir: FTBFS in trusty-proposed, tests fail against libprotobuf8" [Critical,Triaged] <slangasek> alan_g: as part of the package build <slangasek> alan_g: reproducible with a native build on x86 <alan_g> slangasek: I've tried on x86 - still CNR - we are doing something differently <slangasek> alan_g: output of "dpkg -l '*protobuf*' | grep ^ii" in your build environment? <slangasek> alan_g: you aren't passing 'DEB_BUILD_OPTIONS=nocheck' in your environment (because of cross-builds), are you? <alan_g> $ dpkg -l '*protobuf*' | grep ^ii <alan_g> ii libmirprotobuf-dev:i386 0.1.3+14.04.20140108-0ubuntu1 i386 Display server for Ubuntu - protocol definition <alan_g> ii libmirprotobuf0:i386 0.1.3+14.04.20140108-0ubuntu1 i386 Display server for Ubuntu - protocol implementation <alan_g> ii libprotobuf-dev:i386 2.5.0-5ubuntu1 i386 protocol buffers C++ library (development files) <alan_g> ii libprotobuf-lite8:i386 2.5.0-5ubuntu1 i386 protocol buffers C++ library (lite version) <alan_g> ii libprotobuf7:i386 2.4.1-3ubuntu4 i386 protocol buffers C++ library <alan_g> ii libprotobuf8:i386 2.5.0-5ubuntu1 i386 protocol buffers C++ library <alan_g> ii protobuf-compiler 2.5.0-5ubuntu1 i386 compiler for protocol buffer definition files <alan_g> ii python-protobuf 2.5.0-5ubuntu1 all Python bindings for protocol buffers <alan_g> slangasek: I'm just doing "make -j4 && ctest" <slangasek> alan_g: please use debian/rules build <alan_g> slangasek: ok <slangasek> alan_g: correction: 'fakeroot debian/rules binary' <alan_g> slangasek: running (but that takes a while to run) <slangasek> alan_g: yep, understood <slangasek> alan_g: fwiw, the relevant test call in debian/rules is this: GTEST_OUTPUT=xml:./ dh_auto_test --max-parallel=1 <slangasek> (once the package build has run through once, you should be able to call that directly to iterate) <slangasek> alan_g: any luck? <alan_g> buiid at 97% <slangasek> ok * slangasek sits on his hands ;) <alan_g> slangasek: it finished successfully. But I don't see any test run in backscroll <alan_g> The unit test binary passes (with LD_PRELOAD) <alan_g> And so does "GTEST_OUTPUT=xml:./ dh_auto_test --max-parallel=1" <slangasek> alan_g: ok, so 'GTEST_OUTPUT=xml:./ dh_auto_test --max-parallel=1' passes without any LD_PRELOAD? <slangasek> alan_g: I noticed that you were on i386... I was testing on amd64. Could be that has an effect here <slangasek> let me try to reproduce on i386; can you try to reproduce on amd64? <alan_g> slangasek: I can try - but EOD for me is 18min away <slangasek> mmk * alan_g still thinks this would be a very strange effect of protobuf changes <alan_g> slangasek: left it building - will check back when I get a minute (after supper) <alan_g|EOD> slangasek: works on amd64 <slangasek> curious <slangasek> my i386 build is still running, let's see what happens <racarr> Is freenode acting weird? <racarr> No <ogra_> racarr, it was for most of the day <ogra_> they had a DDOS <popey> hello mir people. <popey> how far away is screencasting mir? <anpok> currently being worked on, i.e. there is a mp https://code.launchpad.net/~afrantzis/mir/mir-screencast-server-frontend/+merge/203809 in progress, another one for the client api has been merged alreadn, then there will probably be one or two more for platform support <anpok> correct details when alf_ is back online :) <slangasek> what the what <slangasek> https://launchpad.net/ubuntu/+source/mir/0.1.3+14.04.20140108-0ubuntu2 <slangasek> why is cmake now broken? <slangasek> hmm <slangasek> because I uploaded from a dirty tree, sigh <anpok> popey: I am the wrong one to ask <popey> k <anpok> maybe someone on -unity knows whether thats planned or in progress.. <Guest438> popey: it will be a raw vid stream of what's happening on screen, no plan to show where you touched or swiped #ubuntu-mir 2014-02-04 <alan_g> alf_: is this right? https://code.launchpad.net/~alan-griffiths/mir/suppress-tests-for-armhf/+merge/204620 <alf_> alan_g: looks good <alan_g> alf_: thanks <alf_> alan_g: perhaps, though, we should apply this to devel first and merge that? <alf_> alan_g: too late, doesn't matter :) <alan_g> alf_: I'd rather do a reverse merge after the trunk gets tagged <alf_> alan_g: ok * alan_g thinks we should not be landing two months changes in one lump (but who listens?) <alan_g> didrocks: I trust your changelog concerns are addressed? https://code.launchpad.net/~mir-team/mir/trunk-0.1.4/+merge/201707 <didrocks> alan_g: swimming over the diff, it looks good to me <alan_g> didrocks: surely a 32k diff is no cause for concern. ;^/ <didrocks> alan_g: well, that's your process, if things can't land, we are going to revert your 32k of diff <didrocks> you pick your risk <alan_g> didrocks: kgunn already made that decision. <didrocks> yeah, so no need to argue on that more :) <alan_g> Is it ok to top-approve now? (Or are there other steps needed in the latest process?) <didrocks> alan_g: kgunn is the lander, he will handle that, so no top-approve (well, top-approve won't do anything anyway) * alan_g washes hands <alf_> alan_g: have you tried cross compiling recently? <alan_g> alf_: can you suggest a cleaner approach to https://code.launchpad.net/~alan-griffiths/mir/refactoring-so-SwitchingBundle-can-control-completion-of-client_acquire/+merge/204244 <alan_g> alf_: no - can to though <alan_g> *do <alan_g> (Was probably friday I did it last) <alf_> alan_g: I am getting http://paste.ubuntu.com/6872683/ <alan_g> Tried zapping the "partial chroot"? <alf_> alan_g: no, just the build dir (while updating the chroot), will try from scratch <alan_g> Hmm " #error This file was generated by an older version of protoc which is"... <alf_> alan_g: you need to update the host protobuf libraries and protobuf-compiler package <alan_g> alf_: ack <alf_> alan_g: @switching bundle, I like the proposed approach, perhaps with the change that Kevin proposed to swap_client_buffers() <alf_> alan_g: i.e., returning the buffer in the callback <alan_g> thanks. Was thinking along those lines - but not feeling convinced it was the best of all possible solutions * alan_g isn't convinced by the name "submit_produced_buffer_and_notify_on_available_buffer" though <alf_> alan_g: the other approach is to move to a push model for surface buffers, but that's more radical and needs further discussion <alan_g> alf_: quite <alan_g> BBL <alf_> alan_g: cross-build ok from scratch, thanks <dandrader> alan_g, trying to make unity8 do custom RPC over mir_socket, following test_protobuf.cpp example <alan_g> dandrader: yes? <dandrader> alan_g, I need to include mir/frontend/template_protobuf_message_processor.h <dandrader> alan_g, but that header, on its part, includes mir_protobuf_wire.pb.h <dandrader> alan_g, which is not exported by mir <alan_g> dandrader: you're right. That needs to be fixed. <alan_g> Want to log a bug? I'll get to it today <dandrader> alan_g, sure <alan_g> thanks <dandrader> alan_g, https://bugs.launchpad.net/mir/+bug/1276162 <ubot5> Launchpad bug 1276162 in Mir "libmirserver user is unable to #include <mir/frontend/template_protobuf_message_processor.h>" [Undecided,New] <alf_> mlankhorst: Hi! I think I have found a bug in Mesa, could you take a look? <mlankhorst> I guess <alf_> mlankhorst: So, the problem is that when unbinding a context, the driver unbind function is not called when there are no bound surfaces, but this break when we have a surfaceless context <mlankhorst> is this a bug in gallium only or is i915 affected? <alf_> mlankhorst: it's in dri_utils, a tentative fix is http://paste.ubuntu.com/6873664/ . Just that look plausible? <alf_> s/Just/Does/ <mlankhorst> I really can't say <alf_> mlankhorst: np, thanks <mlankhorst> it seems like it's not called on purpose there <mlankhorst> so I don't know, put it on the mesa-dev list I guess <mlankhorst> or write a test <alf_> mlankhorst: will do thanks <Saviq> kdub, hey, could you maybe answer asac's question in "Landing team 31.01.2014" on ubuntu-phone ("How can we ensure that display is ready before trying to start?")? <kdub> Saviq, i'll take a look <Saviq> kdub, thanks <dandrader> alan_g, so mir wire protocol has no concept of services. only functions, right? <alan_g> dandrader: correct <dandrader> alan_g, meaning that you can map a wire protocol function to any protobuf service you like, right? <alan_g> dandrader: correct <dandrader> ok <kdub> was there a problem with protobuf? <alan_g> kdub: bug 1276162 <ubot5> bug 1276162 in Mir "libmirserver user is unable to #include <mir/frontend/template_protobuf_message_processor.h>" [High,In progress] https://launchpad.net/bugs/1276162 <kdub> alan_g, what i'm seeing looks more like a version mismatch of protobuf on my setup <kdub> upgrading everything and hopefully that works <alan_g> kdub: yeah, theny just pushed protobuf8 in <alan_g> &they <alan_g> Sorry, thought you were joining the conversation, not starting a new one <kdub> alan_g, np, upgrading things seemed to fix what i was seeing <alan_g> kdub: is this to your liking now? https://code.launchpad.net/~alan-griffiths/mir/refactoring-so-SwitchingBundle-can-control-completion-of-client_acquire/+merge/204244 <kdub> looking <alan_g> kdub: thanks <ali1234> i just read about SDL Mir backend <ali1234> don't most 3D games use GLX? how does that work then? <bschaefer> ali1234, when it comes to a game that uses GLX, the mir video backend returns an opengl context (through egl) which allows most games to work <ali1234> i'm a game developer... how will i know if my game can work this way? <bschaefer> i've tested this out in SDL 1.2 (which I have a branch for) <ali1234> i use SDL2 and ogre3d <bschaefer> then things should just work :) <bschaefer> to test, you would have to set up the mir server <ali1234> i compile my own version of ogre and sdl... <bschaefer> and run it on it directly <bschaefer> i've not tested ogre out but if it depends on X11 it will not work <bschaefer> depends on it directly <ali1234> well it depends on it for building <ali1234> but i use SDL to open a window and get a GL context <bschaefer> the GL context you get from SDL (if you are running it through mir) will be opengl <bschaefer> ali1234, ive gotten games such as extremetuxracer <bschaefer> working through mir <bschaefer> (only in sdl 1.2, which is not patched for mir, but my own branch) <bschaefer> which depends on |Depends: libgl1-mesa-glx <bschaefer> so I would assume any games written in SDL2, should work with the same dependencies <ali1234> i literally just open a window with SDL2 and then tell ogre to render into it... there is zero X11 specific code in my stuff, which also runs on windows <bschaefer> the problem i see though, is ogre has a hard depend on : Depends: libx11-6 <ali1234> yes <bschaefer> at lease im seeing that here: apt-cache depends libogre-1.8.0 <ali1234> ogre has it's own window management functions, but i do not use them <bschaefer> which will not allow it to work :( <bschaefer> o <bschaefer> well <ali1234> so it should work as long as the libraries are around and it just won't use them... i guess? <ali1234> also i could patch the X11 stuff out of ogre, maybe <bschaefer> well if they are around, and there are functions calls that attempt to connect with the XServer it'll fail <ali1234> wondering if it's worth it... <ali1234> luckily all this stuff is BSD licensed :) <ali1234> or was it MIT, i forget <bschaefer> well the lease you could do is run down where ogre calls any x11 functions <bschaefer> you would hope that if you are using SDL2 to get the context (and set up the native handling) that ogre would leave all that alone <bschaefer> and let SDL2 handle that <bschaefer> if thats the case it'll work just fine <ali1234> CMake/Packages/FindOpenGLES.cmake: # On Unix OpenGL most certainly always requires X11. <ali1234> :( <bschaefer> :(, thats one assumption that has caused a lot of pain <ali1234> on a related note, the oculus rift devkit relies on X11 and Xinerama as well <bschaefer> to bad they just don't all build a layer ontop of SDL2 and leave all the native window handling to it... <ali1234> well ogre is a lot older than SDL2... SDL1 has no windowing support <bschaefer> right <bschaefer> i forgot how new SDL2 really is :) #ubuntu-mir 2014-02-05 <anpok> alan_g: regarding the include "../lttng/*_report.h" - i could move the code from logging/default_configuration.cpp to src/server/default_server_configuration.cpp <alan_g> anpok: it would still be a cross-component include <alan_g> I've not had a serious think about what the dependencies should be - but I'm tempted by the idea of putting all the reporting options together (that needs a few renames) <anpok> as in putting lttng and logging together? <anpok> or moving them into a report/lttng report/logging structure? <anpok> the only reason we need that is that because whe have to provide a the_..._report() method <anpok> if we could split that one up, we would never have to care about it <anpok> I thought about reigstering the different types somewhere <alan_g> anpok: True - there could be lttng and log report factories <anpok> or we could use something generic like: http://code.google.com/p/hypodermic <alan_g> alf_: opinion? ^^ <anpok> that would dissolve most of default_configuration <anpok> we could wire the program_options with that one - or something like that - havent looked on what it needs and how it is done <alan_g> I'm not sure we need anything that generic <alf_> alan_g: looking <alan_g> Just "return LttngReportBuilder(...).foo_report();" <anpok> it would be the_foo_report() { return container.create<FooReport>() } and inside lttng/default_configuration.cpp 33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abregister_types() { if (get_option("foo-report" == "lttng") { container.register<Foo,LttngFoo>() } <anpok> +Report two times <alf_> alan_g: anpok: (I am not sure if this is what Alan meant) how about the_foo_report() { if (lttng) the_lttng_builder().foo_report(); else the_logging_builder().foo_report(); } <alan_g> alf_: I meant the_foo_report() { if (lttng) LttngBuilder().foo_report(); else LoggingBuilder(the_log()).foo_report(); } <alf_> alan_g: anpok: that being said, lttng and logging are kind of reports so I would be ok with a report/lttng,report/logging structure <alan_g> Agreed <anpok> the generic approach above could also make our live simpler in other cases... i.e. image adding a constructor parameter somewhere, because we factor out functionality. with types registered like above, and compile time information on constructor signature, the change might not have cause further changes in test cases.. <alan_g> I've used IOC containers in other languages and understand the attraction (and the problems). And I do realize that that we're on that road with DefaultServerConfiguration. I just don't think it is quite that simple to drop it in. <anpok> yes. <alan_g> Hmm. Why can't I find "googl33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abprotobu33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abGoogleOnceInitImpl(int*, googl33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abprotobu33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abClosure*)" on the N10 today? <anpok> .. so what would be a good intermediate solution. <anpok> reshuffling into another container - would that also add a namespace? <anpok> s/container/folder <alan_g> What I suggested above? a public class lttng33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abReportFactory { shared_ptr<FooReport> foo_report() const; } in the lttng namespace that can be used by any component. <anpok> ok then agreed <alan_g> alf_: ? <alf_> alan_g: anpok: Why not hide that behind and interface and expose it through the_lttng_report_factory? <alan_g> It doesn't introduce another factory function into DefaultServerConfiguration - just gets used in the implementation. * alan_g powers up N4 to see if that works any better <alf_> alan_g: anpok: But it does introduce a potential "hidden" dependency between lttng and other components <alf_> alan_g: anpok: I think that for our current purposes the report/lttng,report/logging structure would be more straightforward <alan_g> alf_: isn't that orthogonal? <alan_g> I mean something needs to provide assess to private report implementations in report/lttng and report/logging <alan_g> *access <alf_> alan_g: anpok: If it's available only for internal (subcomponent) access, I am OK, but we could just use the internal subcomponent classes directly. However, I got the feeling that lttng33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abReportFactory was going to be public for *all* components to use. <alf_> (not that they would have much reason too) <alf_> s/too/to <alan_g> alf_: we only have "public" and "component private" so yes, it was going to be public <alan_g> alf_: @"but we could just use the internal subcomponent classes directly." that isn't how I've understood our rules <alan_g> Otherwise default_server_configuration.cpp could just access everyone's privates <alf_> alan_g: then perhaps subcomponent is not the right word. In my mind the lttng and logging are implementation details of report in this case, placed in separate internal directories. <alan_g> whereas I would give the classes prefixes and put them all in report <alf_> alan_g: That's an implementation detail ;) <alan_g> anpok: have you decided we're mad yet? <alan_g> alf_: did you get stuff working on android? Today I find that I've got an unresolved protobuf symbol when I try to run things <alf_> alan_g: haven't tried today, but it was working yesterday <alan_g> alf_: thanks <alan_g> \o/ zapping everything in sight and starting over worked <dandrader> alan_g, so mirclient doesn't install include/client/mir/*, just include/client/mir_toolkit/*. Because if that a libmirclient user cannot #include <mir/client/private.h> which is needed for the "custom RPC over mir socket" story <dandrader> s/if that/of that <alan_g> dandrader: I understand the problem. Not sure of the best solution - thinking... <alan_g> dandrader: yes. Adding that directory to include/mirclient seems to be the best answer. Want to log a bug for me to fix? <dandrader> alan_g, sure <dandrader> alan_g, https://bugs.launchpad.net/mir/+bug/1276565 <ubot5> Launchpad bug 1276565 in Mir "libmirclient user cannot "#include <mir/client/private.h>"" [Undecided,New] <alan_g> dandrader: thanks. Am on it <anpok> alan_g: was preparing lunch <anpok> alan_g: let me check on madness <anpok> ..processing.. <anpok> i think yes <alan_g> dandrader: https://code.launchpad.net/~alan-griffiths/mir/fix-1276565/+merge/204899 <kgunn> sil2100: i see "problems with unit test" on mir landing...what's up ? <sil2100> kgunn: where? <sil2100> kgunn: are you sure you're looking at the right landing? <kgunn> sil2100: ooo i better look again <kgunn> sorry :) sil2100 * kgunn should really wait for coffee before trying to read stuff <sil2100> kgunn: no problem ;) We need to wait until we are unblocked from the location-service bug before proceeding thouhj <sil2100> *though <mlankhorst> and xorg-server testing was broken anyway due to protobuf abi break :P <dandrader> alan_g|lunch, solve the problem! I would approve it but launchpad seems to be down at the moment. <dandrader> solves <rsalveti> kgunn: alf_: bug 1276621 needs to be fixed as well to enable the android backend by default <ubot5> bug 1276621 in Mir "Android backend unit-tests FTBS on amd64" [Undecided,New] https://launchpad.net/bugs/1276621 <rsalveti> atm I'm just trying to push a custom mir package that defaults to the android backend <anpok> alf_: alan_g whats the idea behind the separation of ServerConfiguration and DefaultServerConfiguration? <anpok> i.e. the_logger is introduced at DSC <alf_> anpok: ServerConfiguration is the interface used by DisplayServer <alan_g> ServerConfiguration is what DisplayServer needs. DefaultServerConfiguration is a default implementation <dandrader> alan_g, protobuf question: do I have to keep my service stub alive until I get a reply from the service? <alan_g> dandrader: yes <dandrader> alan_g, hmm, looks like they're just thin wrappers around the given rpc_channel.... <dandrader> eg: http://paste.ubuntu.com/6879913/ <alan_g> yeah, they are mostly a level of indirection <dandrader> the thing is that by default they delete the channel when you delete the stub <kdub> do we have to ping someone about that protobuf mismatch problem with CI? <alan_g> kdub: no it sorted itself out. <kdub> alan_g, okay, cool <alan_g> Depending what's in your partial chroot and the image you use you may see the same thing (I did). <alan_g> But the latest versions are OK <alan_g> dandrader: they certainly don't separate concerns in a way that feels natural to me. <anpok> whats the legacy of legacy input report? <alan_g> IIRC that's the intercept of the original logging in the android input code <anpok> ok so it is not legacy in itself <alan_g> Well the idea was (is?) that we'd replace it with something better integrated into our reporting <anpok> hm I first thought it was legacy and hence did not do anything about it <anpok> i would first incorporate it into my current rework to not violate component boundaries <anpok> and then in a further step I would turn the log() interface into something more report-like? <alan_g> anpok: I'm not sure that's the best use of time <anpok> further .. as in .. further down the road <anpok> ... not this week <anpok> just stumbled across it since I was able to remove input_report from the public interface entirely <alan_g> :) <greyback> hey folks, I really need a reliable way of getting the PID of a Session <anpok> alan_g: i meant not with this mp <alan_g> greyback: I don't think it is kept after passing to connection_is_allowed() - I guess that's a feature request. <greyback> alan_g: I've logged it anyway, how could I push for it https://bugs.launchpad.net/mir/+bug/1276704 <ubot5> Launchpad bug 1276704 in Mir "Need way of getting PID of Session" [Undecided,New] <greyback> kgunn: could I push for that feature request? The workaround in unity-mir fails in some scenarios and I can't see any way to make it solid without that feature request <alan_g> greyback: that's the way. ;) <greyback> :D <kgunn> alan_g: are you volunteering by speaking :) * alan_g shats up <alan_g> *shuts <kgunn> lol <kgunn> well..you could shat too...but well <alan_g> kgunn: I won't get to it today. But if you want I can look tomorrow. <kgunn> alan_g: thanks...was just looking to see if we had captured that on a bp as well...is it a specific of "cleanly abstract out application logic from the session mediator" <kgunn> greyback: is this for the sidestage flicker ? or some other ? <greyback> kgunn: other problem: rapid launching of apps confuses unity-mir - ppl do that to test mzanetti's work <alan_g> greyback: is it actually the PID you want? Or would it be better to allow you to attach an object to the session when it is authorised? (I'm thinking shared_ptr<void>) <greyback> alan_g: well PID would be easiest. With the latter suggestion, I would create object with PID and probably app_id to attach. It's much of a muchness to me <greyback> (I need PID to verify with upstart the process' app_id) <alan_g> greyback: PID is fine for us - but as I didn't know what you wanted it for I thought you might want something more generic <greyback> alan_g: gotcha. For now, PID is plenty enough. It is so that when a Session starts, I can take the PID and using upstart, match the app_id. #ubuntu-mir 2014-02-06 <sennn> i hope mir not blackscreen on my APU soon... <sennn> issue <sennn> anyone? <sennn> fine... <dandrader> alan_g, finally got custom messages between qt apps and unity8 through mir_socket working :) <alan_g> dandrader: Great! <alan_g> alf_: I've had to update to track changes on devel - could you recheck before I top-approve? https://code.launchpad.net/~alan-griffiths/mir/refactoring-so-SwitchingBundle-can-control-completion-of-client_acquire/+merge/204244 <alf_> alan_g: looking <anpok> ricmm: ping <anpok> alan_g: alf_: it got larger than I thought ~3k loc <alan_g> anpok: what is "it"? <anpok> avoiding includes between subcomponents <anpok> for reports <alan_g> I imagine a lot of that is moves and renames? <alf_> alan_g: looks good <anpok> yes moved header files around.. <alf_> anpok: alan_g: I still think that moving everything into a report(ing) component is the cleanest way to deal with this... <alan_g> "everything"?! Surely just the reports? <alan_g> 8^) <alf_> alan_g: :) <anpok> alf_: i dont disagree, but just moving lttng/ and logging/ was not enough <anpok> we had a lot of report related stuff cluttered in other places too <anpok> == should be simpler now <alan_g> I wouldn't expect "a lot of report related stuff cluttered in other places too" - what's that? <anpok> alan_g|lunch: hm probably not a lot of .. just a few report logging implementations being provided within the components itself, and accessing component internals.. <xnox> Yo =) ! <xnox> i've installed mirout on my device <xnox> and when i do "mirout" via adb shell I get <xnox> "Could not connect to a display server." <ricmm> anpok: hi <anpok> ricmm: hi -> look at #mir <sil2100> om26er: hi! <om26er> sil2100, hello <chrisccoulson> kgunn, so, I ran this in gdb, and ua_ui_display_get_native_type seems to return NULL (which I verified by setting a breakpoint on eglGetDisplay) <chrisccoulson> i'm just a bit unsure whether this is actually expected, seeing as apps seem to work <kgunn> chrisccoulson: sorry...got interrupted... <kgunn> you were saying "remember what we talked about yesterday? (me wanting to get a valid display handle in oxide that I can pass to chromium for creating EGL contexts)" <kgunn> and "so, this is what I implemented: http://paste.ubuntu.com/6885671/" <chrisccoulson> kgunn, sorry, xchat crashed there <chrisccoulson> ok, so i still get a null display handle, but now i'm not sure if this is actually the expected behaviour, seeing as things seem to work <chrisccoulson> kgunn, i just ran qmlscene in gdb, and set breakpoints on eglGetDisplay and eglCreateContext, both of which seem to succeed, and this is what I see: http://paste.ubuntu.com/6885692/ <kgunn> chrisccoulson: i'll admit i'm not as familiar with the upper stack...but do i read it right that the display id in the qmlscene is null as well? <chrisccoulson> kgunn, that's right. we get a null handle from ua_ui_display_get_native_type(), which gets passed to eglGetDisplay and somehow magically works <kgunn> chrisccoulson: so...wondering...shouldn't papi be taking care of all this egl shennanigans ? <kgunn> (which is maybe why it works) <kgunn> again i'm not as familiar... <chrisccoulson> kgunn, papi? <kgunn> chrisccoulson: platform api...which in turn is talking to mir <chrisccoulson> aha :) <kgunn> chrisccoulson: so i'm just spit-balling...but wondering if maybe, you can ask for egldpy id, but in the end it kind of ignores you and just takes care of some of the binding under the hood ? * kgunn starts to root around in platform-api <kgunn> chrisccoulson: ...right, cause ua_ui_display_get_native_type() is actually from the platform-api i/f <kgunn> ricmm: is it normal for an app that might query ua_ui_display_get_native_type() to get null back ?? but still operate ? <chrisccoulson> kgunn, the other thing - even with a valid display handle, libhybris seems to actually ignore it - http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/libhybris/trusty/view/head:/hybris/egl/egl.c#L173 <chrisccoulson> (it passes EGL_DEFAULT_DISPLAY rather than the actual handle) <kgunn> chrisccoulson: true...(altho you could get a egl no display return if hybris ws considers it invalid...) <ricmm> kgunn: so that call is pretty transparent, it translates directly to mir_connection_get_egl_native_display() <ricmm> so whatever is coming from there, you get <ricmm> which ultimately will wrap hybris' EGL <chrisccoulson> ok, so it seems like what I'm seeing is actually pretty normal <chrisccoulson> so this could be a red herring wrt my original problem <chrisccoulson> kgunn, ricmm, so, IIUC, MirConnection33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abgl_native_display() will always return EGL_DEFAULT_DISPLAY on the device? <kgunn> certainly appears so <chrisccoulson> kgunn, ok, thanks. so i have another issue then <chrisccoulson> there are some android specific egl bits in chromium, i wonder whether we should actually be turning these on <kgunn> chrisccoulson: it would depend, but quite possibly that may be required... <kgunn> this is on n4 right ? <kdub_> alan_g, with this failure: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-builder-trusty-armhf/402/console <kdub_> for CI on ~alan-griffiths/mir/fix-1276565 * alan_g looks... <kdub_> did you figure out what was happening on the builder? i see something similar on one of my branches <alan_g> kdub: no. But I got the impression that everything was very slow yesterday <kdub_> alan_g, okay, thanks <mhall119> kgunn: are there any docs for the mir screencasting feature? <kgunn> mhall119: nope <mhall119> :( <mhall119> is there a way to start/stop it from the commandline? <mhall119> like phablet-screenshot? <kgunn> its not even in archive yet <kgunn> right now its just an api on mir for a server to hook into <kgunn> its not intended to be something used arbitrarily <kgunn> or i guess i should say "server side aware obj: <kgunn> so like...shell will do something for AP testing... <kgunn> and if you wanted apps to be able to utilize this...we'd have to talk to ricmm about how to expose that out to app world in a trusted manner <mhall119> kgunn: I've been tasked with automating the creation of walk-thru videos with autopilot and screen recording, would it be possible for me to use whatever you're using to accomplish that? <mhall119> this doesn't need to be in an app, it can be something I launch from the terminal via adb, or however else <kgunn> mhall119: ah...yeah...likely <kgunn> so, if you're wanting to do something quicker than later....you could use unity8 on desktop that would rely on mir <kgunn> as you'd have a mouse <kgunn> otherwise...not sure what visual queue you'd have for pointer <kgunn> unless AP has some toggle to turn on a visual? <kgunn> also...we've got one bug on desktop in mesa we think we've solve...whereas on android we're running into a driver issue <kgunn> for which we don't have code yadda yadda <mhall119> kgunn: what do you mean I'd have a mouse? <mhall119> I thought unity8+mir on desktop didn't have non-touch input devices working yet <kgunn> mhall119: oh no...i think its _some_ <mhall119> my plan was to have Autopilot dump a log of events and x,y coordinate for them, then programatically over-lay some visual on the video in post-production <kgunn> like some specific hw bewteen certain years <kgunn> mhall119: oh ok...sounds cool <mhall119> bregma: kgunn: so will the Unity8+Mir desktop session preview still happen for 14.04, with enough input device support to actually use it? <bregma> mhall119, that's the aim... I already have enough devices :) <bregma> it really just needs cursor-relative device support and improved out-of-box touchscreen device recognition <bregma> keyboard works OK at the Mir level, but there are no keyboard shortcuts in the shell <bregma> mouse and trackpad are a problem because there's no cursor, could be a configuration problem? <anpok> greyback: any clue why we would permanently recomposit everything when the launcher is displayed? <greyback> anpok: not off hand, lemme see what unity8 is doing.. <greyback> anpok: well I checked in case unity8 was continually rendering with the launcher open, but no. As a result, I've no idea why compositing hasn't stopped <greyback> anpok: I used "QML_RENDER_TIMING=1" to find out by the way, it prints frame stats for each frame <anpok> ah so it does not render <anpok> how is the fading of the phone shell implemented? <anpok> hm alpha value? <greyback> yeah, t draws black rectangle with alpha on top of app surface <bregma> so, I grabbed the latest Mir 0.1.4 source package from Ubuntu and built it in a clean pbuilder (OK), then pushed it to a PPA where it failed on every single udev test ... has anyone else seen that, and is there a workaround? <anpok> bregma: did you run make test? <bregma> I ran dput -- it's a PPA and it's a source package from Ubuntu <anpok> greyback: hm worst case is now three blended buffers, i.e. if you launched camera, then some app .. then it will render Cam|APP|Phone Shell <anpok> because camera has larger buffer.. <anpok> bregma: it sounds like tests being run without libumockdev <bregma> anpok, that would mean the package is broken <bregma> nope mir-0.1.4 build-depends on lubumockdev-dev, and it _did_ pass the tests in a pbuilder chroot, it only fails in a PPA sbuilder <anpok> is a libumockdev-preload.so accessible there? maybe there is an error message comaplaining about not being able to preload the library? <bregma> every unit test fails with "libudev: udev_monitor_new_from_netlink_fd: error getting socket: Invalid argument" <greyback> anpok: sounds good to me! #ubuntu-mir 2014-02-07 <RAOF> Hm. When I'm blowing up code in 3rd_party I should probably move it under src/ shouldn't I. <kdub_> RAOF, tough call <RAOF> Oh, *that's* why you don't move anything from 3rd_party to src/ <RAOF> It doesn't compile, because it generates hundreds of warning from ten or more different constructs. Hurray! <RAOF> âI killed him, cha cha chaâ <RAOF> Alright. That's EOW for me. See yall Tuesday! <anpok_> alf_: would moving null, logging and lttng into report also imply that as another namespace level <anpok_> alf_: good morning <alf_> anpok_: good morning :) I would imagine something like mir33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abreport in which null,logging,lttng implementation are all implementation details <alf_> anpok_: but not necessarily <anpok_> hi alan_g <alan_g> anpok_: ho <anpok_> alf_: implementation details - as there are no public headers? or no further namespaces? <alan_g> as in not needed by users of the class <anpok_> sure we will get there.. <anpok_> just wanted to be sure about the details <alf_> anpok_: primarily the first, but also the second i.e., mir/report/default_configuration.cpp would implement all the_*_report() methods using class internal to the reporting component (logging, lttng) <anpok_> ah ok, I can see why, so all dependencies are in one direction.. <alan_g> alf_: anpok_ any opinions? https://code.launchpad.net/~alan-griffiths/mir/SwitchingBundle-controls-completion-of-client_acquire-without-blocking/+merge/204294 <alf_> alan_g: looking <anpok_> i am a bit puzzled by having multiple compositors <anpok_> what would happen if we turn one screen off <anpok_> i mean we have one compositor per output? <greyback> alan_g: will you have a chance to look at bug 1276704 any time soon? <ubot5> bug 1276704 in Mir "Need way of getting PID of Session" [Undecided,New] https://launchpad.net/bugs/1276704 <alan_g> greyback: I've just put it on today's list <greyback> alan_g: thanks <alf_> anpok_: we have multiple compositors (running in different threads) because 1. each output is backed by a different framebuffer that we need to draw to (exception: clone mode) 2. outputs have different vsync rates and vsync start offsets <anpok_> but when one compositor is stopped it will release all buffers? <anpok_> btw will you kill me for having mrn and mrl (mir33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abreport33ec:265c:71fe:e26d:2682:4ec2:aaa1:99ablogging? <alf_> anpok_: we have one MultiThreadedCompositor that coordinates composition on all outputs, and each output is then handled by a (Default)DisplayBufferCompositor instance <alf_> anpok_: so which compositor are you referring to? :) <anpok_> alf_: ok puzzle solved <anpok_> it happens through the temporary compositor buffer being consumed as a shared ptr for the short time during composition <alf_> anpok_: @mrn,mrl, I don't mind as long as they are internal to report (although Alan may not share this preference?) <alan_g> Does "internal to report" mean in the same src directory? <anpok_> no in another directory underneath <anpok_> i just moved everthing below report <anpok_> yeah this time everything <anpok_> only lttng logging and null_* <alf_> rsalveti: Hi! I was thinking, for the dynamic backends, do you need runtime selection or package time selection (e.g., have a libmirplatformandroid and libmirplatformmesa that both provide libmirplatform)? <alf_> rsalveti: (runtime selection = being able to install both libmirplatformandroid and libmirplatformmesa at the same time and select the actual library at runtime) <rsalveti> alf_: any would do for now (as we have different seeds for desktop and touch), but later on it might be good to do that in runtime <rsalveti> in case someone installs the android one, and ends up breaking his desktop <alf_> rsalveti: the difference in mir code is minimal (since we will load server/clients backends at runtime), it's more of a packaging decision <rsalveti> ogra_: what do you think^? <alan_g> alf_: in case you've not noticed - there's still a little android/mesa code in frontend (chosen at build time). <rsalveti> ogra_: I don't think we have an official way yet to decide if we're in desktop or touch during runtime <alf_> alan_g: thanks, there is also a lot of code on the client that is chosen at build time :) (I am fixing both) <alan_g> :) * ogra_ reads <ogra_> no, we dont have such a way *yet* but we will need one in the future ... for the time being selection via seeds will be fine <ogra_> as long as we dont tie us in with that for the future (i.e. if it still stays an easy switch i guess it is fine to re-visit in 15.04 or 15.10, whatever will have the merged seeds) <kgunn> rsalveti: atm isn't there at least some android version/value that can be interrogated ? <kgunn> e.g. we have hwc1.0, 1.1 as well...and if no android present you're on desktop...couldn't that be the logic ? <kgunn> alf_: ^ <alf_> kgunn: probably <alan_g> greyback: https://code.launchpad.net/~alan-griffiths/mir/fix-1276704/+merge/205357 <greyback> alan_g: nice, thank you <alf_> rsalveti: is the fix for bug 127662 enough to unblock you until we get dynamic backends? <ubot5> bug 127662 in x11-xserver-utils (Ubuntu) "Removing insecure xhost package removes entire X server" [Medium,Expired] https://launchpad.net/bugs/127662 <alf_> rsalveti: hmm, bug 1276621 <ubot5> bug 1276621 in mir (Ubuntu) "Android backend unit-tests FTBS on amd64" [Undecided,New] https://launchpad.net/bugs/1276621 <anpok|lunch> alf_: alan_g: I need a name - a factory that creates reports based on the program options / server options .. <rsalveti> alf_: yeah, trying that today <rsalveti> alf_: ogra_: but it should just be easier for now to have a separated package <rsalveti> and we can land it faster as well <alf_> rsalveti: sure <alf_> anpok|lunch: ReportFactory ? <alan_g> I understand the reluctance to use "Factory" - if there's something less generic than a pattern name it should be preferred <alan_g> is this an function, a class interface, an implementation, ...? <alan_g> *a function <ogra_> yeah, shiny is for later :) <anpok|lunch> alf_: thats the interface <anpok|lunch> alan_g: it is just an aggregation of three of those implementations .. for null reports logging and lttng.. <anpok|lunch> it just delegates to the real ones .. <alan_g> Then surely the interface is AbstractFactory? * alan_g winces <alan_g> ReportSelector? <anpok> yes that would be fine for me, but thats like the generic version of the "er"-rule for turning verbs into nouns <anpok> but since you proposed it, the rule cannot be applied by yourself <anpok> oh... thank you! <anpok> that thing does not need to implement the factory interface. <alf_> kdub: Is mg33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abFBTargetLayerList33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abreset_composition_layers() going to be generally useful in the future? It's only used in the tests right now. <alan_g> kgunn: looks like you're getting ready to land stuff. I think greyback would like this included if it gets reviewed: https://code.launchpad.net/~alan-griffiths/mir/fix-1276704/+merge/205357 <greyback> kgunn: that I would, but landing it will demand a unity-mir rebuild since it changes server API <anpok> alan_g: still there? <bregma> hey guys, I'm trying to run Unity8 on the desktop and I don't have any kind of cursor anywhere ... is there something I need to do in Mir or is it the shell layer that's expected to handle that in software now? #ubuntu-mir 2014-02-10 <RAOF> bregma: https://bugs.launchpad.net/mir/+bug/1206780 and https://bugs.launchpad.net/mir/+bug/1216515 are probably part of your problem. <ubot5> Launchpad bug 1206780 in Mir "[enhancement] Clients cannot change the hardware cursor" [Low,Triaged] <ubot5> Launchpad bug 1216515 in Mir "[multimonitor] Mir's hardware cursor often becomes invisible on one monitor" [Medium,Triaged] <anpok> alf_: the diff is about 7000 loc <anpok> didnt we recently have an issue with unresolved symbol eglCreateImageKHR in unit tests? <alf_> anpok: which diff? <anpok> alf_: report namespace and hidding report implementations <alf_> anpok: I vaguely remember that we used the symbol directly instead of getting it through eglGetProcAddress <alf_> anpok: @7000 line diff, is there a way you can split it up? Do the 7000 lines include moves of files? <anpok> moves of files, and splitting of files <anpok> and lots of trivial renames <anpok> lick NullFooReport null33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abooReport .. <anpok> like <anpok> alf_: we still do that in tests/unit-tests/graphics/test_graphics_platform.cpp or I <alf_> anpok: right, that's wrong... the extensions are already correctly set-up in mock_egl.cpp <alf_> anpok: we can just remove the ON_CALLs from test_graphics_platform <anpok> yes, curious why it did not fail before - or in all current mps <alf_> anpok: possibly the specific egl functions where not even called in those tests <Nothing_Much> How is a Radeon Xpress 200 on XMir or Mir whichever? <Nothing_Much> Anyone? <anpok> Nothing_Much: just try it. You will need the mesa based radeon driver instead of fglrx <Nothing_Much> I just did, but I can't get XMir to work <Nothing_Much> (I'm on an old Radeon Xpress 200) <dandrader> https://bugs.launchpad.net/mir/+bug/1276162 says it's been released on Mir 0.1.5, But lp:mir and lp/ubuntu/mir has 0.1.4. Where is 0.1.5? <ubot5> Error: Could not gather data from Launchpad for bug #1276162 (https://launchpad.net/bugs/1276162). The error has been logged <xnox> ricmm: heya! i've tried to use mirout utility on grouper and it says that it couldn't connect to server. <xnox> ricmm: how / under what environment should mirout be running? <rsalveti> alf_: hey, were you able to split the backends into different packages already? <rsalveti> just want to know if you already got it done somehow, so I can better plan the landing for it <alf_> rsalveti: I am working on it, not ready yet. My plan is to provide package that use dpkg alternatives for the defaults, e.g., /usr/lib/../libmirplatformgraphics.so will point to either android or mesa shared object. You can also use a particular backend by explicitly setting environment variables. <alf_> rsalveti: How does that sound? <rsalveti> alf_: looks good <rsalveti> let me know once you get a mr for it <alf_> rsalveti: ok <anpok> dandrader: there seems to be a tag but the branch has not been merged to lp:mir.. <anpok> reviwe is ongoing <dandrader> anpok, ended up finding this branch https://code.launchpad.net/~mir-team/mir/trunk-0.1.5 <dandrader> so I suppose it will be put to trunk is smoke tests on it go well.... <dandrader> s/is/if <kgunn> dandrader: eventually <kgunn> process is log jammed <kgunn> .............again <kgunn> so yeah, i may even pull in additional changes on top of that mp...if time drags on <kgunn> e.g. pull in newer dev-branch changes <anpok> kdub: https://code.launchpad.net/~kdub/mir/hwc-layerlist-improvements/+merge/204789/comments/481336 -- sorry for taking so long.. <kdub> anpok, that line (59 in hwc layerlist) will just close the fd, all that's really changed on that line is the indentation <anpok> yeah I expected more magic to happen there <anpok> the other class does not need to close the fd? <anpok> kdub: HwcFbDevice? <kdub> that one relies on the fb device, so I don't see those drivers using t he fence, <kdub> thanks anpok #ubuntu-mir 2014-02-11 <kdub> thanks for the review duflu <duflu> kdub: I don't claim to have tested it, but I support the idea :) <RAOF> Oh, wow. <RAOF> bzr merge -i --uncommitted works exactly like how I want it to work. <mlankhorst> morning <anpok_> alan_g: duflu alf_: which direction should i go now.. <anpok_> keep report33ec:265c:71fe:e26d:2682:4ec2:aaa1:99ab, but drop lttng33ec:265c:71fe:e26d:2682:4ec2:aaa1:99ab and report33ec:265c:71fe:e26d:2682:4ec2:aaa1:99ablogging? <duflu> anpok_: Ever forward... ?! <duflu> Oh <duflu> anpok_: I prefer the namespaces how they are today. And would prefer even more if we had fewer than that. So abstain * duflu -> dinner <duflu> Good night <alf_> duflu: bye! <alan_g> Bye <greyback> AlbertA: hey, quick comment on https://code.launchpad.net/~albaguirre/unity-mir/cross-compile-link-fix/+merge/205690 <anpok> alan_g: alf_: ... 200 lines less <AlbertA> greyback: at least the mirserver library <AlbertA> should be there <AlbertA> as it's a direct dependency - it makes sure the api signatures haven't changed <alan_g> anpok: It isn't the number of lines in the diff that matters. It is how easy it is to follow. <AlbertA> greyback: Or not sure if you mean to use only the _LDFLAGS? <greyback> AlbertA: yeah that was what I was asking. I was pouring over cmake manual to understand the difference <greyback> AlbertA: _LIBRARIES seems to not set the -L path, which -LDFLAGS definitely does <AlbertA> greyback: the LDFLAGS for those 3 packages at least just return -L path <AlbertA> and the libraries flag sets -l<libname> <greyback> AlbertA: http://www.cmake.org/cmake/help/v2.8.12/cmake.html <- searching for "_LDFLAGS" was what I was reading. I'm surprised now <greyback> as it implies LDFLAGS contains all required linker flags (which I'd expect), whereas LIBRARIES contains list of lib names that need their pkgconfig scanned for linker flags <greyback> do I mis-understand? <anpok> greyback: the cmake pkg-config module creates a load of variables for each found library <AlbertA> greyback: that's what I read too <anpok> there is for example also PKG_NAME_LIBRARY_DIRS <AlbertA> greyback: but it's essentially the output of pkg-config <anpok> and that one could be used in link_directories() which is just symetric to include_directories() <greyback> AlbertA: right <greyback> So I guess I'm confused :) * greyback needs to dig a little more <anpok> i.e. look inside CMakeCache.txt of your build dir.. <greyback> anpok: yeah I've been doing that, to check AlbertA's patch did what I expected, but now I'm unclear what's really happening <greyback> mterry: comment on https://code.launchpad.net/~mterry/unity-mir/alpha-greeter/+merge/204069 <mterry> greyback, noted. I tested on android and it worked! So apply_to must be doing something currently... <greyback> mterry: nested in android? Or standalone? <mterry> greyback, testing yourself is a little tricky. You'd need to install several branches to see the difference, but will add to MP <mterry> greyback, nested <mterry> greyback, oh, you say that <greyback> mterry: yeah, that I expect to be ok. Just standalone I found apply_to wasn't being called <mterry> greyback, fair. Though I don't happen to care about standalone case <greyback> mterry: yep <greyback> mterry: but I did for a while :) <mterry> greyback, :) hey, how is the scenegraph stuff going, btw? <greyback> mterry: oh I've not been able to touch it for weeks now. Hope to resume it after MWC. racarr is doing some Mir adjustments to help integrate it however <mterry> greyback, cool. Poke me when it is more play-with-able. I eventually plan to use it in the USC for interstitial animations between sessions * mterry heads out to buy a ladder <greyback> mterry: really? Ok. /me thinks we'd better profile it carefully before nesting it like that <AlbertA> greyback: you were right <AlbertA> greyback: we only need LDFLAGS <AlbertA> greyback: it does include everything like the docs say :) <AlbertA> greyback: i.e. -L<path>;-l<libname> <greyback> AlbertA: but I just tried compiling without LIBRARIES and it failed to link to mir! <AlbertA> greyback: really? I tried here just using LDFLAGS it worked ok on both <AlbertA> native and cross compiling <greyback> let me try again, maybe I screwed something up <greyback> AlbertA: you're correct, it works with just LDFLAGS <AlbertA> I pushed a new revision <AlbertA> to the branch <greyback> AlbertA: and approved as it's exactly what I now have. Thank you! <AlbertA> greyback: thanks! <RAOF> anpok: It's not clear to me why logging33ec:265c:71fe:e26d:2682:4ec2:aaa1:99ab should be under report33ec:265c:71fe:e26d:2682:4ec2:aaa1:99ab, as they're kinda two separate things. Not doing that move also reduces the namespace nesting somewhat. #ubuntu-mir 2014-02-12 <anpok_> RAOF: logging33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abLogger and related went back to logging ... only report implementations are inside report now <anpok_> RAOF: report exists only to have a place for report_factory and a place to know which report implementations exist.. so we could also not have report33ec:265c:71fe:e26d:2682:4ec2:aaa1:99ablttng report33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abnull.. but then we would end up having either one directory with 3 * 2 * n + n classes and three or one static libraries built and a shared library for lttng or three directories that do not add a namespace.. <anpok_> s/classes/files <anpok_> n is 6 now <alan_g> duflu: have you had time for more thoughts on https://code.launchpad.net/~alan-griffiths/mir/SwitchingBundle-controls-completion-of-client_acquire-without-blocking/+merge/205568? <duflu> alan_g: On a hangout <alan_g> np <RAOF> anpok: I don't think I'd object to three directories that don't add a namespace :) <anpok> RAOF: hm you only see the other namespaces in test cases when the null reports are used.. <anpok> i could get those cases away too <anpok> i mean with something like .. NullReportFactory().create_what_needed() .. <RAOF> Hm. That looks sensible at a first glance. <duflu> alan_g: The answer is no BTW, I haven't thought about emily84@example.com. Consider that "Abstain" for now <alan_g> duflu: OK. (It's just that I'd like as many good eyes as possible on that bit of code.) <duflu> Yeah, agreed <duflu> But instead, dinner! <alan_g> Enjoy! <alf_> alan_g: anpok: RAOF: at the moment our unit tests for the armhf native CI build run with valgrind, but we completely ignore valgrind errors... I wonder if there is a benefit in running them with valgrind at all at the moment. The only I can think of is the difference in timing that running under valgrind brings, and which may expose races (but then again the different timing may hide races too) <RAOF> I thought valgrind was super-flaky on armhf? <alan_g> So did I <RAOF> As in: I didn't know the unit tests wouldn't SIGILL under valgrind on armhf :) <alan_g> If valgrind can produce meaningful
{'channel': 'ubuntu-mir', 'month': 2}