Debian has the php-uuid package ( https://packages.debian.org/search?keywords=php-uuid ).

For Wikimedia production (and CI when it targets php 7.4) the base OS is Debian Buster which has php 7.3:

https://packages.debian.org/buster/amd64/php-uuid/filelist

/etc/php/7.3/mods-available/uuid.ini
/usr/lib/php/20180731/uuid.so
/usr/share/doc/php-uuid/changelog.Debian.gz
/usr/share/doc/php-uuid/copyright

We thus need serviceops to build php-uuid for Php 7.4 and have the resulting Debian package in buster-wikimedia under component/icu67 (at least that is how it is installed for CI).

I don't know where the sources for our php fork as stored. I could not find anything in Gerrit, I assume that is done directly on the build host.

Thanks for the details! Just to confirm, the request here is for php-uuid packages for both 7.4 and 8.1, correct? (in buster-wikimedia component/icu67 and bullseye-wikimedia component/php81, respectively)

I don't think we specifically need it on PHP 7.4, but it shouldn't harm anything.

It would also mean we can keep things cleaner (same PHP extension list on 7.4 and 8.1 in CI and prod/k8s), and we can do the cleanup in T373751: Remove symfony/polyfill-uuid from Vendor etc earlier when it is fully rolled out.

So if it's not much work to build it, it is probably worth it, saving introducing divergence that would just need removing later when we dropped older PHP support/usage

@Reedy - Got it, thanks for the context! I'll look into how complicated this might be on 7.4 in light of how builds for our icu67 component work. Naively, I'm a little concerned about incompatibility between the older dh-php therein (0.35) and the upstream php-uuid package (which requires at least 4 [0]).

[0] https://salsa.debian.org/php-team/pecl/php-uuid/-/blob/debian/main/debian/control?ref_type=heads

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

[operations/docker-images/production-images@master] php8.1: add php8.1-uuid to php8.1-cli and cascade

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

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

[integration/config@master] Docker: Re-build PHP 8.1+ with php-uuid

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

Change #1072269 merged by Scott French:

[operations/docker-images/production-images@master] php8.1: add php8.1-uuid to php8.1-cli and cascade

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

In T373752#10136087, @Scott_French wrote:

@Reedy - Got it, thanks for the context! I'll look into how complicated this might be on 7.4 in light of how builds for our icu67 component work. Naively, I'm a little concerned about incompatibility between the older dh-php therein (0.35) and the upstream php-uuid package (which requires at least 4 [0]).

[0] https://salsa.debian.org/php-team/pecl/php-uuid/-/blob/debian/main/debian/control?ref_type=heads

Did we manage to get anywhere with this? :)

@Scott_French: Any update on getting the PHP 7.4 php-uuid package pushed so we can resolve this?

Ah, right!

Just to confirm, how recent does the version of php-uuid need to be in the 7.4 case?

As I mentioned in T373752#10136087, the tricky part is likely compatibility between the dh-php version we use in the icu67 component (0.35) and what's required by more recent versions of the packages maintained by the Debian PHP team.

For example, building the same version as we now have in 8.1 may be quite challenging, but reaching back as far as 1.0.4 (dh-php >= 0.33) should be doable (i.e., the version of php-uuid on buster).

Naively, in practice... I think it probably doesn't matter, too much. As long as works. Famous last words.

https://github.com/php/pecl-networking-uuid doesn't seem to obviously show it has any direct dependancies on icu... libuuid will depend on libc6 which will depend on...

We're not actually using the code yet, but we'll need it eventually for T363639: web-auth/webauthn-lib must be upgraded to 4+ for PHP 8.2+ support, which by the time that is actually progressing properly, we'll have probably dropped PHP 7.4 CI for MediaWiki core et al (on master)

Getting something so we can build CI images at least allows us to not have to special case, and we can actually get T373751: Remove symfony/polyfill-uuid from Vendor done too, because we know the extension will be present for our purposes.

And even then, I don't believe we're depending on any specific version/behaviour... So as long as it can be loaded by the version of PHP 7.4 we're using, and generate a UUID... I think we're good.

Thanks, @Reedy!

Alright, after a bit of fiddling, I was able to build php-uuid packages that work with the version of 7.4 in our icu67 component for buster-wikimedia.

As I mentioned, these track the 1.0.4-7 version of the package provided for buster by the debian PHP team.

I've not included these in apt.w.o yet, but pulling the .deb down from build2001 and installing it into a test image based on our docker-registry.wikimedia.org/php7.4-cli:

$ cat test.php 
<?php
$id = uuid_create();
var_dump( $id );
var_dump( uuid_is_valid( $id ) );
$ cat test.php | docker run -i --entrypoint="" test-uuid /usr/bin/php7.4
string(36) "27ea195a-5de5-4132-a283-c68da8009bb0"
bool(true)

So yeah, seems to generate a UUID, which it further considers to be valid. Seems like that ticks our boxes for "works" :)

@MoritzMuehlenhoff - Would you have any concerns if I include php-uuid in the icu67 component? This would unblock work on this while the migration to 8.1 is ongoing (already present there).

Sure, no problem with that. Just make sure that you build with the ICU67-enabld component enabled, so that the ICU67-enableld php-dev gets picket up.

ICU=67 DIST=buster-wikimedia pdebuild --debbuildopts "-sa"

Great, thanks @MoritzMuehlenhoff!

Yes, I believe your pdebuild invocation should be consistent (a couple of layers removed) with the route I took via gbp [0]. Also, I can see in the log output that the relevant build dependencies were indeed satisfied using the icu67 component packages.

I'll look into getting these included next week.

[0] WIKIMEDIA=yes ICU67=yes gbp buildpackage -sa -us -uc --git-pbuilder --git-no-pbuilder-autoconf --git-dist=buster

I guess at this point, we probably really don't care about getting this for PHP 7.4 (T391057: Turn down MediaWiki image builds for PHP 7.4 etc)...

So mostly it's just getting this into our CI images left to do? And similar reasons, remove the PHP 7.4 patch in https://gerrit.wikimedia.org/r/c/1072320 ?

My apologies, @Reedy - I once again lost track of this one.

So, to unblock php-uuid adoption as soon as possible, what's needed is:

1. Building and uploading the 7.4 packages for buster (component/icu67) and bullseye (component/php74).
2. Adding php7.4-uuid to the buster-based 7.4 production image.
3. Adding php{version}-uuid to the set of packages in [0] (most likely generic_name_extensions) installed on bare-metal hosts, since it seems those will continue to linger for a bit.

If we plan to defer adoption until after no production 7.4 use cases exist, we can skip #2 (and potentially skip buster in #1 if all CI images are bullseye).

I'm going to be out next week, but can take a look at moving this forward the week after.

[0] https://gerrit.wikimedia.org/g/operations/puppet/+/refs/heads/production/modules/profile/manifests/mediawiki/php.pp

The eternal question of when we're going to be finished using PHP 7.4!

If we're still a few weeks (or month? hopefully not) away, maybe it's worth doing this if it's not too much effort. If we're pretty close, its maybe not necessary.

I don't think we actually need to add it to the 7.4 prod images, and we may not actually need to add to the CI ones anyway.. As we're not going to do T363639: web-auth/webauthn-lib must be upgraded to 4+ for PHP 8.2+ support before then.

Thanks, @Reedy - It's really not all that much effort to make this happen if it would help unblock you all.

I have php7.4-uuid packages for component/icu67 and component/php74 ready, actually using a slightly newer version than what was originally proposed in T373752#10507023 - 1.2.0, tracking what's available for debian bullseye.

Also, now that we do anticipated having non-k8s cases where 8.1 will be used (e.g., mwdebug hosts), I need to update puppet code in P:mediawiki::php to install uuid regardless.

The question becomes whether that happens conditionally based on the PHP version (e.g., something like https://gerrit.wikimedia.org/r/1139947) vs. unconditionally (e.g., just add it to generic_name_extensions).

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

[operations/puppet@production] P:mediawiki::php: add uuid extension for PHP 8.1+

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

Given the progress made so far in the periodic maintenance jobs migration to k8s (and thus 8.1), it probably does not make sense to support this on 7.4, unless of course there is some urgent need of which I'm not aware (my read of T373752#10756865 is that there is not, but I might be misunderstanding).

As such, I'd like to go ahead and make sure the package is installed by P:mediawiki::php (https://gerrit.wikimedia.org/r/1139947) sooner rather than later, lest I forget to do so before it's actually used.

Change #1139947 merged by Scott French:

[operations/puppet@production] P:mediawiki::php: add uuid extension for PHP 8.1+

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

Change #1072320 merged by jenkins-bot:

[integration/config@master] Docker: Re-build PHP images with php-uuid (and incidentally bump versions)

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

Mentioned in SAL (#wikimedia-releng) [2025-06-05T18:26:24Z] <James_F> Docker: Re-build PHP images with php-uuid (and incidentally bump versions), for T373752

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

[integration/config@master] jjb: Switch jobs to newest PHP images with uuid

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

Change #1154102 merged by jenkins-bot:

[integration/config@master] jjb: Switch jobs to newest PHP images with uuid

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