test failures of 0.9.1 on Solaris (Nevada)

[Danek Duvall]

There are a handful of failures on Solaris.  Some of them are easy to
resolve -- get-with-headers.py and tinyproxy.py are missing from the
tarball and nearly the entirety of the tests that use them fail outright.

test-globalopts fails because /usr/bin/grep on Solaris doesn't support -q.
That's conceivably a bug in grep (/usr/xpg4/bin/grep has it), but the test
might use "> /dev/null" instead, for portability.

However, there are two tests that fail more "seriously":

    --- test-import.out     Fri Jul  7 16:33:19 2006
    +++ test-import.err     Sun Jul 30 12:02:20 2006
    @@ -89,8 +89,6 @@
     1 files updated, 0 files merged, 0 files removed, 0 files unresolved
     applying patch from stdin
     patching file a
    -transaction abort!
    -rollback completed
     % hg export in email, should use patch header
     requesting all changes
     adding changesets
    --- test-init.out       Mon Jul 24 14:43:12 2006
    +++ test-init.err       Sun Jul 30 12:03:38 2006
    @@ -1,6 +1,7 @@
     # creating 'local'
     adding foo
     # init+push to remote2
    +remote: abort: repository remote2 not found!
     changeset:   0:c4e059d443be
     tag:         tip
     user:        test
    @@ -14,8 +15,9 @@
     remote: adding file changes
     remote: added 1 changesets with 1 changes to 1 files
     # clone to remote1
    -searching for changes
     remote: abort: repository remote1 not found!
    +remote: abort: repository remote1 not found!
    +searching for changes
     remote: adding changesets
     remote: adding manifests
     remote: adding file changes

I spent a few hours yesterday trying to figure out the first problem in
test-init.  I didn't figure out what the real problem was, but here's what
I learned ...

On both systems, a remote init (hg init ssh://.....) first attempts a
remote serve on the non-existent repo, which fails, then does the remote
init, and then another serve.  It's that first failure that causes the
extra message above, but while that message propagates to the client on
Solaris, it doesn't on Linux (though it does show up in the log if I make
dummyssh redirect stderr to dummylog).

After that, I'm stumped.  It seems like there are two bugs -- one is that
Linux isn't propagating the (perfectly valid) error message back to the
client, and I've *no* idea why there's a difference there.  Strace/truss
output shows that the data is in fact never being received or sent on
Linux, but is on Solaris.  Perhaps it's a bug in Python on Linux?  I dunno.

The second problem follows from that -- if the error message should be
propagated consistently, then it's still not something the user should see.
Either that first "serve" command shouldn't be attempted, or its error
messages should explicitly be ignored.

I haven't even begun looking for the causes of the other problems, hoping
that perhaps someone else can track them down faster than I can.

Thanks,
Danek