In D53824#1243052, @danfe wrote:

@salvadore wrote:

IMHO, make -V WWW is the way to go.

It is a way to go to obtain the web address programmatically, at the command line, etc., there's no argument about that. We want plain URLs for visual clarity and to be able to click on it in a capable terminal or text editor. I don't want to escape to command prompt to execute xdg-open $(make -V WWW) or write some context-dependent macros when I could just click.

Typing xdg-open $(make -V WWW) took me 1.5 seconds. Reading PORTNAME and PORT VERSION even less. This doesn't seem like a significant argument. I can afford to loose that kind of time out of my life if
it can better facilitate the development and developers of FreeBSD ports. Can't you? :-)

Of course, the same concept might apply to flavors:

Hardly: flavors is a mechanism to build the same program (hence probably same WWW) but in different ways to produce different pile of bits (e.g. against several toolkit versions). Subpackages are more likely to parameterize WWW, but they aren't there yet.

I was involved in the discussion on the mailing list and while I am a proponent of allowing the variable in the WWW.
In the end we're only ever talking about the difference of some half a dozen characters. So not a big deal either way.
If this should ever be documented as a MUST. I'd like to suggest the use of the terms:
"string literal" and "string variable" as opposed to "literal text". As both a variable AND a literal are still after all,
"literally text". :-)

While I was initially an objector to this and am not a big fan of BASIFY. This seems like
a reasonable compromise that is easy enough to tool around. So as to keep current work
flows working w/o too much disruption. Thank you for taking the time to make this work
for everyone. :-)

In D52621#1205738, @ivy wrote:

as discussed on IRC, we'll probably go with a new "optional" set that excludes devel, then base will be optional+devel, which preserves the existing semantic meaning of "base".

IMHO this adds additional complication to a new and already fairly complicated change.
IOW We've already learned (have been trained) as to how the dist sets work. It's
intuitive and makes sense. base is base. It's all you need to run your system and
build additional bits as you require. The same for kernels, 32 bit compatibility
and so-on. It appears we'll reach nearly 30 packages if we continue to split
things up. I guess I'm lobbying to try and keep things as close as possible to what
we've come to expect from FreeBSD. Many of us have built tooling around our expectations
and these proposed changes add additional burdens.

archivers/unalz
devel/frink
misc/hotkeys
net-mgmt/tcptrack
net/spread
security/pks
sysutils/cramfs
textproc/mgdiff
x11-toolkits/tktable
x11-wm/compiz

I just reapplied my patch after a pull which returned your revert, and my MASTERSITES change works as expected. Why the reversal?
The distinfo will need to be updated as well (which my patch included).

I can report that on a freshly built/installed world/kernel at:
15.0-CURRENT FreeBSD 15.0-CURRENT #1 main-n270118-94b09d388b81-dirty: Mon May 13 12:57:41 PDT 2024
with this patch; the sound just works. Required no additional efforts on my part.

The point of choosing the 1.1 target is to keep BSD sed compatibility.
2.n (expressly) drops that ability. Unless I've missed your point regarding
gsed.

LGTM ;)

While I still don't quite know how we got from 8.0 to 8.2.
It all LGTM. Thanks for all your time and efforts here, Otis.

In D37706#857873, @otis wrote:

In D37706#857617, @portmaster_BSDforge.com wrote:

I started this yesterday, But was involved in a head-on collision Monday. So I'm not yet recovered. :(
I ran into the following error using the HTTP(s) mirrored source, building in a 12 jail:

checking for ASIdentifiers_free... no
configure: error: libcrypto with RFC3779 support required
===>  Script "configure" failed unexpectedly.
I think the SSL may be behind in that jail.

Has anyone tried these proposed changes?

It builds with 12.4-RELEASE jail.

I chose the following. As it seemed less prone to failures:

I started this yesterday, But was involved in a head-on collision Monday. So I'm not yet recovered. :(
I ran into the following error using the HTTP(s) mirrored source, building in a 12 jail:

My only objection is that I can NOT get textmode or very stable X on any of the NVIDIA
cards I use unless I build against sc. Does sc(4) use so much space that current kernels
become too big with it's presence? I vote against it's removal.

In D30807#695747, @grembo wrote:

In D30807#695734, @ceri wrote:

'approved', 'allowed', 'rejected': may be clearer.

Those aren't really terms that are usually used in the context of certificates though and using them might raise more questions. It really just seems to be "all certificates" and out of those "trusted ones" (like the "manage certificates" dialog in firefox - you can import and then modify the trust level).

I like your concept. or maybe,
removed, retired, rejected?
lastly, IMHO DIStrusted /would/ be the better than UNtrusted, if us/english is not your first spoken language / "native tongue".

Thanks for all the work you put into this, Stefan!
Having done it the way it's always been done all these years.
This all seemed initially unintuitive. But it's elegant in it's
simplicity, and simplicity is something I can easily get used to. ;-)
Everything looks right to me. So if I have anything to say about
this; consider this an approval. I'm looking forward to it's adoption.

