Re: [PHP-DEV] Again scope

[Xavier Spriet]

This isn't a PHP problem.
use $this->Bar(); on line 14


On Fri, 2003-01-31 at 15:03, michel 'ziobudda' morelli wrote:
>  Class Foo {
>  var $foo2;
> 
>  Function Bar()
>  {
>   echo $foo2."\n";
>   print "Bar";
>  }
> 
>  Function Bar2()
>  {
>   $foo2="foo2";
>   Bar();
>  }
> }
> 
> $f = new foo;
> $f->Bar2();
> ?>
> 
> give me this error: 
> 
> Fatal error: Call to undefined function:  bar() in
> /home/httpd/html/PHP/test/3.php on line 14
> 
> I'm using php-cli from cvs (2 weeks ago). 
> 
> And there is a variable scope (for the class).
> 
> 
> -- 
> michel 'ziobudda' morelli <[EMAIL PROTECTED]>
-- 
Xavier Spriet <[EMAIL PROTECTED]>


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

Re: [PHP-DEV] RfC: version names

[Xavier Spriet]

A very simple solution would simply be to do something like
ls --full-time configure
that allows you to find at what exact time buildconf was used so
pretty much when it was built.

This would be much easier to implement since you don't have to touch CVS
at any time for that... right ?

On Fri, 2003-01-31 at 08:29, Kai Schröder wrote:
> Hi all,
> 
> I'm working on a new framework for analyzing results of "make test" for QA
> Team (see php-qa list).
> 
> Talking with Sebastian Nohn, I realized, that we can't differ the versions
> in detail. That means, that we can't say which source packet was used to
> build php. Is there any way to name the versions 4.3.0 (release), 4.3.1-dev
> (taken from cvs, additional timestamp would be nice), 4.3.1-snapMMDDHHii
> (taken from snaps.php.net) and 4.3.1-win32-snapMMDDHHii (Win32
> Snapshot)?
> 
> This will make it more easy to follow the development and ignore allready
> fixed bugs. The goal is to find out which commit is the reason for the
> failure on which systems. If this works fine, we are able to add detailed
> comments to bugs.php.net and reopen automatic already closed bugs.
> 
> Regards, Kai
-- 
Xavier Spriet <[EMAIL PROTECTED]>


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

Re: [PHP-DEV] CVS Account Request: hitweb

[Xavier Spriet]

On Tue, 2003-01-21 at 18:57, Brian FRAVAL wrote:
> Because I want a mail @php.net.

Heck... I want one of these too !!

>  And I want help you for translating the documentation.

It would be nice to know in what language you intend to work on the
translation... ?

-- 
Xavier Spriet <[EMAIL PROTECTED]>


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

Re: [PHP-DEV] PHP Bug #17868: Multiple Includes

[Xavier Spriet]

Seems to me like there's not much that can be done on the php side but
more on the apache side.
In the meantime I'd suggest migrating your server to Apache 1.3.27 until
the problem is fixed since this may take quite a while.


On Mon, 2003-01-20 at 09:28, Michael D. Petersen wrote:
> The problem is described in a little more detail here:
> http://bugs.php.net/bug.php?id=17868

-- 
Xavier Spriet <[EMAIL PROTECTED]>


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

Re: [PHP-DEV] [Win32] Install Problems....

[Xavier Spriet]

You'll find the latest development snapshot on http://snaps.php.net



On Wed, 2003-01-15 at 14:24, Red Wingate wrote:
>  don't know where i can get a stable version.
> 
> Enviroment:
> Win2000 SP3 with Apache 2.0.43
> 
> --- Red Wingate
> 
> p.s: plz dont flame about my english :)
-- 
Xavier Spriet <[EMAIL PROTECTED]>


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

Re: [PHP-DEV] PHP Look Back 2002

[Xavier Spriet]

This is impressive work!
I have to say what I've seen of the PHP development team during 2002 is
very encouraging for the future and I wish you all you guys a great year
for 2003.

Thanks,


On Mon, 2002-12-30 at 16:23, Derick Rethans wrote:
> Hello!
> 
> We are almost at the end of 2002, and it seemed appropriate to look back
> on the development issues of the past year. So starts the first PHP Look
> Back! You can find it @ http://www.derickrethans.nl/20021230.php, and if 
> you have any comments,feel free to post them with the link at the bottom 
> of the page.
> 
> Have fun reading!
> 
> Derick
> 
> -- 
> 
> -
>  Derick Rethans http://derickrethans.nl/
>  JDI Media Solutions http://www.jdimedia.nl/
>  PHP Magazine - PHP Magazine for Professionals   http://php-mag.net/
> ---------
> 
-- 
Xavier Spriet <[EMAIL PROTECTED]>


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

Re: [PHP-DEV] -+ [01]

[Xavier Spriet]

Well it's up to whoever has karma to make that decision.
People can give their opinion obviously but shouldn't expect to actually
make the decision.


On Wed, 2002-12-18 at 18:43, Sterling Hughes wrote:
> Hey,
> 
> Just clarifying: We never agreed that -+[01] meant anything except a short
> way of:
> 
> -1 = I strongly disagree
> -0 = I disagree
> 0 = neutral
> +0 = I agree
> +1 = I strongly agree
> 
> ie, We don't have a voting system.  If someone, let's call him Barney, says 
> "-1 on this issue," all that means is that Barney disagrees, but that doesn't
> (like in Apache circles[1]), mean that this is blocked.
> 
> Right?
> 
> -Sterling
> 
> [1] If Barney can give a technical reason for blocking it, and can offer an 
> alternative solution.
-- 
Xavier Spriet <[EMAIL PROTECTED]>


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

Re: [PHP-DEV] CGI and CLI

[Xavier Spriet]

Looks good enough for me, I don't see a problem with that.

