Build fails on Arch Linux (core-setup)

[alucryd]

On branch release/2.0, after patching for our newer glibc everything builds fine using clang 3.9, except corefx which produces the following error:

"/home/alucryd/packages/community/dotnet-core/trunk/src/dotnet-core/build.proj" (default target) (1) ->
"/home/alucryd/packages/community/dotnet-core/trunk/src/dotnet-core/targets/repository.proj" (BuildRepositoryAndDependencies target) (2) ->
"/home/alucryd/packages/community/dotnet-core/trunk/src/dotnet-core/targets/repository.proj" (BuildRepositoryAndDependencies target) (2:3) ->
"/home/alucryd/packages/community/dotnet-core/trunk/src/dotnet-core/targets/repository.proj" (BuildRepositoryAndDependencies target) (2:6) ->
(Build target) ->
/home/alucryd/packages/community/dotnet-core/trunk/src/dotnet-core/src/corefx/Tools/depProj.targets(83,5): error : Error no assets were resolved from NuGet packages. [/home/alucryd/packages/community/dotnet-core/trunk/src/dotnet-core/src/corefx/external/ilasm/ilasm.depproj] [/home/alucryd/packages/community/dotnet-core/trunk/src/dotnet-core/targets/repository.proj]
/home/alucryd/packages/community/dotnet-core/trunk/src/dotnet-core/src/corefx/Tools/depProj.targets(83,5): error : Error no assets were resolved from NuGet packages. [/home/alucryd/packages/community/dotnet-core/trunk/src/dotnet-core/src/corefx/external/ilasm/ilasm.depproj] [/home/alucryd/packages/community/dotnet-core/trunk/src/dotnet-core/targets/repository.proj]
/home/alucryd/packages/community/dotnet-core/trunk/src/dotnet-core/targets/repository.proj(74,5): error MSB3073: The command "/home/alucryd/packages/community/dotnet-core/trunk/src/dotnet-core/src/corefx/build.sh -Release -buildArch=x64 -portable=false -- /p:ILLinkTrimAssembly=false" exited with code 1.

Any idea where that's coming from?

[alucryd]

Can anybody help? Arch Linux already switched to icu 60.1, I would like to build our package from source to avoid shipping a compat icu59 package. I'm using the plain build.sh script, I'm quite sure there's nothing wrong with how I'm building. I tried using clang35, but as expected it didn't change anything since the error doesn't happen during compilation of C/C++ code.

[omajid]

Can you include the complete log, by any chance? There may be some earlier error that is leading to this error down the road.

[alucryd]

Apologies for the delay. The log is quite big, but here you go: https://paste.xinu.at/AWIc/

[alucryd]

Hi, did you get around checking that log file, did that help?

[omajid]

Oops. Looking at it now, a couple of things pop out:

Cloning into '/home/alucryd/packages/community/dotnet-core/trunk/src/dotnet-core/src/roslyn'...
fatal: write error: No space left on device
fatal: index-pack failed
fatal: clone of 'https://github.com/dotnet/roslyn' into submodule path '/home/alucryd/packages/community/dotnet-core/trunk/src/dotnet-core/src/roslyn' failed
Failed to clone 'src/roslyn'. Retry scheduled

But later, there is also:

~/packages/community/dotnet-core/trunk/src/dotnet-core/src/coreclr
System.Private.CoreLib.dll build unsupported.
Nuget package generation unsupported.
Repo successfully built.

It looks like you want the fix from #266.

[alucryd]

Thank you! Still had several gigs of free space on that drive, didn't think that could be an issue, the build sure is space hungry. Thanks for the link, I'll give the PR a try this week-end.

[alucryd]

I gave the dev/release/2.0 branch a try, and am now facing an issue (which I thought had been solved already) when building corefx. Our openssl-1.0 package comes with SSLv3 methods disabled as they're considered unsafe, thus making the build fail.

https://paste.xinu.at/zfgvE/

[alucryd]

Branch release/2.1 still fails on Arch Linux, but even earlier than before, coreclr doesn't build:

https://paste.xinu.at/3QQ/

Could you guys please take a look ? I'd like to build our package from source instead of repackaging the binary blobs.

[omajid]

Looks like RID detection is busted:

DistroRid is arch.-x64

That should just be arch-x64. Other places correctly do:

DOTNET_RUNTIME_ID=arch-x64

[alucryd]

Is there a way to force the RID instead of having it computed?

[omajid]

Is there a way to force the RID instead of having it computed?

