Re: Making xemacs-21.5.3+/i686-pc-cygwin

APA> Just include the date, time, and timezone of your CVS update. Why make us do the work of the CVS diff by guessing, when he can give us an exact one? What I would do is first cvs diff -u which gives working file against HEAD, assuming you have no sticky tags. If that is not empty, cvs update and rebuild. If it is empty, cvs diff -u -r r21-5-latest-beta gives the state of your working directory relative to the last beta release (assuming I'm doing the releases correctly, which I believe is now the case ;-). This will actually include the release banner from the ChangeLogs (unless it's empty), so it completely identifies the state of your sources, including any local changes you have (perhaps inadvertantly) made. I don't recommend that you send it unless requested, unless it's pretty small. If it is large you may want to limit it to specific files (eg, the ones you're bombing on and their .h's). Also, if you know where you're bombing, you can do "cvs annotate $file". Each line will say who last checked in a change to it, and which version. If it's a recent version, you might want to cc the responsible developer, especially if they're not very active on the beta list. (Exception: don't write to me for 21.4, Vin Shelton for 21.1, Steve Youngs for packages, or Steve Baur for anything, because we check in everything for our branches, even if approved by other reviewers; in Steve's case, he checked in absolutely everything up to about two years ago.) Be judicious about both including big diffs and direct mail to developers, of course. It's usually true that pretty much any core developer can fix compile problems, if reproducible. So normally a report to -beta or -nt should be enough. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."