On Wed, Dec 08, 2010 at 10:12:52AM -0600, robert wrote: > > Partial output of make check: > > make --no-print-directory check-recursive > Making check in . > make --no-print-directory libudev/test-libudev udev/test-udev > make[3]: `libudev/test-libudev' is up to date. > make[3]: `udev/test-udev' is up to date. > make --no-print-directory check-TESTS > > udev-test will run 142 tests: > > TEST 1: no rules > device > '/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda' > expecting node/link 'sda' > add: ok > remove: error as expected > > TEST 2: label test of scsi disc > device > '/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda' > expecting node/link 'boot_disk' > add: ok > remove: ok > > AFTER THIS, ALL add/remove reports ok, UNTIL > ...... > > TEST 139: TEST MODE=0000 > device > '/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda' > expecting node/link 'sda' > permissions: ok > add: ok > remove: error as expected > > TEST 140: TEST PROGRAM feeds OWNER, GROUP, MODE > device > '/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda' > expecting node/link 'sda' > permissions: ok > add: ok > remove: error as expected > > TEST 141: TEST PROGRAM feeds MODE with overflow > device > '/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda' > expecting node/link 'sda' > permissions: ok > add: ok > remove: error as expected > > TEST 142: magic [subsys/sysname] attribute substitution > device > '/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda' > expecting node/link 'sda-8741C4G-end' > permissions: ok > add: ok > remove: ok > > 1 errors occured > > FAIL: test/udev-test.pl > ============================================== > 1 of 1 test failed > Please report to [email protected] > ============================================== > So, as with many test suites, bookkeeping might not be its strong point. As Stuart noted, we normally ignore "error as expected".
My own build on the machine I'm using today (LFS from a week or two before 6.7 was released) reported that 0 errors occurred and 1 test passed. However, my results differ from yours - I see everything you have quoted, but I had other 'error as expected' reports in tests 81 (remove) and 82 (add). Probably, the term to search for is 'error' not FAIL - maybe you could recheck your log ? If that doesn't show any other information, you need to consider whether the tests all *need* to pass. I'm not familiar with the udev testsuite, but many testsuites check corner-cases and have occasional failures from time to time, usually because something unrelated changed and the testsuite itself broke. Having all tests pass might provide some comfort, but it gives no information about whether the package will work in real life. I am inclined to suggest "install it, continue, and see if it works when you have booted it". Maybe there is something unusual about your host distro, particularly the toolchain or kernel. What are the versions of gcc, glibc, and the kernel on the host system ? (/me hopes this isn't an example of using LFS-6.7 to see if it will build itself). Also, if you have access to the .config for the running kernel (/proc/config.gz if it has been enabled, or other distro-specific places), are any of the CONFIG_SYSFS_DEPRECATED option(s) set ? You definitely _don't_ want those set in a recent system, but might need it/them on an old host. As of 2.6.36 only ..._V2 exists, but I think 2.6.35 might have had both options. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
