[00:02] <bjf> ogasawara, still around? can you ssh to tangerine? I'm getting: shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
[00:02] <bjf> ogasawara, wasn't getting this 5 minutes ago
[00:02] <ogasawara> bjf: yah, lemme try
[00:03] <ogasawara> bjf: was able to ssh just fine, no errors
[00:03] <bjf> huh
[01:28] <vanhoof> bjf: /me is in too
[01:28] <bjf> vanhoof, good to know, it's strange though
[04:26] <lucent> I'm not usually so impatient :/
[04:26] <lucent> "ieee1394: remove the old IEEE 1394 driver stack" makes me nervous
[04:31] <AceLan_> lucent: could you file a bug to describe your problem more detail?
[05:31] <lucent> AceLan_: bug 657081  - what more can I do?
[05:31] <ubot2> Launchpad bug 657081 in linux (Ubuntu) "New firewire stack unreliable with Texas Instruments TSB82AA2 IEEE-1394b (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/657081
[06:34] <lucent> found a regression between 2.6.32-24-generic and 2.6.35-22-generic with a usb serial converter
[06:34] <lucent> works in 2.6.32-24-generic, broken in 2.6.35-22-generic
[07:25] <lucent> reported bug 660315
[07:25] <ubot2> Launchpad bug 660315 in linux (Ubuntu) "U232-P9 USB Serial adapter not working in Ubuntu 10.10 (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/660315
[08:07] <smb> morning .*
[08:09] <lucent> greetings :)
[08:42] <smb> apw, still can't hear you. :)
[08:53] <lucent> should I wait for Manoj to triage my firewire bug report, or is it approrpiate for me to ask Stefan Richter?  
[08:53] <lucent> knowing full well that I am impatient, I also want to do everything I am expected to do in follow up
[08:53] <smb> lucent, Why not asking him directly. Though sometimes a bit of patience is needed there. :)
[08:53] <smb> Maybe asks you to open an upstream bugzilla report which then could get linked to the lp report
[08:54] <lucent> I'm glad to have your opinion, thank you
[10:00] <smb> I would think so (but must admit not to have used oprofile recently). 
[10:07] <jendap> ok, thanks!
[10:30] <cking> apw, hibernate on hpmini, 18.2 seconds with swap in first 8MB, 25.5 seconds with swap in last 8MB
[10:31] <apw> cking, significant support to your other figures
[11:26] <TeTeT> apw+smb: I've tested the patch for bug 586325 the last couple of days and the customer also reports that it is working. Can it be applied to the next lucid kernel?
[11:26] <ubot2> Launchpad bug 586325 in linux (Ubuntu Lucid) (and 2 other projects) "[i965q] Fujitsu Siemens Esprimo E: changing resolution results in non working X (affects: 1) (heat: 16)" [Undecided,Triaged] https://launchpad.net/bugs/586325
[13:23] <JFo> I slept at the proper time last night! \o/
[13:26] <apw> JFo, yay!!
[13:27] <JFo> :-)
[13:27] <JFo> may go offline in a bit. There was a wreck in front of my house that took out 2 telephone poles.
[13:28] <apw> ouch!
[13:28] <JFo> they will likely drop power as they fix/replace them
[13:28] <JFo> yeah, you should've seen the car
[13:28] <JFo> destroyed
[13:28] <apw> i probabally will on one of those 'police video' shows
[13:28] <JFo> the officer outside that I spoke with said the girl driving was unhurt
[13:28] <JFo> she was lucky
[13:28] <JFo> you may indeed :)
[15:55] <apw> TeTeT, proposed for SRU
[15:55] <apw> smb, i've just dropped that backport patch (for the resolution issue) onto the kernel-team@ list, you might consider it for 2.6.32.x.y
[15:56] <smb> apw, I was just about to as. :)
[15:56] <TeTeT> apw: thanks a lot
[15:57] <apw> smb, where can i find the sru template, my local copy has gone awol
[15:57] <smb> apw, Actually I might have already considered... I will know as soon as I see
[15:57] <smb> mail seems to be slow for me recently
[15:58] <smb> apw, Hm a template not sure there is something written down cleanly
[15:58] <lag> smb: apw: Can you have a look at he patches I've submitted to the ML please?
[15:58] <lag> They need to be in by Monday apparently
[15:59] <lag> If they're okay, I'll submit an SRU
[16:00] <lag> Does each patch need the SRU description, or can it be in [0/0
[16:00] <lag> i.e. the cover letter
[16:01] <apw> the SRU description is normally in the 0/0 and at the top of the description of the bug
[16:01] <smb> lag, in 0/0 is sufficient
[16:01] <lag> Should I re-submit? 
[16:01] <smb> actually the patches should preferably be exactly like they could be applied
[16:02] <smb> lag, had not yet time to look at them, so I don't know
[16:02] <lag> k
[16:02] <apw> lag, how come the submitter has not signed them off
[16:02] <lag> I guess he would
[16:03] <lag> He just emailed me the patches
[16:03] <lag> I can get him to
[16:03] <apw> you can't guess, either he has or he hasn't and if he hasn't then they arn't safe to apply
[16:03] <Q-FUNK> it seems that bug #396286 is magically solved as of kernel 2.6.36-generic 0.2
[16:03] <ubot2> Launchpad bug 396286 in linux (Ubuntu) (and 1 other project) "[Geode LX] [ION603] kernels >= 2.6.31 fail to boot [initramfs] (affects: 2) (heat: 26)" [High,Triaged] https://launchpad.net/bugs/396286
[16:04] <smb> apw, bjf Just thinking on the tagging. Probably we could go for UBUNTU: ARM: for those changes we do for arm...
[16:05] <bjf> smb, that's what I did for the ones i did yesterday for maverick (after your email)
[16:07] <smb> bjf, right, it seems to be a good idea to me (though we had not yet written something down on that wiki page we collect them). But those are special in the sense of usually not upstream which would otherwise be a requirement
[16:14] <smb> lag, The patches are a bit hard to understand, but on the good side only affect the omap soc, so as long as they do not break compilation somewhere else any other problems do not affect the main distro. ;) If you resubmit them to sru don't forget to tell which release. The educated guess is Maverick but things get confusing for those who look after all releases.
[16:15] <lag> That's no problem
[16:16] <lag> I will also put the branch name, as they are to be applied to the ti-omap4 branch only
[16:16] <smb> lag, Good point, as some of the arm stuff goes to master and some not it is really hard to tell otherwise
[16:17] <ogra_ac> smb, would be good to have them uploaded today, we're a bit under time pressure with that fix
[16:17] <smb> apw, Your patch has been queued already
[16:17] <ogra_ac> (guessing its your duty now that maverick is released)
[16:18] <smb> ogra_ac, You know that sru and quick are contradicting things. No, I am passing all pain to sconklin and bjf 
[16:18] <ogra_ac> hmm, k
[16:19] <apw> smb, cool
[16:20] <apw> ogra_ac, are you referring to the audio fixes ?
[16:20] <smb> I would assume so
[16:20] <ogra_ac> yes
[16:20] <apw> and are those ti-omap4 ?
[16:20] <ogra_ac> yes
[16:20] <apw> we need to get the originator to sign them off
[16:34] <bjf> apw, it's just an arm branch, we'll put anything in one of those
[16:35] <ogra_ac> hey !
[16:35] <ogra_ac> :)
[16:36] <smb> lag, ogra_ac So as bjf had been acking them, I would go forward and apply them and initiate a test build upload
[16:36] <ogra_ac> THAT WOULD BE COOL
[16:36] <ogra_ac> OOPS
[16:36] <ogra_ac> hrm
[16:36]  * ogra_ac hates that the caps control led doesnt work here
[16:37] <lag> :)
[16:37] <lag> Thanks smb
[16:38] <lag> Thanks bjf 
[16:46] <cking> ogra, w/o a caps LED it's hard to debug the kernel :-)
[16:47] <ogra_ac> cking, you wouldnt want   to debug *that* kernel :)
[16:47] <cking> indeedy
[16:47]  * ogra_ac is typing on an ac100 ... nvidia tegra 2.6.29
[16:48] <ogra_ac> patches from nvidia on top of .29 .... patches from toshiba on top of that
[17:34] <Matthew_> Oh hello
[17:35] <Matthew_> Can somebody please help me on a particular issue
[17:35] <Matthew_> ?
[18:58] <jjohansen> bjf: ping, is there anything I can do to speedup moving the EC2 kernel through -proposed and into updates?
[19:01] <bjf> jjohansen, the only thing i can think of is for you and the server guys talk to pitti about it
[19:01] <jjohansen> bjf: okay thanks
[19:02] <hermes> JFo: ping, I was being told that you could help me around with starting some work on the Linux kernel. I am fairly a beginner so would appreciate if someone could team to help
[19:03] <JFo> hi hermes 
[19:03] <JFo> indeed I can
[19:03] <JFo> what specifically are you interested in?
[19:03] <hermes> If you could direct me I could contribute and get some job done
[19:03] <JFo> triage?
[19:03] <JFo> ok cool :)
[19:03] <bjf> jjohansen, once a kernel is in -proposed it's out of our control (mostly)
[19:04] <hermes> JFo: I have loved system programming and have a lot of inclination towards it, would love to get my hands dirty with whatever your experienced self would feel is best to get started 
[19:06] <JFo> well, if you are looking to begin in the code, I recommend having a look at the bugs with patches and seeing if they already exist in the current kernel, if they are upstream (in Linus' tree) and not in the kernel and working them as appropriate. Sound interesting?
[19:08] <hermes> JFo: Surely mostly definately
[19:08] <JFo> excellent
[19:09] <hermes> JFo: I could begin with that, Great
[19:09] <JFo> now, let me get you a link to those
[19:09] <JFo> hermes, https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.has_patch=on
[19:09] <hermes> JFo: most definately, please I appreciate that very much. Anymore tips and guidelines plz
[19:09] <JFo> that ^^ is the link to all kernel bugs with patches
[19:10] <JFo> if you like, give them a look and see which ones are actually patches and which have mistakenly been set as patches
[19:10] <JFo> then we can begin looking at the ones that are legit
[19:10] <JFo> sound ok?
[19:10] <JFo> that way we are starting a bit slowly
[19:10] <JFo> :)
[19:10] <JFo> I don't want to over whelm you
[19:12] <sbeattie> jjohansen: looking at http://people.canonical.com/~ubuntu-archive/pending-sru.html the linux-ec2 kernel seems to have a lot of bugs marked verification-failed.
[19:12] <sbeattie> (that's the red bug numbers)
[19:12] <hermes> JFo: sounds great
[19:12] <jjohansen> sbeattie: okay thanks
[19:12] <hermes> JFo: I will have a look
[19:13] <JFo> excellent
[19:13] <JFo> let me know any questions you have and we will move forward when you are ready :)
[19:13] <sbeattie> jjohansen: the ones in blue need verification as well. A package (particularly the kernel) doesn't need to be all green to make it out of proposed, but being able to explain why things haven't been verified or are tagged verification-failed is helpful.
[19:13] <hermes> JFo: sure I have a few things to ask you
[19:14] <JFo> ok
[19:14] <sbeattie> jjohansen: so sic the server team on those bugs.
[19:14] <hermes> JFo: I will have a look at these, what the best way to figure these registered bugs are already upstream on Linus' tree
[19:14] <jjohansen> sbeattie: I plan to
[19:14]  * sbeattie grins.
[19:14] <jjohansen> and thanks
[19:15] <hermes> JFo: I have not worked with the Kernel code so its a little difficult to understand at first
[19:15] <JFo> hermes, you would need to have a local branch of Linus' tree so you can check them
[19:15] <JFo> hermes, I see
[19:15] <JFo> t may be a good idea for you to research and get familiar with git (the source management software) before you begin then
[19:16] <JFo> that way you can get the current branches of Linus' tree plus the Maverick tree to view and work from
[19:17] <hermes> JFo: great that elaborates much. I have used GIT , so I will be able to pull the branches. 
[19:17] <JFo> excellent :)
[19:18] <hermes> JFo: Could give me small example for a hypothecial general conditon/bug. I mean how should I approach this
[19:18] <JFo> I keep a local copy of Linus' tree, the Maverick tree and the Lucid tree
[19:18] <JFo> hermes, not sure what you mean?
[19:21] <hermes> JFo: U have done the same exercise right ? so suppose u found a bug X then how did u go about checking. Forgive me for a little abstract
[19:22] <JFo> ah
[19:22] <JFo> so on the bugs with patches...
[19:23] <JFo> I take a look at the patch to see what it fixes and where
[19:23] <apw> jjohansen, picking the first red one at random, it doesn't seem to be ec2
[19:23] <JFo> then I look in the current released source for Ubuntu to see if the patch is there
[19:23] <JFo> if it is not, I look in Linus' tree to see if it is there
[19:24] <jjohansen> apw: yeah, I have been going through them, none of them so far are
[19:24] <JFo> if it isn't there either, I send the patch to the kernel-team list for review
[19:24] <JFo> then, depending on what their remarks are, you may need to submit it upstream and CC stable
[19:24] <JFo> or there may be more needed in the patch
[19:25] <JFo> at which point you would go back to the writer of the patch with feedback
[19:25] <JFo> and have them submit the patch upstream and to stable
[19:25] <JFo> is that what you were asking hermes?
[19:26] <hermes> JFo: precisely, bang on target..very clear
[19:26] <JFo> excellent :)
[19:27] <bjf> jjohansen, those came in as part of the rebase of ec2, the regular kernel with those patches is in updates
[19:27] <hermes> JFo: I would have many questions or doubts as I progress with actual work..I will find you around
[19:28] <JFo> sounds good :)
[19:28] <jjohansen> bjf: right, its just working through and seeing if any of them even apply to EC2
[19:29] <hermes> JFo: thanks man, ok going step by step. I will first pull the code from both sources and then I will start looking at the bugs 
[19:29] <hermes> JFo: we can kick it off from there on, is that ok?
[19:30] <JFo> sounds great hermes :)
[19:33] <hermes> JFo: I am in INdia so its past midnight, I will hit the bed for now. Need to reach work early morning. thanks for the help. I appreciate it man
[19:34] <JFo> sounds good, it is my pleasure hermes :)
[20:02] <vanhoof> thanks JFo :)
[20:02] <vanhoof> JFo: totally not looking forward to a friday->wednesday trip :\
[20:03] <JFo> heh
[20:03] <JFo> I can imagine :)
[20:29] <smagoun> apw: Hi, I see you worked on this for Lucid: "Investigate per device nomodeset override". What was the outcome of that work? Is there a mechanism for overriding nomodeset, or applying it on a per-device basis?
[20:29] <smagoun> (from https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-lucid-kms )
[20:31] <apw> smagoun, there is a kernel blacklist for modeset yes
[20:34] <smagoun> apw: Can it be configured via a file, or does it have to be compiled in? I know I can add something to /etc/modprobe.d, I don't think that helps in my particular case though - I need to use the same OS image on 2 systems w/ Intel gfx. One requires KMS, the other doesn't work with KMS. I'd like to blacklist one or the other
[20:35] <smagoun> but I'm not sure how to do that via /etc/modprobe.d/. Can I pass a PCI ID to the i915 options?
[20:35] <apw> smagoun, its builtin
[20:36] <apw> though we might be able to add a modprobe option list sort of thing
[20:38] <smagoun> apw: ok, thanks. I need this for 9.10(!), so I'll see what's involved in modifying the builtin. Adding support for the options list sounds useful for the nebulous future, don't think it'll help my immediate need.
[20:41] <smagoun> come to think of it, supporting this in 9.10 is probably going to require a larger-than-I-want dkms package, or a backport....yuck
[20:44] <apw> i wish we didn't change the name on release
[20:44]  * ogra_ac is still called ogra over several releases :P
[20:45] <apw> smagoun, in jaunty ?
[20:46] <apw> smagoun, does that go off support in 2 weeks?
[20:46] <ogra_ac> 9.10 was karmic 
[20:46] <bjf> heh, apw needs to go to bed
[20:47] <smagoun> karmic, yeah
[20:47]  * jjohansen -> lunch
[20:48] <bjf> apw, sorry, thought it was later than it is :-)
[20:48] <apw> bah missread indeed
[20:50] <jjohansen> pfft its plenty late for apw, he needs to go party
[20:57]  * apw caught something vile at release sprint and is going to no parties
[21:10]  * ogasawara lunch