Want to try out PHP5.next (PHP5.4?) on Ubuntu?
After the death of PHP6.0 a while ago, development of PHP.next (PHP5.4 probably?) has been going on.
There are a lot of cool features there try out - like traits, scalar type hint, and sh**loads of smaller features.
There is still no public "development preview" or alpha release, but that doesn't mean we can't play around with it, report bugs, ensuring our apps still properly work with it etc etc etc.
It is however a bit annoying needing to "go old-school" and fetch a snapshot and build it yourself though.
When I was playing with launchpad the other day I figured.. why not provide a daily build of PHP trunk/ (PHP.next, PHP5.4 or whatever you want to call it)?
Launchpad isn't all to happy with git, and doesn't support mirroring git branches, so a fork of the php5-vanilla-ubuntu repo to php5-next-vanilla-ubuntu was needed as some of the patches there don't apply to trunk/. But that was about it.
So, want to try out PHP5.4 daily builds? Checkout the PHP5.4-daily PPA on launchpad!
Play around with the new features, provide feedback to the PHP development mailinglist, and make sure your application if forward compatible with it today.
Thursday, April 28, 2011
Sunday, April 17, 2011
up2date PHP5.3 packages for Ubuntu
Most Linux distributions have a policy of not being to up to date with upstream releases of software, mostly for good reasons. This however is extremely painful for developers, as it means they often need to use really outdated version, containing all sorts of bugs - and even missing features.
This has been pissing me off for quite some time, so I have been running my own PHP builds for a while - but when it comes to deploying the apps... the sysadmins obviously start complaining that they have to invest a lot more work into maintaining the servers then they otherwise would have to.
So.. What can we do about that? Launchpad to the rescue!
Launchpad makes it really easy to provide your own custom packages, and even has a vast build farm to build packages automatically for different architectures and different Ubuntu releases. The only down side is it doesn't build rpm packages.. Thats fine by me, but that would be really useful for those wishing to deploy on a RedHat based distro.
After hunting down the debian PHP packaging repo, I forked it onto github (as php5-vanilla-ubuntu) and started ripping out some of their weird patches and enabled mysqlnd, but otherwise keeping their package splitting and the things you would expect from a debian package.
What does this mean?
- Well, if you are looking for up2date PHP packages (currently PHP5.3.6) to work with, checkout the PHP5.3 PPA on launchpad :)
This PPA works just fine as a drop-in-replacement for the default Ubuntu packages, and provides builds for Lucid and Maverick (there are some changes in Natty I need to look into..).
I have been running these packages for some time now, but if you notice any issues - please let me know :)
This has been pissing me off for quite some time, so I have been running my own PHP builds for a while - but when it comes to deploying the apps... the sysadmins obviously start complaining that they have to invest a lot more work into maintaining the servers then they otherwise would have to.
So.. What can we do about that? Launchpad to the rescue!
Launchpad makes it really easy to provide your own custom packages, and even has a vast build farm to build packages automatically for different architectures and different Ubuntu releases. The only down side is it doesn't build rpm packages.. Thats fine by me, but that would be really useful for those wishing to deploy on a RedHat based distro.
After hunting down the debian PHP packaging repo, I forked it onto github (as php5-vanilla-ubuntu) and started ripping out some of their weird patches and enabled mysqlnd, but otherwise keeping their package splitting and the things you would expect from a debian package.
What does this mean?
- Well, if you are looking for up2date PHP packages (currently PHP5.3.6) to work with, checkout the PHP5.3 PPA on launchpad :)
This PPA works just fine as a drop-in-replacement for the default Ubuntu packages, and provides builds for Lucid and Maverick (there are some changes in Natty I need to look into..).
I have been running these packages for some time now, but if you notice any issues - please let me know :)
Friday, December 24, 2010
The PHP project and Code Review
Reading code is not only fun, its also a great way to exercise your brain - not to mention a fantastic way to discover new ways to solve problems. At work (we are hiring btw!), for example, I read pretty much every single commit (and merge requests, for that matter) - and I'm subscribed to several different OSS commit lists. I can't say I read every commit to PHP, I focus on the areas I care about, but I do skim over the rest - if only just to see when new features are added.
The PHP project has a good chunk of mailinglists, everything from support lists, developer discussions, QA, and so on. Every commit to our SVN is automatically posted to the relevant commit mailinglist(s).
The main commit lists are;
- PHP (php-cvs@lists.php.net, http://news.php.net/php.cvs)
- PHP Documentation (doc-cvs@lists.php.net, http://news.php.net/php.doc.cvs)
- PHP-GTK (phpgtk-cvs@lists.php.net, http://news.php.net/php.gtk.cvs)
- PEAR (pear-cvs@lists.php.net, http://news.php.net/php.pear.cvs)
- PECL (pecl-cvs@lists.php.net, http://news.php.net/php.pecl.cvs)
Then we have specific lists for each translation of the docs, all the websites, PEAR docs and so on.
The great thing about these commit lists is that *anyone* can subscribe to them, and quite a lot of people actually are.
For example, there are over 200 people registered to the PHP commit list, and over 100 people on the documentation commit list alone. That is ca 25% of the people that are subscribed to their discussion counterparts.
Granted that most of the subscribers do not actively review the commits, I guesstimate there is still a sizable percentage of them that do.
Just the simple fact that I know people will be reading through my commits makes me think about what I am doing a bit more; "Is this really needed?", "Is there be a better way solving this?", "Could it potentially break other things?", "Is this actually correct?"..
The people who review the commits often don't seem like the friendliest people in the world.. If there are issues with the commit; You will be told. No doubt about it. And you will feel like an idiot, for few minutes, for not having caught it yourself - and promise yourself to review your commits better in the future. Learning from your mistakes. I love it. Mission accomplished.
Last year I updated the credit list, printed out by phpinfo() & phpcredits(), for the people maintaining our websites, with the commit message "Throw some credit around" (yes, the typo and incorrect colspan in the commit was caught and fixed).
Fast forward 15months, to last Friday. Another commit from me to PHP trunk with the commit message "Throw some credit around", and then to PHP 5.3 a minute later with the same commit message.
Less then 10minutes after the commit I had received 2 emails asking me "WTF?" - and a poke on IRC.
I had no idea what those guys were talking about. None what soever. I had not committed anything to any PHP project for several days. Nothing. Not even a typo fix.
Turns out that someone in Asia had somehow managed to get his/hers hands on my PHP.net account credentials.
Interestingly enough the commit doesn't introduce any security holes, bugs, or anything at all really. It just adds "Wolegequ Gelivable" to the credit list (whatever that means).
Its not a great feeling to have your account hacked into, but I do wonder what the intentions were.. Maybe just an credentials check, which was supposed to be followed by evil commits if noone had spotted the first one? The Chinese government trying to introduce security holes so they can break into PHP websites?
In any case. It took less then 10minutes for 3 people to catch it, that is pretty cool.
-Hannes
p.s. Last year, one of my new year's resolutions was to "blog once a month". My last blogpost was in January.
The PHP project has a good chunk of mailinglists, everything from support lists, developer discussions, QA, and so on. Every commit to our SVN is automatically posted to the relevant commit mailinglist(s).
The main commit lists are;
- PHP (php-cvs@lists.php.net, http://news.php.net/php.cvs)
- PHP Documentation (doc-cvs@lists.php.net, http://news.php.net/php.doc.cvs)
- PHP-GTK (phpgtk-cvs@lists.php.net, http://news.php.net/php.gtk.cvs)
- PEAR (pear-cvs@lists.php.net, http://news.php.net/php.pear.cvs)
- PECL (pecl-cvs@lists.php.net, http://news.php.net/php.pecl.cvs)
Then we have specific lists for each translation of the docs, all the websites, PEAR docs and so on.
The great thing about these commit lists is that *anyone* can subscribe to them, and quite a lot of people actually are.
For example, there are over 200 people registered to the PHP commit list, and over 100 people on the documentation commit list alone. That is ca 25% of the people that are subscribed to their discussion counterparts.
Granted that most of the subscribers do not actively review the commits, I guesstimate there is still a sizable percentage of them that do.
Just the simple fact that I know people will be reading through my commits makes me think about what I am doing a bit more; "Is this really needed?", "Is there be a better way solving this?", "Could it potentially break other things?", "Is this actually correct?"..
The people who review the commits often don't seem like the friendliest people in the world.. If there are issues with the commit; You will be told. No doubt about it. And you will feel like an idiot, for few minutes, for not having caught it yourself - and promise yourself to review your commits better in the future. Learning from your mistakes. I love it. Mission accomplished.
Last year I updated the credit list, printed out by phpinfo() & phpcredits(), for the people maintaining our websites, with the commit message "Throw some credit around" (yes, the typo and incorrect colspan in the commit was caught and fixed).
Fast forward 15months, to last Friday. Another commit from me to PHP trunk with the commit message "Throw some credit around", and then to PHP 5.3 a minute later with the same commit message.
Less then 10minutes after the commit I had received 2 emails asking me "WTF?" - and a poke on IRC.
I had no idea what those guys were talking about. None what soever. I had not committed anything to any PHP project for several days. Nothing. Not even a typo fix.
Turns out that someone in Asia had somehow managed to get his/hers hands on my PHP.net account credentials.
Interestingly enough the commit doesn't introduce any security holes, bugs, or anything at all really. It just adds "Wolegequ Gelivable" to the credit list (whatever that means).
Its not a great feeling to have your account hacked into, but I do wonder what the intentions were.. Maybe just an credentials check, which was supposed to be followed by evil commits if noone had spotted the first one? The Chinese government trying to introduce security holes so they can break into PHP websites?
In any case. It took less then 10minutes for 3 people to catch it, that is pretty cool.
-Hannes
p.s. Last year, one of my new year's resolutions was to "blog once a month". My last blogpost was in January.
Subscribe to:
Posts (Atom)