Bug 225342 - lang/luajit: Update to 2.1.0-beta3
Summary: lang/luajit: Update to 2.1.0-beta3
Status: In Progress
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Sergey A. Osokin
Depends on: 226537 226541
  Show dependency treegraph
Reported: 2018-01-20 18:19 UTC by Val Packett
Modified: 2022-01-31 20:43 UTC (History)
4 users (show)

See Also:
bugzilla: maintainer-feedback? (osa)

luajit-2.1.beta3.patch (3.04 KB, patch)
2018-01-20 18:19 UTC, Val Packett
no flags Details | Diff
luajit-2.1.beta3.patch v2 (10.87 KB, patch)
2018-03-11 23:11 UTC, Val Packett
no flags Details | Diff
luajit-2.1.beta3.patch (13.65 KB, patch)
2018-08-07 16:50 UTC, Val Packett
no flags Details | Diff
patch (8.84 KB, patch)
2020-03-07 08:09 UTC, Mikael Urankar
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Val Packett 2018-01-20 18:19:24 UTC
Created attachment 189934 [details]

You might want to wait for 2.1.0 final release, but just throwing this out there — it works on arm64!
Comment 1 Sergey A. Osokin freebsd_committer freebsd_triage 2018-01-20 19:03:01 UTC
Hi Greg,

thanks for the report.

At first look the patch looks incomplete: PORTREVISION should be removed.

Also, several ports depend on lang/luajit and should be updated with this change, this is why I've recommended to garga@ to raise a review in Phabricator.
Comment 2 Val Packett 2018-01-21 12:26:06 UTC
benchmarks/wrk was fixed upstream: https://github.com/wg/wrk/issues/314 asked them for a release.

editors/neovim fixed a non-fatal error, not related to the update but to arm64: https://github.com/neovim/neovim/issues/7879

Apparently "it doesn't seem like a final release [of LuaJIT 2.1] will be out anytime soon". Debian testing is shipping 2.1.0-beta3 already.
Comment 3 Walter Schwarzenfeld 2018-03-11 19:27:53 UTC
Could this included or is it out of time? bugs #191476.
Comment 4 Walter Schwarzenfeld 2018-03-11 19:28:17 UTC
bug #191476.
Comment 5 Val Packett 2018-03-11 23:11:16 UTC
Created attachment 191436 [details]
luajit-2.1.beta3.patch v2

