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/
Attachment:
signature.asc
Description: This is a digitally signed message part