19:43 <@zhen> ok, first on the list: catalyst
19:44 < drobbins> ok
19:44 <@zhen> drobbins: your floor
19:44 < drobbins> all right
19:44 < drobbins> everyone should be using catalyst
19:44 < drobbins> if you don't have boxes, I can give you remote access to a g4 and/or an amd64
19:44 < drobbins> even if you're not officially building stuff, you should use it just to learn it
19:44 < brad_mssw> catalyst is easy enough ... I use it ... not a problem
19:45 < drobbins> ok
19:45 < drobbins> now next comes the catalyst philosophy
19:45 < drobbins> we need it to be a solid build tool
19:45 < drobbins> that means: no hacks
19:45 < drobbins> anything complicated and weird, we push to the appropriate people (genkernel, initscripts, portage) and get them to make their things catalyst-friendly
19:45 < drobbins> so that's a shift that's new
19:46 < drobbins> we need to distribute the complexity to other people, so they can help us manage it
19:46 < drobbins> so for catalyst/livecd stuff, don't view yourself as the one person who has to hack it all together
19:47 < drobbins> catalyst is now an official part of gentoo and official for livecd building and that means everyone needs to help ensure that catalyst is solid
19:47 < iggy> it builds livecd's now?
19:47 < drobbins> nope
19:47 < brad_mssw> what's the status of livecd in catalyst ? has it been started yet ?
19:47 <@zhen> iggy: not yet
19:47 < drobbins> brad_mssw: hasn't really been started, although much of the work is done
19:47 < pvdabeel> trance will be looking at integrating livecd support (with my help) into catalyst
19:47 < pvdabeel> for ppc :-)
19:47 < drobbins> building a livecd is not more than what catalyst already does
19:48 < drobbins> not much more
19:48 <@zhen> what is the release schedule that we want to give to catalyst? initial release by 2004.1?
19:48 < brad_mssw> I've got a good basis for the new genkernel
19:48 < brad_mssw> which should be nicely cross-platform
19:48 < drobbins> right now catalyst can build up custom stages and build in additional packages
19:48 < drobbins> additional steps for livecd:
19:48 < brad_mssw> for the livecd stuff
19:48 < drobbins> build initrd/kernel
19:48 < drobbins> err let me start over
19:48 < drobbins> 1. clean up livecd environment (minimize size)
19:48 < drobbins> 2. initrd/kernel
19:49 < drobbins> 3. any script tweakings needed (we want to minimize these to near-nil)
19:49 < drobbins> 4. loop/cloop/zisofs-ify the filesystem
19:49 < drobbins> 5. build iso image
19:49 < drobbins> 4.5: add additional stuff to iso tree
19:49 < drobbins> so this is not a biggie
19:49 < drobbins> we just need to get everything working together
19:50 <@zhen> drobbins: LiveWire who is currently working on livecd (besides pvdabeel)?
19:50 <@zhen> erm, trance rather
19:50 < drobbins> um
19:50 < drobbins> ok
19:50 < drobbins> we have livewire working on his livecds
19:50 < drobbins> brad_mssw working on his livecds (amd64)
19:50 < drobbins> pvdabeel working on his livecds (ppc)
19:51 < drobbins> so what we need to do is:
19:51 < drobbins> 1) identify hacks in these scripts
19:51 < drobbins> 2) get fixes in initscripts, etc.
19:51 < drobbins> 3) get things consistent
19:51 < drobbins> then we can get a nice multi-platform approach to livecd bulding
19:51 < LiveWire> brad_mssw is using my hacked 2.6 scripts, so only difference is 2.4 > 2.6 and ppc
19:51 < drobbins> I have already pushed a bunch of initscript fixes to baselayout
19:52 < drobbins> you just need to add CDBOOT=1 to /etc/rc.conf
19:52 <@zhen> drobbins: are those changes in stable yet?
19:52 < brad_mssw> yeah, the livecd scripts are a mess right now
19:52 < LiveWire> If baselayout gets fixed, the catalyst stuff wont be a problem
19:52 < drobbins> we also need to get bootsplash as an option, an option that is *independent* of the initscripts
19:52 < drobbins> ie we don't want to add lots of garbage to /etc/init.d/ to get that to work.
19:52 < brad_mssw> I've got my own set of hacks I'm currently using
19:52 < drobbins> LiveWire: I already have everything except bootsplash in baselayout
19:52 < drobbins> LiveWire: just add CDBOOT=1 to /etc/rc.conf
19:53 < pvdabeel> hm, bootsplash on 2.6 is somewhat more architecture independent than on 2.4 it now works on ppc too
19:53 < drobbins> LiveWire: and any additional fixes can continue to be pushed into future baselayouts
19:53 < drobbins> LiveWire: this means that we should always only have a minimal set of tweaks to /etc/init.d....
19:53 < pvdabeel> would be nice to be the first ones with a bootsplash on ppc
19:53 < drobbins> LiveWire: and we should be pushing our fixes into baselayout regularly to keep it that way
19:53 < brad_mssw> pvdabeel: bootsplash works on ppc with what? 2.6 ?
19:53 < pvdabeel> yep
19:53 < drobbins> pvdabeel: bootsplash is probably best as a separate option handled by genkernel
19:54 < brad_mssw> pvdabeel: cool, I just asked and DarkSpecter in #gentoo-ppc said it did not work
19:54 < drobbins> pvdabeel: we need to define the interface from catalyst <-> genkernel, what data needs to be passed
19:54 <@zhen> keeping focus here, what are the essentials to getting livecds working, and what is the progress on getting those essentials working/fixed?
19:54 < drobbins> then I can add this data to the spec file for catalyst
19:54 < drobbins> 1. catalyst <-> genkernel interface defined
19:54 < pvdabeel> brad_mssw: actually it does, but probably alpha quality
19:54 < pvdabeel> brad_mssw: I opened a bug on it a while ago
19:55 < brad_mssw> pvdabeel: cool...
19:55 < drobbins> 2. adding a mature livecd target to catalyst (not hard once we iron out genkernel stuff)
19:55 < drobbins> 3. test, tweak, etc.
19:55 < drobbins> the first goal should be a bootable livecd that does not use bootsplash
19:55 < drobbins> build with catalyst
19:55 < pvdabeel> indeed
19:55 < drobbins> I need to go now I think :/
19:55 <@zhen> drobbins: ok - thanks, say hi to the daughter
19:55 < brad_mssw> drobbins: bootsplash kernel-level is trivial ... so on genkernel's end, it fully supports it
19:56 < brad_mssw> btw, I committed my genkernel rewrite to cvs
19:56 < drobbins> brad_mssw: It gets tricky when we need to tweak /etc/init.d to support it
19:56 < drobbins> brad_mssw: kernel is easy
19:56 <@zhen> brad_mssw: good :)
19:56 < brad_mssw> gentoo/src/genkernel_bradmssw
19:56 < drobbins> brad_mssw: initscript side, it can be messy if we just hack it in (which we can't do anymore)
19:56 < brad_mssw> drobbins: right, the /etc/init.d is the hard stuff
19:56 < drobbins> ok, gotta run
19:56 <@zhen> drobbins: lata
19:56 < brad_mssw> drobbins: k, take it easy
19:56 <@zhen> ok, I'm going to take back the floor for a moment
19:56 < drobbins> brad_mssw: azarah pointed to an external tool for doing bootsplash stuff
19:56 < drobbins> brad_mssw: I recommend looking at that
19:56 < drobbins> ok, bye
19:56 < pvdabeel> bye
19:57 <@zhen> livecd people (which seems to be everyone); have any of you worked together on the current livecd script (hack) in the catalyst tree?
19:57 < brad_mssw> anyhow, I need people to start looking at adding in the required files for each arch to my genkernel rewrite
19:57 < brad_mssw> it should be trivial
19:57 <@zhen> brad_mssw: we'll get there :)
19:58 < brad_mssw> just need to make sure people don't come up with any gotchas before I hit the cleanup and finish mode
19:58 < brad_mssw> as that would be a real PITA
19:58 <@zhen> before we get to genkernel though, we need to finialize a plan for livecds
19:58 < brad_mssw> ok, on the livecd side
19:59 < brad_mssw> looks like we have to use gcloop ?
19:59 <@zhen> I for one want to see a catalyst release for 2004.1/2, since by then we *should* be using it to build our release stages and livecds
19:59 < brad_mssw> since zisofs doesn't seem to work on all arches
19:59 < brad_mssw> why doesn't zisofs work on all arches though?
19:59 < LiveWire> does gcloop work for 2.6 yet?
19:59 <@zhen> brad_mssw: does it support 2.6 now? (gcloop)
19:59 < pvdabeel> somewhat
19:59 < drobbins> zhen: it is on the roadmap for 2004.0
19:59 < brad_mssw> LiveWire: yes, in lu_zero's home directory
19:59 < drobbins> zhen: that is not negotiable
19:59 < pvdabeel> but my personal opinion is that it is very alpha
19:59 < seemant> zhen: catalyst release in what sense?
19:59 < pvdabeel> *very*
19:59 <@zhen> drobbins: cool.
19:59 < pvdabeel> at least on ppc
20:00 <@zhen> seemant: stable ebuild
20:00 < brad_mssw> http://dev.gentoo.org/~lu_zero/gcloop/
20:00 < LiveWire> lu_zero was having problems with it
20:00 < seemant> zhen: gotcha
20:00 < seemant> zhen: if we generate 2004.0 or 2004.1 release with it, then catalyst itself should get released simultaneously, I should think
20:00 < pvdabeel> I take it catalyst supports having a different strategy on different archs to roll the final iso, and to initialize its bootloader
20:00 <@zhen> livecd folks, can you coordinate a time to get together and hack this out, then get back to the rest of us via the (hopefully setup) gentoo-releng ml?
20:00 < seemant> besides which, as I've already experienced, it's a nice qa tool too
20:00 < pvdabeel> is the current system generic enough for all alternative platforms
20:00 <@zhen> seemant: exactly :)
20:01 < pvdabeel> for instance ppc uses yaboot, with a hfs formatted iso, but x86 uses something else
20:01 < drobbins> maybe this would be a good time for brad to talk about his genkernel
20:01 <@zhen> as in, can we see a viable example in the next 2 weeks or sooner?
20:02 < drobbins> we all need to be testing brad's genkernel
20:02 <@zhen> drobbins: I would really like to flatten livecds first, just so we are all on the same page
20:02 < drobbins> flatten = ?
20:03 < LiveWire> so for catalyst we should be able to build the livecd chroot the same on all arches, then have a ARCH specific module for the cloop/zisofs/iso creation
20:03 <@zhen> drobbins: the issue, not the procedure, sorry
20:04 < drobbins> the issues are all genkernel related I think
20:04 < drobbins> that people are talking about
20:04 < drobbins> ?
20:04 < brad_mssw> err, if all arches can support the same method, wouldn't it be better to stick to one of (cloop/zisofs)
20:05 <@zhen> drobbins: ok brad_mssw take it away
20:05 < brad_mssw> drobbins: no, the cloop/zisofs is outside the scope of genkernel obviously, which seems to be the stickler
20:05 < drobbins> LiveWire: genkernel needs to handle gcloop/zisofs since it involves different kernel configs as well as possibly modules on the initrd
20:05 < drobbins> brad_mssw: but it's not
20:05 < drobbins> it's important to understand the interaction
20:05 < brad_mssw> err, right, if I have to handle a module for gcloop I need to know
20:05 < drobbins> genkernel needs to provide a kernel, initrd, and possibly userland tools for the cloop
20:05 < brad_mssw> but zisofs is in the mainline kernel already, so there's nothing there for zisofs
20:05 < brad_mssw> but I'd need to know what hooks are needed for gcloop from me in genkernel
20:06 < drobbins> they can't be handled as independent modules on the catalyst side, since catalyst requires the cooperation of genkernel (for cloop.o on the initrd, etc.)
20:06 < LiveWire> you going to do the iso building in genkernel also? each has a totally different setup
20:06 < brad_mssw> drobbins: right ... like I said, I need to have the hooks defined that people need from genkernel
20:06 < drobbins> brad_mssw: we need to find some very clear, clean way of telling genkernel what compression technologies to enable, and what modules to build, and a clean way of getting userland utils out of genkernel if needed (like create_compressed_fs)
20:06 < LiveWire> i agree that it would be better to use one thing (like gcloop).. but that doesnt seem possible right now
20:07 < brad_mssw> I really have no idea how gcloop works
20:07 < brad_mssw> do they have 2 packages ??
20:07 < drobbins> brad_mssw: do you know how cloop works?
20:07 < brad_mssw> like one kernel module package, and one userland package ?
20:07 < pvdabeel> I think design wise we have to make sure genkernel doesn't become a bottleneck:
20:07 < brad_mssw> pvdabeel: agreed ...
20:08 < drobbins> it's hard for me to architect anything since I didn't have access to genkernel's source
20:08 < pvdabeel> if a new architecture wants support, it should merely add and register a new module
20:08 < drobbins> now that it's online, I can take a look and see
20:08 < brad_mssw> pvdabeel: to genkernel you mean?
20:08 < drobbins> pvdabeel: it's very tempting to pull genkernel in its entirety into catalyst and make them the same thing
20:08 < brad_mssw> pvdabeel: or in general to catalyst ?
20:08 <@zhen> brad_mssw: what is the difficulty w/ genkernel and the compression packages? (gcloop,etc)
20:08 < pvdabeel> brad_mssw: an example:
20:08 < drobbins> pvdabeel: since we need genkernel to be very functional
20:08 <@zhen> drobbins: is there any reason that we couldn't
20:09 < brad_mssw> drobbins: the only thing about that is that many users are using genkernel for building system kernels ... so it really is seperate
20:09 < pvdabeel> genkernel provides some generic function calls like create_compressed_fs
20:09 < brad_mssw> zhen: uhh, nothing is really difficult there ... i just need to know what responsibility it needs to cover
20:09 < pvdabeel> if genkernel uses the ppc module, it can't build zisofs compressed fs
20:09 < brad_mssw> zhen: for instance if genkernel needs to build the kernel module and the userland utils, then pass the userland stuff back to catalyst somehow
20:09 < brad_mssw> zhen: or if each component is responsible for its own
20:10 < brad_mssw> pvdabeel: err, no genkernel doesn't do any create_compressed_fs
20:10 < pvdabeel> nevermind then
20:10 < pvdabeel> I'm probably confused
20:10 <@zhen> brad_mssw: assuming genkernel and catalyst stay separate, wouldn't it be easier to have genkernel do just kernel and have catalyst take care of the userland via cdimage stage building?
20:10 < brad_mssw> pvdabeel: all genkernel will do is build the kernel module and tell the linuxrc to load it inside the initrd
20:11 < pvdabeel> ok
20:11 <@zhen> brad_mssw: that sounds fine to me
20:11 < brad_mssw> zhen: yes, exactly, but drobbins suggested at one point that genkernel might have to build the userland too to ensure that versions were always the same
20:11 < brad_mssw> zhen: like I said, I have no idea how gcloop works at this point though ... so I can't validate or invalidate that
20:12 <@zhen> brad_mssw: if that is true, what about having catalyst read the genkernel config if it is building cdimages?
20:12 <@zhen> we can keep the separation, but we can lock versions
20:12 < pvdabeel> brad_mssw: so genkernel defines knowledge on how to build a kernel for a given architecture. Is it possible for a new architecture to add extra knowledge about how to build a kernel on their arch?
20:13 < pvdabeel> brad_mssw: without starting hacking in the genkernel code
20:13 < brad_mssw> zhen: yep, that could work, or simply pass the package that it needs to use to genkernel, and genkernel will extract the module source and compile it
20:13 <@zhen> brad_mssw: what do you mean by pass it?
20:13 < brad_mssw> pvdabeel: yep, it's totally seperated ;)
20:13 < pvdabeel> brad_mssw: ok :-)
20:13 < brad_mssw> pvdabeel: unless you need something really wacky ;)
20:13 < brad_mssw> pvdabeel: in which case, tell me, and I'll figure out a graceful way to do it
20:14 < brad_mssw> zhen: --gcloop-source=/catalyst/gcloop-module-source.tar.gz
20:14 < pvdabeel> there is one wacky example I can come up with
20:14 <@zhen> brad_mssw: ah, ok
20:14 < drobbins> ok
20:14 < drobbins> the connection is: (chiming in quickly here) that genkernel needs a cloop.o
20:15 < pvdabeel> on ppc, bzImage doesn't work, vmlinux is needed, but on ibm rs6000 vmlinux.prep is needed instead
20:15 < drobbins> but at the same time, it can also build the tool used to compress the cloop
20:15 < drobbins> which could be used later by catalyst (and probably should be)
20:15 < brad_mssw> pvdabeel: yep, that's supported changing that, look in the config.sh for each arch
20:15 <@zhen> brad_mssw: pvdabeel would it help to combine genkernel and catalyst? or should we leave it as is?
20:15 < drobbins> or one pkg
20:16 < pvdabeel> I have no real preference
20:16 < drobbins> with /usr/bin/genkernel and /usr/bin/catalst
20:16 < brad_mssw> pvdabeel: http://www.gentoo.org/cgi-bin/viewcvs.cgi/*checkout*/src/genkernel_bradmssw/x86_64/config.sh?rev=1.1&cvsroot=gentoo&content-type=text/plain
20:16 <@zhen> that would work
20:16 < pvdabeel> brad_mssw: k
20:16 <@zhen> drobbins: what benefit would we get from the combination into one pkg?
20:17 < brad_mssw> zhen: I wouldn't combine them into one package, since genkernel is used outside of catalyst
20:17 < drobbins> zhen: they could eventually use the same config, and be more integrated, or be used separately
20:17 < brad_mssw> zhen: for standard users
20:17 < brad_mssw> zhen: plus, it's totally written in shell, where catalyst is python afaik
20:17 < drobbins> zhen: there's no reason not to combine them
20:18 <@zhen> brad_mssw: catalyst is bash and py
20:18 < brad_mssw> zhen: ok ... didn't know it had any bash portions ... didn't really look at it
20:19 <@zhen> what extentions to catalyst would be beneficial enough to the end user for us to include it w/ genkernel?
20:20 < drobbins> we already have a class-based system for defining arch capabilities in catalyst
20:20 < drobbins> it would allow catalyst and genkernel to both access this information
20:20 < drobbins> could be trivially extended to define what arches support cloop, etc.
20:21 < drobbins> and we have a plugin arch that could be trivially extended to support cloop, gcloop plugins
20:21 <@zhen> brad_mssw: what do you think?
20:21 < drobbins> it seems to match the level of complexity we'll be needing from genkernel
20:22 < brad_mssw> unfortunately, genkernel pretty much requires arch-specific directories to hold stuff like default kernel configs, etc, otherwise it gets real messy ... catalyst defines all the arch-specific stuff in one place ... really doesn't afford you too much
20:22 < brad_mssw> plus they're all python files, and I have no clue about python
20:22 <@zhen> brad_mssw: what about /var/tmp/catalyst/builds/kernel-ppc-1.4 or something like that
20:22 <@zhen> iirc, that is how we manage it now
20:22 < drobbins> brad_mssw: catalyst uses stages taht are external files
20:23 <@zhen> brad_mssw: and on py, not necessarily, driver scripts, the workhorse scripts, are bash
20:23 <@zhen> plugins if you will
20:24 < brad_mssw> uhh, the builds/whatever are generated ... I'm talking about default configs that would be distributed
20:24 <@zhen> the individual .configs?
20:24 < brad_mssw> genkernel is really meant to be something where you can build a default kernel on any arch without the user having to know anything about that arch
20:25 < brad_mssw> right, but that's not all ...
20:25 < brad_mssw> just the /builds dir isn't a valid place
20:25 < brad_mssw> but I just don't see what trying to integrate into catalyst will afford you
20:25 < brad_mssw> since at most you're talking about eliminating 1 file
20:25 < brad_mssw> then adding more complexity to a package like catalyst
20:25 < drobbins> it's about eliminating a complex interface
20:25 < drobbins> brad_mssw: it's not a big deal for catalyst
20:25 < brad_mssw> so if someone externally wants to hack it, it could be a pita ...
20:26 < brad_mssw> drobbins: err, you're talking about totally integrating the genkernel functionality ?
20:26 < drobbins> brad_mssw: I'm talking about having them share code
20:26 < brad_mssw> drobbins: so someone would type catalyst genkernel --opt1 --opt2 etc?
20:26 < drobbins> brad_mssw: no, there could still be a /usr/bin/genkernel
20:26 < brad_mssw> drobbins: ok, then I'm confused
20:27 < drobbins> brad_mssw: it could hook in to the catalyst code/plugins/object model though.
20:27 <@zhen> drobbins: why? we could just make --kernel a target and be done with it
20:27 < drobbins> either
20:28 <@zhen> idea - if we do integrate the two tools, at some point, catalyst could be used as an automated way to build/ install a system
20:28 < pvdabeel> hm, I'll have to leave in about 5 minutes
20:28 < drobbins> yep
20:28 < drobbins> shoudln't be too hard and benefits could be huge
20:29 < pvdabeel> indeed
20:29 < brad_mssw> I don't really agree, since building livecd's I believe is a small portion of the use of genkernel
20:29 <@zhen> download gpg signed up to date portage snap, catalyst -f stage3-install; catalyst -f kernel-install
20:29 < brad_mssw> a lot of people seem to be interesting in using genkernel for building any kernel for their system ..
20:29 <@zhen> brad_mssw: how would that functionality be lost w/ catalyst?
20:30 < brad_mssw> zhen: wouldn't be ...
20:30 < brad_mssw> zhen: just adds the complexity, and possibly confusing end-users
20:31 <@zhen> I think that it would alleviate confusion actually, especially if we use the spec file functionality to get users to build kernels
20:31 < brad_mssw> 'spec file functionality' ??
20:31 <@zhen> yeah, catalyst supports spec files (think per-arch/profile/etc configs)
20:31 <@zhen> so if I want a default gentoo kernel
20:32 <@zhen> I could just do ./catalyst -f /etc/catalyst/kernels/gentoo-2.4.20-r8.spec
20:32 <@zhen> and it would enter the genkernel build routine for that kernel
20:32 < pvdabeel> the spec file functionality is something I have been thinking about for portage-ng too
20:32 <@zhen> if I want a custom kernel, I just do a ./catalyst -genkernel -config or something
20:32 < brad_mssw> zhen: so each kernel would distribute a .spec file for each architecture ?
20:33 < pvdabeel> would allow one to make 'specifications' or requirements about the system one is building
20:33 < drobbins> pvdabeel: yep, could grow into a replacement for profiles' make.defaults
20:33 < pvdabeel> but more about that later
20:33 < pvdabeel> I'll have to leave now
20:33 < pvdabeel> bye
20:33 <@zhen> brad_mssw: each kernel package? no, we would, much like genkernel distributes its kernel-config now
20:33 <@zhen> pvdabeel: lata
20:33 <@zhen> personally, I think that we could benefit from combining the two
20:34 < brad_mssw> zhen: then why did you get so specific on gentoo-2.4.20-r8.spec ?
20:34 < brad_mssw> that's what just confused me there ..
20:34 <@zhen> ah, ok
20:34 <@zhen> well, looking at it from that angle, sure, each package could have a spec file if need be
20:34 <@zhen> or we can give a generic spec file to put in /etc/catalyst/kernel
20:35 <@zhen> really, it is flexible enough to go either way
20:35 < brad_mssw> ok ...
20:36 <@zhen> I for one would like to see this happen, what about everyone else?
20:37 <@zhen> drobbins: if you are still around
20:37 < brad_mssw> dunno, more concerned with just getting genkernel working properly for multiple arches at this point
20:37 < brad_mssw> since I really don't know anything about the layout of catalyst
20:37 < brad_mssw> someone else might have to do that integration
20:37 < brad_mssw> I split everything out into nice easy functions and multiple files, etc
20:37 <@zhen> brad_mssw: i wouldn't mind working on it with you
20:37 <@zhen> brad_mssw: no problem
20:38 <@zhen> i just want to get a working product, and most importantly, unified development
20:38 < brad_mssw> yep
20:39 <@zhen> ok, since everyone had to take off, I will make a summary of this and mail it to everyone
20:39 < brad_mssw> like I said though, it's probably better initially getting genkernel working on other arches before it gets integrated, just think it would be easier for now
20:39 <@zhen> brad_mssw: whatever you need to do
20:39 < brad_mssw> plus I have some other stuff that still needs to get done in it
20:40 <@zhen> brad_mssw: eta?
20:40 < brad_mssw> zhen: well, it's usable now ...
20:40 < brad_mssw> zhen: the other stuff is niceties
20:40 < brad_mssw> zhen: no real eta until I hear back from other arches
20:40 < brad_mssw> zhen: to make sure I don't need to change any core logic
20:41 <@zhen> brad_mssw: who are you waiting on?
20:41 < brad_mssw> zhen: no one in particular ... just need ppc, alpha, sparc, etc people to test it out
20:41 <@zhen> hmm, ok
20:41 < brad_mssw> zhen: haven't contacted anyone yet though
20:41 <@zhen> brad_mssw: when is the soonest that we can start that testing?
20:42 < brad_mssw> zhen: those arches can start testing now ...
20:42 < drobbins> back
20:42 < brad_mssw> zhen: they just have to provide a config.sh appropriate for their platform, and a kernel-config for their platform
20:42 <@zhen> brad_mssw: make it so then, and please keep me updated on the progress. as soon as I get the date for 2004.0, things will start to happen quickly
20:42 <@zhen> drobbins: what is the date for 2004.0?
20:43 < drobbins> January
20:43 < drobbins> zhen: http://www.gentoo.org/proj/en/releng/
20:43 < drobbins> there's info there
20:43 <@zhen> cool
20:43 <@zhen> drobbins: we decided to unify genkernel and catalyst
20:43 < drobbins> catalyst is required for buliding of all stages, grp and livecds. that was approved by managers
20:43 < drobbins> ok
20:43 < drobbins> will look into it in the next couple of days...
20:44 <@zhen> cool, brad is going to contact arch leads to get his genkernel code tested
20:44 < drobbins> ok
20:44 < brad_mssw> who are the arch leads?
20:44 * zhen will mail a summary of all this to everyone
20:44 < brad_mssw> is it documented somewhere ?
20:44 <@zhen> seemant: do you know?
20:45 < drobbins> it may only be documented on the developer list atm
20:45 < drobbins> which is on the site
20:45 < drobbins> brad_mssw: for release, key arches are x86, ppc, amd64 and sparc
20:46 < drobbins> brad_mssw: for 2004(.0)
20:46 < brad_mssw> ok, pvdabeel is ppc
20:46 < drobbins> the others aren't release-ready afaik
20:46 <@zhen> sparc is weeve?
20:46 <@zhen> i think anyway
20:46 < drobbins> brad_mssw: I also have a g4 here, send me your dsa key as an attachment via email if you want access
20:46 < drobbins> yep
20:46 < drobbins> will have an Ultra 10 set up any day now
20:46 < drobbins> like in the next week
20:47 < brad_mssw> drobbins: err, hard to test a kernel remotely ;)
20:47 < drobbins> you can test buliding
20:47 < brad_mssw> drobbins: yeah, but I'm not worried about building, that's a no-brainer ;)
20:47 < drobbins> brad_mssw: you can build, I can test booting it
20:48 < brad_mssw> drobbins: yes, but let me contact the appropriate arches and find out the info first, so I don't keep doing trial and error on stuff they already know
20:48 <@zhen> LiveWire: pvdabeel can you two get together and get your code into catalyst tree for livecds?
20:48 < drobbins> zhen: even better
20:48 < drobbins> pvdabeel: LiveWire: commit your lastest code to cvs
20:49 < drobbins> then we can pull from it as needed
20:49 < drobbins> also, we need to know where brad's code is on cvs if it wasn't yet mentioned
20:49 <@zhen> drobbins: gentoo/src/brad_genkernel or something like that
20:49 <@zhen> drobbins: sounds good to me
20:49 < brad_mssw> gentoo/src/genkernel_bradmssw
20:50 < drobbins> k
20:50 < brad_mssw> http://www.gentoo.org/cgi-bin/viewcvs.cgi/src/genkernel_bradmssw/?cvsroot=gentoo#dirlist
20:51 <@zhen> ok, i think that we are done here - thanks all for coming :)
20:51 <@zhen> expect mail shortly
20:53 < drobbins> thanks for organizing it
20:54 < LiveWire> sorry guys, had a important business call come in
20:54 <@zhen> zhen: np
20:54 <@zhen> LiveWire: np, i will mail a summary
|
