FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo User

 
 
LinkBack Thread Tools
 
Old 02-05-2011, 12:22 PM
Nils Holland
 
Default The CHOST variable

On 21:21 Fri 04 Feb , Enrico Weigelt wrote:

> * Nils Holland <nhg@tisys.org> wrote:
>
> > 1) So a package using the GNU build system determines or is passed
> > (via --host aka. CHOST) a target triplet specifying the system on
> > which the resulting compiled code is supposed to run. What does the
> > package do with that information? Does it only use it to determine
> > what it has to compile (different / special code for different systems
> > / architectures), or does this already have an influence on the
> > optimization of the resulting code for a certain (sub-)architecture?
>
> Exactly. Some packages have arch- and subarch-specific optimizations.
> Those things IMHO should be primarily taken from the target triplet
> (instead of other ./configure options), as it quite exactly defines
> what cputype, platform and toolchain type you're using. It's very
> important for crosscompiling (even some toolchains, eg. gcc., could,
> and should, be explicitly asked for their target triplet).

Hi Enrico,

thanks very much for your in-depth explanation in this and also your
other mail you've sent in response to my question. That was really
helpful, as it cleared up some things I could previously only guess
about but was by no means certain about.

I've learnt something new (which was my highest priority here), and
can even use this knowlede to deduce what makes sense in my current
experiments with building my own stage3's and install boot discs via
catalyst.

So, thanks again for your insightful replies!

Greetings,
Nils


--
Nils Holland * Ti Systems, Wunstorf-Luthe (Germany)
Powered by GNU/Linux since 1998
 
Old 02-07-2011, 10:13 AM
Stroller
 
Default The CHOST variable

On 4/2/2011, at 9:31am, Neil Bothwick wrote:
> ...
> Any time you consider a process that involves emerge -e world, you should
> also consider a reinstall. A reinstall will certainly be quicker, the
> only reason for an in place fix is if you cannot take the machine down
> for that length of time.

I disagree. The `emerge -e world` may take longer, but it will consume less of *my time* overseeing it.

Obviously this may not be the case if we're talking about a desktop system in constant use, and the update breaks your web-browser. But in all my use cases I'm going to be able to leave the `emerge -e world` running in the background and just check up on it periodically.

A Gentoo reinstall is not so easy as "click, click, click" and let it run. You should do a full backup first, because you can easily copy /etc over to the new machine and only afterwards realise you forgot to copy /var/bind/

An `emerge -e world` may break things, but it's not usually that likely to.

Stroller.
 
Old 02-07-2011, 11:24 AM
Stroller
 
Default The CHOST variable

On 4/2/2011, at 5:58am, Florian Philipp wrote:
>> ...
>> The warning is actually there to stop users doing stupid things like blindly
>> trying to convert 32 bit systems to 64 bit. This is how that goes down:
>>
>> 1. Change CHOST
>> 2. emerge -e world
>> 3. ???
>> 4. Fail!
>
> Is the same true for more compatible arches like i486 -> i686? I have a
> system where I used the wrong stage-3 and now I'm stuck with an i486
> CHOST on an Atom netbook where I could use every bit of performance.

I'm in the process of this at the moment.

I have a Cobalt Qube III, which has a K6-2 CPU, and which will never accommodate any other processor.

The closest Gentoo stage was i486, and on such a slow old system it would be nice to squeeze out any extra performance I can.

From the i486 stage I used:

# cat /etc/make.conf.catalyst
# These settings were set by the catalyst build script that automatically
# built this stage.
CFLAGS="-O2 -march=i486 -pipe"
CXXFLAGS="${CFLAGS}"
# WARNING: Changing your CHOST ...
# Please consult http://www.gentoo.org/doc/en/change-chost.xml before changing.
CHOST="i486-pc-linux-gnu"

Following the instructions I changed the CHOST (to i586) and did the `emerge -1 binutils gcc glibc` part.

That went fine, so I changed CFLAGS="-march=native -O2 -pipe -fomit-frame-pointer", and followed the next steps up to 2.12 - `emerge -e world`.

This failed about 3 packages in and really messed things up - I quickly couldn't emerge anything else and running executables failed with a segfault or something.

I had to pull the drive back out of the Qube and copy most of the i486 stage back over the fouled-up installation.

This time around, I changed the CHOST again to i586 and ran `emerge -1 binutils gcc glibc`, then `lafilefixer --justfixit && revdep-rebuild` (didn't need to do anything, it said) then the `emerge -e world` part - but this time still with the original i486 CFLAGS (as the catalyst above). This is currently at "104 of 145" packages through the emerge process, so seems ok.

Hopefully when that's done I'll be able to change CFLAGS to "-march=native" and re-emerge the whole lot again. I'm now a bit nervous of that (I'm wondering if `-mcpu` or `-mtune` would be more suitable as a first step), so I'll take a disk image using dd (again) so that I have a restore point, should I need it.

Stroller.
 
Old 02-07-2011, 12:33 PM
Neil Bothwick
 
Default The CHOST variable

On Mon, 7 Feb 2011 11:13:27 +0000, Stroller wrote:

> > Any time you consider a process that involves emerge -e world, you
> > should also consider a reinstall. A reinstall will certainly be
> > quicker, the only reason for an in place fix is if you cannot take
> > the machine down for that length of time.
>
> I disagree. The `emerge -e world` may take longer, but it will consume
> less of *my time* overseeing it.
>
> Obviously this may not be the case if we're talking about a desktop
> system in constant use, and the update breaks your web-browser. But in
> all my use cases I'm going to be able to leave the `emerge -e world`
> running in the background and just check up on it periodically.
>
> A Gentoo reinstall is not so easy as "click, click, click" and let it
> run.

To a large extent, it is. you've already partitioned the drive, set up
make.conf, created a world file, all of which can be reused. So a
reinstall isn't much more than emerge -e world and recompile the kernel
after emptying the filesystem.

> An `emerge -e world` may break things, but it's not usually that likely
> to.

An emerge -e world is not likely to break things in itself, but the steps
that require it, such as changing CHOST, are. The extra steps of a
reinstall over trying to fix a machine with a borked
binutils/glibc/whatever can be far more time consuming, not to mention
frustrating, than a reinstall, and may only be fixed by a reinstall
anyway after all that.

I'm not an advocate of reinstalling normally, this installation is three
years older than the computer running it, but when performing drastic
low-level surgery, I believe it should be contemplated.


--
Neil Bothwick

Quality control, n.:
Assuring that the quality of a product does not get out of hand
and add to the cost of its manufacture or design.
 
Old 02-07-2011, 10:03 PM
Nils Holland
 
Default The CHOST variable

On 12:24 Mon 07 Feb , Stroller wrote:
>
>
> The closest Gentoo stage was i486, and on such a slow old system it would be nice to squeeze out any extra performance I can.

Well, what I'm currently in the process of trying to do (not because I
have an actual need for it, but rather out of experimentation) is
taking a Gentoo i486 stage3 tarball and turning it into a i586 one.

I realized that on the i686 host I am using, I can just let catalyst
loose on an official Gentoo i486 or i686 tarball and, with the
appropriate settings, have it build a new and more current tarball out
of it. Fine.

However, what certainly doesn't work is taking one of these stage3
tarballs (i486 or i686) and have catalyst build an i586 tarball out of
that. In my attemts when trying this, catalyst first compiled a new
glibc with i586, and the next thing it tried was building a new zlib
with using the i586 glibc and the still i486 gcc and other stuff,
which resulted in failure (don't have the exact error message anymore,
but it was along the lines of the linker complaining about not being
able to determine SONAME of libz.so).

So what would probably work and what I'll try in the next days is the
following: Unpack i486 tarball, chroot into it, and then manually try
to make a i586 tarball out of it. That would probably involve the
process described in the Gentoo "how to change your CHOST" document. I
guess that once I've "prepared" such an i586 stage3 manually, I can
regularely let catalyst handle updating it, just as it does fine with
the original i486 and i686 stage3's.

Again, I'm only doing this out of curiosity to see if it works and /
or what problems I encounter and to learn some stuff; I'm probably
never going to use the resulting stage3 tarball on my own machines,
as Gentoo's i486 and i686 ones suit me just fine and I'm not a big
performance tuner / tweaker. Still, if I succeed and if anyone is
interested, I could certainly make me i586 stage3 available for
download.

