On 10/10/06, Thomas Anders <[EMAIL PROTECTED]> wrote:
> > 1) OpenBSD4 headers
> Huh? We neither have openbsd3.h nor openbsd4.h, but just openbsd.h.
OK - in that case, I don't understand the comment
"openbsd4 uses openbsd.h, and thus a lot of openbsd3 code
that most likely works on openbsd4 is excluded"
I'd assumed this was referring to a file openbsd3.h. Clearly not.
Can someone please clarify the precise issue here.
> I think we should come to a consensus whether foobar42 means "foobar, version
> 42" or "foobar, version 42 or above". We currently use it either way, I think.
That would be useful, certainly. But I'm not convinced that this is
the correct time in the development cycle to have that discussion.
Including any such changes in the 5.4 release feels a bit rushed, so
it would make more sense (IMO) to get 5.4 out first, and then address
this issue properly - ready for 5.5
> > 4) DisMan event crash
> > I'll look at this as soon as I get a free minute
>
> Thanks.
I've now looked at the bug report, and remembered what the problem is.
It's the long-established clash between master-agent-initiated traffic
(SNMP requests) and subagent-initiated traffic (notifications) sharing
a single transport session, and triggering race conditions.
Yes - this is a problem that needs to be addressed. But it's not
going to be simple, so I don't think it's feasible to hold up 5.4
waiting for a workable solution.
I propose this be moved to "light-yellow" status.
> > 5) 64bit nlist
>
> I'm currently working on it and hope to finish it up before rc1.
OK - if you think you can get this working fairly quickly, we look
forward to seeing it.
> > 7) perl compiler warnings
> > If they're simply warnings (rather than errors), then leave till
> > 5.4.1
> > Unless they actually indicate a more serious problem?
>
> Compiler warnings often point to serious programming errors. Classifying them
> as
> harmless or serious is only possible *after* investigation, so this keeps
> being
> a grey area for now.
Is there a list of the warnings logged somewhere?
> > 8) "as-needed" linking
>
> OSX is the only one that fails during "make".
That's the "library layering" bug report, I presume? (Which I
responded to earlier today)
Naive question - does static vs dynamic linking make any difference here?
Requiring static linking obviously isn't ideal, but would be a
workable stop-gap.
> On the other
> (older) systems
> problems probably only happen when doing "make install
> DESTDIR=/some/where/else".
Which is a relatively unusual invocation.
Yes - it needs to be fixed properly, but doesn't feel to be a show-stopper.
> > 9) OS X embedded perl
> Shall we hold off enabling embedded perl by default on OSX?
If it doesn't work, then yes! :-)
> > R1) TCP notifications
> I think it should get sorted out for 5.4 before we're tied to backward compat
> problems.
Juergen has responded on this issue, and offered several alternative
routes forward. I need to examine things in more detail before I'm
prepared to comment on which I'd prefer. I would welcome comments
from others who understand the recent changes better than I.
Dave
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