In D30160#677202, @hselasky wrote:

@swills : Yes, but how to avoid problem with other OS'es implementation? Do you have any suggestion for which command line arguments are free?

In D26447#664044, @pstef wrote:

In D26447#664004, @rgrimes wrote:

Also so much for the project being a democracy, seems that core@ and security@ now simply dictate to developers@ how things are to be done...

Democracy as you describe it effectively means nothing ever changes because there is always someone whose feelings are hurt by a decision made.

Ahem. As you already noted; Democracy is a majority. *Which* majority is something else.
I'd only like to add that democracy is akin to popularity. User popularity keeps FreeBSD alive. Isn't that pole FreeBSD took, what drove the decision to adopt git as the source of future truth for FreeBSD? If ftp(d) is a popular component of base, as the vast majority of mailing list replies would seem to indicate. Maybe it's worth keeping?

In D26447#663880, @gordon wrote:

To be clear, this isn't a referendum on whether we should deprecate ftpd. We are going to deprecate it. There is no need for ftpd to live in the base system. It hasn't been a core system daemon in at least 10 years, probably closer to 15 years.

Referendum or not. The mailing lists reaction should be evidence enough that the FreeBSD user base (those for which FreeBSD exists) have a different opinion on this decision.

In D26447#588691, @cy wrote:

I think we should deprecate the client as well. F5 no longer supports the FTP protocol.

Another thought: Deprecate and remove telnet. It's already in contrib and could be very easily moved to ports. (I'll put that on my todo list.)

MacOS has also done this.
I don't understand why this should be necessary. In fact *because* MacOS depreciated client && server. I discovered it was trivial to simply copy my already built FreeBSD version over to MacOS and use it there. I found it much nicer than the GNU version. :-) Why remove them? I have used and depend on both for _years_. inetd(8) && hosts.allow(5) provide reasonable enough security. Or are they being removed as well?

This was created in error

OK I'm a reasonably intelligent individual. But the software used
for this appears to me to be fairly clueless. In my attempt to
update this differential with a newer diff. It created:
https://reviews.freebsd.org/D27593
Sorry. I simply followed the direction this software took me.

OK I have a proper diff that makes all the necessary corrections. I went to attach it
to this differential, and submit took me to a different differential. I'm unclear how
anyone gets along here.
I'll try to attach it again.

I'm updating the original proposed diff with the changes
necessary to accomplish the original goal.
UPDATES MOVED
UPDATES PORTVERSION
REMOVES PORTREVISION
REMOVES pkg-plist
ADDS autoplist
bumps version in port source (taylor.py)
UPDATES distinfo

Wait a minute. I should really fix the version in the source itself (vcpx_tailor.py).
Can you pull that patch from this differential, and I'll submit the correct diff to the pr.
Or is there a better way, like make all these proposed changes to the pr this differential references?
Sorry. I have limited experience with these differentials, and the preferred procedure.

LGTM
I'm embarrassed I forgot MOVED, as well as *version* in vcpx_tailor.py.

I'm with @koobs on an "informative" error returned on this. If it's possible.
I think it might lend itself to *Maintainers* providing a cure. :)
Thanks for all the time, and effort put into this!

In D15480#327568, @tcberner wrote:

@mat does not seem to mind it, so it's OK, I gueess =)

But could you give them more sensible names like tkdiff-256.png.enc or something instead of just 256.

This version simply changes the names of the icon files, as per @tcberner 's request.

Thanks Mat!
I made the changes you suggested/required, and attempted to add it to this review, by choosing Update Diff from the menu.
But I don't think that was the correct way to do it, as I don't see the change(s).
Sorry, I'm afraid phabricator is still a bit unfamiliar to me.
FWIW I also added the new diff to pr bug #228176

In D15480#327198, @tcberner wrote:

My issue is more with them being shipped in files/ and not downloaded from somewhere -- you could for example create a tkdiff-icons.tar.gz and host it in your public distfiles and add it as an additional distfile.

In D15480#326764, @tcberner wrote:

I'm not sure about the icon handling there... seems a bit icky.

The general solution is to make it easy in the installer to select from a few presets for all of these that will give the desired behaviour. At a previous DevSummit, there was talk of having a Linux-user-friendly port that would provide a bunch of these as a simple installable option. That seems a far better place to focus effort than a bikeshed discussion about whether we like less or more for one specific use.

FWIW I too am big on sticking to POLA. But (personally) in this case I'd be up for the change
(enhancement) providing there was an item added in UPDATING, with the directions to reverse
it, and make that reversal stick.

In D6820#143262, @woodsb02 wrote:

Thanks for the review mat. Waiting on maintainer feedback from Chris Hutchinson before committing.

In version 1.0.0 source was restricted to owner rwx which means
only root can install. I had to prepend the following here