Perhaps you can look for lines of the form

__HostDistroRid="$ID.$VERSION_ID-$__HostArch" 

and modify them to:

__HostDistroRid="$ID-$__HostArch" 

These should be present in src/coreclr/build.sh, and src/corefx/src/Native/build-native.sh and probably other places.

[alucryd]

Thanks, patched all 3 build scripts with:

elif [[ $ID == "arch" ]]; then
    __HostDistroRid="arch-$__HostArch"

I managed to build the SDK locally, however it fails when I try the same in a chroot using our devtools, I get a cryptic error when initializing the cli tool, any idea what it could be? Google seems to indicate this is a permission issue, but the chroot isn't noexec and the build tools are executable.

Failed to initialize CoreCLR, HRESULT: 0x8007001F

Also, it seems the built SDK does not contain ASP.NET, is there a similar way to build these parts?

[omajid]

Failed to initialize CoreCLR, HRESULT: 0x8007001F

Try an strace. It could be something as simple as icu not being found. Or it might be something more complex. strace -f should provide some good hints as to what is going wrong.

Also, it seems the built SDK does not contain ASP.NET, is there a similar way to build these parts?

Nope. ASP.NET Core is not source-buildable just yet. See #375

[alucryd]

Alright, I'll keep downloading the ASP.NET blob for now, thanks.

I got a few straces, the first one: https://paste.xinu.at/ze6/

There were some errors about lttng-ust, after a quick googling I stumbled upon this: https://github.com/dotnet/coreclr/issues/4132

Tried building without lttng-ust in the chroot as suggested, but it failed as well: https://paste.xinu.at/aoD/

[omajid]

From https://paste.xinu.at/ze6/:

[pid 5052] mlock(0x6fcefbd8f000, 4096) = -1 EPERM (Operation not permitted)
[pid 5052] write(2, "Failed to initialize CoreCLR, HR"..., 49Failed to initialize CoreCLR, HRESULT: 0x8007001F) = 49

CoreCLR uses mlock during VM startup. CoreCLR wont run without it. And the build needs to use CoreCLR to run msbuild. You need to somehow give your chroot permission to use mlock (CAP_IPC_LOCK).

Are you using systemd-nspawn by any chance? --capability=CAP_IPC_LOCK should work for that case.

If you can't use modify a chroot - is it some official build system that you can't access? - then that would be worth knowing. Perhaps we can ask coreclr folks to try and handle the case where mlock doesn't work. I am starting to hit this issue in Fedora's build systems as well.

[omajid]

Alright, I'll keep downloading the ASP.NET blob for now, thanks.

I am a bit curious here. Are you doing anything special here or just letting msbuild download it at project build time as a package reference?

[alucryd]

These are official build tools that indeed use systemd-nspawn, I'll talk it over with other arch devs but I'm not sure they'll be keen on enabling it by default. Thanks for the pointer!

As for ASP.NET, I'm just downloading and repackaging the runtime tarball manually.

[omajid]

As for ASP.NET, I'm just downloading and repackaging the runtime tarball manually.

You shouldn't need it. It should all work out of the box: ASP.NET Core should get downloaded via NuGet when you build a project. There's actually code in source-build that handles this. If you are packaging the runtime tarball, you will need to fix up some things in source-build. I can't remember off the top of my head what those are.

[anthraxx]

Ping, any chance to get mlock caps being checked instead of assumed? Quite some time passed so i assume it was forgotten, would be nice to get this resolved

[alucryd]

Actually with the 3.1 release I can build without CAP_IPC_LOCK, sorry for the noise. I assume that when I tried building a preview of 3.0 it was bootstrapped by a 2.2 runtime that didn't have the fix included. I guess this issue can be closed now.

[alucryd]

3.1.104 build breaks on Arch Linux using clang 10, it's corefx again.

/build/dotnet-core/src/dotnet-source-build/artifacts/src/corefx.059a4a19e602494bfbed473dbbb18f2dbfbd0878/src/Native/Unix/System.Native/pal_io.c(917,64): error GD3E32D8E: use of function '__builtin_alloca' is discouraged; there is no way to check for failure but failure may still occur, resulting in a possibly exploitable security vulnerability [-Werror,-Walloca] [/build/dotnet-core/src/dotnet-source-build/artifacts/src/corefx.059a4a19e602494bfbed473dbbb18f2dbfbd0878/src/Native/build-native.proj]

Full build log: https://buildbot.alucryd.xyz/#/builders/257/builds/38/steps/9/logs/stdio

