Hello, is this the official repo of the dotnet snaps?:
I ask because the build of my snap started failing around the 16th of May (I have a recurrent CI job that runs every day which creates a snap and tests that it still works), and I think I pinpointed the regression to the last release of the dotnet-runtime-70 snap. I then reported the bug here:
Let me know if I should report it somewhere else please?
If this is indeed the repo where to report the bug, then my next question is: why are there no git tags in it? If each release in the snap store matched a git tag, then I could possibly investigate the regression myself and I even try to create a PR to fix the regression.
BTW how can this bug show up in a stable channel so easily? By using this snap as a dependency, it seems we cannot stay in the previous version of the snap in any way, so we’ve had to resort for now to a workaround by using stage-packages instead of stage-snaps, but hopefully there’s a better way to rollback to previous versions of snap dependencies, otherwise it is safer to still depend on apt for this? (which seems should not be a long-term goal I guess)
Unfortunately if I’m guessing what’s going on here correctly, this is not a regression.
Your software needs to be built against compatible libraries. When you use dotnet-sdk as a build snap, it brings along core 24 with it, even in the snapcraft build environments.
However assuming you use stage-snaps too, when dotnet requiring core24 is put into your snap, presumably core22, there’s no core24 libraries to use and dotnet cannot run. You can’t mix and match the cores in the snap itself because it’s not using the same mechanisms as build-snaps do.
That’s unfortunately not a problem with the dotnet snap itself, that’s an inherent problem from the use of stage-snaps and in this case, swapping over to the appropriate Apt package is probably the best solution going forward (P.S we have .NET 8 in both 22.04 and 24.04 repo’s now).
So unfortunately I’d have to imagine the reason this slipped by is because it’s in one of the categories that’s guaranteed to break given enough time. There isn’t a fix for this problem because the problem can’t be fixed and just needs avoiding instead. And as many people who see this as broken would see this as fixed (because the same mistake would now work in Core24 until we repeat this again for Core26).
The .NET packages are from apt are in Main and get full support for the lifetime of the Core release (so 10 years!). These packages are guaranteed to remain compatible with their core environment for the duration of the release, and get security updates from Canonical for the duration of that release too. .NET 7 as a snap wouldn’t and is already EOL.
Tl;Dr in this situation, prefer the dotnet stage-packages from Apt.
I kinda understand where you’re coming from, but I’m going to think out loud here and brainstorm some ideas that, to me, seem less hacky than the proposed “resort to deb packages and let those glib crashes live there” solution.
First idea: cannot these dotnet packages have different stable tracks depending on what core version they are from? For example, as far as I understand the dotnet-runtime-70 was updated on the 16th of May, and that new release now started to depend on core24. Couldn’t you leave the previous version, that stilll depends on core22 in a stable-22 track? If this sounds acceptable, then you could also create a stable-24 track, and make the stable be a symbolic link to stable-24, at least until Ubuntu26.04 (and with it, core26) is released.
Second idea: how about coding some sort of safeguard in the snap daemon that detects when you are about to install a snap that depends on core22 if you’re using Ubuntu24.04 (or viceversa). I know then that this would mean hardcoding “magic snap names” into snapd’s source code, but isn’t this ugly-looking-algorithm better than crashes at runtime faced by end-users? (In my case, I was lucky that my CI actually tested the generated snap, but others might not be that lucky.)
BTW, I still don’t know if the github repo where I reported the bug is the correct one? Could you clarify this please. Thanks
The publisher could do this yes, but the end result to yourself in my opinion wouldn’t be much different. When you use build-snaps, the content is put directly into your snap, it’s not a content snap where that content can update separately when a separate snap updates. Whether you use the snap or the apt package, you’re still responsible for rebuilding the snap from time to time, so the end result doesn’t change much (apart from it runs). I’m also unsure, but would have no reason to believe e.g Dotnet 8 as a snap would have more than 3 years security support even as an LTS, but both 7 and 8 would have 10 years as a stage package, apt is explicitly covered by general Ubuntu security policies but I’ve no idea about the Snap, you’d have to ask the publisher.
Did Snapcraft in the CI not do similar? There should be a library linter that is run, and while it won’t find everything, it’s not magic hardcoding. I’d have thought there’d be a warning in the build saying that “libraries were expected but not found” (paraphrased). It won’t outright stop the build because it’s not always a deal breaker but you could adjust your CI process into highlighting if this errors.
I think unfortunately adding special cases to detect errors would probably not go down too well because the incompatibility matrix is effectively infinite (you’re basically saying A is only ever compatible with B). Any single snap can be viable as a build-snap so there’d be tennes of thousands of combinations to test, alternatively you leave it to “common” snaps and inevitably end up missing something. Some stage-snaps might not have compiled code and might even run everywhere (e.g a trivial Python script).
IMO, if you were to treat this as a feature request rather than a bug, you’d need to contact the dotnet packagers, which brings another problem:
dotnet-sdk is possibly becoming dotnet (SDK and Runtime bundled!)
Your request around aligning tracks to cores makes perfect sense, so ultimately it’d come down to whether it justifies the effort on their end. The post says it’ll be owned by the Canonical Foundations Team but doesn’t yet provide a way to contact them (because until now I believe it’s been owned by Microsoft directly).
If you believe snapd could do it better, then that’s an easier place for a bug report, snapd in Launchpad
But ultimately I believe the technically correct and easiest answer for everyone involved is to prefer the Apt package via stage-package, you can see that’s exactly how I’ve been doing it in e.g Pinta since Canonical officially published C# packages!
Before that I was still doing it via Microsoft repositories directly because the dotnet-sdk snap otherwise cause me similar problems it’s causing you here.
I believe you could potentially add the revision ID to stage-snaps to get the exact same reproducible version everytime, but you’d be getting no security or bug fixes too and the pain is you’d need to know the revisions in advance.
IMO, using Apt for C# in snaps like this isn’t a workaround, it’s objectively the best solution in this context and I’ve been sat happily doing that 2-3 years on the official dotnet apt packages already.
The net snap is IMO quite clearly intended for developers/users of NET in traditional environments, not in snaps themselves.
We are currently going through a process of transferring the .NET snap maintenance from Microsoft to Canonical. Long story short, as it currently stands, the dotnet-runtime-* content snaps will continue to be maintained and we’ll replace the dotnet-sdk snap with a dotnet snap that will allow you to install runtimes and SDKs into your machine (as a developer or end-user).
That repository is for this new dotnet snap, although you can still use it to report issues with .NET snaps in general. We’ll find better ways to tag and track releases across all .NET snaps as we progress through this transition.
I was also investigating your report just this morning and found it somewhat weird that you’re now seeing this error after the May 16th update (rev. 30), because the snap base did not change in the interim, as we’re still in core20 and we’re also getting our bits from the same source as last month’s update (rev. 29), which is from https://dotnet.microsoft.com/en-us/download/dotnet/7.0. These bits are supposed to run with any Ubuntu release starting from 18.04 (see docs).
I’ll keep investigating and get back to you on the GitHub issue.
No, our CI didn’t fail at snap generation phase, but at snap testing phase. The snap was already generated and pushed as artifacts, then the next CI job picks it up, installs it, and runs it, to test if it works (and it’s only in this latter step where it failed).
I believe you could potentially add the revision ID to stage-snaps to get the exact same reproducible version everytime,
How to do that? I don’t find any docs that explains this
That repository is for this new dotnet snap, although you can still use it to report issues with .NET snaps in general. We’ll find better ways to tag and track releases across all .NET snaps as we progress through this transition.
That sounds like a great plan, because I couldn’t find git tags that mapped to the last release at the moment
Should say “.NET”, as “.NET Core” is old branding name.
License says “unset”.
It could also point to the github repo for reference (e.g. to report bugs).
I’ll keep investigating and get back to you on the GitHub issue.
Cool, let’s continue on github? To not spam the forum with bits that might be better to put in the github issue. BTW for your investigation you could use my repo which is opensource, so you got a fully reproducible minimal testcase.
