<headius[m]>
well the logic that fails in your short example is doing an fstat to see if the descriptor is open, but wsl does not appear to support that on this inotify fd?
<ahorek[m]>
right
<headius[m]>
this other logic you linked is for us to avoid using our native file channel when not dealing with a regular file, which would apply here
<headius[m]>
so this fstat fails and it gets set up as a non-native channel
<headius[m]>
before we proceed would you agree this needs more work than we want to shove into 9.2.14 at the last minute, yes?
<headius[m]>
it does appear to be a combination of inotify not being fully supported by WSL and JRuby trying to do some unsupported things with that fd
<headius[m]>
this code clearly works on normal linux
<ahorek[m]>
I think so, it can wait...
<headius[m]>
do you know why downgrading inotify seems to work around this?
<headius[m]>
I have not dug into the versions and commits enough yet to know
<ahorek[m]>
no, but I can run tests and find out, I have a WSL env at hand
<headius[m]>
enebo: so yeah this is a larger issue related to wsl support for inotify, no reason to hold up the release
<headius[m]>
ahorek: yeah I have been using my wsl2 env also
<headius[m]>
the two fstats you have pointed out would need to be replaced with something, perhaps just a better fallback... which I think is what you started to do in your PR?
<ahorek[m]>
I would expect there won't be any problem on WSL2 ?
<headius[m]>
so cruby does not fstat the fileno passed to IO.new but we do in order to know if it is open and our existing ChannelFD for it can be reused
<headius[m]>
well it still fails for me
<ahorek[m]>
ok
<headius[m]>
ahorek: I posted an update on the issue that shows CRuby also raises EPERM if you stat the resulting IO object
<headius[m]>
the WSL issues show other system calls but it is clear the inotify descriptor is not fully functional
<ahorek[m]>
you're right
<headius[m]>
enebo: you updated the exe yes?
<headius[m]>
that issue is still open
<enebo[m]>
yeah
<enebo[m]>
Did anyone delete jruby from staging repo on sonatype
<headius[m]>
haven't touched sonatype since JNR stuff last week
<enebo[m]>
hmm what I pushed yesterday is not there. I guess I will do it again?
<headius[m]>
yeah I dunno how long those stick around but you have seen them last more than a day I guess?
<enebo[m]>
yeah for quite a long time
<enebo[m]>
but perhaps they are killing the for space or something
<enebo[m]>
ok so it is appearing. I guess lunch and it will be done
<headius[m]>
most of the issues for this one are one-offs so I will have you review my release notes to see if anything else should go in
<headius[m]>
which would work fine on Linux but darn that WSL
<headius[m]>
so either we need to provide a patch that falls back to old behavior when the inotify fileno can't be fstat'ed, or we need to change how this is handled in JRuby
<headius[m]>
I'm going to boot back into macOS, brb
<headius[m]>
okeedokee
<headius[m]>
ship it
sagax has quit [Ping timeout: 240 seconds]
subbu is now known as subbu|away
ur5us has joined #jruby
subbu|away is now known as subbu
mistergibson has joined #jruby
<enebo[m]>
That is hilarious. I had that chanop irc crap at the front of the old topic and no one told me
enebo has joined #jruby
<headius[m]>
I didn't notice it
<enebo[m]>
clearly I didn't either...SINCE AUGUST
<headius[m]>
enebo: this fzakaria issue might actually be fixed by upgrading jnr
enebo has left #jruby [#jruby]
<headius[m]>
the only flag that dev mode turns on that seems related to native calls is one that disables jnr-ffi assembly stubs, and I did some work this summer to fix broken issues in the non-assembly logic
<headius[m]>
enebo: does this work in your linux env: `jruby --dev -e "system 'date'"`
<headius[m]>
I think I have tracked this down to us using a generic jnr-ffi invoker when compilation is turned off, and that invoker must not be exactly correct on some linux envs
<enebo[m]>
Tue 08 Dec 2020 03:21:35 PM CST
<enebo[m]>
jruby 9.2.14.0 (2.5.7) 2020-12-04 93bd1911a1 OpenJDK 64-Bit Server VM 25.242-b08 on 1.8.0_242-b08 +jit [linux-x86_64]
<enebo[m]>
I can try master too if there is possibly a difference
<enebo[m]>
rdubya: heya I can see your icon...how ya doing? :)
<rdubya[m]>
enebo: heya, doing well. How have you been?
<enebo[m]>
rdubya: pretty good for the apocalypse
<rdubya[m]>
lol
<headius[m]>
enebo: try 9.2.13
<headius[m]>
I assume it is fine but it is puzzling to me that this fails in the Nix environment but works fine otherwise
<enebo[m]>
rebuilding
<enebo[m]>
I have some weird problem with fedora installed maven which blows up
<headius[m]>
older maven?
<enebo[m]>
I started using ./mvnw just to work around until I decided to figure it out and now I realized I have been doing that for a month :)
<enebo[m]>
Apache Maven 3.6.1 (Red Hat 3.6.1-5)
<headius[m]>
seems good
<enebo[m]>
vs Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-24T13:41:47-05:00)
<enebo[m]>
9.2.13.0 works too
<enebo[m]>
let me see what the error was
<headius[m]>
yeah I dunno why either of those would be a problem
<headius[m]>
you may be able to set up this Nix environment he has but at any rate someone will have to do that to really debug this I think