[02:15] <kees> bjf: lucid linux-ec2 changelog shows release tracking bug as 712864, but that bug has nothing to do with the kernel? should that be 716657 ?
[02:16] <bjf> kees, i'll look, thanks for the heads-up
[02:16] <kees> bjf: cool; thanks.
[02:23] <bjf> kees, where do you see 712864 as the tracking bug, i'm looking at the changelog in the kernel tree and it shows 716657
[02:25] <bjf> kees, i see it
[02:26] <bjf> kees, i don't know how that happened, but i can guess, and it was very sloppy work on my part
[02:27] <bjf> kees, thanks again for pointing it out though
[02:39] <anon^_^> anyone able to address my question?
[03:06] <MTecknology> If you were to compile a kernel that was completely monolithic vs using a lot of modules.. when you boot is the longer wait time only in loading the entire kernel into memory; or is there a lot of extra processing that needs to be done?
[03:09] <ohsix> modules builtin will be initialized, modules will be loaded on demand and only initialized when that happens, it's not a huge difference but it is a difference
[03:13] <MTecknology> so there is extra load time for built-in modules if you're not going to frequently use them?
[03:16] <MTecknology> ohsix: thanks :)
[04:54] <jjohansen> MTecknology: actually, it depends.  Modules have linking overhead, and if you are talking about loading modules from the initramfs then builtin is definitely faster
[04:55] <MTecknology> jjohansen: I don't use an initrd though
[04:55] <jjohansen> well that you won't have that added problem to consider
[04:57] <MTecknology> jjohansen: I have a 2.2MB monolithic kernel; I was just wondering if I'm losing by having monolithic and changing some things to loadable modules would be a better idea.
[04:59] <jjohansen> MTecknology: it will just depend, on when it gets used etc. /me likes the flexibility of modules,
[05:01] <MTecknology> jjohansen: I've been kind of sad though... having to stick with -rc2. When I try anything newer X won't start. I see -rc7 has been released; so I think it's time to try that. :)
[05:02] <MTecknology> I know there have been a lot of changes with intel video
[05:02] <jjohansen> MTecknology: yeah, I just tried my machine that display won't work, its still a no go for me
[05:02] <MTecknology> intel video?
[05:03] <jjohansen> yep
[05:03] <jjohansen> I hear some are now working, mine isn't
[05:03] <MTecknology> I hope I have more luck than you then... but i doubt it
[05:05] <MTecknology> I wish I could use acpi -t too :(
[05:11] <anon^_^> anyone able to address my question?
[05:11] <anon^_^> are there issues persisting with latest kernel updates for 10.04 in update manager?
[05:11] <anon^_^> http://img121.imageshack.us/img121/1092/oopsd.jpg
[05:12] <anon^_^> placeholder values for linux kernel are showing up, but not the binaries
[05:12] <jjohansen> anon^_^: not that I know of
[05:13] <anon^_^> jjohansen, so why would placeholders show up as an update but not the actual kernel files
[05:13] <jjohansen> anon^_^: have you tried dropping to the terminal and doing apt-get update, apt-get dist-upgrade
[05:14] <anon^_^> no
[05:14] <jjohansen> anon^_^: sorry I really don't know
[05:17] <jjohansen> anon^_^: try forcing a refresh, hit the check button
[05:18] <anon^_^> refreshed update manager a few times, same result
[05:18] <jjohansen> anon^_^: what sources do you have?
[05:18] <anon^_^> can't select the placeholders for the new kernel 2.6.32.29.35
[05:19] <anon^_^> default sources, no change
[05:19] <anon^_^> added some ppa repos, but nothing that influences the kernel
[05:19] <jjohansen> anon^_^: x86 or x86_64
[05:20] <anon^_^> x86_64
[05:20] <anon^_^> presently running 2.6.32-28-generic
[05:20] <jjohansen> okay, I'll see if I have a lucid around that needs updating
[05:21] <anon^_^> the new kernel placeholders showed up with updates this morning
[06:29] <anon^_^> well that is interesting, when I unchecked docky-core ppa from other software in sources list and then refresh, i suddenly see kernel update files
[06:29] <anon^_^> http://ppa.launchpad.net/docky-core/ppa/ubuntu
[06:29] <anon^_^> was the ppa that i unchecked from sources list
[06:52] <anon^_^> after deselecting docky-core ppa
[06:52] <anon^_^> http://img52.imageshack.us/img52/9138/itworksnow.png
[06:52] <anon^_^> anyone have an idea of why that would occur?
[06:53] <RAOF> anon^_^: Because you've updated the apt lists, and the missing packages have now been added?
[06:55] <anon^_^> when docky-core ppa was included
[06:55] <anon^_^> http://img121.imageshack.us/img121/1092/oopsd.jpg
[06:56] <anon^_^> RAOF, why would apt lists not show kernel updates when a dock ppa is selected
[06:56] <anon^_^> the dock shouldn't change kernel dependencies
[06:57] <RAOF> It won't, but when you removed the docky PPA you also updated the apt lists.
[06:57] <RAOF> (As in: the locally cached list of packages available in the archive)
[06:58] <anon^_^> so RAOF, if i re-enable docky-core ppa in sources list
[06:58] <anon^_^> and refresh, it shouldn't interfere
[06:59] <anon^_^> yes?
[06:59] <RAOF> Indeed.
[06:59] <anon^_^> well that's not the case
[06:59] <anon^_^> because i just re-enabled the docky-core ppa, and the output for update manager
[07:00] <anon^_^> is the same as it was before
[07:01] <anon^_^> i installed linux-libc-dev because i could
[07:02] <anon^_^> then disabled docky-core ppa refreshed
[07:02] <anon^_^> output showed all kernel updates
[07:02] <anon^_^> http://img52.imageshack.us/img52/9138/itworksnow.png
[07:03] <anon^_^> go back and re-enable docky-core ppa in sources list
[07:03] <anon^_^> update sources list
[07:03] <anon^_^> http://img843.imageshack.us/img843/1320/somethingsfishy.png
[07:03] <anon^_^> and it's blocking kernel updates again
[08:10] <fairuz> any special channel I have to join for Perf tool related problems?
[08:14] <apw> perf is shipped as part of the kernel
[08:24] <fairuz> I have this error when I try to use perf stat : Consider tweaking /proc/sys/kernel/perf_event_paranoid
[08:24] <fairuz> taht is when I try to collect caches miss data
[08:27] <fairuz> i tried this command perf stat -e L1-dcache-load-misses echo "test"
[08:29] <jjohansen> apw: this is a screen shot of anon^_^'s failure : http://img121.imageshack.us/img121/1092/oopsd.jpg
[08:31] <fairuz> i tried the command with verbose, and it sais I dont have the permission. So, I tried with sudo and now It says Error counter 0 , sys_perf_event_open() syscall returned with -1 (no such device)
[08:31] <fairuz> *says
[08:32] <apw> fairuz, hmmm never seen that myself
[08:32] <apw> bug #662009
[08:32] <ubot2> Launchpad bug 662009 in alsa-driver "[Lenovo Y530 - Realtek ALC888] Regression from 10.04: No sound with snd_hda_intel model=lenovo-sky" [Undecided,Triaged] https://launchpad.net/bugs/662009
[08:32] <fairuz> I'm running ubuntu on ARM, maybe Perf not supported on ARM platform?
[08:33] <apw> its cirtianly likely that differnet sub-sets of fucntionality are missing yes, they may not yet expose any physical counters
[08:33] <fairuz> hmm ok
[08:35] <fairuz> are you running on x86? can you try the command and see if it come out with cache miss?
[08:35] <fairuz> perf stat -e L1-dcache-load-misses echo "test"
[08:36] <apw>               15419  L1-dcache-load-misses   
[08:36] <apw> seems to work on my intel box yes
[08:36] <fairuz> hmm ok
[08:37] <fairuz> apw: thanks anyway
[08:37] <apw> if you are using arm specifically you might also ask in #ubuntu-arm, they may have more specific knowledge 
[09:28] <Specialist> Hi there! I am currently running 2.6.35 on Ubuntu 10.10 and am considering switching to 2.6.38, which would allow me to use my second video card (which is detected by 2.6.38's nouveau driver, but not by the one from 2.6.35). Are there any pitfalls that I should be aware of? Maybe even some pre-built packages (I have found only packages for 10.04 so far)?
[09:29] <apw> Specialist, it is a common combination for those of us in the kernel-team so it might be expected to work
[09:29] <apw> but its not supported, and as you note there arn't any official packages for that combination
[09:33] <Specialist> Thanks! So I guess compiling it from the git repo is the way to go...
[09:36] <smb> Specialist, You can just use the deb packages of the kernel for Natty
[09:46] <kengyu> smb, good morning. for the eeepc SRU patchset I sent yesterday, two of them (from Corentin Chary) are too new and not yet in mainline, but they're already in mjg59's linux-next branch (http://git.kernel.org/?p=linux/kernel/git/mjg59/platform-drivers-x86.git;a=shortlog;h=refs/heads/linux-next). Since rtg is asking for commit SHA, do you think if it is okay to leave it blank or any preferable way you'd kindly suggest? :-)
[09:49] <smb> kengyu, Well _usually_ you should wait until things _are_ in Linus tree before requesting SRU. (at least imho)
[09:50] <smb> kengyu, Are the changes at least in the official linux-next tree?
[09:53] <kengyu> smb, yes, they are. I suppose you already know patches from me are usually for some reasons. :-/
[09:56] <smb> kengyu, Of course I do not question that they are there for a good reason. Being poking you about them being upstream is more because I want to avoid things getting lost. And us ending up on having working Maverick but not in Natty
[09:57] <smb> kengyu, So if they are in linux-next, then at least add those commit shas and reference to linux next
[09:57] <smb> Like: (cherry-picked from commit x linux-next)
[10:02] <kengyu> smb, appreciated for the suggestion. another question is that if we do use "[Upstream]" in the subject? from debian/commit-templates/upstream-patch, there it is. Though the commit sha is not really mentioned there.
[10:26] <fairuz> a stupid question.. i included arch/arm/include/asm/hardware/cache-l2x0.h in my code..but why I cant use the functions defined in arch/arm/mm/cache-l2x0.c
[10:29] <fairuz> i got l2x0_init undefined error
[10:36] <smb> kengyu, Hm, I am not sure whether we probably need to update the templates. I personally would not use anything in the subject/commit message than is in the upstream version and only modify the content of the message with BugLink and sob and sha reference
[10:40] <apw> yeah [Upsream] does seem to have become redundant these days
[10:40] <apw> as we use the presence of an upstream commit id as that indication now
[10:41] <kengyu> smb, I think I can just follow your convention. :-) I will re-send the patches later. now we have 2-week SRU cycle, is there any regular day for the upload, eg always upload on Fri, any SRU patch after that should wait for the next cycle.
[10:43] <smb> kengyu, I believe that it seems to happen on Fridays. But you want to ask Steve there. I am not paying that much attention to the details anymore. :)
[10:43] <kengyu> apw, will it be a good idea to update the debian/commit-templates/upstream-patch  to reflect current kernel team's convention?
[10:44] <apw> yeah it would ... will add it to the agenda for next week, as we'll be teaching people to use them :)
[10:47] <apw> added to the agenda
[10:48] <kengyu> smb, sure. thanks for the nice answering. you're appreciated as usual. :-)
[10:49] <kengyu> apw, thanks for that. saw your wiki update. :-)
[10:50] <smb> kengyu, You are welcome. I try to be as helpful as one being as anal as me can. ;-)
[10:52] <kengyu> smb, no need to try, you're always helpful. thanks again anyway. :-)
[11:04] <lag> When you use "fdr binary-arch" the build udebs and debs are placed in .. - is there any way to configure that?
[11:04] <lag> Also, how do you tell the fdr not to build a million udebs
[11:15] <lag> apw: ?
[11:15] <apw> lag, nope thats where they go
[11:15] <apw> binary arch is designed to build everything
[11:15] <apw> that includes the udebs
[11:16] <apw> but you ony get those cause you asked for them in kernel_versions.in
[11:16] <lag> apw: So to get the image*.deb I use binary?
[11:16] <apw> nope
[11:17] <lag> apw: So to get the image*.deb I use?
[11:17] <apw> disable_d_i=true binary-arch
[11:17] <lag> That'll do - thanking you
[11:17] <apw> or if its one flavour, simply binary-<flavour>
[11:18] <lag> I don't have a u8500 flavour
[11:18]  * apw wonders if lag remmbers anything we taught him
[11:18] <apw> lag, you must have cause you make a -u8500 package
[11:18] <lag> I know what I used to use fdr binary-omap3/4
[11:18] <apw> it was listed as the flavour in your xorig.log earlier
[11:18]  * lag checks
 I'm using Linux version 2.6.35-1000-u8500
