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