[00:12] <jonpry> is there an ACPI support group or recovery channel?
=== medberry is now known as med_out
=== chrisccoulson_ is now known as chrisccoulson
[08:35]  * apw looks out blearily ...
[08:41] <cking> jet lagged still?
[08:41] <apw> a bit perhaps, not sure, just feeling lethargic this morning
[08:41] <apw> a couple of beers last night did not help i suspect
[09:06] <htorque> hi! i have no idea where to ask, but maybe you can help me out: yesterday i experienced a strange thing where "killall opera" killed opera and xchat.
[09:06] <htorque> i killed opera, because unity's alt-tab switcher preview for opera showed me the xchat window and i thought that's just another unity bug. that seems rather scary, what could cause this? 
[09:09] <apw> htorque, i have never seen that myself.  killall iirc uses the command lines listed in /proc/$$ to identify matching processes.  So a bug in killall or a bug in kernel display of those could trigger this.  Also a bug in display of your command line could also do so, say you ended up really running killall a ... i get that sometimes in bash with wide terminals
[09:11] <apw> its unlikely that those kinds of bugs could also trigger a miss match of the preview, however coincidental that might be, as that is done via X properties ... specificially the X class for unity
[09:11] <htorque> it would just be a strange coincidence that also unity's... right :)
[09:11] <apw> i suspect that actually xchat may have already been lost and just its preview retained in unity
[09:12] <htorque> it was actually the other way round - opera was kinda lost. :-/
[09:12] <htorque> and i only killed opera, according to my bash history
[09:13] <htorque> could this be caused by memory corruption (ie. a hardware error)?
[09:14] <apw> right what i am suggesting is that xchat was actually 'gone' already ie the process was dead, unity was confused and showing xchats last output as the preview for opera, so when you killed opera that got rid of the preview
[09:15] <htorque> i see. now: how do i reproduce that? :P
[09:15] <apw> cking, its POSTPONED ...
[09:15] <apw> htorque, heres hoping that the unity updates get rid of it :)
[09:15] <cking> apw, me made a typo? eh?
[09:16] <apw> cking, or your internal dictionary is corrupt
[09:16] <cking> the latter
[09:16] <apw> cking, ok you corrected it already, but then deleted the workitem and orphaned one
[09:16] <htorque> apw: k, thanks for your answer! at least now i have something to check if that should happen again. :-)
[09:17] <cking> apw, my fail
[09:17] <apw> cking, was the item meant to get deleted? as i have the update here if you need it
[09:18] <cking> which item?
[09:18] <apw> - [colin-king] pre-test program to confirm what output devices they may have: POSTPONED
[09:18] <apw> +
[09:18] <apw>   [sconklin] investigate video DDC pin: TODO
[09:18] <apw> you did that, which deletes an item and replaces it with a blank line, which leaves steves item in the lurch
[09:18] <apw> but i am unsure if you intended to delete it or not
[09:19] <cking> yep, it was intentional to delete that, I think I moved it up and made a note
[09:19] <apw> oh yeah off the top of my screen, doh, so i'll unorphan that item then
[09:20] <apw> cking, ok fixed
[09:20] <cking> thanks, my fail
[09:23] <apw> cking, so the items you deleted i think actully both are DONE
[09:23] <apw> the first the result was "we are not going to do this"
[09:23] <apw> and the second the work went into the debug repo not the kernel, but you did the work
[09:24] <apw> cking, so i think you should write a section for each in the results section of the spec (just a couple of sentances on why/where the work was done) and then mark them :DONE
[09:24] <apw> else the work you did just dissappears
[09:24] <cking> hold on - can I get back to this, I'm doing a tutorial at the mo - I will take you advice and fix it up at 11.30am
[09:24] <apw> cking, yep
[09:24] <apw> cking, this is irc, just ignore me until you have time, that is the nature of irc
[09:25]  * cking is single threaded
[09:25] <apw> who isn't
[10:09] <ppisati> the "look into generating a trimmed down config for debug purposes" in the "Kernel Configuration Review" was more of a request from me to what interesting options i could turn to ease debugging: i think i was looking for some magic switch like "turn off smp, turn off cc optimization, etcetc" to avoid having to do that by hand everytime
[10:10] <ppisati> so, to what status can i put this item like "it never made any sense"? POSTPONED? don't think so
[11:28] <apw> pgraner, this from a grub prompt: hwmatch ${prefix}/gfxblacklist.txt 3
[11:28] <apw> pgraner, then: ec
[11:28] <apw> pgraner, then: echo $?
[11:28] <apw> (ignore the ec)
[11:28] <apw> pgraner, then: echo $match
[11:28] <apw> pgraner, then: set
[11:29] <apw> and see what the gfx thingies are set to
[11:30] <apw> pgraner, what i get is only the modeswitch black flicker just before plymout and a white flash as lightdm starts, the first is unavoidable, the second is a bug
[11:31] <apw> wmatch ${prefix}/gfxblacklist.txt 3
[11:31] <apw> arrgle
[11:39] <pgraner> apw, cool, let me update my laptop first and see what it does, then I'll get back to this machine
[13:26] <cking> apw, I've updated the s3/s4 spec with copious amounts of notes now ;-)
[13:26] <cking> and added some wiki page updates else where too
[13:26] <cking> so it was a good exercise in dotting the i's and crossing the t's
[14:04]  * ogasawara back in 20
[14:47] <diwic> ogasawara or apw, what are the odds for 3.2 vs 3.3 vs 3.4 for Ubuntu 12.04?
[14:48] <ogasawara> diwic: not sure, we havent really discussed it yet.  I believe there was talk about 3.2 at plubmers
[14:49] <diwic> ogasawara, which means all feature development for kernel must happen within a few weeks from now...?
[14:49] <diwic> I think the 3.2 merge window opens soon
[14:50] <ogasawara> diwic: that would be the case if we went with 3.2
[14:51] <ogasawara> diwic: if there are reasons to go with a newer kernel, probably best to make sure we're aware going into UDS as that's where we make the decision
[14:52] <diwic> ogasawara, yeah, I'll try to attend that session. For me a later kernel is always better (less things to backport)
[14:53] <tgardner> ogasawara, in reality we're not gonna choose a kernel version until January. UDS is simply too early to know for sure.
[14:54]  * ogasawara nods
[14:55] <diwic> tgardner, sure. It just is good to have some kind of feeling for it. I mean, should we go for 3.2, FeatureFreeze for kernel is ~4 months ahead of FeatureFreeze for userspace
[14:55] <tgardner> there are a lot of competing pressures, not all of which I can predict.
[14:59]  * apw nods sagely
[14:59] <diwic> tgardner, of course. As long as there as get to add my pressure I understand that it will not always prevail :-)
[15:00] <apw> we have had a lot of benefit from .32 being a long-term kernel
[15:00] <apw> we would love to have 12.04 on a similarly long-term kernel
[15:00] <diwic> but in short, there's a real chance it might be 3.2, so better safe than sorry and try to do kernel development for P asap
[15:01] <diwic> apw, sure. Is 3.2 going to be such a long-term kernel?
[15:01] <apw> that is something we need to figure out for sure
[15:03]  * apw looks at the sun longingly ... i am gonna drift off while its still nice ... see yas
=== med_out is now known as medberry
[15:06] <sforshee> sconklin, looks like commit bbeaf8811 introduced an i915 regression in natty -- bug 838181
[15:07] <ubot2> Launchpad bug 838181 in linux "External monitor connected trough mini DisplayPort wired to integrated Intel AGP is properly recognized and configured but has no sync" [Medium,Triaged] https://launchpad.net/bugs/838181
[15:07] <sconklin> sforshee, whee
[15:08]  * sconklin is wondering if it's time to remove the word 'stable' from upstream updates
[15:08] <sforshee> sconklin, actually that one didn't come from stable :(
[15:08] <sconklin> heh
[15:08] <sconklin> I take back everything bad I ever said about upstream
[15:10] <sforshee> sconklin, do you just want to revert the commit, or do you need me to do something with it?
[15:10] <sconklin> sforshee, I'm looking but I will likely revert and respin
[15:10] <sforshee> okay, let me know if there's anything you need me to do
[15:12] <sconklin> sforshee, ok, thanks. I flagged the tracking bug, so it can't get released
[15:14] <sconklin> sforshee, nice job isolating this, thanks!
[15:15] <sforshee> sconklin, it looks like this one's already in -updates, the patch was in 2.6.38-11.47
[15:15] <tgardner> ogasawara, hey, I got upstream b43 working with open firmware in 3.1-rc6. maybe we're close to seeing the last of wl
[15:15] <sconklin> sigh.
[15:16] <ogasawara> tgardner: \o/
[15:16] <sconklin> ok, then normally we just ship this version and fix it in the next. I'll unblock the tracking bug and stick the revert onto master-next. Actually, I'll talk with the author first, they probably want to get it fixed properly
[15:17] <ogasawara> tgardner: should we consider pulling it into lbm?
[15:18] <tgardner> ogasawara, there is some merit to that idea. I need to track down the provenance and licensing of the open firmware so I can add it too the linux-firmware package
[15:19] <ogasawara> hrm, I just realized I haven't been bumping lbm ABI and uploading
[15:20] <tgardner> ogasawara, tsk, tsk.
[15:20]  * ogasawara add it to today's todo list
[15:21] <tgardner> ogasawara, as for backporting, we'll get the b43 work for free with compat-wireless
[15:21] <ogasawara> tgardner: ah cool
[15:24] <tgardner> ogasawara, it may actually work with the oneiric kernel with the proper firmware
[15:38] <tgardner> ogasawara, oh, thats just way cool. b43 works like a charm with 3.0.0-11
[15:38] <ogasawara> tgardner: nice, ship it
[15:38] <tgardner> ogasawara, don't you have an Inspiron 1501 with b43 ?
[15:39] <ogasawara> tgardner: nope, inspiron 1420 iwl3945
[15:39] <tgardner> ogasawara, hmm, are you experiencing wifi slowdowns with 3945?
[15:40] <ogasawara> tgardner: none here, but I don't use that laptop much aside from running mumble on it
[15:40] <tgardner> ogasawara, ok. there is alot of bitching about 3945 performance lately
[15:41] <ogasawara> tgardner: I'll see if I can get any metrics to confirm
[15:42] <ogasawara> bjf, jjohansen: you guys going to be knitting today?
[15:43] <bjf> ogasawara, nope, don't plan on it
[15:44] <vanhoof> tgardner: manjo was looking into a wifi perf issue on a 6250 iirc which he could only reproduce on oneiric
[15:44] <vanhoof> tgardner: believe he said his router was N only fwiw
[15:45] <tgardner> vanhoof, I've tested a couple of the intel parts against N only. they aren't as fast as I'd like, but they are at least as good as 100 Mbit.
[15:45] <manjo> with mainline RC4 it is even worse 
[15:45] <vanhoof> tgardner: what do you use for testing?
[15:45] <vanhoof> tgardner: i have a couple cards floating around as well here
[15:46] <tgardner> vanhoof, WRT310N is the AP, 6300 and 6250 (I think) for wifi card
[15:47] <vanhoof> tgardner: test wise, something like iperf?
[15:48] <tgardner> vanhoof, yes
[16:00] <jjohansen> ogasawara: yep
[16:14]  * ogasawara heads in to meet up with pdx mafia
=== yofel_ is now known as yofel
[18:09]  * jjohansen heads to meet up with the pdx mafia too
[18:21]  * tgardner -> lunch
=== chuck_ is now known as zul
[19:31] <dupondje> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/703180
[19:31] <ubot2> Ubuntu bug 703180 in linux "SD card reader inaccessible without pci bus rescan" [Undecided,Confirmed]
[19:32] <dupondje> somebody could check this? should really get fixed is my idea ;)