Re: [PHP-DEV] embedded libmagic (from file)

the divergence to the strict minimum. Cheers, -- Raphael Geissert -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] IMAP patches from kolab -- can we get these merged?

Pierre Joye wrote: On Thu, Jul 29, 2010 at 11:44 PM, Raphael Geissert geiss...@php.net wrote: As it seems, the best and maintainable solution is to switch to some other alternative library (sadly, there's no such candidate atm.) What make you think that c-client is dead? I have seen updates

Re: [PHP-DEV] IMAP patches from kolab -- can we get these merged?

Raphael Geissert wrote: As it seems, the best and maintainable solution is to switch to some other alternative library (sadly, there's no such candidate atm.) Actually, I wonder if the imap extension shouldn't be dropped altogether in trunk. The libraries written in PHP are actually more

Re: [PHP-DEV] Re: Commits to PHP_5_3

Johannes Schlüter wrote: On Thu, 2010-03-18 at 22:10 -0600, Raphael Geissert wrote: At the moment dba is the best place to add support for tokyo cabinets without introducing major features (or a pecl extension). without introducing major features doesn't sound like a good way

Re: Re: [PHP-DEV] Debian PHP patches

Raphael Geissert wrote: Johannes Schlüter wrote: Although I would have preferred you wait for me to submit each patch individually with enough information (because I've only been like two years co-maintaining the packages and most patches were added by others, and most before I joined

[PHP-DEV] Re: Commits to PHP_5_3

. That part will become stricter once the next major (5.4/6) release comes closer. In general every bug fix should have a test and bug ID, every new feature should have documentation. I was considering adding support for tokyo cabinets, would that still be acceptable for 5.3.x? Cheers, -- Raphael

Re: [PHP-DEV] Re: Commits to PHP_5_3

Sebastian Bergmann wrote: Am 18.03.2010 19:10, schrieb Raphael Geissert: I was considering adding support for tokyo cabinets, would that still be acceptable for 5.3.x? I think something like that should go into a PECL extension. I would actually be happy if I could build support for dba

Re: [PHP-DEV] Re: Commits to PHP_5_3

Scott applied to PHP6 - I was rather hoping it'd end up in 5.3.x at some point, but he's been too busy. I'll dig out the patch if anyone here wants it, I haven't karma to apply it. Cool. Johannes, would it be ok to merge support for tokyo cabinets into PHP_5_3? Cheers, -- Raphael Geissert -- PHP

Re: [PHP-DEV] 5.3 release schedule and other bits

(probably more than those we included in 5.2.6 for lenny, because of our current work to get the testsuite to pass). Cheers, -- Raphael Geissert -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: why not use strtol instead of php_filter_parse_{int,hex,octal}?

Raphael Geissert wrote: Pierre Joye wrote: What patch? Please do not commit anything there without first posting to the list. There were enough breakage in this area, no need to introduce new ones again. No objection then? Here it is: http://git.debian.org/?p=pkg- php/php.git;a=blob;f

Re: [PHP-DEV] Re: why not use strtol instead of php_filter_parse_{int,hex,octal}?

=3061d111de130df7388cc78e26b63cc105574775 Like Sean stated on his post to the list, the engine is also affected. Somebody would need to apply the patch there. Cheers, -- Raphael Geissert -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: why not use strtol instead of php_filter_parse_{int,hex,octal}?

Derick Rethans wrote: On Mon, 22 Feb 2010, Raphael Geissert wrote: gcc 4.4's optimiser removes the overflow check present in php_filter_parse_int and ZEND_HANDLE_NUMERIC (but I can't touch that part of the code anyway...) which prevents the overflow from being detected. Doesn't

Re: [PHP-DEV] multi-jobs run-tests.php

). Ah, I see, great. From a quick look at the code it looks like it also uses pcntl. Is there any plan to switch to that other implementation? No work has been done in something like the threads extension, has there? Cheers, -- Raphael Geissert -- PHP Internals - PHP Runtime Development Mailing

Re: [PHP-DEV] Re: why not use strtol instead of php_filter_parse_{int,hex,octal}?

the reason, as well as the locale issues that you mention (POSIX locales==useless). Please don't commit this. Ok. Sean came up with a different patch which is being tested right now. If all the tests pass then I'm going to commit it. Cheers, -- Raphael Geissert -- PHP Internals - PHP Runtime

Re: [PHP-DEV] Re: why not use strtol instead of php_filter_parse_{int,hex,octal}?

Derick Rethans wrote: What exactly are you trying to fix here? gcc 4.4's optimiser removes the overflow check present in php_filter_parse_int and ZEND_HANDLE_NUMERIC (but I can't touch that part of the code anyway...) which prevents the overflow from being detected. Cheers, -- Raphael

[PHP-DEV] why not use strtol instead of php_filter_parse_{int,hex,octal}?

no objection, I would like to remove them entirely and use strtol in php_filter_int. Cheers, -- Raphael Geissert -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] multi-jobs run-tests.php

Hi, I've spent the last hours working on making run-tests.php be able to run tests in parallel. The main reason being the time it takes to run the whole testsuite even on multicore CPUs. Attached is the first set of changes needed. It uses pcntl's fork and sysvmsg to send some of the results

