sagax has quit [*.net *.split]
satyanash has quit [*.net *.split]
joast has quit [*.net *.split]
satyanash has joined #jruby
<kares[m]> but I need to think about it a bit more, atm I am trying to finish up some jossl improvements such as shipping with secure defaults and TLS 1.3
<kares[m]> think the openssl gem -> jruby-openssl dependency for the -java version would work.
joast has joined #jruby
subbu has joined #jruby
kroth_lookout[m] has joined #jruby
daveg_lookout[m] has joined #jruby
<kroth_lookout[m]> hey all, I'm having some serious issues as a result (I think) of the latest jruby-openssl release. the release notes indicate that support for java 1.7 was dropped but that 8 should still work, but I get a NoMethodError when I try to use gem install on jruby-9.2.19.0 (installed by rvm). Usually I'd just uninstall the offending gem version and reinstall an older one, but given I can't install gems....
<kroth_lookout[m]> Unhandled Java exception: java.lang.NoSuchMethodError: java.nio.ByteBuffer.limit(I)Ljava/nio/ByteBuffer;
<kroth_lookout[m]> gem install bundler -v 2.1.4 --no-document --source https://my-gem-source
<kroth_lookout[m]> java.lang.NoSuchMethodError: java.nio.ByteBuffer.limit(I)Ljava/nio/ByteBuffer;
<kroth_lookout[m]> * hey all, I'm having some serious issues as a result (I think) of the latest jruby-openssl release. the release notes indicate that support for java 1.7 was dropped but that 8 should still work, but I get a NoMethodError when I try to use gem install on jruby-9.2.19.0 (installed by rvm). Usually I'd just... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/ad8f260e67cbb367e256112e059f2c7222c197b3)
<kroth_lookout[m]> * hey all, I'm having some serious issues as a result (I think) of the latest jruby-openssl release. the release notes indicate that support for java 1.7 was dropped but that 8 should still work, but I get a NoMethodError when I try to use gem install on jruby-9.2.19.0 (installed by rvm). Usually I'd just... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/0d42824c34a742770e741bf686e163b4fae1dcff)
<kroth_lookout[m]> * hey all, I'm having some serious issues as a result (I think) of the latest jruby-openssl release. the release notes indicate that support for java 1.7 was dropped but that 8 should still work, but I get a NoMethodError when I try to use gem install on jruby-9.2.19.0 (installed by rvm). Usually I'd just... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/9d4c0661257403be94a383979c09e11a5741fb1f)
<kroth_lookout[m]> * hey all, I'm having some serious issues as a result (I think) of the latest jruby-openssl release. the release notes indicate that support for java 1.7 was dropped but that 8 should still work, but I get a NoMethodError when I try to use gem install on jruby-9.2.19.0 (installed by rvm). Usually I'd just... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/b80ed38604d06cf0587dd85b2f506b7880558af4)
<kovyrin[m]> Following up on the report above: while building our base CI image after install jruby 9.3.3.0 via RVM I am getting the following trying to run `/usr/share/rvm/rubies/jruby-$JRUBY_VERSION/bin/gem update --system $RUBYGEMS_VERSION --no-document`:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/abfefee31beb3908fb32b6c520d27fbafbd193cc)
<kovyrin[m]> s/up on//, s///
<kovyrin[m]> Just confirmed - it blows up like that on any gem install O_o
<kovyrin[m]> Feels like something is very broken somewhere, but I can't imagine openssl is broken for everybody, so probably my environment or maybe rvm is doing something bad to jruby during installation.
<kroth_lookout[m]> one of my coworkers reports you can do `gem install --local` if you download the gem separately
<kroth_lookout[m]> `jruby -S gem install ...` does not work for me though
<kroth_lookout[m]> * gem separately (which makes some sense since it wouldn't need to do https/ssl things if it's not doing a dl)
<kroth_lookout[m]> * me though (same failure as above)
<kroth_lookout[m]> * one of my coworkers reports you can do `gem install --local` if you download the gem separately (which makes some sense since it wouldn't need to do https/ssl things if it's not doing a dl) e.g.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/2872debfc35f66d85f5f244ddfad232d894c41fa)
<kroth_lookout[m]> * one of my coworkers reports you can do `gem install --local` if you download the gem separately (which makes some sense since it wouldn't need to do https/ssl things if it's not doing a dl) e.g.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/5e27a61c334772d87cf05572a5a6cadca670f116)
<headius> Hey there
<headius> kroth_lookout: hmm that would mean a version mismatch and it can't find a method it is looking for. Possibly we changed something in JRuby that jruby-openssl is using
<headius> But clearly 9.3.3 works with the certain of jruby-openssl we shipped
<headius> You might try downloading latest version gem and installing locally, that may fix it for you
<headius> File a bug if it does not and let me know
jtarvydas[m] has joined #jruby
<jtarvydas[m]> Hi there - this jetty bug looks similar: https://github.com/eclipse/jetty.project/issues/3244 - The issue there was that compiling with JDK 9+ produced bytecode incompatible with JDK 8, even when source/target were set to 1.8. I suspect that's the case here (ByteBuffer.limit is definitely in java 8's API). The fix here might be to add `release => 8` to the compiler options in jruby-openssl's Mavenfile (although I haven't had time to
<jtarvydas[m]> validate any of this locally yet)
<headius> jtarvydas: You are correct about that first error, that looks like jruby-openssl was build with Java 9 or higher without -release 8 so it used those newer method signatures
<kroth_lookout[m]> fwiw: i'm trying 9.3.3 but installing it via rvm is taking an awfully long time to complete `jruby-9.3.3.0 - #importing gemset /Users/kroth/.rvm/gemsets/jruby/global.gems`
<headius> the other error about is on our own RubyArray class and we must have changed it some time after the jruby-openssl version that kroth_lookout has installed (in a global gemset maybe?)
<headius> that first error should be reported on jruby-openssl and we just need to rebuild an x.x.x.1 release with Java 8 to fix it
<kroth_lookout[m]> oh finished, slightly different error on 9.3.3:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/2cd518c302c62c763b3c1e85e9e728d6c7e48a8c)
<headius> the second error should be fixed by a newer jruby-openssl but that may be the one that's built with Java 9 😀
<kroth_lookout[m]> s/https://artifactory.prod.lkt.is/artifactory/api/gems/lookout-gems//etc/
<headius> not sure when this RubyArray.collect method would have changed 🤔
<kroth_lookout[m]> * oh finished, slightly different error on 9.3.3:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/3665090acee452dff51f77f242bf5469c8d61ac3)
<headius> aha
<headius> kroth_lookout: so the first error with the buffer thing was jruby 9.2.19.0
<kroth_lookout[m]> that's right. we still have a number of projects on 9.2.x
<headius> whatever version of jruby-openssl is installed in that one is probably compiled against Java 9+
<headius> so a newer jruby-openssl on that one might help
<headius> for the 9.3.3.0 error there's a different issue, it is using a jruby-openssl that compiled against a different version of that method
<headius> need to figure out what version of jruby-openssl is being used in each case
<kroth_lookout[m]> we only started getting the 9.2 error with jruby-openssl 0.12 afaict... let me see if I can confirm that's what comes in from rvm install
<kroth_lookout[m]> * 0.12 afaict (based on timing)... let
<kroth_lookout[m]> * 0.12 afaict (based on timing, this wasn't a problem yesterday)... let
<headius> aha
<headius> so that is a bug then, 0.12 was built with Java 9 and uses methods that don't exist in 8
<headius> jruby-openssl bug, easy to remedy
<headius> kares: ^
<headius> the other one is more peculiar... RubyArray.collect does not appear to have changed substantially since 2020, so you would have to be using a jruby-openssl older than that probably
<kroth_lookout[m]> i just did rvm install jruby-9.3.3.0, so whatever comes with that :)
<headius> that is likely the offending commit... return value changed from RubyArray to IRubyObject
<headius> that was merged in Apr 2020 for Ruby 2.6 features of JRuby 9.3
<headius> kroth_lookout: is this you? https://github.com/jruby/jruby/issues/7048
<kroth_lookout[m]> headius: nope
<headius> oh I see
<kroth_lookout[m]> but close enough i think
<headius> this version was just released
<headius> today!
<kroth_lookout[m]> yeah
<headius> and now we are getting the bugzies
<headius> ok we will get a rerelease of this.. until then you should just roll back
<kroth_lookout[m]> uh the rolling back is a little difficult as it gets packaged with rvm install
<headius> and rvm is installing whatever is the latest
<headius> you know what, I think I can yank it
<kroth_lookout[m]> one of my coworkers reports you can do `gem install --local` if you download the gem separately (which makes some sense since it wouldn't need to do https/ssl things if it's not doing a dl) e.g.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/621da4029681c535999782b39a946518e73a4891)
<headius> the jossl releases are pushed by kares but I should have rights to yank
<headius> I'm going to do it!
<headius> 💪
<headius> ok the deed is done
<headius> kroth_lookout: if you dump and reinstall it should pull the older gem now and work ok
<headius> I will file an issue with jruby-openssl to get a newly built release of 0.12.0
<headius> and also address that binary incompatibility with 9.2
<kroth_lookout[m]> 👍️
<headius> transfered this one from jruby bugs: https://github.com/jruby/jruby-openssl/issues/244
<headius> I'll file the RubyArray issue separately
<headius> le sigh
<headius> sad thing is if we fix it back to the old signature it will still be broken on 9.3.0/1/2/3 so we need to patch jruby-openssl to work around it
<kroth_lookout[m]> just confirming the yank has put things back to normal for me, thanks very much headius
subbu has quit [Ping timeout: 240 seconds]
<ahorek[m]1> headius: any thoughts about https://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compiler-release.html flag? it should prevent binary incompatible releases like https://github.com/jruby/jruby-openssl/issues/244
<ahorek[m]1> recently we had a very similar problem that lead to https://github.com/rake-compiler/rake-compiler/pull/201
<ahorek[m]1> I've tried it on the main repository, but it complains about using unsafe ```/jruby/core/src/main/java/org/jruby/util/StringSupport.java:[56,15] error: package sun.misc does not exist``` https://bugs.openjdk.java.net/browse/JDK-8214165
<headius> ahorek: ah very nice, so we don't have to have special config for 8 vs 9
<headius> yes good idea
<headius> I will probably use this in jnr-* too because they have to be built for release with 9 but still support 8 (I have just conditionally added -release for now)
<ahorek[m]1> it turns out to be a cleaner solution then https://github.com/headius/backport9/blob/master/src/main/java/com/headius/backport9/buffer/Buffers.java#L35 maybe it could work simply just by adding the flag on smaller repositories like jopenssl
<ahorek[m]1> s/then/than/
<headius> I think we could add it to any of our repositories without any risk
<headius> I would like to get rid of that backport logic anyway