[MIR] php8.0-fpm (binary)

[Matthew Haughton]

NOTE: I only saw that where the source package is in main reports are not
required after spending most of the day writing this up. It's my first MIR so apologies if this isn't the correct process for promoting a binary of an existing source package - I couldn't find documentation on what to do to make that request.

From the PHP documentation: FPM (FastCGI Process Manager) is an alternative PHP FastCGI implementation with some additional features (mostly) useful for heavy-loaded sites.

Availability:

Available in Ubuntu universe in all currently supported Ubuntu releases. Latest release builds on all architectures (amd64, arm64, armhf, i386, powerpc, ppc64el)[1]. Also available on Debian Wheezy (it was not included in Squeeze as FPM was introduced to PHP core too close to Squeeze's release[2]).

Rationale:

Commonly combined with nginx, and can be used with all servers supporting
FastCGI (Apache, Lighttpd, etc). With some momentum behind adding nginx to main[3] it would be nice to have something with security support that can be paired with it to have comparable functionality to the common apache2 + libapache2-mod-php5 combination. According to Ubuntu popcon php5-fpm is used regularly by 950 people, which compares favourably to nginx (nginx-common) which is used regularly by 639 people (according to "Vote" stats).

Security:

php5 is already in main so this search is limited to security issues affecting FPM specifically. PHP FPM is included with and supported as part of the core PHP release in all currently supported versions (5.3.x, 5.4.x and 5.5.x). It therefore has security support from the core PHP team. It also has security support from upstream Debian.

A search for "fpm" on cve.mitre.org and NVD returns only CVE-2012-0831. This appears to have been disclosed responsibly and fixed promptly (NVD shows vulnerability release date of Feb 10, 2012. It was fixed in PHP prior to this disclosure on Feb 2, 2012.)
The USN with updated packages was released Feb 9, 2012.

There are currently no affecting CVEs listed in Ubuntu's security tracker for php5 package[4].
There are currently four open issues listed in Debian's security tracker (not counting "unimportant issues" for php5 package[5]:

* CVE-2010-4657 per Ubuntu tracker "can't reproduce on quantal+", so does not affect Trusty.
* CVE-2011-1398 fixed upstream in 5.4.0, so does not affect Trusty.
* CVE-2011-4718 fixed upstream in 5.5.2, so does not affect Trusty.
* CVE-2012-0789 fixed upstream in 5.5.0, so does not affect Trusty.

The php5-fpm binary is installed in /usr/sbin and installs a daemon. The daemon by default is not public facing and starts a socket listening at /var/run/php5-fpm.sock.

Based on this an in-depth security review is required.

Quality assurance:

The package is automatically started after installation. Provided a web server is correctly configured it should be possible to use this package without any further configuration to begin serving PHP pages.

There are no debconf questions asked during installation.

Upstream PHP FPM bugs: https://bugs.php.net/search.php?cmd=display&package_name[]=FPM+related
Debian bugs: http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=php5-fpm
Ubuntu bugs: https://launchpad.net/ubuntu/+source/php5/+bugs?field.searchtext=fpm

Ubuntu bug 1230917 must be fixed, as this affects logrotate when using Upstart and will send weekly warning emails from cron.
Other Ubuntu bugs either require more information or relate to PHP core or a module, not FPM.

In Debian there are currently no outstanding bugs that can be actioned.

In PHP upstream there are several relevant open bugs:
* 55508 - feature request to listen on IPv6 addresses (current support is limited to IPv4 and sockets)
* 62382 - access log format for FPM shows incorrect values for server time a request is received
* 51983 - pm.status_path not working when cgi.fix_pathinfo=1 (long-standing, probably minor bug)
* 53074 - looks like upstream version of Ubuntu bug 1242376
* 53611 - fastcgi_param PHP_VALUE pollutes other sites (possible security issue, long-standing). Possibly related to 61867 and 63965.
* 60961 - Graceful Restart (USR2) isn't very graceful. Possibly related to 63395.
* 61558 - Runaway spawning of children after pipe error
* 62172 - FPM not working with Apache httpd 2.4 balancer/fcgi setup
* 55322, 62279 - chroot issues
* 64626 - PHP-FPM may segfault/hang on startup

Whether any of these are blockers is up to discretion of MIR approval team. If any are blockers then please state which ones so they can be tracked for a future MIR.

In Debian PTS there are several Lintian errors and warnings for php5, however php5-fpm is clean. There is a build warning on powerpc but no build failures.

The package does not deal with specific hardware.

The package ships a test suite which is referenced in debian/rules.

The package includes a watch file.

UI standards:

N/A

Dependencies:

All build and binary dependencies are satisfyable in main.

Standards compliance:

The current package meets Debian Policy 3.9.4 (current is 3.9.5).

Maintenance:

The php5 source package is already maintained by Ubuntu Developers, who are responsible for providing security updates for several other binary packages from php5 source. Bugs and security issues that affect FPM will typically affect core as well and require updates; security issues which affect PHP FPM are rare so the extra workload required should hopefully be minimal.

NOTE: Ubuntu bug 1242376 was marked as requiring a fix, however it was fixed in Debian in 5.5.6+dfsg-1 and that fix is now in the Trusty archive.

[1] https://launchpad.net/ubuntu/+source/php5/5.5.6+dfsg-1ubuntu2
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603174
[3] https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1262710
[4] http://people.canonical.com/~ubuntu-security/cve/pkg/php5.html
[5] https://security-tracker.debian.org/tracker/source-package/php5

[Robie Basak (racb)]

Who will be your team subscriber? If this is to be ~ubuntu-server, have you cleared it with them? I have seen no mention.

[Matthew Haughton (snafu109)]

Hi Robie,

I can't comment on that. All I did was follow the process for filing the MIR bug; I'm not sure how to progress it from here. If I need to post on the ubuntu-server list to get attention I'm happy to do so.

I believe this bug is at step 4 of https://wiki.ubuntu.com/MainInclusionProcess, and waiting for review by ~ubuntu-mir team. If there's more to the process then where can I find that information?

[Matthew Haughton (snafu109)]

Having said that I see on that wiki page "New binary packages from existing source packages, where the source package is already in main, do not require reports." But who to notify about this bug so php5-fpm can move to main?

[Robie Basak (racb)]

I'm referring to https://wiki.ubuntu.com/UbuntuMainInclusionRequirements

"Packages that deliver major new headline features in Ubuntu need to
have commitment from Ubuntu developers willing to spend substantial time
on them."

In particular, I'm not sure who you are. Are you volunteering to look
after php5-fpm issues in Ubuntu as part of the Ubuntu Server team?

Also, "All packages must have a designated "owning" team, regardless of
complexity, which is set as a package bug contact." - ~ubuntu-server
currently "own" PHP, so it would make sense to be clear about who is
going to do what here.

[Matthew Haughton (snafu109)]

I'm just a user who would like to see FPM have security and QA support for the full 60 months of an LTS release along with the other PHP SAPIs, so I (and others) can use a supported PHP backend with nginx instead of having to use Apache. Now nginx-core is in main it would be excellent to have a fully supported LEMP stack going in Ubuntu. I'm not otherwise involved in the Ubuntu project other than filing the odd bug.

I can keep momentum going on getting the package promoted but I can't commit to ongoing maintenance of the package once it's in main. So I can go to ubuntu-server list to ask for help with this, since I know PHP is a difficult set of packages to maintain and those currently taking on this responsibility may not have the bandwidth to provide full support for an additional package.

[Michael Terry (mterry)]

Hello, I'm on the MIR team and originally looked at this report. Thanks, snafu for filing it!

I assigned the bug to the security team, so the next step is for them to give the relevant code a quick review and confirm whether it is something they are willing to support in main.

As for a team bug subscriber, we are already OK on that front. The php5 source package already has the ubuntu server team subscribed, as well as several other interested parties.

[Michael Terry (mterry)]

I will also add that if the server team is not interested in maintaining the fpm module in main, that would be enough of a reason to block this. If they can positively comment that they are interested in promoting this feature to main and supporting it, that would be good.

[Robie Basak (racb)]

I'm generally the only person in ~ubuntu-server (and ~ubuntu-server-dev) looking after the PHP packaging in Ubuntu at the moment (kindly assisted on occasion by Ondřej, who is also the primary Debian PHP maintainer).

We currently have 21 open bugs mentioning "fpm" in src:php5, and 97 bugs in total. This is too many - mainly because I am quite stretched at the moment looking after many server packages in Ubuntu. As an example, bug 1242376 is an issue I have been involved in but still lacks a resolution in Ubuntu, even though a patch is available. I am aware of it - just haven't had time (and priority, with php5-fpm being a universe package) to look at the latest patch that others have made available. I think this demonstrates that there is a shortage of Ubuntu developers looking into this at the moment, so I am reluctant when it comes to adding to my workload.

In addition, Debian has had an RFS open on php5 for two years now: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664595. I have helped where I can, including fixing things affecting Debian and pushing patches back up. But it is quite clear to me that we could really use more manpower in php5 right now - both in Debian and in Ubuntu.

I support putting server packages into main where they are relevant for our users - but this has to be balanced with the workload. There is little point in doing to the point where quality suffers. That would make main inclusion pointless.

So this is a +0 from me.

I am open to changing my mind if either 1) more developers step up to help maintain the package in Ubuntu, or 2) a convincing case is made for the relevance of php5-fpm in main. I appreciate your popcon research, but I am not convinced that this is representative of production users (who rarely have popularity-contest installed, and where main inclusion really makes a difference, as opposed to hobby experimenters). I welcome further debate/feedback on the relevance topic, though I'm not sure how involved I would be in that except to form an opinion.

[Ondřej Surý (ondrej)]

JFTR although I can't help with regular Ubuntu maintenance, I fully support inclusion of FPM into Ubuntu main as the FCGI/FPM method is far more secure than standard libapache2-mod-php5.

I would even propose to demote libapache2-mod-php5 in favor of php5-fpm (if we can provide reasonably good default configuration with mod_proxy_fcgi in apache2.4).

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Robie Basak (racb)]

I wrote:

> or 2) a convincing case is made for the relevance of php5-fpm in main.

The number of people marked as affected by bug 1230917 (67) does swing me a little. I would like to see the fpm bugs cleared up first, though.

[Ondřej Surý (ondrej)]

> In addition, Debian has had an RFS open on php5 for two years now: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664595.

JFTR the team is quite healthy now, but I keep the bug open since we are always keen on having more people on board.

[Neal Gompa (ngompa13)]

So, I'd like to chime in here a bit.

As Ondřej mentioned earlier, php-fpm is known to be a more secure alternative to mod_php, and is recommended for secure setups. I recently contributed a decent default configuration for php-fpm for PHP 7.0, and I would support flipping libapache2-mod-php7.0 to universe and keep php7.0-fpm in main.

Critically, php-fpm can be used with any web server that supports FastCGI, whereas mod_php is Apache httpd specific. There is, of course, php-cgi, but it isn't recommended either, and I would suggest that it should be in universe as well.

I don't pretend to know the difficulty of maintaining the PHP stack, but I think that perhaps moving these two particular methods of using PHP from main to universe in exchange for php-fpm should be considered.

[Neal Gompa (ngompa13)]

Of course, I realize it means that for httpd, it would need to have mod_proxy_fcgi enabled by default for the php-fpm configuration I contributed to be useful in an out-of-the-box scenario.

[Robie Basak (racb)]

@Neal,

Any chance you have the time to sweep through the fpm bugs? I don't know how many of those are relevant, but if everything reported can be resolved (as no longer applicable, or fixed), then I'd be happy to put "FPM in main" forward. Note that I'm not a decision maker here though; there are other considerations too. But it seems to me that this is unlikely to go forward as long as FPM-related bugs exist.

[Neal Gompa (ngompa13)]

@Robie: I can certainly take a look through them. Where can I see them?

[Seth Arnold (seth-arnold)]

Neal, https://launchpad.net/ubuntu/+source/php5/+bugs?field.searchtext=fpm

The FPM mode of execution feels far better to me than running a PHP interpreter in the same address space as the webserver -- however I have to balance my enthusiasm for the better design against the fact that there are a huge pile of bugs currently open that mention 'fpm', a complete unfamiliarity with the codebase, and Robie expressed that they're stretched too thin as it is.

Demoting mod_php to universe may or may not help the 'spread too thin' aspect.

But having the php interpreter in the same address space as TLS secrets seems insane to me. :)

Thanks

[Jeremy Bícha (jbicha)]

Bumping to php7 since php5 is gone

[Matthew Haughton (snafu109)]

There appear to be 14 bugs open that mention FPM currently (https://launchpad.net/ubuntu/+source/php5/+bugs?field.searchtext=fpm), some of which look like they can be ignored.

* #1283478 - Affects FPM. Crash when non-default configuration used. Raised upstream with PHP but no activity.
* #1288129 - Affects FPM. Raised upstream, patch available, brief review by PHP dev but no activity since May.
* #1385050 - Affects FPM on Trusty. More information needed.
* #1463076 - May have been fixed in Debian? Version 5.5.10+dfsg-1 changelog has the note "Implement more robust way of handling php5-fpm reopen logs from logrotate" but there's no Debian bug linked so can't compare this issue against it.

Bugs that can be ignored:
* #1131115 - Incomplete bug.
* #1352617 - Fixed in Trusty.
* #1406026 - Incomplete bug.
* #1334572 - Unclear where issue lies - apparent packaging issue, but related to a conffile automatically marked as such since it's in /etc, so not related to FPM itself.
* #1475309 - Bug with opcache, not FPM
* #1325083 - Incomplete bug.
* #1444495 - Incomplete bug.
* #1407670 - Incomplete bug.
* #1430033 - Error on installation, log appears to show problem with php5-cli installation, not php5-fpm.
* #1439925 - Issue with php5-mysql & php5-mysqlnd packaging on Trusty, not php5-fpm

By my estimation, there are just three or four bugs that need attention, which doesn't look that bad, unless I've missed something? Just a matter of putting pressure on PHP for fixes for the first two, and somehow reproducing the second two, or marking as incomplete if no further information is provided.

[Michael Terry (mterry)]

Doko, do you have an opinion here? I'm tempted to make the switch based on Seth's comments, assuming that we can demote libapache2-mod-php7.0.

[Marc Deslauriers (mdeslaur)]

It's the same source package, I don't think we need to demote libapache2-mod-php7.0.

[Michael Terry (mterry)]

Well it's about whether Canonical is on the hook for support or not. Ideally the security and server teams don't have to support two versions of the module.

[JK (m0d)]

It's almost a year since the last comment... Any news on this? I've only recently noticed that "ubuntu-support-status --show-unsupported | grep php7" shows php7.0-fpm (and other PHP packages) as unsupported in 16.04 LTS:

> php-zip php7.0-fpm php7.0-imap php7.0-intl php7.0-mbstring php7.0-mcrypt php7.0-xsl php7.0-zip

I did not find any other usable information on this topic beside this bug report. Most people probably don't even know about this problem. It's easy to overlook though, since the "php7.0" meta-package is in main and "apt-cache show php7.0" shows it as fully supported:

> Package: php7.0
> Priority: optional
> Section: php
[...]
> Depends: php7.0-fpm | libapache2-mod-php7.0 | php7.0-cgi, php7.0-common
[...]
> Supported: 5y

And, what's even more confusing, it also depends on "php7.0-fpm". Imo, most people who see this will think: "OK, PHP7 has 5 year support, so I'm safe with my Ubuntu LTS". But in fact, they are not... at least if they use FPM (what they probably do).

Like most people here, I think that php7-fpm should definitely be supported for the full LTS period, because it's a basic component of most web servers. How is the chance that is will be the case in the next LTS version?

BTW: this bug report is slightly related, because it deals with the problem of the different support timespans in LTS and the bad image Ubuntu LTS has because of it: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1574670

[Nish Aravamudan (nacc)]

On 12.06.2017 [13:25:19 -0000], JK wrote:
> It's almost a year since the last comment... Any news on this? I've only
> recently noticed that "ubuntu-support-status --show-unsupported | grep
> php7" shows php7.0-fpm (and other PHP packages) as unsupported in 16.04
> LTS:
>
> > php-zip php7.0-fpm php7.0-imap php7.0-intl php7.0-mbstring
> php7.0-mcrypt php7.0-xsl php7.0-zip

Well, that's odd, but as you found in the related bug, also expected
(with the older ubuntu-support-status command).

> I did not find any other usable information on this topic beside this
> bug report. Most people probably don't even know about this problem.

What is "this" problem in this sentence? That a tool mentions
unsupported status?

> It's easy to overlook though, since the "php7.0" meta-package is in main
> and "apt-cache show php7.0" shows it as fully supported:
>
> > Package: php7.0
> > Priority: optional
> > Section: php
> [...]
> > Depends: php7.0-fpm | libapache2-mod-php7.0 | php7.0-cgi, php7.0-common
> [...]
> > Supported: 5y

Ignore the Supported value, as mentioned in the first comment in the bug
you linked to later.

> And, what's even more confusing, it also depends on "php7.0-fpm".

It depends on a disjunction of three packages. As long as one of them is
in main (in this case libapache2-mod-php7.0) there is no issue.

> Imo, most people who see this will think: "OK, PHP7 has 5 year
> support, so I'm safe with my Ubuntu LTS". But in fact, they are not...
> at least if they use FPM (what they probably do).

What is "safe" and why are they not? Are you misunderstanding what
ubuntu-support-status says? I'm very confused, because you already found
the other bug that says the output is wrong.

> Like most people here, I think that php7-fpm should definitely be
> supported for the full LTS period, because it's a basic component of
> most web servers. How is the chance that is will be the case in the next
> LTS version?

Again, I think you're just misapprehending what is 'supported' (in that
there is someone paying attention? -- I'm not sure what you expect,
exactly) vs. what is in main?

> BTW: this bug report is slightly related, because it deals with the
> problem of the different support timespans in LTS and the bad image
> Ubuntu LTS has because of it: https://bugs.launchpad.net/ubuntu/+source
> /update-manager/+bug/1574670

Basically, the bug you are reporting, as far as I can tell, is this one,
not the one against PHP.

It feelsl ike it overloads the term 'supported'. As far as I can tell,
as that bug documents, `ubuntu-support-status` reflects the
main/universe split, but in an unclear way. It's been fixed in 16.10+,
I'm not sure why/if it will be backported to older releases as Bug
#15746709 mentions.

To be clear, regardless of what `ubuntu-support-status` says, it's not
like php7.0-fpm is going to stop being available or bugs fixed (there
aren't that many filed, afaict).

[JK (m0d)]

Thanks for your fast response, Nish!

> Well, that's odd, but as you found in the related bug, also expected
> (with the older ubuntu-support-status command).

I don't think it's wrong in case of "php7.0-fpm", because this package is in universe and therefore actually _not_ "officially supported by the security team", as mentioned here: https://wiki.ubuntu.com/SecurityTeam/FAQ.

> What is "this" problem in this sentence? That a tool mentions unsupported status?

No, the problem is that "php7.0-fpm" is in universe and therefore "not officially supported by the security team", while it's at the same time a very important component of most web servers.

Unfortunately, I couldn't find any official statement explaining what "unsupported" (or "community supported", as it's called now) actually means. On my 16.04 server, I noticed that I did not receive any updates to "php7.0-fpm" (and the other packages listed above) from "xenial-security" after the first 9 month. I know that there are updates available in "xenial-updates". But, like probably most LTS server administrators, I've only enabled unattended upgrades from "xenial-security" on my server and therefore did not receive the php7.0-XXX updates for a long time...

I've now also enabled unattended upgrades from "xenial-updates", hoping that I get security fixes for my "php7.0-XXX" packages from there, but I'm not sure if that will be the case, because php7.0-fpm is in universe. Furthermore, I'm not sure if enabling unattended upgrades from "xenial-updates" may cause problems, because it does not only contain security fixes... what's is considered "best practice" in this case?

> Again, I think you're just misapprehending what is 'supported' (in that
> there is someone paying attention? -- I'm not sure what you expect,
> exactly) vs. what is in main?

OK, I'll try to make it more clear. This is what I understood so far: according to the source mentioned above, "officially supported" means (in case of Xenial) that a package receives regular security fixes through "xenial-security" for 5 years, while "community supported" means something like "There may be updates, but it's not guaranteed. They may be released shortly after upstream, but maybe only 2 years later. Also, there is no clear distinction between security fixes and other updates." The latter seems to be true for all packages in universe, no matter if they come from "xenial-updates" or any other pocket. Only the packages in main are "officially supported".

And therefore my conclusion is: packages in "universe" are not reliably updated after 9 months and should therefore not be installed on a (public) web server that is only upgraded every 2 to 5 years.
This pretty unrealistic for "php7.0-fpm" (I simply need it), that's why I like to have it in main.

Please correct me if I'm wrong (some sources / official statements would be nice too)! I really hope that I'm wrong in this case :-)

> To be clear, regardless of what `ubuntu-support-status` says, it's not
> like php7.0-fpm is going to stop being available or bugs fixed (there
> aren't that many filed, afaict).

Sounds good, but what does that mean exactly? How long will I receive updates ...

[JK (m0d)]

After some more research, I think that I partly mixed up the "-security vs -updates" with the "main vs. universe" issue. If I understood correctly, -updates contains package updates that are not security related while -security contains only security related updates, but these pockets are NOT related to the "components" (main, universe, etc.), i. e. packages from universe are also updated through -security and -updates pockets, as long as they are supported / maintained. If that's correct, then please ignore my question regarding the unattended-upgrades ;-)

So, my remaining questions are:
- how long will "php7.0-fpm" receive security updates and critical bug-fixes?
- what does "community supported" actually mean? Is it officially defined somewhere?
- how long are packages from universe actually supported and what kind of updates (security, critical bugs, etc.) do they receive?

Thanks

[Robie Basak (racb)]

On Tue, Jun 13, 2017 at 12:36:40PM -0000, JK wrote:
> So, my remaining questions are:
> - how long will "php7.0-fpm" receive security updates and critical bug-fixes?

At least until 16.04 is EOL (April 2021), but see my answer to the next
question.

> - what does "community supported" actually mean? Is it officially defined somewhere?

It means that Canonical make no firm commitment to provide updates, but
all acceptable updates prepared by community members will be gratefully
accepted.

If you are a developer, see https://wiki.ubuntu.com/StableReleaseUpdates
and https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation for
instructions on how to prepare and submit these.

> - how long are packages from universe actually supported and what kind of updates (security, critical bugs, etc.) do they receive?

The same as for main, except that we rely on developers volunteering
updates (both for security and critical bugs) rather than having someone
at Canonical committed to providing them.

I should add:

  * It would be quite unusual to move php7.0-fpm to main
    *in 16.04*. Usually the main/universe split and associated
    commitments are decided before release, and 16.04 has already been
    released. A change to move php7.0-fpm, if it were to happen, would
    affect future releases, not past ones.

  * In practice, most PHP vulnerabilities are likely to affect more than
    just php7.0-fpm. Since php7.0-fpm is built from the same src:php7.0,
    it is likely that you'll get updates from Canonical anyway, since
    an update to the source is likely to be necessary to update the
    binary packages built from the same source that _are_ in main.

[JK (m0d)]

Thanks for the clarification Robie!

Btw, I agree that it's totally reasonable not to move packages to a different component after release. That's why I asked if php7.0-fpm will be moved to main in the next LTS release (18.04).

I still think that it would be great to have all packages that are built from src:php7.0 in main (with guaranteed updates) instead of spreading it out over different components...

[Matthias Klose (doko)]

if it makes sense to demote libapache2-mod-php and promoting the new package, that sounds ok. but that's a seed change for ubuntu-server.

Re-assigning for feedback

[Bryce Harrington (bryce)]

Pulling this bug forward to php7.3 since the issue is still pertinent for consideration.

[Steve Langasek (vorlon)]

Please don't reuse old MIR bugs for new source packages, this obfuscates the history.

Override component to main
php8.1 8.1.0~rc4-1ubuntu2 in jammy: universe/php -> main
libapache2-mod-php8.1 8.1.0~rc4-1ubuntu2 in jammy amd64: universe/httpd/optional/100% -> main
libapache2-mod-php8.1 8.1.0~rc4-1ubuntu2 in jammy arm64: universe/httpd/optional/100% -> main
libapache2-mod-php8.1 8.1.0~rc4-1ubuntu2 in jammy armhf: universe/httpd/optional/100% -> main
libapache2-mod-php8.1 8.1.0~rc4-1ubuntu2 in jammy ppc64el: universe/httpd/optional/100% -> main
libapache2-mod-php8.1 8.1.0~rc4-1ubuntu2 in jammy riscv64: universe/httpd/optional/100% -> main
libapache2-mod-php8.1 8.1.0~rc4-1ubuntu2 in jammy s390x: universe/httpd/optional/100% -> main
libphp8.1-embed 8.1.0~rc4-1ubuntu2 in jammy amd64: universe/php/optional/100% -> main
libphp8.1-embed 8.1.0~rc4-1ubuntu2 in jammy arm64: universe/php/optional/100% -> main
libphp8.1-embed 8.1.0~rc4-1ubuntu2 in jammy armhf: universe/php/optional/100% -> main
libphp8.1-embed 8.1.0~rc4-1ubuntu2 in jammy ppc64el: universe/php/optional/100% -> main
libphp8.1-embed 8.1.0~rc4-1ubuntu2 in jammy riscv64: universe/php/optional/100% -> main
libphp8.1-embed 8.1.0~rc4-1ubuntu2 in jammy s390x: universe/php/optional/100% -> main
php8.1 8.1.0~rc4-1ubuntu2 in jammy amd64: universe/php/optional/100% -> main
php8.1 8.1.0~rc4-1ubuntu2 in jammy arm64: universe/php/optional/100% -> main
php8.1 8.1.0~rc4-1ubuntu2 in jammy armhf: universe/php/optional/100% -> main
php8.1 8.1.0~rc4-1ubuntu2 in jammy i386: universe/php/optional/100% -> main
php8.1 8.1.0~rc4-1ubuntu2 in jammy ppc64el: universe/php/optional/100% -> main
php8.1 8.1.0~rc4-1ubuntu2 in jammy riscv64: universe/php/optional/100% -> main
php8.1 8.1.0~rc4-1ubuntu2 in jammy s390x: universe/php/optional/100% -> main
php8.1-bcmath 8.1.0~rc4-1ubuntu2 in jammy amd64: universe/php/optional/100% -> main
php8.1-bcmath 8.1.0~rc4-1ubuntu2 in jammy arm64: universe/php/optional/100% -> main
php8.1-bcmath 8.1.0~rc4-1ubuntu2 in jammy armhf: universe/php/optional/100% -> main
php8.1-bcmath 8.1.0~rc4-1ubuntu2 in jammy ppc64el: universe/php/optional/100% -> main
php8.1-bcmath 8.1.0~rc4-1ubuntu2 in jammy riscv64: universe/php/optional/100% -> main
php8.1-bcmath 8.1.0~rc4-1ubuntu2 in jammy s390x: universe/php/optional/100% -> main
php8.1-bz2 8.1.0~rc4-1ubuntu2 in jammy amd64: universe/php/optional/100% -> main
php8.1-bz2 8.1.0~rc4-1ubuntu2 in jammy arm64: universe/php/optional/100% -> main
php8.1-bz2 8.1.0~rc4-1ubuntu2 in jammy armhf: universe/php/optional/100% -> main
php8.1-bz2 8.1.0~rc4-1ubuntu2 in jammy ppc64el: universe/php/optional/100% -> main
php8.1-bz2 8.1.0~rc4-1ubuntu2 in jammy riscv64: universe/php/optional/100% -> main
php8.1-bz2 8.1.0~rc4-1ubuntu2 in jammy s390x: universe/php/optional/100% -> main
php8.1-cgi 8.1.0~rc4-1ubuntu2 in jammy amd64: universe/php/optional/100% -> main
php8.1-cgi 8.1.0~rc4-1ubuntu2 in jammy arm64: universe/php/optional/100% -> main
php8.1-cgi 8.1.0~rc4-1ubuntu2 in jammy armhf: universe/php/optional/100% -> main
php8.1-cgi 8.1.0~rc4-1ubuntu2 in jammy ppc64el: universe/php/optional/100% -> main
php8.1-cgi 8.1.0~rc4-1ubuntu2 in jam...