[PHP-DEV] Re: why not use strtol instead of php_filter_parse_{int,hex,octal}?

Raphael Geissert wrote: If there's no objection, I would like to remove them entirely and use strtol in php_filter_int. By the way, I don't think that the fact that strtol is locale-aware should be a reason to make the change. Since scripts are expected to use the value returned

[PHP-DEV] SVN Account Request: geissert

Squash bugs on the test suite and code -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Debian PHP patches

Jani Taskinen wrote: On 01/17/2010 05:19 AM, Raphael Geissert wrote: Jani Taskinen wrote: 16.1.2010 20:10, Raphael Geissert wrote: Some of the other patches include: libdb_is_-ldb Why? Potentially breaks things when you assume db/ being correct place.. Do you have an example of any

Re: [PHP-DEV] Debian PHP patches

, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Debian PHP patches

: http://lists.gnu.org/archive/html/autoconf/2009-11/msg00100.html I see, thanks for the pointer. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Throwing an E_DEPRECATED for short_open_tag

problematic edge cases and bringing them up to speed so they can support per-app configuration. That would be the ideal situation. Sadly it is not that easy to accomplish, hence the need to support more configuration options. Cheers, -- Raphael Geissert - Debian Developer www.debian.org

Re: [PHP-DEV] Throwing an E_DEPRECATED for short_open_tag

Patrick ALLAERT wrote: 2010/1/13 Derick Rethans der...@php.net: On Tue, 12 Jan 2010, Raphael Geissert wrote: [snip] Would it be possible to force short_open_tag to a specific value for those applications alone? Perhaps through an .htaccess file? That way, Debian keeps the PHP default

Re: [PHP-DEV] Debian PHP patches

an online copy of the latest changelog: http://packages.debian.org/changelogs/pool/main/p/php5/current/changelog.html Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net

Re: [PHP-DEV] Debian PHP patches

Jani Taskinen wrote: 16.1.2010 20:10, Raphael Geissert wrote: Some of the other patches include: libdb_is_-ldb Why? Potentially breaks things when you assume db/ being correct place.. Do you have an example of any actual case? 115-autoconf_ftbfs.patch Hell no. You're breaking

Re: [PHP-DEV] 5.3 release schedule and other bits

Debian- specific. The rest should find its way to the upstream code (but some of the patches were not accepted in the past). Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http

Re: [PHP-DEV] Throwing an E_DEPRECATED for short_open_tag

be when the default is Off and they break. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.3 release schedule and other bits

Alexey Zakhlestin wrote: Great news! Does it mean, that 5.3 will move to unstable branch soon? (currently, Debian has 5.3 only in testing) It is currently in experimental, but yes, we will soon be uploading it to unstable so that it later migrates to testing. Cheers, -- Raphael

Re: [PHP-DEV] 5.3 release schedule and other bits

Johannes Schlüter wrote: Hi, On Tue, 2010-01-12 at 14:48 -0600, Raphael Geissert wrote: Hello, At Debian we are planning to include PHP 5.3 in Squeeze, the next stable release. As such, I would like to know for example when we could expect 5.3.2 and 5.3.3 to be released. I hope

Re: [PHP-DEV] 5.3 release schedule and other bits

Daniel Convissor wrote: Hi Raphael: On Tue, Jan 12, 2010 at 02:48:38PM -0600, Raphael Geissert wrote: As a first step I'll be trying to forward most of our patches so that there's a minor divergence. Is there a document somewhere that explains the changes the Debian team has made

Re: [PHP-DEV] Throwing an E_DEPRECATED for short_open_tag

Rasmus Lerdorf wrote: Raphael Geissert wrote: However, we would like to contribute in the quest to make applications stop using short_open_tag. To do so, we have decided to throw an E_DEPRECATED warning when an application makes use of short_open_tag. The current implementation can be found

[PHP-DEV] 5.3 release schedule and other bits

(the package maintainers) and you (the upstream developers). As a first step I'll be trying to forward most of our patches so that there's a minor divergence. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- PHP Internals - PHP Runtime Development Mailing

Re: [PHP-DEV] 5.3 release schedule and other bits

Derick Rethans wrote: On Tue, 12 Jan 2010, Raphael Geissert wrote: At Debian we are planning to include PHP 5.3 in Squeeze, the next stable release. As such, I would like to know for example when we could expect 5.3.2 and 5.3.3 to be released. 5.3.2 is on the way, but not sure when

[PHP-DEV] Throwing an E_DEPRECATED for short_open_tag

;a=blob;f=debian/patches/deprecate_short_open_tag;h=57a79c6215afdc8654c6d18e791a9b7c8f5e373b Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] About dropping magic_quotes in 5.3 (was: Re: [PHP-DEV] Re: PHP 5.2.7 + magic_quotes_gpc broken)

Hannes Magnusson wrote: [...] We really need to work on our relationship with other distros, starting with marking security fixes as security fixes. Yes, please do mark them as such. -Hannes Cheers, -- Raphael Geissert - Debian Maintainer www.debian.org - get.debian.net -- PHP