[00:00] <ogasawara> JFo: not really, take a look at comment 19
[00:00] <JFo> hmmm
[00:00] <JFo> ok, so we have apport data for Jaunty...
[00:01] <ogasawara> JFo: yup, so they've provided the requested info
[00:01] <JFo> excellent
[00:01] <ogasawara> JFo: the only thing it seems they did not do was test the latest upstream kernel
[00:01] <JFo> so this one needs to be sent upConfirmed for Jaunty, Test Upstream
[00:01] <ogasawara> JFo: right
[00:01] <JFo> excellent
[00:01] <JFo> sorry, I keep saying that
[00:01] <ogasawara> JFo: actually just a reminder to test upstream if they could
[00:02] <JFo> so, standard response from the bug jam page
[00:02] <ogasawara> JFo: since it was already asked if they could test upstream in comment 19
[00:02] <JFo> right
[00:02] <ogasawara> yup
[00:02] <JFo> ok
[00:03] <ogasawara> JFo: we can actually remove the "needs-kernel-logs" tag since they ran the apport-collect command
[00:03] <JFo> ok
[00:03] <ogasawara> JFo: unfortunately removing the tag is a separate step from posting a comment and updating status
[00:03] <JFo> ah
[00:03] <JFo> ok
[00:04] <ogasawara> JFo: if you look at the bug description you'll see the list of "Tags"
[00:04] <JFo> I see them
[00:04] <ogasawara> JFo: click on the little yellow pencil icon at the end of the list
[00:04] <JFo> and the 'edit' icon :)
[00:04] <JFo> heh, right
[00:05] <JFo> just removing needs-kernel-logs, yes?
[00:05] <ogasawara> JFo: yup
[00:05] <JFo> ok
[00:05] <ogasawara> JFo: so one last thing, setting the Importance
[00:05] <JFo> ok
[00:06] <ogasawara> JFo: for the most part, bugs usually fall under the Medium Importance
[00:06] <JFo> I can't change that
[00:06] <JFo> ok
[00:06] <ogasawara> JFo: hrm, must be a bugcontrol thing.  I'll change it
[00:06] <JFo> ok
[00:06] <JFo> yeah, permission related as the tool tip tells me
[00:07] <JFo> or hover text or what have you
[00:07] <JFo> :)
[00:07] <ogasawara> JFo: once you feel comfortable enough triaging bugs, you'll want to apply for membership to ubuntu-bugcontrol
[00:07] <JFo> ok
[00:07] <JFo> sounds good
[00:07] <ogasawara> JFo: it requires a small application process where you submit 5 bugs you triaged in order to prove you know what you're doing
[00:08] <ogasawara> JFo: ok, lets move to the next bug
[00:08] <ogasawara> JFo: bug 307780
[00:08] <JFo> I'm with you
[00:08] <ubot3> Malone bug 307780 in linux "Suspend/Hibernate Not Working" [Undecided,Incomplete] https://launchpad.net/bugs/307780
[00:09] <ogasawara> JFo: this is another Incomplete bug, but you'll see they never responded to the last inquiry for information
[00:09] <JFo> so we need to ping them again?
[00:09] <ogasawara> JFo: actually, if they don't respond after 6weeks, I close them
[00:09] <JFo> ah
[00:09] <JFo> good call
[00:10] <JFo> so this one is well over that
[00:10] <ogasawara> JFo: I post a comment why we're closing it and let them know they are free to reopen the bug at any time
[00:10] <ogasawara> JFo: https://wiki.ubuntu.com/KernelTeam/BugDay/20090623#Old Incomplete
[00:11] <ogasawara> JFo: that's a typical stock reply that I'd use for that scenario
[00:11] <JFo> great 
[00:11] <ogasawara> JFo: you probably can't set it to Won't Fix, so go ahead and set it to Invalid
[00:11] <JFo> so technically they don't get closed, they just get set to WontFix?
[00:11] <JFo> ok
[00:12] <ogasawara> JFo: Won't Fix, Invalid, and Fix Released are all considered closed states in launchpad
[00:12] <JFo> ok
[00:12] <JFo> but able to be reopened
[00:12] <JFo> I see
[00:12] <ogasawara> right
[00:12] <JFo> done
[00:13] <ogasawara> JFo: I think we're ready to tackle some of the bugs on the bug day list now
[00:13] <JFo> ok
[00:14] <ogasawara> JFo: I know we can look at the community sections, but lets steal some from Tim Gardner's list (he's away on vaca)
[00:14] <JFo> heh
[00:14] <JFo> I'm ready
[00:14] <ogasawara> JFo: bug 352484
[00:14] <ubot3> Malone bug 352484 in linux "Wireless network not working, System lock-ups with Intel 4965 wireless" [Undecided,New] https://launchpad.net/bugs/352484
[00:15] <ogasawara> JFo: so as you read, the focus of the developer's list of bugs are wifi related bugs
[00:15] <JFo> I see that
[00:16] <ogasawara> JFo: for some drivers, like the iwl4965 driver, there are a few extra things they can test
[00:16] <JFo> k
[00:16] <JFo> so they have tried backports
[00:16] <JFo> do we need kernel logging for this too eventually?
[00:16] <JFo> or is this separate
[00:17] <ogasawara> JFo: we'll want to ask a bunch of things.  even though they tested linux-backports-modules-intrepid, we need them to test the newer Jaunty release
[00:17] <JFo> ok
[00:18] <ogasawara> JFo: if the issue remains in Jaunty, they should also try linux-backports-modules-jaunty
[00:18] <JFo> right
[00:18] <ogasawara> JFo: then run apport-collect to get debug files
[00:18] <ogasawara> JFo: also, I usually like to request they also confirm against the latest upstream compat-wireless stack
[00:18] <JFo> k
[00:18] <JFo> makes sense
[00:19] <JFo> so, standard response from the bug jam page for backports
[00:19] <ogasawara> JFo: it's sorta a lot to ask the bug reporter, bug if you make it a simple multi-step process it's much easier
[00:19] <JFo> looks like
[00:19] <ogasawara> JFo: so we'll likely want to mix and match some of the stock replies
[00:20] <JFo> I see
[00:20] <ogasawara> JFo: basically combining the "Test Jaunty" and "Test linux-backports-modules-jaunty" stock replies
[00:20] <JFo> ok
[00:21] <ogasawara> JFo: whenever I ask someone to test the latest upstream compat-wireless stack I tag the bug "compat-wireless"
[00:21] <JFo> right
[00:21] <ogasawara> JFo: likewise if I ask them to run apport-collect, I tag "needs-kernel-logs"
[00:21] <JFo> makes sense
[00:23] <JFo> done.. very straightforward
[00:23] <JFo> see what you think
[00:23] <JFo> :)
[00:24] <JFo> all I did was add the backport stuff before the 'let us know' bit and added an 'Also,'
[00:24] <ogasawara> JFo: looks great.  one small nit pick is when I paste the apport-collect command, I usually insert the actual bug #
[00:24] <JFo> ah
[00:25] <JFo> I didn't see that
[00:25] <JFo> <- slack
[00:25] <JFo> enabling them to copy/paste the command
[00:25] <ogasawara> JFo: no worries.  it's usually not an issue until you run into the bug reporter that copies and pasts verbatim and complains apport-collect crashes
[00:25] <JFo> I should have seen that
[00:25] <JFo> heh
[00:26] <ogasawara> JFo: lemme see if I can find another good example under the Community section before I turn you loose to do a few on your own
[00:26] <JFo> heh, ok
[00:28] <ogasawara> lets look at bug 21344
[00:28] <ubot3> Malone bug 21344 in linux-source-2.6.22 "Hang when loading ipw2100" [Undecided,Won't fix] https://launchpad.net/bugs/21344
[00:28] <JFo> wow 2005
[00:28] <ogasawara> JFo: it's an oldie
[00:29] <ogasawara> JFo: so one thing I want to start preventing is Triaged bugs which stagnate
[00:29] <JFo> I can certainly understand that
[00:29] <ogasawara> JFo: as you pointed out, this was reported way back in 2005 and the most recent comment was back in Dec of 08
[00:30] <JFo> I see that too :-/
[00:30] <ogasawara> JFo: and that was from the janitor no less, so the last real comment was back in Sep 08
[00:30] <JFo> yeah
[00:30] <JFo> do we need a 'Check for Jaunty' here?
[00:30] <ogasawara> JFo: Triaged to a developer should indicate a bug is up to date ready to be worked on
[00:30] <JFo> or is there something more
[00:30] <JFo> ah hah
[00:30] <JFo> ok
[00:30] <ogasawara> JFo: yup, so pretty much go through the same motions of asking the test against the latest release
[00:30] <JFo> but this is ooooold version
[00:30] <JFo> ok
[00:31] <JFo> cool
[00:31] <JFo> kick back to incomplete as well, yes?
[00:31] <ogasawara> JFo: yup
[00:31] <JFo> cool
[00:31] <ogasawara> JFo: so you'll notice a lot of triaging can be pretty redundant sometimes
[00:32] <JFo> yeah
[00:32] <JFo> but very necessary
[00:32] <ogasawara> JFo: there are some shortcuts, to make that easier :)
[00:32] <JFo> nice :)
[00:32] <ogasawara> JFo: first I'd point you to the launchpad greasemonkey scripts (noted in the bug day page)
[00:32] <JFo> scripts or built in LP tools?
[00:32] <JFo> ok
[00:32] <ogasawara> JFo: both
[00:33] <JFo> :)
[00:33] <ogasawara> JFo: I'd direct you specifically to the stockreplies gm-script as well as the karma suffix
[00:33] <JFo> ok
[00:34]  * JFo needs to unpack his Jaunty Lappy
[00:34] <ogasawara> the stockreplies will allow you to save canned responses, like test jaunty, test linux-backports-modules, and inject them automatically with a single click
[00:34] <JFo> oooh
[00:34] <JFo> I likey
[00:34] <ogasawara> the stockreplies gm-script is also capable of also setting the status and importance
[00:34] <JFo> very nice
[00:35] <ogasawara> JFo: I'm even lazier though and will often revert to using launchpadlib to knock out a whole list of bugs
[00:35] <JFo> hahahaha
[00:35] <JFo> I like that even more :)
[00:35] <ogasawara> JFo: but I'll save the launchpadlib stuff for a later date
[00:35] <JFo> ok
[00:35] <JFo> this is good ofr now
[00:36] <ogasawara> JFo: best to make you triage old school first
[00:36] <JFo> I need to understand first
[00:36] <JFo> yes :)
[00:36] <JFo> how often do you generate the list of bugs for the devs?
[00:36] <ogasawara> JFo: I generate them every 2 weeks
[00:36] <JFo> for instance, if I wanted to look over some of these this weekend...
[00:37] <JFo> ok good :)
[00:37] <ogasawara> JFo: but I'd be happy to generate some custom lists for you if you like
[00:37] <JFo> well, if it isn't too much trouble
[00:37] <JFo> I'd like to have a good list to tackle if you think I am up to it
[00:38] <ogasawara> JFo: definitely.  let me put together a few groups of bugs for you to work on.  I'll email you it tomorrow.
[00:38] <JFo> wonderful
[00:38] <JFo> I look forward to it
[00:38] <ogasawara> JFo: hope this quick triage session helped
[00:38] <JFo> immensely
[00:38] <ogasawara> JFo: obviously feel free to ping/email me with any additional questions
[00:38] <JFo> I'm glad to see that I will be able to help quicker than I thought
[00:38] <JFo> ok, will do
[00:42] <JFo> well, thank you for that excellent training ogasawara 
[00:42] <JFo> I'll hold off for today on the bugs until I see the list tomorrow
[00:43] <ogasawara> JFo: sounds good.  thanks for helping out
[00:43] <JFo> maybe I can help tackle some of the backlog
[00:43] <JFo> no problem at all :)
[00:43] <ogasawara> JFo: indeed, that would be great
[07:31] <\sh> how can we get rid of klibcs ipconfig inside the initramfs really fast...it's a nightmare in enterprise environments using PXE/NFS rootfs mounts
[10:17] <bullgard4> What does 'mmc' stand for in /usr/src/linux-source-2.6.28/drivers/mmc/core/sd.c?
[10:19] <ogra> multimedia card
[10:19] <smb> bullgard4, multi media controller? 
[10:19] <ogra> (SD cards)
[10:20] <smb> as far as I know its those controllers supporting multiple card types
[10:20] <ogra> yeah, or rather contrller :)
[10:20] <ogra> (damned i'm constantly using o's since a few days ... and cant find where they go)
[10:21] <smb> ogra, o's?
[10:23] <smb> overdose on style guide consumption?
[10:25] <bullgard4> ogra, smb Thank you for explaining.
[10:28] <Ng> is rfkill likely to be somewhat broken in 2.6.31 atm?
[10:29] <smb> Ng, Assuming on the fact there has been a rewrite: maybe
[10:30] <Ng> it's just that i noticed that in 2.6.30 the gnome bluetooth thing showed two killswitch tickboxes for my thinkpad's internal bluetooth adapter which correctly disabled it, but they don't in 2.6.31
[10:31] <apw> there is a likelyhood of rfkill horkage yes
[10:31] <apw> thought you should report it
[10:38] <Ng> ok
[11:30]  * apw notes that his machine is much happier under build loads with the latest karmic kernels
[13:38] <james_w> apw: I'd agree about the latest kernels and performance under I/O load
[13:38] <apw> its been a revelation, i can no build a kernel in the background wihtout need for ionice
[13:39] <james_w> I've got two parallel builds going, with the UI much more responsive than before
[13:39] <james_w> shame my disk is still really slow, but it's definitely an improvement
[13:40] <apw> i've not seen a single compix fade out since i've been running 31-* kernels, was normal before with heavy load
[13:41] <james_w> I thought I was seeing a little improvement with .31, but the -2.16 seems to be a lot better again
[15:45] <apw> smb, whatever happened to your mmc patch?
[15:45] <smb> Pierre thinks there might be a better solution and wanted to investigate that
[15:46] <apw> any sign of the better soln?
[15:46] <smb> But I have not heard of something better
[15:46] <smb> No
[15:47] <apw> maybe worth a poke as we are carrying your patch
[15:47] <smb> You certainly can change the block layer to carry additional references
[15:47] <smb> I did poke (not sure how long ago) to get the answer above
[15:48] <apw> ok good enough then
[15:48] <apw> the worry is if its a differnt soln. we may get it without a collission with yours and carry both
[15:49] <smb> apw, Found it, the answer is from first of Jul
[15:49] <apw> so pretty recent then
[15:49] <smb> right. His answer was "I plan to have a closer look at this first. I believe your solution is
[15:49] <smb> a workaround and doesn't solve the real issue. As such, I want to have
[15:49] <smb> one more go at finding and fixing the real problem before committing
[15:49] <smb> this. Your analysis should help a lot in that effort.
[15:49] <smb> "
[16:25] <apw> cking_, i am pushing your first bisect kernel now, should be about 15 mins
[16:26] <cking_> cheers!
[16:31] <apw> cking_, http://people.ubuntu.com/~apw/cpu-bisect/
[16:57] <cking_> apw.. nearly tested
[16:57] <apw> nearly?
[16:57] <cking_> yeah.. double checking to be sure
[16:57] <apw> positive or negative?
[16:58] <cking_> I will let ya know in a jiffy
[17:00] <cking_> first time the hibernate screwed up
[17:04] <cking_> hrm and 2nd time around hibernate gets loads of I/O errors...
[17:04] <apw> bah so hibernate may not work at all
[17:05] <cking_> looks hosed to me
[17:05] <apw> will make a bisect tricky
[17:06] <cking_> let ,me do one more test
[17:07] <apw> is it an amd?
[17:18] <cking_> Nope, Intel 
[17:21]  * cking_ wastes time fsck'ing disc after screwed up hibernate :-(
[17:23] <cking_> this is annoying. some times it works, some times it does not.
[17:25] <cking_> makes testing more time consuming.
[17:27]  * smb can't stand the tension any longer and leaves for a happy place...
[17:28] <cking_> have a nice beer time smb
[17:28] <smb> cking_, ta :)
[17:30] <apw> cking, any luck?
[17:30] <apw> cking, what is a sonoma processor?  we have an old patch for them in your name
[17:31]  * cking tries to recollect
[17:31] <cking> what's the commit id?
[17:32] <cking> some kind of pentium M I believe
[17:34] <cking> 2nd gen Centrino
[17:34] <cking> apw, http://en.wikipedia.org/wiki/Centrino#Sonoma_platform_.282005.29
[17:35] <apw> odd we are carrying a patch for it
[17:35] <cking> why odd?
[17:37] <mjg59> Is this for cpufreq-centrino?
[17:38] <cking> cpufreq/speedstep-centrino.c
[17:39] <mjg59> Yeah
[17:39] <mjg59> The issue there was that the different Sonoma models need different frequency/voltage tables
[17:39] <mjg59> So you have to get the information from ACPI, but some machines were missing it
[17:39] <mjg59> You could patch it to add one table, but there was no way to know which you should use
[17:46] <cking> The freq/voltage tables can be selected from from the cpu id info, and max cpu setting.
[17:46] <cking> it's not pleasant, put it that way.
[17:48] <cking> s/max cpu/max freq/
[17:49]  * cking suspect apw is working his way through a gazillion patches
[17:50] <apw> cking, its odd cause we are still carrying it so long after
[17:50] <apw> and yeah a lot of reading
[18:01] <cking> hrmph. phase of the moon bug this one.
[18:02] <cking> 2.26.27*18  FAIL, OK, OK
[18:03] <cking> 2.6.27*10 OK, OK
[18:03] <cking> 2.6.27*14, FAIL, OK, OK
[18:03] <cking> 2.6.27*12, OK, OK
[18:04] <cking> apw, ^^ it's not easy to reproduce 100% of the time.
[18:04] <cking> gonna take a break, neck is killing me.
[18:04] <apw> cking, hrmmm ... bottom
[18:05] <cking> Gonna revist this again later when it's cooler and my neck  is under some pain killers
[18:07] <apw> cking, it'll wait
[23:18] <JFo> hi ogasawara 
[23:18] <ogasawara> JFo: hiya, just getting your list of bugs I promised put together
[23:18] <JFo> excellent :)