[12:36] <shwag> what kernel does  dapper server  install by default ?
[12:37] <BenC> the -server kernel
[12:37] <shwag> what is the difference between  linux-image-686  and  linux-686-smp  ?  they both actually appear to be SMP
[12:43] <joefso23jh> with and wihtout preempt?
[12:43] <JanC> -smp is a meta-package 
[12:44] <joefso23jh> I pulled 2.6.19 from git today
[12:45] <joefso23jh> and I got: http://pastebin.ca/270903
[12:45] <JanC> to make sure those who had an smp kernel in previous versions of Ubuntu didn't get stuck with an old useless kernel after an upgrade
[12:45] <joefso23jh> (while building the same config from 2.6.19 feitsy)
[12:45] <joefso23jh> s/the/with the/g
[12:47] <JanC> shwag: almost all kernels are smp-ready since dapper 
[12:47] <kylem> joefso23jh, so?
[12:48] <joefso23jh> is there any fix?
[12:48] <shwag> Yah it looks like, linux-686-smp   is preemt ... while  linux-image-server   is not preemt.
[12:48] <kylem> it's in git. not uploaded.
[12:48] <joefso23jh> so it's known?
[12:48] <kylem> why don't you go get the source from feisty.
[12:48] <joefso23jh> cause packages.ubuntu doesn't seem to be uptodate
[12:49] <shwag> uhh...how do I safely remove  linux-686-smp from my system ?
[12:50] <joefso23jh> apt-get remove --purge ?
[12:52] <shwag> joefso23jh: will that put grub back properly ?
[12:59] <gnomefreak> i use synaptic its much neater for kernel removal i have found
[01:01] <qhartman> Intel has released a security advisory about a buffer overflow in their e100/e1000 nic drivers at http://support.intel.com/support/network/sb/CS-023726.htm
[01:02] <qhartman> this seems to affect Ubuntu, given the versions they mention.
[01:14] <shwag> so I installed a kernel image and now I regret it. How do I put grub back to the old kernel ?
[01:24] <shwag> common team...that should be an easy question.
 shwag: you can select a kernel for the next boot with grub-reboot (check man grub-reboot).
 shwag: reboot and select the older kernel to boot. Then remove the new kernel with 'sudo apt-get --purge remove linux-kernel-(version of the new one)'. The grub entry will be removed automagically
