#ubuntu-uds-foundations-1 2013-05-14
<cjwatson> oh wow, my client has been logged in here since UDS 13.03 and I forgot about it
<zyga> hi
<zyga-uds> hi everyone
<brendand> cjwatson, can you provide me the link for the first session (i'll be running it)
<cjwatson> brendand: I'll start up the hangout once the plenary has finished
<zyga> hi
<cjwatson> I think there are access controls on summit that mean I need to start it up (or bdmurray, but me in this case), but more than happy for you to run the actual session :)
<brendand> cjwatson, do you know do people need to be specifically invited, or do they just need the link?
<cjwatson> they just need the link AFAIK
<cjwatson> so you can pass it on
<cjwatson> but there's a limit of *mumble*
<zyga-uds> welcome everyone, if you need to join the hangout ask for the link please
<roadmr> zyga-uds: I need to join the hangout :)
<zyga-uds> if you wish to help with making notes in the etherpad on the side here, please do so
<zyga-uds> roadmr: you'll get a link as soon as we get one
<roadmr> zyga-uds: oooh :) ok heh
* udsbotu changed the topic of #ubuntu-uds-foundations-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1305//foundations-1/ - http://ubottu.com/udslog/%23ubuntu-uds-foundations-1
 * brendand feels like trusting people and posting the link here - rather than sending it to everyone privately. thoughts?
<zyga-uds> +1
<zyga-uds> it will make it easier for people to join
<zyga-uds> and if it fails, we'll know
<sfeole> o/
<zyga-uds> hi
<cjwatson> just fighting G+ to start it up now
<sfeole> hey zyga
<brendand> cjwatson, just pop the link in here when you're ready
<brendand> cjwatson, thanks
<cjwatson> https://plus.google.com/hangouts/_/e57d55608285e7215ba3273218e8ae43d4244d2e?authuser=1&hl=en-GB
* udsbotu changed the topic of #ubuntu-uds-foundations-1 to: Track: Foundations | Checkbox Certification for ARM Servers | Url: http://summit.ubuntu.com/uds-1305/meeting/21723/foundations-1305-checkbox-arm-server/
<cjwatson> there's a fairly substantial lag between the hangout and the youtube video, just so you know
<cjwatson> don't know if that's inherent or due to my network
<roadmr> hello
<zyga-uds> we'll be starting in about 5 minutes,
<zyga-uds> at 16:05 UTC
<brendand> cjwatson, new url or same one?
<cjwatson> https://plus.google.com/hangouts/_/a5bb0a674d670614230e303f5f9e384e7dbbc0e6?authuser=1&hl=en-GB
<cjwatson> no control over that I'm afraid
<cjwatson> I think it's all back now
<brendand> vanhoof[uds], https://plus.google.com/hangouts/_/a5bb0a674d670614230e303f5f9e384e7dbbc0e6?authuser=1&hl=en-GB
<cjwatson> just starting the youtube feed
<brendand> schwuk, want to join?
<schwuk> brendand, not sure I will have much to contribute, but I'm certainly interested in the discussion
<brendand> schwuk, may as well, plenty of room
<smagoun> youtube feed just came online for me
<zyga-uds> https://plus.google.com/hangouts/_/a5bb0a674d670614230e303f5f9e384e7dbbc0e6?authuser=1&hl=en-GB
<smagoun> cjwatson: ^^
<cjwatson> yep
<mahmoh> it's working for me now
<cjwatson> I have no idea whether it's going both ways over my ADSL; if it is, then, well, good luck
<roadmr> cjwatson: it seems to be working fine, thanks for manning the a/v thingamajig!
 * cjwatson puts on the crew hat
<zyga-uds> gema if you want to join:Â https://plus.google.com/hangouts/_/a5bb0a674d670614230e303f5f9e384e7dbbc0e6?authuser=1&hl=en-GB
<gema> zyga-uds: I will join if I need to, I am listening for now
<zyga-uds> thanks
<dannf> does checkbox use lshw?
<roadmr> dannf: no, it doesn't. BTW let me know if you want a slot in the hangout, there's plenty of room and we love contributions and discussion
<brendand> roadmr, can you say that in the hangout?
<vanhoof> brendand: ara: you can sign me up to get you access to newer kit for virt
<brendand> https://plus.google.com/hangouts/_/a5bb0a674d670614230e303f5f9e384e7dbbc0e6?authuser=1&hl=en-GB
<ara> vanhoof, great :)
<gema> QUESTION: are you going to evolve checkbox or are you going to keep the level of development you have on desktop and just grow the server side of the tool_
<gema> ?
<gema> but some tests may only be applicable to desktop
<bladernr> those are not run on servers
<gema> bladernr: ack
<bladernr> different test whitelists are used
<gema> bladernr: understood
<dannf`> device tree
<dannf`> which kernel exposes from firmware
<mahmoh> dmidecode (lost the stream) has a flag (that I can't think of atm) that will run early support for ARM
<spineau> mahmoh: good to know, I'm adding a note for that
<vanhoof> eep
<vanhoof> booted
<zyga-uds> I need to go AFK for 3 minutes
<zyga-uds> roadmr:please take over etherpad
<roadmr> zyga-uds: got it
<mahmoh> spineau: if I remember the flag I'll let you know but it should be easy to find with the tool or ask colin worst case
<spineau> mahmoh: ok, thanks
<mahmoh> np
<bladernr> I don't see why we would
<zyga-uds> re
<bladernr> Unless there's some special sort of marketing push for ARM systems, otherwise, a server is a server
<mahmoh> it would be nice to be able to sort on arch
<mahmoh> but that's not a requirement, just a nice to have
<victorp_uds> hi ara
<vanhoof> zyga-uds: can you pop in lshw -xml into the etherpad, I lost my session
<bladernr> Is there anyting special about an ARM chassis that differs from a blade chassis?
<victorp_uds> OEMs will be selling chassis with sleds on them I guess. So it is probably good to have something for the chassis set up too
<zyga> vanhoof: pop in?
<vanhoof> add it :)
<victorp_uds> bladernr: in some cases they are the same chasis
<narindergupta2> ipmi test could be one of them
<vanhoof> bringingmy session back up
<mahmoh> there are differences but they should be transparent from a cert perspective
<zyga> vanhoof: done
<bladernr> victorp_uds: ack
<bladernr> mahmoh: that was my impression... the chassis is just a 'container' (yes, more than that, but from the actual server/blade POV, it's transparent)
<victorp_uds> ara sorry Â I joined late, but are we including MaaS testing as part of certificaition testing for hyperscale servers?
<mahmoh> bladernr: right
<mahmoh> QUESTION ^^
<ara> victorp_uds, MaaS is going to be greylist for server certification and required for cloud
<victorp_uds> It needs to be reuired too for hyperscale servers
<victorp_uds> otherwise they cant be used
<victorp_uds> :)
<narindergupta2> i think we should start categarizing the hyperscale different from server.
<victorp_uds> narindergupta2:+1
<victorp_uds> brendand: just use MaaS!!!
<narindergupta2> +1
<victorp_uds> brendand:if you dont test MaaS then you are not testing the full solution
<victorp_uds> brendand: definetly
<victorp_uds> ara - are we having a different whitelist for hyperscale?
<ara> victorp_uds, we haven't decided it
<ara> victorp_uds, if we can avoid it, we will, if in the end we need specific tests, we will create a new one
<ara> victorp_uds, we will use the server one until we really need to fork
<victorp_uds> ara - I would rather you use the cloud whitelist rather than the server white list
<victorp_uds> if you dont have a dedicated hyperscale one
<narindergupta2> yes it has
<victorp_uds> vanhoof: \o/
<vanhoof> victorp_uds: :D
<narindergupta2> infact they have power management through chassis
<narindergupta2> and fan control and power supply control
<narindergupta2> through chassis
<bladernr> but is that really through the chassis, or via ipmi passed from the chassis MM to the blade BMC?
<narindergupta2> for BL series you are correct but for moonshot it is through chassis as BMS is in chassis
<bladernr> ahhh
<narindergupta2> /s/BMS/BMC
<bladernr> that is different :) so instead of each cartridge having it's own bmc, there's then one master that controlls all cartriges (even in a mixed cartridge environment?)
<narindergupta2> yes i BMC controlling 15 cartridge
<narindergupta2> so total 3 BMC for 45 nodes within one chasssis
<bladernr> wow
<bladernr> that's pretty neat
<zyga> brendand: really good session, thanks
<lool> Next: Click Packages
<brendand> zyga, yeah surprisingly
<ara> great, I can stay here then
<brendand> zyga, i thought we had everything fleshed out already :)
<zyga> brendand: yeah, same here
<mahmoh> juju bootstrap ; juju status
 * brendand runs off to SDK feedback session
<mahmoh> hi spineau, bye spineau
* udsbotu changed the topic of #ubuntu-uds-foundations-1 to: Track: Foundations | Click packages | Url: http://summit.ubuntu.com/uds-1305/meeting/21760/foundations-1305-click-package/
<aquarius_uds> hey all
<bkerensa> hi
<dbarth> hiya
<dholbach> hiya
<mdeslaur> hello
<cjwatson> https://plus.google.com/hangouts/_/d3fd1e25ecacb43fde03034a86b8a3345f19b801?authuser=1&hl=en-GB
<cjwatson> on air shortly
<cjwatson> on air now
<cjwatson> who wants to hop onto the hangout?
<beuno> cjwatson, this will all be client side, right?
<Laney> not on here
<beuno> if so, I'll watch from the shadows
<apw`> cjwatson:yep we can see yo
<dbarth> it's on now
<cjwatson> beuno: I expect there will be questions about server side too
 * Laney stabs firefox
<Laney> oh yes
<SuperMat1> hi guys!
 * ogra_ sees two guys hanging
<apw`> yes you are good
<beuno> cjwatson, ok, ok, I'll hop in
<ogra_> yes
<xnox> yeah
<SuperMat1> yes, we can see you
<alecu> loud and clear
<barry> yes
 * xnox is watching you well from New York public library =)
