Bug 1858075

Summary: py4j fails to build with java-11-openjdk
Product: [Fedora] Fedora Reporter: jiri vanek <jvanek>
Component: py4jAssignee: Raphael Groner <projects.rg>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: rawhideCC: decathorpe, java-maint-sig, jvanek, projects.rg, sgehwolf
Target Milestone: ---Keywords: Patch, Triaged
Target Release: ---   
Hardware: All   
OS: All   
URL: https://src.fedoraproject.org/rpms/py4j/pull-request/3
Whiteboard: TrivialFix
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-09-04 11:43:45 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1825969    
Attachments:
Description Flags
build.log none

Description jiri vanek 2020-07-16 21:48:11 UTC 
py4j fails to build with java-11-openjdk as sytem JDK. See https://fedoraproject.org/wiki/Changes/Java11 .
See especially part about known failures: https://fedoraproject.org/wiki/Changes/Java11#common_issues_packagers_can_face_and_gathered_solutions

For the build logs, see: https://koji.fedoraproject.org/koji/taskinfo?taskID=47161542
We run the rebuild longer then 10days ago. Log may be gone. Also your package may be passing in regular rawhide.
To reproduce, simply: fedpkg clone py4j; cd py4j;  fedpkg build --target f33-java11; #The target is crucial.

We run two reruns your package failed both.


We had tried 650 packages, and 500 had passed, so the java-11-openjdk will be system JDK in f33, and you should fix your package if you want to keep it alive. Usually the fix is simple, and best is to update the package to latest upstream version.
There will be usual mass rebuild once f33 branches. You may got another FTBFS bug.
Let us know here if you have any questions, here in bug, or at java-devel.org .

We'd appreciate help from the people who know this package best, but if you don't want to work on this now, let us know so we can try to work around it on our side if needed.
Comment 1 jiri vanek 2020-07-17 04:03:17 UTC 
highlight: This was rebuild in sidetag f33-java11. Thus --target is really necessary to reproduce failure.
please note: This side tag, f33-java11, will be merged to main f33 buildroot in aprox 14 days.
Comment 2 Raphael Groner 2020-07-21 15:56:37 UTC 
Created attachment 1701932 [details]
build.log
Comment 3 Raphael Groner 2020-07-21 15:57:33 UTC 
Relevant snippet from build.log:

  [javadoc] Constructing Javadoc information...
  [javadoc] javadoc: error - Error fetching URL: http://java.sun.com/javase/6/docs/api/

Obviously a bug in javadoc.
Comment 4 Fabio Valentini 2020-07-21 16:04:13 UTC 
Uh ... that javadoc error is non-fatal and the build continues after that.
I'm looking at the attempted build for the Java 11 mass rebuild, and there the failure is actually in the test suite:

    [junit] ------------- ---------------- ---------------
    [junit] Testsuite: py4j.GatewayServerTest
    [junit] Tests run: 5, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.35 sec
    [junit] 
    [junit] Testcase: testAuthentication(py4j.GatewayServerTest):	FAILED
    [junit] null
    [junit] junit.framework.AssertionFailedError
    [junit] 	at py4j.GatewayServerTest.testServerAccess(GatewayServerTest.java:201)
    [junit] 	at py4j.GatewayServerTest.testAuthentication(GatewayServerTest.java:156)
    [junit] 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    [junit] 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    [junit] 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    [junit] 
    [junit] 
BUILD FAILED
/builddir/build/BUILD/py4j-0.10.9/py4j-java/build.xml:141: Test py4j.GatewayServerTest failed

https://koji.fedoraproject.org/koji/taskinfo?taskID=47161590 / build.log
Comment 5 Fabio Valentini 2020-07-21 16:07:01 UTC 
Removing line 164 from py4j-java/build.xml should silence the failure to get Java 6 docs from the internet:

	<target name="javadoc">
        <javadoc access="protected" author="true" classpath="" destdir="${javadoc.dir}" doctitle="Py4J" nodeprecated="false" nodeprecatedlist="false" noindex="false" nonavbar="false" notree="false" packagenames="py4j,py4j.examples,py4j.commands,py4j.reflection,py4j.model" source="1.6" sourcepath="src/main/java:src/test/java" splitindex="true" use="true" version="true">
=>            <link href="http://java.sun.com/javase/6/docs/api/"/>
        </javadoc>
    </target>
Comment 6 Raphael Groner 2020-07-22 04:11:14 UTC 
Both errors are non-fatal and can get ignored because properly handled.

Comment 4:
Looking into sources, this GatewayServerTest seems useless for jdk11 as the invalid token gets detected inside core functionality. No idea what happened with jdk8 instead to need this especially.

Comment 5:
Fetching the java 6 documentation isn't critical, right.
Comment 7 Ben Cotton 2020-08-11 15:24:36 UTC 
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle.
Changing version to 33.
Comment 8 Raphael Groner 2020-09-03 09:57:20 UTC 
Pull request: https://src.fedoraproject.org/rpms/py4j/pull-request/3
Comment 9 Fabio Valentini 2020-09-04 07:14:46 UTC 
Note that if py4j compiles with my PR (which it did), it should also compile fine without it (see the build during the mass rebuild).
If there was a real FTBFS issue with Java 11, it seems to have been resolved already in another place (or it was isolated to COPR and doesn't happen in koji).
Comment 10 Raphael Groner 2020-09-04 11:24:35 UTC 
> it should also compile fine without it

For what is this PR then? Obviously not to fix the originally reported FTBFS. Confusing, what should I do? Following my comment #6, it's sufficient to disable both pieces of sources mentioned.
Comment 11 Raphael Groner 2020-09-04 11:43:45 UTC 
Closing due to comment #3 mentions the cause.