dotnet: Add dotnet 10

[spencercw]

This switches from the Visual Studio URLs to the .NET URLs, as per upstream [1].

[1] dotnet/core#9869

---

Note

Adds .NET 10.0.100 support, switches downloads to builds.dotnet.microsoft.com, updates packaging, and includes 10.0.100 in CI.

• Dotnet recipes:
  • New version: Add recipes-mono/dotnet/dotnet_10.0.100.bb (runtime 10.0.0) with per-arch sha512.
  • Source URL: Update recipes-mono/dotnet/dotnet.inc SRC_URI to https://builds.dotnet.microsoft.com/...; drop SRC_FETCH_ID usage and related vardeps.
  • Install/package contents:
    • Install packs into ${datadir}/dotnet/ and include in FILES:${PN}-dev.
    • Add RDEPENDS:${PN}-dev = "zlib".
    • Add INSANE_SKIP:${PN}-dev = "libdir staticdev dev-elf".
• CI:
  • Extend matrix in .github/workflows/CI_github.yml to include dotnet_version: 10.0.100 alongside existing versions.

^{Written by Cursor Bugbot for commit 94b834b. This will update automatically on new commits. Configure here.}

[ajlennon]

Thanks @spencercw

[ajlennon]

(I am having problems with the IT service provider that provides the build system I use for CI - need to fix this over the next few days for the CI to run)

[ajlennon]

The mono 10 builds seem to be failing?

[spencercw]

Ah, apologies, I had not tested the dotnet-helloworld package (I only tested with externally compiled .NET 6/8/10 apps).

It would appear the packs directory is required to perform builds, which I have now added. This directory was also present in the .NET 6 and 8 SDKs; do you know if there was any particular reason this directory was omitted from the Yocto package, or was this a simple oversight?

[ajlennon]

No idea I am afraid - I would go with "oversight" !

[spencercw]

So the build error on 'build-and-test (8.0.406, 6.12.0.206, styhead, arm)':

Error: the required library libhostfxr.so could not be found in [/__w/meta-mono/meta-mono/styhead/build/tmp/work/x86_64-linux/python3-clr-loader-native/0.2.6/recipe-sysroot-native/usr/share/dotnet/host/fxr/10.0.0]

It's trying to use the .NET 10 files even though we are building with .NET 8. I had an issue like this while testing this change and switching between PREFERRED_VERSION values, which I worked around by cleaning the packages (although I don't remember specifically which package needs to be cleaned to resolve this error). I can see there is a commented out clean step in the CI configuration; perhaps this should be uncommented?

[ajlennon]

Any thoughts on why this is failing?

[spencercw]

I've been looking into this a bit more. Essentially what happens is that when the version is switched, empty directories get left behind in tmp/work/core2-64-poky-linux/dotnet-helloworld/1.0/recipe-sysroot-native/usr/share/dotnet with the old version number. This confuses the dotnet tool because it assumes the old version is installed, then falls over when it can't find the required files.

The cleanup happens in meta/classes-global/staging.bbclass:

bb.note("%s exists in sysroot, but is stale (%s vs. %s), removing." % (c, lnk, c + "." + taskhash))
sstate_clean_manifest(depdir + "/" + lnk, d, canrace=True, prefix=workdir)

The canrace=True parameter is what causes the directories to be left behind. Changing this to False sort of helps, but there is another problem. If you switch back to a version which has previously been built, the wrong version can get installed into recipe-sysroot-native. This happens in meta/classes-global/staging.bbclass where oe.sstatesig.find_sstate_manifest returns tmp/sstate-control/manifest-x86_64-dotnet-native.populate_sysroot, which contains the list of files used to populate recipe-sysroot-native, but this list will be of the most recently built version of dotnet-native, so if switching versions did not trigger a rebuild then this list will be out of date.

Hopefully that makes some kind of sense. It's confusing, and the bitbake behaviour around version switches seems a bit buggy. I think we should just clean the dotnet packages in the CI build when switching between versions.

[ajlennon]

Thanks for looking at this @spencercw - it is a bit confusing yes. I did think we had a cleaning step in the CI.

Aha I see I have that commented out - shall we add that back in?

meta-mono/.github/workflows/CI_github.yml

Line 85 in b05f077

# - name: Cleaning

[spencercw]

I have restored the cleaning step and added dotnet-helloworld to it.

[ajlennon]

Great stuff thanks - will see if it builds!

[ajlennon]

Very odd. A completely different pythonnet failure now

[spencercw]

I'm struggling to work out how best to deal with this. The current release version (3.0.5) of pythonnet does not support .NET 10. I might be able to backport the relevant patches from master, but that raises the minimum supported version to .NET 8, which would just leave the test-image-mono build broken for .NET 6.

I'm inclined to leave pythonnet unsupported on .NET 10 until there is an official release, but I'm not sure how best to do that without leaving the CI build in a broken state. Any ideas?

[ajlennon]

I'm inclined to leave pythonnet unsupported on .NET 10 until there is an official release, but I'm not sure how best to do that without leaving the CI build in a broken state. Any ideas?

