[12:12] <jwest-> maybe try this tommorrow
[12:12] <jwest-> thanks though
[12:56] <zul> hey
[01:37] <kylem> benc. ok. i found the problem.
[01:37] <kylem> but my wireless crapped out before i was able to mention it.
[01:39] <zul> aiie....slow close
[01:43] <kylem> fuck, and it is crapping out now.
[01:44] <zul> i blame the westin
[01:44] <zul> ...and i should be there tomorrow
[01:45] <kylem> nice.
[01:45] <kylem> BenC, would it help if i fed you parisc patches? i can probably pretty easily automatically populate a tree.
[01:46] <BenC> _kylem: If I can git-pull them against 2.6.17.x, then yeayh
[01:47] <BenC> or against a clone of the ubuntu git tree
[01:48] <kylem> okie doke.
[01:54] <BenC> so what's the problem?
[01:54] <kylem> you pulled the async scsi scanning stuff from the parisc tree. unless scsi is built into the kernel (so it can be __init) it won't pause and wait for the async scan to complete.
[01:55] <kylem> i'm genning a diff to revert that bit.
[01:55] <kylem> otherwise there's a bit in cvs now that gives you a module to load.
[01:55] <kylem> (it's designed to be the last thing the initramfs loads, and waits for scans to completE)
[02:13] <BenC> oh really?
[02:14] <BenC> that'd be interesting...Kamion would actually like it so he doesn't have to load ide_generic in weird ways
[02:14] <BenC> but that doesn't solve the problem of our current config not even getting serial output
[02:14] <BenC> s/serial/console/
[02:58] <zul> BenC, when you get a sec can you check my kernel config and im not on crack or anything my initrd seems to be failing
[03:01] <BenC> xen?
[03:01] <zul> yep
[04:17] <fabbione> morning guys
[04:18] <zul> you are up early
[04:18] <fabbione> yeah change of core hours
[04:18] <fabbione> it's too warm during the day
[04:18] <zul> ah
[05:22] <BenC> fabbione: I have it pulled, just finishing some things up before a push
[05:25] <fabbione> BenC: cool! thanks a lot dude
[05:25] <fabbione> getting this redhat stuff sorted has been a real pain
[05:25] <fabbione> but i am down to 4 patches from 13
[05:26] <fabbione> all the other 9 have been absorbed upstream
[09:41] <pmjdebruijn> hi
[09:56] <pmjdebruijn> how can I change the ubuntu-kernel configs through menu config?
[10:01] <pmjdebruijn> I only see the old config stuff in on wiki
[02:18] <zul> hi
[02:19] <pmjdebruijn> http://paste.ubuntu-nl.org/18429
[02:19] <pmjdebruijn> why does the dapper kernel break when compiled on Debian?
[02:25] <bernard_> pmjdebruijn: i suspect it broke because acpi is not enabled
[02:26] <pmjdebruijn> bernard_, yeah, right... but that should be considered a bug right?
[02:32] <bernard_> yup. i guess ubuntu kernels are rarely compiled with acpi off. it should be a trivial fix though. if you look inside arch/i386/kernel/setup.c, the call to check_acpi_pci() just needs to move inside the #ifdef CONFIG_ACPI block.
[02:35] <pmjdebruijn> hmm right
[02:39] <pmjdebruijn> it's already surrounded by a #ifdef CONFIG_X86_IO_APIC
[02:41] <bernard_> yes. it needs to go inside CONFIG_ACPI also.
[02:49] <pmjdebruijn> bernard_, ok, will do
[03:09] <pmjdebruijn> if my fix/patch works, where should I submit it, it seems asif launchpad doesn't accept kernel bugs
[03:09] <zul> yes it does
[03:10] <zul> look for linux-source-2.6.15
[03:11] <zul> BenC: my kernel-package patch works
[03:14] <pmjdebruijn> oh and how do I figure out which IO scheduler I'm using?
[03:14] <pmjdebruijn> my dmesg doesn't clear that up
[03:15] <makx> grep sched /var/log/dmesg
[03:15] <makx> indicated by the (default) line
[03:16] <pmjdebruijn> makx, I have no (default) line
[03:16] <pmjdebruijn> that's my point
[03:17] <maswan> pmjdebruijn: /sys/block/<device>/queue/scheduler
[03:18] <pmjdebruijn> noop [anticipatory]  deadline cfq
[03:18] <pmjdebruijn> right!
[03:18] <pmjdebruijn> that's what I was afraid of... anticipatory is still default :(
[03:55] <pmjdebruijn> I'm trying to backport the edgy kernel to dapper
[03:55] <pmjdebruijn> and I'm getting this:
[03:55] <pmjdebruijn> http://paste.ubuntu-nl.org/18437
[03:56] <pmjdebruijn> I'm doing to this primarily to see whether there have been fixes to usb-mass-storage, because my usb-mp3-player doesn't work properly
[04:18] <Keybuk> "His suggestion was to merge it into x86-64 as a sort of special case - making Andi Kleen its maintainer in the process. Andi showed a striking lack of enthusiasm for this idea."
[04:18] <Keybuk> hahaha
[04:19] <Keybuk> (on i386)
[04:31] <thom> heh
[05:04] <fabbione> BenC: http://librarian.launchpad.net/3501440/buildlog_ubuntu-edgy-sparc.ocfs2-tools_1.2.1-1ubuntu2_FAILEDTOBUILD.txt.gz
[05:04] <fabbione> are headers still broken on sparc?
[05:05] <Mithrandir> BenC: freeze is over now, so you're free to upload your kernel stuff.
[05:05] <BenC> Mithrandir: thanks
[05:05] <BenC> fabbione: shouldn't be
[05:06] <fabbione> BenC: looks like we are still missing headers....
[05:13] <makx> Keybuk: any conterargs if i kill of the prereqs stuff in initramfs-tools?
[05:13] <Mithrandir> makx: uh?
[05:14] <Keybuk> makx: I've always thought it was silly, as it wastes time on boot ... I always thought we should just assemble it in the right order at update-initramfs time
[05:14] <Keybuk> *BUT* jbailey will point out the initramfs is supposed to be runtime assembled
[05:14] <Keybuk> which is why you need the PREREQS
[05:15] <makx> Keybuk: what about numerical order aka 05evms 10md 20lvm 90cryptsetup
[05:15] <Keybuk> it's allegedly less flexible
[05:15] <makx> prereqs has no easy way to be first or last
[05:15] <Keybuk> I was actually mulling the idea of maybe replacing the initramfs init with upstart ... ;)
[05:16] <makx> prereqs wasts boot time and hinders klibc only plan
[05:16] <makx> what is upstart?
[05:17] <zul> BenC: ill send you the patch tonight for kernel-package its a very small patch
[05:17] <makx> also lots of script writer get-their.name-totally_wrong
[05:20] <BenC> fabbione: Actually, it looks more like sparc headers are just broken
 are headers still broken on sparc? <-
