[git commit master] FAQ: rephrase toolchain to be version agnostic

[Bernhard Reutner-Fischer]

commit: http://git.uclibc.org/uClibc-website/commit/?id=d068b77fbc2d51023dd84c38c8a78320ec399dd2
branch: http://git.uclibc.org/uClibc-website/commit/?id=refs/heads/master

Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop at gmail.com>
---
 FAQ.html |   57 +++++++++++++++++++++++++++++++++------------------------
 1 files changed, 33 insertions(+), 24 deletions(-)

diff --git a/FAQ.html b/FAQ.html
index f3b98e2..e94ecca 100644
--- a/FAQ.html
+++ b/FAQ.html
@@ -379,56 +379,65 @@ How could it be smaller and not suck?</a></h2>
     <p>
     The current versions of things which are actively supported:
     <ul>
-	<li>Linux-2.4 and newer</li>
+	<li>Linux-2.6 and newer</li>
 	<li>The last two official GNU binutils releases</li>
 	<li>The last few official stable GNU gcc releases</li>
     </ul>
 
     <p>
-    We know that people like to run older versions of Linux (such as the 2.0
-    and 2.2 series).  If things do not work for you on those series, you will
+    We know that people like to run older versions of Linux (such as the 2.2
+    and 2.4 series).  If things do not work for you on those series, you will
     need to come up with a clean fix that can be merged into uClibc.  For
     threading libraries, linuxthreads is planned to be maintained indefinitely
     so long as linux-2.4 support is active.  After that, it will be the same as
     everything else: left alone and hopefully left working.
 
     <p>
-    The last two GNU binutils releases are 2.19 and 2.18.  While 2.18 should
-    work, workarounds for bugs in it are not considered.
+    The last two
+    <a href="http://www.gnu.org/software/binutils/">GNU binutils</a> releases
+    should work fine. Workarounds for bugs in older versions are not
+    considered.
 
     <p>
-    Since the GCC-3.4 and GCC-4.1 series are the recent stable release series
-    (since the 4.0 and 4.2 series tend to be a bit broken for everyone), they
-    are the latest versions we will address.  If you encounter a compile error
-    using an older version (say GCC 3.2), then you're out of luck.  You'll need
-    to workaround it yourself.
+    The last official 
+    <a href="http://www.gnu.org/software/gcc/">GCC</a> point release is
+    supported.
+    If you encounter a compile error using an older version, then you're out of
+    luck.  You'll need to workaround it yourself.
 
     <p>
     For the GNU toolchain releases, only the latest point release is supported.
-    So if you encounter a bug in say GCC-3.4.4, but GCC-3.4.6 works fine, then
+    So if you encounter a bug in say GCC-x.y.7, but GCC-x.y.8 works fine, then
     we will not address it.  Upgrading GCC across point releases is trivial.
-    Same goes for say binutils 2.16 and 2.16.1.
-
-
+    Same goes for binutils.
 
 <hr>
 <p>
 <h2><a name="bugs">I think I found a bug in uClibc!  What should I do?</a></h2>
 <p>
 
-    If you find a problem with uClibc, please submit a detailed bug report to
-    the uClibc mailing list at <a href="mailto:uclibc at uclibc.org">
-    uclibc at uclibc.org</a>.  Please do not send private email to Erik
-    (the maintainer of uClibc) asking for private help unless you are planning
-    on paying for consulting services.  When we answer questions on the uClibc
-    mailing list, it helps everyone, while private answers help only you...
-
-    A well-written bug report should include an example that demonstrates the
-    problem behaviors and enables anyone else to duplicate the bug on their own
-    machine.  For larger applications where it may prove difficult to provide
+    A well-written bug report should include
+    <ul>
+    <li><em>small, self-contained example </em> that demonstrates the problem behaviors
+    <li>Versions of the toolchain used (gcc, binutils, etc)
+    <li>Other relevant information that enables anyone else to duplicate the bug
+    </ul>
+    For architecture-specific bugs, also mention the target triplet (like
+    armeb-linux-uclibcgnueabi).
+    <p>
+    For larger applications where it may prove difficult to provide
     an example application, we recommend that you use a tool such as gdb,
     strace, ltrace, and or valgrind to create a logfile showing the problem
     behavior.
+    <p>
+    If you find a problem with uClibc, please submit a detailed bug report to
+    the uClibc <a href="https://bugs.uClibc.org/">bug tracker</a> or, if you are
+    uncertain that it is a bug, to the mailing list at
+    <a href="mailto:uclibc at uclibc.org"> uclibc at uclibc.org</a>.  Please do not
+    send private email to individual developers asking for private help unless
+    you are planning on paying for consulting services.  When we answer
+    questions on the uClibc mailing list, it helps everyone, while private
+    answers help only you...
 
 
 <hr>
-- 
1.6.3.3