Imported v0.62 tag from svn://svn.tartarus.org/sgt/putty-0.62

Buildscr

@@ -0,0 +1,120 @@
+# -*- sh -*-
+# Build script to construct a full distribution directory of PuTTY.
+
+module putty
+
+# Set up the arguments for the main make command.
+set Makever -DSVN_REV=$(revision)
+ifneq "$(!numeric $(revision))" "yes" set Makever $(Makever) -DMODIFIED
+ifneq "$(RELEASE)" "" set Makever $(Makever) -DRELEASE=$(RELEASE)
+ifneq "$(PRERELEASE)" "" set Makever $(Makever) -DPRERELEASE=$(PRERELEASE)
+ifneq "$(date)" "" set Makever $(Makever) -DSNAPSHOT=$(date)
+set Makeargs VER="$(Makever)"
+ifneq "$(XFLAGS)" "" set Makeargs $(Makeargs) XFLAGS="$(XFLAGS)"
+ifneq "$(MAKEARGS)" "" set Makeargs $(Makeargs) $(MAKEARGS)
+
+# Set up the version string for the docs build.
+set Docmakeargs VERSION="PuTTY revision $(revision)"
+ifneq "$(RELEASE)" "" set Docmakeargs VERSION="PuTTY release $(RELEASE)"
+ifneq "$(PRERELEASE)" "" set Docmakeargs VERSION="PuTTY pre-release $(PRERELEASE):r$(revision)"
+ifneq "$(date)" "" set Docmakeargs VERSION="PuTTY development snapshot $(date)"
+
+# Set up the version string for the Unix source archive.
+set Unxver r$(revision)
+ifneq "$(RELEASE)" "" set Unxver $(RELEASE)
+ifneq "$(PRERELEASE)" "" set Unxver $(PRERELEASE)pre $(revision)
+ifneq "$(date)" "" set Unxver $(date)
+
+# Set up the various version strings for the installer.
+set Iversion r$(revision)
+set Iname PuTTY revision $(revision)
+set Ivertext Revision $(revision)
+set Irev $(revision)
+set Ifilename putty-$(Iversion)-installer.exe
+ifneq "$(RELEASE)" "" set Iversion $(RELEASE)
+ifneq "$(RELEASE)" "" set Iname PuTTY version $(RELEASE)
+ifneq "$(RELEASE)" "" set Ivertext Release $(RELEASE)
+ifneq "$(RELEASE)" "" set Irev 0
+ifneq "$(RELEASE)" "" set Ifilename putty-$(RELEASE)-installer.exe
+ifneq "$(PRERELEASE)" "" set Iversion $(PRERELEASE):r$(revision)
+ifneq "$(PRERELEASE)" "" set Iname PuTTY pre-release $(PRERELEASE):r$(revision)
+ifneq "$(PRERELEASE)" "" set Ivertext Pre-release $(PRERELEASE):r$(revision)
+ifneq "$(PRERELEASE)" "" set Ifilename putty-$(PRERELEASE)-pre$(revision)-installer.exe
+ifneq "$(date)" "" set Iversion $(date):r$(revision)
+ifneq "$(date)" "" set Iname PuTTY development snapshot $(date):r$(revision)
+ifneq "$(date)" "" set Ivertext Development snapshot $(date):r$(revision)
+ifneq "$(date)" "" set Ifilename putty-$(date)-installer.exe
+
+in putty do ./mksrcarc.sh
+in putty do ./mkunxarc.sh $(Unxver)
+in putty do perl mkfiles.pl
+in putty/doc do make $(Docmakeargs) putty.hlp
+in putty/doc do make $(Docmakeargs) chm
+
+# Munge the installer script locally so that it reports the version
+# we're really building.
+in putty/windows do perl -i~ -pe 'BEGIN{$$a=shift@ARGV;}s/^(AppVerName=).*$$/$$1$$a/' '$(Iname)' putty.iss
+in putty/windows do perl -i~ -pe 'BEGIN{$$a=shift@ARGV;}s/^(VersionInfoTextVersion=).*$$/$$1$$a/' '$(Ivertext)' putty.iss
+in putty/windows do perl -i~ -pe 'BEGIN{$$a=shift@ARGV;}s/^(AppVersion=).*$$/$$1$$a/' '$(Iversion)' putty.iss
+in putty/windows do perl -i~ -pe 'BEGIN{$$a=shift@ARGV;$$a=~s/M//;}s/^(VersionInfoVersion=\d+\.\d+\.)\d+(\.\d+)\r?$$/$$1$$a$$2/' '$(Irev)' putty.iss
+
+# Windowsify LICENCE, since it's going in the Windows installer.
+in putty do perl -i~ -pe 'y/\015//d;s/$$/\015/' LICENCE
+
+delegate windows
+  # FIXME: Cygwin alternative?
+  in putty/windows do cmd /c vcvars32 \& nmake -f Makefile.vc $(Makeargs)
+  # Ignore exit code from hhc, in favour of seeing whether the .chm
+  # file was created. (Yuck; but hhc appears to return non-zero
+  # exit codes on whim.)
+  in putty/doc do hhc putty.hhp; test -f putty.chm
+  in putty/windows do iscc putty.iss
+  return putty/windows/*.exe
+  return putty/windows/*.map
+  return putty/doc/putty.chm
+  return putty/windows/Output/setup.exe
+enddelegate
+in putty/doc do make mostlyclean
+in putty/doc do make $(Docmakeargs)
+in putty/windows do zip -k -j putty.zip `ls *.exe | grep -v puttytel` ../doc/putty.chm ../doc/putty.hlp ../doc/putty.cnt
+in putty/doc do zip puttydoc.zip *.html
+
+# Deliver the actual PuTTY release directory into a subdir `putty'.
+deliver putty/windows/*.exe putty/x86/$@
+deliver putty/windows/putty.zip putty/x86/$@
+deliver putty/windows/Output/setup.exe putty/x86/$(Ifilename)
+deliver putty/doc/puttydoc.zip putty/$@
+deliver putty/doc/putty.chm putty/$@
+deliver putty/doc/putty.hlp putty/$@
+deliver putty/doc/putty.cnt putty/$@
+deliver putty/doc/puttydoc.txt putty/$@
+deliver putty/doc/*.html putty/htmldoc/$@
+deliver putty/putty-src.zip putty/$@
+deliver putty/*.tar.gz putty/$@
+
+# Deliver the map files alongside the `proper' release deliverables.
+deliver putty/windows/*.map maps-x86/$@
+
+# Deliver sign.sh, so that whoever has just built PuTTY (the
+# snapshot scripts or me, depending) can conveniently sign it with
+# whatever key they want.
+deliver putty/sign.sh $@
+
+# Create files of cryptographic checksums, which will be signed along
+# with the files they verify. We've provided MD5 checksums for a
+# while, but now MD5 is looking iffy, we're expanding our selection.
+#
+# Creating these files is most easily done in the destination
+# directory, where all the files we're delivering are already in their
+# final relative layout.
+in-dest putty do a=`\find * -type f -print`; md5sum $$a > md5sums && sha1sum $$a > sha1sums && sha256sum $$a > sha256sums && sha512sum $$a > sha512sums
+
+# And construct .htaccess files. One in the top-level directory,
+# setting the MIME types for Windows help files and providing an
+# appropriate link to the source archive:
+in-dest putty do echo "AddType application/octet-stream .chm" >> .htaccess
+in-dest putty do echo "AddType application/octet-stream .hlp" >> .htaccess
+in-dest putty do echo "AddType application/octet-stream .cnt" >> .htaccess
+in-dest putty do set -- putty*.tar.gz; for k in '' .DSA .RSA; do echo RedirectMatch temp '(.*/)'putty.tar.gz$$k\$$ '$$1'"$$1$$k" >> .htaccess; done
+# And one in the x86 directory, providing a link for the installer.
+in-dest putty/x86 do set -- putty*installer.exe; for k in '' .DSA .RSA; do echo RedirectMatch temp '(.*/)'putty-installer.exe$$k\$$ '$$1'"$$1$$k" >> .htaccess; done

