[01:15] <andresmujica> .
[10:19] <speakman_> hello folks
[10:20] <speakman> when is a kernel comming with the atl1e multicast patch applied?
[10:21] <speakman> I'm running 2.6.27-10-generic and it's still not fixed.
[10:24] <speakman> and second; why is scripts in debian/scripts/misc not set +x by default?
[10:32] <abogani> Those scripts are x enabled on all.
[10:33] <abogani> For atl1e patch you should point us at Upstream status (aka git commit).
[10:34] <speakman> really? doing apt-get source requires me to manually set +x
[10:34] <speakman> abogani: I've already done a few weeks ago :)
[10:35] <abogani> speakman: You should use git and relative repos (if you want use Ubuntu build infrastructure).
[10:35] <speakman> the only checkout with git that has atl1e fixed is the "master" branch, and that won't work with nvidia proprietary drivers.
[10:35] <speakman> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/300698
[10:36] <speakman> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=commit;h=790be40d61f4d831dd1893b417d018ba304c5fca
[10:36] <maxb> speakman: Debian source packages represent the changes against the upstream tarball as a patch. Patches don't preserve executable status
[10:37] <speakman> oh, i see! thxn
[10:39] <abogani> speakman: Probably you should wait for 2.6.27-11-generic to see that patch applied
[11:28] <speakman> abogani: when is 2.6.27-11-generic planned for release? Can I get it now via Git?
[11:29] <speakman> and btw, when doint apt-get source linux-image-2.6.27-10-generic It'll download linux_2.6.27-9.19.diff.gz
[11:31] <abogani> speakman: No time planned at the moment. For updated source please read https://wiki.ubuntu.com/KernelGitGuide
[11:37] <speakman> Really? It breaks alot of computers since ATL1E is very common on Asus motherboards, and Asus itself is a very popular brand. I really think this bug is enough for a kernel update itself.
[12:59] <apw> speakman, if we release that change it would release as a -11 kernel, are you saying that the nvidia drivers don't work with -11?
[13:13] <speakman> apw: i'm to "noob" to really make that statement, but I'm trying once again right now.
[13:14] <speakman> (it's still compiling. it will probably take a while. I'll be back with the results)
[13:20] <apw> speakman, are you building .deb's from our git tree?
[13:22] <speakman> trying to, yes :)
[13:23] <apw> 32 or 64 bit?
[13:23] <speakman> i remeber last time, it didn't fail while compiling, but when dpkg -i the package
[13:23] <speakman> nvidia-something failed
[13:23] <speakman> 23
[13:23] <speakman> 32
[13:23] <speakman> It's done compiling! Trying install, please wait.
[13:23] <rtg> apw: sounds like missing headers for dkms
[13:24] <speakman> btw, is "header" supposted to beinstalled furst?
[13:24] <speakman> first*
[13:24] <speakman> DKMS is the word i was looking for
[13:24] <apw> they just both need to be installed, but you need the generic and arch headers
[13:24] <speakman> ? i've only binary-generic
[13:24] <speakman> do I need another compile?
[13:24] <apw> binary-indep
[13:25] <apw> gives you the generic headers
[13:25] <apw> which is linked to by the arch headers
[13:25] <speakman> oh, debian/rules binary-indep ?
[13:28] <apw> yep thats the one
[13:28] <speakman> -rw-r--r-- 1 daniel daniel  630618 2008-12-15 14:19 linux-headers-2.6.27-11-generic_2.6.27-11.21_i386.deb
[13:28] <speakman> -rw-r--r-- 1 daniel daniel 5889698 2008-12-15 14:27 linux-headers-2.6.27-9_2.6.27-9.19_all.deb
[13:28] <apw> yep those are them
[13:28] <speakman> why two? and why one -11 and one -9 ?
[13:29] <apw> they should be both the same abi number
[13:29]  * apw checks his
[13:30] <apw> linux-headers-2.6.27-11_2.6.27-11.21~webcams1apw1_all.deb
[13:30] <apw> linux-headers-2.6.27-11-generic_2.6.27-11.21~webcams1apw1_amd64.deb
[13:30] <speakman> (sorry but I don't know what ABI (Applicatino Binary InterfacE?) number is)
[13:30] <apw> the -9 and -11 are the abi level
[13:30] <speakman> k!
[13:30] <apw> and they should match!
[13:31] <apw> i am building some -11 based test kernels at the moment, so if you don't get anywhere i can point you at those once they are uploaded
[13:31] <apw> sadly for you i did the 64 bit ones first
[13:33] <speakman> can I assist in any way?
[13:34] <apw> heh nope, purely mechanical build, just waiting for it to complete
[13:37] <speakman> btw, why ain't there any core2 kernels? wouldn't that optimize pretty much comparing to i686?
[13:40] <fransman> speakman: I think i686 are core2 kernels, they just run on i686 as well
[13:41] <speakman> if it can be run on i686 I can't imagine it's using the full potential of core2, but I'm no arch expert.
[13:42] <speakman> i.e. I'd like PAE enabled to gain >4GB RAM even on 32bit arch
[13:42] <rtg> speakman: run the -server flavor for PAE support.
[13:42] <apw> there is very little specific to the newer processors which arn't exposed by cpuid bits and therefore used even on kernels targetted at the lower common denominator
[13:43] <speakman> rtg: will it work even on my desktop machine? Not slowing the desktop down or anything?
[13:44] <rtg> speakman: as long as you have the correct headers installed for your nvidia dkms build, it'll work fine.
[13:44] <apw> everything is a trade off.  enabling pae is not free
[13:47] <speakman> apw: do you mean there are drawbacks with PAE?
[13:47] <apw> there are costs yes, every pte entry is double the size, that is not without cost
[13:47] <speakman> should I be running 64bit on a Core2 CPU maybe? 
[13:48] <speakman> no idea what pte entry is, but isn't that the same cost as with everything going 64bit?
[13:48] <apw> i am running 64 bit on my core2 duo
[13:51] <apw> yep, same thing going to 64 bit as well.  trading off equal use of all memory against things being bigger
[14:03] <speakman> Not really a kernel question, but will I experience a better performace with a 64bit installation on my core2quad?
[14:12] <zul> ubuntulog: 
[14:12] <zul> doh..
[14:15] <speakman> apw: how is your compiling going?
[14:16] <apw> just completed the uploads
[14:16] <apw> they are here: http://people.ubuntu.com/~apw/webcams1/
[14:16] <apw> there are a couple of webcam id changes in there, otherwise they are the current -11 head
[14:17] <speakman> okey, I'll just have to download and install and the atl1e issue is gone?
[14:18] <apw> i believe from the discussion that the head of our tree had the fix in, if so then those binaries should have them
[14:35] <speakman> how come you got -11 but I got -9 on indep headers?
[15:01] <speakman> http://henrikalexandersson.blogspot.com/2008/12/och-nu-internetcensur-p-riktigt-i.html
[15:01] <speakman> Av allt elände på Internet så är det p.g.a. spel vi ska filtrera det?
[15:02] <speakman> Och på IP-nivå? 
[15:07] <speakman> apw: is it really i386 and not i686 in your webcams1 dir?
[15:08] <speakman> oh, sorry for the above, wrong window :(
[15:08] <apw> i386 is the debian architecture not the kernel sub-architecture tho
[15:09] <speakman> okay, it's fine running on my core2?
[15:09] <apw> should be yes
[15:11] <speakman> no problem with DKMS this time :)
[15:11] <speakman> rebooting... brb
[15:23] <speakman> Up'n'running, Multicast enabled and no Nvidia problems :D
[16:29] <apw> speakman, good to hear no nvidia issues ... so you should be set until -11 is released
[16:37] <speakman> ...and then the atl1e issue is gone anyway right?
[17:23] <apw> speakman, yeah then you will get the same base kernel which has the fix, as it'll be based on the one i built there
[18:33] <Keybuk> quick Q-of-the-day
[18:33] <Keybuk> if I'm on amd64, how do I do an x86 kernel build?
[18:34] <rtg_> Keybuk: dchroot using linux32 ?
[18:34] <Keybuk> why do I need a chroot?
[18:34] <rtg_> its just the way I do it, 'linux32 dchroot -c intrepis-i386' fior example.
[18:35] <rtg_> I use a chroot because what I'm doing is sometimes interactive, like fixing compile errors.
[18:35] <Keybuk> but you can do that anyway?
[18:36] <rtg_> huh?
[18:36] <Keybuk> I don't see how a chroot helps you there
[18:37] <rtg_> if the compile error is unique to the 32 bit build, then its convenient to be in a 32 bit environment.
[18:37] <Keybuk> the only thing that puts you in the 32-bit environment is linux32 though ;)
[18:37] <rtg_> correct.
[18:38] <Keybuk> the chroot just means you might not have 64-bit files around
[18:38] <Keybuk> do you think make ARCH=i386 would work?
[18:38] <mjg59> Yes
[18:38] <mjg59> Setting ARCH overrides the cross-compiler settings
[18:38] <Keybuk> though I assume I'd need to get the .config somehow
[18:38] <mjg59> Keybuk: ubuntu/configs
[18:38] <Keybuk> mjg59: they need catting together and other sed magickery though, right?
[18:39] <mjg59> cat should be enough
[18:39] <Keybuk> ok
[18:39] <mjg59> Just cat generic and the specific i386 one
[18:39] <mjg59> Later values override earlier ones
[18:39] <Keybuk> cat ... > .config
[18:39] <Keybuk> make ARCH=i386 oldconfig
[18:39] <Keybuk> make ARCH=i386
[18:39] <Keybuk> ?
[18:39] <mjg59> Then make oldconfig
[18:39] <rtg_> Keybuk: you can concatenate the 2 config files, e.g., config and config.i386
[18:39] <mjg59> Right
[18:39] <Keybuk> great
[18:39]  * Keybuk just waits for git now ...
[18:40] <mjg59> The kernel's entirely happy to do an i386 build on a non-i386 system, as long as ARCH is set
[18:40] <mjg59> My recollection is that it special cases amd64->i386 to just call with -m32
[18:41] <Keybuk> yeah, I've generally found it's easier to deal with Kbuild than the Ubuntu debian/rules <g>
[18:41] <mjg59> kbuild is really optimised for the uncommon case
[18:41] <mjg59> At the expense of failing at the common case, but that's fine because seriously, who builds their own kernels these days?
[18:41] <rtg_> I got into the chroot habit when working on kernel dependent packages where the asm link _did_ make a difference.
[18:42] <mjg59> Yeah, module crossbuilding is hard
[18:43] <mjg59> Another reason everything should be upstream :)