Re: CFT: lang/mono 5.10.2

[Russell Haley]

On Wed, Jun 13, 2018 at 12:05 PM, Mark Felder  wrote:

> Hi all,
>
> It's time to get us on a modern stable mono version. I've had nothing but
> issues with mono 5.2 and it seems I'm not alone. I have a port update ready
> for testing here:
>

Hi Mark,

David Naylor was putting together patches to incrementally get us up to a
better version of Mono and I was helping to test his patches. I've moved
away from .Net (professionally and personally) and dropped the ball. Davids
work can be found here for reference:
https://reviews.freebsd.org/D12440

I wish I could promise to look at this but I'm just too far away from mono
to be much help (other than a really terse build test).

Russ

>
> https://reviews.freebsd.org/D15780
>
> Initially I intended to bring us to the very latest release, mono 5.12,
> but that seems to have compatibility issues. I run some ports that just
> don't work with it, so per suggestion I am tracking the  "really stable"
> release which is what Mono ships with MS Visual Studio on Linux.
>
> Please let me know if you have any feedback. I'm hoping to get this
> committed before the 2018Q3 tree gets cut.
>
> --
>   Mark Felder
>   ports-secteam & portmgr member
>   f...@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"
>
___
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: [GSoC'18] Porting Microsoft's CoreCLR, CoreFX, and PowerShell to FreeBSD

[Russell Haley]

On Wed, Apr 25, 2018 at 7:21 AM, Russell Haley <russ.ha...@gmail.com> wrote:

> Hi!
>
> Sorry for the top post. I'm really glad to see someone pick this up as I
> have dropped the ball. I'll try to send you some information later. ‎Here
> is a description of the current status of where the porting is at:
> https://github.com/dotnet/corefx/issues/1626#issuecomment-378627311
>
> I am helping another person with his SGOC on RTEMS so I will not be able
> to give my full attention to you  but will help where I can. It will be
> important to push the Linux ports of dotnetcore 1 forward for your success.
>
Hello Mateus,

So I'm not sure how much you know yet about the state of DotNet Core on
FreeBSD. In order to build dotnet you need to create two "parts" of the
each of the two Libraries CoreFX and CoreCLR. The first part is the native
components that interact with the operating system, and the second half are
the "managed" dotnet parts that interact with the native components (as
well as the rest of the framework).   The problem with FreeBSD is support
was never kept up in the original port of DotNet Core 1. The managed
components for DotNet Core 2 can only be built using a compiler written in
one of the three DotNet variants (.Net framework, DotNet Core 1 or DotNet
Core 2). There was at one point support for building DotNet in Mono, but
Microsoft isn't divulging any of that information and is not interested in
following that path.

SO, a Microsoft Developer named Tomas Wienfrut took the project on and was
able to get DotNet Core 2 building for FreeBSD.Tomas, was able to
cross-build both portions on Linux.  I have been able to build the Native
parts on FreeBSD without issue. I was almost successful building the
Managed components Windows (for FreeBSD) but ran out of steam and I haven't
used .Net for about a year now so my focus is learning new things. The
problem with the above build methods is they are slow and messy and
required copying things back to FreeBSD from another OS. It wasn't very
manageable.

In comes David Naylor - who is pretty much single handedley propping up
Mono on FreeBSD - with a binary Linux port of Dot Net Core 1 and all the
build components that we need for DotNet Core 2!

The important parts that you will need are still only patches. Someone
needs to build and verify his patches so he can commit them. He has created
a tracking ticket in the phabricator review tool here:
https://reviews.freebsd.org/D12440

The important patches for you are here:
 https://reviews.freebsd.org/D14135 - msbuild

 https://reviews.freebsd.org/D13870 - linux binary dotnet core 1

I have patched a ports tree and run the linux dotnet core 1 binary, but
have not completed the process of verifying it works. I just gave it
another shot and there is still a missing package (I commented on the
D13870 ticket).

SO, should you choose to move forward with porting DotNet Core 2, you have
two choices: 1) continue Davids work to get the Linux DotNet binaries
working, or 2) investigate building with Mono - which is a path untaken so
far.

If you wish to continue with the Linux binaries, someone should probably
test the patches that David has provided so we can get the pre-requisites
in the ports tree. After that, the following build instructions should
still be relevant minus any -skipcrossgen flags:

https://github.com/dotnet/corefx/wiki/Building-.NET-Core--2.x-on-FreeBSD

And that should be it right? ha ha. No. You have a long road of testing
ahead of you.

I am thrilled to see this work move forward. If I can provide any further
assistance, please let me know. I can't wait to see PowerShell running on
FreeBSD! Although I am rather fond of fish on GhostBSD now.

Cheers!
Russ



> I will write back soon with more details but didn't want your last message
> to go unanswered.
>
> Cheers
> Russ
>
> Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
>   Original Message
> From: Mateus Rodrigues de Morais
> Sent: Tuesday, April 24, 2018 4:20 PM
> To: m...@freebsd.org
> Subject: [GSoC'18] Porting Microsoft's CoreCLR, CoreFX, and PowerShell to
> FreeBSD
>
> Hello all,
>
> My name is Mateus and I’m an undergraduate at the Federal University of
> Rio Grande do Norte, in Natal, Brazil, studying Computer Engineering. I’m
> currently participating in the 2018 Google Summer of Code and my project is
> to port the CoreCLR, CoreFX and, ultimately, PowerShell, to the FreeBSD
> platform.
>
> I’m expecting to interact quite a bit with you guys here on this list so,
> just introducing myself. Also, I’m happy to receive suggestions from you
> all, if you have any.
>
> Best regards,
>
> Mateus Rodrigues de Morais.
> ___
> freebsd-mono@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-mono
> To unsu

Re: [GSoC'18] Porting Microsoft's CoreCLR, CoreFX, and PowerShell to FreeBSD

[Russell Haley]

Hi!

Sorry for the top post. I'm really glad to see someone pick this up as I have 
dropped the ball. I'll try to send you some information later. ‎Here is a 
description of the current status of where the porting is at: 
https://github.com/dotnet/corefx/issues/1626#issuecomment-378627311

I am helping another person with his SGOC on RTEMS so I will not be able to 
give my full attention to you  but will help where I can. It will be important 
to push the Linux ports of dotnetcore 1 forward for your success. 

I will write back soon with more details but didn't want your last message to 
go unanswered. 

Cheers
Russ

Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
  Original Message  
From: Mateus Rodrigues de Morais
Sent: Tuesday, April 24, 2018 4:20 PM
To: m...@freebsd.org
Subject: [GSoC'18] Porting Microsoft's CoreCLR, CoreFX, and PowerShell to 
FreeBSD

Hello all,

My name is Mateus and I’m an undergraduate at the Federal University of Rio 
Grande do Norte, in Natal, Brazil, studying Computer Engineering. I’m currently 
participating in the 2018 Google Summer of Code and my project is to port the 
CoreCLR, CoreFX and, ultimately, PowerShell, to the FreeBSD platform.

I’m expecting to interact quite a bit with you guys here on this list so, just 
introducing myself. Also, I’m happy to receive suggestions from you all, if you 
have any.

Best regards,

Mateus Rodrigues de Morais.
___
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: Boring TLS support for Mono - pull request

[Russell Haley]

Sorry for the top post,

Hi Allessandro,

FreeBSD doesn't really support git pull requests. We use SVN and a
review board, as well as bugzilla for reporting issues.

David Naylor is the one that is patching Mono. I was helping validate
the builds but I don't have much time right now as I'm changing jobs.
Have you used the FreeBSD Phabricator website before? it's found here:

https://reviews.freebsd.org

Davids issue tracker is here:
https://reviews.freebsd.org/D12440

I know someone else has mentioned interest is patching but I don't
know if it went anywhere.

The reason I mention Davids issue tracker is that's the best way to
get your work reviewed and into the FreeBSD tree. However, using
Davids Diffs requires knowing about "porting", which is a handbook
unto itself here:

https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/

A possible alternative is to speak to David and fork Davids work on
Github. Then you could create a pull request to one of his work in
progress Mono branches?

https://github.com/DragonSA/ports

Sorry I can't be more help right now.

Cheers,

Russ

On Mon, Feb 26, 2018 at 4:24 AM, Alessandro Viganò  wrote:
> Hi,
> sorry for double posting, I was not aware this was a mailing list.
>
> I made some patches to compile Boring TLS.
>
> https://github.com/alvistar/freebsd-ports
>
> How can I create a pull request?
>
> Thanks,
>
>
> Alessandro
> ___
> 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"

Assisting the Mono and DotNet Porting Process

[Russell Haley]

Hi Guys,

So I've managed to talk myself into a job at a medical devices firm
and I signed a new contract on Wednesday. The first project I'm on is
based on qt 5 which is problematic because I know very little about
qt! As you can imagine, I'm going to need to ramp up "starting
yesterday" so I'm not going to have time for mono or dotnet core for a
little while. Unfortunately, I'm not sure what a little while means.

I'd really encourage some of you that are using mono and not active in
the porting process to consider helping David Naylor. Without people
to pull in the patches and test them, it means more overhead for him
because he needs to request many exp-runs to clean up errors. The
amount of effort to actually apply the patches and build the software
is not that onerous and the learning experience really highlights how
Runtimes and VMs work.

At this point, FreeBSD is inches away from being able to build DotNet
Core 2 entirely on FreeBSD. The push to get things working is
measurable in weeks of effort by my estimation. Tomas from Microsoft
has things building and ready for testing, while David Naylor is only
missing a few more components to support DotNet Core 1 via Linux
emulation. *It's soo close*.

Anyway, I'd be happy to provide a little guidance as to what I was
doing to assist David if anyone is interested. I'm sad about putting
in so much effort over the last few months and having to walk away
before the job is complete. I'd love to see Mono and DotNet "pushed
over the line" and will be back to help when time permits.

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: lang/mono TLS 1.2

[Russell Haley]

Hi Egil,

Would you care to submit the patch via reviews.freebsd.org? Please add
David Naylor (dbn) and myself (Search for Russell Haley) as reviewers.
I am assisting David with his Mono 5.4 patches and could look at your
fixes and attempt a build with them.

In my opinion, any discussion about appropriateness of including it
should be had within the review as others outside the mono community
can also comment.

Please feel free to subscribe to the freebsd mono mailing list. I
believe the correct list is freebsd-mono@freebsd.org, not
m...@freebsd.org, but Marks message was delivered so I could be in
error. (Perhaps Mark could elucidate?)

Please see here for more details on subscribing to FreeBSD lists:
https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/eresources-mail.html


Cheers,
Russ

On Fri, Feb 2, 2018 at 8:46 AM, Mark Felder <f...@freebsd.org> wrote:
>
>
> On Fri, Feb 2, 2018, at 08:22, Egil Hasting wrote:
>> Hello,
>>
>> Who are in charge of the lang/mono package? i would like to submit a patch
>> which build in btls as default (if there isnt any good reason to avoid it).
>>
>> rgs
>> Egil Hasting
>
> There is a mono@ team. I'm not up to speed on their work with the mono port, 
> but I will CC them on this email.
>
>
> --
>   Mark Felder
>   ports-secteam & portmgr member
>   f...@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"
___
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: Mono 5.2 patch and DotNet Core 2 update

[Russell Haley]

On Thu, Jan 11, 2018 at 10:45 AM, David Naylor <naylor.b.da...@gmail.com> wrote:
> On Wednesday, 10 January 2018 08:55:45 Russell Haley wrote:
>> Hi David,
>>
>> I've successfully built mono based on a modified version of your patch
>> from here: https://reviews.freebsd.org/D13752
>>
>> I'm getting size and checksum errors for the file
>> dotnet-roslyn-322bd5b_GH0.tar.gz. This shouldn't be an issue: I
>> changed the size of the file in distinfo from 22058493 to the actual
>> size I received of 22058637 in order to make it build. My expectation
>> is that I should then run make checksum to fix the distinfo file
>> correctly. I run sudo make checksum and the target goes into an
>> infinite loop downloading the file, deciding it doesn't match the
>> checksum and then downloading it again. WTH?
>>
>> I am unsure how to proceed. The porters handbook is quite explicit
>> that this is the way forward:
>> https://www.freebsd.org/doc/en/books/porters-handbook/porting-checksum.html
>>
>> I have attached what I think is the svn diff that include both your
>> patch and my update. The distinfo file should still be incorrect. I
>> haven't tested it. I have to get to work . :P
>>
>> I have cc'd the ports list as well in this conversation. Any input
>> from all parties would be grand.
>
> Thank you for the review - I see you commented on the review.  I'll try and
> finish the port over the weekend.
>
> FYI, I have uploaded another two reviews.  These combined get the CentOS
> version of .NET Core running on FreeBSD :-).
>
> Regards

Once I get a nice pattern set up for checking these things it should
go much more smoothly.

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: Mono 5.2 patch and DotNet Core 2 update

[Russell Haley]

On Wed, Jan 10, 2018 at 10:50 AM, Steven Hartland
<kill...@multiplay.co.uk> wrote:
> You want make makesum not make checksum to rebuild the distinfo file

Ugh. So...embarassing. The worst part is I did the same thing in
reverse when I was checking the targets for Lua53 the other day and
spent the better part of an hour not understanding the problem.  I
quandary why the target isn't called distinfo?

Thanks Steven!
Russ


> On Wed, 10 Jan 2018 at 19:43, Romain Tartière <rom...@freebsd.org> wrote:
>>
>> On Wed, Jan 10, 2018 at 08:55:45AM -0800, Russell Haley wrote:
>> > I'm getting size and checksum errors for the file
>> > dotnet-roslyn-322bd5b_GH0.tar.gz. This shouldn't be an issue: I
>> > changed the size of the file in distinfo from 22058493 to the actual
>> > size I received of 22058637 in order to make it build. My expectation
>> > is that I should then run make checksum to fix the distinfo file
>> > correctly. I run sudo make checksum and the target goes into an
>> > infinite loop downloading the file, deciding it doesn't match the
>> > checksum and then downloading it again. WTH?
>>
>> Since there are checksums, the ports systems must be checking them when
>> downloading…  and since the checksum does not match, the download is
>> assumed to have failed…  I guess you can solve this chicken-and-egg
>> problem, vy simply removing the existing distinfo file.
>>
>> The actual files checksums will then be written to distinfo. You can
>> `svn diff` to confirm only the expected files have been touched ;-)
>>
>> Regards,
>> Romain
>>
>> --
>> Romain Tartière <rom...@freebsd.org>  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: Mono 5.2 patch and DotNet Core 2 update

[Russell Haley]

On Wed, Jan 3, 2018 at 11:41 AM, David Naylor <naylor.b.da...@gmail.com> wrote:
> On Tuesday, 2 January 2018 22:17:19 Aaron Havens wrote:
>> On Sun, Dec 31, 2017 at 12:31 AM, Russell Haley <russ.ha...@gmail.com>
>> wrote:
>> > On Thu, Dec 28, 2017 at 9:50 PM, Russell Haley <russ.ha...@gmail.com>
>> > wrote:
>> > > Hey Guys,
>> > >
>> > > Merry Christmas! Hope this finds you all well. While free time for me
>> > > has been at a premium, I have managed to finally get my hands on a
>> > > laptop and cram 16 Gb of ram and a nice big SSD in it. That means I
>> > > now have room for lots of VMs. I have a GhostBSD image (FreeBSD 11.1)
>> > > and will bring up a TrueOS which is a revision oThe answers to questions 
>> > > about using Lua are intrinsically answered in the way the book is 
>> > > written.f CURRENT. Yay for
>> > > Virtual Box!
>
> And happy new year :-)
>
>> > > Mono 5.2
>> > >
>> > > I've created a svn ports repo to mess with and tried out the Mono 5.2
>> > > patch from David. While I ultimately succeeded,  the D12440.diff patch
>> > > had one error. The chunk was in a RUN_DEPENDS (inconsiquential to the
>> > > build) but I patched it manually and ran it. I then found blank patch
>> > > files for patch-mono_metadata_socket-io.c,
>> > > patch-mono_utils_mono-compiler.h and patch-mono_utils_w32handle.c
>> > > (there may have been more, I wasn't careful enough when I was deleting
>> > > them).
>
> Please check the updated patch in (https://reviews.freebsd.org/D13751), I
> might need to refresh it for changes in the ports tree.
>
>> > > After some difficulty with the tarball downloads tThe answers to 
>> > > questions about using Lua are intrinsically answered in the way the book 
>> > > is written.iming out, the build
>> > > completed successfully! I'll be checking MonoDevelop as well shortly.
>> > > I'm hoping David can chime in and we can finish this off?
>
> Other than things I have overlooked I think we have a ship-able patch.  There
> are some more things to do, but I don't think show stoppers.
It needs to be verifiable, that's all I really meant.

>> > So I've had some more time to play with this and the shear breadth of
>> > Davids work is staggering. I've suggested in the review that it be
>> > broken up into pieces so that it can be digested. Some of this work is
>> > important to the DotNet core work; David has a port for msbuild and
>> > Rosyln that are really exciting.
>> >
>> > If David is able to chop the reviews up, is there anyone available to help
>> > test?
>
> I've split the review into 5 sections, 2 with reviews ready:
>
> - https://reviews.freebsd.org/D13751: ancillary ports
> - https://reviews.freebsd.org/D13752: mono (and USES=mono)
> - msbuild (depends on mono)
> - fsharp (depends on msbuild)
> - monodevelop (depends on msbuild)
>
> I suggest you focus on mono, I'll bang out the ancillary ports (hopefully
> tomorrow).
Great work. Thanks and I'm on it.

