User Details
- User Since
- Mar 15 2018, 5:43 AM (370 w, 1 d)
Tue, Apr 8
Dec 24 2023
Yeah, something's still wrong, looking into it.
Oct 17 2023
tested, seems to work.
Oct 4 2023
Oct 3 2023
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)
Sep 28 2023
Sep 27 2023
Aug 25 2023
Unless there is any further comment, would someone commit this please? (w/MFC)
Aug 14 2023
Aug 13 2023
Aug 12 2023
Aug 11 2023
If the long-term solution is going to involve something new, then how about committing this as it stands in the meantime?
Aug 10 2023
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.
Aug 6 2023
Do we have documentation of the scalability impact? I think that should be made clear.
Aug 2 2023
Reword some long or confusing sentences largely following fernape's suggestions.
Aug 1 2023
Fix example domains.
Requested whitespace fixes.
Jul 31 2023
I will open a separate review shortly for documentation for this in the porters handbook.
Jul 28 2023
Pick up CHANGES, MOVED, and finalized PORTREVISION changes from fuz' repo.
Jul 24 2023
Tested this the same way as I tested the original report; no failures detected. The approach looks reasonable to me.
Jul 22 2023
Rebase (on c8adede0fca)
Jul 17 2023
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)
Jul 11 2023
Still waiting.
Jul 10 2023
Jul 2 2023
Rebase (on de1bf48ce).
Jun 17 2023
Rebase on 738e4012 and fix:
Jun 13 2023
The patch literally does nothing unless the variables it checks for are defined. Who is going to be surprised?
Jun 12 2023
Jun 11 2023
Rebase (on 4cec5e5f). Fix some minor issues.
Jun 9 2023
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.
Jun 8 2023
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.
Jun 2 2023
Jun 1 2023
May 31 2023
Should be conditional on LOGIN_SETPRIORITY, no?
May 26 2023
Add remaining guile ports; this should now be complete.
May 23 2023
Update with more ports, and improved logic in guile.mk.
May 22 2023
Superseded by https://reviews.freebsd.org/D40194
May 21 2023
so... two years after everyone seems to have accepted it, maybe someone would commit it?
May 9 2023
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.
Oct 10 2021
The obvious example is doing this in make.conf:
Jun 24 2021
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.
Feb 12 2021
Looks basically sane to me.
Jan 28 2021
Jan 27 2021
Update to 3.0.5, removing patches that were fixed upstream
Jan 17 2021
Don't fold case of variable names. Allow using var@ to unset variables, since some places distinguish between empty and undefined values.
Jan 4 2021
Abandoning; Mina has taken this over in D27962
Dec 30 2020
Dec 13 2020
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.
Nov 15 2020
Nov 9 2020
Oct 19 2020
Update to 3.0.4 plus cherry-picked JIT fixes for arm.
Oct 15 2020
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.
Aug 10 2020
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.
Jul 31 2020
Jul 27 2020
Rewrite to match changes to logic, and extend some parts slightly.
Jul 26 2020
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.
Jul 25 2020
Jul 24 2020
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.
Jul 23 2020
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?
Jul 21 2020
Jul 6 2020
Updates to address comments.
Jun 30 2020
Lua 5.4.0 is now released, so this is now a blocking issue for the lua54 port.
Jun 23 2020
Move to an earlier place in processing (in fact the earliest possible place, just after PKGORIGIN is set).
Jun 16 2020
Jun 5 2020
I think this addresses all of my points.