[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: jcharts 0.7.5-2



On Fri, May 6, 2011 at 3:38 PM, Niels Thykier <niels@thykier.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> 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. :-)

> 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.

>> 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.

>  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.

>
>>     - 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
-- 
Passion - Some people climb mountains - others write Free software.
Don't ask why - the reason is the same.


Reply to: