I plan to commit this tomorrow (in time for the quarterly branch)

I plan to commit this tomorrow (in time for the quarterly branch).

I plan to commit this tomorrow (in time for the quarterly branch).

Update to latest version from github.com/mono/msbuild

Downgrade dotnet from 2.1 to 2.0. Dotnet 2.1 uses Linux's /proc/$PID/maps output for various purposes, however FreeBSD has a but whereby output is truncated at 128KiB. This breaks the parsing of the output.

Update to latest versions of dotnet, fix SDK for v1.1 (no SDK for v1.0).

exp-run successful, please commit :-D

! In D15780#334798, @feld wrote:
For the record, I found a bug related to HTTP headers with my apps that I was able to reproduce with Mono 5.10, so my apps that were "failing" with 5.12 might not have been a 5.12 issue but something else in the 5.x train that caused it. I'd rather we push this out the barn door before 2018Q3 and then we can look at 5.12 in ports again. It should be much easier to upgrade now.

In D15780#334798, @feld wrote:

For the record, I found a bug related to HTTP headers with my apps that I was able to reproduce with Mono 5.10, so my apps that were "failing" with 5.12 might not have been a 5.12 issue but something else in the 5.x train that caused it. I'd rather we push this out the barn door before 2018Q3 and then we can look at 5.12 in ports again. It should be much easier to upgrade now.

feld@ is working on a new version :-) at https://reviews.freebsd.org/D15780

Exp-run done and a few new failures (see [1]). I think you need to restore the following patches:

• patch-mcs_tools_xbuild_data_12.0_Microsoft.CSharp.targets
• patch-mcs_tools_xbuild_data_14.0_Microsoft.CSharp.targets

1. Exp-run started: http://dbn.westeurope.cloudapp.azure.com/mono.html
   • Known issues are games/openar and devel/nant
   • games/openar: periodic failures (likely build concurrency issue)
   • devel/nant: does not build on FreeBSD-12 on a FreeBSD-11 kernel
2. I had difficulty applying your patch regarding the eglib patch files (there is a duplicate entry for the patches).
3. I did find some OS specific code in System.Data [a], although the build system only included a Unix generic file [b]. So I think we are good to go without changing the build system.
4. This update fixes PR 211367

I have been working on an update and I think some of the changes in that patch [1] will be useful. Given that your tests are all passing I suggest we go with your version. I do however see the latest version is 5.10.1.57 (but mono versioning just confuses me).

In D15780#333902, @feld wrote:

Disable USES=display by default. Only used for tests, can hide behind X11 option for now.

Looks good to me. Please revert the white-space change then commit.

If you want to take overship of kdesvn-kde4, please feel welcome to do so.

In D14721#312782, @greg_unrelenting.technology wrote:

oooh this is awesome!

Finally I got WoW64 building nicely in poudriere.

The changes mentioned above will be updated once I have fixed the building issue with poudriere (something about detecting amd64 in the chroot).

• actually delete i386-wine-devel
• pat portlint

Update patch, quite a few tests are failing! SOme known causes:

• DISPLAY not set correctly?
• hostname not resolveable

I've double checked and the issue does not appear to be with this revision. We'll work on the issue in https://reviews.freebsd.org/D13870 and if there is an issue relating to these Linux ports we'll report back.

In D13870#297392, @russ.haley_gmail.com wrote:

russellh@g1 /u/l/lib> pwd
/usr/local/lib
russellh@g1 /u/l/lib> ll libunwind.so*
lrwxr-xr-x 1 root wheel 18B Jul 26 2017 libunwind.so -> libunwind.so.8.0.1
lrwxr-xr-x 1 root wheel 18B Jul 26 2017 libunwind.so.8 -> libunwind.so.8.0.1
-rwxr-xr-x 1 root wheel 43K Jul 26 2017 libunwind.so.8.0.1

Update patch based on committed dependencies.

All changes committed, thank you :-)

Fix patch for:

• vuxml entry (ow committed)
• use SUBDIR for EPEL (per commit)

In D13869#296333, @tijl wrote:

Can you explain why you need the new libraries?

Update diff due to recent commits.

We have a winner. Commit tonight unless there are objections/reviews raised.

In D13752#296384, @russ.haley_gmail.com wrote:

In D13752#293261, @dbn wrote:

We have failing ports. Another github distinfo issue, and other isses with ports.

Sorry, this portion of porting is new to me. Can you point me towards the failure information (exp-run output)?

The patch is yet to pass an exp-run. The last run had two issues:

1. monodevelop had a bad plist due to the change from '.dll.mdb' to '.pdb' debug files (except for one file :-/).
2. nant is crashing on -CURRENT

Trim patch
Add mono group

I think this patch is ready to ship. Any comments or approvals?

Fix missing pkg-plist. Exp-run now passes

If the exp-run is a success I would like to commit this patch - unless there are objections. All other items I would like to defer to https://reviews.freebsd.org/D14006.

bump rpm version for failing packages.

We have failing ports. Another github distinfo issue, and other isses with ports.

• distinfo has been fixed
• all dependent ports have been bumped
• I've moved the '/usr/share/.mono' directory to '$PREFIX/share/mono'

There are some failures in the exp-run. Alll relating to missing distinfo where the package is no longer hosted upstream. I'll submit an additional review to fix those issues.

In D13869#290962, @mmokhi wrote:

Hmm, I don't know if my suggestion is wise and/or practical (so sorry in advance 😅 )
Because I saw linux-version of a port I maintain (lttng-ust), it just came to my mind that "can we have such ports via FLAVORs of the native port?"
How do you think about this?

@mat thank you for your effort in reviewing this port, and improving both the FLAVORS implementation within eric6 and eric6 in general.