and at the top of the page (instead of in tiny font under the date) [19:28] <kees> ScottK: nooo no no [19:29] <sbeattie> ScottK: only for your adress. [19:29] <mdeslaur> jdstrand: oh, ok...you are using <dd>...that's ok...I thought you were doing dashes [19:29] <kees> lol @ sbeattie [19:29] <jdstrand> ScottK: no, but the plaintext formatting will mimic the site [19:30] <jdstrand> kees: good point [19:31] * ScottK relaxes. [19:32] <jdstrand> kees: interestingly, the diverges from what we agreed on in https://wiki.ubuntu.com/SecurityTeam/Specifications/USNSpec [19:32] <jdstrand> kees: however, that page uses a plain text formatting, so it isn't obviously a problem there [19:33] <kees> jdstrand: that doesn't mention title at all [19:33] <kees> jdstrand: but compare to http://www.ubuntu.com/usn/usn-610-1 [19:33] <jdstrand> kees: not <title>, no, but it the 1st and 2nd lines [19:34] <jdstrand> kees: ack. will fix <title>, I also think the teeny text is wrong in the actual usn [19:34] <kees> jdstrand: oh, I don't mind it being repeated there. I just want it in <h1> and <title> instead of the rather useless "Ubuntu security notices" there [19:35] * jdstrand nods [19:35] <jdstrand> will get that fixed [19:35] <kees> what's the plan for dealing with Summary and Software description? [19:35] <jdstrand> basically me going through them [19:36] <kees> heh, owchy [19:36] <jdstrand> I'm not sure what else can be done [19:36] * jdstrand tried to tell people to adjust those all along ;) [19:36] <kees> well, if people used the standard template, you could just drop those entries [19:36] <jdstrand> I didn't actually 'tell', I encouraged... I guess I'll pay for that now [19:37] <jdstrand> kees: true. that might be the wa to go [19:38] <jdstrand> alright. I think the meeting has gone on long enough [19:38] <sbeattie> jdstrand: surely we can split up the effort? [19:38] <jdstrand> please talk to me out of this meeting on improvements to the site [19:38] <sbeattie> or yeah, dropping's not the worst thing, either. [19:39] <kees> I think dropping the "bad" entries is the way to go. Going forward, it should be treated as required. [19:39] <jdstrand> sbeattie: we can discuss. I think dropping is probably fine. [19:39] <jdstrand> hmmm [19:39] <kees> additionally, we may want to start creating a "database" of our software descriptions. [19:40] <jdstrand> there are some issues with older USNs [19:40] <kees> jdstrand: why? it just seems to leave out the missing sections [19:40] <jdstrand> eg http://staging.www.ubuntu.com/usn/usn-372-1/ [19:40] <jdstrand> Software description is empty [19:40] <jdstrand> there are no package versions [19:40] <kees> that's a bug in the parser then [19:41] <jdstrand> no package info [19:41] <jdstrand> probably [19:41] * jdstrand didn't write that either [19:41] * jdstrand didn't write any of it tbh :) [19:41] <jdstrand> anyhoo [19:41] <jdstrand> feel free to review [19:41] <jdstrand> does anyone have any other questions? [19:41] <kees> where are the bugs tracked for it? [19:43] <jdstrand> kees: write now nowhere, I am talking directly with them. can just give to me for the next few days [19:43] <jdstrand> jeez [19:43] <jdstrand> s/write/right/ [19:43] <jdstrand> (what kind of a typo was that?!? [19:43] <micahg_> a homophonic one? [19:44] <jdstrand> it was lame, that is all I know [19:44] <jdstrand> #endmeeting [19:44] <MootBot> Meeting finished at 13:44. [19:44] <jdstrand> thanks everyone! :) [19:44] <micahg_> thanks jdstrand [19:45] <sbeattie> heh, thanks. [19:45] <jjohansen> thanks jdstrand [19:47] <kees> thanks! === Thermi is now known as thermi === Claudinux_ is now known as Claudinux === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === Claudinux_ is now known as Claudinux === Ursinha is now known as Ursinha-afk === chuck

[01:05] hello! [01:06] olololol === Ursula__ is now known as Ursinha-afk === Ursinha-afk is now known as Guest38069 === Ursinha-afk is now known as Ursinha === doko_ is now known as doko === yofel_ is now known as yfoel === yfoel is now known as yofel === thermi is now known as Thermi === claudinux is now known as Claudinux === chuck_ is now known as zul === Quintasan_ is now known as Quintasan [13:59] hi RAOF [14:00] * hrw back in 5-10 minutes [14:00] Evening/afternoon/morning :) [14:01] hey RAOF. [14:02] Third time's the charm? :) [14:03] hello [14:03] hi [14:03] DMB meeting? [14:04] yep, assuming we have quorum [14:04] maco, cody-somerville, Laney: ping ? [14:05] going to go get a coffee while waiting for them to show up, will be back in 2 minutes [14:08] ouch, doesn't look good for quorum :( [14:09] that's not good [14:09] Laney was around not *that* long ago :/ [14:11] question while waiting: can we do have a session at the UDS? [14:13] a session as in ? DMB meeting at UDS or some kind of DMB review session (like what we did for the ARB at last UDS) ? [14:15] shoot, did I miss the DMB? [14:15] nope, it didn't start yet [14:15] we're waiting for other DMB members to arrive as we don't currently have quorum [14:15] stgraber: DMB meeting [14:15] ahh, whew... [14:16] but we could do a review session too [14:16] was it supposed to start 20 minutes ago, or 1:20 ago? [14:16] bdrung: we tried that last time but couldn't get enough DMB members to attend so we had to postpone [14:17] stgraber: it will be my first uds [14:17] psusi: 20 minutes ago. [14:19] bdrung: I wouldn't count on us being able to have quorum during UDS but we can always try it. It really depends on what sessions are running at the same time. [14:20] bdrung: if I'm not wrong in my timezone calculation, it'll be at 2pm Budapest time so either still during plenaries or the first session after the plenaries [14:23] stgraber: 3pm Budapest time [14:23] in worst situation applying for UD will take similar amount then it takes for DD [14:23] bdrung: oh, ok, then definitely during afternoon sessions :) will have to look at the schedule once we have it to see if I can make it [14:24] maco, cody-somerville, Laney: ping (again :)) [14:25] stgraber: what's with geser and persia? [14:26] I don't know, they aren't in this channel. IIRC geser said he couldn't make it at this time and I haven't seen persia in a while [14:30] ;( [14:30] Well, we'll get to catch up with persia at UDS at least :) [14:32] persia has connection issues thanks to all the quakes [14:32] ogra_: I was suspecting it might have something to do with that :( [14:33] he was fine on thu. which is when i talked to him last by phone [14:35] ok, I guess at this point it's not very likely for any of the others to show up and still leave a reasonable amount of time for the meeting :( [14:35] yep ;( [14:35] 3rd meeting for me [14:35] Likewise. [14:36] RAOF, hrw: can you two only make it to our 13:00 UTC meeting ? it seems to be the most problematic one for DMB members (even though the move to an hour later was meant to fix that ...) [14:37] stgraber: I've been to two of the 13:00 and the intervening one last fortnight. [14:37] The other one is early, but still doable. [14:37] * cyphermox will be back in about 30 min. [14:38] ok, I'll suggest on the mailing-list that we schedule another meeting at 13:00 UTC next week but only announce it if we can have quorum (as in, poke people on our mailing-list to confirm they can attend). [14:38] stgraber: I can manage 5:00 - 20:00 UTC (7-22 my time) [14:39] * RAOF isn't wedded to 13:00 UTC. 11pm isn't exactly perfect ;) [14:39] stgraber: +/- 1h if needed [14:41] ok, I'm sending an e-mail now to our mailing-list, to see if we can get the meeting rescheduled for next week, and hopefully make sure we can quorum for that next meeting (13:00 UTC) and the one after (19:00 UTC) as we have a pretty long backlog [14:46] ok, so see you in 2 weeks [14:48] hrw, RAOF: Ok, e-mail sent to DMB mailing list. Thanks for coming to this meeting and sorry we didn't have quorum. [14:49] hrw, RAOF: If we can schedule that extra meeting, I'll be sending an e-mail to ubuntu-devel and will be contacting everyone listed in the agenda to tell them about it. [14:49] thanks stgraber. [14:49] thx stgraber === Claudinux_ is now known as Claudinux === jjohansen is now known as jj-afk [15:10] stgraber: sorry :( i forgot === hggdh_ is now known as hggdh [15:11] ...i just got out of bed [15:11] happens [15:57] hello! [16:00] * skaet waves [16:00] do we have quorum? [16:01] * ara waves [16:02] hmm, sconklin, bjf around? === martin-canonical is now known as martins-support [16:02] hello [16:02] hi pitti [16:03] #startmeeting [16:03] Meeting started at 10:03. The chair is skaet. [16:03] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [16:03] SRU/LTS bi-weekly synch meeting [16:03] Reminder, please follow the convention of using ".." on a separate line when you've finished typing. Also, If someone wants to comment on the last point, please "o/", so we know to wait. [16:03] sorry I'm late [16:04] sconklin, no worries [16:04] [TOPIC] Karmic/Hardy Desktop - EOL approaching [16:04] New Topic: Karmic/Hardy Desktop - EOL approaching [16:04] Just a reminder that April 2011 will see end of life of Karmic Koala (9.10), and Hardy Heron (8.04) Desktop. [16:05] * ara doesn't know whether to feel happy or sad [16:05] I've staggered the actual close dates, so they don't all land on the same week with the Natty release. [16:05] * sconklin is dancing [16:05] Hardy Heron desktop will EOL mid may. [16:06] note for it will go out today. [16:06] Karmic's one month announce note has already gone out. [16:07] sconklin, since server is still supported, I assume this doesn't change the workload for you on heron then. is this correct? [16:07] server on Heron to be clear [16:07] The workload reduction comes in June when Dapper vanishes completely. [16:07] * skaet nods [16:07] skaet: that's pretty much correct. We're currently only taking upstream stable and security fixes, and that continues for server. [16:08] sconklin, thanks for confirming. [16:08] Dapper Drake (6.06) Server will end of life in June 2011. [16:08] Having Dapper gone will be a big load off of us. It's very different to maintain than the subsequent series. [16:09] :) [16:09] Any concerns or issues to flag with the approaching EOLs? [16:09] [TOPIC] Kernel SRU status - sconklin, bjf [16:09] New Topic: Kernel SRU status - sconklin, bjf [16:09] just that we can probably retire the remaining -proposed uploads [16:10] There will be no more uploads from the stable kernel team for Karmic [16:10] unless there's a security emergency [16:10] Current status: [16:11] Everything is ready to be published as soon as signed off by cert and QA, except for Lucid - [16:11] There was a regression in the Lucid kernel that has been fixed with a single change and a new upload to -proposed. [16:11] It would be ideal for the new kernel to receive a complete set of tests, but there is relatively low risk in [16:11] verifying that the change fixes the regression and performing minimal testing otherwise. [16:11] I leave that decision up to the team here and depending on scheduling [16:11] .. [16:12] sconklin, thanks. [16:12] right, testing should be proportional to the amount of changes, no objection [16:12] o/ [16:12] go ara [16:13] for the .61 lucid kernel testing [16:13] is there going to be a verification phase and and testing phase? [16:14] .. [16:14] There could be, or we could pursue them in parallel since it's only verification of one fix [16:15] we could have try to fit a minimum for certification testing next week [16:15] or later this week [16:15] i.e. aiming to run the tests against ~30 systems rather than 100 [16:15] I'm comfortable with that [16:16] fitting in QA testing is probably going to be a concern, depends on how natty testing goes. [16:16] anyone from QA around? (/me just saw jibel drop) [16:16] o/ [16:16] ara, how long does it take to run the tests on all 100? [16:16] bjf, it can take up to two days [16:16] pedro_, is there bandwidth at the later part of the week to check out the lucid kernel? [16:17] ara, thanks, that's good info to know [16:17] as far as I know, there's no huge hurry to get this kernel out [16:18] sconklin, that's good to know. [16:18] skaet, yes, if it gets verified soon we can work on it after ISO Testing and before that as well, meaning tomorrow and Friday [16:18] pedro_, ok, am thinking we'll be iso testing tomorrow as well, but Friday is possible. [16:18] good to know. [16:19] any more questions for sconklin? [16:19] * skaet looks around ... [16:19] [TOPIC] QA status - pedro_ [16:19] New Topic: QA status - pedro_ [16:20] pedro_, do you have something prepared, or should we skip? [16:20] hello, We've verified the Maverick kernel last week, you can see the full results of that here: https://wiki.ubuntu.com/QATeam/KernelSRU-maverick-2.6.35-28.50 [16:21] :) [16:21] the issues listed there are not regressions, that verification was added to the security script after the kernel came out [16:22] that's already fixed by the security team in their branch [16:22] Lucid .60 was also verified last week but later on that testing cycle a regression was found by a community member so we stop [16:23] but in case you want to see the results, the wiki page is at: https://wiki.ubuntu.com/QATeam/KernelSRU-lucid-2.6.32-31.60 [16:23] the errors listed there are GCC ones/script ones and not regressions [16:23] and btw if you want to see all the results there's a new page with those: https://wiki.ubuntu.com/QATeam/KernelSRUResults [16:24] .. [16:24] Thanks pedro! [16:24] 2.6.35-28.50-generic/amd64 (KVM) with DBENCH failed. is this anything to worry about? [16:24] (on maverick results.. ) [16:25] skaet, nope that's one issue that only hggdh is able to reproduce in his kvm installation [16:25] so no regression there either [16:25] ok, thanks. [16:26] any other questions? [16:26] you're welcome [16:26] [TOPIC] HW certification - ara [16:26] New Topic: HW certification - ara [16:26] o/ [16:26] As usual, our reports for the current SRU cycle are located at: [16:26] [LINK] http://people.canonical.com/~hwcert/sru-testing/current/ [16:26] We got a coverage of 102/105 in Lucid and 105/116 in Maverick. Remember that this is the first cycle where we aim to test all the certified systems, rather than 75 systems for each release of the previous cycles. [16:26] LINK received: http://people.canonical.com/~hwcert/sru-testing/current/ [16:26] No regressions were found. We have updated both tracking bugs with this information. [16:26] .. [16:26] Thanks ara! [16:27] is there a summary of the tracking bugs anywhere? [16:27] (for the failing systems....) [16:27] sorry? [16:27] for the systems that failed lucid 3, maverick 11 [16:28] skaet, what are you looking for in a summary ? [16:28] * skaet should not have used the word tracking... sorry. [16:28] No, those were failing due to problems with the infrastructure [16:28] ara, ok, that's what I was trying to figure out. :) [16:28] and the answer I was hoping to hear ;) [16:28] (due to going up from 75 to all systems and finding issues on our way to reach all the systems) [16:29] it will get better .) [16:29] :) [16:29] :) [16:29] any other questions for ara? [16:29] [TOPIC] general SRU status - pitti [16:29] New Topic: general SRU status - pitti [16:29] by and large business as usuall [16:29] no current issues to report [16:30] ..? [16:30] .. [16:30] sorry [16:30] Thanks pitti. :) [16:30] any questions? [16:31] [TOPIC] Support priorities - martin-support [16:31] New Topic: Support priorities - martin-support [16:31] I have two [16:31] first one is the Segmentation fault trigger in ruby [16:32] https://bugs.launchpad.net/ubuntu/+source/ruby1.8/+bug/670571 [16:32] Ubuntu bug 670571 in rails (Ubuntu) "Segmentation fault in Marshal.load" [High,Fix released] [16:32] appears that there is confusion to what the bug is [16:33] that it is not fixed upstream, I have mixed messaging on the status [16:34] Daviey, ^^^ around? [16:34] skaet, o/ [16:34] second SRU I am tracking is the open-likewise [16:34] I think this is fixed, just need to have package to test [16:35] * Daviey reads [16:35] so, it's not sure if it is a bug with ruby or rails [16:35] rails can trigger a seg fault in ruby [16:35] I have fixed the bug in rails... but is it still and issue with core ruby? [16:36] I can have the pse run through the test case again [16:36] I'm not sure if or how to progress past thigs [16:36] this* [16:36] martins-support, please do. [16:36] (on natty) [16:36] ok, I will have a sync with you and etienne, thanks [16:36] martins-support, Or i can upload the fix to a Lucid PPA. [16:37] no, not yet, but its not what they want [16:38] thats all I have [16:38] thanks [16:38] martins-support, is there a bug for the open-likewise issue, or some specific help needed from someone? [16:38] I think colin is on it already, just giving the status that we have not tested it yet [16:38] thanks martins-support. :) [16:39] any questions for support? [16:39] [TOPIC] OEM priorities - vanhoof [16:39] New Topic: OEM priorities - vanhoof [16:39] * skaet looks around for vanhoof ... [16:40] [TOPIC] New business, last chance for general questions? [16:40] New Topic: New business, last chance for general questions? [16:40] ok, not seeing any hands.... [16:40] so think this is probably a good time to end. [16:40] #endmeeting [16:40] Meeting finished at 10:40. [16:40] Thanks! [16:41] thanks all [16:41] thanks all! [16:41] thanks, sconklin, bjf, pedro_, ara, pitti, marttin_support [16:41] thanks skaet [16:43] skaet: sorry was on another screen, all is well on my end presently [16:47] vanhoof, cool [16:47] thanks [16:47] skaet: np :) [16:55] skaet: FYI, KDE 4.5.5 is in queue for Maverick -proposed/updates. [17:05] ScottK, what's the system integration testing planned for KDE 4.5.5 before it goes out from -proposed/updates? [17:05] * skaet also figures we should probably move this to #ubuntu-release [17:05] skaet: It's been tested for a lot time in ~kubuntu-ppa. Once it's in maverick-proposed we'll call for additional testing. [17:05] lot/long [17:06] ScottK, ok, so we'll be looking for your ok or Riddell's then, after the testing is in, before moving to -updates? [17:07] Yes. The standard whine at pitti until he agrees we've tested it enough. [17:09] fair enough. Should I add you to the agenda for the next couple of SRU meetings then, so we can track this a bit? [17:09] ScottK, ^^ ? [17:10] I don't think it's necessary. I think it's adequately tracked through the normal SRU process. [17:10] SInce it's not LTS, there's no respin implications. [17:13] ScottK, ok. Meeting is SRU and LTS, and I was just a bit concerned there may be interacations with some kernel graphics drivers, etc. to worry about - so would be useful for the other teams to be aware. But lets see how it goes, and if all works smoothly no reason to make the meeting longer ;) === jj-afk is now known as jjohansen === Ursinha is now known as Ursinha-afk [18:12] hi! [18:14] \o [18:16] hello [18:17] alright, I guess we'll start [18:17] #startmeeting [18:17] Meeting started at 12:17. The chair is jdstrand. [18:17] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [18:17] [LINK] https://wiki.ubuntu.com/SecurityTeam/Meeting [18:17] LINK received: https://wiki.ubuntu.com/SecurityTeam/Meeting [18:17] [TOPIC] Review of any previous action items [18:17] New Topic: Review of any previous action items [18:18] afaik, the comodo aftermath should be all done as of last week. thanks micahg (I think chromium may be pending?) [18:18] [TOPIC] Weekly stand-up report [18:18] New Topic: Weekly stand-up report [18:18] I'll go first [18:19] I had a short week last week and am in the happy place this week [18:19] I am working on 2 kde updates right now (kde4libs and kdenetwork) [18:20] the former should be uploaded to the security ppa in a little bit [18:20] there are a number of bugs I need to follow up on-- a couple which will be rather time consuming (two different kernel bisections). I'm going to try to get to them this week [18:20] archive admin for beta-2 [18:21] jdstrand: anything you want to point me at there? [18:21] and more with performance reviews [18:21] jjohansen: well, they are kernel bugs seemingly unique to my hardware-- the kvm guest corruption and then a video driver issue [18:22] jjohansen: thanks for the offer though. I may have some questions on the process as I haven't done a kernel bisection in a while, but we'll see how it goes [18:22] jdstrand: right, well I have access to a big machine for building bisected kernels if you want :) [18:22] jjohansen: thanks for the offer though [18:22] jjohansen: ah, well, maybe I will then :) [18:22] jjohansen: thanks! [18:23] I also will be working on the usn microsite this week. it is hoped to go live soon (and the usn databse needs to be updated for those USNs where the isummary was not updated) [18:24] (more on the usn microsite later) [18:24] I have several things to bring up after the standup reports [18:24] kees: you're up [18:25] okay, last week, I did a bunch of stuff with unity [18:25] first, complaining about it, then opening bugs [18:25] did my patch pilot cycle [18:26] been trying to catch up on the state of kernel hardening again. some things have changed recently at redhat, so who manages nx-emu is up in the air again [18:27] trying to get ahead of my email too. down to 82 in my inbox. unfortunately they're all "hard" emails. :) [18:27] this coming week I was going to poke around at the beta + qrt and see if anything pops out [18:27] there are some kernel USNs coming down the pipe [18:28] that's it from me. [18:28] mdeslaur: you're next [18:28] kees: thanks [18:28] okie dokie [18:29] I'm currently testing dhcpd3 updates, will publish them this afternoon [18:29] and have some more updates to test [18:29] will probably be publishing them this week [18:29] and then, I'm going down the list [18:29] mdeslaur: re dhcp3> that is the one you pushed to natty last week? [18:29] nothing too exciting :) [18:29] jdstrand: yes [18:29] that's it from me [18:30] * jdstrand did a dhcp/natty upload today for an apparmor fix and wanted to make sure we were on the same page [18:30] jdstrand: I'm on page 37, last paragraph [18:30] mdeslaur: cool, me too [18:30] mdeslaur: what's that in kindle terms, 28%? [18:30] jdstrand: hehe, yeah it's the same CVE as the one in natty that I uploaded friday [18:31] sbeattie: 1104-1324 whatever that means :) [18:31] sbeattie: you're up [18:31] hehe [18:31] Let's see, I'm on triage this week. [18:31] I'm also currently working on php5 and ia32-libs. [18:32] I poked around last week a bit with the jenkins packaging ppa (continuous integration tool), and have made good progress on getting automated apparmor builds going. [18:33] I'm also eyeing jenkins for some qa-r-t automation. [18:33] I think that's it for me. [18:33] cool :) [18:33] micahg_: you're next [18:34] so, there's still a chromium update lingering, but we're blocked on the password loss regression [18:34] there should be a round of mozilla updates to test soon [18:35] micahg_: what is the status of the password loss? is upstream doing anything about it? [18:35] and I hope to start working through natty QRT testing [18:35] jdstrand: doesn't seem like it [18:35] micahg_: aiui, if we upload people lose access to all their saved passwords. is that correct? [18:36] most probably, yes [18:36] micahg_: does it stay broken or can people start saving again and it works? [18:37] jdstrand: they can start saving again, but there will be another update later which might "fix" it later [18:37] micahg_: so then they end up with 2 different password databases (essentially)? === Ursinha-afk is now known as Ursinha [18:37] yes [18:38] ugh [18:38] micahg_: and there is no movement upstream? [18:38] maybe even 3 depending on the setup (GNOME, KDE, internal) [18:39] doesn't seem to be, they promise to fix it later and give workarounds [18:40] was the problem caused because we (ie Ubuntu chromium maintainer) used the new password functionality two early (ie did we enable something experimental)? are any of these workarounds things that can be packaged? [18:40] micahg_: ^ [18:40] s/two/too/ [18:41] jdstrand: no, it's because one of the new features in Chromium 10 interacts poorly with the GNOME keyring [18:41] * jdstrand shakes head [18:41] fta was looking into packaging one of the workarounds, but the problem is, it doesn't work all the time [18:41] this is a very poor user experience and a bad position to be in [18:42] so basically, it's either security, or no lost passwords? [18:42] * mdeslaur votes for security [18:42] mdeslaur: well yes. the thing is we thought it would be fixed by now [18:42] is there a possibility of sending out a USN just for this one instance? [18:42] it is to the point where we need to get the update out though [18:43] micahg_: we could, but I'd rather not. it wouldn't reach all the users anyway [18:43] I was thinking maybe a NEWS file [18:43] that is a big hammer though [18:43] yeah, we could do that, but how many people read those? [18:43] kees, mdeslaur, sbeattie: ^ opinions? [18:43] micahg_: the NEWS file will pop up on every upgrade. I don't think update-manager can suppress those [18:44] hmmm [18:44] I think we should just push out the update. People who are using upstream's package will have gotten the new update anyway, and this is exactly the type of problem we expected when we started doing full version updates [18:44] I think that it is also very important to note this situation if chromium is ever considered for main [18:45] yeah, agreed on both counts. [18:45] I don't think NEWS file is needed. [18:45] mdeslaur: I agree we should push the update. I am just trying to improve on the poor upstream user experience [18:46] jdstrand: I think that's unforutnately in the upstream's hands :( [18:46] jdstrand: unfortunately, this is the way upstream wants us to handle it [18:47] I don't think upstream said anything about the NEWS file. not being daft, but we are packaging something that is separate from their official chrome [18:47] as such, I think there is a responsibility to try to help the users. the NEWS file may not be that [18:47] oh, I wasn't talking about the NEWS file [18:48] mdeslaur: sorry, I read kees' comment first, then yours, so misinterpreted [18:48] kees: can you elaborate on your NEWS file opinion? [18:48] jdstrand: it's not a strongly held opinion. :) I just think it's a bit of overkill [18:49] jdstrand: but perhaps it is the best way to communicate the change [18:49] * mdeslaur thinks about 2 people will read the NEWS file [18:49] is the "reboot required" notification generalizable? [18:49] kees: I agree it is a huge hammer, but I'm not sure what else to do [18:50] I thought the NEWS file showed up on all upgrades... [18:50] * jdstrand could be wrong [18:50] I don't think update-manager shows them, but I could be wrong. I haven't tested that in a long while [18:50] I specifically remember that we actively chose not to use a NEWS file in the openssl issue from a couple of years ago [18:51] well, if it doesn't display in update-manager, then it doesn't matter [18:51] the changelog should be heavily commented then [18:52] micahg_: can you and fta coordinate that and the practicality of a NEWS file? [18:52] jdstrand: yes [18:52] micahg_: thanks [18:53] micahg_: what is going on with wekit? [18:54] jdstrand: back burner still, will try to get out the update before EOM, but it'll be tight [18:55] micahg_: please make it your highest priority-- ahead of qrt. feel free to coordinate the chromium work though [18:55] micahg_: the rest of the team can do the qrt stuff [18:55] jdstrand: ok, there are also another round of mozilla updates for next tuesday, should it go ahead of that? [18:56] meh [18:56] jdstrand: heh, nm, that was just pushed back a week :) [18:56] micahg_: please get them building like chrisccoulson would do, so that if they don't have changes we don't have to wait on the builds and do last minute testing [18:57] micahg_: sounds like you have your work cut out for you (again :) [18:57] micahg_: anything else for this week? [18:57] jdstrand: ok, will do later this week (builds won't be created until Wed) [18:58] jdstrand: I think that's enough for me :) [18:58] micahg_: thanks! [18:58] [TOPIC] Miscellaneous and Questions [18:58] New Topic: Miscellaneous and Questions [18:59] looks like the hardy desktop EOL announcement went out today and the EOL is may 12th [18:59] that is not optimal, but I discussed with the release team and we will be in on the conversations for EOL delays going forward [19:00] performance reviews are entered into the system for everyone, but there is more I need to do this week [19:00] "Dapper needs another year of support. Kthnxbye." [19:00] ;-) [19:00] heh [19:01] that is not funny :) [19:01] we need to be thinking about UDS topics [19:01] if people can make an individual list of things to move forward, things to revisit and new stuff to work on, that would be great [19:02] we can discuss those in the next week or so as a team and get bps, going, etc, etc [19:02] jdstrand: where are we consolidating those ideas? [19:02] micahg_: no where yet-- just make a personal list for now, jotting down what you think of [19:03] k [19:03] s/no where/nowhere/ [19:03] so, this might be a UDS topic (as apparmor upstream), but at this point, what can we do to get apparmor kernel and userspace tools into Debian? [19:04] Get kees to upload them? [19:04] profiles aren't as big of a deal, but it would be nice if people could apt-get it [19:04] ugh, good question [19:04] ScottK: I think there is kernel coordination involved there [19:04] jjohansen: is it possible to just have Debian enable apparmor without the compat patches with our current tools? [19:05] jjohansen: or even just apparmor_parser? [19:05] * jdstrand is less concerned about the profiles atm [19:05] jdstrand: yes [19:05] its just the tools that break [19:06] jjohansen: so profile generation by hand should work ok, correct? [19:07] yep [19:07] even initscript load [19:07] just to restart [19:08] maybe our first step should be to get it enabled in the kernel, and then ship the initscript and the parser only [19:08] (and abstractions, and other stuff that isn't broken) [19:08] kees: ^ what do you think? [19:11] well, we can revisit that later [19:11]