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.

In D21481#516072, @kevans wrote:

These should have all been committed -- because I didn't want to trigger a close with an incomplete diff, I did not put in the proper tag to close it. Please do close it out if you're satisfied via "Add Action" > "Close Revision" under the diff.

This got brought up _again_ on IRC, but this time someone (sphex) came up with an actually interesting idea: what if there were a login.conf variable, e.g. cron.setpath, which if set caused cron(8) to respect the PATH from the login class if not overridden in the crontab file? This doesn't seem to hard to implement.

Rebase and add docs.

env.1 manpage will need changes, want me to add those?

Any breakage is probably my fault - I need to pick this one up again and work on it some more.

Fix unneeded dependency on guile-cairo when CAIRO option is off.

Add flavors (full/lite).

Add build dependency on gettext-tools, to get some stuff (gnulib's lib-link.m4) that actually has nothing to do with gettext :-(

Ugh, build does break for some option combinations due to hidden dependency on gettext-tools (for aclocal/lib-link.m4). Will post new patch after next round of tests.

No, this change is wrong if LUA_PREFIX is something different from /usr/local, since in that case luaconf.h does indeed get modified.

In D14709#483062, @russ.haley_gmail.com wrote:

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.

You should ask about that on the mailing list. -O2 is specified twice, as well as -Os. Which option does the compiler take?

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.

You seem to have duplicated a patch? There should be no patch for lua.c other than the extra-patch-libedit-dl one.

• When the ASSERT option is selected, the extra-patch-assert file fails to apply cleanly. I tried to port it over but I there has been a change to lgc.c and I don't know enough about lgc to apply the patch (Help Andrew?).

Style fixes. Rebase.

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.

Further proposal (the patch doesn't do this yet): cron should not override PATH when reading a user crontab; whether it should use the user's path, or daemon's path, rather than the hardcoded default when processing the system crontab is a more open question.

I've been pondering whether limits(1) also needs an option to pick up the environment from the login class, or whether that's better addressed in rc.subr for the case of servicename_class="x" settings.

In D21402#467883, @pkubaj wrote:

In D21402#467690, @andrew_tao173.riddles.org.uk wrote:

Why isn't this just CFLAGS+=-fPIC ?

Because e.g. powerpc64 doesn't need it.

Why isn't this just CFLAGS+=-fPIC ?

I've been running this myself for a while and have done explicit tests as listed in the test plan, and as far as I'm concerned it's done unless anyone has feedback on comments or docs. Anyone up for committing it?

Add documentation. Update comments. Refine the wording a little.

In D21350#464589, @imp wrote:

OK. Other than the updating the comments, I'm convinced this is a good thing.

In D21350#464485, @imp wrote:

Nesting is there as a sanity check when you try to create an inner container at offset 0, you don't recurse with the outer container somehow... Does this run afoul of that?

ping?

Apologies for needing another review round. Changes:

Ugh. Hold off on committing, please; there's one more issue to fix.

Philip: are you taking it, or should I find someone else? (I'm not a committer and as far as I know tmunro is only a src committer)

This is my final version unless someone spots a problem with it.

Update PORTREVISION which I forgot before.

In D20646#450328, @tmunro wrote:

However, I wonder if the encoding situation is OK; the modern version is in UTF8, and for example, if you pick Asia -> Kazhakstan, you'll see some non-ASCII characters. I'm not sure I understand ncursesw's model of character encoding, but I can see that we are already showing UTF8 text directly from /usr/shared/misc/iso3166 ("Côte d'Ivoire", "Curaçao", ...), so maybe that's OK.

Use Dq Li in place of most Ql uses, and use Dq alone in place of some uses of Ql that were not in fact literals.

Qq? there are none of those, only Ql for inline literals (though on second reading some of those are wrong and should have been Dq - will fix).