Ryan Liptak

> I do `git tag -d v2.9.3 && git tag v2.9.3 -m "v2.9.3" && git push origin v2.9.3 --force` I went with a different approach, and appveyor seems to be...

Ok, I think we're good to go. The Windows binaries have been moved to the `v2.9.3` tag and still have the proper version (`luvi.exe v2.9.3`), and the `v2.9.3-temp` tag has...

> Checked package download from https://github.com/luvit/luvi/releases/tag/v2.9.3 test pass. Tested the rest except the Windows .lib files. Everything seems good.

Using docker & holy-build-box has portability benefits: https://github.com/phusion/holy-build-box

Looks like we can use Github actions to build arm binaries. @truemedian is doing just that here: https://github.com/truemedian/luvit-bin/blob/main/.github/workflows/manual.yml#L154-L196

Surely it's better than nothing. If we don't want to take the hit for every CI, we could only build arm for tagged releases.

Was thinking about this as well. Would be interesting to try.

Played around with it a bit. Was able to get luv to compile but the resulting LuaJIT fails to load the resulting luv.so. ``` git clone https://github.com/luvit/luv.git cd luv export...

I have a feeling the tough part will be getting OpenSSL to compile. We [use a CMake `ExternalProject`](https://github.com/luvit/luvi/blob/master/deps/openssl.cmake) for it and call out to `make`/`nmake` and let OpenSSL do its...

Was actually able to build a static musl binary of the luvi `tiny` variant by doing: ``` export CC="zig cc -target native-native-musl -fno-sanitize=undefined" export ASM="zig cc" make tiny make ```...