[14:55] <lool> asac: mind op-ing cjohnston?
[14:59] <roadmr> hello!
[14:59] <ogasawara> hi everyone :)
[14:59] <ogasawara> I'm leading the Core 1 track
[14:59] <zyga> hi
[14:59] <ogasawara> are people here who will be participating in this first session?
[14:59] <ogasawara> ie who needs the hangout url
[15:00] <zyga> ogasawara: I think I will 
[15:00] <ogasawara> zyga: https://plus.google.com/hangouts/_/72cpi1qqh03a30ophnekcd2si4?authuser=0&hl=en
[15:00] <zyga> thanks
[15:00] <sfeole> hey
[15:03] <brendand> ogasawara, didn't sabdfl say we can join by clicking a button on the summit page? thanks for the link anyway
[15:03]  * sergiusens wants a hangout link
[15:03] <ogasawara> brendand: hrm, not that I'm aware
[15:03] <rsalveti> sergiusens: https://plus.google.com/hangouts/_/72cpi1qqh03a30ophnekcd2si4?authuser=0&hl=en
[15:03] <ara> sergiusens, https://plus.google.com/hangouts/_/72cpi1qqh03a30ophnekcd2si4?authuser=0&hl=en
[15:03] <sergiusens> ty
[15:03] <ogra_> moop
[15:04] <asac> cjohnston: let me know iif its good
[15:04] <brendand> i'll try that and if i can't then i'll join by the link
[15:05] <zyga> ara: are you joining?
[15:06] <brendand> once the session starts there is a big 'Join Hngout on Air' link
[15:06] <brendand> (without the typo)
[15:06] <ara> zyga, I am here, just not in the hangout :)
[15:06] <asac> ChickenCutlass needs the HO url
[15:07] <asac> L)
[15:07] <ara> classic :)
[15:07] <roadmr> https://plus.google.com/hangouts/_/72cpi1qqh03a30ophnekcd2si4?authuser=0&hl=en
[15:07] <cwayne_> holy echo batman
[15:11] <lool> what happens when one switches between apps with side stage?
[15:15] <rsalveti> ChickenCutlass: https://docs.google.com/a/canonical.com/document/d/1ddNJTp7x9Jnra5akmpJkn-p7DBHp1S5APQ5ZiFM7zDY/edit#
[15:15] <ChickenCutlass> rsalveti: great
[15:16] <ogra_> that should really have been in the topic
[15:16] <ChickenCutlass> right
[15:16] <rsalveti> ogra_: it's in the blueprint
[15:16] <rsalveti> the specification link
[15:16] <ogra_> ah, k
[15:22] <ara> sergiusens, let's add a work item for us to improve documentation on how to create new providers
[15:22] <sergiusens> ara, sure
[15:26] <spineau> such item already exists in the todo of https://blueprints.launchpad.net/checkbox/+spec/core-1311-checkbox-rebirth
[15:32] <ogra_> ChickenCutlass, we have adbd in the initrd
[15:33] <ChickenCutlass> ogra_: right ok
[15:33] <ogra_> it starts automatically if it cant boot the rootfs
[15:33] <ogra_> what we really need is a better proting guide and porting tools
[15:34] <janimo> ogra_, +1 porting docs really need to be in better shape
[15:35] <ogra_> janimo, i'd even say we should toolize as much as we can of the porting process
[15:35] <janimo> ogra_, definitely
[15:35] <ogra_> "run tool a, then tool b, then add these kernel patches and try to boot"
[15:35] <rsalveti> +1 for both
[15:35] <rsalveti> :-)
[15:50] <zyga> ok, godo session!
[15:50] <sergiusens> zyga, I'll be in touch (pun)
[15:50] <zyga> sergiusens: so we should sync after UDS is done (or in some spot in between sessions)
[15:50] <ogra_> /whois godo
[15:50] <zyga> hehe
[15:50] <ogra_> :)
[15:50] <sergiusens> ogra_, don't be a peek
[15:50] <zyga> sergiusens: I'll show you how to get started and how to play with this
[15:51] <sergiusens> zyga, I guess I'll be more aware after the plainbox session :-)
[15:51] <zyga> sergiusens: that will be more about packaging and transitions from checkbox-old
[15:51] <zyga> sergiusens: setting things up and writing tests is _really_ easy and you won't be affected by that much
[15:52] <zyga> sergiusens: (by the new packages that we push into ubuntu)
[15:52] <sergiusens> zyga, yeah, the test writing part is going to be easy ;-)
[15:53] <slangasek> ogasawara: so for the next hour, I need to be in this session - trade off rooms? :)
[15:53] <ogasawara> slangasek: sure, works for me
[15:54] <zyga> sergiusens: well the tests are interesting and hard, integrating them with plainbox is easy in comparison
[15:55] <sergiusens> zyga, I have to agree :-)
[16:01] <slangasek> next session hangout: https://plus.google.com/hangouts/_/7acpjg77gbecup6lie1l78lut4
[16:02] <cwayne_> in this session are we going to talk about the possibility of customized bootsplashes as well?
[16:02] <cwayne_> i.e. for oem's
[16:03] <zyga> sergiusens: join us in #checkbox though
[16:03] <zyga> sergiusens: and get your test authors there too, we're going to help you all out
[16:03] <zyga> ok, next session
[16:06] <sergiusens> zyga, ack
[16:09] <cwayne_> ogra_, i think it's an important piece of customization as well, OEM/Carriers might want to have their logo shown on boot...
[16:13] <sergiusens> rsalveti, bootanim you mean?
[16:14] <sergiusens> don't we need a mir guy here?
[16:15] <sergiusens> rsalveti, I think alan_g was supposed to join
[16:19] <slangasek> isn't that who joined the hangout a few minutes ago?
[16:20] <slangasek> or do I have a phantom icon here?
[16:20] <ogra_> no, thats him :)
[16:23] <sergiusens> slangasek, that's him :-)
[16:31] <sergiusens> ChickenCutlass, I didn't setup a session for that
[16:31] <sergiusens> it was discussed last cycle, but it's still a work item
[16:31] <ChickenCutlass> sergiusens: ok -- we can discuss it
[16:31] <ogra_> sergiusens, you can take over my battery checking session
[16:31] <ogra_> (on thu.)
[16:31] <ogra_> seems we covered that bit already here
[16:32] <sergiusens> ogra_,if you don't have more to discuss later; let's just get it ironed out today :-)
[16:32] <ogra_> k
[16:33] <sergiusens> rsalveti, yeah, would be good to have design here; just take the action to get me a name and I'll get the other stuff going
[16:34] <cwayne_> can we be sure to keep customization in mind when designing this? i.e. have it look in XDG_DATA_DIRS or something so that we can override the boot animation in /custom
[16:34] <sergiusens> cwayne_, the update part is in recovery though
[16:35] <rsalveti> sergiusens: sure
[16:35] <cwayne_> im saying just for the initial boot animation, not necessarily the update one
[16:35] <sergiusens> cwayne_, oh; yeah, that's better :-)
[16:36] <cwayne_> that's what i figured, i just wanted to make sure that it was part of the plan from the beginning :)
[16:36] <cwayne_> figured it won't be hard
[16:36] <rsalveti> yeah
[16:57] <ogasawara> slangasek: switch back?  I figured you want to be in that Cgroup manager one
[17:12] <slangasek> ogasawara: yeah, happy to switch back
[17:13] <ogasawara> slangasek: also, tomorrow at 19:05 is the "Planning the hardware enablement strategy for 14.04 LTS" which it looks like we both might want to attend.  do you have anyone else on your team who could lead the other "Ubuntu Touch for x86 emulator" session?
[17:51] <xnox> hm, we have two emulator sessions, interesting (7pm on wednesday, 6pm on thursday)
[17:52] <ogra_> one is x86 only
[17:52] <ogra_> (or should be)
[17:53] <ogra_> https://blueprints.launchpad.net/ubuntu/+spec/core-1311-ubuntu-touch-for-x86
[17:53] <ogra_> also a lot more thna just emulator stuff
[17:54] <xnox> ogra_: yeah, i wonder if i'll be able to make the thursday session.
[17:54] <xnox> ogra_: i might be on 3G connection.
[17:54] <ogra_> should suffice for IRC at least
[17:58] <ogasawara> lool et al:  you still have a few mins, but when you're ready -> https://plus.google.com/hangouts/_/7acpjik1c25tdpu9cn9di3e6f4?authuser=0&hl=en
[18:01] <lool> hey
[18:01] <lool> ogasawara: thanks
[18:03] <lool> jdstrand: https://plus.google.com/hangouts/_/7acpjik1c25tdpu9cn9di3e6f4?authuser=0&hl=en
[18:03] <mdeslaur> am I needed in the fishbowl?
[18:03] <jdstrand> thanks
[18:03] <slangasek> ogasawara: yeah, bdmurray should have the access to run the other session tomorrow
[18:03] <ogasawara> slangasek: awesome, thanks
[18:04] <asac> o/
[18:04]  * asac waits for stream
[18:05] <ogasawara> rounding up the right people, give us all a sec
[18:05]  * cwayne_ would like to add online accounts to the list of plugins we'd need in clicks
[18:06] <tvoss_> lool, o/
[18:06] <pmcgowan> cwayne_, +1
[18:08] <zhangchao_UK> #ubuntu-uds-client-2
[18:08] <kenvandine> online accounts plugins too
[18:08] <dbarth> +1
[18:08] <robruds_> lool: webapps!
[18:09] <dbarth> robruds_: well, that's different i think
[18:09] <cwayne_> we'd need this fixed i think for online-accounts: https://bugs.launchpad.net/ubuntu/+source/click/+bug/1245826
[18:09] <udsbotu> Launchpad bug 1245826 in click (Ubuntu) "Allow applying a hook to multiple files" [Wishlist,Triaged]
[18:09] <dbarth> ie, webapps may reuse the the container
[18:10] <robruds_> dbarth: there will be some overlap between click webapps and click scopes/UOA accounts...
[18:10] <robruds_> dbarth: the webapps are essentially just a browser plugin.
[18:10] <ssweeny-uds> I'd like to see Friends plugins installable as click packages as well
[18:10] <dbarth> whereas OA will need hooks
[18:10] <lool> robruds_: these are already clickified!
[18:10] <robruds_> lool: not in the desktop they're not!!!
[18:10] <cwayne_> ssweeny-uds, what do you mean?
[18:11] <robruds_> ssweeny-uds: that's probably a good idea
[18:11] <cwayne_> what's a Friends plugin?
[18:11] <ssweeny-uds> cwayne_: Friends (nee Gwibber). Only twitter and facebook plugins are installed on the phone
[18:11] <dobey> cwayne_: presumably the online-accounts bits, and the friends-service plug-ins to parse the feeds
[18:11] <robruds_> cwayne_: Friends plugins allow Friends to support new social media sites. They're basically just files within a python module
[18:11] <cwayne_> ssweeny-uds, isn't that the same as online-account plugins?
[18:11] <ssweeny-uds> cwayne_: no
[18:11] <robruds_> cwayne_: highly correlated though
[18:12] <cwayne_> ah, alright
[18:12] <ssweeny-uds> cwayne_: o-a is auth. friends actually reads/writes to the streams
[18:12] <cwayne_> ah
[18:12] <cwayne_> ok
[18:12] <cwayne_> i gotcha
[18:12] <robruds_> cwayne_: friends plugins depend on o-a plugins 1:1, but they're implemented in different projects in different languages.
[18:13] <cwayne_> robruds_, yeah, i understand now, thanks!
[18:14] <cjwatson> cwayne_: Right, 1245826 is fairly straightforward and in my queue
[18:14] <cjwatson> You'll have it for trusty
[18:14] <cwayne_> wonderful, thank you
[18:15] <cwayne_> cjwatson, will that include being able to pass entire dirs as well?
[18:15] <cwayne_> a good example there is the qml-plugins dir for online-accounts
[18:17] <cjwatson> I think you can do that right now
[18:17] <cjwatson> You'll just get a symlink to the directory
[18:18] <cwayne_> i tried and it complained that it was a directory..
[18:18] <dbarth> cwayne_: what are you trying to do specifically?
[18:18] <cjwatson> cwayne_: bug please
[18:18] <cjwatson> (with details)
[18:18] <cwayne_> cjwatson, ack, thanks
[18:18] <cjwatson> we don't need to go into it here
[18:18] <dbarth> we're discussing plans to have a hook to get new OA providers in click packages
[18:19] <cwayne_> dbarth, make click hooks for online-accounts (well that's what i was doing)
[18:19] <dbarth> ok
[18:19] <dbarth> but then we feel that the plan is to use a special process, because we can't get that all automated for now
[18:20] <tedg> lool, Location service will have to have a user space component to handle trust store anyway.
[18:21] <tedg> lool, So there'll be user installed plugins as well.
[18:21] <tvoss_> tedg, why is that?
[18:21] <tvoss_> tedg, or do you refer to user space as in session?
[18:21] <tedg> tvoss_, Yes, in the session.
[18:21] <tedg> Sorry
[18:21] <tedg> Wrong term :-)
[18:21] <tvoss_> tedg, still: I don't see why a user would need to install a plugin to that specific location service
[18:22] <tedg> tvoss_, A provider wants to charge $2 for the plugin.
[18:22] <tedg> tvoss_, They want that to be per-user.
[18:22] <tedg> tvoss_, Or perhaps Google wants you to login with your Google account to get data.
[18:23] <tvoss_> tedg, hmmm ... google has got api keys to support that specific use-case for a reason I would think
[18:23] <tvoss_> tedg, however, I do agree with per-user plugin installation in general
[18:23] <tedg> tvoss_, Sure, theoretical example, not today.
[18:23]  * tedg start using Foogle for theoretical services
[18:23] <lool> is pad down for everyone or just me?
[18:24] <ogra_> here too
[18:24] <tedg> lool, Me aswell
[18:24] <jdstrand> down for me too
[18:25]  * ogra_ could imagine things like camera filters etc 
[18:25] <ogra_> (as user plugins)
[18:25] <tvoss_> lool, likewise
[18:26] <tvoss_> lool, did you think about an app (say: foogle) wanting to install a complete, custom gstreamer pipeline
[18:26] <tvoss_> lool, as opposed to only certain sinks or sources?
[18:26] <lool> tvoss_: what do you mean wiht a pipeline?
[18:26] <lool> like a plugin implementing a pipeline depending on elements?
[18:27] <lool> a pipeline is usually a runtime object, not a plugin, but you can provide a factory object
[18:27] <tvoss_> lool, yup, say a streaming media service having specific requirements for buffering or such things
[18:27] <tvoss_> lool, yeah, that's what I'm referring to
[18:27] <ogra_> android does that too ... i.e. mplayer or vlc for android have separate optimized codec packages
[18:28] <tvoss_> lool, with that, apps can leverage existing service infrastructure in a more flexible way
[18:30] <alecu> QUESTION: Do we really want app devels to be using weird codecs with little or no support for hardware accelerated decoding?
[18:30] <ogra_> alecu, they can do that on other platforms
[18:31] <alecu> ogra_: in other mobile platforms?
[18:31] <ogra_> and if you ship i.e. some media player that makes use fo HW acceleration of the HW you actually want codecs for the specific device
[18:31] <ogra_> yes, see what ii wrote above ... mplayer or vlc for android do that
[18:31] <kenvandine> i've seen it on android
[18:31] <ogra_> installing them will give you SW rendering by default
[18:31] <ogra_> and you can boost them by installing the right codecs for your device
[18:33] <ogra_> pad is back
[18:34] <tvoss_> alecu, ogra_ the one thing we need to make sure is that installed codecs are "confined" to the app that installed them, avoiding the situation where installing an app destroys the default media experience
[18:34] <tvoss_> lool, ^
[18:34]  * ogra_ doesnt like that we solely talk about codecs
[18:35] <ogra_> there are surely other plugins that would like to work close to the HW
[18:35] <ogra_> i.e. imagine something that enhances the camera ...
[18:36] <ogra_> (or any device in the phone/tablet actually ... camera filters that make use of HW directly just came to my mind first)
[18:36] <alecu> ogra_: I agree that we need other examples besides codecs. I really don't think we should provide plugins if the only use case is providing plugins for vlc or mplayer
[18:36] <alecu> ogra_: and
[18:36] <alecu>  sorry
[18:37] <ogra_> right ... i think there are a lot other opportunities ...
[18:37] <ogra_> anything that might enhance the HW or driver directly
[18:37] <lool> tvoss_: sorry, didn't follow everything and we moved on from codecs
[18:37] <lool> tvoss_: codecs confined to the apps installing them >> right, apparently that's hard and might not be required, so we'd just have trusted codecs
[18:38] <alecu> ogra_: regarding filters, that sounds like something that can be done with gpu shaders, I don't think it makes sense to let confined code running closer to hw drivers
[18:39] <ogra_> alecu, well, i thought more about something like adding HDR support on the driver level etc
[18:40] <alecu> ah, right
[18:40] <alecu> ogra_: that
[18:40] <alecu> sorry
[18:41] <dobey> well, Qt provides plenty of APIs for doing stuff to imagesd
[18:41] <ogra_> but camera only being an example here ... could be anything
[18:41] <dobey> err, images
[18:41] <ogra_> (equalizer talking directly to the audio driver ... )
[18:41] <dobey> there's no reason someone couldn't write a "filter" for the camera app to add some weird effect, using qt
[18:42] <ogra_> dobey, i mean enhancing the HW capabilities ...
[18:42] <ogra_> or making use of specific ones we can not offer out of the box
[18:42] <ogra_> HDR is nothing you can do in post processing
[18:43] <alex-abreu> lool, there is a separate session sur desktop webapps as click on thursday
[18:43] <ogra_> (or slow motion video (for which you need to raise the frame rate of the camera to get proper reults))
[18:44] <dobey> ogra_: i'm not sure that's a general case issue though. it does make sense for a vendor to ship special filters or whatever that take advantage of hardware
[18:44] <dobey> while other vendors might not ship it
[18:44] <tedg> mdeslaur, Run an image compressor under valgrind.  See if any errors happen :-)
[18:44] <ogra_> dobey, i dont care about vendors, my team is working on nexus images :)
[18:45] <ogra_> (tell that to achiang :) )
[18:45] <dbarth> lool: right
[18:45] <dobey> ogra_: then put it in the stock image :)
[18:45] <mdeslaur> tedg: yes, something like that
[18:45] <ogra_> dobey, not if it bloats the stock image for all platforms
[18:46] <tedg> lool, They're on the roadmap currently
[18:46] <tedg> lool, The idea is that apps can provide custom data, and the visualizations for that data.
[18:47] <tedg> beuno, No more database, now flat files
[18:47] <dobey> ogra_: right, so it needs to be simple enough to add it. there's no reason an approved click package can't do something with hardware. it's just a matter of approval and writing the things that load plug-ins to do things right in the realm of ubuntu touch
[18:47] <lool> tedg: https://plus.google.com/hangouts/_/72cpi1qqh03a30ophnekcd2si4?authuser=0&hl=en
[18:47] <mdeslaur> tedg: we'll need to look at the confinement story around that
[18:47] <ssweeny-uds> robruds_: can a friends plugin access data for an account other than the one it is called with?
[18:47] <lool> tedg: is there a security design for this?
[18:47] <jdstrand> yes
[18:47] <tedg> mdeslaur, I'll forward you my proposal
[18:47] <jdstrand> lool: no, not yet
[18:47]  * mdeslaur cancels his email account
[18:48] <jdstrand> tedg: can you send it to security@?
[18:48] <ogra_> dobey, right, is that "approved click package" already defined ?
[18:49] <tedg> jdstrand, Done
[18:49] <jdstrand> thanks
[18:49] <dobey> ogra_: i presume not since we're having the session to outline what we need, right now :)
[18:50] <ogra_> dobey, right :)
[18:50] <lool> any questions from IRC?
[18:50] <lool> ogasawara: sorry forgot to warn you to stop the recording
[18:50] <ogasawara> lool: no worries, I was following
[18:51] <lool> great
[18:51] <mdeslaur> thanks!
[18:51] <pmcgowan> thanks
[18:51] <cwayne_> thanks guys
[18:52] <lool> tedg: Thanks for raising this visualization use case
[18:52] <lool> this might actually be a real system wide plugin use case, since the greeter is for all users
[18:53] <tedg> The visualizations are per-user.
[18:53] <tedg> So I don't think it's system wide.
[18:53] <cwayne_> it is called 'usermetrics' :)
[18:53] <tedg> i.e. my fitbit data is just about me, and I might want it to look a particular way.
[18:59] <ogasawara> ogra_: you've got time, but when you're ready -> https://plus.google.com/hangouts/_/7acpimlsp5j5angdmi9mtqd06s?authuser=0&hl=en
[19:00] <lool> tedg: I mean there's only one greeter running
[19:00] <lool> tedg: on e.g. the desktop
[19:04] <ogasawara> hrm, anyone else joining this next session?
[19:04]  * ogra_ hopes so 
[19:04] <ogra_> sergiusens, ^^^ ?
[19:05] <ogra_> or rsalveti
[19:05] <sergiusens> ogra_, sorry got distracted with racy tests :-)
[19:05] <sarnold> I'll be listening / watching
[19:05] <ogra_> hmm
[19:05] <sergiusens> ogra_, give me a min to join
[19:05] <ogra_> seb wanted to send one settings app guy over too
[19:06] <rsalveti> will join the qt ubuntu x kubuntu one instead
[19:06] <ogra_> oh, indeed
[19:07] <ogasawara> ogra_: joining soon?
[19:07] <ogra_> ogasawara, if i get an url
[19:08] <ogasawara> ogra_: https://plus.google.com/hangouts/_/7acpimlsp5j5angdmi9mtqd06s?authuser=0&hl=en
[19:10] <seb128> ogra_, I can IRC participate (knowing I'm not listening to that stream because I'm in another session)
[19:13] <t1mp> I think a single "developer mode" option that does all the magic would be fine :)
[19:13] <t1mp> QUESTION: would enabling developer mode switch on writable mode?
[19:14] <t1mp> enabling developer mode would have to install gcc and a bunch of stuff needed to compile apps right?
[19:14] <t1mp> s/apps/plugins
[19:14] <doanac`> QUESTION: do we want SSH over RNDIS?
[19:14] <doanac`> or just wifi
[19:15] <ogra_> doanac`, add it to the pad
[19:15] <t1mp> ogra_: do you want to have the questions in the pad? Or we just ask them here? (prefixed with QUESTION:)
[19:17] <t1mp> adb only works when connected via a usb cable right? Or am I wrong? ssh can be used over wifi.
[19:17] <ogra_> right
[19:17] <sergiusens> t1mp, i'll bring them up
[19:17] <t1mp> sergiusens: ok, thanks.
[19:17] <ssweeny-uds> there are shell options you can pass to make adb shell behave more sanely, and it could be useful to wrap those up in a phablet shell command
[19:17] <pbass> QUESTION: is this bug relevant to the discussion? https://bugs.launchpad.net/ubuntu-system-image/+bug/1192577
[19:17] <udsbotu> Launchpad bug 1192577 in Ubuntu system image "Support for switching to system builder mode ... and back!" [Wishlist,Triaged]
[19:18] <cwayne_> ssweeny-uds, imho a phablet-shell command should be ssh so that its got the right environment
[19:18] <cwayne_> like attached to upstart, etc
[19:19] <ssweeny-uds> cwayne_: good point. ssh is probably the better option overall
[19:21] <t1mp> QUESTION: Did you consider supporting the possibility to have two ubuntu installations on one phone? One (stable) could be used for daily use, the other can be in developer mode with a writable image for testing new stuff
[19:21] <t1mp> ^so, dual booting between two ubuntu installs
[19:21] <ogra_> t1mp, once we have dual boot (in 15.10 or so :P)
[19:22] <t1mp> :)
[19:22] <ogra_> dual boot is wanted, but not in focus this cycle
[19:22] <sarnold> running out of space doesn't seem like a big problem to me -- someone who is prepared to hit a button that says "I know what I'm doing" doesn't necessarily need _that_ much hand-holding, right?
[19:22] <ogra_> sarnold, well, the system gety unusable at some point
[19:22] <ogra_> *gets
[19:24] <t1mp> QUESTION: How do you install build tools to compile (for example) C++ without enabling writeable mode?
[19:24] <ogra_> you cant
[19:24] <t1mp> ok. Just checking that I am not doing something stupid
[19:24] <ogra_> you dont ;)
[19:25] <cjwatson> compiling on device was only ever a stopgap
[19:25] <doanac`> the issue sergiusens mentioned makes CI work really hard
[19:26] <sarnold> cjwatson: won't we want to offer compile-on-device as part of our converged story?
[19:26] <cjwatson> sarnold: no, we want to offer cross-building
[19:27] <sarnold> cjwatson: that might work for e.g. rovio and so forth, but kind of hard to sell to a village in pakistan or india or africa
[19:27] <cjwatson> eh, surely for most cases we want to be presenting qml/etc.
[19:28] <cjwatson> and are you really asserting that people in villages will be developing apps *entirely* on device, without even an editor on another computer?
[19:29] <sarnold> sure, but if we're positioning a converged device as a realistic computing device rather than just a media consumption device, we ought not prematurely close doors like "compile on device"  :)
[19:29] <sarnold> cjwatson: yes.
[19:29] <cjwatson> if you have an editor somewhere else, you can do cross-building there too, and it will probably work better than compile-on-device
[19:29] <cjwatson> well, in that case it will need to be substantially more writeable than we have right now
[19:29] <sarnold> cjwatson: thousands of awesome and incredible apps were developed entirely that way on e.g. hp48 calculators in 32KB RAM.
[19:30] <cjwatson> or we need to build a chroot to do the building
[19:30] <t1mp> cjwatson: if the phone is supposed to be able to replace a PC eventually, then we want to develop 100% on a device (with keyboard and screen attached)
[19:30] <t1mp> cjwatson: yeah.. why not run the dev environment in a chroot?
[19:31] <sarnold> people may want to upgrade from their netbooks ;) hehe
[19:31] <cjwatson> t1mp: sure, that's possible
[19:32] <cjwatson> I no longer think of that as really "compile-on-device", because there isn't a separate device at that point, it's just your environment.  but meh, semantics
[19:32] <t1mp> QUESTION: could you provide a chroot image (that can be installed as a click package?) that has everything enabled that is needed for developing? would that work?
[19:32] <sergiusens> t1mp, there's a session for that I think
[19:33] <sergiusens> t1mp, but it doesn't go the path you propose
[19:33] <t1mp> sergiusens: which session?
[19:34] <cjwatson> it makes a lot more sense IMO to build chroots on the fly
[19:34] <cjwatson> shipping chroot images means shipping gobloads of data already mirrored etc. in other ways, which is futile
[19:34] <sergiusens> t1mp, http://summit.ubuntu.com/uds-1311/meeting/21991/core-1311-cross-compilation/
[19:34] <cjwatson> and a pain to keep up to date
[19:35] <sarnold> yeah, <3 sbuild for keeping all that stuff transparent from me :)
[19:35] <t1mp> sergiusens: I think that is for compiling touch/arm stuff on desktop/i386
[19:35] <cjwatson> t1mp: it winds up looking much the same, or should
[19:35] <sergiusens> t1mp, that's why I said, not the path you want
[19:36] <cjwatson> native building is effectively a degenerate subcase of cross-building
[19:36] <t1mp> sergiusens, cjwatson probably my requirements for developer mode are not those of a "standard" app developer. I need more stuff to build and test the UI toolkit on device
[19:36] <cjwatson> extra build-dependencies are boringly easy
[19:37] <t1mp> cjwatson: my "problem" is that every time after installing a new image, I need to enable write-mode and re-install all build-deps.
[19:38] <t1mp> cjwatson: nothing complicated, but I need to wait more before I can compile my stuff
[19:38] <cjwatson> t1mp: we need to fix things as necessary so you can cross-build
[19:38] <cjwatson> that is the path for (at least) 14.04
[19:38] <t1mp> ok
[19:38] <cjwatson> (as laid out in more detail at the client sprint, and in a session later this week)
[19:38] <t1mp> still building on device is cool :)
[19:39] <cjwatson> cross-building is cooler (once it works)
[19:39] <cjwatson> :-)
[19:39] <t1mp> once you have a phone that is faster than your laptop it is not cooler anymore ;)
[19:39] <cjwatson> let me know when you do
[19:39] <t1mp> unless you cross-compile for i386 from your phone :)
[19:39] <t1mp> cjwatson: okay :)
[19:42] <ogra_> ogasawara, i think you can stop recording
[19:42] <ogasawara> ogra_: thanks, will do
[19:43] <sarnold> how are you guys going to get an ssh authorized_Keys onto the device?
[19:44] <ogra_> sarnold, we didnt really cover ssh much, i guess by default we'll still go with passwords ... up to you to copy keys in place
[19:45] <sarnold> ogra_: eww. passwords. :)
[19:45] <ogra_> (the key negotiation in the notes was for adb)
[19:46] <sarnold> ogra_: I'd rather not have a few hundred thousand phones walking around with password-based authentication open to all..
[19:46] <ogra_> sarnold, why would they be open to all ?
[19:46] <ogra_> ssh wont start by default unless you enable the dev mode, adb neither
[19:47] <sarnold> ogra_: will turning on developer mode turn on sshd by default?
[19:48] <ogra_> i think we should have a separate switch for that
[19:48] <sarnold> that'd make me feel better; someone who turns on developer mode _and_ sshd is much more likely to configure keys than someone who just clicks a button "hey developer mode sounds fun"  :)
[19:48] <doanac`> could we have phablet-flash copy your .pub key over during provisioning?
[19:49] <ogra_> doanac`, sure
[19:49] <sarnold> doanac`: keen
[19:49] <ogra_> can someone add that to the notes ? :)
[19:49] <rsalveti> ogra_: lxc-console -nandroid already works with phablet upstream
[19:49] <ogra_> so i dont forget about it
[19:49] <rsalveti> ogra_: will be part of my next upload
[19:50]  * ogra_ hugs rsalveti 
[19:50] <ogra_> Ursinha, tell him he rocks !
[19:50] <rsalveti> haha
[19:50] <ogra_> (and give him a kiss)
[19:51] <Ursinha> :)
[19:54] <sarnold> thanks ogra_ :)
[19:54] <ogra_> thanks for the valuable questions !
[19:54] <ogra_> :)