Thanks Matt for taking the time to look through my package. Your comments helped a lot. I've updated the package:
deb http://debian.richcole.org.s3.amazonaws.com unstable/ deb-src http://debian.richcole.org.s3.amazonaws.com unstable/ in line with your suggestions. I had originally mistakenly believed it was building correctly but it was using the jar that came with the source to create the timezone files rather than the built jar. (Hence my confusion about the classpath in the manifest :) After fixing that issue the process to generate the timezone files bombs out with [java] Exception in thread "main" java.lang.ArithmeticException: Adding time zone offset caused overflow This only occurs when running with gcj on the built jar, a jar built with gcj but run on the sun jvm on the other hand succeeds. It is also the case that gcj requires a modification to one of the source files to compile (it has to do with a class extending Calendar which implements Comparable<Calendar>) I wonder if the exception I'm getting is due to me having chosen a bad version of gcj or whether for the time being its a showstopper for compiling with gcj. To make some progress time being I changed the dependency to sun-java6-jdk. I went to create an ITP and discovered that joda-time has already been packaged. Somehow I missed it previously. Credit to reportbug for asking me to search :) The current version of the package (libjoda-time-java) doesn't build on my system. It gets the same exception as I listed above when trying to generate the timezone files. If an existing package doesn't build at what point is it a bug. Should it build in the current version of testing? Is there any system that regularly tests that existing packages are still buildable? Or is it developers who test? I guess if it built and the tests ran before and now it doesn't then its more likely the latest version of gcj that is to blame. regards, Richard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
