September 12 Meeting log

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