[00:46] <psusi> jjohansen, so let's figure out how to handle it ;)
[00:51] <psusi> the kernel needs some way of notifying the clients ( fs, md, dm, blockdev ) of the block device that it either wants to be , or already has been ( requested or surprise ) removed so they can release the bdev pointer.  that seems a wee bit problematic by the fact that multiple clients can have references...
[00:58] <jjohansen> psusi: yes its problematic
[07:08] <apw> mjg59, the original was pulled as it was generic, that one is restricted to two models of dell where the touchpad doesn't work at all with alps, thats my memory anyhow ... causing issues ?
[07:18] <smb> morning
[07:24] <apw> morning
[07:26] <jk-> hey smb & apw
[07:26] <smb> hey jk- 
[09:02] <cking> yawn
[09:12] <apw> cking, morning
[09:14] <cking> apw, hiya
[09:14] <apw> cking, hows it going ...
[09:14] <cking> fine
[12:36] <mjg59> apw: Well, it still doesn't work at all with alps in any real way
[12:36] <mjg59> apw: You're still just changing one non-configurable setup for another
[12:37] <apw> mjg59, the patch as commited only applies to those specific models but yes its crap
[12:38] <apw> mjg59, i am told that alps refuse to disclose how to enable the touchpad correctly as a touchpad
[12:39] <mjg59> You end up with something where you can't turn off tap to click, which may or may not be preferable to the original state
[12:40] <apw> mjg59, yeah i get you, cause its not a touchpad that option doesn't exist, sigh
[12:40] <mjg59> Right
[12:40] <mjg59> ALPS seem to believe that their multitouch protocol is a massive trade secret
[12:40] <mjg59> And it's annoyingly inconvenient to trace PS/2
[12:40] <apw> i can only call the whole mess, well a mess
[12:41] <apw> yeah ... we are pushing vendors to use something else for their linux enabled stuff, they are just too painful to talk to
[12:41] <mjg59> But Dell aren't willing to push ALPS because that patch exists and is carried by Ubuntu
[12:44] <apw> mjg59, great indeed
[12:45] <mjg59> So kind of an awkward situation for everyone
[12:46] <mjg59> I should look into whether I can work out the init sequence using qemu, really
[12:48] <apw> if you have the kit yeah that would be a good plan me thinks
[13:26] <ogasawara> hrm, anyone recall if bjf had a script which closed a bugs task that has a nomination which is EOL
[13:27] <ogasawara> I'm particularly looking at https://bugs.launchpad.net/ubuntu/karmic/+source/linux
[13:27] <tgardner> ogasawara, seems like he's been running something lately since I've seen a bunch of those kind of closures.
[13:29] <apw> ogasawara, if not it should be a trivial one to write
[13:29] <ogasawara> apw: indeed, was just hoping to save myself the 10min since I'm lazy
[13:30] <ogasawara> I'll just wait till he comes online
[13:31] <ogasawara> I'm thinking that whatever creates the CVE bugs should also drop adding karmic as a target, if it's not already fixed that is
[13:32] <apw> ogasawara, ok i've finally rememberd to add that section to the config review, with the modulular things which are not modular
[13:32] <apw> ogasawara, i believe we already have stopped adding karmic for cves
[13:32] <apw> ogasawara, and my script should be closing them out, do you have an example of a non-won't-fix one ?
[13:33] <ogasawara> apw: I actually meant to say if the script wasn't already fixed, it should be
[13:34] <apw> ogasawara, i believe it is suppressed by the karmic being mark Supported: false
[13:36] <apw> ogasawara, https://wiki.ubuntu.com/KernelTeam/Specs/KernelOneiricConfigReview#Non-modular_modules is the full list which needs review.  not sure how we should handle the review part, prolly needs a wi
[13:38] <ogasawara> apw: cool.  I'll add myself a work item to start sifting through them.
[13:52] <apw> ogasawara, last week we found a page which had your report on it for the bugs for the meeting, since then the link seems to have gone dead in th
[13:52] <apw> the readme, did it move ?
[13:53] <ogasawara> apw: can you point me to which README?
[13:54] <apw> kteam-tools/irc-meeting/README
[13:56] <ogasawara> apw: hrm, I'd been using http://reports.qa.ubuntu.com/reports/ogasawara/kt-meeting.txt but I do recall I should have move it from my own personal directory to the kernel-ppa/reports
[13:57] <apw> ogasawara, would it run on people? as most of the reports are there
[13:57] <ogasawara> apw: I don't see why know, I'll move it there for consistency and update the README
[13:57] <ogasawara> wow, s/know/not/
[14:01] <bjf> ogasawara, we talked about adding it to the Makefile that generates all the reports
[14:01] <ogasawara> bjf: yep, makes sense
[14:02] <ogasawara> bjf: also before I forget, didn't you say you had a script which closes out a bug task for a nomination that is not EOL
[14:02] <bjf> ogasawara, if that did/does happen, I'll need to update the copy of kteam-tools in people/~kernel
[14:02] <ogasawara> bjf: i was looking at https://bugs.launchpad.net/ubuntu/karmic/+source/linux
[14:03] <bjf> ogasawara, i was "won't fix"ing bugs last night that were filed against dapper, feisty, and intrepid
[14:04] <bjf> ogasawara, i don't have one that changes nominations for tasks that are EOL (but I should)
[14:04] <apw> ogasawara, let me know when you are done fiddling with kernel i have something to add too
[14:04] <ogasawara> bjf: ok no worries, I'll whip up a script to close out EOL nominations
[14:04] <ogasawara> apw: ack
[14:04] <apw> bjf, i assume the "plan" is to check everything into team-tools, and then rsync it over the one in ~kernel ?
[14:04] <ogasawara> bjf: I assume I can edit the Makefile the same as I did when I added my CVE report
[14:04] <hggdh> bjf: just confirming, the only other kernel for us (QA) to test now is Hardy, correct?
[14:05] <bjf> apw, yes, that's how I do it
[14:05] <bjf> ogasawara, yes
[14:05] <apw> bjf ok cool
[14:05] <bdmurray> apw, ogasawara: I've uploaded a new version of kerneloops which should *not* report WARNINGs.  I'm working on the driver tagging today.
[14:06] <ogasawara> apw: go ahead and add whatever you need to kernel, I have to tweak my script I think
[14:06] <bjf> ogasawara, look at mark-unsupported-wont-fix in kteam-tools/bugs 
[14:06] <bdmurray> apw, ogasawara: so if you happen to see any Oopses with warnings in them let me know.
[14:06] <bjf> hggdh, you have to ask sconklin 
[14:06] <ogasawara> bdmurray: awesome, thanks
[14:07] <bjf> bdmurray, are you prefixing the driver tags with "kernel-" or anything, or is it just the driver name?
[14:07] <bdmurray> bjf: just the driver name
[14:08] <bdmurray> I gave ogasawara a list of the existing oopses I tagged
[14:08] <bjf> bdmurray, if ogasawara and apw agree, I think it should be prefixed with "kernel-driver-"
[14:08] <ogasawara> bjf: that's fine with me, I just had bdmurray originally tag by driver name just for simplicity
[14:10] <bjf> ogasawara, since we are prefixing all our other tags with "kernel-" and since I think it makes it more clear what that tag is for, it would be nice to have the prefix
[14:10] <ogasawara> bjf: makes sense
[14:12] <bjf> ogasawara, i can also put together a report based on just "kernel-driver-*" bugs at some point
[14:12] <bdmurray> I guess it would be easier to find new ones too
[14:12] <ogasawara> bjf: that would be nice
[14:12] <bdmurray> rather than if something just got tagged e1000
[14:12] <herton> hggdh: not only hardy, including it these bugs are waiting for QA: 801636 806586 808934
[14:13] <bdmurray> bjf: I'll try and find whatever I wrote to tag the existing Oopses and retag them with kernel-driver-fglrx (or whatever)
[14:14] <bjf> bdmurray, that would be great, thanks
[14:15] <bjf> bdmurray, maybe after whatever changes you make this time and after this run of it, we should take it into our tools repo and maintain it ?
[14:16] <hggdh> herton: thanks. I was not aware we were doing backporting tests also
[14:16] <herton> hggdh: I'm not sure what is done about lts-bakckport packages also regarding QA
[14:16] <bdmurray> bjf: so the plan is to modify apport so that oops are tagged kernel-driver-drivername when the oops is being submitted.  This is just cleaning up the already reported stuff so really should be a one time thing.  Additionally, its a mess of parsing Oops reports that I've downloaded
[14:17] <bjf> bdmurray, ah! ok, that makes sense

