Yeah, something's still wrong, looking into it.

tested, seems to work.

In D42023#959423, @kib wrote:

fsid for MNT_UPDATE call should be taken from the last statfs, I believe

Sent.

The additional check of the fstype in automount.c got lost in this patch; without it, you get a lot of unnecessary errors (since it will log_err for each covered mountpoint)

In D40961#953488, @kib wrote:

It feels too hackish, in particular the fact that the type is preserved.

In D41975#957684, @vsasjason_gmail.com wrote:

In D41975#957656, @andrew_tao173.riddles.org.uk wrote:.

Take a look at devel/git or mail/postfix which override OPTIONS_FILE to allow different options for flavors.

Could you please suggest Makefile line number for devel/git? I don't see that.

In D41975#957578, @vsasjason_gmail.com wrote:

So, initial thoughts on rework:

After carefully reading bsd.options.mk I came to following coclusions (but I may be wrong):

1. OPTIONS_FILE being crafted from <category>/<portname>, which means we can't really define any options inside flavors, but in root of Makefile only (to prevent overwriting OPTIONS_FILE by different flavors.

Unless there is any further comment, would someone commit this please? (w/MFC)

In D40961#943728, @rmacklem wrote:

If the kernel patch is applied, is the automount.c change needed?
(Or does the nmount(2) fail with EINVAL?)

In D40961#943507, @kib wrote:

Am I right that e.g. the following usage is broken by the patch 'as-is' : mount -u -w /?

In D40961#943360, @mjg wrote:

but this is only trying to paper over part of the problem and flush_autofs still does not work?

If the long-term solution is going to involve something new, then how about committing this as it stands in the meantime?

No, I don't think even that is possible; on 32-bit arch, there are literally zero flag bits available.

Possible approach: rename existing MNT_BYFSID to MNT_BYFSID_OLD and add a new MNT_BYFSID with a non-colliding value; have nmount support (only) the new value, but leave umount supporting both.

In D40961#942915, @mjg wrote:

The mount update path should grow support for FSID, which would close the problem.

Check kern_unmount to see what I mean.

In D41334#941330, @kib wrote:

ufs by default uses the vn_io_fault code path, which uses rangelocks, and does not (normally?) reach the pgcache path.

UFS does use pgcache reads.

Do we have documentation of the scalability impact? I think that should be made clear.

In D41334#941270, @mjg wrote:

ufs is the only other pgcache vop user, does it work without rangelocks?

Reword some long or confusing sentences largely following fernape's suggestions.

Fix example domains.

Requested whitespace fixes.

I will open a separate review shortly for documentation for this in the porters handbook.

Pick up CHANGES, MOVED, and finalized PORTREVISION changes from fuz' repo.

Tested this the same way as I tested the original report; no failures detected. The approach looks reasonable to me.

Rebase (on c8adede0fca)

Updated to include manpage fix.

Maybe the added requirement that fstype must match when MNT_UPDATE is used should go in the manpage? (I can add that)

Still waiting.

Rebase (on de1bf48ce).

Rebase on 738e4012 and fix:

The patch literally does nothing unless the variables it checks for are defined. Who is going to be surprised?

Rebase (on 4cec5e5f). Fix some minor issues.

I'm not at all sure I approve of the logic of this one. If the caller asked for LOGIN_SETPRIORITY, they may well be explicitly intending that the current process priority not be inherited by the eventual user's process.

It's perhaps worth noting that basically all of login_cap's memory handling is dubious - it leaks in several places, the manpages and the code disagree about whether values should be freed by the library or the caller, and it uses non-obvious and undocumented static state.

In D40281#918468, @kib wrote:

How the effects of that are different than the current code, where the ^C handler just set a flag and returns?

Should be conditional on LOGIN_SETPRIORITY, no?

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()?