<sergiusens> you are hearable
<aquarius_uds> https://lists.ubuntu.com/archives/ubuntu-devel/2013-May/037074.html is the discussion on ubuntu-devel
<rickspencer3> o/
<olli-uds> hiho
<rickspencer3> hi aquarius_uds I was invited to join, so I joined ;)
<ogra_> joined and left :P
<dobey> can qml not be byte-compiled?
<mdeslaur> Any reason why the manifest file in the binary package doesn't simply point to a public source code repo when the source is available?
<mdeslaur> ie: why even have a source package format
<dobey> if random people are uploading it, we aren't distributing it are we? the person uploading it is
<cjwatson> we're certainly (re)distributing it
<dobey> we're just a "file sharing service" in that respect
<cjwatson> it is not generally that simple :-)
<xnox> it would be nice to upload the source and/or download them in addition to the app.
<mdeslaur> ok, source package formay is bzr, and you install it with bzr co
<apw`> cjwatson:can we not just 'keep' the <package>_src guarenteed available for the source once we have figured it out.
<apw`> ie, so we have <package>.click and <package>_src.click
<xnox> some people embed src tarball inside the app-package. but it's cumbersome to download on your developer machines. One would want to download it on your laptop instead of your phone.
<TheMuso> dobey: I thought I read somewhere that QML could be byte-compiled, but I may be mixing it up with somethign else.
<ogra_> rickspencer3, that will eat your disk on the phone fast
<rickspencer3> hi ogra_ well, that's what I'm asking
<rickspencer3> how much will it *really* do that, versus how much are we just worried that it will?
<dobey> TheMuso: it would seem a bit odd to me if it wasn't possible, at least.
<cjwatson> there are certainly source packages in the Ubuntu archive which are significantly larger than the binaries
<ogra_> rickspencer3, i want to write a DVB TV app that needs 6 libs plus my C++ source plus the QML for the UI
<cjwatson> though I would need to do some research if you wanted specifics :)
<ogra_> i would have to include all of that source
<rickspencer3> ogra_, right, but that seems like an exception to the rule
<victorp_uds> rickspencer3:I think the amount of apps that will include *a* gpl component will be high
<TheMuso> dobey: Especially if a dev wanted to obfoscate some secret class that they didn't want people to grab.
<dobey> TheMuso: right, or an API key for a web service
<ogra_> rickspencer3, devs are crazy people :)
<xnox> Have the "source app store" for the desktop =)
<Laney> aren't we going to need a source package format to get stuff built anyway, never mind the distribution problem?
<xnox> login - and download the sources for apps installed on your phone =)
<alecu> Hi, my team will be working on the UI to install click packages, and we'll need to get a list of apps installed by the current user, and download new application packages, so: QUESTION: who will be handling the database of installed packages? lp:click-package as well?
<victorp_uds> cjwatson:do people need to get to it from the phone? they could download it from an app store website
<xnox> Laney: good point.
<beuno> alecu, no, the server
<beuno> <----
<beuno> well
<beuno> no
<beuno> I lie
<ogra_> liar
<beuno> not the installed apps
<dobey> right, liar
<alecu> beuno: you usually do :-)
<beuno> :)
<beuno> <----  not
<dobey> server will know what's been "purchased", but not if it's installed on a particular device
<geofft> Laney: Not necessarily. For proprietary apps, my workplace at least is already working around Debian source packaging.
<geofft> Laney: And I keep pondering just switching to ar and forgetting proper source packaging.
<james_w> Laney: only if we're expecting to have a buildd system for these. If the developers upload binaries then we don't need it
<alecu> dobey: the android server knows what is installed on each of your devices, though.
<barry> cjwatson: even on the desktop, leaf packages only, right?
<cjwatson> IMO yes
<barry> +1
<alecu> dobey: (I'm not saying that's a good idea, though)
<glatzor-uds> Hello, as anaptdaemondeveloper I am interested at which level the new package system will be integrated? Will there be a separate (perhaps DBus) API for the management?
<dobey> alecu: right, that's certainly possible. but i'm not sure it's reasonable :)
<Laney> james_w: Indeed, I was assuming we would have that
<Laney> don't know what other app stores do
<beuno> there is no plan to have a build system on the server
<beuno> we'll ask for built binaries
<cjwatson> glatzor-uds: noted, will get to that shortly
<Laney> intriguing
<AlanBell> can other people host a repository for click packages?
<beuno> cjwatson, see alecu's question about what tracks installed apps
<dholbach> maybe we could all prefix questions with QUESTION: so they stand out?
<brunogirin> aquarius_uds: also if you focus on a simpler packaging model, you won't be able to repackage everything
<cjwatson> urgh, my connection fell over
<beuno> AlanBell, yes, it will just be http(s) downloads
<cjwatson> is the hangout still running?
<xnox> glatzor-uds: hey there =)
<ogra_> cjwatson, yes
<aquarius_uds> cjwatson: the hangout is running
<aquarius_uds> but it is off air
<dobey> cjwatson: yes and you're still in it it seems
<cjwatson> bleh
<cjwatson> my browser periodically loses its mind - I'll have to restart it
<Laney> I think the lag is pretty significant
<rickspencer3> I didn't think I was saying anything quite so controversial that cjwatson had to leave
<dobey> or maybe not
<glatzor-uds> hello xnox
<zebaszp> QUESTION: where would click packages unpack to? and should we be concerned about the FHS?
<dobey> oh there it goes
<AlanBell> hangout has gone . . .
<zebaszp> oh dammit, it died
<xnox> cjwatson: =) now hangout is done pending on you coming back =)
<alecu> it died
<xnox> s/done/gone/
<jdstrand> arg
<dholbach> volveremos pronto!
<xnox> "<cjwatson> my browser periodically loses its mind - I'll have to restart it"
<ogra_> probably someone with a higher bandwith line should be the host
<mterry_uds> Huh, hangout isn't working for me right now
<Laney> haha
<aquarius_uds> the hangout will be back shortly: cjwatson is returning any moment now
<mterry_uds> whoops, didn't see that was old news  :)
<cjwatson> zebaszp: /opt/apps.ubuntu.com/<package>/<version> or similar, which should be FHS-compatible
<apw`> it is poor that the hangout is owned by any one person, shame on you google
 * ogra_ hands out candy from the corridor 
<zebaszp> cjwatson, thanks :)
<apw`> oh i miss the candy, though my wasteline may not
<rickspencer3> hey all, does it seem to be working again?
<zebaszp> not for me yet
<bioevolgenec> Nope
<ballock> nope
<mdeslaur> Please, stay on the line. Your call is important to us.
<brunogirin> rickspencer3: no
<Ferruck> no
<ogra_> nope
<dbarth> not yet
<aquarius_uds> it will return shortly
<zebaszp> lol mdeslaur
<cjwatson> there is a lag; the same lag likely applies to startup
<Ursinha-uds> there you go
<mdeslaur> ah! back now
<apw`> cjwatson:we are back
<ogra_> there we are
<xnox> back =)
<brunogirin> yay, it's back!
<zebaszp> yeah!
<apw`> cjwatson:i can see you from here
<dobey> it's on air
<xnox> refresh webpage to reconnect, btw....
<Laney> i didn't have to
<brunogirin> QUESTION: so are we saying that click-package is a simple way to package simple apps and is not designed to replace .debs?
<zebaszp> yes brunogirin
<alecu> brunogirin: I understand that, yes.
<cjwatson> brunogirin: yes
<zebaszp> I said it first :P
<apw`> how will security handle evaluating binary only packages
<mdeslaur> apw`: we'll be confining them
<bioevolgenec> apw +1
<alecu> apw`: that's what app sandboxing is for
<mdeslaur> apw`: and the app author is responsable for it
<apw`> mdeslaur: that is both great, and about the most scarey thing in the world :)
<geofft> mdeslaur: That seems like the actually interesting part of the design. :)
<AlanBell> so, version numbers and automatic updates . . .
<mdeslaur> apw`: well, it's something that is quite necessary if you want a phone with 100k apps
<AlanBell> and updates from one repository to another, is this all stuff that has been thought about?
<alecu> apw`: each app will be run as a different user, and within an apparmor profile, and will have limited access outside its sandbox
<apw`> mdeslaur:yep, i cannot deny it is correct, it is just scarey
<zebaszp> QUESTION: how are user privileges handled with click packages? forÂ installation,Â removal, on runtime, etc
<geofft> I'm reminded of the complaining in the Mac developer community over the Apple App Store sandbox (on the desktop)
<mdeslaur> alecu: not as a different user, no
<xnox> AlanBell: server-side, as far as I understand it.
<alecu> mdeslaur: ack
<brunogirin> QUESTION: should it include a way to package tests (as in autopilot tests)?
<dobey> cjwatson: if it was via aptdaemon, it'd make things much easier :)
<mdeslaur> geofft: if you don't want it to be confined, you get it in the normal ubuntu archive
<alecu> geofft: good point. But inspecting source code does not scale
<dobey> as far as install/remove/upgrade goes
<beuno> AlanBell, the plan is for the client to ping the server with all the apps it has installed and versions regularaly, and the server responds with newer versions
 * ogra_ hopes we'll never get a million apps