>> > Russ
>>
>> I am willing to help test. Just may need some guidance on where to start
>> and what is needed.
>
> I suggest you try build mono (https://reviews.freebsd.org/D13752).  You can
> test by:
>  - running the unit tests (i.e. `make test`)
>  - run your favourite mono apps
>  - try some random mono apps in the ports collection
>
>> > > DotNet Core 2
>> > >
>> > > Tomas from MS has been building out the Core Framework (corefx) and
>> > > has an "Frankensteins Monster" SDK ready for testing. I have been
>> > > working on getting the Common Language Runtime (coreclr) test suite to
>> > > build to validate the system. The working instructions are being
>> > > generated as we go. I've been building the managed parts on Windows,
>> > > while Tomas has been using GNU/Linux for a build platform. I'm hoping
>> > > my work will start to coalesce with Tomas' soon and we can see some
>> > > progress.
>
> Excellent to hear.  Any idea as to when FreeBSD will be self-hosting?
Not sure. If only we knew someone with a Roslyn compiler, msbuild, and
a working Framework on FreeBSD? Hmmm

> Regards
>
> David
___
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"

Mono 5.2 patch and DotNet Core 2 update

[Russell Haley]

Hey Guys,

Merry Christmas! Hope this finds you all well. While free time for me
has been at a premium, I have managed to finally get my hands on a
laptop and cram 16 Gb of ram and a nice big SSD in it. That means I
now have room for lots of VMs. I have a GhostBSD image (FreeBSD 11.1)
and will bring up a TrueOS which is a revision of CURRENT. Yay for
Virtual Box!

Mono 5.2

I've created a svn ports repo to mess with and tried out the Mono 5.2
patch from David. While I ultimately succeeded,  the D12440.diff patch
had one error. The chunk was in a RUN_DEPENDS (inconsiquential to the
build) but I patched it manually and ran it. I then found blank patch
files for patch-mono_metadata_socket-io.c,
patch-mono_utils_mono-compiler.h and patch-mono_utils_w32handle.c
(there may have been more, I wasn't careful enough when I was deleting
them).

After some difficulty with the tarball downloads timing out, the build
completed successfully! I'll be checking MonoDevelop as well shortly.
I'm hoping David can chime in and we can finish this off?

DotNet Core 2

Tomas from MS has been building out the Core Framework (corefx) and
has an "Frankensteins Monster" SDK ready for testing. I have been
working on getting the Common Language Runtime (coreclr) test suite to
build to validate the system. The working instructions are being
generated as we go. I've been building the managed parts on Windows,
while Tomas has been using GNU/Linux for a build platform. I'm hoping
my work will start to coalesce with Tomas' soon and we can see some
progress.

Tomas, can you add anything?

Anyway, hope springs eternal in the new year.

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

Re: Update on porting mono 5

[Russell Haley]

On Thu, Nov 23, 2017 at 9:33 PM, Russell Haley <russ.ha...@gmail.com> wrote:
> On Thu, Nov 23, 2017 at 1:01 PM, David Naylor <naylor.b.da...@gmail.com> 
> wrote:
>> On Monday, 13 November 2017 23:11:03 David Naylor wrote:
>>> In the interim, I tried my hand at my own exp-run [1][2][3].  And things
>>> didn't go well (well the exp-run was a success, but the results...).
>>>
>>> It appears that somehow the assemblies are being delay signed during build,
>>> instead of signed.  It appears csc(1) [the replacement for mcs(1)] does not
>>> support signing on non-Windows machines [4].  Mono recommends sn(1) should
>>> be used to sign the dll after build.  I suggest we patch
>>> Microsoft.Common.CurrentVersion.target to restore signing functionality.
>>
>> I've fixed signing of assemblies by using sn(1) after the compile step in the
>> CoreCompile target.  This fixed one port and pushed post packages to breaking
>> due to changes from mdb to pdb debug info.
> Wow. I haven't seen sn or SigningTool in a long time. Nice job. I
> didn't even think of it.
>
>>> Any help with the above or the following will be most appreciated:
>>>  - Bumping the PORTREVISION of all ports that depend on mono
>>>  - Patching security/ca_root_nss to update/sync/clear the mono certificate
>>> (see cet-sync(1))
>>>  - (Optional) Patch mono to store the certificates in $PREFIX, instead of
>>> /usr/local/
>>  - fix the follow port's pkg-plist:
>>- devel/dbus-sharp
>>- devel/mono-addins
>>- devel/newtonsoft-json
>>- multimedia/emby-server
>>  - investigate why the following ports do not build:
>>- games/openra
>>- security/gnome-keyring-sharp
>
> I'm perusing your review right now. I haven't absorbed enough to
> comment yet. You seem to have added a new make variable for
> nuget_depends. Can you speak a little about that? I am wondering if
> leverage that in dotnet core to pull in the managed assemblies that we
> can't build on FreeBSD?
>
> Russ

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: Help Wanted - Work with MSFT and help finish the port of .NET Core to FreeBSD

[Russell Haley]

+1
I threw some comments on the open issues.

On Wed, Sep 27, 2017 at 6:36 PM, Geoffrey Huntley <ghunt...@ghuntley.com> 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 <russ.ha...@gmail.com> 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 <russ.ha...@gmail.com>
>> wrote:
>> > On Tue, Sep 5, 2017 at 11:52 AM, David Naylor <naylor.b.da...@gmail.com>
>> > 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: 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 <naylor.b.da...@gmail.com> 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 <naylor.b.da...@gmail.com> 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"

DotNet Core 2.0 - Status Update

[Russell Haley]

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.

Thoughts?

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]

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 <russ.ha...@gmail.com> 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 <russ.ha...@gmail.com> wrote:
>> > On Thu, Sep 21, 2017 at 1:20 PM, David Naylor <naylor.b.da...@gmail.com>
> 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: DotNet Core Source Build Questions

[Russell Haley]

Comment inline.

On Tue, Sep 19, 2017 at 10:18 PM, Russell Haley <russ.ha...@gmail.com> wrote:
> On Tue, Sep 19, 2017 at 10:11 PM, Tomas Weinfurt
> <tomas.weinf...@microsoft.com> wrote:
>> I’ll take a look. Once you on path where it tries to install Tools it is bad.
>> Please try src/Native/build-native.sh directly.
>
> Okay, that started things in the right direction:
>
> russellh@prescott:/storage/russellh/Git/corefx/src/Native%
> ./build-native.sh
> Setting up directories for build
> WARNING: Can not determine runtime id for current distro.
> Checking pre-requisites...
> Commencing build of corefx native components for FreeBSD.x64.Debug
> Invoking cmake with arguments:
> "/storage/russellh/Git/corefx/src/Native/Unix" DEBUG
> -DFEATURE_DISTRO_AGNOSTIC_SSL=0 -DCMAKE_STATIC_LIB_LINK=0
> -- The C compiler identification is Clang 4.0.0
> -- The CXX compiler identification is Clang 4.0.0
> -- Check for working C compiler: /usr/bin/clang
> -- Check for working C compiler: /usr/bin/clang -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Check for working CXX compiler: /usr/bin/clang++
> -- Check for working CXX compiler: /usr/bin/clang++ -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> -- Looking for include file linux/in.h
> -- Looking for include file linux/in.h - not found
#Here is the problem. The pal_networking.cpp file has a definition for
in_pktinfo. It didn't get hit because the following test succeeded and
it should have failed:

