For the record: after discussing with Li-Wen Hsu, it has been suggested to wait until after the 12.1 EOL, and I am actually fine with that.

In D26817#601100, @imp wrote:

In D26817#601097, @pfg wrote:

First of all: thanks!

I should mention this was actually for a hacked linux binary-based intel compiler.

There exists a native FreeBSD [[ https://software.intel.com/content/www/us/en/develop/tools/system-studio/freebsd.html | Intel System Studio ]]compiler that claims to be GCC compatible which may just work (I tihnk it may be based on clang, but I am not sure).

I keep hearing rumors of this item, but never have been able to get a copy through my friends at Intel. I'll have to send a few emails out to see if I can see if I can get access to one, though it's a fairly low propriety. I suspect, based on a lot of things, that this doesn't actually exist, but I'll poke and prod anyway.

First of all: thanks!

Re-state krb524

Update with cy's feedback.
This will be committed about a week after 12.2 is released.

Thanks, will update soon.

Merge latest current

In D25640#567710, @yuripv wrote:

In D25640#567601, @pfg wrote:

LGTM however, I would recommend an exp-run. Many times before have sed changes caused trouble in the ports tree to be later reverted.

Yep, I was looking at the svn log of usr.bin/sed/ and noticed quite a few backouts. I agree that exp-run should be done, but even if some ports break those would need to be fixed instead of rejecting this change as it's obvious bug (and yes, gsed agrees).

LGTM however, I would recommend an exp-run. Many times before have sed changes caused trouble in the ports tree to be later reverted.

I plan to re-commit this as soon as FreeBSD 12.2 is released, to avoid a limitation of the build system.

In D23259#543516, @fsu wrote:

In D23259#543509, @pfg wrote:

Sorry I meant to approve this:
https://reviews.freebsd.org/D24685

(fsu should have comandeered this one instead of opening a new one)

I did not managed with new diff uploading, diff did not want to attach to this revision.
Seems like, I can attach diffs only to revisions, which were opened by me.
Please correct me if I am wrong or lose something in the Phabricator UI.

Sorry I meant to approve this:
https://reviews.freebsd.org/D24685

In D13209#537057, @trasz wrote:

Ping? What's the status of this?

In D21638#531526, @asomers wrote:

Can we close this review now?

LGTM, but I have no time to test.
Note that this type of changes should be checked with an exxp-run

Update User Ports, attempting to bring balance with what can actually appear in a UNIX system.

I thought cem would want to do the commit.
I've been a bit sick, but I'll commit it this week if no one else does.

LGTM

The code is rather tricky, it would be convenient to checksum the object code on Little Endian to make sure nothing changes.

Approved BTW, the code obviously doesn't change anything for LE.

Hmm... if the tests pass I guess it is good, but does the comment need updating as well?
The else case in the old code was going backwards but this one doesn't.

It did compile but no joy sadly :(.
I left the complete log here:
https://people.freebsd.org/~pfg/docs/Xorg.0.log

Ugh.. I think this was discussed when __unreachable() was introduced (D2536 perhaps), and back then it was not considered a good idea.

IANA has indeed removed some services: I think people can de-register services they don't use/develop anymore. We should remove at least Kerberos IV and netatalk, both are not in the IANA. Also IANA lists first tcp, udp and lastly sctp so perhaps its better to jeep things consistent.

Sync with latest updates.

Update Take2:
It is important to consider the differences between System Ports and User
ports. This changes keeps the system ports closely in sync with IANA.

In D23621#518545, @cy wrote:

The fact that Kerberos IV is EOL doesn'[t mitigate the fact that the entries are still registered with IANA and that some KRB4 app may expect the entries to exist. Suggest we use https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml as a reference.

In D23621#518528, @mjg wrote:

If you want an example of what happens when a random parameter gets whacked out of proportion compared to Linux, here it is:

https://www.postgresql.org/message-id/CAEepm%3D3VF%3DPUp2f8gU8fgZB22yPE_KBS0%2Be1AHAtQ%3D09schTHg%40mail.gmail.com

Parameter set to 65536 because "why not" while it is 4096 on Linux resulted in a 256KB buffer in postgres when it should have been a fraction of that size. And so on. If there is no reason to deviate, don't.

Hello;

In D23621#518513, @mjg wrote:

Removing very stale entries or adding something may be fine, but the list as suggested is a non-starter. One has to expect there is plenty of custom userspace code parsing it which will choke on the new size.

Good, indeed r252956, which was the predecesor of this, was built on an UFS patch.
Well done, thanks!