<geofft> I certainly agree that confining is right, just that it's hard :)
<zebaszp> why not, ogra_?
<ogra_> (i prefer 100k good apps to 1mio crap ones)
<AlanBell> beuno: so, if I run a third party repo for my app, can I override someone elses app?
<zebaszp> oh
<geofft> mdeslaur: I'm curious about things like, does it have the Android issue where you can't refuse certain permissions?
<jonobacon> ogra_: agreed
<dobey> but if we use aptdaemon, will it be rewritten in c++? or will we ship python on phones?
<mdeslaur> geofft: yes, but it's par for the course now...android and ios do it, etc.
<ogra_> dobey, in javascript ;)
<diwic> maybe if the privileges cost extra (if an application declares wanting to send SMS, Canonical takes 30% instead of 20%) that would make apps in general wanting to have the least privileges.
<jdstrand> re sandboxing/confinement/isolation: https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement. I suggest taking that up on ubuntu-devel@ mailing list of #ubuntu-hardened on Freenode
<cjwatson> we don't presently have a prohibition on using python for non-long-running things
<mdeslaur> geofft: in v1, yes
<beuno> AlanBell, yes, like it is today with PPAs and such
<jdstrand> if people have questions (it is tangentially related to this, but really its own topic)
<geofft> jdstrand: thanks
<ogra_> dobey, we already ship python (and guess we'll go on doing so) ... you are not allowed to write daemons in it though
<dobey> ogra_: aptdaemon is written in python though :)
<cjwatson> a d-bus service is kind of on the edge; IMO it doesn't run for long enough to be a practical problem
<ogra_> dobey, as long as it doesnt constantly run ...
<xnox> REST call to a server, return paged results.
<dobey> rickspencer3: having a local copy of the db
<zebaszp> apt-cache? XD
<xnox> (e.g. top 10, 20, 50, etc)
<mdeslaur> cpu is less important than data transfer fees
<dobey> searching via aptdaemon would be fine
<xnox> zebaszp: no, no =) no apt-cache =)
<mdeslaur> having a local database is a bad idea
<dobey> hitting the rest api is going to hit network, which may more costly than just using cpu
<ogra_> dobey, we dont want a db locally
<zebaszp> I know, I was just kidding
<glatzor-uds> next to the aptdaemon API there is also the PackageKit API (system and session).It would be sad to see another API to trigger installations/updates
<ogra_> dobey, we generally have SD card speed on the disks
<xnox> aptdaemon API is back-end agnostic =) such that you can search clicks and debs and rpms and etc.
<ogra_> you dont want to search a DB locally if you can avoid it
<zebaszp> side note: iOS (as far as I know) does not keep a local db for the App Stor
<zebaszp> *Store
<mdeslaur> whatever api, it needs to gain knowledge of using an online db, instead of a local db
<xnox> It's a good isolation point. either of them.
<zebaszp> Cydia (aka APT for iOS) does, though, but we probably don't want to go that way :P
<dobey> ogra_: if it's a minimal db (and not the apt cache), it's probably not an issue in terms of speed vs. SD
<beuno> there will be a search api on the server
<mdeslaur> Cydia is painful :P
<dobey> ogra_: network could be MUCH slower
<zebaszp> indeed mdeslaur
<ogra_> dobey, well, show me a package db that works fast on an SD on constrained HW and i'll agree :)
<ogra_> i simply havent seen one yet
<mdeslaur> a package db that contains 250k packages is going to be big.
<ogra_> right
<xnox> please no.
<diwic> mdeslaur, not to mention the network fees to download its regular updates.
<mdeslaur> yep
<zebaszp> I don't know about iOS App Store data consumption because I have an iTouch, and I never bothered checking network usage
<xnox> no changelogs - i'd rather have them in the app-store / on the web. And not downloaded and stored on my phone pointlessly.
<zebaszp> I agree with xnox
<beuno> oh, absolutely no local DB of all the apps available
<geofft> IIRC iOS does the changelog as part of the app store submission, but not as part of the downloaded thing
<dobey> mdeslaur: i wouldn't store the entire apt cache locally. just an index cache, and hit the network for more extensive data. we don't need to store *everything* offline
<xnox> I really don't care about changelogs any more on my phone. It just updates.
<victorp_uds> aquarius_uds: +1
<victorp_uds> aquarius_uds:make it optional
<zebaszp> the App Store (I know, sorry for bringing it up yet again) does that, it shows a "changes" box on each app in the upgrade list
<xnox> if I want to read it, I read them on my computer on the apps store "big" webpage.
<mdeslaur> dobey: storing a cache with a limited subset of data adds complexity for very little benefit
<xnox> zebaszp: is it app store, or the app on first launch showing it? i remeber apps themself have a "changelog widget"
<cjwatson> brunogirin: where are we expecting that these would be run?
<zebaszp> the app store, xnox
<dobey> mdeslaur: and yet necessary if we want a fast UI
<xnox> thanks.
<victorp_uds> aquarius_uds:seems that we are forgetting that an app will also have a web page that people can refer too?
<apw`> cjwatson:tests might want to be in the same 'hole' as source
<zebaszp> at least, when I go to the upgrade section, each app with available upgrade has a "changes" dropdown
<cjwatson> perhaps, yes
<cjwatson> zebaszp: yeah, but it often says "Bugs fixed", right? :)
<mdeslaur> dobey: oh, caching the app store data is a different issue
<dobey> mdeslaur: if we're going to have live search or let users filter results while they're coming in, we're going to have to cache some data for speed
<mdeslaur> dobey: why? ios doesn't, android doesn't...
<brunogirin> cjwatson: as part of validating that the app doesn't break anything and as an option for users to run them locally (ok, scope creeep for v1 :-))
<zebaszp> cjwatson, sometimes, but you'd be surprised
<mdeslaur> dobey: search is better served online
<olli-uds> there are existing tests
<zebaszp> I think changes on the last version also appear on the store itself, before downloading a *new* app
<achiang> why would an end user want a test suite on the phone?
<rickspencer3> hi mdeslaur o/
<rickspencer3> :)
<achiang> ... downloaded as part of the app isntall
<brunogirin> achiang: to file a bug report
<achiang> brunogirin: i highly doubt any normal consumers would want that
<mdeslaur> hehe
<jdstrand> \o/
<mdeslaur> :)
<jdstrand> fyi (again)> https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement
<zebaszp> as an example, check Feedly's store page, the "What's new" section works as a changelog of sorts: https://itunes.apple.com/us/app/feedly/id396069556
<mdeslaur> I can join the hangout with people want to discuss security more
<mdeslaur> s/with/if/
<zebaszp> but with mobile apps, you don't need much more than that
<alecu> o/
<zebaszp> when apps upgrade to major revisions, though, they tend to do an advert-like changelog
<xnox> In app purchases, addons, extensions?
<zebaszp> like "We've redesigned the whole interface so it is now easier to do x and y", and that sort of thing
<dobey> i wrote an alternate package manager once
<xnox> are those going to be implemented? or those will be separate apps? (e.g. a free app and a paid app)
<brunogirin> achiang: you're probably right, it could be a future extension to enable the Ubuntu app store to validate the quality of an app (or lack thereof)
<mdeslaur> Users should be able to rate apps
<mdeslaur> I don't think the platform is in a good position to be rating developer's apps
<dobey> cjwatson: if it's all abstracted behind aptdaemon on the client, does it matter much?
<beuno> yes, we have ratings and reviews
<dobey> aquarius_uds: similar to when all branches on lp were upgraded to bzr v2 format
<zebaszp> beuno, on USC, yes, but what about Touch? I thought the Dash would replace USC, can we rate apps from there?
<brunogirin> QUESTION: ideally, we'd want to minimise app dev's effort to re-package apps from one release to another: how can we do that?
<zebaszp> is there/will there be one-click packaging on QtCreator or something along those lines?
<alecu> brunogirin: good point. My guess is that packages should work from release to release
<dobey> zebaszp: it would be part of the "preview" in the dash, i'd suspect
<beuno> zebaszp, yes, the plan is to keep using the same system
<cjwatson> this is mainly an SDK job to maintain maximal compatibility
<cjwatson> if you look at the format as present, it has a framework field so that you can pick different versions if need be
<jdstrand> beuno: maybe I misheard-- I thought we would have a gate on manual review (even if that was not an in depth review)?
<mdeslaur> I assume device compatibility via capabilities is going to be in the manifest file, and needs to be looked into server-side
<beuno> jdstrand, we will have a manual review stage, yes
<jdstrand> ok
<beuno> how in depth, I can't say  :)
<jdstrand> sure
<davmor22> QUESTION:  is there a danger here that more space will be taken up if the apps are installing all their own libs?   Also is there not more chance of malicious software being hidden in libs attached to apps?
<brunogirin> alecu: yes, otherwise you release a new version of Ubuntu and some take several months to be updated or are never updated at all
<zebaszp> yay! :D
<dobey> does the SDK currently do cross-compiling for all the necessary archs?
<cjwatson> davmor22: (a) yes if taken too far, but the primary focus is apps built against the SDK (b) apparmor confinement
<cjwatson> dobey: we have a need to discuss cross-compiling with the SDK folks in detail
<cjwatson> aiui it doesn't yet
<cjwatson> imo it should :)
<dobey> ok
<dobey> right, it will have to if developers are going to upload binaries
<zebaszp> just looking at his face, rickspencer3 is not amused
<beuno> productized!
<cjwatson> beuno: bingo
<dobey> arm, i386, x86_64 at least
<beuno> ralsina1, you listening?  :)
<aquarius_uds> ralsina1:ping :)
<xnox> well, mostly =)
<geofft> QUESTION: So this clearly isn't in the space of 0installer/listaller/etc. now, given sandboxing. Is the plan  explicitly that it never will be?
<dobey> beuno: alecu and i are at least
<ralsina1> Sure!
<geofft> Namely, for an ISV (like my workplace) that sells software that's inherently unsandboxable, this is sounding less interesting than it originally sounded
<geofft> Which is not a complaint, just worth knowing.
<xnox> geofft: nothing is set in stone. But so far for really large apps (compiled with their own libraries and large / precise dependenices) .deb and normal apt archive is the best way to go.
<zebaszp> QUESTION: why isn't Rick as cheerful as the rest?
<rickspencer3> hi zebaszp
<zebaszp> I want to hear you laugh :P
<rickspencer3> HA HA HA
<rickspencer3> ?
<xnox> geofft: e.g. skype is a .deb multi-arched and in canonical partner repository. I'd be expecting that on the desktop for a while still.
<dholbach> thanks everyone!
<aquarius_uds> ralsina1: so, could you please track the work items that arise from the app lens design in the click packages blueprint?
<zebaszp> that doesn't count :(
<xnox> geofft: it's not sandboxable it should be on ubuntu phones =/
<geofft> xnox: I'm also thinking of the companies who currently distribute things via RPM or .tgz only.
<cjwatson> geofft: the plan is, at least, to always require sandboxing for this; one of the purposes is to use that so that apps don't get snarled up in indefinitely long review queues
* udsbotu changed the topic of #ubuntu-uds-foundations-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1305//foundations-1/ - http://ubottu.com/udslog/%23ubuntu-uds-foundations-1
<zebaszp> oh! 1 hour break!
<cjwatson> geofft: so if sandboxing is literally impossible for your application (why?), then I would say it's out of scope
<aquarius_uds> I would be interested to hear why an app is unsandboxable, too
<cjwatson> geofft: as I said earlier in the session, I'm intentionally not trying to supersede all uses of .debs
<geofft> cjwatson: Well, the primary thing we sell is desktop virtualization :)
<geofft> So unless there's an apparmor profile that lets us get to the virtualization interfaces, well....
<geofft> I'm also thinking of things (both from my company and others) like backup clients that read everything in your homedir or your system
<cjwatson> there will certainly be situations where .debs are still required/useful, and I don't think e.g. that it would be worth spending lots of time going through and converting the Ubuntu archive (for one thing, we'd be taking on an incremental maintenance commitment by doing that)
<cjwatson> I think mdeslaur would have to speak to the specifics of confining such things
<cjwatson> both whether it's possible and whether it's useful
<dobey> geofft: i presume sandboxed wouldn not preclude a way to allow the user to say an app is allowed to access certain data
<geofft> I was curious if this would be useful as a simpler replacement for .deb for companies that can barely be bothered to distribute RPMs.
<cjwatson> however I'm reminded of the fact that Android has a permission called "BRICK"
<jdstrand> geofft: they can be confined, but required hand-crafted profiles. that is out of scope for apps in the app store in the shrot term
<jdstrand> short
<dobey> geofft: facebook app for example would want to access your photos, so you could upload them, for example
<cjwatson> that doesn't necessarily render them out of scope for this package format / independent distribution though
<dobey> doh, i said "for example" twice there
<jdstrand> you can still use apparmor with debs, etc, so like cjwatson said, that is always available
<geofft> jdstrand: if the implication is "possibly okay in the long term", cool!
<mdeslaur> geofft: I'm missing some context...you want to get your application in the app store?
<cjwatson> FWIW, I think sandboxing is kind of orthogonal to listaller/0install/etc.
<zebaszp> examples, examples, examples! </ballmer>
<cjwatson> in that the thing that executes apps is (in principle, mostly) independent of the thing that installs them
<cjwatson> 0install does define a "how to run this app" command for each app
<geofft> mdeslaur: I'm mostly just thinking about proprietary apps I've run as a user that distribute themselves as poorly-made RPMs.
<cjwatson> listaller probably does too (haven't looked in detail), and we clearly need to
<geofft> So, like, IBM's TSM backup client, VMware Player (which isn't even an RPM), proprietary VPN clients, ....
<dobey> i must be off though, as that session ate through my normal lunch time. :)
<geofft> From the description of "better format for people who don't care about Debian packaging complexities", it sounds like it fits those.
<mdeslaur> geofft: well, a backup client is a bit special, but the other apps you've mentioned should work file with both the packaging format, and the app confinement
<geofft> From the description "and sandboxing", it sounds like it fits none of those, so I'm just realigning my expectations
<cjwatson> don't care and can't be persuaded to care :)
<mdeslaur> geofft: if you're just looking for a way to distribute your stuff internally, the click package format is just a simplified deb at the moment, so you have nothing to gain from using that vs. regular debs
<mdeslaur> geofft: and the deb format is just an archive really...you don't need a source package to create one
<geofft> Yeah. Work is currently using actual debs (slightly less than actual source packages) and actual CDBS.
<cjwatson> right, I think if you already have in-house .deb experience the gains are less interesting
<geofft> _I'm_ happy to do Debian packaging, but not everyone is.
<geofft> OK.
<cjwatson> in that a sizeable part of this is simplifying things for app developers
<cjwatson> now, there *are* other gaisn
<cjwatson> *gains
<mdeslaur> geofft: so instead of generating your .deb files from source packages, just create them as an archive
<cjwatson> things like speed of app installation, guaranteed independence if things go wrong - at the cost of flexibility though
<cjwatson> so it depends, if you were relying on being able to do non-trivial maintainer script things, you're probably still better off with .debs
<cjwatson> if it's "unpack a filesystem tree", this might be simpler
 * cjwatson <- not a salesman
<geofft> Sounds reasonable
<kiwinote> so the app store server will allow us to upload deb files as well as click packages?
<kiwinote> or does deb files imply an own distribution channel?
<cjwatson> not in v1 at least; I think if you're doing debs you might consider getting them into Ubuntu (if appropriate) or partner (if appropriate)
<xnox> kiwinote: correct. debs should go into PPA / Ubuntu Archive / self-hosted and will not be available to install on the phone. initially at least.
<cjwatson> err, "not be available to install on the phone" is a strong statement, you mean through the dash integration stuff
<xnox> kiwinote: there is also myapps / extras.ubuntu.com for deb apps.
<kiwinote> thanks, looks like canonical partners seems the best fit here
<xnox> cjwatson: normal debs -> imply writable root-fs -> which we do not have, until convergence is delivered & enabled.
<cjwatson> https://wiki.ubuntu.com/ImageBasedUpgrades calls for a switch to enable apt
<xnox> true.
<cjwatson> and nothing to stop you reflashing with extra things installed ... anyway I'm mostly just objecting to the use of categorical negative statements that are likely to scare people :)
 * xnox looks at my "convergence" poster again =) sure normal debs will need to start working rather sooner than later.
 * xnox off to find lunch.
 * cjwatson -> dinner
* udsbotu changed the topic of #ubuntu-uds-foundations-1 to: Track: Foundations | Image based updates | Url: http://summit.ubuntu.com/uds-1305/meeting/21725/foundations-1305-image-based-updates/
<cjwatson> https://plus.google.com/hangouts/_/00c6326d8b41453b4fabc6512864290fa41cf78a?authuser=1&hl=en-GB
<cjwatson> on air now
<diwic> cjwatson, still "starting soon..." here
<apw> no sign of the stream on the u-tube bit
<lool> started here after reloading
<mfisch> diwic: thats youtube being stupid, force reload several times
<lool> reload the page
<diwic> tried that, this time it worked though
<apw> what junk ... there now
<cjwatson> diwic: there's a time lag
<diwic> cjwatson, btw last session one could see the background color of your screen reflecting in your face :-)
<zyga> hi
<jdstrand> information disclosure
<cjwatson> diwic: heh, not much I can do about the lighting in this room - wasn't designed for video
<timrc> achiang: always get a kick out of your profile picture
<stgraber> https://wiki.ubuntu.com/ImageBasedUpgrades
 * achiang is on video mute because eating lunch now (i had another call last hour)
 * lool hasn't joined the HO but is watching and might jump in later
<ogra_> rsalveti,
<ogra_> oops
<gQuigs> anyone have direct youtube link?
<gema> gQuigs: for joining the hangout or just watching?
<gQuigs> gema: just watching
<zyga> QUESTION: stgraber, does that mean the recovery partition and the upgader itself cannot be upgraded if they have issues?
<gema> gQuigs: http://www.youtube.com/watch?feature=player_embedded&v=Nddn4duIR2c
<gQuigs> thanks gema
<lool> zyga: they can be upgraded just like all the android bits can be upgraded including the bootloader
<cjwatson> stgraber: sure, sorry
<gema> gQuigs: you just need to click on the embedded version of the videos where it says "YouTube" and it takes you there, no probs
<zyga> lool: thanks
<lool> but we likely wouldn't do this too frequently
<Laney> is there going to be any UI for the apt update route?
<gQuigs> gema: wasn't loading for me at all... oh.. because I'm on the wrong talk :/ oops
<gema> ;)
<lool> stgraber: FYI, green on black a bit hard to read over stream; white on black or black on white might be better
<stgraber> zyga: the update may contain changes to any partition including the android bits, basedband or even recovery partition
<zyga> stgraber: interesting, thanks
<zyga> stgraber: and totally impressive demo
<gema> cjwatson: can you unclick stgraber?
<gema> so that others take the screen when talking
<victorp> stgraber, how are system configurations, like operator branding is kept at update time. I am assuming it is not stored on the data partition
<cjwatson> gema: done
<gema> cjwatson: ta!
<victorp> stgraber, so is that file then automatically re-install in an update?
<Laney> so operators and oems would have to offer an apt archive too, right?
<stgraber> victorp: yes, it'd appear as if it was part of our read-only base system
<zebaszp> QUESTION: what about superphones/desktop-capable mobile devices? how would you update those, do you disable apt for the base system packages?
<stgraber> Laney: nope, they'd have to provide us with a .tar.xz overlay to apply on our base system
<Laney> stgraber: but you can get yourself out of overlay upgrade mode
<geofft> who generates the diff images? I guess this is part of the server?
<stgraber> right, in which case those bits will likely not be updated
<victorp> stgraber, lool are default apps installed in the system partition?
<sergiusens> ogra_: yeah, how are ports going to be maintained?
<victorp> ogra_, yes with rickspencer3 branding
<victorp> :)
<Laney> hmm
<victorp> ogra_, shouldnt we give the community the option to have the same set up?
<infinity> ogra_: Is there any reason we need to have enough Android userspace installed that these weird directories are being created?
<ogra_> infinity, persistent properties are stored in direcories and files in /userdata
<infinity> ogra_: I don't see why we need the bits that create all that junk if what we really need is just a libc and a few binary drivers.
<sergiusens> victorp: not all devices are _fastboot_ devices and simple to tinker with
<victorp> sergiusens,  agreed, I thought we were talking about the "official" community devices that we produce images for
<victorp> rather than all devices
<TheMuso> infinity: Thats the impression I was under as well.
<infinity> It sounds to me like we're including more of Android's userspace than we actually need.
<victorp> infinity, we are using more than that right now
<infinity> But that's probably out of scope for this conversation.
<ogra_> infinity, we include HAL, all sensor drivers and userspace tools, the audio system etc .... and the platform-api makes use of these
<sergiusens> infinity: not really
<victorp> ogra_, seems like you need another session for that?
<apw> it seems like this is getting into rather tooo detailed, it sounds like the two sides need to get together offline and "work it out"
<victorp> that = partitions and folders
<victorp> apw, +1
<ogra_> victorp, well, we're short on free slots
<victorp> ogra_, make one slot with you, lool and stgraber :)
<ogra_> as long as the syystem can adapt i'm happy though
<victorp> ogra_, adapt and assimilate
<sergiusens> ogra_: if that happens include me in the slot as some of that work will fall onto me
<ogra_> fine with me, i just dont want to find out by end of the month that what i implemented will never work :)
<ogra_> sergiusens, sure
 * victorp hugs ogra_
 * ogra_ hugs victorp 
<lool> (I hear nice bird cheeps coming from one of the streams)
<ogra_> might be me
<ogra_> i have the window open
<victorp> very relaxing
<timrc> Bird Song as a Service
<ogra_> heh
<cjwatson> acronym isn't great
<infinity> I prefer Bird as a Service.
<lool> victorp: apps provided with the system are installed in the system partition for now; I've suggested that we could possibly bundle them as .click packages and install them on first boot in the future, but it seems it's a bit early to consider this
<ogra_> pidgin mail ?
<victorp> lool, sure , makes sense
<victorp> lool, it would be nice for all apps to be manage/upgraded the same way
<lool> true
<victorp> as long as you can install newer versions of apps in the system partition as clicks so you dont have to wait for updates that maybe gated on who knows what
<sergiusens> cjwatson: I guess you can start with the community core apps
<victorp> lool, ^
<cjwatson> victorp: that's definitely a new technical requirement - may be interesting issues with having different versions of apps installed in different places
<apw> presumably the image updater does not care what format they are
<lool> victorp: exactly; there's no reason that the app update frequency and OS update frequency need to match; especially for e.g. OEM apps
<infinity> There's nothing wrong with the Android-style hybrid of having a package both in the base system AND in the store.
<cjwatson> it doesn't but click-package certainly would :)
<infinity> Assuming we can overlay that sanely.
<sergiusens> infinity: +1
<cjwatson> we'd need to make sure that the app executor can cope, basically
<infinity> The upshot of the Android hybrid model is that if your store app update explodes, you can remove it and you're back to the base system core apps that work.
<lool> any other question from anyone?
<victorp> cjwatson, that happens lots where a manufacturer install a partner app as part of the system but then the publisher releases newer version for the store
<gema> what kind of testing are we planning on this?
<victorp> e.g. dropbox
<cjwatson> infinity: do they just have an executor that looks in both places?
<timrc> Is there going to be a rollback feature?
<apw> stgraber, i have been adding what I am _hearing_ as actions, they should be reviewed before the end in case I miss understood
<sergiusens> lool: is it going to be possible to rollback?
<apw> stgraber, and some need owners if they are right
<infinity> cjwatson: I'm not sure, TBH, how that works.  The older version just "disappears" from the UI until you uninstall the new one.
<infinity> cjwatson: On the underside, I'm not sure what they're doing.
<lool> sergiusens: oh that's a good one
<gema> QUESTION: What about testing, what are you guys going to do/expect from QA?
<geofft> Are there plans / thoughts to make this work on the desktop?
<victorp> sergiusens, +1
<geofft> It sounds like all this discussion is very Android-specific.
<zebaszp> QUESTION (I asked this earlier): what about superphones/desktop-capable mobile devices? how would you update those, do you disable apt for the base system packages?
<timrc> sergiusens: was that coincidence that we asked the same question?
<sergiusens> timrc: interesting, didn't see it.
<timrc> sergiusens: freaky
<sergiusens> timrc: but it had to be asked... today we have lots of mechanisms to move around
<gema> ack
<lool> ah it's actually timrc's question too
<apw> QUESTION: how are these updates going to interact with the propose 'staggered updates' we are moving to for .debs ?
<cjwatson> YM phased updates I think?
<victorp> zebaszp, superphones are first of all phones. So i will assume they update more like phones that desktop for the core base packages
<lool> sergiusens, timrc: Will ask as soon as the current discussion ends
<apw> cjwatson, indeed phased
<timrc> lool: Thanks
<zebaszp> thanks victorp, but then what happens to non-core user-installed desktop packages?
<lool> (URL rewrites basically)
<victorp> zebaszp, indeed what happens
<lool> e.g. channels.json?model=galaxy-nexus&country=fr
<lool> zebaszp: these are installed in the userdata partition
<victorp> zebaszp, if they are store in the data partition
<mwilley> It would be interesting to apply these techniques on the desktop as well; is it considered? Â Something like a chromebook.
<lool> which is not updated
<victorp> then they can be updated with apt, they wont be wiped by this, but it creates an interesting game with dependecies
<ogra_> mwilley, if it proves to be good, i dont see why not
<lool> mwilley: it's definitley something we'd like to apply to desktop, but we will need to study the additional requirements for converging with desktop use cases and supporting the installed userbase
<victorp> mwilley, agreed - this is interesting for some desktops and thinclients
<victorp> lool, 14.04 :)
<rsalveti> "developer" mode :-)
<victorp> stgraber, so you can't install .deb packages in the userdata partition?
<lool> no; unless you are root and create a whole Ubuntu chroot there  :-)
<xnox> well it will be an "upgrade", whice leaves things rw & offers no other upgrade paths.
<ogra_> rsalveti, and we'll make them tap 8 times !!!
<sergiusens> lool: how is convergence going to be taken into account then?
<rsalveti> ogra_: o/
<ogra_> muhahaha
<victorp> lool, does that work for a converge device?
<sergiusens> ah, youtube lag answered my question :-P
<xnox> sergiusens: not targeted for 13.10.
<victorp> alright stgraber just answer my question
<rsalveti> and not properly planned I'd guess
<lool> great
<lool> any other question?
<victorp> stgraber, that needs some thinking about for 14.04
<Laney> how will we be delivering SRUs?
<barry> lp:~barry/+junk/resolver
<Laney> rolling them up into a weekly image or something?
<ogra_> weekly ?
<barry> (probably needs a better name + a real lp project page)
<lool> victorp: we've actually discussed it in the past, but didn't settle on a design for this
<stgraber> https://phablet.stgraber.org
<xnox> Laney: monthly delta image.
<geofft> There's some mention in the blueprint about multiple /var/lib/dpkgs etc. Did that end up being relevant?
<ogra_> yeah, monthly sounds more like it
<victorp> lool, I agree that it doesnt not need to be solved for 13.10
<geofft> (I'm interested in that for a couple of reasons, only one of which is an implementation of image-based updates)
<xnox> geofft: that's rough plans at how to handle convergence.
<timrc> so if I skip 10 updates, and then update, will I have 10 separate updates in tandem to do?
<geofft> xnox: So not relevant for a pure image-based system, until apt starts being user-exposed?
<xnox> and having some ReadOnly dpkg packages while others RW.
<lool> victorp: one approach could be to have split dpkg/apt databases between system and userdata, but that brings some issues with it that I think stgraber was listing; another approach would be to maintain an Ubuntu chroot under the userdata partition and update it like an app -- a bit like the Ubuntu for Android idea
<achiang> timrc: it depends on what kind of user you are
<xnox> timrc: if upgrader calculates, that a full image is quicker, it will simply take that.
<xnox> geofft: correct.
<timrc> xnox: okay
<victorp> lool, that is what I was thinking
<geofft> OK. Idly, is there current work towards that in some bzr branch or something?
<lool> geofft: it's definitely one of the two approaches that we're considering
<xnox> timrc: see stephane's demo earlier.
<geofft> I was half wanting to fiddle with that in my spare time
<jsjgruber-uds> QUESTION: When would the updates happen so the user isn't impacted by the reboot?
<victorp> lool, anyway - we should understand it better by october, via UfA work
<stgraber> server code: https://code.launchpad.net/~stgraber/+junk/phablet-update
<victorp> and we can talk again then
<timrc> jsjgruber-uds: when you open the kindle app and get into a good book
<stgraber> client code: https://code.launchpad.net/~barry/+junk/resolver
<lool> victorp: exactly; also, we will have had some experience with these image based updates and a better understanding of them too
<timrc> (my experience with android :))
<achiang> timrc: that will be the model for commercial phones -- you have to do upates in serial
<victorp> timrc, user error... stop reading books and the world will be better
<victorp> :)
<achiang> timrc: however, note that for a commercial phone, it won't be 10 updates, but more like 1 or 2 over the life of the device
<timrc> achiang: aye
<lool> achiang: depends
<ogra_> totally
<timrc> victorp: hah
<victorp> timrc, also the download will be done in the background (wifi only) so you would not know
 * barry enjoys the relaxing birdsong in the last few minutes
<Laney> will we have a way of presenting the changes?
<apw> presumably we will be taking into account whether they have b/w for this
<Laney> so you can see how much you want to reboot or not
<sergiusens> achiang: well you could do like the chromebook and subscribe to the _developer channel_
<apw> for example being on wifi does not mean i want updates, i may be proxying 3g onto wifi for example
<infinity> apw: Some people have ISPs that show up within a few days of them moving in.
<apw> *slap*
<infinity> apw: Don't let your BT bitterness colour spec writing.
<apw> infinity, i think i was just asking for 'download when i click only' 'download on wifi' 'download immediatly always' as option
<chiluk> that actually brings about an important issue.  has it been made possible to only pull updates over wifi?
<Laney> I suppose there should be a system API for this
<infinity> apw: (And yes, "always", "wifi", "manual" seem to be the usual choices for this sort of thing)
<Laney> it'll affect e.g. uploading pictures too
<sergiusens> stgraber: is this new recovery image going to be backwards compatible with update.zips ?
<apw> infinity, design tends to not like usual options
<mwilley> Agreed on "wifi" does not necessarily mean open season on downloads. Â My "wifi" is actually a bandwidth-capped satellite connection half the time.
<ogra_> sergiusens, as i understood it will be just an ubuntu initrd
<ogra_> with special scripts etc
<infinity> Laney: On the one hand, I like the idea of a system wide "when to abuse my bandwidth" setting, on the other hand, updates are hugely different from when to upload a picture or something.
<sergiusens> ogra_: well, for non fastboot phones, updating recovery is a dangerous operation :-)
<ogra_> sergiusens, well, dd :)
<geofft> yeah, an NM interface for "am I on a reasonable connection or not" would be great
<ogra_> just dont run out of power
<apw> stgraber, some of us are saying being on WIFI is not enough to know my b/w is free
<geofft> on desktop, that may want to be conditionalized by e.g. what ESSID I'm on
<Laney> not according to whether Three decide to raid my walle they aren't, sadly
<sergiusens> ogra_: so if I were a person (which I think I am) I would want to move from cyanogenmod to ubuntu touch perhaps, but just use one compatible recovery mechanism
<Laney> but I might want to prioritise its usage, yeah
* udsbotu changed the topic of #ubuntu-uds-foundations-1 to: Track: Foundations | Ubuntu Kernel - Misc Topics | Url: http://summit.ubuntu.com/uds-1305/meeting/21777/foundations-1305-kernel/
<geofft> e.g. the desktop apt daemon should download updates when I'm at home or work, but not on a tethered phone or at Starbucks
<ogra_> sergiusens, well, you would pull the zip for your device (using phablet-flash) ... and that zip would replace the recovery part.
<lool> geofft: I think these are great ideas; it's hard to factor them in at this point though as we don't even run the basic mobile update features yet, but they seem like good convergence features
<mwilley> I like the NetworkManager bandwith guide idea. Â Time of use can be expressed too. Â B/W free on my satellite during middle night.
<sergiusens> ogra_: not on non fastboot devices ;-)
<stgraber> sergiusens: the current work for the recovery image is a remastered cyanogenmod recovery partition with added tar, xz and gpg support, so in theory there's nothing preventing us from support update.zip in there but it's not a priority as it's not the update format we'll be using
<ogasawara> cjwatson: do I ping your or bdmurray for hangout url for next foundations session?
<ogra_> sergiusens, what non fastboot devices are there that we support atm ?
<cjwatson> ogasawara: I believe bdmurray will be running it
<sergiusens> ogra_: thinking about community here
<ogasawara> cjwatson: ack, thanks
<cjwatson> I've run three in a row now :)
<cjwatson> well, been crew for, anyway ...
<ogra_> sergiusens, well, they use android based phones atm ... and thats using fastboot mostly
 * timrc pretends he's eating a churro and drinking a coke while he waits for the next session
<ogra_> and as long as our platform-api is so closely bound to android i dont see that changing
<ara> timrc, lol
<sergiusens> timrc: you can do it for real too :-P
<cjwatson> bdmurray: ...
 * rsalveti waves for the kernel session
<bdmurray> cjwatson: setting it up
<cjwatson> cool
<cjwatson> you seem to be on air now
<lool> yup
<cjwatson> (lower third reminder)
<timrc> birds singing, white noiseâ¦ are you people trying to put me to sleep?
<smb> Hm, is it just breaking up a lot for me?
<jmleddy> I don't hear anything
<jmleddy> there is a lot of static
<jmleddy> that just went away for a little bit
<lool> ogasawara: there is like a white scratch noise, but no feedback on the stream
<mdeslaur> ogasawara: I hear you
<kamal-uds> the audio sounds fine to me, no feedback
<timrc> Yeah lots of static but it went away for a spell
<sforshee> ogasawara, do you have the youtube stream open?
<lool> ogasawara: do you have a tab of the meeting open?
<jdstrand> ogasawara: do you have your google+ and your etherpad/etal window open? I recommend pausing the one next to the etherpad
<bdmurray> I think she sorted it out now
<jmleddy> what happened to phb-crystal-ball?
<lool> ogasawara: these are just desktop (non-touch) kernels, right?
<vanhoof> jmleddy: http://phb-crystal-ball.org/
<bubbly> I would, as of currently, say 3.11.x if all possible
<jmleddy> oh nice, it's back up
<jmleddy> vanhoof: thanks
<rtg_> lool, correct
<xnox> the video feed says "please stand by"
<xnox> are we on air?
<lool> xnox: it's on
<lool> xnox: reload maybe
<TheMuso> I'm getting video here.
<ppisati> AFA arm is concerned, 3.11 is way better if we want to ad exynos5 support to -generic
<xnox> ah, yeah came up now.
<ppisati> rtg_: correct
<ppisati> ogasawara: ^
<lool> ppisati: aren't we tracking android kernel trees for each target touch SoC anyway?
<ppisati> lool: yep, talking about desktop here
<vanhoof> ppisati: +1 exynos5 in generic, ike is involved there, ogasawara ^
<lool> ppisati: ah exynos5 is a desktop target too?  ok
<bubbly> My opinion, if the generic flavuor doesn't fit your liking, compile your own kernel
<ppisati> lool: i've no idea if there's any exysno5 project going on, just an observation
<rsalveti> cool, should be able to test nexus 10 later today
<lool> ppisati: ack
 * ppisati notes the video stream is really crappy here... :(
<smb> ppisati, Same here
<jdstrand> ogasawara: we discussed that there might be something we can do with update-manager as well
<jjohansen> ogasawara: yep from security team
<jdstrand> ogasawara: like a one-time 'this kernel is EOL, blahblah...'
<ara> QUESTION: can you elaborate more on that, please?
<ara> why we are not upgrading people?
<ogra_> ara, nope, only software
<ogra_> :)
<ara> ogra_, lol
<ara> I certainly need an upgrade
<ara> it is time for ara 2.0
<ogra_> nah, you are good
<jmleddy> heh
<xnox> ogasawara: why was that in place before? or was that decision post-poned until there is a second backport kernel?
 * ogra_ wonders why the stream is so choppy this session
<apw> ogra_,  i have found a reload on the stream can help when that happens
<cjwatson> I'm not sure how much of it depends on the person running the hangout
<jmleddy> wasn't it always that way?
<ara> thanks
<cjwatson> but it's bizarre that anyone else running the hangout might make it *worse* than me doing so
<jmleddy> or are you talking about the images?
 * ogra_ reloads
<bjf> ogra_, bdmurray is running the session on a nexus4
<ogra_> haha
<cjwatson> unless it's CPU-dependent rather than network-dependent
<ogra_> really ?!?
<apw> any further questions, #ubuntu-kernel on freenode
 * smb blames the UK people with big pipes draining the bits
<bubbly> I don't upgrade becauseof hardware issues
<jmleddy> if it isn't broke don't fix it
<ara> we are still getting a new HWE stack in 12.04.3?
<ara> QUESTIOn: ^
<apw> smb, you just need to spend some more of your hard currency, harder than mine anyhow
<gQuigs> ara: yea.. I remember something about raring not getting a backport to 12.04.2
<apw> ara ask that again over on #ubuntu-kernel, folk have gone
<gQuigs> ^
<jmleddy> ara: I think so, it's just not going to be automatic upgrade
<xnox> ara: i think there was consultation, and in the beginning there wasn't going to be one, but than later there was demand for it, so it should be there. but my info can be out of date =) ping ogasawara on #ubuntu-kernel.
<kentb> ara: afaik that is the plan (to have a 12.04.3 stack) and like jmleddy siad, no automatic upgrade. OEM's like Dell are really relying on an HWE stack for 12.04.3 because of new server hardware rolling out later this year.
<cjwatson> xnox: er, or she's in the session right here :)
<xnox> "This live event is over" =)))))))
<smb> xnox, better than "this life event is over" :-p
<xnox> smb: "this second life is over" :DDDDD
<smb> thankfully, this first one is depressing enough 3:)
* udsbotu changed the topic of #ubuntu-uds-foundations-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1305//foundations-1/ - http://ubottu.com/udslog/%23ubuntu-uds-foundations-1
* udsbotu changed the topic of #ubuntu-uds-foundations-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1305/foundations-1/ - http://ubottu.com/udslog/%23ubuntu-uds-foundations-1
#ubuntu-uds-foundations-1 2013-05-15
<SleepyJeremy> hello
<geofft> you're a little late, if you were intending to show up for one of the sessions :)
<SleepyJeremy> understood
<SleepyJeremy> I was under a firewall when the session I was interested was on
<SleepyJeremy> a.k.a. @work
<SleepyJeremy> :)
<SleepyJeremy> anybody on from the "Next steps for the click-package prototype for simplified app package installation" session? Or who knows about the app packaging model being proposed for ubuntu touch/phone?
<geofft> You should be able to watch the video recording, from the summit page
<geofft> and see the Etherpad notes.
<geofft> #ubuntu-devel is probably a better channel to find folks
<SleepyJeremy> ah ok
<SleepyJeremy> I tried that before, kept being pushed into #ubuntu-touch which nobody is ever watching
* udsbotu changed the topic of #ubuntu-uds-foundations-1 to: Track: Foundations | Further improvements to the Checkbox release process | Url: http://summit.ubuntu.com/uds-1305/meeting/21743/foundations-1305-checkbox-release-process/
<zyga> hi
<zyga> brendand: so you're leading this one as well>?
<roadmr> hey!
<brendand> zyga, indeed
<brendand> seems this is starting in 3 mins
<brendand> brb
<zyga> brendand: ok, paste the hangout link when ready
<roadmr> do we know who'll be helping us with the hangout and stuff?
<bdmurray> I will
<zyga-uds> bdmurray:thanks
<roadmr> bdmurray: thanks! good morning!
<spineau> Could someone paste the hangout url again?
<spineau> please
<brendand> bdmurray, paste the link here
<roadmr> spineau: I don't think we have it yet
<bdmurray> https://plus.google.com/hangouts/_/21d0b82e4f2532f0af0e595e8d62e13abb019da2?authuser=0&hl=en
<spineau> roadmr: ok, I'm not late then :)
<bladernr`> whats the link to the BP?
<roadmr> https://blueprints.launchpad.net/certify-planning/+spec/foundations-1305-checkbox-release-process
<bladernr`> thanks
<jeffreyc> yes, CE QA is really happy with current process
<bladernr`> can you join the hangout jeffreyc
<bladernr`> https://plus.google.com/hangouts/_/21d0b82e4f2532f0af0e595e8d62e13abb019da2?authuser=0&hl=en
<ara> hello
<roadmr> ara: hi!
<roadmr> ara: https://plus.google.com/hangouts/_/21d0b82e4f2532f0af0e595e8d62e13abb019da2
<ara> roadmr, I will stay on IRC, for the 10 minutes that lasts
<ara> but thanks :)
<roadmr> ara: ok :)
<ara> zyga, a schedule
<ara> zyga, and when
<spideyman> can I vote that we only put changes/bug fix note about checkbox core into the changelog? Remove the cruft of job and individual script updates?
<ara> spideyman, that would never be accepted in Ubuntu
<spideyman> meh...then we probably need to decouple them from checkbox.
<ara> spideyman, yes, that I agree :)
<cjwatson> You can still summarise changes in Ubuntu though; they don't have to be commit-level or anything
<cjwatson> Or you could treat it as an upstream tarball, where we frequently have changes only in upstream changelogs/NEWS files or whatever and don't repeat them in debian/changelog
<cjwatson> Various possibilities
* udsbotu changed the topic of #ubuntu-uds-foundations-1 to: Track: Foundations | Kubuntu and UEFI and LTS Backports | Url: http://summit.ubuntu.com/uds-1305/meeting/21779/kubuntu-and-uefi-and-lts-backports/
<roadmr> cjwatson: thanks!
<zyga-uds> indeed, thanks
<zyga> ara: what did you mean by 'a schedule and when'?
<roadmr> ara: do you know how to go about scheduling another session for tomorrow?
<cjwatson> starting up hangout now
<cjwatson> roadmr: ask a suitable track lead
<cjwatson> (may or may not be space)
<roadmr> cjwatson: oh ok thanks :)
<Riddell> afternoon
<brendand> running sessions is tiring :)
<cjwatson> Kubuntu/UEFI/LTS hangout: https://plus.google.com/hangouts/_/6f16a08fd55e3e6db336ef84515052124bef0e8f?authuser=1&hl=en-GB
<ara> zyga, I meant scheduling the work to be done
<zyga> ara: scheduling the packaging changes? ok
<cjwatson> (should I expect Kubuntu folks in the hangout?  I'm not certain whether you have the google hangout plugin sorted and such)
<cjwatson> ah, there
<Riddell> txwikinger: ?
<cjwatson> txwikinger,xnox: are you joining the hangout?
<Riddell> apw subscribed too?
 * apw is just watching
<xnox> cjwatson: i'm watching from a libary. I can provide a pretty picture with a backdrop, but can't speak out loud.
<xnox> =)
<xnox> (unless I move elsewhere)
<xnox> I'd rather chat on irc.
<apw> cjwatson, i can see it
<xnox> \o/
<Riddell> http://blogs.kde.org/2013/05/09/breakouts-uefi
<xnox> cjwatson: Riddell: isn't this more about SB, rather than just UEFI.
<skellat> Any of you have working cameras?
<cjwatson> I have mine turned off
<cjwatson> I mean if you *really* want to see my ugly mug :P
<Riddell> mine doesn't seem to work today
<Riddell> xnox: about SB?
<bubbly193> no camera here
<bubbly193> unless it decides to work
<xnox> well, reading the blog post, it is a bit confusing as to what happened there. i only ever always had a single efi partition =/
<apw> b 43
<cjwatson> Bug 1167622
<udsbotu> Ubuntu bug 1167622 in linux (Ubuntu) "Cannot change EFI variables using efibootmgr (raring regression)" [Medium,Confirmed] https://launchpad.net/bugs/1167622
<cjwatson> That bug seems to be the root cause of the Kubuntu failure here
<cjwatson> I'm not sure why it didn't break Ubuntu as well
<cjwatson> Could be related to Kubuntu not using a signed kernel, I suppose, which would mean it would be booted slightly differently
<apw> cjwatson, we would indeed boot rather differently if we are not using a signed kernel
<apw> bug 1178294
<udsbotu> Ubuntu bug 1178294 in ubiquity (Ubuntu) "Install fails with Kubuntu 13.04 on UEFI system" [Undecided,Confirmed] https://launchpad.net/bugs/1178294
<cjwatson> apw: can you comment on 1167622?  would that cause the precise symptom in 1178294?
<cjwatson> the failure there seems to be "bricks system" rather than "causes set_variable to fail"
<apw> May 9 16:52:54 kubuntu ubiquity: Can't access efivars filesystem at /sys/firmware/efi/efivars, aborting
<apw> that implies we did not have any access to the efivars at all, perhaps as a result of the mode
<apw> ie not being booted into via the efi entry point
<apw> on the '50% full' issue for nvram there have been some re-re-re-fixing in the handling of sizes
<cking> bug 1167622 gets an efi "EFI_OUT_OF_RESOURCES" error, so it looks like there is not enough free EFI NVRAM free
<udsbotu> Ubuntu bug 1167622 in linux (Ubuntu) "Cannot change EFI variables using efibootmgr (raring regression)" [Medium,Confirmed] https://launchpad.net/bugs/1167622
<apw> cking, that might be one of those corner cases the later kernels have worked round, where the firmware lies in some of the size responses
<cking> yep, or just lame firmware that can't be worked around, hard to tell
<apw> indeed
<cjwatson> damn, lost my connection
 * cjwatson attempts to reconnect but isn't hopeful
 * cking notes any EFI status  8000000000000009 means there isn't enough variable space, but we are at the mercy of the EFI run time services so who knows why it really failed
<apw> cjwatson, i think kernel concurs with your position, that we should get kubuntu using the signed kerenl and then review the remaining issues, the rest ought to be common to ubuntu as well
<apw> Riddell, is it you who has the list of bugs found during the install, those should be in the pad
<xnox> cjwatson: you did well =)
<stgraber> cjwatson: looks good, same URL
<Riddell> apw: I filed bug 1178294 for not working on my uefi/sb machine, is that what you mean?
<udsbotu> Ubuntu bug 1178294 in ubiquity (Ubuntu) "Install fails with Kubuntu 13.04 on UEFI system" [Undecided,Confirmed] https://launchpad.net/bugs/1178294
 * cjwatson tries to find apachelogger's bug
<cjwatson> he said on 2013-05-02 that he was going to file one
<apw> bug 1167622
<udsbotu> Ubuntu bug 1167622 in linux (Ubuntu) "Cannot change EFI variables using efibootmgr (raring regression)" [Medium,Confirmed] https://launchpad.net/bugs/1167622
<cjwatson> bug 1171099 - but on reflection it appears unrelated
<udsbotu> Ubuntu bug 1171099 in kubuntu-settings (Ubuntu Saucy) "kubuntu - plymouth not shown" [High,Triaged] https://launchpad.net/bugs/1171099 - Assigned to Harald Sitter (apachelogger)
<cjwatson> sorry for derailing, I was triggering mentally on "grub" and "kubuntu" :)
<cjwatson> apw,cking: would one of you be a sensible kernel contact if there are still outstanding bugs?
<apw> cjwatson, yeap poke me
<cjwatson> definitely looks like the first step is "get saucy into gear and try it"
<cjwatson> ok
<apw> yep concur, i should have kit to test it with as well, at least a bit
<cking> apw, as long as you don't brick it
<apw> cking, i am sure i will
<apw> cjwatson, there was a bug somewhere with all the changes connected to it i think, at least all the packages
<cjwatson> Yeah, I remember that, though I fear it was incomplete
<cjwatson> I'll hunt it down
<cjwatson> Riddell: is there a blueprint for this, btw?  just asking 'cos if so it would decrease the chance of work items getting lost
<Riddell> cjwatson: nope, shall I make one?
<cjwatson> if you would that'd be great
<Riddell> cjwatson: voila https://blueprints.launchpad.net/ubuntu/+spec/foundations-1305-kubuntu
<cjwatson> ta
<cjwatson> done the seed bits for saucy at least - precise will take more work
<cjwatson> and probably ought to make sure first that it works in saucy, anyway
* udsbotu changed the topic of #ubuntu-uds-foundations-1 to: Track: Foundations | Mobile Power Management | Url: http://summit.ubuntu.com/uds-1305/meeting/21776/foundations-1305-mobile-pm/
<lool> hey
 * pitti waves
 * ogasawara waves
<ogasawara> not sure if bdmurray or cjwatson is starting up our session
<cjwatson> ogasawara: bdmurray
<bdmurray> ogasawara: I should be just a moment
<ogasawara> ack, thanks
<cjwatson> we had a brief mix-up
<ogasawara> https://plus.google.com/hangouts/_/d9954311986ea36d3861625cd022d9dc8db2c213?authuser=0&hl=en
<ogasawara> lool, mfisch, sforshee ^^
<ogasawara> pitti: ^^ if you feel inclined
<apw> ogasawara, are we live yet ?
<ogra_> doesnt look like
<ogasawara> just starting
<apw> not seeing it yet
 * ogra_ sees ... 
<ppisati> video stutters here...
<ogra_> it didnt here until you said that !
<ppisati> LOL :)
<ogra_> :)
<sforshee> http://goo.gl/KMlMv
<mfisch> system power policy doc: http://goo.gl/KMlMv
<rickspencer3> I like the mental model that it's a constant battle between the power manager trying to reduce power and apps trying to keep it
<rickspencer3> so app authors have to do work to fight against the power manager
<mfisch> right, via curated APIs
<ogra_> yeah the api should help them
<rickspencer3> yeah
<rickspencer3> app authors have to wage battle against the power manager, but only through the api
<rickspencer3> that means the power manager will have the deck stacked in its gavor
<ogra_> tvyou are
<rickspencer3> favor*
<achiang> maybe google i/o is melting the internet now
<mfisch> seth's video always freezes ;)
<brendand> QUESTION: at what level will these inhibitors be 'switched on' as it were, such that all the responsibility doesn't lie with each individual app?
<pitti> sforshee: yeah, I think I have like a 10 second lag, sorry
<ogra_> funny conversation
<brendand> e.g. why have each app that could play music switch it on, when the audio subsystem (pulse?) will know this anyway?
<ogra_> brendand, well, tha ypi will switchi it on
<ogra_> *the api
<achiang> brendand: the responsibility is *below* the app level
<achiang> brendand: the API backend will manage this on behalf of the apps
<ogra_> i.e. your app plays music ... the api knows that and tells pulse about it
<ogra_> and pulse inhibits
<mfisch> brendand: the app calls playBackgroundMusic() and then the audio service/pulse tells power manager "dont suspend"
<brendand> it seems that it should be inhibited at the lowest level possible that makes sense
<mfisch> brendand: what do you mean?
<achiang> brendand: the whole point of hiding it behind the API is precisely to inhibit at the level that makes sense
<ogra_> pitti, it think we also want to live that stuff on a system level, not a session one ... logind could be our channel for conversation i guess though
<pitti> ogra_: yes, I agree; you can query them at a system level, but they are still tied to a particular session/seat
<pitti> (powerd wouldn't need to care about which particular session, of course)
<ogra_> right
<brendand> mfisch, i guess my question is answered. that was just a general observation
<mfisch> ogra_: thats what we envisioned, logind is out path to match sessions and seats
<ogra_> yeah
<mfisch> sessions may request a display state and we need to map that to a physical display (seat) which in turn is managed by a system compositor
<ogra_> did you guys look into teh existing powerd already
<ogra_> ?
<mfisch> ogra_: yes, we are currently coding some enhancements onto it to prove out the concepts
<ogra_> awesome :)
<brendand> question the second: how fine grained can the hardware control be? can it switch e.g. everything off but the wifi chip, or even vice versa?
<ogra_> the kernel can ...
<mfisch> brendand: we plan that PM only manages screen power and system power (suspend), but not, for example, low power wifi states
<ogra_> so the question is how much use do we make of it
<mfisch> if the wifi chip supports some low power mode, for example, the wifi stack deals with that
<ogra_> (over time)
<brendand> mfisch, that's true
<cking> the devil is in the unexpected detail, so we need to start somewhere
<mfisch> agreed
<mfisch> just from starting to implement some stuff I've run into several questions about how the API would work
<ogra_> he is currently doing it himself
<ogra_> since he wrote the initial version
<apw> ogasawara, damn straight
<ogra_> sforshee, about time !
<ogra_> kernels are boring ... userspace has all the excitiment
<mfisch> Chicken: you've got me until friday ;)
<brendand> mfisch, actually what i meant was that say the only thing that is happening on the system is a file download. what is the most efficient power state that can be reached?
<sforshee> ogra_, I like kernels ;-)
<ogra_> :)
<mfisch> brendand: it depends on the system, realistically probably screen off but not suspended, however, if you had a system where you could download a file without the system CPU, then it would work like this
<mfisch> (these are made-up API calls), app calls downloadBackgroundFile()
<pitti> aren't ARM processors more flexible in that regard?
<mfisch> then download manager decides whether the system should suspend or not
<ogra_> a lot
<mfisch> right
<pitti> i. e. that they already shut down units which aren't necessary for a particular task?
<ogra_> depends
<sforshee> pitti, yes to some degree
<lool> it's a whole system really
<lool> on a single chip
 * pitti really liked the OLPC which could display a static image with shutting down the CPU and GPU :)
<ogra_> i.e. if the kernel (and HW) supports the interactive governor you can do very intresting things on that level
<rfowler> QUESTION: when suspending the device via power button you should still be able to access a device via adb correct?
<ogra_> very finegrained too
<rfowler> because the nexus 10 doesn't
<mfisch> rfowler: I thought on Android there's a wakelock held when you're using adb that prevents suspend
<pitti> ogra_: can you run an ARM CPU at hilariously slow speeds? like 500 kHz or so?
<sforshee> rfowler, yes, in that case the system should turn off the screen but not suspend
<sforshee> rfowler, we don't have all the infrastructure in place yet ;-)
<ogra_> pitti, heh, never tried below 200MHz
<ogra_> pitti, i suppose it might work though
<sforshee> mfisch, the nexus 10 kernel doesn
<sforshee> doesn't have the same wakelock infrastructure as past android devices
<mfisch> ah the n4 seemed to
<mfisch> I dont have a n10
<sforshee> n4 still uses the old android wakelock model
<rfowler> thanks
* udsbotu changed the topic of #ubuntu-uds-foundations-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1305/foundations-1/ - http://ubottu.com/udslog/%23ubuntu-uds-foundations-1
* udsbotu changed the topic of #ubuntu-uds-foundations-1 to: Track: Foundations | Plans for documentation and positioning of the development release | Url: http://summit.ubuntu.com/uds-1305/meeting/21761/foundations-1305-development-release-planning/
 * cjwatson gets back to the hangout creation dance
<cjwatson> https://plus.google.com/hangouts/_/375a4beea5be9186d8db528da6728c294bddc025?authuser=1&hl=en-GB
<cjwatson> anyone else joining the hangout?  It's rather quieter than I expected :)
<cjwatson> rickspencer3: ^-
<cjohnston> is it just you cjwatson ? ;-)
<cjwatson> And stgraber
<rickspencer3> hi cjwatson I'd be happy to join
<rickspencer3> cjwatson, I don't know that I can contribute much technical, thouhg
<cjwatson> Fair enough, thanks
<cjwatson> https://plus.google.com/hangouts/_/375a4beea5be9186d8db528da6728c294bddc025?authuser=1&hl=en-GB
<pumpichank> sorry, could someone please repost the hangout url?
<balloons> https://plus.google.com/hangouts/_/375a4beea5be9186d8db528da6728c294bddc025?authuser=1&hl=en-GB
<pumpichank> thanks
<xnox> stgraber++
<pumpichank> let's call it "sid" <wink>
<apw> cjwatson, would we be able to upload to this new name, i am assuming not
<stgraber> apw: no
<stgraber> well, that's what Rick brought up, but the current plan is a simple symlink at the archive level
<stgraber> LP wouldn't be aware of that
 * xnox ideally wishes _all_ uploads to be phased in the devel release =)
<balloons> the current qa community folks would be happy to run this :-)
<cjwatson> apw: Rick brought it up and I hadn't thought about it; it's easy enough to do
<cjwatson> stgraber: I was planning to have LP create the symlink, though (in the publisher)
<cjwatson> pumpichank: iron rule: no name clashes with Debian :)
<cjohnston> In the session before lunch we discussed how to display key performance indicators on the QA Dashboard that could be  helpful of people trying to decide to update
<xnox> the bit that is missing, is the pop-up: 'wanna see the next ubuntu's wallpaper?' =)))))
<xnox> cjohnston: KPI is an indicator, using a devel release should be more playful & impulsive. I think. If one looks at stability indicators, precise will always win.
<chiluk`> I think the other fear is fear of hardware being killed by the development version...
<cjohnston> xnox: sure, however if people are asking on IRC if they should update, that would give them something to look at
<balloons> if they are asking to update or not, odds are they aren't good candidates :-)
<xnox> I am somewhere between cjohnston & balloons, closer to balloons stance I think =)
<cjohnston> I haven't switched yet, but I've thought about it.. partially due to time... but it would still be nice to see if today is looking ok before doing it
<balloons> it is fair to ask/check if something is totally borked before upgrading.. but in general, your running the devel release for a specific reason. We hope your running it to help ubuntu itself out by testing, hacking, developing, whatever
<cjohnston> that's what I'm getting at
<balloons> cjohnston, however, I've never done such a thing.. If an upgrade fails, I file a bug
<balloons> wait and try again ;-)
<cjohnston> If you can look and see that its going to break and there is already a bug, why try
<chiluk`> can't we get statistics like that by monitoring accesses to the development repos?
<balloons> cjohnston, if there was a known issue, I would be more inclined to try :-)
<balloons> it's about setting expectations for the release. I don't think anything has to really changed on that front. If your running -devel release things may break
<balloons> it's all part of the experience, and to the extent you have an issue, report it, workaround it and move on
<pumpichank> omgomega
 * xnox .o0(now we just need a 7 grade scale of neo-users)
<lool> "dev"
<chiluk`> tip++
<balloons> you could still call it rolling :-)
<xnox> where is the marketing department when you need them? =))))
<pumpichank> good thing there's no possibility of bikeshedding the name
<pumpichank> rickroll
<xnox> "fresh"?
<xnox> let's call it "tumble weed".
<balloons> preview?
<xnox> warty?
<TheMuso> lol
<cjohnston> nonameyet
<xnox> adjective and an animal? to put into lsb-release os / etc?
<balloons> +1 nonamyet
<chiluk`> rolling does already have a bunch of publicity out there.
<cjohnston> nonameyet because Mark hasn't picked an animal
<cjohnston> heh
<plars> voyager
<pumpichank> rolling is not bad
<balloons> honestly rolling probably communicates things simply, without requiring more explanation
 * apw suggests bikeshed
<lool> +1
<cjwatson> phk </obscure>
<apw> lool, no no no, he wants one we cannot have without blowing LP up
<lool> :-)
<chiluk`> just blog about it
<lool> plus it's probably (tm) google
<chiluk`> that would be help those who are afraid to move early in the development release as well.
<Laney> anything else here?
<rickspencer3> thanks cjwatson
<rickspencer3> I <3 "rolling" ;)
<cjwatson> thanks everyone
<chiluk`> rolling roadrunner Â ...... acme flashbacks
<cjwatson> rickspencer3: I'll drop this into the blueprint whiteboard/WIs, so maybe just edit there when I'm done rather than fighting with etherpad
<balloons> rick rolling rash roadrunner
<balloons> release
<balloons> :-p
<apw> rickspencer3, it hought you loved the rolling release, hiding it seems odd
<cjwatson> ah, "export as plain text" from the pad => less unpleasant way to get it into blueprints
<cjwatson> rickspencer3: all in the bp now
<rickspencer3> cjwatson, ok, I'll pop my notes in there then
* udsbotu changed the topic of #ubuntu-uds-foundations-1 to: Track: Foundations | semiannual release schedule review | Url: http://summit.ubuntu.com/uds-1305/meeting/21794/semiannual-release-schedule-review/
<knome> hello
<knome> who's running the hangout?
<bdmurray> I am
<knome> i suppose i'd like to join that one :)
<knome> defining want in the "should" sense ;9
<knome> elfy, o/
<bdmurray> https://plus.google.com/hangouts/_/ef55fe3b04e56166a89aa6c2a748602a149da165?authuser=0&hl=en
<elfy> knome: yep - I'm here
<elfy> more or less
<knome> :)
<knome> oodie
<knome> +g too (not g+)
<xnox> is the feed live?
<elfy> it's very quiet :p
<elfy> xnox: not that I can see
<apw> xnox, not here
<bdmurray> just started it
<plars> hear no evil, see no evil... not live yet
<apw> bdmurray, there is a heck of a lag from the originators timezone to ones a ways away
<stgraber> https://wiki.ubuntu.com/SaucySalamander/ReleaseSchedule
<plars> ah, there it is
<bdmurray> apw: are you suggesting I move?
<balloons> ahh video :-)
<apw> bdmurray, it is the obvious solution :)
<xnox> cjwatson: there are bits on the pad to discuss =)
<cjwatson> those were things I said
<balloons> lol.. yes, milestones seem to be pretty good drivers for flavors
<cjwatson> balloons: what was your sense of testing of earlier milestones?
<xnox> cjwatson: i see =) lag.
<balloons> in comparison to ubuntu, they were pretty tame. However, I do echo stgraber here. Flavors like kubuntu and lubuntu got there work done as part of having milestones; they seemed to like having that 'hard date' in which work needed to be complete
 * elfy is listening - I'd agree with what knome has said 
