diff --git a/README b/README
index 17e6072451e..6752555a270 100644
--- a/README
+++ b/README
@@ -50,7 +50,14 @@ FreeBSD info:
Solaris info:
You will most likely need to build Wine with the GNU toolchain
- (gcc, gas, etc.)
+ (gcc, gas, etc.). Warning : installing gas does *not* ensure that it
+ will be used by gcc. Recompiling gcc after installing gas or
+ symlinking cc, as and ld to the gnu tools is said to be necessary.
+
+File systems info :
+ Wine should run on most file systems. However, Wine will fail to start
+ if umsdos is used for the /tmp directory. A few compatibility problems have
+ also been reported using files accessed through Samba.
Wine requires kernel-level threads to run. Currently, only Linux
version 2.0 or later, FreeBSD-current or FreeBSD 3.0 or later,
diff --git a/documentation/bugs.sgml b/documentation/bugs.sgml
index d96fe59a70a..dcc6bf722c5 100644
--- a/documentation/bugs.sgml
+++ b/documentation/bugs.sgml
@@ -5,7 +5,7 @@
How To Report A Bug
- Written by &name-gerard-patel; &email-gerard-patel;
+ Written by (???)
(Extracted from wine/documentation/bugreports)
diff --git a/documentation/cvs-regression.sgml b/documentation/cvs-regression.sgml
index 9f2a2f585fd..1871db84ee8 100644
--- a/documentation/cvs-regression.sgml
+++ b/documentation/cvs-regression.sgml
@@ -2,7 +2,7 @@
How to do regression testing using Cvs
- written by (???)
+ written by Gerard Patel
(Extracted from wine/documentation/bugreports)
@@ -20,8 +20,8 @@
Get the 'full cvs' archive from winehq. This archive is
the cvs tree but with the tags controlling the versioning
- system. It's a big file (> 15 meg) with a name like
- full-cvs-<last update date> (it's more than 100mb
+ system. It's a big file (> 40 meg) with a name like
+ wine-cvsdirs-<last update date> (it's more than 100mb
when uncompressed, you can't very well do this with
small, old computers or slow Internet connections).
@@ -31,7 +31,7 @@
untar it into a repository directory:
cd /home/gerard
- tar -zxffull-cvs-2000-05-20.tar.gz
+ tar -zxfcvs-dirs-2000-05-20.tar.gz
mv wine repository
@@ -53,8 +53,25 @@
Note that it's not possible to do a checkout at a given
date; you always do the checkout for the last date where
- the full-cvs-xxx snapshot was generated.
+ the wine-cvsdirs-xxx snapshot was generated.
+
+ Note also that it is possible to do all this with a direct
+ Cvs connection, of course. The full cvs file method is less
+ painful for the winehq cvs server and probably a bit faster
+ if you don't have a very good net connection.
+
+
+
+ If you use Cvs directly from the winehq.com server, do not
+ forget to add to your .cvsrc file:
+
+
+ cvs -z 3
+ update -dPA
+ diff -u
+
+
@@ -63,11 +80,14 @@
Now update this image to the date you want:
cd /home/gerard/wine
- cvs -d $CVSROOT update -D "1999-06-01"
+ cvs -d $CVSROOT update -D "1999-06-01 EDT"
- The date format is YYYY-MM-DD.
+ The date format is YYYY-MM-DD HH:MM:SS.
+ Using the EDT date format ensure that you will be able to
+ extract patches in a way that will be compatible with the
+ wine-cvs archive : http://www.winehq.com/hypermail/wine-cvs
Many messages will inform you that more recent files have
@@ -90,33 +110,6 @@
./configure
make depend && make
-
- When you have found the exact date when a bug was added to
- the cvs tree, use something like :
-
- cvs -d $CVSROOT diff -D "1999-07-10" -D "1999-07-12"
-
- to get all the differences between the last cvs tree
- version known to work and code that first displayed the
- misbehavior.
-
-
-
- I did not include flags for diff
- since they are in my .cvsrc file:
-
-
- cvs -z 3
- update -dPA
- diff -u
-
-
-
- From this diff file, particularly the file names, and the
- ChangeLog, it's usually possible to
- find the different individual patches that were done at
- this time.
-
If any non-programmer reads this, the fastest method to get
at the point where the problem occured is to use a binary
@@ -124,41 +117,31 @@
mid-year, then is the problem is already here, back to 1st
April, if not, to 1st October, and so on.
+
+ If you have lot of hard disk free space (a full compile takes
+ currently 400 Mb), copy the oldest known working version before
+ updating it, it will save time if you need to go back (it's
+ better to make distclean before going back in time, so you
+ have to make everything if you don't backup the older version)
+
+
+ When you have found the day where the problem happened, continue
+ the search using the wine-cvs archive (sorted by date) and a
+ more precise cvs update including hour, minute, second :
+
+ cvs -d $CVSROOT update -D "1999-06-01 15:17:25 EDT"
+
+ This will allow you to find easily the exact patch that did it.
+
- The next step is to start from the last working version
- and to dig the individual contributions from
-
- http://www.integrita.com/cgi-local/lwgate.pl/WINE-PATCHES/
- (where the Wine patches mailing list is archived)
-
-
- If the patch was done by the Wine maintainer or if it was
- sent directly to his mail address without going first through
- wine-patches,
- you are out of luck as you will never find the patch in
- the archive. If it is, it's often possible to apply the
- patches one by one to last working cvs snapshot, compile and test.
- If you have saved the next candidate as
- /home/gerard/buggedpatch1.txt:
-
-
- cd /home/gerard/wine
- patch -p 0 < /home/gerard/buggedpatch1.txt
-
-
- Beware that the committed patch is not always identical to
- the patch that the author sent to wine-patches, as
- sometimes the Wine maintainer changes things a bit.
-
-
- If you find one patch that is getting the cvs source tree to
- reproduce the problem, you have almost won; post the problem on
- comp.emulators.windows.wine and there
- is a chance that the author will jump in to suggest a fix; or
- there is always the possibility to look hard at the patch until
- it is coerced to reveal where is the bug :-)
+ If you find the patch that is the cause of the problem, you have
+ almost won; report about it on comp.emulators.windows.wine
+ or susbscribe to wine-devel and post it there. There is a chance that the author
+ will jump in to suggest a fix; or there is always the possibility
+ to look hard at the patch until it is coerced to reveal where is
+ the bug :-)