[00:40] <manjo> cking and manjo in the lobby
[00:40] <manjo> anyone in the hotel?
[00:41] <manjo> pgraner, you in?
[00:42] <pgraner> manjo: yep just got here
[00:43] <manjo> pgraner, cking says hi
[00:43] <manjo> we are in the lobby
[00:43] <pgraner> manjo: k be there in 5
[00:43] <manjo> pgraner, cking making a phone call and will be back in 10
[00:44] <pgraner> manjo: ack see you in 10 then
[00:46] <manjo> ack
[07:36] <dholbach> hola
[07:37] <dholbach> how many people reported already that 2.6.32-20 does not boot any more?
[07:37] <dholbach> I saw it on ubuntu-devel-discuss already but wondered if you'd still need a backtrace or something
[07:38] <RAOF> I haven't seen anyone report that, except the one post on u-d-d.
[07:39] <dholbach> I have the same on my laptop here
[07:39] <dholbach> I guess it dies too quickly to even write an apport log or something
[07:39] <RAOF> What does it actually do?
[07:40] <dholbach> write an oops message and hang there, no magic sysrq
[07:40] <RAOF> Urgh.
[07:40] <dholbach> very very early on
[07:40] <dholbach> damn it
[07:40] <Sarvatt> can you get a picture of it?
[07:40] <dholbach> I don't have my camera here
[07:40] <RAOF> Oh, with no /dev/sda thingy?  THat the one?
[07:41] <dholbach> RAOF: I'd need to check again
[07:41] <RAOF> It oopses with no root filesystem found, though?
[07:41]  * RAOF russtles up the u-d-d post.
[07:42] <dholbach> RAOF: I'll check - hang on
[07:42] <dholbach> brb
[07:47] <Sarvatt> darn, -20 boots fine on all of my machines
[07:52] <RAOF> That's an ominous lack of dholbach.
[07:53] <dholbach> http://people.canonical.com/~dholbach/Bild002.jpg
[07:53] <dholbach> RAOF: ^
[07:55] <RAOF> Hm.  I'm not going to be of much help here.  It'd be nice if the kernel didn't scroll the top of that trace off the screen, though!
[07:55] <Sarvatt> dholbach: looks like https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/561151
[07:55] <ubot3> Malone bug 561151 in linux "reproducible oops at startup on thinkpad x61s in acpi_ex_read_data_from_field" [Undecided,New] 
[07:56] <dholbach> Sarvatt: thanks muchly
[07:56] <dholbach> RAOF: I agree :)
[07:56] <Sarvatt> dholbach: fallout from http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=commit;h=3f80f9e8e30f4759ad0e29d23856126edbfc7b41 :(
[07:58] <dholbach> aha
[07:58] <dholbach> apw: ^ :)
[08:17] <Sarvatt> apw: reverting 6a63b06f3c494cc87eade97f081300bda60acec7 instead might be an option to fix that bug going by the upstream bug report. after reverting 3f80f9e8e30f4759ad0e29d23856126edbfc7b41 it reverts cleanly
[08:18] <dholbach> hey smb
[08:19] <smb> dholbach, Morning
[08:19] <dholbach> did you also have something to do with http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=commit;h=3f80f9e8e30f4759ad0e29d23856126edbfc7b41 (causes bug 561151)
[08:19] <ubot3> Malone bug 561151 in linux "reproducible oops at startup on thinkpad x61s in acpi_ex_read_data_from_field" [Undecided,New] https://launchpad.net/bugs/561151
[08:19] <Sarvatt> dholbach: does a 2.6.34 kernel boot for you?
[08:20] <dholbach> Sarvatt: I didn't try
[08:21] <Sarvatt> http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/2010-04-09-lucid/ -- that fix is upstream so if it doesn't fail the same way it's probably something due to it being backported from .34 to .32..
[08:25] <dholbach> ok
[08:27]  * apw looks at dholbach ... how dare you have issues with my shiney kernel :(
[08:27] <dholbach> I'll try 2.6.34 in a sec
[08:28] <dholbach> brb
[08:29]  * smb waves to apw
[08:29] <apw> o/ smb
[08:29] <RAOF> Aloha apw
[08:30] <apw> yo
[08:30] <jk-> hey .eu-ers
[08:31] <RAOF> Can I haz also a noaccel quirk for geforce 6100 cards? :)
[08:32]  * smb wonders whether we will have 3D in Lucid
[08:32] <RAOF> apw: You whipped up a test kernel for bug #558657 before the weekend, I believe.  Where is it, so I can point the reporter at it?
[08:32] <ubot3> Malone bug 558657 in linux "mouse usage causes Xorg CPU usage to spike, and mouse pointer becomes less responsive" [High,Incomplete] https://launchpad.net/bugs/558657
[08:32] <apw> Sarvatt, got a pointer to the upstream bug for daniels issue?
[08:32] <RAOF> smb: Not in nouveau; we've never planned on having it.
[08:33] <smb> RAOF, Yeah right, that was the one with experimental 3D on xorg-edgers
[08:33] <dholbach> Sarvatt: 2.6.34 boots
[08:33] <apw> RAOF, possibly, i did about 200
[08:33] <smb> RAOF, But probably not for my card anyways. I need to check whether there has been any progress on the phantom connector front. :-P
[08:33] <Sarvatt> apw: no I haven't seen any upstream bugs about it at all which is why I was asking him to try 2.6.34, https://bugzilla.kernel.org/show_bug.cgi?id=14667 is the bug I was looking at though
[08:34] <RAOF> smb: Right.  Sadly, nouveau's version of “experimental” seems to be pretty much superior in every way to intel's version of “fully supported i845 chipset” :(
[08:34] <ubot3> bugzilla.kernel.org bug 14667 in EC "bisected 2.6.32 EC regression - Temperatures not correctly detected after suspend" [Normal,Resolved: patch_already_available] 
[08:34] <apw> <Sarvatt> apw: reverting 6a63b06f3c494cc87eade97f081300bda60acec7 instead might be an option to fix that bug going by the upstream bug report. after reverting 3f80f9e8e30f4759ad0e29d23856126edbfc7b41 it reverts cleanly
[08:34] <apw> so what does upstream bug report refer in that context
[08:35] <Sarvatt> the bug I linked just now bisected it down to the regression starting from 6a63b06f3c494cc87eade97f081300bda60acec7
[08:36] <Sarvatt> (which is the latest commit to drivers/acpi/ec.c in lucid outside of the fix)
[08:37] <apw> RAOF, seems i built and pushed them and forgot the bug update ... now in the bug
[08:38] <RAOF> apw: Thanks.
[08:38] <apw> Sarvatt, its a shame that one is a pre-req of the EC multi-byte fix which fixed a whole bunch of peoples overheating
[08:39] <apw> dholbach, so a recent mainline worked ok for you ... on your x61
[08:39] <dholbach> apw: yes, x61s, like in the bug report
[08:42] <Sarvatt> the EC multi byte fix was needed *because* of ACPI: EC: use BURST mode only for MSI notebooks though
[08:44] <Sarvatt> at least thats what it sounds like from the report, it unconditionally disabled ec burst mode unless there was a MSI dmi match.. anyway I'm not sure thats even the issue, just what I noticed at a glance
[08:44] <apw> Sarvatt, ahh i seem what you mean
[09:20] <apw> dholbach, you on 32 or 64 bit?
[09:35] <dholbach> apw: 32
[10:05] <Laibsch> what is the proper way to fix bug 535132?  One way to deal with this would be for the newer package to conflict on the older, but I'm not sure that is the best way to do this.  I'm thinking about moving /lib/udev/compat_firmware.sh into a separate package.  Opinions?
[10:05] <ubot3> Malone bug 535132 in linux-backports-modules-2.6.32 "package linux-backports-modules-wireless-2.6.32-16-generic-pae 2.6.32-16.6 failed to install/upgrade: trying to overwrite '/lib/udev/compat_firmware.sh', which is also in package linux-backports-modules-wireless-2.6.32-16-generic 0:2.6.32-16.7" [Medium,Triaged] https://launchpad.net/bugs/535132
[10:40] <mdz> I'm having a terrible time using b43 to associate a Broadcom 4306 (core rev 5) with my home AP. it fails to scan most of the time, and when it does see the AP, it usually fails to associate (WPA or insecure). rebooting the AP, oddly, seems to have helped, and now I can associate insecurely, but it's unusably slow
[10:40] <mdz> any tips?
[10:42] <smb> mdz, Usually my best tip is not use b43 but the binary driver (wl)
[10:42] <apw> mdz in my experience b43 has not been a good driver for those, i have used wl for all my broadcom based systems
[10:42] <mdz> this is a powerpc system, so I think that's not an option for me
[10:42] <apw> ahhh
[10:42] <smb> Thats bad
[10:43] <smb> Not sure lbm is better atm
[10:43] <mdz> so my other options are buying a USB dongle, or using Mac OS X
[10:43] <mdz> I am going to try with macos to see if I can rule out a hardware problem or incompatibility with the AP
[10:44] <apw> i would suggest we try lbm as well, that has a newer stack i believe
[10:44] <apw> lbm-wireless
[10:44] <smb> I think around 2.6.33
[10:44] <mdz> apw, I don't think there is one for ppc
[10:44] <apw> oh hrm
[10:45] <mdz> I could build compat-wireless from source easily enough, presumably
[10:45] <apw> mdz yeah was just wondering why its only x86 these days
[10:46] <smb> Yeah, either just never tried or it had issues in the past
[10:46] <smb> But have not tried it lately
[10:46] <apw> likely cause of the ports/not-ports split
[10:48] <mdz> any recommendations for a USB dongle if I go that way?
[10:53] <jk-> mdz: which machine is this?
[10:53] <mdz> jk-, it's an iBook G4 with an Airport Extreme
[10:54]  * jk- thinks back to powerbook days
[10:54] <mdz> I'm told the slot is electrically miniPCI, but the form factor is incompatible for the usual Apple reasons
[10:55] <mdz> so the card is in theory replaceable, but I don't think anything else fits
[10:55] <jk-> hooray apple :(
[10:55] <jk-> is this a recent change after upgrading, or the first you've tried on this machine?
[10:56] <mdz> jk-, first try
[10:56] <mdz> though I was encouraged to hear that others had success with this hardware, e.g. http://shellack.de/info/content/ibook-g4-running-ubuntu-karmic-koala
[10:57] <jk-> mdz: ISTR that b43 tended to have problems when the firmware version was out of sync with what the kernel expected
[10:58] <jk-> but that was a while ago..
[10:58] <jk-> i've gotta scoot, but benh and johill on #mklinux may be able to help
[10:59] <mdz> jk-, the firmware is all versioned, and the driver is getting what it asked for
[10:59] <mdz> jk-, thanks
[11:10] <amitk> apw: I've got another enforce to add to omap and just got me thinking how to make sure these are available to all branches
[11:10] <apw> amitk, well if its applicable to all branches it should be on master
[11:10] <apw> of course you arn't based on any of our masters so its not so easy
[11:12] <amitk> apw: I wonder if it makes sense to separate out debian/ into its own branch, then every 'branch' would only contain the local debian.foo dir
[11:13] <apw> well then you would have to have git to make a buildable directory
[11:13] <amitk> -ENOPARSE
[11:13] <amitk> me would merge the 'debian' branch at build-time
[11:13] <amitk> *we
[11:17] <amitk> apw: ^
[11:18] <apw> amitk, or check it out perhaps yes ... the problem is you might want different ones for differnet releases, or not
[11:18] <apw> i think it is a sensible goal to be honest, and one i would think deserves thinking on for sure
[11:18] <apw> i was going to do some sync up between releeases after L is off my plate, so that would be a good time
[11:19] <apw> we should put it on the agenda for our release sprint too, ie. in beer time
[11:19] <amitk> apw: release sprint agenda?
[11:19] <amitk> heh, ok
[11:19] <apw> yeah ... i've added it to my paper list
[11:19] <ogra> shudder ... paper
[13:14] <apw> dholbach, about?  want to try a test kernel for your boot issue?  as mainline works I am trying to eliminate some ubuntu changes in the area
[13:19] <apw> dholbach, kernels will be here shortly: http://people.canonical.com/~apw/lp561151-lucid/
[13:46]  * apw waits for his t30 to update
[13:55] <smb> apw, I just sent out another work-around patch you might want to consider (or not). I really only covers a WARN_ON by removing it. And its there only to prevent incompatible (e.g. with ARM) development. But for that reason never goes upstream that way. And the proper fix needs a bit more time that we have
[13:57] <apw> smb, thanks ... i'll look it over
[13:57] <apw> once i've shovelled all these thinkpads into a skip
[13:58] <smb> apw, How many do you have?
[13:59] <apw> all of them i think
[14:00] <smb> apw, Hm, probably I am not parsing "shoveling ... thinkpads into a skip" correctly
[14:00] <apw> that EC change seems to have made them _all_ break
[14:03] <smb> apw, Sounds like joy. And you mentioned that upstream kernels are ok, right?
[14:04] <apw> yep ... and they have the same patches ... so ... can't happen... *bang*
[14:04] <mdz> apw, Jane has just told me about the issue you're working
[14:05] <apw> mdz, hi
[14:05] <mdz> apw, can we get on the phone for 3 minutes to assess the situation?
[14:05] <apw> mdz sure
[14:07] <dholbach> apw: will test in a sec
[14:07] <apw> dholbach, i suspect it will crash too
[14:09] <dholbach> apw: I'll let you know
[14:15] <mdz> apw, I've got a sysadmin on standby to do the magic, as soon as I have the version number(s)
[14:17] <mdz> is it this change here?
[14:17] <mdz> * (pre-stable) ACPI: EC: Allow multibyte access to EC
[14:17] <mdz>     - LP: #526354
[14:17] <apw> mdz:
[14:17] <apw> linux-image-2.6.32-20-generic_2.6.32-20.29_amd64.deb (29.5 MiB)
[14:17] <apw> linux-image-2.6.32-20-preempt_2.6.32-20.29_amd64.deb (29.9 MiB)
[14:17] <apw> linux-image-2.6.32-20-server_2.6.32-20.29_amd64.deb (29.5 MiB)
[14:17] <apw> linux-image-2.6.32-20-386_2.6.32-20.29_i386.deb (29.5 MiB)
[14:17] <apw> linux-image-2.6.32-20-generic_2.6.32-20.29_i386.deb (29.5 MiB)
[14:17] <apw> linux-image-2.6.32-20-generic-pae_2.6.32-20.29_i386.deb (29.6 MiB)
[14:17] <apw> mdz that is the one we believe it is yes, will confirm shortly
[14:17] <mdz> apw, and it's lucid only, correct?
[14:18] <apw> mdz that is correct lucid only
[14:19] <apw> mdz thanks 
[14:25] <apw> bug #561462
[14:25] <ubot3> Malone bug 561462 in linux "MacBook 4,1 starts up with 2.6.32.19 but not 2.6.32.20" [Undecided,New] https://launchpad.net/bugs/561462
[14:26] <dholbach> apw: fails too, let me upload the picture
[14:26] <apw> dholbach, yeah ironically that is good ... as its therefore not the changes we made internally to the code there
[14:26] <apw> i assume its the same type of hand
[14:27] <apw> hang
[14:28] <dholbach> apw: new crash: http://people.canonical.com/~dholbach/IMG_6807.JPG
[14:29] <dholbach> apw: this is the old one: http://launchpadlibrarian.net/43892737/Bild002.jpg
[14:29] <apw> dholbach, ok thats good, same type of crash ... not ubuntu code changes ... revert is building and i'll have that tested shortly (/me has found a laptop behind the TV which exhibits the issue
[14:30] <dholbach> awesome
[14:30] <dholbach> although it will mean that we have to reopen the other bug again?
[14:30] <apw> amazing where laptops hide out these days
[14:30] <apw> yep, but at least they booted, even if they overheat
[14:31]  * apw also has one of those ... how lucky am i
[14:31] <dholbach> :)
[14:31]  * dholbach hugs apw
[14:32] <apw> dholbach, thanks ... /me kicks his build box ... faster damn you
[14:32] <dholbach> let me know if there's anything I can do
[14:32] <apw> will do ... ta
[14:33] <smb> apw, So mysteriously upstream kernels work and ours doesn't even as our specific change does not make a difference?
[14:33] <apw> smb, that is the non-sensible current facts yes
[14:34] <apw> i am waiting on both the revert to test, and a mainline build of .32.11 to complete for comparitive testing
[14:34] <apw> i am assuming if the revert is 'good' on thinkpads we'll upload that and expedite it out
[14:34] <apw> and then try and work out how on earth that change can work upstream later
[14:35] <smb> apw, sounds quite reasonable for this time
[14:36] <smb> apw, I am upgrading the external installation of my thinkpad too
[14:36] <apw> smb, thanks if you could confirm it kills your TP as well that would be helpful
[14:36] <apw> smb, unless its a T30 when i know it does :/
[14:36] <smb> apw, That was my line of thinking. No, its a T42p
[14:37] <apw> smb, cool
[14:40] <JFo> Bug 561140
[14:40] <ubot3> Malone bug 561140 in linux "Boot hangs after update to kernel 2.6.32-20" [Undecided,Confirmed] https://launchpad.net/bugs/561140
[14:41] <mdz> apw, should ^^ be the master bug for this issue, or is there a better one?
[14:41] <apw> bug #561151 is the one i was first made aware of
[14:41] <ubot3> Malone bug 561151 in linux "reproducible oops at startup on thinkpad x61s in acpi_ex_read_data_from_field" [High,In progress] https://launchpad.net/bugs/561151
[14:42] <apw> that at least has the accurate panic information recorded in the title et al
[14:42] <JFo> good call
[14:42] <apw> mdz ^^
[14:43] <mdz> apw, OK to set 561140 and all dupes as duplicates of 561151?
[14:44] <JFo> I can do that if you like.
[14:44]  * JFo begins gathering the duplicates to look over
[14:45] <apw> mdz JFo i think the first one mentioned is a duplicate in the main
[14:46] <apw> though there are as always some bad sharers i think, but yes i think consolidating on that one is good
[14:46] <mdz> OK
[14:46] <JFo> got it
[14:46] <apw> i'll put something in it so they have some information
[14:46] <JFo> apw, cool
[14:46] <mdz> JFo, I had the command line all cued up, running it now
[14:46] <mdz> done
[14:46] <JFo> mdz, excellent :)
[14:46] <mdz> 561151 is the master now
[15:12] <apw> dholbach, its looking like this EC change is the culprit, could you test this kernel and confirm its good for you: lp561151-lucid/linux-image-2.6.32-20-generic_2.6.32-20.30~lp561151v201004121418_i386.deb (should be there in 2 minutes)
[15:13] <dholbach> rock on
[15:14] <apw> dholbach, ok its complete ... should be there to download
[15:18] <dholbach> apw: rebooting
[15:19] <mdz> apw, robbiew is relieving me wrt this issue
[15:20] <apw> mdz, ack
[15:21] <dholbach> apw: 
[15:21] <dholbach> daniel@miyazaki:~$ uname -a
[15:21] <dholbach> Linux miyazaki 2.6.32-20-generic #30~lp561151v201004121418 SMP Mon Apr 12 13:19:07 UTC 2010 i686 GNU/Linux
[15:21] <dholbach> daniel@miyazaki:~$ 
[15:21] <apw> dholbach, thanks ... i think we can call that 'good'
[15:21] <dholbach> yeah :)
[15:22] <dholbach> mdz: ^ (test kernel with fix seems good :))
[15:32] <mdz> robbiew, ^^
[15:32] <mdz> apw, does that give you enough data for an ETR?
[15:32] <robbiew> mdz: ack
[15:34] <apw> mdz ETR ?
[15:34] <mdz> apw, sorry, estimated time for repair
[15:34] <mdz> how long before the fix
[15:35] <apw> robbiew, mdz, i have three reliable confirmations that a single patch revert will resolve the thinkpad issues
[15:35] <apw> i would propose uploading just that single change now, wh
[15:35] <robbiew> apw: but will the Dell issues occur?
[15:35] <apw> which should see updated binaries in the archive in about 4 hours
[15:35] <apw> robbiew, yes we will regain the dell issues, but they do at least boot
[15:36] <robbiew> ok
[15:36] <apw> i will continue to examine the combination to understand why upstream works on TP with that fix
[15:36] <apw> as that indicates we should be able to make a working combination for both
[15:36] <robbiew> apw: ack
[15:37] <robbiew> thanks apw
[15:37] <JFo> bug 561532
[15:37] <ubot3> Malone bug 561532 in linux "MacBook Pro 5,1 fails to boot with 2.6.32.20" [Undecided,New] https://launchpad.net/bugs/561532
[15:38] <apw> JFo, i am unsure if that one is a correct duplicate at this instant
[15:38] <JFo> same here
[15:38] <apw> will confirm with bac whether the kernel fixes him.  suspect not
[15:38] <JFo> ok
[15:44] <robbiew> apw: what is the bug number for the Dell issue
[15:45] <apw> http://bugs.launchpad.net/bugs/526354
[15:45] <ubot3> Malone bug 526354 in linux "[Dell Studio 1537] temperature sensors and fan stop working following suspend/resume" [High,Fix released] 
[15:45] <robbiew> thnx
[15:45] <apw> this actually seems to affect m1330 and a number of other dell systems to varying degrees of severity
[15:48] <JFo> bug 561431
[15:48] <ubot3> Malone bug 561431 in linux "OOPS during boot with linux-image-2.6.32-20-generic-pae" [Undecided,New] https://launchpad.net/bugs/561431
[15:48] <JFo> think that ^ is a dup
[15:48]  * JFo reads some more
[15:49] <JFo> yep, it is thinkpad as well
[15:50] <JFo> marked appropriately
[15:50] <apw> jfo yeah looks like it
[15:50] <JFo> cool
[15:50]  * apw tries a 2.6.32.11 kernel to see if that boots ok
[15:53] <smb> apw, confirmed that the t42p also crashes on boot, though it would need to find out how to make the font smaller to see what the messages are
[15:53] <apw> smb, near the bottom you should have EIP still
[15:53] <apw> whats that
[15:53] <smb> apw, No it moves on for quite a while after it and does not allow to move up again
[15:54] <apw> smb, ok ... does this kernel fix you
[15:54] <apw> http://people.canonical.com/~apw/lp561151-lucid/linux-image-2.6.32-20-generic_2.6.32-20.30~lp561151v201004121418_i386.deb
[15:58] <smb> apw, while I am installing. Have you checked whether thinkpad-acpi received anything we do not have, yet after the multibyte-ec patch?
[15:58] <apw> smb, also could you look over the tip of master for any 'rushing too fast' thinkos
[15:58] <apw> smb, not as yet
[16:01] <apw> smb, skype?
[16:01] <JFo> bug 561151
[16:01] <ubot3> Malone bug 561151 in linux "2.6.32.30 reproducible oops at startup in acpi_ex_read_data_from_field" [High,In progress] https://launchpad.net/bugs/561151
[16:01] <JFo> I'm asking for more details
[16:01] <JFo>  /logging
[16:01] <apw> yep thats the one we are working on?
[16:01] <apw> i don't think we need anything more
[16:01] <JFo> grrr, wrong bug #
[16:01] <JFo> bug 561497
[16:01] <ubot3> Malone bug 561497 in linux "With new Linux Kernel linux-image-2.6.32-20-generic system does not boot  " [Undecided,New] https://launchpad.net/bugs/561497
[16:01] <JFo> there we go
[16:01] <smb> apw, sure, just need to use the hands-in-the-air machine
[16:02] <apw> smb, hehe
[16:03] <smb> apw, ok, the test kernel boots
[16:04] <JFo> apw, what do we mean when we say "The EC change" what does EC mean in that context?
[16:05]  * JFo just trying to understand the bug
[16:05]  * JFo guessed Error Correction 
[16:05] <smb> JFo, embedded controller
[16:06] <JFo> ah hah!
[16:06] <JFo> thanks smb 
[16:18] <apw> JFo, most x86 systems have a little embedded controller scanning the power buttons and the like, and its 'on the other side' of acpi normally
[16:19] <JFo> I see
[16:20] <JFo> ah, excellent
[16:20] <JFo> Launchpad is read only
[16:31] <apw> jfo u jest
[16:31] <JFo> nope
[16:31] <apw> how can they keep doing that right before milestones
[16:31] <JFo> no idea
[16:31] <JFo> but it is back out of read only
[16:32] <JFo> naturally they only put it read only when I am doing something
[16:32] <JFo> :-/
[16:39] <BenC> Note to self, latitude d420's don't use normal sized hd's so get a spare :-/
[17:10] <robbiew> cjwatson: I wonder if we should enable the grub menu be default during development (alpha and beta), and then disable in the RC.  Probably would have helped people boot into older kernels a lot easier.  
[17:10] <robbiew> apw: any thoughts? ^^
[17:11] <apw> robbiew, an interesting idea... 
[17:11] <apw> though we have more people after release who are likely to be unable to cope than before
[17:11] <robbiew> true
[17:12] <robbiew> I know there was some sort of "magic" cjwatson put in that caused grub to boot to the menu if the first boot failed...however I guess in this instance, the boot "succeeded", but the kernel failed :/
[17:13] <robbiew> I dunno...we are in beta, so...there has to be some tolerance for issues like this
[17:13] <robbiew> imo
[17:14] <apw> yeah its not obvious it was trivial to avoid
[17:14] <apw> perhaps we need to better document 'useful things to do if your beta breaks'
[17:14] <apw> which could include 'hold shift'
[17:16] <robbiew> heh...good point
[17:17] <persia> GIven the number of folk who didn't get hit by this (and similarly wouldn't get hit by any given kernel issue), it may make sense to push that documentation for RC even.
[17:17] <Laibsch> I've successfully recompiled a -generic kernel from Ubuntu git.  Now I want to add a patch for one of the modules and recompile without restarting from scratch.  Is that possible?
[17:17] <Laibsch> make clean in the respective directory does not work
[18:07] <JFo> apw, bac says that your kernel fixed him
[18:13] <apw> jfo, yeah i think it can be explained though unexpected ... the async thread would die ...and not do the other tasks assigned
[18:13] <JFo> well I am glad that helped get further to the cause
[18:13] <JFo> I still have no idea what is happening :-)
[18:15] <JFo> well, I can't say that. I have an idea, but some things are still new enough that I don't fully understand
[18:29] <apw> ogasawara, about?  whats what with that raid thing bug #557429
[18:29] <ubot3> Malone bug 557429 in mdadm "booting out of sync RAID1 array fails with ext3 (comes up as already in sync)" [High,Triaged] https://launchpad.net/bugs/557429
[18:30] <ogasawara> apw: it's still seeing discussion upstream and it seems by looking at the bug report, not all are in favor of the potential fix
[18:30] <ogasawara> apw: I'm skeptical that i'll get resolved by final release
[18:30] <apw> ogasawara, did it end up being userspace in fact?
[18:30] <ogasawara> apw: yes, appears so
[18:30] <apw> well thats something
[19:53] <apw> akgraner, you about?
[19:53] <akgraner> apw, I am - what's up?
[19:54] <apw> just a heads up that the dell fix for our fans had to be backed out
[19:54] <apw> i think i have it fixed so it doesn't eat all thinkpads now, and will have a
[19:54] <apw> test kernel later i hope for testing ... as you were affected i'd like you to test it 
[19:54] <akgraner> yeppers
[19:55] <akgraner> just let me know when and I will help ya out he best I can :-)
[19:55] <akgraner> s/he/the
[20:03] <apw> akgraner, thanks ... will be around an hour i'd guess
[20:05] <akgraner> apw after 4:30 EDT I have to run the kids to practice and all that - so If I don't get to test with you today can we try it 1st thing in the morning your time?
[20:05] <apw> akgraner, what time is it now?
[20:06] <akgraner> 3:06PM EDT :-)
[20:06] <apw> ahh there it is on my menu ... hiding in plain sight
[20:06] <akgraner> hehe
[20:06] <apw> yep ... no problem if you arn't there you arn't there, and i can't whip the horses any harder than i am
[22:19] <apw> akgraner, if and when you get to look at the test kernel its here: people.canonical.com/~apw/lp526354-lucid/ ... let me know
[22:43] <akgraner> apw, thanks!  I'll let ya know :-) shortly :-)  do you want an email or do you want me to reply here?
[23:00] <Nader> will there be any chance of including ATA TRIM in .32? whats the situation