Re: Update on porting mono 5

[Russell Haley]

Hi David, your patch applied cleanly but failed to find a file.

Complete output here:https://pastebin.com/0Q92wURs . The interesting
part follows.


russellh@prescott:~/FreeBSD/ports% cd lang/mono
russellh@prescott:~/FreeBSD/ports/lang/mono% make
===>  License MIT accepted by the user
===>   mono-5.2.0.215 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by mono-5.2.0.215 for building
===>  Extracting for mono-5.2.0.215
=> SHA256 Checksum OK for nuget.31.zip.
=> SHA256 Checksum OK for monolite-105021-latest.tar.gz.
=> SHA256 Checksum OK for mono-mono-mono-5.2.0.215_GH0.tar.gz.
=> SHA256 Checksum OK for mono-Lucene.Net.Light-85978b7_GH0.tar.gz.
=> SHA256 Checksum OK for mono-NUnitLite-690603b_GH0.tar.gz.
=> SHA256 Checksum OK for mono-Newtonsoft.Json-471c3e0_GH0.tar.gz.
=> SHA256 Checksum OK for mono-NuGet.BuildTasks-8d30747_GH0.tar.gz.
=> SHA256 Checksum OK for mono-aspnetwebstack-e77b12e_GH0.tar.gz.
=> SHA256 Checksum OK for mono-buildtools-b5cc6e6_GH0.tar.gz.
=> SHA256 Checksum OK for mono-cecil-1003fcb_GH0.tar.gz.
=> SHA256 Checksum OK for mono-cecil-33d50b8_GH0.tar.gz.
=> SHA256 Checksum OK for mono-corefx-78360b2_GH0.tar.gz.
=> SHA256 Checksum OK for mono-corert-ed6296d_GH0.tar.gz.
=> SHA256 Checksum OK for mono-ikdasm-88b67c4_GH0.tar.gz.
=> SHA256 Checksum OK for mono-ikvm-fork-7c1e61b_GH0.tar.gz.
=> SHA256 Checksum OK for mono-linker-c7450ca_GH0.tar.gz.
=> SHA256 Checksum OK for
mono-reference-assemblies-142cbeb_GH0.tar.gz.
=> SHA256 Checksum OK for mono-roslyn-binaries-dcb0a05_GH0.tar.gz.
=> SHA256 Checksum OK for mono-rx-b29a4b0_GH0.tar.gz.
=> SHA256 Checksum OK for xamarin-benchmarker-97f618c_GH0.tar.gz.
=> SHA256 Checksum mismatch for dotnet-coreclr-c7da48a_GH0.tar.gz.
=> SHA256 Checksum mismatch for dotnet-roslyn-322bd5b_GH0.tar.gz.
===>  Refetch for 1 more times files:
dotnet-coreclr-c7da48a_GH0.tar.gz  dotnet-roslyn-322bd5b_GH0.tar.gz
===>  License MIT accepted by the user
===>   mono-5.2.0.215 depends on file: /usr/local/sbin/pkg - found
=> dotnet-coreclr-c7da48a_GH0.tar.gz doesn't seem to exist in
/usr/home/russellh/FreeBSD/ports/distfiles/.
=> Attempting to fetch
https://codeload.github.com/dotnet/coreclr/tar.gz/c7da48a?dummy=/dotnet-coreclr-c7da48a_GH0.tar.gz
fetch: 
https://codeload.github.com/dotnet/coreclr/tar.gz/c7da48a?dummy=/dotnet-coreclr-c7da48a_GH0.tar.gz:
size unknown
fetch: 
https://codeload.github.com/dotnet/coreclr/tar.gz/c7da48a?dummy=/dotnet-coreclr-c7da48a_GH0.tar.gz:
size of remote file is not known
dotnet-coreclr-c7da48a_GH0.tar.gz   30 MB 2657
kBps 00m12s
=> Fetched file size mismatch (expected 31762122, actual 31762105)
=> Trying next site
=> Attempting to fetch
http://distcache.FreeBSD.org/ports-distfiles/dotnet-coreclr-c7da48a_GH0.tar.gz
fetch: 
http://distcache.FreeBSD.org/ports-distfiles/dotnet-coreclr-c7da48a_GH0.tar.gz:
Not Found
=> Couldn't fetch it - please try to retrieve this
=> port manually into /usr/home/russellh/FreeBSD/ports/distfiles/ and
try again.
*** Error code 1

Stop.
make[2]: stopped in /usr/home/russellh/FreeBSD/ports/lang/mono
*** Error code 1

Stop.
make[1]: stopped in /usr/home/russellh/FreeBSD/ports/lang/mono
*** Error code 1

Stop.
make: stopped in /usr/home/russellh/FreeBSD/ports/lang/mono
russellh@prescott:~/FreeBSD/ports/lang/mono%



Night,
Russ

On Thu, Nov 23, 2017 at 10:58 PM, Russell Haley  wrote:
> On Thu, Nov 23, 2017 at 9:33 PM, Russell Haley  wrote:
>> On Thu, Nov 23, 2017 at 1:01 PM, David Naylor  
>> 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/op

Re: Update on porting mono 5

[Russell Haley]

On Thu, Nov 23, 2017 at 9:33 PM, Russell Haley  wrote:
> On Thu, Nov 23, 2017 at 1:01 PM, David Naylor  
> 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

I submitted some comments on the patch. You've put in quite a bit of work!

It seem that you are pulling binaries for Nuget, Rosyln and a big
chunk of the dotnet framework. I can't help but think we could
directly use this port as a framework to build the managed assemblies
for core2 if we have all that working in order to build mono.

I also see nuget3000 and paket are used. Can you describe where these
are needed and what they are used for? I could have asked this on the
review but thought this is a better for others on the list that don't
want to wade through a review. :)

Night,
Russ
___
freebsd-mono@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-mono
To unsubscribe, send any mail to "freebsd-mono-unsubscr...@freebsd.org"

Re: Update on porting mono 5

[Russell Haley]

On Thu, Nov 23, 2017 at 1:01 PM, David Naylor  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
___
freebsd-mono@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-mono
To unsubscribe, send any mail to "freebsd-mono-unsubscr...@freebsd.org"

Re: Update on porting mono 5

[David Naylor]

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.  

> 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


signature.asc
Description: This is a digitally signed message part.

Re: Update on porting mono 5

[David Naylor]

On Thursday, 21 September 2017 22:20:54 David Naylor wrote:
> Hi
> 
> A quick update on the update to mono5.  In theory everything should be
> working (i.e. mono, monodevelop, etc).
> 
> A review has also been created (so you can access the patch).  Please test
> it.
> 
> https://reviews.freebsd.org/D12440

Another update, the review has been updated:
 - summary of work done (thanks Russel)
 - commit message
and an exp-run has been requested.  Github has also been updated.  

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.

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/

Regards

[1] http://dbn.westeurope.cloudapp.azure.com/10_3-i386-default/latest
[2] http://dbn.westeurope.cloudapp.azure.com/11_0-i386-default/latest
[3] http://dbn.westeurope.cloudapp.azure.com/12-i386-default/latest
[4] https://github.com/dotnet/roslyn/issues/8210

signature.asc
Description: This is a digitally signed message part.

Re: Update on porting mono 5

[David Naylor]

On Monday, 25 September 2017 23:35:04 Russell Haley wrote:
> Sorry, hit send in gmail somehow. :-/
> 
> Hi David,
> 
> So, point 1: I suck at patching. I'm going to re-attempt when I'm not
> so tired with a fresh ports from svn.
> 
> tldr; I think I failed to apply the patch, but the build started after
> I modified the distinfo file.
> 
> Details:
> I tried the new patch from phabricator, but mucked it up (man wget
> russell!). So I used the patch above. I had items rejected but
> realised the port version on this computer might have been old. I
> reverted, updated and tried again. The patch patch seemed to succeed
> (Output is here http://termbin.com/373z). However, I forgot to clean
> up the *.rej and *.orig files so I'm a little unsure of the state.
> None the less, the build for mono 5 started and ended on the following
> error:
> 
> russellh@prescott:~/FreeBSD/ports/lang/mono% make
> ===>  License MIT accepted by the user
> ===>   mono-5.2.0.215 depends on file: /usr/local/sbin/pkg - found
> => dotnet-coreclr-c7da48a_GH0.tar.gz doesn't seem to exist in
> /usr/home/russellh/FreeBSD/ports/distfiles/.
> => Attempting to fetch
> https://codeload.github.com/dotnet/coreclr/tar.gz/c7da48a?dummy=/dotnet-core
> clr-c7da48a_GH0.tar.gz fetch:
> https://codeload.github.com/dotnet/coreclr/tar.gz/c7da48a?dummy=/dotnet-cor
> eclr-c7da48a_GH0.tar.gz: size mismatch: expected 31762122, actual 31762105
> => Attempting to fetch
> http://distcache.FreeBSD.org/ports-distfiles/dotnet-coreclr-c7da48a_GH0.tar.
> gz fetch:
> http://distcache.FreeBSD.org/ports-distfiles/dotnet-coreclr-c7da48a_GH0.tar
> .gz: Not Found
> => Couldn't fetch it - please try to retrieve this
> => port manually into /usr/home/russellh/FreeBSD/ports/distfiles/ and
> try again.
> *** Error code 1
> 
> Stop.
> make[1]: stopped in /usr/home/russellh/FreeBSD/ports/lang/mono
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/home/russellh/FreeBSD/ports/lang/mono
> 
> I modified the distinfo file and changed the size. I also had to
> change the size of the rosyln download. The last two files of the
> distinfo were modified:
> 
> SHA256 (dotnet-coreclr-c7da48a_GH0.tar.gz) =
> 8529ce9e9dcc524046205487ca8a8e584d8180c3fecb59bc27944326525d8c83
> SIZE (dotnet-coreclr-c7da48a_GH0.tar.gz) = 31762105
> SHA256 (dotnet-roslyn-322bd5b_GH0.tar.gz) =
> 9740a0922f2fafa0251f462e7f27cfd6891dc078c22b008c49e11db6637edeea
> SIZE (dotnet-roslyn-322bd5b_GH0.tar.gz) = 22058637
> 
> I ran the port without checksum, but then the patches failed (see point 1).
> 
> russellh@prescott:~/FreeBSD/ports/lang/mono% make NO_CHECKSUM=yes
> ===>  License MIT accepted by the user
> ===>   mono-5.2.0.215 depends on file: /usr/local/sbin/pkg - found
> ===> Fetching all distfiles required by mono-5.2.0.215 for building
> ===>  Extracting for mono-5.2.0.215
> /bin/mkdir -p
> /usr/home/russellh/FreeBSD/ports/lang/mono/work/mono-mono-5.2.0.215/mcs/cla
> ss/lib/monolite /bin/mv
> /usr/home/russellh/FreeBSD/ports/lang/mono/work/monolite-105021-latest
> /usr/home/russellh/FreeBSD/ports/lang/mono/work/mono-mono-5.2.0.215/mcs/cla
> ss/lib/monolite/105021 ===>  Patching for mono-5.2.0.215
> ===>  Applying FreeBSD patches for mono-5.2.0.215
> ===>   Ignoring patchfile patch-configure.ac.orig
> ===>   Ignoring patchfile patch-eglib_src_gfile-posix.c.orig
>   I can't seem to find a patch in there anywhere.
> => FreeBSD patch patch-mono_metadata_socket-io.c failed to apply
> cleanly.
> => Patch(es)  patch-configure.ac patch-eglib_src_gfile-posix.c applied
> cleanly.
> *** Error code 1

Oops, I gave you the incorrect incantation for patch.  Something like:
# patch -Ep1 < /path/to/patch

The patch in question should be removed (and should be empty).  See [1] for 
what the patches should look like (minus the .orig files ;-)).  

Regarding distinfo - I've been having issues with a lot (but not all?) of 
them.  It appears the github has changes how they get generated.  I'll need 
verify no changes in the sources though.

[1] https://github.com/DragonSA/ports/tree/mono-5.2.0.215/lang/mono/files

signature.asc
Description: This is a digitally signed message part.

Re: Update on porting mono 5

[Russell Haley]

Sorry, hit send in gmail somehow. :-/

Hi David,

So, point 1: I suck at patching. I'm going to re-attempt when I'm not
so tired with a fresh ports from svn.

tldr; I think I failed to apply the patch, but the build started after
I modified the distinfo file.

Details:
I tried the new patch from phabricator, but mucked it up (man wget
russell!). So I used the patch above. I had items rejected but
realised the port version on this computer might have been old. I
reverted, updated and tried again. The patch patch seemed to succeed
(Output is here http://termbin.com/373z). However, I forgot to clean
up the *.rej and *.orig files so I'm a little unsure of the state.
None the less, the build for mono 5 started and ended on the following
error:

russellh@prescott:~/FreeBSD/ports/lang/mono% make
===>  License MIT accepted by the user
===>   mono-5.2.0.215 depends on file: /usr/local/sbin/pkg - found
=> dotnet-coreclr-c7da48a_GH0.tar.gz doesn't seem to exist in
/usr/home/russellh/FreeBSD/ports/distfiles/.
=> Attempting to fetch
https://codeload.github.com/dotnet/coreclr/tar.gz/c7da48a?dummy=/dotnet-coreclr-c7da48a_GH0.tar.gz
fetch: 
https://codeload.github.com/dotnet/coreclr/tar.gz/c7da48a?dummy=/dotnet-coreclr-c7da48a_GH0.tar.gz:
size mismatch: expected 31762122, actual 31762105
=> Attempting to fetch
http://distcache.FreeBSD.org/ports-distfiles/dotnet-coreclr-c7da48a_GH0.tar.gz
fetch: 
http://distcache.FreeBSD.org/ports-distfiles/dotnet-coreclr-c7da48a_GH0.tar.gz:
Not Found
=> Couldn't fetch it - please try to retrieve this
=> port manually into /usr/home/russellh/FreeBSD/ports/distfiles/ and
try again.
*** Error code 1

Stop.
make[1]: stopped in /usr/home/russellh/FreeBSD/ports/lang/mono
*** Error code 1

Stop.
make: stopped in /usr/home/russellh/FreeBSD/ports/lang/mono

I modified the distinfo file and changed the size. I also had to
change the size of the rosyln download. The last two files of the
distinfo were modified:

SHA256 (dotnet-coreclr-c7da48a_GH0.tar.gz) =
8529ce9e9dcc524046205487ca8a8e584d8180c3fecb59bc27944326525d8c83
SIZE (dotnet-coreclr-c7da48a_GH0.tar.gz) = 31762105
SHA256 (dotnet-roslyn-322bd5b_GH0.tar.gz) =
9740a0922f2fafa0251f462e7f27cfd6891dc078c22b008c49e11db6637edeea
SIZE (dotnet-roslyn-322bd5b_GH0.tar.gz) = 22058637

I ran the port without checksum, but then the patches failed (see point 1).

russellh@prescott:~/FreeBSD/ports/lang/mono% make NO_CHECKSUM=yes
===>  License MIT accepted by the user
===>   mono-5.2.0.215 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by mono-5.2.0.215 for building
===>  Extracting for mono-5.2.0.215
/bin/mkdir -p 
/usr/home/russellh/FreeBSD/ports/lang/mono/work/mono-mono-5.2.0.215/mcs/class/lib/monolite
/bin/mv 
/usr/home/russellh/FreeBSD/ports/lang/mono/work/monolite-105021-latest
/usr/home/russellh/FreeBSD/ports/lang/mono/work/mono-mono-5.2.0.215/mcs/class/lib/monolite/105021
===>  Patching for mono-5.2.0.215
===>  Applying FreeBSD patches for mono-5.2.0.215
===>   Ignoring patchfile patch-configure.ac.orig
===>   Ignoring patchfile patch-eglib_src_gfile-posix.c.orig
  I can't seem to find a patch in there anywhere.
=> FreeBSD patch patch-mono_metadata_socket-io.c failed to apply
cleanly.
=> Patch(es)  patch-configure.ac patch-eglib_src_gfile-posix.c applied
cleanly.
*** Error code 1

Stop.
make[1]: stopped in /usr/home/russellh/FreeBSD/ports/lang/mono
*** Error code 1

Stop.
make: stopped in /usr/home/russellh/FreeBSD/ports/lang/mono

Okay, that's it for tonight,

Cheers,

Russ

On Mon, Sep 25, 2017 at 4:54 AM, David Naylor  wrote:
> On Sunday, 24 September 2017 20:39:32 Russell Haley wrote:
>> Phabricator database is down. David, if you see this and can send your
>> patch I'll give it a shot tonight.
>
> Please see attached, to apply:
> # cd /usr/ports
> # patch -p1 < /path/to/patch
___
freebsd-mono@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-mono
To unsubscribe, send any mail to "freebsd-mono-unsubscr...@freebsd.org"

Re: Update on porting mono 5

[Russell Haley]

Hi David,

I tried the new patch from phabricator, but mucked it up (man wget
russell!). So I used the patch above. I had items rejected but
realized the port version on this computer might have been old. I
reverted, updated and tried again. The patch patch seemed to succeed
(Output is here http://termbin.com/373z). However, I forgot to clean
up the *.rej and *.orig files so I'm a little unsure of the state.
None the less, the build for mono 5 started and ended on the following
error:

russellh@prescott:~/FreeBSD/ports/lang/mono% make
===>  License MIT accepted by the user
===>   mono-5.2.0.215 depends on file: /usr/local/sbin/pkg - found
=> dotnet-coreclr-c7da48a_GH0.tar.gz doesn't seem to exist in
/usr/home/russellh/FreeBSD/ports/distfiles/.
=> Attempting to fetch
https://codeload.github.com/dotnet/coreclr/tar.gz/c7da48a?dummy=/dotnet-coreclr-c7da48a_GH0.tar.gz
fetch: 
https://codeload.github.com/dotnet/coreclr/tar.gz/c7da48a?dummy=/dotnet-coreclr-c7da48a_GH0.tar.gz:
size mismatch: expected 31762122, actual 31762105
=> Attempting to fetch
http://distcache.FreeBSD.org/ports-distfiles/dotnet-coreclr-c7da48a_GH0.tar.gz
fetch: 
http://distcache.FreeBSD.org/ports-distfiles/dotnet-coreclr-c7da48a_GH0.tar.gz:
Not Found
=> Couldn't fetch it - please try to retrieve this
=> port manually into /usr/home/russellh/FreeBSD/ports/distfiles/ and
try again.
*** Error code 1

Stop.
make[1]: stopped in /usr/home/russellh/FreeBSD/ports/lang/mono
*** Error code 1

Stop.
make: stopped in /usr/home/russellh/FreeBSD/ports/lang/mono

I modified the distinfo file and changed the size. I also had to
change the size of the rosyln download. The last two files of the
distinfo were modified:


On Mon, Sep 25, 2017 at 4:54 AM, David Naylor  wrote:
> On Sunday, 24 September 2017 20:39:32 Russell Haley wrote:
>> Phabricator database is down. David, if you see this and can send your
>> patch I'll give it a shot tonight.
>
> Please see attached, to apply:
> # cd /usr/ports
> # patch -p1 < /path/to/patch
___
freebsd-mono@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-mono
To unsubscribe, send any mail to "freebsd-mono-unsubscr...@freebsd.org"

Re: Update on porting mono 5

[Russell Haley]

Phabricator database is down. David, if you see this and can send your
patch I'll give it a shot tonight.

Russ

On Sun, Sep 24, 2017 at 12:21 AM, Russell Haley  wrote:
> This is the process, no apologies necessary! Will try again shortly.
>
> Russ
>
> Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
>   Original Message
> From: David Naylor
> Sent: Saturday, September 23, 2017 11:50 PM
> To: Russell Haley
> Cc: Freebsd-mono
> Subject: Re: Update on porting mono 5
>
> On Friday, 22 September 2017 20:29:03 Russell Haley wrote:
>> On Fri, Sep 22, 2017 at 7:01 PM, Russell Haley  wrote:
>> > On Thu, Sep 21, 2017 at 1:20 PM, David Naylor 
> wrote:
>> >> Hi
>> >>
>> >> A quick update on the update to mono5. In theory everything should be
>> >> working (i.e. mono, monodevelop, etc).
>> >>
>> >> A review has also been created (so you can access the patch). Please
>> >> test
>> >> it.
>> >>
>> >> https://reviews.freebsd.org/D12440
>> >
>> > Hi David,
>> >
>> > I created a VM with fdb current and created a ports dir from svn under
>> > my user. I attempted to apply your patch file and part of it was
>> > rejected. It's most likely my error as I'm poor at patching.
>> >
>> > I haven't even looked it over yet, but I've got to run out for a bit.
>> > I'll check back later. Here is the output:
>> >
>> > Script started on Fri Sep 22 11:44:20 2017
>> >
>> > russellh@fbd-12:~/ports % patch -p0 <../patches/D12440
>> So I've failed to apply the patch. I've tried three times now so I'm
>> clearly doing something wrong or the patch is broken - which is
>> doubtful. These things are usually my fault. I'm just chasing my tail
>> trying to spot fix it and it means I haven't validated anything. I
>> have a ~/patches with the file and a ~/ports with er... the ports.I
>> tried:
>>
>> russellh@fbd-12:~/ports % patch -p0 <../patches/D12440
>> and
>> russellh@fbd-12:~/ports % patch <../patches/D12440
>>
>> There have been various issues. The makefile for mono has a rejected
>> chunk (see above), the files in the files/ directory weren't removed
>> (i.e. patch-mono_metadata_socket-io.c) and the /files patches don't
>> apply cleanly when I try to run the port.
>>
>> Any help would be grand. I've attached a svn diff of the ports dir in
>> case it's helpful?
>
> Hi
>
> Apologies, mistakes abound for me :-(. The patch is broken against HEAD.
> I've since rebased against r450479 and updated the patch per Phabricator.
>
> Regards
___
freebsd-mono@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-mono
To unsubscribe, send any mail to "freebsd-mono-unsubscr...@freebsd.org"

Re: Update on porting mono 5

[Russell Haley]

This is the process, no apologies necessary! Will try again shortly. 

Russ

Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
  Original Message  
From: David Naylor
Sent: Saturday, September 23, 2017 11:50 PM
To: Russell Haley
Cc: Freebsd-mono
Subject: Re: Update on porting mono 5

On Friday, 22 September 2017 20:29:03 Russell Haley wrote:
> On Fri, Sep 22, 2017 at 7:01 PM, Russell Haley  wrote:
> > On Thu, Sep 21, 2017 at 1:20 PM, David Naylor  
wrote:
> >> Hi
> >> 
> >> A quick update on the update to mono5. In theory everything should be
> >> working (i.e. mono, monodevelop, etc).
> >> 
> >> A review has also been created (so you can access the patch). Please
> >> test
> >> it.
> >> 
> >> https://reviews.freebsd.org/D12440
> > 
> > Hi David,
> > 
> > I created a VM with fdb current and created a ports dir from svn under
> > my user. I attempted to apply your patch file and part of it was
> > rejected. It's most likely my error as I'm poor at patching.
> > 
> > I haven't even looked it over yet, but I've got to run out for a bit.
> > I'll check back later. Here is the output:
> > 
> > Script started on Fri Sep 22 11:44:20 2017
> > 
> > russellh@fbd-12:~/ports % patch -p0 <../patches/D12440
> So I've failed to apply the patch. I've tried three times now so I'm
> clearly doing something wrong or the patch is broken - which is
> doubtful. These things are usually my fault. I'm just chasing my tail
> trying to spot fix it and it means I haven't validated anything. I
> have a ~/patches with the file and a ~/ports with er... the ports.I
> tried:
> 
> russellh@fbd-12:~/ports % patch -p0 <../patches/D12440
> and
> russellh@fbd-12:~/ports % patch <../patches/D12440
> 
> There have been various issues. The makefile for mono has a rejected
> chunk (see above), the files in the files/ directory weren't removed
> (i.e. patch-mono_metadata_socket-io.c) and the /files patches don't
> apply cleanly when I try to run the port.
> 
> Any help would be grand. I've attached a svn diff of the ports dir in
> case it's helpful?

Hi

Apologies, mistakes abound for me :-(. The patch is broken against HEAD. 
I've since rebased against r450479 and updated the patch per Phabricator. 

Regards
___
freebsd-mono@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-mono
To unsubscribe, send any mail to "freebsd-mono-unsubscr...@freebsd.org"

Re: Update on porting mono 5

[David Naylor]

On Friday, 22 September 2017 20:29:03 Russell Haley wrote:
> On Fri, Sep 22, 2017 at 7:01 PM, Russell Haley  wrote:
> > On Thu, Sep 21, 2017 at 1:20 PM, David Naylor  
wrote:
> >> Hi
> >> 
> >> A quick update on the update to mono5.  In theory everything should be
> >> working (i.e. mono, monodevelop, etc).
> >> 
> >> A review has also been created (so you can access the patch).  Please
> >> test
> >> it.
> >> 
> >> https://reviews.freebsd.org/D12440
> > 
> > Hi David,
> > 
> > I created a VM with fdb current and created a ports dir from svn under
> > my user. I attempted to apply your patch file and part of it was
> > rejected. It's most likely my error as I'm poor at patching.
> > 
> > I haven't even looked it over yet, but I've got to run out for a bit.
> > I'll check back later. Here is the output:
> > 
> > Script started on Fri Sep 22 11:44:20 2017
> > 
> > russellh@fbd-12:~/ports % patch -p0 <../patches/D12440
> So I've failed to apply the patch. I've tried three times now so I'm
> clearly doing something wrong or the patch is broken - which is
> doubtful. These things are usually my fault. I'm just chasing my tail
> trying to spot fix it and it means I haven't validated anything. I
> have a ~/patches with the file and a ~/ports with er... the ports.I
> tried:
> 
> russellh@fbd-12:~/ports % patch -p0 <../patches/D12440
> and
> russellh@fbd-12:~/ports % patch <../patches/D12440
> 
> There have been various issues. The makefile for mono has a rejected
> chunk (see above), the files in the files/ directory weren't removed
> (i.e. patch-mono_metadata_socket-io.c) and the /files patches don't
> apply cleanly when I try to run the port.
> 
> Any help would be grand. I've attached a svn diff of the ports dir in
> case it's helpful?

Hi

Apologies, mistakes abound for me :-(.  The patch is broken against HEAD.  
I've since rebased against r450479 and updated the patch per Phabricator.  

Regards

signature.asc
Description: This is a digitally signed message part.

Re: Update on porting mono 5

[Russell Haley]

distinfo files pkg-message pkg-plist.orig
Makefile.orig Makefile.rej.orig distinfo.orig pkg-descr pkg-plist
russellh@fbd-12:~/ports % cat Makefile  .rej

cat: Makefile.rej: No such file or directory
russellh@fbd-12:~/ports % cat lang/mono/Makefile.rej

@@ -2,9 +2,8 @@
 # $FreeBSD: head/lang/mono/Makefile 446741 2017-07-27 13:57:30Z mat $

 PORTNAME= mono
-PORTVERSION= 4.8.1.0
+PORTVERSION= 5.2.0.215
 DISTVERSIONPREFIX= mono-
-PORTREVISION= 1
 CATEGORIES= lang

 MAINTAINER= m...@freebsd.org
russellh@fbd-12:~/ports % exit

exit

Script done on Fri Sep 22 11:46:10 2017


Cheers,
Russ

> Regards
>
> On 25 August 2017 at 21:41, David Naylor  wrote:
>
>> On Tuesday, 15 August 2017 12:21:20 Romain Tartière wrote:
>> > Hi David,
>> >
>> > On Tue, Aug 15, 2017 at 09:11:57AM +0200, David Naylor wrote:
>> > > Here is an update on porting mono 5:
>> > >  - mono: 5.1.0.1 (needs to be updated to 5.2, tests run)
>> > >  - msbuild: 15.3 (needs tests ported and run, upstream bugs filed)
>> > >  - fsharp: 4.1.25 (WIP)
>> > >  - monodevelop: 7.0.1.24 (WIP)
>> > >  - gtksharp20: 2.12.45 (WIP)
>> > >  - avahi-sharp: 0.7 (not started)
>> > >  - bumping all dependent ports (not started)
>> > >  - exp-run (not started)
>> > >
>> > > Would anyone be interested in doing a (Phabricator) review?
>> >
>> > I don't actively use mono nowadays but sure, I can check if my old code
>> > tests suites still pass with the update.  I have just registered to
>> > Phabricator and have no previous experience with this tool, so get ready
>> > to teach me stuff ;-)
>>
>> Great, thanks.
>>
>> Here is a status update (with patch [1][3]).  Things aren't ready yet, but
>> as
>> it
>> stands:
>>  - lang/mono: 5.2.0.215 (tests failing in mcs/class/corlib
>> [run-test-local])
>>  - devel/msbuild: 15.3 (tests failing [with SIGABRT])
>>  - lang/sharp: 4.1.25 (tests failing in math/measures/test.fsx [Invalid IL
>> code])
>>  - x11-toolkits/gtk-sharp20: 2.12.45
>>  - x11-toolkits/gnome-sharp20: 2.24.4
>> WIP:
>>  - devel/monodevelop: 7.1.0.1297 (full nuget package restore required
>> [extra
>> nuget support required])
>>  - devel/mono-addins: depreciate [2] (broken with mono5), fix dependencies
>> TODO:
>>  - mono: test self hosting
>>  - update mono-lite version
>>  - avahi-sharp: 0.7
>>  - bump all dependent ports
>>  - exp-run
>>  - commit to ports
>>  - upstream patches
>>  - fix tests
>>
>> Note that the failing tests don't worry me too much.  Most of them are edge
>> cases that won't affect the average user (i.e. not a blocker to commit to
>> ports) - also I don't know how many tests are failing on other platforms
>> (if
>> any).
>>
>> [1] git clone https://github.com/DragonSA/ports; cd ports; git diff
>> master..origin/mono5.2.0.215
>> [2] A general discussion needs to be had around nuget packages.  How do we
>> consume them?
>>   i) as downloads with each port containing a copy
>>  ii) local ports with consistency across the Ports Collections
>> iii) A mixture of the above (i.e. (ii) is there is a native component,
>> otherwise (i))
>> I prefer (ii) as I think it gives the end user the best leverage to patch
>> issues with nuget packages locally (and to get updates without waiting on
>> a)
>> upstream, and b) us/ports maintainer).  However, at this point that option
>> is
>> at 0% progress.
>> [3] https://people.freebsd.org/~dbn/mono-20170825.diff.xz
> ___
> freebsd-mono@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-mono
> To unsubscribe, send any mail to "freebsd-mono-unsubscr...@freebsd.org"
___
freebsd-mono@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-mono
To unsubscribe, send any mail to "freebsd-mono-unsubscr...@freebsd.org"

Re: Update on porting mono 5

[David Naylor]

Hi

A quick update on the update to mono5.  In theory everything should be
working (i.e. mono, monodevelop, etc).

A review has also been created (so you can access the patch).  Please test
it.

https://reviews.freebsd.org/D12440

Regards

On 25 August 2017 at 21:41, David Naylor  wrote:

> On Tuesday, 15 August 2017 12:21:20 Romain Tartière wrote:
> > Hi David,
> >
> > On Tue, Aug 15, 2017 at 09:11:57AM +0200, David Naylor wrote:
> > > Here is an update on porting mono 5:
> > >  - mono: 5.1.0.1 (needs to be updated to 5.2, tests run)
> > >  - msbuild: 15.3 (needs tests ported and run, upstream bugs filed)
> > >  - fsharp: 4.1.25 (WIP)
> > >  - monodevelop: 7.0.1.24 (WIP)
> > >  - gtksharp20: 2.12.45 (WIP)
> > >  - avahi-sharp: 0.7 (not started)
> > >  - bumping all dependent ports (not started)
> > >  - exp-run (not started)
> > >
> > > Would anyone be interested in doing a (Phabricator) review?
> >
> > I don't actively use mono nowadays but sure, I can check if my old code
> > tests suites still pass with the update.  I have just registered to
> > Phabricator and have no previous experience with this tool, so get ready
> > to teach me stuff ;-)
>
> Great, thanks.
>
> Here is a status update (with patch [1][3]).  Things aren't ready yet, but
> as
> it
> stands:
>  - lang/mono: 5.2.0.215 (tests failing in mcs/class/corlib
> [run-test-local])
>  - devel/msbuild: 15.3 (tests failing [with SIGABRT])
>  - lang/sharp: 4.1.25 (tests failing in math/measures/test.fsx [Invalid IL
> code])
>  - x11-toolkits/gtk-sharp20: 2.12.45
>  - x11-toolkits/gnome-sharp20: 2.24.4
> WIP:
>  - devel/monodevelop: 7.1.0.1297 (full nuget package restore required
> [extra
> nuget support required])
>  - devel/mono-addins: depreciate [2] (broken with mono5), fix dependencies
> TODO:
>  - mono: test self hosting
>  - update mono-lite version
>  - avahi-sharp: 0.7
>  - bump all dependent ports
>  - exp-run
>  - commit to ports
>  - upstream patches
>  - fix tests
>
> Note that the failing tests don't worry me too much.  Most of them are edge
> cases that won't affect the average user (i.e. not a blocker to commit to
> ports) - also I don't know how many tests are failing on other platforms
> (if
> any).
>
> [1] git clone https://github.com/DragonSA/ports; cd ports; git diff
> master..origin/mono5.2.0.215
> [2] A general discussion needs to be had around nuget packages.  How do we
> consume them?
>   i) as downloads with each port containing a copy
>  ii) local ports with consistency across the Ports Collections
> iii) A mixture of the above (i.e. (ii) is there is a native component,
> otherwise (i))
> I prefer (ii) as I think it gives the end user the best leverage to patch
> issues with nuget packages locally (and to get updates without waiting on
> a)
> upstream, and b) us/ports maintainer).  However, at this point that option
> is
> at 0% progress.
> [3] https://people.freebsd.org/~dbn/mono-20170825.diff.xz
___
freebsd-mono@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-mono
To unsubscribe, send any mail to "freebsd-mono-unsubscr...@freebsd.org"

Re: Update on porting mono 5

[Romain Tartière]

On Fri, Sep 08, 2017 at 04:35:36PM -0700, Russell Haley wrote:
> Thanks for that Romain! I suppose I was more being philosophical then
> literal (and a little silly). If the pkg repository server where the
> package was built is using the exact same sources, OS version and
> dependencies as I would use from Ports, IS it a binary? Your (perfect)
> response clearly shows the answer is yes, but I was trying to have
> some fun with that idea.

In fact, it's the rather large problem of "reproductible builds" [1]
which is embrassed by many projects [2].

I just discovered FreeBSD even has a Mailing-List dedicated to this
topic [3]. While the archive seems to say no essage where posted, I
guess a few folks are subscribed, and adding this list to the discussion
might be a good idea?

References:
  1. https://reproducible-builds.org/
  2. https://reproducible-builds.org/who/
  3. https://lists.freebsd.org/mailman/listinfo/freebsd-reproducibility

-- 
Romain Tartière   http://people.FreeBSD.org/~romain/
pgp: 8234 9A78 E7C0 B807 0B59  80FF BA4D 1D95 5112 336F (ID: 0x5112336F)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)


signature.asc
Description: PGP signature

Re: Update on porting mono 5

[Russell Haley]

On Fri, Sep 8, 2017 at 12:41 AM, Romain Tartière  wrote:
> On Thu, Sep 07, 2017 at 05:36:17PM -0700, Russell Haley wrote:
>> A subtle but important distinction. Also, are all items available in
>> pkg built from source? If yes, does that mean pkg is a source or
>> binary download? (kaboom! My head explodes).
>
> Unfortunately, some packages are not build from source.
>
> Let's recap, FreeBSD has a ports tree and also packages:
>
>   - When installing through the ports tree, you build the software from
> source.  Any missing build or run dependency is also build from
> source.  The "ports tree" is basically a set of rules to build each
> piece of software, and is made available by the FreeBSD project on
> the internet;
>   - When you install using packages, you install binaries. Only missing
> run-time dependencies are installed using packages (no
> build-dependencies since you build nothing, so you end-up with less
> software installed).  The packages you install have been build using
> the ports tree (with ports-mgmt/poudriere for example) on some
> machine of the FreeBSD project, and made available to the wild.
>
> So, when using pkg(8), you only handle binary packages, never source
> code.  But the opposite is not true: the ports tree attempts to cope with
> redistribution restrictions [1], so some ports will just download and
> install binary blobs (e.g. proprietary drivers).
>
> By extension, some ports decided to trim-down build dependencies by
> simply downloading a binary (it works well for things like Java and .Net
> because they are not native binaries).  To check this, have a look at
> the many Java project (e.g. net/activemq downloads a tarball containing
> 107 .jar files and has NO_BUILD set, so the port just put the files at
> the right place, but does nothing more).
>
> Even some upstream projects trend to do so, for example, when compiling
> monodevelop from upstream's source, the build procedure use nugets to
> download dependencies as binary blobs.  I understand that it eases-up
> the life of the project's developers, but is not in-line with the
> philosophy of the ports tree. Ports are supposed to build from source,
> quoting the porter handbook [2]: « Always use mainstream sources when
> and where possible ».
>
> Russell, do these details help preventing your head from exploding?

Thanks for that Romain! I suppose I was more being philosophical then
literal (and a little silly). If the pkg repository server where the
package was built is using the exact same sources, OS version and
dependencies as I would use from Ports, IS it a binary? Your (perfect)
response clearly shows the answer is yes, but I was trying to have
some fun with that idea.

Cheers!

Russ

> References:
>  1. 
> https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/book.html#porting-restrictions
>  2. 
> https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/book.html#slow-sources
>
> --
> Romain Tartière   http://people.FreeBSD.org/~romain/
> pgp: 8234 9A78 E7C0 B807 0B59  80FF BA4D 1D95 5112 336F (ID: 0x5112336F)
> (plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)
___
freebsd-mono@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-mono
To unsubscribe, send any mail to "freebsd-mono-unsubscr...@freebsd.org"

Re: Update on porting mono 5

[Romain Tartière]

On Thu, Sep 07, 2017 at 05:36:17PM -0700, Russell Haley wrote:
> A subtle but important distinction. Also, are all items available in
> pkg built from source? If yes, does that mean pkg is a source or
> binary download? (kaboom! My head explodes).

Unfortunately, some packages are not build from source.

Let's recap, FreeBSD has a ports tree and also packages:

  - When installing through the ports tree, you build the software from
source.  Any missing build or run dependency is also build from
source.  The "ports tree" is basically a set of rules to build each
piece of software, and is made available by the FreeBSD project on
the internet;
  - When you install using packages, you install binaries. Only missing
run-time dependencies are installed using packages (no
build-dependencies since you build nothing, so you end-up with less
software installed).  The packages you install have been build using
the ports tree (with ports-mgmt/poudriere for example) on some
machine of the FreeBSD project, and made available to the wild.

So, when using pkg(8), you only handle binary packages, never source
code.  But the opposite is not true: the ports tree attempts to cope with
redistribution restrictions [1], so some ports will just download and
install binary blobs (e.g. proprietary drivers).

By extension, some ports decided to trim-down build dependencies by
simply downloading a binary (it works well for things like Java and .Net
because they are not native binaries).  To check this, have a look at
the many Java project (e.g. net/activemq downloads a tarball containing
107 .jar files and has NO_BUILD set, so the port just put the files at
the right place, but does nothing more).

Even some upstream projects trend to do so, for example, when compiling
monodevelop from upstream's source, the build procedure use nugets to
download dependencies as binary blobs.  I understand that it eases-up
the life of the project's developers, but is not in-line with the
philosophy of the ports tree. Ports are supposed to build from source,
quoting the porter handbook [2]: « Always use mainstream sources when
and where possible ».

Russell, do these details help preventing your head from exploding?

References:
 1. 
https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/book.html#porting-restrictions
 2. 
https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/book.html#slow-sources

-- 
Romain Tartière   http://people.FreeBSD.org/~romain/
pgp: 8234 9A78 E7C0 B807 0B59  80FF BA4D 1D95 5112 336F (ID: 0x5112336F)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)


signature.asc
Description: PGP signature

Re: Update on porting mono 5

[Russell Haley]

On Thu, Sep 7, 2017 at 11:09 AM, David Naylor  wrote:
> On Tuesday, 5 September 2017 13:09:14 Russell Haley wrote:
>> On Tue, Sep 5, 2017 at 12:25 PM, David Naylor 
> wrote:
>> > On Saturday, 2 September 2017 07:40:28 Russell Haley wrote:
>> >> On Sat, Sep 2, 2017 at 4:55 AM, Robert Alegrid 
>> >> Worrying about per-port repositories for Nuget is not a thing because
>> >> the manifest within DotNet applications decides what runtime version
>> >> of the assembly to use at build time so it is necessarily per-port.
>> >> Also, DotNet can have hard or soft links (I forget the terminology) to
>> >> required assemblies in the sense they can specify to use any version
>> >> or a specific version, and can specify if the assemblies require to be
>> >> signed (i.e. verified by the authors credentials against a trusted
>> >> list). The GAC handles versioning for system level assemblies and if
>> >> you overwrite a required version in your local repository it's a
>> >> development error that you need to sort yourself.
>> >
>> > Unfortunately, we do need to worry about per ports dependencies.  In the
>> > practical case it is around the need to download the nuget packages within
>> > the Ports Collections framework (so we get security protection, etc),
>> > before the build phase.  Ports are not allowed interest access during
>> > build.
>>
>> In my mind, all the build tools/build dependencies should be handled
>> differently from the runtime dependencies. These binaries we are
>> discussing are only used for bootstrapping if I understand correctly.
>> Build items specified within the port that are only available as
>> binaries from nuget should be downloaded into the "work" directory and
>> discarded after the build is complete (via make clean). I would think
>> this is true unless said binaries are also runtime requirements, but
>> in that case I would think the runtime required copies should be built
>> from source where possible.
>
> I agree with the above - except how do we define a runtime dependency:
>  a) If the dependency needs to be installed (i.e. `pkg add`) for the program
> to run; or
>  b) The program needs the dependency's dll (even if it is bundled) to run
>
> I think the policy should be for (b) [but (a) for now due to practical
> issues].
>
> Regards

Hi David,

TLDR; I agree with you, but since I typed out my thoughts, I'll add it
to the discussion...

A subtle but important distinction. Also, are all items available in
pkg built from source? If yes, does that mean pkg is a source or
binary download? (kaboom! My head explodes).

My attempt at clarity about what constitutes a runtime dependency:

First we should clarify what dependency means in this context. I think
what we are really meaning is *external* dependency. If the sources
(sigh, or binaries. I may come from Windows land, but it still makes
me sad...) are provided by the package itself and used during runtime,
it is NOT an external runtime dependency and should not be considered.
This may be splitting hairs though. What if a version of OpenSSL is
included as source and built by the applications build tools? Is it an
internal or external dependency? (kaboom!). Again, I think we could
(willfully) simplify this by saying "anything not built (or
downloaded) by the application build tool for use by the build tools
output" is an external dependency and of interest to the discussion.

In the end, I think you are correct in your assessment. Policy A
(external dependencies) is really what we are talking about now, but a
shift to a more granular view of a package may provide flexibility.
That flexibility may come at the potential cost of adding complexity
and uncertainty (i.e. allowing someone to change an 'internal
dependency' package would have consequences). One must ask though, if
the user really wants to start mucking with internal library versions,
that user should just build from source themselves. Is the ports tool
a general tool for users, or a source manager for developers (a la Git
or Sourceforge)? As always, applying requirements gathering practices
to a problem is probably wise: What is our use case for Ports?

Russ
___
freebsd-mono@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-mono
To unsubscribe, send any mail to "freebsd-mono-unsubscr...@freebsd.org"

Re: Update on porting mono 5

[David Naylor]

On Tuesday, 5 September 2017 13:09:14 Russell Haley wrote:
> On Tue, Sep 5, 2017 at 12:25 PM, David Naylor  
wrote:
> > On Saturday, 2 September 2017 07:40:28 Russell Haley wrote:
> >> On Sat, Sep 2, 2017 at 4:55 AM, Robert Alegrid 
> >> Worrying about per-port repositories for Nuget is not a thing because
> >> the manifest within DotNet applications decides what runtime version
> >> of the assembly to use at build time so it is necessarily per-port.
> >> Also, DotNet can have hard or soft links (I forget the terminology) to
> >> required assemblies in the sense they can specify to use any version
> >> or a specific version, and can specify if the assemblies require to be
> >> signed (i.e. verified by the authors credentials against a trusted
> >> list). The GAC handles versioning for system level assemblies and if
> >> you overwrite a required version in your local repository it's a
> >> development error that you need to sort yourself.
> > 
> > Unfortunately, we do need to worry about per ports dependencies.  In the
> > practical case it is around the need to download the nuget packages within
> > the Ports Collections framework (so we get security protection, etc),
> > before the build phase.  Ports are not allowed interest access during
> > build.
> 
> In my mind, all the build tools/build dependencies should be handled
> differently from the runtime dependencies. These binaries we are
> discussing are only used for bootstrapping if I understand correctly.
> Build items specified within the port that are only available as
> binaries from nuget should be downloaded into the "work" directory and
> discarded after the build is complete (via make clean). I would think
> this is true unless said binaries are also runtime requirements, but
> in that case I would think the runtime required copies should be built
> from source where possible.

I agree with the above - except how do we define a runtime dependency:
 a) If the dependency needs to be installed (i.e. `pkg add`) for the program 
to run; or
 b) The program needs the dependency's dll (even if it is bundled) to run

I think the policy should be for (b) [but (a) for now due to practical 
issues].  

Regards


signature.asc
Description: This is a digitally signed message part.

Re: Update on porting mono 5

[Russell Haley]

* I apologize for being lazy and linking to stack exchange answers. In
a perfect world I would go and look this stuff up in the Nuget
documentation. It leaves open the possibility of miss-interpretation
(by me) and possible wrong answers.

On Tue, Sep 5, 2017 at 12:25 PM, David Naylor  wrote:
> On Saturday, 2 September 2017 07:40:28 Russell Haley wrote:
>> On Sat, Sep 2, 2017 at 4:55 AM, Robert Alegrid 
> wrote:
>> >>Another problem with nugets packages is that you only get binaries,
>> >>right?  That means that is something goes really wrong, there is no way
>> >>to audit the source code of what led to disaster.  The problem is
>> >>similar with the few Java projects I gave a look at.  My feeling is that
>> >>this is even worst :-(  Ruby being interpreted, there is no such
>> >>problems.
>> >>
>> > NuGet packages have in their manifest a field to specify where the source
>> > code lives. However, since it's optional and is just a URL to the
>> > repository, it probably doesn't help much for this use case.
>>
>> Is this coming up because of the use of Nuget during the build process
>> or is it because of general concern for the user?
>
> The first issue is a practical one: with ports now requiring tens of nuget
> packages (and lock files generated by nuget - so we cannot cheat) it is
> becoming an issue with porting.

 Agreed. A poor deployment strategy by the Mono team IMHO.

> The second issue is more a philosophical one around concern for the user.  The
> discussion below covers this concern and doesn't change the immediate plans
> for handling nuget packages (as bundled dependencies).
>
>> As a professional DotNet developer, I agree with Mr. Alegrid for the
>> most part. Nuget is designed as a binary tool because DotNet is a
>> binary based system. It comes from a user mindset, not an opensource
>> mindset. Because of that, I question why we are having this
>> discussion. Is it not the decision of the user/developer how they
>> would like to use their package manager?  Also, it is their choice if
>> they prefer to use sources. I sometimes do both. Stable packages from
>> Nuget and others from source.
>
> The question here is how easy is it for the developer to change the binaries
> they consume?
>
> A good way to illustrate the problem is the Heart Bleed bug in OpenSSL.
> Currently on FreeBSD the libopenssl.so file is centrally accessible, so to fix
> the bug just requires fixing the centrally stored libopenssl.so file.
> However, if all programs that used libopenssl.so had their own local copy (say
> statically compiled, or otherwise) the fix would be a headache.  In the land
> of Ports, we would need to patch (or wait for an update of) every single port
> that used OpenSSL.
>
> This is obviously a problematic situation to be in.  Philosophically it is one
> of the differences between Windows (everyone bundles all their dependencies)
> and Unix [1] (all dependencies are centrally available).

My perspective is that the entire point of Nuget is allow a developer
to intrinsically link his project to a binary file of a specific
version and be confident that the package manager will always download
and link to that version (see the answer here:
https://stackoverflow.com/questions/19817378/is-it-possible-to-add-update-assemblies-to-the-gac-via-a-nuget-package.).
If the developer *wants* to always use the latest version, that is
something the developer can configure (see
https://stackoverflow.com/questions/24765802/nuget-spec-dependencies-get-latest-version).

Though I agree with your point, I don't agree that this is a
Unix/Windows difference. There are plenty of packages and applications
on Unix where the developer chose not to use the global version and
"Library Hell" is a real thing that FreeBSD handles very manually by
specifying the version in the port name (Lua is a great example having
lua51, lua52 and lua53). Conversely, Windows spent a long time using
the registry (shudder) and the GAC has existed since the inception of
DotNet. For DotNet, the decision to move to per-installation libraries
has been a conscious choice made irrespective of OS philosophy.

>> Nuget is designed for local, per project resources. It is particularly
>> effective when developing across many developers as it will go and get
>> the packages for you automatically at build time (wicked cool feature,
>> which seamlessly mixes source with binary distribution). Items that
>> are supposed to live system wide are to be stored in the General
>> Assembly Cache (GAC) and should be designed to be put there. You can
>> get Nuget to drop things in the GAC but have not used this feature.
>> The GAC is designed around large scale software deployments which,
>> sadly, I don't think will ever apply to mono on FreeBSD.
>
> In a limited sense, nuget is redundant on FreeBSD thanks to the Ports
> Collection and pkg - but I do see the need on Windows and more generally in
> the .NET ecosystem.
>
> Do you perhaps have any links that detail how nu

Re: Update on porting mono 5

[David Naylor]

On Saturday, 2 September 2017 07:40:28 Russell Haley wrote:
> On Sat, Sep 2, 2017 at 4:55 AM, Robert Alegrid  
wrote:
> >>Another problem with nugets packages is that you only get binaries,
> >>right?  That means that is something goes really wrong, there is no way
> >>to audit the source code of what led to disaster.  The problem is
> >>similar with the few Java projects I gave a look at.  My feeling is that
> >>this is even worst :-(  Ruby being interpreted, there is no such
> >>problems.
> >>
> > NuGet packages have in their manifest a field to specify where the source
> > code lives. However, since it's optional and is just a URL to the
> > repository, it probably doesn't help much for this use case.
> 
> Is this coming up because of the use of Nuget during the build process
> or is it because of general concern for the user?

The first issue is a practical one: with ports now requiring tens of nuget 
packages (and lock files generated by nuget - so we cannot cheat) it is 
becoming an issue with porting.  

The second issue is more a philosophical one around concern for the user.  The 
discussion below covers this concern and doesn't change the immediate plans 
for handling nuget packages (as bundled dependencies).  

> As a professional DotNet developer, I agree with Mr. Alegrid for the
> most part. Nuget is designed as a binary tool because DotNet is a
> binary based system. It comes from a user mindset, not an opensource
> mindset. Because of that, I question why we are having this
> discussion. Is it not the decision of the user/developer how they
> would like to use their package manager?  Also, it is their choice if
> they prefer to use sources. I sometimes do both. Stable packages from
> Nuget and others from source.

The question here is how easy is it for the developer to change the binaries 
they consume?  

A good way to illustrate the problem is the Heart Bleed bug in OpenSSL.  
Currently on FreeBSD the libopenssl.so file is centrally accessible, so to fix 
the bug just requires fixing the centrally stored libopenssl.so file.  
However, if all programs that used libopenssl.so had their own local copy (say 
statically compiled, or otherwise) the fix would be a headache.  In the land 
of Ports, we would need to patch (or wait for an update of) every single port 
that used OpenSSL.  

This is obviously a problematic situation to be in.  Philosophically it is one 
of the differences between Windows (everyone bundles all their dependencies) 
and Unix [1] (all dependencies are centrally available).  

> Nuget is designed for local, per project resources. It is particularly
> effective when developing across many developers as it will go and get
> the packages for you automatically at build time (wicked cool feature,
> which seamlessly mixes source with binary distribution). Items that
> are supposed to live system wide are to be stored in the General
> Assembly Cache (GAC) and should be designed to be put there. You can
> get Nuget to drop things in the GAC but have not used this feature.
> The GAC is designed around large scale software deployments which,
> sadly, I don't think will ever apply to mono on FreeBSD.

In a limited sense, nuget is redundant on FreeBSD thanks to the Ports 
Collection and pkg - but I do see the need on Windows and more generally in 
the .NET ecosystem.  

Do you perhaps have any links that detail how nuget can store dlls in the GAC?

> Worrying about per-port repositories for Nuget is not a thing because
> the manifest within DotNet applications decides what runtime version
> of the assembly to use at build time so it is necessarily per-port.
> Also, DotNet can have hard or soft links (I forget the terminology) to
> required assemblies in the sense they can specify to use any version
> or a specific version, and can specify if the assemblies require to be
> signed (i.e. verified by the authors credentials against a trusted
> list). The GAC handles versioning for system level assemblies and if
> you overwrite a required version in your local repository it's a
> development error that you need to sort yourself.

Unfortunately, we do need to worry about per ports dependencies.  In the 
practical case it is around the need to download the nuget packages within the 
Ports Collections framework (so we get security protection, etc), before the 
build phase.  Ports are not allowed interest access during build.  

Regards

[1] I know PC-BSD, for a while at least, also bundles all dependencies within 
a PBI?

signature.asc
Description: This is a digitally signed message part.

Re: Update on porting mono 5

[David Naylor]

On Saturday, 2 September 2017 11:55:15 Robert Alegrid wrote:
> I apologize in advance if I formatted this message incorrectly or addressed
> it incorrectly. This is the first time I'm posting to a mailing list, so I
> have no real idea how I should be doing it.

Looks good to me :-), welcome to the list.  

> I also just program as a hobby (and mostly on Windows at that), so that
> should be taken in consideration as well.
> 
> On Saturday, 2 September 2017 7:03 PM, Romain Tartière wrote:
> >On Fri, Aug 25, 2017 at 09:41:43PM +0200, David Naylor wrote:
> >> [2] A general discussion needs to be had around nuget packages.  How do
> >> we
> >> consume them?
> >>
> >>   i) as downloads with each port containing a copy
> >>  ii) local ports with consistency across the Ports Collections
> >>
> >> iii) A mixture of the above (i.e. (ii) is there is a native component,
> >> otherwise (i))
> >> I prefer (ii) as I think it gives the end user the best leverage to patch
> >> issues with nuget packages locally (and to get updates without waiting on
> >> a) upstream, and b) us/ports maintainer).  However, at this point that
> >> option is at 0% progress.
> 
> It's possible for NuGet to use a local directory as a feed:
>   https://docs.microsoft.com/en-us/nuget/hosting-packages/local-feeds
> If you add the local feed earlier in the list of sources, it should pick up
> your locally built packages instead of fetching it from the internet.

Good to know, but this will still require patching each port to use a local 
feed.

> NuGet also maintains a cache of packages that it uses to restore from when
> it doesn't have an internet connection to work with.

I believe this location is $PACKAGES=$HOME/.nuget/packages and is the best 
approach to provide packages during build phase.  

Regards

signature.asc
Description: This is a digitally signed message part.

Re: Update on porting mono 5

[David Naylor]

On Saturday, 2 September 2017 11:03:59 Romain Tartière wrote:
> On Fri, Aug 25, 2017 at 09:41:43PM +0200, David Naylor wrote:
> > [2] A general discussion needs to be had around nuget packages.  How do we
> > consume them?
> > 
> >   i) as downloads with each port containing a copy
> >  
> >  ii) local ports with consistency across the Ports Collections
> > 
> > iii) A mixture of the above (i.e. (ii) is there is a native component,
> > otherwise (i))
> > I prefer (ii) as I think it gives the end user the best leverage to patch
> > issues with nuget packages locally (and to get updates without waiting on
> > a) upstream, and b) us/ports maintainer).  However, at this point that
> > option is at 0% progress.
> 
> Yeah, it's a problem that is broader and broader…  and for which I don't
> think a universal solution works :-/

At a minimum, any nuget package that contains a native (i.e. compiled) portion 
needs to be a Port.  

> With local copies (i) you end-up with a lot of duplication (Go
> applications are a good example of how this can become quite stupid, I
> recently created a port for a go application, the source tarball
> includes the source of all dependencies, and everything is bundled in a
> 13MB executable (that only depends on libc.so and libthr.so).
> 
> With a port per dependency (ii), you sooner or later have to handle
> conflicts between dependencies (port A needs foo-1.0.0 but port B needs
> foo-2.0.0) and it can get tricky.

I think we can already handle that (see all the Qt ports).  I'm not sure what 
currently happens when A depends on B and C but B and C depend on different 
versions of D.  Does .NET just use the latest version of D?

> I only have experience with programming with Ruby as a language that has
> similar problem.  I ended at only installing system tools using the
> FreeBSD ports (e.g. puppet, vagrant, passenger), and for applications I
> actually use, I just grab the source, and use bundler to gather all
> dependencies as the user running the software, therefore I end up having
> something similar to (i) without using the port system.
> 
> My weak Windows development experience learned me to put all dll of an
> application in the application directory.  If it's still a good advice,
> I guess that each application should have it's copy of all it's
> dependencies, and therefore each port should install a bundle of all
> what is required by it.

In my ideal situation all dlls will be installed in the GAC (or just linked to 
where they are installed).  If I read this [1] correctly, Debian advocates for 
all dlls to be registered in the GAC.  
 
> Another problem with nugets packages is that you only get binaries,
> right?  That means that is something goes really wrong, there is no way
> to audit the source code of what led to disaster.  The problem is
> similar with the few Java projects I gave a look at.  My feeling is that
> this is even worst :-(  Ruby being interpreted, there is no such
> problems.
> 
> I am not enough involved in Java nor .Net to think about mitigations of
> this issue.

This is my primary concern, how does one take control when each port manages 
its own private dependencies.  

[1] https://pkg-mono.alioth.debian.org/cli-policy/

signature.asc
Description: This is a digitally signed message part.

Re: Update on porting mono 5

[Russell Haley]

On Sat, Sep 2, 2017 at 4:55 AM, Robert Alegrid  wrote:
> I apologize in advance if I formatted this message incorrectly or addressed it
> incorrectly. This is the first time I'm posting to a mailing list, so I have 
> no
> real idea how I should be doing it.
>
> I also just program as a hobby (and mostly on Windows at that), so that should
> be taken in consideration as well.
>
> On Saturday, 2 September 2017 7:03 PM, Romain Tartière wrote:
>>On Fri, Aug 25, 2017 at 09:41:43PM +0200, David Naylor wrote:
>>> [2] A general discussion needs to be had around nuget packages.  How do we
>>> consume them?
>>>   i) as downloads with each port containing a copy
>>>  ii) local ports with consistency across the Ports Collections
>>> iii) A mixture of the above (i.e. (ii) is there is a native component,
>>> otherwise (i))
>>> I prefer (ii) as I think it gives the end user the best leverage to patch
>>> issues with nuget packages locally (and to get updates without waiting on a)
>>> upstream, and b) us/ports maintainer).  However, at this point that option 
>>> is
>>> at 0% progress.
> It's possible for NuGet to use a local directory as a feed:
>   https://docs.microsoft.com/en-us/nuget/hosting-packages/local-feeds
> If you add the local feed earlier in the list of sources, it should pick up 
> your
> locally built packages instead of fetching it from the internet.
>
> NuGet also maintains a cache of packages that it uses to restore from when it
> doesn't have an internet connection to work with.
>
>>Yeah, it's a problem that is broader and broader…  and for which I don't
>>think a universal solution works :-/
>>
>>With local copies (i) you end-up with a lot of duplication (Go
>>applications are a good example of how this can become quite stupid, I
>>recently created a port for a go application, the source tarball
>>includes the source of all dependencies, and everything is bundled in a
>>13MB executable (that only depends on libc.so and libthr.so).
>>
>>With a port per dependency (ii), you sooner or later have to handle
>>conflicts between dependencies (port A needs foo-1.0.0 but port B needs
>>foo-2.0.0) and it can get tricky.
> When building a prgram, you can save
> You're going to end up with a lot of duplication either way, given how 
> assembly
> locations are resolved:
>   http://www.mono-project.com/docs/advanced/assemblies-and-the-gac/
>
>>I only have experience with programming with Ruby as a language that has
>>similar problem.  I ended at only installing system tools using the
>>FreeBSD ports (e.g. puppet, vagrant, passenger), and for applications I
>>actually use, I just grab the source, and use bundler to gather all
>>dependencies as the user running the software, therefore I end up having
>>something similar to (i) without using the port system.
>>
>>My weak Windows development experience learned me to put all dll of an
>>application in the application directory.  If it's still a good advice,
>>I guess that each application should have it's copy of all it's
>>dependencies, and therefore each port should install a bundle of all
>>what is required by it.
> Aside from a few special assemblies which live in the GAC, yes, that's 
> basically
> what you're supposed to do.
>
>>Another problem with nugets packages is that you only get binaries,
>>right?  That means that is something goes really wrong, there is no way
>>to audit the source code of what led to disaster.  The problem is
>>similar with the few Java projects I gave a look at.  My feeling is that
>>this is even worst :-(  Ruby being interpreted, there is no such
>>problems.
> NuGet packages have in their manifest a field to specify where the source code
> lives. However, since it's optional and is just a URL to the repository, it
> probably doesn't help much for this use case.

Is this coming up because of the use of Nuget during the build process
or is it because of general concern for the user?

As a professional DotNet developer, I agree with Mr. Alegrid for the
most part. Nuget is designed as a binary tool because DotNet is a
binary based system. It comes from a user mindset, not an opensource
mindset. Because of that, I question why we are having this
discussion. Is it not the decision of the user/developer how they
would like to use their package manager?  Also, it is their choice if
they prefer to use sources. I sometimes do both. Stable packages from
Nuget and others from source.

Nuget is designed for local, per project resources. It is particularly
effective when developing across many developers as it will go and get
the packages for you automatically at build time (wicked cool feature,
which seamlessly mixes source with binary distribution). Items that
are supposed to live system wide are to be stored in the General
Assembly Cache (GAC) and should be designed to be put there. You can
get Nuget to drop things in the GAC but have not used this feature.
The GAC is designed around large scale software deployments which,
sadly, I don't think wi

Re: Update on porting mono 5

[Robert Alegrid]

I apologize in advance if I formatted this message incorrectly or addressed it
incorrectly. This is the first time I'm posting to a mailing list, so I have no
real idea how I should be doing it.

I also just program as a hobby (and mostly on Windows at that), so that should
be taken in consideration as well.

On Saturday, 2 September 2017 7:03 PM, Romain Tartière wrote:
>On Fri, Aug 25, 2017 at 09:41:43PM +0200, David Naylor wrote:
>> [2] A general discussion needs to be had around nuget packages.  How do we 
>> consume them?
>>   i) as downloads with each port containing a copy
>>  ii) local ports with consistency across the Ports Collections
>> iii) A mixture of the above (i.e. (ii) is there is a native component, 
>> otherwise (i))
>> I prefer (ii) as I think it gives the end user the best leverage to patch 
>> issues with nuget packages locally (and to get updates without waiting on a) 
>> upstream, and b) us/ports maintainer).  However, at this point that option 
>> is 
>> at 0% progress.  
It's possible for NuGet to use a local directory as a feed:
  https://docs.microsoft.com/en-us/nuget/hosting-packages/local-feeds
If you add the local feed earlier in the list of sources, it should pick up your
locally built packages instead of fetching it from the internet.

NuGet also maintains a cache of packages that it uses to restore from when it
doesn't have an internet connection to work with.

>Yeah, it's a problem that is broader and broader…  and for which I don't
>think a universal solution works :-/
>
>With local copies (i) you end-up with a lot of duplication (Go
>applications are a good example of how this can become quite stupid, I
>recently created a port for a go application, the source tarball
>includes the source of all dependencies, and everything is bundled in a
>13MB executable (that only depends on libc.so and libthr.so).
>
>With a port per dependency (ii), you sooner or later have to handle
>conflicts between dependencies (port A needs foo-1.0.0 but port B needs
>foo-2.0.0) and it can get tricky.
When building a prgram, you can save 
You're going to end up with a lot of duplication either way, given how assembly
locations are resolved:
  http://www.mono-project.com/docs/advanced/assemblies-and-the-gac/

>I only have experience with programming with Ruby as a language that has
>similar problem.  I ended at only installing system tools using the
>FreeBSD ports (e.g. puppet, vagrant, passenger), and for applications I
>actually use, I just grab the source, and use bundler to gather all
>dependencies as the user running the software, therefore I end up having
>something similar to (i) without using the port system.
>
>My weak Windows development experience learned me to put all dll of an
>application in the application directory.  If it's still a good advice,
>I guess that each application should have it's copy of all it's
>dependencies, and therefore each port should install a bundle of all
>what is required by it.
Aside from a few special assemblies which live in the GAC, yes, that's basically
what you're supposed to do.

>Another problem with nugets packages is that you only get binaries,
>right?  That means that is something goes really wrong, there is no way
>to audit the source code of what led to disaster.  The problem is
>similar with the few Java projects I gave a look at.  My feeling is that
>this is even worst :-(  Ruby being interpreted, there is no such
>problems.
NuGet packages have in their manifest a field to specify where the source code
lives. However, since it's optional and is just a URL to the repository, it
probably doesn't help much for this use case.

Regards,
Robert Alegrid
___
freebsd-mono@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-mono
To unsubscribe, send any mail to "freebsd-mono-unsubscr...@freebsd.org"

Re: Update on porting mono 5

[Romain Tartière]

On Fri, Aug 25, 2017 at 09:41:43PM +0200, David Naylor wrote:
> [2] A general discussion needs to be had around nuget packages.  How do we 
> consume them?
>   i) as downloads with each port containing a copy
>  ii) local ports with consistency across the Ports Collections
> iii) A mixture of the above (i.e. (ii) is there is a native component, 
> otherwise (i))
> I prefer (ii) as I think it gives the end user the best leverage to patch 
> issues with nuget packages locally (and to get updates without waiting on a) 
> upstream, and b) us/ports maintainer).  However, at this point that option is 
> at 0% progress.  

Yeah, it's a problem that is broader and broader…  and for which I don't
think a universal solution works :-/

With local copies (i) you end-up with a lot of duplication (Go
applications are a good example of how this can become quite stupid, I
recently created a port for a go application, the source tarball
includes the source of all dependencies, and everything is bundled in a
13MB executable (that only depends on libc.so and libthr.so).

With a port per dependency (ii), you sooner or later have to handle
conflicts between dependencies (port A needs foo-1.0.0 but port B needs
foo-2.0.0) and it can get tricky.

I only have experience with programming with Ruby as a language that has
similar problem.  I ended at only installing system tools using the
FreeBSD ports (e.g. puppet, vagrant, passenger), and for applications I
actually use, I just grab the source, and use bundler to gather all
dependencies as the user running the software, therefore I end up having
something similar to (i) without using the port system.

My weak Windows development experience learned me to put all dll of an
application in the application directory.  If it's still a good advice,
I guess that each application should have it's copy of all it's
dependencies, and therefore each port should install a bundle of all
what is required by it.



Another problem with nugets packages is that you only get binaries,
right?  That means that is something goes really wrong, there is no way
to audit the source code of what led to disaster.  The problem is
similar with the few Java projects I gave a look at.  My feeling is that
this is even worst :-(  Ruby being interpreted, there is no such
problems.

I am not enough involved in Java nor .Net to think about mitigations of
this issue.

-- 
Romain Tartière   http://people.FreeBSD.org/~romain/
pgp: 8234 9A78 E7C0 B807 0B59  80FF BA4D 1D95 5112 336F (ID: 0x5112336F)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)


signature.asc
Description: PGP signature

Re: Update on porting mono 5

[Alexander Regueiro]

Thanks for the tip, Ivan. It’s actually enabled by default on Mono 5.2.

A

> On 26 Aug 2017, at 08:48, Ivan Radovanovic  wrote:
> 
> On 26/08/2017 02:47, Alexander Regueiro wrote:
>> Thanks for the tip. In fact, it turns out I just needed to use the 
>> `—disable-dtrace` option when configuring, to get rid of that linkage error, 
>> oops!
>> Here’s the successful procedure that I followed to build & install Mono 5.2 
>> on my FreeBSD 11 machine, in case it’s of interest to anyone while the port 
>> is being updated. I’m CCing the mailing list in case this is of use to 
>> someone.
>> (Make sure beforehand you have installed ports/packages for mono [to 
>> bootstrap], gcc, and gmake.)
>> The following can be run as a bash script and should do the whole job.
>> PREFIX=“$HOME/build/mono/“ &&
>> VERSION=“5.2.0.215” &&
>> FILENAME=“mono-$VERSION.tar.bz2” &&
>> curl -O "https://download.mono-project.com/sources/mono/$FILENAME 
>> ” &&
>> tar -xvf “$FILENAME” &&
>> cd “mono-$VERSION” &&
>> ./configure —prefix=“$PREFIX" --disable-nls --disable-dtrace --build="$(gcc 
>> -dumpmachine)” &&
>> sed -EI -e "s|#define HAVE_LOCALCHARSET_H.*|#undef HAVE_LOCALCHARSET_H|" 
>> eglib/config.h &&
>> mkdir -p “$PREFIX” &&
>> gmake &&
>> gmake install &&
>> echo “Mono $VERSION successfully built and installed to '$PREFIX'."
>> (This was inspired by the docs at 
>> http://www.mono-project.com/docs/compiling-mono/mac/ 
>> , but with some 
>> significant changes.)
>> Alex
> 
> I suggest enabling btls, otherwise it won't be able to connect to servers 
> using TLS 1.2 (unless it is enabled by default in 5.2)
> 
> Kind regards,
> Ivan

___
freebsd-mono@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-mono
To unsubscribe, send any mail to "freebsd-mono-unsubscr...@freebsd.org"

Re: Update on porting mono 5

[David Naylor]

On Friday, 25 August 2017 12:54:02 Russell Haley wrote:
> On Fri, Aug 25, 2017 at 12:41 PM, David Naylor  
wrote:
> > On Tuesday, 15 August 2017 12:21:20 Romain Tartière wrote:
> >> Hi David,
> >> 
> >> On Tue, Aug 15, 2017 at 09:11:57AM +0200, David Naylor wrote:
> >> > Here is an update on porting mono 5:
> >> >  - mono: 5.1.0.1 (needs to be updated to 5.2, tests run)
> >> >  - msbuild: 15.3 (needs tests ported and run, upstream bugs filed)
> >> >  - fsharp: 4.1.25 (WIP)
> >> >  - monodevelop: 7.0.1.24 (WIP)
> >> >  - gtksharp20: 2.12.45 (WIP)
> >> >  - avahi-sharp: 0.7 (not started)
> >> >  - bumping all dependent ports (not started)
> >> >  - exp-run (not started)
> >> > 
> >> > Would anyone be interested in doing a (Phabricator) review?
> >> 
> >> I don't actively use mono nowadays but sure, I can check if my old code
> >> tests suites still pass with the update.  I have just registered to
> >> Phabricator and have no previous experience with this tool, so get ready
> >> to teach me stuff ;-)
> > 
> > Great, thanks.
> > 
> > Here is a status update (with patch [1][3]).  Things aren't ready yet, but
> > as it
> > 
> > stands:
> >  - lang/mono: 5.2.0.215 (tests failing in mcs/class/corlib
> >  [run-test-local])
> >  - devel/msbuild: 15.3 (tests failing [with SIGABRT])
> >  - lang/sharp: 4.1.25 (tests failing in math/measures/test.fsx [Invalid IL
> > 
> > code])
> > 
> >  - x11-toolkits/gtk-sharp20: 2.12.45
> >  - x11-toolkits/gnome-sharp20: 2.24.4
> 
> Are the tests integrated into the build (I don't remember)? Does this
> mean it builds but the external tests fail or do the tests cause a
> build failure?

The tests are part of the 'make test' target.  The build succeeds but the mono 
test suite fails.  At least part of the acceptance tests (i.e. from dotnet) 
succeed.  

It would be great if someone(tm) can investigate the unit test failures and 
fix them, but this isn't a show topper, IMHO.  

The current state of the port:
 - mono builds and installs
 - mono is able to build msbuild, msbuild installs
 - mono+msbuild is able to build fsharp, fsharp installs
 - mono+msbuild+fsharp is able to build monodevelop, monodevelop still 
requires work to get building working reproducible  (i.e. getting `nuget 
restore` to work without internet during build phase).  


signature.asc
Description: This is a digitally signed message part.

Re: Update on porting mono 5

[Ivan Radovanovic]

On 26/08/2017 02:47, Alexander Regueiro wrote:

Thanks for the tip. In fact, it turns out I just needed to use the 
`—disable-dtrace` option when configuring, to get rid of that linkage error, 
oops!

Here’s the successful procedure that I followed to build & install Mono 5.2 on 
my FreeBSD 11 machine, in case it’s of interest to anyone while the port is being 
updated. I’m CCing the mailing list in case this is of use to someone.

(Make sure beforehand you have installed ports/packages for mono [to 
bootstrap], gcc, and gmake.)

The following can be run as a bash script and should do the whole job.

PREFIX=“$HOME/build/mono/“ &&
VERSION=“5.2.0.215” &&
FILENAME=“mono-$VERSION.tar.bz2” &&
curl -O "https://download.mono-project.com/sources/mono/$FILENAME 
” &&
tar -xvf “$FILENAME” &&
cd “mono-$VERSION” &&
./configure —prefix=“$PREFIX" --disable-nls --disable-dtrace --build="$(gcc 
-dumpmachine)” &&
sed -EI -e "s|#define HAVE_LOCALCHARSET_H.*|#undef HAVE_LOCALCHARSET_H|" eglib/config.h 
&&
mkdir -p “$PREFIX” &&
gmake &&
gmake install &&
echo “Mono $VERSION successfully built and installed to '$PREFIX'."

(This was inspired by the docs at 
http://www.mono-project.com/docs/compiling-mono/mac/ 
, but with some 
significant changes.)

Alex




I suggest enabling btls, otherwise it won't be able to connect to 
servers using TLS 1.2 (unless it is enabled by default in 5.2)


Kind regards,
Ivan
___
freebsd-mono@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-mono
To unsubscribe, send any mail to "freebsd-mono-unsubscr...@freebsd.org"

Re: Update on porting mono 5

[Alexander Regueiro]

Thanks for the tip. In fact, it turns out I just needed to use the 
`—disable-dtrace` option when configuring, to get rid of that linkage error, 
oops!

Here’s the successful procedure that I followed to build & install Mono 5.2 on 
my FreeBSD 11 machine, in case it’s of interest to anyone while the port is 
being updated. I’m CCing the mailing list in case this is of use to someone.

(Make sure beforehand you have installed ports/packages for mono [to 
bootstrap], gcc, and gmake.)

The following can be run as a bash script and should do the whole job.

PREFIX=“$HOME/build/mono/“ &&
VERSION=“5.2.0.215” &&
FILENAME=“mono-$VERSION.tar.bz2” &&
curl -O "https://download.mono-project.com/sources/mono/$FILENAME 
<https://download.mono-project.com/sources/mono/$FILENAME>” &&
tar -xvf “$FILENAME” &&
cd “mono-$VERSION” &&
./configure —prefix=“$PREFIX" --disable-nls --disable-dtrace --build="$(gcc 
-dumpmachine)” &&
sed -EI -e "s|#define HAVE_LOCALCHARSET_H.*|#undef HAVE_LOCALCHARSET_H|" 
eglib/config.h &&
mkdir -p “$PREFIX” &&
gmake &&
gmake install &&
echo “Mono $VERSION successfully built and installed to '$PREFIX'."

(This was inspired by the docs at 
http://www.mono-project.com/docs/compiling-mono/mac/ 
<http://www.mono-project.com/docs/compiling-mono/mac/>, but with some 
significant changes.)

Alex

> On 25 Aug 2017, at 21:00, Russell Haley  wrote:
> 
> Prefix everything with "Russell *thinks* this is how it works but it
> could be wrong because it's from memory".
> 
> collect2: error: ld returned 1 exit status
> 
> That's a linker error. Someone, somewhere is trying to link to a lib
> directory in the "wrong" place. In FreeBSD libraries and includes
> generally need to be prefixed with /usr/local/. Check in the makefile
> in /usr/home/aj/mono/mono/metadata. Often just adding (I'm going to
> get this wrong, I know it) -I /usr/local/include to CFLAGS and -L
> /usr/local/lib to LDFLAGS fixes those kinds of problems.
> 
> 
> Good luck!
> Russ
> 
> On Fri, Aug 25, 2017 at 8:59 AM, Alexander Regueiro  wrote:
>> This is easy enough to get around, but unfortunately I then get this bug,
>> which is rather more troublesome!
>> 
>> https://bugzilla.xamarin.com/show_bug.cgi?id=29962
>> 
>> Any ideas?
>> 
>> On 25 Aug 2017, at 07:01, Russell Haley  wrote:
>> 
>> On Thu, Aug 24, 2017 at 8:03 PM, Alexander Regueiro  wrote:
>> 
>> Hi Russ,
>> 
>> I wasn’t under the impression it was that straightforward, but will
>> certainly give it a go. Thanks.
>> 
>> 
>> I'm getting an undefined reference:
>> 
>> ../../mono/eglib/.libs/libeglib.a(libeglib_la-gunicode.o): In function
>> `monoeg_g_get_charset':
>> /usr/home/russellh/Git/mono/mono/eglib/gunicode.c:212: undefined
>> reference to `locale_charset'
>> collect2: error: ld returned 1 exit status
>> 
>> So I guess the answer is no, it's not. :)
>> 
>> Russ
>> 
>> Alex
>> 
>> On 24 Aug 2017, at 19:44, Russell Haley  wrote:
>> 
>> Sorry for the top post.
>> 
>> Have you tried building it yourself from their git repository? If memory
>> serves, most of the changes to get mono 4 to build revolved around calling
>> gmake instead of make and correcting paths for sh and bash.  ‎If I remember,
>> the bootstrapping of the build was only for monodevelop.
>> 
>> Russ
>> 
>> Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
>> Original Message
>> From: Alexander Regueiro
>> Sent: Thursday, August 24, 2017 11:24 AM
>> To: freebsd-mono@freebsd.org
>> Subject: Re: Update on porting mono 5
>> 
>> I’ve recently seen David Naylor’s message
>> <https://lists.freebsd.org/pipermail/freebsd-mono/2017-August/002524.html
>> <https://lists.freebsd.org/pipermail/freebsd-mono/2017-August/002524.html>>
>> summarising the work towards porting Mono 5, but it seems a lot of the WIP
>> is not public at the moment. Is there any way I can access this material?
>> Ideally I’d like to get Mono 5 building on my FreeBSD machine ASAP (even if
>> it’s just a hack), since I’m a bit deadline-constrained here, so if there’s
>> any way I can help, even leaving the testing aside for now, do please let me
>> know.
>> ___
>> freebsd-mono@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-mono
>> To unsubscribe, send any mail to "freebsd-mono-unsubscr...@freebsd.org"
>> 
>> 
>> 

___
freebsd-mono@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-mono
To unsubscribe, send any mail to "freebsd-mono-unsubscr...@freebsd.org"

Re: Update on porting mono 5

[Alexander Regueiro]

What about getting mono to actually build first?

Sent from my iPhone

> On 25 Aug 2017, at 20:41, David Naylor  wrote:
> 
>> On Tuesday, 15 August 2017 12:21:20 Romain Tartière wrote:
>> Hi David,
>> 
>>> On Tue, Aug 15, 2017 at 09:11:57AM +0200, David Naylor wrote:
>>> Here is an update on porting mono 5:
>>> - mono: 5.1.0.1 (needs to be updated to 5.2, tests run)
>>> - msbuild: 15.3 (needs tests ported and run, upstream bugs filed)
>>> - fsharp: 4.1.25 (WIP)
>>> - monodevelop: 7.0.1.24 (WIP)
>>> - gtksharp20: 2.12.45 (WIP)
>>> - avahi-sharp: 0.7 (not started)
>>> - bumping all dependent ports (not started)
>>> - exp-run (not started)
>>> 
>>> Would anyone be interested in doing a (Phabricator) review?
>> 
>> I don't actively use mono nowadays but sure, I can check if my old code
>> tests suites still pass with the update.  I have just registered to
>> Phabricator and have no previous experience with this tool, so get ready
>> to teach me stuff ;-)
> 
> Great, thanks.  
> 
> Here is a status update (with patch [1][3]).  Things aren't ready yet, but as 
> it 
> stands:
> - lang/mono: 5.2.0.215 (tests failing in mcs/class/corlib [run-test-local])
> - devel/msbuild: 15.3 (tests failing [with SIGABRT])
> - lang/sharp: 4.1.25 (tests failing in math/measures/test.fsx [Invalid IL 
> code])
> - x11-toolkits/gtk-sharp20: 2.12.45
> - x11-toolkits/gnome-sharp20: 2.24.4
> WIP:
> - devel/monodevelop: 7.1.0.1297 (full nuget package restore required [extra 
> nuget support required])
> - devel/mono-addins: depreciate [2] (broken with mono5), fix dependencies
> TODO:
> - mono: test self hosting
> - update mono-lite version
> - avahi-sharp: 0.7
> - bump all dependent ports
> - exp-run
> - commit to ports
> - upstream patches
> - fix tests
> 
> Note that the failing tests don't worry me too much.  Most of them are edge 
> cases that won't affect the average user (i.e. not a blocker to commit to 
> ports) - also I don't know how many tests are failing on other platforms (if 
> any).  
> 
> [1] git clone https://github.com/DragonSA/ports; cd ports; git diff 
> master..origin/mono5.2.0.215
> [2] A general discussion needs to be had around nuget packages.  How do we 
> consume them?
>  i) as downloads with each port containing a copy
> ii) local ports with consistency across the Ports Collections
> iii) A mixture of the above (i.e. (ii) is there is a native component, 
> otherwise (i))
> I prefer (ii) as I think it gives the end user the best leverage to patch 
> issues with nuget packages locally (and to get updates without waiting on a) 
> upstream, and b) us/ports maintainer).  However, at this point that option is 
> at 0% progress.  
> [3] https://people.freebsd.org/~dbn/mono-20170825.diff.xz
___
freebsd-mono@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-mono
To unsubscribe, send any mail to "freebsd-mono-unsubscr...@freebsd.org"

