[08:34]  * smb Rebooting
[08:38] <ppisati> pulseaudio refuses to collaborate this morning
[08:38] <ppisati> or maybe is mumble
[08:42]  * smb hates these "experienced and internal problem" messages. So not saying anything
[08:42] <ppisati> uh
[08:42] <ppisati> and i hatre my usb mic not working
[08:42] <smb> ppisati, Do you have levels in the sound indicator?
[08:43] <ppisati> smb: levels?
[08:43] <smb> ppisati, Some movement on the level-meter
[08:44] <smb> if you go to input and your mic
[08:44] <ppisati> if i raise the sensitivity, yes
[08:44] <ppisati> it's alive
[08:45] <smb> Ok, so its either tuned too low or mumble needs the restart, killpulse, twidle setting dance we all love so much
[08:47] <ppisati> cool
[08:47] <ppisati> just killed pulseaudio
[08:47] <ppisati> and now i've lost sound for every app
[08:47] <ppisati> and i can't even close skype
[08:47] <ppisati> it's stuck in a limbo
[08:48] <smb> ppisati, sounds like another reboot another lucky draw
[09:35]  * ppisati -> back in 10mins
[10:47]  * ppisati scratches his head
[10:50] <ppisati> perf is part of linux-base and linux-tools-common
[11:08] <Daviey> smb: Hey, are you around?
[11:10] <Daviey> smb: I'd like to raise bug 898127 as crucial, it seems to be present just by showing extreme IO.
[11:10] <ubot2`> Launchpad bug 898127 in linux "system hangs and errors at /build/buildd/linux-3.2.0/arch/x86/kernel/apic/ipi.c:113 default_send_IPI_mask_logical+0xdc/0xf0()" [Medium,Confirmed] https://launchpad.net/bugs/898127
[11:10] <Daviey> I believe it's that bug anyway...
[11:10] <Daviey> I believe i can get you access to hardware where you can see it.
[11:10] <apw> Daviey, i think you just missed him popping to lunch
[11:10] <Daviey> apw: Oh :(
[11:13] <apw> ppisati, yeah linux-base is on my todo for today to sort that out, its a debian sync
[11:15] <ppisati> apw: well, actually there's even a skew between kernel version and perf version
[11:15] <ppisati> apw: dunno if it's the same
[11:16] <ppisati> apw: http://paste.ubuntu.com/890466/\
[11:16] <ppisati> and 'perf top' shows nothing
[11:17] <apw> ppisati, where did you get your 1409 build ?
[11:17] <ppisati> apw: ti-omap4, latest kernel
[11:17] <apw> built where
[11:17] <ppisati> got it from dist-upgrade
[11:17] <apw> armel or hf ?
[11:17] <ppisati> armhf
[11:19] <apw> dpkg -S /usr/bin/perf says what
[11:19] <ppisati> linux-tools-common
[11:19] <ppisati> flag@panda:~$ dpkg -S /usr/bin/perf
[11:19] <ppisati> linux-tools-common: /usr/bin/perf
[11:19] <apw> ppisati, try installing linux-tools instead
[11:19] <ppisati> it's there iirc
[11:19] <apw> linux-ti-omap4-tools-3.2.0-1409
[11:20] <ppisati> ah
[11:20] <ppisati> uhm
[11:20] <apw> is the binary package, but i'd expect the linux-tools to bring it in
[11:20] <ppisati> nope
[11:20] <ppisati> linux-tools brought in linux-tools-3.2.0-19
[11:20] <ppisati> let me double check
[11:20] <apw> oh hmmm ... yeah
[11:20] <apw> maybe there isn't a linux-tools for ti-omap4
[11:20] <apw> it would have to have a different name anyhow
[11:20] <ppisati> k
[11:21]  * ppisati goes researching the solution
[11:21] <apw> actually isn't there a linux-tools-omap4 or something
[11:21] <apw> i remmber us having to have a differnet name, and realising we should have had a flavour specific tools name even though it would have been a noop on x86
[11:21] <apw> as if you have multiple source packages the linux-tools have to differ in name
[11:21] <ppisati> so, linux-tools tries to install linux-tools-3.2.0-19
[11:22] <apw> yep, thats x86 or 'from master' speciific
[11:22] <ppisati> ah
[11:22] <ppisati> linux-tools-omap4
[11:22] <apw> is there a linux-tools-omap4, thats the right one
[11:22] <apw> and there is a 'bug' that we don't have linux-tools-generic etc to match it
[11:22] <ppisati> anyway, linux-tools-omap4 imported the right one: linux-ti-omap4-tools-3.2.0-1409
[11:23] <apw> ok good... will add to my todo to look at that
[11:23] <ppisati> but perf still doesn't work
[11:23] <ppisati> nice
[11:23] <ppisati> i've a new toy
[11:23] <ppisati> thanks
[11:23] <apw> heh whats it do
[11:23] <ppisati> nothing
[11:23] <ppisati> PerfTop:       0 irqs/sec  kernel:-nan%  exact:  nan% [1000Hz cycles],  (all, 2 CPUs)
[11:23] <ppisati> mute
[11:23] <ppisati> silent
[11:24] <apw> hrm, thats a worry, config perhaps ?
[11:24] <ppisati> probably
[11:24] <ppisati> i'm over it
[11:35]  * ppisati -> out for lunch
[12:20] <apw> smb, i've talked to Daviey about his issue, its actually a different bug
[12:52] <smb> apw, Hm, a different bug than what? (/me back now)
[12:52] <apw> the one daivy was making you look at
[12:54] <Daviey> Yes, sorry - i suck.
[12:54] <smb> Ah ok, so anything I still should look at or are we waiting for him to file information
[12:55] <gema> hi guys, couldn't find this in the normal debug symbols apt source: linux-image-3.2.0-17-generic-dbgsym , could someone help there? 
[12:56] <apw> gema, may have expired as that is an old kernel
[12:56]  * smb wonders whether the bug he was referring to is offlining cpus as of poewnap
[12:56] <gema> apw: it is the beta1 kernel
[12:56] <apw> yes that was the one he was referring to, but the machine is ooming
[12:56] <smb> otherwise ddebs.archive.ubuntu.com I think
[12:56] <apw> gema, yep but we have -19 in the archive now
[12:57] <apw> so if -17 was >14 days ago then it may have gone
[12:57] <smb> apw, or was it just ddebs.ubuntu.com
[12:57] <smb> Its a pita that any variation exists but some are not good
[12:58] <gema> apw: so you recommend updating ? the problem appeared when rebooting after an alternate install on a production machine, we cannot really afford to reinstall to reproduce.. :/
[12:59] <apw> i'd not recommend running a production box on beta1 thats for sure, we're nearly a month on from there
[12:59] <gema> apw: I know, I convinced my other half to use beta 1 for his purposes, because it does what he needs, and we bumped on 3 defects during the install/reboot
[13:00] <gema> apw: so we are trying to raise the kernel one, but without the symbols we only have a picture of the crash
[13:00] <apw> gema, so if you can let me see the picture i might recognise it
[13:00] <apw> not sure i would ever install an old snap of precise tho. given we make CD daily
[13:01] <gema> apw: our daily images are not half as tested as beta 1
[13:01] <gema> apw: take my word on that one
[13:01] <apw> i was under the impression our testing was daily and automated, but hey
[13:01] <apw> but as all the machines i care about are running the crap in the archive right now, and seem good, that'd be my recommendation if you are using P
[13:02] <apw> otherwise i'd say O or L was a better plan
[13:02] <gema> apw: ack
[13:03] <gema> apw: there is a lot of manual and varied community hw testing that happens during Beta
[13:03] <gema> that doesn't happen daily
[13:03] <gema> nor automated
[13:03] <gema> we are on a road there, but not there yet
[13:04] <gema> apw: sent you that email
[13:06] <apw> gema, so this is an EFI machine ?
[13:06] <gema> aye
[13:08] <gema> apw: fwiw, grub was screwed when we tried to reboot, that's another of the problems
[13:08] <smb> apw, we can hear you
[13:20] <apw> gema, ok this is looking like an EFI triggered bug, is this machine an EFI bios?
[13:20] <apw> if it is we might not expect L to work either on it, but O probabally can, we think
[13:21] <gema> apw: it is an EFI but it emulates the normal bios behaviour
[13:21] <gema> apw: the machine is quite happy after that reboot 
[13:21] <apw> hmmm for those efi routines to be being used, that implies its in EFI mode i think ... cking <<
[13:21] <cking> yep definitely in EFI
[13:21] <gema> apw: by L you mean P ? 
[13:23] <apw> gema, no i mean L, if tis an EFI mode bios then it probabally won't run L in native EFI mode
[13:23] <apw> and i suspect its in that mode from the panic
[13:24] <gema> apw: not sure what the kernel was using at that particular moment, but the normal bios behaviour was there too, as the machine runs DragonFly with no problems, and that wouldn't happen if it was in EFI mode
[13:25] <mjg59> Most EFI systems will EFI boot if the media supports it, and fall back to BIOS automatically if it doesn't
[13:25] <mjg59> The Ubuntu install media includes EFI support
[13:26] <mjg59> So if you tried to boot Dragonfly it'd fall back to BIOS, but if you tried to boot Ubuntu it'd be in EFI
[13:26] <gema> mjg59: ack, understood
[13:28] <cking> gema, efI_pstore_write() is failing for you - but w/o seeing the top of the oops it's impossible to say way efi_call5() fails
[13:29] <gema> cking: ack, alex is willing to debug it if he finds / can get the debug symbols
[13:30] <cking> gema, yep, with a bug filed please 
[13:30] <gema> cking: not a problem, can you get us the symbols for beta1 kernel?
[13:33] <cking> gema, I will build you one
[13:33] <gema> cking: thanks a million
[13:39] <tgardner> cking, can you change to tangerine? gomeisa is getting relocated.
[13:39] <cking> tgardner, ack
[13:40] <tgardner> ogasawara, gomeisa will be down for a bit for relocation
[13:41] <ogasawara> tgardner: ack
[13:41] <ogasawara> tgardner: where's it relocating to?
[13:41] <tgardner> ogasawara, new rack and network switch (I think)
[13:41] <tgardner> tangerine will follow in a bit
[13:43] <gema> cking: tracking this problem on Bug #959286 
[13:43] <ubot2`> Launchpad bug 959286 in linux "EFI related kernel panic on reboot from alternate installer " [Undecided,New] https://launchpad.net/bugs/959286
[13:45] <gema> cking: bwalex will be adding his findings there
[13:48] <cking> gema, thanks
[14:30] <apw> cking, how long will your build be ... on tang
[14:31] <cking> apw, which one, I'm futzing around doing several
[14:31] <apw> cking, how long will you be using tangerine, we want to take ti down for its move, gome is back
[14:33] <cking> I'll log off now
[14:33] <cking> done
[14:34] <smb> apw, 
[14:34] <smb> apw, I am using tangerine right now, too
[14:35] <cking> apw, how long will it be offline for?
[14:35] <apw> cking, about as long as gomeisa i assume, 10s of minutes
[14:35] <apw> smb, how long :)
[14:36] <smb> apw, till now
[14:36] <smb> :)
[14:36]  * smb got his kernels off
[14:36] <apw> everyone happy ?
[14:36] <apw> smb, cking, got waht you need off her
[14:36] <cking> apw, I was going to pull off a .ddeb, so it's going to take an insane length of time, so just go ahead
[14:37] <smb> apw, I am good
[14:37] <apw> cking, it is
[14:37] <apw> cking, remember you can scp it to zinc
[14:38] <tgardner> cking, or even gomeisa
[14:39]  * ogasawara back in 20
[14:39] <cking> ok - done
[14:50] <henrix> diwic, Sarvatt: ping
[14:50] <diwic> henrix, hi
[14:50] <henrix> diwic: hi! would you be able to help me with bug #956479 ?
[14:51] <ubot2`> Launchpad bug 956479 in linux "no analog audio output after HDMI display standby with kernel 3.0.0-17.30" [Medium,Confirmed] https://launchpad.net/bugs/956479
[14:51] <henrix> diwic: it looks like a regression
[14:51] <henrix> diwic: could you please take a look at it, before i ping lkml (and others)?
[14:53] <diwic> henrix, so the issue is just that hdmi becomes auto-selected when it previously wasn't, not that anything stops working permanently?
[14:53] <mdeslaur> cking: are you aware of bug 952556? could it be related to the power savings work you've done?
[14:53] <ubot2`> Launchpad bug 952556 in ubuntu-meta "[Precise] [Hardware-killer] HD restarts every few seconds" [High,Confirmed] https://launchpad.net/bugs/952556
[14:54] <cking> mdeslaur, lemme look
[14:54] <henrix> diwic: yes, that was my understanding. everything seems to work fine
[14:54] <mdeslaur> cking: could you hand that off to someone appropriate if you're not the right person...the bug does look important
[14:54] <henrix> diwic: i reverted one of the patches that came from stable, and the problem seems to be solved
[14:55] <diwic> henrix, so the issue is probably that from the audio driver, it looks like the monitor was unplugged and replugged
[14:55] <diwic> henrix, and in fact, today I'm working on not switching to HDMI for 12.04
[14:56] <henrix> diwic: ok, so you believe the issue is at the audio driver
[14:57] <diwic> henrix, so it should hopefully be resolved for 12.04. Anyway, to confirm this theory, you can try commenting out "load-module module-switch-on-port-available" in /etc/pulse/default.pa
[14:57] <diwic> henrix, naah, it's probably in the video driver, it shouldn't tell us the monitor is not connected I guess, but at the same time, that's not easy to know
[14:58] <henrix> diwic: hmm... ok, i can ask the reporter to try to comment that and see what we get
[14:59] <diwic> henrix, aha, I thought you were the reporter, sorry
[14:59] <henrix> diwic: ah, no. sorry, should have made that clear :)
[15:01] <henrix> diwic: thanks for you hints. i'll try to investigate this a little bit more
[15:01] <diwic> henrix, well, so this seems to have made it into 3.3
[15:02] <diwic> so this commit is not in precise, correct?
[15:02] <henrix> diwic: i haven't check that, but it should be
[15:02] <henrix> diwic: it is reported against oneiric
[15:03] <bjf> henrix, diwic, yes, that commit is in precise
[15:03] <diwic> bjf, thanks
[15:03] <henrix> yeah, it just. just checked as well
[15:05] <diwic> henrix, so I care mostly about 12.04, in which case this would be resolved by the Pulseaudio patch I'm writing today
[15:05] <diwic> henrix, for 11.10; well, dunno if it's causing a lot of problems, revert it
[15:06] <henrix> diwic: well, not sure about reverting it. we would need to know what problems it would cause
[15:07] <diwic> henrix, as for reporting bugs upstream; it could be worth having the discussion I guess, but it might backfire on us loading the module-switch-on-port-available in the first place
[15:07] <diwic> henrix, which is related to the jack detection stuff I've been doing.
[15:08] <henrix> diwic: ah, ok.
[15:08] <henrix> diwic: would that pulse patch be backported into oneiric?
[15:09] <henrix> diwic: or there are no plans for that?
[15:09] <diwic> henrix, so question is if this actually a bug fix or rather a change in behaviour
[15:09] <cking> mdeslaur, thanks for the heads-up on that bug, I'm on to it right now
[15:09] <mdeslaur> cking: cool, thanks!
[15:09] <henrix> diwic: yeah, i understand what you mean
[15:10] <diwic> henrix, I'm not currently planning to backport it, but I don't know...I'm okay with backporting it myself if there is demand for it.
[15:10] <diwic> henrix, but that PulseAudio change is also a change in behaviour more than a bug fix
[15:10] <henrix> henrix: ack
[15:11] <diwic> henrix, maybe I should ask Wu about what this patch actually resolves?
[15:12] <henrix> diwic: that patch came in from upstream stable. i would need to spend some time looking at the stack in order to actually understand the changes introduced
[15:14] <diwic> henrix, I tend to like the patch.
[15:14] <diwic> henrix, at least judging from the commit text.
[15:15] <henrix> diwic: well, yeah... but i am unable to measure the consequences just looking at it :)
[15:15] <diwic> henrix, it's just a little stupid that we can't tell the difference between a monitor being plugged in, and being returned from standby.
[15:16] <henrix> diwic: so, you already helped me a lot by explaining that this is more a change in the behaviour
[15:17] <henrix> diwic: so, i'll take a better look at the whole thing and try to have some conclusion about all this
[15:18] <diwic> henrix, ok
[15:18] <henrix> diwic: and thanks!
[16:06] <dholbach> hiya
[16:06] <dholbach> can anyone reply to https://twitter.com/#!/MttCastelli/statuses/181737540187987968 maybe?
[16:09] <tgardner> dholbach, besides the fact that he's running a 3.3 kernel (Precise is 3.2), the Nvidia DKMS driver is owned by OEM.
[16:10] <dholbach> sure, I wasn't trying to make this your problem - just wondering if anyone had a reply for the guy
[16:11] <tgardner> dholbach, I don't think any of us tweet
[16:11] <tgardner> dholbach, feel free to paraphrase my response
[16:11] <dholbach> I'll see if I can find anyone at OEM who knows what's going on - thanks
[16:12] <tgardner> dholbach, contact tseliot
[16:12] <dholbach> yep
[16:13] <dholbach> according to http://www.nvnews.net/vbulletin/showthread.php?p=2536982 "This issue got fixed and available in next 295 driver."
[16:14] <dholbach> I'll mention that to Alberto too
[16:44] <apw> dholbach, mainline kernels are not even supported, plus there is a known issue that binary modules do not work with them ...
[16:47] <Sarvatt> dholbach: it's not compatible with the 3.3 kernels yet, its a really common occurance. the next update we do in precise should be :)
[16:47]  * cking --> in deep thought mode
[17:02] <brendand> bjf, bryceh - we have one certification system that can't start x with the new -proposed kernel
[17:02] <bjf> brendand: what's the bug # ?
[17:02] <brendand> bjf, bryceh - the tester is telling me that it seems not be related to the kernel itself entirely though
[17:02] <brendand> bjf - being raised right now, i'll get you it asap
[17:06] <brendand> bjf, bryceh - https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/959494
[17:06] <ubot2`> Launchpad bug 959494 in xorg "[HP Probook 6550b] Fails to start graphical environment" [Undecided,New]
[17:07] <brendand> bjf, but booting with the -updates kernel also doesn't work
[17:08] <bjf> brendand: well, unfortunately, that makes it _not_ a regression (at least not a regression for this kernel)
[17:09] <brendand> is this an argument for including other packages in the kernel SRU cadence?
[17:10] <brendand> like x for example?
[17:11] <bjf> brendand, i don't think so. i think it's a case for better regression testing of other packages.
[17:12] <brendand> bjf - that's sort of what i was trying to say, maybe they don't need to follow the same cadence, but the same process
[17:13] <bjf> brendand, yes, i agree that other packages should follow a similar process
[17:14] <bryceh> brendand, how has he determined it not to be related to the kernel?
[17:14] <bryceh> brendand, if it's an X issue we'll have to see the Xorg.0.log
[17:15] <brendand> bryceh, by booting into the -updates kernel. isn't that good enough?
[17:21] <brendand> bryceh, it's just an intel chipset too so i'm wondering what other packages could be involved in the regression
[17:21] <bryceh> brendand, very little has changed in X on lucid, so I was just asking if he had any better evidence
[17:22] <brendand> bryceh, yeah. i always remember you telling me that
[17:22] <bryceh> brendand, typically this class of issue is most commonly caused by an error in the xorg.conf, but can also happen if an X driver got uninstalled, or was broken for some reason
[17:23] <brendand> bryceh, well - we have a very strictly controlled install process so user error is unlikely to occur
[17:23] <apw> bryceh, yo ... did you manage to do any further testing on that edid patch?  i'd want to be commiting things like that right after beta if we're going to have it, as kernel freeze is RSN
[17:23] <bryceh> in any case, generally an error will get written to Xorg.0.log or gdm.log in this type of failure.
[17:23] <brendand> bryceh, so perhaps one of those things happened, but it would most likely have been one of the updates that did it
[17:24] <brendand> bryceh, so far we:
[17:24] <brendand> installed (PxE)
[17:24] <bjf> brendand: we need the log files
[17:24] <bryceh> apw, heya, yep top of the todo list
[17:24] <bjf> brendand: that bryceh has asked for
[17:24] <bryceh> apw, last week was a bit crazy with people needing stuff looked into
[17:24] <apw> bryceh, ahh cool ... /me wonders if that needs any shining ... i should look
[17:25] <apw> bryceh, they are like that people, always wanting things ... good job i am a robot instead
[17:25] <bryceh> apw, I should turn robot too!
[17:26] <bryceh> brendand, also the dpkg.log might be useful in tracking down which packages had gotten updates.  Surprised that isn't already included in your apport hook.
[17:26] <brendand> bjf, i know you do - he's just stepped out for lunch though
[17:26] <bjf> brendand: ok, i think further discussion can wait until we see the log
[17:36] <tgardner> ogasawara, I have 3.2.12 prepped. shall I push it ?
[17:36] <ogasawara> tgardner: yes please
[17:37] <tgardner> ogasawara, still doing build tests, but I think it'll be OK. pushed...
[17:37] <tgardner> or rather, pushing....
[17:37] <ogasawara> tgardner: is it an ABI bumper?
[17:38] <ogasawara> tgardner: we could squeeze in an upload before beta-2 freeze this thurs
[17:38] <tgardner> ogasawara, dunno yet
[17:38] <tgardner> ogasawara, gimme 10 mins
[17:41] <apw> tgardner, ogasawara, infinity has confirmed that a UP build of the same commit as your last upload boots ok, the smp only powerpc build does not on his H/W
[17:42] <apw> smb, do your menus appear ok now, or do you still get the partial versions ?
[17:42] <apw> smb, as that bug got closed fixed, adn i can't recall when i last noticed them
[17:42] <ogasawara> apw: hrm, so that would contradict our beliefs that smp should work on non-smp hw
[17:42] <smb> apw, No, that seemed to have been fixed around when they closed it
[17:43] <apw> ogasawara, for one machine at least yes
[17:43] <apw> not sure if that warrent backing it out for beta and some more investigation
[17:43] <apw> there is almost no obvious difference between the configs for the two other than the CPU count
[17:46] <ogasawara> apw: I'd lean towards backing it out until we find a fix.  tgardner thoughts?
[17:47] <tgardner> ogasawara, nak from me. lets find out if there is more then 1 machine like it left in the world. I'm tired of supporting antiques.
[17:53] <tgardner> ogasawara, no ABI bump on amd64
[17:53] <ogasawara> tgardner: ack, I'll prep an upload
[17:54] <ogasawara> tgardner: tgardner: for powerpc, I'll ship with non-smp removed for Beta-2 to see if we can flush out any other broken systems.  but I think if we can't find a solution for infinity and others (if any), we may have to reinstate it based on the same argument against dropping generic i386.  We'll give them at least another 5yrs with the LTS, but drop it in Q.
[17:55] <tgardner> ogasawara, you're gonna make me cry.
[17:57] <tgardner> ogasawara, back in a sec. I'm boot testing 3.2.12
[18:10]  * henrix will be out for ~20 mins
[18:15] <ogasawara> tgardner-lunch: I have an idea baking to make both parties happy for powerpc, mumble when you get back
[18:20] <jjohansen> ogasawara: when is the last kernel upload?
[18:21] <ogasawara> jjohansen: I'll probably squeeze one in today, but then that will be it until after Beta-2 (assuming no kitten killers)
[18:22] <ogasawara> jjohansen: we'll probably be able to squeeze in 1 or 2 more uploads in between Beta-2 and Kernel Freeze (Thurs Apr 5)
[18:22] <jjohansen> ogasawara: okay, /me doesn't have anything that would affect todays upload
[18:23] <jjohansen> ogasawara: thanks. I will work on getting a rebase request based on the 3.4 version of apparmor together for you post Beta-2
[18:24] <ogasawara> jjohansen: cool, if I could ask you try to get them to us before the end of March, that would be ideal.  As I hope to upload our final kernel Mon Apr 2.
[18:24] <jjohansen> ogasawara: yep that should work, just have to wait for linus to suck in the security-next tree
[18:25] <ogasawara> jjohansen: ack
[18:35]  * apw goes for supplies ...
[19:12] <SaveTheRb0tz> Hi. I've just noticed that I can't build 3.2 precise kernel in lucid chroot without porting new dpkg >= 1.16.0 and dpkg-dev (for new dpkg-architecture -qDEB_HOST_MULTIARCH).. Is there some workarounds or fixes planned?
[19:30]  * apw goes fine beer
[19:30] <tgardner> SaveTheRb0tz, we've not put any effort into supporting that configuration. build in a Preicse schroot, or on a Precise host.
[19:36] <apw> SaveTheRb0tz, i am supprised they don't build ... we build mainline builds in lucid chroots with precise packaging
[20:10]  * ogasawara lunch
[20:14]  * tgardner -> EOD
[20:25]  * cking --> EOD too
[20:30] <cking> :-( my ThinkPad is dead
[20:31] <vanhoof> cking: the x220?
[20:32] <cking> yep
[20:33] <cking> did "reset BIOS settings to default, F10 save", reboot, completely bricked
[20:33] <cking> uttter pants
[20:33] <vanhoof> cking: :\
[20:33] <vanhoof> cking: under a year old?
[20:33]  * vanhoof assumes so
[20:34] <vanhoof> they came out about this time last year
[20:34] <vanhoof> they were really easy to work w/ when my lcd went bad
[20:34] <vanhoof> fixed it in ~3 days
[20:34] <cking> vanhoof, yep, 3 months old
[20:34] <cking> if that
[20:35] <cking> tomorrow's problem
[21:06] <SaveTheRb0tz> apw: from my little research lucid's dpkg doesn't know anything about multiarch... So it's pretty strange that you somehow got it built on lucid.
[21:08] <bryceh> apw, the edid write thing tests out well on my hardware.  is there a chance of it being included in precise?
[21:59]  * cking gives up for the day
[22:37] <infinity> ogasawara: That was the most formal email anyone has ever written to me when our previous conversation involved discussing *censored* and *censored* over beer. :P
[22:39] <mjg59> infinity: There's something about you that encourages people to treat you like a gentleman
[22:39] <infinity> mjg59: Everyone but you?
[22:41] <pbuckley> lol