On Fri, Jun 13, 2008 at 09:57:23AM -0600, Brad Nicholes wrote:
> What is the status of this patch? Does it need to be proposed for backport?
> If so, 3.1.x and 3.0.x?
the implementations suggested at the end of these email are not yet complete
(attached patch which removes the "four times" hard
On Sat, Jun 14, 2008 at 12:36:01AM +0200, Ulf wrote:
>
> great work your version 3.1.0.1410 seems to work, the "EXPORT_SYMBOLS =
> -Wl,-bexpfull" fixes the problem. I think this was the only change, haven' t
> checked that.
yes and should work for AIX 5.1 maintenance level 2 or older; checked i
On Mon, Jun 16, 2008 at 11:29:40AM -0700, Bernard Li wrote:
>
> I can revert this if Carlo has no issues. Sorry for the "bad" check-in.
why would I have any issues?, revert was my initial option if only I decided
instead to do some cleanup and figure out what the real problem was from the
bug re
>>> On 6/13/2008 at 10:16 AM, in message
<[EMAIL PROTECTED]>, "Bernard Li"
<[EMAIL PROTECTED]> wrote:
> Hi Brad:
>
> On Fri, Jun 13, 2008 at 9:08 AM, Brad Nicholes <[EMAIL PROTECTED]> wrote:
>
>> Not sure either, but I would like to know why gmetad-python is not able to
> connect to a data_sourc
Hi:
On Mon, Jun 16, 2008 at 10:26 AM, Brad Nicholes <[EMAIL PROTECTED]> wrote:
> This isn't the right thing to do. It leaves the gmetric memory allocation
> coming from two different pools with no way to clean it up completely. It
> actually introduces a memory leak. See my comments in the
This isn't the right thing to do. It leaves the gmetric memory allocation
coming from two different pools with no way to clean it up completely. It
actually introduces a memory leak. See my comments in the bug
(http://bugzilla.ganglia.info/cgi-bin/bugzilla/show_bug.cgi?id=190). A gmetric
