link to /usr/share/java/httpclient.jar and httpcore.jar.
This is 2 MB of dependencies to replace 20 KB of copied code,
so may not be worth it, esp. for Tails.
Prep for dependency on libtomcat7
Doesn't work yet, breaks susidns.
glassfish-javaee for jstl.jar and standard.jar version 1.2 won't work with tomcat7,
it's ancient and not compatible with recent el libs.
Add back option to depend on libjakarta-taglibs-standard and libjstl1.1-java which are version 1.1.2,
but not clear if they will work with tomcat7 either, even though they are
dependencies of libjetty8-extra-java.
We switched from JSTL 1.1.2 to JSTL 1.2 when we went from Jetty 5 to Jetty 6 in 2012.
1.2 libs are not available anywhere except for Glassfish, and
Debian only has the ancient Java EE 5 Glassfish 2.1.
Not clear there's any way to get susidns (and bote) to work with both Tomcat 6 and 7.
- Fix wrong jsp-api version
- Fix other minor errors in install and links files.
- Log stack trace for Jetty warnings if log level is WARN
- SusiDNS: Move standard.jar and jstl.jar out of WEB-INF/lib, where Tomcat 7 build refuses to find them
Add dependency on libjetty8-java and libservlet3.0-java packages
Remove those binaries in debian builds
Prep for dependency on libservlet2.5-java package
Prep for dependency on libtomcat6-java package
Prep for dependency on libtomcat7-java package
Prep for dependency on libjakarta-taglibs-standard-java package
Prep for dependency on libjstl1.1-java package
Add build properties for building with packages
Rework of apps/jetty/build.xml for building with packages
Redefine debian/ as the files for the jessie build
Make debian-alt directories for ubuntu builds
Move debian/changelog to debian-alt/trusty/changelog
Move debian-alt/jessie/changelog to debian/changelog
Add apps/jetty/jettylib/jsp-api.jar to classpath for jsp builds
Include Maxmind geoip-api-java library v1.3.1 (LGPL v2.1)
Use Maxmind database for geoip lookup if it exists
Debian:
Don't bundle geoip.txt and geoipv6.dat.gz, depend on geoip-database instead
Don't bundle launch4j licenses in non-windows builds
Clarify in LICENSES.txt that launch4j is not bundled in non-windows builds and packages
Debian:
Change maintainer
Remove Debian patch that drops the launch4j licenses
If someone runs "ant debian" to make installable packages, they do not need to
have their own wrapper or commons-logging jars. The PPA builds, however, do
require them. During the last release I made the mistake of overwriting my "PPA
debian/control" file with the one from MTN that did not include these
dependencies.
Also updating "debianhowto" to reflect the fact that we no longer use
Debian's/Ubuntu's Jetty pkgs since Jetty6 appears to be leaving their repos in
the near future.
On Debian Squeeze the default-jre-* packages point to gij/gcj which is suboptimal.
Openjdk cannot be forced since not all platforms--such as kFreeBSD--have it as
an available option.
installed by default if a JRE isn't installed yet. Since the packages
previously depended on "default-jre|java5-runtime|java6-runtime", an
already-installed headless package would have satisfied the dependency.
GnewSense.
This change will break nothing since we check for the existence of the lsb
function files in the initscript. With an older version of lsb-base (like the
one that came with Hardy (and GnewSense uses), the output from the initscript
will simply look a little different (but again, nothing will break). Virtually
everything but GnewSense comes with the desired lsb-base package anyway...
This commit splits the i2p package into a second package, i2p-router.
* The new 'i2p-router' package does not depend on the java-wrapper nor jbigi.
Jbigi is recommended. This package can be installed on the ports or
distributions that the java-wrapper is not available for.
* The new 'i2p' package depends on i2p-router, libjbigi-jni, and the java-wrapper.
This package will add the i2psvc system user and the initscript. Existing
users of the i2p package will have the i2p-router package pulled in
automatically and for them there will be no usability changes.
Executive summary: No functionality changes will take place for either those
that installed the i2p package in the past or those that
install the newly split i2p package. For them, "The Song
Remains the Same."
This sets i2p up as a functional Debian source package. dpkg-buildpackage
will build i2p using ant preppkg (tarball takes too long and not
helpful). It creates a binary .deb archive of the i2p installation,
which when installed goes into /var/lib/i2p as the non-root user i2p,
and adds an /etc/init.d script to start it up.
Some problems not yet solved:
1) under Debian the conf should go into /etc/i2p, but since it doesn't
things like the eepsite index file get overwritten if you reinstall.
should check for those somehow and not replace them, or ask the user.
2) under Debian they like it if you split the generated data from the
static code, so i2p should go into /usr/lib/i2p maybe, but its
netDB and any other cache files into /var/cache/i2p
that's important not just for organization, but also /var is often
on a filesystem optimized for churn. For now just put it in /var/lib
3) i2p is supposedly architecture independant, but it does choose a
native jbigi library on postinstall, so does that really count
as architecture independant?