On Wed, 2002-12-18 at 17:39, Shane Caraveo wrote:
> No.  At the most, if anything, CLI should output an error message:
> 
> if(getenv("GATEWAY_INTERFACE") != NULL) {
>printf("This is the PHP CLI binary, please configure your server to 
> use the correct PHP CGI binary.");
>exit(1);
> }
> 
> Xavier Spriet wrote:
> > Great.
> > In that case, in order to make things a little smoother for users, could
> > a little workaround like the one offered by Robin be considered ?
> > 
> > 
> > 
> > On Wed, 2002-12-18 at 17:21, Andrei Zmievski wrote:
> > 
> >>On Wed, 18 Dec 2002, Philip Olson wrote:
> >>
> >>>So every tutorial and documentation on this would have to
> >>>say this right?
> >>>
> >>>  "Ask your sysadmin what the CGI and CLI versions of your
> >>>   PHP are called, they could be anything as there is no
> >>>   standard.  For the purpose of this (tutorial|documentation), 
> >>>   we'll call CLI php-cli and CGI php-cgi."
> >>>
> >>>Same goes for all cgi scripts, they'll work some places but
> >>>not others...  And various RPM's would have different naming
> >>>schemes depending on the maintainers preference.
> >>
> >>The merging of CLI and CGI will still happen, but in 4.3.1.
> >>
> >>-Andrei   http://www.gravitonic.com/
> >>* Marriage is not a word. It's a sentence. Life-long sentence. *
-- 
Xavier Spriet <[EMAIL PROTECTED]>


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

Re: [PHP-DEV] CGI and CLI

[Xavier Spriet]

Great.
In that case, in order to make things a little smoother for users, could
a little workaround like the one offered by Robin be considered ?



On Wed, 2002-12-18 at 17:21, Andrei Zmievski wrote:
> On Wed, 18 Dec 2002, Philip Olson wrote:
> > 
> > So every tutorial and documentation on this would have to
> > say this right?
> > 
> >   "Ask your sysadmin what the CGI and CLI versions of your
> >PHP are called, they could be anything as there is no
> >standard.  For the purpose of this (tutorial|documentation), 
> >we'll call CLI php-cli and CGI php-cgi."
> > 
> > Same goes for all cgi scripts, they'll work some places but
> > not others...  And various RPM's would have different naming
> > schemes depending on the maintainers preference.
> 
> The merging of CLI and CGI will still happen, but in 4.3.1.
> 
> -Andrei       http://www.gravitonic.com/
> * Marriage is not a word. It's a sentence. Life-long sentence. *
-- 
Xavier Spriet <[EMAIL PROTECTED]>


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

RE: [PHP-DEV] CGI and CLI

[Xavier Spriet]

On Wed, 2002-12-18 at 16:17, Sebastian Nohn wrote:
> Again: Thousands if not millions of servers use PHP as CGI.

>> PHP-CGI will _NOT_ be renamed either.


>  Who uses PHP for
> CLI-apps? 100? 1000? 5000? If you use experimental technology you always
> MUST have in mind that anything can change anytime. Why was'nt PHP available
> for Apache 2 for a long time (is it in the meantime btw.?)?. Because Apache
> Group continiously changed their API.
> > -----Original Message-
> > From: Xavier Spriet [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, December 18, 2002 9:53 PM
> > To: Sebastian Nohn
> > Cc: Sterling Hughes; Andrei Zmievski; PHP Developers
> > Subject: RE: [PHP-DEV] CGI and CLI
> >
> >
> > Experimental or not, people use it and have developed a need for it.
> > Many apps out there are based on experimental technology, that's not a
> > reason to break them all...
> >
> > On Wed, 2002-12-18 at 15:48, Sebastian Nohn wrote:
> > > > -Original Message-----
> > > > From: Sterling Hughes [mailto:[EMAIL PROTECTED]]
> > > > Sent: Wednesday, December 18, 2002 9:30 PM
> > > > To: Xavier Spriet
> > > > Cc: Andrei Zmievski; PHP Developers
> > > > Subject: Re: [PHP-DEV] CGI and CLI
> > > >
> > > >
> > > > > This note from Derick pretty much reflects the idea... it
> > makes sense:
> > > > > 
> > > > > I see that renaming the CGI to php-cgi might break things
> > indeed, and
> > > > > that's never a good idea. But so is changing the name of
> > the CLI (php)
> > > > > to something else. It also breaks things, not only for me,
> > but also for
> > > > > countless others using the CLI with the name 'php'. We also need to
> > > > > think about these users as well. This leaves my opinion
> > that i'm -1 on
> > > > > renaming the CLI to something else, and i'm a -0 (yes this
> > changed :) on
> > > > > renaming the CGI. This leaves the (IMO) only possible solution:
> > > > > integrate them back into one binary and adding some magic
> > which triggers
> > > > > CLI or CGI mode (perhaps to check for some environment variable).
> > > > > 
> > > > >
> > > >
> > > > Hrmm, how does renaming php-cli break compatibility between PHP
> > > > _releases_?
> > >
> > > In no way! PHP-CLI always was marked as experimental.
> > >
> > > MfG, Sebastian
> > --
> > Xavier Spriet <[EMAIL PROTECTED]>
> >
> >
-- 
Xavier Spriet <[EMAIL PROTECTED]>


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

RE: [PHP-DEV] CGI and CLI

[Xavier Spriet]

> I think a lot more users will be pissed of when renaming php to php-cgi than
> regarding to the cli-version of php as php-cli or phpsh or anything else.
> The best solution would be indeed bundling both to one binary. If this
> delays a 4.3.0-release? I don't give a damn about it! The idea "release
> fast, release often" is completely ridiculous in my eyes.
> 
> If you would like to release 4.3.0 as soon as possible simply let php be php
> (i talk about the cgi-version), mark cgi still as experimental and work on
> the integration to one binary for 4.3.1 or 5.0.0.
> 
This is not even the issue here since both would be merged together in
one binary that would be able to figure out in which context it was
called..
I agree for the delay... Quality > Quantity


> Regards,
>Sebastian Nohn
> --
> [EMAIL PROTECTED] - http://www.nohn.net/
> PGP Key Available - Did I help you? Consider a gift:
> http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/
-- 
Xavier Spriet <[EMAIL PROTECTED]>


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

Re: [PHP-DEV] CGI and CLI

[Xavier Spriet]

If it gets done that way it will be really confusing for everyone...
All users used to CLI as "php" will need to switch to "php-cli" for
4.3.0 then back to "php" afterwards ?
I think if there's not enough time to merge both back together, it would
be wiser to wait a bit, at least until it's done if it isn't already
done.

On Wed, 2002-12-18 at 16:03, Andi Gutmans wrote:
> At 03:54 PM 12/18/2002 -0500, Andrei Zmievski wrote:
> >On Wed, 18 Dec 2002, Xavier Spriet wrote:
> > > Experimental or not, people use it and have developed a need for it.
> > > Many apps out there are based on experimental technology, that's not a
> > > reason to break them all...
> >
> >So I strongly suggest that whoever has the necessary knowledge on how to
> >merge CGI and CLI back together come forward and do this. Let's get
> >4.3.0 out the door and move on to the new great things.
> 
> I doubt this will happen fast enough. We should just release the way we 
> released 4.2.x, which as far as I know was php for CGI and php-cli for CLI 
> or am I a bit behind things? :)
> 
> Andi
-- 
Xavier Spriet <[EMAIL PROTECTED]>


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

RE: [PHP-DEV] CGI and CLI

[Xavier Spriet]

Experimental or not, people use it and have developed a need for it.
Many apps out there are based on experimental technology, that's not a
reason to break them all...