> -- Performing Test HAVE_IN_PKTINFO
> -- Performing Test HAVE_IN_PKTINFO - Success
> -- Performing Test HAVE_IP_MREQN
> -- Performing Test HAVE_IP_MREQN - Success
> -- Performing Test HAVE_FLOCK64
> -- Performing Test HAVE_FLOCK64 - Failed
> -- Looking for lseek64
> -- Looking for lseek64 - not found
> -- Looking for mmap64
> -- Looking for mmap64 - not found
> -- Looking for ftruncate64
> -- Looking for ftruncate64 - not found
> -- Looking for posix_fadvise64
> -- Looking for posix_fadvise64 - not found
> -- Looking for stat64
> -- Looking for stat64 - not found
> -- Looking for pipe2
> -- Looking for pipe2 - found
> -- Looking for getmntinfo
> -- Looking for getmntinfo - found
> -- Looking for strcpy_s
> -- Looking for strcpy_s - not found
> -- Looking for strlcpy
> -- Looking for strlcpy - found
> -- Looking for posix_fadvise
> -- Looking for posix_fadvise - found
> -- Looking for ioctl
> -- Looking for ioctl - found
> -- Looking for sched_getaffinity
> -- Looking for sched_getaffinity - not found
> -- Looking for sched_setaffinity
> -- Looking for sched_setaffinity - not found
> -- Looking for TIOCGWINSZ
> -- Looking for TIOCGWINSZ - found
> -- Looking for tcgetattr
> -- Looking for tcgetattr - found
> -- Looking for tcsetattr
> -- Looking for tcsetattr - found
> -- Looking for ECHO
> -- Looking for ECHO - found
> -- Looking for ICANON
> -- Looking for ICANON - found
> -- Looking for TCSANOW
> -- Looking for TCSANOW - found
> -- Performing Test HAVE_STAT_BIRTHTIME
> -- Performing Test HAVE_STAT_BIRTHTIME - Success
> -- Performing Test HAVE_DIRENT_NAME_LEN
> -- Performing Test HAVE_DIRENT_NAME_LEN - Success
> -- Performing Test HAVE_STATFS_FSTYPENAME
> -- Performing Test HAVE_STATFS_FSTYPENAME - Success
> -- Performing Test HAVE_STATVFS_FSTYPENAME
> -- Performing Test HAVE_STATVFS_FSTYPENAME - Failed
> -- Check size of struct statfs
> -- Check size of struct statfs - done
> -- Performing Test HAVE_GNU_STRERROR_R
> -- Performing Test HAVE_GNU_STRERROR_R - Failed
> -- Performing Test HAVE_READDIR_R
> -- Performing Test HAVE_READDIR_R - Success
> -- Performing Test KEVENT_HAS_VOID_UDATA
> -- Performing Test KEVENT_HAS_VOID_UDATA - Success
> -- Performing Test HAVE_FDS_BITS
> -- Performing Test HAVE_FDS_BITS - Success
> -- Performing Test HAVE_PRIVATE_FDS_BITS
> -- Performing Test HAVE_PRIVATE_FDS_BITS - Success
> -- Performing Test HAVE_SENDFILE_4
> -- Performing Test HAVE_SENDFILE_4 - Failed
> -- Performing Test HAVE_SENDFILE_6
> -- Performing Test HAVE_SENDFILE_6 - Failed
> -- Looking for fcopyfile
> -- Looking for fcopyfile - not found
> -- Looking for epoll_create1
> -- Looking for epoll_create1 - not found
> -- Looking for accept4
> -- Looking for accept4 - found
> -- Looking for kqueue
> -- Looking for kqueue - found
> -- Performing Test HAVE_GETHOSTBYADDR_R
> -- Performing Test HAVE_GETHOSTBYADDR_R - Success
> -- Performing Test HAVE_GETHOSTBYNAME_R
> -- Performing Test 

Re: DotNet Core Source Build Questions

[Russell Haley]

 note: expanded from macro '_ALIGN'
#define _ALIGN(p)   (((__uintptr_t)(p) + _ALIGNBYTES) &
~_ALIGNBYTES)
^
/usr/include/netinet6/in6.h:549:8: note: 'in6_pktinfo' declared here
struct in6_pktinfo {
   ^
/storage/russellh/Git/corefx/src/Native/Unix/System.Native/pal_networking.cpp:1171:43:
error: unknown type name 'in_pktinfo'; did you mean 'in6_pktinfo'?
if (controlMessage->cmsg_len < sizeof(in_pktinfo))
  ^~
  in6_pktinfo
/usr/include/netinet6/in6.h:549:8: note: 'in6_pktinfo' declared here
struct in6_pktinfo {
   ^
/storage/russellh/Git/corefx/src/Native/Unix/System.Native/pal_networking.cpp:1177:38:
error: unknown type name 'in_pktinfo'; did you mean 'in6_pktinfo'?
auto* pktinfo =
reinterpret_cast<in_pktinfo*>(CMSG_DATA(controlMessage));
 ^~
 in6_pktinfo
/usr/include/netinet6/in6.h:549:8: note: 'in6_pktinfo' declared here
struct in6_pktinfo {
   ^
/storage/russellh/Git/corefx/src/Native/Unix/System.Native/pal_networking.cpp:1178:99:
error: no member named 'ipi_addr' in 'in6_pktinfo'
ConvertInAddrToByteArray(>Address.Address[0],
NUM_BYTES_IN_IPV4_ADDRESS, pktinfo->ipi_addr);

  ~~~  ^
/storage/russellh/Git/corefx/src/Native/Unix/System.Native/pal_networking.cpp:1180:64:
error: no member named 'ipi_ifindex' in 'in6_pktinfo'; did you mean
'ipi6_ifindex'?
packetInfo->InterfaceIndex =
static_cast(pktinfo->ipi_ifindex);

^~~

ipi6_ifindex
/usr/include/netinet6/in6.h:551:15: note: 'ipi6_ifindex' declared here
unsigned intipi6_ifindex;   /* send/recv interface index
*/
^
/storage/russellh/Git/corefx/src/Native/Unix/System.Native/pal_networking.cpp:1248:90:
error: use of undeclared identifier 'IP_PKTINFO'
if (controlMessage->cmsg_level == IPPROTO_IP &&
controlMessage->cmsg_type == IP_PKTINFO)

  ^
/storage/russellh/Git/corefx/src/Native/Unix/System.Native/pal_networking.cpp:1954:31:
error: use of undeclared identifier 'IP_PKTINFO'
optName = IP_PKTINFO;
  ^
7 errors generated.
*** [System.Native/CMakeFiles/System.Native-Static.dir/pal_networking.cpp.o]
Error code 1

make[2]: stopped in
/storage/russellh/Git/corefx/bin/obj/FreeBSD.x64.Debug/native
1 error

make[2]: stopped in
/storage/russellh/Git/corefx/bin/obj/FreeBSD.x64.Debug/native
*** [System.Native/CMakeFiles/System.Native-Static.dir/all] Error code
2

make[1]: stopped in
/storage/russellh/Git/corefx/bin/obj/FreeBSD.x64.Debug/native
1 error

make[1]: stopped in
/storage/russellh/Git/corefx/bin/obj/FreeBSD.x64.Debug/native
*** [all] Error code 2

make: stopped in
/storage/russellh/Git/corefx/bin/obj/FreeBSD.x64.Debug/native
1 error

make: stopped in
/storage/russellh/Git/corefx/bin/obj/FreeBSD.x64.Debug/native
Failed to build corefx native components.
russellh@prescott:/storage/russellh/Git/corefx/src/Native%

Looks like there is a missing struct that is in Windows and Linux. in_pktinfo?

https://lists.freedesktop.org/archives/gstreamer-bugs/2016-July/180624.html


> Tomas
>
> On 9/19/17, 10:07 PM, "Russell Haley" <russ.ha...@gmail.com> wrote:
>
> Hey Tomas,
>
> coreclr native parts built first time for me. I am trying to build the
> dotnet fx native parts and I'm still stalled out on Linux emulation
> errors. I have a question in the TrueOS forums and will poke around:
> 
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdiscourse.trueos.org%2Ft%2Fexecuting-64-bit-linux-binaries%2F703%2F2=02%7C01%7CTomas.Weinfurt%40microsoft.com%7C3b720d481d9b4e70aceb08d4ffe57ac2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636414808455309694=us2YL%2F%2BjZg2xtSCtzDCrhRwGH3EqoTwPK8MWcazmNEo%3D=0
>
> Here is my build output:
>
> russellh@prescott:/storage/russellh/Git/corefx% ./build.sh native
> -clang=clang3.9
> Unsupported OS 'FreeBSD' detected. Downloading linux-x64 tools.
> Installing dotnet cli...
> Restoring BuildTools version 2.0.0-prerelease-01931-01...
> ELF interpreter /lib64/ld-linux-x86-64.so.2 not found, error 2
> /storage/russellh/Git/corefx/init-tools.sh: line 142: 39789 Abort trap
>  $__DOTNET_CMD restore "$__INIT_TOOLS_RESTORE_PROJECT"
> --no-cache --packages $__PACKAGES_DIR --source $__BUILDTOOLS_SOURCE
> /p:BuildToolsPackageVersion=$__BUILD_TOOLS_PACKAGE_VERSION >>
> $__init_tools_log
> ERROR: Could not restore build tools correctly.
> Please check the detailed log that follows.
> Running: /storage/russellh/Git/corefx/init-tools.sh
> Installing 
> 'https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdotnetcli

DotNet Core Source Build Questions

[Russell Haley]

Hey Tomas,

coreclr native parts built first time for me. I am trying to build the
dotnet fx native parts and I'm still stalled out on Linux emulation
errors. I have a question in the TrueOS forums and will poke around:
https://discourse.trueos.org/t/executing-64-bit-linux-binaries/703/2

Here is my build output:

russellh@prescott:/storage/russellh/Git/corefx% ./build.sh native
-clang=clang3.9
Unsupported OS 'FreeBSD' detected. Downloading linux-x64 tools.
Installing dotnet cli...
Restoring BuildTools version 2.0.0-prerelease-01931-01...
ELF interpreter /lib64/ld-linux-x86-64.so.2 not found, error 2
/storage/russellh/Git/corefx/init-tools.sh: line 142: 39789 Abort trap
 $__DOTNET_CMD restore "$__INIT_TOOLS_RESTORE_PROJECT"
--no-cache --packages $__PACKAGES_DIR --source $__BUILDTOOLS_SOURCE
/p:BuildToolsPackageVersion=$__BUILD_TOOLS_PACKAGE_VERSION >>
$__init_tools_log
ERROR: Could not restore build tools correctly.
Please check the detailed log that follows.
Running: /storage/russellh/Git/corefx/init-tools.sh
Installing 
'https://dotnetcli.azureedge.net/dotnet/Sdk/2.0.0-preview1-005977/dotnet-dev-linux-x64.2.0.0-preview1-005977.tar.gz'
to '/storage/russellh/Git/corefx/Tools/dotnetcli/dotnet.tar'
Running: /storage/russellh/Git/corefx/Tools/dotnetcli/dotnet restore
"/storage/russellh/Git/corefx/init-tools.msbuild" --no-cache
--packages /storage/russellh/Git/corefx/packages --source
https://dotnet.myget.org/F/dotnet-buildtools/api/v3/index.json
/p:BuildToolsPackageVersion=2.0.0-prerelease-01931-01
Initializing BuildTools...
chmod: 
/storage/russellh/Git/corefx/packages/microsoft.dotnet.buildtools/2.0.0-prerelease-01931-01/lib/init-tools.sh:
No such file or directory
/storage/russellh/Git/corefx/init-tools.sh: line 121:
/storage/russellh/Git/corefx/packages/microsoft.dotnet.buildtools/2.0.0-prerelease-01931-01/lib/init-tools.sh:
No such file or directory
ERROR: An error occurred when trying to initialize the tools.
Please check the detailed log that follows.
Running: /storage/russellh/Git/corefx/init-tools.sh
Installing 
'https://dotnetcli.azureedge.net/dotnet/Sdk/2.0.0-preview1-005977/dotnet-dev-linux-x64.2.0.0-preview1-005977.tar.gz'
to '/storage/russellh/Git/corefx/Tools/dotnetcli/dotnet.tar'
Running: /storage/russellh/Git/corefx/Tools/dotnetcli/dotnet restore
"/storage/russellh/Git/corefx/init-tools.msbuild" --no-cache
--packages /storage/russellh/Git/corefx/packages --source
https://dotnet.myget.org/F/dotnet-buildtools/api/v3/index.json
/p:BuildToolsPackageVersion=2.0.0-prerelease-01931-01
Running: 
/storage/russellh/Git/corefx/packages/microsoft.dotnet.buildtools/2.0.0-prerelease-01931-01/lib/init-tools.sh
/storage/russellh/Git/corefx
/storage/russellh/Git/corefx/Tools/dotnetcli/dotnet
/storage/russellh/Git/corefx/Tools
russellh@prescott:/storage/russellh/Git/corefx%


I tried building the mscorelib in monodevelop (and also tried xbuild)
but got the following error:

Error: /storage/russellh/Git/coreclr/src/mscorlib/System.Private.CoreLib.csproj:
/storage/russellh/Git/coreclr/dir.targets: Project file could not be
imported, it was being imported by
/storage/russellh/Git/coreclr/src/mscorlib/System.Private.CoreLib.csproj:
/storage/russellh/Git/coreclr/dir.targets could not import
"$(ToolsDir)/Build.Common.targets" (System.Private.CoreLib)x

A quick search showed something about wrong framework version. I
wonder if I should ping off the Xamarina/Mono team?

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"

Funny

[Russell Haley]

___
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 on FreeBSD

[Russell Haley]

Hey Guys,

So I had a good chat on the phone today with Karel Zikmund and Tomas
Weinfurt from Microsoft. Karel and Tomas work together on the DotNet
Core Team. Tomas was looking for a way to get in deep with the
framework and has past FreeBSD experience, so offered to look into
porting Core 2.0 over to FreeBSD on his own time. Karel has supported
Tomas by advocating for giving him work time to devote to the porting
process.[1]

Microsoft and the DotNet Core Team have agreed to restart the FreeBSD
porting process and are looking to engage the FreeBSD community
because there is quite a bit of work to be done. There are many moving
parts to building and running DotNet, each with it's own challenge in
the porting process. Just between the three people in the phone call
there were numerous paths identified for others to engage. Because of
the width of the problem, Karel and Tomas have put together the
following outline of the outstanding work:

