Re: RFS: jcharts 0.7.5-2
On 5/6/11, Niels Thykier <niels@thykier.net> wrote:
> -----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).
This one seems probably a special case. So I am not raising the issue yet.
>
>>> 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)
My mistake. lintian was not at 2.5.0~rc3 on my machine.
>
>>>> 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.
Quite a few of them are not officially supported architectures. Anyway
I changed back the build-dep and JAVA_HOME.
>
>>> 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. :-)
Fixed rest of the comments. Updated files are in pkg-java svn. Please
review (and upload).
Onkar
--
Passion - Some people climb mountains - others write Free software.
Don't ask why - the reason is the same.
Reply to: