Mentioned in SAL (#wikimedia-operations) [2025-02-24T21:33:08Z] <swfrench-wmf> reprepro include php8.1_8.1.31-1+wmf11u3 php-apcu_5.1.23-1+wmf11u3 into component/php81 - T386006

Change #1122258 had a related patch set uploaded (by Jforrester; author: Jforrester):

[integration/config@master] [WIP] Docker: [php81] Upgrade Wikimedia-provided PHP to 8.1.31-1+wmf11u3

https://gerrit.wikimedia.org/r/1122258

Thanks for the follow-up, @hashar!

That's great that the CI images using sury.org packages for 8.2 and 8.3 are already exercising PCRE2 10.40. That significantly narrows the gap vs. the 10.42 version we're backporting from bookworm.

Alright, to recap where things are at for the moment:

I've included rebuilds in component/php81 that revert back to the stock bullseye 10.36 package for now - i.e., we're back in the state we were earlier today.

The reason I did that is I'd like to reassess how the custom components are laid out in order to minimize potential gotchas, as well as some surprises involving dependency version behavior.

Original plan: My plan was to include the 10.42 backport in component/pcre2 (done) and use said component in rebuilds for packages with a build dependency on pcre2, including the latter in component/php81 (done). Then, in places where we use component/php81, I would also add the component/pcre2 component.

The motivation behind using a standalone component for PCRE2, vs. including the new packages directly in component/php81, was to avoid immediately introducing a newer PCRE2 version than the collocated php packages had been built with. In addition, we expect component/pcre2 to see some reuse.

This is largely what I did today, up until the last step, where I was testing image builds (https://gerrit.wikimedia.org/r/1120588) locally before merging.

Problem: When doing that, I realized there's a subtle issue: Since docker-registry.wikimedia.org/bullseye already installs PCRE2 (10.36), it seems that simply adding a sources list file for component/pcre2 is not sufficient to also upgrade it during installation of php packages.

Either an explicit upgrade or adding libpcre2-8-0 to the list of packages install is needed in order to get the "right" version. This also true regardless of whether we're using a separate component for PCRE2 vs. dropping it in component/php81.

What's a bit concerning to me here is that, implicitly, there's something interesting going on with resolution of ${shlibs:Depends} if the version bound is not being set to what was being used at build time (if I understand correctly; see edit below - I did not, heh), which would have forced an updated when the php packages were installed. Indeed, it seems to be set to:

Depends: ... libpcre2-8-0 (>= 10.32) ...

Edit: Never mind, I now see based on the contents of /var/lib/dpkg/info/libpcre2-8-0:amd64.symbols that 10.32 is actually the expected outcome of running dpkg-shlibdeps given the PCRE2 symbols actually used. So yes, this is entirely the expected behavior, which should have been obvious to me in retrospect :)

In any case, before potentially switching gears to a different layout for the components (e.g., either include PCRE2 directly in component/php81 or, a potentially cleaner option, create a separate php81-pcre2 component that contains both), it would be good to know if there are patterns for this that might be less error prone in contexts where PCRE2 is already installed (albeit at an older version).

I'm wondering whether this is something that @MoritzMuehlenhoff or @MatthewVernon may have seen before, and have any thoughts.

After a bit more thought, I think sticking with the original plan (i.e., the backport goes in component/pcre2), and being sure to update use cases of component/php81 to apt-get install the libpcre2-8-0 package to upgrade, is probably the simplest option.

I've updated https://gerrit.wikimedia.org/r/c/operations/docker-images/production-images/+/1120588 to go that route. We should be able to do something similar in quibble-bullseye-php81.

If folks have strong opinions otherwise, though, I'm happy to reconsider.

I'd seen your question about ${shlibds:Depends}, but I see you answered it yourself. But yes, Depends: should express the necessary runtime dependency, which is not necessarily what version the package was built again. If you want to check that, it should be in the .\buildinfo file.

Change #1120588 merged by Effie Mouzeli:

[operations/docker-images/production-images@master] php8.1: use pcre2 backport

https://gerrit.wikimedia.org/r/1120588

Mentioned in SAL (#wikimedia-operations) [2025-02-25T11:30:56Z] <jiji@deploy2002> Started scap sync-world: T386006 - use pcre2 backport in php8.1 images

Mentioned in SAL (#wikimedia-operations) [2025-02-25T11:55:27Z] <jiji@deploy2002> Finished scap sync-world: T386006 - use pcre2 backport in php8.1 images (duration: 25m 34s)

Deployed the latest images which include php8.1_8.1.31-1+wmf11u3 php-apcu_5.1.23-1+wmf11u3 and pcre2_10.42-1~wmf11+1!
Many thanks to @MatthewVernon for giving us a hand!

@Scott_French I reckon we can close this as soon as we pickup ramping up traffic where we left off?

Change #1122258 merged by jenkins-bot:

[integration/config@master] Docker: [php81] Upgrade Wikimedia's PHP to 8.1.31-1+wmf11u3 & PCRE to 10.42

https://gerrit.wikimedia.org/r/1122258

Mentioned in SAL (#wikimedia-releng) [2025-02-25T14:07:10Z] <James_F> Docker: [php81] Upgrade Wikimedia's PHP to 8.1.31-1+wmf11u3 & PCRE to 10.42 for T386006

Change #1122588 had a related patch set uploaded (by Jforrester; author: Jforrester):

[integration/config@master] jjb: Switch PHP 8.1 jobs to 8.1.31 + PCRE 10.42

https://gerrit.wikimedia.org/r/1122588

Alright, so it looks like there's been some miscommunication: for the time being, please wait before taking any action the wmf11u3 builds currently live in component/php81 are not built against pcre2 10.42. This is what I meant by:

I've included rebuilds in component/php81 that revert back to the stock bullseye 10.36 package for now - i.e., we're back in the state we were earlier today.

... in my latest update.

Now, in practice, this "should be fine" - i.e., the API surface used should be stable since 10.32, as noted yesterday - but strictly we really should have the build dependency satisfied with the version we intend to use.

I'll try to get those live ASAP, but note that an additional round of rebuilds will be needed to pick them up.

Change #1122604 had a related patch set uploaded (by Scott French; author: Scott French):

[operations/docker-images/production-images@master] php8.1: rebuild to pick up newer php8.1 packages

https://gerrit.wikimedia.org/r/1122604

Mentioned in SAL (#wikimedia-operations) [2025-02-25T15:47:56Z] <swfrench-wmf> reprepro include php8.1_8.1.31-1+wmf11u4 into component/php81 - T386006

Mentioned in SAL (#wikimedia-operations) [2025-02-25T15:51:31Z] <swfrench-wmf> reprepro include php-apcu_5.1.23-1+wmf11u4 into component/php81 - T386006

Alright, component/php81 is now back up to date.

@Jdforrester-WMF - Thank you so much for getting the CI images up to date in https://gerrit.wikimedia.org/r/1122258! Alas, another round of rebuilds will be needed in order to pick up the wmf11u4 versions of the php 8.1 and php-apcu packages now that they've been rebuilt (again) against pcre2 10.42. No content changes are needed to your Dockerfile.template (just a rebuild that installs the latest packages from component/php81 will suffice).

Change #1122604 merged by Scott French:

[operations/docker-images/production-images@master] php8.1: rebuild to pick up newer php8.1 packages

https://gerrit.wikimedia.org/r/1122604

Mentioned in SAL (#wikimedia-operations) [2025-02-25T17:27:51Z] <swfrench-wmf> built 8.1.34-1-s2 php8.1 production images - T386006

Mentioned in SAL (#wikimedia-operations) [2025-02-25T17:32:44Z] <swfrench@deploy2002> Started scap sync-world: Use php packages built against pcre2 backport - T386006

Mentioned in SAL (#wikimedia-operations) [2025-02-25T17:56:46Z] <swfrench@deploy2002> Finished scap sync-world: Use php packages built against pcre2 backport - T386006 (duration: 26m 35s)

Change #1122658 had a related patch set uploaded (by Jforrester; author: Jforrester):

[integration/config@master] Docker: [php81] Update PHP to 8.1.31-1+wmf11u4

https://gerrit.wikimedia.org/r/1122658

Change #1122658 merged by jenkins-bot:

[integration/config@master] Docker: [php81] Update PHP to 8.1.31-1+wmf11u4

https://gerrit.wikimedia.org/r/1122658

Mentioned in SAL (#wikimedia-releng) [2025-02-25T20:25:27Z] <James_F> Docker: [php81] Update PHP to 8.1.31-1+wmf11u4, for T386006

Change #1122588 merged by jenkins-bot:

[integration/config@master] jjb: Switch PHP 8.1 jobs to 8.1.31 + PCRE 10.42

https://gerrit.wikimedia.org/r/1122588

Possibly related error in CI https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-php81-noselenium/26736/console

10:40:00 INFO:quibble.commands:>>> Start: composer test in /workspace/src/extensions/CodeMirror
10:40:00 PHP Warning:  PHP Startup: ^(text/|application/xhtml\+xml) (offset=0): unrecognised compile-time option bit(s) in Unknown on line 0
10:40:00 PHP Fatal error:  Uncaught ErrorException: preg_match_all(): Compilation failed: unrecognised compile-time option bit(s) at offset 0 in phar:///usr/bin/composer/vendor/symfony/console/Formatter/OutputFormatter.php:154
10:40:00 Stack trace:
10:40:00 #0 [internal function]: Composer\Util\ErrorHandler::handle()
10:40:00 #1 phar:///usr/bin/composer/vendor/symfony/console/Formatter/OutputFormatter.php(154): preg_match_all()
10:40:00 #2 phar:///usr/bin/composer/vendor/symfony/console/Formatter/OutputFormatter.php(137): Symfony\Component\Console\Formatter\OutputFormatter->formatAndWrap()
10:40:00 #3 phar:///usr/bin/composer/vendor/symfony/console/Output/Output.php(157): Symfony\Component\Console\Formatter\OutputFormatter->format()
10:40:00 #4 phar:///usr/bin/composer/vendor/symfony/console/Output/Output.php(132): Symfony\Component\Console\Output\Output->write()
10:40:00 #5 phar:///usr/bin/composer/vendor/symfony/console/Application.php(838): Symfony\Component\Console\Output\Output->writeln()
10:40:00 #6 phar:///usr/bin/composer/vendor/symfony/console/Application.php(154): Symfony\Component\Console\Application->renderThrowable()
10:40:00 #7 phar:///usr/bin/composer/vendor/symfony/console/Application.php(177): Symfony\Component\Console\Application->Symfony\Component\Console\{closure}()
10:40:00 #8 phar:///usr/bin/composer/src/Composer/Console/Application.php(147): Symfony\Component\Console\Application->run()
10:40:00 #9 phar:///usr/bin/composer/bin/composer(93): Composer\Console\Application->run()
10:40:00 #10 /usr/bin/composer(29): require('...')
10:40:00 #11 {main}
10:40:00   thrown in phar:///usr/bin/composer/vendor/symfony/console/Formatter/OutputFormatter.php on line 154
10:40:00 
10:40:00 Fatal error: Uncaught ErrorException: preg_match_all(): Compilation failed: unrecognised compile-time option bit(s) at offset 0 in phar:///usr/bin/composer/vendor/symfony/console/Formatter/OutputFormatter.php:154
10:40:00 Stack trace:
10:40:00 #0 [internal function]: Composer\Util\ErrorHandler::handle()
10:40:00 #1 phar:///usr/bin/composer/vendor/symfony/console/Formatter/OutputFormatter.php(154): preg_match_all()
10:40:00 #2 phar:///usr/bin/composer/vendor/symfony/console/Formatter/OutputFormatter.php(137): Symfony\Component\Console\Formatter\OutputFormatter->formatAndWrap()
10:40:00 #3 phar:///usr/bin/composer/vendor/symfony/console/Output/Output.php(157): Symfony\Component\Console\Formatter\OutputFormatter->format()
10:40:00 #4 phar:///usr/bin/composer/vendor/symfony/console/Output/Output.php(132): Symfony\Component\Console\Output\Output->write()
10:40:00 #5 phar:///usr/bin/composer/vendor/symfony/console/Application.php(838): Symfony\Component\Console\Output\Output->writeln()
10:40:00 #6 phar:///usr/bin/composer/vendor/symfony/console/Application.php(154): Symfony\Component\Console\Application->renderThrowable()
10:40:00 #7 phar:///usr/bin/composer/vendor/symfony/console/Application.php(177): Symfony\Component\Console\Application->Symfony\Component\Console\{closure}()
10:40:00 #8 phar:///usr/bin/composer/src/Composer/Console/Application.php(147): Symfony\Component\Console\Application->run()
10:40:00 #9 phar:///usr/bin/composer/bin/composer(93): Composer\Console\Application->run()
10:40:00 #10 /usr/bin/composer(29): require('...')
10:40:00 #11 {main}
10:40:00   thrown in phar:///usr/bin/composer/vendor/symfony/console/Formatter/OutputFormatter.php on line 154

Thanks, @tstarling!

So, if I'm understanding the changes in https://gerrit.wikimedia.org/r/1122588 correctly, it looks like quibble-{packages-source}-{database}-{php}-noselenium was updated to use docker-registry.wikimedia.org/releng/quibble-bullseye-php81:1.12.0-s2.

However:

$ docker run --entrypoint /usr/bin/php8.1 docker-registry.wikimedia.org/releng/quibble-bullseye-php81:1.12.0-s2 --ri pcre
PHP Warning:  PHP Startup: ^(text/|application/xhtml\+xml) (offset=0): unrecognised compile-time option bit(s) in Unknown on line 0

pcre

PCRE (Perl Compatible Regular Expressions) Support => enabled
PCRE Library Version => 10.36 2020-12-04
PCRE Unicode Version => 13.0.0
PCRE JIT Support => enabled
PCRE JIT Target => x86 64bit (little endian + unaligned)

Directive => Local Value => Master Value
pcre.backtrack_limit => 1000000 => 1000000
pcre.recursion_limit => 100000 => 100000
pcre.jit => 1 => 1

$ docker run --entrypoint apt docker-registry.wikimedia.org/releng/quibble-bullseye-php81:1.12.0-s2 list --installed | grep -E '(pcre2|php8[.]1)'

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

libpcre2-8-0/now 10.36-2+deb11u1 amd64 [installed,local]
php8.1-apcu/now 5.1.23-1+wmf11u4 amd64 [installed,local]
php8.1-bcmath/now 8.1.31-1+wmf11u4 amd64 [installed,local]
php8.1-cli/now 8.1.31-1+wmf11u4 amd64 [installed,local]
php8.1-common/now 8.1.31-1+wmf11u4 amd64 [installed,local]
php8.1-curl/now 8.1.31-1+wmf11u4 amd64 [installed,local]
php8.1-fpm/now 8.1.31-1+wmf11u4 amd64 [installed,local]
php8.1-gd/now 8.1.31-1+wmf11u4 amd64 [installed,local]
php8.1-gmp/now 8.1.31-1+wmf11u4 amd64 [installed,local]
php8.1-igbinary/now 3.2.15-1+wmf11u1 amd64 [installed,local]
php8.1-intl/now 8.1.31-1+wmf11u4 amd64 [installed,local]
php8.1-ldap/now 8.1.31-1+wmf11u4 amd64 [installed,local]
php8.1-mbstring/now 8.1.31-1+wmf11u4 amd64 [installed,local]
php8.1-memcached/now 3.2.0++-1+wmf11u1 amd64 [installed,local]
php8.1-msgpack/now 1:2.2.0-4+wmf11u1 amd64 [installed,local]
php8.1-mysql/now 8.1.31-1+wmf11u4 amd64 [installed,local]
php8.1-opcache/now 8.1.31-1+wmf11u4 amd64 [installed,local]
php8.1-pcov/now 1.0.11-5+wmf11u1 amd64 [installed,local]
php8.1-pgsql/now 8.1.31-1+wmf11u4 amd64 [installed,local]
php8.1-readline/now 8.1.31-1+wmf11u4 amd64 [installed,local]
php8.1-sqlite3/now 8.1.31-1+wmf11u4 amd64 [installed,local]
php8.1-tidy/now 8.1.31-1+wmf11u4 amd64 [installed,local]
php8.1-wikidiff2/now 1.14.1-2+wmf11u2 amd64 [installed,local]
php8.1-xml/now 8.1.31-1+wmf11u4 amd64 [installed,local]
php8.1-zip/now 8.1.31-1+wmf11u4 amd64 [installed,local]

So yeah, it looks like PHP 8.1 packages build against PCRE2 10.42 (wmf11u4) have somehow been combined with PCRE 10.36 (i.e., stock bullseye).

Let me see if I can sort out where the component/pcre2 or apt install was missed in the hierarchy of images.

Yes, it looks like https://gerrit.wikimedia.org/r/plugins/gitiles/integration/config/+/refs/heads/master/dockerfiles/quibble-bullseye-php81/Dockerfile.template doesn't derive from a base image that was updated to pick up the component and newer PCRE2 in https://gerrit.wikimedia.org/r/c/integration/config/+/1122258.

I can post a patch to fix that, but I have zero familiarity with how these images are built / managed.

Change #1122700 had a related patch set uploaded (by Scott French; author: Scott French):

[integration/config@master] Docker: [quibble-bullseye-php81] Ensure correct PCRE2 (10.42) is used

https://gerrit.wikimedia.org/r/1122700

Change #1122701 had a related patch set uploaded (by Scott French; author: Scott French):

[integration/config@master] jjb: Update all instances of quibble-bullseye-php81 to 1.12.0-s3

https://gerrit.wikimedia.org/r/1122701

Alright, I believe merging https://gerrit.wikimedia.org/r/1122700, rebuilding the images, and then merging https://gerrit.wikimedia.org/r/1122701 should fix this.

However, that's about the limit of my knowledge in terms of how CI image are built, and am struggling to find any documentation to this effect.

@Jdforrester-WMF or @hashar - Would either of you be able to move this forward?

Change #1122700 merged by jenkins-bot:

[integration/config@master] Docker: [quibble-bullseye-php81] Ensure correct PCRE2 (10.42) is used

https://gerrit.wikimedia.org/r/1122700

Mentioned in SAL (#wikimedia-releng) [2025-02-26T01:16:44Z] <Reedy> Updating docker-pkg files on contint primary for https://gerrit.wikimedia.org/r/1122700 T386006

Confirmed that docker-registry.wikimedia.org/releng/quibble-bullseye-php81:1.12.0-s3 now has the expected PCRE2 (10.42).

Change #1122701 merged by jenkins-bot:

[integration/config@master] jjb: Update all instances of quibble-bullseye-php81 to 1.12.0-s3

https://gerrit.wikimedia.org/r/1122701

Alright, many thanks to @Reedy for the image rebuilds following https://gerrit.wikimedia.org/r/1122700 and @bd808 for updating the job definitions from https://gerrit.wikimedia.org/r/1122701.

We're now seeing the affected jobs passing again, so I believe these issues should be resolved, unless of course there's something subtle I overlooked somewhere (though AFAICT, quibble-bullseye-php81 was the only updated image that did not derive from php81 in some way).

In T386006#10581278, @Scott_French wrote:

However, that's about the limit of my knowledge in terms of how CI image are built, and am struggling to find any documentation to this effect.

For future references (permissions are required):

https://www.mediawiki.org/wiki/Continuous_integration/Docker#Deploy_images
https://www.mediawiki.org/wiki/Continuous_integration/Jenkins_job_builder#Deploy_changes

And as a followup from the conversation in -releng as this was all going on

xref T320818: Configure CI to test the Wikimedia production gate code against PHP 8.1 instead of PHP 7.4

https://gerrit.wikimedia.org/r/c/integration/config/+/1115147 - We should go back to at least running PHP 8.1 jobs as well as PHP 7.4 jobs, though, as James' patch is currently, we can probably just switch to *only* PHP 8.1

PHP 7.4 is still run on master

In T386006#10581278, @Scott_French wrote:

Alright, I believe merging https://gerrit.wikimedia.org/r/1122700, rebuilding the images, and then merging https://gerrit.wikimedia.org/r/1122701 should fix this.

That is why I suggested to put libpcre2-8 under the same component as our Php 8.1 packages (component/php81). The Php packages are not usable as is and we don't have a way to express a dependency between components. Anyway that can always be improved later on and I usually refer to @MoritzMuehlenhoff for that.

In T386006#10581360, @Scott_French wrote:

... (though AFAICT, quibble-bullseye-php81 was the only updated image that did not derive from php81 in some way).

The short story, and pardon my rudeness: Docker sucks!!1!. The layers are a list and there is no support for multiple inheritance or for cherry-picking/merging in a layer or a series of them. The Quibble images have a common ancestor holding Quibble and all the shared lib and tools (npm, apache config etc) which is then extended for each of the PHP versions we support (7.4, 8.1, 8.2, 8.3), that is essentially another fleet of PHPs images.

Since PHP packages are nowadays co-installable, I am contemplating having a single php image that holds all installable versions and have the Quibble one extend it. We'd have to move back to use an environment variable to switch between versions as we did back in the days (PHP_BIN=php8.1 and /usr/bin/php recognizing it to invoke the given version). But I digress :-]

Thank you for the successful roll out!!

Change #1122901 had a related patch set uploaded (by Hashar; author: Hashar):

[operations/puppet@production] php: use component/pcre2 when using Php 8.1

https://gerrit.wikimedia.org/r/1122901

We have the same issue on Beta-Cluster-Infrastructure:

Warning: PHP Startup: ^(text/|application/xhtml\+xml) (offset=0): unrecognised compile-time option bit(s) in Unknown on line 0

Which I have filed as T387276

In T386006#10577357, @Scott_French wrote:

The motivation behind using a standalone component for PCRE2, vs. including the new packages directly in component/php81, was to avoid immediately introducing a newer PCRE2 version than the collocated php packages had been built with. In addition, we expect component/pcre2 to see some reuse.

It's probably a little late (I was out the past two days), but in this specific case I think we're better off with just importing the new PCRE2 build into component/php81 for the following reasons:

• components should be self-contained and without the updated PCRE PHP would be broken
• I don't expect any further use of the updated PCRE build, that is a regression that only affects the specific combination of "recent" PHP and the PCRE from Bullseye (PCRE in Bookworm is already recent enough) and none of the packages in Bullseye seem to be affected since no such bug was ever reported to the BTS during the Bullseye non-LTS lifetime
• we reduce complexity by avoiding build hooks and simpler image builds

(Just my two cents and to provide some context, it's perfectly fine to just resume with the status quo now that the work has already happened)

mvernon merged https://gitlab.wikimedia.org/repos/sre/wmf-debci/-/merge_requests/17

Attempt to use trusted runners where appropriate

Thanks, all, for the follow-up.

@hashar - Many thanks for addressing the issue in Beta. My understanding - which of course might be very mistaken - is that even with PCRE2 present in component/php81, we would still need an explicit apt-get install in some form when building an image from a base image that already has a version of the library installed, as in all of the cases encountered here. Stated differently, while avoiding a component/pcre2 would reduce number of lines of change, simply using component/php81 would not be sufficient (and would still result in broken packages were it not for the explicit upgrade).

@MoritzMuehlenhoff - These are all great points. My main reservation was including a mismatched PCRE2 version in the already-used component/php81 before the PHP packages therein had been rebuilt (i.e., I was concerned about the interoperability risks that might pose). It turned out, though, that since effectively all use cases already install the stock 10.36 PCRE2, this would never happen without further action (i.e., there would be no reason to upgrade). Ultimately, agreed that collapsing these into a single component makes sense now that these are consistent, so the above is no longer a concern.

mvernon updated https://gitlab.wikimedia.org/repos/sre/wmf-debci/-/merge_requests/18

skip building of udebs by default

Staging now has PCRE2 - https://apt-staging.wikimedia.org/wikimedia-staging/pool/main/p/pcre2/

I've also put in a MR to make noudeb builds the default (since we generally won't want them, as the staging repo can't take them).

Thank you very much, @MatthewVernon!

Great, so I think the remaining tasks here are:

• Consolidating into component/php81 and retiring component/pcre2 across all production images, CI images, and puppet (the latter used by beta).
• Configuring updates to PCRE2 in component/php81 from apt-staging.

Change #1122901 merged by Clément Goubert:

[operations/puppet@production] php: use component/pcre2 when using Php 8.1

https://gerrit.wikimedia.org/r/1122901

mvernon merged https://gitlab.wikimedia.org/repos/sre/wmf-debci/-/merge_requests/18

skip building of udebs by default

Change #1125536 had a related patch set uploaded (by Scott French; author: Scott French):

[operations/docker-images/production-images@master] php8.1: Install PCRE2 backport from component/php81

https://gerrit.wikimedia.org/r/1125536

Change #1125529 had a related patch set uploaded (by Scott French; author: Scott French):

[operations/puppet@production] P:mediawiki::php: install PCRE2 backport from component/php81

https://gerrit.wikimedia.org/r/1125529

Change #1125537 had a related patch set uploaded (by Scott French; author: Scott French):

[operations/puppet@production] package_builder: remove pbuilder hook for pcre2 component (1 of 2)

https://gerrit.wikimedia.org/r/1125537

Change #1125538 had a related patch set uploaded (by Scott French; author: Scott French):

[operations/puppet@production] package_builder: remove pbuilder hook for pcre2 component (2 of 2)

https://gerrit.wikimedia.org/r/1125538

Change #1125539 had a related patch set uploaded (by Scott French; author: Scott French):

[operations/puppet@production] aptrepo: remove component/pcre2

https://gerrit.wikimedia.org/r/1125539

Following up, I had a bit of time this afternoon to prepare most (but not yet all) of the patches necessary to consolidate into component/php81 and retire component/pcre2.

I've also revised https://gerrit.wikimedia.org/r/c/operations/puppet/+/1121388 to configure automated updates from apt-staging to the former, rather than the latter.

What remains is to prepare patches to the relevant Dockerfile templates in integration/config (edit: done now).

Change #1125557 had a related patch set uploaded (by Scott French; author: Scott French):

[integration/config@master] Docker: [quibble-bullseye-php81] Use PCRE2 backport from component/php81

https://gerrit.wikimedia.org/r/1125557

Change #1125558 had a related patch set uploaded (by Scott French; author: Scott French):

[integration/config@master] Docker: [php] Use PCRE2 backport from component/php81

https://gerrit.wikimedia.org/r/1125558

Alright, I think that should be everything except the jjb config changes to use the new images in CI once they exist.

In any case, I'll follow up next week to get the ball (boulder?) rolling on this cleanup, starting with getting the packages into component/php81 by way of https://gerrit.wikimedia.org/r/c/operations/puppet/+/1121388.

Until that point none of the WIP-marked patches tagged on this task are ready for review, let alone merging.

In T386006#10564838, @MatthewVernon wrote:

Which PCRE version(s) do you want? Our CI is currently building unstable-for-{bookworm,bullseye}, so currently 10.45-1 (which becomes 10.45-1~wmf11+1 for bullseye and 10.45-1~wmf12+2 for bookworm), which is likely what will end up in the forthcoming trixie release. Current version table:

Debian suite	pcre2 version
Unstable	10.45-1
testing / trixie	10.44-5
stable / bookworm	10.42-1
oldstable / bullseye	10.36-2+deb11u1

The 10.45 migration to trixie is currently blocking on a bug in the mariadb test suite, which is pending an upload of mariadb.

As a cross reference... It's seemingly a good job we didn't use 10.45! See T388335: PCRE incompatibility in 10.45 in pear/Net_URL2

Change #1121388 merged by Scott French:

[operations/puppet@production] aptrepo: update pcre2 backport from apt-staging

https://gerrit.wikimedia.org/r/1121388

Mentioned in SAL (#wikimedia-operations) [2025-03-10T15:54:04Z] <swfrench-wmf> reprepro update pcre2_10.42-1~wmf11+1 in component/pcre2 from apt-staging - T386006

I just realized there's a typo in my SAL log in T386006#10619559 - that should have read "in component/php81 from apt-staging" (oops).

Change #1125529 merged by Scott French:

[operations/puppet@production] P:mediawiki::php: install PCRE2 backport from component/php81

https://gerrit.wikimedia.org/r/1125529

Change #1125536 merged by Scott French:

[operations/docker-images/production-images@master] php8.1: Install PCRE2 backport from component/php81

https://gerrit.wikimedia.org/r/1125536

Mentioned in SAL (#wikimedia-operations) [2025-03-11T16:54:41Z] <swfrench-wmf> rebuilt php8.1 production images to pick up PCRE2 backport from component/php81 - T386006

Mentioned in SAL (#wikimedia-operations) [2025-03-11T16:58:24Z] <swfrench@deploy2002> Started scap sync-world: Deployment to pick up new php8.1 production image - T386006

Mentioned in SAL (#wikimedia-operations) [2025-03-11T17:24:22Z] <swfrench@deploy2002> Finished scap sync-world: Deployment to pick up new php8.1 production image - T386006 (duration: 26m 26s)

Change #1125537 merged by Scott French:

[operations/puppet@production] package_builder: remove pbuilder hook for pcre2 component (1 of 2)

https://gerrit.wikimedia.org/r/1125537

Change #1125557 merged by jenkins-bot:

[integration/config@master] Docker: [quibble-bullseye-php81] Use PCRE2 backport from component/php81

https://gerrit.wikimedia.org/r/1125557

Change #1125558 merged by jenkins-bot:

[integration/config@master] Docker: [php81] Use PCRE2 backport from component/php81

https://gerrit.wikimedia.org/r/1125558

Mentioned in SAL (#wikimedia-releng) [2025-03-11T20:48:54Z] <James_F> Docker: [quibble-bullseye-php81 & php81] Use PCRE2 backport from component/php81, for T386006

Change #1126657 had a related patch set uploaded (by Jforrester; author: Jforrester):

[integration/config@master] jjb: Update PHP 8.1-based images to PCRE2 from component/php81

https://gerrit.wikimedia.org/r/1126657

Change #1126657 merged by jenkins-bot:

[integration/config@master] jjb: Update PHP 8.1-based images to PCRE2 from component/php81

https://gerrit.wikimedia.org/r/1126657

Change #1125538 merged by Scott French:

[operations/puppet@production] package_builder: remove pbuilder hook for pcre2 component (2 of 2)

https://gerrit.wikimedia.org/r/1125538

I completely missed until now that the CI jobs have already been updated to use the latest images. Thanks for that, @Jdforrester-WMF!

Alright, the last remaining cleanup is https://gerrit.wikimedia.org/r/1125539. However, per comments on the patch, it sounds like that might not actually be common practice for disused components, so I may abandon that.

Change #1128522 had a related patch set uploaded (by Scott French; author: Scott French):

[operations/docker-images/production-images@master] php8.1: fix comment typo in Dockerfile.template

https://gerrit.wikimedia.org/r/1128522

Change #1125539 merged by Scott French:

[operations/puppet@production] aptrepo: remove component/pcre2

https://gerrit.wikimedia.org/r/1125539

Change #1128522 merged by Scott French:

[operations/docker-images/production-images@master] php8.1: fix comment typo in Dockerfile.template

https://gerrit.wikimedia.org/r/1128522

Mentioned in SAL (#wikimedia-operations) [2025-03-17T21:10:50Z] <swfrench-wmf> ran reprepro --delete clearvanished to complete removal of unused component/pcre2 - T386006