forked from Mirrors/wine-wine
Misc doc updates.
Gerard Patel
Alexandre Julliard
parent
4e2cf00b24
commit
2895e7f4fa
9
README
9
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,
|
||||
|
|
|
|||
|
|
@ -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>)
|
||||
|
|
|
|||
|
|
@ -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
|
||||
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).
|
||||
</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
|
||||
and to dig the individual contributions from
|
||||
<ulink url="http://www.integrita.com/cgi-local/lwgate.pl/WINE-PATCHES/">
|
||||
http://www.integrita.com/cgi-local/lwgate.pl/WINE-PATCHES/</ulink>
|
||||
(where the Wine patches mailing list is archived)
|
||||
</para>
|
||||
<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 < /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 :-)
|
||||
If you find the patch that is the cause of the problem, you have
|
||||
almost won; report about it on <systemitem>comp.emulators.windows.wine</systemitem>
|
||||
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 :-)
|
||||
</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
|
|
|||
Loading…
Reference in New Issue