Package Details: php70 7.0.33-9

Git Clone URL: https://aur.archlinux.org/php70.git (read-only, click to copy)
Package Base: php70
Description: PHP. A general-purpose scripting language that is especially suited to web development
Upstream URL: http://www.php.net
Licenses: PHP
Submitter: betrixed
Maintainer: wget (el_aur)
Last Packager: el_aur
Votes: 11
Popularity: 0.122062
First Submitted: 2017-02-05 08:12 (UTC)
Last Updated: 2022-02-18 12:01 (UTC)

Sources (18)

Pinned Comments

el_aur commented on 2022-02-03 18:46 (UTC) (edited on 2022-02-04 11:29 (UTC) by el_aur)

Created binary repository on build.opensuse.org

https://build.opensuse.org/project/show/home:el:archphp

For Arch Linux, edit /etc/pacman.conf and add the following (note that the order of repositories in pacman.conf is important, since pacman always downloads the first found package):

[home_el_archphp_Arch]
Server = https://download.opensuse.org/repositories/home:/el:/archphp/Arch/$arch

Then run the following as root

key=$(curl -fsSL https://download.opensuse.org/repositories/home:el:archphp/Arch/$(uname -m)/home_el_archphp_Arch.key)
fingerprint=$(gpg --quiet --with-colons --import-options show-only --import --fingerprint <<< "${key}" | awk -F: '$1 == "fpr" { print $10 }')
pacman-key --init
pacman-key --add - <<< "${key}"
pacman-key --lsign-key "${fingerprint}"

Refresh packages database

pacman -Syy

Now search for php packages you need:

pacman -Ss php70

Install with pacman -S packages you need or all PHP 7.0 packages with:

sudo pacman -S $(pacman -Ssq | grep '^php70')

el_aur commented on 2022-02-03 18:45 (UTC) (edited on 2022-02-03 18:47 (UTC) by el_aur)

Read Carefully! Breaking changes in compare with native PHP package

  1. Console version /usr/bin/php70 is installed with php70-cli subpackage, php81 doesn't include it anymore!!!

  2. PEAR and PECL are available as php70-pear and php70-pecl subpackages

  3. All shared modules are respresented as stand-alone subpackages and are not included with php70 package anymore.

  4. No more extensions in php.ini itself!

Separate INI files for each extension are placed in /etc/php70/conf.d

They are loaded in correct order according to priority

Latest Comments

el_aur commented on 2022-02-03 18:46 (UTC) (edited on 2022-02-04 11:29 (UTC) by el_aur)

Created binary repository on build.opensuse.org

https://build.opensuse.org/project/show/home:el:archphp

For Arch Linux, edit /etc/pacman.conf and add the following (note that the order of repositories in pacman.conf is important, since pacman always downloads the first found package):

[home_el_archphp_Arch]
Server = https://download.opensuse.org/repositories/home:/el:/archphp/Arch/$arch

Then run the following as root

key=$(curl -fsSL https://download.opensuse.org/repositories/home:el:archphp/Arch/$(uname -m)/home_el_archphp_Arch.key)
fingerprint=$(gpg --quiet --with-colons --import-options show-only --import --fingerprint <<< "${key}" | awk -F: '$1 == "fpr" { print $10 }')
pacman-key --init
pacman-key --add - <<< "${key}"
pacman-key --lsign-key "${fingerprint}"

Refresh packages database

pacman -Syy

Now search for php packages you need:

pacman -Ss php70

Install with pacman -S packages you need or all PHP 7.0 packages with:

sudo pacman -S $(pacman -Ssq | grep '^php70')

el_aur commented on 2022-02-03 18:45 (UTC) (edited on 2022-02-03 18:47 (UTC) by el_aur)

Read Carefully! Breaking changes in compare with native PHP package

  1. Console version /usr/bin/php70 is installed with php70-cli subpackage, php81 doesn't include it anymore!!!

  2. PEAR and PECL are available as php70-pear and php70-pecl subpackages

  3. All shared modules are respresented as stand-alone subpackages and are not included with php70 package anymore.

  4. No more extensions in php.ini itself!

Separate INI files for each extension are placed in /etc/php70/conf.d

They are loaded in correct order according to priority

wget commented on 2022-02-03 13:56 (UTC)

@el_aur thanks made you co maintainer :)

el_aur commented on 2022-01-27 16:28 (UTC)

Hi guys. Wanna adopt this package. Have made universal builds for all PHP versions 5.3-8.1. Maintaining already php55, php72, php73, php74, php81 in AUR

el_aur commented on 2022-01-25 14:33 (UTC)

Have ported cve patches and Debian patches, can share here if you make me comaintainer :)

PetrP commented on 2021-12-12 13:07 (UTC)

To get this compile with libicu70, I used those two patches:

git apply <(wget -qO- https://gist.githubusercontent.com/PetrP/7310f2b6bbf25be87f3f04d866104e66/raw/rakotomandimby.patch)
git apply <(wget -qO- https://gist.githubusercontent.com/PetrP/7310f2b6bbf25be87f3f04d866104e66/raw/icu70.patch)

First is from rakotomandimby's comment bellow, second is slightly modified version of this patch from php72 NAlien's comment

rakotomandimby commented on 2021-09-30 20:39 (UTC)

Hi all,

I made a repo where:

  1. I tooked the snapshot https://aur.archlinux.org/cgit/aur.git/snapshot/php70.tar.gz
  2. I addressed the TRUE and FALSE undeclared issue
  3. I addressed the GD_FLIP_HORINZONTAL GD_FLIP_VERTICAL GD_FLIP_BOTH undeclared issue https://aur.archlinux.org/packages/php74/#comment-826973

Maintainer, feel free to get it at: https://bitbucket.org/rakotomandimby/aur-php70/commits/06d776e99e5192c4284f1c51061325a6efbcaa71

Users, you can just clone the repo and run "makepkg"

hamedsbt commented on 2021-08-25 04:14 (UTC)

@df8oe , I confirm solution by @reibeku (from php71 thread) it's working:

open PKGBUILD file and Replace:


build() {
    local phpConfig="\
        --srcdir=../${_pkgbase}-${pkgver} \
        --config-cache \

With:


build() {
        export CC="gcc -DTRUE=1 -DFALSE=0"
        export CXX="g++ -DTRUE=1 -DFALSE=0"
    local phpConfig="\
        --srcdir=../${_pkgbase}-${pkgver} \
        --config-cache \

Thank you @reibeku

df8oe commented on 2021-04-29 06:29 (UTC)

I can confirm issue like @MrKMG reports - same for php71 packages.

MrKMG commented on 2021-03-15 18:53 (UTC) (edited on 2021-03-15 18:53 (UTC) by MrKMG)

I am getting the following errors while compiling with gcc version 10.2.0.

php-7.0.33/ext/intl/collator/collator_sort.c:347:26: error: ‘TRUE’ undeclared (first use in this function)
php-7.0.33/ext/intl/collator/collator_sort.c:541:26: error: ‘FALSE’ undeclared (first use in this function)

After some googling, it appears that nothing included contains #DEFINE TRUE or #DEFINE FALSE

Not sure what the appropriate way to address this is.

anxest commented on 2020-12-30 07:04 (UTC) (edited on 2020-12-30 07:09 (UTC) by anxest)

Looks like there is a new issue with icu:

php70 -v PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php70/modules/intl.so' - libicui18n.so.67: cannot open shared object file: No such file or directory in Unknown on line 0 PHP 7.0.33 (cli) (built: Sep 3 2020 05:45:19) ( NTS )

Building also fails on both of my arch computers:

make: *** [Makefile:1135 : ext/intl/collator/collator_sort.lo] Erreur 1 ==> ERREUR : Une erreur s’est produite dans build().

I couldn't find a solution so far, but still looking

contreras.joseja commented on 2020-07-31 16:14 (UTC)

$ gpg --keyserver hkp://hkps.pool.sks-keyservers.net:80 --recv-keys 1A4E8B7277C42E53DBA9C7B9BCAA30EA9C0D5763 6E4F6AB321FDC07F2C332E3AC2BF0BC433CFC8B3

wget commented on 2019-09-15 14:49 (UTC)

@gchamon I haven't been able to reproduce the problem. Could you test on a fresh ArchLinux VM?

gchamon commented on 2019-05-08 13:54 (UTC)

problem with ICU v63 was with extensions installed with pecl. Uninstalling ICU63 and reinstalling extensions is also a viable solution.

The problem with the Test open_basedir configuration still persists, but looking at bug 52176 it is related with symbolic links. My .cache is stored offsite, in a secondary hard drive's partition, and the way it is being mounted might be causing issues, but I can't confirm without reverting .cache back to my ssd, I don't think it is worth the hassle. Any updates I can install by just disabling tests, I know it is unsafe, but if I was really concerned with safety I would either be using a container or wouldn't be using an outdated php version at all.

thanks

wget commented on 2019-04-28 22:33 (UTC)

@gchamon I updated the package. Could you please retry from your side? The freeetype bug should be solved. But the one with icu, I cannot reproduce. :-/

gchamon commented on 2019-04-08 15:22 (UTC)

icu updated to v.64 and broke php70 in general

solution is to install package icu63 until php70 adds icu63 as a dependency

gchamon commented on 2019-04-08 14:40 (UTC)

After recent system update, a test started failing

Test open_basedir configuration

Also cannot enable intl and mongodb drivers due to missing icu driver (cannot reproduce error right now because php70 refuses to install)

gchamon commented on 2019-02-11 12:19 (UTC)

@wget package installed successfully. Thanks for maintaing this! This is a recurrent conversation topic where I work, why oh why must there be a migration guide for upgrading php between minor versions. Anyway thanks!

wget commented on 2019-02-10 17:46 (UTC)

@gchamon @CaffeinatedTech Sorry for the delay. Actually I fixed the issue you reported the same week you reported the it to me, but forgot to push the fix. :D Done. Let me know if there are other issues.

CaffeinatedTech commented on 2019-02-01 08:06 (UTC)

Yep @gchamon I had to install sendmail to get mine to update also. Thank you. It'd be nice if it told you what failed at the end, because it scrolls for about four kilometers before failing.

gchamon commented on 2019-01-10 22:05 (UTC)

this extension recently updated to 7.0.33-2 and I couldn't update due to some undocumented error in check procedure. Analysing check in PKGBUILD, it only checked for sendmail and ran php tests. I found out then that sendmail was not installed in my system and installing it allowed me to update this package. Sendmail should, therefore, be a package dependency or at least the user should be warned that sendmail is not installed

wget commented on 2018-08-10 09:37 (UTC)

@TomaszGasior I don't know. I cannot reproduce the issue. The GPG keys are being imported fine from my side even on a brand new Arch Linux test machine. Maybe checking n the GPG documentation could help. Maybe this is related to dirmngr? https://wiki.archlinux.org/index.php/GnuPG#gpg_hanged_for_all_keyservers_.28when_trying_to_receive_keys.29

TomaszGasior commented on 2018-07-28 11:51 (UTC)

@wget When I try to import keys by your command, I have a different error: "gpg: keyserver receive failed: General error". What should I do?

wget commented on 2018-07-03 16:01 (UTC)

Thanks tunght13488! Package update with your fixes. And indeed this is working :) On my side I realized the compilation of this package was happening on one CPU core and tweaked a bit the PKGBUILD in order to improve it even further.

tunght13488 commented on 2018-06-18 03:04 (UTC) (edited on 2018-06-18 03:04 (UTC) by tunght13488)

I managed to get configure using pkg-config instead of freetype-config: https://github.com/tunght13488/aur-php70/commit/4a0db6535088bac262560aa7378092586da3b533

tunght13488 commented on 2018-06-18 02:23 (UTC) (edited on 2018-06-18 02:24 (UTC) by tunght13488)

I tried adding --with-freetype-dir=/usr \ after --with-enchant=shared,/usr \ but the build failed with freetype-config not found. Looks like freetype-config is no longer available in freetype2 and we should use something like pkg-config --cflags freetype2 instead of freetype-config --cflags. I'm still trying to figure out how to do that during the build.

tunght13488 commented on 2018-06-18 02:06 (UTC) (edited on 2018-06-18 02:25 (UTC) by tunght13488)

Looks like v7.0.30 removed freetype support. Function imageftbbox is no longer available

wget commented on 2018-06-13 15:41 (UTC)

Thanks el_aur for the patch! I appreciate it. It has been applied. Anything else I should replace/correct?

el_aur commented on 2018-06-07 13:14 (UTC) (edited on 2018-06-07 13:14 (UTC) by el_aur)

There's issue with -embed package can you add there instrtuction to PKGBUILD:

mv ${pkgdir}/usr/lib/libphp7.so ${pkgdir}/usr/lib/libphp-70.so

just after

make -j1 INSTALL_ROOT=${pkgdir} PHP_SAPI=embed install-sapi

/usr/lib/libphp7.so is already owned by php package from native repo

wget commented on 2018-05-14 14:00 (UTC)

@rdoursenaud I started to implement the fix, but even with my bunch of regex to force the rename (see related commented lines in PKGBUILD), the build process still produce libphp7.so. Any help would be appreciated.

wget commented on 2018-05-14 13:59 (UTC)

@betrixed No problem.

betrixed commented on 2018-05-13 12:56 (UTC) (edited on 2018-05-13 12:56 (UTC) by betrixed)

Thanks for taking over. I have lost interest in php 7.0, I was only updating versions. .29 PKGBUILD could be updated to .30 , edit VERSION, replace 2 sha512sums for new sources.

rdoursenaud commented on 2018-05-12 16:30 (UTC)

In package php70-embed, /usr/lib/libphp7.so conflicts with php-embed from extra. Please rename to libphp70.so.

wget commented on 2018-05-12 15:51 (UTC)

When upgrading from a previous version of this package I have noticed tools like yaourt were actually "boot"looping when compiling this package. I'm currently investigating.

wget commented on 2018-05-11 09:48 (UTC)

7.0.30 is on the way. Bringing support for sources check in the process. Keep you posted.

wget commented on 2018-04-24 22:41 (UTC) (edited on 2019-02-11 11:48 (UTC) by wget)

This package makes use of GPG keys for integrity verification. Here are the PGP keys you need to import (if you trust them):

$ gpg --recv-keys 1A4E8B7277C42E53DBA9C7B9BCAA30EA9C0D5763 6E4F6AB321FDC07F2C332E3AC2BF0BC433CFC8B3

Receiving GPG keys might fail with the following error message: $ gpg: keyserver receive failed: Connection refused. If this happens, just check your DNS or use other ones.

nicolas7 commented on 2018-04-15 08:22 (UTC)

checking for ENCHANT support... yes, shared configure: error: Cannot find enchant.

I cannot install enchant-pure because it conflicts with enchant.

How can I fix this ?

marce commented on 2018-04-12 08:00 (UTC)

checking for ENCHANT support... yes, shared configure: error: Cannot find enchant

yaourt -S enchant-pure

it's fixed for me

undu commented on 2018-04-11 08:22 (UTC) (edited on 2018-04-11 09:45 (UTC) by undu)

Configuration fails for me:

checking for ENCHANT support... yes, shared
configure: error: Cannot find enchant

Can this be a problem with the enchant package?

EDIT: just tried wget's pkgbuild, that one works fine. Thanks!

tunght13488 commented on 2018-04-05 03:21 (UTC)

thanks @wget

wget commented on 2018-04-04 16:10 (UTC)

I updated the package to the latest 7.0.29 on my repository -> https://github.com/wget/archlinux-aur-php70

For previous users, this update is mandatory. The package icu has been updated by Arch Linux which breaks your current PHP 7.0 install with the following error: PHP Startup: Unable to load dynamic library '/usr/lib/php70/modules/intl.so' - libicui18n.so.60: cannot open shared object file: No such file or directory in Unknown on line 0. This required file patching and recompilation in order to link to the right library version.

malina commented on 2018-03-30 12:48 (UTC)

wget, many thanks for php70 (7.0.28) pkgbuild repo - you saved me a lot of time

lilmike commented on 2018-03-12 08:28 (UTC)

Hi all, I've just created a php71 package that doesn't conflict with php 7.2 (or any other php version to my knowledge). It's called php71-noconflict (and php71-[...]-noconflict). Let me know if you have any feedback. Hope people find it useful! -Michael.

wget commented on 2018-03-09 10:51 (UTC)

Package upgraded to 7.0.28: https://github.com/wget/archlinux-aur-php70

ncoder-2 commented on 2018-02-06 15:17 (UTC)

This is broken without the patch by @wget.

wget commented on 2018-02-01 11:54 (UTC)

Hello everyone. Could someone merge this commit in this package? https://github.com/wget/archlinux-aur-php70/commit/13d6560cdb713e842de659d7e811678f51265a1b Otherwise, without this enchant 2 fix, php 7.0 cannot be built on Arch Linux. Thanks a lot :)

broiniac commented on 2018-01-18 11:14 (UTC) (edited on 2018-01-18 11:17 (UTC) by broiniac)

@Varakh: php7.1 for some reason is available in Community repo for 9 days now: https://www.archlinux.org/packages/community/x86_64/php71/ Unfortunately it is in conflict with regular (up-to-date) php (v7.2).

+1 though to your request - having nice, non conflicting 7.1 version would be nice.

I did tried to compile it by myself using same pkbuild as this package doing proper source and checksum changes, but I've failed. Epicly.

Varakh commented on 2018-01-09 09:11 (UTC)

@betrixed: Thanks for maintaining the package, very useful as PHP 7.2 breaks several old applications. Do you plan to provide a PHP 7.1 package aswell? This would be very nice. I already tried building it myself using old PKGBUILD files of the official repository, but I didn't get it running.

rio commented on 2017-12-25 06:56 (UTC)

I guess in all packages we should just have provides directives with ${pkgbase} replaced by ${_pkgbase} since no package should have dependencies on php70-foo anyway. Note that the current PKGBUILD already does this for php-cgi.

Raansu commented on 2017-12-23 08:34 (UTC)

Manually applying the fix mentioned by @teekay fixes the issue for me and Nextcloud installs without issue.

Raansu commented on 2017-12-23 07:30 (UTC) (edited on 2017-12-23 07:36 (UTC) by Raansu)

Even though I have this package installed I get an error trying to install Nextcloud, something needs to be fixed.

[kumo@kumo ~]$ sudo pacman -S nextcloud
resolving dependencies...
warning: cannot resolve "php-gd<7.2", a dependency of "nextcloud"
:: The following package cannot be upgraded due to unresolvable dependencies:
      nextcloud

teekay commented on 2017-12-11 13:22 (UTC)

I second @aexoxea's and @z3ntu's comments regarding provides for the split packages.

For example php70-gd with

provides=("${pkgbase}-gd=$pkgver" "${_pkgbase}-gd=$pkgver")

would make nextcloud-12.x happy (which requires php-gd<7.2)

z3ntu commented on 2017-12-11 09:06 (UTC) (edited on 2017-12-11 10:34 (UTC) by z3ntu)

I also get

php70-apache: /usr/lib/httpd/modules/libphp7.so exists in filesystem

and I would also appreciate proper "provides" for php- packages instead of just php70-

loumray commented on 2017-12-07 02:17 (UTC) (edited on 2017-12-07 02:17 (UTC) by loumray)

I get conflict with the arch package.

How about changing: install -D -m755 ${srcdir}/build-apache/libs/libphp7.so ${pkgdir}/usr/lib/httpd/modules/libphp7.so to install -D -m755 ${srcdir}/build-apache/libs/libphp7.so ${pkgdir}/usr/lib/httpd/modules/libphp70.so

Thanks!

aexoxea commented on 2017-09-30 12:26 (UTC)

Hi, I'd like to suggest that the modules with a "provides=("${pkgbase}-xxx=$pkgver")" parameter are changed to "provides=("${_pkgbase}-xxx=$pkgver")". Using php70-intl as an example (it's not the only one though): It currently provides "php70-intl=7.0.23", whereas with this change it would provide "php-intl=7.0.23", which would be much more useful. I note the module packages for php55 and php56 are already configured this way (e.g. their intl modules show "php-intl=5.5.38" and "php-intl=5.6.31"). It would be great if the php70 modules could be consistent with that. Thank you.

francoism90 commented on 2017-09-15 10:10 (UTC)

Could you change this install -D -m644 ${srcdir}/apache.conf ${pkgdir}/etc/httpd/conf/extra/php7_module.conf to install -D -m644 ${srcdir}/apache.conf ${pkgdir}/etc/httpd/conf/extra/php70_module.conf? Now it conflicts with the arch package. Thanks.

lilmike commented on 2017-09-02 19:20 (UTC)

Looks like the /etc/php70/php-fpm.d/www.conf isn't backed up on package upgrade, but probably should be. -Michael.

midgard commented on 2017-08-13 13:18 (UTC)

Hi, in PKGBUILD you should quote variables that may contain spaces, in particular ${srcdir}, ${pkgdir} and ${_build}. Otherwise the build may fail.

betrixed commented on 2017-07-25 02:27 (UTC)

I incorporated the corrections suggested earlier. Sorry not checking for them often enough. This package won't pass PGP check unless the first key in the validpgpkeys array for Anatol Belski <ab@php.net> is added to the local key-ring. See comment near validpgpkeys This command line works on my setup. gpg --recv-keys 1A4E8B7277C42E53DBA9C7B9BCAA30EA9C0D5763 I don't know how to make the package auto magically work for everybody, by having the package ensure the key is imported before the validity check. I think the validpgpkeys get checked before the call to prepare(), and therefore no way I can put key addition in the package. I also do not know how new pgp keys such as above, get proposed to put in the pacman key-ring, for use of AUR builds by makepkg.

enginefeeder101 commented on 2017-06-24 10:00 (UTC)

There is an error in PKGBUILD line 191. Due to the single quotes the php.ini file is NOT BACKED UP, your configuration will be LOST! --- PKGBUILD 2017-06-24 11:41:32.769813893 +0200 +++ PKGBUILD 2017-06-24 11:56:25.114753127 +0200 @@ -188,7 +188,7 @@ replaces=('php70-ldap') conflicts=('php70-ldap') provides=("${_pkgbase}=$pkgver") - backup=('etc/${pkgbase}/php.ini') + backup=("etc/${pkgbase}/php.ini") cd ${srcdir}/build make -j1 INSTALL_ROOT=${pkgdir} install-{modules,cli,build,headers,programs,pharcmd}

aeno commented on 2017-05-16 13:47 (UTC)

PKGBUILD line 271 should read: install -D -m644 ${srcdir}/php-fpm.tmpfiles ${pkgdir}/usr/lib/tmpfiles.d/${pkgbase}-fpm.conf currently, there's a /../ after the srcDir

rhssk commented on 2017-05-15 15:07 (UTC) (edited on 2017-05-15 15:07 (UTC) by rhssk)

backup=('etc/${pkgbase}/php.ini') (from quick glance this seems like the only problematic line) needs to be enclosed in double quotes instead of single as the pkgbase variable is parsed as plain string. The unintended result can be seen in pacman -Qii php70 backup line and results in a complete php.ini overwrite.

pipo1000 commented on 2017-05-11 07:37 (UTC)

I have installed the openssl-1.0 package like in the AUR php56 package. However a previous build php 7.0-17 with a installed openss-1.0 and openssl-1.1 lib bombs out with segmentation fault even on a php_info(). Without changes php70 does not build with 1.1 installed. I have tried the PKG_CONFIG_PATH and now it builds again but I did not try it yet as this server this business critical and I first have to setup a test server to make sure it does not fails with segmentation errors. At this time I have moved back to AUR/php56 which seems to run fine.

lilmike commented on 2017-05-02 13:53 (UTC)

When looking at the php56 package, which does detect openssl-1.0 correctly, I noticed before the ./configure etc steps: export PKG_CONFIG_PATH=/usr/lib/openssl-1.0/pkgconfig This (seems to have) done the trick. Perhaps this could be tested and incorporated into the package if it works? -Michael.

stef.an commented on 2017-04-27 14:37 (UTC)

openssl-1.0 installs in a way PHP doesn't detect. Here's my (dirty) way to compile it anyway: 1. install openssl-1.0 2. mkdir -p /opt/openssl-1.0/include 3. ln -s /usr/lib/openssl-1.0/ /opt/openssl-1.0/lib 4. ln -s /usr/include/openssl-1.0/openssl/ /opt/openssl-1.0/include/openssl 5. edit PKGBUILD, change --with-openssl to --with-openssl=/opt/openssl-1.0

VVL commented on 2017-04-25 14:59 (UTC)

After upgrading OpenSSL to 1.1.0 gives error: "configure: error: OpenSSL version >= 1.1 is not supported." even if openssl-1.0 installed. Cant find it at PKGBUILD to fix manually. On php.net seems php support openssl 1.1.0. What ways make it work? :)

eschwartz commented on 2017-04-20 08:49 (UTC) (edited on 2017-04-20 08:54 (UTC) by eschwartz)

After someone asked about this in the #archlinux IRC channel, I looked at this PKGBUILD, and you really need to add the validpgpkeys array back. I don't know why you thought it should be removed in the first place, because now everyone *definitely* has problems since makepkg tries to verify the PGP signature but doesn't recognize the key! ... gpg --verify warned you that the key has not been marked as a trusted key, but this is not actually problematic in any way, since makepkg and gpg are two entirely different things... see the wiki for more details: https://wiki.archlinux.org/index.php/PKGBUILD#validpgpkeys Particularly the part about "[makepkg] will ignore the trust values from the keyring".

cutgah commented on 2017-04-20 08:44 (UTC)

From the #archlinux IRC: The maintainer should put that array back where it came from [the validpgpkeys array] because the whole point of that array is to tell makepkg that the named key is trusted, but manually running gpg --verify does not have the same trust.

grawity commented on 2017-04-20 08:37 (UTC)

The point of validpgpkeys is that it bypasses the web of trust. It's telling makepkg that these keys are always trusted, and *only* these keys. So basically you're supposed to list in validpgpkeys the key fingerprints of all developers who sign those PHP tarballs.

betrixed commented on 2017-04-11 02:45 (UTC)

Response to tomaszgasior comment on 2017-04-08 19:06 Release 2 c-client dependency added. php extension LDAP is compiled into the PHP binary. I guess this was/is a flaw with the php56 PKGBUILD that I modified to make the php70 PKGBUILD. I have changed the name of the 'conflicts' and 'replaces' to php70-ldap, -even though its not created here, so this will remove the potential for conflict with the vanilla php package name php-ldap. I haven't investigated, I don't know the cost/benefit of having LDAP extension compiled into the binary. I don't know how big it is, how often it gets used, etc. As for PGP of php-7.0.17.tar.xz, I got a "Good Signature" but Warning, its not certified with a trusted signature! The pgpkey in the PKGBUILD array is the primary key 'fingerprint' of the owners key (Anatol Belski <ab@php.net>). I don't know which steps are needed for further automation into web of trust, or whether it is easier not to use this in the package and rely on that I trust the source. Since its giving a problem, I've removed the validpgpkeys for this release, at least until I understand how it should be properly used.

TomaszGasior commented on 2017-04-08 19:06 (UTC)

Please rename conflict package from php-ldap to php70-ldap or remove it from PKGBUILD. Currently because of it PHP 7.1 and this package cannot be installed in the same time. Also check PGP keys. Key of php-7.0.17.tar.xz is incorrect.

TomaszGasior commented on 2017-03-26 22:25 (UTC)

Is there any repository where I can find compiled older versions of PHP?

makikatze commented on 2017-02-07 16:38 (UTC)

This package needs the "c-client" package as a dependency, otherwise the configuration during build process will fail. Though I did not test if it's only needed for compilation (make) or for php to run, it's most probably needed for running, as the package "php-imap" from the Extra repository needs it for both, compiling and running. Furthermore, the check() function failed for me without installing something that provides "/usr/bin/sendmail" (I chose to install msmtp which works). Skipping the checks with makepkg's "--nocheck" option should also work, of course.