[EMAIL PROTECTED] wrote:
>> Assumed we succeed in improving configure this way: are there any
>> objectionsagainst turning on embedded perl by default in 5.4?
>
> We use Net-SNMP in an embedded system. I wouldn't want the default
> build to grow any. (I'll keep my religious aversion to Perl to
> ...
> Assumed we succeed in improving configure this way: are there any
> objectionsagainst turning on embedded perl by default in 5.4?
We use Net-SNMP in an embedded system. I wouldn't want the default
build to grow any. (I'll keep my religious aversion to Perl to myself.)
-
-Coders,
we've been discussing (and adding) warnings for 5.3 back then, e.g. the
configure warning for disman/event-mib vs. disman/event and the "deprecated"
warning for exec.
Are there proposals for adding/removing similar warnings in 5.4?
Are there any legacy features waiting to be deprecated?
Robert Story wrote:
> On Wed, 16 Aug 2006 00:23:07 +0200 Thomas wrote:
> TA> Hmmh, I actually prefer your original net-snmp-config-internal.h proposal
> TA> since it's much more clear what to expect from this file, then. I'd be
> TA> reluctant about re-using the old config.h name for something not
On Wed, 16 Aug 2006 00:23:07 +0200 Thomas wrote:
TA> Robert Story wrote:
TA> > I'd propose going back to the original 'config.h' for the 'internal' file
TA> > name.
TA>
TA> Hmmh, I actually prefer your original net-snmp-config-internal.h proposal
TA> since it's much more clear what to expect from
Robert Story wrote:
> On Tue, 15 Aug 2006 10:31:23 +0200 Thomas wrote:
> TA> Dave Shield wrote:
> TA> > One thing I've wondered about for a long time would be the ability to
> TA> > re-specify the list of MIB modules to include *without* having to
> TA> > rerun the rest of the configure tests. (An
-Coders,
I'm interested to see embedded perl turned on by default in future releases from
5.4 onwards. I realize there are a number of configure checks to be
added/improved to avoid breaking the build for too many people (which I think is
the major argument for *not* turning it on):
- turn "#er
Robert Story wrote:
> On Wed, 16 Aug 2006 00:01:33 +0200 Thomas wrote:
> TA> Another proposal that came up on IRC was to split net-snmp-config.h into
> an
> TA> external and an internal header file (with the PACKAGE_* variables being
> TA> in the internal one, of course).
>
> I would like to see
On Wed, 16 Aug 2006 00:01:33 +0200 Thomas wrote:
TA> Another proposal that came up on IRC was to split net-snmp-config.h into an
TA> external and an internal header file (with the PACKAGE_* variables being
TA> in the internal one, of course).
I would like to see this resolved as well, and think th
On Tue, 15 Aug 2006 17:17:44 +0200 Thomas wrote:
TA> However, at the end, net-snmp.spec has *not* been kept in the patches
TA> branches, but only in MAIN. How to properly handle the differences
TA> between the different branches in this situation? Will "%if" contructs
TA> for the various branches i
-Coders,
net-snmp-config.h currently contains a number of problematic variables like all
the PACKAGE_* that shouldn't be defined in an external header file because it
may easily interfere with the PACKAGE_* variables (even if internal) of another
package that's using net-snmp. I'd really like to g
Wes Hardaker wrote:
> Robert> So, what I proposed is that we leave a little wiggle room in
> Robert> the versioning. Can't do much about 5.1 and 5.2 - they are
> Robert> already sandwiched (well, 5.1 isn't yet, but it's about to
> Robert> me. More on that in a sec). But we can make room for 5.3. I
I’m trying to use the proxy feature to implement the
DS1-MIB (located at SNMPv2-SMI::transmission.18). I just added a line like
“
proxy -v2c -c public 192.168.1.1 .1.3.6.1.2.1.10.18”
to snmpd.conf. It basically works, but there’s one problem. If
I walk the MIB, the get-next responses sk
Thomas Anders wrote:
> Wes Hardaker wrote:
>> Sounds like everyone actually agrees without arguments or objections.
>> I'm now scared.
>
> Looks like we've agreed "in principle", but we still have to decide the
> little details (like what *exactly* should be kept in "dist" for the
> source distrib
On 15/08/06, Thomas Anders <[EMAIL PROTECTED]> wrote:
> Either these changes or the ones you did earlier today broke my nightly
> MAIN builds for Linux/x86. Linking now fails with:
>
> ./.libs/libnetsnmpmibs.so: undefined reference to `linux_read_icmp_stat'
> ./.libs/libnetsnmpmibs.so: undefined re
On Tue, 15 Aug 2006 10:31:23 +0200 Thomas wrote:
TA> Dave Shield wrote:
TA> > One thing I've wondered about for a long time would be the ability to
TA> > re-specify the list of MIB modules to include *without* having to
TA> > rerun the rest of the configure tests. (And then re-compiling
TA> > shou
Dave Shield wrote:
> On 14/08/06, Wes Hardaker <[EMAIL PROTECTED]> wrote:
>> configure now reads the list of modules to start with from
>> agent/mibgroup/default_modules.h.
>
> Sounds great.
>
>> Feedback appreciated. (more configure changes likely coming soon as well)
>
> Care to give us a hin
Wes Hardaker wrote:
> Update of /cvsroot/net-snmp/net-snmp
> In directory sc8-pr-cvs7.sourceforge.net:/tmp/cvs-serv20915
>
> Modified Files:
> acinclude.m4 configure configure.in
> Log Message:
> - Cleaned up the debugging code for the module section
> - Added a AC_MSG_MODULE_DBG macro to
On 14/08/06, Wes Hardaker <[EMAIL PROTECTED]> wrote:
> configure now reads the list of modules to start with from
> agent/mibgroup/default_modules.h.
Sounds great.
> Feedback appreciated. (more configure changes likely coming soon as well)
Care to give us a hint of what might be on the horizon?
19 matches
Mail list logo
