FreeBSD Port Team: Volunteers needed

[janhenke]

Following the discussion on the chat, I am looking for volunteers to start a FreeBSD port team.

The purpose is to have a group of people working together on making coreclr working well on FreeBSD. This includes having more people with FreeBSD experience for reviewing patches and keeping an eye on PRs.

This issue is intended to discuss this idea and as a means to get into contact with each other. Also technical discussions about porting to FreeBSD are possible.

[xied75]

My experience with FreeBSD is making VM template for CloudStack, if this can qualify I would like to join the team and picking up this brilliant OS on the way. :)

[MattWhilden]

it's likely that you're already aware of this fork but if not it's worth checking out: https://github.com/ajensenwaud/coreclr

[MattWhilden]

Ugh. Was too fast on the comment button. Meant to attempt to summon @ajensenwaud to the thread.

[richlander]

To provide some more context ... to make this project awesome, we'd want a core group of folks that felt ownership and accountability (in a good way) to make the project happen. In turn, the .NET Core team would be more compelled to invest in CI infrastructure for FreeBSD as a first class citizen.

I like the idea of "port team". Some of very best people the CLR team has ever had were on the "X64 port team", 10+ years ago. They simply referred to themselves as "the port team". Not the type of folks you'd want to meet in (technical) dark allies ;)

[kangaroo]

While I don't have the time to contribute significant resources to this, given the familiarities with OS X, I'm happy to support with code review, direction and suggestions. Feel free to @kangaroo me on issues.

[ghuntley]

Long time FreeBSD user/supporter.

I'd be keen to help out from an administrative/sysadmin/marketing/documentation role where needed.

@qbit (OpenBSD), @josteink (FreeBSD), @Aesthetikx (FreeBSD), @ajensenwaud (FreeBSD) and @kangaroo (OSX) have been involved in previous work to bring CoreCLR to BSD.

[richlander]

These PRs are relevant to this discussion: https://github.com/dotnet/coreclr/pull/453, https://github.com/dotnet/coreclr/pull/470.

Nice to see that they have been merged.

[josteink]

I mostly tried to help out in @ajensenwaud's repo as a sort of "challenge accepted" short-term project.

As I don't have any up-to-date FreeBSD production-systems, I doubt I'm a good candidate for a longer term FreeBSD "port team". I do agree about the name though. It has a nice ring to it. Go for it!

That said, I appreciate being summoned and namedropped in dotnet/coreclr. That's almost going on my resume ;)

[ajensenwaud]

Hi all

Thanks Jostein, appreciate your help so far!

I am very keen to still assist with the porting and can also assist with test infrastructure, as required. How many are in for this?

Anders

On 18 Mar 2015, at 20:47, Jostein Kjønigsen notifications@github.com wrote:

I mostly tried to help out in @ajensenwaud's repo as a sort of "challenge accepted" short-term project.

As I don't have any up-to-date FreeBSD production-systems, I doubt I'm a good candidate for a longer term FreeBSD "port team". I do agree about the name though. It has a nice ring to it. Go for it!

That said, I appreciate being summoned and namedropped in dotnet/coreclr. That's almost going on my resume ;)

— Reply to this email directly or view it on GitHub.

[qbit]

