v2.2.15 released

[Ron]

Hi Phil,

On Wed, Oct 29, 2014 at 03:07:54PM +0200, Phil Carmody wrote:
> On Sat, Oct 25, 2014 at 04:39:29PM -0400, Gedalya wrote:
> > On 10/25/2014 11:43 AM, Timo Sirainen wrote:
> > >On 25 Oct 2014, at 04:59, Gedalya <gedalya at gedalya.net> wrote:
> > >
> > >>>> Also I have one minor issue to report.  dovecot broke API from
> > >>>> 2.2.13 to 2.2.14 but it only provides version macros for the
> > >>>> first two components of the version number.  This has caused a
> > >>>> small upgrade problem for the antispam plugin which is in a
> > >>>> separate package (dovecot-antispam.) Was that addressed in
> > >>>> 2.2.15?
> > >>> I only remember an ABI problem with antispam. Recompiling fixed
> > >>> that AFAIK. (And no Dovecot version guarantees ABI
> > >>> compatibility.) Is there some API problem also?
> > >>
> > >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765943
> > >
> > > Oh, it uses the really old way to do things. In v1.1+ T_BEGIN { ..
> > > } T_END should have been used instead. Patch attached.
> 
> The header file could admittedly have been a little more persuasive
> in weaning people off the old interface.
> 
> However, it was my bad that I didn't consider the old interface may
> still be in use. Apologies.

Part of the catch here is that the dovecot-antispam code has tried to
remain compatible with earlier versions of dovecot too, since there is
always going to be some spread of versions in the wild at any given
time.  But if this just means dropping support for versions < 1.1 now,
that might not be such a big deal anymore.

The original patch we looked at for this was basically quite simple:
http://anonscm.debian.org/cgit/users/ron/dovecot-antispam.git/commit/?id=2aa93d15409f5a47589d264991fd3e8261d34b1b

The main catch being dovecot only exports version macros for the
MAJOR and MINOR version components, not for the final "patch level"
component, so we need to parse the full version string to get that.
That wasn't really a problem while the API only changed with a minor
version bump, but this change changed that.

It would be nice (in the long term) if dovecot itself provided macros
that let us avoid what we (and other plugins) are doing here:
http://anonscm.debian.org/cgit/users/ron/dovecot-antispam.git/tree/dovecot-version.c


> > OK, it's not working as it is.
> > 
> > This little bit seems like a typo:
> > -    t_pop();
> > +    } T_POP;
> > 
> > Gives me:
> > 
> > pipe.c:315:4: error: ?T_POP? undeclared (first use in this function)
> >   } T_POP; 
> > 
> > I tried T_END and I still get:
> > 
> > pipe.c: In function ?backend_handle_mail?:
> > pipe.c:314:2: error: label at end of compound statement
> >   out:
> >   ^
> > 
> > I got it to compile, see the attached. I don't really know C
> ...
> >   out:
> > -	t_pop();
> > +	;
> > +	} T_END;
> 
> That is the correct fix. C is quirky about labels, you can only label
> statements, nothing else. As Timo mentioned, the t_push()/t_pop()
> interface hasn't been the recommended interface since about 2008,
> so this definitely is the correct way to go.

Yeah, or we can just move the label outside the extra brace scope
for the couple of places that's a problem here.

> If upstream is out there somewhere, for your patch:
> Acked-by: Phil Carmody <phil at dovecot.fi>

I've added Johannes to the CC for this.

  Thanks!
  Ron