I've also, just for fun, looked at a i386 stage3. However, while that
would technically certainly also be possible, it seems that Gentoo's
glibc ebuild is specifically set up to bail out when building on
i386. That would probably even be fixable by not building with nptl,
but that way it would only be possible to built something that would
make problems when using the normal portage tree and coming into a
situation where it wants to build a new (nptl-enabled) glibc for the
first time, not to mention that I don't have a clue what other stuff
would break when the user tries to install it from portage on a system
that comes with a glibc I've "hacked" to come without nptl.

Greetings,
Nils

--
Nils Holland * Ti Systems, Wunstorf-Luthe (Germany)
Powered by GNU/Linux since 1998


Tue Feb 8 00:30:02 2011
Return-path: <devel-bounces@lists.fedoraproject.org>
Envelope-to: tom@linux-archive.org
Delivery-date: Mon, 07 Feb 2011 23:58:47 +0200
Received: from bastion02.fedoraproject.org ([209.132.181.3]:58906 helo=bastion.fedoraproject.org)
by s2.java-tips.org with esmtp (Exim 4.69)
(envelope-from <devel-bounces@lists.fedoraproject.org>)
id 1PmZ6d-0001Hr-Ja
for tom@linux-archive.org; Mon, 07 Feb 2011 23:58:47 +0200
Received: from lists.fedoraproject.org (collab1.vpn.fedoraproject.org [192.168.1.21])
by bastion02.phx2.fedoraproject.org (Postfix) with ESMTP id AE89C10F9D3;
Mon, 7 Feb 2011 23:07:32 +0000 (UTC)
Received: from collab1.fedoraproject.org (localhost.localdomain [127.0.0.1])
by lists.fedoraproject.org (Postfix) with ESMTP id DE841326782;
Mon, 7 Feb 2011 23:07:31 +0000 (UTC)
X-Original-To: devel@lists.fedoraproject.org
Delivered-To: devel@lists.fedoraproject.org
Received: from smtp-mm03.fedoraproject.org (smtp-mm3.fedoraproject.org
[152.46.7.226])
by lists.fedoraproject.org (Postfix) with ESMTP id F0267326781
for <devel@lists.fedoraproject.org>;
Mon, 7 Feb 2011 23:07:29 +0000 (UTC)
Received: from mail-ew0-f45.google.com (mail-ew0-f45.google.com
[209.85.215.45])
by smtp-mm03.fedoraproject.org (Postfix) with ESMTP id 69D7837D58
for <devel@lists.fedoraproject.org>;
Mon, 7 Feb 2011 23:07:29 +0000 (UTC)
Received: by ewy10 with SMTP id 10so2685257ewy.32
for <devel@lists.fedoraproject.org>;
Mon, 07 Feb 2011 15:07:28 -0800 (PST)
Received: by 10.216.186.144 with SMTP id w16mr14971980wem.13.1297120048450;
Mon, 07 Feb 2011 15:07:28 -0800 (PST)
Received: from [192.168.1.1] (157-157-196-145.dsl.dynamic.simnet.is
[157.157.196.145])
by mx.google.com with ESMTPS id u2sm2484236weh.12.2011.02.07.15.07.27
(version=SSLv3 cipher=RC4-MD5); Mon, 07 Feb 2011 15:07:27 -0800 (PST)
Subject: Re: Could not find debuginfo pkg for dependency package. . .
From: =?ISO-8859-1?Q?J=F3hann?= "B." =?ISO-8859-1?Q?Gu=F0mundsson?=
<johannbg@gmail.com>
To: devel@lists.fedoraproject.org
Date: Mon, 07 Feb 2011 23:07:22 +0000
In-Reply-To: <20110207160146.7eb34eb5@ohm.scrye.com>
References: <1297117392.3733.9.camel@localhost.localdomain>
<20110207160146.7eb34eb5@ohm.scrye.com>
X-Mailer: Evolution 2.91.6.1 (2.91.6.1-1.fc15)
Message-ID: <1297120043.1744.1.camel@localhost.localdomain>
Mime-Version: 1.0
X-BeenThere: devel@lists.fedoraproject.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Development discussions related to Fedora
<devel@lists.fedoraproject.org>
List-Id: Development discussions related to Fedora
<devel.lists.fedoraproject.org>
List-Unsubscribe: <https://admin.fedoraproject.org/mailman/listinfo/devel>,
<mailto:devel-request@lists.fedoraproject.org?subject=unsubscrib e>
List-Archive: <http://lists.fedoraproject.org/pipermail/devel>
List-Post: <mailto:devel@lists.fedoraproject.org>
List-Help: <mailto:devel-request@lists.fedoraproject.org?subject=help>
List-Subscribe: <https://admin.fedoraproject.org/mailman/listinfo/devel>,
<mailto:devel-request@lists.fedoraproject.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: devel-bounces@lists.fedoraproject.org
Errors-To: devel-bounces@lists.fedoraproject.org

