luc14n0/glib
1
0
Fork 0
mirror of https://gitlab.gnome.org/GNOME/glib.git synced 2025-09-07 08:28:43 +02:00
Code Issues Packages Projects Releases Wiki Activity

Remove warnings about conflicts with the stable version.

Browse Source 
Mon Apr 16 12:04:52 2001  Owen Taylor  <otaylor@redhat.com>

        * configure.in: Remove warnings about conflicts with the
        stable version.

	 * glib-2.0.m4: Fix some of the error text to be halfway
        up to date.

        * README.in INSTALL.in: Add these to generate README, INSTAL
        (as in the stable branch). Update.

	  * HACKING: Update.
This commit is contained in:
Owen Taylor
2001-04-17 00:55:34 +00:00
committed by Owen Taylor
parent 4eab875811
commit 525689823d
18 changed files with 322 additions and 72 deletions
Download Patch File Download Diff File Expand all files Collapse all files

54
README
View File

@@ -7,24 +7,13 @@ 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
This is GLib version 1.3.4. GLib is a library which includes support
routines for C such as lists, trees, hashes, memory allocation, and
many other things.
@@ -34,12 +23,11 @@ The official ftp site is:
The official web site is:
http://www.gtk.org/
A mailing list is located at:
gtk-list@redhat.com
To subscribe: mail -s subscribe gtk-list-request@redhat.com < /dev/null
(Send mail to gtk-list-request@redhat.com with the subject "subscribe")
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
============
@@ -49,26 +37,23 @@ See the file 'INSTALL'
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.
@@ -82,9 +67,16 @@ In the mail include:
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.
If the patch fixes a bug, it is usually a good idea to include
all the information described in "How to Report Bugs".
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.)