<headius> enebo: travis has not replied to my issue about them shutting down service, so I guess that's it
<headius> we will need to migrate those jobs to GHA
<headius> silly me... we also need to audit the 2.7 feature list
<headius> enebo: you might be able to go through this quicker based on your 3.0 work
<headius> I will let you do a first pass since a lot of this is probably done
<headius> I added a note here
<headius> ugh and snapshot deploys were on travis too
<headius> I guess I have my marching orders for tomorrow
mattpatt[m] has joined #jruby
<mattpatt[m]> I am moving to a new M1 Pro MBP and am getting nowhere fast with JNR/JFFI and 9.3 on Azul's aarch64 JDK 11. Is there a recommended Apple Silicon JDK to use, or do I just need to keep plugging? (I do not recall having these problems with 9.2.19 on an M1 Mac mini, but I also don't recall what I actually did...)
<mattpatt[m]> headius: Shout if you want/need a hand with GHA/Travis migration - I will have some time tonight...
<mattpatt[m]> (actually, just saw your tweet. Will check in later on once kid is asleep)
<mattpatt[m]> so, looks like bundler on native Apple Silicon JDK is a no go until libffi support is upstreamed from Apple. Okay, JDK under Rosetta it is then...
<mattpatt[m]> welp, still faster than on my old MBP 🤣
<headius> mattpatt: yeah that FFI support is the only missing thing really
<headius> x86 JDK is a good workaround for now since it still runs well
<mattpatt[m]> @headius I'm looking at the Travis and existing GHA stuff now
<headius> edipo.federle: are you still looking at that Enumerator/ArithmeticSequence thing? Looks like that is the last failure in Array specs on master (13 of the same error).
<headius> mattpatt: oh that would be great... enebo should we do it against 9.3 or 9.2?
<headius> none of our branches are getting tested now
<headius> 9.3 and master are a bit better than 9.2 because they moved some mvn-launched jobs to GHA
<headius> none of the main Ruby suites are running though
<enebo[m]> headius: do which GHA?
<headius> yeah
<enebo[m]> Yeah I think all three if we can since 9.2 may need more releases
<enebo[m]> I think my only concern is I hit limits on GHA per month and I am uncertain if that will happen to us on an org account
<enebo[m]> OTOH we only do so much dev at a time in any one place so it probably will not matter from hitting some quota
<mattpatt[m]> The existing actions stuff that's been done was to move jobs out of Travis? (I was looking for additions to .github and removals from .travis.yml and am not finding much with my quick poking about)
<headius> mattpatt: 9.3 and master should be mostly the same and have all (or most of) the maven-launched jobs running on GHA
<headius> 9.2 has almost nothing on GHA
<headius> I think there'
<headius> there's a build smoke test and that's it
<headius> and yes we moved those jobs to get out of travis but never got past the simple maven jobs
<headius> mattpatt: you know a lot of this is academic... pick 9.2 or 9.3 branch and try moving a job over and we will see how it goes
<headius> we don't have to boil the ocean
<enebo[m]> mattpatt: headius Let's do simplest thing first
<enebo[m]> 9.3 branch which we will merge to master since GHA is already partially there
<enebo[m]> we can cherrypick or copy that directory to 9.2 after it is running
<enebo[m]> 9.3 will be our next release too so there's that
<headius> yeah 9.2 will require some tweaks because it has never been set up to run tests on GHA
<headius> 9.3 is a good target
<mattpatt[m]> workflow in `master` and in `jruby-9.3` seem to be identical
<headius> yeah no change there
<enebo[m]> mattpatt: yeah they should be...only code is different
<headius> we just merge 9.2 => 9.3 => master (9.4)
<mattpatt[m]> I was assuming I'd start on master, but sounds like I should start directly on 9.3
<headius> so 9.3 changes will get into master naturally but not the other way around
<headius> 9.3 is current release too so good to prioritize getting it working in CI again
<headius> and master fails all its tests because we moved to 3.0 and not everything is there yet
<headius> which is what I'm working on today 😀
subbu has joined #jruby
<mattpatt[m]> Just opening a test-this-action PR
<headius> cool
<mattpatt[m]> `jruby -S rake test:mri:core:int` is running and has been for 5 minutes, so with luck it's working right (I guess pass/fail is orthogonal to work/not work at this point)
<headius> yeah just getting it running there will be a framework
<mattpatt[m]> the `windows-ci.yml` workflow does it
<mattpatt[m]> and that basic approach seems to work here too
<headius> great!
<headius> hmm
<headius> ARGF.gets reads the contents of the file with default encoding FAILED
<headius> Expected #<Encoding:ASCII-8BIT> == #<Encoding:US-ASCII>
<headius> that only fails in a full ARGF spec run
<headius> I tried mimicking the CRuby logic for argf_getline but it doesn't seem to help
<headius> I'll commit what I have and revisit this later
<mattpatt[m]> given the differences between Travis runners and the GHA runners, do we still need the memory / JVM opt stuff?
<mattpatt[m]> `-Xms60M -Xmx720M -XX:InitialCodeCacheSize=40M -XX:ReservedCodeCacheSize=120M -Djava.security.egd=file:/dev/./urandom`
<mattpatt[m]> I'm guessing the `java.security.egd` option is probably not needed anymore
<mattpatt[m]> but I don't understand if the memory options are for travis limitations or goosing the env for the Indy / JITy stuff that might take a while to warm up otherwise
<mattpatt[m]> Right, got a an actual run-to-completion (fail) for `rake test:mri:core:int` on JDK 11, and a mysterious 'operation cancelled' on JDK 8. Going to take that as a win and try with the additional JAVA_OPTS stuff in the morning, see if I can JDK 8 to fail too.
<mattpatt[m]> Ugh, had the PR set to rebase off master not 9.3, so that may account for some of the weirdness. Definitely one for the morning
sagax has quit [Quit: Konversation terminated!]
sagax has joined #jruby
<headius> yeah that is positive
<headius> yeah if you can edit it just switch it to base off 9.3, otherwise I can change it