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

Re: RFS: svgsalamander (updated)



Hi,

I had some exams last week so I haven't had time to look into
svgsalamander again until today. I addressed most of the comments from
Niels in the new version I uploaded to mentors (and git).

Le 26/02/2011 à 16:17, Niels Thykier <niels@thykier.net> écrivit :
> On 2011-02-19 18:49, Nicolas Dandrimont wrote:
> > The package can be found on mentors.debian.net:
> > - URL: http://mentors.debian.net/debian/pool/main/s/svgsalamander
> > - Source repository: deb-src http://mentors.debian.net/debian unstable main
> > 	contrib non-free
> > - dget http://mentors.debian.net/debian/pool/main/s/svgsalamander/svgsalamander_0089-1.dsc
> > 
> > It is also available under git at
> > 	git://git.debian.org/pkg-java/svgsalamander.git
> > (Browser: http://git.debian.org/?p=pkg-java/svgsalamander.git;a=summary)
> > 
> > This is my first Java package, so I'm sure I didn't get everything
> > right. Off the top of my head, here are some of my thoughts:
> > 
> > - The jar is being signed at build-time. Should I disable this?
> > 
> 
> I have not tried to build it; else I would have been able to answer this
> myself. :P  If signs automatically without requiring any interaction,
> then it is not a problem (build-wise, but the signature is probably not
> worth a lot then).  If the build stops waiting for the user to (e.g.)
> supply a password, then it is definitely not okay (since then it will
> not be rebuildable on our auto-build machines).

The jar files are automatically signed by a build-time-generated
temporary key. As this seems to be pointless, I just removed it
altogether.

> > - I decided to install the javadoc at the same time as the
> > package. Should I split it in another package?
> > 
> 
> Yes please; javadoc tends to take up a lot more space than the jar files
> themselves.  You should also make the javadoc link against the system
> javadoc (this requires a Build-Depends on default-jdk-doc plus the -doc
> packages of any package it depends plus [for ant] a couple of <link
> href="/path/to/javadoc/" /> in the javadoc tag).

Done.

> > - I'll put the package under team-maintainance. If I understand the
> > Policy correctly, I should set:
> > ---8<---
> > Maintainer: Debian Java Maintainers
> > 	<pkg-java-maintainers@lists.alioth.debian.org>
> > Uploaders: Nicolas Dandrimont <nicolas.dandrimont@crans.org>
> > ---8<---
> > even though I'm neither a DD nor a DM. Is that correct?
> > 
> 
> Yes.

Done.

> So; debian/docs is empty - if the file is not needed you should remove it.

Done.

> The copyright file does not list that
> svg-core/src/main/java/com/kitfox/svg/batik/RadialGradientPaintContext.java
> (and quite possibly other files) are Copyright Apache Software
> Foundation and under Apache-1.1
> You should probably ping upstream about that.

I updated the copyright file with the info for
svg-core/src/main/java/com/kitfox/svg/batik/*. Those seem to have been
taken verbatim from batik, but I don't know which version. I'm pinging
upstream about this to know :
 - From which batik version those files were taken
 - If the files were modified
 - If it is at all possible to use the system batik library instead of
 embedding a few source files... Which should be okay as long as the
 Apache project is properly attributed as per the Apache-1.1 license.

> Then there is doc/dev/GetTRDoc.pdf which says that "Distribution is
> unlimited" but says nothing about modification.  Torsten would probably
> ask where the source of it is, though it looks to be a scanning of the
> paper document.

This paper is a thesis work done inside the US Naval Postdoctoral
School. Unlimited distribution is indeed allowed, but I couldn't find
any info on modifications (whether that is pertinent or not). As the
file is not installed anyway, I dropped it from the orig tarball and
left a note in README.source with info on how to fetch it back.

> What is the version scheme of this package? Just the raw svn revision?
> If so 0~svn${revision}-1 is probably a better version in case upstream
> makes a real release later.  On a related note; dpkg ignores the "00"
> prefix - as demonstrated by:
> 
> $ dpkg --compare-versions 0089-1 '=' 89-1 && echo "yes"

Well, there haven't been any upstream releases, and the library seems to
be in maintenance mode. I'll contact upstream to see if he intends to
make a release. I'll change this if needed when he answers.

Thanks for your review,
-- 
Nicolas Dandrimont

Attachment: pgpDKi8aJNq0s.pgp
Description: PGP signature


Reply to: