<enebo[m]>
speaking to that the minitest mock issue I was chasing yesterday is odd and I do not think it is a kwargs bug
<enebo[m]>
I isolated our failure and extracted it and we run exactly the same between Ruby 3.1 and us...
<enebo[m]>
then I am aha this env MT_KWARGS_HACK=1 must be set in rails ci
<enebo[m]>
then I noticed the failing test has corrected their calling syntax on rails head (as opposed to rails-7-stable)
<enebo[m]>
now I see i18nvalidation tests showing we are not sending kwargs to the mock but as a regular arg...This might be a mistake we are making in arjdbc or it could be a legit kwarg issue
<enebo[m]>
This morning I plan on figuring this out but once I check this off I will start testing for 9.4.2
<headius>
Ok great
<headius>
Quiet day here so I will be working
<enebo[m]>
ah alright
<enebo[m]>
I just tested windows and it seems ok
<enebo[m]>
I have a couple of things as well as lunch but how about trying to launch this afternoon
<enebo[m]>
I mean I already started so there's that but I mean finializing the release assuming I do not trip over something
<headius>
yeah sounds good to me
<headius>
doing nothing but sitting around the pool today
<headius>
it's nothing important but the rake-compiler extension build might not be working properly on Windows
<headius>
or maybe json uses some custom logic
<headius>
it's obviously not picking up the JRuby jar
<enebo[m]>
hmm
<enebo[m]>
just another thing to figure out
<headius>
yeah
<enebo[m]>
my Rails kwargs + minitest mock is/was frustrating
<headius>
yeah so we are not actually broken
<headius>
?
<enebo[m]>
I believe we will pass tests in newer rails because they rewrote them for modern kwargs minitest mock API
<enebo[m]>
but that is not on rails-7-stable I think because 2.7 is supported
<enebo[m]>
well something might be broken but it probably isn't kwargs
<enebo[m]>
it is maddening though. I could not figure out if MY_KWARGS_HACK is set on Rails CI because it is pretty sophisticated
<enebo[m]>
It may be set in images or maybe isn't displayed in logs while running
<headius>
weird
<enebo[m]>
but if I extract a failure as a separate minitest mock example MRI 3.1 behaves the same as us
<enebo[m]>
both work with the "tempoary" env var
<enebo[m]>
but when I set that i18n valididations tests fail but I got some env issue which pissed me off so I decided to ignore this today :)
<enebo[m]>
Iti much more likely it calls something internal in arjdbc which is not kwargsish so it passes that option back as regular hash
<enebo[m]>
I have seen nothing yet to imply we do kwargs wrong
<enebo[m]>
the tests but having studied how the mock impl works I do not see how MRI 3+ could possibly work without that env set
<headius>
ok I guess we just move forward for now then
<headius>
hey so what do you think about this jffi glibc issue
<enebo[m]>
afk 5 minutes or so...delivery is here
<headius>
I still have not found a good way to automate the build, but the released binaries will remain busted on centos7 and rhel7 unless we build it there and release that binary
<headius>
I do not want to have to manually build the linux ext every time on a centos VM but I don't know how to automate it
<headius>
I am leaning toward just sucking it up and doing the manual build now and hopefully figuring out how to automate it before long
<headius>
I can't really do it today because my centos VM is on home x86 machine and I only have M1 machine with me
<headius>
(I don't think any of the reporters are JRuby users)
<headius>
maybe I'll ask twitter for ideas
<enebo[m]>
yeah. this feels like it should be a solved problem somewhere
<headius>
glibc does not appear to have any good ways to bind to an older version
<headius>
you just have to build against old glibc
<headius>
which is pretty lame
<headius>
I just realized my attempt to use older debian had a bug so I'm retrying that