[06:16] <fabbione> morning
[06:51] <jbailey> Fabio!
[06:54] <jbailey> fabbione: I have kernelish things to pester you about too re: initramfs. =)
[06:54] <fabbione> jbailey: sure.. go ahead
[06:54] <jbailey> Part of what I want to do is have the kernel ship bundles of things to be included in the initramfs - Like a collection of ide drivers in a cpio file, or scsi drivers, or net/nfs drivers, etc...
[06:55] <fabbione> hmmm ok
[06:55] <fabbione> why do you need it shipit in a special way?
[06:55] <jbailey> I want to take the logic of choosing the drivers to include out of the hands of the initramfs and have it assemble the initramfs from bundles that exist on the system.
[06:56] <jbailey> The eventual goal is that grub or whatever bootloader should be able to assemble them at runtime.
[06:56] <jbailey> So there's no work to be done by mkinitramfs at all on each kernel install.
[06:56] <jbailey> Remove the generation step completely.  That's a future.
[06:57] <jbailey> Have you looked at the initramfs stuff at all?
[06:57] <fabbione> i am not sure i understand ....
[06:57] <fabbione> just give me a sec... brb
[06:57] <jbailey> Sure, or I can come back in 6 hours to talk then.  I should go to sleep. =)
[06:57] <fabbione> re
[06:58] <fabbione> no i didn't look at initramfs at all yet
[06:58] <fabbione> i know you need modules.. that's crystal clear :)
[06:58] <fabbione> what i don't understand is why the kernel should select them for you
[06:58] <fabbione> it sounds a lot like creating a udeb
[06:58] <jbailey> Which I also think the kernel package should do...
[06:59] <jbailey> But yes, along the same lines of it.
[06:59] <fabbione> and how do you want me to ship what?
[07:00] <jbailey> Basically gzip'd cpio files.
[07:00] <jbailey> Of the modules that would be interesting for booting.
[07:00] <fabbione> yes ok.. but what modules?
[07:00] <jbailey> That's the part that I have to work out with you. =)
[07:00] <fabbione> ah ok
[07:01] <jbailey> I have some guesses. =)  I need more eyes on the problem to get it right.
[07:01] <fabbione> ok..
[07:01] <fabbione> because it sounds like a subset of udeb modules
[07:01] <jbailey> It might be, or it might be the same set, and there might be a sane way of merging the two ideas.
[07:02] <jbailey> Colin and I chatted a bit about the idea that udebs should just be cpio files in Sydney.
[07:02] <jbailey> If that were the case, they could be merged perfectly.
[07:02] <jbailey> I don't expect we'll get it right for Breezy, but I'm hoping we can get it close. =)
[07:03] <fabbione> let's plan a meeting between the 3 of us?
[07:03] <jbailey> Tomorrow (my tomorrow, later today for you..) I'll get a new initramfs-tools up that does all the IDE and SCSI detection correctly, in which case I think the setup should be good for anyone not using lvm or evms.
[07:04] <fabbione> ok
[07:04] <jbailey> I don't have either of those running here, so I need someone else to help me test those setups before I inflict them on the world.
[07:04] <fabbione> i can create test boxes for that
[07:04] <fabbione> that's easy for me
[07:04] <jbailey> Cool.
[07:04] <fabbione> given that probably the default install will be on lvm
[07:04] <jbailey> Really?
[07:04] <jbailey> Wow.
[07:05] <jbailey> Means I should probably learn it. =)
[07:05] <fabbione> it's simple really.. don't be so scared
[07:05] <jbailey> I suspect a simple diagram of how physcial volume, to logical volumes, to device nodes all map together would solve it all for me.
[07:06] <fabbione> sure...
[07:06] <jbailey> It also doesn't help that the PPC installer pretends to support LVM but doesn't really.
[07:06] <jbailey> (Missing parted support before)
[07:06] <jbailey> So the time I spent trying to learn LVM was on a setup that couldn't work.
[07:06] <fabbione> hda* -> each of them add becomes a pv
[07:06] <fabbione> all pv are aggregated into one or more vg
[07:07] <fabbione> you create lvm volumes out of a vg space
[07:07] <fabbione> lvm volumes are like block devices
[07:07] <fabbione> pv is basically a tag that sais device hda1 is part of a vg (volume group)
[07:07] <jbailey> Always aggregated, or sometimes raidN?
[07:07] <fabbione> you can think of a volumegroup as an aggregation of pv
[07:08] <fabbione> always.. you don't see them as devices
[07:08] <fabbione> a vg exports the overall space to lvm
[07:08] <jbailey> Okay, so an md setup would be on top of the vg?
[07:08] <fabbione> than you create the "real" device with lvm
[07:08] <fabbione> i use the other way around
[07:08] <jbailey> or on top of the volume?
[07:08] <fabbione> it makes more sense to have lvm on top of raid
[07:08] <fabbione> but you can do both
[07:09] <jbailey> Creepy. =)
[07:09] <dilinger> i thought you could only do it one way
[07:09] <dilinger> ?
[07:09] <jbailey> Autodetecting that in the initrd will really suck.
[07:09] <fabbione> indeed
[07:09] <fabbione> nah
[07:09] <dilinger> lvm over raid
[07:09] <fabbione> let's make an example:
[07:09] <fabbione> you have 2 partitions... sda1 and sdb2
[07:09] <jbailey> Well, I will have to recurse through detecting and assembliung until I eventually get something with a filesystem on it. =)
[07:10] <fabbione> jbailey: it's possible to detect it.
[07:10] <fabbione> with a very simple C program
[07:10] <jbailey> Oh good. =)
[07:10] <fabbione> i can possibly write it for you
[07:10] <jbailey> Even if you pseudocode if for me, I'd appreciate it.
[07:10] <fabbione> but there are already tools to do that
[07:10] <jbailey> That would do too.
[07:10] <fabbione> jbailey: well basically both lvm and md use metadata on the disk
[07:10] <jbailey> Although a simple C program might be better to keep the size of the stuff on the initramfs down.
[07:11] <fabbione> so you just need to recurse a couple of times to undertsand the layoyt
[07:11] <fabbione> the best way is always to try to detect md before lvm
[07:12] <jbailey> 'k
[07:12] <jbailey> Will you be around in 6 hours?
[07:12] <jbailey> I'm starting to fade.
[07:12] <fabbione> i will be around till 13:00 UTC
[07:12] <fabbione> than i need to go out for a couple of hours
[07:12] <jbailey> Lovely, so I'll have 3 or 4 hours with you.
[07:12] <fabbione> but i can come back .. that's for sure
[07:13] <jbailey> Well, this doesn't have to all happen today, but if I can get started on lvm support that would be lovely.
[07:13] <fabbione> i need to take my wife to the doctor..
[07:13] <jbailey> I want to put out a wider call for testers.
[07:13] <fabbione> so i really can't postpone it
[07:15] <jbailey> jdub is now using initramfs-tools to boot his system. =)
[07:16] <fabbione> ehhehe
[07:18] <jbailey> He pointed out some ide booting issues, but after that, I'm guessing that most of the systems out there could sanely boot with the initramfs without touching their configs.
[07:19] <fabbione> jbailey: i need to get .12 final out.. but i plan to switch to initramfs asap
[07:20] <jbailey> No worries.
[07:20] <jbailey> It needs to be the default for .13
[07:20] <jbailey> I have no intention of fixing initrd-tools to work without devfs.
[07:21] <jbailey> I'm off to pass out.
[07:22] <fabbione> jbailey: i am going to kill devfs in .12 soon
[07:22] <fabbione> we won't get .13 in breezy
[07:22] <jbailey> dilinger: I'll try to look at the cdbs testsuite email you sent tomorrow.  Failing that, I'll do it while at the summit.
[07:22] <jbailey> There's enough talks there that I truly just don't understand, I should have hack time. =)
[07:22] <fabbione> jbailey: let's talk about it later when you wake up :)
[07:22] <fabbione> good night
[07:22] <jbailey> g'n =)
[07:23] <dilinger> jbailey: i committed some small debug changes
[07:23] <jbailey> away "Neque porro quisquam est qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit..."
[07:23] <dilinger> that were attempts at a cleanup
[07:23] <dilinger> but alas, bash stupidity kept me from committing the rest
[07:24] <jbailey> dilinger: Ugh.  Feel free to commit with stuff hardcoded to ${Andres-favourite-shell}
[07:24] <jbailey> I'll mop it up after.
[07:25] <jbailey> Zzzz...
[07:26] <dilinger> good night
[07:40] <fabbione> (new playground.. kill the abi number from the branch name)
[09:38] <fabbione> hey chmj 
[09:45] <chmj> hye 
[09:47] <fabbione> chmj: i have started swithing the external-driver to passed.kwatch
[09:47] <fabbione> and cleaned up the overall
[09:47] <fabbione> if you want to checkout the playground as in topic :)
[09:48] <fabbione> it would be nice if you could finish the conversion from external-drivers to passed.kwatch
[09:55] <chmj> ok 
[09:55] <chmj> have just been fiddling with sf.net urls 
[09:55] <chmj> becouse of the way they use mirrors 
[09:56] <fabbione> chmj: ok there is a way to access always the same as reference.. i just can't remember how
[10:00] <chmj> fabbione: is there? 
[10:00] <fabbione> chmj: ?
[10:01] <fabbione> chmj: is there what?
[10:04] <chmj> I mean, a way to access specific files 
[10:05] <chmj> without using the mirrors 
[10:05] <fabbione> chmj: you can just use always the same mirror
[10:05] <fabbione> that should be safe enough
[10:06] <chmj> thats what i'm trying 
[01:11] <zul> hey
[01:12] <fabbione> hey zul
[01:12] <zul> how goes it?
[01:12] <fabbione> it's going good
[01:12] <fabbione> working on .12
[01:13] <zul> i noticed
[01:13] <fabbione> i think this will be one of the fastest kernel release we will ever make :)
[01:13] <fabbione> there is not a single patch that doesn't apply
[01:13] <zul> i did some work on lnsm this weekend
[01:13] <fabbione> and guess what?
[01:13] <zul> nifty
[01:13] <fabbione> NO ABI CHANGE!
[01:13] <zul> wohoo!
[01:13] <fabbione> MUHA MUHA
[01:13] <fabbione> but i am still updating the external drivers
[01:13] <fabbione> so that might take more time
[01:13] <zul> heh
[01:14] <zul> i did some work on non-supported-modules this weekend...almost had it working
[01:14] <fabbione> ah neat
[01:18] <doko> fabbione: misdn update?
[01:18] <fabbione> doko: there is no misdn in the kernel :)
[01:18] <fabbione> i will look at it after i get .12 final out of the door
[01:19] <doko> " but i am still updating the external drivers"
[01:19] <doko> fabbione: thanks
[01:19] <fabbione> doko: misdn is not even there
[01:19] <fabbione> doko: so it's not question of updating.. but adding ;)
[01:19] <thom> fabbione: make ipw2100 work ;-)
[01:19] <zul> its in restircticed-modules isnt it?
[01:19] <fabbione> thom: did you test what i asked you?
[01:19] <fabbione> zul: not all of it
[01:19] <thom> no, couldn't get it to build
[01:20] <fabbione> uh?
[01:20] <zul> fabbione: http://zulinux.homelinux.net/lnsm-rules
[01:21] <zul> its just me testing kind of
[01:21] <fabbione> ok :)
[01:22] <fabbione> you scared me for a second :)
[01:22] <zul> any comments though
[01:22] <fabbione> i will need to look at it in details..
[01:22] <fabbione> and test it..
[01:22] <zul> sure
[01:22] <fabbione> why don't you put in baz?
[01:22] <zul> its doesnt work yet though
[01:22] <fabbione> so i can check the branch...
[01:23] <zul> i was going to get it to partially work today then put it in baz
[01:32] <jbailey> karlheg: My x-chat is full anyway, freenode won't let me join more channels.
[01:32] <jbailey> Module arguments, good.
[01:32] <jbailey> It's one of the things I hadn't thought through yet.
[01:33] <karlheg> It's fairly easy to do.  Instead of a 'for x in ...' it does 'cat file | while read mod args'
[01:33] <karlheg> I'll send you the patch.
[01:33] <karlheg> (give me a few minutes)
[01:34] <karlheg> It's not tested; I've not ever tried to run it, but it's pasted with small edits from a script I know is working.
[01:34] <jbailey> Cool.
[01:34] <jbailey> Do you have any questions about the hook scripts?
[01:35] <karlheg> In mkinitramfs, I'm thinking of .'ing in the 'functions' script, then calling 'run_scripts /etc/mkinitramfs/mkinitramfs-hooks' just before the call to cpio.  what do you think?
[01:35] <karlheg> I've added 'local-bottom' and 'nfs-bottom' directories to the 'dirs' file also.
[01:36] <jbailey> If you do that, you should do both /etc/mkinitramfs/mkinitramfs-hooks and /usr/share/initramfs-tools/hooks
[01:36] <jbailey> Packagies needing to do things should probably drop things into /usr/share rather than /etc...
[01:37] <jbailey> I guess the package can decide if it's something the user ought to edit or not....
[01:37] <jbailey> THe trick to remember is that almost all decisions should be deferred until runtime.
[01:38] <karlheg> Ah, right, so packages can drop in non-conffile ones.
[01:39] <jbailey> So I'm reluctant to encourage people to write build-time hooks mostly because I'm moving towards the ability to have one initramfs do *everything* needed to boot.
[01:39] <jbailey> I know it's not completely realistic. but I'd rather people think more in terms of "my module might be always included, and that's a good thing"
[01:40] <jbailey> And then provide a way for that to be included or not and have those decisions deferred to boottime.
[01:40] <Mithrandir> jbailey: problem with "this does everything" solutions is that the space covered by "everything" is ever-growing.
[01:40] <jbailey> Mithrandir: Right, that's why I want to the bootloader to eventually be able to assembly the modules dynamically.
[01:40] <jbailey> So then the decision to include or remove functionality is left as late as possible and allows for a potentially more recoverable system.
[01:41] <Mithrandir> jbailey: yeah, and as we discussed in .au, that should be an easy fix for grub.
[01:41] <karlheg> Software Suspend 2 needs the userui binaries installed in the initramfs, and also needs a hook to run before any file systems are mounted.
[01:41] <Mithrandir> jbailey: lilo is probably a lost cause, since it doesn't understand file systems.
[01:42] <jbailey> Right.  So in this case what I'd like to see is suspend2 providing a .cpio.gz file that gets dropped into some useful location that mkinitramfs will (right now) just assemble into the initramfs.
[01:42] <jbailey> karlheg: Are you aware of how the cpio unpack magic works in the kernel?
[01:42] <karlheg> So the /etc/mkinitramfs/hooks/ is needed for that.  At hibernate time, it needs it in PATH, at resume, in the initramfs or initrd.
[01:43] <karlheg> I think it can unpack a series of cpio, each successive one potentially overwriting the one before it?
[01:43] <jbailey> Right
[01:43] <jbailey> And you can just cat the .cpio.gz files together to assemble them.
[01:43] <karlheg> The hook script will copy the needed binary to the TMPDIR, I thought.
[01:44] <jbailey> So I'd rather that the package just provide the cpio.gz file all bundled together already.
[01:44] <jbailey> Then the decisions can be made at boot time.
[01:44] <karlheg> Ah.
[01:45] <karlheg> ? At boot time?  How does that work?  Wouldn't the decision about what cpio are in the initrd loaded by the bootloader be made at kernel-install time or at mkinitramfs time?
[01:46] <Mithrandir> karlheg: if the boot loader did concatenate the cpio files, there wouldn't be a need for mkinitramfs.  It would happen when you booted.
[01:46] <jbailey> Right now, in the legacy case, mkinitramfs has to cat the modules together.
[01:47] <jbailey> But I don't want any logic around it - I'd really like it to be "You have this package installed, so we include it"
[01:50] <karlheg> Patch is in the mail.
[01:52] <karlheg> I just don't like the idea of having to install both a cpio.gz and the binary itself, when all that's needed in the initramfs is the binary and a very short script.
[01:52] <karlheg> That script would go in /etc/mkinitramfs/local-top or local-premount.
[01:52] <jbailey> karlheg: We'll probably be doing it for a bunch of other things.
[01:54] <karlheg> usplash
[01:57] <karlheg> The hook script approach allows custom logic behind what gets put into the initramfs.  The cpio.gz does not... the hooks are run via 'run_scripts', and are dependancy ordered.  How would you determine the order of catenation of cpio.gz, in case one is meant to shadow another?
[01:58] <karlheg> Perhaps that catenation should be managed by hook scripts, perhaps using a 'functions' API to simplify the client code?
[01:58] <jbailey> That would work.
[01:58] <jbailey> I haven't thought that through beyond my dream that mkinitramfs eventually goes away.
[01:59] <karlheg> catenate_cpiogz /path/to/my/cpio.gz
[01:59] <karlheg> ... with the depends stuff above it, and maybe some custom logic too.
[02:00] <karlheg> how will that work?  The bootloader is already an OS...
[02:01] <fabbione> jbailey: i think waldi gave me the solution for the kernel problem on new glibc
[02:01] <fabbione> testing now the linking crap
[02:02] <jbailey> fabbione: Do tell?
[02:02] <karlheg> The catenation can be done that way, via a function, and before the TMPDIR cpio is created.  The function will create a temporary cpio.gz, and after the main one is made, will catenate that onto the end.
[02:02] <karlheg> Then the hooks are there for either method, and don't have to be segregated into pre-cpio, post-cpio.
[02:02] <karlheg> ?
[02:03] <karlheg> If that is acceptable, I will implement it if you like.
[02:05] <karlheg> Coffee beckons...  I shall return \aprox 20 min.
[02:09] <jbailey> Sometime you'll have to explain to me why you're up at 5 am. =)
[02:42] <jbailey> karlheg: +++ scripts/functions 
[02:42] <jbailey> @@ -1,3 +1,5 @@
[02:42] <jbailey> +# -*- shell-script -*-
[02:42] <jbailey> Is that emacs-fu?
[02:42] <Mithrandir> jbailey: yes
[02:43] <jbailey> 'k
[02:43] <Mithrandir> it means shell-script-mode will be active for that file.
[02:43] <jbailey> Cool.  Been awhile since I used emacs. =)
[02:43] <Mithrandir> similary, you can have # -*- shell-script; coding: utf-8 -*- to force it to be treated as utf8.  vim has about the same thing, iirc.
[02:43] <jbailey> I tend to disable all that crap for vim - it tends to guess things poorly for me.
[02:44] <Mithrandir> which is why you can set it explicitly in the file.
[02:45] <jbailey> *shrug* apathy.  But if it's useful for him, I'll include it in the patch.
[02:58] <zul> fabbione: ping
[03:00] <fabbione> zul: pong
[03:01] <zul> did you put the .12 on your webpace?
[03:01] <fabbione> zul: only the orig
[03:01] <zul> ok..
[03:01] <zul> can you put up the rest? :)
[03:02] <fabbione> done
[03:02] <fabbione> usual rule apply.. get the baz archive after
[03:02] <zul> thanks
[03:02] <karlheg> I've got an Ubuntu linux-source-2.6.12 patched up with Software Suspend 2, 1Gb-lowmem, and madwifi.  It builds; I have not booted it.
[03:03] <karlheg> Q: Why one monolithic patch for Ubuntu linux-source, rather than split patches like the Debian kernel?  (and I wonder how they maintain that.)
[03:04] <fabbione> A: read the sourse Luke.
[03:04] <fabbione> all the patches are there ... one by one
[03:04] <fabbione> you want apt-get source linux-source-2.6.12
[03:05] <fabbione> not apt-get install linux-source-2.6.12
[03:05] <karlheg> sure, but in one patch file, rather than split out.  I just wonder whether you find that eaier to maintain, or what?  I've little experience with that kind of work, at this point.
[03:05] <fabbione> karlheg: the patches are all separated.
[03:05] <fabbione> karlheg: you are mixing 3 different packages
[03:05] <fabbione> the source
[03:05] <fabbione> the install linux-source-2.6.12
[03:05] <fabbione> and the linux-ubuntu-patch-2.6.12
[03:06] <fabbione> you want the source
[03:06] <karlheg> Ah.  Let me try that.  Perhaps it would have been less work to do the patch-up I did yesterday to add Suspend2.
[03:06] <fabbione> apt-get source linux-source-2.6.12
[03:06] <zul> uh...ok...suspend2
[03:06] <fabbione> we won't include it anyway
[03:06] <karlheg> What tools do you use to maintain a kernel source package with associated patches?
[03:07] <zul> vim mostly..:)
[03:07] <karlheg> I know; I think it should be the one used.
[03:07] <fabbione> karlheg: apt-get build-dep linux-source-2.6.12
[03:07] <karlheg> I like it a lot better than the default.  Have you tried it?
[03:07] <karlheg> (recently, with userui?)
[03:07] <karlheg> Ok...  I'm running 'apt-src install linux-source-2.6.12' right now.
[03:08] <fabbione> no
[03:08] <fabbione> apt-get source linux-source-2.6.12
[03:10] <karlheg> I like apt-src better.  Have you tried it?
[03:12] <fabbione> no..
[03:12] <fabbione> i usually edit stuff directly in the .diff.gz
[03:12] <fabbione> i rarely need to get the unpacked source
[03:12] <thom> fabbione: why does 2.6.10-34.2 not have any of the abi stuff and why isn't it in arch? :P
[03:12] <fabbione> thom: it's in arch
[03:12] <fabbione> and the abi is named with the previous version
[03:13] <fabbione> thom: you just baz mv that dir to the version
[03:13] <zul> *sigh* guinea pig is making a mess
[03:13] <thom> fabbione: 34.1 is in arch, i can't see 34.2
[03:13] <fabbione> thom: just baz mv 34.1 to 24.2
[03:13] <fabbione> meh
[03:13] <fabbione> 34.2
[03:13] <karlheg> fabbione, wow, and with 'echo' and 'cat', right?  You would never use 'ed' or any of those other sissy tools.
[03:14] <fabbione> the abi files for 34.2 are generated at build time. since there was no abi change, you can safely copy the old ones
[03:14] <thom> fabbione: dude. there's  kernel-debian--mainline-2,6,10-34,1--0/  ; no 34,2
[03:14] <fabbione> karlheg: sed is my friend
[03:14] <thom> this is what i mean
[03:14] <fabbione> ops
[03:14] <karlheg> (reads fast, doesn't need 'more')
[03:14] <fabbione> thom: i think i might have forgot to tag it?
[03:14] <thom> tsk tsk
[03:15] <fabbione> thom: gimme a sec...
[03:16] <fabbione> thom: did you get the last mail from pitti?
[03:17] <karlheg> Anyone ever thought of trying to load a software speech synth in the initramfs or initrd... will that work with 'speakup'?  I wonder how feasable that is.
[03:17] <jbailey> karlheg: Easy.  Add an audio module to the initramfs, and a binary to do the console to speech work.
[03:18] <jbailey> karlheg: I don't see that as any more annoying, really, than the fact that usb keyboards aren't built in.
[03:18] <jbailey> (And I suspect that frame buffers will eventually go into the initramfs too)
[03:18] <thom> fabbione: todays one? yes
[03:18] <fabbione> thom: ok
[03:18] <zul> inotify updated
[03:19] <jbailey> zul: You just like pain, don't you?
[03:19] <zul> i live in ottawa dont i? :)
[03:19] <jbailey> Right.
[03:19] <jbailey> Are you coming to gcc summit?
[03:19] <karlheg> There seems to be some relatively new code concerning support for usb-legacy mode?
[03:19] <fabbione> zul: slow down boy... i am working on updating drivers too
[03:19] <jbailey> I've just finalised my ride up there tomorrow and back on Saturday.\
[03:19] <karlheg> Does that give Linux usb-legacy via BIOS or something?
[03:19] <zul> jbailey: i wish..dont have the money
[03:19] <fabbione> zul: please keep working on the l-n-s :)
[03:19] <zul> meh..
[03:20] <zul> :)
[03:20] <jbailey> karlheg: Dunno.  I install the drivers, and I hope it works. =)
[03:20] <fabbione> zuk: i will merge the inotify but i need to do some other stuff before that
[03:20] <karlheg> I'd rather use HID of course...  I did not look at it long; still reading prereq to really comprehend it.
[03:20] <fabbione> s/zuk/zul
[03:20] <zul> uh someone changed external-drivers on me
[03:20] <fabbione> zul: no shit.. i told you i was updating everything
[03:20] <fabbione> zul: external-drivers is dieing
[03:21] <fabbione> read the changelog
[03:21] <zul> :P
[03:21] <fabbione> we are switching to passed.kwatch that will take a more decent named after we finish the conversion
[03:21] <zul> k cool
[03:22] <fabbione> i also have some changes pending here that i can't commit until concordia is up and running again. they need to be test-builded
[03:22] <fabbione> so leave the drivers alone until i am back in 2 hours :)
[03:22] <zul> noooooo..:)
[03:23] <zul> jbailey: but we will have to have lunch when you come up
[03:24] <jbailey> Cool. =)
[03:27] <fabbione> thom: almost done... baz is on slow crack today
[03:29] <fabbione> thom: kernel-team@ubuntu.com--2005/kernel-debian--pre34,3--2.6.10 <- all the abi/changelog/00list files work is done. you only need to add the patches, build, test and upload.
[03:29] <fabbione> i need to run
[03:29] <fabbione> bbl
[03:30] <thom> fabbione: ah, rock. thanks
[03:51] <zul> ewww...thats a big lass http://www.thepowerteam.com/roster/jclark.htm
[03:56] <thom> zul: i don't even want to know how you found that
[03:56] <zul> it was on tv
[03:57] <karlheg> Where can I read brief wrt 'abi' ?
[03:58] <karlheg> My guess is it has to do with glibc builds and sys_* ?
[03:58] <jbailey> Wha?
[03:58] <jbailey> karlheg: Which abi are you refering to?
[03:58] <zul> karlheg: uh not exactly..
[04:00] <zul> *sigh* stop upload gcc...its hurts :)
[04:00] <jbailey> this sentence no verb.
[04:00] <jbailey> try again?
[04:00] <zul> man...i need breakfast...bbl
[04:00] <zul> that would do nicely
[04:00] <karlheg> :-)  I'm looking at the kernel source debian/abi and rules.
[04:00] <karlheg> 'read' <-- verb.
[04:00] <jbailey> zul: I think it's interesting that we tend on a legalisation side of downers: codeine, alcohol, marijuana.
[04:01] <jbailey> zul: But the only upper we allow is caffeine.
[04:01] <zul> i havent had any caffine in like a week
[04:01] <jbailey> Nice!
[04:01] <zul> not really..
[04:01] <jbailey> I haven't had any in a decade and don't miss it now.
[04:01] <jbailey> The first two weeks were hell, though.
[04:02] <zul> its not by choice ;)
[04:02] <zul> my wife is evil
[04:04] <zul> i dont think she loves me sometime ;)
[04:05] <jbailey> My wife passed by, read over my own shoulder and commented that it's probably for your own good.
[04:05] <jbailey> (She has a coffee in her hands)
[04:05] <zul> :P
[04:07] <jbailey> karlheg: So do you stay up all day too? =)
[04:10] <karlheg> Sure.  Or else I won't sleep all night again.
[04:10] <karlheg> My clock is off from weekend all-nighters.
[04:10] <jbailey> Ah.  I was thinking that perhaps you were an overnight sysadmin at the school.
[04:11] <karlheg> No.  Just a wanna-bee programmer...  It's the beginning of summer break, and I've finally got enough free time to get after some things I had no time for during school term.
[04:13] <karlheg> I have more projects than I can finish over the summer...  and a pile of books I need to read.  I wanted a new kernel, to try latest Suspend2 and started working on that.  I learned about initramfs when I tried fbsplash, along with the fbsplash support in Suspend2 and it's fb userui.
[04:13] <jbailey> Right, I understand.
[04:13] <jbailey> I can't remember the last time I had fewer projects than spare time. =)
[04:14] <karlheg> I wonder how you folks go about creating and maintaining all of those dpatch files?  Do you work with multiple kernel source directories, or what?  Is there a writeup?
[04:14] <karlheg> I'll look in dpatch doc...
[04:15] <jbailey> g'm Andres. =)
[04:16] <zul> karlheg: there is a README.NMU in the debian directory start there
[04:18] <karlheg> Check (done)
[04:18] <zul> and then look at an example dpatch
[04:20] <dilinger> jbailey: 'morning
[04:21] <lamont> mooorning
[04:22] <jbailey> Heya LaMont!
[04:22] <zul> hey lamont 
[04:27] <zul> hmmm...reports of 2.6.12 haning on udev
[04:30] <jbailey> Eh?
[04:30] <jbailey> udev is just an app, how would it hang?
[04:32] <zul> http://lkml.org/lkml/2005/6/18/19
[04:33] <jbailey> Dear user, learn to use strace, figure out what's hanging.  udev has no magic in it.  kthxbye.
[04:34] <zul> heh
[04:34] <zul> or http://lkml.org/lkml/2005/6/18/41
[05:50] <zul> fabbione: the baz stuff is in my arch
[05:50] <zul> er...the non-supported modules stuff
[05:52] <fabbione> zul: ok
[05:52] <fabbione> jbailey: apparently 2.6.12 final needs a version of udev that's not even in sid.
[06:44] <fabbione> zul: out of curiosity... before updating inotify.. did you actually check the there are already 3 versions more out?
[06:44] <zul> yeah...i got -10
[06:44] <fabbione> and there is -13 out :)
[06:44] <zul> bugger
[06:44] <fabbione> ahhaha
[06:45] <fabbione> ok don't worry... keep working on the lnsm stuff
[06:45] <fabbione> i will take care of the drivers :)
[06:46] <fabbione> (also because i want to try to avoid to bump the abi this time ;))
[06:46] <thom> fabbione: can you quickly verify something for me; i don't think can-2005-1764 is applicable to hoary; changeset is here: http://tinyurl.com/aq3zr
[06:47] <fabbione> thom: checking
[06:49] <zul> fabbione: i have a lnsm-install-686 i was wondering how to create a deb out of it
[06:49] <fabbione> zul: hint: instead of doing the work in debian/build...
[06:49] <fabbione> add the linux-n-s-m in debian/control
[06:49] <fabbione> meh right
[06:49] <zul> cp the files to the linux-n-s-m
[06:49] <fabbione> nevermind
[06:50] <fabbione> dpkg-deb is what you need but there is more that needs to be done there
[06:50] <zul> you need to remove the drivers from linux-image as well though
[06:51] <fabbione> exactly..
[06:51] <zul> bag
[06:51] <fabbione> that's why i need to look at it in details
[06:51] <zul> bah..even
[06:51] <fabbione> thom: it looks to me that hoary is not affected.
[06:51] <fabbione> thom: apparetntly somebody did a mistake across the development
[06:52] <fabbione> thom: and reverted adding a - 4096 instead of the value of TASK_SIZE we have in hoary
[06:52] <fabbione> probably the one in git is more readable..
[06:52] <thom> yeah
[06:52] <thom> thanks for the confirm, i'm leaving well alone then :-)
[06:53] <fabbione> thom: i think that's the same bug Herbert says it doesn't apply in warty
[06:53] <thom> fabbione: it is, yes
[06:53] <fabbione> thom: but i am pretty sure i did forward the mail to you
[06:53] <fabbione> perfect
[06:55] <thom> thanks dude
[06:59] <zul> meh...another one today
[07:06] <fabbione> interview?
[07:07] <zul> yeah PHP developer
[07:07] <dilinger> my condolences
[07:07] <zul> thanks...they think my starting pay is high...well see...
[07:08] <fabbione> Dear PHP Developer, die. kthxbye
[07:09] <zul> hey!
[07:09] <dilinger> Dear PHP Developer, please fork php and make it not suck.   Thank you.  Sincerely, Everyone Who's 
[07:09] <dilinger> Ever Dealt With PHP
[07:09] <fabbione> haha
[07:18] <Mithrandir> dilinger: a) kill it off b) kill all the developers who've ever touched it.
[07:19] <dilinger> Mithrandir: c'mon, there are plenty of developers that touched it that didn't  mean to.  they were drunk.  or young and naive, and stupid.  or both.
[07:19] <Mithrandir> dilinger: ok, excuse those, but kill the rest.
[07:20] <dilinger> good plan
[07:20] <Mithrandir> dilinger: and I did (at first) intend to just kill those who've touched php's code, not php code.
[07:25] <zul> dilinger: *ahem* im none of the above
[09:11] <karlheg> zul, have you ever used or looked over HTML::Mason ?
[09:11] <karlheg> (OT)
[09:50] <karlheg> jbailey, I've got only a little more to go on that, and I'll send you another patch.  Have you made changes today?
[09:50] <karlheg> If not, I'll just send a replacement diff.
[09:51] <karlheg> ... for your review and approval.
[09:51] <jbailey> I have not, I just got back from a meeting that I've been at for the last 3.5 hours
[09:52] <karlheg> Question: When the run_init is called, the /dev filesystem is mounted in /, right?  And run_init nukes the ramfs /, then chroot chdir / into the new rootfs... but where is /dev now?
[09:53] <jbailey> /dev isn't mounted, it's just a directory.
[09:53] <jbailey> Since / is a tmpfs, there's no need for a seaparate /dev
[09:53] <karlheg> I'm confused about the semantics of the MS_MOVE mount, I guess.
[09:53] <jbailey> MS_MOVE literally moves the mount of the /root filesystem on top of /
[09:53] <karlheg> So the run_init will remove the /dev directory and contents?
[09:53] <jbailey> Right.
[09:54] <karlheg> How can it do that if anything has a device open?
[09:54] <jbailey> There's nothing left on the / filesystem at that point.
[09:54] <jbailey> Nothing is holding the inode in /deb open at that point.  It's all in-kernel
[09:54] <jbailey> So the kernel doesn't care if I remove the deivce node, it's got everything it needs.
[09:55] <karlheg> But there may be running processes that have devices open... ?  Hmmm... I supposed that something like usplash can simply close the fb before the run_init.
[09:55] <jbailey> Right.  Haven't got as far as usplash yet.  It would probably have to do something like that, though.
[09:55] <karlheg> Ah, the refcount goes down, it's still there, but invisible?  But won't it keep the file system busy?
[09:55] <karlheg> "standing on it"?
[09:55] <jbailey> Nope, the kernel doesn't go through the filesystem to talk to its own devices - that would be inefficient.
[09:56] <karlheg> "literally moves" means what?  cp -a ?
[09:56] <karlheg> I think I'll have to UTSL to "get" this one.
[09:57] <jbailey> Umm, how to describe.
[09:57] <jbailey> The effect of the MS_MOVE is that the filesystem is now as if it were mounted on / instead.
[09:58] <jbailey> Apparently overmounting like this makes it so that kernel threads that do rely on the filesystem don't have to have crazy magic applied to them.
[09:58] <karlheg> Uhh... so if anything has /dev/console open on it's stdin / stdout, the device inode has a refcount.  Even if you rm the device file, it's still "there", I think.
[09:58] <jbailey> It depends.  For userspace applications, yes.
[09:59] <jbailey> If something inside the kernel is using the device, it's no big dealk.
[09:59] <karlheg> Oh!  That's what it is when I see that /dev/root stuff and there's two mounts shown for / in /proc/mounts?  So that /dev can just stay there until it's closed?  But what about freeing the ramfs... I guess when it's empty, it's free anyhow.
[09:59] <jbailey> So for right now, no process is accessing those devices, so we can delete them and their refcount is zero.
[09:59] <jbailey> Right.  The kernel will reduce the memory used for the ramfs with no penalty.
[10:00] <jbailey> But ideally nothing should keep a ref open to something in /dev.  The FB and /dev/console are the two things I can think of, and hopefully those can be released for long enough to fire up run-init, and start their stuff once udev is running on the other side of init.
[10:00] <karlheg> Perhaps /dev should be a mount point and move mounted into the real root under a different name, say, "/tmp/initramfs-dev",, and then a later-in-the-boot sequence script can clean it up when all procesess that had devices there open are done.
[10:01] <jbailey> That's a possibility that hasn't been necessary so far.
[10:01] <karlheg> Any new opens will happen in /dev, which is shadowed by udev's ramfs anyhow...
[10:02] <karlheg> Perhaps the 'refcount' I'm thinking of does not really happen with device inodes?  I'd better look at the kernel source and learn how that works.
[10:05] <karlheg> If the move mount of /dev happened, it would anyway get shadowed by udev just as the hard-drive /dev does, I think.  Perhaps the devices open from inside initramfs /dev can be shadowed in a similar way...
[10:07] <karlheg> They can remain open, but are no longer visible to 'ls'.  The leakage of resources is probably very minor, like a few pages of virtual memory at most, and the physical pages would get reclaimed soon enough anyhow?  or a struct for that ramfs that never can go away, or can it?  What happens to it when we MS_MOVE mount on top of it?
[10:52] <zul> heylo
[10:54] <zul> whoa...one of my patches made it into 2.6.12