You have to have your version on PATH so build scrip can find it to avoid attempt to download it. (script checks if expected version is available).
I also set DotNetCoreSdkDir but I'm not sure if that is still needed. (I have my working environment for a while and I don't touch it)
Jumping ahead, make sure you have both 3.0 and 2.1 packages ready. I'm not sure if instructions were ever updated to reflect latest needed steps.
It seems like latest Arcade does not need LibGit2Sharp. Was that ported back to 3.0 branch @crummel ? That would avoid another annoying step.

Hey @am11 . I did take a look and buildbootstrapcli.sh will not work. That only rebuilds native bits and that is not sufficient in our case.
It seems like we lost old Wiki page with instructions how to update bootstrap cli in transition to runtime repo.  If I find some time I'll try to write some script later this week to automate that.

I put up back old page how to create bootstrap cli: https://github.com/wfurt/corefx/wiki/Building-.NET-Core-3.x-on-FreeBSD
As far as I know there is no good way how to recreate that only on FreeBSD. Best shot would probably be last published sdk for FreeBSD but unfortunately it is too old and not compatible with current build.
If we want to automate that @am11, we would need some dual OS setup and build coordinated between them. I'm wondering if wee should turn that to separate project/repo for now.
Once that is available, it should feed to source-build and rest should be pretty straight forward.
BTW did you have any luck progressing forward @FeodorFitsner ?

@wfurt, I took a look and it seems buildbootstrapcli.sh was really meant for this (build-from-very-scratch) use-case. It uses the linux-x64 tarball as a seed input then replaces the RID here, then overwrites linux native components (from tarball) with just-compiled native components. If I am missing something, please correct me. Otherwise, we can try to fix this script as, in addition to FreeBSD, it will benefit future OSes (like Solaris) and architectures (like MIPS).

@wfurt I didn't have a chance to work on this today, but I tried your suggestions yesterday and still was unable to run a simple web application with the same The specified framework 'Microsoft.AspNetCore.App', version '3.0.0' was not found. error. I must be doing something wrong. Is there any chance @jasonpugsley could modify the guide to include building ASP.NET Core SDK as well?

@FeodorFitsner I'll take a look at what is required to have ASP.NET Core working for FreeBSD. I don't think it has any native components so the quickest way might just be to grab the Linux artifacts and crossgen them for FreeBSD. I'll get back to you on that.
Now that the coreclr, corefx and core-setup repos have had master archived, where are code changes being committed? I've built 3.0.1-servicing, 3.1.0-preview1 and 3.1.0-rtm but they don't include any of the changes that have been made over the last few months for FreeBSD.
To build the 3.1.0 SDK, I needed SDKs for 3.0.100 and 3.1.100-preview1. I'll take a look soon at the new runtime repo and .NET 5 requirements because the typical build requirement for each published build has been an SDK from another recent build. I don't want 5 to move on so far that it requires 5.0.0-preview1 to build 5.0.0-preview3 and no one knows how to build preview1.
I haven't checked, but does source-build include support for building .NET 5 or will that come later?

As per the announcement, the branches are preserved with tags, e.g. https://github.com/dotnet/coreclr/tree/master/. The new development (post 3.1) is taking place in dotnet/runtime repo.

I don't think it has any native components

Actually there are (at least?) two mutually exclusive native dependencies in ASP.NET: libuv, used by Kestrel and SQLitePCLRaw.bundle_e_sqlite3  used by EFCore. The former is available via FreeBSD Ports (pkg install libuv). Related issue for the latter: https://github.com/ericsink/SQLitePCL.raw/issues/176.

the problem is that replacing native binaries is not sufficient and it only worked for new Linux distributions and architecture. But for example System.Diagnostic.Process (msbuild heavily needs) will try to get process list from /proc and /sys entries. What we need is instead is call to BSD interop code. Only way how to fix it is to also rebuild managed code and target FreeBSD so proper source code is pulled in for managed assemblies.

to pick up fixes for 3.x we will need to keep them as patches to source-build, fork repo or keep them as patches applied independently. (like port code)
For post 3.x life should be easier as everything runtime needs lives in single place.
We should try to stabilize that and possibly build runtime separately from the rest.
As far as I know SDK part does not have any direct platform dependencies and even Linux version should work with runtime.
For asp.net sockat backend is default AFAIK and libuv should not be necessary.
As far as I know it is fallback for legacy reasons (like we used to have libcurl for HTTP)

OK, thanks for the explanation. I was trying to avoid FreeBSD-only solution, but i think we cannot avoid it (each system has its own kind of containerization technologies, linux-lxc, freebsd-jail, solaris-hypervisor, windows-containers.. docker).
What we can do (as a prerequisite to buildbootstrapcli.sh) is to create a linux jail in FreeBSD, rebuild the managed components inside the linux jail's skel portion with freebsd-x64 RID. It will complement the rest of the bootstapping script (build native components), which we can run in host after existing the jail.
If it sounds like a good idea, i can work on the (non-interactive) script over the weekend, that will prepare jail-with-linux.

@FeodorFitsner  I won't have a chance to try rebuilding aspnet right now but see what you get from the crossgen'd linux files. Extract this archive into the same location as your dotnet binary, the contents end up in "shared" alongside "Microsoft.NETCore.App"
aspnetcore-runtime-3.0.0-freebsd-x64.tar.gz
With a vanilla 3.0.0 SDK a simple test fails because FileSystemWater isn't implemented on FreeBSD though @wfurt did submit a patch for that a while back.
See how you go.

@jasonpugsley Looks like I lost the access to my FreeBSD instance after turning it off/on. I will probably start doing the whole exercise according the your guide. Just to clarify, I have to put aspnetcore-runtime-3.0.0-freebsd-x64.tar.gz into the same directory where I unpack produced dotnet-sdk-3.0.100-freebsd-x64.tar.gz?

Microsoft.AspNetCore.App should be at same level as Microsoft.NETCore.App under dotnet/shared

cc @dseefeld for bootstrapping, I think we might be obsoleting buildbootstrapcli.sh soon.

Sorry, I was confused, that script is still valid for native bootstrapping.  Dan's new scripts are for toolset bootstrapping so they don't apply here.

I don't think Jail will work @am11. I did some experiments over the weekend and I get:
linux: pid 4425 (dotnet): syscall membarrier not implemented
pid 4425 (dotnet), jid 0, uid 0: exited on signal 11 (core dumped)

Documentation does mention that some beasts like systemd may not work. I think runtime is even worse as it depends on many special functions most user utilities do not need.
I was also thinking about the problem and I'm not aware of any good way how to create managed assemblies without having supported cli. However I did realized that I can spin up ad-hoc VM and treat is almost as "BSD only" as it does not depend on any external system  to do the build.
I started https://github.com/wfurt/freebsd-bootstrap-cli focused solely on creating bootstrap cli. It may be slow but if it is reliable and consistent it may serve the job.
It is not quite complete but it has core parts - building on freebsd & creating VM where assemblies can be built. It would be great if people can take a look and contribute feedback or code updates. I looked at my old notes and things have changed. It seems like @jasonpugsley may have most recent experience. My goal would be to take his notes (or any other feedback) and turn them to scripts.
Discussion about bootstrap cli can move there and we can keep this thread only for issues with source-build it self.

@wfurt, just a quick thought; .NET runtime is also compatible with OpenRC (init system for Alpine Linux), in addition to systemd. Maybe we can use Alpine (as it is super slim) in the jail, and we only need it for (AnyCPU) managed assemblies.

turn them to scripts.

this was exactly what i was thinking, 100% reproducible build on a public cloud is a far better investment compared to one-off, point in time, successful local build, which just works on my machine.

I don't think Jail will work @am11. I did some experiments over the weekend and I get:
linux: pid 4425 (dotnet): syscall membarrier not implemented
pid 4425 (dotnet), jid 0, uid 0: exited on signal 11 (core dumped)

FWIW, this should be quite trivial to implement.  Are you running 13-CURRENT?  Could you point me to the dotnet binary?

I'm running on 12.1 (VM) but that is easy to fix. You can get https://download.visualstudio.microsoft.com/download/pr/d731f991-8e68-4c7c-8ea0-fad5605b077a/49497b5420eecbd905158d86d738af64/dotnet-sdk-3.1.100-linux-x64.tar.gz and run dotnet --info. However that may not be only one issue as the code depends on /proc and /sys entries and that seems to be incomplete. But if we could get enough working to build, it could be path forward.

@junglebus' question was asked more than a month ago and has still not been answered. It would be very nice to get some more information about the .NET Core roadmap for FreeBSD, including the initial support for FreeBSD in the Azure Pipelines Agent, to see if Microsoft and the .NET Platform teams are currently working on it, or if everyone who is interested in .NET Core for FreeBSD should contribute to the dotnet/runtime repo, which is now the current starting point for this, I think.
I also noticed that the Workflow Guide already contains an entry for FreeBSD, but it's not mentioned elsewhere in the text. Maybe you could give some hint where to start there, because I think the build instructions in this thread are mostly outdated since the main dotnet repos have been moved to dotnet/runtime.

I do not believe there is a plan to support FreeBSD officially (ie., offer Microsoft support for it) but we do continue to want to support folks who are enthusiastic about working on it. @wfurt is our primary person here.
cc @jkotas

I thought I'd write to this thread as there's already a lot of potentially interested people on it and I haven't been able to find much discussion elsewhere.
As far as I know, FreeBSD is still not on the roadmap for 5.0.  Regardless, @wfurt and others have been committing FreeBSD changes to dotnet/runtime and they've done a great job. I had to spend several weeks catching up and building many interim releases but I finally got Preview 1 & 2 built and now I have no issue getting the master branch to regularly build on FreeBSD. That's a huge leap forward and I can see a great deal of effort went in to get the branch to that state.
It looks like work is underway to cross-compile the SDK from Linux so that the FreeBSD build can be added to the devops pipeline for frequent automated builds. That's great as the configuration for the build of runtime and installer (was core-sdk) is frequently updated to use quite recent prior builds and packages. I've been lucky so far as there have only been a few times where the dependencies have actually required a newer build, but it does involve a lot of work each time. I'll be happy when the builds and packages start getting published again.
I spent this weekend getting an updated build of SDK 3.1.103 together. I did incorporate the libinotify fix as well as build ASP.NET this time. For a non-trivial test I installed https://piranhacms.org/docs/basics/project-templates (had to muck around to get libe_sqlite3.so compiled and working) and the web app seemed to work OK. If there are people that want 3.1.103 then let me know and I'll upload the files and create some basic install instructions. I'm not going to update the build instructions for 3 as it would be a lot of work to reproduce the steps from scratch for someone else to follow (and no, I'm not making a port). I doubt I'll spend any more time focusing on 3 now and instead concentrate on 5.
My reason for building 3.1.103 was to attempt to build the azure-pipelines-agent. It was kinda tricky but I managed to get version 2.166.2 to build. I have no idea how to configure/use it though :grin: so I don't know if it works. I think the Linux agent has official support, so the cross-compiled 5.0 SDK may be the way forward for now. Is it worth trying to get a FreeBSD agent functioning for this or any other use on Azure Pipelines?
Finally, can anyone tell me if there are discussions happening regarding FreeBSD & .NET 5.0 anywhere because I don't know what it would be useful to look at next.

