on success, close the pipes from the child. Fix from Tim.

[platform/upstream/glib.git] / README

diff --git a/README b/README
index e69de29..a593d4d 100644 (file)
--- a/README
+++ b/README
@@ -0,0 +1,89 @@
+General Information
+===================
+
+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/
+
+Information about mailing lists can be found at
+  http://www.gtk.org/mailinglists.html
+
+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
+==================
+
+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 bug report please include:
+
+* Information about your system. For instance:
+
+   - What operating system and version
+   - 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 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.
+
+* If the bug was a crash, the exact text that was printed out
+  when the crash occured.
+
+* Further information such as stack traces may be useful, but
+  is not necessary.
+
+Patches
+=======
+
+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.
+
+Patches should be in unified diff form. (The -u option to GNU
+diff.)