Bug#731414: pu: NMU proftpd-mod-vroot/0.9.2-2

["Adam D. Barratt" <adam@adam-barratt.org.uk>]

Control: tags -1 + moreinfo

On Thu, 2013-12-05 at 10:50 +0100, Andreas Beckmann wrote:
> According to #715569 proftpd-mod-vroot needs to be rebuilt to be
> functional with the proftpd in wheezy. The 0.9.2-2+b2 binNMU that is to
> be found in most architectures in wheezy has been built against
> proftpd 1.3.4a-1, while wheezy has 1.3.4a-5+deb7u1 nowadays.
> I have no idea what causes this binary incompatibility.
[...]
>  proftpd-mod-vroot | 0.9.2-2    | wheezy | source, armhf
>  proftpd-mod-vroot | 0.9.2-2    | sid    | source
>  proftpd-mod-vroot | 0.9.2-2+b1 | wheezy | s390x
>  proftpd-mod-vroot | 0.9.2-2+b1 | sid    | armhf
>  proftpd-mod-vroot | 0.9.2-2+b2 | wheezy | amd64, armel, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, sparc
>  proftpd-mod-vroot | 0.9.2-2+b2 | sid    | s390x
>  proftpd-mod-vroot | 0.9.2-2+b3 | sid    | amd64, armel, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, sparc

Before we consider another rebuild in sid with a higher binNMU number,
do we know whether the package currently works there?

Binary incompatibility breaking within uploads of the same upstream
release a) sucks and b) seems like something that should be expressed in
package relationships (or better yet, fixed).

Regards,

Adam