on Sat Jul 21 2007, till <klimpong-AT-gmail.com> wrote:
Not to rush you, but is anyone looking at these results? I went to considerable trouble to produce them, so a simple acknowledgement would make me feel better about having done it :)
Pong!
I can't provide you with an ETA on when I will look. Probably on the weekend. Maybe others will look earlier - or later.
Just checking in again, thanks...
Sorry, still have no ETA. I can try again next week but I am somewhat on vacation.
Sorry to pester, but how about now?
Hey David,
I just took a look at your files but I didn't find any answers for you.
However, I did notice you were running PHP/5.2.0 with Suhosin-Patch.
Is anyone else running that patch with 5.2.0? I'm curious if we could eliminate that as a potential point of interest.
Also, you may have mentioned this, but what version of firefox are you using? Have you tried other browsers to determine if it's the browser or the server causing the hang?
Matt
David Abrahams wrote:
on Sat Jul 21 2007, till <klimpong-AT-gmail.com> wrote:
>>>> Not to rush you, but is anyone looking at these results? I
went to
>>>> considerable trouble to produce them, so a simple
acknowledgement
>>>> would make me feel better about having done it :) >> Pong! >> >> I can't provide you with an ETA on when I will look. Probably
on the
>> weekend. Maybe others will look earlier - or later. Just checking in again, thanks...
Sorry, still have no ETA. I can try again next week but I am somewhat on vacation.
Sorry to pester, but how about now?
List info: http://lists.roundcube.net/dev/
Hi,
On 8/2/07, Matt Kaatman roundcube-dev@matt.kaatman.com wrote:
(...) However, I did notice you were running PHP/5.2.0 with Suhosin-Patch.
Is anyone else running that patch with 5.2.0? I'm curious if we could eliminate that as a potential point of interest.
I run Suhosin on all my installations. However, I've never run 5.2.0 - nor would. ;-) The current is 5.2.3. As far as I can remember 5.2.0 had too many issues to be used in production.
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
on Thu Aug 02 2007, till <klimpong-AT-gmail.com> wrote:
Hi,
On 8/2/07, Matt Kaatman roundcube-dev@matt.kaatman.com wrote:
(...) However, I did notice you were running PHP/5.2.0 with Suhosin-Patch.
Is anyone else running that patch with 5.2.0? I'm curious if we could eliminate that as a potential point of interest.
I run Suhosin on all my installations. However, I've never run 5.2.0 - nor would. ;-) The current is 5.2.3. As far as I can remember 5.2.0 had too many issues to be used in production.
My PHP is the one in my FreeBSD ports (I didn't even patch it explicitly), and despite the many "easy" guides to updating a FreeBSD system, I haven't been able to figure out how to actually do that safely.
My PHP is the one in my FreeBSD ports (I didn't even patch it explicitly), and despite the many "easy" guides to updating a FreeBSD system, I haven't been able to figure out how to actually do that safely.
Upgrade your ports with cvsup, then upgrade the specific packages you installed. Looks like php 5.2.3 is currently in /usr/ports/lang/php5/Makefile . Check the freebsd handbook for "cvsup"; you might also want to look at the package "portupgrade" (should be in your ports directory as well).
List info: http://lists.roundcube.net/dev/
Jason Fesler wrote:
My PHP is the one in my FreeBSD ports (I didn't even patch it explicitly), and despite the many "easy" guides to updating a FreeBSD system, I haven't been able to figure out how to actually do that safely.
Upgrade your ports with cvsup, then upgrade the specific packages you installed. Looks like php 5.2.3 is currently in /usr/ports/lang/php5/Makefile . Check the freebsd handbook for "cvsup"; you might also want to look at the package "portupgrade" (should be in your ports directory as well).
David,
Although this is a getting little off-topic for RoundCube development, it might help you and potentially others so here goes:
In FreeBSD 6.x and newer, "csup" (a c-based cvsup replacement) is included in the base system and you do not have to install anything extra to use it. Installing the cvsup client, especially via source, takes a while and brings in some hefty dependencies.
It may be as simple as running:
csup -h cvsup4.freebsd.org /usr/share/examples/cvsup/ports-supfile cd /usr/ports make fetchindex
You may want to sub another number for the cvsup server, 1-18 used to work but I think there are some gaps currently.
If you are still running FreeBSD 5.x, you'll have to use the cvsup client which may be installed as: pkg_add -r cvsup-without-gui or pkg_add -r cvsup Depending on whether or not you have (or want) the xorg/X11 libraries installed.
You can install the portupgrade port, as Jason mentioned and then update PHP as well as the extensions like so: portupgrade php5-*
While you're at it, you may want to update Apache, and some other programs. You can check to see which ports/packages are out of date with pkg_version -vL=
A couple caveats to this, however, from my experience:
- Look at /usr/ports/UPDATING after you csup/cvsup. Some things may bite
you when trying to update PHP, such as the recent autoconf update, or if you need the X11 libs, the xorg 7.2 conversion section may need to be done. There are plenty of detailed instructions in the UPDATING file for each action you need to perform.
Personally for the xorg upgrade I just put WITHOUT_X11=yes in /etc/make.conf and rebuilt php and others so they did not require X libraries, then removed the unneeded xorg ports/packages. This may not be feasible if you really do need things that rely on xorg libraries.
You may need to cd /usr/ports/lang/php5 make config
- Ensure APACHE is checked
Be aware of the order the extensions get installed. In some cases, the
extension order can cause Apache to die. See: http://www.pingle.org/2006/10/18/php-crashes-extensions/ And: http://www.pingle.org/2007/05/13/php-crashes-extensions-2/
This can be fixed by editing your php.ini after the upgrade is done and putting the modules in a better order.
- If you have cron jobs that use PHP scripts, such as cacti's poller, you
may want to disable them during the upgrade as the scripts may fail as parts get uninstalled and reinstalled. They may also fail because of the extension ordering mentioned above.
I maintain PHP installs on several servers, updating as needed, and the only thing that gets me on a regular basis is having to check and recheck the extension ordering. Often this is as easy as backing up my current /usr/local/etc/php/extensions.ini and then copying it back after portupgrade finishes.
In reality, it sounds a lot scarier than it is. Roundcube, as well as other apps, will probably be happier on a more up-to-date installation of PHP. Not to mention more secure.
Jim _______________________________________________ List info: http://lists.roundcube.net/dev/
On 8/2/07, Jim Pingle lists@pingle.org wrote:
(...) I maintain PHP installs on several servers, updating as needed, and the only thing that gets me on a regular basis is having to check and recheck the extension ordering. Often this is as easy as backing up my current /usr/local/etc/php/extensions.ini and then copying it back after portupgrade finishes.
This and the issues with extensions that actually need to be build static (e.g. PCRE, OpenSSL), but FreeBSD builds them all shared. The only obstacles I ran into in over five years of FreeBSD-happyness. ;-)
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
till wrote:
On 8/2/07, Jim Pingle lists@pingle.org wrote:
(...) I maintain PHP installs on several servers, updating as needed, and the only thing that gets me on a regular basis is having to check and recheck the extension ordering. Often this is as easy as backing up my current /usr/local/etc/php/extensions.ini and then copying it back after portupgrade finishes.
This and the issues with extensions that actually need to be build static (e.g. PCRE, OpenSSL), but FreeBSD builds them all shared. The only obstacles I ran into in over five years of FreeBSD-happyness. ;-)
I haven't hit that, but I thought there were some knobs that could be set in make.conf to accomplish that. I don't remember if CONFIGURE_ARGS gets carried over from the environment or not, if it does you can set the variables like I do below. You can always hack the Makefile, but that's not too elegant and it gets clobbered every time you update.
For example, here's what I do to get subversion and Apache2 to play nice, in /etc/make.conf:
.if ${.CURDIR:M*/www/apache22} WITH_BERKELEYDB=db42 .endif .if ${.CURDIR:M*/devel/subversion} WITH_APACHE2_APR=yes .endif .if ${.CURDIR:M*/devel/apr-svn} APR_UTIL_WITH_BERKELEY_DB=yes .endif
And I don't have to worry about setting those every time I do a port upgrade.
Jim _______________________________________________ List info: http://lists.roundcube.net/dev/
On 8/2/07, Jim Pingle lists@pingle.org wrote:
till wrote:
On 8/2/07, Jim Pingle lists@pingle.org wrote:
(...) I maintain PHP installs on several servers, updating as needed, and the only thing that gets me on a regular basis is having to check and recheck the extension ordering. Often this is as easy as backing up my current /usr/local/etc/php/extensions.ini and then copying it back after portupgrade finishes.
This and the issues with extensions that actually need to be build static (e.g. PCRE, OpenSSL), but FreeBSD builds them all shared. The only obstacles I ran into in over five years of FreeBSD-happyness. ;-)
I haven't hit that, but I thought there were some knobs that could be set in make.conf to accomplish that. I don't remember if CONFIGURE_ARGS gets carried over from the environment or not, if it does you can set the variables like I do below. You can always hack the Makefile, but that's not too elegant and it gets clobbered every time you update.
For example, here's what I do to get subversion and Apache2 to play nice, in /etc/make.conf:
.if ${.CURDIR:M*/www/apache22} WITH_BERKELEYDB=db42 .endif .if ${.CURDIR:M*/devel/subversion} WITH_APACHE2_APR=yes .endif .if ${.CURDIR:M*/devel/apr-svn} APR_UTIL_WITH_BERKELEY_DB=yes .endif
And I don't have to worry about setting those every time I do a port upgrade.
Even though this will go off-topic - but hey f' that! :D
Basically the issues with PCRE you can run into are pretty special - for example. You install PHP (PCRE is shared, as is any other extension), but then instead of using ports to install a pecl (0) extension, you think you can install it through "pecl install foo".
The pecl installer doesn't load installed extensions so they can be modified etc. (which makes a lot of sense) but since the installer expects PCRE to build static (included) it also relies/depends on it.
So what happens is, it "unloads" all extensions (including PCRE) and wants to use PCRE, and dies. Of course the work around is to use ports to install the PECL module as well - but yeah, we are all human and make mistakes. IMO this should be also fixed by the maintainer - I have not heard of a work around to include PCRE without hacking the Makefile, or maybe using CONFIGURE_ARGS.
I just don't like having to remember that to include it accross updates. That kind of defeats the purpose for me, but of course that is all doable. I could also roll my own port - not too hard, but yeah
- I actually just want to "consume". ;-)
I also have a patch for my pecl issue, but somehow I doubt they accept my "workaround".
The OpenSSL issues I found were related to some weird warning/failure PHP issues when I connected to a payment processors SSL endpoint. I was told on bugs.php.net that my install "sucks" because it's build shared and not static, when everyone in the world knows it has to be static. Well too bad. ;-)
I don't want to bash anyone, so I guess php should offer guidelines for the distributions and collaborate with maintainers on those issues. (In a perfect world.)
Cheers, Till
0, http://pecl.php.net _______________________________________________ List info: http://lists.roundcube.net/dev/
till wrote:
Even though this will go off-topic - but hey f' that! :D
Well getting PHP installed, running, and maintained is sort of relevant to developing and running RoundCube :)
[snip]
So what happens is, it "unloads" all extensions (including PCRE) and wants to use PCRE, and dies. Of course the work around is to use ports to install the PECL module as well - but yeah, we are all human and make mistakes.
Ahh... that must be why I haven't had this problem. I use ports for everything.
IMO this should be also fixed by the maintainer - I have not heard of a work around to include PCRE without hacking the Makefile, or maybe using CONFIGURE_ARGS.
It should probably do like perl and some others do, when CPAN or what-have-you installs a module, it does register it with the ports system. I did have trouble with some PEAR modules I installed by hand once that never got listed anywhere, but the modules I needed have since been added to the ports system so I had forgotten about that.
Ruby has a similar issue with gems. I know some gems, like those for rails, have their own ports but they often lag way behind and it's easier to use gem to keep them up to date on your own.
It would be nice to have a Makefile option or an alternate meta-port that would build with some or all extensions static. It might even be in progress. I'd check the ports mailing list archive and the GNATS system to see if someone has opened a PR about it.
I just don't like having to remember that to include it accross updates. That kind of defeats the purpose for me, but of course that is all doable. I could also roll my own port - not too hard, but yeah
- I actually just want to "consume". ;-)
Same here. It must just be luck that has let us get by with the minimal trouble we've had. "It Works For Me"(TM) -- most of the time. :)
I also have a patch for my pecl issue, but somehow I doubt they accept my "workaround".
Well it wouldn't hurt to mail it to the ports list or file a PR. The worst that can happen is it gets closed or ignored. If enough people chime in, the maintainer or a developer may take notice and propose a better fix or adopt yours.
The OpenSSL issues I found were related to some weird warning/failure PHP issues when I connected to a payment processors SSL endpoint. I was told on bugs.php.net that my install "sucks" because it's build shared and not static, when everyone in the world knows it has to be static. Well too bad. ;-)
We don't use SSL in PHP for anything mission-critical. (Our billing system runs in Perl.) In fact, I think the only place we use it is in RoundCube for the spell-checking functions if they're routed through Google. Again, probably luck that's spared us from that trouble...
I don't want to bash anyone, so I guess php should offer guidelines for the distributions and collaborate with maintainers on those issues. (In a perfect world.)
That would be nice. I'd love to see a mechanism for the ports system to respect the order of my extensions and how they load. I know others have the problem, they even linked to my writeup when talking about it on several different mailing list posts. I guess nobody has been able to come up with a workable solution yet (myself included...)
Jim
List info: http://lists.roundcube.net/dev/
-
David Abrahams -
Jason Fesler -
Jim Pingle -
Matt Kaatman -
till