Hello,

Today I am pleased to announce a new php5-fpm TESTING package for
ubuntu. Its a candidate for an official debian package.

Instructions and guide available at:
http://dreamcat4.jottit.com/new_php5-fpm_testing_candidate


So anyone want to try it out?

This is a TESTING package. So some TESTING / verification would be a
great help on;
- Operation with sqlite, mysql and pgsql databases
- Check inter-operability with apache2 webserver
- Look for and possible conflicts against existing php variants, or
apache installation.
(dpkg --contents <php5-fpm.deb> to list files)
- Needs a short, concise man page. Anybody good at writing man pages?


(1) Known Issues:
Php extensions aren't loaded by the php-fpm binary. This may prove to
be somewhat limiting in a production environment.

dreamcat4@ubuntu910server:/usr/local/src/play/php-fpm$ sudo
/etc/init.d/php5-fpm start
Starting php_fpm Failed loading /usr/lib/php5/20060613+lfs/xcache.so:
/usr/lib/php5/20060613+lfs/xcache.so: undefined symbol:
function_add_ref
PHP Warning: PHP Startup: Unable to load dynamic library
'/usr/lib/php5/20060613+lfs/pdo.so' -
/usr/lib/php5/20060613+lfs/pdo.so: undefined symbol:
zend_objects_store_add_ref in Unknown on line 0
done

I'm not exactly sure the reason for this. Its the fpm binary.
Something may be missing during the link stage. Hopefully the issue
can be fixed in the fpm source code, and someone can provide update.
We'll have to see.


Best regards,
dreamcat4

This is based off the new PHP-FPM (from launchpad/the non-patch version) right?


On Thu, Aug 20, 2009 at 1:35 PM, dreamcat four<dreamcat4@gmail.com> wrote:
>
> Hello,
>
> Today I am pleased to announce a new php5-fpm TESTING package for
> ubuntu. Its a candidate for an official debian package.
>
> Instructions and guide available at:
> http://dreamcat4.jottit.com/new_php5-fpm_testing_candidate
>
>
> So anyone want to try it out?
>
> This is a TESTING package. So some TESTING / verification would be a
> great help on;
>  - Operation with sqlite, mysql and pgsql databases
>  - Check inter-operability with apache2 webserver
>  - Look for and possible conflicts against existing php variants, or
> apache installation.
>   (dpkg --contents <php5-fpm.deb> to list files)
>  - Needs a short, concise man page. Anybody good at writing man pages?
>
>
> (1) Known Issues:
> Php extensions aren't loaded by the php-fpm binary. This may prove to
> be somewhat limiting in a production environment.
>
>        dreamcat4@ubuntu910server:/usr/local/src/play/php-fpm$ sudo
> /etc/init.d/php5-fpm start
>        Starting php_fpm Failed loading /usr/lib/php5/20060613+lfs/xcache.so:
>  /usr/lib/php5/20060613+lfs/xcache.so: undefined symbol:
> function_add_ref
>        PHP Warning:  PHP Startup: Unable to load dynamic library
> '/usr/lib/php5/20060613+lfs/pdo.so' -
> /usr/lib/php5/20060613+lfs/pdo.so: undefined symbol:
> zend_objects_store_add_ref in Unknown on line 0
>         done
>
> I'm not exactly sure the reason for this. Its the fpm binary.
> Something may be missing during the link stage. Hopefully the issue
> can be fixed in the fpm source code, and someone can provide update.
> We'll have to see.
>
>
> Best regards,
> dreamcat4
>

On Thu, Aug 20, 2009 at 10:18 PM, Michael Shadle<mike503@gmail.com> wrote:
>
> This is based off the new PHP-FPM (from launchpad/the non-patch version) right?

Yes. It may seem confusing, but after editing the sources, we still
must convert it to a patch for the Debian people. There's a shell
script in my launchpad branch ('generate-fpm-patch') that creates the
"fpm.patch" file.

Download the source tree, and use a directory diff tool like Meld or
Beyond Compare 2. Its not really possible to see on the web-portal
because of all those autogenerated files.