Not ideal is it but not much we can do about it either. I am inclined to agree we wait until pythonnet is supported properly rather than diving in. Which does mean yes we remove it from the CI build. Shall we remove the recipe here and make a note in an update to the README that pythonnet is not supported with .NET 10?

meta-mono/recipes-mono/images/test-image-mono.bb

Line 11 in b05f077

python3-pythonnet \

[spencercw]

Ok how's this?

[ajlennon]

LGTM - let's see what happens (I've seen a chatter about M$ charging per minute for self hosted runners so will have to work out what these builds are costing now and whether there's a need to move to another CI offering... Any thoughts appreciated!

[spencercw]

Yeah I saw that. Mad isn't it. I think they've postponed that for the time being, but I'm sure it'll be back before long.

We self-host GitLab at my job which works well enough for us. We've still got a bunch of CI stuff on Jenkins as well.

[ajlennon]

yeah meta-mono was on Jenkins before I moved over to GitHub because I couldn't cope with the agony any more :-D

[spencercw]

Looks like the arm version has a dependency on liblttng-ust.so.1. Let's try this.

[ajlennon]

Great we got a passing build - will let the other complete

[spencercw]

System.UnauthorizedAccessException: Access to the path '/github/home/.local/share/NuGet/Migrations' is denied.

Well that's a new one. Any idea what that's about?

[ajlennon]

No - excepting that previously and what should happen is that the CI recipes run individually. I see now they seem to be running in parallel which could be causing problems

[spencercw]

Hm, that does sound problematic. Maybe this?

I'm off for Christmas now so can pick this up again next week. Merry Christmas :)

[ajlennon]

ok have a good break !

[ajlennon]

Nearly there - now there's a test file missing?

https://github.com/DynamicDevices/meta-mono/actions/runs/20490977722/job/58883349870#step:10:67

[spencercw]

Urgh. The interpreter path in the binary is wrong:

$ file tmp/work/core2-64-poky-linux/dotnet-helloworld/1.0/image/opt/dotnet-helloworld/dotnet-helloworld
tmp/work/core2-64-poky-linux/dotnet-helloworld/1.0/image/opt/dotnet-helloworld/dotnet-helloworld: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /mnt/data3/its/yocto-styhead/build-docker/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=6a499c38ea223fd4a6256645555dcee6ee907966, stripped

I've added a patchelf to the dotnet-helloworld recipe to work around this. I'm open to suggestions if you've got a better idea.

[spencercw]

Any chance this can be progressed? It needs another CI run.

[ajlennon]

Ah thanks for prodding me - have kicked one off

[ajlennon]

10 and 8 built successfully but it seemed to run into trouble with 6 ?

https://github.com/DynamicDevices/meta-mono/actions/runs/20571801153/job/61718537286?pr=268

[spencercw]

I don't really understand what's happening here. I'm unable to reproduce the error locally, even inside your Docker image. I have added some commands to print out some extra data which may potentially give a clue.

[ajlennon]

I'm not sure why your workflows need my approval to be honest - I had things set up so I needed to approve an initial PR which seems sensible but after that it seems to me trust can be extended. Not entirely sure if this is some tightening of the GitHub rules but it's another thing on my list to look at.

I was out at FOSDEM last weekend so somewhat overcome and playing catchup here but I was chatting with the Yocto folks and I am very keen to try to bring meta-mono up to follow best Yocto practices, put it through the Yocto layer compliance checks and try to achieve the compliance badge.

Not least because I want to know for myself what current best practice looks like so I can follow it with my commercial hat on. So.... apologies again for the long iteration period trying to merge in your - much appreciated - PRs but I'm going to try really hard to figure out what the hell is going on with these build failures :)

And, because I don't think people say this enough, thank-you for putting the effort in to push your improvements into this repo sir

[ajlennon]

RIght ho - so I was following this through and I see we fail again at the same point with the 6.x build.

I have a couple of thoughts on ways forward

• the techie in me wants to know what the problem is and fix it. You seem to be saying you don't see this problem so it may just be a CI thing but neither of us know what it is

• I have limited time and limited visibility on whether anybody actually cares about maintaining older code.

I am thinking we say "this is no longer supported as it doesn't work in CI and has been removed, use at your own risk"

If people actuallly do care they will shout and - perhaps even - fix the issue

That enables us to move on and merge in your contribution. Does that make sense or am I missing something?

[ajlennon]

I think we are getting these CI errors elsewhere - I am not sure why but am having a comprehensive look at what's going on the new PR

[ajlennon]

I did a deep dive into trying to work out what's going on and to be honest @spencercw I'm still not entirely sure but it seemed to be related to sstate caching oddities. I've added a couple of commits which get things building, the CI is passing and I'll merge this in now. Thanks once more for your contribution. and apologies that it's taken it this long to get this in!

[spencercw]

Thanks for picking this up. I have backported this to scarthgap in #274, so now we can do this all over again 😂

[ajlennon]

Haha! Well let's hope some of these CI fixes "stick" !!! :-D