On Thu, 2008-04-03 at 12:12 +0100, Robin Cornelius wrote: > Dear mentors, > > I am looking for a sponsor for my package "xmlrpc-epi".
Hi Robin, I'll review this tonight. There are one or two things I've seen already: http://wiki.debian.org/EmdebianGuide#head-7d381311f6972e4d3a4853bd96485e508fb6ac1f (also see the autotools-dev README) --build should be used for all calls to ./configure --host should only be used if actually cross-building so that your package does not inadvertently try to use a cross compiler. e.g. on my amd64: x86_64-linux-gnu-gcc -DPACKAGE_NAME=\"\" ... when it should be gcc -DPACKAGE_NAME=\"\" ... This is a preventative measure - with or without evidence of errors caused directly by this, it should be changed in line with the autotools recommendations to prevent errors later. Also, add a -dbg package (see docs on dh_strip). See also #436419 You close the same bug twice in the debian/changelog - to build a new version including the changes (and bug closures) of a previous version that was not uploaded, use the -v option to debuild or dpkg-buildpackage. (to include the first version, invent a version older than the first) $ debuild -v0.51-0 results in a .changes file like: Closes: 413986 413986 Changes: xmlrpc-epi (0.53-1) unstable; urgency=low . * New upstream release (Closes: #413986) - Upstream has been updated, drop all patches we were applying - Use libxml2 as xmlparser on configure option . xmlrpc-epi (0.51-1) UNRELEASED; urgency=low . * Initial release (Closes: #413986) - Modified to use system expat rather than included (OLD) expat version - Libtoolized and autoreconfd - Install headers to /usr/include/xmlrpc-epi/ to avoid conflicting with libxmlrpc-c3-dev - Sync up to libxmlrpc from PHP5's xmlrpc extension - Fix various compilation warnings See also: http://people.debian.org/~codehelp/#increment The best option, I think, would be to remove the ITP closure from 0.53-1. Also, when closing bugs in the changelog, use 'bts -a --closes #1' so that the full title of the bug report is included, so that you know you are fixing the right bug and so that people scanning your changelog via the PTS webpages at some future date know what you did at that point in the changelog. You have useful changelog entries for the other changes, it's only reasonable to do the same with the BTS entries. > * License : MIT (and a few others - I'll check on that later.) There's no need for a new upload to mentors to fix these issues - it's only a very quick review. I'll send a more detailed response this evening. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
signature.asc
Description: This is a digitally signed message part
