In D23300#614738, @dvl wrote:In D23300#614246, @missoline_protonmail.com wrote:Is anyone working on this?
I have been told that future/current release has some nasty stuff in it which doesn't work on FreeBSD. They have chosen to use Ubuntu and while they have previously worked to have this compatible with FreeBSD, that has ended. I am basing this on 2nd hand conversations with people I trust.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed Advanced Search
Advanced Search
Advanced Search
Dec 12 2020
Dec 12 2020
Dec 8 2020
Dec 8 2020
russ.haley_gmail.com added a comment to D23300: lang/mono: take maintainership, update to 6.8.0.105.
russ.haley_gmail.com added a comment to D23300: lang/mono: take maintainership, update to 6.8.0.105.
Just an FYI the DotNet Core guys are ramping up as well:
Oct 23 2020
Oct 23 2020
russ.haley_gmail.com added a comment to D23300: lang/mono: take maintainership, update to 6.8.0.105.
I have had to actively avoid using FreeBSD at times because of the lack of Mono or .Net Core support. PLEASE someone push SOMETHING. I would be happy to jump back into supporting Mono and help get the .Net Core to build natively on FreeBSD.
Jul 26 2020
Jul 26 2020
In D25797#571704, @andrew_tao173.riddles.org.uk wrote:5.3.6 is imminent, if there's any point at all in doing this cosmetic change then it could at least be folded into that.
Jul 25 2020
Jul 25 2020
russ.haley_gmail.com added a comment to D24510: [new port] devel/mingw-w64 - LLVM MingGW cross compilation toolchain for Windows Executables.
In D24510#571587, @russ.haley_gmail.com wrote:Hello,
I've been messing with this port in my time off.
I have been unable to get mingw-w64-clang-rt90 to build:
/usr/bin/sed -I '' 's,^FLAGS=""$,FLAGS="--sysroot=/usr/local/${TARGET}",' /usr/home/russellh/freebsd/ports/devel/mingw-w64-clang-wrapper/work/llvm-mingw-39f7bf5/wrappers/clang-target-wrapper.sh /usr/bin/sed -I '' 's,^export PATH=",export PATH="/usr/local/llvm90/bin:,' /usr/home/russellh/freebsd/ports/devel/mingw-w64-clang-wrapper/work/llvm-mingw-39f7bf5/wrappers/dlltool-wrapper.sh /usr/bin/sed -I '' 's,^export PATH=",export PATH="/usr/local/llvm90/bin:,' /usr/home/russellh/freebsd/ports/devel/mingw-w64-clang-wrapper/work/llvm-mingw-39f7bf5/wrappers/ld-wrapper.sh /usr/bin/sed -I '' 's,^export PATH=",export PATH="/usr/local/llvm90/bin:,' /usr/home/russellh/freebsd/ports/devel/mingw-w64-clang-wrapper/work/llvm-mingw-39f7bf5/wrappers/objdump-wrapper.sh ===> Building for mingw-w64-clang-wrapper-llvm90-20200217 cd /usr/home/russellh/freebsd/ports/devel/mingw-w64-clang-wrapper/work/llvm-mingw-39f7bf5 && /usr/bin/env WRAPPER_PREFIX=/usr/local/mingw-w64 LLVM_PREFIX=/usr/local/llvm90 TOOLCHAIN_ARCHS="i686 x86_64 armv7 aarch64" DESTDIR=/usr/home/russellh/freebsd/ports/devel/mingw-w64-clang-wrapper/work ./install-wrappers.sh "/usr/local" ===> Staging for mingw-w64-clang-wrapper-llvm90-20200217 ===> mingw-w64-clang-wrapper-llvm90-20200217 depends on package: llvm90>=0 - found ===> Generating temporary packing list cp -f -R /usr/home/russellh/freebsd/ports/devel/mingw-w64-clang-wrapper/work/usr/local/bin/ /usr/home/russellh/freebsd/ports/devel/mingw-w64-clang-wrapper/work/stage/usr/local/bin /bin/mkdir -p /usr/home/russellh/freebsd/ports/devel/mingw-w64-clang-wrapper/work/stage/usr/local/mingw-w64 cp -f -R /usr/home/russellh/freebsd/ports/devel/mingw-w64-clang-wrapper/work/usr/local/mingw-w64/bin/ /usr/home/russellh/freebsd/ports/devel/mingw-w64-clang-wrapper/work/stage/usr/local/mingw-w64/bin ====> Compressing man pages (compress-man) ===> Installing for mingw-w64-clang-wrapper-llvm90-20200217 ===> Checking if mingw-w64-clang-wrapper-llvm90 is already installed ===> Switching to root credentials for 'install' target ===> Registering installation for mingw-w64-clang-wrapper-llvm90-20200217 as automatic [jailbird] Installing mingw-w64-clang-wrapper-llvm90-20200217... ===> Returning to user credentials ===> mingw-w64-20200217 depends on package: mingw-w64-clang-wrapper-llvm90>=0 - found ===> Returning to build of mingw-w64-20200217 ===> mingw-w64-20200217 depends on package: mingw-w64-clang-rt90>=0 - not found /!\ WARNING /!\ Ports Collection support for your FreeBSD version has ended, and no ports are guaranteed to build on this system. Please upgrade to a supported release. ===> License LLVM PD LLVM2 accepted by the user ===> mingw-w64-clang-rt90-9.0.1 depends on file: /usr/local/sbin/pkg - found ===> Fetching all distfiles required by mingw-w64-clang-rt90-9.0.1 for building ===> Extracting for mingw-w64-clang-rt90-9.0.1 => SHA256 Checksum OK for compiler-rt-9.0.1.src.tar.xz. ===> Patching for mingw-w64-clang-rt90-9.0.1 ===> mingw-w64-clang-rt90-9.0.1 depends on package: llvm90=9.0.1 - not found ===> mingw-w64-clang-rt90-9.0.1 depends on package: llvm90=9.0.1 - not found *** Error code 1 Stop. make[1]: stopped in /usr/home/russellh/freebsd/ports/devel/mingw-w64-clang-rt *** Error code 1 Stop. make: stopped in /usr/home/russellh/freebsd/ports/devel/mingw-w64If I attempt to re-run the port, it doesn't even try to build LLVM90 because the target is already up to date:
russellh@jailbird ~/f/p/d/mingw-w64> make BATCH=yes ===> Staging for mingw-w64-20200217 ===> mingw-w64-20200217 depends on package: mingw-w64-clang-wrapper-llvm90>=0 - found ===> mingw-w64-20200217 depends on package: mingw-w64-clang-rt90>=0 - not found ===> mingw-w64-clang-rt90-9.0.1 depends on package: llvm90=9.0.1 - not found ===> mingw-w64-clang-rt90-9.0.1 depends on package: llvm90=9.0.1 - not found *** Error code 1 Stop. make[1]: stopped in /usr/home/russellh/freebsd/ports/devel/mingw-w64-clang-rt *** Error code 1 Stop. make: stopped in /usr/home/russellh/freebsd/ports/devel/mingw-w64 russellh@jailbird ~/f/p/d/mingw-w64> clang90 --version clang version 9.0.1 Target: x86_64-portbld-freebsd12.0 Thread model: posix InstalledDir: /usr/local/llvm90/binI've done this a few times now and even cleaned and tried different backends (FreeBSD targets, All non-experimental). I'm wondering if LLVM didn't build for the correct architecture? I noted there is no explicit port option for windows binaries (obviously) so I did select all non-experimental backends.
@theron.tarigo_gmail.com, you may know right away what I have done incorrectly? I assume from the language in our email that you were using this port prior to my uploading it. Did you ever install LLVM from a source other than the LLVM90 port? I wonder if LLVM was built with different backend settings and the files have lingered?
russ.haley_gmail.com added a comment to D24510: [new port] devel/mingw-w64 - LLVM MingGW cross compilation toolchain for Windows Executables.
I've been messing with this port in my time off.
In D14709#571443, @andrew_tao173.riddles.org.uk wrote:In D14709#571428, @russ.haley_gmail.com wrote:
- Removed non-relevant ports packages included by mistake
They were not included by mistake; they were the ports which would otherwise have broken by adding lua54 as per previous discussion.
However, the change to version selection logic from D24492 does hopefully obviate that issue, since now adding lua54 won't change the lua version used by any existing port.
Jul 25 2020, 5:13 AM · Restricted Project
Move lua:flavors from USES to LUAJIT_USES_OFF as per comments.
In D25784#571453, @andrew_tao173.riddles.org.uk wrote:I still think it's nuts to install multiple luarocks installations when the big feature of luarocks 3.x was the ability to handle multiple lua versions. But I'll withdraw my objection.
In D25784#571410, @russ.haley_gmail.com wrote:And in a fit of hopeful speculation I wonder if pkg can pick up the different flavors? Installations then become pkg install lua-luarocks53 if this is possible.
Adding flavors will cause all of lua51-luarocks, lua52-luarocks, lua53-luarocks, and (when lua54 is committed) lua54-luarocks to be built as separate packages.
(It is lua53-luarocks and not lua-luarocks53 for consistency with every other package, the convention for all language-version flavors is to use them as a prefix.)
But there's another issue that needs fixing here, which is that you're breaking the luajit option. The lua:flavors option has to go on the LUAJIT_USES_OFF line, not the USES line, because lua flavors don't work with luajit (which is forced to be 5.1). Better integration of luajit is something I've so far failed to work out a good solution for; luajit really ought to be its own flavor, but there are too many conflicts between that and stock lua 5.1.
You seem to be stuck between a luarock and a hard place... :)
Jul 24 2020
Jul 24 2020
russ.haley_gmail.com retitled D14709: [new port] lang/lua54 - new port for Lua 5.4.0 from lang/lua54 - new port for Lua 5.4.0 to [new port] lang/lua54 - new port for Lua 5.4.0.
Jul 24 2020, 9:40 PM · Restricted Project
russ.haley_gmail.com abandoned D13691: Update bsd.defaults.mk for lua to 5.3 and questions about lua.mk.
Would really like it if we could all work towards getting Lua 5.4 as the default version on FreeBSD!
- Removed non-relevant ports packages included by mistake
- Copied current Lua53 makefile and adjusted for Lua54.
- Moved OPTIONS variable block below build variables (will submit a correction to lua53 as well)
Jul 24 2020, 9:36 PM · Restricted Project
In D25784#571283, @andrew_tao173.riddles.org.uk wrote:In D25784#571185, @russ.haley_gmail.com wrote:In D25784#570925, @andrew_tao173.riddles.org.uk wrote:What's the justification for adding flavors, given that one luarocks install is supposed to be able to manage multiple lua versions?
When I try installing LuaRocks from ports/pkg I always get 5.2, regardless of the installed version of lua (due to the FreeBSD default Lua version of 5.2). The FreeBSD default means Luarocks is also configured for Lua 5.2 and the executable/script is called luarocks52. Perhaps I've done something wrong and there is an easier way around that, but this seems to perfectly fit the use case for flavors?
Luarocks has a --lua-version option that allows one copy of luarocks to manage rocks trees for multiple versions of Lua regardless of what version it itself uses. Therefore flavors are neither necessary nor desirable.
I have never used that option on any of the three platforms on which I use LuaRocks. Moreover, there is no way currently to generate config files (outside of installation) so a user must manually copy and modify the existing one (I agree that replicating configs is a simple task for an experienced user). I have a "feature request" with the LuaRocks team for a feature to create config files.
Added PORTREVISION. Corrected diff format.
In D25784#570923, @mat wrote:This needs to get a PORTREVISION bump.
Also, could you please use devel/arcanist to create/update reviews, or at least, create a diff with full context as it does. (Using svn diff -x -U9999 or git diff -U9999.)
In D25784#570925, @andrew_tao173.riddles.org.uk wrote:What's the justification for adding flavors, given that one luarocks install is supposed to be able to manage multiple lua versions?
Jul 23 2020
Jul 23 2020
Updated to use the official release Lua 5.4.0
Jul 23 2020, 5:30 AM · Restricted Project
May 2 2020
May 2 2020
russ.haley_gmail.com added a comment to D24510: [new port] devel/mingw-w64 - LLVM MingGW cross compilation toolchain for Windows Executables.
In D24510#539110, @theron.tarigo_gmail.com wrote:Thank you for working on this. You are welcome to claim maintainership if you'd like but that it also is not necessary as I do not wish to abandon this project.
The package uses mingw64 and Clang10
Does this pertain to planned work? The patch still shows
DISTVERSION= 9.0.1
etc.
Apr 20 2020
Apr 20 2020
russ.haley_gmail.com retitled D24510: [new port] devel/mingw-w64 - LLVM MingGW cross compilation toolchain for Windows Executables from devel/mingw-w64 - Clang LLVM cross compilation toolchian to devel/mingw-w64 - LLVM MingGW cross compilation toolchian for Windows Executables.
Apr 18 2020
Apr 18 2020
Luarocks has already been updated to 3.3.1 and this patch is broken. I'm abandoning this review.
Apr 18 2020, 6:04 AM · Restricted Project
Apr 17 2020
Apr 17 2020
In D14709#537546, @andrew_tao173.riddles.org.uk wrote:Update to lua 5.4.0-rc1
Update to match recent changes to Lua framework; connect to the build; add the new version to the list of supported versions in default-versions and Uses/lua.mk.
Allowing 5.4 in Uses/lua.mk does have the potential to break builds of ports that specify, e.g., USES=lua:53+ (so that the default version of 5.2 is not in range) and where they use interfaces that change from 5.3 to 5.4. I'm not sure how many cases of this there are (if any); I will do my own test run soon, but an exp-run will likely be needed at some point.
Now that there's an actual release candidate, we can think about pushing this forward.
Apr 17 2020, 5:42 AM · Restricted Project
Nov 8 2019
Nov 8 2019
I am testing this patch with LuaRocks (as noted in above). I removed all the OPTIONS that I had created which used flavors and added lua:51-54 to my USES:
Nov 8 2019, 5:56 AM · Restricted Project
Nov 5 2019
Nov 5 2019
russ.haley_gmail.com added inline comments to D14709: [new port] lang/lua54 - new port for Lua 5.4.0.
Nov 5 2019, 5:36 AM · Restricted Project
Patch out CFLAGS optimization in third party makefile as per handbook:
Nov 5 2019, 5:31 AM · Restricted Project
Oct 22 2019
Oct 22 2019
Patch out targets that added -Os to llex.o, lparser.o, and lcode.o.
Oct 22 2019, 4:13 AM · Restricted Project
In D14709#483029, @andrew_tao173.riddles.org.uk wrote:Looks like Roberto snuck some hardcoded -Os options into the makefile, we need to either patch those back out or think of something else to do with them.
Oct 22 2019, 3:48 AM · Restricted Project
Oct 19 2019
Oct 19 2019
This has been implemented as a ports option and is already in the tree
This version is updated to use LUA_FLAVORS from here: https://reviews.freebsd.org/D16494. I have implemented options for each flavor.
Oct 19 2019, 5:27 AM · Restricted Project
I worked with the upstream maintainer to fix the issue with the default FreeBSD unzip(1) implementation. The bug existed because LuaRocks would test for the existance of unzip using the -h option, which is not present in FreeBSD. LuaRocks now implicitly recognizes that FreeBSD has unzip so it doesn't test for it.
Oct 19 2019, 4:18 AM · Restricted Project
Oct 18 2019
Oct 18 2019
Added option for arc4random random seed. I tested running math.random and it looked randomish to me? I don't know what I'm looking for but the flags were present in the build output:
Oct 18 2019, 5:38 AM · Restricted Project
Addressed andrews comments. Fixed missing patch for LIBEDIT_DL and tested LIBEDIT_DL option. twice. :-/
Oct 18 2019, 5:13 AM · Restricted Project
New patch to address comments, thank you Andrew.
Oct 18 2019, 4:18 AM · Restricted Project
Oct 17 2019
Oct 17 2019
hmmmm?
Oct 17 2019, 4:18 AM · Restricted Project
Is this patch for arc4random something that we should look at applying?
Oct 17 2019, 4:04 AM · Restricted Project
Updated for the latest Lua 5.4 Beta release.
Oct 17 2019, 4:01 AM · Restricted Project
Oct 15 2019
Oct 15 2019
In D14709#478684, @andrew_tao173.riddles.org.uk wrote:Now that a 5.4.0-beta release has been made, and there are signs that features are actually stabilizing (there have been many changes since work2), perhaps we could pick this up again. The distinfo needs an update of course.
Oct 15 2019, 4:49 AM · Restricted Project
Jun 16 2019
Jun 16 2019
Updated diff for 3.1.3
Jun 16 2019, 6:26 PM · Restricted Project
russ.haley_gmail.com retitled D17814: devel/lua-luarocks: update to 3.2.1 from devel/lua-luarocks: update to 3.0.4 to devel/lua-luarocks: update to 3.1.3.
Jun 16 2019, 6:24 PM · Restricted Project
Mar 31 2019
Mar 31 2019
Mar 26 2019
Mar 26 2019
Hi @mat, this port update has been languishing for some time now. How do I get this committed without @jbeich removing his change request? I completed the requested changes some time ago and have been using this port update for a few weeks now.
Mar 26 2019, 5:35 PM · Restricted Project
Mar 22 2019
Mar 22 2019
I've installed cqueues, ldoc and penlight on freebsd 12.0 using Lua52. Output for ldoc and penlight installation:
Mar 22 2019, 4:28 AM · Restricted Project
Feb 16 2019
Feb 16 2019
In D18939#405379, @andrew_tao173.riddles.org.uk wrote:While we're in here changing stuff, is it also worth adding a patch for the upvaluejoin bug? The bug in itself is a non-issue, but some prat filed a CVE for it.
Jan 29 2019
Jan 29 2019
Jan 29 2019, 6:26 AM · Restricted Project
I just tested on 12-Release using a clean /usr/ports directory. The system force me to install Lua5.2 because Mk/bsd.default-versions.mk isn't patched (the upside is luarocks is tested with Lua52 now!). How do I go about getting the default version bumped? I would guess an exp-run would be required? I'd also like to see an exp-run to find out what's not current. @andrew_tao173.riddles.org.uk also has a patch in the works to add FLAVOURS to lua here: https://reviews.freebsd.org/D16494
Jan 29 2019, 6:24 AM · Restricted Project
russ.haley_gmail.com retitled D18939: Add pthread to lang/lua53 from Add pthread Option to lang/lua53 to Add pthread to lang/lua53.
Add patch that removes use of unsupported -h option. The option is used to check for the existence of unzip, which is present in the base FreeBSD image.
Jan 29 2019, 5:46 AM · Restricted Project
Jan 28 2019
Jan 28 2019
Add PORTVERSION.
Jan 27 2019
Jan 27 2019
Added comment noting bug.
Jan 26 2019
Jan 26 2019
Removed -pthread options. Added -pthread to LIBS.
Jan 25 2019
Jan 25 2019
In D18939#405045, @andrew_tao173.riddles.org.uk wrote:I think in the short term there's no point in adding an option, and instead we should just append -lpthread to LIBS, since we ignore LIBS when building the .so anyway.
(I've tried this and the dependencies all seem to come out right.)
Having the lua53 binary pull in libthr is certainly harmless (it has no effect unless someone loads a module that uses threads, in which case they're referencing it anyway) and if it's a sufficient workaround for the bug, then why not.
Removed whitespace changes, used recommended svn diff options.
Jan 24 2019
Jan 24 2019
Removed commented out code.
Nov 9 2018
Nov 9 2018
In D17814#382917, @jbeich wrote:What is the benefit of using archivers/unzip? unzip -h just shows help string. -h and --version are GNUisms. On BSDs one is supposed to read manpages first before playing with fire (e.g., shutdown -h ;). unzip is always available on DragonFly, FreeBSD and NetBSD but not OpenBSD. In the ports tree only FreeBSD and DragonFly are supported. While you can probably emulate which(1) in Lua then submit the fix upstream, in the ports patching out the offending check is another option.
Nov 9 2018, 9:58 PM · Restricted Project
In D17814#382652, @russ.haley_gmail.com wrote:In D17814#380958, @jbeich wrote:Doesn't work:
$ pkg install lua52-luarocks $ luarocks-5.2 install --local penlight Warning: Failed searching manifest: Failed extracting manifest file: 'unzip -n' program not found. Make sure unzip is installed and is available in your PATH (or you may want to edit the 'variables.UNZIP' value in file '/usr/local/etc/luarocks/config-5.2.lua') Installing https://raw.githubusercontent.com/rocks-moonscript-org/moonrocks-mirror/master/penlight-1.5.4-1.rockspec Missing dependencies for penlight 1.5.4-1: luafilesystem (not installed) penlight 1.5.4-1 depends on luafilesystem (not installed) Warning: Failed searching manifest: Failed extracting manifest file: 'unzip -n' program not found. Make sure unzip is installed and is available in your PATH (or you may want to edit the 'variables.UNZIP' value in file '/usr/local/etc/luarocks/config-5.2.lua') Installing https://raw.githubusercontent.com/rocks-moonscript-org/moonrocks-mirror/master/luafilesystem-1.7.0-2.src.rock Error: Failed installing dependency: https://raw.githubusercontent.com/rocks-moonscript-org/moonrocks-mirror/master/luafilesystem-1.7.0-2.src.rock - Failed unpacking rock file: /tmp/luarocks_luarocks-rock-luafilesystem-1.7.0-2-h01bYU/luafilesystem-1.7.0-2.src.rock: 'unzip -n' program not found. Make sure unzip is installed and is available in your PATH (or you may want to edit the 'variables.UNZIP' value in file '/usr/local/etc/luarocks/config-5.2.lua')I posted on the lua mailing list and it turns out luarocks 3.0.4 uses unzip -h to check for the existence of unzip. The unzip included with base FreeBSD doesn't provide this functionality but the version in ports/archivers does. As noted in the error message, the config-X.X.lua file provides a variable for UNZIP. I set the variable to point at /usr/local/bin/unzip and successfully built and installed luasec (via luarocks).
SO, my plan going forward is to add a dependency to archivers/unzip and patch the luarocks-X.X.lua config file. One thing I don't know yet is if I should add a patch in files/ for pre-build patching or if a post build step is required.
Nov 9 2018, 6:38 AM · Restricted Project
In D17814#380958, @jbeich wrote:Doesn't work:
$ pkg install lua52-luarocks $ luarocks-5.2 install --local penlight Warning: Failed searching manifest: Failed extracting manifest file: 'unzip -n' program not found. Make sure unzip is installed and is available in your PATH (or you may want to edit the 'variables.UNZIP' value in file '/usr/local/etc/luarocks/config-5.2.lua') Installing https://raw.githubusercontent.com/rocks-moonscript-org/moonrocks-mirror/master/penlight-1.5.4-1.rockspec Missing dependencies for penlight 1.5.4-1: luafilesystem (not installed) penlight 1.5.4-1 depends on luafilesystem (not installed) Warning: Failed searching manifest: Failed extracting manifest file: 'unzip -n' program not found. Make sure unzip is installed and is available in your PATH (or you may want to edit the 'variables.UNZIP' value in file '/usr/local/etc/luarocks/config-5.2.lua') Installing https://raw.githubusercontent.com/rocks-moonscript-org/moonrocks-mirror/master/luafilesystem-1.7.0-2.src.rock Error: Failed installing dependency: https://raw.githubusercontent.com/rocks-moonscript-org/moonrocks-mirror/master/luafilesystem-1.7.0-2.src.rock - Failed unpacking rock file: /tmp/luarocks_luarocks-rock-luafilesystem-1.7.0-2-h01bYU/luafilesystem-1.7.0-2.src.rock: 'unzip -n' program not found. Make sure unzip is installed and is available in your PATH (or you may want to edit the 'variables.UNZIP' value in file '/usr/local/etc/luarocks/config-5.2.lua')
Nov 9 2018, 4:19 AM · Restricted Project
Nov 5 2018
Nov 5 2018
Patch file was removed in error. Rebased patch file for src/luarocks/core/cfg.lua.
Nov 5 2018, 5:51 AM · Restricted Project
In D17814#380958, @jbeich wrote:Doesn't work:
$ pkg install lua52-luarocks $ luarocks-5.2 install --local penlight Warning: Failed searching manifest: Failed extracting manifest file: 'unzip -n' program not found. Make sure unzip is installed and is available in your PATH (or you may want to edit the 'variables.UNZIP' value in file '/usr/local/etc/luarocks/config-5.2.lua') Installing https://raw.githubusercontent.com/rocks-moonscript-org/moonrocks-mirror/master/penlight-1.5.4-1.rockspec Missing dependencies for penlight 1.5.4-1: luafilesystem (not installed) penlight 1.5.4-1 depends on luafilesystem (not installed) Warning: Failed searching manifest: Failed extracting manifest file: 'unzip -n' program not found. Make sure unzip is installed and is available in your PATH (or you may want to edit the 'variables.UNZIP' value in file '/usr/local/etc/luarocks/config-5.2.lua') Installing https://raw.githubusercontent.com/rocks-moonscript-org/moonrocks-mirror/master/luafilesystem-1.7.0-2.src.rock Error: Failed installing dependency: https://raw.githubusercontent.com/rocks-moonscript-org/moonrocks-mirror/master/luafilesystem-1.7.0-2.src.rock - Failed unpacking rock file: /tmp/luarocks_luarocks-rock-luafilesystem-1.7.0-2-h01bYU/luafilesystem-1.7.0-2.src.rock: 'unzip -n' program not found. Make sure unzip is installed and is available in your PATH (or you may want to edit the 'variables.UNZIP' value in file '/usr/local/etc/luarocks/config-5.2.lua')In D17814#380680, @russ.haley_gmail.com wrote:Argh! Sorry about that @jbeich. I forgot to delete the patch in svn.
Why? Maintainer is supposed to be able to rebase patches. If patches are dropped for other reasons rationale has to be explicitly stated (can be short).
Quite right. A maintainer should also know better than to look at the patched file in the work directory and come to the incorrect conclusion that the patch is no longer needed. :-/
I'll push a rebased patch and then look why unzip might not be working next chance I get.
Nov 5 2018, 5:45 AM · Restricted Project
Nov 2 2018
Nov 2 2018
Corrections as per feedback from @jbeich.
Nov 2 2018, 5:45 AM · Restricted Project
Argh! Sorry about that @jbeich. I forgot to delete the patch in svn.
Nov 2 2018, 5:38 AM · Restricted Project
Nov 2 2018, 5:34 AM · Restricted Project
russ.haley_gmail.com retitled D17814: devel/lua-luarocks: update to 3.2.1 from devel/lua-luarocks: update to 3.0.1 to devel/lua-luarocks: update to 3.0.4.
Nov 2 2018, 4:49 AM · Restricted Project
russ.haley_gmail.com retitled D17814: devel/lua-luarocks: update to 3.2.1 from Bump lua-rocks to 3.0.4 to devel/lua-luarocks: update to 3.0.1.
Nov 2 2018, 4:49 AM · Restricted Project
Nov 2 2018, 4:45 AM · Restricted Project
Aug 14 2018
Aug 14 2018
In D13690#354595, @andrew_tao173.riddles.org.uk wrote:So, once again, are we done here? I have nothing more to add.
Aug 14 2018, 3:35 AM · Restricted Project
Jul 28 2018
Jul 28 2018
In D14709#350017, @andrew_tao173.riddles.org.uk wrote:In D14709#349874, @russ.haley_gmail.com wrote:Hi @dbn, Lua 5.4 is still in a beta phase so my preference is to hold this port until the Lua 5.4 official release, then update and push it to the repository. @andrew_tao173.riddles.org.uk has already indicated his preference to hold the port until the Lua release (unless something has changed?)
I didn't say to hold it until release, I said -work2 was "not ready for prime time" or some such. But in the absence of any statement from the Lua devs about the likely timing of a -work3 or a final 5.4.0, I see these options:
- make the port available anyway as is (it doesn't seem unusual to have ports for non-final releases of languages, see e.g. tcl87)
- add a patch to stop it enabling the generational GC by default in lua.c (generational GC has known crash/corruption bugs in -work2) and make it available
- combine options 1 and 2 by making the patch an option
- sit on it until there's a (hopefully more stable) -work3 or final release, but we have no idea of the timeline for this
I'm not all that keen on option 1, but any of options 1-3 might be useful from a Lua development point of view.
Another factor to consider is updating Uses/lua.mk (which doesn't recognize 5.4 yet). I have been testing the idea of giving USES=lua a flavors option for lua modules to use and it seems to work well - I could put that work up as a separate revision for review?
Jul 28 2018, 11:44 PM · Restricted Project
In D14709#349808, @dbn wrote:I cannot comment on the specifics of lua (i.e. do these changes work), I've never used lua and haven't tested it. However, I am happy with the above changes with the following comments:
- I assume the indentation is correct, despite it not rendering correctly in Chrome
- Please try to upstream all patches
@jbeich: your thoughts?
And, who will commit this change?
Jul 28 2018, 3:20 PM · Restricted Project
In D16274#349185, @andrew_tao173.riddles.org.uk wrote:Style/format fixes
Also remove redundant --versioned-rocks-dir option
Jul 28 2018, 2:58 PM · Restricted Project
Jul 28 2018, 2:56 PM · Restricted Project
In D13690#349766, @andrew_tao173.riddles.org.uk wrote:So are we done here? I have nothing more to add.
Jul 28 2018, 2:24 AM · Restricted Project
In D14709#349765, @andrew_tao173.riddles.org.uk wrote:So are we done here? I have nothing more to add.
Jul 28 2018, 2:22 AM · Restricted Project
Jul 28 2018, 2:21 AM · Restricted Project
Jul 24 2018
Jul 24 2018
In D16274#348497, @mat wrote:Please revert all the whitespace changes, it is impossible to read the diff with all the noise.
Jul 24 2018, 2:00 PM · Restricted Project
"Reverted" whitespace cleanup.
Jul 24 2018, 4:29 AM · Restricted Project
Whitespace alignment. It looks great in geany...
Jul 24 2018, 4:26 AM · Restricted Project
- Updated as per comments. Thanks @mat.
- LuaRocks has been released. Updated port to release download.
Jul 24 2018, 4:16 AM · Restricted Project
Jul 19 2018
Jul 19 2018
Jul 19 2018, 12:10 AM · Restricted Project
- Updated according to comments. Thanks @mat.
- Updated port description to quote from the Lua.org website. Now the same as lua-5.3.pc.in.
- Removed extraneous patch of freebsd target in src/Makefile. Thanks @andrew_tao173.riddles.org.uk
Jul 19 2018, 12:07 AM · Restricted Project
Jul 19 2018, 12:02 AM · Restricted Project
Jul 17 2018
Jul 17 2018
Jul 17 2018, 7:34 PM · Restricted Project
Jul 17 2018, 7:01 PM · Restricted Project
Changed no name as per comment from @mat.
Jul 17 2018, 6:57 PM · Restricted Project
Jul 17 2018, 4:36 AM · Restricted Project
Cleanup mistake. Lua counts from 1, ports revisions do not. :)
Jul 17 2018, 4:28 AM · Restricted Project
Jul 17 2018, 4:27 AM · Restricted Project
Cleanup. Added port revision number.
Jul 17 2018, 4:23 AM · Restricted Project
Jul 15 2018
Jul 15 2018
There seems to be a bug in the base LuaRocks Makefile that requires running 'make build' twice. Therefore this patch works if you run make twice. I have a message on the Lua mailing list for further information from Hisham.
Jul 15 2018, 8:39 PM · Restricted Project
Jul 15 2018, 4:21 AM · Restricted Project
Corrected soname value.
Jul 15 2018, 2:44 AM · Restricted Project