[14:17] <bjf> bdmurray, disregard my earlier comment, still waking up
[14:17] <herton> hggdh: steve mentioned that for backport packages teams have to sign-off on them also, so I guess it is up to you, but better confirm with him later
[14:18] <hggdh> herton: I just wish I got to be informed of things that affect QA
[14:19] <apw> hggdh, don't the tasks in launchpad tell you things you need to be concerned with ?
[14:19] <hggdh> apw: not enough of a warning, if you add in unplanned-for work
[14:20] <apw> hggdh, so what sort of warning are you looking for
[14:21] <hggdh> apw: something like 'hey QA, we are going to add backporting tests to your expected work load, how about getting ready to it?' <- in advance
[14:22] <apw> hggdh, are we talking about lts-backport-foo here ?
[14:22] <hggdh> apw: bugs 806586 808934
[14:22] <ubot2> Launchpad bug 806586 in kernel-sru-workflow/security-signoff "linux-lts-backport-natty: 2.6.38-10.46~lucid1 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/806586
[14:23] <ogasawara> bjf: do by chance know if lplib has a way of retrieving a list of current supported releases, so I don't have to maintain a hardcoded list like "releases = ['oneiric', 'natty', 'maverick', 'lucid', 'hardy']"
[14:24] <bjf> ogasawara, in kteam-tools look at ktl/ubuntu, also look at the script i mentioned earlier, it calls a method to determine "support"
[14:24] <ogasawara> bjf: cool
[14:25] <bjf> ogasawara, basically, we already maintain a master list and it's in ktl/ubuntu.py
[14:30] <apw> hggdh, ahh my understanding of why we are passing those your way, is cause you were signed up to do them
[14:32]  * herton -> lunch
[15:07]  * ogasawara back in 20
[15:11] <apw> ogasawara, where can i find your current report, want to look at the format
[15:18] <paultag> Hey kernel-ers. I've been testing btrfs for the cycle, and it's gotten to the point of horrid IO times, to the point where bootup is taking much longer then it should (2.6.38-8-generic-pae) -- has anyone heard anything about IO speeds on the +1 kernel, or upstream?
[15:19] <paultag> It feels like I'm back in 2004 :)
[15:19] <apw> paultag, nothing specific other than a general feeling that as they fix consistancy issues in btrfs it is losing its performance edge
[15:19] <tgardner> paultag, have you tried oneiric? a lot of work has gone into btrfs this cycle
[15:20] <paultag> tgardner: I have not, I'm still on natty. Should I consider it?
[15:20] <paultag> apw: well that's good anyway :)
[15:21] <paultag> Is there any way I can dump some sort of profile or set of statistics that might help development upstream?
[15:21] <tgardner> paultag, absolutely. you can run the oneiric kernel without having to change your user space.
[15:21] <paultag> tgardner: sure, sure :)
[15:25] <paultag> Also, I do have one other, perhaps related, issue. Once in a while, after the screensaver's been on and DPMS shuts off the screen, the kernel locks up (not sure if btrfs blocks or fails a read, and it's stuck waiting for IO, or if it's kernel it's self, but I don't recall this with ext4), and will only respond to a REISUB. Does anyone have advice on how to debug this, and put together a sane report?
[15:26] <paultag> it's fairly reproducable, and it always happens when I need my machine in a bad way :)
[15:26] <paultag> (then I have to put up with a horrid boot time, welcome to my hell)
[15:27] <apw> paultag, is it always when DPMS has triggered, there was/is a problem with vsync not restarting and breaking compiz
[15:28] <ogasawara> apw: http://people.canonical.com/~kernel/reports/kt-meeting.txt
[15:28] <paultag> apw: I seem to recall one time seeing the screensaver frozen, but that could have been some sort of race condition. I also have two monitors if that helps debug anything
[15:29] <paultag> apw: should I upgrade a package or two and test if it is vsync?
[15:29] <apw> paultag, i guess i'd wnat to know if you can login remotly, that'd be the first test
[15:30] <paultag> apw: good point. I'll install ssh and wait for it to happen, then let ya'll know. Since I REISUB, I'm guessing the kernel's online, and it does not look like a panic, so it *should* work
[15:30] <paultag> apw: cheers, thanks!
[15:30] <apw> np
[15:59] <ogasawara> bjf: how often does the cron on lillypilly run for the kernel reports?
[16:00] <ogasawara> bjf: nm, every 30
[16:16] <apw> bjf, is this in a tabalable form for the irc converter: http://people.canonical.com/~apw/cve/pkg/CVE-linux.txt
[16:18] <bjf> apw, yes, any "moin table" format can be handled
[16:19] <apw> at rally we talked about reporting something in the weekly meeting on CVEs and that seems like the sort of thing, what you think
[16:20] <bjf> apw, that looks good to me
[16:20] <apw> ok will get that into the readme while i am at it, if you could add to the agenda
[16:20] <apw> probabally belongs in the 'stable' section
[16:21] <bjf> apw, ack
[16:21] <bjf> apw, who should i put as the reporter? you for now?
[16:21] <apw> bjf sure
[16:23] <ogasawara> what are the devel and mainline branches of kteam-tools?
[16:23] <bjf> ogasawara, ignore "devel", i think sconklin created it
[16:24] <apw> ogasawara, yeah i work against the master always ... ps i just updated the README for irc so we are likely to collide
[16:24] <apw> bjf, i've added moveing the CVE stats and the CVE report over to ~kernel for my 'next week' todo list
[16:24] <ogasawara> apw: ack, I'll rebase and push
[16:25] <bjf> apw, ack, added agenda item to wiki page and to the runes
[16:26] <ogasawara> apw: did you push your bits up yet?
[16:26] <apw> ogasawara, yep
[16:26] <apw> feel free to just merge it and fix the README
[16:27] <apw> we are used to a mergetastic history
[16:27] <ogasawara> apw: I'm not seeing your bits on kteam-tools master
[16:28] <apw> ogasawara, brad found them, merged with them and pushed again
[16:28] <apw> so i assume they are up there
[16:29] <ogasawara> apw: ah that makes sense then, I was looking for you as the author
[16:29] <herton> ogasawara: devel is some experimental things we have been playing with (changes to sru workflow), just ignore it for now
[16:55] <apw> bjf, ubuntu.supported_serieses ?? really, is not the plural of series series ?
[16:55] <bjf> apw, yes, thanks for pointing out i can't spell
[16:56] <apw> bjf, heh its bad if i spell better than thou
[16:56] <bjf> apw, i blame being drunk but I know you wouldn't believe that
[16:56] <ogasawara> hehe, I saw that too and chuckled
[17:04]  * smb decides to end the day
[17:10]  * apw cracks a cold one in sympathy
[17:15]  * tgardner yanks the power to a noisy fan
[17:43]  * apw calls it a day ... see your all next week
[17:44] <jjohansen> have a good weekend apw
[17:45] <tgardner> apw, what is the derby thing ?
[17:53]  * tgardner --> lunch
[17:55] <vanhoof> hey guys -- quick question :)
[17:56] <vanhoof> latest oneiric kernel brought in the isci driver for newer intel sas controllers
[17:57] <apw> tgardner, fun is all
[17:57] <vanhoof> is there a process i should follow to request they be pulled into the initrd for installs?
[17:58] <apw> tgardner, updated it ... better ?
[18:18] <vanhoof> disregard my question :)
[18:46] <bdmurray> bjf: I'm to lazy to remove the existing tag so I'll just add kernel-driver-ipaq and leave ipqa
[18:46] <bdmurray> er ipqa
[18:47] <bdmurray> wtf ipaq
[18:47] <bdmurray> there!
[18:47] <bjf> bdmurray, ok
[19:05] <bjf> apw, did you pick a usb drive? i just picked up a Patriot Rage XT (8G). Avg. read rate: 31.6MB/s Avg write rate: 5.8 MB/s   
[21:58] <ohsix> did natty stop logging to /var/log/messages? :O my confings didn't change but theres no messages in there since march
[21:58] <ohsix> nm