[Pkg-giraffe-discuss] Bug#865320: kopanocore FTBFS: error: expected class-name before '{' token

[Carsten Schoenert]

Hi,

Am 20.06.2017 um 15:55 schrieb Adrian Bunk:
> Source: kopanocore
> Version: 8.1.0-3
> Severity: serious
> 
> Some recent change in unstable causes kopanocore to FTBFS:
> 
> https://tests.reproducible-builds.org/debian/history/kopanocore.html
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/kopanocore.html
> 
> ...
> In file included from ../../../inetmapi/inputStreamMAPIAdapter.cpp:23:0:
> ../../../inetmapi/inputStreamMAPIAdapter.h:25:77: error: expected class-name before '{' token
>  class inputStreamMAPIAdapter _kc_final : public vmime::utility::inputStream {
I've looked at this issue yesterday in the evening.
The reason for this FTBFS isn't kopanocore but the upload of libvmime
0.9.2 to unstable done by me.

kopanocore is needing libvmime-dev which was previously also provided by
version .1.
But now libvmime 0.9.2 has done a API change and this change isn't
backward compatible as seen now.

So I have thought about the current packaging of libvmime which isn't
fully correct in my eyes. In  detail for the development files in
libvmime-dev.

It's probably more correct to create a new binary package libvmime1-dev
which isn't putting the header files into /u/i/vmime, by this the old
package would be co-installable. But upstream seems to not take care on
this. It's not a problem to adjust the control file and the packaging of
libvmime1 related files and folders. But every depending package on
libvmime1-dev would be needed to being patched as headers are included
and searched in /usr/include/vmime instead of /usr/inlcude/vmime1. That
would bring a lot extra work into package maintaining not only for libvmime.

What to do?
Should we try to convince upstream to create a new sub-release of
libvmime-0.9.x with a different installation base for the header files?
I think this can be a long standing challenge if Kopano isn't pushing
into this direction too. In the long term this would be the best solution.

Should we try to patch the existing kopanocore 8.1.0 source? I don't
know if this is really possible.

Or should we ignore this all and go ahead and stay with the current
situation as libvmime-dev isn't needed by any other package in Debian
testing?

> $ apt-rdepends -r libvmime-dev
> Reading package lists... Done
> Building dependency tree       
> Reading state information... Done
> libvmime-dev
This all is a bit unfortunate due kopanocore > 8.1.0 needs libvmime
0.9.2. But currently we need to wait for gsoap for starting working on a
new kopanocore version.

-- 
Regards
Carsten Schoenert