<kares[m]>
regarding the jruby-openssl "regression" - hacked the .rb parts to resemble 0.11 (before the refactoring) -> allows jossl to work-around the autoload bug under 9.2
<kares[m]>
already pushed jruby-openssl 0.12.2 ... if there's a next 9.2 release than we should update the default gem
fidothe has quit [*.net *.split]
yosafbridge has quit [*.net *.split]
fidothe has joined #jruby
yosafbridge has joined #jruby
yosafbridge has quit [Max SendQ exceeded]
yosafbridge has joined #jruby
<headius>
That's great that you found a workaround in the gem. You can update the jruby branches any time but not sure when we will put out a new 9.2
subbu has joined #jruby
subbu has quit [Quit: Leaving]
<kares[m]>
okay - no rush on my end for anything 9.2
<kares[m]>
how's the 9.4 progress, you guys seem super busy 😉
<kares[m]>
s/,/?/
<headius>
coming along well... need to start running real apps but the net-http ssl stuff is a bit of a blocker
<headius>
ruby compat is good, most of the work I have been doing is in getting all the default gems working
<headius>
enebo: can you reproduce any of these sh-related failures locally?
<headius>
running spec/ruby/language/magic_comment_spec.rb might do it but a full rake-launched run may be necessary
<enebo[m]>
headius I will try
<enebo[m]>
raw command-line is no issue
<enebo[m]>
ok after the bisect my current dir is broken because it cannot find optparse
<enebo[m]>
doing a clean build to make sure
<headius>
should be coming from gem
<enebo[m]>
yeah hopefully I see it install
<enebo[m]>
I see it scroll by on build
<headius>
the syntax errors we see in the CI run appear to indicate something is trying to run bin/jruby as Ruby code
<enebo[m]>
so ruby_exe is somehow not really doing sh but ruby
<headius>
before I added the quotes it was a similar error
<enebo[m]>
but if you revert the sh commit does it work again?
<headius>
I am wondering if the argument munging in those commits is somehow feeding the jruby script back to itself
<enebo[m]>
I guess commiting with the show me everything option to sh will show something like that (and also create a lot of failing tests with extra stderr output)
<enebo[m]>
At least I think it will show expanded values
<headius>
yeah not sure what option to turn on to show this... I see no code in mspec to log the command output or the actual errors the subcommand dumps
<enebo[m]>
I know it also can show ${foo} ${bar} and not the expansion
<headius>
I have not tried to revert because I can't reproduce locally so far
<enebo[m]>
I am trying full spec:ruby:fast locally
<headius>
oh hey before that gets too far make sure bin/jruby and bin/jruby.sh are the same
<headius>
I forget whether the copying always happens or if it skips it if bin/jruby is already there
<headius>
I'm making sure here and will also try a rake run
<enebo[m]>
they are the same
<headius>
ok
<enebo[m]>
I keep wondering if ci defines some of the env values in a significantly different way than how we have things defined in our envs
<enebo[m]>
like absolute vs relative path
<enebo[m]>
or extra env we do not have set which does something a tad differently which hits whatever is wrong
<enebo[m]>
but what you say would make sense that it passes $0 as one of the last arguments which it interprets as a Ruby file
<enebo[m]>
ruby file1 file2 sort of thing
<headius>
yeah that is just a guess
<headius>
but the sh script is definitely getting parsed by us somehow
<enebo[m]>
Since it happens on the commit for an sh script and we see it trying to ruby interp the sh script I think it is an extremely solid guess :)
<enebo[m]>
unless we set some variable which JRuby internally thinks is a ruby script
<enebo[m]>
but that is just a variant of what you said
<headius>
I do not seem to be getting the same errors locally
<enebo[m]>
Magic comments in an -e argument must be the first token of the line FAILED
<enebo[m]>
Expected "" == "UTF-8"
<enebo[m]>
to be truthy but was false
<headius>
you got it!
<enebo[m]>
I do not remember these
<headius>
are there some that say exit code 1 too?
<enebo[m]>
Oh so I will not see error 1
<headius>
I do not get any of those locally, which makes sense because they would have gotten tagged accidentally
<headius>
that error you have just checks the output so it doesn't notice the process failed
<enebo[m]>
I even got these from mspec directly
<headius>
it just has no stdout
<enebo[m]>
I will see what I can see
<headius>
yeah ok
<enebo[m]>
I like your theory so much I will prove it
<enebo[m]>
Not the fastest tests to run but I suppose I can interrupt on first fail
<headius>
you can force the script to dump environment every time it runs
<enebo[m]>
I have to say this is very interesting...does the sh stuff get confused by '#'?
<headius>
it shouldn't
<enebo[m]>
how the hell is this even running this
<headius>
what do you mean though
<headius>
look for ruby_exe.rb in mspec for some of them
<headius>
others just popen
<enebo[m]>
@object.call('case_magic_comment.rb')
<headius>
oh yeah the shared crap
<headius>
the top part of that file just runs in each context in the lower part
<enebo[m]>
I want to focus on this one since it is seemingly just executing the file
<headius>
all they really do is change the magic_comment file it checks
<headius>
Yes some use an intermediate script and pipe the other script in and others just run it directly I think
<enebo[m]>
This is interesting because when run from mspec without the echo it is "" == "Big5"
<enebo[m]>
It follow use_exec path
<headius>
Hmm
<enebo[m]>
I realized I was not putting JRUBY_STATUS echo in right place and then it never printed
<enebo[m]>
HEH...although now thatI comment that out I am seeing the same error
<headius>
mrnoname is on his way
<enebo[m]>
"Big50
<enebo[m]>
" == "Big5"
<enebo[m]>
So this is pretty weird to me. I am not seeing return 1 but I am seeing full output if I output anything
<headius>
Hah that definitely looks like the loop variable quoting
<enebo[m]>
that 0 is me echoing at end of script
<enebo[m]>
It is like it is flushing the output
<headius>
Oh nevermind then
<enebo[m]>
if no echo is there this becomes "" == "Big5"
<headius>
Yeah that is pretty strange
<headius>
I did recently change how some subprocess streams are handled but all I did was remove cloexec
<headius>
And only for streams that were intended to be inherited in the child
<headius>
Oh and that might not be merged yet anyway
<headius>
Hmm
mrnoname1000[m] has joined #jruby
<enebo[m]>
Seems like the exit 1 is from executing Ruby which is strange but I do not think that is happening in my env
<enebo[m]>
So if I put a puts and output in ruby_exe I see the output and not "". If I put an echo into the sh script I see the output plus that echo output
<headius>
enebo: sure mrnoname the commands you run to get fails
<enebo[m]>
Are newlines used as a delimeter for something?
<mrnoname1000[m]>
Hmm
<enebo[m]>
Let me run that again with the COMMAND output showing what ruby is passing to the script
<mrnoname1000[m]>
Newlines should be escaped between single quotes but it could be an issue with eval-ing the array to get the values out
<enebo[m]>
Ok I should end up with a golden command line to shwo this
<enebo[m]>
I am confused now. Somehow for some specs we are doing -e '{line1\nline2...}' but I am having a rough time seeing where it is really happening
<enebo[m]>
I can see something in ruby_cmd which does it yet I cannot see it ever fire
<enebo[m]>
In fact now that I remove the puts I just put in it stopped
<enebo[m]>
It would appear it will -e if it is given code but the file for code does not exist
<mrnoname1000[m]>
Something is definitely wrong, any newline in -e gets turned into a space
<enebo[m]>
if code and !File.exist?(code)
<enebo[m]>
end
<enebo[m]>
body = "-e #{code.inspect}"
<enebo[m]>
This is highly questionable in Ruby to me
<enebo[m]>
So I have to have lunch but I will leave with another idea
<enebo[m]>
Somehow we are losing some pathing variable telling us where we are running which in turn maks the File.exist? check fail
<enebo[m]>
That would end up triggering this which I half wonder if this works as expected
<enebo[m]>
but I will be back in about 30 or so
<mrnoname1000[m]>
Fixed the newline issue
<mrnoname1000[m]>
I missed an extra layer of quoting
<mrnoname1000[m]>
--environment looks pretty gross with literal newlines though
<mrnoname1000[m]>
Figured out the other issue too
<mrnoname1000[m]>
Apparently in dash, local doesn't make a new, empty variable but a copy of the external one if it exists
<mrnoname1000[m]>
No wonder it was so hard to find
<enebo[m]>
oh cool!
<enebo[m]>
That lunch paid off
<enebo[m]>
mrnoname1000: with the patch above I only have one failure now in magic_comment_spec. I am pretty curious if we see this fix the CI issue since that behavior is seemingly different than my local fails
<enebo[m]>
The one failure may actually be reasonable failure too...not sure if this is tagged or not
<enebo[m]>
We were 188-190 or so and we are again with no magic comment failures.
<mrnoname1000[m]>
🎉
<enebo[m]>
It only someone could party explode my party explode
contour[m] has joined #jruby
<headius>
Nice work. More reasons why I hate maintaining shell scripts
<contour[m]>
Hi Everyone, Does anyone know if jruby ships with the appropriate ruby version needed?
<headius>
Hello there!
<headius>
The latest version of jruby, 9.3.x, is compatible with Ruby 2.6
<headius>
We have a 9.4 release coming up soon that bumps that up to Ruby 3.1 compatible
<contour[m]>
Ah, so I am attempting to upgrade a legacy app. The `$ gem env` command is showing the RUBY EXECUTABLE: /usr/local/jruby-9.2.19.0/bin/jruby
<contour[m]>
And the `RUBY VERSION: 2.5.8 (2021-06-15 patchlevel 0) [java]` But when I do `$ ruby -v` It says Ruby is 2.0.0
<contour[m]>
So I am wondering how the ruby version on my project is reflected an updated version
<headius>
That looks like your path is not picking up JRuby's version of the Ruby command
<headius>
9.2.19 should say 2.5.8 for Ruby -v
<contour[m]>
Right!
<headius>
How did you install JRuby? I wonder if this is a case where you need to tell it to use JRuby for the Ruby command, like java_alternatives does for Java
<contour[m]>
well the Jruby command works fine
<contour[m]>
shows the correct version
<headius>
Where is the `ruby` command? If it is a symlink, where does it go?
<headius>
However this is being installed I would guess it is not setting up that command to point at JRuby
<contour[m]>
`$which ruby` goes to /usr/bin/ruby
<contour[m]>
which I believe is the systems generic ruby install?
<headius>
FWIW we would probably recommend you use a Ruby installer/switcher like rvm or rbenv, they make it much easier to have multiple versions and implementations of Ruby installed and you just pick the one you want before you start working
<headius>
Yeah that is probably just the system Ruby which on your system is currently 2.0.0
<contour[m]>
Yeah. this is a legacy app.
<headius>
Is this Linux?
<headius>
Ah I see
<contour[m]>
Yes
<headius>
Does a `ruby` command exist in that JRuby bin dir above?
<contour[m]>
Where would be the Ruby for that shows its `RUBY VERSION: 2.5.8 (2021-06-15 patchlevel 0) [java]`
<contour[m]>
headius: thats what i thought I tried that
<contour[m]>
no it doesnt
<headius>
It will depend how you want to set this up and how your system wants it set up but the commands `jruby` and `ruby` are just the same executable for us
<headius>
So you could add a link there or somewhere in PATH from ruby to JRuby, it should work fine
<enebo[m]>
You can also use jruby -S gem etc... if you want both available
<contour[m]>
Well everything works fine on this version of the application. I have no problems. I am just curious how its showing `RUBY VERSION: 2.5.8 (2021-06-15 patchlevel 0) [java]` in the gem env
<contour[m]>
Like where did that RUBY VERSION come from? Did it ship when a update to `JRUBY` occured?
<enebo[m]>
contour: is there a .ruby-version file in your app?
<enebo[m]>
Maybe that is switching in your app to jruby
<contour[m]>
What `dir` would that be specified under?
<headius>
Yeah that's a possibility, or something is hard-coded to use the jruby command to start up?
<headius>
Hard to know without seeing your app and your environment but you were correct in assuming that that 2.0.0 number is not the correct version for your installed JRuby
<enebo[m]>
Another thought is you do not have rubygems installed in ruby 2.0 (whereever that is) and it is deferring further down to jruby install
<enebo[m]>
jruby -v; ruby -v
<enebo[m]>
If those two are different then ruby is installed in your path ahead of jruby
<enebo[m]>
which ruby is also useful command to run
<headius>
He mentioned above that there does not seem to be a ruby executable in the JRuby install
<headius>
So I'm curious how this was installed
<contour[m]>
Right!
<contour[m]>
It's a legacy app and I didnt do previous patching
<headius>
Nothing we ship would install into /usr/local so this is something specific to that flavor of Linux
<enebo[m]>
type `which jruby` at a prompt
<contour[m]>
Right @headius
<headius>
But that's an answer anyway, the app is launching probably using the JRuby executable directly while your system Ruby is a different version
<headius>
I don't think we even ship an install script
<headius>
Whoever set this up may have just unpacked it in place
<enebo[m]>
Well that's mysterious
<headius>
Indeed
<enebo[m]>
Not an OS package. Not a standard Ruby manager.
<headius>
Doesn't seem to be
<enebo[m]>
Could be just an image someone set up
<headius>
Yeah, a legacy app where they just unpacked JRuby in a specific spot and hard coded the app to use it
<enebo[m]>
If I made an image I would still use a Ruby manager but I could see someone installing to /usr/local
<headius>
Yeah
<headius>
Especially if this was a single purpose image
<contour[m]>
Right this is like a decade old app
<contour[m]>
legacy
<headius>
Ha nice
<enebo[m]>
contour: So it just appears this install of JRuby is missing bin/ruby in the install. copying bin/jruby to bin/ruby should fix things.
<headius>
Well hopefully that answers your questions. If you want to have the ruby command point at jruby there's several ways to do that but that's up to you
<enebo[m]>
but I bet whoever was doing this in the past was just doing `jruby -S bundle whatever`
<headius>
Yeah that is a simple way
<contour[m]>
yes^
<contour[m]>
Well this is the testing server
<contour[m]>
and it works fine
<contour[m]>
but i need to upgrade the production server from testing server and its offline
<headius>
True, that would use JRuby for subprocesses as well I believe
<headius>
Unless they literally shell out to `ruby`
<contour[m]>
its offline so i cant do remote update
<headius>
Yeah I'm not sure what would be appropriate for your setup but now you know why the versions don't match
<contour[m]>
I'm just confused as to how jruby versioning correlates to ruby
<contour[m]>
Actually
<contour[m]>
Thanks for you help :D
<contour[m]>
I really appreciate it
<headius>
No problem! It's pretty exciting to hear about a 10-year-old legacy JRuby app still in production. If your company is interested in sharing any information about that we'd love to tell others
<headius>
We never hear about the apps that just work 😀
<enebo[m]>
The other part of this is that test clearly got upgraded from a 10 year old codebase
<enebo[m]>
since it is showing 2.5.8
<headius>
Oh yeah that's a very good point
<headius>
So someone out there knows how it was set up 😏
<enebo[m]>
It might be a good idea to consider 9.3 but I am happy nonetheless :)
<headius>
I'm going to merge the shell script fix
<headius>
Goofy shell oddities 101
<enebo[m]>
yeah and that should make your wip tags green
<headius>
Yeah after that's merged I will rebase my branch and see how it looks