[Pkg-giraffe-discuss] oustanding autopkgtset issues for kopanocore 8.6.90

[Carsten Schoenert]

Hi,

thanks to the excellent help (once more) from Guido while the ORR about
the usage of KVM images for doing autopkgtest in a clean environment I
was able to get the autopkgtest now running successfully after tweaking
the smoke script! Yeah!

The tests now are successful but I'm sure some things needs to be improved.

I'm not really sure why the tests have failed in the past as we had
switched the user of kopano-server was running as to a normal system
user instead of root. Upstream is doing the same now as the default for
some time.

The main problem for the failed autopkgtests was the user kopano-server
which was trying to connect to the sql server which the server of course
don't know of (and shouldn't). The user 'kopano-server' comes from the
file /etc/kopano/debian-db.cfg which should be 'kopano' instead. But
even changing the string for kopano-server/db/app-user in the smoke test
script doesn't make any effect. dbconfig-common voodoo I'm not know
enough about. I worked around later by using a sed line.

Secondly the sql server didn't had a database associated to the kopano
user with access rights. I guess this should be all handled by
dbconfig-common!?

So I made some workaround into the smoke test script to get the tests
working. But there might be some more things not completely clear to me
if i look at the full log of the autopkgtest.

Thirdly I figured out that the systemd unit file for kopano-server from
upstream is probably missing some PreExec things and switched back to
the usage of the Debian file instead, we need this to ensure the access
control of kopano-server to /var/lib/kopano.
Small similar things are also true for dagent and presence. We simply
need to get this cleared and finally upstream all the needed changes.

Guido, you mentioned a needed 'Breaks: python-mapi' on python3-mapi,
this is something I haven't looked at now.

And we still have also #910438 [1] to consider. At this logrotate
leftover I also haven't looked.

As this isn't RC I'm thinking if we should prepare a upload to NEW
anyway to not depend later on coming late to the party.

I pushed my rather smallish changes to GitHub and Salsa. The Travis log
is visible here [2]. Note the Salsa tree hasn't a updated changelog file
if you want to rebuild the packages!

[1] https://bugs.debian.org/910438
[2] https://travis-ci.org/tijuca/Giraffe

-- 
Regards
Carsten Schoenert