and 'ec72b34db00b2e5880f02e321a040b625907cc27'

Add another commented example to wrapper.config for those instances in which bindipv6only causes problems

Windows Uninstall the service if I2P is installed, whether the service was enabled by the installer or not.

My rationale for this:
1) in case someone is installing I2P on top of an already existing installation
   this will cause I2P to be shutdown
2) no hangs during the installation if i2p is already installed as a service
3) in case the NT service settings are changed in wrapper.config by us, this
   will force the service settings to be updated.
4) versions of I2P < 0.8.7 did not remove the service when uninstalling. If someone
   removed I2P in the past and reinstalls I2P--opting to run as a service--the
   installation process will hang.

            This will force a reextraction by CPUID and NBI.

    jbigi and wrapper files for arm.
    Compiled on trimslice with gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5) 
    Log postinstall errors to postinstall.log.
    java version "1.6.0_18"
    OpenJDK Runtime Environment (IcedTea6 1.8.7) (6b18-1.8.7-0ubuntu2.1)
    OpenJDK Zero VM (build 14.0-b16, mixed mode)
    GMP 4.3.2 (half the size of 5.0.2, and no speed difference) LGPLv3
    Wrapper 3.5.9 GPLv2
    All binaries stripped.

    As on the Android emulator, the stock BigInteger.modPow()
    has some serious bug on arm.
    Without the libjbigi checked in here, the JVM crashes almost immediately.

     and 'edb2bfcff621cb4739bdf41520580e3f57bb1b2a'

With this checkin I'm trying to lessen the occurences of ticket #474:

If a user installs I2P on top of an already existing I2P installation with the service
enabled, the installer will hang. The Quit button cannot be clicked. Clicking
the X in the corner seems to roll back the installation.

Also #472: service is not removed when I2P is uninstalled

     and 'a9936ae0cadad0b2bb646c9af046b32f3c497188'

  you don't have gettext and want the build to continue.

  to do the first time that I noticed I added these files with those unneccesry
  attributes.
* Set the "manual merge" attribute on these files.

working directory set to $INSTALL_DIR, C:\Program Files\I2P is not removed in
XP.

...but even with the working directory removed, the the Uninstaller folder is left
within $INSTALL_DIR in Windows 7.

for use with a 32 bit JRE.

Rationale:
On an x64 system using a 32 bit jvm Without the 32 bit libwrapper, messages
like this will be shown in wrapper.log with the wrapper in MTN & I2P >= 0.8.7:

-----------------------
 Launching a JVM...
 WrapperManager: Initializing...
 WrapperManager: 
 WrapperManager: WARNING - Unable to load the Wrapper's native library 'libwrapper.so'.
 WrapperManager:           The file is located on the path at the following location but
 WrapperManager:           could not be loaded:
 WrapperManager:             $I2P/lib/libwrapper.so
 WrapperManager:           Please verify that the file is both readable and executable by the
 WrapperManager:           current user and that the file has not been corrupted in any way.
 WrapperManager:           One common cause of this problem is running a 32-bit version
 WrapperManager:           of the Wrapper with a 64-bit version of Java, or vica versa.
 WrapperManager:           This is a 32-bit JVM.
 WrapperManager:           Reported cause:
 WrapperManager:             $I2P/lib/libwrapper.so: $I2P/lib/libwrapper.so: 
                           wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch)
 WrapperManager:           System signals will not be handled correctly.
-----------------------

With libwrapper.so removed, one sees the following:

 WrapperManager: WARNING - Unable to load the Wrapper's native library because none of the
 WrapperManager:           following files:
 WrapperManager:             libwrapper-linux-x86-32.so
 WrapperManager:             libwrapper.so
 WrapperManager:           could be located on the following java.library.path:
 WrapperManager:             $I2P
 WrapperManager:             $I2P/lib
 WrapperManager:           Please see the documentation for the wrapper.java.library.path
 WrapperManager:           configuration property.
 WrapperManager:           System signals will not be handled correctly.
-----------------------

The 32 bit lib names, when installed on an x64 system, will match the alternate
names that the wrapper looks for.