On Thu, 2009-03-12 at 12:54 +0100, Paulo Martinez wrote:
- Sorry for double posting. The Archive was not including my post. -
- For the sake of them, which only read through the archive. -
I *think* there's a small delay (I don't know how much) for things to get moved to the archive. In the past I noticed that stuff I posted was not available right away, but was a few days later when I checked again. <snip>
William L. Maltby wrote:
On Thu, 2009-03-12 at 12:54 +0100, Paulo Martinez wrote:
- Sorry for double posting. The Archive was not including my post. -
- For the sake of them, which only read through the archive. -
I *think* there's a small delay (I don't know how much) for things to get moved to the archive. In the past I noticed that stuff I posted was not available right away, but was a few days later when I checked again.
Normally the archive gets mails first - or at least at the same time as the first mails are going out to the users.
That's why I check the archive if a mail doesn't come back to me, just to see if some mail server in the path has hiccups.
Ralph
Am 12.03.2009 um 14:25 schrieb William L. Maltby:
On Thu, 2009-03-12 at 12:54 +0100, Paulo Martinez wrote:
- Sorry for double posting. The Archive was not including my post. -
- For the sake of them, which only read through the archive. -
I *think* there's a small delay (I don't know how much) for things to get moved to the archive. In the past I noticed that stuff I posted was not available right away, but was a few days later when I checked again.
My fault, i use X-No-Archive as additional header. Even setting to "X-No-Archive = No" prevent the archiving.
Regards
P.M.
Hi Devel,
just to communicate. php from c5-testing is working so far:
rpm -qa |grep php php-soap-5.2.6-2.el5s2 php-gd-5.2.6-2.el5s2 php-ldap-5.2.6-2.el5s2 php-common-5.2.6-2.el5s2 php-cli-5.2.6-2.el5s2 php-bcmath-5.2.6-2.el5s2 php-5.2.6-2.el5s2 php-xml-5.2.6-2.el5s2 php-mbstring-5.2.6-2.el5s2 php-pear-Auth-SASL-1.0.2-4.el5.centos php-imap-5.2.6-2.el5s2 php-pear-1.4.9-4.el5.1 php-pdo-5.2.6-2.el5s2 php-dba-5.2.6-2.el5s2 php-mysql-5.2.6-2.el5s2 php-xmlrpc-5.2.6-2.el5s2
At time of installation with:
yum --enablerepo=c5-testing update php
There were no dependencies errors from php packages of extras repo like php-mcrypt but they should because the of the changed AP-Interface for php-modules. Anyway, the installation/upgrade runs flawless.
In my environment there were following packages of extras repo
php-mcrypt php-mhash php-pecl-Fileinfo
Deleting this php-modules resolves this (issue of starting httpd):
PHP Warning: PHP Startup: fileinfo: Unable to initialize module \nModule compiled with module API=20050922, debug=0, thread-safety=0\nPHP compiled with module API=20060613, debug=0, thread-safety=0\nThese options need to match\n in Unknown on line 0 PHP Warning: PHP Startup: mcrypt: Unable to initialize module \nModule compiled with module API=20050922, debug=0, thread-safety=0\nPHP compiled with module API=20060613, debug=0, thread-safety=0\nThese options need to match\n in Unknown on line 0 PHP Warning: PHP Startup: mhash: Unable to initialize module\nModule compiled with module API=20050922, debug=0, thread-safety=0\nPHP compiled with module API=20060613, debug=0, thread-safety=0\nThese options need to match\n in Unknown on line 0
I am sure all extra-repo packages
php-* php-pecl*
have to be touched to run also with centosplus candidate php 5.2.x
i had php-eaccelerator installed and now removed. I will recompile it in the next days. I wonder, CentOSPlus/CentOSWebStack for Centos 4 have php-eaccelerator. What do you think about a package for Centos 5?
For now - thank you.
Best Regards
P.M.
Paulo Martinez a écrit :
php-mcrypt php-mhash php-pecl-Fileinfo
Deleting this php-modules resolves this (issue of starting httpd):
PHP Warning: PHP Startup: fileinfo: Unable to initialize module \nModule compiled with module API=20050922, debug=0, thread-safety=0\nPHP compiled with module API=20060613, debug=0, thread-safety=0\nThese options need to match\n in Unknown on line 0 PHP Warning: PHP Startup: mcrypt: Unable to initialize module \nModule compiled with module API=20050922, debug=0, thread-safety=0\nPHP compiled with module API=20060613, debug=0, thread-safety=0\nThese options need to match\n in Unknown on line 0 PHP Warning: PHP Startup: mhash: Unable to initialize module\nModule compiled with module API=20050922, debug=0, thread-safety=0\nPHP compiled with module API=20060613, debug=0, thread-safety=0\nThese options need to match\n in Unknown on line 0
This should be detect before installation, not on apache start...
That's why Fedora 5.2.x php package provides the new php(zend-abi) = 20060613
Which should be required by all pecl extension /etc/rpm/macros.php (in php-devel) provides usefull macros for this.
I am sure all extra-repo packages
php-* php-pecl*
have to be touched to run also with centosplus candidate php 5.2.x
Note only touch, but probably adapted to also require php(zend-abi), to avoid installation with incompatible php version.
And some others stuff, like rrdtool-php (and syck-php, graphviz-php, uuid-php but not available on CentOS, I think)
Regards
+
Am 12.03.2009 um 19:46 schrieb Remi Collet:
PHP Warning: PHP Startup: mhash: Unable to initialize module\nModule compiled with module API=20050922, debug=0, thread-safety=0\nPHP compiled with module API=20060613, debug=0, thread-safety=0\nThese options need to match\n in Unknown on line 0
This should be detect before installation, not on apache start...
That's why Fedora 5.2.x php package provides the new php(zend-abi) = 20060613
Which should be required by all pecl extension /etc/rpm/macros.php (in php-devel) provides usefull macros for this.
It should be enough to specify Require/Provides-tags. As done in php-5.2.6-2.el5s2.src.rpm and php-mcrypt (src: php-extras) via
%define apiver xxxxxxx
php-5.2.6-2.el5s2.src.rpm defines apiver 20041225. And here comes my question: It defines this ^^ ?
rpm -q php-common-5.2.6-2.el5s2 --provides | grep api php(api) = 20041225 php-api = 20041225
so far on rpms site. But
php -i | grep -P 'PHP API|PHP Version' PHP Version => 5.2.6 PHP API => 20041225
contrary to above log errors (API=20060613).
Anyway, it explains why ex. php-mcrypt did't bleated at installation time about different APIs - it was satisfied.
php-mcrypt (src: php-extras) define apiver on compile time
%global apiver %((echo 0; php -i 2>/dev/null | sed -n 's/^PHP API => //p') | tail -1)
Besides of php packages in extras repos. Is the apiver-definition in php-5.2.6-2.el5s2 correct?
P.M.
Am 12.03.2009 um 21:13 schrieb Paulo Martinez:
Am 12.03.2009 um 19:46 schrieb Remi Collet:
PHP Warning: PHP Startup: mhash: Unable to initialize module \nModule compiled with module API=20050922, debug=0, thread-safety=0\nPHP compiled with module API=20060613, debug=0, thread-safety=0\nThese options need to match\n in Unknown on line 0
This should be detect before installation, not on apache start...
That's why Fedora 5.2.x php package provides the new php(zend-abi) = 20060613
Which should be required by all pecl extension /etc/rpm/macros.php (in php-devel) provides usefull macros for this.
It should be enough to specify Require/Provides-tags. As done in php-5.2.6-2.el5s2.src.rpm and php-mcrypt (src: php-extras) via
%define apiver xxxxxxx
php-5.2.6-2.el5s2.src.rpm defines apiver 20041225. And here comes my question: It defines this ^^ ?
rpm -q php-common-5.2.6-2.el5s2 --provides | grep api php(api) = 20041225 php-api = 20041225
so far on rpms site. But
php -i | grep -P 'PHP API|PHP Version' PHP Version => 5.2.6 PHP API => 20041225
Paulo you fool:
php -i | grep -P 'PHP E|PHP Version' PHP Version => 5.2.6 PHP Extension => 20060613
Log entry (API=20060613) confused me.
P.M. :)
contrary to above log errors (API=20060613).
Anyway, it explains why ex. php-mcrypt did't bleated at installation time about different APIs - it was satisfied.
php-mcrypt (src: php-extras) define apiver on compile time
%global apiver %((echo 0; php -i 2>/dev/null | sed -n 's/^PHP API => //p') | tail -1)
Besides of php packages in extras repos. Is the apiver-definition in php-5.2.6-2.el5s2 correct?
Paulo Martinez a écrit :
It should be enough to specify Require/Provides-tags. As done in php-5.2.6-2.el5s2.src.rpm and php-mcrypt (src: php-extras) via
%define apiver xxxxxxx
php-5.2.6-2.el5s2.src.rpm defines apiver 20041225. And here comes my question: It defines this ^^ ?
rpm -q php-common-5.2.6-2.el5s2 --provides | grep api php(api) = 20041225 php-api = 20041225
I saw ; rpm -qp --provides php-common-5.2.6-2.el5s2.x86_64.rpm php(api) = 20041225 php(zend-abi) = 20060613 php-api = 20041225
php(api) is not meanfull since it haven't chance for years (2004) Only php(zend-api) is useful
php 5.1.x => 20050922 php 5.2.x => 20060613 php 5.3.x => 20090115
so far on rpms site. But
php -i | grep -P 'PHP API|PHP Version' PHP Version => 5.2.6 PHP API => 20041225
Check "phpize -v" : Configuring for: PHP Api Version: 20041225 Zend Module Api No: 20060613 Zend Extension Api No: 220060519
contrary to above log errors (API=20060613).
Exactly what I write above. "PHP Api Version" as no sense as the php extension loader check the "Zend Module Api No"
Anyway, it explains why ex. php-mcrypt did't bleated at installation time about different APIs - it was satisfied.
php-mcrypt (src: php-extras) define apiver on compile time
%global apiver %((echo 0; php -i 2>/dev/null | sed -n 's/^PHP API => //p') | tail -1)
Should use (simpler) %php_core_api and %php_zend_api from /etc/rpm/macros.php.
Generally Fedora package use something like :
%global php_apiver %((echo 0; php -i 2>/dev/null | sed -n 's/^PHP API => //p') | tail -1)
%if %{?php_zend_api}0 # For php 5.2.x use macros from /etc/rpm/macros.php Requires: php(zend-abi) = %{php_zend_api} Requires: php(api) = %{php_core_api} %else # Poor check for older PHP Requires: php-api = %{php_apiver} %endif
+
I just installed this release without issue. I want to thank the maintainers for getting 5.2 on there. My application depends on the new built in JSON parser.
Anthony
Anthony Francis wrote:
I just installed this release without issue. I want to thank the maintainers for getting 5.2 on there. My application depends on the new built in JSON parser.
Thanks for the feedback!
On 06/05/2009, Karanbir Singh mail-lists@karan.org wrote:
Anthony Francis wrote:
I just installed this release without issue. I want to thank the maintainers for getting 5.2 on there. My application depends on the new built in JSON parser.
Thanks for the feedback!
-- Karanbir Singh : http://www.karan.org/ : 2522219@icq
Hi there
We have been running 5.2.6 from testing for about a month on both production and dev web servers. everything has been fine apart from phpmyadmin complaining about the lack of php-mcrypt. I would really like to see this updated and moved from testing into extras or plus. Further to this end, if there is anything that i can do please let me know.
bw
mike
Michael Simpson wrote:
We have been running 5.2.6 from testing for about a month on both production and dev web servers. everything has been fine apart from phpmyadmin complaining about the lack of php-mcrypt.
There is the other thing about the c5-testing packages needing an update, I'll look into that shortly.
I would really like to see this updated and moved from testing into extras or plus. Further to this end, if there is anything that i can do please let me know.
There will be plenty to help out with. I've been investigating the idea of sub-rep's and how we might handle that in the buildsystem. Give me a few days and I should have a proposal that we can all consider. The end aim being : <php/web interest group> should be able to request and build pkgs into a subrepo that others can opt in or out from. It would need to be subrepo's with direct conflict situation between them in this case since there are atleast 3 clear php routes so far:
- distro php - rhwas php - php.net php
people need to have : a) easy way to stick to one tree b) relative easy way to switch from one to the other
and hopefully never need multiple php's on the same machine.
Karanbir Singh wrote: <snip>
There will be plenty to help out with. I've been investigating the idea of sub-rep's and how we might handle that in the buildsystem. Give me a
<snip>
Thank you for all this great stuff.
If possible, please consider including an rpm for Eaccelerator ( http://eaccelerator.net ). I have found this application indispensable for speeding up PHP applications.
Dag provides the rpm for the base repo, but I am not sure his repo will include builds for all these great repos you are developing.
As an aside, should there be a webstack mailing list?
John Thomas wrote:
If possible, please consider including an rpm for Eaccelerator ( http://eaccelerator.net ). I have found this application indispensable for speeding up PHP applications.
are you offering to maintain the package and keep it in sync with whats in rpmforge ? If so, well done!
As an aside, should there be a webstack mailing list?
Lets stick with this list for now, I dont think there is nearly enough traffic to merit its own list.
Karanbir Singh wrote:
John Thomas wrote:
If possible, please consider including an rpm for Eaccelerator ( http://eaccelerator.net ). I have found this application indispensable for speeding up PHP applications.
are you offering to maintain the package and keep it in sync with whats in rpmforge ? If so, well done!
Yes, I will do that.
I have never done such a thing, so if anybody would not mind mentoring me, that'd be great. I am a finance/real estate guy, with self taught computer skills. I have rebuilt rpms, but never fiddled with the spec file. I suspect Dag takes care of most of the brain damage.
Once I am comfortable and if I may, I may want to add more, like http://pecl.php.net/package/uploadprogress .
On Wed, 2009-05-06 at 12:39 -0700, John Thomas wrote:
Karanbir Singh wrote:
John Thomas wrote:
If possible, please consider including an rpm for Eaccelerator ( http://eaccelerator.net ). I have found this application indispensable for speeding up PHP applications.
are you offering to maintain the package and keep it in sync with whats in rpmforge ? If so, well done!
Yes, I will do that.
I have never done such a thing, so if anybody would not mind mentoring me, that'd be great. I am a finance/real estate guy, with self taught computer skills. I have rebuilt rpms, but never fiddled with the spec file. I suspect Dag takes care of most of the brain damage.
https://fedoraproject.org/wiki/Docs/Drafts/BuildingPackagesGuide
I'm willing to help guide, but do go through the examples in that article.
John Thomas wrote:
Karanbir Singh wrote:
John Thomas wrote:
If possible, please consider including an rpm for Eaccelerator ( http://eaccelerator.net ). I have found this application indispensable for speeding up PHP applications.
are you offering to maintain the package and keep it in sync with whats in rpmforge ? If so, well done!
Yes, I will do that.
I have never done such a thing, so if anybody would not mind mentoring me, that'd be great. I am a finance/real estate guy, with self taught computer skills. I have rebuilt rpms, but never fiddled with the spec file. I suspect Dag takes care of most of the brain damage.
Sorry, this was a mistake. I cannot do this. I want to help. I did not think this through first. Eventually, I will figure out a way to help. I apologize and am embarrassed.
Karanbir Singh a écrit :
Michael Simpson wrote:
We have been running 5.2.6 from testing for about a month on both production and dev web servers. everything has been fine apart from phpmyadmin complaining about the lack of php-mcrypt.
There is the other thing about the c5-testing packages needing an update, I'll look into that shortly.
I would really like to see this updated and moved from testing into extras or plus. Further to this end, if there is anything that i can do please let me know.
There will be plenty to help out with. I've been investigating the idea of sub-rep's and how we might handle that in the buildsystem. Give me a few days and I should have a proposal that we can all consider. The end aim being : <php/web interest group> should be able to request and build pkgs into a subrepo that others can opt in or out from. It would need to be subrepo's with direct conflict situation between them in this case since there are atleast 3 clear php routes so far:
- distro php
- rhwas php
- php.net php
people need to have : a) easy way to stick to one tree b) relative easy way to switch from one to the other
and hopefully never need multiple php's on the same machine.
We use our own set of php5 renamed packages which : - doesn't conflict with others php packages - try to follow both upstream and php.net - provide a lot of usefull/less modules ;-)
See : http://redhat.sorbonne.fr/CentOS-5/siris/repoview/P.group.html
<php/web interest group> is certainly where I'll be the more efficient to help.
Regards, Jean-Marc
Jean-Marc LIGER wrote:
We use our own set of php5 renamed packages which :
- doesn't conflict with others php packages
- try to follow both upstream and php.net
- provide a lot of usefull/less modules ;-)
That doesnt work very well on a larger scale. eg:
how do you provide a upgrade path from the distro php to the >someother< php, and how do you handle rpms for php-<feature> packages ? and how do they track what php version is being followed.
- KB
Karanbir Singh a écrit :
Jean-Marc LIGER wrote:
We use our own set of php5 renamed packages which :
- doesn't conflict with others php packages
- try to follow both upstream and php.net
- provide a lot of usefull/less modules ;-)
That doesnt work very well on a larger scale. eg:
Did I say that ? No, I just said I could/want to help in the php process :-)
how do you provide a upgrade path from the distro php to the >someother< php,
We deal with yum install/update php5[-feature] and the Provides/Obsoletes options.
and how do you handle rpms for php-<feature> packages ?
All the php-<feature> are built with the same php5 rpm.
and how do they track what php version is being followed.
The php version is forced in the php-<feature> Requires options.
One thing I forgot, our php rpm is hardened with the suhosin patch. You can look at the spec file here : http://redhat.sorbonne.fr/CentOS-5/siris/SPECS/php5.spec
Jean-Marc
Jean-Marc LIGER wrote:
how do you provide a upgrade path from the distro php to the >someother< php,
We deal with yum install/update php5[-feature] and the Provides/Obsoletes options.
but if php5-feature Obsoletes: php-feature, a yum upgrade will force the user to php5.
and how do you handle rpms for php-<feature> packages ?
All the php-<feature> are built with the same php5 rpm.
That just sounds like a really bad idea. Imagine what would happen if all of cpan was built into perl
One thing I forgot, our php rpm is hardened with the suhosin patch. You can look at the spec file here : http://redhat.sorbonne.fr/CentOS-5/siris/SPECS/php5.spec
why are you building all the php-<feature> stuff into the main spec ?
Karanbir Singh a écrit :
Jean-Marc LIGER wrote:
how do you provide a upgrade path from the distro php to the >someother< php,
We deal with yum install/update php5[-feature] and the Provides/Obsoletes options.
but if php5-feature Obsoletes: php-feature, a yum upgrade will force the user to php5.
We assume that, as it is provided in a specific repo you have to enable first, and where you can exclude php5* if you want to proceed a yum upgrade.
and how do you handle rpms for php-<feature> packages ?
All the php-<feature> are built with the same php5 rpm.
That just sounds like a really bad idea. Imagine what would happen if all of cpan was built into perl
Definitively yes or no, depending on what you are focus on :
- In a distro packaging way, you should reduce build cpu time and bandwith consumption, so you split packages every time you can, to reduce src.rpm sizes and the numbers of packages you must rebuild when some stuff need to be updated ; - In my service way, we have to reduce first human skills consumption, and we don't care about consuming some build cpu time or local network bandwith for that. So we customized a php5 packages which actually stick to our needs. Notice that with all the pecl and pear features I've had, I would have to maintain more than 50 different spec files instead of one.
One thing I forgot, our php rpm is hardened with the suhosin patch. You can look at the spec file here : http://redhat.sorbonne.fr/CentOS-5/siris/SPECS/php5.spec
why are you building all the php-<feature> stuff into the main spec ?
Apart from the easy spec file maintenance fact, I don't benefit of a high quality assurance build process like the CentOS one. So I like the idea of having all my php-<feature> built in a single pass, especially when I update php version from php.net.
Jean-Marc
Karanbir Singh a écrit :
Jean-Marc LIGER wrote:
how do you provide a upgrade path from the distro php to the >someother< php,
We deal with yum install/update php5[-feature] and the Provides/Obsoletes options.
but if php5-feature Obsoletes: php-feature, a yum upgrade will force the user to php5.
We assume that, as this is provided in a specific repo you have to enable first, and where you can exclude php5* if you want to proceed a yum upgrade.
and how do you handle rpms for php-<feature> packages ?
All the php-<feature> are built with the same php5 rpm.
That just sounds like a really bad idea. Imagine what would happen if all of cpan was built into perl
Definitively yes or no, depending on what you are focus on :
- Yes in a distro packaging way, you should reduce build cpu time and bandwith consumption, so you split packages every time you can, to reduce src.rpm sizes and the numbers of packages you must rebuild when some stuff need to be updated ; - No in my service way, where we have to reduce human skills consumption first, and we don't care about consuming some build cpu time or local network bandwith for that. So we customized a php5 packages which actually stick to our needs. Notice that with all the pecl and pear features I've had, I would have to maintain more than 50 different spec files instead of one.
One thing I forgot, our php rpm is hardened with the suhosin patch. You can look at the spec file here : http://redhat.sorbonne.fr/CentOS-5/siris/SPECS/php5.spec
why are you building all the php-<feature> stuff into the main spec ?
Apart from the easy spec file maintenance fact, I don't benefit of a high quality assurance build process like the CentOS one. So I like the idea of having all my php-<feature> built in a single pass, especially when I update php version from php.net.
Jean-Marc
-
Anthony Francis -
Ignacio Vazquez-Abrams -
Jean-Marc LIGER -
John Thomas -
Karanbir Singh -
Michael Simpson -
Paulo Martinez -
Ralph Angenendt -
Remi Collet -
William L. Maltby