On Fri, 22 Jul 2022 at 17:54, Magnus Fromreide wrote:
> 06_extramibs.patch - which adds the Gnome MIB - touches on something I have
> pondering - how should a distribution add MIBs?
>
> On Debian we have this patch.
>
> On RedHat Net-SNMP ships one heap of MIBs and libsmi ships another,
> slightl
On Thu, Jul 21, 2022 at 08:37:29PM +1000, Craig Small wrote:
> Hi,
> I'd like to see how I can reduce the number of patches carried by the
> Debian net-snmp packages. Some of these will have to stay because we have a
> particular way of storing files for example. That wil
Hi,
I'd like to see how I can reduce the number of patches carried by the
Debian net-snmp packages. Some of these will have to stay because we have a
particular way of storing files for example. That will also mean these
fixes will be everywhere and not just in Debian.
If you want to see
On Thu, Aug 13, 2020 at 03:55:31PM -0700, Wes Hardaker via Net-snmp-coders
wrote:
> Magnus Fromreide writes:
>
> > I just noticed that T0222snmpv3bulkget_simple depends on SHA authentication
> > and AES privacy but fails to check for this so if one builds the agent
> > without that support the t
Magnus Fromreide writes:
> I just noticed that T0222snmpv3bulkget_simple depends on SHA authentication
> and AES privacy but fails to check for this so if one builds the agent
> without that support the test fails.
Is it really just that test? I actually thought that most of the tests
were usin
Hello!
I just noticed that T0222snmpv3bulkget_simple depends on SHA authentication
and AES privacy but fails to check for this so if one builds the agent
without that support the test fails.
Now, I am not certain about exactly what T0222 tests but I think it is about
bulkget limits and thus the u
Hello,
This is a series of nine patches that have not yet been posted before
on the net-snmp-coders mailing list and of which I think these are worth
applying before v5.8 is released. Since we are in the rc phase at least
three positive votes are required before any of these patches can be
Thank you Wes, sorry for being impatient.
I happen to be retouching the more direct python<->C API changes I'm using
to do asynchronous collection. I'll rebase master and send you a pull
request with those, but I don't know if you'd rather have them as a stream
of commits, or as complete files to
David Hankins writes:
> I conclude the net-snmp maintainers have no engagement model.
No, you did the right thing. We're a bit distracted, admittedly.
I'll go look at it.
--
Wes Hardaker
Please mail all replies to [email protected]
I conclude the net-snmp maintainers have no engagement model.
On Wed, Nov 16, 2016 at 2:50 PM, David Hankins wrote:
> I've had a pull request in sourceforge open since March. It's not a huge
> deal, it fixes a problem where a single error in a python NetSNMP session
> causes all subsequent requ
On Tue, Dec 13, 2016 at 1:47 AM, Bart Van Assche
wrote:
> On 12/12/2016 08:56 PM, Bill Fenner wrote:
>
>> On Mon, Nov 28, 2016 at 11:44 PM, bart > <mailto:[email protected]>> wrote:
>>
>>
>>
On Mon, Dec 12, 2016 at 02:56:32PM -0500, Bill Fenner wrote:
> On Mon, Nov 28, 2016 at 11:44 PM, bart
> wrote:
>
> >
> > The branch, V5-7-patches has been updated
> > 413eb441c2f71298cd07ff0c480505ba62cad8bb ->
> > 920f20b745da6c90c56a68d6d1ea782ca4fc074b
On Mon, Nov 28, 2016 at 11:44 PM, bart
wrote:
>
> The branch, V5-7-patches has been updated
> 413eb441c2f71298cd07ff0c480505ba62cad8bb ->
> 920f20b745da6c90c56a68d6d1ea782ca4fc074b
>
> ...
> create mode 100644 include/net-snmp/library/netsnmp-attribute-format.h
I've had a pull request in sourceforge open since March. It's not a huge
deal, it fixes a problem where a single error in a python NetSNMP session
causes all subsequent requests to be treated as errors (even if they
succeeded).
But I have a bunch of other changes queued up to send you behind this
ally breaking it in the future.
Maybe I should read the RFCs and review patches, which on the other hand
> will not take any less time :)
>
Something that might take less time is to *try* patches, say "I had this
problem, tried this patch and my problem went away too".
My biggest p
Hi list,
We've been using snmptrapd_sql and noticed a few issues with it.
The first one should be obvious, and I hope the second isn't too contentious.
The third one is the one I'm not sure about - if it should be done another way,
I'm all ears.
-
Den 28-01-2013 23:19, Claus Klein skrev:
> It prevent MIB loading while test, so some tests fails.
> I have to change it to an absolute path.
Good you found it
> Today, I tried to run the test under ubunto linux with new default dash
> shell.
> The make test exit immediately.
> When I change /bin
it.
For the next project, we will change to the next long term supported
branch.
//Regards
Claus
On 28.01.2013, at 06:41, Niels Baggesen wrote:
On Sun, Jan 27, 2013 at 12:07:40AM +0100, Claus Klein wrote:
Hi,
what is the status of the current V5.4-patches branch?
Is it planed to release
On Sun, Jan 27, 2013 at 12:07:40AM +0100, Claus Klein wrote:
> Hi,
> what is the status of the current V5.4-patches branch?
> Is it planed to release a v5.4.5 version this year?
I would expect that, yes
> I tried the following before working on some back-ports for this branch
Hi,
what is the status of the current V5.4-patches branch?
Is it planed to release a v5.4.5 version this year?
I tried the following before working on some back-ports for this branch:
+ git checkout V5-4-patches
Switched to a new branch 'V5-4-patches'
Branch V5-4-patches set up to tr
On 23 April 2012 05:47, Lawrence E Widman wrote:
> Also, snmpset doesn't work with Counter32 or Counter64 because
> the 'c' and 'C' types were inadvertantly omitted from the
> current source.
No - that was not an oversight.
It is not permissable to SET counter-based objects.
They are inherently r
Robert, Thanks! - Larry
On Mon, Apr 23, 2012 at 09:16:15AM -0400, Robert Story wrote:
> You should submit them to the patch tracker..
> http://net-snmp.org/patches/
--
Lawrence E. Widman, MD PhD
7950 Floyd Curl Drive, Suite 803
San Antonio, TX 78229
210-615-9500 v, 210-615-9600
LEW> Also, snmpset doesn't work with Counter32 or Counter64 because
LEW> the 'c' and 'C' types were inadvertantly omitted from the
LEW> current source. Once these are added to the switch() statement,
LEW> it works fine.
LEW>
LEW> If these patches would b
; and 'C' types were inadvertantly omitted from the
current source. Once these are added to the switch() statement,
it works fine.
If these patches would be interesting, what is the right way
to submit them so you all can vet them?
Thanks - Larry Wid
On Fri, Jul 22, 2011 at 10:37 PM, Rudd, Michael wrote:
> Currently we are building net-snmp version 5.4.2.1 / 12.fc11. We had
> numerous patches we had downloaded to apply as well as a few of our own. *
> ***
>
> ** **
>
> Now we are moving to centos 6 which has version 5.5
Currently we are building net-snmp version 5.4.2.1 / 12.fc11. We had numerous
patches we had downloaded to apply as well as a few of our own.
Now we are moving to centos 6 which has version 5.5 / 27.el6_0.1. We've
noticed some of the 5.4.2.1 patches are applied to the source code and
autoreconf -iv.
>
> Modified Paths:
> --
>branches/V5-5-patches/include/net-snmp/net-snmp-config.h.in
>
Hello Dave,
Regenerating net-snmp-config.h.in revealed that the following is missing in
acconfig.h:
#define NETSNMP_DRAGONFLYID 17
#if defined(__DragonFly__)
#defin
On Wed, 12 Jan 2011 08:55:53 -0500 Robert wrote:
RS> Anyone else having issues in 5-4-patches?
RS>
RS> configure: creating ./config.status
RS> ./config.status: line 1511: warning: here-document at line 502 delimited by
end-of-file (wanted `\CEOF')
RS> ./config.status: lin
Anyone else having issues in 5-4-patches?
configure: creating ./config.status
./config.status: line 1511: warning: here-document at line 502 delimited by
end-of-file (wanted `\CEOF')
./config.status: line 1512: syntax error: unexpected end of file
THe fix is easy:
diff v5-4-pa
;> >>
>> >> Hello developers,
>> >>
>> >> I'm getting the following crash every time the agent is stopped. This
>> >> seems to
>> >> happen only with code from the v5-6-patches branch, not with trunk.
>> >>
>>
g the following crash every time the agent is stopped. This
> >> seems to
> >> happen only with code from the v5-6-patches branch, not with trunk.
> >>
> >> #0 __libc_free (mem=0x31) at malloc.c:3710
> >> #1 0x7f1d41403b80 in snmp_free_var_int
On Mon, Nov 1, 2010 at 1:15 PM, Bart Van Assche wrote:
> On Mon, Nov 1, 2010 at 2:13 PM, Leonardo Chiquitto
> wrote:
>>
>> Hello developers,
>>
>> I'm getting the following crash every time the agent is stopped. This
>> seems to
>> happen only w
On Mon, Nov 1, 2010 at 2:13 PM, Leonardo Chiquitto <
[email protected]> wrote:
> Hello developers,
>
> I'm getting the following crash every time the agent is stopped. This seems
> to
> happen only with code from the v5-6-patches branch, not with trunk.
>
&g
Hello developers,
I'm getting the following crash every time the agent is stopped. This seems to
happen only with code from the v5-6-patches branch, not with trunk.
#0 __libc_free (mem=0x31) at malloc.c:3710
#1 0x7f1d41403b80 in snmp_free_var_internals (var=0x7f1d423fcac0)
> On Fri, 15 Oct 2010 23:34:00 +0200, Magnus Fromreide
> said:
>> Cause it's C silly!
>>
>> If it was perl it'd be pagentlib! ha ha!
MF> p as in python I suppose?
No, see... Those silly python people believe that everything in their
world should start with "py" so we're safe there (
> On Fri, 15 Oct 2010 21:20:18 +0200, Bart Van Assche
> said:
>> > On Fri, 15 Oct 2010 17:09:57 +0200, Bart Van Assche <
>> [email protected]> said:
>>
BVA> How about the suffix "cagentlib" for agent library tests ?
>>
>> Sounds fine!
>>
BVA> See also r19466.
Great, thanks!
--
On Fri, 2010-10-15 at 09:04 -0700, Wes Hardaker wrote:
> > On Fri, 15 Oct 2010 16:52:02 +0100, Dave Shield
> > said:
>
> DS> What's the meaning of the leading 'c' in these two prefixes?
> DS> I.e. why 'cagentib_' rather than simple 'agentlib_' ?
>
> Cause it's C silly!
>
> If it was pe
On Fri, Oct 15, 2010 at 5:35 PM, Wes Hardaker <
[email protected]> wrote:
> > On Fri, 15 Oct 2010 17:09:57 +0200, Bart Van Assche <
> [email protected]> said:
>
> BVA> How about the suffix "cagentlib" for agent library tests ?
>
> Sounds fine!
>
See also r19466.
Bart.
-
> On Fri, 15 Oct 2010 16:52:02 +0100, Dave Shield
> said:
DS> What's the meaning of the leading 'c' in these two prefixes?
DS> I.e. why 'cagentib_' rather than simple 'agentlib_' ?
Cause it's C silly!
If it was perl it'd be pagentlib! ha ha!
--
Wes Hardaker
Please mail all replies to
>> My feeling for this, was that
>> the clib_ prefix would be for the base library only and should stay that
>> way and another prefix should be used for the agent library.
> How about the suffix "cagentlib" for agent library tests ?
Silly question time:
What's the meaning of the leadin
> On Fri, 15 Oct 2010 17:09:57 +0200, Bart Van Assche
> said:
BVA> How about the suffix "cagentlib" for agent library tests ?
Sounds fine!
--
Wes Hardaker
Please mail all replies to [email protected]
-
On Fri, Oct 15, 2010 at 3:24 PM, Wes Hardaker <
[email protected]> wrote:
>
> Regarding this one:
>
> Log Message:
> ---
> CHANGES: testing: Unit tests can now invoke functions from libagent.
> CHANGES: testing: Added unit test for table_dataset.
> (Backported from r19450
Regarding this one:
Log Message:
---
CHANGES: testing: Unit tests can now invoke functions from libagent.
CHANGES: testing: Added unit test for table_dataset.
(Backported from r19450 from the trunk.)
My feeling for this, and my eventual plan that I didn't get to, was that
the c
If any get +3 in the next few hours, I'll apply them before rc2.
They're worth looking through quickly as many are good bug fixes.
--
Wes Hardaker
Please mail all replies to [email protected]
--
This
> On Wed, 31 Mar 2010 09:42:30 +0100, Dave Shield
> said:
DS> I'm not particularly bothered about the 5.2.x line, since this is
DS> being shut down anyway, and we'd want to discourage people
DS> from using it. But I'm strongly in favour of including some
DS> form of this fix in the 5.4
> On Wed, 31 Mar 2010 08:54:27 -0400, Robert Story
> said:
RS> sounds like a good place for a netsnmp_assert(). :-)
Note that there are a few new macros now that improve netsnmp_assert to
allow for returning a value when the assert condition is hit and a hard
break isn't turned on by a
On Wed, 31 Mar 2010 09:11:25 +0100 Dave wrote:
DS> Is this ever going to happen?
DS> The value 'multiplier' is based on either 'f_bsize' or 'f_frsize'
DS> (scaled from bytes to kB)
DS>Are either of these ever going to be zero?
DS>
DS> If so, the underlying system is probably fundamentally brok
On Wed, Mar 31, 2010 at 10:55 AM, Dave Shield wrote:
> On 31 March 2010 09:44, Bart Van Assche wrote:
> > On most 64-bit systems sizeof(int) == 4 and on some others sizeof(int) ==
> 8.
>
> But what is the value of INT32_MAX on such systems?
> I would expect that to be 0x7fff regardless of the
On 30 March 2010 20:32, Magnus Fromreide wrote:
> a) It won't compile due to
>
> if (x < (y / z)
Argghhh!!!
Thanks.
> b) I would probably prefer the following since it makes sense to use
> a well known name and this define is located in an implementation
> file.
>
> #ifndef INT32_MAX
>
On 31 March 2010 09:44, Bart Van Assche wrote:
> On most 64-bit systems sizeof(int) == 4 and on some others sizeof(int) == 8.
But what is the value of INT32_MAX on such systems?
I would expect that to be 0x7fff regardless of the value of sizeof(int)
I may well be missing something here, but
On Wed, Mar 31, 2010 at 10:08 AM, Dave Shield wrote:
> On 31 March 2010 08:25, Bart Van Assche wrote:
> >> MF> #ifndef INT32_MAX
> >> MF> #define INT32_MAX 0x7fff
> >> MF> #endif
>
> > It seems like some context information got lost in this discussion. The
> > constant in 0x7fff in the so
On 31 March 2010 03:25, Wes Hardaker wrote:
> Wa behind the times on this (sorry), but just FYI in case you
> haven't dealt with them already.
I've applied two-and-a-bit of the proposed patches.
It's really only the latching of disk stats that is outstanding.
> DS&g
On 31 March 2010 07:49, Bart Van Assche wrote:
> The code in the patch you posted will trigger a division by zero when
> multiplier == 0.
Is this ever going to happen?
The value 'multiplier' is based on either 'f_bsize' or 'f_frsize'
(scaled from bytes to kB)
Are either of these ever going to
On 31 March 2010 08:25, Bart Van Assche wrote:
>> MF> #ifndef INT32_MAX
>> MF> #define INT32_MAX 0x7fff
>> MF> #endif
> It seems like some context information got lost in this discussion. The
> constant in 0x7fff in the source file agent/mibgroup/ucd-snmp/disk.c
> ... [refers] to the larg
On Wed, Mar 31, 2010 at 4:16 AM, Wes Hardaker <
[email protected]> wrote:
> > On Tue, 30 Mar 2010 21:32:57 +0200, Magnus Fromreide <
> [email protected]> said:
>
> MF> b) I would probably prefer the following since it makes sense to use
> MF> a well known name and this define i
On Tue, Mar 30, 2010 at 2:07 PM, Dave Shield wrote:
> [ ... ]
>
> In response to these comments, I've drafted a revised version
> of this patch (attached), which uses the comparison code
> structure that you suggest.
> It also uses INT32_MAX where available (but doesn't rely
> on this necessaril
> On Mon, 22 Mar 2010 15:54:56 +, Dave Shield
> said:
Wa behind the times on this (sorry), but just FYI in case you
haven't dealt with them already.
DS> 1) Latch disk statistics: no / 54x only / both 54x and 52x
After reading the discussions, -1 unless all the issues are reso
> On Tue, 30 Mar 2010 21:32:57 +0200, Magnus Fromreide
> said:
MF> b) I would probably prefer the following since it makes sense to use
MF> a well known name and this define is located in an implementation
MF> file.
MF> #ifndef INT32_MAX
MF> #define INT32_MAX 0x7fff
MF> #endif
Ther
On Tue, 2010-03-30 at 13:07 +0100, Dave Shield wrote:
> On 24 March 2010 07:56, Magnus Fromreide wrote:
> >> 1) Latch disk statistics: no / 54x only / both 54x and 52x
> >
> > both -1
> >
> > Adds warnings about silly compares on 32 bit platforms.
> > Adds magic constant instead of using INT32_M
On 24 March 2010 07:56, Magnus Fromreide wrote:
>> 1) Latch disk statistics: no / 54x only / both 54x and 52x
>
> both -1
>
> Adds warnings about silly compares on 32 bit platforms.
> Adds magic constant instead of using INT32_MAX
> Works differently on 32 and 64 bit if the multiplication above
On 03/22/2010 04:54 PM, Dave Shield wrote:
> 1) Latch disk statistics (disk-latch.patch)
+1 both
> 2) Missing privKey crash (des-priv.patch)
+1 both
> 3) VACM best match(vacm-best-match.patch)
0
> 4) MIB dir path logging (mibdir-log.patch)
0
Jan
---
On Mon, 2010-03-22 at 15:54 +, Dave Shield wrote:
> On 21 March 2010 08:45, Dave Shield wrote:
> > On 20 March 2010 15:13, Robert Story wrote:
> >> Dave, have any other issues come up that might warrant a rc2?
> >
> > I've got a list of three or four pos
Dave Shield wrote:
> 1) Latch disk statistics: no / 54x only / both 54x and 52x
> 2) Missing privKey crash: no / 54x only / both 54x and 52x
> 3) VACM best match: no / 54x only / both 54x and 52x
> 4) MIB dir path logging: no / 54x only / both 54x and 52x
+1 for 1), 2), 3): both 54x and
On Mon, Mar 22, 2010 at 4:54 PM, Dave Shield wrote:
> Please find attached four proposed patches, which could potentially be
> applied to the 5.4.x (and 5.2.x) lines. We're currently in release-freeze
> for both of these branches, so could people please indicate whether or
> no
32-1 (for Unsigned32) or -2^31..2^31-1
> (for Integer32) isn't a valid SNMP value.
>
> But it sounds as if you're voting no for this patch being included.
> Which is fair enough - that's the point of putting it out to vote.
> (Of course, if no-one else chips in,
On Mon, 22 Mar 2010 15:54:56 + Dave wrote:
DS> 2) Missing privKey crash: no / 54x only / both 54x and 52x
This is a protocol bug that affects all platforms, so I vote both 54x and 52x
DS> 3) VACM best match: no / 54x only / both 54x and 52x
This is a protocol bug that affects all platf
for this patch being included.
Which is fair enough - that's the point of putting it out to vote.
(Of course, if no-one else chips in, then *none* of
these patches will be included!)
>> What if:
>> a) 'netsnmp_get_mib_directory' was added to
>>
On Tue, Mar 23, 2010 at 10:34 AM, Dave Shield
wrote:
> On 22 March 2010 18:46, Bart Van Assche wrote:
> > How well have these patches been tested, and on which platforms ?
>
> The first three were in response to queries on the mailing list.
> I've tested (2) and (3)
On 22 March 2010 18:46, Bart Van Assche wrote:
> How well have these patches been tested, and on which platforms ?
The first three were in response to queries on the mailing list.
I've tested (2) and (3) myself (on Fedora), and received
positive feedback from the original posters.
(4)
On Mon, Mar 22, 2010 at 4:54 PM, Dave Shield wrote:
> On 21 March 2010 08:45, Dave Shield wrote:
> > On 20 March 2010 15:13, Robert Story wrote:
> >> Dave, have any other issues come up that might warrant a rc2?
> >
> > I've got a list of three or four pos
On 21 March 2010 08:45, Dave Shield wrote:
> On 20 March 2010 15:13, Robert Story wrote:
>> Dave, have any other issues come up that might warrant a rc2?
>
> I've got a list of three or four possible patches sitting on my desk at work.
> I'll send out a CFV tomorrow.
On Sat, Mar 13, 2010 at 12:51 PM, Magnus Fromreide wrote:
> On Sat, 2010-03-13 at 09:14 +0100, Bart Van Assche wrote:
> > On Sat, Mar 13, 2010 at 2:28 AM, Wes Hardaker
> > wrote:
> > > On Fri, 19 Feb 2010 19:44:31 +0100, Bart Van Assche
> > said:
> >
> > BVA> It would
On Sat, 2010-03-13 at 09:14 +0100, Bart Van Assche wrote:
> On Sat, Mar 13, 2010 at 2:28 AM, Wes Hardaker
> wrote:
> > On Fri, 19 Feb 2010 19:44:31 +0100, Bart Van Assche
> said:
>
> BVA> It would make several Net-SNMP maintainers happy if
> support fo
On Sat, Mar 13, 2010 at 2:28 AM, Wes Hardaker <
[email protected]> wrote:
> > On Fri, 19 Feb 2010 19:44:31 +0100, Bart Van Assche <
> [email protected]> said:
>
> BVA> It would make several Net-SNMP maintainers happy if support for
> BVA> MSVC 6 could be dropped.
>
> It'd make ot
> On Fri, 19 Feb 2010 19:44:31 +0100, Bart Van Assche
> said:
BVA> It would make several Net-SNMP maintainers happy if support for
BVA> MSVC 6 could be dropped.
It'd make other Net-SNMP maintainers happy if support for MSCV could be
dropped.
Ha ha.
--
Wes Hardaker
Please mail all rep
On Fri, 19 Feb 2010 19:14:27 +0100 Magnus wrote:
MF> On Fri, 2010-02-19 at 12:35 +, [email protected] wrote:
MF> > Revision: 18166
MF> > http://net-snmp.svn.sourceforge.net/net-snmp/?rev=18166&view=rev
MF> > ---
MF> > Backported r17869: changed the return type of
On Fri, Feb 19, 2010 at 7:14 PM, Magnus Fromreide wrote:
> On Fri, 2010-02-19 at 12:35 +, [email protected] wrote:
> > Revision: 18166
> >
> http://net-snmp.svn.sourceforge.net/net-snmp/?rev=18166&view=rev
> > Author: bvassche
> > Date: 2010-02-19 12:35:03 + (Fri, 19 Feb
On Fri, 2010-02-19 at 12:35 +, [email protected] wrote:
> Revision: 18166
> http://net-snmp.svn.sourceforge.net/net-snmp/?rev=18166&view=rev
> Author: bvassche
> Date: 2010-02-19 12:35:03 + (Fri, 19 Feb 2010)
>
> Log Message:
> ---
> Backported r17869:
Thanks for those.
They have been applied to all relevant active lines of code,
and should be included in future releases of the software.
Dave
--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
pow
--
--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based develo
>>>>> On Mon, 10 Nov 2008 14:05:44 -0800, "dan anderson" <[EMAIL PROTECTED]>
>>>>> said:
da> "Submit your ideas, questions, patches etc. to the net-snmp-coders
da> mailing list as you come up with them." from
da> http://www.ne
dan anderson wrote:
> Er, I just realized that the net-snmp site says to submit patches
> using this list, but I don't recall actually seeing any - is this the
> right place?
Not sure where this is stated. The best place by nature in fact is the
project's patches tracker: http
"Submit your ideas, questions, patches etc. to the net-snmp-coders
mailing list as you come up with them." from
http://www.net-snmp.org/dev/helpingout.html
Thanks, I'll use the tracker from now on. (Especially for miniscule
comment-only patches like this!)
Cheers,
-Dan
2008/11/1
mån 2008-11-10 klockan 13:04 -0800 skrev dan anderson:
> Er, I just realized that the net-snmp site says to submit patches
> using this list, but I don't recall actually seeing any - is this the
> right place?
Ooops. We would prefer if you used the SF patch tracker to make sure
Er, I just realized that the net-snmp site says to submit patches
using this list, but I don't recall actually seeing any - is this the
right place?
-Dan
-
This SF.Net email is sponsored by the Moblin Your Move Develo
ensions to Net-SNMP patch
JS> tracker. But I am quite disappointed that most of these patches were not
JS> accepted and they did not stimulate any discussion at all.
Jan,
I'd like to apologize for the slowness of our patch application. It's
not your fault, it's ours. We t
Hello,
It's my job to maintain net-snmp in Red Hat Enterprise Linux and Fedora
distributions. During this work I fix problems reported by users and I
always try to send my bug fixes and extensions to Net-SNMP patch
tracker. But I am quite disappointed that most of these patches wer
Dear net-snmp-coders,
I submitted a patch for linkUp/linkDown traps generation. It also fixed
ifLinkUpDownTrapEnable effectiveness.
Regards,
Emi Yanagi
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C
On 10/05/07, Magnus Fromreide <[EMAIL PROTECTED]> wrote:
> I have a couple of patches which I think would be good to add, does
> anyone have any comments?
The first two look definite shoo-ins, the third seems plausible, though
I'd need to examine the context more carefully t
Hello!
I have a couple of patches which I think would be good to add, does
anyone have any comments?
cache_handler-always-log-tag:
Make sure that all debug lines are decorated with the tag that
controls the log.
hr_proc-log-in-right-domain:
Make the debug tag a bit more
On 22/01/07, Josef Moellers <[EMAIL PROTECTED]> wrote:
> We have finally found a solution to a bug which has kept us busy for
> quite some time: net-snmp-Bugs-1403948.
>
> The proposed patch reorders the takedown of an unresponsive agentx
> subagent session.
Looks good. Thanks.
> Kindly request
We have finally found a solution to a bug which has kept us busy for
quite some time: net-snmp-Bugs-1403948.
The proposed patch reorders the takedown of an unresponsive agentx
subagent session.
Kindly request acceptance of the patch,
Josef
--
Josef Möllers (Pinguinpfleger bei FSC)
If
imagined to fix this properly. Attached is a pile
of patches that I think fixes the problem.
snmp_sess_add_ex-consistent-delete:
This adddresses that snmp_sess_add_ex is unclear regarding the
ownership of the transport argument. The patch clarifies the
ownership issue to be that snmp_se
chris jalbert wrote:
> Thomas was working on this but his proposed patch did not work. This one
> does. [...]
>> Subject: [ net-snmp-Patches-1566777 ] Patch for memory_darwin.c
Applied.
+Thomas
--
Thomas Anders (thomas.anders at b
Thomas was working on this but his proposed patch did not work. This one does.--chrisBegin forwarded message:From: "SourceForge.net" <[EMAIL PROTECTED]>Date: 27 September 2006 8:19:55 PM PDTTo: [EMAIL PROTECTED]Subject: [ net-snmp-Patches-1566777 ] Patch for memory_darwin.c Patch
some minor code problems. I have posted 5 patches chris> (so far) to sourceforge to address the compilation issues I was chris> experiencing. Thanks for submitting them. Unfortunately, they won't make it into 5.3.1 but they should for 5.3.2.That's cool. Thanks. chris> I have a
>>>>> On Mon, 10 Jul 2006 18:47:58 -0700, chris jalbert <[EMAIL PROTECTED]>
>>>>> said:
chris> Hey there. My team is now responsible for maintaining Net-SNMP
chris> here at Apple. While trying to port 5.3.0.1 to OS X, I have
chris> encountered some
Hey there. My team is now responsible for maintaining Net-SNMP here at Apple. While trying to port 5.3.0.1 to OS X, I have encountered some minor code problems. I have posted 5 patches (so far) to sourceforge to address the compilation issues I was experiencing.I have a couple of other patches
Wes Hardaker wrote:
> The following is a patch to the perl build process. The question is,
> does it go in before 5.3.1 so it's in 5.3.1, or after 5.3.1 but before
> publishing to CPAN?
It has been committed already which I'm fine with, at least after the
env var for the override had been changed
The following is a patch to the perl build process. The question is,
does it go in before 5.3.1 so it's in 5.3.1, or after 5.3.1 but before
publishing to CPAN?
--
Wes Hardaker
Sparta, Inc.
Index: Makefile.subs.pl
===
RCS file: /cvs
1 - 100 of 146 matches
Mail list logo