Maybe we should make a wiki with status of each port, next steps and hurdles? OpenBSD is stuck until libunwind is ready (unless coreclr people can confirm that isn't a hard dep?).

[janvorli]

You can start porting without the libunwind. It is required for exception handling and GC. So as long as an application doesn't throw an exception or initiate a GC, everything should work without the libunwind. That's the way we were bringing up coreclr on Linux, the exception and GC support came quite recently.

[qbit]

:+1: - I will keep hacking away then!

[janhenke]

Hi folks,

I did not answer earlier as I want to know how big the feedback is. So far I am happy to see quite some people eager to join this project.

One question we should answer though is whether we want separate BSD teams (one for FreeBSD, one for OpenBSD, one for NetBSD) or one big BSD Port Team. My experience is limited to FreeBSD so far, which by my understanding is also the most often used of the different BSDs. But from what I read there seems quite some differences e.g. between OpenBSD and FreeBSD. So I have the tendency to limit the scope of the "FreeBSD Port Team" to FreeBSD only for the time being.

As @richlander proposed I would start a PR with a new Wiki page, describing the intention of the team, current members, agenda and way to participate. Currently I see as members:

• @janhenke
• @xied75
• @kangaroo
• @ghuntley
• @josteink
• @ajensenwaud

Also @qbit for OpenBSD. As a rought list of people interesting. Would be nice to get an answer to the FreeBSD <-> OpenBSD <-> NetBSD question and a ack/nak to team memebrship from everyone in the list. Then I can prepare the wiki page based on that outcome. Best reply until Friday noon UTC. :)

[ghuntley]

Alright, have created an Azure virtual machine (2 cores, 3.5GB memory) running FreeBSD 10.1-RELEASE which @josteink (and the others above) can call home for the foreseeable future whilst this issue is open. There's no NetBSD/OpenBSD images available in VMDepot, they were to magically appear then I would create another VMs for them as well.

Post a public ssh-key here and I will create you an account on portteam.cloudapp.net that has sudo access. Treat it with respect but don't be afraid to break it as it can be recreated as needed with a simple shell script.

[josteink]

I'm pretty busy these days, so I'm definitely not making any promises.

Anyway, I appreciate @ghuntley's initiative, and to show that, here's an SSH-key which means that in theory I can contribute should I ever get the time:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDMaGl5KG5P6fogg5B5tY9K26X2rx0d7MZg7x28TYxICZGK1aHCODylNy3WfnBFvQ5hRsrf0kCT2u36JUmgJzXTBx6Vc3AchrEOMJLRl3KvJfsbpANrymkW666sDgQW6PyqXSZ8f17vREGZrvFa41/dwAxMvxlQELwS8HRgNzY8GoZBP9BTm6qqZFozBf25nZLN/p3/X3w3GxW4USJutnH5T2oBJc3TqVnBFSgrsnHMMlmV+Xj0EMBy4di+JoNBm78hCDwt1QVMJ+NDOH224LuWgTlhOIRRDZfNee3qGHOB1llI78BZkc4x/9SJR8Fiv13pUINHc1zfLBzmB1PPLztLS2j8kOTh/ymr3Gc5+8iGgPX9ZideNLoTjD9necwQ+GhPdys/DkU8idYkCJnVPv6il+OOwk55xopyyfs11660xlAxJKdNy8D3lbSBSQQCGMRKAXhXxUsQr1R64fScZ0NejmpXwYR+9vybymKbiMWizxYQ8ap/KxOAs3znPWYpu2mjldkHqKd0Wc5z4/pgZS/m2KVHr95oy1Lx/O77x6QSy9h7Wu1xIcayV5R+wIvfz6BhQ7Hpr2Lu2MHpNQr2T4UzIodfSJ/LWp/xo37Fl7Bg9SntEC4NepSW9FFSJ0q48/CfcTJYMvLTvqGYn85Y8PnlrKsr295RiRyMiD3Ys4RNtw== jostein@irssi

Anyone else?

[josteink]

But from what I read there seems quite some differences e.g. between OpenBSD and FreeBSD.

From what I can tell, coreclr is pretty well abstracted and most (everything?) platform-specific goes through the Platform Abstraction Layer (PAL). If that builds cleanly, the build as a whole goes quite a bit further without too much trouble.

The PAL seems focused on underlying implementations rather than platform (see context.cpp): That checks if this architecture has BSD regs, PT regs, GREG-sets, what register-mapping etc.

Since I'm not sure if this is a problem at all, the best plan I can think of is to closely collaborate with the OpenBSD team (@qbit. anyone else?) and make sure the commited changes are mutually compatible.

