=== kamalm is now known as kamalm-away === doko__ is now known as doko === jamie is now known as Guest31141 === zul is now known as sorensbot === sorensbot is now known as zul === kamalm-away is now known as kamalm === jsalisbury_ is now known as jsalisbury [16:01] o/ [16:01] * slangasek waves [16:02] * marjo waves [16:02] o/ [16:02] * ogasawara waves [16:02] o/ [16:02] #startmeeting [16:02] Meeting started at 11:02. The chair is slangasek. [16:02] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [16:02] [LINK] https://wiki.ubuntu.com/ReleaseTeam/Meeting/2010-03-26 [16:02] LINK received: https://wiki.ubuntu.com/ReleaseTeam/Meeting/2010-03-26 [16:02] pitti: I'll be giving the Kubuntu report today since Riddell is away. [16:02] o/ [16:03] [TOPIC] Actions from previous meetings [16:03] New Topic: Actions from previous meetings [16:03] * review status of branding for Kubuntu, Edubuntu next week [16:03] * asac to talk to mozilla upstream about the need for system cairo in Ubuntu [16:03] o/ [16:03] * ScottK, slangasek to review python sync/merge candidates [16:03] * pitti to get people to investigate #528524 [16:03] * pitti to file bug about sound indicator being muted [16:03] sorry, I'll be "really" here in a minute; firefox ate all my tabs [16:03] slangasek: sound indicator bug filed, conor is debugging it [16:03] ScottK: any progress on branding? [16:04] stgraber: ^^ [16:04] pitti: ok, great! [16:04] slangasek: Nope. Silence. [16:04] asac: have you reached out to Mozilla upstream? [16:04] and #528524 made some progress [16:04] ScottK: mm [16:04] slangasek: awaiting reponse from them today on the cairo bug. they want to pursue this upstream and have assigned a dev to it (so it gets finally resolved).. if we dont get anything by monday we will go with what we have and replace it when they have a real solution [16:04] [ACTION] slangasek to shake the branding tree and see what falls out [16:04] ACTION received: slangasek to shake the branding tree and see what falls out [16:04] slangasek: wrt. mozilla, we decided to go ahead and apply the patch in the firefox source; Chris Coulson did that, but now it's looking worse than before, so investigations ongoing [16:04] slangasek: We need to think about if this is something we'd really want to touch after beta 2, but having an Ubuntu splash on Kubuntu is going to make a lot of users not happy. [16:05] asac: that's a reasonable timeline, thanks. Is Mozilla aware of this Monday deadline? [16:05] pitti: er, heh [16:05] slangasek: yes, they are aware of the urgency [16:05] pitti: interesting. was that local build? [16:05] yes [16:05] ok fine [16:06] pitti: 528524 - ok, good; is there a further action item there? Is Luke the correct assignee to carry it forward? [16:06] *nng*, firefox, start [16:07] slangasek: it should probably be reassigned to crimsun, he's currently working on it [16:07] done [16:08] ScottK: yes, I really wouldn't like us to be changing this post-beta2, so I'll see what I can do to get things moving [16:09] ScottK: python sync/merge - I have time for that today if you do [16:09] Possibly. [16:10] * slangasek nods [16:10] [TOPIC] QA Team [16:10] New Topic: QA Team [16:10] marjo: hello [16:10] * Hardware testing [16:10] http://people.canonical.com/~fader/hw-testing/current.html [16:10] Netbook: [16:10] passed: 11 (79%) failed: 1 ( 7%) untested: 2 (14%) [16:10] Laptop: [16:10] passed: 32 (100%) failed: 0 ( 0%) untested: 0 ( 0%) [16:10] LINK received: http://people.canonical.com/~fader/hw-testing/current.html [16:10] Server: [16:10] passed: 63 (91%) failed: 0 ( 0%) untested: 6 ( 9%) [16:10] Desktop: [16:10] passed: 13 (100%) failed: 0 ( 0%) untested: 0 ( 0%) [16:11] per asac's request: [16:11] * Beta 1 Outstanding Serious Bugs Status [16:11] http://people.canonical.com/~marjomercado/isotestingbugs.html [16:11] LINK received: http://people.canonical.com/~marjomercado/isotestingbugs.html [16:11] hah [16:11] asac: better? [16:12] marjo: can we get an assignee column in that list? [16:12] looks nice. [16:12] if we can, a variant would supersede some hacking work I've been doing [16:12] cjwatson: will do, thx for feedback [16:12] marjo: looks nice - though it looks like bugs that were referenced more than once are repeated, would be nice to fix that :) [16:12] cjwatson: ok, working w/ bdmurray on improvements for usability [16:12] still some weird dups in that list [16:12] slangasek: ditto re bdmurray's help [16:13] can we get bugs actively *off* that list without fixing them? bug 527377 has been true forever [16:13] Launchpad bug 527377 in ubiquity "on resize mode i can't choose in which disk install to" [Undecided,Confirmed] https://launchpad.net/bugs/527377 [16:13] marjo: anything we need to discuss re: the 8 machines not yet tested for hw testing? [16:13] cjwatson: sure, we can consider that [16:14] slangasek: We're actively looking at all of them. The two netbooks we can test with a USB installer so they're certain to get tested soon [16:14] slangasek: not really, they're basically on deck [16:14] mind you, I can just dup that bug [16:15] cjwatson: go for it! [16:15] The dead HP server is dependent on HP getting it fixed and back to us; the one that needs a serial dongle should be up by EOD today [16:15] marjo, fader_: ok. also, in past cycles there's been hw that was not yet provisioned that as a result wasn't even listed as "untested" - is there anything like that pending this cycle? [16:15] slangasek: Yes, anything we don't physically have is not reflected in this report. As I receive hardware I add it to the list [16:16] slangasek: i think that's the proper way, doesn't make sense to list "not yet provisioned" [16:17] +1, especially as we're never 100% certain when or even if we will get all the hardware that is targeted :/ [16:17] marjo: if it's hardware that we have an obligation to get provisioned and certified before it's too late to change 10.04 to fix anything, I think we do need to have it on the radar [16:17] (but I have no visibility into what hw we might have such obligations on...) [16:17] slangasek: agree, will consider [16:18] slangasek: yes, that needs to be considered in the reporting [16:18] next topic ok? [16:18] marjo: can I give you an action item to check on this? [16:18] slangasek: please do [16:19] [ACTION] marjo to confirm whether there are committments to certify any hardware for 10.04 that's not yet provisioned [16:19] ACTION received: marjo to confirm whether there are committments to certify any hardware for 10.04 that's not yet provisioned [16:19] next topic [16:19] Lucid Quality (wrt Bugs) Status Report [16:19] 34 days left and 322 bug tasks to fix [16:19] Barring no new work - we need to fix 9 bug tasks a day now [16:19] The Canonical Desktop Team needs to deal with 21 bug tasks [16:19] Chris Coulson is the most overtasked with 10 bug tasks [16:19] Martin Pitt is rockin' with 66 bug tasks fixed [16:19] Yesterday's hero was Martin Pitt with 2 bug tasks fixed [16:20] not exactly 34 days, due to final freeze milestone [16:20] and the day before yesterday, the hero was Martin Pitt. [16:20] I talked with Chris about his' [16:20] the day before yesterday was actually Dustin! ;-) [16:20] he said he has fixes for many of them already, and the firefox ones will be fixed in one go [16:20] hah! [16:21] :-) [16:21] Dustin and I have a permanent race on http://qa.ubuntu.com/reports/bug-fixing/lucid-fixes-report.html, yes :) [16:21] we are trying to help him, he releases most of the team fixes. [16:21] (oh, on par again .. /me pedals harder) [16:21] Specs Status [16:21] http://people.canonical.com/~pitti/workitems/canonical-platform-qa-ubuntu-10.04-beta-2.html [16:21] https://blueprints.launchpad.net/ubuntu/+spec/lucid-qa-bugs-hwdb-querying [16:21] Status: On track [16:21] https://blueprints.launchpad.net/ubuntu/+spec/lucid-qa-bugs-hwdb-querying [16:21] Status: On track [16:21] LINK received: http://people.canonical.com/~pitti/workitems/canonical-platform-qa-ubuntu-10.04-beta-2.html [16:22] slangasek: Bug:530380: checkbox writes to .cache/checkbox/submission before submission completes [16:22] Status: cr3 has submitted the merge request. Waiting for review by release team. [16:22] that's it folks [16:22] thanks for all the feedback [16:22] hope you find the reports useful to focus your work on quality! [16:22] slangasek: that's it from QA team [16:23] ok, thanks! [16:23] any questions from anyone? [16:23] [TOPIC] Server Team [16:23] New Topic: Server Team [16:23] ttx: hi [16:23] o/ [16:24] So we are in good shape with beta2-targeted bugs, mostly thanks to a eucalyptus sprint where smoser, mathiaz and kirkland have been fixing the euca beta2-targeted issues [16:24] The others should all get fixed by beta2Freeze [16:24] I'll mention bug 522509 being blocked by a FFe [16:24] Launchpad bug 522509 in tftp-hpa "[FFE] tftpd-hpa doesn't start on boot" [High,In progress] https://launchpad.net/bugs/522509 === yofel_ is now known as yofel [16:24] ... which might not be necessary (conversion to upstart is a feature ?) [16:25] Ah, I forgot to paste the link [16:25] https://wiki.ubuntu.com/ServerTeam/ReleaseStatus [16:25] makes it easier to follow ;) [16:25] [LINK] https://wiki.ubuntu.com/ServerTeam/ReleaseStatus [16:25] LINK received: https://wiki.ubuntu.com/ServerTeam/ReleaseStatus [16:25] Questions about our beta2-targeted bugs ? [16:26] well, upstart jobs are all still supposed to be passed to Foundations for review prior to upload, so an FFe works as well as anything for that [16:26] slangasek: ok :) [16:26] I can review this today [16:26] cool, thanks [16:26] On the specs side, looking at High specs < 75 % completion: [16:27] server-lucid-uec-testing (33% completion): Incompatibilities between testrig and installer capabilities threaten multi-network automated testing, in which case we'll switch to manual testing. The rest is on track. [16:27] server-lucid-papercuts (33% completion): On track, one work item per week. 11 targets, 36% fixed [16:27] will work next week on improving that score [16:27] server-lucid-eucalyptus-merging-and-packaging (71% completion) is onn track [16:27] server-lucid-ec2-ebsroot (0%): just a cleanup script is missing, should be completed by Tuesday [16:28] Bugs affecting server, in other teams: [16:28] bug 531494: upstart does not run cloud-init job (Foundations) [16:28] Launchpad bug 531494 in upstart "cloud-init job sometimes not running in cloud images without ramdisk" [Critical,Confirmed] https://launchpad.net/bugs/531494 [16:28] ttx: is mathiaz actively working on the openldap bugs? I can easily see those overrunning the beta freeze if he doesn't get an early start on them [16:28] I couldn't get an updated status from him on those [16:28] I'll watch ethm and possibly help [16:29] ok [16:29] I've been discussing this bug with cjwatson [16:29] ttx: great job of ubuntu team [16:29] since foundations need to prioritize where they spend their upstart/plymouth efforts [16:29] we have a way to trigger the bug much less often, which is the workaround we did for beta1 [16:29] (re-enable ramdisks) [16:30] so we'll reenable them for lucid. Doesn't mean the bug shouldn't get fixed [16:30] since it's a race that can certainly still be lost [16:30] some questions remains around the EC2 images [16:30] "less often" - that hardly sounds like something we want to leave you with for release [16:30] since they ship without ramdisk for quite some time in Lucid now [16:31] slangasek: taht was an overstatement [16:31] we never lost the race so far with ramdisk enabled [16:31] but we still fear the race could be lost. [16:31] shouldn't get fixed => the problem is that the cause of the bug has not been isolated [16:31] I don't think a fix is going to be practical at this point [16:31] ttx: ah, ok [16:31] and it's impractical to expect foundations to isolate the causes of bugs that are only replicable on cloud systems [16:31] (since only server are familiar with them) [16:32] let's say that needs some combined expertise. But I agree your efforts are better spent elsewhere right now [16:32] the problem is the length of the "right now" [16:32] * slangasek nods [16:32] so we still need to decide what's best for EC2 image, before Beta2freeze ideally [16:33] bug 527208: EC2 kernel fails to boot in c1.xlarge (Kernel) [16:33] Launchpad bug 527208 in linux-ec2 "ec2 instance fails boot, no console output on c1.xlarge" [High,Confirmed] https://launchpad.net/bugs/527208 [16:33] I believe that, legally speaking, the age at which I will not have a million things clamoring for my attention is 65 in this country ;-) [16:33] could we clone you ? [16:33] ttx: I have indicated that I would be amenable to this approach, yes ;-) [16:33] I didn't get an update from jjohansen on this one [16:34] it was in good shape last time he reported about it, so I wonder why it's still open [16:34] ogasawara: ^^ do you know where that bug sits? [16:34] "in good shape" how? [16:34] The others are well-known issues about installer [16:34] "slangasek: fix tested and working" [16:34] ok [16:34] bug 527401, bug 539324 and bug 546929 [16:35] Launchpad bug 527401 in partman-base "grub-installer fails to install on a raid1 array" [High,Fix released] https://launchpad.net/bugs/527401 [16:35] Launchpad bug 539324 in debian-installer "Setting up swap fails when setting lvm+encryption" [High,Confirmed] https://launchpad.net/bugs/539324 [16:35] Launchpad bug 546929 in linux "most PATA/SATA modules missing in Lucid netboot" [Critical,Fix committed] https://launchpad.net/bugs/546929 [16:35] * JFo looks those over [16:35] the first one's done, you're out of date :) [16:35] beh [16:35] Other/future issues expected to impact the Lucid release: [16:35] smb promised that the third would be uploaded today [16:35] cjwatson, Yep working on that [16:35] ttx, slangasek: I'll get with jj when he gets back from vaca about it's current status [16:35] Rising controversy from an otherwise-calm community about missing server boot messages [16:36] The opinions are pretty one sided on that. [16:36] I discussed it with cjwatson and I think we ahve an agreement that the default server boot should be more verbose [16:36] and not hide any init.d output [16:36] ttx: 546929 should have a fix uploaded today [16:36] ttx: hum, plymouth doesn't give us many options there; we have one dip switch for "verbose", and that's to turn off splash [16:37] anything else requires plymouth development work [16:37] huh [16:37] cjwatson mentioned other possibilities [16:37] it gives you lots of options [16:37] there's a "details" plugin, I'm given to understand [16:37] Keybuk: that don't require feature work? [16:37] slangasek: indeed [16:37] the problem isn't Plymouth [16:37] we have bug 542666, but it's about one side of the issues (suppressed init.d output) [16:37] Launchpad bug 542666 in upstart "No verbose output on ubuntu-server" [Undecided,New] https://launchpad.net/bugs/542666 [16:37] not really default behavior [16:37] cjwatson: well, that gives *lots* of details (and is what happens when you disable 'splash') [16:38] Plymouth has lots of features to capture console output and log them, and allow plugins to display them [16:38] you can even write graphical plugins with scrolling boot messages [16:38] Keybuk: I'm including "plymouth theme work" in "plymouth development work" [16:38] the problem is that in Ubuntu, right now, we don't connect the init.d scripts to the console :p [16:38] I don't think the server folk want anything graphical [16:38] cjwatson: I guess I need to file a better bug about "verbose text boot by default" ? [16:38] slangasek: details behaves like this bu default [16:38] cjwatson: Mark does AIUI [16:38] that being said [16:38] Keybuk: so I've vaguely heard, but ttx didn't seem to know about this [16:39] those following bzr may have noticed that I've subtly arranged the packages so that server simply need to not seed a plymouth-theme-* package ;-) [16:39] and if the server tech lead doesn't, I'm assuming that it has not been very clearly stated [16:39] and jib is with me, FWIW [16:39] and then they'll have details.so only [16:39] One issue i've heard about is using Plymouth with a serial console, i haven't yet tried this. [16:39] ttx: if you and jib tell me not to seed a graphical theme ... I will not do so [16:39] Keybuk: works for me :) [16:40] (you have to tell me not to :p) [16:40] that's about it from me [16:40] alrighty [16:40] any other questions for server? [16:40] slangasek: just one note [16:40] if the initramfs-tools update I just did works [16:40] cjwatson: should I file a bug about default text verbose boot for server ? If which, against which package ? plymouth ? [16:40] then I'm happy to re-enable "console output" for init.d scripts [16:41] since Plymouth will capture it all anyway [16:41] should it also be re-enabled for other upstart jobs? [16:42] slangasek: the easiest thing will be just to change the default inside Upstart [16:42] ttx: file it on ubuntu-meta, subscribe me, and we'll take it from there [16:42] ok [16:42] Keybuk: easiest; but safe? [16:42] since we know we'll at least need a seed change [16:42] slangasek: I can't think of any danger [16:43] Keybuk: I can't either, but I think I'd like that change to happen before b2 freeze if it's going to so we have time to notice issues and back it out [16:43] slangasek: *nods* [16:43] I plan to have this plymouth package uploaded by three days ago [16:43] excellent, I'll test it yesterday [16:43] [TOPIC] Mobile Team [16:43] New Topic: Mobile Team [16:43] asac: hi :) [16:43] hi [16:44] [LINK] https://wiki.ubuntu.com/MobileTeam/ReleaseStatus/Lucid [16:44] LINK received: https://wiki.ubuntu.com/MobileTeam/ReleaseStatus/Lucid [16:44] so openoffice fix uploaded. somehow the build is still in queue [16:44] so pending verification [16:44] omap enablement is chunk of work now for rest of cycle [16:45] it didnt went as well as hoped [16:45] but thats expected [16:45] kernel is broken, but seems on track to be fixed by amitk [16:45] hum, the bug had said there was a successful build of OOo already, oops [16:45] all i know is that we havent verified the latest upload on our own :) [16:46] so omap being a bit behind made a late MIR for x-loader and uboot go away [16:46] we will rely on the flash being properly setup for omap this cycle [16:46] asac: oh, there's a 3.2.0-4ubuntu2 upload as of 9h ago, with unrelated changes - is -4ubuntu1 tested at all? [16:46] i think -4ubuntu1 was what doko was referring to in his comment [16:46] slangasek: right. its not tested by our QA and i dont believe it until they confirm [16:46] (is it still installable, or does the reupload break that? if it's not installable, can I suggest grabbing the dependencies from the librarian by hand?) [16:46] ;) [16:47] unless we want more testers that should be closed [16:47] but its probably fixed [16:47] slangasek: we will get that verified today [16:47] right - if there's enough doubt about the fix to be keeping the bug open, then you shouldn't be waiting until Monday for -4ubuntu2 to be built on arm [16:48] *nod* [16:48] for the omap image building we could need some help from a cdimage person, StevenK integrated my build scripts, we have livefses but somehow no actual image comes out on the rear end [16:48] I think it was closed, but doko reopened it again because debian/copyright was wrong or so [16:48] i cant find any problem looking at the code [16:48] (doko tested it and said OO.o was working fine on arm now..) [16:48] ogra: I checked that the notice is removed in 4ubuntu2 [16:49] doko, great, so it can be fully closed now [16:49] ogra, asac: I need to talk to someone about this omap stuff and what our expectations for release are, because this was never mentioned when https://wiki.ubuntu.com/LucidLynx/ReleaseManifest was being put together and I expect anything we do there for 10.04 to land *very* rough [16:49] slangasek: yes, sory for that [16:49] slangasek: we can go over that on monday [16:50] [ACTION] slangasek, asac to discuss omap plans for 10.04 [16:50] ACTION received: slangasek, asac to discuss omap plans for 10.04 [16:50] slangasek, we dont do any special effort, userspace works as well as on other armel, the only issues are kernel related for 10.04 there is a "as good as it gets" approach [16:51] ogra: yes, I want things pinned down a bit more specifically then that; will discuss with asac on Monday as suggested [16:51] so on spec front only thing that is missing is email webservices, where i waited for permission to use icons of the mail providers ... i think this wont happen, so i am redoing bits of the integration to work well without icons. that will go up asap then we are set [16:52] asac: you have bug #532733 on your list, which is marked 'medium' - bump to 'high'? [16:52] Launchpad bug 532733 in qemu-kvm "apt/dpkg in qemu-system-arm hangs if a big task is installed" [Medium,Confirmed] https://launchpad.net/bugs/532733 [16:53] slangasek: yes, we can make that high [16:53] higs seems appropriate ... [16:53] we have no lead on that though [16:53] you've marked it as a blocker and said it should be RC, so 'high' [16:53] yes [16:53] done [16:54] anything else? [16:54] the few thumb2 porting bugs will get resolved before beta-2 === zul_ is now known as zul [16:54] either by getting the real fix or by dropping to -marm ... [16:54] its two that have no fix according to my book [16:55] * slangasek nods [16:55] besides from that we are done [16:55] any questions for mobile? [16:56] [TOPIC] Kernel Team [16:56] New Topic: Kernel Team [16:56] thanks ;) [16:56] Overall Kernel Team status is summarised at the first URL below, including the items called out in the agenda. Beta-2 activity is summarised at the second URL below, with items pushed out shown as At Risk. The burndown chart for Beta-2 is at the third URL, and our burndown chart is at the fourth: [16:56] [LINK] https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Lucid [16:56] [LINK] https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Lucid#Milestone%20ubuntu-10.04-beta-2 [16:56] [LINK] http://people.canonical.com/~pitti/workitems/canonical-kernel-team-ubuntu-10.04-beta-2.html [16:56] [LINK] http://people.canonical.com/~pitti/workitems/canonical-kernel-team.svg [16:56] asac: thank you! [16:56] Of the pushed out Beta-1 items, the investigative tasks are either complete or on track to be complete by beta-2. The remaining items should be nearing completion with patches awaiting final review, test, and upload. [16:56] On the items pulled out on the agenda, our blueprint status is as follows: [16:56] * The KMS strategy review has one bug In Progress with test kernels built and posted. The other bug is still under investigation. The remaining work item is investigative and should be on track to complete by beta 2. [16:56] * The ureadahead optimisation work remains to be tested but is a small patch kernel side and does not impact any features. [16:56] * Apparmor development saw another push to LKML this week and is still hoping to hit the 2.6.34 release. [16:56] * The configuration review is complete and patches to pull out some built-in drivers have been committed and released. [16:56] * For bug handling, the documentation review is now complete and a re-work of the kernel team wiki's is underway. [16:56] * The investigation of ALSA quirks which could likely leverage the device tree work has been postponed to M. [16:57] Our list of bugs on the agenda grew quite substantially this week compared to last. I've posted a status summary for each bug on our release status page, https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Lucid . Patches and/or test kernels have been posted for the majority. Bug 491210 doesn't seem to have been confirmed to exist with Lucid so I'm questioning if this should really be milestoned for beta-2 at the moment. [16:57] I also assigned bug 544741 to our team to get futher investigation. I'll get with apw asap when he returns to try to get kernels uploaded with fixes for the majority and avoid having to SRU these. An upload should be happening today to close out bug 546929. [16:57] Launchpad bug 491210 in linux "[i865G] Monitor Resolution limited to 800x600" [High,Confirmed] https://launchpad.net/bugs/491210 [16:57] Launchpad bug 544741 in linux "[X700] KMS, amd64: Kernel panic while trying to launch system > preferences > appearance" [High,Triaged] https://launchpad.net/bugs/544741 [16:57] Launchpad bug 546929 in linux "most PATA/SATA modules missing in Lucid netboot" [Critical,Fix committed] https://launchpad.net/bugs/546929 [16:58] Also, linux-2.6.32-17.26 was uploaded last week and primarily contains the 2.6.32.10 stable patches. linux-fsl-imx51-2.6.31-605.10 was also uploaded last week and contains a fix for bug 537083. The new linux-ti-omap-2.6.33-500.3 also landed yesterday which should provide us a reference kernel for the TI OMAP ARM processor. [16:58] Launchpad bug 537083 in linux-fsl-imx51 "Suspend no longer works after updating to 2.6.31-605.9 kernel" [High,Fix released] https://launchpad.net/bugs/537083 [16:58] [17:00] ogasawara: "patches to pull out some built-in drivers" - do you mean that there are still some changes there that are committed but /not/ released, or have they all been released? [17:00] slangasek: should all have been released [17:00] ok, because I'd have to nack any further reshuffling of the kernel config on that level, given the critical bug we already have regarding sata drivers missing from netboot [17:01] slangasek: ack, the netboot bug was a result of that shuffling [17:01] yes :) [17:01] slangasek: smb should be uploading that fix today [17:01] netboot> and everything else [17:02] (notwithstanding the bug title) [17:02] ScottK: looks like you've volunteered to test bug #491210? [17:02] Launchpad bug 491210 in linux "[i865G] Monitor Resolution limited to 800x600" [High,Confirmed] https://launchpad.net/bugs/491210 [17:02] slangasek: Yes, but didn't get to it yet. [17:03] ScottK: think you will by Monday? [17:03] Maybe. [17:03] Need to either find my USB stick or my stack of CDRs. [17:03] 357673 is an action item from me, to test the kernel patch that implements the alsa mixer for the thinkpad bios [17:03] I'll get that done today [17:04] ScottK: ack :) [17:04] any other questions for kernel? [17:04] [TOPIC] Desktop Team [17:04] New Topic: Desktop Team [17:04] ogasawara: thanks [17:04] [LINK] https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus [17:04] LINK received: https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus [17:04] beta-2 WIs are well on track (7 left to do), we are in almost 100% bug fixing mode now [17:04] Good progress with RC and general bug fixing, but they keep coming in. (Which is actually an improvement in processes and cooperation with QA, thanks to them! At least we know very well where the fires are) [17:05] Specs called out in release team meeting invitation: [17:05] - desktop-lucid-xorg-multitouch: Code changes for Lucid are done. One remaining WI is testing, the other is evaluating kernel changes, which I believe was just forgotten to be closed. Will check with Andy when he comes back next week. [17:05] - desktop-lucid-startup-speed: Only WI left is for OLS team, to defer startup of u1 sync daemon; being worked on, and trivial to fix [17:05] - lucid-duplicated-packages: Dropping db4.7 still seems feasible to do; we probably have to defer tcl/tk8.4 at this point of the release cycle. [17:05] Bugs called out in release team meeting invitation: [17:05] - bug 537356 - that is for the mobile team [17:05] Launchpad bug 537356 in webservice-office-zoho "application menu entries dont do anything" [High,Triaged] https://launchpad.net/bugs/537356 [17:05] pitti: thank you! [17:05] - as a fair trade, bug 432631 is in the desktop field now (from foundations) [17:05] Launchpad bug 432631 in sudo "clean up system/per-user proxy handling" [Medium,In progress] https://launchpad.net/bugs/432631 [17:06] status for other bugs is on the wiki page, I spare the copy&paste [17:06] I also have three questions to discuss, shall I go ahead with them? [17:06] that's a fair trade as far as I'm concerned! [17:06] * slangasek grins [17:06] pitti: yes, go ahead [17:06] Last week, after releasing beta-1 with an one-day delay, we thawed very late (after Europe went to sleep and weekend already); that caused some interesting fallout over the weekend. For situations like that, can we either thaw earlier (when it's clear that we won't rebuild any more), or defer the thawing until the Monday after? [17:07] my opinion at the time was that it wasn't clear that we'd have responded to the situation any more quickly on a Monday night than on a Friday night [17:07] * pitti apologizes for the cdbs trouble [17:07] I think it's worth examining the timeline in detail before responding [17:07] well, there were some brave souls (thanks StevenK, persia) who worked on Saturday to fix it [17:07] I think there are other things we should have done - there's no evidence that escalation was done to the extent of phoning people and getting them out of bed [17:08] AFAICS [17:08] so in this particular case it wasn't too bad [17:08] cjwatson: no, there wasn't [17:08] pitti: I don't think it was practical to thaw earlier because the people who would do the thawing were still bound up in releasing [17:08] it's just a general strawman proposal to mitigate the impact [17:08] we could have unfrozen the archive for new uploads but left the queue in place for later review? [17:08] I'd have been concerned about momentum problems with thawing later [17:09] OTOH, I reviewed and accepted that cdbs upload thinking it looked reasonable in scope [17:09] slangasek: that might be a good compromise [17:09] some of the very same people who were saying we should have thawed on Monday were clamouring for a thaw on Friday :-) [17:09] cjwatson:FWIW, I was phoned...but could only update the twitter status :/ [17:09] slangasek: I think a better idea is people shouldn't upload stuff during the freeze they don't want in before the milestone. [17:09] cjwatson: I suppose you mean seb128? [17:09] robbiew: were you out of your normal environment? [17:09] pitti: I don't recall the names, and am not sure that naming names would be productive even if I did :) [17:09] To be fair his concern was thawing on a Friday night, not thawing ASAP so that we can continue to develop lucid [17:10] cjwatson: yes...and by the time I returned...folks were working on it [17:10] ScottK: desktop team wouldn't be happy with that, their workflow involves pushing things off their desk and into the queue ASAP [17:10] robbiew: ah [17:10] anyway, no need to spend a long time discussing this, but I thought I'd bring it up [17:11] slangasek: well, we do that because it's possible [17:11] pitti: when it wasn't possible, there were many objections [17:11] pitti: and if it wasn't possible, seb128 wouldn't be happy :-) [17:11] if it's better to not stash uploads that way, we can stop doing that [17:11] we have bzr, after all [17:11] I think it's fine to stash uploads that way, personally, but I think we could have responded better to the situation that arose [17:12] there was some explicit handoff that wasn't done, too [17:12] I guess it also comes down to "test your changes better" (which I take as a "brown paperbag" for me) [17:12] it wasn't really perceived as a crisis until it was far too late, AFAICS [17:12] I know I initially was confused because the problem description sounded to me a lot like what the upload was intended to fix. My initial thought was it was people who hadn't updated with problems. [17:14] ok, thanks everyone for your opinions [17:14] I guess I should go on [17:14] FFE bug 546933 -- should we go ahead with this? It looks like a quite intrusive change, but it'd avoid releasing a third configuration format change for input devices, and also get us much better aligned with Debian; and it's also relatively easy to test; but like any change of that magnitude, there's a certain regression potential, of course [17:14] Launchpad bug 546933 in xorg-server "FFE: xorg.conf.d/inputclass backport" [Wishlist,Fix committed] https://launchpad.net/bugs/546933 [17:14] should we disuss that in the meeting, or in the bug report? [17:14] bug report, I think [17:15] ok [17:15] [17:15] For Kubuntu: [17:15] We expect KDE 4.4.2 tarballs to start packaging any moment now, so that should be our version for Beta 2 and almost certainly for release. Likely we would upload this Monday or Tuesday. [17:15] Branding has already been discussed. [17:15] tseliot's Plymouth smooth transition patch for KDM is uploaded. kdebase-workspace is building now. [17:15] That's all I have. [17:15] any other questions for desktop team? [17:16] [TOPIC] DX Team [17:16] New Topic: DX Team [17:16] pitti, ScottK: thanks [17:16] davidbarth: hi === nikolam is now known as Guest57625 [17:18] njpatel_: around? [17:18] ok, moving on; we'll circle around if they show up later [17:18] [TOPIC] Foundations Team [17:18] New Topic: Foundations Team [17:18] cjwatson: hi [17:19] [LINK] https://wiki.ubuntu.com/FoundationsTeam/ReleaseStatus/Lucid [17:19] Release collaboration with Debian: per doko, we currently have a pre-release of IcedTea 1.8 in lucid, and both lucid and squeeze will get 1.8 final (no new features) in time for lucid release [17:19] LINK received: https://wiki.ubuntu.com/FoundationsTeam/ReleaseStatus/Lucid [17:19] We are pretty much in full bug mode now; see the URL above for status of trailing work items. slangasek, what's happening with foundations-lucid-supportable-binaries? [17:19] There are still quite a few installer bugs (Steve expressed concern about this in the agenda), but we fixed three milestoned ones today and are making good parallel progress on several more. The worst outstanding one is the LVM+encryption failure, which I'm working on. [17:19] For full bug details, see the URL above. [17:20] (that's it, short summary, long wiki) [17:20] cjwatson: supportable-binaries> I'm going to plow through this today/tomorrow [17:20] slangasek, hey [17:21] njpatel_: hi; are you available to give us a DX status update after we finish w/ Foundations? [17:21] slangasek: sorry, currently on a call; the weekly report is at the usual location: https://wiki.ubuntu.com/DesktopExperienceTeam/LucidReleaseStatus#preview [17:21] slangasek: can I help? [17:21] erm, let me see, I though dbarth was around for todays (I don't know the status of the blueprints) [17:21] mind you maybe I should be fixing my bugs instead [17:22] cjwatson: yeah, I think having two people working on this is probably a waste, I just need to sit down and finish it [17:23] unfortunately it went long enough after UDS without action that the memories faded a bit, and the spec doesn't fully document the agreed algorithm for identifying removal candidatse [17:23] slangasek: We can discuss that if you want. === nikolam_ is now known as nikolam [17:23] (later) [17:23] ScottK: sounds good [17:24] no more questions from me on Foundations; anyone else? [17:24] the second beta has been good in that it's given us time to shake out a bunch of serious installer bugs, but it's been bad in that the bug flow has been enormous. [17:25] we should post-mortem at UDS [17:25] * slangasek nods [17:25] however, we get a lot of "good" bug reports due to that, too [17:25] cjwatson: agree, but i think it's a good thing overall [17:25] pitti: we do, it's a mix [17:25] mix> absolutely [17:25] post-mortem> we're not dead yet, let's save this conversation for UDS :) [17:25] he's pushing up the daisies! [17:26] slangasek: agree [17:26] he's gone to join the choir invisible [17:26] ahem [17:26] [TOPIC] DX Team [17:26] New Topic: DX Team [17:26] [LINK] https://wiki.ubuntu.com/DesktopExperienceTeam/LucidReleaseStatus [17:26] LINK received: https://wiki.ubuntu.com/DesktopExperienceTeam/LucidReleaseStatus [17:26] slangasek: easy for you to say [17:26] any questions for DX? [17:28] davidbarth, njpatel_: there were a couple of WIs on dx-lucid-me-menu that were still targeted to beta-1 which I've moved; it's ok if you don't have status on those currently, but I want to make sure it's on your radar [17:28] slangasek, thanks, will take a look through the blueprints again [17:29] Keybuk: if you're dead, don't admit it, that'll just tell people you don't need to take breaks for physical needs ;) [17:29] [TOPIC] Security Team [17:29] New Topic: Security Team [17:29] jdstrand: hi [17:29] hi [17:30] https://wiki.ubuntu.com/SecurityTeam/ReleaseStatus/Lucid [17:30] [LINK] https://wiki.ubuntu.com/SecurityTeam/ReleaseStatus/Lucid [17:30] LINK received: https://wiki.ubuntu.com/SecurityTeam/ReleaseStatus/Lucid [17:30] not a lot to report (again). we are in bug fixing mode. one bug worth mentioning is bug #528274 [17:30] Launchpad bug 528274 in ubuntuone-client "syncdaemon should have AppArmor profile" [High,Fix committed] https://launchpad.net/bugs/528274 [17:30] it has been unmilestoned and deferred to lucid+1 due to all the changes with ubuntu-one that are still landing (ie, profiling a moving target is difficult). I suggested that we at least ship a supported but disabled profile, like we do with firefox, which we can turn on in 'm'. It seems the ubuntu-one people will do this. [17:31] ok [17:31] any questions for security? :) [17:32] none from me ;) [17:32] [TOPIC] MOTU [17:32] New Topic: MOTU [17:32] jdstrand: thanks [17:32] sure! :) [17:32] sistpoty|work, ScottK: how goes? [17:33] o/ [17:33] * ScottK lets sistpoty|work go first. [17:33] slangasek: didn't have much time for ubuntu this week, so nothing to report from my side :( [17:33] There was some concern about the pace of syncs for the Ruby transition this week. [17:34] That got into a long discussion about how we deal with syncs in general. [17:34] I found out today that due to the fix for http://bugs.python.org/issue691291 landing in the archive in python2.6.5, we broke at least one package. [17:34] Fortunately the Debian maintainer had already fixed it and I got it sync'ed. [17:35] I don't know how many others (if any) got broken. [17:35] Bug #548849 is the one in question. [17:35] Launchpad bug 548849 in gaupol "Sync gaupol 0.15.1-1 (universe) from Debian unstable (main)" [Wishlist,Fix released] https://launchpad.net/bugs/548849 [17:35] Do we have a good way to investigate this? [17:36] BTW, thanks jdstrand for the sync. [17:36] That's all I have. [17:36] doko: ^^ do you have any insight here? [17:36] is there a way to grep for the problem? [17:37] looking [17:37] we don't have an unpacked lintian lab like Debian, but we could do a full-source grep, it would just take a while ... [17:37] codecs.open( ... would give you a list. [17:37] what was the breakage? [17:37] It wouldn't be all that use the function, just those that made the wrong assumption about binary/text mode. [17:38] ah [17:38] ScottK: you're welcome [17:38] hmm, have to run, will look at this tomorrow ... [17:38] slangasek: Maybe an action then. [17:39] doko: you're taking that action? [17:39] [ACTION] doko to grep the archive for codecs.open in python code, to find other packages broken by http://bugs.python.org/issue691291 [17:40] ACTION received: doko to grep the archive for codecs.open in python code, to find other packages broken by http://bugs.python.org/issue691291 [17:40] anything else? [17:40] oh, we've got delegates still outstanding [17:40] We seem to be doing OK without .... [17:41] *shrug* [17:41] I keep promising to reply to that email and it hasn't happened [17:42] I'm afraid part of it is I keep winding up bogged down trying to map nicknames in the mail to people [17:42] and then I get pulled away [17:42] I'll reply today for reals [17:42] thanks! [17:43] slangasek: if you want, I can resend with a list of lp-ids and names instead of only nicks [17:43] sistpoty|work: if you can do that quickly, that would certainly expedite my response :) [17:43] [TOPIC] AOB [17:43] New Topic: AOB [17:43] slangasek: it is, there's no remaining feature to implement; mostly a reminder to check for IM client status bugs (sorry to talk on another topic) [17:44] davidbarth: ok [17:44] going once... [17:44] going twice... [17:44] #endmeeting [17:44] Meeting finished at 12:44. [17:44] thanks, folks [17:44] slangasek: thx [17:46] thanks everyone [17:58] slangasek: sent [17:58] thanks! === txwikinger2 is now known as txwikinger === txwikinger is now known as txwikinger2 === txwikinger2 is now known as txwikinger