On 07/06/2011 05:24 PM, Tim Beale wrote:
> Hi,
>
> We've hit a problem in the recovery code and I'm struggling to understand why
> we do the following:
>
> /*
>* The recovery sort queue now becomes the regular
>* sort queue. It is necessary to copy the state
>* into
Hi,
We've hit a problem in the recovery code and I'm struggling to understand why
we do the following:
/*
* The recovery sort queue now becomes the regular
* sort queue. It is necessary to copy the state
* into the regular sort queue.
*/
sq_cop
Hi Steve,
Yes, sorry - we're using uClibc-0.9.30.1 on linux.
The problem is uClibc's semctl() always tries to access the fourth arg using
va_arg(), which results in a crash for us. It seems uClibc doesn't do any
checking on whether the semctl cmd specified actually needs the 4th semun arg.
I'm no
On 07/06/2011 01:02 PM, Florian Haas wrote:
> On 07/06/2011 03:52 PM, Steven Dake wrote:
>> From: Florian Haas
>>
>> Enable RDMA in RPM builds by default to maintain the previous behavior
>> (which always included --enable-rdma in the %configure invocation).
>
> Steve, seeing that you acked all t
On 07/06/2011 03:52 PM, Steven Dake wrote:
> From: Florian Haas
>
> Enable RDMA in RPM builds by default to maintain the previous behavior
> (which always included --enable-rdma in the %configure invocation).
Steve, seeing that you acked all the others, any objections to this one?
I didn't get y
Thanks for the patch
Reviewed-by: Steven Dake
On 07/06/2011 06:52 AM, Steven Dake wrote:
> From: Florian Haas
>
> Failure to force "C" dates will have RPM et al. complain about invalid
> dates and timestamps.
> ---
> Makefile.am |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
On 07/06/2011 07:08 AM, Florian Haas wrote:
> On 2011-07-06 15:59, Steven Dake wrote:
>> On 07/06/2011 06:56 AM, Florian Haas wrote:
>>> On 2011-07-06 15:49, Steven Dake wrote:
Florian,
I'll take improvements however I can get them, but sending patches to
the list is preferred t
On 2011-07-06 16:08, Florian Haas wrote:
> Hmmm. You can merge from my repo into yours, then use "git rebase -i
> " to edit commit messages and add your Reviewed-By lines. But
> the downside of this is that this creates in place of my changesets it
> creates new ones, and then I have to reset my t
On 07/06/2011 06:52 AM, Steven Dake wrote:
> From: Florian Haas
>
> Rather than curiously disable RDMA support by default in configure and
> enable it by default in RPM builds, streamline the default
> configuration to always turn RDMA support off. It can be enabled in
> RPM builds with "--with r
On 2011-07-06 16:07, Steven Dake wrote:
> On 07/06/2011 06:52 AM, Steven Dake wrote:
>> From: Florian Haas
>>
>> Having to force {ibverbs,rdmacm}_{LIBS,CFLAGS} looks positively odd;
>> so this may warrant further review. However, they are definitely not
>> needed if building without RDMA support.
On 2011-07-06 15:59, Steven Dake wrote:
> On 07/06/2011 06:56 AM, Florian Haas wrote:
>> On 2011-07-06 15:49, Steven Dake wrote:
>>> Florian,
>>>
>>> I'll take improvements however I can get them, but sending patches to
>>> the list is preferred that way multiple people can look at them.
>>
>> Argu
On 07/06/2011 06:52 AM, Steven Dake wrote:
> From: Florian Haas
>
> Having to force {ibverbs,rdmacm}_{LIBS,CFLAGS} looks positively odd;
> so this may warrant further review. However, they are definitely not
> needed if building without RDMA support.
Florian,
I agree it does look odd, and I was
On 2011-07-06 15:49, Steven Dake wrote:
> Florian,
>
> I'll take improvements however I can get them, but sending patches to
> the list is preferred that way multiple people can look at them.
Arguably that counts for github too, as my repo happens to be quite
public. :)
> The way I generally do
On 07/06/2011 12:21 AM, Florian Haas wrote:
> On 2011-07-05 14:03, Fabio M. Di Nitto wrote:
>> I checked the changes in that branch and they are good to me.
>
> I've rebased my repo against current upstream (after the RRP ring
> recovery merge).
>
> Cheers,
> Florian
>
>
>
Florian
apologies
This signs the patch.
Regards
-steve
___
Openais mailing list
Openais@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/openais
From: Florian Haas
Rather than curiously disable RDMA support by default in configure and
enable it by default in RPM builds, streamline the default
configuration to always turn RDMA support off. It can be enabled in
RPM builds with "--with rdma".
---
corosync.spec.in |2 +-
1 files changed,
From: Florian Haas
Having to force {ibverbs,rdmacm}_{LIBS,CFLAGS} looks positively odd;
so this may warrant further review. However, they are definitely not
needed if building without RDMA support.
---
corosync.spec.in |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/cor
From: Florian Haas
Enable RDMA in RPM builds by default to maintain the previous behavior
(which always included --enable-rdma in the %configure invocation).
---
corosync.spec.in |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/corosync.spec.in b/corosync.spec.in
inde
From: Florian Haas
Failure to force "C" dates will have RPM et al. complain about invalid
dates and timestamps.
---
Makefile.am |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index 0929ca7..252caf1 100644
--- a/Makefile.am
+++ b/Makefile.am
On 07/05/2011 07:22 PM, Tim Beale wrote:
> Hi,
>
> Another issue we found upgrading was that the code doesn't compile when
> _POSIX_THREAD_PROCESS_SHARED < 1. When it does compile, it crashes on our
> system - our version of uClibc seems to always expect a 4th arg. The man pages
> suggests the 4th
On 07/05/2011 07:20 PM, Tim Beale wrote:
> Hi,
>
> We've just upgraded to corosync v1.3.1 and struck a problem with corosync
> failing to startup. The problem is the getpwnam_r()/getgrnam_r() calls return
> ERANGE on our system, meaning insufficient buffer space was supplied (the
> expected buffer
On 07/05/2011 04:51 PM, Russell Bryant wrote:
> On Tue, Jul 5, 2011 at 2:14 PM, Steven Dake wrote:
>> Signed-off-by: Steven Dake
>> ---
>> exec/totemsrp.c | 14 ++
>> 1 files changed, 14 insertions(+), 0 deletions(-)
>>
>> diff --git a/exec/totemsrp.c b/exec/totemsrp.c
>> index 3dc
On 2011-07-05 14:03, Fabio M. Di Nitto wrote:
> I checked the changes in that branch and they are good to me.
I've rebased my repo against current upstream (after the RRP ring
recovery merge).
Cheers,
Florian
signature.asc
Description: OpenPGP digital signature
23 matches
Mail list logo
