On Fri, Nov 03, 2023 at 12:00:32AM -0400, Nathan Hartman wrote:
> On Mon, Oct 16, 2023 at 9:16 AM Daniel Sahlberg
> <[email protected]> wrote:
> >
> > Den sön 15 okt. 2023 kl 06:50 skrev Nathan Hartman
> > <[email protected]>:
> >>
> >> On Fri, Oct 13, 2023 at 1:58 PM Johan Corveleyn <[email protected]> wrote:
> >>>
> >>> On Fri, Oct 13, 2023 at 5:35 PM Stefan Sperling <[email protected]> wrote:
> >>> >
> >>> > On Fri, Oct 13, 2023 at 08:43:59AM +0200, Daniel Sahlberg wrote:
> >>> > > Hi,
> >>> > >
> >>> > > There are quite a number of improvements waiting to be released. Can
> >>> > > we
> >>> > > muster the energy to do a new release?
> >>> > >
> >>> > > In trunk there are a lot of changes that warrant a 1.15, but before
> >>> > > doing
> >>> > > that I think we should also go back to the discussion of changing the
> >>> > > /
> >>> > > adding a checksum algorithm in the WC. That deserves a separate
> >>> > > thread and
> >>> > > I'm half way through summarising the previous discussions so I'd like
> >>> > > to
> >>> > > hold back 1.15 for the moment.
> >>> > >
> >>> > > Still in 1.14 there have been a number of bugfixes that might be good
> >>> > > to
> >>> > > get released. Maybe doing 1.14.3 first could set us up to do 1.15 a
> >>> > > little
> >>> > > later?
> >>> >
> >>> > The first problem to solve before the ball starts rolling would be
> >>> > finding a release manager. I don't have enough spare time to play RM
> >>> > this time around but I would support the RM as far as my time allows
> >>> > for.
> >>> >
> >>> > Doing 1.14.3 first sounds like a good plan. This would help potential
> >>> > new releases managers to get bootstrapped into the process. A major
> >>> > release tends to involve a little bit more effort because some new
> >>> > problems
> >>> > may only show up on specific operating system platforms during -rc
> >>> > testing.
> >>>
> >>> +1
> >>>
> >>> --
> >>> Johan
> >>
> >>
> >>
> >> Hi all,
> >>
> >> I agree that a 1.14.3 release makes sense for a first-time RM, to be
> >> followed by a 1.15.0 at a later stage. (Also, there are some unresolved
> >> issues regarding 1.15.0, such as the above-mentioned question of checksum
> >> algorithms, that may require more development, but 1.14.3 should be much
> >> more straightforward.)
> >>
> >> At this moment I cannot promise to volunteer for this cycle but I will try
> >> to do so.
> >>
> >> Before I do, I need to get my system bootstrapped properly. I can build
> >> SVN and run most of the testsuite, but one pesky longstanding issue I have
> >> had is with the JavaHL bindings. That will require a separate thread and
> >> I'll describe the issues there. I'll check my notes to see what else might
> >> be a showstopper on my end.
> >
> >
> > I've successfully built and tested the JavaHL bindings at one point and I
> > think I can dig out my notes to help you if needed.
> >
> >>
> >>
> >> If I can get set up and solve the problems I've encountered previously in
> >> a reasonable time frame (and everyone's help is appreciated of course)
> >> I'll volunteer.
> >
> >
> > That would be great! I'd volunteer to do the next release after this.
> >
> > There were some Docker scripts floating around (Both from CMike and from
> > Mark). Maybe we should figure out if these can be included in /tools as a
> > help to set up the environment and to execute the necessary steps.
> >
> > Kind regards,
> > Daniel
>
>
> Hi all,
>
> Previously I mentioned I plan to RM for the upcoming 1.14.3 release.
> This being my first time, I need to solve some issues first.
>
> One of these, which has been a stumbling block for me since the
> beginning, is getting the JavaHL bindings to build and test
> successfully.
>
> I have made progress on this, but not a complete breakthrough yet.
>
> The progress was discovering that I need to have $JAVA_HOME set in my
> environment; without this, our build system (in build/ac-macros/java.m4)
> fails to find javac and assigns 'none' to JAVAC; then, much later,
> 'make check-javahl' tries to call this 'none', which unsurprisingly
> doesn't work. (I was surprised that the other logic in this AC_DEFUN
> couldn't find javac without $JAVA_HOME being set, but that's a subject
> for another thread.) The clue was the use of $JAVA_HOME there.
>
> I tried various values for $JAVA_HOME but nothing that seemed sensible
> worked; based on a StackOverflow answer [1], I ended up setting
> $JAVA_HOME as follows:
>
> $ export JAVA_HOME=$(readlink -f /usr/bin/javac | sed "s:/bin/javac::")
>
> On my system, this sets $JAVA_HOME to:
> /usr/lib/jvm/java-17-openjdk-amd64
>
> This value seems a little strange IMHO but it finally got 'configure' to
> find the JDK successfully and got me past the longstanding 'none'
> problem!
>
> But then I promptly ran into the next issue:
>
> [[[
>
> $ make check-javahl
> (snip)
> /usr/lib/jvm/java-17-openjdk-amd64/bin/java -Xcheck:jni
> "-Dtest.rootdir=/home/nathan/ramdrive/svndev/svn-1.14.x/subversion/bindings/javahl/test-work"
> "-Dtest.srcdir=/home/nathan/ramdrive/svndev/svn-1.14.x/subversion/bindings/javahl"
> "-Dtest.rooturl=" "-Dtest.fstype="
> "-Djava.library.path=:/home/nathan/ramdrive/svndev/prefix/svn-1.14.x/lib"
> -classpath
> "subversion/bindings/javahl/classes:/home/nathan/ramdrive/svndev/svn-1.14.x/subversion/bindings/javahl/src:"
> "-Dtest.cleanup=" "-Dtest.tests="
> org.apache.subversion.javahl.RunTests
> Error: Could not find or load main class org.apache.subversion.javahl.RunTests
> Caused by: java.lang.ClassNotFoundException:
> org.apache.subversion.javahl.RunTests
> make: *** [Makefile:530: check-apache-javahl] Error 1
>
> ]]]
>
> If I understand correctly, there should be a file called
> 'RunTests.class' in one of the directories specified with -classpath
> above. Well, there are other .class files to be found there, but not
> RunTests.class. A search for RunTests with any (or no) extension in the
> 1.14.x tree gives these two RunTests.java (not .class) files:
>
> $ find . -name RunTests\*
> ./subversion/bindings/javahl/tests/org/apache/subversion/javahl/RunTests.java
> ./subversion/bindings/javahl/tests/org/tigris/subversion/javahl/RunTests.java
>
> Forgive me if this is something obvious, but I know almost nothing about
> the Java ecosystem. :-)
>
> I'll have to continue this exploration tomorrow, but I'm at least glad
> to finally have made progress on a longstanding stumbling block.
>
> Meanwhile, any clues would be appreciated!
>
> [1] https://stackoverflow.com/a/29622512
>
> Cheers,
> Nathan
>
In my build script (in Subversion's tree at tools/dev/unix-build/) I pass the
following flags to Subversion's configure script if JavaHL is enabled:
--enable-javahl=yes --with-jdk --with-jikes=no \
--with-junit=$(DISTDIR)/$(JUNIT_DIST)
Did you also pass --with-junit?
For some reason I don't recall, my build script is fetching a self-hosted
junit JAR file from here: https://stsp.name/distfiles/junit-4.10.jar
(sha256: 36a747ca1e0b86f6ea88055b8723bb87030d627766da6288bf077afdeeb0f75a)
Given that you have self-compiled svn libraries in a non-standard prefix
you might also want to try setting LD_LIBRARY_PATH when invoking the tests.
Loading a wrong set of libsvn_*.so files would certainly cause issues, and the
ld.so runtime linker probably won't see JVM settings like -Djava.library.path.
env LD_LIBRARY_PATH="/home/nathan/ramdrive/svndev/prefix/svn-1.14.x/lib" \
make check-all-javahl
Hope this helps,
Stefan