[11:19] <apw> u8500 in that context is the flavour name
[11:21] <lag> I could have sworn I tried fdr binary-u8500 and it couldn't find the flavour
[11:21] <lag> I build the packaging, so I guess I should know
[11:21] <lag> built*
[11:21] <lag> Hmm... it seems to work now
[11:21] <lag> That'll do me, thanks apw
[12:17] <apw> sconklin-gone, bjf, the tag for hardy maverick is missing
[12:17] <apw> sconklin-gone, bjf, the tag for hardy _master_ is missing
[14:55] <skaet_> apw,  thanks!
[14:55] <apw> skaet_, ?
[14:56] <skaet_> comments in the TechOverview. :)
[14:59] <tgardner> apw, mumblwe
[15:00] <apw> tgardner, there
[15:00] <apw> skaet_, ah
[15:33] <sconklin-gone> apw: did you tag hardy? 
[15:38] <apw> sconklin, nope, was assiming it was sitting in your tree
[15:39] <sconklin> it was. I just got a strange warning when I tried to push it to the master. But it's all resolved and pushed now
[16:44] <JFo> <-lunch
[17:02] <tgardner> sconklin, I'm not really in favor of another mailing list. why isn't the existing kernel team list sufficient?
[17:03]  * apw wonders what it is for
[17:03] <smb> tgardner, Though I just pushed the additional patchset to 2.6.32.30, I would not announce it yet as it seems to need the swiotlb patch reverted. Otherwise compile breaks.
[17:03] <sconklin> tgardner: because this includes people from qa, cert, archive admins, release managers, etc
[17:03] <tgardner> sconklin, and they can't subscribe to the k-t list?
[17:04] <sconklin> tgardner: no. too much traffic and not specific enough
[17:04] <bjf> tgardner, there is more noise in that mailing list that they don't want to deal with
[17:04] <tgardner> thats what filters are for
[17:05] <bjf> tgardner, one of the issues with the new cadence is the difficulty of clearly handing things off between the different parties and clearly communicating what is happening, this addresses those concerns
[17:05] <bjf> tgardner, some of them anyway
[17:06] <tgardner> bjf, I don't think a mailing list is a good method for state management. Isn't that what LP is supposed to do?
[17:06] <bjf> tgardner, it's not handling that part its to help with clearer communication of kernel sru work/issues
[17:08]  * smb -> away to buy a new power supply
[17:16] <tgardner> sconklin, bjf: gimme some examples of the kinds of messages you intend to send on this mailing list.
[17:16] <sconklin> just sent one
[17:17] <sconklin> Will be sending another one soon about copying packages from ppa to proposed
[17:18] <vish> apw: hi.. poking about Bug 652934 again ;) , can we get that SRU milestoned.. all testing work has already been done, we just need to upload it :)
[17:18] <ubot2> Launchpad bug 652934 in linux "[RV515] Guest session causes screen to flicker violently and session is unusable" [Medium,Confirmed] https://launchpad.net/bugs/652934
[17:18] <vish> apw: also, we should probably look into dropping that patch from natty too..
[17:19] <bjf> tgardner, there was an issue with ec2 kernel which we wanted all the relevant folks to know about which was holding up maverick from moving to updates, that email would have gone to that mailing list
[17:19]  * vish noticed that we got a kernel update this week, and was hoping this bug would have been included ;)
[17:21] <bjf> vish, if you subscribed to the kernel team mailing list you'd have a clearer idea if any given patch had been submitted for sru and if it had been accepted
[17:22] <apw> vish, that commit is gone from natty as far as i can see
[17:22] <vish> bjf: ah, cool! but i'm not that list yet.. :)
[17:23] <vish> apw: about the SRUs for lucid & maverick? (atleast maverick as I'm still on it ;p)
[17:24] <vish> i did test your lucid kernel too 
[17:24] <apw> vish will look
[17:24] <vish> thanks.. :)
[17:35] <tgardner> bjf, it seems to me that ubuntu-devel would be appropriate for emails of that nature, e.g., "Lucid and Maverick EC2 kernels still lack verification". It should reach all concerned parties, its a well known list, _and_ you don't have to subscribe the key players 'cause they're already there. Starting a new list cuts out a big chunk of the public.
[17:42] <sconklin> tgardner: well, this was discussed among the people who actually tale action items from the sru kernel process. I included you more for your information than anything else. So I think it's serving the needs of the stakeholders in a reasonable way
[17:42] <sconklin> s/tale/take/
[17:55] <apw> vish ok patches submitted to the lists for revieww
[17:55] <vish> apw: thanks.. :)
[18:35]  * tgardner --> lunch
[19:04] <bdmurray> I really don't see much relevant information in https://wiki.ubuntu.com/Kernel/LinuxWireless other than the link to upstream documentation
[19:21] <JFo> well that was interesting
[19:41] <kamal> apw: fyi that mem=nopentium panic fix that I sent upstream landed in linux-next but does not appear in 2.6.38-rc7 ...  maybe it won't hit mainline until 2.6.39 (?)
[19:51] <kees> tgardner: hi, if it's not already on your TODO list, can you take a look at bug 707577 for pitti's questions?
[19:51] <ubot2> Launchpad bug 707577 in linux-meta-lts-backport-maverick "Lucid LTS Maverick backport, update to 2.6.35-25.44" [Undecided,In progress] https://launchpad.net/bugs/707577
[19:52] <tgardner> kees, otp, gimme a bit
[19:53] <kees> tgardner: sure, no rush. I added the "kernel-tracking-bug" tag to that bug too, since I didn't see it in the sru-report.
[20:03]  * jjohansen -> lunch
[20:55] <rick_h_> howdy, wanted to check in and see if anyone was familiar with this failed to get i915 symbols, graphics turbo disabled issue that seems to be going around in 10.10?
[20:55] <rick_h_> upgraded and having display issues: http://askubuntu.com/questions/28730/upgrade-wont-allow-second-display-to-go-to-1920x1080
[20:56] <rick_h_> and stumbled upon a bunch of bugs, this one lends me hope a kernel upgrade might fix? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/651104
[20:56] <ubot2> Launchpad bug 651104 in linux "intel graphics turbo disabled" [Undecided,New]
[20:56] <rick_h_> but nervous of just dropping in some linked kernel/etc
[21:22] <sforshee> rick_h_, yeah, looks like you'd need to upgrade to kernel version 2.6.37 for the turbo mode fix, but I don't know if that will fix the screen resolution problem
[21:24] <sforshee> rick_h_, which linked kernel are you referring to?
[21:40] <apw> JFo, about ?
[21:41] <JFo> apw, yessir
[21:41] <apw> got time for a chat ?
[21:41] <JFo> sure, though I am in the hammock and my headset is inside :-D
[21:41] <JFo> want me to grab it?
[21:42] <apw> JFo, sure :)
[21:42] <JFo> brb
[21:48] <pmathews> I'm having problems with git:
[21:48] <pmathews>  git clone git://git.omapzoom.org/kernel/omap.git 
[21:48] <pmathews> Initialized empty Git repository in /home/pmathewslocal/DB-117/omap/.git/
[21:48] <pmathews> remote: Counting objects: 2021581, done.
[21:48] <pmathews> remote: Compressing objects: 100% (318816/318816), done.
[21:48] <pmathews> remote: Total 2021581 (delta 1686376), reused 2019306 (delta 1684356)
[21:48] <pmathews> Receiving objects: 100% (2021581/2021581), 430.22 MiB | 600 KiB/s, done.
[21:48] <pmathews> error: inflate: data stream error (invalid distance too far back)
[21:48] <pmathews> fatal: serious inflate inconsistency
[21:48] <pmathews> fatal: index-pack failed
[21:49] <pmathews> I have tried 4-5 times to clone the kernel but get this same error every time
[21:52] <sconklin> pmathews: have you tried cloning from any other repo? (just to see whether it's a local problem or one with the remote repo)
[22:02] <dorpsgek> hi
Give me an alternative repo please
[22:03] <dorpsgek> why is /dev/dsp taken from the kernel, it cannot be the size of the module, i have to compile a new kernel every new kernel update
[22:05] <sforshee> pmathews, I cloned that repository without issue, may be a local problem
[22:05] <sconklin> pmathews: git://kernel.ubuntu.com/ubuntu/ubuntu-lucid.git for example
[22:09] <rick_h_> sforshee: http://kernel.ubuntu.com/~manjo/maverick/lp651104/ was what I was checking out
[22:09] <rick_h_> that's still .35 though
[22:10] <rick_h_> sforshee: so the debate now is, how best to approach this. Should I just test a natty alpha? Is it a later kernel? (haven't looked yet)
[22:10] <rick_h_> go back to LTS and wait it out
[22:11] <rick_h_> or best way to get a .37 kernel that won't cause me issues with anything else going forward with 10.10
[22:13] <dorpsgek> ok, i think it will be goodbey for ubuntu, it is no fun to compile everytime a new kernel for this
[22:13] <herton> dorpsgek, oss is disabled in the kernel, I think since bug 579300
[22:13] <ubot2> Launchpad bug 579300 in linux "Please disable CONFIG_SOUND_OSS* and CONFIG_SND_*OSS*" [Wishlist,Fix released] https://launchpad.net/bugs/579300
[22:15] <sforshee> rick_h_, manjo's kernel should be safe to try, but natty is using .38 so it will have the fix
[22:16] <rick_h_> ok, I'll give a usb boot a test then tonight. Thanks
[22:16] <sforshee> np
[22:18] <dorpsgek> herton: to disable something without a (good) replacement is not nice
[22:20] <mjg59> dorpsgek: There's been a good replacement for it since 2002
[22:21] <apw> dorpsgek, and pulse is meant to supply a replacement
[22:21] <apw> that is why it was disabled
[22:22] <dorpsgek> ut2004 --> open /dev/[sound/]dsp: No such file or directory    etc....................
[22:23] <dorpsgek> during DOOM 3 initialization...
[22:23] <dorpsgek> WARNING: failed to open sound device '/dev/dsp': No such file or directory  etc...............
[22:24] <dorpsgek> so for a lot of stuff what people can use to have some fun
[22:24] <kees> dorpsgek: OSS devices were eliminated a while back. perhaps try using "padsp /your/command"
[22:25] <JFo> <-headset battery finally died.
[22:25] <dorpsgek> ok, ik know what to do, thanx for the support
[22:26] <dorpsgek> is there a way to blacklist kernelupdates
[22:34] <apw> probabally can pin: the kernel
[22:53] <kees> bjf, sconklin: regression in 2.6.32-29? bug 727653
[22:53] <ubot2> Launchpad bug 727653 in linux "initrd.img-2.6.32-29-generic breaks iwlwifi-6050" [Undecided,New] https://launchpad.net/bugs/727653
[22:53] <apw> kees, beat me to it :)
[22:54] <kees> apw: :)
[22:54] <kees> it doesn't look to bad, maybe a bad dkms hook or something? not really sure
[22:55] <sconklin> kees: thanks for letting us know. I wonder if we have any of this hardware
[22:57] <apw> sconklin, it looks like a firmware load failure
[22:57] <jsalisbury> sconklin, I have this laptop with this wireless card, I plan on applying updates on Friday, so I guess my wireless will break :-O
[22:57] <apw> was there anything like that in the changes in -29 ?
[22:58] <apw> otherwise it might be a firmware updare issue ... we might want to check they didn't get a firmware version update
[22:58] <apw> as in a linux-firmware package
[22:58] <bjf> apw, there is one sitting in -proposed
[22:58] <bjf> apw, a linux-firmware
[22:59] <JFo> my connection has gotten fragile, thanks for looking bjf, sconklin, apw :)
[22:59] <apw> any idea what is changed in it bjf ?
[23:00] <bjf> apw, looks like some new firmware, i need to pull the sources and look
[23:00] <jsalisbury> sconklin, Actually, I'm running Natty, so I can't test.
[23:00] <apw> see if those new names are in there
[23:00] <apw> Mar 2 03:47:28 cogito kernel: [ 109.671281] iwlagn 0000:02:00.0: firmware: requesting iwlwifi-6050-3.ucode
[23:00] <apw> it looks for -4, -3, -2, -1 in that order
[23:03] <bjf> apw, i see iwlwifi-6050-4.ucode but no -3, -2, -1
[23:03] <apw> bjf, in the new one?
[23:04] <apw> or in the old one
[23:04] <bjf> apw, yes the one in -proposed
[23:04] <apw> wahts in the current one ....
[23:04] <bjf> apw, well the git repo actually
[23:07] <apw> bjf, worth asking if the firmware is on their machine, the updates to l-f don't appear to change anything
[23:07] <apw> on those filenames
[23:09] <bjf> apw, the lucid firmware package in updates has:   * iwlwifi: 41.28.5.1 iwlwifi-6050-5.ucode      in the changelog
[23:10] <apw> oh crap looking at the wrong branch
[23:11] <bjf> brb
[23:13] <apw> bjf, not really sure why its not there the -4 as it is on maverick
[23:15] <apw> i suspect we need that adding in, just not sure why we suddenly are missing it
[23:15] <apw> but its only one piece of h/w so i think we can get tim to look at it in the mornign
[23:21] <apw> bjf i think we should get the user to try manually installing the -4 firmware
[23:22] <apw> and see if things work, if so then we can add it to the package tmrow
[23:22] <apw> sconklin, ^^
[23:23] <sconklin> sounds reasonable.
[23:23] <sconklin> I'll update the bug
[23:23] <apw> sconklin, it seems to be in the maverick branch, ie there is -4 and -5 in there, but the lucid only has -5 which seems counter intituitive at best
[23:24] <apw> why it worked before the -29 i do not know, best to ask what version tehy had before too
[23:24] <sconklin> agreed
[23:24] <bjf> so maverick has both -4 and -5 , lucid only has -5
[23:25] <bjf> natty has both
[23:25] <apw> has to be the cause, but how it ever worked on lucid is beyond me
[23:25] <apw> some background digging seems appropriate
[23:26] <sconklin> yeah, I'm fetching now
[23:26] <bjf> as usual we probably are getting a small part of the story
[23:26] <apw> too true
[23:26] <sconklin> This is another area where we probably need to share some knowledge
[23:27] <apw> anyhow, one piece of hardware affected, and they have an old kernel to use so no need to be escalated any further me thinks
[23:27] <apw> sconklin, yeah indeed
[23:40] <jsalisbury> apw, sconklin, One piece of info.  I'm running Natty, with linux-firmware 1.47 on the same hardware.  iwlwifi-6050-5.ucode looks like it was added in l-f 1.42 according to the changelog.  I've seen no issues.
[23:40] <apw> jsalisbury, and you have -5 and -4 on your machine right ?
[23:40] <apw> in /lib/firmware
[23:41] <jsalisbury> apw, yes: 
[23:41] <jsalisbury> jsalisbury@salisbury:/lib/firmware$ ls iwlwifi-6050*
[23:41] <jsalisbury> iwlwifi-6050-4.ucode  iwlwifi-6050-5.ucode
[23:42] <apw> yeah so it seems we have -4 and -5 on later releases, but only -5 on earlier ones; which is unexpected
[23:44] <jsalisbury> apw, not sure who to check if my system is using -4 or -5, maybe something in /proc?  Already checked dmesg and logs.
[23:44] <jsalisbury> apw, I do see this in /var/log/udev:
[23:44] <jsalisbury> KERNEL[1298912762.504059] add      /devices/pci0000:00/0000:00:1c.4/0000:02:00.0/firmware/0000:02:00.0 (firmware)
[23:44] <jsalisbury> UDEV_LOG=3
[23:44] <jsalisbury> ACTION=add
[23:44] <jsalisbury> DEVPATH=/devices/pci0000:00/0000:00:1c.4/0000:02:00.0/firmware/0000:02:00.0
[23:44] <jsalisbury> SUBSYSTEM=firmware
[23:44] <jsalisbury> FIRMWARE=iwlwifi-6050-5.ucode
[23:44] <jsalisbury> ASYNC=1
[23:44] <jsalisbury> SEQNUM=1897
[23:57] <sconklin> jsalisbury: I just updated the bug, with an attached version 4 of the firmware.