lopex has quit [Quit: Connection closed for inactivity]
lopex has joined #jruby
lopex is now known as Guest82013
Guest82013 is now known as lopex
_whitelogger has joined #jruby
travis-ci has joined #jruby
<travis-ci> jruby/jruby (master:2866cd5 by Benoit Daloze): The build was broken. https://travis-ci.com/jruby/jruby/builds/218471278 [209 min 1 sec]
travis-ci has left #jruby [#jruby]
<travis-ci> jruby/jruby (master:0d34abb by Benoit Daloze): The build is still failing. https://travis-ci.com/jruby/jruby/builds/218471920 [202 min 55 sec]
travis-ci has left #jruby [#jruby]
travis-ci has joined #jruby
<travis-ci> jruby/jruby (master:040b142 by Benoit Daloze): The build is still failing. https://travis-ci.com/jruby/jruby/builds/218475091 [207 min 40 sec]
travis-ci has left #jruby [#jruby]
travis-ci has joined #jruby
nirvdrum has joined #jruby
travis-ci has left #jruby [#jruby]
travis-ci has joined #jruby
<travis-ci> jruby/jruby (master:52c21a2 by Benoit Daloze): The build was fixed. https://travis-ci.com/jruby/jruby/builds/218478954 [205 min 40 sec]
<nirvdrum> I'm trying to install JRuby on a new installation where Java 15 is the default. Do I really need to switch to Java 8 to install 9.2.15.0?
<headius[m]> Using the windows installer?
<headius[m]> JRuby works fine on 15
<nirvdrum> Using ruby-build. It explicitly checks for Java 8.
<headius[m]> That is a ruby-build issue then I guess
<headius[m]> Maybe they meant to require at least java 8? There is no requirement on our end
<headius[m]> I mean other than 8+
<nirvdrum> Okay. I could have sworn I had installed other 9.2.x releases with > 8, but was wondering if I had that wrong.
<headius[m]> That seems to do a less than check
<nirvdrum> So, I took that as some new requirement I overlooked. Changing to "require_java 15" fails. I didn't look too much, but I think the version string format inspection doesn't work quite right. Removing the line entirely got 9.2.15.0 installed.
<nirvdrum> This check seems unnecessary to me. I can't imagine anyone installing JRuby would be unaware they need a JVM set up. And even then, it'd fail when trying to invoke it, which ought to be fairly obvious.
<headius[m]> Yeah file a bug with ruby-build I guess
<nirvdrum> Cool. Thanks for the clarification.
<headius[m]> Perhaps they do this check because they need to run jruby for part of the installation
<headius[m]> So not having Java at all would fail halfway through
<nirvdrum> I think it just unpacks the tarball.
<nirvdrum> Heh. Booting this old JRuby + TorqueBox project is a pain in the neck. There were core library and even syntax changes reflected in 9k. 1.7.x doesn't work with newer Java releases.
<nirvdrum> I should probably bite the bullet and track down a Java 7 build.
<nirvdrum> It looks like the CA support in Java 8 doesn't handle the rubygems.org SSL certificate.
<headius[m]> There are 7 builds from a number of sources
<headius[m]> Wish we could have kept TB going but the devs moved to other projects. To much for just two of us to handle
<nirvdrum> Well, booting a project that hasn't been booted in six years can't be a terribly common use case. I guess I had hoped that being Java-based, this would have gone smoother. I'm a bit constrained by this crazy old version of sidekiq-pro I have cached because I can't download any other versions and I must have downloaded that early into my work on JRuby+Truffle, since I had set it up with JRuby 9.0.5.0. But, I can't get that to communicate with
<nirvdrum> rubygems.org due to the aforementioned SSL issue. Updating to work with JRuby 9.2 is just requiring a bunch of changes, including one to the internals of TorqueBox.
<nirvdrum> And I don't know when it happened, but at some point Bundler did something different with its dependency resolution, so the TorqueBox gems don't resolve correctly. It sees "3.1.0" and "3.1.0-java" as different, but that's how the graph resolves. I had to roll back to Bundler 1.10 to get past that or keep manually modifying the Gemfile.lock.
<headius[m]> Hmm that is odd. What exactly is the ssl issue?
<nirvdrum> I haven't dug too deeply into it, but I see this when running "rbenv install 9.0.5.0":
<nirvdrum> ERROR: Could not find a valid gem 'jruby-launcher' (>= 0), here is why:
<nirvdrum> Unable to download data from https://rubygems.org/ - Received fatal alert: handshake_failure (https://api.rubygems.org/specs.4.8.gz)
<nirvdrum> A quick search brought me to a similar issue a Logstash user had: https://github.com/rubygems/rubygems/issues/4150
<nirvdrum> Bumping from TorqueBox 3.1.0 to 3.2.0 might get me part of the way there, but the CloudBees URL for the 3.2.0 dist is dead.
<nirvdrum> Oh well. I suppose this is a fool's errand.
nirvdrum_ has joined #jruby
nirvdrum__ has joined #jruby
nirvdrum_ has quit [Read error: Connection reset by peer]
nirvdrum__ has quit [Remote host closed the connection]
<nirvdrum> Wow. I forgot about this one :-) https://github.com/jruby/jruby/issues/3622
_whitelogger has joined #jruby
nirvdrum has quit [Ping timeout: 245 seconds]
Freaky has quit [Quit: reboot]
Freaky has joined #jruby
<headius[m]> Ah yeah the handshake