If we later discover there's any substantial difference between FreeBSD and OpenBSD (or for instance Darwin), we might need more differentiation between the platforms than just saying "it's BSD", but let's save that for later, if for nothing else, just to get something going.

Alright, have created an Azure virtual machine ... Treat it with respect but don't be afraid to break it as it can be recreated as needed with a simple shell script.

If there's any global prerequisites/requirements will they be embedded in this script? According to the best of my knowledge @kangaroo's changes to support Darwin means clang3.7 (which of we will be cherry picking some) will be required to build this. Clang3.7 is not installed by default in FreeBSD 10.1, nor is it the default c-compiler.

It would be nice to have stuff like this (and other things we may add incrementally) available to everyone. Basically a public build-script for the machine. Sounds doable?

Which leads us to the next issue. Where do we work?

Since I doubt we'll be given commit rights into coreclr directly, or have PR's accepted before we have something to show for, should we have a place of sorts to work where we can commit incremental improvements? If so @ajensenwaud already has something going.

Should the work be based on that, or should we "start over", based on the current coreclr and just port the fixes we have so far?

[janhenke]

Thanks @ghuntley for the sponsoring of a porting machine. My SSH pub key is

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAEAQDEhh5lz6n4LN6S9McCGCrDrr+rZNtY4PqMc0aRK2hND14UrZo0tfO9nPY9rZMhnJ8GUdOWbcX79l1IkEMZTI62rPP4TL65hhLDQBD6WeXy4ib8VFFwOjjmHt8BOctAAsaWQOich3kLcigMCyvn7HA4YXTvqwfY2M5AK6yCrBcWdfAcAaSv45uX7XCwg4xWd/xrwV6aE+rFPsbZCEcb0s/5MQ+/exILHuLMXxgJfUC7a+3HkJLyUZWWLt1JfVAz67/xPe5Z2P+eYF98Xq21T2Ptl2p8HFDgV6OpqfOkVYJrjriUxd4OABFPzsh63qaOmtvTT5VAMED/Z7+5nt7TY+lCLpYTt8ncAoIXoqbu0St1E121ZChsw9Y2Ltuj3Z9FSP69x9jogREJnC5TyTZOxNjoIVKD4o6zFYlls9fqqXC8tynJT6vrn0GxfC9ew4lD/Nin+97vwbZAJZVHqLBNpcDLCMIR3PTgc7TsUDrTUce6vsigczbp/69rJPpRqkPZcKPXT5kokW8z4gEE1/iICsZouoaVcZNCRiLt+PJO2nUlnYJQ5dIWOCJivxSAmZgk7RyHsc8zvLunrhVnse4tF+pTfa8pc5BJ23E2VIeVUbtwqrd2IwcuRoJy0E8yz/lJrZAVffGcXSOty6MM3fd68QeekbZpy/lT5FN73O6oU4TFGy+yVL368yFXXIjcfSQSG0sMaZFGXHdJwfJnJEdZgxuOCqaA3SooC5pnuC5pOF2Mt95RgahYPFo4GMU17AhpOSrJBz1zo94FCHcKUdsF4P9+GE6810q/uw8QwLOniw8IoBUP04ikbBSa95C2Qx6t1ygujrAxb+LJTtJ/X619t2CuCrHnMf2Vh+UNWtRbjuof5QWbO0GI97zt46vJifJC0w8fmuvOxP7bDdEITSWztPTgXftt0X7EVYXnf6dg2mGE/JWOZEfnspvbuYetkqCI+dqVWfuVodHGZ8H7nJr2XfEwxs+NLSOZkLu9v0EuJF/lviFbmpedBhCmfiqjo8POWU7jZ1MFSYGxqGsXHbL2b2/xr92aRqo3ZkX9NsqA4ofINePeGwuFMTpDMq0VWWW6V2Y5E3t8Noje8TRnN9uIZjLjLhBSVcwcmQivwF+GF6yi/osHnSHXYvajFQdkYuxRUlUeOh0MJIPExOs//jZ65srTL5yjEx4zkBn6Qsy4EPUGdchB8gPsZEtRt8zMGCPuoCL+3G4UOrjAxnLbbxb/PrIqvWKeFgvYnFMZSONA3BAYiAHKy67EqWq1yYttCyLQUT9R2R+wfMLlgCeWP9YGBDY8ArxUpPQzJZPJtnIo0ny+Sd0JFemql07jT7KTKlNL0vKaOpiGpBP11D7KHbKtIxI3 JanHenke_BSD_Port_Team

@josteink the major difference that came to my mind is the focus of OpenBSD on security. I read they introduced their own special APIs to make software more secure and less vulnerable to security related bugs. Admittedly though I do not know any details and just read that.

If it works from a compatibility side, it certainly would be nice to see all three BSDs supported. Though I think at the beginning FreeBSD should be the priority in case something does not work on all three the same way. We could also organize it in a way that we all are the BSD Port Team and we assign people according to their preference to one or more "subteams", one for each BSD flavour.

Clang 3.7 is the current development IIRC. Clang 3.5 should be fine for the moment.

For the work, I was thinking about creating a Github "Organization", which could host our fork of the coreclr tree. @richlander how is your feeling about this? Also given that it would need a matching name with CoreCLR or dotnet in it. Maybe one member of the DotNet Foundation or Microsoft can set that up so it is guaranteed there also someone with administrative access at hand?

In any way I think it would be better to have central tree somewhere and not everybody having their private trees.

[josteink]

Clang 3.7 is the current development IIRC. Clang 3.5 should be fine for the moment.

Fair enough. We'll stay on 3.5 unless it causes issues.

I was thinking about creating a Github "Organization"

Seconding this. How about just "DotnetBSD"? What I'm not sure about is if we really do need central support for the DotNet Foundation or Microsoft to do this? What do we stand to gain? I'm not against it per se, but if it causes us delays or to lose momentum, that would be a shame.

But then again this issue has @richlander's attention so it might be a non-issue altogether.

In any way I think it would be better to have central tree somewhere and not everybody having their private trees.

Absolutely positively agreed.

[qbit]

Thanks @ghuntley !

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDNLvc26CLuM48MI0V6jQQVYZ5f3nMMPcX1iQPjfnHf9Wp9qlHaRUKYyveh4qcrfpVObvHfHbFZwyNQ+Ri7xfs0AFJLNiATKd50ditWT9FZ//xiGBuhpn2UwiYYTuCywkVuXbEdZXQesq9BrHhNn8ifmhPseKoMGOEil+eJGvxXnR3thiWGwuNSZ4D24brbVz3Hm/Fv9Gnbe3flui4jf73OxCyAT82NZ2FzbKCms5Q2QptwoAoDVTqgOar4lWX+vsZvs08EJ/HIRGTeHF/Yk9j8azJFHYxm6ao4eeQ9fHg5vXpsc/NX0VDm4ncfeuP/yVkxo7ZQC8yW+SkMlnj05CK9 qbit@slip.bold.daemon

Since I'm not sure if this is a problem at all, the best plan I can think of is to closely collaborate with the OpenBSD team (@qbit. anyone else?) and make sure the commited changes are mutually compatible.

This works for me. Also trying to recruit other OpenBSD devs.

the major difference that came to my mind is the focus of OpenBSD on security.

This isn't so much of an issue - most of the changes have "standard" counterparts that give you stern warnings when using them. The bigger difference will be availability of ports / required things (libunwind..) / location of installed ports.

[richlander]

My morning now, so time to reply.

I'd be happy to setup a coreclr-freebsd (or some similar name) repo as a fork of coreclr within the dotnet org and give the port team commit rights to it. To my mind, that provide the following:

• Unfettered development process (you control merging PRs).
• High discoverability of the repo (good to get more people involved).
• It's easy to setup the CLA and CI process on the repo.
• .NET Core team has access to the repo should that be needed.

PRing your changes to upstream on a regular basis would still be a good idea, but I think that is your plan, anyway.

I haven't asked anyone else's opinion on this, like @jkotas or @martinwoodward, but this is my proposal, and I think its a good one.

[jkotas]

I do not think we need a fork for the FreeBSD port. I expect that the changes for the FreeBSD port are going to non-controversial, and they can be submitted to master as they are made.

[kangaroo]

I agree with @jkotas -- I expect the FreeBSD port will be far less invasive than the OS X one was.

[richlander]

What do you think about @janhenke?

[janhenke]

My idea was a bit different. I thought about having a Port Team Organization and repo primarily to directly work in it. So I would no longer have my private janhenke/coreclr tree, but there would some dotnetbsdteam/coreclr, where I can commit code to and open feature branches. In that way someone else in the team can work together with me on a feature without needing PRs for every commit.

PRs would only be used once we think a certain feature is ready so I can merged into the main sources.

So I do not want to have "parallel tree" here, but I rather thought a working place where we can work cooperatively in feature branches until they are ready to be merged. So by definition all changes this tree has from upstream is consider unstable until a PR is opened.

I also would not accept any PR into that tree, all PRs should go directly into dotnet/coreclr. Also the CI is only needed on the main dotnet repo, expanding the current bot simply with FreeBSD/OpenBSD/NetBSD instances.

[kangaroo]

I'm pretty strongly against this direction, as I can see it spiraling out of control quickly. Having a separate tree per os? Per platform?

Is there a compelling reason for the primary maintainer to not just have it on their personal fork, and accept PRs themselves and push to coreclr as needed? You can also give individuals push access to your tree.

[janhenke]

More centralization and overview what is being done. I do agree that it seems a matter of which kind of work flow we want to establish with this team.

If the majority does not like the idea, it is fine too. As I said I just want us to agree one common procedure to organize the work flow and also somehow make it possible to create a team where we can recognize each other and issues that affect us more easily. In the end it would also be good to have one easy way to summon the team as a whole to an issue or PR if the opinion of a BSD porter is needed.

[kangaroo]

I'm not sure why we're focusing on centralization outside the canonical repo. MS has made it clear they'd be happy to upstream the patches, so lets just centralize here like for all other OSs.

In terms of having people recognize the issues, that seems like an easy candidate for a label?

[xied75]

Dear all,

Here is my ssh key:

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAyVtbcfl/UqP8syjU0aEKRxr3+EOkmFWMZcR/xTSDo5unAqp3QX6G0qEp7upcQdvIrr7YUAkS3JupxRuaTQtSpb/qbP+Zy9bN2ktaylLg2LycyT5NKS2V5gDrO98ekM7/fxIICX+JShbT54IUReE7IwC5HlW0QNLOV2lkCt5BQoYKukqfs3t2J5OCuUuitmVugJ0QPtBhOVWdtvk48YiTlmS+NTWCoF/O9SxnctKTW4Fi90jIpfO7s/Onw/dD6GF+cxBykQRXiW6ukj4HY+oqzCkHvwzgfsS2NfnLZCE2q9lYvwLKTfOWca5C+fKf5/JCn7D8X9I+m7wxWeEwXk2KQQ== xied75@gmail.com

Please somebody kindly advise what shall I need to do/read to prepare for this project: e.g. read about FreeBSD, LLVM, Clang, or the source code, etc.

Thanks all.

[ajensenwaud]

Great idea with the VM on Azure!

Here is my ssh key:

ssh-dss AAAAB3NzaC1kc3MAAACBAI0brhrRR9wMD9xm62O7MkQBpX2ASl0lGue4L+y2KFptZmfoioQt ZjPoBgjhKaG64uPH6V3MLzHGJn2iiSHHWxyA+2WHK1K3rQt6mEiIiU4N3PmI140wKJpuoyoCnKwScTGC P7VYT5nJH5yKTz/nRNmS1llFkfaSfSxEXhgT0MYHAAAAFQDG6uDfY9dUBFYiPPLtV/7yCG4+owAAAIEA iYVmRHXgBE6jiQ7GogQ/3ZqdoSu6bufyIN1kG7p9xEgFHeH8V+wPczb/RmS47X39qNraI3RcZ+zIaSrF s1M9uyhA1MIYGQ4P3kXS+H+4Wydq3SUCINfO7oGEgxsLCnDo6gdz1//HZqaWRiazM7mtpBzeO1rP0W5e o5BJyW2L1EsAAACAKgo7Kz2EL993yXFJJGFNWomZiYviwMCxSGF/zrjF3vJt8QrUJyvBfDosD6HUcfok qdUBd4ztOOPT6fHVE1Oa1lOCQe5731+sk1Zq5bA4BDnOmhfu/LZHAH6GctPOegb9U0QHcVrhzt6okMtB 8yiFrFiX/TiixXORHnQGt4HKQWs= aj@beastie.jensenwaud.com

On Fri, Mar 20, 2015 at 8:21 AM, Dong Xie notifications@github.com wrote:

Dear all,

Here is my ssh key:

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAyVtbcfl/UqP8syjU0aEKRxr3+EOkmFWMZcR/xTSDo5unAqp3QX6G0qEp7upcQdvIrr7YUAkS3JupxRuaTQtSpb/qbP+Zy9bN2ktaylLg2LycyT5NKS2V5gDrO98ekM7/fxIICX+JShbT54IUReE7IwC5HlW0QNLOV2lkCt5BQoYKukqfs3t2J5OCuUuitmVugJ0QPtBhOVWdtvk48YiTlmS+NTWCoF/O9SxnctKTW4Fi90jIpfO7s/Onw/dD6GF+cxBykQRXiW6ukj4HY+oqzCkHvwzgfsS2NfnLZCE2q9lYvwLKTfOWca5C+fKf5/JCn7D8X9I+m7wxWeEwXk2KQQ== xied75@gmail.com

Please somebody kindly advise what shall I need to do/read to prepare for this project: e.g. read about FreeBSD, LLVM, Clang, or the source code, etc.

Thanks all.

— Reply to this email directly or view it on GitHub https://github.com/dotnet/coreclr/issues/455#issuecomment-83763746.

[ajensenwaud]

On Fri, Mar 20, 2015 at 7:46 AM, Geoff Norton notifications@github.com wrote:

I'm not sure why we're focusing on centralization outside the canonical repo. MS has made it clear they'd be happy to upstream the patches, so lets just centralize here like for all other OSs.

In terms of having people recognize the issues, that seems like an easy candidate for a label?

Agree, but unless all of us get commit access to coreclr, we are not going to be able to consolidate our patches before submitting them to upstream?

For sake of separation, I suggest building out github.com/dotnetbsd unless we can all work out of the coreclr repo.

— Reply to this email directly or view it on GitHub https://github.com/dotnet/coreclr/issues/455#issuecomment-83756136.

[kangaroo]

Patches can be consolidated by anyone and everyone, thats kind of the point of git. See my work with @mikem8361 for reference. He's leading the LLDB efforts, and when I find issues with his PRs into dotnet/coreclr I submit a PR from kangaroo/coreclr -> mikem8361/coreclr. He integrates, and the PR reflects that.

[josteink]

My gut-reaction was similar to @ajensenwaud and @janhenke, in that I thought having a common workspace/repo/organization (but probably just repo) would be the best way to collaborate on this.

But with that said, I do have some experience with forked repos, and it it does come with some risks and costs, as mentioned by @jkotas and @kangaroo. A very basic example would be that 1. You need to work on your fork, and 2. at the same time ensure you keep up to date with all upstream patches. It doesn't sound like much, but it usually turns out to be a higher workload than you expected, especially when you need to prepare PRs back to mainline.

