<byteit101[m]>
hmmm, subspawn should depend on subspawn posix on posixy platforms only, should the gemspec depend on it and build subspawn for each platform, or no dependency and warn about it?
<headius>
yeah starting to permute too many combinations now
<headius>
wait does libfixposix work on Windows? I feel like I missed something here
<headius>
I am getting my projects crossed between you and ldywicki
<byteit101[m]>
I don't think so
<headius>
ok
<byteit101[m]>
I have been assuming i'd have a subspawn-win32 project (vs subspawn-posix) for windows
<headius>
fever dream there for a second... I really want posix_spawn to work on Windows
<byteit101[m]>
it may work for msys or cygwin or such
<byteit101[m]>
but I'm not sure
<byteit101[m]>
:-)
<byteit101[m]>
I could also make the few *-windows builds for subspawn-posix be empty to avoid dragging in LFP for windows
<byteit101[m]>
and everyone else (ie posix systems) wold get the normal subspawn-posix
<byteit101[m]>
or we could just let users have two gems in their gemfiles
<headius>
yeah I don't have a good answer, Windows support gives me headache
drbobbeaty_ has joined #jruby
drbobbeaty has quit [Ping timeout: 272 seconds]
razetime has joined #jruby
razetime has quit [Ping timeout: 246 seconds]
razetime has joined #jruby
<ldywicki[m]>
looking at dockcross I see various variants of windows compiler/linker ie. windows-x64-static, windows-x64-static-posix. Does it matter for jnr?
<headius>
ldywicki: if it's possible to statically link dependencies that would be great, but I think we'll always depend on the MS C runtime
<headius>
I'm not sure what those names mean though
<ldywicki[m]>
Roger, I think we will be able to experiment with these later on, so far I found a way to call makefile.
<ldywicki[m]>
Turns out I can pass necessary variables into makefile through env variables making it produce dll without necessity to parameterize everything with maven
<ldywicki[m]>
Keeping flexibility of make while preserving simplicity of maven side
<ldywicki[m]>
I've got windows x86_64 .dll out of build, waiting for x32 docker image
<headius>
enebo: there's a few straggling failures I'm tagging but the MRI WIP PR is just about ready
<ldywicki[m]>
this is a maven build which execs a `compile-native.sh` with few options such as java home, linking mode etc. Compilation and make execution happens inside dockcross container launched by script itself.
<ldywicki[m]>
I think I found several edge cases with windows arm and probably didn't pass all required parameters to script itself to produce proper libs, but its first attempt :)
<ldywicki[m]>
I noticed there are some differences between two versions of libtest found in jnr, ignoring them for now as main point is having cross platform build
<headius>
I'll be in the office shortly and will catch up
<headius>
byteit101: I just looked over the spawn code in LFP and definitely would not work on Windows because there's fork calls
<headius>
I keep hoping we will find a spawn implementation built on top of win32 CreateProcess
<headius>
Refactoring our existing process logic is an open task, necessary before we swap out the guts to make it work on Windows
<headius>
while this WIP PR settles down (stdlib keeps having one additional failure that doesn't repro locally, something unstable in test_https) I'm going to try to close out this loongarch thing
<headius>
byteit101: I have access to all the gcc compile farm machines now
<enebo[m]>
lol
razetime has quit [Remote host closed the connection]
<ldywicki[m]>
so we don't need dockcross? ;-)
<headius>
well, I don't think we can really use this as part of a CI or something
<ldywicki[m]>
Depends if CI/CD has docker-in-docker option (DIND). I used such feature with gitlab, also with kubernetes deployment. Its doable. If you have a computing resource you can dedicate to become an agent ie. of github actions, its matter of tweaking bunch of (crappy) yaml files.
<ldywicki[m]>
Maven in this regard is just a bit complicated, but still, a firing point
<byteit101[m]>
headius: handy, though I think I got most arch's working with dockcross last night
<byteit101[m]>
headius: Yup, see the chart I made on the subspawn readme a while ago
<ldywicki[m]>
byteit101: can you test repo I posted above?
<headius>
ldywicki: ok
<headius>
ldywicki: Not sure what this error is or why you wouldn't have seen it:
<headius>
dc7fc53eda71: Pull complete
<headius>
Status: Downloaded newer image for dockcross/linux-x64:20221101-57a27d5
<headius>
Error: short-name resolution enforced but cannot prompt without a TTY
<ldywicki[m]>
I think its a script issue - the way docker is ran misses `-it` or so option
<ldywicki[m]>
pull is fine
<headius>
ldywicki: by "I don't think we can really use this as part of a CI or something" I meant the build farm... it is not really meant for persistent services
<headius>
byteit101: in theory we can provide at least a subset of posix_spawn on top of CreateProcess and similar win32 calls, but we have not attempted it
<ldywicki[m]>
headius: model in which agents are working is rather straight, you deploy a controller which uses minimal resources, but runs continuously. It deploys a temporary container which is evicted after build. Build itself has to externalize its results and state.
<headius>
jffi already has some docker-based builds, so I think that should slot into this nicely
subbu has joined #jruby
<ldywicki[m]>
do you have these available for cross check with mess I am making with dockcorss?
<ldywicki[m]>
Looking at this it looks like an issue with oci stuff, its beyond docker itself.
<headius>
linux x64, should be pretty recent docker install
subbu has quit [Quit: Leaving]
<headius>
enebo: frustrating single failures still on this WIP exclude branch... every time I push an exclude for TestNetHTTPS another single failure pops up
<headius>
I may just merge what I have and move on
<headius>
it is something environmental or something preventing all tests from running
<ldywicki[m]>
[using containers for reproducible builds ;-)]
<headius>
enebo: I did one last push of WIP excludes at https://github.com/jruby/jruby/pull/7422 and regardless of the result I'll merge... at least we can now track core and extra regressions and stdlib is pretty close
<headius>
then we're down to about five suites failing
<enebo[m]>
headius: yeah I saw you were working towards that
<headius>
Of course my one last exclude appears to have made stdlib green
<headius>
Merged!
mattpatt[m] has joined #jruby
<headius>
I'm going through some backlog PRs for 9.4
<headius>
I rebased this PR for deprecating Joda Time but the new java.time stuff is really hard to grok and isn't a drop-in replacement: https://github.com/jruby/jruby/pull/6602
<headius>
not sure if we can release with Joda Time endpoints deprecated until we know the java.time endpoints work right
<headius>
this also doesn't pass all tests because I tried to fix all internal uses of the deprecated Joda Time methods and ran into incompatibilities
<headius>
it depends on our JRuby fork of jzlib (which isn't being maintained anyway) and sets up the jruby jar to depends on the other jars as modules rather than shaded
<headius>
there are some launch script changes that didn't port over when rebasing