[12:58] <NCommander> #startmeeting
[12:58] <MootBot> Meeting started at 06:58. The chair is NCommander.
[12:58] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[12:58] <ogra_ac> bah
[12:58] <ogra_ac> you're to early
[12:59] <rsalveti> NCommander: and the meeting date is wrong
[12:59] <ogra_ac> that too
[12:59] <rsalveti> you created it as 1009
[12:59] <rsalveti> unless you think the release is tomorrow, you're wrong
[12:59] <NCommander> ugh
[12:59] <rsalveti> :-)
[12:59] <ogra_ac> hehe
[13:00] <NCommander> davidm: I'm here :-P, no need to call :-P
[13:00] <davidm> Yep, just saw that, had phone to ear
[13:00] <NCommander> I'm just waiting for GrueMaster to rise
[13:01] <NCommander> [link] https://wiki.ubuntu.com/MobileTeam/Meeting/2010/20101109
[13:01] <MootBot> LINK received:  https://wiki.ubuntu.com/MobileTeam/Meeting/2010/20101109
[13:01] <ogra_ac> hmpf, note to self: starting update-manager right before a meeting isnt a clever idea
[13:02] <NCommander> There are no action items or special items from the last meeting
[13:02] <ogra_ac> when was that anyway
[13:02] <NCommander> ogra_ac: the 2nd, but only davidm and GrueMaster was there
[13:02] <davidm> Last week
[13:02] <NCommander> most of us were in transit for something
[13:03] <davidm> I ran it since no one besides Gruemaster showed up
[13:03] <davidm> And I like fast meetings
[13:03] <davidm> Speaking of which.....
[13:03] <NCommander> [topic] Standing Itmes
[13:03] <MootBot> New Topic:  Standing Itmes
[13:03] <NCommander> [link] http://people.canonical.com/~pitti/workitems/natty/canonical-mobile.html
[13:03] <MootBot> LINK received:  http://people.canonical.com/~pitti/workitems/natty/canonical-mobile.html
[13:04] <NCommander> [link] http://people.canonical.com/~pitti/workitems/natty/canonical-mobile-natty-alpha-1.html
[13:04] <MootBot> LINK received:  http://people.canonical.com/~pitti/workitems/natty/canonical-mobile-natty-alpha-1.html
[13:04] <NCommander> 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] <NCommander> once those are done, I'll write that spec, and get the work items up
[13:05] <rsalveti> I'm finishing reviewing and finalizing the specs today
[13:05] <NCommander> Ugh
[13:05] <NCommander> argh
[13:06] <NCommander> It looks like since my specs didn't make it to approved, they weren't counted togethers the workitem tracker
[13:06] <ogra> hey
[13:06] <ogra> no hurry
[13:06] <ogra> spec deadline is the 18th
[13:06] <NCommander> so the trendline is completely screwed up. again.
[13:06]  * NCommander bangs his head on the desk
[13:06] <ogra> also the WI tracker has to be changed a lot
[13:06] <rsalveti> but we all want to do some "real" work soon :-)
[13:06] <ogra> sure, just go ahead
[13:07] <NCommander> [action] NCommander to track down why his specs aren't on the tracker and to have that fixed
[13:07] <ogra> still though, the tracker points to the wrong team name etc
[13:07] <MootBot> ACTION received:  NCommander to track down why his specs aren't on the tracker and to have that fixed
[13:07] <ogra> NCommander, leave that to me
[13:07] <NCommander> [action] ogra to take previous action
[13:07] <MootBot> ACTION received:  ogra to take previous action
[13:07] <ogra> the tracker has to be rewriotten
[13:07] <ogra> we are not mobile anymore etc
[13:07] <ogra> i haver to work with pitti on that
[13:07] <ogra> *have
[13:07] <rsalveti> true
[13:08] <ogra> nomenclature changed too
[13:08] <NCommander> right
[13:08] <ogra> its on my TODO for this week
[13:08] <NCommander> on, let's move on
[13:08] <rsalveti> will also change the ml?
[13:08] <NCommander> [topic] Kernel Status (cooloney, mpoirier, lag)
[13:08] <MootBot> New Topic:  Kernel Status (cooloney, mpoirier, lag)
[13:08] <ogra> no idea, up to davidm
[13:08] <ogra> NCommander, we dont have kernel guys atm
[13:08] <rsalveti> it'd be better to have ubuntu-arm instead of mobile, so we avoid questions regarding eeepc :-)
[13:08] <ogra> pointless topic
[13:08] <rsalveti> until they start shipping arm cpus
[13:09] <ogra> hehe
[13:09] <lag> cooloney is still with you
[13:09] <NCommander> k
[13:09] <ogra> rsalveti, well, as i said, up to davidm
[13:09] <rsalveti> sure :-)
[13:09] <NCommander> GrueMaster: any point to doing QA status?
[13:09] <ogra> lag, true, but not around atm
[13:09]  * NCommander guesses not
[13:09] <lag> Nope, I believe he's in Lex
[13:09] <rsalveti> cooloney did some work this week
[13:09] <ogra> lets do a short spec overview
[13:09] <ogra> who has what etc
[13:09] <NCommander> [topic] Specification Overview
[13:09] <MootBot> New Topic:  Specification Overview
[13:09]  * NCommander is a fan of that
[13:09] <GrueMaster> No QA status at this time.
[13:10] <ogra> for anything else the topics dont suit well
[13:10] <ogra> oh, and probably discuss A1
[13:10] <NCommander> 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] <ogra> https://blueprints.edge.launchpad.net/ubuntu/+spec/other-arm-n-public-panda-ppa-build-cluster
[13:10] <ogra> https://blueprints.edge.launchpad.net/ubuntu/+spec/appdevs-arm-n-minimal-preinstalled-developer-images
[13:10] <ogra> https://blueprints.edge.launchpad.net/ubuntu/+spec/other-arm-n-jasper-rewrite
[13:11] <ogra> https://blueprints.edge.launchpad.net/ubuntu/+spec/other-arm-n-arm-thin-clients
[13:11] <davidm> 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] <ogra> these are my four
[13:11] <ogra> davidm, A1
[13:11] <davidm> OK thanks'
[13:11] <ogra> https://wiki.ubuntu.com/NattyReleaseSchedule
[13:11] <ogra> for anyone who doesnt have it
[13:12]  * ogra waits for more spec links 
[13:13] <rsalveti> https://blueprints.edge.launchpad.net/ubuntu/+spec/multimedia-arm-gles-in-ubuntu
[13:13] <rsalveti> https://blueprints.edge.launchpad.net/ubuntu/+spec/other-arm-n-handle-core-boot-files-update
[13:13] <rsalveti> https://blueprints.launchpad.net/ubuntu/+spec/multimedia-arm-n-set-top-box
[13:13] <rsalveti> https://blueprints.edge.launchpad.net/ubuntu/+spec/packageselection-arm-n-more-stable-vm-solution-for-arm
[13:13] <rsalveti> my four
[13:13]  * ogra has some items on the set-top-box one
[13:13] <ogra> iirc
[13:13] <NCommander> https://blueprints.edge.launchpad.net/ubuntu/+spec/other-arm-n-userland-subarch-detection
[13:13] <NCommander> https://blueprints.edge.launchpad.net/ubuntu/+spec/other-arm-natty-improved-subarch-detection
[13:13] <rsalveti> we'll all end up having work items in different blueprints :-)
[13:14] <ogra> yep
[13:14] <ogra> motre than last time
[13:14] <ogra> which is good :)
[13:14] <NCommander> https://blueprints.edge.launchpad.net/ubuntu/+spec/other-arm-n-seed-spices
[13:14] <GrueMaster> https://blueprints.launchpad.net/ubuntu/+spec/other-arm-n-customcheckboxtests
[13:14] <rsalveti> yup :-)
[13:14] <ogra> is persia with us ?
[13:14] <davidm> ogra, I have pretty much taken over panda-ppa-build-cluster.   But any assistance with wiki spec gladly accepted ;-P
[13:14] <ogra> davidm, i'll do it :)
[13:15] <davidm> rsalveti, I added the paste notes to the botton
[13:15] <rsalveti> davidm: cool, was going to do that, but didn't know if I should put at the wiki or the blueprint itself
[13:15] <rsalveti> thanks anyway
[13:16] <davidm> I put it at the bottom of the wiki for now
[13:16] <davidm> Seemed to be a good place
[13:16] <davidm> persia, ??
[13:16] <NCommander> -ENOPERSIA
[13:16] <ogra> rsalveti, the blueprint should just have WIs
[13:16] <ogra> all the rest goes into the wiki
[13:16] <rsalveti> ok, because I saw many blueprints with notes in it
[13:16] <rsalveti> mostly linaro ones
[13:17] <ogra> well, for dumping the notes the whiteboard is an easy place
[13:17] <ogra> but during cleanup and drafting it should be moved in the proper place
[13:17] <rsalveti> ok
[13:18] <ogra> also note that linaro might just handle it differently
[13:18] <rsalveti> yeah
[13:18] <ogra> better to look at ubuntu specs ;)
[13:18] <nigelb> !info python-gtk2
[13:18] <nigelb> err, sorry
[13:18] <NCommander> anyone else got any other specs to post?
[13:19] <ogra> 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] <NCommander> then I'm moving on unless someone else has something
[13:19] <ogra> we will get a new employee soon
[13:19] <ogra> please think about WIs he can take
[13:19]  * NCommander has nothing for FTBFS status, and there are no images yet so ...
[13:19] <ogra> from your specs
[13:19] <rsalveti> what he's good at?
[13:19] <ogra> images failed today, havent checked why
[13:19] <NCommander> ogra: oh, crontabs are running?
[13:20] <GrueMaster> Do we still want omap & dove images to build?
[13:20] <ogra> rsalveti, everything but dont overload him ;)
[13:20]  * NCommander didn't see a build failure image this morning
[13:20] <ogra> GrueMaster, omap -> yes, dove -> no i guess
[13:20] <rsalveti> ogra: :-)
[13:20] <ogra> NCommander, you should have mail
[13:20] <NCommander> GrueMaster: Dove is dead. omap3 is in the hands in Ubuntu ARM, and omap4 is maintained by Canonical
[13:20] <ogra> davidm, can you confirm ? no more dove in natty, right ?
[13:21] <davidm> correct no more dove in natty
[13:21] <GrueMaster> We'll probably kickstart it again mid February-March.
[13:21] <ogra> for reference: https://lists.ubuntu.com/archives/ubuntu-devel/2010-November/031952.html
[13:22] <ogra> that applies to omap3 currently
[13:22] <NCommander> GrueMaster: don't make me come and stab you
[13:22] <ogra> waiting for solutions from kernel and linaro teams
[13:22] <davidm> GrueMaster, I doubt it, the kernel we have access to is too far behind for natty
[13:23] <ogra> 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] <NCommander> ogra: I'll keep on eye on it for A1
[13:23] <ogra> so that might need some heavy lifting on our side
[13:24] <NCommander> [action] NCommander to supervise pre-installed omap4 images for Alpha 1
[13:24] <ogra> to have the deps and seeds right
[13:24] <MootBot> ACTION received:  NCommander to supervise pre-installed omap4 images for Alpha 1
[13:24] <NCommander> ^- standing item until Alpha 1
[13:24] <ogra> as well as ftbfs
[13:24] <ogra> NCommander, thanks
[13:24] <ogra> the ftbfs list looks awful atm
[13:24] <NCommander> ogra: I've got access to GrueMaster's pandas, so I can do TI work again.
[13:24] <ogra> though thats mainly kde/QT related
[13:24] <NCommander> ogra: not as bad as in cycles past TBH
[13:25] <ogra> well, but again qreal issues as far as i can see
[13:25] <ogra> the always reoccuring issue
[13:25] <ogra> NCommander, how about finally applying the upstream fix to it ?
[13:25] <NCommander> ogra: the one we can't fix without breaking the ABI of Qt :-/
[13:25] <Riddell> where are qreal issues?
[13:25] <ogra> davidm, ^^^
[13:25] <NCommander> ogra: upstream won't move until Qt5
[13:26] <ogra> any words on that ?
[13:26] <ogra> Riddell, armel as usual
[13:26] <ogra> Riddell, we have that every release
[13:26] <davidm> NCommander, I thought upstream wnated the change??
[13:26] <NCommander> ogra: sometime in the future. Not even Nokia knows when based off feedback from last Akademy
[13:26] <NCommander> davidm: yeah, but they can't until they break the ABI in general
[13:26] <ogra> well, they asked for it at the brussels UDS
[13:26] <NCommander> ogra: Linaro asked for it
[13:26] <ogra> and its really a non issue since its armel only
[13:26] <davidm> NCommander, can you please verify that upstream does not want it now?
[13:26] <ogra> NCommander, no
[13:27] <ogra> NCommander, i was at the discussion between asac and upstream
[13:27] <davidm> It is really creating havoc here
[13:27] <Riddell> ogra: I haven't seen any new qreal issues.  there's the issue with CXXFLAGS += -Wa,-mimplicit-it=thumb
[13:27] <NCommander> 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] <ogra> 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] <ogra> which costs a lot of time
[13:28] <NCommander> ogra: that's a toolchian issue because we had a patch in previously to make that the default
[13:28] <ogra> and upstream aksed to just switch TQ on armel for fixing that upstream
[13:28] <NCommander> 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] <davidm> NCommander, can you please verify with upstream if they want/will take the change.
[13:28] <ogra> NCommander, on the upstream QT qreal changes ?
[13:29]  * ogra wonders how thats related to doko
[13:29] <Riddell> the CXXFLAGS is related to doko
[13:29] <ogra> right, but thats fixed
[13:29] <NCommander> 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] <Riddell> 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] <ogra> what i care about is NCommander  wasting workdays on the same issue each release
[13:30] <ogra> adjusting the same patches every round
[13:31] <ogra> while upstream asked us to fix it with an upstream patch
[13:31] <NCommander> ogra: and we can't fix it upstream
[13:31] <ogra> we can
[13:31] <NCommander> I'm not repeating this disucssion. We do it every cycle
[13:31] <ogra> just patch QT properly and be done
[13:31] <NCommander> ogra: how do you suggest we sanely break Qt's ABI
[13:32] <NCommander> I'm not doing it
[13:32] <ogra> we only break it on armel
[13:32] <ogra> and given that we rebuild the whole distro, thats a non issue
[13:33] <NCommander> I am *NOT* having this discussion again
[13:33] <NCommander> I will post the links to every meeting we have discusssed it
[13:33] <NCommander> Because its the same argument going around
[13:33] <NCommander> 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] <ogra> i still fail to see the reason to not do it
[13:36] <davidm> Next please
[13:36] <NCommander> [topic] Any Other Business
[13:36] <MootBot> New Topic:  Any Other Business
[13:36] <NCommander> Going once
[13:36] <NCommander> Going twice
[13:36] <NCommander> Going three times
[13:37] <NCommander> #endmeeting
[13:37] <MootBot> Meeting finished at 07:37.
[17:00]  * apw limps in
[17:00]  * ogasawara waves
[17:00] <kamal> o/
[17:00]  * cking here o/
[17:00] <cking> apw, broken foot?
[17:00]  * smb /O\
[17:00]  * ericm|ubuntu here o/
[17:00] <jjohansen> \o
[17:00]  * ogra_ac lurks
[17:00] <ericm|ubuntu> \0/
[17:01] <SergioMeneses> hi
[17:01] <cooloney> yup
[17:01] <sconklin> here!
[17:01] <bjf> #startmeeting
[17:01] <MootBot> Meeting started at 11:01. The chair is bjf.
[17:01] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[17:01] <bjf> [LINK] https://wiki.ubuntu.com/KernelTeam/Meeting
[17:01] <MootBot> LINK received:  https://wiki.ubuntu.com/KernelTeam/Meeting
[17:01] <bjf> [LINK] https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Maverick
[17:01] <MootBot> LINK received:  https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Maverick
[17:01] <bjf> [TOPIC] ARM Status (lag)
[17:01] <MootBot> New Topic:  ARM Status (lag)
[17:01] <cooloney> ericm|ubuntu: you first, lady
[17:01] <bjf> cooloney, ^?
[17:02] <bjf> heh
[17:02] <ericm|ubuntu> no problem, simple word - nothing going on with Marvell dove
[17:02] <ericm|ubuntu> they've shipped their LSP 5.3.6, I'll talk with tgardner offline for that
[17:03] <bjf> #
[17:03] <bjf> # NOTE: '..' indicates that you are finished with your input.
[17:03] <bjf> #
[17:03] <cooloney> for ti-omap4, we just fixed a config issue bug 672635
[17:03] <cooloney> tim pushed and uploaded
[17:03] <cooloney> that's for maverick
[17:04] <bjf> cooloney, is that it?
[17:04] <cooloney> and some status from mpoirier
[17:04] <cooloney> * Texas Instruments (ti-omap)
[17:04] <cooloney>  * PATCH    : PowerSGX patch:
[17:04] <cooloney>               .Spent a lot of time looking at powerSGX
[17:04] <cooloney>               .Studied 3 implementation: Android, Meego and rcn-ee
[17:04] <cooloney>               .The Meego patch was folded in linaro-linux-2.6.35 but got rejected -> not upstreamable
[17:04] <cooloney>               .To be accepted, the patch would have to be nursed through the iteration process -> this is a full time assignment
[17:04] <cooloney>               .Going from ubuntu to linaro for kernel maintenance mandate that submitted patches be upstreamable
[17:05] <cooloney> for me, i'm working some upstream OMAP DSS2 patches. that's not for our ubuntu release
[17:06] <cooloney> yeah, that's it
[17:06] <cooloney> i'm done
[17:06] <apw> .. ?
[17:06] <bjf> [TOPIC] Release Metrics (JFo)
[17:06] <MootBot> New Topic:  Release Metrics (JFo)
[17:06] <apw> ENO-JFO
[17:07] <bjf> ack
[17:07] <bjf> [TOPIC] Blueprints: Kernel Configuration Review (apw)
[17:07] <bjf> [LINK] https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-config-review
[17:07] <MootBot> New Topic:  Blueprints: Kernel Configuration Review (apw)
[17:07] <MootBot> LINK received:  https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-config-review
[17:07] <apw> Configuration changes are defined and approved.  Work has not yet started on applying these, should hit before natty-alpha-1.
[17:07] <apw> ..
[17:07] <bjf> [TOPIC] Blueprints: Enhancements to the firmware test suite (cking)
[17:07] <bjf> [LINK] https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-firmware-test-suite-enhancements
[17:07] <MootBot> New Topic:  Blueprints: Enhancements to the firmware test suite (cking)
[17:07] <MootBot> LINK received:  https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-firmware-test-suite-enhancements
[17:07] <cking> Changes to fwts (natty development branch):
[17:07] <cking>  * Added more intelligence in backlight issues found in klog
[17:07] <cking>  * add --show-tests-full option
[17:07] <cking>  * add --lp-tags to print out LP tags when scanning klog errors
[17:07] <cking>  * make -p (show progress) default
[17:08] <cking>  * add -q, --quiet option
[17:08] <cking>  * add --dumpfile to load tables from acpidump and fwts --dump output
[17:08] <cking>  * prototyped ACPI method execution for sanity checks and mutex state checks
[17:08] <cking> ..
[17:08] <bjf> [TOPIC] Blueprints: Handling of Deviations from Standard Kernels (smb)
[17:08] <bjf> [LINK] https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-stable-frankenkernel-maintenance
[17:08] <MootBot> New Topic:  Blueprints: Handling of Deviations from Standard Kernels (smb)
[17:08] <MootBot> LINK received:  https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-stable-frankenkernel-maintenance
[17:08] <smb> Err
[17:08] <bjf> :-)
[17:09] <smb> Not much to add for the moment
[17:09] <smb> Working on the announcement scripts
[17:09] <smb> And I guess someone needs to do the documentation at some point...
[17:09] <smb> ..
[17:10] <bjf> [TOPIC] Blueprints: Review of the Stable Maintenance Process (sconklin)
[17:10] <bjf> [LINK] https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-stable-process-review
[17:10] <MootBot> New Topic:  Blueprints: Review of the Stable Maintenance Process (sconklin)
[17:10] <MootBot> LINK received:  https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-stable-process-review
[17:10] <sconklin> 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] <sconklin> https://wiki.ubuntu.com/Kernel/StableReleaseCadence
[17:10] <sconklin> It looks like the first official cycle may start on Nov 18th, but this is still indiscussion
[17:10] <sconklin> ..
[17:10] <tgardner> sconklin, any progress on the testing front?
[17:10] <sconklin> No
[17:11] <tgardner> how can we start a cycle without a prototype of the process?
[17:11] <bjf> maybe we should invite someone from testing to this meeting?
[17:11] <apw> skaet, any update on the testing ?
[17:11] <sconklin> tgardner: good question. We're awaiting our first information from the people responsible for testing
[17:11] <tgardner> hmm
[17:12] <apw> bjf, i think we need an action on steve to get one of them here for the next meeting till its resolved
[17:12] <ogasawara> 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] <bjf> [ACTION] sconklin to make sure someone from testing attends the weekly kernel meeting :-)
[17:12] <MootBot> ACTION received:  sconklin to make sure someone from testing attends the weekly kernel meeting :-)
[17:13] <tgardner> ..
[17:13] <sconklin> we're going to slip the Thursday requirement for verification testing
[17:13] <apw> why so ?
[17:14] <bjf> apw, without the full process in place should we go ahead and revert patches?
[17:14] <apw> (i suspect this is a #u-k discussion)
[17:14] <sconklin> Because we have not officially begun the new cycle, and have no definition of the testing process.
[17:14] <apw> lets take this offline then ..
[17:14] <sconklin> ..
[17:14] <tgardner> sconklin, well, you have announced that we're gonna do it on a certain date.
[17:15] <sconklin> tgardner: that's correct, an I can just as easily announce that we're slipping
[17:15] <bjf> apw, i thought thats what this meeting was about / for (this kind of discussion)
[17:15] <apw> oh ok, then i think if you start by slipping the verification revert
[17:15] <apw> then people will think they can always assume you will
[17:15] <apw> sets a bad precident
[17:15] <sconklin> That announcement was predicated on the assurance that we would have testing results by the end of last week
[17:15] <skaet> apw, sconklin - haven't got an update - but not sure I'm on the official list to get one.
[17:15] <apw> the longer we soak with only the patches we are going to release with the more
[17:16] <apw> happy [sic] the SRU team will be
[17:16] <bjf> skaet, if your not on the "official" list who would be?
[17:16] <tgardner> 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] <sconklin> I also have no problem dropping patches as announced, but we are feeling the process out
[17:16] <apw> 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] <skaet> bjf, sconklin is who victorp is communicating with.
[17:16] <cking> only the patches that are not tested?
[17:17] <apw> cking, right the un 'verified' bugs
[17:17] <cking> cool
[17:17] <sconklin> 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] <tgardner> sconklin, ack
[17:17] <sconklin> works for me
[17:17] <cking> and if testing fails to occur, we are effectively roadblocked?
[17:17] <apw> cking, we are in a bad place.
[17:17] <bjf> so no changes can be made to the repos until we've reverted patches?
[17:18] <tgardner> cking, we're no worse off then we were before, e.g., crowd sourcing
[17:18] <sconklin> bjf: effectively, yes.
[17:18] <smb> bjf, That probably is done on a side branch
[17:18] <bjf> smb, what good does it do to do them on a side branch?
[17:18] <sconklin> agreed, we just need to choose a naming convention for the "next" branch
[17:18] <sconklin> and we will have a merge window for it
[17:19] <smb> I was thinking along starting a branch from the upload and revert
[17:19] <smb> then that can be merged back to master
[17:19] <sconklin> no reverts, we will remove the patches and force-update the master branch
[17:19] <skaet> how about sru-candidate?
[17:19] <smb> sconklin, I would not do that, but its your decision
[17:20] <apw> skaet, in that week we are essentially on hold waiting on verification
[17:20] <sconklin> Too much clutter, and I'm afraid it will break all the tools which parse changelogs
[17:20] <bjf> sconklin, if we revert, we can comment why it was reverted (failure to verify)
[17:20] <sconklin> bjf: that will be documented in the bug
[17:21] <bjf> also, if we are adding patches to a "next" branch, do we do a "pre-proposed" from that?
[17:21] <skaet> 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] <sconklin> can anyone tell me how many tools there are which parse kernel changlelogs, in and out of the kernel team?
[17:21] <apw> what about the debian changelog
[17:21] <apw> won't that show the patches going in only if you do not revert, even though they are not in the tree ?
[17:21] <smb> sconklin, I just fear that you are causing pain by force-updating and rewriting a sort of pushed tree
[17:22] <sconklin> we regenerate the changelog. We simply make the patches dissappear.
[17:22] <apw> sconklin, i am not sure the archive admins will accept that, as it does not reflect correct history
[17:22] <smb> apw, I think at the moment it might be a case where apply and revert are done in two uploads
[17:22] <sconklin> The basic assumption I'm operating under is that anything after a tag is mutable
[17:22] <smb> apw, That is probably not handled as you would expect in the changelog
[17:22] <apw> right, which this is by definition
[17:23] <smb> sconklin, But you would do that if you remove patches from before
[17:23] <smb> wheras revert does not change the past
[17:23] <sconklin> smb: do what?
[17:23] <bjf> correct, the patches you are "disappearing" have been "tagged"
[17:23] <smb> sconklin, you sounded like using rebase -i to remove patches
[17:23] <tgardner> sconklin, lets take this offline. its a process issue thats not really relevant to the overall testing issue
[17:23] <bjf> as part of a -proposed upload
[17:24] <sconklin> 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] <apw> sconklin, a revert is just another patch on top
[17:24] <apw> they do not need to be understood per-see
[17:24] <sconklin> I understand that, but it leaves the original patch and the buglink
[17:24] <apw> we might wish to drop the bug link ...
[17:25] <smb> sconklin, apw Lets discuss this later on
[17:25] <apw> ack
[17:25] <apw> ..
[17:25] <sconklin> yes, we'll tackle this later
[17:25] <sconklin> ..
[17:25] <bjf> smb, apw, tgardner, sconklin, when and where because I want to be there
[17:25] <smb> #ubuntu-kernel
[17:26] <skaet> I'll be there too.
[17:26] <bjf> [TOPIC] Blueprints: Ubuntu Kernel Delta Review (apw)
[17:26] <bjf> [LINK] https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-ubuntu-delta-review
[17:26] <MootBot> New Topic:  Blueprints: Ubuntu Kernel Delta Review (apw)
[17:26] <MootBot> LINK received:  https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-ubuntu-delta-review
[17:26] <apw> Work has started on updating the Ubuntu drivers.  Work centers on updating aufs2 which is a blocker for (performant) live-cds.  Pulled in an experimental version of aufs2 for testing in v2.6.36.  Also pulled this up to v2.6.37-rc1 and did some testing.  Looking good so far.
[17:26] <apw> ..
[17:26] <bjf> [TOPIC] Blueprints: Kernel Version and Flavouts (apw)
[17:26] <bjf> https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-version-and-flavours
[17:26] <MootBot> New Topic:  Blueprints: Kernel Version and Flavouts (apw)
[17:27] <apw> Pulled the ports meta-packages into the main master branch to simplify ongoing maintenance.
[17:27] <apw> ..
[17:27] <apw> PS: the title here is spelt wrong
[17:27] <bjf> my bad
[17:27] <bjf> [TOPIC] Status: Natty (apw)
[17:27] <MootBot> New Topic:  Status: Natty (apw)
[17:28] <apw> Natty has just moved over to a v2.6.37-rc1 based kernel.  Stability is unexpectedly high.  Work is ongoing to get aufs2 working again so we can have performant live-cds shortly; likely in the next upload.  Blueprints are mostly up to date with initial work items and work is just beginning on our deliverables.
[17:28] <apw> Anyone who has not yet added milestones for their work items are likely to find I have assigned them one.  You may well find that means your entire natty workload is now scheduled for natty-alpha-1.  Please review these and split them out as necessary.
[17:28] <apw> ..
[17:29] <bjf> [TOPIC] Security & bugfix kernels - Maverick/Lucid/Karmic/Hardy/Dapper (sconklin)
[17:29] <MootBot> New Topic:  Security & bugfix kernels - Maverick/Lucid/Karmic/Hardy/Dapper (sconklin)
[17:29] <sconklin> ||                         || Upd./Sec.     || Proposed      || TiP || Verified    ||
[17:29] <sconklin> || Dapper: Kernel          || 2.6.15-55.89  ||               ||     ||             ||
[17:29] <sconklin> || Hardy:  Kernel          || 2.6.24-28.80  ||               ||     ||             ||
[17:29] <sconklin> || =       LRM             || 2.6.24.18-28.7||               ||     ||             ||
[17:29] <sconklin> || Karmic: Kernel          || 2.6.31-22.68  ||               ||     ||             ||
[17:29] <sconklin> || =       mvl-dove        || 2.6.31-214.30 || 2.6.31-214.32 ||     ||             ||
[17:29] <sconklin> || =       ec2             || 2.6.31-307.21 ||               ||     ||             ||
[17:29] <sconklin> || Lucid:  Kernel          || 2.6.32-25.45  || 3.6.32-26.46  || 14  ||  6 / 24     ||
[17:29] <sconklin> || =       LBM             || 2.6.32-25.24  || 2.6.32-26.25  ||     ||             ||
[17:29] <sconklin> || =       mvl-dove        || 2.6.32-209.25 || 2.6.32-211.27 ||     ||             ||
[17:29] <sconklin> || =       fsl-imx51       || 2.6.31-608.19 || 2.6.31-608.20 ||     ||             ||
[17:29] <sconklin> || =       ec2             || 2.6.32-309.18 ||               ||     ||             ||
[17:29] <sconklin> || = lts-backport-maverick || 2.6.35.22.34  ||               ||     ||             ||
[17:29] <sconklin> || Maverick: Kernel        || 2.6.35-22.35  || 3.6.35-23.37  || 14  ||  12 / 30    ||
[17:30]  * ogra_ac wonders about the maverick arm kernels in that list
[17:31]  * cooloney still is waiting for the list to finish
[17:31] <tgardner> maybe sconklin got booted
[17:31] <sconklin> I'm here, looks good to me
[17:31] <sconklin> even including the final ..
[17:31] <ogra_ac> mvl-dove, omap3 and omap4 should be in maverick
[17:31] <bjf> not seeing it
[17:31] <tgardner> sconklin, are ther more then one Maverick entry?
[17:31] <smb> Me neither
[17:31] <ogra_ac> wheer omap3 is built from the ubuntu tree as is
[17:31] <sconklin> || Maverick: Kernel        || 2.6.35-22.35  || 3.6.35-23.37  || 14  ||  12 / 30    ||
[17:31] <sconklin> || =       mvl-dove        || 2.6.32-410.27 ||               ||     ||             ||
[17:31] <sconklin> || =       ti-omap4        || 2.6.35-903.18 ||               ||     ||             ||
[17:32] <tgardner> much better
[17:32] <sconklin> That's all I have for Maverick
[17:32] <ogra_ac> :)
[17:32] <apw> we didn't get the last two lines
[17:32] <sconklin> whew
[17:32] <sconklin> ..
[17:32] <sconklin> oh, and then you also missed:
[17:32] <sconklin>  * The Karmic proposed kernel has been moved to updates.
[17:32] <sconklin>  * Jaunty is no longer supported
[17:32] <apw> indeed
[17:32] <sconklin> ..
[17:32] <apw> RIP jaunty
[17:32] <bjf> [TOPIC] Open Discussion or Questions: Raise your hand to be recognized (o/)
[17:32] <MootBot> New Topic:  Open Discussion or Questions: Raise your hand to be recognized (o/)
[17:32] <apw> o/
[17:32] <ogra_ac> o/
[17:33] <bjf> apw go
[17:33] <apw> For those who own a blueprint could you add a 'Status:' block to your
[17:33] <apw> whiteboards which should be a couple of sentences covering the current
[17:33] <apw> progress and any blockers.
[17:33] <apw> ..
[17:33] <bjf> ogra_ac, go
[17:33] <ogra_ac> i would like to rais some attention to
[17:33] <ogra_ac> https://lists.ubuntu.com/archives/ubuntu-devel/2010-November/031952.html
[17:33] <ogra_ac> which the arm team would like to have clearness about
[17:34] <apw> Subject: Ubuntu ARM and the linaro kernels
[17:34] <apw> ogra_ac, yes, that is on our radar ... when we know yo
[17:34] <ogra_ac> its currently not clear where the kernels for the new images are supposed to come from and who does the maintenance and how
[17:34] <apw> you will know too :)
[17:34] <ogra_ac> ah, good
[17:34] <tgardner> ogra_ac, its not cleat to us either
[17:34] <tgardner> clear*
[17:34] <ogra_ac> my main concern is that we need "distro" kernels
[17:34] <ogra_ac> thats fine then :)
[17:35] <apw> ogra_ac, yes, and supported ones
[17:35] <cooloney> i think we are pretty sure about that, we will keep ti-omap4 branch as Maverick
[17:35] <ogra_ac> ++
[17:35] <cooloney> but not sure about the omap3 solution
[17:35] <ogra_ac> omap3 is moving to linaro on my request
[17:35] <bjf> apw, it may be on the radar but the email thread is getting no love
[17:35] <apw> ogra_ac, are you testing a CD with their output (omap3) ?
[17:35] <ogra_ac> with worst case dropping full support for the image if we cant get a distro like kernel for it
[17:35] <cooloney> so who are going to maintain that omap3 stuff in our distro kernel
[17:36] <ogra_ac> and keep it as a community goodie
[17:36] <ogra_ac> apw, thats the plan
[17:36] <ogra_ac> my only concern is about security support
[17:36] <ogra_ac> but i'm willing to demote the image to a community one
[17:36] <apw> bjf, yes that is true, when we have some clarity we will publicise ...
[17:36] <ogra_ac> omap3 is just a nice to have
[17:37] <apw> ogra_ac, well the result of your testing will help very much with the planning process for this arm stuff
[17:37] <ogra_ac> omap4 has to be supported but there seem to be no probs ahead with that
[17:37] <apw> ogra_ac, when might we see your test results there.   we probabally need an official work-item for that testing as it is gating on some of the decision making imo
[17:37] <ogra_ac> apw, right, prob is that we need the kernel in main etc
[17:38] <ogra_ac> and indeed would prefer ubuntu suace as well as similar configs
[17:38] <sconklin> we have no resources at all for anything that is simply "nice to have"
[17:38] <apw> ogra_ac, it should have sauce in theory ...
[17:38] <ogra_ac> neither is clear yet if linaro can do that
[17:38] <ogra_ac> all i heard yet was that sauce is ripped out in linaro
[17:38] <ogra_ac> i might be wrong though (and would be happy to be)
[17:38] <apw> bjf could you action me to get some work-items for arm testing created
[17:39] <ogra_ac> and that the amount of built drivers is supposed to be reduced in linaro
[17:39] <tgardner> ogra_ac, John Rigby sends me pull requests for linux-linaro that has Ubuntu SAUCE
[17:39] <bjf> [ACTION] apw to get work-items created for arm testing
[17:39] <MootBot> ACTION received:  apw to get work-items created for arm testing
[17:39] <ogra_ac> tgardner, awesome
[17:39] <ogra_ac> then i'm wrong (and happy)
[17:39] <tgardner> ogra_ac, and has been for all of Maverick
[17:39] <ogra_ac> ok
[17:39] <ogra_ac> i didnt touch any linaro kernels before
[17:40] <tgardner> ogra_ac, I think you should try it out. I thought you were already using it
[17:40] <bjf> tgardner, do those also have security updates?
[17:40] <ogra_ac> nope, they dont have all drivers nor the same config
[17:40] <ogra_ac> and no security support at all
[17:40] <tgardner> bjf, yep cause jrigby rebases against Maverick master
[17:40] <bjf> tgardner, cool
[17:40] <ogra_ac> (which doesnt help much in natty)
[17:41] <tgardner> ogra_ac, natty is a different story that is still in development
[17:41] <ogra_ac> right
[17:41] <ogra_ac> my concern is all about natty
[17:41] <ogra_ac> maverick is done
[17:41] <ogra_ac> we only do SRUs and maintenance
[17:42] <tgardner> ogra_ac, I just don't know what the RM story for natty is yet.
[17:42] <ogra_ac> (we wont change anything thats not SRU)
[17:42] <tgardner> ARM*
[17:42] <ogra_ac> yes, nobody seems to
[17:42] <ogra_ac> yet i have to build images for alpha1
[17:42]  * cooloney feels lost
[17:42] <tgardner> ogra_ac, you shold be talking to jrigby
[17:43] <ogra_ac> tgardner, that wont solve anything on the distro side
[17:43] <tgardner> ogra_ac, why not? He's producing a distro kernel.
[17:43] <ogra_ac> i just noticed i have a mail from him but that wont help with distro or security
[17:43] <ogra_ac> he doesnt build all drivers
[17:43] <tgardner> ogra_ac, ok, so bug him to turn stuff on or off
[17:43] <ogra_ac> we want mostly identical configs across all builds
[17:44] <ogra_ac> k
[17:44] <bjf> does anyone have anything else?
[17:44] <tgardner> ..
[17:44] <ogra_ac> ..
[17:45] <bjf> thanks everyone
[17:45] <bjf> #endmeeting
[17:45] <MootBot> Meeting finished at 11:45.
[17:45] <kamal> thanks bjf
[17:45] <sconklin> thanks bjf
[17:46] <cooloney> thanks bjf very much
[17:50] <cking> thanks bjf
[18:09] <SpamapS> anybody here for server team meeting?
[18:09] <SpamapS> seeing as its 18:09 UTC
[18:10] <JamesPage> hmmm; should be here and now according to https://wiki.ubuntu.com/ServerTeam/Meeting
[18:10] <JamesPage> but seems a little quiet....
[18:10] <smb> I am sort of standby, but google-cal may have gone hazzard
[18:12]  * jjohansen is hanging around too
[18:12] <jjohansen> SpamapS: I think the whole dst ending in n. america may have messed people up a bit
[18:13] <SpamapS> jjohansen: yeah, plus the time was set at 19:00 in the header by ttx last week because he wasn't going to be able to attent at 18:00
[18:13] <SpamapS> ok, I'll change the meeting time back to 19:00 in the header, and we'll try again in 45 minutes
[18:13] <jjohansen> ah, I had missed that
[18:59] <SpamapS> o/
[19:00] <smb> \o
[19:01]  * SpamapS waits for 1 more o/ 
[19:01] <jjohansen> \o
[19:01] <SpamapS> woot ok here we go
[19:01] <SpamapS> #startmeeting
[19:01] <MootBot> Meeting started at 13:01. The chair is SpamapS.
[19:01] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[19:01] <mathiaz> o/
[19:01] <JamesPage> o/
[19:01] <SpamapS> FYI, the meeting was sort of half scheduled for 18:00, half for 19:00, so we're doing it now
[19:02] <SpamapS> I will be the scribe since daviey is possibly unavailable
[19:02] <SpamapS> [TOPIC] Review ACTION points from previous meeting
[19:02] <MootBot> New Topic:  Review ACTION points from previous meeting
[19:02] <SpamapS> Unfortunately, I believe those ACTION points in the agenda are the same as last week's.
[19:03] <JamesPage> is that because we did not do them last week?
[19:03] <SpamapS> please standby I will grep them out of the meeting log from last week..
[19:04] <SpamapS> Ok there were none it seems
[19:04] <SpamapS> moving on
[19:04]  * mathiaz \o/
[19:04] <SpamapS> [TOPIC] Natty Development
[19:04] <MootBot> New Topic:  Natty Development
[19:04] <mathiaz> it's always like that at the begining of a release cycle
[19:04] <SpamapS> Indeed. :)
[19:05] <SpamapS> I added this topic, just wanted to make sure people had a forum for any questions or comments on the spec process.
[19:05] <mathiaz> so the focus is to get WI defined
[19:05] <robbiew> right
[19:05] <SpamapS> We should all be submitting specs for review by... is it next Thursday?
[19:05] <mathiaz> once the WI are defined and rough plan is outlined the spec status should be moved to Review
[19:05] <robbiew> and I've started reviewing/approving/deferring/asking :)
[19:06]  * robbiew gave https://wiki.ubuntu.com/ServerTeam/NattyBlueprints some loving
[19:06] <SpamapS> Feature Definition Freeze is 11/25, so specs must be approved before then right?
[19:06] <mathiaz> one thing to consider is that it's possible (and actually encouraged) to add WI after the spec has been approved
[19:06] <SpamapS> yes, its mostly about getting the design and intent clear
[19:06] <mathiaz> as it helps to keep track of what needs to be done
[19:07] <SpamapS> And a general idea of how much is needed to be done.
[19:07] <mathiaz> and if an important is taking more time we can know in advance what other things should be dropped
[19:07] <mathiaz> so WIs defined when a spec is approved are not set in stone
[19:08] <SpamapS> ok, anything else on Natty?
[19:08] <mathiaz> Natty is going to ROCK!
[19:09] <SpamapS> Its going to burst forth from the ocean like a unicorn with flippers and a blow hole.
[19:09] <robbiew> lol
[19:09] <SpamapS> Alright, moving on.
[19:09] <RoAkSoAx> is the meeting almost over or just started?
[19:09] <SpamapS> [TOPIC] Maverick SRUs
[19:09] <MootBot> New Topic:  Maverick SRUs
[19:10] <SpamapS> I think this list also wasn't updated in the agenda.. and zul was mostly in charge of these, but does anyone have new ones to bring up for discussion?
[19:10] <JamesPage> yes - bug 666028;
[19:10] <JamesPage> for awareness more than anything else; its a follow up to bug 658227
[19:11] <mathiaz> JamesPage: the upload has been accepted in maverick-proposed
[19:11] <mathiaz> and should be ready in a couple of hours for testing
[19:11] <JamesPage> yep  - just went through
[19:11] <SpamapS> right looks like pitti accepted it into proposed just now
[19:11] <JamesPage> its holding up bug 661547
[19:12] <JamesPage> but that might be debatable for SRU (we'll see I guess)
[19:12] <SpamapS> Is anyone signed up to do the verification yet?
[19:12] <mathiaz> SpamapS: usually it's the SRU team in QA that does it
[19:12] <SpamapS> Ok.. I tend to verify my SRU's too.
[19:12] <mathiaz> SpamapS: however it's become a zero-man team recently
[19:12] <SpamapS> wha?
[19:13] <mathiaz> well - not really - volunteer are still trying to do verification
[19:13] <mathiaz> but it can take time
[19:13]  * SpamapS debates an action for robbiew: "FIX IT!"
[19:13] <mathiaz> so having someone within the server team taking care of sru-verification would be helpful
[19:13]  * robbiew is no longer release manager ;)
[19:13] <mathiaz> I'll do the sru-verification for openldap
[19:14] <robbiew> +1 on having Server team member on SRU team
[19:14] <robbiew> we are lucky to have pitti back from oem rotation this cycle for sure \o/...but help is definitely needed
[19:14] <mathiaz> it's also better to have the sru verification done by someone else than develop and sponsored the fix
[19:14] <SpamapS> [ACTION] mathiaz: to verify SRU bug 666028
[19:14] <MootBot> ACTION received:  mathiaz: to verify SRU bug 666028
[19:14] <JamesPage> mathiaz: I agree
[19:14] <SpamapS> s/better/vital/
[19:15] <mathiaz> which means that 3 people are required for getting an SRU through
[19:15] <mathiaz> (1 developer, 1 reviewer, 1 verifier)
[19:15] <SpamapS> Ok, so maybe another topic for discussion should be that we should raise the SRU manpower issue?
[19:15]  * hggdh pays attention now
[19:15] <mathiaz> yeah - that would be an interesting issue to solve
[19:16] <mathiaz> we had plans to improve the SRU process
[19:16] <SpamapS> maybe somebody could publicize that we are in need of some volunteer help for SRU's
[19:16] <mathiaz> (devised in the summer sprint in dublin more than 1 year ago)
[19:17]  * s3hh wonders what a reviewer task entails
[19:17] <Daviey> o/
[19:17] <robbiew> SpamapS: heh...if it were just advertising, it'd be a simple process to solve
[19:17] <robbiew> MIR team needs help too
[19:17] <SpamapS> yeah no kidding :p
[19:17] <mathiaz> the SRU tracker was designed as a tool to help in tracking what needs to be done
[19:17] <robbiew> and the Release Team could stand to grow a bit.../me gets off his soap box
[19:17] <robbiew> :)
[19:17] <mathiaz> it mainly is a ressource issue
[19:18] <mathiaz> s3hh: a review task is about reviewing the SRU prepared by another developer
[19:18] <mathiaz> s3hh: given that SRU is making there are no regression many eyes are important
[19:18] <SpamapS> Ok, so right now, we just make it clear that there is a resource issue, and tax other devs for verification?
[19:18] <ajmitch> robbiew: I didn't think the release team was necessarily involved in SRUs :)
[19:19] <mathiaz> SpamapS: yeah - I think that's the good way
[19:19] <mathiaz> SpamapS: with the sru tracker we should be able to generate a list of bugs that need to be verified
[19:19] <robbiew> ajmitch: you should check out the members of each then ;)
[19:19] <SpamapS> mathiaz: there's a tag for that ;)
[19:20] <mathiaz> SpamapS: and then the verification needs to be done by someone
[19:20] <ajmitch> SpamapS: is the problem mostly verification, or getting a package into -proposed in the first place?
[19:20] <mathiaz> SpamapS: yes - the SRU tracker also filters the list to make it relevant to server package
[19:20] <mathiaz> ajmitch: both ;)
[19:20] <SpamapS> So maybe we should add a "daily verification" schedule similar to daily triage.
[19:20] <mathiaz> SpamapS: make it smaller chunks
[19:20] <mathiaz> SpamapS: yop - that was the next step :)
[19:21] <SpamapS> zul_: think you could add a list of verification-needed bugs to the SRU tracker easily?
[19:21] <mathiaz> SpamapS: it already is IIRC
[19:21] <SpamapS> yes, why yes it is
[19:21] <mathiaz> SpamapS: http://people.canonical.com/~chucks/SRUTracker/sru-tracker-bugs.html#verified_bugs
[19:22] <SpamapS> [ACTION] ALL: please check the SRU tracker for verification-needed bugs and help out with verification
[19:22] <MootBot> ACTION received:  ALL: please check the SRU tracker for verification-needed bugs and help out with verification
[19:22] <SpamapS> Ok, lets move on
[19:23] <SpamapS> ajmitch: getting things into proposed seems to happen at a fairly nice pace, we can thank pitti for that.
[19:23] <SpamapS> [TOPIC] Weekly Updates & Questions for the QA Team (hggdh)
[19:23] <MootBot> New Topic:  Weekly Updates & Questions for the QA Team (hggdh)
[19:23] <hggdh> k
[19:23] <hggdh> first question is from myself
[19:23] <hggdh> how are we going to test server images for MAC, armel, PPC?
[19:24] <hggdh> nice to have them, but...
[19:24] <ajmitch> SpamapS: oh I meant getting a package ready for -proposed, ie finding the fix
[19:24] <mathiaz> hggdh: are there any images published for these architecture?
[19:24] <hggdh> mathiaz: yes, just popped in in the server/daily
[19:25] <JamesPage> whats the status of libvirt/kvm on those architectures?
[19:25] <SpamapS> hggdh: I believe there were some build machines distributed for armel at UDS.. did we not get QA machines as well?
[19:25] <hggdh> SpamapS: none for server testing at least; I did not hear of any for QA at all
[19:26] <mathiaz> hggdh: well - I think these images should be tested
[19:26] <s3hh> JamesPage: well ppc kvm is supposed to work iirc
[19:26] <mathiaz> hggdh: in order to do that hardware needs to be available
[19:26] <hggdh> mathiaz: I agree, I  did not say they would not, I asked *how* ;-)
[19:26] <mathiaz> hggdh: which I don't have
[19:26] <mathiaz> hggdh: and I don't know who on the team has hardware
[19:27] <hggdh> robbiew: hello, sir :-)
[19:27] <SpamapS> I have an old PowerMac G5.. but what really troubles me is that this suggests maybe we're going to have even *more* iso tests to run?
[19:27] <hggdh> yes we will
[19:27] <SpamapS> JamesPage: time to fire up automated iso testing on PPC. :-D
[19:27] <robbiew> wait
[19:27] <hggdh> libvirt would help, but we need to also try bare metal
[19:27] <s3hh> doh
[19:27] <robbiew> why are we discussing this?
[19:28] <SpamapS> robbiew: no idea, hggdh brought it up
[19:28] <robbiew> Ubuntu Server testing on PPC32?
[19:28] <mathiaz> robbiew: http://cdimage.ubuntu.com/ubuntu-server/daily/current/
[19:28] <JamesPage> SpamapS; yes - but we need to cover the other two cases using physical hardware as well
[19:28] <mathiaz> robbiew: ^^ there are images for these architecture published there
[19:28] <hggdh> robbiew: we have the images now
[19:29] <SpamapS> Ooo I volunteer to host the PS3 test box...
[19:29] <robbiew> we don't spin official ISOs for Server on PPC32
[19:29] <robbiew> or PS3
[19:29] <SpamapS> darn
[19:29] <robbiew> these are ports, right?
[19:30] <mathiaz> robbiew: I don't know - it's the first time I see these images show up on cdimage
[19:30] <SpamapS> right, so we don't need to complete the iso tests.. that would be something the community would need to complete.
[19:30] <mathiaz> robbiew: under the ubuntu-server daily iso
[19:30] <robbiew> hmm
[19:30] <robbiew> let me dig into this
[19:30] <hggdh> thank you
[19:30] <highvoltage> there are PS3 images on cdimage!?
[19:30] <robbiew> I say for now...no testing of these flavors
[19:30] <mathiaz> robbiew: it may be an error on the iso build scripts
[19:30] <robbiew> intel and amd64 for now
[19:30] <hggdh> robbiew: the same for AMD64-mac?
[19:31]  * highvoltage sees there is and apologizes for his ignorance
[19:31] <robbiew> just focus on i386 and amd64 images
[19:31] <hggdh> k
[19:31] <SpamapS> sounds good to me. :)
[19:31] <hggdh> next item from QA
[19:31] <mathiaz> hggdh: so nothing changes compared to last release cycle
[19:31] <ajmitch> highvoltage: good luck getting a PS3 that you can still run it on :)
[19:31] <hggdh> mathiaz: ack
[19:32] <hggdh> I intend to expand daily build for packages with build-time checks
[19:32]  * robbiew suspects this has to do with the discussion at UDS around relocating the ports stuff
[19:32] <hggdh> so I would like you folks to give me these packages (so that I can add them in)
[19:33] <mathiaz> hggdh: you're looking for packages that have their test suite run during the build?
[19:33] <SpamapS> ahh so just add the natty package as a daily build, to test for toolchain regressions.
[19:33] <hggdh> mathiaz: yes, this would be immediately used (like mysql, coreutils, etc)
[19:33] <hggdh> which are already built daily, BTW
[19:33] <mathiaz> hggdh: ok - I'd suggest to send email to ubuntu-devel/ubuntu-server for a first round of feedback
[19:34] <SpamapS> hggdh: its not entirely clear how one would determine that easily, other than noticing it while looking at a package.
[19:34] <mathiaz> hggdh: you can also find good candidates by looking at packages that support the nocheck option at build time
[19:34] <hggdh> will look for them
[19:34] <SpamapS> mathiaz: how is that determined though? grep nocheck debian/rules ?
[19:34] <mathiaz> hggdh: as nocheck is the recommended way (may even be in the policy now) to disable tests at build time
[19:34] <mathiaz> SpamapS: yes - nocheck in debian/rules
[19:35] <mathiaz> SpamapS: write a script that looks for all debian/rules in the archive
[19:35] <mathiaz> SpamapS: I recommand a local mirror of the archive to do so
[19:35] <SpamapS> ok so that could be done in an automated fashion (albeit slow, since it would basically require grepping every diff and unpacking every .debian.tar.gz
[19:35] <mathiaz> SpamapS: I usually as kees to run these scripts ;)
[19:35] <SpamapS> hah good point
[19:35] <SpamapS> so, is somebody going to do that?
[19:36] <mathiaz> SpamapS: kirkland also has a local mirror and ran similar scripts before
[19:36] <hggdh> will look for easy ways. Meanwhile, if you know of any such packages now... I can add them
[19:36] <mathiaz> hggdh: mysql, openldap
[19:36] <JamesPage> hggdh: is it possible to see whats already covered somewhere?
[19:37] <hggdh> JamesPage: yes, just a sec
[19:38] <SpamapS> hggdh: how about you send a message to ubuntu-server and ubuntu-devel with the coverage and a request for more packages that do checks?
[19:38] <hggdh> deal.
[19:38] <SpamapS> we need to move on.
[19:38] <hggdh> I am done
[19:38] <robbiew> right...so the new look of the daily images has to do with https://blueprints.launchpad.net/ubuntu/+spec/ubuntutheproject-foundations-n-cdimage-ports-consolidation
[19:38] <robbiew> just an FYI
[19:38] <SpamapS> hggdh: thanks! :)
[19:38] <SpamapS> [TOPIC] Weekly Updates & Questions for the Kernel Team (jjohansen)
[19:38] <MootBot> New Topic:  Weekly Updates & Questions for the Kernel Team (jjohansen)
[19:39] <jjohansen> well first up lets add an action item to change that from jjohansen to smb :)
[19:39] <jjohansen> smb: did you have anything you wanted to bring up?
[19:39] <smb> Just one notification that I was made aware of a bug which looks server related by Montreal: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/415353
[19:40] <smb> Have not looked at that deeply but plan to do tomorrow
[19:40] <SpamapS> jjohansen: will do when doing the minutes
[19:41]  * smb spent most of today from recovering / catching up from yesterday which he spent recovering from returning from Plumbers
[19:41] <jjohansen> The config patch for Bug #651370 has been submitted and accepted for SRU
[19:42] <SpamapS> alright, anything else?
[19:42] <mathiaz> smb: how is the kernel release manager for natty?
[19:42] <mathiaz> smb: *who*
[19:42] <jjohansen> what else, the pv-on-hvm drivers are in the natty kernel and we will be experimenting with them this week
[19:43] <smb> apw
[19:43] <SpamapS> mathiaz: aw, and here I thought you were just concerned for apw's well being
[19:43] <mathiaz> :)
[19:43] <SpamapS> alright, we're running a bit short on time, so unless there is anything else?
[19:44] <jjohansen> I'm done
[19:44] <SpamapS> sommer seems to be absent so we will skip Doc team q&a for now
[19:44] <SpamapS> I've pinged kim0 .. but we can move on to the next topic till he replies
[19:44] <SpamapS> [TOPIC] Meeting time and scheduling (SpamapS)
[19:44] <MootBot> New Topic:  Meeting time and scheduling (SpamapS)
[19:45] <SpamapS> I think actually Daviey and ttx brought this up originally
[19:45] <SpamapS> two issues really
[19:45] <SpamapS> 1) today's was moved back to 1900 UTC accidentally I think.. or did we move it to 1900 so it stays at the same local time for everybody who is now on DST ?
[19:46] <mathiaz> SpamapS: 1) - yes for 2nd option
[19:46] <robbiew> any reason why it's so late in the day?
[19:46] <SpamapS> So given that do we have any strong thoughts about moving the meeting to 1600 UTC?
[19:46] <robbiew> could we do 1700 UTC?
[19:46] <mathiaz> robbiew: historical reason
[19:47] <robbiew> or even 1600UTC
[19:47] <JamesPage> 1600UTC would be better for me (and I now Daviey was keen as well)
[19:47]  * robbiew would love 1600UTC...but wasn't sure SpamapS would be awake ;)
[19:47] <mathiaz> 1600 UTC would mean we'd be back to back with the Tech Board
[19:47] <Daviey> \o/
[19:47] <mathiaz> every other week
[19:47] <SpamapS> 1600 UTC will be 8:00am for me, but I have a 1 year old so thats usually 3 - 4 hours after I wake up
[19:47] <Daviey> mathiaz: we used to be back to back
[19:47] <Daviey> it was *rarely* a problem
[19:47] <robbiew> eh...TB isn't that important anyway :P
[19:48] <mathiaz> Daviey: yes - the meeting was at 16:00 UTC for a long time
[19:48]  * robbiew says we move it back
[19:48]  * JamesPage seconds the motion
[19:48]  * s3hh is good w that
[19:48] <SpamapS> I am totally fine w/ 16:00 as long as its understood I may be surly and have messy hair.
[19:49] <robbiew> lol
[19:49] <s3hh> SpamapS: keep that webcam off
[19:49] <robbiew> yes..please!
[19:49] <SpamapS> Ok, 16:00 UTC it is
[19:49] <smb> This also means the meeting has to finish after one hour. :)
[19:49] <SpamapS> (I believe we also discussed this offline with some other team members last week so I feel comfortable saying that "the motion carries")
[19:49] <RoAkSoAx> jeez im gonna have to wake up early now :(
[19:49] <SpamapS> smb: ++
[19:50] <SpamapS> RoAkSoAx: I'll make an extra big pot of coffee so we can share
[19:50] <SpamapS> [TOPIC] Open Discussion
[19:50] <MootBot> New Topic:  Open Discussion
[19:50] <RoAkSoAx> I need a volunteer to review the library split for cluster-stack packages... anyone? :)
[19:51] <RoAkSoAx> before actually uploading to universe and requesting MIRs
[19:51] <ajmitch> RoAkSoAx: 16:00 UTC shouldn't be that bad for you? there aren't too many server community people in this part of the world though
[19:51] <SpamapS> RoAkSoAx: throw it up as a merge proposal and ask ubuntu-server for a review.
[19:52] <SpamapS> RoAkSoAx: I'll take a peek.
[19:52] <robbiew> wait folks...I think the desktop team meets at 16:30UTC...according to the Fridge
[19:52] <SpamapS> Anybody else have any other topics?
[19:52] <SpamapS> robbiew: doh
[19:52] <mathiaz> robbiew: nope - they meet in ubuntu-desktop
[19:52] <robbiew> sweet
[19:52] <mathiaz> robbiew: the fridge is probably wrong
[19:52] <robbiew> and odd...but who cares
[19:53] <SpamapS> oh thats the other thing
[19:53] <robbiew> \o/
[19:53] <SpamapS> should we update the fridge?
[19:53] <SpamapS> we aren't even listed there
[19:53] <robbiew> I can
[19:53] <SpamapS> [ACTION] robbiew: update the fridge calendar with new ubuntu server meeting time
[19:53] <MootBot> ACTION received:  robbiew: update the fridge calendar with new ubuntu server meeting time
[19:53] <RoAkSoAx> ajmitch: no it is actually not that bad... but it is early for me :P I wake up late sometimes :)
[19:53] <SpamapS> Alright
[19:53] <SpamapS> [TOPIC] Announce next meeting date and time
[19:53] <MootBot> New Topic:  Announce next meeting date and time
[19:53] <SpamapS> Tuesday 2010-11-16 at 1600 UTC - #ubuntu-meeting
[19:54] <SpamapS> Thanks everyone!
[19:54] <SpamapS> #endmeeting
[19:54] <MootBot> Meeting finished at 13:54.
[19:54] <mathiaz> SpamapS: thanks!
[23:59] <UndiFineD> o/
[23:59] <cprofitt> #startmeeting Ubuntu Beginners Team
[23:59] <MootBot> Meeting started at 17:59. The chair is cprofitt.
[23:59] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[23:59] <friTTe|> \o
[23:59] <pedro3005> \o/
[23:59] <cprofitt> hello Beginners Team