At the same time I also think it's worth noting the opinions of @kangaroo and similar people who has already contributed to coreclr. If they think a separate organization/repo sounds like overkill, we should respect that opinion as an experience-based one.

So I guess I've changed stance here.

If we go and try without a separate "official" BSD-repo, just prepare PRs into official coreclr and this later on proves to be suboptimal for our workflow or progress, surely we can amend that later and create a common repo/org as needed?

[janhenke]

IMHO PRs for ongoing development work are just too complicated. Real cooperation in development means I can commit straight away. A PR should only be used to merge the finished feature into the main tree.

I definitely see the point that any fork needs regular updates to stay in sync with the main tree. But that can be done rather easily or even by a bot.

I do think we should have something to make cooperation easy between the members and also something to create a group feeling. Also an easy way to exchange opinion about implementation details which might not be of interest to the general public outside the BSD folks.

[akoeplinger]

I agree with @janhenke that it'll be easier to have a separate repo for the BSD work where everyone in the port team can commit than to coordinate PRs between a bunch of people. That said, if @kangaroo and @jkotas are right and the port will be straight-forward it may not be worth creating it under the dotnet org and hooking up the cla bot etc.

So why not start simple and just give everyone access to @ajensenwaud's repo. It was already mentioned in a couple of places as the BSD bring up fork :smile:

The repo can be abandoned after the initial bring up is done and patches get less invasive.

[josteink]

Ok. So as far as I can tell, we all agree this should be doable, but we're just not in agreement about how things should be done.

That disagreement is clearly affecting momentum, and not in a good way. This thread went from lively to dead in about a week.

As far as I can tell, we seem to have two camps:

• One which wants to do their stuff as they see fit in private repos and just submit PRs directly to coreclr as it is, making coreclr the colleberative branch.
• Another which wants a non-official repo to work with which tracks mainline (and by proxy group one), where access to commits are easy, and where they can work on partial commits and fixes in a more colleberative fashion, until we have something working.

These two positions aren't really compromisable, but do we have to make that a problem? If we can't agree as a group, do we really need to?

Those who want to submit directly to coreclr can do so, and those who want a seperate repo can work together on that one. Let's just do something to keep moving and not kill this issue over something as mundane as this.

If this is the best agreement we can come up with, lets at least agree to that, so that we can move on.

If/when we can get confirmation that everyone is on this, I think it would be time to summon richlander to prepare a repo under the dotnet org, to avoid the "forkers" to flee too far from main base. No offense, @ajensenwaud :)

So guys... Are we good to go or not? Make some noise.

[janhenke]

@josteink I am with you.

@ghuntley What is the current status of the porter box you kindly offered. Are the keys posted here setup to access it?

[josteink]

@ghuntley Have you used our github names as user-names? I can't authenticate.

[ajensenwaud]

On Mon, Mar 23, 2015 at 6:02 AM, Jostein Kjønigsen <notifications@github.com

wrote:

Ok. So as far as I can tell, we all agree this should be doable, but we're just not in agreement about how things should be done.

If/when we can get confirmation that everyone is on this, I think it would be time to summon richlander to prepare a repo under the dotnet org, to avoid the "forkers" to flee to far from main base. No offense, @ajensenwaud https://github.com/ajensenwaud :)

So guys... Are we good to go or not? Make some noise.

Regardless of the approach, I am good to go. :) Even if we just fork the HEAD from dotnet/coreclr into our own branches and hand around individual patches, I am happy to go. Let's get the porting started!

— Reply to this email directly or view it on GitHub https://github.com/dotnet/coreclr/issues/455#issuecomment-84676722.

[josteink]

While we're waiting for @ghuntley...

I do currently have some monthly Azure credit I'm not using for anything, but I didn't find any pre-prepped FreeBSD images available, so I couldn't get anything up there.