<xnox> in-dash payments.
<xnox> was the other one, i think.
<balloons> a2 and a3 being so close meant most flavors looking at it weren't going to do one of them :-)
<cjwatson> yeah, I think that was among the reasons we deleted a3 from raring
 * cjwatson harks back to the days of 7 alphas
<knome> the proposed changes sound fine to me
<knome> not me!
<knome> way to go, mute all the community people >;)
<balloons> +1 on making milestones ~= monthly cadence
<cjwatson> :-P
<cjwatson> unmute yourselves if you want to talk :)
<knome> nah
 * cjwatson is muted too
<balloons> lol.. good practice so background noise of your cat doesn't pop in :-)
<knome> oh, one can't see who's muted or not. interesting
<knome> cat pooping in?
<knome> i was told i type really loudly
<balloons> will ff be moved back again?
<balloons> I know there was still some drama even with it moved so far back into the cycle
<cjwatson> you're the first person who's expressed a desire to move it back :)
<cjwatson> want to expand?  as stgraber was saying, for once it seems to have been sort of successful
<cjwatson> in that we didn't actually have too many major disruptive changes after FF
<knome> depends on the release team i suppose
<balloons> cjwatson, I think I confused everyone.. aka.. it's week 17, will it be week 20 in saucy like raring or no?
<balloons> I speaking of feature freeze ^^
<cjwatson> right, yeah, like we said there are a bunch of changes we made in raring that don't seem to have been mirrored into saucy
<balloons> ok.. right, excellent
<cjwatson> basically because there was an incredibly unwise decision several releases ago to create a bunch of release schedules in advance
<cjwatson> so now we have to keep remembering to mirror changes ...
<cjwatson> Adam took an action to push things over
<balloons> lol.. you try and make less work for yourself, and boom
<elfy> tring to remember last time that worked for me
<balloons> mm.. adam, that's the point of cadence testing
<balloons> fyi, if your curious of stats for raring; http://91.189.93.58/ scroll down to the "Raring Image Testers" and "Raring Image Results"
<balloons> you can see the spikes are the milestones
<balloons> the later milestones had much more traction than the early milestones
<knome> adam should use xfce ;)
<balloons> use google dns :-p
<knome> can you also mail the flavor devel lists?
* udsbotu changed the topic of #ubuntu-uds-foundations-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1305/foundations-1/ - http://ubottu.com/udslog/%23ubuntu-uds-foundations-1
#ubuntu-uds-foundations-1 2013-05-16
<zyga> hi
* udsbotu changed the topic of #ubuntu-uds-foundations-1 to: Track: Foundations | Port checkbox-certification-server on top of plainbox | Url: http://summit.ubuntu.com/uds-1305/meeting/21759/foundations-1305-checkbox-certification-server-on-plainbox/
<cjwatson> OK, time to figure out the new hangouts interface I hear about
<zyga> cjwatson: new?
<zyga> cjwatson: could you paste the hangout link here when ready, please?
<cjwatson> Yeah, going to
<ara> hello all!
<cjwatson> apparently google rolled out a new interface last night - may only matter for those starting hangouts
<zyga> oh
<zyga> heh
<zyga> beware of google updates ;) wait, we cannot control that
<spineau> I didn't notice any changes this morning
<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
<cjwatson> bdmurray: if you're lost, BTW, it's in home (at the left) -> hangouts on air
<brendand> link!
<cjwatson> https://plus.google.com/hangouts/_/c6f853c7682e14d362c469190256247ab5cfc2eb?authuser=1&hl=en-GB
<zyga> thanks
<cjwatson> zyga: not so much port to python 3 as fix it, presumably, since python3-urwid does exist
<brendand> kicked off?
<bladernr`> brendand: you froze
<bladernr`> brendand: plugin again?
* udsbotu changed the topic of #ubuntu-uds-foundations-1 to: Track: Foundations | Packaging the android Ubuntu Touch parts | Url: http://summit.ubuntu.com/uds-1305/meeting/21807/foundations-1305-android-builds-revisited/
<zyga> woot
<zyga> thanks
<zyga> cjwatson: it's totally broken
<zyga> cjwatson: it's not doing anything useful
<zyga> cjwatson: tests never even got invoked once there
<zyga> cjwatson: (because of a bug in setup.py)
<brendand> zyga, i don't think plainboxes remit should go beyond the M part of MVC really
<zyga> cjwatson: it's a total automatic conversion that does not work
<cjwatson> ah, suck
<brendand> zyga, and maybe the model part is complete, but we just need to ensure it is
<zyga> brendand: it's not that complete but it's sufficiently good for our existing needs, but I agree in general
<brendand> zyga, i kind of think it would be a useful exercise to write a noddy gui app using plainbox in parallel
<zyga> brendand: +1 from me
<zyga> brendand: just pick your toolkit
<brendand> zyga, to make sure we have the right level of abstraction
<roadmr> qml? *ducks*
<zyga> brendand: agreed
<zyga> roadmr: qml is interesting
<zyga> roadmr: as to how to bridge that :)
<brendand> roadmr, yes qml
<brendand> roadmr, i know cr3's objection was that there was no ui toolkit for it at the time
<brendand> roadmr, anyone say ubuntu sdk?
<roadmr> brendand: yes something like that
<bdmurray> okay, its about time for the next session
<brendand> roadmr, well that's the past now :)
<bdmurray> https://plus.google.com/hangouts/_/c3ffb1d0fd80765471ed4f856fe6c43ec2eb1a92?authuser=0&hl=en
<ogra_> i kind of need a toolchain person for this
<ogra_> infinity seems to be afk ... doko as well :/
<cjwatson> might be worth an sms
<sergiusens> ogra_: can it be postponed?
<ogra_> sergiusens, no free slots
<ogra_> (we just discussed it in -touch)
<cjwatson> doko is around
<ogra_> yeah
<cjwatson> summoning him :)
<cjwatson> I'll try SMSing Adam
<ogra_> well, one of them shoudl be enough i think
 * apw waits for the stream
