From 2895e7f4fa869f6f8c4df4b3d4ce022394995656 Mon Sep 17 00:00:00 2001 From: Gerard Patel Date: Tue, 16 Oct 2001 21:47:51 +0000 Subject: [PATCH] Misc doc updates. --- README | 9 ++- documentation/bugs.sgml | 2 +- documentation/cvs-regression.sgml | 115 +++++++++++++----------------- 3 files changed, 58 insertions(+), 68 deletions(-) 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 :-)