Digital Ocean however does have some and they have a decent referral program: If you sign up with this link you'll get a $10 credit which is enough to run a 1-core machine with 1GB RAM and 30GB SSD for one month. If you just want a clean place to work for now until we get something "official" up, you could certainly do worse.

I'm using one of those myself, but with those specs it's obviously not a very shareable machine, hence the suggestion above.

[ghuntley]

.... indeed, sorry about that.

Accounts have been created for the following users as they have provided keys:

@janhenke, @josteink, @ajensenwaud & @qbit

# ssh username@portteam.cloudapp.net

portteam.cloudapp.net (104.209.35.155) ED25519 key fingerprint
is 76:84:42:88:49:ee:e5:48:c6:2c:02:c9:fd:9b:8d:da.

No password, key auth only. All users have the ability to su - directly to root as they all belong to wheel.

You all may do with the box as you desire (including adding new users) on the proviso that activities should be related to this issue/port. If you install a package via pkg or manually from ports please record/comment on the following gist https://gist.github.com/ghuntley/cd56a682b0dfb0c626e5 which will be used for tracking these sort of details.

[josteink]

Nice. Never mind my suggestion then. We've got some proper iron now :)

Thanks @ghuntley!

[qbit]

can you post the fingerprints for the server?

[ghuntley]

Yep, for sure - should have done that in the original post - have edited it.

@qbit:

portteam.cloudapp.net (104.209.35.155) ED25519 key fingerprint
is 76:84:42:88:49:ee:e5:48:c6:2c:02:c9:fd:9b:8d:da.

@janhenke has been provided the username/password to the Azure Management Portal of this machine and can reboot/shutdown/provision autonomously as needed.

[josteink]

If we're otherwise ready to go, I think (for those of use wanting it) setup a seperate collaberative repo to work with.

@richlander: Can you take care of this?

This repo can then also include a wiki where we share useful stuff, like build/development dependencies, how to cleanly resolve those, etc.

Since @ajensenwaud & me looked at this last time, I can see some new dependencies have been introduced (like libunwind, and LLDB for SOS), so I think it makes sense to minimize the effort spent into getting those ready, before we completely mess up ghuntley's Azure VM :)

[janhenke]

A short update. I spoke with @richlander on Gitter. FreeBSD will be added to the CI infrastructure once we manage to successfully build coreclr (it does not have to work perfectly, just build cleanly). I started looking into the next steps for that. See also issue dotnet/coreclr#547.

That should be extra motivation for use to get things going. Come guys, we can make this compile on FreeBSD.

[janhenke]

Once dotnet/coreclr#556 gets merged, configuration should work on FreeBSD. So we can now focus on the compiler errors (which start directly with the first file pal.h). Let us do this! We can make it! :+1:

[josteink]

Me, @kangaroo and @ajensenwaud did already resolve most (all?) of the compiler-errors in PAL.

Right now I'm trying to find the "correct" way to get a proper version of LLDB compiled for a clean FreeBSD system so that this can get documented and installed in our Azure VM (and replicated for a CI-environment).

@janhenke If you already got this handled, would you mind documenting it, and then I can verify the documentation by trying to apply it to our Azure VM?

Once that is done, I may start porting PAL-fixes as well.

[janhenke]

LLDB is also still an open point for me. I did try to compile it at some point, but in the end skipped that. For the moment it is also not the most important thing, as LLDB is only needed for the SOS LLDB-plugin. The config script outputs just a warning.

I suggest we first try to fix the PAL and get it compiling successfully. Then we can start looking into the finer details of LLDB and the remaining warnings.

[josteink]

Just checked and you're right: For now LLDB is just a warning, not a build-breaker so I'll leave that be until later.

As for PAL-fixes, unless you beat me to it, I'll try to see if I can't get (some of) those patches applied to the current coreclr master-branch and see if we can't get any further.

[emaste]

I work on LLDB for FreeBSD; the upstream source should build out of the box but will help sort out issues if not. Is there a specific version you need?