Re: RFS: phing (Another try...)
-----BEGIN PGP SIGNED MESSAGE-----
IANADD (twb told me, I shall be lazy!), here are some comments on your
On 21.07.2011 09:13, Nicolas wrote:
> I am looking for a sponsor for my package "phing".
* Please extend description of the -doc package. Its a bit too short.
You don't need to be too verbose, but please expand it by a few words.
For example you could tell what exactly the package contains and what
its purpose is. Compare with other -doc packages in Debian to get an idea
* Your copyright looks pretty good, however "Copyright: 2001,2002
THYRELL" is probably a bit to few of information. Maybe add a contact
address, I noticed in the code is listed one. Same for "2003,
seasonfive". Yes, this is pure pedantry - feel free to ignore this.
* There is a new upstream release. Please consider packaging it.
Besides, the checksums of your orig.tar.gz don't not match with
upstream's package, being it the full package or the PEAR one. Please
don't touch it.
$ sha1sum phing-2.4.5.tgz.1
bf4c5e709c9141555c299e02aab8ac80cddd2cf7 phing-2.4.5.tgz.1 (this is PEAR)
$ sha1sum phing-2.4.5.tgz
$ sha1sum phing_2.4.5.orig.tar.gz
* What's /usr/share/php/phing/etc for? Those files don't look like
something which should be put in a etc-directory. I'm fine if you keep
it that way in /usr/share/php/phing/etc, I'm just trying to find out,
whether those files are meant to be touched at all. If so, they
shouldn't reside in /usr.
* In debian/rules, please remove unneeded comments dh-make produced.
* Please generate your manpage during build. It seems to me, you ship it
pre-compiled from the SGML man page you wrote.
* Similar case for the API docs you package straight from the tarball.
The DFSG mandate that a software package is available from source and
its processing must be self-containing (e.g. compare with the "preferred
form for modification" from the GPL license). For the generated API docs
this means, there must be a way to regenerate those docs by means the
main archive provides. You don't necessarily need to do this when
producing the binary package, but please add at least a README.source
file, where you document how to regenerate those API docs, upstream
ships, if desired.
* Your upstream tarball contains regression tests. Consider running them
Good work. Those are almost all cosmetic changes.
with kind regards,
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----