=== dyfet` is now known as dyfet === freeflyi1g is now known as freeflying === dyfet` is now known as dyfet === Claudinux_ is now known as Claudinux === rgreening_ is now known as rgreening [14:02] o/ [14:06] o/ [14:07] No meeting today then [14:08] well, we should have it, waiting NCommander [14:08] give NCommandera few minutes to shake off the cob webs. [14:09] G'day [14:10] NCommander has been successfully poked. [14:11] #startmeeting [14:11] Meeting started at 08:11. The chair is NCommander. [14:11] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [14:11] question is if he stays awake :) [14:11] * NCommander had a time zone adjustment failure [14:11] Does he ever? [14:11] heh [14:12] [link] https://wiki.ubuntu.com/MobileTeam/Meeting/2010/20101005 [14:12] LINK received: https://wiki.ubuntu.com/MobileTeam/Meeting/2010/20101005 [14:12] No Action items or special items from last week [14:12] [topic] Burndown chart [14:12] New Topic: Burndown chart [14:12] [link] http://people.canonical.com/~pitti/workitems/maverick/canonical-mobile.html [14:12] LINK received: http://people.canonical.com/~pitti/workitems/maverick/canonical-mobile.html [14:13] [link] http://people.canonical.com/~pitti/workitems/maverick/canonical-mobile-ubuntu-10.10.html [14:13] LINK received: http://people.canonical.com/~pitti/workitems/maverick/canonical-mobile-ubuntu-10.10.html [14:13] OMG ! [14:14] we're deep red [14:14] so there's one last action item left open, persia, can you close it? :-) [14:14] persia, !!! [14:14] NCommander, there are three [14:14] (see the overall chart) [14:16] [action] persia to close and/or postpone his remaining action items for 10.10 [14:16] ACTION received: persia to close and/or postpone his remaining action items for 10.10 [14:16] anything else on the charts? [14:16] what about the buglist ? [14:16] [link] http://qa.ubuntu.com/reports/team-assigned/canonical-mobile-assigned-bug-tasks.html [14:16] LINK received: http://qa.ubuntu.com/reports/team-assigned/canonical-mobile-assigned-bug-tasks.html [14:16] ogra_ac: that's separate from the burndown charts no? [14:17] k [14:17] * ogra_ac vaguely remembers an action item for NCommander that doesnt seem to have been transferred ;) [14:17] regarding the bugs :) [14:18] * NCommander doesn't :-) [14:18] [action] NCommander to unassign himself from bugs (c/o) [14:18] ACTION received: NCommander to unassign himself from bugs (c/o) [14:18] anything else on the bug list? [14:19] I guess not [14:19] [topic] Kernel Status (cooloney, mpoirier, lag) [14:19] New Topic: Kernel Status (cooloney, mpoirier, lag) [14:19] been working on b637947 all week - nothing else to report. [14:19] .. [14:19] NCommander, dont you run so fast ! [14:19] 7me was just typing :P [14:19] anyway [14:19] bug 637947, maybe? [14:19] Launchpad bug 637947 in linux-ti-omap4 (Ubuntu Maverick) "no sound devices on current ES2.0 boards" [High,Confirmed] https://launchpad.net/bugs/637947 [14:20] o/ [14:20] we're working on it [14:20] trying to get patches in today [14:20] since thats the last chance to make the release [14:21] can you guys make sure the kernel team is available for us to make uploads etc ? [14:21] anything else from the kernel side? [14:21] * Texas Instruments (ti-omap) [14:21] * PATCH : IGEPv2's 6 patches are being worked into the SRU process (OMAP3) [14:21] * PATCH : A new set of ftrace patches have been released - will integrate in Natty (OMAP3) [14:21] * PATCH : Received patch from TI that enables passing the MAC address to the kernel from u-boot [14:21] * ON GOING : B637947 Latest sound patches are available from TI - configuration problem still exists [14:21] * ON GOING : B653002 Currently under investigation - TI suspects a silicone problem [14:21] * ON GOING : B637947 Still working on the userspace ALSA or PulseAudio configuration [14:21] * FIXED : B647890 Fixed the building error [14:21] * WORKROUND: B633227 Applied patches from Nicolas to set memory 2G:2G - enabled the errata for PL310 lx20 cache controller [14:21] * MISC : "fakeroot debian/rules binary-omap" seems to be broken on Natty - investigation is required [14:22] * MISC : Some members of the Arm team received ES2.1 boards - so far it's as good as ES2.0 [14:22] .. [14:22] ah, there's lag [14:22] :D [14:22] Hi ya [14:22] yeah, we have slow network NCommander :) [14:22] lots of lag :) [14:22] lag, Natty ?!?! [14:23] lag, please stop building omap3 in natty [14:23] that either needs to go into a feature branch again or we need to swithc to linaro [14:23] Speak to mpoirier [14:23] * ogra_ac will add a spec for that [14:23] ogra_ac: that's a company decision... [14:23] ogra_ac: yes well, its not my fault you forgot to pack a high-speed interneet connection from Germany ogra_ac ! [14:23] mpoirier, no [14:24] mpoirier, we cant work that way, omap3 needs fixes at times where the mainline kernel cant be uploaded anymore ... [14:24] mpoirier, building omap3 delays the mainline kernel builds a lot [14:24] both teams suffer from it being in the core tree [14:25] who's idea was it to put it in the core tree ? [14:25] thats an unbearable situation, we either need to change it back or completely switch to linaro kernels [14:25] mpoirier, lool's with agreement from the kernel team [14:25] I suppose it was put there for a reason... [14:25] we tried it one release, its not workable [14:25] yes, "because we can" [14:26] its a test that failed badly [14:26] then let's get the concerned parties together and settle on the issue. [14:26] we would have IGEP2 support properly working if we had a feature branch with separate policies [14:26] mpoirier, thats what i said above [14:26] i'll create a spec for discussion at UDS [14:26] ogra_ac: mpoirier I think UDS would be the proper venue for this discussion TBH [14:27] ah [14:27] just dont waste time on natty branches now [14:27] :-) [14:27] anyway, can I move on? [14:27] yep [14:27] just again [14:28] [topic] QA Status (GrueMaster) [14:28] New Topic: QA Status (GrueMaster) [14:28] we need exceptoions and uploads [14:28] *today* [14:28] RC Testing went well. No major issues found, except the missing installer icon on dove images, which is now fixed. [14:28] please someone be available from the kernel team to do that [14:28] Netboot image for omap was missing modules for usb. No keyboard, no networking. Colin has worked to fix this for release. [14:29] \o/ [14:29] GrueMaster: omap3 or 4 ? when was that discovered ? [14:29] ast week [14:29] *last [14:29] omap/omap3/beagle. [14:30] we dont build netboot for omap4 [14:30] and omap3 are just a nice to have goodie [14:30] leftover from luicd [14:30] This is not a kernel issue. This was an issue with debian installer. [14:30] right, that too [14:30] The modules were not included in the netboot image. [14:31] NCommander, move if there are no other questions [14:32] [topic] ARM Porting/FTBFS status (NCommander, dyfet) [14:32] New Topic: ARM Porting/FTBFS status (NCommander, dyfet) [14:32] We (ncommander and I) discussed plt-scheme yesterday [14:32] FTBFS looks relatively happy on all architectures, not just ARM excluding openjjfk [14:32] below 100 pkgs !!! [14:32] thanks to doko !!! [14:33] we owe him a lot, he's the only one really working actively on that list atm [14:33] +1 beer to doko [14:33] +3 from me :) [14:34] :-) [14:34] [topic] ARM Image Status (ogra, NCommander) [14:34] New Topic: ARM Image Status (ogra, NCommander) [14:34] omap4 runs on panda ES2.1 !!! [14:34] * NCommander heard [14:34] WOOT! [14:34] all open RC bugs were fixed apart from sound [14:34] Its great when hardware is properly designed to be relatively compatible and sane [14:35] Dove is currently looking good, sound issue aside [14:35] not sure about omap3 (i didnt test since a while) or dove [14:35] GrueMaster, how did omap3 look last time you tested ? [14:35] Installer icon shows up where it should be, and its relatively fast and responsive [14:35] Looked good, other than the missing modules in the netboot image. [14:35] cool [14:36] Audio has the same issues across the board, though. [14:36] omap, omap4, dove. [14:36] omap and dove can have SRUs for that [14:36] omap4 will get fixes today [14:36] I think we're in very good shape at this point and I think armel+dove and possibly armel+omap can go out the door on 10.10.10 [14:36] (or workarounds) [14:36] omap4 too [14:36] hopefully [14:37] we only need the xloader patch [14:37] that should be enough, workst case all other fixes can be SRUs [14:37] ogra_ac: check thatwith davidm since thats contray to what I heard yesterday [14:37] xloader and uboot are the things we cant update [14:37] otherwise, WOO [14:37] if they are in shape omap4 is ready for 10.10.10 [14:38] davidm, ^^^^ [14:38] please agree [14:38] ogra_ac: why can't you update XLO or u-boot [14:38] NCommander, because they are not handled by packages in the image [14:38] we treat them like BIOS [14:38] ogra_ac: ah. fair enough.We could fix it, but it would be fugly [14:38] a way we inherit through using flash-kernel from debian [14:38] NCommander, lets fix it in a non ugly way [14:39] SPEC !!! [14:39] ogra_ac: right [14:39] will need good thinking through [14:39] [action] ogra + davidm to determine armel+omap4 releasability and notify the release team with the result [14:39] ACTION received: ogra + davidm to determine armel+omap4 releasability and notify the release team with the result [14:39] ++ [14:39] thanks [14:39] i'll be able to tell tonight [14:40] [topic] Any Other Business [14:40] New Topic: Any Other Business [14:40] really depends on the kernel team [14:40] ogra_ac, theree were NO kernel changes for OMAP 4? [14:40] we need an uploader for the sound fix [14:40] davidm, apart from sound ? no [14:40] davidm, es2.1 should work out of the box with the xloader changes [14:40] ogra_ac, lets have a talk later [14:40] yep [14:40] lets wait how today at TI turns out [14:41] we can say for sure by end of day [14:41] robclark is just testing the instabilities issues we saw yesterday [14:41] so soon we should know better if it works or not [14:41] but I'd say that we just need x-loader fixes [14:41] ++ [14:42] anything else left for this meeting? [14:42] Or can I close it out? [14:42] nops, hopefully we'll be on-line sooner today [14:42] activity reports !! [14:42] dont foget them :) [14:42] I did mine ;-) [14:42] rsalveti rocks [14:42] rsalveti: maybe one of you should buy a prepaid broadband solutoin and make a hotspot [14:42] (and he's the only one here) [14:42] NCommander, THATS WHAT WE USE [14:43] OOPS [14:43] yup :-) [14:43] damned caps [14:43] ogra_ac: so when you run out of bandwidth on AT&T they make you use all caps?< i didn't know that! [14:43] * NCommander runs. [14:43] anyway, about to close the meeting [14:43] going once [14:44] * ogra_ac slaps NCommander with a holiday inn pancake [14:44] mmmmm, tasty [14:44] So ogra_ac, does thisw mean you will do a status report too? [14:44] * ogra_ac slaps GrueMaster with a holiday inn pancake [14:44] * GrueMaster has bacon and will slap back. [14:45] greasy meeting ! [14:45] * NCommander notes that ogra_ac and GrueMaster should get a room to save all our visions. [14:45] anyway [14:45] NCommander, quick close the meeting [14:45] going once [14:45] twice [14:45] three times [14:45] #endmeeting [14:45] Meeting finished at 08:45. [14:45] * NCommander resets his alarm to respect the local time [14:51] mpoirier, ogra_ac: Sorry, I didn't follow; what was my decision wiht the kernel team agreement? [14:52] lool, at one point or another omap3 became part of mainstream. [14:53] since this it the time I got hired, I *think* lucide was a topic branch and was wrapped in mainstream for maverick. === chrisccoulson is now known as nosluoccsirhc [14:54] \o [14:55] lool, having omap built from the main tree is a pain for everyone [14:56] lool, so i want either a topic branch for natty again or directly switch to linaro [14:56] * ogra_ac takes further discussion to #ubuntu-arm [14:56] I think this is a large topic === nosluoccsirhc is now known as chrisccoulson [14:57] yep [15:02] pitti: hi [15:02] hello [15:03] gosh, am I chair [15:03] kees: around? [15:03] ah yes [15:03] ah, so you are [15:03] I thought it was pitti, but that's the meeting I missed [15:03] no obvious sign of Keybuk; pinged sabdfl [15:04] hello [15:04] cjwatson: sabdfl is on a conference [15:04] he asked to be skipped on the chair rotation [15:04] aha [15:04] so he might lag or not be present at all [15:04] #startmeeting [15:04] Meeting started at 09:04. The chair is cjwatson. [15:04] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [15:04] [TOPIC] Action review [15:04] New Topic: Action review [15:04] Martin Pitt to ask Martin Pool about bzr self test instructions on installed system [15:05] pitti: ? [15:05] cjwatson: yup [15:05] cjwatson: he asked, but I didn't see a reply [15:06] cjwatson: done [15:06] he replied [15:06] Kees to add bzr self test to qa-regression-testing project [15:06] and even better, they seemed to have made a lot of fixes [15:06] bzr 2.0.3 should have a fully working test suite [15:06] cjwatson: did that [15:06] or .2 even [15:06] Martin to add bzr microrelease exception to StableReleasePolicy [15:07] done [15:07] excellent [15:07] [TOPIC] Decide/document ubuntu-archive interaction with ARB packages [15:07] New Topic: Decide/document ubuntu-archive interaction with ARB packages [15:07] [LINK] https://lists.ubuntu.com/archives/technical-board/2010-September/000516.html [15:07] LINK received: https://lists.ubuntu.com/archives/technical-board/2010-September/000516.html [15:08] I don't remember whether we discussed this, or if so what the outcome was [15:08] normally, one function of the archive admins is to at least ensure legality of distribution [15:08] it's new to me, though I missed the previous meeting [15:08] which is more or less the bare minimum [15:09] this wasn't in the previous meeting; ScottK asked about it on our list, although he apologised that he wouldn't be able to make it to this meeting [15:10] so the question is whether archive admins will have responsibility for reviewing ARB packages as well as other kinds of packages? [15:10] my memory is that extras.ubuntu.com is actually a mirror of a PPA owned by the ARB [15:10] is there anyone else in a position to do it? [15:11] which would mean that ubuntu-archive wouldn't actually naturally have access to it, only the ARB [15:11] the ARB themselves? [15:11] (ScottK may or may not be aware of this) [15:11] https://wiki.ubuntu.com/PostReleaseApps/Process is not terribly clear on the matter [15:12] if it's an ARB-owned PPA, then I think the answer is simple, but the process documentation needs to be expanded to mention that [15:12] sounds straightforward enough [15:12] does anyone know the answer to that authoritatively? [15:12] presumably there's an existing archive admin checklist which could be reused? [15:12] I knew a couple of months ago ... [15:12] I don't know about the PPA implementation [15:13] https://wiki.ubuntu.com/ArchiveAdministration#NEW%20handling has various things we do [15:13] rickspencer3 is here; I could ask him if he's likely to know [15:13] I think he would [15:13] please do [15:13] ok, I'll run over [15:14] cjwatson: he doesn't quite know [15:14] he redirected to mvo [15:15] mvo: around? [15:16] [ACTION] cjwatson to ensure that documentation on nature of extras.ubuntu.com archive makes it into process docs [15:16] ACTION received: cjwatson to ensure that documentation on nature of extras.ubuntu.com archive makes it into process docs [15:16] cjwatson: maybe we need to chase this offline [15:16] I think it's clear that that's needed no matter what [15:16] OK, I'll take an action and chase it up tomorrow probably [15:16] [ACTION] cjwatson to chase up archive processing details for extras.ubuntu.com [15:16] ACTION received: cjwatson to chase up archive processing details for extras.ubuntu.com [15:16] [TOPIC] Decide on permission changes documented in LP: 174375 - Matt Zimmerman [15:16] New Topic: Decide on permission changes documented in LP: 174375 - Matt Zimmerman [15:17] I already acked that bug both in person and in LP [15:17] bdmurray sent email to the mailing list and didn't get enough of a response to feel comfortable moving forward [15:17] I'm +1 on it [15:17] maybe we can just do a quick vote assuming folks have read it? [15:17] there seems to be slight pushback from LP over the split in responsibilities between spec management and release management, but I think that's the essence of the change we need and so we can't give ground there [15:18] anyone feel they need a few minutes to read over bug 174375? [15:18] Launchpad bug 174375 in Launchpad Registry "Distribution drivers permissions may need redesign" [Low,Triaged] https://launchpad.net/bugs/174375 [15:18] I've read it a few times now :) [15:18] https://lists.ubuntu.com/archives/technical-board/2010-August/000426.html [15:18] * pitti reads to refresh memory [15:19] is brian's proposal [15:19] which is also in the bug at https://bugs.edge.launchpad.net/launchpad-registry/+bug/174375/comments/4 [15:19] Launchpad bug 174375 in Launchpad Registry "Distribution drivers permissions may need redesign" [Low,Triaged] [15:20] mdz: yes, I'm around [15:21] mvo: the question earlier was whether extras.ubuntu.com is a mirror of a PPA owned by the ARB [15:21] mdz: yes, that is the case [15:21] mvo: thanks [15:21] yw [15:22] mvo: thank you, looks like that answers the question; I'll follow up with ScottK et al [15:22] thanks cjwatson [15:22] pitti: refreshed? [15:22] mdz: yes [15:23] [VOTE] Approve Brian's proposal for redesign of distribution driver permissions [15:23] Please vote on: Approve Brian's proposal for redesign of distribution driver permissions. [15:23] Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0 to MootBot [15:23] E.g. /msg MootBot +1 #ubuntu-meeting [15:23] +1 [15:23] +1 received from cjwatson. 1 for, 0 against. 0 have abstained. Count is now 1 [15:23] +1 [15:23] +1 received from kees. 2 for, 0 against. 0 have abstained. Count is now 2 [15:23] I think bug targetting needs to be more open than just release-managers; the rest looks fairly okay [15:23] if we understand "ubuntu drivers" as "team leads, tech leads, etc" [15:24] +1 [15:24] +1 received from mdz. 3 for, 0 against. 0 have abstained. Count is now 3 [15:24] under that assumption, [15:24] +1 [15:24] +1 received from pitti. 4 for, 0 against. 0 have abstained. Count is now 4 [15:24] pitti: I'm not too concerned about bug targeting, as long as we can control it independently from spec handling [15:24] (FAOD that doesn't affect my vote either way) [15:24] cjwatson: *nod* [15:24] yeah, the real change is making it a separate slot [15:24] [ENDVOTE] [15:24] Final result is 4 for, 0 against. 0 abstained. Total: 4 [15:24] I'll go back to Brian and let him know we acked it, thanks [15:24] separating blueprints and bugs is the main goal here indeed [15:24] targeting: Brian says "should be fixed as long as it doesn't exclude uploaders" which is OK by me [15:25] right [15:25] [TOPIC] Scan the mailing list archive for anything we missed [15:25] New Topic: Scan the mailing list archive for anything we missed [15:25] the only thing I see is: is the security team still awaiting confirmation on what to do with chromium, or is that settled? [15:25] (sorry, I appear to be a stateless machine today) [15:26] cjwatson: I think it's understood; we're just waiting for a final proposal from fta [15:26] I think there is a consensus there [15:26] right [15:26] September's thread from https://lists.ubuntu.com/archives/technical-board/2010-September/000501.html is sort of ambiguous as to what to do with the waiting period [15:26] basically, throw out the upstream updates pretty much blindly [15:26] but it's not mature enough yet for main [15:27] absolutely agreed [15:27] I think the waiting period needs to be dropped, but at the same time, debian/ changes should be limited [15:27] kees: well, perhaps dropped -> shortened [15:27] * kees nods [15:27] it should at least build and get a coarse upgrade/install test [15:28] right, but I call that "testing" :) [15:28] we can drop the 7 days maturing period, but please let's not drop -proposed and at least quick verification [15:28] yup [15:28] +2 [15:29] is -proposed required? [15:30] as kees said, we require testing [15:30] uploading the stuff straight to -updates is way too risky IMHO [15:30] it won't ever blindly be uploaded [15:30] if it buids on amd64 and fails on i386, we create uninstallability, etc. [15:30] eg, I'd run it through qrt [15:30] pitti: sure, we test both i386 and amd64. it is part of the testing procedures [15:31] (that is part of the security team's checklist) [15:31] sounds good [15:31] I guess what I am getting at is this [15:32] I noticed yesterday that we are showing chromium as a supported browser in the maverick livecd slideshow [15:32] !? [15:32] yes, I was surprised too... [15:32] well, we'll keep it up to date either way [15:33] but the security team will just need to treat it like flashplugin-nonfree-- it is universe, but we know a ton of people use it [15:33] that seems realistic, yes [15:33] so we test it ourselves in a similar manner [15:33] ie, with all our checklists, etc, etc [15:33] i. e. it's not an OMGincident if it suddenly breaks with a particular web page [15:34] correct [15:34] and no USN [15:34] (chromiums seems to do that a lot, at least on our arm systems) [15:34] like I mentioned, we have a qrt script which should catch any really huge issues [15:35] (js, ssl, redirects, images, flash, java, etc, etc...) [15:35] jdstrand: wow, so you call it on different web page types and check that it doesn't "Aw, snap!"? nice [15:35] I'm happy to do all the pocket copying if it is required, but if we have the standing exception, and we treat it this way, I'm not sure it is [15:36] pitti: yes [15:36] it is semi-automatic [15:36] it seems to have worked pretty well with the last handful of updates [15:36] at least from my POV [15:36] ie, it requires you to be looking at the test as it runs and close the browser, but it leads you through repeatable tests [15:36] yes [15:37] ok, anything further on this? [15:37] so what's remaining on this? [15:37] standing SRU exception? [15:38] it seems to be pretty much without alternative [15:38] yeah; should we vote on it? [15:38] I haven't heard any disagreement [15:38] yes. iirc fta is supposed to write something up formally. he isn't sure why that is required since it has been discussed at length, but I can try to prod him [15:38] without requiring the 7 days testing period, too [15:38] but why don't we vote on fta's proposal [15:38] when it arrives [15:38] *nod* [15:39] let's move on for now, then [15:39]