Description of problem: Upstream NSS includes in it's tar ball a test script which can verify and NSS installation. We should make that test script, which the necessary binaries which aren't already in an NSS package, in it's own package that can be installed and ran.
Chandra, do you have experience with running the NSS test programs? Bob R: Is your proposal to run "all.sh" ? How should this work in detail? I just tried to run all.sh on my system, I started with HOST=localhost DOMSUF=localdomain ./all.sh and the test seems to be in a kind of endless loop where a TCP test with tstclnt repeatedly fails. Should this be a purely optional manual task that someone can run and look at the test output? Or, does the script return a single exit code that indicates "all tests succeeded"?
Your endless loop thing should be identified. I run all.sh on my machines all the time to verify my fixes. Unfortunately all.sh itself does not return a rollup success code, but there are scripts which can determine if all.sh had any failure or not. The tools is definately meant to be run automatically as well as manually (tinderbox automatically runs all.sh, for instance, after every build, all.sh failures turn tinderbox orange rather than red (build failures)).
The original approach seemed hard, this is why I had not worked on this bug yet. However, we did come up with a better idea! Let's run the test suite as part of the rpm build process. A successful run of the test suite on the build test is a necessary precondition to get a rpm package! This should avoid the need for having the test suite available for installation. This has been fixed in Rawhide. Test suite is currently enabled for i386 and x86_64, but temporarily disabled for ppc and ppc64 because of an upstream failure.