[01:17] <crimsun> bjf: please bump alsa-driver-cod-karmic.git for -20.33 in -updates
[01:31] <bjf> crimsun, sorry I missed that, will do
[01:31] <crimsun> bjf: rockin', thanks!
[01:32] <bjf> crimsun, give me a sec and I'll submit a new build
[01:36] <mozmck> I keep getting 4 off these errors: drivers/usb/core/hcd.c:144: error: expected expression before '>>' token
[01:36] <mozmck> all in hcd.c  when compiling karmic kernel from git.
[01:37] <mozmck> anyone seen this before?
[01:38] <JFo> mozmck, google is your friend
[01:39] <mozmck> couldn't find anything on it.
[01:39] <JFo> looks like a gcc issue maybe
[01:41] <JFo> hmmm, or perhaps something to do with how you are compiling it
[01:46] <mozmck> I don't know.  The time it worked I applied the patch I needed on master and compiled using "skipabi=true skipmodule=true no_dumpfile=true fdr binary-rtai"
[01:46] <mozmck> Then I created a flavour for my changes and did the same and I get the errors
[01:47] <mozmck> basically used the howto here http://blog.avirtualhome.com/2009/11/03/how-to-compile-a-kernel-for-ubuntu-karmic/
[02:57] <mozmck> ok, I don't get the error it seems if I don't try to make my own flavour
[02:58] <mozmck> when I try to install the headers package, it says I need linux-headers-2.6.31-21, which was not created.  how do I get this?
[03:01] <mozmck> forget that, I didn't run binary-indep :(
[14:26] <cnd> apw, I know this is hitting late, but do you have any thoughts on making hid a module?
[14:27] <apw> we need to review the generall building in policy.  i hope to upload drm today, then we'll have a window monday to review that and make changes in time for thursday
[14:28] <cnd> apw, sounds good
[14:28] <cnd> apw, also, looks like 2.6.33 fixes some nvidia (binary) driver issues
[14:28] <cnd> hopefully .33 drm contains the fix :)
[14:28] <apw> but yes its all getting squeeky tight round here
[14:29] <cnd> apw, if there's anything I can look at to help you out, let me know
[14:29] <cnd> I'm just browsing bugs
[14:29] <apw> cnd, wouldn't expect it to, drm is not used for nvidia binary driver as far as i know
[14:29] <cnd> apw, I can still hope can't I?
[14:29] <apw> heh you can ... 
[14:29] <cnd> either way, I directed them to the red ppa
[14:29] <apw> just don't bet any actual cash on it
[14:29] <apw> cnd good plan
[14:30] <cnd> and we can do some git bisecting to figure it out otherwise
[14:30] <cnd> always better to have upstream work than have only a regression from a previous release
[14:32] <apw> rtg some nice shiney new nvidia drivers just hit the archive
[14:32] <apw> cnd, may be of interest to you too
[14:33] <tgardner> apw, cool. I hope screen save starts working again
[14:33] <cnd> apw, rtg, they've been using them already I believe
[14:33] <cnd> these are the bugs where they still fail to resume in lucid (even after the chvt fix), and graphics corruption after resume
[14:34] <apw> oh where didi you get them from
[14:34] <cnd> I'm guessing they got them from nvidia
[14:35] <cnd> yep, looks like they got them directly from nvidia
[14:35] <cnd> they were perusing the changelogs to see if there was anything of note
[14:47] <tgardner> apw, do these KVM patches on the k-t list fix the regression that you and smb were looking at yesterday?
[14:47] <tgardner> the one kirkland was on about
[14:48] <smb> tgardner, Probably not. That was fixed by reverting another patch
[14:48] <apw> tgardner, the Pause-Loop ones?
[14:48] <apw> those are enablement
[14:48] <tgardner> apw, yeah, the pause-loop ones
[14:48] <tgardner> k
[14:49] <apw> and unrelated, i've reverted all the kvm ones in the security block till that is resolved
[14:49] <tgardner> k, I saw those and wondered
[14:49] <cnd> apw, where are manjo's suspend timing patches?
[14:49] <cnd> in a lucid kernel yet?
[14:50] <apw> in the next one i think
[14:50] <cnd> are they in a kernel ppa I can point someone at to test with?
[14:51] <JFo> probably his personal one
[14:51] <apw> cnd check the changelog for red, i think they are in there
[14:52] <cnd> apw, ok
[14:52] <apw> [15232.884115] PM: late suspend of drv:uhci_hcd dev:0000:00:1d.3 complete after 1000.073 msecs
[14:52] <apw> [15233.884098] PM: late suspend of drv:uhci_hcd dev:0000:00:1d.0 complete after 999.593 msecs
[14:52] <apw> ...
[14:52] <apw> [15234.680342] PM: resume of drv:i915 dev:0000:00:02.0 complete after 191.423 msecs
[14:52] <apw> even seems to work!
[14:53] <cnd> apw, yep, they're there
[14:53] <apw> cnd, thats a 'red' kernel so it must be there
[14:56] <cnd> has there been any thought as to pushing manjo's patch upstream?
[14:59] <apw> i've cleaned it up a lot, and likely whats there is upstreamable
[14:59] <apw> we have a bunch in there that i'll remind people about after freeze, i have a few myself
[15:00] <cnd> apw, ok
[15:00] <cnd> is this the general way things are done, get patches into ubuntu before freeze, then upstream them after when we have more bandwidth?
[15:00] <tgardner> cnd, not really, but we're in a time crunch right now.
[15:01] <cnd> tgardner: so we usually try to upstream in line with adding them to the kernel, but near freeze that may get delayed?
[15:01] <tgardner> cnd, exactly
[15:01] <cnd> ok
[15:02] <tgardner> cnd, for the simple reason that patches do not usually make it through the upstream review process intact, so its  management hassle to revert an old patch, then apply the new one.
[15:02] <cnd> yeah
[15:27] <amitk> apw: what are you planning on for making HID a module? (Re: MultiTouchScreen Support thread)
[15:28] <tgardner> amitk, we'll review it monday
[15:29] <amitk> ack
[15:31] <apw> perhaps we should have a mini-meeting on that subject monday ... and chose the things we thing arn't needed
[16:10] <mozmck> is there a document showing how to create a new kernel flavour for karmic?
[16:41] <manjo> mozmck, https://wiki.ubuntu.com/KernelTeam/KernelMaintenanceStarter
[16:45] <apw> mozmck, there was a new one added to lucid fairly recently which might help you get the right files
[16:58] <mozmck> apw: a new flavour?
[17:08] <tgardner> apw, https://bugs.edge.launchpad.net/ubuntu/+bug/531981/comments/6
[17:08] <ubot3> Malone bug 531981 in ubuntu "[MIR] linux-qcm-msm" [Undecided,Fix committed] 
[17:09] <apw> yeha i see it has been approved, though still awaits someone to actually do it
[17:10] <tgardner> apw, I'll see about annoying the archive admin du jour
[17:48] <manjo> apw, after an upgrade on my MIni10V booting up with out splash works, but with splash it boots to a black screen with grabage chars on it 
[17:50] <apw> manjo, which upgrade
[17:50] <manjo> apt-get distupgrade
[17:50] <apw> may be 'luck' you may n
[17:50] <apw> need to test it a few times
[17:50] <apw> mine is current as of a hour ago and boots ok
[17:55] <manjo> apw, are you running red on your 10v ? 
[17:55] <apw> i am yes
[17:55] <manjo> s**t
[17:55] <apw> though i have just booted to -15 and that works too
[17:55] <manjo> 32-16 ? 
[17:56] <manjo> works for you ? 
[18:07] <manjo> apw, I just emailed you a screen shot of what it looks like when it boots 
[18:12] <manjo> apw, ok I found another thing ... while its booting if I press the shift key when it displays the splash screen it boots to gdm
[18:12] <manjo> apw, otherwise I get what I showed you in the mail 
[18:13] <tgardner> manjo, have you tried removing plymouth to see if its causal?
[18:13] <apw> manjo, i see that about one in 10, and suspect plymouth racyness
[18:13] <apw> hitting ctrl i think did it for me
[18:14] <manjo> apw, also hitting enter on that blank screen also launched gdm
[18:14] <manjo> tgardner, definitely looks like plymoth
[18:14] <manjo> tgardner, removing splash it boots ok 
[18:16] <tgardner> manjo, I've found tat it really sucks to have nVidia and plymouth
[18:16] <manjo> tgardner, but this is on intel unfortunately
[18:16] <tgardner> ah, that sucks even more since it _should_ work
[18:16] <apw> faster machines hit it i think
[18:17] <apw> we know there are plymouth issues outstanding
[18:18]  * manjo is not digging the new color scheme either .. turned his windows purple 
[18:19]  * manjo does hates that fact that all the buttons 0 - X are now on the left .. 
[18:20] <cnd> what's the best way to do a git bisect on a mainline kernel?
[18:20] <bjf> manjo, which theme are you using, I'm using "Ambiance" and the buttons are on the right
[18:20] <manjo> bjf, did you upgrade today ? 
[18:21] <cnd> is there some sort of debianized way of doing them?
[18:21] <bjf> manjo, yes
[18:21] <manjo> you probbly asked it to keep the original gnome cof 
[18:21] <manjo> conf
[18:21] <manjo> I asked it to replace it 
[18:22] <bjf> manjo, no they were on the left and now are on the right, I'll update again
[18:23] <tgardner> cnd, likely the easiest way is to just copy a prepared config, then build the normal way.
[18:26]  * manjo out for lunch & phy therapy
[18:28] <bjf> manjo, mine flipped back to the left again
[18:28] <bjf> I guess the design team thinks they work for apple
[18:35] <cnd> tgardner: is there anything special I need to do about an initramfs though?
[18:35]  * cnd is used to doing everything manually ala gentoo
[18:37] <tgardner> cnd, dunno, I've not done much outside of the debian way lately. you may be veering into uncharted waters.
[18:38] <cnd> tgardner: hrm... well, I'll try stuff out and update wikis if needed
[18:46] <cnd> tgardner: I should have looked on the wiki earlier, I think everything I need is there
[18:52] <tgardner> apw, I'm working on an LBM firmware borkage, so don't go uploading it over the weekend before I push a patch.
[18:54] <apw> tgardner, ok ... i was literally just about to drop it in the queue
[18:54] <apw> i think we'll do another upload on tuesday for the HID etc changes so it could go in with those
[18:55] <apw> i'll hold it for now anyhow, so get it to me as soon as you can as i'll be watching the upload over the weekend as it builds
[18:55] <tgardner> apw, somehow we lost the iwlwifi firmware bits. still investigating.
[18:55] <apw> probabally my fault when i updated wireless to the 2.6.33 bits
[18:56] <tgardner> apw, i dunno, the firmware stuff should be version independent
[18:56] <apw> but if it was in the wireless directory i may have stamped on it by accident
[18:56] <tgardner> apw, no, the bits are in the firmware directory, so no clobber there
[18:57] <apw> fair enough
[18:57] <tgardner> apw, ah, here is the issue: /lib/firmware/2.6.32-15-generic
[18:57] <tgardner> they should go into  just /lib/firmware
[18:58] <tgardner> its just packaging
[18:58] <apw> how can they they would conflict release to release
[18:58] <apw> or do they 'replace' each otehr?
[18:58] <tgardner> apw, lbm-iwlwifi-4965-2.ucode v.s. iwlwifi-4965-2.ucode
[18:58] <tgardner> note the prefix
[18:58] <apw> no i mean if we have -15 and -16 of LBM installed at the same time
[18:59] <apw> tgardner, i have pushed up my updated LBM tree which you probabally should base of
[18:59] <tgardner> good point. 
[18:59] <apw> base off, as i changed the packaging to get rid of nouveau
[18:59] <tgardner> k, I'll just change the driver swizzling to add the right path
[19:00] <apw> perhaps i lost some swizzling in my changes
[19:00] <tgardner> apw, no biggie, I'll have it figured out in a bit. I even have HW to test it on.
[19:01] <apw> tgardner, if you get it done tonight send it out and i'll pull it in in the morning ... i want this stack done by monday if i can
[19:01] <tgardner> apw, will do.
[19:01] <apw> cool ... /me wanders off to find food
[19:07] <cnd> tgardner: I think they should still be in /lib/firmware/`uname -r`
[19:08] <cnd> apw ^
[19:08] <cnd> if you look in /lib/udev/firmware.sh, it's smart enough to go looking there too
[19:08] <tgardner> cnd, nah, you can have multiple LBMs installed and you are not allowed to trash files from another package
[19:08] <cnd> and I think firmware under that directory comes from linux-image
[19:09] <cnd> hmmm... let me read the backscroll more carefully
[19:09] <tgardner> cnd, actually, I misread your comment. 
[19:09] <tgardner> maybe I should review my udev rules.
[19:10] <tgardner> cnd, where did you find that firmware udev rule in the bug report yesterday?
[19:10] <cnd> the rule itself is /lib/udev/rules.d/50-firmware.rules I think
[19:11] <cnd> but what you are probably interested in more is /lib/udev/firmware.sh:
[19:11] <cnd> FIRMWARE_DIRS="/lib/firmware/updates/$(uname -r) /lib/firmware/updates \
[19:11] <cnd>                /lib/firmware/$(uname -r) /lib/firmware"
[19:11] <cnd> so lbm packages (I think this is what you're looking at?) should be putting them into /lib/firmware/updates/$(uname -r)
[19:11] <tgardner> cnd, hmm, I only have a binary /lib/udev/firmware
[19:12] <cnd> tgardner: what's your rule in 50-firmware.rules?
[19:12] <cnd> are you running karmic?
[19:12] <tgardner> cnd, lucid
[19:13] <cnd> tgardner: I've been working in karmic, as was the e100 issue
[19:13] <cnd> maybe it's changed?
[19:13] <tgardner> cnd, looks like
[19:14] <cnd> yep, I'm taking a look at my lucid partition
[19:15] <cnd> tgardner: how much you want to bet firmware.sh was made native for boot speed :)
[19:16] <tgardner> cnd, ./udev-151/extras/firmware/firmware.c
[19:17] <cnd> tgardner: still looks like the same paths are used
[19:17] <tgardner> cnd, looks like the search paths are /lib/firmware/updates/ and /lib/firmware/
[19:17] <cnd> tgardner: with the possibility of the kernel release added on
[19:17] <cnd> tgardner: http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=extras/firmware/firmware.c;h=16455dec8f3299ef2283ce1382ad1cb1d99a0cb4;hb=HEAD#l137
[19:17] <cnd> or just look at line 137
[19:18] <tgardner> cnd, so, you think it'll decend into  /lib/firmware/updates/ ?
[19:18] <tgardner> ah, yuo're right
[19:18] <tgardner> I can test that soon enough
[19:18] <cnd> tgardner: so that's everything you needed to fix your issue?
[19:19] <tgardner> cnd, I think so. I'll know soon enough
[19:19] <cnd> cool
[19:35] <tgardner> cnd, since you're fresh on udev, remind me how to enable debug. 
[19:36] <cnd> tgardner: https://wiki.ubuntu.com/KernelTeam/Firmware :)
[19:36] <tgardner> tahts right, I remember seeing your page go by
[19:36] <cnd> let me know if there's any other info you need or if something's not clear
[19:37] <cnd> I suppose it will need to be updated for lucid...
[19:40] <Keybuk> tgardner: udev should look in /lib/firmware/updates/$(uname -r)/FW
[19:42] <tgardner> FW?
[19:43] <tgardner> Keybuk, oh, you mean /lib/firmware/updates/2.6.32-15-generic/lbm-iwlwifi-4965-2.ucode
[19:43] <Keybuk> yes
[19:44] <tgardner> Keybuk, the log shows FIRMWARE=lbm-iwlwifi-4965-2.ucode, so the names appear to be correct
[19:45] <tgardner> lemme make sure it can find it if I copy to /lib/firmware
[19:46] <cnd> tgardner: Keybuk: what's going wrong?
[19:46] <cnd> the firmware is in the right place, but still isn't getting loaded?
[19:49] <tgardner> cnd, shit, I may have trashed my drive.
[19:49] <cnd> tgardner: heh, how'd that happen?
[19:50] <tgardner> modprobe -r iwlagn, then hard power cycle after it wedges
[19:50] <tgardner> even recover locks up
[19:50] <tgardner> recovery*
[19:51] <tgardner> it must suddenly be lunch time
[19:51] <cnd> tgardner: boot from an iso and fsck?
[19:51] <cnd> tgardner: if you want me to look into an issue for you while you fix your drive let me know
[19:52] <tgardner> cnd, I'll get it figured out eventually. don't worry about it
[19:52] <cnd> ok
[20:24] <cnd> apw: how is your mainline ppa generated?
[20:25] <cnd> I'm wondering if we should have a compat-wireless mainline ppa as well for people to test with
[22:22] <manjo> bjf, looking for me ?