Dave Shield wrote:
> We've agreed to not fix a bug, because of a concern that the fix is likely
> to have greater impact than the bug itself.
>That's a judgement call, and may turn out to be the wrong decision.
> But it's not an unreasonable position to take.
Exactly. (And I still feel confide
On 16/10/2007, Wes Hardaker <[EMAIL PROTECTED]> wrote:
> But do realize we've just voted to not fix a bug in previous releases.
> It's not a new feature. It fixes the usability of a library.
We've agreed to not fix a bug, because of a concern that the fix is likely
to have greater impact than the
> "TA" == Thomas Anders <[EMAIL PROTECTED]> writes:
TA> Great we all agree on that. Wes, would you mind committing the patch
TA> with the library boolean to trunk?
Yep, I will.
But do realize we've just voted to not fix a bug in previous releases.
It's not a new feature. It fixes the usabil
Magnus Fromreide wrote:
> On mån, 2007-10-15 at 13:07 -0400, Robert Story wrote:
>> On Mon, 15 Oct 2007 19:03:12 +0200 Thomas wrote:
>> TA> Robert Story wrote:
>> TA> > I tend to agree. And if we are going to make this a public global in
>> the
>> TA> > library, then I strongly suggest we rename i
On mån, 2007-10-15 at 13:07 -0400, Robert Story wrote:
> On Mon, 15 Oct 2007 19:03:12 +0200 Thomas wrote:
> TA> Robert Story wrote:
> TA> > I tend to agree. And if we are going to make this a public global in the
> TA> > library, then I strongly suggest we rename it, prefixing with
> 'netsnmp_trap
On Mon, 15 Oct 2007 19:03:12 +0200 Thomas wrote:
TA> Robert Story wrote:
TA> > I tend to agree. And if we are going to make this a public global in the
TA> > library, then I strongly suggest we rename it, prefixing with
'netsnmp_trapd'
TA> > or something in that vein...
TA>
TA> +1 for the rename,
Robert Story wrote:
> I tend to agree. And if we are going to make this a public global in the
> library, then I strongly suggest we rename it, prefixing with 'netsnmp_trapd'
> or something in that vein...
+1 for the rename, but I still think this change should be trunk only.
IMHO there's not enou
On Tue, 09 Oct 2007 09:02:23 +0200 Magnus wrote:
MF> On mån, 2007-10-08 at 12:01 -0700, Wes Hardaker wrote:
MF> > The 5.4.1 code:
MF> >
MF> > - Has an int in snmptrapd.c called "dropauth".
[...]
MF> > Cause the solution also changes the interface for libnetsnmptrap too? I
MF> > think? And may nee
On mån, 2007-10-08 at 12:01 -0700, Wes Hardaker wrote:
> The 5.4.1 code:
>
> - Has an int in snmptrapd.c called "dropauth".
> - This int is referenced (extern) in snmptrapd_handlers.c
> - snmptrapd_handlers.c gets compiled into libnetsnmptrapd
> - TrapReceiver.xs (part of the NetSNMP::TrapReceiver
> "TA" == Thomas Anders <[EMAIL PROTECTED]> writes:
TA> Now, if one uses the same code *from within snmptrapd* (as done by
TA> default through snmp_perl_trapd.pl as shipped), the code *does* work
TA> because snmptrapd has dropauth itself. This is also why test #36
TA> ("snmptrapd embedded perl
Wes Hardaker wrote:
> The 5.4.1 code:
>
> - Has an int in snmptrapd.c called "dropauth".
> - This int is referenced (extern) in snmptrapd_handlers.c
> - snmptrapd_handlers.c gets compiled into libnetsnmptrapd
> - TrapReceiver.xs (part of the NetSNMP::TrapReceiver perl module) fails
> to load at
> "WH" == Wes Hardaker <[EMAIL PROTECTED]> writes:
WH> Same problem + a similar problems = new patch:
And that patch had syntax errors; but you'll get the drift. I have a
working one.
--
Wes Hardaker
Sparta, Inc.
-
Thi
> "WH" == Wes Hardaker <[EMAIL PROTECTED]> writes:
WH> The 5.4.1 code:
Same problem + a similar problems = new patch:
Index: apps/snmptrapd_ds.h
===
--- apps/snmptrapd_ds.h (revision 16710)
+++ apps/snmptrapd_ds.h (working copy)
The 5.4.1 code:
- Has an int in snmptrapd.c called "dropauth".
- This int is referenced (extern) in snmptrapd_handlers.c
- snmptrapd_handlers.c gets compiled into libnetsnmptrapd
- TrapReceiver.xs (part of the NetSNMP::TrapReceiver perl module) fails
to load at run-time because it links to libn
14 matches
Mail list logo
