Hello.
Resending this message without attachment as previous version occurred to be scrambled inside archives: http://mail.ibr.cs.tu-bs.de/pipermail/libsmi/2008-March/000994.html
I've tried to run test in libsmi-0.4.7 but 2 of 21 tests failed. Is this expected? The failed tests were:
comparing `smidump -f sming SNMPv2-MIB' output with dumps/sming/*. comparing `smidump -f sming IF-MIB' output with dumps/sming/*. comparing `smidump -f sming MAU-MIB' output with dumps/sming/*. comparing `smidump -f sming RMON2-MIB' output with dumps/sming/*. *** smidump output differs, see smidump-sming.out/*.diff FAIL: smidump-sming.test [snip] comparing `smidump -f smiv2 SNMPv2-MIB' output with dumps/orig-smiv2/*. comparing `smidump -f smiv2 IF-MIB' output with dumps/orig-smiv2/*. comparing `smidump -f smiv2 MAU-MIB' output with dumps/orig-smiv2/*. comparing `smidump -f smiv2 RMON2-MIB' output with dumps/orig-smiv2/*. *** smidump output differs, see smidump-orig-smiv2.out/*.diff FAIL: smidump-orig-smiv2.test [snip] ==================== 2 of 21 tests failed ====================
Bzip2ed tarball of mentioned directories you can download at the link: http://theor.ran.gpi.ru/tests.fail.tbz2
Summary about build system:
default-linux/x86/2007.0, gcc-4.2.3, glibc-2.7-r1, 2.6.23-gentoo-r8 i686 ================================================================= System uname: 2.6.23-gentoo-r8 i686 Intel(R) Pentium(R) M processor 1700MHz app-shells/bash: 3.2_p33 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.61-r1 sys-devel/automake: 1.10.1 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.24 CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=i686 -pipe -mtune=i686" CHOST="i686-pc-linux-gnu" CXXFLAGS="-O2 -march=i686 -pipe -mtune=i686" =================================================================
Thank you in advance for any hints,
On Mon, Mar 03, 2008 at 08:23:04AM +0300, Peter Volkov wrote:
I've tried to run test in libsmi-0.4.7 but 2 of 21 tests failed. Is this expected? The failed tests were:
comparing `smidump -f sming SNMPv2-MIB' output with dumps/sming/*. comparing `smidump -f sming IF-MIB' output with dumps/sming/*. comparing `smidump -f sming MAU-MIB' output with dumps/sming/*. comparing `smidump -f sming RMON2-MIB' output with dumps/sming/*. *** smidump output differs, see smidump-sming.out/*.diff FAIL: smidump-sming.test
This is kind of expected since the sming backend does not right now correctly translate SMIv2 to SMIng. In other words, this is harmless since nobody uses SMIng at the moment.
comparing `smidump -f smiv2 SNMPv2-MIB' output with dumps/orig-smiv2/*. comparing `smidump -f smiv2 IF-MIB' output with dumps/orig-smiv2/*. comparing `smidump -f smiv2 MAU-MIB' output with dumps/orig-smiv2/*. comparing `smidump -f smiv2 RMON2-MIB' output with dumps/orig-smiv2/*. *** smidump output differs, see smidump-orig-smiv2.out/*.diff FAIL: smidump-orig-smiv2.test [snip]
I can't reproduce this on the head version. Frank, did you update the test cases?
/js
В Втр, 04/03/2008 в 14:32 +0100, Juergen Schoenwaelder пишет:
This is kind of expected since the sming backend does not right now correctly translate SMIv2 to SMIng. In other words, this is harmless since nobody uses SMIng at the moment.
Ok, thanks.
comparing `smidump -f smiv2 SNMPv2-MIB' output with dumps/orig-smiv2/*. comparing `smidump -f smiv2 IF-MIB' output with dumps/orig-smiv2/*. comparing `smidump -f smiv2 MAU-MIB' output with dumps/orig-smiv2/*. comparing `smidump -f smiv2 RMON2-MIB' output with dumps/orig-smiv2/*. *** smidump output differs, see smidump-orig-smiv2.out/*.diff FAIL: smidump-orig-smiv2.test [snip]
I can't reproduce this on the head version. Frank, did you update the test cases?
Fails here with trunk too. Also on HPPA, smidump-cm.test fails as well, please, see:
http://bugs.gentoo.org/show_bug.cgi?id=212075
Hello again.
And finally we have smidump-cm.out. Seems that this test failure is not locale specific. Please, take a look at:
http://bugs.gentoo.org/show_bug.cgi?id=212075#c7
Hello, do you need any additional information about tests or does information in bug 212075 is enough? Thank you.
В Птн, 14/03/2008 в 10:49 +0300, Peter Volkov пишет:
And finally we have smidump-cm.out. Seems that this test failure is not locale specific. Please, take a look at:
Hi Peter,
Am 03.03.2008 um 06:23 schrieb Peter Volkov:
[snip] comparing `smidump -f smiv2 SNMPv2-MIB' output with dumps/orig-smiv2/ *. comparing `smidump -f smiv2 IF-MIB' output with dumps/orig-smiv2/*. comparing `smidump -f smiv2 MAU-MIB' output with dumps/orig-smiv2/*. comparing `smidump -f smiv2 RMON2-MIB' output with dumps/orig-smiv2/*. *** smidump output differs, see smidump-orig-smiv2.out/*.diff FAIL: smidump-orig-smiv2.test
Since I could not reproduce this test case failure either, I looked at your supplied test output files from the "orig-smiv2" test case. There was only a difference in the order of imported items. This does NOT affect the correctness of the emited files.
However, it would be interesting to know how this happened. I can just guess that it's something like a differing order of results from readdir(3) calls when MIBs are looked up, or something similar. I admit that my enthusiasm is limited to get this to a more deterministic fashion.
В Втр, 11/03/2008 в 10:15 +0100, Frank Strauß пишет:
Hi Peter,
Am 03.03.2008 um 06:23 schrieb Peter Volkov:
[snip] comparing `smidump -f smiv2 SNMPv2-MIB' output with dumps/orig-smiv2/ *. comparing `smidump -f smiv2 IF-MIB' output with dumps/orig-smiv2/*. comparing `smidump -f smiv2 MAU-MIB' output with dumps/orig-smiv2/*. comparing `smidump -f smiv2 RMON2-MIB' output with dumps/orig-smiv2/*. *** smidump output differs, see smidump-orig-smiv2.out/*.diff FAIL: smidump-orig-smiv2.test
Since I could not reproduce this test case failure either, I looked at your supplied test output files from the "orig-smiv2" test case. There was only a difference in the order of imported items. This does NOT affect the correctness of the emited files.
However, it would be interesting to know how this happened. I can just guess that it's something like a differing order of results from readdir(3) calls when MIBs are looked up, or something similar. I admit that my enthusiasm is limited to get this to a more deterministic fashion.
Oh, seems that this due to different locale settings. I've tried with LC_COLLATE=C and then only sming failed. Now I forced LC_ALL=C in ebuild, but may be it's better to force that in test suite. If there will be any update from hppa team I'll mail you. Thank you!
participants (3)
-
Frank Strauß -
Juergen Schoenwaelder -
Peter Volkov