|
Bugzilla – Full Text Bug Listing |
| Summary: | LSB3.2 tests failed on opensuse-11-beta2-ppc64-Power6. | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 11.0 | Reporter: | LTC BugProxy <bugproxy> |
| Component: | Other | Assignee: | Jiri Dluhos <jdluhos> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | matz |
| Version: | Beta 2 | ||
| Target Milestone: | --- | ||
| Hardware: | PowerPC-64 | ||
| OS: | All | ||
| URL: | http:// | ||
| See Also: | https://bugzilla.linux.ibm.com/show_bug.cgi?id=44924 | ||
| Whiteboard: | |||
| Found By: | Third Party Developer/Partner | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
tar-gzip ball of the results-3.2
tar ball of the results-3.1 A simple test case. Source of the offending test. Desktop test result-3.2.0.8 libstdc++ test result -3.2.0.8 desktop-t2c test results-3.2.0.8 |
||
|
Description
LTC BugProxy
2008-06-13 10:09:03 UTC
Created attachment 222000 [details]
tar-gzip ball of the results-3.2
Created attachment 222001 [details]
tar ball of the results-3.1
Thank you for the logs; I am now analysing them. Many of the failures are known to us, are in process of being fixed. Here is a quick summary for the Core test: /tset/LI18NUX2K.L1/base/strptime/T.strptime 32: - a glibc bug - please see https://bugzilla.novell.com/show_bug.cgi?id=355887 /tset/LSB.os/procprim/execl/T.exec* 3, /tset/LSB.os/procenv/nice_X/T.nice_X 1, /tset/LSB.os/procprim/fork/T.fork 8: - bug in kernel privilege check for SCHED_FIFO - please see https://bugzilla.novell.com/show_bug.cgi?id=394548 /tset/POSIX.os/procprim/exec/T.exec* 15, /tset/POSIX.os/procenv/sysconf/T.sysconf 1: - wrong value of ARG_MAX in libc headers - please see https://bugzilla.novell.com/show_bug.cgi?id=389791 /tset/lsb_release/testcases/lsb_release/lsb_release-tc 2 - this failure is harmless, caused by the fact that lsb_release does not report LSB 3.2 (as we did not yet reached full LSB 3.2 compatibility) /tset/LSB.os/ioprim/readv_L/T.readv_L 24, /tset/LSB.os/ioprim/writev_L/T.writev_L 30: - these are test suite deficiencies: - please see https://www.linuxfoundation.org/lsbprs/pr/116, https://www.linuxfoundation.org/lsbprs/pr/117 /tset/LSB.pam/testcases/*: - all these failures seem to be caused by a miscompiled test suite Could you please re-run the tests with the newest OpenSUSE pre-release *and* with the newest beta build of the LSB tests? (I am generally using the most recent beta of the LSB tests when testing our own betas; it is useful because the betas typically have some additional fixes.) To the other tests in the report: At least part of the Gtk failures look to me like test suite deficiencies; results should be better when using the most recent beta of the LSB tests. Results in the Qt3 and libstc++ test are strange; I suspect that you had accidentally downloaded a miscompiled version of the test suite. Again, please inform us how the result changes with the most recent beta. ------- Comment From IndhuDurai@in.ibm.com 2008-06-24 04:32 EDT------- Vinay, As opensuse11.0 public release is over, is it ok to run on that or you want me to run on the prior release? regards, Indhu Durai ------- Comment From IndhuDurai@in.ibm.com 2008-07-11 02:34 EDT------- Hi Vinay, The size of the results tar ball is exceeding the limits(2M) of the attachment(4M) size. I have uploaded the results in the repo->9.124.111.85:/dump/IMAGES/opensuse/11/lsb/results.tgz. Regards, Indhu Durai ------- Comment From vinaysridhar@in.ibm.com 2008-07-11 06:16 EDT------- Novell, You can obtain the results file from "testcase.software.ibm.com/fromibm/linux/results.tgz" using the anonymous login Thank you for the info; I am now analyzing it. So far I can tell: Results from the library check seem fine to me; all failures are caused by missing libraries, which is normal for a server system (unless you know that these libraries were installed and should be found). Results of the runtime test are reflecting two known bugs where fixing is underway (#355887, #389791), and two known test suite deficiencies: https://www.linuxfoundation.org/lsbprs/pr/116 https://www.linuxfoundation.org/lsbprs/pr/117 The only really interesting failure is /tset/LI18NUX2K.L1/base/iswctype/T.iswctype.2 I don't recall seeing this before; it seems to only occur on ppc64. Created attachment 227370 [details]
A simple test case.
I have created a small test case which, hopefully, might reproduce the bug. Could you please test it on the same machine? I will try to test it on-site as soon as I get my paws on a free PPC machine.
(It is necessary to install the locale first, then run the test.)
------- Comment From vinaysridhar@in.ibm.com 2008-07-21 08:14 EDT------- Novell, Could you please specify how the locale is to be set up? If everything works as expected, it should be enough to enter the directory with the two testing locale source files (LTP_1 and UTF-8) and enter (as root): localedef -c -f UTF-8 -i LTP_1 "LTP_1.utf8" This should install the testing locale to the system. ------- Comment From vinaysridhar@in.ibm.com 2008-07-22 01:23 EDT------- Novell, On running the above command I get the following message : "LC_MONETARY: value of field `int_curr_symbol' does not correspond to a valid name in ISO 4217" Do not worry, the message is only a warning. The installation should succeed; the "-c" flag is there for that purpose. ------- Comment From vinaysridhar@in.ibm.com 2008-07-22 06:08 EDT------- Ok, ran the test after setting the locale. Test ran silently with the "return" variable = 0 ------- Comment From vinaysridhar@in.ibm.com 2008-07-22 06:09 EDT------- Sorry, I meant the "result" variable = 0 ------- Comment From vinaysridhar@in.ibm.com 2008-07-24 05:52 EDT------- Novell, Did the above test result reveal anything? The result is interesting because the test did not detect the iswctype() problem the LSB test suite has detected. Did you use the same computer and OS as the one where the last LSB test suite was run? (Maybe I have a bug in the small test program, or maybe the LSB test suite failure is caused by a problem in a different test.) Finally I have a working ppc machine! :-) So far, it seems that the problem does _not_ appear in openSUSE 11 if a ppc32 version is used; the /tset/LI18NUX2K.L1/base/iswctype/T.iswctype.2 test normally passes. I will try the ppc64 version now... Well, it seems I have misunderstood something :-( The ppc64 version of LSB tests, which I assume is the version you used, refuses to even install on our testing machine. After some thinking I have realized that this is probably normal because in openSUSE for ppc, the userspace is mostly 32-bit; only the kernel is 64-bit, plus some libraries. The primary cause why the package does not install is that it cannot find the lsb-core-ppc64 symbol, which is not present because the 'lsb' package in openSUSE is built in 32-bit mode. I am able to bypass this obstacle by building a custom package, but it is a hack adnd I'm not sure whether the result can be called a clean distro. :-( Please, how did you manage to install the 64-bit test suite at all? ------- Comment From vinaysridhar@in.ibm.com 2008-07-28 07:44 EDT------- Indhu, Could you please reply to the queries in comments 37 and 39? Thanks, Vinay ------- Comment From pnaregun@in.ibm.com 2008-07-29 06:28 EDT------- (In reply to comment #39) > > Please, how did you manage to install the 64-bit test suite at all? Created a soft link of /lib64/ld64.so.1 to /lib64/ld-lsb-ppc64.so.3 and /lib64/ld-lsb-ppc64.so.2. This managed us to run it on 64-bit test suite. Finally I have managed to reproduce the problem; it requires not only the symlinks but also install a specially compiled LSB package that provides the lsb-core-ppc64 atom. The results look very similar to yours, with the single problem that worries me: /tset/LI18NUX2K.L1/base/iswctype/T.iswctype 2 CC'ing to our libc gurus. *** Bug 384903 has been marked as a duplicate of this bug. *** Michael, Pasky, do you have any idea about the iswctype problem? It seems that a test that does iswctype() segfaults on ppc64; as far as I can tell, the test is straightforward, I don't know why it crashes. Attaching the source code of the test. Created attachment 230860 [details]
Source of the offending test.
------- Comment From vinaysridhar@in.ibm.com 2008-07-31 06:44 EDT------- Novell, Is this a libc issue or a test-suite issue? Because running the test you posted earlier did not cause any libc issue. The iswctype problem comes only from lsb... Jiri, please give me exact instructions how I should reproduce this. I.e. commands and files I need (it seems I need some exact locale files?). Best if you pack every necessary file together in a tarball and attach it here. Vinay: So far, I still can't tell whether it is a libc bug or a problem of the test suite. It is true that the test program I produced did not reproduce it, but that may be because I failed to mimic the behavior of the test suite close enough. We are still working on it - please stay tuned. Ah well. I am an idiot. http://bugs.linuxbase.org/show_bug.cgi?id=2146 The iswctype problem is already known for 14 days; it is a bug in the test suite (uninitialized variable), and fixed in the bazaar version. That's why my test program did not crash - I extracted it from the bazaar version, where the problem is already fixed. When I un-fixed the code, it exhibits the crash perfectly. Morale: always google first before getting entangled in the code. Michael, Vinay, Pasky, Jan: I'm sorry for bothering you. Alarm canceled. If I count correctly, this was the last problem, at least regarding the core test. However, we need to wait until the LSB team builds a new beta of the test suite with these fixes included, so that it can be tested. ------- Comment From vinaysridhar@in.ibm.com 2008-08-05 07:29 EDT------- Novell, The core failure issues seem to be settled. Could you share information on the other failures : gtk, qt3, libstdc++, etc? Hmmm... The set of failures in libstdc++ is interesting. When I have run the test on our ppc64 machine, it passed (which is also strange - LSB tests are so strict that it is a sign of special luck when some of them passes). I will try the rest and attach the resulting report; maybe we will find the causes by comparison. The tests are still running, but so far it seems that the number of failures is significantly lower than in your tests. I think it might be caused by old tests; I would recommend downloading a fresh new Desktop Test Toolkit from linuxfoundation.org: http://www.linuxfoundation.org/en/Downloads and re-running the desktop and libstdc++ tests, allowing the DTK to download new versions of tests from the web. With all other tests disabled, the run should be quite fast - let's say two hours. I will attach my results as soon as they are completed. Created attachment 232334 [details]
Results of the desktop test run on a ppc64 machine in Novell
I have attached the results of the test run on our testing machine. From a quick view, the results look quite good; most of the remaining failures are known test suite problems.
Can you please re-run the desktop and libstc++ tests (plus any other you need) with the newest version of the Desktop Test Kit and new test packages? I believe the results will be much better. For better orientation, here is a short summary of failures I have seen in the test run on our machine: === libchk === (Only uninstalled libraries, plus known test defects.) === desktop T2C test === * /glib-t2c/tests/glib_unicode/glib_unicode 18 * /glib-t2c/tests/glib_character_set_conversion/glib_character_set_conversion 32 * /gmodule-t2c/tests/gmodule/gmodule 23 (These three look like test suite problems, but deserve investigation.) === gtk test === * /tests/functions/GtkToolbar/GtkToolbar 15 (Test suite bug, http://bugs.linuxbase.org/show_bug.cgi?id=1895) * /tests/functions/GdkImages/GdkImages 2 (Test suite bug, http://bugs.linuxbase.org/show_bug.cgi?id=1893) * /tests/functions/Drag_and_Drop/Drag_and_Drop 41 (Looks like http://bugs.linuxbase.org/show_bug.cgi?id=1260) ------- Comment From pavan.naregundi@in.ibm.com 2008-08-12 06:03 EDT------- (In reply to comment #54) > ------- Comment From jdluhos@novell.com 2008-08-08 07:10:15 MDT------- Result of the libstdc++(4 failures), desktop(10 failures) and desktop-t2c(16 failures) tests on opensuse11.1 Alpha1 is attached below. Some of the failures are same as mentioned in comment #55. I have run these tests with lsb-dist-testkit-3.2.0.8. Created attachment 232913 [details]
Desktop test result-3.2.0.8
Created attachment 232914 [details]
libstdc++ test result -3.2.0.8
Created attachment 232915 [details]
desktop-t2c test results-3.2.0.8
I'm sorry but results from openSUSE 11.1 alpha1 cannot help us in this case. We need results from openSUSE 11.0 final. The new openSUSE 11.1 is too different. Therefore, results #38, #39, #40 are flawed - sorry for that. Also, the desktop test is still old; the most recent version is currently 3.2.1-2; this affects at least the GTK test (I think the Drag-and-Drop failures are all already fixed bugs in the test suite, probably even the Resource_Files.34 failure). ------- Comment From pavan.naregundi@in.ibm.com 2008-08-13 04:23 EDT------- (In reply to comment #60) > ------- Comment From jdluhos@novell.com 2008-08-12 09:26:57 MDT------- I have rerun the tests on opensuse11. Results are similar to one mentioned in comment #55, except that following failure did not occur. /glib-t2c/tests/glib_character_set_conversion/glib_character_set_conversion 32 This is a bit strange because my results are still different; please, did you use the newest version of the desktop test? (3.2.1-2) ------- Comment From pavan.naregundi@in.ibm.com 2008-08-19 00:43 EDT------- (In reply to comment #62) > ------- Comment From jdluhos@novell.com 2008-08-13 05:47:26 MDT------- > This is a bit strange because my results are still different; please, did you use the newest version of the desktop test? (3.2.1-2) Yes. ------- Comment From vinaysridhar@in.ibm.com 2008-09-02 02:04 EDT------- Pavan, Novell, how do we proceed on this? If we could agree on a common list of test failures, we could see what could be worked on. Could you please update with your views? Thanks, Vinay I'm sorry for the delay, I somehow managed to miss your first answer :-( I had a more thorough look at the results of the desktop-t2c tests; it seems that at least part of the fails are test bugs that behave semi-randomly, which might explain why you have got a different set of fails than we have. So far, I have found these failures to be test bugs, and reported them to the LSB committee as such: /glib-t2c/tests/glib_unicode/glib_unicode 18 - reported as http://bugs.linuxbase.org/show_bug.cgi?id=2276 /glib-t2c/tests/glib_trash_stack/glib_trash_stack 1 - reported as http://bugs.linuxbase.org/show_bug.cgi?id=2277 /glib-t2c/tests/glib_threads/glib_threads 2 - reported as http://bugs.linuxbase.org/show_bug.cgi?id=2278 I am still pondering over the remaining failures - please stay tuned. desktop-t2c tests, continued: /glib-t2c/tests/glib_string_utility/glib_string_utility 55-60 - reported as http://bugs.linuxbase.org/show_bug.cgi?id=2279 desktop-t2c tests, continued: /glib-t2c/tests/glib_messagelog/glib_messagelog 9,10 /glib-t2c/tests/glib_commandline_option_parser/glib_commandline_option_parser 24,25,46,47 - with these, I have no idea; I have not found any specific bug in the tests, and these failures do not occur at our testing machine. ------- Comment From pavan.naregundi@in.ibm.com 2008-09-05 07:50 EDT------- (In reply to comment #67) > ------- Comment From jdluhos@novell.com 2008-09-04 07:36:42 MDT------- > desktop-t2c tests, continued: > > /glib-t2c/tests/glib_messagelog/glib_messagelog 9,10 > /glib-t2c/tests/glib_commandline_option_parser/glib_commandline_option_parser 24,25,46,47 > - with these, I have no idea; I have not found any specific bug in the tests, and these failures do not occur at our testing machine. Novell, I think you are not able to see my post of the result of latest run using desktop test(3.2.1-2), as I have mentioned comment 55, but it does not point to anything. Sorry for that. Here is the summary of result I got in latest run using desktop test(3.2.1-2) === desktop T2C test === * /glib-t2c/tests/glib_unicode/glib_unicode 18 * /gmodule-t2c/tests/gmodule/gmodule 23 These are only errors. === gtk test === * /tests/functions/GtkToolbar/GtkToolbar 15 (Test suite bug, http://bugs.linuxbase.org/show_bug.cgi?id=1895) * /tests/functions/GdkImages/GdkImages 2 (Test suite bug, http://bugs.linuxbase.org/show_bug.cgi?id=1893) * /tests/functions/Drag_and_Drop/Drag_and_Drop 41 (Looks like http://bugs.linuxbase.org/show_bug.cgi?id=1260) These are known failures. Excellent! It seems that many test suite failures are fixed in the newest test suite version, which is good. Were the other tests (desktop and libstdc++) also better? Can we consider this issue closed? ------- Comment From pavan.naregundi@in.ibm.com 2008-09-10 07:47 EDT------- (In reply to comment #69) > ------- Comment From jdluhos@novell.com 2008-09-05 06:13:26 MDT------- > Were the other tests (desktop and libstdc++) also better? Can we consider this issue closed? There where only known failures in libstdc++ and desktop tests. Yes, we can close this bug now. Thanks Pavan ------- Comment From vinaysridhar@in.ibm.com 2008-09-11 05:48 EDT------- Closing as per the above comments Rodrigo Sampaio Vaz <rsampaio@br.ibm.com> - 2008-04-04 16:51 EDT ---Problem Description--- While running LSB 3.1 runtime-tests on a power machine I noticed 9 failures on SLES-10sp2-RC1 (2.6.16.60-0.9-ppc64 #1 SMP) using lsb-dist-testkit-3.1.1-5.ppc64.tar.gz Following are the 9 errors collected from html report generated by runtime-tests 1) /tset/LI18NUX2K.L1/base/iswctype/T.iswctype 2 Unresolved Messages from the test If wc does not belong character class which shows desc, verify this function returns 0. Test Locale is LTP_1.UTF-8 unexpected signal 11 (SIGSEGV) received 2) /tset/LI18NUX2K.L1/base/swscanf/T.swscanf 12 Failed Messages from the test If a conversion wide character is `p', verify this function stores the pointer value. Test Locale is LTP_1.UTF-8 Conversion wide character p is not interpreted correctly path tracing error: path counter 0, expected 1 3) /tset/LI18NUX2K.L1/base/__wcstold_internal/T.__wcstold_internal 8 Failed Messages from the test When the correct value is outside of representable values, verify that plus or minus HUGE_VALL is returned and ERANGE is stored in errno. Test Locale is C The return value is not correct. The errno is not correct. path tracing error: path counter 0, expected 2 4) /tset/LI18NUX2K.L1/base/wcstold/T.wcstold 8 Failed Messages from the test When the correct value is outside of representable values, verify that plus or minus HUGE_VALL is returned and ERANGE is stored in errno. Test Locale is C The return value is not correct. The errno is not correct. path tracing error: path counter 0, expected 2 5) /tset/LSB.fhs/root/bin/bin-tc 11 Failed Messages from the test Reference 3.4-11 (A) The implementation provides an exec-able version of the dmesg utility in the /bin directory. Expected output to stdout, but none written 6) /tset/LSB.os/ioprim/readv_L/T.readv_L 24 Failed Messages from the test iov[0].iov_base = 0x8f4003f4010, iov[0].iov_len = 1024 iov[1].iov_base = 0x8f4003f4010, iov[1].iov_len = 1024 iov[2].iov_base = 0x8f4003f4010, iov[2].iov_len = 1024 .... iov[1021].iov_base = 0x8f4003f4010, iov[1021].iov_len = 1024 iov[1022].iov_base = 0x8f4003f4010, iov[1022].iov_len = 1024 iov[1023].iov_base = 0x8f4003f4010, iov[1023].iov_len = 1024 readv(5, iov, 1024) did not behave as expected ERRNO VALUES: expected: 22 (EINVAL), observed: 14 (EFAULT) 7) /tset/LSB.os/ioprim/writev_L/T.writev_L 30 Failed Messages from the test Could not allocate a large write buffer (wanted 1024 bytes) Will attempt to test using a buffer of 8589934592 bytes This may result in a SIGSEGV being raised iov[0].iov_base = 0x8f4003f4010, iov[0].iov_len = 1024 iov[1].iov_base = 0x8f4003f4010, iov[1].iov_len = 1024 iov[2].iov_base = 0x8f4003f4010, iov[2].iov_len = 1024 ... iov[1022].iov_base = 0x8f4003f4010, iov[1022].iov_len = 1024 iov[1023].iov_base = 0x8f4003f4010, iov[1023].iov_len = 1024 writev(7, iov, 1024) did not behave as expected: ERRNO VALUES: expected: 22 (EINVAL), observed: 14 (EFAULT) 8) /tset/PTHR.os/procenv/getlogin_r/T.getlogin_r 1 Failed Known problem Messages from the test If the feature test macro _POSIX_THREAD_SAFE_FUNCTIONS is defined: concurrent calls by multiple threads to getlogin_r(name, namesize) store the name associated by the login activity with the controlling terminal of the current process in the character array referenced by name and return 0 if successful. Posix Ref: Component GETLOGIN_R Assertion 9945-1:1996 4.2.4.2-1(C) The system does not support the PTHREAD_SCOPE_PROCESS scope, using PTHREAD_SCOPE_SYSTEM The system does not support the PTHREAD_SCOPE_PROCESS scope, using PTHREAD_SCOPE_SYSTEM The system does not support the PTHREAD_SCOPE_PROCESS scope, using PTHREAD_SCOPE_SYSTEM The system does not support the PTHREAD_SCOPE_PROCESS scope, using PTHREAD_SCOPE_SYSTEM The system does not support the PTHREAD_SCOPE_PROCESS scope, using PTHREAD_SCOPE_SYSTEM The system does not support the PTHREAD_SCOPE_PROCESS scope, using PTHREAD_SCOPE_SYSTEM The system does not support the PTHREAD_SCOPE_PROCESS scope, using PTHREAD_SCOPE_SYSTEM The system does not support the PTHREAD_SCOPE_PROCESS scope, using PTHREAD_SCOPE_SYSTEM Unexpected login name root, should be vsx0 Unexpected login name root, should be vsx0 Unexpected login name root, should be vsx0 Unexpected login name root, should be vsx0 Unexpected login name root, should be vsx0 Unexpected login name root, should be vsx0 Unexpected login name root, should be vsx0 Unexpected login name root, should be vsx0 LSB Report Status: Reported to the LSB Committee as PR 0137. ---Additional Hardware Info--- keechi-lp1:~ # cat /proc/cpuinfo processor : 0 cpu : POWER6 (architected), altivec supported clock : 3504.000000MHz revision : 3.1 (pvr 003e 0301) processor : 1 cpu : POWER6 (architected), altivec supported clock : 3504.000000MHz revision : 3.1 (pvr 003e 0301) processor : 2 cpu : POWER6 (architected), altivec supported clock : 3504.000000MHz revision : 3.1 (pvr 003e 0301) processor : 3 cpu : POWER6 (architected), altivec supported clock : 3504.000000MHz revision : 3.1 (pvr 003e 0301) processor : 4 cpu : POWER6 (architected), altivec supported clock : 3504.000000MHz revision : 3.1 (pvr 003e 0301) processor : 5 cpu : POWER6 (architected), altivec supported clock : 3504.000000MHz revision : 3.1 (pvr 003e 0301) processor : 6 cpu : POWER6 (architected), altivec supported clock : 3504.000000MHz revision : 3.1 (pvr 003e 0301) processor : 7 cpu : POWER6 (architected), altivec supported clock : 3504.000000MHz revision : 3.1 (pvr 003e 0301) timebase : 512000000 machine : CHRP IBM,9125-F2A keechi-lp1:~ # free -m total used free shared buffers cached Mem: 8037 1596 6441 0 94 1287 -/+ buffers/cache: 213 7823 Swap: 2055 0 2055 ---uname output--- Linux keechi-lp1 2.6.16.60-0.9-ppc64 #1 SMP Mon Mar 17 17:16:31 UTC 2008 ppc64 ppc64 ppc64 GNU/Linux Machine Type = P6/IH - p 575 ---Steps to Reproduce--- 1 - fetch the latest autotest from test.kernel.org/autotest (svn checkout svn://test.kernel.org/autotest/trunk/client /usr/local/autotest ) 2 - now cd /usr/local/autotest 3 - run bin/autotest tests/lsb_dtk/control 4 - check results in /usr/local/autotest/results/default (Takes about 6 hrs to reproduce) ---Other Component Data--- Userspace tool common name: lsb-dist-testkit-3.1.1-5.ppc64.tar.gz The userspace tool has the following bit modes: 64-bit Userspace rpm: lsb-runtime-test-3.1.1-4.ppc64.rpm --------------------------- Mirroring this bug to your for your awareness of 8 LSB 3.1 failures on SLES10 SP2. -thanks. Jiri, can you have a look at this LSB issue? *** This bug has been marked as a duplicate of bug 399986 *** I have looked at the problems; most are known test suite deficiencies. Only #2, #5 and #8 are interesting. I would recommend running newer tests as many test suite bugs were already fixed, and see whether some of the failures persist. 1) Test suite bug (uninitialized variable), please see http://bugs.linuxbase.org/show_bug.cgi?id=2146 2) Further info would be needed; this might, but does not have to, be related to http://bugs.linuxbase.org/show_bug.cgi?id=1958 3) Test suite bug, see http://bugs.linuxbase.org/show_bug.cgi?id=1771 4) Looks like the same problem as 3) 5) More data would be needed; looks like some simple problem, like missing /bin/dmesg. 6) Known problem, https://www.linuxfoundation.org/lsbprs/pr/117 7) Same as 6), only a different call: https://www.linuxfoundation.org/lsbprs/pr/116 8) The automated test analyzer reports marks this as a test suite problem (see https://www.linuxfoundation.org/lsbprs/pr/137), which I'm not sure if it is the same thing, although I believe it is a test suite problem. As I believe these bugs are all test suite problems, closing this bug; if the failures persist with newer tests, please re-open. Closed :-) |