subbu has quit [Quit: Leaving]
<headius> good morning!
<rdubya[m]> good morning!
<headius> rdubya: hey there!
<rdubya[m]> It's been a while, thought I'd start lurking in the channel again 🙂
<enebo[m]> rdubya: good to see you
<rdubya[m]> you too, looks like you guys are still hammering away at it, I still follow it even though I don't get to use it day to day
<headius> enebo: can you show me your `man posix_spawn_file_actions_adddup2` please?
<headius> I just noticed on macos there are extra file actions for chdir
<headius> do you have a manpage for posix_spawn_file_actions_addchdir?
<headius> looks like this was added in just the last few years
<enebo[m]> nope
<headius> interesting
<headius> the sole remaining failure in CRuby test_rand.rb appears to be a problem in the test harness spawning a subprocess
<headius> woot, got it
<headius> the test harness passes a pipe fd to the child process by redirecting it to itself; if that fd is CLOEXEC it gets closed before it can be used in the child
<headius> so this has been a bug in our spawn logic for a while
<headius> I think it gets fixed in CRuby code we don't run because we don't use fork
<enebo[m]> there is also an issue with some MRI tests because they will fork and for us they use eval (which at a minimum messes up warnings)
<headius> this may fix some other spawned tests
<enebo[m]> I have not worried too much about that since a) we won't support fork b) the things we fail all seem to just be from this difference in how it is run
<headius> 39 tests, 813 assertions, 0 failures, 0 errors, 0 skips
<headius> test_rand is green
<enebo[m]> nice
<headius> securerandom in CRuby 3.1 does not match the released gems
<headius> sigh
<headius> enebo: I'm going to merge the Random fixes but on the fence about switching to the securerandom gem
<enebo[m]> headius: because of the out of sync issue with MRI?
<headius> well that's part of it, but more because we lose our native SecureRandom
<enebo[m]> ah
<headius> but the code in there is mostly replaced by native stuff added to Random
<enebo[m]> so a bit more Ruby around the native pieces
<headius> the gem has like 100 lines of Ruby code total and backends on the Random bytes feature
<enebo[m]> I guess the larger question is who will end up with this as a transitive dep from their gems?
<headius> yeah I can check reverse deps on rg.org
<enebo[m]> If we install the gem then I guess we would also still work so long but we could not install it by default and just have the second impl
<headius> not many
<enebo[m]> I just assume as a non-default a trans dep would just more or less replace the namespace since they would have the same methods
<headius> but it will be one more library we don't have to maintain
<headius> it would if explicitly activated yes
<headius> it might complain about overwriting ours
<enebo[m]> I think in the long run anything default will end up deep down in trans deps
<headius> and if not activated it might not get used at all because we will find stdlib version and no default gemspec
<headius> yeah most likely
<enebo[m]> So working in the gem is obviously really important but whether we ship it or not is a different question
<headius> so I guess the main question is whether we want to update our native version to have the same functionality and ship that in the gem, or just use the gem
<headius> you can see the code is pretty basic
<enebo[m]> ok so if it doesn't activate then only issues would be API changed in an unexpected way or there was a security fix
<headius> yeah
<enebo[m]> I don't really know how hot this is and obviously I don't even know if there is a perf difference
<headius> yeah I guess we should just go with the gem and deal with perf if it is a problem (which it probably will not be)
<enebo[m]> If it is same speed then it seems like moving to gem and default would mean less code for us but more coordination maybe
<enebo[m]> but we definitely need to have the gem work
<enebo[m]> yeah seems reasonable to me
<headius> ok
<enebo[m]> I have wondered about whether we will have a situation where we decide to ignore a gem or we use some internal version if we detect it is safe to do so
<headius> yeah there may be cases
<headius> we also still have to do something about bigdecimal and openssl because their maintainers are fully against merging JRuby code in (which is why I proposed having -java versions of those gems that depend on our gems)
<enebo[m]> yeah I think that sounds like the right workaround. They never have to do anything at that point other than perhaps let us know of API changes
<enebo[m]> They will still get issues opened against them I bet but what can you do? They have the name of the gem and we all need to work
<headius> yeah nobu was questioning why we have to merge our impls into their ext gems today
<enebo[m]> like he didn't understand the basic issue?
<headius> I didn't get more out of him yet...
<headius> "Is this kind of full merger really necessary?
<headius> Eventually two different gem files will be released, and only few files and the version number will be shared."
<enebo[m]> yeah but we have to release with the same name
<headius> I explained that but it was likely after hours for him
<enebo[m]> yeah
<headius> so I will see what he thinks the alternative is whenever he's back
<enebo[m]> Also the Ruby calling into the same native methods means Ruby can change for fixes and both work
<enebo[m]> Obviously that is true for a securerandom but less so for openssl
<headius> yeah I can understand the reluctance on larger gems but we still have to have the name
<enebo[m]> and indirecting all of them through an empty top-level name would suck
<headius> maybe he believes it would be better for us to maintain a separate repo with our version of the gem, but then we're duplicating tests in three places (including CRuby repo) and still have to release in lock step with them or JRuby users break
<enebo[m]> that also absolves them from keeping us in sync at all
<headius> so it doesn't seem helpful to split the repo by Ruby impl
<enebo[m]> and I am not saying they need to do the work as much as not just pretend we will magically fix it after we notice it came out
<enebo[m]> yeah this is definitely something which needs coordination
<enebo[m]> I do sympathize that we create some extra burden but it is not a surprise...we have been around for 20 years
<headius> indeed