FAQ
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

Search Discussions

  • Jani Taskinen at Sep 3, 2007 at 8:59 am
    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
    On Mon, 2007-09-03 at 01:55 -0400, BuildSmart wrote:
    -----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

    --
    Make me happy: http://pecl.php.net/wishlist.php/jani
  • BuildSmart at Sep 3, 2007 at 12:55 pm

    On Sep 3, 2007, at 04:58:51, Jani Taskinen wrote:

    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
    On Mon, 2007-09-03 at 01:55 -0400, BuildSmart wrote:
    -----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

    --
    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
  • Hartmut Holzgraefe at Sep 3, 2007 at 1:45 pm
    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
  • BuildSmart at Sep 3, 2007 at 7:51 pm

    On Sep 3, 2007, at 15:21:26, Hartmut Holzgraefe wrote:

    Dear Mr. BuildSmart
    I didn't change my autoconf to correct the problem, that is an
    assumption on your part,
    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.
    I edited 2 lines in a m4 file supplied in the PHP6 distro.
    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
  • BuildSmart at Sep 3, 2007 at 10:10 pm
    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(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
  • Pierre at Sep 4, 2007 at 9:24 am
    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
  • BuildSmart at Sep 4, 2007 at 10:39 am
    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

    On Sep 4, 2007, at 05:24:13, Pierre wrote:

    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
  • Pierre at Sep 4, 2007 at 10:50 am

    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
  • Hartmut Holzgraefe at Sep 4, 2007 at 1:02 pm
    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
  • BuildSmart at Sep 4, 2007 at 5:48 pm

    On Sep 4, 2007, at 09:02:23, Hartmut Holzgraefe wrote:

    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
  • Stut at Sep 4, 2007 at 6:07 pm
    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

    On Sep 4, 2007, at 09:02:23, Hartmut Holzgraefe wrote:

    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



    --PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • BuildSmart at Sep 4, 2007 at 8:39 pm

    On Sep 4, 2007, at 14:07:35, Stut wrote:

    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
    On Sep 4, 2007, at 09:02:23, Hartmut Holzgraefe wrote:
    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
  • Hartmut Holzgraefe at Sep 5, 2007 at 10:01 am
    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
  • William A. Rowe, Jr. at Sep 5, 2007 at 12:49 pm

    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
  • BuildSmart at Sep 5, 2007 at 1:50 pm

    On Sep 5, 2007, at 06:00:41, Hartmut Holzgraefe wrote:

    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?
    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
  • David Coallier at Sep 5, 2007 at 2:06 pm

    On 9/5/07, BuildSmart wrote:
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    On Sep 5, 2007, at 06:00:41, Hartmut Holzgraefe wrote:

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




    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
    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,
  • BuildSmart at Sep 5, 2007 at 3:33 pm

    On Sep 5, 2007, at 10:06:45, David Coallier wrote:
    On 9/5/07, BuildSmart wrote:
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    On Sep 5, 2007, at 06:00:41, Hartmut Holzgraefe wrote:

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




    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
    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
  • Jani Taskinen at Sep 5, 2007 at 2:15 pm
    On Wed, 2007-09-05 at 09:49 -0400, BuildSmart wrote:
    [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
  • Nuno Lopes at Sep 4, 2007 at 6:20 pm

    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
  • Antony Dovgal at Sep 4, 2007 at 6:34 pm

    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
  • Stanislav Malyshev at Sep 4, 2007 at 7:43 pm

    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
  • Hartmut Holzgraefe at Sep 4, 2007 at 10:47 pm
    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
  • David Coallier at Sep 3, 2007 at 1:52 pm

    On 9/3/07, BuildSmart wrote:
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    On Sep 3, 2007, at 04:58:51, Jani Taskinen wrote:

    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
    On Mon, 2007-09-03 at 01:55 -0400, BuildSmart wrote:
    -----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

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

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php

    --
    David Coallier,
    Founder & Software Architect,
    Agora Production (http://agoraproduction.com)
    51.42.06.70.18
  • Nicolas Bérard-Nault at Sep 3, 2007 at 2:54 pm
    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,
    On 9/3/07, BuildSmart wrote:

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

    On Sep 3, 2007, at 04:58:51, Jani Taskinen wrote:

    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
    On Mon, 2007-09-03 at 01:55 -0400, BuildSmart wrote:
    -----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

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

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php

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

    Homepage: http://nicobn.googlepages.com

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedSep 3, '07 at 5:55a
activeSep 5, '07 at 3:33p
posts25
users11
websitephp.net

People

Translate

site design / logo © 2022 Grokbase