(In reply to w.schwarzenfeld from comment #3)
I'm not sure what exactly you meant, but I've included that pthread patch in this update.

Plus fixes for dependent ports. I think most of them should work now…
Comment 6 Sergey A. Osokin freebsd_committer freebsd_triage 2018-04-21 05:00:04 UTC
Looks very good for me.
Comment 7 Val Packett 2018-08-07 16:50:41 UTC
Created attachment 195982 [details]

Updated with fixes for more dependent ports.
Comment 8 Adam Weinberger freebsd_committer freebsd_triage 2019-01-05 21:33:30 UTC
What's the status here? It would be nice to see luajit get updated.
Comment 9 Mikael Urankar freebsd_committer freebsd_triage 2020-02-03 18:04:31 UTC
Comment 10 Adam Weinberger freebsd_committer freebsd_triage 2020-02-03 21:33:49 UTC
Sergey, are you planning on committing this?
Comment 11 Sergey A. Osokin freebsd_committer freebsd_triage 2020-02-10 21:11:36 UTC
Thanks for the new patch.

Looks good for me.  There are several ports are involved in this update.  I believe we can test (do a build?) those propertly before we commit the change.
Comment 12 Mikael Urankar freebsd_committer freebsd_triage 2020-03-07 08:09:12 UTC
Created attachment 212216 [details]

Comment 13 Daniel Engberg freebsd_committer freebsd_triage 2020-03-20 08:47:04 UTC
Perhaps it would be worth looking at porting moonjit https://github.com/moonjit/moonjit or raptorjit https://github.com/raptorjit/raptorjit instead which seems to be much more active and make it default instead?
Comment 14 Val Packett 2020-03-21 00:14:18 UTC
(In reply to daniel.engberg.lists from comment #13)

Huh, moonjit is the integration fork I sent a PR to before it was called moonjit.

I'm for moonjit then. Though my interest in this has significantly lowered since neovim gained support for normal lua.. (and I switched to another editor later anyway lol)
Comment 15 Adam Weinberger freebsd_committer freebsd_triage 2020-03-21 19:25:51 UTC
Greg and Daniel, I really appreciate your input here! You know far more about this than I do.

Do you have a feel for moonjit vs raptorjit?

Also, is there a substantive benefit to luajit over lua in neovim?
Comment 16 Val Packett 2020-03-22 20:27:57 UTC
(In reply to Adam Weinberger from comment #15)

Moon expands portability (powerpc64, s390x), Raptor destroys portability ("removing #ifdef features that are not required for Linux/x86-64 e.g. Windows support, 32-bit heap support, and non-x86 backends"). Raptor is not suitable for replacing an OS package of luajit, Moon is.
Comment 17 Mikael Urankar freebsd_committer freebsd_triage 2020-11-17 16:07:31 UTC
any progress on this?
Comment 18 Daniel Engberg freebsd_committer freebsd_triage 2020-12-02 08:42:07 UTC
moonjit is dead so I'd suggest that we should point everything to openresty fork.
Comment 19 Sergey A. Osokin freebsd_committer freebsd_triage 2022-01-28 02:58:53 UTC

we'd probably need to close this PR since we have three ports of luajit:


The last one is recent version, i.e. 2.1.0-beta3.

Please let me know your thoughts.

Thank you.
Comment 20 Mikael Urankar freebsd_committer freebsd_triage 2022-01-28 10:06:22 UTC
(In reply to Sergey A. Osokin from comment #19)
as long as lang/luajit is broken on aarch64 this PR must remain open.
Comment 21 Sergey A. Osokin freebsd_committer freebsd_triage 2022-01-28 14:42:08 UTC
(In reply to Mikael Urankar from comment #20)

Thanks, Mikael.  Any plans to backport aarch64 staff from luajit-devel?
Comment 22 Daniel Engberg freebsd_committer freebsd_triage 2022-01-28 19:45:55 UTC
...or just move every port to openresty like Alpine Linux?
Comment 23 Mikael Urankar freebsd_committer freebsd_triage 2022-01-30 14:50:21 UTC
(In reply to Sergey A. Osokin from comment #21)
luajit is almost 5 years old. I don't see myself backporting 5 years worth of development just to support aarch64. We should just consider 2.1.beta3 as the latest release or move to openresty.
Comment 24 Sergey A. Osokin freebsd_committer freebsd_triage 2022-01-30 15:49:16 UTC
(In reply to Mikael Urankar from comment #23)

Alright, that's exactly what I replied earlier, latest version of luajit 2.1.0-beta3 is available from lang/luajit-devel port.
Comment 25 Mikael Urankar freebsd_committer freebsd_triage 2022-01-30 16:32:06 UTC
(In reply to Sergey A. Osokin from comment #24)
Sorry but I don't understand. Are you gonna use luajit-devel instead of luajit for all consumers and deorbit luajit?
Comment 26 Sergey A. Osokin freebsd_committer freebsd_triage 2022-01-30 17:29:56 UTC
(In reply to Mikael Urankar from comment #25)

I'm on position to have options to choose, so I'd suggest to take a look on databases/redis, where it's possible to build three different flavors of the key-value database: lua, luajit, and luajit-openresty.

Another idea is to create a framework as we have for four versions of lua.
Comment 27 Adam Weinberger freebsd_committer freebsd_triage 2022-01-31 07:24:41 UTC
(In reply to Sergey A. Osokin from comment #26)

Is there a use case for luajit anymore? Per upstream, it will never see another actual release, and consumers tend to target openresty anyway.

I don't think very many people would actually care to switch their luajit backend at will. I think the majority of people would just like a lua backend that works, receives updates, and is highly compatible. AFAIK, of all the lua options (PUC and JIT), that means just luajit-openresty.
Comment 28 Val Packett 2022-01-31 19:02:47 UTC
(In reply to Adam Weinberger from comment #27)

> Per upstream, it will never see another actual release

luajit upstream is not dead anymore, Mike Pall is back, latest commits are 4 days ago:

Comment 29 Sergey A. Osokin freebsd_committer freebsd_triage 2022-01-31 19:12:57 UTC
(In reply to Greg V from comment #28)

Thanks, Greg, yeah, that's exactly what we have in lang/luajit-devel.
Comment 30 Daniel Engberg freebsd_committer freebsd_triage 2022-01-31 20:43:35 UTC
Looking at other distros and projects I think it makes most sense to use openresty for the tree as default and when/if there's a reasonable argument we can switch back instead of having ports pulling in different variants?