  1.  Produce binaries in CoreCLR & CoreFX repo targeting FreeBSD –
using hacks is fine
 *   Hard to parallelize, Tomas will work on that
 *   The build can be mix of builds from other platforms (Mac,
Linux) targeting FreeBSD
 *   We will need steps to reproduce the build with
FreeBSD-specific bug fixes
  2.  Run & stabilize CoreCLR tests (using corerun)
 *   Tests may be built on another platform
 *   Goal: Provides basic quality of runtime
  3.  Run & stabilize CoreFX tests (using corerun)
 *   Tests may be built on another platform
 *   Note this requires xunit. We believe, based on our past
porting experience, once #2 is done, xunit will just work.
 *   This can be in theory parallelized with #2 – it may require
shortcutting xunit (e.g. generate static execution recipe on another
platform)
  4.  Full stack build on FreeBSD (using corerun as bootstrapper from #1-#3)
 *   We will need all tools (nuget, msbuild, roslyn) to work on
boostrapping .NET Core
  5.  Installers (FreeBSD ports)
 *   First-stage: Using product binaries from nuget feeds
 *   Second-stage: Build product from source (blocked on build
from source effort)
 *   Requires FreeBSD community expertise and guidance on design
 *   Note: We can link FreeBSD packages also from official .NET
Core download pages as community-support packages
  6.  Regular build and test runs on FreeBSD
 *   Goal: Make sure changes in .NET Core repos breaking FreeBSD
are known early
 *   Design needed
 *   Requires FreeBSD community expertise and guidance on design

This list is just a general overview of what's needs to happen. There
is still some incomplete critical path work, but that seems to be
pretty well in hand by Tomas. I asked them to give us whatever they
had and let the people pour over it, so Tomas has agreed to put
together a document.

The next big step in getting traction is for the community to identify
people who would like to participate in the porting process, and
finding ways to engage. Obviously, you're free to do what you want,
but Karel and Tomas are hoping to direct the work towards specific
goals and try to drive the porting process as fast as possible. I
suggested that teams like the KDE team, or past mono teams seem to
have worked liked that.

If you'd like to participate/join the fun, please set up a GitHub
account and send a 'me too' email with the username or email address.
I'll send an invite for the FreeBSD-DotNet to that account. I'm not so
sure anymore about using GitHub for FreeBSD stuff, but it's a good
place to congregate.

Either way, I'm hoping to get a handle on the whole thing again and
try and be productive myself. I'm hoping to talk to David about
spring-boarding off of his Mono 5 work and start a new dotnet-core
port. There are also opportunities to use Mono to kickstart the build
process to get people working with the system.

Thanks guys, I look forward to hearing from you (I hope!). If not,
I'll be keeping people up to date on this mailing list.

Cheers,
Russ

[1] My paraphrasing of the situation. I could be totally off base.

On Sun, Sep 10, 2017 at 10:09 PM, Russell Haley <russ.ha...@gmail.com> wrote:
> Does anyone here run Unity? Unity is a very popular gaming engine that
> is cross platform and provides a C# API.
>
> https://en.wikipedia.org/wiki/Unity_(game_engine)
>
> https://mellinoe.wordpress.com/2017/01/18/net-core-game-engine/
>
> Kaboom! (Head exploded again. This is getting messy)
>
> Russ
>
> On Sun, Sep 10, 2017 at 10:03 PM, Russell Haley <russ.ha...@gmail.com> wrote:
>> On Sun, Sep 10, 2017 at 9:59 PM, Russell Haley <russ.ha...@gmail.com> wrote:
>>> Hey Marcin,
>>>
>>> So I just read the Contribution License Agreement and I didn't see
>>> anything untoward.
>>>
>>> https://cla2.dotnetfoundation.org/cladoc/net-foundation-contribution-license-agreement.pdf
>>>
>>&g

Re: DotNet Core on FreeBSD

[Russell Haley]

Does anyone here run Unity? Unity is a very popular gaming engine that
is cross platform and provides a C# API.

https://en.wikipedia.org/wiki/Unity_(game_engine)

https://mellinoe.wordpress.com/2017/01/18/net-core-game-engine/

Kaboom! (Head exploded again. This is getting messy)

Russ

On Sun, Sep 10, 2017 at 10:03 PM, Russell Haley <russ.ha...@gmail.com> wrote:
> On Sun, Sep 10, 2017 at 9:59 PM, Russell Haley <russ.ha...@gmail.com> wrote:
>> Hey Marcin,
>>
>> So I just read the Contribution License Agreement and I didn't see
>> anything untoward.
>>
>> https://cla2.dotnetfoundation.org/cladoc/net-foundation-contribution-license-agreement.pdf
>>
>> Just remember all these projects are MIT, Apache 2 or CC license. I
>> think bringing this code into FreeBSD is a bonkers good idea. (Kaboom!
>> lolz). Especially if you think about how much proprietary code is out
>> there on Windows that people will want to protect. A FreeNAS style
>> management console would make FreeBSD a particularly attractive offer
>> over GPL licensed OSes for companies to create appliance style systems
>> (physical or virtual, a-la FreeNAS). Jails become yet another great
>> way to distribute proprietary code.
>>
>> Sony PS 3&4, NetApp and now Nintendo Switch are all great examples of
>> what you can do with FreeBSD in a proprietary system.
>>
>> Dot Net Core also opens up Arm based systems on FreeBSD in some ways
>> because it's specifically designed do be modular. I don't think Mono
>> has built on Arm for a long time and the performance of Mono has been
>> a problem of note.
>>
>> Russ
>
> I'm trying to perform due diligence because I want to throw some time
> into this. Avoiding GPL and other encumbering licenses is important to
> me. I had to know myself so I made this list of licenses:
>
> https://github.com/dotnet/csharplang - Microsoft
> https://github.com/dotnet/cli -
> https://www.microsoft.com/net/dotnet_library_license.htm
>
> https://github.com/dotnet/source-build - MIT
> https://github.com/dotnet/core-setup - MIT
> https://github.com/dotnet/corefx - MIT
> https://github.com/dotnet/coreclr - MIT
> https://github.com/dotnet/sdk - MIT
> https://github.com/dotnet/dotnet-docker - MIT
> https://github.com/dotnet/standard - MIT
> https://github.com/dotnet/sdk - MIT
> https://github.com/dotnet/netcorecli-fsc - MIT
>
> https://github.com/nuget/home - A2
> https://github.com/aspnet/home - A2
> https://github.com/dotnet/roslyn - A2
>
> https://github.com/aspnet/Docs - CC
> https://github.com/dotnet/docs - CC
>
> Russ
>
>> On Sun, Sep 10, 2017 at 8:52 AM, Russell Haley <russ.ha...@gmail.com> wrote:
>>> Sorry for the top post,
>>>
>>> Marcin, can you expand on your thoughts about the contributor license? This 
>>> has been one of the concerns of mine‎ (part of the pedanticism). I didn't 
>>> get a chance to read the doc itself yet.
>>>
>>> Russ
>>>
>>> Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
>>>   Original Message
>>> From: Marcin Cieslak
>>> Sent: Sunday, September 10, 2017 1:13 AM
>>> To: Russell Haley
>>> Cc: David Naylor; Geoffrey Huntley; Freebsd-mono; 
>>> freebsd-advoc...@freebsd.org; freebsd-po...@freebsd.org
>>> Subject: Re: DotNet Core on FreeBSD
>>>
>>> On Sun, 10 Sep 2017, Russell Haley wrote:
>>>
>>>> Hey guys,
>>>>
>>>> I am talking to Karel and Tomas at Microsoft's DotNet Core Team about
>>>> putting together a "proposal" for community involvement, which will be
>>>> followed by more information on this list. Most of the talk has been
>>>> me blowing air and being pedantic about nothing (I get excited and
>>>> type alot).
>>>
>>> I was tinkering around FreeBSD support when dotnet core was first published.
>>> Stack unwinding for exceptions was very hacky at the time, and there were
>>> some unnecessary discussions about how to implement some FreeBSD sepecific
>>> sysctl's. I got a bit frustrated with that (a whole porting effort is about
>>> coercing Unix to offer part of Win32 APIs).
>>>
>>> It was somewhat running on FreeBSD natively back then, haven't checked
>>> recently.
>>>
>>> I have also decided not to sign their bad contributor agreement
>>> and some of the sysctl code I decided to put in mono instead :)
>>>
>>> Marcin
>>> saper on github
___
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 on FreeBSD

[Russell Haley]

Hey Marcin,

So I just read the Contribution License Agreement and I didn't see
anything untoward.

https://cla2.dotnetfoundation.org/cladoc/net-foundation-contribution-license-agreement.pdf

Just remember all these projects are MIT, Apache 2 or CC license. I
think bringing this code into FreeBSD is a bonkers good idea. (Kaboom!
lolz). Especially if you think about how much proprietary code is out
there on Windows that people will want to protect. A FreeNAS style
management console would make FreeBSD a particularly attractive offer
over GPL licensed OSes for companies to create appliance style systems
(physical or virtual, a-la FreeNAS). Jails become yet another great
way to distribute proprietary code.

Sony PS 3&4, NetApp and now Nintendo Switch are all great examples of
what you can do with FreeBSD in a proprietary system.

Dot Net Core also opens up Arm based systems on FreeBSD in some ways
because it's specifically designed do be modular. I don't think Mono
has built on Arm for a long time and the performance of Mono has been
a problem of note.

Russ

On Sun, Sep 10, 2017 at 8:52 AM, Russell Haley <russ.ha...@gmail.com> wrote:
> Sorry for the top post,
>
> Marcin, can you expand on your thoughts about the contributor license? This 
> has been one of the concerns of mine‎ (part of the pedanticism). I didn't get 
> a chance to read the doc itself yet.
>
> Russ
>
> Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
>   Original Message
> From: Marcin Cieslak
> Sent: Sunday, September 10, 2017 1:13 AM
> To: Russell Haley
> Cc: David Naylor; Geoffrey Huntley; Freebsd-mono; 
> freebsd-advoc...@freebsd.org; freebsd-po...@freebsd.org
> Subject: Re: DotNet Core on FreeBSD
>
> On Sun, 10 Sep 2017, Russell Haley wrote:
>
>> Hey guys,
>>
>> I am talking to Karel and Tomas at Microsoft's DotNet Core Team about
>> putting together a "proposal" for community involvement, which will be
>> followed by more information on this list. Most of the talk has been
>> me blowing air and being pedantic about nothing (I get excited and
>> type alot).
>
> I was tinkering around FreeBSD support when dotnet core was first published.
> Stack unwinding for exceptions was very hacky at the time, and there were
> some unnecessary discussions about how to implement some FreeBSD sepecific
> sysctl's. I got a bit frustrated with that (a whole porting effort is about
> coercing Unix to offer part of Win32 APIs).
>
> It was somewhat running on FreeBSD natively back then, haven't checked
> recently.
>
> I have also decided not to sign their bad contributor agreement
> and some of the sysctl code I decided to put in mono instead :)
>
> Marcin
> saper on github
___
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 on FreeBSD

[Russell Haley]

Sorry for the top post,

Marcin, can you expand on your thoughts about the contributor license? This has 
been one of the concerns of mine‎ (part of the pedanticism). I didn't get a 
chance to read the doc itself yet. 

Russ

Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
  Original Message  
From: Marcin Cieslak
Sent: Sunday, September 10, 2017 1:13 AM
To: Russell Haley
Cc: David Naylor; Geoffrey Huntley; Freebsd-mono; freebsd-advoc...@freebsd.org; 
freebsd-po...@freebsd.org
Subject: Re: DotNet Core on FreeBSD

On Sun, 10 Sep 2017, Russell Haley wrote:

> Hey guys,
> 
> I am talking to Karel and Tomas at Microsoft's DotNet Core Team about
> putting together a "proposal" for community involvement, which will be
> followed by more information on this list. Most of the talk has been
> me blowing air and being pedantic about nothing (I get excited and
> type alot).

I was tinkering around FreeBSD support when dotnet core was first published.
Stack unwinding for exceptions was very hacky at the time, and there were
some unnecessary discussions about how to implement some FreeBSD sepecific
sysctl's. I got a bit frustrated with that (a whole porting effort is about
coercing Unix to offer part of Win32 APIs).

It was somewhat running on FreeBSD natively back then, haven't checked
recently.

I have also decided not to sign their bad contributor agreement
and some of the sysctl code I decided to put in mono instead :)

Marcin
saper on github
___
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 Fri, Sep 8, 2017 at 12:41 AM, Romain Tartière <rom...@freebsd.org> 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 <rom...@freebsd.org>  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: Help Wanted - Work with MSFT and help finish the port of .NET Core to FreeBSD