On Wed, 2002-12-18 at 15:48, Sebastian Nohn wrote:
> > -Original Message-
> > From: Sterling Hughes [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, December 18, 2002 9:30 PM
> > To: Xavier Spriet
> > Cc: Andrei Zmievski; PHP Developers
> > Subject: Re: [PHP-DEV] CGI and CLI
> >
> >
> > > This note from Derick pretty much reflects the idea... it makes sense:
> > > 
> > > I see that renaming the CGI to php-cgi might break things indeed, and
> > > that's never a good idea. But so is changing the name of the CLI (php)
> > > to something else. It also breaks things, not only for me, but also for
> > > countless others using the CLI with the name 'php'. We also need to
> > > think about these users as well. This leaves my opinion that i'm -1 on
> > > renaming the CLI to something else, and i'm a -0 (yes this changed :) on
> > > renaming the CGI. This leaves the (IMO) only possible solution:
> > > integrate them back into one binary and adding some magic which triggers
> > > CLI or CGI mode (perhaps to check for some environment variable).
> > > 
> > >
> >
> > Hrmm, how does renaming php-cli break compatibility between PHP
> > _releases_?
> 
> In no way! PHP-CLI always was marked as experimental.
> 
> MfG, Sebastian
-- 
Xavier Spriet <[EMAIL PROTECTED]>


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

Re: [PHP-DEV] CGI and CLI

[Xavier Spriet]

The problems that can occur that I can think of are:
- Crontabs calling the php CLI binary
- CLI scripts starting with #!/usr/bin/php
- Scripts from other languages calling for a specific binary
- and also all the users that call the CLI binary directly by its name.

I agree that the old binary will still remain there but then none of
these scenarios can actually benefit of a new release if it actually
fixes a bug preventing it from working properly.

On Wed, 2002-12-18 at 15:30, Sterling Hughes wrote:
> > This note from Derick pretty much reflects the idea... it makes sense:
> > 
> > I see that renaming the CGI to php-cgi might break things indeed, and 
> > that's never a good idea. But so is changing the name of the CLI (php) 
> > to something else. It also breaks things, not only for me, but also for 
> > countless others using the CLI with the name 'php'. We also need to 
> > think about these users as well. This leaves my opinion that i'm -1 on 
> > renaming the CLI to something else, and i'm a -0 (yes this changed :) on
> > renaming the CGI. This leaves the (IMO) only possible solution: 
> > integrate them back into one binary and adding some magic which triggers
> > CLI or CGI mode (perhaps to check for some environment variable).
> > 
> >
> 
> Hrmm, how does renaming php-cli break compatibility between PHP _releases_?
> 
> -Sterling
> 
> > 
> > On Wed, 2002-12-18 at 14:59, Andrei Zmievski wrote:
> > > What was the consensus on CGI vs. CLI naming or merging issue? Or was
> > > there a consensus at all? I full plan to go ahead with 4.3.0 release
> > > before the end of the year, so those interested in doing anything about
> > > this issue better get their butts in gear.
> > > 
> > > -Andrei   http://www.gravitonic.com/
> > > 
> > > "This isn't right. This isn't even wrong."
> > >-- Wolfgang Pauli
> > -- 
> > Xavier Spriet <[EMAIL PROTECTED]>
> > 
> > 
> > -- 
> > PHP Development Mailing List <http://www.php.net/>
> > To unsubscribe, visit: http://www.php.net/unsub.php
> > 
-- 
Xavier Spriet <[EMAIL PROTECTED]>


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

Re: [PHP-DEV] CGI and CLI

[Xavier Spriet]

This note from Derick pretty much reflects the idea... it makes sense:

I see that renaming the CGI to php-cgi might break things indeed, and 
that's never a good idea. But so is changing the name of the CLI (php) 
to something else. It also breaks things, not only for me, but also for 
countless others using the CLI with the name 'php'. We also need to 
think about these users as well. This leaves my opinion that i'm -1 on 
renaming the CLI to something else, and i'm a -0 (yes this changed :) on
renaming the CGI. This leaves the (IMO) only possible solution: 
integrate them back into one binary and adding some magic which triggers
CLI or CGI mode (perhaps to check for some environment variable).



On Wed, 2002-12-18 at 14:59, Andrei Zmievski wrote:
> What was the consensus on CGI vs. CLI naming or merging issue? Or was
> there a consensus at all? I full plan to go ahead with 4.3.0 release
> before the end of the year, so those interested in doing anything about
> this issue better get their butts in gear.
> 
> -Andrei   http://www.gravitonic.com/
> 
> "This isn't right. This isn't even wrong."
>-- Wolfgang Pauli
-- 
Xavier Spriet <[EMAIL PROTECTED]>


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

Re: [PHP-DEV] PHP building on Linux: A question on configurescript!

[Xavier Spriet]

Just a couple of comments, see below.

On Tue, 2002-12-17 at 00:36, Ananth Kesari wrote:
> Well, we could figure out this as of now. Thanks for your response. We will get back 
>if we have further problems.
> 
> Thanks,
> Ananth.
> 
> >>> Derick Rethans <[EMAIL PROTECTED]> 12/13/02 08:04PM >>>
> Hi,
> 
> On Fri, 13 Dec 2002, Ananth Kesari wrote:
> 
> > To build for Apache on Unix, it appears that we have to use the
> > following options in the configure script to get the equivalent of
> > what I mentioned above:
> > 
> > --with-apache= --disable-posix 
> > --with-mysql=shared --with-ldap=shared --enable-ftp --enable-bcmath 
> > --enable-calendar
> > 
> > The problem in this approach is that we seem to be getting a static
> > library (xxx.a) as an output. We are not clear what we are supposed to
> > do with this library! Perhaps this needs to be then built along with
> > Apache into the Apache executable.
> 
> Yup, you're correct with that statement.

In order to build it along, you would configure your apache with the
--activate-module=src/modules/php4/libphp4.a


> 
> > 
> > There is an option called:
> > 
> > --with-apxs=
> > 
> > which seems to produce a "DSO" which doesn't seem to work on Linux.
> > The build fails due to errors in the apxs script.
> 
> --with-apxs would be the way to go, what errors do you get? Are you
> using Apache 1.3 or a 2.0 series?
> 
> Derick

It might also be relevant to know how you built apache and with what
options... I'm not 100% sure but I believe apxs will only be installed
if you use --enable-module=so
I could be wrong or even off-topic though.


> 
> -- 
> 
> -
>  Derick Rethans http://derickrethans.nl/
>  PHP Magazine - PHP Magazine for Professionals   http://php-mag.net/
> -
> 
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
-- 
Xavier Spriet <[EMAIL PROTECTED]>


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

[PHP-DEV] url_rewriter maximum buffer size

[Xavier Spriet]

After switching to PHP 4.2.3 for awhile, it seems the url_rewriter bug
is still present at some level (though much less than before).
Some users reported some errors during parsing of long URLs.
I have been trying to see if I could fix this problem myself or at least
identify it but with no success...

I'm looking for a problem in the following function:
int php_url_scanner_add_var(char *name, int name_len, char *value, int
value_len, int urlencode TSRMLS_DC)

in  ext/standard/url_scanner_ex.re

Am I even in the right direction ?

Thanks.

Xavier Spriet.
[EMAIL PROTECTED]



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

Re: [PHP-DEV] PHP mem leaks

[Xavier Spriet]

what version of mod_ssl are you using ?
your situation looks very familiar since I experienced the same problem,
the issue was mod_ssl, there is a new version available to fix this bug.
(buffer overflow).

Thanks.

Xavier Spriet.
[EMAIL PROTECTED]


On Thu, 2002-09-12 at 08:58, John Wards wrote:
> Oooops.
> 
> We are running Apache/1.3.26, PHP/4.2.2 mod_ssl/2.8.9 under FreeBSD 4.6.
> Apache modules:
> 
> mod_php4, mod_ssl, mod_setenvif, mod_so, mod_auth, mod_access, mod_alias,
> mod_userdir, mod_actions, mod_imap, mod_asis, mod_cgi, mod_dir,
> mod_autoindex, mod_include, mod_status, mod_negotiation, mod_mime,
> mod_log_config, mod_env, http_core
> 
> all compiled in except for mod_php4 and mod_ssl which are loaded using
> LoadModule.
> - Original Message -
> From: "Xavier Spriet" <[EMAIL PROTECTED]>
> To: "John Wards" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Thursday, September 12, 2002 1:49 PM
> Subject: Re: [PHP-DEV] PHP mem leaks
> 
> 
> > Could you please let us know what modules it is that you're using as
> > well...
> >
> > Thanks,
> >
> > Xavier Spriet
> > [EMAIL PROTECTED]
> >
> >
> > On Thu, 2002-09-12 at 08:52, John Wards wrote:
> > > Shoot me down if this should go on the gen list but I think this
> question
> > > would get a better answer on this list.
> > >
> > > I am running a large PHP/MySQL/Apache driven website and I am finding
> that
> > > the apache Processes get larger and larger as the days go on. When I
> > > stop/start apache the processes are around 16-17 meg each and after a
> week
> > > they are about 40meg each and if we then get a large in flux of traffic
> say
> > > a Monday lunch time the server just pages out and dies...
> > >
> > > I have been on the apache list given them all my modules that I have
> running
> > > and they pointed the finger at PHP, I was told to change
> maxrequestsperchild
> > > to 100 but this made no difference. Is there a fix for this? or a
> planned
> > > fix for this?
> > >
> > > Cheers
> > > John Wards
> > > SportNetwork.net
> > >
> > >
> > > --
> > > PHP Development Mailing List <http://www.php.net/>
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> >
> >
> > --
> > PHP Development Mailing List <http://www.php.net/>
> > To unsubscribe, visit: http://www.php.net/unsub.php
> 


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

Re: [PHP-DEV] PHP mem leaks

[Xavier Spriet]

Could you please let us know what modules it is that you're using as
well...

Thanks,

Xavier Spriet
[EMAIL PROTECTED]


On Thu, 2002-09-12 at 08:52, John Wards wrote:
> Shoot me down if this should go on the gen list but I think this question
> would get a better answer on this list.
> 
> I am running a large PHP/MySQL/Apache driven website and I am finding that
> the apache Processes get larger and larger as the days go on. When I
> stop/start apache the processes are around 16-17 meg each and after a week
> they are about 40meg each and if we then get a large in flux of traffic say
> a Monday lunch time the server just pages out and dies...
> 
> I have been on the apache list given them all my modules that I have running
> and they pointed the finger at PHP, I was told to change maxrequestsperchild
> to 100 but this made no difference. Is there a fix for this? or a planned
> fix for this?
> 
> Cheers
> John Wards
> SportNetwork.net
> 
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


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

RE: [PHP-DEV] php.ini include directive

[Xavier Spriet]

We are indeed talking about the same thing, this is exactly how I was
seeing it also.
It would definitely help keep things organized since I imagine if this
was implemented, the old way of doing it would still remain possible so
I don't see why not, though I have no idea of what the technical
difficulty would be.

XS

On Wed, 2002-09-11 at 14:15, Brian France wrote:
> I don't think we are talking about the same thing.
> 
> I would like to do something like this:
> 
> php.ini
> ---
> [PHP]
> 
> include = php-mbstring.ini
> ---
> 
> php-mbstring.ini
> ---
> [mbstring]
> mbstring.internal_encoding = EUC-JP
> mbstring.http_input = auto
> mbstring.http_output = EUC-JP
> mbstring.detect_order = auto
> mbstring.substitute_character = none;
> ---
> 
> or this would include all .ini files from the include directory
> 
> php.ini
> ---
> [PHP]
> 
> include = include/
> ---
> 
> 
> Or may be a something like this:
> 
> php.ini
> ---
> [PHP]
> 
> 
> [INCLUDE]
> file = php-mbstring.ini
> file = php-mysql.ini
> directory = include/
> ---
> 
> Brian
> 
> 
> At 1:59 PM -0400 9/11/02, [EMAIL PROTECTED] wrote:
> >I see how this could be useful, possibly for custom session handlers or
> >including something at the top of every file for free hosted customers or
> >something (so that they can't get around the ads or whatever).
> >
> >Anyway, I don't know.  I give this maybe +.25 for right now, see what
> >reactions are.
> >
> >I could put together a quick patch for this if people thought it would be
> >useful.  If you guys like the idea, lemme know, and I'll patch it.
> >
> >Devon
> >
> >Original Message:
> >-
> >From: Brian France [EMAIL PROTECTED]
> >Date: Wed, 11 Sep 2002 10:56:06 -0700
> >To: [EMAIL PROTECTED]
> >Subject: [PHP-DEV] php.ini include directive
> >
> >
> >Has anybody looked into doing a include directive for the php.ini file?
> >
> >Something like what Apache has?
> >
> >http://httpd.apache.org/docs/mod/core.html#include
> >
> >Thoughts?
> >
> >Cheers,
> >
> >Brian
> >
> >--
> >PHP Development Mailing List 
> >To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
> >
> >mail2web - Check your email from the web at
> >http://mail2web.com/ .
> >
> >
> >
> >--
> >PHP Development Mailing List 
> >To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


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

RE: [PHP-DEV] php.ini include directive

[Xavier Spriet]

I believe what Brian meant was to be able to use multiple configuration
file.
I believe there is already an implementation of what you are referring
to.
auto_append_file and auto_prepend_file if I'm correct.
Using multiple configuration files could also be an interesting thing.

Xavier Spriet
[EMAIL PROTECTED]


On Wed, 2002-09-11 at 13:59, [EMAIL PROTECTED] wrote:
> I see how this could be useful, possibly for custom session handlers or
> including something at the top of every file for free hosted customers or
> something (so that they can't get around the ads or whatever).
> 
> Anyway, I don't know.  I give this maybe +.25 for right now, see what
> reactions are.
> 
> I could put together a quick patch for this if people thought it would be
> useful.  If you guys like the idea, lemme know, and I'll patch it.
> 
> Devon
> 
> Original Message:
> -
> From: Brian France [EMAIL PROTECTED]
> Date: Wed, 11 Sep 2002 10:56:06 -0700
> To: [EMAIL PROTECTED]
> Subject: [PHP-DEV] php.ini include directive
> 
> 
> Has anybody looked into doing a include directive for the php.ini file?
> 
> Something like what Apache has?
> 
> http://httpd.apache.org/docs/mod/core.html#include
> 
> Thoughts?
> 
> Cheers,
> 
> Brian
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 
> 
> mail2web - Check your email from the web at
> http://mail2web.com/ .
> 
> 
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


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

Re: [PHP-DEV] http://www.php-con.com/

[Xavier Spriet]

this is still the wrong list.

On Thu, 2002-09-05 at 08:56, Andrey Hristov wrote:
> I meant gray background .
> 
> 
> Andrey
> 
> - Original Message -
> From: "Andrey Hristov" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, September 05, 2002 3:53 PM
> Subject: [PHP-DEV] http://www.php-con.com/
> 
> 
> > Hi,
> > can someone change the HTML of http://www.php-con.com/ and add
> > bgcolor="#FF" in the  tag.
> > My default theme is with gray font so the page is not looking so nice :)))
> >
> > Andrey
> >
> >
> >
> >
> > --
> > PHP Development Mailing List 
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


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

