NSS BuildBot Status

This page lists known issues related to the NSPR/NSS/JSS continuous integration builds found at http://test.nss-crypto.org

Please check the Rules section if you are new to this project.

Hints

Most output shown in the buildbot log has been filtered, to suppress the vast amount of e.g. polling status information produced by the test tools.
At the end of the logfile, all FAILED results are printed with 50 lines of preceeeding context.

occassionaly a build is red for no apparent reason, such as that final section of the logfile not reporting any matches for the string FAILED (besides the overall failure status). One possible reason is, occassionally, the "output directory rotation" is failing. As a result, directory tests_results/security is reused, and the output of a second build cycle is written into that directory (with hostname.2). This breaks the assumptions of the test scripts. This needs investigation how to ensure that directory rotation works reliably, or at least gets detected and reported.
Android: Building happens on a Linux computer and testing happens on an Android tablet. You might occassionally see the build to succeed, and the test failing, complaining about missing files. Most likely the Android tablet is offline. This can happen is the SSH daemon goes offline, or if the Android tablet looses its wifi connection. If this happens, the tablet's wifi and SSH daemon need to be manually checked/restarted.
we occassionally see test failures because the OCSP server cannot be reached from a build slave

One positive review or super-review is necessary to commit to the NSS trunk.
Always check this page before any commit to the trunk. If the most recent completed build on any platform shows red, do NOT commit until it goes green. Obviously, if you're trying to fix the very reason that it is red, this rule does not apply to you.
Any patch committed while the tree is red is a candidate to be backed out by the sheriff, even if it is not the cause of the red.
If someone else has checked in to the trunk recently, and the tree has not yet done a full build cycle on all tinderboxes since then, you should wait until all builds complete a cycle with the preceding checkin, and are all green, before you check in.
After you check in, watch this page until all machines have completed a full build cycle with your patch and have gone (stayed) green. Don't check in right before going to bed, or on vacation.
If your checkin makes any tinderbox go red, it's YOUR responsibility to make it go green again before walking away from it. If you develop a new corrective patch, you still need a review for it. So, generally the best plan is to back out your bad patch.