[Russell Haley]

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 <russ.ha...@gmail.com> wrote:
> On Tue, Sep 5, 2017 at 11:52 AM, David Naylor <naylor.b.da...@gmail.com> 
> 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: Update on porting mono 5

[Russell Haley]

On Thu, Sep 7, 2017 at 11:09 AM, David Naylor <naylor.b.da...@gmail.com> wrote:
> On Tuesday, 5 September 2017 13:09:14 Russell Haley wrote:
>> On Tue, Sep 5, 2017 at 12:25 PM, David Naylor <naylor.b.da...@gmail.com>
> wrote:
>> > On Saturday, 2 September 2017 07:40:28 Russell Haley wrote:
>> >> On Sat, Sep 2, 2017 at 4:55 AM, Robert Alegrid <eraleg...@hotmail.com>
>> >> 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

[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 <naylor.b.da...@gmail.com> wrote:
> On Saturday, 2 September 2017 07:40:28 Russell Haley wrote:
>> On Sat, Sep 2, 2017 at 4:55 AM, Robert Alegrid <eraleg...@hotmail.com>
> 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

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

[Russell Haley]

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: 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,

Re: Has anyone tried to port Mono to RTEMS

[Russell Haley]

___
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: [package - 101amd64-default][lang/referenceassemblies-pcl] Failed for referenceassemblies-pcl-4.6_1 in package

[Russell Haley]

This is just a guess because I'm looking at this on my phone. The profiles for 
the missing files aren't in the list of --include parameters in the previous 
staging step?

Russ

Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
  Original Message  
From: Romain Tartière
Sent: Saturday, October 15, 2016 12:17 AM
To: freebsd-mono@freebsd.org
Cc: d...@freebsd.org
Subject: Re: [package - 101amd64-default][lang/referenceassemblies-pcl] Failed 
for referenceassemblies-pcl-4.6_1 in package

Hello

On Sat, Oct 15, 2016 at 01:16:06AM +, pkg-fall...@freebsd.org wrote:
> ===
> ===> Building package for referenceassemblies-pcl-4.6_1
> pkg-static: Unable to access file 
> /wrkdirs/usr/ports/lang/referenceassemblies-pcl/work/stage/usr/local/lib/mono/xbuild-frameworks/.NETPortable/v4.0/Profile/Profile136/RedistList/FrameworkList.xml:
>  No such file or directory
> pkg-static: Unable to access file 
> /wrkdirs/usr/ports/lang/referenceassemblies-pcl/work/stage/usr/local/lib/mono/xbuild-frameworks/.NETPortable/v4.0/Profile/Profile136/SupportedFrameworks/.NET
>  Framework 4.xml: No such file or directory
> [... many more files ...]
> pkg-static: Unable to access file 
> /wrkdirs/usr/ports/lang/referenceassemblies-pcl/work/stage/usr/local/lib/mono/xbuild-frameworks/.NETPortable/v4.6/Profile/Profile44/mscorlib.dll:
>  No such file or directory
> pkg-static: Unable to access file 
> /wrkdirs/usr/ports/lang/referenceassemblies-pcl/work/stage/usr/local/lib/mono/xbuild-frameworks/.NETPortable/v4.6/RedistList/FrameworkList.xml:
>  No such file or directory
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/ports/lang/referenceassemblies-pcl

Same problem here: no problem to build the port on my bare metal FreeBSD
11.0-STABLE system, but can't get any package with poudriere :

https://packages.blogreen.org/data/10_3_RELEASE_amd64-mono/2016-10-15_07h53m31s/logs/errors/referenceassemblies-pcl-4.6_1.log

Any idea?

-- 
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: Latest MonoDevelop Progress

[Russell Haley]

Success!

I was able to build monodevelop from master by including the correct
PCLs (links below, thanks Romain!) and applying the small git diff
attached. I created a default console project in MD and ran it, but
that's as far as I took my exploration (so far).

Thanks very much for everyones help. Mikayla, thanks so much for your support.

So, about that "patch".  I basically just hacked something out of a
file in a language i know nothing about. It seemed trivial enough
(someones not going to get a popup)? I don't use fsharp so

On another note, I was poking around on the .net core sites. I wonder
what's going to happen with monodevelop and .net core? It seems they
(er, you?) have side stepped mono entirely.

Anyway, I'm going to enjoy my small irrelevant victory. Cheers!

Russ

Romains zip. I haven't tested it yet, but it unzips fine.
https://romain.blogreen.org/distfiles/PortableReferenceAssemblies-2014-04-14.zip

tar I created using 7zip.
https://github.com/FreeBSD-DotNet/Microsoft-PCLs


Frameworks:

russellh@prescott:~/Git/monodevelop% pkg info fsharp
fsharp-4.0.1.10
Name   : fsharp
Version: 4.0.1.10
Installed on   : Tue Aug 16 23:37:05 2016 PDT
Origin : lang/fsharp
Architecture   : freebsd:10:x86:64
Prefix : /usr/local
Categories : lang
Licenses   : APACHE20
Maintainer : m...@freebsd.org
WWW: http://fsharp.org/
Comment: Functional and object-oriented language for the .NET platform
Annotations:
Flat size  : 45.5MiB
Description:
F# is an open-source, strongly typed, multi-paradigm programming
language encompassing functional, imperative and object-oriented
programming techniques.  F# is most often used as a cross-platform CLI
language, but can also be used to generate JavaScript and GPU code.

F# is developed by The F# Software Foundation and Microsoft.  An open
source, cross-platform edition of F# is available from the F# Software
Foundation.  F# is also a fully supported language in Visual Studio.
Other tools supporting F# development include Mono, MonoDevelop,
SharpDevelop and the WebSharper tools for JavaScript and HTML5 web
programming.

F# originated as a variant of ML and has been influenced by OCaml, C#,
Python, Haskell, Scala and Erlang.

WWW: http://fsharp.org/

russellh@prescott:~/Git/monodevelop% pkg info mono
mono-4.4.2.11
Name   : mono
Version: 4.4.2.11
Installed on   : Sun Aug 14 22:57:25 2016 PDT
Origin : lang/mono
Architecture   : freebsd:10:x86:64
Prefix : /usr/local
Categories : lang
Licenses   :
Maintainer : m...@freebsd.org
WWW: http://www.mono-project.com/
Comment: Open source implementation of .NET Development Framework
Shared Libs required:
libinotify.so.0
Shared Libs provided:
libmonosgen-2.0.so.1
libmonoboehm-2.0.so.1
libikvm-native.so
libmono-profiler-iomap.so.0
libmono-profiler-aot.so.0
libmono-profiler-log.so.0
libMonoSupportW.so
libMonoPosixHelper.so
Annotations:
cpe: cpe:2.3:a:mono:mono:4.4.2.11:freebsd10:x64
Flat size  : 178MiB
Description:
Mono is an open source implementation of .NET Development Framework. Its
objective is to enable UNIX developers to build and deploy cross-platform
.NET Applications. The project implements various technologies developed by
Microsoft that have now been submitted to the ECMA for standardization.

Mono provides the necessary software to develop and run .NET client and
server applications on BSD, Linux, Solaris, Mac OS X, Windows, and Unix.

WWW: http://www.mono-project.com/



On Thu, Aug 18, 2016 at 2:15 PM, Russell Haley <russ.ha...@gmail.com> wrote:
> On Tue, Aug 16, 2016 at 11:59 PM, Romain Tartière <rom...@blogreen.org> wrote:
>> On Tue, Aug 16, 2016 at 10:37:28PM -0700, Russell Haley wrote:
>>> Thanks for this Romain, I'm just getting around to it now. It looks
>>> like Nuget is now part of the mono make system so there's not much
>>> there to do. I tried to contact the master site in your patch
>>> http://storage.bos.xamarin.com/bot-provisioning/
>>>
>>> but it didn't respond.
>>
>> Seems currently broken, I hope it has not been decomissioned.  In the
>> meantime, I lukily still have the distfile around, I made it avialble
>> here:
>>
>> https://romain.blogreen.org/distfiles/PortableReferenceAssemblies-2014-04-14.zip
>
> If you would like to simply publish your port file with a re-direct to
> this zip I would be just as happy with that. It appears this file is
> "well formed" as the directories are respected when I open it from
> PC-BSD (gui or non-gui). I guess I'll compare against the "newer" list
> I have.
>
>>> I don't know if you saw, but I tried installing the official microsoft
>>> pcl refer

Re: Latest MonoDevelop Progress

[Russell Haley]

On Tue, Aug 16, 2016 at 11:59 PM, Romain Tartière <rom...@blogreen.org> wrote:
> On Tue, Aug 16, 2016 at 10:37:28PM -0700, Russell Haley wrote:
>> Thanks for this Romain, I'm just getting around to it now. It looks
>> like Nuget is now part of the mono make system so there's not much
>> there to do. I tried to contact the master site in your patch
>> http://storage.bos.xamarin.com/bot-provisioning/
>>
>> but it didn't respond.
>
> Seems currently broken, I hope it has not been decomissioned.  In the
> meantime, I lukily still have the distfile around, I made it avialble
> here:
>
> https://romain.blogreen.org/distfiles/PortableReferenceAssemblies-2014-04-14.zip

If you would like to simply publish your port file with a re-direct to
this zip I would be just as happy with that. It appears this file is
"well formed" as the directories are respected when I open it from
PC-BSD (gui or non-gui). I guess I'll compare against the "newer" list
I have.

>> I don't know if you saw, but I tried installing the official microsoft
>> pcl reference binaries. They need to be extracted on Windows from the
>> binary installer (exe) and then the zip file doesn't work in FreeBSD
>> (doesn't respect the MSDOS directory names).   I've put a tar file up
>> on  github under Freebsd-dotnet and I'll try my hand at a port file.
>
> Maybe it's worth double-checking this is permitted :-)  Also, maybe
> checking the differences with
> https://github.com/mono/reference-assemblies makes sense?

I did try the mono reference assemblies once before but will look at it again.
___
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: Latest MonoDevelop Progress

[Russell Haley]

On Mon, Jun 27, 2016 at 5:11 AM, Romain Tartière <rom...@blogreen.org> wrote:
> On Sun, Jun 26, 2016 at 11:25:06PM -0700, Russell Haley wrote:
>> On Sat, Jun 25, 2016 at 2:48 PM, Carsten Larsen <c...@innolan.dk> wrote:
>> > On 25-06-2016, 20:56 Russell Haley wrote:
>> > > I'm unsure to where they get copied.
>> >
>> > [...]
>> >
>> > The Debian package consist of 955 files (and folders):
>> > http://pastebin.com/ATS2M4F7
>>
>> Thanks Carsten, that is the confirmation I needed. Great reference here:
>>
>> https://github.com/gentoo/dotnet/issues/111
>
> In case it helps, there is an old patch for adding
> devel/referenceassemblies-pcl to the ports tree (but installing binaries
> through the ports system is ugly, so I did not pushed it in the official
> ports):
> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=168589=edit


Thanks for this Romain, I'm just getting around to it now. It looks
like Nuget is now part of the mono make system so there's not much
there to do. I tried to contact the master site in your patch
http://storage.bos.xamarin.com/bot-provisioning/

but it didn't respond.

I don't know if you saw, but I tried installing the official microsoft
pcl reference binaries. They need to be extracted on Windows from the
binary installer (exe) and then the zip file doesn't work in FreeBSD
(doesn't respect the MSDOS directory names).   I've put a tar file up
on  github under Freebsd-dotnet and I'll try my hand at a port file.

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: Maintaining mono/.net

[Russell Haley]

On Tue, Jul 5, 2016 at 8:06 AM, Ivan Radovanovic <radovano...@gmail.com> wrote:
> On 06/30/2016 06:31, Russell Haley wrote:
>>
>> ...
>> Apparently I was mistaken, there is no way to "apply" to an
>> organization.  Please feel free to send me your handle like David, and
>> I'll add you.
>>
>> And just in case anyone is fuzzy on GitHub access: There is no need to
>> join the FreeBSD-DotNet organization to create pull requests (i.e.
>> push patches) and our end products should wind up in the Ports tree
>> when we are done.
>>
>
> I had some spare time during weekend so I was playing little bit with mono -
> I cloned mono repository, then branched "freebsd" from their 4.4 branch
> (which is maybe also nice coincidence (freebsd and bsd4.4)), then I merged
> all our changes in that branch - I added Romain's patches to eglib, I added
> my implementation of FS watcher to System.dll, I also added test for FS
> watcher to test cases (so hopefully it will be easier to spot errors), I
> also fixed just couple of warning in C code they have in main mono source
> (there are many warnings there, some look serious to me - my plan is to keep
> reducing their number).
>
> Instead of changing their Kevent watcher implementation I added this one as
> completely new FS watcher (FreeBSD watcher), and I modified
> mono/metadata/filewatcher.c to always use this watcher when compiled on
> FreeBSD (I don't know about kevent implementation on other BSDs - maybe
> FreeBSD implementation should be used there as well).
>
> All mono tests pass (running gmake check), but those related to profiler
> (they segfault in native code - I am planning to investigate that further).
>
> Btw, I am configuring mono with:
>
> ./configure --disable-dtrace --with-checked-build=yes
>
> since if I leave dtrace enabled I get billion linking errors later (I will
> investigate that at certain point as well).
>
> Now, the question is how I push these changes to repository Russ created (is
> that repository we want to use for this project)? I am also not familiar
> enough with git to know if this setup now will work (we were talking to have
> our local repositories to talk to main mono repository for reading, and our
> (fbsd) repository for writing (to keep patches), now actual setup is that
> repository Russ created is forked from mono (I don't know if that changes
> anything)). Maybe somebody can clarify this?
>
> Kind regards,
> Ivan

That's awesome Ivan! That really kicks things up a notch.

A git fork is really nothing more than a set of patches applied to the
original repository. Therefore, we either manually maintain the
patches through the ports tree (via someone with a commit bit), or we
push to github and then everyone can share your work without
centralized supervision. If mono decides to accept our pull requests,
then fine, otherwise, 'to-hell-with-em'. The rub with GitHub is that
there is no way to auto-magically keep a fork up to date, meaning as
soon as you create a fork and apply patches, it becomes possible to
get out of date without manual updates. That means it becomes the
teams job to make sure we keep our repositories current (or get all
patches pushed upstream).

So, there are three ways that I know of to sync your changes *assuming
they under git currently*:
1) via pull requests
2) via raw patches
3) switching the remote origin, pulling the changes, then switching again (?)

