> On 1. 1. 2022, at 9:01, Paul Gevers <elb...@debian.org> wrote: > > Hi, > > On 31-12-2021 21:25, Paul Gevers wrote: >> Hi Ondřej, PHP PECL Maintainers, >> On 31-12-2021 12:50, Ondřej Surý wrote: >>> Uploaded php 8.1.1 and php-defaults 91 switching the Debian PHP version to >>> PHP 8.1 >> Thanks. >> Will you also upload src:php-imagick, which seems to block some rebuilds in >> the current state. >> I want to update the ben transition tracker file to catch these kind of >> packages. Should I add a "Depends on php7.4-common" to the "bad" list? > > It seems I don't understand how PHP packaging works. I scheduled rebuilds of > several packages that were yesterday on the tracker page [1] when that still > only had the phpapi-* listed. Several packages can't be build yet it seems > (because they depend on packages that need new uploads), but e.g. wikidiff2 > built fine *but disappeared* from the tracker. I looked at a build log [2] > and noticed that the binary has files in /etc/php8.1 (and not in > /etc/php7.4), but doesn't tell otherwise (in package relations) that it's > meant for php8.1 and not for php7.4. Why did that phpapi-* thing disappear? > Is that intended? The built binaries already migrated to testing, while the > default there is still php7.4. I assume we can consider php-wikidiff2 > (partially?) broken now *in testing*? Same for php-luasandbox [3], php-geos > [4], and php-excimer [5] (which also FTBFS on mipsel).
This has been tracker as #1000233 and hopefully fixed in dh-php 4.4 > Some rebuilds failed, e.g. php-horde-lz4 [6], The FTBFS is unrelated to PHP 8.1 transition > php-wmerrors [7], owfs [8]. These two need upstream update. > I also notice that quite some php packages grew a php7.4-* package in > unstable. Is the idea that that needs to be done for php8.1 too and that all > those packages require a round trip through NEW? If that's the case, next > time please prepare those in experimental, such that we don't need to wait > for processing of NEW during the transition. If that's not the case, please > upload new versions of those packages dropping the php7.4 package. Yes, I rewrote the helper scripts for PECL based packages, and I haven’t realized this. The idea is to align the embedded extensions schema[a] with the externally (PECL) distributed extensions. This is bit tricky though, I was faced with two options: 1. Add all binary packages to debian/control directly and do the NEW queue 2. Generate all binary packages to debian/control during the build, but this would then require overrides (which I think doesn’t really scale) > Please enlighten me on the details of php packaging that I'm missing and that > we should be aware of for this (and future) transition(s). Currently, there are two types: 1. arch:any php-<name> that contains the extension and the configuration - uses whatever build system is there 2. arch:all php-<name> depending on arch:any phpX.Y-<name> that uses /usr/share/dh-php/pkg-pecl.mk Makefile snippet which does a lot of “magic”, but so is a bit fragile as everything that is “magic” is. Ondrej a. Arch: any package php<maj>.<min>-<ext> and Arch: all package php-<ext> that depend on it -- Ondřej Surý (He/Him) ond...@sury.org > Paul > > [1] https://release.debian.org/transitions/html/php8.1.html > [2] > https://buildd.debian.org/status/fetch.php?pkg=wikidiff2&arch=amd64&ver=1.13.0-1%2Bb1&stamp=1640981156&raw=0 > [3] https://buildd.debian.org/status/package.php?p=php-luasandbox > [4] https://buildd.debian.org/status/package.php?p=php-geos > [5] https://buildd.debian.org/status/package.php?p=php-excimer > [6] https://buildd.debian.org/status/package.php?p=php-horde-lz4 > [7] https://buildd.debian.org/status/package.php?p=php-wmerrors > [8] https://buildd.debian.org/status/package.php?p=owfs
signature.asc
Description: Message signed with OpenPGP
