deb.sury.org
deb.sury.org copied to clipboard
oerdnj
PHP 8.1 - initial packaging
I'm just wondering what your plan for PHP 8.0 is. Do you plan to start making php8.0 available from 8.0.0beta1, or just the RC releases, or even just the stable releases? I'm asking just so I can plan ahead for the next few weeks. That is, do I need to build PHP 8.0 myself, or will there be a pre-build extensions coming in August? :)
[Edited for PHP 8.1]
I will start packaging the PHP 8.1 somewhere between beta1 and rc1 - depends on my free time (the time I could spend with my family doesn't count as "free").
Packaging extra PHP version is usually not that complicated once I did it so many times, but it's the extra extensions that require extra work - some of the extensions are compatible right away, but some require pulling patches from upstream or external repositories. It's hard to estimate how much time this will consume.
Last time, I was asked about estimate as incentive for packaging it rather sooner than later. For PHP 8.1 (including doing all the extra work for extensions), let's go for 3000,- EUR in total.
FYI: Beta #2 is out, and #3 should follow this week. Is there a rouuughh timeline for this php8 package? I'm just planning to switch some development context already
can we have this issue reopened
No, there’s no reason to it.
and can you write any estimate?
It will be done when it will be done. If you want a fixed estimate I can certainly give you a quote.
Is the packaging code open source? That would allow community contributions.
Of course it is and it always was. The location is in the source package headers (https://salsa.debian.org/php-team/php).
@taylorotwell $2000 for the PHP and $1000 for doing maintenance on the PECL extensions.
@ottok OK. Email me (taylor at laravel dot com) and @oerdnj and we can coordinate?
Great! Send me invoicing details otto at seravo.com and we will pay. No paperwork for my part required, I trust Ondrej to keep his word due to our shared history.
I will be following https://salsa.debian.org/php-team/php/-/branches for upstream/8.0 branch to appear and will help testing once there are builds at https://launchpad.net/~ondrej/+archive/ubuntu/php?field.series_filter=bionic.
Thanks, gentlemen, I’ll email you privately and start working on it tomorrow.
JFTR I've managed to update the extra patches today, got the PHP building and now it's only the Debian bits, several paths have changed and there are changes to extensions - JSON is now always included, so no php8.0-json, it's always there and xmlrpc extension has been moved to PECL, it needs to be re-packaged again.
This is just great :+1:
@oerdnj I'd like to join these gentleman by adding 1000 $ from my @rectorphp company. For any unexpected issues that appear and as "thank you" for your long-term support on this project since PHP 5.4+.
Send me an invoice to tomas at getrector.org and we'll process it.
And for the rest of us who can't send large sums but have benefited from Ondřej's work in the past...
Anyway, the PHP 8.0.0~rc1 is available from https://launchpad.net/~ondrej/+archive/ubuntu/php-qa
It's pretty much barebones and untested - the only guarantee is "it builds" for the moment. I will start updating the tooling around the new major version tonight or tomorrow and we'll see how it goes.
Thank you. First issue I found. A lot of PEAR core libs in Ubuntu 18.04 needs update. "PHP Fatal error: Array and string offset access syntax with curly braces is no longer supported" is quite common there.
A lot of PEAR core libs in Ubuntu 18.04 needs update.
That's one package that's most painful to update :-(.
Thanks for preliminary testing.
@alecpl There's updated php-pear package, could you try whether it works out of the box now, please?
Couple of extensions have been also uploaded to php-qa; some packages are not building (yet) and it's a general mayhem, but I am making progress.
Something's wrong with the apache module.
Syntax error on line 146 of /etc/apache2/apache2.conf: Syntax error on line 3 of /etc/apache2/mods-enabled/php8.0.load: Can't locate API module structure `php8_module' in file /usr/lib/apache2/modules/libphp8.0.so: /usr/lib/apache2/modules/libphp8.0.so: undefined symbol: php8_module
@oerdnj Since this, when upgrading any instance with one php version installed (Ubuntu 20.04), all versions are installed. Here upgrading one instance with only PHP7.4 installed.
Reading state information... Done
Calculating upgrade... Done
The following NEW packages will be installed:
php5.6-cli php5.6-common php5.6-igbinary php5.6-json php5.6-opcache php5.6-phpdbg php5.6-readline php7.0-cli php7.0-common php7.0-igbinary
php7.0-json php7.0-opcache php7.0-phpdbg php7.0-readline php7.1-cli php7.1-common php7.1-igbinary php7.1-json php7.1-opcache php7.1-phpdbg
php7.1-readline php7.2-cli php7.2-common php7.2-igbinary php7.2-json php7.2-opcache php7.2-phpdbg php7.2-readline php7.3-cli php7.3-common
php7.3-igbinary php7.3-json php7.3-opcache php7.3-phpdbg php7.3-readline php7.4-igbinary php8.0-cli php8.0-common php8.0-igbinary php8.0-opcache
php8.0-phpdbg php8.0-readline
The following packages will be upgraded:
php-common php-igbinary php7.4-bcmath php7.4-bz2 php7.4-cli php7.4-common php7.4-curl php7.4-fpm php7.4-gd php7.4-gmp php7.4-intl php7.4-json php7.4-mbstring
php7.4-mysql php7.4-opcache php7.4-readline php7.4-xml php7.4-zip
The contents of '/etc/php/8.0` is structured differently than in 7.4. Is this intentional?
# find /etc/php/8.0/ -maxdepth 2
/etc/php/8.0/
/etc/php/8.0/mods-available
/etc/php/8.0/mods-available/ctype.ini
/etc/php/8.0/mods-available/ldap.ini
/etc/php/8.0/mods-available/ffi.ini
/etc/php/8.0/mods-available/posix.ini
/etc/php/8.0/mods-available/sysvsem.ini
/etc/php/8.0/mods-available/shmop.ini
/etc/php/8.0/mods-available/igbinary.ini
/etc/php/8.0/mods-available/calendar.ini
/etc/php/8.0/mods-available/gettext.ini
/etc/php/8.0/mods-available/bcmath.ini
/etc/php/8.0/mods-available/readline.ini
/etc/php/8.0/mods-available/imagick.ini
/etc/php/8.0/mods-available/sysvmsg.ini
/etc/php/8.0/mods-available/redis.ini
/etc/php/8.0/mods-available/exif.ini
/etc/php/8.0/mods-available/gmp.ini
/etc/php/8.0/mods-available/sysvshm.ini
/etc/php/8.0/mods-available/ftp.ini
/etc/php/8.0/mods-available/phar.ini
/etc/php/8.0/mods-available/tokenizer.ini
/etc/php/8.0/mods-available/pdo.ini
/etc/php/8.0/mods-available/iconv.ini
/etc/php/8.0/mods-available/fileinfo.ini
/etc/php/8.0/mods-available/intl.ini
/etc/php/8.0/mods-available/opcache.ini
/etc/php/8.0/mods-available/sockets.ini
/etc/php/8.0/phpdbg
/etc/php/8.0/phpdbg/php.ini
/etc/php/8.0/phpdbg/conf.d
/etc/php/8.0/cli
/etc/php/8.0/cli/php.ini
/etc/php/8.0/cli/conf.d
vs.
# find /etc/php/7.4/ -maxdepth 2
/etc/php/7.4/
/etc/php/7.4/fpm
/etc/php/7.4/fpm/pool.d
/etc/php/7.4/fpm/php.ini
/etc/php/7.4/fpm/php-fpm.conf
/etc/php/7.4/fpm/conf.d
/etc/php/7.4/mods-available
/etc/php/7.4/mods-available/zip.ini
/etc/php/7.4/mods-available/ctype.ini
/etc/php/7.4/mods-available/mysqlnd.ini
/etc/php/7.4/mods-available/ldap.ini
/etc/php/7.4/mods-available/xmlrpc.ini
/etc/php/7.4/mods-available/ffi.ini
/etc/php/7.4/mods-available/tidy.ini
/etc/php/7.4/mods-available/posix.ini
/etc/php/7.4/mods-available/gd.ini
/etc/php/7.4/mods-available/sysvsem.ini
/etc/php/7.4/mods-available/soap.ini
/etc/php/7.4/mods-available/shmop.ini
/etc/php/7.4/mods-available/igbinary.ini
/etc/php/7.4/mods-available/xmlwriter.ini
/etc/php/7.4/mods-available/calendar.ini
/etc/php/7.4/mods-available/sqlite3.ini
/etc/php/7.4/mods-available/xmlreader.ini
/etc/php/7.4/mods-available/mbstring.ini
/etc/php/7.4/mods-available/gettext.ini
/etc/php/7.4/mods-available/bcmath.ini
/etc/php/7.4/mods-available/pdo_sqlite.ini
/etc/php/7.4/mods-available/ssh2.ini
/etc/php/7.4/mods-available/readline.ini
/etc/php/7.4/mods-available/imagick.ini
/etc/php/7.4/mods-available/sysvmsg.ini
/etc/php/7.4/mods-available/redis.ini
/etc/php/7.4/mods-available/exif.ini
/etc/php/7.4/mods-available/pdo_mysql.ini
/etc/php/7.4/mods-available/simplexml.ini
/etc/php/7.4/mods-available/imap.ini
/etc/php/7.4/mods-available/memcache.ini
/etc/php/7.4/mods-available/xsl.ini
/etc/php/7.4/mods-available/gmp.ini
/etc/php/7.4/mods-available/xml.ini
/etc/php/7.4/mods-available/sysvshm.ini
/etc/php/7.4/mods-available/json.ini
/etc/php/7.4/mods-available/mysqli.ini
/etc/php/7.4/mods-available/ftp.ini
/etc/php/7.4/mods-available/dom.ini
/etc/php/7.4/mods-available/phar.ini
/etc/php/7.4/mods-available/tokenizer.ini
/etc/php/7.4/mods-available/pdo.ini
/etc/php/7.4/mods-available/curl.ini
/etc/php/7.4/mods-available/iconv.ini
/etc/php/7.4/mods-available/fileinfo.ini
/etc/php/7.4/mods-available/intl.ini
/etc/php/7.4/mods-available/opcache.ini
/etc/php/7.4/mods-available/sockets.ini
/etc/php/7.4/mods-available/tideways.ini
/etc/php/7.4/cli
/etc/php/7.4/cli/php.ini
/etc/php/7.4/cli/conf.d
Also noticed there is no php8.0-xdebug module, and the old php7.4-xdebug also disappeared (which seems like a regression).
Also noticed there is no php8.0-xdebug module, and the old php7.4-xdebug also disappeared (which seems like a regression).
There's no xdebug for PHP 8.0 yet, and php7.4-xdebug should be restored at least for some archs: https://launchpad.net/~ondrej/+archive/ubuntu/php/+build/20140163
The contents of '/etc/php/8.0` is structured differently than in 7.4. Is this intentional?
What's different there?
The phpdbg is a SAPI that got pulled due this issue: https://github.com/oerdnj/deb.sury.org/issues/1465
Sorry for the noise about /etc/php/8.0/fpm, that was my error, installed php7.4-fpm while testing. When installing php8.0-fpm all is good.
Have been testing today and the packaging of PHP 8.0 RC1 seems all good so far. Only thing missing in php8.0-xdebug which I assume will be sorted out later. Thanks! :ok_hand:
Just a heads up, Xdebug v3.0-beta for PHP 8 released today: https://github.com/xdebug/xdebug/releases -- Thanks for all your hard work Ondrej!
@oerdnj Even though xdebug 3.0 will be compatible with PHP 7.2, I don't think it should ever be used, because phpunit 8 will crash with xdebug 3.0 and phpunit 9 doesn't supporr PHP 7.2. Thus, the best thing to do for packaging is to ship Xdebug 2.9.x for both PHP 7.1 and 7.2, and xdebug 3.x for PHP 7.3+ once it's stable.
My plan was to use xdebug 3.0 only for PHP 8.0+ at this moment.
I’ll probably ship a version for 5.6, version for 7.0-7.2 and version for 7.3-8.0 to keep my sanity.
Right. My point was that xdebug 3.0 will be compatible with 7.2, but I don't think this ppa should use that version, ever, because of the phpunit compat issue.
version for 7.0-7.2
7.0 and 7.1 have different max compatible versions:
NB that table has a typo (7.1 is not actually supported by xdebug 3.0)
I guess, to be explicit, what I am proposing is (once xdebug 3.0 is stable):
- PHP 5.6: xdebug 2.5.x
- PHP 7.0: xdebug 2.7.x
- PHP 7.1: xdebug 2.9.x
- PHP 7.2: xdebug 2.9.x
- PHP 7.3: xdebug 3.0.x
- PHP 7.4: xdebug 3.0.x
- PHP 8.0: xdebug 3.0.x
@oerdnj Big thanks for providing PHP8 packages, tests on stretch and buster are looking good so far!
For those who want to compile pecl extensions manually before the packages are available, I'm using:
DEBIAN_FRONTEND=noninteractive apt-get -y --no-install-recommends install make php8.0-dev \
&& mkdir -p /usr/src/php/ext/apcu \
&& curl -fsSL https://pecl.php.net/get/apcu | tar xvz -C "/usr/src/php/ext/apcu" --strip 1 \
&& cd /usr/src/php/ext/apcu \
&& phpize8.0 \
&& autoreconf -fi \
&& ./configure \
&& make \
&& make install \
&& echo "extension=apcu.so" >/etc/php/8.0/mods-available/apcu.ini \
&& phpenmod apcu \
&& mkdir -p /usr/src/php/ext/pcov \
&& curl -fsSL https://pecl.php.net/get/pcov | tar xvz -C "/usr/src/php/ext/pcov" --strip 1 \
&& cd /usr/src/php/ext/pcov \
&& phpize8.0 \
&& autoreconf -fi \
&& ./configure \
&& make \
&& make install \
&& echo "extension=pcov.so" >/etc/php/8.0/mods-available/pcov.ini \
&& phpenmod pcov \
&& mkdir -p /usr/src/php/ext/xdebug \
&& curl -fsSL https://pecl.php.net/get/xdebug | tar xvz -C "/usr/src/php/ext/xdebug" --strip 1 \
&& cd /usr/src/php/ext/xdebug \
&& phpize8.0 \
&& autoreconf -fi \
&& ./configure \
&& make \
&& make install \
&& echo "zend_extension=xdebug.so" >/etc/php/8.0/mods-available/xdebug.ini \
&& phpenmod xdebug
I think I am done here. The rest of the extensions will be updated as the PHP 8.0 support becomes available.
I guess, to be explicit, what I am proposing is (once xdebug 3.0 is stable):
- PHP 5.6: xdebug 2.5.x
- PHP 7.0: xdebug 2.7.x
- PHP 7.1: xdebug 2.9.x
- PHP 7.2: xdebug 2.9.x
- PHP 7.3: xdebug 3.0.x
- PHP 7.4: xdebug 3.0.x
- PHP 8.0: xdebug 3.0.x
The PHP 7.0 is already at xdebug 2.8.1, @GrahamCampbell, are you sure you got the table right?
The PHP 7.0 is already at xdebug 2.8.1, @GrahamCampbell, are you sure you got the table right?
Yeh, it compiles, but doesn't work properly. I think Derek retrospectively dropped PHP 7.0 support from that version after releasing. That table is taken from xdebug's website.
I would love to see the xdebug 3.0.0beta1 go in on php8. If I understand right though it has some changes to config names, so may not be compatible out of the box with existing configs, so might not be a really great choice for php7.3 and 7.4 right now.
The Ubuntu has it already available. I will start rebuilding the extensions for Debian soon.
Great @oerdnj thanks for releasing final PHP 8.0.0 for Debian! Any ETA when the following extensions will be available?
- imagick
- apcu
- mailparse
Will those still be included in the global php-imagick, php-apcu, php-mailparse packages?
While imagick AFAIK is not ready yet, the following versions just compiled fine under PECL, using your latest phpize8.0: mailparse 3.1.1, apcu 5.1.19
/usr/bin/phpize8.0
./configure --with-php-config=/usr/bin/php-config8.0
make clean
make
make install
Cheers, Philip
Waiting for php-redis and php-apcu packages.
Both are being compiled fine using pecl install php-xxx. But I don't want to compile them manually in production environment.
Thanks @oerdnj for providing us apcu!
php-apcu is now out for PHP 8.0 and should be installed as version specific package, e.g. php8.0-apcu. For those who did not pick it up, here's Ondřej's October update for DEB.SURY.ORG repositories
$ apt info php8.0-apcu
Package: php8.0-apcu
Version: 5.1.19+4.0.11-2+0~20201204.15+debian10~1.gbpa95fb8
Priority: optional
Section: php
Source: php-apcu
Maintainer: Debian PHP PECL Maintainers <[email protected]>
Installed-Size: 189 kB
Provides: php-apcu
Pre-Depends: php-common (>= 2:69~)
Depends: libc6 (>= 2.14)
Recommends: php-apcu-bc
Suggests: php-gd
Conflicts: php-xcache, php-yac
Breaks: php-apcu (<< 5.1.19+4.0.11-2+0~20201204.15+debian10~1.gbpa95fb8~)
Replaces: php-apcu (<< 5.1.19+4.0.11-2+0~20201204.15+debian10~1.gbpa95fb8~)
Homepage: https://pecl.php.net/package/APCu
Download-Size: 44.7 kB
APT-Manual-Installed: yes
APT-Sources: https://packages.sury.org/php buster/main amd64 Packages
I confirm php8.0-apcu and php8.0-redis in there, yay and thanks!
php8.0-imagick is not there yet,
php8.0-imagick is now also there, thanks a lot @oerdnj !!
$ apt info php8.0-imagick
Package: php8.0-imagick
Version: 3.4.4-10+0~20201209.22+debian10~1.gbp2e170e
Priority: optional
Section: php
Source: php-imagick
Maintainer: Debian PHP PECL Maintainers <[email protected]>
Installed-Size: 503 kB
Provides: php-imagick
Pre-Depends: php-common (>= 2:69~)
Depends: libc6 (>= 2.14), libmagickcore-6.q16-6 (>= 8:6.9.10.2), libmagickwand-6.q16-6 (>= 8:6.9.10.2)
Recommends: ghostscript, ttf-dejavu-core
Breaks: php-imagick (<< 3.4.4-10+0~20201209.22+debian10~1.gbp2e170e~)
Replaces: php-imagick (<< 3.4.4-10+0~20201209.22+debian10~1.gbp2e170e~)
Homepage: http://pecl.php.net/package/imagick
Download-Size: 102 kB
APT-Manual-Installed: yes
APT-Sources: https://packages.sury.org/php buster/main amd64 Packages
Description: Provides a wrapper to the ImageMagick library
Imagick is a native php extension to create and modify images using the
ImageMagick API.
This extension requires ImageMagick version 6.2.4+ and PHP 5.1.3+.
.
IMPORTANT: Version 2.x API is not compatible with earlier versions.
... even though https://github.com/Imagick/imagick/issues/358 is not resolved yet, imagick compiles fine from master branch.
I am wondering if anyone knows any timing on release of ssh2 for php8.0.
I am wondering if anyone knows any timing on release of ssh2 for php8.0.
Not the best place for this question, but 10 days ago the timing for 1.3 release was "Working on it". https://github.com/php/pecl-networking-ssh2/pull/44
The beta3 has been uploaded to ppa:ondrej/php-qa repository, let's see what happens during the build...
Working for ddev too in https://github.com/drud/ddev/pull/3198, thanks! Top of my wishlist is xdabug and xhprof :)
Some packages not available in 8.1 (joglomedia/LEMPer#106)
E: Unable to locate package php8.1-gnupg
E: Couldn't find any package by glob 'php8.1-gnupg'
E: Couldn't find any package by regex 'php8.1-gnupg'
E: Unable to locate package php8.1-xmlrpc
E: Couldn't find any package by glob 'php8.1-xmlrpc'
E: Couldn't find any package by regex 'php8.1-xmlrpc'
E: Unable to locate package php8.1-swoole
E: Couldn't find any package by glob 'php8.1-swoole'
E: Couldn't find any package by regex 'php8.1-swoole'
The packages are available on older versions
Do you plan to add them? or there any alternative?
Thanks
PHP 8.1 release candidate is here.
the PHP_API_VERSION constant (in php.h) changed from 20201009 (in beta) to 20210902 (in release candidate). Based on previous PHP version, I suppose the PHP_API_VERSION value from RC is the final value.
php extension binary build againt current PHP 8.1 package (beta) will be incompatible with PHP 8.1 RC and final.
So, if this is possible for you, @oerdnj , I think it'll be useful if you can update your package to RC. So we will start produce binary without compatibility problem.
regards, and thank you for the work!
php extension binary build against current PHP 8.1 package (beta) will be incompatible with PHP 8.1 RC and final.
Yup, that's why I am waiting with building the PECL extensions until the PHPAPI stabilizes...
So, if this is possible for you, @oerdnj , I think it'll be useful if you can update your package to RC. So we will start produce binary without compatibility problem.
On it...
Thanks so much for all of this. Could we get xdebug in soon?
I'm doing a major release of ddev in the next few days and it would be oh-so-lovely if we could have xdebug for php8.1.0RC1 in there. I took a quick look at pecl install xdebug-3.1.0beta2 and it seemed to be fine, so it would be lovely to see it.
And @derickr is quite confident of it with PHP8.1, https://twitter.com/derickr/status/1438554237177372684
Hi @oerdnj,
I would like to thank you for your endless work you do for our PHP community :clap: :+1: :heart:
Not just in words, but also chip in sponsoring from last year. Could you send me an invoice for 1000 $?
Thanks for getting php RC4 in there.
Really, really hoping for php8.1-xdebug (especially now that xdebug 3.1.1 is in there, and should work fine with php 8.1).
Also, please bump uploadprogress to current 2.0.2 so it will work with both php 8.0 and 8.1 (really bad right now). https://pecl.php.net/package/uploadprogress