General Information
===================
-This is GLib version 1.1.12. GLib, is a library which includes support
-routines for C such as lists, trees, hashes, memory allocation, and
-many other things.
-
-Versions of GLib prior to 1.1.0 are distributed with GTK+ versions prior
-to 1.1.0.
+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.
-
-In the mail include:
+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.
-* 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.)
projects / platform / upstream / glib.git / blobdiff