[08:29] <laga> um
[08:29] <laga> BenC: where's aufs gone?!
[08:29] <laga> BenC: amitk committed aufs yesterday. these commits are gone now
[12:14] <BenC> laga: probably eaten by my rebase
[12:14] <BenC> I can re-apply them
[12:24] <apt_get> Hi frieds
[12:25] <apt_get> I have a Emylex Fiber Channel.  It´s connected and Link-Up.    When I modprobe lpfc, its shows me 'scsi7 :  on PCI bus 0b device 00 irq 16'.   But I cant see the disks.  Whats wrong?
[13:00] <BenC> apt_get: what kernel?
[13:10] <laga> BenC: please re-apply them.
[13:11] <BenC> laga: I said I would :)
[13:11] <laga> BenC: misinterpretation++;
[13:11] <amitk> BenC: did you rebase to -rc8?
[13:14] <BenC> amitk: yeah
[13:15] <amitk> BenC: laga: pushed the aufs patches again
[13:15] <laga> yay
[13:16] <laga> BenC: i'll be watching your commits ;))
[13:17] <apt_get> BenC:  xen kernel '2.6.18-8'
[13:19] <BenC> amitk: thanks
[13:19] <BenC> apt_get: we've never had a 2.6.18 kernel, so are you actually running ubuntu kernels?
[13:19] <BenC> otherwise we can't help much
[13:20] <BenC> laga: I don't mind that at all...I make mistakes :)
[13:20] <mjg59> BenC: We shipped 2.6.18 in edgy, didn't we?
[13:20] <BenC> that was 2.6.17
[13:21] <BenC> we went 2.6.15, 2.6.17, 2.6.20
[13:21] <mjg59> Huh. Yeah.
[13:26] <apt_get> its the proper xen kernel
[13:30] <BenC> apt_get: well, this is the ubuntu kernel channel....best bet is to talk to the regular kernel channel, and they might even ask you to boot a stock kernel just to test that (since xen is so highly patched)
[13:30] <apt_get> ok
[13:30] <apt_get> thanks
[13:30] <BenC> np
[16:07] <munckfish> smb_tp: so there's an naming issue with linux-port-meta? Is it easy to solve?
[16:26] <smb_tp> munckfish, yes it is. it was simply a misunderstanding on my side.
[16:28] <munckfish> smb_tp: ok so is it sat in the queue ready for post-beta?
[16:30] <smb_tp> munckfish, Since ports do not go on any CDs it sounded as they could get up as soon as they are done
[16:31] <munckfish> smb_tp: oh
[16:32] <munckfish> smb_tp: from what cjwatson had said to me I presumed we were going to do CD iso images for the beta
[16:33] <munckfish> and that because of this issue we'd miss the official beta
[16:34] <munckfish> smb_tp: confusing :)
[16:34] <smb_tp> munckfish, hm I definitely have to ask him. Yes, well, when I asked it was during the freeze and about the ports package
[16:35] <munckfish> smb_tp: cool. Well whatever you can do is appreciated :). If we miss the beta for PS3 that's fine we can do an unofficial against the next daily after
[16:36] <munckfish> anyway - usplash won't be working on PS3 in the beta - my fix for that will go in after anyway
[16:43] <smb_tp> munckfish, I try what I can. :) Ok, whenever you have something, shout.
[16:44] <munckfish> smb_tp: btw I notice that in the main ubuntu kernel Ben added a patch to add a /proc/version_signature file with the full Ubuntu package version in it
[16:44] <munckfish> I think that is something we should get into the ports kernel too
[16:45] <munckfish> so the main kernel bug submitting instructions are the same for ports
[16:47] <munckfish> smb_tp: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=commit;h=529f9635c8250d355828710c7e54f1b676dc1365
[16:49] <smb_tp> munckfish, I guess this would be usefull.
[16:49] <smb_tp> munckfish, I check whether this applies simply to ports and get it in.
[16:49] <munckfish> smb_tp: great thx
[16:51] <rtg> smb_tp: ports is supposed to be community supported, wherein munckfish does the legwork and presents a pull request to you.
[16:51] <munckfish> rtg: ok understood
[16:51] <munckfish> I am happy to pull that one in :)
[16:51] <smb_tp> rtg, I know, but since I would have to pull anyways I can just pull from ben
[16:58] <munckfish> well smb_tp if it doesn't pull cleanly let me know and I'll integrate and submit. Whatever you decide.
[17:31] <smb_tp> munckfish, applied and push (in progress)
[17:33] <munckfish> smb_tp: thx :)
[19:12] <zafy> hi I'm trying to patch the hardy kernel with this :  http://lkml.org/lkml/2008/8/4/110 and I was told by somebody here that it should patch cleanly  but I'm getting this error : http://paste.linuxassist.net/16375
[19:12] <zafy> can anyone help
[19:13] <jdong> zafy: su to root first.
[19:14] <jdong> or echo nvidia.patch | sudo patch -p1
[19:14] <jdong> the permission denied error towards the beginning is the funadmental error
[19:14] <johanbr> zafy: Easiest thing is probably to look at the file and apply the patch by hand.
[19:14] <zafy>  echo nvidia.patch | sudo patch -p1 returns patch: **** Only garbage was found in the patch input.
[19:14] <laga> it still doesn't work if he uses sudo.
[19:15] <zafy> johanbr, I didn't really think I should do that
[19:15] <laga> also, you probably meant 'cat nvidia.patch | sudo patch -p1'
[19:15] <zafy> laga, so what are you suggesting ?
[19:16] <mjg59> zafy: s/echo/cat/
[19:16] <zafy> mjg59, yeah that returns what I pasted 
[19:17] <mjg59> zafy: If cat nvidia.patch | sudo patch -p1 returns the error, the patch is malformed
[19:17] <laga> zafy: apply the patch manually ;)
[19:17] <mjg59> But if you use echo, then you will definitely get that error.
[19:17] <zafy> http://paste.linuxassist.net/16377
[19:17] <mjg59> Because the string "nvidia.patch" is not a valid patch
[19:18] <zafy> laga, okay I'll try
[19:18] <laga> i wonder why he can apply the first hunk twice, though.
[19:18] <zafy> I dunno
[19:18] <mjg59> jdong: Eh? sudo patch will work fine. patch doesn't use stdio for modifications.
[19:20] <jdong> mjg59: yeah, you're right :)
[19:20] <jdong> didn't see the 2nd part.
[19:21] <jdong> looks like the patch doesn't apply cleanly then :)
[19:21] <zafy> so I should just apply it by hand then ?
[19:21] <jdong> yeah, looks trivial enough to do so
[19:24] <zafy> okay I just need to compile and install and cross my finger to see if it works
[19:24] <zafy> and it it doesn't, I hope I don't have to reinstall
[19:24] <zafy> thanks guys
[19:25] <jdong> hmm what does a sound driver have to do with preventing a reinstall though?
[19:25] <zafy> it's just I don't want to mess my already existing kernel and not being able to use it if this one doesn't
[19:27] <zafy> it's my first time patching/recompiling and reinstaling the kernel
[19:31] <zafy> ls
[20:02] <munckfish> smb_tp: ummm, it seems that the version_signature commit on it's own isn't enough
[20:02] <munckfish> Something's missing in the build infrastructure
[20:03] <munckfish> smb_tp: as now it fails the build at the start in the make silentoldconfig stage
[20:03] <munckfish> I'll need to investigate
[20:04] <smb_tp> munckfish, Hm, ok. I might push this to a ports machine as well and see how it fares..
[20:04] <rtg> munckfish: make sure its clean: git ls-files --others | xargs rm -vf
[20:04] <munckfish> guys actually
[20:05] <munckfish> maybe debian/rules updateconfigs
[20:05] <munckfish> would fix it
[20:05] <munckfish> as this is a new variable which doesn't show up in our configs
[20:05] <munckfish> gimme a minute I'll check
[20:07] <munckfish> smb_tp, rtg: ok that was all that was necessary. We just need to update the configs to include the new variable introduced by that change
[20:08] <munckfish> I'm about to do a test build now I'll let you guys know if it's all ok
[20:13] <munckfish> What does (no-op) mean in the newer commit log messages?
[20:34] <munckfish> smb_tp: I've pushed a commit with the updated configs to my tree
[20:34] <munckfish> that stops the build failing immediately
[20:34] <munckfish> http://kernel.ubuntu.com/git?p=dmunckton/ubuntu-intrepid-ports-ps3.git;a=commit;h=4ca511c73bc959d7294f7895f754efdbe2a4a4d4
[20:38] <smb_tp> munckfish, pulled
[20:39] <munckfish> smb_tp: thx - what does (no-op) mean in the new commit log messages?
[20:40] <smb_tp> munckfish, Wasn't that no-up? But don't exactly know. BenC ?
[20:40] <munckfish> smb_tp: yes no-up
[20:40] <smb_tp> munckfish, might be no(t)-up(stream)
[20:41] <munckfish> smb_tp: ah that would make sense. Right making a powerpc build now to test it out
[21:07] <Le-Chuck_ITA> Hello, since hardy iwl3945 is in ubuntu, however since hardy this driver mostly sucks, for me it is so slow to be unusable. Bug is reported in ubuntu and upstream, but intel will never care it seems - they likely have more urgent issues
[21:07] <Le-Chuck_ITA> is there any hope that ipw3945 will be put back in kernel?
[21:11] <BenC> smb_tp, munckfish: Means it wont be sent upstream
[21:28] <munckfish> smb_tp: ports builds fine now. And the version sig changes work fine too. cat /proc/version_signature ---> Ubuntu 2.6.25-3.4~danm2-powerpc64-smp. Perfect! Thx
[21:29] <smb_tp> munckfish, The thanks for that go BenC