Imported Upstream version 2.67.2
[platform/upstream/glib.git] / README
diff --git a/README b/README
index 8fdd724..96dc92f 100644 (file)
--- a/README
+++ b/README
@@ -1,92 +1 @@
-General Information
-===================
-
-This is GLib version 2.5.7. 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.4.0
-======================
-
-* GObject now enforces CONSTRUCT_ONLY properties; due to an oversight
-  in previous versions, it was possible to set CONSTRUCT_ONLY properties
-  after construct time.
-
-* The child watch functionality tends to reveal a bug in many
-  thread implementations (in particular the older LinuxThreads implementation
-  on Linux) where it's not possible to call waitpid() for a child
-  created in a different thread. For this reason, for maximum portability,
-  you should structure your code to fork all child processes that you want
-  to wait for from the main thread.
-
-* A problem was recently discovered with g_signal_connect_object(); 
-  it doesn't actually disconnect the signal handler once the object being 
-  connected to dies, just disables it. See the API docs for the function 
-  for further details and the correct workaround that will continue to 
-  work with future versions of GLib.
-
-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.)
+See README.md