Subversion's been hitting test suite failures on mipsel, s390(x), and
the Hurd.  The Linux errors are new since 1.7.9-1, and may stem in
part from recent changes to build dependencies, whereas the Hurd
errors (less critical, as it's not a release architecture) date back
to 1.7.5-1:

https://buildd.debian.org/status/logs.php?pkg=subversion

Could you please take a look?

Thanks!

Hi,

Aaron M. Ucko wrote:

This now includes also amd64 and ia64. While ia64 is about to be
removed from Jessie IIRC, amd64 is the most popular architecture we
have.

The error on amd64 seems to be in the ruby-bindings test suite which
does not seem to cover potentially unsorted output:

/«PKGBUILDDIR»/subversion/bindings/swig/ruby/test/test_wc.rb:285:in `test_ancestry':
<[["/tmp/wc-tmp/wc", Svn::Error::Cancelled],
 ["/tmp/wc-tmp/wc/file1", Svn::Error::Cancelled],
 ["/tmp/wc-tmp/wc/file2", Svn::Error::Cancelled]]> expected but was
<[["/tmp/wc-tmp/wc", Svn::Error::Cancelled],
 ["/tmp/wc-tmp/wc/file2", Svn::Error::Cancelled],
 ["/tmp/wc-tmp/wc/file1", Svn::Error::Cancelled]]>.

(file1 and file2 in unexpected order)

I suspect that this can be fixed easily in the test itself in case the
order is really irrelevant in this test.

The error on ia64 is java-bindings related and is probably caused by a
newer Java version or maybe also different Java implementation:

The method getTag() from the type Version refers to the missing type String
----------
1016. ERROR in /«PKGBUILDDIR»/subversion/bindings/javahl/src/org/apache/subversion/javahl/types/Version.java (at line 83)
      private native String getTag();
                     ^^^^^^
String cannot be resolved to a type
----------
1017. ERROR in /«PKGBUILDDIR»/subversion/bindings/javahl/src/org/apache/subversion/javahl/types/Version.java (at line 89)
      private native String getNumberTag();
                     ^^^^^^
String cannot be resolved to a type
----------
1017 problems (1011 errors, 6 warnings)make[1]: *** [subversion/bindings/javahl/classes/org/apache/subversion/javahl/ClientException.class] Error 255
make[1]: Leaving directory `/«PKGBUILDDIR»/BUILD'
make: *** [debian/stamp-build-arch] Error 2

(No idea how to fix that. Probably someone with more Java experience
than me should have a look at.)

It's not clear to me what exactly caused the s390(x) build failures.
Looks like test suite failures in svn-test-work/working_copies, but
I'm not 100% sure as I can't pinpoint where the failure happened.

		Regards, Axel

Hi.

The problem on amd64 is discussed here.
http://subversion.1072662.n5.nabble.com/1-7-10-up-for-signing-testing-td181092.html

It seems that ordering is not significant, and I can fix the FTBFS
problem by applying a tiny patch.
I hope this patch helps you.

Peter had a fix for this staged in a 1.7.10-1 upload, closing #705364.
I'll pull that into a 1.7.9+nmu4 upload.

1.7.9+nmu2 built as did a test build I ran on merulo, so hopefully my
NMU will as well.

I'll leave this bug open for handling of the non-Ruby build failures,
but those seem to be flaky.

Cheers,

Control: severity -1 important
Control: retitle -1 subversion: FTBFS on hurd-i386

This has been uploaded and the only remaining build problems are on hurd
and s390x.  The s390x failure is a failing test due to the + in the
directory name (which doesn't happen with newer sbuild versions), so I'm
doing a manual build to get that uploaded.  This test is also getting
fixed upstream.

The only remaining failure is on hurd.  Since that's not a release
architecture, I'm lowering the severity.

Cheers,