dreamcat4
dreamcat4@gmail.com

Ideally this should be able to be packaged as a standalone debian type
package, not a patch necessarily. just like php5-mysql and other php
modules.

On Thu, Aug 20, 2009 at 3:18 PM, dreamcat four<dreamcat4@gmail.com> wrote:
>
> On Thu, Aug 20, 2009 at 10:18 PM, Michael Shadle<mike503@gmail.com> wrote:
>>
>> This is based off the new PHP-FPM (from launchpad/the non-patch version) right?
>
> Yes. It may seem confusing, but after editing the sources, we still
> must convert it to a patch for the Debian people. There's a shell
> script in my launchpad branch ('generate-fpm-patch') that creates the
> "fpm.patch" file.
>
> Download the source tree, and use a directory diff tool like Meld or
> Beyond Compare 2. Its not really possible to see on the web-portal
> because of all those autogenerated files.
>
>
> dreamcat4
> dreamcat4@gmail.com
>

On Thu, Aug 20, 2009 at 11:24 PM, Michael Shadle<mike503@gmail.com> wrote:
>
> Ideally this should be able to be packaged as a standalone debian type
> package, not a patch necessarily. just like php5-mysql and other php
> modules.

Assuming that you mean an standalone orig.tar.gz *source* package here
(as opposed binary package which is what a regular user would
install).

Hmm...
There appear to be a similar number common and/or separated source
packages for php5. I've been listening for more news on this and but
have yet to hear ways for how things could be better that way. Perhaps
i'm slightly biased (am i?). It's certainly a possibility however my
own investigation of this had found that route requires a considerable
amount of additional work + maintenance overhead. So without any clear
benefits to go with that, i was unable to justify the expenditure to
myself in terms of developer time.


Here's 4 good reasons not to:

1) You will loose everything in $(WEB_CONFIG).

2) You'll have to stay on top of the security updates. The Debian
maintainers of PHP5 do a really great service by worrying about these
security updates for us and it would be a shame to loose that. (not to
mention that you won't actually be approved without providing those).

3) Conversely, by remaining within official php5 source package (+our
separate source tree), we have official people automatically fixing
all the ubuntu and php - related build problems for us. Isn't that
just like heaven or something? So from a maintainability standpoint -
it's really hard to see much benefit unless you have a faster
iteration release cycle than php (which FPM project doesn't).

4) That's not to say we don't still maintain our own source code, and
have complete independence in our FPM project. A source package is
simply that - it is only a package and not the contents. We really
should want to be productively focussed on the contents of the package
and not the parcel it comes in.


OTOH - a good thing for giving choices to Ubuntu and better
accommodate their packaging needs. We can consult both MOTU and
ubuntu-main-developers before deciding anything. Yet another
possibility might be to put fpm in php5-common's orig.tar.gz file.
Meaning no patch and presumably some alternative vcs-delivery method
instead. If we don't know what to do - we start a conversation on IRC
or Launchpad.

That's just meant to be an example - question i.e. how through
consultation we can help make an informed choice here. Personally i'm
not interested to be involved at that level. Indeed why stretch /
over-reach our abilities to go even further by making the source
package seperate? Is it an ubuntu way? What are the true benefits? Im
certainly curious to see how it will all eventually pan out. Worst
case is we get something i cannot use in production because it's not
got library X,Y,Z (wheras apache2module does). I hope people at least
look at the common, even if its a separate, and copy the good bits
over or something.


Best regards,

dreamcat4
dreamcat4@gmail.com

Well when Andrei had created this new FPM, it only had two
dependencies - the slightly modified libevent and a vanilla PHP that
had been ./compiled and make'd without any switches needed.

In theory your bug with extensions not loading shouldn't have anything
to do with FPM as PHP is compiled with its own flags and FPM just
interacts with it (of course, that doesn't seem to be the case if you
launch it normally just fine but under FPM it doesnt work)

I FPM as being something that can be an enhancement to PHP and tying
it in to their source code limits how fast we can move. I don't know
how packaging is done though.

