4 ms·

> DO NOT use pseudo-releases or tarballs created by third parties. In particular, automatic tarballs made by GitHub and other mirrors are lacking the .git direc

> DO NOT use pseudo-releases or tarballs created by third parties. In particular, automatic tarballs made by GitHub and other mirrors are lacking the .git directory and will not properly build anymore. It's a little concerning that their build process relies on a .git directory being present. That's going to make it quite tough for packagers to actually package this.

corsix 3y ago
I think https://github.com/LuaJIT/LuaJIT/commit/6a2163a6b45d6d2515993e829153442f1cdf5631 https://github.com/LuaJIT/LuaJIT/commit/6a2163a6b45d6d251599... improved things a bit, notably making automatic tarballs work again.
- 0xcoffee 3y ago
  The export-subst attribute was new to me. Here is a description of what it does: If the attribute export-subst is set for a file then Git will expand several placeholders when adding this file to an archive. The expansion depends on the availability of a commit ID, i.e., if git-archive[1] has been given a tree instead of a commit or a tag then no replacement will be done. The placeholders are the same as those for the option --pretty=format: of git-log[1], except that they need to be wrapped like this: $Format:PLACEHOLDERS$ in the file. E.g. the string $Format:%H$ will be replaced by the commit hash. However, only one %(describe) placeholder is expanded per archive to avoid denial-of-service attacks. https://git-scm.com/docs/gitattributes#_export_subst https://git-scm.com/docs/gitattributes#_export_subst
masklinn 3y ago
Surely a packager would be working off of the actual releases not a random git archive? And if they can’t wait for official releases, they’d be working off of the git repo?
- Twirrim 3y ago
  > Surely a packager would be working off of the actual releases not a random git archive? There are no official releases. To quote from the linked email: > No release tarballs or binaries are made available. Please do not use obsolete versions from older tarballs or zip files. Please remove any outdated links to these downloads -- they will cease to work soon. The only way to get a release version of LuaJIT is to compile it from the git repo.
  - fullstop 3y ago
    > The only way to get a release version of LuaJIT is to compile it from the git repo. It will be interesting to see how this is packaged in, say, Ubuntu. Will they assign their own version numbers? Dates?
    - planede 3y ago
      I would say something along the lines of git-describe, and packages would need to depend on the exact version. If upstream can't commit to compatibility across release versions then I don't see it happening in distros either.
  - layer8 3y ago
    Sounds like eternal beta.
    - andersa 3y ago
      It has been an eternal, abandoned beta for many years. But sounds like work resumed now. Maybe one day it shall be stable.
- kzrdude 3y ago
  The packagers can make their own snapshot, but they don't want to grab a full .git directory for the source - distributions such as Debian never want to do that: The packager is responsible for auditing all the code including copyright status in the artifacts - best not have the whole history of the project included in that case, because the task is then a little bit too big.
  - fullstop 3y ago
    You can clone a specific tag or branch from a git repository without the full history. It looks like LuaJIT's git repository does not support this, although the github mirror does: # git clone -b v2.1.ROLLING --depth 1 git@github.com:LuaJIT/LuaJIT.git The git log looks like this: commit 2090842410e0ba6f81fad310a77bf5432488249a (grafted, HEAD, tag: v2.1.ROLLING) Author: Mike Pall <mike> Date: Mon Aug 21 03:18:35 2023 +0200 Merge branch 'master' into v2.1
dividuum 3y ago
Somewhat difficult to find on the linked list archive, but this exact issue was dicussed there. See the followup mails: https://www.freelists.org/archive/luajit/08-2023?threads=1 https://www.freelists.org/archive/luajit/08-2023?threads=1
andersa 3y ago
I'm confused what you mean. What is a packager doing here? I always assumed that the intention of this library is that you, as a developer, compile and embed it in a product that needs a scripting engine. What use would a standalone LuaJIT package be?
- fullstop 3y ago
  It's available as a package, and a library, in most Linux distributions. It includes the library and the interpreter. edit: I have a few scripts with #!/usr/bin/luajit as the shebang line.
  - andersa 3y ago
    Interesting, that's neat. Somehow didn't realize using it like this was an option, but now that you mention it...
    - kzrdude 3y ago
      libluajit is a drop-in replacement for the regular liblua (v5.1)
- deleted 3y ago
  [deleted]
- Bu9818 3y ago
  Even ignoring the installed interpreter, libraries on Linux distributions are usually installed system-wide as their own packages which other packages depend on (neovim, mpv, cgit, etc.)
- kragen 3y ago
  if you apt install libluajit-5.1-dev you can compile and link your c programs with it without having to compile it yourself similarly if you are writing programs in lua rather than in c you can run them in luajit if you just apt install luajit if you want to release your programs as free software so other people can compile and link them, it's important for them to be able to get the version of luajit you were using so they can debug why your program doesn't work in the current version of luajit
legends2k 3y ago
I've never needed to build LuaJIT as a git repo. Just download the tarball and did: make and make install; all I have is GNU make and GCC. Am I missing something?
- kzrdude 3y ago
  The build script changed slightly four days ago, and you will need git in the future (and build from a checkout of the repo.)
  - legends2k 3y ago
    That's a shame; I thought it was one of the nice features of LuaJIT. In fact it built its own intermediate tools needed to build LuaJIT dist.
    - Rochus 3y ago
      You don't need Git. It just issues a warning if it's not able to infer git information.