Re: [PHP-DEV] PHP 4.2.3 release.

[Xavier Spriet]

my bad...
it was indeed a user error...
Thanks everyone  ;)


On Wed, 2002-09-04 at 14:09, Mike Hall wrote:
> Beat me to it! :-)
> 
> - Original Message - 
> From: "Rasmus Lerdorf" <[EMAIL PROTECTED]>
> To: "Xavier Spriet" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Wednesday, September 04, 2002 6:50 PM
> Subject: Re: [PHP-DEV] PHP 4.2.3 release.
> 
> 
> > This is not a bug.  Your syntax is wrong.  It should be:
> > 
> > fields[tech_id][]
> > 
> > -Rasmus
> 
> 
> 
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


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

[PHP-DEV] PHP 4.2.3 release.

[Xavier Spriet]

Hi Guys,

I don't know exactly when you plan to release PHP 4.2.3 as a final
release but I believe I just found a bug that I haven't seen reported on
bugs.php.net or in any of the php-dev threads, unfortunately, I will not
be able to confirm this bug until friday night, time at which I will
recompile our development server.

The bug concerns passing multi-dimensional arrays in $_POST via
form/POST, there is an obvious parsing error on my 4.2.3RC1 that makes
it impossible to pass it a multi-dimensional array.

e.g.

