Yeah, something's still wrong, looking into it.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Dec 24 2023
Oct 17 2023
tested, seems to work.
Oct 4 2023
In D42023#959423, @kib wrote:fsid for MNT_UPDATE call should be taken from the last statfs, I believe
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
In D40961#953488, @kib wrote:It feels too hackish, in particular the fact that the type is preserved.
Sep 27 2023
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):
- 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.
Aug 25 2023
Unless there is any further comment, would someone commit this please? (w/MFC)
Aug 14 2023
Aug 13 2023
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?)
Aug 12 2023
In D40961#943507, @kib wrote:Am I right that e.g. the following usage is broken by the patch 'as-is' : mount -u -w /?
Aug 11 2023
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?
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.
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.
Aug 6 2023
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?
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
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?
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
In D24325#635020, @arrowd wrote:The comment about aclocal/guile.m4 file is not relevant anymore?
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
In D14709#571480, @russ.haley_gmail.com wrote:Ah, I thought I had mucked something. Shall I restore them?
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.
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?
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
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.
Jun 5 2020
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.
May 29 2020
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()?