Skip to content
Snippets Groups Projects
Commit 2895e7f4 authored by Gerard Patel's avatar Gerard Patel Committed by Alexandre Julliard
Browse files

Misc doc updates.

parent 4e2cf00b
No related merge requests found
...@@ -50,7 +50,14 @@ FreeBSD info: ...@@ -50,7 +50,14 @@ FreeBSD info:
Solaris info: Solaris info:
You will most likely need to build Wine with the GNU toolchain 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 Wine requires kernel-level threads to run. Currently, only Linux
version 2.0 or later, FreeBSD-current or FreeBSD 3.0 or later, version 2.0 or later, FreeBSD-current or FreeBSD 3.0 or later,
......
...@@ -5,7 +5,7 @@ ...@@ -5,7 +5,7 @@
<title>How To Report A Bug</title> <title>How To Report A Bug</title>
<para> <para>
Written by &name-gerard-patel; <email>&email-gerard-patel;</email> Written by (???)
</para> </para>
<para> <para>
(Extracted from <filename>wine/documentation/bugreports</filename>) (Extracted from <filename>wine/documentation/bugreports</filename>)
......
...@@ -2,7 +2,7 @@ ...@@ -2,7 +2,7 @@
<title>How to do regression testing using Cvs</title> <title>How to do regression testing using Cvs</title>
<para> <para>
written by (???) written by Gerard Patel
</para> </para>
<para> <para>
(Extracted from <filename>wine/documentation/bugreports</filename>) (Extracted from <filename>wine/documentation/bugreports</filename>)
...@@ -20,8 +20,8 @@ ...@@ -20,8 +20,8 @@
<para> <para>
Get the 'full cvs' archive from winehq. This archive is Get the 'full cvs' archive from winehq. This archive is
the cvs tree but with the tags controlling the versioning 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 when uncompressed, you can't very well do this with
small, old computers or slow Internet connections). small, old computers or slow Internet connections).
</para> </para>
...@@ -31,7 +31,7 @@ ...@@ -31,7 +31,7 @@
untar it into a repository directory: untar it into a repository directory:
<screen> <screen>
cd /home/gerard cd /home/gerard
tar -zxffull-cvs-2000-05-20.tar.gz tar -zxfcvs-dirs-2000-05-20.tar.gz
mv wine repository mv wine repository
</screen> </screen>
</para> </para>
...@@ -53,8 +53,25 @@ ...@@ -53,8 +53,25 @@
<para> <para>
Note that it's not possible to do a checkout at a given Note that it's not possible to do a checkout at a given
date; you always do the checkout for the last date where 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>
<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>
<listitem> <listitem>
<para> <para>
...@@ -63,11 +80,14 @@ ...@@ -63,11 +80,14 @@
Now update this image to the date you want: Now update this image to the date you want:
<screen> <screen>
cd /home/gerard/wine cd /home/gerard/wine
cvs -d $CVSROOT update -D "1999-06-01" cvs -d $CVSROOT update -D "1999-06-01 EDT"
</screen> </screen>
</para> </para>
<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>
<para> <para>
Many messages will inform you that more recent files have Many messages will inform you that more recent files have
...@@ -90,33 +110,6 @@ ...@@ -90,33 +110,6 @@
./configure ./configure
make depend && make make depend && make
</screen> </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> <para>
If any non-programmer reads this, the fastest method to get If any non-programmer reads this, the fastest method to get
at the point where the problem occured is to use a binary at the point where the problem occured is to use a binary
...@@ -124,41 +117,31 @@ ...@@ -124,41 +117,31 @@
mid-year, then is the problem is already here, back to 1st mid-year, then is the problem is already here, back to 1st
April, if not, to 1st October, and so on. April, if not, to 1st October, and so on.
</para> </para>
</listitem>
<listitem>
<para> <para>
The next step is to start from the last working version If you have lot of hard disk free space (a full compile takes
and to dig the individual contributions from currently 400 Mb), copy the oldest known working version before
<ulink url="http://www.integrita.com/cgi-local/lwgate.pl/WINE-PATCHES/"> updating it, it will save time if you need to go back (it's
http://www.integrita.com/cgi-local/lwgate.pl/WINE-PATCHES/</ulink> better to make distclean before going back in time, so you
(where the Wine patches mailing list is archived) have to make everything if you don't backup the older version)
</para> </para>
<para> <para>
If the patch was done by the Wine maintainer or if it was When you have found the day where the problem happened, continue
sent directly to his mail address without going first through the search using the wine-cvs archive (sorted by date) and a
<ulink url="mailto:wine-patches@winehq.com">wine-patches</ulink>, more precise cvs update including hour, minute, second :
you are out of luck as you will never find the patch in <screen>
the archive. If it is, it's often possible to apply the cvs -d $CVSROOT update -D "1999-06-01 15:17:25 EDT"
patches one by one to last working cvs snapshot, compile and test. </screen>
If you have saved the next candidate as This will allow you to find easily the exact patch that did it.
<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>
</listitem>
<listitem>
<para> <para>
If you find one patch that is getting the cvs source tree to If you find the patch that is the cause of the problem, you have
reproduce the problem, you have almost won; post the problem on almost won; report about it on <systemitem>comp.emulators.windows.wine</systemitem>
<systemitem>comp.emulators.windows.wine</systemitem> and there or susbscribe to wine-devel and post it there. There is a chance that the author
is a chance that the author will jump in to suggest a fix; or will jump in to suggest a fix; or there is always the possibility
there is always the possibility to look hard at the patch until to look hard at the patch until it is coerced to reveal where is
it is coerced to reveal where is the bug :-) the bug :-)
</para> </para>
</listitem> </listitem>
</orderedlist> </orderedlist>
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment