ur5us_ has quit [Read error: Connection reset by peer]
ur5us_ has joined #jruby
ur5us_ has quit [Ping timeout: 260 seconds]
ur5us_ has joined #jruby
ur5us_ has quit [Quit: Leaving]
_whitelogger has joined #jruby
jeremyevans has quit [*.net *.split]
michael_mbp has quit [*.net *.split]
michael_mbp has joined #jruby
jeremyevans has joined #jruby
michael_mbp has quit [Max SendQ exceeded]
michael_mbp has joined #jruby
<daveg_lookout[m]>
peacand: I just mentioned this issue to a friend who works on jruby+logstash at Elastic
<headius[m]>
ahorek: back in the office today
<headius[m]>
enebo: did you see ahorek issue?
<headius[m]>
ripper thing that might be easy to fix
<enebo[m]>
headius: no but I will check it out
<enebo[m]>
ahorek: you sure this is 2.6 and not earlier?
<headius[m]>
ahorek: a spec would be good, ripper specs are a bit thin
<headius[m]>
9.2 snapshot build have been failing, I will look into that today
<headius[m]>
peacand: I have not figured out why the snapshot deploy is failing in CI but my local deploy worked... there should be a new snapshot there now
<headius[m]>
I will look at that unixsocket issue now
<headius[m]>
enebo: if you can confirm that a full deploy works on your system I think I will just look into moving this to GHA rather than wrestling with Travis
<enebo[m]>
headius: I will try
subbu is now known as subbu|lunch
<headius[m]>
enebo: seems to work in GHA
<enebo[m]>
hmm
<enebo[m]>
I need to try again
<headius[m]>
I can't make it depend on Travis passing so it would deploy for every push to jruby-9.2 regardless
<enebo[m]>
it is stuck uploading jruby-core to sonatype
<enebo[m]>
but it could be a prompt for my key?
<headius[m]>
we have no GHA for 9.2 branch up to this point
<enebo[m]>
I did also update to FC33 yesterday
<headius[m]>
hmmm
<headius[m]>
well sonatype sucks sometimes
<headius[m]>
may be a glitch
<enebo[m]>
going to try from terminal instead of emacs shell
<headius[m]>
I am trying a deploy from GHA on a branch now
<enebo[m]>
but fwiw I got stuck in a different place than travis
<enebo[m]>
you might need to reinstall the gem which depends on the missing jar or in case there is Jars.lock then resolve the jars with `lock_jars` command
<enebo[m]>
no such file to load -- org/yaml/snakeyaml/1.18/snakeyaml-1.18 (LoadError)
<enebo[m]>
It almost looks like we are pulling in a newer version of some gem for jruby 1.7.22 and it is just confused
<enebo[m]>
although I do wonder if we should be using 9.x for our old stable release for this
<headius[m]>
yeah that extended job has been failing for years... perhaps we should accept that mkristian is not going to fix it
<enebo[m]>
trying at 69334b7b49f9c269f43192bcd5d78cfcfbb88b7a
<headius[m]>
enebo: fwiw CRuby 2.5 and 2.6 do not set racc as a default gem so I could revert this and just copy the bits in like before
<enebo[m]>
I think that was just before the racc merge
<headius[m]>
I just did it on 9.2 because we do it on master and it is fine
<headius[m]>
and because of that related report of our shipped racc b
<headius[m]>
being broken and not upgradable
<headius[m]>
I do not know why this breaks though so I am reluctant to just blindly revert
<headius[m]>
ahh right
<headius[m]>
so the reported issue is that parser depends on newer racc bits than we shipped in 9.2.14, and since racc is not a default gem you have to explicitly activate the gem to get newer bits
<headius[m]>
and loading parser does not explicitly load racc gem, so it falls back on shipped version that is not compatible
<headius[m]>
so just updating the bits is the minimum fix... making racc a default gem was bonus features of aligning with master and allowing users to upgrade it easily
<enebo[m]>
headius: worked commit before that landed
<headius[m]>
hmm ok
<headius[m]>
I am a little surprised either of these commits would cause it
<headius[m]>
I can revert the PR and just update the bits manually for 9.2.x
<headius[m]>
enebo: are you doing any more investigation or should I just go forward with some solutu