[01:47] <robert_ancell> thomi, is quantal still enabled for lightdm CI?
[01:48] <thomi> robert_ancell: should be quantal & raring
[01:49] <thomi> if I'm reading this config file correctly
[01:49] <robert_ancell> thomi, the quantal builds are failing (qt5), I think we decided to drop them right?
[01:49] <thomi> robert_ancell: ahh, OK. I'll propose a merge now.
[01:49] <robert_ancell> thomi, ta
[01:52] <thomi> robert_ancell: https://code.launchpad.net/~autopilot/cupstream2distro-config/enable-mir-docs-upload/+merge/162907
[15:08] <kdub_> good morning, got internal client/inprocess working yesterday on android, today, getting both android and gbm to sit under the same platform abstraction for inprocess
[15:13] <tvoss> kdub_, \o/
[16:11] <kgunn> kdub_: sweet...
[16:56] <kgunn> its so quiet in here w/o alan & alf
[17:05] <kdub_> yep
[17:42] <kdub_> we probably need a namespaced "mir_egl_mesa_display_is_valid()" for both server and client
[18:11] <leowt> hi there, what is the status of the android drivers usage in mir?
[18:12] <kdub_> leowt, great!
[18:13] <leowt> kdub_: is there any arm platform used in development currently?
[18:13] <kdub_> the nexus line of devices
[18:14] <leowt> kdub_: what does need to be done to use a arm development board like pandaboard and so?
[18:15] <leowt> "loading drivers" is enough or theres much to do?
[18:15] <kdub_> leowt, with the pandaboard
[18:15] <kdub_> which, if i remember has an imagination gpu
[18:15] <kdub_> probably pretty close to the galaxy nexus, which works fine
[18:16] <kdub_> but you'd have to put an android image on the pandaboard, then an ubuntu touch install to get an ubuntu chroot
[18:16] <kdub_> and then just load the blobs, load mir on the device, and give it a go
[18:16] <leowt> kdub_: i have a couple of boards with Mali-400 available, same situation?
[18:18] <kdub_> leowt, havent tried with mir with mali cores yet, but i got my first mali device (nexus10) in the mail this week
[18:18] <leowt> im very interested in mir for desktop purposes
[18:19] <kdub_> so maybe 50% chance mir will work out the box, 50% chance i'll have to bang on it for a bit to get it to work
[18:19] <leowt> i will be glad to help
[18:19] <leowt> i have a couple of dev boards
[18:20] <kdub_> well, the easiest route is to find an xda-ported ubuntu touch image for one of your boards
[18:21] <leowt> kdub_: currently i see that you develop on top of android images, am i right?
[18:22] <kdub_> leowt, right, but that's really so we can use the android drivers unmodified
[18:23] <leowt> kdub_: what are the plans to get away from that "workaround"?
[18:23] <leowt> i mean, a pure ubuntu system
[18:23] <kdub_> well, its a much bigger effort than just the gpu... #ubuntu-touch might give a fuller picture
[18:24] <leowt> i see
[18:24] <leowt> kdub_: tnks
[18:25] <kdub_> no problem
[19:45] <jdstrand> hi! will MIR support XSETTINGS (I hope not, since it makes application isolation more difficult)?
[19:53] <kgunn> jdstrand: had to go look at XSettings spec....i come from android land
[19:53] <kgunn> but its a good question
[19:54] <kgunn> this only might come up
[19:54] <kgunn> in the future convergence story
[19:54] <kgunn> where we want to also support old x-apps (via rootless x on mir)
[19:55] <kgunn> for the near term we've only to worry with qt, wonder if there's something analogous
[19:55] <jdstrand> that rootless X on mir, that is a situation where all the applications running in X are in the same session, correct? ie, there is no isolation for keyboard events, etc
[19:55] <kgunn> & just as concerning in qt world
[19:57] <jdstrand> (for those in X, but an app in X couldn't mess with native mir app or vice-versa
[19:57] <kgunn> jdstrand: i'll have to punt and say "don't know" wrt no isolation on keyboard events
[19:57] <jdstrand> )
[19:57] <kgunn> yeah...that does sound correct
[19:57] <jdstrand> ok, well, mir is of course designed to thwart keyboard and mouse sniffing and screen grabs
[19:57] <kgunn> yes
[19:58] <jdstrand> right, so within that X there might be some questions on keyboard events
[19:58] <jdstrand> (that's fine)
[19:58] <jdstrand> it's also fine if xsettings is in X in mir
[19:58] <kgunn> cool
[19:58] <jdstrand> what I'm curious about is xsettings or its equivalent in native mir
[19:59] <jdstrand> (well, by some definition of 'fine'-- it is not great that applications can sniff each other in their, but those won't be coming from the app store, so it isn't an immediate concern)
[19:59] <kgunn> jdstrand: yeah, that's just it....mir tends to push out true window management/policy stuff....up to the shell's responsibility
[19:59] <jdstrand> s/their/there/
[20:00] <kgunn> jdstrand: but it is designed such that the shell will have access to privileged interfaces
[20:01] <jdstrand> if I understand that statement and what xsettings does, it sounds like the shell would be what would handle these kind of preferences, as opposed to the individual apps trying to honor them
[20:01] <jdstrand> (via a lib or something)
[20:01] <kgunn> right...and actually the mir guys sat with your guys last week
[20:01]  * jdstrand nods
[20:01] <kgunn> cause we did discuss apps sharing data (like drag and drop)
[20:02] <jdstrand> I don't know if xsettings came up in particular, so I wanted to ask
[20:02] <kgunn> i don't think it did...
[20:02] <jdstrand> (xsettings actually allows for module loading, so apps not being able to manipulate them or their equivalent is important)
[20:02] <kgunn> i will bring up with robertA gets on later
[20:03] <jdstrand> kgunn: thanks, I appreciate it. it sounds like we are ok, but I wanted to have a definitive answer
[20:03] <kgunn> for sure....i know raof & roberta will know for certain
[21:14] <kgunn> robert_ancell: i'm about to have to jet...kid has a dr appt....
[21:14] <robert_ancell> kgunn, ok
[21:14] <kgunn> but jdstrand was asking if xsettings would be used in the future
[21:15] <kgunn> like with rootless x for legacy x apps
[21:15] <kgunn> bottom line....will x apps be able to screw with each others settings ? or input streams ?
[21:16] <kgunn> i told him, x apps would be seperate process from shell/qt apps wrt settings like these
[21:16]  * kgunn wonders if he was right :)
[21:18] <kdub_> sounds about right
[21:22] <jdstrand> robert_ancell: right, so my question was mostly about native mir apps and mir supporting something like xsettings (I hope it does not). xsettings in the old X model would allow an app load modules and things by abusing xsettings
[21:23] <jdstrand> robert_ancell: it sounds like the shell would handle all that and apps would have direct access to any of it. can you confirm?
[21:24] <jdstrand> robert_ancell: as for rootless X server, it sounds like there will be a shared X session for all the non-Mir stuff to get lumped into. as such, anything in that session could in theory snoop/poke at everything in that session (but not outside)
[21:25] <kdub_> thomi, jenkins builds armhf package and then puts it in ppa:mir-team/staging on every commit, right?
[21:25] <jdstrand> robert_ancell: can you confirm that as well? if so, it could be neat to have a different rootless x server for each non-Mir app (at least optionally), which would isolate them much like Xephyr/Xnest/etc do now (though that might break some things that they expect to have)
[21:29] <jdstrand> robert_ancell: err, s/apps would have direct access/apps would *not* have direct access/
[21:29] <robert_ancell> jdstrand, otp, be back in 30mins
[21:30] <jdstrand> robert_ancell: ok, I'll probably be eod then, but I read backscroll. feel free to answer at your convenience
[21:33] <kdub_> if anyone has some review cycles for today... https://code.launchpad.net/~kdub/mir/native-buffer-type/+merge/162635
[22:26] <thomi> kdub_: correct
[22:26] <thomi> kdub_: sorry for the delay
[22:27] <kdub_> thomi, no problem :)
[22:28] <robert_ancell> jdstrand, correct apps will contact the shell for shell behaviour. Where appropriate, we will put things into the Mir protocol to avoid unnecessary side protocols, but we haven't really found anything for that yet
[22:29] <robert_ancell> jdstrand, confirm with RAOF, but for rootless X I think the default assumption is the X apps all share the same server. We'd treat using separate X servers per app as a security optimization. My gut feel is it wont be required (there wont be so many legacy apps to matter)
[22:41] <RAOF> I don't think there's any particular reason we couldn't have one-rootless-server-per-X-app.
[22:44] <robotfuel> when I run mir_demo_server on saucy, I get the following error message:  mir_demo_server: error while loading shared libraries: libmirserver.so.0: cannot open shared object file: No such file or directory
[22:45] <robotfuel> what should I be running to run the mir server?
[22:46] <kdub_> robotfuel, sounds like something's not installed right
[22:47] <robotfuel> http://pastebin.ubuntu.com/5646158/ is what I have installed from mir
[22:48] <robotfuel> apt-get install -y mir-demos is what I used to do the install of mir
[22:49] <kdub_> maybe mir-demos should depend on libmirserver0
[22:53] <robotfuel> kdub_: thats it thanks :D
[23:06] <RAOF> thomi: Could we please turn on Saucy builds in the PPA?
[23:07] <thomi> RAOF: yeah, I'm surpised they're not on already. will check now
[23:07] <RAOF> Ahem. Or maybe I could actually add the PPA back after blowing away my install.
[23:08] <thomi> robert_ancell: while I'm in here, do you want saucy for the lightdm daily builds?
[23:09] <robert_ancell> thomi, yes please
[23:09] <thomi> RAOF: no, you were correct - no saucy builds AFAICS
[23:12] <RAOF> Hm. The dependencies for mir-demos are a filthy lie.
[23:12] <thomi> FYI: https://code.launchpad.net/~thomir/cupstream2distro-config/add-saucy-for-mir/+merge/163071 - will get francis to take a look when get gets online
[23:12] <RAOF> At the moment you're publishing raring builds into the saucy repo, which isn't terrible.
[23:59] <RAOF> Boo. What broke the build under gcc 4.8?
[23:59] <kdub_> RAOF, have you noticed that mir_demo_inprocess_egl  doesn't terminate with ctrl-c?