Re: [PHP-DEV] embedded libmagic (from file)
Scott MacVicar wrote: > I have a diff sitting that I did yesterday that upgrades us to the > latest libmagic, it supports the new magic file format and updates > that bundle. But that's all. > > I'm also against allowing the non-php version. Yes it's a fork but > unfortunately it's for the best. Last time I checked there were some general bug fixes (e.g. fixing type casting) that were not in upstream's version. Were they forwarded for 5.05? (I haven't personally checked) It's easy to understand the wish of hacking libmagic to provide some more features, but it would be great to keep 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 > 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 last > year and I know that the main developer still works and support this > library. I don't think either that using 6 years old discussions to > decide something is a good idea. Tomas already clarified that point. > Something like that happened for php > and gd with Etch, and it was a total fiasco. I talked to Jonas about gd too, the failed collaboration attempt, etc, and I would like if we could try to make it work. However, that's a different topic and should be discussed separately. I hope we can count on you. 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?
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 reliable and work better. Regards, -- 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?
Mikko Koppanen wrote: > I was looking at annotations patch and it seems that my c-client does > not support the functionality (2007b on Debian Lenny). Do the > annotations require a custom patch to c-client as well? The request to include the annotations patch at Debian is at: http://bugs.debian.org/456947 But as you can see, it is marked as blocked by http://bugs.debian.org/456591 (the request against uw-imap/libc-client to include the patch.) Therefore, the blocker at the php level is enabling the annotations code at configure time if the system supports it. Of course, support on libc-client is necessary for it to be of any use. I just talked to Jonas Smedegaard (the Debian maintainer of libc-client,) and apparently the reason for not merging it is that the code is dead upstream and unmaintainable. A dead end. While digging for alternatives, it appears that there was a discussion in 2004 for FC2 about the situation of libc-client, but besides that: nothing. As it seems, the best and maintainable solution is to switch to some other alternative library (sadly, there's no such candidate atm.) HTH -- Raphael Geissert -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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), thanks. I'll try to comment on each but I don't
> know about them all and can't check them right now (I'm short on time).
>
I haven't had much time to work on merging those patches, but will try to
eventually get to do it.
>> 047-zts_with_dl.patch
>> I don't support this. dl() can be used by CLI users for loading Gtk or
>> such on demand but avoiding to load (and inititalize) all the Gtk
>> stuff every time they use PHP and avoid messing with config files...
The least I can say is that that patch is obsolete. We don't build the
apache modules with ZTS.
However, I don't understand what you are saying about Gtk. The patch doesn't
change the behaviour of the cli/cgi/embed SAPIs. It only re-enables dl() on
any SAPI even with ZTS.
>> 052-phpinfo_no_configure.patch
>> Neither do I support this. Users might benefit when building own
>> modules or might be interested in the configure line for other
>> reasons ...
The main issue is that we build the different SAPIs with different configure
flags. This seems to have lead to bogus bug reports in the past and
confusion (--disable-*/--without-* in certain SAPIs). For example, the
shared extensions are built when building the apache SAPI, the cgi build
options are also massaged after a first build, etc.
>>
>> 053-extension_api.patch
>> When adding random options to command line tools please mark them as
>> Debian specific. Additionally the man page should be updated.
>
> Indeed. In this case I'd prefer if this option is added upstream.
> The --phpapi option is used to determine the path to the extensions
> directory. In the case of architectures where LFS is enabled, the phpapi
> value is appended '+lfs'.
Is there any objection to making this change? (only to trunk, I assume.)
>> 100-recode_is_shared.patch
>> The conflict between MySQL and recode should only happen with an old
>> libmysql (3.23?) not sure about imap ... but in your case the patch
>> might make sense, while I won't directly apply it to our tree as
>> usually people will build extensions to load them together...
Shouldn't checking for $PHP_IMAP_SHARED != "yes" (and the same for mysql)
work? if either recode or imap/mysql are being built as shared I don't think
there's any reason to abort the build. A warning should be enough, don't you
think?
>> 108-64_bit_datetime.patch
>> 116-posixness_fix.patch
>> Why is that needed on our system? - I never saw an issue about these
>> and if they are missing there should be build issues.
>
> I will later be commenting on these two.
Haven't had time to check, deferring.
>> Did you consider mysqlnd?
Leaving any security concern aside, there are at the moment some missing
features and behaviour changes that I don't feel very comfortable with. In a
future release we might switch, but won't happen for Squeeze.
> Some of the other patches include:
> libdb_is_-ldb
Not yet merged, but at least support for db-4.{7,8} was added.
> 115-autoconf_ftbfs.patch
as per discussion we will continue carrying it
> fix_broken_upstream_tests.patch
not completely merged/resolved
> bad_whatis_entries.patch
merged
Cheers,
--
Raphael Geissert
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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 for > architecture decisions. This sounds a bit like "let's do it the way we > can trick the process" to me. Well, it is just another handler :) > And there is a pecl extension: http://pecl.php.net/package/tokyo_tyrant > Which doesn't address the same problem. Tokyo tyrant is a DBMS internally using tokyo cabinets. There are cases where running tokyo tyrant is either not possible, an overkill or not the right solution to a problem, hence the request of the dba handler. >> That'd be great. In fact, the interface isn't really bad. It is surely >> missing multiple features, some of which are only supported by a couple >> of dbms, but the code behind is what really needs to be improved. > > Thanks for volunteering! :-) > Meh :) >> > In addition, I wrote a patch for Tokyo Cabinet support >> > for ext/dba a while back, which 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? > > I didn't review it, yet, it sounds like a bit much, putting the review > on my todo. Would be great if it is merged. Thanks in advance. Cheers, -- Raphael Geissert -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Commits to PHP_5_3
Michael Maclean wrote: > Antony Dovgal wrote: >>> Here I'm talking about adding support for tokyo cabinets as a dba >>> handler, not a complete interface to the multiple tokyo cabinet APIs. >> >> Are you sure you want to add it to ext/dba? >> dba is .. well.. dead, and it sound like a complete waste of time. At the moment dba is the best place to add support for tokyo cabinets without introducing major features (or a pecl extension). > > There is an item on the wishlist for PHP 6.0 about refactoring ext/dba > to use PDO-style drivers. I intend to investigate this, unless someone > else wants to. That'd be great. In fact, the interface isn't really bad. It is surely missing multiple features, some of which are only supported by a couple of dbms, but the code behind is what really needs to be improved. > In addition, I wrote a patch for Tokyo Cabinet support > for ext/dba a while back, which 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 Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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 handlers as separate extensions, but that doesn't seem to be the case. Correct me if I'm wrong. Here I'm talking about adding support for tokyo cabinets as a dba handler, not a complete interface to the multiple tokyo cabinet APIs. Cheers, -- Raphael Geissert -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Commits to PHP_5_3
Johannes Schlüter wrote: > Hi, > > now that a new trunk is about to be created some comments about 5.3: > PHP_5_3 is a stable branch. This means mostly bug fixes. Small features > (like array_seek) can be added. There won't be a strict rule about what > is "small", common sense and asking applies. 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 Geissert -- 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
Hi Johannes, Johannes Schlüter wrote: > for 5.3.3 it depends on security issues being reported, bug fixes going > in, ... maybe 3 months after. With the current discussion about moving 6.0 to a branch and continuing the development of 5.4+ in trunk, I was wondering if there is going to be a change of plan. I'm mostly interested in knowing if it would be possible to get 5.3.3 out in a month, more or less (the latter preferred). This would be of great help from a Debian POV, as it would reduce the divergence; otherwise at Debian we are going to end up with 5.3.2 with many patches (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=debian/patches/filter_validate_int.patch;hb=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 this sound like a GCC bug to you then? > Sorry for the late response. No, it is not a bug, please refer to Sean's message. 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}?
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. > Here it is: http://git.debian.org/?p=pkg- php/php.git;a=blob;f=debian/patches/filter_validate_int.patch;hb=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: > 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 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, Pierre Joye wrote: >> Please don't commit this change. I remember some issues with strtol >> (portability, BC breaks, etc.). Please wait until we figured them out, >> or find back in the archives why strtol could be a bad idea. > > Poratability was indeed 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 Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] multi-jobs run-tests.php
Hi Pierre, Pierre Joye wrote: > There is an on-going work on run-test (which began as part of last > year GSoC). I would begin there instead of working on the current > run-test.php. Parallel testing is part of the new features as well, in > a portable way (like not only where pcntl is available). > 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 List To unsubscribe, visit: http://www.php.net/unsub.php
[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 by filter_var() there should be no problem with the fact that strings such as "100'000" are accepted as a valid integer, under certain locales. 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 back to the parent process.
Main functionalities still work, but the summary doesn't include failed
tests.
I plan to move away from sysvmsg because with the current implementation
killing the parent process can leave message queues open (nothing that can't
be fixed by adding a proper exit handler) and sysvmsg is not enabled by
default. Probably to something php://memory-based.
To support all the features under multi-jobs mode I think the proper fix is
to cleanup the code so that run_test() stores the state information via an
interface. This would make the code cleaner and would let multi-jobs mode
just change the state-storing interface.
How should I handle this? just by committing the changes? first sending them
here (to internals)? by contacting somebody else?
Cheers,
--
Raphael Geissertdiff --git a/run-tests.php b/run-tests.php
index 81f218b..9516490 100755
--- a/run-tests.php
+++ b/run-tests.php
@@ -451,6 +451,12 @@ if ($compression) {
$output_file = 'compress.zlib://' . $output_file . '.gz';
}
+$max_jobs = false;
+
+if (extension_loaded('pcntl') && extension_loaded('sysvmsg')) {
+$max_jobs = 1;
+}
+
$just_save_results = false;
$leak_check = false;
$html_output = false;
@@ -551,6 +557,14 @@ if (isset($argc) && $argc > 1) {
$ini_overwrites[] = $argv[++$i];
break;
//case 'h'
+case 'j':
+ if ($max_jobs !== false) {
+ $max_jobs = (int)$argv[++$i];
+ if ($max_jobs < 1) {
+ $max_jobs = 1;
+ }
+ }
+ break;
case '--keep-all':
foreach($cfgfiles as $file) {
$cfg['keep'][$file] = true;
@@ -665,6 +679,9 @@ Options:
-d foo=bar Pass -d option to the php binary (Define INI entry foo
with value 'bar').
+-j Maximum number of jobs to run in parallel (defaults to 1,
+requires pcntl and sysvmsg).
+
-m Test for memory leaks with Valgrind.
-p Specify PHP executable to run.
@@ -1082,9 +1099,30 @@ function system_with_timeout($commandline, $env = null, $stdin = null)
return $data;
}
+function reap_jobs($queue, &$results)
+{
+ // process messages aggresively to avoid
+ // saturating the queue, stalling childs
+ // waiting for space in the queue to exit
+ while (msg_receive($queue, 0, $null, 4096, $msg, true, MSG_IPC_NOWAIT))
+ $results[$msg['index']] = $msg['result'];
+ return pcntl_wait($null);
+}
+
function run_all_tests($test_files, $env, $redir_tested = null)
{
global $test_results, $failed_tests_file, $php, $test_cnt, $test_idx;
+ global $max_jobs;
+
+ $run_once = 0;
+
+ if ($max_jobs !== false) {
+ $jobs_avail = $max_jobs;
+ do {
+ $queue_key = mt_rand();
+ } while (function_exists('msg_queue_exists') && msg_queue_exists($queue_key));
+ $queue = msg_get_queue($queue_key);
+ }
foreach($test_files as $name) {
@@ -1100,15 +1138,56 @@ function run_all_tests($test_files, $env, $redir_tested = null)
$index = $name;
}
$test_idx++;
+
+ if ($max_jobs && ($max_jobs > 1 || $jobs_avail == 0)) {
+ if (!$jobs_avail) {
+if (reap_jobs($queue, $test_results) > 0)
+$jobs_avail++;
+ }
+ $pid = pcntl_fork();
+ if ($pid == -1) {
+ // Do nothing special, test will be run by
+ // the parent process.
+ // Decrement $jobs_avail and $max_jobs so that if
+ // future calls to fork fail we will end up
+ // disabling multi-jobs support without
+ // leaving childs behind.
+ $jobs_avail--;
+ $max_jobs--;
+ } else if ($pid) {
+ // parent process
+ $jobs_avail--;
+ continue;
+ } else {
+ // child process:
+ $max_jobs = false;
+ $run_once = 1;
+ }
+ }
+
$result = run_test($php, $name, $env);
if (!is_array($name) && $result != 'REDIR') {
- $test_results[$index] = $result;
+ // send the results back to the parent process
+ // if there's an active queue
+ if (isset($queue))
+msg_send($queue, 1, array('index' => $index, 'result' => $result));
+ else
+$test_results[$index] = $result;
if ($failed_tests_file && ($result == 'XFAILED' || $result == 'FAILED' || $result == 'WARNED' || $result == 'LEAKED')) {
fwrite($failed_tests_file, "$index\n");
}
}
+ if ($run_once) exit;
}
+
+ if ($max_jobs !== false) {
+ // check for messages one last time before removing the queue
+ // reap jobs at the same time
+ while (reap_jobs($queue, $test_results) > 0);
+ msg_remove_queue($queue);
+ }
+
}
//
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] why not use strtol instead of php_filter_parse_{int,hex,octal}?
Hi, While working on bug #51023, Sean and I were wondering why they were written in the first place, instead of using strtol; which can handle the three cases and properly detect overflows and underflows (and doesn't risk being optimised-away like with the current implementations). If there's 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] 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] Throwing an E_DEPRECATED for short_open_tag
Rasmus Lerdorf wrote: > > I think you are again becoming a victim of too much generalization. > Like using the slower re-entrant mysql client library, for example, just > in case you have a threaded SAPI that needs it. 99% of people are going > to be using the prefork Apache SAPI or fastcgi, neither of which needs > this, and thus you are penalizing the majority in order to support edge > cases more easily. The switch to libmysqlclient_r was because the mysql driver of apr-util was going to be enabled and would cause a symbols conflict. MySQL 5.1 did not change the symbols and as such we still can't link to the non-reentrant library. > > Same goes for per-package configuration. The common case, Apache and > fastcgi, can do per-directory configuration, but you are choosing not to > use it in order to support edge cases. Instead of trying to change PHP > here, I'd be going after your 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 - 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
Rasmus Lerdorf wrote: > Rasmus Lerdorf wrote: >> >> You can read this thread about my attempts to create a portable autoconf >> setup that works both in autoconf-2.60+ and previous versions. There >> were various ideas, but in the end none of them proved to be reliable. >> >> We need diversions prior to 2.60 or whichever version introduced >> AC_PRESERVE_HELP_ORDER. In autoconf versions that have >> AC_PRESERVE_HELP_ORDER we can use that and we can drop the diversions >> entirely. >> >> Renumbering the diversions and the various other attempts people have >> made doesn't work. > > Oops, missed the thread link: > > 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] Debian PHP patches
Gwynne Raskind wrote: > > Though I thought the use of high-numbered diversions was > actually a supported thing - or was that only in 2.13? > That argument is not supported by the autoconf manual. Please see the discussion at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542906#10 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] 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 actual case? > > Do you have an example where it's actually needed? Yes, every time a new libdb version is released we would have to patch the config.m4 file. Instead, what this patch does is make the config.m4 pick the versionless files. For example, 5.3.1's ext/dba/config.m4 only knows up to db4.6 but at Debian we have already moved to 4.7 and are switching to 4.8. >> Can you tell me what exactly we are breaking? divert calls should only be >> used internally by autoconf and the, apparently useless, usage of them in >> php makes it fail to build with any other autoconf. > > If you remove them, things break. I don't remember right now why, but it > did, Rasmus tried this already and failed. Search the mailing lists for > more. His commit message is a bit weird, I think it should say "2.6x is > broken in so many ways" rather than 2.13: > >http://svn.php.net/viewvc?view=revision&revision=291414 > Well, we use autoconf2.63 (2.13 is soon to be dropped) and we need those changes to make it work. 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] 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 the configure again with this crap. I already > reverted the idiocy once, don't even think about doing this shit again. > PHP configure works properly only with autoconf-2.13 which was the last > working autoconf. Can you tell me what exactly we are breaking? divert calls should only be used internally by autoconf and the, apparently useless, usage of them in php makes it fail to build with any other autoconf. > >> fix_broken_upstream_tests.patch > > The soap thing seems ok. > > But why are you disabling > ext/standard/tests/general_functions/phpinfo.phpt ?? That test passes fine > for me everywhere. The patch says: > >test suite's handling of "%s" is incompatible with this test" > > Eh? I've never seen that test actually work but I don't remember the details right now. Will check it next time and report. > >> Which should all be merged > > And next time, please include direct links to the patches, makes easier to > follow these and comment on them. :) Ok. 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] Debian PHP patches
n general we prefer > to use the bundled lib so users get the same behavior on all > platforms. We use the shared library to avoid extra work on security issues and general maintenance. > > 108-64_bit_datetime.patch > 116-posixness_fix.patch > Why is that needed on our system? - I never saw an issue about these > and if they are missing there should be build issues. I will later be commenting on these two. > > use_embedded_timezonedb.patch > Like with the SQLite note above we prefer to have the same behavior > over all platforms by using a common time database. > Same here, updating the tz data on PHP everytime would be a pain. And yes, at some point we used the PECL extension but was later dropped in favour of the above patch. > force_libmysqlclient_r.patch > Why are you using the reentrant version of this library which is > slower than the "regular" one? Did you consider mysqlnd? * New patch: force_libmysqlclient_r.patch, forcing the build system to link against the threadsafe libmysqlclient without having to enable the other zts features in php. This is required since the apr libraries are now linking against this as well and mysql exports the same symbols from both libraries. Thanks to Stefan Fritsch (closes: #469081). I don't think we are going to switch to mysqlnd as it would require more maintenance from our part and more work in case of security issues. > > 009_ob-memory-leaks.patch >Any test case? (While this looks good on first sight) I think there was one for the original patch (as you can see the patch was taken from php). Later, when we refreshed the patches it was still applying at a different part of the same file and a quick review demonstrated it looked correct. > > exif_read_data-segfault.patch >Any sample case for this? Any bug report? > Looks like somebody forgot to remove it, as the code is already upstream (and the context that can be seen is exactly the same check). This is the fix for CVE-2009-2687. > sybase-alias.patch >I have no idea about MS SQL and Sybase but "randomly" aliassing looks >bad to me. Since the mssql and sybase extensions both use freetds their internal behaviour is the same. As such, the aliases were added to preserve compatibility with applications using the sybase set of functions. > > strcmp_null-OnUpdateErrorLog.patch >You should at least ad an "echo 'done';" or such to the expect >section to make sure it really works ... Could be added, yes, but in case it fails it would lead to a segfault. > > I skipped the patches related to build system and such and maybe skipped > one or two by accident > Some of the other patches include: libdb_is_-ldb 115-autoconf_ftbfs.patch fix_broken_upstream_tests.patch bad_whatis_entries.patch Which should all be merged. Here's 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/unsub.php
Re: [PHP-DEV] Throwing an E_DEPRECATED for short_open_tag
Patrick ALLAERT wrote: > 2010/1/13 Derick Rethans : >> 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" but still allows those apps to work. > > Raphael, you didn't seem to react on Derick's suggestion above > although it seems one of the best proposition so far. > I sort of commented about it on one of my replies to Rasmus. The problem with that approach is that not all SAPIs can be configured via a .htaccess, and changing the global value affects all applications (and if they all use a SAPI where .htaccess files can't change the settings there's not much they can do). 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
Rasmus Lerdorf wrote: > Raphael Geissert wrote: >> I'm still looking for a way to warn about the use of open_short_tag not >> being explicitly enabled on the PERDIR level. Otherwise the only thing I >> see would make applications change would be when the default is Off and >> they break. > > But why do you want them to change? Short tags are convenient and if > the app doesn't have to worry about run happily with short tags enabled. Because it is just not about the application but the whole system. With the apache filter SAPI enabling short_open_tag is really a no-op. As for the other SAPIs it mostly depends on what kind of files are used and whether an extension such as htscanner is at hand or not. If that's not available, having to change the settings for every application is a mess. By making it a runtime-only option they would always work. 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
Philip Olson wrote: > > It's worth noting that PHP (as of 5.3) does not distribute a php.ini file > that contains default values (like php.ini-dist essentially did). So I > imagine issues arise when distributions want to enable one during the PHP > install. > > Curious, do you enable one of the php.ini-* files by default? Which? > Perhaps with a few other changed values to meet the defaults, like with > short_open_tag? On 5.2 and older we use -dist. On 5.3 we will take -production as a base but we have not yet decided what other changes we are going to make. 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
Rasmus Lerdorf wrote: > > Then we have to have logic to differentiate It would make the parser quite a bit more complex if we have to start > parsing stuff outside of the active open tags. Not sure it is worth the > effort nor the extra overhead. > Isn't something similar already done? I was thinking that making short_open_tag runtime-only would be the best solution (applying it only to include/require files, not on the same script enabling the option), but given the amount of necessary code and behaviour changes it is unsuitable for 5.3 (and somebody needs to be willing to do that). I'm not aware of something similar being proposed before, so, what do you think? I'm still looking for a way to warn about the use of open_short_tag not being explicitly enabled on the PERDIR level. Otherwise the only thing I see would make applications change would 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
Daniel Convissor wrote: > Hi Raphael: > >> What patch do you want to know more about? > > None. I am wondering if there is a resource for lay-people interested in > installing PHP via packages so they can know any eccentricities they will > encounter when compared to compiling it themselves. Well, there are multiple packages to make php use the system copies of the libraries and security enhancements, among many other reasons. > > For example, you discussed changing some ini settings and the possibility > of making short tags throw deprecated warnings. So I wouldn't be > surprised if there are other changes in your forks. The change on the ini file is to avoid breaking applications (that incorrectly rely on short_open_tag being On) on upgrade (which is very important). We aren't doing anything really different, the default value in the interpreter is still On. The warning was being proposed to make sure those applications are fixed to avoid having to carry the ini patch too long. > > Such a document could also be used to clarify/direct your discussions > here. The documentation will be included in the patch header. Note that most of them predate the time I joined the maintenance team. >> Patches have not been properly documented, but they are usually >> referenced by an entry on the changelog giving a bit more information. >> >> You can browse the patches applied to every release (and download or view >> them individually) at: >> http://patch-tracker.debian.org/package/php5 > > This is a little nicer than reading the whole diff file, but as you > mentioned, it still isn't documented well. Meaning it doesn't say > whether a patch is Debian specific or just bringing in something done by > the PHP team itself. Only the debian-quirks and php.ini_securitynotes patches are really 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://www.php.net/unsub.php
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 at [1]. >> >> How does this sound? > > We have no plans to deprecate the short open tag. So throwing an > E_DEPRECATED would not be appropriate. > True. An idea I just had was to continue throwing E_DEPRECATED (or a warning with a most appropriate name, if one is added) iff short tags are used without explicitly enabling them at runtime. I haven't looked at how the short_open_tag runtime switch was implemented so I don't know if it's possible or not. This would for example make the following code throw a warning: foo.php But not this one: bar.php Does that sound more reasonable? or do you have another idea? 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
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? (Other than reading a 600 kb diff file from the package web > page.) > What patch do you want to know more about? Patches have not been properly documented, but they are usually referenced by an entry on the changelog giving a bit more information. You can browse the patches applied to every release (and download or view them individually) at: http://patch-tracker.debian.org/package/php5 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
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 that the new release branch mere-tracking-tool goes live today, > so that the new experimental release branch based process works nicer, > so 5.3.2RC2 will follow shortly after (either until tomorrow, which will > be quite a rush, better tuesday next week) further progress then depends > on feedback from testers, hopefully 5.3.2 will be out very late > January/early February. > for 5.3.3 it depends on security issues being reported, bug fixes going > in, ... maybe 3 months after. Ok, so it looks we will be releasing with 5.3.2 + any backported patch necessary to fix important or critical bugs. Thanks for the info. > >> On a slightly different topic, I'd like to express that I would like to >> improve the communication between us (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. > > I think that's an important topic. And I think it would be good to > improve communication with packagers to unify things that might be > handled differently and prevent packagers from back-porting security > fixes in a wrong way. I now that MySQL has a "packgers" list, maybe such > a thing might be good for php, too. internals might sometimes be a bit > crowded to follow ... > Such kind of mailing list might be useful, yes. It would at least help give the impression that there's interest on improving the communication channels. That said, I think reading and at times discussing stuff here will still be needed. As for security patches, yes, it would help if for every issue there's a pointer to the commits fixing them. I recently started a discussion on oss- sec about PHP's security policy, but haven't brought it up with the php security team yet. I hope we can make a progress. 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 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
[PHP-DEV] Throwing an E_DEPRECATED for short_open_tag
Hi again, Disclaimer: although discussions about this topic tend to be heated (and hated) this is not the usual short_open_tag thread. Please refrain from talking about other previous proposals and whether short_open_tag should be dropped or not. As mentioned on my other post, at Debian we are planning to include 5.3 in Squeeze. Given that the development and production php.ini files both turn short_open_tag by default but many applications shipped by Debian itself still require it to be enabled, we have decided to _enable_ it again on the .ini files. 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 at [1]. How does this sound? [1] http://git.debian.org/?p=pkg- php/php.git;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] 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 exactly it will be released. Yes, I've seen the RCs. Hope it doesn't take long. > >> On a slightly different topic, I'd like to express that I would like >> to improve the communication between us (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. > > Awesome, does that also mean you'd be willing to listen in case we might > think some patches are a bad idea? > Yes, I'm willing to discuss patches. 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
[PHP-DEV] 5.3 release schedule and other bits
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. On a slightly different topic, I'd like to express that I would like to improve the communication between us (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 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 Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
