Did figure out that build 101 of Java 1.8 introduced support for the root CA that signed LetEncrypt’s CA; as well as support for some new certificate signing algorithms; and removal of some no longer trusted signing algorithms, so it could simply be that something is not trusted somewhere if using an older Java 1.8.
toggle quoted messageShow quoted text
On Oct 4, 2019, at 09:11, Bob Jacobsen <@BobJacobsen> wrote:
Matt, thanks for the PR.
I’m looking into this on Jenkins.
It _seems_ to be related to Jenkins still being standardized on a very early Java 8 JDK.
On Oct 4, 2019, at 4:24 AM, Matthew Harris <@mattharris> wrote:--
On Fri, Oct 4, 2019 at 08:43 AM, danielb987 wrote:
2019-10-04 08:33 skrev Matthew Harris:
Looks like the upstream job has failing tests since then so, yes,
So, we need to figure out what's causing the test failure and fix it.
Randall Wood is working on it.
Looks like that might be a different issue.
The test failure right now can be seen at:
I've put together what I think should resolve this in https://github.com/JMRI/JMRI/pull/7472 but we should really dig further into why local builds and Jenkins builds seem to end-up with different behaviours with the compilation of `jmri.jmrit.XmlFile.dumpElement`: https://github.com/JMRI/JMRI/blob/master/java/src/jmri/jmrit/XmlFile.java#L281
Hopefully, once merged, this will resolve that specific test failure and allow packages to build again (other errors not withstanding).