Bug#635181: subversion: javahl BasicTests.testLogDate fails (expected:1191466852134992 but was:1191423652134992)
Hi,
Peter Samuelson wrote:
The Subversion high-level Java bindings ('javahl') in Debian have gone
through 3 different compilers (Jikes, Kaffe, and now gcj) and none of
them could make all the tests pass.
[etc]
Thanks for explaining.
What is the state of the
Java build and runtime world? Last I heard, gcj could target some sort
of native code, not just JVM bytecode. Does that mean it's still
better than Oracle's offering, or does nobody care?
The subversion packaging takes advantage of that iiuc, so I don't
think it's important.
As Michael mentioned, the default jdk in Debian on most arches is
openjdk now. Looking over the java policy in
/usr/share/doc/java-common/ and http://bugs.debian.org/548755 I am
still left with some questions about how to use it (e.g., where the
5 comes from in the dependency on java5-runtime-headless and whether
it is is right). So the following it just a sketch.
Next step will be to read over the test and make sure openjdk's answer is
really the right one.
Thanks for keeping subversion in good shape all these years. :)
---
diff --git a/debian/control b/debian/control
index b46834be..b12600b5 100644
--- a/debian/control
+++ b/debian/control
@@ -11,7 +11,7 @@ Build-Depends: debhelper, libneon27-gnutls-dev,
libserf-0-0-dev (= 0.3.0-0.2),
quilt, doxygen, autotools-dev, autoconf, libtool, swig,
python-all-dev, python-support,
perl, libperl-dev, ruby1.8, ruby1.8-dev,
- gcj-jdk (= 4:4.4) [!alpha !arm !hppa !m68k !mips !mipsel
!hurd-i386],
+ default-jdk [!alpha !arm !hppa !m68k !mips !mipsel !hurd-i386],
junit [!alpha !arm !hppa !m68k !mips !mipsel !hurd-i386]
Build-Conflicts: libsvn-dev ( 1.7~)
XS-Python-Version: = 2.4, 3.0
@@ -117,7 +117,7 @@ Description: Assorted tools related to Subversion
Package: libsvn-java
Section: java
Architecture: any
-Depends: gij | java5-runtime-headless, libsvn1 (= ${binary:Version}),
${shlibs:Depends}
+Depends: default-jre | java5-runtime-headless, libsvn1 (= ${binary:Version}),
${shlibs:Depends}
Description: Java bindings for Subversion
This is a set of Java classes which provide the functionality of
libsvn, the Subversion libraries. It is useful if you want to, for
diff --git a/debian/patches/java-build b/debian/patches/java-build
index 23a5bbf4..fa7acfdd 100644
--- a/debian/patches/java-build
+++ b/debian/patches/java-build
@@ -16,14 +16,20 @@ javah, symbols in a nested class use _ as a separator
instead of _00024.
[ps, 2010-11-08: Refresh to apply to trunk r1032687 (new makefile
generation system).]
+[jn, 2011-07-26: Allow openjdk, too.]
+
--- a/build/generator/templates/makefile.ezt
+++ b/build/generator/templates/makefile.ezt
-@@ -90,7 +90,8 @@
+@@ -90,7 +90,12 @@
[if-any target.headers][target.varname]_CLASS_FILENAMES =[for
target.header_class_filenames] [target.header_class_filenames][end]
[target.varname]_CLASSES =[for target.header_classes]
[target.header_classes][end]
$([target.varname]_HEADERS): $([target.varname]_CLASS_FILENAMES)
- [target.link_cmd] -d [target.output_dir] -classpath
[target.classes]:$([target.varname]_CLASSPATH) $([target.varname]_CLASSES)
-+ [target.link_cmd] -d [target.output_dir] -classpath
[target.classes]:$([target.varname]_CLASSPATH) -all [target.classes]
++ if [target.link_cmd] -all --help /dev/null 21; then \
++ [target.link_cmd] -d [target.output_dir] -classpath
[target.classes]:$([target.varname]_CLASSPATH) -all [target.classes]; \
++ else \
++ [target.link_cmd] -d [target.output_dir] -classpath
[target.classes]:$([target.varname]_CLASSPATH) $([target.varname]_CLASSES); \
++ fi
+ cd [target.output_dir]; sed -i s/_00024/_/ *.h
[end][if-any target.sources][target.varname]_SRC =[for target.sources]
[target.sources][end]
$([target.varname]_OBJECTS): $([target.varname]_SRC)
diff --git a/debian/rules b/debian/rules
index 977f3c73..8f35102f 100755
--- a/debian/rules
+++ b/debian/rules
@@ -94,7 +94,7 @@ export DH_OPTIONS
ifdef DEB_OPT_WITH_JAVAHL
# jikes 1.22 cannot compile javahl.
confflags += --enable-javahl --without-jikes \
- --with-jdk=/usr/lib/jvm/java-gcj \
+ --with-jdk=/usr/lib/jvm/default-java \
--with-junit=/usr/share/java/junit.jar
else
DH_OPTIONS += -Nlibsvn-java
--
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#635181: subversion: javahl BasicTests.testLogDate fails (expected:1191466852134992 but was:1191423652134992)
[Jonathan Nieder]
| There was 1 failure:
| 1)
testLogDate(org.tigris.subversion.javahl.BasicTests)junit.framework.AssertionFailedError:
expected:1191466852134992 but was:1191423652134992
|at
org.tigris.subversion.javahl.BasicTests.testLogDate(BasicTests.java:91)
|at org.tigris.subversion.javahl.RunTests.main(RunTests.java:111)
Is the problem known? Is it Debian-specific? debian/rules says
# This fails on current free JVMs, according to Blair Zajac.
# Thus the - prefix, to ignore failure, for now.
Is it a JVM bug? Inquiring minds want to know. :)
The Subversion high-level Java bindings ('javahl') in Debian have gone
through 3 different compilers (Jikes, Kaffe, and now gcj) and none of
them could make all the tests pass. Oracle's OpenJDK implementation
apparently works, so this failure is presumably either a gcj or Java
runtime bug, or an ambiguity in the standard. Ubuntu switched over to
OpenJDK some time ago (before OpenJDK was in Debian, unsurprisingly),
but I've never found the energy to care enough about the Java stuff to
apply the Ubuntu patch to switch Debian's Subversion to use OpenJDK. I
don't know if it's even a good idea to do so. What is the state of the
Java build and runtime world? Last I heard, gcj could target some sort
of native code, not just JVM bytecode. Does that mean it's still
better than Oracle's offering, or does nobody care?
By the way, big thanks for your attention to the Subversion packaging
of late,
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#635181: subversion: javahl BasicTests.testLogDate fails (expected:1191466852134992 but was:1191423652134992)
On 2011-07-25 18:24, Peter Samuelson wrote:
[Jonathan Nieder]
| There was 1 failure:
| 1)
testLogDate(org.tigris.subversion.javahl.BasicTests)junit.framework.AssertionFailedError:
expected:1191466852134992 but was:1191423652134992
|at
org.tigris.subversion.javahl.BasicTests.testLogDate(BasicTests.java:91)
|at org.tigris.subversion.javahl.RunTests.main(RunTests.java:111)
Is the problem known? Is it Debian-specific? debian/rules says
# This fails on current free JVMs, according to Blair Zajac.
# Thus the - prefix, to ignore failure, for now.
Is it a JVM bug? Inquiring minds want to know. :)
The Subversion high-level Java bindings ('javahl') in Debian have gone
through 3 different compilers (Jikes, Kaffe, and now gcj) and none of
them could make all the tests pass. Oracle's OpenJDK implementation
apparently works, so this failure is presumably either a gcj or Java
runtime bug, or an ambiguity in the standard. Ubuntu switched over to
OpenJDK some time ago (before OpenJDK was in Debian, unsurprisingly),
but I've never found the energy to care enough about the Java stuff to
apply the Ubuntu patch to switch Debian's Subversion to use OpenJDK. I
don't know if it's even a good idea to do so.
Unfortunately, Debian promoted the GNU/kFreeBSD port a while ago, which
does not have OpenJDK. Previously, I used to provide backports for
Debian stable built with OpenJDK.
http://wiki.debian.org/Java
OpenJDK
A GPL2 version of Sun's JDK!
Available on most archs.
Installed by default where available.
GNU's GIJ/GCJ
Installed by default when openjdk is not available.
What is the state of the
Java build and runtime world? Last I heard, gcj could target some sort
of native code, not just JVM bytecode. Does that mean it's still
better than Oracle's offering, or does nobody care?
I believe OpenJDK will be the reference implementation for Java 7. Does
the native code feature in gcj matter at all for the Subversion Java
bindings? I don't think GIJ/GCJ has much to offer.
(I wouldn't mind supporting GIJ/GCJ as a special case for architectures
that still don't have OpenJDK.)
--
Michael Diers, elego Software Solutions GmbH, http://www.elego.de
signature.asc
Description: OpenPGP digital signature
Bug#635181: subversion: javahl BasicTests.testLogDate fails (expected:1191466852134992 but was:1191423652134992)
Source: subversion Version: 1.6.17dfsg-1 Severity: minor Justification: cosmetic Tags: upstream When building subversion from source, I see | /usr/lib/jvm/java-gcj/bin/java -Dtest.rootdir=/tmp/subversion-1.6.17dfsg/BUILD/subversion/bindings/javahl/test-work -Dtest.fstype= -Djava.library.path=subversion/bindings/javahl/native/.libs:/usr/lib -classpath subversion/bindings/javahl/classes:/usr/share/java/junit.jar -Dtest.tests= org.tigris.subversion.javahl.RunTests | ...FE.. | . | Time: 8.927 | There was 1 error: | 1) testBasicCatStream(org.tigris.subversion.javahl.BasicTests)java.lang.NullPointerException |at org.tigris.subversion.javahl.SVNClientSynchronized.streamFileContent(SVNClientSynchronized.java:1555) |at org.tigris.subversion.javahl.BasicTests.testBasicCatStream(BasicTests.java:1904) |at org.tigris.subversion.javahl.RunTests.main(RunTests.java:111) | There was 1 failure: | 1) testLogDate(org.tigris.subversion.javahl.BasicTests)junit.framework.AssertionFailedError: expected:1191466852134992 but was:1191423652134992 |at org.tigris.subversion.javahl.BasicTests.testLogDate(BasicTests.java:91) |at org.tigris.subversion.javahl.RunTests.main(RunTests.java:111) | | FAILURES!!! | Tests run: 50, Failures: 1, Errors: 1 | | make[2]: *** [check-javahl] Error 1 This report is about the failure (not the error). The error is not present in svn 1.7, so I'm not worried about it, but the failure remains and seems more interesting. Is the problem known? Is it Debian-specific? debian/rules says # This fails on current free JVMs, according to Blair Zajac. # Thus the - prefix, to ignore failure, for now. Is it a JVM bug? Inquiring minds want to know. :) Thanks, Jonathan $ dpkg-query -W gcj-jdk gcj-jdk 4:4.6.1-2 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
