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.

Just an FYI the DotNet Core guys are ramping up as well:

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.

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.

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-w64

If 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/bin

I'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?

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.

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... :)

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)

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?

Updated to use the official release Lua 5.4.0

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.

Luarocks has already been updated to 3.3.1 and this patch is broken. I'm abandoning this review.

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.

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:

Patch out CFLAGS optimization in third party makefile as per handbook:

Patch out targets that added -Os to llex.o, lparser.o, and lcode.o.

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.

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.

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.

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:

Addressed andrews comments. Fixed missing patch for LIBEDIT_DL and tested LIBEDIT_DL option. twice. :-/

New patch to address comments, thank you Andrew.

hmmmm?

Is this patch for arc4random something that we should look at applying?

Updated for the latest Lua 5.4 Beta release.

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.

Updated diff for 3.1.3

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.

I've installed cqueues, ldoc and penlight on freebsd 12.0 using Lua52. Output for ldoc and penlight installation:

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.

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

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.

Add PORTVERSION.

Added comment noting bug.

Removed -pthread options. Added -pthread to LIBS.

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.

Removed commented out code.

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.

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.

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')

Patch file was removed in error. Rebased patch file for src/luarocks/core/cfg.lua.

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.

Corrections as per feedback from @jbeich.

Argh! Sorry about that @jbeich. I forgot to delete the patch in svn.

In D13690#354595, @andrew_tao173.riddles.org.uk wrote:

So, once again, are we done here? I have nothing more to add.

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:

1. 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)
2. 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
3. combine options 1 and 2 by making the patch an option
4. 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?

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:

1. I assume the indentation is correct, despite it not rendering correctly in Chrome
2. Please try to upstream all patches

@jbeich: your thoughts?

And, who will commit this change?

In D16274#349185, @andrew_tao173.riddles.org.uk wrote:

Style/format fixes

Also remove redundant --versioned-rocks-dir option

In D13690#349766, @andrew_tao173.riddles.org.uk wrote:

So are we done here? I have nothing more to add.

In D14709#349765, @andrew_tao173.riddles.org.uk wrote:

So are we done here? I have nothing more to add.

In D16274#348497, @mat wrote:

Please revert all the whitespace changes, it is impossible to read the diff with all the noise.

"Reverted" whitespace cleanup.

Whitespace alignment. It looks great in geany...

• Updated as per comments. Thanks @mat.
• LuaRocks has been released. Updated port to release download.

• 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

Changed no name as per comment from @mat.

Cleanup mistake. Lua counts from 1, ports revisions do not. :)

Cleanup. Added port revision number.

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.

Corrected soname value.