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