I think the "non-revealed port is closed" test can break other tests, depending on the gc's behavior. At the moment this is easy to reproduce for some reason (presumably differing gc behavior) on the Debian s390x machines.
I believe the problem is that if the gc doesn't collect the port when the test calls (gc), then the test (which recognizes that possibility) calls close-fdes on the underlying fd. However, the port still exists, and it may be garbage collected later, during a test that's using the same fd, which may break that test. I did add some low-level fprintf diagnostics which confirmed that exact behavior. i.e. one of the subsequent tests would call (gc), and I could see that the old port object (identified by the %p pointer) from the earlier "non-revealed port is closed" test, closed the fd which broke the the current test when it attempted a seek on the fd that should still be open. For now, I've just commented out the test in the Debian packages, and unless some other arrangements can be made, suspect we might want to do the same thing in Guile itself. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4