All three problems found by the tinderbox so far have now been fixed, and the tree is all green.

Spent some time reworking the password expiry patch for (hopefully) the last time by deleting a lot of the optional code (eg HP-UX support, since non-PAM password password expiry isn't supported now, and an unnecessary privsep call).

An unrelated subject, we just upgraded the OS on some of our systems to the latest patch set. Despite the fact that that this is allegedly a supported configuration, one of the important apps core dumps mere milliseconds after starting up. It crashed so fast, in fact, that the only way I could catch it with a debugger was to write a one-line command line script to busy-wait for it to start. (Before you ask, no, it did not actually leave a core file, that would have been too easy). My first attempt was even too slow, I had to optimize it! The debugger showed it was crashing in a libc function call.

Naturally, this had not shown up on the test system. Also naturally, the application vendor's support blamed it on a corrupt libc! (obviously, that's why every other binary on the system works fine). Given a choice between the most-used library in the OS and an application with a history of bugs from a vendor with a bigger history of bugs, guess which one I'm betting on...

If they must ship this crap, could they at least ship it with debugging symbols to give us a fighting chance?