[00:56] soren: you around>? [01:18] hi [01:19] rtg, BenC: argh, after hal the serial.h header bug now struck cups [01:19] would you guys consider bug 302888 as something which needs to be fixed, or something which is intended and needs to be changed in hal/cups/etc.? [01:28] ah, I checked upstream, it's not a bug there [01:28] seems to be an Ubuntu-introduced bug [01:29] pitti: hi, its on my todo list. I'll check it first thing in the morning. [01:29] rtg: great, thanks; so I [01:29] 'll just let the FTBFS sit there === chuck_ is now known as zul [06:47] lamont: What's up? [07:52] are there plans to build multipath-modules for the installer? [12:09] hi BenC , are you working on 2.6.28-rc7? [12:10] hey BenC, do we have any plans to move madwifi from LRM to the ubuntu folder now that its HAL is open? [12:12] NCommander: i dont think the madwifi code changed [12:12] Kano, no, they released the HAL for it [12:12] there the blob still exists [12:12] aka, the closed source blob [12:15] it would probably make more sense to get rid of madwifi completely if ath5k and ath9k work for a majority of the users. [12:16] As long as madwifi is maintained, it should still be an option [12:16] People get kinda pissed when their hardware stops working all of a sudden [12:17] i.e. Windows Vista [12:17] well kanotix users have got no complains against ath5k, i enabled it - as little diff to your config [12:17] so eee pc and co works out of the box [13:20] apw: I responded re LP 302888 and 303711. [13:20] rtg cool [13:21] hi rtg , how about 2.6.28-rc7 [13:21] Kano: I take it from your question that it must be out :) [13:21] rtg, will sort it out now [13:22] Kano: As usual we are working on it as quickly as possible, without concern for outside questining [13:22] questioning [13:23] * apw had something to ask benc ... what was it ... oh yeah, did you do the roll forward from Hardy to Intrepid? [13:23] BenC: well i did not see any new commits ;) [13:23] i want nfs working, did anybody else that that [13:23] apw: Hmm....I think so, but that was awhile ago :) [13:23] benc, we lost an unbutu driver, specifically [13:24] benc, we lost an ubuntu driver, specifically the snd-aloop one, and wondered if you remebered the history [13:24] apw, are you sure we lost it or is that just a rename? [13:24] apw: was it in the ALSA directory? [13:24] sound, rather [13:25] That clue with dummy seemed good [13:25] apw: we had an ubuntu driver called snd-aloop? [13:26] apw: if it was in alsa proper, best bet is to check alsa history [13:27] BenC, no it was in l-u-m [13:27] apw: but the sound drivers in lum were just a tarball of upstream [13:27] apw, It was in lum but under sound which is alsa [13:27] apw: so we didn't really pay attention to individual drivers in it [13:28] hmmm ... ok then will go look at it from that point of view [13:28] except maybe snd-hda-intel [13:28] well that should be upstream as well. maybe even more upstream than the rest [13:29] rtg, that header file fix is pushed up to jaunty [13:29] rtg: Can you get me a cup of coffee too :) [13:29] oh you referred to paying attention [13:29] * apw salivates ... and has to go make one [13:29] My brain is only at about 70% right now...need that extra caffeine kick to get to 71% [13:34] apw, snd-dummy really looks alike snd-aloop beside of having everything renamed from loopback to dummy... [13:34] BenC: I've got time to rebase and test build Jaunty this morning. OK? [13:34] smb_tp, interesting ... i did see one commit which talked about dummy which sounded like it do something [13:34] will do compare them [13:36] rtg: Have at it :) [13:36] BenC: will do. coffee is almost ready. bought a new 5lb bag of Italian roast just yesterday. [13:39] mmmm...italian [13:39] rtg, Need COIP ;-) [13:41] Anybody working on LRM/meta for Jaunty? [13:41] amitk: I was going to do that since rtg had the rebase, but if you are already started, it's yours [13:42] BenC: not started. I'll be busy this week with ARM. [13:42] amitk: do you have the linux-meta armel portion? [13:42] amitk: Ok, I'll get lrm forward ported then [13:42] BenC: not yet. Since I was waiting for the fallout from the -ub- version_signature discussion [13:42] rtg: When you do the rebase, can you remember to remove the via chrome9 drivers from ubuntu/? [13:43] BenC: can do. amitk - you promised a discussion for why you added -ub to package names. [13:44] rtg: basically to help identify ubuntu machines with upstream bug reporting and oops reporting [13:44] rtg, while we are on the subject of version, i got that patch to put the ubuntu upload+changelog into the /proc/version #N field [13:44] rtg: yes. As soon as I am done with the spec here. [13:44] apw: that would be nice [13:44] Linux version 2.6.27-10-generic (root@dm) (gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11) ) #21~lp276943apw1 SMP Mon Dec 1 17:56:07 GMT 2008 [13:45] note the [13:45] note the #21~... in there where we always have #1 [13:45] also note that in theory this would also be in the oops output [13:45] what is the ~lp... ? [13:45] that is a local change tree i have installed, and i added that to the changelog [13:46] BenC: with apw's patch to /proc/version and in the oops patch, we should be able to revert the -ub change [13:46] apw: can you paste "head -1 " of changelog so I can see what it is parsing into it? [13:46] ie. what i put in there is everything after the abi number [13:46] ok [13:46] BenC: adding -ub to the package name does't have anything to do with kerneloops, does it? I thought it was all in /proc/signature [13:46] linux (2.6.27-10.21~lp276943apw1) UNRELEASED; urgency=low [13:46] so normally we would expect it to be #21 or maybe #21ubuntu1 [13:47] rtg: well changing the package name made things easier in the build scripts, since it is assumed that the package name matches the kernel version name [13:47] this is a local build for testing so i bung that into the changelog too [13:47] yeah you don't have much choice but to change the name if you add it to the real version [13:48] the other options were to just change the ooops output, to add a marker [13:48] though logically it would be better for mainline to add a CONFIG_DISTRO [13:48] and default that to mainline [13:48] amitk: so how does kerneloops tell that it is an ubuntu proper kernel and not just a kernel built on an ubuntu machine? [13:48] so all oopses had mainline , or Ubuntu [13:50] apw: that was kind of the idea behind version_signature, but I wasn't prepared to push it hard enough to send it to linux-kernel@ [13:51] well it would be sensible enough, we just need it in the oops output [13:51] BenC: why am I ripping out via_chrome9 (which appears to be enabled) ? Is there an LP report? [13:51] BenC: it scans dmesg for oopses [13:52] BenC: here is a sample first line from Fedora [13:52] Linux version 2.6.24-0.77.rc4.git4.fc9 (kojibuilder@) (gcc version 4.1.2 2007112 [13:52] 4 (Red Hat 4.1.2-35)) #1 SMP Thu Dec 6 16:50:13 EST 2007 [13:53] rtg: because it is in mainline now [13:53] uh, I guess that makes sense :) [13:54] amitk: right, but how is our kernel going to look different than a kernel a user built, or do they not care about that? [13:55] BenC: they don't care unless it is tainted [13:56] amitk: that sucks, because I care :) [13:56] BenC: you want to differentiate official kernels from user-compiled ones? [13:56] amitk: then why couldn't they just check for Ubuntu in the kernel oops already...that's always been there [13:57] amitk: it's always been in oops and /proc/version [14:00] BenC: our /proc/version in intrepid is [14:00] Linux version 2.6.27-10-generic (buildd@crested) (gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11) ) #1 SMP Fri Nov 21 19:19:18 UTC 2008 [14:00] The first part has no mention of ubuntu [14:01] The only Ubuntu in there is related to the gcc toolchain use [14:01] *used [14:01] and oopsen only use that first version field [14:01] * amitk nods [14:01] well thats not quite true, they also include the #1 field [14:02] one of my alternative patches put -Ubuntu in there, #1-Ubuntu [14:02] we could combine that with my other patch to make it like #12-Ubuntu [14:07] apw: for our official kernels, that would be sweet [14:07] apw: where can I find the patch? [14:08] we can probabally even key that off the whether we are under an autobuilder [14:08] BenC, want me to send it out? [14:08] apw: that's easy to do, see debian/rules.d/0-*, there's a check for CurrentlyBuilding or something similar [14:08] apw: that means we are under a build daemon [14:08] apw: yes, please [14:08] i'll poke it so it adds the -Ubuntu on autobuilder and send it to the kernel team list [14:16] BenC: have you ever considered removing debian/control, debian/control.stub, and debian/d-i/kernel-versions from git ? All of these files are generated and often cause rebase conflicts. [14:16] i often wonder why we have the abi files in there either [14:17] other than the getabi thing being very slow cause it gets the whole kernel package [14:17] apw: well, the ABI for the previous version really needs to be there. [14:17] rtg: odd, I've never had a rebase conflict with them [14:17] we need to know it for the build right, but not necessary in the source tree itself? [14:18] apw: it needs to be there so we can easily go back through history [14:18] are they not in the pacakges we released too tho? [14:18] apw: they are pertinent to the state of the tree [14:18] BenC: I'm having a rebase conflict with the -ub additions in debian/d-i/kernel-versions.in, and I'm not quite sure why. [14:18] apw: they packages we released will disappear sooner then the end of the development cycle :) [14:18] fair point [14:19] rtg: easy enough to just ignore those...I've never had issue with that before [14:19] regen at the end of the rebase [14:19] BenC: well, I can't exactly ignore kernel-versions.in, that one I have to resolve. the rest are no problem. [14:20] rtg: just delete those files before you start the rebase and regen them at the end [14:20] rtg: I suspect that it more to do with armel and -ub- clashes rather than just normal stuff [14:20] rtg: .in versions for the generated versions? [14:20] BenC, actually the given the abi cannot change within an -N abi stream and given the each abi is a differnt package, then all the abis should be available always [14:20] BenC: isn't that what I said? [14:20] s/for/or [14:21] apw: as I said though, the abi files are very pertinent to the state of the tree, so they should be there [14:21] apw: we shouldn't have to download the abi files to go back through history...easier to just use git [14:21] fair enough, just usual to have generated stuff in there [14:22] rtg: oh, I thought you just said -ub-....I was just remembering a bit of merging I had to do with amitk's -armel stuff and -ub- changes [14:22] apw: abi files aren't generated in the tree though...we have to fetch them [14:22] you can probably make the case for control,control.stub,kernel-versions though [14:23] as long as they get added to .git-ignore, I wont complain :) [14:23] BenC, i cannot argue with that [14:24] It might be best to keep them though...we've always assumed that git tags hold the exact source we uploaded [14:25] BenC: until we rebase, that is.. Then the tags are meaningless [14:25] well no the old tags are still there, they don't move [14:26] BenC has a retag script :) [14:26] he is a bad bad man [14:26] I keep the original tags though [14:27] like Ubuntu-2.6.28-1.1.orig [14:27] why would we move them ever? don't they correspond to something specific? [14:27] and they never get overwritten after they are created [14:27] apw: we move them so they correspond to git history [14:27] apw: it's good to have the original and the retag [14:28] why do we need the new ones? the old ones tell you how to get the source as it was for that release [14:28] apw: because if they don't correspond to the new line of history, we can't git-bisect [14:28] what do the new ones on the rebase tell us [14:28] * apw mulls that over [14:28] if you rebase, you can't bisect from HEAD back to 2.6.28-1.1 [14:29] unless you use the updated tag that corresponds to the new line of history [14:29] and the old tags make it so we can keep a link back to the actual upload [14:29] BenC: debian/scripts/misc/retag before you startnewrelease, right? [14:29] although the fact it worked in 2.6.28-1.1 means nothing in the new kernel [14:30] rtg: you can run it at any time [14:30] as the new kernel has new stuff 'older than' 2.6.28-1.1 [14:30] so its not obvious a known good point on an older branch means anything int eh new tree [14:30] apw: it's very subtle, but I did write the script because our process demanded it at a few points during development :) [14:30] these tags are useful for bisecting only inside Ubuntu's patches [14:30] * BenC doesn't add scripts for no particular purpose [14:31] heh, not doubting there is a use case for them [14:31] just my 'perfection' beeper is going off at the thought of ever changing the tags [14:31] apw: the reason we rebase here instead of merge is because when we bisect, we want to be sure we are bisecting ubuntu patches and not upstream [14:32] apw: when we bisect upstream, we don't want to be bisecting ubuntu patches in the middle of it [14:32] apw: if you want, rtg and I can rehash our old arguments for and against this at UDS :) [14:32] yeah am happy we rebase, that helps keep our delta contained and minimised, even if it is painful [14:33] i had not expected the tags to move, and i can see why they might, not sure they are entirly valid given a good result on a kernel with an older version of the tag, but i can see how it does help to have the split on the current set too [14:33] * apw adds 'if there is a .orig for a tag, its the master' to his mental model [14:33] apw: after the kernel goes stable, we don't rebase anymore, so the moving target is usually only during development cycle [14:35] BenC, i can see i would have done something similar (now i have all the facts) though i would probabally have kept the original tags unchanges and made like a Ubuntu-2.6.27-10-2, -3 etc for each of their new positions, but the effect is the same [14:46] BenC, patch for the #NN -> #21-Ubuntu is in the pipe === lamont` is now known as lamont [14:52] apw: you didn't push it, right? 'cause I'm gonna clobber stuff when I push Jaunty. [14:53] rtg, it ? [14:53] apw: ' patch for the #NN -> #21-Ubuntu is in the pipe' [14:54] nope, that means 'on the way to the mailing list' [14:54] i did push the other fix, but i assume you have done your thing since then [14:54] if not i'll do it again [14:56] apw: I have the __u32 fix, and my chrome9 patch is still top of the gitweb. [14:57] rtg all sounds good to me [15:00] hmm, looks like the biking season has come to an abrupt end. in the last 2 hours 2 inches of snow has accumulated. [15:08] amitk: iop32xx FTBS'd on the last upload. do you expect that it will succeed this time? [15:10] rtg: 2.6.28-1.1? [15:10] amitk: yes [15:11] rtg: I see it successfully built [15:11] https://edge.launchpad.net/ubuntu/+source/linux/2.6.28-1.1/+build/798103 [15:12] amitk: getabi failed, so I assumed.... lemme go look closer [15:12] OH HAI. I CAN HAZ MY ETHERNET BACK PLS? [15:13] lamont: ARE YOU DEEF? [15:13] I did a dist-upgrade, intrepid-security kernel, and *poof* no BCM4401-B0 agaiin [15:13] lamont: you have LBM installed, right? [15:15] linux-backports-modules-2.6.27-9-generic is already the newest version. [15:15] lamont: you'll likely have to pull from -propsed [15:15] -proposed, even [15:16] so when does intrepid release then? [15:16] early Q1 probably [15:16] yeah - please to quit breaking [15:16] kthx [15:16] lamont: bitch and moan [15:17] I realize it's not like anyone is actually using it or anything.... :-( [15:19] amitk: the problem is the package name, e.g., iop32x v.s. iop32xx [15:20] rtg: 2.6.27-10? [15:20] lamont: that should be the version in -proposed [15:20] yeah, but no way in hell I'm dist-upgrading from -proposed --> cherrypick [15:21] lamont: why not? its your laptop. ots not like its a production server [15:21] my laptop [15:21] == production lifeblood [15:21] lamont: what model? [15:22] inspiron 1520 [15:22] lamont: I think I have one of those. I'll test it, but I think -proposed is working pretty good. [15:23] I know for sure the b44 issue is resolved. [15:23] which still brings up the question of how -updates got the b0rked one. again. [15:24] maybe remove the backport modules [15:24] 'cause we has a -security kernel update which necessitated an ABI bump. [15:24] LBM has not been promoted to -updates in awhile [15:24] Intrepid LBM, that is. [15:25] rtg: one would expect that we'd rev lbm at the same time... [15:25] and the currently running kernel is -9 [15:25] lamont: I did, but only the ABI number. I'll bug pitti, its probably time to push LBM to -updates [15:35] rtg: it should've been iop32x [15:38] sweet, lrm builds without problems under 2.6.28 [15:47] rtg: let me know when you get -2.2 uploaded and I'll follow with an lrm to match it [15:50] BenC: still test building. I ran into a problem getting ABI files, etc. also had some background distractions with Intrepid LBM. [16:03] fabbione: I've been meaning to ask you if we still need gfs? Is fs/gfs2 sufficient? [16:05] rtg: you still need gfs for at least another 3/4 years I guess [16:05] rtg: you can drop gnbd [16:05] rtg: gnbd has been deprecated upstream [16:05] fabbione: thanks, consider it gone. [16:06] rtg: do you need a newer gfs for .28? [16:06] fabbione: yep [16:06] rtg: remember that now gfs doesn't need any extra patches to kernel like it used to [16:06] fabbione: I think BenC just forward ported Intrepid gfs to Jaunty [16:06] rtg: old versions of gfs required some exported symbols from gfs2. This is not the case anymore since .27 [16:07] rtg: I dunno.. I'd like to see the patches tho so we can actually apply them upstream [16:07] rtg: also.. you guys should really stop doing that forward port without upstream.. [16:07] or at least talk to us [16:08] it's bad for you as you lack tons of bug fixes [16:08] and your gfs doesn't go through QA [16:08] so if it breaks you keep the pieces :) [16:08] fabbione: I agree with everything you're saying. its a matter of resources. [16:09] rtg: if you have the time to port gfs, you have the time to send me an email, same as you can ping me on IRC :) [16:09] fabbione: well, I was still busy with Intrepid while BenC was doing Jaunty, so the stink is on him. [16:10] rtg: i didn't blame you.. just that the resource thing doesn't hold with me as I have been there before :P [16:11] fabbione, i suspect he did a git rebase, and it 'worked' so its wasn't any effort [16:11] (other for the computer) [16:11] fabbione: gfs didn't build right away, so I just disabled it for the first upload [16:11] fabbione: intentions were to download the newer version for next upload [16:12] BenC: ok. we don't have a version for .28 yet [16:12] fabbione: I did no porting to gfs at all [16:12] BenC: ok :) [16:12] BenC: i'll ping you as usual to do a pull when it's ready [16:12] no panic [16:12] s/GFS=m/GFS is not enabled/ [16:13] * apw senses an effort shift to fabbione ... excellent for us :) [16:13] Juanty barely started [16:13] apw: you have no idea who I am, do you? [16:13] fabbione: sure thing...I can do the pull whenever it's ready [16:14] apw: fabbione is the godfather that brought me into canonical as the "kernel team" [16:14] BenC: absolutely.. usual stuff, or I'll make sure that your shrink will be rich out of your money for the next 100 sessions [16:14] heh nope no clue ... [16:14] apw: I used to be the kernel team alone for about 2 releases [16:14] apw: :) [16:14] fabbione: My shrink is named beer, and he's pretty cheap [16:14] that i don't envy you :) [16:14] and at the time there were more arches to support than you do [16:15] BenC: should I really really remind you about me trying to grab your ass at night?? [16:15] yeah that must have been at best 'mad' ... [16:15] fabbione: but you weren't the OEM's little mistress back then :) [16:15] fabbione: it took several weeks of beer and jaegar bombs to get over that night [16:15] * BenC shivers [16:15] BenC: ehheeh true that... [16:15] haha [16:17] anyway.. kill gnbd [16:17] I'll make userland disappear soonish [16:18] fabbione: I think clan now has a 3 foot minimum spacing between beds in shared rooms requirement because of my complaints about that [16:18] apw: and btw.. now I am release manager for gfs :) [16:18] BenC: ROFL [16:18] apw: for me it's a no brain to do it for ubuntu [16:20] fabbione: especially because I don't think jono is any safer than you are even though he is married now [16:20] fabbione: when do you think a gfs pull will be ready? [16:21] BenC: end of next week maybe [16:21] BenC: I am rebuildnig the whole datacenter here [16:21] BenC: and I had too many issues before I could start reinstalling the community clusters (fedora, ubuntu etc) [16:22] BenC: i need to show you pictures of what I have done here :) [16:22] fabbione, nice to know :) i am a lowly pleb [16:22] BenC: a 8 heads workstation ;) [16:23] BenC: 5000x2300 resolution.. given or taken :) [16:23] * amitk thinks of forwarding the irc log to clan to push for separate rooms [16:23] amitk: ahah you have my blessing! [16:23] HI CLAN! [16:23] :) [16:23] amitk: either that, or we should have a mental anxiety reimbursement :) [16:24] fabbione: sweet... played flight simulator on that? [16:24] amitk: not yet.. i just installed it 2 days ago :) [16:24] amitk: but the CPU is not a gaming one [16:24] * BenC imagines fabbione playing frets of fire and having the biggest video crowd ever! [16:24] BenC: try to imagine something more useful than gaming [16:25] this is the best Porn machine ever [16:25] hehe [16:25] 8 porn movies at the same time! [16:25] (welcome to quote me ;)) [16:25] 2girls1cup, mr hands, pain olympics, and all their glory [16:25] AltGr+e ftw? ;-) [16:47] fabbione: nice [16:48] rtg did you push the tags for this new jaunty? [16:48] i have a -2.2 tag, but the 1.1 and 0.0 are missing [16:48] apw: I did [16:49] apw: it says everything is up to date [16:49] hmmm ... they are still in their originals on my fetch [16:49] you have to explicitly push tags [16:49] iirc [16:50] 'git push --tags origin master' is what I just did [16:50] oh hmmm i had to explicitly fetch the tags ... oddness [16:51] I've run into that before [16:51] rtg: git-push --tags [16:51] i am pretty sure its not meant to do that... [16:51] err, nm [16:51] rtg: you shouldn't really explicitly push origin, fyi :) [16:52] BenC: why not? I _always_ check to make sure I know what origin is first. [16:54] BenC: also, you do your LRM thing now. [16:54] s/you/you can/ [16:56] rtg: just the nature of origin is local to the repo...I don't think it will hurt anything, just that master is the one that matters [16:57] rtg: ack on lrm, thanks [17:19] BenC, how do i figure out what head you started from when you rebased to .28 for the first time? [17:20] apw: hard to tell, but you can get an idea from the changelog as to where it was when I cloned it [17:20] the entry before 2.6.28-1.1 is the last upload before I cloned, so that + maybe-some-other-commits [17:21] we should probabally tag that in future [17:21] and i'll try and figure it out too [17:39] is there any 2.6.28-rcX kernel packaed for jaunty yet? [17:42] mnemo: 2.6.28-1.1 available from https://edge.launchpad.net/ubuntu/jaunty/+source/linux/2.6.28-1.1 [17:42] and if you wait a day you might get a -2.2 that based on the latest -rc [17:43] can some on help me debug my system ? [17:44] I'm getting kernel locks on shutdown (halt) [17:44] and suspend stop working last week [17:44] I'm on jaunty [17:45] amitk: when I did "update-manager -d" it left me with 2.6.27-something, is that normal? do I need to do something explicit to switch over to the new kernel? [17:47] mnemo: I got stuck on the .27 kernel until I manually installed it via synaptics [17:47] mnemo: 2.6.28 is not installable through update-manager yet. Some meta packages are missing [17:48] best wait a day or so if you need update-manager support [17:48] yeah amitk... it looks like it === mdz_ is now known as mdz [19:10] lrm on its way up [20:11] * fabbione larts BenC for not building usb-serial in sparc hardy kernel! [20:11] fabbione: was hardy sparc still built from linux proper source? [20:12] yeps [20:12] fabbione: I claim lack of need for usb-serial [20:12] i claim I need it :) [20:13] i just plugged my backup adsl line in my new (sparc) firewall and zack [20:13] <- owner [20:13] owned [20:13] fabbione: become a sparc community kernel maintainer :) [20:14] * fabbione larts BenC with a pci2usb card ;) [20:14] BenC: i am going to test it.. if it works, can you just flip it on the next build? [20:14] it's sparc only, doesn't affect main arches yada yada [20:22] fabbione: bug report, SRU request, kernel-team@ [20:22] SRU? [20:22] for a config option on a non supported arch? [20:23] Stable Release Update [20:23] yeah i know what SRU is.. i mean all the paper work for non supported arch? [20:23] fabbione: I don't handle stable, best to talk to smb_tp [20:23] ok....... [20:23] * smb_tp comes over [20:24] smb_tp: ^^^ [20:24] brb [20:24] fabbione, ok, so I have some time to read context :) [20:30] fabbione, Ah ok, well if it works, at least write a mail asking and explaining why to kernel-team@. You will help greatly if you could do a simple bug report as well, but since it is so simple I can do it this time. ;-) It is hard but it helps remembring why things were done. Especially since team now is >1 [20:43] smb_tp: ok.. but remember a good git entry in the log and debian/changelog is also as useful :) [20:43] smb_tp: anyway first testing... then everything else [20:44] smb_tp: if i am bored i´ll just give you a tree to pull :) [20:44] fabbione, Heh, for sure [20:44] apw: Is the fix for bug 193970 only for the iwl4965 driver? [20:44] fabbione, Even better. :) [20:45] bug #193970 [20:46] bah stupid ubotto [20:46] ubotto sleeps with the fishes [20:47] bdmurray, yes the fix ascribed to that bug seems to only help the higher level iwl4965 driver [20:47] its on my list to find out if there is another fix out there for the older driver [20:47] apw: it applies to both iwl 4K and 5K drivers. [20:56] yeah, will investigate further tommorrow