Peter Pentchev writes: > On Sat, Dec 12, 2009 at 04:56:45PM +0200, George Danchev wrote: > > > 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. > > [snip] > > I've uploaded a new package with the same version number, > 0.0.2009.07.17-3; the mentors.d.n URL is the same, > http://mentors.debian.net/debian/pool/main/d/dma/dma_0.0.2009.07.17-3.dsc > > The changes are: > - the postinst script does an additional chown/chmod if necessary > (see below) > - the smarthost and dbounceprog are always taken from the debconf > database, never from the (possibly modified by hand) dma.conf file; > this fixes #544663, since there is no way to tell if the dma.conf > contents are from a modification by hand or from an earlier debconf > run with the default "mail.example.com" value! > - the debian/config script mistakenly looked for "defer" instead of > "dbounceprog" > > See below for more comments. > > > > * 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/. > > Well, actually, upon thinking about it a bit more, it turns out that > a debconf question is never really needed. The dma executable binary > is always installed setgid mail, so root/mail/640 for /etc/dma/* > Should Be Enough For Everyone(tm) :) That is also true, and actually preferred way to go in that case. > I've added a snippet to the postinst script, checking whether we're > upgrading from an earlier version and doing the chown/chmod if so. > IMHO, this should cover all cases. > > > > * 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. > > Yes, it's really easy to test - just point dma to any mailserver that > does not recognize the STARTTLS command on port 25 :) But, yes, I've > tested it and it seems to work. Yeah, time (check on the run;-) now upon upload, I tested with and without STARTTLS. > > 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 > > Well, I wrote most of those patches because without them, dma either simply > could not replace a local MTA (e.g. the "sendmail -t" mode tha many, many > programs use to send e-mail messages in a really simple way), or did some > really weird things (e.g. the "seen" patch that was later integrated and > without which dma would list the same message several times when listing > the queue with no indication whether it was needed or not). Most of > the patches were accepted upstream, and some (like -t processing) were > not explicitly rejected, but implemented in a different way in later > versions. When I finish integrating a later snapshot of dma in my > local repository, you'll see the next Debian upload with a lot less > non-Debian-specific patches :) Okay, I'd really like that. > Yes, I know debian/patches is not intended as a development repository, > especially on a project with a very active and responsive upstream, as > dma happens to be. I don't do this with other packages, but this > particular case was special - in order to be an easily-usable MTA, dma > needed a couple of nudges in the right direction, but definitely not > enough to warrant a full-scale fork on my part. Good. My whole point was not to silently grow a thoroughly different/deviated dma while packaging it for Debian ;-) > Thanks for taking a look at it and for the comments; and thanks in advance > should you decide to also take a look at the new version :) Welcome. -- pub 4096R/0E4BD0AB <people.fccf.net/danchev/key pgp.mit.edu>
Attachment:
signature.asc
Description: This is a digitally signed message part.