On Sun, 17 Oct 2004 12:33:21 -0400 [EMAIL PROTECTED] wrote: SN> > > #-#-#-#-#-#-#-# SN> > > net-snmp-5.0.8-readonly.patch SN> > > This change to netsnmp_wrap_up_request fixing a problem with SN> > > processing RO vs RW objects (I'm not sure) was applied in a different SN> > > source location. SN> > SN> > I've reviewed the latest code in snmp_agent.c and can't find a place SN> > where you fix this somewhere else. Could you please be a little more SN> > specific so i can verify that our patch is obsolete? SN> SN> I"m sorry to be lame on this. Dave/Robert/Wes would know more about SN> recent (18 months) read-only MIB object changes.
Is there a test-case for the original problem? Even I can't keep up with the implications of every change since 5.0.8. SN> [SNIP] SN> > > #-#-#-#-#-#-#-# SN> > > net-snmp-5.1.1-ipAdEntIfIndex.patch SN> > > Will adding struct in_ifaddr break compiles on RedHat 7.2 ? SN> > > SN> > SN> > See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119106 SN> > It's not about breaking compiles, it's about a real bug that the IfIndex SN> > on Linux sometimes is wrong. SN> SN> Coders, would this conflict with recent changes made to the main branch ? SN> If not, I for one would think it appropriate to apply to the 5.1 and main SN> branches. It looks good for 5.1.x (I just applied it), but a different fix will be in 5.2.x. It will fix the problem of ifIndex inconsistency. 5.2 has a different fix because it addresses the problem of changing ifIndexes as interfaces are added or deleted. SN> > > #-#-#-#-#-#-#-# SN> > > net-snmp-5.1.1-pie.patch SN> > [SNIP] it SN> > actually stands for Position Independant Executable. Basically the SN> > counterpart to -pic but for binaries instead of for libraries. This is SN> > required for newer releases for exec-shield to work properly, which is a SN> > security feature (makes buffer overflows much harder to exploit). SN> SN> My ignorance tells me this may have unseen problems for other platforms. Right. There should be a configure test of some sort for this. SN> > > #-#-#-#-#-#-#-# SN> > > net-snmp-5.1-bsdcompat.patch SN> > > Removing SO_BSDCOMPAT should be done in both places used. SN> > > Patch does not address the code in snmpUDPIPv6Domain.c SN> SN> memshared and bsdcompat were addressed in an improperly applied SN> patch, since removed. Coders, I would like comments on re-forming the SN> patch. For 5.1.x and 5.2.x, I think a band-aid of a uname call and kernel check is probably the way to go. If we wan't to come up with a more generalized api for 5.3 and beyond, that can be discussed on coders (after we get 5.2 out, please!). SN> > > #-#-#-#-#-#-#-# SN> > > net-snmp-5.1.2-lelf.patch SN> > > We will need to make this elf test "if not Linux" SN> > SN> > Again as you say fairly Linux/Red Hat specific. IIRC the test just SN> > produces a wrong/unecessary result on our distro so it was removed. There were lots of problems with libelf, starting around RH 8, I believe. It seemed that a particular symlink was only installed if certain devel RPMs were installed. In Fedora, this problem extends to a few other libraries too (bz, selinux). It would be nice if we could figure out how to fix these too. SN> > > #-#-#-#-#-#-#-# SN> > > net-snmp-5.1-64bit.patch SN> > > Interesting that some of the changes are HPUX11 specific... SN> > > What is the origin of this patch? SN> > SN> > That patch originally came from AMD. They verified that these fixes were SN> > needed for their new AMD64 boxes. IIRC this is the 3rd revision of the SN> > patch, so it has been around for quite some time now in our rpms. SN> SN> Coders, comments, please. Looks good to me. The change of a long from 4 to 8 bytes is the root cause here, and I'm sure there are many many more instances of this problem lurking about. SN> > > #-#-#-#-#-#-#-# SN> > > net-snmp-5.1-async-getnext.patch SN> > > Do you have a test for this Perl module patch ? SN> > SN> > Again a patch from Kaj J. Niemi: SN> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=111479 SN> > SN> > He didn't provide a test though, but i generally trust his patches and SN> > fixes. SN> SN> Coders, would this have a positive effect if applied ? Reading the bug report, it looks appropriate. -- Robert Story; NET-SNMP Junkie <http://www.net-snmp.org/> <irc://irc.freenode.net/#net-snmp> Archive: <http://sourceforge.net/mailarchive/forum.php?forum=net-snmp-coders> You are lost in a twisty maze of little standards, all different. ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Net-snmp-coders mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