CHECKLST.txt

@@ -0,0 +1,196 @@
+Checklists for PuTTY administrative procedures
+==============================================
+
+Locations of the licence
+------------------------
+
+The PuTTY copyright notice and licence are stored in quite a few
+places. At the start of a new year, the copyright year needs
+updating in all of them; and when someone sends a massive patch,
+their name needs adding in all of them too.
+
+The LICENCE file in the main source distribution:
+
+ - putty/LICENCE
+
+The resource files:
+
+ - putty/windows/pageant.rc
+    + the copyright date appears twice, once in the About box and
+      once in the Licence box. Don't forget to change both!
+ - putty/windows/puttygen.rc
+    + the copyright date appears twice, once in the About box and
+      once in the Licence box. Don't forget to change both!
+ - putty/windows/win_res.rc2
+    + the copyright date appears twice, once in the About box and
+      once in the Licence box. Don't forget to change both!
+ - putty/windows/version.rc2
+    + the copyright date appears once only.
+ - putty/unix/gtkdlg.c
+    + the copyright date appears twice, once in the About box and
+      once in the Licence box. Don't forget to change both!
+
+The documentation (both the preamble blurb and the licence appendix):
+
+ - putty/doc/blurb.but
+ - putty/doc/licence.but
+
+The website:
+
+ - putty-website/licence.html
+
+Before tagging a release
+------------------------
+
+ - First of all, go through the source (including the documentation),
+   and the website, and review anything tagged with a comment
+   containing the word XXX-REVIEW-BEFORE-RELEASE.
+   (Any such comments should state clearly what needs to be done.)
+
+ - Also, do some testing of the Windows version with Minefield, and
+   of the Unix version with valgrind or efence or both. In
+   particular, any headline features for the release should get a
+   workout with memory checking enabled!
+
+For a long time we got away with never checking the current version
+number in at all - all version numbers were passed into the build
+system on the compiler command line, and the _only_ place version
+numbers showed up in the source files was in the tag information.
+
+Unfortunately, those halcyon days are gone, and we do need the
+version number checked in in a couple of places. These must be updated
+_before_ tagging a new release.
+
+The file used to generate the Unix snapshot version numbers (which
+are <previousrelease>-<date> so that the Debian versioning system
+orders them correctly with respect to releases):
+
+ - putty/LATEST.VER
+
+The Windows installer script (_four_ times, on consecutive lines):
+
+ - putty/windows/putty.iss
+
+The Windows resource file (used to generate the binary bit of the
+VERSIONINFO resources -- the strings are supplied by the usual means):
+
+ - putty/windows/version.rc2 (BASE_VERSION; NB, _comma_-separated)
+
+It might also be worth going through the documentation looking for
+version numbers - we have a couple of transcripts showing the help
+text from the command-line tools, and it would be nice to ensure the
+whole transcripts (certainly including the version numbers) are up
+to date. Sometimes these are marked in between releases as `0.XX', so
+it's worth grepping for that too.
+
+ - putty/doc/pscp.but
+ - putty/doc/plink.but
+ - putty/doc/psftp.but (in case it ever acquires a similar thing)
+
+The actual release procedure
+----------------------------
+
+This is the procedure I (SGT) currently follow (or _should_ follow
+:-) when actually making a release, once I'm happy with the position
+of the tag.
+
+ - Double-check that we have removed anything tagged with a comment
+   containing the words XXX-REMOVE-BEFORE-RELEASE or
+   XXX-REVIEW-BEFORE-RELEASE.
+
+ - Write a release announcement (basically a summary of the changes
+   since the last release). Squirrel it away in
+   atreus:src/putty/local/announce-<ver> in case it's needed again
+   within days of the release going out.
+
+ - Build the release: `bob putty-0.XX RELEASE=0.XX'. This should
+   generate a basically valid release directory as
+   `build.out/putty', and provide link maps and sign.sh alongside
+   that in build.out.
+
+ - Do a bit of checking that the release binaries basically work,
+   report their version numbers accurately, and so on. Test the
+   installer and the Unix source tarball.
+
+ - Save the link maps. Currently I keep these on atreus, in
+   src/putty/local/maps-<version>.
+
+ - Sign the release: in the `build.out' directory, type `./sign.sh
+   putty Releases', and enter the passphrases a lot of times.
+
+ - Now the whole release directory should be present and correct.
+   Upload it to atreus:www/putty/<ver>.
+
+ - Do final checks on the release directory:
+    + verify all the signatures:
+      for i in `find . -name '*.*SA'`; do case $i in *sums*) gpg --verify $i;; *) gpg --verify $i ${i%%.?SA};; esac; done
+    + check the checksum files:
+      md5sum -c md5sums
+      sha1sum -c sha1sums
+      sha256sum -c sha256sums
+      sha512sum -c sha512sums
+
+ - Having double-checked the release, copy it from atreus to
+   chiark:ftp/putty-<ver> and to the:www/putty/<ver>.
+
+ - Check the permissions! Actually try downloading from the, to make
+   sure it really works.
+
+ - Update the HTTP redirects.
+    + Update the one at the:www/putty/htaccess which points the
+      virtual subdir `latest' at the actual latest release dir. TEST
+      THIS ONE - it's quite important.
+    + atreus:www/putty/.htaccess has an individual redirect for each
+      version number. Add a new one.
+
+ - Update the FTP symlink (chiark:ftp/putty-latest -> putty-<ver>).
+
+ - Update web site.
+   + Adjust front page to say 'The latest version is <ver>'.
+   + Adjust front page to add a news item.
+   + Adjust Download page to say 'The latest release version (<ver>)'.
+   + Adjust Download page to update filenames of installer and Unix
+     tarball (both in the hrefs themselves and the link text).
+   + Check over the Download page and remove any mention of
+     pre-releases, if there were any before this release. Comment out
+     the big pre-release section at the top, and also adjust the
+     sections about source archives at the bottom.
+   + Adjust header text on Changelog page. (That includes changing
+     `are new' in previous version to `were new'!)
+
+ - Update the wishlist. This can be done without touching individual
+   items by editing the @releases array in control/bugs2html.
+
+ - Check the Docs page links correctly to the release docs. (It
+   should do this automatically, owing to the `latest' HTTP
+   redirect.)
+
+ - Check that the web server attaches the right content type to .HLP
+   and .CNT files.
+
+ - Run webupdate, so that all the changes on atreus propagate to
+   chiark. Important to do this _before_ announcing that the release
+   is available.
+
+ - After running webupdate, run update-rsync on chiark and verify that
+   the rsync mirror package (~/ftp/putty-website-mirror) contains a
+   subdirectory for the new version and mentions it in its .htaccess.
+
+ - Announce the release!
+    + Mail the announcement to <[email protected]>.
+       * Put a 'Reply-To: [email protected]' header on the
+	 mail so that people don't keep replying to my personal
+	 address.
+    + Post it to comp.security.ssh.
+    + Mention it in <TDHTT> on mono.
+
+ - Relax (slightly).
+
+After the release
+-----------------
+
+The following want doing some time soon after a release has been made:
+
+ - If the release was made from a branch, make sure the version number
+   on the _trunk_ is up to date in all the locations listed above, so
+   that (e.g.) Unix snapshots come out right.

LATEST.VER

@@ -0,0 +1 @@
+0.62

LICENCE

@@ -0,0 +1,25 @@
+PuTTY is copyright 1997-2011 Simon Tatham.
+
+Portions copyright Robert de Bath, Joris van Rantwijk, Delian
+Delchev, Andreas Schultz, Jeroen Massar, Wez Furlong, Nicolas Barry,
+Justin Bradford, Ben Harris, Malcolm Smith, Ahmad Khalifa, Markus
+Kuhn, Colin Watson, and CORE SDI S.A.
+
+Permission is hereby granted, free of charge, to any person
+obtaining a copy of this software and associated documentation files
+(the "Software"), to deal in the Software without restriction,
+including without limitation the rights to use, copy, modify, merge,
+publish, distribute, sublicense, and/or sell copies of the Software,
+and to permit persons to whom the Software is furnished to do so,
+subject to the following conditions:
+
+The above copyright notice and this permission notice shall be
+included in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+NONINFRINGEMENT.  IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE
+FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF
+CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.