FTBFS with PHP 8.0 on Impish

[Sergio Durigan Junior]

Kopanocore FTBFS with PHP 8.0 on Impish.

Here's the full log for more details:

https://launchpadlibrarian.net/544879021/buildlog_ubuntu-impish-amd64.kopanocore_8.7.0-7.1ubuntu3_BUILDING.txt.gz

The problem happens because the php-mapi binary package cannot be built. The php-mapi package carries PHP bindings, and they are compatible with PHP 7.4 only.

Here's the lay of the land:

- kopanocore has been orphaned in Debian. It's a complex package and is lagging behind from upstream (Debian and Ubuntu carry version 8.7, whereas upstream is already on version 11).

- Initially we thought it'd be possible to just get rid of the php-mapi package and be done with it. Indeed, doing this makes the package build fine, but unfortunately php-mapi has reverse deps:

Reverse-Depends
* kopano-webapp-common
* z-push-backend-kopano
* z-push-kopano-gab2contacts
* z-push-kopano-gabsync

- The z-push package is *also* orphaned in Debian.

- Upstream kopanocore already supports PHP 8.0, but I don't think the patch is backportable:

https://github.com/Kopano-dev/kopano-core/commit/9b3bbd27ea63af180ce73a30a218d34b6e6535a4

But I may be wrong.

- Last, but not least, kopanocore blocks the OpenLDAP 2.5 transition.

I'm not entirely convinced of what the best course of action is here. I don't think that we can just remove php-mapi and the related rdeps, but OTOH backporting the patch mentioned above or updating the whole kopanocore package seems too difficult.

[Bryce Harrington (bryce)]

The patch is in line with the type of patching we've been doing for PHP 8. It does seem to be a hard patch, and has a lot of conflicts when applying, but may be the best path here.

[Bryce Harrington (bryce)]

I took a shot at backporting the patch, however no sign of mapi.so in the build log; I gather something more is involved than just this patch to get php8 working.

Regarding the idea of removing php-mapi and z-push, it looks like z-push is just an enhancement to kopano. I don't think we'd risk breaking anything beyond kopano if we removed it for impish. We could then re-evaluate it down the road when debian has moved to php8.

[Utkarsh Gupta (utkarsh)]

I have few more additions to this bug. Whilst I am still struggling with the after-effects of the first shot, I'd like to mention them here so as to hopefully unblock others or at least give ideas that might help.

If you check the condition of the package, it's sort of broken. At least the autopkgtest. Check the Debian tracker: all red (:/) and there's an RC bug for that, too. This means that even if you get around to "building" this, there will still be autopkgtest failure. I haven't yet inspected what the problem is but I know that it's going to bite us here as well. So just fixing the build isn't the only thing we're trying to achieve here.

Furthermore, if you see, the package has been removed from testing because it's not suitable for a stable release. Going along those lines, I think I would personally prefer to ask the AA to remove this package from the "release" pocket and just let it be there in the "proposed" pocket until things are fixed in Debian or at least we have somebody here who cares for this. And I am pretty sure that it's reasonable enough to ask this.

Once this happens, the package would no longer be a problem for openldap or anything else. In case it sees a fix then, awesome, else, oh well! ¯\_(ツ)_/¯

Personally, I don't think it's worthy of fixing this unless we *really* care about it, which looks unlikely. Thoughts?

[Bryce Harrington (bryce)]

One of the reasons the original patch did not apply is because php7-ext/ got merged into php-ext/ at one point (commit b8d29e9f58440f1d75bddf77df3d25fd6367af20 specifically). The files in the two directories are roughly similar, though, and as along as same changes are applied to both then we should be fine.

Another reason the patch doesn't apply is due to refactoring the wrappers to new API calls that this version doesn't have.

The patch also updates the php test, but in our version we don't even have the test framework in place to run it. Easiest to just omit the test case change.

Anyway, working through all that I got a buildable package. I'm going to go ahead and directly upload it, so we can get openldap & co. moving but when you're back from vacation I'd appreciate if you'd give the patch a glance over to sanity check.

The autopkgtests failed in my local environment, but it's not "clean" so may have tripped over past database entries. So it may get stuck migrating, but at least having the built package in -proposed will let some things process a bit further.

[Bryce Harrington (bryce)]

My hunch apparently was not too far off mark, as the tests did indeed pass. kopanocore now no longer is a blocker for openldap or php8 migrations; instead now openldap blocks kopanocore and php8. So not 100% finished but the FTBFS is sorted and kopanocore should need no further attention, hence this bug can be closed.

Utkarsh, yeah I also saw the red in debian's CI, however the test failures I reproduced don't match the ones in debian. Those test failures appear to be some mysql/mariadb confusion during the setup part of the test; the issues I was hitting occur a little later in the test during the auth prep, so it didn't quite feel like an apples to apples situation.

If my hunch had been wrong and the autopkgtests continued to fail, next step was going to be to consider disabling or hinting the still-failing tests. Or perhaps your proposal would have been better. Would have been an interesting debate. :-) And I'm also not at all opposed to dropping kopanocore + company from the archive should it continue to cause maintenance trouble; the package we're shipping is quite old compared with current upstream, and I suspect we have few users of it.

[Sergio Durigan Junior (sergiodj)]

Thanks for taking care of this one while I was away, Bryce.