<ogra_> he wasnt feeling well
<ogra_> (we talked before)
<cjwatson> ah, ok, well too late I already sent it
<ogra_> heh
<ogra_> doko, https://plus.google.com/hangouts/_/c3ffb1d0fd80765471ed4f856fe6c43ec2eb1a92?authuser=0&hl=en
<bdmurray> okay its live now
<apw> bdmurray, i see it
<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?
<cjwatson> or else your hangout is way behind :)
<ogra_> http://phablet.ubuntu.com/export/
<doko> cjwatson, sorry I don't see where ...
<doko> now, no etherpad here
<cjwatson> Can't tell from this end, all I could tell was that we were hearing things from a minute or so ago
<cjwatson> There's a link in the summit page called "notes in a separate window"
<bdmurray> http://pad.ubuntu.com/uds-1305-foundations-1305-android-builds-revisited
<cjwatson> Or pause the youtube stream
<ogra_> http://phablet.ubuntu.com/gitweb
<apw> ogra_, have we tried compiling with the archive compilers at all?  I assume we know we _do_ need this special compiler.
<ogra_> https://wiki.ubuntu.com/Touch/Porting
<cjwatson> apw: we need bionic at least
<apw> cjwatson, point indeed
<apw> ogra_, thanks
<ogra_> . build/envsetup.sh
<ogra_> brunch mako
<asac_web> repo sync for source package prep
<asac_web> repo sync for source package prep
<ogra_> right
<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
<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
<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
<asac> bah :)
<asac> stupid web thing
<asac> i think the hal stuff is what people usually touch
<sergiusens> ogra_: do we have a hangout link?
<ogra_> https://plus.google.com/hangouts/_/c3ffb1d0fd80765471ed4f856fe6c43ec2eb1a92?authuser=0&hl=en
<stgraber> ogra_: you realize we'll likely be repacking/converting any zip file you generate into our tar.xz format anyway, right?
<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, ...)
<asac> stream offline
<stgraber> asac: works fine here
<asac> back now
<ogra_> stgraber, right. thats what we have now too
<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?
<cjwatson> nor do I
<cjwatson> it sounds like it will be significant excess work even if it doesn't look like it now
<asac> can you repeat the proposal?
<asac> :)
<asac> ogra?
<asac> you can speak :)
<ogra_> http://phablet.ubuntu.com/export/
<lool> asac: there's a lag between video and here
<cjwatson> so the zip files are *only* the output of the android build?  they contain no Ubuntu-specific content at all?
<sergiusens> asac: there's 4 minutes lag sometimes
<sergiusens> asac: he's explaining
<lool> now you seem him typing his answer  :-)
<lool> *see
<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.
<lool> a .zip in a .deb generated by just moving the contents of a .tgz seem a bit inefficient use of buildd time  :-)
<apw> ogra_, i assume we would invent a nice base orig to make this not be humungous on each upload
<asac> isnt the content in the zip also in out/target/product/maguro?
<ogra_> apw, right
<asac> so you can just package that  up?
<asac> or you can just unpack it before packagint he binary during build :)
<josepht> asac: perhaps you could join the hangout
<asac> right
<asac> i am on another call :)
<asac> will there be no build dependencies from the ubuntu system that need this stuff?
<ogra_> nope
<ogra_> well, libhybris and the platform-api will need bionic
<apw> ogra_, when one does a 'brunch mako' does that spit out just the mako bits
<ogra_> apw, yeah
<cjwatson> anything in the Ubuntu system that needs it will build-depend on arch: all packages that contain armel binaries
<asac> apw: depends what you mean with "just mako bits"
<cjwatson> which is the plan of record for bionic for instance
<asac> there is clearly mako independent stuff produced during that from what i know
<cjwatson> do you mean mako dependent?
<asac> cjwatson: oh ... can we keep the door open for x86 binaries?
<cjwatson> sure, I don't mean exclusively
<asac> the arch: all feels constraining us to produce phablet x86 images
<cjwatson> no, not at all
<cjwatson> you misunderstand :)
<asac> ok i will leave you
<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
<asac> will sync after/offline to catch up :)
<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
<cjwatson> the same would go for x86 if they were linked against bionic, probably
<cjwatson> anyway arch: all doesn't constrain us to anything, it relaxes a constraint
<asac> kk
<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
<ogra_> apw, yeah, i#m not to worried about that bit
<ogra_> http://cdimage.ubuntu.com/ubuntu-touch-preview/daily-preinstalled/current/
<ogra_> http://cdimage.ubuntu.com/ubuntu-touch-preview/daily-preinstalled/current/raring-preinstalled-armel+grouper.zip
<lool> win 9
<lool> ups
<rsalveti> sergiusens: I put my name in there as I'm working on cleaning hybris anyway
* udsbotu changed the topic of #ubuntu-uds-foundations-1 to: Track: Foundations | ARM64 bringup for saucy | Url: http://summit.ubuntu.com/uds-1305/meeting/21756/foundations-1305-arm64-bringup/
<baozich> hi
<sergiusens> rsalveti: no worries!
<vanhoof> hi
<cjwatson> hi, just bringing up the hangout now
<cjwatson> https://plus.google.com/hangouts/_/ceaefc95b48453edfea3dadabe276df43df5876f?authuser=1&hl=en-GB
<rbasak> Is the stream live? I'm getting errors.
<bjf> not live here
<cjwatson> not on air yet
<apw> bjf waiting on the participants currently
<cjwatson> waiting for a few more people to show up
<rbasak> I get "An error occurred. Please try again later"
<rbasak> (behind the "Please stand by." screen)
<cjwatson> I'll say here when I put it on air
<rbasak> OK thanks
<cjwatson> doko: joining the hangout?
<zyga> hi
<cjwatson> should be on air now or shortly
<kentb> \o/
<rbasak> It errored a bit more but seems to be working now - thanks.
 * rbasak likes how cjwatson says "Saucy"
