- *** IMPORTANT ***
-
-This is a development version of GLib. You should be using a stable
-version, which is available at ftp://ftp.gtk.org/pub/gtk/v1.2/. This
-version is meant for developers of GLib only:
-
- * You should not base stable software on this version of GLib.
- * GNOME developers should use a stable version of GLib.
-
-Distributions should *NOT* ship a development package of this GLib.
-Do not ship the headers and do not ship the glib-config script. These
-things will conflict with the stable 1.2 series. Package only enough
-to satisfy the requirements of some other package. Package only the
-library itself. Doing otherwise will do no favors to the community.
-
-If you install this version of GLib, we strongly recommend that you
-install it in a different prefix than GLib 1.2. Use --prefix as an
-argument to configure to do this. Otherwise, you will not be able to
-do development with GLib 1.2 any longer.
-
-*** You should be using GLib 1.2 instead. ***
-
-
General Information
===================
-This is GLib version 1.3.1. GLib is a library which includes support
-routines for C such as lists, trees, hashes, memory allocation, and
-many other things.
+This is GLib version 2.0.1. GLib is the low-level core
+library that forms the basis for projects such as GTK+ and GNOME. It
+provides data structure handling for C, portability wrappers, and
+interfaces for such runtime functionality as an event loop, threads,
+dynamic loading, and an object system.
The official ftp site is:
ftp://ftp.gtk.org/pub/gtk
The official web site is:
http://www.gtk.org/
-A mailing list is located at:
- gtk-list@redhat.com
+Information about mailing lists can be found at
+ http://www.gtk.org/mailinglists.html
-To subscribe: mail -s subscribe gtk-list-request@redhat.com < /dev/null
-(Send mail to gtk-list-request@redhat.com with the subject "subscribe")
+To subscribe: mail -s subscribe gtk-list-request@gnome.org < /dev/null
+(Send mail to gtk-list-request@gnome.org with the subject "subscribe")
Installation
============
See the file 'INSTALL'
+Notes about GLib-2.0.0
+======================
+
+* On systems without the libintl from GNU gettext() or a recent version
+ of the GNU C library, the encoding of translated error messages will be
+ incorrect (they should be in UTF-8). A workaround for this is to install
+ GNU gettext and use that libintl. This is expected to be fixed in GLib-2.0.1.
+ Application programmers should not call g_locale_to_utf8() on these
+ strings.
+
+* Similarly, the GLib error logging functions such as g_print(), g_warning(),
+ g_error(), currently do not convert the strings they are passed from
+ UTF-8 to the encoding of the locale, or check that the strings they
+ are passed are valid UTF-8. They should, despite this, be assumed to take
+ UTF-8 arguments.
+
+
How to report bugs
==================
-To report a bug, send mail either to gtk-list, as mentioned
-above, or to gtk-bugs@gtk.org. If you send mail to gtk-list, you
-must be subscribed yourself.
+Bugs should be reported to the GNOME bug tracking system.
+(http://bugzilla.gnome.org, product glib.) You will need
+to create an account for yourself.
-In the mail include:
-
-* The version of GLib
+In the bug report please include:
* Information about your system. For instance:
- What operating system and version
- - What version of X
- For Linux, what version of the C library
And anything else you think is relevant.
* How to reproduce the bug.
- If you can reproduce it with the testglib program that is built
- in the glib/ directory, that will be most convenient. Otherwise,
+ If you can reproduce it with the testgtk program that is built
+ in the gtk/ subdirectory, that will be most convenient. Otherwise,
please include a short test program that exhibits the behavior.
As a last resort, you can also provide a pointer to a larger piece
of software that can be downloaded.
Patches
=======
-Patches can be uploaded to the incoming/ directory on
-ftp.gtk.org. Please follow the instructions there, and include
-your name and email address in the README file.
+Patches should also be submitted to bugzilla.gnome.org. If the
+patch fixes an existing bug, add the patch as an attachment
+to that bug report.
+
+Otherwise, enter a new bug report that describes the patch,
+and attach the patch to that bug report.
+
+Bug reports containing patches should include the PATCH keyword
+in their keyword fields. If the patch adds to or changes the GLib
+programming interface, the API keyword should also be included.
-If the patch fixes a bug, it is usually a good idea to include
-all the information described in "How to Report Bugs".
+Patches should be in unified diff form. (The -u option to GNU
+diff.)