I have to go now, so let us know where your changes are. I'm not sure
if you can create pull requests between forks of the same repo, it
will be neat to try. If you are unfamiliar with pushing your changes
back to your remote repository, I always used this:

https://rogerdudler.github.io/git-guide/



Cheers,

Russ

p.s. I have tried some things with MD but still can't get around the
PCL error. I'll write about that later.
___
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: Maintaining mono/.net

[Russell Haley]

On Tue, Jun 28, 2016 at 2:43 AM, Baptiste Daroussin <b...@freebsd.org> wrote:
> On Mon, Jun 27, 2016 at 11:06:02AM -0700, Russell Haley wrote:
>> Hello Ports Team,
>>
>> A couple of us on the freebsd-mono@ mailing list are having a
>> discussion on how best to maintain the mono ports/.net ports. One of
>> the things that has come up is maintaining the patches for "all this
>> stuff". The current paradigm in FreeBSD as I understand it is to use
>> the files directory and apply the patches to the port via svn/ports
>> tree. However, with the ubiquity of GitHub in opensource, it now seems
>> to be feesable to simply create a Github accound to maintain a bunch
>> of forked repositories (which is essentially a patched git
>> repository!). This makes it easier to create and apply patches and
>> gives us the natural path to push things back upstream. In the end, we
>> would just pull from the FreeBSD specific repository, which is no
>> different than, say, pulling from the mono project directly.
>>
>> This email is a request for response from anyone on the ports team (or
>> FreeBSD general) to give some input as to the acceptability of this
>> solution, as well as any "gotchas" we haven't thought of yet. Thanks
>> in advance!
>>
> There are absolutely nothing against this. Actually some ports were already
> doing that before the github era :D
>
> The only difficulty the history told us is : when active people get less 
> active
> for various reasons you need to make sure enough people continues to get 
> access
> to the said repo.
>
> Tracking upstream updates because more complicated for people not in the team
> (we already saw in the past ports stucked for more than 5/6 years actions 
> being
> taken (maintainer of the forked becoming mostly MIA)
>
> It also depends how many patches you end up with, I haven't checked the
> mono/.net ports but if that is just a bunch of small patches then the overhead
> is not worth the pain, if there are lots of patches then sure maintaining your
> repo is simpler.
>
> Depending on how active you (the team) are and how close to the upstream you 
> are
> one can also see those repositories as "temporary" until all the amount of
> patches are upstreamed and when done the ports can switch back to the official
> distfiles (this is always a goal for ports upstreaming all our patches so we 
> can
> remain as close as possible from the vanilla sources)
>
> That said I do applause the effort. As a conclusion do what ever you think is
> the easiest mechanism for you as long as things like monodevelop and friends 
> can
> be pushed in a working state again.
>
> Best regards,
> Bapt

Thanks for the input everyone. I think the overhead of keeping
volatile patches in a globally accessible area is worth while. One of
the things I struggled with historically is how to share my local
changes that I couldn't commit to the svn tree.

I have created an open source organization called FreeBSD-DotNet in
Github. I have differentiated from the Mono moniker because the
merging of the frameworks is inevitable with the purchase of Xamarian.

I went a little crazy and forked a whole bunch of stuff, which I now
think is a bad idea. The only thing that currently requires
customization would be the ports tree itself (MonoDevelop doesn't
build yet, but I haven't needed to change any code). However, I think
we can put a bunch of how-to and wiki stuff in there for the
development efforts.

SO, with that: Anyone wishing to join the FreeBSD-DotNet organization
can go to https://github.com/FreeBSD-DotNet and send a request. I'll
try to flesh out an outstanding items list that can be ratified
sometime in the next couple of weeks.

Thanks,

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"

Maintaining mono/.net

[Russell Haley]

Hello Ports Team,

A couple of us on the freebsd-mono@ mailing list are having a
discussion on how best to maintain the mono ports/.net ports. One of
the things that has come up is maintaining the patches for "all this
stuff". The current paradigm in FreeBSD as I understand it is to use
the files directory and apply the patches to the port via svn/ports
tree. However, with the ubiquity of GitHub in opensource, it now seems
to be feesable to simply create a Github accound to maintain a bunch
of forked repositories (which is essentially a patched git
repository!). This makes it easier to create and apply patches and
gives us the natural path to push things back upstream. In the end, we
would just pull from the FreeBSD specific repository, which is no
different than, say, pulling from the mono project directly.

This email is a request for response from anyone on the ports team (or
FreeBSD general) to give some input as to the acceptability of this
solution, as well as any "gotchas" we haven't thought of yet. Thanks
in advance!


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: Latest MonoDevelop Progress

[Russell Haley]

Thanks Carsten,

I'm unsure to where they get copied.

Sent from my BlackBerry 10 smartphone on the Koodo network.
  Original Message  
From: Carsten Larsen
Sent: Saturday, June 25, 2016 10:31 AM
To: Russell Haley; Freebsd-mono
Subject: Re: Latest MonoDevelop Progress

Hi Russ

On 25-06-2016, 09:14 Russell Haley wrote:

> Lots of work and still no love. My last attempt to port monodevelop
> wasn't nearly this complicated. I'm blogging it in my wiki:
>
> https://github.com/RussellHaley/monodevelop/wiki

I think you are missing the|PCL Reference Assemblies (Portable Class Library).|

|The are ironically not open source and you need to download them from 
Microsoft or Xamarin. Carsten Larsen |

___
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"

Latest MonoDevelop Progress

[Russell Haley]

Lots of work and still no love. My last attempt to port monodevelop
wasn't nearly this complicated. I'm blogging it in my wiki:

https://github.com/RussellHaley/monodevelop/wiki

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: MonoDevelop Build Progress

[Russell Haley]

On Mon, Jun 20, 2016 at 11:16 PM, Russell Haley <russ.ha...@gmail.com> wrote:
> Hey, so I wasn't totally successful but it's going pretty good so far.
> The configure scripts have been update since last time I played with
> it, but as Romain pointed out, there is also an FSharp dependancy now.
> You should be able to follow along from my notes.
>
> https://github.com/RussellHaley/monodevelop/wiki
>
> Cheers,
>
> Russ

Hi Guys, I was able to get the MonoDevelop Build to start, but it dies
out after 39 seconds. All my notes are in the wiki:

 https://github.com/RussellHaley/monodevelop/wiki

I'm going to go and see if I can get IntelliJ to install!

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"

MonoDevelop Build Progress

[Russell Haley]

Hey, so I wasn't totally successful but it's going pretty good so far.
The configure scripts have been update since last time I played with
it, but as Romain pointed out, there is also an FSharp dependancy now.
You should be able to follow along from my notes.

https://github.com/RussellHaley/monodevelop/wiki

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"

New Mono/.Net ports team?

[Russell Haley]

Okay, so there has been more than one person that has expressed
interest in playing in this space, I'll bite.

I propose the following:
1) I'll put my notes together and get monodevelop running from github.
There are also some binary installations that I think we might be able
to get rid of.
2) Some one starts going over the porters handbook and lookg at
creating a new portcreate a new port pointing to github
3) Someone gets a.Net Core build running agian and then we create a
port for that, even if it includes a binary installation.

I also think it's important to start getting some .net ports in there
as well, like Pinta and...er... are there any others?

I'm willing to throw 8 hours a month at this. Probably more to get it started.

The one person who is notably absent from this conversation is the
only one among us with any commit rights: Mr. Romain Tartière.

Mr. Tartiere, are you willing to help us out?

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: maintaining ports and mono

[Russell Haley]

On Fri, Jun 17, 2016 at 2:59 PM, Aaron Havens <aa...@toomanymiles.net> wrote:
> Has any work started on a port for the .NET Core? I have looked at it and
> worked on getting the build instructions updated in GitHub but ran out of
> time. If someone is working on it I would be willing to see what they were
> working on and if I could chip in.

I had .net Core working many many moons ago but it required that you
build binaries (runtime?) on a Windows machine and then transfer them
over. I will check if I still have notes.

