# buildconf and the generated configure script for PHP6 is faulty. - Thread: https://externals.io/message/32012 - Original archive: https://news-web.php.net/php.internals/32012 - Started by BuildSmart on 2007-09-03T05:55:15+00:00 - Messages: 25 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #32012 — BuildSmart — 2007-09-03T05:55:15+00:00 URL: https://externals.io/message/32012#32012 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There appears to be an issue with the configure script generation that warrants further examination which might just be related to Darwin / Mac OSX but unconfirmed at this time. I have tested this on 3 different machines with the same results and it places 2 lines in an incorrect/premature location within the configure script. daleenterprise:/php6 root# ./buildconf --force Forcing buildconf using default Zend directory buildconf: checking installation... buildconf: autoconf version 2.59 (ok) buildconf: Your version of autoconf likely contains buggy cache code. Running cvsclean for you. To avoid this, install autoconf-2.13. rebuilding aclocal.m4 rebuilding configure aclocal.m4:2141: PHP_PROG_LEX is expanded from... rebuilding acconfig.h rebuilding main/php_config.h.in autoheader: WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' autoheader: WARNING: and `config.h.top', to define templates for `config.h.in' autoheader: WARNING: is deprecated and discouraged. autoheader: autoheader: WARNING: Using the third argument of `AC_DEFINE' and autoheader: WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without autoheader: WARNING: `acconfig.h': autoheader: autoheader: WARNING: AC_DEFINE([NEED_FUNC_MAIN], 1, autoheader: [Define if a function `main' is needed.]) autoheader: autoheader: WARNING: More sophisticated templates can also be produced, see the autoheader: WARNING: documentation. aclocal.m4:2141: PHP_PROG_LEX is expanded from... daleenterprise:/php6 root# ./configure --help|more ./configure: line 447: 5: Bad file descriptor ./configure: line 448: 6: Bad file descriptor `configure' configures this package to adapt to many kinds of systems. ____________________________________________ The offending lines: (showing 447 - 453) echo "$as_me:$LINENO: checking whether rounding works as expected" >&5 echo $ECHO_N "checking whether rounding works as expected... $ECHO_C" >&6 # Name of the host. # hostname on some systems (SVR3.2, Linux) returns a bogus exit status, # so uname gets run too. ac_hostname=`(hostname || uname -n) 2>/dev/null | sed 1q` ____________________________________________ The two offending lines should be much further into the configure script: (just before 105676 - 105680) if test "$cross_compiling" = yes; then PHP_ROUND_FUZZ=0.50000000001 echo "$as_me:$LINENO: result: cross compile" >&5 echo "${ECHO_T}cross compile" >&6 ____________________________________________ The faulty configure script can be obtained at: http://daleenterprise.com/patches/configure - -- Dale -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFG26HE0hzWbkf0eKgRAlsEAJoCu/cQbjCLuwx0bbB5qfnCiKktLwCgsFKw omQjpISlRuVjPmIKfAG/+po= =/yla -----END PGP SIGNATURE --- ## #32013 — Jani Taskinen — 2007-09-03T08:58:51+00:00 URL: https://externals.io/message/32012#32013 · In reply to: #32012 Perhaps you should stick to using the pre-generated configure and not try to hack things since you obviously have no clue. If you want to build configure (which usually is very bad thing!) yourself, install autoconf-2.13. Any other version is not supported. --Jani > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > There appears to be an issue with the configure script generation > that warrants further examination which might just be related to > Darwin / Mac OSX but unconfirmed at this time. > > I have tested this on 3 different machines with the same results and > it places 2 lines in an incorrect/premature location within the > configure script. > > daleenterprise:/php6 root# ./buildconf --force > Forcing buildconf > using default Zend directory > buildconf: checking installation... > buildconf: autoconf version 2.59 (ok) > buildconf: Your version of autoconf likely contains buggy cache code. > Running cvsclean for you. > To avoid this, install autoconf-2.13. > rebuilding aclocal.m4 > rebuilding configure > aclocal.m4:2141: PHP_PROG_LEX is expanded from... > rebuilding acconfig.h > rebuilding main/php_config.h.in > autoheader: WARNING: Using auxiliary files such as `acconfig.h', > `config.h.bot' > autoheader: WARNING: and `config.h.top', to define templates for > `config.h.in' > autoheader: WARNING: is deprecated and discouraged. > autoheader: > autoheader: WARNING: Using the third argument of `AC_DEFINE' and > autoheader: WARNING: `AC_DEFINE_UNQUOTED' allows to define a template > without > autoheader: WARNING: `acconfig.h': > autoheader: > autoheader: WARNING: AC_DEFINE([NEED_FUNC_MAIN], 1, > autoheader: [Define if a function `main' is needed.]) > autoheader: > autoheader: WARNING: More sophisticated templates can also be > produced, see the > autoheader: WARNING: documentation. > aclocal.m4:2141: PHP_PROG_LEX is expanded from... > daleenterprise:/php6 root# ./configure --help|more > /configure: line 447: 5: Bad file descriptor > /configure: line 448: 6: Bad file descriptor > `configure' configures this package to adapt to many kinds of systems. > > ____________________________________________ > > > The offending lines: (showing 447 - 453) > echo "$as_me:$LINENO: checking whether rounding works as expected" >&5 > echo $ECHO_N "checking whether rounding works as expected... $ECHO_C" > > […] > > # Name of the host. > # hostname on some systems (SVR3.2, Linux) returns a bogus exit status, > # so uname gets run too. > ac_hostname=`(hostname || uname -n) 2>/dev/null | sed 1q` > > ____________________________________________ > > > The two offending lines should be much further into the configure > script: (just before 105676 - 105680) > if test "$cross_compiling" = yes; then > > PHP_ROUND_FUZZ=0.50000000001 > echo "$as_me:$LINENO: result: cross compile" >&5 > echo "${ECHO_T}cross compile" >&6 > > ____________________________________________ > > > The faulty configure script can be obtained at: > http://daleenterprise.com/patches/configure > > > - -- Dale > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2.2 (Darwin) > > iD8DBQFG26HE0hzWbkf0eKgRAlsEAJoCu/cQbjCLuwx0bbB5qfnCiKktLwCgsFKw > omQjpISlRuVjPmIKfAG/+po= > =/yla > -----END PGP SIGNATURE----- > -- Make me happy: http://pecl.php.net/wishlist.php/jani --- ## #32020 — BuildSmart — 2007-09-03T12:55:25+00:00 URL: https://externals.io/message/32012#32020 · In reply to: #32013 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Perhaps you should stick to using the pre-generated configure and not > try to hack things since you obviously have no clue. Did somebody piss in your cornflakes or are you always this charming? What hack, it's your buildconf script and the only version of PHP that gets it wrong is PHP6. Never mind, I've resolved the issue and concluded that carelessness on your part doesn't constitute a problem on my part. > > If you want to build configure (which usually is very bad thing!) > yourself, install autoconf-2.13. Any other version is not supported. A bad thing, have you stopped taking your medication? The configure script wont rebuild itself without a little prodding and I don't see you offering any free service to do it. Why would I want to downgrade, don't tell me it's because you claim all other versions are buggy, I find that hard to accept since the only problem I've ever experienced to date has been with PHP6 and swapping two lines corrected this. > > --Jani > > > > […] > -- > Make me happy: http://pecl.php.net/wishlist.php/jani With an attitude like yours I can see why your wishlist hasn't changed much over a long period of time. > > > - -- Dale -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFG3AQ90hzWbkf0eKgRAtrOAKCaErfaH2tUNRlyy+3FsrfNXKDm9gCfS0re fsSoNR2Kw4FNh9OAOogW7Ls= =80bw -----END PGP SIGNATURE --- ## #32021 — Hartmut Holzgraefe — 2007-09-03T13:45:32+00:00 URL: https://externals.io/message/32012#32021 · In reply to: #32020 BuildSmart wrote: [... inappropriate language removed ...] > Why would I want to downgrade, don't tell me it's because you claim all > other versions are buggy, I find that hard to accept since the only > problem I've ever experienced to date has been with PHP6 > and swapping two lines corrected this. Well, the fact that the lines ended up in the wrong place in the final configure file produced while the one created with 2.13 ... what is that if not a strong indication of an autoconf bug? buildconf just calls autoconf, so why do you think it is to blame for wrong autoconf output that only seems to happen with *some* versions of autoconf? -- Hartmut Holzgraefe, Principal Support Engineer . Discover new MySQL Monitoring & Advisory features at: http://www.mysql.com/products/enterprise/whats_new.html Hauptsitz: MySQL GmbH, Dachauer Str.37, 80335 München Geschäftsführer: Kaj Arnö - HRB München 162140 --- ## #32022 — David Coallier — 2007-09-03T13:52:50+00:00 URL: https://externals.io/message/32012#32022 · In reply to: #32020 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > > > […] > > Did somebody piss in your cornflakes or are you always this charming? > > What hack, it's your buildconf script and the only version of PHP > that gets it wrong is PHP6. > > Never mind, I've resolved the issue and concluded that carelessness > on your part doesn't constitute a problem on my part. > > > […] > > A bad thing, have you stopped taking your medication? > > The configure script wont rebuild itself without a little prodding > and I don't see you offering any free service to do it. > > Why would I want to downgrade, don't tell me it's because you claim > all other versions are buggy, I find that hard to accept since the > only problem I've ever experienced to date has been with PHP6 and > swapping two lines corrected this. > Mr. BuildSmart, if you have personal problems with one of the members, please take it offlist and do not pollute the mailing list. Any sorts of insults are not welcome here. Thanks, > > […] > > With an attitude like yours I can see why your wishlist hasn't > changed much over a long period of time. > > > […] > > - -- Dale > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2.2 (Darwin) > > iD8DBQFG3AQ90hzWbkf0eKgRAtrOAKCaErfaH2tUNRlyy+3FsrfNXKDm9gCfS0re > fsSoNR2Kw4FNh9OAOogW7Ls= > =80bw > -----END PGP SIGNATURE----- > > -- > > > > -- David Coallier, Founder & Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 --- ## #32024 — nicobn@gmail.com — 2007-09-03T14:54:23+00:00 URL: https://externals.io/message/32012#32024 · In reply to: #32020 Hi Mr. BuildSmart, I invite you to take a look at http://www.php.net/anoncvs.php before complaining. It is clearly stated that autoconf 2.13 is a requirement. Most package distributions (I checked Ubuntu, FreeBSD ports and pkgsrc) still provide autoconf 2.13 and it is not really a problem to have two versions installed, ergo you don't need to downgrade. Nobody pissed in Jani's cornflakes, but you have to understand this is the internals mailing list, not a general help mailing list. Regards, > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > > > […] > > Did somebody piss in your cornflakes or are you always this charming? > > What hack, it's your buildconf script and the only version of PHP > that gets it wrong is PHP6. > > Never mind, I've resolved the issue and concluded that carelessness > on your part doesn't constitute a problem on my part. > > > […] > > A bad thing, have you stopped taking your medication? > > The configure script wont rebuild itself without a little prodding > and I don't see you offering any free service to do it. > > Why would I want to downgrade, don't tell me it's because you claim > all other versions are buggy, I find that hard to accept since the > only problem I've ever experienced to date has been with PHP6 and > swapping two lines corrected this. > > > […] > > With an attitude like yours I can see why your wishlist hasn't > changed much over a long period of time. > > > […] > > - -- Dale > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2.2 (Darwin) > > iD8DBQFG3AQ90hzWbkf0eKgRAtrOAKCaErfaH2tUNRlyy+3FsrfNXKDm9gCfS0re > fsSoNR2Kw4FNh9OAOogW7Ls= > =80bw > -----END PGP SIGNATURE----- > > -- > > > > -- Nicolas Bérard-Nault (nicobn@gmail.com) Étudiant D.E.C. Sciences, Lettres & Arts Cégep de Sherbrooke Homepage: http://nicobn.googlepages.com --- ## #32026 — BuildSmart — 2007-09-03T19:51:11+00:00 URL: https://externals.io/message/32012#32026 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Dear Mr. BuildSmart > > > […] > > talking about assumptions: i didn't claim that changing the > autoconf version used was what you did but what you should > have done ... Well perhaps you have a bad memory because you stated the autoconf 2.13 generated version works and I don't have 2.13 installed and a configure script isn't provided so you must have assumed I generated the working one with 2.13 otherwise you would not have mentioned anything about autoconf 2.13 generating a working configure script. > > > […] > > Oh? That may be what you did (in which case it would be > interesting to know *which* m4 file and how the actual > change looks like), what you *sent* though was a change > to the generated configure file, not to any of the > *.m4 files it was created from ... I sent no changed file, I provided a link to the faulty (un-edited) configure script, I explained that two lines were ending up in the wrong place, I showed where they are, and where they should be. Since you believe it's an autoconf bug and don't support any other version of autoconf there is no need to pursue the matter further, I've noted the issue internally as an unsupported autoconf version fix. > > -- > Hartmut Holzgraefe, Principal Support Engineer - --Dale -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFG3GWv0hzWbkf0eKgRAv7HAJ9yTxlUTBE91No+HZfbSGbT6wvMlQCfWtEX IIgVUnY6PpI84L5TggxuSlA= =JUqW -----END PGP SIGNATURE --- ## #32027 — BuildSmart — 2007-09-03T22:10:40+00:00 URL: https://externals.io/message/32012#32027 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 For those interested in the fix. ext/standard/config.m4: dnl dnl round fuzz dnl +AC_DEFUN([PHP_CHECK_ROUNDING_WORKS],[ AC_MSG_CHECKING([whether rounding works as expected]) AC_TRY_RUN([ #include /* keep this out-of-line to prevent use of gcc inline `floor()` */ double somefn(double n) { return floor(n*pow(10,2) + 0.5); } int main() { return somefn(0.045)/10.0 != 0.5; } ],[ PHP_ROUND_FUZZ=0.5 AC_MSG_RESULT(yes) ],[ PHP_ROUND_FUZZ=0.50000000001 AC_MSG_RESULT(no) ],[ PHP_ROUND_FUZZ=0.50000000001 AC_MSG_RESULT(cross compile) ]) AC_DEFINE_UNQUOTED(PHP_ROUND_FUZZ, $PHP_ROUND_FUZZ, [ see #24142 ]) +]) +PHP_CHECK_ROUNDING_WORKS -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFG3IZh0hzWbkf0eKgRAjsRAJ99kd45aNx3Ch53UAc6tHocYaSYtgCfUOUV shkWqcinQfP6no8fZ8iDaR4= =qfI+ -----END PGP SIGNATURE --- ## #32029 — Pierre — 2007-09-04T09:24:13+00:00 URL: https://externals.io/message/32012#32029 · In reply to: #32027 Hi Dale, I'm not sure I was clear enough in my last four replies. We have two important issues tracker (for your needs): http://bugs.php.net for all you can have in php releases or snaps http://pecl.php.net for all PECL packages http://pear.php.net for all PEAR packages (pear installer included) All patches, bugs report and feature requests should be posted in one of them. They can be discussed on the respective mailing list but having the reports in these tools is the _only_ safe way to do not loose them in the list archive and to track them. Thanks for your work and understanding, Cheers, --Pierre --- ## #32030 — BuildSmart — 2007-09-04T10:39:06+00:00 URL: https://externals.io/message/32012#32030 · In reply to: #32029 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'd like to work on resolving as many of the bugs as possible in the shortest amount of time because there are not enough PHP developers to go around validating and fixing every reported bug, this means that the person assigned many of the bugs has his workload reduced because he only has to substantiate the solution. SInce I didn't consider it a bug but rather a minor error of importance, I thought it would best be handled by making the maintainers aware of the issue since the fix is relatively simple and provided to avoid the filing of bug reports which would have occurred. For example, several complaints regarding MySQL and PHP and Mac OS X have resulted in the filing of bug reports over an extended period of time (since mysql.org has been providing binaries for Mac OS X) and the issue never really documented or resolved, now this bug can be entirely ignored because I took the time to validate the complaint and bring to light the true fault (which I already knew from previous experience with their packaged software) so now it should be openly documented to avoid any more false filing on this bug. If you prefer all matters to be handled by the respective bug report venues that isn't a problem, I can collect all of the issues regardless of their importance and file them and let the respective assignee determine what is important and determine the appropriate fix because my time would then be consumed by the filing of bug reports with little time to spend substantiating and providing a fix, however I feel that it may overwhelm the respective assignee due to the shear number of issues and I was thinking that by weeding through the simple fixes and providing the solution, the whole bug process and a lot of user related complaints could be dramatically reduced by prevention alone. Further more, you could have played on my strengths by assigning me the Mac OS X related bugs to substantiate and provide solutions for those I can because I am fluent in this environment and the amount of time required would more than likely be minimal but that looks like a thought that wasn't considered by anyone. Actually, I'll simplify matters even more and save my time, I wont file any bug reports or provide any solutions, I'll leave that to the end user to file a report after release that gets ignored because he isn't technically inclined enough to write a proper report that includes enough instructions, details or a potential solution as it gets dragged out over an extended period of time because there isn't enough personnel to go around. Since all issues, even in betas and pre-release are to be considered bugs and should be filed as bugs, I can now see why the PHP wheels turn so slowly, sorry for wasting your time in an effort to assist and expedite matters by trying to free the developers to more important issues like software development rather than chasing bugs. - -- Dale > Hi Dale, > > I'm not sure I was clear enough in my last four replies. We have two > important issues tracker (for your needs): > > http://bugs.php.net for all you can have in php releases or snaps > http://pecl.php.net for all PECL packages > http://pear.php.net for all PEAR packages (pear installer included) > > All patches, bugs report and feature requests should be posted in one > of them. They can be discussed on the respective mailing list but > having the reports in these tools is the _only_ safe way to do not > loose them in the list archive and to track them. > > Thanks for your work and understanding, > > Cheers, > --Pierre > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFG3TXK0hzWbkf0eKgRAvR4AJ9+oVtlS6h78NmmuVBd50TSGtbHMgCdEIPJ g7pQPJF+oYdwq0OaXXQQ4Xs= =86lS -----END PGP SIGNATURE --- ## #32031 — Pierre — 2007-09-04T10:50:51+00:00 URL: https://externals.io/message/32012#32031 · In reply to: #32030 > Actually, I'll simplify matters even more and save my time, I wont > file any bug reports or provide any solutions, It looks like there is a misunderstanding. My answers had no bad meanings. It was only about telling you how we use to work. Most of us work on this project (*.php.net) in our free time and we have to use a common tools to __track__ issues, patches, changes or releases. One of these tools is an issue tracker. I can safely say that it is a common practice in every project to use an issue tracker, I completely fail to see where is the problem and why you suddenly end to this conclusion. Not that it really interests me (politics suck and I have no interest in FUD :), but I'm sad to see your efforts ending in such way. Cheers, --Pierre --- ## #32032 — Hartmut Holzgraefe — 2007-09-04T13:02:23+00:00 URL: https://externals.io/message/32012#32032 · In reply to: #32030 Dear Mr BuildSmart BuildSmart wrote: > SInce I didn't consider it a bug but rather a minor error of importance, just out of curiosity: how do you define "bug" if not as "any error"? > I thought it would best be handled by making the maintainers aware of > the issue since the fix is relatively simple and provided to avoid the > filing of bug reports which would have occurred. this is wrong in several ways: - your original posting did not include the actual fix but only what should change in the generated configure file the actual fix was only in your mail of 12:10 today. giving you the benefit of the doubt i'd assume for now that it was attached to the original message, too, but got stripped, this would not have happened with a bug report though - the bug database is not only a todo list, it is also a repository of bugs fixed in the past. e.g. have you noticed the duplicate detection when filing a bug? with a bug fixed out of band without involving the bugs db duplicate detection can't kick in on new bug reports - changelog entries usually refer to a bug number, having them point to a mail archive instead would be inconsistant and so bad - same for commit messages ... add to this that it is easy to refer to a bug number but way less so to refer to a distinct email So working around the bug system is not a shortcut, it actually generates *more* work in the long run. The bug system is there to be *used*, not to be circumvented. If you had submitted your finding as a bug report with proper how-to-reproduce instructions (which your original message did not have, what you wrote there was way to vague) and also with your patch to ext/standard/config.m4 things would probably been handled just fine already. Look what mess you caused instead ... :( -- Hartmut Holzgraefe, Principal Support Engineer . Discover new MySQL Monitoring & Advisory features at: http://www.mysql.com/products/enterprise/whats_new.html Hauptsitz: MySQL GmbH, Dachauer Str.37, 80335 München Geschäftsführer: Kaj Arnö - HRB München 162140 --- ## #32041 — BuildSmart — 2007-09-04T17:48:28+00:00 URL: https://externals.io/message/32012#32041 · In reply to: #32032 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Dear Mr BuildSmart > > BuildSmart wrote: > > […] > > just out of curiosity: how do you define "bug" if not as "any error"? > > > […] > > this is wrong in several ways: > > - your original posting did not include the actual fix but > only what should change in the generated configure file > > the actual fix was only in your mail of 12:10 today. > giving you the benefit of the doubt i'd assume for now > that it was attached to the original message, too, but > got stripped, this would not have happened with a bug > report though > > - the bug database is not only a todo list, it is also > a repository of bugs fixed in the past. e.g. have you > noticed the duplicate detection when filing a bug? > with a bug fixed out of band without involving the > bugs db duplicate detection can't kick in on new bug > reports > > - changelog entries usually refer to a bug number, > having them point to a mail archive instead would > be inconsistant and so bad > > - same for commit messages ... add to this that it is > easy to refer to a bug number but way less so to > refer to a distinct email > > So working around the bug system is not a shortcut, > it actually generates *more* work in the long run. > > The bug system is there to be *used*, not to be > circumvented. > > If you had submitted your finding as a bug report > with proper how-to-reproduce instructions (which > your original message did not have, what you wrote > there was way to vague) and also with your patch > to ext/standard/config.m4 things would probably > been handled just fine already. Look what mess you > caused instead ... :( My original post did very well outline how to reproduce the issue because the entire terminal session was provided, mess??? Unlike many developers who do this in their spare time, I have the time, resources, energy and motivation to attack PHP with extreme aggression. I'm paid a minimum of $750.00 USD to generate binaries of PHP, yes people pay me because they are tired of the issues with using packages like the entropy PHP (nothing personal against Mark, I know him) so for the most part, I spend an average of 8 hours a day building various version of PHP and the required dependancy software. Due to the nature of my work, I have encountered just about every imaginable bug in the build process, if I were to submit bug reports on each and every issue encountered, the number alone would swamp the developers who spend their time validating and substantiating the reported bugs because I am not your average yogi bear. A supply of various hardware is abundantly on hand, I build for 2 different architectures so I see problems that only affect one architecture and not the other and I can generate a dual architecture build in a single pass on a single machine so spending the time building on two different machines and then manually combining the binaries or scripting the process isn't required. If someone here can generate the same type of build that works I would be very impressed. If you think I'm wrong or talking out of my @$$, try building PHP for dual architecture in a single pass with date enabled and then run this build on a ppc and an intel machine and tell me that the php_info () function doesn't fail on one of the architectures or that it doesn't segfault when using the date functions. I wont even go into the dedication issue of providing windows binaries but no binaries for other platforms that is a constant user gripe that windows is favored which is another reason that posting the extensive bug list would further tarnish the current image which isn't to shiny to begin with. I'm not interested in filing a minimum of 100 bug reports when you don't have the manpower to process them, I've resolved most of them already (at least the ones related to the php base) and any that I haven't I've noted as "Broken - DNU" so I don't pass anything unstable on to my clients. So now that you see I'm talking about considerably more than a handful of bugs you should be able to grasp why I don't report them or wish to spend the considerable amount of time required in reporting all of them when it would take forever for them to be processed and to have users hit the PHP site and see the large list would only create further animosity by a quickly growing group of hardware owners who already believe that their platform isn't being properly supported by the PHP dev group as it is. > > -- > Hartmut Holzgraefe, Principal Support Engineer - -- Dale -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFG3Zps0hzWbkf0eKgRAvCuAKCCUJmTvX7jdrScyEAsuJtPRMmtYgCfT8Cq QDX4C2DLiHcGbDF2nijHnk8= =op9E -----END PGP SIGNATURE --- ## #32042 — Stut — 2007-09-04T18:07:35+00:00 URL: https://externals.io/message/32012#32042 · In reply to: #32041 Hello Dale, I'm not experienced enough to comment on most of what you said, but not reporting bugs in a piece of software because you're worried that 1) the developers won't be able to deal with the volume and 2) you're worried about damaging the reputation of said software has to be the most idiotic attitude I've ever come across. -Stut BuildSmart wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > > > […] > > My original post did very well outline how to reproduce the issue > because the entire terminal session was provided, > > mess??? > > Unlike many developers who do this in their spare time, I have the time, > resources, energy and motivation to attack PHP with extreme aggression. > > I'm paid a minimum of $750.00 USD to generate binaries of PHP, yes > people pay me because they are tired of the issues with using packages > like the entropy PHP (nothing personal against Mark, I know him) so for > the most part, I spend an average of 8 hours a day building various > version of PHP and the required dependancy software. > > Due to the nature of my work, I have encountered just about every > imaginable bug in the build process, if I were to submit bug reports on > each and every issue encountered, the number alone would swamp the > developers who spend their time validating and substantiating the > reported bugs because I am not your average yogi bear. > > A supply of various hardware is abundantly on hand, I build for 2 > different architectures so I see problems that only affect one > architecture and not the other and I can generate a dual architecture > build in a single pass on a single machine so spending the time building > on two different machines and then manually combining the binaries or > scripting the process isn't required. > > If someone here can generate the same type of build that works I would > be very impressed. > > If you think I'm wrong or talking out of my @$$, try building PHP for > dual architecture in a single pass with date enabled and then run this > build on a ppc and an intel machine and tell me that the php_info() > function doesn't fail on one of the architectures or that it doesn't > segfault when using the date functions. > > I wont even go into the dedication issue of providing windows binaries > but no binaries for other platforms that is a constant user gripe that > windows is favored which is another reason that posting the extensive > bug list would further tarnish the current image which isn't to shiny to > begin with. > > I'm not interested in filing a minimum of 100 bug reports when you don't > have the manpower to process them, I've resolved most of them already > (at least the ones related to the php base) and any that I haven't I've > noted as "Broken - DNU" so I don't pass anything unstable on to my clients. > > So now that you see I'm talking about considerably more than a handful > of bugs you should be able to grasp why I don't report them or wish to > spend the considerable amount of time required in reporting all of them > when it would take forever for them to be processed and to have users > hit the PHP site and see the large list would only create further > animosity by a quickly growing group of hardware owners who already > believe that their platform isn't being properly supported by the PHP > dev group as it is. > > > […] > > - -- Dale > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2.2 (Darwin) > > iD8DBQFG3Zps0hzWbkf0eKgRAvCuAKCCUJmTvX7jdrScyEAsuJtPRMmtYgCfT8Cq > QDX4C2DLiHcGbDF2nijHnk8= > =op9E > -----END PGP SIGNATURE --- ## #32043 — Nuno Lopes — 2007-09-04T18:20:06+00:00 URL: https://externals.io/message/32012#32043 · In reply to: #32041 > I'm not interested in filing a minimum of 100 bug reports when you > don't have the manpower to process them, I've resolved most of them > already (at least the ones related to the php base) and any that I > haven't I've noted as "Broken - DNU" so I don't pass anything > unstable on to my clients. hey man you have two options: - you fill bug reports and attach patches to them (you said you have fixed them all). manpower is surely not an issue on our side. if something needs discussion, you can also join us on IRC. - you shut up (i.e. stop posting on PHP mailing lists). I already have enough useless e-mails on my inbox every day. Thanks, Nuno --- ## #32044 — Antony Dovgal — 2007-09-04T18:34:05+00:00 URL: https://externals.io/message/32012#32044 · In reply to: #32041 On 04.09.2007 21:48, BuildSmart wrote: > Unlike many developers who do this in their spare time, I have the > time, resources, energy and motivation to attack PHP with extreme > aggression. Please stop here, right now. No need to attack anything or anyone. If you want your job (or life, 'cause for most of us job is a substantial part of life) to become a little bit easier, you need to learn to communicate and to be a part of community. Yes, it might not be that easy as it looks like from the first glance. But if you continue to do what you're doing right now, you'll get into everybody's ignore list in couple of days. > Due to the nature of my work, I have encountered just about every > imaginable bug in the build process, if I were to submit bug reports > on each and every issue encountered, the number alone would swamp the > developers who spend their time validating and substantiating the > reported bugs because I am not your average yogi bear. Believe it or not, but due to the nature of my job I've encountered hundreds of issues and fixed/reported (or both) most of them. And that did not cause a flamewar in the lists and did not involve any personal insults. We really do appreciate your contributions, but it's just impossible to work with someone who ignores all the rules and does not respect the others. > A supply of various hardware is abundantly on hand, I build for 2 > different architectures so I see problems that only affect one > architecture and not the other and I can generate a dual architecture > build in a single pass on a single machine so spending the time > building on two different machines and then manually combining the > binaries or scripting the process isn't required. > > If someone here can generate the same type of build that works I > would be very impressed. Please, calm down, no need to worry so much. During the previous several years I did it almost every week, for MacOS, Linux, AIX, Solaris and other platforms. Yes, and universal binaries too. And they work fine, yes, thanks for asking. So what? > If you think I'm wrong or talking out of my @$$, try building PHP for > dual architecture in a single pass with date enabled and then run > this build on a ppc and an intel machine and tell me that the php_info > () function doesn't fail on one of the architectures or that it > doesn't segfault when using the date functions. This issue was discussed on the list a couple of weeks ago, search the archives. Btw, thanks for reminding, I need to commit the patch fixing it. > I wont even go into the dedication issue of providing windows > binaries but no binaries for other platforms that is a constant user > gripe that windows is favored It's funny to hear such things from someone definitely familiar with operating systems.. > I'm not interested in filing a minimum of 100 bug reports when you > don't have the manpower to process them, I've resolved most of them > already (at least the ones related to the php base) and any that I > haven't I've noted as "Broken - DNU" so I don't pass anything > unstable on to my clients. That's really nice. "I fixed something nasty, but I won't show you. Find it yourself, you stupid." Way to go! Really helpful. > So now that you see I'm talking about considerably more than a > handful of bugs you should be able to grasp why I don't report them > or wish to spend the considerable amount of time required in > reporting all of them when it would take forever for them to be > processed and to have users hit the PHP site and see the large list > would only create further animosity by a quickly growing group of > hardware owners who already believe that their platform isn't being > properly supported by the PHP dev group as it is. Sam Ruby wrote really nice blog entry on this topic: http://intertwingly.net/blog/2007/07/17/Popular-Sovereignty If you want PHP dev to support your platform properly - become one of them and do it. It's easy. -- Wbr, Antony Dovgal --- ## #32052 — Stanislav Malyshev — 2007-09-04T19:42:44+00:00 URL: https://externals.io/message/32012#32052 · In reply to: #32041 > Due to the nature of my work, I have encountered just about every > imaginable bug in the build process, if I were to submit bug reports on > each and every issue encountered, the number alone would swamp the > developers who spend their time validating and substantiating the > reported bugs because I am not your average yogi bear. I think you need not to worry about swamping developers. If all of the issues are real bugs, the developers would find time - now or in the future - to fix them. Even if they do not - either because nobody considered it important or some other reason - the issue would still be known and waiting for somebody to fix it, eventually. That's the power of open source development model. I understand that having to encounter a lot of bugs can be frustrating, and it can happen if you venture to do something that not many have done before. The best way to deal with it is to contribute a little amount of your time on filing bug reports, thus enabling the community to work with you and contribute back. > I'm not interested in filing a minimum of 100 bug reports when you don't > have the manpower to process them, I've resolved most of them already > (at least the ones related to the php base) and any that I haven't I've > noted as "Broken - DNU" so I don't pass anything unstable on to my clients. Of course, nobody could demand from you to contribute your fixes or your information back - but it is a good citizenship if you do. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #32055 — BuildSmart — 2007-09-04T20:39:33+00:00 URL: https://externals.io/message/32012#32055 · In reply to: #32042 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Hello Dale, > > I'm not experienced enough to comment on most of what you said, but > not reporting bugs in a piece of software because you're worried > that 1) the developers won't be able to deal with the volume and 2) > you're worried about damaging the reputation of said software has > to be the most idiotic attitude I've ever come across. The complaints over the 4 or 5 I have mentioned on the list has borne the remarks that I swamp the list with the reports, how it would be if I dumped a couple hundred? To disregard the perception of the PHP software and it's developers is a stoic thought concept, since you have no issues accepting the concept that the majority of end users believe that the PHP software is a collection of cruft managed by a group of pompous programmers doesn't mean that the other developers share in this concept, image in a web-related world has value whether you give it any or not so airing everything isn't always the best policy. Rather than contribute to any negative thoughts and impressions that would be attained by submitting countless bug reports that would take months if not years to process or most likely just be ignored, I believe it's best to refrain from such submission unless it's absolutely critical. This is going absolutely nowhere, I'm dropping out of this discussion to avoid retaliations due to bruised egos. Let it die here. > > -Stut > > BuildSmart wrote: > > […] - -- Dale -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFG3cKG0hzWbkf0eKgRAjojAJ0YFSWSUCjDOK1fW1i7S00IAMho1QCfWuk/ HsWZYVM16GS0cBi+tBNaw4k= =iaKb -----END PGP SIGNATURE --- ## #32058 — Hartmut Holzgraefe — 2007-09-04T22:46:58+00:00 URL: https://externals.io/message/32012#32058 · In reply to: #32041 Dear Mr. BuildSmart > I'm not interested in filing a minimum of 100 bug reports when you don't > have the manpower to process them, I've resolved most of them already > (at least the ones related to the php base) and any that I haven't I've > noted as "Broken - DNU" so I don't pass anything unstable on to my clients. if you want your fixes applied you need to get them reviewed for now, and the proper workflow to get that done is to file bug reports with patches attached, not posting them in the mailing list (and especially not putting them in only rather late in a thread). Posting patches to the mailing list right away sort of works, too, but in the long run it produces *more* work for everyone, not less. You don't have to agree with this, but you have to accept the established workflow nonetheless ... or accept not being taken serious (which your insistence of not putting your real name into your "From:" field already substantially contributes to ...) -- Hartmut Holzgraefe, Principal Support Engineer . Discover new MySQL Monitoring & Advisory features at: http://www.mysql.com/products/enterprise/whats_new.html Hauptsitz: MySQL GmbH, Dachauer Str.37, 80335 München Geschäftsführer: Kaj Arnö - HRB München 162140 --- ## #32061 — Hartmut Holzgraefe — 2007-09-05T10:00:41+00:00 URL: https://externals.io/message/32012#32061 · In reply to: #32055 Hello Mr B*S* > The complaints over the 4 or 5 I have mentioned on the list has borne > the remarks that I swamp the list with the reports, how it would be if I > dumped a couple hundred? if you dumped them on the list you would end up in everyones ignore list as *the list is not the right communication channel for that* If the bug system is not the right place to put things then nothing is. Is this really so hard to understand? > To disregard the perception of the PHP software and it's developers is a > stoic thought concept, since you have no issues accepting the concept > that the majority of end users believe that the PHP software is a > collection of cruft managed by a group of pompous programmers doesn't > mean that the other developers share in this concept, image in a > web-related world has value whether you give it any or not so airing > everything isn't always the best policy. Talking about image, why are you trying *so* hard to ruin your own? > Rather than contribute to any negative thoughts and impressions that > would be attained by submitting countless bug reports How do bug reports contribute to a negative impression? There is no bug free software. And having the known bugs tracked in the open instead of somewhere under the hood is is actually building trust instead of demolishing it IMHO > that would take months if not years to process Did you try? where does this estimate come from? I see a lot of claims in your postings but only very little fact it is built upon > or most likely just be ignored, One of the things that influences whether a bug is ignored or taken serious is the attitude of the reporter, too. Things that do not help with that: - Insisting to push things to the wrong communication channels - revealing the actual fix you claim to have only several messages down the thread instead of right away - not providing version information up front ... yes, the autoconf version you were using was to be found in the post somewhere ... but you ignored a very simple and substantial rule that applies to all forms of one-to-many communication: "the burden shall be on the writer, not the readers" > I believe > it's best to refrain from such submission unless it's absolutely critical. well, if you think so ... > This is going absolutely nowhere, I'm dropping out of this discussion > to avoid retaliations due to bruised egos. Has there been a discussion? At least from your side it was mostly flaming IMHO. Anyway, i agree that this is not getting us anywhere. You've clearly shown that you want to have it your way and are not willing to adapt in any way ... -- Hartmut Holzgraefe, Principal Support Engineer . Discover new MySQL Monitoring & Advisory features at: http://www.mysql.com/products/enterprise/whats_new.html Hauptsitz: MySQL GmbH, Dachauer Str.37, 80335 München Geschäftsführer: Kaj Arnö - HRB München 162140 --- ## #32064 — William A. Rowe — 2007-09-05T12:49:03+00:00 URL: https://externals.io/message/32012#32064 · In reply to: #32061 Hartmut Holzgraefe wrote: > > > […] > > if you dumped them on the list you would end up in everyones ignore > list as *the list is not the right communication channel for that* Well, other than the totally uncivilized discussion by nearly everyone on this thread, I'd argue that discussing the whole "you must use the one working (long abandoned) version of autoconf" is certainly a good topic for a developer list and a good puzzle to solve. I'd have to agree with Dale on this point; PHP has more fragile dependencies on build tools than any modern open source project out there. I totally disagree with him that not providing binaries is discourteous to users; that's a packager problem (and on Mac/OSX, one to complain to Apple about, eh?) Bill --- ## #32065 — BuildSmart — 2007-09-05T13:49:49+00:00 URL: https://externals.io/message/32012#32065 · In reply to: #32061 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Hello Mr B*S* hmm, not my name or my pseudonym but the remainder of this post appears to have been written by me, dyslexic are you? > > > > […] > > if you dumped them on the list you would end up in everyones ignore > list as *the list is not the right communication channel for that* > > If the bug system is not the right place to put things then nothing > is. > > Is this really so hard to understand? Are you so dumb that you can't grasp the concept that it has nothing to do with understanding what you're trying to point out? > > > […] > > Talking about image, why are you trying *so* hard to ruin your own? This doesn't ruin my image, the general opinion of me (as I'm told) is that I am actively and openly trying to help, unfortunately people like you are preventing this with flame tactics. > > > […] > > How do bug reports contribute to a negative impression? There is no > bug free software. And having the known bugs tracked in the open > instead of somewhere under the hood is is actually building trust > instead of demolishing it IMHO > > > […] > > Did you try? where does this estimate come from? > I see a lot of claims in your postings but only very > little fact it is built upon Examine the bug tracker, it appears it's a slow process for the majority of bugs related to Mac OS X. > > > […] > > One of the things that influences whether a bug is ignored > or taken serious is the attitude of the reporter, too. Things > that do not help with that: > > - Insisting to push things to the wrong communication channels > - revealing the actual fix you claim to have only several > messages down the thread instead of right away > - not providing version information up front ... yes, > the autoconf version you were using was to be found in > the post somewhere ... but you ignored a very simple > and substantial rule that applies to all forms of > one-to-many communication: "the burden shall be on the > writer, not the readers" It helps if the reader actual reads the post and sees the content you claim with the exception of providing the fix is present, I just reread the original post which contains the terminal session and it clearly displays my autoconf version so you might want to seek the services of an optometrist to correct your problem. The reason that the fix was not included, the developers may have a different approach to this solution > > > […] > > well, if you think so ... I'm sorry that your ability to perceive more than the written word is non-existent. > > > […] > discussion > > […] > > Has there been a discussion? At least from your side it > was mostly flaming IMHO. Anyway, i agree that this is not > getting us anywhere. You've clearly shown that you want > to have it your way and are not willing to adapt in any > way ... Everyone wants it there way, adaptation on my part has never been an issue, your perception of things is. Flaming on your part only shows your lack of ability to actively participate in sensible communication, many already believe you to be an idiot, all you've succeeded in doing is validating this belief that so many of the non-publicly visible members of this list have of you who fear publicly posting and being subjected to your abusive nature. When they think of your name they associate it with PHP and this taints the opinion that people have of PHP and it's dev group so it appears you are a major contributor to the poor image people have of PHP and the PHP dev group, way to go sherlock. Yes, you can believe it, I have received many off-list responses from people who have offered this opinion of you and while attempting to give you the benefit of doubt, you have succeeded in making me believe exactly what these people have been telling me about you. If you put 1/10th the energy you use in flaming people towards the PHP effort, you would be helping to advance things considerably faster by not wasting the valuable time of the reader who has to wade through this type of crap. Now, if you have anything further to add, please refrain from cluttering the list and do so privately. > > -- > Hartmut Holzgraefe, Principal Support Engineer - -- Dale -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFG3rP90hzWbkf0eKgRAoHuAKC8Sggp3Bt+pOp9ojfebdCmxuvNawCfW8j5 M9BuK2gSySo4U80NgL1qVU0= =2QJh -----END PGP SIGNATURE --- ## #32067 — David Coallier — 2007-09-05T14:06:45+00:00 URL: https://externals.io/message/32012#32067 · In reply to: #32065 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > > > […] > > hmm, not my name or my pseudonym but the remainder of this post > appears to have been written by me, dyslexic are you? > > > […] > > Are you so dumb that you can't grasp the concept that it has nothing > to do with understanding what you're trying to point out? > > > […] > > This doesn't ruin my image, the general opinion of me (as I'm told) > is that I am actively and openly trying to help, unfortunately people > like you are preventing this with flame tactics. > > > […] > > Examine the bug tracker, it appears it's a slow process for the > majority of bugs related to Mac OS X. > > > […] > > It helps if the reader actual reads the post and sees the content you > claim with the exception of providing the fix is present, I just > reread the original post which contains the terminal session and it > clearly displays my autoconf version so you might want to seek the > services of an optometrist to correct your problem. > > The reason that the fix was not included, the developers may have a > different approach to this solution > > > […] > > I'm sorry that your ability to perceive more than the written word is > non-existent. > > > […] > > Everyone wants it there way, adaptation on my part has never been an > issue, your perception of things is. > > Flaming on your part only shows your lack of ability to actively > participate in sensible communication, many already believe you to be > an idiot, all you've succeeded in doing is validating this belief > that so many of the non-publicly visible members of this list have of > you who fear publicly posting and being subjected to your abusive > nature. > > When they think of your name they associate it with PHP and this > taints the opinion that people have of PHP and it's dev group so it > appears you are a major contributor to the poor image people have of > PHP and the PHP dev group, way to go sherlock. > > Yes, you can believe it, I have received many off-list responses from > people who have offered this opinion of you and while attempting to > give you the benefit of doubt, you have succeeded in making me > believe exactly what these people have been telling me about you. > > If you put 1/10th the energy you use in flaming people towards the > PHP effort, you would be helping to advance things considerably > faster by not wasting the valuable time of the reader who has to wade > through this type of crap. > > Now, if you have anything further to add, please refrain from > cluttering the list and do so privately. > > > […] > > - -- Dale > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2.2 (Darwin) > > iD8DBQFG3rP90hzWbkf0eKgRAoHuAKC8Sggp3Bt+pOp9ojfebdCmxuvNawCfW8j5 > M9BuK2gSySo4U80NgL1qVU0= > =2QJh > -----END PGP SIGNATURE----- > > -- > > > > I'll repeat again, if anyone has a personal problem with someone else, either take it offlist, take a beer or see a psychiatrist. We don't care if you don't like someone else, do it elsewhere, this list is for PHP issues, not personal issues. (And I'm not only talking about you mr. BS, this applies to anyone who would be throwing insults.) JFC...thanks, -- David Coallier, --- ## #32068 — Jani Taskinen — 2007-09-05T14:15:05+00:00 URL: https://externals.io/message/32012#32068 · In reply to: #32065 [lot of crap cut to save the innocent] > Examine the bug tracker, it appears it's a slow process for the > majority of bugs related to Mac OS X. There's good reason to it: Most of us don't want to spend ridiculous amount of money just to get a regular PC branded as Apple just to be able to run MacOSX when you can just install any *BSD / Linux variant for free in your existing PC. :) I added the most expensive one I could find to my wishlist. Now go and buy it for me so that I can fix these issues and everyone will be happy. And most of all, I'll be happy. And when I'm happy, I usually try to use "please" and other niceties in my mails. :D --Jani -- Make me happy: http://pecl.php.net/wishlist.php/jani --- ## #32069 — BuildSmart — 2007-09-05T15:32:40+00:00 URL: https://externals.io/message/32012#32069 · In reply to: #32067 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > > […] > > I'll repeat again, if anyone has a personal problem with someone else, > either take it offlist, take a beer or see a psychiatrist. We don't > care if you don't like someone else, do it elsewhere, this list is for > PHP issues, not personal issues. (And I'm not only talking about you > mr. BS, this applies to anyone who would be throwing insults.) > > JFC...thanks, > > > -- > David Coallier, I would have thought that my last statement was an effort to remove this bantering from the public list, if you want it gone from the list then why address it publicly and complain about it publicly. If you're speaking to me, you'd be better off addressing me properly and with a little respect if you don't want to be ignored and expect to be taken seriously rather than contributing to the abusive nature of certain individuals and if you're acting in some kind of professional capacity, please do so in a professional manner and refrain from singling out any one participant if you are responding in a public forum setting such as a mailing list, this would display your ability to effectively manage the environment without bias and prejudice rather than look like someone who has to get a lick or two in themselves, nobody likes a dirty cop. - -- Dale -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFG3swZ0hzWbkf0eKgRAmZ7AKDKJ0F/1p6MzeQ4OMGI9sq1oyHRvgCfQpMw TL/fcZjdPSXxnnlU+P9fD80= =hkkd -----END PGP SIGNATURE