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) :) 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. > 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 :) 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. 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 :) G'luck, Peter -- Peter Pentchev roam@ringlet.net roam@space.bg roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 I am the meaning of this sentence.
Attachment:
pgpgfwhHOut75.pgp
Description: PGP signature