[PHP-DEV] Bug #10597: RE #5684: PHP Intermittently reports Unable to allocate connection record
From: [EMAIL PROTECTED] Operating system: RedHat 6.2 PHP version: 4.0.5 PHP Bug Type: Sybase-ct (ctlib) related Bug description: RE #5684: PHP Intermittently reports Unable to allocate connection record RE #5684, You asked for any other cases: I get this error when I use a custom error handler to catch sybase errors. For example, if I try to delete a record with children in other tables, it raises a FK constraint violation error...everything normal. But after that error, where I try to do database reads and writes in my error handler function, I get really wierd problems. The main problem is that ctlib start reporting level 10 errors, instead of level 11, eg: DB ERROR: Changed database context to 'xxx'. After this, I get cannot allocate connection record. This only happens after I catch the error. If I turn off my error handling function, everything is fine. This says to me that the ctlib (or PHP) can't carry on after an error. But then I know little about either :) -- Edit Bug report at: http://bugs.php.net/?id=10597edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10598: Windows Protocol ini file placement
From: [EMAIL PROTECTED] Operating system: Windows PHP version: 4.0.5 PHP Bug Type: *Install and Config Bug description: Windows Protocol ini file placement I've been running PHP with this: http://www.php.net/do_download.php?download_file=php405-installer.exesource_site=www.php.net Basically, I have a problem with the placement of your php.ini. I would have thought, hoped it would run from the php directory as well as the windows directory. This is standard Windows protocol. A windows *.exe normally prioritises looking in the app directory and then in the windows directory for the location of *.ini files. Your Msvcrt.dll was installed in my network drive: t:\php\ and works like a charm; so should the php.ini!. My at-work installation of windows is NT Server based and I don't have permissions to access D:\ntdir where NT was installed. I'm running a http microweb out of a separate directory and hoped to make use of PHP at work. I can't because I can't put the php in the windows directory. It won't work in my network drive: t:\php\php.ini While my case may or may not be non-standard, your port to windows lack in basic *.ini protocol. It should look in the app directory to see if the ini exists there too! -- Edit Bug report at: http://bugs.php.net/?id=10598edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #7615 Updated: Session management in thttpd / proxy problem
ID: 7615 User Update by: [EMAIL PROTECTED] Old-Status: Feedback Status: Open Bug Type: Other web server Description: Session management in thttpd / proxy problem James, This works OK: thttpd - Firewall w/NAT - Internet - ISP - Client This doesn't: thttpt - Firewall - Internet - ISP - Proxy - Client Seems that either thttpd/php does not deliver the 'proxy-no-cache' pragma or that the proxy filters out the 'no-cache' pragma on the way to the client browser. Regards, Ben Previous Comments: --- [2001-05-01 08:58:54] [EMAIL PROTECTED] Can you please try this without the firewall inbetween you and the webserver and see if the firewall delay is causing the problem or if it is definatly a PHP-Thttpd problem. - James --- [2000-12-26 04:51:27] [EMAIL PROTECTED] I think the initial post pretty much sums it up. I haven't got any sample page/app ready with authentication, cookies _and_ a firewall in between. But Dragonflymail/Squirrelmail is pretty easy to install and should yield the desired behaviour. Don't you have kinda regression test suites ready at php's? Now this would be a very useful addition. Regards, Ben --- [2000-12-22 20:02:56] [EMAIL PROTECTED] Do I understand you correctly that thttpd/PHP does not read the POST data completely? If that is the case, PHP might not be able to get the correct POST data. Can you provide an example for this situation (i.e. a form which gets submitted to a server which displays the variables it received)? --- [2000-11-03 05:11:26] [EMAIL PROTECTED] I installed thttpd-2.20b with PHP 4.0.3pl1 with --with-trans-sid, --with-imap --with-sockets --with-thttpd. I have Squirrelmail and Dragonflymail installed to check them out. Both worked. When trying to access them via a company's firewall, login was not possible, neither via trans-sid nor cookies. I ran a network trace against both thttpd and apache (on which the very same box with the very same apps work) and saw that thttpd is very quick (as not to say impatient) at session build-up. It simply does not seem to wait until the client had answered *all* questions. It seems that the client has no time to transmit session IDs *and* POSTing the login information. I've read somewhere that someone had as similar problem with apache which he solved by adding a delay in the session-buildup routine. I don't know if this is a thttpd problem or php-in-thttpd problem. Other pages (that had nothing to do with session stuff) just work fine. For the time being, I leave apache installed although its footprint is way bigger than thttpd's... Regards, Ben --- Full Bug description available at: http://bugs.php.net/?id=7615 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10549 Updated: Performance problem with Openlink ODBC drivers
ID: 10549 User Update by: [EMAIL PROTECTED] Old-Status: Feedback Status: Open Bug Type: ODBC related Description: Performance problem with Openlink ODBC drivers I'm using the Openlink Data Access Driver Suite (Multi Tier Edition) Version 4.0, Connecting to a Progress 8.3B Database running on an AIX Unix Box. Previous Comments: --- [2001-05-01 16:59:38] [EMAIL PROTECTED] before i commit such a patch, what version of OpenLink are you using? --- [2001-04-29 06:35:11] [EMAIL PROTECTED] Hello, I've experienced a compilation error and some huge performance problems setting up an ODBC connection via Openlink ODBC drivers. I've configured my Php: ./configure --with-openlink=/usr/src/openlink When compiling Php, it complains about missing the iodbc.h udbcext.h header files which are not included in the SDK software package of Openlink. When I remove the two above include files from ./ext/odbc/php_odbc.h line 125 128 the compilation works fine without errors or warnings, and am able to etablish a connection to my Openlink drivers. When I query my DB from out of Php via Openlink, a simple query takes huges amounts of time, while the same query is very fast using the included odbctest utility from the Openlink SDK package. I've run a query via Php and the odbctest utility and compared the two debug files and saw that Php uses the ExtendedSQLFetch C- function. The odbctest utility uses an 'normal' SQLFetch function. So I have changed my ./ext/odbc/php_odbc.h file line 124 from: #elif defined(HAVE_OPENLINK) /* OpenLink ODBC drivers */ #define ODBC_TYPE Openlink #include iodbc.h #include isql.h #include isqlext.h #include udbcext.h #define HAVE_SQL_EXTENDED_FETCH 1 #define SQLSMALLINT SWORD #define SQLUSMALLINT UWORD to: #elif defined(HAVE_OPENLINK) /* OpenLink ODBC drivers */ #define ODBC_TYPE Openlink // #include iodbc.h #include isql.h #include isqlext.h // #include udbcext.h // #define HAVE_SQL_EXTENDED_FETCH 1 #undef HAVE_SQL_EXTENDED_FETCH #define SQLSMALLINT SWORD #define SQLUSMALLINT UWORD With this small change I was able to compile my Php succesfully and query my Database via the Openlink Package very fast! Regards, Anne van der Velden Correct Express The Netherlands --- Full Bug description available at: http://bugs.php.net/?id=10549 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10600: php4dll compile fails in Release_TS mode
From: [EMAIL PROTECTED] Operating system: Win32 PHP version: 4.0.5 PHP Bug Type: Compile Failure Bug description: php4dll compile fails in Release_TS mode When trying to compile project php4dll, you get a message from VC6: The source files ext\bcmath\libbcmath\src\output.c and ext\standard\output.c are both configured to produce the output file Release_inline\output.obj The project cannot be built I´ll try to make a workaround for myself, but just to make you know. -- Edit Bug report at: http://bugs.php.net/?id=10600edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10598 Updated: Windows Protocol ini file placement
ID: 10598 Updated by: brianlmoon Reported By: [EMAIL PROTECTED] Status: Open Bug Type: *Install and Config PHP Version: 4.0.5 Assigned To: Comments: While I do agree with you that this is a pain, there is a possible solution assuming that you can set environment variables on your machine. Set PHPRC to the path where the php.ini file is. Then PHP will look there instead. Previous Comments: --- [2001-05-02 03:17:12] [EMAIL PROTECTED] I've been running PHP with this: http://www.php.net/do_download.php?download_file=php405-installer.exesource_site=www.php.net Basically, I have a problem with the placement of your php.ini. I would have thought, hoped it would run from the php directory as well as the windows directory. This is standard Windows protocol. A windows *.exe normally prioritises looking in the app directory and then in the windows directory for the location of *.ini files. Your Msvcrt.dll was installed in my network drive: t:php and works like a charm; so should the php.ini!. My at-work installation of windows is NT Server based and I don't have permissions to access D:ntdir where NT was installed. I'm running a http microweb out of a separate directory and hoped to make use of PHP at work. I can't because I can't put the php in the windows directory. It won't work in my network drive: t:phpphp.ini While my case may or may not be non-standard, your port to windows lack in basic *.ini protocol. It should look in the app directory to see if the ini exists there too! --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10598edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10601: crypt() not work
From: [EMAIL PROTECTED] Operating system: Windows NT 4.0 Workstation PHP version: 4.0.5 PHP Bug Type: Feature/Change Request Bug description: crypt() not work windows php 4.0.4pl1 work with crypt(), but windows php 4.0.5 not work with crypt(). really? I necessarily need crypt() with windows php. please help me. -- Edit Bug report at: http://bugs.php.net/?id=10601edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #10598 Updated: Windows Protocol ini file placement
Looking at the API I think I can do this. The only question I have is how do I tell from inside the code whether or not PHP is a DLL or an EXE? The function call has to be made differently depending on that information. Brian Moon -- dealnews.com, Inc. Makers of dealnews, dealmac http://dealnews.com/ | http://dealmac.com/ - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, May 02, 2001 2:56 AM Subject: [PHP-DEV] Bug #10598 Updated: Windows Protocol ini file placement ID: 10598 Updated by: brianlmoon Reported By: [EMAIL PROTECTED] Status: Open Bug Type: *Install and Config PHP Version: 4.0.5 Assigned To: Comments: While I do agree with you that this is a pain, there is a possible solution assuming that you can set environment variables on your machine. Set PHPRC to the path where the php.ini file is. Then PHP will look there instead. Previous Comments: -- - [2001-05-02 03:17:12] [EMAIL PROTECTED] I've been running PHP with this: http://www.php.net/do_download.php?download_file=php405-installer.exesource _site=www.php.net Basically, I have a problem with the placement of your php.ini. I would have thought, hoped it would run from the php directory as well as the windows directory. This is standard Windows protocol. A windows *.exe normally prioritises looking in the app directory and then in the windows directory for the location of *.ini files. Your Msvcrt.dll was installed in my network drive: t:php and works like a charm; so should the php.ini!. My at-work installation of windows is NT Server based and I don't have permissions to access D:ntdir where NT was installed. I'm running a http microweb out of a separate directory and hoped to make use of PHP at work. I can't because I can't put the php in the windows directory. It won't work in my network drive: t:phpphp.ini While my case may or may not be non-standard, your port to windows lack in basic *.ini protocol. It should look in the app directory to see if the ini exists there too! -- - ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10598edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10599: background attribute in the body tag causes a double insert
From: [EMAIL PROTECTED] Operating system: linux PHP version: 4.0.4pl1 PHP Bug Type: MySQL related Bug description: background attribute in the body tag causes a double insert I have documented the problem at a href=http://www.dukemarket.com/bug.php;http://www.dukemarket.com/bug.php/a. If you have any questions, email me at a href=mailto:[EMAIL PROTECTED];[EMAIL PROTECTED]/a. -- Edit Bug report at: http://bugs.php.net/?id=10599edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0 Bug #10589 Updated: buildconf not compatiblewith Gnu Libtool 1.4
ID: 10589 User Update by: [EMAIL PROTECTED] Status: Closed Bug Type: *Install and Config Description: buildconf not compatible with Gnu Libtool 1.4 [root@gecko /root]# cd /usr/src/php4 [root@gecko php4]# ./cvsclean; ./buildconf buildconf: checking installation... buildconf: autoconf version 2.13 (ok) buildconf: automake version 1.4 (ok) build/buildcheck.sh: test: integer expression expected before -ge buildconf: libtool version 1.4 found. You need libtool version 1.3.3 or newer installed to build PHP from CVS. make: *** [buildmk.stamp] Error 1 I see the problem when I force $lt_version to 1.4 (which appears to be what 'libtool --version' is returning) in build/buildcheck.sh. A patch to workaround this: ===CUT=== --- buildcheck.sh.bak Wed May 2 01:39:07 2001 +++ buildcheck.sh Wed May 2 01:37:41 2001 @@ -67,14 +67,27 @@ fi lt_version=`echo $lt_pversion|sed -e 's/\([a-z]*\)$/.\1/'` IFS=.; set $lt_version; IFS=' ' -if test $1 -gt 1 || test $2 -gt 3 || test $2 = 3 (test $3 = c || test $3 -ge 3) +if test $1 -gt 1 || test $2 -gt 3 || test $2 = 3 (test x$3 != x) then -echo buildconf: libtool version $lt_pversion (ok) + if test $3 = c || test $3 -ge 3 + then + echo buildconf: libtool version $lt_pversion (ok) + else + echo buildconf: libtool version $lt_pversion found. + echoYou need libtool version 1.3.3 or newer installed + echoto build PHP from CVS. + exit 1 + fi else -echo buildconf: libtool version $lt_pversion found. -echoYou need libtool version 1.3.3 or newer installed -echoto build PHP from CVS. -exit 1 + if test x$3 == x test $2 -lt 4 + then + echo buildconf: libtool version $lt_pversion found. + echoYou need libtool version 1.3.3 or newer installed + echoto build PHP from CVS. + exit 1 + else + echo buildconf: libtool version $lt_pversion (ok) + fi fi am_prefix=`which automake | sed -e 's#/[^/]*/[^/]*$##'` ===CUT=== Chris -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10600 Updated: php4dll compile fails in Release_TS mode
ID: 10600 User Update by: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: Compile Failure Description: php4dll compile fails in Release_TS mode ok, I saw it had already been reported. My workaround: I renamed one of the files (the one in bcmath) to output2.c, and I edited the php4dll.dsp to reflect the change, and it compiled fine :-) Previous Comments: --- [2001-05-02 03:49:56] [EMAIL PROTECTED] When trying to compile project php4dll, you get a message from VC6: The source files extbcmathlibbcmathsrcoutput.c and extstandardoutput.c are both configured to produce the output file Release_inlineoutput.obj The project cannot be built I´ll try to make a workaround for myself, but just to make you know. --- Full Bug description available at: http://bugs.php.net/?id=10600 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10602: $HTTP_POST_FILES doesn't work properly
From: [EMAIL PROTECTED] Operating system: Linux 7.0 PHP version: 4.0.4pl1 PHP Bug Type: HTTP related Bug description: $HTTP_POST_FILES doesn't work properly for upload of 3 images from POST form it gives me nothing (even no error message): echo $HTTP_POST_FILES['name'][0]; echo $HTTP_POST_FILES['name'][1]; echo $HTTP_POST_FILES['name'][2]; echo $HTTP_POST_FILES['type'][0]; echo $HTTP_POST_FILES['type'][1]; echo $HTTP_POST_FILES['type'][2]; echo $HTTP_POST_FILES['tmp_name'][0]; echo $HTTP_POST_FILES['tmp_name'][1]; echo $HTTP_POST_FILES['tmp_name'][2]; echo $HTTP_POST_FILES['size'][0]; echo $HTTP_POST_FILES['size'][1]; echo $HTTP_POST_FILES['size'][2]; even like - echo $HTTP_POST_FILES['name'][0]; -- Edit Bug report at: http://bugs.php.net/?id=10602edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10603: Problems changing the language.
From: [EMAIL PROTECTED] Operating system: Windows 2000 PHP version: 4.0.5 PHP Bug Type: Gettext related Bug description: Problems changing the language. I run php as apache module (apache 1.3.19) I put this code: putenv(LANG=RO); bindtextdomain (domain, ./locale); textdomain (domain); everything is ok. Then I modify the value of the language ( and it's ok 'cause I display it with getenv(LANG), but the translation doesn't change. If I run php as cgi this works fine. I have the same problem with php 4.0.4pl1 -- Edit Bug report at: http://bugs.php.net/?id=10603edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10269 Updated: Installation fails at line 58 of file 'my_getwd.c
ID: 10269 Updated by: mysql Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Compile Failure PHP Version: 4.0.4pl1 Assigned To: Comments: To compile my_getwd.c, you must either have the getcwd() or getwd() library call in the libc library. The FreeBSD 3.x system I have used has this call, so the problem in this case is probably that all development headers/libraries are not installed on this machine. To find out what's wrong, please examine the config.log file and try to find out why neither of the above functions was found by configure. Regards, Monty Previous Comments: --- [2001-04-29 05:17:34] [EMAIL PROTECTED] This is a bug in libmysql which is maintained by the kinda folks over at mysql.com please report the bug to them. - James --- [2001-04-10 14:40:03] [EMAIL PROTECTED] OS: FreeBSD 3.4-STABLE (tested on different servers under this OS) Type of bag - stable - can't find any depends of installed packages or compiled kernel modules. Problem compiling place: Making all in libmysql gcc -I. -I/usr/home/virtan/tmp/php-4.0.4pl1/ext/mysql/libmysql -I/usr/home/virtan/tmp/php-4.0.4pl1/main -I/usr/home/virtan/tmp/php-4.0.4pl1 -I/usr/home/virtan/tmp/apache_1.3.12rusPL29.4/src/include -I/usr/home/virtan/tmp/apache_1.3.12rusPL29.4/src/os/unix -I/usr/home/virtan/tmp/php-4.0.4pl1/Zend -I/usr/local/include/freetype -I/usr/local/include -I/usr/home/virtan/tmp/php-4.0.4pl1/ext/mysql/libmysql -I/usr/home/virtan/tmp/php-4.0.4pl1/ext/xml/expat/xmltok -I/usr/home/virtan/tmp/php-4.0.4pl1/ext/xml/expat/xmlparse -I/usr/home/virtan/tmp/php-4.0.4pl1/TSRM -DXML_BYTE_ORDER=12 -g -O2 -c my_getwd.c touch my_getwd.lo my_getwd.c:58: #error No way to get current directory *** Error code 1 Configure parameters: ./configure --enable-versioning --with-mysql --enable-track-vars --with-mod_charset --with-apache=../apache_1.3.12rusPL29.4 --enable-calendar --enable-ftp --with-gd=/usr/local --with-jpeg-dir --with-tiff-dir --with-xpm-dir --with-zlib-dir=/usr/local/lib --enable-ftp --with-ttf --with-mysql --with-png-dir --with-regex=system --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10269edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10604: couldnt update a session var or just register one
From: [EMAIL PROTECTED]
Operating system: linux (redhat 7.0)
PHP version: 4.0.4pl1
PHP Bug Type: *Session related
Bug description: couldnt update a session var or just register one
Hi and sorry to disturb but i have a pb
and i dont know if is it a bug or something
else, hope is not a bug!
maybe the problem comes from the compilation,
maybe from me, but when i do :
-- SESSION PB ---
session_start();
$ID=session_id(); $WHAT=$pass.$ID;
if(!$SID){
session_register(SID);
$SID=md5($WHAT);
}else{
$LOCAL_SID=md5($WHAT);
if($SID!=$LOCAL_SID){
session_destroy();
?scriptalert(ops...);/script?
}
}
--
and i do :
echo session_encode();
i get :
--
usr_pro|s:1:1;usr_key|s:1:1;connected|i:1;usr_log|s:3:flo;!SID|secteur|s:1:2;
with SID unset...
and other pb is that i cannot update a session var:
session_unregister('toto');
session_register('toto');
when this is done, i got the same values from toto :-(
thanks for all !
regards,
José PLANS
--
Edit Bug report at: http://bugs.php.net/?id=10604edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #8315 Updated: strange session behavior with register_globals off
ID: 8315
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: *Session related
PHP Version: 4.0 Latest CVS (18/12/2000)
Assigned To:
Comments:
Previous Comments:
---
[2000-12-18 13:02:23] [EMAIL PROTECTED]
Apache 1.3.14 through apache-1.3_20001218111201
PHP snapshots since about two weeks ago through php-4.0.4RC6
stock php.ini-optiomized (with the exception of error_reporting E_ALL)
Actually I cannot confirm this bug with latest CVS, because it won't build, but this
has been valid for apachephp4.dll for about two weeks.
This issue can be stripped down to: it seems that with register_globals off, variables
registered in a session become members of $HTTP_SESSION_VARS on the NEXT request, and
when unregistered, get re-registered on the next request. The latter looks like an
outstanding bug.
The (lack of) presence of the error_reporting() calls in the beginning of all the
files has no effect on the issue.
Also, notice that when register_globals is on, session_is_registered() returns true,
the global variable has it's value and is subsequently recreated on the next request,
however, on the request where the session is started, $HTTP_SESSION_VARS is empty.
With register_globals off, it already contains the variable when I traverse the array.
(with the following bump: the increment call in the following block:
$count = 0 ;
session_register( 'count' ) ;
$HTTP_SESSION_VARS['count']++ ;
results in undefined index warning...)
Seems like session support should be tagged 'experimental' on win32 Apache... Which is
a pitty, as this httpd represents the shortest and most straightforward way from win32
dev machines to most unix servers...
register_globals on
===
test1.php
===
error_reporting( E_ALL ) ;
session_start() ;
$count = 0 ;
session_register( 'count' ) ;
$count++ ;
echo session_is_registered('count') ? 'yes' : 'no' ;
echo $count ;
foreach( $HTTP_SESSION_VARS as $k = $v ) {
echo $k : $vn ;
} ;
echo 'a href=/test2.phptest2.php/a'
===
relevant output:
===
yes
1
===
test2.php
===
error_reporting( E_ALL ) ;
session_start() ;
session_unregister( 'count' ) ;
$count++ ;
echo session_is_registered('count') ? 'yes' : 'no' ;
echo $count ;
foreach( $HTTP_SESSION_VARS as $k = $v ) {
echo $k : $vn ;
} ;
echo 'a href=/test3.phptest3.php/a' ;
===
relevant output:
===
no
2
count : 1
test3.php
===
error_reporting( E_ALL ) ;
session_start() ;
echo session_is_registered('count') ? 'yes' : 'no' ;
echo $count ;
foreach( $HTTP_SESSION_VARS as $k = $v ) {
echo $k : $vn ;
} ;
echo 'a href=test1.phptest1.php/a' ;
===
relevant output:
===
no
Warning: Undefined variable: count ...
register_globals off
===
test1.php
===
error_reporting( E_ALL ) ;
session_start() ;
$count = 0 ;
session_register( 'count' ) ;
$HTTP_SESSION_VARS['count']++ ;
echo session_is_registered('count') ? 'yes' : 'no' ;
echo $HTTP_SESSION_VARS['count'] ;
foreach( $HTTP_SESSION_VARS as $k = $v ) {
echo $k : $vn ;
} ;
echo 'a href=/test2.phptest2.php/a'
===
relevant output:
===
Warning: Undefined index: count ...
yes
1
count : 1
===
test2.php
===
error_reporting( E_ALL ) ;
session_start() ;
session_unregister( 'count' ) ;
$HTTP_SESSION_VARS['count']++ ;
echo session_is_registered('count') ? 'yes' : 'no' ;
echo $HTTP_SESSION_VARS['count'] ;
foreach( $HTTP_SESSION_VARS as $k = $v ) {
echo $k : $vn ;
} ;
echo 'a href=/test3.phptest3.php/a' ;
===
relevant output:
===
no
2
count : 2
test3.php
===
error_reporting( E_ALL ) ;
session_start() ;
echo session_is_registered('count') ? 'yes' : 'no' ;
echo $HTTP_SESSION_VARS['count'] ;
foreach(
[PHP-DEV] PHP 4.0 Bug #10555 Updated: .htaccess config setting cause sudden loss of PHP-include path or apache crash
ID: 10555
User Update by: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: *Configuration Issues
Description: .htaccess config setting cause sudden loss of PHP-include path or apache
crash
Problem has disappeared with the new version of php 4.0.5
Previous Comments:
---
[2001-04-29 13:55:16] [EMAIL PROTECTED]
ERROR:
==
A *VERY* tricky error only showning up under load.
A simple reproduceable sample is below and a guess of reason.
Error will show up if you use Apache (V3.1.19) and try to set the PHP include_path as
config setting in the .htaccess file (instead of using the php-ini file) as described
in chapter 3 of the PHP documentation.
E.g. content of the .htaccess:
php_value include_path c:varwwwphp
Setup as described above and refresh the sample below quickly few times and you'll see
the effect:
- Either the apache server will crash
OR
- A PHP Fatal error: Failed opening required 'empty.php' (include_path=' KÞ') in ...
on line 2
will display suddenly in one of the frames instead of OK. The content of
include_path is then random or an empty string.
REASON GUESS:
Either a PHP or Apache problem. When reading the .htaccess file it seams to cause a
pointer error. As this effect comes up under load, I guess it's a file pointer- or
cashing- problem.
WORK AROUND:
Don't use .htaccess for PHP config settings under windows.
SAMPLE:
===
2 Files empty.php and bug.php
A) empty.php: An empty PHP file that must be lying in the include_path (e.g.
c:varwwwphp).
B) bug.php: The code is at the end of this repport. Put it somewhere accessable by the
server and browse it. On success you should see 4x4 frames displaying OK. The error
case is described above.
?
require_once('empty.php');
$thisFile = $PHP_SELF;
if (!isSet($input)) $input=0;
if ($input2) {
$input++;
?
!-- frames --
frameset rows=50%,* cols=50%,*
frame src=? echo $thisFile; ??input=? echo $input; ?
frame src=? echo $thisFile; ??input=? echo $input; ?
frame src=? echo $thisFile; ??input=? echo $input; ?
frame src=? echo $thisFile; ??input=? echo $input; ?
/frameset
?
} else {
echo OK;
}
?
---
Full Bug description available at: http://bugs.php.net/?id=10555
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10605 Updated: php4dll compiles but won't link
ID: 10605 User Update by: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: Compile Failure Description: php4dll compiles but won't link I didn't compile php4ts.lib properly so I got those nasty link errors. Everything is ok now :-D Previous Comments: --- [2001-05-02 05:55:20] [EMAIL PROTECTED] I've compiled and linked successfully all the projects within workspace php4.dsw (Win32_Release), all but php4dll, which cannot link. This is the output from VC++ 6 : Configuration: php4dll - Win32 Release Linking... Creating library ..Release/php4nts.lib and object ..Release/php4nts.exp LINK : warning LNK4049: locally defined symbol _pcre_free imported LINK : warning LNK4049: locally defined symbol _pcre_malloc imported fopen_wrappers.obj : error LNK2001: unresolved external symbol __imp__virtual_chdir_file main.obj : error LNK2001: unresolved external symbol __imp__virtual_chdir_file fopen_wrappers.obj : error LNK2001: unresolved external symbol __imp__virtual_file_ex internal_functions_win32.obj : error LNK2001: unresolved external symbol _VARIANT_module_entry COM.obj : error LNK2001: unresolved external symbol _php_char_to_OLECHAR COM.obj : error LNK2001: unresolved external symbol _php_OLECHAR_to_char COM.obj : error LNK2001: unresolved external symbol _php_pval_to_variant COM.obj : error LNK2001: unresolved external symbol _php_variant_to_pval ..Releasephp4nts.dll : fatal error LNK1120: 7 unresolved externals Error executing link.exe. php4nts.dll - 9 error(s), 2 warning(s) So what might go wrong? (I could compile/link v4.0.3pl1 with no problems) --- Full Bug description available at: http://bugs.php.net/?id=10605 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] sessions, track_vars, register_globals
two snips from the manual: 1) If both track_vars and register_globals are enabled, then the globals variables and the $HTTP_SESSION_VARS entries will reference the same value. 2) As of PHP 4.0.3, track_vars is always turned on. This is not the case with Apache 1.3.20-dev, 4.0.5 RC7, and 4.0.5 (final) on NT4 SP5 - with register_globals on, $HTTP_SESSION_VARS is always empty. Is this a bug in the docs or in the behavior? [EMAIL PROTECTED] - And the eyes of them both were opened and they saw that their files were world readable and writable, so they chmoded 600 their files. - Book of Installation chapt 3 sec 7 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10565 Updated: mysql_real_connect dumps core, fix included
ID: 10565 Updated by: cynic Reported By: [EMAIL PROTECTED] Status: Open Bug Type: MySQL related PHP Version: 4.0.4pl1 Assigned To: Comments: mailed MySQL Previous Comments: --- [2001-04-30 16:57:34] [EMAIL PROTECTED] ** This is a problem in MySql. This report provides a code modification to compensate for the MySql problem. ** Under SCO OpenServer 5.0.6, Apache 1.3.19, PHP 4.0.4 PL 1, and MySql 3.23.36 (precompiled MySQL for OpenServer 5.0.x), calls to mysql_real_connect will silently dump core if mysql_init was not allowed to *allocate* the memory for the MySQL structure. To function properly, mysql_init must be passed NULL, thus allowing it to allocate and manage the memory. If you use a previously malloc()'ed or static structure, MySQL will dump core on connect. We find this problem to be present in MySQL, and can duplicate it using a C code stub. The problem, of course, also exists in PHP, causing a core dump there as well, since PHP pre-malloc()'s its own structure. Here is a DIFF for ext/mysql/php_mysql.c which fixes the problem for us. It's ugly, and hack-y, but it works. FYI. 198c198 efree(link); --- /* efree(link); */ 456c456 mysql = (MYSQL *) malloc(sizeof(MYSQL)); --- /* mysql = (MYSQL *) malloc(sizeof(MYSQL)); */ 458c458 mysql_init(mysql); --- mysql = mysql_init(NULL); 542c542 mysql = (MYSQL *) emalloc(sizeof(MYSQL)); --- /* mysql = (MYSQL *) emalloc(sizeof(MYSQL)); */ 544c544 mysql_init(mysql); --- mysql = mysql_init(NULL); --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10565edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] sessions, track_vars, register_globals
Sounds like a bug in PHP to me. Andi At 01:00 PM 5/2/2001 +0200, Cynic wrote: two snips from the manual: 1) If both track_vars and register_globals are enabled, then the globals variables and the $HTTP_SESSION_VARS entries will reference the same value. 2) As of PHP 4.0.3, track_vars is always turned on. This is not the case with Apache 1.3.20-dev, 4.0.5 RC7, and 4.0.5 (final) on NT4 SP5 - with register_globals on, $HTTP_SESSION_VARS is always empty. Is this a bug in the docs or in the behavior? [EMAIL PROTECTED] - And the eyes of them both were opened and they saw that their files were world readable and writable, so they chmoded 600 their files. - Book of Installation chapt 3 sec 7 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10605: php4dll compiles but won't link
From: [EMAIL PROTECTED] Operating system: Win32 PHP version: 4.0.5 PHP Bug Type: Compile Failure Bug description: php4dll compiles but won't link I've compiled and linked successfully all the projects within workspace php4.dsw (Win32_Release), all but php4dll, which cannot link. This is the output from VC++ 6 : Configuration: php4dll - Win32 Release Linking... Creating library ..\Release/php4nts.lib and object ..\Release/php4nts.exp LINK : warning LNK4049: locally defined symbol _pcre_free imported LINK : warning LNK4049: locally defined symbol _pcre_malloc imported fopen_wrappers.obj : error LNK2001: unresolved external symbol __imp__virtual_chdir_file main.obj : error LNK2001: unresolved external symbol __imp__virtual_chdir_file fopen_wrappers.obj : error LNK2001: unresolved external symbol __imp__virtual_file_ex internal_functions_win32.obj : error LNK2001: unresolved external symbol _VARIANT_module_entry COM.obj : error LNK2001: unresolved external symbol _php_char_to_OLECHAR COM.obj : error LNK2001: unresolved external symbol _php_OLECHAR_to_char COM.obj : error LNK2001: unresolved external symbol _php_pval_to_variant COM.obj : error LNK2001: unresolved external symbol _php_variant_to_pval ..\Release\php4nts.dll : fatal error LNK1120: 7 unresolved externals Error executing link.exe. php4nts.dll - 9 error(s), 2 warning(s) So what might go wrong? (I could compile/link v4.0.3pl1 with no problems) -- Edit Bug report at: http://bugs.php.net/?id=10605edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP Conference
It wasn't official... I guess it should change to the first official PHP conference. Zeev At 08:10 2/5/2001, Sebastian Bergmann wrote: Hi there, I just read the following on php.net: [1-May-2001] The first ever PHP Conference, part of the O'Reilly ... This is not true. The first PHP Conference ever was last year's 'PHP Kongress' in Cologne, Germany. True, it was not really international, but it was the first. Just a thought, Sebastian -- sebastian bergmann[EMAIL PROTECTED] http://www.sebastian-bergmann.de bonn.phpug.de | www.php.net | www.phpOpenTracker.de | www.titanchat.de -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10589 Updated: buildconf not compatible with Gnu Libtool 1.4
ID: 10589 Updated by: andi Reported By: [EMAIL PROTECTED] Old-Status: Closed Status: Open Bug Type: *Install and Config PHP Version: 4.0 Latest CVS (01/05/2001) Assigned To: Comments: Any reason why this was closed? Previous Comments: --- [2001-05-01 21:13:18] [EMAIL PROTECTED] [root@gecko /root]# cd /usr/src/php4 [root@gecko php4]# ./cvsclean; ./buildconf buildconf: checking installation... buildconf: autoconf version 2.13 (ok) buildconf: automake version 1.4 (ok) build/buildcheck.sh: test: integer expression expected before -ge buildconf: libtool version 1.4 found. You need libtool version 1.3.3 or newer installed to build PHP from CVS. make: *** [buildmk.stamp] Error 1 --- [2001-05-01 20:43:23] [EMAIL PROTECTED] Works for me just fine. Try doing './cvsclean ; ./buildconf' --jani --- [2001-05-01 15:58:38] [EMAIL PROTECTED] After the problems installing 4.0.5, I got the latest CVS. Running buildconf told me I needed libtool installed. Went to Gnu, got the latest (1.4) and installed it. buildconf now reports: buildconf: libtool version 1.4 found. You need libtool version 1.3.3 or newer installed to build PHP from CVS. make: *** [buildmk.stamp] Error 1 --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10589edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] 4.0.6
Hi, I think we should make a list of known 4.0.5 bugs which need to be fixed for 4.0.6 and once we fix them branch 4.0.6. I think there have been enough changes to warrant a 4.0.6 release soon. My list of bugs (please add to this): - COM support is completely broken (bug #10594) - libtool detection in ./configure seems to be kind of broken (bug #10589). Patch posted to php-dev Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] CVS Account Request
Full name: Ruiming Zhou Email: [EMAIL PROTECTED] ID: trzhou Purpose: Learning PHP and coding PHP source in C -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10606: function pdf_open_memory_image undefined function
From: [EMAIL PROTECTED] Operating system: Windows 98 SE PHP version: 4.0.5 PHP Bug Type: *PDF functions Bug description: function pdf_open_memory_image undefined function I use PHP 4.0.5 and Apache 1.3.12 My script : ? $pdf=pdf_new(); $im = ImageCreate(100, 100); $col = ImageColorAllocate($im, 80, 45, 190); ImageFill($im, 10, 10, $col); $pim = PDF_open_memory_image($pdf, $im); ImageDestroy($im); PDF_place_image($pdf, $pim, 100, 100, 1); PDF_close_image($pdf, $pim); ? The server's answer : Fatal error: Call to undefined function: pdf_open_memory_image() in c:\web\essaipdfnew.php on line 6 -- Edit Bug report at: http://bugs.php.net/?id=10606edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP Conference
Zeev Suraski wrote: It wasn't official... I guess it should change to the first official PHP conference. how do you define 'official' ? -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] 4.0.6
Andi Gutmans wrote: I think we should make a list of known 4.0.5 bugs which need to be fixed for 4.0.6 and once we fix them branch 4.0.6. I think there have been enough changes to warrant a 4.0.6 release soon. and i would suggest to announce the RCs not only here but on php.net and freshmeat.net as well -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP Conference
Officially announced by the PHP Group and on www.php.net. It doesn't make much of a difference. Zeev At 15:49 2/5/2001, Hartmut Holzgraefe wrote: Zeev Suraski wrote: It wasn't official... I guess it should change to the first official PHP conference. how do you define 'official' ? -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10608: Don't read max_execution_time value in php.ini
From: [EMAIL PROTECTED] Operating system: FreeBSD 4.3 PHP version: 4.0.5 PHP Bug Type: PHP options/info functions Bug description: Don't read max_execution_time value in php.ini I work with php in command line : php -c php.ini dir -f filename Command script exit with message : Profiling timer expired This bug I look after migrate from 4.0.4pl1 to 4.0.5 -- Edit Bug report at: http://bugs.php.net/?id=10608edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10568 Updated: error using ODBC
ID: 10568
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: ODBC related
Description: error using ODBC
(Iam using a traductor English/Spanish)
I use the software Microsoft Query for test the DNS connection and it worked very
well, but when I try to enter through php it throws me the mentioned error and not you
that it is.
This is a script:
?php
function a() {
$connect = odbc_connect ( dig , root , cir0921, SQL_CUR_USE_ODBC );
$query = SELECT * FROM local;
$result = odbc_exec($connect, $query);
while(odbc_fetch_row($result)) {
$id=odbc_result($result,1);
$pass=odbc_result($result,2);
echo id:$id,pass:$pass
;
}
odbc_close_all($connect);
return true;
} / / a
?
?php
echoLines Before;
$bb = a();
echo Lines Later;
?
Previous Comments:
---
[2001-05-01 09:59:18] [EMAIL PROTECTED]
i'm not sure i understand the error you're receiving. can you please give a sample
script that creates the error?
also, are you sure your SELECT statement works properly?
---
[2001-04-30 18:37:36] [EMAIL PROTECTED]
Hello:
I am using a database called RECITAL . I am trying to connect myself using ODBC.
When executing the command: odbc_exec($connect, $query) I can revise the connection
from the database and indeed her ago. But then treatment of consenting to the data
using any function ODBC, for example:
odbc_result_all($connect, BGCOLOR = ' #AAFFAA ' border=3 width=30% bordercolordark = '
#FF ');
---
and it throws me this error:
-
Warning: Not tuples available at this result index in programa/apache c:/archivos
group/apache/htdocs/b.html on line 7
-
I need to know if they can help me with this.
thank you.
(the table if it exists, some fields is: nlocal,ncontr)
This is the program php:
---
?php
function to () {
$connect = odbc_connect ( dig , root , cir0921, SQL_CUR_USE_ODBC );
$query = SELECT * local FROM;
$result = odbc_exec($connect, $query);
while(odbc_fetch_row($result)) {
$id=odbc_result($result,1);
$pass=odbc_result($result,2);
echo id:$id,pass:$pass
;
}
odbc_close_all($connect);
return true;
} / / a
?
?php
echoLines Before;
$bb = a();
echo Lines Later;
?
---
---
Full Bug description available at: http://bugs.php.net/?id=10568
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
At 15:18 2/5/2001, Hartmut Holzgraefe wrote: Andi Gutmans wrote: I think we should make a list of known 4.0.5 bugs which need to be fixed for 4.0.6 and once we fix them branch 4.0.6. I think there have been enough changes to warrant a 4.0.6 release soon. and i would suggest to announce the RCs not only here but on php.net and freshmeat.net as well I don't think that's a good idea, because then people will treat them as releases. I think that the way things are currently, plus the natural growth of the QA team, are the right way to go. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
At 04:02 PM 5/2/2001 +0300, Zeev Suraski wrote: At 15:18 2/5/2001, Hartmut Holzgraefe wrote: Andi Gutmans wrote: I think we should make a list of known 4.0.5 bugs which need to be fixed for 4.0.6 and once we fix them branch 4.0.6. I think there have been enough changes to warrant a 4.0.6 release soon. and i would suggest to announce the RCs not only here but on php.net and freshmeat.net as well I don't think that's a good idea, because then people will treat them as releases. I think that the way things are currently, plus the natural growth of the QA team, are the right way to go. I disagree. We are not getting enough testing of our RCs. I think if we announce an RC and we tell people they are just helping us test the pre-release it's OK. It's not as if they can't grab a snapshot. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] 4.0.6
At 02:18 PM 5/2/2001 +0200, Hartmut Holzgraefe wrote: Andi Gutmans wrote: I think we should make a list of known 4.0.5 bugs which need to be fixed for 4.0.6 and once we fix them branch 4.0.6. I think there have been enough changes to warrant a 4.0.6 release soon. and i would suggest to announce the RCs not only here but on php.net and freshmeat.net as well Yes we should probably get more people testing the RCs. Maybe the regular PHP mailing list is enough. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
At 16:02 2/5/2001, Andi Gutmans wrote:
I disagree. We are not getting enough testing of our RCs.
I think if we announce an RC and we tell people they are just helping us
test the pre-release it's OK.
It's not as if they can't grab a snapshot.
People usually tend to deal with pre-release or release candidate as if
they're releases. It's not that RC's are necessary significantly less
stable than releases, but I don't think that announcing them on such wide
forums would give our QA efforts anything. It's pretty much the same as
saying we announce 4.0.{x} as an RC for 4.0.{x+1}, because 4.0.{x} bugs
will start flowing as soon as it's out.
What I'm trying to say is that if we make that jump from a QA team to the
entire world, then essentially, we go a step backwards. I think that the
way things are today is good, and most of the bugs which aren't found can
only be found in wide scale testing, but I don't think that announcing RCs
in prominent places is the way to go.
Perhaps we should announce the QA team again, so that people who would join
but don't know about it would get a chance.
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
At 04:15 PM 5/2/2001 +0300, Zeev Suraski wrote:
At 16:02 2/5/2001, Andi Gutmans wrote:
I disagree. We are not getting enough testing of our RCs.
I think if we announce an RC and we tell people they are just helping us
test the pre-release it's OK.
It's not as if they can't grab a snapshot.
People usually tend to deal with pre-release or release candidate as if
they're releases. It's not that RC's are necessary significantly less
stable than releases, but I don't think that announcing them on such wide
forums would give our QA efforts anything. It's pretty much the same as
saying we announce 4.0.{x} as an RC for 4.0.{x+1}, because 4.0.{x} bugs
will start flowing as soon as it's out.
What I'm trying to say is that if we make that jump from a QA team to the
entire world, then essentially, we go a step backwards. I think that the
way things are today is good, and most of the bugs which aren't found can
only be found in wide scale testing, but I don't think that announcing RCs
in prominent places is the way to go.
Perhaps we should announce the QA team again, so that people who would
join but don't know about it would get a chance.
I don't think that the PHP mailing list is the whole world. It's a fairly
large amount of people but a relatively small percent of the amount of
downloaders (10% IMO).
I think that the amount of QA people (even if the amount doubles) is enough
to find those little bugs that crept in.
And many bugs can only be found by trying to actually run the RC for a few
days on a development machine. I don't know how many QA guys actually do that.
Andi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
I don't see any unusual peak now; We have tons of bug reports all the time. IMHO our problem is no longer lack of QA, but lack of developer resources to fix bugs. I truly think that making RCs effective releases gains nothing. If everyone else thinks differently, so be it. Zeev At 16:08 2/5/2001, Hartmut Holzgraefe wrote: Zeev Suraski wrote: I don't think that's a good idea, because then people will treat them as releases. thats just a matter of labeling and announcement message I think that the way things are currently, plus the natural growth of the QA team, are the right way to go. IMHO the current peak in new bug reports tells a different story -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
What I'm trying to say is that if we make that jump from a QA team to the entire world, then essentially, we go a step backwards. I think that the way things are today is good, and most of the bugs which aren't found can only be found in wide scale testing, but I don't think that announcing RCs in prominent places is the way to go. Perhaps we should announce the QA team again, so that people who would join but don't know about it would get a chance. I don't see how announcing RCs which are explicitly marked as such in a larger forum can hurt PHP or the release process. Could you elaborate? - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
At 04:22 PM 5/2/2001 +0300, Zeev Suraski wrote: I don't see any unusual peak now; We have tons of bug reports all the time. IMHO our problem is no longer lack of QA, but lack of developer resources to fix bugs. I truly think that making RCs effective releases gains nothing. If everyone else thinks differently, so be it. The COM problem would have been found IMO if we had released a bigger RC. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Failing configure
Hello, with latest snapshot I get this error during configure: Configuring libtool checking build system type... Configuration name missing Usage: ./config.sub CPU-MFR-OPSYS or ./config.sub ALIAS where ALIAS is a recognised configuration type. configure worked fine with earlier CVS version, and I've no problem compiling it as a CGI (only has Apache module). Any idea what goes wrong here? Derick Rethans - PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED] SRM: Site Resource Manager - www.vl-srm.net - JDI Media Solutions - www.jdimedia.nl - [EMAIL PROTECTED] Boulevard Heuvelink 102 - 6828 KT Arnhem - The Netherlands - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0 Bug #10589 Updated: buildconf not compatiblewith Gnu Libtool 1.4
Because I didn't read the report well enough. I didn't know that libtool 1.4 had been released. :( And now the machine hosting the bug system is down so I can't reopen it.. --Jani On Wed, 2 May 2001, Andi Gutmans wrote: Any idea why the status is 'Closed'? I don't see a resolution. Andi At 01:13 AM 5/2/2001 +, [EMAIL PROTECTED] wrote: ID: 10589 User Update by: [EMAIL PROTECTED] Status: Closed Bug Type: *Install and Config Description: buildconf not compatible with Gnu Libtool 1.4 [root@gecko /root]# cd /usr/src/php4 [root@gecko php4]# ./cvsclean; ./buildconf buildconf: checking installation... buildconf: autoconf version 2.13 (ok) buildconf: automake version 1.4 (ok) build/buildcheck.sh: test: integer expression expected before -ge buildconf: libtool version 1.4 found. You need libtool version 1.3.3 or newer installed to build PHP from CVS. make: *** [buildmk.stamp] Error 1 Previous Comments: --- [2001-05-01 20:43:23] [EMAIL PROTECTED] Works for me just fine. Try doing './cvsclean ; ./buildconf' --jani --- [2001-05-01 15:58:38] [EMAIL PROTECTED] After the problems installing 4.0.5, I got the latest CVS. Running buildconf told me I needed libtool installed. Went to Gnu, got the latest (1.4) and installed it. buildconf now reports: buildconf: libtool version 1.4 found. You need libtool version 1.3.3 or newer installed to build PHP from CVS. make: *** [buildmk.stamp] Error 1 --- Full Bug description available at: http://bugs.php.net/?id=10589 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0 Bug #10589 Updated: buildconf not compatible with Gnu Libtool 1.4
I reopened it :) We just need someone who knows the configure stuff well to accept the patch and commit it to the CVS. Andi At 03:23 PM 5/2/2001 +0200, Jani Taskinen wrote: Because I didn't read the report well enough. I didn't know that libtool 1.4 had been released. :( And now the machine hosting the bug system is down so I can't reopen it.. --Jani On Wed, 2 May 2001, Andi Gutmans wrote: Any idea why the status is 'Closed'? I don't see a resolution. Andi At 01:13 AM 5/2/2001 +, [EMAIL PROTECTED] wrote: ID: 10589 User Update by: [EMAIL PROTECTED] Status: Closed Bug Type: *Install and Config Description: buildconf not compatible with Gnu Libtool 1.4 [root@gecko /root]# cd /usr/src/php4 [root@gecko php4]# ./cvsclean; ./buildconf buildconf: checking installation... buildconf: autoconf version 2.13 (ok) buildconf: automake version 1.4 (ok) build/buildcheck.sh: test: integer expression expected before -ge buildconf: libtool version 1.4 found. You need libtool version 1.3.3 or newer installed to build PHP from CVS. make: *** [buildmk.stamp] Error 1 Previous Comments: --- [2001-05-01 20:43:23] [EMAIL PROTECTED] Works for me just fine. Try doing './cvsclean ; ./buildconf' --jani --- [2001-05-01 15:58:38] [EMAIL PROTECTED] After the problems installing 4.0.5, I got the latest CVS. Running buildconf told me I needed libtool installed. Went to Gnu, got the latest (1.4) and installed it. buildconf now reports: buildconf: libtool version 1.4 found. You need libtool version 1.3.3 or newer installed to build PHP from CVS. make: *** [buildmk.stamp] Error 1 --- Full Bug description available at: http://bugs.php.net/?id=10589 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10609: comments made with # or // in included files cause visible output
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.0.5 PHP Bug Type: Scripting Engine problem Bug description: comments made with # or // in included files cause visible output using PHPnuke files are are often included inside others that are included as well. I had to change all the comments of my THEME.php file (the most internal include) otherwise they would produce output to the page! changing // and # to the /* */ syntax solve the problem! note that this only happens in included files I can easily reproduce it if needed. Only relevalnt to 4.0.5 was warking fine with 4.0.4 -- Edit Bug report at: http://bugs.php.net/?id=10609edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10611: Unrecognized functions
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.0.5 PHP Bug Type: Unknown/Other Function Bug description: Unrecognized functions Since upgrading to 4.0.5 I get this error: Fatal error: Call to undefined function: connection_timeout() in /home/www/common/class.gzip_encode.php on line 158 Please note that it didn't appear always, but I failed to understand which circumstances trigger it. -- Edit Bug report at: http://bugs.php.net/?id=10611edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
On Wed, 2 May 2001, Andi Gutmans wrote: The COM problem would have been found IMO if we had released a bigger RC. I think the COM problem would have been found if somebody ran the test suite immediately before releasing 4.0.5 final. I think modifying the RC process to ensure that the last thing we do before releasing is to make sure the release passes the validation suite is a simpler step than opening the QA process to thousands of less qualified testers. I know the QAT does its best to build and validate the RCs on as many platforms and configurations as possible. But, always adding in new features, to go along with bug fixes, makes it harder to gather all the testers together to review each RC. If we had less RCs or the RCs modified fewer files, it'd be easier to ensure like mistakes like COM don't slip through the cracks. We always have minor buglets in the RCs. It's much easier for the QAT to locate them internally than to wade through all the excess bug reports that will come in. Mozilla makes their daily builds easily available, which is great. OTOH, one of their biggest QA problems is getting people to handle the huge amount of bug reports -- many of which are dups, missing info, or bogus. -adam -- / adam maccabee trachtenberg | visit college life online \ \ [EMAIL PROTECTED] | http://www.student.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
At 09:39 AM 5/2/2001 -0400, Adam Trachtenberg wrote: On Wed, 2 May 2001, Andi Gutmans wrote: The COM problem would have been found IMO if we had released a bigger RC. I think the COM problem would have been found if somebody ran the test suite immediately before releasing 4.0.5 final. I think modifying the RC process to ensure that the last thing we do before releasing is to make sure the release passes the validation suite is a simpler step than opening the QA process to thousands of less qualified testers. The COM isn't in the test suite because it only runs on Windows. In any case, the test suite doesn't catch most problems. It is often tiny bugs which only happen under very certain setups. I know the QAT does its best to build and validate the RCs on as many platforms and configurations as possible. But, always adding in new features, to go along with bug fixes, makes it harder to gather all the testers together to review each RC. If we had less RCs or the RCs modified fewer files, it'd be easier to ensure like mistakes like COM don't slip through the cracks. We always have minor buglets in the RCs. It's much easier for the QAT to locate them internally than to wade through all the excess bug reports that will come in. Mozilla makes their daily builds easily available, which is great. OTOH, one of their biggest QA problems is getting people to handle the huge amount of bug reports -- many of which are dups, missing info, or bogus. Well we can experiment with RC1 of 4.0.6 and see what happens. I think we can only gain from doing this. If there are bug reports that come in which aren't relevant they would come in after the 4.0.6 release anyway. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
On Wed, 2 May 2001, Andi Gutmans wrote: At 04:22 PM 5/2/2001 +0300, Zeev Suraski wrote: I don't see any unusual peak now; We have tons of bug reports all the time. IMHO our problem is no longer lack of QA, but lack of developer resources to fix bugs. I truly think that making RCs effective releases gains nothing. If everyone else thinks differently, so be it. The COM problem would have been found IMO if we had released a bigger RC. That COM problem is Win32 specific. And as Microsoft in it's great wisdom has decided not to include any compilers in their OSs, the lack of binary builds for RCs kinda makes it a bit hard for those who would like to to test to actually test. Or are there binaries build for Winblows of each RC ? Another thing would be great, is that the snapshots of CVS were also found as binaries for Windoze. (Forgive me, I don't do Windows..=) --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
At 03:51 PM 5/2/2001 +0200, Jani Taskinen wrote: On Wed, 2 May 2001, Andi Gutmans wrote: At 04:22 PM 5/2/2001 +0300, Zeev Suraski wrote: I don't see any unusual peak now; We have tons of bug reports all the time. IMHO our problem is no longer lack of QA, but lack of developer resources to fix bugs. I truly think that making RCs effective releases gains nothing. If everyone else thinks differently, so be it. The COM problem would have been found IMO if we had released a bigger RC. That COM problem is Win32 specific. And as Microsoft in it's great wisdom has decided not to include any compilers in their OSs, the lack of binary builds for RCs kinda makes it a bit hard for those who would like to to test to actually test. Or are there binaries build for Winblows of each RC ? Another thing would be great, is that the snapshots of CVS were also found as binaries for Windoze. (Forgive me, I don't do Windows..=) Yes, that would definitely be nice and it used to exist on php4win.de. Hopefully when the site returns it'll start happening again. In any case, this problem isn't Windows or UNIX specific. It's just a question of not having enough people test the RC's. I don't think leaking some RC information to the PHP mailing list is a bad thing :) Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0 Bug #10589 Updated: buildconf not compatiblewith Gnu Libtool 1.4
Sascha is the one who knows this best.. :) And as we're talking about this..shouldn't the libtool bundled with PHP be updated as well? --Jani p.s. What's wrong again with the machine running CVS? On Wed, 2 May 2001, Andi Gutmans wrote: I reopened it :) We just need someone who knows the configure stuff well to accept the patch and commit it to the CVS. Andi At 03:23 PM 5/2/2001 +0200, Jani Taskinen wrote: Because I didn't read the report well enough. I didn't know that libtool 1.4 had been released. :( And now the machine hosting the bug system is down so I can't reopen it.. --Jani On Wed, 2 May 2001, Andi Gutmans wrote: Any idea why the status is 'Closed'? I don't see a resolution. Andi At 01:13 AM 5/2/2001 +, [EMAIL PROTECTED] wrote: ID: 10589 User Update by: [EMAIL PROTECTED] Status: Closed Bug Type: *Install and Config Description: buildconf not compatible with Gnu Libtool 1.4 [root@gecko /root]# cd /usr/src/php4 [root@gecko php4]# ./cvsclean; ./buildconf buildconf: checking installation... buildconf: autoconf version 2.13 (ok) buildconf: automake version 1.4 (ok) build/buildcheck.sh: test: integer expression expected before -ge buildconf: libtool version 1.4 found. You need libtool version 1.3.3 or newer installed to build PHP from CVS. make: *** [buildmk.stamp] Error 1 Previous Comments: --- [2001-05-01 20:43:23] [EMAIL PROTECTED] Works for me just fine. Try doing './cvsclean ; ./buildconf' --jani --- [2001-05-01 15:58:38] [EMAIL PROTECTED] After the problems installing 4.0.5, I got the latest CVS. Running buildconf told me I needed libtool installed. Went to Gnu, got the latest (1.4) and installed it. buildconf now reports: buildconf: libtool version 1.4 found. You need libtool version 1.3.3 or newer installed to build PHP from CVS. make: *** [buildmk.stamp] Error 1 --- Full Bug description available at: http://bugs.php.net/?id=10589 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0 Bug #10589 Updated: buildconf not compatible with Gnu Libtool 1.4
At 03:58 PM 5/2/2001 +0200, Jani Taskinen wrote: Sascha is the one who knows this best.. :) Yep. AFAIK And as we're talking about this..shouldn't the libtool bundled with PHP be updated as well? Don't know. What is the gain? (besides a 4.0.6pl1 :) p.s. What's wrong again with the machine running CVS? It should be OK now. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
We're going to have a Windows build machine at Zend, that will have automated builds (it's actually quite around the corner now). Once it's ready, we're going to have daily snapshots as well as RC builds all the time. Zeev At 16:51 2/5/2001, Jani Taskinen wrote: On Wed, 2 May 2001, Andi Gutmans wrote: At 04:22 PM 5/2/2001 +0300, Zeev Suraski wrote: I don't see any unusual peak now; We have tons of bug reports all the time. IMHO our problem is no longer lack of QA, but lack of developer resources to fix bugs. I truly think that making RCs effective releases gains nothing. If everyone else thinks differently, so be it. The COM problem would have been found IMO if we had released a bigger RC. That COM problem is Win32 specific. And as Microsoft in it's great wisdom has decided not to include any compilers in their OSs, the lack of binary builds for RCs kinda makes it a bit hard for those who would like to to test to actually test. Or are there binaries build for Winblows of each RC ? Another thing would be great, is that the snapshots of CVS were also found as binaries for Windoze. (Forgive me, I don't do Windows..=) --Jani -- PHP Quality Assurance Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
On Wed, 2 May 2001, Andi Gutmans wrote: Or are there binaries build for Winblows of each RC ? Another thing would be great, is that the snapshots of CVS were also found as binaries for Windoze. Yes, that would definitely be nice and it used to exist on php4win.de. Hopefully when the site returns it'll start happening again. Excuse me my stupidity, but why should it be their job to deliver these? IMO we should be providing them. Or is setting up some Windows machine to build them so hard? (I don't know shit about compiling on Windows :) I don't think leaking some RC information to the PHP mailing list is a bad thing :) The RC should also be announced on www.php.net as news item. With both Win32 binary and sources to be dowloaded there. --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
At 04:07 PM 5/2/2001 +0200, Jani Taskinen wrote: On Wed, 2 May 2001, Andi Gutmans wrote: Or are there binaries build for Winblows of each RC ? Another thing would be great, is that the snapshots of CVS were also found as binaries for Windoze. Yes, that would definitely be nice and it used to exist on php4win.de. Hopefully when the site returns it'll start happening again. Excuse me my stupidity, but why should it be their job to deliver these? IMO we should be providing them. Or is setting up some Windows machine to build them so hard? (I don't know shit about compiling on Windows :) Well we'll get one up and running at Zend. I don't think leaking some RC information to the PHP mailing list is a bad thing :) The RC should also be announced on www.php.net as news item. With both Win32 binary and sources to be dowloaded there. I think it's enough to announce it on the PHP mailing list with a short explanation of what RC means. We don't want the whole world to download the RC. Andi Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.0.6 (fwd)
The question is, if you think people will actually download the RC in order to test it (as opposed to using it) - why won't they join the QA team? At 17:11 2/5/2001, Sascha Schumann wrote: As I said, I don't think it's a big deal, but I think it will only have slight negative impact, and even slighter positive impact. I believe that people who are willing to download RC's and test them as such (i.e., send detailed and informative bug reports, or even positive summaries) would join the QA team. The ones will reach by announcing it on php-general/php.net/freshmeat are essentially people that will regard them as releases, and are likely to put them on production servers. Well, yeah. Lots of people in companies actually have test-servers with installations of their software where things can break without affecting any users. I'm not sure that we reach those users with our current QA process. But we might be able to do that by planting announcements on freshmeat.net-like sites. - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- PHP Quality Assurance Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
At 17:07 2/5/2001, Jani Taskinen wrote: On Wed, 2 May 2001, Andi Gutmans wrote: Yes, that would definitely be nice and it used to exist on php4win.de. Hopefully when the site returns it'll start happening again. Excuse me my stupidity, but why should it be their job to deliver these? IMO we should be providing them. Or is setting up some Windows machine to build them so hard? (I don't know shit about compiling on Windows :) Well, that's just the way things usually work; If you can donate something, you do it... Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.0.6 (fwd)
On Wed, 2 May 2001, Zeev Suraski wrote: The question is, if you think people will actually download the RC in order to test it (as opposed to using it) - why won't they join the QA team? Their job description might list test new software releases before putting them into production, and not join the PHP QA team. Joining the QA team for downloading a simple pre-release sounds a bit too much bureaucratic. And just to give an example. In the past, I've installed various pre-releases of the Linux kernel. If something broke, I reported it. But I don't think I would have ever joined a Linux QA team. Enabling more people to test RCs on a wider range of systems will hopefully produce more feedback and hence increase the quality of the release process. - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.0.6 (fwd)
At 17:29 2/5/2001, Sascha Schumann wrote: On Wed, 2 May 2001, Zeev Suraski wrote: The question is, if you think people will actually download the RC in order to test it (as opposed to using it) - why won't they join the QA team? Their job description might list test new software releases before putting them into production, and not join the PHP QA team. Testing new software releases before putting them into production is pretty much a one sentence description of what 'Quality Assurance' is. Joining the QA team for downloading a simple pre-release sounds a bit too much bureaucratic. And just to give an example. In the past, I've installed various pre-releases of the Linux kernel. If something broke, I reported it. But I don't think I would have ever joined a Linux QA team. Enabling more people to test RCs on a wider range of systems will hopefully produce more feedback and hence increase the quality of the release process. I don't seem to recall Linux publishing far-reaching announcements about -pre versions. If you walked around the development mailing lists or the behind-the-scene web sites, you could hear about it, much like you can with PHP today. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] RE: Bug #10581 Updated: signal 6 when starting server
If you get this message more than once, sorry I seem to be having problems getting any messages through today. Sorry, seems there was a core file, and since there was (and you didn't give me any choice) I went ahead and recompiled with debug and installed gdb and generated a backtrace. Here it is: (gdb) bt #0 0xef114d1c in __sigprocmask () from /usr/lib/libthread.so.1 #1 0xef10ba44 in _resetsig () from /usr/lib/libthread.so.1 #2 0xef10b18c in _sigon () from /usr/lib/libthread.so.1 #3 0xef10dfe0 in _thrp_kill () from /usr/lib/libthread.so.1 #4 0xef07a5d8 in abort () from /usr/lib/libc.so.1 #5 0xee56cacc in ts_resource_read () at zend_ini_scanner_cc.cc:1695 #6 0xee56c7e0 in ts_resource_ex () at zend_ini_scanner_cc.cc:1695 #7 0xee4b8684 in php4_init () at zend_ini_scanner_cc.cc:1695 #8 0xef6624e0 in __0Fafunc_native_pool_wait_workPFP6GpblockP6HSessionP6HRequest_iUiP6GpblockP 6HSessionP6HRequest () from /export/home1/netscape/bin/https/lib/libns-httpd40.so #9 0xef661b80 in __0FNfunc_exec_strP6KFuncStructP6GpblockP6HSessionP6HRequest () from /export/home1/netscape/bin/https/lib/libns-httpd40.so #10 0xef661e2c in INTfunc_exec () from /export/home1/netscape/bin/https/lib/libns-httpd40.so #11 0xef65f974 in INTconf_run_init_functions () from /export/home1/netscape/bin/https/lib/libns-httpd40.so #12 0x2eacc in __0FLmagnus_initP6KPRFileDescPCc () #13 0x2f204 in main () (gdb) -Original Message- From: Anil Madhavapeddy [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 01, 2001 7:55 PM To: Faine, Mark Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] RE: Bug #10581 Updated: signal 6 when starting server Without more information it's pretty impossible to solve (I don't have access to an iPlanet installation at the moment). Can anyone else look at the problem with iPlanet 4.x? Otherwise you'll have to try to dive in yourself, Mark. Did it work with an older version of PHP? Try looking at the SAPI code differences and see if you can spot what's changed to break it. Anil - Original Message - From: Faine, Mark [EMAIL PROTECTED] To: 'Bug Database' [EMAIL PROTECTED] Sent: Tuesday, May 01, 2001 8:29 PM Subject: [PHP-DEV] RE: Bug #10581 Updated: signal 6 when starting server It's possible but it wouldn't be easy, for one I don't have gdb installed, AFAIK it doesn't come with Solaris so I'd have to install it. Also, I compiled with --disable-debug. Then there the fact there is no core file and I don't even know if I could get any kind of information from iPlanet even if I recompiled and installed gdb. -Mark -Original Message- From: Bug Database [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 01, 2001 2:20 PM To: [EMAIL PROTECTED] Subject: Bug #10581 Updated: signal 6 when starting server ID: 10581 Updated by: avsm Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: iPlanet related PHP Version: 4.0.5 Assigned To: Comments: Hmm, need backtraces from gdb to show where things are going wrong ... is that possible? (not sure if you can get get debugging symbols from iPlanet) Previous Comments: -- - [2001-05-01 15:16:28] [EMAIL PROTECTED] User Feedback: Yes, that was the first thing I tried, the server will start with these changes but will timeout on every page, even non-php pages. No page will load. It's Netscape iPlanet Server 4.0 SP5 -- - [2001-05-01 15:00:30] [EMAIL PROTECTED] Have you tried these entries in obj.conf ? Init fn=load-modules shlib=/path/to/server4/bin/libphp4.so funcs=php4_init,php4_close,php4_execute,php4_auth_trans Init fn=php4_init LateInit=yes These fix a library loading problem; if it doesn't fix yours, then we have to keep on searching. Incidentally, what version of iPlanet are you running? -- - [2001-05-01 14:47:28] [EMAIL PROTECTED] My bug is exactly the same as Bug id #10012, except for my OS/PHP/Web server version differences. I am getting exactly the same error. I have set everything up correctly as stated in: http://www.php.net/manual/en/install.netscape-enterprise.php Error Message follows: Status: [https-bc_devel]: start failed. (2: unknown early startup error) [https-bc_devel]: server terminated (signal 6): watchdog is restarting it [https-bc_devel]: failure: server initialization failed Error An error occurred during startup. The server https-bc_devel was not started. Return to process control Also, I don't even get that much when I try to start from the console. I get no error message at all, logs don't even say what the problem was? Strange. This is still not working, I'd go back to 4.0.4 pl1 but it's got it's own problems. Anybody? -- - [2001-05-01 11:43:56] [EMAIL
[PHP-DEV] PHP 4.0 Bug #10581 Updated: signal 6 when starting server
ID: 10581 User Update by: [EMAIL PROTECTED] Old-Status: Feedback Status: Open Bug Type: iPlanet related Description: signal 6 when starting server If this shows up more than once, I'm sorry, it seems I'm having trouble getting any messages through today. Sorry, seems there was a core file, and since there was (and you didn't give me any choice) I went ahead and recompiled with debug and installed gdb and generated a backtrace. Here it is: (gdb) bt #0 0xef114d1c in __sigprocmask () from /usr/lib/libthread.so.1 #1 0xef10ba44 in _resetsig () from /usr/lib/libthread.so.1 #2 0xef10b18c in _sigon () from /usr/lib/libthread.so.1 #3 0xef10dfe0 in _thrp_kill () from /usr/lib/libthread.so.1 #4 0xef07a5d8 in abort () from /usr/lib/libc.so.1 #5 0xee56cacc in ts_resource_read () at zend_ini_scanner_cc.cc:1695 #6 0xee56c7e0 in ts_resource_ex () at zend_ini_scanner_cc.cc:1695 #7 0xee4b8684 in php4_init () at zend_ini_scanner_cc.cc:1695 #8 0xef6624e0 in __0Fafunc_native_pool_wait_workPFP6GpblockP6HSessionP6HRequest_iUiP6GpblockP6HSessionP6HRequest () from /export/home1/netscape/bin/https/lib/libns-httpd40.so #9 0xef661b80 in __0FNfunc_exec_strP6KFuncStructP6GpblockP6HSessionP6HRequest () from /export/home1/netscape/bin/https/lib/libns-httpd40.so #10 0xef661e2c in INTfunc_exec () from /export/home1/netscape/bin/https/lib/libns-httpd40.so #11 0xef65f974 in INTconf_run_init_functions () from /export/home1/netscape/bin/https/lib/libns-httpd40.so #12 0x2eacc in __0FLmagnus_initP6KPRFileDescPCc () #13 0x2f204 in main () (gdb) Previous Comments: --- [2001-05-01 15:19:54] [EMAIL PROTECTED] Hmm, need backtraces from gdb to show where things are going wrong ... is that possible? (not sure if you can get get debugging symbols from iPlanet) --- [2001-05-01 15:16:28] [EMAIL PROTECTED] User Feedback: Yes, that was the first thing I tried, the server will start with these changes but will timeout on every page, even non-php pages. No page will load. It's Netscape iPlanet Server 4.0 SP5 --- [2001-05-01 15:00:30] [EMAIL PROTECTED] Have you tried these entries in obj.conf ? Init fn=load-modules shlib=/path/to/server4/bin/libphp4.so funcs=php4_init,php4_close,php4_execute,php4_auth_trans Init fn=php4_init LateInit=yes These fix a library loading problem; if it doesn't fix yours, then we have to keep on searching. Incidentally, what version of iPlanet are you running? --- [2001-05-01 14:47:28] [EMAIL PROTECTED] My bug is exactly the same as Bug id #10012, except for my OS/PHP/Web server version differences. I am getting exactly the same error. I have set everything up correctly as stated in: http://www.php.net/manual/en/install.netscape-enterprise.php Error Message follows: Status: [https-bc_devel]: start failed. (2: unknown early startup error) [https-bc_devel]: server terminated (signal 6): watchdog is restarting it [https-bc_devel]: failure: server initialization failed Error An error occurred during startup. The server https-bc_devel was not started. Return to process control Also, I don't even get that much when I try to start from the console. I get no error message at all, logs don't even say what the problem was? Strange. This is still not working, I'd go back to 4.0.4 pl1 but it's got it's own problems. Anybody? --- [2001-05-01 11:43:56] [EMAIL PROTECTED] My bug is exactly the same as Bug id #10012, except for my OS/PHP/Web server version differences. I am getting exactly the same error. I have set everything up correctly as stated in: http://www.php.net/manual/en/install.netscape-enterprise.php Error Message follows: Status: [https-bc_devel]: start failed. (2: unknown early startup error) [https-bc_devel]: server terminated (signal 6): watchdog is restarting it [https-bc_devel]: failure: server initialization failed Error An error occurred during startup. The server https-bc_devel was not started. Return to process control Also, I don't even get that much when I try to start from the console. I get no error message at all, logs don't even say what the problem was? Strange. --- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. Full Bug description available at: http://bugs.php.net/?id=10581 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators,
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.0.6 (fwd)
Their job description might list test new software releases before putting them into production, and not join the PHP QA team. Testing new software releases before putting them into production is pretty much a one sentence description of what 'Quality Assurance' is. The main point here is that I think lowering the barrier is good and is more likely to produce good end results. I don't seem to recall Linux publishing far-reaching announcements about -pre versions. If you walked around the development mailing lists or the behind-the-scene web sites, you could hear about it, much like you can with PHP today. 10 announcements for the 2.2.19pre branch: http://freshmeat.net/branches/12527/ The same amount of 2.4-testing http://freshmeat.net/branches/12570/ - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
On 2001-05-02 15:03:50, Zeev Suraski [EMAIL PROTECTED] wrote: We're going to have a Windows build machine at Zend, that will have automated builds (it's actually quite around the corner now). Once it's ready, we're going to have daily snapshots as well as RC builds all the time. That's good news; the cygwin test suite suggestion is probably still valid though. --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
On 2001-05-02 14:51:53, Jani Taskinen [EMAIL PROTECTED] wrote: That COM problem is Win32 specific. And as Microsoft in it's great wisdom has decided not to include any compilers in their OSs, the lack of binary builds for RCs kinda makes it a bit hard for those who would like to to test to actually test. What would be great is a cross-compiler based on the cygwin package that would allow the developers to build win32 versions without having to have access to a win32 platform. That way they could at least test to make sure that it builds. Couple that with VMWare and you're flying :-) Seriously though, win32 is particular hard to do automated testing. Maybe we could use cygwin for running the test-suite under win32 and at least be able to use standard *nix tools? I haven't really looked at the test-suite, so this is just a (hopefully) helpful suggestion. --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.0.6 (fwd)
At 05:34 PM 5/2/2001 +0300, Zeev Suraski wrote: I don't seem to recall Linux publishing far-reaching announcements about -pre versions. If you walked around the development mailing lists or the behind-the-scene web sites, you could hear about it, much like you can with PHP today. Linux kernel pre-releases are usually publicized and easily downloadable. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.0.6 (fwd)
On Wed, 2 May 2001, Zeev Suraski wrote: At 17:29 2/5/2001, Sascha Schumann wrote: On Wed, 2 May 2001, Zeev Suraski wrote: Their job description might list test new software releases before putting them into production, and not join the PHP QA team. Testing new software releases before putting them into production is pretty much a one sentence description of what 'Quality Assurance' is. I would rather describe QA as Making sure the release does have as least bugs as possible. IMO this is different then just testing RC's. I think a QA team should be the team who says Yes, release it or No, there are still some bugs left we want to fix. Of course, in order to do this, they need to test RC's. Derick Rethans - PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED] SRM: Site Resource Manager - www.vl-srm.net - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
At 03:38 PM 5/2/2001 +0100, Wez Furlong wrote: On 2001-05-02 14:51:53, Jani Taskinen [EMAIL PROTECTED] wrote: That COM problem is Win32 specific. And as Microsoft in it's great wisdom has decided not to include any compilers in their OSs, the lack of binary builds for RCs kinda makes it a bit hard for those who would like to to test to actually test. What would be great is a cross-compiler based on the cygwin package that would allow the developers to build win32 versions without having to have access to a win32 platform. That way they could at least test to make sure that it builds. Couple that with VMWare and you're flying :-) Seriously though, win32 is particular hard to do automated testing. Maybe we could use cygwin for running the test-suite under win32 and at least be able to use standard *nix tools? I haven't really looked at the test-suite, so this is just a (hopefully) helpful suggestion. The nature of PHP on Windows is that it's really best to compile it with Visual C++. It uses native threading support and ISAPI support. I don't think it's a good or feasible idea to move to cygwin. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10565 Updated: mysql_real_connect dumps core, fix included
ID: 10565
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Analyzed
Bug Type: MySQL related
PHP Version: 4.0.4pl1
Assigned To:
Comments:
I had a conversation with Sinisa, this is the outcome. If it isn't true, please
contact the MySQL team directly. All in all, you said it's a bug in MySQL.
From: Sinisa Milivojevic [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: mysql_real_connect dumps core
Cynic writes:
no, the patch was (probably) generated with diff -c. read:
- mysql_init(mysql);
---
+ mysql = mysql_init(NULL);
MYSQL *mysql = (MYSQL *)NULL;
mysql = mysql_init(mysql);
mysql_real_connect(mysql,...
must work on any system with 3.23 client API.
Regards,
Sinisa
__ _ _ ___ == MySQL AB
/*/\*\/\*\ /*/ \*\ /*/ \*\ |*| Sinisa Milivojevic
/*/ /*/ /*/ \*\_ |*| |*||*| mailto:[EMAIL PROTECTED]
/*/ /*/ /*/\*\/*/ \*\|*| |*||*| Larnaca, Cyprus
/*/ /*/ /*/\*\_/*/ \*\_/*/ |*|
/*/^^^\*\^^^
/*/ \*\Developers Team
Previous Comments:
---
[2001-05-02 06:59:39] [EMAIL PROTECTED]
mailed MySQL
---
[2001-04-30 16:57:34] [EMAIL PROTECTED]
** This is a problem in MySql. This report provides a code
modification to compensate for the MySql problem. **
Under SCO OpenServer 5.0.6, Apache 1.3.19, PHP 4.0.4 PL 1,
and MySql 3.23.36 (precompiled MySQL for OpenServer 5.0.x),
calls to mysql_real_connect will silently dump core if
mysql_init was not allowed to *allocate* the memory for the
MySQL structure.
To function properly, mysql_init must be passed NULL, thus
allowing it to allocate and manage the memory. If you use
a previously malloc()'ed or static structure, MySQL will
dump core on connect.
We find this problem to be present in MySQL, and can
duplicate it using a C code stub. The problem, of course,
also exists in PHP, causing a core dump there as well,
since PHP pre-malloc()'s its own structure.
Here is a DIFF for ext/mysql/php_mysql.c which fixes the
problem for us. It's ugly, and hack-y, but it works. FYI.
198c198
efree(link);
---
/* efree(link); */
456c456
mysql = (MYSQL *) malloc(sizeof(MYSQL));
---
/* mysql = (MYSQL *) malloc(sizeof(MYSQL)); */
458c458
mysql_init(mysql);
---
mysql = mysql_init(NULL);
542c542
mysql = (MYSQL *) emalloc(sizeof(MYSQL));
---
/* mysql = (MYSQL *) emalloc(sizeof(MYSQL)); */
544c544
mysql_init(mysql);
---
mysql = mysql_init(NULL);
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10565edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.0.6 (fwd)
Okay guys, do whatever you want. Most people seem to agree with you. Zeev At 17:42 2/5/2001, Andi Gutmans wrote: At 05:34 PM 5/2/2001 +0300, Zeev Suraski wrote: I don't seem to recall Linux publishing far-reaching announcements about -pre versions. If you walked around the development mailing lists or the behind-the-scene web sites, you could hear about it, much like you can with PHP today. Linux kernel pre-releases are usually publicized and easily downloadable. Andi -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.0.6 (fwd)
I would rather describe QA as Making sure the release does have as least bugs as possible. IMO this is different then just testing RC's. I think a QA team should be the team who says Yes, release it or No, there are still some bugs left we want to fix. Of course, in order to do this, they need to test RC's. Yes, the QA team might consider feedback from outsiders who have configurations which are not in wide deployment or not available to the QA team. Additionally, real-life scripts tend to stress PHP in ways no imaginable test framework can, so we get another dimension of pre-release testing. - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.0.6 (fwd)
Zeev Suraski wrote: Testing new software releases before putting them into production is pretty much a one sentence description of what 'Quality Assurance' is. that's QA for their products usually and not so much for 3rd party components I don't seem to recall Linux publishing far-reaching announcements about -pre versions. If you walked around the development mailing lists or the behind-the-scene web sites, you could hear about it, much like you can with PHP today. o come on, all those 2.x.yPREz and .ACn announcements on freshmeat.net are not far-reaching? that's ridiculous! -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10612: error connecting to database
From: [EMAIL PROTECTED] Operating system: Linux6.2 PHP version: 4.0.5 PHP Bug Type: *Install and Config Bug description: error connecting to database I upgraded from php-4.0.3pl1 to 4.0.5 as a DSO in apache and now php cannot connect to MySQL database Warning: MySQL Connection Failed: Can't connect to local MySQL server through socket '/tmp/mysql.sock' (111) in /httpd/sites/55lo/html/mainfile.php on line 17 Unable to select database what have I done -- Edit Bug report at: http://bugs.php.net/?id=10612edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10613: No doc on the session properties in the configuration file
From: [EMAIL PROTECTED] Operating system: Win32 PHP version: 4.0.5 PHP Bug Type: Documentation problem Bug description: No doc on the session properties in the configuration file The chapter which describes all the properties of the php.ini is not complete. There is no help with the session properties. -- Edit Bug report at: http://bugs.php.net/?id=10613edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: Bug #10561 Updated: sockets.c uses `SUN_LEN' unconditionally - undefined on Solaris
Have you tried 4.0.5 as I think this is fixed in it. Also, you don't need to set those CPPFLAGS anymore. It looks like sockets.c has been fixed, but pdf.c has been broken on the way :-( pdf.c, line 2704: prototype mismatch: 3 args passed, 2 expected 2702 PDF_close_pdi_page(pdf, 2703 Z_LVAL_PP(arg2)-PDFLIB_PDI_OFFSET, 2704 Z_LVAL_PP(arg3)-PDFLIB_IMAGE_OFFSET); pdflib 4.0.0 has a two-argument PDF_close_pdi_page, 3.0 hasn't got one at all. Time for another bug report. Rob -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10613 Updated: No doc on the session properties in the configuration file
ID: 10613 Updated by: hholzgra Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: Documentation problem PHP Version: 4.0.5 Assigned To: Comments: theese are described on the introduction page of the session functions reference as these are belonging to the session extension Previous Comments: --- [2001-05-02 10:56:24] [EMAIL PROTECTED] The chapter which describes all the properties of the php.ini is not complete. There is no help with the session properties. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10613edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: Bug #10561 Updated: sockets.c uses `SUN_LEN' unconditionally - undefined on Solaris
Have you tried 4.0.5 as I think this is fixed in it. Also, you don't need to set those CPPFLAGS anymore. It looks like sockets.c has been fixed, but pdf.c has been broken on the way :-( Ignore me. I was trying to use the pdf module that came with php, instead of replacing it with the one that came from pdflib. Sorry for the confusion. Rob -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
On 2001-05-02 15:43:57, Andi Gutmans [EMAIL PROTECTED] wrote: At 03:38 PM 5/2/2001 +0100, Wez Furlong wrote: Seriously though, win32 is particular hard to do automated testing. Maybe we could use cygwin for running the test-suite under win32 and at least be able to use standard *nix tools? The nature of PHP on Windows is that it's really best to compile it with Visual C++. It uses native threading support and ISAPI support. I don't think it's a good or feasible idea to move to cygwin. I agree about the compiling part, but cygwin isn't just a compiler - you get bash, sed, perl, awk and all those unix tools. I'm suggesting that perhaps the test suite could be run using those tools on a win32 platform. --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
On 2001-05-02 15:03:50, Zeev Suraski [EMAIL PROTECTED] wrote: We're going to have a Windows build machine at Zend, that will have automated builds (it's actually quite around the corner now). Once it's ready, we're going to have daily snapshots as well as RC builds all the time. That's good news; the cygwin test suite suggestion is probably still valid though. Another thing would be to branch into Borland C++, as thats also a strong windows based compiler, it opens compilation to a lot more people. I have to say, being able to download a prebuilt windows version would be good, heres a number of reasons why.. #1 What if the problem was with the MS VC++ on the machine that built it, rather than the actual code? #2 It does mean that for people like me who have access to Vis Studio but are not so familiar with it for whatever reason we can just download and test #3 Most people have access to a windows machine, thus opening for more of the people prepared to do proper QA to have a check on the windows stuff Liz -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10614: make fails
From: [EMAIL PROTECTED] Operating system: Mandrake 8.0 PHP version: 4.0.5 PHP Bug Type: *Install and Config Bug description: make fails I was following the instructions on devshed to install php and when i ran make it went a while then drops given this: /bin/sh ../libtool --silent --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../main -DSUPPORT_UTF8 -DXML_BYTE_ORDER=12 -g -02 -c zend_hash.c zend_hash.c: In function `zend_hash_minmax': zend_hash.c:1233: Internal error: Segmentation fault. Please submit a full bug report. make[1]: *** [zend_hash.lo] Error 1 make[1]: Leaving directory `/tmp/download/php-4.0.5/Zend' make: *** [all-recursive] Error 1 Any ideas? Am I doing something wrong? -- Edit Bug report at: http://bugs.php.net/?id=10614edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10615: JPEG size info not properly returned on unmodified JPEG images from digicam
From: [EMAIL PROTECTED] Operating system: Linux 2.4.4 (Redhat 7.0) PHP version: 4.0.5 PHP Bug Type: GetImageSize related Bug description: JPEG size info not properly returned on unmodified JPEG images from digicam Issue noted in 4.0.5 and 4.0.6-dev. Currently running 4.0.6-dev Location where issue can be viewed. http://pictures.ourjohnsonfamily.com/2001/april%2014,%202001%20-%20easter%20eve%20and%20prego%20pics/ On demo page - thumbnails in left frame should display image dimensions. Since 4.0.5, image info is only obtainable if image file has been modified in any way. If images have been pulled straight from digicam, information cannot be displayed. Script source can be viewed here: http://www.htmlspinnr.org/photodisplay.phps Find function GetDimension, this is where GetImageSize is called. Function worked properly in 4.0.4pl1, so I'm not blaming code. configure string: ./configure '--prefix=/usr' '--with-mysql=/usr' '--with-apxs' '--sysconfdir=/etc' '--with-config-file-path=/etc' '--enable-inline-optimization' '--enable-ftp' '--enable-ssl' '--enable-imap' '--with-gd' '--with-gd-dir=/usr/lib' '--with-jpeg' '--with-png' '--with-jpeg-dir' '--with-png-dir' '--with-freetype-dir=/usr/local/lib' '--enable-gd-native-ttf' other runtime info (incl. compile string, etc.) http://www.ourjohnsonfamily.com/info.php ( a file containing ? PHP_INFO ?) -- Edit Bug report at: http://bugs.php.net/?id=10615edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Sybase Patch. Could someone review it please? it is small. (Zeev? Joey?)
Hi, there. Sorry for picking your names, Zeev and Joey, but Zeev is listed as a maintainer, and Joey has assigned this particular bug to himself. I have been trying to find someone to look at the patch, see if you like it, and apply it (I do not have the karma myself), or tell me what you don't like. But nobody seemed to respond:( I posted the patch in the bug description of bug 8126. http://bugs.php.net/?id=8126 Thanks, Vlad Re-thinking the Web on a SinglePage(TM) http://www.echospace.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10614 Updated: make fails
ID: 10614 Updated by: hholzgra Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: *Install and Config PHP Version: 4.0.5 Assigned To: Comments: Do you get the same error in the same place when you run again? The only reasons that made gcc bail out with a segmentation fault during compilation i came across within years were faulty ram and overheated CPUs In this case you will experience segfaults from gcc in random places, typing make again and again finally gets you through the process (although you should not trust the result) Previous Comments: --- [2001-05-02 12:51:03] [EMAIL PROTECTED] I was following the instructions on devshed to install php and when i ran make it went a while then drops given this: /bin/sh ../libtool --silent --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../main -DSUPPORT_UTF8 -DXML_BYTE_ORDER=12 -g -02 -c zend_hash.c zend_hash.c: In function `zend_hash_minmax': zend_hash.c:1233: Internal error: Segmentation fault. Please submit a full bug report. make[1]: *** [zend_hash.lo] Error 1 make[1]: Leaving directory `/tmp/download/php-4.0.5/Zend' make: *** [all-recursive] Error 1 Any ideas? Am I doing something wrong? --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10614edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
Wez; Is there another test suite other than the run-test.php script? (Which does run on Win32: TEST RESULT SUMMARY = Number of tests: 165 Tests skipped: 66 ( 40%) Tests failed: 22 ( 22%) Tests passed: 77 ( 78%) = Skipped 0 extensions. V:\php-4.0.5RC8 ) - Matt Wez Furlong [EMAIL PROTECTED] 05/02/01 12:02PM On 2001-05-02 15:43:57, Andi Gutmans [EMAIL PROTECTED] wrote: At 03:38 PM 5/2/2001 +0100, Wez Furlong wrote: Seriously though, win32 is particular hard to do automated testing. Maybe we could use cygwin for running the test-suite under win32 and at least be able to use standard *nix tools? The nature of PHP on Windows is that it's really best to compile it with Visual C++. It uses native threading support and ISAPI support. I don't think it's a good or feasible idea to move to cygwin. I agree about the compiling part, but cygwin isn't just a compiler - you get bash, sed, perl, awk and all those unix tools. I'm suggesting that perhaps the test suite could be run using those tools on a win32 platform. --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: Bug #9448 Updated: It does not works / -cpath Look for php.ini file in this directory
Indeed does not give an error but it does not work, just hung-up
#!/usr/bin/php -c /home/marcello -q
?
echo "test";
?>
where a php.ini file reside in /home/marcello and another in /usr/local/lib
Marcello
Bug Database wrote:
ID: 9448
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: *Install and Config
PHP Version: 4.0.4pl1
Assigned To:
Comments:
You need to use a space between the -c and the path. That gives no error
to me. The -h output reflects this in the upcoming PHP 4.0.5
Derick
Previous Comments:
---
[2001-02-25 17:13:10] [EMAIL PROTECTED]
I use php with apache, in the same time a crontab generate big html
page from a .php source file.
#/usr/bin/php -q
?
...
?>
, but if I use -c/usr/local/newphp to force the read of another php.ini
file just for the cgi and different from the one used with php/apache it
gives an error.
php -?
Usage: php [-q] [-h] [-s] [-v] [-i] [-f file>] | {file> [args...]}
-q
Quiet-mode. Suppress HTTP Header output.
-s
Display colour syntax highlighted source.
-ffile> Parse file>.
Implies `-q'
-v
Version number
-cpath> Look for php.ini
file in this directory
-a
Run interactively
-d foo[=bar] Define INI entry foo with value 'bar'
-e
Generate extended information for debugger/profiler
-zfile> Load Zend extension
file>.
-i
PHP information
-h
This help
-c is in the list , but not in the Usage , it should be nice to have
diferent php.ini depending on scripts, excpecialy because zend optimizer
works for the php/apache and not for cgi php (logically).
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9448edit=2
[PHP-DEV] PHP 4.0 Bug #10614 Updated: make fails
ID: 10614 User Update by: [EMAIL PROTECTED] Old-Status: Feedback Status: Open Bug Type: *Install and Config Description: make fails Hmm that may have been it I ran it again and it worked.. thanks for the help.. Previous Comments: --- [2001-05-02 13:07:59] [EMAIL PROTECTED] Do you get the same error in the same place when you run again? The only reasons that made gcc bail out with a segmentation fault during compilation i came across within years were faulty ram and overheated CPUs In this case you will experience segfaults from gcc in random places, typing make again and again finally gets you through the process (although you should not trust the result) --- [2001-05-02 12:51:03] [EMAIL PROTECTED] I was following the instructions on devshed to install php and when i ran make it went a while then drops given this: /bin/sh ../libtool --silent --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../main -DSUPPORT_UTF8 -DXML_BYTE_ORDER=12 -g -02 -c zend_hash.c zend_hash.c: In function `zend_hash_minmax': zend_hash.c:1233: Internal error: Segmentation fault. Please submit a full bug report. make[1]: *** [zend_hash.lo] Error 1 make[1]: Leaving directory `/tmp/download/php-4.0.5/Zend' make: *** [all-recursive] Error 1 Any ideas? Am I doing something wrong? --- Full Bug description available at: http://bugs.php.net/?id=10614 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Sybase Patch. Could someone review it please? it is small. (Zeev? Joey?)
Can you please send the .diff as an attachment so that I can apply it easily? I'll apply it (I hope it's OK :) Andi At 10:05 AM 5/2/2001 -0700, PHP development @echospace wrote: Hi, there. Sorry for picking your names, Zeev and Joey, but Zeev is listed as a maintainer, and Joey has assigned this particular bug to himself. I have been trying to find someone to look at the patch, see if you like it, and apply it (I do not have the karma myself), or tell me what you don't like. But nobody seemed to respond:( I posted the patch in the bug description of bug 8126. http://bugs.php.net/?id=8126 Thanks, Vlad Re-thinking the Web on a SinglePage(TM) http://www.echospace.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10614 Updated: make fails
ID: 10614 Updated by: hholzgra Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: *Install and Config PHP Version: 4.0.5 Assigned To: Comments: Previous Comments: --- [2001-05-02 13:07:59] [EMAIL PROTECTED] Do you get the same error in the same place when you run again? The only reasons that made gcc bail out with a segmentation fault during compilation i came across within years were faulty ram and overheated CPUs In this case you will experience segfaults from gcc in random places, typing make again and again finally gets you through the process (although you should not trust the result) --- [2001-05-02 12:51:03] [EMAIL PROTECTED] I was following the instructions on devshed to install php and when i ran make it went a while then drops given this: /bin/sh ../libtool --silent --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../main -DSUPPORT_UTF8 -DXML_BYTE_ORDER=12 -g -02 -c zend_hash.c zend_hash.c: In function `zend_hash_minmax': zend_hash.c:1233: Internal error: Segmentation fault. Please submit a full bug report. make[1]: *** [zend_hash.lo] Error 1 make[1]: Leaving directory `/tmp/download/php-4.0.5/Zend' make: *** [all-recursive] Error 1 Any ideas? Am I doing something wrong? --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10614edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
That COM problem is Win32 specific. And as Microsoft in it's great wisdom has decided not to include any compilers in their OSs, the lack of binary builds for RCs kinda makes it a bit hard for those who would like to to test to actually test. Can anyone make it easy to (via a good tutorial or some dsw) how to build and test php on windows ? If it only were as easy as in *nix :) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
That COM problem is Win32 specific. And as Microsoft in it's great wisdom has decided not to include any compilers in their OSs, the lack of binary builds for RCs kinda makes it a bit hard for those who would like to to test to actually test. Can anyone make it easy to (via a good tutorial or some dsw) how to build and test php on windows ? If it only were as easy as in *nix :) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
On Wed, 2 May 2001, Eduardo Dominguez wrote: That COM problem is Win32 specific. And as Microsoft in it's great wisdom has decided not to include any compilers in their OSs, the lack of binary builds for RCs kinda makes it a bit hard for those who would like to to test to actually test. Can anyone make it easy to (via a good tutorial or some dsw) how to build and test php on windows ? If it only were as easy as in *nix :) http://www.php.net/manual/en/install-windows.php -- alex -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Re: [PHP-QA] 4.0.6
At 04:22 PM 5/2/2001 +0300, Zeev Suraski wrote: I don't see any unusual peak now; We have tons of bug reports all the time. IMHO our problem is no longer lack of QA, but lack of developer resources to fix bugs. I truly think that making RCs effective releases gains nothing. If everyone else thinks differently, so be it. The COM problem would have been found IMO if we had released a bigger RC. Andi The com problem wouldnt be there if 1) Phanto hadnt made such a big patch in RC7 2) He had tested it as I asked him to in an email saying I wouldnt have time to do so. unfortunatly I think this is a problem with the release process only x people should commit to branches these people should be people we trust and any other patch commited to the branch should be reverted until it can be verified by one of the X people (who test it before commiting) - James -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] RE: [PHP-QA] 4.0.6
Andi Gutmans wrote: I think it's enough to announce it on the PHP mailing list with a short explanation of what RC means. We don't want the whole world to download the RC. i would like to spread the news as far as possible Let's take it one step at a time. We should have an RC1 for 4.0.6 soon and we can see how the response from the PHP mailing lists are. That will already reach thousands. I would be very against this.. to me it seems silly, the current QA Team will have to spend 90% of their time running through the (maybe hundreds) of reports rather than testing. It makes more sense to me to try and attract more people who know what they are doing to the QA Team rather than having a fairly (maybe more :)) disorderly group of people testing from people who do not really know what they are doing.. - James -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
Seriously though, win32 is particular hard to do automated testing. Maybe we could use cygwin for running the test-suite under win32 and at least be able to use standard *nix tools? It already does run under windows. - James -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] RE: [PHP-QA] 4.0.6
At 06:34 PM 5/2/2001 +0100, James Moore wrote: Andi Gutmans wrote: I think it's enough to announce it on the PHP mailing list with a short explanation of what RC means. We don't want the whole world to download the RC. i would like to spread the news as far as possible Let's take it one step at a time. We should have an RC1 for 4.0.6 soon and we can see how the response from the PHP mailing lists are. That will already reach thousands. I would be very against this.. to me it seems silly, the current QA Team will have to spend 90% of their time running through the (maybe hundreds) of reports rather than testing. It makes more sense to me to try and attract more people who know what they are doing to the QA Team rather than having a fairly (maybe more :)) disorderly group of people testing from people who do not really know what they are doing.. You have tens of thousands of people testing releases today. What's the difference? Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Imap SSL support (Bug #10330)
Quoting J. Jones [EMAIL PROTECTED]: The imap module fails with the following (perhaps only when building against imap-2000*): php_imap.c: In function `php_minit_imap': php_imap.c:450: `auth_ssl' undeclared (first use in this function) php_imap.c:450: (Each undeclared identifier is reported only once php_imap.c:450: for each function it appears in.) This code branch should only be triggered if HAVE_IMAP_SSL is defined, which should only happen if you configure php --with-imap-ssl. If you're doing so, it's assumed that you've built c-client with SSL support. -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] You will receive an urgent transmission from the Martian government informing you that Mars does not, in fact, need women, so please stop sending them. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10330 Updated: imap-2001.BETA and imap-ssl support in PHP4
ID: 10330 Updated by: chagenbu Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: IMAP related PHP Version: 4.0 Latest CVS (14/04/2001) Assigned To: Comments: The --with-imap-ssl option is only intended for cases when you've compiled c-client with SSL support. Previous Comments: --- [2001-05-02 00:17:00] [EMAIL PROTECTED] It's imap-2001.BETA that is broken here. Use imap-2000. That works just fine. --Jani --- [2001-04-14 23:22:22] [EMAIL PROTECTED] I've built the imap-2001.BETA toolkit with SSL (OpenSSL 0.9.6a) support and copied the c-client header files in a 'standard' location and c-client library files, but when compiling PHP4-cvs --with-imap-ssl support I get the following error: config.nice: ./configure --with-apxs --with-config-file-path=/var/www/conf --with-gdbm --with-gettext --with-imap --with-imap-ssl --with-mysql --with-openssl --with-regex=system --with-zlib --enable-memory-limit --enable-safe-mode --enable-track-vars --enable-bcmath --enable-wddx --enable-xml $ make ... -DTARGET=httpsd -DUSE_HSREGEX -DUSE_EXPAT -DAPACHE_SSL -DSUPPORT_UTF8 -DXML_BYTE_ORDER=12 -g -O2 -c php_imap.c php_imap.c: In function `php_minit_imap': php_imap.c:450: `auth_ssl' undeclared (first use in this function) php_imap.c:450: (Each undeclared identifier is reported only once php_imap.c:450: for each function it appears in.) make[3]: *** [php_imap.lo] Error 1 make[3]: Leaving directory `/home/raul/src/cvs/php4/ext/imap' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/raul/src/cvs/php4/ext/imap' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/raul/src/cvs/php4/ext' make: *** [all-recursive] Error 1 ~/src/imap-2001.BETA.SNAP-0104140025$ cat c-client/linkage.c mail_link (mboxdriver); /* link in the mbox driver */ mail_link (imapdriver); /* link in the imap driver */ mail_link (nntpdriver); /* link in the nntp driver */ mail_link (pop3driver); /* link in the pop3 driver */ mail_link (mhdriver);/* link in the mh driver */ mail_link (mxdriver);/* link in the mx driver */ mail_link (mbxdriver); /* link in the mbx driver */ mail_link (tenexdriver); /* link in the tenex driver */ mail_link (mtxdriver); /* link in the mtx driver */ mail_link (mmdfdriver); /* link in the mmdf driver */ mail_link (unixdriver); /* link in the unix driver */ mail_link (newsdriver); /* link in the news driver */ mail_link (philedriver); /* link in the phile driver */ mail_link (dummydriver); /* link in the dummy driver */ auth_link (auth_md5);/* link in the md5 authenticator */ auth_link (auth_pla);/* link in the pla authenticator */ auth_link (auth_log);/* link in the log authenticator */ ssl_onceonlyinit (); Thank you. Raul --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10330edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] RE: [PHP-QA] 4.0.6
I would be very against this.. to me it seems silly, the current QA Team will have to spend 90% of their time running through the (maybe hundreds) of reports rather than testing. It makes more sense to me to try and attract more people who know what they are doing to the QA Team rather than having a fairly (maybe more :)) disorderly group of people testing from people who do not really know what they are doing.. You have tens of thousands of people testing releases today. What's the difference? The big difference is during a release process is the time scale. There are likley to be more bugs in an RC as well as people reporting bugs more rigerously (As well as probably reporting lots of bogus/dup bugs, which are very tedious to trawl through). If this is to happen (which I dont think it should) then we need to get the people to understand that RC testing is this this and this, not please test our latest RC and send feedback, if you come accross a problem then send the feedback here and here so it can be dealt with, please check the bugs database first etc. If we announce PHP 4.0.6RC1 in X places then people will think oh 4.0.6 is released (remeber PHP users are incapable of reading anything more than about 10 words) lets use that; they then wont bother upgrading when the real 4.0.6 is released. This means we will start to get bug reports saying this isnt working in 4.0.6 when it has been fixed in the RC phase but is still present in the first RC. Everyone seems to be trying to fix the problem the wrong way. IMHO the problem here was with the Release Cycle not the amount of testing. Normally I test RC1 massivly then if there are problems I check for them in later RC's where people have said they have been fixed (or its decided that the bug should be fixed before the release). This time this didnt work for the single reason Phanto was unresposible and commited a huge (700 line commit) to RC7 and DIDNT test it. I asked him (as I asked sascha too) to when we decided to have RC8 (I think I cc'd the list) to test his changes throughly as I would not have time due to real work. Now Phanto obviously didnt do this, maybe someone should have caught it but I feel that by not testing Phanto invalidated a lot of hard work by the rest of the team to make 4.0.6 stable. I am certainly pissed off that this has happened as a lot of people put a lot of work into making sure 4.0.5 was stable and the problem here is not the testing but the developers commiting unneeded stuff to the RC branch. I feel we should only have x people commiting to the branch and if somthing is commited as late as the COM stuff was its up to the developer to test throughly otherwise its their head on the block. and remember the old proverb Too many cooks spoil the broth... - James -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] maybe not a PHP library?
I'm trying to create a minimal module to do some debugging work, but it fails to load. I essentially used ext_skel to create an fresh extension, moved it out of the PHP tree, then did: $ phpize $ ./configure --enable-apdebug $ make # make install The extension is generated OK AFAICT, but it lacks the symbol get_module, which gets me 'PHP Warning: Invalid library (maybe not a PHP library) 'apdebug.so' in Unknown on line 0' in my error log. Any ideas, anyone? Using Apache 1.3.19 and 4.0.4.5rc6 on Debian sid. Emile -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Sybase Patch. Could someone review it please? it is small. (Zeev? Joey?)
Andi,
Patch is attached. When you apply it, please tell me and I'll close related bug
reports (there are a few, and they look different although they are about the same
problem).
Vlad
- Original Message -
From: Andi Gutmans
To: PHP development @echospace ,[EMAIL PROTECTED]
Sent: Wed, 02 May 2001 20:17:50 +0300
Subject: Re: [PHP-DEV] Sybase Patch. Could someone review it please? it is small.
(Zeev? Joey?)
Can you please send the .diff as an attachment so that I can apply it easily?
I'll apply it (I hope it's OK :)
Andi
At 10:05 AM 5/2/2001 -0700, PHP development @echospace wrote:
Hi, there. Sorry for picking your names, Zeev and Joey, but Zeev is
listed as a maintainer, and Joey has assigned this particular bug to
himself. I have been trying to find someone to look at the patch, see if
you like it, and apply it (I do not have the karma myself), or tell me
what you don't like. But nobody seemed to respond:(
I posted the patch in the bug description of bug 8126.
http://bugs.php.net/?id=8126
Thanks,
Vlad
Re-thinking the Web on a SinglePage(TM)
http://www.echospace.com
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re-thinking the Web on a SinglePage(TM)
http://www.echospace.com
diff -urN php-4.0.5-tdsbroken/ext/sybase/config.m4 php-4.0.5/ext/sybase/config.m4
--- php-4.0.5-tdsbroken/ext/sybase/config.m4Mon May 1 21:27:02 2000
+++ php-4.0.5/ext/sybase/config.m4 Tue May 1 16:28:14 2001
@@ -21,4 +21,8 @@
AC_DEFINE(HAVE_LIBDNET_STUB,1,[ ])
])
AC_DEFINE(HAVE_SYBASE,1,[ ])
+ AC_CHECK_LIB(sybdb, tdsdbopen,
+ [ AC_DEFINE(PHP_SYBASE_DBOPEN,tdsdbopen,[ ])
+ AC_DEFINE(DBMFIX,1,[ ]) ],
+ [ AC_DEFINE(PHP_SYBASE_DBOPEN,dbopen,[ ]) ])
fi
diff -urN php-4.0.5-tdsbroken/ext/sybase/php_sybase_db.c
php-4.0.5/ext/sybase/php_sybase_db.c
--- php-4.0.5-tdsbroken/ext/sybase/php_sybase_db.c Sun Feb 25 22:07:24 2001
+++ php-4.0.5/ext/sybase/php_sybase_db.cTue May 1 15:42:54 2001
@@ -379,7 +379,7 @@
RETURN_FALSE;
}
/* create the link */
- if ((sybase.link=dbopen(sybase.login,host))==FAIL) {
+ if ((sybase.link=PHP_SYBASE_DBOPEN(sybase.login,host))==FAIL) {
/*php_error(E_WARNING,Sybase: Unable to connect to
server: %s,sybase_error(sybase));*/
efree(hashed_details);
dbloginfree(sybase.login);
@@ -415,7 +415,7 @@
sybase_ptr = (sybase_link *) le-ptr;
/* test that the link hasn't died */
if (DBDEAD(sybase_ptr-link)==TRUE) {
- if
((sybase_ptr-link=dbopen(sybase_ptr-login,host))==FAIL) {
+ if
+((sybase_ptr-link=PHP_SYBASE_DBOPEN(sybase_ptr-login,host))==FAIL) {
/*php_error(E_WARNING,Sybase: Link to server
lost, unable to reconnect);*/
zend_hash_del(EG(persistent_list),
hashed_details, hashed_details_length+1);
efree(hashed_details);
@@ -462,7 +462,7 @@
RETURN_FALSE;
}
- if ((sybase.link=dbopen(sybase.login,host))==NULL) {
+ if ((sybase.link=PHP_SYBASE_DBOPEN(sybase.login,host))==NULL) {
/*php_error(E_WARNING,Sybase: Unable to connect to server:
%s,sybase_error(sybase));*/
efree(hashed_details);
RETURN_FALSE;
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] RE: [PHP-QA] 4.0.6
James Moore wrote: If we announce PHP 4.0.6RC1 in X places then people will think oh 4.0.6 is released (remeber PHP users are incapable of reading anything more than about 10 words) lets use that; they then wont bother upgrading when the real 4.0.6 is released. This means we will start to get bug reports saying this isnt working in 4.0.6 when it has been fixed in the RC phase but is still present in the first RC. IMHO is's still better to have a RC that people do not update from then a pl1 that people do not update to (and we still have lots of error reports from people using versions way before 4.0.4, too) but if someone uses a RC and did not upgrade to the final release we can blame him if someone uses a release and didn't get the message that a pl1 is out it isn't that easy when using a RC you should be aware that a release (or a new RC) will be coming soon and that you should watch for it, especially if you have a problem with the RC when using a release there is nothing but experience with previous php 4 releases that gives you a clue that you should watch for a pl1 within days sure, some people don't get the clue whatever you do but with labeling something as release candidate, announcing it as such, and maybe adding bells and wistles to configure, make and the installers for precompiled windows versions (maybe even to every error message php generates) it should be possible to get the attention of everyone not totally clueless maybe we can agree on the following compromise? : - RC1 up to RCn announcements go to php-dev and QA only - as soon as things seem to work for QA we create RCn+1 or maybe PRC1 (public release candidate) and announce it to php-general this continues up to RCm or PRCm - when things have stabalzied even more we create [P]RCm+1 and announce it whereever we can - and finaly we do a release this would be just one additional step after all: take what we label as a release now and re-label it as (hopefully) final release candidate so that we hopefully get a release version which would otherwise be labeled as pl1 -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Sybase Patch. Could someone review it please? it is small. (Zeev? Joey?)
Applied. Please check out the latest CVS and test it. Andi At 11:13 AM 5/2/2001 -0700, PHP development @echospace wrote: Andi, Patch is attached. When you apply it, please tell me and I'll close related bug reports (there are a few, and they look different although they are about the same problem). Vlad - Original Message - From: Andi Gutmans To: PHP development @echospace ,[EMAIL PROTECTED] Sent: Wed, 02 May 2001 20:17:50 +0300 Subject: Re: [PHP-DEV] Sybase Patch. Could someone review it please? it is small. (Zeev? Joey?) Can you please send the .diff as an attachment so that I can apply it easily? I'll apply it (I hope it's OK :) Andi At 10:05 AM 5/2/2001 -0700, PHP development @echospace wrote: Hi, there. Sorry for picking your names, Zeev and Joey, but Zeev is listed as a maintainer, and Joey has assigned this particular bug to himself. I have been trying to find someone to look at the patch, see if you like it, and apply it (I do not have the karma myself), or tell me what you don't like. But nobody seemed to respond:( I posted the patch in the bug description of bug 8126. http://bugs.php.net/?id=8126 Thanks, Vlad Re-thinking the Web on a SinglePage(TM) http://www.echospace.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] Re-thinking the Web on a SinglePage(TM) http://www.echospace.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
