Add remaining guile ports; this should now be complete.

Update with more ports, and improved logic in guile.mk.

Superseded by https://reviews.freebsd.org/D40194

so... two years after everyone seems to have accepted it, maybe someone would commit it?

I have to agree with kib here, the right fix is to unblock the signal around open/read/write/close rather than this business with flags.

The obvious example is doing this in make.conf:

The whole handling of fsreadfd and fswritefd makes me itch. They are opened and closed at random places, and some places test for them being < 0, but they are not statically initialized to -1 nor set to -1 when closed. I would honestly not be surprised if there were some weird combination of options that caused data blocks to be written to stdin rather than the disk.

As far as I can tell, gjournal_check assumes fswritefd is already open, so this is no good.

Looks basically sane to me.

In D24325#635020, @arrowd wrote:

The comment about aclocal/guile.m4 file is not relevant anymore?

Update to 3.0.5, removing patches that were fixed upstream

Don't fold case of variable names. Allow using var@ to unset variables, since some places distinguish between empty and undefined values.

Abandoning; Mina has taken this over in D27962

You could have just put this one on bugzilla with maintainer-approval set on the patch, for a routine update putting it up here seems overkill.

Update to 3.0.4 plus cherry-picked JIT fixes for arm.

Any chance of some review or action on this please?

Update to 5.4.1

Here's one that updates to 5.3.6 and has more extensive changes to variable order that satisfies portclippy, barring the use of a few variables it doesn't know about.

Your login.conf changes need to be rebased against an up-to-date version from current - you're undoing the introduction of the "mail" capability and other changes related to environment vars from D21481.

Rewrite to match changes to logic, and extend some parts slightly.

Also PORTREVISION should not be changed if there are no functional changes, since you'd just be forcing rebuilds/updates of every dependent port for no reason.

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 D14709#571480, @russ.haley_gmail.com wrote:

Ah, I thought I had mucked something. Shall I restore them?

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 D14709#571428, @russ.haley_gmail.com wrote:

• Removed non-relevant ports packages included by mistake

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?

I think, in fact, the only useful change would be to install config files for every supported lua version rather than just the default one.

What's the justification for adding flavors, given that one luarocks install is supposed to be able to manage multiple lua versions?

Updates to address comments.

Lua 5.4.0 is now released, so this is now a blocking issue for the lua54 port.

Move to an earlier place in processing (in fact the earliest possible place, just after PKGORIGIN is set).

In D22189#557452, @mat wrote:

Is it possible to have the flavors not conflict with each other? Like, the full flavor only install the bits that are enabled by the options.

I think this addresses all of my points.

In D25038#553896, @kevans wrote:

Will we be able to wrap this up before the conclusion of the 11.4 release cycle, or is this suddenly going to get bumped into SA status?

It's also not clear to me if we're now-satisfied with the changes, including stack alignment.

In D25038#551788, @kevans wrote:

In D25038#551786, @andrew_tao173.riddles.org.uk wrote:

While at it, would it be worth adding a check that the stack size is at least MINSIGSTKSZ + PATH_MAX ?

When you say 'adding a check', are you proposing a static assert that PSPAWN_STACK_ALIGNMENT at least fits MINSIGSTKSZ + PATH_MAX , or runtime check just before calling rfork_thread()?

Adding an EINVAL return to rfork_thread will cause this code to fall through to the "use vfork instead" logic, hiding the error in unexpected ways.

Discussion point: this implementation converts the variable name to upper case for consistency with the way that port option_VARS works. But there are some cases where one might want to set a mixed-case name (such as CFLAGS.arch), so maybe it shouldn't do that and just use the case as written?

Incidentally, in case it's not obvious, if my addition is moved to before the inclusion of bsd.default-versions.mk then it remains entirely possible to do

In D24324#544139, @adamw wrote:

I really like the idea of being able to simply and cleanly set vars for specific ports from /etc/make.conf. I think the choice of variable naming is exactly right here, and the implementation is clean and simple.

However, I am 100% with @mat here that bsd.default-versions.mk is the wrong place for this. The idea is that the things defined in there choose one from a list of conflicting options. If every port is built with ssl=openssl and one port is overridden with ssl=libressl, then it will be impossible to install that port without uninstalling everything else. I can't think of a scenario where any default version should be overridden.

Can you implement this somewhere else, so that default versions are preserved?

Lua 5.4.0 is planned for release next week, it would be nice to have this resolved sometime reasonably soon.

In D24324#543789, @mat wrote:

What difference is there from having either a Makefile.local with whatever you need in the port's directory, or using what everyone has been using for decades:

.if ${.CURDIR:M*/lang/rust*}
DISABLE_MAKE_JOBS=yes
.endif

Discussion opened upstream at http://mm.icann.org/pipermail/tz/2020-May/028970.html

I don't think there's a great deal of merit in adding this change just to pander to broken apps (it's not like fstat is hard), but I do think it's actually an improvement from a UX perspective (who amongst us has not been annoyed at some point by cat'ing a directory by mistake).

I just noticed that the diff here had been replaced by the one from the first commit, so I'm re-uploading the diff of just the uncommitted part for ease of further review.

This needs to stay on hold pending the change to the version selection logic discussed on D14709.

Others have supported the "closest to default" rule, so I'll put up a separate patch for that.

In D14709#538596, @antoine wrote:

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

In D14709#538585, @antoine wrote:

In my opinion, it's a bug in Mk/Uses/lua.mk that USES=lua:53+ chooses lua 5.4 over 5.3

What alternative logic do you suggest?

Maybe chose the closest from default version that fits the constraints

In D14709#538585, @antoine wrote:

In my opinion, it's a bug in Mk/Uses/lua.mk that USES=lua:53+ chooses lua 5.4 over 5.3

Change the two ports that declared themselves lua:53+ to just lua:53, since they don't seem to respond sanely to attempts to force configuration with 5.4 using environment vars.

Add a note about avoiding use of XY+ version specifications

Should work with patch -p1

Test results: adding support for 5.4 causes only two ports (archivers/urbackup-server and x11-toolkits/termit) to switch from lua 5.3 to 5.4 when LUA_DEFAULT is 5.2. (They would not switch if the default were 5.3; both are declared as lua:53+, and the default version is chosen if it is in range, otherwise the latest available version in the range.)

Update to lua 5.4.0-rc1

This should have been fixed in bsd.sites.mk, which would unbreak a bunch of other ports too.

In D24306#535952, @ngie wrote:

new installs *should* be using the new timezone mappings, so the need for the old ones will die off over time.

In D24306#535757, @delphij wrote:

does not mean we should remove these links.

To explain the full context of the original link:

I think this change is a bad idea and should be reverted. (The "backward" file in the IANA db is for ancient compatibility, and FreeBSD has been excluding it by default since 1994 as far as I can tell; this is not the time to be adding it back.)

Fix rebase error that caused a deleted file (lua51-iconv/Makefile) to be revived due to a conflicting trunk commit.

Ugh, previous diff was reversed. Fix.

Rebase. Un-deprecate lua-iconv, because the only thing keeping it broken is the failure to update bsd.sites.mk in a timely manner.

Rebase. Fix most of mat's requests. Make the usage of LUA_VER / LUA_VER_STR a bit more consistent. Allow for the option of lua:build,run if needed.

From discussion just after I posted this, it sounds like math/plplot actually needs a PORTREVISION bump not included in this patch.

Rebase and include fixes.

This one includes the changes to the actual ports, plus fixes to a few issues in lua.mk.

Fix bug in non-LOGIN_CAP case. Update manpage.