[00:27] <RAOF> WOOO! Party at racarr__'s place!
[01:25] <racarr__> RAOF: WOOOO. CHROMIUM ALL NIGHT
[01:25] <racarr__> haha not really im almost done
[01:26] <racarr__> then sometime tonight ill remove all the like // TODO: Lol comments from xmir-input.c and send it yo you on github
[01:26] <racarr__> RAOF: I am not sure exactly what we should do with it...
[01:26] <racarr__> for the case of a single keyboard and mouse I mean it seems
[01:27] <racarr__> really good
[01:27] <racarr__> but I guess it breaks everything else
[01:30] <RAOF> I'll block some time out to merge it and clean up the rest of xmir.
[01:31] <RAOF> It shouldn't be too hard to do in such a way that it doesn't break everything else :)
[05:41] <duflu> Ah so many code reviews, so few years in human life
[05:41] <duflu> Where's skynet when you need it?
[06:33] <duflu> That's odd. How does an 84 line test program that's dynamically linked produce an executable of 2269640 bytes?
[07:05] <RAOF> Template expansion, debugging symbols? :)
[07:13] <duflu> RAOF: Yeah I excluded debugging symbols and it's still big. Templates are the prime suspect(s)
[07:15] <duflu> Heh. Pick the C++ program from the C programs:
[07:15] <duflu> -rwxrwxr-x 1 dan dan     19135 Apr 30 15:02 mirout
[07:15] <duflu> -rwxrwxr-x 1 dan dan     18080 Apr 30 15:02 mirping
[07:15] <duflu> -rwxrwxr-x 1 dan dan   1630369 Apr 30 15:02 mirscreencast
[07:27] <RAOF> :)
[07:42] <RAOF> Hey, mpt! Up early?
[07:43] <mpt> RAOF, I usually start at 8am. I was a little late today because the subway workers are striking.
[07:43] <RAOF> Ah. BST is in effect.
[07:45] <mpt> Indeed
[07:46] <RAOF> I wonder how much https://wiki.ubuntu.com/AccountPrivileges should change, if at all, given that we restrict screenshots and can do funky things with fullscreen windows.
[07:47] <RAOF> Although I don't particularly want to add anything to what I'm sure is a huge backlog of things requiring thought.
[08:21] <anpok> are there other reasons than lack of existance, why the mi::EventFilter interface is used by the nested platform?
[08:22] <anpok> - i mean we could now remove that indirection and just pass the events to the mi::InputDispatcher which has more or less the same interface
[08:29] <duflu> anpok: The filter is an important interface the server/shells will override. So although it looks unused it probably is used very much in real servers
[08:31] <anpok> sure
[08:32] <anpok> thats not what I wanted to change
[08:32] <anpok> the event filter interface is just also used in the nested output - while the composite event filter is used by the dispatcher
[08:32] <RAOF> I don't think there's any particular reason not to send nested events through the InputDispatcher; I think I'd prefer to send them through the _full_ input stack, with a Nested input driver (if that ends up being reasonable)
[08:33] <anpok> so we have nestedoutput -> input_relay : public EventFilter -> InputDispatcher -> ... which calls another EventFilter while dispatching..
[08:33] <anpok> i believe we just recycled the interface there because there was no mir style InputDispatcher till now..
[08:34] <anpok> duflu: i get different results when I make normal build..
[08:34] <anpok> *a
[08:34] <anpok> nm - will make a separate MP later..
[08:35] <anpok> already enough gore
[08:35] <duflu> anpok: Consider demo-shell. None of the input handling would work at all unless EventFilter is called:
[08:36] <duflu> class WindowManager : public input::EventFilter
[08:36] <anpok> .. and again thats not wht I wanted to change
[08:36] <mpt> RAOF, good question. I’d rather avoid using a full-screen window or a system-modal window for other reasons, even if it isn’t as futile as I thought. :)
[08:36] <duflu> OK
[08:36] <duflu> Cool
[08:36] <anpok> just wanted to get rid of input_relay
[08:44] <RAOF> mpt: Fair enough. We'll probably need to treat those windows specially in some ways, right? In particular, focus probably needs to be treated strictly.
[08:45]  * RAOF is sad that we can't make it system-modal. Then we could display it entirely outside the user's desktop; it's a marvellous technical solution! :)
[08:45]  * mpt has flashbacks to Windows NT asking you to type Ctrl Alt Del to ensure your security
[08:46] <RAOF> It's something we could totally do :)
[08:47] <RAOF> But a SAK is mostly overkill.
[08:47] <duflu> ^ irony anyone?
[08:47] <mpt> RAOF, sure, maybe we could dial down the probability of focus stealing when that window is up. But to keep perspective, we don’t do that for browser windows on HTTPS pages containing probably-more-important password fields.
[08:48] <RAOF> ...which will mostly be prefilled by the browser, anyway? :)
[08:48] <RAOF> Anyway, EOD for me now. Thanks, chaps!
[08:50]  * duflu waves to RAOF
[09:52] <duflu> alan_g: Still got plans to unduplicate BasicSurface/Surface ? Or can I assume those classes are more settled now?
[09:55] <alan_g> duflu: I was pretty much done with the surface hierarchy and about to look at other aspects of scene & shell when asked to stop moving stuff. I won't be back to that for a few days anyway as I'm dealing with trust session related changes at the moment.
[09:56] <duflu> alan_g: Well I won't have any related changes ready any time soon either. Just thinking
[09:57] <duflu> alan_g: Good luck with the trust stuff. Last I heard I think we mostly agreed it had no need to be in Mir at all. Although maybe you've found reasons to the contrary. Actually I don't want to know
[09:57]  * alan_g wishes it were that simple
[12:18] <sil2100> kgunn: hello!
[12:20] <sil2100> kgunn: the Mir silo was prepared in the morning, we pressed the build button as well, but it seems there are FTBFS ;/
[12:20] <sil2100> https://launchpad.net/~ci-train-ppa-service/+archive/landing-007/+packages
[12:20] <sil2100> kgunn: could you have someone looking at those?
[12:22] <sil2100> kgunn: the Mir FTBFS seems to be rather trivial
[12:34] <alf_> sil2100: looking
[12:34] <sil2100> alf_: thanks :)
[12:56] <alf_> sil2100: do we need to do something to trigger a rebuild or will a push to the used mir branch be enough?
[12:56] <sil2100> alf_: push to the used branch and I can fire a rebuild :)
[12:57] <kgunn> alf_: sil2100 ...i'm on now...thanks
[12:58] <sil2100> alf_: just give me a sign once it's updated
[12:58] <sil2100> kgunn: o/
[12:59] <alf_> kgunn: do you want me to push to the branch directly or prepare an MP?
[13:00] <alf_> kgunn: (I assume the right branch is ~mir-team/mir/trunk-0.1.9)
[13:01] <kgunn> alf_: its easiest if you just update to the branch directly
[13:02] <kgunn> alf_: i assume you're making a change ? not pulling from a dev-branch rev beyond the tagged rev ?
[13:02] <alf_> kgunn: right a change which I am going to forward-port to devel too (with an MP)
[13:02] <kgunn> alf_: cool, that will work
[13:05] <sil2100> kgunn: will you pick it up from now on? Making sure it builds? :)
[13:05] <kgunn> yes sir! sil2100 thanks
[13:06] <sil2100> kgunn: thanks! I hope to see it ready for releasing later today :D
[13:08] <kgunn> me too!
[13:09] <dandrader> anpok, hey. how is it going with the input changes?
[13:09] <dandrader> I saw the first patch landed
[13:12] <anpok> i am kind of through with cleanups and making the android input dispatcher use the input sender
[13:13] <anpok> but it seems like I broke something in input dispatcher..
[13:15] <anpok> I had to add two futher methods to the mir input dispatcher interface - those are triggers needed by the android input dispatcher - an empty stub should do there
[13:15] <alf_> kgunn: sil2100: pushed change ~mir-team/mir/trunk-0.1.9
[13:15] <sil2100> o/ Thanks
[13:15] <kgunn> alf_: ta...
[17:09] <greyback> fginther: ping
[17:44] <fginther> greyback, pong
[17:46] <greyback> fginther: hey, could you set up CI and autolanding on a few dev branches for me please? lp:unity-mir/devel lp:platform-api/devel
[17:48] <fginther> greyback, sure, lp:unity-mir/devel is already setup
[17:48] <greyback> fginther: oh cool, I'd not noticed
[17:48] <fginther> greyback, let me know if it doesn't appear to be working
[17:48] <greyback> fginther: will do
[17:50] <greyback> fginther: could you also do lp:qtubuntu/devel  please?
[17:51] <fginther> greyback, yes
[17:52] <greyback> fginther: thanks very much!
[17:56] <greyback> fginther: I'd like your opinion on something actually. How possible would it be to create a PPA with the devel branches of mir, platform-api, qtubuntu & unity-mir (hmm, might need USC too) which would rebuild everything any time the devel branch changes?
[17:56] <greyback> it would be good so that if Mir breaks API/ABI, the dependent projects would notice quickly and fix it
[18:01] <fginther> greyback, it's possible to dput changes to a PPA as part of the autolanding jobs...
[18:02] <fginther> but are you asking to rebuild every package in the PPA whenever any MP is merged?
[18:03] <greyback> fginther: kinda yeah :) Well at least if mir changes, the dependents are rebuilt.
[18:06] <fginther> greyback, so we have a way to do that, but it might be a little clunky for what you're trying to do. We can try to set it up this way and see how well it works
[18:07] <fginther> greyback, the idea is that a mir autolanding job would kick off a rebuild job of every dependent project in a specific list of jobs
[18:07] <greyback> fginther: that would do just fine
[18:07] <fginther> and at the end of each job, the PPA would be update
[18:07] <greyback> how do the dependent projects learn if the new mir revision breaks their compilation?
[18:08] <fginther> that's part of the clunky part :-). The notification mechanism is an email that the job failed
[18:08] <greyback> that would do. It's what mail filters are for :)
[18:09] <fginther> it sorta works because these rebuild jobs should never fail. so if it does, it's a strong indication of an abi breakage
[18:09] <greyback> tat's exactly the info we want. This sounds perfect
[18:10] <fginther> ok. I'll first work on add the branches you mentioned and setup the build chain as a second step. Do you already have a PPA for this?
[18:11] <greyback> fginther: great, thank you. No I've no PPA set up, there is https://launchpad.net/~mir-team/+archive/staging but I can't say if being used (doesn't look like it)
[18:11] <greyback> kgunn: can you say^^ ?
[18:25] <slvn_> hello,
[18:26] <slvn_> I develop a native C application, to run on arm UbuntuPhone os
[18:26] <slvn_> I should connect to MIR
[18:26] <slvn_> (through SDL backend)
[18:26] <slvn_> but it can get access to /tmp/mir_socket
[18:27] <slvn_> in other terms,  I try to run "mir_demo_client_eglplasma" from command line (adb shell)
[18:27] <slvn_> and it works
[18:27] <slvn_> but, If I package this "mir_demo_client_eglplasma" into a click package,
[18:28] <slvn_> I get an error : "Can't get connection"
[18:28] <slvn_> Any Idea ?
[18:29] <greyback> slvn_: are you running it with unity8?
[18:30] <slvn_> yes, this is with unity
[18:30] <slvn_> 8
[18:30] <greyback> slvn_: does ~/.local/upstart/unity8.log contain any "REJECTED" messages?
[18:31] <kgunn> greyback: whats the question ? ....staging ppa is something that can be used for just that "staging"
[18:31] <kgunn> so you're welcome to  modify any of the recipes...just put a note in if you do
[18:31] <greyback> kgunn: I just saw other bits & pieces in there and was worried it was for staging other things.
[18:31] <kgunn> we were thinking we might use that for keeping the dev branches building and sane (before ci airline)
[18:31] <kgunn> yeah...but everything is on-demand i believe
[18:31] <kgunn> you should be ok
[18:32] <greyback> kgunn: yes exactly, I'm asking fginther to set up mir/devel, platform-api/devel and others to all build into that staging ppa
[18:32] <kgunn> perfect!!!
[18:32] <kgunn> that's where i wanted it to get to
[18:32] <greyback> great
[18:33] <greyback> fginther:  https://launchpad.net/~mir-team/+archive/staging is a good PPA to use
[18:33] <greyback> thank you!
[18:34] <slvn_> greyback, no "REJECTED" messages in unity8.log but some in  /var/log/syslog :  apparmor="DENIED" operation="connect" parent=11049 profile="com.ubuntu.developer.blabla.myapp2_myapp2_0.912" name="/tmp/mir_socket" pid=11056 comm="mir_demo_client" requested_mask="rw" denied_mask="rw" fsuid=32011 ouid=0
[18:35] <fginther> greyback, ack
[18:35] <greyback> slvn_: oh interesting, appArmor is blocking
[18:35] <slvn_> could I be facing this issue : https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1236912 ?
[18:36] <greyback> slvn_: are you specifying the mir socket?
[18:36] <slvn_> yes,  export MIR_SOCKET=/tmp/mir_socket
[18:37] <greyback> slvn_: I didn't think that was necessary
[18:38] <greyback> but in your click package, that isn't being done, is it?
[18:39] <greyback> I expect "$XDG_RUNTIME_DIR/mir_socket" to be the correct socket your application should connect to
[18:39] <slvn_> greyback,  It is done in my click package. I call a  "sh" script that set the MIR_SOCKET then run "mir_client_eglplasma".
[18:39] <slvn_> i will try
[18:39] <ogra_> that wont work i guess
[18:40] <greyback> slvn_: yes please remove that MIR_SOCKET definition
[18:40] <ogra_> talk to jdstrand on #ubuntu-touch ... i doubt you will be able to access anything in /tmp
[18:40] <greyback> it will be set correctly for apps for you
[18:40] <ogra_> app confinement wont let you
[18:42] <slvn_> wont work
[18:42] <greyback> slvn_: to explain the architecture to you. There is actually 2 mir servers running on your phone. One is unity-system-compositor, which is the system compositor (runs as root, manages user sessions, uses /tml/mir_socket). The other is unity8 itself, which is a user session/nested server (runs as the logged in user, uses socket $XDG_RUNTIME_DIR/mir_socket)
[18:43] <greyback> the unity8 mir server connects to /tmp/mir_socket. It then offers $XDG_RUNTIME_DIR/mir_socket for the user's apps to connect to
[18:44] <greyback> slvn_: please check the output of unity8.log again. I suspect a REJECTED message is there now
[18:46] <slvn_> greyback, ApplicationManager REJECTED connection from app with pid 11371 as no desktop_file_hint specified
[18:46] <greyback> slvn_: yep
[18:47] <greyback> slvn_: you need to get rid of your shell script, and have the "mir_demo_client_eglplasma" run directly
[18:48] <ogra_> that wont still allow access to the socket ... talk to the security team (specifically jdstrand) a confined click app will not be able to access anything on the rootfs by design
[18:49] <greyback> ogra_: he doesn't want to. He was accidentally specifying the wrong mir server socket
[18:49] <greyback> appArmor was doing its job well
[18:49] <ogra_> they only have access to /opt/click.ubuntu..com/$appname and the appdir under ~/.cache
[18:49] <ogra_> ah, k
[18:50] <slvn_> ogra_, greyback,  but maybe I can run the app with the XDG_rUNTIME_DIR/mir_socket ?
[18:50] <kgunn> anpok: is the multiple creation of input dispatcher config also blocking this ....(i mean i would guess so, but just in case ) https://code.launchpad.net/~andreas-pokorny/mir/input-sender-split
[18:51] <greyback> slvn_: that is not necessary, that value is already set by the click script that launches the binary
[18:51] <greyback> slvn_: that unity8.log message tells me the app is connecting to unity8, but unity8 is rejecting it because a shell script is launching the binary
[18:52] <greyback> you need to get rid of that shell script
[18:53] <josharenson> kdub, have a minute to discuss inprocessserver?
[18:53] <kdub> josharenson, I haven't gone and refreshed my memory on that class, but I can see what I remember
[18:53] <josharenson> kdub, I have this http://pastebin.ubuntu.com/7368197/
[18:54] <josharenson> kdub, but same issue as all other menthods I've tried... as soon as the display server stops blocking, glmark2 claims it cannot connect to mir
[18:54] <josharenson> kdub I should mention the class that the code is in extends InProcessServer
[18:55] <kdub> why do mir_connect_sync there?
[18:55] <kdub> glmark-es2-mir should be going and connecting at some point
[18:57] <slvn_> greyback, Ok. I understand now. I need to remove the a.sh, so that the executable is called with the --desktop_hint_file,  But in the otherside I need to specify the mir_socket to XDG. which is then problem !
[18:57] <josharenson> kdub, ah I guess the mir_connect_sync is not needed because run_mir is called from InProcessServer's setup method... but I don't understand when glmark2 is supposed to connect
[18:57] <kdub> well, popen goes and runs the glmark-es2-mir binary, so that's where glmark would connect
[18:58] <greyback> slvn_: but you don't need to specify the mir socket, it is done for you by the click scripts
[18:58] <josharenson> kdub... thought so, and I've looked at the glmark2-es2-mir code and it seems pretty straightforward.... still can't figure out why my hack solution works, and this doesn't
[18:59] <kdub> it might have something to do with that socket negotiation like greyback suggested?
[18:59] <greyback> slvn_: and you don't need the desktop_file_hint parameter either actually. Just the binary name should be enough
[19:00] <slvn_> greyback, yes, that's true :/
[19:00] <josharenson> kdub, ok ill keep looking i guess...
[19:00] <slvn_> greyback, I mean it works. I though I did the test previously
[19:01] <kdub> oh sorry greyback josharenson got my independent convo threads intertwined :)
[19:01] <greyback> np, the joy of IRC :)
[19:01] <kdub> josharenson, we're sure that the socket file is designated correctly on both sides?
[19:02] <greyback> josharenson: if a mir client claims it cannot connect, always check ~/.local/upstart/unity8.log for a "REJECTED" message
[19:02] <josharenson> kdub, I think so.. I've tried piping directly to the socket and no luck
[19:02] <greyback> josharenson: unity8 is very strict on what clients it allows to connect.
[19:03] <josharenson> noted
[19:03] <kdub> josharenson, how would you pipe with glmark2-es2-mir's command line options though
[19:03] <slvn_> greyback, so this works now I see the eglplasma launch from my click package
[19:03] <greyback> slvn_: yay!
[19:03] <slvn_> greyback,  but not my problem with my real app :)
[19:03] <josharenson> I got the name of the socet file and did popen(glmark2 > /tmp/socket)
[19:04] <slvn_> greyback, is that I cannot load the shared libraries !
[19:04] <greyback> slvn_: ah, that's weird. Are they shared libraries part of your click package? Do you get appArmour messages relating to it?
[19:04] <josharenson> brb food
[19:04] <ogra_> you will have to build static ...
[19:05] <greyback> ogra_: really?
[19:05] <ogra_> yes
[19:05] <greyback> eww
[19:05] <ogra_> as i said, no rootfs access unless you use QML/Qt bindings
[19:05] <greyback> slvn_: there's your answer
[19:05] <ogra_> jdstrand probably knows a way around
[19:05] <ogra_> not sure there is one though
[19:06] <slvn_> ogra_, greyback,  but, if I were using the "sh" script I could have defined the LD_LIBRARY_PATH, and that was working ! (but not the mir_socket)
[19:06] <greyback> surely read-only access to the click package directory wouldn't kill anyone
[19:06] <kdub> josharenson, and is "glmark2-es2-mir > /tmp/socket" a way to designate the connection socket?
[19:06] <ogra_> slvn_, right, but your script wants running under confinement i guess ...
[19:06] <ogra_> *wasnt
[19:07] <slvn_> orga_, but it was rejected by mir (not the "sh" script but the executable, i understand correctly)
[19:08] <greyback> slvn_: that surprises me
[19:08] <ogra_> well, i dont know all of the mechanics (which is why i keep referring to jdstrand ;) )
[19:09] <greyback> slvn_: as an experiment, if you could restore your script, where you call your binary, append "--desktop_file_hint=/path/to/your/desktopfile.desktop" and try it
[19:09] <greyback> slvn_: it's a workaround (warning: likely to go away) for unity8 rejecting apps with PIDs it does not expect
[19:09] <slvn_> greyback, I tried :) and I got the "syntax help" of mir_client_eglplasma
[19:10] <greyback> slvn_: ah, try "-- --desktop_file_hint....."
[19:10] <greyback> that's two dashes, and a space, before the rest of it
[19:17] <slvn_> greyback,  I am confused, --desktop_file_hint is not even working on the Exec line.
[19:18] <ogra_> that only works with QML
[19:18] <slvn_> greyback, Exec=mir_demo_client_eglplasma -- --desktop_file_hint=./myapp2.desktop   >>  it displays the help of the problem
[19:18] <ogra_> it is an option qmlscene uses
[19:18] <slvn_> ok, it makes sense
[19:19] <greyback> slvn_: it's not an option for any binary really, it's actually read by unity8. I just need the binary to ignore it :)
[19:19] <greyback> hence the --
[19:21] <slvn_> greyback, ok, anyway ...
[19:25] <slvn_> greyback, ogra_,  so my next trouble is this LD_LIBRARY_PATH that I cannot set, even to current directory. Who could help me about this ?
[19:25] <ogra_> jdstrand ;)
[19:25] <greyback> slvn_: jdstrand :)
[19:25] <ogra_> but i guess his answer will just be "build statically"
[19:26] <ogra_> that you could even run a shellscript is most likely a bug
[19:26] <greyback> static building is kinda lame, but the more people who complain, the more likely we add support for shared libs
[19:27] <ogra_> oyu can indeed ship your own libs inside the click
[19:27] <ogra_> and *then* you can use LD_LIBRARY_PATH pointing to it
[19:28] <slvn_> orgra_, I can build statically this is true ... I have no real anwser to that,  it's a working solution :)
[19:28] <greyback> rpath maybe?
[19:28] <slvn_> ogra_, hmmm say it again. I will ship my own libs !
[19:31] <ogra_> i pinged jamie in #ubuntu-touch ... see if he drops by here
[19:33] <jdstrand> hi
[19:34] <slvn_> hi
[19:34] <slvn_> I have a little problem :)
[19:34] <slvn_> I have build a click package for my ARM (Nexus10) with ubuntu touch
[19:35] <slvn_> I want to run a native C++ application using MIR and using shared library
[19:35] <bschaefer> slvn_, you can always use mir-staging ppa that includes an SDL2 that has mir enabled
[19:35] <slvn_> (Actually the shared library is SDL)
[19:35] <bschaefer> err
[19:35] <bschaefer> but theres that opengl problem atm...
[19:36] <slvn_> yes, that's also true ...
[19:36] <jdstrand> slvn_: have you stated all of the problem?
[19:37] <slvn_> jdstrand, yes. basically the only problem is that I would like to use a shared library in my app
[19:37] <bschaefer> slvn_, or you can just compile/install sdl2 to the default location...
[19:37] <bschaefer> so you don't have to update the LD_LIB path
[19:37] <slvn_> and that I can provide the shared library
[19:38] <jdstrand> slvn_: ok. the library should be usable by your app if it is included in the ubuntu framework you specify
[19:39] <jdstrand> slvn_: (ie, if it is in the framework and not usable, that is a bug)
[19:39] <leitao> what is the plan for Mir on Ubuntu?
[19:39] <jdstrand> slvn_: if it is not part of the framework, you need to ship it in your click package
[19:39] <leitao> I mean, what is the target release to have Mir.
[19:40] <slvn_> jdstrand,  the .so lib in my package.
[19:40] <slvn_> but not accessible
[19:40] <slvn_> unless un do LD_LIBRARY_PATH=.
[19:40] <bschaefer> jdstrand, you should be able to use one of the hard coded *.desktop file though?
[19:40] <bschaefer> so you're not using a click package...
[19:40] <bschaefer> as SDL2 is not in the framework atm
[19:40] <jdstrand> slvn_: yes. LD_LIBRARY_PATH is set for you automatically by upstart-app-launch/aa-exec-click to include $pkgdir/lib/$gnutriplet
[19:41] <jdstrand> where pkgdir is the install directory for that click
[19:41] <jdstrand> bschaefer: I don't understand your question wrt *.desktop. I thought we were talking about click
[19:42] <bschaefer> jdstrand, well, i was trying to help him out using non-click package. Just editing a simple gallery*.deskop yesterday
[19:42] <slvn_> bschaefer :
[19:42] <slvn_> I have build a click package with .desktop .json and manifest
[19:42] <jdstrand> if it is non-click, then just install the sdl libraries via apt and use them
[19:43] <bschaefer> slvn_, unless you want a click app, which is the new in way to package things :)
[19:43] <slvn_> and it works when I specify Exec=mir_demo_client_eglplasma
[19:43] <slvn_> but when I put Exec=a.out it asks for the SDL2.so libs
[19:43] <slvn_> I am in :)
[19:44] <bschaefer> slvn_, right, try installing SDL in the default locations
[19:44] <bschaefer> vs your staging dir
[19:44] <bschaefer> so you don't have to do the LD_LIB
[19:44] <jdstrand> I'm not sure why that would be unless mir_demo_client_eglplasma was staically linked (yet another option for you)
[19:45] <bschaefer> jdstrand, once SDL2 gets added to the framework... things will be easier....
[19:45] <slvn_> what do you mean by "staging dir" ?
[19:45] <jdstrand> yes
[19:45] <bschaefer> slvn_, hmm where do you normally install SDL2?
[19:45] <bschaefer> jdstrand, i've to talk to Saviq about how hard that is, or what that means :)
[19:45] <slvn_> hmm... I compiled the SDL2 with a chroot armhf
[19:46] <slvn_> so no real location..
[19:46] <bschaefer> slvn_, and install the *.deb?
[19:46] <bschaefer> slvn_, as, where do you point LD_LIB?
[19:46] <bschaefer> as you should be attempting to put SDL2 in the default locations of LD_LIB
[19:46] <jdstrand> so, if you are distributing as a click, that implies you want others to use it. you will have to statically link or ship the libs in the click for the app to be usable on other systems (since those won't have sdl2)
[19:46] <bschaefer> so you don't have to specify it
[19:46] <jdstrand> once sdl2 is part of the framework, you won't have to do that
[19:47] <bschaefer> jdstrand, that sounds a loot easier
[19:47] <bschaefer> slvn_, as right now the only way to get your SDL app to run is by specify the LD_LIB path right?
[19:47] <slvn_> mm, I dont really understand. Maybe I dont understand what is click
[19:47] <jdstrand> click has the concept of fat packages-- ie those that can ship binaries/libraries for multiple architectures
[19:47] <slvn_> I want to distribute apps like .apk
[19:48] <jdstrand> right, that is click
[19:48] <slvn_> ok good :)
[19:48] <jdstrand> you upload click apps to the app store and they are available for ubuntu touch users
[19:48] <jdstrand> the ubuntu-sdk is setup to help you with that
[19:48] <bschaefer> i see, yeah im talking about non-click app atm
[19:48] <slvn_> bschaefer, currently there was to solution : use Exec=a.sh  and Exec=a.out
[19:48]  * bschaefer has a very limited understand of unity8
[19:49] <jdstrand> the problem is that you have ventured outside of the framework, so you have some extra things to do
[19:49] <bschaefer> slvn_, i normally stop unity8 and run my own mir server to test SDL apps on arm :)
[19:49] <slvn_> bschaefer, yep, but user wont kill unity8 to run my app :)
[19:49] <bschaefer> slvn_, haha
[19:49] <bschaefer> slvn_, no
[19:50] <slvn_> bschaefer,  Exec=a.sh allows me to set th LD_LIBRARY_PATH, but I get reject by MIR (mir_socket pb)
[19:50] <jdstrand> slvn_: so, you'll need to decide how to deal with sdl2 for your app while sdl2 isn't in the framework
[19:50] <slvn_> Exec=a.out is ok for MIR (as proven by mir_client_Demo_eglplasma) , but I cannot set the LD_LIBRARY_PATH
[19:50] <jdstrand> slvn_: warning, using Exec=a.sh isn't going to work under confinement
[19:51] <bschaefer> slvn_, right, that makes sense
[19:51] <bschaefer> slvn_, so you'll have to figure out
[19:51] <bschaefer> where LD_LIB normally looks
[19:51] <bschaefer> and ensure SDL2 is there
[19:51]  * bschaefer doesn't know if theres a default LD_LIB path...
[19:51] <jdstrand> *or* copy those files in $pkgdir/lib/$gnutriplet in the click package
[19:51] <bschaefer> i assume /usr/lib is one of them?
[19:52] <bschaefer> that would be a good way to test
[19:52] <slvn_> I dont understand that
[19:52] <jdstrand> then put your binary in $pkgdir/lib/$gnutriplet/bin in the click package
[19:52] <slvn_> you mean I should creat a "usr/lib/ directory in my click package ?
[19:53] <jdstrand> slvn_: lets say your click is unpacked in /opt/click.ubuntu.com/foo/0.1
[19:54] <jdstrand> then LD_LIBRARY_PATH is set to:
[19:54] <jdstrand> /opt/click.ubuntu.com/foo/0.1/lib/arm-linux-gnueabihf
[19:54] <jdstrand> and PATH is set to:
[19:54] <jdstrand> PATH="/opt/click.ubuntu.com/foo/0.1/lib/arm-linux-gnueabihf/bin:$PATH"
[19:55] <jdstrand> so, you just put whatever libraries you want in lib/arm-linux-gnueabihf in your click
[19:55] <jdstrand> and whatever binaries in lib/arm-linux-gnueabihf/bin
[19:56] <jdstrand> eg: you have Exec=fooexec
[19:56] <jdstrand> then you have lib/arm-linux-gnueabihf/bin/fooexec
[19:56] <jdstrand> and lib/arm-linux-gnueabihf/somesldlib.so
[19:57] <jdstrand> then when upstart-app-launch goes to launch the app, it finds lib/arm-linux-gnueabihf/bin/fooexec which uses lib/arm-linux-gnueabihf/somesldlib.so
[19:58] <jdstrand> you can see all the different paths that are set by examing aa-exec-click (note, aa-exec-click is not used on unity8, but does everything upstart-app-launch does)
[19:59] <bschaefer> slvn_, so the overall idea, is to get the SDL lib placed in the default location that upstart-app-launch is looking in
[19:59] <bschaefer> so you dont have to set the LD_LIB path
[20:00] <jdstrand> if you wanted to have this also usable on amd64, you would also ship lib/x86_64-linux-gnu/somesdllib.so and lib/x86_64-linux-gnu/bin/fooexec compiled for amd64
[20:00] <jdstrand> bschaefer: yes
[20:00] <bschaefer> yup
[20:00] <slvn_> ok, it makes sense !
[20:00] <jdstrand> your can cheat in the short term by installing the sdl libraries via apt, then just copying them in. note, this probably won't be robust across the release
[20:01] <bschaefer> right, but it'll be  a nice way to check you're heading the right direction :)
[20:01] <jdstrand> yes
[20:01] <slvn_> I try
[20:01] <bschaefer> jdstrand, thanks for the explanation!
[20:01] <jdstrand> np
[20:02]  * jdstrand also notes that QML2_IMPORT_PATH is also set to $pkgdir/lib/$gnutriplet, in case you need it
[20:09] <bschaefer> thats good to know
[20:10] <slvn_> bschaefer, jdstrand, the PATH is correctly set, but the LD_LIBRARY_PATH is empty
[20:10] <bschaefer> slvn_, im assuming it doesn't get set globally (only when its being clicked)
[20:10] <slvn_> the app "b.out" is found, but same problem of missing lib .so
[20:10] <jdstrand> (and as mentioned, you can see all the env vars that are set by looking at /usr/bin/aa-exec-click, which while not used by unity8, sets all the same variables upstart-app-launch does)
[20:11] <bschaefer> slvn_, did you do an echo $QML2_IMPORT_PATH
[20:11] <bschaefer> and attempt to put the sdl2 lib there?
[20:11] <bschaefer> in the click package it self?
[20:11]  * bschaefer doesn't have a N<n> laying around atm
[20:12] <slvn_> QML2_IMPORT_PATH=/usr/lib/arm-linux-gnueabihf/qt5/imports:/opt/click.ubuntu.com/.click/users/@all/com.ubuntu.developer.blabla.myapp2/lib/arm-linux-gnueabihf
[20:12] <bschaefer> slvn_, looks like: /opt/click.ubuntu.com/.click/users/@all/com.ubuntu.developer.blabla.myapp2/lib/arm-linux-gnueabihf
[20:12] <bschaefer> is where you'll want to take a look at
[20:12] <slvn_> ./lib/arm-linux-gnueabihf/bin/b.out
[20:13] <slvn_> ./lib/arm-linux-gnueabihf/libSDL2-2.0.so.0
[20:13] <slvn_> b.out: error while loading shared libraries: libSDL2-2.0.so.0: cannot open shared object file: No such file or directory
[20:13] <bschaefer> slvn_, well, i would have to assume its looking in a different location :)
[20:14] <bschaefer> slvn_, hmm , did you look in :/opt/click.ubuntu.com/.click/users
[20:14] <bschaefer> for your app?
[20:14] <jdstrand> slvn_: is lib/arm-linux-gnueabihf/libSDL2-2.0.so.0 a symlink or an actual file?
[20:14] <slvn_> look strange, because PATH and QML2_IMPORT_PATH are correct
[20:14] <slvn_> but LD_LIBRARY_PATH is empty
[20:14] <slvn_> (when I do an echo with the sh script)
[20:14] <jdstrand> slvn_: how are you launching the shell script?
[20:15] <slvn_> could this be a protection of root shell... or something
[20:15] <slvn_> Exec=a.sh
[20:15] <jdstrand> right, but how are you executing that?
[20:16] <jdstrand> via the app scope? via 'start application APP_ID=...', something else?
[20:16] <slvn_> in the click package, I do some "echo" that I get back with the log file
[20:16] <slvn_> I build the click package, download it, install it.  click manually on the tablet, and look at the log
[20:17] <bschaefer> slvn_, try with out the *.sh?
[20:17] <bschaefer> and the bin directly
[20:17] <jdstrand> slvn_: what did you set as your template in your security manifest?
[20:18] <jdstrand> (ie, if it is running confined, then you can't use a shell script in this manner)
[20:18] <slvn_>     "policy_version": 1.1 ?!
[20:18] <jdstrand> slvn_: please paste your security manifest
[20:19] <slvn_> {     "name": "com.ubuntu.developer.blabla.myapp2",     "description": "this is my app",     "framework": "ubuntu-sdk-14.04-dev1",     "hooks": {         "myapp2": {             "apparmor": "myapp2.json",             "desktop": "myapp2.desktop"         }     },       "maintainer": "",      "title": "My App Slvn",     "version": "0.912" }
[20:19]  * ogra_ returns from dinner 
[20:20] <ogra_> jdstrand, heh, yeah i was worndering if he found a bug when i heard the script works
[20:20] <jdstrand> slvn_: that is your click manifest. what is the contents of the security manifest?
[20:20] <slvn_> Unable to exec 'a' in '/opt/click.ubuntu.com/.click/users/@all/com.ubuntu.developer.blabla.myapp2': No such file or directory
[20:20] <slvn_> I have no security manifest :)
[20:20] <ogra_> ah
[20:20] <jdstrand> slvn_: myapp2.json
[20:20] <jdstrand> "apparmor": "myapp2.json"
[20:21] <jdstrand> myapp2.json is the security manifest
[20:21] <slvn_> {     "policy_groups": [         "networking"     ],       "policy_version": 1.1  } ~
[20:22] <jdstrand> slvn_: right, so the app is running under confinement. what is the output of 'grep DEN /var/log/syslog' (please use http://paste.ubuntu.com)
[20:25] <slvn_> I get : b.out: error while loading shared libraries: libSDL2-2.0.so.0: cannot open shared object file: No such file or directory
[20:25] <slvn_> in the app log file
[20:25] <slvn_> but nothing new in the syslog
[20:28] <jdstrand> slvn_: this is not a gui app atm?
[20:29] <jdstrand> like, you are just trying to test to see if it loads the library?
[20:29] <slvn_> well, it should be GUI app, but it dont load the lib yet
[20:29] <slvn_> in the .desktop
[20:29] <slvn_> Terminal=false
[20:29] <slvn_> Type=Application
[20:29] <slvn_> X-Ubuntu-Touch=true
[20:30] <slvn_> X-Ubuntu-Single-Instance=true
[20:30] <slvn_> StartupNotify=true
[20:30] <jdstrand> slvn_: and there was no output with 'grep DEN /var/log/syslog' on the device?
[20:32] <slvn_> no ...  BUT. If I use a "sh" script to start the "b.out" (with LD_LIBRARY_PATH=.) thenr the access to the mir_socket is reject
[20:32] <slvn_> nothing appear on syslog when I click on the app
[20:33] <jdstrand> slvn_: I'm not sure why LD_LIBRARY_PATH would not be set. you can see that it is here: http://ci.ubuntu.com/smokeng/utopic/touch/mako/5:20140430.1:20140411.3/7821/security/1059670/
[20:40] <slvn_> Yes, this is strange :/ I have tried to update to the same security manifest, and swith the framework to 13.10. but same problem.
[20:42] <slvn_> no sure if this is relevant, but I installed the Nexus10 image, one week ago
[20:42] <slvn_> this is revision (?) #303
[20:42] <slvn_> dont know if it make sens
[20:42] <slvn_> e
[20:45] <slvn_> Sometimes LD_LIBRARY_PATH get removed : http://superuser.com/questions/27376/why-does-my-ld-library-path-get-unset-launching-terminal
[20:46] <slvn_> I have already seen this, dont know if it is possible in that case :/
[20:47] <slvn_> maybe I dont install the click package correctly ?
[20:47] <slvn_> I do :  click install  com....
[20:47] <slvn_> but there is also "register",  and --all-user,
[20:50] <jdstrand> slvn_: if you are installing on the device, you should use: pkcon install-local /path/to/click
[20:50] <jdstrand> slvn_: I am preparing a click package for you to test. give me a minute
[20:52] <slvn_> even with pkcon install-local .. same problem
[21:06] <fginther> greyback, kgunn, is it ok to move the mir/devel branch builds to utopic?
[21:07] <greyback> fginther: I think so yes
[21:08] <jdstrand> slvn_: I think there is a bug in upstart-app-launch
[21:08] <slvn_> ok:)
[21:08] <slvn_> no problem, now this identified !
[21:08] <slvn_> *is
[21:09] <jdstrand> well, maybe my manifest is not correct
[21:09] <jdstrand> tedg: hey, do I need to do anything special to my click manifest to make ual set LD_LIBRARY_PATH?
[21:09] <fginther> greyback, thx
[21:10] <jdstrand> https://code.launchpad.net/~jdstrand/+junk/test-click-env
[21:10] <jdstrand> there is com.ubuntu.developer.jdstrand.click-env_0.1_all.click in http://bazaar.launchpad.net/~jdstrand/+junk/test-click-env/files
[21:10] <jdstrand> install that with: pkcon install-local com.ubuntu.developer.jdstrand.click-env_0.1_all.click
[21:10] <kgunn> fginther: yes
[21:10] <jdstrand> then run start application APP_ID=com.ubuntu.developer.jdstrand.click-env_click-env_0.1 && sleep 5 && grep LD_LIBRARY_PATH ~/.cache/upstart/application-click-com.ubuntu.developer.jdstrand.click-env_click-env_0.1.log
[21:11] <jdstrand> there is no LD_LIBRARY_PATH set
[21:11] <tedg> jdstrand, We're not setting the LD_LIBRARY_PATH
[21:11] <jdstrand> oh? why not?
[21:11] <jdstrand> I thought we decided to do that? I updated aa-exec-click to do that some time ago
[21:11] <tedg> jdstrand, No one asked me to :-)
[21:12] <jdstrand> tedg: can you do it?
[21:12] <jdstrand> :)
[21:12] <tedg> jdstrand, Sure, to package dir /lib
[21:12] <jdstrand> tedg: you can look at aa-exec-click for what it is doing, but basically:
[21:12] <jdstrand> libdir="$pkgdir/lib/$gnutriplet"
[21:12] <jdstrand> if [ -n "$LD_LIBRARY_PATH" ]; then
[21:13] <jdstrand>   export LD_LIBRARY_PATH="$libdir:$LD_LIBRARY_PATH"
[21:13] <jdstrand> else
[21:13] <jdstrand> export LD_LIBRARY_PATH="$libdir"
[21:13] <jdstrand> fi
[21:13] <jdstrand> slvn_: so, there you go
[21:13] <jdstrand> tedg: do you need a bug?
[21:14] <slvn_> jdstrand, yep, thanks, so i dont need to try your click package
[21:15] <tedg> jdstrand, Uhm, no I'll do it right now.
[21:15] <jdstrand> tedg: thanks
[21:15] <jdstrand> tedg: note that aa-exec-click does this:
[21:15] <jdstrand> libdir="$pkgdir/lib/$gnutriplet"
[21:15] <jdstrand> export PATH="$libdir/bin:$PATH"
[21:16] <jdstrand> ...
[21:16] <jdstrand> export LD_LIBRARY_PATH="$libdir:$LD_LIBRARY_PATH"
[21:16] <jdstrand> tedg: so you have things like lib/arm-linux-gnueabihf/foo.so and lib/arm-linux-gnueabihf/bin/fooexec
[21:17] <jdstrand> tedg: I thought that looked slightly odd, but pretty sure that was what was decided on the list
[21:17] <tedg> jdstrand, Yeah, I think we're already doing that with the path
[21:17] <jdstrand> tedg: yes, we are. I think you missed what I was saying
[21:17] <tedg> Not sure why it's not "bin/triplet"
[21:18] <jdstrand> tedg: ie, the .so file and the bin/ are at the same livel
[21:18] <jdstrand> level
[21:18] <jdstrand> yeah
[21:18] <jdstrand> yeah, me either
[21:19] <jdstrand> I don't particularly care what it is, but if we change it, it might break things. nothing uses aa-exec-click that I know of other than test scripts, so if you would prefer to change things, just let me know
[21:19] <tedg> I don't care that much.
[21:19] <tedg> Are you going to the SDK sprint?
[21:20] <jdstrand> week 1?
[21:20] <tedg> As long as we align with the Qt Creator folks I don't think it matters too much.
[21:20] <tedg> Yeah
[21:20] <jdstrand> I'll be there thu and fri
[21:20] <tedg> See how loudly they're complaining :-)
[21:21] <jdstrand> tedg: you are already setting QML2_IMPORT_PATH correctly by appending. LD_LIBRARY_PATH would be the same except prepending
[21:21] <jdstrand> ok, I've gotta go
[21:21] <jdstrand> tedg: thanks for taking care of that! :)
[21:22] <slvn_> thanks jdstrand for you help !
[21:22] <jdstrand> sure thing
[21:23] <slvn_> thanks also ogra_, greyback, and bshaefer
[21:23] <ogra_> :)
[21:24] <slvn_> tedg, hi, just wondering how it works for this kind of modification ?
[21:24] <greyback> welcome, hope it gets sorted out
[21:24] <slvn_> tedg, when does it get released ?
[21:25] <slvn_> greyback, yep, hope, then I will have to see with bschaefer why the sdl dont print anything on mir :)
[21:25] <greyback> :)
[21:25] <tedg> slvn_, Uhm, not sure. I can put it up for review but I don't have much control after that.
[21:25] <tedg> Probably not this week considering May day.
[21:26] <slvn_> tedg, no problem, I just ask because I am not familiar with the process. like, is there a ticket/report, and any *weekly* releaes or so
[21:27] <slvn_> I installed Ubuntutouch on my Nexus10 using : ubuntu-device-flash --channel=devel --bootstrap
[21:36] <ogra_> slvn_, it needs to go through several steps ... first it needs to get merged into the trunk branch, then the landing team assigns a build area for it where a deb gets produced, that deb goes to QA testing, once it passed that it goesd to the ubuntu archive and will then be picked up by the next phone image build
[21:37] <slvn_> ogra_, but how long to see it in "channel=devel" ? 1week, 1month, 1year?
[21:37] <ogra_> usually there is a bugreport accompaying it or a merge proposal at least that you can watch ... since tedg said above already he wont need a bug for it he might be able to give you the link to the MP so you can watch that
[21:38] <ogra_> really depends... such small changes usually only take a day (we only build two new images in max per day)
[21:39] <ogra_> but the landing and QA teams are mostly employees ... and there is may day in many parts of the world
[21:39] <ogra_> which means many people wont work tomorrow
[21:39] <ogra_> (or on the weekend)
[21:42] <slvn_> ok great, so very fast, cool
[21:43] <ogra_> lol
[21:44] <ogra_> before we had that setup it would have been in the archive in 20min
[21:45] <tedg> slvn_, MR is here: https://code.launchpad.net/~ted/upstart-app-launch/ld-library-path/+merge/217832
[21:45] <slvn_> but without review and smoke test
[21:45] <ogra_> yeah
[21:45] <tedg> I'd be surprised if it took less that 2 weeks.
[21:46] <tedg> than
[21:46] <ogra_> tedg, heh
[21:46] <ogra_> pessimist
[21:46] <slvn_> 2weeks, would be fine anyway :)
[21:46] <tedg> There are UAL MRs that are over a month old already.
[21:46] <ogra_> approved ones ?
[21:46] <tedg> Yes
[21:47] <ogra_> wow
[21:48] <tedg> ogra_, https://code.launchpad.net/ubuntu-menu-bar/+activereviews
[21:48] <ogra_> then whoever is the lander for your team should do his job better
[21:48] <ogra_> or you should have more landers in your team
[21:52] <slvn_> thanks again ! and see you. I go to sleep
[22:23] <racarr__> lol forgot that I deleted x-input-evdev last week
[22:24] <racarr__> treated to quite a surprise
[22:24] <racarr__> on rebooting
[23:30]  * RAOF giggles at racarr__ 
[23:40] <anpok> kgunn: yes..
[23:43] <kgunn> good grief...do you sleep :)
[23:44]  * kdub has wondered about that too :P
[23:50] <anpok> i had a few friends visiting
[23:50] <anpok> they just left..
[23:50] <anpok> so it is not my fault!