[03:35] <hallyn_> ikepanhc: hey, dave hansen and i are interested in your ideapad-laptop kernel tree :)
[03:35] <ikepanhc> hallyn_: thanks
[03:36] <hallyn_> ikepanhc: do you by chance have suspend/resume working in yours?
[03:36] <ikepanhc> hallyn_: for s10-3 s3/s4 works fine
[03:37] <hallyn_> cool - do you have it built in a ppa?
[03:37] <hallyn_> if not i'll try one
[03:37] <ikepanhc> hallyn_: no, the patch is for upstream kernel
[03:38] <hallyn_> excellent
[03:39] <ikepanhc> hallyn_: I will consider to maintain a dkms package in my ppa, so that everyone can easily use it :)
[03:45] <hallyn_> ikepanhc: when i get some time i'll have to see why your patches woudl make a difference with resume
[03:46] <ikepanhc> hallyn_: ahhh? you mean my patches let your laptop can not resume?
[03:48] <hallyn_> no, i mean maverick kernel does that.
[03:49] <hallyn_> if you say your kernel resumes, then either something in your patches fixes it, or your config
[03:49] <hallyn_> (dhansen has a x86-64 config for maverick that lets resume work on his s10-3)
[03:49] <ikepanhc> hallyn_: I use maverick kernel with ideapad-laptop and bcmwl as external module
[03:50] <ikepanhc> hallyn_: I just test again on B550 and it works fine
[03:50] <hallyn_> what does 'with ideapad-laptop' mean/
[03:50] <hallyn_> with your patches?
[03:50] <hallyn_> or some package?
[03:50] <ikepanhc> hallyn_: I compile the driver as a external module
[03:50] <ikepanhc> hallyn_: use a hello-world Makefile
[03:50] <hallyn_> i'm using wl.ko as came with the default install
[03:51] <ikepanhc> hallyn_: me too
[03:51] <hallyn_> shucks
[03:51] <hallyn_> all right, fwiw first glance your patches looked quite nice.  anyway, i'm out - ttyl
[03:52] <ikepanhc> :)
[07:32] <torgny_j_> apw: ping
[08:48]  * apw yawns
[08:48] <jk-> hey apw
[08:48] <apw> mornign
[08:48] <smb> morning
[08:49] <jk-> heya smb
[08:49] <smb> j/me waves to jk- 
[08:49]  * smb cannot type correctly this morning
[08:51] <apw> heheh
[08:53] <jk-> apw: just looking through Arjan's patches as per delta review spec
[08:54] <apw> jk-, ta
[08:54] <jk-> the 'cache EDID...' one has gone upstream, as you probably already know
[08:54] <jk-> and that appears to have been dropped in master-next
[08:54] <apw> mark it so in the page and i'll make sure its gone, i think it has
[08:54] <jk-> which is good
[08:54] <apw> yep, we've moved somewhat forward since the top list was originally generated for UDS
[08:55] <jk-> so that still needs updating, or does the change in master-next mean that it's already taken care of?
[08:55] <apw> well just mark it as needing dropping and i'll spin through and say its already gone when i apply your recommendations
[08:56] <jk-> ok
[09:20] <jk-> ah, it's in the dropped section already
[14:36] <tgardner> cking, hallyn_, AceLan: I'm bouncing tangerine in 10 minutes for openssl update
[14:38] <cking> ok - I will log off
[14:39] <JFo> apw, I had a thought earlier... did pete say he wanted to move the stuff I have running off of the qa machine and onto one of ours?
[14:39] <JFo> I seem to recall some conversation surrounding that
[14:39] <JFo> I think it had to do with us having more control of what version of things were on there
[14:40] <JFo> like LPlib
[14:40] <JFo> etc.
[14:40] <apw> i don't recall that specifically, i do know he was keen for it to just run, if its helpful for us i to move i don't think anyone cares where it is
[14:40] <apw> as long as it is on somethign which is not going missing any time soon
[14:41] <JFo> yeah
[14:41] <JFo> dunno what made me think of it
[14:55] <JFo> apw, second question: Do you think it is worthwhile to have the gfxpayload bugs on our list? I think we should.
[14:56] <apw> JFo, unsure if they should be on the main list, I could do with a list though as i care about them directly
[14:56] <JFo> good idea
[14:56]  * JFo works that up
[15:10] <apw> JFo, sounds good thanks
[15:10] <apw> JFo, is that anything other than a launchpad search actually?  if we are tagging them ?
[15:13] <JFo> not much more
[15:13] <JFo> but would you rather there be a report or just do the search yourself?
[15:13] <JFo> well, not more at all really
[15:15] <apw> i think we should have a page with the lists referenced
[15:15] <apw> so there can be a Key Bugs link to your report, and a 'gfxpayload bugs' which is just a link to the search
[15:15] <JFo> ok
[15:15]  * JFo adds that to the TODO
[15:16] <JFo> <-so this guy doesn't forget it
[15:16] <apw> hows the tag based list automation going
[15:17] <JFo> pretty good
[15:17] <JFo> I was going about getting the tags the wrong way earlier
[15:17] <JFo> I'm trying to see if/how that has changed since I was doing it way back earlier in the year
[15:18] <JFo> could be that I was trying to do it wrong then
[15:18] <JFo> but I should have that bit worked out in a bit
[15:18] <apw> if you have a working way i'd just be happy
[15:18] <JFo> hopefully have something rough by EOD today
[15:18] <JFo> that was the problem :) it didn't work 
[15:18] <apw> JFo, where i can see the current mock up
[15:19] <JFo> but I think I know what I was doing wrong
[15:19] <JFo> I don't have it pushed yet
[15:19] <JFo> didn't want to put it up there until it was at least doing something
[15:19]  * apw talks at you
[15:19]  * JFo puts his headset on :)
[15:23] <bjf> moin
[15:33] <JFo> moin bjf
[15:44] <apw> JFo, blocks-hwcert this one ?
[15:49] <vanhoof> bjf: this one went out in the previous SRU, right? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/613381
[15:49] <ubot2> Launchpad bug 613381 in linux (Ubuntu Maverick) (and 2 other projects) "S3 resume hang when PCI Express wakeups don't clear the PM1 PCI_WAKE_DISABLE bit (affects: 1) (heat: 12)" [Undecided,Fix released]
[15:50] <vanhoof> bjf: /me wondering why its listed on pending sru list
[15:51] <bjf> vanhoof, looking, these are auto-generated by what's in the changelog
[15:51] <tgardner> vanhoof, it looks like its been released in both Lucid and Maverick
[15:53] <vanhoof> yeah i thought it was, just going through each one by one today and that one looked off
[15:56] <bjf> vanhoof, it is because it was "(pre-stable)" then came in from stable so it was reverted and reapplied, i'll just mark it verification done, we have stopped reverting "(pre-stable)"
[15:58] <bjf> vanhoof, i've marked it as verification-done
[16:05] <cking> bjf, I've verified that one, don't want to keep on re-doing it :-)
[16:05] <bjf> cking, as i said, i've handled it :-)
[16:05]  * apw screams about C crashing
[16:05] <apw> X
[16:06] <cking> should be called XXXX
[16:09] <vanhoof> bjf: gotcha, thanks for the info
[16:10] <vanhoof> cking: we've got the wmi fix to verify, I have other paths to hardware should it not get to you in time :)
[16:12] <cking> vanhoof, I'll do that tomorrow
[16:12]  * apw pops out to run an errand
[16:12] <cking> if that's not too late
[16:12] <vanhoof> cking: did it arrive?
[16:12] <cking> not yet
[16:12] <bjf> cking, vanhoof, we have a week to do the verifications
[16:12] <vanhoof> cking: we have till friday
[16:12] <vanhoof> cking: theres one in lex though
[16:13] <bjf> vanhoof, cking, since the kernels weren't available until today, the clock starts today
[16:13] <vanhoof> bjf: i like pressure
[16:13] <tgardner> JFo, looking at your top bug list. why haven't some of these been expired? e.g., bug #190492 
[16:13] <ubot2> Launchpad bug 190492 in linux (Ubuntu) "Kernel hangs on boot (SATA, AMD64/i386) (affects: 3) (dups: 7) (heat: 15)" [High,Triaged] https://launchpad.net/bugs/190492
[16:15]  * bjf running son to school, will be right back
[16:17] <JFo> tgardner, good question
[16:17] <tgardner> JFo, I thought all bugs with no activity were expired at some point
[16:17] <JFo> well, they have to meet a certain set of criteria
[16:18]  * JFo looks to see why this one didn't meet it
[16:18]  * apw finally makes it out the door
[16:18] <tgardner> apw, out of the closet door?
[16:19] <JFo> :-/
[16:20] <tgardner> bjf, there is a Lucid AA patch from jj-afk on the k-t list that could use your review.
[16:21] <JFo> tgardner, just from a quick look, I'd have to say it was the duplicates that probably kept this one from expiring
[16:21] <JFo> but I don't see much other than that
[16:22] <tgardner> JFo, I wonder if any of them have rolled forward to Maverick, etc. It ain't gonna get fixed in Hardy
[16:22] <tgardner> or Lucid even
[16:23] <JFo> I can look if you want me to
[16:23] <tgardner> JFo, I'm gonna mark it 'won't fix'
[16:23] <JFo> tgardner, works for me
[16:26] <JFo> something is chewing up my network... brb
[16:37] <bjf> tgardner-afk, i saw it, wasn't sure your discussion with jj was finished
[16:41]  * dannf points manjo at #687400
[16:52] <didrocks> JFo: do you need the output of uname -a for bug #686070 ?
[16:52] <ubot2> Launchpad bug 686070 in linux (Ubuntu) "black screen (no more gdm/X server) with nvidia propriatery after gfxpayload=keep activation (affects: 2) (heat: 14)" [Undecided,New] https://launchpad.net/bugs/686070
[17:08]  * JFo looks
[17:09] <JFo> didrocks, shouldn't need
[17:10] <JFo> I was running an old script that had not been updated for natty
[17:10] <didrocks> oh ok :)
[17:10] <JFo> apologies for the confusion :)
[17:10] <didrocks> no worry :)
[17:10] <JFo> was entirely my fault
[17:10] <didrocks> I got it and dholbach too
[17:10] <JFo> heh
[17:10] <didrocks> so for now I workarounded it
[17:10] <didrocks> but you can poke me if you need further info/testing
[17:11] <JFo> indeed I will, thanks :)
[17:12] <JFo> <-lunch 
[17:24] <didrocks> enjoy :)
[17:33] <apw> didrocks, its the prop-drivers so there is little chance of a fix for those
[17:34] <didrocks> apw: right, so we should maybe workaround on some pci?
[17:34] <apw> i suspect we should just turn off that feature when you install those
[17:34] <didrocks> yep
[17:34] <didrocks> because we will require the prop-driver for unity
[17:34] <didrocks> and engage people installing it
[17:34] <apw> didrocks, have fun with that given we cannot put it on the CD
[17:36] <didrocks> apw: already planned, ubiquity will offer that as an option
[17:36] <didrocks> like the mp3 support
[17:36] <apw> didrocks, so is the lve CD  going to use classic desktop mode for nvidia, guess it'll have to
[17:36] <didrocks> and pitti will slightely change the driver wording on install to tell "hey, that can change your graphical interface"
[17:36] <didrocks> apw: right, that's the drawback :/
[17:39] <apw> didrocks, does 3d work well enough on the normal ati drivers?
[17:40] <didrocks> apw: for now, on unity at least, we don't as many issue in compiz than we had with mutter
[17:40] <didrocks> so, quite positive :)
[17:40] <didrocks> (the prop one seems to have more issues, weird…)
[17:41] <apw> well thats something at least, starting to think intel was it
[17:42] <didrocks> yeah, the issue is really nvidia-focused
[17:42] <didrocks> so, for that particular bug, which is quite annoying
[17:42] <didrocks> I can only say that daniel and I got this
[17:42] <didrocks> and we don't have the same card
[17:42] <didrocks> not sure if it's the driver making that for everyone or if we are just unlucky
[17:45] <apw> the issues on intel with that combination was that the driver is initialising from vga mode, regardless of actual mode so can sometimes leave thngs not initialised
[17:45] <apw> its probabally the same for nvidia
[17:52] <didrocks> hum, ok, make sense then
[17:52] <didrocks> well, just to keep that in mind so that we don't release in that state, or we will hear from it :)
[17:59] <apw> didrocks, likely its a grub thing we'll have to change, i'll open a task there
[18:00] <didrocks> apw: sure, just ensure that colin is ok with it, he told me to open a kernel task to first get feedback from your team :)
[18:01] <apw> didrocks, yep but as its prop-drivers they arn't in the kernel and we have exactly zero control over them
[18:01] <apw> our recommendation would be not to install them
[18:01] <didrocks> sure, but as we need 3D now :)
[18:01] <didrocks> and our nouveau doesn't support it well yet
[18:03] <apw> didrocks, not obvious why we need 3d but there you go
[18:03] <apw> given everything on my screen is basically 2d even with unity
[18:03] <didrocks> you need acceleration for the opengl effect
[18:09] <apw> didrocks, but there is the rub isn't it.  nothing in the interface needs 3d, the clever and inovative bits are not the fact its 3d, but that its touch ready and simple, and whatever else we claim
[18:11] <apw> didrocks, any idea what the prop-drivers are called source package wise
[18:11] <didrocks> apw: well, I think it's more something to talk with the dx team (compiz and unity guys) but they ensure that it's not possible to get the same effects with a 2D library like cairo and such, so they need acceleration
[18:11] <didrocks> apw: hum, one sec
[18:12] <apw> didrocks, <personal opinion> they are conflating the two things, being wizzy and doing things don't have to be the same </p.o>
[18:12] <didrocks> apw: nvidia-graphics-drivers
[18:12] <apw> but its not my call, and as noone will give me anything but intel h/w i am not affected anyhow :)
[18:12] <didrocks> :)
[18:20] <tgardner> apw, what do you think about CONFIG_CRYPTO_CRC32C=y for Natty to solve the lib/libcrc32c shash registration race (as well as an initramfs modprobe issue) ?
[18:21] <apw> if its tested to work it doesn't seem like a bad solution, we build in all of AGP for similar reasons
[18:21] <tgardner> see bug #681819
[18:21] <ubot2> Launchpad bug 681819 in linux (Ubuntu) "libcrc32c.ko does not declare dependancy on crc32c.ko (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/681819
[18:21] <tgardner> apw, do we have a boot speed profile? 
[18:22] <tgardner> 'cause I think building it in may have an impact
[18:23] <apw> tgardner, positive or negative ?
[18:23] <apw> we can make one both sides pretty easy to check
[18:23] <tgardner> apw, registering an shash algorithm performs some run time testing. dunno how much.
[18:23] <apw> tgardner, i wonder if we can hack that out, seems odd to test it every time you insert the module
[18:24] <apw> tgardner, bug i'll put it on my todo list to go and measure it
[18:24] <tgardner> apw, well, I'll turn it on for now and we can just measure it
[18:24] <apw> tgardner, ok
[18:29]  * JFo goes to dose up some more Vitamin C, brb
[18:37] <apw> JFo, ping
[18:42] <GrueMaster> Who can move linux-image-2.6.35-24.42-omap from New to maverick-proposed so I can properly test it?  It has been sitting for 3 hours and I have deadlines to get it tested.
[18:43] <JFo> apw, pong
[18:43] <apw> JFo, hows the list generation going
[18:44] <JFo> working out some kinks now
[18:44] <JFo> should have the list soon
[18:44] <JFo> well, the final list
[18:44] <apw> i am assuming we can have the tag oriented bits auto generating hourly or something today
[18:45] <JFo> should do
[18:46] <apw> did you fix up the script to add the tags ?
[18:46] <apw> s/tags/summary information/
[18:47] <apw> would it help to sit down with that script and talk through what all the bits mean
[18:50] <apw> JFo, ^^
[18:51] <JFo> yeah, I have that worked out
[18:56]  * GrueMaster has an ominous feeling that JFo's scripts will start spamming him...again.  :P
[19:04] <apw> GrueMaster, heh, no these are reporting scripts not spamming scripts :)
[19:04]  * apw finds its generally bjf who spams him
[19:04] <GrueMaster> Ah.  
[19:05]  * GrueMaster would like to see a report of how many scripts currently spam him.
[19:05] <GrueMaster> :P
[19:07]  * tgardner --> lunch
[19:13]  * cking --> calling it a day
[19:43] <bjf> tgardner, is bug #684448 just a tracking bug (looks like it is to me)?
[19:44] <ubot2> Launchpad bug 684448 in linux-lts-backport-maverick (Ubuntu Lucid) (and 1 other project) "Lucid LTS Maverick backport, security update to 2.6.35-23.41 (affects: 1) (heat: 10)" [Medium,Fix committed] https://launchpad.net/bugs/684448
[19:54] <JFo> IT's ALIVE!!!!
[19:54]  * JFo passes cigars out in celebration of the birth of a new script
[19:55]  * JFo puts it into a server labor camp immediately
[19:55] <JFo> :)
[19:58] <GrueMaster> Still need someone to publish linux-image-2.6.35-24-omap-2.6.35-24.42.
[20:09] <bjf> GrueMaster, there are no archive-admins on the kernel team
[20:16] <tgardner> bjf, yeah, that kind of looks like  a tracking bug
[20:16] <bjf> tgardner, cool, i'll tag it as such
[20:36] <smoser> stupid question. I just did a 'fakeroot debian/rules binary-virtual'. then a 'fakeroot debian/rules clean' and then binary-virtual again.
[20:36] <smoser> i had ccache first in my path, and i can see that ccache --show-stats is getting misses.
[20:36] <smoser> but i'm only getting misses even the second time. 
[20:37] <smoser> any idea what woudl be changing ?
[20:41] <tgardner> smoser, no idea. maybe time stamps or something are changing the object output.
[20:41] <smoser> yeah, thats what i'd have to suspec too, but that sucks.
[20:41] <tgardner> smoser, what is your cache hit percentage?
[20:42] <smoser> cache hit                              4
[20:42] <smoser> cache miss                         13000
[20:42] <smoser> what percent is that ? :)
[20:42] <tgardner> its bad...
[20:43] <tgardner> smoser, its so bad you might as well not bother.
[20:43] <smoser> yes, in fact almost certainly the ccache overhead is worse.
[20:44] <tgardner> smoser, I've used it for kernel builds with better results then that.
[20:44] <smoser> but it really "should work".  ccache is an awesome speed up for those of us withouth access to 64 way machines
[20:47] <tgardner> smoser, I'll run one of my builds twice to see what kind of hit rate I get
[20:55]  * jjohansen lunch
[21:42] <kees> apw: there were 2 problems with module NX. one was solved and I forwarded an email about it. but I think you'd mentioned something else? I want to track that down and see if it's been fixed yet.
[22:27] <kees> apw: ah-ha, found it. http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=commitdiff;h=691513f70d3957939a318da970987b876c720861
[22:43] <djalterego> I'm trying to isolate an nfs client issue to an Ubuntu component.  When testing using mainline kernels, should I use http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/ or http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.34-lucid/ since I'm using Lucid?