>
> Aaron
>
> On Fri, Jun 17, 2016 at 4:41 PM, Mathieu Prevot <mathieu.pre...@gmail.com>
> wrote:
>
>> 2016-06-17 9:08 GMT+02:00 Ivan Radovanovic <radovano...@gmail.com>:
>>
>> > On 06/16/2016 21:53, Mathieu Prevot napisa:
>> >
>> >>
>> >>
>> >> 2016-06-16 20:08 GMT+02:00 Russell Haley <russ.ha...@gmail.com
>> >> <mailto:russ.ha...@gmail.com>>:
>> >>
>> >> Hi Mathieu,
>> >>
>> >> I have expressed interest in helping maintain mono on FreeBSD but
>> have
>> >> moved away due to lack of interest and support. Currently someone
>> has
>> >> ported more recent versions of Mono (Romain I think?), but
>> MonoDevelop
>> >> is somewhat out of date. I had patches to build MonoDevelop with
>> >> Rolsyn but couldn't get the MonoDevelop github repos to work with
>> >> FreeBSD ports so I gave up after multiple requests for help on both
>> >> this mailing list and the FreeBSD forum.
>> >>
>> >> Other .Net things I'd like to see:
>> >> - Ivan had some patches for kqueue issues, he passed them on to me
>> but
>> >> again, I have moved away from .net on FreeBSD
>> >> - I would like to see a port of Pinta on FreeBSD
>> >> (https://pinta-project.com/pintaproject/pinta/) because gimp makes
>> me
>> >> want to throw my computer
>> >> - I once built and ran .Net Core and would like to see if that has
>> >> progressed, perhaps put together a FreeBSD port for it. The ultimate
>> >> goal in my mind is to update MonoDevelop to use .net Core
>> >> - Porting and testing asp.net <http://asp.net> and MVC to FreeBSD
>> >> - Testing the latest mono on FreeBSD CURRENT for ARM
>> >>
>> >> I had also at one point seen a possible business model helping
>> clients
>> >> get their .net software off of Windows to save $$$ and create
>> >> resalable appliances, but that idea died on the vine.
>> >>
>> >> Ultimately, there are so many development options on FreeBSD, I
>> moved
>> >> to something that was better supported (lua), but I really really
>> miss
>> >> that big beautiful framework. I guess there's always Java, or
>> Python,
>> >> or Ruby... :(
>> >>
>> >>
>> >> There are many points here, from .NET to IDEs and business.
>> >>
>> >> IMHO having .NET framework work is good, APS.NET <http://APS.NET> too.
>> >> Ultimately, having WPF too would be amazing. I'm planing to probe this
>> >> with the WPF team.
>> >> There is request on UserVoice (Microsoft interface for feedback and
>> >> features requests) of opening WPF sources, which is possible.
>> >> Microsoft recent policy is to make Windows the #1 platform for software
>> >> development, and have GNU tools work natively in Windows.
>> >> Their Azure platform now supports FreeBSD 10.3 VM.
>> >> Despite everything, they will want probably to make sure Windows still
>> >> have competitive advantages, making the WPF and ASP.net not that likely
>> >> to be available/ported/opened.
>> >>
>> >> Historically and to my knowledge, GNU/Linux was used for desktop at
>> >> Google, and FreeBSD rather for servers. Having FreeBSD a stronger dev
>> >> platform is questionable and might require a lot of energy/time/effort
>> >> from the community.
>> >>
>> >> Have you tried java/javaFX/openGL ?
>> >>
>> >> M
>> >>
>> >>
>> > Hi Mathieu,
>> >
>> > IMHO opinion there is no interest to have Mono running properly on
>> FreeBSD
>> > from either side. Original mono developers are even proud to say they
>> don't
>> > care about having it run on *BSD,
>> >
&

Re: maintaining ports and mono

[Russell Haley]

On Thu, Jun 16, 2016 at 11:08 AM, Russell Haley <russ.ha...@gmail.com> wrote:
> Hi Mathieu,
>
> I have expressed interest in helping maintain mono on FreeBSD but have
> moved away due to lack of interest and support. Currently someone has
> ported more recent versions of Mono (Romain I think?), but MonoDevelop
> is somewhat out of date. I had patches to build MonoDevelop with
> Rolsyn but couldn't get the MonoDevelop github repos to work with
> FreeBSD ports so I gave up after multiple requests for help on both
> this mailing list and the FreeBSD forum.

NOTE: The issue was with FreeBSD ports not allowing me to use multiple
repositories with specific tags or commits. It had nothing to do with
building MD.

> Other .Net things I'd like to see:
> - Ivan had some patches for kqueue issues, he passed them on to me but
> again, I have moved away from .net on FreeBSD
> - I would like to see a port of Pinta on FreeBSD
> (https://pinta-project.com/pintaproject/pinta/) because gimp makes me
> want to throw my computer
> - I once built and ran .Net Core and would like to see if that has
> progressed, perhaps put together a FreeBSD port for it. The ultimate
> goal in my mind is to update MonoDevelop to use .net Core
> - Porting and testing asp.net and MVC to FreeBSD
> - Testing the latest mono on FreeBSD CURRENT for ARM
>
> I had also at one point seen a possible business model helping clients
> get their .net software off of Windows to save $$$ and create
> resalable appliances, but that idea died on the vine.
>
> Ultimately, there are so many development options on FreeBSD, I moved
> to something that was better supported (lua), but I really really miss
> that big beautiful framework. I guess there's always Java, or Python,
> or Ruby... :(
>
>
> Cheers,
>
> Russ
>
>
> On Thu, Jun 16, 2016 at 9:07 AM, Mathieu Prevot
> <mathieu.pre...@gmail.com> wrote:
>> Hello,
>>
>> I would like to have an update about the community working on mono, and
>> maintaining the mono ports.
>>
>> This page was updated last in 2010:
>> http://www.mono-project.com/archived/monofreebsd/
>>
>> I was reading the last 10 month archives, it seems not very active.
>>
>> Who is interesting by running mono / roslyn / c# on FreeBSD ?
>> Who is doing c# development on any platform ?
>> What are you platforms ? (dev and execution) ? What is your fields of
>> activity ?
>> Who might be interested by c# development / execution on FreeBSD?
>>
>> Cheers
>> Mathieu
>> ___
>> 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: DNS is broken with mono

[Russell Haley]

This looks like a bug that should be pushed up to xmarian for inclusion in 
mono, not just the freebsd port. 

Russ

Sent from my BlackBerry 10 smartphone on the Koodo network.
  Original Message  
From: Mark Felder
Sent: Thursday, December 17, 2015 1:19 PM
To: m...@freebsd.org
Subject: DNS is broken with mono

Consider shipping this patch please. I've updated to 4.2.1.124 locally
and applied it without issue:

https://github.com/mono/mono/commit/932359f3d627da13408350b1172ceb63c30f6327.diff

because without it mono caches DNS entries *forever*.


-- 
Mark Felder
f...@feld.me
___
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"

SIGABRT when debugging

[Russell Haley]

Hey,

I am running MonoDevelopl 5.10 on Freebsd 10.2. When I try to debug this
one particular project and inspect one of my classes, the debugger crashes
with this:

Can't find custom attr constructor image:
/usr/home/rhaley/Projects/Objektiv2/Objektiv/ProtospeakServer/bin/Debug/Objektiv.dll
mtoken: 0x0a06
* Assertion at loader.c:1153, condition `!mono_loader_get_last_error ()'
not met

Stacktrace:


=
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=

/usr/local/bin/bash: line 1: 92150 Abort trap
/usr/local/bin/mono --debug --debugger-agent=transport=dt_socket,address=
127.0.0.1:23867
"/usr/home/rhaley/Projects/Objektiv2/Objektiv/ProtospeakServer/bin/Debug/ProtospeakServer.exe"

Press any key to continue...


Any input would be really helpful.
Thanks,
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: [MonoDevelop] Monodevelop 5.10

[Russell Haley]

Hey,

So a big win last night: after installing libgit2 from ports, was able to
build and run MOnoDevelop from MonoDevelop. I patched
file:///usr/home/rhaley/git/monodevelop/main/external/libgit2sharp/LibGit2Sharp/Core/NativeDllName.cs:

public const string Name = "/usr/local/lib/libgit2.so";

and had to make some other changes and remove an NFactory test.  I'll try
to reproduce it and create a patch some time later. Yay!

The REAL error I am trying to track down occurs when adding or removing a
new project to a solution. I get a general I/O error. I've tracked it down
to

main/src/core/MonoDevelop.Core/MonoDevelop.Core/FileService.cs

at line 572 a Syscall.rename is attempted and the error code is not handled
in the case statement. I am getting
Mono.Unix.Native.Errno.EXDEV (value 18)

Which I tracked down here:
http://docs.go-mono.com/index.aspx?link=F%3AMono.Unix.Native.Errno.EXDEV
"Cross-device link. A hard link to a file on another file system was
attempted."

Values are:

sourceFile"/tmp/tmp51cc4b8d.tmp"
destFile
"/usr/home/rhaley/Projects/Objektiv2/Objektiv/Objektiv/Objektiv.sln"

mount reveals the following:

tank/tmp on /tmp (zfs, local, nosuid, nfsv4acls)
tank/usr/home on /usr/home (zfs, local, nfsv4acls)
tank/usr/home/rhaley on /usr/home/rhaley (zfs, local, nfsv4acls)


however, I can manuall mv the file.

Any thoughts? I am guessing that the syscall.rename is doing something
other than an mv and zfs doesn't like it. Or conversly, zfs is doing
something funky and the mono wrapper library doesn't like it?

Anyway, all input welcome. Much thanks!

Russell


On Sat, Oct 31, 2015 at 1:03 AM, Robert N <sushihango...@outlook.com> wrote:

> Great to hear...
>
>
> --
> *From:* Russell Haley <russ.ha...@gmail.com>
> *Sent:* Friday, October 30, 2015 9:14 PM
> *To:* Robert N; monodevelop-l...@lists.ximian.com
> *Subject:* Re: [MonoDevelop] Monodevelop 5.10
>
> Hey Robert,
>
> Thanks for the great input. Someone on the freebsd-mono@ mailing list
> told me to build libgit2 from ports. With your information now everything
> makes sense.
>
> Thanks for the help!
>
> Russ
>
> On Fri, Oct 30, 2015 at 7:43 AM, Robert N <sushihango...@outlook.com>
> wrote:
>
>>
>> "Can anyone tell me more about "git2-3d5286e"? Where will I find it if
>> it does exist?"
>>
>>
>> Libgit2sharp version of the libgit2 native dll/shared object is
>> versioned with the git sha of the build.
>>
>>
>> 'Normally' you obtain the libgit2sharp CIL assembly with the
>> corresponding native Win32/64 dll (via the Window's nuget). There is also a
>> nuget (LibGit2Sharp.NativeBinaries) for Win32/64, OS-X and Linux libgit2
>> native binaries that can be used.
>>
>>
>> Since you are on BSD, I assume you would need to go to source and build
>> it: https://github.com/libgit2/libgit2 .
>>
>>
>>
>> -Robert
>> libgit2/libgit2 · GitHub <https://github.com/libgit2/libgit2>
>> github.com
>> libgit2 - The Library ... README.md libgit2 - the Git linkable library.
>> libgit2 is a portable, pure C implementation of the Git core methods
>> provided as a re-entrant ...
>>
>>
>>
>>
>>
>> --
>> *From:* monodevelop-list-boun...@lists.ximian.com <
>> monodevelop-list-boun...@lists.ximian.com> on behalf of Russell Haley <
>> russ.ha...@gmail.com>
>> *Sent:* Thursday, October 29, 2015 11:34 PM
>> *To:* m...@freebsd.org; monodevelop-l...@lists.ximian.com
>> *Subject:* [MonoDevelop] Monodevelop 5.10
>>
>> Hey I have been able to compile and run Monodevelop on FreeBSD 10.2. The
>> source is from git and I use the gmake method to build. I am trying to load
>> the MonoDevelop workspace IN MonoDevelop to debug some issues, but when
>> loading I am getting the following error:
>>
>> An unhandled exception has occured. Terminating MonoDevelop? True
>> System.TypeInitializationException: An exception was thrown by the type
>> initializer for LibGit2Sharp.Core.NativeMethods --->
>> System.DllNotFoundException: git2-3d5286e
>>   at (wrapper managed-to-native)
>> LibGit2Sharp.Core.NativeMethods:git_libgit2_init ()
>>   at LibGit2Sharp.Core.NativeMethods+LibraryLifetimeObject..ctor ()
>> [0x0] in :0
>>   at LibGit2Sharp.Core.NativeMethods..cctor () [0x0] in > unknown>:0
>>   --- End of inner exception stack trace ---
>>   at
>> LibGit2Sharp.Core.Proxy+c__AnonStoreyE.<>m__0
>> (LibGit2Sharp.Core.Handles.GitBuf buf) [0x0] in :0
>>   at LibGit2Sharp.Core.Proxy.ConvertPath (System.Func`2 

MonoDevelop 5.10 For FreeBSD 10.2

[Russell Haley]

Hello,

I just thought I'd send a progress update. Currently, I am stuck between
two different build methods for the "latest" MonoDevelop build. I have been
able to successfully build from github and create patches. However, the
existing ports Makefile (devel/monodevelop) uses the tarball method. My
github approach fails when attempting to build using the tarball method.

Cons of Github build:
- The github approach doesn't feel stable. The monodevelop branch naming in
git is all over the place and there are binaries in the externals download.

Cons of Tarball build:
- Have to figure out why it's failing too build. Seems to be issues with
LibGet2Sharp, again in the externals folder.

Other problems still outstanding:

1) kqueueEvent still causes crashes. An environment variable needs to be
set to use the managed filesystemwatcher
2) I have to build gtksharp20 twice. Once before the initial compile. Then
the Monodevelop build fails, I rebuild gtksharp20 and then Monodevelop
continues to build to success. WTF?
2.5) The build says it's for Linux. Boo!
3) I'm getting errors when trying to save the solution file. Not sure if
that's a MD bug, or a "me bug".

That's it. If anyone has any input, I'd love to have it.

Thanks,

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: MonoDevelop port

[Russell Haley]

Ah, you mean the chapter about Updating a Port that I somehow entirely
missed? fail sound effect

Thank you!
Russ

On Sat, Aug 29, 2015 at 1:28 AM, Mathieu Arnold m...@freebsd.org wrote:



 +--On 28 août 2015 22:02:50 -0700 Russell Haley russ.ha...@gmail.com
 wrote:
 | Hello,
 |
 | I would like to update the ports files for the MonoDevelop IDE to the
 | latest version. I have contacted the m...@freebsd.org mailing list about
 | my intentions with no response. What is the next step forward to submit
 an
 | update? Do I just create the shar and submit it via bugzilla?

 See chapter 10 of the porter's handbook[1]. Especially the part about *not*
 using shar to submit updates.

 1:
 https://www.freebsd.org/doc/en/books/porters-handbook/port-upgrading.html
 --
 Mathieu Arnold
___
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: Hello

[Russell Haley]

Okay, well I can make all the changes required and submit it to the
bugzilla for a 5.10 port.  Do you mind playing tester? Give me a a week and
I should have something for you.  If you follow the previous email, you can
build from the git repository I've got 5.10 running right now.

Hey Ivan, how are you? Did you ever get the kQueueWatcher fixed?

Russ

