17 years ago by BuildSmart — view source

unread

-----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 forconfig.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 functionmain' 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

17 years ago by Jani Taskinen — view source

unread

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 forconfig.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 functionmain' 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-----

--
Make me happy: http://pecl.php.net/wishlist.php/jani

17 years ago by BuildSmart — view source

unread

-----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

-----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 forconfig.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 functionmain' 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-----

--
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

17 years ago by Hartmut Holzgraefe — view source

unread

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

17 years ago by David Coallier — view source

unread

-----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.

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,

--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 forconfig.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 functionmain' 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-----

--
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-----

--

--
David Coallier,
Founder & Software Architect,
Agora Production (http://agoraproduction.com)
51.42.06.70.18

17 years ago by nicobn@gmail.com — view source

unread

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

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

-----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 forconfig.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 functionmain' 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-----

--
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-----

--

--
Nicolas Bérard-Nault (nicobn@gmail.com)
Étudiant D.E.C. Sciences, Lettres & Arts
Cégep de Sherbrooke

Homepage: http://nicobn.googlepages.com

17 years ago by BuildSmart — view source

unread

-----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 <math.h>
/* keep this out-of-line to prevent use of gcc inline floor() /
double somefn(double n) {
return floor(npow(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

17 years ago by Pierre — view source

unread

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

17 years ago by BuildSmart — view source

unread

-----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

17 years ago by Pierre — view source

unread

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

17 years ago by Hartmut Holzgraefe — view source

unread

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

17 years ago by BuildSmart — view source

unread

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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 ... :(

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

17 years ago by Stut — view source

unread

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

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 ... :(

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

17 years ago by BuildSmart — view source

unread

-----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:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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 ... :(
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)

iD8DBQFG3cKG0hzWbkf0eKgRAjojAJ0YFSWSUCjDOK1fW1i7S00IAMho1QCfWuk/
HsWZYVM16GS0cBi+tBNaw4k=
=iaKb
-----END PGP SIGNATURE

17 years ago by Hartmut Holzgraefe — view source

unread

Hello Mr BS

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

17 years ago by William A. Rowe — view source

unread

Hartmut Holzgraefe wrote:

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

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

17 years ago by BuildSmart — view source

unread

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Mr BS

hmm, not my name or my pseudonym but the remainder of this post
appears to have been written by me, dyslexic are you?

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?

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?

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?

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.

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

Examine the bug tracker, it appears it's a slow process for the
majority of bugs related to Mac OS X.

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"

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 believe it's best to refrain from such submission unless it's
absolutely critical.

well, if you think so ...

I'm sorry that your ability to perceive more than the written word is
non-existent.

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 ...

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

17 years ago by David Coallier — view source

unread

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Mr BS

hmm, not my name or my pseudonym but the remainder of this post
appears to have been written by me, dyslexic are you?

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?

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?

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?

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.

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

Examine the bug tracker, it appears it's a slow process for the
majority of bugs related to Mac OS X.

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"

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 believe it's best to refrain from such submission unless it's
absolutely critical.

well, if you think so ...

I'm sorry that your ability to perceive more than the written word is
non-existent.

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 ...

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-----

--

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,

17 years ago by BuildSmart — view source

unread

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Mr BS

hmm, not my name or my pseudonym but the remainder of this post
appears to have been written by me, dyslexic are you?

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?

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?

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?

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.

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

Examine the bug tracker, it appears it's a slow process for the
majority of bugs related to Mac OS X.

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"

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 believe it's best to refrain from such submission unless it's
absolutely critical.

well, if you think so ...

I'm sorry that your ability to perceive more than the written word is
non-existent.

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 ...

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-----

--

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

17 years ago by Jani Taskinen — view source

unread

[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

17 years ago by Nuno Lopes — view source

unread

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

17 years ago by Antony Dovgal — view source

unread

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

17 years ago by Stanislav Malyshev — view source

unread

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

17 years ago by Hartmut Holzgraefe — view source

unread

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

buildconf and the generated configure script for PHP6 is faulty.

Name of the host.

hostname on some systems (SVR3.2, Linux) returns a bogus exit status,

so uname gets run too.

Name of the host.

hostname on some systems (SVR3.2, Linux) returns a bogus exit status,

so uname gets run too.

Name of the host.

hostname on some systems (SVR3.2, Linux) returns a bogus exit

so uname gets run too.

Name of the host.

hostname on some systems (SVR3.2, Linux) returns a bogus exit

so uname gets run too.

Name of the host.

hostname on some systems (SVR3.2, Linux) returns a bogus exit

so uname gets run too.

Of course, nobody could demand from you to contribute your fixes or your information back - but it is a good citizenship if you do.

Of course, nobody could demand from you to contribute your fixes or your
information back - but it is a good citizenship if you do.