Would probably help if I included the diffs:

-Bug #33414 [2] (Comprehensive list of incorrect days returned after
strotime() / date() tests) [ext/date/tests/bug33414-2.phpt]

033+ result=Wednesday 1970-01-07 00:00:00 PST 0
033- result=Wednesday 1970-01-06 00:00:00 PST 0

-Bug #16069 [ext/iconv/tests/bug16069.phpt]

001+ ????????????????????????????????????????(?맥??)
001-
?ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???
ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?С???ߥ?
С???ߥ?С???ߥ?С???(?맥??)

-iconv stream filter [ext/iconv/tests/iconv_stream_filter.phpt]

(related to the last one it looks like)

007+ string(20) "1b244f24332466245824"
008+ string(10) "4e24421b28"
009+ string(2) "4f"
007-
008- Warning: fread(): iconv stream filter ("ISO-2022-JP"=>"EUC-JP"):
invalid multibyte sequence in %s on line %d
009- string(0) ""
010- string(0) ""
011- string(0) ""

-Bug #31142 test #2 (imap_mail_compose() generates incorrect output)
[ext/imap/tests/bug31142_2.phpt]

This one is caused by a segfault. bt is:

#0 0x407545c8 in pthread_mutex_lock () from /lib/libpthread.so.0
#1 0x40906dd8 in free () from /lib/libc.so.6
#2 0x40073d93 in fs_give () from /usr/lib/libc-client.so.2001
#3 0x40070b5b in mail_free_body_parameter () from
/usr/lib/libc-client.so.2001
#4 0x40070a5c in mail_free_body_data () from /usr/lib/libc-client.so.2001
#5 0x40070996 in mail_free_body () from /usr/lib/libc-client.so.2001
#6 0x080f797f in zif_imap_mail_compose (ht=2, return_value=0x84b3ebc,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1)
at /home/rasmus/php51/ext/imap/php_imap.c:3240
#7 0x08276526 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfffd6f0) at zend_vm_execute.h:184
#8 0x08275d49 in execute (op_array=0x84af31c) at zend_vm_execute.h:87
#9 0x0825540c in zend_execute_scripts (type=8, retval=Variable "retval"
is not available.
) at /home/rasmus/php51/Zend/zend.c:1078
#10 0x0821eb1b in php_execute_script (primary_file=0xbffffaac) at
/home/rasmus/php51/main/main.c:1675
#11 0x082dd78a in main (argc=3, argv=0xbffffb64) at
/home/rasmus/php51/sapi/cli/php_cli.c:1039

Probably do to a bogus pthread-enabled libc-client on this Debian box.

-various fputcsv() functionality tests
[ext/standard/tests/file/fputcsv.phpt]

040+ 16 => 'aaa,"\"bbb",ccc',
041+ 17 => 'aaa"\"a""","bbb"',
042+ 18 => '"\""","aaa"""',
043+ 19 => '"\"""",aaa
044+ ',
040- 16 => 'aaa,"\"bbb,ccc',
041- 17 => 'aaa"\"a","bbb"',
042- 18 => '"\"","aaa"',
043- 19 => '"\""",aaa',

-Bug #27908 (default handler not being called) [ext/xml/tests/bug27908.phpt]

001- x_default_handler <root>
002- x_default_handler </root>

-Rasmus

Also, I see the following 6 failed test cases on my Linux box:

-Bug #16069 [ext/iconv/tests/bug16069.phpt]

According to the last two comments in that bug report, glibc iconv()
does not support CP932 and this test should be skipped instead of
failing. No idea how to check for that in the test system, so I'll
leave it to Jani or someone else.

-iconv stream filter [ext/iconv/tests/iconv_stream_filter.phpt]

This test exhibits wildly different behavior depending on the platform
and/or version of iconv library. On BSD the last portion of it fails
with "unknown error" instead of "invalid multibyte sequence". On Linux
(with glibc iconv) it moronically goes ahead and actually decodes the
ROT-13 "encrypted" data without outputting any errors. I don't think
there's much we can do here unless we're willing to invest an
inordinate amount of effort into tracking down specific iconv()
versions and making allowances for them everywhere.

-Andrei

Rasmus Lerdorf wrote:

-Bug #31142 test #2 (imap_mail_compose() generates incorrect output)
[ext/imap/tests/bug31142_2.phpt]

This bug was just fixed.

Ilia

http://bugs.php.net/search.php?cmd=display&status=Open&bug_type%5B%5D=PDO+related
http://pecl.php.net/bugs/search.php?cmd=display&status=Open&package_name%5B%5D=PDO&package_name%5B%5D=PDO_FIREBIRD&package_name%5B%5D=PDO_MYSQL&package_name%5B%5D=PDO_OCI&package_name%5B%5D=PDO_ODBC&package_name%5B%5D=PDO_PGSQL&package_name%5B%5D=PDO_SQLITE

They sound pretty straight-forward (although #33707 and #34233 sound a
bit harder), so if you do have some resources to throw at them, I'd
really appreciate it--I've just been too damned busy lately, and don't
forsee having the time to sit down and get it done for a week or so.

--Wez.

Wez Furlong wrote:

There's a bunch of open PDO bugs that need to be fixed before we go
with 5.1 final.

Do you have some sort of plan/timeline for these getting fixed? Do you
need some help? We can't wait indefinitely on PDO. If you have a list
of outstanding issues I can throw some resources at it.

For those of you who submitted patches to 5.1 since RC1 - do you believe that
we need another RC or can we go ahead and roll 5.1 final and run a sanity test
for 24 hours? I went over the patches, none of them appears to be too
dangerous, but if any of you thinks differently, let me know.

Should I also commit:
http://files.derickrethans.nl/patches/e_recoverable_error-php-5.1-20050826.diff.txt
?

Should I assume that if nobody replies, there are no objections?

 I'm replying now and I don't want to see something like this in 5.1.
 This is new stuff, new stuff goes to HEAD..

 --Jani