# Debug Build Container Image for GitHub Packages - Thread: https://externals.io/message/125386 - Original archive: https://news-web.php.net/php.internals/125386 - Started by Go Kudo on 2024-09-02T13:11:49+00:00 - Messages: 11 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #125386 — Go Kudo — 2024-09-02T13:11:49+00:00 URL: https://externals.io/message/125386#125386 Hi Internals. PHP currently does not provide official container images. Given that DockerHub adequately maintains these and considering the maintenance costs, we haven't felt the need to change the status quo. However, the official DockerHub images lack debug builds, which can be somewhat inconvenient when trying to report bugs or reproduce issues. What if we were to provide debug build container images that are compatible with the official DockerHub images? Fortunately, we already conduct most of our development on GitHub, which has a container registry called Packages. This could be achieved simply by creating a single repository under the php organization on GitHub. What are your thoughts on this? Best Regards. Go Kudo --- ## #125388 — Daniil Gentili — 2024-09-02T14:37:50+00:00 URL: https://externals.io/message/125386#125388 · In reply to: #125386 +1 on this, this is very much needed, I encountered the need of a debug version of the docker-library php image almost every week ever since I've started recently, and recently even more, as I've been getting many more segfault reports from my users ever since the release of 8.3.11. Regards, Daniil Gentili. > Hi Internals. > > PHP currently does not provide official container images. Given that > DockerHub adequately maintains these and considering the maintenance > costs, we haven't felt the need to change the status quo. > > However, the official DockerHub images lack debug builds, which can be > somewhat inconvenient when trying to report bugs or reproduce issues. > > What if we were to provide debug build container images that are > compatible with the official DockerHub images? Fortunately, we already > conduct most of our development on GitHub, which has a container > registry called Packages. > > This could be achieved simply by creating a single repository under > the php organization on GitHub. What are your thoughts on this? > > Best Regards. > Go Kudo --- ## #125396 — kevin@dunglas.fr — 2024-09-02T21:59:39+00:00 URL: https://externals.io/message/125386#125396 · In reply to: #125388 This would help the FrankenPHP project a lot! The build script used for the official images already contains an environment variable for creating variants containing debugging symbols: https://github.com/docker-library/php/blob/a15b1e1448d2f99db63f68dc4ce21da9a82f5aad/Dockerfile-linux.template#L406 Basically, all the PHP project has to do is build and publish these debug images. I can help with that. Best, On Mon, Sep 2, 2024 at 4:40 PM Daniil Gentili wrote: > +1 on this, this is very much needed, I encountered the need of a debug > version of the docker-library php image almost every week ever since > I've started recently, and recently even more, as I've been getting many > more segfault reports from my users ever since the release of 8.3.11. > > Regards, > > Daniil Gentili. > > > > […] --- ## #125397 — Ben Ramsey — 2024-09-02T23:44:21+00:00 URL: https://externals.io/message/125386#125397 · In reply to: #125386 > > > Hi Internals. > > PHP currently does not provide official container images. Given that DockerHub adequately maintains these and considering the maintenance costs, we haven't felt the need to change the status quo. > > However, the official DockerHub images lack debug builds, which can be somewhat inconvenient when trying to report bugs or reproduce issues. > > What if we were to provide debug build container images that are compatible with the official DockerHub images? Fortunately, we already conduct most of our development on GitHub, which has a container registry called Packages. > > This could be achieved simply by creating a single repository under the php organization on GitHub. What are your thoughts on this? > > Best Regards. > Go Kudo Since the folks who do the DockerHub builds already have all the infrastructure set up to maintain the images, I think it might be easier to work with them to have them provide debug builds. Perhaps there’s someone from that team on this list who can speak to that? Cheers, Ben --- ## #125398 — Bob Weinand — 2024-09-02T23:53:37+00:00 URL: https://externals.io/message/125386#125398 · In reply to: #125397 > > […] > > Since the folks who do the DockerHub builds already have all the infrastructure set up to maintain the images, I think it might be easier to work with them to have them provide debug builds. > > Perhaps there’s someone from that team on this list who can speak to that? > > Cheers, > Ben Hey Ben, what I'd _really_ like to see is not debug-builds, but debug symbols. Basically, you'd have a docker image "php:8.3" and a docker image "php:8.3-dbgsym". The former image then just has a gnu_debuglink. The latter has the actual symbols file included and is based on the former. Thanks, Bob --- ## #125400 — Ben Ramsey — 2024-09-03T00:18:30+00:00 URL: https://externals.io/message/125386#125400 · In reply to: #125398 > > > > > […] > > Hey Ben, > > what I'd _really_ like to see is not debug-builds, but debug symbols. > > Basically, you'd have a docker image "php:8.3" and a docker image "php:8.3-dbgsym". The former image then just has a gnu_debuglink. The latter has the actual symbols file included and is based on the former. > > > Thanks, > > Bob I think the team who manages the Docker builds could also provide images with debug symbols. Since they’re already equipped for it and have the experience, why don’t we partner with them to provide these images to the community? Cheers, Ben Cheers, Ben --- ## #125401 — Bob Weinand — 2024-09-03T00:36:11+00:00 URL: https://externals.io/message/125386#125401 · In reply to: #125400 > > […] > > I think the team who manages the Docker builds could also provide images with debug symbols. Since they’re already equipped for it and have the experience, why don’t we partner with them to provide these images to the community? > > Cheers, > Ben Yes. Absolutely. The problem, however, if you want to provide a build with debug symbols and one without, the primary value for me would be being able to take a core dump produced in an image without debug symbols and then simply open the image with debug symbols and inspect it there. To the best of my knowledge however, it isn't trivially possible to build two docker images with the same docker build invocation. Basically you'd need an intermediary image, from which you then create both (so, 3 different docker builds - one base image which has the build and the symbols but is not uploaded. And two images where the base images files are copied into.). I believe this would not be compatible with the way docker-library/php is built currently. So, yes, please reach out to them what they are willing to do. Thanks, Bob --- ## #125402 — Ben Ramsey — 2024-09-03T01:34:48+00:00 URL: https://externals.io/message/125386#125402 · In reply to: #125401 > > > > > […] > Yes. Absolutely. > The problem, however, if you want to provide a build with debug symbols and one without, the primary value for me would be being able to take a core dump produced in an image without debug symbols and then simply open the image with debug symbols and inspect it there. > To the best of my knowledge however, it isn't trivially possible to build two docker images with the same docker build invocation. Basically you'd need an intermediary image, from which you then create both (so, 3 different docker builds - one base image which has the build and the symbols but is not uploaded. And two images where the base images files are copied into.). I believe this would not be compatible with the way docker-library/php is built currently. > So, yes, please reach out to them what they are willing to do. > > Thanks, > Bob I opened an issue on their GitHub tracker to gauge their interest: https://github.com/docker-library/php/issues/1538 Cheers, Ben --- ## #125406 — Go Kudo — 2024-09-03T07:47:23+00:00 URL: https://externals.io/message/125386#125406 · In reply to: #125402 2024年9月3日(火) 10:35 Ben Ramsey : > > […] > DockerHub adequately maintains these and considering the maintenance costs, > we haven't felt the need to change the status quo. > > […] > be somewhat inconvenient when trying to report bugs or reproduce issues. > > […] > compatible with the official DockerHub images? Fortunately, we already > conduct most of our development on GitHub, which has a container registry > called Packages. > > […] > the php organization on GitHub. What are your thoughts on this? > > […] > infrastructure set up to maintain the images, I think it might be easier to > work with them to have them provide debug builds. > > […] > that? > > […] > "php:8.3-dbgsym". The former image then just has a gnu_debuglink. The > latter has the actual symbols file included and is based on the former. > > […] > images with debug symbols. Since they’re already equipped for it and have > the experience, why don’t we partner with them to provide these images to > the community? > > […] > and one without, the primary value for me would be being able to take a > core dump produced in an image without debug symbols and then simply open > the image with debug symbols and inspect it there. > > […] > build two docker images with the same docker build invocation. Basically > you'd need an intermediary image, from which you then create both (so, 3 > different docker builds - one base image which has the build and the > symbols but is not uploaded. And two images where the base images files are > copied into.). I believe this would not be compatible with the way > docker-library/php is built currently. > > […] > > > I opened an issue on their GitHub tracker to gauge their interest: > https://github.com/docker-library/php/issues/1538 > > Cheers, > Ben > > > > Hi. I think it's great that drop-in replacement images are being provided on DockerHub. Thank you for the suggestion! However, I believe it would be beneficial to have image variants as well. For instance, providing images with LLVM MemorySanitizer enabled builds would allow us to easily conduct various tests using our local PHP code. This would also be useful for testing third-party extensions. For safely developing PHP extensions, I primarily use the following build variants: - The build provided by DockerHub - GCC debug build - GCC debug with gcov build - GCC Valgrind build - Clang MSan build - Clang ASan build - Clang UBSan build These images are intended for development purposes, and it might be challenging to host them on DockerHub, which typically hosts images for general use. That said, I already maintain these [1], and I think it could be beneficial to offer them as official PHP images. Of course, I plan to continue maintaining them if we decide to do so. Additionally, I'd like to point out that we could utilize the existing GitHub infrastructure for both the build environment and hosting environment when publishing these images. [1] https://github.com/colopl/pskel Best Regards, Go Kudo --- ## #125545 — Daniil Gentili — 2024-09-14T15:14:23+00:00 URL: https://externals.io/message/125386#125545 · In reply to: #125406 It seems like the discussion on github has stalled... --- ## #125558 — Go Kudo — 2024-09-15T12:48:18+00:00 URL: https://externals.io/message/125386#125558 · In reply to: #125545 2024年9月15日(日) 0:15 Daniil Gentili : > It seems like the discussion on github has stalled... > Hello, I've been continuing to approach this issue and I'm considering whether we could publish nightly builds of php-src as container images on GitHub Packages. If this becomes a reality, it would allow for quicker reproduction of bugs and setup of development environments. https://github.com/zeriyoshi/php-containers-development/pkgs/container/php-containers-development I feel we could meet the requirements if we could create an image based on this one that's compatible with the php image on DockerHub. Best regards, Go Kudo