Re: Update on porting mono 5

[David Naylor]

On Tuesday, 15 August 2017 12:21:20 Romain Tartière wrote:
> Hi David,
> 
> On Tue, Aug 15, 2017 at 09:11:57AM +0200, David Naylor wrote:
> > Here is an update on porting mono 5:
> >  - mono: 5.1.0.1 (needs to be updated to 5.2, tests run)
> >  - msbuild: 15.3 (needs tests ported and run, upstream bugs filed)
> >  - fsharp: 4.1.25 (WIP)
> >  - monodevelop: 7.0.1.24 (WIP)
> >  - gtksharp20: 2.12.45 (WIP)
> >  - avahi-sharp: 0.7 (not started)
> >  - bumping all dependent ports (not started)
> >  - exp-run (not started)
> > 
> > Would anyone be interested in doing a (Phabricator) review?
> 
> I don't actively use mono nowadays but sure, I can check if my old code
> tests suites still pass with the update.  I have just registered to
> Phabricator and have no previous experience with this tool, so get ready
> to teach me stuff ;-)

Great, thanks.  

Here is a status update (with patch [1][3]).  Things aren't ready yet, but as 
it 
stands:
 - lang/mono: 5.2.0.215 (tests failing in mcs/class/corlib [run-test-local])
 - devel/msbuild: 15.3 (tests failing [with SIGABRT])
 - lang/sharp: 4.1.25 (tests failing in math/measures/test.fsx [Invalid IL 
code])
 - x11-toolkits/gtk-sharp20: 2.12.45
 - x11-toolkits/gnome-sharp20: 2.24.4
WIP:
 - devel/monodevelop: 7.1.0.1297 (full nuget package restore required [extra 
nuget support required])
 - devel/mono-addins: depreciate [2] (broken with mono5), fix dependencies
TODO:
 - mono: test self hosting
 - update mono-lite version
 - avahi-sharp: 0.7
 - bump all dependent ports
 - exp-run
 - commit to ports
 - upstream patches
 - fix tests

Note that the failing tests don't worry me too much.  Most of them are edge 
cases that won't affect the average user (i.e. not a blocker to commit to 
ports) - also I don't know how many tests are failing on other platforms (if 
any).  

[1] git clone https://github.com/DragonSA/ports; cd ports; git diff 
master..origin/mono5.2.0.215
[2] A general discussion needs to be had around nuget packages.  How do we 
consume them?
  i) as downloads with each port containing a copy
 ii) local ports with consistency across the Ports Collections
iii) A mixture of the above (i.e. (ii) is there is a native component, 
otherwise (i))
I prefer (ii) as I think it gives the end user the best leverage to patch 
issues with nuget packages locally (and to get updates without waiting on a) 
upstream, and b) us/ports maintainer).  However, at this point that option is 
at 0% progress.  
[3] https://people.freebsd.org/~dbn/mono-20170825.diff.xz

signature.asc
Description: This is a digitally signed message part.

Re: Update on porting mono 5

[Alexander Regueiro]

I’ve recently seen David Naylor’s message 
> 
summarising the work towards porting Mono 5, but it seems a lot of the WIP is 
not public at the moment. Is there any way I can access this material? Ideally 
I’d like to get Mono 5 building on my FreeBSD machine ASAP (even if it’s just a 
hack), since I’m a bit deadline-constrained here, so if there’s any way I can 
help, even leaving the testing aside for now, do please let me know.
___
freebsd-mono@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-mono
To unsubscribe, send any mail to "freebsd-mono-unsubscr...@freebsd.org"

Re: Update on porting mono 5

[Romain Tartière]

Hi David,

On Tue, Aug 15, 2017 at 09:11:57AM +0200, David Naylor wrote:
> Here is an update on porting mono 5:
>  - mono: 5.1.0.1 (needs to be updated to 5.2, tests run)
>  - msbuild: 15.3 (needs tests ported and run, upstream bugs filed)
>  - fsharp: 4.1.25 (WIP)
>  - monodevelop: 7.0.1.24 (WIP)
>  - gtksharp20: 2.12.45 (WIP)
>  - avahi-sharp: 0.7 (not started)
>  - bumping all dependent ports (not started)
>  - exp-run (not started)
> 
> Would anyone be interested in doing a (Phabricator) review?

I don't actively use mono nowadays but sure, I can check if my old code
tests suites still pass with the update.  I have just registered to
Phabricator and have no previous experience with this tool, so get ready
to teach me stuff ;-)

Romain

-- 
Romain Tartière   http://people.FreeBSD.org/~romain/
pgp: 8234 9A78 E7C0 B807 0B59  80FF BA4D 1D95 5112 336F (ID: 0x5112336F)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)


signature.asc
Description: PGP signature

Update on porting mono 5

[David Naylor]

Hi

Here is an update on porting mono 5:
 - mono: 5.1.0.1 (needs to be updated to 5.2, tests run)
 - msbuild: 15.3 (needs tests ported and run, upstream bugs filed)
 - fsharp: 4.1.25 (WIP)
 - monodevelop: 7.0.1.24 (WIP)
 - gtksharp20: 2.12.45 (WIP)
 - avahi-sharp: 0.7 (not started)
 - bumping all dependent ports (not started)
 - exp-run (not started)

Would anyone be interested in doing a (Phabricator) review?

Regards

signature.asc
Description: This is a digitally signed message part.