test
Adam
Eric
Marc
Drew

Doug
Xavier

This should give us $_POST[fields[tech_id[0]]], 1, 2, 3, etc...
in fact, here is what it gives me:
   ["tech_id["]=>
string(4) "Doug"

Thanks,

Xavier Spriet.
[EMAIL PROTECTED]
(519)-945-2032 Ext. 233



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

Re: [PHP-DEV] trans-sid warning?

[Xavier Spriet]

Hi Dan,

This was exactly what I meant to suggest by allowing to time out any
session even active.
Even though your workaround would also definitely make the task harder,
as George pointed out, we still don't have a solution against a
motivated cracker.

I think it would be very good but I am wondering with your
implementation how support will be kept for automated applications.



On Tue, 2002-08-20 at 11:00, Dan Hardiker wrote:

> It is also very conceivable that a person would send a link to a java
> applet or any other kind of wrapper (PHP or other CGI actually would be
> able to establish the connection on the server side always sending the
> same user agent string and sending back the data from your site) to
> establish the session in which case this is rendered useless.

So because its not flawless, we shouldnt try to get as close to perfection
as we can?

I know its not water-tight by any stretch of the imagination, but the more
checking in there, the harder it is for hackers to get the foot in the
door and penetrate. The more abstract the system is (especially on a site
by site basis) the more work a cracker has to do to work out how a host is
authenticated.

At the end of the day, nothing from the client can be trusted - nothing.
So we are never gonna reach perfection when the client is involved in
relaying information.


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



Xavier Spriet
Developer/Administrator/Apache Build
Next Dimension Inc.
[EMAIL PROTECTED]
Tel: (519)-945-2032 Ext. 233

Re: [PHP-DEV] trans-sid warning?

[Xavier Spriet]

It is also very conceivable that a person would send a link to a java
applet or any other kind of wrapper (PHP or other CGI actually would be
able to establish the connection on the server side always sending the
same user agent string and sending back the data from your site) to
establish the session in which case this is rendered useless.

On Tue, 2002-08-20 at 10:18, George Schlossnagle wrote:

Dan Hardiker wrote:

>>>Well, more worrisome would be if a bad guy tricks you into clicking on
>>>a link or simply sends you an image in an email that makes a request
>>>to my server with a valid-looking session id.  Then if you go to this
>>>site (that
>>>
>>I've debunked that scenario already a few times.  The net
>>result is that this class of attacks is impossible to
>>prevent.
>>
>>The assumption in your scenario and the following is this:
>>
>>The attacker has access to a script X which calls
>>session_start().
>>
>>My scenario:
>>
>>1.) Attacker A accesses X and stores the SID which PHP assigns to
>>him.
>>
>>2.) A crafts a link containing SID and sends it to victim V.
>>
>>3.) A keeps SID alive by repeatedly accessing X using SID.
>>
>>4.) V opens link and authenticates.
>>
>>5.) A's script notices (4).  A can overtake V's session.
>>
>
>Ive extended the session handling so that upon session start, it takes a
>snapshot of the browser string (and maybe a couple of other
>javascript-retrieved variables about the user's os, eg: the resolution)
>and build up as much of a picture of the client as possible.
>
>Then store this with the session id, and each time its loaded, check that
>the system hasnt changed. Ive found that (although all the data can be
>faked) that the browser string alone causes alot of grief - especially as
>IE's browser string is changed by many plugin programs.
>
>Just a thought.
>

Unfortunately, this info gets obscured by many major (aol) proxy farms 
as well.

>
>
>




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


Xavier Spriet
Developer/Administrator/Apache Build
Next Dimension Inc.
[EMAIL PROTECTED]
Tel: (519)-945-2032 Ext. 233

Re: [PHP-DEV] trans-sid warning?

[Xavier Spriet]

h. I get it now...
it would indeed make some sense since you have an alternative way of
tracking session.
Unfortunately, I do not have the answer to your question.

On Tue, 2002-08-20 at 10:09, Marko Karppinen wrote:

Xavier:
> So you wish to prevent your users from forging GET/POST values and are
> willing to rely on client-side cookies ?
> How is that any safer ?
>
> On Tue, 2002-08-20 at 09:18, Marko Karppinen wrote:
>> By the way, does session.use_only_cookies work with
>> session.use_cookies=off?

Who said I was using cookies? I'm not. I asked if 
session.use_only_cookies
worked (ie. prevented supplying the sid in GET/POST parameters) without
actually setting cookies on.

mk


Xavier Spriet
Developer/Administrator/Apache Build
Next Dimension Inc.
[EMAIL PROTECTED]
Tel: (519)-945-2032 Ext. 233

Re: [PHP-DEV] trans-sid warning?

[Xavier Spriet]

So you wish to prevent your users from forging GET/POST values and are
willing to rely on client-side cookies ?
How is that any safer ?

On Tue, 2002-08-20 at 09:18, Marko Karppinen wrote:

Sascha:
> If you want your site to be safe, enable
> session.use_only_cookies and be done with it.  No amount of
> checking on the server side can otherwise prevent this class
> of attacks.

By the way, does session.use_only_cookies work with 
session.use_cookies=off?

I'm using an alternative method (HTTP Basic Authentication) for the 
session
id propagation, and would like to prevent users from setting the sid in 
get/post
parameters.

mk


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


Xavier Spriet
Developer/Administrator/Apache Build
Next Dimension Inc.
[EMAIL PROTECTED]
Tel: (519)-945-2032 Ext. 233

Re: [PHP-DEV] strange bug in bugs.php.net

[Xavier Spriet]

http://bugs.php.net/search.php?cmd=display&bug_type=Any&status=Won\'t%20fix&search_for=&php_os=&bug_age=0&by=&order_by=id&direction=ASC&phpver=4&limit=10&assign=&begin=10


It's because the apostrophe hasn't been stripslash()ed
Try removing the / and it works fine.


On Tue, 2002-08-20 at 08:22, Sebastian Nohn wrote:

Hi,

to reproduce this:

-> http://bugs.php.net/search.php

Select Status: Won't fix, hit Search

on the following page select "Next 10 Entries"

Regards,
   Sebastian Nohn
-- 
+49 170 471 8105 - [EMAIL PROTECTED] - http://www.nohn.net/
PGP Key Available - Did I help you? Consider a gift:
http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/

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


Xavier Spriet
Developer/Administrator/Apache Build
Next Dimension Inc.
[EMAIL PROTECTED]
Tel: (519)-945-2032 Ext. 233

RE: [PHP-DEV] trans-sid warning?

[Xavier Spriet]

 

> Again, this is a good step, but is not at all effective against an
> attacker motivated to compromise your site.


You are right. However, it could be an acceptable policy to "improve" overall 
security.  


> The problem is, while this means something to the developer, it means
> nothing to the average end-user, especially since most large ISP users
> will have ip's that fluctuate form request-to-request.


I agree again. But once again, maybe a strict policy could make a user open a 
new session when their IP address change (this policy would not be mandatory of 
course)...

This would probably be a pain but could on the other hand give a feeling of 
increased security to your visitor and discourage a regular attacker imho

RE: [PHP-DEV] trans-sid warning?

[Xavier Spriet]

I was not refering to a way to timeout inactive session but instead to allow the 
administrator
to override this policy by a stricter one and allow a maximum active session time if 
he decides to implement it.
Which means a user may do what they have to do on your site for x amount of minutes 
and then they will have to create a new session to continue.
The behaviour for timing out inactive sessions would simply complement this policy.

-Original Message- 
From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]] 
Sent: Mon 19/08/2002 10:27 PM 
To: Xavier Spriet 
Cc: [EMAIL PROTECTED] 
Subject: RE: [PHP-DEV] trans-sid warning?



