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