[Amavisd-new-debian-devel] Doing some amavisd-new work for Wheezy

[Alexander Wirt]

On Sun, 05 Aug 2012, Henrique de Moraes Holschuh wrote:

> I am trying to do some cleanup and fixes for amavisd-new, in hope they will
> get freeze-exceptions and make it to Wheezy.
yeah, life :).

> 
> 1. Upstream bug-fix release 2.7.2
> 2. dpkg-maintainerscript-helper rm-conffile for the old anacron cronjob
> 3. assorted stuff.
assorted stuff? I am following -release very closely and I would say that the releaseteam
won't accept anything that isn't really rc or following the guidelines for
unblock exceptions.

> 
> I also uploaded a backport of the current package (2.7.1-2) to bpo60.
yeah, I saw that, very appreciated.

> I've created release/* branches in my local repo to make it easier to track
> each branch (possibly known to) the bts.  One should always include previous
> changelog entries from that branch in new uploads to that branch, or the bts
> version tracking goes apeshit.  This is not something that easy to remember,
> I forgot that detail when uploading the 2.7.1-2~bpo60+1 backport, and the
> result is the mess you can see in #678501's fixed/not-fixed version tree.  I
> will clean that up in a future backport (you just need to add the missing
> debian/changelog entires at their proper place, and document you had to do
> it).
I am not a big fan of non-automated things in git. I try to follow the
semantics of git-buildpackage very closely to make development easy for third
party members and of course for myself. Having the same workflow for all my
packages really helps.
> 
> While working on this stuff, I noticed that the upstream branch in git was
> not forwarded to upstream/2.7.1 (easily fixed).  I also noticed none of the
> tags are signed.
> 
> I will be using signed tags, they will make life ****MUCH**** easier the
> next time any of us has to deal with a possible compromised git repo.  Due
> to the way git works, this will also secure all previous history, but it
> does nothing to secure previous tags.
> 
> I propose that for the future, we should use signed tags (both for
> upstream/* and debian/* namespaces).
git-import-orig and git-buildpackage support signed tags, so I am fine with
it.
> 
> Actually, it might be worth the effort to actually retag everything with
> signed tags, but there are drawbacks, one of the worst ones being that
> git will bitch to anyone who already got the unsigned tag in their local
> repos.
I am not very keen on getting git bitching on my local repos, so I would
prefer just doing this for future tags.

Thanks for getting back to the package

Alex