=== kylem [n=kyle@206-248-151-76.dsl.ncf.ca] has joined #ubuntu-kernel === johanbr [n=j@jupiter.physics.ubc.ca] has joined #ubuntu-kernel [12:50] BenC: MWAHAHAHAHAH [12:50] I mean. [12:50] It's all good. =) [12:55] who...xen-image-2.6.16-1-xen-686_2.6.16-1_i386.deb [12:58] Nice! [12:58] Next I should make libc6-xen not suck. [12:58] Hmm [12:59] Maybe later this week. [12:59] Still one more merge to do tomorrow. === _human_blip_ [n=mike@220.157.65.29] has joined #ubuntu-kernel === nigel_c [n=nigel@nigel.suspend2.net] has joined #ubuntu-kernel === zul [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel === johanbr [n=j@d154-20-189-105.bchsia.telus.net] has joined #ubuntu-kernel === zul_ [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel === nigel_1 [n=nigel@nigel.suspend2.net] has joined #ubuntu-kernel === nigel_1 is now known as nigel_c === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #ubuntu-kernel === chris__ [n=chris@p54BE4619.dip0.t-ipconnect.de] has joined #ubuntu-kernel === chris__ [n=chris@p54BE4619.dip0.t-ipconnect.de] has left #ubuntu-kernel ["Ex-Chat"] === human_blip [n=mike@220.157.65.29] has joined #ubuntu-kernel === Lure [n=lure@ubuntu/member/lure] has joined #ubuntu-kernel === ivoks [n=ivoks@ubuntu/member/ivoks] has joined #ubuntu-kernel === doko [n=doko@dslb-088-073-107-122.pools.arcor-ip.net] has joined #ubuntu-kernel === lloydinho [n=andreas@rosinante.egmont-kol.dk] has joined #ubuntu-kernel === _human_blip_away [n=mike@220.157.65.29] has joined #ubuntu-kernel === mdz_ [n=mdz@studiocity-motorola-bsr1-70-36-194-85.vnnyca.adelphia.net] has joined #ubuntu-kernel === nigel_c [n=nigel@nigel.suspend2.net] has joined #ubuntu-kernel === Lure [n=lure@ubuntu/member/lure] has joined #ubuntu-kernel === zul [n=chuck@dsl-72-1-199.219.tel-ott.com] has joined #ubuntu-kernel [02:13] hey === Keybuk [n=scott@quest.netsplit.com] has joined #ubuntu-kernel === tuxmaniac [n=aanjhan@unaffiliated/tuxmaniac] has joined #ubuntu-kernel === ivoks [n=ivoks@ubuntu/member/ivoks] has joined #ubuntu-kernel === lloydinho [n=andreas@rosinante.egmont-kol.dk] has joined #ubuntu-kernel === zul [n=chuck@ubuntu/member/zul] has joined #ubuntu-kernel === BenC [n=bcollins@debian/developer/bcollins] has joined #ubuntu-kernel [05:06] hey BenC [05:21] hey [05:21] kernel-wedge is done, finishing up kernel-package [05:21] cool... [05:46] infinity, jbailey: ping [05:46] whoo...lunch time [05:46] BenC: pong, about to go for lunch [05:49] jbailey: nm, I'll ask adam about initramfs-tools [05:49] ask him which? [05:50] I want to sync it with debian along with kernel-{package,wedge} [05:50] BenC: I'm doing initramfs-tools [05:50] Don't sync it. [05:50] It would break alot of things. [05:50] ah, ok [05:51] Like, anyone who needs a framebuffer to work. =) [05:52] I'm really surprised that kernel-package isn't using update-initramfs now that it's in debian's initramfs-tools [05:52] jbailey: while you are at it can you also look at the bug i did open today? [05:52] anyone know how debian is doing this...I recall they had a smimilar tool now === lloydinho_ [n=andreas@rosinante.egmont-kol.dk] has joined #ubuntu-kernel [06:40] Keybuk: kernel-wedge uploaded [06:40] kernel-package is almost done [06:40] cool [07:03] BenC: Debian still supports yaird. [07:05] yaird? [07:06] yet-another-init-rd [07:06] ah ok [07:17] Creative naming and all. =) === ivoks [n=ivoks@ubuntu/member/ivoks] has joined #ubuntu-kernel [07:17] hehe.. [07:36] BenC: mkinitramfs-kpkg [07:36] wrapper around mkinitramfs [07:36] Manoj wanted to stay on old style calling convention of initrd/initramfs generators [07:37] yaird is dead water doesn't have decent uuid support [07:37] where's that script come from? [07:38] makx: Does yaird's author consider it dead yet? [07:38] makx: Are do we still have to crush it with proper dep support in initramfs-tools. [07:38] jbailey mia since end of last year [07:39] proper dep support is on my TODO list [07:39] let's see how badly I screwed up this kernel-package sync [07:39] but i'd prefer to have klibc only initramfs before [07:39] that is much higher priority [07:41] BenC: yaird is a perl vodoo [07:41] makx: infinity said that he thought dep mode should be easy enough to do with the infrastructure in there. [07:41] makx: No, I want to know where mkinitramfs-kpkg comes from :) [07:42] But that klibc-only meant that you need to have some ability to detect when it's going to need more and then go all glibc/busybox. [07:42] BenC: initramfs-tools [07:42] Oh? [07:42] I haven't started the merge yet, is that something I need to bring into Ubuntu? [07:42] jbailey: busybox needing boot scripts put an echo "BUSYBOX=y" in /usr/share/initramfs-tools/conf.d/ [07:43] jbailey: which merge haven't you started yet ? [07:43] Keybuk: initramfs-tools. [07:43] jbailey: !! [07:43] Keybuk: I'm not doing any other merges. [07:43] jbaley: depends on your kernel-package [07:43] Keybuk: What, there''s still 4 hours left in my workdayu. [07:43] uups evident typo [07:44] jbailey: hehe, you think you can do it in 4 hours? :p [07:44] Keybuk: I sponsor almost every upload to Debian. [07:44] fair enough [07:44] Keybuk: That's why I still know the code as well as I do. =) [07:44] a klibc-only initramfs always seems like a waste of effort [07:44] you have to compile everything twice, once for klibc and once for glibc [07:45] nack [07:45] and then you find something that doesn't work with klibc, and *boom* you may as well just go back to glibc again [07:45] if it was done right, it'd be awesome though [07:45] sure, if we didn't need evms, lvm, etc. I'd love it [07:45] you get a much smaller initramfs [07:45] Keybuk: Given that klibc's on the running system, for anythign appropriate, you should just compile it once with klibc. [07:45] jbailey: disagree, you can't debug things compiled with klibc [07:45] yeah, having klibc+glibc in initramfs isn't so bad [07:46] Keybuk: I've used gdb on klibc binaries. [07:46] BenC: except it somewhat defeats the point of compiling things additionally against klibc in the first place ... at that point you may as well just compile them against glibc [07:46] Keybuk: more and more things will get klibc ready [07:47] makx: really? [07:47] klibc+glibc in corner cases isn't that bad, if we can make most installs klibs only [07:47] given that the udev upstream has abandoned all attempts to make it work with klibc, I'd challenge that [07:47] likewise the modprobe upstream [07:47] Isn't modprobe and udev upstream the same person? ;) [07:47] ^ new [07:47] no, modprobe upstream is Jon Masters (now) and previously Rusty Russell [07:47] Keybuk: well because klibc was not entering linus tree [07:47] it is on its way now [07:48] I'm all for a klibc-ONLY initramfs, don't get me wrong [07:48] kpartx works already === ivoks_ [n=ivoks@lns02-1513.dsl.iskon.hr] has joined #ubuntu-kernel [07:48] Keybuk: oh i was just explaining what will push upstreams to work with klibc [07:49] eh, we should strive to get rid of glibc even on the running system and do klibc only :) === Keybuk makes BenC stand in the corner [07:49] that's almost Tollef levels of evilness [07:49] BenC: Spoken like a former glibc maintainer. =) [07:49] BenC: then we will see klibc growing up to libc7 [07:49] if you all continue to blame everything on the kernel, then I have no choice but to put everything in it :) [07:50] BenC: let's merge gcc and glibc into the kernel source [07:50] boot strap of death [07:50] hehe, a bootstrap with real reboots :) [07:50] They proposed merging a c compiler in at one point. [07:51] can we get X merged into the kernel too? [07:51] jbailey: there is already a bootloader that can build the kernel at boot time [07:51] jbailey: tcc? [07:51] Keybuk: I don't remember which one, but it was along the lines of "We don't trust the optimisers anyway, so why not just use our own compiler?" [07:51] Keybuk: X already *is* in the kernel, silly. [07:52] X is just a kernel extension anyway...why give it a life of it's own [07:53] BenC: yeah right.. why all this drm/dri sync issues.. let's just add mesa and server and drivers to the kernel [07:53] hmm...new kernel package screws up my automated build scripts [07:53] actually, if we stick everything in the kernel, it'll stop them being evil and thinking about putting partition detection into userspace [07:53] or filesystems into userspace, etc. [07:54] or proposing perl/python/c++ kernel modules [07:54] Keybuk: Partition detection is *already* in userspace. [07:54] Keybuk: We just need to get the last dregs out of the kernel. [07:55] I know, and I hate it [07:55] like the part that reads the partion map? :) [07:55] BenC: If you use evms, and (I think) LVM, all of that is redone by a userspace daemon anyway. [07:55] partition map could be done in userspace now, I think [07:56] thank god evms and lvm are gone from our default install [07:56] Did we pitch lvm? [07:56] using stuff like loop devices to point to block offsets on a drive [07:56] jbailey: yeah, it's something that shouldn't be in by default [07:56] if people want it, it can be installed [07:57] Keybuk: lvm is Good And Right, dude. =) [07:57] no, it, is, not [07:57] Keybuk: The problem with just doing things on raw partitions is that it's hard to do anythign useful later on. [07:57] You can't just add a drive and span the partition, or add a drive and mirror. [07:57] lvm doesn't scale well [07:58] the idea might be cute, but the implementation is from the dark ages [07:58] try creating > 800 logical volumes, and then restart lvm (if you actually get them created) [07:59] you'll see what I mean === jbailey tries to imagine a system where 800 LVs would be a good idea. [07:59] office fileserver [08:00] where each user has his own logical volume [08:00] To overcome how badly the quota system sucks? =) [08:00] does away with silly quota stuff [08:00] :) [08:01] I actually used it in a commercial produce (www.swissdisk.com) so each customer has an encrypted filesystem [08:01] s/produce/product/ [08:01] Ah, I could see that. [08:01] I had to man handle the meta-data areas [08:01] Although if you're doing that, you really want to make sure that it doesn't pre-allocate all the space for each user. [08:01] hack the hell out of the userspace tools, just to keep things limping along [08:03] the main problem is that it takes 20 minutes to start lvm [08:04] rebooting the e4500 takes 10 minutes already...requiring 30 minutes for a reboot cycle minimum [08:04] Yeah. I can see that sucking. Transparently migrating and extending filesystems does rock though. One of my favourite parts of AIX is the everything-on-lvm bit. [08:05] yeah, the whole idea of lvm kicks ass [08:05] but I agree with Keybuk, the implementation sucks ass [08:05] all you really want is the ability to tell the kernel to create a block device, based on other block devices [08:05] e.g. "foo1" is "sda1 from block 512 to block 1000" and then "sda2 from block 0 to block 1024" [08:06] and have the kernel map foo1 block requests to the underlying physical blocks [08:06] then you could set the block maps from udev [08:06] and as foo1 would have a kobject in the block subsystem, udev would also know about virtual block devices [08:07] dpkg-gencontrol: error: package linux-headers-2.6.17-5-g3611c20c-dirty not in control info [08:07] kernel-package is really whacked out on this [08:07] BenC: Noone's really working on a better lvm, are they? [08:07] "they seem me rollin', they hatin', patrollin' and trying to catch me ridin dirty" [08:08] jbailey: not that I know of [08:09] actually, it strikes me that the above would not be difficult to implement [08:09] I still remember the painful migration to lvm2 [08:10] It would be good if someone got it right, really right. :) [08:13] fedora does default lvm installs irc [08:14] didn't knew that the ubuntu default installs no longer do it [08:14] Nah, not default, just easy to add. There's an lvm button. [08:15] without lvm2 even more args for klibc initramfs-tools: faster boot [08:21] makx: not much faster [08:21] it's all in RAM anyway [08:21] cjb: that's the same theory we're taking, if someone clicks "LVM" in the installer, we can always add it [08:56] Keybuk: kernel-package looks ok, but I want to do a full 6-arch build with it to make sure [08:56] probably upload in a few hours === kylem [n=kyle@206-248-151-76.dsl.ncf.ca] has joined #ubuntu-kernel [09:09] okey dokey [09:38] Keybuk: that's exactly what device-mapper does [09:39] mdz: except that device mapper is its own subsystem, and doesn't just use the block subsystem [09:40] and device-mapper isn't kobjectified [09:40] etc. [09:50] anyone familiar with the debconf voodoo? [09:51] new kernel-package image postrm script calls purge() and it seems to be causing the postrm script to fail for some unknown reason (even though it "exit 0"'s at the end) [09:52] if I comment out "my $ret = purge();", the script finishes and dpkg is happy [09:52] excuse me, the script finishes no matter what, but with the purge() dpkg gets a non-zero exit [09:53] Perl implicitly returns the last scalar evaled as a ret value. [09:53] So if the exit 0 isn't in the path, I'd say that purge() is failing and it's being passed on. [09:54] But I don't know the code. Just letting you know that there's an implicit 'return $ret' on the end if that's the last assignment in the sub. === ivoks [n=ivoks@ubuntu/member/ivoks] has joined #ubuntu-kernel [09:57] so $ret is special? [09:58] No, the last assignment of a sub is special. [09:59] my $ret = purge(); [09:59] .... [09:59] exit 0; [09:59] Ah. [09:59] the .... is mainly a var and a for loop [09:59] Dunno, then. [10:00] You're sure it's hitting exit 0, rather than an exit 1 inside purge() or something? [10:00] yeah [10:00] I placed warn's all the way down to just before the exit [10:04] later === johanbr [n=j@jupiter.physics.ubc.ca] has joined #ubuntu-kernel [10:49] Uh oh, someone from BC.. [10:55] jbailey: yeah, I've sent the boys around to find out what's happened to initramfs-tools :p [10:57] Keybuk: Hmm? [10:58] Oh, lol =) [10:58] ya know what, I'm going to entirely abandon our n-m packages [10:58] and just fix the Debian ones === nigel_c [n=nigel@nigel.suspend2.net] has joined #ubuntu-kernel [11:40] that sounds entirely reasonable. [12:01] Keybuk: You could rejoin Debian and hijack the package ;) [12:03] that would involve touching n-m :) === mdz_ [n=mdz@studiocity-motorola-bsr1-70-36-194-85.vnnyca.adelphia.net] has joined #ubuntu-kernel [12:08] jbailey: Yes, watch out for us coffee-drinking hippies.