testsuite failues of 1.0.9 on GNU/Linux sparc/ia64

[David Kimdon <dw...@debian.org>]

Hi,

I'm trying to update the subversion Debian packages to 1.0.9 and am
getting intermittent testsuite failures on sparc and ia64.  For all
other archs (i386 alpha hppa s390 m68k arm mipsel mips powerpc) the
testsuite passed.  At this point I am thinking that this is a problem
with the build machines.

For ia64 first the build failed on the machine 'caballero'[1], but
then when I ran the build on a different machine, 'merulo', the
testsuite passed.  I uploaded the package thinking the failure on
caballero was simply random and moved onto fixing sparc.

For sparc all testsuite failures have happenned on the same machine,
'vore'. Every time the testsuite has failed in a different
place[2,3,4].

There is plenty of space on the filesystem.  The only oddity is that
the filesystem, at least in the cases where I ran the build manually
are a Linux 'bind' mount.  All the failures look like we have a broken
filesystem.

I'm thinking of saying this isn't subversion's problem, disabling the
testsuite on sparc, and uploading the package . . .

The sparc machine is running Linux 2.4.26, FWIW.

Thanks for any clues,

David

[1] : Here is the ia64 autobuilder failing

http://buildd.debian.org/fetch.php?&pkg=subversion&ver=1.0.9-2&arch=ia64&stamp=1097970486&file=log&as=raw

EXPECTED STDERR:
ACTUAL STDERR:
/build/buildd/subversion-1.0.9/build-tree/subversion-1.0.9/subversion/clients/cmdline/.libs/lt-svn: error while loading shared libraries: libsvn_ra_local-1.so.0: cannot open shared object file: No such file or directory
EXCEPTION: SVNLineUnequal
FAIL:  log_tests.py 8: 'svn log TGT' with copyfrom history

[2] : Here is the sparc autobuilder failing:

http://buildd.debian.org/fetch.php?&pkg=subversion&ver=1.0.9-2&arch=sparc&stamp=1097970681&file=log&as=raw

PASS:  lt-fs-test 12: set and get some revision properties
svn: Berkeley DB error while creating 'strings' table for filesystem test-repo-txn-props:
DB_RUNRECOVERY: Fatal error, run database recovery
svn: warning: Berkeley DB error while closing 'revisions' database for filesystem test-repo-txn-props:
DB_RUNRECOVERY: Fatal error, run database recovery
FAIL:  lt-fs-test 13: set/get txn props, commit, validate new rev props
svn: Can't create Berkeley DB environment dir 'test-repo-node-props': No such file or directory
FAIL:  lt-fs-test 14: set and get some node properties 

START: run-repos-tests.py
Traceback (most recent call last):
  File "/build/buildd/subversion-1.0.9/build-tree/subversion-1.0.9/subversion/tests/libsvn_repos/run-repos-tests.py", line 11, in ?
    import exectest
ImportError: No module named exectest
END: run-repos-tests.py

[3] These errors occured when I ran the build manually on merulo

http://people.debian.org/~dwhedon/tests.log.1

IOError: [Errno 2] No such file or directory: 'repositories/commit_tests-30/conf/svnserve.conf'
FAIL:  commit_tests.py 30: commit with a log message containing bad
data

EXPECTED STDERR:
ACTUAL STDERR:
svn: Working copy 'working_copies/merge_tests-12/A/B/E' locked
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
EXCEPTION: SVNLineUnequal
FAIL:  merge_tests.py 12: diff after merge that creates a new file

[4] These errors occured when I ran the build manually on merulo

http://people.debian.org/~dwhedon/tests.log.2

Unequal Types: one Node is a file, the other is a directory
EXCEPTION: SVNTreeUnequal
FAIL:  merge_tests.py 14: merge into missing must not break working
copy

IOError: [Errno 2] No such file or directory: 'repositories/autoprop_tests-11/conf/svnserve.conf'
FAIL:  autoprop_tests.py 11: import: config=no,  commandline=no


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: testsuite failues of 1.0.9 on GNU/Linux sparc/ia64

[Tristan Seligmann <tr...@quotemaster.co.za>]

On Mon, Oct 18, 2004 at 09:58:54AM -0500, kfogel@collab.net wrote:
> David Kimdon <dw...@debian.org> writes:
> > There is plenty of space on the filesystem.  The only oddity is that
> > the filesystem, at least in the cases where I ran the build manually
> > are a Linux 'bind' mount.  All the failures look like we have a broken
> > filesystem.
> 
> Is that like NFS, or something else?

You can mount an already visible directory tree onto another location by
doing:

    mount --bind /path/to/existing /path/to/newlocation

Vaguely like a sym/hardlink, but implemented in the VFS layer. I think this
is what he's referring to.
-- 
Tristan Seligmann
Software Engineer / Network Administrator

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: testsuite failues of 1.0.9 on GNU/Linux sparc/ia64

[kf...@collab.net]

David Kimdon <dw...@debian.org> writes:
> There is plenty of space on the filesystem.  The only oddity is that
> the filesystem, at least in the cases where I ran the build manually
> are a Linux 'bind' mount.  All the failures look like we have a broken
> filesystem.

Is that like NFS, or something else?

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org