aquijoule__ has joined #jruby
aquijoule_ has quit [Ping timeout: 265 seconds]
sagax has quit [Read error: Connection reset by peer]
sagax has joined #jruby
<mattpatt[m]> Okay, that's weird - something's popped /usr/bin off the end of $PATH when it gets to the failing spec, which is why the shell can't find `zip` (or `which`)
<MateuszFryc[m]> Hmm, I am not sure if my mail reached proper people, I din't get any reply about a failure from smtp server, but didn't get any confirmation that email reached proper people. Is this normal? In archived list of issues there is no my issue listed. Additionally I tried to subscribe to the list, but no reply message showed up in my mailbox so far. Issue occurred already 4 times
<MateuszFryc[m]> in my production environment on 3 out of 4 servers which crashing software is installed. Only on the weakest machine it hasnt happened yet. I hope my mail reached the group.
<MateuszFryc[m]> * headius: Hmm, I
<mattpatt[m]> @enebo I have an idea...
siasmj has quit [Ping timeout: 256 seconds]
siasmj has joined #jruby
<MateuszFryc[m]> headius: just for your information, I also submitted an issue on oracle bug submission sites, following some information about how to proceed in such a cases if one have no access to JBS. And received following feedback: "We will review your report and have assigned it an internal review ID : 9071983. Depending upon the completeness of the report and our ability to reproduce the problem, either a new bug will be posted, or we will
<MateuszFryc[m]> contact you for further information." So when someone assesses it is a bug, it should show up in some publicly accessible database I guess, then one will be able to link it to jruby bug issues tracker if needed.
<headius> Yo
<headius> Mateusz Fryc: I do not see your email either. May be moderated
<headius> Oracle bug submission is good. I will try to post to the compiler list if your email does not show up today
<headius> Maybe I should just have filed a JBS bug but I'm skittish
<headius> I suppose I could also raise it directly with the red hat JDK folks since I'm technically on that team
mlaug has left #jruby [The Lounge -]
drbobbeaty has quit [Ping timeout: 250 seconds]
<mattpatt[m]> headius: Chasing down the failure in `rake spec:ji` - added details at
<mattpatt[m]> seems like there's a helper method that resets `ENV['PATH']` and never sets it back
<mattpatt[m]> the spec that calls it is guarded in a way that makes me think that maybe it just never ran on Travis
<mattpatt[m]> What's really weird is that I tried altering it so that `ENV['PATH']` gets reset at the end of that spec with an ensure block on the method, but it doesn't seem to get called.
<mattpatt[m]> headius: yeah, managed to get it passing, but in a horrendously brittle way
<mattpatt[m]> no idea why the ensure didn't work
<mattpatt[m]> Okay, got a version that works. Think the previous non-execution of the `ensure` was down to execution context/thread stuff
<mattpatt[m]> caused by me being daft
<enebo[m]> mattpatt: Perhaps we are throwing an internal error
<enebo[m]> We run so many tests too that it becomes easy to miss partial execution of stuff because there are a lot of logs
subbu has joined #jruby
<mattpatt[m]> not here - I have been running just spec:ji on a just JDK 8 in a branch
<mattpatt[m]> and grepping the logs for debug `puts`s
<enebo[m]> so can you repro that ensure is not running?
<mattpatt[m]> I think so - tweaked it several times adding more debug output
<mattpatt[m]> and it ran in none of them
<mattpatt[m]> here's the version that didn't work: def hide_ant_from_path... (full message at
<mattpatt[m]> ooops
<enebo[m]> yeah I was looking at your comments on the PR
<mattpatt[m]> Can you see my builds? Unsure if GHA builds on public repos are totally public
<enebo[m]> mattpatt: Run with -d if you get it locally and we may see something raised
<mattpatt[m]> that's the working version. the `instance_exec` seemed to make the difference
<enebo[m]> It looks like I can see all the action runs associated with PRs?
<mattpatt[m]> does the link I sent work for you?
<enebo[m]> yeah it shows a green run
<enebo[m]> although there are errors
<mattpatt[m]> yeah, pendings
<mattpatt[m]> this is the final form of the ensure-not-running:
<enebo[m]> ah ok I did not think there were that many but it makes sense
<mattpatt[m]> to run with -d I can do `jruby -d -S rake ...`
<mattpatt[m]> not an arg passed to rake
<enebo[m]> yeah
<enebo[m]> undefined local variable or method `original_env_path' for #<RSpec::ExampleGroups::RakeAntAnt:0x752e4223>
<mattpatt[m]> great, it's much simpler if i was being an idiot
<enebo[m]> Unless you changed from the ensure I find that really weird
<mattpatt[m]> `orginal_env_path` and `original_env_path`. 👍️
<enebo[m]> mattpatt: can you change that method from doing def; ensure;end to def; end with a begin;ensure;end within it?
<mattpatt[m]> sure
<enebo[m]> This error if it is from the code linked above implies tyhat original_env_path is not seeing a local variable scope and thinks it is a vcall (e.g. method with no parens or params)
<mattpatt[m]> I think the ensure was always running, i just couldn't type
<enebo[m]> ok but that specific error in the run shows that it is aborting on original_env_path not being found
<enebo[m]> which would be above your puts in that last commit
<enebo[m]> I do doubt we broke def a; ensure;end since although uncommon it is not that rare but it looks like it thinks it is a vcall
<mattpatt[m]> yeah - it was aborting before it to my debug `puts`, and it couldn't reset `ENV['PATH']`, so I was seeing the spec with `zip` still failing
<mattpatt[m]> so I think the problem was squarely between brain and keyboard, and not with `ensure`
<mattpatt[m]> it's working fine in my latest version of the solution
<enebo[m]> yeah and I can confirm ensure is firing too
<mattpatt[m]> will tidy up a bit then submit a PR
<enebo[m]> mattpatt: great
<mattpatt[m]> enebo: is there a rule around trailing whitespace in files? my editor is set to remove it, and it hasn't been a problem with other JRuby source files I've worked with, but `spec/java_integration/utilities/jar_glob_spec.rb` has a load of empty lines with trailing whitespace...
<mattpatt[m]> Do I need to revert those?
<enebo[m]> mattpatt: Naw. Over time we have gotten rid of them so it is fine.
<enebo[m]> you can also whitespace ignore even in github to avoid seeing them when looking at a diff
<mattpatt[m]> GHA CI is running now, hopefully spec:ji now passes on all tested JDKs
<enebo[m]> I never remember &w=1 and they keep changing their UI
<mattpatt[m]> looking good here
subbu has quit [Quit: Leaving]
subbu has joined #jruby
<headius> Oh looks good so I merged!
<headius> What a weird piece of code
<headius> mattpatt: nice find!
<mattpatt[m]> when I saw that `$PATH` was only missing `/usr/bin` I figured it had to be something else in the test run mutating it
<headius> Yeah makes sense
drbobbeaty has joined #jruby
subbu has quit [Ping timeout: 265 seconds]
<headius> odd, my addrinfo fix did not seem to work on GHA
<headius> oh boo I targeted master
<headius> ok so test:mri:stdlib should be green then
<headius> enebo: I should have checked this before... some of the spec failures have "travis" tags
<headius> so they were failing on travis too but are not being masked on GHA
<headius> do any specs fail for you locally on fedora?
<headius> I'm doing a run locally under docker ubuntu 20.04 and will also inspect these other failures
subbu has joined #jruby
<headius> some of these look like it's running ipv6 specs when ipv6 is not present... I see checks for this in the specs but we are probably defining all the constants all the time so it thinks they should work
<headius> there must be a better way, right?
subbu has quit [Ping timeout: 256 seconds]
subbu has joined #jruby
<headius> ok the ip6 things are only in my docker ubuntu which must not have ip6 set up
<headius> I will fix this constant but it probably won't help GHA
<headius> attn ahorek also... these constants are still "defined" on jnr-constants but ipv6 may not be available
<headius> the mkconstants.rb file in MRI ext/socket is difficult to follow
<headius> ok another of these specs fails because it tries to use a Socket as a server and we just don't support that
<headius> this one is probably not tagged because we have ignored when it fails locally
<headius> we have talked about trying to get the FFI socket library working but I wonder if just doing it for Socket would be sufficient
<headius> anyone using Socket directly wants the low-level behavior
<headius> 🤦‍♂️
<headius> yeah most of these socket failures in GHA also fail for me locally on MacOS with ipv6
<headius> so they are just broken ipv6 things that in some cases are already tagged for the ip4v versions
<headius> mattpatt: I think I have everything to make this green now
<headius> so these are the "travis" tags right now, but I think only the getlogin one is showing up on GCA
<headius> GHA
<headius> that should be it
<headius> I remarked the getlogin tag as "tty" and enable it by testing `$stdin.tty?` in jruby.mspec
<headius> the other travis tags I removed since they are passing on GHA