Re: RFS: jcharts 0.7.5-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 2011-05-06 14:48, Onkar Shinde wrote:
> On Fri, May 6, 2011 at 3:38 PM, Niels Thykier <niels@thykier.net> 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
>>> svn.
>>> 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
>>> JRE.
>>>
>>
>> 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
java-common).
>> 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
> tags.
>
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
>>> accordingly.
>>
>> 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
sh4 sparc
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
> package.
>
Sure.
>>
>>> - Build against libservlet2.5-java instead of libservlet2.4-java.
>>
>> Nice
>>
>>> - 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 <onkarshinde@ubuntu.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. :-)
>
>
> Onkar
Good :)
~Niels
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCAAGBQJNw/uUAAoJEAVLu599gGRCCrwQAIzys3y2fBXKFZDSLFw23F+U
OugVncMwDLw0U8ZDYol0X96BadcOOVdU+DSd2zxWz1+EJg7aHZB7ltHD4Viq/+Cy
vv4UYJEtlo90FUaTNCkrWKkrWDvJu3eKk5z02ymq9QoxYXSkZdy5cxP3EjZperbL
NBhrlqggfnTd9jpiD0K8NfMq4fHRp/sz6yzTDUJ4pWPFbk3EjtP56y9uYu/SyyXL
iGDvrvyu29gT5BUrlEsX3gtKxBvRZAwiTsyqphCkFkm2UZag3N0acZiS/FQlCfcd
YTpz/LRoHWfrIq3VTT6rkMtp9N/CSKT10GzvMFvjevfbmlaCcFu5RJS15Sei+1lc
KX7p3OLP6mCGDIlglcZNUFKwpFGVQMppOmHsKmE+vA7sUMkGFq8J8URXJqTNvNXM
16gwSk0s9ZdTMq7zv0LbQ8MnSbAqKsBcwdj/2i0S5bsqxvWq2ymBVzYDM3fFPx4C
4ZYfNOVsA+QzWDf4aDkTbE+2RcV+QHhmq7F1Q1LjzSvFdFBEvA8UbTabYTfO1BnG
KSORF6B4gdLIfIjb4F3xuDxCav3XU1jqccDpyv8Ie8WGAJH+sCEEQBXqphUur3VF
uMCr/qVqkC/KReZUnk4dncRERUR71sMCeZhFDnDCtdywOQCyHBlbwUJO/ZJkSSiW
w8QPKCKOyNW2LiKRPjmq
=zyVp
-----END PGP SIGNATURE-----
Reply to: