FS#47200 - [php-composer] fails to run (1.0.0.alpha11-1)

Attached to Project: Arch Linux
Opened by Bosco Witch (boscowitch) - Friday, 27 November 2015, 11:05 GMT
Last edited by Pierre Schmitz (Pierre) - Tuesday, 29 December 2015, 12:08 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Pierre Schmitz (Pierre)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:
php-composer fails in newest version

composer
PHP Fatal error: Class 'Phar' not found in /usr/bin/composer on line 23

downgrading to 2 versions and it worked again

Additional info:
* package version(s):
not working: php-composer-1.0.0.alpha11-1-any.pkg.tar.xz
last working:php-composer-1.0.0.alpha10.465-1-any.pkg.tar.xz


Steps to reproduce:
update/install php-composer
try to run composer command
This task depends upon

Closed by  Pierre Schmitz (Pierre)
Tuesday, 29 December 2015, 12:08 GMT
Reason for closing:  Fixed
Comment by Pierre Schmitz (Pierre) - Saturday, 28 November 2015, 08:12 GMT
You need to enable phar.so in your php.ini.
Comment by Bosco Witch (boscowitch) - Saturday, 28 November 2015, 10:06 GMT
ah i could have thought about that... can we add a notice for pacman after install?

But unfortunately there is more now:

PHP Warning: Phar::mapPhar(): open_basedir restriction in effect. File(/usr/bin/composer) is not within the allowed path(s): (/usr/bin/php:/srv/http/:/home/:/tmp/:/usr/share/pear/:/usr/share/webapps/) in /usr/bin/composer on line 23
PHP Warning: require(phar://composer.phar/bin/composer): failed to open stream: phar error: invalid url or non-existent phar "phar://composer.phar/bin/composer" in /usr/bin/composer on line 24
PHP Fatal error: require(): Failed opening required 'phar://composer.phar/bin/composer' (include_path='.:/usr/share/pear') in /usr/bin/composer on line 24


seems like one also has to add "/usr/bin/composer" to the open_basedir (had this problem before with php executable ...)
guess it will become a longer notice ...
BTW: now it seems to run testet composer install with one production project
Comment by muhas (muhas) - Sunday, 29 November 2015, 09:30 GMT
add /usr/bin/ to open_basedir and composer work fine
Comment by Bosco Witch (boscowitch) - Sunday, 29 November 2015, 11:33 GMT
well of course one can add every binary, question is will this change be made from the package or will does it need to happen manually (with a notice after install)
Comment by niels abspoel (aboe) - Sunday, 06 December 2015, 15:16 GMT
@boscowitch and @Pierre

My solution was to copy /etc/php/php.ini to /etc/php/php-cli.ini, and empty the basedir variable.

This way php from command line will use /etc/php/php-cli.ini without restriction, but let me keep my /etc/php/php.ini with basedir for php-fpm or apache.

Is this a solution for you?
Comment by Pierre Schmitz (Pierre) - Sunday, 06 December 2015, 16:47 GMT
On a side not, the package I am prepareing for PHP 7 have no basedir setting and also include phar by default.
Comment by niels abspoel (aboe) - Sunday, 06 December 2015, 20:12 GMT
@Piere, you could split it, I'm testing this on my virtual arch server,
create a /etc/php/php.ini with the sane defauls and basedir restrictions, to used as default by apache or php-fpm
and create a /etc/php/php-cli.ini just for the cli tasks, like drush composer etc. this way the drush / composer packaged don't need to change,
because they will use /etc/php/php-cli.ini instead of the default.

Comment by Adam Brodziak (adambro) - Tuesday, 29 December 2015, 11:52 GMT
I've had the same issue, adding /usr/bin to open_basedir in php.ini solved the problem.

How about setting open_basedir to make it work with composer by default?
Comment by Pierre Schmitz (Pierre) - Tuesday, 29 December 2015, 12:08 GMT
As I said, open_basedir is no longer set with PHP 7.

Loading...