bug#72962: php-8.3.10 build failure

bug#72962: php-8.3.10 build failure

[Marek Paśnikowski via Bug reports for GNU Guix]

Good morning or afternoon.

I am not able to update my system due to the following build failure:

standard output context
~
The following derivations will be built:
  /gnu/store/m7jd9csjwb8yvznassm2mgkx8nyx9m0q-easyeffects-7.1.7.drv
  /gnu/store/1gr6a27wls2xlykjqkgy51pxv8c5hfmi-lsp-plugins-1.2.15.drv
  /gnu/store/gxjs8dzg8gmif2gj1ybkxxzv623qpq4q-php-8.3.10.drv
~

build log context
~
configure: error: Package requirements (gdlib >= 2.1.0) were not met:

Package 'freetype2', required by 'gdlib', not found
~

I checked with the source code of (gnu packages php) — freetype does not
exist in the file.

I apologize for not posting a patch, but I am still wrapping my head
around concepts more fundamental than patch submission.  For example, I
think it is a good idea to Cc the PHP team here, but failed to find
documentation on how to identify the team’s email address.

bug#72962: php-8.3.10 build failure

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

merge 72943 72962
thanks
^ bot commands

Hi Marek,

> I apologize for not posting a patch, but I am still wrapping my head
> around concepts more fundamental than patch submission.

Good news!  I've merged this issue with the likely cause and a possible 
fix.

> For example, I
> think it is a good idea to Cc the PHP team here, but failed to find
> documentation on how to identify the team’s email address.

Teams don't have addresses/aliases, so you could have kept looking.

The teams are defined[0] in the Guix git repository, to facilitate 
automation[1] integrated with ‘git send-email’, and to keep one 
consistent source of truth.

If those examples look too complicated, ignore them, and just manually 
look up your favourite team members :-)

Kind regards,

T G-R

Sent from a Web browser.  Excuse or enjoy my brevity.

[0]: https://git.savannah.gnu.org/cgit/guix.git/tree/etc/teams.scm
[1]: https://guix.gnu.org/manual/devel/en/html_node/Teams.html

[bug#72962] php-8.3.10 build failure

[Rutherther via Guix-patches via]

Hello everyone,

note that the linked issue solves this only partially.
It fixes gd itself, but then there are still three
failing tests in php.

I suggest this as current workaround locally:
---
(use-modules
 (guix packages)
 (gnu packages gd)
 (gnu packages php))

(define gd-fixed
  (package/inherit gd
    (name "gd-fixed")
    (propagated-inputs
     (package-inputs gd))))

(define php
  (package/inherit php
    (inputs (modify-inputs (package-inputs php)
              (replace "gd" gd-fixed)))))

php

[bug#72962] php-8.3.10 build failure

[Nathan Dehnel]

ping

[bug#72943] [PATCH] gnu: gd: Requires.private to propagated inputs

[Carlo Zancanaro]

On Mon, Sep 02 2024, Rutherther via Guix-patches via wrote:
> It seems much better to me to not use propagated-inputs whenever possible,
> so I prefer your solution to this one. However, I do wonder about this: other packages that
> have Requires.private do provide the libraries in these as propagated-inputs. Also
> the cookbook shows to do this with such libraries. What is the correct approach here
> then? Maybe every package that has Requires.private could be patched like this, possibly
> somehow automatically instead of manual patches?

Ah, I didn't look into it, so I didn't know that other packages in the
same situation just propagate their inputs. If that's more consistent
with the rest of Guix's packages then it would probably be better to do
that than restoring the patch.

> I am quite new here, this is my first patch. So I am not really sure how to go about this.
> Will you open a new issue with your patch, and maintainers will decide patch from which
> issue to use? Or is it enough it's in this issue?

I wasn't planning to open a new issue. Ideally I think we would agree on
which change is more appropriate, then someone with commit access would
apply it.

If this problem is solved elsewhere in Guix with propagated-inputs, then
I think your change is a better idea than mine.

This still leaves the issue of the failing tests, though. I investigated
a bit and looking at [1] and [2], I believe the issue is that our
version of libgd doesn't support the BICUBIC interpolation method.

I'm rebuilding PHP now with those tests removed. I'll send through some
patches soon.

Carlo

[1]: https://github.com/php/php-src/issues/11252
[2]: https://github.com/libgd/libgd/issues/847

[bug#72943] [PATCH 2/2] gnu: php: Disable tests relating to BICUBIC interpolation.

[Carlo Zancanaro]

* gnu/packages/php.scm (php)[arguments]: Delete three tests that are known to
fail.

Change-Id: Ib684328654c75f37111d252fb0f9fb3356daff9a
---
 gnu/packages/php.scm | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/gnu/packages/php.scm b/gnu/packages/php.scm
index 8f879dbdca..ce7458d0e5 100644
--- a/gnu/packages/php.scm
+++ b/gnu/packages/php.scm
@@ -253,6 +253,13 @@ (define-public php
                          ;; AVIF support disabled
                          "ext/gd/tests/imagecreatefromstring_avif.phpt"
 
+                         ;; These tests fail due to issues in upstream gd
+                         ;; 2.3.3 around BICUBIC interpolation.  See
+                         ;; https://github.com/libgd/libgd/issues/847
+                         "ext/gd/tests/bug79676.phpt"
+                         "ext/gd/tests/imageinterpolation_basic.phpt"
+                         "ext/gd/tests/imagescale_preserve_ratio.phpt"
+
                          ;; XXX: These test failures appear legitimate, needs investigation.
                          ;; open_basedir() restriction failure.
                          "ext/curl/tests/curl_setopt_ssl.phpt"
-- 
2.45.2

[bug#72962] php-8.3.10 build failure

[guix-patches--- via]

Carlo Zancanaro <carlo@zancanaro.id.au> writes:

> * gnu/packages/php.scm (php)[arguments]: Delete three tests that are known to
> fail.
>

This is my first time composing a patch review — I am not sure if I am
doing it correctly.

I attempted to build php with the following command:
=
guix build php --with-patch=gd=patch-1.txt --with-patch=php=patch-2.txt
=

The text files are files saved by using the “download” option of the web
interface of Guix Issues.  My understanding is that the patch to gd
applies cleanly, but the patch to php does not:

=
source is at 'php-8.3.10'
applying '/gnu/store/f2zxspb49cbcmcla3mbjrikl48kmbf52-patch-2.txt'...
can't find file to patch at input line 13
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|* gnu/packages/php.scm (php)[arguments]: Delete three tests that are known to
|fail.
|
|Change-Id: Ib684328654c75f37111d252fb0f9fb3356daff9a
|---
| gnu/packages/php.scm | 7 +++++++
| 1 file changed, 7 insertions(+)
|
|diff --git a/gnu/packages/php.scm b/gnu/packages/php.scm
|index 8f879dbdca..ce7458d0e5 100644
|--- a/gnu/packages/php.scm
|+++ b/gnu/packages/php.scm
--------------------------
No file to patch.  Skipping patch.
1 out of 1 hunk ignored
patch unexpectedly ends in middle of line
=

Is this helpful?

[bug#72943] bug#72962: php-8.3.10 build failure

[Carlo Zancanaro]

Hi Marek!

On Wed, Sep 04 2024, Marek Paśnikowski wrote:
> This is my first time composing a patch review — I am not sure if I am
> doing it correctly.

Thanks for taking a look at my patch!

> I attempted to build php with the following command:
> =
> guix build php --with-patch=gd=patch-1.txt --with-patch=php=patch-2.txt
> =

I don't expect this command to work. The --with-patch argument expects
to apply the patch to the source of the package, whereas the patches I
have prepared should be applied on a checkout of the Guix git repository
(which you can clone from https://git.savannah.gnu.org/git/guix.git).

You should be able to apply them in a fresh clone of the repository with
"git am $patch-name". To build, you can follow the instructions in the
manual "(guix) Building from Git". After that, you can build PHP with
these patches with "./pre-inst-env guix build php".

This can take a bit of time, but things are easier once you're set up
with a working Guix clone.

Carlo

[bug#72962] php-8.3.10 build failure

[guix-patches--- via]

Carlo Zancanaro <carlo@zancanaro.id.au> writes:

>> I attempted to build php with the following command:
>> =
>> guix build php --with-patch=gd=patch-1.txt --with-patch=php=patch-2.txt
>> =
>
> You should be able to apply them in a fresh clone of the repository with
> "git am $patch-name". To build, you can follow the instructions in the
> manual "(guix) Building from Git". After that, you can build PHP with
> these patches with "./pre-inst-env guix build php".
>

I had a guix clone from previous attempts to patch things, so I
proceeded to apply the patches.  Patch 1 returned a message along the
lines (translation) of "apply: * gnu/packages/gd.scm (gd): Change inputs
to propagated-inputs".  However,
=
LC_ALL=C git am ../Downloads/patch-2.txt
Patch format detection failed.
=

[bug#72962] php-8.3.10 build failure

[guix-patches--- via]

Upon further inspection, I noticed the second patch is missing the
From: <email> header.  I copied it from the first patch and it applied.

The build is now in progress on my slow laptop, so I am sending this
report immediately.

[bug#72962] php-8.3.10 build failure

[guix-patches--- via]

The build completed and passed all the tests.

Is this the right moment to say reviewed-looks-good? Would I do it by
writing the usertag followed by thanks in the beginning of the message?
Or am I confusing concepts?