> 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> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
