Re: RFS: dma (bugfixes, debconf, 3.0 (quilt))
> Dear mentors,
>
> I am looking for a sponsor for the new version 0.0.2009.07.17-3
> of my package "dma", the DragonFly Mail Agent. This version
> fixes a couple of bugs, updates the debconf translations, and
> converts the package to the 3.0 (quilt) source format.
>
> It builds a single binary packages:
> dma - lightweight mail transport agent
>
> The package has been tested with lintian and pbuilder.
>
> The upload would fix these bugs: 544664 (file permissions),
> 547594 (fix a crash), 552586 (fix a debconf template),
> 552754 (debconf German translation), 554515 (debconf Japanese translation),
> and 558421 (install mailq and newaliases).
>
> The package can be found on mentors.debian.net:
> dget
> http://mentors.debian.net/debian/pool/main/d/dma/dma_0.0.2009.07.17-3.dsc
>
> I would be glad if someone uploaded this package for me.
>
> JFYI, here's the changelog entry:
>
> dma (0.0.2009.07.17-3) unstable; urgency=low
>
> * Really install the files in /etc/dma/ as root/mail/640.
> Closes: #544664
That only works for a newly installed dma package, and won't work for
upgrading from older versions. My best bet on that would be a debconf question
asking the user to perform the above actions on files at /etc/dma/.
> * Install the /usr/bin/mailq and /usr/bin/newaliases symlinks.
> Closes: #558421
> * Switch to the 3.0 (quilt) source format.
> * Update the debconf translations:
> - add German. Closes: #552754
> - add Japanese. Closes: #554515
> - remove a double space and unfuzzy the translations. Closes: #552586
> * Fix a crash when the SMTP server does not support STARTTLS.
> Closes: #547594
I had a look at 25-unsupported-starttls.patch, which looks good to me, however
I was not able to test it, so I assume you have tested that as well.
By the way, IMO having so many patches in debian/patches (in fact much more
than source files;-) looks like you are trying to develop there, nothing wrong
with that, but it is not the most suitable place for that purpose. For
instance, 9K 20-parse-recipient.patch is suitable for a new feature branch.
IMO you either push that harder upstream [1], slow down pushing such feature
patches with the package or fork the whole thing upstream and form a new
project. Actually you have already diverged that enough to do the latter. IMO,
debian/patches should be only for patches specific to Debian, feature
explosions should be evolved upstream ;-)
[1] though I don't see that rejected at (as written in the patch header):
http://bugs.dragonflybsd.org/issue1321
--
pub 4096R/0E4BD0AB <people.fccf.net/danchev/key pgp.mit.edu>
Reply to: