The following items will cause this application to likely break once PHP 5.6 is removed at the end of 2018/early 2019 due to End-of-Life (older versions have the same or more problems): File: work/davical-1.1.7/inc/caldav-client.php > Line 51: [Error] PHP 4 constructors are now deprecated function CalDAVClient($base_url, $user, $pass, $calendar = '') { } File: work/davical-1.1.7/inc/PublicSession.php > Line 62: [Error] PHP 4 constructors are now deprecated function PublicSession() { } File: work/davical-1.1.7/inc/HTTPAuthSession.php > Line 63: [Error] PHP 4 constructors are now deprecated function HTTPAuthSession() { }
The first one (caldav-client.php) does not seem to have any effect, since it seems to be dead code that is not required anymore (will create a pull request for removal upstream). I will have a look at the other cases in the next days, since the constructors seem to be non empty and are not matched by a __construct(). Thus they are no fallback versions of a constructor. I am wondering if they are actually unused or the values get set after initialization since I am running davical 1.1.7 with PHP 7.1 since a while and have not noticed any breakage, but at least there are other files referencing them. Anyway, that should be fixed in one or the other way. How did you stumble over this problem? Maybe I should include the step in my testing.
(In reply to Till Schäfer from comment #1) > The first one (caldav-client.php) does not seem to have any effect, since it > seems to be dead code that is not required anymore (will create a pull > request for removal upstream). > > I will have a look at the other cases in the next days, since the > constructors seem to be non empty and are not matched by a __construct(). > Thus they are no fallback versions of a constructor. > > I am wondering if they are actually unused or the values get set after > initialization since I am running davical 1.1.7 with PHP 7.1 since a while > and have not noticed any breakage, but at least there are other files > referencing them. Anyway, that should be fixed in one or the other way. > > How did you stumble over this problem? Maybe I should include the step in my > testing. I did not do any runtime testing. Just a cursory overview using the https://github.com/sstalle/php7cc/releases tool to help me look at certain files.
FWIW, this will not cause an error directly, but the constructor will be assumed to be empty. Therefore runtime results may vary between versions.
Created upstream bug report and merge request to use __construct. I will wait for the upstream response for a while and decide if I will create a patched revision based on the feedback. https://gitlab.com/davical-project/davical/issues/142
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=71c1797a48ef1d612091642a18e6b9cafe60346f commit 71c1797a48ef1d612091642a18e6b9cafe60346f Author: Till Schäfer <till2.schaefer@uni-dortmund.de> AuthorDate: 2018-11-28 17:40:06 +0000 Commit: Virgil Dupras <vdupras@gentoo.org> CommitDate: 2018-12-06 01:06:02 +0000 www-apps/davical: fix php4 style constructors Closes: https://bugs.gentoo.org/650926 Package-Manager: Portage-2.3.51, Repoman-2.3.11 Signed-off-by: Till Schäfer <till2.schaefer@uni-dortmund.de> Closes: https://github.com/gentoo/gentoo/pull/10513 Signed-off-by: Virgil Dupras <vdupras@gentoo.org> www-apps/davical/davical-1.1.7-r1.ebuild | 61 ++++++++++++++++++++++ ...davical-1.1.7-fix_php4_style_constructors.patch | 39 ++++++++++++++ 2 files changed, 100 insertions(+)
