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

[Henrique de Moraes Holschuh]

On Mon, 06 Aug 2012, Alexander Wirt wrote:
> 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.

Yeah, like build-{arch,indep}, and removing deprecated crap from the
config files.

> > 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.

We can use the per-branch config of gbp.conf, then (I don't like it much
because it leaks a gbp.conf to the source package). 

Release branches don't cause any problem for gbp, and it *IS* the proper
way to deal with multiple releases.  If you don't configure gbp in any
specific way, it will complain that you're not in the "debian branch",
tell you where you are, and what option to use to build anyway.

I am also a gbp user, you see :-P

> > 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.

BTW, this is supposed to be impossible to happen with gbp.  Please check
whether you pushed all your changes ;-)

> > 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.

It is an one-time thing.  You'd need to do git tag -d on every tag git
complained, git fetch again, and that's it.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh