-
Notifications
You must be signed in to change notification settings - Fork 7.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sockets extension compilation errors #7978
Comments
from the linked error report, if ucred is not detected it might be because it needs |
Indeed. Can you please provide it, @devsibwarra? |
|
thanks
seems to be what I expected. |
I confirm this issue on both Alpine & Debian linux. see https://github.com/mvorisek/image-php/runs/4899353809 it seems it can be reproduced with very basic configuration, I wonder how this passed release testing |
Looks like this also impacts the newly released PHP 8.1.2 |
Could any of you please check #7981? |
For me it works now with patch from #7981 with |
Patched |
* PHP-8.0: Fix GH-7978: sockets extension compilation errors
* PHP-8.1: Fix GH-7978: sockets extension compilation errors
We should probably set up a nightly CI job that builds on alpine. We don't pass tests with musl, but we can at least make sure it builds. |
This is why we do RCs. 😁 We need volunteers to help us test the RCs on all sorts of platforms. We don't have the resources or people to do it all. |
What's our protocol for this? The RC in 2 weeks is the next patch release, but I guess we could do a hotfix for 8.0.15 and 8.1.2. Would they be tagged at 8.0.16 and 8.1.3, respectively? If so, we'd need to make sure we branch from |
@ramsey, right. We could do 8.0.16/8.1.3 or 8.0.15pl1/8.1.3pl1 (although the latter is probably a legacy variant now). We could tag on Tuesday and release on Thursday. The question is if it is really necessary; I mean the were no security fixes, so people could stick with 8.0.14/8.1.2 for a while, if they face these build issues. |
If there was an RC for those minor releases, it would be easier to do so. We are currently using the Which docker tag should we use to test out the latest RCs, to filter out and detect issues like these? Both (Can this be improved, such that the community can be a better help?) |
php.net does not offer Docket images; these are provided by somebody else, so please ask them to also provide images of the pre-releases. |
As @cmb69 said, the PHP project doesn't maintain the official Docker images. They are "official" in that they are provided by Docker. However, the PHP project does release RCs of its patch releases. These are not pushed through normal distribution channels, but it's possible to detect their releases through the feed located here: https://qa.php.net/api.php?type=qa-releases&format=json In that feed, there are currently no RCs for any supported versions ( We also announce patch-level RCs on the internals mailing list: |
The docker-library/php project has merged a PR to generate images of PHP RCs, so some folks should keep an eye on that and test it out when our next RCs are tagged. |
Is there a temp. fix for this? |
docker-library/php#1245 (comment) @rlated1337 |
Bug issue: php/php-src#7978 Docker image issue: docker-library/php#1245
Bug issue: php/php-src#7978 Docker image issue: docker-library/php#1245
Bug issue: php/php-src#7978 Docker image issue: docker-library/php#1245
Bug issue: php/php-src#7978 Docker image issue: docker-library/php#1245
This can be reverted when PHP Docker image tag 8.0-fpm-alpine3.15 includes PHP >= 8.0.16.
This reverts commit fbf0eb9.
Description
Building PHP with sockets extension
Related PHP change: 51647eb
Resulted in this output:
Reported initially at docker-library/php#1245
PHP Version
PHP 8.0.15 / PHP 8.1.2
Operating System
Debian Bullseye / Buster, Alpine Linux 3.15
The text was updated successfully, but these errors were encountered: