#ubuntu-kernel 2005-12-01 <fabbione> BenC: 4.5 failed on sparc. It's a config issue <fabbione> Support for SUN4 machines (disables SUN4[CDM] support) (SUN4) [N/y/?] (NEW) aborted! <fabbione> Console input is closed. Run 'make oldconfig' to update configuration. <BenC> fabbione: ok <BenC> fabbione: that's odd though, it's trying to build sparc32 <BenC> fabbione: I built on my machine without doing "sparc32 dpkg-buildpackage ..." <BenC> and I'm running 2.6.15-4.5, BTW :) <BenC> -sparc64-smp <BenC> why is sparc64 set as KPKG_ARCH=sparc in debian/config/archmap? <BenC> fabbione: ping * ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | New git tree for dapper: https://wiki.ubuntu.com/KernelGitGuide | 2.6.15-4.6 (2.6.15-rc2-ubuntu1) uploaded <BenC> later <mjg59> So if I copy the 2.6.12 framebuffer layer into 2.6.15, usplash works again <lamont-away> BenC: you probably don't want to know that -4.6 is FTBFS on ppc, right? <lamont-away> kernel-wedge copy-modules 2.6.15-4 powerpc 2.6.15-4-powerpc <lamont-away> missing module nls_base * lamont-away points craighoward@example.net <BenC> lamont-away: yeah, saw that #ubuntu-kernel 2005-12-02 <xulin> hi .. <xulin> is there somebody who know things about tcpa ? <raghu> hi, I am developing a packet scheduling policy in Ubuntu Kernel(N/w subsystem), I am struck at a point <raghu> it would be gr8 if I could get some help <raghu> I have sprinkled printk(KERN_CRIT,"kernel ... "); in the following functions in ip_input.c <raghu> ip_rcv(), ip_rcv_finish(), net_rx_action() <raghu> but I do not see the messages in /var/log/messages? any ideas pls <raghu> ? <zul> heylo <fabbione> BenC: please revert af586a17bada5fa8300ff7a33ef961ec4964b312 (sparc -> sparc64 rename) <fabbione> or pull from me <fabbione> .15 failed because i forgot an override in sbuild <fabbione> and the change will make kernel-package cry out loud <fabbione> BenC: when you have time, please revert the OCFS2 manual commit i did and pull from http://oss.oracle.com/git/ocfs2-dev.git <fabbione> BenC: it will be easier to maintain in future <fabbione> i just can't get git to do it properly <BenC> ok <fabbione> hey <fabbione> Trying really trivial in-index merge... <fabbione> fs/Makefile: needs update <fabbione> fatal: Entry 'fs/Makefile' not uptodate. Cannot merge. <fabbione> Nope. <BenC> fabbione: next weekend my e3k will be available to do buildd and such <fabbione> this is the error i get from git <fabbione> basically it can't merge a file <BenC> but I can't let it be perm, because I need that box for doing debug <BenC> fs/Makefile must be modified <BenC> git-status <fabbione> and i don't understand how the hell i get to see the old, new files <fabbione> yeah git status was telling me that the file was modified <BenC> git-checkout -f will overwrite any modifications you have (if they are not valid) <BenC> git-ls-files -o -t <BenC> that will show you files that are "new" <fabbione> hmmm <fabbione> well basically i do a clone of our tree <fabbione> revert a commit <fabbione> pull from oracle <fabbione> i get that error <fabbione> i must be able to see the attempt merge to understand what to fix <fabbione> that's what i can't figure <BenC> then the revert needed merging to complete <fabbione> i sort of need to see where the conflict is <BenC> after the revert, do git-status <fabbione> the revert goes fine... <fabbione> git-status tells me nothing needs to be done <BenC> most likely, you need to open fs/Makefile, and fix any conflicts from the revert <BenC> doubt it, else it wouldn't do that <fabbione> i get the error on pull <fabbione> yeah there is an error in the revert, but i get to fix that and do the commit <BenC> fs/Makefile wouldn't be modified from the pull though <BenC> hmm, ok, I'll attempt it <fabbione> it needs to merge 2 lines <BenC> yeah, then do "git-commit" and it will finish the merge <BenC> s/merge/revert/ <fabbione> yup.. i am redoing it right now <fabbione> git clone ubuntu-2.6/ crap-2.6 <fabbione> defaulting to local storage area <fabbione> takes a little bit <fabbione> ok reverting now <fabbione> git revert b6d1b58933a2eec5bfc4d14bb733686e446e497f <fabbione> [SNIP} <fabbione> BenC: yeah it works now! thanks <fabbione> BenC: you should be able to pull from me <fabbione> OCFS2 integrated from oracle git repo <fabbione> dunno if it builds. <fabbione> but should.. it's the same version from 2 different sources <CataEnry> hi all <CataEnry> bye all <mjg59> So, I've found what broke usplash <mjg59> infinity: Can you take a look at http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=c465e05a03209651078b95686158648fd7ed84c5;hp=e764a20196f4e1b497a42fdc6e9d254e7ec290f2 and see if you have any idea why it might b0rk vga16fb? <mjg59> (And, if possible, revert it and see if it fixes things for you) #ubuntu-kernel 2005-12-03 <BenC> mjg59: I see one thing odd <BenC> look at the diff to bitblit.c <BenC> nm <BenC> I didn't see where it set err = 1 <BenC> I can't see anything that jumps out <BenC> pretty straight forward <mjg59> BenC: Reverting it seems to make usplash work <mjg59> So I'm wondering whether it's changing order of initialisation in some subtle way <BenC> what's the URL again? <BenC> nm, got it <BenC> no, I don't, can you past it again? <mjg59> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=c465e05a03209651078b95686158648fd7ed84c5;hp=e764a20196f4e1b497a42fdc6e9d254e7ec290f2 <mjg59> I'd prefer it if someone else can verify that it changes the behaviour <mjg59> I'm not entirely convinced that I haven't buggered up my test system along the way <BenC> I don't have anything other than the machine that was already broken in breezy to test on <BenC> nothing changes when softcursor.c got moved (code wise) <mjg59> Hmm. <mjg59> Yeah. So now I'm confused. <mjg59> Hmm. <mjg59> The usplash script tries to load softcursor.ko <mjg59> Which is obviously going to fail <mjg59> I wonder if that's the problem <BenC> how's it going to fail? <BenC> did you make the change I submitted in the bug report to fix the loading? <mjg59> It gets installed in a different location, I think <mjg59> Uhm. Which bug report? <mjg59> (Sorry, I've lost track of which ones are on which issues) <BenC> I filed a bug report on usplash about the module loading order and location <BenC> softcursor needs to be loaded first, and needs to be changed to video/console/softcursor.ko <mjg59> I'm actually shifting to modprobe <mjg59> Just let me get a fresh kernel image and I'll check <BenC> that'll work, modprobe vga16fb should do the right thing <mjg59> Ok, modprobe doesn't fix it <mjg59> Hm. So now I wonder if I was finding the wrong breakage with my bisection <mjg59> Grr <mjg59> I may be entirely wrong about that patch, so <mjg59> Oh ha ha fucking ha <mjg59> Making sure that fbcon is loaded before vga16fb makes it work <mjg59> So not a kernel issue at all <mjg59> PAIN <infinity> ... Isn't that backwards? * infinity always assumed fbcon depended on having an fb loaded, not the other way around. <infinity> Oh well, whatever. :) <infinity> If you've figured out the magical load order, can you eiher push me a patch, or just make an upload? <mjg59> I've uploaded <infinity> Yay. <mjg59> 0.1-23 should fix <infinity> BTW, do we have any spare slots in the pallette? <mjg59> No <mjg59> It's all taken up with brown <infinity> Too... Much... Brown. <mjg59> So, can we have the 640x400 patch? Can we can we can we? <infinity> I need to push aside a shade of brown for some sort of yellow/warn colour, I think. <mjg59> Ngh. <mjg59> I'd also like some artwork that used flat colours rather than trying to anti-alias with a tiny number of them <mjg59> I think that would be a feature <infinity> Yeah. Good luck convincing someone to do that. <mjg59> How about we kill Jeff and get someone else to spec the artwork next time? <mjg59> Also: <mjg59> BenC: Have you dropped the Toshiba acpi key magic patch? <jbailey> mjg59: Eh? <jbailey> mjg59: Of what do you accuse me? =) <infinity> I'm sure I could just scribble "OOBOONTOO" in a red pen in The GIMP and use that. <mjg59> jbailey: Other Jeff <jbailey> mjg59: Oh good. <mjg59> infinity: I'll upload it tomorrow * infinity goes into his little corner to give mjg59 a working lrm for his ath. <mjg59> I have an ath? <mjg59> Oh, yes <infinity> Someone should send me an atheros card for Christmas, so I can actually test this driver. <infinity> The only LRM stuff I can test is fglrx and nvidia. <infinity> (Which is the largest amount of work in the package anyway, so I guess that works) <mjg59> BenC: Can you add the diff from http://www.codon.org.uk/~mjg59/tmp/fb-sysfs.diff ? <mjg59> Haha. <mjg59> So. <mjg59> The reason for powernow not working on my Turion may have been the fact that I'd disabled it in the BIOS <mjg59> Oh deary me. <infinity> *cough* <mjg59> Which means that the only real thing missing from this machine is the Broadcom wireless <mjg59> Looks like it just got support for scanning. Hurrah. <mjg59> Association can't be too far off <BenC> mjg59: patch will be in -5.7 <mjg59> BenC: Rock, thanks <BenC> mjg59: what was the url to the softmac stuff? <mjg59> softmac.sipsolutions.net <BenC> thanks <fabbione> hey guys <fabbione> BenC: sparc fails with oldconfig at kernel-headers otherwise we look good <fabbione> i think the defconfig in the tree is old <fabbione> dpkg-deb: building package `linux-headers-2.6.15-4' in `../linux-headers-2.6.15-4_2.6.15-4.6_sparc.deb'. <BenC> I just did a str8 build and it did fine <fabbione> that's weird <fabbione> how do you call the build? <BenC> not with sparc32 <BenC> just directly <infinity> Okay, dude, we can be coworkers still ,but we can't be friends anymore. * infinity mutters about people typing "straight" as "str8"... <BenC> infinity: I can say str8 if I want to :P <fabbione> if i use sparc64 in debian/config/archmap and dpkg-buildpackage it farts <BenC> I'm used to typing that when I play online poker <BenC> habit <fabbione> unknown Debian architecture sparc64, you must specify GNU system type, too at /u <BenC> fabbione: guess I need to test with "sparc32 dpkg-buildpackage ..." <BenC> see if I can figure out what is going on <fabbione> well what i did was: <fabbione> use sparc in archmap <fabbione> and build using sparc64 dpkg-build... <BenC> that's what I have now <fabbione> that builds all the kernel except the old config for -header- <fabbione> i need to test out of git <BenC> I didn't call sparc64, but it should be the same <fabbione> this was 4.6 <BenC> I need to push, have a big changeset <BenC> (ocfs2, and linus sync) <fabbione> did you also pull from me? <fabbione> perfect <fabbione> if you can push, i can run a build <infinity> BenC : eta on -5.X? <BenC> if all goes well, tomorrow night <infinity> BenC : We really need the update-initramfs change for the -5 ABI bump, and I need to push you the vga16fb patch too, before it's too late. <BenC> probably a good idea if I make tomorrow a "get everything ready for linux-meta switch to .15" day <infinity> (Need to build kernels and test on a couple of machines here first, before I decide to inflict it on the world) <BenC> including fixing k-p <infinity> Yeah, LRM will be in by then. <infinity> Updating it for the ABI bump is simple. <BenC> lamont: !! <infinity> So that's no big deal, once I've done the hard bits (fixing it to stop sucking and actually build) <BenC> lamont: I have -5.7 building on hppa and ia64 now :) <BenC> infinty: good deal <fabbione> coll <fabbione> cool <BenC> I have 5 builds going atm <infinity> BenC : mdz wants me to give you a quick tour of LRM too, so you're not stuck blocking on me when the world crashes around my ears with other tasks. <BenC> only reason I don't have amd64 going is I haven't pushed for concordia to pull from yet <infinity> BenC : But we'll save that until after I've updated all the drivers. <BenC> infinity: unless there's more than what I already encountered doing a few ABI bumps in breezy, then I'm good <infinity> BenC : Axcept for the part where I'm changing that mechanism, no. If you never have to update a driver, LRM should be simple. <BenC> fabbione: the e3k is my new best friend...I can pump out a quick build in 15 minutes just to see if it compiles ok :) <infinity> If you find yourself having to update one (especially nvidia or fglrx), you'll hate yourself. So, it's best not to bother. :) <fabbione> BenC: ehehe ok <fabbione> i didn't want to keep you awake <BenC> infinity: I'll try to stay clear of actually doing work on lrm :) * infinity looks in wonder at the new word he's created. <infinity> s/Axcept/Except/ <BenC> infinity: my hillbilly accent rubbin' off on ya'll <infinity> BenC : Ugh, dude, I was talking like you for days after you left. <fabbione> BenC: ok, i am going to stop building the kernel for now. Just let me know if i need to build it with sparc32 or sparc64. I can override that in sbuild per source pkg <BenC> was surprised my wife didn't notice my slight french accent when I got back <fabbione> lol <fabbione> Merci <BenC> I noticed I even spoke broken english a few times, in addition to the accent <infinity> If it's not buildable with sparc32, you're not doing it right. :) Period. <infinity> I sure as heck wouldn't special-case the powerpc buildds to build with linux64 for kernel builds. <BenC> infinity: yeah, because we all know that it has to build on a 50mhz sun4c :) <fabbione> ehhehe <fabbione> infinity: i blame kernel-package <fabbione> no really.. <infinity> BenC : No, but the buildds themselves run in linux32/sparc32 for pretty valid reasons, and having the kernel builds not fit into my little automated world sucks. :) <infinity> (doubly-so, if I end up with a sparc buildd in the DC) <BenC> yeah, before I set the sparc buildd's to use sparc32 way back when, administering it was awful <fabbione> infinity: that's why lamont did implement an option in sbuild for that :) <BenC> for what? <fabbione> $build_env_cmnd{'linux-source-2.6.15'} = '/usr/bin/sparc64'; <fabbione> <- in .sbuildrc <BenC> ah <infinity> Oh, that's just vile. <fabbione> so you can override the environment per source pkg <fabbione> infinity: no. it works <fabbione> BenC: the buildd defaults to sparc32 <fabbione> and you can make exceptions <infinity> Anyhow, that wasn't lam. <infinity> lamont, even. <fabbione> infinity: you? <fabbione> because the default environment was alredy there <fabbione> the override per source was lamont <fabbione> i am pretty sure about that <fabbione> check the baz changelog <infinity> Oh, wait. Yes, that was him. <infinity> It kinda mucks with how we do the global linux32 stuff though. Yay. <infinity> To be fair, I hacked the latter after he did the former. <infinity> Specifically to work around the bogus requirement to have sparc32/linux32 in the chroots. <infinity> Which is painfully dumb. <fabbione> infinity: after we will get the sparc buildd at the CD <fabbione> we will see how it works <fabbione> i really don't care.. <fabbione> just don't break the stuff for older releases <infinity> I don't plan on breaking anything. :) <infinity> If you have whacky sbuild configs, though, you'll have to push those to me. <fabbione> infinity: sure <fabbione> that's no problem <fabbione> the line you saw is basically the only custom in that config <fabbione> well.. for hoary/breezy/dapper atm <fabbione> we didn't build warty <infinity> Ahh, so you haven't done these overrides for older linux source stuff? <fabbione> so that's no issue <fabbione> yes. only the kernels <fabbione> $build_env_cmnd{'linux-source-2.6.10'} = '/usr/bin/sparc64'; <fabbione> $build_env_cmnd{'linux-source-2.6.12'} = '/usr/bin/sparc64'; <fabbione> $build_env_cmnd{'linux-source-2.6.15'} = '/usr/bin/sparc64'; <fabbione> that's all the custom love i have there <infinity> Ahh, three lines then, not one. :) <infinity> Well, let's see about fixing kernel-package. <fabbione> + the default to use sparc32 <infinity> If it DTRT on powerpc, surely we can make it do the same for sparc. <fabbione> oh yeah <fabbione> specially because we don't care about 32bit kernels <fabbione> that's where all the mess comes from <infinity> Well, yes, 32-bit targets on sparc are laughable, but it's technically a bi-arch system with a bi-arch toolchain, and we should treat it as such. <infinity> Even if the kernels will all be 64-bit. <infinity> Some day, someone may resurrect sun4 support in 2.6, I'll boot it once, remember how HIDEOUSLY SLOW they were, and never again. :) <fabbione> errr * BenC remebers the 28 hour builds for libc6 on his Sparc LX <fabbione> we already killed support for sparc32 in glibc <fabbione> there is really no point in sparc32 <fabbione> at all <BenC> libc is v9 optimized? <fabbione> if somebody will resurrect it... well they are welcome to patch everything back <fabbione> BenC: you need ask jbailey but i think they are <fabbione> - debian/sysdeps/sparc.mk: Set libc_configure_build=sparcv9-linux <fabbione> set sparc64_configure_build=sparc64-linux <fabbione> * Drop support for Neanderthal Sparc systems <fabbione> - debian/sysdeps/sparc.mk: Drop sparcv9 package <fabbione> Default to nptl for main build and sparcv9b <fabbione> - debian/control.in/opt: Drop sparcv9 package <fabbione> - debian/control: Regenerate <fabbione> so i think they are optimized <infinity> Is that true in Debian too? <fabbione> no <fabbione> only ubuntu <infinity> Kay, that makes sense. <fabbione> sparc is our pet arch.. mmk? <fabbione> no really we can do stuff in here that Debian can't <fabbione> let's do i <fabbione> it <infinity> <nod> <infinity> I need to get a reasonably speedy Ultra in my house. <fabbione> i need to get elmo and znarl to look at buildd prices and get them to the datacenter <fabbione> so i can finally use my sparc for debugging and testing <infinity> We should be able to get a set of craptastic Sunfire V240s for next to nothing. <infinity> Should fit well with the buildds we already have. <fabbione> i think elmo was looking in something like that <infinity> The 240 is a lot less crap than the 100/120s I had to work with at my last job, at least. <CataEnry> hi all <zul> heylo <fabbione> hey zul <jbailey> Heya Chuck! <jbailey> zul: Ottawa's even pretty in snow, it's kinda sick. <zul> meh...its ok :) <zul> hey guys how was your weekend? <mjg59> infinity: Can't remember if I asked this last night - what's the situation with the 640x400 thingy? <zul> hmmm...my touchpad is foobared <mjg59> On 2.6.15? <mjg59> Known <zul> yeah i know <mjg59> I blame Scott <zul> heh. <mjg59> Or Marco, or GregKH <jbailey> zul: <Keybuk> http://people.ubuntu.com/~scott/packages/new-udev <jbailey> From #ubuntu-boot not too long ago. <zul> hmmm.. <makx> zul: link to your weblog? <makx> do you have modular mousedev <makx> ? <zul> makx: i dont have a weblog <makx> ah ok wasn't you that said to respond to davej, zul? <zul> dont have time to <mkrufky> zul: you closed bug 15395, and ive been busy -- didnt have enough time to write you back <mkrufky> anyhow, yes... i confirm that not only is it not an ubuntu bug (it was an upstream bug) it is also fixed now <mkrufky> the problem was due to missing dvb headers for users trying to install v4l modules from cvs -- it is a moot point now, as we have officially merged dvb and v4l cvs repositories <mkrufky> side note: we are also merging ivtv and pvrusb2 and usbvision drivers into v4l ... so such problems will be nothing but history soon <zul> ok cool.. <mkrufky> ya, sorry for the 2-week delay in my response ;-) <zul> meh...its ok i guess ;0 * netjoined: irc.freenode.net -> brown.freenode.net <BenC_> lamont: ping <zul> hmmm...somtimes i can be such a bastard <BenC> lamont: hey, when can ia64 and/or hppa use initramfs? <BenC> lamont: btw, I have 2.6.15-5.7 running on my i2k <makx> BenC: hppa needs an klibc patch. <makx> haven't uploaded it yet to Debian due to troubles with missing asm symlink in linux-headers <BenC> what about ia64? <makx> " inflate code misreads magic number" according to jbailey. <jbailey> klibc has the patch in Ubuntu. <makx> aah you added it :) <makx> need to sync with that badly. <jbailey> I need to make lkh not suck in Debian badly. <makx> hehe <BenC> jbailey: so I can safely switch ia64 to use initramfs, or has it not been tested? <BenC> if it hasn't been tested, I can surely do it, and make the change to kernel-package with this update-initramfs change I'm about to do <jbailey> BenC: Well, it doesn't boot. =) <jbailey> BenC: My initial suspicion is that the READ_BYTE or some such macro isn't right. <jbailey> I had LaMont add some printk's to give us the value of those bytes, and they were complete whacked. <jbailey> It's probably easy enough to troubleshoot, but my ia64 isn't local. <BenC> I might just wait till the weekend and take a look at it then <BenC> jbailey: -5.7 will be using update-initramfs, fyi <jbailey> BenC: Nice, thanks! <fabbione> have a nice evening guys <fabbione> cya tomorrow <fabbione> or very late today :) <crimsun> 'night, fabbione <fabbione> night <janimo> BenC, I don't know if LaptopTesting issues have different priority but here's https://bugzilla.ubuntu.com/show_bug.cgi?id=20085 <janimo> it makes a test laptop boot <BenC> is that the acpi return value ignore patch? <janimo> yes <BenC> if so, it's in -5.7 <janimo> it is confirmed upstream <janimo> thanks! <CataEnry> bye all <BenC> sure thing <BenC> jbailey: ping <jbailey> BenC: pong <BenC> jbailey: update-initramfs has a bug <BenC> the -d option requires an argument, yet it never sets version to the argument, so it always fails <jbailey> BenC: It's infinity's package now, but if it's an obvious fix, I'd say just upload it. <BenC> ok <jbailey> You're the most important consumer of update-initramfs, so bend it to your needs. * BenC adds another package to his list of "get the damn thing ready for linux-meta" <zul> hehe <BenC> nm, I was just using it wrong <BenC> the wiki page for the spec said just -d, and it needs to be -d -k <ver> <makx> BenC: which wiki page? <BenC> https://wiki.ubuntu.com/InitramfsUpdates <lamont> jbailey: BenC - ia64 initramfs problem is an elilo issue, forwarded upstream <jbailey> lamont: Cool. Is it just setting the load address too low? <lamont> nfc <lamont> which reminds me... need to see what we did for breezy elilo <zul> BenC: you know those unknown key pressed errors that some people are getting in their dmesg? <BenC> zul: yeah <BenC> I get it sometimes too <BenC> lamont: I've fixed the hppa64-gcc thing (it needed to be hppa64-linux-gnu-gcc-3.4 for my breezy install), however, hppa64 is a nobuild from git right now <BenC> a lot of missing headers referenced for the compat layer <BenC> zul: do you have a fix for it? <zul> BenC: yeah remove the prink that is causing that, its useless <BenC> hehe, put it in yout git so I can pull it :) <zul> ill make a patch for you tonight <jbailey> BenC: From the parisc git, or from Linus? <BenC> I pulled parisc git hoping to get things working <BenC> but it seems to only get hppa32 working, and not hppa64 :/ * jbailey pings kyle to tell him. <BenC> cool, the update-initramfs stuff works...install, upgrade/reinstall, and remove/purge <BenC> did the reboot-notifier too * jbailey ^5's BenC * zul disklikes the reboot-notifier <zul> anyways home for me #ubuntu-kernel 2005-12-04 <jbailey> BenC: Apparently git isn't all setup yet, and CVS should be still considered canonical. <jbailey> BenC: They'renot expecting to be over on git for at least another week. <BenC> who's that? <BenC> parisc? <zul> BenC: its there now <jbailey> BenC: Yes, sorry. =) <zul> doh...mental note...dont put anything in /tmp <jbailey> It's fine until you reboot. =) <zul> duh... <zul> :) <zul> so when are you coming back? <jbailey> Back where? <zul> here * jbailey looks around. <jbailey> I *am* here. <zul> er...ottawa <jbailey> Oh. Mmm. <jbailey> Unlikely to be in 2005. <zul> ah.. <zul> true... <jbailey> Maybe in January to hang out with Carlos for a weekend picking his brain on toolchain btis. <zul> neato <BenC> finally, running 2.6.15-5.7 on all my machines except the a500 <BenC> even reverted to stable rt2500 for my mame cabinet <zul> heh <BenC> infinity: ping <jbailey> BenC: It's runnig on the ppc64 and the sparc boxes? <infinity> BenC : pong... I'm doing test builds of the vga16fb change... Can you hold off on 5.7 for a bit? <infinity> BenC : If you're itching to get it uploaded and go to bed, just do it, and I'll do a 5.8 later when I've tested this stuff more. <BenC> jbailey: running on my g4, not ppc64 though <BenC> jbailey: but definitely test it, since there were more ppc64 updates this time around <BenC> infinity: how soon before you can get the vga16fb patch ready? <BenC> infinity: also, what's the ETA on lrm? <BenC> infinity: update-initramfs and notifier changes are in 5.7, btw <fabbione> mornig guys <BenC> hey fabbione <fabbione> hey Ben <fabbione> still up? <BenC> yeah, was hoping to catch adam again <BenC> I'd like to wait for the vga16fb patch before uploading -5.7, but I want to see how long he'll be with it <fabbione> i think he is out for lunch <BenC> I've got -5.7 building cleanly on 5 architectures, I need to do an upload before something breaks it :) <fabbione> aahha <fabbione> bah crappp!!!!! <infinity> BenC : Just upload it, then. I may be up all night. :/ <infinity> I'm having a pretty miserable day of one step forward, two steps back. <fabbione> so fltk doesn't export opengl stuff on sparc that makes openexr FTBFS that stalls all of KDE <fabbione> GO KDE! <BenC> infinity: ok, I'll just do another upload when you get that patch ready <BenC> infinity: is there anything I can do to help with lrm, so we can get linux-meta updated? <fabbione> BenC: nah.. <fabbione> it's better infinity does LRM and get the blames :) <BenC> I'm more than willing to put the blame on infinity :) <BenC> even if I break it :) <fabbione> ehehhe * ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | New git tree for dapper: https://wiki.ubuntu.com/KernelGitGuide | 2.6.15-5.7 uploaded (The "Five Arches" release) <fabbione> lol <fabbione> congratulation dude <BenC> don't congratulate me till the buildd's agree with my assessment :) <BenC> this time though, I did all my builds through to udeb builds, so I should be good to go <fabbione> ehhe <fabbione> ok fltk1.1 fixed <fabbione> kde will unleash soon <fabbione> good night ben <fabbione> cya later <BenC> good night <infinity> BenC : No, I just need to figure out some minor details. <fabbione> dilinger: ping? <jbailey> BenC: Checked ppc64, it still fails with the same rtc failure even though you've built it in. <zul> heylo <oldguy> quick ot ok/ <jbailey> oldguy: Dad? <jbailey> =) <oldguy> yeah i m a dad..but got three girls <jbailey> I have long hair, but that's as close as I get, sorry. <oldguy> im trying to build a 2/6 kernel for netvista and ltsp-4.2..i built an uncompressed kerenl and catted the initramfs onto it..but get unsupported file type.. <oldguy> so if vmlinux is unsupported..and vmlinuz is unsupported..what else is there? <CataEnry> hi all <chrisle> hi <jbailey> BenC, fabbione: What's the word on Xen on Breezy? <jbailey> oldguy: You can't cat the initramfs onto a kernel. You have to embed it in the data segment. <jbailey> oldguy: Or you can pass it in using the initrd mechanism. <fabbione> jbailey: Xen has some kind of .12 support afaik.. but that's it <fabbione> jbailey: last time i did try a merge they were at .11 <fabbione> and we were shipping .12 <jbailey> But it's nothing we support natively. <fabbione> nope <jbailey> 'kay, thanks, <BenC> fedora's .14 based kernel has patches <jbailey> Ah, cool. <BenC> kick ass, the big three have successful builds for -5.7 <BenC> jbailey: feel free to test -5.7 on ppc64 when you get a chance <jbailey> It's more someone I have looking for us to support Xen. <jbailey> BenC: See my comment to you in this channel from a little under 2 hours ago. =) <BenC> jbailey: I looked into it, but the patches are so big and so invasive, I didn't see the point trying at this point <BenC> ah <fabbione> hmm <BenC> jbailey: let me see if there's a kernel command line option that can disable rtc or something <fabbione> if we really really want Xen we can pull it in from their development branch <jbailey> BenC: 'k <BenC> fabbione: is there a Xen git? <BenC> IIRC, they are going to try to get it into 2.6.16 <fabbione> BenC: there is an hg tree <fabbione> the tool that's similar to git <fabbione> it's also on kernel.org afaik <BenC> fabbione: -5.7 hit your sparc buildd yet? <fabbione> http://www.kernel.org/hg/ <fabbione> BenC: it's building as we speak <BenC> jbailey: can you past the URL to that oops again, please? <fabbione> http://www.cl.cam.ac.uk/Research/SRG/netos/xen/downloads.html <fabbione> The public Mercurial repository for Xen, the modified Linux, and the domain control tools is hosted on http://xenbits.xensource.com, where you can browse the source and inspect the <fabbione> 15 hours ago: The device sharing check races when more than one file backed vbd is <fabbione> author: craighoward@example.net <fabbione> *perhaps* we can try to get in touch with that guy :) <jbailey> BenC: Hmm, grep isn't turning it up in my logs. <BenC> let me check firefox history, what host name would it be? <jbailey> That's what I'm trying to remember. =) <BenC> lol <jbailey> Something ending in .nl =) <jbailey> grep pastebin.ubuntulinux.nl * | grep jbailey <jbailey> isn't giving me anything. hmm <jbailey> No, right! <jbailey> I didn't put it in there. <jbailey> I took a picture instead. <dilinger> fabbione: pong <jbailey> http://people.ubuntu.com/~jbailey/P1010042.JPG <BenC> thanks <jbailey> BenC: If you want I can update it for -5.7 <BenC> yeah, that'd be nice. see if you can get the whole screen aswell <fabbione> dilinger: hey.. thanks i did manage without :) <infinity> BenC : Okay, LRM ABI switches are now a one-button affair, much like linux-meta, but MUCH SCARIER under the hood. <infinity> BenC : So, once this thing &#@$ing builds for me, your minor maintenance tasks with it should be a no-brainer. <BenC> if I ever have to pop the hood, I'll be sure to take it to the shop(you) rather than work on it myself :) * infinity kisses hardcoded kernel versoins and annoying *_minor stuff goodbye. <infinity> Of course, now I have an irritating QT build issue to deal with. * BenC adds ia64 to the successful builds for -5.7 <infinity> About time. <BenC> so far everything has built fine <BenC> I expect sparc to build, but I know hppa will fail * infinity kicks weddell and screams at it to be faster. <fabbione> BenC: sparc is at 64-smp (half way) <BenC> it had been so long since I booted my i2k this weekend, I actually had to smack it on the side of the case to get it to power on <fabbione> it won't take much much longer <BenC> fabbione: sweet <fabbione> i am falling asleep and partman-auto-lvm on ppc is winning 2:0 * fabbione starts to get pissed off <fabbione> time for coffe and smoking bof <BenC> opinions...in linux-meta, because {686,k7}-smp are going away, should I make the linux-{image,headers}-{686,k7}-smp meta packages depend on linux-{image,headers}-{686,k7} meta packages or make them depend on the kernel-abi-version packages directly (sans the -smp)? <infinity> Make them depend on the other meta packages, so we can eventually remove the SMP packages. <BenC> that's what I was thinking <infinity> (Assuming we want to down the road) <BenC> lamont: ia64 built :) <lamont> BenC: woot! <lamont> and hppa is still git-ftbfs? <BenC> yeah <BenC> if we had 64-bit hppa64 userspace, it wouldn't be a problem :) <lamont> well, yeah <jbailey> lamont: willy said to keep using CVS for at least another week. <lamont> ah, I see. <BenC> probably take a week to get a decent patch out of CVS anyway :) <BenC> anyone packaged git 0.99.9x for ubuntu yet, or even debian? <oldguy> jbailey: thanks..gonna try an experiment <BenC> debian has it...we should grab that to dapper <fabbione> BenC: i think we already sync that automatically <BenC> universe? <BenC> yep, there it is, thanks <BenC> jbailey: can you disable the hwclock problem (mv it out of the way, and symlink to /bin/true, e.g.) and see where you get after that? <jbailey> BenC: You scare me. <jbailey> But okay. =) <BenC> disable hwclock program I meant <jbailey> Is that really the only thing that will cause an rtc event? <jbailey> Or should I avoid using this system for much after that? <oldguy> rootcd /opt/lytsp/i386-4.2 <BenC> nothing else should <jbailey> 'k * jbailey tries <BenC> everything else should use the system clock rather than the rtc directly <infinity> (should) <BenC> odd that his system seems to oops/freeze on sig 7 from I/O accesses, I would have thought that hw traps would recover from that <BenC> jbailey: running? <jbailey> $ uname -a <jbailey> Linux starshine 2.6.15-5-powerpc64-smp #1 SMP Tue Nov 29 07:20:51 UTC 2005 ppc64 GNU/Linux <BenC> sweet <BenC> ready to attempt to crash it? :) <BenC> cat /proc/drivers/rtc <jbailey> The only observation so far is that power mgmt is also a bit broken. <jbailey> The fans are slowly speeding up. <BenC> odd <jbailey> Should I be on the console for that? =) <BenC> yeah <jbailey> NO such file or directory <jbailey> mm <jbailey> driver singular. <jbailey> BenC: I got an oops, but no crash. <BenC> well, it's a start <BenC> can you email me the oops? <infinity> Did you actually get any output? :) <BenC> yeah, did any output come out, or did the cat process lockup? <jbailey> BenC: http://paste.ubuntulinux.nl/5190 <BenC> well, it would have to get to the end of the proc function before the buffer was returned to the user <BenC> jbailey: thanks <jbailey> (Recovered from dmesg so I can just paste) <BenC> that's not what I expected <BenC> I was expecting to see rtc_get_rtc_time() again <BenC> heh, that can't be good :) <BenC> jbailey: thanks, I'll be able to do more with this dmesg now <BenC> maybe I'll have something you can test later, if you have time <jbailey> Apparently doing it a second time to see if there was any output crashes the machine. =) <BenC> at the very least, a little sprinkling of printk's to see where it actually oopses <jbailey> BenC: Cool. I'll try to run anything I need long term in screen sessions on other machines. =) <jbailey> infinity: At some point when you're bored... ;) <infinity> ? <infinity> Not that that point is now, but I may want to plan for the future. <mjg59> Is usplash working for everyone now? <mjg59> And what magic does it need in its postinst? <infinity> a) Don't know <infinity> b) update-initramfs -u <mjg59> infinity: Is the 640x400 patch submitted yet? <mjg59> I want to shift to 640x400 artwork in the next usplash upload <infinity> Too focussed on making LRM work. :/ <infinity> If yo uhave a tested patch, give it to BenC, otherwise I'll do mine tomorrowish. <jbailey> infinity: I have instruction here on making kdump work to store OOPS information when it happens. <jbailey> infinity: I collected it at OLS last year, and dug it up a couple days ago. <infinity> Though, you should be able to switch the artwork anyway, since artwork that's smaller than the fb isn't a problem. <mjg59> Yeah <infinity> (As evidenced by the tiny artwork in the middle of my massive vesafb) <BenC> usplash looks tiny on my readonfb at 1024x768 <infinity> (What will happen with artwork that's bigger than the FB?... For people upgrading?) <BenC> anyway to scale usplash on higher resolutions? :) <infinity> BenC : Did you see it on my 1400x1050? <BenC> nah, hehe <infinity> Speaking of seeing things on my laptop, did you finally finish watching Family Guy and regain productivity? :) <BenC> I have about 10 episodes left to watch :) * mjg59 uploads new usplash <mjg59> Also: usplash needs to check if the display is capable of 256 colours <infinity> mjg59 : I don't suppose that one daemonises (and removes the sleep from the init)? <mjg59> Nope <mjg59> I'll do that next time <infinity> Kay. I'll do that the first time I touch it, then. <mjg59> Can you file a bug? <infinity> Unless you're on a warpath. :) <mjg59> Well, I'm in bed, ill <infinity> Which, obviously, leads to hacking graphical boot thingees. <lucasvo> hi <lucasvo> I would like to make a clustering system with upstream compatible Kernel for terminal server. What do you suggest? <mjg59> I have found scary ways of helping vesafb survive suspend/resume <BenC> lucasvo: I don't undetstand your question <BenC> terminal server and clustering conflict in my brain <lucasvo> BenC: I would like to develop clustering which may be included by ubuntu <BenC> what sort of clustering? <infinity> mjg59 : It always has done for me anyway. <lucasvo> if one uses powerful ltsp clients, one could use them for clustering <lucasvo> BenC: like openmosix <mjg59> infinity: Yeah, it doesn't here <BenC> mjg59: FYI, the fb-no-write patch is in -5.7 <infinity> BenC : LRM has turned into a mauch larger headache than I'd originally hoped. I'm going to go catch a 4 hour nap (It's 4am now) and finish up in the morning. :/ <BenC> lucasvo: oh, you lost me, I don't do much with that sort of thing <mjg59> BenC: Thanks <lucasvo> BenC: ok <BenC> infinity: ok <BenC> lucasvo: but I still don't know what you are asking..."what do you suggest" is very vague :) <lucasvo> BenC: I need a clustering system which is accepted by ubuntu policy <BenC> we have ocfs2, but I'm not sure if that suits your needs, since it's only a clustering filesystem <lucasvo> BenC: exactly, I need RAM/CPU sharing <fabbione> lucasvo: we don't have that solution yet <BenC> and "accepted by ubuntu policy" is something you'll have to gain somewhere down the line, it's not something that can be decided before hand <fabbione> lucasvo: and probably won't <fabbione> lucasvo: what kind of clustering exactly are you looking for? <BenC> fabbione: what is the clustering thing that was talked about at UBZ? <fabbione> lucasvo: something like openmosix or a batch/queue/job scheduler? <BenC> some IBM thing <lucasvo> fabbione: yes, I want to make one for ubuntu <lucasvo> fabbione: yes <fabbione> lucasvo: yes it's not an answer to what i did ask :). <BenC> there's another guy wanting to do the same thing <BenC> and pretty much, he is having to do his work outside of ubuntu, in the hopes that he can prove its viability for dapper+1 <lucasvo> fabbione: hm I didn't see the or <lucasvo> fabbione: I mean something like openmosix <fabbione> BenC: i don't remember talkign about IBM solutions really.. but we have something on the boilerplate <fabbione> lucasvo: no, we won't have openmosix or similar solution for some time <BenC> fabbione: maybe it was HP <fabbione> BenC: yeah HP <fabbione> openssi <BenC> lucasvo: email -devel about it and see if you can catch the attention of other people (and there are some) looking to do the same <lucasvo> fabbione: what I would like to do is to include a clustering system into ubuntu which is accepted by upstream <BenC> yeah, that's it <lucasvo> BenC: ubuntu-devel? <fabbione> lucasvo: https://wiki.ubuntu.com/UbuntuClusters <fabbione> lucasvo: most of solutions like openmosix are for 2.4 kernels only <BenC> lucasvo: yeah <fabbione> and we don't support 2.4 <fabbione> porting to 2.6 is on the way but still at a too early stage to be even considered <lucasvo> fabbione: there is some 2.6 code at openmosix but it is not accepted by Linus <BenC> as we discussed at the last Developers Summit, a group will have to develop this outside of ubuntu proper, and then seek inclusion, so I suggest getting on the bandwagon with people who want to do the same to avoid extra work and conflicts <fabbione> lucasvo: because the userland is broken. <fabbione> and the patch for 2.6 probably sucks <fabbione> BenC: exactly <BenC> lucasvo: accepted by upstream as in linus? <BenC> don't see that happening with many clustering systems <lucasvo> I mean this use case: Hospital delta is deploying hundreds of thin clients with Ubuntu and LTSP, and wants complete failover for the terminal services. <lucasvo> BenC: yes <BenC> it will get into ubuntu before it gets into kernel proper :) <fabbione> lucasvo: that's not an openmosix cluster <BenC> why the criteria for inclusion with linus? <fabbione> that's a HA cluster <lucasvo> fabbione: yes <lucasvo> fabbione: but I actually want HPC <fabbione> lucasvo: we don't have it and we won't for a while :) same answer as before. ;) <fabbione> lucasvo: we might be able to provide slurm (job queue scheduler) <fabbione> but that's it for dapper <lucasvo> fabbione: I am not talking about dapper more about dapper+ 1 or 2 <lucasvo> fabbione: and I would like to develop it, I don't want out of the box solution <fabbione> lucasvo: from here to dapper+1 there are at least another 10 months.. perhaps by that time there will be available solution.. <fabbione> who knows.. <zul> hola fabbione <fabbione> hey zul <BenC> yo zul <zul> hey benco <BenC> jbailey: ping <zul> ugh..this is an ugly website <zul> http://wwwredesign.gentoo.org/ <fabbione> BenC: sparc is at dpkg-deb now :) <BenC> fabbione: sparc success will finally mean an upload went as planned :) <fabbione> ehehhe <BenC> goal for -6 is to disable all the drivers that have missing symbols (mostly smp and 64-bit incompatible drivers) <fabbione> yeah <fabbione> i saw a bunch <BenC> wow, linus tagged 2.6.15-rc3 just a mere 29 minutes after I tagged 2.6.15-5.7 <BenC> my timing is improving :) <dilinger> heh <fabbione> ehhe <zul> slacker <zul> :) <zul> BenC: i wrote a patch for the atkbd last night its in my git archive <fabbione> zul: patch to do what? <zul> remove that unknown key bullshit <zul> fabbione: http://zulinux.homelinux.net/cgi-bin/gitweb.cgi?p=ubuntu-2.6.git;a=commit;h=1ec11f9bc0963516a9b944e43fb89fbf5545a27b <BenC> silly printk, warnings are for developers <fabbione> bah it's just a warning <fabbione> linux-source-2.6.15_2.6.15-5.7: successful <BenC> but it causes uneeded bug reports * fabbione ^5s BenC <BenC> sweet <BenC> cool, latest git has --no-merge for git-pull <BenC> so you can inspect before merging and committing <fabbione> eheh <fabbione> i didn't play with git that much <fabbione> i rely mostly on what you tell me <fabbione> + my ppc is down until i can unfuck partman-auto-lvm <zul> fabbione: i know but a user complained about it and its annoying the fuck out of me on my laptop <fabbione> BenC: <fabbione> fabbione willy: i am cool with that.. ben is merging rc3 and i was wondering when we could pull from you.. i expect lamont wants that ;) <fabbione> willy fabbione: keep pulling from cvs <fabbione> ^^ hppa tree <BenC> fabbione: not only that, but even if we switch it to KERN_INFO, it will still cause uneeded fillage of kern.log (and clearing of the dmesg buffer) <BenC> fabbione: I'll leave it up to lamont to get me a diff from CVS <fabbione> BenC: is there actually anything that use that output? iirc we were using it to track kernel -> X -> gnome keyboard issues <fabbione> BenC: didn't you pull from hppa git once? <BenC> fabbione: yeah <fabbione> ok <lamont> BenC: once they finish the rc3 merge, I'll gen a diff <BenC> not sure about tracking the keys <fabbione> lamont: better if you push them to move to git :P <BenC> yeah, there's a freaking CVS tool fot git anyway :) <lamont> fabbione: the trick is to help them get the infrastructure git-happy, and then it'll happen... it's not that they don't want to move. <lamont> BenC: its the autobuild stuff, and such <BenC> ah <lamont> bunch of home-grown tools to do thing <lamont> s <fabbione> lamont: yeah i understand that... <BenC> I'm a little leary of taking a cold monolithic patch for hppa, if they will get around to being in git real soon <fabbione> that's exactly what i was thinking <BenC> maybe we can do what fabbione and I discussed and just run patch/unpatch for that one diff <fabbione> but you might endup duplicating the merge work <BenC> or I might be off by a line or two and cause uneeded deltas in our tree <fabbione> since they do it and you have to do it to pull in rc3 <fabbione> perhaps talk with them and see how to handle it best? <lamont> gah. git-core goes through 0.99.9i, and then it's git_0.99.9j - wish they'd make up their mind <BenC> lamont: apt-get install git-core (from dapper universe) <BenC> fabbione: bah, git-core is not built for sparc yet! :) <fabbione> BenC: hmmm probably <fabbione> git-core: <fabbione> Package : git-core <fabbione> Version : 0.99.9j-1 <fabbione> State : Needs-Build <fabbione> yeah * BenC tries to remember that Alt+F4 in X will not get him to VT4 <fabbione> ahhahahahah <fabbione> BenC: the universe buildd is almost at the end of gcc-snapshot <fabbione> that's probably why it didn't built yet <fabbione> and i did unleash the kde mess just today <fabbione> so the main buildd is like utterly busy <BenC> fabbione: FYI, if you have trouble finding an affordable ultra for the DC, I know where you can get UE 4500's for pretty cheap <fabbione> BenC: you should tell that to elmo/znarl.. but afaik they are looking into new hw <fabbione> it needs to be as small as possible (size wise) <fabbione> because we pay hosting by size <fabbione> but i am not sure 100% <fabbione> things keep changing on a daily base <BenC> yeah, the 4500 isn't small, but it's cheap and powerful <fabbione> yeah i know <fabbione> ok time to stop for today <fabbione> or better <fabbione> start cooking some real food * lamont builds -9k on breezy <lamont> git push ssh://rookery.ubuntu.com/home/lamont/public_html/archives/ubuntu-2.6.git <lamont> bash: git-receive-pack: command not found * lamont grunbles <lamont> and grumbles, too <lamont> BenC: would you be so kind as to send RT a request to install git on rookery? <lamont> meanwhile, I've updated ~/.bashrc <BenC> on rookery, you can point to my git bin's <lamont> only if .bashrc says to * lamont has a copy of git in ~/bin <BenC> lamont: done <BenC> well, rt ticket sent, not installed yet :) <lamont> right <lamont> thanks <lamont> 'tis better coming from you, and all that. <CataEnry> bye all <zul> garrr...i hate batch files <mjg59> BenC: ACPI sleep support doesn't seem to be getting initialised on i386, for some reason <BenC> mjg59: ok, I'll look at it in a little bit <mjg59> BenC: Uhm. CONFIG_ACPI_SLEEP is missing <mjg59> On -686, at least <mjg59> BenC: Also, http://lkml.org/lkml/2005/11/29/74 <mjg59> Can we grab that? <BenC> Kconfig shows "depends ... (!SMP ...)" for ACPI_SLEEP <BenC> I'll get that patch, sure <BenC> is suspend/resume not compatible with smp? <mjg59> I was under the impression it had been fixed <mjg59> But that may not have been merged yet <mjg59> BenC: If we can't fix that, then I guess we'll have to go back to UP kernels <BenC> I can do another pull from acpi git and see <mjg59> Looks like there were patches in April <mjg59> They may never have been merged <mjg59> The acpi git tree doesn't seem to have been updated in months <BenC> are you checking the right acpi branch? <mjg59> Hm. Which is the right one? <BenC> I'm using the "test" branch that -mm uses <mjg59> Ah <BenC> lamont: ping <mjg59> Yeah, last one there seems to be September <mjg59> The code isn't in -mm now. It was back in 2.6.12 time. <BenC> -mm is pulling from that test git branch is all <mjg59> Well, either we forward-port the stuff from 6 months ago, or we go back to shipping UP kernels <BenC> how large was the "works on smp" stuff? <BenC> a huge portion of the acpi stuff was already merged, so we can't just apply the acpi dpatch from breezy <mjg59> I don't know if we had it in Breezy <mjg59> And I can't find the patches nicely bundled anywhere <mjg59> http://www.kernel.org/pub/linux/kernel/people/akpm/patches/(864)930-0890-mm1/broken-out/ seems to be the latest ones <mjg59> Various patches from there are needed <mjg59> But it looks like there's runtime checks /anyway/ <mjg59> So just force the !SMP for now? <mjg59> Hang on <mjg59> It looks like there's support for it <mjg59> BenC: Nngh <mjg59> BenC: Can you just turn on CONFIG_HOTPLUG_CPU? <mjg59> That ought to make it work <BenC> ok <dilinger> this machine loves to hang for 1/2 a second at random times since upgrading to breezy :/ <BenC> lamont: ping <zul^> later folks <BenC> lamont: I got a hppa64-smp vmlinux <BenC> lamont: most of the breezy hppa patch was in the git, except the compat signal/siginfo stuff, which wasn't that much <BenC> I'll try to boot it shortly <lamont> oh, way cool <BenC> mjg69: enabled hotplug_cpu for amd64 and i386 targets, along with acpi sleep/suspend stuff <mjg59> BenC: Rock, thanks <mjg59> BenC: Does that break ABI? <BenC> doing an abi bump anyway, since I synced a lot from linus <mjg59> Ok <mjg59> Any ETA on uploading it? <BenC> lamont: do you have a breezy palo.conf I can look at? <BenC> mjg59: 2-3 days, depending on lrm and vga16fb patch <mjg59> Suspend/resume tends to show breakage at all sorts of inopportune moments, so it'd be good to get as much testing time as possible <mjg59> BenC: Ok, sounds good <BenC> just glad we could enable it without a lot of extra patching :) <lamont> BenC: yeah <BenC> and /etc/kernel-img.conf if you don't mind <BenC> my system is just a dist-upgraded woody box (really old) <lamont> btw, if you're so inclined, please enable BLK_DEV_IDEPCI, BLK_DEV_IDEDMA_PCI, and then BLK_DEV_NS87415 - fabbione and I will thank you <lamont> all hppa configs, as modules where appropriate <BenC> ok, I wont need those for my
{'channel': 'ubuntu-kernel', 'month': 12}