| 1 |
On Fri, 2005-09-23 at 13:01 +0200, Georg Lippold wrote: |
| 2 |
> Hi Chris, |
| 3 |
> |
| 4 |
> thanks for your comments. |
| 5 |
> |
| 6 |
> Chris Gianelloni wrote: |
| 7 |
> > Well, if you're shooting for accuracy, catalyst does *not* require a |
| 8 |
> > running Gentoo system. It will work on *any* Linux, even Red Hat. I've |
| 9 |
> > also got it running on Mac OS X (building Linux/PPC stages/LiveCD |
| 10 |
> > images) but am working on cleaning up the changes before I merge them |
| 11 |
> > back into catalyst CVS. |
| 12 |
> |
| 13 |
> That is good. I will fix that. Do you have a download site with a short |
| 14 |
> introduction on how to get genkernel and catalyst running on other |
| 15 |
> systems? Apparently it needs at least emerge, genkernel and benefits |
| 16 |
> from splashutils and so. I would like to post a link for other linux |
| 17 |
> users, since I'm going to have a speech at the OpenCA Congress in Munich |
| 18 |
> on Oct., 17th. Then, I could try it under debian (have a server with |
| 19 |
> that) and give a short introduction to that as well. |
| 20 |
|
| 21 |
No. Catalyst only depends on python. You will need a seed stage |
| 22 |
tarball and a portage snapshot, but neither of those require the portage |
| 23 |
application. You don't even need genkernel. Remember that everything |
| 24 |
done within catalyst is downloaded/compiled by catalyst. So |
| 25 |
genkernel/splashutils, etc all come from *inside* the chroot, which will |
| 26 |
*always* be Gentoo if using a Gentoo stage tarball, even if you're |
| 27 |
running on Debian or Fedora as your host. |
| 28 |
|
| 29 |
Using catalyst on debian would be as simple as this: |
| 30 |
|
| 31 |
tar -cxjf catalyst-1.1.10.10.tar.bz2 -C /usr/lib |
| 32 |
mkdir -p /etc/catalyst |
| 33 |
cp /usr/lib/catalyst/files/catalyst.conf /etc/catalyst |
| 34 |
|
| 35 |
> > As for distcc, it works perfectly fine with cross-compiling. |
| 36 |
> |
| 37 |
> See my bug under |
| 38 |
> |
| 39 |
> http://bugs.gentoo.org/show_bug.cgi?id=103493 |
| 40 |
> |
| 41 |
> I'm just telling about my experiences. That bug didn't get any attention |
| 42 |
> yet, although I could easily reproduce it. |
| 43 |
|
| 44 |
Yeah, it's your toolchain causing the issue. It works fine with a |
| 45 |
proper cross-compiler, as I stated. |
| 46 |
|
| 47 |
> > It also |
| 48 |
> > does not require Gentoo. We have several Red Hat Enterprise Linux |
| 49 |
> > machines running distcc perfectly here at work. |
| 50 |
> |
| 51 |
> Is there a rpm for RHL? I'm sorry, but I don't use RHL any more. RHL 6.2 |
| 52 |
> was the last version I was satisfied with, after that, I tried some 7.x |
| 53 |
> but there they messed up the gcc and I was very disappointed... Then I |
| 54 |
> found out about gentoo and installed 1.2 and was happy again. I never |
| 55 |
> again touched RHL. Only debian unstable on my server and SuSE 9.0 once, |
| 56 |
> but it was also a 'pain in the ass' compared to Gentoo ;) |
| 57 |
|
| 58 |
Does it matter if there's an RPM? I honestly don't know, as I compiled |
| 59 |
my own RPM. |
| 60 |
|
| 61 |
> > By the way, x86 == generic. i386 == i386... ;] |
| 62 |
> |
| 63 |
> What do you mean by 'generic' compared to i386? I think that Linux won't |
| 64 |
> run on <=286 (without some serious patching, at least). So, in my |
| 65 |
> opinion, i386 is the most generic Platform on Intel x86 compatible |
| 66 |
> Processors... |
| 67 |
|
| 68 |
No. As far as catalyst is concerned, x86 == *any x86 processor* and |
| 69 |
i386 == *i386* processor. They are not the same. If you want to |
| 70 |
compile for a 386, you use *i386* as your subarch. If you want to |
| 71 |
compile for *any* x86 CPU, you use *x86* as your subarch. |
| 72 |
|
| 73 |
-- |
| 74 |
Chris Gianelloni |
| 75 |
Release Engineering - Strategic Lead |
| 76 |
Games - Developer |
| 77 |
Gentoo Linux |
Archives