<cjwatson> my vowels are all permuted randomly from standard English I'm afraid :)
<dannf> server stuff :)
 * cjwatson waves hands furiously :)
<dannf> lamp stack - php/python/apache/etc - probably the maas depends too
<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
<cjwatson> a bunch of core packages build-depend on java for plugins and the like
<dannf> right
<cjwatson> so it's quite inconvenient not to have something basic, although it *can* be turned off in most of the relevant ones
<rbasak> Would non-JIT Java be bearable for build-depends?
<dannf> vanhoof: +1 - seems doable
<cjwatson> rbasak: if it works yes
<dannf> cjwatson: sure, we'll deal w/ that separately
<dannf> power mgmt, etc
<rbasak> I don't think there will be any fundamental issues - just an individual bringup task for individual chassis as they become available.
<dannf> bug getting django, etc is more what i meant for this session
<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
<rbasak> (for maas)
<cjwatson> rbasak: right, that's sort of what I was asking about, whether that's needed for 13.10
<rbasak> Yes - Ubuntu Core would be really useful for early hardware bringup work
<cjwatson> hopefully not since we AFAIK have no idea what we're doing there yet :-)
<apw> rbasak, someone needs to own maas for this, is that in your hands ?
<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.
 * dannf isn't sure maas is needed in this cycle - but i think coordination belongs to our (vanhoof's) group