[05:20] <fabbione> :)
[05:20] <BenC> fabbione: the include for those headers should probably be wrapped in __KERNEL__
[05:21] <BenC> actually, why is ocfs2 including page.h anyway?
[05:21] <BenC> on all other arches, it is an empty file
[05:21] <BenC> in lkh at least
[05:22] <fabbione> BenC: no idea
[05:22] <fabbione> it was building before
[05:24] <makx> Keybuk: google doesn't give hints on upstart? -v 
[05:24] <Keybuk> http://wiki.ubuntu.com/ReplacementInit
[05:24] <Keybuk> makx: why do prereqs affect klibc-only?
[05:24] <BenC> fabbione: I'd edit mount.ocfs2.h and remove the asm/page.h include
[05:25] <fabbione> BenC: can you make sure that's the right thing to do?
[05:25] <BenC> fabbione: nm, I see the problem...it'll be fixed in the next upload
[05:26] <fabbione> ok
[05:26] <fabbione> thanks
[05:26] <BenC> that actually is the right thing, but I can work around it
[05:26] <fabbione> well if it's the right thing i can do it
[05:26] <makx> Keybuk: basename usage - thought to get rid of both as prereqs is flacky
[05:26] <fabbione> i am just on the edge every day to leave stuff in proper order
[05:27] <BenC> fabbione: it's the right thing, but I'm not sure it will work :)
[05:27] <makx> Keybuk: btw thx for the doc
[05:27] <fabbione> BenC: exactly :)
[05:27] <Keybuk> makx: it's intended as our replacement for /sbin/init in the real root ... but for edgy+1 it may make some sense to start it in the initramfs instead <g>
[05:28] <pmjdebruijn> anybody here a clue why this fails: http://paste.ubuntu-nl.org/18437
[05:35] <fabbione> BenC: it looks like we will need to go and dig into GFS2/GFS failures. According to upstream it works for them and it fails with our kernel
[05:35] <BenC> lamont: ping
[05:35] <makx> Keybuk: there is an side issue not mentioned in this spec, usually when you upgrade a Debian box you find lots of devices running that weren't before
[05:36] <Keybuk> makx: "devices running" ?
[05:36] <makx> Keybuk: sorry to warm s/devices/services/
[05:36] <pmjdebruijn> oh silly me, it's because of the extra tag
[05:37] <Keybuk> makx: right, upgrade brings in new services ... ?
[05:37] <BenC> well, it might bring in new devices too :)
[05:37] <BenC> ipw3945 comes to mind
[05:37] <makx> Keybuk: no postinst brings new service that wasn't running before upgrade
[05:37] <Keybuk> BenC: if an upgrade to etch upgraded my atheros to an ipw3495 I'd be impressed
[05:37] <Keybuk> makx: oh, right ... the way a postinst starts a service you explicitly stopped
[05:38] <BenC> ah, I thought you meant general upgrades
[05:38] <makx> Keybuk: yup
[05:39] <pmjdebruijn> bernard_, thanks for the help, I posted it: https://launchpad.net/bugs/53533
[05:43] <bernard_> pmjdebruijn: looks good! ta.
[05:50] <makx> Keybuk: daemontools are not mentioned, they are the best for keeping services up atm
[05:51] <Keybuk> makx: that goes nowhere near the use cases mentioned
[05:51] <makx> Keybuk: matches Corey
[05:53] <Keybuk> which is near the bottom, no?
[05:53] <makx> second use case afais
[05:54] <fabbione> Keybuk: any chance you can upload udev to fix libvolumeid today?
[05:55] <Keybuk> fabbione: yes
[05:55] <fabbione> Keybuk: thanks dude
[05:56] <zul> makx: is there any changes to initramfs that debian did for xen?
[05:57] <makx> run depmod if that wasn't run previously
[05:57] <zul> ah ok
[06:27] <zul> if anyone is interested the proceddings for ols is up http://www.linuxsymposium.org/2006/proceedings.php 
[06:46] <makx> Keybuk: it would be cool if that init could snapshot like resume to disk some parts of the boot process :)
[06:48] <Keybuk> makx: how do you mean?
[06:48] <zul> wohoo..
[06:48] <zul> xen_mem: Initialising balloon driver.
[06:49] <makx> Keybuk: idea from aboves ols proceeding
[06:49] <Keybuk> makx: -v please :p
[06:49] <makx> see "Improving Linux Startup Time Using Software Resume"
[06:50] <makx> this ols papers features the idea of snapshot booting
[06:50] <mjg59> It's not a bad idea
[06:51] <mjg59> Would need careful integration work, though
[08:44] <makx> Keybuk: using shell parameter expansion instead of basename, works well. so leaving the prereqs for now.
[12:09] <kriebly> my Dell Precision 470's  aren't happy with the kernel I compiled from linux-source-2.6.15_2.6.15-26.45 :(
[12:10] <kriebly> need to do more troubleshooting...
[12:10] <kriebly> i probably missed something simple
[12:10] <kriebly> cd /join nethack