[Pkg-giraffe-maintainers] kopanocore_8.1.0-1_amd64.changes REJECTED

[Guido Günther]

Hi Scott,
On Thu, Dec 22, 2016 at 10:00:10PM +0000, Scott Kitterman wrote:
> 
> Unfortunately, I am going to have to reject your package.  It contains
> php5-mapi.  php5 is in the process of being removed and will not be part of
> the next release, so we aren't accepting new packages that would further
> complicate the process of removal.  You will need to either use php7 or drop
> php support from the package.

Thanks for having a look at the package. We decided to go with php5 for
the upload since

    * back then it looked as if stretch would ship with php5
    * php7 support is well underway upstream but not everything
      _dependent_ on zarafacore was able to use php7 back then

We'll likely disable php support for the moment to get the package into
the archive and enable it once the dependencies support php7.

> Additionally, while not a reject reason, lintian found a good stack of errors
> that should be addressed before this is uploaded again:
> 
> E: kopanocore source: build-depends-on-obsolete-package build-depends: libmysqlclient-dev => default-libmysqlclient-dev
> W: kopano-dev: file-name-contains-wildcard-character usr/lib/*/
> W: kopano-dev: file-name-contains-wildcard-character usr/lib/*/kopano/
> W: kopano-dev: file-name-contains-wildcard-character usr/lib/*/kopano/ldapmsplugin.so
> E: kopano-ical: init.d-script-needs-depends-on-lsb-base etc/init.d/kopano-ical (line 39)
> E: kopano-dagent: init.d-script-needs-depends-on-lsb-base etc/init.d/kopano-dagent (line 40)
> E: kopano-monitor: init.d-script-needs-depends-on-lsb-base etc/init.d/kopano-monitor (line 39)
> E: kopano-spooler: init.d-script-needs-depends-on-lsb-base etc/init.d/kopano-spooler (line 40)
> E: kopano-gateway: init.d-script-needs-depends-on-lsb-base etc/init.d/kopano-gateway (line 39)
>

Will do. Lintian we used back then didn't have these checks yet.

> I did not check copyright, but I thought, while glancing at it I saw some
> boilerplate information in there indicating the file was autogenerated
> and not manually corrected afterwards.  I would suggest double checking that.

Hopefully not. The first time kopano was rejected (back in March) it was
due to a licensing issue. Could you have a look at the copyright file so
we can clean that up as well in case you find something lacking?
Cheers,
 -- Guido