Nice.

btls patch doesn't look updated, where's the ifndef ID_AA64ISAR0_AES_VAL stuff?

https://github.com/mono/boringssl/pull/23/files is the source for the final patch

I'm not very familiar with Phabricator

If you were, you'd know you could steal D23300 by clicking "Add action.." -> "Commandeer Revision" above the comment form :) and then updating its diff

By the way, this breaks the devel/msbuild port, because the old msbuild version is not compatible with the newer compiler version. Given that it relies on pulling a plethora of binary dependencies from nuget anyways, there is arguably little point in having it actually compile msbuild. On Arch Linux there is a package that simply pulls in http://download.mono-project.com/repo/ubuntu/pool/main/m/msbuild/msbuild_16.5+xamarinxplat.2020.02.20.11.54-0xamarin2+ubuntu2004b1_all.deb (ubuntu package provided by the mono project). This runs just fine on FreeBSD with only two changes:

1. Rename all files from /usr/ to /usr/local/
2. Patch the two paths in the /usr/local/bin/msbuild script to also be prefixed with /usr/local

I think the msbuild port should simply take this approach. I just don't know how to make it do this, so I would greatly appreciate some advice.

There are a bunch of portlint issues that can be fixed:

portlint -AC

Do the same for lang/mono please.

In D24988#551785, @mikael wrote:

Do the same for lang/mono please.

Would you mind elaborating? I'm not familiar with any of this.

installing gettext translation files, please define USES[+]=gettext as appropriate

Do I just blindly add USES=gettext?

use of DISTFILES with single file discouraged. distribution filename should be set by DISTNAME and EXTRACT_SUFX.
WARN: Makefile: DISTFILES/DISTNAME affects WRKSRC. take caution when changing them.

I guess I just ignore this?

WARN: Makefile: "BROKEN" has to appear earlier.
WARN: Makefile: "NOT_FOR_ARCHS" has to appear earlier.
WARN: Makefile: "BROKEN" has to appear earlier.
WARN: Makefile: "NOT_FOR_ARCHS" has to appear earlier.
WARN: Makefile: "LIB_DEPENDS" has to appear earlier.
WARN: Makefile: "BUILD_DEPENDS" has to appear earlier.
WARN: Makefile: "RUN_DEPENDS" has to appear earlier.
WARN: Makefile: "USES" has to appear earlier.

No idea what this means, just tell me where to move things.

WARN: /usr/ports/lang/mono/files/patch-btls-aarch64: patch was not generated using `make makepatch''. It is recommended to use `make makepatch'' when you need to [re-]generate a patch to ensure proper patch format.
WARN: /usr/ports/lang/mono/files/patch-inotify: patch was not generated using `make makepatch''. It is recommended to use `make makepatch'' when you need to [re-]generate a patch to ensure proper patch format.
WARN: /usr/ports/lang/mono/files/patch-mcs_class_corlib_System_Environment.cs: patch was not generated using `make makepatch''. It is recommended to use `make makepatch'' when you need to [re-]generate a patch to ensure proper patch format.

No idea what to do with these.

In D24988#551787, @noah.bergbauer_tum.de wrote:

installing gettext translation files, please define USES[+]=gettext as appropriate

Do I just blindly add USES=gettext?

This one can be ignored (it's handled by NLS_USES= gettext) see using gettext

use of DISTFILES with single file discouraged. distribution filename should be set by DISTNAME and EXTRACT_SUFX.
WARN: Makefile: DISTFILES/DISTNAME affects WRKSRC. take caution when changing them.

I guess I just ignore this?

Yes

WARN: Makefile: "BROKEN" has to appear earlier.
WARN: Makefile: "NOT_FOR_ARCHS" has to appear earlier.
WARN: Makefile: "BROKEN" has to appear earlier.
WARN: Makefile: "NOT_FOR_ARCHS" has to appear earlier.
WARN: Makefile: "LIB_DEPENDS" has to appear earlier.
WARN: Makefile: "BUILD_DEPENDS" has to appear earlier.
WARN: Makefile: "RUN_DEPENDS" has to appear earlier.
WARN: Makefile: "USES" has to appear earlier.

No idea what this means, just tell me where to move things.

Good question, it seems to be in the correct order porting-order. Just ignore it.

WARN: /usr/ports/lang/mono/files/patch-btls-aarch64: patch was not generated using `make makepatch''. It is recommended to use `make makepatch'' when you need to [re-]generate a patch to ensure proper patch format.
WARN: /usr/ports/lang/mono/files/patch-inotify: patch was not generated using `make makepatch''. It is recommended to use `make makepatch'' when you need to [re-]generate a patch to ensure proper patch format.
WARN: /usr/ports/lang/mono/files/patch-mcs_class_corlib_System_Environment.cs: patch was not generated using `make makepatch''. It is recommended to use `make makepatch'' when you need to [re-]generate a patch to ensure proper patch format.

No idea what to do with these.

I never understood why the patch header has to be in a certain form, either regenerate them with make makepatch or fix it manually, the header should look like this

--- configure.ac.orig   2020-03-15 16:11:23 UTC
+++ configure.ac

In D24988#550221, @pkubaj wrote:

Looking at the diff between pkg-plist and pkg-plist.powerpc, I noticed I missed this at the end of pkg-plist.powerpc:

@postexec %%PREFIX%%/bin/cert-sync %%LOCALBASE%%/share/certs/ca-root-nss.crt
@postunexec rm -rf %%LOCALBASE%%/share/.mono

Please add this.

This is incorrect and it must not be in pkg-plist.powerpc, because pkg-plist.powerpc is strictly an append. Everything in pkg-plist is for 100% of platforms; ppc64 generates additional binaries, not replacement binaries.
Do NOT duplicate the @postunexec under ANY circumstances no matter what. Because this breaks both upgrading the package and NuGet consumers. I am still working with a solution that will address NuGet consumers, because this is getting into host-dynamic plists and no you cannot wildcard.

Also, there is a reason msbuild is to not be used for any reason: it not only does but will break. msbuild has never been tested beyond "yes, everything went terribly." It has never been in CI and will never be in CI, either. All CI and unit testing is done with monolite. msbuild is just a thing that exists.

All that said, I hate to be the bearer of bad news but 1) 6.8.0.105 is (likely) out of date at this point 2) 6.8.0.105 with the BTLS patches is showing a severe regression in BTLS itself now, which is not proving fun to track down 3) 6.8.0.123 has other severe issues I'm working through around solving the sgen problems. I asked the VMM people for guidance and they didn't care to come down from their ivory towers, so now it's gonna be whatever I throw together and that's it. And this is a MUST FIX due to catastrophic sgen performance regression without it. (Oh, and blowing up the VMM system. No big, right? )

System.Net.WebException: Error: TrustFailure (Authentication failed, see inner exception.):  [redacted] System.Net.WebException: Error: TrustFailure (Authentication failed, see inner exception.) ---> System.Security.Authentication.AuthenticationException: Authentication failed, see inner exception. ---> Mono.Btls.MonoBtlsException: Ssl error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED
at /wrkdirs/usr/ports/lang/mono/work/mono-6.8.0.105/external/boringssl/ssl/handshake_client.c:1132
  at Mono.Btls.MonoBtlsContext.ProcessHandshake () [0x00048] in <88c7d2e4b4df4e27baa411ae9198218c>:0 
  at Mono.Net.Security.MobileAuthenticatedStream.ProcessHandshake (Mono.Net.Security.AsyncOperationStatus status, System.Boolean renegotiate) [0x000da] in <88c7d2e4b4df4e27baa411ae9198218c>:0 
  at (wrapper remoting-invoke-with-check) Mono.Net.Security.MobileAuthenticatedStream.ProcessHandshake(Mono.Net.Security.AsyncOperationStatus,bool)
  at Mono.Net.Security.AsyncHandshakeRequest.Run (Mono.Net.Security.AsyncOperationStatus status) [0x00006] in <88c7d2e4b4df4e27baa411ae9198218c>:0 
  at Mono.Net.Security.AsyncProtocolRequest.ProcessOperation (System.Threading.CancellationToken cancellationToken) [0x000fc] in <88c7d2e4b4df4e27baa411ae9198218c>:0 
   --- End of inner exception stack trace ---

The failure here occurs on amd64, not a tier 2 architecture, so something has gone very wrong but frankly I don't know anywhere near enough about btls to guess what.

In D24988#552276, @prj_rootwyrm.com wrote:

Also, there is a reason msbuild is to not be used for any reason: it not only does but will break. msbuild has never been tested beyond "yes, everything went terribly." It has never been in CI and will never be in CI, either. All CI and unit testing is done with monolite. msbuild is just a thing that exists.

Perhaps there is some miscommunication here, but msbuild works just fine for me. If you're talking about building mono with msbuild then please note that I haven't touched your patch at all except for changes I listed above.

All that said, I hate to be the bearer of bad news but 1) 6.8.0.105 is (likely) out of date at this point 2) 6.8.0.105 with the BTLS patches is showing a severe regression in BTLS itself now, which is not proving fun to track down 3) 6.8.0.123 has other severe issues I'm working through around solving the sgen problems. I asked the VMM people for guidance and they didn't care to come down from their ivory towers, so now it's gonna be whatever I throw together and that's it. And this is a MUST FIX due to catastrophic sgen performance regression without it. (Oh, and blowing up the VMM system. No big, right? )

Hm, the diff to 6.8.0.123 seems fairly small. Do you have any details?

The failure here occurs on amd64, not a tier 2 architecture, so something has gone very wrong but frankly I don't know anywhere near enough about btls to guess what.

Is this the .105 BTLS regression you were talking about? Because I used to get this error when the cert-sync postexec task failed (and hence no certificates were installed). This is why I removed the --quiet flag which sadly silences all output, both success and errors (which would be important to know).

The bottom line is that I haven't run into any of the catastrophic problems you're talking about - after a week of using it every day (on amd64). So if you have more information, perhaps I could try to reproduce and debug? And just in case this helps you, here is my mono package and this is msbuild.