Re: Help Wanted - Work with MSFT and help finish the port of .NET Core to FreeBSD

2017-09-27 Thread Russell Haley
+1
I threw some comments on the open issues.

On Wed, Sep 27, 2017 at 6:36 PM, Geoffrey Huntley  wrote:
> Tomas and Karel from MSFT have some updates for us, in short, the full-scale
> battle can start and volunteers are needed.
>
> - FreeBSD: implement System.Diagnostic.Process:
> https://github.com/dotnet/corefx/issues/24292
> - FreeBSD: System.Console is not working right:
> https://github.com/dotnet/corefx/issues/24259
>
>> I was finally able to run corefx tests on FreeBSD 11.0 (without outerloop
>> tests)
>> Total passed: 144208
>> Total failed: 2622
>> Total skipped 207
>>
>> I will update dotnet/corefx/wiki/Building-.NET-Core--2.x-on-FreeBSD with
>> instructions.
>>  I will file specific issues and tag them with with os-freebsd and
>> up-for-grab.
>>
>
> From https://github.com/dotnet/corefx/issues/1626#issuecomment-332668619
>
>
>
> On 8 September 2017 at 10:51, Russell Haley  wrote:
>>
>> Hi I just dropped a twitter to Karel (suddenly feel less smart) and
>> this was his response:
>>
>> "Yep, I was poking at a plan internally first. Got some hinys and will
>> reply tomorrow. Tomas even made some progress ."
>>
>> Sweet!
>>
>> Russ
>>
>> On Tue, Sep 5, 2017 at 12:24 PM, Russell Haley 
>> wrote:
>> > On Tue, Sep 5, 2017 at 11:52 AM, David Naylor 
>> > wrote:
>> >> On Monday, 4 September 2017 10:54:21 Geoffrey Huntley wrote:
>> >>> See https://www.youtube.com/watch?v=NHllisWOCpU and
>> >>> https://twitter.com/GeoffreyHuntley/status/904227946084294656
>> >>
>> >> Hi Geoffrey
>> >>
>> >> It is great to hear there is more interest in finishing the port of
>> >> .NET Core
>> >> to FreeBSD (and, I hope, to have ports living in the Port's
>> >> Collection).
>> >>
>> >> Would it be possible for you to put me (and the mono@ mailing list) in
>> >> touch
>> >> with Karel and Tomas - I'm not on Twitter.
>> >>
>> >> I'll reply to this email (dropping ports@ and advocacy@) with more
>> >> technical
>> >> details.
>> >>
>> >> Regards
>> >>
>> >> David
>> >
>> > Just an FYI: I found Karel's email address and dropped him a private
>> > message for more information (I also don't use twitter). I wanted to
>> > wait for permission before publishing any information on the mono
>> > mailing list (including his email address etc).
>> >
>> > I had the DotNet CORE and CLR running on FreeBSD using the
>> > instructions posted way back when. I also asked about more information
>> > a few months back on the DotNet forums but I can't find the message.
>> > The response was that "nothing was happening at the time".
>> > http://forums.dotnetfoundation.org/
>> >
>> >
>> > Cheers,
>> >
>> > 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: Help Wanted - Work with MSFT and help finish the port of .NET Core to FreeBSD

2017-09-27 Thread Geoffrey Huntley
Tomas and Karel from MSFT have some updates for us, in short, the
full-scale battle can start and volunteers are needed.

- FreeBSD: implement System.Diagnostic.Process:
https://github.com/dotnet/corefx/issues/24292
- FreeBSD: System.Console is not working right:
https://github.com/dotnet/corefx/issues/24259

> I was finally able to run corefx tests on FreeBSD 11.0 (without outerloop
tests)
> Total passed: 144208
> Total failed: 2622
> Total skipped 207
>
> I will update dotnet/corefx/wiki/Building-.NET-Core--2.x-on-FreeBSD with
instructions.
>  I will file specific issues and tag them with with os-freebsd and
up-for-grab.
>

>From https://github.com/dotnet/corefx/issues/1626#issuecomment-332668619



On 8 September 2017 at 10:51, Russell Haley  wrote:

> Hi I just dropped a twitter to Karel (suddenly feel less smart) and
> this was his response:
>
> "Yep, I was poking at a plan internally first. Got some hinys and will
> reply tomorrow. Tomas even made some progress ."
>
> Sweet!
>
> Russ
>
> On Tue, Sep 5, 2017 at 12:24 PM, Russell Haley 
> wrote:
> > On Tue, Sep 5, 2017 at 11:52 AM, David Naylor 
> wrote:
> >> On Monday, 4 September 2017 10:54:21 Geoffrey Huntley wrote:
> >>> See https://www.youtube.com/watch?v=NHllisWOCpU and
> >>> https://twitter.com/GeoffreyHuntley/status/904227946084294656
> >>
> >> Hi Geoffrey
> >>
> >> It is great to hear there is more interest in finishing the port of
> .NET Core
> >> to FreeBSD (and, I hope, to have ports living in the Port's Collection).
> >>
> >> Would it be possible for you to put me (and the mono@ mailing list) in
> touch
> >> with Karel and Tomas - I'm not on Twitter.
> >>
> >> I'll reply to this email (dropping ports@ and advocacy@) with more
> technical
> >> details.
> >>
> >> Regards
> >>
> >> David
> >
> > Just an FYI: I found Karel's email address and dropped him a private
> > message for more information (I also don't use twitter). I wanted to
> > wait for permission before publishing any information on the mono
> > mailing list (including his email address etc).
> >
> > I had the DotNet CORE and CLR running on FreeBSD using the
> > instructions posted way back when. I also asked about more information
> > a few months back on the DotNet forums but I can't find the message.
> > The response was that "nothing was happening at the time".
> > http://forums.dotnetfoundation.org/
> >
> >
> > Cheers,
> >
> > 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: DotNet Core 2.0 - Status Update

2017-09-27 Thread Tomas Weinfurt via freebsd-mono
Yes, your assessment seems right David. 
This is similar to building compiler. You need something to compile it with. 
C# compiler Roslyn is written in c#. 
To break the loop, you have set of reference bits – previous version, mono or 
something else. 
We will still probably need precompiled assemblies in order to run Roslyn and 
other tools.

I’ve been trying to hack up “previous” version for FreeBSD so at least people 
can build and start working on fixes.
Fact that code builds does not mean it is ready. I can build and run “hello 
world” but running msbuild kills runtime.
Many tests are failing in corefx. (don’t know about coreclr and other repos 
yet) 
I think there is long way before we can call it ready for preview. 

The build from beginning is not specific to FreeBSD.
To add to the list: - Build the managed parts on FreeBSD with Linux/OSX/Windows 
version (theoretical only)
There may be more than one answer. It may be handy if previous version exists – 
for people who want to just hack on single repo and fix a bug. 
Building everything from scratch can be complicated and tedious. But I think 
the path should exist and be scriptable. 

Tomas

On 9/27/17, 12:15 PM, "David Naylor"  wrote:

On Sunday, 24 September 2017 23:36:32 Russell Haley wrote:
> Hey,
> 
> *This is my understanding of what's going on and I am looking for
> Tomas or Karel to correct or clarify.
> 
> I've continued poking around on the build to little effect so far.
> Tomas has said there is an update to the official repository coming
> soon that runs for the most part on his 11-release instance. (I'm sure
> he will elaborate at some point).
> 
> Progress for Users:
> The ability to produce binaries that will allow people to compile and
> run applications is still a little ways out but there is a "first
> candidate" coming for the curious.
> 
> For "the curious":
> There are multiple repositories for DotNet Core but two main "halves"
> to any runtime: the native parts and the managed code parts. Right
> now, the native pieces build for Tomas. The managed code parts however
> require there to be an existing copy of the .Net Framework to build
> dotnet core 2.0. Because that doesn't exist on FreeBSD (and never
> will), there are currently three solutions:
> 
> - Build the managed parts on Windows
> - Build the managed parts on Linux
> - Build the managed parts on FreeBSD with mono (theoretical only)
> 
> >From what I understand, this bootstrap conundrum will always exist for
> 
> FreeBSD (except using a prior port to bootstrap the next one?). What I
> think needs to happen is we need to create a first version of the port
> that imports the managed code from a Windows or Linux repository. This
> would become a boot strap port that could be replaced once the DotNet
> Core team at Microsoft figure out a more permanent solution. Or not,
> and we always have a bootstrap package.  :P
> 
> The alternative is to work towards getting the managed parts to build
> in Mono and making mono a prerequisite to build. This would be a
> FreeBSD only solution, but could get some traction from the Mono team
> (now at Microsoft) and would be good for the FreeBSD mono port.

We could do what Mono does to bootstrap the managed code (i.e. monolite):
 1) Have a machine running a prior version of dotnet (say 2.0)
 2) Use existing dotnet (2.0) to compile managed code for new dotnet (say 
2.1)
 3) Tarball the managed code and make available through FreeBSD's public 
