-----BEGIN PGP SIGNED MESSAGE-----
On 2011-05-06 14:48, Onkar Shinde wrote:
> On Fri, May 6, 2011 at 3:38 PM, Niels Thykier <firstname.lastname@example.org> wrote:
>> On 2011-05-06 07:49, Onkar Shinde wrote:
>>> I am looking for sponsorship for jcharts 0.7.5-2. This will fix the
>>> bug 594270. This revision adds a new -doc package so it will go
>>> through binary new queue. I have committed the changes in pkg-java
>>> Please note that jcharts uses lot of AWT APIs so we can not remove the
>>> dependency on java runtime. But this revision makes it possible (at
>>> least theoretically) to use it with runtimes other than OpenJDK or Sun
>> Not entirely convinced by this, but I do support the "let the
>> applications depend on the JRE they need" philosophy. Nevertheless, if
>> you do keep the JREs for this package, please add a lintian override
>> (with rationale) for needless-dependency-on-jre (from lintian 2.5.0~rc3
>> or newer).
> As per my understanding of code, jcharts uses AWT API for even basic
> functionality. So it is not possible to use it with headless runtime.
> That is the reason I kept dependencies on -jre/-runtime.
>> If it is a general issue with libraries should depend on JREs in
>> certain cases, please do file a bug against java-common to have the
>> policy amended.
> Any idea what would be wording of such a bug report? Because I can not
> come up with any. :-)
In general we can always figure out the exact wording later as long as
we recognise the policy does not reflect the reality in a reasonable
amount of cases. Though I do not know if this is the case here; if you
think so, we can bring it up (either on list or as a bug against
>> What about the missing classpath entry in the installed jcharts jar
>> (missing-classpath tag emitted by lintian 2.5.0~rc3 as well).
>> Note lintian has a false-positive tag on the -doc package, which will
>> be fixed in the next lintian release.
> Are you sure that all the tags you mentioned are part of lintian
> 2.5.0~rc3? I am running Debian testing and I didn't see any of those
Yes, I am pretty sure they are in 2.5.0~rc3: missing-classpath was added
in 2.5.0~rc3 and needless-dependency-on-jre in 2.5.0~rc1. Particularly
needless-dependency-on-jre had a false-positive reported against it that
I fixed in 2.5.0~rc3 (#622396) and the missing-classpath check was a
part of Vincent's Java checks (#620829)
>>> Latest changelog for reference.
>>> jcharts (0.7.5-2) unstable; urgency=low
>>> * debian/patches/01_remove_old_functionality.diff
>>> - Patch to exclude files that use Sun proprietary APIs and related changes.
>>> (Closes: #594270)
>>> * debian/control
>>> - No need to use only OpenJDK or Sun JDK/JRE now. Updated (build-)deps
>> Unfortunately GCJ appears to choke on the javadoc generation, so we
>> probably have to keep the B-D as openjdk-6 and use openjdk-6 in
>> JAVA_HOME (probably with a note in d/rules as to why).
> How many supported architectures have GCJ as default java? I will
> surely change build-dep if there is a high chance that someone will
> try to rebuild the package (on buildd or otherwise) with GCJ as
> default java.
I believe default java is:
openjdk-6 on alpha amd64 armel i386 ia64 mipsel powerpc powerpcspe s390
gcj on hppa hurd-i386 kfreebsd-amd64 kfreebsd-i386 m68k mips sparc64
So reasonable amount still have gcj.
>> If you restore sun-java6 as alternative, please remember to make
>> d/rules pick up the JAVA_HOME for sun-java6 if openjdk-6 is not present.
>> (otherwise it will FTBFS if openjdk-6 is not installed).
> I will not setup Sun JDK as alternate build dependency because the
> number of arch where Sun JDK is available is even less than OpenJDK.
> Also I am not inclined to add alternative build-dep on non-free
>>> - Build against libservlet2.5-java instead of libservlet2.4-java.
>>> - Add libjcharts-java-doc package containing API documentation.
>> The doc package only needs to recommend the other doc packages; it still
>> works without them (although without them it will contain broken links)
> Sounds ok. I will move them to recommends.
>>> - Update standards version to 3.9.2. No change needed.
>>> * debian/rules
>>> - Change JAVA_HOME to 'default-jdk' home.
>>> - Use servlet-api-2.5 instead of servlet-api in build classpath.
>>> - Build javadocs as well.
>>> * debian/libjcharts-java-doc.install
>>> - Install API documentation at appropriate place.
>>> * Convert package to source format 3.0.
>>> -- Onkar Shinde <email@example.com> Fri, 06 May 2011 10:27:01 +0530
>> The build complains about "Target clean does not exist" and on a related
>> note it does appear to fail if you build it twice in a row (at least the
>> javadoc is not cleaned).
> Upstream ships generated javadoc in source root in javadocs directory.
> But the build system generates javadocs in build/javadocs directory. I
> think since there is no clean target, the clean rule in debian/rules
> should delete the 'build' directory (currently it only deletes certain
> parts of it).
> I will fix this.
> I will reply when I am done with certain changes. Meanwhile we can
> continue the discussion on debatable topics. :-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org