From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp05.gnvlscdb.sys.nuvox.net (smtp.nuvox.net [64.89.70.9]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j4BHXoV2012252 for ; Wed, 11 May 2005 17:33:50 GMT Received: from cgianelloni.nuvox.net (216.215.202.4.nw.nuvox.net [216.215.202.4]) by smtp05.gnvlscdb.sys.nuvox.net (8.12.11/8.12.11) with SMTP id j4BHY7LE020776 for ; Wed, 11 May 2005 13:34:07 -0400 Received: by cgianelloni.nuvox.net (sSMTP sendmail emulation); Wed, 11 May 2005 13:33:40 -0400 Subject: Re: [gentoo-catalyst] Keeping a test environment using catalyst From: Chris Gianelloni To: gentoo-catalyst@lists.gentoo.org In-Reply-To: References: <17024.65176.779934.871798@lemming.engeast.baynetworks.com> <1115755578.27166.9.camel@cgianelloni.nuvox.net> <1115816128.20511.3.camel@cgianelloni.nuvox.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-l9VLJJfOdG5IGh15HErc" Organization: Gentoo Linux Date: Wed, 11 May 2005 13:33:38 -0400 Message-Id: <1115832819.23106.6.camel@cgianelloni.nuvox.net> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-catalyst@gentoo.org Reply-to: gentoo-catalyst@lists.gentoo.org Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 X-Archives-Salt: 61050736-6816-4769-8799-d146f0765ee0 X-Archives-Hash: 08d3c8f885d333e68c1253d5f11a3f27 --=-l9VLJJfOdG5IGh15HErc Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2005-05-11 at 12:39 -0400, Paul Smith wrote: > %% Chris Gianelloni writes: >=20 > cg> We don't do any shortcuts simply because we *are* the catalyst > cg> developers. When we find shortcomings in catalyst, we fix them. ;= ] >=20 > >> If there are no fancy tricks that I'm missing I'm sure I can come up > >> with some myself :-). >=20 > cg> Like I said before, I'm not sure I really follow what you're > cg> trying to do. >=20 > Hi Chris; thanks for taking the time to reply! >=20 > I completely see your viewpoint here. My situation is that I'm trying > to add somewhat more esoteric software to my livecd than comes on a > "typical" livecd. Some of it doesn't even have any Gentoo ebuilds, so > I'm writing them myself. For ebuilds that are in Gentoo, I need to run > emerge -p to see what would be pulled in, investigate the USE flags in > the ebuilds to see if I can turn off features I don't like, then see > what would be pulled in, etc. Also, to find out what I can unmerge and > still have the thing work properly. OK. This makes sense to me now. > In a situation like this it's very time consuming to have to rebuild > livecd1 and then livecd2 every time I need to tweak an ebuild or add or > remove a package, so I was looking for a "development mode" where things > were maybe not as clean, but were "good enough" to allow development > work to proceed quickly. Then obviously there's polishing at the end > that would have to be done more cleanly. Your best bet here is then to chroot into your livecd-stage1 and start playing. Remember that catalyst just uses "emerge" for most of its work, so you can easily duplicate the steps. You might also want to look into the tinderbox target. It will allow you to determine just what is required above and beyond a stage3 tarball to get your packages working. Personally, I prefer the USE=3D"-*" approach, rather than deciding what you don't need, try to figure out what you want. Turn everything off, then only turn on what you really need. > I quite understand your position: you are using ostensibly stable Gentoo > packages and your work is focused on making sure Catalyst works. I'm > using unstable/development packages and assuming that Catalyst is stable. Catalyst is anything but stable. It works quite well for building a *Gentoo* release, but is not well suited for other things (yet) simply due to that being the only focus of catalyst until recently. > Anyway, I think I have enough now to work with for the moment; adding in > libstdc++ works (I did this last night but forgot to send email), and I > can bind-mount the snapshot and chroot and that works as well. Cool. > My current project is understanding where the kernel boot parameters > come from (my bootline has "nodhcp" which I don't want). My other > problem is that the hardware detection stuff is running too late in the > "default" boot process; it brings up eth0, then sshd, then apache, > _THEN_ runs the hardware detection. So, I can't quite figure out how it > brings up eth0 without detecting the hardware... maybe it runs twice? All of the boot parameters come from the archscript. Normally, autoconfig is started first due to it being first alphabetically. The "hwsetup" portion you see on the Gentoo releases is done by autoconfig, and runs before coldplug. Just curious, but what arch are you building? x86? amd64? ppc? --=20 Chris Gianelloni Release Engineering - Strategic Lead/QA Manager Games - Developer Gentoo Linux --=-l9VLJJfOdG5IGh15HErc Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBCgkHykT4lNIS36YERArD+AKC2L/KqvkHTH1qg7VUTz9JBD/m3ggCdFFGV kDTZ2Pswq4EuNekVtbOTgwM= =AGnK -----END PGP SIGNATURE----- --=-l9VLJJfOdG5IGh15HErc-- -- gentoo-catalyst@gentoo.org mailing list