* version.h (VERSION): 2.3.4.

	* README.template: Various updates.
	* README: Regenerated.
	* NEWS: Mention ports.
	* README-alpha: File removed.

6 files changed, 30 insertions, 363 deletions

diff --git a/ChangeLog b/ChangeLog
index 76ee5da9b8..7db9612f04 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,11 @@
 2004-12-19  Roland McGrath  <roland@frob.com>
 
+	* version.h (VERSION): 2.3.4.
+	* README.template: Various updates.
+	* README: Regenerated.
+	* NEWS: Mention ports.
+	* README-alpha: File removed.
+
 	[BZ #416]
 	* locale/langinfo.h: Comment fixes.
 
diff --git a/NEWS b/NEWS
index 236c4378f8..f73d3287c4 100644
--- a/NEWS
+++ b/NEWS
@@ -1,4 +1,4 @@
-GNU C Library NEWS -- history of user-visible changes.  2004-10-19
+GNU C Library NEWS -- history of user-visible changes.  2004-12-19
 Copyright (C) 1992-2002,2003,2004 Free Software Foundation, Inc.
 See the end for copying conditions.
 
@@ -40,7 +40,13 @@ Version 2.3.4
 * Low-overhead boundary checking variants of string and some stdio functions
   were added.  These are to be used in conjunction with a gcc patch by
   Jakub Jelinek which adds calls to these functions if possible.
-  Patch by Jakub Jelinek and Ulrich Drepper.
+  Implemented by Jakub Jelinek and Ulrich Drepper.
+
+* Old code for several operating systems and machine architectures that
+  have not been in working condition in a long time have been removed from
+  the main source tree maintained by the GNU C Library's maintainers.
+  These files are now reside in the separate `ports' source module
+  that is usable as an add-on when building the library.
 
 Version 2.3.3
 
diff --git a/README b/README
index 69a712a6cf..36a2af9129 100644
--- a/README
+++ b/README
@@ -1,4 +1,4 @@
-This directory contains the version 2.3.3 release of the GNU C Library.
+This directory contains the version 2.3.4 release of the GNU C Library.
 Many bugs have been fixed since the last release.
 Some bugs surely remain.
 
@@ -21,39 +21,12 @@ configurations:
 		s390-*-linux-gnu	Linux-2.x on IBM S/390
 		s390x-*-linux-gnu	Linux-2.4+ on IBM S/390 64-bit
 		sh-*-linux-gnu		Linux-2.x on Super Hitachi
-		cris-*-linux-gnu	Linux-2.4+ on CRIS
 		x86-64-*-linux-gnu	Linux-2.4+ on x86-64
 
-Former releases of this library (version 1.09.1 and perhaps earlier
-versions) used to run on the following configurations:
-
-		alpha-dec-osf1
-		i[3456]86-*-bsd4.3
-		i[3456]86-*-isc2.2
-		i[3456]86-*-isc3
-		i[3456]86-*-sco3.2
-		i[3456]86-*-sco3.2v4
-		i[3456]86-*-sysv
-		i[3456]86-*-sysv4
-		i[3456]86-force_cpu386-none
-		i[3456]86-sequent-bsd
-		i960-nindy960-none
-		m68k-hp-bsd4.3
-		m68k-mvme135-none
-		m68k-mvme136-none
-		m68k-sony-newsos3
-		m68k-sony-newsos4
-		m68k-sun-sunos4
-		mips-dec-ultrix4
-		mips-sgi-irix4
-		sparc-sun-solaris2
-		sparc-sun-sunos4
-
-Since no one has volunteered to test and fix the above configurations,
-these are not supported at the moment.  It's expected that these don't
-work anymore.  Porting the library is not hard.  If you are interested
-in doing a port, please contact the glibc maintainers by sending
-electronic mail to <bug-glibc@gnu.org>.
+Past releases of this library ran on a variety of configurations that are
+no longer supported.  Porting the library is not hard.  If you are
+interested in doing a port, please contact the glibc maintainers;
+see http://www.gnu.org/software/libc/ for more information.
 
 There are some add-ons which can be used together with GNU libc.  They
 are designed in a way to ease the installation by integrating them in
@@ -76,11 +49,9 @@ The file NOTES contains a description of the feature-test macros used
 in the GNU C library, explaining how you can tell the library what
 facilities you want it to make available.
 
-We prefer to get bug reports sent using the `glibcbug' shell script which
-is installed together with the rest of the GNU libc to <bugs@gnu.org>.
-Simply run this shell script and fill in the information.  Nevertheless
-you can still send bug reports to <bug-glibc@gnu.org> as normal electronic
-mails.
+Please see http://www.gnu.org/software/libc/bugs.html for bug reporting
+information.  We are now using the Bugzilla system to track all bug reports.
+This web page gives detailed information on how to report bugs properly.
 
 The GNU C Library is free software.  See the file COPYING.LIB for copying
 conditions, and LICENSES for notices about a few contributions that require
diff --git a/README-alpha b/README-alpha
deleted file mode 100644
index a2a15ddb23..0000000000
--- a/README-alpha
+++ /dev/null
@@ -1,287 +0,0 @@
-			 GNU libc SNAPSHOT SYSTEM
-			    (general info)
-			   Updated 1997-9-26
-
-WHAT ARE GNU libc SNAPSHOTS
----------------------------
-
-Snapshots are an "image" of the main glibc development tree, captured at a
-particular random instant in time.  When you use the snapshots, you should be
-able to maintain a local copy of libc that is no more than one day older than
-the official source tree used by the libc maintainers.
-
-The primary purpose of providing snapshots is to widen the group of motivated
-developers that would like to help test, debug, and enhance glibc, by providing
-you with access to the "latest and greatest" source.  This has several
-advantages, and several disadvantages.
-
-    First the advantages:
-
-    o	Once we have a large base of motivated testers using the snapshots,
-	this should provide good coverage across all currently supported
-	glibc hosts and targets.  If a new bug is introduced in glibc due to
-	fixing another bug or ongoing development, it should become
-	obvious much more quickly and get fixed before the next general
-	net release.  This should help to reduce the chances of glibc being
-	released to the general public with a major bug that went unnoticed
-	during the release cycle testing because they are machine dependent.
-	We hope to greatly improve glibc's stability and reliability by
-	involving more people and more execution environments in the
-	prerelease testing.
-
-    o	With access to the latest source, any diffs that you send to fix
-	bugs or add new features should be much easier for the glibc team
-	to merge into the official source base (after suitable review
-	of course).  This encourages us to merge your changes quicker,
-	while they are still "fresh".
-
-    o	Once your diffs are merged, you can obtain a new copy of glibc
-	containing your changes almost immediately.  Thus you do not
-	have to maintain local copies of your changes for any longer
-	than it takes to get them merged into the official source base.
-	This encourages you to send in changes quicker.
-
-    And the disadvantages:
-
-    o	The snapshot you get will be largely untested and of unknown quality.
-	It may fail to configure or compile.  It may have serious bugs.
-	You should always keep a copy of the last known working version
-	before updating to the current snapshot, or at least be able to
-	regenerate a working version if the latest snapshot is unusable
-	in your environment for some reason.
-
-	If a production version of glibc has a bug and a snapshot has the fix,
-	and you care about stability, you should put only the fix for that
-	particular problem into your production version.  Of course, if you
-	are eager to test glibc, you can use the snapshot versions in your
-	daily work, but users who have not been consulted about whether they
-	feel like testing glibc should generally have something which is at
-	least as bug free as the last released version.
-
-    o	Providing timely response to your questions, bug reports, and
-	submitted patches will require the glibc development team to allocate
-	time from an already thin time budget.  Please try to help us make
-	this time as productive as possible.  See the section below about
-	how to submit changes.
-
-
-WHO SHOULD TRY THE SNAPSHOTS
-----------------------------
-
-Remember, these are snapshots not tested versions.  So if you use
-these versions you should be able to
-
-    o	make sure your system stays usable
-
-    o	locate and hopefully fix problems
-
-    o	to port glibc to a new target yourself
-
-You should not use the snapshots if
-
-    o	your system is needed in a production environment which needs
-	stability
-
-    o	you expect us to fix your problems since you somehow depend on them.
-	You must be willing to fix the problems yourself, we don't want to
-	see "I have problems, fix this" messages.
-
-
-HOW TO GET THE SNAPSHOTS
-------------------------
-
-At the moment we provide a full snapshot weekly (every sunday), so
-that users getting a snapshot for the first time, or updating after
-a long period of not updating, can get the latest version in a single
-operation.  Along with the full snapshot, we will provide incremental
-diffs on a nearly daily basis (whenever code changes).  Each daily
-diff will be relative to the source tree after applying all previous
-daily diffs.  The daily diffs are for people who have relatively low
-bandwidth ftp or uucp connections.
-
-The files will be available via anonymous ftp from alpha.gnu.org, in
-directory /gnu/libc and on linux.kernel.org in /pub/software/libs/glibc.  The
-directories should look something like:
-
-	libc-970921.tar.gz
-	libc-970917-970922.diff.gz
-	libc-970922-970925.diff.gz
-	.
-	.
-	.
-
-Please note that the snapshots on alpha.gnu.org and on
-linux.kernel.org are not always in sync. Patches to some files might
-appear a day a diff earlier or later on alpha than on kernel.
-Use always alpha or always kernel but don't mix them.
-
-There are sometimes additionally test releases of the add-ons available in
-these directories.  If a new version of an add-on is available it is normally
-required for the corresponding snapshot so always pay attention for these.
-
-Note that we provide GNU gzip compressed files only.  You can ftp gzip
-from ftp.gnu.org in directory pub/gnu.
-
-In some cases the dates for diffs and snapshots do not match like in the
-example above.  The full release is for 970921 but the patch is for
-970917-970922.  This only means that nothing changed between 970917 and 970922
-and that you have to use this patch on top of the 970921 snapshot since the
-patch is made on 970922.
-
-Also, as the gcc developers did with their gcc snapshot system, even though we
-will make the snapshots available on a publically accessible ftp area, we ask
-that recipients not widely publicise their availability.  The motivation for
-this request is not to hoard them, but to avoid the situation where the
-general glibc user base naively attempts to use the snapshots, has trouble with
-them, complains publically, and the reputation of glibc declines because of a
-perception of instability or lack of quality control.
-
-
-GLIBC TEST SUITE
-----------------
-
-A test suite is distributed as an integral part of the snapshots.  A simple
-"make check" in your build directory is sufficient to run the tests.  glibc
-should pass all tests and if any fails, please report it.  A failure might not
-originate from a bug in glibc but also from bugs in the tools, e.g. with gcc
-2.7.2.x the math tests fail some of the tests because of compiler bugs.
-
-Note that the test suite is still in its infancy.  The tests themselves only
-cover a small portion of libc features, and where tests do exist for a feature
-they are not exhaustive.  New tests are welcome.
-
-
-GETTING HELP, GLIBC DISCUSSIONS, etc
-------------------------------------
-
-People who want to help with glibc and who test out snapshots
-regularly should get on the libc-alpha@sourceware.cygnus.com mailing
-list by sending an email to libc-alpha-subscribe@sourceware.cygnus.com.
-This list is meant (as the name suggests) for the discussion of test
-releases and also reports for them.  People who are on this list are
-welcome to post questions of general interest.
-
-People who are not only willing to test the snapshots but instead
-really want to help developing glibc should contact
-libc-hacker-subscribe@sourceware.cygnus.com.org to be put on the developers
-mailing list.  This list is really only meant for developers.  No
-questions about installation problems or other simple topics are
-wanted nor will they be answered.
-
-Do *not* send any questions about the snapshots or patches specific to the
-snapshots to bug-glibc@gnu.org.  Nobody there will have any idea what
-you are talking about and it will just cause confusion.
-
-
-BUG REPORTS
------------
-
-Send bug reports directly to Ulrich Drepper <drepper@gnu.org>.  Please
-do *not* use the glibcbug script for reporting bugs in the snapshots.
-glibcbug should only be used for problems with the official released versions.
-We don't like bug reports in the bug database because otherwise the impression
-of instability or lack of quality control of glibc as a whole might manifest
-in people's mind.
-
-Note that since no testing is done on the snapshots, and snapshots may even be
-made when glibc is in an inconsistent state, it may not be unusual for an
-occasional snapshot to have a very obvious bug, such as failure to compile on
-*any* machine.  It is likely that such bugs will be fixed by the next
-snapshot, so it really isn't necessary to report them unless they persist for
-a couple of days.
-
-Missing files should always be reported, since they usually mean there is a
-problem with the snapshot-generating process and we won't know about them
-unless someone tells us.
-
-Bugs which are non-obvious, such as failure to compile on only a specific
-machine, a new machine dependent or obscure bug (particularly one not detected
-by the testsuite), etc should be reported when you discover them, or have a
-suggested patch to fix them.
-
-
-FORMAT FOR PATCHES
-------------------
-
-If you have a fix for a bug, or an enhancement to submit, send your patch to
-Ulrich Drepper <drepper@gnu.org>.  Here are some simple guidelines for
-submitting patches:
-
-    o	Use "unified diffs" for patches.  A typical command for generating
-	context diffs is "diff -ru glibc-old glibc-patched".
-
-    o	Use the "minimalist approach" for patches.  That is, each patch
-	should address only one particular bug, new feature, etc.  Do not
-	save up many unrelated changes and submit them all in one big
-	patch, since in general, the larger the patch the more difficult
-	it is for us to decide if the patch is either correct or
-	desirable.  And if we find something about the patch that needs
-	to be corrected before it can be installed, we would have to reject
-	the entire patch, which might contain changes which otherwise would
-	be accepted if submitted separately.
-
-    o	Submit a sample ChangeLog entry with your patch.  See the existing
-	glibc ChangeLog for examples of what a ChangeLog entry should look
-	like.  The emacs command ^X4A will create a ChangeLog entry header
-	for you.
-
-
-BUILDING SNAPSHOTS
-------------------
-
-The `best' way to build glibc is to use an extra directory, e.g.:
-tar xzf libc-970921.tar.gz
-mkdir build-glibc
-cd build-glibc
-../libc-970921/configure ...
-
-In this way you can easily clean up (since `make clean' doesn't work at
-the moment) and rebuild glibc.
-
-
-NECESSARY TOOLS
----------------
-
-For the recommended versions of gcc, binutils, make, texinfo, gettext,
-autoconf and other tools which might be especially needed when using patches,
-please read the file INSTALL.
-
-
-HOW CAN YOU HELP
-----------------
-
-It helps already a lot if you just install glibc on your system and try to
-solve any problems.  You might want to look at the file `PROJECTS' and help
-with one of those projects, fix some bugs (see `BUGS' or the bug database),
-port to an unsupported platform, ...
-
-
-FURTHER DOCUMENTATION
----------------------
-
-A lot of questions are answered in the FAQ.  The files `INSTALL', `README' and
-`NOTES' contain the most important documentation.  Furthermore glibc has its
-own 700+ pages info documentation, ...
-
-
-
-And finally a word of caution: The libc is one of the most fundamental parts
-of your system - and these snapshots are untested and come without any
-guarantee or warranty.  You might be lucky and everything works or you might
-crash your system.  If you install a glibc snapshot as primary library, you
-should have a backup somewhere.
-
-On many systems it is also a problem to replace the libc while the system is
-running.  In the worst case on broken OSes some systems crash.  On better
-systems you can move the old libc aside but removing it will cause problems
-since there are still processes using this libc image and so you might have to
-check the filesystem to get rid of the libc data.  One good alternative (which
-is also safer) is to use a chroot'ed environment.
-
-Thanks for your help and support.
-
-Thanks to Fred Fish from Cygnus for the original version of this text
-(for GDB).
-
-
-Ulrich Drepper
diff --git a/README.template b/README.template
index 9b300a9226..d501d718df 100644
--- a/README.template
+++ b/README.template
@@ -21,39 +21,12 @@ configurations:
 		s390-*-linux-gnu	Linux-2.x on IBM S/390
 		s390x-*-linux-gnu	Linux-2.4+ on IBM S/390 64-bit
 		sh-*-linux-gnu		Linux-2.x on Super Hitachi
-		cris-*-linux-gnu	Linux-2.4+ on CRIS
 		x86-64-*-linux-gnu	Linux-2.4+ on x86-64
 
-Former releases of this library (version 1.09.1 and perhaps earlier
-versions) used to run on the following configurations:
-
-		alpha-dec-osf1
-		i[3456]86-*-bsd4.3
-		i[3456]86-*-isc2.2
-		i[3456]86-*-isc3
-		i[3456]86-*-sco3.2
-		i[3456]86-*-sco3.2v4
-		i[3456]86-*-sysv
-		i[3456]86-*-sysv4
-		i[3456]86-force_cpu386-none
-		i[3456]86-sequent-bsd
-		i960-nindy960-none
-		m68k-hp-bsd4.3
-		m68k-mvme135-none
-		m68k-mvme136-none
-		m68k-sony-newsos3
-		m68k-sony-newsos4
-		m68k-sun-sunos4
-		mips-dec-ultrix4
-		mips-sgi-irix4
-		sparc-sun-solaris2
-		sparc-sun-sunos4
-
-Since no one has volunteered to test and fix the above configurations,
-these are not supported at the moment.  It's expected that these don't
-work anymore.  Porting the library is not hard.  If you are interested
-in doing a port, please contact the glibc maintainers by sending
-electronic mail to <bug-glibc@gnu.org>.
+Past releases of this library ran on a variety of configurations that are
+no longer supported.  Porting the library is not hard.  If you are
+interested in doing a port, please contact the glibc maintainers;
+see http://www.gnu.org/software/libc/ for more information.
 
 There are some add-ons which can be used together with GNU libc.  They
 are designed in a way to ease the installation by integrating them in
@@ -76,11 +49,9 @@ The file NOTES contains a description of the feature-test macros used
 in the GNU C library, explaining how you can tell the library what
 facilities you want it to make available.
 
-We prefer to get bug reports sent using the `glibcbug' shell script which
-is installed together with the rest of the GNU libc to <bugs@gnu.org>.
-Simply run this shell script and fill in the information.  Nevertheless
-you can still send bug reports to <bug-glibc@gnu.org> as normal electronic
-mails.
+Please see http://www.gnu.org/software/libc/bugs.html for bug reporting
+information.  We are now using the Bugzilla system to track all bug reports.
+This web page gives detailed information on how to report bugs properly.
 
 The GNU C Library is free software.  See the file COPYING.LIB for copying
 conditions, and LICENSES for notices about a few contributions that require
diff --git a/version.h b/version.h
index 07d0ac72f6..4eeb1cceb3 100644
--- a/version.h
+++ b/version.h
@@ -1,4 +1,4 @@
 /* This file just defines the current version number of libc.  */
 
 #define RELEASE "stable"
-#define VERSION "2.3.3"
+#define VERSION "2.3.4"