Update on porting mono 5

[Russell Haley]

On Thu, Nov 23, 2017 at 1:01 PM, David Naylor <naylor.b.david at gmail.com> wrote:
> On Monday, 13 November 2017 23:11:03 David Naylor wrote:
>> In the interim, I tried my hand at my own exp-run [1][2][3].  And things
>> didn't go well (well the exp-run was a success, but the results...).
>>
>> It appears that somehow the assemblies are being delay signed during build,
>> instead of signed.  It appears csc(1) [the replacement for mcs(1)] does not
>> support signing on non-Windows machines [4].  Mono recommends sn(1) should
>> be used to sign the dll after build.  I suggest we patch
>> Microsoft.Common.CurrentVersion.target to restore signing functionality.
>
> I've fixed signing of assemblies by using sn(1) after the compile step in the
> CoreCompile target.  This fixed one port and pushed post packages to breaking
> due to changes from mdb to pdb debug info.
Wow. I haven't seen sn or SigningTool in a long time. Nice job. I
didn't even think of it.

>> Any help with the above or the following will be most appreciated:
>>  - Bumping the PORTREVISION of all ports that depend on mono
>>  - Patching security/ca_root_nss to update/sync/clear the mono certificate
>> (see cet-sync(1))
>>  - (Optional) Patch mono to store the certificates in $PREFIX, instead of
>> /usr/local/
>  - fix the follow port's pkg-plist:
>    - devel/dbus-sharp
>    - devel/mono-addins
>    - devel/newtonsoft-json
>    - multimedia/emby-server
>  - investigate why the following ports do not build:
>    - games/openra
>    - security/gnome-keyring-sharp

I'm perusing your review right now. I haven't absorbed enough to
comment yet. You seem to have added a new make variable for
nuget_depends. Can you speak a little about that? I am wondering if
leverage that in dotnet core to pull in the managed assemblies that we
can't build on FreeBSD?

Russ