[00:07] <Sarvatt> broder: there's only been 2 kernel SRU's to natty so far and 2.6.38.x is dead so things need to be recommended manually, absolutely yes :)
[00:08] <broder> ok, cool. i'll try to learn how the process works and send off the patch :)
[07:38] <ppisati> morning *
[08:25] <apw> ppisati, morning
[08:34] <ppisati> looks like LP is down...
[08:35] <ppisati> ok, it's back
[08:36] <apw> ppisati, for maintenance ?
[08:36] <ppisati> no no
[08:36] <ppisati> just got the Oops page for some reload in a row
[08:36] <ppisati> now it's ok
[08:41] <apw> ppisati, ahh yes she does do that to annoy one
[08:44] <ppisati> they respun natty, or so it seems...
[08:45] <apw> respun ?
[08:46] <ppisati> yep
[08:46] <ppisati> respin
[08:50] <apw> do we know why this time ?
[08:51] <ppisati> just deleted the email, but there was a regression in a patch
[08:51] <ppisati> patch reverted and kernel respinned
[08:51] <ppisati> and thus all the derivative pkgs got a new tracking bug
[08:52] <apw> ahh nice
[09:49] <apw> ppisati, bah ... we didn't sign your key last week
[09:51] <ppisati> apw: want it now? :)
[09:51] <apw> bah humbug
[09:52] <apw> ppisati, didn't realise you were signing the tags too ... we must remember to do it the next time we are together
[09:52] <ppisati> k
[12:34] <sladen> ogasawara et al: bug #834725 - are we short of a kernel interface that powertop needs?
[12:34] <ubot2`> Launchpad bug 834725 in powertop "Powertop fails to report number of wakeups/events" [Medium,Triaged] https://launchpad.net/bugs/834725
[13:06] <ogasawara> sladen: I'm unaware of anything off the top of my head, we' have to investigate further
[14:05] <bjf> ##
[14:05] <bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[14:05] <bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
[14:05] <bjf> ##
[14:11] <ppisati> herton: natty has been respinned, but natty/ti-omap4 doesn't depend on natty/master thus i'm invalidating the tracking bug
[14:11] <herton> ppisati: ok
[14:12] <ppisati> herton: not so fast: http://paste.ubuntu.com/688351/
[14:14] <herton> ppisati: hmm I didn't run the script for a while, may be something changed in lpltk. Are you running with the latest python-launchpadlib-toolkit from arsenal-devel ppa?
[14:22] <ppisati> herton: actually i was running the vanilla py-lpltk
[14:34] <herton> ppisati: the vanilla should not work, does it work updating to latest python-launchpadlib-toolkit? (# apt-add-repository ppa:arsenal-devel/ppa; apt-get update; apt-get install python-launchpadlib-toolkit
[14:39] <herton> ppisati: I'm going to lunch, let me know if it doesn't work
[14:39]  * herton -> lunch
[14:48]  * ogasawara back in 20
[14:52] <ppisati> herton: worked fine, thanks
[14:52] <ppisati> for the kernel irc meeting: arm status -> http://paste.ubuntu.com/688380/
[14:53] <apw> ppisati, not going to be around to deliver it ?
[14:53] <apw> bjf, ^^
[14:54] <bjf> apw, no one cares about arm
[14:54] <bjf> :-P
[14:55] <ppisati> :)
[14:55] <ppisati> luckily no ones care about arm... :)
[14:55] <ppisati> sent an email on the k-t m-l
[15:18] <ppisati>  /quit
[15:32] <jjohansen> ogasawara, apw, tgardner: so I have been looking at CONFIG_DYNAMIC_DEBUG (last of the work items) and I don't see a reason to enable it on production systems.  It requires debugfs be mounted and then you can dynamically enable/disable per call site, code that used pr_debug()/dev_dbg().
[15:32] <jjohansen> Its okay for debugging when you insert extra debug code using these or the bug is near code already there using those.  So I am recommending it as another debug tool when building debug kernels, but don't see the point on enabling it on production systems.
[15:32] <jjohansen> ogasawara: I will close off the work item
[15:33] <ogasawara> jjohansen: ack, thanks.
[15:33] <apw> jjohansen, sounds good, just note that in the spec in the results section
[15:33] <jjohansen> apw: ack
[15:40] <tyhicks> jjohansen: Take this with a grain of salt, but I thought that dynamic debug was now the preferred way to log debug messages as opposed to each subsystem having their own one-off way of logging debug messages?
[15:41] <tyhicks> jjohansen: For example, eCryptfs is way too verbose for a filesystem, but what is dumped out to syslog is a great help for me to triage bug reports
[15:42] <jjohansen> tyhicks: hrmm right
[15:42] <tyhicks> jjohansen: I was hoping to switch everything over to dynamic debug at some point so that a user can flip the switch when they hit problems and get me useful debug messages
[15:43] <jjohansen> tyhicks: I look some more, I am not opposed to having it on.  I'll look some more at what subsystems are using it.
[15:45] <tyhicks> jjohansen: Good idea - maybe no one is using it. I don't care one way or the other, at this point, since eCryptfs doesn't currently use it
[16:00] <bjf> ##
[16:00] <bjf> ## Kernel team meeting in one hour
[16:00] <bjf> ##
[16:14] <bjf> apw, did you ship the box ? :-)
[16:15] <apw> should be going in the morning
[16:15] <apw> i am sick of it filling up my hall ...
[16:38] <jjohansen> rebooting
[16:54] <bjf> ##
[16:54] <bjf> ## Kernel team meeting in 7 minutes
[16:54] <bjf> ##
[17:04] <jjohansen> ogasawara: I have an ecryptfs patch upstream I would like to squeeze into today if possible
[17:04] <ogasawara> jjohansen: sure, send it to the list asap.
[17:04] <jjohansen> ogasawara: ack
[17:04] <kirkland> jjohansen: cool, which one?  trailing garbage?
[17:04] <ogasawara> jjohansen: I plan on uploading this afternoon
[17:05] <kirkland> ogasawara: missed you in Santa Rosa last week -- running trail by hotel and weather were both exceptional!
[17:05] <jjohansen> kirkland: uhm can't remember but I think so.  I cherry-picked it last week but didn't get to testing it
[17:05] <kirkland> jjohansen: k
[17:05] <ogasawara> kirkland: I think I would have died :)  I literally haven't ran for over a year now.
[17:06] <kirkland> ogasawara: wow!  no kidding!  I did eight miles, from the hotel into a bunch of vineyards, and back, 59F (which is over 40 degrees cooler than here right now)!
[17:07]  * ogasawara decides to break out the running shoes today
[17:08] <apw> sconklin, all those !verified reversions, is there someone needing a kick on those?  or is it just many people
[17:09] <sconklin> it's many people, and a number of reasons. I'd have to look but I think the most common is "I've found a workaround, and although I have a reproducer and reported it, I have no interest in helping you"
[17:09] <kirkland> ogasawara: i'm early, but on track and signed up for the next Austin Marathon
[17:09] <apw> sconklin, shame we can't apply a patch to stop their work around working too
[17:09] <sconklin> there's also some "I told you it fixes the problem when it was a one-off patch applied for a test, I see no need to test your -proposed kernel"
[17:10] <sconklin> and a lot of just never getting a response at all to the calls for testing
[17:10] <sconklin> it's all in the bugs which were linked
[17:11] <apw> sconklin, welll lets hope discovering we arn't going to fix it if they ignore it will shake them up
[17:11] <sconklin> The ecryptfs and nouveau ones were especially annoying. The ecryptfs one got pulled from 2 or 3 kernels
[17:11] <apw> sconklin, that sounds like the one jjohansen is trying to put into oneiric
[17:12] <sconklin> https://bugs.launchpad.net/ecryptfs/+bug/509180
[17:12] <ubot2`> Ubuntu bug 509180 in ecryptfs "ecryptfs sometimes seems to add trailing garbage to encrypted files" [High,Fix released]
[17:12] <apw> jjohansen, ^^ is that the one you are talking about ?  
[17:13] <jjohansen> apw: checking
[17:14] <jjohansen> apw: no https://bugs.launchpad.net/ecryptfs/+bug/816387
[17:14] <ubot2`> Ubuntu bug 816387 in ecryptfs "ecryptfs kernel panic when rebooting/shutdown" [High,Fix released]
[17:15] <apw> so it sounds like kirkland was intereested in the ones we've just reverted for lack of testing
[17:15] <jjohansen> I did look briefly at 509180 and that is why I wasn't sure
[17:16] <broder> newbie question - where is the natty kernel in the sru cadence right now?
[17:16] <jjohansen> rebooting
[17:18] <apw> broder, i think that was jut reported on #ubuntu-meeting
[17:19] <broder> apw: oh, ok. i think i see it, thanks
[17:19] <apw> broder, and i think it is 'unverified fixes now reverted, awaiting QA before release'
[17:19] <sconklin> broder, this is a good place to look any time http://people.canonical.com/~kernel/reports/kernel-sru-workflow.html
[17:20]  * broder awesome. that is very helpful
[17:22] <apw> Phase:  CopyToUpdates
[17:22] <apw> Tags:  certification-testing-passed, kernel-release-tracking-bug, lucid, qa-testing-passed, verification-failed 
[17:22] <apw> that doesn't seem to make much sense for the lucid one, given copy to * are invalid too
[17:23] <apw> sconklin, herton ^^
[17:23] <sconklin> That's because it was stopped at the last minute from being published due to the i915 regression
[17:24] <sconklin> The "Phase" still reflects the phase it was stopped in
[17:24] <apw> perhaps shank should say "Unknown (was XXX)" when it sees Incomplete
[17:25] <kirkland> apw: was it a lack of testing, or was the patch clearly shown to cause regressions or not fix the issue?
[17:25] <sconklin> those represent some well defined states, and it is going to take some deeper discussion before changing them
[17:25] <apw> kirkland, lack of testing i think was the report ... sconklin the ecryptfs patch reversion was !tested right
[17:26] <sconklin> lack of testing
[17:31] <kirkland> apw: sconklin: who has that responsibility?  the community?
[17:31] <sconklin> kirkland: generally the reporter, or whoever cares
[17:32] <kirkland> sconklin: hmm, okay
[17:32] <jjohansen> kirkland: reporter, community or someone who is interested and can reproduce.
[17:32] <kirkland> jjohansen: okay, thanks
[18:30] <salty-horse> hi. anyone around? looking at <https://wiki.ubuntu.com/KernelTeam/Specs/KernelOneiricUbuntuDeltaReview> I see the section about fsam7400 and a consideration for dropping it. there's another, more recent implementation called fsaa1655g: http://ubuntuforums.org/showthread.php?t=1530962
[18:30] <salty-horse> what does it take to include it by default?
[18:59] <ogasawara> salty-horse: the best way to have it included by default is to get the driver included upstream.  I'm not in favor of carrying an out of tree driver, especially one which looks like it was last touched in 2006.
[19:00] <salty-horse> ogasawara, the one i linked seems to be from 2010
[19:00] <salty-horse> upstream == debian?
[19:01] <dupondje> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/703180 any chance this could be fixed before final?
[19:01] <ubot2`> Ubuntu bug 703180 in linux "SD card reader doesn't work on new Dell XPS" [Undecided,Confirmed]
[19:01] <ogasawara> salty-horse: by upstream I mean the upstream linux kernel
[19:02] <salty-horse> hmm.. well I have nothing to do with that project, and I'm not a kernel hacker. it does seem to prevent me and others from having a functioning machine
[19:03] <ogasawara> salty-horse: might be best to get in touch with the driver maintainer and ask if they'd work to get the driver upstream
[19:04] <salty-horse> emailing
[19:08] <ogasawara> jjohansen: how's that ecryptfs patch coming?
[19:08] <jjohansen> ogasawara: give me 15 min, I am just compile testing
[19:09] <ogasawara> jjohansen: ack
[19:14] <dupondje> ogasawara: don't know if you could check https://bugs.launchpad.net/ubuntu/+source/linux/+bug/703180 and maby put priority or so? Cause alot of people seem to hit this bug :)
[19:14] <ubot2`> Ubuntu bug 703180 in linux "SD card reader doesn't work on new Dell XPS" [Undecided,Confirmed]
[19:23] <jjohansen> ogasawara: heh, go turns out my tree was a couple few days out of date, the patch is already in
[19:23] <ogasawara> jjohansen: heh, cool works for me.
[19:24] <ogasawara> dupondje: I'll take a look and triage that bug in a bit.  gotta get a kernel out the door first.
[19:26] <dupondje> thx :)
[19:40]  * jjohansen -> lunch
[20:49] <kees> apw: woooo, run your merge & export, loooooots of CVEs closed now that the arms published :)