Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:125406 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id 18BB01A00BD for ; Tue, 3 Sep 2024 07:47:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1725349774; bh=LYVldUO2HmUkJG7QVar+P2HtsBhsdJvlT7fNnQWvtpM=; h=References:In-Reply-To:From:Date:Subject:To:From; b=A7mN60szgJE7NkD2i6Vjcl0ONKDDPkXQWZyI4CMYpBGwsj4VdowgG30LIp/v4AJLx 2mwWjFAj+jJtyuJV76bp9XPxcq0sl7BjrlIgIvxKLho2pXd0zpEAAtc0eveER9fE// M8Uqt0mHOupV26OeLft8VF0Ujds+Tsg0VuLsmJoEZLEOXD9RERAaCEBOQAywNfeCuD hyUv5zmyZG++P8xAkgJNZiVKmG9n1tSqPvVqA10D7Tm0hUM9U2JjS2y8lh4hmO6Noh ++UYyb9N6AwMq+8wjW1a1dAgG9q95gqORUV6Eyk0DCTMEwZs2SO+EP+2nR3mVVCXlb tlJ91trGB9xbw== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 07623180068 for ; Tue, 3 Sep 2024 07:49:34 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-qk1-f180.google.com (mail-qk1-f180.google.com [209.85.222.180]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 3 Sep 2024 07:49:33 +0000 (UTC) Received: by mail-qk1-f180.google.com with SMTP id af79cd13be357-7a966f0a985so122356185a.3 for ; Tue, 03 Sep 2024 00:47:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725349655; x=1725954455; darn=lists.php.net; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=LYVldUO2HmUkJG7QVar+P2HtsBhsdJvlT7fNnQWvtpM=; b=M1D42MS7rPEciBE9Jm4OKCvpXXrLhRF6dHzW4aZOESXW+MJMV96DD0KwpEbtVuEYld esUjup2I+Wt+RTw2dD7gu6P4ombGnYeBy10nQLRa4pP15dT7Io5HLEsVxjT2aYen3Ga9 WZ6eblgrF5c1Eucy+9rSN7gmTFtGC/eLos9oUMboMQ6Eq3CHt21u125vapFn7eFXdpV2 e3lkAgPYXURtmprtbU2NpmE5XYaFJ2Jq76GvuzT3/oVYheAoJcTpIkSrW0klTgVLBC6P bLfoRnIr5Riq5FeWDfOXdSilblRdHPvNxuldvbrtt2XXWuIxnn2XUPQ+9kKyoG60ZIzD zwFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725349655; x=1725954455; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=LYVldUO2HmUkJG7QVar+P2HtsBhsdJvlT7fNnQWvtpM=; b=bNN0jnr5nsNjviZ5uyAE/eubbmQx9VAVx4kjhoxWvpxBcAwVbIT60eYRcBA+0v/80z etD+HvFfeJioqWk+bAJtFA6EgFWyuD0Hgd5x6l9ZutKvTQw5M8lODwApKC3zo2kextd0 BYYEKjyMPtAv76+8V4cUz+F80HqQyGUaVmYwrVjTFdfog4pGgyXNdTa8rlOSSmp/w0DS 6itXeN3c8ea5BEwnVhNpOCZJTgEZJZ2cCE6AUeX9zAhS6pLtaXNL159yrBq2jxqhsEwM n8fUu/FgLA6cIt1k8DtJma/TQnpFTjYBdbsumXU1ownMMg2Vq3xzrhufkCoeiH3XYgLu 44uQ== X-Gm-Message-State: AOJu0YyE6VDsuGaGRikw895Jtj0mCmn4/HO6g/Ay0LHSNBSuR3FNzKO1 /RlXiefSM+yGxbm8QtjkZkAGpVOYnpgK+43zOwwjn9kY5hBVpcqmFzu6weAuznQ8sW41tjgeP8B W8Cg/6QUtGwznlzd71Eaiy59vYfIBATQP X-Google-Smtp-Source: AGHT+IFcWa/bkPbQ5YPZ4cMl+iu16bkO6AfSooiPFqwJNpJXrlBMOMvXS9qRNLjT6Av0/vPbBH3T7quPLnTsnOhzBhE= X-Received: by 2002:a05:6214:570a:b0:6c3:5a86:6a2e with SMTP id 6a1803df08f44-6c510d11ffamr10987626d6.50.1725349655230; Tue, 03 Sep 2024 00:47:35 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 References: <5C7B4216-6D52-4BF0-9C30-89DD5465FB48@php.net> <8D35CEB1-3B48-4889-BEAB-63AAE6DB8A01@php.net> <444E0751-A2DD-4581-9134-95D580702FBB@php.net> In-Reply-To: <444E0751-A2DD-4581-9134-95D580702FBB@php.net> Date: Tue, 3 Sep 2024 16:47:23 +0900 Message-ID: Subject: Re: [PHP-DEV] Debug Build Container Image for GitHub Packages To: PHP internals Content-Type: multipart/alternative; boundary="00000000000050432e062132452f" From: zeriyoshi@gmail.com (Go Kudo) --00000000000050432e062132452f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2024=E5=B9=B49=E6=9C=883=E6=97=A5(=E7=81=AB) 10:35 Ben Ramsey : > > On Sep 2, 2024, at 19:36, Bob Weinand wrote: > > > > On 3.9.2024 02:18:30, Ben Ramsey wrote: > >>> On Sep 2, 2024, at 18:53, Bob Weinand wrote: > >>> > >>> On 3.9.2024 01:44:21, Ben Ramsey wrote: > >>> > >>>>> On Sep 2, 2024, at 08:11, Go Kudo wrote: > >>>>> > >>>>> Hi Internals. > >>>>> > >>>>> PHP currently does not provide official container images. Given tha= t > DockerHub adequately maintains these and considering the maintenance cost= s, > 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=E2=80=99s 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 > >>> > >> > >> I think the team who manages the Docker builds could also provide > images with debug symbols. Since they=E2=80=99re already equipped for it = and have > the experience, why don=E2=80=99t we partner with them to provide these i= mages 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 a= re > 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 > > > > 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 --00000000000050432e062132452f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

2024=E5=B9=B49=E6=9C=883=E6=97=A5(=E7=81= =AB) 10:35 Ben Ramsey <ramsey@php.net<= /a>>:
> On= Sep 2, 2024, at 19:36, Bob Weinand <bobwei9@hotmail.com> wrote:
>
> On 3.9.2024 02:18:30, Ben Ramsey wrote:
>>> On Sep 2, 2024, at 18:53, Bob Weinand <bobwei9@hotmail.com> wrote:
>>>
>>> On 3.9.2024 01:44:21, Ben Ramsey wrote:
>>>
>>>>> On Sep 2, 2024, at 08:11, Go Kudo <zeriyoshi@gmail.com> wrote:=
>>>>>
>>>>> Hi Internals.
>>>>>
>>>>> PHP currently does not provide official container imag= es. Given that DockerHub adequately maintains these and considering the mai= ntenance costs, we haven't felt the need to change the status quo.
>>>>>
>>>>> However, the official DockerHub images lack debug buil= ds, which can be somewhat inconvenient when trying to report bugs or reprod= uce issues.
>>>>>
>>>>> What if we were to provide debug build container image= s that are compatible with the official DockerHub images? Fortunately, we a= lready conduct most of our development on GitHub, which has a container reg= istry called Packages.
>>>>>
>>>>> This could be achieved simply by creating a single rep= ository under the php organization on GitHub. What are your thoughts on thi= s?
>>>>>
>>>>> Best Regards.
>>>>> Go Kudo
>>>>>
>>>> Since the folks who do the DockerHub builds already have a= ll the infrastructure set up to maintain the images, I think it might be ea= sier to work with them to have them provide debug builds.
>>>>
>>>> Perhaps there=E2=80=99s someone from that team on this lis= t who can speak to that?
>>>>
>>>> Cheers,
>>>> Ben
>>>>
>>> Hey Ben,
>>>
>>> what I'd _really_ like to see is not debug-builds, but deb= ug symbols.
>>>
>>> Basically, you'd have a docker image "php:8.3" a= nd a docker image "php:8.3-dbgsym". The former image then just ha= s a gnu_debuglink. The latter has the actual symbols file included and is b= ased on the former.
>>>
>>>
>>> Thanks,
>>>
>>> Bob
>>>
>>
>> I think the team who manages the Docker builds could also provide = images with debug symbols. Since they=E2=80=99re already equipped for it an= d have the experience, why don=E2=80=99t we partner with them to provide th= ese images to the community?
>>
>> Cheers,
>> Ben
> Yes. Absolutely.
> The problem, however, if you want to provide a build with debug symbol= s and one without, the primary value for me would be being able to take a c= ore dump produced in an image without debug symbols and then simply open th= e image with debug symbols and inspect it there.
> To the best of my knowledge however, it isn't trivially possible t= o 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 symb= ols but is not uploaded. And two images where the base images files are cop= ied into.). I believe this would not be compatible with the way docker-libr= ary/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




Hi.

I t= hink it's great that drop-in replacement images are being provided on D= ockerHub. Thank you for the suggestion!

However, I believe it would = be beneficial to have image variants as well. For instance, providing image= s with LLVM MemorySanitizer enabled builds would allow us to easily conduct= various tests using our local PHP code. This would also be useful for test= ing 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 Valg= rind build
- Clang MSan build
- Clang ASan build
- Clang UBSan bui= ld

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 co= ntinue 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 the= se images.

[1] https://g= ithub.com/colopl/pskel

Best Regards,
Go Kudo<= br>
=C2=A0
--00000000000050432e062132452f--