This is not the issue we are discussing.  PHP already times out inactive
sessions, and in this particular case the session has even been created
yet, so there is nothing to time out.

-Rasmus

On Mon, 19 Aug 2002, Xavier Spriet wrote:

> (I might have sent this one twice again...)
> --
> why not simply allow a maximum amount of time a session can exist (let's 
say, 25 minutes).
> This could be customised or even disabled by the administrator so it won't 
be a flea to regular users, and even though it won't be bulletproof, it will make 
things considerably more complicated for the attacker.
> Sending a link and hoping it will be clicked in the next 25 minutes is just 
trying your luck.
>
> Also a good web developer aware of this will most certainly put a little 
informing text such as:
> You are currently loged in as:   you loged in with the following 
IPaddr/Uagent:   blablah.
>
> Xavier.
>
>   -Original Message-
>   From: Sascha Schumann [mailto:[EMAIL PROTECTED]]
>   Sent: Mon 19/08/2002 8:50 PM
>   To: George Schlossnagle
>   Cc: Rasmus Lerdorf; Yasuo Ohgaki; [EMAIL PROTECTED]
>   Subject: Re: [PHP-DEV] trans-sid warning?
>
>
>
>   > To play devil's advocate, pure cookie based authentication is not a
>   > panacea.  If you allow users to put things like javascript on your 
site,
>   > or if you have users who exploit ie bugs like the about: cookie 
domain
>   > bug from last year, cookies can be stolen and session hijacked.  
pure
>   > cookie auth is definitely a good thing, but does not provide safety 
in a
>   > number of 'real world' applications.
>
>   Yes, I pointed that out in an earlier discussion about this
>   topic.  A online-banking site could for example check the
>   browser for certain types of common vulnerabilities and post
>   a nice "please upgrade" dialogue.
>
>   This would exclude IE by default though, because there are
>   quite a load of unfixed, publically known security bugs.
>
>   http://www.jscript.dk/unpatched/ listed them, but the page
>   seems to be down now.  Google still finds
>
>   http://www.jscript.dk/unpatched/MS02-023update.html
>
>   "Yesterday I hosted a list of 14 publickly known unpatched
>   vulnerabilities, today I host a list of 12 such. It can still
>   be found at http://jscript.dk/unpatched/
>
>   - Sascha
>
>
>   --
>   PHP Development Mailing List <http://www.php.net/>
>   To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>

RE: [PHP-DEV] trans-sid warning?

[Xavier Spriet]

(I might have sent this one twice again...)
--
why not simply allow a maximum amount of time a session can exist (let's say, 25 
minutes).
This could be customised or even disabled by the administrator so it won't be a flea 
to regular users, and even though it won't be bulletproof, it will make things 
considerably more complicated for the attacker.
Sending a link and hoping it will be clicked in the next 25 minutes is just trying 
your luck.
 
Also a good web developer aware of this will most certainly put a little informing 
text such as:
You are currently loged in as:   you loged in with the following IPaddr/Uagent:   
blablah.
 
Xavier.

-Original Message- 
From: Sascha Schumann [mailto:[EMAIL PROTECTED]] 
Sent: Mon 19/08/2002 8:50 PM 
To: George Schlossnagle 
Cc: Rasmus Lerdorf; Yasuo Ohgaki; [EMAIL PROTECTED] 
Subject: Re: [PHP-DEV] trans-sid warning?



> To play devil's advocate, pure cookie based authentication is not a
> panacea.  If you allow users to put things like javascript on your site,
> or if you have users who exploit ie bugs like the about: cookie domain
> bug from last year, cookies can be stolen and session hijacked.  pure
> cookie auth is definitely a good thing, but does not provide safety in a
> number of 'real world' applications.

Yes, I pointed that out in an earlier discussion about this
topic.  A online-banking site could for example check the
browser for certain types of common vulnerabilities and post
a nice "please upgrade" dialogue.

This would exclude IE by default though, because there are
quite a load of unfixed, publically known security bugs.

http://www.jscript.dk/unpatched/ listed them, but the page
seems to be down now.  Google still finds

http://www.jscript.dk/unpatched/MS02-023update.html

"Yesterday I hosted a list of 14 publickly known unpatched
vulnerabilities, today I host a list of 12 such. It can still
be found at http://jscript.dk/unpatched/

- Sascha


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

Re: [PHP-DEV] PHP tested on 64-bit OS?

[Xavier Spriet]

Absolutely,
PHP is used on production servers in many 64 bit Operating Systems.
I use it myself on our production SPARC solaris servers.

Also, you may note that PHP has been ported to Novell Netware in the
past:
http://developer.novell.com/ndk/leadedge.htm#le169
However, it seems to be a beta version only so more work is most
certainly expected.


On Mon, 2002-08-19 at 11:36, Ananth Kesari wrote:

Hi,

We are working on porting PHP for NetWare.

We have a question here: Has PHP been tested on any 64-bit Operating System?

Thanks,
Ananth.



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


Xavier Spriet
Developer/Administrator/Apache Build
Next Dimension Inc.
[EMAIL PROTECTED]
Tel: (519)-945-2032 Ext. 233

[PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] 4.2.3

[Xavier Spriet]

Okay then...
let's start up the QA process whenever you guys are ready and I'll test as much as I 
can on 2 of our developement machines, one on linux the other one on SPARC 64.
I'll start as soon as the process is ignited.
Let's get to work and give it some momentum  ;)

-Original Message- 
From: Edin Kadribasic [mailto:[EMAIL PROTECTED]] 
Sent: Sun 18/08/2002 4:21 PM 
    To: Xavier Spriet; Zeev Suraski 
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] 
Subject: Re: [PHP-QA] Re: [PHP-DEV] 4.2.3



> >As long as there is momentum on the development process and on the QA
> >process when needed,
> >I don't think release momentum matters that much.
>
> Right.  Since the first part of the sentence does not stand in reality,
the
> direct result is that momentum matters, a lot :)  Lack of momentum is the
> main reason PHP releases are taking several weeks now.  It's not as if
> people are testing it thoroughly for weeks and weeks...

