This blocks the migration out of NFS - bug 36646. The reason being that we will then want to use the regular production tools (such as scap) and definitely need to lint PHP files before copying them to Apaches.

Workaround:
I have installed php-dev and ran pecl install parsekit on deployment-dbdump.

The following extra packages will be installed:

autoconf automake autotools-dev libltdl-dev libssl-dev libssl0.9.8 libtool
m4 shtool

Then :
You should add "extension=parsekit.so" to php.ini

Did that in /etc/php5/conf.d/parsekit.ini and leaved a comment there.

Do we know if parsekit works reliably on 5.3+ yet?

I had *quite* a few issues with false positives awhile back and had to give up using it locally.

Could you clarify if you need it for lucid, precise or both?

(In reply to comment #3)

Do we know if parsekit works reliably on 5.3+ yet?

I had *quite* a few issues with false positives awhile back and had to give up
using it locally.

We are using parsekit on fenari as part of the scap script (which call lint which is :

php -n -dextension=parsekit.so dirname $0/lint.php "$@"

So yeah, works for us ;-D

(In reply to comment #4)

Could you clarify if you need it for lucid, precise or both?

Would need it for lucid for now so we can clean out the hack on fenari and use it on dbdump (beta bastion).

We could use a file /etc/php5/conf.d/parsekit.ini containing :
extension=parsekit.so

Since php5-parsekit will only be installed on bastion, it is not going to do any harm to Apaches.

(In reply to comment #5)

(In reply to comment #3)

Do we know if parsekit works reliably on 5.3+ yet?

I had *quite* a few issues with false positives awhile back and had to give up
using it locally.

We are using parsekit on fenari as part of the scap script (which call lint
which is :

php -n -dextension=parsekit.so dirname $0/lint.php "$@"

So yeah, works for us ;-D

Run checkSyntax.php over the entire codebase with no errors, then I'll feel better :)

(In reply to comment #7)

Run checkSyntax.php over the entire codebase with no errors, then I'll feel
better :)

We will use CodeSniffer instead ;-]

Marking as an operation bug.

Package php5-parsekit is on our apt repo, you should be able to (make puppet) apt-get it. Let me know if you need anything else with that.

Thanks Faidon. I have tested the package on 'beta'.

Change for puppet is in https://gerrit.wikimedia.org/r/13048. Will follow up there.

(In reply to comment #10)

Package php5-parsekit is on our apt repo, you should be able to (make puppet)
apt-get it. Let me know if you need anything else with that.

Any chance of it being upstreamed? Thanks :D

(In reply to comment #12)

Any chance of it being upstreamed? Thanks :D

Will need too fill out a request for a new Debian Package. Feel free to open a bug there and make sure you CC: Faidon, he definitely has clue about how we could do it (even if someone else will end up doing the paper work).

I think Sam meant that *I* should upload it to Debian and maintain it there :-) I have no problem doing so (as I have no problem sponsoring/mentoring other people to do that), but it's obviously on my low-priority list.

on integration slaves in labs it is attempted to install this package but it fails:

Error: /Stage[main]/Contint::Packages/Package[php5-parsekit]/ensure: change from purged to present failed: Execution of '/usr/bin/apt-get -q -y -o DPkg::Options::=--force-confold install php5-parsekit' returned 100: Reading package lists...
Building dependency tree...
Reading state information...
E: Unable to locate package php5-parsekit

@integration-slave1006-trusty eqiad.wmflabs

See bug 68256 comment 5. The php jobs currently don't run on the trusty slaves so it missing will not cause immediate problems, and puppet fortunately continues applying the remainder of the manifest.