On Tue, Aug 23, 2011 at 10:26 PM, marius adrian popa wrote:
> On Tue, Aug 23, 2011 at 9:51 PM, Rasmus Lerdorf wrote:
>> On 08/23/2011 09:45 AM, Daniel Convissor wrote:
>>> Hi:
>>>
>>> On Sun, Aug 21, 2011 at 03:08:09PM +0200, Reindl Harald wrote:
FAIL DateTime::diff() days -- spring type2 ty
Lester Caine wrote:
Rasmus Lerdorf wrote:
and visit it daily from now on? I'd like to see this go to 0 before we
release the first 5.4 beta later this year. Probably by moving the bulk
of these to XFAIL, but in some cases the tests themselves really are
bogus and either need to be removed or fix
Reindl Harald wrote:
Actually this is possibly another argument for a properly managed DVCS setup?
On other projects I can pick
> critical commits and apply them, and it flags when other bits need to be
implemented as well. Almost does away
> with the need to produce actual releases, but you
+1, it is so good if there is no compile warnings or test failed at all. :-)
Thanks
Sent from my iPhone
在 2011-8-24，7:49，Daniel Convissor 写道：
> Hi Rasmus:
>
> On Tue, Aug 23, 2011 at 11:51:32AM -0700, Rasmus Lerdorf wrote:
>>
>> http://gcov.php.net/viewer.php?version=PHP_5_4&func=tests
>>
>> a
Hi Rasmus:
On Tue, Aug 23, 2011 at 11:51:32AM -0700, Rasmus Lerdorf wrote:
>
> http://gcov.php.net/viewer.php?version=PHP_5_4&func=tests
>
> and visit it daily from now on? I'd like to see this go to 0 before we
> release the first 5.4 beta later this year. Probably by moving the bulk
> of these
Hi!
On 8/23/11 2:37 PM, Derick Rethans wrote:
For the DateTime stuff, Dan and I (mostly Dan) are working on getting
this fixed, once we figure out how we want it to work.
Thanks! Recent test change doesn't look good though, unless I am missing
something - it makes add, diff and sub inconsiste
On Tue, 23 Aug 2011, Rasmus Lerdorf wrote:
> On 08/23/2011 09:45 AM, Daniel Convissor wrote:
> > Hi:
> >
> > On Sun, Aug 21, 2011 at 03:08:09PM +0200, Reindl Harald wrote:
> >> FAIL DateTime::diff() days -- spring type2 type2
> >> [ext/date/tests/DateTime_days-spring-type2-type2.phpt]
> >> FAIL
Rasmus Lerdorf wrote:
and visit it daily from now on? I'd like to see this go to 0 before we
release the first 5.4 beta later this year. Probably by moving the bulk
of these to XFAIL, but in some cases the tests themselves really are
bogus and either need to be removed or fixed.
I think that th
On Tue, Aug 23, 2011 at 9:51 PM, Rasmus Lerdorf wrote:
> On 08/23/2011 09:45 AM, Daniel Convissor wrote:
>> Hi:
>>
>> On Sun, Aug 21, 2011 at 03:08:09PM +0200, Reindl Harald wrote:
>>> FAIL DateTime::diff() days -- spring type2 type2
>>> [ext/date/tests/DateTime_days-spring-type2-type2.phpt]
>>>
On 08/23/2011 09:45 AM, Daniel Convissor wrote:
> Hi:
>
> On Sun, Aug 21, 2011 at 03:08:09PM +0200, Reindl Harald wrote:
>> FAIL DateTime::diff() days -- spring type2 type2
>> [ext/date/tests/DateTime_days-spring-type2-type2.phpt]
>> FAIL DateTime::diff() days -- spring type2 type3
>> [ext/date/
Hi:
On Sun, Aug 21, 2011 at 03:08:09PM +0200, Reindl Harald wrote:
> FAIL DateTime::diff() days -- spring type2 type2
> [ext/date/tests/DateTime_days-spring-type2-type2.phpt]
> FAIL DateTime::diff() days -- spring type2 type3
> [ext/date/tests/DateTime_days-spring-type2-type3.phpt]
> FAIL DateTi
Am 22.08.2011 13:08, schrieb Lester Caine:
> Reindl Harald wrote:
>> there should be placed diff-files for security fixes directly on the
>> download-page
>> they could be easily included in rpmbuild/spec-file if they are matching to
>> the latest
>> tar.bz2, but the current release process doe
Reindl Harald wrote:
there should be placed diff-files for security fixes directly on the
download-page
they could be easily included in rpmbuild/spec-file if they are matching to the
latest
tar.bz2, but the current release process does not support this and forces users
if they wanting their ma
Am 22.08.2011 11:33, schrieb Lester Caine:
> Pierre Joye wrote:
>> but does it work with 5.3.6? On the servers where 5.3.7 fails?
>
> While switching back should simply be a matter of telling the package manager
> to use the older version
with full disclosed security-bugs they are open and kno
Pierre Joye wrote:
but does it work with 5.3.6? On the servers where 5.3.7 fails?
While switching back should simply be a matter of telling the package manager to
use the older version ... how many people actually get that process to work?
Not a PHP problem, but one that affects most of us now
YES how often shoud i reapeat this?
* < 5.3.6 since a year on several machines cronjobs connecting per WAN to mysql
* update to 5.3.7
* it takes 30 minutes to get the first error-mails from cronjobs
* it takes so long because they all run in a timeout
* after an hour you have 50 instances of every
but does it work with 5.3.6? On the servers where 5.3.7 fails?
On Mon, Aug 22, 2011 at 10:26 AM, Reindl Harald wrote:
> i can not easily replace files because rpmbuild does
> unpack and patch the source automated and some patches
> are needed since ages to get PHP even compiled on fedora
>
> Am 2
i can not easily replace files because rpmbuild does
unpack and patch the source automated and some patches
are needed since ages to get PHP even compiled on fedora
Am 22.08.2011 10:05, schrieb Andrey Hristov:
> Hi guys,
> what I observe is hanging on the client side with SSL. Pconn doesn't matte
On Sun, Aug 21, 2011 at 8:55 PM, Reindl Harald wrote:
>> be the server or the libmysql
>
> we are speaking about mysqlnd, libmysql is not involved
> the problem is taht something for libmysql was fixed and breaking mysqlnd
It was about giving examples where similar issues happened in the
past, no
> be the server or the libmysql
we are speaking about mysqlnd, libmysql is not involved
the problem is taht something for libmysql was fixed and breaking mysqlnd
please look again at https://bugs.php.net/bug.php?id=55283
there is a comment "Changing mysqli to make libmysql happy will cause leaks
That's not why I said.
There could have a bug in the server making the actual valid fix not
working with some versions. It happened already a lot in the past (be
the server or the libmysql).
On Sun, Aug 21, 2011 at 8:46 PM, Reindl Harald wrote:
> hardly to understand because the mysql-server is
hardly to understand because the mysql-server is unchanged
mysql 5.5.15 and before 5.3.7 there was no problem for
over a year - so if the only changed component is PHP 5.3.7
how should the problem be not PHP?
Am 21.08.2011 20:30, schrieb Pierre Joye:
> hi,
>
> I shortly discussed this issue with
hi,
I shortly discussed this issue with Ulf. As far I can tell it is not
certain that this bug is in php itself but on the server side. It
means that the fix applied in 5.3.7 actually works with server
versions but not other.
However we can't take a decision without their agreement (no revert if
Am 21.08.2011 16:21, schrieb Daniel Convissor:
> Hi Reindl:
>
> On Sun, Aug 21, 2011 at 03:08:09PM +0200, Reindl Harald wrote:
>> This is my try to help badly prevent broken releases like
>> 5.3.7 in the future, 54 failing tests are way too much and
>> the XFAILED should be removed until they are
Hi Again Reindl:
On Sun, Aug 21, 2011 at 10:21:40AM -0400, Daniel Convissor wrote:
> On Sun, Aug 21, 2011 at 03:08:09PM +0200, Reindl Harald wrote:
>
> > FAIL DateTime::diff() days -- spring type2 type2
> > [ext/date/tests/DateTime_days-spring-type2-type2.phpt]
> > FAIL DateTime::diff() days -- s
Hi Reindl:
On Sun, Aug 21, 2011 at 03:08:09PM +0200, Reindl Harald wrote:
> This is my try to help badly prevent broken releases like
> 5.3.7 in the future, 54 failing tests are way too much and
> the XFAILED should be removed until they are working
XFAIL's should stay, in my opinion. Their resu
Am 21.08.2011 15:21, schrieb Pierre Joye:
> hi,
>
> The question is more about whether this bug was present before as
> well. If yes, I'd to wait to make sure we get 5.3.8 out on Tuesday
> without any other change but the crypt's fix
as said it was broken with 5.3.7
what about release 5.3.8 w
hi
it was surely not present in mysqlnd before because we are running a bundle
of servers which using the same ssl-certs for php and mysql over WAN and all
of them started running in timeot/mysql server gone away directly
after update to PHP 5.3.7 (we are speaking about cronjobs every 5 minutes)
hi,
The question is more about whether this bug was present before as
well. If yes, I'd to wait to make sure we get 5.3.8 out on Tuesday
without any other change but the crypt's fix.
Cheers,
On Sun, Aug 21, 2011 at 3:08 PM, Reindl Harald wrote:
> This is my try to help badly prevent broken rel
This is my try to help badly prevent broken releases like
5.3.7 in the future, 54 failing tests are way too much and
the XFAILED should be removed until they are working
the crypt()-bug which is the reason for 5.3.8 this week is fixed
in this build with the patch included on fedora-buildserver
Te
30 matches
Mail list logo