distfiles infrastructure
 4) Update port's version of dotnet native code to new version (2.1)
 5) Use the tarball in step (3) to compile managed code in ports for new 
version (2.1)
This is mostly the same as your first suggestion, except we compile the 
managed code from a prior version for dotnet instead of using a different 
OS.  

I would, personally, prefer directly compiling the managed code with mono 
as a 
backup (say, if someone wants to bootstrap the process themselves).  

___
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: DotNet Core 2.0 - Status Update

2017-09-27 Thread David Naylor
On Sunday, 24 September 2017 23:36:32 Russell Haley wrote:
> Hey,
> 
> *This is my understanding of what's going on and I am looking for
> Tomas or Karel to correct or clarify.
> 
> I've continued poking around on the build to little effect so far.
> Tomas has said there is an update to the official repository coming
> soon that runs for the most part on his 11-release instance. (I'm sure
> he will elaborate at some point).
> 
> Progress for Users:
> The ability to produce binaries that will allow people to compile and
> run applications is still a little ways out but there is a "first
> candidate" coming for the curious.
> 
> For "the curious":
> There are multiple repositories for DotNet Core but two main "halves"
> to any runtime: the native parts and the managed code parts. Right
> now, the native pieces build for Tomas. The managed code parts however
> require there to be an existing copy of the .Net Framework to build
> dotnet core 2.0. Because that doesn't exist on FreeBSD (and never
> will), there are currently three solutions:
> 
> - Build the managed parts on Windows
> - Build the managed parts on Linux
> - Build the managed parts on FreeBSD with mono (theoretical only)
> 
> >From what I understand, this bootstrap conundrum will always exist for
> 
> FreeBSD (except using a prior port to bootstrap the next one?). What I
> think needs to happen is we need to create a first version of the port
> that imports the managed code from a Windows or Linux repository. This
> would become a boot strap port that could be replaced once the DotNet
> Core team at Microsoft figure out a more permanent solution. Or not,
> and we always have a bootstrap package.  :P
> 
> The alternative is to work towards getting the managed parts to build
> in Mono and making mono a prerequisite to build. This would be a
> FreeBSD only solution, but could get some traction from the Mono team
> (now at Microsoft) and would be good for the FreeBSD mono port.

We could do what Mono does to bootstrap the managed code (i.e. monolite):
 1) Have a machine running a prior version of dotnet (say 2.0)
 2) Use existing dotnet (2.0) to compile managed code for new dotnet (say 2.1)
 3) Tarball the managed code and make available through FreeBSD's public 
distfiles infrastructure
 4) Update port's version of dotnet native code to new version (2.1)
 5) Use the tarball in step (3) to compile managed code in ports for new 
version (2.1)
This is mostly the same as your first suggestion, except we compile the 
managed code from a prior version for dotnet instead of using a different OS.  

I would, personally, prefer directly compiling the managed code with mono as a 
backup (say, if someone wants to bootstrap the process themselves).  

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


Re: Update on porting mono 5

2017-09-27 Thread 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.