PHP 8.1 - initial packaging

[GrahamCampbell]

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? :)

[sinbadxiii]

I join @GrahamCampbell, I am also interested in this question :)

[oerdnj]

[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.

[krusic22]

There it is.

[brainexe]

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

[mvorisek]

@oerdnj can we have this issue reopened and can you write any estimate?

[oerdnj]

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.

[GrahamCampbell]

Is the packaging code open source? That would allow community contributions.

[oerdnj]

Of course it is and it always was. The location is in the source package headers (https://salsa.debian.org/php-team/php).

[taylorotwell]

@oerdnj what is the quote for the fixed estimate? 💸 thanks

[oerdnj]

@taylorotwell $2000 for the PHP and $1000 for doing maintenance on the PECL extensions.

[ottok]

@taylorotwell Seravo can pay 1500€ if you pay the other half.

[taylorotwell]

@ottok OK. Email me (taylor at laravel dot com) and @oerdnj and we can coordinate?

[ottok]

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.

[oerdnj]

Thanks, gentlemen, I’ll email you privately and start working on it tomorrow.

[oerdnj]

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.

[TomasVotruba]

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.

[stancl]

And for the rest of us who can't send large sums but have benefited from Ondřej's work in the past...

[oerdnj]

@TomasVotruba @stancl Thanks!

[oerdnj]

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.

[alecpl]

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.

[oerdnj]

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.

[oerdnj]

@alecpl There's updated php-pear package, could you try whether it works out of the box now, please?

[alecpl]

Thanks, it's working now. I don't see any issues.

[oerdnj]

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.

[alecpl]

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

[krusic22]

Just replace 'php8_module' with 'php_module'. Explained here.

[alecpl]

Worked. Thanks.

[solracsf]

@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

[ottok]

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

[ottok]

Also noticed there is no php8.0-xdebug module, and the old php7.4-xdebug also disappeared (which seems like a regression).

[oerdnj]

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

[oerdnj]

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

[ottok]

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.

[ottok]

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:

[Mike-Benoit]

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!

[GrahamCampbell]

@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.

[oerdnj]

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.

[GrahamCampbell]

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.

[GrahamCampbell]

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)

[GrahamCampbell]

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

[thbley]

@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

[oerdnj]

I think I am done here. The rest of the extensions will be updated as the PHP 8.0 support becomes available.

[oerdnj]

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?

[GrahamCampbell]

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.

[GrahamCampbell]

[rfay]

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.

[oerdnj]

The Ubuntu has it already available. I will start rebuilding the extensions for Debian soon.

[onlime]

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

[f1mishutka]

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.

[onlime]

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 <team+php-pecl@tracker.debian.org>
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