[01:26] <Keybuk> quest procwatch% sudo ./forkwatch
[01:26] <Keybuk> 1 -> 19414
[01:26] <Keybuk> 1 -> 19415
[01:26] <Keybuk> 1 -> 19416
[01:26] <Keybuk> 1 -> 19417
[01:26] <Keybuk> 1 -> 19418
[01:26] <Keybuk> 1 -> 19419
[01:26] <Keybuk> ...
[01:26] <Keybuk> why does the kernel keep spawning things
[01:26] <Keybuk> (at least I assume it's the kernel and not init :p)
[01:38] <Keybuk> hmm, something to do with threads
[01:41] <Keybuk> 1/1 -> 20348/6513
[01:41] <Keybuk> 	'evolution --component=mail '
[01:41] <Keybuk> 1/1 -> 20349/6506
[01:41] <Keybuk> 	'/usr/lib/firefox-3.0.6/firefox '
[01:44] <Keybuk> ah
[01:44] <Keybuk> I'm being stupid
[01:44] <Keybuk> if you clone() to make a new thread, the new thread shares the same parent as the old one
[01:44] <Keybuk> firefox and evo's parents are init
[01:44] <Keybuk> so a new thread will also have a parent as init
[01:45] <mjg59> Keybuk: Oops
[01:47] <Keybuk> mjg59: don't laugh :p
[01:48] <mjg59> Keybuk: I spent half of today trying to debug something before realising that I'd stubbed out the functionality last month
[01:52] <Keybuk> d'oh
[12:35] <Laibsch> I'm sure DKMS is nice and all, but I wonder if we're not going to see Ubuntu-supplied kernel modules as a separate package anytime soon (compiled with the help of dkms, I suppose)
[12:36] <Laibsch> I hope this is on-topic here, if not suggest a better channel, please
[12:36] <soren> Laibsch: I don't think I understand what you're saying.
[12:36] <Laibsch> Alright, I'll retry
[12:37] <Laibsch> virtualbox has a module.  that module used to ship in a separate package, but was available for ubuntu supplied kernels
[12:38] <Laibsch> That is not the case anymore.  I have to install dmks, linux-headers, lots of dev-packages and lots of other stuff pulled in by virtualbox-ose-source these days to compile the module myself
[12:38] <soren> Yes.
[12:39] <Laibsch> I wonder if ubuntu couldn't handle packaging that module (probably with the help of dkms) so everybody (including me) doesn't have to do that
[12:39] <Laibsch> Right now, I don't see any obvious reason it couldn't be done
[12:39] <soren> On the other hand, you'll never more upgrade your kernel and suddenly have virtualbox not working because noone bothered to upload a new virtualbox-modules-2.6.xx-newabi-foobar package and go through the whole process of getting it accepted, through the various queues and stuff.
[12:39] <Laibsch> I'm here to understand the situation
[12:40] <soren> ...which is exactly the problem dkms solves.
[12:40] <Laibsch> OK
[12:40] <Laibsch> But it still is inconvenient
[12:40] <Laibsch> I'm wondering if a PPA might help?
[12:40] <soren> How is it inconvenient?
[12:40] <soren> It's all automatic.
[12:40] <Laibsch> But I don't think dkms works in a PPA environment
[12:41] <soren> What do you mean+
[12:41] <soren> ?
[12:41] <soren> dkms runs on the target system, not on the buildd's.
[12:41] <IntuitiveNipple> I put DMS packages in my PPA 
[12:41] <Laibsch> Yes, that is what I was basically saying
[12:41] <IntuitiveNipple> s/DMS/DKMS/
[12:42] <Laibsch> soren: I think the previous situation was preferable, at least speaking from my POV
[12:42] <soren> IntuitiveNipple: You mean packages that actually run dkms on the buildd's or just a package that uses dkms when it's installed in the final system?
[12:42] <soren> Laibsch: Why?
[12:42] <soren> Laibsch: How is it inconvenient? It's /automatic/.
[12:42] <IntuitiveNipple> soren: Just regular DKMS packages... built on the target client
[12:43] <soren> IntuitiveNipple: Right, there's no reason that wouldn't work. They're regular packages.
[12:43] <IntuitiveNipple> I wrote a tutorial on how to do the packaging, if it would help
[12:43] <soren> IntuitiveNipple: We're not discussing how to create packages that use dkms.
[12:43] <IntuitiveNipple> ahh, sorry.
[12:43] <Laibsch> soren: i don't like all the packages pulled in.  You may have a fat HD, unlimited bandwidth and whatnot, I may not.  I just see the sources and all the associated things on my system as cruft.  If I wanted LFS, I'd go gentoo.
[12:45] <Laibsch> It's basically the same reason I use Ubuntu over Gentoo.  In that sense, I'm a binary-type-of-guy
[12:45] <Laibsch> I hope that makes sense
[12:45] <soren> dkms solves a very real problem:
[12:45] <Laibsch> I'm not disputing that
[12:46] <soren> We have lots of kernel modules that are built outside the kernel, but needs to be in sync with the kernel.
[12:46] <soren> During development, this is not all that bad, but if, after release, a security problem comes up that requires us to bump the ABI, there are a few options:
[12:47] <soren> a) Don't install the updated kernel until someone else has taken care of updating *all* the other packages.
[12:47] <soren> b) Install the new kernel and lose the functionality provided by the other packages.
[12:47] <soren> Neither is very useful.
[12:48] <Laibsch> Understood, if the kernel team itself can't handle *all* out-of-source kernel modules, fine
[12:48] <soren> They can't, and shouldn't.
[12:48] <soren> What if you have an extra module from a PPA?
[12:48] <Laibsch> I'm wondering if there isn't a way to make dkms one more step
[12:48] <Laibsch> source -> binary -> package
[12:49] <Laibsch> dkms stops at dkms AFAIK
[12:49] <soren> Again: How about the packages you get from a PPA?
[12:49] <Laibsch> I want package ;-D
[12:49] <Laibsch> soren: what do you mean?  what about them?
[12:49] <soren> Laibsch: They will obviously not be rebuilt by the kernel team or anything else automatic. Only your system knows that the package even exists.
[12:50] <soren> ...so you end up having to choose be between the two options I mentioned a few minutes ago.
[12:50] <Laibsch> I'm not following you
[12:50] <Laibsch> Let's concentrate on virtualbox for a minute
[12:50] <Laibsch> so things are clearer (at least for me)
[12:50] <soren> Ok.
[12:51] <soren> So, say you wanted a more up-to-date version of virtualbox than is in the archive, and you go and install it from a PPA.
[12:51] <Laibsch> That is also the case I'm most interested in, I don't use proprietary drivers, for example
[12:51] <Laibsch> no, that is not what this is about
[12:51] <soren> Says who?
[12:51] <soren> It's my example :)
[12:51] <Laibsch> Ubuntu vbox and Ubuntu kernel
[12:52] <soren> Ok, then.
[12:52] <Laibsch> Let's not make things complicated before I understand the basics fully
[12:52] <soren> Ok.
[12:52] <Laibsch> Situation before dkms: ubuntu provides package
[12:52] <soren> So, say you have linux-image-2.6.27-22-generic installed and virtualbox-modules-2.6.27-22-generic as well.
[12:52] <soren> Both from the archive.
[12:52] <Laibsch> after dkms: ubuntu provides source and automatic system for user to compile binary
[12:53] <soren> Note: Virtualbox is in universe.
[12:53] <soren> A security problem comes up that forces us to update the kernel in a way that breaks the ABI.
[12:53] <soren> So, to be safe from whatever was the security problem, you need linux-image-2.6.27-23-generic.
[12:53] <Laibsch> OK
[12:54] <soren> ...but since it's not the kernel team that maintains virtualbox-modules, it might take hours, days, or weeks before there's a virtualbox-modules-2.6.27-23-generic.
[12:54] <Laibsch> virtualbox-modules-2.6.27-22-generic isn't currently available, right? It's just to illustrate your point, do I understand correctly?
[12:54] <soren> Right, these are made up version numbers.
[12:54] <Laibsch> Yes, and that is where my PPA suggestion came in
[12:55] <soren> Oh, no.
[12:55] <Laibsch> Why not?
[12:55] <soren> If I don't get to talk about PPA's, neither do you :)
[12:55] <Laibsch> I for one would prefer that over the current solution
[12:55] <Laibsch> Be serious now, will you ;-)
[12:55] <soren> So, during the time between linux-image-2.6.27-23-generic comes out and virtualbox-modules-2.6.27-23-generic comes out, you can choose between being safe or having virtualbox.
[12:56] <Laibsch> Yes
[12:56] <Laibsch> I'd be OK with that
[12:56] <soren> Right, because virtualbox is not a critical function to you, or you don't care about security.
[12:56] <Laibsch> Given that the recompilation is automatic
[12:56] <soren> Eh?
[12:57]  * amitk thinks Laibsch is misunderstanding how PPAs work
[12:57] <Laibsch> Given that the recompilation is automatic it shouldn't take a dedicated team too long to update their modules packaegs
[12:57] <Laibsch> amitk: I think I do
[12:57] <soren> But it's not automatic!
[12:57] <Laibsch> I'm not a DKMS expert, though
[12:57] <soren> That's why we added dkms to /make/ it automatic.
[12:57] <Laibsch> yes, dkms is a good thing -> see my first sentence in this channel
[12:58] <amitk> Laibsch: someone has to upload a _new_ version of vbox to the PPA to make a new version available to you
[12:58] <amitk> it is not automatic, it brings us back to the original problem
[12:58] <Laibsch> What I don't think is so great is that currently things stop at the very first step in "source -> binary -> package"
[12:58] <soren> Laibsch: Your first sentence in this channel was the one I completely didn't understand. At all.
[12:59] <Laibsch> I'm wondering if it isn't possible to officially or inofficially continue to ship modules (can be a subset of those depending on dkms currently)
[12:59] <amitk> soren: Laibsch doesn't like things being compiled on his machine. He wants it to be available _automatically_ through PPAs
[12:59] <Laibsch> soren: vbox has to be rebuilt?  I think that isn't ture
[12:59] <Laibsch> true
[13:00] <Laibsch> It's the module that needs to be rebuilt
[13:00] <Laibsch> amitk: yes
[13:00] <Laibsch> thanks for clarifying
[13:00] <soren> Laibsch: Of course. I didn't mean to discuss userspace at all.
[13:00] <Laibsch> PPAs, or some other official or inofficial channel
[13:00] <soren> Laibsch: Well, you're free to set something like that up.
[13:01] <Laibsch> I'm willing to put some work into that
[13:01] <Laibsch> But I need help
[13:01] <Laibsch> help and guidance with what dkms does and how it works
[13:01] <soren> Then you need to find someone who /can/ and who also thinks it's useful. I'm only in one of those categories :)
[13:01] <amitk> soren: Laibsch: something like this - a new kernel upload (abi bumper) should automatically trigger a rebuild of all dkms packages in the archive and make their binary .debs available.
[13:02] <soren> amitk: That seems to be the stated goal.
[13:02] <Laibsch> amitk: Yes, that is what I'm looking for.  I think currently, it isn't done, or is it?
[13:02] <amitk> Laibsch: currently it can't be done
[13:02] <soren> It all means that the time from known vulnerability to patched system is longer.
[13:03] <Laibsch> amitk: because dkms doesn't do it and there is nothing else, right?
[13:03] <Laibsch> I wonder how complicated it would be to either extend dkms to also churn out packages or wrap something around dkms like is done with pbuilder and friends
[13:04] <amitk> dependencies handling in external kernel modules, automatic trigger support, package naming issues,
[13:04] <soren> Laibsch: Are you familiar with module-assistant?
[13:04] <amitk> and several other issues wil have to be solved. You should probably check on #ubuntu-devel for experts on this sort of thing.
[13:05] <soren> Laibsch: It's how some packages used to do this. It builds packages that you can install, but it can't be run automatically for various reasons.
[13:05] <Laibsch> soren: I used to run m-a a few times in the past
[13:05] <Laibsch> I wouldn't call myself familiar with it
[13:12] <Laibsch> BTW, this isn't really automatic
[13:12] <Laibsch> Error! Could not locate vboxnetflt.ko for module vboxnetflt in the DKMS tree.
[13:12] <Laibsch> You must run a dkms build for kernel 2.6.28-2-386 (i686) first.
[13:13] <Laibsch> Whatever that means, I hope google will tell me
[16:04] <apw> jbuncher, cool.  this a kernel issue, so we might as well have it here, #u-bugs is not really the right venue
[16:04]  * apw goes look at the 2.6.24.4 build logs
[16:06] <apw> jbuncher, could you confirm the /proc/version string from the .4 version
[16:07] <jbuncher> apw:  I just rebooted, hang on
[16:14] <jbuncher> apw:  "Linux version 2.6.24-02062404-generic (root@zinc) etc etc"
[16:23] <jbuncher> apw:  I have not been installing the headers, btw.
[16:24] <apw> jbuncher, yeah no worries if you'd needed them you would know by now
[16:25] <apw> seems that iwl has moved to l-u-m, will try and work out what to do to test this next
[16:25] <jbuncher> apw:  l-u-m = linux-ubuntu-modules?
[16:26] <apw> yeah
[16:26] <apw> of course there isn't one of those for a mainline kernel
[16:26] <apw> so ... we need anything 'moved' there turned on in mainliine builds
[16:26] <apw> not somethign thats trivial to detect automagically
[16:27] <apw> a royal pain
[16:28] <jbuncher> should I just enable "Intel Wireless WiFi Link Drivers" in the kernel config?
[16:30] <jbuncher> or would that not work (e.g., if the source ot make those modules has been physically removed from the source debs you posted)
[16:30] <apw> they are in there.
[16:30] <apw> i was jsut going to try a rebuild of the .4 with that enabled
[16:31] <apw> need to figure out how to do this in a safe manner
[16:31] <jbuncher> apw:  what would the "danger" be?
[16:32] <apw> the problem is how do i reenable it in such a way that each time i build a new .24.N build
[16:32] <apw> it will happen right and automatically without intervention
[16:36] <jbuncher> ok
[16:37] <apw> give me a couple of mins to think on it
[16:37] <jbuncher> sure thing
[16:56] <apw> jbuncher, ok i think i have something workable.  am rebuilding the .24.4 now, will let you know when its done so you can test before i rebuild and others
[16:58] <jbuncher> ok
[16:59] <apw> sadly it will take somewhat over an hour so no holding of breath
[17:03] <jbuncher> apw:  you don't happen to know of a tool that scans your hardware and then auto-configs a kernel, so you don't have to build modules for stuff you don't have/use, do you?
[17:04] <apw> jbuncher, nope, that would be nice.  i bought some bigger build engines to get round that issue
[17:04] <jbuncher> nice
[17:08] <IntuitiveNipple> I saw something that does exactly that last week... let me see if I can remember what it was
[17:09] <apw> easier than waiting for godot
[17:09] <apw> IntuitiveNipple, intresting
[17:09] <apw> just when i've stopped being allowed to make small kernels :(
[17:10] <IntuitiveNipple> Trouble is, when you're visiting tons of search-engine hits a day, it's hard to remember when or where :)
[18:01] <apw> Keybuk, the work you are doing with netlink, does that make the work on pselect et al for arm less urgent?
[18:05] <apw> jbuncher, ok the 2.6.24.4 is rebuilt if you could test that sometime
[18:06] <jbuncher> apw: alright, I need to head to work and get some lunch, but I should be able to get to it this afternoon.  Is it on the same page as before?
[18:07] <apw> jbuncher, yep replaced the originals with some with iwl stuff turned on i hope
[18:07] <apw> if you could report back in the bug too that would help me keep track
[18:07] <jbuncher> apw:  sure thing, thanks again for all your work.
[18:08] <apw> no problem, be nice to get that one nailed
[18:32] <mgolisch> anyone here?
[18:32] <mgolisch> which dump facilities does ubuntu provide?
[18:37] <Keybuk> apw: no, it has nothing to do with udev
[19:36] <jbuncher> apw:  Success on both counts.  The .4 recognized my wireless card, as well as being able to connect to the wireless.  I'm posting in the bug thread now
[23:09] <apw> jbuncher, i will re-build the remainder and let you know when they are done
[23:27] <mgolisch> crash dump facilities in ubuntu kernels?
[23:28] <mgolisch> anyone?
[23:32] <apw> i think crash dumping is a jaunty goal
[23:35] <mgolisch> i wonder why its not there yet
[23:35] <mgolisch> for example ubuntu ships the crash tool for debuging crashdumps since ages
[23:35] <mgolisch> i allways wondered why there is no crashdump stuff
[23:36] <mgolisch> i mean srsrrly they try to do server stuff, i wouldnt want a server without the ability to get dumps of kernelpanics
[23:37] <mgolisch> enough ranting :) ill wait for the next release then
[23:37] <mgolisch> :)
[23:38] <apw> i would't take my word for it, i know some stuff is going on in that space for jaunty
[23:38] <apw> it may be workable if you have the recipe on server
[23:39] <apw> mgolisch, have you asked on #ubuntu-server ?  they would have the definative answeer
[23:39] <mgolisch> ill try that