Misc doc updates.

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,

documentation/bugs.sgml

@@ -5,7 +5,7 @@
       <title>How To Report A Bug</title>
 
       <para>
-        Written by &name-gerard-patel; <email>&email-gerard-patel;</email>
+        Written by (???)
       </para>
       <para>
         (Extracted from <filename>wine/documentation/bugreports</filename>)

documentation/cvs-regression.sgml

@@ -2,7 +2,7 @@
     <title>How to do regression testing using Cvs</title>
 
     <para>
-      written by (???)
+      written by Gerard Patel
     </para>
     <para>
       (Extracted from <filename>wine/documentation/bugreports</filename>)
@@ -20,8 +20,8 @@
         <para>
           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
+          system. It's a big file (> 40 meg) with a name like
-          full-cvs-&lt;last update date> (it's more than 100mb
+          wine-cvsdirs-&lt;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).
         </para>
@@ -31,7 +31,7 @@
           untar it into a repository directory:
           <screen>
             cd /home/gerard
-            tar -zxffull-cvs-2000-05-20.tar.gz
+            tar -zxfcvs-dirs-2000-05-20.tar.gz
             mv wine repository
           </screen>
         </para>
@@ -53,8 +53,25 @@
         <para>
           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.
         </para>
+        <para>
+          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.
+        </para>
+        <note>
+          <para>
+            If you use Cvs directly from the winehq.com server, do not
+            forget to add to your <filename>.cvsrc</filename> file:
+          </para>
+          <screen>
+            cvs -z 3
+            update -dPA
+            diff -u
+          </screen>
+         </note>
       </listitem>
       <listitem>
         <para>
@@ -63,11 +80,14 @@
           Now update this image to the date you want:
           <screen>
             cd /home/gerard/wine
-            cvs -d $CVSROOT update -D "1999-06-01"   
+            cvs -d $CVSROOT update -D "1999-06-01 EDT"   
           </screen>
         </para>
         <para>
-          The date format is <literal>YYYY-MM-DD</literal>.
+          The date format is <literal>YYYY-MM-DD HH:MM:SS</literal>.
+          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
         </para>
         <para>
           Many messages will inform you that more recent files have
@@ -90,33 +110,6 @@
           ./configure
           make depend && make
         </screen>
-        <para>
-          When you have found the exact date when a bug was added to
-          the cvs tree, use something like :
-          <screen>
-            cvs -d $CVSROOT diff -D "1999-07-10" -D "1999-07-12"
-          </screen>
-          to get all the differences between the last cvs tree
-          version known to work and code that first displayed the
-          misbehavior.
-        </para>
-        <note>
-          <para>
-            I did not include flags for <command>diff</command>
-            since they are in my <filename>.cvsrc</filename> file:
-          </para>
-          <screen>
-            cvs -z 3
-            update -dPA
-            diff -u
-          </screen>
-        </note>
-        <para>
-          From this diff file, particularly the file names, and the
-          <filename>ChangeLog</filename>, it's usually possible to
-          find the different individual patches that were done at
-          this time. 
-        </para>
         <para>
           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.
         </para>
+        <para>
+          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)
+        </para>
+        <para>  
+          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 :
+          <screen>
+            cvs -d $CVSROOT update -D "1999-06-01 15:17:25 EDT"
+          </screen>
+          This will allow you to find easily the exact patch that did it.
+        </para>
       </listitem>
       <listitem>
         <para>
-          The next step is to start from the last working version
+          If you find the patch that is the cause of the problem, you have
-          and to dig the individual contributions from
+          almost won; report about it on <systemitem>comp.emulators.windows.wine</systemitem>
-          <ulink url="http://www.integrita.com/cgi-local/lwgate.pl/WINE-PATCHES/">
+          or susbscribe to wine-devel and post it there. There is a chance that the author
-            http://www.integrita.com/cgi-local/lwgate.pl/WINE-PATCHES/</ulink>
+          will jump in to suggest a fix; or there is always the possibility
-          (where the Wine patches mailing list is archived)
+          to look hard at the patch until it is coerced to reveal where is
-        </para>
+          the bug :-) 
-        <para>
-          If the patch was done by the Wine maintainer or if it was
-          sent directly to his mail address without going first through 
-          <ulink url="mailto:wine-patches@winehq.com">wine-patches</ulink>,
-          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
-          <filename>/home/gerard/buggedpatch1.txt</filename>:
-        </para>
-        <screen>
-          cd /home/gerard/wine
-          patch -p 0 &lt; /home/gerard/buggedpatch1.txt
-        </screen>
-        <para>
-          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.
-        </para>
-        <para>
-          If you find one patch that is getting the cvs source tree to
-          reproduce the problem, you have almost won; post the problem on
-          <systemitem>comp.emulators.windows.wine</systemitem> 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 :-) 
         </para>
       </listitem>
     </orderedlist>