imtringued 3y ago
It could be using git submodules or tags. That isn't very concerning.
kragen 3y ago
yeah, obviously this isn't acceptable for things like debian, ubuntu, or guix

corsix 3y ago

I think https://github.com/LuaJIT/LuaJIT/commit/6a2163a6b45d6d2515993e829153442f1cdf5631 https://github.com/LuaJIT/LuaJIT/commit/6a2163a6b45d6d251599... improved things a bit, notably making automatic tarballs work again.

0xcoffee 3y ago
The export-subst attribute was new to me. Here is a description of what it does: If the attribute export-subst is set for a file then Git will expand several placeholders when adding this file to an archive. The expansion depends on the availability of a commit ID, i.e., if git-archive[1] has been given a tree instead of a commit or a tag then no replacement will be done. The placeholders are the same as those for the option --pretty=format: of git-log[1], except that they need to be wrapped like this: $Format:PLACEHOLDERS$ in the file. E.g. the string $Format:%H$ will be replaced by the commit hash. However, only one %(describe) placeholder is expanded per archive to avoid denial-of-service attacks. https://git-scm.com/docs/gitattributes#_export_subst https://git-scm.com/docs/gitattributes#_export_subst

masklinn 3y ago

Surely a packager would be working off of the actual releases not a random git archive? And if they can’t wait for official releases, they’d be working off of the git repo?

Twirrim 3y ago
> Surely a packager would be working off of the actual releases not a random git archive? There are no official releases. To quote from the linked email: > No release tarballs or binaries are made available. Please do not use obsolete versions from older tarballs or zip files. Please remove any outdated links to these downloads -- they will cease to work soon. The only way to get a release version of LuaJIT is to compile it from the git repo.
- fullstop 3y ago
  > The only way to get a release version of LuaJIT is to compile it from the git repo. It will be interesting to see how this is packaged in, say, Ubuntu. Will they assign their own version numbers? Dates?
  - planede 3y ago
    I would say something along the lines of git-describe, and packages would need to depend on the exact version. If upstream can't commit to compatibility across release versions then I don't see it happening in distros either.
- layer8 3y ago
  Sounds like eternal beta.
  - andersa 3y ago
    It has been an eternal, abandoned beta for many years. But sounds like work resumed now. Maybe one day it shall be stable.
kzrdude 3y ago
The packagers can make their own snapshot, but they don't want to grab a full .git directory for the source - distributions such as Debian never want to do that: The packager is responsible for auditing all the code including copyright status in the artifacts - best not have the whole history of the project included in that case, because the task is then a little bit too big.
- fullstop 3y ago
  You can clone a specific tag or branch from a git repository without the full history. It looks like LuaJIT's git repository does not support this, although the github mirror does: # git clone -b v2.1.ROLLING --depth 1 git@github.com:LuaJIT/LuaJIT.git The git log looks like this: commit 2090842410e0ba6f81fad310a77bf5432488249a (grafted, HEAD, tag: v2.1.ROLLING) Author: Mike Pall <mike> Date: Mon Aug 21 03:18:35 2023 +0200 Merge branch 'master' into v2.1

dividuum 3y ago

Somewhat difficult to find on the linked list archive, but this exact issue was dicussed there. See the followup mails: https://www.freelists.org/archive/luajit/08-2023?threads=1 https://www.freelists.org/archive/luajit/08-2023?threads=1

andersa 3y ago

I'm confused what you mean. What is a packager doing here? I always assumed that the intention of this library is that you, as a developer, compile and embed it in a product that needs a scripting engine. What use would a standalone LuaJIT package be?

fullstop 3y ago
It's available as a package, and a library, in most Linux distributions. It includes the library and the interpreter. edit: I have a few scripts with #!/usr/bin/luajit as the shebang line.
- andersa 3y ago
  Interesting, that's neat. Somehow didn't realize using it like this was an option, but now that you mention it...
  - kzrdude 3y ago
    libluajit is a drop-in replacement for the regular liblua (v5.1)
deleted 3y ago
[deleted]
Bu9818 3y ago
Even ignoring the installed interpreter, libraries on Linux distributions are usually installed system-wide as their own packages which other packages depend on (neovim, mpv, cgit, etc.)
kragen 3y ago
if you apt install libluajit-5.1-dev you can compile and link your c programs with it without having to compile it yourself similarly if you are writing programs in lua rather than in c you can run them in luajit if you just apt install luajit if you want to release your programs as free software so other people can compile and link them, it's important for them to be able to get the version of luajit you were using so they can debug why your program doesn't work in the current version of luajit

legends2k 3y ago

I've never needed to build LuaJIT as a git repo. Just download the tarball and did: make and make install; all I have is GNU make and GCC. Am I missing something?

kzrdude 3y ago
The build script changed slightly four days ago, and you will need git in the future (and build from a checkout of the repo.)
- legends2k 3y ago
  That's a shame; I thought it was one of the nice features of LuaJIT. In fact it built its own intermediate tools needed to build LuaJIT dist.
  - Rochus 3y ago
    You don't need Git. It just issues a warning if it's not able to infer git information.

imtringued 3y ago

It could be using git submodules or tags. That isn't very concerning.

kragen 3y ago

yeah, obviously this isn't acceptable for things like debian, ubuntu, or guix