T24gTW9uLCAyMDExLTAyLTA3IGF0IDE2OjAxIC0wNzAwLCBLZX ZpbiBGZW56aSB3cm90ZToKPiBP
biBNb24sIDA3IEZlYiAyMDExIDIyOjIzOjExICswMDAwCj4gSs OzaGFubiAiQi4iIEd1w7BtdW5k
c3NvbiA8am9oYW5uYmdAZ21haWwuY29tPiB3cm90ZToKPiAKPi A+IEkndmUgYmVlbiBleHBlcmll
bmNpbmcgc29tZSBtdXR0ZXIgY3Jhc2hlcyB3aGVuIHRyeWluZy B0byByZXBvcnQgaXQKPiA+IHZp
YSBhYnJ0LCBhYnJ0IGluZm9ybWVkIG1lIHRoYXQgcmVwb3J0aW 5nIHdhcyBkaXNhYmxlZCBiZWNh
dXNlIHRoZQo+ID4gYmFja3RyYWNlIGlzIHVudXNhYmxlIGFuZC BzdWdnZXN0ZWQgSSBpbnN0YWxs
ZWQgZGVidWdpbmZvLWluc3RhbGwKPiA+IG11dHRlciB0aGVuIH JlZnJlc2ggYW5kIHRyeSBhZ2Fp
biB3aGljaCByZXZlYWxlZC4gLi4gCj4gPiAKPiA+IENvdWxkIG 5vdCBmaW5kIGRlYnVnaW5mbyBw
a2cgZm9yIGRlcGVuZGVuY3kgcGFja2FnZQo+ID4gZ2xpYmMtMi 4xMy45MC0yLng4Nl82NAo+ID4g
Q291bGQgbm90IGZpbmQgZGVidWdpbmZvIHBrZyBmb3IgZGVwZW 5kZW5jeSBwYWNrYWdlCj4gPiBj
bHV0dGVyLTEuNi4yLTEuZmMxNS54ODZfNjQKPiAKPiBXaGVyZS BkaWQgeW91IGluc3RhbGwgZ2xp
YmMgZnJvbSA/IEtvamk/IAo+IAo+ID4gSSdtIGEgYml0IGN1cmlvdXMgaWYgd2UgY2FudC BhdXRv
bWF0aWNhbGx5IGNoZWNrIGZvciBtaXNzaW5nIGRlYnVnaW5mbw o+ID4gcGFjYWtnZXMgZm9yIHJl
bGV2YW50IGNvbXBvbmVudChzKSBhbmQgaW5mb3JtIHRoZSBwYW NrYWdlci9tYWludGFpbmVyCj4g
PiBlbmNhc2UgdGhleSBkb250IGV4aXN0IHRvIHByZXZlbnQgZW 5jb3VudGVycyBsaWtlIHRoaXM/
Cj4gCj4gVGhlIHByb2JsZW0gaXMgdGhhdCB0aGF0IHZlcnNpb2 4gb2YgZ2xpYmMgd2FzIGJ1aWx0
IHRvZGF5LCBzbyBpdCdzIG5vdAo+IGluIHJlcG9zIGFuZCB0aH VzIGl0J3MgZGVidWdpbmZvIGlz
bid0IGluIHJlcG9zIGVpdGhlci4gCj4gCj4gSSBkb24ndCB0aG luayB0aGUga29qaSBzdGF0aWMg
cmVwb3MgaW5jbHVkZSBkZWJ1Z2luZm8sIHNvIGlmIHlvdSBhcm UKPiBpbnN0YWxsaW5nIGZyb20g
dGhlcmUgeW91IHdpbGwgbmVlZCB0byBkb3dubG9hZCBhbmQgaW 5zdGFsbCB0aGUKPiBkZWJ1Z2lu
Zm8gbWFudWFsbHkuIAoKWXVwIHVzaW5nIHN0YXRpYyByZXBvIG Zyb20ga29qaQoKVGhhbmtzIGZv
ciB0aGUgaGVhZHMgdXAgd2lsbCBhZGQgdGhvc2UgcGFja2FnZX MgbWFudWFsbHkgCgpKQkcKCgot
LSAKZGV2ZWwgbWFpbGluZyBsaXN0CmRldmVsQGxpc3RzLmZlZG 9yYXByb2plY3Qub3JnCmh0dHBz
Oi8vYWRtaW4uZmVkb3JhcHJvamVjdC5vcmcvbWFpbG1hbi9saX N0aW5mby9kZXZlbA==
 