On Fri, Aug 28, 2015 at 11:39 PM, Jeff Sukow jdsu...@gmail.com wrote:


 Well, more patient? No, keep pushing. Lately there has been a lack of
 mono/.Net contribution in FreeBSD (been hanging around for 3 years or so).
 You have made it way further than I have with getting MonoDevelop to work.
 I'm glad you pushed as far as you did, now to help get it implemented
 I'm not sure how to do that either but I have some ideas.

 Do you watch BSDNow http://feeds.feedburner.com/BsdNowMobile? Good
 show. They are always asking about issues in the FreeBSD community. I think
 this issue fits. You could contact them feedb...@bsdnow.tv. I will try to
 hit up TJ their producer who I have has some contact with in the past...

 Of course, maybe someone will see you message on the m...@freebsd.org
 list and answer all your questions.

 Jeff


 On 08/29/15 01:06, Russell Haley wrote:

 Ah ha, I understand now. Sorry, I get a bit indignant when I don't get
 responses from mailing lists or forums. I should learn to be more patient.

 My email titled MonoDevelop 5.10 for FreeBSD 10.1 spells out the fixes
 needed (I'll forward it again after this).  But not how to implement them.
 I was just going through the porters handbook to figure out where to make
 the changes required to get this moving, but if you're up to speed, then it
 may be faster for you to do it. I'm cool either way. So steps forward:

 1)We need to update the Makefile to point to the latest sources. While
 Xmarian seems to publish tarballs, we could also consider moving to a git
 based fetch.
 2) The port and/or pkg install for mono needs to be updated to run
 mozroots (as per previous email). I'm just as cool with it being in the
 monodevelop installation, but Mike Hutchison from Xmarian recommended it go
 in the mono installation
 3) setenv MONO_MANAGED_WATCHER true needs to be set somewhere as there
 is still a bug in kevents. I set my in the MonoDevelop in the
 /usr/local/bin directory. This could be applied after installation or using
 a patch to the command that creates the script during the install target.
 maybe???
 4)  env SHELL=/usr/local/bin/bash needs to be added to either a make
 target or to the /scripts/configure.sh script specifically. This could be
 done using a patch
 5) The restore-packages target needs the following change:

 -nuget restore
 +mono
 /usr/home/rhaley/git/monodevelop/main/external/nuget-binary/NuGet.exe
 restore

 That would get us going.

 *Thoughts? *

 *Russ *

 On Fri, Aug 28, 2015 at 10:35 PM, Jeff Sukow jdsu...@gmail.com wrote:

 I have been on vacation for a bit and just saw your message on
 m...@freebsd.orgm...@freebsd.org. I figured I would hit you up
 directly vs the list...

 Where does MonoDevelop stand? I think I saw that you had/almost had it
 working...

 Jeff




___
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: Hello

[Russell Haley]

Hi, I was just corrected on the instructions to update the port according
to Porters Handbook chapter 10.

Russ

On Sat, Aug 29, 2015 at 12:09 AM, Russell Haley russ.ha...@gmail.com
wrote:

 Okay, well I can make all the changes required and submit it to the
 bugzilla for a 5.10 port.  Do you mind playing tester? Give me a a week and
 I should have something for you.  If you follow the previous email, you can
 build from the git repository I've got 5.10 running right now.

 Hey Ivan, how are you? Did you ever get the kQueueWatcher fixed?

 Russ

 On Fri, Aug 28, 2015 at 11:39 PM, Jeff Sukow jdsu...@gmail.com wrote:


 Well, more patient? No, keep pushing. Lately there has been a lack of
 mono/.Net contribution in FreeBSD (been hanging around for 3 years or so).
 You have made it way further than I have with getting MonoDevelop to work.
 I'm glad you pushed as far as you did, now to help get it implemented
 I'm not sure how to do that either but I have some ideas.

 Do you watch BSDNow http://feeds.feedburner.com/BsdNowMobile? Good
 show. They are always asking about issues in the FreeBSD community. I think
 this issue fits. You could contact them feedb...@bsdnow.tv. I will try
 to hit up TJ their producer who I have has some contact with in the past...

 Of course, maybe someone will see you message on the m...@freebsd.org
 list and answer all your questions.

 Jeff


 On 08/29/15 01:06, Russell Haley wrote:

 Ah ha, I understand now. Sorry, I get a bit indignant when I don't get
 responses from mailing lists or forums. I should learn to be more patient.

 My email titled MonoDevelop 5.10 for FreeBSD 10.1 spells out the fixes
 needed (I'll forward it again after this).  But not how to implement them.
 I was just going through the porters handbook to figure out where to make
 the changes required to get this moving, but if you're up to speed, then it
 may be faster for you to do it. I'm cool either way. So steps forward:

 1)We need to update the Makefile to point to the latest sources. While
 Xmarian seems to publish tarballs, we could also consider moving to a git
 based fetch.
 2) The port and/or pkg install for mono needs to be updated to run
 mozroots (as per previous email). I'm just as cool with it being in the
 monodevelop installation, but Mike Hutchison from Xmarian recommended it go
 in the mono installation
 3) setenv MONO_MANAGED_WATCHER true needs to be set somewhere as there
 is still a bug in kevents. I set my in the MonoDevelop in the
 /usr/local/bin directory. This could be applied after installation or using
 a patch to the command that creates the script during the install target.
 maybe???
 4)  env SHELL=/usr/local/bin/bash needs to be added to either a make
 target or to the /scripts/configure.sh script specifically. This could be
 done using a patch
 5) The restore-packages target needs the following change:

 -nuget restore
 +mono
 /usr/home/rhaley/git/monodevelop/main/external/nuget-binary/NuGet.exe
 restore

 That would get us going.

 *Thoughts? *

 *Russ *

 On Fri, Aug 28, 2015 at 10:35 PM, Jeff Sukow jdsu...@gmail.com wrote:

 I have been on vacation for a bit and just saw your message on
 m...@freebsd.orgm...@freebsd.org. I figured I would hit you up
 directly vs the list...

 Where does MonoDevelop stand? I think I saw that you had/almost had it
 working...

 Jeff





___
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: Mono Develop 5.0.1_1 Not Launching?

[Russell Haley]

Hi guys,

I didn't realize how old the monodevelop port was. I close the bug
with Xamarian as there is no way they would want to support something
almost 10 editions old.

I'll see if I can't figure out how to build it form source and update
the ports/packages tree.

Stay tuned.

Russ

On Fri, Jul 31, 2015 at 2:18 AM, Ivan Radovanovic radovano...@gmail.com wrote:
 On 07/31/15 07:34, Jeff Sukow napisa:

 I'm not sure what the mono/monodevelop project changed, but the prior
 version of MonoDevelop worked great on freeBSD. I upgraded and that was
 it.


 After the mono upgrade:

 I tried running an old package of monodevelop with the latest version of
 mono but that didn't work.


 http://pkg.freebsd.org/freebsd:10:x86:64/release_0/All/monodevelop-4.0.12.txz


 That led me to believe it was a mono framework change that affect this
 (have no proof or time to look into it).

 I still run a couple of websites (Asp.Net MVC) in freeBSD jails that
 work great but I'm worried about future .Net/mono support. I have
 reverted to Visual Studio for my builds.

 Jeff


 On 07/31/15 00:06, Russell Haley wrote:

 Yup, that's it. Thanks Jeff! First step to fixing it is identification...


 Russ

 Sent from my BlackBerry 10 smartphone on the Koodo network.
Original Message
 From: Jeff Sukow
 Sent: Thursday, July 30, 2015 10:03 PM
 To: Russell Haley; m...@freebsd.org
 Subject: Re: Mono Develop 5.0.1_1 Not Launching?

 Hi Russ,

 I'm running FreeBSD but I bet it is the same problem that I'm seeing.

 System.IO.FileNotFoundException: Could not load file or assembly
 'Mono.Cairo, Version=4.0.0.0, Culture=neutral,
 PublicKeyToken=0738eb9f132ed756' or one of its dependencies.


 From the cli, run 'monodevelop --no-redirect'




 INFO [2015-07-30 23:59:41Z]: Starting MonoDevelop 5.0.1
 INFO [2015-07-30 23:59:41Z]: Running on Mono 4.0.1 (tarball Sun Jul 5
 01:37:28 UTC 2015) (64-bit)
 INFO [2015-07-30 23:59:41Z]: Using GTK+ 2.24.28
 ERROR [2015-07-30 23:59:41Z]: MonoDevelop failed to start. Some of the
 assemblies required to run MonoDevelop (for example gtk-sharp)may not be
 properly installed in the GAC.
 System.Exception: Toolkit could not be loaded ---
 System.IO.FileNotFoundException: Could not load file or assembly
 'Mono.Cairo, Version=4.0.0.0, Culture=neutral,
 PublicKeyToken=0738eb9f132ed756' or one of its dependencies.
 File name: 'Mono.Cairo, Version=4.0.0.0, Culture=neutral,
 PublicKeyToken=0738eb9f132ed756'
 at System.Reflection.MonoCMethod.InternalInvoke (System.Object obj,
 System.Object[] parameters) [0x0] in filename unknown:0
 ...


 I haven't found a fix yet. Let me know if you find a solution.

 Jeff


 On 07/29/15 01:16, Russell Haley wrote:

 Hi there,

 I am trying to run Monodevelop on PC-BSD 10.1 release 25. First, ports
 wouldn't build any of the dependency files and then when I finally got
 it installed through the AppCafe using a binary, the application fails
 to start. There is no error or pop-up. It just fails to start.

 I'd really like to debug this and fix the issue. Is there any logging
 or any way I can figure out what the next step in debuggin this issue
 is?

 Thanks,

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


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


 Hi guys,

 I suspect what you are experiencing is rather some bug in mono 4.0 (or in
 FreeBSD port) - I am running at the moment MonoDevelop 5.7.1 and 6.0 beta
 (for D) on older version of mono (3.2.3 and 3.10) and everything works
 normally (although I always built MonoDevelop manually from their source,
 because port was out of date)

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

Re: Mono Develop 5.0.1_1 Not Launching?

[Russell Haley]

https://bugzilla.xamarin.com/show_bug.cgi?id=32656

Russ

On Thu, Jul 30, 2015 at 10:43 PM, Russell Haley russ.ha...@gmail.com wrote:
 Yes, it worked on a 10.0 VM I have but I have moved to bare metal thinking 
 everything would be the same. Surprise!

 I will try poking around the mono forums. I will keep you aprised of any 
 progress.

 Russ

 Sent from my BlackBerry 10 smartphone on the Koodo network.
   Original Message
 From: Jeff Sukow
 Sent: Thursday, July 30, 2015 10:34 PM
 To: Russell Haley; m...@freebsd.org
 Subject: Re: Mono Develop 5.0.1_1 Not Launching?

 I'm not sure what the mono/monodevelop project changed, but the prior
 version of MonoDevelop worked great on freeBSD. I upgraded and that was it.


 After the mono upgrade:

 I tried running an old package of monodevelop with the latest version of
 mono but that didn't work.

 http://pkg.freebsd.org/freebsd:10:x86:64/release_0/All/monodevelop-4.0.12.txz

 That led me to believe it was a mono framework change that affect this
 (have no proof or time to look into it).

 I still run a couple of websites (Asp.Net MVC) in freeBSD jails that
 work great but I'm worried about future .Net/mono support. I have
 reverted to Visual Studio for my builds.

 Jeff


 On 07/31/15 00:06, Russell Haley wrote:
 Yup, that's it. Thanks Jeff! First step to fixing it is identification...


 Russ

 Sent from my BlackBerry 10 smartphone on the Koodo network.
 Original Message
 From: Jeff Sukow
 Sent: Thursday, July 30, 2015 10:03 PM
 To: Russell Haley; m...@freebsd.org
 Subject: Re: Mono Develop 5.0.1_1 Not Launching?

 Hi Russ,

 I'm running FreeBSD but I bet it is the same problem that I'm seeing.

 System.IO.FileNotFoundException: Could not load file or assembly
 'Mono.Cairo, Version=4.0.0.0, Culture=neutral,
 PublicKeyToken=0738eb9f132ed756' or one of its dependencies.


From the cli, run 'monodevelop --no-redirect'



 INFO [2015-07-30 23:59:41Z]: Starting MonoDevelop 5.0.1
 INFO [2015-07-30 23:59:41Z]: Running on Mono 4.0.1 (tarball Sun Jul 5
 01:37:28 UTC 2015) (64-bit)
 INFO [2015-07-30 23:59:41Z]: Using GTK+ 2.24.28
 ERROR [2015-07-30 23:59:41Z]: MonoDevelop failed to start. Some of the
 assemblies required to run MonoDevelop (for example gtk-sharp)may not be
 properly installed in the GAC.
 System.Exception: Toolkit could not be loaded ---
 System.IO.FileNotFoundException: Could not load file or assembly
 'Mono.Cairo, Version=4.0.0.0, Culture=neutral,
 PublicKeyToken=0738eb9f132ed756' or one of its dependencies.
 File name: 'Mono.Cairo, Version=4.0.0.0, Culture=neutral,
 PublicKeyToken=0738eb9f132ed756'
 at System.Reflection.MonoCMethod.InternalInvoke (System.Object obj,
 System.Object[] parameters) [0x0] in filename unknown:0
 ...


 I haven't found a fix yet. Let me know if you find a solution.

 Jeff


 On 07/29/15 01:16, Russell Haley wrote:
 Hi there,

 I am trying to run Monodevelop on PC-BSD 10.1 release 25. First, ports
 wouldn't build any of the dependency files and then when I finally got
 it installed through the AppCafe using a binary, the application fails
 to start. There is no error or pop-up. It just fails to start.

 I'd really like to debug this and fix the issue. Is there any logging
 or any way I can figure out what the next step in debuggin this issue
 is?

 Thanks,

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


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

Mono Develop 5.0.1_1 Not Launching?

[Russell Haley]

Hi there,

I am trying to run Monodevelop on PC-BSD 10.1 release 25. First, ports
wouldn't build any of the dependency files and then when I finally got
it installed through the AppCafe using a binary, the application fails
to start. There is no error or pop-up. It just fails to start.

I'd really like to debug this and fix the issue. Is there any logging
or any way I can figure out what the next step in debuggin this issue
is?

Thanks,

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