@jasonpugsley I'd love to play with SDK 3.1.103 (ironically for the same reason - running AppVeyor Build Agent on FreeBSD 😄) - could you share your build please. Thank you for your efforts!

FreeBSD is now part of CI validation. Hopefully that will last longer than previous attempt. That however does not produce consumable packages as there is hesitancy to do official builds for unofficial platform. That may be fixed in reasonably near future as some alternative plans are being discussed.
I'm in process of updating build instructions. Same strategy we use in CI can be used to produce runtime (and possibly SKD) and either be used directly or used as bootstrap CLI in runtime repo on FreeBSD or for complete source-build.
I still think there is value in getting 3.1 builds as that is current LTS and it would be nice IMHO to get parity. @am11 did some work and had Cirus setup to do build: https://github.com/am11/freebsd-bootstrap-cli/releases/tag/v3.0.0. Maybe that can be extended to produce images unless somebody has better idea or build options.
As far as the agent, my original PR got closed recently after waiting more than year for review. If there is interest I think best next step is to establish fork and work there instead of trying to get fixes to the main tree. I'd be happy to help and contribute my past experience. From runtime repo perspective it is unlikely we would use FreeBSD agent (and build on FreeBSD) any time soon.

Thank you for instrumenting FreeBSD cross-compilation, @wfurt. I am looking forward to the source-build part (https://github.com/dotnet/runtime/pull/34000#issuecomment-606863417) to get dotnet CLI + SDK for FreeBSD. It will also aid bringing up other Unix-based platforms, such as; NetBSD, SmartOS (https://github.com/dotnet/runtime/issues/34944), QNX and since so forth. We can document the formal procedure in BTOR porting guide for future reference so anyone can try/automate it.

Maybe that can be extended to produce images unless somebody has better idea or build options.

This is possible. In CirrusCI, we can either:

cross compile for FreeBSD on Ubuntu task and download artifacts in FreeBSD task to continue with next steps
or download the build artifacts directly from AzDO, when FreeBSD leg build succeed (using a webhook trigger, or some such)

i'd prefer this approach, @wfurt as today when I tried running./eng/common/cross/build-rootfs.sh freebsd12 x64

on Ubuntu 18.04 Azure VM, it threw these errors at the very end of pkg(1) compilation: pkg: repository meta /datadrive/projects/runtime/.tools/rootfs/x64/var/db/pkg/FreeBSD.meta has wrong version 2
repository FreeBSD has no meta file, using default settings
Fetching packagesite.txz: 100%    6 MiB 383.4kB/s    00:17
pkg: repository meta /datadrive/projects/runtime4/.tools/rootfs/x64/var/db/pkg/FreeBSD.meta has wrong version 2
pkg: Repository FreeBSD load error: meta cannot be loaded Success
Unable to open created repository FreeBSD
Unable to update repository FreeBSD
Error updating repositories!

as you have also noticed previously, catching up with upstream changes of FreeBSD's package manager (which is not very CI-friendly in terms of merciless breaking changes and whipping out old data from permalinks) in arcade is not scalable (unless we perform hacks like these).

You need to pick up build-rootfs.sh from https://raw.githubusercontent.com/dotnet/arcade/master/eng/common/cross/build-rootfs.sh as it did not bubble to runtime yet.

or actually use the container what CI uses. Since that is now part of verification, we will need to keep up functional. If we can incorporate container, it would bring all other dependencies runtime has or may have in the future.

Thanks. Using rootfs script from arcade repo worked (for now, until the next breaking change upstream. :)
Container approach is much better. CirrucCI is running kubernetes so containers are support.
Here is the CirrusCI build running with readymade container as AzDO:
ci job | .cirrus.yml
We can start extending this script with FreeBSD task and copy artifacts using push and pull approach using CI's local HTTP cache server (one instance of HTTP is running for the entire job, so tasks for different operating systems can access it).

That sounds good. I look at the outcome and it looks nice. We should perhaps move that discussion outside of  source-build. We can return here if there is actual problem with source-build.

Just a quick update, you can download the 3.1.103 SDK
The instructions need a bit more work but hopefully it's enough to start.

I haven't had much time this week but I did build 5.0 Preview 3 including ASP.NET. Files linked here.

Discussion about how anyone can build the product from source is pretty relevant to dotnet/source-build repository, and even matches the title of this issue.
Discussion about sharing just the binaries, without reproducible source script or steps how it was built is something which probably belong dontet/installer repo.

@jasonpugsley It works! 😃 Using your SDK 3.1 we've been able to build AppVeyor Build Agent to executables (yes, with -r freebsd-x64 option) without a single warning! And it works! I was able to hack a proof-of-concept FreeBSD 12.1 build image on GCP with that agent and run some builds: https://ci.appveyor.com/project/FeodorFitsner/freebsd-test/builds/32445332
The agent has quite a codebase: lots of deployment providers, internal Kestrel web server for API, it's communicating with AppVeyor via SignalR, etc. - I don't know yet which parts are not working, but essential functionality does: https://ci.appveyor.com/project/FeodorFitsner/freebsd-test/builds/32431289#L13
I'd love to capture your knowledge on how you do your builds and implement it in AppVeyor build, so we could always have a working SDK. We can use that image as a bootstrap. If you'd like to share your recipe I can sketch an appveyor.yml and we can continue working on that directly in some repo.
I'm so excited to work on that now as we have a working prototype of a real app! 🎉

@FeodorFitsner I finally went through the steps again and documented them
Build .NET SDK 3.1.103 for FreeBSD
Good luck!

@jasonpugsley Thank you! Will give it a try this week and let you know.

Building via @jasonpugsley guide fails in a FreeBSD 11.3 jail with
Failed to create CoreCLR, HRESULT: 0x8007001F
ERROR: An error occurred in /usr/home/build/src/coreclr/.dotnet/dotnet restore /nologo /verbosity:minimal /clp:Summary /m /home/build/src/coreclr/src/.nuget/optdata/optdata.csproj /p:__BuildArch=x64 /p:__BuildType=Release /p:__BuildOS=FreeBSD /nodeReuse:false /p:RestoreDuringBuild=true /v:detailed /p:PortableBuild=false /p:OfficialBuildId=20200218.3 /p:ContinuousIntegrationBuild=true /p:PortableBuild=true. Check logs under /home/build/src/coreclr.
I does not generate any logs either.
The best I can tell (from someone else with a build similar issue on MacOSX) is that its an mlock() issue or having only 18G free of RAM when ZFS cache is eating over 320G might be an issue

I haven't used jails but I have come across the mlock issue myself on another freebsd based system so it could be what's going on here. The failure occurred when it allocated 4096 bytes and then tried to mlock() that memory, it failed with EPERM. I didn't get a chance to look any further.
Everything I've done here has been using a vanilla FreeBSD 11.3 install in a fully virtualised VM.

@wfurt what do you all need to make FreeBSD an official platform at this point? There's no possible way I can bring this current process into ports. And that is the direction that I would like to take things on the FreeBSD side.

I'm afraid some of it is not technical. We would need to convince product owners it is worth it. It is not just the code base but also infrastructure and support commitments. Adding CI leg to prevent build regressions was best I could do so far.
We've been progressing on independent build with @am11 with the intention to produce rolling builds, packages and test runs. I think it is unlikely there will be official FreeBSD support in .NET 5 so I was thinking about some form of community effort.
I think targeting ports is right direction. Maybe we can brainstorm via chat or call what would need to be done for the ports, and perhaps bring specific issues back here. The source-build exist with the intention that distro owners could incorporate it to their package builds and be independent of MS binaries.

Totally aware of the political aspects of it, which is what I'm asking about. Unfortunately I'm also painfully well aware that's going to be an uphill battle to an extent due to the current state of the (Microsoft owned and maintained) FreeBSD Azure images.
The problem here is that there is absolutely no possible way the current method can be put into ports due to the SDK binary elements that are still required. That creates a hard blocking legal issue.
Definitely up for some brainstorming to see what we can do to sell the product owners on it. What's the best platform for you?

The problem here is that there is absolutely no possible way the current method can be put into ports due to the SDK binary elements that are still required. That creates a hard blocking legal issue.

I am a Linux guy, so maybe I am missing something, but we have similar restrictions in Free-focused linux distributions like Fedora. source-build has let us work around all that:

We used an initial set of prebuilt (compilers, runtime, packages) binaries in our packages. This is similar to bootstrapping any other language. I hope even FreeBSD allows for that.

We then used the prebuilt binaires to build source-build within Fedora.

Then we threw away the prebuilt binaires and used the just-built source-build to bulid source-build again.

Now we have a working .NET Core SDK (based on source-build) which works without requiring prebuilt SDK (or other) binaries. End users (folks consuming Fedora packages) still need to fetch things from nuget to build their own applications, of course.
Is a workflow like this suitable for FreeBSD ports? If not, can you help us understand what else source-build needs to do?

@omajid this is a false equivalence because you have legally available, legitimate SDK binaries direct from Microsoft. FreeBSD does not any longer and has no way to bootstrap. A random OneDrive link to retracted binaries is not a legitimate source. The only way any of this can legally go into ports in any form (which is still going to be months of arguing) is with official SDK blobs either 'officially supported' or 'as-is' officially published by Microsoft.

as-is may be doable via https://github.com/dotnet/runtime/issues/35609

has no way to bootstrap.

Here are the self-dependent bootstrapping steps for 5.0 in the form of shell script, which are running on public CI: https://github.com/wfurt/freebsd-bootstrap-cli/blob/428905/.cirrus.yml.
We required the real Linux VM because Linux emulation on FreeBSD failed to execute some syscalls made by dotnet(1) (membarrier etc.), among other mechanical glitches like missing ca certificates in base chroot to make the initial curl call by shell scripts in dotnet/runtime (FreeBSD bugzilla has issues opened for these two).
I think if Microsoft's CI in this repo (or dotnet/runtime && dotnet/sdk?) can ensure that these bootstrapping steps are maintained, any (not officially supported) platforms can reliably depend on them. The chances of these steps getting staled/broken are approximately once a week, whenever PRs from app/dotnet-maestro are merged in dotnet/sdk or dotnet/runtime repos.

Thanks, @rootwyrm . I didn't realize that the issues were about the source of the bootstrap SDK (and other binaries).
For my own understanding, is there any guidance on how "authoritative" that source needs to be? Would it need to be Microsoft, the company? Could it be a developer working on .NET but paid by Microsoft? What if it's a developer who works on .NET but paid by $ANOTHER_COMPANY? What about a person who contribute to .NET on their own free time?

as-is may be doable via dotnet/runtime#35609

@wfurt I'll have to take a look; if they're actually providing the seed binaries required to bootstrap. Those are the hard blockers. 'Anything goes' NuGet is already in the tree (albeit broken as hell, and not likely to be fixed before 2022 at this rate.) Once we have either seed or SDK binaries (either-or) it's one of those 'hopefully a few days' things as opposed to 'check back in 6 months.' Aside from actually getting it committed, or finding those few days.

For my own understanding, is there any guidance on how "authoritative" that source needs to be? Would it need to be Microsoft, the company? Could it be a developer working on .NET but paid by Microsoft? What if it's a developer who works on .NET but paid by $ANOTHER_COMPANY? What about a person who contribute to .NET on their own free time?

For legal and security reasons, it always MUST be the original author, followed by an explicitly or implicitly authorized mirror as an optional alternate. Any other source is an automatic 'no-no' because there is no possible way to ascertain whether or not there are modifications or it is in compliance with the code's licensing.
Using Mono as an example, Mono is MIT licensed. This means that FreeBSD can redistribute binary packages of it (so a non-RESTRICTED port.) However, I cannot just re-host a tarball that the Mono team retracted and call it good.  It has to originate from the official main distribution site, and be confirmed against the MD5/SHA/signature of the original file, and patches must apply against those files.
In the case of the SDK and/or seed binaries (specifically referring to dotnet.microsoft.com/download/), the license is not explicitly open and redistribution is clearly prohibited, similar to portions of Java. And this extends to any linked in components (e.g. CoreLib, assemblies, etcetera.) These essentially taint the port's license.
The other problem at this point is that the entire method as it sits just cannot work within the ports infrastructure. (Which I'm sure @wfurt is thrilled to hear.) Things like "set your system timezone to UTC" and "requires python27" are automatic deal-breakers, even before we get to "download things in the middle of the build" (which is a whole thing.) Especially python27.

Why don't you contact me at me GH address tweinfurt at yahoo. We can find channel to have conversation and bring back specific issues @rootwyrm

Thanks @rootwyrm , but now I have another set of questions. Thanks again for putting up with me.

Using Mono as an example, Mono is MIT licensed. This means that FreeBSD can redistribute binary packages of it (so a non-RESTRICTED port.) However, I cannot just re-host a tarball that the Mono team retracted and call it good.

This is about a binary SDK release, right?

 It has to originate from the official main distribution site, and be confirmed against the MD5/SHA/signature of the original file, and patches must apply against those files.

But this is about source tarball? If so, then this might be another action item for source-build. Right now, source-build does not publish releases. They tag things in the git tree. That's not acceptable, is it? Or would signed git tags be acceptable?

In the case of the SDK and/or seed binaries (specifically referring to dotnet.microsoft.com/download/), the license is not explicitly open and redistribution is clearly prohibited, similar to portions of Java.

Hm. I (on behalf of Red Hat) have worked with folks at Microsoft to fix this this. My understanding was everything is explicitly open source for non-Windows now. For example, I just downloaded https://dotnet.microsoft.com/download/dotnet-core/thank-you/sdk-3.1.300-linux-x64-binaries and checked out the LICENSE and ThirdPartyNotices.txt files. Every license looked open source to me.
Do you see anything different on your end? I think we can/should fix those issues.

And this extends to any linked in components (e.g. CoreLib, assemblies, etcetera.) These essentially taint the port's license.

Can you enumerate these? I am not sure these issues still exist. Source-build has (or at least was supposed to) fix them all. If there's stuff here that's not open source, that would affect us in Fedora as well, which only packages open source code.

Things like ... "requires python27" are automatic deal-breakers

Can you please file bugs if python 3 doesn't work? I am running without python 2 here. Everything (including coreclr) should support python3 out of the box now. For example:

https://github.com/dotnet/coreclr/pull/19043
https://github.com/dotnet/coreclr/pull/21532
https://github.com/dotnet/coreclr/pull/22145

~I haven't used jails but I have come across the mlock issue myself on another freebsd based system so it could be what's going on here. The failure occurred when it allocated 4096 bytes and then tried to mlock() that memory mprotect that memory with PROT_NONE, it failed with EPERM EACCESS. I didn't get a chance to look any further.~ Sorry, ignore all that. It doesn't apply to vanilla FreeBSD.
Everything I've done here has been using a vanilla FreeBSD 11.3 install in a fully virtualised VM.

took me a month but I found free time (aka 10 minutes of not being lazy) to get a FreeBSD VM setup under Hyper-V. builds perfectly!
Thanks for all the work!

dotNET preview 5 builds (after linux bootstrap) on FreeBSD
Totally off topic bit:
I also took a deep dive on my issue with the dotnet binary failing in a jail.
It was not jail related. It was actually because of an issue that is isolated to only FreeNAS as it was fixed more than a year ago upstream on FreeBSD
https://jira.ixsystems.com/browse/NAS-106193
https://docs.freebsd.org/cgi/getmsg.cgi?fetch=145846+0+archive/2019/svn-src-head/20190519.svn-src-head
Summary: SDK that now builds under FreeBSD (after linux bootstrap). If you want your binary to work in FreeNAS you will have to wait until the upstream solution is merged.

@jasonpugsley any tips for getting aspnetcore to build on dotnet 5 previews? Nuget seems to be mismatching the runtime I built

Salve, scusate dove posso scaricare il file dotnet-runtime-3.1.3-freebsd-x64.tar.gz

Wow, that is a lot of intensive Q/A.  Super!
I understand that we can run .NET in a Linux container environment under Bhyve, with FreeBSD - perhaps it might serve to support some web app tests, at least? I'm certainly interested in helping out this porting process, for .NET support on FreeBSD. Albeit I wonder if I might be in a little over my depth, with the syscall concerns and then so many moving parts in the build process.
I wonder, Are there any ideas for how the build process might change in .NET 6? I understand that there's .NET MAUI support being proposed for that that platform release, candidly not familiar with much else about that SDK major version however. (Off topic, wondering if there will be any changes in Entity Framework, circa then)
For all the documentation so far, will try to take a look at it once the yearly port upgrade finishes. Personally, I might also be interested in seeing if there may be a way to build it with pkgsrc, on NetBSD, FreeBSD, or other OS (Linux w/ pkgsrc?).
Candidly, I'm still getting familiar with VS 2019 here. I think this looks like a really great platform though, very accessible!

.NET 5 bootstraps/crossbuilds from Linux to FreeBSD with minor changes. That package can be used for further building of .NET 5 releases natively under FreeBSD with different minor changes it also produces working native FreeBSD binaries of programs built with -r freebsd-x64. Some require major changes like Azure Pipelines Agent others build with no changes like jellyfin.
.NET 6 preview bootstraps/crossbuilds from Linux to FreeBSD with minor changes. Currently that package is unable to build natively under FreeBSD

.NET 5 bootstraps/crossbuilds from Linux to FreeBSD with minor changes. That package can be used for further building of .NET 5 releases natively under FreeBSD with different minor changes it also produces working native FreeBSD binaries of programs built with -r freebsd-x64. Some require major changes like Azure Pipelines Agent others build with no changes like jellyfin.
.NET 6 preview bootstraps/crossbuilds from Linux to FreeBSD with minor changes. Currently that package is unable to build natively under FreeBSD

Stupid question - is this somewhere documented, how to (cross)build .NET 5 for FreeBSD?

I look at runtime docs @sec and some is still very old written by @josteink years ago. The official build is using docker image to make it easier but once and create it locally using build-rootfs.sh and esentially run build with -cross -os FreeBSD -clang9 I can dig out more details about various parts if anybody wants to put some effort to docs.
I'm also going to post some more notes to main runtime issue

https://github.com/Thefrank/dotnet-freebsd-crossbuild ? That is what I use to get started
That script should cover building runtime, aspnetcore, and packaging into installer
TODO: Using said product natively under FreeBSD. It requires patches and/or work arounds that I have no been able to condense into a script yet.
hattip: @ta264

@wfurt @Thefrank
Using https://github.com/Thefrank/dotnet-freebsd-crossbuild I was able to compile .NET 5 on fresh Linux machine (there was one error with path to patch, download problems, nothing major), but in the end I got the SDK. I took the packages from both aspnetcore and runtime artifacts dir, SDK from installer artifacts, put those on fresh FreeBSD 13 machine (according to https://github.com/jasonpugsley/installer/wiki/.NET-Core-3.1.103-for-FreeBSD) and tried, almost worked:
/usr/home/sec/dotnet5/sdk/5.0.202/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(99,5): error NETSDK1084: There is no application host available for the specified RuntimeIdentifier 'freebsd-x64'.
What I missed?
Worth to mention that SDK from https://github.com/jasonpugsley/installer/wiki/.NET-5.0-Preview-3-for-FreeBSD works fine on the same BSD box (simple MVC webapp with EF Core + Sqlite).
sec@hyperv:~ % dotnet --info
.NET SDK (reflecting any global.json):
 Version:   5.0.202
 Commit:    db7cc87d51

Runtime Environment:
 OS Name:     FreeBSD
 OS Version:  13
 OS Platform: FreeBSD
 RID:         freebsd-x64
 Base Path:   /usr/home/sec/dotnet5/sdk/5.0.202/

Host (useful for support):
  Version: 5.0.5
  Commit:  2f740adc14

.NET SDKs installed:
  5.0.202 [/usr/home/sec/dotnet5/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 5.0.5 [/usr/home/sec/dotnet5/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 5.0.5 [/usr/home/sec/dotnet5/shared/Microsoft.NETCore.App]

Output from 5 preview build has diffrent RID: freebsd.13-x64, but according to RuntimeIdentifierGraph.json this should be fine, so my best bet is that something minor is missing.
Another stupid questions - assuming SDK will work - how to execute test suite for it on BSD box?

@sec the missing host thing likely came from one of the sed hacks in the installer step failing.
In your specific case this should resolve it:
sed -i.ORI 's/osx-x64/osx-x64;freebsd-x64/' /usr/home/sec/dotnet5/sdk/5.0.202/Microsoft.NETCoreSdk.BundledVersions.props
do you have the build error(s) that were generated? That should help me figure out what went wrong.
As for the RID being different, the preview ones patch in full FreeBSD version numbers...which, because FreeBSD has a nice symbol versioning feature, really should be used.

@Thefrank Thanks, that replace did the thing - I was greping json files and missed that one :)
So now I have .NET 5.0.5 working on FreeBSD, "yay" :)
The errors during crossbuild on Linxu machine were:

the were problems with downloading "https://dotnetcli.blob.core.windows.net/dotnet/Sdk/5.0.202-servicing.21201.17/dotnet-toolset-internal-5.0.202-servicing.21201.17.zip" - I was getting connection reset, timeouts, etc - in the end I downloaded that by hand and put into correct directory
invalid path to patches/installer/0001-freebsd-support.patch in script (it's directly in patches, typo :)

As for the sed, I saw it's included in your build script - I will run the whole thing from start and check why it failed - maybe I took the file from wrong directory or something - is there any "packer" to grab all the needed output and produce a nice set of "dotnet" things or just a simple cp will to the trick (just like I did by hand, dunno know if I missed anything, though) ?
And what would be the next step in getting this to compile on bsd box?
And can't this output be used to help in getting bsd build "somewhere" "semi-official"? :)
And if could point me to some direction on how to run test suite for .net/aspnetcore directly on bsd box - I assume I can use the build I just produced?

download errors

Those seem pretty random but I always assumed they were on my end but I guess other people get those too. No idea what is going on there :(

typo

I will get that fixed ASAP!
The sed lines in the installer segment manually patch in support for FreeBSD into the SDK when it gets bundled. Something may have changed in the files to cause one or both of those to fail hence the missing support.
As for a packer: the installer repo is what creates a full working, bundled dotNET SDK. Check in ./installer/artifacts and there should be an SDK in both tar.gz and zip
For compiling under FreeBSD take a look the work being done here: https://github.com/dotnet/runtime/issues/14537

download errors

Those seem pretty random but I always assumed they were on my end but I guess other people get those too. No idea what is going on there :(

typo

I will get that fixed ASAP!

For me git -C installer apply ../patches/0001-freebsd-support.patch worked

The sed lines in the installer segment manually patch in support for FreeBSD into the SDK when it gets bundled. Something may have changed in the files to cause one or both of those to fail hence the missing support.

I will check the logs after build complete and check why it's not there.

As for a packer: the installer repo is what creates a full working, bundled dotNET SDK. Check in ./installer/artifacts and there should be an SDK in both tar.gz and zip

Yes I saw those, but those don't include the nuget packages that needs to be put into local feed (or I just missed them).

For compiling under FreeBSD take a look the work being done here: dotnet/runtime#14537

I'm been reading/writing in that thread for the last 5 years :) it's a bit out-of-date now, as building chain changed from what I saw and I'm trying to get back into that, but either I'm can't search for docs or just can't find a clean howto the whole process works :) I saw https://github.com/wfurt/freebsd-bootstrap-cli which I plan to check in coming days

oh! if you use Azure DevOP you can checkout https://github.com/Servarr/dotnet-bsd as an Azure version of Shell script.
The releases also include the nuget packages that are required for either building under FreeBSD or building to FreeBSD. The same sed script that I gave you for your SDK error will add support for FreeBSD to any working SDK as long as you provide the nuget packages in your own feed.
The advantage is that it uses all the nice Azure reporting and it might be more familiar to people. Anything that requires native testing will still require a FreeBSD VM but all of the building can be done under your preferred OS.

@Thefrank I also saw this, thanks.
My point is that, at the moment I did the cross-compile under Linux to FreeBSD, prepared nuget packages from aspnetcore and runtimes artifcats by hand, took sdk from artifacts, put this into bsd box and it's working fine - thanks to your scripts :)
Question to that part was, is there an archive with those nuget's produced by installer, as I only saw SDK and runtime (I assume they are pushed later into official feed, but for FreeBSD we're not there yet, that's why we need to have them locally with correct RID's etc inside, right?).
Now what I would like to know next, is how to start building native this under bsd box and/or run tests under bsd box, to see what is failing etc. That's the same discussion as in https://github.com/dotnet/runtime/issues/14537 - just trying to read/find the correct docs about building process of .net core etc.

SDKs don't include NuGet packages. dotNET/NuGet gets those packages during restore by looking both locally and from feeds provided to it.
for building programs you will need the following packages:
from runtime:
Microsoft.NETCore.App.Host.freebsd-x<IP_ADDRESS>.nupkg
Microsoft.NETCore.App.Runtime.freebsd-x<IP_ADDRESS>.nupkg

and from ASPNetCore:
Microsoft.AspNetCore.App.Runtime.freebsd-x<IP_ADDRESS>.nupkg

as for native builds you will need a seed SDK (like the one you just built) and various patches different patches to cover things like bad linker detection, crossgen2 issues, and inconsistent version numbering. jasonpugsley (https://github.com/dotnet/runtime/issues/14537#issuecomment-826650762) has done a good job of combining the patches needed to build runtime natively. it should also pass all of the tests...you may have to install ncurses for the console tests to pass...that might also require a patch too...its been  a while :(
ASPNetCore requires fewer patches but sadly has test failures. On the plus they mostly seem seem libuv related and that has been dropped for dotNET6+
Finally, wfurt is looking for volunteers! https://github.com/dotnet/runtime/issues/14537#issuecomment-824248881

Hey,
It's betting more and more clear :) I think I just need to read/find more docs etc., but that's already good start.
For the things that were failing - here's a patch for 2 lines that fixes both errors I've had https://gist.github.com/sec/ce64d033399ad96a2617d4c358b1adba
Again thanks for help @Thefrank :)
If I'm not wrong, the same thing could apply to patches in https://github.com/Servarr/dotnet-bsd @ta264
@joperator do you think this issue is still valid to be open?

@sec thanks for the patch! I added it and updated some info in the README.md to make things (hopefully) a bit more clear

@joperator do you think this issue is still valid to be open?

@sec Yes, because there is still no official and especially up-to-date documentation on how to build the .NET Core SDK on FreeBSD:
The Developer Guide for dotnet/sdk does not mention FreeBSD at all and the Requirements to build dotnet/runtime on FreeBSD are outdated. Current instructions are scattered across multiple repos, issues, and comments, making it difficult, especially for new developers, to find a good starting point on how to build .NET 5, 6, and future versions on FreeBSD.

I look at runtime docs @sec and some is still very old written by @josteink years ago. The official build is using docker image to make it easier but once and create it locally using build-rootfs.sh and esentially run build with -cross -os FreeBSD -clang9 I can dig out more details about various parts if anybody wants to put some effort to docs.
I'm also going to post some more notes to main runtime issue

Glad someone asked, tbt. Finally getting back around to this now ... imo, the mention of documentation, it may seem to remind of the FreeBSD Documentation Project (in all of its DocBook formalism).
I'd guess Markdown works, too? Not in regards to formats so much, I wonder: Pursuant of any more interest in the topic, may it be possible for anyone - perhaps, anyone more familiar with the build process and the framework itself - to contact the FreeBSD mailing lists if not the FreeBSD Fdn itself, if it may be possible for to assign a mailing list to the topic? Not only for the heavy use of LLVM in the .NET build and throughout the FreeBSD base system, too, perhaps there may be any intersectional interests for .NET and "FreeBSD Core" broadly (??) Of course, I'm just kind of guessing here - understanding, I'm not a formal representative of .NET or FreeBSD.
Personally, I've not ever worked on a group documentation project, though I'm familiar with DocBook 4 and DocBook 5. For .NET Core build itself, I'll still have to put my own notes together to try to produce a build with my FreeBSD 11.2 build and local ports configuration - subsequent of finishing a local upgrade, using FreeBSD 11.2 here.
Perhaps something like one of the formal FreeBSD documentation docs could be of help, at some future time?
Health, all

Sean

So, what's the status of this? Running ./build.sh on the FreeBSD machine gives me
dotnet-install: Downloading primary link https://dotnetcli.azureedge.net/dotnet/Sdk/6.0.100-rc.1.21430.12/dotnet-sdk-6.0.100-rc.1.21430.12-freebsd-x64.tar.gz
curl: (22) The requested URL returned error: 404

I guess, the binaries produced by @Thefrank should be uploaded somewhere?

It has been more than a year, but the script supported using a custom local, SDK at the time.

OK, let's streamline the SDK production first. IIUIC, you're producing SDKs by cross-compiling it from Linux to FreeBSD?
If yes, why can't this be done only once, and then we just use native SDK to produce native SDK?

runtimelabs does not produce SDK -> just runtime. To get SDK you need to work across several other repos. But from my past experience, the runtime is hardest and it can be combined with Linux SDK to produce functional Frankenstein SDK - probably not suitable for production but perhaps good enough to feed it to native build on FreeBSD.
To get SDK you still need (some) previous SDK @arrowd.

The source-build source tree has changed over time? In the master branch, it's now showing instructions for building .NET 6 from a dotnet installer repository. Maybe there's an earlier branch where the previous instructions could still work, with that repository?
There's an existing build for .NET on FreeBSD, the dotnet command there shows a version 3.0.100-preview-010021. It's referred from FreeBSD build instructions under the dotnet/runtime source tree. The (dotnet-sdk-latest-freebsd-x64.tar.gz)[https://dotnetcli.blob.core.windows.net/dotnet/Sdk/master/dotnet-sdk-latest-freebsd-x64.tar.gz] referred there seems to have been last updated in 2019. I've not tried using it for anything except 'dotnet --version' on FreeBSD 12.3, not being certain of how it may fit it into any further bootstrapping workflow.
The build instructions also mention a repository that contains some snapshots for FreeBSD (last updated a few years ago).
Assuming it's ABI-compatible with the FreeBSD build host, could either of these existing dotnet SDK bundles for FreeBSD be used in the bootstrap procedure for .NET 6 now mentioned in the readme at the source-build repository? Just guessing albeit, maybe if DOTNET_INSTALL_DIR was set it would be picked up by build.sh?

During the .NET 6.0 release, the source-build repo has transitioned to a starting point of sorts for source-build, documentation/issue tracking etc.  To build .NET 5.0/3.1 source-build please see these instructions which involving switching branches.  For building .NET 6.0, please see these instructions which involves building source-build from the dotnet/installer repo.  The instructions here do appear outdated in places and will need some updating for 6.0.

After taking a look at the build.sh scripting in dotnet-freebsd-crossbuild by @Thefrank then the documentation for GitHub's Docker container actions, and lastly the YAML syntax for composite actions under a repository's dot-github scripting, maybe it's possible to automate some of the build for this approach, at GitHub?
The dotnet-freebsd-crossbuild scripting appears to be designed for a Debian-based system, such as Ubuntu. For the GitHub actions scripting, maybe much of it could be run within the same dotnet Docker image. Using the sources and patches retrieved in dotnet-freebsd-crossbuild, the latest dotnet/versions would use the ubuntu-18.04-cross-freebsd-12-20220318070727-f13d79e docker image.
For building Mono's msbuild on FreeBSD - in its latest release - it seems that a dotnet distribution for FreeBSD could be useful, even there. I've tried to script the dotnet Linux integration for a port update to match with a Mono 6.12 release. While most of the build in the patched port for mono's msbuild would use a dotnet Linux release (under FreeBSD) but something in sthe Arcade targets still tries to download a FreeBSD dotnet distribution. If that was available at some specific version and was already installed, maybe the build would simply continue from there.
I'll fork the dotnet-freebsd-crossbuild repository, to test out the possibility of scripting it with Docker actions. Perhaps it could be used as part of a distfile production chain for something under ports

In parallel to the present approach we are pursuing, does anyone know top off the mind what is the first .NET Core release that could be built without an SDK and where build instructions can be found? Maybe this rabbit hole will turn out to be somehow easier and more sustainable than setting up and maintaining these cross-build pipelines (maybe I will regret even asking :smile:).
For example, if it turns out that any SDK can be built by bootstrapping using .NET Core 1.0, maybe it will turn out to be quite a viable path. However, early versions are likely to have plenty of linuxism so whether this is a viable path needs to be seen.
Anyway, clarifying the minimal SDK version we need to target for bootstrapping will be helpful even for setting up the cross-build pipelines (in an ideal world we do not want to have to update the bootstrapping SDK).

,NET of given version needs .NET SDK of the same version to bootstrap, bootstrapping on anything lower is not realistically possible.

Using Microsoft's feeds you can start at 3.1. This will be an ONLINE build however:
so 3.1 (with patches) -> 5.0 (with patches) -> 6.0 (with patches) -> HEAD/7.0 (no patching needed)

While testing the patch for adding a Docker-focused build scripting in the cross-build repository, I've tested the patched code on a Debian 11 bare metal install and with a chroot environment on FreeBSD, the later installed with the sysutils/debootstrap port.
The patch would be an adaptation of the original build.sh at the dotnet-freebsd-crossbuild repository, though ideally it could all be run within a single docker image (or independent of docker). I've been testing it outside of Docker, before testing any new Docker images for it.
In  a couple of .NET runtime releases for tags in the 6.100 series, the build fails persistentlhy with errors similar to the following:
/usr/local/crossbuild/build/runtime/.dotnet/sdk/6.0.101/NuGet.RestoreEx.targets(19,5): error : '6.0.3-dev.22175.024243' is not a valid version string. (Parameter 'value') [/usr/local/src/dotsys_wk/dotnet_wk/dotnet-freebsd+docker-crossbuild/build/runtime/Build.proj

I'm not certain if a workaround can be patched on to that. The build has presumably not failed as so, on any Windows runtime environments?
Such a "valid version string" error was occuring when beginning with dotnet-sdk-5.0 or dotnet-sdk-6.0 under Debian 11 on a bare metal install and Debian 11 under chroot on FreeBSD. Maybe there's something in the Microsoft docker images that somehow prevents such an error from occuring (??)

Starting with anew openSUSE Tumbleweed installation under Bhyve (EFI/GPT in the configuration, accessing via ssh for build) I'm seeing some more success with the local adaptations on the cross build scripting.
Using the .NET Core runtime and AspNetCore repositoies at tag v6.0.3, installer repository at tag v6.0.103, plus patches from dotnet-freebsd-crossbuild then in running the adapted build directly on openSUSE, it at least reaches the cmake part of the cross-build.
At eng/native/tryrun.cmake the build seems to expect a file ${CROSS_ROOTFS}/bin/freebsd-version pursuant to setting the FREEBSD build flag. I'm assuming that this file must exist under a filesystem on the Linux machine for the cross-build.
After some tooling with FreeBSD /usr/src/release/Makefile under a local FreeBSD 12.3 build on the stable/12 branch, I have a base.txz available. I'll try installing that under the CROSS_ROOTFS dest then running the build again.
iirc the docker scripting that has been available for the cross-build was using Ubuntu 18.04 in the docker instance. Maybe there'll be some more progress starting with OpenSUSE and Bhyve?

An entry point for the docker-oriented cross-build scripting, but for running the cross-build on some Linux outside of docker : entrypoint_local.sh. This script calls actions/entrypoint.sh with a build environment configured for building outside of Docker.
Tools needed in the build environment: jq; git; patch; sed; tar; gzip; wget; dotnet
I haven't yet addressed the concern of setting up a FreeBSD cross-rootfs for the build, just wanted to send to the patch along at its present changeset

Here is how the crossrootfs is generated for the docker images:
https://github.com/dotnet/arcade/blob/549523c3fc8929da1a3073d1a97f298e0d1dc342/eng/common/cross/build-rootfs.sh#L297-L313
It has been more than a year but the environment setup from that allowed for crossbuilding the FreeBSD runtime from inside Ubuntu (18.xx??)
I might have some time over the weekend to tinker with this but no promises

It seems that it will need some packages from ports instaleld under the cross-rootfs. For this, some of the ports may need to have been updated. So far, I've discovered that these pkgs from FreeBSD will need to have been installed under FreeBSD base system in the cross-rootfs dir:

libunwind  (devel/libunwind)
icu (devel/libicu)
lttng-ust on FreeBSD (sysutils/lttng-ust) and probably its dependencies, including liburcu (sysutils/liburcu)
libinotify (devel/libinotify)

For ensuring lttng-ust would be available at least for testing, I've sent a tenative patch for sysutils/lttng-ust to FreeBSD bugzilla. This would update the port to the latest upstream release, 2.13.2. Candidly, I understand that I may not be well enough familiar with the C language and that project's source API enough to really test the patch or to provide any substantial quality assurance about it. At least the pkg is available is now. Hopefully, the cmake part of the cross-build can now complete that part of the build.
It looks like the FreeBSD packagesite.txz file contains some JSON data under a YAML filename. Like with the original build.sh and the scripting in contrib, once all of the deps in FreeBSD packages are available, the JSON can probalby be parsed with jq, towards automating the pkg retrieval in the cross-build under Linux. For the testing, I've been using pkg builds from my local Poudriere package tree.
The scripting has been updated for the "Install a FreeBSD base system under a Linux environment" part. I'm not all sure of how to approach to the pkg part, I'm sure it will use jq though.
After some more thorough cleanign in the dotnet source trees I was workign with locally, a lot of the build errors I was seeing have cleared up. Building under openSUSE, the dotnet/runtime cross-build had at least reached part of the cmake build where it needed those pkg libraries and headers available for generating the makefiles or the ninja.build file. Those patches from the cross-build repository are invaluable, imo. I'll try to continue with the testing for the local build scripting, now that the pkg dependencies are available at least locally.

libunwind (devel/libunwind)

FWIW, there's a bundled copy of libunwind in dotnet/runtime. Perhaps you can use that instead (at least initially)?

This would update the [lttng-ust] port to the latest upstream release, 2.13.2

Please note that 2.13 is actually incompatible with .NET runtime: https://github.com/dotnet/runtime/issues/57784. It might crash or just not work.

libunwind (devel/libunwind)

FWIW, there's a bundled copy of libunwind in dotnet/runtime. Perhaps you can use that instead (at least initially)?

This would update the [lttng-ust] port to the latest upstream release, 2.13.2

Please note that 2.13 is actually incompatible with .NET runtime: dotnet/runtime#57784. It might crash or just not work.

Oh these side effects. TY for mentioning!
If the build is building dotnet/runtime from source, maybe the soname linkage won't be an issue for the FreeBSD cross-build? I can only hope. Will see how it goes, hopefully, once the build-deps are worked out. It also needs a Kerberos impl (heimdal or mit krb5)
It seems that the cmake scripting for the cross build was trying to locate the libraries and header files under the FreeBSD cross-rootfs.

I noticed the #define DAC_TABLE_RVA 0x error occuring under crossrootfs builds that were not using docker. I never figured out WHY that was happening and just moved to docker because it was the easiest way to fix the issue at the time :(
Also, as a heads up for net7.0+, lttng is no longer used in the build process for FreeBSD and OSX. If you are sourcebuilding net6, you will still need it, but starting in net7 it just falls back to dummyprovider (like OSX). I would like to see support for DTrace for FreeBSD and/or OSX but I doubt that will happen.

I noticed the #define DAC_TABLE_RVA 0x error occuring under crossrootfs builds that were not using docker.

fwiw in tracing it across the build files, with dotnet/runtime version v6.0.3 there is the following in dotnet/runtime source file src/coreclr/debug/daccess/CMakeLists.txt. This seems to provide a conditional configuration for  a script at coreclr/pal/tools/gen-dactable-rva.sh for generating the dactable symbol file
if(CLR_CMAKE_HOST_FREEBSD OR CLR_CMAKE_HOST_NETBSD OR CLR_CMAKE_HOST_SUNOS)
  add_definitions(-DUSE_DAC_TABLE_RVA)

  set(args $<$<NOT:$<BOOL:${CLR_CMAKE_HOST_OSX}>>:--dynamic> $<TARGET_FILE:coreclr> ${GENERATED_INCLUDE_DIR}/dactablerva.h)

  add_custom_command(
    OUTPUT  ${GENERATED_INCLUDE_DIR}/dactablerva.h
    DEPENDS coreclr
    VERBATIM
    COMMAND_EXPAND_LISTS
    COMMAND ${CLR_DIR}/pal/tools/gen-dactable-rva.sh ${args}
    COMMENT Generating ${GENERATED_INCLUDE_DIR}/dactablerva.h
  )

  set_source_files_properties(
    ${GENERATED_INCLUDE_DIR}/dactablerva.h
    PROPERTIES GENERATED TRUE
  )

  add_custom_target(
    dactablerva_header
    DEPENDS ${GENERATED_INCLUDE_DIR}/dactablerva.h
  )

  add_dependencies(daccess dactablerva_header)
endif(CLR_CMAKE_HOST_FREEBSD OR CLR_CMAKE_HOST_NETBSD OR CLR_CMAKE_HOST_SUNOS)~~~~

in gen-dactable-rva.sh [full source] I think it's due to this:
value="$(printf "%016s\n" [_sic_]))

This adds whitespaace to the head of the value interpolated from input to the script, which is then produced vertabim in printf "#define DAC_TABLE_RVA 0x%s\n" "$value". I'll try updating the runtimeRTM patches for this
fwiw where the value is used in src/coreclr/debug/daccess/daccess.cpp
HRESULT
GetDacTableAddress(ICorDebugDataTarget* dataTarget, ULONG64 baseAddress, PULONG64 dacTableAddress)
{
#ifdef TARGET_UNIX
#ifdef USE_DAC_TABLE_RVA
#ifdef DAC_TABLE_SIZE
    if (DAC_TABLE_SIZE != sizeof(g_dacGlobals))
    {
        return E_INVALIDARG;
    }
#endif
    // On MacOS, FreeBSD or NetBSD use the RVA include file
    *dacTableAddress = baseAddress + DAC_TABLE_RVA;
#else
    // On Linux/MacOS try to get the dac table address via the export symbol
    if (!TryGetSymbol(dataTarget, baseAddress, "g_dacTable", dacTableAddress))
    {
        return CORDBG_E_MISSING_DEBUGGER_EXPORTS;
    }
#endif
#endif
    return S_OK;
}

dactablerva.h genrated by that tools script had contained only the single line, illustrating where the whitespace is introduced:
#define DAC_TABLE_RVA 0x          6c0df8

imo with as well organized as the patches are for this cross-build, this update would be trivial, to simply remove the additional formatting spec from the initial printf in that script

Also, as a heads up for net7.0+, lttng is no longer used in the build process for FreeBSD and OSX. If you are sourcebuilding net6, you will still need it, but starting in net7 it just falls back to dummyprovider (like OSX).

TY. I'd noticed the .NET 7 release tags in the git ls-remote. tbt if it was not for the original crossbuild repository, I would not even be able to guess my way through this build, lol.
If I can work out the additional build tooling for a .NET 6 build, I'll try to put together a port that would use the cross-built parts and produce it for FreeBSD. If there's a docker image for FreeBSD that could be used with the GitHub Workflow/Actions scripting, it might even be possible to produce a pkg build for installation to any system using the official FreeBSD release base system and kernel.

I would like to see support for DTrace for FreeBSD and/or OSX but I doubt that will happen.

fwiw for that machine running the Bhyve system, which is running the openSUSE system that I'm testing this with, the FreeBSD host was build with WITH_CTF=               Defined in src.conf (handbook ref available).
If that build option may not have been used in the base system  installed under the cross-rootfs, perhaps the dotnet/runtime cross-build may not produce any support for dtrace in the built objects. If it was available in the original base.txz for the cross-rootfs, maybe that option would be availble under the dotnet/runtime cross build?
tbt I'd like to be sure that this can be built without GitHub actions scrpiting. If it can be produced with bhyve - albeit, in assuming the availability of superuser credentials in the scripting - ideally the whole build could be produced with one machine. The build host here is a laptop that has 16 GB RAM and ZFS on root. With FreeBSD, it's been working out lol!

I was able to build a working dotnet SDK using openSUSE Tumbleweed in Bhyve.
For addressing the initial build failure in the dotnet/runtime section, and for addressing some issues I was seeing under the tests in the aspnetcore section,  I've added a couple of trivial updates on the the original patch set from dotnet-freebsd-crossbuild. The patch additions for the cross-build with dotnet/runtime and the a node.js part under the testing for aspnetcore have each been sent to upstream with separate pull requests.
I was using the entrypoint_local.sh script, which I've been working on in a contrib branch. This calls actions/entrypoint.sh such that could ostensibly be used for automating the build with Docker under a GitHub Workflow definition. The scripts can be used independent of Docker.
The most of the documentation is in entrypoint.sh. There are build dependencies listed there, including those for the build host and those for the cross-rootfs. The cross-rootfs itself and the build dependencies would have to be manually installed.
For the cross-rootfs, I'd used a base.txz from [12.3-RELEASE/](http://ftp.freebsd.org/pub/FreeBSD/releases/amd64/12.3-RELEASE/] unpacked with bsdtar --no-fflags to the directory denoted as CROSS_ROOTFS to the build scripts. I'd then installed each build dependency from a local port build for a local 12.3 FreeBSD base system and kernel build. This crude package installation process did not offer any support for post-install scripts or retaining package metadata. It simply provided the files at some location under the cross rootfs, for the dotnet/runtime cross build.
The build dependencies are listed in the script. For the GSS-API option, I'd used an mit krb5 build from the local ports tree.
In order to build the lttng-ust build dependency for the cross-rootfs in the build, I'd used a patched local ports tree. The diff has been submitted to FreeBSD bugzilla.
After some fixes for the scripting I've been tooling with, then notwithstanding the quality of the local network, but it went pretty straightforwardly. To my best estimate with the tree I'm working with locally, the build needs up to 16 GiB of filesystem space.
I'm going to take a look at running openSUSE in Docker ... lol under openSUSE in bhyve. If it may serve to provide a way to test out the entrypoint.sh script in a docker environment, hopefully it will be possible to automate this and to put together some way to build the build dependencies independent of my local FreeBSD installation.
Assuming that there would be a suitable range of SDK versions available from the cross-build approach, I think it may be possible to start building the runtime and SDK parts natively on FreeBSD. I'll try to test out the scripting under Docker and put somethign together for automating a build with GitHub Workflow Actions.

@spchamp I am both excited and intrigued by your progress because there is one thing that isn't totally clear to me: what is the goal?
I tend to think that your end goal is to 1) create a FreeBSD port using bhyve behind the scenes to build the SDK, and 2) enable the .NET team to build for FreeBSD more easily upstream by providing them a docker image that they can automate using Github Actions.
If this understanding is correct, for 1) are we sure that the build system of the official FreeBSD package repository will allow us to run bhyve to build the port? There are all sort of limitations there such as the fact that it is not possible to fetch anything after the fetch stage of the build progress.
For 2) my (limited) understanding is that the .NET team uses Azure Pipelines to build .NET so I struggle to understand how the Github Action integration will help them. At the same time since docker is not supported on FreeBSD I assume that this is not intended to be used by FreeBSD users, so the goal of the Docker part of your effort is obscure to me.
Could you please help me clarify the goal that you have in mind

@nkosi23 although I've been looking at a couple of ideas for how to automate the build outside of my own own VM configuration, I don't believe anything is really concrete about it as yet. Presently, I'm simply trying to test the build under a certain VM configuration using openSUSE.
After some further reading about some ostensible options, I understand that it would not be possible to build the FreeBSD build dependencies under Docker here at GitHub.
Although I have an openSUSE installation under Bhyve available for some initail testing, but it seems that the GitHub Workflow documentation favors Debian-based distributions for Docker automation. I'm assuming that's what they're running on the servers. So, I'm going to test the build under a Debian-based distribution locally, before putting together anything in Docker with GitHub.
That would not serve to address the issue of the missing build-dependency for lttng-ust. Without some kind of a patch for the ports tree, it may not build for amd64. There is not any pkg available. If it may be possible to build a patched port tree for purpose of the build dependencies, of course that would have to be conducted outside of Docker - unless there would be some way to build a FreeBSD base system and a small number of ports for a FreeBSD system, within a Linux compiler environment, lol.
If automating the build-depeddencies part in some FreeBSD system, perhaps it might also serve to provide any build options for different GSS-API implementations (MIT krb5, heimdal, or krb5 in the base system) and for DTrace support in the build. Coordinating this with some Linux-based system for the cross build may not be posible singularly at GitHub. I'll try to take a look at what I may be able to put together for an independent build server with Azure DevOps or DigitalOcean, for automating that part of the build.
That is about the limit of what I have in mind. Health, all.

To my best estimate with the tree I'm working with locally, the build needs up to 16 GiB of filesystem space.

@spchamp, In case you are not already using it, there is a /p:CleanWhileBuilding=true build option that will reduce the size needed to build.

So, how is the progress?  Did we come any closer to having modern .NET stack in FreeBSD ports?  I've noticed that @sec is updating his repo more or less regularly (last commit being this year), are there any connections between his work and upstream?
In FreeBSD ports, we currently rely on Mono to build C# projects, and recently some developers become more feared it's being phrased out, sometimes dubbed as "dead upstream".  While this is not quite true AFAICT, there's clearly an increasing demand for modern .NET implementation which FreeBSD is unfortunately lacking.

@danfe very close. There are a few issues I noted in https://github.com/dotnet/runtime/issues/14537. There are two matching PRs open to fix the R2R issue. The others need to be opened/fixed here in source-build.
After the above PR's, the build process would look like:
download pre-built SDK
clone dotnet repo
unpack SDK into repo
./prep.sh
manually add missing NuGets (issue noted above)
manually patch FreeBSD RIDs into installer
./build.sh --online

Additional considerations when building:

No official support means manually downloading and unpacking a pre-built SDK (noted above)

There are three public sources for this: @sec has native built ones for x64 and ARM64 for FreeBSD 13 and both I and the Servarr team have crossbuilt ones for FreeBSD 12 x64

No official support means manually downloading the missing FreeBSD NuGets (noted above)

Both I and @sec provide NuGet feeds with our prebuilt items

No official support means manually patching RIDs into installer (noted above)

Intentional. FreeBSD is community supported. We do not want to create a massive support headache for Microsoft if people think there is official support so the RID must be manually patched here

allow.mlock=1 in jail when building/running
AFAIK offline building is still not supported for source-building, which means the ports system can not build this

This will hopefully be fixed before net8 launches

@danfe we now have .net 8 port in FreeBSD ports tree, ready for use (x64 and arm64).

With lang/dotnet in FreeBSD port I think think this is safe to close?
The port uses the VMR with a prebuilt bootstrap and some script work to make sure it works under the constraints of FreeBSD's build and pkg servers.
Those wanting a portable build can always use either a) cross-building from Linux or b) native non-VMR building. The patches from ports should be enough but there are a few PRs for future versions of dotNET that portable builders should either cherry-pick or wait for them to get merged (e.g. FreeBSD RID, OpenSSL3 support)

