Bug#441200: libconfig name clash
users of the library and is likely to result > in ongoing confusion. > > 14. Renaming the newer library in Debian might benefit projects and > sites which use the name `libconfig' for internal libraries; it is > hard to know how many such projects there are and we might not be > aware of any clashes. A quick search shows that a piece of > software called `libpqxx' renamed an internal header it called > `libconfig.h' probably for this reason. > > 12. Neither library has a particularly good claim to this name. > > 13. The existing library's author has failed on many of the counts of > good practice. Debian policy documents discuss namespace > conflicts in the context of command names, which while not > directly on point ought to have alerted the library's author to > the potential problem. The library is extremely parochial and so > needs an especially distinctive name. Obviously the existing > library came first but even a cursory web search at the time would > probably have revealed prior private uses elsewhere which would be > at least as interesting. The steward of the existing library > seems to have been largely oblivious to the problem and has not > made a concerted effort to defend the name. > > 14. The newer library's authors have also failed but not so > seriously. As a standalone project they do not have the benefit > of our policy documentation to guide them away from these kind of > problems. Their library is intended to be of general > applicability and interest, which mitigates the poor choice of > name. There is no evidence that the authors did a web search for > the name; if they had done they would have found a few internal > libraries and probably the existing library in Debian. > > Conclusions > > 15. All of the factors - particularly the parochial nature of the > existing library - suggest that the existing library has very > little basis for keeping the name. > > 16. Whether the newer library should be allowed to complete this > namespace landgrab is less clear. Convenience would suggest yes, > whereas propriety would suggest no. > > 17. I would err on the side of propriety. > > Choice of replacement names > > 18. The new name (if any) chosen by the existing library should > ideally contain the name of the author, their site, or some > similar parochial identifier. > > 19. The new name for the newer library should include something which > will distinguish it from other libraries suitable for > configuration. > > 20. It is necessary to ensure that the chosen new names do not > themselves cause problems. We would like to avoid a heavyweight > procedure for approving the new names but have an opportunity to > stop the use of an inappropriate name. The proposed name > `libconfig1' for the newer library is not appropriate. > > Decision > > 21. I would therefore rule as follows: > > -8<- > > (1) The existing libconfig must be renamed or removed. > (2) The newer library may not use the name libconfig either. > (3) Each maintainer is invited to suggest one or more new > name(s), within 14 days of this resolution. > (4) If after that no member of the TC objects to a name within 7 > days (counted from the maintainer's suggestion), then the > package is entitled to the name. > (5) Even if a TC member objects, if the TC does not pass > a resolution vetoing the new name within 28 days, the > package is likewise entitled to the new name. > (6) This applies to both packages; it applies to library > names, filenames, package names, and the like. > (7) Suggestions and objections are to be sent to this bug. > > -8<- > > Ian. > -- Regards Abraham ___ Abraham vd Merwe - The Debian Project 1st Floor, Albion Springs, 183 Main Road, Newlands Phone: +27 21 689 3867 Cell: +27 82 565 4451 Http: http://people.debian.org/~abz/ Email: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#438683: ITP: libconfig -- simple library for manipulating structured configuration files
Hi Julien>@2007.08.20_13:38:49_+0200 > At 1187477920 time_t, Julien Danjou wrote: > > Package: wnpp > > Severity: wishlist > > Owner: Julien Danjou <[EMAIL PROTECTED]> > > > > * Package name: libconfig > > Version : 1.1.3 > > Upstream Author : Mark Lindner > > * URL : http://www.hyperrealm.com/libconfig/libconfig.html > > * License : LGPL > > Programming Lang: C, C++ > > Description : simple library for manipulating structured > > configuration files > > > > > > libconfig is a simple library for manipulating structured configuration > > files. The file format is more compact and more readable than XML. And > > unlike XML, it is type-aware, so it is not necessary to do string > > parsing in application code. > > The library includes bindings for both the C and C++ languages. It works > > on POSIX-compliant UNIX systems (GNU/Linux, Mac OS X, Solaris, FreeBSD) > > and Windows (2000, XP and later). > > > > > > Currently there's already a libconfig in Debian, that seems unmaintained > > and not used. > > > > I don't know yet what I'm going to do ; maybe ask the maintainers if he > > thinks we can remove it. > > Do you think libconfig is still useful in Debian? > It does not seem to be used nor really developed. > Can we ask it for removal and replace it with a new libconfig, see above? No, please don't. It is still used by some of my programs and a few people and I've recently written a new version which I'm about to upload. -- Regards Abraham ___ Abraham vd Merwe - The Debian Project 1st Floor, Albion Springs, 183 Main Road, Newlands Phone: +27 21 689 3867 Cell: +27 82 565 4451 Http: http://people.debian.org/~abz/ Email: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#429699: ftm depends on a development library
Hi Uwe >@2007.06.19_17:29:59_+0200 Good question. I must've stuffed up - will fix it (: > Package: ftm > Version: 0.0.8 > Severity: normal > > Why does ftm depend on a development version of a library? > > # dpkg -s ftm > Package: ftm > Version: 0.0.8 > Depends: libabz0 (>= 0.6.2), libc6 (>= 2.3.6-6), libdebug0 (>= 0.4.2), > libncurses5 (>= 5.4-5), libabz0-dev (>= 0.7.2) > > Also depending on different versions of libabz0 (>= 0.6.2) > and libabz0-dev (>= 0.7.2) does not look very consistent. > > Uwe > > > -- System Information: > Debian Release: 4.0 > APT prefers stable > APT policy: (850, 'stable'), (750, 'testing'), (650, 'unstable') > Architecture: i386 (i686) > Shell: /bin/sh linked to /bin/bash > Kernel: Linux 2.6.18-4-k7 > Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) > > Versions of packages ftm depends on: > ii libabz0 0.7.2Miscellaneous useful routines > ii libabz0-dev 0.7.2Development files for the abz > libr > ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries > ii libdebug0 0.4.2Memory leak detection system and > l > ii libncurses5 5.5-5Shared libraries for terminal > hand > > ftm recommends no packages. > > -- no debconf information > -- Regards Abraham ___ Abraham vd Merwe - The Debian Project 1st Floor, Albion Springs, 183 Main Road, Newlands Phone: +27 21 689 3867 Cell: +27 82 565 4451 Http: http://people.debian.org/~abz/ Email: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#416039: hexcat - FTBFS: Unable to recognise the format of the input file `debian/hexcat/usr/bin/hexcat'
Hi Martin>@2007.05.16_17:21:26_+0200 > * Abraham vd Merwe <[EMAIL PROTECTED]> [2007-05-16 17:15]: > > > Yes, the upstream tar ball contains a PowerPC binary, so make doesn't > > > do anything and the powerpc is used. > > > > > dpkg-source: extracting hexcat in hexcat-0.0.3 > > > > There is no executable in the hexcat source package if I use ftp.debian.org > > nor is there in the package I uploaded. > > The latest release in unstable is 0.0.3.1. It appears Anthony Towns > did a NMU and fucked something up. Ah, ok - I'll see what he did, fix and upload a new version now. Thanks for the help. -- Regards Abraham ___ Abraham vd Merwe - The Debian Project 1st Floor, Albion Springs, 183 Main Road, Newlands Phone: +27 21 689 3867 Cell: +27 82 565 4451 Http: http://people.debian.org/~abz/ Email: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#416039: hexcat - FTBFS: Unable to recognise the format of the input file `debian/hexcat/usr/bin/hexcat'
Hi Martin>@2007.05.16_12:56:20_+0200 > * Abraham vd Merwe <[EMAIL PROTECTED]> [2007-05-16 12:41]: > > Can you please elaborate? The statement above is not true (i.e. it doesn't > > ship with a PowerPC binary - I do not even have access to a PowerPC > > platform). > > Yes, the upstream tar ball contains a PowerPC binary, so make doesn't > do anything and the powerpc is used. > > > (sid)23897:[EMAIL PROTECTED]: ~/src] apt-get source hexcat > Reading package lists... Done > Building dependency tree... Done > Need to get 18.1kB of source archives. > Get:1 http://ftp.osuosl.org sid/main hexcat 0.0.3.1 (dsc) [457B] > Get:2 http://ftp.osuosl.org sid/main hexcat 0.0.3.1 (tar) [17.6kB] > Fetched 18.1kB in 0s (35.8kB/s) > gpg: Signature made Mon 12 Mar 2007 06:58:39 AM UTC using DSA key ID 2A4E3EAA > gpg: Can't check signature: public key not found > dpkg-source: extracting hexcat in hexcat-0.0.3.1 > dpkg-source: unpacking hexcat_0.0.3.1.tar.gz > (sid)23898:[EMAIL PROTECTED]: ~/src] file hexcat-0.0.3.1/src/hexcat > hexcat-0.0.3.1/src/hexcat: ELF 32-bit MSB executable, PowerPC or cisco 4500, > version 1 (SYSV), for GNU/Linux 2.4.1, dynamically linked (uses shared libs), > stripped > (sid)23899:[EMAIL PROTECTED]: ~/src] < snip <--< snip <--< snip < [EMAIL PROTECTED]:~/c++/released/public/hexcat/old# grep deb-src /etc/apt/sources.list deb-src ftp://ftp.debian.org/debian testing main non-free contrib [EMAIL PROTECTED]:~/c++/released/public/hexcat/old# apt-get source hexcat Reading Package Lists... Done Building Dependency Tree... Done Need to get 14.6kB of source archives. Get:1 ftp://ftp.debian.org testing/main hexcat 0.0.3 (dsc) [487B] Get:2 ftp://ftp.debian.org testing/main hexcat 0.0.3 (tar) [14.1kB] Fetched 14.6kB in 5s (2477B/s) dpkg-source: extracting hexcat in hexcat-0.0.3 dpkg-source: unpacking hexcat_0.0.3.tar.gz [EMAIL PROTECTED]:~/c++/released/public/hexcat/old# tar ztvf hexcat_0.0.3.tar.gz | grep hexcat$ [EMAIL PROTECTED]:~/c++/released/public/hexcat/old# file hexcat-0.0.3/src/hexcat hexcat-0.0.3/src/hexcat: cannot open (hexcat-0.0.3/src/hexcat) [EMAIL PROTECTED]:~/c++/released/public/hexcat/old# < snip <--< snip <--< snip < There is no executable in the hexcat source package if I use ftp.debian.org nor is there in the package I uploaded. -- Regards Abraham ___ Abraham vd Merwe - The Debian Project 1st Floor, Albion Springs, 183 Main Road, Newlands Phone: +27 21 689 3867 Cell: +27 82 565 4451 Http: http://people.debian.org/~abz/ Email: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#416039: hexcat - FTBFS: Unable to recognise the format of the input file `debian/hexcat/usr/bin/hexcat'
Hi Martin>@2007.05.16_11:30:22_+0200 > * Bastian Blank <[EMAIL PROTECTED]> [2007-03-24 11:13]: > > Package: hexcat > > > > strip --remove-section=.comment --remove-section=.note > > > debian/hexcat/usr/bin/hexcat > > > strip: Unable to recognise the format of the input file > > > `debian/hexcat/usr/bin/hexcat' > > > dh_strip: command returned error code 256 > > hexcat ships with a powerpc binary that is used (rather than > compiled)... Abraham, can you please fix this? Can you please elaborate? The statement above is not true (i.e. it doesn't ship with a PowerPC binary - I do not even have access to a PowerPC platform). -- Regards Abraham ___ Abraham vd Merwe - The Debian Project 1st Floor, Albion Springs, 183 Main Road, Newlands Phone: +27 21 689 3867 Cell: +27 82 565 4451 Http: http://people.debian.org/~abz/ Email: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#388209: Status of the orca and tinysnmp packages ?
Hi Regis >@2007.04.18_00:37:28_+0200 > The orca package was last uploaded in July 2004 (same age as the latest > upstream release), has 5 RC bugs open against it, needs to be ported to > the new rrd and tinysnmp APIs since 2 years ago. Is this package still > active upstream and maintained ? Or should we request for its removal ? > > Same goes for tinysnmp, with the same maintainer (also upstream), last > uploaded 2 years ago, 4 RC bugs, never in a stable release. > > CC'ing QA, the maintainer might actually be MIA... Both packages are still in use, but I'm not actively maintaining/developing either anymore. orca is definitely obsolete and should be removed. Tinysnmp should stay. There is nothing really wrong with it and most, if not all of the RC bugs has to do with orca. -- Regards Abraham ___________ Abraham vd Merwe - The Debian Project 1st Floor, Albion Springs, 183 Main Road, Newlands Phone: +27 21 689 3867 Cell: +27 82 565 4451 Http: http://people.debian.org/~abz/ Email: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#388256: tinysnmp-agent: SIGBUS on sparc at startup
Hi Niko >@2006.09.19_13:36:02_+0200 Thanks for the help. Can you send me your patch with the memmove()'s and I'll have a look at it? > Package: tinysnmp-agent > Version: 0.8.4 > Severity: grave > Justification: renders package unusable > > This is the same as #282260, but as that's already archived, I'm opening > a new bug. > > The tinysnmpd daemon still doesn't start on sparc but gives a SIGBUS > instead. This is with a recompiled (with -O0, as is the default on sparc) > package due to #385881. > > The stack trace with symbols is the same as in #282260: > > (gdb) run -l debug /etc/tinysnmp.conf /usr/lib/tinysnmp > Starting program: /home/niko/src/tinysnmp-0.8.4+debug/agent/tinysnmpd -l > debug /etc/tinysnmp.conf /usr/lib/tinysnmp > VERBOSE: log.c:603: Starting to log output. > VERBOSE: module.c:185: registered module system > VERBOSE: module.c:185: registered module snmp > > Program received signal SIGBUS, Bus error. > 0x00017838 in tree_create (type=VALUE, node=0xef897010) at odb.c:148 > 148odb->data.value = node->value; > (gdb) bt > #0 0x00017838 in tree_create (type=VALUE, node=0xef897010) at odb.c:148 > #1 0x00017b38 in tree_add (odb=0x2e414, node=0xef897010) at odb.c:215 > #2 0x00017a14 in tree_add_child (odb=0x2e3b4, node=0xef897110) at odb.c:188 > #3 0x00017be0 in tree_add (odb=0x2e3b4, node=0xef897110) at odb.c:223 > #4 0x00017a14 in tree_add_child (odb=0x2e354, node=0xef897210) at odb.c:188 > #5 0x00017be0 in tree_add (odb=0x2e354, node=0xef897210) at odb.c:223 > #6 0x00017a14 in tree_add_child (odb=0x2e2f4, node=0xef897310) at odb.c:188 > #7 0x00017be0 in tree_add (odb=0x2e2f4, node=0xef897310) at odb.c:223 > #8 0x00017a14 in tree_add_child (odb=0x2e294, node=0xef897410) at odb.c:188 > #9 0x00017be0 in tree_add (odb=0x2e294, node=0xef897410) at odb.c:223 > #10 0x00017a14 in tree_add_child (odb=0x2e234, node=0xef897510) at odb.c:188 > #11 0x00017be0 in tree_add (odb=0x2e234, node=0xef897510) at odb.c:223 > #12 0x00017a14 in tree_add_child (odb=0x2e1d4, node=0xef897610) at odb.c:188 > #13 0x00017be0 in tree_add (odb=0x2e1d4, node=0xef897610) at odb.c:223 > #14 0x00017a14 in tree_add_child (odb=0x2e14c, node=0xef897710) at odb.c:188 > #15 0x00017be0 in tree_add (odb=0x2e14c, node=0xef897710) at odb.c:223 > #16 0x00017a14 in tree_add_child (odb=0x2e0ec, node=0xef897810) at odb.c:188 > #17 0x00017be0 in tree_add (odb=0x2e0ec, node=0xef897810) at odb.c:223 > #18 0x00017a14 in tree_add_child (odb=0x2e0b4, node=0xef897910) at odb.c:188 > #19 0x00017be0 in tree_add (odb=0x2e0b4, node=0xef897910) at odb.c:223 > #20 0x00017a14 in tree_add_child (odb=0x2d744, node=0xef897a10) at odb.c:188 > #21 0x00017be0 in tree_add (odb=0x2d744, node=0xef897a10) at odb.c:223 > #22 0x00017de4 in odb_add (odb=0x2d744, oid=0x2d758, value=0xef897a98) at > odb.c:266 > #23 0x0001a260 in module_extend (oid=0x1c13c, descr=0x1c158 "The MIB module > for SNMP entities") > at module-system.c:369 > #24 0x000142c8 in module_open (path=0xef897df6 "/usr/lib/tinysnmp") at > module.c:247 > #25 0x0001a89c in main (argc=5, argv=0xef897cc4) at main.c:184 > > The problem seems to be data alignment: > > (gdb) print &(odb->data.value) > $1 = (snmp_value_t *) 0x2e45c > > which is not word-aligned. > > FWIW, I had some success working around this by replacing the assignment > with memmove(). This led to other similar bus errors surfacing from > either assignments or memcpy() calls, which I also replaced. I did get > tinysnmpd to apparently work this way. I don't think it's the right > solution, though, but more like a side effect of memmove() copying the > data byte-by-byte or something like that. > > -- System Information: > Debian Release: testing/unstable > APT prefers testing > APT policy: (500, 'testing') > Architecture: sparc (sparc64) > Shell: /bin/sh linked to /bin/bash > Kernel: Linux 2.6.15-1-sparc64 > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > > Versions of packages tinysnmp-agent depends on: > Ii libabz0 0.6.3 Miscellaneous useful routines > ii libber0 0.4.1 A Basic Encoding Rules (ITU > X.690) > ii libc62.3.6.ds1-4 GNU C Library: Shared libraries > ii libdebug00.4.2 Memory leak detection system and > l > ii libevent11.1a-1 An asynchronous event > notification > > Versions of packages tinysnmp-agent recommends: > pn tinysnmp-module-interfaces (no description available) > pn tinysnmp-module-resources (no description ava
Bug#385881: tinysnmp-agent: does not start due to libabz0 ABI change
Hi Steve >@2006.09.03_23:26:54_+0200 > reassign 385881 libabz0 > found 385881 0.6.3 > thanks > > On Sun, Sep 03, 2006 at 08:45:26PM +0300, Niko Tyni wrote: > > starting tinysnmp-agent currently fails on current sid with: > > > # /etc/init.d/tinysnmp-agent start > > Starting router-monitoring daemon: tinysnmpd/usr/sbin/tinysnmpd: symbol > > lookup error: /usr/sbin/tinysnmpd: undefined symbol: tokens_parse > > . > > > This happens because of this change in libabz0 0.6.3: > > > In my understanding, the right fix is to either revert the change > > in libabz or to bump its soname and recompile tinysnmp (and other > > reverse-depends as well.) > > Correct, and therefore reassigned to libabz0. > > (And why is libabz a native package?) Because I wrote it? -- Regards Abraham ___ Abraham vd Merwe - The Debian Project 1st Floor, Albion Springs, 183 Main Road, Newlands Phone: +27 21 689 3867 Cell: +27 82 565 4451 Http: http://people.debian.org/~abz/ Email: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#381034: orca: Missing dependency librrd0
Hi Petter>@2006.08.01_18:08:04_+0200 > Package: orca > Severity: serious > > When trying to install orca in the current unstable distribution, it > fail to install because it have a versioned depend on the virtual > package librrd0. It seem rrdtool providing librrd0 changed, and the > orca package didn't get updated to match the change. A quick search > show that librrd2 is the current library version. > > The last orca upload was 2004-07-19. rrdtool switched from librrd0 to > librrd2 with the upload 2005-08-14. This make me suspect the package > maintainer Abraham vd Merwe is missing or inactive. Just out of interest, I am still here and still keen to maintain all of these packages (you'll see that I do upload packages occassionally), but I'm just very busy right now. Unfortunately it doesn't really make sense to hand over these packages to somebody else either as I wrote all of this and the maintainer are likely to get frustrated with me. With regards to orca, I am actually busy with a complete rewrite, so this will get fixed one day... -- Regards Abraham _______ Abraham vd Merwe - The Debian Project 1st Floor, Albion Springs, 183 Main Road, Newlands Phone: +27 21 689 3867 Cell: +27 82 565 4451 Http: http://people.debian.org/~abz/ Email: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#333915: Unsatisfiable build dep on librrd0-dev
Hi Luk >@2005.10.14_14:10:42_+0200 I don't think so. librrd2 is not backwards compatible to librrd0, so it is not as simple as updating the build dependency. Also, librrd0-dev is still in Debian for that very reason. If you don't have any objection to this, I'm going to close the bug. > Package: orca > Severity: serious > Version: 0.2.3 > > Hi > > Please update your build dependency on librrd0-dev to librrd2-dev > > Cheers > > Luk -- Regards Abraham ___________ Abraham vd Merwe - The Debian Project 1st Floor, Albion Springs, 183 Main Road, Newlands Phone: +27 21 689 3876 Cell: +27 82 565 4451 Http: http://people.debian.org/~abz/ Email: [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#327610: libabz: FTBFS: iptables.h:49: error: 'iptables_add' aliased to external symbol 'batch_add'
Hi Kurt >@2005.09.11_13:27:25_+0200 On what architecture/platform is this? The undefined symbols are from another module compiled before iptables.o. Please check if there were any errors/warnings while building batch.o. > Package: libabz > Version: 0.6.1 > Severity: serious > > Hi, > > Your package is failing to build with the following error: > gcc -Wall -Wno-trigraphs -Os -pipe -fno-strict-aliasing -fno-common -fPIC > -I/usr/local/include -I../include -DGETHOSTBYNAME -DGETSERVBYNAME -c -o > iptables.o iptables.c > ../include/abz/iptables.h:49: error: 'iptables_add' aliased to external > symbol 'batch_add' > ../include/abz/iptables.h:58: error: 'iptables_append' aliased to undefined > symbol 'batch_append' > ../include/abz/iptables.h:64: error: 'iptables_destroy' aliased to undefined > symbol 'batch_destroy' > make[3]: *** [iptables.o] Error 1 -- Regards Abraham ___ Abraham vd Merwe - The Debian Project 1st Floor, Albion Springs, 183 Main Road, Newlands Phone: +27 21 689 3876 Cell: +27 82 565 4451 Http: http://people.debian.org/~abz/ Email: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#293143: tinysnmp-agent crashes with signal 15
Hi Jacco >@2005.02.01_14:51:51_+0200 Could you please send me the output of the following: snmpwalk -cpublic -v1 192.168.1.254 (i.e. walk the tree of that router using net-snmp's snmpwalk) Also, could you please tell me on which ObjectID it dies? Also, if possible, could you run tinysnmpd in the foreground while doing the tinysnmpwalk command. As follows: /usr/sbin/tinysnmpd -f crash.log -l noisy /etc/tinysnmp.conf /usr/lib/tinysnmp Then when it crashes, send me the crash.log file. Thanks > Package: tinysnmp-agent > Version: 0.8.3 > > Whenever i try to walk the snmp-tree with 'tinysnmpwalk 192.168.1.254 > public' i get a timeout and the tinysnmp-agent daemon (tinysnmpd) gives > the following log-info: > > > Feb 1 13:37:13 localhost tinysnmpd[5634]: caught signal 15 > Feb 1 13:37:13 localhost tinysnmpd[5634]: Memory Leak Detection System > Feb 1 13:37:13 localhost tinysnmpd[5634]: > Feb 1 13:37:13 localhost tinysnmpd[5634]: Attempted to free an > unallocated pointer: 0x2 > Feb 1 13:37:13 localhost tinysnmpd[5634]: > Feb 1 13:37:13 localhost tinysnmpd[5634]: Discovered in file > "network.c" at line 297 in function network_close() > Feb 1 13:37:13 localhost tinysnmpd[5634]: Memory Leak Detection System > Feb 1 13:37:13 localhost tinysnmpd[5634]: > Feb 1 13:37:13 localhost tinysnmpd[5634]: Attempted to free an > unallocated pointer: 0x2 > Feb 1 13:37:13 localhost tinysnmpd[5634]: > Feb 1 13:37:13 localhost tinysnmpd[5634]: Discovered in file > "network.c" at line 297 in function network_close() > Feb 1 13:37:13 localhost tinysnmpd[5634]: Memory Leak Detection System > Feb 1 13:37:13 localhost tinysnmpd[5634]: > Feb 1 13:37:13 localhost tinysnmpd[5634]: Unfreed pointer: 0x805b5ac > Feb 1 13:37:13 localhost tinysnmpd[5634]:Allocated in file > "network.c" at line 233 in function network_open() > Feb 1 13:37:13 localhost tinysnmpd[5634]: Stopped logging output. > Feb 1 13:37:14 localhost tinysnmpd[16425]: Starting to log output. > Feb 1 13:37:14 localhost tinysnmpd[16425]: registered module system > Feb 1 13:37:14 localhost tinysnmpd[16425]: registered module snmp > Feb 1 13:37:14 localhost tinysnmpd[16425]: registered module interfaces > Feb 1 13:37:14 localhost tinysnmpd[16425]: registered module dvb > Feb 1 13:37:14 localhost tinysnmpd[16425]: registered module resources > Feb 1 13:37:14 localhost tinysnmpd[16425]: listening on > 192.168.1.254:161 [udp] > Feb 1 13:37:16 localhost tinysnmpd[16426]: recvfrom failed: Bad address > > > Running Debian Sarge Unstable > > On request i can deliver output of 'dpkg -l' > > Regards, > > J. van Koll -- Regards Abraham TODAY the Pond! TOMORROW the World! -- Frogs (1972) ___ Abraham vd Merwe - The Debian Project 1st Floor, Albion Springs, 183 Main Road, Newlands Phone: +27 21 689 3876 Cell: +27 82 565 4451 Http: http://people.debian.org/~abz/ Email: [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#293403: Segfaults or aborts with assertion.
Hi Steve >@2005.02.09_14:52:31_+0200
Thanks for the info. I'll try to relink/submit all my packages linked
against libevent tonight (if not, tomorrow)
> Recompiling potion against current libevent headers seems to be enough to
> fix this bug -- looks like libevent broke ABI compatibility between 0.8 and
> 1.0 without changing the soname. :P
>
> Since this version of libevent is already in testing and libevent was not in
> woody, it's probably better to just rebuild potion instead of trying to
> correct libevent's soname now. Please upload a fixed potion binary ASAP.
>
> It would be good if someone could also look at libevent1's other
> reverse-dependencies, to check for similar breakage. The following packages
> depend on libevent1 and were also last built prior to the upload of libevent
> 1.0:
>
> xsteg (stegdetect)
> tinysnmp-agent (tinysnmp)
> systrace
> scanssh
> memcached
> fragroute
> farpd
--
Regards
Abraham
TODAY the Pond!
TOMORROW the World!
-- Frogs (1972)
___
Abraham vd Merwe - The Debian Project
1st Floor, Albion Springs, 183 Main Road, Newlands
Phone: +27 21 689 3876 Cell: +27 82 565 4451
Http: http://people.debian.org/~abz/
Email: [EMAIL PROTECTED]
signature.asc
Description: Digital signature
