From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marius Bakke Subject: Re: [PATCH] Add php Date: Thu, 17 Nov 2016 19:22:48 +0100 Message-ID: <87a8cyc6fb.fsf@kirby.i-did-not-set--mail-host-address--so-tickle-me> References: <20161030130828.3797d37d@polymos.lepiller.eu> <20161030175105.1f6eeff2@polymos.lepiller.eu> <87ins9s9y1.fsf@duckhunt.i-did-not-set--mail-host-address--so-tickle-me> <20161102224052.7ec98d2d@lepiller.eu> <87eg2k8xp2.fsf@gnu.org> <20161111173123.51375f43@polymos.lepiller.eu> <87eg2etms7.fsf@kirby.i-did-not-set--mail-host-address--so-tickle-me> <87bmxitmdi.fsf@kirby.i-did-not-set--mail-host-address--so-tickle-me> <87y40m8ben.fsf@gnu.org> <8760nqtbg6.fsf@kirby.i-did-not-set--mail-host-address--so-tickle-me> <87lgwm6rwx.fsf@gnu.org> <87h977c6ux.fsf@kirby.i-did-not-set--mail-host-address--so-tickle-me> <89e7b7e761086ed5ace17abc9a7bf435@lepiller.eu> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58286) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c7RKp-00033X-3H for guix-devel@gnu.org; Thu, 17 Nov 2016 13:22:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c7RKl-0001jL-Rf for guix-devel@gnu.org; Thu, 17 Nov 2016 13:22:55 -0500 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:38185) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c7RKl-0001iI-N4 for guix-devel@gnu.org; Thu, 17 Nov 2016 13:22:51 -0500 In-Reply-To: <89e7b7e761086ed5ace17abc9a7bf435@lepiller.eu> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: tyreunom , guix-devel@gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable tyreunom writes: > Le 2016-11-17 01:01, Marius Bakke a =C3=A9crit=C2=A0: >> Ludovic Court=C3=A8s writes: >>=20 >>> Marius Bakke skribis: >>>=20 >>>> Some failures are indeed due to missing network or programs in the=20 >>>> build >>>> environment. I tried patching a few just now, but unfortunately some >>>> files are in a format apparently not supported by Guile! >>>>=20 >>>> 870: 5 [call-with-input-file "ext/mbstring/tests/bug26639.phpt" ...] >>>> In=20 >>>> /gnu/store/ciqw5z470c8ihl1kfswj1j3ix6hs092d-module-import/guix/build/u= tils.scm: >>>> 556: 4 [#>>> /gnu/store/ciqw5z470c8ihl1kfswj1j3ix6hs092d-module-import/guix/buil >>>> d/utils.scm:555:10 (in)> #>>> 11>] >>>> 592: 3 [#>>> /gnu/store/ciqw5z470c8ihl1kfswj1j3ix6hs092d-module-import/guix/buil >>>> d/utils.scm:578:6 (in out)> #>>> 11> ...] >>>> In ice-9/rdelim.scm: >>>> 188: 2 [read-line #=20 >>>> concat] >>>> In unknown file: >>>> ?: 1 [%read-line #] >>>> In ice-9/boot-9.scm: >>>> 109: 0 [#>>> args)> decoding-error ...] >>>>=20 >>>> ice-9/boot-9.scm:109:20: In procedure #>>> ice-9/boot-9.scm:100:6 (thrown-k . arg >>>> s)>: >>>> ice-9/boot-9.scm:109:20: Throw to key `decoding-error' with args=20 >>>> `("scm_getc" "input decoding error >>>> " 84 #)'. >>>>=20 >>>> `file` reports: ext/mbstring/tests/bug26639.phpt: Non-ISO=20 >>>> extended-ASCII text >>>=20 >>> Presumably this is =E2=80=98substitute*=E2=80=99 failing to read the fi= le. >>>=20 >>> =E2=80=98substitute*=E2=80=99 expects input files to be UTF-8-encoded; = when this is=20 >>> not >>> the case, you need to bind =E2=80=98%default-port-encoding=E2=80=99 to = whatever is the >>> right encoding or #f for the catch-all ISO-8859-1. See >>> =E2=80=98gettext-minimal=E2=80=99 for an example. >>=20 >> Thank you! That was exactly what I needed. >>=20 >> Unfortunately that only fixed a handful of tests, the remaining >> 50-something had to be disabled for a variety of reasons. >>=20 >> I've added a commentary to each disabled test. If you recognize any of >> these errors/think you know what's going on, please update the patch. >> It would be nice to know if the iconv and gd stuff is expected, and if >> the two sqlite tests can really be ignored. The curl one is strange=20 >> too. > > Just as I wanted to send a similar patch ;) > > I've been looking at some of them. The failing sqlite test is a bug in=20 > sqlite that has been fixed last august=20 > (https://sqlite.org/src/info/ef360601). We currently have version=20 > 3.14.1, when the latest upstream version is 3.15.1. Updating should fix=20 > the problem. > > 73159 has been fixed in gd: https://github.com/libgd/libgd/issues/289=20 > (more recent than latest gd release unfortunately) > > 73155 has also been fixed in gd:=20 > https://github.com/libgd/libgd/issues/309 (even more recent) > > 72482 is fixed here:=20 > https://gist.github.com/anonymous/873314feb4f89bd8336711333299f748 (a=20 > patch to the bundled libgd) > > 73213 is fixed here:=20 > https://git.php.net/?p=3Dphp-src.git;a=3Dblobdiff;f=3Dext/gd/libgd/gd.c;h= =3D033d4fa5f0e9740e8b8c397a9038a115c617c419;hp=3D0b4b42fa27558fa32cc54e14dc= 297d9d0ba10832;hb=3D9acfb1a3a5268febb123b7e5fbd4eaf072c83537;hpb=3Dc0219b32= 3e0048440acbdd9ad74624c4bc33c335=20 > (a patch to the bundled libgd) > > 72339 has a CVE id: 2016-5766, but it should be fixed in libgd 2.2.3=20 > that we have according to the CVE description, and the failure is=20 > different from what the report says. > > 39780 has the unexpected output described in the bug report, so it=20 > really fails. I don't think we can fix our libgd though, because the=20 > bundled one has some php_* functions that are used to get a warning=20 > instead of an error. > > we could include patches to our libgd to fix two (maybe four) issues. We= =20 > should also upgrade our sqlite version, but many packages will then have= =20 > to be rebuilt, or we could create a separate package for the newer=20 > version. What do you suggest? Wow, thanks for this list! Including the two upstream gd fixes in a "gd-for-php" package should be fine, until a new release of gd is out. I'm more vary about including the PHP-specific ones though. If there are serious problems with using an external (vanilla) gd, I think we either need to maintain a "gd-for-php" package indefinitely, or bite the bullet and use the bundled one. Do you think it's safe to use our gd? And if not, would you be willing to keep up with PHP development and maintain the externalized gd component with it? I've confirmed that using a newer sqlite fixes the sqlite test, thanks for that. I will submit a "sqlite-3.15.1" package with this patch, and make sure it's updated in the next 'core-updates' cycle. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJYLfV4AAoJEKKgbfKjOlT6kD4H/RTm687RROzQBod2jCAsRiGA kEPkGkMITl+pdEZb99j8VNdZeZW4NZPNaJF5HK4C+QNHh4bEKAbjcLUIJC73TGyJ 8u6NnCQtWMcLLDlurdF0vYdR5ZsqIaHfzuDUrT7zUe1amVJDtPMBE+TQBBeJVZuT 0y1igfoxLIC/Lur5AV4gRScvKhUDaSHNdOPPD2Yq5xfovpjigd4W7M1STqaAHrH6 QoZESF698cqqFo7LfRdWJ9qPr0I2X0Hq6W+ERkNXTXlTMwRZfe9bXSas0VdnWllY wnF6G5MVh4+INyFxANwPoF0gVKq+bYnYbczCFI1IBYon5cHifopz5Nq7jCMwEb8= =4SSF -----END PGP SIGNATURE----- --=-=-=--