With this check-in I'm adding the EXTRAVERSION to our javadocs and the custom
installer targets (if EXTRAVERSION is set in RouterVersion.java). Also,
i2pinstall*jar and i2pinstall.bz2 will be removed when ant clean is run.
When zipping with infozip, executable permissions are left intact. When zip is
called with ant, these permissions are lost. When tarring using ant the
permissions seem to be lost too. Switching to calling tar directly ensures that
the executable permissions aren't lost.
Instead of deleting debian/copyright with "ant clean", add it to .mtn-ignore.
With the current method, the copyright file doesn't end up in the debian source
package...
- Fix Polish po file
- Install as a service by default on Windows again
- Change CPUID getters to package private
- Split new jbigi install messages into two lines
- Javadocs
Add an icon (in OSX parlance, a 'bundle') to the installation folder to start
I2P.
While there might be a better way to handle this (admittedly, I don't know OSX
that well), it is my belief that this way is less 'hackish' than the various
OSX 'installers' that I've seen floating around.
- Add the router version to the zip file comment in the updater
- Add a class to extract the zip file comment
- Require the sud version header to match the zip file comment
to prevent spoofing of the version number, since the version
number in the header is not covered by the sud signature.
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.
The Tanuki Software website states "64-bit Windows versions of the Java Service Wrapper
are not currently being made available in the Community Edition." The Makefile
for x86_64 is missing from the upstream tarball as well.
Well...included in this checkin is a diff against
$WRAPPER-3.5.9-SRC/src/c/Makefile-windows-x86-32.nmake (see the README in
installer/libs/wrapper/win64.
- removing from /build.xml
- moving recent changes from installer/resources/postinstall.bat to installer/install.xml
- dropping installer/resources/postinstall.bat