Exactly right. During the last release cycle, Derick made elaborate test
cases, etc. but the result was not very promising. Very few people actually
took part in the QA process and as a result 4.2.0 was released with some
serious bugs in it.

I believe that 4.2.3 should be released, and that it should be very fast. If
Derick has no time for the release, and Zeev volunteers to do it, I really
see no point in delaying it further. Especially since 4.3.0 release doesn't
seem to be very near.

Edin

[PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] 4.2.3

[Xavier Spriet]

As long as there is momentum on the development process and on the QA process when 
needed,
I don't think release momentum matters that much.
It is important to keep up with the current development for 4.3.0 and also for future 
implementation of ze2,
which I think probably takes some time.
 
However, a bugfix release is probably expected any time now, and yeah... maybe the qa 
process for a 4.2.3 RC could
start in the next few days, I'm willing to provide as much time as I have available if 
it does.
 
I still believe backporting as many bugfixes as possible would make the transition 
from 4.2.3 to 4.3.0 much better for everyone.

-Original Message- 
From: Zeev Suraski [mailto:[EMAIL PROTECTED]] 
Sent: Sun 18/08/2002 2:35 AM 
To: [EMAIL PROTECTED] 
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] 
Subject: [PHP-QA] Re: [PHP-DEV] 4.2.3



I did not intend to reply to that, but generally, the reasons I think 4.2.3
should either be released in the immediate future or not released at all
are (a) clashing with the 4.3.0 release process (b) momentum.  The most
serious problem PHP releases have suffered from, in my opinion, ever sense
v4.1.0 (inclusive), is lost momentum.
I was (am) willing to coordinate the release of 4.2.3 provided it gets
ignited within a couple of days.

Zeev

At 03:16 18/08/2002, [EMAIL PROTECTED] wrote:
>On Sat, 17 Aug 2002, Sascha Schumann wrote:
>
> > > I think 4.2.3 makes perfect sense as long as it gets started 
immediately,
> > > immediately being sometime within the next few days.
> >
> > Is there some event I'm not aware of that a few days matter
> > to you?  If not, I don't see any problem with merging all
> > important fixes and commencing the QA process afterwards.
>
>I agree with that.
>
>Derick
>
>---
>  Did I help you?   http://www.derickrethans.nl/link.php?url=giftlist
>  Frequent ranting: http://www.derickrethans.nl/
>---
>  PHP: Scripting the Web - [EMAIL PROTECTED]
> All your branches are belong to me!
> SRM: Script Running Machine - www.vl-srm.net
>---
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP Quality Assurance Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] 4.2.3

[Xavier Spriet]

I agree on every point.
It's not "buggy as hell" but it's quite annoying and it puts the developer in a 
situation where many workarounds have to be made when these bugs are fixed in CVS...

-Original Message- 
From: Sascha Schumann [mailto:[EMAIL PROTECTED]] 
Sent: Sat 17/08/2002 5:18 PM 
To: Zeev Suraski 
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] 
Subject: RE: [PHP-QA] Re: [PHP-DEV] 4.2.3



On Sat, 17 Aug 2002, Zeev Suraski wrote:

> At 22:58 17/08/2002, Sascha Schumann wrote:
> > > 64-bit fixes (for whatever reason), I think that's quite alright.  
64-bit
> > > support is a major thing, which people, especially businesses, will not
> > > really expect to be implemented in a bug-fix release.
> >
> > 64-bit support has worked for years in PHP
>
> This is what I thought too.  I'm not sure what these fixes are, but it's
> quite possible that it didn't really work too well in 64-bit systems for
> years as you and I thought, in which case it's quite alright to wait.  I'm
> not saying we *should* wait, I'm saying it's a possibility, depending on
> how far-reaching they are.

Well, my primary workstation was a 64-bit Alpha system for
about a year in 1999 or 2000.  After fixing a few issues, PHP
worked without a hitch -- while it is easy for me to imagine
that new code violated some portability concerns, I don't
think that PHP or the Zend engine have been actually
destabilized to the effect of being unusable. :-)

I've had at a look at the bug reports Sebastian Nohn pointed
out.  None of these are major issues.  Annoying, but nothing
which would qualify PHP as being "buggy as hell".  Still,
having these fixes in 4.2.3 would be a definitive advantage.

- Sascha




--
PHP Quality Assurance Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] 4.2.3

[Xavier Spriet]

(sorry Zeev, I sent this reply only to you the first time)
 
Sebastian Nohn is the one that has noticed most of the 64 bits related bugs I was 
refering to.
I am sure he can give you more information of these bugs.
It seems it was working fine just a few months ago.
I experience some of them on SPARC64, not all.
Sebastian is working on Tru64 though, different architecture.
 
And it seems these fixes are type related indeed and also I believe they were pretty 
much all fixed in CVS, it wouldn't be too hard to backport it to 4.2 branch in my 
opinion.
However, it's not my decision to make and I agree with Zeev for everything else, I 
don't have any other objections for 4.2.3 whatsoever.

-Original Message- 
From: Zeev Suraski [mailto:[EMAIL PROTECTED]] 
Sent: Sat 17/08/2002 4:05 PM 
To: Sascha Schumann 
    Cc: Xavier Spriet; [EMAIL PROTECTED]; [EMAIL PROTECTED] 
Subject: RE: [PHP-QA] Re: [PHP-DEV] 4.2.3



At 22:58 17/08/2002, Sascha Schumann wrote:
> > 64-bit fixes (for whatever reason), I think that's quite alright.  64-bit
> > support is a major thing, which people, especially businesses, will not
> > really expect to be implemented in a bug-fix release.
>
> 64-bit support has worked for years in PHP

This is what I thought too.  I'm not sure what these fixes are, but it's
quite possible that it didn't really work too well in 64-bit systems for
years as you and I thought, in which case it's quite alright to wait.  I'm
not saying we *should* wait, I'm saying it's a possibility, depending on
how far-reaching they are.

Zeev

[PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] 4.2.3

[Xavier Spriet]

This is quiteconcerning.
It appears the PHP release process is not suited to the way PHP is developed anymore
and this can lead in severe inconsistencies.
What seemed to have happened is that several bugfixes were fixed in CVS instead of the 
bugfix release which if fine with me... but the bugs in question are pretty important.
This seems to be partly due to a lack of communication between developement and QA 
since this problem was aborded weeks ago already and Sebastian Nohn raised that 
question on several occasions.
 
The way the developement team and qa can improve the organisation for better 
communication can be solved easily in the upcoming weeks, however, it seems now we 
have to face a more important problem.
 
IMHO, it is important that the 64bits architecture related bugs be fixed in the next 
release as most of the people that will be pissed off if it doesn't, are business 
users that absolutely need a modern release to work in their environement or will 
simply stop supporting PHP in their environement/business.
 
Many good suggestions have been made, mine is to find out which bugs were "fixed in 
CVS" and are important and spend the week on backporting them to the bugfix release, 
4.2.3
We can have a RC1 ready for next monday and no doubt we won't need a RC2 and can 
release later that week.
 
Do you guys think this could be done in an acceptable timeframe ?
 
Thanks.

-Original Message- 
From: Zeev Suraski [mailto:[EMAIL PROTECTED]] 
Sent: Sat 17/08/2002 11:37 AM 
To: Rasmus Lerdorf 
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] 
Subject: [PHP-QA] Re: [PHP-DEV] 4.2.3



