=== gnomefreak [n=gnomefre@ubuntu/member/gnomefreak] has joined #ubuntu-kernel === rikai_ is now known as rikai === holycow_ [n=a@mail.wjsgroup.com] has joined #ubuntu-kernel === zul [n=bob@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel === sevrin [n=sevrin@202.75.186.154] has joined #ubuntu-kernel === sdrik` [n=sdrik@ip-93-4.dsl.newel.net] has joined #ubuntu-kernel === joejaxx [i=joejaxx@alpha.joejaxx.net] has joined #ubuntu-kernel === joejaxx [i=joejaxx@ubuntu/member/joejaxx] has left #ubuntu-kernel [] === joejaxx [i=joejaxx@ubuntu/member/joejaxx] has joined #ubuntu-kernel === ake [i=ake@k214-e.hpc2n.umu.se] has left #ubuntu-kernel [] === Lure [n=lure@external-7.hermes.si] has joined #ubuntu-kernel === fabbione [n=fabbione@vpn-nat.fabbione.net] has joined #ubuntu-kernel === gnomefreak [n=gnomefre@ubuntu/member/gnomefreak] has joined #ubuntu-kernel === marcin_ant [n=marcin@aim181.internetdsl.tpnet.pl] has joined #ubuntu-kernel === rikai_ [n=rikai@unaffiliated/rikai] has joined #ubuntu-kernel === tuxmaniac [n=aanjhan@unaffiliated/tuxmaniac] has joined #ubuntu-kernel === pkl_ [n=phillip@lougher.demon.co.uk] has joined #ubuntu-kernel [12:45] BenC: hi [12:46] pkl_: Hey [12:47] BenC: a good time to discuss kernel devel? [12:47] pkl_: Yeah, give me about 5 minutes to finish up something [12:47] BenC: no problem. [12:55] pkl_: Ok, I assume you've done a git clone from either kernel.org or rookery...if you did kernel.org, I would suggest rebasing on the rookery one [12:56] pkl_: I also assume you've read the git-guide on the wiki and have used git before, so I'll skip all the redundant how-to-use-git stuff :) [12:56] Yeah, I used kernel.org. Rookery is the Ubuntu repo? [12:57] Yes, I've used git before. I started playing around with it in its early development [12:58] On rookery.ubuntu.com /srv/kernel-team holds our repos [12:58] it's the same as what's on kernel.org, but you wont be able to get to any non-public branches if and when we create them [12:58] I have _not_ used it for +1 year, and it seems more capable now. Though kernel.org is now extremely slow :-) [12:58] then there's that :) [12:59] pkl_: Have you ever used kernel-package/make-kpkg from debian before? [01:00] No. I've always been extremely disto agnostic. I use so many distros that I used commands that work across them all. I daresay it will b easier to learn the Debian processes :-) [01:01] it's actually really horrible because it's a tool meant to work with almost any kernel version for almost any flavor of kernel [01:01] My guess is make-kpkg builds the kernel, modules, installs the kernel and rebuilds the initrd/initramfs as necessary. [01:02] we'll actually stop using it for feisty+1, but since we have 4 releases using it now, you'll need to get used to it a little [01:02] initramfs-es are built on installation. [01:02] since you want to update them when you update bits of them, like usplash or something. [01:02] It packs all of it up, and includes install hooks in the package for updating the boot loader and calling other tools to do the initramfs rebuild [01:03] right, other packages can include initramfs hooks, so it's an at-install function [01:03] so, the initramfs is not explicitly rebuilt as part of the kernel install? [01:03] it is as part of the install [01:03] but there is no initramfs in the kernel package [01:04] the kernel postinst hook calls update-initramfs [01:04] which does the dirty work [01:04] pkl_: Anyway, make-kpkg is only semi important for our work === fabbione [n=fabbione@modemcable178.77-70-69.static.videotron.ca] has joined #ubuntu-kernel [01:04] we use it almost like you'd use "make" [01:04] ok. === fabbione [n=fabbione@modemcable178.77-70-69.static.videotron.ca] has joined #ubuntu-kernel [01:05] the main part of the build is the ABI, and flavours/configs [01:05] In debian/config/ you will find must of the ugliness that tells the build system what kernels to build for each architecture [01:05] debian/config/$arch/ contains the per architecture config files [01:06] there is a debian/config/$arch/config that contains the common parts for all flavours, and debian/config/$arch/config.$flavour for each specific flavour [01:06] the build cats both of them together and does a "make oldconfig" to get things started [01:07] the oldconfig will fail if there's any new questions that the config does not explicitly answer [01:07] To update all the configs, you can do "debian/rules updateconfigs", this rebuilds all of the architectures [01:07] and splits them using some magic in debian/bin/ [01:08] The splitting is done to make it easier to keep configs consistent per architecture [01:08] ok [01:08] morning pkl_ [01:08] Stop me if you have any questions [01:09] morning fabbione. It's a really nice Sunny morning here in Wales., for a change! [01:09] So when the build starts, it basically creates a copy of the source in debian/build/build-$flavour/ [01:09] for each flavour, cats the config, and does the build, then completes it by creating a .deb [01:09] BenC: ok. I'm trying to look through the kernel while you say this.. [01:09] feh.. it's -25 C here in Montreal [01:09] fabbione: Blame Canada :) [01:09] toasty [01:10] Canada = the biggest sperm bank in the world.... [01:10] it's enough you get out to freeze and store [01:10] Global warming hit Cabada yet? [01:11] s/Cabada/Canada/ :-) [01:11] pkl_: The other nifty thing we do is track the ABI of our kernels... [01:12] The debian/abi directory contains the ABI for the last uploaded release of the kernel [01:12] after the build, it checks this (via a simple diff) to see if the ABI changes [01:12] Ok. ABI to me means App Binary Interface?? How do you track that? [01:12] We encode the ABI into our package name, and into the kernels EXTRAVERSION [01:12] Modules.srcver [01:13] each exported function (vmlinux and modules) is tracked in there with a hash of the function [01:13] the hash is of the function name, it's arguments and return value [01:13] this is something the kernel does already, we just use it to check if it changes [01:14] so our package package versions are something like 2.6.20-6-generic, which EXTRAVERSION=-6-generic, and 6 is the ABI [01:14] Ok. Sounds good. I didn't know Debian did that. [01:14] generic is the flavour [01:14] I don't think debian does [01:14] pkl_: (we'd had problems with modules outside the kernel packages breaking unexpectedly on what we thought were minor updates - this stops us getting caught out by forcing us to rebuild when the interface changes) [01:14] Debian does now [01:15] pkl_: Do not confuse anything we do with what debian may or may not do :) [01:15] at least as far as the kernel is concerned [01:16] pkl_: So, when you do a test build for a new kernel, if the ABI changes, you would see it error with that message, and you would bump the ABI [01:16] how you bump the ABI is different with feisty and pre-feisty [01:17] pre-feisty, you do "debian/rules bumpabi", and feisty you simply edit debian/changelog and change it in there (e.g. 2.6.20-6.12 to 2.6.20-7.12) [01:17] Note, our minor version (.12 in the above example) is ever increasing, it does not restart at 1 when the ABI (major) increases [01:18] The debian/config dir only contains dirs for architectures supported by Ubuntu. Hence no arm etc. This implies parisc is supported? [01:18] it's sort of a rolling counter of the builds we've done [01:18] pkl_: parisc was supported, but hasn't been built since dapper, AFAIK [01:18] I left it in there because I keep hearing rumors that lamont will revive it...and maybe that Kyle dude will fix it :) === Keybuk [n=scott@wing-commander.netsplit.com] has joined #ubuntu-kernel [01:19] pkl_: Technically it doesn't mean we support it (like x86, ppc, x86_64, sparc), it just means we build it...parics and ia64 are community supported architectures [01:20] ok [01:20] we build it, but only if non-paid people take the time to get it going [01:20] pkl_: any questions so far? === Eruantalon [n=hans@56345442.rev.stofanet.dk] has joined #ubuntu-kernel [01:21] I'm saving all this to put into a wiki BTW, so a nice FAQ would be nice === Nafallo understands it so far :-) [01:22] lots of niceness [01:22] Simply editing the changelog to update ABI implies the build process checks this? [01:22] yes [01:23] it will rebuild the debian/control file, which lists all the packages [01:23] Obviously the changelog is not simply human readable as in many projects [01:23] debian/control is built from debian/control.stub, which is further generated from debian/control.stub.in [01:23] no, debian/changelog is very formatted [01:24] in fact, in feisty, you do not edit at all, except to start a new release, or change the abi === chuck_ [n=bob@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel === zul [n=chuck@ubuntu/member/zul] has joined #ubuntu-kernel [01:24] all the changelog entries are generated from git using "debian/rules insertchanges" [01:24] "debian/rules printchanges" gives you a running list [01:24] kylem: i dont think you want to go outside today -39C with the windchill [01:24] "debian/rules help" if you forget any of this [01:25] kewl :-) [01:25] Hey BenC [01:25] hi zul :-) [01:25] hi Nafallo [01:25] pkl_: In case it isn't obvious, "debian/rules" is the primary build entry for all debian packages :) [01:25] zul: hey [01:25] pkl_: Which brings us to actually building this bohemoth [01:26] pkl_: When I do test builds, I simplify things, and just run "fakeroot debian/rules binary-debs" [01:26] (you'll want to install the fakeroot program, it's a debian developers best friend) [01:27] pkl_: If you only want to build a single flavour, useful for quick tests, do "debian/rules binary-debs flavours=foo", e.g. foo can be generic, which is the most common flavour [01:27] either of those will leave you (if the build succeeded) a package in debian/build/ [01:27] which you can install and test [01:28] For feisty, before any upload, I usually do full builds on x86, x86_64, powerpc, sparc and ia64, and I boot at least one kernel from each of those [01:29] You wont have to worry about feisty uploads, but for security uploads, I would suggest doing at least as much, maybe a little more testing (considering it's a stable release) [01:29] pkl_: absorb this, I'll be back in 10 minutes === Lure likes this tutorial... ;-) [01:30] fakeroot debian/rules binary-debs" will build all flavours for the current architecture? Can you build for all architectures (which would require appropriate cross-compilation environment) [01:32] pkl_: no you can't cross compile yet [01:32] it would require a bunch of changes in debian/rules [01:32] pkl_: we have porting machines for that [01:32] where you can build sparc/ppc etc.. [01:34] Yes, I didn't think you could, but I thought I'd check... [01:35] Who hosts the porting machines? [01:37] Canonical. [01:37] they're in the London DC [01:38] pkl_: The canonical wiki lists the machines, and also shows you how to use ssh proxy to get to them [01:39] pkl_: There's one exception to the flavours bit, the lowlatency kernel is built as a modified generic kernel..it used debian/config/$arch/config.generic and manually seds some things [01:39] you can ignore it for now, since it's not an officially supported kernel [01:39] but just so you know how it gets created :) [01:40] if the porting machines are in London, you must have someone around to push the button if something goes wrong :-)( [01:40] they're generally just for building - you don't have root on them [01:41] ok. You can use the porting machines to build, but you mush have a machine locally (or ask someone who has) to build the new kernel. No problem, just need to understand this. [01:42] build == boot. [01:42] "to build the new kernel" -> "to boot the new kernel" [01:42] correct. [01:43] or just upload to feisty. :-P === Mithrandir hides. [01:43] since Mithrandir is the release manager I think we should do what he says ;-) [01:43] Or just use Mith for all your guinea pig needs [01:44] pkl_: One thing to remember (and Mith will no doubt re-enforce this) the buildd's are not test build systems :) [01:44] BenC: I only care about amd64, so as long as you don't break that, I'm happy. ;-) [01:44] the buildd's are the machines that actually build the source we upload for users to eventually use [01:44] and if it builds, it ends up in the archive, which means that people will use it. [01:44] when we upload, we should expect it to build [01:45] right, so builds sent there are also not considered "testing"...especially in the cases of security updates [01:45] feisty is sort of testing, but we try to not make it so bad :) [01:45] word :-) [01:46] Yes, I actually do have all the support architectures at home , but not hppa, or ia64. [01:46] don't worry about either of them...for stable releases, ia64 and hppa are not even considered important, and for devel like feisty, it's only partially important [01:47] I'm not sure that security is supported for ports.ubuntu.com architectures [01:47] i.e. if mark says that we will support either of them next cycle, they might be important ;-) [01:48] BenC: they are probably just built, but I think we can ignore arch-specific CVEs :-) [01:49] pkl_: Any questions thus far? [01:49] pkl_: while it's nice if you don't break hppa and ia64, I'm not too fussed about them if they do end up blowing up slightly. [01:49] This is a lot of material, and will be doing the wiki for it today [01:50] like, hppa is a catastrophe right now due to threads being fucked. [01:50] I think sparc kernel is still FTBFS on breezy :) [01:50] hehe [01:50] no wonder I'm never up this early... the Sun is shining right in my eyes at this time of the morning [01:50] that's your own fault for using sparc hardware === cjwatson runs [01:51] LOL [01:51] ahhaha [01:51] Sound ok. The obvious thing to ask next is what do you do to 'test' a build. Is this a defined framwork, automated, regression checked for etc. Or is it ad-hoc? [01:52] so far, ad-hoc. iwj is building some automated test suite, but I'm not sure how it applies to the kernel. [01:52] pkl_: "hey the patch applies! It's ready for stable.." [01:52] :P [01:53] Who still uses hppa? It not as bad as MIPS (any desktop MIPS must be 10+ years old), but HP hasn't built parisc systems for years...? === fabbione does [01:54] I used to use one 12 years ago! === fabbione pats his 2 amiga's [01:55] pkl_: they do. [01:55] they finished the last CPU design of the line less than a year ago, iirc. [01:55] Running HPUX unfortunately (with such a broken compiler/asembler you had to use GCC and gas). [01:56] I still have my Archimedes/QL/SPectrum stull but never turn them on now :-) === larsemil [n=larsemil@81-233-250-172-no13.tbcn.telia.com] has joined #ubuntu-kernel === pina [n=germinta@unaffiliated/pina] has joined #ubuntu-kernel [01:57] I used to know the people who wrote parts of Amiga DOS (it was based on Tripos) [01:58] pkl_: i have a zx81 still working.. [01:58] i did sell the Spectrum at the time :) [01:58] I butchered mine for a micromouse I built back in 1985 :-( [02:00] my Spectrum+ died of terminal keyboard failure (repaired N times). bit of a standard problem with that model I think :( [02:00] pkl_: I have some scripts that I use to build across all my machines === Nafallo waits for the lkm and lm tutorials :-) [02:01] pkl_: I have them in debian/bin/bens-build-scripts/ in feisty [02:01] no docs, just a chunk of shell code [02:02] Yes, the membrane keyboard practically disintegrates. Becomes brittle and snaps. The keybaord on my Dragon 32 still works (even it's older) because it used old-fashioned makde/break leaf contact keyboard. [02:02] pkl_: As far as testing, goes, I just do boot testing on all the machines I have (which is too many to list) [02:04] I don't think Ubuntu is anyworse at testing that other distros AFAIK. Testing is, however, a bit of a disaster however WRT to the kernel. === larsemil_ [n=larsemil@81-233-250-172-no13.tbcn.telia.com] has joined #ubuntu-kernel [02:05] Ok. All sounds good so far :-) [02:06] pkl_: in the case of you managing to get a busted kernel into the archive (as in, completely busted), please do get in touch and we can make it so that nobody new is getting the kernel at least, and through that limit the damage. === bubbasucks [i=bubba@ritalin.simplylinux.org] has joined #ubuntu-kernel [02:07] Do you test the security fixes/patches. Some of the security notices are (to say the least) hypothetical, and almost impossible to trigger? [02:07] pkl_: there's some docs on the ubuntu wiki about stable release uploads [02:08] pkl_: We usually patch any CVE's that have been patched in 2.6.x.y git [02:08] sup ben [02:08] even if hypothetical [02:08] hey bubba [02:08] StableReleaseUpdates on the wiki mostly just covers non-security uploads [02:09] cjwatson: There's a kernel wiki regarding it's special case for proposed [02:09] I think SRU wiki links to it [02:09] cjwatson: Isn't there a wiki page for busted stable/security uploads from germany sprint? [02:10] hey Mr Wilson [02:11] https://wiki.ubuntu.com/StableReleaseUpdates [02:11] ^^ SRU [02:12] BenC: I think so, but I don't remember the page name [02:12] yay, lrm built [02:12] cjwatson: fabbione says it's canonical wiki [02:13] yeah it's somewhere there.. i am looking for it [02:14] who here has an atheros wifi? [02:14] I have... [02:14] I need someone to actually tell me if it works with the lrm I just uploaded to feisty [02:14] whats that fab [02:15] BenC: no luck with rt2x00 I guess? :-) [02:15] I can do that...though I'll have to reboot this machine [02:16] rt2x00 got demoted [02:16] using rt2x00-legacy stuff in git, but that's not uploaded yet [02:16] oh. why so? [02:16] demote that is [02:17] not that I [02:17] rt2x00 drivers don't build with the new d80211 stack [02:17] ouch [02:17] wow. ben's up early. [02:18] morning. [02:18] hey kylem [02:18] hey kylem [02:18] kylem: he wanted the sun in his eyes ;-) [02:18] lol. [02:18] hi kylem :-) === kylem waves. [02:18] sweet, the module checking code kicked in and caught some missing modules for -7.12 :) [02:18] kylen: Been up for 5 hours now, your just lazy :P [02:19] BenC, ... damn dude. [02:19] wow that is quite some process [02:19] so sounds like i need to get my old kernel working [02:20] pkl_, kylem: I want to arrange a day this week (and hopefully every week) when the kernel team can meet regularly...how does 10AM EST, 3PM UK sound? [02:20] glad kernel's are special cases [02:21] probably tomorrow or wed [02:21] sounds fine. [02:21] bubbasucks: I would say that kernels made the rules instead of breaking them, but I'd probably get smacked down for that :) [02:23] kylem: ? [02:23] ha! [02:24] sounds like the buerocracy at my old job [02:25] heh, not really any bureaucracy here, just general put-you-in-your-place kind of stuff :) === matt4magic [n=matt4mag@iderifr.hh.se] has joined #ubuntu-kernel [02:25] Where did you work? I know places with so much bureaucracy you could hardly get anything donw. [02:26] canonical has the least bureaucracy of any place I've worked for [02:26] we're starting to get some from basic growth, but it's the well needed kind [02:29] heh [02:29] brb [02:29] The important thing is to avoid getting management types, especially ones where doing things by the book, and holding meetings are all important. [02:30] A three letter company I used to work for springs to mind. === bubbasucks [i=bubba@ritalin.simplylinux.org] has joined #ubuntu-kernel [02:32] BenC, bubbasucks: the problem bubba has might be a genuine driver bug. the pci is is in megaraid_mbox [02:32] (checked the sources and module is loaded by initramfs) [02:32] fabbione: is it an AMI? [02:32] but there are no /proc/partitions [02:32] BenC: dunno.. it's in the email bubba did send to us.. wait [02:32] How many people does canonical have working with the kernel? Any of them do upstream kernel development or is it just packaging? [02:32] fabbione: Because I also have an AMI machine that is listed in mbox, but it's ignored because it isn't the actual raid device (it's just the processor) [02:32] no driver is loaded for it [02:32] 0000:02:07.0 RAID bus controller: American Megatrends Inc. MegaRAID [02:32] (rev 02) [02:32] Subsystem: Dell PowerEdge Cost Effective RAID Controller [02:32] ATA100/4Ch [02:33] BenC: ah... and what't the fix for that? [02:33] Eruantalon: we have 4 as of today (Tim just started today), I used to do upstream linux1394, and Phillip does squashfs which will hopefully be upstream soon [02:33] Eruantalon: Kyle does parisc === fabbione does sparc and cluster sometimes and so to speak.. ;) [02:34] fabbione: No fix, it's just not used...there would be another device that actually handles the raid, and if it's what I'm thinking, then it needs edgy-security to work [02:34] oh ok.. i guess we can get him to test that [02:35] pkl_: Do you want to attempt a simple build from feisty git to see if you've got things going correctly? [02:35] pkl_: You'd need kernel-package, kernel-wedge, fakeroot, debhelper and build-essential installed to start off [02:36] or apt-get build-dep linux-source-2.6.20 [02:36] and fakeroot [02:36] Yes, I'm in the process of doing that. I already discovered (though trail and error) the things I need :-) [02:36] yeah, that works too :) [02:37] BenC: I just realised that you are the guy i read about in Behind Ubuntu that lives on a farm :-) [02:37] pkl_: initially, if you have things to commit, run them past kernel-team@lists.ubuntu.com (which you need to subscribe to) [02:38] Eruantalon: hehe, my infamous interview :) [02:38] Squashfs will, hopefully, be upstream early this year. The work I was asked by LKML to do, has been done. There's just one or two more little-ish things to be done before I resubmit. [02:39] Yup, I'm subscribed. === BenC goes to do some wiki editing [02:42] BenC, anytime is fine. sorry, was in the shower. [02:42] hopefully I can bring it up to snuff and inline with jono's suggestions [02:42] BenC: put meeting in topic maybe? :-) [02:42] kylem: You shower? Are you really a kernel hacker? [02:43] lol [02:43] yes, a clean one. [02:43] not very clean shaven though :) [02:44] BTW, I notice you've still got Squashfs 3.1 in the feisty kernel :-) [02:44] pkl_: it's been working, so we haven't wanted to touch it :) === brottman [n=brianr@216.120.143.226] has joined #ubuntu-kernel [02:45] BenC, haha. [02:46] Squashfs 3.2 has some nice updates. It been harden to be more resiliant to corrupted filesystems (as a result of MoKB and a CVE). It also has NFS support, which might be useful for one of the Ubuntu specs. [02:47] pkl_: just push the crack to the git tree ;) [02:47] ben will love that :) [02:49] s/crack/crap/g ? [02:49] i think we have 3.1+patches in {dapper,edgy} [02:50] BenC: btw.. i just made you owner of the kernel team in LP... i think it was about time.. [02:50] fabbione: muchos gracias [02:50] BenC: hehe i just so totally forgot about it ;) === fabbione officially passes the baton to Ben with only almost 2 years delay [02:50] pkl_: crack == slang for new shit [02:51] crap is something we reserve for xen only :) [02:51] fabbione: :-O [02:51] ugh. [02:51] fabbione: Better late than never :) [02:51] fabbione: two years already? [02:51] :-) [02:51] 183 N GNU/kFreeBSD Ma Bits from the Debian GNU/kFreeBSD porters [02:51] why do i even bother trying to read my email? [02:51] 1.33 years [02:52] kylem: lol...crack or crap? :) [02:52] ah. thought it wasn't two :-) [02:52] coffee, cigarette... [02:54] I avoided Xen for a long time, not having an Intel machine for a long time. It is really that bad? [02:54] worse. [02:54] hmm [02:55] oh its not that bad....hah.. [02:55] The guys that wrote are pretty clever. Ian Pratt was one of my drinking mates in Cambridge 11+ years ago. [02:57] Lhype/Lguest/Rustyvisor seems to be going quite well. Anyone manage to see the talk at LCA? [03:00] Xen is lovely as long as you don't look at the code. :-) [03:04] pkl_: I've been using kvm a lot, and it's actually pretty cool [03:05] pkl_: looking at the xen code has a tendency to make you go crazy or make people think that you are crazy :) [03:10] BenC: do you think you can take a look at https://launchpad.net/ubuntu/+bug/83412 ? [03:10] BenC: i am not 100% sure if it's the testcase or the kernel.. [03:10] i did check the latest ltp version and it reports the same error [03:12] fabbione: Could be 32-bit/64-bit thunking problem [03:12] it doesn't look like it [03:12] I assume LTP builds/runs 32-bit code [03:12] how can I reproduce it? [03:12] i would like to exclude the Niagara vs other sparc cpu case first [03:12] 100% on niagara [03:13] my e3k isn't booted right now...been too cold to walk out to the barn to power cycle it :) [03:13] Reproduction steps: [03:13] 1. Install the ltp-kernel-test package. [03:13] 2. Run /usr/lib/debian-test/tests/linux/testcases/bin/shmt09 [03:13] ok.. it's a minor problem for what i can tell [03:14] but i want to make absolutely sure it's a kernel issue before i ask david to look at it [03:14] BenC: define toocold ? [03:14] :P [03:15] too cold for us Virginians [03:15] ah ok ;) [03:15] you should teach one of your cows to turn it on/off [03:15] "Clarabella: turn on!" [03:15] you can keep your colder than Antarctica weather up there in Montreal :) [03:15] "Clarabella: turn off!" [03:15] lol [03:15] or just buy a power switch [03:16] + remote ;) [03:16] fabbione, how's mtl this morning? [03:17] kylem: cold... -20C and -30 with windchill [03:17] not that cold [03:17] bummer. -37 here. === larsemil_ [n=larsemil@81-233-250-172-no13.tbcn.telia.com] has left #ubuntu-kernel ["Lmnar"] === brottman [n=brianr@216.120.143.226] has joined #ubuntu-kernel [03:25] BenC: 32/64 bits makes no diff [03:25] fabbione: it's cold either way, then? [03:26] lamont: yeah [03:26] only -1C here [03:26] up [03:26] err, yo [03:26] er, -2 [03:26] lucky lamont [03:27] then again, you have like 10 ft of snow? [03:27] kylem: it's been bitter cold the last few days... [03:27] still have snow piles in town. out here, we didn't pile it up so much, so it's mostly melted. [03:27] ah. [03:27] or blown to kansas [03:27] haha. === ivoks [n=ivoks@7-90.dsl.iskon.hr] has joined #ubuntu-kernel [03:35] BenC: lvm requires hardware VT support, which I have not (yet) got, except for the Mac which I tend to run in Mac OS X. Pity because it seems quite good. [03:35] s/lvm/lkm/g [03:35] kvm? [03:36] Yeah, I have three boxes here with Intel support I've been testing it on [03:36] yeah, that's what it's called. [03:37] Silly, three letter acromyns. Kvm always makes me think of Java (there is or was a Java VM called Kvm). [03:37] pkl_: You have your launchpad account setup? [03:37] kvm makes me think of keyboard-video-mouse switch [03:38] he [03:38] h [03:38] pkl_: Make sure you do join the kernel-team at https://launchpad.net/~ubuntu-kernel-team [03:38] I'll check. I set it up months ago, but I'm not what it is setup. What should I have? [03:40] pkl_: You should have a launchpad account, done the Code of Conduct, added your gpg and ssh keys, etc. [03:44] is it possible to get newer 3w-9xxx in dapper during updates? [03:45] (for next kernel release?) [03:49] ivoks: In proposed updates yes [03:51] BenC: do you need diff? [03:51] :) [03:51] argh... git, right? :) [03:52] yes, and send it to kyle [03:52] no, send it to kernel-team@lists.u.c [03:52] ;-) [03:52] ii linux-image-2.6.17-10-generic 2.6.17.1-10.34 [03:52] ok :) [03:53] BenC: according to bubba, he has -security [03:54] hmm...not sure then, I'd have to check the dmesg/lspci output again to see what's up [03:54] [4294671.621000] megaraid: found 0x101e:0x1960:bus 2:slot 7:func 0 [03:54] (this is from 2.6.12) [03:55] 02:07.0 RAID bus controller: American Megatrends Inc. MegaRAID (rev 02) [03:55] 02:07.0 0104: 101e:1960 (rev 02) [03:56] AMI, yeah, that's just a virtual device for the RAID processor [03:56] no module is supposed to use it [03:56] what's the sub vendor/device? [03:57] i received my CSA v11 today [03:57] where can i get sub/vendor device? [03:57] lspci -vvn [03:57] the second line I think [03:58] 02:07.0 0104: 101e:1960 (rev 02) [03:58] Subsystem: 1028:0511 [03:58] you guys want to read this? [03:58] bsd vs linux debate [04:00] i doubt it's a debate, probably holly war :) === BenC avoids counter-productive debates [04:00] not a debate actually [04:01] its a summary acutally what the author thinks of the two [04:01] i thought holly wars only happened at Christmas time [04:01] http://www.over-yonder.net/~fullermd/rants/bsd4linux/bsd4linux1.php [04:01] we don't care. [04:03] BenC: is that the right info? [04:03] pina: it's a personal opinion (i didn't read it, but "Conclusions" say: "Why do I run BSD?" and "Why Should you run BSD?", ending with "The End" chapters tell me that :) [04:03] bubbasucks: Yeah, checking things [04:03] k [04:03] ivoks: precisely [04:03]