| cjwatson | oh wow, my client has been logged in here since UDS 13.03 and I forgot about it | 14:09 |
|---|---|---|
| zyga | hi | 14:28 |
| zyga-uds | hi everyone | 14:30 |
| brendand | cjwatson, can you provide me the link for the first session (i'll be running it) | 14:34 |
| cjwatson | brendand: I'll start up the hangout once the plenary has finished | 14:36 |
| zyga | hi | 14:36 |
| 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 :) | 14:36 |
| brendand | cjwatson, do you know do people need to be specifically invited, or do they just need the link? | 14:37 |
| cjwatson | they just need the link AFAIK | 14:37 |
| cjwatson | so you can pass it on | 14:37 |
| cjwatson | but there's a limit of *mumble* | 14:38 |
| zyga-uds | welcome everyone, if you need to join the hangout ask for the link please | 14:44 |
| roadmr | zyga-uds: I need to join the hangout :) | 14:44 |
| zyga-uds | if you wish to help with making notes in the etherpad on the side here, please do so | 14:44 |
| zyga-uds | roadmr: you'll get a link as soon as we get one | 14:44 |
| roadmr | zyga-uds: oooh :) ok heh | 14:45 |
| === 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? | 14:46 | |
| zyga-uds | +1 | 14:48 |
| zyga-uds | it will make it easier for people to join | 14:48 |
| zyga-uds | and if it fails, we'll know | 14:48 |
| sfeole | o/ | 14:51 |
| zyga-uds | hi | 14:51 |
| cjwatson | just fighting G+ to start it up now | 14:51 |
| sfeole | hey zyga | 14:51 |
| brendand | cjwatson, just pop the link in here when you're ready | 14:51 |
| brendand | cjwatson, thanks | 14:51 |
| cjwatson | https://plus.google.com/hangouts/_/e57d55608285e7215ba3273218e8ae43d4244d2e?authuser=1&hl=en-GB | 14:53 |
| === 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 | 14:55 |
| cjwatson | don't know if that's inherent or due to my network | 14:56 |
| roadmr | hello | 14:58 |
| zyga-uds | we'll be starting in about 5 minutes, | 14:59 |
| zyga-uds | at 16:05 UTC | 14:59 |
| brendand | cjwatson, new url or same one? | 15:02 |
| cjwatson | https://plus.google.com/hangouts/_/a5bb0a674d670614230e303f5f9e384e7dbbc0e6?authuser=1&hl=en-GB | 15:02 |
| cjwatson | no control over that I'm afraid | 15:02 |
| cjwatson | I think it's all back now | 15:04 |
| brendand | vanhoof[uds], https://plus.google.com/hangouts/_/a5bb0a674d670614230e303f5f9e384e7dbbc0e6?authuser=1&hl=en-GB | 15:04 |
| cjwatson | just starting the youtube feed | 15:04 |
| brendand | schwuk, want to join? | 15:04 |
| schwuk | brendand, not sure I will have much to contribute, but I'm certainly interested in the discussion | 15:05 |
| brendand | schwuk, may as well, plenty of room | 15:06 |
| smagoun | youtube feed just came online for me | 15:06 |
| zyga-uds | https://plus.google.com/hangouts/_/a5bb0a674d670614230e303f5f9e384e7dbbc0e6?authuser=1&hl=en-GB | 15:06 |
| smagoun | cjwatson: ^^ | 15:06 |
| cjwatson | yep | 15:06 |
| mahmoh | it's working for me now | 15:06 |
| cjwatson | I have no idea whether it's going both ways over my ADSL; if it is, then, well, good luck | 15:07 |
| roadmr | cjwatson: it seems to be working fine, thanks for manning the a/v thingamajig! | 15:07 |
| * cjwatson puts on the crew hat | 15:07 | |
| zyga-uds | gema if you want to join: https://plus.google.com/hangouts/_/a5bb0a674d670614230e303f5f9e384e7dbbc0e6?authuser=1&hl=en-GB | 15:09 |
| gema | zyga-uds: I will join if I need to, I am listening for now | 15:10 |
| zyga-uds | thanks | 15:10 |
| === dannf` is now known as dannf | ||
| dannf | does checkbox use lshw? | 15:12 |
| 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 | 15:13 |
| brendand | roadmr, can you say that in the hangout? | 15:13 |
| vanhoof | brendand: ara: you can sign me up to get you access to newer kit for virt | 15:14 |
| brendand | https://plus.google.com/hangouts/_/a5bb0a674d670614230e303f5f9e384e7dbbc0e6?authuser=1&hl=en-GB | 15:14 |
| ara | vanhoof, great :) | 15:14 |
| === ts2 is now known as tsimpson_ | ||
| 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_ | 15:20 |
| gema | ? | 15:20 |
| gema | but some tests may only be applicable to desktop | 15:24 |
| bladernr | those are not run on servers | 15:25 |
| gema | bladernr: ack | 15:25 |
| bladernr | different test whitelists are used | 15:25 |
| gema | bladernr: understood | 15:25 |
| dannf` | device tree | 15:31 |
| dannf` | which kernel exposes from firmware | 15:31 |
| mahmoh | dmidecode (lost the stream) has a flag (that I can't think of atm) that will run early support for ARM | 15:33 |
| spineau | mahmoh: good to know, I'm adding a note for that | 15:35 |
| vanhoof | eep | 15:36 |
| vanhoof | booted | 15:36 |
| zyga-uds | I need to go AFK for 3 minutes | 15:37 |
| zyga-uds | roadmr:please take over etherpad | 15:37 |
| roadmr | zyga-uds: got it | 15:37 |
| 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 | 15:38 |
| spineau | mahmoh: ok, thanks | 15:38 |
| mahmoh | np | 15:38 |
| bladernr | I don't see why we would | 15:38 |
| zyga-uds | re | 15:39 |
| bladernr | Unless there's some special sort of marketing push for ARM systems, otherwise, a server is a server | 15:39 |
| mahmoh | it would be nice to be able to sort on arch | 15:39 |
| mahmoh | but that's not a requirement, just a nice to have | 15:40 |
| victorp_uds | hi ara | 15:40 |
| vanhoof | zyga-uds: can you pop in lshw -xml into the etherpad, I lost my session | 15:41 |
| bladernr | Is there anyting special about an ARM chassis that differs from a blade chassis? | 15:41 |
| 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 | 15:41 |
| zyga | vanhoof: pop in? | 15:41 |
| vanhoof | add it :) | 15:41 |
| victorp_uds | bladernr: in some cases they are the same chasis | 15:41 |
| narindergupta2 | ipmi test could be one of them | 15:41 |
| vanhoof | bringingmy session back up | 15:41 |
| mahmoh | there are differences but they should be transparent from a cert perspective | 15:41 |
| zyga | vanhoof: done | 15:42 |
| bladernr | victorp_uds: ack | 15:42 |
| 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) | 15:43 |
| victorp_uds | ara sorry I joined late, but are we including MaaS testing as part of certificaition testing for hyperscale servers? | 15:43 |
| mahmoh | bladernr: right | 15:44 |
| mahmoh | QUESTION ^^ | 15:44 |
| ara | victorp_uds, MaaS is going to be greylist for server certification and required for cloud | 15:44 |
| victorp_uds | It needs to be reuired too for hyperscale servers | 15:45 |
| victorp_uds | otherwise they cant be used | 15:45 |
| victorp_uds | :) | 15:45 |
| narindergupta2 | i think we should start categarizing the hyperscale different from server. | 15:45 |
| victorp_uds | narindergupta2:+1 | 15:45 |
| victorp_uds | brendand: just use MaaS!!! | 15:46 |
| narindergupta2 | +1 | 15:46 |
| victorp_uds | brendand:if you dont test MaaS then you are not testing the full solution | 15:48 |
| victorp_uds | brendand: definetly | 15:49 |
| victorp_uds | ara - are we having a different whitelist for hyperscale? | 15:49 |
| ara | victorp_uds, we haven't decided it | 15:50 |
| ara | victorp_uds, if we can avoid it, we will, if in the end we need specific tests, we will create a new one | 15:51 |
| ara | victorp_uds, we will use the server one until we really need to fork | 15:51 |
| victorp_uds | ara - I would rather you use the cloud whitelist rather than the server white list | 15:52 |
| victorp_uds | if you dont have a dedicated hyperscale one | 15:52 |
| narindergupta2 | yes it has | 15:53 |
| victorp_uds | vanhoof: \o/ | 15:54 |
| vanhoof | victorp_uds: :D | 15:54 |
| narindergupta2 | infact they have power management through chassis | 15:54 |
| narindergupta2 | and fan control and power supply control | 15:54 |
| narindergupta2 | through chassis | 15:54 |
| bladernr | but is that really through the chassis, or via ipmi passed from the chassis MM to the blade BMC? | 15:55 |
| narindergupta2 | for BL series you are correct but for moonshot it is through chassis as BMS is in chassis | 15:55 |
| bladernr | ahhh | 15:56 |
| narindergupta2 | /s/BMS/BMC | 15:56 |
| 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?) | 15:56 |
| narindergupta2 | yes i BMC controlling 15 cartridge | 15:57 |
| narindergupta2 | so total 3 BMC for 45 nodes within one chasssis | 15:57 |
| bladernr | wow | 15:57 |
| bladernr | that's pretty neat | 15:57 |
| zyga | brendand: really good session, thanks | 15:58 |
| lool | Next: Click Packages | 15:58 |
| brendand | zyga, yeah surprisingly | 15:58 |
| ara | great, I can stay here then | 15:59 |
| brendand | zyga, i thought we had everything fleshed out already :) | 15:59 |
| zyga | brendand: yeah, same here | 15:59 |
| mahmoh | juju bootstrap ; juju status | 15:59 |
| * brendand runs off to SDK feedback session | 15:59 | |
| mahmoh | hi spineau, bye spineau | 16:00 |
| === 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 | 16:01 |
| bkerensa | hi | 16:01 |
| dbarth | hiya | 16:02 |
| dholbach | hiya | 16:02 |
| mdeslaur | hello | 16:04 |
| cjwatson | https://plus.google.com/hangouts/_/d3fd1e25ecacb43fde03034a86b8a3345f19b801?authuser=1&hl=en-GB | 16:04 |
| cjwatson | on air shortly | 16:05 |
| cjwatson | on air now | 16:05 |
| cjwatson | who wants to hop onto the hangout? | 16:06 |
| beuno | cjwatson, this will all be client side, right? | 16:06 |
| Laney | not on here | 16:06 |
| beuno | if so, I'll watch from the shadows | 16:06 |
| apw` | cjwatson:yep we can see yo | 16:06 |
| dbarth | it's on now | 16:06 |
| cjwatson | beuno: I expect there will be questions about server side too | 16:06 |
| * Laney stabs firefox | 16:06 | |
| Laney | oh yes | 16:06 |
| SuperMat1 | hi guys! | 16:06 |
| * ogra_ sees two guys hanging | 16:06 | |
| apw` | yes you are good | 16:07 |
| beuno | cjwatson, ok, ok, I'll hop in | 16:07 |
| ogra_ | yes | 16:07 |
| xnox | yeah | 16:07 |
| SuperMat1 | yes, we can see you | 16:07 |
| alecu | loud and clear | 16:07 |
| === SuperMat1 is now known as SuperMatt | ||
| barry | yes | 16:07 |
| * xnox is watching you well from New York public library =) | 16:07 | |
| sergiusens | you are hearable | 16:07 |
| aquarius_uds | https://lists.ubuntu.com/archives/ubuntu-devel/2013-May/037074.html is the discussion on ubuntu-devel | 16:08 |
| rickspencer3 | o/ | 16:08 |
| olli-uds | hiho | 16:09 |
| rickspencer3 | hi aquarius_uds I was invited to join, so I joined ;) | 16:10 |
| ogra_ | joined and left :P | 16:10 |
| dobey | can qml not be byte-compiled? | 16:13 |
| 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? | 16:13 |
| mdeslaur | ie: why even have a source package format | 16:14 |
| dobey | if random people are uploading it, we aren't distributing it are we? the person uploading it is | 16:14 |
| cjwatson | we're certainly (re)distributing it | 16:14 |
| dobey | we're just a "file sharing service" in that respect | 16:15 |
| cjwatson | it is not generally that simple :-) | 16:15 |
| xnox | it would be nice to upload the source and/or download them in addition to the app. | 16:15 |
| mdeslaur | ok, source package formay is bzr, and you install it with bzr co | 16:15 |
| apw` | cjwatson:can we not just 'keep' the <package>_src guarenteed available for the source once we have figured it out. | 16:15 |
| apw` | ie, so we have <package>.click and <package>_src.click | 16:16 |
| 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. | 16:16 |
| TheMuso | dobey: I thought I read somewhere that QML could be byte-compiled, but I may be mixing it up with somethign else. | 16:17 |
| ogra_ | rickspencer3, that will eat your disk on the phone fast | 16:17 |
| rickspencer3 | hi ogra_ well, that's what I'm asking | 16:17 |
| rickspencer3 | how much will it *really* do that, versus how much are we just worried that it will? | 16:17 |
| dobey | TheMuso: it would seem a bit odd to me if it wasn't possible, at least. | 16:17 |
| cjwatson | there are certainly source packages in the Ubuntu archive which are significantly larger than the binaries | 16:18 |
| ogra_ | rickspencer3, i want to write a DVB TV app that needs 6 libs plus my C++ source plus the QML for the UI | 16:18 |
| cjwatson | though I would need to do some research if you wanted specifics :) | 16:18 |
| ogra_ | i would have to include all of that source | 16:18 |
| rickspencer3 | ogra_, right, but that seems like an exception to the rule | 16:18 |
| victorp_uds | rickspencer3:I think the amount of apps that will include *a* gpl component will be high | 16:18 |
| TheMuso | dobey: Especially if a dev wanted to obfoscate some secret class that they didn't want people to grab. | 16:18 |
| dobey | TheMuso: right, or an API key for a web service | 16:19 |
| ogra_ | rickspencer3, devs are crazy people :) | 16:19 |
| xnox | Have the "source app store" for the desktop =) | 16:19 |
| Laney | aren't we going to need a source package format to get stuff built anyway, never mind the distribution problem? | 16:19 |
| xnox | login - and download the sources for apps installed on your phone =) | 16:19 |
| 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? | 16:19 |
| victorp_uds | cjwatson:do people need to get to it from the phone? they could download it from an app store website | 16:19 |
| xnox | Laney: good point. | 16:19 |
| beuno | alecu, no, the server | 16:20 |
| beuno | <---- | 16:20 |
| beuno | well | 16:20 |
| beuno | no | 16:20 |
| beuno | I lie | 16:20 |
| ogra_ | liar | 16:20 |
| beuno | not the installed apps | 16:20 |
| dobey | right, liar | 16:20 |
| alecu | beuno: you usually do :-) | 16:20 |
| beuno | :) | 16:20 |
| beuno | <---- not | 16:20 |
| dobey | server will know what's been "purchased", but not if it's installed on a particular device | 16:21 |
| geofft | Laney: Not necessarily. For proprietary apps, my workplace at least is already working around Debian source packaging. | 16:21 |
| geofft | Laney: And I keep pondering just switching to ar and forgetting proper source packaging. | 16:21 |
| 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 | 16:21 |
| alecu | dobey: the android server knows what is installed on each of your devices, though. | 16:21 |
| barry | cjwatson: even on the desktop, leaf packages only, right? | 16:22 |
| cjwatson | IMO yes | 16:22 |
| barry | +1 | 16:22 |
| alecu | dobey: (I'm not saying that's a good idea, though) | 16:22 |
| 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? | 16:22 |
| dobey | alecu: right, that's certainly possible. but i'm not sure it's reasonable :) | 16:22 |
| Laney | james_w: Indeed, I was assuming we would have that | 16:22 |
| Laney | don't know what other app stores do | 16:22 |
| beuno | there is no plan to have a build system on the server | 16:23 |
| beuno | we'll ask for built binaries | 16:23 |
| cjwatson | glatzor-uds: noted, will get to that shortly | 16:23 |
| Laney | intriguing | 16:23 |
| AlanBell | can other people host a repository for click packages? | 16:23 |
| beuno | cjwatson, see alecu's question about what tracks installed apps | 16:23 |
| dholbach | maybe we could all prefix questions with QUESTION: so they stand out? | 16:24 |
| brunogirin | aquarius_uds: also if you focus on a simpler packaging model, you won't be able to repackage everything | 16:24 |
| cjwatson | urgh, my connection fell over | 16:24 |
| beuno | AlanBell, yes, it will just be http(s) downloads | 16:24 |
| cjwatson | is the hangout still running? | 16:24 |
| xnox | glatzor-uds: hey there =) | 16:24 |
| ogra_ | cjwatson, yes | 16:24 |
| aquarius_uds | cjwatson: the hangout is running | 16:24 |
| aquarius_uds | but it is off air | 16:24 |
| dobey | cjwatson: yes and you're still in it it seems | 16:24 |
| cjwatson | bleh | 16:24 |
| cjwatson | my browser periodically loses its mind - I'll have to restart it | 16:24 |
| Laney | I think the lag is pretty significant | 16:24 |
| rickspencer3 | I didn't think I was saying anything quite so controversial that cjwatson had to leave | 16:24 |
| dobey | or maybe not | 16:24 |
| glatzor-uds | hello xnox | 16:24 |
| zebaszp | QUESTION: where would click packages unpack to? and should we be concerned about the FHS? | 16:24 |
| dobey | oh there it goes | 16:24 |
| AlanBell | hangout has gone . . . | 16:25 |
| zebaszp | oh dammit, it died | 16:25 |
| xnox | cjwatson: =) now hangout is done pending on you coming back =) | 16:25 |
| alecu | it died | 16:25 |
| xnox | s/done/gone/ | 16:25 |
| jdstrand | arg | 16:25 |
| dholbach | volveremos pronto! | 16:25 |
| xnox | "<cjwatson> my browser periodically loses its mind - I'll have to restart it" | 16:25 |
| ogra_ | probably someone with a higher bandwith line should be the host | 16:25 |
| mterry_uds | Huh, hangout isn't working for me right now | 16:25 |
| Laney | haha | 16:25 |
| aquarius_uds | the hangout will be back shortly: cjwatson is returning any moment now | 16:25 |
| mterry_uds | whoops, didn't see that was old news :) | 16:25 |
| cjwatson | zebaszp: /opt/apps.ubuntu.com/<package>/<version> or similar, which should be FHS-compatible | 16:25 |
| apw` | it is poor that the hangout is owned by any one person, shame on you google | 16:25 |
| * ogra_ hands out candy from the corridor | 16:26 | |
| zebaszp | cjwatson, thanks :) | 16:26 |
| apw` | oh i miss the candy, though my wasteline may not | 16:26 |
| rickspencer3 | hey all, does it seem to be working again? | 16:26 |
| zebaszp | not for me yet | 16:26 |
| bioevolgenec | Nope | 16:26 |
| ballock | nope | 16:26 |
| mdeslaur | Please, stay on the line. Your call is important to us. | 16:26 |
| brunogirin | rickspencer3: no | 16:26 |
| Ferruck | no | 16:26 |
| ogra_ | nope | 16:26 |
| dbarth | not yet | 16:26 |
| aquarius_uds | it will return shortly | 16:26 |
| zebaszp | lol mdeslaur | 16:26 |
| cjwatson | there is a lag; the same lag likely applies to startup | 16:26 |
| Ursinha-uds | there you go | 16:26 |
| mdeslaur | ah! back now | 16:26 |
| apw` | cjwatson:we are back | 16:27 |
| ogra_ | there we are | 16:27 |
| xnox | back =) | 16:27 |
| brunogirin | yay, it's back! | 16:27 |
| zebaszp | yeah! | 16:27 |
| apw` | cjwatson:i can see you from here | 16:27 |
| dobey | it's on air | 16:27 |
| xnox | refresh webpage to reconnect, btw.... | 16:28 |
| Laney | i didn't have to | 16:28 |
| brunogirin | QUESTION: so are we saying that click-package is a simple way to package simple apps and is not designed to replace .debs? | 16:29 |
| zebaszp | yes brunogirin | 16:29 |
| alecu | brunogirin: I understand that, yes. | 16:29 |
| cjwatson | brunogirin: yes | 16:29 |
| zebaszp | I said it first :P | 16:29 |
| apw` | how will security handle evaluating binary only packages | 16:29 |
| mdeslaur | apw`: we'll be confining them | 16:29 |
| bioevolgenec | apw +1 | 16:29 |
| alecu | apw`: that's what app sandboxing is for | 16:29 |
| mdeslaur | apw`: and the app author is responsable for it | 16:29 |
| apw` | mdeslaur: that is both great, and about the most scarey thing in the world :) | 16:30 |
| geofft | mdeslaur: That seems like the actually interesting part of the design. :) | 16:30 |
| AlanBell | so, version numbers and automatic updates . . . | 16:30 |
| mdeslaur | apw`: well, it's something that is quite necessary if you want a phone with 100k apps | 16:30 |
| AlanBell | and updates from one repository to another, is this all stuff that has been thought about? | 16:31 |
| alecu | apw`: each app will be run as a different user, and within an apparmor profile, and will have limited access outside its sandbox | 16:31 |
| apw` | mdeslaur:yep, i cannot deny it is correct, it is just scarey | 16:31 |
| zebaszp | QUESTION: how are user privileges handled with click packages? for installation, removal, on runtime, etc | 16:31 |
| geofft | I'm reminded of the complaining in the Mac developer community over the Apple App Store sandbox (on the desktop) | 16:31 |
| mdeslaur | alecu: not as a different user, no | 16:31 |
| xnox | AlanBell: server-side, as far as I understand it. | 16:31 |
| alecu | mdeslaur: ack | 16:31 |
| brunogirin | QUESTION: should it include a way to package tests (as in autopilot tests)? | 16:32 |
| dobey | cjwatson: if it was via aptdaemon, it'd make things much easier :) | 16:32 |
| mdeslaur | geofft: if you don't want it to be confined, you get it in the normal ubuntu archive | 16:32 |
| alecu | geofft: good point. But inspecting source code does not scale | 16:32 |
| dobey | as far as install/remove/upgrade goes | 16:32 |
| 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 | 16:32 |
| * ogra_ hopes we'll never get a million apps | 16:32 | |
| geofft | I certainly agree that confining is right, just that it's hard :) | 16:32 |
| zebaszp | why not, ogra_? | 16:32 |
| ogra_ | (i prefer 100k good apps to 1mio crap ones) | 16:32 |
| AlanBell | beuno: so, if I run a third party repo for my app, can I override someone elses app? | 16:33 |
| zebaszp | oh | 16:33 |
| geofft | mdeslaur: I'm curious about things like, does it have the Android issue where you can't refuse certain permissions? | 16:33 |
| jonobacon | ogra_: agreed | 16:33 |
| dobey | but if we use aptdaemon, will it be rewritten in c++? or will we ship python on phones? | 16:33 |
| mdeslaur | geofft: yes, but it's par for the course now...android and ios do it, etc. | 16:33 |
| ogra_ | dobey, in javascript ;) | 16:33 |
| 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. | 16:33 |
| 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 | 16:33 |
| cjwatson | we don't presently have a prohibition on using python for non-long-running things | 16:33 |
| mdeslaur | geofft: in v1, yes | 16:33 |
| beuno | AlanBell, yes, like it is today with PPAs and such | 16:33 |
| jdstrand | if people have questions (it is tangentially related to this, but really its own topic) | 16:33 |
| geofft | jdstrand: thanks | 16:34 |
| ogra_ | dobey, we already ship python (and guess we'll go on doing so) ... you are not allowed to write daemons in it though | 16:34 |
| dobey | ogra_: aptdaemon is written in python though :) | 16:35 |
| cjwatson | a d-bus service is kind of on the edge; IMO it doesn't run for long enough to be a practical problem | 16:35 |
| ogra_ | dobey, as long as it doesnt constantly run ... | 16:35 |
| xnox | REST call to a server, return paged results. | 16:36 |
| dobey | rickspencer3: having a local copy of the db | 16:36 |
| zebaszp | apt-cache? XD | 16:36 |
| xnox | (e.g. top 10, 20, 50, etc) | 16:36 |
| mdeslaur | cpu is less important than data transfer fees | 16:36 |
| dobey | searching via aptdaemon would be fine | 16:36 |
| xnox | zebaszp: no, no =) no apt-cache =) | 16:36 |
| mdeslaur | having a local database is a bad idea | 16:37 |
| dobey | hitting the rest api is going to hit network, which may more costly than just using cpu | 16:37 |
| ogra_ | dobey, we dont want a db locally | 16:37 |
| zebaszp | I know, I was just kidding | 16:37 |
| 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 | 16:37 |
| ogra_ | dobey, we generally have SD card speed on the disks | 16:37 |
| xnox | aptdaemon API is back-end agnostic =) such that you can search clicks and debs and rpms and etc. | 16:37 |
| ogra_ | you dont want to search a DB locally if you can avoid it | 16:37 |
| zebaszp | side note: iOS (as far as I know) does not keep a local db for the App Stor | 16:38 |
| zebaszp | *Store | 16:38 |
| mdeslaur | whatever api, it needs to gain knowledge of using an online db, instead of a local db | 16:38 |
| xnox | It's a good isolation point. either of them. | 16:38 |
| zebaszp | Cydia (aka APT for iOS) does, though, but we probably don't want to go that way :P | 16:39 |
| 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 | 16:39 |
| beuno | there will be a search api on the server | 16:39 |
| mdeslaur | Cydia is painful :P | 16:39 |
| dobey | ogra_: network could be MUCH slower | 16:39 |
| zebaszp | indeed mdeslaur | 16:39 |
| ogra_ | dobey, well, show me a package db that works fast on an SD on constrained HW and i'll agree :) | 16:39 |
| ogra_ | i simply havent seen one yet | 16:39 |
| mdeslaur | a package db that contains 250k packages is going to be big. | 16:40 |
| ogra_ | right | 16:40 |
| xnox | please no. | 16:40 |
| diwic | mdeslaur, not to mention the network fees to download its regular updates. | 16:40 |
| mdeslaur | yep | 16:40 |
| zebaszp | I don't know about iOS App Store data consumption because I have an iTouch, and I never bothered checking network usage | 16:40 |
| xnox | no changelogs - i'd rather have them in the app-store / on the web. And not downloaded and stored on my phone pointlessly. | 16:40 |
| zebaszp | I agree with xnox | 16:41 |
| beuno | oh, absolutely no local DB of all the apps available | 16:41 |
| geofft | IIRC iOS does the changelog as part of the app store submission, but not as part of the downloaded thing | 16:41 |
| 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 | 16:41 |
| xnox | I really don't care about changelogs any more on my phone. It just updates. | 16:41 |
| victorp_uds | aquarius_uds: +1 | 16:41 |
| victorp_uds | aquarius_uds:make it optional | 16:42 |
| 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 | 16:42 |
| xnox | if I want to read it, I read them on my computer on the apps store "big" webpage. | 16:42 |
| mdeslaur | dobey: storing a cache with a limited subset of data adds complexity for very little benefit | 16:42 |
| xnox | zebaszp: is it app store, or the app on first launch showing it? i remeber apps themself have a "changelog widget" | 16:42 |
| cjwatson | brunogirin: where are we expecting that these would be run? | 16:42 |
| zebaszp | the app store, xnox | 16:43 |
| dobey | mdeslaur: and yet necessary if we want a fast UI | 16:43 |
| xnox | thanks. | 16:43 |
| victorp_uds | aquarius_uds:seems that we are forgetting that an app will also have a web page that people can refer too? | 16:43 |
| apw` | cjwatson:tests might want to be in the same 'hole' as source | 16:43 |
| zebaszp | at least, when I go to the upgrade section, each app with available upgrade has a "changes" dropdown | 16:43 |
| cjwatson | perhaps, yes | 16:43 |
| cjwatson | zebaszp: yeah, but it often says "Bugs fixed", right? :) | 16:43 |
| mdeslaur | dobey: oh, caching the app store data is a different issue | 16:44 |
| 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 | 16:44 |
| mdeslaur | dobey: why? ios doesn't, android doesn't... | 16:44 |
| 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 :-)) | 16:44 |
| zebaszp | cjwatson, sometimes, but you'd be surprised | 16:44 |
| mdeslaur | dobey: search is better served online | 16:44 |
| olli-uds | there are existing tests | 16:44 |
| zebaszp | I think changes on the last version also appear on the store itself, before downloading a *new* app | 16:45 |
| achiang | why would an end user want a test suite on the phone? | 16:45 |
| rickspencer3 | hi mdeslaur o/ | 16:45 |
| rickspencer3 | :) | 16:45 |
| achiang | ... downloaded as part of the app isntall | 16:45 |
| brunogirin | achiang: to file a bug report | 16:45 |
| achiang | brunogirin: i highly doubt any normal consumers would want that | 16:46 |
| mdeslaur | hehe | 16:46 |
| jdstrand | \o/ | 16:46 |
| mdeslaur | :) | 16:46 |
| jdstrand | fyi (again)> https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement | 16:46 |
| 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 | 16:46 |
| mdeslaur | I can join the hangout with people want to discuss security more | 16:46 |
| mdeslaur | s/with/if/ | 16:46 |
| zebaszp | but with mobile apps, you don't need much more than that | 16:46 |
| alecu | o/ | 16:48 |
| zebaszp | when apps upgrade to major revisions, though, they tend to do an advert-like changelog | 16:48 |
| xnox | In app purchases, addons, extensions? | 16:48 |
| zebaszp | like "We've redesigned the whole interface so it is now easier to do x and y", and that sort of thing | 16:49 |
| dobey | i wrote an alternate package manager once | 16:49 |
| xnox | are those going to be implemented? or those will be separate apps? (e.g. a free app and a paid app) | 16:49 |
| 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) | 16:49 |
| mdeslaur | Users should be able to rate apps | 16:50 |
| mdeslaur | I don't think the platform is in a good position to be rating developer's apps | 16:50 |
| dobey | cjwatson: if it's all abstracted behind aptdaemon on the client, does it matter much? | 16:50 |
| beuno | yes, we have ratings and reviews | 16:50 |
| dobey | aquarius_uds: similar to when all branches on lp were upgraded to bzr v2 format | 16:51 |
| zebaszp | beuno, on USC, yes, but what about Touch? I thought the Dash would replace USC, can we rate apps from there? | 16:51 |
| 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? | 16:51 |
| zebaszp | is there/will there be one-click packaging on QtCreator or something along those lines? | 16:52 |
| alecu | brunogirin: good point. My guess is that packages should work from release to release | 16:52 |
| dobey | zebaszp: it would be part of the "preview" in the dash, i'd suspect | 16:52 |
| beuno | zebaszp, yes, the plan is to keep using the same system | 16:52 |
| cjwatson | this is mainly an SDK job to maintain maximal compatibility | 16:52 |
| cjwatson | if you look at the format as present, it has a framework field so that you can pick different versions if need be | 16:53 |
| jdstrand | beuno: maybe I misheard-- I thought we would have a gate on manual review (even if that was not an in depth review)? | 16:53 |
| mdeslaur | I assume device compatibility via capabilities is going to be in the manifest file, and needs to be looked into server-side | 16:53 |
| beuno | jdstrand, we will have a manual review stage, yes | 16:53 |
| jdstrand | ok | 16:53 |
| beuno | how in depth, I can't say :) | 16:54 |
| jdstrand | sure | 16:54 |
| 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? | 16:54 |
| 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 | 16:54 |
| zebaszp | yay! :D | 16:54 |
| dobey | does the SDK currently do cross-compiling for all the necessary archs? | 16:54 |
| cjwatson | davmor22: (a) yes if taken too far, but the primary focus is apps built against the SDK (b) apparmor confinement | 16:54 |
| cjwatson | dobey: we have a need to discuss cross-compiling with the SDK folks in detail | 16:54 |
| cjwatson | aiui it doesn't yet | 16:55 |
| cjwatson | imo it should :) | 16:55 |
| dobey | ok | 16:55 |
| dobey | right, it will have to if developers are going to upload binaries | 16:55 |
| zebaszp | just looking at his face, rickspencer3 is not amused | 16:56 |
| beuno | productized! | 16:56 |
| cjwatson | beuno: bingo | 16:56 |
| dobey | arm, i386, x86_64 at least | 16:56 |
| beuno | ralsina1, you listening? :) | 16:57 |
| aquarius_uds | ralsina1:ping :) | 16:57 |
| xnox | well, mostly =) | 16:57 |
| 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? | 16:57 |
| dobey | beuno: alecu and i are at least | 16:57 |
| ralsina1 | Sure! | 16:58 |
| geofft | Namely, for an ISV (like my workplace) that sells software that's inherently unsandboxable, this is sounding less interesting than it originally sounded | 16:58 |
| geofft | Which is not a complaint, just worth knowing. | 16:58 |
| 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. | 16:59 |
| zebaszp | QUESTION: why isn't Rick as cheerful as the rest? | 16:59 |
| rickspencer3 | hi zebaszp | 16:59 |
| zebaszp | I want to hear you laugh :P | 16:59 |
| rickspencer3 | HA HA HA | 16:59 |
| rickspencer3 | ? | 16:59 |
| 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. | 16:59 |
| dholbach | thanks everyone! | 17:00 |
| aquarius_uds | ralsina1: so, could you please track the work items that arise from the app lens design in the click packages blueprint? | 17:00 |
| zebaszp | that doesn't count :( | 17:00 |
| xnox | geofft: it's not sandboxable it should be on ubuntu phones =/ | 17:00 |
| geofft | xnox: I'm also thinking of the companies who currently distribute things via RPM or .tgz only. | 17:00 |
| 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 | 17:00 |
| === 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! | 17:00 |
| cjwatson | geofft: so if sandboxing is literally impossible for your application (why?), then I would say it's out of scope | 17:01 |
| aquarius_uds | I would be interested to hear why an app is unsandboxable, too | 17:01 |
| cjwatson | geofft: as I said earlier in the session, I'm intentionally not trying to supersede all uses of .debs | 17:01 |
| geofft | cjwatson: Well, the primary thing we sell is desktop virtualization :) | 17:01 |
| geofft | So unless there's an apparmor profile that lets us get to the virtualization interfaces, well.... | 17:01 |
| 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 | 17:02 |
| 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) | 17:02 |
| cjwatson | I think mdeslaur would have to speak to the specifics of confining such things | 17:02 |
| cjwatson | both whether it's possible and whether it's useful | 17:02 |
| dobey | geofft: i presume sandboxed wouldn not preclude a way to allow the user to say an app is allowed to access certain data | 17:02 |
| 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. | 17:02 |
| cjwatson | however I'm reminded of the fact that Android has a permission called "BRICK" | 17:03 |
| 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 | 17:03 |
| jdstrand | short | 17:03 |
| dobey | geofft: facebook app for example would want to access your photos, so you could upload them, for example | 17:03 |
| cjwatson | that doesn't necessarily render them out of scope for this package format / independent distribution though | 17:03 |
| dobey | doh, i said "for example" twice there | 17:03 |
| jdstrand | you can still use apparmor with debs, etc, so like cjwatson said, that is always available | 17:03 |
| geofft | jdstrand: if the implication is "possibly okay in the long term", cool! | 17:04 |
| mdeslaur | geofft: I'm missing some context...you want to get your application in the app store? | 17:04 |
| cjwatson | FWIW, I think sandboxing is kind of orthogonal to listaller/0install/etc. | 17:05 |
| zebaszp | examples, examples, examples! </ballmer> | 17:05 |
| cjwatson | in that the thing that executes apps is (in principle, mostly) independent of the thing that installs them | 17:05 |
| cjwatson | 0install does define a "how to run this app" command for each app | 17:05 |
| geofft | mdeslaur: I'm mostly just thinking about proprietary apps I've run as a user that distribute themselves as poorly-made RPMs. | 17:05 |
| cjwatson | listaller probably does too (haven't looked in detail), and we clearly need to | 17:05 |
| geofft | So, like, IBM's TSM backup client, VMware Player (which isn't even an RPM), proprietary VPN clients, .... | 17:06 |
| dobey | i must be off though, as that session ate through my normal lunch time. :) | 17:06 |
| geofft | From the description of "better format for people who don't care about Debian packaging complexities", it sounds like it fits those. | 17:06 |
| 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 | 17:07 |
| geofft | From the description "and sandboxing", it sounds like it fits none of those, so I'm just realigning my expectations | 17:07 |
| cjwatson | don't care and can't be persuaded to care :) | 17:07 |
| 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 | 17:07 |
| mdeslaur | geofft: and the deb format is just an archive really...you don't need a source package to create one | 17:08 |
| geofft | Yeah. Work is currently using actual debs (slightly less than actual source packages) and actual CDBS. | 17:08 |
| cjwatson | right, I think if you already have in-house .deb experience the gains are less interesting | 17:08 |
| geofft | _I'm_ happy to do Debian packaging, but not everyone is. | 17:08 |
| geofft | OK. | 17:08 |
| cjwatson | in that a sizeable part of this is simplifying things for app developers | 17:08 |
| cjwatson | now, there *are* other gaisn | 17:08 |
| cjwatson | *gains | 17:08 |
| mdeslaur | geofft: so instead of generating your .deb files from source packages, just create them as an archive | 17:09 |
| cjwatson | things like speed of app installation, guaranteed independence if things go wrong - at the cost of flexibility though | 17:09 |
| 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 | 17:09 |
| cjwatson | if it's "unpack a filesystem tree", this might be simpler | 17:09 |
| * cjwatson <- not a salesman | 17:09 | |
| geofft | Sounds reasonable | 17:10 |
| kiwinote | so the app store server will allow us to upload deb files as well as click packages? | 17:10 |
| kiwinote | or does deb files imply an own distribution channel? | 17:11 |
| 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) | 17:11 |
| 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. | 17:11 |
| cjwatson | err, "not be available to install on the phone" is a strong statement, you mean through the dash integration stuff | 17:12 |
| xnox | kiwinote: there is also myapps / extras.ubuntu.com for deb apps. | 17:12 |
| kiwinote | thanks, looks like canonical partners seems the best fit here | 17:12 |
| xnox | cjwatson: normal debs -> imply writable root-fs -> which we do not have, until convergence is delivered & enabled. | 17:12 |
| cjwatson | https://wiki.ubuntu.com/ImageBasedUpgrades calls for a switch to enable apt | 17:13 |
| xnox | true. | 17:14 |
| 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 :) | 17:14 |
| * xnox looks at my "convergence" poster again =) sure normal debs will need to start working rather sooner than later. | 17:15 | |
| * xnox off to find lunch. | 17:15 | |
| * cjwatson -> dinner | 17:17 | |
| === 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 | 18:04 |
| cjwatson | on air now | 18:05 |
| diwic | cjwatson, still "starting soon..." here | 18:06 |
| apw | no sign of the stream on the u-tube bit | 18:06 |
| lool | started here after reloading | 18:06 |
| mfisch | diwic: thats youtube being stupid, force reload several times | 18:06 |
| lool | reload the page | 18:06 |
| diwic | tried that, this time it worked though | 18:07 |
| apw | what junk ... there now | 18:07 |
| cjwatson | diwic: there's a time lag | 18:07 |
| diwic | cjwatson, btw last session one could see the background color of your screen reflecting in your face :-) | 18:07 |
| zyga | hi | 18:07 |
| jdstrand | information disclosure | 18:08 |
| cjwatson | diwic: heh, not much I can do about the lighting in this room - wasn't designed for video | 18:08 |
| timrc | achiang: always get a kick out of your profile picture | 18:08 |
| stgraber | https://wiki.ubuntu.com/ImageBasedUpgrades | 18:08 |
| * achiang is on video mute because eating lunch now (i had another call last hour) | 18:09 | |
| * lool hasn't joined the HO but is watching and might jump in later | 18:10 | |
| ogra_ | rsalveti, | 18:10 |
| ogra_ | oops | 18:10 |
| gQuigs | anyone have direct youtube link? | 18:10 |
| gema | gQuigs: for joining the hangout or just watching? | 18:11 |
| gQuigs | gema: just watching | 18:11 |
| zyga | QUESTION: stgraber, does that mean the recovery partition and the upgader itself cannot be upgraded if they have issues? | 18:11 |
| gema | gQuigs: http://www.youtube.com/watch?feature=player_embedded&v=Nddn4duIR2c | 18:11 |
| gQuigs | thanks gema | 18:11 |
| lool | zyga: they can be upgraded just like all the android bits can be upgraded including the bootloader | 18:11 |
| cjwatson | stgraber: sure, sorry | 18:11 |
| 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 | 18:11 |
| zyga | lool: thanks | 18:11 |
| lool | but we likely wouldn't do this too frequently | 18:12 |
| Laney | is there going to be any UI for the apt update route? | 18:12 |
| gQuigs | gema: wasn't loading for me at all... oh.. because I'm on the wrong talk :/ oops | 18:12 |
| gema | ;) | 18:12 |
| lool | stgraber: FYI, green on black a bit hard to read over stream; white on black or black on white might be better | 18:13 |
| stgraber | zyga: the update may contain changes to any partition including the android bits, basedband or even recovery partition | 18:14 |
| zyga | stgraber: interesting, thanks | 18:15 |
| zyga | stgraber: and totally impressive demo | 18:15 |
| gema | cjwatson: can you unclick stgraber? | 18:15 |
| gema | so that others take the screen when talking | 18:16 |
| 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 | 18:16 |
| cjwatson | gema: done | 18:17 |
| gema | cjwatson: ta! | 18:17 |
| victorp | stgraber, so is that file then automatically re-install in an update? | 18:20 |
| Laney | so operators and oems would have to offer an apt archive too, right? | 18:20 |
| stgraber | victorp: yes, it'd appear as if it was part of our read-only base system | 18:20 |
| zebaszp | QUESTION: what about superphones/desktop-capable mobile devices? how would you update those, do you disable apt for the base system packages? | 18:21 |
| stgraber | Laney: nope, they'd have to provide us with a .tar.xz overlay to apply on our base system | 18:21 |
| Laney | stgraber: but you can get yourself out of overlay upgrade mode | 18:21 |
| geofft | who generates the diff images? I guess this is part of the server? | 18:21 |
| stgraber | right, in which case those bits will likely not be updated | 18:21 |
| victorp | stgraber, lool are default apps installed in the system partition? | 18:22 |
| sergiusens | ogra_: yeah, how are ports going to be maintained? | 18:22 |
| victorp | ogra_, yes with rickspencer3 branding | 18:22 |
| victorp | :) | 18:22 |
| Laney | hmm | 18:24 |
| victorp | ogra_, shouldnt we give the community the option to have the same set up? | 18:24 |
| infinity | ogra_: Is there any reason we need to have enough Android userspace installed that these weird directories are being created? | 18:24 |
| ogra_ | infinity, persistent properties are stored in direcories and files in /userdata | 18:25 |
| 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. | 18:25 |
| sergiusens | victorp: not all devices are _fastboot_ devices and simple to tinker with | 18:25 |
| victorp | sergiusens, agreed, I thought we were talking about the "official" community devices that we produce images for | 18:26 |
| victorp | rather than all devices | 18:26 |
| TheMuso | infinity: Thats the impression I was under as well. | 18:26 |
| infinity | It sounds to me like we're including more of Android's userspace than we actually need. | 18:27 |
| victorp | infinity, we are using more than that right now | 18:27 |
| infinity | But that's probably out of scope for this conversation. | 18:27 |
| ogra_ | infinity, we include HAL, all sensor drivers and userspace tools, the audio system etc .... and the platform-api makes use of these | 18:28 |
| sergiusens | infinity: not really | 18:29 |
| victorp | ogra_, seems like you need another session for that? | 18:29 |
| 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" | 18:29 |
| victorp | that = partitions and folders | 18:29 |
| victorp | apw, +1 | 18:29 |
| ogra_ | victorp, well, we're short on free slots | 18:29 |
| victorp | ogra_, make one slot with you, lool and stgraber :) | 18:30 |
| ogra_ | as long as the syystem can adapt i'm happy though | 18:30 |
| victorp | ogra_, adapt and assimilate | 18:31 |
| sergiusens | ogra_: if that happens include me in the slot as some of that work will fall onto me | 18:31 |
| ogra_ | fine with me, i just dont want to find out by end of the month that what i implemented will never work :) | 18:31 |
| ogra_ | sergiusens, sure | 18:31 |
| * victorp hugs ogra_ | 18:32 | |
| * ogra_ hugs victorp | 18:32 | |
| lool | (I hear nice bird cheeps coming from one of the streams) | 18:32 |
| ogra_ | might be me | 18:32 |
| ogra_ | i have the window open | 18:32 |
| victorp | very relaxing | 18:33 |
| timrc | Bird Song as a Service | 18:33 |
| ogra_ | heh | 18:33 |
| cjwatson | acronym isn't great | 18:33 |
| infinity | I prefer Bird as a Service. | 18:34 |
| 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 | 18:34 |
| ogra_ | pidgin mail ? | 18:34 |
| victorp | lool, sure , makes sense | 18:34 |
| victorp | lool, it would be nice for all apps to be manage/upgraded the same way | 18:35 |
| lool | true | 18:36 |
| 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 | 18:36 |
| sergiusens | cjwatson: I guess you can start with the community core apps | 18:36 |
| victorp | lool, ^ | 18:36 |
| cjwatson | victorp: that's definitely a new technical requirement - may be interesting issues with having different versions of apps installed in different places | 18:37 |
| apw | presumably the image updater does not care what format they are | 18:37 |
| 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 | 18:37 |
| infinity | There's nothing wrong with the Android-style hybrid of having a package both in the base system AND in the store. | 18:37 |
| cjwatson | it doesn't but click-package certainly would :) | 18:37 |
| infinity | Assuming we can overlay that sanely. | 18:37 |
| sergiusens | infinity: +1 | 18:37 |
| cjwatson | we'd need to make sure that the app executor can cope, basically | 18:37 |
| 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. | 18:37 |
| lool | any other question from anyone? | 18:38 |
| 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 | 18:38 |
| gema | what kind of testing are we planning on this? | 18:38 |
| victorp | e.g. dropbox | 18:38 |
| cjwatson | infinity: do they just have an executor that looks in both places? | 18:38 |
| timrc | Is there going to be a rollback feature? | 18:38 |
| apw | stgraber, i have been adding what I am _hearing_ as actions, they should be reviewed before the end in case I miss understood | 18:38 |
| sergiusens | lool: is it going to be possible to rollback? | 18:38 |
| apw | stgraber, and some need owners if they are right | 18:38 |
| infinity | cjwatson: I'm not sure, TBH, how that works. The older version just "disappears" from the UI until you uninstall the new one. | 18:38 |
| infinity | cjwatson: On the underside, I'm not sure what they're doing. | 18:39 |
| lool | sergiusens: oh that's a good one | 18:39 |
| gema | QUESTION: What about testing, what are you guys going to do/expect from QA? | 18:39 |
| geofft | Are there plans / thoughts to make this work on the desktop? | 18:39 |
| victorp | sergiusens, +1 | 18:39 |
| geofft | It sounds like all this discussion is very Android-specific. | 18:39 |
| 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? | 18:39 |
| timrc | sergiusens: was that coincidence that we asked the same question? | 18:39 |
| sergiusens | timrc: interesting, didn't see it. | 18:40 |
| timrc | sergiusens: freaky | 18:40 |
| sergiusens | timrc: but it had to be asked... today we have lots of mechanisms to move around | 18:40 |
| gema | ack | 18:40 |
| lool | ah it's actually timrc's question too | 18:40 |
| apw | QUESTION: how are these updates going to interact with the propose 'staggered updates' we are moving to for .debs ? | 18:41 |
| cjwatson | YM phased updates I think? | 18:41 |
| victorp | zebaszp, superphones are first of all phones. So i will assume they update more like phones that desktop for the core base packages | 18:41 |
| lool | sergiusens, timrc: Will ask as soon as the current discussion ends | 18:41 |
| apw | cjwatson, indeed phased | 18:41 |
| timrc | lool: Thanks | 18:41 |
| zebaszp | thanks victorp, but then what happens to non-core user-installed desktop packages? | 18:44 |
| lool | (URL rewrites basically) | 18:44 |
| victorp | zebaszp, indeed what happens | 18:44 |
| lool | e.g. channels.json?model=galaxy-nexus&country=fr | 18:45 |
| lool | zebaszp: these are installed in the userdata partition | 18:45 |
| victorp | zebaszp, if they are store in the data partition | 18:45 |
| mwilley | It would be interesting to apply these techniques on the desktop as well; is it considered? Something like a chromebook. | 18:46 |
| lool | which is not updated | 18:46 |
| victorp | then they can be updated with apt, they wont be wiped by this, but it creates an interesting game with dependecies | 18:46 |
| ogra_ | mwilley, if it proves to be good, i dont see why not | 18:46 |
| 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 | 18:46 |
| victorp | mwilley, agreed - this is interesting for some desktops and thinclients | 18:46 |
| victorp | lool, 14.04 :) | 18:46 |
| rsalveti | "developer" mode :-) | 18:48 |
| victorp | stgraber, so you can't install .deb packages in the userdata partition? | 18:48 |
| lool | no; unless you are root and create a whole Ubuntu chroot there :-) | 18:49 |
| xnox | well it will be an "upgrade", whice leaves things rw & offers no other upgrade paths. | 18:49 |
| ogra_ | rsalveti, and we'll make them tap 8 times !!! | 18:49 |
| sergiusens | lool: how is convergence going to be taken into account then? | 18:49 |
| rsalveti | ogra_: o/ | 18:49 |
| ogra_ | muhahaha | 18:49 |
| victorp | lool, does that work for a converge device? | 18:49 |
| sergiusens | ah, youtube lag answered my question :-P | 18:49 |
| xnox | sergiusens: not targeted for 13.10. | 18:49 |
| victorp | alright stgraber just answer my question | 18:49 |
| rsalveti | and not properly planned I'd guess | 18:49 |
| lool | great | 18:49 |
| lool | any other question? | 18:50 |
| victorp | stgraber, that needs some thinking about for 14.04 | 18:51 |
| Laney | how will we be delivering SRUs? | 18:51 |
| barry | lp:~barry/+junk/resolver | 18:51 |
| Laney | rolling them up into a weekly image or something? | 18:51 |
| ogra_ | weekly ? | 18:51 |
| barry | (probably needs a better name + a real lp project page) | 18:51 |
| lool | victorp: we've actually discussed it in the past, but didn't settle on a design for this | 18:51 |
| stgraber | https://phablet.stgraber.org | 18:51 |
| xnox | Laney: monthly delta image. | 18:51 |
| geofft | There's some mention in the blueprint about multiple /var/lib/dpkgs etc. Did that end up being relevant? | 18:51 |
| ogra_ | yeah, monthly sounds more like it | 18:51 |
| victorp | lool, I agree that it doesnt not need to be solved for 13.10 | 18:52 |
| geofft | (I'm interested in that for a couple of reasons, only one of which is an implementation of image-based updates) | 18:52 |
| xnox | geofft: that's rough plans at how to handle convergence. | 18:52 |
| timrc | so if I skip 10 updates, and then update, will I have 10 separate updates in tandem to do? | 18:52 |
| geofft | xnox: So not relevant for a pure image-based system, until apt starts being user-exposed? | 18:52 |
| xnox | and having some ReadOnly dpkg packages while others RW. | 18:52 |
| 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 | 18:52 |
| achiang | timrc: it depends on what kind of user you are | 18:52 |
| xnox | timrc: if upgrader calculates, that a full image is quicker, it will simply take that. | 18:52 |
| xnox | geofft: correct. | 18:53 |
| timrc | xnox: okay | 18:53 |
| victorp | lool, that is what I was thinking | 18:53 |
| geofft | OK. Idly, is there current work towards that in some bzr branch or something? | 18:53 |
| lool | geofft: it's definitely one of the two approaches that we're considering | 18:53 |
| xnox | timrc: see stephane's demo earlier. | 18:53 |
| geofft | I was half wanting to fiddle with that in my spare time | 18:53 |
| jsjgruber-uds | QUESTION: When would the updates happen so the user isn't impacted by the reboot? | 18:53 |
| victorp | lool, anyway - we should understand it better by october, via UfA work | 18:54 |
| stgraber | server code: https://code.launchpad.net/~stgraber/+junk/phablet-update | 18:54 |
| victorp | and we can talk again then | 18:54 |
| timrc | jsjgruber-uds: when you open the kindle app and get into a good book | 18:54 |
| stgraber | client code: https://code.launchpad.net/~barry/+junk/resolver | 18:54 |
| lool | victorp: exactly; also, we will have had some experience with these image based updates and a better understanding of them too | 18:54 |
| timrc | (my experience with android :)) | 18:54 |
| achiang | timrc: that will be the model for commercial phones -- you have to do upates in serial | 18:54 |
| victorp | timrc, user error... stop reading books and the world will be better | 18:55 |
| victorp | :) | 18:55 |
| 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 | 18:55 |
| timrc | achiang: aye | 18:55 |
| lool | achiang: depends | 18:55 |
| ogra_ | totally | 18:55 |
| timrc | victorp: hah | 18:55 |
| victorp | timrc, also the download will be done in the background (wifi only) so you would not know | 18:56 |
| * barry enjoys the relaxing birdsong in the last few minutes | 18:56 | |
| Laney | will we have a way of presenting the changes? | 18:56 |
| apw | presumably we will be taking into account whether they have b/w for this | 18:56 |
| Laney | so you can see how much you want to reboot or not | 18:56 |
| sergiusens | achiang: well you could do like the chromebook and subscribe to the _developer channel_ | 18:56 |
| apw | for example being on wifi does not mean i want updates, i may be proxying 3g onto wifi for example | 18:56 |
| infinity | apw: Some people have ISPs that show up within a few days of them moving in. | 18:57 |
| apw | *slap* | 18:57 |
| infinity | apw: Don't let your BT bitterness colour spec writing. | 18:57 |
| apw | infinity, i think i was just asking for 'download when i click only' 'download on wifi' 'download immediatly always' as option | 18:58 |
| chiluk | that actually brings about an important issue. has it been made possible to only pull updates over wifi? | 18:58 |
| Laney | I suppose there should be a system API for this | 18:58 |
| infinity | apw: (And yes, "always", "wifi", "manual" seem to be the usual choices for this sort of thing) | 18:58 |
| Laney | it'll affect e.g. uploading pictures too | 18:58 |
| sergiusens | stgraber: is this new recovery image going to be backwards compatible with update.zips ? | 18:58 |
| apw | infinity, design tends to not like usual options | 18:58 |
| mwilley | Agreed on "wifi" does not necessarily mean open season on downloads. My "wifi" is actually a bandwidth-capped satellite connection half the time. | 18:59 |
| ogra_ | sergiusens, as i understood it will be just an ubuntu initrd | 18:59 |
| ogra_ | with special scripts etc | 18:59 |
| 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. | 18:59 |
| sergiusens | ogra_: well, for non fastboot phones, updating recovery is a dangerous operation :-) | 18:59 |
| ogra_ | sergiusens, well, dd :) | 18:59 |
| geofft | yeah, an NM interface for "am I on a reasonable connection or not" would be great | 18:59 |
| ogra_ | just dont run out of power | 18:59 |
| apw | stgraber, some of us are saying being on WIFI is not enough to know my b/w is free | 18:59 |
| geofft | on desktop, that may want to be conditionalized by e.g. what ESSID I'm on | 19:00 |
| Laney | not according to whether Three decide to raid my walle they aren't, sadly | 19:00 |
| 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 | 19:00 |
| Laney | but I might want to prioritise its usage, yeah | 19:00 |
| === 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 | 19:00 |
| ogra_ | sergiusens, well, you would pull the zip for your device (using phablet-flash) ... and that zip would replace the recovery part. | 19:01 |
| 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 | 19:01 |
| mwilley | I like the NetworkManager bandwith guide idea. Time of use can be expressed too. B/W free on my satellite during middle night. | 19:01 |
| sergiusens | ogra_: not on non fastboot devices ;-) | 19:02 |
| 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 | 19:02 |
| ogasawara | cjwatson: do I ping your or bdmurray for hangout url for next foundations session? | 19:02 |
| ogra_ | sergiusens, what non fastboot devices are there that we support atm ? | 19:02 |
| cjwatson | ogasawara: I believe bdmurray will be running it | 19:02 |
| sergiusens | ogra_: thinking about community here | 19:02 |
| ogasawara | cjwatson: ack, thanks | 19:02 |
| cjwatson | I've run three in a row now :) | 19:02 |
| cjwatson | well, been crew for, anyway ... | 19:03 |
| ogra_ | sergiusens, well, they use android based phones atm ... and thats using fastboot mostly | 19:03 |
| * timrc pretends he's eating a churro and drinking a coke while he waits for the next session | 19:03 | |
| ogra_ | and as long as our platform-api is so closely bound to android i dont see that changing | 19:03 |
| ara | timrc, lol | 19:03 |
| sergiusens | timrc: you can do it for real too :-P | 19:04 |
| cjwatson | bdmurray: ... | 19:05 |
| * rsalveti waves for the kernel session | 19:05 | |
| bdmurray | cjwatson: setting it up | 19:06 |
| cjwatson | cool | 19:06 |
| cjwatson | you seem to be on air now | 19:09 |
| lool | yup | 19:09 |
| cjwatson | (lower third reminder) | 19:10 |
| timrc | birds singing, white noise… are you people trying to put me to sleep? | 19:10 |
| smb | Hm, is it just breaking up a lot for me? | 19:12 |
| jmleddy | I don't hear anything | 19:12 |
| jmleddy | there is a lot of static | 19:12 |
| jmleddy | that just went away for a little bit | 19:12 |
| lool | ogasawara: there is like a white scratch noise, but no feedback on the stream | 19:12 |
| mdeslaur | ogasawara: I hear you | 19:12 |
| kamal-uds | the audio sounds fine to me, no feedback | 19:12 |
| timrc | Yeah lots of static but it went away for a spell | 19:12 |
| sforshee | ogasawara, do you have the youtube stream open? | 19:12 |
| lool | ogasawara: do you have a tab of the meeting open? | 19:12 |
| jdstrand | ogasawara: do you have your google+ and your etherpad/etal window open? I recommend pausing the one next to the etherpad | 19:12 |
| bdmurray | I think she sorted it out now | 19:12 |
| jmleddy | what happened to phb-crystal-ball? | 19:13 |
| lool | ogasawara: these are just desktop (non-touch) kernels, right? | 19:13 |
| vanhoof | jmleddy: http://phb-crystal-ball.org/ | 19:13 |
| bubbly | I would, as of currently, say 3.11.x if all possible | 19:13 |
| jmleddy | oh nice, it's back up | 19:14 |
| jmleddy | vanhoof: thanks | 19:14 |
| rtg_ | lool, correct | 19:14 |
| xnox | the video feed says "please stand by" | 19:14 |
| xnox | are we on air? | 19:14 |
| lool | xnox: it's on | 19:14 |
| lool | xnox: reload maybe | 19:14 |
| TheMuso | I'm getting video here. | 19:14 |
| ppisati | AFA arm is concerned, 3.11 is way better if we want to ad exynos5 support to -generic | 19:14 |
| xnox | ah, yeah came up now. | 19:14 |
| ppisati | rtg_: correct | 19:15 |
| ppisati | ogasawara: ^ | 19:15 |
| lool | ppisati: aren't we tracking android kernel trees for each target touch SoC anyway? | 19:15 |
| ppisati | lool: yep, talking about desktop here | 19:15 |
| vanhoof | ppisati: +1 exynos5 in generic, ike is involved there, ogasawara ^ | 19:15 |
| lool | ppisati: ah exynos5 is a desktop target too? ok | 19:15 |
| bubbly | My opinion, if the generic flavuor doesn't fit your liking, compile your own kernel | 19:16 |
| ppisati | lool: i've no idea if there's any exysno5 project going on, just an observation | 19:16 |
| rsalveti | cool, should be able to test nexus 10 later today | 19:16 |
| lool | ppisati: ack | 19:16 |
| * ppisati notes the video stream is really crappy here... :( | 19:16 | |
| smb | ppisati, Same here | 19:16 |
| jdstrand | ogasawara: we discussed that there might be something we can do with update-manager as well | 19:18 |
| jjohansen | ogasawara: yep from security team | 19:18 |
| jdstrand | ogasawara: like a one-time 'this kernel is EOL, blahblah...' | 19:18 |
| ara | QUESTION: can you elaborate more on that, please? | 19:18 |
| ara | why we are not upgrading people? | 19:18 |
| ogra_ | ara, nope, only software | 19:19 |
| ogra_ | :) | 19:19 |
| ara | ogra_, lol | 19:20 |
| ara | I certainly need an upgrade | 19:20 |
| ara | it is time for ara 2.0 | 19:20 |
| ogra_ | nah, you are good | 19:20 |
| === hikiko__ is now known as hikiko-uds | ||
| jmleddy | heh | 19:20 |
| xnox | ogasawara: why was that in place before? or was that decision post-poned until there is a second backport kernel? | 19:20 |
| * ogra_ wonders why the stream is so choppy this session | 19:21 | |
| apw | ogra_, i have found a reload on the stream can help when that happens | 19:22 |
| cjwatson | I'm not sure how much of it depends on the person running the hangout | 19:22 |
| jmleddy | wasn't it always that way? | 19:22 |
| ara | thanks | 19:22 |
| cjwatson | but it's bizarre that anyone else running the hangout might make it *worse* than me doing so | 19:22 |
| jmleddy | or are you talking about the images? | 19:22 |
| * ogra_ reloads | 19:22 | |
| bjf | ogra_, bdmurray is running the session on a nexus4 | 19:22 |
| ogra_ | haha | 19:22 |
| cjwatson | unless it's CPU-dependent rather than network-dependent | 19:22 |
| ogra_ | really ?!? | 19:22 |
| apw | any further questions, #ubuntu-kernel on freenode | 19:23 |
| * smb blames the UK people with big pipes draining the bits | 19:23 | |
| bubbly | I don't upgrade becauseof hardware issues | 19:23 |
| jmleddy | if it isn't broke don't fix it | 19:23 |
| ara | we are still getting a new HWE stack in 12.04.3? | 19:23 |
| ara | QUESTIOn: ^ | 19:23 |
| apw | smb, you just need to spend some more of your hard currency, harder than mine anyhow | 19:23 |
| gQuigs | ara: yea.. I remember something about raring not getting a backport to 12.04.2 | 19:24 |
| apw | ara ask that again over on #ubuntu-kernel, folk have gone | 19:24 |
| gQuigs | ^ | 19:24 |
| jmleddy | ara: I think so, it's just not going to be automatic upgrade | 19:24 |
| 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. | 19:25 |
| 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. | 19:25 |
| cjwatson | xnox: er, or she's in the session right here :) | 19:26 |
| xnox | "This live event is over" =))))))) | 19:26 |
| smb | xnox, better than "this life event is over" :-p | 19:27 |
| xnox | smb: "this second life is over" :DDDDD | 19:29 |
| smb | thankfully, this first one is depressing enough 3:) | 19:30 |
| === 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 | ||
| === schwuk is now known as schwuk_away | ||
| === 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 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!