Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-releng
Navigation:
Lists: gentoo-releng: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-releng@g.o
From: John Davis <zhen@g.o>
Subject: Meeting summary
Date: Mon, 08 Dec 2003 23:36:12 -0500
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all:
A summary of the topics discussed as the meeting is as follows (also see
the attached meeting log):

1. All livecd scripts are to be integrated into catalyst. *Please check
your code into cvs (gentoo/src) ASAP so that we can audit it and get to
work on adding it into catalyst*. As soon as all code is in CVS, we will
start on creating a unified livecd script. Livewire and pvdabeel, you
will be in charge of this initiative.

2. genkernel and catalyst are going to be integrated into one tool.
brad_mssw, please check your code into CVS so that we can start the same
process on it as we are going to do on livecds. You had mentioned
testing your genkernel code before integration. Make it so - please get
a hold of the arch leads ASAP and get your code to them.

If you have any questions on how to integrate your code into catalyst,
please contact either drobbins or myself.

What I would like to see with catalyst soon:
- -Roadmap - we need to know the future of catalyst. Daniel - perhaps we
can sit down and hash this out?

Release ETAs:
- -DEC 31 IS THE FINAL DUE DATE. After this date, catalyst will be frozen,
whether or not your code is ready. When 2004.0 is released, it will be
built with catalyst (livecds and stages) as voted upon by the managers,
and we *need* to release a stable version of catalyst (in portage) along
with 2004.0. 2004.0 will not release until we do so.

- -I would like to see all livecd and genkernel code in CVS by Friday,
December 12th. The sooner we get it in, the sooner we can start coding
it into catalyst.

I will follow up with more mail as more subjects arise. Thanks for your
patience and hard work :)

Cheers,
//zhen
- --
John Davis
Gentoo Linux Developer
<http://dev.gentoo.org/~zhen>

- ----
Knowledge can be more terrible than ignorance if you're powerless to
change your world.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/1VE8ZlASNRlGLUcRAqzLAJ4zlh21+6iO2Sr+7VoNUepX/HQUbQCffgGZ
v6xbgujqWo9zIfB9SzGcgtE=
=v5Zk
-----END PGP SIGNATURE-----
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

--
gentoo-releng@g.o mailing list
Replies:
Re: Meeting summary
-- Pieter Van den Abeele
Navigation:
Lists: gentoo-releng: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
test
Next by thread:
Re: Meeting summary
Previous by date:
test
Next by date:
Re: Meeting summary


Updated Jun 17, 2009

Summary: Archive of the gentoo-releng mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.