With lang/dotnet in FreeBSD port I think think this is safe to close?

This FreeBSD port is very good for installing a ready-to-use .NET SDK on FreeBSD (something I've wanted for years). However, maybe I'm a bit traditional, but I'd still like to have some kind of documentation on how to build the .NET SDK on or at least for FreeBSD using native build and/or cross-build on Linux.

@joperator the port uses dotnet's VMR to generate a non-portable build. if you have a ports tree setup, you can just make build in lang/dotnet and it will produce all of the items need to not only install the SDK (make install works too) but build SDK minorversion+1 from the VMR.
If you want portable native builds @sec has an excellent set of scripts setup for that and even publishes SDKs with a handful of NuGets
If you want portable cross-builds from Linux I have a repo for that. I publish the SDK along with NuGets too. I do however need to spend some time improving the scripts as the default container switched from ubuntu to cbl-mariner and that breaks a number of things.
Both of us maintain our own NuGet feeds if you just need NuGets.
My general advice is to use the port as pkg install dotnet is easier and quicker than the other options. If you want to build a portable version @sec scripts will be more useful for pure FreeBSD users. My repo will be better for those that want to produce FreeBSD items but work in Linux/OSX
Finally, for official documentation? Well, FreeBSD is still a community supported platform so it only has instructions to build the runtime repo and nothing more. The FreeBSD wiki entry might be a better place but it needs some updates. The only major difference between natively building and cross building from Linux is that the native builds need a working SDK  and a handful of NuGets setup before hand while the cross build can download just about anything it needs from Microsoft's feeds. The cross build requires docker unless you want to create your own crossrootfs.

It's not an official documentation, but your comment is something I asked for: A quick overview where to find scripts and instructions to build the .NET SDK on/for FreeBSD. Thank you very much and it's great to see how far the community has come with this. 🎉

Maybe we should put some additional code to the port to ease cross-compiling? Like, some knobs or targets hidden in the Makefile that may be adjusted/ran by the end user.


Logger pring "undefined"

`POST undefined /api/getfileinfo``

yes if you're not set the status, It displays an undefined status. but it'll be 200 status automatically.

Then it will be print 200.


Exchange data chart type

Hello there !
I need help again.. I hope you can answer...
https://prnt.sc/ioga36
Which chart is this ? Highchart or what ? Where can i found this chart sources ? I want to build same as like this look for mobile resolutions .
What is your ideas fellows ?
Thank you for sharing.

This is kline: https://github.com/chxj1992/kline
I have code to make it work with this library. My version uses PHP to get around CORS security issues

Thank you so much....

no problem, there are two undocumented built-in functions in this library that are very useful for charting.
.highstock(chart) will return the data in array format [open, high, low, close, volume]
.ohlc(chart) will return the data in object format .open .high .low .close .volume
        // convert chart data to highstock array [timestamp,open,high,low,close]
        highstock: function(chart, include_volume = false) {
            let array = [];
            for ( let timestamp in chart ) {
                let obj = chart[timestamp];
                let line = [
                    Number(timestamp),
                    parseFloat(obj.open),
                    parseFloat(obj.high),
                    parseFloat(obj.low),
                    parseFloat(obj.close)
                ];
                if ( include_volume ) line.push(parseFloat(obj.volume));
                array.push(line);
            }
            return array;
        },
        ohlc: function(chart) {
            let open = [], high = [], low = [], close = [], volume = [];
            for ( let timestamp in chart ) { //ohlc[symbol][interval]
                let obj = chart[timestamp];
                open.push(parseFloat(obj.open));
                high.push(parseFloat(obj.high));
                low.push(parseFloat(obj.low));
                close.push(parseFloat(obj.close));
                volume.push(parseFloat(obj.volume));
            }
            return {open:open, high:high, low:low, close:close, volume:volume};
        },


create tool to use plugin readme's in our docs in a automated way.

We have quite a few plugins that all have their own documentation in their own readme.
We should pull those into the docs site in an automated fasion.

@jorgeucano @SanderElias anyone looking into this feature?

@ngdevelop-tech Not right now.
It's on @jorgeucano task-list, but I suspect he will not come around to this shortly.
(@jorgeucano correct me if I'm wrong!)


Badge Name
Haxe
Description
https://haxe.org

@inttter haxe is not a framework btw, it's a programming language

my bad, i wasn't reading properly. should be fixed now!

looks good to me 👍


ci-operator internals: incorporate old docs

I found this page in the old repository with useful information, some of which
I'd already planed to cover, so I'm just copying it almost unchanged except to
make it fit better in the current structure:
https://github.com/openshift/ci-operator/blob/master/ARCHITECTURE.md
Also added an example ci-operator step graph from the recent presentation to
the steps page.

https://deploy-preview-271--zealous-shirley-0f56b3.netlify.app/docs/architecture/ci-operator-internals/
https://deploy-preview-271--zealous-shirley-0f56b3.netlify.app/docs/architecture/ci-operator-internals/steps/#step-graph

/test links

/lgtm


more than one library with package name 'com.google.android.gms.license

Ionic version:  (check one with "x")
[ ] 2.x
[x] 3.x
[ ] 4.x
I'm submitting a ...  (check one with "x")
[x] bug report
[ ] feature request
Current behavior:

Not able to build platform android using "ionic cordova run android" command
Expected behavior:

Should run properly
Steps to reproduce:

Run "ionic cordova run android" command

Other Information:

@ionic/cli-utils  : 1.19.1
ionic (Ionic CLI) : 3.19.1

global packages:
cordova (Cordova CLI) : 7.1.0

local packages:
@ionic/app-scripts : 1.3.7
Cordova Platforms  : none
Ionic Framework    : ionic-angular 3.2.1

System:
Node : v6.11.3
npm  : 3.10.10
OS   : Windows 7

Do you use the Firebase plugin? If so, check this ticket: https://github.com/arnesson/cordova-plugin-firebase/issues/610

I also have this problem. Last time everything built; we did not change anything; today the android build is dead with this error

@DBnR1, no i am not using Firebase plugin.

Btw, I am using Firabese plugin...
But in this case maybe it is not at all a Firebase plugin bug?
I could see on the console during the build that these dependencies were updated:
deps-updated.txt

Actually, for me it was really the Firebase plugin. Thanks for the link @DBnR1, it solved for me.
Specifically, for me the solution was in this comment: https://github.com/arnesson/cordova-plugin-firebase/issues/610#issuecomment-374941040

Actually for me it was the Google plus plugin "cordova-plugin-googleplus"
Thanks for the link @DBnR1, however i added 2 more dependencies to solve the issues.
Add bellow code at the end of platforms/android/build.gradle file
configurations.all {
   resolutionStrategy {

       force "com.google.android.gms:play-services-auth:11.8.0"
       force "com.google.android.gms:play-services-identity:11.8.0"

       force "com.google.android.gms:play-services-ads:11.8.0"
       force "com.google.android.gms:play-services-base:11.8.0"
       force "com.google.android.gms:play-services-gcm:11.8.0"
       force "com.google.android.gms:play-services-analytics:11.8.0"
       force "com.google.android.gms:play-services-location:11.8.0"
       force "com.google.android.gms:play-services-basement:11.8.0"
       force "com.google.android.gms:play-services-tagmanager:11.8.0"
       force 'com.google.firebase:firebase-core:11.8.0'
       force 'com.google.firebase:firebase-crash:11.8.0'
       force 'com.google.firebase:firebase-auth:11.8.0'
       force 'com.google.firebase:firebase-common:11.8.0'
       force 'com.google.firebase:firebase-config:11.8.0'
       force 'com.google.firebase:firebase-messaging:11.8.0'
   }
}

Hi @ejaz47! The problem you were having seems to be more related to Cordova than Ionic. Is it still an issue? If not, can you please close it? (I'm volunteering to triage issues). Thanks!

@FdezRomero, yes its related to cordova so  closing it. Thanks


how to install Primal

Describe the bug
A clear and concise description of what the bug is.
Steps to reproduce
Steps to reproduce the behavior.
Expected behavior
A clear and concise description of what you expected to happen.
Environment

Details that you think may affect.

Additional context
Add any other context about the problem here.

I trief to install Primal through Alby, and did not succeed.
i can write notes and can search for notes of others. However i cannot use the 'follow button' (is inactive, network problem); cannot remove my notes; cannot correct my notes;
In this way it is not useable

i tried


Question

I know you mentioned config paths and such in your video, if I am using the exe and have set it up, what is the best way to duplicate the settings. Can I just drop a config file in a specific path? I would mostly use this as admin but sometimes under a limited user so I know that plays into install directories and config locations. Thanks again having that favorites bar is freaking awesome!

It will first look for the config file in the same directory as the script/exe. If it doesn't find it, it will then look for it in the user's AppData roaming directory in a folder called "Explorer-Dialog-Path-Selector".
Though you could change the AppData folder name or even the config file name in the script by editing these values):
global g_pth_SettingsFile := SettingsFile(
    "ExplorerDialogPathSelector-Settings.ini", ; Name of the settings file
    "Explorer-Dialog-Path-Selector"            ; Name of the folder in AppData where the settings file will be stored
)

If a settings file is loaded and you change and save the settings, it will update the file wherever it was loaded. If you save the settings when no settings file was loaded, then it will first try to save next to the script/exe, and then if it can't it will go in the AppData folder.
Assuming the following:

The admin and user accounts have different usernames
You want to share the same settings file, I can think of a few possibilities
The exe is in Program Files

Then I can think of a few options:

You could put the config file next to the Exe in program files. It will be able to read from it even when not escalated, but you'll have to escalate to update it. Whether that means while you're running the script as admin or copying an updated version of the config file and accepting the UAC prompt.
Have two separate copies of the config file in each user's AppData folder
Probably the easiest: Put the config in one user's AppData folder and make a Symlink for it in the other's AppData folder. So whether you run it from either account it will actually act on the same file.


Fixes vulnerable deps | npm 6 update

Hopefully this works. Last time I updated with npm 6 there were issues. Let's see what happens.
Changes

Updates package-lock files from npm 6.
Updates protractor to 5.3.2 to fix high severity security vulnerability.
Updates jasmine-reporters, webpack, and uglifyjs-webpack-plugin

Testing

npm install.
gulp build should pass.
gulp test:acceptance --headless should pass.

Closing this in favor of https://github.com/cfpb/cfgov-refresh/pull/4141 because gulp-imagemin fails on npm 6 with https://github.com/imagemin/imagemin/issues/252


assertion failed: self.form property MUST be assigned

I am getting the error above when trying to call tableView.reloadData() from my function.
But if I put it inside the button's action, it works fine:
func submit(_: UIBarButtonItem!) {

        //let message = self.form.formValues().description

        //let alert: UIAlertView = UIAlertView(title: "Form output", message: message, delegate: nil, cancelButtonTitle: "OK")

        //alert.show()
        row4.configuration[FormRowDescriptor.Configuration.Options] = ["hello", "from", "the"]
        row4.value = "hello"
        self.tableView.reloadData()

    }
What should I do?

Last question please..

Please, refer to README.MD to know how to configure a FormViewController properly. As you mentioned in your issue title. FormViewController form property is not being assigned.


[FLINK-31743][statebackend/rocksdb] disable rocksdb log relocating wh…

…en instance path too long
What is the purpose of the change
disable rocksdb log relocating when instance path too long, see FLINK-31743.
Verifying this change
This change added verification to existing test  RocksDBStateBackendConfigTest#testDefaultDbLogDir().
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (no)
The serializers: (no)
The runtime per-record code paths (performance sensitive): (no)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: (no)
The S3 file system connector: (no)

Documentation

Does this pull request introduce a new feature? (no)

Thanks @masteryhx for help review the pr,  I have updated the code as your comments.

LGTM. @Myasuka Do you have any other comments?

Thanks for the reminder, I will take a look today.

@flinkbot run azure

@flinkbot run azure

@zoltar9264 Thanks for the PR, should the description of state.backend.rocksdb.log.dir be changed accordingly?

Thanks for your reminder @fredia , but I think this pr is just a hotfix. I will submit a PR to the frocksdb repository to finally fix this issue.

Thanks for meticulous suggestion @Myasuka , I have updated the PR and the CI passed. PTAL.


Getting raw ADC values with real resolution

My initial implementation of ADC with calibration allowed me get raw values with 12 bit resolution.
This values can be easily converted to millivolts when needed.
The PR #836 removed that useful feature.

I didn't end up reviewing #836, so I don't have much context here, but the PR states that the calibration was being done in millivolts so the extra resolution was essentially lost already because the calibration would be wrong. I believe you wrote the original calibration code, so do you have any comments on that?
My 2c is that we should have an easy API for obtaining the raw 12bit resolution and the mv converted values; we don't need to pick just one.

Yes I agree that you would like to have both.
Of course calibrated values would be best suited for both cases.

Isn't AdcCalBasic the API for obtaining the raw 12bit resolution? Whatever the units for AdcCalLine are, if the gain coefficient is less than 1 there will be a loss of resolution.


Power consumption

Hi, I'm using a Waveshare BLE400 board and I noticed an abnormal power usage compiling with arduino.
I'm using the blue thermometer example and I got a 4mA if compiling with arduino but a similar example with mbed compiled with platformio uses about 100uA with the same tx power and advertising period.
Why?

@webfrank

Hi, I'm using a Waveshare BLE400 board and I noticed an abnormal power usage compiling with arduino.
I'm using the blue thermometer example and I got a 4mA if compiling with arduino but a similar example with mbed compiled with platformio uses about 100uA with the same tx power and advertising period.
Why?

I was facing a similar issue. I had to declare the following after blePeripheral.begin().
Like this:
blePeriph.begin();
sd_ble_gap_tx_power_set(-16);

// 100ms; in multiples of 0.625ms.
blePeriph.setAdvertisingInterval(160);

See the following lines for understanding:
//github.com/sandeepmistry/arduino-BLEPeripheral/blob/161a4163f565be3cd5b62bbc59f0c2b522d82b02/src/nRF51822.cpp#L188-L196
Hope it helps you! 😃


Fix createhome directory for adduser role

A typo in the adduser role prevents the createhome
variable to be taken into account.
Fix #3164

Please sign the cla.
/lgtm

I just signed the cla.

/approve

ci check this


Add Longest Palindromic Substring

A program to find longest palindromic substring

please review my PR, In case of any conflict let me know I will fix it.
I would be thankful if u add the label as Hacktoberfest-accepted.


ods:hasRelatedPID: rename, as the element breaks the naming convention

Term Name
ods:hasRelatedPID
Digital Object Name
DigitalSpecimen: TombstoneMetadata
Feedback
This element contains an array of PIDs, however according to the naming convention, the name implies that it is an object property pointing to a class called RelatedPID. If the property should be used it its current form, it should be renamed to ods:relatedPIDs, (with the plural to indicate that it allows for multiple entries). Alternatively, this could be renamed to hasRelatedIdentifier and be an object property to the Identifier class.

This is an issue in the generation of the terms documentation pages which we will fix.
The ods:hasRelatedPID should contain an object with two properties ods:ID and ods:relationshipType


Go Get Dependency Error on Apache Arrow

I get an error by getting the library:
go get gorgonia.org/golgi
and get the result
go: downloading gorgonia.org/golgi v0.0.0-20201019204706-021b9dd290fd
go: gorgonia.org/golgi upgrade => v0.0.0-20201019204706-021b9dd290fd
go get<EMAIL_ADDRESS>requires
<EMAIL_ADDRESS>invalid version: unknown revision 26aad5dc2281

a call for go get gorgonia.org/golgi is working well

That's a concerning error. Looking into it right how

That's a concerning error. Looking into it right how


Show currently played chord

Show the exact chord currently being played on Analysis tab.
Choose the simplest one that applies:

Overtonal enumeration
Undertonal enumeration
Array of fractions
Array of steps and a backslash for the edo
Array of cents (not exact)

Time estimate: 4 hours


custom fields: code placement

The following classes are located in the service package.
    "CustomFieldsSchema",
    "CustomFieldsSchemaUI",
    "CustomFieldsService",
    "CustomFieldsServiceConfig",
    "KeywordCF",
    "TextCF",

Do they belong there? should the CF classes be moved to its own package?

Im closing this, so far the custom fields are used in the service level, to define the schema. It is true that the ui_field will be called from the resource layer for serialization, but that happens also for most of the schemas and fields defined in the service layer. It is the natural flow of calls.


Fix language within devicemapper thinpool setup

Proposed changes
Previous language indicated that a user would be "creating a thin pool". This language is confusing as it indicates that the logical volume created is of the thin pool type; instead, the volume being created is a linear volume group which is then converted to a thin pool in step 6. This is an important nuance when implementing setup through configuration management tools such as Salt or Ansible. When initially provisioning the two logical volumes as thin pool, the error "Pool metadata LV docker/thinpoolmeta is of an unsupported type". Updating the language reflects the actual command behaviors.
Related issues (optional)
N/A

Here's a link to the page within netlify for review:
https://deploy-preview-1368--docker-docs.netlify.com/engine/userguide/storagedriver/device-mapper-driver/


Implement fast roaring bitmap union (Part 1)

Overview
This pull partially addresses #1765 by providing a much faster and less allocation heavy implementation of the union operation.
Pull request checklist

[X] I have read the contributing guide.
[X] I have agreed to the Contributor License Agreement.
[X] I have updated the documentation.
[X] I have resolved any merge conflicts.
[X] I have included tests that cover my changes.
[X] All new and existing tests pass.

Code review checklist
This is the checklist that the reviewer will follow while reviewing your pull request. You do not need to do anything with this checklist, but be aware of what the reviewer will be looking for.

[ ] Ensure that any changes to external docs have been included in this pull request.
[ ] If the changes require that minor/major versions need to be updated, tag the PR appropriately.
[ ] Ensure the new code is properly commented and follows Idiomatic Go.
[ ] Check that tests have been written and that they cover the new functionality.
[ ] Run tests and ensure they pass.
[ ] Build and run the code, performing any applicable integration testing.

Thank you for the thorough comments!

@alanbernstein No problem. Any idea why the race test is failing? there is no output

@seebs How does the latest version look? Also, any idea about the failing C.I?

I did my best to confirm that the CircleCI race detection that was failing is not directly related to this PR. There seems to be and issue with cluster logic on the node-leave event, and I filed an issue for that here: #1772.

@travisturner Awesome thanks, I addressed the last bits of feedback about my comments. I'll rebase master and push again

@travisturner everything should merge cleanly now

Thanks @richardartoul. Nice work!


UI does not update when this.state is updated.

Description
I am using Checkbox from react-native-elements that would require to be checked to move to the next slide (this can also be replicated with the switch button). The implementation is as such:
<CheckBox           center           title='I Consent'           containerStyle={{backgroundColor: 'transparent', borderColor: 'transparent'}}           textStyle={{fontSize: 24, color: '#fff'}}           checked={this.state.checked}           onPress={() => this.setState({checked: !this.state.checked})}         />
The issue here is if you click on it, the this.state.checked value on the backend changes but the UI does not update.
Image

Could you try passing extraData={this.state.checked} to the componennt?

Closing for inactivity.


Submit connector to connector gallery

Submit connector to be incorporated in official connector gallery.
Can be done here with more information here or here.

Not going to happen as it turns out I need to provide the backend service for that instead of the consumers deploying a private instance of this repository.


Update packages

This PR updates all dependencies to the latest versions and increases the pub.dev score by 10 points.
The version of package_info_plus was once locked to 1.3.0, then in this PR updated, but without adding a caret.
Since the newer version (than the fixed version from a few months ago) came out only 12 days ago, the fixed version was probably not related to 1.4.2.

Hi @nohli ! Thanks for your PR! 🙏 Unfortunately, this is a read-only repository, and changes should be made in our SDK Generator repo. Feel free to make the PR over there.


broken link on gitcvs-migration page

On this page:
https://git-scm.com/docs/gitcvs-migration
I find the following:
First, install version 2.1 or higher of cvsps from http://www.cobite.com/cvsps/ and make sure it is in your path. Then cd to a checked out CVS working directory of the project you are interested in and run git-cvsimport[1]:
the cobite.com link is a 404.  I presume, but am not sure, it's now this:  https://github.com/andreyvit/cvsps
thanks

Thanks. This documentation actually comes from the upstream git project, but I've sent a patch there to fix it.

I kind of wondered about that, but the link at the bottom of the page led here.
This open sourced site is hosted on GitHub.
Patches, suggestions and comments are welcome
thanks!


[Test] Generalize a few attribute tests for iOS.

The tests for the @main and @_originallyDefinedIn attributes were
insufficiently general to get decent platform coverage. Generalize
them to at least run on iOS, with appropriate %target-run'ification.

@swift-ci please smoke test and merge


Register as Issuer (with verification)

Issuer can get their organisation verified by providing GSTIN number (WIP)

Can you please explain this a lil bit , seems interesting , will work on it

@Jassi10000 we will work on this once milestone 1 is completed