[00:56] hello [01:02] you're a little late, if you were intending to show up for one of the sessions :) [01:04] understood [01:04] I was under a firewall when the session I was interested was on [01:04] a.k.a. @work [01:04] :) [01:05] anybody on from the "Next steps for the click-package prototype for simplified app package installation" session? Or who knows about the app packaging model being proposed for ubuntu touch/phone? [01:07] You should be able to watch the video recording, from the summit page [01:07] and see the Etherpad notes. [01:07] #ubuntu-devel is probably a better channel to find folks [01:08] ah ok [01:09] I tried that before, kept being pushed into #ubuntu-touch which nobody is ever watching === smb` is now known as smb === schwuk_away is now known as schwuk === schwuk is now known as schwuk_away === schwuk_away is now known as schwuk === schwuk is now known as schwuk_away === schwuk_away is now known as schwuk === jsjgruber is now known as Guest90717 === Guest90717 is now known as jsjgruber === udsbotu changed the topic of #ubuntu-uds-foundations-1 to: Track: Foundations | Further improvements to the Checkbox release process | Url: http://summit.ubuntu.com/uds-1305/meeting/21743/foundations-1305-checkbox-release-process/ [13:54] hi [13:55] brendand: so you're leading this one as well>? [13:55] hey! [13:55] zyga, indeed [13:56] seems this is starting in 3 mins [13:57] brb [13:57] brendand: ok, paste the hangout link when ready [13:57] do we know who'll be helping us with the hangout and stuff? [13:57] I will [13:57] bdmurray:thanks [13:58] bdmurray: thanks! good morning! [13:59] Could someone paste the hangout url again? [13:59] please [13:59] bdmurray, paste the link here [13:59] spineau: I don't think we have it yet [14:00] https://plus.google.com/hangouts/_/21d0b82e4f2532f0af0e595e8d62e13abb019da2?authuser=0&hl=en [14:00] roadmr: ok, I'm not late then :) [14:09] whats the link to the BP? [14:10] https://blueprints.launchpad.net/certify-planning/+spec/foundations-1305-checkbox-release-process [14:10] thanks [14:20] yes, CE QA is really happy with current process [14:20] can you join the hangout jeffreyc [14:20] https://plus.google.com/hangouts/_/21d0b82e4f2532f0af0e595e8d62e13abb019da2?authuser=0&hl=en === bladernr` is now known as bladernr [14:43] hello [14:44] ara: hi! [14:44] ara: https://plus.google.com/hangouts/_/21d0b82e4f2532f0af0e595e8d62e13abb019da2 [14:45] roadmr, I will stay on IRC, for the 10 minutes that lasts [14:45] but thanks :) [14:45] ara: ok :) [14:51] zyga, a schedule [14:51] zyga, and when [14:56] can I vote that we only put changes/bug fix note about checkbox core into the changelog? Remove the cruft of job and individual script updates? [14:57] spideyman, that would never be accepted in Ubuntu [14:58] meh...then we probably need to decouple them from checkbox. [14:58] spideyman, yes, that I agree :) [14:59] You can still summarise changes in Ubuntu though; they don't have to be commit-level or anything [15:00] Or you could treat it as an upstream tarball, where we frequently have changes only in upstream changelogs/NEWS files or whatever and don't repeat them in debian/changelog [15:00] Various possibilities === udsbotu changed the topic of #ubuntu-uds-foundations-1 to: Track: Foundations | Kubuntu and UEFI and LTS Backports | Url: http://summit.ubuntu.com/uds-1305/meeting/21779/kubuntu-and-uefi-and-lts-backports/ [15:01] cjwatson: thanks! [15:01] indeed, thanks [15:02] ara: what did you mean by 'a schedule and when'? [15:02] ara: do you know how to go about scheduling another session for tomorrow? [15:02] starting up hangout now [15:02] roadmr: ask a suitable track lead [15:02] (may or may not be space) [15:02] cjwatson: oh ok thanks :) [15:03] afternoon [15:03] running sessions is tiring :) [15:04] Kubuntu/UEFI/LTS hangout: https://plus.google.com/hangouts/_/6f16a08fd55e3e6db336ef84515052124bef0e8f?authuser=1&hl=en-GB [15:04] zyga, I meant scheduling the work to be done [15:04] ara: scheduling the packaging changes? ok [15:05] (should I expect Kubuntu folks in the hangout? I'm not certain whether you have the google hangout plugin sorted and such) [15:05] ah, there [15:07] txwikinger: ? [15:07] txwikinger,xnox: are you joining the hangout? [15:07] apw subscribed too? [15:07] * apw is just watching [15:08] cjwatson: i'm watching from a libary. I can provide a pretty picture with a backdrop, but can't speak out loud. [15:08] =) [15:08] (unless I move elsewhere) [15:08] I'd rather chat on irc. [15:09] cjwatson, i can see it [15:09] \o/ [15:09] http://blogs.kde.org/2013/05/09/breakouts-uefi [15:10] cjwatson: Riddell: isn't this more about SB, rather than just UEFI. [15:10] Any of you have working cameras? [15:10] I have mine turned off [15:11] I mean if you *really* want to see my ugly mug :P [15:12] mine doesn't seem to work today [15:12] xnox: about SB? [15:13] no camera here [15:13] unless it decides to work [15:14] well, reading the blog post, it is a bit confusing as to what happened there. i only ever always had a single efi partition =/ [15:14] b 43 [15:15] Bug 1167622 [15:15] Ubuntu bug 1167622 in linux (Ubuntu) "Cannot change EFI variables using efibootmgr (raring regression)" [Medium,Confirmed] https://launchpad.net/bugs/1167622 [15:15] That bug seems to be the root cause of the Kubuntu failure here [15:15] I'm not sure why it didn't break Ubuntu as well [15:15] Could be related to Kubuntu not using a signed kernel, I suppose, which would mean it would be booted slightly differently [15:16] cjwatson, we would indeed boot rather differently if we are not using a signed kernel [15:17] bug 1178294 [15:17] Ubuntu bug 1178294 in ubiquity (Ubuntu) "Install fails with Kubuntu 13.04 on UEFI system" [Undecided,Confirmed] https://launchpad.net/bugs/1178294 [15:18] apw: can you comment on 1167622? would that cause the precise symptom in 1178294? [15:18] the failure there seems to be "bricks system" rather than "causes set_variable to fail" [15:18] May 9 16:52:54 kubuntu ubiquity: Can't access efivars filesystem at /sys/firmware/efi/efivars, aborting [15:19] that implies we did not have any access to the efivars at all, perhaps as a result of the mode [15:19] ie not being booted into via the efi entry point [15:20] on the '50% full' issue for nvram there have been some re-re-re-fixing in the handling of sizes [15:22] bug 1167622 gets an efi "EFI_OUT_OF_RESOURCES" error, so it looks like there is not enough free EFI NVRAM free [15:22] Ubuntu bug 1167622 in linux (Ubuntu) "Cannot change EFI variables using efibootmgr (raring regression)" [Medium,Confirmed] https://launchpad.net/bugs/1167622 [15:23] cking, that might be one of those corner cases the later kernels have worked round, where the firmware lies in some of the size responses [15:23] yep, or just lame firmware that can't be worked around, hard to tell [15:23] indeed [15:28] damn, lost my connection [15:28] * cjwatson attempts to reconnect but isn't hopeful [15:29] * cking notes any EFI status 8000000000000009 means there isn't enough variable space, but we are at the mercy of the EFI run time services so who knows why it really failed [15:29] cjwatson, i think kernel concurs with your position, that we should get kubuntu using the signed kerenl and then review the remaining issues, the rest ought to be common to ubuntu as well [15:29] Riddell, is it you who has the list of bugs found during the install, those should be in the pad [15:31] cjwatson: you did well =) [15:31] cjwatson: looks good, same URL [15:31] apw: I filed bug 1178294 for not working on my uefi/sb machine, is that what you mean? [15:31] Ubuntu bug 1178294 in ubiquity (Ubuntu) "Install fails with Kubuntu 13.04 on UEFI system" [Undecided,Confirmed] https://launchpad.net/bugs/1178294 [15:31] * cjwatson tries to find apachelogger's bug [15:33] he said on 2013-05-02 that he was going to file one [15:33] bug 1167622 [15:33] Ubuntu bug 1167622 in linux (Ubuntu) "Cannot change EFI variables using efibootmgr (raring regression)" [Medium,Confirmed] https://launchpad.net/bugs/1167622 [15:36] bug 1171099 - but on reflection it appears unrelated [15:36] Ubuntu bug 1171099 in kubuntu-settings (Ubuntu Saucy) "kubuntu - plymouth not shown" [High,Triaged] https://launchpad.net/bugs/1171099 - Assigned to Harald Sitter (apachelogger) [15:36] sorry for derailing, I was triggering mentally on "grub" and "kubuntu" :) [15:38] apw,cking: would one of you be a sensible kernel contact if there are still outstanding bugs? [15:38] cjwatson, yeap poke me [15:38] definitely looks like the first step is "get saucy into gear and try it" [15:38] ok [15:39] yep concur, i should have kit to test it with as well, at least a bit [15:39] apw, as long as you don't brick it [15:40] cking, i am sure i will [15:41] cjwatson, there was a bug somewhere with all the changes connected to it i think, at least all the packages [15:42] Yeah, I remember that, though I fear it was incomplete [15:42] I'll hunt it down [15:45] Riddell: is there a blueprint for this, btw? just asking 'cos if so it would decrease the chance of work items getting lost [15:46] cjwatson: nope, shall I make one? [15:46] if you would that'd be great [15:52] cjwatson: voila https://blueprints.launchpad.net/ubuntu/+spec/foundations-1305-kubuntu [15:53] ta [15:55] done the seed bits for saucy at least - precise will take more work [15:55] and probably ought to make sure first that it works in saucy, anyway === udsbotu changed the topic of #ubuntu-uds-foundations-1 to: Track: Foundations | Mobile Power Management | Url: http://summit.ubuntu.com/uds-1305/meeting/21776/foundations-1305-mobile-pm/ [16:02] hey [16:03] * pitti waves [16:03] * ogasawara waves [16:03] not sure if bdmurray or cjwatson is starting up our session [16:04] ogasawara: bdmurray [16:04] ogasawara: I should be just a moment [16:04] ack, thanks [16:04] we had a brief mix-up [16:05] https://plus.google.com/hangouts/_/d9954311986ea36d3861625cd022d9dc8db2c213?authuser=0&hl=en [16:05] lool, mfisch, sforshee ^^ [16:06] pitti: ^^ if you feel inclined [16:07] ogasawara, are we live yet ? [16:07] doesnt look like [16:07] just starting [16:08] not seeing it yet [16:09] * ogra_ sees ... [16:10] video stutters here... [16:10] it didnt here until you said that ! [16:10] LOL :) [16:11] :) [16:12] http://goo.gl/KMlMv [16:12] system power policy doc: http://goo.gl/KMlMv [16:15] I like the mental model that it's a constant battle between the power manager trying to reduce power and apps trying to keep it [16:16] so app authors have to do work to fight against the power manager [16:16] right, via curated APIs [16:16] yeah the api should help them [16:18] yeah [16:18] app authors have to wage battle against the power manager, but only through the api [16:18] that means the power manager will have the deck stacked in its gavor [16:18] tvyou are [16:18] favor* [16:20] maybe google i/o is melting the internet now [16:20] seth's video always freezes ;) [16:21] QUESTION: at what level will these inhibitors be 'switched on' as it were, such that all the responsibility doesn't lie with each individual app? [16:21] sforshee: yeah, I think I have like a 10 second lag, sorry [16:21] funny conversation [16:21] e.g. why have each app that could play music switch it on, when the audio subsystem (pulse?) will know this anyway? [16:22] brendand, well, tha ypi will switchi it on [16:22] *the api [16:22] brendand: the responsibility is *below* the app level [16:22] brendand: the API backend will manage this on behalf of the apps [16:22] i.e. your app plays music ... the api knows that and tells pulse about it [16:22] and pulse inhibits [16:22] brendand: the app calls playBackgroundMusic() and then the audio service/pulse tells power manager "dont suspend" [16:23] it seems that it should be inhibited at the lowest level possible that makes sense [16:24] brendand: what do you mean? [16:24] brendand: the whole point of hiding it behind the API is precisely to inhibit at the level that makes sense [16:24] pitti, it think we also want to live that stuff on a system level, not a session one ... logind could be our channel for conversation i guess though [16:26] ogra_: yes, I agree; you can query them at a system level, but they are still tied to a particular session/seat [16:26] (powerd wouldn't need to care about which particular session, of course) [16:26] right [16:26] mfisch, i guess my question is answered. that was just a general observation [16:27] ogra_: thats what we envisioned, logind is out path to match sessions and seats [16:27] yeah [16:27] sessions may request a display state and we need to map that to a physical display (seat) which in turn is managed by a system compositor [16:27] did you guys look into teh existing powerd already [16:27] ? [16:28] ogra_: yes, we are currently coding some enhancements onto it to prove out the concepts [16:28] awesome :) [16:28] question the second: how fine grained can the hardware control be? can it switch e.g. everything off but the wifi chip, or even vice versa? [16:28] the kernel can ... [16:28] brendand: we plan that PM only manages screen power and system power (suspend), but not, for example, low power wifi states [16:28] so the question is how much use do we make of it [16:29] if the wifi chip supports some low power mode, for example, the wifi stack deals with that [16:29] (over time) [16:29] mfisch, that's true [16:29] the devil is in the unexpected detail, so we need to start somewhere [16:29] agreed [16:30] just from starting to implement some stuff I've run into several questions about how the API would work [16:30] he is currently doing it himself [16:30] since he wrote the initial version [16:31] ogasawara, damn straight [16:31] sforshee, about time ! [16:32] kernels are boring ... userspace has all the excitiment [16:32] Chicken: you've got me until friday ;) [16:33] mfisch, actually what i meant was that say the only thing that is happening on the system is a file download. what is the most efficient power state that can be reached? [16:33] ogra_, I like kernels ;-) [16:33] :) [16:34] brendand: it depends on the system, realistically probably screen off but not suspended, however, if you had a system where you could download a file without the system CPU, then it would work like this [16:34] (these are made-up API calls), app calls downloadBackgroundFile() [16:34] aren't ARM processors more flexible in that regard? [16:34] then download manager decides whether the system should suspend or not [16:34] a lot [16:34] right [16:34] i. e. that they already shut down units which aren't necessary for a particular task? [16:35] depends [16:35] pitti, yes to some degree [16:35] it's a whole system really [16:35] on a single chip [16:35] * pitti really liked the OLPC which could display a static image with shutting down the CPU and GPU :) [16:35] i.e. if the kernel (and HW) supports the interactive governor you can do very intresting things on that level [16:35] QUESTION: when suspending the device via power button you should still be able to access a device via adb correct? [16:35] very finegrained too [16:36] because the nexus 10 doesn't [16:36] rfowler: I thought on Android there's a wakelock held when you're using adb that prevents suspend [16:36] ogra_: can you run an ARM CPU at hilariously slow speeds? like 500 kHz or so? [16:36] rfowler, yes, in that case the system should turn off the screen but not suspend [16:36] rfowler, we don't have all the infrastructure in place yet ;-) [16:36] pitti, heh, never tried below 200MHz [16:36] pitti, i suppose it might work though [16:37] mfisch, the nexus 10 kernel doesn [16:37] doesn't have the same wakelock infrastructure as past android devices [16:37] ah the n4 seemed to [16:37] I dont have a n10 [16:37] n4 still uses the old android wakelock model [16:37] thanks === udsbotu changed the topic of #ubuntu-uds-foundations-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1305/foundations-1/ - http://ubottu.com/udslog/%23ubuntu-uds-foundations-1 === udsbotu changed the topic of #ubuntu-uds-foundations-1 to: Track: Foundations | Plans for documentation and positioning of the development release | Url: http://summit.ubuntu.com/uds-1305/meeting/21761/foundations-1305-development-release-planning/ [18:01] * cjwatson gets back to the hangout creation dance [18:02] https://plus.google.com/hangouts/_/375a4beea5be9186d8db528da6728c294bddc025?authuser=1&hl=en-GB [18:05] anyone else joining the hangout? It's rather quieter than I expected :) [18:05] rickspencer3: ^- [18:05] is it just you cjwatson ? ;-) [18:06] And stgraber [18:06] hi cjwatson I'd be happy to join [18:06] cjwatson, I don't know that I can contribute much technical, thouhg [18:07] Fair enough, thanks [18:07] https://plus.google.com/hangouts/_/375a4beea5be9186d8db528da6728c294bddc025?authuser=1&hl=en-GB [18:09] sorry, could someone please repost the hangout url? [18:09] https://plus.google.com/hangouts/_/375a4beea5be9186d8db528da6728c294bddc025?authuser=1&hl=en-GB [18:09] thanks === schwuk is now known as schwuk_away [18:14] stgraber++ [18:14] let's call it "sid" [18:16] cjwatson, would we be able to upload to this new name, i am assuming not [18:17] apw: no [18:17] well, that's what Rick brought up, but the current plan is a simple symlink at the archive level [18:17] LP wouldn't be aware of that [18:19] * xnox ideally wishes _all_ uploads to be phased in the devel release =) [18:24] the current qa community folks would be happy to run this :-) [18:25] apw: Rick brought it up and I hadn't thought about it; it's easy enough to do [18:26] stgraber: I was planning to have LP create the symlink, though (in the publisher) [18:26] pumpichank: iron rule: no name clashes with Debian :) [18:26] In the session before lunch we discussed how to display key performance indicators on the QA Dashboard that could be helpful of people trying to decide to update [18:27] the bit that is missing, is the pop-up: 'wanna see the next ubuntu's wallpaper?' =))))) [18:27] cjohnston: KPI is an indicator, using a devel release should be more playful & impulsive. I think. If one looks at stability indicators, precise will always win. [18:28] I think the other fear is fear of hardware being killed by the development version... [18:28] xnox: sure, however if people are asking on IRC if they should update, that would give them something to look at [18:29] if they are asking to update or not, odds are they aren't good candidates :-) [18:30] I am somewhere between cjohnston & balloons, closer to balloons stance I think =) [18:31] I haven't switched yet, but I've thought about it.. partially due to time... but it would still be nice to see if today is looking ok before doing it [18:31] it is fair to ask/check if something is totally borked before upgrading.. but in general, your running the devel release for a specific reason. We hope your running it to help ubuntu itself out by testing, hacking, developing, whatever [18:31] that's what I'm getting at [18:32] cjohnston, however, I've never done such a thing.. If an upgrade fails, I file a bug [18:32] wait and try again ;-) [18:33] If you can look and see that its going to break and there is already a bug, why try [18:34] can't we get statistics like that by monitoring accesses to the development repos? [18:34] cjohnston, if there was a known issue, I would be more inclined to try :-) [18:35] it's about setting expectations for the release. I don't think anything has to really changed on that front. If your running -devel release things may break [18:35] it's all part of the experience, and to the extent you have an issue, report it, workaround it and move on [18:37] omgomega [18:37] * xnox .o0(now we just need a 7 grade scale of neo-users) [18:38] "dev" [18:38] tip++ [18:39] you could still call it rolling :-) [18:39] where is the marketing department when you need them? =)))) [18:39] good thing there's no possibility of bikeshedding the name [18:39] rickroll [18:39] "fresh"? [18:40] let's call it "tumble weed". [18:40] preview? [18:40] warty? [18:40] lol [18:40] nonameyet [18:40] adjective and an animal? to put into lsb-release os / etc? [18:41] +1 nonamyet [18:41] rolling does already have a bunch of publicity out there. [18:42] nonameyet because Mark hasn't picked an animal [18:42] heh [18:42] voyager [18:42] rolling is not bad [18:43] honestly rolling probably communicates things simply, without requiring more explanation [18:43] * apw suggests bikeshed [18:43] +1 [18:43] phk [18:44] lool, no no no, he wants one we cannot have without blowing LP up [18:44] :-) [18:44] just blog about it [18:44] plus it's probably (tm) google [18:51] that would be help those who are afraid to move early in the development release as well. [18:53] anything else here? [18:53] thanks cjwatson [18:53] I <3 "rolling" ;) [18:53] thanks everyone [18:54] rolling roadrunner ...... acme flashbacks [18:54] rickspencer3: I'll drop this into the blueprint whiteboard/WIs, so maybe just edit there when I'm done rather than fighting with etherpad [18:54] rick rolling rash roadrunner [18:54] release [18:54] :-p [18:54] rickspencer3, it hought you loved the rolling release, hiding it seems odd [18:56] ah, "export as plain text" from the pad => less unpleasant way to get it into blueprints [18:56] rickspencer3: all in the bp now [18:56] cjwatson, ok, I'll pop my notes in there then === udsbotu changed the topic of #ubuntu-uds-foundations-1 to: Track: Foundations | semiannual release schedule review | Url: http://summit.ubuntu.com/uds-1305/meeting/21794/semiannual-release-schedule-review/ [19:01] hello [19:02] who's running the hangout? [19:02] I am [19:03] i suppose i'd like to join that one :) [19:03] defining want in the "should" sense ;9 [19:04] elfy, o/ [19:04] https://plus.google.com/hangouts/_/ef55fe3b04e56166a89aa6c2a748602a149da165?authuser=0&hl=en [19:04] knome: yep - I'm here [19:04] more or less [19:05] :) [19:05] oodie [19:05] +g too (not g+) [19:08] is the feed live? [19:08] it's very quiet :p [19:08] xnox: not that I can see [19:08] xnox, not here [19:08] just started it [19:09] hear no evil, see no evil... not live yet [19:09] bdmurray, there is a heck of a lag from the originators timezone to ones a ways away [19:09] https://wiki.ubuntu.com/SaucySalamander/ReleaseSchedule [19:09] ah, there it is [19:09] apw: are you suggesting I move? [19:09] ahh video :-) [19:10] bdmurray, it is the obvious solution :) [19:11] cjwatson: there are bits on the pad to discuss =) [19:12] those were things I said [19:13] lol.. yes, milestones seem to be pretty good drivers for flavors [19:13] balloons: what was your sense of testing of earlier milestones? [19:14] cjwatson: i see =) lag. [19:15] in comparison to ubuntu, they were pretty tame. However, I do echo stgraber here. Flavors like kubuntu and lubuntu got there work done as part of having milestones; they seemed to like having that 'hard date' in which work needed to be complete [19:15] * elfy is listening - I'd agree with what knome has said [19:22] in-dash payments. [19:22] was the other one, i think. [19:27] a2 and a3 being so close meant most flavors looking at it weren't going to do one of them :-) [19:28] yeah, I think that was among the reasons we deleted a3 from raring [19:28] * cjwatson harks back to the days of 7 alphas [19:28] the proposed changes sound fine to me [19:29] not me! [19:29] way to go, mute all the community people >;) [19:29] +1 on making milestones ~= monthly cadence [19:29] :-P [19:29] unmute yourselves if you want to talk :) [19:29] nah [19:29] * cjwatson is muted too [19:30] lol.. good practice so background noise of your cat doesn't pop in :-) [19:30] oh, one can't see who's muted or not. interesting [19:30] cat pooping in? === hikiko-uds is now known as hikiko [19:30] i was told i type really loudly [19:31] will ff be moved back again? [19:31] I know there was still some drama even with it moved so far back into the cycle [19:32] you're the first person who's expressed a desire to move it back :) [19:32] want to expand? as stgraber was saying, for once it seems to have been sort of successful [19:33] in that we didn't actually have too many major disruptive changes after FF [19:33] depends on the release team i suppose [19:33] cjwatson, I think I confused everyone.. aka.. it's week 17, will it be week 20 in saucy like raring or no? [19:34] I speaking of feature freeze ^^ [19:34] right, yeah, like we said there are a bunch of changes we made in raring that don't seem to have been mirrored into saucy [19:34] ok.. right, excellent [19:34] basically because there was an incredibly unwise decision several releases ago to create a bunch of release schedules in advance [19:34] so now we have to keep remembering to mirror changes ... [19:35] Adam took an action to push things over [19:35] lol.. you try and make less work for yourself, and boom [19:36] tring to remember last time that worked for me [19:39] mm.. adam, that's the point of cadence testing [19:43] fyi, if your curious of stats for raring; http://91.189.93.58/ scroll down to the "Raring Image Testers" and "Raring Image Results" [19:43] you can see the spikes are the milestones [19:44] the later milestones had much more traction than the early milestones [19:48] adam should use xfce ;) [19:48] use google dns :-p [19:51] can you also mail the flavor devel lists? === udsbotu changed the topic of #ubuntu-uds-foundations-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1305/foundations-1/ - http://ubottu.com/udslog/%23ubuntu-uds-foundations-1