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.