=== SergioMeneses_ is now known as SergioMeneses === lukjad is now known as Guest655 === lan3y is now known as Laney === mc44_ is now known as mc44 === rodrigo__ is now known as rodrigo_ === Mohan_chml is now known as Guest46187 === Guest46187 is now known as Mohan_chml === Claudinux_ is now known as Claudinux === freeflying_ is now known as freeflying [12:58] #startmeeting [12:58] Meeting started at 06:58. The chair is NCommander. [12:58] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [12:58] bah [12:58] you're to early [12:59] NCommander: and the meeting date is wrong [12:59] that too [12:59] you created it as 1009 [12:59] unless you think the release is tomorrow, you're wrong [12:59] ugh [12:59] :-) [12:59] hehe [13:00] davidm: I'm here :-P, no need to call :-P [13:00] Yep, just saw that, had phone to ear [13:00] I'm just waiting for GrueMaster to rise [13:01] [link] https://wiki.ubuntu.com/MobileTeam/Meeting/2010/20101109 [13:01] LINK received: https://wiki.ubuntu.com/MobileTeam/Meeting/2010/20101109 [13:01] hmpf, note to self: starting update-manager right before a meeting isnt a clever idea [13:02] There are no action items or special items from the last meeting [13:02] when was that anyway [13:02] ogra_ac: the 2nd, but only davidm and GrueMaster was there [13:02] Last week [13:02] most of us were in transit for something [13:03] I ran it since no one besides Gruemaster showed up [13:03] And I like fast meetings [13:03] Speaking of which..... [13:03] [topic] Standing Itmes [13:03] New Topic: Standing Itmes [13:03] [link] http://people.canonical.com/~pitti/workitems/natty/canonical-mobile.html [13:03] LINK received: http://people.canonical.com/~pitti/workitems/natty/canonical-mobile.html [13:04] [link] http://people.canonical.com/~pitti/workitems/natty/canonical-mobile-natty-alpha-1.html [13:04] LINK received: http://people.canonical.com/~pitti/workitems/natty/canonical-mobile-natty-alpha-1.html [13:04] All my specs expect spice seeds have their work items in properly. We don't have any notes for spice ATM (waiting for IS to post the audio logs of UDS to recreate them) [13:05] once those are done, I'll write that spec, and get the work items up [13:05] I'm finishing reviewing and finalizing the specs today [13:05] Ugh [13:05] argh [13:06] It looks like since my specs didn't make it to approved, they weren't counted togethers the workitem tracker [13:06] hey [13:06] no hurry [13:06] spec deadline is the 18th [13:06] so the trendline is completely screwed up. again. [13:06] * NCommander bangs his head on the desk [13:06] also the WI tracker has to be changed a lot [13:06] but we all want to do some "real" work soon :-) [13:06] sure, just go ahead [13:07] [action] NCommander to track down why his specs aren't on the tracker and to have that fixed [13:07] still though, the tracker points to the wrong team name etc [13:07] ACTION received: NCommander to track down why his specs aren't on the tracker and to have that fixed [13:07] NCommander, leave that to me [13:07] [action] ogra to take previous action [13:07] ACTION received: ogra to take previous action [13:07] the tracker has to be rewriotten [13:07] we are not mobile anymore etc [13:07] i haver to work with pitti on that [13:07] *have [13:07] true [13:08] nomenclature changed too [13:08] right [13:08] its on my TODO for this week [13:08] on, let's move on [13:08] will also change the ml? [13:08] [topic] Kernel Status (cooloney, mpoirier, lag) [13:08] New Topic: Kernel Status (cooloney, mpoirier, lag) [13:08] no idea, up to davidm [13:08] NCommander, we dont have kernel guys atm [13:08] it'd be better to have ubuntu-arm instead of mobile, so we avoid questions regarding eeepc :-) [13:08] pointless topic [13:08] until they start shipping arm cpus [13:09] hehe [13:09] cooloney is still with you [13:09] k [13:09] rsalveti, well, as i said, up to davidm [13:09] sure :-) [13:09] GrueMaster: any point to doing QA status? [13:09] lag, true, but not around atm [13:09] * NCommander guesses not [13:09] Nope, I believe he's in Lex [13:09] cooloney did some work this week [13:09] lets do a short spec overview [13:09] who has what etc [13:09] [topic] Specification Overview [13:09] New Topic: Specification Overview [13:09] * NCommander is a fan of that [13:09] No QA status at this time. [13:10] for anything else the topics dont suit well [13:10] oh, and probably discuss A1 [13:10] I currently have improved ARM subarch support + userland subarch support, and spice seeds once we get the session notes recovered and the spec writen. [13:10] https://blueprints.edge.launchpad.net/ubuntu/+spec/other-arm-n-public-panda-ppa-build-cluster [13:10] https://blueprints.edge.launchpad.net/ubuntu/+spec/appdevs-arm-n-minimal-preinstalled-developer-images [13:10] https://blueprints.edge.launchpad.net/ubuntu/+spec/other-arm-n-jasper-rewrite [13:11] https://blueprints.edge.launchpad.net/ubuntu/+spec/other-arm-n-arm-thin-clients [13:11] ogra, the image for the PPA build system, will you get that done before A1 or is that an A2 task for you? [13:11] these are my four [13:11] davidm, A1 [13:11] OK thanks' [13:11] https://wiki.ubuntu.com/NattyReleaseSchedule [13:11] for anyone who doesnt have it [13:12] * ogra waits for more spec links [13:13] https://blueprints.edge.launchpad.net/ubuntu/+spec/multimedia-arm-gles-in-ubuntu [13:13] https://blueprints.edge.launchpad.net/ubuntu/+spec/other-arm-n-handle-core-boot-files-update [13:13] https://blueprints.launchpad.net/ubuntu/+spec/multimedia-arm-n-set-top-box [13:13] https://blueprints.edge.launchpad.net/ubuntu/+spec/packageselection-arm-n-more-stable-vm-solution-for-arm [13:13] my four [13:13] * ogra has some items on the set-top-box one [13:13] iirc [13:13] https://blueprints.edge.launchpad.net/ubuntu/+spec/other-arm-n-userland-subarch-detection [13:13] https://blueprints.edge.launchpad.net/ubuntu/+spec/other-arm-natty-improved-subarch-detection [13:13] we'll all end up having work items in different blueprints :-) [13:14] yep [13:14] motre than last time [13:14] which is good :) [13:14] https://blueprints.edge.launchpad.net/ubuntu/+spec/other-arm-n-seed-spices [13:14] https://blueprints.launchpad.net/ubuntu/+spec/other-arm-n-customcheckboxtests [13:14] yup :-) [13:14] is persia with us ? [13:14] ogra, I have pretty much taken over panda-ppa-build-cluster. But any assistance with wiki spec gladly accepted ;-P [13:14] davidm, i'll do it :) [13:15] rsalveti, I added the paste notes to the botton [13:15] davidm: cool, was going to do that, but didn't know if I should put at the wiki or the blueprint itself [13:15] thanks anyway [13:16] I put it at the bottom of the wiki for now [13:16] Seemed to be a good place [13:16] persia, ?? [13:16] -ENOPERSIA [13:16] rsalveti, the blueprint should just have WIs [13:16] all the rest goes into the wiki [13:16] ok, because I saw many blueprints with notes in it [13:16] mostly linaro ones [13:17] well, for dumping the notes the whiteboard is an easy place [13:17] but during cleanup and drafting it should be moved in the proper place [13:17] ok [13:18] also note that linaro might just handle it differently [13:18] yeah [13:18] better to look at ubuntu specs ;) [13:18] !info python-gtk2 [13:18] python-gtk2 (source: pygtk): Python bindings for the GTK+ widget set. In component main, is optional. Version 2.21.0-0ubuntu1 (maverick), package size 721 kB, installed size 2628 kB [13:18] err, sorry [13:18] anyone else got any other specs to post? [13:19] apart from persias we should have all [13:19] * NCommander has a pretty good idea at this point who's doing what for the forseable future [13:19] then I'm moving on unless someone else has something [13:19] we will get a new employee soon [13:19] please think about WIs he can take [13:19] * NCommander has nothing for FTBFS status, and there are no images yet so ... [13:19] from your specs [13:19] what he's good at? [13:19] images failed today, havent checked why [13:19] ogra: oh, crontabs are running? [13:20] Do we still want omap & dove images to build? [13:20] rsalveti, everything but dont overload him ;) [13:20] * NCommander didn't see a build failure image this morning [13:20] GrueMaster, omap -> yes, dove -> no i guess [13:20] ogra: :-) [13:20] NCommander, you should have mail [13:20] GrueMaster: Dove is dead. omap3 is in the hands in Ubuntu ARM, and omap4 is maintained by Canonical [13:20] davidm, can you confirm ? no more dove in natty, right ? [13:21] correct no more dove in natty [13:21] We'll probably kickstart it again mid February-March. [13:21] for reference: https://lists.ubuntu.com/archives/ubuntu-devel/2010-November/031952.html [13:22] that applies to omap3 currently [13:22] GrueMaster: don't make me come and stab you [13:22] waiting for solutions from kernel and linaro teams [13:22] GrueMaster, I doubt it, the kernel we have access to is too far behind for natty [13:23] we might have a slight prob for A1 btw, we need livecd-rootfs to work for the preinstalled ones and i think cjwatson wont focus on live images (usually he looks only at alternate for A1) [13:23] ogra: I'll keep on eye on it for A1 [13:23] so that might need some heavy lifting on our side [13:24] [action] NCommander to supervise pre-installed omap4 images for Alpha 1 [13:24] to have the deps and seeds right [13:24] ACTION received: NCommander to supervise pre-installed omap4 images for Alpha 1 [13:24] ^- standing item until Alpha 1 [13:24] as well as ftbfs [13:24] NCommander, thanks [13:24] the ftbfs list looks awful atm [13:24] ogra: I've got access to GrueMaster's pandas, so I can do TI work again. [13:24] though thats mainly kde/QT related [13:24] ogra: not as bad as in cycles past TBH [13:25] well, but again qreal issues as far as i can see [13:25] the always reoccuring issue [13:25] NCommander, how about finally applying the upstream fix to it ? [13:25] ogra: the one we can't fix without breaking the ABI of Qt :-/ [13:25] where are qreal issues? [13:25] davidm, ^^^ [13:25] ogra: upstream won't move until Qt5 [13:26] any words on that ? [13:26] Riddell, armel as usual [13:26] Riddell, we have that every release [13:26] NCommander, I thought upstream wnated the change?? [13:26] ogra: sometime in the future. Not even Nokia knows when based off feedback from last Akademy [13:26] davidm: yeah, but they can't until they break the ABI in general [13:26] well, they asked for it at the brussels UDS [13:26] ogra: Linaro asked for it [13:26] and its really a non issue since its armel only [13:26] NCommander, can you please verify that upstream does not want it now? [13:26] NCommander, no [13:27] NCommander, i was at the discussion between asac and upstream [13:27] It is really creating havoc here [13:27] ogra: I haven't seen any new qreal issues. there's the issue with CXXFLAGS += -Wa,-mimplicit-it=thumb [13:27] davidm: we can not break it down here independently of upstream. If upstream wants it broken, they need to fix it upstream, then we get it via normal updates [13:27] Riddell, hmm, that might be a new one, usually NCommander puts in a few weeks to adjust his armel patches per app though [13:28] which costs a lot of time [13:28] ogra: that's a toolchian issue because we had a patch in previously to make that the default [13:28] and upstream aksed to just switch TQ on armel for fixing that upstream [13:28] ogra: doko kicked it out since upstream rejected it. [13:28] * NCommander had a discussion with doko on this very issue during UDS. [13:28] NCommander, can you please verify with upstream if they want/will take the change. [13:28] NCommander, on the upstream QT qreal changes ? [13:29] * ogra wonders how thats related to doko [13:29] the CXXFLAGS is related to doko [13:29] right, but thats fixed [13:29] ogra: CXXFLAGS was doko, and no it wasn't, it was worked around. [13:30] * ogra doesnt really care about stuff that has a fix/workaround already [13:30] most packages still fail to build on arm because of the CXXFLAGS issue, been waiting for doko to show up to discuss it [13:30] what i care about is NCommander wasting workdays on the same issue each release [13:30] adjusting the same patches every round [13:31] while upstream asked us to fix it with an upstream patch [13:31] ogra: and we can't fix it upstream [13:31] we can [13:31] I'm not repeating this disucssion. We do it every cycle [13:31] just patch QT properly and be done [13:31] ogra: how do you suggest we sanely break Qt's ABI [13:32] I'm not doing it [13:32] we only break it on armel [13:32] and given that we rebuild the whole distro, thats a non issue [13:33] I am *NOT* having this discussion again [13:33] I will post the links to every meeting we have discusssed it [13:33] Because its the same argument going around [13:33] And I have no interest wasting meeting time discussing it again when nothing has changed [13:34] * ogra prefers wasting 1h meeting time to two manweeks of work [13:35] i still fail to see the reason to not do it [13:36] Next please [13:36] [topic] Any Other Business [13:36] New Topic: Any Other Business [13:36] Going once [13:36] Going twice [13:36] Going three times [13:37] #endmeeting [13:37] Meeting finished at 07:37. === oubiwann is now known as oubiwann-away === jdstrand_ is now known as jdstrand === oubiwann-away is now known as oubiwann === dholbach_ is now known as dholbach === apw` is now known as apw === SuperHark is now known as MichealH === yofel_ is now known as yofel [17:00] * apw limps in [17:00] * ogasawara waves [17:00] o/ [17:00] * cking here o/ [17:00] apw, broken foot? [17:00] * smb /O\ [17:00] * ericm|ubuntu here o/ [17:00] \o [17:00] * ogra_ac lurks [17:00] \0/ [17:01] hi [17:01] yup [17:01] here! [17:01] #startmeeting [17:01] Meeting started at 11:01. The chair is bjf. [17:01] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [17:01] [LINK] https://wiki.ubuntu.com/KernelTeam/Meeting [17:01] LINK received: https://wiki.ubuntu.com/KernelTeam/Meeting [17:01] [LINK] https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Maverick [17:01] LINK received: https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Maverick [17:01] [TOPIC] ARM Status (lag) [17:01] New Topic: ARM Status (lag) [17:01] ericm|ubuntu: you first, lady [17:01] cooloney, ^? [17:02] heh [17:02] no problem, simple word - nothing going on with Marvell dove [17:02] they've shipped their LSP 5.3.6, I'll talk with tgardner offline for that [17:03] # [17:03] # NOTE: '..' indicates that you are finished with your input. [17:03] # [17:03] for ti-omap4, we just fixed a config issue bug 672635 [17:03] Launchpad bug 672635 in linux-ti-omap4 (Ubuntu) "enable CONFIG_SCSI_MULTI_LUN" [Medium,Confirmed] https://launchpad.net/bugs/672635 [17:03] tim pushed and uploaded [17:03] that's for maverick [17:04] cooloney, is that it? [17:04] and some status from mpoirier [17:04] * Texas Instruments (ti-omap) [17:04] * PATCH : PowerSGX patch: [17:04] .Spent a lot of time looking at powerSGX [17:04] .Studied 3 implementation: Android, Meego and rcn-ee [17:04] .The Meego patch was folded in linaro-linux-2.6.35 but got rejected -> not upstreamable [17:04] .To be accepted, the patch would have to be nursed through the iteration process -> this is a full time assignment [17:04] .Going from ubuntu to linaro for kernel maintenance mandate that submitted patches be upstreamable [17:05] for me, i'm working some upstream OMAP DSS2 patches. that's not for our ubuntu release [17:06] yeah, that's it [17:06] i'm done [17:06] .. ? [17:06] [TOPIC] Release Metrics (JFo) [17:06] New Topic: Release Metrics (JFo) [17:06] ENO-JFO [17:07] ack [17:07] [TOPIC] Blueprints: Kernel Configuration Review (apw) [17:07] [LINK] https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-config-review [17:07] New Topic: Blueprints: Kernel Configuration Review (apw) [17:07] LINK received: https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-config-review [17:07] Configuration changes are defined and approved. Work has not yet started on applying these, should hit before natty-alpha-1. [17:07] .. [17:07] [TOPIC] Blueprints: Enhancements to the firmware test suite (cking) [17:07] [LINK] https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-firmware-test-suite-enhancements [17:07] New Topic: Blueprints: Enhancements to the firmware test suite (cking) [17:07] LINK received: https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-firmware-test-suite-enhancements [17:07] Changes to fwts (natty development branch): [17:07] * Added more intelligence in backlight issues found in klog [17:07] * add --show-tests-full option [17:07] * add --lp-tags to print out LP tags when scanning klog errors [17:07] * make -p (show progress) default [17:08] * add -q, --quiet option [17:08] * add --dumpfile to load tables from acpidump and fwts --dump output [17:08] * prototyped ACPI method execution for sanity checks and mutex state checks [17:08] .. [17:08] [TOPIC] Blueprints: Handling of Deviations from Standard Kernels (smb) [17:08] [LINK] https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-stable-frankenkernel-maintenance [17:08] New Topic: Blueprints: Handling of Deviations from Standard Kernels (smb) [17:08] LINK received: https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-stable-frankenkernel-maintenance [17:08] Err [17:08] :-) [17:09] Not much to add for the moment [17:09] Working on the announcement scripts [17:09] And I guess someone needs to do the documentation at some point... [17:09] .. [17:10] [TOPIC] Blueprints: Review of the Stable Maintenance Process (sconklin) [17:10] [LINK] https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-stable-process-review [17:10] New Topic: Blueprints: Review of the Stable Maintenance Process (sconklin) [17:10] LINK received: https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-stable-process-review [17:10] During UDS, discussions were held which resulted in the adoption of a new process for release of stable kernel updates. Details about why this was needed and how it will be implemented have been committed to the Ubuntu wiki here: [17:10] https://wiki.ubuntu.com/Kernel/StableReleaseCadence [17:10] It looks like the first official cycle may start on Nov 18th, but this is still indiscussion [17:10] .. [17:10] sconklin, any progress on the testing front? [17:10] No [17:11] how can we start a cycle without a prototype of the process? [17:11] maybe we should invite someone from testing to this meeting? [17:11] skaet, any update on the testing ? [17:11] tgardner: good question. We're awaiting our first information from the people responsible for testing [17:11] hmm [17:12] bjf, i think we need an action on steve to get one of them here for the next meeting till its resolved [17:12] I'd sent email yesterday poking hw cert about the testing. They're still trying to run a full smoke test of the kernel in -proposed to see how long it takes. [17:12] * cking wonders why he pulled the finger out on saturday to do some testing when we are blocked en-route by process [17:12] * apw wonders why cking did that when the deadline wathursday [17:12] [ACTION] sconklin to make sure someone from testing attends the weekly kernel meeting :-) [17:12] ACTION received: sconklin to make sure someone from testing attends the weekly kernel meeting :-) [17:13] .. [17:13] we're going to slip the Thursday requirement for verification testing [17:13] why so ? [17:14] apw, without the full process in place should we go ahead and revert patches? [17:14] (i suspect this is a #u-k discussion) [17:14] Because we have not officially begun the new cycle, and have no definition of the testing process. [17:14] lets take this offline then .. [17:14] .. [17:14] sconklin, well, you have announced that we're gonna do it on a certain date. [17:15] tgardner: that's correct, an I can just as easily announce that we're slipping [17:15] apw, i thought thats what this meeting was about / for (this kind of discussion) [17:15] oh ok, then i think if you start by slipping the verification revert [17:15] then people will think they can always assume you will [17:15] sets a bad precident [17:15] That announcement was predicated on the assurance that we would have testing results by the end of last week [17:15] apw, sconklin - haven't got an update - but not sure I'm on the official list to get one. [17:15] the longer we soak with only the patches we are going to release with the more [17:16] happy [sic] the SRU team will be [17:16] skaet, if your not on the "official" list who would be? [17:16] sconklin, I think we should go ahead and prototype that part of the process at least, despite not being able to get official testing. [17:16] I also have no problem dropping patches as announced, but we are feeling the process out [17:16] sconklin, testing is meant to occur in the second week after the reversions, right? so testing will occur after this thursday for the official release [17:16] bjf, sconklin is who victorp is communicating with. [17:16] only the patches that are not tested? [17:17] cking, right the un 'verified' bugs [17:17] cool [17:17] ok, so as announced, we wi can drop all unverified patches on Friday, and then we're in a straight-up testing hold. [17:17] sconklin, ack [17:17] works for me [17:17] and if testing fails to occur, we are effectively roadblocked? [17:17] cking, we are in a bad place. [17:17] so no changes can be made to the repos until we've reverted patches? [17:18] cking, we're no worse off then we were before, e.g., crowd sourcing [17:18] bjf: effectively, yes. [17:18] bjf, That probably is done on a side branch [17:18] smb, what good does it do to do them on a side branch? [17:18] agreed, we just need to choose a naming convention for the "next" branch [17:18] and we will have a merge window for it [17:19] I was thinking along starting a branch from the upload and revert [17:19] then that can be merged back to master [17:19] no reverts, we will remove the patches and force-update the master branch [17:19] how about sru-candidate? [17:19] sconklin, I would not do that, but its your decision [17:20] skaet, in that week we are essentially on hold waiting on verification [17:20] Too much clutter, and I'm afraid it will break all the tools which parse changelogs [17:20] sconklin, if we revert, we can comment why it was reverted (failure to verify) [17:20] bjf: that will be documented in the bug [17:21] also, if we are adding patches to a "next" branch, do we do a "pre-proposed" from that? [17:21] apw, yah - and from yesterday's probing, it doesn't seem clear on the verification side the handoff between the cert and QA for running tests. [17:21] can anyone tell me how many tools there are which parse kernel changlelogs, in and out of the kernel team? [17:21] what about the debian changelog [17:21] won't that show the patches going in only if you do not revert, even though they are not in the tree ? [17:21] sconklin, I just fear that you are causing pain by force-updating and rewriting a sort of pushed tree [17:22] we regenerate the changelog. We simply make the patches dissappear. [17:22] sconklin, i am not sure the archive admins will accept that, as it does not reflect correct history [17:22] apw, I think at the moment it might be a case where apply and revert are done in two uploads [17:22] The basic assumption I'm operating under is that anything after a tag is mutable [17:22] apw, That is probably not handled as you would expect in the changelog [17:22] right, which this is by definition [17:23] sconklin, But you would do that if you remove patches from before [17:23] wheras revert does not change the past [17:23] smb: do what? [17:23] correct, the patches you are "disappearing" have been "tagged" [17:23] sconklin, you sounded like using rebase -i to remove patches [17:23] sconklin, lets take this offline. its a process issue thats not really relevant to the overall testing issue [17:23] as part of a -proposed upload [17:24] smb: but we have numerous tools which parse the changelog, sch as those used by archive admins, and those tools do not understand reverts as far as I know [17:24] sconklin, a revert is just another patch on top [17:24] they do not need to be understood per-see [17:24] I understand that, but it leaves the original patch and the buglink [17:24] we might wish to drop the bug link ... [17:25] sconklin, apw Lets discuss this later on [17:25] ack [17:25] .. [17:25] yes, we'll tackle this later [17:25] .. [17:25] smb, apw, tgardner, sconklin, when and where because I want to be there [17:25] #ubuntu-kernel [17:26] I'll be there too. [17:26] [TOPIC] Blueprints: Ubuntu Kernel Delta Review (apw) [17:26] [LINK] https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-ubuntu-delta-review [17:26]