Created on 2018-10-21.12:59:47 by jeff.allen, last changed 2018-10-26.18:18:36 by jeff.allen.
|msg12148 (view)||Author: Jeff Allen (jeff.allen)||Date: 2018-10-21.12:59:45|
In test_ssl I notice that in a couple of places we have disabled tests when running on Java 9 or beyond (in BasicSocketTests.test_errors and ContextTests.test_load_cert_chain). I am experiencing what looks to be the same failure in test_socket_jy (on Java 9) in SSLSocketConnectTest.test_connect_ex_workout . test_ssl contains the comment: # Possible FIXME similar issue as seen in # test_load_cert_chain - apparently this RSA 1024 cert is too weak and gets a # java.security.KeyStoreException: Key protection algorithm not found before the # ValueError raised on earlier versions of Java; # but we need to confirm this is truly the case on Java 9 (The test is supposed to raise a ValueError but fails creating the socket, I think.) I'm raising it as an issue here so we do not just forget it. I cannot tell yet whether this is just a problem with the test material or a real problem in use.
|msg12149 (view)||Author: Stefan Richthofer (stefan.richthofer)||Date: 2018-10-21.14:05:34|
Is this related to failing Travis CI on OSX? Currently in Travis CI significantly more tests fail on OSX than on Linux. On Linux only test_urllib2net fails while on OSX we get: [exec] 10 tests failed: [exec] test_codecencodings_tw test_dict test_dict_jy test_import_jy [exec] test_os_jy test_re_jy test_signal test_socket_jy test_ssl [exec] test_unicode_jy See https://travis-ci.org/jythontools/jython/jobs/433951090. Just asking because the log complains a lot about certs and test_ssl is also failing here.
|msg12151 (view)||Author: Jeff Allen (jeff.allen)||Date: 2018-10-21.16:53:33|
I would say so. "platform: java10.0.1" is the clue. The list is the same that I see (or saw) on Java 9. I hadn't noticed we were testing on 9+ *<:( I have eliminated some of these failures this weekend, and the ugly reflective access warnings (except from jnr.posix). I have a couple more in my sights, then will push as a batch to save possible merges. Another thing to mention is that the idiom: if support.get_java_version() < (1, 9): will not work reliably, so test_ssl (it appears) is not skipping the problematic code. But this also is fixed on my repo. Do we intend to test on 10? I think this has happened because we allow it to choose the default Java. It's useful to see, but it will be red for a while. Or rather, given our CI *is* running on versions 9+, we should make it run cleanly by skipping (and raising an issue). I can easily do that, and for a couple of them, fixing them is as quick.
|msg12154 (view)||Author: Stefan Richthofer (stefan.richthofer)||Date: 2018-10-21.19:36:18|
Alright, I had overlooked "platform: java10.0.1", just saw OSX platform. Java 9+ is of course an enlightening explanation for the additional failures.
|msg12160 (view)||Author: Jeff Allen (jeff.allen)||Date: 2018-10-26.18:18:35|
Skipped on Java 9+ for now in: https://hg.python.org/jython/rev/5aa64ce0b8b8
|2018-10-26 18:18:36||jeff.allen||set||messages: + msg12160|
|2018-10-21 19:36:18||stefan.richthofer||set||messages: + msg12154|
|2018-10-21 16:53:33||jeff.allen||set||messages: + msg12151|
messages: + msg12149
Supported by Python Software Foundation,
Powered by Roundup