[00:02] I'm calling a meeting [00:02] Everyone, say hi [00:02] * MTecknology says hi [00:02] meeting concluded [00:03] sorry, it's just been so idle in here === Crazyguy_ is now known as Crazyguy === asac_ is now known as asac [10:05] * persia looks about, wondering if it's this week or next week, as the wiki page hasn't been updated. [10:17] RIght. Next week then. [10:20] sorry for asking : next week at what time? [10:21] @schedule [10:21] ? [10:21] @ schedule [10:21] leoquant: not updated !!! [10:21] :P [10:24] MaWaLe, I'm guessing 10:00, but I'm not sure. [10:25] thx persia & leoquant [11:15] persia, oh crap. sorry :( === lamont` is now known as lamont [11:35] elky, It's the nature of things, and two of us wouldn't have been enough anyway. [11:36] persia, lifeless was kind of around, but even that would have done us no good without yet another [11:37] Right. I suspect that there were four of us around, but without our feerless leader to organise us, we're less than coordinated. [14:59] o/^ [14:59] * mathiaz waves [14:59] yo [14:59] o/ [15:00] Hmm. Did the server meeting move? [15:00] allright - let's get started. [15:00] o/ [15:00] Isn't it 15:00 UTC? Isn't this the TB meeting? [15:00] I was expecting a Technical Board meeting here now [15:00] cjwatson: hm [15:00] there has been some timezone confusion due to the US moving to DST earlier than Europe [15:01] Yes, some parts of the world chose to adjust their clocks, but that's just those parts of the world. [15:01] the Fridge calendar says 3pm TB 4pm server team, which I assume is either UTC or my local timezone (currently identical) [15:01] last week I checked and the TB meeting had been moved to 14:00 UTC on the calendar [15:01] is there a conflict? [15:01] Fridge calendar should be UTC. [15:01] that was an error due to Google Calendar having no idea whatsoever about DST [15:01] it was fixed earlier today [15:01] persia: what time is your meeting usually? [15:02] mdz, Not my meeting. I'm here for the TB meeting. [15:02] mathiaz: How about if we move to #uubntu-server [15:02] yes - let's move to #ubuntu-server [15:02] ScottK: +1 [15:02] persia: sorry, I see [15:02] #startmeeting [15:02] Meeting started at 10:02. The chair is mdz. [15:02] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [15:03] Keybuk: here? [15:03] present [15:03] sabdfl will not be attending [15:03] [TOPIC] SRU guidelines for Landscape (robbiew) [15:03] New Topic: SRU guidelines for Landscape (robbiew) [15:04] cjwatson: thanks for drafting a resolution for us [15:04] I believe it is just awaiting your feedback now [15:04] have you had a chance to read it? [15:04] I have only just scanned it prior to the meeting, I'm afraid, having been traveling all last week [15:05] I think it is fine [15:05] the rationale strikes a good balance, sufficiently explicit without being cumbersome [15:05] we will want to iterate on it further if and when we need to apply this to other cases [15:06] be it resolved, then? if so, I'll take an action to send out mail about it and update the SRU documentation [15:06] but I am prepared to support it as is for the current case [15:06] [VOTE] cjwatson's proposed resolution regarding Landscape, <20090302122315.GK7367@riva.ucam.org> [15:06] Please vote on: cjwatson's proposed resolution regarding Landscape, <20090302122315.GK7367@riva.ucam.org>. [15:06] Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0 to MootBot [15:06] E.g. /msg MootBot +1 #ubuntu-meeting [15:06] +1 [15:06] +1 received from mdz. 1 for, 0 against. 0 have abstained. Count is now 1 [15:06] +1 [15:06] +1 received from cjwatson. 2 for, 0 against. 0 have abstained. Count is now 2 [15:06] +1 [15:06] +1 received from Keybuk. 3 for, 0 against. 0 have abstained. Count is now 3 [15:06] sabdfl said +1 in private mail [15:06] [ENDVOTE] [15:06] Final result is 3 for, 0 against. 0 abstained. Total: 3 [15:07] [ACTION] cjwatson to document and announce Landscape resolution [15:07] ACTION received: cjwatson to document and announce Landscape resolution [15:07] [TOPIC] Upload permission for Romain Francoise for emacs-snapshot [15:07] New Topic: Upload permission for Romain Francoise for emacs-snapshot [15:08] I'm not aware of any change here; jono is on holiday today and I don't have an update from him [15:08] though I understand that the TB voted to do something similar for mdke recently [15:08] so maybe it is worth revisiting? [15:09] cjwatson,Keybuk: any thoughts? [15:10] mdz: I still don't think he's shown anything necessary to meet the requirements [15:10] mdz: I could ask him to follow https://wiki.ubuntu.com/UbuntuDevelopers#PerPackage now that we have a process for it? [15:10] Is there a recent refresher of status from the candidate? [15:10] (as in, last few months) [15:10] in particular, the developer concerned does not seem to be actively pursuing the application [15:10] which was turned in by somebody else and not by then [15:10] I know this has been on our table for some time [15:10] dholbach: can you confirm whether or not they are actually still interested? [15:10] IIRC the request was made by someone else on their behalf [15:11] dholbach, I'll take that one, given your status for the next two days. [15:11] persia: that's probably a good idea [15:11] if I were to review the criteria [15:11] based on the current application [15:11] mdz: I informed Romain when were discussing the process and he thanked us for looking into it - I'd take that as a "yes" [15:11] it would a very solid -1 [15:12] in any case I feel that the process with the list of requirements clearly depicts the way ahead [15:12] Keybuk: how so? [15:12] # have sufficient technical knowledge of the package(s) in question from documented work in the package through sponsorship, work in other distributions, or work upstream. [15:13] he has had one, single, upload sponsored [15:13] in other distributions, ie. Debian, he is not a maintainer of emacs or emacs-snapshot [15:13] and I couldn't see any work from him upstream [15:13] # have an understanding that such an access grant does not permit sole-maintainership, but rather the right to participate in the maintenance of the package as part of a team. [15:13] since he has not been involved in his own application, I am unconvinced from him of any understanding of what it implies [15:13] # have an understanding of the broad strokes of the release schedule, relevant freezes that would affect the package in question, and appropriate means by which to handle any exceptions. [15:13] since he has no other activity in Ubuntu, I do not believe he has demonstrated this [15:13] # need to show advocation and support of existing developers indicating that previous work on the package demonstrated that unsupervised upload is warranted. [15:14] 15:13 he has had one, single, upload sponsored [15:14] the only sponsored upload he did was uploaded by siretart, who hasn't spoken about him fwict [15:14] I think I would have to dispute the facts there [15:14] # need to have documented previous concern for the packages in question in Ubuntu, including previous uploads, effective bug management, and similar previous work. [15:14] none that I can see [15:14] # need to show a history of effective collaboration with other developers in Ubuntu. [15:14] none that I can see [15:14] 'aptitude changelog emacs-snapshot' shows a long series of uploads from him [15:14] cjwatson: those are syncs from debian, no? [15:15] emacs-snapshot is not in Debian [15:15] so they may be syncs from somewhere, but it isn't Debian [15:15] the only upload I can see where he was sponsored by the usual procedure was 13 Oct 2008 of 1:20081013-1 into intrepid [15:15] at least I think it is enough to demonstrate technical knowledge of the package in question [15:15] Keybuk: he has maintained emacs-related packages in Debian, and is a Debian maintainer in good standing afaik [15:16] http://www.mail-archive.com/debian-newmaint@lists.debian.org/msg01266.html [15:16] LINK received: http://www.mail-archive.com/debian-newmaint@lists.debian.org/msg01266.html [15:16] http://qa.debian.org/developer.php?login=rfrancoise&comaint=yes [15:16] LINK received: http://qa.debian.org/developer.php?login=rfrancoise&comaint=yes [15:16] Keybuk: I'm not necessarily disputing your other points, but your general point of "doesn't seem to work on the package" doesn't stand up to detailed examination [15:17] cjwatson: I didn't say he hasn't worked on the package [15:17] I've said he hasn't met our criteria [15:17] he is listed as a maintainer of GNU emacs upstream [15:17] he has 155 uploads of this package listed in the changelog [15:17] cjwatson: none of which have been made to Ubuntu [15:17] unless Soyuz is lying to me [15:17] I think the intent of: [15:17] 15:12 # have sufficient technical knowledge of the package(s) in question from documented work in the package through sponsorship, work in other distributions, or work upstream. [15:17] The log of bug #252328 may be interesting in this context [15:17] Launchpad bug 252328 in emacs-snapshot "please sync emacs-snapshot - 1:20080723-1 from the ubuntu-elisp PPA to intrepid" [Wishlist,Fix released] https://launchpad.net/bugs/252328 [15:18] is to indicate work done on the package *somewhere*, wherever it may be [15:18] Keybuk: Soyuz lies about changelogs. It's a known bug [15:18] and a fairly high-priority one [15:18] cjwatson: I'm reading the publishing history [15:19] https://edge.launchpad.net/ubuntu/+source/emacs-snapshot/+publishinghistory [15:19] there have been no uploads in jaunty [15:19] Soyuz is just not a reliable means to determine this sort of information [15:19] unfortunately [15:19] I disagree [15:19] Soyuz knows perfectly well what is published where [15:19] and when [15:19] I agree that there have been no uploads in Jaunty [15:19] this is not an area that it is deficient in [15:19] but Soyuz is very little use at telling you who was responsible for particular uploads [15:20] cjwatson: the changelogs and uploads are signed by siretart [15:20] except for the top-most one [15:20] it appears to me that Romain is maintaining the package in the ubuntu-elisp PPA [15:20] and occasionally asking for sponsorship of snapshots from siretart [15:21] then I would like to see siretart speaking on his behalf [15:21] he did [15:21] I concur [15:21] and, most pointledly, I'd like to see some kind of interest from Romain himself in his own application [15:21] dholbach just addressed that [15:21] So shall I tell Romain that he should follow the new process, and restart the application? [15:22] persia: I think that would be a good way to get things moving again. he could review the criteria and provide us with information about how he meets hem [15:22] s/hem$/them/ [15:22] rather than us dredging launchpad etc. [15:23] [ACTION] persia to request a new application based on the now-established PerPackage criteria [15:23] ACTION received: persia to request a new application based on the now-established PerPackage criteria [15:23] That seems reasonable. I'll do that, and bring it back to the TB once he has addressed the specific criteria. [15:23] [TOPIC] codecs in ffmpeg (Reinhard Tartler) [15:23] New Topic: codecs in ffmpeg (Reinhard Tartler) [15:23] this is with jono at the moment [15:24] he's getting advice to help formulate a policy [15:24] I haven't caught up with him on it in the past 2 weeks due to travel and his holiday [15:24] so, nothing to report [15:24] [TOPIC] Governance changes in the context of Archive Reorganisation [15:24] New Topic: Governance changes in the context of Archive Reorganisation [15:24] cjwatson? [15:25] I updated http://wiki.ubuntu.com/ArchiveReorganisation to account for the changes we discussed in Berlin (i.e. splitting the work into two parts and considering permissions first, so that we can move ahead with that while we figure out how to solve problems with the component changes) [15:25] I believe this was said to be blocked on finalizing the design [15:25] ArchiveReorganisation/Permissions now contains the work I expect to be possible in the near term [15:25] I have a call with dholbach and jono on Thursday to discuss it [15:26] it does involve some Launchpad changes still, but I've discussed those with Muharem and Julian and they're in progress [15:26] cjwatson: is that a discussion call, or a decision-making call? [15:26] i.e. what do we need to do in order to move forward? [15:28] the next thing we need to do is determine what we're doing with social structures that rely on the split between core and MOTU [15:28] and that's the purpose of the Thursday discussion? [15:29] yes, and to thrash out expected timeline and the bits that still need planning from the community team [15:29] ok [15:29] anything else on this topic? [15:29] not for the present [15:29] [ACTION] cjwatson to discuss latest ArchiveReorganisation plan with jono and dholbach and agree a plan for governance changes [15:29] ACTION received: cjwatson to discuss latest ArchiveReorganisation plan with jono and dholbach and agree a plan for governance changes [15:30] [TOPIC] AOB [15:30] New Topic: AOB [15:30] meeting time wrt to DST [15:30] I'd like to raise the question of meeting times and DST, given the start of the meting. [15:30] right [15:30] usually the meeting time is in GMT, shall we stick to this? [15:30] my expectation is that the meeting time remains the same until/unless we change it through explicit discussion [15:30] * siretart turns up [15:31] "the same" meaning GMT or UTC? [15:31] this was apparently foiled by Google Calendar [15:31] persia: "the same" UTC time [15:31] mdz: remains the same in UTC, or in your/our timezone? [15:31] ok [15:31] UTC is the one true global meeting timezone [15:31] the fridge calendar is set to no-DST [15:32] and so is the calendar where the event is [15:32] so I don't know why it changed [15:32] Google Calendar popped up and asked me if I wanted to change my time zone to GMT (which of course it already was) [15:33] I am open to moving the meeting once BST starts, or not, it doesn't matter too much to me [15:33] any issues with that? [15:33] other meetings nearby seem to be in a mix of US time, GMT and UTC [15:33] it surprised me that the server team meeting moved an hour earlier [15:34] they were previously immediately after us, IIRC [15:34] so I imagine that they suffered the same problem [15:34] but perhaps have more US residents [15:34] the server team meeting is now at different times on dendrobates' calendar and the fridge [15:34] because they were separate events rather than invites [15:34] note that Google Calendar has severely confused itself [15:34] mdz moved this week's meeting back to 1500UTC [15:35] in two weeks time it's at 1400UTC [15:35] but in four weeks time, it's at 1500 BST because that's when the time warp ends and Google goes back to its usual service [15:35] Keybuk: or is it? once BST starts it might move [15:35] mdz: I'm looking at the raw iCal feed [15:35] which gives UTC times [15:35] Note that it's still a different time for some of us, who may either not have DST, or have it on the other direction. [15:36] Keybuk: what do we need to do in order to make it sane? [15:36] and this is consistent with Google Calendar's past behaviour [15:36] mdz: use something that's not Google Calendar [15:36] sadly [15:36] it appears to simply be a bug in their software [15:36] I mean in the short term [15:36] how do we fix the calendar to implement what we just agreed? [15:36] you can't store UTC meetings in google calendar fwict [15:36] sounds like we may need to move one meeting [15:36] we've moved the server team meeting back one hour because I based my judgement on google calendar [15:36] if you drag the meeting back an hour for four weeks, it'll fix it for the next 6 months [15:37] ok, let's do that then [15:37] any other business? [15:37] so to confirm, next TB meeting will be at 1400 UTC, and 1400 UTC thereafter? [15:37] ie. we're actually rescheduling it [15:37] (it's currently 1500 UTC) [15:38] done [15:38] no, I've put it at 1500 UTC [15:38] for the next meeting? [15:38] and the one after that at 1400 UTC? [15:38] wait, BST starts when? [15:38] 0200 29/03 [15:39] so between the TB meeting in two weeks time and the TB meeting in four weeks time [15:39] so I've moved it on 24 March to 1500 [15:39] on 7 April, it currently shows 1500 as well [15:40] but who knows what that will actually be once google is finished with it [15:40] Keybuk: do you think we need to move it or not? [15:40] you just have to monitor week-by-week [15:40] in the real world it's the only sane way to keep meetings at the intended times across DST changes [15:40] mdz: if we leave it as it is, the meeting in four weeks time will be at 1500 London time [15:40] (BST) [15:41] ok [15:41] so we'll hold the meeting at the same time in 2 weeks, and after DST, I'll look at it and see if it needs to be changed [15:42] anything else? [15:42] thanks, all [15:42] #endmeeting [15:42] Meeting finished at 10:42. === mc44_ is now known as mc44 [17:00] Time for the weekly kernel-team meeting [17:00] tis [17:00] #startmeeting [17:00] [LINK] https://wiki.ubuntu.com/KernelTeam/Meeting [17:00] The above link points to today's agenda. [17:00] Meeting started at 12:00. The chair is smb_tp_. [17:00] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [17:00] LINK received: https://wiki.ubuntu.com/KernelTeam/Meeting [17:00] waves [17:00] * rtg waves [17:01] * cking waves [17:01] [TOPIC] New Starters [17:01] New Topic: New Starters [17:01] hi [17:01] * ikepanhc waves [17:01] hi [17:01] We have two new people that joined us last and this week: Brad Figg (bradF) and Bryan Wu (cooloney). Welcome to both of you (again)! [17:01] waves [17:01] hello guys [17:01] Ok, that being said... [17:01] * BradFigg waves [17:01] [TOPIC] Security & bugfix kernels [17:01] New Topic: Security & bugfix kernels [17:02] Me [17:02] * apw looks about 10% here [17:02] There are uploads planned to -proposed for Hardy and Intrepid. I summarized the current changeset for those uploads below. [17:02] == Hardy (proposed) == [17:02] [kernel] [17:02] • rt: Updated PREEMPT_RT support to rt27 [17:02] • fix apparmor memory leak on deleted file ops [17:02] • KVM: MMU: Add locking around kvm_mmu_slot_remove_write_access() [17:02] • serial: 8250: fix shared interrupts issues with SMP and RT kernels [17:02] • 8250.c: port.lock is irq-safe [17:02] • ACPI: Clear WAK_STS on resume [17:02] [LBM] [17:02] • [R] SAUCE: compat-wireless: Fix module load for crypto modules [17:02] The one marked with [R] was reported as regression [17:02] smb_tp_, nice summary [17:03] This I would prepare soon to be uploaded [17:03] smb_tp_: are you ready for an Intrepid LBM update? I'vve pushed with the latest compat-wireless [17:03] == Intrepid == [17:03] [kernel] [17:03] • SAUCE: ACPI: EC: Limit workaround for ASUS notebooks even more [17:03] • [R] SAUCE: report rfkill changes event if interface is down [17:03] • [R] SAUCE: floppy: Provide a PnP device table in the module. [17:03] • fix apparmor memory leak on deleted file ops [17:03] • KVM: MMU: Add locking around kvm_mmu_slot_remove_write_access() [17:03] [LBM] [17:03] • scripts: Fix typo in prepare-compat-wireless.sh [17:03] • Update MUNGE script for latest wireless-testing/compat-wireless [17:03] • Update compat-wireless to master-2009-03-04 [17:03] rtg, Yep, noticed it [17:03] There will possibly be a few more for intrepid [17:03] which just get SRUed today [17:04] smb_tp_: I tried both iwl 3945 and 4965, they seemed to work well. [17:04] Sound promising but as with that screen black regression (which I am also fixing by reverting the [17:05] acpi changes, you never know until the whole bunch of hw has been tried outside [17:06] So we will revert the change for acpi integers for Intrepid to be on the safe side with binary gfx drivers [17:06] I think that would be all from me [17:06] There are two minor bullets on the agenda [17:07] * Archiving the Hardy/Intrepid OEM LPIA trees [17:07] smb_tp_: don't we have to wait until after the kernel sprint in Lexington? [17:07] this will be deferred until after the sprint [17:07] apw, You added that? [17:08] smb_tp_, that was a direct copy from the previous week and [17:08] and had its discussion then, can be ignored for now [17:08] Ok, so we defer that until then, sconklin would that be an action for you? [17:08] we will discuss that at the sprint i am sure [17:08] my action, but not for a month [17:09] Ok, I'll just add it so it is not forgotten [17:09] [ACTION] sconklin bring up archiving of Hardy/Intrepid OEM LPIA trees after the sprint [17:09] ACTION received: sconklin bring up archiving of Hardy/Intrepid OEM LPIA trees after the sprint [17:10] There was also the thing of movin Jaunty LPIA into distro kernel [17:10] I believe that happened... right? [17:10] I thought so, too [17:10] smb_tp_: done, but the use of it is deferred until the OEM has tested [17:10] OEM team* [17:10] Ok. Fine with me [17:11] apw, Anything else for stable kernels I forgot? [17:11] I'll take an action to coordinate testing by the OEM team for both hardy and jaunty lpia [17:11] sou [17:11] sounds like its all there... handy summaries both [17:11] [ACTION] sconklin coordinate testing by the OEM team for Hardy and Jaunty lpia [17:11] ACTION received: sconklin coordinate testing by the OEM team for Hardy and Jaunty lpia [17:11] [TOPIC] Jaunty Status [17:11] New Topic: Jaunty Status [17:12] * Jaunty Alpha 6 [17:12] rtg, Its comming, right :) [17:12] smb_tp_: I'm uploading a kernel this morning with ARM updates [17:12] i assume the kernel basically closes today [17:12] its got the Freescale patches, and yes, this is about it before A6 [17:13] I might get some Radeon patches in later today === mc44_ is now known as mc44 [17:13] smb_tp_: thats it from me [17:13] Ok [17:13] * Suspend/Resume [17:14] apw, You wanted to do some updates how we stand? [17:14] i have been working some on the test scripts which have been pushed [17:14] to the checkbox repo ready to go [17:14] we should be doing another call-for-testing for A6, i assume [17:14] ogasawara_ will handle that as normal [17:14] apw: yep [17:15] ok, so [17:15] assuming the checkbox changes get uploaded today (and they are meant to before A6) [17:15] [ACTION] ogasawara_ handle another call for testing for A6 [17:15] ACTION received: ogasawara_ handle another call for testing for A6 [17:15] then the defautl checkbox will include it, so desktop would have the test suite already installed [17:15] apw, are we seeing any new issues, or just more of the same? [17:15] apw, mark was doing some work on checkbox this week [17:15] we may want to check that and update instructions if so [17:15] cking, almost everything coming in is generall brokenness all different [17:15] most are still not diagnosed with any specificity [17:16] there are some 116 reports and thats a huge heap to do anything senesible with [17:16] there is a fix for the pm-utils going in which helps with the suspend/resume [17:16] marking your network disabled [17:16] on the positive side [17:17] nothing else of interest that i can think of [17:17] ok thanks [17:17] * Vanilla Kernel Builds [17:18] nothing much there, one new kernel this week. lots of use of them reported [17:18] We now have a page that links vanilla build versions to Ubuntu versions [17:18] yes, ogasawara_'s page has been sucked into the 'official' kernel user [17:19] http://kernel.ubuntu.com/~kernel-ppa/info/kernel-version-map.html [17:19] LINK received: http://kernel.ubuntu.com/~kernel-ppa/info/kernel-version-map.html [17:19] that is updated regularly and should include new Karmic kernels when they appear [17:19] I'll redirect my existing page to the official one [17:20] Ok, so I think thats all on that [17:20] yep [17:20] [TOPIC] ARM Tree [17:20] New Topic: ARM Tree [17:20] amitk, Whats up [17:21] just finished uploading patches to enable the freescale SoC [17:21] imx51 [17:21] that should be it as far as ARM features for Jaunty our concerned [17:22] s/our/are [17:22] we'vev also added mv78xx0 for Marvell buildds [17:22] rtg: though that isn't too useful w/o two VFP related patches [17:22] to fix PREEMPT and floating-point issues [17:23] amitk: bradF has 'em, we'll get them applied [17:23] I believe BradFigg is onto it [17:23] amitk: right [17:23] Ok, anything else to note? [17:24] nothing else [17:24] thanks [17:24] ok, thanks [17:24]