[12:57] <zyga> hi
[13:57] <cjwatson> OK, time to figure out the new hangouts interface I hear about
[13:57] <zyga> cjwatson: new?
[13:57] <zyga> cjwatson: could you paste the hangout link here when ready, please?
[13:57] <cjwatson> Yeah, going to
[13:57] <ara> hello all!
[13:57] <cjwatson> apparently google rolled out a new interface last night - may only matter for those starting hangouts
[13:58] <zyga> oh
[13:58] <zyga> heh
[13:58] <zyga> beware of google updates ;) wait, we cannot control that
[13:58] <spineau> I didn't notice any changes this morning
[13:59] <cjwatson> the interface to start a hangout on air is in an entirely different place; there was internal RT traffic this morning from people confused by it
[13:59] <cjwatson> bdmurray: if you're lost, BTW, it's in home (at the left) -> hangouts on air
[14:00] <brendand> link!
[14:00] <cjwatson> https://plus.google.com/hangouts/_/c6f853c7682e14d362c469190256247ab5cfc2eb?authuser=1&hl=en-GB
[14:00] <zyga> thanks
[14:53] <cjwatson> zyga: not so much port to python 3 as fix it, presumably, since python3-urwid does exist
[14:58] <brendand> kicked off?
[14:58] <bladernr`> brendand: you froze
[14:58] <bladernr`> brendand: plugin again?
[15:00] <zyga> woot
[15:00] <zyga> thanks
[15:00] <zyga> cjwatson: it's totally broken
[15:00] <zyga> cjwatson: it's not doing anything useful
[15:00] <zyga> cjwatson: tests never even got invoked once there
[15:00] <zyga> cjwatson: (because of a bug in setup.py)
[15:01] <brendand> zyga, i don't think plainboxes remit should go beyond the M part of MVC really
[15:01] <zyga> cjwatson: it's a total automatic conversion that does not work
[15:01] <cjwatson> ah, suck
[15:01] <brendand> zyga, and maybe the model part is complete, but we just need to ensure it is
[15:02] <zyga> brendand: it's not that complete but it's sufficiently good for our existing needs, but I agree in general
[15:02] <brendand> zyga, i kind of think it would be a useful exercise to write a noddy gui app using plainbox in parallel
[15:02] <zyga> brendand: +1 from me
[15:02] <zyga> brendand: just pick your toolkit
[15:02] <brendand> zyga, to make sure we have the right level of abstraction
[15:03] <roadmr> qml? *ducks*
[15:03] <zyga> brendand: agreed
[15:03] <zyga> roadmr: qml is interesting
[15:03] <zyga> roadmr: as to how to bridge that :)
[15:03] <brendand> roadmr, yes qml
[15:04] <brendand> roadmr, i know cr3's objection was that there was no ui toolkit for it at the time
[15:04] <brendand> roadmr, anyone say ubuntu sdk?
[15:04] <roadmr> brendand: yes something like that
[15:04] <bdmurray> okay, its about time for the next session
[15:04] <brendand> roadmr, well that's the past now :)
[15:05] <bdmurray> https://plus.google.com/hangouts/_/c3ffb1d0fd80765471ed4f856fe6c43ec2eb1a92?authuser=0&hl=en
[15:06] <ogra_> i kind of need a toolchain person for this
[15:06] <ogra_> infinity seems to be afk ... doko as well :/
[15:06] <cjwatson> might be worth an sms
[15:07] <sergiusens> ogra_: can it be postponed?
[15:07] <ogra_> sergiusens, no free slots
[15:07] <ogra_> (we just discussed it in -touch)
[15:08] <cjwatson> doko is around
[15:08] <ogra_> yeah
[15:08] <cjwatson> summoning him :)
[15:08] <cjwatson> I'll try SMSing Adam
[15:09] <ogra_> well, one of them shoudl be enough i think
[15:09]  * apw waits for the stream
[15:09] <ogra_> he wasnt feeling well
[15:09] <ogra_> (we talked before)
[15:09] <cjwatson> ah, ok, well too late I already sent it
[15:10] <ogra_> heh
[15:11] <ogra_> doko, https://plus.google.com/hangouts/_/c3ffb1d0fd80765471ed4f856fe6c43ec2eb1a92?authuser=0&hl=en
[15:13] <bdmurray> okay its live now
[15:14] <apw> bdmurray, i see it
[15:15] <cjwatson> doko: I muted you (twice) - feedback with a long time lag, sounds like you're also listening to the video stream on youtube or something?
[15:15] <cjwatson> or else your hangout is way behind :)
[15:16] <ogra_> http://phablet.ubuntu.com/export/
[15:16] <doko> cjwatson, sorry I don't see where ...
[15:17] <doko> now, no etherpad here
[15:17] <cjwatson> Can't tell from this end, all I could tell was that we were hearing things from a minute or so ago
[15:17] <cjwatson> There's a link in the summit page called "notes in a separate window"
[15:17] <bdmurray> http://pad.ubuntu.com/uds-1305-foundations-1305-android-builds-revisited
[15:18] <cjwatson> Or pause the youtube stream
[15:21] <ogra_> http://phablet.ubuntu.com/gitweb
[15:22] <apw> ogra_, have we tried compiling with the archive compilers at all?  I assume we know we _do_ need this special compiler.
[15:24] <ogra_> https://wiki.ubuntu.com/Touch/Porting
[15:24] <cjwatson> apw: we need bionic at least
[15:24] <apw> cjwatson, point indeed
[15:25] <apw> ogra_, thanks
[15:25] <ogra_> . build/envsetup.sh
[15:25] <ogra_> brunch mako
[15:26] <asac_web> repo sync for source package prep
[15:26] <asac_web> repo sync for source package prep
[15:26] <ogra_> right
[15:27] <asac_web> i think if we could split it up in a part for "platform enablement" and one part for the rest it would be good
[15:28] <asac_web> i think if we could split it up in a part for "platform enablement" and one part for the rest it would be good
[15:28] <asac_web> i think if we could split it up in a part for "platform enablement" and one part for the rest it would be good
[15:28] <asac> bah :)
[15:28] <asac> stupid web thing
[15:29] <asac> i think the hal stuff is what people usually touch
[15:33] <sergiusens> ogra_: do we have a hangout link?
[15:33] <ogra_> https://plus.google.com/hangouts/_/c3ffb1d0fd80765471ed4f856fe6c43ec2eb1a92?authuser=0&hl=en
[15:33] <stgraber> ogra_: you realize we'll likely be repacking/converting any zip file you generate into our tar.xz format anyway, right?
[15:34] <stgraber> basically for the Ubuntu images we'll have two main tar.xz files, one that contains the hardware independent bits (rootfs) and another that contains hardware dependent bits (android bits, boot partition, recovery partition, any kind of firmware/baseband, ...)
[15:35] <asac> stream offline
[15:35] <stgraber> asac: works fine here
[15:35] <asac> back now
[15:36] <ogra_> stgraber, right. thats what we have now too
[15:36] <asac> i dont understand the proposal with producing the zip files in the package build ... is that to avoid doing stuff in the image production code?
[15:36] <cjwatson> nor do I
[15:37] <cjwatson> it sounds like it will be significant excess work even if it doesn't look like it now
[15:37] <asac> can you repeat the proposal?
[15:37] <asac> :)
[15:37] <asac> ogra?
[15:37] <asac> you can speak :)
[15:37] <ogra_> http://phablet.ubuntu.com/export/
[15:37] <lool> asac: there's a lag between video and here
[15:37] <cjwatson> so the zip files are *only* the output of the android build?  they contain no Ubuntu-specific content at all?
[15:37] <sergiusens> asac: there's 4 minutes lag sometimes
[15:37] <sergiusens> asac: he's explaining
[15:37] <lool> now you seem him typing his answer  :-)
[15:38] <lool> *see
[15:38] <asac> so i thought ... we produce one big or a few packages with the android bits. install them during image production with apt-get etc... and then just mangle it to produce real phone images and all the zips we need etc.
[15:39] <lool> a .zip in a .deb generated by just moving the contents of a .tgz seem a bit inefficient use of buildd time  :-)
[15:39] <apw> ogra_, i assume we would invent a nice base orig to make this not be humungous on each upload
[15:39] <asac> isnt the content in the zip also in out/target/product/maguro?
[15:39] <ogra_> apw, right
[15:39] <asac> so you can just package that  up?
[15:40] <asac> or you can just unpack it before packagint he binary during build :)
[15:40] <josepht> asac: perhaps you could join the hangout
[15:40] <asac> right
[15:40] <asac> i am on another call :)
[15:41] <asac> will there be no build dependencies from the ubuntu system that need this stuff?
[15:42] <ogra_> nope
[15:42] <ogra_> well, libhybris and the platform-api will need bionic
[15:43] <apw> ogra_, when one does a 'brunch mako' does that spit out just the mako bits
[15:43] <ogra_> apw, yeah
[15:43] <cjwatson> anything in the Ubuntu system that needs it will build-depend on arch: all packages that contain armel binaries
[15:43] <asac> apw: depends what you mean with "just mako bits"
[15:43] <cjwatson> which is the plan of record for bionic for instance
[15:43] <asac> there is clearly mako independent stuff produced during that from what i know
[15:44] <cjwatson> do you mean mako dependent?
[15:44] <asac> cjwatson: oh ... can we keep the door open for x86 binaries?
[15:44] <cjwatson> sure, I don't mean exclusively
[15:44] <asac> the arch: all feels constraining us to produce phablet x86 images
[15:44] <cjwatson> no, not at all
[15:44] <cjwatson> you misunderstand :)
[15:44] <asac> ok i will leave you
[15:44] <apw> ogras description seemed to imply there was independant and mako-speciifc output from brunch, but that they were separate, and i am trying to confirm if he meant that
[15:44] <asac> will sync after/offline to catch up :)
[15:45] <cjwatson> if we want to build armel binaries then those don't correspond to any architecture in the Ubuntu archive; we have no alternative but to cross-compile, and the most sensible way to do that is to cross-compile once on i386
[15:45] <cjwatson> the same would go for x86 if they were linked against bionic, probably
[15:45] <cjwatson> anyway arch: all doesn't constrain us to anything, it relaxes a constraint
[15:45] <asac> kk
[15:51] <apw> ogra_, or get someone with a good network to sync the bits onto a machine, and then use rsync from your local machine to there before upload
[15:52] <ogra_> apw, yeah, i#m not to worried about that bit
[15:52] <ogra_> http://cdimage.ubuntu.com/ubuntu-touch-preview/daily-preinstalled/current/
[15:54] <ogra_> http://cdimage.ubuntu.com/ubuntu-touch-preview/daily-preinstalled/current/raring-preinstalled-armel+grouper.zip
[15:57] <lool> win 9
[15:57] <lool> ups
[16:00] <rsalveti> sergiusens: I put my name in there as I'm working on cleaning hybris anyway
[16:01] <baozich> hi
[16:02] <sergiusens> rsalveti: no worries!
[16:04] <vanhoof> hi
[16:04] <cjwatson> hi, just bringing up the hangout now
[16:04] <cjwatson> https://plus.google.com/hangouts/_/ceaefc95b48453edfea3dadabe276df43df5876f?authuser=1&hl=en-GB
[16:06] <rbasak> Is the stream live? I'm getting errors.
[16:06] <bjf> not live here
[16:07] <cjwatson> not on air yet
[16:07] <apw> bjf waiting on the participants currently
[16:07] <cjwatson> waiting for a few more people to show up
[16:07] <rbasak> I get "An error occurred. Please try again later"
[16:07] <rbasak> (behind the "Please stand by." screen)
[16:07] <cjwatson> I'll say here when I put it on air
[16:07] <rbasak> OK thanks
[16:07] <cjwatson> doko: joining the hangout?
[16:07] <zyga> hi
[16:09] <cjwatson> should be on air now or shortly
[16:10] <kentb> \o/
[16:10] <rbasak> It errored a bit more but seems to be working now - thanks.
[16:11]  * rbasak likes how cjwatson says "Saucy"
[16:15] <cjwatson> my vowels are all permuted randomly from standard English I'm afraid :)
[16:21] <dannf> server stuff :)
[16:22]  * cjwatson waves hands furiously :)
[16:23] <dannf> lamp stack - php/python/apache/etc - probably the maas depends too
[16:23] <dannf> i don't know that we need any java stuff commercially - but its the things that build-dep on java for side packages that might bite us
[16:24] <cjwatson> a bunch of core packages build-depend on java for plugins and the like
[16:24] <dannf> right
[16:24] <cjwatson> so it's quite inconvenient not to have something basic, although it *can* be turned off in most of the relevant ones
[16:25] <rbasak> Would non-JIT Java be bearable for build-depends?
[16:26] <dannf> vanhoof: +1 - seems doable
[16:26] <cjwatson> rbasak: if it works yes
[16:26] <dannf> cjwatson: sure, we'll deal w/ that separately
[16:27] <dannf> power mgmt, etc
[16:27] <rbasak> I don't think there will be any fundamental issues - just an individual bringup task for individual chassis as they become available.
[16:28] <dannf> bug getting django, etc is more what i meant for this session
[16:28] <rbasak> And support in d-i for each system, of course. Hopefully the kernels will have device tree but even if not we can do them the same way as we do armhf MAAS enablements
[16:28] <rbasak> (for maas)
[16:29] <cjwatson> rbasak: right, that's sort of what I was asking about, whether that's needed for 13.10
[16:29] <rbasak> Yes - Ubuntu Core would be really useful for early hardware bringup work
[16:29] <cjwatson> hopefully not since we AFAIK have no idea what we're doing there yet :-)
[16:29] <apw> rbasak, someone needs to own maas for this, is that in your hands ?
[16:30] <rbasak> vanhoof: coordinating individual MAAS enablements are your department, I think? I'm not sure about anything for 13.10 though - we need real hardware to enable MAAS I think.
[16:31]  * dannf isn't sure maas is needed in this cycle - but i think coordination belongs to our (vanhoof's) group
[16:31] <rbasak> (it depends on the BMC firmware vendors give us)
[16:31] <vanhoof> dannf: I think it's worth investigation now, I've reframed the work item
[16:31] <dannf> thx
[16:32] <rbasak> There is a task for me to make MAAS work with device tree kernels though (or anything other than -highbank).
[16:32] <rbasak> I can do that together with the first enablement.
[16:32] <cjwatson> ok, given you a WI for that
[16:33] <cjwatson> or do you want to drop that and it'll in practice come up later?
[16:34] <dannf> rbasak: i have some patches for that i can share, let's sync up at some point
[16:34] <rbasak> It's a definite dependency for any MAAS enablement, armhf or arm64. So I think it's safe to drop it and it'll come up as soon as we consider an actual enablement.
[16:34] <dannf> if you mean feeding the dtb to machines, that is
[16:35] <rbasak> dannf: sure, we should chat. Thanks!
[16:35] <dannf> don't expect anything awesome :)
[16:36] <cjwatson> rbasak: ok
[16:37] <lool> ups looks like I wasn't muted when my family came back home
[16:38] <dannf> see ya
[16:38] <cjwatson> thanks
[16:38] <vanhoof> cheers!
[17:06] <zyga-uds> hi
[18:02] <bdmurray> hang out url https://plus.google.com/hangouts/_/90b69f088ee82ef1cd236813add7c301a409611a?authuser=0&hl=en
[18:06] <bdmurray> video is live
[18:06] <tedg> mdeslaur, You gonna hangout with us?
[18:06] <mdeslaur> tedg: I'm with you
[18:06] <mdeslaur> tedg: look carefully :)
[18:07] <zyga-uds> hi
[18:08] <jodh> anyone else getting a lot of extraneous hiss on this hangout?
[18:08] <sbeattie> jodh: yes, lots of audio noise
[18:08] <lool> ricmm: are you in the hangout?
[18:09] <zyga> tedg: question later on when appropriate: if you use upstart for that, can you instantiate a job per user without making it an instance job?
[18:09] <lool> there's a high-pitched noise from time to time in the hangout
[18:09] <lool> tedg: one issue is integration wiht app mgr
[18:10] <tedg> lool, What is app mgr?
[18:10] <jodh> lool: what is "app mgr"?
[18:11] <lool> sorry, the application manager role of Unity + Mir
[18:11] <zyga> normal?
[18:11] <lool> that is, it will signal apps that they are about to be suspended
[18:11] <lool> and resume then
[18:11] <lool> *them
[18:11] <gQuigs> does this give us app specific logs for free?
[18:12] <mdeslaur> gQuigs: yes!
[18:12] <tedg> gQuigs, yes!
[18:12] <mdeslaur> lol
[18:12] <lool> sorry, not sure why ,y video is broken
[18:12] <gQuigs> that's awesome :)
[18:12] <zyga> jodh: so 'application' job would be one super-task that is instantiated per app and user?
[18:12] <bfiller> tedg: is the shell planning to switch to using upstart to launch apps?
[18:13] <bfiller> if so, when?
[18:13] <sars> lego man, you're impossible to hear :(
[18:14] <zyga> lool: you're not getting through on the hangout
[18:15] <pitti> tedg: you mean kill remaining processes of the session?
[18:15] <lool> zyga: is it better now?
[18:15] <lool> zyga: now that I've rejoined
[18:15] <zyga> yes
[18:15] <pitti> tedg: logind ccan already do that, but I'm not sure it's what we want (as people might start screen sessions, for example)
[18:16] <lool> I don't understand where my video stream is coming from
[18:18] <dbarth> QUESTION: what is the plan wrt to webapps or remote apps that may have 1 app/process managing multiple distinct distant apps?
[18:19] <dbarth> i imagine app mgr can give us a distinct id
[18:19] <dbarth> but how will that id be integrated with the upstart scheme?
[18:20] <mdeslaur> dbarth: for security reasons, those need to be separate processes to have their own security confinement anyway
[18:20] <mdeslaur> were you referring to html5 apps, for example?
[18:21] <dbarth> RDP / Citrix (admintedly a desktop specific case) will multiplex things in the end
[18:21] <mdeslaur> ah! ok
[18:21] <dbarth> so there may be a need to let those distinct processes communicate with the one holding the socket to the remote server
[18:22] <dbarth> html5 will be easier there; or may be not actually, since i guess there's one main process also doing the network side, and multiple ones for rendering
[18:29] <zyga> tedg: could you explain how it would work on the desktop?
[18:29] <zyga> tedg: starting with someone clicking on the launcher icon?
[18:32] <txwikinger> terminals are startup several times.. but I think it uses the trick of different names
[18:33] <bdmurray> http://pad.ubuntu.com/uds-1305-foundations-1305-upstart-app-launching
[18:33] <bdmurray> tedg: ^
[18:34] <zyga> txwikinger: terminal is not confined in any way to run multiple times IIRC, some apps explictly try to prevent that
[18:34] <zyga> tedg: would what you just explained be in upstart core or in a specific job?
[18:40] <zyga> tedg: thanks
[18:41] <gQuigs> apport should collects the app logs when reporting bugs for said app  ~ where are the apps going to be logged to?
[18:42] <pitti> gQuigs: apport already collects those (in saucy)
[18:42] <pitti> gQuigs: ~/.cache/upstart/<job>.log
[18:43] <gQuigs> pitti: perfect
[18:43] <pitti> that mostly supersedes/replaces collecting ~/.xsession-errors
[18:45] <cjwatson> (at the end of this session, could somebody give me a one-sentence summary for the closing plenary?  I had a conflict and couldn't make it)
[18:49] <jjohansen> mdeslaur: we also should have env rules in apparmor
[18:50] <jjohansen> but upstart should do most of what we need
[18:50] <mdeslaur> jjohansen: yeah, the environment will be pretty clean already, but we can blacklist some in both places if we need to
[18:51] <tedg> pitti, Will apport grab the application-<instance>.log files as well?
[18:52] <pitti> checking..
[18:52] <pitti> it attaches <name>.log for each /usr/share/upstart/sessions/<name>.conf that the package ships
[18:52] <pitti> so if the job names are different from the log names in that case, we need to adjust it
[18:53] <pitti> tedg, jodh: works?
[18:53] <tedg> Yeah, in this case it would be application-<desktop name>.log
[18:53] <tedg> So we'd need to grab that log for any desktop file.
[18:53] <pitti> ok, needs changing then
[18:53] <tedg> pitti, Can I add an action item for you there?
[18:54] <tedg> Heh, pitti thanks!
[18:54] <tedg> You're too fast!
[18:54] <pitti> tedg: added a WI, does that look right?
[18:54] <pitti> heh
[18:54] <tedg> pitti, Yup, looks good!
[18:54] <tedg> Thanks!
[18:55] <asac> one question (catching up) ... what role will upstart play in the new app life-cycle approach? will some logic about that be in upstart? will there be specific features for that added to upstart?
[18:56] <asac> stgraber: ?
[18:57] <stgraber> asac: upstart will just take care of starting and stopping the app and applying the various apparmor/seccomp/cgroup profile/restrictions
[18:57] <stgraber> asac: my understanding is that suspend/resume and other similar features will be handled by Mir/Unity instead but I'm not terribly familiar about those bits myself
[18:59] <asac> stgraber: yeah. just occurs to me that starting/stopping etc. are too activities in the lifecycle
[18:59] <asac> so thought maybe other states might make sense to be reflected in the same place :)
[18:59] <asac> whatever that might mean :)