<rbasak> (it depends on the BMC firmware vendors give us)
<vanhoof> dannf: I think it's worth investigation now, I've reframed the work item
<dannf> thx
<rbasak> There is a task for me to make MAAS work with device tree kernels though (or anything other than -highbank).
<rbasak> I can do that together with the first enablement.
<cjwatson> ok, given you a WI for that
<cjwatson> or do you want to drop that and it'll in practice come up later?
<dannf> rbasak: i have some patches for that i can share, let's sync up at some point
<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.
<dannf> if you mean feeding the dtb to machines, that is
<rbasak> dannf: sure, we should chat. Thanks!
<dannf> don't expect anything awesome :)
<cjwatson> rbasak: ok
<lool> ups looks like I wasn't muted when my family came back home
<dannf> see ya
<cjwatson> thanks
<vanhoof> cheers!
* udsbotu changed the topic of #ubuntu-uds-foundations-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1305/foundations-1/ - http://ubottu.com/udslog/%23ubuntu-uds-foundations-1
<zyga-uds> hi
* udsbotu changed the topic of #ubuntu-uds-foundations-1 to: Track: Foundations | Launching Applications using Upstart | Url: http://summit.ubuntu.com/uds-1305/meeting/21781/foundations-1305-upstart-app-launching/
<bdmurray> hang out url https://plus.google.com/hangouts/_/90b69f088ee82ef1cd236813add7c301a409611a?authuser=0&hl=en
<bdmurray> video is live
<tedg> mdeslaur, You gonna hangout with us?
<mdeslaur> tedg: I'm with you
<mdeslaur> tedg: look carefully :)
<zyga-uds> hi
<jodh> anyone else getting a lot of extraneous hiss on this hangout?
<sbeattie> jodh: yes, lots of audio noise
<lool> ricmm: are you in the hangout?
<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?
<lool> there's a high-pitched noise from time to time in the hangout
<lool> tedg: one issue is integration wiht app mgr
<tedg> lool, What is app mgr?
<jodh> lool: what is "app mgr"?
<lool> sorry, the application manager role of Unity + Mir
<zyga> normal?
<lool> that is, it will signal apps that they are about to be suspended
<lool> and resume then
<lool> *them
<gQuigs> does this give us app specific logs for free?
<mdeslaur> gQuigs: yes!
<tedg> gQuigs, yes!
<mdeslaur> lol
<lool> sorry, not sure why ,y video is broken
<gQuigs> that's awesome :)
<zyga> jodh: so 'application' job would be one super-task that is instantiated per app and user?
<bfiller> tedg: is the shell planning to switch to using upstart to launch apps?
<bfiller> if so, when?
<sars> lego man, you're impossible to hear :(
<zyga> lool: you're not getting through on the hangout
<pitti> tedg: you mean kill remaining processes of the session?
<lool> zyga: is it better now?
<lool> zyga: now that I've rejoined
<zyga> yes
<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)
<lool> I don't understand where my video stream is coming from
<dbarth> QUESTION: what is the plan wrt to webapps or remote apps that may have 1 app/process managing multiple distinct distant apps?
<dbarth> i imagine app mgr can give us a distinct id
<dbarth> but how will that id be integrated with the upstart scheme?
<mdeslaur> dbarth: for security reasons, those need to be separate processes to have their own security confinement anyway
<mdeslaur> were you referring to html5 apps, for example?
<dbarth> RDP / Citrix (admintedly a desktop specific case) will multiplex things in the end
<mdeslaur> ah! ok
<dbarth> so there may be a need to let those distinct processes communicate with the one holding the socket to the remote server
<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
<zyga> tedg: could you explain how it would work on the desktop?
<zyga> tedg: starting with someone clicking on the launcher icon?
<txwikinger> terminals are startup several times.. but I think it uses the trick of different names
<bdmurray> http://pad.ubuntu.com/uds-1305-foundations-1305-upstart-app-launching
<bdmurray> tedg: ^
<zyga> txwikinger: terminal is not confined in any way to run multiple times IIRC, some apps explictly try to prevent that
<zyga> tedg: would what you just explained be in upstart core or in a specific job?
<zyga> tedg: thanks
<gQuigs> apport should collects the app logs when reporting bugs for said app  ~ where are the apps going to be logged to?
<pitti> gQuigs: apport already collects those (in saucy)
<pitti> gQuigs: ~/.cache/upstart/<job>.log
<gQuigs> pitti: perfect
<pitti> that mostly supersedes/replaces collecting ~/.xsession-errors
<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)
<jjohansen> mdeslaur: we also should have env rules in apparmor
<jjohansen> but upstart should do most of what we need
<mdeslaur> jjohansen: yeah, the environment will be pretty clean already, but we can blacklist some in both places if we need to
<tedg> pitti, Will apport grab the application-<instance>.log files as well?
<pitti> checking..
<pitti> it attaches <name>.log for each /usr/share/upstart/sessions/<name>.conf that the package ships
<pitti> so if the job names are different from the log names in that case, we need to adjust it
<pitti> tedg, jodh: works?
<tedg> Yeah, in this case it would be application-<desktop name>.log
<tedg> So we'd need to grab that log for any desktop file.
<pitti> ok, needs changing then
<tedg> pitti, Can I add an action item for you there?
<tedg> Heh, pitti thanks!
<tedg> You're too fast!
<pitti> tedg: added a WI, does that look right?
<pitti> heh
<tedg> pitti, Yup, looks good!
<tedg> Thanks!
<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?
<asac> stgraber: ?
<stgraber> asac: upstart will just take care of starting and stopping the app and applying the various apparmor/seccomp/cgroup profile/restrictions
<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
<asac> stgraber: yeah. just occurs to me that starting/stopping etc. are too activities in the lifecycle
<asac> so thought maybe other states might make sense to be reflected in the same place :)
<asac> whatever that might mean :)
* udsbotu changed the topic of #ubuntu-uds-foundations-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1305/foundations-1/ - http://ubottu.com/udslog/%23ubuntu-uds-foundations-1
