path: root/installer/meeting-logs/2004/20040912_log.txt

18:22:45<         esammer@> the reason for this meeting is to discuss current status, releng integration efforts, live cd requirements, and a release date
18:23:14! samyron [scott@uc-bloom-184-200.dmisinetworks.net] has joined #gentoo-installer
18:23:20<        agaffney > there's one
18:23:35<         esammer@> samyron: we're starting now
18:23:38<            zhen > i have to be out by 3:30, so if we could do the releng stuff relatively soon, that would be great
18:23:43<         samyron > esammer: sorry, lost track of time!
18:23:48<         esammer@> samyron: no problem
18:23:55<         esammer@> ok, let's start with releng
18:24:17<         esammer@> so, zhen and beejay have been lurking around offering help from releng
18:24:18<         samyron > k]
18:24:26<            zhen > yup
18:24:58<         esammer@> the idea is that we should coordinate for the purposes of releases and live cd work.
18:24:59<            zhen > esammer: would you like me to talk about the integration efforts and livecd requirements?
18:25:08<         esammer@> zhen: that would be great, yea.
18:25:11<         codeman > is dialog on the livecd?
18:25:20<            zhen > codeman: yes, it should be
18:25:31<            zhen > codeman: and if it is not, we can always add it
18:25:32<         codeman > k.  i know python is as well
18:25:41<         esammer@> zhen: also, if you could let us know what releng is aiming for (your perspective) that would be great too.
18:25:52<            zhen > python is not on the livecd and we would like to keep it that way for size constraints
18:25:58<            zhen > esammer: sure
18:26:13<         codeman > i've run python from the universal livecds b4
18:26:20<         samyron > yeah, python is on 2002.4
18:26:22<         samyron > er
18:26:23<         samyron > 2004.2
18:26:30<            zhen > integration of the installer project should not be difficult
18:26:48<         esammer@> ok. zhen has the floor, so let's save questions for the end.
18:26:52<            zhen > if it is packaged up as an ebuild, we should have no problem sticking it on the livecd
18:27:30<            zhen > we can provide an X LiveCD, standard CLI livecd, and anything else that you need
18:28:24<            zhen > so to sum it up, releng is flexible to do whatever the installer project requires of us
18:29:01<            zhen > questions?
18:29:41<         samyron > zhen: where do you want the installer to start and where would you like it to end.. meaning.. you boot off of the cd.. what "step" should it start at... and what "step" should it end at?
18:29:44<         esammer@> ok. sounds good. so, live cd requirements are obviously an issue. the only problem i foresee is being able to run teh installer prior to unpacking hte stage.
18:30:17<         esammer@> (the python issue, i mean)
18:30:36<            zhen > samyron: up to you folks. depending on how we package our cds, execution time would change
18:30:39<            zhen > s/change
18:30:44<         samyron > k
18:31:01<         codeman > how would you have space for X on a liveCD?
18:31:01<            zhen > samyron: for example, the minimal cd should probably go to a prompt first because experienced users might pick that one for its small size
18:31:19<         samyron > sounds good to me
18:31:23<            zhen > and a universal cd would probably have it start automactically
18:31:52<         klieber > we also need to support both guided and automatic installations from the liveCD.  We can't just assume everyone wants a guided install
18:32:10<            zhen > klieber: yup
18:32:20<         samyron > klieber: already thought of that
18:32:26<         klieber > samyron: great
18:32:29<         samyron > klieber: that's pretty much already built into the backend
18:32:41<            zhen > codeman: we can do kde on the cd in 240 MB :)
18:32:49<            zhen > and that is w/o our space reductions we are undertaking right now
18:32:52<         klieber > samyron: true -- I'm just saying the front-end needs to provide a method for selecting which install to use.
18:33:00<         samyron > ah, ok
18:33:02<         klieber > including the universal CD
18:33:12<         samyron > simple enough:-)
18:33:16<         klieber > graet
18:33:20<         klieber > great, even.
18:34:18! hadfield [~hadfield@S0106002018892b9c.vc.shawcable.net] has quit [Remote closed the connection]
18:34:39<            zhen > any other questions?
18:34:48<         codeman > how far along would we have to be before converting this project to an ebuild?
18:34:52<         esammer@> ok, so we need to figure out exactly when and how the installer should be run from teh live cds. the only other thing is that we need to figure out the requirements in terms of libraries and utilities that need to be available for the installer.
18:35:13! hadfield [~hadfield@S0106002018892b9c.vc.shawcable.net] has joined #gentoo-installer
18:35:17<         samyron > i propose we do it the 'slackware' way
18:35:19<         esammer@> we don't have to figure out these things now, but at least we have a point of contact and communication open
18:35:25<            zhen > yup :)
18:35:28<         samyron > kick them to a prompt and in the motd, we say "Type 'setup' to run the installer."
18:35:49<         esammer@> samyron: right. our options are open.
18:35:50<         variant > I think just typeing "installer" at any point should launch the isntaller
18:36:06* samyron likes that idea
18:36:11<         samyron > cause then we can have cmd line options
18:36:18<         variant > allso a boot prompt for "command line install" or "automated installer"
18:36:21<       spyderous > that doesn't really work for an automated one, though. maybe it should check for existence of some kickstart-like file
18:36:22<         codeman > setup/installer/install all should run the installer
18:36:25<         samyron > installer --config /etc/gliconfig.xml --profile /etc/myprofile.xml
18:36:34<         klieber > spyderous: yeah, good idea.
18:36:38<         samyron > very good idea
18:36:39<         samyron > then
18:36:45<         esammer@> spyderous: we may need a special live cd for automated installs
18:36:46<         samyron > we have to *standardize* on a filename/location
18:37:00<         esammer@> spyderous: something that probes for files or network locations or whatever
18:37:06<          Method > keep the entrypoint high :) can't boot right into the installer or anything like that
18:37:07<            zhen > the installer should check for the presence of a usb key or something to grab the config from
18:37:11<            zhen > or floppy
18:37:32<       spyderous > the very first thing on it should ask whether you wanna load a kickstart from somewhere
18:37:41<         klieber > (including network)
18:37:58<         samyron > klieber: already done:-)
18:37:58<          Method > erm
18:38:01<         klieber > although....actually, coudln't that be part of the install?
18:38:06<          Method > isn't that the only place you can load a kickstart from?
18:38:10<         klieber > wait...nm
18:38:24<         klieber > Method: no -- you can store it locally on the install media
18:38:31<          Method > oh right
18:38:35<          Method > at which point it shouldn't even ask
18:38:37<          Method > it should just do it
18:38:43<         samyron > while i was testing some stuff.. i was having it pull the profile from "https://...../config.xml"
18:38:55<         klieber > cool
18:39:00<         samyron > and it was working well
18:39:05<            zhen > sweet
18:39:13<         klieber > we could also control some of this via kernel boot params, no?
18:39:20<         samyron > http(s)|rsync|file are all supported
18:39:25<         samyron > klieber: good idea
18:39:27<         klieber > red hat uses that to control init levels, fedx
18:39:31<         klieber > fex, even...
18:39:43<          Method > samyron: no tftp? gah, dark ages
18:39:43<         esammer@> klieber: i was thinking the same
18:39:53<         samyron > er, ftp too
18:39:54<         samyron > sorry
18:39:55<         codeman > like boot:  gentoo automatic-install?
18:39:56<         samyron > forgot about that one
18:40:13<         klieber > codeman: that, plus location of the file
18:40:24<         esammer@> Method: there will be PXE / netboot at some later date which should work with tftp
18:40:40<            zhen > esammer: has any of your team looked into the knoppix-like installation method of dumping the livecd contents to the HD?
18:40:48<         codeman > at that point you haven't mounted any devices or network or anything.. there'd be no way to verify the file's existance.
18:40:57<         esammer@> zhen: we haven't but that is probably a good idea
18:41:21<            zhen > zhen: that would be a nice and easy feature to implement early 2005
18:41:27<            zhen > er, esammer rather
18:41:42<         esammer@> zhen: yep
18:42:21<         esammer@> ok. is there anything else regarding releng / live cd?
18:42:32<            zhen > not from my end
18:42:36<         codeman > what about parted?
18:42:48* codeman has not checked
18:42:56<            zhen > what about it?
18:43:12<         codeman > we use pyparted i think for partitioning stuff at the moment
18:43:36<         esammer@> codeman: this has been discussed to some degree. parted doesn't work for all archs. it's a bit of a contraversial issue. :)
18:44:08<         codeman > ah. ok.
18:44:23<         esammer@> we can talk about that outside of this meeting
18:44:43<         esammer@> codeman: but it is a valid concern
18:44:49<         esammer@> anything else folks?
18:44:59<         klieber > a date?
18:45:00<         codeman > are we going to need a separate release for each arch?
18:45:03<         klieber > for the release?
18:45:51<         esammer@> codeman: hopefully not.
18:45:51! cokehabit_ [George@dsl-80-43-81-29.access.uk.tiscali.com] has joined #gentoo-installer
18:45:56<      cokehabit_ > sorry im late
18:45:56<         esammer@> ok - release date.
18:46:21<         esammer@> so zhen - when does 2005.0 go "gold?"
18:46:24<            zhen > well
18:46:28<            zhen > not sure yet, 2005 is not planned
18:46:33<            zhen > we have some other stuff to sort out
18:46:43<         esammer@> zhen: oh. what release were we aiming for?
18:47:10<            zhen > esammer: anything 2005
18:47:17<            zhen > after 2004.3 we will plan out 2005
18:47:22<         klieber > can we just set an internal date for Dec 31st?
18:47:25<            zhen > we might be changing up release cycles
18:47:28<         klieber > or is that too agressive?
18:48:00<         codeman > i'd say Dec 31st for a non-partitioning release?
18:48:01<         esammer@> well, let's do this - let's talk about status and how far we are from our goals. that should dictate release date and what's feasible.
18:48:13<         samyron > esammer: good idea
18:48:39<         klieber > can we talk about the partitioning?  'cause I think that's going to affect the rest of the decision making process.
18:49:14<           tseng@> also, does the current code exclude adding lvm, raid or whatever
18:49:25<         esammer@> ok, but quickly as partitioning can turn into an all day discussion if we're not careful.
18:49:25<           tseng@> at a later date.
18:49:42<         esammer@> tseng: no. it should be possible to add support for it.
18:49:52<           tseng@> wonderful.
18:49:53<         klieber > esammer: specifically, I'd like to suggest that, if we can get an arch-specific installer out sooner, then we should
18:49:59<        agaffney > was npmccallum's detect_devices.py script ever to the point where it would detect *everything*?
18:50:21<         esammer@> agaffney: i honestly don't recall. i have the feeling that the answer is no.
18:50:32<         klieber > i.e. if the hold-up on the partitioning stuff is non-x86 arches, then we should slip that feature to something post 1.0
18:50:47<        agaffney > looking at the code, it appears it still only detects ide/scsi (and scsi emulating) devices
18:51:22<         esammer@> klieber: the hold up is non-x86 archs, or more specifically, that it's difficult to handle them all in a generic way.
18:51:41<         klieber > esammer: then I'd push for making 1.0 x86-specific
18:51:53<         codeman > there's a lot more besides detecting the devices.  that code works pretty well afaik.
18:52:02! seemant [~trinity@seemant.developer.gentoo] has joined #gentoo-installer
18:52:03<         samyron > the good news is that x86 and amd64 = almost identical :-)
18:52:06<         esammer@> so here are our choices - have an x86 specific installer OR leave out partitioning and have multiple archs
18:52:15<         klieber > can we do both?
18:52:24<         samyron > i'm confident that we can
18:52:27<         klieber > if x86, do partitioning, else fail to manual?
18:52:42! brad[] [~brad@209.161.229.122] has joined #gentoo-installer
18:52:52<         samyron > i was thinking about, for the time being, handling partitioning in a 'hack' way
18:52:53! cokehabit_ is now known as cokehabit
18:52:55<         samyron > just dump them to cfdisk
18:53:00<         samyron > cfdisk = pretty easy to use
18:53:12<           tseng@> id love that
18:53:18<         esammer@> cfdisk does not work on all archs either
18:53:19<         codeman > but then you run into the issue of your automatic install all of a sudden sitting at a prompt
18:53:28<         samyron > esammer: but it works beautifully on x86
18:53:29<        agaffney > samyron: what about non-CLI installers?
18:54:04<         klieber > let's not get too mired in the details. Are we comfortable with an x86-specific installer for 1.0?  (with an option of failing to manual partitioning for non-x86?)
18:54:04<         samyron > agaffney: for the time being, i'm not worried about those as much, there is still a lot left to do on the backend side.. and i know that i don't have any time to spend writing anything not CLI.. unless you want too :-)
18:54:10<         esammer@> klieber: the problem is after manual, how to get them back to where they left off
18:54:31<         klieber > esammer: ok, if that's a problem, then I'd say ignore it.  x86 only, period.
18:54:31<         samyron > esammer: easy
18:54:36<         klieber > at least until 1.5/2.0
18:55:00<         codeman > esammer: we have run_bash for that.
18:55:03<         samyron > esammer: the installer has a 'spawn_bash()' function.. which will dump the user to a bash shell
18:55:09<         codeman > s/run/spawn
18:55:11<         samyron > when he/she types 'exit' the installer picks up where it was before
18:55:20<         esammer@> ok. good.
18:55:41<         klieber > so, are we OK with that model?
18:55:57<         esammer@> so that's it - if x86, we'll partition automatically if we can, otherwise to a bash prompt they go
18:56:04<         klieber > yay
18:56:17<         codeman > sounds good
18:57:17<         variant > what other architectures does parted support (if any)?
18:57:18<         klieber > so, that brings us back to the discussion about dates
18:57:31<         klieber > variant: I assume it supports amd64
18:57:31<         esammer@> klieber: no. please, status first.
18:57:35! cokehabit [George@dsl-80-43-81-29.access.uk.tiscali.com] has left #gentoo-installer ["Leaving"]
18:57:38<         klieber > esammer: sorry, that's what I meant.
18:58:31<         esammer@> ok. i'm going to turn this over to samyron and codeman as they've been working on the majority of the core code these days. scott - can you talk about the current status of the code and what's left / unstable?
18:58:34! brad[] [~brad@209.161.229.122] has quit [Remote closed the connection]
18:58:34<         codeman > well using my hacked scripts i was able to setup this laptop with only 3 breaks where i had to drop to bash to fix something.
18:59:03<         codeman > samyron can start w/ the config/controller
18:59:18* esammer kicks samyron's chair
18:59:59<         samyron > ok
19:00:08<         samyron > *clears throat*
19:00:10! brad[] [~brad@209.161.229.122] has joined #gentoo-installer
19:00:36<         samyron > the client configuration is what 'configs' the client controller
19:00:51<         samyron > the client controller is going to provide all of the API to talk to the frontend (which we NEED to talk about)
19:02:10<         codeman > the client controller basically sets up the network, and all of the stuff that doesn't actually effect the new environment
19:02:22<         samyron > so far, the controller does the following things: sets up the ftp,http&rsync proxy, loads kernel modules, sets the root password, sets up the networking, and enables ssh(if the user wants), and downloads/cp's the install profile that the user wants
19:02:44<         samyron > (sorry for that delay, I had to look at the src to remember everything it does :-))
19:03:03<         samyron > i've done some pretty simple testing, and it seems to be pretty stable thus far
19:03:24<         codeman > then the FE would execute the start function in the controller, which would call the appropriate arch-template
19:03:56<         samyron > what's currently not done: the arch templates
19:03:59<         codeman > and the install would always no matter what be automated from that point on (am i correct in this samyron?)
19:04:17<         samyron > i'm still not 100% comfortable with how they're being implemented(even though it was my design)
19:04:21<         samyron > something just doesn't feel right yet
19:04:30<         samyron > codeman: correct
19:04:34<         samyron > basically
19:04:43<         samyron > once the backend starts, it's all automated
19:04:56<         samyron > the user has no more intervention, UNLESS, the installer runs 'spawn_bash' for some reason
19:05:11<         samyron > which might happen, due to unimplemented parts of the install, but this is to be avoided AT ALL COSTS
19:05:52<         samyron > *thinks*
19:05:55<         samyron > any questions?
19:06:06<        agaffney > can the client controller part be bypassed?
19:06:21<        agaffney > for example, if the user is installing in a chroot from within another install?
19:06:38<         samyron > agaffney: not at the moment, but this can be added
19:06:39<        agaffney > in that case, you wouldn't want the installer to set up networking, load kernel modules, etc.
19:06:44<         samyron > agaffney: rather simply
19:06:48! spyderous_ [~spyderous@spyderous.developer.gentoo] has joined #gentoo-installer
19:06:49! spyderous [~spyderous@spyderous.developer.gentoo] has quit [Read error: 104 (Connection reset by peer)]
19:07:00<        agaffney > samyron: just wanted to throw that out there
19:07:08! spyderous_ is now known as spyderous
19:07:18<         samyron > agaffney: k, good idea, esp for testing
19:08:04<         codeman > yup
19:08:26<         samyron > any other questions?
19:09:00<         esammer@> samyron: so teh problem is that we need to review the arch template stuff?
19:09:15<         samyron > yeah.. right now i'm doing something *kinda* hacked
19:09:21<         samyron > like
19:09:24<         codeman > samyron: anything specific you don't like?
19:09:24<         samyron > i have a generic template class
19:09:40<         samyron > and this provides all methods that aren't arch specific
19:10:05<         samyron > then, each arch template will be a subclass of this class and define all arch specific methods
19:10:08<        agaffney > something like Portage's cascaded profiles?
19:10:08<         samyron > (like partitioning)
19:10:21<         samyron > agaffney: i have no clue about portage's cascaded profiles :-)
19:10:29<         samyron > now... this solutions works
19:10:32<         samyron > and i think it'll work great
19:10:39<         samyron > does it 'feel' right to you guys?
19:10:42<         samyron > if so, i'll stick w/ it
19:10:57<         codeman > hrm
19:11:10<         esammer@> samyron: so the short answer is that it doesn't seem to be a natural design and needs to be looked at but it does work.
19:11:12* codeman thinks about how the manual is set up
19:11:25<        agaffney > samyron: it sounds exactly like Portage's cascaded profiles and if the Portage guys do it, it must be good!
19:11:38<         samyron > esammer: yeah...
19:11:45<         samyron > one thing i thought of doing
19:11:49<         codeman > that structure would be similar to calling an arch template which would grab the generic functions and then do the arch-specific stuff on its own
19:11:50<         samyron > was creating some sort of 'scripting language'
19:11:56<         samyron > but i think that'd be more difficult than what it's worth
19:12:08<           tseng@> ebuilds are scripted
19:12:08<         esammer@> ok. let's not get into specific details now.
19:12:11<           tseng@> its bash..
19:12:15<         samyron > k
19:12:58<         esammer@> samyron: given what we have and the possibility that it might be reworked, how far from a end to end installer do you feel we are?
19:13:13<         samyron > well..
19:13:15<         samyron > minus testing
19:13:23<         samyron > and a notification system
19:13:41<         samyron > we are probably about 70% done
19:13:42<         samyron > meaning
19:13:49<         samyron > w/ some simple scripts, we'd be able to get an install finished
19:13:58<         codeman > the majority of the work still is the FE-BE interfacing and notification stuff.
19:14:14<         esammer@> notifications i can handle in a very short amount of time.
19:14:17<         samyron > k
19:14:21<         samyron > output would also be ugly
19:14:38<         samyron > but i'm not too worried about that
19:14:54<         samyron > we really are close
19:15:08<         esammer@> ok. this all sounds good.
19:15:09<         samyron > and i'm trying my hardest to balance school & work and this installer
19:15:15<         samyron > so i apologize if my work slows
19:15:18<         samyron > but it shouldn't stop
19:15:24<         klieber > would it make sense to have a public beta period, btw?
19:15:26<         esammer@> samyron: that's understandable
19:15:28<         klieber > before we stick this on a livecd?
19:15:33<         esammer@> klieber: yes, i think so
19:15:47<         codeman > so can we increase our status to mega-super-alpha?
19:16:01<         esammer@> codeman: officially, i think so.
19:16:22<         codeman > once we get a scripted complete install i suggest switching to a version # :)
19:16:44<         codeman > with a bunch of 0's
19:16:44<        agaffney > 0.0.1-mega-super-alpha :)
19:16:50<         samyron > lol
19:16:56<         esammer@> ok. so, the question - can we be tested and working for 2005.0?
19:17:06* agaffney doesn't think that would be a valid Portage accepted version number...
19:17:10<         samyron > esammer: i'm pretty confident
19:17:16<         samyron > esammer: it's really coming down to polishing
19:17:21<         esammer@> samyron: i am as well. codeman?
19:17:30<         codeman > we can do it
19:17:39* codeman is optimistic
19:17:40<         esammer@> well, i think that says it.
19:17:42<         samyron > esammer: it's coming down to getting stuff like 'install_cron' put in the arch template
19:17:47<         samyron > esammer: which i'm sure you know takes about 30 seconds
19:17:54<         esammer@> samyron: right.
19:18:04<         codeman > grub is going to be a pain
19:18:12<         codeman > it isn't too multi-arch friendly
19:19:05<         esammer@> well, that's a detail we'll work out
19:19:15<         codeman > i'm just saying it will take time
19:19:26<         klieber > I'd suggest a staged plan of supporting arches, btw.  x86 (and maybe amd64) first, then add 1-2 more next release, 1-2 more after that, etc.
19:19:38<         klieber > also, not being supported will probably motivate some of the arch folks to help out and get their arch supported.
19:19:50<         esammer@> klieber: yes. that is probably a good idea.
19:19:51<         codeman > oo, i like that
19:20:13<         esammer@> some things are easier to handle than others. portage masks a lot of difficulty from us.
19:20:20<         samyron > we're trying to make it as easy as possible for other arch people to help out
19:20:20<         samyron > meaning
19:20:32<       spyderous > we might wanna add ppc after amd64, that'd give us a decent coverage of different arch types
19:20:37<         samyron > all they need to do is fill in a few methods in their arch template
19:20:41<         samyron > and then it'll be done
19:21:11<         esammer@> so, let's wrap it up on that note... unless there's any questions (that are not specific implementation details that don't pertain to everyone)
19:21:40<         klieber > oh, documentation
19:21:49<         klieber > that's going to be a huge part of making this installer a success
19:21:56<         klieber > (telling people how to use it)
19:22:02<         klieber > who's doing it?
19:22:18<         samyron > no one yet
19:22:19<         esammer@> a good question.
19:22:25<         esammer@> a good answer.
19:22:25<         samyron > we're still changing out mind a lot
19:22:33<         samyron > and a lot of things aren't definate
19:22:35<         klieber > samyron: is the XML stuff finalized yet?
19:22:39<        agaffney > are you talking about API documentation or end-user docs?
19:22:45<         klieber > agaffney: primarily end-user docs
19:22:50<         klieber > the API stuff can come later, imo
19:22:53<         samyron > klieber: getting close
19:23:00<         klieber > samyron: ok, that's where we can start I suppose.
19:23:04<         samyron > klieber: k
19:23:19<         samyron > i guess since i know that... since i did it.. i'll write that documentation
19:23:25<         klieber > heh
19:23:33<         samyron > :-)
19:23:59<         esammer@> so, we'll sucker someone to work on end user docs as things solidify
19:24:20<         codeman > there were many volunteers we asked to show up to the meeting
19:24:21<         klieber > I don't want this to end up like webapp-config
19:24:33<         klieber > i.e. great product, but nobody knows how to use it.
19:24:47<           tseng@> klieber, the man page isnt that bad
19:24:54<           tseng@> i figured it out np
19:25:07<         klieber > tseng: the man page didn't exist last I checked, so at least that's an improvement
19:25:12* agaffney is scared of webapp-config
19:25:20<           tseng@> sorry for OT
19:25:22<         esammer@> ok. on topic or we're done.
19:25:29* klieber slaps himself
19:25:31<         esammer@> heh ;)
19:25:38* agaffney sidesteps
19:25:50<         samyron > i'll bbiab.. got to do a few things around here
19:25:54<         klieber > so we're shooting for EOY?
19:26:00<         samyron > klieber: yessir
19:26:02<         esammer@> klieber: yep
19:26:08<           tseng@> exciting.
19:26:09<         klieber > or do we want to shoot for a public beta by the end of november?
19:26:31! samyron is now known as samyron|gone
19:26:54<       spyderous > i've gotta run, unfortunately. enjoy the rest of the meeting.
19:27:07<         esammer@> spyderous: thanks for coming
19:27:17<       spyderous > it was my pleasure.
19:27:25! spyderous [~spyderous@spyderous.developer.gentoo] has quit ["Client exiting"]
19:27:59<         esammer@> klieber: a public beta would be cool, yea.
19:28:10<         klieber > can we do that by end of november?
19:28:10<         esammer@> we'll have to play it by ear, i think.
19:28:16<         klieber > that's ~3 months
19:28:23<         esammer@> klieber: i think it's possible, yes.
19:28:30<         klieber > cool deal neal
19:29:35<         esammer@> ok folks. thanks for coming. if someone can send a log to the list, i'd appreciate it.