[Pkg-giraffe-discuss] zarafa-7.2.1 RC1 released

[Guido Günther]

Hi Zarafians,
On Sat, Sep 12, 2015 at 09:46:42PM +0200, Guido Günther wrote:
> Libraries
> =========
> 
> $ grep "Package: lib" debian/control | wc -l
> 14
> 
> That's a lot for a groupware. I wonder if we couldn't just bundle them
> in one library package for the time being? Especially things like
> libzcp_common_ssl seem to only have one single class:
> 
> # objdump -w --dynamic-syms /usr/lib/libzcp_common_ssl.so.0.0.0 | grep " g "| grep ECC | wc -l
> 33
> 
> Bundling things would certainly make the ftp-masters happy. We could
> also split into three: client, server and common. Opinions?

I've cut this down considerably as discussed with Mark:

    $ grep "Package: lib"  debian/control  | wc -l
    7

I've completely dropped the libarchive* parts by patching out the
functionality were needed:

    http://anonscm.debian.org/cgit/pkg-giraffe/giraffe.git/tree/debian/patches/Remove-archiver-related-code.patch    

It would be great if this could go upstream for 7.2.1 (maybe compile
time toggled (-DDISABLE_ARCHIVE) since carrying it could become
cumbersome in the future. I've also renamed libmapi to libzarafa_mapi:

    http://anonscm.debian.org/cgit/pkg-giraffe/giraffe.git/tree/debian/patches/Rename-libmapi-to-libzarafa_mapi.patch

It would be great if this could go upstream since it doesn't make sense
to ship a *public* library with a different name in Debian.

> Recommends
> ==========
> * We currently only suggest a database server so it doesn't get pulled in
>   when doing a "apt-get install zarafa-server"
>   I think we should recommend mariadb-server so the user gets a working
>   installation. If he doesn't want it he an always install without it or
>   move it to a different server later. If there's agreement I'll fix this
>   in git.
> 
> * We don't recommend zarafa-webapp either. o.k. to add this as
>   Recommends to the zarafa package? (until we have the webapp in the
>   archive and then make it a dependency).
> 
> Any opnions on this one?

Fixed as suggested above.

> Poor error handling on wrong permissions
> ========================================
> Doing a
> 
>    # zarafa-server -F -c /etc/zarafa/server.cfg && echo "Success."
>    Success.
> 
> but the daemon is _not_ running due to a:
> 
>    pid 19928] mkdir("/var/lib/zarafa/attachments", 0700) = -1 EACCES (Permission denied)
>    [pid 19928] open("/var/lib/zarafa/attachments/testfile", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 EACCES (Permission denied)
>    [pid 19928] write(3, "Sat Sep 12 20:03:00 2015: [error"..., 180) = 180
> 
> so it writes to the log nicely but doesn't exit with status 1 making it
> impossible for the init system to report the error to the user. The same
> is true if the database password is wrong. Log file is o.k. but init
> script reports server started although it's not running.
> 
> I've applied the attached patch to the Debian package which at least
> makes the -F case work as expected. I've not fixed the forking case
> yet.
> I' also worked around the permission problem in
> /etc/init.d/zarafa-server for the time being:
> 
>     http://anonscm.debian.org/cgit/pkg-giraffe/giraffe.git/commit/?id=878012959c7ee186d4ed0ce823894d98ff250655

This helps at least for the systemd case. Are you going to look into the
daemonized case for 7.2.1?


> Documentation in /usr/share/doc/zarafa
> ======================================
> The folder currently contains little documentation but lots of
> scripts. Iff we want to ship them they should go to
> /usr/share/doc/zarafa-server/examples but most of this is of little use
> to Debian users. All files need to be moved to
> /usr/share/doc/zarafa-server/ since that's the package that ships it.
> We can ship a symlink /u/s/doc/zarafa -> zarafa-server if wanted.

Not done yet. Patch for ths would be welcome.

> Manpages
> ========
> At least the zarafa-server manpages talks about license keys. I don't
> think that is applicable for the server (or is it)? If not we should
> remove it.

Not done yet. Patch for ths would be welcome.

> dbconfig-common
> ===============
> There are issues like
> 
> Unpacking zarafa-server (7.2.1~RC51272-1~1.gbpdd4839) over (7.2.1~RC51272-1~1.gbpdd4839) ...
> /var/lib/dpkg/info/zarafa-server.postrm: 275: /var/lib/dpkg/info/zarafa-server.postrm: db_get: not found
> /var/lib/dpkg/info/zarafa-server.postrm: 276: /var/lib/dpkg/info/zarafa-server.postrm: db_reset: not found
> 
> when upgrading packags. I'll have a look at these.

Fixed.

> Handling of security updates
> ============================
> With the LTS team in Debian we now support packages for 5 years. It's
> always a pity if we have to end security support before that due to
> lack of upstream support. So I wonder: once we have a version in a
> Debian stable release will zarafa support the security team in
> backporting fixes to these versions?

We had a short discussion about that at the tour but I'm not sure what
the exact outcome was. Maybe you guys can pick this up in Hannover
again? Since you do have a CVE process making the patches that fixes the
CVEs available would be a great first step.

> zarafa-search
> =============
> If there are issues running as non root in 7.2.1 should we skip it for
> the initial upload. We can easily readd it once the dust has settled
> (once we're through the NEW queue).

I think we can leave search as is for now and fix it with 7.2.2.

I've noticed one further thing:

Public headers
==============
While the zarafa-dev package ships the symlinkcs to the SOs it doesn't
ship any public headers. Looking at the header I couldn't find a clear
cut between public and private headers. Can you suggest what we should
move into the package. It would also be great to have a minimalistic
autopkg test that builds one simple binary that lnks e.g. against
libzarafa-mapi.
Cheers,
 -- Guido