On Thu, Aug 20, 2009 at 6:44 PM, dreamcat four<dreamcat4@gmail.com> wrote:
>
> On Thu, Aug 20, 2009 at 11:24 PM, Michael Shadle<mike503@gmail.com> wrote:
>>
>> Ideally this should be able to be packaged as a standalone debian type
>> package, not a patch necessarily. just like php5-mysql and other php
>> modules.
>
> Assuming that you mean an standalone orig.tar.gz *source* package here
> (as opposed binary package which is what a regular user would
> install).
>
> Hmm...
> There appear to be a similar number common and/or separated source
> packages for php5. I've been listening for more news on this and but
> have yet to hear ways for how things could be better that way. Perhaps
> i'm slightly biased (am i?). It's certainly a possibility however my
> own investigation of this had found that route requires a considerable
> amount of additional work + maintenance overhead. So without any clear
> benefits to go with that, i was unable to justify the expenditure to
> myself in terms of developer time.
>
>
> Here's 4 good reasons not to:
>
> 1) You will loose everything in $(WEB_CONFIG).
>
> 2) You'll have to stay on top of the security updates. The Debian
> maintainers of PHP5 do a really great service by worrying about these
> security updates for us and it would be a shame to loose that. (not to
> mention that you won't actually be approved without providing those).
>
> 3) Conversely, by remaining within official php5 source package (+our
> separate source tree), we have official people automatically fixing
> all the ubuntu and php - related build problems for us. Isn't that
> just like heaven or something? So from a maintainability standpoint -
> it's really hard to see much benefit unless you have a faster
> iteration release cycle than php (which FPM project doesn't).
>
> 4) That's not to say we don't still maintain our own source code, and
> have complete independence in our FPM project. A source package is
> simply that - it is only a package and not the contents. We really
> should want to be productively focussed on the contents of the package
> and not the parcel it comes in.
>
>
> OTOH - a good thing for giving choices to Ubuntu and better
> accommodate their packaging needs. We can consult both MOTU and
> ubuntu-main-developers before deciding anything. Yet another
> possibility might be to put fpm in php5-common's orig.tar.gz file.
> Meaning no patch and presumably some alternative vcs-delivery method
> instead. If we don't know what to do - we start a conversation on IRC
> or Launchpad.
>
> That's just meant to be an example - question i.e. how through
> consultation we can help make an informed choice here. Personally i'm
> not interested to be involved at that level. Indeed why stretch /
> over-reach our abilities to go even further by making the source
> package seperate? Is it an ubuntu way? What are the true benefits? Im
> certainly curious to see how it will all eventually pan out. Worst
> case is we get something i cannot use in production because it's not
> got library X,Y,Z (wheras apache2module does). I hope people at least
> look at the common, even if its a separate, and copy the good bits
> over or something.
>
>
> Best regards,
>
> dreamcat4
> dreamcat4@gmail.com
>

On Fri, Aug 21, 2009 at 8:14 AM, Michael Shadle<mike503@gmail.com> wrote:
> I FPM as being something that can be an enhancement to PHP and tying
> it in to their source code limits how fast we can move. I don't know
> how packaging is done though.

In terms of recent work, there's absolutely nothing been happening to
affect the relationship between PHP and FPM source code. Meaning - to
impinge on the choices to develop FPM in its new more separate /
standalone / isolated manner. I kindda feel guilty for pushing these
big FPM commits upstream to you Mike, and specifically having the
changes marked out as 'only' for recent Ubuntu packaging efforts.

The truth is it's more about general improvements for improving the
FPM configure script. There's bags of autoconf macro fixes in there
which aren't related to any particular packaging scheme. And i think
probably only Andrei would be able to approve those ones. The
buildconf improvements again are really something for Andrei's
decision also. Finally there's a bit of new documentation, however
probably better to do *after* the code because it has references to
FPM's configuation flags and switches.

If Andrei takes an interest then i'd be happy to come back and explain
the changes a bit further.



Best regards,

dreamcat4
dreamcat4@gmail.com