Is it safe to pass -Wno-alloca?

[omajid]

I think this has less to do with 3.1.104 and more to do with the switch to clang 10. You can use -Wno-alloca: dotnet/corefx#42900

[alucryd]

@omajid Thanks, I had to add 2 more flags to get corefx to build -Wno-sign-conversion -Wno-unused-result.

Now the build fails at core-setup, I'm not sure why: https://buildbot.alucryd.xyz/#/builders/257/builds/43/steps/10/logs/stdio

[alucryd]

Sure thing: https://paste.xinu.at/J4hJzsBPAWUwOnwh/

[omajid]

Thanks. I see 3 issues and I am not sure I understand why 2 of them are happening:

+ init_rid_plat
+ '[' == 1 ']'
bash: [: ==: unary operator expected

This error is from if [ $__CrossBuild == 1 ];. The variable should be quoted. But I don't understand how it can be empty. This shell script initializes it to 0. Something else can override it, but it's never empty.

+ __rid_plat=
+ '[' -e /etc/os-release ']'
+ source /etc/os-release
++ NAME='Arch Linux'
++ PRETTY_NAME='Arch Linux'
++ ID=arch
++ BUILD_ID=rolling
++ ANSI_COLOR='38;2;23;147;209'
++ HOME_URL=https://www.archlinux.org/
++ DOCUMENTATION_URL=https://wiki.archlinux.org/
++ SUPPORT_URL=https://bbs.archlinux.org/
++ BUG_REPORT_URL=https://bugs.archlinux.org/
++ LOGO=archlinux
+ [[ arch == \r\h\e\l ]]
+ __rid_plat=arch.

That's another bug. The computed value for __rid_plat should be arch, not arch. (the trailing dot is wrong).

+ '[' == 1 ']'
bash: [: ==: unary operator expected

This is from [ $__linkPortable == 1 ]. Again, __linkPortable is initialized to 0; I dont see how it can be empty here.

[alucryd]

I ran the function as is in a shell, that explains why those variables aren't initialized. The main issue is likely the additional dot, this is not the first time it happens either.

[omajid]

Ah. That explains it. Can you try this change?

-            __rid_plat="$ID.$VERSION_ID"
+            __rid_plat="$ID${VERSION_ID:+.${VERSION_ID}}"

[alucryd]

It does remove the dot, but I just saw I'm already patching core-setup for this particular error: https://git.archlinux.org/svntogit/community.git/tree/trunk/9999-Fix-versionless-RID-computation.patch?h=packages/dotnet-core

[alucryd]

The new 3.1.5 release still fails on Arch Linux, with a new implicit conversion error that's easy to ignore, but again with another RID error: https://buildbot.alucryd.xyz/#/builders/257/builds/51/steps/10/logs/stdio

[omajid]

I think the RID error is actually just a warning. Can you disable the conversion warning (or make it a warning, not an error) and try again?

[alucryd]

You were right, with the help of an additional flag it was able to proceed further. Now core-setup is failing: https://buildbot.alucryd.xyz/#/builders/257/builds/54/steps/10/logs/stdio

[omajid]

    /build/dotnet-core/src/dotnet-source-build/artifacts/src/core-setup.65cd7897774a464b5991c1962f7a0d476bb63101/src/corehost/build.sh --configuration Release --arch x64 --apphostver 3.1.5 --hostver 3.1.5 --fxrver 3.1.5 --policyver 3.1.5 --commithash 6686cd7574e0410b07601e094ed6239df226b7e8
    Unknown base rid (eg.: osx.10.12, ubuntu.14.04) being targeted
  ##vso[task.logissue type=error;sourcepath=/build/dotnet-core/src/dotnet-source-build/artifacts/src/core-setup.65cd7897774a464b5991c1962f7a0d476bb63101/src/corehost/build.proj;linenumber=41;columnnumber=5;code=MSB3073;](NETCORE_ENGINEERING_TELEMETRY=Build) The command "/build/dotnet-core/src/dotnet-source-build/artifacts/src/core-setup.65cd7897774a464b5991c1962f7a0d476bb63101/src/corehost/build.sh --configuration Release --arch x64 --apphostver 3.1.5 --hostver 3.1.5 --fxrver 3.1.5 --policyver 3.1.5 --commithash 6686cd7574e0410b07601e094ed6239df226b7e8" exited with code 255.
  /build/dotnet-core/src/dotnet-source-build/artifacts/src/core-setup.65cd7897774a464b5991c1962f7a0d476bb63101/src/corehost/build.proj(41,5): error MSB3073: The command "/build/dotnet-core/src/dotnet-source-build/artifacts/src/core-setup.65cd7897774a464b5991c1962f7a0d476bb63101/src/corehost/build.sh --configuration Release --arch x64 --apphostver 3.1.5 --hostver 3.1.5 --fxrver 3.1.5 --policyver 3.1.5 --commithash 6686cd7574e0410b07601e094ed6239df226b7e8" exited with code 255.

The exit code is 255, which is the same as -1. This is probably from https://github.com/dotnet/core-setup/blob/aa28510afc9b986c6837db6784d816fe4a66c7d0/src/corehost/build.sh#L192-L195

This earlier comment (#285 (comment)) was about this same issue. Is that patch for that still being applied? Does the updated file contain this change?

-            __rid_plat="$ID.$VERSION_ID"
+            __rid_plat="$ID${VERSION_ID:+.${VERSION_ID}}"

[alucryd]

Worked fine for a couple releases, and it broke with 3.1.109, again, this is getting very old very fast. Can we please get this whole RID situation fixed once and for all ?

https://paste.xinu.at/eFg6qDLenYeBmtRQ/
https://buildbot.alucryd.xyz/#/builders/257/builds/83/steps/10/logs/stdio

@omajid Yes patch is still applied, here are the 3 patches that were previously (and still are afaict) needed to build on arch: https://github.com/archlinux/svntogit-community/tree/packages/dotnet-core/trunk

[omajid]

Sorry for not getting to this sooner (I had a few days off).

I tried out building core-setup (with and without https://github.com/archlinux/svntogit-community/blob/packages/dotnet-core/trunk/9999-Fix-versionless-RID-computation.patch) and I can't reproduce the issue.

From a quick glimpse at the file that's printing the error, it looks like no RID is being computed (not even linux-x64, and definitely not archlinux-x64). Do you have a /etc/os-release file in the environment where you are building this? Any chance you could insert a set -x at the beginning of /build/dotnet-core/src/dotnet-source-build/artifacts/src/core-setup.774fc3d6a9659077864171d095f46b1ea19bb51d/src/corehost/build.sh so we can see where the computation is going wrong?

Can we please get this whole RID situation fixed once and for all ?

If you mean "handle all RIDs correctly" then please count me in as joining your effort. But I don't know how to make this happen. Some of this is also captured in #297

If you mean handling the ArchLinux RIDs, then maybe we could try adding it to the CI matrix for .NET?That should help catch any more breakages where a version-less RID is being incorrectly handled? We might also want to backport dotnet/corefx#41750 to release/3.1 branch to get this into the next 3.1.xxx. release.

[alucryd]

@omajid Sorry about my lack of reply, I have had zero time to do extra work these past weeks. I guess I'll wait for 5.0 to be published here now before having another look at it, hopefully that will sort itself out.

[alucryd]

Finally had time to have a look at 5.0. I managed to go past the first failure with the runtime, but now I don't really know what to do about the aspnetcore failure.

There is an issue with corehost, link libraries are in the wrong order, resulting in a bunch of undefined references, this patch fixes it: https://paste.xinu.at/wSnPbYdO2NeyMLMU/

After that it complains about a missing crossgen in aspnetcore. I also got a warning about nodejs not being in the path so I installed it. Here's the build log: https://buildbot.alucryd.xyz/#/builders/257/builds/98/steps/11/logs/stdio

[omajid]

There is an issue with corehost, link libraries are in the wrong order, resulting in a bunch of undefined references, this patch fixes it: https://paste.xinu.at/wSnPbYdO2NeyMLMU/

This was merged upstream as: dotnet/runtime#42094

Here's the build log: https://buildbot.alucryd.xyz/#/builders/257/builds/98/steps/11/logs/stdio

I haven't seen this error before. Can you build the aspnet repo by itself? Does it also give you the crossgen errors?

[alucryd]

There is an issue with corehost, link libraries are in the wrong order, resulting in a bunch of undefined references, this patch fixes it: https://paste.xinu.at/wSnPbYdO2NeyMLMU/

This was merged upstream as: dotnet/runtime#42094

I'm late to the party again, thanks for the heads up!

Here's the build log: https://buildbot.alucryd.xyz/#/builders/257/builds/98/steps/11/logs/stdio

I haven't seen this error before. Can you build the aspnet repo by itself? Does it also give you the crossgen errors?

Sure thing, I'll give it a try tomorrow and will report back. Thanks for the quick reply.

[alucryd]

I had a local build running when I wrote the above lines, turns out this one went further but still failed later: https://paste.xinu.at/n1dW6Gn11izrMW0D/

It seems to look for a tarball of the runtime, but the only file in that directory is dotnet-hostfxr-internal-arch-x64.5.0.0.tar.gz.

Putting that error aside, the immediate differences between this build and the one above I can think of is that this one ran locally on my machine, using 16 threads on a regular HDD, while the above ran on our build server in a chroot with 48 threads on an SSD. Could it be some kind of race condition where stuff runs before crossgen is actually available?

Seeing that aspnetcore builds fine locally via source-build but not in that chroot I'm not sure if building aspnetcore standalone will help (can't really do that in a chroot with our tools unless I write a dedicated PKGBUILD), but I can still give it a try locally if you think it's worth it.

[omajid]

It seems to look for a tarball of the runtime, but the only file in that directory is dotnet-hostfxr-internal-arch-x64.5.0.0.tar.gz.

That's strange. Did the build produce any other .tar.gz files? If not, it seems like the actual error is somewhere earlier.

Could it be some kind of race condition where stuff runs before crossgen is actually available?

It's definitely possible. We have seen build races earlier and I have even seen some builds fail recently which then worked on a re-try without any changes.

The hard part is going to be finding the race. Is the build error reproducible on the build server?

[alucryd]

@omajid Apologies for the lack of reply, life got the better of me again. I tried building the newest 5.0.102 SDK, but it comes with yet another regression: use of undeclared identifier 'TRUE' while building the runtime part, please see the full log here: https://buildbot.alucryd.xyz/#/builders/257/builds/106/steps/11/logs/stdio

I have less and less time to debug the dotnet build process and make it work for us, and I fear the Arch Linux packages will stay at 3.1.108 for a long time with every release seemlingly more broken than the last. You mentioned adding an Arch Linux build in your CI, is that still on the table? It would help tremendously if all these problems were caught upstream.

[omajid]

I tried building the newest 5.0.102 SDK, but it comes with yet another regression: use of undeclared identifier 'TRUE' while building the runtime part, please see the full log here: https://buildbot.alucryd.xyz/#/builders/257/builds/106/steps/11/logs/stdio

Sounds like something to do with libicu. This will need further investigation...

You mentioned adding an Arch Linux build in your CI, is that still on the table?

@crummel @dagood @dseefeld Any thoughts on this? What would it take to add additional distributions to our CI run?

[dagood]

Things needed to get that off the ground:

• A Docker image with all the build prerequisites. (Adding a Dockerfile in https://github.com/dotnet/dotnet-buildtools-prereqs-docker)
• Patches that fix the build in dotnet/runtime and anywhere else. Arch is not supported by .NET 5.0 so this may be tricky for the dotnet/runtime native build in particular. I'm not familiar with how different Arch is from other distros.
• Add the Arch RID to this list of RIDs: (we haven't had time to get rid of this for Add support for banana linux #297)

  source-build/tools-local/tasks/Microsoft.DotNet.SourceBuild.Tasks.XPlat/PublishCoreSetupBinaries.cs

  Lines 40 to 43 in 29505f6

  	"-rhel.7", "-rhel.8", "-rhel.9",
  	".rhel.7", ".rhel.8", ".rhel.9",
  	"-centos.7", "-centos.8", "-centos.9",
  	".centos.7", ".centos.8", ".centos.9",

• Add to matrix.yml to get CI jobs in.

At that point we'll be able to tell if there are issues. It doesn't really prevent regressions though. Because dotnet/source-build is only able to pick up the sources from a .NET SDK build that has already completed all the way through, someone on the dotnet/source-build side needs to see the error and file issues manually on the root-cause repo (dotnet/runtime), then add any patches needed to dotnet/source-build to get around the problem. If we can't get that done very quickly, it seems likely to me that we would have to tag the repo before fixing the problems to avoid delaying .NET availability on other distros that do have official declared support. There can always be PRs after the tag to fix up Arch, though.

(We do have a plan targeting 6.0 (arcade-powered source-build) that lets us put source-build CI in each repo, to actually prevent regressions from entering the source repo. Adding Arch CI to these repos is probably another discussion we'll have to have at that point.)

[dagood]

use of undeclared identifier 'TRUE' while building the runtime part,

It looks like this is discussed at dotnet/runtime#47346 with a workaround in the last comment. Says it happens with libicu is too new. Here's a fix PR in 6.0, can potentially cherry-pick it into a patch file: dotnet/runtime#47352.

[alucryd]

Thank you both for the quick replies.

@dagood AFAIK Arch has never been supported, but seeing how many emails I get from people expecting updates to .NET 5, it seems to be a pretty popular choice among .NET developers anyway. Would be great to enter the supported club.

Things needed to get that off the ground:

• A Docker image with all the build prerequisites. (Adding a Dockerfile in https://github.com/dotnet/dotnet-buildtools-prereqs-docker)

I can definitely work on a PR for the Dockerfile over the weekend.

• Patches that fix the build in dotnet/runtime and anywhere else. Arch is not supported by .NET 5.0 so this may be tricky for the dotnet/runtime native build in particular. I'm not familiar with how different Arch is from other distros.

The required patches (at least for 3.1.108) are already stored in our git: https://github.com/archlinux/svntogit-community/tree/packages/dotnet-core/trunk

Arch is not that different from other distros, we're very similar to Fedora Rawhide and (almost) always provide the very latest stable version of everything in a rolling fashion.

• Add the Arch RID to this list of RIDs: (we haven't had time to get rid of this for Add support for banana linux #297)

  source-build/tools-local/tasks/Microsoft.DotNet.SourceBuild.Tasks.XPlat/PublishCoreSetupBinaries.cs

  Lines 40 to 43 in 29505f6

  	"-rhel.7", "-rhel.8", "-rhel.9",
  	".rhel.7", ".rhel.8", ".rhel.9",
  	"-centos.7", "-centos.8", "-centos.9",
  	".centos.7", ".centos.8", ".centos.9",

• Add to matrix.yml to get CI jobs in.

Guessing these 2 are to be undertaken on your end.

At that point we'll be able to tell if there are issues. It doesn't really prevent regressions though. Because dotnet/source-build is only able to pick up the sources from a .NET SDK build that has already completed all the way through, someone on the dotnet/source-build side needs to see the error and file issues manually on the root-cause repo (dotnet/runtime), then add any patches needed to dotnet/source-build to get around the problem. If we can't get that done very quickly, it seems likely to me that we would have to tag the repo before fixing the problems to avoid delaying .NET availability on other distros that do have official declared support. There can always be PRs after the tag to fix up Arch, though.

(We do have a plan targeting 6.0 (arcade-powered source-build) that lets us put source-build CI in each repo, to actually prevent regressions from entering the source repo. Adding Arch CI to these repos is probably another discussion we'll have to have at that point.)

Thanks for the heads up.

use of undeclared identifier 'TRUE' while building the runtime part,

It looks like this is discussed at dotnet/runtime#47346 with a workaround in the last comment. Says it happens with libicu is too new. Here's a fix PR in 6.0, can potentially cherry-pick it into a patch file: dotnet/runtime#47352.

Awesome, thanks for the link. The PR doesn't apply cleanly though, I'll rebase it over the week-end, see if I can get everything to build.

[dagood]

• PublishCoreSetupBinaries.cs [...]
• Add to matrix.yml to get CI jobs in. [...]

Guessing these 2 are to be undertaken on your end.

This should be doable via public PR actually, just add more lines like the existing ones:

• tools-local/tasks/Microsoft.DotNet.SourceBuild.Tasks.XPlat/PublishCoreSetupBinaries.cs#L40-L43
• .vsts.pipelines/builds/matrix.yml#L72-L81

Arch is not that different from other distros, we're very similar to Fedora Rawhide and (almost) always provide the very latest stable version of everything in a rolling fashion.

Being a rolling distro is actually a problem for declared official support. 😕 Right now .NET 5.0 specifically supports versioned Fedora releases, not Rawhide. Similarly, openSUSE Leap is supported but not Tumbleweed. dotnet/runtime#3527 (comment)

(The doc IMO isn't clear on this: the "+" may imply the rolling versions of these distros are supported. I initially took it that way when I read it.)

[ettolrach]

Is there any update on this? The last comment has been from a month and 4 days ago, and .NET 5 is still not available on Arch Linux. I would like to start a new project and I'd hate to have to use Windows for it.

[laktak]

@ettolrach .Net 5 is in AUR. Works fine tough I'd also prefer to have it in the official repo.

[MichaelSimons]

[Triage] Closing as .NET is being source built by Arch Linux - https://wiki.archlinux.org/title/.NET and Arch Linux - dotnet-sdk 6.0.10.sdk110-1 (x86_64)