[13:57]  * lool waves and pokes sladen 
[13:57] <lool> ups
[13:57] <lool> slangasek:
[13:57] <lool> not sladen, sorry
[13:57]  * slangasek is poked
[13:58] <ScottK> \o
[13:59] <heno> hi
[13:59] <pitti> hello
[14:00] <slangasek> mdz, pgraner, robbiew, cjwatson, rickspencer3, Riddell, sbeattie, Hobbsee, fader: ping
[14:00]  * fader waves.
[14:00] <sbeattie> hey
[14:01] <mdz> slangasek: good morning
[14:01]  * pgraner yawns
[14:01] <dendrobates> o/
[14:01] <mdz> finally I get to attend without a meeting conflict!
[14:01] <slangasek> :)
[14:02]  * rickspencer3 throws cold water on pgraner
[14:02] <pitti> I'm sure he'd rather appreciate a coffe
[14:03] <slangasek> #startmeeting
[14:03] <MootBot> Meeting started at 09:03. The chair is slangasek.
[14:03] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[14:03] <mdz> slangasek: I sent you a couple of additional topics by email (sorry for it being last minute)
[14:03] <pgraner> pitti: cold water is better :-D
[14:03] <mdz> they should be quick
[14:03]  * rickspencer3 hands pgraner a non-fat soy latte
[14:03] <slangasek> [LINK] Agenda: https://wiki.ubuntu.com/ReleaseTeam/Meeting/2009-03-20
[14:03] <MootBot> LINK received:  Agenda: https://wiki.ubuntu.com/ReleaseTeam/Meeting/2009-03-20
[14:04] <cjwatson> whoa, I forgot about the time change
[14:04] <pgraner> rickspencer3: me hands it back
[14:05] <slangasek> mdz: ack, seen now
[14:07] <slangasek> [TOPIC] outstanding actions
[14:07] <MootBot> New Topic:  outstanding actions
[14:07] <slangasek> bug #88746 remains an eyesore on my todo list for another week
[14:07] <slangasek> I confirmed the suspend/resume test plan with ogasawara last night
[14:08] <fader> A summary of the hardware testing is on ogasawara's weather report
[14:08] <slangasek> fader: did you get a chance to talk to ogasawara about linking the HW cert report from the weather report ?
[14:08] <slangasek> ok, great!
[14:08] <fader> Updated once per day atm
[14:08]  * ScottK tosses out a thanks to cjwatson for figuring a way to avoid the qt4-x11 ICE on powerpc (previous week's action).
[14:08] <cjwatson> ScottK: doko fixed the gcc bug too, so that can be dropped the next time qt4-x11 is getting an upload anyway
[14:08] <mdz> wow, that's a lot of comments on 88746
[14:09] <ScottK> cjwatson: Thanks.  Good to know.
[14:09] <slangasek> yes, it's probably a dozen or so bugs in a single bug report :/
[14:10] <mdz> fader: that's great
[14:10] <slangasek> [TOPIC] QA team
[14:10] <MootBot> New Topic:  QA team
[14:10] <slangasek> 'hardware testing' is the only thing on my agenda here - are we in good shape for certification testing on the beta?
[14:11] <fader> Yup, we're getting good coverage
[14:11] <fader> file:///home/fader/Desktop/cr-20090320.html
[14:11] <mdz> the (only) two failures both look like problems with the test suite
[14:11] <heno> see http://people.ubuntu.com/~fader/hw-testing/current
[14:11] <cjwatson> there is a known problem with cciss and lvm, which fader's testing uncovered
[14:12] <fader> Modulo a couple of hardware issues that we're still working through, there are only 2 failures that as mdz says are things we need to look at with checkbox
[14:12] <cjwatson> bug 341928
[14:12] <mdz> ouch
[14:12] <davmor2> cjwatson: beat me to it
[14:12] <cjwatson> I suspect that at this point we won't manage to clean that up for beta, but we have a rough idea of whereabouts the problem lies
[14:13] <mdz> release note?
[14:13] <slangasek> cjwatson: something that we could preemptively errata then?
[14:13] <cjwatson> yes, I think so
[14:13] <slangasek> (erratate?)
[14:13] <slangasek> cjwatson: can you take that action?
[14:13] <cjwatson> I see that it was mistakenly not targeted to jaunty, so I'll do that now
[14:13] <cjwatson> slangasek: yes
[14:13] <slangasek> [ACTION] cjwatson to document cciss+lvm problem for beta
[14:13] <MootBot> ACTION received:  cjwatson to document cciss+lvm problem for beta
[14:14] <cjwatson> (it's only for removing LVM on such systems, BTW; setting up LVM is fine)
[14:14] <cjwatson> (which is why I'm not panicking)
[14:14] <slangasek> heno: anything else showing up as a concern from the QA side?
[14:14] <mdz> I believe there's some infrastructure work on the ISO tracker for beta
[14:15] <slangasek> ah?
[14:15] <pitti> heno: is the process of feeding bugs to teams and getting them reviewed/processed/ct-rev'ed working now?
[14:15] <mdz> RT 3363
[14:15] <mdz> 33363, rather
[14:15] <mdz> ETA is today
[14:15] <heno> yes, we've been allocated a new server, not sure if we will migrate for beta, likely not
[14:16] <slangasek> would that at least give you streamlined access to the SQL db, or is that dependent on migration?
[14:16] <slangasek> I got halfway to putting UNR on the tracker, but I would need another RT to add test cases for it :)
[14:16] <mdz> I gave a heads up to IS that cdimage was a likely contentious resource
[14:16] <heno> pitti: the infrastucture is all working, not sure how much uptake there is - some teams still have a long list of old assigned bugs
[14:17] <mdz> (for beta image testing)
[14:17] <heno> slangasek: I'm sure we can do db updates even on the current setup
[14:17] <lool> slangasek: Test cases are a bit of a mess, we have a bunch of them, but it's not clear which site to fix (testcases.qa.u.c or the wiki)
[14:17] <pitti> heno: from my perspective it's working well, we get some important bugs tossed from QA, and I channel them to people, etc.
[14:17] <lool> But we certainly have a list of things to test in UNR, thanks to OEM's earlier testplan efforts
[14:18] <heno> we're setting up a backup mirror just in case too
[14:18] <mdz> there are 48 bugs on the regression list, 15 of which have no importance set yet
[14:18] <heno> sbeattie: ^
[14:19] <cjwatson> ... 13
[14:19] <heno> slangasek: about other concerns - not yet, but I'd like us to do some more audio testing
[14:19] <heno> We are also doing a run of manual testing of the laptops in Montreal starting today, following the test plan at http://testcases.qa.ubuntu.com/Plans/LaptopTesting
[14:20] <heno> This will include running the suspend / resume script
[14:20] <slangasek> what sort of audio testing?  verifying that it works on different hardware?
[14:20] <mdz> there are 276 open suspend/resume bugs resulting from the testing, about half triaged I estimate
[14:20] <slangasek> lool: test cases for what?  ISO testing?
[14:20] <heno> fader: is that all lined up to go ahead?
[14:20] <lool> slangasek: for UNR
[14:20] <lool> slangasek: Yes, for the iso testing tracker
[14:20] <fader> heno: Yes, we're doing manual laptop tests today
[14:21] <heno> slangasek: yes that and some more testing around VoIP
[14:21] <fader> David Bensimon is helping with that which I really appreciate :)
[14:21] <lool> [link] https://wiki.ubuntu.com/Testing/Cases/Ubuntu-Netbook-Remix
[14:21] <MootBot> LINK received:  https://wiki.ubuntu.com/Testing/Cases/Ubuntu-Netbook-Remix
[14:21] <lool> QA folks in the mobile team are aware of these and will use them
[14:21] <heno> we've seen issues with skype and gizmo
[14:21] <slangasek> lool: hrm, how many is "a bunch" then?  we don't want too much combinatorial explosion on the ISO test cases...
[14:22] <lool> slangasek: There is a lot of coverage, I don't think you want to link them all to the ISO testing site, but we could select some for that
[14:22] <slangasek> heno: sounds good - shall I assume that any problems found will be filed and escalated?
[14:22] <heno> slangasek: yes
[14:23] <slangasek> lool: that would be helpful
[14:23] <slangasek> [ACTION] lool to identify a set of UNR test cases to link from the ISO tracker
[14:23] <MootBot> ACTION received:  lool to identify a set of UNR test cases to link from the ISO tracker
[14:23] <slangasek> [TOPIC] Desktop team
[14:23] <MootBot> New Topic:  Desktop team
[14:24] <pitti> as usual, report is on https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus
[14:24] <slangasek> rickspencer3: heyo
[14:24] <slangasek> (and pitti :)
[14:24] <pitti> please notice that I took the fixed bugs off the list (some were still mentioned in the agenda)
[14:24] <pitti> we made quite some good progress on fixing RC bugs last week, especially in the X.org area
[14:24] <pitti> unfortunately the list still grows instead of shrinks, but that's mostly because there are more and more "less critical" things getting on that list now
[14:24] <pitti> the first four bugs are still nasty, but all other bugs are entirely tractable and on track to get fixed by the release; I grouped them accordingly on the wiki page
[14:25] <slangasek> pitti: which ones were still on the agenda that were fixed?  that list should've been filtered already
[14:25] <pitti> we'll get a new GNOME maintainer next week, so he can hopefully help out with e. g. 325973
[14:25] <pitti> slangasek: the nss comodo one, the fglrx migration
[14:26] <mdz> 304871 -> has that been escalated to intel?
[14:26] <pitti> and the compiz flicker
[14:26] <pitti> mdz: yes, many times
[14:26] <pitti> mdz: they basically stop supporting old hardware :(
[14:26] <pitti> and likewise, putting most of their energy into developing UXA
[14:27] <mvo> pitti: compiz is still flickering with notify-osd?
[14:27] <pitti> so keeping support for the i8xx chips has become pretty much a community effort nwo
[14:27] <rickspencer3> mdz: to them, the fix is to buy a shiny new card that works with their new code
[14:27] <pitti> mvo: oh, is it? I thought that was fixed for good?
[14:27] <mdz> rickspencer3: more like a new motherboard or laptop :-/
[14:28] <pitti> mdz: which isn't entirely out of Intel's interest..
[14:28] <pitti> </snide remark>
[14:28] <mvo> pitti: yes, should be fixed
[14:28] <lool> exactly what I was thinking :)
[14:28] <pitti> mvo: right, what I thought
[14:28] <slangasek> mvo: yes, pitti was commenting that he had closed the bug :)
[14:28] <pitti> so, option 1 is to transition those people to vesa on upgrades
[14:29] <pitti> rickspencer3 and I also mentioned short-term contracting a driver developer, but I guess they don't exactly grow on trees
[14:29] <mvo> aha, sorry. misread the comment then
[14:29] <mdz> option 2 is to punt and say that it's dead upstream and we can't do much about it
[14:30] <slangasek> pitti: bug #304871 does show a different error with the new upstream version than it did before, perhaps that's more tractable?
[14:30] <pitti> mdz: right, that's pretty much option 1 (i. e. at least not entirely break the upgrade)
[14:30] <mdz> I'm happy for the desktop team to make the call on how to handle it; do we need to discuss more in the meeting?
[14:31] <pitti> slangasek: I noticed, but to me personally it's just gibberish, I'm afraid; I'll consult with bryce, the last testing results are not even a day old
[14:31] <slangasek> (there's also wildfire saying that he has "the same failures" after upgrade, but there's no context for what that means since he hadn't previously commented on the bug with any kind of error message...)
[14:31] <pitti> mdz: not from my side; we can always move them to vesa as a last resort
[14:31]  * slangasek nods
[14:32] <pitti> slangasek: Anand Kumria did comment a lot before, and it's not fixed for him either
[14:32] <slangasek> pitti: he commented a lot, but *none* of his comments link his problem to the error in the bug title
[14:32]  * ScottK has i865 hardware he can do testing with if needed.
[14:32] <pitti> ah, I see
[14:32] <ScottK> (and a related self interest in this getting fixed)
[14:33] <pitti> ScottK: can't hurt; the bug is about i845, but if it previously failed for you, and now works, that'd be a good sign
[14:33] <slangasek> [ACTION] ScottK to try to reproduce bug #304871 on his i865 hardware
[14:33] <MootBot> ACTION received:  ScottK to try to reproduce bug #304871 on his i865 hardware
[14:33] <ScottK> There were some comments about i865 too.
[14:33] <slangasek> [TOPIC] Mobile team
[14:33] <MootBot> New Topic:  Mobile team
[14:34] <lool> list of specs and bugs on our radar <https://wiki.ubuntu.com/MobileTeam/Roadmap>; current high-level status per topic:
[14:34] <lool> * UNR: good shape; most bugs discovered during testing of this spin are not UNR specific
[14:34] <lool> * MID image was broken, likely due to the broken deps on lpia which cjwatson fixed recently; Emmet and Steve looking at fixing it and QA (Paul and Tobin) to look at it again on Monday; 345621
[14:34] <lool> * armel's "iMX51 Babbage" work: providing install media images, general enablement, kernel fixes/debug, integration, installer; good progress, but installer work is the scary part and is late; 345534 and misc others
[14:34] <lool> * VFP optimized libs: infrastructure now runs fixed kernels \o/  vfp libc pushed, ~4 other remaining libraries to come next week after beta (pango1.0, gtk+2.0, cairo, ffmpeg-debian); relatively low risk as the changes should only add files to the armel binaries; 303232
[14:34] <lool> * NEON: last minute request to support NEON hwcaps; kernel part uploaded; needs a couple of glibc patches similar to VFP support aimed at just after beta; 343602
[14:34] <lool> * milestoned bugs: almost no progress, more focus on them once we have a babbage daily image
[14:34] <lool> * Poulsbo drivers: late, but initial packaging for intrepid seems ready now; needs checking with bryce that it's ok to proceed to similar changes in jaunty, FFE, and actual upload; still seems preferable than a SRU; 335276 for intrepid
[14:34] <lool> <done with dump>
[14:34] <mdz> lool: is it still impossible to test UNR using KVM due to the launcher requiring 3D?  that may be a consideration for ISO testing
[14:34] <cjwatson> lool: also, armel is in bad shape installability-wise right now
[14:34] <cjwatson> I've been working on fixing some of that stuff up today
[14:35] <cjwatson> but it will bite any current images
[14:35] <lool> mdz: I asked qa folks in our team to see whether virutalbox GL support helps
[14:35] <davidbarth> lool: does it support GL on Linux now?
[14:35] <lool> cjwatson: Ok; I've seen the number of ftbfs was relatively high yesterday ~350 or so and thought we'd look more into it as we face installability issues when building images and when working on general archive consitency; it has indeed been less of a focus recently
[14:36] <davmor2> I'm sure most people who have netbooks can at least test live desktop if not install
[14:36] <slangasek> lool: 280669, 338148 are not targeted to jaunty (from your roadmap); should they be?
[14:36] <cjwatson> lool: a lot of it was due to libgnome being outdated, which will be fixed as soon as the armel buildds get unstuck from whatever they're very slowly building at the moment
[14:37] <slangasek> [LINK] https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus
[14:37] <MootBot> LINK received:  https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus
[14:37] <lool> davidbarth: I think it did support a subset, but I only read indirectly about it
[14:37] <slangasek> [LINK] https://wiki.ubuntu.com/MobileTeam/Roadmap
[14:37] <MootBot> LINK received:  https://wiki.ubuntu.com/MobileTeam/Roadmap
[14:37] <lool> slangasek: 280669, no; we just owe the kernel team to look at it quickly, but not related to jaunty
[14:38] <lool> slangasek: 338148, no, just an armel ftbfs which we're trying to get fixed to improve the number of building packages
[14:38] <slangasek> lool: could you open tasks on 303232 on the libs that are going to be changed, so that the scope of this is more easily apparent?
[14:38] <lool> slangasek: (These bugs are the ones we visit at our weekly meetings)
[14:38] <mdz> are we at risk of not having installable armel images for beta?
[14:38] <lool> slangasek: Ack, action me on it if you mlike
[14:39] <slangasek> [ACTION] lool to open per-lib tasks on bug #303232
[14:39] <MootBot> ACTION received:  lool to open per-lib tasks on bug #303232
[14:39] <cjwatson> mdz: I think we'll be OK
[14:39] <cjwatson> the only reason there hasn't been more progress today yet is that there were a couple of very long-running builds in the queue
[14:39] <mdz> cjwatson: ok, thanks
[14:39] <cjwatson> I'll raise a red flag if it's still looking bad on Monday
[14:39] <lool> mdz: For babbage we're at risk of not having images for beta; for the other targets, we're not outputting isos so they are uninstallable rapidly
[14:40] <lool> cjwatson: thanks
[14:40] <lool> did I miss any question?
[14:41] <slangasek> I don't think so
[14:41] <slangasek> and... done digesting, so ready to move on
[14:41] <slangasek> [TOPIC] Kernel team
[14:41] <MootBot> New Topic:  Kernel team
[14:41] <slangasek> pgraner: hi
[14:41] <pgraner> 334994: Degraded RAID boot fails - apw will update with the latest
[14:41] <pgraner> apw: ^^^^
[14:42] <apw> that one is in progress.  have just received a kvm image which should
[14:42] <apw> allow me to reproduce the issue.  looking like an interacton between
[14:42] <apw> kernel and userspace tools at the moment
[14:42] <apw> possibly an interaction between the kernel udev and the madmin recovery
[14:43] <pgraner> LP 326621: kernel support for Ralink rt2870 802.11n - Fix Committed
[14:44] <mdz> will there be kernel uploads during beta freeze?
[14:44] <pgraner> we will realistically have at least one
[14:45] <slangasek> when is that coming?
[14:45] <pgraner> to deal with issues that pop up
[14:45] <slangasek> ("today" would be a good answer)
[14:45] <amitk> slangasek: it should be today
[14:45] <mdz> what is the status of suspend/resume bugs?
[14:45] <mdz> given that's a focus area
[14:45] <pgraner> apw: your turn again
[14:45] <apw> most of the bugs we have are still being investigate
[14:46] <apw> we have a lot of bugs, but no real view on a single low haning fix
[14:46] <apw> we also have those false positives which we will want to push out an
[14:46] <mdz> https://edge.launchpad.net/ubuntu/+source/linux/+bugs?field.tag=suspend shows 276 bugs, *lots* of incomplete but a significant number still new
[14:46] <apw> update to the userspace tools
[14:46] <apw> yes.  regressions are taking priority at the moment
[14:47] <mdz> are the suspend/resume regressions tagged as such?
[14:47] <slangasek> the false-positives are included in that count of 276?
[14:47] <apw> they will be yes
[14:47] <mdz> slangasek: yes, I can see several in the list which are open
[14:47] <mdz> apw commented he thought he had found one of the false positive triggers
[14:47] <mdz> which sounds like it could affect a lot of folks
[14:48] <apw> mdz i haven't tagged any as regressions, but that is a fair point and should be done
[14:48] <apw> yeah i think i have managed to trigger a false positive here, and think i know the underlying cause
[14:48] <mdz> it should be standard practice in triage to read the comments and if they indicate it's a regression, tag it
[14:48] <apw> just need to figure out how it gets left in a mess
[14:48] <slangasek> is there enough information in the false-positives to let QA systematically clean them out?
[14:48] <apw> mdz agree, my bad
[14:48] <apw> slangasek, they are indistingishable unless the user knows they didn't suspend
[14:49] <mdz> slangasek: they generally say "I don't know why I'm seeing this, I didn't notice a problem"
[14:49] <slangasek> ah
[14:49] <apw> but we should put together a standard reply and ask qa to do first dibs touch on all of them
[14:50] <mdz> also, as I mentioned in email to slangasek, I'm concerned about the number of maintainer script failures in the kernel packages
[14:50] <mdz> https://edge.launchpad.net/ubuntu/+source/linux/+bugs?field.tag=apport-package
[14:50] <pgraner> Kernel package installation/upgrade failures https://edge.launchpad.net/ubuntu/+source/linux/+bugs?field.tag=apport-package
[14:51] <slangasek> [LINK] Kernel package installation/upgrade failures https://edge.launchpad.net/ubuntu/+source/linux/+bugs?field.tag=apport-package
[14:51] <MootBot> LINK received:  Kernel package installation/upgrade failures https://edge.launchpad.net/ubuntu/+source/linux/+bugs?field.tag=apport-package
[14:51] <pgraner> I'm asking ogasawara to take a pass thru them and get a better idea of why and how they are happening
[14:51] <mdz> slangasek: many of them look to be related to update-grub
[14:51] <mdz> based on a random sampling
[14:51] <cjwatson> some of those are "victim" failures; the "operation not permitted" ones are due to the casper bug on USB sticks that Evan fixed a little while ago
[14:51] <ogasawara> pgraner: finding a lot of em are really grub issues
[14:51] <cjwatson> (I'm not sure why the linux side of that particular bug is still open)
[14:51] <pgraner> We should have a clear picture early next week
[14:52] <slangasek> yes; a certain amount of that is inevitable based on the limited improvement we were able to make to update-grub to avoid it silently clobbering configs on upgrade
[14:52] <mdz> cjwatson: there are also some random program crashes and such
[14:52] <mdz> but I think there are hints that the maintainer scripts could be made more robust
[14:52] <cjwatson> ogasawara: bug 292159, for your reference
[14:52] <ogasawara> cjwatson: yup, saw a few dups of that bug as well
[14:53] <pitti> I also saw a bug where dpkg was completely hosed
[14:53] <pitti> http://launchpadlibrarian.net/21112577/DpkgTerminalLog.txt
[14:53] <MootBot> LINK received:  http://launchpadlibrarian.net/21112577/DpkgTerminalLog.txt
[14:53] <mdz> a lot of them are on pre-jaunty kernels
[14:53] <mdz> not sure if they're old or being reported on stable
[14:53] <pitti> like someone or something deleted /var/lib/dpkg/info/*.list or so
[14:53] <cjwatson> pitti: right, probably filesystem corruption that will result in a random firehose of bugs to miscellaneous packages
[14:54] <pitti> I generally find a lot of noise and local corruption issues on those package failures
[14:54] <cjwatson> me too
[14:54] <mdz> cjwatson,pitti: let's discuss some heuristics to help filter those out
[14:54] <mdz> (offline)
[14:54] <pitti> yeah, and also better log acquisition to do auto-duplication
[14:54] <mdz> e.g. segfaults should probably never be reported this way
[14:54] <mdz> if it's a real bug, it'll have its own crash report
[14:55] <mdz> pitti: yes, it takes a lot of trawling through DpkgTerminalLog.txt to get to the real problem
[14:56] <mdz> what's the verdict on kerneloops?
[14:56] <pgraner> kerneloops package. We are continuing to fix bugs. The package will stay in universe for Jaunty, we will MIR for Karmic. Foundations team (Keybuk) will be taking ownership for Karmic.
[14:56] <mdz> should probably update the MIR bug accordingly, that's currently an open High importance bug
[14:56] <pitti> it got a lot better with kenvandine_wk's and mdz's fixes yesterday, but it's late indeed
[14:56] <pgraner> mdz: ack I'll do it after the meeting
[14:57] <pitti> and either way this isn't something we'd ever want to enable by default in stables anyway
[14:57] <mdz> I think this is the right thing to do; we didn't get kerneloops working at all until quite late, and it's turning out to have a lot of problems
[14:57] <pitti> so if we want to enable it for beta and disable it again for final, that'd be acceptable from my POV
[14:57] <slangasek> [ACTION] pgraner to update status on the kerneloops MIR bug
[14:57] <MootBot> ACTION received:  pgraner to update status on the kerneloops MIR bug
[14:57] <mdz> pitti: it's not even installed by default at this point (it's in universe), I don't think it's worth trying to add it given the problems
[14:57] <mdz> but we can invite people to opt in by installing the package if you want
[14:58] <mdz> maybe in the beta notes?
[14:58] <pitti> right, some blogging on planet.u.c. might attract just the right interested people
[14:58] <pitti> sounds good to me
[14:58] <pgraner> mdz: I'll blog and release note it
[14:58] <mdz> pitti: we'll probably want to clean up the suspend/resume bugs first, since they currently share the same tag (is there a bug open about that?)
[14:59] <slangasek> [ACTION] pgraner to draft beta release note entry inviting users to install kerneloops
[14:59] <MootBot> ACTION received:  pgraner to draft beta release note entry inviting users to install kerneloops
[14:59] <pgraner> mdz: rtg was fixing it
[14:59] <pgraner> mdz: I'll open a bug to be sure
[14:59] <mdz> pgraner: if it requires more than a trivial change to the script, he should probably reach out to pitti
[14:59] <davidbarth> pgraner: make sure you take the patch for the dialog box (should be integrated since yesterday); ie don't rely on the fallback dialog on n.osd
[15:00] <mdz> davidbarth: yes, that's done
[15:00] <pitti> indeed, they are still apport.report.Report(type='KernelOops')
[15:00] <pitti> they shouldn't be
[15:00] <pgraner> mdz: ack
[15:00] <pitti> mdz: it's not truly trivial, since the type determines some UI strings
[15:00] <pgraner> davidbarth: got it
[15:00] <slangasek> pitti: is there an action item there for you?
[15:01] <pitti> slangasek: I guess so
[15:01] <pgraner> slangasek: for me to file a bug and get some help
[15:01] <apw> pitti, is not the error there tho, that its KernelOoops in stead of KernelProblem
[15:01] <apw> not that the share a type
[15:01] <pitti> apw: well, but the Type: field determines thet ag
[15:01] <slangasek> [ACTION] pgraner to file a bug regarding wrong tag on kernel suspend/resume bugs and solicit pitti's help
[15:01] <MootBot> ACTION received:  pgraner to file a bug regarding wrong tag on kernel suspend/resume bugs and solicit pitti's help
[15:01] <mdz> apw: KernelProblem isn't a valid type, only KernelCrash and KernelOops
[15:01] <pitti> apw: and if you want to tell apart suspend/resume problems from oopses, they need to have a different type, so that they get a different tag
[15:02] <mdz> (neither of which is appropriate for a suspend/resume failure)
[15:02] <pitti> apw: or do you want to filter by bug title?
[15:02] <mdz> pitti/apw: (offline?)
[15:02] <pitti> ack
[15:02] <slangasek> please take further discussion out of band, we're running behind
[15:02] <pgraner> An FYI for everyone, the MX51 kernel will *not* have AppArmor enabled, it has huge issues on ARM. amitk can provide details offline if anyone is interested.
[15:02] <apw> ack
[15:02] <slangasek> [TOPIC] Foundations team
[15:02] <MootBot> New Topic:  Foundations team
[15:02] <cjwatson> so due to me screwing up the time I don't have our release status page updated, sorry about that; but the bug count is quite low so I'll just comment here
[15:03] <cjwatson> 44194 - moves of various libraries to /lib in the archive now, but wpasupplicant still needs to be syslogified before we can fix this; apparently this has now landed upstream which should make it straightforward to finish off after beta
[15:03] <cjwatson> 323108 - mvo just hasn't quite had time yet, but will look at it tomorrow or early next week and is still optimistic for beta; not as important as it looks since update-notifier will nag about it eventually
[15:03] <cjwatson> 334284 - evand has made this a lot better than it was, but it's still a bit off. We'll finish this after beta
[15:03] <cjwatson> also still trying to get 337306 fixed, which is quite nasty for server OEM users
[15:03] <cjwatson> and a couple of us have been beating on the lpia shlibdeps problem that doko identified, which has required a number of rebuilds
[15:03] <cjwatson> slangasek gave us approval to keep going on that into beta freeze, since we were over halfway through already, so hopefully we'll finish that
[15:04] <cjwatson> finally have also been trying to beat down the number of uninstallables across the board to achieve some kind of reasonable archive consistency for beta
[15:04] <cjwatson> Debian added some new sections to their archive recently, which caught us a bit by surprise and meant that a few recent syncs/merges have failed
[15:04] <slangasek> the lpia rebuilds are rather beta-critical, to the extent that they might leave packages installable but missing libs
[15:05] <cjwatson> the Soyuz guys are dealing with that as a matter of urgency and I've moved all our existing packages out of the obsolete 'base' section, which in fairness we ought to have done years ago
[15:05] <slangasek> (at least for anything in the default system)
[15:05] <cjwatson> right, some of that has been slowed by running into build failures
[15:05] <cjwatson> which tuned me into the uninstallables problem on ports
[15:06] <cjwatson> but no major worries from our team AFAICS, beyond that
[15:06] <slangasek> 334284 - seems like a rather high-profile installer UI blemish, should we release-note that for beta as well?
[15:06] <cjwatson> it is, although the points are much less far out than they were in an earlier version
[15:06] <slangasek> ok
[15:06] <cjwatson> but yes, I think that will probably deserve a release note; action me
[15:07] <slangasek> [ACTION] cjwatson to document bug #334284 for beta release notes
[15:07] <MootBot> ACTION received:  cjwatson to document bug #334284 for beta release notes
[15:08] <cjwatson> I'm done, if you want to move on
[15:08] <slangasek> yep, no other questions here - thansk
[15:08] <slangasek> [TOPIC] Server team
[15:08] <MootBot> New Topic:  Server team
[15:08] <slangasek> dendrobates: hi
[15:08] <dendrobates> hi
[15:09] <dendrobates> kirkland has turned over some debugging infor to Andy on  bug 334994
[15:10] <dendrobates> Apart from that we seem to be ok.
[15:10] <dendrobates> the likewise-open ffe went through this week.
[15:10] <mdz> dendrobates: please read the agenda; there's a bug on there requesting status from you
[15:10] <slangasek> I think I saw some bug states moving around on #341159?
[15:10] <mdz> 341159: dkms handling of non-default kernel flavors
[15:12] <slangasek> dendrobates: I don't recall seeing a likewise-open FFe bug, and I still see likewise-open 4.1 in jaunty - what do you mean "went through"?
[15:12] <mdz> slangasek: dendrobates said earlier this week that likewise-open 5 was going to universe, and we are staying with v4 for 9.04
[15:12] <dendrobates> slangasek: we are keeping 4.1 in main and putting 5 in universe
[15:12] <slangasek> right, status on 341159 is "wontfixed the other tasks"
[15:12] <slangasek> ah
[15:13] <slangasek> that explains why I wasn't seeing it where I was looking :)
[15:13] <slangasek> has likewise-open5 gotten its pam integration fixed?
[15:14] <dendrobates> slangasek: yes, but it does not cleanly upgrade from 4.1, hence the universe.
[15:14] <mdz> dendrobates: there are several High bugs on http://qa.ubuntu.com/reports/team-assigned/canonical-server-assigned-bug-tasks.html
[15:14] <slangasek> ok
[15:14] <dendrobates> sbug 341159
[15:15] <dendrobates> bug 341159
[15:15] <mdz> and 18 Undecided
[15:16] <mdz> dendrobates: ayt?
[15:16] <dendrobates> mdz: I haven't had time to review all the bugs since my return, my team reported no critical bugs.
[15:17] <mdz> I understand IS testing will begin very soon, please make sure that any resulting bugs end up on your radar
[15:17] <dendrobates> mdz: ack
[15:18] <slangasek> moving on?
[15:18] <dendrobates> yep
[15:18] <mdz> no more from me
[15:18] <slangasek> [TOPIC] MOTU
[15:18] <MootBot> New Topic:  MOTU
[15:18] <slangasek> ScottK: hi
[15:18] <ScottK> hello
[15:19] <ScottK> Python 2.6 is still the main source of excitement.
[15:19]  * slangasek nods
[15:19] <ScottK> There's plenty left to do and I imagine there will be until final freeze.
[15:19] <ScottK> Process wise we've started public discussion of a motu-release charter.
[15:20] <doko> ScottK: are these not yet converted packages? or packages where upstream doesn't have 2.6 support yet?
[15:20] <ScottK> Up to now we've pretty much just done stuff ....
[15:20] <ScottK> doko: It's a mix.
[15:20] <slangasek> bug #338079 is the high-profile python-4suite 2.6 compat bug
[15:20] <ScottK> Personally I haven't had a lot of time to spend on it this week as $WORK has gotten busy.
[15:21] <ScottK> This still unresolved, but at least upstream has shown some interest.
[15:21] <ScottK> I don't think there's anything else that needs to be brought up.
[15:22] <slangasek> hmm, upstream seems to be unable to reproduce the build hangs that I saw; is someone (dktrkranz?) taking responsibility for interfacing with upstream on that bug?
[15:22] <ScottK> Yes.  So work is being done, but no idea if we'll get it sorted.
[15:22] <slangasek> ok
[15:23] <slangasek> ScottK: thanks
[15:23] <ScottK> I should probably toss in https://wiki.ubuntu.com/MOTU/MOTUReleaseCharter if anyone is interested.
[15:23] <slangasek> [LINK] https://wiki.ubuntu.com/MOTU/MOTUReleaseCharter
[15:23] <MootBot> LINK received:  https://wiki.ubuntu.com/MOTU/MOTUReleaseCharter
[15:24] <slangasek> [TOPIC] Known regressions
[15:24] <MootBot> New Topic:  Known regressions
[15:25] <slangasek> as noted earlier, we have some work to do on triaging the regression-potential bugs; overall these seem to be under control
[15:25] <mdz> slangasek: I just noticed they don't show up on the weather report, and perhaps it would be useful if they did?
[15:26] <slangasek> there were very few bugs that needed to be highlighted for alpha6, those that were are pretty well-known by this point
[15:27] <mdz> slangasek: shameless plug for bug 328035?
[15:27] <slangasek> mdz: I don't think it's a good "weather" indicator since we don't expect to be completely regression-free as a criterion for release; I prefer to just make sure the regressions get release-targeted if they're critical
[15:28] <mdz> slangasek: maybe regression-potential+>=High would be useful
[15:28] <slangasek> mdz: well, I'll continue abusing my video inputs today, but I can't reproduce that bug now so I think it's all on you :)
[15:28] <mdz> slangasek: do you have a simple method to determine whether a random crash is caused by that bug or something else?
[15:28] <mdz> I only noticed by stracing
[15:29] <mdz> (bah, let's take this out of band)
[15:29] <slangasek> ack
[15:29] <ScottK> If we're shamelessly plugging, I'll throw out Bug 290153.
[15:30] <slangasek> regression-potential+high - I think it's still possible we would release with such a bug in some reasonable cases, so the weather report would never go green for that item
[15:30] <sbeattie> ScottK: wasn't that also a problem in intrepid?
[15:30] <ScottK> sbeattie: It is.  It's a regression from hardy that's still unresolved.
[15:31] <sbeattie> ScottK: generally, we tag those as regression-release, to differentiate from regressions introduced by the current development release.
[15:32] <ScottK> Two weeks ago I got told it should have both tags.
[15:32] <mdz> sbeattie: you will triage the list and ensure they all have importance set, yes?
[15:32] <sbeattie> mdz: yes
[15:32] <mdz> dendrobates: there are several regressions assigned to canonical-server
[15:32] <mdz> dendrobates: these need your attention to assign them out to your team
[15:33] <mdz> I see two New/Undecided hotkey regressions on the list
[15:33] <mdz> slangasek: I find http://qa.ubuntu.com/reports/regression/regression_tracker.html a more useful overview than the launchpad URL you gave in the agenda
[15:33] <mdz> (e.g. it shows assignee)
[15:34] <mdz> there are quite a few with no assignee; who is expected to do that? sbeattie?
[15:34] <sbeattie> mdz: yes.
[15:34] <pitti> slangasek: speaking of hotkeys, with acpi-fakekey not working, does it make much sense to keep those bits in acpi-support?
[15:34] <mdz> sbeattie: I count 25 unassigned
[15:34] <pitti> I guess many hotkey regressions are coming from that, since acpi-support doesn't actually work any more
[15:34] <slangasek> hmm; I continue to assume that the regression lists are intended primarily as input into the release targeting process
[15:35] <slangasek> pitti: which bits, acpi-fakekey itself or scripts that use it?
[15:35] <pitti> slangasek: both actually
[15:35] <slangasek> pitti: I think it's useful to keep the latter as documentation until we can move it somewhere else
[15:35] <pitti> slangasek: given that the scripts don't work if acpi-fakekey doesn't work?
[15:36] <slangasek> pitti: also, there's a chance that acpi-fakekey *happens* to work for some systems+keys
[15:36] <pitti> slangasek: oh, does it? okay; I thought it was completely broken
[15:36] <slangasek> sbeattie, ScottK: I think it's reasonable for release regressions still present in the current release to also carry the regression-potential tag?
[15:37] <slangasek> anyway, need to move on here, still have one more item and it's non-null :P
[15:37] <slangasek> [TOPIC] ISO size
[15:37] <MootBot> New Topic:  ISO size
[15:37] <slangasek> the Ubuntu dailies have all gone oversized in the past week
[15:38] <cjwatson> this is mostly delta language packs, isn't it?
[15:38] <slangasek> and unfortunately it happened all at once when some deps that were mysteriously absent from the ISO popped back in and added 5MB, so I don't know (yet) where the size went
[15:38] <mdz> can you attribute the increase to something specific?
[15:38] <cjwatson> I admit I haven't done a detailed comparison
[15:39] <mdz> cjwatson: do you have a script for that?
[15:39] <cjwatson> mdz: slangasek does, cd-size-analysis on antimony
[15:39] <slangasek> I'm going to work on getting us to where we can get ongoing meaningful comparisons of package sizes
[15:39] <slangasek> that script depends on the .debs being on disk still
[15:39] <cjwatson> right
[15:39] <slangasek> so fails miserably in many cases
[15:39] <cjwatson> we're due new base language packs on Monday, in any case
[15:40] <slangasek> anyway, it could be langpacks, in which case we'll see significant improvement with the full langpack export which I believe is in progress now
[15:40] <slangasek> other than that... now is not a good time to ask to add anything to the CDs ;)
[15:40] <slangasek> and I'll hopefully know more by Monday
[15:41] <slangasek> but as usual, if anyone has brilliant ideas for saving space...
[15:41] <cjwatson> slangasek: are you taking the action to look into this in more detail, or do I/somebody-else need to?
[15:41] <slangasek> [ACTION] slangasek to find out where our CD space went
[15:41] <MootBot> ACTION received:  slangasek to find out where our CD space went
[15:42] <slangasek> that's it, then
[15:42] <slangasek> AOB?
[15:42] <pitti> slangasek: I can probably squeeze out 0.5 MB of live CD space with some package fixes to remove gconf translations
[15:43] <pitti> (compiz, totem, mousetweaks, devhelp)
[15:43] <pitti> ah, devhelp isn't on CD
[15:43] <slangasek> .5MB> I expect that's worth doing
[15:43] <pitti> there's not a lot of air left in /usr/share/gconf/schemas/, though
[15:44]  * slangasek nods
[15:44] <slangasek> ok - any other space-saving schemes we can discuss out-of-band
[15:44] <slangasek> #endmeeting
[15:44] <MootBot> Meeting finished at 10:44.
[15:44] <pitti> thanks everyone
[15:44] <slangasek> thanks, all
[15:49] <lool> mdz: ( http://vbox.innotek.de/pipermail/vbox-announce/2009-March/000013.html )
[15:49] <lool> 3D support in linux hosts in dev release
[16:26] <GrueMaster> lool:  VirtualBox has had GL support on the Linux Host since 2.1 (maybe 2.0).  What 2.2 adds is GL support to the Linux Client drivers.
[16:27] <GrueMaster> (I know because I have been using it since 2007).
[16:27] <lool> GrueMaster: Are you sure?  I read earlier a news from december 2008 that it just got GL guest support but only for windows hosts
[16:27] <lool> and then this news that they add GL support for linux hosts
[16:27] <lool> GrueMaster: Ah perhaps it's virtualbox versus virtualbox-ose
[16:28] <GrueMaster> possible.
[16:28] <GrueMaster> The note I see (from your link is "* OpenGL 3d acceleration for Linux guests "