| === tvoss|eod is now known as tvoss | ||
| === Sweetsha1k is now known as Sweetshark | ||
| === tvoss is now known as tvoss|food | ||
| === rsalveti_ is now known as rsalveti | ||
| === tvoss|food is now known as tvoss | ||
| === pete-woods1 is now known as pete-woods | ||
| === udsbotu changed the topic of #ubuntu-uds-client-1 to: Track: Client | Out-of-the-box experience for Ubuntu Phone | Url: http://summit.ubuntu.com/uds-1303/meeting/21604/client-1303-out-of-box-experience/ | ||
| tsdgeos_uds | is the out of the box experience session happenning? | 14:03 |
|---|---|---|
| Mirv | tsdgeos_uds: it isn't in the schedule at the moment: http://summit.ubuntu.com/uds-1303/2013-03-06/ | 14:06 |
| tsdgeos_uds | yeah | 14:06 |
| tsdgeos_uds | but it was like 30 min ago last time i checked :D | 14:06 |
| Mirv | hmm.. | 14:07 |
| pete-woods | it seems to have disappeared.. | 14:07 |
| ricmm | it *just* disappeared | 14:08 |
| ricmm | the session is cancelled | 14:09 |
| ricmm | sorry guys | 14:10 |
| tsdgeos_uds | okidoki | 14:10 |
| tsdgeos_uds | back later then D: | 14:10 |
| === udsbotu changed the topic of #ubuntu-uds-client-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1303/client-1/ - http://ubottu.com/uds-logs/%23ubuntu-uds-client-1.log | ||
| === udsbotu changed the topic of #ubuntu-uds-client-1 to: Track: Client | Add app-model and -lifecycle to platform api | Url: http://summit.ubuntu.com/uds-1303/meeting/21613/client-1303-add-app-model-and-lifecycle-to-platform-api/ | ||
| tvoss | seb128, are you going to start the session? | 14:53 |
| seb128 | tvoss, yep, just finishing the previous one (I had to host the foundations one, slangasek was having hangout issues) | 14:54 |
| tvoss | seb128, ack | 14:54 |
| tedg | Let's go! | 15:01 |
| tedg | Oh, sure | 15:01 |
| tvoss | tedg, wanna join, we have got free places :) | 15:01 |
| achiang | tvoss: can you send an invite to ondrej kubik? | 15:02 |
| tvoss | achiang, at canonical.com? | 15:02 |
| achiang | tvoss: one sec, trying to track him down ;) | 15:02 |
| tvoss | achiang, yup | 15:02 |
| achiang | ondra: to what email address shall tvoss send an invite to? | 15:02 |
| tvoss | tedg, you coming? | 15:03 |
| victorp_ | \o/ | 15:03 |
| victorp_ | rsalveti I am definetly rolling | 15:03 |
| victorp_ | downhill | 15:03 |
| rsalveti | victorp_: haha | 15:04 |
| victorp_ | tvoss just dont do it in a public channel | 15:04 |
| victorp_ | TBOB | 15:06 |
| achiang | 7 bits shall be sufficient! | 15:07 |
| kyleN | POWER | 15:08 |
| seb128 | we have 2 tedg, scary | 15:09 |
| tedg | seb128, yeah, chrome crashed :-( | 15:10 |
| ricmm | and my network went down | 15:11 |
| ricmm | and now I cant reach plus.google.com :( | 15:11 |
| awe_ | ted, telephony-app has the same problem... | 15:15 |
| bfiller_ | if hud fires a command to an app via the HUD and the app is suspended need a way to deliver the event to the app when it wakes up | 15:16 |
| bfiller_ | or somehow process it | 15:16 |
| awe_ | bfiller_, we need a concept of services | 15:16 |
| awe_ | provided by apps | 15:16 |
| awe_ | ondra is nailing it | 15:16 |
| bfiller_ | it's one solution | 15:16 |
| awe_ | bfiller_, we need the concept ( I'm not proposing a particular solution ) | 15:17 |
| victorp_ | tvoss when is phase1 and phase2 | 15:17 |
| bfiller_ | not sure how that helps with the hud example by having a background service | 15:17 |
| awe_ | bfiller_, like answering a phone call | 15:18 |
| awe_ | bingo | 15:18 |
| dbarth | tedg: what about serializing the last known command set before the app suspend? | 15:18 |
| tedg | dbarth, Yeah, I'm less worried about getting the options, we cache that, I'm worried what happens if the user clicks on them. | 15:19 |
| tedg | dbarth, They'd expect the app to respond somehow. | 15:19 |
| kyleN | CURIOUS: are the high level usability requirements for this? | 15:20 |
| zyga-uds_ | hi | 15:20 |
| dbarth | tedg: and that could be one reason to wake up the app, reply, go back to sleep; until the app really has to perform the action itself | 15:20 |
| dbarth | ? | 15:20 |
| kyleN | s_the_there_ | 15:20 |
| tedg | dbarth, Yeah, that would be an option, perhaps HUD manages app state? Seems a bit heavy though. | 15:20 |
| dbarth | tedg: ie, short helper "continuation"s, as opposed to long running tasks | 15:21 |
| dbarth | HUD could rely on ad-hoc side APIs for that purpose; for ex. other mobile OSes have APIs for download tasks or VOIP calls | 15:23 |
| achiang | tedg: no - iOS doesn't allow badly written apps | 15:23 |
| dbarth | ie, specialized APIs to adjust to the general app lifecycle | 15:23 |
| tedg | achiang, Well, sure. I don't think we want that level of control. | 15:23 |
| achiang | tedg: why not? i think we do | 15:23 |
| achiang | tedg: this is my hot button | 15:24 |
| tedg | achiang, Because it would suck on the desktop | 15:24 |
| victorp_ | tedg - it shouldnt suck anywhere | 15:24 |
| victorp_ | even on a 512MB phone | 15:25 |
| achiang | tedg: i don't think that logically follows. if the system API is written well, then let the *system* figure out how to let apps behave differently (either on mobile or desktop) | 15:25 |
| achiang | but *apps* don't get that privilege | 15:25 |
| achiang | that leads to the Android mess | 15:25 |
| tedg | achiang, Yes, but we need to be able to support the desktop use cases, which allow for background running of the apps. So you want to be able to have YouTube running unfocused. | 15:26 |
| tedg | That isn't directly related, but we need to do both. | 15:26 |
| achiang | tedg: the platform API should be aware of form factor | 15:26 |
| seb128 | achiang, want to join the hangout? | 15:26 |
| achiang | seb128: sure | 15:27 |
| dbarth | lool: if the shell identifies clearly the focused app, then you can guide the kernel to be a lot more aggressive about swapping out apps | 15:27 |
| tedg | achiang, Sure, but we shouldn't require the app to be aware of it (well, at this level) | 15:27 |
| dbarth | lool: and for background activities, you can define things a lot more specifically; again to guide the kernel to swap out everything that is not registered with those background apps | 15:27 |
| mfisch | you can solve the memory worries by making the lifecycle firm that suspended apps can be killed without warning | 15:28 |
| dbarth | +1 | 15:28 |
| mfisch | apps going into suspend should clean up in case they never get resumed | 15:28 |
| lool | dbarth: I think we're covering swap right now indeed | 15:29 |
| joe-uds | what metrics will you use to measure resource usage? Or, in other words, which resources are your highest priority; memory, power? | 15:29 |
| victorp_ | tedg doesnt that means that app can dump anything there and blow out the disk space? | 15:31 |
| bfiller_ | tedg: apps can do that now | 15:31 |
| mfisch | does android limit how much space the apps have to store local state? | 15:31 |
| dbarth | victorp_: we should expect the app manifest and container to constraint that | 15:32 |
| victorp_ | dbarth: ack | 15:32 |
| dbarth | greedy apps being prevented from installing / running if the system doesn't have the resource budget | 15:32 |
| victorp_ | well we should stop them from running at all | 15:33 |
| tedg | Yeah, we will have to limit caches for apps in general. | 15:33 |
| mfisch | dbarth: does the system prevent them from running? | 15:33 |
| mfisch | what if I have a device where I only want to run one app, but it's resource intensive? | 15:33 |
| dbarth | i don't know ;) tvoss? | 15:33 |
| victorp_ | tedg - but the system should be the one doing that for the app | 15:33 |
| mfisch | I think in Android, apps that use too much memory or disk are policed by users complaining about them | 15:33 |
| mfisch | I just installed an android game that used 1.8G of disk | 15:34 |
| rsalveti | the system will not block any apps | 15:34 |
| rsalveti | it'll just kill them if needed | 15:34 |
| awe_ | ChickenCutlass, ask rsalveti about firefox | 15:34 |
| mfisch | rsalveti: right | 15:34 |
| dbarth | ChickenCutlass: :D | 15:35 |
| victorp_ | rsalveti, so if the hoggin app is the first one launched what happens to the next app that ones to run | 15:35 |
| bfiller_ | desktop is just another policy, done | 15:35 |
| victorp_ | QUESTION: tvoss, will we have application budgets depeding on the system for memory and other things? | 15:35 |
| rsalveti | victorp_: once the hogging app is in background, the system will probably kill it | 15:35 |
| victorp_ | rsalveti: I dont hink we should allow that app even to start | 15:36 |
| rsalveti | it's just hard to guess that before actually running the app | 15:36 |
| rsalveti | we could have similar solution as low memory killer, or using cgroup to limit the application (cpu and memory wise) | 15:36 |
| victorp_ | rsalveti: I agree,, I gues I am saying regardless if the space is available | 15:37 |
| rsalveti | but trying to guess and request the app to tell how much it'd use, doesn't seems too safe | 15:37 |
| victorp_ | you will have to run it to start with | 15:37 |
| rsalveti | right | 15:37 |
| kyleN | can't it be phone AND desktop? (docked) | 15:38 |
| victorp_ | achiang - not sure how the manual process with apple is more about design | 15:38 |
| victorp_ | kyleN yeap | 15:39 |
| achiang | victorp_: they audit for API abuse | 15:39 |
| awe_ | ChickenCutlass, but it's how the platform API allows an application to do these things | 15:39 |
| mfisch | win8 caps roaming app data (data that travels between devices and the cloud) at 100k | 15:40 |
| mfisch | 50x the suggested limit here | 15:40 |
| dbarth | kyleN: we could imagine that this extra desktop is a sort of specialized app, like U4A to Android | 15:41 |
| dbarth | with lxc or a cgroup to prevent the desktop to crush the phone resrouces | 15:41 |
| victorp_ | ondra: but if you make it a % and the total is bigger (e.g. memory) then the rule is device specific | 15:41 |
| dbarth | lool: can we have one to map the desktop / converged case with that model? | 15:43 |
| victorp_ | tvoss +! | 15:44 |
| victorp_ | +1 | 15:44 |
| === udsbotu changed the topic of #ubuntu-uds-client-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1303/client-1/ - http://ubottu.com/uds-logs/%23ubuntu-uds-client-1.log | ||
| dbarth | lool: which one do you call the follow-up session? the one on the update process? | 15:48 |
| lool | dbarth: No, a separate session later after vUDS | 15:49 |
| dbarth | achiang: they do a static audit for api calls afaik; but you can abuse that by crafting objc calls at runtime | 15:49 |
| dbarth | ok | 15:49 |
| === udsbotu changed the topic of #ubuntu-uds-client-1 to: Track: Client | Update process for Ubuntu phones | Url: http://summit.ubuntu.com/uds-1303/meeting/21605/foundations-1303-single-image-update/ | ||
| achiang | dbarth: interesting. surely that gets detected later though... i mean sooner or later, the apple police find you ;) | 15:50 |
| dbarth | yeah, they run faster than you'd think | 15:52 |
| stgraber | seb128: can you send me the link to this hangout? (assuming you're the one running it) | 15:58 |
| stgraber | seb128: nevermind, summit just gave it to me now | 15:59 |
| seb128 | stgraber, ok | 15:59 |
| achiang | seb128: both ondra and i would like to be part of it too, please | 16:00 |
| * ogra_ waves | 16:00 | |
| seb128 | achiang, gave you the link | 16:01 |
| mfisch | the french speakers are taking over! | 16:01 |
| seb128 | ogra_, want to join the hangout? | 16:01 |
| achiang | seb128: thanks | 16:01 |
| vibhav | seb128: me too! | 16:02 |
| ogra_ | seb128, yup | 16:02 |
| swaveck | QUESTION: will "Mir" be updated automatically to current Ubuntu phone OS ? | 16:02 |
| lool | ChickenCutlass: here | 16:02 |
| seb128 | swaveck, wrong session? | 16:02 |
| seb128 | swaveck, we do " Update process for Ubuntu phones, tablets " | 16:02 |
| rsalveti | swaveck: not automatic from our current images I'd say | 16:02 |
| cjohnston | please | 16:02 |
| rsalveti | as we still need to do some more work at the android side of the image | 16:03 |
| rsalveti | as ubuntu can't update the android part atm | 16:03 |
| swaveck | thx, that's all I wanted to know | 16:03 |
| ogra_ | seb128, ? | 16:03 |
| seb128 | ogra_, I was wondering if you wanted to join the hangout | 16:03 |
| seb128 | ups | 16:04 |
| ogra_ | seb128, and i said yes :) | 16:04 |
| mfisch | Except carriers won't be controlling the desktop like they will phoens | 16:04 |
| seb128 | ogra_, sorry, overlooked that | 16:04 |
| vibhav | seb128: You forgot me too :) | 16:05 |
| * slangasek waves | 16:05 | |
| sebsebseb | hi | 16:05 |
| vibhav | slangasek: hey | 16:05 |
| slangasek | sorry, I seem to be unable to join a hangout while I'm also running camera for another one, so I'll be IRC only | 16:05 |
| seb128 | vibhav, cf query | 16:05 |
| seb128 | slangasek, ok | 16:05 |
| selena2013 | greetings from Miami | 16:06 |
| sebsebseb | selena2013: you followed me :d | 16:07 |
| cjwatson | rsalveti: apt-clone | 16:07 |
| pitti_ | tedg: how is the "factory" and "current" image different? | 16:07 |
| cjwatson | (Package manifest + delta) | 16:07 |
| tedg | pitti_, The current could have updates. factory + 1 | 16:07 |
| pitti_ | tedg: I assume we have some kind of overlay anyway where packages can install themselves in? | 16:07 |
| ogra_ | cjwatson, join the hangout :) | 16:07 |
| cjwatson | Need a break from being on camera :) | 16:08 |
| ogra_ | heh | 16:08 |
| gema_ | cjwatson: keep the camera off | 16:08 |
| xnox | it's full as well isn't it? | 16:08 |
| pitti_ | tedg: ah, I thought we'd just create new images every month or so, and people download/install those | 16:08 |
| slangasek | no | 16:08 |
| cjwatson | Actually I forget to just what extent apt-clone shows a delta; it may only be for files modified in any given package | 16:08 |
| mfisch | I dont think carriers will let you do monthly updates | 16:08 |
| mfisch | too much testing for them | 16:08 |
| xnox | You cannot rebase overlays effectively onto new image. | 16:08 |
| mfisch | in the US anyway the carries have a lot of power | 16:08 |
| rsalveti | cjohnston: sure, but that's not necessarily something we use by default | 16:08 |
| pitti_ | well, whichever cycle is appropriate | 16:09 |
| rsalveti | cjohnston: sorry | 16:09 |
| gema_ | mfisch: carriers would decide what they update, I think | 16:09 |
| rsalveti | cjwatson: ^ :-) | 16:09 |
| ogra_ | use nilfs2 :) | 16:09 |
| mfisch | gema_: right | 16:09 |
| cjwatson | rsalveti: We include it in some bug reports today | 16:09 |
| seb128 | lool, do you know if somebody is taking notes? | 16:09 |
| gema_ | mfisch: so it's up to them, not us | 16:09 |
| mfisch | most android phones now seem to get 0 or 1 updates | 16:09 |
| cjohnston | seb128: notes are being taken in the pad | 16:09 |
| mfisch | over the whole life of the product | 16:09 |
| pitti_ | stgraber: why would it be COW, if we only update once a month? | 16:09 |
| rsalveti | cjwatson: right, cool | 16:09 |
| slangasek | so one of the notes in the etherpad is "let's ignore apps for now" | 16:09 |
| cjwatson | And could certainly include it in more | 16:09 |
| pitti_ | stgraber: I thought more like "OS" == image, "apps" -> overlay? | 16:09 |
| gema_ | mfisch: I keep getting new versions of android every couple of months on my galaxy sIII | 16:09 |
| seb128 | cjohnston, by who? | 16:09 |
| cjohnston | seb128: I see a couple of colors, I don't know who | 16:10 |
| mfisch | gema_: my droid razr max is still 4.1 | 16:10 |
| slangasek | we can't ignore the problem of /var/lib/dpkg vis-à-vis full-image updates | 16:10 |
| mfisch | gema_: some phones update more often than others, usually the flagship ones | 16:10 |
| seb128 | cjohnston, that doesn't mean somebody is assigned to take note or while assure everything is recorded | 16:10 |
| gema_ | mfisch: right | 16:10 |
| cjwatson | slangasek: I think that was regarding sandboxing of apps | 16:10 |
| cjwatson | And suchlike | 16:10 |
| slangasek | cjwatson: yes, and some people are handwaving everything into the category of "apps" | 16:10 |
| slangasek | and we need to not do that | 16:10 |
| cjwatson | Granted | 16:10 |
| slangasek | there are three features we want here, and AFAICS we can only have two | 16:11 |
| slangasek | - ability to use apt | 16:11 |
| ogra_ | slangasek, i think they talk about the android rootfs | 16:11 |
| ogra_ | vs ubuntu userspace | 16:11 |
| slangasek | - ability to do system image updates | 16:11 |
| lool | seb128: there are some notes being taken in the pad at least | 16:11 |
| lool | seb128: I'm taking some too | 16:11 |
| seb128 | me too | 16:11 |
| lool | done so in most sessions today | 16:11 |
| seb128 | lool, let's assume we will manage to cover | 16:11 |
| lool | :-) | 16:11 |
| slangasek | ogra_: ok, I don't know why they're talking about an android rootfs, that wasn't what this session was set up for :) | 16:11 |
| Wellark | QUESTION: for factory reset, would it be possible to use the flashing tools to do that? we would have a tool which has a simple button "Reset to Factory State" and the tool would simply reflash the phone with fresh image effectively doing factory reset. Naturally this would require the device vendor to provide their factory images for public | 16:11 |
| slangasek | 3) avoiding the overhead of overlay | 16:12 |
| ogra_ | slangasek, the subtitle says "For phones and tablets, it doesn't necessarily make sense to use apt to update the OS; a full-OS update may make more sense ..." | 16:12 |
| slangasek | ogra_: yes, "the OS" isn't an *android* rootfs | 16:12 |
| ogra_ | its part of it | 16:12 |
| pitti_ | that's what I assumed -- we wouldn't use apt for the "base OS" | 16:12 |
| cjwatson | You can do all three if you required apps to live in a separated filesystem segment and used different apt and dpkg dbs. I'm not saying we'd want to but it's possible | 16:12 |
| ogra_ | right | 16:12 |
| ogra_ | unless you port it to android :) | 16:13 |
| slangasek | ogra_: could you please steer the discussion in this direction? | 16:13 |
| cjwatson | (Admittedly with some constraints enforced outside apt/dpkg) | 16:13 |
| pitti_ | if we do want to use apt, I retract my proposal of an overlay, of course | 16:13 |
| mfisch | this is an important point | 16:13 |
| slangasek | because it seems folks are not paying attention to IRC | 16:13 |
| mfisch | we're used to being in control of updates... | 16:13 |
| rsalveti | Wellark: but we'd need to store the factory image somehow | 16:13 |
| cjwatson | pitti_: I think it's a mistake to discard apt from the design, given that we need to converge things on the desktop too | 16:13 |
| slangasek | eh, oh; is ogra on the video either? | 16:13 |
| slangasek | (seems not) | 16:13 |
| Laney | he is | 16:13 |
| mfisch | and operater gets to add their crapware | 16:13 |
| seb128 | he is | 16:13 |
| ogra_ | i am | 16:13 |
| rsalveti | otherwise the user would need to download it, which is bad, as usually you want factory reset when something really bad happened | 16:13 |
| cjwatson | Our remit is not simply to design something that works *only* for carrier-mediated systems | 16:13 |
| slangasek | ah, there you are | 16:13 |
| ogra_ | but i dont want to interrupt the monologue | 16:13 |
| slangasek | silly tiny videos | 16:13 |
| ogra_ | german flag :) | 16:14 |
| pitti_ | cjwatson: *nod*; so we should rather focus on making apt more efficient (delta debs, etc.) than rolling out full new OS images for upgrades? | 16:14 |
| gema_ | I don't think an apt model would work with phones / tablets due to the lack of control operators/carriers would have | 16:14 |
| cjwatson | I'm not arguing against the system-image-update model | 16:14 |
| Wellark | rsalveti: they can be downloaded. for example Nokia does provide firmware images for all their mobile phones over Internet and the service centers simply download those images when the consumer brings a device for reflash | 16:14 |
| cjwatson | I'm just saying we should design such that it's something we can build without discarding apt on systems where it's usable | 16:15 |
| cjwatson | IYSWIM | 16:15 |
| seb128 | slangasek, what points do you want to be made/in which direction want to move the direction? | 16:15 |
| rsalveti | Wellark: right, but then it's a full flash/full factory reset | 16:15 |
| pmcgowan | app update model is different, just not relevant here | 16:15 |
| rsalveti | Wellark: but the phone still provide a way for the user for the system to go back to factory reset | 16:15 |
| Wellark | well, they were talkig about factory reset before | 16:15 |
| rsalveti | without erasing everything for all partitions, for example | 16:15 |
| ogra_ | pmcgowan, its the same package database | 16:15 |
| cjwatson | Well | 16:15 |
| cjwatson | Today | 16:15 |
| pmcgowan | would not assume that | 16:15 |
| === isantop_ is now known as isantop | ||
| ogra_ | pmcgowan, unless there was something defined which isnt discussed at UDS | 16:16 |
| gema_ | why don't we store the factory image on a partition on the device to be able to restore? | 16:16 |
| rsalveti | Wellark: guess we're talking about 2 models for factory reset here | 16:16 |
| cjwatson | In order to do system image updates, it kind of has to be a separate db | 16:16 |
| ogra_ | cjwatson, right | 16:16 |
| pmcgowan | ogra_: not discussed yet, needs more work | 16:16 |
| slangasek | seb128: the problem that needs to be solved is how we can update the Ubuntu image without trashing any packages the user has installed | 16:16 |
| rsalveti | one is one way the user could trigger at the device, and the other for a full clean flash | 16:16 |
| slangasek | maybe we solve this by not allowing users to install any apps | 16:16 |
| slangasek | s/apps/packages/ | 16:16 |
| slangasek | but then it's not very Ubuntu :) | 16:16 |
| seb128 | tedg, ^ what slangasek said | 16:16 |
| pitti_ | cjwatson: we could perhaps install "core os" dpkgs into the "core os" partition, and everything else into the apps overlay, so that you can use apt and new OS images at any time without duplicating the disk space? | 16:17 |
| vibhav | 21:46 < pmcgowan> ogra_: not discussed yet, needs more work | 16:17 |
| slangasek | well | 16:17 |
| cjwatson | pitti_: that general principle | 16:17 |
| vibhav | oops, sorry for the wrong hilight | 16:17 |
| cjwatson | Ish | 16:17 |
| ogra_ | vibhav, yes, pings highlight for me on IRC | 16:17 |
| slangasek | lool: but it's not "apps", it's *packages* that are the existing Ubuntu system | 16:17 |
| vibhav | highlight, even | 16:17 |
| dbarth | slangasek: the tools for ubuntu, the OS "toolkit" for developers, and ubuntu, the OS on end-user devices, may have different OS installer / updaters? | 16:17 |
| pitti_ | that's very similar to "daily dist-upgrade" vs. "daily ISOs" in fact | 16:17 |
| slangasek | and there's no separation between the base system and "packages" today | 16:17 |
| cjwatson | I do think we should finish off the debdelta work, but I don't think it's desperately related to this ... | 16:18 |
| dbarth | with apt/dpkg still being what's used to construct images for client runtimes sans apt | 16:18 |
| xnox | slangasek: sure, but the system os can ship fake equivs that provides everything that one gets from the base image, and then in apt world those will exist normally. | 16:18 |
| pmcgowan | dbarth: right thats a possible model | 16:18 |
| seb128 | slangasek, seems like the "investigate" are about looking at replacing the apt/packaging model | 16:19 |
| slangasek | dbarth: "may" have doesn't really address the design | 16:19 |
| cjwatson | Who is talking? Sorry, no lower-third there | 16:19 |
| lool | slangasek: I don't understand the distinction between apps and packages point | 16:19 |
| slangasek | which is what we should be using this session for | 16:19 |
| lool | slangasek: I'm saying that we need a separation no matter what technology we pick | 16:19 |
| lool | including if we use .debs | 16:19 |
| dbarth | slangasek: make 'may' into a strict negation; a you have a clear cut design ;) | 16:20 |
| lool | we will want some kind of user side root for his .debs separate from the system one | 16:20 |
| slangasek | lool: so that needs to be designed | 16:20 |
| lool | yes | 16:20 |
| lool | but no matter how we design user installed apps, we will want a way to deploy factory system images and updates to system image | 16:21 |
| seb128 | slangasek, ok, back on topic ;-) | 16:21 |
| ev | is dpkg really appropriate for a mobile platform? It's not atomic, for a start. | 16:21 |
| asb_b_b | has anyone analysed what maemo did? | 16:21 |
| ogra_ | :) | 16:21 |
| pgraner | ChickenCutlass, +100 | 16:21 |
| barry | yes, but what are the requirements for phone app updates that are not (or can't be) fulfilled by apt? | 16:21 |
| slangasek | ChickenCutlass: it's not too many people, it's I'm in another hangout and I can't be in two simultaneously | 16:21 |
| xnox | Laney: jump off =) | 16:21 |
| ChickenCutlass | slangasek: ok | 16:22 |
| asb_b_b | meamo was also deb-based for app installs at least (not sure about system updates) | 16:22 |
| seb128 | slangasek, use a second account :p | 16:22 |
| Laney | it's not full | 16:22 |
| slangasek | seb128: I did, it doesn't help | 16:22 |
| seb128 | slangasek, weird | 16:22 |
| sebsebseb | Yes good point there, a phone must just work, like a microwave! | 16:22 |
| rsalveti | asb_b_b: and it's slow as hell :-) | 16:22 |
| gema_ | tedg: but you don't have the same amount of HW diversity on phones, as you'd have on desktops | 16:22 |
| sebsebseb | consumers won't fix stuff etc | 16:22 |
| stgraber | slangasek: we can probably invite your landline, that should work | 16:22 |
| xnox | Laney: i see 10 faces.... =) | 16:22 |
| ogra_ | tedg, we just need to use a proper filesystem that supports snapshotting :) | 16:22 |
| rsalveti | as dpkg/apt consumes a *lot* of io | 16:22 |
| asb_b_b | rsalveti: this is true :) | 16:22 |
| ev | I realise we have a lot tied to it already, but its problems are fairly large to carry to an entirely new platform. | 16:22 |
| slangasek | stgraber: oh, good point | 16:22 |
| tedg | ogra_, Yeah, FS snapshotting is a good answer | 16:22 |
| Laney | 11 | 16:22 |
| stgraber | seb128: ^ can you invite slangasek's phone? | 16:22 |
| cjwatson | apt-get update> could be considerably improved by pdiffs | 16:22 |
| * ogra_ points to nilfs2 | 16:22 | |
| xnox | ogra_: filesystems that support snapshot do not support rebasing onto new snapshot. | 16:22 |
| ogra_ | xnox, well, for now we only want rollback | 16:23 |
| xnox | ogra_: no. we want to upgrade to new snapshot. =)))) | 16:23 |
| mzanetti | Maemo was using apt. They at least seem to have solved the factory reset issue with it. Probably worth to have a look at. | 16:23 |
| ogra_ | xnox, as i understood we want to be able to roll back if an upgrade fails | 16:23 |
| ogra_ | xnox, since you cant fix it on a phone/tablet | 16:24 |
| ssweeny | maemo updating was really slow | 16:24 |
| ev | achiang: it also is built around a model where the applications share a filesystem namespace - presumably not the case here? | 16:24 |
| asb_b_b | cjwatson: I've found pdiff to be pretty cpu intensive | 16:24 |
| cjwatson | cpu/bandwidth tradeoff, true | 16:24 |
| seb128 | stgraber, slangasek: how do I do that? the invite doesn't take phone numbers? | 16:24 |
| ogra_ | xnox, though rolling forward to new snapshots woudl be cool :) | 16:24 |
| cjwatson | pitti_: well, there's eatmydata et al | 16:24 |
| achiang | ev: well it is the case today still (as we know), and we just don't know how to get from where we are today to the future | 16:24 |
| tumbleweed | pdiffs also require significantnly more requests, if you are several pdiffs behind | 16:24 |
| cjwatson | I have some background concerns about the reliability of LVM snapshotting ... | 16:25 |
| slangasek | seb128: perhaps on-air doesn't allow phones | 16:25 |
| xnox | tedg: sure, but it doesn't help to rebase onto new snapshot. | 16:25 |
| isantop | What Filesystem is being used on the UTDP right now? | 16:25 |
| seb128 | sorry | 16:25 |
| Wellark | the feed died! | 16:25 |
| tsdgeos_uds | errr | 16:25 |
| asb_b_b | arrrghhh, hangout is dead | 16:25 |
| cjwatson | I've seen the odd mysterious problem with snapshots failing to remove in some undebuggable way | 16:25 |
| jdstrand | bummer | 16:25 |
| tsdgeos_uds | what happened? | 16:25 |
| achiang | we are still here in the hangout | 16:25 |
| kyleN | hangout died | 16:25 |
| slangasek | seb128: wrong button ;-) | 16:25 |
| xnox | hangout died. | 16:25 |
| victorp_ | ooooops | 16:26 |
| cgregan_ | refresh the page usually fixes it | 16:26 |
| xnox | the host has quick! | 16:26 |
| pgraner | yep hangout is dead | 16:26 |
| cgregan_ | yay | 16:26 |
| kyleN | ok, youtube stream died | 16:26 |
| xnox | the host has quit! | 16:26 |
| kyleN | back | 16:26 |
| asb_b_b | aaaand we're back | 16:26 |
| tsdgeos_uds | it's back! | 16:26 |
| cgregan_ | back | 16:26 |
| seb128 | sorry, wrong click | 16:26 |
| Saviq|UDS | ^^^ most useful IRC conversation _ever_:D | 16:26 |
| seb128 | slangasek, yeah, seems hangout (or google.fr) doesn't allow it | 16:26 |
| ev | tedg, pitti_, others: would this not be solvable with a extremely simple package management system (just a zip, as achiang mentioned other platforms use) and filesystem namespace separated software? | 16:26 |
| dbarth | seb128: hands off the keyboard | 16:26 |
| slangasek | seb128: hangout allows it, but I checked here and I also don't have the to-POTS option for an on-air hangout. Probably because someone being called has no option to accept the broadcast agreement | 16:27 |
| xnox | ogra_: we do want to keep / /usr to be readonly. | 16:27 |
| cjwatson | ev: we'd want to assemble the former from debs - redesigning our entire build process as well as designing the deployment process doesn't seem like a sensible use of resources | 16:27 |
| kyleN | define a "system" | 16:27 |
| seb128 | slangasek, oh, works now | 16:27 |
| seb128 | slangasek, just did it | 16:27 |
| slangasek | seb128: oh | 16:27 |
| seb128 | bah | 16:27 |
| seb128 | no | 16:27 |
| pitti_ | ev: yes, or even just two separate partitions for dpkg (this needs untangling /var/lib/dpkg/info, though) | 16:27 |
| seb128 | I've a 0€ credit | 16:27 |
| * achiang would like to get a clear sense of the requirements and then solve backwards from there | 16:27 | |
| slangasek | ev: that doesn't help us with any of the existing packages that users may want to install | 16:27 |
| seb128 | they want money for it | 16:27 |
| xnox | kyleN: ubuntu-minimal. | 16:27 |
| ev | cjwatson: do we actually need it? All the software in the archive isn't going to run on this thing. It's an opportunity to make a clear break from a system that's built for an entirely different structure. | 16:27 |
| slangasek | we have three choices here | 16:27 |
| slangasek | - don't support full-image updates | 16:27 |
| stgraber | seb128: US/Canada numbers are free | 16:27 |
| slangasek | - don't support apt | 16:28 |
| slangasek | - implement splitting the base OS from other packages on disk | 16:28 |
| seb128 | stgraber, slangasek: well, I added the number in there, not sure if that worked | 16:28 |
| cjwatson | ev: The packages that go to make up the images are ones that we want to converge onto the desktop in due time, and we're going to want to build them as part of Ubuntu | 16:28 |
| slangasek | and so far, I think we're talking in circles around this issue | 16:28 |
| cjwatson | ev: It's not necessary to make a "clear break" for the build side of things | 16:28 |
| cjwatson | Deployment, sure | 16:28 |
| seb128 | slangasek, got it? | 16:28 |
| cjohnston | slangasek: do you have a personal account you could join with? | 16:29 |
| tedg | slangasek, I think that the splitting is orthogonal | 16:29 |
| slangasek | seb128: incoming | 16:29 |
| lool | who is it on the phone? | 16:29 |
| barry | to have a credible convergence story, the same mechanisms must work on both the phone and desktop, otherwise you've got the linux version of os x and ios | 16:29 |
| lool | is it Steve? | 16:29 |
| tedg | slangasek, We could split and even have different policies on each. | 16:29 |
| ev | cjwatson: so take a deb and turn it into something that requires no client-side processing (on the server, of course) | 16:29 |
| ev | ? | 16:29 |
| cjwatson | ev: well, it's basically an image build isn't it | 16:29 |
| ev | yeah | 16:29 |
| cjwatson | ev: as you say except s/a deb/a pile of debs/ | 16:29 |
| * ev nods | 16:30 | |
| xnox | cjwatson: sure, it's just like we don't need locally all the descriptions of all the apps - one can fetch it over the network if one wants new packages. | 16:30 |
| slangasek | tedg: that's option 3, and currently we don't have it and there's no convergence on it, just handwaving | 16:30 |
| slangasek | this is a completely separate question from third-party packages | 16:30 |
| seb128 | slangasek, did you try talking? didn't hear you yet | 16:31 |
| TheMuso | I can hear phone activity... | 16:31 |
| seb128 | slangasek, \o/ | 16:31 |
| TheMuso | Or what sounds like something coming over a phone line. | 16:31 |
| tedg | What if we have a package that represents "the image". Basically something that hardcodes to the version of packages to a set of specific versions. | 16:32 |
| tedg | If you change anything, you have to drop that package. | 16:33 |
| tedg | If you have one, then we can download a zip that has debs to go to a different version. | 16:33 |
| tedg | So we get a zip of debs. | 16:33 |
| gema_ | TheMuso: there is an echo on the video indeed | 16:34 |
| cjwatson | Tying this to a developer mode sounds very sensible | 16:34 |
| dbarth | chromeos does that, without packaging system though | 16:34 |
| xnox | rsalveti: cjwatson: but that doesn't sound like convergence to me. | 16:34 |
| ogra_ | we plan to offer a terminal app ... | 16:34 |
| ogra_ | that means we give console access to users (kind of) | 16:34 |
| pmcgowan | the operators will somewhat dictate what happens for a normal production system | 16:34 |
| xnox | "sources" | 16:35 |
| xnox | I want to do image updates from month-to-month on the desktop. | 16:36 |
| xnox | I want my desktop & cloud do that as well. | 16:36 |
| xnox | and do that in fast-path mode as well for cloud nodes for example. | 16:36 |
| ogra_ | i want my phone to do desktop and cloud ! | 16:36 |
| ogra_ | in a converged world :) | 16:36 |
| xnox | this is not _just_ for the phone | 16:36 |
| ev | is the suggestion being made that we use apt/dpkg for all applications on this system, or just legacy applications from the ubuntu archive? | 16:37 |
| dbarth | ogra_: your desktop could be an app, with a container hosting the regular apps and packages | 16:37 |
| dbarth | like U4A, but for Ubuntu | 16:37 |
| ogra_ | dbarth, yes, but i want to be able to acces the phone app and its data from my desktop app for example | 16:37 |
| ogra_ | thats what i understand under convergence | 16:38 |
| xnox | dbarth: interesting, as long as we can snapshot on top of base image. | 16:38 |
| pmcgowan | you want one app actually | 16:38 |
| dbarth | ogra_: that's an IPC, dbus or sometihng similar | 16:38 |
| ogra_ | pmcgowan, if i use a different better desktop suited app (gimp) i still want to access the phone data | 16:38 |
| ogra_ | which i created with a phione app | 16:38 |
| xnox | "sanity check" | 16:39 |
| ogra_ | (touch-gimp) | 16:39 |
| dbarth | ogra_: you use a mount bind, like with lxc | 16:39 |
| ogra_ | dbarth, my MOM wont be able to :) | 16:39 |
| dbarth | ogra_: make another app for her to do that | 16:39 |
| ogra_ | she docks the phone and expects to access the same data and having the apps available | 16:40 |
| ev | lool: ++; | 16:40 |
| ogra_ | and to be able to use more powerful apps on the same data | 16:40 |
| dbarth | or do it automatically on a known shared directory | 16:40 |
| dbarth | exchange zone | 16:40 |
| cjwatson | Having user apps live in a separate (maybe sandboxed) apt/dpkg database would have the effect of making apt's handling of those very much faster; but again isn't necessarily a converged approach | 16:40 |
| ogra_ | thats not what i woudl call convergence | 16:40 |
| bfiller_ | another firm requirement is installing new apps on phablet from Ubuntu Software Center | 16:42 |
| dbarth | we're just defining what convergence will mean for various compartments of the product | 16:42 |
| cjwatson | achiang: To what extent is this required to be handled by package management on the device, as opposed to by static checking on the archive side? | 16:42 |
| lool | why would we have the source of things done in postinst? | 16:43 |
| achiang | cjwatson: i don't think it is a requirement to have it handled on the device | 16:43 |
| lool | we could still check binaries to see whether they attempt to do something | 16:43 |
| xnox | ogra_: slangasek: how would unionfs "rebase" onto new image? | 16:43 |
| lool | but it seems really hard | 16:43 |
| lool | I'd rather we design it in a way that apps don't have root when installing and are constrained to some file system hierarchy | 16:44 |
| cjwatson | achiang: Because we do have lots of well-understood and extensible tools for checking packages, so we could enforce whatever constraints we wanted on apps on the server side | 16:44 |
| cjwatson | e.g. no maintainer scripts except for vetted debhelper-produced fragments | 16:44 |
| slangasek | lool: we need to do that, but that's a separate question | 16:44 |
| cjwatson | (or no maintainer scripts at all if feasible) | 16:44 |
| slangasek | out of scope for this session | 16:44 |
| cjwatson | achiang: I'm asking this because I think that's lots easier and I'd like to use that possibility to trim the scope of the required client work | 16:45 |
| dbarth | cjwatson: +1 that will preserve the goodnes built into packages, without the runtime overhead | 16:45 |
| kyleN | base os = ubuntu-minimal + ubuntu-standard? | 16:45 |
| dbarth | less of an abrupt / risky change | 16:46 |
| cjwatson | well, standard's pretty small, but bikeshed | 16:46 |
| barry | look at ios. base system updates are very heavyweight. updating apps are lighterweight and happen all the time | 16:46 |
| achiang | cjwatson: ah, i see your point now. thanks | 16:46 |
| bfiller_ | how does android handle all of this? can that be a model for us then adapted | 16:46 |
| lool | base OS would include display server and unity | 16:46 |
| ogra_ | bfiller_, android isnt converged :) | 16:46 |
| lool | bfiller_: android doesn't try to support 10000 apt-get installable packages | 16:46 |
| lool | which is what people want to do here | 16:47 |
| lool | I dont personally agree that's a goal for phone images | 16:47 |
| ogra_ | the prob isnt to find a way to upgrade phones and tablets, it is how to not trash the convergence :) | 16:47 |
| lool | I don't think we want apt-get install on the phone | 16:47 |
| seb128 | lool, it's not the goal for the phone image | 16:47 |
| seb128 | it's the goal for the convergent desktop to still have the option to use Ubuntu packages | 16:47 |
| cjwatson | tedg: I'd like to encapsulate as much as possible in debhelper fragments | 16:47 |
| lool | Yes | 16:47 |
| cjwatson | We're quite a long way there already | 16:47 |
| Wellark | lool: the phone can be docked and you get a standard desktop | 16:47 |
| seb128 | lool, otherwise our "convergent 14.04 LTS" will have none of Ubuntu | 16:47 |
| seb128 | e.g no libreoffice | 16:47 |
| tedg | cjwatson, Yeah, I was thinking just having a different divert helper for base vs. non-base. | 16:47 |
| cjwatson | tedg: Because then we can do static checking without having to add a lot more code to the core package manager | 16:47 |
| pitti_ | lool: but our goals is not to do a "phone" OS, but something that works everywhere, so dropping apt-get install support ins't really an option IMHO | 16:48 |
| tedg | cjwatson, Yeah, I'm just worried about things we, for instance, sync from debian that might not be checked. | 16:48 |
| lool | I actually believe our model is flawed to scale to support more apps | 16:48 |
| dbarth | guys, use lxc and put your converged desktop in it; you won't have to migrate all of your packages for 14.04; just the ones criticil to the phone os | 16:48 |
| bfiller_ | ogra_, lool : so maybe we need to think about adapting what we have | 16:48 |
| tedg | cjwatson, Or if someone sets up a debian repo in their search path. | 16:48 |
| cjwatson | tedg: Well, if the testing is manual that's kind of a failure :) | 16:48 |
| seb128 | lool, nobody wants to scale it | 16:48 |
| cjwatson | tedg: If they do that surely they own the problem | 16:48 |
| seb128 | lool, I think what is wanted is to keep compat support for it to not loose the Ubuntu archive | 16:49 |
| tedg | cjwatson, Heh, yes. But a PPA is probably more typical. | 16:49 |
| lool | I am open that we keep a way to have extra APT-installed apps in this or that chroot somewhere, but eventually moving to some new app format | 16:49 |
| ogra_ | bfiller_, we need to design it right from the ground up ... or invent an interim solution we'll throw away once real convergence happens | 16:49 |
| seb128 | lool, +1 | 16:49 |
| lool | (whether the new format is implemented with .deb or not doesn't matter) | 16:49 |
| seb128 | lool, right, new format is an orthogonal discussion | 16:49 |
| cjwatson | ChickenCutlass: this is not quite as fixed as it looks | 16:49 |
| lool | but I don't want the transitional requirements to affect our base design | 16:49 |
| jdstrand | fyi, currenly the application isolation work will use a dh script to put stuff in /etc | 16:50 |
| cjwatson | ChickenCutlass: separate dpkg database for apps + path filtering (which exists in dpkg) | 16:50 |
| awe_ | If you need an additional lib for an Android app, it goes to the app's sandbox... it's cannot be leveraged by other apps | 16:50 |
| xnox | pitti_: but we can wrap dpkg with dpkg-filter to trim all the locations we don't like. | 16:50 |
| ChickenCutlass | cjwatson: ok great | 16:50 |
| barry | couldn't that be somewhat mitigated by better pre-processing and imposition of rules on debs? | 16:50 |
| jdstrand | it doesn't strictly *have* to be etc, but worth noting | 16:50 |
| mzanetti | Nokia had a check for every deb package ending up in the store that it only installs stuff to /opt/ except the .desktop file and icon | 16:50 |
| lool | slangasek: Sorry, I dont feel able to followup on the overlay question | 16:50 |
| cjwatson | man dpkg and grep for --path-exclude and --path-include | 16:50 |
| lool | I am happy to follow the discussion though | 16:50 |
| cjwatson | For the basic facility that you could use | 16:51 |
| pitti_ | xnox: well, we don't want to just cut out random files from ubuntu archive packages | 16:51 |
| asb_b_b | anyone looked at Valeries Aurora's union mounts? | 16:51 |
| greyback | QUESTION: sorry I'm late, I missed stuff, have alternative package formats been considered? | 16:51 |
| cjwatson | It might be more sensible to use a container; I'm just saying there are possibilities | 16:51 |
| pitti_ | xnox: I think if we do any modification, they should apply to the "base OS" side, not to the "everything else" side | 16:51 |
| xnox | pitti_: cutting out /home sounds like a good idea across the board =) | 16:51 |
| ogra_ | greyback, nope | 16:51 |
| cjwatson | mzanetti: Yeah, that's exactly the kind of thing I'm suggesing | 16:51 |
| cjohnston | seb128: 4 minutes left fwiw | 16:51 |
| cjwatson | +T | 16:51 |
| seb128 | cjohnston, right | 16:51 |
| pitti_ | xnox: heh, yes :) | 16:51 |
| zebaszp | I did join a little late, but did rsync/zsync get mentioned at any point? just curious | 16:52 |
| pitti_ | xnox: there's certainly a white list of alllowed toplevel dirs (/etc/, /lib/, /var, /usr, etc.) | 16:52 |
| xnox | greyback: out of scope for this topic. | 16:52 |
| stgraber | cjwatson: oh nice, I didn't know that was there already, that should make things much easier | 16:52 |
| greyback | ogra_, xnox: why? Shouldn't we first decide if another package format is worth considering, before looking into solutions for the problems dpkg gives us? | 16:52 |
| ogra_ | greyback, apt and dpkg will always be used in your desktop ... i.e. if you dock the phone | 16:53 |
| Wellark | pitti_: we could define the packager guidelines which dictate what is OK and what is not. Then we would check all the packages in the repository against these rules | 16:53 |
| bfiller_ | lool: +1 on that, base image updates in single file, new apps that will be installed in new packaging format or restricted deb format | 16:53 |
| ogra_ | greyback, we need a proper plan that covers both cases | 16:53 |
| ogra_ | else its throw away work | 16:53 |
| pitti_ | Wellark: for the "new apps", sure; but not for all packages that are already in Ubuntu | 16:53 |
| bfiller_ | or something like that for a phase 1 | 16:53 |
| rsalveti | bfiller_: problem is when we look from the convergence pov | 16:53 |
| pitti_ | Wellark: we already do that for the extras.ubuntu.com appdev bits | 16:53 |
| dbarth | lool: you should list usecases to define the reqs | 16:54 |
| lool | dbarth: they are in the pad | 16:54 |
| zebaszp | I hate to repeat myself, but...I did join a little late, but did rsync/zsync get mentioned at any point? just curious | 16:54 |
| achiang | how does maemo/meego solve this problem? what is their app sandbox model? | 16:54 |
| greyback | ogra_: sure. But for me dpkg has disadvantages that are pretty major for a phablet | 16:54 |
| lool | dbarth: "requirements" in the pad | 16:54 |
| dbarth | lool: sorry, checking | 16:54 |
| ogra_ | bfiller_, that will do fine as an interim, but cant be the answer, so the question is how much will we invest in throw away work | 16:54 |
| Wellark | pitti_: well, if the rules are sane (like, don't install to /home) then there probably would not be that many problematic packages | 16:54 |
| achiang | zebaszp: not relevant to this discussion, imho | 16:54 |
| xnox | slangasek: pitti_: yes we do need for factory reset. | 16:54 |
| xnox | "full image" to flash. | 16:54 |
| achiang | zebaszp: or maybe it is relevant | 16:54 |
| ogra_ | greyback, but thats what we have atm | 16:54 |
| xnox | or when the delta between .1 and .5 is missing. | 16:54 |
| achiang | zebaszp: but we haven't talked about it yet ;) | 16:54 |
| zebaszp | achiang, it could be useful when it comes to downloading updates (or updated package lists) | 16:55 |
| zebaszp | I think arch does it with pacman? | 16:55 |
| greyback | ogra_: I know. I want to throw out new ideas. I seriously think dpkg is a poor choice for applications on a phablet, so I would like alternatives to be considered | 16:55 |
| xnox | pitti_: as long as the next system image has those security updates. | 16:55 |
| ev | woooooooooooo | 16:55 |
| zebaszp | well, it's knida late now the sessin is out of time, but I just thought I'd throw it out there :P | 16:55 |
| zebaszp | *session | 16:56 |
| === udsbotu changed the topic of #ubuntu-uds-client-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1303/client-1/ - http://ubottu.com/uds-logs/%23ubuntu-uds-client-1.log | ||
| xnox | ev: join us in Turing =) | 16:56 |
| xnox | ev: or are you not in bluefin?! | 16:56 |
| ev | xnox: is that where you are? | 16:56 |
| ev | okay | 16:56 |
| ev | I'm here | 16:56 |
| ev | on my way | 16:56 |
| ogra_ | greyback, but you still want convergence ... apps need to be usable in both, desktop and phone ... and data needs to be accessible for both, and you dont want a ton of different rootfses for each of the possible convergence cases | 16:56 |
| xnox | lool: yeah, like updates for usb-creator sticks with persistance enabled. | 16:56 |
| lool | yeah | 16:56 |
| greyback | ogra_: so perhaps we can innovate on the desktop :) | 16:56 |
| dbarth | lool: the pad thing is completely broken for me | 16:57 |
| xnox | slangasek: stgraber: me! | 16:57 |
| ogra_ | greyback, so apt has to stay, even if there grows a new format specifically for phone | 16:57 |
| jodh | slangasek: I'm interested! | 16:57 |
| lool | dbarth: open in a separate window, that works much better most of the time | 16:57 |
| xnox | slangasek: you have the usual three. | 16:57 |
| lool | you need to go through SSO on pad.u.c | 16:57 |
| slangasek | :-) | 16:57 |
| dbarth | lool: but i'd suggest listing the actions that users, image builders or the system (as the install procesS) can do | 16:57 |
| xnox | stgraber: ^ | 16:57 |
| greyback | ogra_: I know. apt is great for the lower level system, I'm fine with it. But for apps, something else could be good | 16:57 |
| kyleN | excellent. | 16:57 |
| dbarth | lool: and write down the steps for each case; the scope and reqs will appear more clearly | 16:57 |
| xnox | greyback: that will be discussed separately. | 16:58 |
| ogra_ | greyback, but that something doesnt exist yet | 16:58 |
| stgraber | xnox: ok, I added your name to the blueprint | 16:58 |
| ogra_ | greyback, we need to work from what we have right now and we need to cover the convergence in the plan | 16:58 |
| slangasek | xnox, jodh: yep, happy to have you guys working with stgraber on it - the question was more directed at the folks who were working on the phablet, because they probably have background on different pieces of this puzzle | 16:58 |
| slangasek | and we want to make sure we're getting their input | 16:58 |
| ogra_ | we will definitely grow that knowledge too with the move to raring | 16:59 |
| ogra_ | (we have to) | 16:59 |
| greyback | ogra_: right. Convergence can go both ways though. I just want to float the idea. | 16:59 |
| stgraber | slangasek: I'll write something down later this week/next and share with the foundations mailing-list + Alex and Loic, as pretty much all of foundations showed interest ;) | 16:59 |
| slangasek | stgraber: wasn't it ChickenCutlass I heard speak up, not achiang? | 17:00 |
| slangasek | (since I was audio only, I didn't see whose lips moved on the video :) | 17:00 |
| stgraber | slangasek: hmm, I thought it was achiang but I'm not completely sure. | 17:00 |
| stgraber | achiang, ChickenCutlass: ^ | 17:00 |
| achiang | stgraber: it was ChickenCutlass, but i'd like to be involved too | 17:01 |
| ogra_ | greyback, no disagreement that phone apps will have to be handled differently than your general desktop app :) | 17:01 |
| stgraber | achiang: ok | 17:01 |
| ogra_ | greyback, but we need to solve the basic probs first before looking into app space | 17:01 |
| greyback | ogra_: understood | 17:02 |
| ogra_ | else we need to redesign all that stuff in a year | 17:02 |
| MacSlow | hey hikiko | 17:22 |
| MacSlow | hikiko, do you know the link to the hangout for this session? Or anybody else? | 17:22 |
| Laney | D | 17:23 |
| Laney | oops | 17:23 |
| selena2013 | all sessions link are in your schedule page | 17:24 |
| * thomi waves | 18:03 | |
| TheMuso | Morning indeed. | 18:03 |
| TheMuso | Its too early for breakfast yet. :p | 18:04 |
| === udsbotu changed the topic of #ubuntu-uds-client-1 to: Track: Client | Unity ui converged for all form factors | Url: http://summit.ubuntu.com/uds-1303/meeting/21679/client-1303-unity-ui-converged/ | ||
| mhall119|uds | hello guys | 18:07 |
| mhall119|uds | yes, we can all see you :) | 18:08 |
| tsdgeos_uds | is the feed lagging for anyone else? | 18:08 |
| tsdgeos_uds | or is it just me? | 18:08 |
| Saviq | can't connect to the hangout at all :/ | 18:08 |
| mmrazik | tsdgeos_uds: its certainly for me | 18:08 |
| bschaefer | mine has stopped | 18:08 |
| mhall119|uds | did you guys stop the broadcast? | 18:08 |
| tsdgeos_uds | i guess tvoss wanted to say something not polite :D | 18:09 |
| TheMuso | Ok it wasn't just me then. | 18:09 |
| ogra_ | mhall119|uds, session starts at 15 past | 18:09 |
| Saviq | yay | 18:09 |
| * tsdgeos_uds goes grab some cookies | 18:09 | |
| TheMuso | Lookes like the hangout stopped. | 18:09 |
| krabador | yes | 18:09 |
| ogra_ | The it hasnt started | 18:09 |
| mhall119 | ogra_: ok, everybody will need to manually refresh the page once you put the new broadcast URL in the Summit form | 18:10 |
| j-johan-edwards | Seems a pretty immense topic for 45m... | 18:10 |
| tvoss | tsdgeos_uds, nope, I wanted to say that I appreciate the input | 18:10 |
| mhall119 | j-johan-edwards: this won't be the last of the conversations about it | 18:10 |
| tsdgeos_uds | tvoss: ok :-) | 18:10 |
| MacSlow | Saviq, where is the hangout link? | 18:13 |
| mhall119 | if you are marked as a "Required" participant, you will have to refresh to see the hangout link | 18:16 |
| tsdgeos_uds | are we there yet? | 18:16 |
| tsdgeos_uds | can't see the feed | 18:16 |
| mhall119 | tsdgeos_uds: you will when they turn on broadcast | 18:16 |
| tsdgeos_uds | "An error occurred" | 18:16 |
| mhall119 | unless you get an error, is what I meant :) | 18:16 |
| === netcurli_ is now known as netcurli | ||
| mhall119 | in which case, refresh | 18:16 |
| j-johan-edwards | okay, I see the hangout | 18:17 |
| Saviq | MacSlow, toolbox, no need for effects | 18:17 |
| seb128 | tsdgeos_uds, http://youtu.be/bp9Kh3WxJj0 should work? | 18:17 |
| tsdgeos_uds | ok, had to refresh the page | 18:18 |
| cgregan_ | dropped but back up | 18:19 |
| kgunn | https://blueprints.launchpad.net/ubuntu/+spec/client-1303-unity-ui-iteration-0 | 18:19 |
| kgunn | blueprint for unity next ui | 18:19 |
| seb128 | Saviq, muted you, you have some background noise | 18:20 |
| Saviq | seb128, sure, will do manual | 18:20 |
| guestman | Question: I tried to build phablet-mods branch. Is this the branch that is used for testing ? | 18:22 |
| Saviq | guestman, yes, there's a build script that _should_ get you somewhere, but we're fixing the build scripts as we speak | 18:23 |
| guestman | thanks Saviq | 18:24 |
| mhall119|uds | Saviq: can you repeat that on the video please? It'll help people watching later | 18:24 |
| Saviq | guestman, for now we need a custom build of (lib)unity | 18:24 |
| guestman | Question: will you all be porting dconf-qt like it was for unity 2d | 18:24 |
| guestman | qt5 ^^ | 18:24 |
| Saviq | mhall119|uds, yeah, will do, at least as part of summarizing the work items | 18:24 |
| quesh | didrocks: the name is Unity next or Unity next gen ? | 18:25 |
| mhall119|uds | for the record, I volunteered to publish the docs, not write them :) | 18:26 |
| guestman | Question: On that note will all the older stuff from unity 2d be ported so hat we can use all the libs from before ? | 18:26 |
| guestman | s|hat|that | 18:26 |
| isantop | Unity Next sounds cooler. | 18:26 |
| guestman | dee dconf-qt | 18:27 |
| Saviq | mhall119|uds, ;) | 18:27 |
| guestman | bamf | 18:27 |
| bschaefer | don't need bamf anymore, mir handles that | 18:28 |
| mhall119|uds | yay for application-aware display server! | 18:28 |
| bschaefer | \0/ | 18:28 |
| mhall119|uds | QUESTION: Do we have a list of what needs to be ported that we can provide to community hackers? | 18:28 |
| === mhr3__ is now known as mhr3 | ||
| guestman | Question: where can one find the qt lib or whatever it is called. Ubuntu.appliacations so that I can test out on apps ? seems like it is needed for alot of apps to work | 18:30 |
| mterry_ | guestman: http://developer.ubuntu.com/get-started/gomobile/ | 18:30 |
| guestman | not there ^^ | 18:30 |
| mhall119|uds | is that something that the SDK team provides? | 18:30 |
| mhall119|uds | mterry_: I don't think we have it there | 18:31 |
| mterry_ | Sorry, I guess I thought you meant the Ubuntu componentss | 18:31 |
| guestman | gallarey uses it | 18:31 |
| guestman | every app that I compile is calling for it in JS functions | 18:31 |
| mhall119|uds | mterry_: yeah, we have some of them, but not Ubuntu.Applications specifically | 18:31 |
| j-johan-edwards | Question: Can desktop Unity behavior start merging into lp:phablet, or does the "form-factor aware" codepath still need to be worked out? | 18:31 |
| diwic | QUESTION: how are standard apps such as gnome-control-center, gnome-settings-deamon etc related to all of this? Will they be replaced by qt equivalents? | 18:31 |
| j-johan-edwards | (sorry to add to questions) | 18:32 |
| gusch | gallery works on desktop | 18:32 |
| gusch | it only prints a warning about the Ubuntu.Applications | 18:32 |
| mhall119|uds | diwic: that's probably out of scope for this session | 18:32 |
| guestman | Question: is the formfactors going to live on glib? just like Unity ? | 18:33 |
| mhall119|uds | Saviq: does the current codebase currently support different form-factors? | 18:33 |
| mhall119|uds | like desktop unity has a feature to switch, even if the different ones aren't implemented | 18:33 |
| guestman | glib ^^ | 18:34 |
| isantop | Form-factors | 18:34 |
| bschaefer | netbook? | 18:34 |
| robert_ancell | guestman, will get to that next | 18:34 |
| mhall119|uds | I know you won't be able to focus on desktop form-factor, but is the switching functionality there for other people who want to do it? | 18:34 |
| robert_ancell | guestman, I'm not sure what you mean though? | 18:34 |
| guestman | no robert_ancell I think that he is asking that | 18:34 |
| selena2013 | so a regular user will log in to his/her account on any device right ? | 18:35 |
| diwic | QUESTION: so it sounds like you're going to make huge changes to the desktop UI after october, i e, quite shortly before the 14.04 LTS release. That sounds bad from a quality standpoint? | 18:35 |
| mhall119|uds | Saviq: is there any ETA on when that design work/switching functionality might be done? | 18:35 |
| mhall119|uds | thanks | 18:37 |
| guestman | like com.caonical.unity | 18:38 |
| ricmm | Saviq: tvoss robert_ancell: whats the plan for transitioning our current phone/tablet session to using a proper session manager for startup/shutdown that works across all devices? | 18:39 |
| ricmm | didier and I had a doubt on that | 18:39 |
| ricmm | tvoss: I can track that if you need hands ;) | 18:40 |
| krabador | Question: with the new announced video server transition, and unity directly connected with it, what we can expect from unity on 13.10 ? | 18:40 |
| ricmm | kgunn: yea I added it | 18:40 |
| diwic | krabador, there is no 13.10 | 18:40 |
| krabador | diwic, oh, great. | 18:41 |
| krabador | yes :) | 18:41 |
| selena2013 | any device one account sounds fine to me | 18:41 |
| snwh | so the phone/tablet UI development will "trickle down" to the desktop? | 18:42 |
| guestman | Question: I tried to build of androidx11 have any of you got it to work for virtual machines ? | 18:42 |
| mhall119|uds | QUESTION: Will developers be able to run local builds in a nested window or VM? | 18:42 |
| robert_ancell | guestman, that sounds out of scope for unity | 18:42 |
| mzanetti | mhall119|uds: local builds of what? | 18:43 |
| mhall119|uds | mzanetti: of Unity Next | 18:43 |
| mhall119|uds | previosly running local builds of Unity 3D required replacing hte running shell | 18:43 |
| mhall119|uds | \o/ | 18:43 |
| thomi | that's awesome. | 18:43 |
| diwic | QUESTION: are the hw requirements different for current Unity (3d) and unity-next? | 18:43 |
| thomi | Having a separate window might help us run autopilot tests as well | 18:44 |
| mhall119|uds | tvoss: yeah, but keep it simple :) | 18:44 |
| mzanetti | thomi: yeah | 18:44 |
| thomi | \o/ | 18:44 |
| tvoss | mhall119|uds, yup :) | 18:44 |
| veebers | thomi: :-) | 18:44 |
| j-johan-edwards | I don't see the problem, currently Mir does an job displaying random boxes and stripes in /dev/tty1 | 18:44 |
| j-johan-edwards | (excellent job) | 18:44 |
| TheMuso | I guess this is more a Mir questino, will Mir support LLVM Pipe? | 18:45 |
| bschaefer | So is the current list for what needs porting to QML: Switcher? | 18:45 |
| diwic | thanks for all the answers so far :-) | 18:45 |
| fugue88 | On assuming a GPU---do you assume a 3D GPU, or would one with only 2D accel work? | 18:45 |
| TheMuso | Doesn't need to be answered in the hangout. | 18:45 |
| gusch | LLVM Pipe is a good question | 18:45 |
| selena2013 | will i be able to install ubuntu touch to a regular android device ? | 18:45 |
| mhall119|uds | selena2013: you already can | 18:46 |
| mhall119|uds | selena2013: https://wiki.ubuntu.com/Touch/Devices | 18:46 |
| krabador | Question (joke): Now , with qt, unity develop will copy things from kde? | 18:46 |
| mzanetti | krabador: KDE developers are here :D | 18:46 |
| mhall119|uds | krabador: if we do, I'm sure they'll let you know | 18:47 |
| krabador | yes, sure :) | 18:47 |
| gusch | krabador: KDE is moving more and more stuff to Qt, that will likely picked up | 18:47 |
| mhall119|uds | QUESTION: Do we have a doc with a roadmap/milestones/things to do next that we can follow along and get people to help with? | 18:48 |
| snwh | bouncy ball! | 18:48 |
| mhall119|uds | Question: Do we have specs from the design team for the things that need to be ported? | 18:49 |
| guestman | Question: do you all have public meetings/forum ? | 18:50 |
| MacSlow | guestman, #ubuntu-unity might be your best starting point... | 18:51 |
| mhall119|uds | there is #ubuntu-mir now too | 18:51 |
| MacSlow | guestman, and the public mailing-list | 18:51 |
| mhr3 | with unity in qml there'll be great support for customization, right? are we going to officially support that capability? | 18:52 |
| dednick | mhr3: what customisation? | 18:53 |
| mhr3 | yea, also like replacing launcher with something else | 18:54 |
| mhall119|uds | ok, we're almost out of time, are there any more work items that need to be put in the pad? | 18:54 |
| gusch | Saviq: customization - selective acticate/deactivate certain lenses | 18:54 |
| mhr3 | no connection, disregard my nick :) | 18:54 |
| TheMuso | I wouldn't want that customization to make sure carriers don't screw with the phone shell. | 18:55 |
| TheMuso | s/carriers/phone vendors/ | 18:55 |
| * kenvandine agrees with TheMuso | 18:55 | |
| diwic | TheMuso, couldn't that also mean that you can override/revert the customizations done by the carriers, too? | 18:56 |
| TheMuso | diwic: Urm, I doubt it. | 18:56 |
| diwic | ok | 18:56 |
| TheMuso | But I don't know for sure, I haven't known of anybody being able to get rid of a vendor's android skin without replacing the ROM. | 18:57 |
| Saviq | TheMuso, well, it's open source, can't really protect from that, if they really want to | 18:57 |
| mhall119|uds | kgunn: I was cleaning up the work items to make it easier to copy/paste into the blueprint | 18:57 |
| krabador | Question: Will Unity development contribute in some way, to improve the experience for "non official" ubuntu touch devices? | 18:57 |
| cjohnston | mzanetti: are the tests running some where right now? | 18:57 |
| bschaefer | Hows multi monitor going to be handled with the new unity? (One thing in mind are the pointer barriers that X provides atm). | 18:57 |
| TheMuso | Saviq: This is true, but not allowing easy customizatino will make it harder for them. | 18:57 |
| Saviq | TheMuso, not necessarily better for the users ;) | 18:57 |
| kgunn | mhall119: np :) | 18:57 |
| TheMuso | Saviq: Yeah I know. | 18:58 |
| Saviq | TheMuso, 'cause they will still customize it, just make a worse job of it | 18:58 |
| TheMuso | There is a good and a bad side to it. | 18:58 |
| Saviq | it's not like these customizations are driven by the developers actually implementing them | 18:58 |
| nonamejam | any plans for qml and quickly | 18:58 |
| mmrazik | didrocks: I don't think thats the case for current autopilot tests (sleeps) | 18:59 |
| mhall119|uds | nonamejam: I started a re-write of Quickly, and I do want to support QML apps, yes | 18:59 |
| mmrazik | didrocks: we are using the eventually stuff and that is polling in 1s intervals | 18:59 |
| * thomi agrees | 18:59 | |
| mmrazik | up to 10 seconds and then timeouts | 18:59 |
| dednick | QUESTION: where are the autopilot tests for UnityNext (if there are any currently?). I can't see any in the tsts folder. | 18:59 |
| nonamejam | mhall119|uds: sweet | 18:59 |
| mhall119|uds | nonamejam: for now, QtCreator does a good job of getting you started with a QML app | 18:59 |
| tsdgeos_uds | dednick: tests folder | 18:59 |
| thomi | dednick: there are none yet - come to the autopilot session up next maybe :) | 19:00 |
| guestman | why not just add "Quickly" to qtcreator ? with virtual machines and the templets that are there allready ? | 19:00 |
| dednick | thomi: sure :) planning to | 19:00 |
| tsdgeos_uds | dednick: http://bazaar.launchpad.net/~unity-team/unity/phablet/files/head:/tests/ | 19:00 |
| guestman | thanks all v.nice | 19:00 |
| mhall119|uds | this was a good session | 19:00 |
| mhall119|uds | thanks guys for watching IRC :) | 19:00 |
| Saviq | http://developer.ubuntu.com/get-started/gomobile/ | 19:00 |
| ptl | thankssss | 19:00 |
| === udsbotu changed the topic of #ubuntu-uds-client-1 to: Track: Foundations | Migrate from ConsoleKit to logind | Url: http://summit.ubuntu.com/uds-1303/meeting/21646/foundations-1303-consolekit-logind-migration/ | ||
| quesh | thanks | 19:01 |
| mhall119|uds | guestman: that was the plan, I just didn't have time to pull it off yet | 19:01 |
| quesh | bye | 19:01 |
| thomi | o/ | 19:01 |
| krabador | hi to you all | 19:01 |
| dednick | tsdgeos_uds: ah. thanks. need to get latest. | 19:01 |
| guestman | mhall119|uds: you know how to get a hold of me | 19:02 |
| tvoss | o/ | 19:02 |
| guestman | great session | 19:02 |
| kenvandine | tvoss, you're my inspiration :-D | 19:02 |
| tvoss | kenvandine, awesome :D | 19:02 |
| didrocks | lovely ;) | 19:02 |
| xnox | hello =) | 19:04 |
| seb128 | xnox, hey | 19:04 |
| seb128 | xnox, joining us? ;-) | 19:04 |
| xnox | seb128: I am, cjwatson is as well =) | 19:05 |
| pitti_uds | I can haz hangout link? | 19:05 |
| seb128 | youtube: http://youtu.be/VTlPLZfJDVc | 19:05 |
| cjwatson | I'll sit and listen for a bit, might join the hangout later | 19:05 |
| seb128 | hangout: https://plus.google.com/hangouts/_/3dad298411e4a7119dbe80e5f1b917f6bfdad8d9?authuser=0&hl=fr | 19:05 |
| xnox | pitti_uds: https://plus.google.com/hangouts/_/3dad298411e4a7119dbe80e5f1b917f6bfdad8d9?authuser=0&hl=de in german for you =) | 19:05 |
| xnox | https://plus.google.com/hangouts/_/3dad298411e4a7119dbe80e5f1b917f6bfdad8d9?authuser=0&hl=en in english for the rest of us | 19:06 |
| * xnox was confused about french G+ from seb128 last time around. | 19:06 | |
| didrocks | xnox: come on! | 19:06 |
| didrocks | the interface is easy | 19:06 |
| didrocks | and the language is lovely :) | 19:06 |
| ogra_ | scary people | 19:06 |
| zyga-uds2 | hi everyone | 19:06 |
| cjwatson | glad to know somebody's accent is worse than mine :) | 19:06 |
| * ogra_ goes back to the foundations room | 19:06 | |
| zyga-uds2 | you are | 19:07 |
| zyga-uds2 | there are two leeters in the url ;) | 19:07 |
| zyga-uds2 | letters | 19:08 |
| * slangasek waves | 19:08 | |
| seb128 | slangasek, hey, coming? | 19:08 |
| pitti_uds | hey slangasek | 19:08 |
| slangasek | I'm stuck in a different hangout again as videographer | 19:08 |
| slangasek | this is a silly limitation :) | 19:08 |
| seb128 | slangasek, want me to invite your phone again? | 19:08 |
| * lool is watching | 19:09 | |
| seb128 | lool, want to come? https://plus.google.com/hangouts/_/3dad298411e4a7119dbe80e5f1b917f6bfdad8d9?authuser=0&hl=fr | 19:09 |
| lool | ok | 19:09 |
| * zebaszp waits impatienly | 19:09 | |
| slangasek | seb128: sure | 19:09 |
| cjwatson | slangasek: since I seem to have stable G+ now, I guess next time I can share the foundations load | 19:09 |
| slangasek | cjwatson: next time I think we should figure out how to have a "virtual camera crew" that aren't on the hook for participating in sessions :) | 19:10 |
| cjwatson | That too | 19:10 |
| robert_ancell | stgraber, your background looks like you have some fake mountain scene background :) | 19:10 |
| zyga-uds2 | feed is broken | 19:10 |
| diwic | oh no | 19:10 |
| barry | uh oh | 19:10 |
| dedalus | brb? | 19:10 |
| * mdeslaur kicks hangouts | 19:10 | |
| zebaszp | oh noes! | 19:10 |
| seb128 | should be back on | 19:10 |
| zyga-uds2 | back | 19:10 |
| dedalus | ah, there we go | 19:10 |
| zebaszp | yay! back! | 19:10 |
| diwic | back | 19:10 |
| mdeslaur | s/hangouts/hangups/ | 19:11 |
| seb128 | I hate to leave/rejoin to be able to invite a phone | 19:11 |
| zyga-uds2 | woot, cool feature | 19:11 |
| zebaszp | QUESTION: what about the rest of systemd? <flamewar> | 19:12 |
| seb128 | zebaszp, going to ignore that one :p | 19:13 |
| zebaszp | seb128, almost intended to be ignored, even though I'd like to see us migrate to systemd | 19:14 |
| zebaszp | </flamewar> | 19:14 |
| seb128 | zebaszp, not going to happen anytime soon | 19:14 |
| seb128 | migrating all the init scripts is tons of work and we have lot to get done this cycle | 19:15 |
| seb128 | which doesn't include changing the init system for not visible user benefit | 19:15 |
| zebaszp | seb128, gotcha; anyhow, I doubt the community will stop pushing for this to happen, but let's keep the chat in topic | 19:16 |
| seb128 | right, different discussion | 19:17 |
| seb128 | it might happen | 19:17 |
| seb128 | but the focus for this year is to get a working phone image out | 19:17 |
| seb128 | and systemd is not a blocker for that | 19:17 |
| pitti_uds | jodh: muting you because of typing noise | 19:17 |
| zebaszp | fingers crossed for 16.04 :P | 19:17 |
| zyga-uds2 | for the typists: mute yourself please | 19:17 |
| jodh | pitti_uds: thanks - I've now muted myself too :) | 19:18 |
| TheMuso | pulse does have support for logind/systemd. | 19:21 |
| TheMuso | Pulse has src/modules/module-systemd-login.c, so yeah a module for logind. | 19:22 |
| mdeslaur | of course he said it shouldn't :) | 19:22 |
| zyga-uds2 | QUESTION: do you guys see a loosesystemd source tree that mainitains all the plumbing bits that don't pull in systemd entirely to ensure we don't get into a forced transition later | 19:24 |
| zyga-uds2 | lool: ^^ | 19:26 |
| asb_asb_asb | udev can be built out of the systemd tree | 19:26 |
| asb_asb_asb | I believe Debian has packages that do this | 19:27 |
| zyga-uds2 | asb_asb_asb: yes but that's just now, what if that's removed tomorrow | 19:27 |
| zyga-uds2 | asb_asb_asb: and I mean more than just udev | 19:27 |
| zyga-uds2 | pitti_uds: ^^ (see QUESTION above if you can) | 19:27 |
| asb_asb_asb | zyga-uds2: I've seen no indication that would be the case. Though if so, I guess eudev | 19:27 |
| asb_asb_asb | though eudev has got off to a rocky start | 19:28 |
| xnox | asb_asb_asb: there are no plans to package nor use eudev at this time in Debian nor by extension in Ubuntu. | 19:28 |
| asb_asb_asb | xnox: indeed, why would there be? I'm just saying in some scary world where upstream goes crazy, eudev would be the new upstream | 19:29 |
| slangasek | console-kit-dae /usr/sbin/console-kit-daemo 440 2094012 436 | 19:29 |
| slangasek | srsly? what kind of VSS usage is that? | 19:29 |
| xnox | zyga-uds2: at the time, slangasek split the tree and it's not based on loosesystemd at the moment. | 19:29 |
| slangasek | I haven't split any trees here | 19:30 |
| xnox | asb_asb_asb: upstream did not go crazy yet, but eudev already is not source compatible without bringing anything useful for us to integrate. | 19:30 |
| xnox | zyga-uds2: slangasek: sorry. Did not split, but package it in a way that only some of it ends up in debs. | 19:32 |
| zyga-uds | xnox: I know that's going on right now | 19:32 |
| zyga-uds | xnox: I wonder if as long as we use upstart (and that's not changing so far) can we ride this wave of systemd components that still work for us | 19:33 |
| zyga-uds | xnox: before having to have to take action to really support them standalone better | 19:33 |
| xnox | well that's what we are discussing at the moment =)))))) | 19:34 |
| asb_asb_asb_ | regarding devtmpfs doing most of the work right now, Funtoo is currently looking at moving completely to mdev+devtmpfs | 19:34 |
| dbarth | stgraber: is the notion of "atconsole" fixed with lxc / udev setup you're describing? | 19:34 |
| asb_asb_asb_ | main thing you miss out on is libudev | 19:34 |
| cjwatson | That's pretty significant for us | 19:34 |
| asb_asb_asb_ | cjwatson: of course :) | 19:35 |
| stgraber | dbarth: I didn't recheck atconsole with logind, my hope was that it'd at least be different from what we had with consolekit | 19:35 |
| cjwatson | Rather, critical | 19:35 |
| dbarth | ok | 19:35 |
| slangasek | http://paste.ubuntu.com/5591297/ | 19:36 |
| olafura_ | QUESTION: Does logind fix the bug in console-kit of taking 4 GiB in virtual memory? | 19:37 |
| cjwatson | (I don't know, but) not sure the virt size is all that important - its actual resident size is tiny | 19:39 |
| cjwatson | well, by comparison :) | 19:39 |
| olafura_ | cjwatson but it must have some side effect | 19:39 |
| cjwatson | why must it? | 19:39 |
| cjwatson | virt size is a terrible measure of a process' actual memory footprint - PSS is better, see https://wiki.ubuntu.com/Nexus7/MeasuringMemoryUsage | 19:40 |
| cjwatson | not that reducing it is a bad thing, it's just not something that's worth spending much time on :) | 19:41 |
| stgraber | downside of vUDS, people can show up at your place at random... | 19:41 |
| robert_ancell | stgraber, heh, I had builders next door yesterday | 19:41 |
| olafura_ | cjwatson duly noted ;) | 19:43 |
| cjwatson | (e.g. mmaping a giant file will increase your process' virt size, but doesn't have any meaningful effect on system memory use) | 19:43 |
| seb128 | xnox, is there any way you can crosscheck the packages that already have logind support in your grepping? | 19:44 |
| seb128 | xnox, some support both | 19:44 |
| xnox | seb128: sure. adding as an action for myself. | 19:44 |
| seb128 | xnox, thanks | 19:45 |
| TheMuso | As above, pulse does. Once systemd is in main, we can start building the module for pulse. | 19:47 |
| slangasek | cjwatson: right, so IIRC a lot of what's getting measured in consolekit's memory usage are a bunch of large, multi-megabyte anonymous mappings with *no* perms set on them (read, write, or execute) | 19:53 |
| slangasek | cjwatson: so the kernel happily sweeps those under the rug | 19:53 |
| lool | CK did come up in the memory optimization efforts | 19:54 |
| lool | we suspected it oculd be optimized | 19:54 |
| lool | but if it's being replaced, it doesn't really matter | 19:54 |
| jdstrand | slangasek: fyi, I have the ability to grep the archive. if someone gives me what to look for, I can get it to you. I'm sure others can do it too | 19:59 |
| slangasek | jdstrand: sounds like xnox has already done it via the Debian archive | 19:59 |
| jdstrand | ok | 20:00 |
| === udsbotu changed the topic of #ubuntu-uds-client-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1303/client-1/ - http://ubottu.com/uds-logs/%23ubuntu-uds-client-1.log | ||
| cjwatson | lool: Yeah, the 1.7M PSS is more of a concern | 20:00 |
| cjwatson | slangasek: I'd be concerned about relying solely on the Debian archive; it's no longer the case, but the consolekit patch in openssh was an Ubuntu-specific patch for a long time | 20:01 |
| slangasek | ah | 20:01 |
| cjwatson | (It still kind of is, but it's in the Debian source package and conditionally configured) | 20:01 |
| slangasek | xnox: ^^ can you tell jdstrand what to grep for? | 20:01 |
| jdstrand | xnox: just whenever. it will take a while to generate the results | 20:05 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!