It's not a matter of what we call it - I thought it would make sense to
release a new version based on the 4.2 branch, because 4.3 has TONS of new
features and is thus very likely to introduce new inconsistencies and
bugs.  As people have said here several times in the last few weeks, most
users will be unlikely to install 4.3.0 anyway, until they either hear it's
ok, or see it mature with a few bugfix releases.
Just a thought.

Zeev

At 18:33 17/08/2002, Rasmus Lerdorf wrote:
>Regardless of what we call it, we need to light a fire under people to get
>a new release out.  The fixes are piling up in CVS.  Stig, could you give
>us a status report?  Do you still have time to push this release?
>
>-R
>
>On Sat, 17 Aug 2002, Zeev Suraski wrote:
>
> > Ok then, I retract my suggestion to release 4.2.3.
> >
> > Zeev
> >
> > At 17:59 17/08/2002, Dan Kalowsky wrote:
> > >I disagree that it should go out as is, very strongly at that too.
> > >
> > >Some fixes not in the 4.2 branches:
> > >
> > >- ODBC no longer crashes on Windows upon unloading
> > >- while not fully tested, ext/java now works for 1.4 JDK's
> > >- various memory leak fixes provied by Ilia (pack being one of them)
> > >- a few misc fixes for Win32 platforms
> > >- nsapi build fix which allows it to build and reported run again
> > >   (although I still think we need to decide if we can kill this support)
> > >- numerous domxml bug fixes have been added as well.
> > >- QTDOM fix to allow it to compile again and run again
> > >
> > >This is one yet to be made, but:
> > >- a potential fix to have 'make install' work on AIX machines again
> > >   finally.
> > >
> > >These are just bug fixes.  I don't want to see new functionality added to
> > >PHP for a potential 4.2.3, but I do want to see a LOT of these bugs
> > >squished.  There is a fix, why go and release another version of PHP with
> > >known and non-fixed bugs in it?
> > >
> > >It still doesn't seem to compile and work on 64-bit arch's.
> > >
> > >But yet again, there are numerous reasons why we should move to release
> > >PHP 4.3.  The biggest of which in my book is, it supports OSX!  While
> > >possibly a minor issue to many of the users on this list, it's becoming a
> > >more significant issue, especially with Jaguar/10.2 being released in a
> > >few days.  There have been numerous fixes to all the code bases in an
> > >effort to get support for OSX implemented into them (ext/java still being
> > >a bastard).
> > >
> > >
> > >On Sat, 17 Aug 2002, Zeev Suraski wrote:
> > >
> > > > I think it makes good sense to release 4.2.3 as-is (after a short
> QA cycle,
> > > > that will ensure we didn't introduce any new bugs).  If 4.2.3 becomes 
a
> > > > larg

[PHP-DEV] RE: [PHP-QA] Supporting Apache 2 with PHP 4.2.0

[Xavier Spriet]

ummm actually...
maybe we should wait for 4.2.1 then  ;)

Xavier Spriet.
Software/Web Developer
Next Dimension Inc.
Phone: 519.945.2032 Ext. 233
http://www.nextdimensioninc.com
[EMAIL PROTECTED]


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 10, 2002 3:51 PM
To: Xavier Spriet
Cc: PHP Quality Assurance Team Mailing List; PHP Developers Mailing List
Subject: RE: [PHP-QA] Supporting Apache 2 with PHP 4.2.0


GOod, another volunteer to check out the bugreports...

Derick

On Wed, 10 Apr 2002, Xavier Spriet wrote:

> It can be enabled only when the user compiles PHP with --with-apxs2 or 
>--with-apache2 anyway right ?
> so I agree with the idea to leave it there and explain that it is not supposed to 
>work in a stable way...
> it won't bother users that don't try to compile it with apache2 support and for the 
>other ones, they'll
> know what to expect anyway...
> it's just my opinion.
> 
> Xavier Spriet.
> Software/Web Developer
> Next Dimension Inc.
> Phone: 519.945.2032 Ext. 233
> http://www.nextdimensioninc.com
> [EMAIL PROTECTED]
> 
> 
> -Original Message-
> From: Andi Gutmans [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, April 10, 2002 3:23 PM
> To: Robinson, Mike; 'Jani Taskinen'; Stanislav Malyshev
> Cc: PHP Quality Assurance Team Mailing List; PHP Developers Mailing List
> Subject: Re: [PHP-QA] RE: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] RE:
> [PHP-QA] Supporting Apache 2 with PHP 4.2.0
> 
> 
> At 08:39 09/04/2002 -0400, Robinson, Mike wrote:
> 
> >Jani Taskinen writes:
> >
> > > I'd rather have 4.2.0 released without the apache2 support
> > > and  work on the code to get it work for real and release
> > > 4.2.1 with the fixed support.
> >
> >IMHO, removing Apache2 support will not affect the number of
> >Apache2-related bugs reported. If anything, removing it will
> >cause more.
> >
> >Why not leave it in there, mark it as beta/unstable and be
> >vocal about that in the release announcement.
> 
> +1 from me. I think giving people a chance to play around with it will make 
> it easier for us to make the next version stable.
> 
> Andi
> 
> 
> -- 
> PHP Quality Assurance Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 
> -- 
> PHP Quality Assurance Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

---
 Did I help you? Consider a gift:
  http://www.amazon.co.uk/exec/obidos/registry/SLCB276UZU8B
---
  PHP: Scripting the Web - [EMAIL PROTECTED]
All your branches are belong to me!
SRM: Script Running Machine - www.vl-srm.net
---


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

[PHP-DEV] RE: [PHP-QA] RE: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] RE: [PHP-QA] Supporting Apache 2 with PHP 4.2.0

[Xavier Spriet]

It can be enabled only when the user compiles PHP with --with-apxs2 or --with-apache2 
anyway right ?
so I agree with the idea to leave it there and explain that it is not supposed to work 
in a stable way...
it won't bother users that don't try to compile it with apache2 support and for the 
other ones, they'll
know what to expect anyway...
it's just my opinion.

Xavier Spriet.
Software/Web Developer
Next Dimension Inc.
Phone: 519.945.2032 Ext. 233
http://www.nextdimensioninc.com
[EMAIL PROTECTED]


-Original Message-
From: Andi Gutmans [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 10, 2002 3:23 PM
To: Robinson, Mike; 'Jani Taskinen'; Stanislav Malyshev
Cc: PHP Quality Assurance Team Mailing List; PHP Developers Mailing List
Subject: Re: [PHP-QA] RE: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] RE:
[PHP-QA] Supporting Apache 2 with PHP 4.2.0


At 08:39 09/04/2002 -0400, Robinson, Mike wrote:

>Jani Taskinen writes:
>
> > I'd rather have 4.2.0 released without the apache2 support
> > and  work on the code to get it work for real and release
> > 4.2.1 with the fixed support.
>
>IMHO, removing Apache2 support will not affect the number of
>Apache2-related bugs reported. If anything, removing it will
>cause more.
>
>Why not leave it in there, mark it as beta/unstable and be
>vocal about that in the release announcement.

+1 from me. I think giving people a chance to play around with it will make 
it easier for us to make the next version stable.

Andi


-- 
PHP Quality Assurance Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php


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