Old 02-08-2011, 11:41 AM
Stroller
 
Default The CHOST variable

On 7/2/2011, at 11:03pm, Nils Holland wrote:
> On 12:24 Mon 07 Feb , Stroller wrote:
>>
>>
>> The closest Gentoo stage was i486, and on such a slow old system it would be nice to squeeze out any extra performance I can.
>
> ...
> So what would probably work and what I'll try in the next days is the
> following: Unpack i486 tarball, chroot into it, and then manually try
> to make a i586 tarball out of it. That would probably involve the
> process described in the Gentoo "how to change your CHOST" document.

If my process wasn't clear from my last email: it looks like, following that document, you have to do the whole thing with changed CHOST, *before* making any changes to CFLAGS. It appears like only after you've `emerge -e world` with the new CHOST can you change CFLAGS.

> I guess that once I've "prepared" such an i586 stage3 manually, I can
> regularely let catalyst handle updating it, just as it does fine with
> the original i486 and i686 stage3's.

I haven't used catalyst at all. You make it sound interesting & useful.

Stroller.
 
Old 02-08-2011, 08:11 PM
Nils Holland
 
Default The CHOST variable

On 12:41 Tue 08 Feb , Stroller wrote:

> If my process wasn't clear from my last email: it looks like, following that document, you have to do the whole thing with changed CHOST, *before* making any changes to CFLAGS. It appears like only after you've `emerge -e world` with the new CHOST can you change CFLAGS.

Thanks for the hint, right now I've got the i486 stage3 in a chroot
and have changed both the CHOST and CFLAGS to i586. If that leads to
problems, as you've described, I'll start over with only setting CHOST
to i586 at first and then changing CFLAGS. Currently the build process
is running fine, however, but I'm mentally prepared for difficults
now. ;-)

> > I guess that once I've "prepared" such an i586 stage3 manually, I can
> > regularely let catalyst handle updating it, just as it does fine with
> > the original i486 and i686 stage3's.
>
> I haven't used catalyst at all. You make it sound interesting & useful.

I've found it useful in the sense that it has allowed me to download
an original Gentoo stage3 way back, and then - say, once a month -
I've let catalyst build a new, updated stage3 out of it which I then
used for new installations whenever I had to do then. Of course, I
could just have grabbed one of the official Gentoo stage3's that get
updated weekly, but hey, somehow it just feels cooler to use a stage3
you've rolled yourself. ;-)

I'll post again when I have my i586 stage3 available for
download. Folks wanting to perform a new Gentoo installation on an
i586 kind of machine could then just grab and use that one if they
don't want to use Gentoo's i486 stage3 (and stay at i486 or change the
CHOST / CFLAGS to i586 after installation themselves).

Greetings,
Nils


--
Nils Holland * Ti Systems, Wunstorf-Luthe (Germany)
Powered by GNU/Linux since 1998
 
Old 02-08-2011, 08:55 PM
Alan McKinnon
 
Default The CHOST variable

Apparently, though unproven, at 15:33 on Monday 07 February 2011, Neil
Bothwick did opine thusly:

> > An `emerge -e world` may break things, but it's not usually that likely
> > to.
>
> An emerge -e world is not likely to break things in itself, but the steps
> that require it, such as changing CHOST, are. The extra steps of a
> reinstall over trying to fix a machine with a borked
> binutils/glibc/whatever can be far more time consuming, not to mention
> frustrating, than a reinstall, and may only be fixed by a reinstall
> anyway after all that.
>
> I'm not an advocate of reinstalling normally, this installation is three
> years older than the computer running it, but when performing drastic
> low-level surgery, I believe it should be contemplated.


If you're a gambling man, play it by the numbers:

A re-install for a Gentoo user with a clue is a certain 1 hour of your life
tops to get it redone with a recent stage 3, more likely 30 minutes. That will
give you a working system albeit one a bit out of date that emerge -avunD
world will fix nicely.

Trying to fix the existing system complete with it's borkage is very
uncertain. Maybe it's 5 minutes, maybe it's 2 hours, maybe it's three days on
this list scratching heads before eventually giving up and re-installing
anyway.

Personally, I long ago proved I can do #2. I like the certainty from #1.


--
alan dot mckinnon at gmail dot com
 
Old 02-10-2011, 02:18 PM
Stroller
 
Default The CHOST variable

On 8/2/2011, at 9:55pm, Alan McKinnon wrote:
> ...
> If you're a gambling man, play it by the numbers:
>
> A re-install for a Gentoo user with a clue is a certain 1 hour of your life
> tops to get it redone with a recent stage 3, more likely 30 minutes. That will
> give you a working system albeit one a bit out of date that emerge -avunD
> world will fix nicely.

That makes no sense to me at all.

There are stage3s built on a daily basis - they won't be out of date at all. But they don't include system logger, cron, locale, or any of your personalisations.

On any kind of complex system it will take me more than a day to set those up - can I be sure that I'll get them right first time, every time?

If we're talking about an older system then I need to back up everything so that I can copy files the files I missed from the /etc to the new one.

If you're talking about stuff like KDE then that alone is going to take more than an hour to compile.

I understood that a backup that was of your own system - that might be a bit out of date but which includes these things - was called a stage4. And in that case you're still faced with the problem that it's probably just as out of date as the install which is proving difficult to update in the first place.

My experience of a system which was a year or even 18 months old was that it did have some blockers and some bugs which had been addressed here months before. It did require me to pull some files out of Gentoo's CVS attic and emerge the old ebuilds from my local tree, before they could be updated to current. But I knew that the configuration was sound and that all I had to do was address the blocker and then resume the `emerge -ud world`- the emerging is something that can go on in the background whilst I'm not paying attention.

Stroller.
 
Old 02-10-2011, 02:24 PM
Stroller
 
Default The CHOST variable

On 8/2/2011, at 9:11pm, Nils Holland wrote:
> On 12:41 Tue 08 Feb , Stroller wrote:
>
>> If my process wasn't clear from my last email: it looks like, following that document, you have to do the whole thing with changed CHOST, *before* making any changes to CFLAGS. It appears like only after you've `emerge -e world` with the new CHOST can you change CFLAGS.
>
> Thanks for the hint, right now I've got the i486 stage3 in a chroot
> and have changed both the CHOST and CFLAGS to i586. If that leads to
> problems, as you've described, I'll start over with only setting CHOST
> to i586 at first and then changing CFLAGS. Currently the build process
> is running fine, however, but I'm mentally prepared for difficults
> now. ;-)

I completed the `emerge -e world` with the new CHOST, ran `lafilefixer --justfixit && revdep-rebuild` and then Python and the Perl packages, as listed in the documentation. I'm pretty sure I ran `lafilefixer --justfixit && revdep-rebuild` again, finding nothing.

Changing CFLAGS="-march=native -O2 -pipe -fomit-frame-pointer" failed again on the first package, ncurses. CFLAGS="-mtune=native -O2 -pipe -fomit-frame-pointer" seems to be working (now on package 10 of 155).

Perhaps I should have tried CFLAGS="-O2 -march=i586 -pipe" instead. I don't really know what the "-fomit-frame-pointer" part does - I imagine someone suggested it, perhaps on here, years ago, and it has got copied from system to system.

Stroller.
 

Thread Tools




All times are GMT. The time now is 11:52 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org