[01:28] <JanC> shwag: this is not a support channel...
[01:28] <shwag> my bad
[01:29] <JanC> and tehre is no kernel in the -smp package
[04:53] <BenC> Paravirtualization support (EXPERIMENTAL) (PARAVIRT) [N/y/?]  (NEW)
[04:53] <BenC> yummy
[04:58] <BenC>   10. Core 2/newer Xeon (MCORE2) (NEW)
[04:58] <BenC> hmm...wonder if it's worth it to do a Core2 kernel
[05:04] <mjg59> Doubt it
[05:25] <bronson> BenC: building with dpkg-buildpackage did indeed get rid of the -rel- like you said.
[05:26] <bronson> But now it has the identical name to Ubuntu's package.
[05:27] <bronson> Is there any easy way to insert my version in the package name?
[05:27] <bronson> Something like EXTRAVERSION = .14-ubuntu1-vs2.0.2.1
[05:28] <bronson> ...  actually, I think I know the answer.  I need to add a changelog entry?
[05:30] <bronson> Is there any way with dpkg-buildpackage to only build 386?  These 5 hour compile cycles are killing me!
[05:51] <BenC> bronson: rm configs you don't want from debian/config/i386
[05:51] <bronson> BenC: thanks.
[07:00] <Game_Ender> Is this the proper channel to discuss compiling a kernel module from upstream?
[07:01] <Game_Ender> I am looking at the Attansic L1 Ethernet driver
[07:02] <lifeless> yes, I think so
[07:04] <Game_Ender> Can someone point me the right direction of what I would do with patch set once I get it?
[07:05] <Game_Ender> The driver is being worked on as a patch for 2.6.19
[07:05] <Game_Ender> So I could remove my current kernel module (compiled from the source on my motherboard CD)
[07:06] <Game_Ender> then try to apply the patch to ubuntu kernel module
[07:06] <Game_Ender> I would then have to configure the entire kernel to build that one module correct?
[07:12] <Game_Ender> well its off to sleep
[07:12] <Game_Ender> I should probably try when its not 11PM - 1AM in the US
[07:35] <joefso>   CC [M]   ubuntu/misc/dm-bbr.o
[07:35] <joefso> ubuntu/misc/dm-bbr.c:102:59: error: macro "INIT_WORK" passed 3 arguments, but takes just 2
[07:35] <joefso> ubuntu/misc/dm-bbr.c: In function 'bbr_alloc_private':
[07:35] <joefso> ubuntu/misc/dm-bbr.c:102: error: 'INIT_WORK' undeclared (first use in this function)
[07:35] <joefso> ubuntu/misc/dm-bbr.c:102: error: (Each undeclared identifier is reported only once
[07:35] <joefso> ubuntu/misc/dm-bbr.c:102: error: for each function it appears in.)
[07:35] <joefso> make[3] : *** [ubuntu/misc/dm-bbr.o]  Error 1
[07:35] <joefso> make[2] : *** [ubuntu/misc]  Error 2
[07:35] <joefso> make[1] : *** [ubuntu]  Error 2
[07:35] <joefso> i'm trying to compiles 2.6.19 on edgy
[07:35] <joefso> using make oldconfig
[07:35] <joefso> however, it fails as we see
[09:15] <gebruiker> 2.6.19 doesn't build on edgy
[09:22] <dade`> I think it does
[09:23] <gebruiker> YOU THINK?
[09:23] <gebruiker> jeejz
[09:24] <dade`> yes I can think
[09:30] <gebruiker> ubuntu/misc/dm-bbr.c:102:59: error: macro "INIT_WORK" passed 3 arguments, but takes just 2
[09:30] <gebruiker> ubuntu/misc/dm-bbr.c: In function bbr_alloc_private:
[09:30] <gebruiker> ubuntu/misc/dm-bbr.c:102: error: INIT_WORK undeclared (first use in this function)
[09:30] <gebruiker> ubuntu/misc/dm-bbr.c:102: error: (Each undeclared identifier is reported only once
[09:30] <gebruiker> ubuntu/misc/dm-bbr.c:102: error: for each function it appears in.)
[09:31] <dade`> how  do you compile it ?
[09:32] <gebruiker> sudo make-kpkg --rootcmd fakeroot --initrd --append-to-version=-1 kernel-image kernel-headers
[09:32] <dade`> is this a git kernel ?
[09:32] <gebruiker> yes
[09:32] <dade`> ok wait
[09:32] <dade`> https://wiki.ubuntu.com/KernelCustomBuild
[09:32] <dade`> read this
[09:33] <gebruiker> yes I did?
[09:33] <dade`> no you didn'y
[09:33] <dade`> t
[09:36] <gebruiker> dude
[09:36] <gebruiker> even if the code is *not* from git
[09:37] <gebruiker> the code fails with the same error when using linux-source-2.6.19_2.6.19-7.11.tar.gz
[09:38] <dade`> well, I don't know, but compiling a git kernel with that command is wrong.
[09:39] <gebruiker> there is no guide on compiling git kernels the proper way
[09:39] <dade`> I just gave you
[09:40] <gebruiker> kernelcostumbuild?
[09:40] <gebruiker> have you read it?
[09:40] <dade`> yes
[10:37] <gebruiker> what a bunch of crap dade` even invoke just 'make' makes the build fail
[10:38] <dade`> ..
[10:39] <gebruiker> ubuntu/misc/dm-bbr.c:102:59: error: macro "INIT_WORK" passed 3 arguments, but takes just 2
[10:39] <gebruiker> ubuntu/misc/dm-bbr.c: In function bbr_alloc_private:
[10:39] <gebruiker> ubuntu/misc/dm-bbr.c:102: error: INIT_WORK undeclared (first use in this function)
[10:39] <gebruiker> ubuntu/misc/dm-bbr.c:102: error: (Each undeclared identifier is reported only once
[10:39] <gebruiker> ubuntu/misc/dm-bbr.c:102: error: for each function it appears in.)
[10:39] <gebruiker> make[2] : *** [ubuntu/misc/dm-bbr.o]  Fout 1
[10:39] <gebruiker> make[1] : *** [ubuntu/misc]  Fout 2
[10:39] <gebruiker> make: *** [ubuntu]  Fout 2
[10:52] <gebruiker> BenC broke the tree ;\
[10:54] <lifeless> gebruiker: sounds like you are building against an upstream kernel, not an ubuntu one
[10:55] <gebruiker> no
[10:55] <gebruiker> it's pulled from git
[10:55] <gebruiker> according to the kernelGitGuide
[10:55] <gebruiker> i don't thing dm-bbr.c is in vanilla
[10:55] <lifeless> its not
[10:56] <lifeless> its part of the evms patchset
[10:59] <dade`> have you tried using 'AUTOBUILD=1 fakeroot debian/rules binary-debs ...' on a clean git source ?
[11:05] <gebruiker> how does one let it build it's own config without affecting the debian tree/
[11:05] <gebruiker> ?
[11:16] <gebruiker> UTOBUILD=1 fakeroot debian/rules binary-debs flavours=386 doesnt' even work
[11:16] <gebruiker> +a
[02:58] <zul> BenC: ping
[02:59] <BenC> zul: yo
[02:59] <zul> i was thinking that the vmi (vmware stuff) can go straight into the generic kernel but the xen bits of paravirt would need its own flavour...of course i would have to test tis
[03:03] <zul> *this
[03:03] <zul> damn i need more coffee
[03:56] <zul> hey kylem 
[03:57] <BenC> yay, ubuntu-2.6 is building again
[03:58] <zul> workqueues fixed?
[03:58] <BenC> workqueue, freezer, crypto API's, SLAB_* crap
[03:59] <zul> cool
[03:59] <BenC> 2.6.20 is a bigger leap than 2.6.19, which scares me
[03:59] <zul> heh ill break it again for you dont worry..:)
[03:59] <BenC> $ debian/rules printchanges | wc -l
[03:59] <BenC> 2423
[03:59] <kylem> jesus.
[03:59] <zul> ouch..
[03:59] <BenC> zul: upstream is doing a fine job of it already :)
[04:00] <dade`> now git is .20 ?
[04:00] <BenC> dade`: 2.6.20-pre
[04:01] <BenC> Keybuk: ping
[04:03] <Keybuk> BenC: yo
[04:03] <BenC> Keybuk: I think I figured out the missing bit for "the plan"
[04:04] <dade`> maybee this one will sleep WITH macbook
[04:04] <BenC> Keybuk: I was wondering how all this would work when udev didn't have a "rule" for device->driver, and we wanted binding to just work...udev had no info on this
[04:04] <dade`> (wow sexy)
[04:04] <Keybuk> go on?
[04:04] <BenC> Keybuk: So what I am going to do is make the kernel send a "match" event for when it would normally bind with a device, so that udev can send that bind to the driver
[04:05] <Keybuk> how do you mean?  over the netlink socket?
[04:05] <Keybuk> how would you know udev was on the other end?
[04:06] <BenC> if auto-bind is disabled, the kernel would send an event of some kind saying "this driver and device match, do something", and whatever is on the other end would do that thing
[04:07] <BenC> Keybuk: unless I'm missing something, in the plan you have now, if udev disables auto-bind in the kernel, there's nothing that says to actually do the binding on devices that don't have a specific driver rule
[04:09] <BenC> kylem: I don't see CVE-2006-4572 listed in your dapper changelog
[04:09] <kylem> BenC, i still haven't heard back from patrick, i pinged him again last night.
[04:09] <Keybuk> BenC: the plan was that there'd be a generic rule
[04:10] <BenC> kylem: So are we uploading dapper without 4572 fix?
[04:10] <Keybuk> make DRIVER= work like NAME=, so the first one sticks
[04:10] <Keybuk> then just do specific stuff early
[04:10] <kylem> BenC, yes, pitti wanted it uploaded because of a local root hole, iirc
[04:10] <Keybuk> and as a final rule, just have a general ENV{MODALIAS}=="?*", DRIVER="modprobe $env{MODALIAS}"
[04:10] <Keybuk> (where modprobe is the udev builtin thing)
[04:10] <zul> so breezy is ok as well since it doesnt have CVE-2006-4572 and its already been uploaded previously
[04:11] <Keybuk> BenC: the one thing I was thinking; bind and unbind override the usual device tables, yes?
[04:11] <BenC> Keybuk: Sure, that will load the driver, but I mean what will cause the bind?
[04:11] <kylem> BenC, 4572 isn't exactly what i'd call a critical hole...
[04:11] <BenC> kylem: Ok, just making sure I had everything
[04:12] <Keybuk> BenC: I was thinking we just make udev always do it
[04:12] <Keybuk> so as well as making /dev nodes, one of its other primary functions is to bind devices and drivers
[04:13] <Keybuk> so after processing a rule, if there's any DRIVER set, it binds it
[04:13] <BenC> Keybuk: but what if there's no driver set? :)
[04:13] <Keybuk> we'd set one from the alias tables?
[04:13] <Keybuk> as a default rule
[04:16] <BenC> ok
[04:45] <zul> i so much dislike rpm
[06:24] <joefso> where can I get a list of patches that are applied to ubuntu kernel tree?
[06:24] <zul> git
[06:24] <joefso> yes git can pull them in
[06:25] <joefso> howveer I want a _list_ of patches
[06:25] <joefso> that are applied to the src tree
[07:32] <BenC> joefso: Is this ubuntu-2.6?
[07:34] <bronson> Can anyone suggest a version number for my linux-vserver enabled kernel?  I'm basing it off kernel 2.6.17.1-10.35 and adding vserver 2.0.2.1
[07:35] <bronson> Would that be 2.6.17.1.vserver2.0.2.1-10.35?
[07:36] <bronson> Or should I change something else?
[07:42] <BenC> bronson: I actually suggest just making a new flavour
[07:43] <bronson> BenC: sounds good.  How do I do that?
[07:43] <BenC> bronson: Copy debian/config/i386/*.generic to *.vserver-2.0.2.1
[07:43] <BenC> and edit was needed
[07:43] <BenC> then do : debian/rules debian/control.stub
[07:43] <bronson> Ah, OK.
[07:43] <BenC> and do the normal build
[07:44] <bronson> Would it make sense to have generic-vserver2.0.2.1, server-bigiron-vserver2.0.2.1, etc?
[07:45] <bronson> That would make sense to me, anyway.  :)  I'll try it.
[08:44] <bronson> BenC: I also need to change the files in debian/abi/2.6.17-10.34/i386 right?
[08:44] <BenC> no
[08:44] <BenC> ignore those
[08:45] <BenC> bronson: Edit debian/rules and set skipabi=true
[08:45] <bronson> ah, ok.  Will do.
[08:45] <bronson> I notice that the kernel is .34 but the abi is still .33 in the 2.6.17 git tree.
[08:47] <BenC> .33 is not the ABI
[08:47] <BenC> the ABI is 10
[08:47] <BenC> .33 and .34, those are the release revs
[08:48] <BenC> it increments everytime we do an upload...the 10 is only incremented when the ABI changes
[08:48] <bronson> I mean, the directory is named debian/abi/2.6.17-10.33
[08:49] <BenC> right, we keep the previous abi's to compare with the current build
[08:49] <bronson> cool.
[08:49] <BenC> current ABI's are only known after the build, so we can't very well keep those in the upload
[08:49] <bronson> :)  got it.
[08:49] <bronson> thanks.
[08:56] <bronson> BenC: skipabi was true because I'm using AUTOBUILD=1.
[08:56] <bronson> I think there's a missing skipabi check at line 238?
[08:57] <bronson> That exit 1 always fires regardless of the value of skipabi.
[09:04] <bronson> Yes, adding '-a "$(skipabi)" != "true"' to debian/rules line 238 appears to work.
[09:16] <joefso> Benc Yes.
[09:17] <BenC> joefso: debian/rules diffupstream > ubuntu.diff
[09:17] <joefso> BenC, however i want to apply -rt but acpi problems
[09:17] <bronson> BenC: I just thought of something.  My packages are built from a different source tree than the ubuntu kernel.  But if I only change the flavor, then my packages will claim to be built from the regular Ubuntu kernel source.
[09:18] <bronson> I need to change the package name too?
[09:18] <joefso> BenC, would it beneift community if we would package -ck kernels ontop of the -generic patched kernels?
[09:18] <BenC> joefso: No
[09:18] <joefso> or s/lowlatency/ck
[09:18] <joefso> BenC, could you eleborate a bit?
[09:18] <BenC> lowlatency is just a config option change
[09:18] <joefso> i noticed hz change
[09:18] <BenC> I'm adding any any very obtrusive patches to our tree
[09:18] <joefso> but wha'ts the reason that -ck tree wouldn't benefit community?
[09:19] <BenC> it wont benefit our users
[09:19] <BenC> 1) Creating too many kernel package options confuses users
[09:19] <bronson> joefso: what -ck feature do you want?
[09:19] <BenC> 2) Adding huge patches to our tree makes it hard to maintain
[09:20] <joefso> well 1) we already have lowlatency in feitsy 2) ck isn't that dificult to main, most of the time it applies clieanly ontop of the git tree 
[09:20] <BenC> joefso: You are more than welcome to provide such kernel packages yourself though
[09:21] <BenC> joefso: You've no idea what it takes to maintain the kernel once you've added patches that modify stock kernel code
[09:21] <BenC> security, updates, changes from upstream, all these things break it
[09:21] <BenC> I just spent the past two days getting our ubuntu/* drivers to build under 2.6.20-pre git
[09:22] <BenC> that's easy because it didn't touch stock kernel code
[09:22] <joefso> well, most of the time con just takes vanilla and then inclues latest stable into his patchset. However just applying them from broken-out is not much work until now, atleast those a re my experiences. And I have used it for quite some time now. The only thing I havn't really done is benchmark them to ubuntu kernels.
[09:23] <joefso> well perhaps I should take it for testing through ubuntuforums?
[09:23] <joefso> and see where it gets me
[09:23] <joefso> and how the community reacts
[09:23] <BenC> joefso: What is in -ck that would be so beneficial?
[09:24] <joefso> mm-*prio
[09:24] <joefso> *-ionice
[09:24] <BenC> why are those patches not in mainline kernel?
[09:25] <BenC> that's not really a question, it's more of a statement
[09:25] <joefso> yes I noticed
[09:25] <BenC> they aren't in there because they aren't stable yet
[09:25] <joefso> did you ever had time to take a look at it?
[09:26] <BenC> give me a URL?
[09:26] <joefso> and I remember some time where andrew morton would put ck code into -mm
[09:26] <joefso> http://members.optusnet.com.au/ckolivas/kernel/
[09:27] <BenC> -mm isn't a stable tree by any means :)
[09:27] <BenC> eh, it already gets a big NO
[09:27] <BenC> latest is against .18, and we are doing .20pre
[09:27] <joefso> take a look at the patches dir
[09:28] <joefso> perhaps i(havn't looked yet) there are patches for .20pre in testing patches
[09:28] <BenC> even .19 is not good enough
[09:29] <joefso> and if it's worth con kolivas could even provide it, if we would just ask, or else fix up the broken diffs our selves. Form the point I have seen it all he does until now is keepon syncing code with current stable.
[09:30] <BenC> joefso: 33 changes files, and 125k diff
[09:30] <BenC> that's more than our current delta against the mainline kernel
[09:30] <BenC> by almost double
[09:30] <bronson> BenC: Instead of creating different flavors, I need to create packages with an entirely different base name?  Does that sound right or am I missing something?
[09:30] <BenC> bronson: Why?
[09:31] <bronson> Because if I only change the flavor, my package will still claim to be built from Ubuntu's source package.
[09:31] <bronson> It's not though...  I've applied the linux-vserver patch.
[09:32] <BenC> it will be linux-image-2.6.17-10-vserver package name though
[09:32] <bronson> But it still claims to be built from linux-source-2.6.17-10 right?
[09:32] <BenC> if you want that much differentiation from our source, I can't help you...way too much involved
[09:33] <bronson> Well, the source issues are solved.  It's the packaging issues that are stumping me.  :)
[09:36] <BenC> you're getting into common packaging questions that are probably best solved in #ubuntu
[09:37] <bronson> Am I?  Not many people there have dealt with control.stub...
[09:37] <bronson> Or kernel flavors.
[09:38] <BenC> but you want to change the source package
[09:38] <BenC> which actually is as simple as editing the changelog
[09:39] <bronson> Or building with -sa.
[09:42] <bronson> I guess you're right -- it's not a problem.  I must have screwed up reprepro somehow.
[09:43] <bronson> My package's source package: linux-source-2.6.17_2.6.17.1-10.34.vserver2.0.2.1.tar.gz  :)
[09:43] <bronson> I don't think there's quite enough version numbers in there...  maybe I could add grsecurity.
[10:31] <low_> hi
[10:32] <bronson> hi low
[10:43] <joefso23> hello
[10:44] <joefso23> I'm unable to use "!" when invoking dialog --yesno "tekst" 5 80
[10:44] <kylem> and?
[10:45] <joefso23> when i add a ! to the "tekst" I get: rror: Expected no more than 3 tokens for --yesno, have 5
[10:45] <kylem> how is this a kernel problem.
[10:45] <joefso23> damn wrong channel
[10:45] <joefso23> excuse me
[10:45] <kylem> ps: add a \
[10:46] <joefso23> no won't do, but anyway excuse me
[10:47] <kylem> works in zsh. ;-) try single quotes instead of double in bash.
[10:59] <bronson> BenC: When I run debian/rules debian/control.stub, a bunch of packages get "-ref" added to their names.
[10:59] <bronson> Is there an easy way to make -ref not appear?
[11:00] <BenC> bronson: no
[11:00] <bronson> So just live with it?  :)
[11:00] <bronson> OK.
[11:00] <BenC> you're trying to do stuff that the build system there wasn't designed to do
[11:00] <BenC> you're sort of on your own :)
[11:01] <bronson> True.  I can live with that.  Hope you don't mind if I ask you easy questions though.
[11:07] <BenC> joefso23: I wrote this up real quick, since your question about including patches comes up quite often
[11:07] <BenC> joefso23: It explains things in more detail
[11:07] <BenC> https://wiki.ubuntu.com/KernelPatches
[11:09] <bronson> BenC, can you tell me briefly where -ref comes from?
[11:09] <BenC> what do you mean by -ref?
[11:09] <bronson> linux-headers-2.6.17-10-ref
[11:09] <BenC> I don't know what -ref is
[11:09] <bronson> (from the debian/control file)
[11:10] <BenC> is that what it actually says?
[11:10] <bronson> Yes, it showed up when I ran debian/rules debian/control.stub.
[11:10] <bronson> I'll dig deeper.
[11:10] <BenC> if you actually see "-ref" then you likely buggered something to make it do that
[11:10] <BenC> head -1 debian/changelog
[11:10] <BenC> let me see that
[11:11] <bronson> The full line is "Package: linux-headers-2.6.17-10-ref"
[11:11] <bronson> not all names have -ref, just some.
[11:11] <bronson> here you go: linux-source-2.6.17 (2.6.17.1-10.34.vserver2.0.2.1) edgy; urgency=low
[11:14] <bronson> No, it didn't show up when I ran debian/rules debian/control.stub .  That went OK.
[11:15] <bronson> I'll dig into this further before asking more.  And start with a fresh git tree.
[11:17] <BenC> that's the problem
[11:17] <BenC> do not add the .vserver2.0.2.1 in the versioning
[11:19] <bronson> Ah, good.
[11:19] <bronson> Is there a place I can maintain a rev number?  I don't expect to get this package right the first time.  :)
[11:20] <bronson> Or do I just need to bump the .34 to .35 and diverge from your upstream package?
[11:21] <BenC> that's the idea
[11:21] <bronson> OK, will do.
[11:21] <bronson> Thanks.
[12:10] <cassidy> guys, i'll pay you a beer at next FOSDEM or GUADEC if you package the fix for this bug ASAP https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.17/+bug/63418  :)
[12:11] <cassidy> i just received my new laptop and it's very frustrating to not be able to use it ;)
[12:16] <BenC> cassidy: is this the ipw3945 softlockup when rfkill is on?